Lecture 1: RUP and XP

Software Development Life Cycle (SDLC)

1. Specification - Define functionality we must support

2. Development - Create software that delivers functionality

3. Validation - Verify software does what it is supposed to

4. Evolution - Evolve to software to meet customer needs

Waterfall Method

A sequential (non-iterative) design process, flows steadily downward

Waterfall Model Phases

1. Requirements - collect and analyze what system should do. Outcome: requirements specification document

2. Design - Create system architecture and detailed design. Outcome: design specifications for developers

3. Implementation - Develops write code. Outcome: working software components

4. Verification - Test the system against requirements. Outcome: verified product, ready for delivery

5. Maintenance - After transfer to user; updates, bug fixes, and improvements. Outcome: long-term system support

Waterfall Method Key Characteristics

1. Popular with traditional engineering

2. PLAN/ DOCUMENTATION HEAVY

3. Good for need to get right the first time, cost of failure is high, have complete and stable requirements

4. Inflexible, late discovery of issues, bad for evolving requirements

V(Verification/Validation) Model

• address the main limitation of the Waterfall model—late testing. By having test that corresponding with every test.

• Testing is planned in parallel and performed in reverse order after coding.

• Step 1 → Step 2 → Step 3 → Step 4 → Coding → Step 4 Test → Step 3 Test → Step 2 Test → Step 1 Test

Boehm’s Spiral Model

• risk-driven software development process (identify and reduce risk early)

• Iterative. In loops

Boehm’s Spiral Model Loop Phases

1. Define objectives & constraints

2. Risk assessment & reduction

3. Development & testing

4. Planning next iteration

Boehm’s Spiral Model Key Characteristics

• Customer feedback at each iteration

• Lots of RISK ANALYSIS

• Good when: large/complex project, unclear/evolving requirements, high-risk, frequent user feedback needed

Iterative Model

• system is built incrementally through repeated cycles (iterations).

• Delivers partial working system early

• Each iteration includes design, build, test

• Requirements are mostly known but can evolve

• User feedback after each iteration

• Best when: requirements are not complete upfront, early protypes are helpful, change is expected

• Key: early issue detection = risk reduction

Agile Methods Key Points

• Flexible and iterative w/ rapid delivery & continuous improvement.

• Sprint cycles

• Faster to market

• Adaptable, customer involvement, continuous testing and delivery

• Use when: big upfront planning is not practical, need to reduce risk, visibility with customers

Agile Sprint Phases

1. Plan - Define sprint goals

2. Design - High-level or detailed design decision made. Design is kept lightweight and adaptive

3. Build - Write code (small tasks)

4. Test - tested continuously. unit, integration, and acceptance testing

5. Review - demonstrate features to stakeholders. Feedback collected

6. Launch - working product (or increment) is launched/deployed.

7. Repeat and improve

Big Bang/ Chaos Method

• Little to no planning, figure out as you go

• Very small projects or start ups

Traditional SDLC v. Agile SDLC

Rational Unified Process (RUP)

• an iterative and incremental software development framework that guides life cycle of software development focused on

  • Clear structure

  • Risk mitigation

  • Continuous user involvement

  • Iterative refinement

RUP Best Practices

1. Develop software iteratively

   • to complex & risky to go one pass. allow customer involvement

2. Manage Requirements

   • Use cases and scenarios help to identify requirements

3. Use component-based architecture

   • Robust architecture prior to full-scale development to aid reusable, component-based software

4. Visually model software

   • UML diagram

5. Verify software quality

   • Verification and Validation is not an afterthought

6. Control changes to software

   • Control, track, and monitor changes

RUP Phases

1. Inception - define project scope, goals, business case, and high-level risks

2. Elaboration - refine requirements, build architecture, resolve high-level risk

3. Construction - Build the software in increments

4. Transition - prepare for an perform deployment

RUP Disciplines

• Business Modeling - create & maintain traceability between business and software modules

• Requirements - describe what system should do

• Analysis and Design - show how system will be realized in implementation phase

• Implementation - system is realized through implementation of reusable components

• Test - find defects as early as possible

• Deployment - produce product release and deliver to users

• Configuration and Change Management - manage access to project work

• Project Management - manage risks, direct people, coordinate with other stake holders

• Environment - ensure that the process, guidance and tools are available

Boehm’s Risk Exposure: Safety Critical Profile

• For normal projects (blue curve), the sweet spot is reached with moderate planning.

• For large, safety-critical projects (green curve), the sweet spot is shifted towards more extensive planning to reduce risks of large system rework or failures.

Boehm’s Risk Exposure: Agile Profile

• ow size of loss S(L) because rework is easy and frequent (short iterations, continuous feedback).

• accept a higher probability of small losses but keep losses small.

• The sweet spot is towards lower planning effort—agile minimizes upfront planning.

Extreme Programming (XP) - 12 Practices

1. The Planning Game - Once per iteration. Decide scope, priory, release dates, estimate effort, technical consequences, scheduling

2. Whole team - customer is member of team

3. Pair Programming - all code written by two people at one machine. Driver(implementation) & navigator(viability of approach, new tests, simpler ways)

4. Testing - Continuous tests, must pass test for development to continue

5. Continuous Integration - integrate & test every few hours. Easy to see what broke code

6. Small Release - frequent feedback & tracking

7. Refactoring - restructure system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility

8. Simple Design - easy to understand what is going on

9. Coding Standard - clear, unambiguous code

10. Collective Ownership - Everyone knows something about every part to mitigate loss if someone leaves

11. System Metaphor - Detailed enough to drive architecture, avoid buzz words & jargon

12. Sustainable Pace - Don’t burn out