Extreme Programming (XP) and Rational Unified Process (RUP)

Extreme Programming (XP)

Extreme Programming (XP) is an influential agile method developed in the late 1990s. It introduces agile development techniques with an extreme approach to iterative development.

Key Aspects of XP

  • Iterative Development: New versions are built several times per day.
  • Incremental Delivery: Increments are delivered to customers every 2 weeks.
  • Testing: All tests must be run for every build, and the build is accepted only if the tests run successfully.

What is XP?

XP is described as:

  • Lightweight
  • Humane
  • Adaptive
  • Value-driven

The Extreme Programming Release Cycle

The XP release cycle involves several key principles and practices:

  • Incremental Planning: Requirements are recorded on story cards, and stories for a release are determined by time and priority. Developers break these stories into development 'Tasks'.
  • Small Releases: The minimal useful functionality providing business value is developed first. Releases are frequent and incrementally add functionality.
  • Simple Design: Enough design is carried out to meet current requirements, and no more.
  • Test-First Development: Automated unit tests are written before the functionality itself is implemented.
  • Refactoring: Continuous refactoring is expected from all developers to keep the code simple and maintainable.

XP and Agile Principles

  • Incremental Development: Supported through small, frequent system releases.
  • Customer Involvement: Full-time customer engagement with the team.
  • Collective Ownership: Avoids long working hours.
  • Change Support: Through regular system releases.
  • Simplicity: Maintained through constant refactoring of code.

Influential XP Practices

  • Technical Focus: XP emphasizes technical practices like pair programming, test-driven development, and continuous integration.
  • Limited Adoption: The original XP method is not widely used due to its strict focus, but many Agile methodologies borrow key practices from it. Organizations often adopt a mix of Agile practices.

Key Practices

  • User stories for specification
  • Refactoring
  • Test-first development
  • Pair programming

User Stories for Requirements

  • Customer Involvement: A customer or user is part of the XP team and makes decisions on requirements.
  • User Stories: User requirements are expressed as user stories or scenarios.
  • Standard Template: “As a , I want to so that .”

User Stories for Requirements

  • Tasks: User stories are broken down into implementation tasks, which form the basis for schedule and cost estimates.
  • Prioritization: The customer chooses stories for inclusion in the next release based on priorities and schedule estimates.

Rational Unified Process (RUP)

RUP is a software development process model that is deliberately flexible and can be tailored to the needs of the project.

RUP Key Aspects:

  • Tailoring: Tailored to the needs of the project, defining activities, roles, and artifacts.
  • UML Notation: The model defines the core of RUP using UML notations.
  • Phases: Four phases
  • Activities: Multiple activities
  • Iterations

Six Principles of RUP

To minimize faults and increase productivity:

  • Develop iteratively
  • Manage requirements, keeping in mind the requirements set by customers that will be changed by users.
  • Use components and test individual components for reusability.
  • Model visually using diagrams to represent major components, users, and their interactions (UML).
  • Verify quality by making testing a major part of the project.
  • Control changes, ensuring changes are synchronized and verified constantly.

Two Dimensions of RUP

  • Horizontal Axis: Represents time and shows the lifecycle aspects of the process as it unfolds.
  • Vertical Axis: Represents core process workflows, which group activities logically by nature.

RUP Building Blocks

  • Roles (who): Define skills, competencies, and responsibilities.
  • Work Products (what): Represent something resulting from a task, including documents and models.
  • Tasks (how): Describe a unit of work assigned to a Role that provides a meaningful result.

Life-cycle Phases

  • Inception
  • Elaboration
  • Construction
  • Transition

Each phase focuses on a key objective and milestone delivery and has a sequential nature.

Inception Phase

Objectives:
  • Establish the project's software scope and acceptance criteria (requirements).
  • Establish main use-case scenarios that define core functionality.
  • Evaluate alternative architectures and create a preferred candidate architecture.
  • Estimate overall cost and schedule for the project.
  • Estimate risks.
  • Produce the “business case” justifying the project.
  • Create a work plan for the following elaboration phase.
Activities:
  • Synthesize a candidate architecture.
  • Evaluate alternatives for risk management, staffing, project plan, and trade-offs.
  • Plan and prepare a business case.
  • Formulate the scope of the project.
Outcomes:
  • A vision document outlining core requirements and constraints.
  • List all identified use cases and actors.
  • Business context and success criteria.
  • Financial forecast.
  • An initial business case, risk assessment, and project plan.
Vision Document
  • Describe the problem, who it affects, how it affects them, and the solution.
  • Problem statement
  • Identify stakeholders and users with their needs
  • Product features, functional and non-functional requirements, and design constraints.
Identifying Features:
  • Software Engineer: Configure system/project, Install tools
  • Process administrator
Inception Stakeholders

Stakeholders are persons or organizations affected directly or indirectly.

Inception Stakeholders Evaluation:
  • Stakeholder concurrence on scope, cost, and schedule.
  • Requirements understanding through use cases.
  • Credibility of estimates, priorities, risks, and development process.
  • Prototype architecture depth and breadth.
  • Actual vs planned expenditure.

Elaboration Phase

Objectives:
  • Refine requirements and identify additional use cases.
  • Focus on getting a baseline architecture from use cases.
  • Baseline the vision and plan for the construction phase.
  • Demonstrate that the architecture supports the vision at a reasonable cost and time.
Activities:
  • Integrate and assess components against primary use cases.
  • Select subsystems for purchase (COTS).
  • Elaborate system architecture (development environment, tools, test automation).
  • Develop a solid understanding of critical use cases and finalize the “vision.”
Outcomes:
  • Use-case model (at least 80% complete).
  • Supplementary requirements (non-functional).
  • Software architecture description.
  • Executable architectural prototype.
  • Revised risk list and business case.
  • Development plan for the overall project.
  • Preliminary user manual (optional).

Construction Phase

Objectives:
  • Minimize development costs by optimizing resource usage.
  • Achieve adequate quality rapidly.
  • Achieve useful versions quickly.
Activities:
  • Assessment of product releases against acceptance criteria.
  • Complete component development and testing.
  • Resource management, control, and process optimization.
Iteration Planning:
  • Iterations are planned with defined use-cases and time schedules (time boxing).
  • This leads to a “build” that can be released to others.
Iteration Releases:
  • Revisions are made based on feedback.
  • Scope reduction, feature movement, re-analysis, re-design, and re-work may be required.

Transition Phase

Objectives:
  • Move the software product to the users.
  • Phase starts when the system is mature enough for deployment in the end-user domain.
  • Usable subset of the system has been completed to an acceptable level of quality with User documentation that is available.
Activities:
  • Beta testing
  • Parallel operation with existing systems
  • Training of users and maintainers
  • Rollout of the product to marketing, distribution, and sales teams

Transition Objectives:

  • Achieve user self-supportability.
  • Achieve stakeholder concurrence that deployment baselines are complete.
  • Achieve the final product baseline rapidly and cost-effectively.

Transition Activities:

  • Deployment-specific engineering.
  • Tuning activities (bug fixing, performance enhancements).
  • Assessing deployment baselines against the vision and acceptance criteria.

Transition Evaluation:

  • Deciding whether objectives were met and whether to start another development cycle.
  • User satisfaction and acceptable resource expenditures are the primary evaluation criteria.

Workflows and Models

  • Requirements
    • Use Case Model
  • Analysis
    • Use Case, Sequence Diagram, Statechart Diagram, Activity Diagram
    • Analysis Model
  • Design
    • Class Diagram, Sequence Diagram, Statechart Diagram, Activity Diagram
    • Design Model
  • Implementation
    • Class Diagram, Component Diagram, Sequence Diagram, Statechart Diagram, Activity Diagram
    • Impl. Model
  • Test
    • All models
    • Test Model
  • Deployment
    • Component Diagram, Sequence Diagram
    • Depl. Model