JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617

HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 38

Component Driven Approach to Overcome

The Challenges in Software Development
Process
Rupinder Kaur, Jyotsna Sengupta

Abstract—In software process models, focus is on the activities directly related to development of software, such as
requirement analysis, design, coding and testing. As the software process models play a vital role in software development, it
really forms the core of the software product. Various software process models are proposed till now but the high failure rate in
software development has shown the need of new approach. This paper will present a new approach of software process
model, which deals with the various issues like changing requirements, quality, cost and time. This approach also helps in
managing each phase more efficiently.

Index Terms— Component driven development approach, development process model, stage model, process model.

——————————  ——————————

1 INTRODUCTION

T O solve actual problems in an industry setting, a

software engineer or a team of engineers must incor-
porate a development strategy that encompasses the
process, methods, and tools layers. This strategy is often
referred to as a process model. Process models specifies a
general process, usually as a set of stages in which a
project should be divided, the order in which the stages
should be executed and any other constraints and condi-
tion on execution of stages. Several process models exist
to streamline the development process, which provides
the framework to aid the software development. Software
product quality results from a combination of factors in-
volving not only the product being developed but also
the process that develops that product [14]. As Jaccheri
observe, software processes are highly complex activities
that affect critical factors such as final product quality,
time and costs, so process control is essential [12]. Soft-
ware engineering is seen as a fixed, standardized discip-
line that evolves slowly, and a view which is often reflect-
ed in the repetitious or redundant character of recent
software engineering methods.
One technique to improve the effectiveness of software
engineering would be to ensure that it dynamically
adapts to change. Tracking and monitoring change would
then become essential components of software engineer-
ing. An adaptive response to dynamic requirements that
adjusts according to changing environments can lead to a
better solution, which is lacking in present software
process models. This leads us to introduce the new soft-
ware process model, which is based on dynamic design
specification and development and scope for dynamic
testing during software development process. This ap-
————————————————
 F.A. Rupinder is pursuing PhD in Computer Science, Department of ciating testing activities with the analysis and design
Computer Science, Punjabi University Patiala.
 S.B. Jyotsna Sengupta is working with the Department of Computer phases [5]. This model had higher chance of success over
Science, Punjabi University Patiala.
© 2010 Journal of Computing Press, NY, USA, ISSN 2151-9617
http://sites.google.com/site/journalofcomputing/
proach is totally unlike CBSD (Component Based Soft-
ware Development) which is based on pre-built, stan-
dardize software components. The new approach pro-
vides the ground for new software development life cycle
model, which while implementing proven engineering
techniques. This will limit all the software development
risks to a component only, and provide the firmer control
over software development process.
The remainder of the paper is organized as follows: Sec-
tion II discuss existing models and techniques, Section III
presents new software process model, which will handle
dynamic requirements efficiently and has controller to
listing the details of components which are added due to
requirement changes or because of new requirements. In
Section IV we conclude and put forward the future work
directions.
2 BACKGROUND WORK
There are various different methods and techniques used
to direct the life cycle of a software development project.
The most influencing and initial process model was Wa-
terfall Model. It follows the linear sequence to software
development that begins at the system level and
progresses through analysis, design, coding, testing, and
support. The Waterfall Model was widely used because it
formalized certain elementary process control require-
ments. But it was not without problems, shortcomings of
the Waterfall Model included its lack of risk assessment,
fixed requirement, slow or unresponsive structure, and its
inadequacy for object orientation. Later the German de-
fense organization introduced a modified version of the
Waterfall in 1992 called the V-Shaped Model. This model
included validation and verification processes by asso-
the Waterfall Model due to the development of the test
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
plan but was very inflexible like Waterfall Model. Then,
demand for new method of developing system leads to
iterative development, in which project was divided into
small parts. Prototyping Model helps to understand un-
certain requirements but leads to false expectations and
poorly designed system. A popular variation of the Proto-
typing Model is called Rapid Application Development
(RAD). This model introduces firm time limits on each
development phase and relies heavily on rapid applica-
tion tools which allow for quick development [9]. Explo-
ratory model use the prototyping as a technique for ga-
thering requirements and was very simple in its construc-
tion but is limited with high level language for rapid de-
velopment. Lichter observed that prototyping reflects an
evolutionary view of software development [6]. It is close-
ly related to incremental development except that, in pro-
totyping, the development phase turn-around time is re-
duced by the quick development of a primitive version of
the product.
A number of Process Models evolved from the Iterative
enhancement (evolutionary) approach. They are characte-
rized in a manner that enables software engineers to de-
velop increasingly more complete versions of the soft-
ware. The incremental model combines elements of the
linear sequential model with the iterative philosophy of
prototyping. The incremental model applies linear se-
quences in a staggered fashion as time progresses. Each
linear sequence produces a deliverable “increment” of the
software [10]. Boehm proposed the Spiral Model, which
provides the potential for rapid development in a series
of incremental releases [2]. Risk analysis, which identify
situations that might cause a development effort to fail or
go over budget, occurs during each spiral cycle. In the
course of several papers, Boehm and his colleagues ex-
tended the spiral model to a variant called the Win–Win
Spiral Model [2], [3], [4]. The win–win stakeholder ap-
proach is used to determine three critical project miles-
tones that together anchor the development of the project:
namely, life-cycle objectives, life-cycle architectures, and
initial operational capability [1].
Agile process model give less stress on analysis and de-
sign. Implementation begins much early in the life cycle
of the software development. This process model de-
mands fixed time. Extreme Programming (XP) was
created by Kent Beck during software development, and
is based on iterative enhancement model. Like other agile
software development, XP attempts to reduce the cost of
change by having multiple short development cycles,
rather than one long one. It only works on teams of
twelve or fewer people [11]. Industrial Extreme Pro-
gramming (IXP) was introduced as an evolution of XP. It
is intended to bring the ability to work in large and dis-
tributed teams. It then supported flexible values [8].
There is not enough data to prove its usability.
These days, majority of the software development project
involve some level of reuse of existing artifact like design
or code modules. The component-based development
(CBD) model incorporates many of the characteristics of
the spiral model. It is evolutionary in nature, demanding
an iterative approach to the creation of software [13]. The
39
component-based development model leads to software
reuse, and reusability provides software engineers with a
number of measurable benefits. The unified software de-
velopment process is representative of a number of com-
ponent-based development models that have been pro-
posed. Using a combination of iterative and incremental
development, the unified process defines the function of
the system by applying a scenario-based approach [7].The
concentration is on object oriented development.
The literature has shown that engineers, researchers and
practitioners are still using the traditional process models
or combination of best features of different process mod-
els. But to manage the concern and challenges of modern
world, no approach or model for effective software de-
velopment is explicitly defined.
3 FUSION PROCESS MODEL
Fusion process model is based on component driven de-
velopment approach, where each component implements
a problem solving model. It includes the explicit
processes for technically analyzing the problem, solution
space analysis, alternative management, dynamic design
specification and development and scope for dynamic
testing. It implements the 3C-Model [15] on each stage or
phase, which assist fusion process model in generalizing
the process of solving the problems in each stage. It im-
plements component based development approach,
which provides a dynamic nature to complete software
development. Since it is component driven approach, the
risk associated with cost and time will be limited to com-
ponent only and ensure the overall quality of software
system, reduce the development cost and time by consi-
dering the changing requirements of customer, risk as-
sessment, identification, evaluation and composition of
relative concerns at each phase of development process.
The 3C-Model for each stage helps in mapping the real
world problems or requirement with technical problems,
and providing the best available alternative with the help
of complete background information gathered and con-
trolled using process like solution space analysis, mathe-
matical models and heuristics and optimization tech-
niques. The following section describes the various tech-
niques of implementation model in detail.
4.1 Problem Analysis and Alternate Generation
The control part of 3C-Modle performs this step where it
analyzes the actual problem, which arises due to client
requirements. This provides an understanding of the
client perspective of the software system. The next step
involves the technical problem analysis process in which
client requirements are mapped to technical problems
and solution domain is identified using solution space
analysis process. Technical Problem Analysis includes the
definition of the problems and the sub problems that
need to be solved. In the problem analysis process, tech-
nical problems are identified and structured into loosely
coupled sub-problems that are first independently solved
and later integrated in the overall solution.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
Extracting requirements of a desired software product is
the first task in creating it. This process is called require-
ments elicitation. While customers probably believe they
know what the software should do, it may require skill
and experience in software engineering to recognize in-
complete, ambiguous or contradictory requirements. Re-
quirement analysis process provides an understanding of
the client perspective of the software system. After re-
quirements elicitation, client requirements are mapped to
technical problems in the technical problem analysis
process. The problem analysis process consists of the fol-
lowing steps:
1. Generalize the Requirements: whereby the require-
ments are abstracted and generalized.
2. Identify the Sub-Problems: whereby technical problems
are identified from the generalized requirements.
3. Specify the Sub-Problems: whereby the overall technic-
al problem is decomposed into sub-problems.
4. Prioritize the Sub-Problems: whereby the identified
technical problems are prioritized before they are
processed.
Problem reduction is a strategic approach to manage
complexity. A widely known method for solving large
and complex problems is to split them into simpler prob-
lems and then iteratively apply this process. The process
is put into action until the sub-problems are reduced to a
level of complexity at which they are easily solved or at
least exhibit an irreducible level of difficulty. This para-
digm for solving problems is called problem reduction. In
this, a problem in a given domain is decomposed into a
structured set of sub-problems in the same domain. Each
sub-problem is evaluated for suitability to be further de-
composed until each sub-problem is determined solvable.
This problem reduction paradigm has been successfully
applied to problems in a variety of application domains
and in many phases of the process in which a top-down
decision making strategy is applicable.
The problem reduction can be expensive if not handled
properly. Often, the same process must be done repeated-
ly for a similar type of problem with only minor differ-
ences. As a result, problem reduction may cost even more
over time as problems become more complex. One impor-
tant approach of handling the side effects of problem re-
duction is to build reusable sub-problems and solutions,
instead of continually reinventing a related system reduc-
tive hierarchy. Such reusable sub-problems and solutions
can be stored in a components library and retrieved as
required. Complete solutions can then be obtained by
using and reassembling appropriate sub-solution compo-
nents.
The capture part of 3C-Model consist these concepts:
Need, Problem Description, Solution Domain Knowledge,
Alternative, Solution Description and Artifact.
 Need represents an unsatisfied situation existing in
the context (environment).
 Problem Description represents the description of the
40
problem.
 Solution Domain Knowledge represents the back-
ground information that is used to solve the problem.
 Alternative represents the possible alternative solu-
tions.
 Solution Description represents a feasible solution for
the given problem.
 Artifact represents the solution for the given need.
4.2 Solution Domain and Alternate Space Analysis
Solution Domain represents the background information
that is used to solve the problem and alternative space
represents the possible alternative solutions. It includes
the search for the solution space, and the complete back-
ground information required to solve the problems. In the
solution space analysis process, requirements are speci-
fied using some representation and this should be refined
along the software development process until the final
software is delivered.
The Solution Domain Analysis process applied in soft-
ware design phase aims to provide a solution domain
model that will be utilized to extract the architecture de-
sign solution. It consists of the following activities:
1. Identify and prioritize the solution domains for each
sub-problem
2. Identify and prioritize knowledge sources for each so-
lution domain.
3. Extract solution domain concepts from solution domain
knowledge.
4. Structure the solution domain concepts.
5. Refine the solution domain concepts.
The alternative space includes the alternative generation
and alternative evaluation of the defined solutions. This
can be defined as a set of possible design solutions that
can be derived from a given conceptual software architec-
ture. The alternative design space analysis aims to depict
this space and consists of the two sub-processes: define
the alternatives for each concept and describe the con-
straints. Let us now explain these sub-processes in more
detail.
 Define the Alternatives for each Concept- In this
approach the various architecture design alternatives
are derived from well-established concepts in the
solution domain that have been leveraged to the
identified technical problems.
 Describe the Constraints - The total set of alternatives
per concept may be too large and/or not relevant for
solving the identified problems. Therefore, to define
the boundaries of the architecture it is necessary to
identify the relevant alternatives and omit the
irrelevant ones.
4.3 Development Process Control
The development process in software engineering starts
with the need, while the goal is to arrive at an artifact
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
(output) by applying a sequence of actions. Since this may
be a complex process, the concepts and functions that are
applied are usually controlled. This is represented by the
Control part in the model. The controller observes va-
riables from the system, evaluates this against the criteria
and constraints, produces the difference, and performs
some control actions to meet the criteria.
 Mathematical Model represents a description of the
concept Alternative.
 Quality Criteria represent the relevant criteria that
need to be met for the final artifact.
 Constraints represent the possible constraints either
from the context or as described in Problem
Statement.
 Heuristics/Optimization Techniques represents the
information for finding the necessary actions to meet
the criteria and constraints.
4.4 Software Development Scope
Both the control and the problem-solving activities take
place in a particular context. Context can be expressed as
the environment in which software development takes
place including a broad set of external constraints that
influence the final solution and the approach to the solu-
tion. Constraints are the rules, requirements, relations,
conventions, and principles that define the context of
software engineering, that is, anything, which limits the
final solution. Since constraints rule out alternative design
solutions directing engineers into taking action on what is
doable and feasible.
The context also defines the need and may be very
wide and include different aspects like the engineer’s ex-
perience and profession, culture, history, and environ-
ment.
4.5 Domain Engineering
The phased model use domain analysis to identify do-
mains, bounding them, and discovering commonalities
and variability’s among the systems. This information is
captured in models that are used in the domain imple-
mentation phase to create artifacts such as reusable com-
ponents, a domain-specific programming language, or
application generators that can be used to build new sys-
tems in the domain. A key idea in systematic software
reuse is the domain, a software area that contains systems
sharing commonalities.
4 CONCLUSION
We have presented a Fusion Process Model for software
development process and discussed the concept of 3C-
Model for each phase of development process model. In
this approach transformation of a problem specification
to a solution is made by decomposing the problem into
sub-problems that are independently solved and inte-
grated into an overall solution. This process consist of
multiple cycles, were each cycle transform from problem
specification state to design state. After each state trans-
formation, a sub-problem is solved and a new sub-
problem possibly be added to the problem specification
41
state. Every transformation process engages an evaluation
step, evaluation of design state with the initial require-
ments is done and verifies if additional requirements
identified during this step. In particular, this process in-
cludes an explicit phase for searching design alternatives
in the corresponding solution space and selecting these
alternatives based on explicit quality criteria. Our work
has shown that how this approach helps in controlling the
overall development process by implementing compo-
nent based approach. Since it is component driven ap-
proach, the threat tied with cost and time will be re-
stricted to component only, ensuring the overall quality
of software product, considering the changing require-
ment of customer, risk assessment, identification, evalua-
tion and composition of relative concerns at each phase of
development process.
REFERENCES
[1] Barry Boehm, “Anchoring the Software Process”, IEEE Transaction on
Software Engineering, pp. 79-82, July 1996.
[2] B.Boehm, “A Sprial Model of Software Development and Enhancement”,
IEEE Computer, Volume 21, Issue 5, pp. 61-72, 1988.
[3] B.Boehm and D.Port, “Escaping the software tar pit: model clashes and
how to avoid them”, Software Engineering Note, Volume 24, Issue 1, pp. 36-
48, 1999.
[4] B.Boehm and P.Bose, “A Collaborative Spiral Software Process Model
Based on Theory W.Processing of ICSP”, 3, New York: IEEE Press, 1994.
[5] Fadi P. Deek, James A.M. McHugh and Osama M. Eljabiri, “Strategic
Software Engineering an Interdisciplinary Approach”, Auerbach Publica-
tions, pp. 11-35, 2005.
[6] H.Lichter, M Hufschmidt Schneider,and H. Zullighoven, “Prototyping in
industrial software projects”, IEEE Trans. Software Eng., 20(11), pp. 825–832,
1994.
[7] I. Jacobson, G. Booch, and J. Rumbaugh, “The Unified Software Develop-
ment Process”, Addison-Wesley, 1999.
[8] Joshua Kerievsky, “Industrial XP: Making XP Work in Large Organiza-
tions”, vol. 6, issue 2, Cutter Consortium Agile Product and Project Manage-
ment.
[9] J. Martin, “Rapid Application Development”, Prentice-Hall Publication,
1991.
[10] J. McDermid and P. Rook, “Software Development Process Models,” in
Software Engineer’s Reference Book, CRC Press, pp. 15/26–15/28, 1993.
[11] Kent Beck, “Extreme Programming Explain: Embrace Change”, Addi-
son-Wesley, First Edition-1999, Second Edition- 2004.
[12] M.L.Jaccheri,G.P. Picco, and P. Lago, (1998). Eliciting software process
models with the E3 language. ACM Trans. Software Eng. Methodol, Vo-
lume7, Issue 4, pp. 368–410, 1998.
[13] O.Nierstrasz, S. Gibbs, and D. Tsichritzis, “Component-Oriented Soft-
ware Development,” CACM, vol. 35, no. 9, pp. 160–165, September 1992.
[14] R.S.Pressman, “Software Engineering: a Practitioner’s Approach”,
McGraw–Hill Publication, Fourth Edition, 1996.
[15] Rupinder Kaur and Jyotsna Sengupta, “Development and Analysis of
3C-Model for Software Development Lifecycle”, IEEE 2nd International
Conference on Computer Engineering and Technology (ICCET 2010), Vo-
lume 6, April 16 -18, Chengdu, China, 2010.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 42

     
Project  Software  Realization  Testing  Go Live and 
Preparation  Blueprint  Support 

Fusion Process Controller

Fig. 1. Fusion Process Model