Agile Model Driven Development(AMDD)

Software Development Life Cycle (SDLC)

It is developing a computer system It concerns a process which takes from two months to two years This is called a system development life cycle System Development Methodology  Standard process followed in an organization to conduct all the steps necessary to analyze, design, implement and maintain information systems. Traditional methodology for developing, maintaining, and replacing information systems

Project Phases

Potential Deliverables by Phase

Requirements
Inputs: SOW, Proposal Outputs:  Requirements Document (RD)
Requirements Specification Document (RSD) Software Requirements Specification (SRS)

 1st Project Baseline The What phase  Software Project Management Plan (SPMP)  Requirements Approval & Sign-Off
Your most difficult task in this phase

Perhaps most important & difficult phase Shortchanging it is a classic mistake Can begin with a Project Kickoff Meeting Can end with a Software Requirements Review (SRR)  For Sponsor and/or customer(s) approval

Why are Requirements so Important?

Requirements
Characteristics & Issues
 Conflict of interest: developer vs. customer  Potential tug-of-war: Disagreement on Features & Estimates Especially in fixed-price contracts  Frequent requirements changes  Achieving sign-off

Project planning occurs in parallel Requirements are capabilities and condition to which the system more broadly, the project must conform

2 Types of Requirements
 Functional (behavioral)
 Features and capabilities

 Non-functional ( technical) Usability

       Human factors, help, documentation Reliability  Failure rates, recoverability, availability Performance  Response times, throughput, resource usage Supportability  Maintainability, internationalization Operations: systems management, installation Interface: integration with other systems Other: legal, packaging, hardware

Requirements
Other ways of categorizing
 Go-Ahead vs. Catch-up Relative to competition  Backward-looking vs. Forward-looking Backward: address issues with previous version Forward: Anticipating future needs of customers

Must be prioritized
Must-have Should-have Could-have (Nice-to-have: NTH)

Must be approved

Analysis & Design

The How Phases Inputs: Requirements Document Outputs:
     

Functional Specification Detailed Design Document User Interface Specification Data Model Prototype (can also be done with requirements) Updated Plan (improved estimates; new baseline)

Continues process from RD

Analysis & Design

Ends with Critical Design Review (CDR)  Formal sign-off  Can also include earlier Preliminary Design Review (PDR) for high level design Characteristics & Issues  Enthusiasm via momentum  Team structure and assignments finalized  Delays due to requirements changes, new information or late ideas  Issues around personnel responsibilities  Unfeasible requirements (technical complexity)  Resource Issues
Including inter-project contention

Development
The Do It phase Coding & Unit testing Often overlaps Design & Integration phases  To shorten the overall schedule  PM needs to coordinate this Other concurrent activities  Design completion  Integration begins  Unit testing of individual components  Test bed setup (environment and tools)  Project plans updated  Scope and Risk Management conducted

Development
Characteristics
 Pressure increases  Staffing at highest levels  Often a heads-down operation

Issues
   

Last-minute changes Team coordination (esp. in large projects) Communication overhead Management of sub-contractors

Integration & Test

Evolves from Dev. Phase Often done as 2 parallel phases  Partial integration & initial test Starts with integration of modules An initial, incomplete version constructed Progressively add more components Integration primarily a programmer task Test primarily a QA team task Integration:  Top-down: Core functionality first, empty shells for incomplete routines (stubs)  Bottom up: gradually bind low-level modules  Prefer top-down generally

Integration & Test

Tests
             Integration testing Black & White-box testing Load & Stress testing Alpha & Beta testing Acceptance testing Final budgeting; risk mgmt.; training; installation preparation; team reduced Increased pressure Overtime Customer conflicts over features Frustration over last-minute failures Budget overruns Motivation problems (such as burnout) Difficulty in customer acceptance
Esp. true for fixed-price contracts

Other activities Characteristics & Issues

Deployment & Maintenance

Installation depends on system type
 Web-based, CD-ROM, in-house, etc.

Migration strategy How to get customers up on the system

 Parallel operation

Deployment typically in your project plan, maintenance not Maintenance

   Fix defects Add new features Improve performance

Configuration control is very important here Documents need to be maintained also Sometimes a single team maintains multiple products

Deployment & Maintenance

Characteristics & Issues
     

Lack of enthusiasm Pressure for quick fixes Insufficient budget Too many patches Personnel turnover Regression testing is critical
Preferably through automated tools

Lifecycle Planning
Lifecycle Management or SDLC Greatly influences your chance of success Not choosing a lifecycle is a bad option Three primary lifecycle model components
   Phases and their order Intermediate products of each phase Reviews used in each phase

Different projects require different approaches You do not need to know all models by name You should know how that if given a certain scenario what sort of SDLC would be appropriate There are more than covered here A lifecycle is not a design, modeling or diagramming technique
 The same technique (UML, DFD, etc) can be used with multiple lifecycles

Pure Waterfall
The granddaddy of models Linear sequence of phases  Pure model: no phases overlap Document driven All planning done up-front Works well for projects with  Stable product definition  Well-understood technologies  Quality constraints stronger than cost & schedule  Technically weak staff
Provides structure Good for overseas projects

Waterfall
Follows the classic SDLC: Requirements Analysis, Design, Coding, Testing, Operations. Great for managing projects and controlling clients, lousy for actually building software. Assumes you can identify and agree on requirements that wont change. Doesnt find problems until late in the game when theyre very difficult and expensive to fix. Sets up a very specific set of expectations around creation of artifacts (and getting paid!).

Disadvantages of Waterfall
 Not flexible
Rigid march from start->finish

 Difficult to fully define requirements up front  Can produce excessive documentation  Few visible signs of progress until the end

Spiral
Emphasizes risk analysis & mgmt. in each phase A Series of Mini-projects Each addresses a set of risks
 Start small, explore risks, prototype, plan, repeat

Early iterations are cheapest Number of spirals is variable

 Last set of steps are waterfall-like

Iterative: Spiral
Concurrent rather than sequential determination of artifacts Review of objectives, constraints, alternatives, and risk with commitment to proceed Level of effort driven by risk considerations Degree of detail driven by risk considerations Use of LCO, LCA, IOC anchor point milestones Emphasis on system and lifecycle activities

Spiral
Advantages
 Can be combined with other models  As costs increase, risks decrease  Risk orientation provides early warnin

Disadvantages
 More complex  Requires more management

Prototyping

Iterative development process: Requirements quickly converted to a working system System is continually revised Close collaboration between users and analysts

Prototyping Model
Advantages::

   

Good when input/output requirements and user interface not clear initially Good for development of visible parts of the system Fosters communication with customers and users Helps identify and refine requirements

Disadvantages:


 

False expectations: customer sees what appears to be a working product Not good for invisible aspects of system Early unfinished prototypes may perpetuate themselves

Iterative Model

Core Product

Analysis

The Incremental Model (Linear Sequential)

Design

Increment 1

Programming Analysis Design Testing, etc.

Integration + Regression Testing

Increment 2

Programming Analysis Design Testing, etc.

Etc.
Programming Testing, etc.

Incremental Model
Advantages:

 

Core functionality can be provided quickly Increments can be planned to manage technical risks (e.g., increment, evaluate, increment, evaluate, etc.)

Disadvanges:

 

Takes a long time to finish entire system Later increments may never get done

V Process Model

V Process Model
Designed for testability
 Emphasizes Verification & Validation

Variation of waterfall Strengths

 Encourages V&V at all phases

Weaknesses
 Does not handle iterations  Changes can be more difficult to handle

Good choice for systems that require high reliability such as patient control systems

Rapid Application Development (RAD)

Methodology to decrease design and implementation time Involves: prototyping, JAD, CASE tools, and code generators

Commercial Off-The-Shelf software (COTS)

Build-vs.-buy decision Advantages
 Available immediately  Potentially lower cost

Disadvantages
 Not as tailored to your requirements

Remember: custom software rarely meets its ideal (so compare that reality to COTS option)

Agile Modeling (AM)

AM is a chaordic, practices-based process for modeling and documentation AM is a collection of practices based on several values and proven software engineering principles AM is a light-weight approach for enhancing modeling and documentation efforts for other software processes such as XP and RUP

XP: eXtreme Programming

Not a Microsoft product Part of movement called Agile Development A Lightweight methodology A bit counter-culture Currently in vogue Motto: Embrace Change Highly Incremental / Iterative Suitable for small groups Attempts to minimize unnecessary work Uses an on-site customer Small releases Pair programming Refactoring Stories as requirements You want good developers if you use this

eXtreme Programming

Rational Unified Process

RUP From Rational Corporation Generic version is the Unified Process Commercial Extensive tool support (expensive) Object-oriented Incremental Newer Develop Iteratively Manage Requirements Uses UML (Unified Modeling Language) Produces artifacts Use component-based architecture Visually model software Complex process A framework Suitable for large scale systems

Rational Unified Approach - RUP

Elaboration

Inception

Construction

Transition

phases of the EUP

Iterative: Rational Unified Process

Use case-driven, architecturecentric, iterative: tackles risk early Phases:

   

Inception: Scope; Go/No-Go Elaboration: Test the architecture Construction: Build the rest Transition: Tune and hand off

50% done = 50% built Different approach to project management: challenge to control iterative, incremental development
Prob em S o u t o n

RUP: Key Characteristics

Iterative: Consistent, improvable, insightful, tangible, measurable
R D C T R D C T R D C T R D C T R D C T

time

Use case-driven: What is the context, who are the actors, how do they interact with the system, and what observable value do they derive? For each interaction, whats the happy path and what are the alternate paths? Architecture-centric: What are the structural elements and how are they interfaced? What behaviors must result from their interactions? How do these structural and behavioral elements fit into the overall systems context?

Agile Model Driven Development (AMDD) Project Level

What Are Agile Models?

Agile models:
 Fulfill their purpose  Are understandable  Are sufficiently accurate  Are sufficiently consistent  Are sufficiently detailed  Provide positive value  Are as simple as possible

Agile models are just barely enough!

Agile Models

Usage Modeling
- Acceptance Tests - Essential Use C ases - Features - System Use C ases - Usage scenario - User Stories

Agile Documentation
Travel light You need far less documentation than you think Agile documents:
           
Maximize stakeholder investment Are concise Fulfill a purpose Describe information that is less likely to change Describe good things to know Have a specific customer and facilitate the work efforts of that customer Are sufficiently accurate, consistent, and detailed Are sufficiently indexed Your project stakeholders require it To define a contract model To support communication with an external group To think something through

Valid reasons to document:

Communication Modes
Face-to-face at w hiteboard C om m unication E ffectiveness Face-to-face conversation V ideo conversation P hone conversation V ideotape E m ail conversation M odeling O ptions

Audiotape D ocum entation O ptions

P aper

C old

R ichness of C om m unication C hannel

H ot

The Cost of Traditional BRUF

Successful Projects Still Have Significant Waste
Aw y 7% Oft n 13% N v r 45%

Som t m 16%

R r y 19%

AMDD Simple Approach

Agile Methods
eXtreme Programming (XP) SCRUM Dynamic Systems Development Method (DSDM) Feature Driven Development (FDD) Adaptive Software Development Crystal and many more !

Generic Agile Process

AMDD CASE Approach

AMDD Agile MDA Approach

AMDD Enterprise Level

Agile Software Requirements Management

References
Agile Methodologies (General)
 http://www.martinfowler.com/articles/newMethod ology.html  http://www.agilealliance.org/

Extreme Programming
 Kent Beck, Extreme Programming Explained: Embrace Change (Addison Wesley, 1999).  Kent Beck and Martin Fowler, Planning Extreme Programming (Addison Wesley, 2001).  www.xprogramming.com  www.extremeprogramming.org