Agile Model Driven Development (AMDD)
Agile Model Driven Development (AMDD)
Agile Model Driven Development (AMDD)
Project Phases
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
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
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
Functional Specification Detailed Design Document User Interface Specification Data Model Prototype (can also be done with requirements) Updated Plan (improved estimates; new baseline)
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
Configuration control is very important here Documents need to be maintained also Sometimes a single team maintains multiple products
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
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
Increment 1
Increment 2
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
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
Disadvantages
Not as tailored to your requirements
Remember: custom software rarely meets its ideal (so compare that reality to COTS option)
eXtreme Programming
Inception
Construction
Transition
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
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 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
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
P aper
C old
H ot
Som t m 16%
R r y 19%
Agile Methods
eXtreme Programming (XP) SCRUM Dynamic Systems Development Method (DSDM) Feature Driven Development (FDD) Adaptive Software Development Crystal and many more !
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