1.  2004 by SEC Chapter 2 Software Development Process Models

2. 2  2004 by SEC Table of Contents 2.1Introduction to Software Processes 2.2Software Development Process Models 2.2.1 Waterfall Model 2.2.2 Incremental Model 2.2.3 Prototyping Model 2.2.4 Spiral Model 2.2.5 Fourth-Generation Techniques (4GT) 2.2.6 Rational Unified Process (RUP) Model 2.3Comparison of Software Development Process Models Exercises

3.  2004 by SEC 2.1Introduction to Software Processes

4. 4  2004 by SEC Software Processes l Software activities are tasks in a project to develop a software system. l A software process is a structured set of software activities in a project. –A linear sequence of activities: analysis, design, coding, testing, training, maintenance l A software activity might be a software process, too.

5. 5  2004 by SEC Software Activities l Requirement acquisition l Requirement analysis l Requirement specification l System analysis l System design

6. 6  2004 by SEC Software Activities (cont’d) l Detailed design l Coding l Testing l Maintenance

7. 7  2004 by SEC Requirement Acquisition l problem statements –to describe the problem to be solved and providing a conceptual overview of the proposed system

8. 8  2004 by SEC Requirement Analysis l A process of discovering, refinement, modeling and specification. –Principles: represent information domain of a problem –Modeling: (graphical & textual description) l modeling methods: SA, OOA, JSD, DSSD, SADT l model component: information, function, behavior –Artifact l Requirement specification. –capturing: functionality, behavior, and structure

9. 9  2004 by SEC Design l The problem is decomposed into modules l The interface between modules must be specified l Define architecture l Artifact: design model –Data design: data abstraction, data structure, data modeling –Procedural design: iteration, conditional, sequence –Architectural design: program structure, software architecture

10. 10  2004 by SEC Implementation l Individual module programming –pseudo-code  computer programs l The goals –the development of well-documented programs –reliable, easy to read, flexible, correct programs l Integration of modules l Artifact: executable programs

11. 11  2004 by SEC Testing l Test the system from requirement engineering to implementation –Verification and Validation (V&V) l Artifact: testing report

12. 12  2004 by SEC Maintenance l Maintain user satisfaction –Repair errors, requirements changed or extended l Changes are inevitable in both the system environment and user requirements. –Maintenance = Evolution

13. 13  2004 by SEC Maintenance (cont’d) l 4 kinds of maintenance activities –Corrective –Adaptive –Perfective –Preventive The Impact of Changes Cost

14.  2004 by SEC 2.2Software Development Process Models

15. 15  2004 by SEC Software Development Process Models l Also “Software Life Cycle Models” –Waterfall model –Incremental model –Prototyping –Spiral model –Fourth-generation techniques (4GT) –Rational Unify process (RUP) model

16. 16  2004 by SEC Waterfall Model l The waterfall model is defined with a sequence of activities. l An activity starts after the previous activity is fully completed. l This model is documentation-centric.

17. 17  2004 by SEC Waterfall Model (cont’d)

18. 18  2004 by SEC Waterfall Model (cont’d) l This model implicitly requires a corresponding verification with each activity. l This model is best applied to projects whose requirements and implementation are well understood. –However, it is difficult to define all requirements at the beginning of a project. l This model does not address the adaptation to changes.

19. 19  2004 by SEC Waterfall Model (cont’d) l A working version of the system is not seen until late in the project’s life cycle. l Real projects are rarely sequential. l This model is frequently for software implemented with functional decomposition.

20. 20  2004 by SEC Incremental Model l The incremental model uses the waterfall model to develop software systems through incremental releases that provide improved versions of a system at regular intervals. l User requirements are prioritized and the highest priority requirements are included in early increments.

21. 21  2004 by SEC Incremental Model (cont’d) version 1 version 2 version 3 the highest priority requirements Cycle 1 Cycle 2 Cycle 3 lower priority requirements the lowest priority requirements

22. 22  2004 by SEC Incremental Model (cont’d) l This model can produce a working version of the system earlier in the project’s life cycle. l This model can reduce the risk of the project. l Early increments can help elicit requirements for later increments.

23. 23  2004 by SEC l The prototyping model rapidly builds prototypes that provide a reduced functionality or a limited performance version of the system. l The model gives more emphasis on the requirement activity of a project. –Prototypes can be used to clarify requirements rapidly. Prototyping Model

24. 24  2004 by SEC System Implementation Determine Requirements Construct Prototype Demonstrate Prototype Requirements Adjustments Prototype OK Prototyping Model (cont’d)

25. 25  2004 by SEC l The roles of prototyping –as the means to acquire and validate users requirements. –as scaled-down version of the final operational system. –as the means to validate solution specifications. –as a solution specification for design and implementation l Benefits : –improve communication –reduce risk –most feasible way to validate specification –for maintenance as well. Prototyping Model (cont’d)

26. 26  2004 by SEC l Strategies: –Throwaway prototyping: l The objective is to understand the user requirements. l Starts with poorly understood requirements l implement only aspects poorly understood –Evolutionary prototyping: l The objective is to work with customers and to evolve a final system from the prototype. l Should start with well-understood requirements l more likely to implement aspects better understood Prototyping Model (cont’d)

27. 27  2004 by SEC Spiral Model l The spiral model combines the features of the previous three models and adds risk assessment as a new feature. l Risks are explicitly assessed and resolved throughout the process.

28. 28  2004 by SEC Progress through steps Cumulative cost Determine objectives, alternative, constraints Risk analy -sis Prototype Risk analysis Risk analysis Risk analysis 123 Prototype Operational Prototype Simulations, models, benchmarks Detailed design Code Unit test Integration and test Acceptance test Service Design validation and verification Software product design Software requirement Requirement validation Development plan Integration and test plan Plan next phases Develop, verify next-level product Evaluate alternatives identify, resolve risks Requirements plan life-cycle plan Review Commitment partition Spiral Model (cont’d)

29. 29  2004 by SEC Steps in Spiral Model l 4 steps in a cycle (loop): –Objectives: identify specific objectives and devise alternative approaches –Risk assessment: assess risks based on alternatives, resolve risks, and decide which process model to use. –Development and validation: develop the system –Planning: review the system and plan the next phase l Each cycle represents a phase in this model.

30. 30  2004 by SEC 4GT l Use diagrams or some specific languages as input to describe the characteristics and behavior of the software. –The input is called 4 th -generation language (4GL) l With the input, automatically generate source code. –The techniques used are called 4th-generation Techniques (4GT).

31. 31  2004 by SEC Requirements gathering Design strategy implementation using 4GL Testing 4GT (cont’d)

32. 32  2004 by SEC RUP Model l The Rational Unified Process (RUP) model is –Use-case driven l Drive the design, implementation, and validation of the system l Use case model is for requirement analysis. –Architecture-centric l An architecture describes the entire system that is divided into parts and their interactions. l The architecture can be used to decide which parts need to be developed and which parts can be built by reusing the existing software components.

33. 33  2004 by SEC RUP (cont’d) –Iterative and incremental l See the figure. l The model repeats over a series of cycles. –A cycle consists of 4 phases: inception, elaboration, construction, transition. Each phase has iterations. l Incremental: Incrementally add something new, such as functions, components and subsystems, to the system. l Design and documentation use UML.

34. 34  2004 by SEC RUP (cont’d)

35. 35  2004 by SEC RUP (cont’d) l Inception: Specify the most critical use cases and build a outline architecture. l Elaboration: Specify most of the use cases and build a system architecture. l Construction: Build the system. l Transition: Move into beta release, train customer personnel, provide help-line assistance.

36.  2004 by SEC 2.3Comparison of Software Development Process Models

37. 37  2004 by SEC l Waterfall model problems –traceability/different languages in different phases –Process is too linear l requirement acquisition and validation –maintainability : difficult due to the use of functional decomposition –assume fully elaborated documentation at the early stage of the life cycle. l reusability : top-down design l communication: Waterfall Model

38. 38  2004 by SEC –based on functional decomposition l Strongly dependent on detailed functional breakdown l not consider evolutionary changes. l not encourage reusability Waterfall Model (cont’d)

39. 39  2004 by SEC l Prototyping (partial implementation ) –Benefits l improve communication –reduce risk –communication between developments –determine a proposed design’s unknown properties –address requirement acquisition and validation limitation –provide a basis for assessing the feasibility and performance of alternative designs –most feasible way to validate specification. –for maintenance as well Prototyping Model

40. 40  2004 by SEC –Limitation l quick and direct approach without considering issues such as quality and maintainability. Prototyping Model (cont’d)

41. 41  2004 by SEC Languages Used in Different Phases l Prototyping language: both specification and design l Specification language: abstract of system functionality l Design language: abstract of system structure l Programming language: optimization

42. 42  2004 by SEC verify correctness and completeness of design or implementation interconnections during architecture and module design containing quantifies prototyping lang. specification language Design language executable supporting formal reasoning low priority detail algorithm and data structure no yes not necessary must no yes not programming language efficient Languages Used in Different Phases (cont’d)

43. 43  2004 by SEC longevity t0t1t2t3t4t5 Functionality Time inappropriateness lateness shortfall slop : adaptability original reqt. A B D C E waterfall model O : (t 0 ) original reqt. A : ( at t1) an operational product, not satisfying the old to needs because poor understanding of needs. A - B : undergo a series of enhancements. B - D : the cost of enhancements increase, to build a new system. stop at t4. * cycle repeat itself Waterfall Model

44. 44  2004 by SEC before understanding of the user`s need => increase in functionality t0t1t2t4 Functionality Time Throwaway Prototyping and Spiral Model

45. 45  2004 by SEC Time t0t1t2t4 Functionality Evolutionary Prototyping

46. 46  2004 by SEC t0t1t2t4 Functionality Time user Reusable Software approach conventional approach Reusable Software versus Conventional

47. 47  2004 by SEC l Do you think “complexity”and “change”is the problems of software development? Why? l Comparison of different software engineering paradigms : l waterfall, prototyping, spiral, OOLC, 4GL –prototype : both specification and design –program : optimization Exercises

48. 48  2004 by SEC l Issues in using different kinds of language in waterfall model l different phases need different kinds of languages l transformation between languages at different phases. l main features of each language –specification, design, prototype, program –specification : abstract of system functionality –design : abstract of system structure –prototype : both specification and design –program : optimization Exercises (cont’d)