Professional Documents
Culture Documents
Senad Cimic
Computer Science Department
North Dakota State University
1301 12th Avenue North - Fargo, ND 58105
senad.cimic@ndsu.edu
Abstract
In this paper we take a closer look at one of the largest problems in the software
development processes – ability to adopt changes in the requirements at any stage of
development. Although parallel software development is designed to satisfy these
requirements, some of the problems still remain. The idea of applying some of the most
widely used software development models (such as agile and prescriptive models) to the
parallel model in order to make it more suitable for ongoing development and to increase
speed of development is introduced.
1 Introduction
In the software development world, software development organizations need to choose
which software methodology is going to be used when developing a software product. All
of the common methodologies have their advantages and disadvantages when it comes to
process management, adopting changes in requirements, ability in going back to previous
steps of development without major problems, etc. In this paper we, will compare the
characteristics of some of the most widely used software development methodologies
(agile and prescriptive models) and decide which one could be implemented in the
parallel model in order to improve it. These two models differ in many ways, and the
application of both models in certain cases may be impossible.
One the major challenges in the software development lifecycle is the change in the
requirements. In certain projects where requirements are not 100 percent defined, most
likely at some point of the lifecycle, some requirements may get changed or new ones
could be introduced. To satisfy this assumption that software development is ongoing
process, a new model has been introduced – Parallel Process Development Lifecycle
(discussed in next section).
When choosing which software development model to follow, organizations are not
limited to using a single model at the time, but instead two or more models can be
combined. Because of the problem of ongoing development, even after the release, and
the problem of having tight deadlines for release, we examine if some of the commonly
used methodologies could be applied in the parallel development in order to improve the
ability of modifying product in any stage and increasing the speed of development. The
following sections overview the characteristics of parallel model and compare agile and
prescriptive models when dealing with the problem of ongoing change in requirements.
Requirements are the process of gathering required features from end users and
determining technical requirements under which the software must operate. Solution
Development is the process of design, implementation, and unit testing of the delivery
software. In this model coding often begins while requirements are still unsettled. The
Quality Assurance process is involved in the selection of criteria for acceptance as well as
the techniques for testing. This process also includes the actual testing and quality
assessment of the software product to deliver. Management is concerned with making
sure the appropriate resources are available and well utilized in order to complete the
production of the software product.
1
Parallel Software Development also identifies two additional parallel lines that exist in
addition to the above mentioned four lines of activities: Configuration management and
documentation. Configuration management in software development is defined as, “set
of activities designed to control change by identifying the work products that are likely to
change, establishing relationships among them, defining mechanisms for managing
different versions of these work products, controlling the changes imposed, and auditing
and reporting on the changes made,”(Pressman, 2005). Configuration management in
Parallel Software development is no different than other software development lifecycle
methods. It aims to control and manage change in a software development project.
Documentation in a software development project is likewise similar to all other software
development lifecycle methods where information that either needs to be shared
internally with other teams or externally with the end users is written down and kept and
ultimately should be under configuration management in order to track the changes in the
document artifacts created during the software development project.
2
are compromised. Even though the requirements are well defined, the product is
delivered in iterations and hence addition of functionality is possible, but limited. Rapid
Application Development (RAD) emphasizes a short development cycle. It is high speed
adaptation of waterfall model. Communication, planning and modeling serve as basis for
the construction activity. Different RAD teams work on different modules and hence to
combat to the changing requirements proves to be costly affair. There are also some
proscriptive models that provide more functional and inexpensive way to deal with this
problem. For example, prototyping model assists the customer and the software engineer
to better understand what to build when requirements are fuzzy. The prototyping iteration
is planned quickly and modeling occurs. The customer feedback is used to refine the
requirements for the software. Ideally, the prototype serves as a mechanism for
identifying software requirements.
Overall, the agile methods really prove to generally deal better with changing
requirements than the prescriptive methods. However, some prescriptive methods such as
prototyping can also introduce new or changed requirements very sufficiently. In all of
those methods that resolve this problem, customer involvement is intense and continuous.
This means that the customer is present on development site and works together with the
team in specifying requirements during whole development, or customer is provided with
some kind of working product (prototype, increment, etc.) and gives his/her feedback.
3
The philosophy in this case is simple – the more the customer is involved the more
current requirements the product will satisfy.
6.1 Implementation
The main question when applying agile concepts to any model is which concepts should
be applied and where? The agile method that will be applied to the Parallel Model will be
XP.
The Requirements process will remain same – there will still be requirements specialists
closely working with customers in defining customer and technical requirements.
However, instead of placing requirements in the requirements specification documents
they should be separated in smaller pieces (in shape of stories), which would be passed to
the development teams. After the prototypes are released, they would be evaluated from
the customers’ side, meaning that elicitation techniques would expand into the
development.
XP model substitutes documentation with working models, and gives the developing
team control of its own destiny. In order to successfully implement XP in the parallel
process, managers should give more freedom to the developers, and there should be no
emphasis on the documentation, but on prototypes (working software) instead.
In the development process the XP fundamentals will also apply. There will still remain
design, coding, and unit testing for each story, but instead of having developers working
directly with customer developers will receive finished stories describing what needs to
be implemented. Developers will work in pairs that would be changed frequently, and as
4
their code passes the unit tests, it will be passed to Quality Assurance phase for
immediate integration testing, and pair shall receive another story to work on.
Quality assurance will also mostly remain unchanged. In the agile development,
prototypes are usually released about every two to six weeks, and therefore before every
release the prototype should pass the integration testing before presented to the
customers. Using the parallelism would mean that the integration testing starts together
with the development. The demand of parallel development that prioritize team to find
and fix defects, completing essential features and fixes immediately and postponing less
essential ones will still be satisfied by using agility. Because of this, software
development is broken into smaller projects, each with small requirement set and a short
development cycle, for which the agile methodology could be applied.
Requirements
Stories
Integration Testing
Configuration Management
The figure above shows the simplified result when XP is applied as discussed to the
Parallel Model. Development is done in cycles, while other three main processes remain
linear. Documentation is eliminated, while the Configuration Management remains, but
the working software is primarily used in this process.
5
6.1.1 Advantages of Applying XP to Parallel Model
One of the most obvious advantages of applying XP in discussed model is the ability to
change or introduce requirements during the whole process. Since the documentation is
eliminated and management control reduced, the personnel number is reduced bringing
the cost down.
Another major advantage is increasing the speed of the whole process. Because code is
being integrally tested as delivered to Quality Assurance, the product is virtually finished
when all the requirements are gathered from the customer (since those requirements are
immediately processed and implemented).
By having developers work in pairs that are frequently changed, the knowledge of
individuals is spread among other team members. Because of this, developers’
performance improves at higher paste.
Since the development team is given freedom and responsibility in this model, the
emphasis has to be on the motivated and qualitative individuals that should be able to
also perform certain managerial tasks, which is not always the case. Managerial role is
reduced, and therefore managing the whole process is a hard task.
Eliminating documentation also has negative side effects. Creating new software based
on the existing one that was created using this model would become extremely difficult
because there is no documentation, but prototypes instead.
The other advantage of using this approach is satisfying the demands of time-to-market
compression. In competitive software market the products are pushed out the door as
soon as possible. Those products need to be faster and with higher quality than their
earlier versions, and rapidly releasing prototypes in parallel development enables rapid
introduction of new features because it is highly responsive and adaptive. Because of this,
an organization can dynamically reprioritize requirements according to the current needs
6
and delicately slip features that prove to be problematic without holding up other critical
functions.
When the agility is applied to the parallel development developers can’t rely on a formal
specification and are capturing requirements only informally in user stories, which can
cause production prototyping to be costly. It can involve a fair amount of rework in
changing operational software systems to match shifting customer needs. Prototyping can
also lead to larger than needed focus on user interface, giving short attention to important
computational aspects. Critical requirements like security, scalability, and robustness are
hard to appraise through prototyping.
One of the other disadvantages of the constantly releasing prototypes with new features is
that users might need additional training in order to be able to use new functionalities.
Another drawback is that large, complicated revisions are nearly impossible to
contemplate. The limited scope of requirements might lead to scalability problems, e.g.
many small components could introduce overhead that becomes overwhelming at high
volume.
7
avoid formally documenting requirements, because they see such activity as unnecessary
overhead. Detailed requirements analysis delays the development team’s response to
rapidly changing market conditions. Also, when using this approach in parallel
development, the customer is privileged. Developers receive an instant feedback on
creative new features. The approach also rapidly moves the latest customer needs into the
system, which prevents the risk of building yesterday’s systems for tomorrow.
The disadvantages of the using customer implementation are similar like in prototyping;
it is assumed that users know what they want, but it is rarely the case. Many customers or
users do not think consistently and systematically about their day-to-day problems.
Because of this, developers must routinely bound customer requirements against the
quality that the delivered product can achieve.
7 Summary
In this paper the possibility of applying agile methodology to the parallel development in
order to increase ability of developing product before and after its release was discussed.
Agile methods such as XP and parallel model can easily be implemented together,
because their emphasis is on the same thing – being able to adopt new requirements.
Some of the common used agile methods such as customer interaction in the incremental
software releases can also be used in the parallel software development. By implementing
XP model to the parallel model, the development process would use the fundamentals of
parallel model (having more than one process executed at a time) and use discussed XP
fundamentals which would reduce the cost and increase the speed of the development.
The most important problem of being able to adopt changes in any stage of development
is also resolved.
References
Baskerville, R. & colleagues (2003). Is Internet-Speed Software Development Different?
IEEE Software, 20(6), 70-77.
Boehm, B. (2002, January). Get Ready for Agile Methods, with Care. Computer, 15(2),
64-69.