Cost and effort are low at the beginning, peak during the execution of the work, and fall back quickly toward the end of the project

Risk and uncertainty are greatest at the beginning of the project and gradually decrease throughout the life cycle of the project as decisions are made and deliverables are accepted

Impact of variables that change over project time

The waterfall model is a classic software life cycle model

The waterfall model divides software development into several stages: feasibility analysis (planning), requirements analysis, software design (outline design, detailed design), coding (including unit testing), testing, operation and maintenance, etc.

There is sequence and dependency between stages: the input of the next stage can only be started after the work of the previous stage is completed.

Using this input, what should be done to implement the activity

The work success of this activity is given and passed as output to the next development activity.

Review the results of the implementation of this activity

Develop software at a relatively small expense

Quality is guaranteed at every development stage, reducing rework

Meticulous documentation reduces communication costs and helps early detection of problems

Inability to resolve issues where software requirements are unclear or inaccurate

Risks are often not revealed until later in the development phase, and opportunities for early correction are lost.

Since it is a single process, lessons learned during development cannot be fed back into the process of applying this product.

Usually projects with very clear user needs

Small scale, simple requirements, single function project

Software development projects with clear requirements and relaxed time requirements

The user has certain abilities and the expression of needs is accurate

The spiral model is an evolutionary software process model that combines the iterative characteristics of prototype implementation with the controlled and systematic aspects of linear sequential (waterfall) models

Enables rapid development of incremental versions of software

In the spiral model, software development is a series of incremental releases

The development process has a recurring spiral shape

Formulate plans: Set software goals, select implementation plans, and clarify project development constraints;

Risk analysis: analyze the selected options and consider how to identify and eliminate risks;

Implementation engineering: Implement software development (requirements, design, coding, testing, etc. are promoted in a spiral cycle)

Customer evaluation: Evaluate the development results of this round, propose corrections, and plan the next round of work.

The emphasis on alternatives and constraints is conducive to the reuse of existing software and also helps to regard software quality as an important goal of software development.

Reduced over-testing or under-testing

There is no essential difference between maintenance and development

The cost of risk management is too high. In risk analysis, high requirements are placed on project team members.

Risk-driven, pay attention to risks, decide whether to continue the project after risk analysis

The spiral model emphasizes risk analysis and is especially suitable for large and complex systems with unclear requirements and high risks.

The core workflow describes the static components of the iterative model from a technical perspective, including: business modeling, requirements elicitation, analysis and design, implementation, testing, and deployment

In an iterative process, each phase includes a different proportion of all activities

iterative model

The iterative model on the diagram, with the time dimension in the horizontal direction, describes the entire software development life cycle from the perspective of organizational management.

It is divided into four stages: initialization, refinement, construction, and handover, which can be further described as cycle, phase, and iteration.

The core workflow describes the static components of the iterative model from a technical perspective, including: business modeling, requirements elicitation, analysis and design, implementation, testing, and deployment

The shaded area in the figure depicts different workflows with different workloads in different time periods. Almost all workflows have workloads in all time periods, but the size is different.

Initial phase: systematically elaborate the scope of the project, select a feasible system architecture, plan and prepare the business case

Elaboration stage: refine the idea, refine the process and infrastructure, refine the architecture and select components

Construction phase: resource management, control and process optimization, complete the development of components and test them according to the evaluation criteria, and evaluate the release of the product according to the acceptance criteria of the concept

Handover phase: synchronize and integrate concurrent construction increments into a consistent implementation baseline, implementation-related engineering activities (commercial packaging and production, personnel training, etc.), evaluate the implementation baseline against the acceptance criteria of the complete vision and requirements set

Suitable for software development with unclear and difficult requirements

V model

The V model consists of left and right sides. It is a symmetrical structure that clearly indicates the different levels that exist in the testing process.

And very clearly describes the correspondence between these testing phases and development phases.

Unit testing: Verifies whether the software unit executes correctly according to the unit specifications (detailed design instructions) to ensure that each smallest unit can run normally, usually performed by developers

Integration testing: Checks whether multiple units work together as described in the system outline design. The main focus of integration testing is that the system can be compiled successfully, the main business functions can be realized, and the data between the various modules of the system can communicate normally, etc.

System testing: Verify that the entire system meets the requirements specifications

Acceptance testing: Checking whether the system meets the requirements defined in the contract or user needs from the user's perspective

The main idea embodied in the V model is that development and testing are equally important. The left side represents development activities, while the right side represents testing activities.

The V model has a test level corresponding to each development stage.

Testing is still a stage in the development life cycle. Unlike the waterfall model, there are multiple testing levels corresponding to the development stages.

The V model is used when requirements are clear and requirements change infrequently.

Inability to resolve issues where software requirements are unclear or inaccurate

Poor flexibility, relying on early demand surveys and unable to adapt to changes in demand

Requirements and technologies are fully identified and understood

prototyping model

The first step in prototyping the model is to create a rapid prototype that satisfies project stakeholders and future users to interact with the prototype.

Then, through full discussion and analysis with relevant stakeholders, we finally figure out the needs of the current system. After a full understanding, we develop a product that satisfies users based on the prototype.

In the actual project process, with the help of organizational process assets and rapid model software, some simple prototypes can usually be established during demand analysis.

It does not require a comprehensive and detailed investigation and analysis of the system, but is based on the developer's preliminary understanding of user needs.

First quickly develop a prototype system, and then implement the user's final system requirements through repeated modifications

Practical and feasible

Has the basic characteristics of the final system

Convenient, fast and low-cost construction

The characteristic of the prototype method is that the prototype method dynamically responds to user needs and gradually incorporates them. System analysis, design and implementation are all completed simultaneously with the continuous modification of a working model. There are no obvious boundaries between them. No clear division of labor

System development plan is a process of repeated modifications

throwaway prototype

Evolutionary prototype

Customers can propose general goals, but cannot specify detailed input, processing, and output requirements; or developers cannot determine the effectiveness of algorithms, the adaptability of operating systems, and the form of human-computer interaction.

The user defines a set of general goals but cannot identify detailed input, processing, and output requirements;

Developers may not be sure of the effectiveness of algorithms, the suitability of operating systems, or the form of human-computer interaction.

It combines the basic components of the waterfall model with the iterative characteristics of prototypes. Use a linear sequence that staggers as schedule time progresses.

Analyze, design, code, test and release software products as a series of incremental building blocks

The first stage increment is often the core product

Each phase increment is a releaseable version, and early increments are "detachable" versions of the final product.

Since the initial increment is the basis for subsequent increments, if the requirements of the initial increment are to be modified, it may affect subsequent increments.

Too many increments will cause management cost overruns and affect progress.

The personnel allocation is flexible, so there is no need to invest a lot of human resources in the beginning. When the core product is very popular, more manpower can be added to achieve the next stage of increment. People can work in parallel at the same time.

Parts with clear requirements can be implemented in stages, gradually optimizing system requirements and gradually integrating system elements.

Phased delivery provides a way to launch the core product first when the staff cannot complete the product within the set deadline or when customer/market requirements are urgent. In this way, partial functions are delivered to customers in stages, which acts as a sedative to customers. role.

Suitable for software projects with gradually clear requirements

The product can be divided into different stages and completed separately.