Software Engineering process models Hamza Mohammed Naji 120090117

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

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

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.

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

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

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

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

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

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

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

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

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

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

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)

Spiral model

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

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

Use of the Models in Practice

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