X hits on this document

PDF document

A State-of-the-Practice Survey of Off-the-Shelf Component-Based Development Processes - page 12 / 14





12 / 14

The EPIC approach [1], like the RUP, consists of four phases and each phase con- sists of one or more EPIC iterations. The information of four spheres of influences, such as stakeholders’ needs, architecture design, risk, and marketplace, was gathered and evaluated in each iteration. The project management, customer requirements, and system architecture will be adjusted according to the trade-offs of the four spheres of influences. Since every iteration includes a complete sub-process to make the trade- off decision and select the OTS component, it is more flexible and suitable to be used as a reference in scenarios 4 to 7.

6. How to select the OTS components

The results of this study support our conclusion in the exploratory study [6], and shows that the familiarity-based and internet search-based processes are frequently used in practice. The results also confirm that OTS component selection can be per- formed in different development phases (requirements, design, or implementation), depending on the project context, especially on the familiarity with possible OTS components, and/or the flexibility of requirements [6]. In addition, results show pro- ject members aim at reusing familiar OTS components and selecting them in early phases. In our study, we measured the importance of an OTS component by their contribution on the functionality of the system. Although the results show no correla- tion between the OTS component’s importances with the phase it was selected, we still suggest project members to select OTS in the earlier phases, especially if the OTS component has a tight coupling with other components.

In different scenarios shown in Section 5, different OTS component selection strategies and processes can be used. In scenarios 1, 2, 4, 5, and 7, some unfamiliar OTS component candidates are going to be used. The selection process for unfamiliar OTS components can either be an internet search with hand-on trial-based, or a for- mal selection process, such as processes shown in [5], [8], [9], [11], [13], [14]. In scenarios 3 and 6, all possible OTS component candidates have been used by the project members, the selection process could mainly be familiarity-based.

In scenarios 1 to 3, the use of OTS component is well-planned. In general, the OTS component will be selected in the early phase of the project in these scenarios. Selecting OTS component in the early phase can help to design the software architec- ture with consideration on constrains of the OTS components. Therefore, it is easier to avoid the mismatch between the OTS components and other components in the system.

In scenarios 4 to7, the OTS components are usually be evaluated at a phase which most of the other components are already integrated in the system. Since the goal is to integrate the OTS component into the current system and to check its integration thoroughly, integrate the demo version of the OTS component and do a hand-on trial is necessary. In case the OTS component was selected in the very late stage of the project, it is better to select a component that has a loose coupling with the other components. OTS components tightly coupled with existing components may impose a high number of changes onto the system.


Document info
Document views39
Page views39
Page last viewedTue Jan 17 13:53:21 UTC 2017