CS310 Software Engineering Lecturer Dr.Doaa Sami

1. CS310 Software EngineeringLecturer Dr.Doaa Sami Software Process Models

2. Objectives • To introduce software process models • To describe three generic process models

3. The Software Process • A structured set of activities required to develop a software system • Specification – defining what the system should do; • Design and implementation – defining the organization of the system and implementing the system; • Validation – checking that it does what the customer wants; • Evolution – changing the system in response to changing customer needs

4. Major problems in software development The developers understood it in that way The requirements specification was defined like this This is how the problem is solved now This is how the problem was solved before. This is how the program is described by marketing department This, in fact, is what the customer wanted … ;-) That is the program after debugging

5. What is a Software Process Model? • A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. • Workflow perspective represents inputs, outputs and dependencies • Data-flow perspective represents data transformation activities • Role/action perspective represents the roles/activities of the people involved in software process

6. Generic software process models • The waterfall model • Separate and distinct phases of specification and development. • Incremental (Evolutionary) development • Specification, development and validation are interleaved. • Formal systems development • A mathematical system model is formally transformed to an implementation (we will not study this in detail) • Reuse-based/Component-based software engineering • The system is assembled from existing components In practice, most large systems are developed using a process that incorporates elements from all of these models

7. Waterfall Model • In a waterfall model, each phase must be completed in its entirety before the next phase can begin  • At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project

8. Waterfall Model

9. Waterfall Model • Requirements Analysis and Definition • The system's services, constraints and goals are established by consultation with system users. They are then defined in a manner that is understandable by both users and development staff • System and Software Design • System design: Partition the requirements to hardware or software systems. Establishes an overall system architecture • Software design: Represent the software system functions in a form that can be transformed into one or more executable programs • Unified Modeling Language (UML)

10. Waterfall Model • Implementation and Unit Testing • The software design is realized as a set of programs or program units. (Written specifically, acquired from elsewhere, or modified) • Individual components are tested against specifications • Integration and System Testing • The individual program units are: • integrated and tested as a complete system • tested against the requirements as specified • delivered to the client

11. Waterfall Model • Operation and Maintenance • Operation: The system is put into practical use • Maintenance: Errors and problems are identified and fixed • Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment • Phase out: The system is withdrawn from service

12. Advantages of the Waterfall Model • Well-structured engineering process • Easy to use and understand • Every phase produces some document • Easy to manage due to the rigidity of the model • each phase has specific deliverables and a review process • Phases are processed and completed one at a time • Works well for smaller projects where requirements are very well understood and changes will be rare

13. Disadvantages of the Waterfall Model • The main drawback is the difficulty of accommodating change after the process is underway • In principle, a phase has to be complete before moving onto the next phase • Each stage in the process reveals new understanding of the previous stages, that requires the earlier stages to be revised • Backtracking and overlapping of activities are usually required • Waterfall model takes a static view of requirements • Ignore changing needs • Lack of user involvement once specification is written • Late feedback from the customer

14. Disadvantages of the Waterfall Model • No working software(code) is produced until late during the life cycle • Most analysis (testing) is done on program code • Hence, problems not detected until late in the process • Poor model for complex and object-oriented projects • Poor model for long and ongoing projects

15. Extended Waterfall Model (with backtracking) CS310 Software Engineering

16. Incremental (Evolutionary) Development • Concept: Develop an initial implementation, expose this to user comment and refine this through many versions till an adequate system has been developed CS310 Software Engineering

17. Incremental (Evolutionary) Development • Each increment or version incorporates some of the functionality needed by the customer • Early increments include the most important or most urgently required functionality • Customer can evaluate the system at a relatively early stage if it delivers the required functionality • If not, only the current increment has to be changed and new functionality defined for later increments

18. Incremental development benefits • The cost of accommodating changing customer requirements is reduced. • The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model. • It is easier to get customer feedback on the development work that has been done. • Customers can comment on demonstrations of the software and see how much has been implemented. • More rapid delivery and deployment of useful software to the customer is possible. • Customers are able to use and gain value from the software earlier than is possible with a waterfall process.

19. Incremental development problems • The process is not visible. • Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system. • System structure tends to degrade as new increments are added. • Regular change tends to corrupt the structure. Incorporating further software changes becomes increasingly difficult and costly.

20. Applicability of Incremental Development • For small (less than 100,000 lines of code) or medium-size (up to 500,000 lines of code) interactive systems; • For parts of large systems (e.g. the user interface); • For short-lifetime systems

21. Component-based/Reuse-oriented Software Engineering • Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. • Main characteristics: • Makes intensive use of existing reusable components • The focus is on integrating the components rather than on creating them from the scratch • This approach is becoming increasingly used as component standards have emerged

22. Component-based Software Engineering • Process stages • Component analysis – search for available components that match specification • Requirements modification – modify requirements to reflect available components • System design with reuse – design the system to incorporate available components and design new components if needed • Development and integration – internally produced software and commercially available software are integrated to create the new system

23. Component-based Software Engineering • Advantages: • Reduces considerably the software to be developed “in-house” • Allows faster delivery • In principle, more reliable systems, due to using previously tested components • Disadvantages • Lack of required Components • Component Maintenance Costs • Reliability and Sensitivity to changes • Unsatisfied Requirements • Trust

24. Recommended Reading • Relevant topics from Chapter 2 of the textbook