CEN 4021 Software Engineering II

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

2. Acknowledgements • Dr. Onyeka Ezenwoye • Dr. Peter Clarke • Dr. Betty Cheng • Dr. Bernd Bruegge • Dr. Allen Dutoit

3. 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. The software process • A structured set of activities required to develop a software system • Specification; • Design; • Validation; • Evolution. • A software process model is an abstractrepresentation of a process. It presents a description of a process from some particular perspective.

5. Abstraction • Elimination of unnecessary detail • Model • Abstract view • Abstract representation

6. Software Process model • A software process model is an abstractrepresentation 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. 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. 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. Software Process Models • Waterfall • V • Spiral • Rapid Application Development

10. Waterfall model

11. 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. 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. Project and Requirements Planning Production Operation and Maintenance Product Requirements and Specification Analysis System and Acceptance Testing Architecture or High-Level Design Integration and Testing Detailed Design Unit Testing Coding V-Shaped Model

14. 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. 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. 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. 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. 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. 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. Phases in the V-Shaped Model • Productions, operation and maintenance • Puts software into production and provides for enhancements and corrections.

21. 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. 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. Spiral model of the software process Determine objectives, alternatives and constraints Evaluate alternatives, identify, resolve risks Operational prototype requirements And test plan Plan next phase Develop, verify next-level product

24. 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. 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. 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. RAD Model User Involvement Development Effort Construction User Description Requirements Planning Cut Over Time

28. 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. 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. 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. 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. Generic activities • Specification • Design (and implementation) • Validation • Evolution

33. 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. example requirements engineering process

35. 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. example design process activities • Architectural design • Abstract specification • Interface design • Component design • Data structure design • Algorithm design

37. example software design process

38. 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. 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. Testing phases note that model is V

41. 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. Example evolution process