Applying Agility To The
Parallel Software Development Lifecycle
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.
2 Overview of Parallel Development
This model was originally created to give ability to software development organizations
to be able to continue development for as long the product is in use. Parallel development
is the type of development in which there are four main processes (requirements,
development, quality assurance, and management), which are overlapped and executed
simultaneously and sequentially (shown in Figure 1).
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.
Figure 1: Parallel Model
3 Change of Requirements in Prescriptive Models
Introducing new requirements in the prescriptive models is highly undesirable and very
expensive. For example, the waterfall process handling of the changing requirements is
not advised as this model starts of with a well understood requirements document. There
is scope for going back to implement the changes however it will prove to be expensive
both with time and money wise. In the incremental model the iterations of linear phases
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.
4 Change of Requirements in Agile Models
One of the main attributes of the agile development models welcome change of
requirements, even late in programming - Extreme Programming (XP) for example. Since
the agile models in general develop working software frequently, the customer is able to
actively participate in development by analyzing the current release and deciding weather
or not it satisfies particular requirements. In case the customer introduces any new
requirements, those requirements are presented to the developers and are put in a
particular format (stories in XP, basic requirements in ASD, backlog – Scrum) and will
be implemented in the one of the next increments. All of the agile models continuously
build up by implementing new requirements to their working software products. These
requirements are used to create acceptance tests which next release has to pass. If the
story is changed after the acceptance test was created according to that story, then the
acceptance test also has to be changed in order to meet new requirement. Once the
current release passes acceptance tests, the process goes back to the start phase (planning
phase in XP, speculation phase in ASD, etc.) in order to produce the next increment. This
means that in agile models the software is developed in cycles. After one round of
requirements is satisfied and we have a working prototype ready to collect customer
feedback, the process goes back at the beginning of the cycle. Customer provides instant
feedback on the latest release by introducing, changing, modifying, or removing
requirements. The development team then reconsiders all remaining releases and
modifying its plan accordingly, so that set of new requirements is satisfied in the next
increments.
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.
5 Modifying Parallel Development
As earlier mentioned, the combination of more that one model is possible as a software
development model, but not all of the models can be implemented in some cases. In this
particular case, agile and prescriptive models are being considered for the implementation
in the parallel model. Since the prescriptive models assume that all of the requirements
are predefined, and approach software development as a linear process, it contradicts the
nature of parallel methodology where more than one process is executed simultaneously.
On the other side, agile and parallel model have more attributes in common, such as both
models can adopt new requirements and are able to continue with the development even
after the release of the product. The following section examines how the agility could be
implemented in the parallel model of software development, and what are the resulting
advantages and disadvantages.
6 Using Agility in the Parallel Development
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.
By having requirements’ specialists defining stories, developing units based on those
stories using XP, and at the same time performing integration testing, the development
time will be reduced. Documentation in this case will be eliminated, which will also
reduce development time and cost. Managerial interaction will also be reduced, but not
eliminated. The development team should still report the progress and other relevant
information to the managers; however the development team should operate
independently.
Requirements
Stories
XP Pairs
Develop &
Unit test
Integration Testing
Configuration Management
Management (limited supervision)
Figure 2: Parallel Model using XP
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.
6.1.2 Disadvantages of Applying XP to Parallel Model
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.
6.2 Releases and Prototyping in Parallel Development
In parallel system where the agility is being used, instead of dividing development phases
between teams, projects should be divided by related features into releases, and have one
team (or pair if using Extreme Programming) perform all phases for one release, while
other teams are working on the other releases. By implementing this fundamental of
agility to the parallel systems, there is less emphasis on maintenance, and is simply faster
and cheaper to reimplement successive versions rather than to maintain them. This ability
is very important if it is expected for the requirements to change.
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.
Rapid prototyping also improves customer-developer communication because it focuses
on an operational artifact. There are two main types of prototypes: design and production
prototypes. Design prototypes can help finalize requirements and design issues and are
discarded after the software is built. In the parallel development where agility is being
applied, design prototypes are not as needed since the emphasis is not on well defined
and understood requirements. Production prototypes are efficient enough to support live
operation. Component-based development is enabling the use of production prototyping
to rapidly develop production systems. Both types are very useful in defining and
understanding poorly defined requirements. Such problems arise in high-speed agile
development because users aren’t often sure what they want. Production prototyping
crystallizes requirements and reveals design issues, enabling customers to be involved
actively. Customers often find that position very awarding, and the development team
reaches the coding stage quickly. As the entire upcoming customer requirements are
being satisfied in the releases, by the time all requirements are defined, software product
is nearly finished.
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.
6.3 Customer Implementation
Customer implementation is a typical agile practice in which high speed development
teams often enlist customers or users either as full time or temporary, assigning them as a
part of the team. Its fundamentals are very similar to prototyping, but in this case
customer interaction is even more intense. As developers construct the software from
informally specified requirements and customer-developer discussions, customers
prioritize requirements and redirect development, release-by-release. In the addition to all
the advantages of the prototyping, customer implementation also helps to refine the
requirements. In the high-speed development requirements can also be changed because
of the evolving of market place and technology. This turbulence often leads developers to
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.
Beck, K. (2000). Extreme Programming Explained: Embrace Change. Boston: AddisonWesley.
McConnel, S. C. (1996). Rapid Development: Taming Wild Software Schedules.
Redmond: Microsoft Press.
Boehm, B. (2002, January). Get Ready for Agile Methods, with Care. Computer, 15(2),
64-69.
Pressman, R. S. (2005). Software Engineering: A Practitioner’s Approach. New York:
McGraw Hill.
8