1. CEN 4021 2 nd Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi http://www.cs.fiu.edu/~sadjadi/ sadjadi@cs.fiu.edu Software Process Models

2. 2 nd LectureCEN 4021: Software Engineering II Acknowledgements  Dr. Onyeka Ezenwoye  Dr. Peter Clarke  Dr. Betty Cheng  Dr. Bernd Bruegge  Dr. Allen Dutoit 2

3. 2 nd LectureCEN 4021: Software Engineering II Objectives  To understand –Software process and process models, including the main characteristics of each model, critical software process issues, and the pros and cons of each model. –The generic process activities and what they mean. This includes details of what exactly each activity is for and the stages within them.

4. 2 nd LectureCEN 4021: Software Engineering II 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.

5. 2 nd LectureCEN 4021: Software Engineering II Abstraction  Elimination of unnecessary detail  Model  Abstract view  Abstract representation

6. 2 nd LectureCEN 4021: Software Engineering II Software Process model  A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.  No universal software process  Highly intellectual  Must dynamically adjust to creative needs of professionals and tasks

7. 2 nd LectureCEN 4021: Software Engineering II Critical Software Process Issues  Factors to consider –Nature of the project.  Software projects are different. –Organizational needs. –Experience level of members/team –Current product status  E.g., Brand new product? –Available tools and facilities

8. 2 nd LectureCEN 4021: Software Engineering II Critical Software Process Issues  Factors to consider –Quality  More intensive quality assurance –Product Technology  New technology or algorithm? –Requirements instability  Unknown requirements  Unstable requirements –Complexity  Large systems

9. 2 nd LectureCEN 4021: Software Engineering II Software Process Models  Waterfall  V  Spiral  Rapid Application Development

10. 2 nd LectureCEN 4021: Software Engineering II Waterfall model

11. 2 nd LectureCEN 4021: Software Engineering II 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.

12. 2 nd LectureCEN 4021: Software Engineering II 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.  Requirements have to be understood early on.

13. 2 nd LectureCEN 4021: Software Engineering II V-Shaped Model Project and Requirement s Planning Product Requirements and Specification Analysis Architecture or High-Level Design Detailed Design Unit Testing Integration and Testing System and Acceptance Testing Coding Production Operation and Maintenance

14. 2 nd LectureCEN 4021: Software Engineering II V-Shaped Model  A variation of the Waterfall model.  Places strong emphasis on Verification and Validation.  Testing of the product is planned in the early phases of the process.  Acceptance test plan is developed.  System test plan is developed.

15. 2 nd LectureCEN 4021: Software Engineering II V-Shaped Model  Emphasizes the relationship between the phases preceding and following coding.  The dotted lines indicate that these phases should be considered in parallel.

16. 2 nd LectureCEN 4021: Software Engineering II Phases in the V-Shaped Model  Project and requirements planning –Determines system requirements and allocation of resources.  Product requirements and specification analysis –Analysis of software problem, concludes with complete specification of the software.

17. 2 nd LectureCEN 4021: Software Engineering II Phases in the V-Shaped Model  Architecture or High-level design –Determines how the software functions are to implement the design.  Detailed Design –Defines algorithms for components that were defined during the architecture phase.

18. 2 nd LectureCEN 4021: Software Engineering II Phases in the V-Shaped Model  Coding –Transforms the algorithms defined during the design phase into software.  Unit Testing –Checks each code module for errors.

19. 2 nd LectureCEN 4021: Software Engineering II Phases in the V-Shaped Model  Integration and Testing –Integrate and test individual code modules.  System and acceptance testing –Test entire software system in its hardware environment.

20. 2 nd LectureCEN 4021: Software Engineering II Phases in the V-Shaped Model  Productions, operation and maintenance –Puts software into production and provides for enhancements and corrections.

21. 2 nd LectureCEN 4021: Software Engineering II V-Shaped Model Problems  Does not easily handle concurrent events  No iteration of phases  Cannot handle dynamic changes in requirements throughout the life cycle  Requirements are tested too late to make changes without affecting the schedule  No risk analysis

22. 2 nd LectureCEN 4021: Software Engineering II Spiral development  Process is represented as a spiral rather than as a sequence of activities with backtracking.  Each loop in the spiral represents a phase in the process.  No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.  Risks are explicitly assessed and resolved throughout the process.

23. 2 nd LectureCEN 4021: Software Engineering II Spiral model of the software process Determine objectives, alternatives and constraints Evaluate alternatives, identify, resolve risks Develop, verify next-level product Plan next phase And test plan requirements Operational prototype

24. 2 nd LectureCEN 4021: Software Engineering II Spiral model sectors  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.

25. 2 nd LectureCEN 4021: Software Engineering II Spiral Model problems  Highly dependent on risk analysis –Requires very knowledgeable personnel –Errors may occur if risk is not properly analyzed  Willingness of the Customer

26. 2 nd LectureCEN 4021: Software Engineering II RAD Model  Rapid Application Development  User is involved in all phases  Use tools that allow product evaluation at all stages of development  Characterized by quick turnaround time from requirements definition to delivery  High component reuse factor

27. 2 nd LectureCEN 4021: Software Engineering II RAD Model Development Effort Time Requirements Planning User Description Construction Cut Over User Involvement

28. 2 nd LectureCEN 4021: Software Engineering II Phases in RAD Model  Requirements planning phase –Requirements are gathered using technique called joint requirements planning (JRP)  User description –Joint application design (JAP) is used to harness user involvement.

29. 2 nd LectureCEN 4021: Software Engineering II Phases in RAD Model  Construction phase –Combines design, coding, testing. Heavy use of code generators and other production tools  Cut over –Acceptance testing, installation and user training.

30. 2 nd LectureCEN 4021: Software Engineering II Strengths of RAD  Use of powerful tools reduces cycle time  Lower cost due to reduced cycle time  Ongoing customer involvement  Reuse of existing program component

31. 2 nd LectureCEN 4021: Software Engineering II RAD problems  Heavily dependent on user involvement throughout the process.  Requires highly skilled developers in the use of development tools.  Heavily dependent on reusable components.

32. 2 nd LectureCEN 4021: Software Engineering II Generic activities  Specification  Design (and implementation)  Validation  Evolution

33. 2 nd LectureCEN 4021: Software Engineering II Specification  The process of establishing what services are required and the constraints on the system’s operation and development.  Requirements engineering process –Feasibility study; –Requirements elicitation and analysis; –Requirements specification; –Requirements validation.

34. 2 nd LectureCEN 4021: Software Engineering II example requirements engineering process

35. 2 nd LectureCEN 4021: Software Engineering II design and implementation  The process of converting the system specification into an executable system.  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.

36. 2 nd LectureCEN 4021: Software Engineering II example design process activities  Architectural design  Abstract specification  Interface design  Component design  Data structure design  Algorithm design

37. 2 nd LectureCEN 4021: Software Engineering II example software design process

38. 2 nd LectureCEN 4021: Software Engineering II Validation  Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer.  Involves checking and review of processes, various testing stages.  Testing involves executing the system with test cases that are derived from the specification.  Testing tries to establish if observed behaviour matches expected behaviour.

39. 2 nd LectureCEN 4021: Software Engineering II Testing stages  Unit testing –Individual components are tested independently; –Components may be functions or objects or coherent groupings of these entities.  Integration testing (subsystem testing) –Individual components are merged and tested.  System testing –Testing of the system as a whole. Testing of emergent properties is particularly important.  Acceptance testing –Testing with customer data to check that the system meets the customer’s needs.

40. 2 nd LectureCEN 4021: Software Engineering II Testing phases note that model is V

41. 2 nd LectureCEN 4021: Software Engineering II Evolution  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.

42. 2 nd LectureCEN 4021: Software Engineering II Example evolution process