1. Generic products Stand-alone systems that are marketed and sold to any customer who wishes to buy them • Examples•PC software such as graphics
... [Show More] programs•Pro- ject management tools•CAD software•Software for specif- ic markets such as appointments systems for dentists. 2. Customized products 3. What is soft- ware? 4. What are the at- tributes of good software? 5. What is software engineering? 6. What are the fun- damental soft- ware engineering activities? 7. What is the dif- ference between software engi- neering and com- puter science? 8. What is the dif- ference between software engi- neering and sys- tem engineer- ing? Software that is commissioned by a specific customer to meet their own needs. •Examples -embedded control systems, air traffic control software, traffic monitoring sys- tems. Computer programs and associated documentation. Soft- ware products may be developed for a particular customer or may be developed for a general market. Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable. Software engineering is an engineering discipline that is concerned with all aspects of software production. Software specification, software development, software validation and software evolution. Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software. System engineering is concerned with all aspects of com- puter-based systems development including hardware, software and process engineering. Software engineering is part of this more general process. 9. What are the key challenges fac- ing software en- gineering? 10. What are the Coping with increasing diversity, demands for reduced delivery times and developing trustworthy software. Roughly 60% of software costs are development costs, costs of software 40% are testing costs. For custom software, evolution engineering? 11. What are the best software en- gineering tech- niques and meth- ods? costs often exceed development costs. While all software projects have to be professionally man- aged and developed, different techniques are appropriate for different types of system. For example, games should always be developed using a series of prototypes whereas safety critical control systems require a complete and ana- lyzable specification to be developed. You can't, therefore, say that one method is better than another. 12. Acceptability Software must be acceptable to the type of users for which it is designed. This means that it must be understandable, usable and compatible with other systems that they use. 13. Stand-alone ap- plications 14. Interactive trans- action-based ap- plications 15. Embedded con- trol systems 16. Batch process- ing systems These are application systems that run on a local comput- er, such as a PC. They include all necessary functionality and do not need to be connected to a network. Applications that execute on a remote computer and are accessed by users from their own PCs or terminals. These include web applications such as e-commerce ap- plications. These are software control systems that control and man- age hardware devices. Numerically, there are probably more embedded systems than any other type of system. These are business systems that are designed to process data in large batches. They process large numbers of individual inputs to create corresponding outputs. 17. Entertainment systems 18. Systems for modelling and simulation 19. Data collection systems 20. Systems of sys- tems These are systems that are primarily for personal use and which are intended to entertain the user. These are systems that are developed by scientists and engineers to model physical processes or situations, which include many, separate, interacting objects. These are systems that collect data from their environ- ment using a set of sensors and send that data to other systems for processing. These are systems that are composed of a number of other software systems. 21. RE defects cost RE defects cost 10-200 times more to correct once fielded than they would if they were detected during requirements development. 22. Ounce of Preven- tion 23. Requirements Engineering (RE) Involve end users as early as possible. Create a throwaway prototyping. Deliver the software incrementally instead of all at once. Conduct a requirements workshop Perform use case analysis Create the user manual first. a set of activities concerned with identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used. Hence, RE acts as the bridge between the real world needs of users, customers, and other constituencies affected by a software system and the capabilities and opportunities afforded by software- intensive technologies 24. Types of Require- ments User requirements Statements in natural language plus diagrams of the ser- vices the system provides and its operational constraints. Written for customers System requirements A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor Software specification A detailed software description which can serve as a basis for a design or implementation. Written for developers 25. User require- ments Client manager System end-users Client engineers Contract managers System architects 26. System require- ments System end-users Client engineers System architects Software developers 27. Software design specification Client engineers (perhaps) System architects Software developers 28. Functional re- quirements Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. 29. Non-functional requirements Constraints on the services or functions offered by the system such as timing constraints, constraints on the de- velopment process, standards, etc. 30. Feasibility stud- A short focused study that checks ies -If the system contributes to organisational objectives =If the system can be engineered using current technolo- gy and within budget -If the system can be integrated with other systems that are used 31. Elicitation and Involves technical staff working with customers to find out analysis about the application domain, the services that the system should provide and the system's operational constraints. 32. Requirements Introduction Document Glossary Structure User requirements definition System architecture System requirements specification System models System evolution Appendices Index 33. Requirements Validity checking Consistency Completeness Realism Verifiability 34. What is a "re- a condition or capability needed by a user to solve a quirement"? problem or achieve an objective 35. What is a "prob- A problem is a difference lem"? between things as desired and things as perceived 36. A software an abstract representation of a process. It presents a 37. process model is description of a process from some particular perspective. The main draw- is the difficulty of accommodating change after the back of the water- process is underway. In principle, a phase has to be com- fall model 38. There are sep- arate identified phases in the wa- terfall model 39. Waterfall model problems 40. Incremental de- velopment bene- fits 41. Incremental de- velopment prob- lems 42. The four ba- sic process activ- ities 43. The process of establishing pleted before moving onto the next phase. Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance -Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer require- ments. -The waterfall model is mostly used for large systems en- gineering projects where a system is developed at several sites. -The cost of accommodating changing customer require- ments is reduced. -It is easier to get customer feedback on the development work that has been done. -More rapid delivery and deployment of useful software to the customer is possible. -The process is not visible. -System structure tends to degrade as new increments are added. specification, development, validation and evolution are organized differently in different development processes. -Feasibility study -Requirements elicitation and analysis what services are -Requirements specification required and the constraints on the system's op- eration and de- velopment. -Requirements validation 44. Design activities -Architectural design, where you identify the overall struc- ture of the system, the principal components (sometimes called sub-systems or modules), their relationships and how they are distributed. -Interface design, where you define the interfaces be- tween system components. -Component design, where you take each system compo- nent and design how it will operate. -Database design, where you design the system data structures and how these are to be represented in a data- base. 45. Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer. 46. Testing stages -Development or component testing Individual components are tested independently; Components may be functions or objects or coherent groupings of these entities. -System testing Testing of the system as a whole. Testing of emergent properties is particularly important. -Acceptance testing Testing with customer data to check that the system meets the customer's needs. 47. Software evolu- tion Software is inherently flexible and can change. As requirements change through changing business cir- cumstances, the software that supports the business must also evolve and change. Although there has been a demarcation between devel- opment and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new. 48. Change leads to rework so the costs of change include both rework (e.g. re-analysing requirements) as well as the costs of imple- menting new functionality 49. Change avoid- ance where the software process includes activities that can anticipate possible changes before significant rework is required. 50. Change toler- ance where the process is designed so that changes can be accommodated at relatively low cost. 51. A prototype is an initial version of a system used to demonstrate con- cepts and try out design options. 52. Benefits of proto- typing Improved system usability. A closer match to users' real needs. Improved design quality. Improved maintainability. Reduced development effort. 53. Examples of pro- totyping LYMB LYMB is an object-oriented development environment aimed at developing applications that require combining graphics-based user interfaces, visualization, and rapid prototyping. PSDL PSDL is a prototype description language, to describe the real-time software 54. Incremental de- velopment Develop the system in increments and evaluate each in- crement before proceeding to the development of the next increment; Normal approach used in agile methods; Evaluation done by user/customer proxy. 55. Incremental de- livery Deploy an increment for use by end-users; More realistic evaluation about practical use of software; Difficult to implement for replacement systems as incre- ments have less functionality than the system being re- placed 56. Incremental de- livery problems Most systems require a set of basic facilities that are used by different parts of the system. The essence of iterative processes is that the specification is developed in conjunction with the software. Iterative delivery is problematic when the new system is intended to replace an existing system. 57. Boehm's spiral model Process is represented as a spiral rather than a sequence of activities with backtracking. Each loop in the spiral represents a phase in the process. No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required. Risks are explicitly assessed and resolved throughout the process. 58. Spiral model sec- tors Objective setting Specific objectives for the phase are identified. Risk assessment and reduction Risks are assessed and activities put in place to reduce the key risks. Development and validation A development model for the system is chosen which can be any of the generic models. 59. What is the main difference be- tween the "Spiral model" and oth- er Software process models? 60. The Rational Uni- fied Process Planning The project is reviewed and the next phase of the spiral is planned. Explicit Recognition of Risk A modern generic process derived from the work on the UML and the associated Unified Software Development Process. +Good example of a hybrid process model. -Brings together aspects of the 3 generic process models discussed previously. -Illustrates good practice in specification and design -Supports prototyping and incremental delivery +Normally described from 3 perspectives -A dynamic perspective that shows phases over time; -A static perspective that shows process activities; -A practice perspective that suggests good practice. 61. RUP phases Inception Establish the business case for the system. Elaboration Develop an understanding of the problem domain Establish an architectural framework Develop the project plan Identify key project risks. Construction System design, programming and testing. Transition Deploy the system in its operating environment. 62. RUP iteration In-phase iteration Each phase is iterative with the results developed incre- mentally. Cross-phase iteration As shown by the loop in the RUP model, the whole set of phases may be enacted incrementally. 63. The Rational Uni- fied Process is 64. The most impor- tant innovation in the RUP are 65. What are the problems with the traditional methods? 66. Agile methods a modern generic process model that is organized into phases (inception, elaboration, construction and transi- tion) but separates activities (requirements, analysis and design, etc.) from these phases. the separation of phases and workflows, and the recogni- tion that deploying software in a user's environment is part of the process. Unclear/Fuzzy Requirements Cannot accommodate changes quickly Heavy Documentation and Sign offs User involvement only at the beginning and end Working software visible very late Testing is (very) late in the project 67. The aim of agile methods is Focus on the code rather than the design Are based on an iterative approach to software develop- ment Are intended to deliver working software quickly and evolve this quickly to meet changing requirements. to reduce overheads in the software process (e.g. by lim- iting documentation) and to be able to respond quickly to changing requirements without excessive rework. 68. Agile manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 69. The principles of agile methods Customer involvement Customers should be closely involved throughout the de- velopment process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system. Incremental delivery The software is developed in increments with the customer specifying the requirements to be included in each incre- ment. People not process The skills of the development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes. Embrace change Expect the system requirements to change and so design the system to accommodate these changes 70. Problems with agile methods 71. Plan-driven and agile develop- ment 72. Is it important to have a very de- tailed specifica- tion and design before moving to implementation? Maintain simplicity Focus on simplicity in both the software being developed and in the development process. Wherever possible, ac- tively work to eliminate complexity from the system. It can be difficult to keep the interest of customers who are involved in the process. Team members may be unsuited to the intense involve- ment that characterizes agile methods. Prioritizing changes can be difficult where there are multi- ple stakeholders. Maintaining simplicity requires extra work. Contracts may be a problem as with other approaches to iterative development. Plan-driven development A plan-driven approach to software engineering is based around separate development stages with the outputs to be produced at each of these stages planned in advance. Not necessarily waterfall model - plan-driven, incremental development is possible Iteration occurs within activities. Agile development Specification, design, implementation and testing are in- ter-leaved and the outputs from the development process are decided through a process of negotiation during the software development process. If so, you probably need to use a plan-driven approach 73. Is an incremental delivery strategy, where you deliv- er the software to customers and get rapid feed- back from them, realistic? 74. How large is the system that is be- ing developed? 75. Extreme pro- gramming 76. XP and agile prin- ciples 77. 77. If so, consider using agile methods. Agile methods are most effective when the system can be developed with a small co-located team who can commu- nicate informally. This may not be possible for large systems that require larger development teams so a plan-driven approach may have to be used. New versions may be built several times per day; Increments are delivered to customers every 2 weeks; All tests must be run for every build and the build is only accepted if tests run successfully. Incremental development is supported through small, fre- quent system releases. Customer involvement means full-time customer engage- ment with the team. People, not process, are supported through pair program- ming, collective ownership and a process that avoids long working hours. Change supported through regular system releases. Maintaining simplicity through constant refactoring of code. Extreme pro- gramming prac- tices(A) 78. Extreme pro- gramming prac- tices (b) Incremental planning Requirements are recorded on story cards and the stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development 'Tasks'. Small releases The minimal useful set of functionality that provides busi- ness value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. Simple design Enough design is carried out to meet the current require- ments and no more. Test-first development An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. Refactoring All developers are expected to refactor the code continu- ously as soon as possible code improvements are found. This keeps the code simple and maintainable. Pair programming Developers work in pairs, checking each other's work and providing the support to always do a good job. Collective ownership The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything. Continuous integration As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable pace Large amounts of overtime are not considered acceptable as the net effect is often to reduce code quality and medi- um term productivity On-site customer A representative of the end-user of the system (the cus- tomer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for imple- mentation. 79. Requirements scenarios The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates. These are written on cards and the development team break them down into implementation tasks. 80. Examples of refactoring Re-organization of a class hierarchy to remove duplicate code. Tidying up and renaming attributes and methods to make them easier to understand. The replacement of inline code with calls to methods that have been included in a program library. 81. Code Smells Duplicate code Long methods Big classes 82. XP testing diffi- culties 83. The Scrum ap- proach is 84. There are three phases in Scrum. Big switch statements Long navigations (e.g., a.b().c().d()) Lots of checking for null objects Data classes (classes that have mainly fields/properties and little or no methods) Un-encapsulated fields (public member variables) Incomplete tests Do not check for all possible exceptions that may occur. Some tests can be very difficult to write incrementally. It is difficult to judge the completeness of a set of tests. a general agile method but its focus is on managing itera- tive development rather than specific agile practices. The initial phase is an outline planning phase where you establish the general objectives for the project and design the software architecture. This is followed by a series of sprint cycles, where each cycle develops an increment of the system. The project closure phase wraps up the project, completes required documentation such as system help frames and user manuals and assesses the lessons learned from the project. 85. The Sprint cycle Once these are agreed, the team organize themselves to develop the software. During this stage the team is isolated from the customer and the organization, with all communications channelled through the so-called 'Scrum master'. 86. UML: Unified Modeling Lan- guage 87. Types of UML Di- agrams The role of the Scrum master is to protect the development team from external distractions. At the end of the sprint, the work done is reviewed and presented to stakeholders. The next sprint cycle then be- gins. An industry-standard graphical language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling. The UML uses mostly graphical notations to express the OO analysis and design of software projects. Simplifies the complex process of software design Use Case Diagram: capture requirements. Clarify exactly what the system is supposed to do Displays the relationship among actors and use cases. Different from traditional flow chart. Class Diagram: static relationships between classes. Describe the types of objects in the system and various kinds of static relationships that exist among them. Sequence Diagram: Displays the time sequence of the objects participating in the interaction. Collaboration Diagram Displays an interaction organized around the objects and their links to one another. State Diagram Displays the sequences of states that an object of an inter- action goes through during its life in response to received stimuli, together with its responses and actions. Component Diagram Illustrate the organizations and dependencies of the phys- 88. Use Case Dia- gram(core com- ponents) ical components in a system. A higher level than class diagrams. Actors: A role that a user plays with respect to the sys- tem,including human users and other systems. e.g.,inani- mate physical objects (e.g. robot); an external system that needs some information from the current system. Use case: A set of scenarios that describing an interaction between a user and a system. System boundary: a rectangle diagram representing the boundary between the actors and the system. Association: communication between an actor and a use case; represented by a solid line. Generalization: relationship between one general use case and one specific use case. Represented by a line with a triangular arrow head toward the parent use case, the more general modeling element. Include: a dotted line labeled <> beginning at base use case and ending with an arrows pointing to the include use case. An "Include" relationship is used to indicate that a particular Use Case must include another use case to perform its function Extend: a dotted line labeled <> with an arrow toward the base case. The extending use case may add behavior to the base use case. The base class declares "extension points". 89. Class Diagram Each class is represented by a rectangle subdivided into three compartments Name Attributes 90. Aggregation vs. Composition Operations Modifiers are used to indicate visibility of attributes and operations. '+' is used to denote Public visibility (everyone) '#' is used to denote Protected visibility (friends and de- rived) '-' is used to denote Private visibility (no one) By default, attributes are hidden and operations are visi- ble. The last two compartments may be omitted to simplify the class diagrams Composition is really a strong form of aggregation components have only one owner components cannot exist independent of their owner; both have coincident lifetimes components live or die with their owner e.g. (1)Each car has an engine that can not be shared with other cars. (2) If the polygon is destroyed, so are the points. Aggregations may form "part of" the aggregate, but may not be essential to it. They may also exist independent of the aggregate. Less rigorous than a composition. e.g. (1)Apples may exist independent of the bag. (2)An order is made up of several products, but the products are still there even if an order is cancelled. [Show Less]