SC.2 Incremental Development
SZ.2 Inkrementelle Entwicklung
The incremental procedure is based on the basic idea that a system is planned as a whole but realized in parts-with a constant, step-by-step increase in functionality. Normally, a first system version is delivered to the user at an early stage. This early version offers the basic functionality. System parts that are developed later (and delivered) essentially improve the functionality.
The incremental procedure expects that the essential aspects of the user requirements can be collected at the beginning of the development, and that it is possible to design, develop, introduce and to use the entire system in various subsections or increments (builds).
The individual increments meet one part of the entire planned system functionality.. Thereby it is necessary to design the entire system early enough by means of defining the System Architecture. To realize the incremental procedure, special requirements are expected of the System Architecture. For example, it is necessary to define clearly interfaces and to make a modular, step-by-step system development possible.
During the later process, the System Architecture is structured into parts (normally according to functional criteria) so the individual increments can be defined with regard to size and to the order they are processed.
A placement of the individual increments as individual contracts is possible. The end user can already apply the corresponding increments for his activities.
The sequence of the SD activities in an incremental development is illustrated in Figure SC.1.
Figure SC.1: Sequence of SD Activities in an Incremental Development
Time T 0-Start
Initialization of the project and beginning of the tasks with regard to submodel SD.
Time T 1-First Increment
A preliminary system description is available as a result of activity SD1.2 - Description of Application System. It describes the core and the total objective for the system functionality.
For some of the fields (first increment) identified in activity SD1.5 - User-Level System Structure the user-level requirements are completed in part (field 1), others parts have not been completely generated (field 2).
Together, the results of activities SD1.2 - Description of Application System and SD1.5 - User-Level System Structure constitute the User Requirements; a first version is available with T 1.
The User Requirements must be detailed sufficiently to achieve the following goals:
As a result of activity SD2.1 - Technical System Design, the fields of the first increment have to be described in their technical environment (both in the System Architecture and the Technical Requirements).
- All relevant user-level fields must be named as soon as possible, their functional scope has to be demarcated.(1)
- The cooperation of fields must be clearly defined for all persons participating in the project.
- It must be clear in which (field-related) levels the system is to be generated and which overall functionality is to be covered with the final version. To do so, milestones (if necessary, as baselines with functional scope) have to be defined.
The individual fields are detailed and processed to the degree required for the first productive system version. In later versions, the individual fields can be refined and completed by new ones.
Taking into consideration the technical solutions within the scope of the SD1 - System Requirements Analysis activities and respective sub-activities, what results is a sound and sufficiently described specification from the user-level point of view for the realization of the first increment by a customer. System Architecture and Technical Requirements are completed and all other documents specifications required for the realization are generated. When the realization is completed, the first increment is made ready to be used.
Time T 2 to T N-1-Further Increments
At the time T 2, a refined version of the preliminary system description is available as a result of the repeated realization of activity SD1.2 - Description of Application System. Normally, the refinements remain within the scope of the overall system functionality that had already been defined at the time of T1. They represent a specification of the requirements. However, such refinements may also lead to new fields.
The user-level requirements are defined for the parts of the second increments. In this connection, it is possible to re-describe fields that were not taken into consideration before, and to refine fields that were already available. The first feedback after using the first increment will be taken into consideration.
The User Requirements thus available in a second version are the beginning of the refinement and completion of the System Architecture and the Technical Requirements.
The implementor, e. g. a contractor, enlarges the already productive system version 1 by newly added parts and integrates them within the scope of the integration process. It may also be possible that system version 1 has to be changed during the integration tasks. When the second increment has been completed, it is also made available to be used.
These steps will be repeated for each increment.
Time T N-Conclusion of the System Development
At the time T N, User Requirements, System Architecture, and Technical Requirements are complete and available in a consistent version. After the realization of the last increment it is made available to be used. The complete System is now applied.
The special complexity of the project management for developments completed in increments result from the fact that system parts are made available to the user (possibly in parallel mode) while active with the development tasks. The consecutive delivery of system parts results in several delivery dates to be coordinated, and usually in partial acceptances as well.
The PM cycle to be applied has been illustrated in Figure SC.2.
Figure SC.2: PM Cycle for Incremental Development
The planning of increments must take place within the scope of the preliminary planning. This refers both to the delimitation with regard to the contents of the increments and to the time plan for the generation of the individual increments. The conditions for structuring the System Architecture into individual realization levels are based on the modularity of the architecture. It must enable the incremental system development without having to update already completed increments.
The risk management on the level of the project management can be realized as a feasibility study on a technical level. The results are part of the basis for project management decisions.
In a phase review it is decided if the realization of a requirement control is necessary.
Within the scope of the project plan, a baseline is defined as the basis for the following development for each time T in the above sequence description.
Based on the point of view of quality assurance, partial deliveries result in increased requirements for the testing of interfaces. When realizing partial deliveries after a quality assurance, this must be considered in the assessment plan.
In the case of an incremental procedure, the configuration management administers not only the configuration structure but also, along with the technical system development, the structure of the already delivered system part.
The following list of advantages and disadvantages plus the listing of the most important requirements support the decision-making necessary for the selection of the illustrated incremental development strategy.
- Early delivery of a basis System and thus early use of an operable System core on the user's site,
- setting priorities for delivery by the user (possibly based on experience with the Systems delivered first),
- simple exchange of system parts (i. e. the increments) in case maintenance or modification was required,
- changing the contractor after the realization of an increment without any problem,
- refinement of User Requirements during the development (the User Requirements do not have to be complete at the beginning),
- noticeably shorter cycles when changing User Requirements as in conventional development.
- Changes of planned strategy for system generation must take into consideration the actual delivery status. Problems may be prevented by appropriate modularization and the definition of clean interfaces.
- The necessity to specify the total System at a very early stage may be difficult in projects with long runtimes. In cases like these it may be practical to define several successive projects.
- It must be possible to separate the System with clear interfaces (modular structure of System Architecture).
- The mentioned advantages and disadvantages must be investigated and evaluated. They cannot be applied to all projects but have to be checked with regard to the user-level and Technical Requirements and the marginal conditions to be observed.
Mail 0247 - Re: Ist die inkrementelle Entwicklung richtig dargestellt (247)
Mail 0244 - Ist die inkrementelle Entwicklung richtig dargestellt? (244)
Mail 0246 - Re: Umfang von SE 1.2 bei inkrementeller Entwicklung (246)
Mail 0243 - Re: Umfang von SE 1.2 bei inkrementeller Entwicklung (243)
Mail 0242 - Umfang von SE 1.2 bei inkrementeller Entwicklung (242)
Mail 0187 - Re: Projektmanagement fuer Inkrementelle Softwareentwicklung (187)
Mail 0183 - Projektmanagement für Inkrementelle Softwareentwicklung (183)
(1) It is possible that new user-level fields are added in the course of development. This can be problematic for contractual reasons.