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 usedin 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 cross- functional 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 two-month 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 Languagedeveloping 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-size-fits-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 .