An Analysis Of Life Cycle Models For CBSD

— The need for computer software development is fast growing in our society today. The major challenges faced by the industry is to provide products with quality and functionality at low cost and short time. To meet these challenges software development must be coped with complexity and to adapt quickly to changes. The solution of this is reusability. A number of software life cycle models existing today focused on building on traditional software systems. But the question is whether these existing models are ready to fit in this emerging field. Several life cycle models for component based software development have been introduced by researchers. The role of component based software engineering is to develop the reusable components and assemble them into one system. In this research, we surveyed some of the popular approaches and provide a comparative study of these approaches.


III. LIFE CYCLE MODELS OF CBSD
Component based software systems are built from well-defined, independently produced self made components and assembling them together rather than programming on overall system from the scratch. Component based software models focus on reusing the whole software components Traditional life cycle models basically do not focus on artifact reuse. Thus the life cycle of the traditional software system is different from component based software system. A life cycle model is a blueprint of the software process. It describes all the phases in order in which the flow of process goes on. To develop a good software product, software engineers must identify a suitable life cycle model for their project. In Figure 1 Sommerville has provided a sequential approach for CBSD [3]. The approach comprises of the following Six Steps: i.
Step 1: The user requirements are developed in outline rather than in detail as specific requirements limit the number of components that might be used. ii.
Step 2: A complete outlined set of requirements is used to identify as many components as possible for reuse. iii.
Step 3: Requirements are refined and modified so that they can comply with components. iv.
Step 4: Architectural design is developed. v.
Step 5: After system architecture is designed, steps 2 and 3 may be repeated. vi.
Step 6: Finally the components are integrated which turns into a complete system. There are various life cycle models for CBSD have been designed so far. In this section we will describe briefly some of those proposed models for CBSD.

A. The X Model
In this X Model, the processes are started by requirement engineering and requirement specification. The main characteristic of this software life cycle model is reusability in which software is developed by building reusable components for software development and software development from reusable and testable components. In software development, it uses two main approaches, develop software component for reuse and software development with or without modification in reusable component [4].

B. The Y Model
The Y Software Life Cycle Model describes software reusability during CBSD. The Y Shape of the model considers iteration and overlapping. Although the main phases may overlap each other and iteration is allowed, the planned phases are: domain engineering, frame working, assembly, archiving, system analysis, design, implementation, testing, deployment and maintenance [5].
The reusability within this life cycle is efficient and more effective than within the traditional models because it integrates at its core, the concern for reuse and the mechanisms to achieve it. The Y model supports "development with reuse" through component assembly, as well as "development for reuse" through component archiving. Y model shows great applicability in component based software development.

C. The Y Model
The V Model is a top-down approach to system design: the system is designed first and then components are developed. A straightforward adaptation of the V Model for CBD would be to retain the top-down approach to system design but uses a component as a module. However, such a straightforward adaptation of the V Model is at variance with the standard CBD process precisely because it does not include a component life cycle and consequently does not incorporate the bottom-up nature of CBD [6].
An adaptation of the V Model for CBD that does incorporate the bottom up nature of CBD is completed by containing separate life cycles for component development and system development. However, this adaptation really applies the V Model only to its system life cycle; there is no evidence of the V Model in its component life cycle. So, for adaptation of the V Model properly for CBD, both the component life cycle and the system life cycle are needed.

D. The W Model
The Two V Models are conjoined via the step of component selection, adaptation, and deployment. This 'double V' process is represented as the W Model. It consists of two phases: component design and component deployment, and is set in the context of a problem domain. In the design phase, components are designed and constructed according to the domain requirements or knowledge, and deposited into a repository [7]. Repository components are domain-specific but not system-specific. In the deployment phase, components are retrieved from the repository and instantiated into executable component instances which are then deployed into a specific system under construction. Bottom up approach is used for the process of component selection and adaptation, followed by system assembly, which is simply the composition of the deployed components. The bottom up nature of this process is indicated by an iterative loop. It is worth noting that within this loop, the component life cycle links up with the system life cycle, since deployed components are iteratively assembled into the system life cycle [8].
Applying the V Model to both the component and system life cycle yields a W model. The component life cycle of W model is similar to that in the Y model. However, the Y model does not apply the V model in any way to its component life cycle.

E. The Knot Model
A Component based model is described in which reusability in the form of the component is applied. The utmost emphasis is given on reusability, modularity, risk analysis and feedback in each phase, which results in simple, error free and a profound new system with proper feedback in each phase of software development. The major advantages of this software life cycle is to handle the complex systems using modularity, reusability, lifetime process, evaluation & testing in each phase to reduce the risk [9].
This model emphasizes on reusability considering risk analysis and feedback on each and every phase. It is best suited for medium or larger complex system. A component that is developed is based on general specifications not on particular application's specification. In this model risk is resolved in the early stages of each phase that results in the reduction of cost and time.

F. The M Model
The M model is a new Component based model which enhanced the concept of reusability in the form of the component. The M model represents a combination of Traditional models and component based software engineering model. The process steps start upward in a two way direction, on first phase, i.e. called development for reuse, after the storage of component in pool i.e. called second phase, the process steps moving down which is called the development from reuse i.e. third phase. The process steps are bent upwards in the fourth phase, which is called testing phase, and then it is once again moving down in the fifth phase to form the typical M shape. The M model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. This model follows the both top down and bottom-up approach. At last after developing a system the component of the system place in the component storage pool for reuse in future [10]. M model is used for fast development and delivery of a high quality component based system at low investment cost. It improves the productivity of software.
The component process model can be a part of software development process. Table 1 shows the characteristics and limitations of the above stated models:

IV. CONCLUSION
In this paper, we studied several life cycle processes for component-based software development and provided a comparative analysis of these processes. Component-based software engineering is still at its young stage of life and there is much room for research in this field. We noticed that the present life cycle models have several weaknesses. In our future research, we will try to propose CBSD life cycle model that can efficiently face the weaknesses of present CBSD life cycle models.