 |
 |
 |
|
 |
|||
 |
|||
| SC.4 Use of Off-the-Shelf Products |
SZ.4 Einsatz von Fertigprodukten
SC.4.1 Sequence Description for the Activities in Submodel SD
The integration of off-the-shelf products (available, suitable function units for the project) into a System are based on the idea to reduce the development costs and efforts by using already existing modules (SW and HW).
Off-the-shelf products may have different origins:
- Commercial off-the-shelf products are offered on the market. Normally, the source code is not available. These products are obtained under license.
- Off-the-shelf products are available in the own environment (e. g. industry, authorities, well-known organizations). In these cases, the source code is usually available.
Using off-the-shelf products within the scope of an incremental development has been illustrated in Figure SC.4.
Preliminary Remarks:
- The scenario for the incremental system development is the basis for the following descriptions.
- The additions to the use of off-the-shelf products are shown in italics.
Figure SC.4: Sequence of SD Activities when Off-the-Shelf Products are Used
Time T 0-Start
Initialization of the project and begin of activities with regard to contents of submodel SD.Time T 1-Assessment with Regard to Off-the-Shelf Products to be Used
As a result of activity SD1.2 - Description of Application System, a preliminary system description is available describing the core and the entire functionality of the System.For some fields identified in activity SD1.5 - User-Level System Structure (first increment) the user-level requirements are partly complete (field 1), other parts are incomplete (field 2).
Together, the results of activities SD1.2 - Description of Application System and SD1.5 - User-Level System Structure represent the User Requirements that are available in a first version (User Requirements version 1).
The User Requirements must be detailed enough to achieve the following goals:
- As far as possible, all relevant user-level fields must be named and delimited with regard to their functional scope.(1)
- The cooperation of fields must be clearly defined for the project participants.
- 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 achieve this, milestones (if necessary, as baselines with deadline and function scope) must be defined.
The individual fields are detailed and specified to the degree necessary for the first productive system version. The individual fields can be refined and completed in later levels.
The market survey realized within the scope of the feasibility study shows that parts of the User Requirements can be covered by commercially available products. The evaluation of the off-the-shelf products (in activity PM2 - Placement/ Procurement) that may be used prove, however, that none of the off-the-shelf products meets all the defined User Requirements. The realization of a requirement control was decided on within the cope of a phase review (activity PM6 - Phase Review).
During the requirement control, suggestions for a modification/reduction of requirements will be defined. The results of the requirement control are integrated into the User Requirements (User Requirements version 2). If necessary, a modification of the system architecture is also required. The User Requirements are the basis for the criteria catalogue to be generated in the PM; this catalogue is used for the selection of suitable off-the-shelf products.
Time T 2-Integration of Off-the-Shelf Products
At the time of T 2, the off-the-shelf products obtained by the PM have been integrated into the first increment. All required assembly tasks have been realized. After completion of the integration, the first increment is made available to be used.
Time T 3 to T N-1-Further Increment Levels
At the time of T 3, 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 affect the entire functionality of the System that was defined at the time of T 1. They are a specification of the requirements. However, these refinements may also lead to a new field.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 requirements realized in the second increment cannot be covered by off-the-shelf products. 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.4.2 Cooperation with the Remaining Submodels
SC.4.2.1 Cooperation with Submodels SD and PM
The procuring of the off-the-shelf products is realized in submodel PM (activity PM2 - Placement/ Procurement). Because of competition, it is necessary to get offers from different manufacturers. These must be evaluated. The required assembly measures have to be defined in connection with the evaluation of the offers.
In case none of the offered off-the-shelf products meets all of the defined selection criteria, a phase review will decide (activity PM6 - Phase Review) about the necessity of a requirement control.
SC.4.2.2 Cooperation of Submodels SD and QA
Meeting the requirements expected of an off-the-shelf product is assessed and evaluated during the evaluation of the offers (activity PM2 - Placement/ Procurement). Therefore, the explicit assessment of the off-the-shelf products within the scope of submodel QA is not necessary.
The realized assembly measures must be assessed according to the regulations of submodel QA, and also within the scope of the tender documents generated in activity PM2.
SC.4.2.3 Cooperation of Submodels SD and CM
With regard to configuration management, each off-the-shelf product must be treated like an internally developed product. With regard to the change management it is necessary to note that the improvement is influenced by the manufacturer in question. Normally, the modification of User Requirements has no impact on the further development of the final product.
SC.4.3 Criteria for the Selection of Scenarios
The following list of advantages and disadvantages and the listing of the most important requirements support the decision-making with regard to the use of off-the-shelf products.
Advantages:
- Reduction of the development risk,
- minimization of time needed for the development,
- productivity increase for software development,
- reduction of the lifecycle cost,
- use of already perfected state-of-the-art products,
- minimization of the maintenance/modification cost,
- fast realization of prototypes.
- Lacking influence with regard to the further development of the off-the-shelf product (dependence on supplier),(2)
- off-the-shelf products often do not meet all the defined requirements,
- using off-the-shelf products as a licensed product,
- deficits with regard to security and dependability,
- often change of organization required.
- Defined selection criteria,
- stable User Requirements.
Note: (1) It is possible that new user-level fields are added in the course of development. This can be problematic for contractual reasons.
(2) Product development is predominantly driven by the marketplace, not by user requirements.
Links to the V-Model Mailinglist
Mail 0344 - Re: Einsatz von COTS-ProduktenMail 0342 - Einsatz von COTS-Produkten
Mail 0295 - Re: Szenario "Einbinden von Fertigprodukten"
|
|
|
This page online • GDPA Online • Last Updated 03.Mar.2004 by C. Freericks |