Iterative Software Development Technology
1. Problems with traditional development processes
The traditional software development process is a document-driven process, which divides the entire software development process into several phases in sequence. Each stage must complete all the specified tasks (documents) before entering the next stage. If you must complete all the System Requirement Specification specifications before entering the outline design stage, coding must be completed after the system design is complete. This means that system integration is performed only after all system modules are developed. For a complex system composed of hundreds of modules, this is a very arduous and long task.
As the software projects we develop become more and more complex, the traditional waterfall development process constantly exposes the following problems: errors in requirements or design are often discovered only in the later stages of the project, for example: after the system is delivered to the customer, it is found that the original understanding of the requirements is wrong, and the problems in the system design can only be found at the test stage.
The project risk control capability is weak. The project risk can be really reduced when the project development is late. It is often determined whether the design can truly meet the system requirements after the system test.
Software projects are often delayed or development costs exceed the budget. Project development progress is often disrupted by unexpected problems, and rework or other additional development cycles are required, this may result in project delays or overspending.
Project Management Personnel focus on the completion and review of documents to estimate the progress of the project. Therefore, the project manager's estimation of the project status is often inaccurate, when he answered that the system has completed 80% of the development tasks, the remaining 20% of the development tasks actually consume 80% of the development resources of the entire project.
In the traditional waterfall model, problems in requirements and design cannot be detected in the early stage of project development. Only when the system is integrated for the first time, these design defects are exposed during testing, resulting in a series of rework: re-design, coding, and testing, resulting in project delays and increased development costs. 2. Control Project risks using iterative development
To solve problems in the traditional software development process, we recommend that you use iterative development methods to replace the waterfall model. In the waterfall model, what we need to accomplish is the overall goal of software system development. In the iterative method, we divide the development goals of the entire project into some small goals that are easier to accomplish and achieve. These small targets all have a clearly defined stage evaluation standard. Iteration is a series of development activities to achieve certain stage goals. Before each iteration starts, an iteration plan should be formulated based on the current state of the project and the stage objectives to be achieved, the entire iteration process includes various types of development activities, such as requirements, design, implementation (coding), deployment, and testing. After the iteration is complete, the results of the iteration must be evaluated, then, the goal of the next iteration is determined based on this. Compared with the traditional waterfall development model, iterative development has the following features: allowed change requirements
Requirements always change. This is a fact. The major challenges to projects are demand changes and demand "creep", which may lead to delayed delivery, delay in construction, customer dissatisfaction, and developer frustration. By presenting some of the system functions generated by iterations to users, we can collect user feedback on the system as early as possible and correct the misunderstanding of user requirements in a timely manner, this ensures that the developed system truly solves the customer's problems.
Gradually integrate elements
In traditional project development, because all modules in the system need to be integrated at once, the integration phase usually accounts for a large proportion of the work of the entire project (up to 40% ), work at this stage is often uncertain and tricky. In iterative methods, integration can be said to be continuous. Each iteration will incrementally integrate some new system functions, and the elements to be integrated are much less than in the past, therefore, the workload and difficulty are relatively low.
Reduce risks as soon as possible
The main guiding principle of iterative development is to take the architecture as the center. The main problem to be solved in the early iterations is to determine the system architecture as soon as possible, through several iterations, we can quickly design a system architecture that can meet core requirements, which can quickly reduce the risks of the entire project. After the system architecture is stable, the risks of the project will be relatively low. At this time, the unfinished functions in the system will be implemented to complete the entire project.
Helps improve team morale
Developers can see their work results in a short period of time through each iteration, which helps them enhance their confidence and better complete development tasks. In non-iterative development, developers can only see the development results when the project is nearing the end. For a long time before this, we are still exploring the future in uncertainty.
Generate high-quality products
Each iteration generates a runable system. By testing this runable system, we can detect and correct defects in an early iteration, performance bottlenecks can also be discovered and processed as soon as possible. Because errors are always corrected in each iteration, We can get higher quality products.
Ensure project development progress
At the end of each iteration, an evaluation is performed to determine whether the iteration has reached the expected goal. The Project Manager can clearly know what needs have been fulfilled, accurately estimate the project status, and make necessary adjustments to the project development progress to ensure that the project is completed on time.
Allow product tactical changes
Iterative development provides greater flexibility. During the iteration process, you can adjust product development according to business conditions or market environment at any time. For example, in order to compete with existing similar products, you can decide to use the method of one step ahead of competitors to release a product with simplified functions in advance.
The iterative process itself can be improved and refined in the process.
The evaluation at the end of an iteration should not only examine the project situation from the perspective of products and progress, but also analyze what the Organization and process have to be improved, in order to better complete the task in the next iteration. The iterative method mainly solves risk control problems. It can be seen that the risks of the system in the traditional development process should go to the later stage of project development (mainly in the test phase) can be truly reduced. The risks in iterative development can be solved as soon as possible through several iterations in the early stages of project development. Once a problem occurs in an early iteration, for example, if an iteration fails to fulfill the predefined goal, we can adjust the development progress in time to ensure that the project is completed on time. Generally, in the later stage of project development (risk control phase), most of the high-risk factors (such as requirements, architecture, and performance) have been solved, at this time, you only need to invest more resources to meet the remaining requirements. Project development at this stage is highly controllable, so that we can deliver a high-quality software system on time. Iterative development is not an advanced software engineering theory. It provides an effective mechanism for controlling project risks. In our daily work, we often apply this basic idea. For a very large project, we often divide it into several phases for implementation, in this way, we can break down complicated problems into small problems that are relatively easy to solve, and we can see the effects of some systems in a short period of time, by exposing problems as early as possible, we can help us adjust our development resources as early as possible, enhance the project progress's controllability, and ensure that the project is completed on time. 3. Manage iterative software projects
When we practice iterative thinking in practical work, Rational Unified Development Process (Rational Unified Process) can provide us with practical guidance. RUP is a general software process framework. It is an architecture-centric, case-driven iterative software development process. It is summarized from the practical experience of thousands of software projects. It has a strong guiding significance for actual projects and is a de facto industrial standard in the software development industry. 3.1 four phases of Software Development
In RUP, we divide the software development lifecycle into four stages. The end sign of each stage is a major milestone (as shown in ). These four phases aim to achieve the following milestones: Inception: Determine the project development objectives and scope
Elaboration: determine the system architecture and clarify the requirements
Construction: implement the remaining system functions
Productization: completes software productization and transfers the system to the customer
Every target milestone is a business decision point. For example, after the start stage is over, we need to determine whether the project is feasible and whether to continue with the project. Each stage is determined by milestones. The mark of determining whether a stage ends is to check whether the current state of the project meets the conditions set in the monument. From this phase division model, we can see that the main risks of the project are concentrated in the first two stages. After several iterations in the finalization phase, we need to establish a stable architecture for the system. When more system requirements are met, we no longer need to modify the architecture. At the same time, in the refinement stage, we continuously collect user demand feedback through iteration, so that the system needs must be gradually clarified and complete. 3.2 allocation of development resources
Based on the risk-driven iterative development model of RUP, we only need to invest a small amount of resources in the project's initial stage to conduct some exploratory research on the project's development prospects and business feasibility. In the finalization stage, we have invested more R & D efforts to achieve some core architecture-related requirements and gradually build the system architecture. After the two phases are over, some major risks and problems of the project have been solved, and then the entire team will be fully engaged in system development. In the product stage, all the major development tasks have been completed. The project no longer needs to maintain a large-scale development team, and the development resources can also be reduced. Shows how to allocate development resources during the project development cycle. This arrangement can make full and effective use of the company's development resources to ease the software company's increasing demand for human resources, thus reducing costs. On the other hand, due to the high risk of the first two phases (initial and precise), we only invest some resources. Once rework or project objectives change, we can also minimize the waste of resources. In the traditional software development process, the allocation of development resources basically runs through the entire project cycle, and resources are often not fully and effectively used. Based on this resource allocation mode, the relationship between the project progress and the completed workload may be shown in the following table. Advanced and refined construction of productization
Workload ~ 5% 20% 65% 10%
Progress 10% 30% 50% 10% 3.3 iteration strategy
There are usually four typical policy modes for the arrangement of iteration plans: Incremental (incremental)
This mode features a low risk of the Project architecture (usually repetitive projects), so only one iteration is required in the finalization phase. However, the development workload of the Project is large, and the construction phase requires multiple iterations. Each iteration adds some system functions based on the previous iteration, gradually implement the functions of the entire system through iteration.
Evolutionary)
When the project architecture is highly risky (similar projects have never been developed), the system architecture needs to be established through multiple iterations in the Refinement phase. The architecture is explored through multiple iterations, gradually evolved. When the architecture is built, the system functions are often basically implemented, so the build phase only needs one iteration.
Incremental Delivery)
This mode features many iterations in the productization phase. A common example is that the project is not difficult, but the business needs are constantly changing, therefore, it is necessary to continuously deploy the completed system through iteration. At the same time, it is necessary to continuously collect user feedback to improve the system requirements and supplement these requirements through subsequent iterations. The application of this policy requires that the system architecture be very stable and can meet the requirements of subsequent changes in demand.
Grand Design)
The traditional waterfall model can be seen as a special case of iterative development. The entire development process only has one iteration. However, this pattern has an inherent weakness. Due to its poor risk control capability, it often produces some additional iterations in the productization phase, resulting in project delays.
These iteration strategies are only representative of some typical modes. They should be applied flexibly in actual application based on actual conditions. The most common iteration plan is usually a combination of these modes. 3.4 develop a project development plan
In the iterative development model, the Project Development Plan is also refined, adjusted and improved as the project progresses. The traditional project development plan is developed in the early stage of the project, and the Project Manager always tries to develop a very detailed and complete development plan at the beginning of the project. On the contrary, the iterative development model assumes that only a rough development plan needs to be developed in the early stage of the project, because the project status is constantly changing as the project progresses, the project manager must adjust the project plan at any time based on the iteration results, and formulate a detailed plan for the next iteration. In RUP, we divide the project development plan into the following three parts: Project Plan
Determine the development objectives and schedule of the entire project, including the start and end time periods of each stage.
Phase plan
The current stage contains several iterations, including the target and schedule for each iteration.
Iteration plan
Detailed development plans for the current iteration, including development activities and Allocation of related resources.
The project development plan fully embodies the idea of iteration. In each iteration, the Project Manager constantly adjusts and refines the project development plan based on the project situation. An Iteration plan is developed based on the previous iteration result evaluation. If the previous iteration reaches the predefined goal, the current iteration only needs to solve the remaining problems; if some problems remain unsolved in the last iteration, the current iteration needs to continue to solve these problems. Therefore, it must be noted that iterations cannot overlap, that is, when you have not completed the current iteration, you must not enter the next iteration, because the next iteration plan is based on the results of the current iteration.
