Component Based Software Development (CBSD) refers to the development of software
systems making considerable use of already existing software components. Instead
of building software systems from scratch, they are assembled from reusable
software components. This approach facilitates the development of software within
time and budget constraints. It also results in quality and productivity gains
(Szyperski et al., 2000). These reusable software
components may be built in-house or acquired from third party vendors for a
price (called Commercial Off The Shelf components-COTS) or free of cost (called
Open Source Software Components).
The CBSD has a lot of promises. But it is not a silver bullet. For achieving
all the gains, CBSD approach needs to be followed religiously. We cannot get
along with the scheme of things used in the traditional way of software development.
There is a significant difference in CBSD and traditional software development
approach. The traditional software development processes do not address challenges
and risks of using reusable components. 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 CBSD has to be followed.
This study gives an account of the various component based development process
models available in the research literature. Towards the end, a review of the
existing scenario, regarding the use of software process models in the software
industry, is also presented.
SOFTWARE DEVELOPMENT PROCESS
Software development process focuses on the activities related to software
production, for example design, coding and testing. 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. Here we briefly discuss various process models proposed
in the research literature (Schach, 2008).
Waterfall model gives a fixed ordering to the basic set of process activities such as requirement analysis, design, implementation and testing. Simplicity of the model is its strength. However, heavy documentation and the constraint of pre-decided fixed set of requirements are some of the weaknesses. Prototyping model helps to understand uncertain requirements. It also reduces the risks involved in developing novel systems. Rapid Application Development (RAD) is a variation of prototyping model. RAD relies heavily on rapid application tools to quickly deliver the product. Iterative enhancement (evolutionary) model combines benefits of both the waterfall and prototyping models. Initially basic functionality of the system is implemented. Quality of the system is improved in next iterations. Agile process model puts less emphasis on analysis and design. Implementation starts much earlier in the life cycle of the software product. This process model demands fixed time rather than fixed features. A new version of software is delivered after every 3 weeks. Extreme Programming is a new software development approach, based on iterative enhancement model. It is a test driven approach. To begin with, programmers design test cases for a new task. Task is implemented and it is ensured that all the test cases are satisfied by the task. Spiral model includes the best features of waterfall, prototype and iterative enhancement models and introduces a new concept - risk assessment and resolution. This new feature makes the spiral model more realistic than others process models. All these process models are suitable for development from scratch. Now days, majority of the software development projects involve some degree of reuse of existing artifacts such as design or code modules. Rational Unified Process (RUP) considers reuse of existing classes in one of its initial phases. But it focuses only on object oriented development. So we need to look for process models which support the reuse of already existing reusable software components irrespective of their development or deployment platform.
Component Based Software Development Process
Boehm and Abts (1999) regard both the waterfall model
and evolutionary development unsuitable 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
||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 bars the development team from adjusting these
software components to their needs
During component based software development, reusable artifacts have to be
explicitly considered and the development process has to be tailored to appropriately
reflect the reuse-based approach. Reuse-related activities such as component
selection and composition have to be modeled as separate process steps rather
than being performed under the hood of conventional development steps. CBSD
clearly signals a paradigm shift. Some of the characteristics of a component
based software process model which make it different from a traditional process
model are presented by Kaur et al. (2007).
Sommerville (2005) identifies the intermediate stages
in a reuse-oriented process:
Analysis: After the requirement specification, component repository
is searched to identify the matching components
||Requirement Modification: In case matching components
are not available, requirements may have to be modified. If not possible,
a re-search is done to find the alternate solutions
Design with Reuse: New system is designed keeping in mind the reusable
||Development and Integration: If appropriate components
are not available, they are developed from scratch. New and old components
are integrated to build the final solution
COMPONENT BASED SOFTWARE DEVELOPMENT PROCESS MODELS THE STATE OF ART
Component based software development is a twin process activity. The two processes are used at different stages of the life cycle of an application. First process is the component development process. It caters to the development of reusable software components, which are to be used in building an application using the second category process. Second process is the component based software development process and it is related to the development of a software application using already existing reusable software components. Both the processes are independent of each other with respect to time-frame and organizational homes. Individual components may be developed at different time and at different places. They may be later composed in to a software system at a different time and at a different place. The first process i.e., the software component development process resembles a traditional software development process. In addition to that it requires a horizontal analysis of the relationships and constraints that the component may have with the external environment so as to produce a product which can be used in multiple applications. Here the focus is to find an adequate trade-off between different factors, such as generality and complexity, in order to produce a component that is effectively reusable. A more general term to refer to this process in CBSD terminology is domain analysis. The output of domain analysis is not a single component but a set of components that can be used, in combination, to support functionalities of several applications in a specific domain.
This study discusses the process models only for the second type of CBSD activity i.e., software development using reusable software components. Here we discuss the component based development process models proposed in the research literature. The focus is on pure component oriented development. Evolutionary models such as RUP with object oriented development approach are not discussed here.
CBSD process model suggested by Sommerville follows sequential approach and
is shown in Fig. 1 (Sommerville, 2005).
This process model has 6 phases:
||Outline System Requirements: The user requirements
are outlined briefly (rather than developed in detail, as specific requirements
limit the number of components that might be used)
Components: A complete outlined set of requirements are used to identify
as many components as possible for reuse
Requirements: Requirements are refined and modified so that they can
comply with components
Design: Architectural design is developed
can be negotiated to incorporate architecture compatible components. After
system architecture is designed, steps 2 and 3 may be repeated
Finally the chosen components are integrated to get the software system
Kotanya et al. (2003) Model
Kotonya et al. (2003) has suggested a component
based development process, which takes into account activities related to component
use as well as component management. The development process phases are given
System Requirements: The phase includes activities such as requirements
elicitation, requirements scoping, requirements modeling and specification
System Architecture: This is the process of partitioning system requirements
into logical components or subsystems
||Compose System: This is the process of replacing abstract
design components with concrete off-the-shelf components. The composition
process must devise mechanisms for integrating the different components
without compromising the system quality (i.e., ensuring that the components
conform to the adopted component model) (Fig. 2)
||Verification: The verification process corresponds
to the whole development process. Focus of verification changes in each
phase. At the requirements stage, verification is used to establish the
availability of software components and viability of a component-based solution.
At the design stage verification is concerned with ensuring that the design
matches the system context (i.e., in terms of non-functional requirements,
architectural concerns and business concerns). This may require detailed
blackbox testing of the software components and architectural analysis of
the design. At the composition stage verification translates to design validation,
through component assembly testing and system testing
||Management: This phase looks after activities such
as managing assets, system configurations, managing change and assuring
quality. Asset management includes acquisition of components, their usage
and evolution. Components (especially COTS) in a component based system
evolve at different times with different objectives giving multiple versions
of the same component in the same application. So a framework for tracking
and controlling the versions of black box software components and custom
software installed at all locations for the system is required. Management
phase is also responsible for market research. New software as well as hardware
products are introduced in the market every day. A framework guides for
determining the timescale and kind of changes to be made to the commercial
components that are already in a component based system
In this model, basic activities of a software development process such as
System Analysis, Design, Implementation, Testing, Deployment and Maintenance
are available as such. Some additional activities are added to support the component
based software development (Fig. 3). New phases introduced
in this process are as follows:
||Domain Engineering: Domain engineering is concerned
with identification of potentially reusable components for a particular
domain. For example in the banking domain, the components such as CreateAccount,
CheckBalanace, DepositAmount and WithdrawAmount can be reused across multiple
banking applications. Domain engineering is a process of analyzing an application
domain in order to identify areas of commonality and ways to describe it
using a uniform vocabulary
||Frameworking: A framework is a skeleton or a template
used for producing software in an application domain. Frameworks capture
the semantic relationships between the components of a particular domain.
The main purpose of frameworking phase here is to reuse the software components
already developed and then classify them further to form new frameworks
In this phase, the software application is composed from the existing
reusable software components
||Archiving: The components developed for a particular
software application are archived for future use in other related applications.
This involves activities such as component cataloguing and storage
The V-model for traditional software development is adapted by (Crnkovic
et al. (2005) for building a system from pre-existing components,
the main theme of component-based approach. The activities in different phases
of the development process are shown in Fig. 4 and described
||Requirements Analysis and Specifications: Requirements
are analyzed and specified keeping in mind the available components. If
possible, requirements can be negotiated as well in order to make use of
the available components
||System and Software Design: In this phase again, component
pool is available. Components selected in the previous phase may have to
be rejected if they do not fit into the overall design of the software.
Alternatives can be selected from the component pool
||Implementation and Unit Testing: An ideal case to build
an application is the direct integration or connection of component interfaces.
But in practice, glue-code/component wrappers need to be written to bridge
component interface mismatches. Sometimes new functions have to be written
to fill the gaps in system requirements and component capabilities. These
modules are then tested separately
adapted for component based software development
||System Integration: The integration process includes
integration of standard infrastructure components such as data base management
and communication software components that build a component framework and
the application components
||System Verification and Validation: Standard tests
and verification techniques are used here. Error identification is more
difficult in case of black box components, which are procured from various
||Operation Support and Maintenance: In the operational
system, new components may have to be added or existing components have
to be modified/removed in order to support the changing requirements. The
support and maintenance process includes deployment of new or modified components
in the system, change in glue-code, or replacement of troubling components
Qureshi and Hussain (2008) Model
This model proposed recently is largely influenced by object oriented software
development life cycle. Main phases of this process model are given below:
Every new project starts from communication with the customer
Project feasibility is evaluated in the planning phase
||Analysis and Component Selection: If feasibility report
is OK then analysis of the detailed requirements of the project starts.
Alongside requirement analysis, suitable components are selected
||Engineering and Testing: In the engineering and testing
phase, selected components are adapted, if required. Development of new
components also takes place in the same phase, in case existing components
could not fulfill all the requirements of the software application. Integration
and system testing of the newly developed and of the reused components are
Developed system is submitted to the customer for feedback
Existence of a component repository is essential in this life cycle model.
Component repository supports the application developer during the analysis
and selection phase (Fig. 5). But there is no explicit mention
of how and when components are added to the repository.
Top Down v/s Bottom Up approach of Component Based Software Development
An important question to ask is as to what type of role software architecture
plays in building an application-active or passive. Should the software architecture
be specified first and then components selected accordingly that fit into the
specified architecture? Or the components, which match the application requirements,
should be chosen first and then architecture of the application decided. A brief
overview of the definitions of software architecture and component architecture
give an idea of level of interconnection required for smooth composition of
||Software Architecture: The software architecture defines
the static organization of software into subsystems interconnected through
interfaces and defines at a significant level how nodes executing those
software subsystems interact with each other
||Component Architecture: Component system architecture
consists of a set of platform decisions; a set of component frameworks and
an interoperation design for the component frameworks (Crnkovic
and Larsson, 2002)
Ideally every component should conform to a component model for easy interoperability with other components. NET, JAVA and CORBA are some of the popular component models. It is possible to use components implemented in different component technologies, but in practice it is very difficult to achieve interoperability between different component models. A component model requires a particular architectural framework and the application is supposed to use this framework. This has a direct impact on architectural decisions. For example, if the component model requires a client-server architecture style, it is obvious that the application will use that style and not another one for example pipe-filter. This will put limitations on the system design.
So for a successful and cost-effective component integration, either components have to follow the interaction mechanisms imposed by the software architecture of the application, or the software architecture of the application should adapt to the interaction mechanism or platform restrictions embedded in the software components.
We discuss below both the strategies of software development (Top/Down and Bottom/Up).
Architecture Driven (Top/Down) Software Development
This approach is similar to the traditional way of software development.
First a high level design and specifications of needed software components are
created. Once the software architecture has been defined, the components which
are to constitute the system must be developed or selected. Components typically
need to be adapted before integrating them into the system. This top-down approach
ensures the fulfillment of requirements to some extent. However, this approach
does not encourage the reuse of preexisting components, since there is a high
degree of probability that only a few or no pre-existing components exactly
fit into the system (Brownsword et al., 1998).
Component Driven (Bottom/Up) Software Development
The architecture driven component based development process follows the
traditional approach i.e., first analyze the requirements and then identify
the components that match the requirements. But such a process is essentially
a failure for component based software. Because it ignores the existence of
reusable components and tries to find a component that matches the newly identified
requirements and the chosen architecture. What if the required components do
In component driven software development, the system requirements and architectural
design are already influenced by available software components. The system design
is based on available components and compared to architecture driven development,
results in a higher degree of reuse. Sametinger (1997) opines
that development based on components should preferably be done in a bottom up
manner rather than top to down.
The Y model supports both the strategies of software development-top/down as well as bottom/up. In this software process model, choice in top-down or bottom-up software development strategy 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. This knowledge naturally determines the prevailing strategy to software development.
Availability of reusable software components also influences the choice of
software development strategy. Different development process is required depending
on the degree to which the components are pre-existing (Crnkovic
and Larsson, 2002).
A strictly top-down or bottom-up strategy to software production is not quite
appropriate. A mix of bottom-up and top-down approaches begins with the system
requirements and the analysis of possible candidate components. Component specification
and selection have impact on final requirements and the system architecture.
There is a critical relationship between component selection, requirement specification
and architecture definition. Pragmatically, three essential elements (requirements,
architecture and component selection) must be worked in parallel with constant
trade-offs among them (Brownsword et al., 1998).
But this juggling may result in cyclic requirement-component dependency problem
experienced by Tran et al. (1998). The problem
can be described as follows:
or modification of a system requirement forces reexamination of COTS products
that have been previously selected
of a new COTS product forces reexamination of all associated system requirements
They have also outlined some risk mitigation approaches to minimize the impact of this problem.
models and component activities
Means the process model supports the activity
The Development Process and Component Activities
Component based software development approach consists of activities, which
do not exist in the traditional software development approach. The development
processes described in section 3 are compared on the basis of component related
activities supported for component based development. As shown in Table
1, the parameters for comparison are the specific activities needed for
software development using components based approach. These parameters are listed
in column 1. Other columns of the table show the information about the process
models in this order - Sommervilles model (2005),
Kotonya et al.s model (Kotonya et al.,
2003), V-model (Crnkovic et al., 2005), Y-model
(Capertz, 2005) and Qureshi et al.s Model
(Qureshi and Hussain, 2008).
It could be observed in Table 1 that all models support all
the activities except 2, namely domain analysis and Component Evolution. But
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 Kotanyas model looks into this
issue related to new versions of software components available in the market.
Significance of this issue can be judged from the fact that vendors upgrade
their components every 10 months on average and component releases go unsupported
after an average of 3 releases (Yang et al., 2005).
Market analysis helps to study the component changes required as a result of
continual component updates. So the application maintainers have to be in look
out for new versions of the components to maintain the application successfully.
WHAT THE STANDARDS SAY?
IEEE 1517 was published in 1999 as a supplement to IEEE/EIA 12207 (IEEE,
1999). It is intended as a specification of the minimum requirements that
a software life cycle model must meet to enable and support proper reuse. IEEE
1517 organizes the required life-cycle processes in four categories: - cross
project, primary (software development process), secondary (such as configuration
management process, quality assurance process and project management process)
and Organizational. The last 3 processes are adapted from ISO 12207 and the
cross project category is added to accommodate software reuse. Domain engineering
is the only process categorized as a cross project process, where domain is
defined by IEEE 1517 as a problem space. Domain engineering covers the life
cycle of a product and provides the assets that can be used by the primary process.
So the process models that follow the bottom/up approach of software development
conform to the standards specified for component based software development
process. V-model and Y-model both conform to the standards defined for a reuse
based development process model.
THE STATE OF PRACTICE
Here, we present the state of practice. Initially we discuss some of the studies/experiences reported in the research literature. In the end of the section, we present findings of an investigation that we carried out to know the present practices followed in the software industry.
Li et al. (2009) did an empirical study on the
adoption of the component based development process by the software industry
boasting of reuse based development. The study analyzed 133 software development
projects from 127 companies. It is reported that there is a discrepancy between
academic theory and industrial practices regarding the use of components. Software
companies have not adopted any reused based process but adapted their traditional
processes to incorporate component integration related activities. In around
75% of the studied projects, development process was chosen in advance without
reuse in mind. Formal methods for component selection, evaluation etc., proposed
by researchers were not followed. Reasons given are that formal methods are
more time consuming; only a few components are available; developers use (select)
only those components which they themselves have already experienced with; company
have a long-term partnership with a specific component provider and lastly components
do not constitute important parts of the system. Mainly waterfall, waterfall
with prototyping and incremental mixed with prototyping processes are used.
Prototyping is used to negotiate a match between identified requirements and
In a pre study of this study (Li et al., 2006)
focused on Norwegian software companies, 16 reuse based projects were studied.
It was found that in all 12 successful projects out of the 16, developers were
making use of components that they were already familiar with and components
were selected in the initial phases. The remaining unsuccessful projects were
using top/down approach of software development i.e. components were selected
in the later phases.
Another experience is reported by Morisio et al.
(2000). The Flight Dynamics Division (FDD) at NASA/Goddard Space Flight
Center, is responsible for the development of large amounts of ground support
software for NASA satellites, In the 1980s and 90s, the FDD achieved effective
software reuse levels as high as 90%. This trend has gradually evolved into
COTS based software development. A study carried out by Software engineering
Institute, Carnegie Melon University, revealed that the process followed for
the projects at NASA is not Component based. Requirements are finalized first
and then suitable components are searched for. No formal component selection
method is being used.
Lastly we discuss the findings of a small study we carried out to know the reuse based development processes followed in the software industry. We randomly selected over 30 medium to large size software companies, both of national and international level. In order to collect the data, regarding the software development processes followed by the software companies, we studied the information published on their web sites. On the website, following types of hyperlinks pointed to the desired information:
process models followed in the software industry
A software company offers many services ranging from new product development
to product support or 3rd party integration. But we restricted our search to
new product development only. However, we could not find the process related
information from the website of every company, we visited. Only some of the
companies furnish this information explicitly.
Table 2 summarizes the data collected from the web sites of software companies. It is not surprising to find that waterfall model is still followed in the software industry. Waterfall model with prototyping for requirement analysis, spiral and classical V-model are used for traditional software development. To meet the shorter time-to-market constraints, RAD and agile methodologies are also preferred. Many software companies claim to follow reuse based approach. But it is not mentioned as to which reuse based development process, they use or have adapted to. We could not get any references to the process models discussed in this study except one. Only one out of the 30 companies studied, mentions V-model as the development process followed for reuse based development.
Service Oriented Architecture or web services are the next catchy words in the software industry after software components. Number of companies using SOA/web services is the maximum in this study.
For a reuse based solution, traditional development processes are not suitable.
Several activities, such as component search, evaluation, selection, adaptation,
which are important for a reuse based solution do not find any mention in the
key process areas of the traditional processes. Research community has put in
efforts to look for tools and techniques to realize reuse based solutions. But
these solutions are not as such adopted by the practitioners. As discussed,
a number of component based software development process models have been proposed.
Many of them also comply with the prescribed standards of a reuse based process.
Component selection is another important activity in a reuse based approach.
Many component selection methods have been suggested in the research literature
(Land et al., 2008). But studies of the industrial
practices reveal that a component selection method is seldom used. The reason
behind this academic-industry gap can be attributed to less number of empirical
studies on the proposed methods. Perhaps application developers are not convinced
with researchers proposals published in conference proceedings and journals.
Practitioners find the proposed processes as too lengthy and heavyweight to
deliver software in shorter time periods. In their opinion, more effort and
time is required to develop software using these formal processes.
While looking at information on the websites of software companies, it could
be realized that Service Oriented Architecture (SOA) is the buzzword now a days.
Service-Oriented Software Engineering (SOSE) is a software engineering paradigm
that aims to support the development of rapid, low-cost and easy composition
of distributed applications even in heterogeneous environments (Papazoglou
et al., 2007). It utilizes services as fundamental elements for developing
applications and solutions. SOA, a key element in SOSE, enables a collection
of services to communicate with each other. An emerging technology leveraging
use of SOA is Software as a Service (SaaS) in which the software users do not
purchase a software package but pay for its use through subscription (Olsen,
2006). As Brown et al. (2003) discuss, both
SOA and CBSE are complementary to each other. Rather than using these two technologies
in isolation, they should be integrated together to develop software systems
which are more predictable, dependable, dynamic and flexible (Brown
et al., 2003; Zhu, 2005). Collet
et al. (2007) propose that CBSD and SOA should be integrated to enable
some form of component based engineering of services.
Software process lays the foundation for a good quality product. A reuse based approach to software development requires a software process different from the traditional process. The reason behind this is that traditional processes cannot accommodate the risks that are associated with the use of reusable components. Several reuse based process models have been proposed in the literature and some processes confirm to the laid down international standards as well. But as far as the practice goes, a few projects, implementing reusable components, actually use the proposed reuse based development processes. 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. To start with Component quality is not given any consideration. Under the prevalent circumstances, it is further required to design a series of experiments, in which relative costs and benefits of choosing a component based process can be weighed against the choice of a traditional software development process. Taking up such studies will influence the developers decision regarding choice of the suitable development process.