Software industry faces a big challenge from fast growing need of rapid and cost effective development and maintenance of large-scale, complex software systems. So the latest buzz in the industry is to adopt Component Based Software Development (CBSD). As the name says, it refers to the development of software systems by assembling the already existing software components. Rather than building software systems from scratch, they are assembled from reusable software components. CBSD facilitates the development of software within time and budget constraints. These reusable software components may be built in-house or bought from third party vendors (i.e. Commercial Off The Shelf components-COTS) or free of cost (i.e. Open Source Software Components). New applications are now deployed as a combination of pre-assembled and newly created components integrated to form complex business systems. The resulting increase in reuse is expected further to dramatically improve time-to-market, software lifecycle costs, and quality.

Component Based Software Engineering (CBSE) is a process that emphasizes the design and construction of computer-based systems using reusable software “components” (Brooks et al., 2005).

CBSE is primarily concerned with three functions:

• Developing software from pre-produced parts.
• The ability to reuse those parts in other applications.
• Easily maintaining and customizing those parts to produce new functions and features.

Software development process focuses on the activities related to software production. It consists of a sequence of steps that are always performed in a particular order. The process helps to achieve consistency in a project, which involves a large number of people with different skills.

Lifecycle processes include all activities of a product or a system during its entire life, from the business idea for its development, through its usage and its completion of use. Namely,

• Project planning and feasibility study
• Requirements analysis and specification
• System design
• Implementation
• System integration and testing
• Acceptance, installation and deployment
• Maintenance

The main idea of the component-based approach is building systems from already existing components. This assumption has several consequences for the system lifecycle (Crnkovic et al., 2006).

Separation of development processes: The development processes of component-based systems are separated from development processes of the components; the components should already have been developed and possibly have been used in other products when the system development process starts.

A new process in Component Assessment: A new, possibly separated process, finding and evaluating the components appears. Component assessment (finding and evaluation) can be a part of the main process, but many advantages are gained if the process is performed separately. The result of the process is a repository of components that includes components' specifications, descriptions, documented tests, and the executable components themselves.

Changes in the activities in the development processes: The activities in the component-based development processes are different from the activities in noncomponent- based approach. For the system-level process, the emphasis will be on finding the proper components and verifying them. For the componentlevel process, design for reuse will be the main concern.

According to ISO 9126 software quality can be defined in a generic way in terms of six desirable characteristics Figure 1 shows how CBSD contributes to each of these characteristics:

Functionality: Use of pre-existing components allows faster delivery of greater functionality.

Maintainability: The modular structure of a componentbased solution allows individual components to be replaced easily.

Usability: Use of standard components supports commonality of GUI. CBD also supports desk-top integration, which gives the user a single view of heterogeneous data.

Efficiency: Performance bottlenecks can be identified, and the need for performance tuning can then usually be localized in a small number of performance-critical components. Components can be internally optimized to improve per formance, without affecting their specification; components can be moved between platforms to improve performance, without affecting the functionality or usability of the application.

Reliability: The reliability of the application as a whole is a separate issue, but is clearly enhanced when the application is constructed from reliable components.

Portability: The specification of a component is platform independent. So a component can be quickly rebuilt for a new platform, without affecting any other component.

CBSD promises a lot of benefits but for achieving productivity and quality gains, this approach needs to be followed religiously. There is a mark-able difference in CBSD and traditional software development approach. CBSE has introduced fundamental changes in the software development and maintenance.

Figure 1. Quality Attributes Provided by CBSD

During component based software development, reusable components have to be explicitly considered and the development process has to be altered to reflect the reuse-based approach. Activities such as component selection and composition have to be modeled as separate process steps rather than being performed as the part of traditional development steps. CBSD clearly depicts a shift from the norm.

In the requirements and design phases the availability of existing components must be considered. Software applications are assembled from components from a variety of sources; the components themselves may be written in several different programming languages and run on several different platforms. Best components selected in the beginning of life cycle may suffer from incompatibility problems towards the end. Technical standardization is necessary and a method suited to CBD has to be followed. According to Boehm and Abts (Boehm and Abts, 1999) both the waterfall model and evolutionar y development are inappropriate for component based development because:

• In the sequential waterfall model, requirements are identified at an earlier stage and the software components are chosen at a later stage. This increases the likelihood of the software components not offering the required features.
• Evolutionary development assumes that additional features can be added if required. However, software components acquired from third party vendors (COTS) cannot be upgraded for one particular development team. The absence of source code hinders the development team from adjusting these software components to their needs.

Several reuse based process models have been proposed. Sommerville's Model (Sommerville, 2005), Kotanya's Model (Kotonya, 2003), Y Model (Capretz, 2005) V Model (Crnkovic et al., 2006), Qureshi and Hussain's Model (Qureshi and Hussain, 2008). The main features of these models are presented in Table 1.

Table 1. Important Features of CBSD models

In Sommerville's model (Sommerville, 2005) there is no operational support and maintenance, also there is no component management activity which leads to a great amount of requirements trade-off. Whereas the Kotanya's model (Kotonya et.al. 2003) provides substantial component management. The V model (Crnkovic et al., 2006) provides support and maintenance process that includes deployment of new or modified components in the system, change in glue-code, or replacement of troubling components. The Y-Model (Capretz, 2005) can be used both top-down and bottom-up wise. In this model, choice in top-down or bottom-up approach depends upon the knowledge of the software engineer about the application domain. A novice developer may use bottom-up approach, but an experienced one may prefer to work on high level abstractions. Component selection, requirement specification and architecture definition must be worked in parallel with constant tradeoffs among them but this juggling may result in cyclic requirement-component dependency problem (Tran et al., 1998). The problem can be described as follows:

• Creation or modification of a system requirement forces reexamination of COTS products that have been previously selected.
• Selection of a new COTS product forces reexamination of all associated system requirements

In the Qureshi and Hussain (Qureshi and Hussain, 2008) model there is no component management because the model claims the use of repository but there is no explicit mention of how and when components are added to the repository. From many processes available, the problem is to find the model suitable for a particular type of component based development.

Comparison of all the component based development models for the purpose of highlighting the common activities required in all and finding the important one for further improvements.

As shown in Table 2, the parameters for comparison are the specific activities needed for software development using components based approach.

Table 2. Component Activities Present in Various Models

It could be observed that all models support all the activities except domain analysis and Component Evolution. And for systematic reuse these two activities are very important. In order to actually gain positive economic benefits, availability of a set of suitable reusable components is essential. To this end, the domain analysis provides a pool of reusable components that can address the requirements of various applications in that particular domain. Domain analysis helps in preparing for application development using already available reusable components, whereas component evolution helps in application maintenance. Only Kotanya's model (Kotonya et al., 2003) considers the issue related to new versions of software components available in the market. Various activities identified as essential in all the component development process are listed in Table 2. The activity of component selection is the most important because

• it comes before any other activity for evaluation
• all the efforts are waste if a wrong component is selected. So the next focus is for getting a best component selection technique which can be included in any of these process models for improvement.

Software development process model lays the foundation for a good quality product. A reuse based approach to software development requires a software process different from the traditional process as the traditional processes cannot accommodate the risks that are associated with the use of reusable components. As far as the practice goes, the actual use of the proposed reuse based development processes is very low (Kaur and Singh. 2010) . Most of the projects are still using traditional processes by just adding to them some additional activities related to component identification and component selection etc. Component selection is a very important activity in a CBSD approach. New models that include such activities as domain analysis, component selection and component evolution need to be proposed and prototyped. There is a need to spread the word of component based development model exclusively.

Just like the traditional models, CBSD models also need to gain popularity in the industry. This might be possible once the relative costs and benefits of choosing a component based process can be weighed against the choice of a traditional software development process.