1. Software Engineering process models
Hamza Mohammed Naji

2. What Is a Software Engineering Process?
It can be very difficult to explain what a process is, if people aren’t already familiar with it. An informal example most people can relate to is the process of balancing a checkbook at the end of the month. Most of us have developed a process we use - the same steps every month. It shortens the time required to accomplish the task and ensures that we don’t forget any steps. The same applies to a software engineering process. We want it to be repeatable and ensure that all required tasks are accomplished when required. Of course, a software engineering process is much more complex than balancing a checkbook and there is a tremendous amount of information contained in the RUP.
A process defines Who is doing What, When and How in the development of a software system
Roles and workflows
Work products
Milestones
Guideline …
The UML is a generic modeling language. With UML, you can produce blueprints for any kind of software system.
The Rational Unified Process (RUP) is a generic process that uses UML as a modeling language. RUP can be used for any kind of software system.
New or changed
requirements
system
Software Engineering
Process

3. Process & Product Process model Tools People Project Product
Automation
Tools
Template
Participants
People
Project
Result
Product

4. An Effective Process ...
This is a good opportunity to contrast the RUP with old-fashioned processes. RUP is meant to be used on a daily basis. It is relevant because it is integrated with the tools the developer is using. It is easy to access since it is on the desktop.
Emphasize that the process contains far more information than any one person can remember. It is not intended that they learn it all at once. The best approach is to first get an overview so that they understand how it is organized and where to look for things. Then access the online process to learn the details of each task as they need to perform the task.
Provides guidelines for efficient development of quality software
Reduces risk and increases predictability
Captures and presents best practices
Learn from other’s experiences
Mentor on your desktop
Extension of training material
Promotes common vision and culture
Provides roadmap for applying tools
Delivers information on-line, at your finger tips
The focus of the process is the production of high-quality executables with a minimum of overhead, rather than what documents to produce.
By providing a “written-down”, very detailed set of procedures for developing software according to Rational’s six best practices, the process is easier to apply and repeatable. This results in software projects that are more predicable and successful.
Another feature of the Rational Unified Process is that it is not just theory. It instructs the developer on how to implement the activities using the tools the developer is using.
Finally, the process is available on-line as a Website. While hardcopy books have their place, most developers prefer to reference the process from their desktops when they need help. Both hardcopy and on-line versions are available.

5. Lightweight vs. Heavyweight Processes
e.g., V-Process
Customizable
Framework
e.g., Rational
Unified
Process (RUP)
Agile (Lightweight)
e.g., eXtreme
Programming (XP)
Document driven
Elaborate workflow definitions
Many different roles
Many checkpoints
High management overhead
Highly bureaucratic
Focus on working code
rather than documentation
Focus on direct communication
(between developers and
between developers and the customer)
Low management overhead

6. Process choice
Process used should depend on type of product which is being developed
For large systems, management is usually the principal problem so you need a strictly managed process. For smaller systems, more informality is possible.
High costs may be incurred if you force an inappropriate process on a development team

7. Build and Fix Model Properties Advantage Disadvantage
No planning or analysis
The working program is the only workproduct
Advantage
Appropriate for small programs written by one person
Disadvantage
Understandability and maintainability decrease rapidly with increasing program size
Totally unsatisfactory
Need a life-cycle model
“Game plan”
Phases
Milestones

8. Waterfall Model Characterized by Advantages Disadvantages
Sequential steps (phases)
Feedback loops (between two phases in development)
Documentation-driven
Advantages
Documentation
Maintenance easier
Disadvantages
Complete and frozen specification document up-front often not feasible in practice
Customer involvement in the first phase only
Sequential and complete execution of phases often not desirable
Process difficult to control
The product becomes available very late in the process

9. Rapid Prototyping Model
Rapid prototyping phase followed by waterfall
Do not turn the rapid prototype into the product
Rapid prototyping may replace the specification phase—never the design phase
Comparison:
Waterfall model—try to get it right the first time
Rapid prototyping—frequent change, then discard

10. Advantages and Disadvantages
Requirements better specified and validated
Early feasibility analysis
Strong involvement of the customer in the prototyping phase
Disadvantage
Higher development effort
Danger that due to schedule slip, the prototype becomes part of the product

11. Incremental Release 1 Design Coding Test Deployment Release 2
Requirements
Design
Coding
Test
Deployment
Release 3
Design
Coding
Test
Deployment

12. Incremental Model (contd)
Waterfall, rapid prototyping models
Operational quality complete product at end
Incremental model
Operational quality portion of product within weeks
Less traumatic
Smaller capital outlay, rapid return on investment

13. Evolutionary Version 1 Design Coding Test Deployment Requirements
Feedback
Design
Coding
Test
Deployment
Requirements

14. Evolutionary Model (contd)
Advantages
Constant customer involvement and validation
Allows for good risk management
Disadvantages
Build-and-fix danger
Contradiction in terms

15. Spiral model
Waterfall model plus risk analysis preceding each phase and evaluation following each phase
Prototyping for high-risk specifications
Radial dimension: cumulative cost to date
Angular dimension: progress through the spiral
If all risks cannot be resolved, the project is immediately terminated
Appropriate only for big projects (high management overhead)

16. Spiral model

17. Process model risk problems
Waterfall
High risk for new systems because of specification and design problems
Low risk for well-understood developments using familiar technology
Prototyping
Low risk for new applications because specification and program stay in step
High risk because of lack of process visibility
Evolutionary and Spiral
Middle ground between waterfall and prototyping

18. Hybrid process models
Large systems are usually made up of several sub-systems
The same process model need not be used for all subsystems
Prototyping for high-risk specifications
Waterfall model for well-understood developments
Taylor the process to a problem

19. Use of the Models in Practice

20. Process improvement The fundamental problem with software
The software process is badly managed
Understanding existing processes
Introducing process changes to achieve organisational objectives which are usually focused on quality improvement, cost reduction and schedule acceleration