# Presentation: 223672

## 

February 2003

**February 2003**

**LBNL **
**Project Management:**
**IT Application Specific**

## Objectives

- Identify the six phases of Systems Development at LBNL
- Identify the key activities in each Systems Development phase
- Understand how to choose which Systems Development version to use on an LBNL project
- Understand which deliverables go with which version
- Contrast the Waterfall and Incremental development approaches

- By the end of this module, you will be able to:

## Agenda

**System Development at LBNL**
**System Development Phases**
**System Development Versions**
**Incremental Approach**
**Recommended Reading**

## A.  System Development at LBNL

## Building a System

- Which one should we build?
- How should we organize ourselves?
- What do we want/how should it look?
- Build it.
- Get it ready to use.
- What improvements do we want?

- Identify & Assess
- Plan
- Analyze/Design
- Build
- Implement
- Support & Maintain

## Why Does it Take Sooooo Long?

**What about training?**
**What about security?**
**What about connecting to the networks?**
**How often do reports need to be run?**
**Etc.**

## Why Does it Take Sooooo Long?

## Why Does it Take Sooooo Long?

- It’s just a little bit
- of programming.

- Everyone knows
- how to program
- these days.

## Why Does it Take Sooooo Long?

**Size**
- Number of clients
- Requirements
- Communication
- Security
- Training
- Number of items to build
- A little programming
- Testing
- More Testing
- Still More Testing

**Complexity**
- e.g. -> Web it
- 3 servers cooperating
- And a network
- Development, Testing, Production, and maybe Training = maybe 12 servers

## Why Does it Take Sooooo Long?

**Why Does it Take Sooooo Long?**

**System**

## Why Does it Take Sooooo Long?

**Costs**

**Network**

**Why Does it Take Sooooo Long?**

**Testing**

**Communication**

**Security**

**Programming**

**Requirements**

**Potential**** ****Issues**

**Training**

**Etc....**

**Resources**

**Reports**

## Why Does it Take Sooooo Long?

**Lots of details takes an organized process**

## SEI Capability Maturity Model

**SEI Capability Maturity Model**

## Project Management Maturity Model

**Project Management Maturity Model**

## Speeding it Up

**It can get quicker if you have a repeatable, stable PROCESS**

- RESOURCES 

**Support &**
**Maintain**

**Speeding it Up**

## Speeding it Up

- 3 – 6 Months (or less...)
- Production Deliverables
- Split Large Projects
- Controlled Speed via a **PROCESS**

## B.  System Development Phases

## Building a System

**Which one should we build?**
- How should we organize ourselves?
- What do we want/how should it look?
- Build it.
- Get it ready to use.
- What improvements do we want?

**Identify and Assess **
- Plan
- Analyze/Design
- Build
- Implement
- Support & Maintain

##  Identify & Assess

** ****Identify & Assess**

##  Identify & Assess

**Define Project Objectives & Boundary (Scope)**
- How do we measure success?
**Perform Business Case Analysis **
- What is the business rationale?
**Produce Feasibility Study**
- Can it be done?
**Define Risks and Mitigation Approaches**
- What might stop us, and how do we prevail?
**Identify Value/Benefit to the Enterprise (including ROI)**
- What’s our payback?

##  Identify & Assess

**Produce Initial Funding Requirements for Planning **
- How much will planning cost (in as much detail as we can tell)?
**If EC project, submit Project Request to ECSC**
**     ****	****Else, submit Project Request to Project Sponsor **
- Will this fit in with your larger plans?
**If Request is approved, develop Project Charter**
- What’s the contract?
**If EC project, submit Project Charter to ECSC**
**     ****	****Else, submit Project Charter to Project Sponsor**
- Is this what you want for your money?
**If Charter is approved, go to Planning Phase**

## Identify & Assess

**Objectives**
- External Effects
- Specific
- Measurable
- Attainable
- Realistic
- Timely
- Multiple Objectives may specify different dates

**Boundary (In or Out)**
- Features / Functions
- Organizations
- Resources
- Geographies
**Portray Boundary by drafting:**
- Context Diagram
- Key Event List

**Define Project Objectives & Boundary (Scope)**

## Identify & Assess

**Perform Business Case Analysis**

**Determine the history that led to the current Request**
**Describe the need for the results of the proposed Project**
**Refer to other ongoing efforts that may intersect with this Request**
**Suggest possible outcomes if Sponsors decide to reject this Request**

## Identify & Assess

**Produce Feasibility Study**

**Is the idea doable technically?**
**Are there alternative approaches available?**
**What are the risks?**
**What is the fit with existing systems and procedures?**

## Identify & Assess

**Define Risks and Mitigation Approaches**

**Risks = Attacks on **
- Time
- Cost
- Quality
**Mitigation = How you plan to manage the known risk**
**Look at the System Development Life Cycle (SDLC) Template for suggestions**

## Identify & Assess

**Improved Service**
**Cost savings due to:**
- Avoiding increased staff
- Enabling existing staff to do more
- Avoiding adding capital intensive resources
- Avoiding software costs
**Intangibles**
- Regulations adhered to

**Identify Value /Benefits to the Enterprise **
**including Return On Investment (ROI)**

***Formulate these Outcomes***
***as explicit Objectives***

## Identify & Assess

**Produce Initial Funding Requirements for Planning**

**What are the Gold Owners willing to invest for Chartering and Planning?**
**Refer to earlier project histories for guidance**

## Identify & Assess

**If EC project, submit Project Request to Enterprise Computing Steering Committee **
**Else submit Project Request to Project Sponsor **

**Project Objectives & Boundary (Scope)**
**Business Case Analysis **
**Feasibility Study**
**Risks and Mitigation Approaches**
**Value/Benefit to the Enterprise**
**Initial Funding Requirements for Planning**
**Create a presentation, if it will help**

## Identify & Assess

**If EC project, submit Project Charter to Enterprise Computing Steering Committee**
**Else, submit Project Charter to Project Sponsor**

- Vision/Mission
- External Objectives
- Internal Objectives
- Boundary Exhibits:
- Context Diagram
- Key Event List

***The final choices concerning***
***Charter contents at LBNL are ******still under development.***

- Project Sponsor, Project Director, Project Manager and other key players
- Committed Resources: people time, dollars, tools, training, access, environment, permission to iterate

**Some items that should be in a Charter:**

## Identify & Assess - Deliverables                         

**Identify & Assess - Deliverables           ****              **

- Project Request
- Project Charter

## Building a System

- Which one should we build?
**How should we organize ourselves?**
- What do we want/how should it look?
- Build it.
- Get it ready to use.
- What improvements do we want?

- Identify & Assess
**Plan**** **
- Analyze/Design
- Build
- Implement
- Support & Maintain

## Plan

**Plan**

## Extend Project Team Organization

Conduct Project Kick-Off

Draft Project Plan:
Work Breakdown Structure
Dependency Network
Schedule
Resource Requirements

Draft Plans:
Communications
Risk Management
Change Management

**Conduct Project Kick-Off**
**Draft Project Plan:**
- Work Breakdown Structure
- Dependency Network
- Schedule
- Resource Requirements
**Draft Plans:**
- Communications
- Risk Management
- Change Management

**Plan**

## Plan

**For package, perform high-level Fit / Gap Assessment**
**Define Target Architecture / Technical Requirements / Service Level Requirements**
**Decide on Make or Buy**
**Prepare Project Plans for Analyze/Design Phase**

**Plan**

## Extend Project Team Organization

**Roles & Responsibilities**

**Plan**

**Anticipate the Roles necessary for your project this time around**
**Flesh out IT technical specialists, business specialists and end user roles**
**Recruit participants whose ****skills (and availability) ****match the Roles**

## Conduct Project Kick-Off

**Plan**

**Secure commitment from candidate project team members**
**Gather project team together**
**Formally present Project Charter to team**
**Orient team to the LBNL project management strategy**

## Draft Project Plan:
Project Team Member Roles and Responsibilities
Work Breakdown Structure
Project Dependency Network
Schedule
Resource Requirements

- Project Team Member Roles and Responsibilities
- Work Breakdown Structure
- Project Dependency Network
- Schedule
- Resource Requirements

**Plan**

**Do several rough passes -- whiteboards and Post-it notes**
**Use scheduling software to capture your plan**
**Get commitment to resources before committing to a delivery date**

## Draft Plans:
Communications
Risk Management
Change Management		

- Communications
- Risk Management
- Change Management	**	**

**Plan**

**Use templates to help your speculations**
**Involve the entire team in the planning**
**Cover the  broad view for now**
**Be willing to change your initial draft**

## Plan

**Define high-level System Requirements**

**Of sufficient detail to:**
- Make preliminary determination of feasibility of project
- Estimate resources that are needed
- Assess hardware and software requirements
- Estimate need for equipment or software training
**Acceptable formats:**
- High-level workflow
- Report sets
- Key event list
- Level 1 data flow diagram
- Statement/bullet items

## Plan

**Determine user volumes and transaction variety**
**Determine record counts and volatility**
**Determine reporting and inquiry traffic**
**Look for capability and availability on current infrastructure**
**Plan for acquiring any additional needed capacity**
**Negotiate up-time and availability expectations**
**Negotiate Service Level expectations**

**Define Target Architecture / Technical Requirements / Service Level Requirements**

## Plan

**Plan**

**From High-level System Requirements, Target Architecture and Technical Requirements, survey available vendor offerings that offer a possible fit**
**Determine existing schedules and plans for development staff**
**Check in with Enterprise Computing Strategy**
**If the decision is to make, plan for development**
**If the decision is to buy, begin discussions with vendors**

## Plan

**For package, perform high-level Fit / Gap Assessment**

**If Package-New or Package-Upgrade, begin with Objectives and Key events (from Charter)**
**Review Context Diagram for additional cross-boundary information flows**
**Determine where Package meets and/or misses**
**Plan to Certify the fit; plan to build the rest or ****agree not to build (Charter revision)**

## Plan

**Plan**

**Use Project Planning Templates**
**Create presentation for delivery to sponsoring authority**

## Plan

**Issues Log Starts Now!**

**Extremely important part of the Process**
**Lives through the entire life of the project**

## Plan

**Plan**

- Project Request
- Project Charter

- Project Plan
- Communication Plan
- Risk Management Plan
- Change Management Plan
- Issues Log

## Building a System

- Which one should we build?
- How should we organize ourselves?
**What do we want / how should it look?**
- Build it.
- Get it ready to use.
- What improvements do we want?

- Identify & Assess
- Plan
**Analyze/Design**** **
- Build
- Implement
- Support & Maintain

## Analyze/Design

**Analyze/Design**

## Analyze/Design

**Model Essential System**
**Perform Essence Model Review**
**Prepare Design Specifications**
**Create Data Storage Schema**
**Construct Prototype**
**Draft Service Level Agreement (SLA)**
**Perform Design Review**

## Analyze/Design – Analysis Activities

**Model Essential* System**

**Working from Objectives and Key  Events:**
- Prepare a model of system memory (in Class Diagram or Entity-Relationship format)
- Prepare a model of the life cycle and behavior (state) changes of “interesting” memory components
- Prepare a description of processing taking place during state changes
- Model Information Events; e.g., inquiries, reports, screens

***Essential = everything the system **_**must**_** do, regardless of the means of ****	****       implementation**

## Analyze/Design – Analysis Activities

**Perform Essence Model Review**

**Use Rigorous Review Guidelines**
**Include a broad representation from the Gold Owners and users**

## Analyze/Design – Design Activities

**Analyze/Design – Design Activities**

**Propose candidate technology components**
**Determine interactions among technology components**
**Create control structures within each component**
**Evaluate and design interfaces**
**Research and account for possible ****technology glitches/failures**
**Anticipate volume and load**
**Design backup/restart**

## Analyze/Design – Design Activities

**Create Data Storage Schema**

**Following the guidelines of your database software vendor:**
- Design records
- Design links
- Choose primary and alternate keys
- Evaluate size and volume considerations
- Create navigation paths
- Design data integrity checks and  alerts
- Design backup/restart

## Analyze/Design – Design Activities

**Construct Prototype**

**Using quick-build tools, build a demonstration system for users to play with:**
- Refine the shared understanding of system requirements
- Refine  the user interaction aspects of the design
- Validate design choices

## Analyze/Design – Design Activities

**Draft Service Level Agreement (SLA)**

**Based on Service Level Expectations (from Planning) and user experience with the Prototype:**
- Formalize the Service Level Agreement

## Analyze/Design – Design Activities

**Perform Design Review**

**Use Rigorous Review Guidelines**
**Include a broad representation from technology and operations experts**

***Stay in touch with******the Issues Log!***

## Analyze/Design – Design Activities

**Rigorous Review Guidelines**

**Intention: **to accept group responsibility for the quality of the _review_
- The producer remains responsible for the quality of the _work_
**Flow of communication: **from the reviewers to the work
**Length: **one hour (no exceptions)
**Participants: **5 persons, 7 roles

- Facilitator
- Recorder
- Producer
- Discipline specialist

- Gold Owner representative
- Futures wizard
- Best practices captain

## Analyze/Design – Design Activities

**Rigorous Review Guidelines - Protocol**

**Producer**
- Creates work
- Invokes review gathering
- Establishes venue and time
- Distributes copies/access to the work
- May observe
**Facilitator**
- Starts on time / adjourns on time
- Confirms participant preparedness
- Manages information flow / guides recorder
- Facilitates group consensus, evaluating quality of work
- Creates review report

## Analyze/Design – Design Activities

**Rigorous Review Guidelines - Protocol**

**Recorder**
- Keeps public notes of salient commentary
**Off-Limits:**
- Any attempt to explain or justify the work
- Any suggestions for refinement or corrections
- Any criticism of persons
- Discussion of Best Practices
- Extraneous discussion
**Levels of Evaluation:**
- Work makes us proud
- Work needs minor revision
- Let’s schedule another review

## Analyze/Design - Deliverables 

**Analyze/Design - Deliverables**** **

- Project Request
- Project Charter

- Project Plan
- Communication Plan
- Risk Management Plan
- Change Management Plan
- Issues Log

- Essential Data Model
- Essential Process Model
- Essential State Change Model
- Essential Data Dictionary
- Design Specifications
- Data Storage Schema
- Prototype
- Test Plans
- Service Level Agreements

## Building a System

**Building a System**

- Which one should we build?
- How should we organize ourselves?
- What do we want/how should it look?
**Build it.**
- Get it ready to use.
- What improvements do we want?

- Identify & Assess
- Plan
- Analyze/Design
**Build**
- Implement
- Support & Maintain

## Build

**Build**

## Build

**Code**
**Unit Test**
**Perform Use Case Scenario**
**Perform System Test**
**Initiate Go Live Plan**
**Perform Stress Test**
**Perform User Acceptance Test**

## Build

**Code**

**Create or modify source code: views, interfaces, application**
**Follow up to see that in-line commentary matches the execution of the code**

## Build

**Unit test**

**Execution of individual routines and modules**
**Performed by developer or independent tester**
**For purpose of finding defects**

## Build 

**Perform Use Case Scenario**

**Sequence of key events necessary for completion of a business operation**
**Capture user interaction details**

## Build

**Perform System Test**

**Systematic exercise of an entire program**
**Performed by developer and users**
**For purpose of finding defects**

## Build

**Initiate Go Live Plan**

**Propose Go Live dates**
**Secure agreement to dates**
**Go Live Communication Plan**

## Build

**Perform Stress Test**

**Oblige the system to perform with:**
- Peak volumes
- Peak user interaction
**To discover:**
- Performance characteristics
- Bog-down situations
- Unexpected impact on other processes

## Build

**Perform User Acceptance Test**

**Prepare user acceptance questionnaire**
**Invite users to perform real work simulations**
**Invite commentary and questions**
**Administer questionnaire**
**Revise system per feedback**
**Seek formal acceptance from ****sponsors**
**Plan to do another acceptance ****test after Go Live**

## Build - Deliverables                         

**Build - Deliverables      ****                   **

- Project Request
- Project Charter

- Project Plan
- Communication Plan
- Risk Management Plan
- Change Management Plan
- Issues Log

- Essential Data Model
- Essential Process Model
- Essential State Change Model
- Data Dictionary
- Design Specifications
- Data Storage Schema
- Prototype
- Test Plans
- Service Level Agreements

- Code
- All Test Results
- Go Live Plan

## Building a System

**Building a System**

- Which one should we build?
- How should we organize ourselves?
- What do we want/how should it look?
- Build it.
**Get it ready to use**.
- What improvements do we want?

- Identify & Assess
- Plan
- Analyze/Design
- Build
**Implement**
- Support & Maintain

## Implement

**Implement**

## Implement

**Train Clients**** **
**Finalize Go Live Plan**** **
**Finalize System Documentation**** **
**Define the Support Model**** **
**Go Live**

## Implement

**Train Clients**

**Secure venue (way in advance)**
**Decide on level of training**
**Publish training calendar**
**Determine audience**
**Create training materials**
**Formalize user procedures**
**Identify training database**

## Implement

**Finalize Go Live Plan**

**Anticipate Go / No Go points**
**Sequence of installation points**
**Transition Management**

**Show-stopping Issues Resolved**

## Implement

**Finalize System Documentation**

**Checklist for planners to think about:**
- System services
- System technology
- Libraries/ version control
- Process
- Sequencing
- Scheduling
- Responsibilities
- Security
- Customization history
- Changes to essence models
- Attend to appropriate archiving

## Implement

**Define the Support Model**

**Identify individuals and access detail for:**
- Initial point of contact
- Application problems
- Technology problems
- Fix requests

## Implement

**Go Live**

**Review Plan**
**Rehearse, at least once**
- Anticipate timings
**Throw the switch (perform installation events)**
**Audit / check-out**
**CELEBRATE!**

## Implement - Deliverables

**Implement - Deliverables**

- Project Request
- Project Charter

- Project Plan
- Communication Plan
- Risk Management Plan
- Change Management Plan
- Issues Log

- Essential Data Model
- Essential Process Model
- Essential State Change Model
- Data Dictionary
- Design Specifications
- Data Storage Schema
- Prototype
- Test Plans
- Service Level Agreements

- Code
- All Test Results
- Go Live Plan

- Go Live Client Acceptance Sign-Off
- Training Materials
- User Procedures
- System Document-ation
- Support Model

## Slide 80

## Building a System

- Which one should we build?
- How should we organize ourselves?
- What do we want/how should it look?
- Build it.
- Get it ready to use.
**What improvements do we want?**

- Identify & Assess
- Plan
- Analyze/Design
- Build
- Implement
**Support & Maintain**** **

## Support & Maintain

**Address Business Requirements Delayed from Earlier Phases**
**Certify Deliverables and Accomplishments**
**Conduct Project Retrospective**
**Prepare for Ongoing Support for Clients **

## Support & Maintain

**Address Business Requirements Delayed from Earlier Phases**

**Determine if change request or new project**

## Support & Maintain

**Certify Deliverables and Accomplishments**

**Takes place at dates associated with objectives**
**Completes the loop with Gold Owners ****showing the outcomes of their ****investment**

## Support & Maintain

**Conduct Project Retrospective**

**Wait for a time, until the system and its users settle in**
**Arrange a venue (off-site if possible) where all project participants can gather**
**Create (with the help of project artifacts) ****the experiences of the project, over a ****timeline**
**Create (with the help of stories) ****the feelings of the project**
**Celebrate successes**
**Take lessons from failures **

## Support & Maintain - Deliverables 

**Support & Maintain - Deliverables**** **

- Project Request
- Project Charter

- Project Plan
- Communication Plan
- Risk Management Plan
- Change Management Plan
- Issues Log

- Essential Data Model
- Essential Process Model
- Essential State Change Model
- Data Dictionary
- Design Specifications
- Data Storage Schema
- Prototype
- Test Plans
- Service Level Agreements

- Code
- All Test Results
- Go Live Plan

- Go Live Client Acceptance Sign-Off
- Training Materials
- User Procedures
- System Document-ation
- Support Model

- Project Lessons Learned

## Who Does What?

| SDLC | Project Director Responsible | Project Manager Responsible | Joint Effort |
| --- | --- | --- | --- |
| Phase 1
Identify & Assess | Project Request |  | Project Charter |
| Phase 2
Plan | Communication Plan
Change Management Plan | Project Plan
Issues Log | Risk Management Plan |
| Phase 3
Analyze/Design |  | Essential Data Model
Essential Process Model
Essential State Change Model
Test Plans
Design Specifications
Data Storage Schema
Prototype | Data Dictionary
Service Level Agreements |
| Phase 4
Build |  | Code
All Test Results | Go Live Plan |
| Phase 5
Implement | Go Live Client Acceptance Sign-Off | System Documentation
Support Model | User Procedures
Training Materials |
| Phase 6
Support & Maintain |  | Project Lessons Learned | Certify Accomplishments |

## C.  System Development Versions

## System Development Versions

**Do we have to go through all the same steps if it’s a vendor software package?**
**What if it’s a small project?**
**What’s the difference between a development project and an enhancement request?**

## System Development Versions

**In-House Development / Enhancement Release**
** ****Lite**
** ****Large**
**Vendor Software Package**
** ****New**
** ****Upgrade**

## System Development Versions

**In-House Development**
*   **Custom development of a software application*
**Enhancement Release**
**   ***Set of modifications which add features to the system and are made available in the form of a new version of the software application*
**Vendor Software Package**
*   **Software application that was not developed in-house*

## System Development Versions

**Lite Dev/ER or Minor Package Upgrade**
-  Low risk and
-  < 100 person-hours
**Large Dev/ER or New or Major Package Upgrade**
-  High risk or
-  > 100 person-hours

## System Development Versions

- Project Request
- Project Charter

- Project Plan
- Communication Plan
- Risk Management Plan
- Change Management Plan
- Issues Log

- Code
- All Test Results
- Go Live Plan

- Go Live Client Acceptance Sign-Off
- Training Materials
- User Procedures
- System Document-ation
- Support Model

- Project Lessons Learned

- Essential Data Model
- Essential Process Model
- Essential State Change Model
- Data Dictionary
- Design Specifications
- Data Storage Schema
- Prototype
- Test Plans
- Service Level Agreements

**Do all versions have to produce all these deliverables?**

## System Development Versions

**Lite In-House Development / Enhancement Release**
**Minor Package Upgrade**
- Why fill out all the paperwork?
- Every question still needs to be answered!
- SDLC templates are guidelines

## System Development Versions

**Large In-House Development / Enhancement Release**
**New Package or Major Package Upgrade**
- Use all project deliverables to keep project activities under control
- Remember the Capability Maturity Model
- Requirements are mapped from Essential Data Model to       Package Definitions to produce Fit / Gap Analysis
-  Impacts:
-  Business process
-  Infrastructure

## System Development Versions

|  | Work Breakdown Structure | Formal Network | Calendar | Resource |
| --- | --- | --- | --- | --- |
| Lite Dev/ER and
Package Minor Upgrade | Y | Y | Y | Sort of |
| Large Dev/ER 
and
Package New/Major Upgrade | Y | Y | Y | Y |

**Do all Projects do all this?**

## Defines which deliverables are:

**System Development Versions**

**M – Mandatory****	****	****	**Required
**R – Recommended****	****	**Important but not required
**S – Suggested****	****	****	**Good business practice
**O – Optional**
**N/A – Not applicable**

**Deliverables Matrix**

## System Development Versions

**Deliverables Matrix**

## System Development Versions

**Deliverables Matrix**

## D.  Incremental Approach

## Which Curve is it?

## System Development Life Cycle

**Historically the lifecycle used for EC projects**
**Traceable to ISO 12207 standard**
**Also called System Development Life Cycle (SDLC)**
**Oldest and most widely used approach to system development, it was developed by Royce in 1970**

**The***** ***_***Waterfall***_*** *****Lifecycle**

## Going over the Waterfall in a Barrel

**The likelihood of getting it right the first time is zero**
**Real projects rarely follow the sequential process -- iteration through the cycles is required**
**It is impossible for the customer to state all requirements explicitly at the start of the development lifecycle**
**Metrics resulting from Waterfall phases are usually skewed toward the plan rather than the reality**

**System Development Life Cycle**

## System Development Life Cycle

**The customer must be patient -- a working version only becomes available late in the development lifecycle**
**The team gets, at most, one chance to celebrate success**
**Any feedback/lessons learned from any phase are lost for the current project**
**Gold Owners must sustain funding for the entire project in order for the project team to be able to install anything useful**

**System Development Life Cycle**

## System Development Life Cycle

**The Waterfall approach was invented when computing technology was expensive –- hardware is now a commodity**
**A clean separation of phases is unrealistic**
**The linear process creates schedule slip and cost growth**
**Detailed project plans are less and less accurate the further out in time they are**

**A Waterfall – Without water it’s a cliff...**

## Incremental Approach

**Also called spiral or iterative**
**Deployable increments offer the team the ability to track the project based on real work**
**There is still residual value if the project is terminated midstream**
**All system disciplines become lifestyles rather than episodes**

**The Alternative: Incremental Development**

## Incremental Approach

**Timebox the entire incremental timeline**
**Each timebox duration = 2-12 weeks**
**At the end of every timebox increment -- deliver an end-to-end working version of one or more Key Events**

**Timebox**

## Incremental Approach

***Discretionary***
**    **examples:
-            - customer pays invoice
-            - sensor reports temperature exceeds threshold
-            - manager requests summaries
***Temporal***
**    **examples:
-            - Jan. 31 (time for 1099s & W2s)
-            - rental period expires

**Key Events may be:**

## Incremental Approach

## Incremental Approach

**Some Key Event Responses are small/well understood**
**Some Key Event Responses are large/uncharted**
**A minimum of two increments for the easy ones**
**Maybe four or five increments for the scary ones**
**    **
**Each successive increment delivers a more complete version of the Response**

**Key Event Responses**

## Incremental Approach

**Key Event:**

**An occurrence beyond the boundary of the system**
**It is instantaneous**
**It gives rise to a stimulus that crosses our boundary and provokes a response that is:**
- Planned
- Essential
- Systematic
- Instantaneous
**   **

## Incremental Approach

_**Increment I**_
- Key Event 6, version1
- Log on, capture ID + profile, confirm capture
_**Increment II**_
- Key Event 6, version 2
- Add facilities assignment, issue facilities authorization
- Key Event 1, version1
- Set up Customer preferences, confirm changes

**Increment Planning**

## Incremental Approach

_**Increment III**_
**	**Key Event 1, version 2
- 		Change Customer Preferences, confirm changes
- 	Key Event 8, version 1
- 		Create Customer/Facilities account
_**Increment IV**_
**	**Key Event 1, version 3
- 		Add Customer Usage permissions, confirm permissions
- 	Key Event 8, version 2
- 		Add history capability to Customer/Facilities account

**Increment Planning ****cont.**

## Incremental Approach

-  I&A

- P

- A/D

-  B

- I

-  S&M

-  I&A

- P

- A/D

-  B

- I

-  S&M

-  I&A

- P

- A/D

-  B

- I

-  S&M

-  I&A

- P

- A/D

-  B

- I

-  S&M

-  I&A

- P

- A/D

-  B

- I

-  S&M

-  I&A

- P

- A/D

-  B

- I

-  S&M

-  I&A

- P

- A/D

-  B

- I

-  S&M

-  I&A

- P

- A/D

-  B

- I

-  S&M

-  I&A

- P

- A/D

-  B

- I

-  S&M

-  I&A

- P

- A/D

-  B

- I

-  S&M

-  I&A

- P

- A/D

-  B

- I

-  S&M

-  I&A

- P

- A/D

-  B

- I

-  S&M

**Cycle      Cycle      Cycle       Cycle      Cycle      Cycle       Cycle       Cycle      Cycle       Cycle      Cycle      Cycle**
**    ****1             2              3              4              5              6              7              8              9             10            11            12**

**Etc....**

## Incremental Approach

**Tracking Key Event Progress**

## Incremental Approach

**Overly-detailed planning up to the end**
- Planning must be continual...
- Planning must not drive beyond headlights...
**Starting before adequate planning**
**Urge to postpone difficult problems**
**Ignoring new risks**
**Pushing for too much in the early increments**
**Too many increments**
**Overlapping increments**

*From Philippe Kruchten, Rational Software Development*

**Traps**

## Incremental Approach

**Which Wedge is 30 degrees?**

**Why is Incremental Better?**

## Incremental Approach

**Incremental Approach**

**Error at 10 feet; 1 mile**

- A = 3.6 in; 157ft
- B = 1.8 in; 79ft
- C = 1.8 in; 79ft
- D = 3.6 in; 157ft

**Which Wedge is 30 degrees?**

## Incremental Approach

**Integrated project core teams**
**Progress is cumulative and **_**measurable**_
***Chicken tests *****are done early**
***Surprises***** are less costly**
**User requirements and delivered capabilities have greater overlap**
**Residual value if project stopped midstream**
**Recurring opportunities for celebration**
**Opportunity to capture realistic metrics**
**Lessons learned are fed back into current project**
**Increased quality within same timeline**

**Advantages:**

## E.  Recommended Reading

## Recommended Reading

- Systems Analysis and Design Methods by Jeffrey L. Whitten, Lonnie D. Bentley, Kevin C. Dittman
- What Every Programmer Should Know About Object-Oriented Design by Meilir Page-Jones, Larry L. Constantine
- Fundamental Concepts of Information Modeling by Matt Flavin
- Object Technology: A Manager's Guide by David A. Taylor
- Essential Systems Analysis by Stephen M. McMenamin, John F. Palmer
- Project Retrospectives: A Handbook for Team Reviews by Norman L. Kerth