AGILE SOFTWARE DEVELOPMENT PROCESSES :
RUP,CRYSTAL
Abstract
In software development there exists a tension between quality, cost,
and time .Today’s mainstream software processes do not effectively
address the two major questions of cost and time .Many traditional
software processes are top heavy with documentation and rigid control
mechanisms making it difficult applying them to different software
projects. New families of processes, referred to as Agile Processes, are
making headway into the software industry. These processes focus on
code rather than documentation calling themselves agile because,
unlike the traditional processes, they are adaptable, not rigid. This
paper discusses two of these Agile Processes namely RUP(Rational
Unified Process) and Crystal, the implementation and the challenges.
Introduction
For many years in the past software has been a part of the society and so have
software development processes .The field software developments has introduced
several methodologies of which only a few survived to be used today. A recent study
claims that traditional software development methodologies are too mechanistic to be
used in detail. As a result industrial software developers have become skeptical about
“new” solutions that are difficult to grasp and thus remain not used .This lead to the
emergence of agile software development methods.
Agile Software Development is an emerging philosophy producing new processes
which effectively address the two prevailing questions of cost and time. The new
processes focus more on people interactions and early development of code than on
documentation and planning.
This paper discusses Agile Software Processes .The paper begins by exploring
Agile Process Philosophy followed by overview of two agile processes RUP ( Rational
Unified Process) and Crystal .The challenges associated with implementing agile
processes are presented and the paper concludes with a summary concerning that though
Agile Processes are valuable they are not a panacea capable of solving all problems with
software design and development.
Agile Process Philosophy
The pressures introduced by the rapidly changing markets introduce pressures into the
software industry requiring them to be as adaptable as the markets to which products are
used. Agile Software development philosophy has it roots in the reality of today’s
markets. The emergence of agile software processes attempt to deal with the issues
introduced by rapidly changing and unpredictable markets. Reading the “Manifesto for
Agile Software Development” the basic ideas of the philosophy are introduced through
four basic values:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan.
These central values that the agile community adheres to are:
First, the agile movement emphasizes the relationship and communality of software
developers and the human role reflected in the contracts, as opposed to institutionalized
processes and development tools. In the existing agile practices, this manifests itself in
close team relationships, close working environment arrangements, and other procedures
boosting team spirit.
Second, the vital objective of the software team is to continuously turn out tested working
software . New releases are produced at frequent intervals, in some approaches even
hourly or daily, but more usually bi-monthly or monthly. The developers are urged to
keep the code simple, straightforward, and technically as advanced as possible, thus
lessening the documentation burden to an appropriate level.
Third, the relationship and cooperation between the developers and the clients is given
the preference over strict contracts, although the importance of well drafted contracts
does grow at the same pace as the size of the software project. The negotiation process
itself should be seen as a means of achieving and maintaining a viable relationship. From
a business point of view, agile development is focused on delivering business value
immediately as the project starts, thus reducing the risks of non- fulfillment regarding the
contract.
Fourth, the development group, comprising both software developers and customer
representatives, should be well-informed, competent and authorized to consider possible
adjustment needs emerging during the development process life-cycle This means that
the participants are prepared to make changes and that also the existing contracts are
formed with tools that support and allow these enhancements to be made.
The values derived from the philosophy of agile processes serve to manage
change and reduce cost. Co-located teams working together producing code instead of
high maintenance documentation can help to increase productivity. Furthermore by
extending the team’s technical decision making capabilities and granting them continuous
access to business expertise both internal and through the use of on sight customer
participation the code being produced will better reflect the true requirements of the
customer. Finally, instead of enforcing a rigid plan using predictive process
methodologies with rigid and unchanging requirements embrace change; recognize it is
part of today’s business climate and work to handle the changes as they occur. Doing this
does not mean that there will be a bunch of coders creating chaos with no regard to
processes. Agile processes are rigorous requiring a lot of hard work to make them
successful.
Agile Processes
There are many variations of agile processes this paper provides an overview of
two of the most popular ones used today. This paper introduces Crystal and the Rational
Unified Process (RUP) to the reader.
Crystal
Crystal is a family of processes each applied to different kinds of projects. Crystal
approach includes principles for tailoring the methodologies to fit the varying
circumstances of different projects . The idea of having multiple processes stems from the
thinking that some projects require fewer rigors than others do. Small and non-critical
projects can be developed using less rigorous Crystal methods. Larger and more critical
projects, however, demand more attention and therefore, a more rigorous Crystal process
used.
Selecting a Crystal process requires that a project be matched to one of four
criticality levels.
• Comfort
• Discretionary money
• Essential money
• Life A system failure for the first
Criticality level C indicates that a system crash due to defects causes a loss of comfort for
the user whereas defects in a life critical system may literally cause loss of life.
Each of the processes shares common policy standards.
• Incremental delivery
• Progress tracking by milestones based on software deliveries and major
decisions rather than written documents.
•Direct user involvement .
• Automated regression testing of functionality
• Two user viewings per release
• Workshops for product and methodology-tuning at the beginning and in the
middle of each increment.
Crystal Clear and Crystal Orange are the two family members that have been constructed
and used .Crystal Clear is designed for very small projects comprising upto six
developers .Crystal Clear should be located in a shared office space due to the limitation
in its communication structure.
Crystal Orange is designed for medium sized projects, with a total of 10 to 40 project
members, and with a project duration of one to two years .In Crystal Orange the project is
split up for several teams with cross-functional groups . It emphasizes the importance of
the time to market issue.
One Crystal Orange Increment
All Crystal methodologies involve a number of practices, such as incremental
development . The increment of a Crystal Orange includes activities such as staging ,
monitoring , reviewing ,along with parallelism and flux.
Monitoring
The progress is monitored regarding the team deliverables during the development
process with respect to their progress and stability.Monitoring is required in both Crystal
Clear and Crystal Orange.
Parallelism and flux
Once the monitoring of stability gives the positive result for the deliverables the next task
can start. In Crystal Orange this means that the multiple teams can proceed with
maximum parallelism successfully.
Holistic diversity strategy
Crystal Orange includes this method for splitting large functional teams into crossfunctional groups. The central idea of this is to include multiple specialities in one team
User viewings
Two user viewings are suggested for Crystal Clear per one release. In Crystal Orange ,
user reviews must be organized three times for each increment.
Methodology tuning technique
It is one of the basic tuning techniques for Crystal Clear and Orange. It uses project
interviews and team work shops for working out a specific Crystal methodology for each
individual project.
Staging
Staging includes the planning of the next increment of the system. It should be scheduled
to produce a working release in every 3 to 4 months at the maximum. The team selects
the requirements to be implemented in the increment and schedules what they feel they
are able to deliver.
Revision and review
Each increment includes several iterations. Each iteration includes the following
activities: construction, demonstration and review of the objectives of the increment.
While each of the Crystal processes share the standards the rigor involved is dependent
on the project and the chosen process. For example, less critical projects suggest twomonth incremental delivery time spans whereas critical projects, demanding a rigorous
process, may extend time-to-delivery increments to a maximum of four months. Projects
are comprised of multiple increments . Crystal processes define the functions contained
in an increment.
The functions or practices are explicitly defined. Staging, this is the scheduled
time frame for one increment ranging from one to four months duration. Increments
include several iterations during which construction, demonstration, and reviews are
included activities. Iterations are monitored and team deliverables gage the progress and
stability of an iteration. User viewings, (i.e. reviews by users), are conducted one to three
times per iteration depending on the criticality of the project. Methodology-tuning is a
basic technique used to fix and improve the process applying knowledge gained in one
iteration to the next iteration. In addition to the methodology-tuning workshops there are
reflection workshops conducted at the start of an increment and midway into it.
The multiple processes offered by the Crystal methodologies are adaptive and
agile. They are adaptive because they offer multiple solutions for projects having
different criteria. They are agile because they deliver work products at the completion of
each project increment and are able to apply lessons learned to the next iteration.
Additionally, they demand customer involvement, and decisions are made based on
outcomes rather than trying to force conformance to a plan developed early in a project’s
phase.
Rational Unified Process
The Rational Unified Process, (RUP), is a generic process framework that uses a
specific methodology to accomplish the tasks associated with it. The RUP uses the
Unified Modeling Language developing use cases for the software system design. The
nature of its versatile framework is something that different organizations can apply to
different applications using people with different skill levels working on projects with
varying levels of complexity. How it is used depends on the environment and how the
project chooses to tailor it.
In its most simple form its workflows mimic classic BDUF waterfall processes.
Gain knowledge of your customer’s business, translate the business needs into a set of
requirements, do analysis and design creating the software architecture, implement the
design and test it extensively prior to delivering it to the customer. These attributes are
core to RUP’s framework. The core attributes are applied to four unique phases occurring
over the life cycle of a RUP project.
The RUP framework
The RUP framework is organized around several simple interconnected concepts [4]:





It defines process roles, which capture the competence, skills, and responsibilities
that individuals taking part in the development may be called to play.
It describes the work that each role performs in activities, decomposed into steps.
These activities operate on concrete artifacts: models, code, documents, and
reports.
There is a wealth of associated guidance for the roles, activities, and artifacts, in
the form of guidelines, templates, examples, and tool mentors, which explain how
to perform a certain activity with a given tool.
All these process definition elements are organized into disciplines
Adapting the RUP
The RUP is neither a dogma nor a religion. The RUP does not define a rigid, "one-sizefits-all" recipe for software development. No, you do not need a minimum of 40 people to
fulfill the 40 roles, and you do not need to develop over a hundred different artifacts. You
could quickly get into trouble if you were to try this. These process elements are defined
in the RUP and provided in electronic form to provide the flexibility you need to adapt
the process you want to use to the demands of your specific development environment.
The RUP embodies many proven software development practices. Six have been made
more visible:






Develop iteratively.
Model visually.
Manage requirements.
Control changes.
Continuously verify quality.
Use component-based architectures.
Additionally, the RUP is based on other key principles that are less visible and more
easily forgotten. To mention only a few:








Develop only what is necessary.
Focus on valuable results, not on how the results are achieved.
Minimize the production of paperwork.
Be flexible.
Learn from your mistakes.
Revisit your risks regularly.
Establish objective, measurable criteria for progress.
Automate what is human intensive, tedious, and error prone.


Use small, empowered teams.
Have a plan.
A key concept in adopting and adapting the RUP is the development case. A development
case is a tailored project-specific instance of the RUP. This process description defines
and identifies, by reference to the RUP framework:







What will be developed
Which artifacts are really needed
Which templates should be used
Which artifacts already exist
Which roles will be needed
Which activities will be performed
Which guidelines, project standards, and tools will be used
Producing a development case
The development case is usually produced by:




Selecting relevant elements in the RUP framework
Eliminating unnecessary process elements
Adding any missing company-, domain-, or technology-specific elements
Tailoring some elements to the precise project context
As the project unfolds, the development case captures some of the lessons learned by
evolving itself in parallel with the software product being developed. Often guidelines or
checkpoints for reviews are added to avoid repeating mistakes. The project evolves not
only the software it produces, but also its own ability to develop that software.
In many cases, the development case is produced by referring to the generic RUP, but
you can also create and deploy an instance of the RUP; that is, a configuration of the
RUP that is tailored to your own needs. A development case is not necessarily a big
document
Iterative Development
Of the six best practices embraced by the RUP, the one that has the greatest impact on
process agility is iterative development.
The RUP describes a versatile development lifecycle with four phases (inception,
elaboration, construction, and transition), each one with specific objectives. Inside these
phases, development proceeds in small iterations: design a little, build a little, and test a
little. It is a spiral process .
Building the software product incrementally not only allows for early risk mitigation,
making tactical changes, and managing scope, but also fine-tuning the process itself:
adjusting the development process, guidance, activities, and artifacts as you learn from
previous iterations. So an initial development case is likely to evolve during the
development cycle. This is done after each iteration by reflecting on what has worked,
what has not worked, and how the organization and the process can be improved.
Iterative development provides an ideal setting for a software process improvement
process.
Iterative development requires some careful planning. The development case is only one
facet of that planning, which must be done not only for the whole cycle, but also for each
iteration. The project plan, revisited at each iteration, must reflect the instantiated process
and explicitly define everyone's roles and activities. The mapping of roles to individuals
embodied in the plan means that not everyone would have to know everything about the
RUP.
The organization and the project complexity drive the iterations. Organizations could use
RUP in its most simple configuration, one iteration for each phase, creating a waterfall
style process or use it in a more agile manner creating multiple iterations, having lengths
of one to two weeks. Ultimately, “the goal of each iteration is to develop some working
software that can be demonstrated to all the stakeholders, and that the stakeholders will
find meaningful.”
Each phase iterates through each workflow while the project lifecycle moves
through the phases. Inception is concerned with gathering requirements and putting
together the project plan. During elaboration the software architecture is defined and the
detailed plan for future iterations is established. During Construction the software system
is built and tested and the user documentation is completed. Finally, the Transition phase
closes the project and delivers the product to the customer.
RUP is tailored according to an organization’s culture and by project complexity
making it highly versatile. It uses defined workflows to complete its work products and
has four phases defining the process life cycle. In many ways it resembles a classic
waterfall styled process, however, because of its versatility it is generally tailored for use
as an agile software .
Conclusion
Agility is the ability for an organization to adapt and react expeditiously and
appropriately to changes in its environment and to the demands imposed by the
environment. An agile process is one that readily embraces and supports this kind of
adaptability.
While not a panacea, agile processes can help an organization to better compete in a
volatile and rapidly changing market by helping to deliver high quality software at a
competitive price and in a timely manner to a market moving at blinding speed
The Rational Unified Process contains the guidance necessary to adapt its framework to
the initial project environment and to evolve it as a project unfolds. The RUP framework
provides this agility by offering a wealth of process guidance to choose from, which
prevents having to reinvent process and accommodates a larger scope of situations. A
great part of the RUP's agility is derived from its iterative approach, which provides
many feedback loops and opportunities to make ongoing tactical changes to evolve the
process.
References:
Bibliography
Extreme Programming Explained First Edition; Beck, Kent; Addison-Wesley Publishing
Co.1999
Webliography
Crystal Methodologies; http://crystalmethodologies.org/
Rational Unified Process(RUP) ; http://www.cutter.com/