Software Engineering Management: Unified Software Development Process and Extreme Programming

Table of Contents

Introduction
Agile methodologies
The agile manifesto states
Unified Software Development Process (USDP)
USDP (RUP) v/s XP
Recommendations
References

The document is a brief report on Unified Software Development Process (USDP) and Extreme programming (XP) methodologies, critically comparing them to check their suitability to deliver increased efficiency and quality to the software projects and how well they support effective cost estimation, project planning, risk management and testing.

Introduction

There have been considerable issues in managing the software development process for the web applications and systems integration projects completed recently. This has increased the need for adopting a suitable software development methodology keeping in mind the issues faced in past projects and constraints under which the projects need to be developed.

Some of the common issues have been costs exceeding the budget, inability to respond quickly to changes, inappropriate management and short timelines leading to low quality output. This report aims to provide information on two methodologies Unified Software Development Process and Extreme Programming.

Of particular interest is how these methodologies help increase productivity and quality of the software while helping in arriving at effective cost estimates, project planning, risk management and testing. Another important factor to consider is that the methodology should be effective to implement even with a small team size.

Agile methodologies

Traditional software methodologies like waterfall method do not work unless the requirements are known upfront. Waterfall method requires following a rigid pre-planned schedule and is averse to changes. Also, client only comes into the picture after the software is delivered which can lead to massive changes in the development if there has been any miscommunication.

However, unlike accounts software for example where most requirements are known upfront, requirements of most other applications may not be known to the customer and evolve as the development progresses. Agile software development methodologies based on iterative/incremental approach works in such circumstances as it allows the stakeholders to participate in the development and also supports changes.

Agile methods usually involve breaking the project into small increments and developing minimal plan for the current increment rather than doing any long-term planning.

Each iteration goes through a full software development life cycle beginning with planning, requirements analysis, design, coding, and testing post which the stakeholders can see a working product. Changes can be suggested and incorporated in the next iteration. Agile methods are usually employed for time-critical applications.

The agile manifesto states

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

(Source: Cunningham, W. (2001) Manifesto for Agile Software Development [online]

Agile methods consider customer satisfaction at highest priority through frequent delivery of software with shorter timescale. It supports changes in requirements. Collaboration between business and development team, team empowerment, face-to-face conversation, simplicity, self-organizing teams and regular progress meetings are encouraged. The primary measure of progress is a working software.

Extreme Programming and Unified Software Development Process are two agile software development methodologies. (Cunningham, 2001)

Extreme Programming (XP):

Based on observations of what helped speed up or slow the programming activity, Extreme Programming or XP, an agile methodology, was designed. XP overcomes the weaknesses of traditional software methodologies as well as helps reduce costs (Wells, 1999). It is a lightweight methodology with fewer rules making it easier to follow. XP stresses on customer satisfaction and team work and helps improve software development through communication, simplicity, feedback and courage (Beck, 2000):

Regular communication with customers and peers
Simple and clean design
Testing (and therefore, feedback) from day one
Respond courageously to changing requirements and technology

The name comes from the fact that XP takes common practices to extreme levels. For example, since code reviews are considered common sense practices in software development, XP requires reviewing code all the time through pair programming. Testing, simple designing, refactoring, and integrating all happen more frequently than in other methodologies. (Bhattacharjee, n.d.)

Some of the rules and practices of XP are:

Create user stories
Frequent small releases
Iterative development
Daily meetings
Simple design
Refactoring (removing duplicate code)
Follow coding standards
Constant communication with customer
Create unit tests code first
Pair programming one developer does the coding while another reviews the code
Frequent integration
Collective code ownership
Optimization at the end
Code must pass unit tests before release
New tests are created for bugs found post release
Frequent acceptance tests

(Source: Wells, 1999; Beck, 2000)

XP is considered to be more effective for small-to-medium sized teams although large teams also benefit from the same. XP is mainly used when the requirements are not well-known or when there is a possibility of frequent changes in requirements. (Wells, 1999; Beck, 2000 and Bhattacharjee, n.d.)

Cost estimation is based on the user stories that are created at the start of the project. User stories are written by the customers in laymen terms and are easy to understand. They are used instead of large requirements document. They ideally provide only enough detail to be able to make a reasonably low risk completion time and cost estimate. (Well, 1999 and Goebel, 2003)

XP requires working in iterations with planning done right before the beginning of iteration. In other words, there is no plan for the entire project that one can stick to. Since XP expects and embraces changes in requirements, complete plans wouldnt work well either. However, each iteration is run like a small project and follows the typical project management methodologies.

Daily meetings and communication amongst stakeholders (specifically customers and developers) help keep everyone in the loop and provide a plan for now.

Although the team does aim to complete as per the initial estimates provided, there are chances of the user stories taking longer than expected or scope changes coming as a result of better understanding of the system during an iteration that lead to increase in time and cost estimates. (Goebel, 2003)

This can be controlled by ensuring that user stories are selected based on the value it provides to the customer as well as the time and cost estimates provided by the developers thereby creating an environment of shared responsibility. (Goebel, 2003)

Also it is worth noting that any user story that takes more than 2-3 weeks (depending on timeframe decided for each iteration), requires to be split further so that no user story requires more than 2-3 weeks of time to implement. (Wells, 1999)

The principles of XP help mitigate or avoid some of the risks common to software development projects. For example, XP works on the concept of iterations. At the end of iteration, there is a release to the customer which helps get early feedback and generates lesser rework than it would be if the customer got to see the product at the end of the development cycle.

While early releases could mean earlier generation of return-on-investment, it can also help provide a warning sign in case a project is in trouble and needs to be adjusted for time, cost or perhaps scrapped altogether. Pair programming and Collective Ownership help mitigate the problems associated with resources such as attrition, moving resources between projects, non-availability of resources due to other projects or leave, etc.

Continuous integration also helps early resolution of integration issues that would otherwise crop up at the end, thereby reducing the chances of many bugs coming up at the last moment. (Goebel, 2003)

Quality management comes with the following rules and principles:

Pair programming ensures review of all code.
Unit tests are coded first and all code has to pass the unit tests.
Continuous integration helps fix integration bugs earlier. (Goebel, 2003)

With XP, testing begins from day one. Unit tests are first created and executed. Frequent acceptance tests are conducted (at the end of each iteration instead of at the end of the project). Also, new tests are created for every bug that is found ensuring that the same will be covered in the next iteration and wont get to the production. (Goebel, 2003)

Unified Software Development Process (USDP)

Unified Software Development Process, commonly known as Unified Process, is an extensible and customizable framework that is use-case driven, architecture-centric, and iterative and incremental (Khamis & Abdelmonem, 2002 and Rational Software Corporation, c. 2000).

A use-case helps capture all the functional requirements and are used in the remaining phases to help design, implement and test. Use-cases help define a function whereas architecture helps relate and integrate these functions. The iterative and incremental lifecycle is followed accepting that change is inevitable.

The four main phases of the incremental lifecycle (Khamis & Abdelmonem, 2002 and Rational Software Corporation, c. 2000) are:

Inception: High-level use-cases are developed
Elaboration: The use-cases are developed in detail along with the architecture
Construction: Actual coding is done
Transition: Software product is moved from testing to end-users.

Each phase may require to be completed in one or more iterations with each iteration going through requirements analysis, design, implementation, and testing processes.

There have been many variations of the Unified Process like Agile Unified Process, Basic Unified Process, Enterprise Unified Process, Open Unified Process, Rational Unified Process (RUP), etc. Rational Unified Process is a development process of IBM and is the best-known and well-documented as compared to others. RUP suggests the following best practices:

Iterative development reducing risks
Requirements management with the help of use-cases
Component-based architecture
Visual modeling (e.g. using UML)
Software quality verification
Change control

(Source: Khamis & Abdelmonem, 2002 and Rational Software Corporation, c. 2000)

RUP is based on nine workflows, six of them are core engineering workflows while the remaining are supporting workflows. The core engineering workflows are business modeling, requirements, analysis and design, implementation, test and deployment while the supporting workflows are project management, configuration and change Management and environment (Khamis & Abdelmonem, 2002 and Rational Software Corporation, c. 2000).

Note that the core engineering workflows resemble the waterfall software development life cycle; however, these workflows will be used again and again throughout the lifecycle during each iteration although the intensity would vary. The workflows are explained in brief below:

Business Modeling: RUP provides a common language and process for both business engineering and software engineering community, thereby providing a way of communication between the two. This is done through the creation of use-cases.
Requirements: This is where a vision document is created, requirements are finalized and the description is also agreed upon. Use cases are prepared with detailed description. Use case modeling is also completed at this stage.
Analysis and Design: The goal here is to create a design model. An analysis may also be created if required. The design model is a blueprint of how the code will be structured.
Implementation: The system is realized through components either by reusing existing ones or implementing new ones which are well-defined and reusable as far as possible. Unit testing is also completed during this phase.
Testing: The goal of this workflow is to verify the interaction between the various objects created, to ensure that the components are integrated appropriately and to release defect-free software. Since an iterative approach is used, testing is carried throughout the project. Also, each of the quality dimensions (functionality, reliability, and performance) goes through a test lifecycle which is similar to the waterfall model (i.e. planning, design, implementation, and testing). Automated test strategies are also defined here.
Deployment: This workflow aims to release products successfully and involves producing a release, packaging, distributing, installing and training the users. It may also involve beta testing, data migration, and formal acceptance of the software.
Project Management: This involves balancing expectations and objectives, managing risks, and overcoming constraints to successfully deliver a product. This workflow provides a framework for managing projects and associated risks as well as guidelines to help plan, staff, execute and monitor projects.
Configuration and Change Management: This workflow seeks to avoid or resolve conflicts that may occur due to simultaneous update or multiple versions of the same artifacts. It also includes guidelines on change request management.
Environment: The aim of this workflow is to create a supportive work environment for the development team. This means providing them with processes and tools that are required to support the development team. It may also contain with guidelines and templates that can help customize the process.

USDP (RUP) v/s XP

RUP and XP are similar on a superficial level since both support iterative and incremental methodologies and encouraging significant stakeholder participation throughout the development process. RUP supports iterative development but within the framework of a waterfall methodology. XP, on the other hand, supports agile development. (Nicolette, 2005)

While XP is lightweight methodology, RUP is a customizable framework that can be either lightweight or heavyweight depending on how the process is customized by the organization. A lightweight methodology focuses on working solution rather than documentation.

It supports direct communication amongst stakeholders (developers and customers) thereby reducing management overhead. A heavyweight methodology, on the other hand, requires a lot of documentation, following processes with many checkpoints requiring high management overhead.

The pair programming concept of XP may not be favorable to a developer and may bring about feelings of distrust, which would be the opposite of what it aims to achieve. RUP may be easier to adopt since the framework can be customized to suit the organizations needs. RUP also provides supporting workflows and guidelines for project management, configuration and change management and environment, which are not explicitly defined in XP methodology.

While XP methodology utilizes user stories in laymen language, RUP involves creating a vision document and use case analysis. XP methodology, however, also insists on an on-site customer to support the software development process.

The differences between RUP and XP methodologies are highlighted below:

Tasks	RUP	XP
Requirement analysis	Use-case analysis	User stories On-site customer Collaboration
Analysis and Design	Analysis and Design modeling	Simple design
Implementation		Frequent small releases Pair programming Refactoring Continuous integration Collective ownership
Testing	Complete test lifecycle including planning, design, and implementation	Unit testing
Deployment	Deployment plan User documentation Support/Training Plan
Configuration and Change Management	Guidelines Change request documents
Project Management	Status reports Guidelines	Iteration plan

XP methodology is people-oriented and relies more on human resources to accomplish the project. RUP, on the other hand, tends to be more document-oriented. While XP methodology is suitable for projects with vague or evolving requirements or when small teams are involved, RUP is not restricted.

Recommendations

Extreme programming seems to be a better answer to the companys requirements for agility, increased productivity through paired programming and improved quality even with a small team. On the other hand, RUP seems to be a better answer to the companys requirements for project planning, risk management, and effective cost estimates.

The company cannot ascertain the availability of an on-site customer for all projects and hence, full utilization of XP methodology may not be possible. However, it is possible to use RUP and XP together since RUP is an extensible and customizable framework. Both have common practices as well as complementary ones that can help overcome their weaknesses and provide a better customized methodology to follow. (Pollice, 2001)

Both agree on the fact that requirements change and so do plans. While XP preaches implementing only what is required at the moment, RUP does the same by suggesting requirements management. XP requires coding tests first, then coding and requires customers to write the acceptance tests.

RUP provides a general framework and guidelines for testing and also suggests other tests required in addition to unit and acceptance tests unlike XP. This is where the best of both worlds could be combined. (Pollice, 2001)

RUP does not include code refactoring; however, it should be considered moderately to avoid risks for the team. Pair programming can be considered only if the team members are co-located and are compatible with their partners. RUP does not enforce pair programming. Continuous integration of XP methodology is complemented by the general framework and guidelines of Configuration and Change Management provided by RUP.

While XP requires an on-site customer, RUP is more flexible and understands that it may not always be possible. RUP defines roles and activities and understands that an on-site customer may not be available, but there has to be someone who can perform the same activities of providing information and clarification as soon as possible to the team. XP requires following coding standards while RUP provides coding standard examples to start with. (Pollice, 2001)