Transition from the waterfall development to iterative development
English original
content:
The four steps of the benefits of iterative development methods Apply these steps to more ways to note about the author's articles
The Rational Zone is also:
All articles online courses
Per Kroll (Pkroll@us.ibm.com) Director, Rational Unified Process, IBM 2004 May
This article comes from Rational EDGE: an ideal iterative development method model has fundamentally different from the ideal waterfall development model. However, from the actual example, there is no team that strictly applies each development method model. This article explains why the development team decided to gradually transform from a similar waterfall type development method into a more similar iterative development, and it also outlines the steps that can help this transformation.
Most software development teams are still using a waterfall development process in the development project. Using extreme waterfall development methods means you have to complete a series of project phases in strict order: demand analysis, design, implementation / integration then test. When problems in the project is difficult and solve the problem is expensive, you may postpone the test until the end of the project cycle; these problems can also threaten the time limit for software and make the main team members in some development links. It is idle. In fact, most development teams use improved waterfall development methods, they break the project into two or more parts, and sometimes these parts are called phase or period. This improvement can help simplify integration, making testers earlier early testing work and provides an earlier project state observation. This method also decomposes the code into a piece of easy management and minimizes the code integration required by the stub and driver. In addition, this approach allows you to prototype you think of risk or have difficulty parts, and use feedback from every stage to modify your design. However, the implementation and imagination of the use of waterfall development methods is the opposite: Many design teams regard the modification design after phase 1 as their original design or demand process failure. Although an improved waterfall development method does not exclude feedback, it does not promote, support and encourage feedback. Finally, you want to minimize the risk, don't typically drive a waterfall development project. For software development, this paper explores the progress of "iterative" development methods surpassing traditional waterfall development methods. The benefits of iterative development are compared, iterative development methods - use IBM Rational Uniform Procedure®, or RUP ® as an example - including a series of increments steps or iterations. Each iteration includes some or many development activities (demand, analysis, design, implementation, etc.), as you can see in Figure 1. Each iteration also has a series of good definition goals and generates part of the final system. Each subsequent iteration is based on the previous iteration to make the system develop and refine until the final product is completed. Early iterations focused on demand, analysis and design; later iterations focused on implementation and testing. Figure 1: Iterative development of RUP. Each iteration includes demand, analysis, design, implementation, and testing activities. At the same time, each iteration is based on the previous iterative work, and each iteration will generate an executable version of the final product. Iterative development methods have proven to be superior to the waterfall development method, the reasons are as follows:
It allows for changes in demand. Demand changes and "further spread" - the accumulation of technologies and customer-driven features - the main cause of trouble, extension delivery, unsatisfactory to customers and disciating developers. In order to solve these problems, teams that use iterative development methods should pay attention to generating and demo executable software in a few weeks of project development, which enforces demand inspections and helps reduce demand to reflect the nature of the system. Integrated is not "big action" in the end of the project. Almost always lead to time consuming rework, which will always lead to time-consuming rework - sometimes spent 40% of the workload of the project. In order to avoid this rework, each iteration ends in each part of the integrated build system; this continuous accumulation will minimize future rework. Early iterations can expose risks. Iterative development methods can help teams reduce risks in early iterations because of these iterations include testing of all process components. When earlier iteration covers many aspects of the project - Tools, purchased software and team members' skills, etc. Revecil that there is no new risks discovered when the cost is resolved. Management of products can take tactical changes. Iterative development can quickly generate an executable architecture (although function is limited), this architecture can make it a "lightweight" or "improved" version to deal with the fast version of the competitor. It makes it easier to reuse. The common part of the partial design and implementation of the identification in iteration is more easier than finding the public part during the plan. The design review in early development allows architects to find potentially reusable opportunities, and use this opportunity to develop mature public code for the next iteration. You can find and correct the defects in every iteration. This will generate a robust architecture and high quality applications. You can even find defects in the early iterations rather than at the end of the project. You can discover it before the performance bottleneck does not destroy your plan. It can better utilize project staff resources. Many development organizations use a pipelined organization to match their waterfall development methods: Analyst will send the required demand to the designer, the designer will be completed to the development programmer, the programmer will again The developed components are sent to integration personnel, and integrators are integrated into testers testing. This multiple times is not only easy to generate errors and the application causes misunderstanding; this approach will also feel that they have little responsibility for the final product. Iterative development process encourages team members to participate in a broader event in all aspects of the project, allowing team members to play a variety of roles. Project managers can better utilize available projects and can eliminate risk-free delivery. Team members can learn along the road road. Developers working in an iterative development project have a lot of opportunities in the software development cycle to learn from their own mistakes and can enhance their skills from an iteration to another iteration. By evaluating each iteration, the project manager can discover the chance of training for team members. Instead, developers working in the waterfall development method are typically limited to narrow technical expertise, and only have the opportunity to work in one of the design, coding or testing. You can improve the development of the process along the project. The assessment of the end of the iterative can not only reveal the status of the project from the product or plan; they can also help the project manager to analyze how to improve the organizational structure and process of the project in the next iteration. Some project managers resist anti-antective development methods, regarding iterative development as an endless, uncontrolled form. However, in RUP, this project is capable of controlling it. The number of iterations, cycle and goals are carefully planned; and the project participants' tasks and roles are well defined. In addition, the objective metric of progress should be available. Although the team has to do something from an iteration to the next iteration, this work is also controlled carefully. The four steps of transformation are divided into the development of work into phases or periods; we can also treat this part as a first step to iterative. However, in order to implement the transition to iterative development methods, we should use the following four steps to apply different process principles:
Build a function prototype as early as possible. Detailed design, implementation, and test phases to different iterations. A executable architecture in the project early baseline. Adopt iterative and risk-driven management processes. Let us further explain each step. Step 1: As soon as possible to build a function prototype as a first step to iterately develop transformation, consider one or more functional prototypes during the demand and design phase. The goal of these prototypes is to reduce the main technical risks and clarify what should be understood by the project. By identifying the most important three technical risks and the most important three feature clarified features begins. Technical risks may be related to new technologies, which are not decided to have many unresolved techniques that have much affected or you know about technical needs. Functional risks may provide fuzzy demand or several demand for project systems. For every important technical risk, to develop what you want prototypes to reduce risks. Consider the following example: Technology Risk: The project needs to be transplanted to the IBM WebSphere Application Server running. Users have begun to complain the performance of the application, and what you are worried is that it may be more slower after transplantation. Prototype: Building a prototype of a architecture to find different methods of transplant your application. Require an expert-level WebSphere architect to help you. Evaluation results and write architectural and design guidelines to provide development teams to do what should be done and should not do. This will increase the performance of your transplantation is good enough to avoid the possibility of rework after the project. Technical risk: You are building a new application for the arrangement and estimation of software projects. You know how to support iterative plans for this key distinguishing between this app and purchased software. However, this is also one of the most blurred parts in your needs. Prototype: Based on your idea to support iterative project plans to build a functional prototype. By presenting the original shape in different projects, you will be able to encourage them to pay more attention to the project's plan, and they can tell you what their idea is for you, which is not agree. The prototype will help you clarify the needs of the plan, and you can provide you with useful information about the user experience and the appearance and feeling of your application. This prototype can even produce some reusable code. Step 2: Detailed design, implementation, and test phases to different iterations. Many project teams have found that it is difficult to divide a project to become a meaningful iteration before they know what the project is really about. However, when you have entered the detailed design phase, what you usually look like and what the system's architecture looks like something looks well. This is the time our test iteration is developed! You can use two main ways to determine what you should do in what iterate. Let us discuss every method from the opposite side. Method 1: Develop one or more subsystems simultaneously. Let us assume that you have nine subsystems, each has a number of increasing components. You can divide the detailed design, implementation, and test phases to three iterations, each iterative aiming to implement three of the nine subsystems. If there is a limited dependency between different subsystems, it will work quite good. For example, if each of your nine subsystems provide a good definition of a good definition, you can develop a priority subsystem in the first iteration, followed by the important subsystem to implement in the second iteration. In this class. This method has a great advantage: If your progress is behind, you can still deliver some of the most important part of the system.
However, if you have a hierarchical architecture, this method will not work well in the capabilities of the underlying subsystem. If you have to build a subsystem within a time, such an architecture will force you to build the underlying subsystem and build a subsystem increasingly superior. However, in order to build the correct capabilities of the underlying subsystem, you usually need to make a lot of detailed design and implementation on the upper subsystem, because they determine what you need in the underlying subsystem. This creates "CATCH-22" phenomenon; the second method explains how to solve this problem.
Method 2: First develop the most important scene. If you use method 1, you can only develop a subsystem at a time. Usage 2, you will focus on important scenes or use the key ways of the system, and then add more than that is not the important scene. This is different from ways 1? Let's take an example. Suppose you are building a new application, which will provide users with the ability to manage defects. This is a layered app that is built on WebSphere Application Server using DB2 as the underlying database. In the first iteration, you have developed a series of important scenarios, such as entering a simple defect. In the second iteration, you add complexity to these scenes - for example, you may make the defects can be processed by a workflow. In the third iteration, you provide complete support for atypical users, such as the ability to save the part and return to this entry, and so on.
Using this method, you have completed all subsystems in all iterations, but you still pay attention to the most important scenes in the first iteration, and will not be very important or minimum and difficult scenes staying up. Realization.
If you are working in a well-defined system architecture system, method 1 is more suitable - such as an existing system to enhance or develop new applications using simple architecture. Most Build complex applications should use Method 2, but they should plan iteration in such a way that this method can reduce the range of iterations to compensate for possible time delays. Step 3: Early baseline of the project is an executable architecture. You can think of this step as a method of finishing step 1 (as early as possible). But what is "executable architecture"? The executable architecture is a partial implementation of the system, which is constructed to demonstrate the key functions supported by the architecture. More importantly, it can prove that design can meet the performance, production capacity, capacity reliability, measurable, and other aspects. Building an executable architecture allows you to build all system functionality on a solid foundation in a later stage. This executable architecture is an evolutionary prototype, which maintains the characteristics that have been proven when the system's architecture is mature and guarantees that they are most likely to meet the needs of the system. In other words, these features will be part of the delivery system. This evolutionary prototype covers all aspects of architectural issues compared to the function prototypes you built in step 1. Generating an evolutionary prototype means you want to design, implement and test a frame structure or architecture of a system. At the point of view, the functionality of the system has not been completed, but the interface between most build modules has been implemented, you can (and should be compiled and tested to some extent. Guide the initial load and performance test. This prototype also reflects your key design decision, including technology, main components, and the choice of interface between them. But how will you propose a system architecture for this evolutionary prototype? The key is to focus on the most important percent of 20% to 30 (the system provides a full service provided by the user). Here is some of the most important ways to decide.
The function is the core of the application, or the key interface it uses. The key function of the system should be able to determine the system architecture of the system. Usually, architects identify most important use cases by analyzing many factors: redundant management strategy, resource competition risk, performance risks and data security strategies, etc. For example, in a POS system, check out and payment (PAY) is a critical case because it verifies the interface of the credit card confirmation system - and it is also important from performance and load. Select the use case that describes the function that must be delivered. Delivering applications that do not contain critical features are meaningless. For example, a order input system is unacceptable if the user is not allowed to enter the order. Usually, domain and problem experts can understand key functions required (primary behavior, peak data processing, critical control transactions) from users, and they can help define critical use cases. Select the functionality described in the system architecture and is not used by other critical cases. To ensure that your team can put your attention in all major technical risks, they must understand each area of the system. Even if there is no high risk in a certain field of architecture, it may be hidden technology difficulty, which can only be exposed by some functions in the field of design, implementation and test architecture. The first and last standards listed above are the most concerned about architects; the project manager focuses on the first two. For each critical case, identify the most important scenes and use them to create an executable system architecture. In other words, it is design, implementation, and testing these scenes. Step 4: Adopt iterative and risk-driven management processes. If you will follow steps 2 and step 3 described above, you will be very close to the model of "ideal" iterative development. So, your next step should be to fusion steps 2 and 3, and add a management lifecycle that supports risk drive and iterative development. This is the life cycle of the iterative openings described in RUP. RUP provides a structured approach to iterative development, which divides a project into four phases: initial phase, refinement phase, build phase, and conversion phase. Each stage contains one or more iterations, each iteration focuses on generating the necessary technical deliverables to implement the stage of business goals. The number of iterations that the team experience is the same as the number of targets that need to be achieved, not more. If they don't have successful implementation of these goals in the team's iteration, they must add additional iterations to that stage - and postpone the project. To avoid this happening, you must strictly focus your energy on every stage you need to achieve business objectives. For example, it will be too concentrated in the initial phase to achieve the opposite effect. Below is a brief description of a typical phase objective.
Initial phase: By obtaining a good understanding of the system to build what the system will build by obtaining a high-level understanding and establishment of the system. Reduce most business risks, to build a system to generate business use cases, and obtain confirmation of whether or not to continue the project from all project decision makers. Differential stages: Caring for most of the most technically difficult tasks: design, implementation, testing, and baseline, an executable system architecture, including subsystems, mechanisms on their interfaces, key components, and architectures (for example, how to handle processes Communication or persistence issues). By implementing and verifying actual code, dealing with primary technical tasks, such as resource competition, performance risks, and data security risks. Construction Phase: When you migrate from an executable system architecture to the first operational version of the system, you need to complete half of your implementation. Deploy several internal and alpha versions to ensure that the system is available and can meet the needs of users. By deploying a full-featured system beta version, this phase is completed, including installation, supporting documents, and training materials; however, to remember that the quality of functionality, performance, and system will likely need to be adjusted. Conversion phase: Make sure the software can meet the needs of software users. This includes tested products in the system released, and small adjustments to the system based on user feedback. At this point in the software development cycle, user feedback should focus on the problem of fine-tuning products and configuration, installation, and availability; all major structures have been solved in the early stage of the project cycle. 1 Applying these steps in this article, we have described you can use four steps to gradually switch from the waterfall type development method to incremental iterative development methods. Each step adds a practical value to your development work with the smallest interruption. Some teams use more than one step each time; other teams may work several items on a step before performing the next step. However, you should choose to use this wise implementation method because it can help you reduce the risk of process changes in development organizations. Note 1 For a detailed description of the RUP software development cycle, see the Rational Unified Process Made Easy, Per Kroll, and Philippe Kruchten (Addison-Wesley, 2003). About the author Per Kroll is the supervisor of the IBM Rational Software Rational Unified Process Development and Product Management Team. He has developed him to develop RUP-based customer training, guidance and consulting. When the RUP product team was established in 1996, he served as the original RUP product manager. He also casts a lot of effort to the RUP service of certified partners and training Rational staff.
