Chapter 2 Intro to SE(SW Process Models.pptx)
- 1. Software Development Approaches and Process Models Chapter 2: Software development approaches and process models
- 2. What is software development process? • A structured set of activities required to develop a software. • Many different software processes, but ALL involve: Specification Development (Design and implementation) Validation Evolution
- 3. Plan-driven VS Agile development approach VS DevOps approach • Plan-driven approach, is a practice where ALL development activities planned in advance and progress is measured against that plan. • Agile approach (continuous delivery), is a practice where planning incrementally achieved and easier to change the process to reflect changing customer requirements. • DevOps approach (continuous deployment), is a practice that aims at merging development, quality assurance, and operations (deployment and integration) into a single, continuous set of processes. This methodology is a natural extension of Agile and continuous delivery approaches.
- 7. In practice, no right or wrong software development approach
- 8. Software development process models • The classic development process model Plan-driven approach. Separate and distinct phases of specification and development. • Evolutionary development process model Specification, development and validation are interleaved. Could be agile or DevOps. • Reuse-oriented development process model The system is assembled from existing reusable components, rather than developing them from scratch. May be plan-driven or agile. In practice, most large systems are developed using a process that incorporates elements from ALL of these models.
- 9. Classic development process model
- 10. Limitations of the classic development process model • In practice, requirements are changed frequently. • Never go back to previous phase to fix errors or problems. • The customer can not use the software UNTIL the entire system is complete. • The model implies that once the software is completed, everything else is maintenance cost.
- 11. When the classic development process model is appropriate to use? • Requirements must be well- understood and identified. • No changes in requirements during the development process. • Large scale software projects where a software project is developed at several sites.
- 12. Evolutionary development process models • Based on developing an initial implementation, exposing this to user’s comments and refining it through many versions until an adequate software is developed. • Specification, development and validation activities are interleaved with rapid feedback across activities
- 13. Types of evolutionary development process model Incremental development approach: This approach works with the customer to explore their requirements and deliver a final software step by step. The development starts with the requirements of the software that are well-understood. Prototyping development approach: This approach emphasizes on experimenting with the customer requirements that are poorly understood. The development follows proof of concept method.
- 14. Limitations of the incremental development process model • Lack of process visibility. • Software is usually poorly structured. • Special skills (e.g. technical skills) may be required for rapid prototyping.
- 15. When the incremental development process model is appropriate to use? • Small to medium size software projects. • NOT enough staffing is available for the whole software project. • Parts of a large-scale project (e.g. user interfaces) • Short-lifetime software projects.
- 16. Limitations of the prototyping development process model • Project may expand beyond the original plans. • Cost factor since it may take several iterations for defining software requirements. • Designing prototypes sometimes quick rather than quality
- 17. When the prototyping development process model is appropriate to use? • When the customer has poor information about the software. • When the software project needs to have a lot of interaction with end users. • Web user interfaces. • High technology software projects.
- 18. Rapid Application Development (RAD) Model • It makes heavy use of reusable software components with an extremely short development cycle (60-90) days.
- 19. Limitations of the RAD development process model • Requires sufficient human resources, particularly for large scale projects. • Projects committed in a much- shortened time-frame. • Problematic if system can not be modularized. • Not appropriate when technical risks are high (heavy use of new technology).
- 20. When the RAD development process model is appropriate to use? • If software requirements are well understood and project time is constrained.
- 21. Spiral development process model • Process is represented as a spiral rather than as a sequence of activities with backtracking. • Each loop in the spiral model represents a phase in the development process model. • 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. 21
- 22. Limitations of the spiral development process model • It is difficult to convince customers (particularly in contract situations) that the model is controllable. • Risk assessment expertise is required to succeed. 22
- 23. When the spiral development process model is appropriate to use? • Good for large and critical- mission software projects. • When the risk and costs evaluation is important. • Additional functionality can be added at a later date. • When requirements are unclear and complex.
- 24. Reuse-oriented development process model • Software systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. • Reuse is now the standard approach for building many types of business system.
- 25. The Rational unified development process model (RUP) • RUP is a generic process derived from the work on the UML and associated process. • Brings together aspects of the 3 generic process models discussed previously. • Normally described from 3 perspectives A dynamic perspective that shows phases over time; A static perspective that shows process activities; A proactive perspective that suggests good practice. 25
- 26. Phases in the rational unified development process model 26
- 27. RUP good practice • Develop software iteratively Plan increments based on customer priorities and deliver highest priority increments first. • Manage requirements Explicitly document customer requirements and keep track of changes to these requirements. • Use component-based architectures Organize the system architecture as a set of reusable components. 27
- 28. RUP good practice • Visually model software Use graphical UML models to present static and dynamic views of the software. • Verify software quality Ensure that the software meets organizational quality standards. • Control changes to software Manage software changes using a change management system and configuration management tools. 28
Editor's Notes
- #24: COTS are stand-alone software systems that are configured for use in a particular environment. Reused components could be collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE.
- #26: Inception: defines the scope and budget of the project and develop business case. Elaboration: Plan project, specify features, assessing risks and baseline the architecture. Construction: Build the product. Transition: the final project phase which delivers the new system to its end-users.