1. CS310 Software Engineering Lecturer 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