Previous Next V-Model Official Homepage by IABG  
Part 3: Collection of Manuals Homepage  
Scenarios  Homepage  
SC.2 Incremental Development  

  SZ.2 Inkrementelle Entwicklung

Contents  
  • SC.2.1 Sequence Description for the Activities in Submodel SD
  • SC.2.2 Cooperation with the remaining Submodels
  •       SC.2.2.1 Cooperation with Submodels SD and PM
  •       SC.2.2.2 Cooperation of Submodels SD and QA
  •       SC.2.2.3 Cooperation of Submodels SD and CM
  • SC.2.3 Criteria for the Selection of Scenarios
  • Links to the V-Model Mailinglist
  • Links to Glossary
  • SC.2.1 Sequence Description for the Activities in Submodel SD

    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
    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).

    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.

    SC.2.2 Cooperation with the remaining Submodels

    SC.2.2.1 Cooperation with Submodels SD and PM

    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
    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.

    SC.2.2.2 Cooperation of Submodels SD and QA

    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.

    SC.2.2.3 Cooperation of Submodels SD and CM

    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.

    SC.2.3 Criteria for the Selection of Scenarios

    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.

    Advantages:

    Disadvantages: Requirements:


    Links to the V-Model Mailinglist

    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)

    Links to Glossary

    Incremental Development

    Note:

    (1) It is possible that new user-level fields are added in the course of development. This can be problematic for contractual reasons.

    Previous Next This page online  •  GDPA Online  •  Last Updated 03.Mar.2004 by C. Freericks