Sequential Development
Waterfall model
This model suggests a linear development technique where one phase must be completed before the next phase can start.
Original planning covers the whole project.
Customer must be involved early in the process.
Assuming that all requirements can be defined up front becomes a major drawback .
Some practitioners have introduced “iterative back steps” or “back pass”.
Often does not accommodate time-to-market.
The ROLLING WAVE variant – The first phase is planned in detail and the remaining phases at a higher level of detail. Once completed, then the next phase is planned out in detail and this process continues until the future is clear
The TIMEBOXING variant – Of the triple constraints, the scope or functionality becomes the only flexible or negotiable variable. The timeframe and the pool of resources are constrained. The preferred timeframe is from 4 to 6 months
V-model
The “V” is for verification and validation.
The connection between development and test activities is emphasized.
The test plan and strategy is worked out at the end each phase.
Test, debug and change tasks at every phase.
W-model
A second “V” dedicated to testing is integrated into the original V-model.
Test plan created as soon as the basis for it is ready.
Tight interaction between testing and the changes in implementation is clarified in cycles of testing, debugging, changing and retesting.
Iterative Development
Spiral model (Barry Boehm)
Introduces the notion of Project Risk: project size grows but resources remain constant (1986).
Each spiral loop represents one phase split into 4 sectors of major activities.
RAD model (James Martin)
RAD – Rapid Application Development (1991) to build usable systems in 60-90 days
RAD essentials
Tools – (code generators, 4GLs, prototyping tools)
Methodology – (use tools effectively during phases)
People – (motivated with right skills and talents)
Management – ( not place obstacles)
Infrastructure – (collocation)
Important factors
Extensive user involvement
Joint Application Design sessions (JAD)
Joint Requirements Planning sessions (JRP)
Prototyping
Integrated CASE tools
Iterative (incremental prototyping)
Timeboxing
Process Model Phases
Requirements planning
User Design
Construction
Cutover
Joint Requirements Planning (JRP) & Joint Application Design (JAD)
JRP to identify requirements at strategic level
JAD is top-down approach to user design
Both forms of workshops follow the same pattern
Structured meetings with facilitator, pin/whiteboards and CASE tools
CASE Tools
Acronym for Computer-aided software engineering
To be used in all phases (including code generation)
Model use more suitable when:
Business objectives are well defined
Simple analysis or reporting of the data
Decisions made by a small number of collocated people
Small project team (6 or less)
Proven technology already in place
Microsoft Solutions Framework (MSF)
MSF is called a framework instead of a methodology. As a framework, it provides guidance without imposing much prescriptive detail.
Foundational Principles of MSF (version 3)
The Team Model
The Process Model
The Project Management Discipline
The Risk Management Discipline
The Readiness Management Discipline
Foundational Principles of MSF (version 3)
Foster open communications
Work toward a shared vision
Empower team members
Establish clear accountability and shared responsibility
Focus on delivering business value
Stay agile, expect change
Invest in quality
Learn from all experiences
The Team Model
Team Model Role Clusters
Product Management
Program Management
Development
Test
Release Management
User’s Experience
The Process Model
Three distinctive features of the Process Model
Phase and milestone-based
Iterative approach (versioned releases)
Integrated view of development and deployment
Process Model Phases and Milestones
Envisioning
Planning
Developing
Stabilizing
Deploying
The Project Management Discipline
Planning, Tracking, Change Control
Scope Management
Schedule Management
Cost Management
Staff Resource Management
Communication Management
Risk Management
Procurement Management
Quality Management
The Risk Management Discipline
Identification
Analysis and Prioritization
Planning and Scheduling
Tracking and Reporting
Control
Learning
The Readiness Management Discipline
Define readiness as a measurement of the current state versus the desired state of knowledge, skills and abilities of individual in the organization
Proven practices
Carry out readiness planning
Measure and track skills and goals
Treat readiness gaps as risks
Readiness Process
Define
Assess
Change
Evaluate
Rational Unified Process (RUP)
Captures many of the best practices in modern software development:
Develop software iteratively
Manage requirements
Use component-based architecture (COM, etc.)
Visually model software (UML by Rational Software )
Verify software quality
Control change to software
Deliverable driven where you manage the risks more than the dates
The Time Dimension - Phases and Iterations
Inception
Elaboration
Construction
Transition
The Static Structure
Workers
Activities
Artifacts (piece of information)
Workflows
Core process and supporting workflows (9)
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Project Management
Configuration & Change Management
Environment
Agile Development
In February 2001, the Manifesto for Agile Software Development was signed by 17 experienced and recognized software development practitioners.
“We are uncovering better ways of developing by doing it and helping other do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”
Agility
Agility is the ability to both create and respond to change in order to profit in a turbulent business environment
Agile model
A holistic environment that includes 3 interwoven components:
A “chaordic” perspective (chaos, order)
Collaborative values and principles
Barely sufficient methodology
Agile model effectiveness increases quickly over rigorous methodologies for projects characterized by change, speed and complexity.
SCRUM
SCRUM Essentials
Development is not a “defined process”, as rigorous methodologies assume, but an “empirical process”
Empirical processes cannot be consistently repeated and require constant monitoring and adaptation
SCRUM has a project management emphasis to facilitate the interaction of the team members
Process Model Phases
Pre-Sprint Planning
Sprint (30-day period, no-change rule)
Post-Sprint Meeting
Daily 20-minute informational meeting (not development meeting) attended by all team members.
Dynamic Systems Development Method (DSDM)
DSDM was created (1997) and is maintained by a consortium of independent companies to improve on RAD
DSDM principles:
Active user involvement
Team members must be empowered to make decisions
Focus is on frequent delivery of products
Fitness for business purpose is the essential criterion for acceptance
Iterative and incremental development
All change during development are reversible
Requirements are baselined at a high level
Testing is integrated throughout the life cycle
A collaborative and cooperative approach between all stakeholders
Use of 3 interacting iterative models with 2 to 6 week time-boxes
Prototypes: business, usability, performance and capacity
Functionality is allowed to vary over the course of project, control is maintained by using time-boxes
Use of prototypes rather than documents to capture information
Excellent manual and support materials available to consortium member companies
Primary target is small- to medium-sized projects with significant user interface component
The DSDM Process Model
Functional Model Iteration (documented in prototypes)
Design & Build Iteration
Implementation
Extreme Programming (XP)
XP Practices
Planning Game (3-week iteration, stories)
Small Releases
Metaphor (overall coherent theme)
Simple Design
Refactoring (ongoing redesign, design patterns)
Testing
Pair Programming
Collective Ownership
Continuous Integration
Sustainability
On-site Customer
Coding Standards
Frequent-Built Technique
Also known as build-and-smoke-test, daily built or continuous integration is frequently integrated to agile and iterative development.
All source files are compiled and linked to build an executable system as often as possible, daily if possible.
Test may vary from superficial to thorough, according to needs and possibilities.
Other Agile models
Crystal Methods
First-order focus on people and communication and second-order relates to process and tools (A. Cockburn)
Feature-Driven Development
Scale-up projects (250 people, 18-month period, Jeff De Luca, Peter Coad)
Lean Development
The most strategic-oriented model derived from the principles of Lean Production of the 1980's (Bob Charette)
Adaptive Software Development
A Change-Oriented Life Cycle dedicated to continuous learning and oriented to reevaluation, peering into uncertain future, and intense collaboration (Jim Highsmith)
Integrated Product Development
Capabilities Maturity Model Integration (CMMI)
The 1990s were the Decade of Process for IT. We were determined to plan the work and work the plan.
Based on the CMM model where the underlying assumption is good processes lead to good results.
Developed by the Software Engineering Institute ( Carnegie Mellon University ).
CMM version 1.0 released in 1991, version 1.1 in 1993, version 2.o has been overtaken by CMMI.
Latest CMMI version includes : systems engineering (SE), software engineering (SW), integrated product and process development (IPPD) and supplier sourcing (SS) (CMMI-SE/SW/IPPD/SS V1.1, continuous and staged, 03/2002).
Process areas in CMMI are divided into 4 main groups:
Process management (definition, performance)
Project Management (planning, control, risks)
Engineering (requirements, solution, verification)
Support (configuration management, QA)