1. Chapter 2 Software Development Model and 1

2. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided software engineering 2

3. software process vs software process model A software development process, also known as a software development life cycle (SDLC), is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. I A software process model is a simplified description of a software process which is presented from a particular perspective. Software process model is an abstraction of the actual process which is being described. Process models may include activities which are part of the software process, software products and the roles of people involved in software engineering. 3

4. 4 Analysis of project Methodologies Methodologies Comprehensive guidelines to follow for completing every SDLC activity Collection of models, tools, and techniques

5. 5 Relationships Among Components of a Methodology

6. 6 Models Models Representation of an important aspect of real world, but not same as real thing Abstraction used to separate out aspect physical (like a model of an airplane) abstract (e.g. in form of mathematical notation or in graphical form) Models in SDLC are graphical: diagrams and charts Project planning and budgeting aids

7. 7 Some Models Used in SDLC

8. 8 Tools Tools Software support that helps create models or other required project components Range from simple drawing programs to complex CASE tools to project management software

9. 9 Some Tools Used in SDLC

10. 10 Techniques Techniques Collection of guidelines that help analysts complete a system development activity or task Can be step-by-step instructions or just general advice

11. 11 Some Techniques Used in SDLC

12. The software process A structured set of activities required to develop a software system – Specification; – Design; – Validation; – Evolution. A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. 12

13. Generic software process models The waterfall model – Separate and distinct phases of specification and development. Evolutionary development – Specification, development and validation are interleaved. Component-based software engineering – The system is assembled from existing components. There are many variants of these models e.g. formal development where a waterfall-like process is used but the specification is a formal specification that is refined through several stages to an implementable design. 13

14. Waterfall model 14

15. Waterfall model phases Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase. 15

16. Waterfall model problems Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. Few business systems have stable requirements. The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. 16

17. The V-Model (waterfall variation) Is validated by These are building a model of the system These are validating the system V- Model 17

18. V-Shaped Strengths Emphasize planning for verification and validation of the product in early stages of product development Each deliverable must be testable Project management can track progress by milestones Easy to use 18

19. V-Shaped Weaknesses Does not easily handle concurrent events Does not handle iterations or phases Does not easily handle dynamic changes in requirements Does not contain risk analysis activities 19

20. 20 Prototyping model Performs analysis, design and implementation phases concurrently, and all three phases are performed repeatedly in a cycle until the system is completed. The first prototype is shown to the users and the project sponsor, who provide comments, which are used to re-analyze, re-design, and re- implement a second prototype that provides a few more features This process continues in a cycle until the analysts, users and sponsor agree that the prototype provides enough functionality to be installed and used. Refinement occurs until it is accepted as the new system.

21. 21 Prototyping SDLC

22. 22 Prototyping model: pros and cons The key advantages: Very quickly provides a system for users to interact with. It reassures the users that the project team is working on the system. The users can interact with the prototype to better understanding what it can and cannot do rather than attempting to understand a system specification on paper. The major disadvantages: Fast-paced system releases challenge attempts to conduct careful, methodical analysis. Often the prototype undergoes such significant changes that many initial design decisions become poor ones. This can cause problems in the development of complex systems because fundamental issues and problems are not recognized until well into the development process.

23. Spiral Model (Boehm 1987) “ Waterfall with iteration and risk management”? Note: This is an example of how the spiral model might work Spiral Model 23

24. Spiral Model Determine objectives, alternatives, constraints Evaluate alternatives, identify and resolve risks Develop & verify next level product Plan Next Phase 24

25. Spiral Model The spiral model an iterative model with the following activities – Determine objectives and constraints – Evaluate Alternatives – Identify risks – Resolve risks – Develop a series of prototypes for the identified risks starting with the highest risk. – Use a waterfall model for each prototype development (“cycle”) – If a risk has successfully been resolved, evaluate the results of the “cycle” and plan the next round – If a certain risk cannot be resolved satisfactorily, terminate the project 25

26. Spiral Model Strengths Provides early indication of insurmountable risks, without much cost Users see the system early because of rapid prototyping tools Critical high-risk functions are developed first The design does not have to be perfect Users can be closely tied to all lifecycle steps Early and frequent feedback from users Cumulative costs assessed frequently 26

27. Spiral Model Weaknesses Time spent for evaluating risks too large for small or low-risk projects Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive The model is complex Risk assessment expertise is required Spiral may continue indefinitely Developers must be reassigned during non-development phase activities May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration 27

28. When to use Spiral Model When creation of a prototype is appropriate When costs and risk evaluation is important For medium to high-risk projects Users are unsure of their needs Requirements are complex New product line Significant changes are expected (research and exploration) 28

29. Incremental Development Model Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. User requirements are prioritised and the highest priority requirements are included in early increments. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve. 29

30. Incremental development 30

31. Incremental development advantages Customer value can be delivered with each increment so system functionality is available earlier. Early increments act as a prototype to help elicit requirements for later increments. Lower risk of overall project failure. The highest priority system services tend to receive the most testing. 31

32. Process iteration System requirements ALWAYS evolve in the course of a project so 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 Two (related) approaches – Incremental development – Spiral development 32

33. Incremental & iterative - summary Iterative model - This model iterates requirements, design, build and test phases again and again for each requirement and builds up a system iteratively till the system is completely build. Incremental model - It is non integrated development model. This model divides work in chunks and one team can work on many chunks. It is more flexible. Spiral model - This model uses series of prototypes in stages, the development ends when the prototypes are developed into functional system. It is flexible model and used for large and complicated projects. Evolutionary model - It is more customer focused model. In this model the software is divided in small units which is delivered earlier to the customers. V-Model - It is more focused on testing. For every phase some testing activity are done. 33

34. Operational Specification Model Requirements are executed (examined) and their implication evaluated early in the development process Functionality and the design are allowed to be merged 34

35. Transformational Model 35

36. Phased Development: Increments and Iterations Shorter cycle time System delivered in pieces – enables customers to have some functionality while the rest is being developed Allows two systems functioning in parallel – the production system (release n): currently being used – the development system (release n+1): the next version 36

37. Phased Development: Increments and Iterations 37

38. Phased Development: Increments and Iterations Incremental development: starts with small functional subsystem and adds functionality with each new release Iterative development: starts with full system, then changes functionality of each subsystem with each new release 38

39. Phased Development: Increments and Iterations Phased development is desirable for several reasons – Training can begin early, even though some functions are missing – Markets can be created early for functionality that has never before been offered – Frequent releases allow developers to fix unanticipated problems globaly and quickly – The development team can focus on different areas of expertise with different releases 39