Software Engineering C h a p t e r 2 Software Process Dr. Doaa Sami Modified from Sommerville’s originals

Objectives  To introduce software process models 2  To introduce software process models  Waterfall, iterative and spiral model.  To describe process activities  To explain the Rational Unified Process  An example of a modern software process.

Video Tutorials Software Engineering Process Models Reasons for Agile Processes Spiral Model

SOFTWARE-DEVELOPMENT LIFE-CYCLE The software-development life-cycle is used to facilitate the development of a large software product in a systematic, well-defined, and cost- effective way

MAINTENANCE Maintenance is an important part of the SDLC Maintenance may consume more time than the time consumed in the development The cost of maintenance varies from 50% to 80% of the total development cost

TYPES OF MAINTENANCE 1. Corrective Maintenance: Corrective maintenance means repairing processing failures or making changes because of previously uncorrected problems 2. Adaptive Maintenance: Adaptive maintenance means changing the program function. This is done to adapt to the external environment change

TYPES OF MAINTENANCE 3. Perfective Maintenance: Perfective maintenance means enhancing the performance or modifying the programs to respond to the user’s additional or changing needs

TYPES OF MAINTENANCE 4. Preventive Maintenance: Preventive maintenance is the process by which we prevent our system from being obsolete It involves the concept of re-engineering and reverse engineering in which an old system with an old technology is re-engineered using new technology

Ad Hoc Software Development 3 3  Developing software without planning for each phase, and without specifying tasks, deliverables, or time constraints.  Relies entirely on the skills and experience of the individuals performing the work.  The software process may change as work progresses.

Overcome Problems of Ad Hoc Development 4  Problems (include But not limited to):  Difficult to distinguish between tasks  important tasks may be ignored.  Inconsistent schedules, budgets, functionality, and product quality.  Delayed problem discovery  more costly to fix. Solution? Software Process Model “ an abstract representation of a process. It presents a description of a process from some particular perspective.”  Software Process Models provide guidelines to organize how software process activities should be performed and in what order.

Plan-driven and Agile Processes 5  Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan.  In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements.  In practice, most practical processes include elements of both plan-driven and agile approaches.  There are no right or wrong software processes.

Software Process Models 6  Waterfall Model  Separate and distinct phases of specification and development.  Iterative Model  Specification, development and validation are interleaved.  Reuse-oriented Software Engineering  The system is assembled from existing components.  Which software process model is best?  Depends on the project circumstances and requirements  In practice, most large systems are developed using a process that incorporates elements from all of these models.

Waterfall Model Phases 7 Requirements definitions System and software design Implementation and unit testing Integration and system testing Operation and maintenance

Waterfall Model  There are separate phases in the waterfall model: 8  There are separate phases in the waterfall model:  Requirements analysis and definition  System and software design  Implementation and unit testing  Integration and system testing  Operation and maintenance  Waterfall Model Description  Sequential (linear) design process  Flow steadily downwards  One phase has to be completed before moving onto the next phase.

Waterfall Model Advantages 9  It has a clear structure which makes it easy to use.  It is appropriate when the requirements are well- understood and changes will be fairly limited during the design process.  It is mostly used for large systems engineering projects where a system is developed at several sites.

Waterfall Model Disadvantages 10  The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway  No prototypes are used. It is difficult for customers to described all requirements explicitly.  Requires customer patience because a working version of the program doesn't occur until the final phase.  Few business systems have stable requirements.

Software prototyping A prototype is an initial version of a system used to demonstrate concepts and try out design options. A prototype can be used in: The requirements engineering process to help with requirements elicitation and validation; In design processes to explore options and develop a UI design; In the testing process to run back-to-back tests. Chapter 2 Software Processes

Benefits of prototyping Improved system usability. A closer match to users’ real needs. Improved design quality. Improved maintainability. Reduced development effort. Chapter 2 Software Processes

The process of prototype development Chapter 2 Software Processes

Prototype development May be based on rapid prototyping languages or tools May involve leaving out functionality Prototype should focus on areas of the product that are not well-understood; Error checking and recovery may not be included in the prototype; Focus on functional rather than non-functional requirements such as reliability and security Chapter 2 Software Processes

Iterative Model iteration where earlier stages are reworked is always 11  System requirements ALWAYS evolve. Process iteration where earlier stages are reworked is always part of the process for large systems.  Iteration can be applied to any of the generic process models.  Three (related) approaches  Incremental delivery.  Spiral development.  Agile development.

Incremental Delivery Description 12  The Incremental Model = Linear Sequential Model (waterfall) + the iterative philosophy.  When an Incremental Model is used, the first increment is often the “core product”.  The subsequent iterations are the supporting functionalities or the add-on features that a customer would like to see.  The model is designed, implemented and tested as a series of incremental builds until the product is finished.

Incremental Delivery Description Cont. 13  Each increment cycle  delivers part of the functionality.  Provides a needed set of functionalities sooner while delivering optional components later.  User requirements have to be prioritized .  Requirements with highest priority are included in early increments.  Freezing requirements for each increment (no changing in requirement once a specific increment started).

Incremental Delivery 14 Define outline Assign Design system Develop system requirements increment Architecture increment System incomplete? Validate Integrate Validate Deploy increment increment system increment System complete? Final Increment 1: Analysis Design  Develop  Test  integrate  test (Delivery of 1st Increments). Normally ''Core Product“ Increment 2:Analysis Design  Develop  Test  integrate  test (Delivery of 2nd Increments) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Increment n: Analysis Design  Develop  Test  integrate  test (Delivery of nth Increments) requirement to

Incremental development Chapter 2 Software Processes

Incremental Delivery Advantages 15  Customer don’t need to wait until the entire system deliver.  Give customer some opportunities to delay some decisions.  Lower risk of overall project failure.  The highest priority system services tend to receive the most testing.

Incremental Delivery Disadvantages 16  Most systems require a set of basic facilities that are used by different parts of the system. Difficult to identify common requirements between increments.  Increments should be relatively small and still deliver some functionality.  Might be difficult to map customer requirements into increments.  High level requirements may not be sufficient to define system architecture.

Spiral Model 17  Process is represented as a spiral rather than as a sequence of activities.  Using the Spiral Model, the software is developed in a series of incremental releases.  Unlike the incremental Model, where in the first product is a core product, in the Spiral Model the early iterations could result in a paper model or a prototype.  Risks are explicitly assessed and resolved throughout the process.  It is favored for large, expensive, and complicated models.

Spiral Model of The Software Process 18

Spiral Model Sectors  Objective setting 19  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.  Planning  The project is reviewed and the next phase of the spiral is planned.

Spiral Model Advantages 20  Estimates of the budget and schedule become more realistic as work progresses because of the questions that have been raised.  Easier to cope with the changes inherent to software development.  Software engineers can start working on the project earlier rather than wading through a lengthy early design process.

Spiral Model Disadvantages 21  Estimating the budget and time are harder to be judged at the beginning of the project since the requirements evolve through the process.  Requires considerable expertise in risk assessment.  Requires more time, and is more expensive.

The concurrent engineering model Software Engineering Software Processes Software Engineering

The concurrent engineering model It explicitly accounts for the divide and conquer principle. Each team works on its own component, typically following a spiral or evolutionary approach. There has to be some initial planning, and periodic integration. Software Engineering Software Processes Software Engineering

Risks 22  Risk driven process model  What is risk?  Example risks:  Different risk patterns can lead to choosing different process models  What is risk?  Situations or possible events that may cause a project to fail to meet its goal.  Example risks:  Experienced staff leave the project.  Hardware which is essential for the system will not be delivered on schedule.

Reuse-oriented Software Development 23  It also called Component Based Software Engineering (CBSE).  Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-Off-The- Shelf) systems.  Process stages  Component analysis;  Requirements modification;  System design with reuse;  Development and integration.  This approach is becoming increasingly used as component standards have emerged.

Reuse-oriented software engineering Chapter 2 Software Processes

CBSE Advantages and Disadvantages 24  Advantages  Reduce amount of software to be developed.  Reduce costs and risks.  Faster delivery.  Disadvantages:  Requirements compromises, system does not meet real needs of users.  Control over system evolution is lost.

Evolutionary development Develop an initial implementation prototype Client test drive … feed back Refine prototype  2 types of Evolutionary development Exploratory development Throw-away prototyping Software Engineering Software Processes

Evolutionary development Software Engineering Software Processes Software Engineering

Evolutionary development 2 types of Evolutionary development Exploratory development Objective is to work with customers, explore their requirements and to evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer. Throw-away prototyping Objective is to understand the system requirements and outline abetter definition of requirements. Should start with poorly understood requirements to clarify what is really needed. Software Engineering Software Processes Software Engineering

TIME BOXING PROCESS MODEL To speed up development, parallelism between the different iterations can be employed A new iteration commences before the system produced by the current iteration is released, and hence development of a new release happens in parallel with the development of the current release

TIME-BOXING PROCESS MODEL .

TIME-BOXING PROCESS MODEL In the time boxing model, the basic unit of development is a time box, which is of fixed duration Since the duration is fixed, a key factor in selecting the requirements to be built in a time box is what can be fit into the time box This is in contrast to regular iterative approaches where the functionality is selected and then the time to deliver is determined

TIME-BOXING PROCESS MODEL Each time box is divided into a sequence of stages The model requires that the duration of each stage is approximately the same Having time-boxed iterations with stages of equal duration and having dedicated teams renders itself to pipelining of different iterations

TIME-BOXING PROCESS MODEL To illustrate the use of this model, consider a time box consisting of three stages: requirement specification, build, and deployment The requirement stage is executed by its team of analysts and ends with a prioritized list of requirements to be built in this iteration along with a high-level design

TIME-BOXING PROCESS MODEL The build team develops the code for implementing the requirements, and performs the testing The tested code is then handed over to the deployment team, which performs pre-deployment tests, and then installs the system for use These three stages can be done in approximately equal time in an iteration

TIME-BOXING PROCESS MODEL Timeboxing is well suited for projects that require a large number of features to be developed in a short time around a stable architecture using stable technologies These features should be such that there is some flexibility in grouping them for building a meaningful system in an iteration that provides value to the users

TIME-BOXING PROCESS MODEL The main cost of this model is the increased complexity of project management (and managing the products being developed) as multiple developments are concurrently active Also, the impact of unusual situations in an iteration can be quite disruptive

TIME-BOXING PROCESS MODEL Tasks of Different Teams

V PROCESS MODEL .

V PROCESS MODEL The V model is a variant of the waterfall model It represents a tacit recognition that there are testing activities occurring throughout the waterfall software life cycle model and not just during the software testing period

V PROCESS MODEL For example, during requirements specification, the requirements are evaluated for testability and an STRS may be written This document would describe the strategy necessary for testing the requirements

V PROCESS MODEL Testing is a full life-cycle activity and that it is important to constantly consider the testability of any software requirement and to design to allow for such testability

Process Activities 25  The four basic process activities are organized differently in different development processes:  Software Specification.  Software Development (design + implementation).  Validation.  Evolution.

Software Specification 26  The process of establishing what services required and constraints on the system’s operation and development.  Requirements engineering process:  Feasibility study  Cheap and quick.  Requirements elicitation and analysis  This document is derived by observation of existing one, task analysis, talk to customer.  Requirements specification  Defining requirements in detail.  Requirements validation  Checking the validity of the requirements.

Requirements Engineering Process 27

Software Design and Implementation 28  The process of converting system specification into an executable system.  Software design  Design a software structure that realises the specification;  Implementation  Translate this structure into an executable program;  The activities of design and implementation are closely related and may be inter-leaved.

Design Activities  Architectural design,  Interface design: 29  Architectural design,  where you identify the overall structure of the system.  Interface design:  where you define the interfaces between system components.  Component design:  where you take each system component and design how it will operate.  Database design:  where you design the system data structures and how these are to be represented in a database.

General Model of The Design Process 30

Programming and Debugging 31  Translating a design into a program and removing errors from that program.  Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process.  Testing Differ Than Debugging?  How!!  Debugging (locating defects and correcting).  Testing (establish existing of defects).

The debugging process Software Engineering Software Processes 44 Software Engineering Software Processes Software Engineering

Software Validation system testing. 32  Verification and Validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the customer.  Involves checking and review processes and system testing.  System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system.  Validation ensures that ‘you built the right thing’.  Verification ensures that ‘you built it right’.

Defect Distribution in SW Life Cycle Software Engineering Software Processes Software Engineering Software Processes

Testing Stages 33

Testing stages  Component (Unit) Testing  System Testing 34  Component (Unit) Testing  Individual components are tested independently;  Components may be functions or objects or coherent groupings of these entities.  System Testing  System components are integrated to create a complete system.  Testing of the system as a whole.

potential customer who report any problems to the developer. Testing Stages Cont. 35  Acceptance Testing  Testing with customer data to check that the system meets the customer’s needs.  Alpha Testing: Continues till the system developer and the client agree that the system is acceptable.  Usually applicable for bespoke/Custom systems.  Beta Testing: Involves delivering a system to a number of potential customer who report any problems to the developer.  Usually applicable for generic software.

Testing phases in a plan-driven software process Chapter 2 Software Processes

Software Evolution  Software is inherently flexible and can change. 36  Software is inherently flexible and can change.  As requirements change through changing business circumstances, the software that supports the business must also evolve and change.  Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new.

Software Evolution 37

The Rational Unified Process (RUP) 38  A modern process derived from the work on UML and associated Unified Software Development Process.  UML: Unified Model Language: is an industry standard language allows us to clearly communicate requirements, architectures and designs.  RUP is a phased model that identifies four discrete phase in a software process.

Different Perspectives of RUP 39  RUP normally described from 3 perspectives:  Dynamic perspective: Shows phases over time.  Static perspective Shows process activities.  Practice perspective Suggests good practices to be used.

Phases in the Rational Unified Process 40

Inception Phase 41  The goal of this phase is to:  Establish the business case for the system by:  Identify all external entities with which the system will interact (actors) and define the nature of this interaction.  Assess the contribution that system makes to the business.  If this contribution is minor, the project may be cancelled after this phase.

 On completion of this phase we should have: Elaboration Phase 42  The goals of this phase are to:  Develop an understanding of the problem domain.  Establish an architectural framework for the system.  Develop the project plan and identify the key project risks.  On completion of this phase we should have: Requirement model for the system. Development plan for the software.

 On completion of this phase we should have: Construction Phase 43  The goals of this phase are to:  System design, programming and testing.  Parts of the system are developed in parallel and integrating during this phase.  On completion of this phase we should have: Working software system. Associated documentation. The system is ready for delivery to the users.

 On completion of this phase we should have: Transition Phase 44  The final phase is concerned with moving the system from development community to user community and making it work in a real environment.  This phase is ignored in most models, but it is expensive and sometimes problematic activity.  On completion of this phase we should have: Documented software system that is working correctly in its operational environment.

SOFTWARE STANDARDS ISO  International Organization for Standardization ACM  Association for Computing Machinery IEEE  Institute of Electrical and Electronics Engineers DOD  The U.S. Department of Defence

Summery a software system. Software process models are abstract 48  Software processes are the activities involved in producing a software system. Software process models are abstract representations of these processes.  General process models describe the organization of software processes. Examples of these general models include the ‘waterfall’ model, iterative development, and reuse-oriented development.  Processes may be structured for iterative development and delivery so that changes may be made without disrupting the system as a whole Requirements engineering is the process of developing a software specification.

Summary transforming a requirements specification into an  Design and implementation processes are concerned with transforming a requirements specification into an executable software system.  Software validation is the process of checking that the system conforms to its specification and that it meets the real needs of the users of the system.  Software evolution takes place when you change existing software systems to meet new requirements.  RUP is a modern generic process model that involves four phases (inception, elaboration, construction and transition).  CASE tools are software systems which are designed to support routine activities in the software process. 49

Thank you End of Chapter 2