Project Methodologies AD642

Agenda Waterfall Lifecycle Model RUP Lifecycle Model Agile Software Development Methodologies Extreme Programming

Waterfall Model Activity-centered view of the software lifecycle Define detailed upfront requirements Come up with the design that will support the required behavior. Implement the required system. Integrate and test the components. Activities are performed in sequence Described in 1970 by Royce.

Waterfall Model Illustrated Requirements Process System Allocation Concept Exploration Design Implementation Installation Operation & Support Process Verification & Validation

About Waterfall Lifecycle Managers love waterfall models: Nice milestones No need to look back (linear system), one activity at a time Easy to check progress : 90% coded, 20% tested Developers hate the waterfall model Requirements are a moving target They have to come up with estimates based on no data.

Problems with the Waterfall (I) Complete up-front specifications with sign-off Research showed that 45% of features created from early specifications were never used—with an additional 19% rarely used [Johnson02]. Over-engineering, a study of 400 projects spanning 15 years showed that less than 5% of the code was actually useful or used [CLW01].

Problems with the Waterfall (II) Late Integration and Test The waterfall pushes this high-risk and difficult issues toward the end of the project. Waterfall is called fail-late lifecycle. Reliable Up-front Estimates and Schedules Can not be done when the full requirements and risks are not reliably known at the start, and high rates of change are the norm. “Plan the work, work the plan” values Limited value for high change, novel, innovative domains such as software development.

Iterative and Incremental Lifecycle Models 1960’s: ad-hoc code-and-fix 1970’s: Waterfall was thought to be the ideal approach to software development In practice, waterfall is only applicable to the most straightforward projects. 1980’s: Iterative and incremental lifecycle models The lifecycle is composed of a sequence of iterations. Each iteration is a mini-project composed of activities such as requirements analysis, design, programming and testing. An iteration ends with an iteration release, a stable, integrated and tested partially complete system. 1990’s: Rational Unified Process Popular example of Iterative and incremental lifecycle A product and a process based on object orientation and UML

RUP: Rational Unified Process Derived from the work on the UML at Rational Booch, Jacobson, and Rumbaugh (1999) 4 Phases: Inception Elaboration Construction Transition Several Iterations in each phase For each iteration, several parallel activities (workflows)

(source: www.rational.com)

RUP Dimensions First Dimension: A dynamic perspective that shows phases and iterations over time Second Dimension: static perspective that shows process activities (workflows)

RUP Dynamic Perspective Phases can be enacted incrementally Each phase is enacted In an iterative way

RUP Phases Inception Elaboration Construction Transition Establish the business case for the system Identify actors and initial use cases Initial planning, estimation and schedule Elaboration Understand problem domain Requirements model (use case model) Overall system architecture Construction System design, object design, programming and testing Develop a working software system ready to deliver to users Transition Deploy the system in its operating environment.

Static workflows

RUP Illustrated Time Workflows

RUP Good Practice Develop software iteratively Manage requirements Plan increments based on customer priorities Manage requirements Explicitly document requirements and track requirement changes Analyze impact of changes before accepting them Use component-based architectures Visually model software (UML) Control changes to software Manage changes to software using a change management system and configuration management procedures and tools

Agile Methods In the 1908os and early 1990s there was a widespread view that the best way to achieve better software was through careful project planning formalised quality assurance the use of analysis and deign methods supported by CASE tools controlled and rigorous software development

Agile Methods (Cont.) This view came from software engineers who were developing large, long-lived software systems Teams in different companies and geographically distributed When heavy weight, plan-based development approaches were applied to small and medium size systems The overhead sometimes dominated the software development process Consider the cost of changing requirements

Agile Methods (Cont.) More time was spent on how the system should be developed than on program development and testing In the 1990s new agile methods were formulated which relied on an iterative & incremental approach allowed for changing requirements Rapid software delivery to customers

General Principles of Agile Methodologies Customer close involvement Incremental delivery A focus on people, not the process Team members develop their own ways of working Embrace requirements and change Maintain simplicity

Examples of Agile Methodologies Extreme programming (covered here) Crystal Adaptive Software Development Scrum DSDM Best suited for small and medium sized projects

Light-weight Methodologies Heavy-weight methodologies: (based on waterfall or RUP) Up-front analysis & design documentation Strict phases Large teams, long iteration cycles, long release times Feature intensive Light-weight (Agile) methodologies: (E.g., XP) No up-front analysis & design documentation Test-first coding Small teams, short iteration cycles, short release times Change intensive

Software Development Processes Waterfall Iterative Extreme Programming (XP) Analysis Design Code Design

XP Highlights Probably the best known and most widely used agile method Founded on four values: communication, simplicity, feedback, and courage (courage in changing requirements and code). Programmers work in pairs Develop tests for each task before writing code New versions of the software may be created several times a day Increments are delivered to customers roughly every two weeks

XP Highlights (Cont.) All scenarios and requirements are represented as user stories Customer is involved in specifying and prioritising requirements The customer is part of the development team The software is continually refactored

User Stories Written by customer Used instead of large requirements documents Similar to scenarios but not limited to features visible to the outside world. Used for release planning Used for the creation of acceptance test Typically much less detailed than scenarios and use cases Typically takes 1-3 weeks to implement

XP Release Cycle Select user stories for this release Breakdown stories into tasks Plan release Develop/integrate/ test software Release software Evaluate System

12 XP Practices Pair-programming On-site Customer Test-first Iterative Development Refactoring Simple Design Planning Game Coding Standards Continuous Integration Metaphor 40-Hour Rule Collective Code Ownership

Pair Programming All code to be included in a production release is created by two people working together at a single computer. One person types and codes, the other one observes and constantly monitors the code. The observer is doing real-time code review, and perhaps thinking more strategically than the person typing. Pairs dynamically swap rolls Active communication, sharing expertise

On-Site Customer Programmers and customers work together in the same team (same room). Immediate check, feedback, and clarification by customer through face-to-face communication. Customer performs acceptance test of features as they are completed. Customer satisfaction: early and frequent delivery of software features.

Test-First Development Develop automated tests before implementation Test-then-code instead of code-then-test Test-driven coding: constant validation and verification Constant testing: unit, integration, acceptance (by onsite customer) Automated testing (JUnit framework) Open source framework for implementing unit tests in Java Comes with Eclipse

Iterative Development Customers choose the story cards for next iteration (next features to be implemented) depending on their business priorities. Short iterations, release frequency, customer prioritized short cycles Iteration plan, release plan from planning games Small complete and continuous releases Frequent delivery of working software progressively acquiring new features

Refactoring Improves code quality Extreme re-factoring for continued improvement of design Constantly simplifies code Changing existing program to make adding new features simple Re-factoring after adding a new feature to clean up and organize the effect of the change Re-factor as often as needed

Simple Design Design for now, not for the future Extreme simplicity in design: avoid shortcuts, smart hard-to-understand code No duplicate logic (no parallel class hierarchies) Fewest possible classes and methods Only features in the current iteration Good design (re-factored) and technical excellence

Continuous Integration Integration and integration testing of tasks frequently (every few hours, at least once a day) Integration on a machine dedicated for integration Integration testing before completing current integration session Continuous code review: integration testing and code review of completed code

Metaphor Use of best practices: design patterns, naming, defining Easy to use system of names: consistent naming of classes and methods

40-Hour Rule Best individual effort without overwork and undue pressure Uniform individual velocity: sustainable development pace Fresh and eager team when starting in the morning Satisfied and not tired when finishing the day in the evening 40 hr may vary (35 - 45) Discourage overtime. No two successive days of over-time. Vacation and weekend work discouraged for best developer contribution Highly motivated and fully fit developing members

Collective Code Ownership Any pair programmers may re-factor any part of the code Faster development by eliminating the bottleneck associated with change requests in an individual code ownership model Pair programming, adherence to the code standard, and continuous integration lower the danger of this free model of modifying the code. No individual (or pair) responsibility or blame after integration

XP Achieves Timing: Delivery On Time Releasing: Frequent Releases (with Business Prioritized Features) Quality: Simple Code--easy to test and modify Reliability: Constantly Tested, Pair-programmed & Integrated Features Flexibility: Rapid Response to Feedback, Change, Re-scheduling Low Initial Cost: Flattened Change Cost Curve, No Future-safe Cost Communication: Face-to-face, On-site Customer, Pair-programming Team-work: Constant Team Integration, Team Spirit & Esteem Iterating: Micro-iterations, Small Analyze/Test/Design/Code Episodes People-Centered: Stand-up Meetings, Planning Games, Individual Velocities

Which Methodology to Use? Each has advantages and disadvantages Small projects tend to fit well into iterative processes Large projects often need more up-front planning and a waterfall approach Outsourcing, market constraints, corporate culture all come into play