Process Management & Project Management Capstone Courses.

Process ManagementProcess Management&&

Project Management Project Management

Capstone CoursesCapstone Courses

Shocking Statistics

• Some organizations are 10 (even 600) times more productive than others(1)

• Most Software Projects Fail• Some definitions for Failure:

– Missed schedule– Missed functionality– Missed budget– Too fragile for usage demands– Defect rates too high once in production(1) Steve McConnell, After the Gold Rush. Redmond, WA. Microsoft Press, 1999.

Shocking Statistics

• In 1995, only 16% of software projects were expected to finish on time and on budget.(1)

• Projects completed by the largest US organizations have only 42% of originally proposed functions.(1)

• An estimated 53% of projects will cost nearly 190% of their original estimates.(1)

• In large companies, only 9% of projects will be completed on time and on budget.(1)

(1) Standish Group International Report, “Chaos”, as reported in March ‘95 Open Computing. Copyright 1995 SPC.

Shocking Statistics

• Canceled projects—$81 billion loss to US in 1995(1)

• Average MIS—1 year late, 100% over budget(2)

(1) Standish Group International Report, “Chaos”, as reported in March ‘95 Open Computing. Copyright 1995 SPC.(2) Capers Jones, Applied Software Measurement, McGraw-Hill, 1991.

Project Management

Tasks Time

RisksMoney

People Relations

Project management frameworkProject management framework

Objectives

Logistics

Technical Resources

Introductory Parts

• Background (what is wrong with the AS-IS system)• Problem Statement (what should be done TO-BE system)• Market Research

Previous work is well defined and analyzed (Literature Review) with proper citation  

• Methodology Selection Methodology is well defined and evaluated quantitatively ( evaluation matrix) with Pre/Post Analysis

• Glossary• Project Organization

The proposal is well organized with numbering, title page , references and appendix.

Money Management

• Cost Estimation– COCOMO– Function Points

• Cost Benefit Analysis– ROI– NPV– BEP– More!

WBS• Breakdown structures• Breakdown phases into sub phases• Breakdown sub phases into tasks• Breakdown tasks into subtasks• Estimate durations (starting and ending times)• Determine predecessors • Allocate resources

Top Down Task Identification

PhasesPhases with

high level steps

Work Plan Deliverables Estimated Actual Assignedhours hours To

****

A Gantt Chart

A PERT Chart

PERT Chart Showing Activities and Sequence

Risk Management

• Identify Risks

• Measure Risks

• Suggest Strategies to reduce vulnerabilities

Boehm’s top ten risk items• Personnel shortfalls• Unrealistic schedules and budgets• Developing the wrong functions• Developing the wrong user interfaces• Gold-plating• Continuing stream of requirements changes• Shortfalls in externally-performed tasks• Shortfalls in externally-furnished components• Real-time performance shortfalls• Straining computer science capabilities

Risk management requirements

• Risk impact: the loss associated with the event

• Risk probability: the likelihood that the event will occur

• Risk control: the degree to which we can change the outcome

Risk exposure = (risk probability) x (risk impact)

Three strategies for risk reduction

• avoiding the risk: change requirements for performance or functionality

• transferring the risk: transfer to other system, or buy insurance

• assuming the risk: accept and control it

risk leverage = difference in risk exposure divided by cost of reducing the risk

Process Management

• Starting from Fall 2005, we unleashed a new version of the capstone course experience that is more adaptive, more team-intensive and more speedy.

• This version is a response to our evolutionary capstone experience in real world projects in which change management, effective collaboration and agility have been dominant factors in influencing team performance and problem solving quality.

• Our approach benefits tremendously from agile software development strategies with more emphasis on Scrum and FDD (feature driven development) as key models.

The Venerable Waterfall Process

AnalysisAnalysis

DesignDesign

ImplementationImplementation

TestingTesting

MaintenanceMaintenance• Postpones Confronting Risk• Late Design Breakage

• Can work on well-defined efforts

• Can work in smaller efforts• Great for reporting apparent progress

SCRUM

Scrum• Scrum – an activity that occurs during a rugby match.• Scrum—distinguishing features

– Development work is partitioned into “packets”– Testing and documentation are on-going as the product is

constructed– Work occurs in “sprints” and is derived from a “backlog” of

existing requirements– Meetings are very short and sometimes conducted without chairs– “demos” are delivered to the customer with the time-box

allocated• Scrum incorporates a set of process patterns that emphasize project

priorities, compartmentalized work units, communication, and frequent customer feedback.

Scrum Principles

• Small working teams used to maximize communication and minimize overhead

• Process must be adaptable to both technical and business challenges to ensure best product produced

• Process yields frequent increments that can be inspected, adjusted, tested, documented and built on

• Development work and people performing it are partitioned into clean, low coupling partitions

• Testing and documentation is performed as the product is built

• Ability to declare the product done whenever required

Scrum - 1

• Backlog– prioritized list of requirements or features the provide

business value to customer

– items can be added at any time)

• Sprints– work units required to achieve one of the backlog items

– must fit into a predefined time-box

– affected backlog items frozen

Scrum - 2

• Scrum meetings– 15 minute daily meetings– what was done since last meeting?– what obstacles were encountered?– what will be done by the next meeting?

• Demos– deliver software increment to customer for

evaluation

By Kevin Aguanno. (C) 2002 Element K Journals.

Feature 1

Feature 3

Feature 7

Feature 2

Feature 4

Feature 5

Feature 6

Grouped List of Features

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5

Feature 6

Feature 7

Initial List of Features

Planning

Sprint #1

Sprint #2

Inte

gra

ted

Dem

on

stratio

n

Closure

Product Backlog

SCRUM Structure

SCRUM – Project Structure

(C) 2002 Kevin Aguanno.

SCRUM projects are not "Out of Control" and, in fact, have several good management and control elements:

Daily SCRUM Meeting. This is a daily meeting attended by all team members for a Sprint. The call is generally very brief (15 mins.), the purpose of which is to update the project manager and other team members on progress and to raise any issues that the project manager or other team members can assist with. Three questions are answered by each participant:

What did I do in the last 24 hours? What do plan to do in the next 24 hours? What obstacles are standing in my way?

Visible Progress Demonstration. At the end of each Sprint, the customer and all project team members get to see a visual demonstration of progress to date. Customer feedback can be obtained early in the process this way, and avoid costly changes late in the project lifecycle. Overall project progress is very visible and very easy to track in this way via a function/feature checklist, function points, or other similar means.

SCRUM – Management Controls

Text (C) 2002 Kevin Aguanno. Chart (C) 1997 Advanced Development Methods Inc.

Sprint Burndown Charts. During a Sprint, the team provides an updated estimate on the number of hours/days to complete their work during the daily SCRUM meetings. The project manager can use this data to build a Sprint Burndown Chart showing the progress within a Sprint. The total projected number of hours for a Sprint usually increases in the early days of the Sprint as nuances and additional work are uncovered, but then rapidly decline as work gets underway.

SCRUM – Management Controls

(C) 2002 Kevin Aguanno.

Accelerated Customer Approval. Because the customer reviews visible deliverables at the end of each Sprint and provides feedback at that time, coupled with the fact that subsequent Sprints build upon the work of earlier Sprints, the final output should not contain any surprises to the customer and will already include the bulk of his feedback. This should allow for a faster final customer approval/acceptance of the deliverables.

SCRUM – Management Controls

A Solution

• Feature-Driven Development– Client-centric– Architecture-centric– Repeatable process– Pragmatic, livable methodology– Great for developers– Great for managers– Great for the application!

Feature Driven Development• Practical process model for OO SW engineering.• Applicable to moderate sized and larger SW projects.• FDD—distinguishing features

– Emphasis is on defining “features”• a feature “is a client-valued function that can be implemented in two weeks or less.”

– Uses a feature template• <action> the <result> <by | for | of | to> a(n) <object>

– A features list is created and “plan by feature” is conducted– Design and construction merge in FDD

• FDD puts a greater emphasis on project management guidelines and techniques than many other agile methods.

• Defines 6 milestones during the design and implementation of a feature– design walkthrough, design, design inspection, code, code inspection, promote to

build.

Feature Driven Philosophy

• Emphasizes collaboration among team members

• Manages problem and project complexity using feature-based decomposition followed integration of software increments

• Technical communication using verbal, graphical, and textual means

• Software quality encouraged by using incremental development, design and code inspections, SQA audits, metric collection, and use of patterns (analysis, design, construction)

Feature Driven Design - 1

• Develop overall model– contains set of classes depicting business model of application to

be built

• Build features list– features extracted from domain model

– features are categorized and prioritized

– work is broken up into two week chunks

• Plan by feature– features assessed based on priority, effort, technical issues,

schedule dependencies

Feature Driven Design - 2

• Design by feature– classes relevant to feature are chosen

– class and method prologs are written

– preliminary design detail developed

– owner assigned to each class

– owner responsible for maintaining design document for his or her own work packages

• Build by feature– class owner translates design into source code and performs unit

testing

– integration performed by chief programmer

Why the FDD Process?

• To enable and enforce – the repeatable delivery of – working software in a – timely manner with – highly accurate and meaningful reporting to– all key stakeholders inside and outside a

project.

The FDD Process in Brief

FDD #1Develop

anOverallModel

FDD #2 Build

aFeatures

List

FDD #3

Planby

Feature

FDD #4

Designby

Feature

• 5 Major Steps/Activities

FDD #5

Buildby

Feature

Requirements& Design

Design,SomeCode

Code,Initial

Testing

Test& Put

in Build

Sched.&

$$ Est.

Build

Promoteto

Build

Build

Promoteto

Build

Priorit

ized

Releas

es

#4#4

• #1 & #2 are Reqt’s & Design throughModeling/Coding/ Prototyping to get it right

• #4 is very granular Detailed Design/Code

• #5 is Detailed Code and Test in very,very granular

chunks of client-valued functionality

FDD & Typical SDLC Phases

AnalysisAnalysis

DesignDesign

ImplementationImplementation

TestingTesting

MaintenanceMaintenance

#1#1#2#2 #5#5

Reminder:

• Why FDD #1 & #2 Processes’ Emphasis on Requirements & Design?– Studies have shown conclusively that it pays to do

things right the first time– Unnecessary changes are expensive– TRW: a change in requirements-analysis cost 50-200

times less than same change later in the cycle (construction-maintenance). Boehm, Parpaccio 1988

– IBM: removing an error by the start of design, code or unit test allows rework to be done 10-100 times less expensively than during unit test or functional test. Fagan 1976

FDD “Engineering” Outputs

FDD #1Develop

anOverallModel

FDD #2 Build

aFeatures

List

FDD #3

Planby

Feature

FDD #4

Designby

Feature

FDD #5

Buildby

Feature

An object model (more shape than content)

A categorized list of features

A Develop-ment Plan

FDD “Construction” Outputs

An object model (more shape than content)

FDD #1Develop

anOverallModel

FDD #2 Build

aFeatures

List

FDD #3

Planby

Feature

FDD #4

Designby

Feature

FDD #5

Buildby

Feature

A categorized list of features

A Develop-ment Plan

A design pack-age (sequences)(more content than shape)

A client-valued function

Dec 2001

Completion Percentage:

Completion Status:

Completed

Targeted Completion Month

Example:Feature Set:

Making Product Assess’ts – Work in Progress

CP-1 is the Chief Programmer’s initials

(14) there are fourteen features that make up this feature set

75% Feature Set is 75% complete

Target is to complete in Dec 2001

Overall Status:

MY

Progress bar

Work in progress

Attention (ie, Behind)

Completed

MakingProduct

Assessments(14)

75%Not yet started

CP-1

FDD UML Extensions (iii)

Product Sale Management (PS)

InvoicingSales

(33)

Dec 2001

CP-1

Setting upProduct

Agreements(13)

Dec 2001

SellingProducts

(22)

Nov 2001

CP-1

ShippingProducts

(19)

Dec 2001

CP-1

10%

DeliveringProducts

(10)

Dec 2001

CP-3

30%

MakingProduct

Assessments(14)

Dec 2001

75%99% 3%

Customer A/C Mgmt (CA)

EvaluatingAccount

Applications(23)

Oct 2001

95%

LoggingAccount

Transactions(30)

Nov 2001

82%

OpeningNew

Accounts(11)

Oct 2001

100%

Inventory Mgmt (IM)

EstablishingStorage Units

(26)

Nov 2001

100%

MovingContent

(19)

Nov 2001

82%

CP-3

AcceptingMovementRequests

(18)

Nov 2001

97%

CP-3

KEY: Work In Progress Attention Completed Progress Bar Not Started

CP-2 CP-1

CP-2 CP-2 CP-2 CP-3

FDD Sample Feature Sets

FDD Plan View

FDD Feature View

FDD Weekly Summary

FDD Weekly Summary (ii)

• Where/how does it fit into s/w development practices– In modern software development methodologies, there is a

large degree of iterative development.– Productive modeling environments automatically

synchronize source code and class diagrams– This implies that you take successive passes at the system,

adding new information and capability along the way.

Fitting UML into Development

InceptionInception IterativeElaboration

IterativeElaboration

Iterative Construction

Iterative Construction TransitionTransition

The Utility of UML

• Helps to promote standard communication– But does not supplant human contact!

• Class Diagrams are very useful• Sequence and Activity help with dynamics• Use Cases

– Useful if your organization has meaningful way to apply them—no silver bullet

– Can be replaced by other means of capturing features/requirements

FDD UML Extensions

• Report progress to management and clients

• Very high level (major feature sets)MS-RMS-R

<<major feature set>>

Cash Sale Management

Creating Cash Sales

Delivering Cash Sales

(2)

27%

Dec 1999

JKJK

<<major feature set>>

Product Sale Management

Selling Products

Shipping Products

Delivering Products

Accepting Payments

Ordering Products

Creating Orders

(6)

22%

Dec 1999

• These reflect UML extensionsmade in Together®

FDD UML Extensions (ii)

EdEd

<<feature set>>

Delivering Products

UseCase1

UseCase2

UseCase3

UseCase4

UseCase5

UseCase6

UseCase7

UseCase8

UseCase1

(8)

100%

Aug 1999

JonJon

<<feature set>>

Creating Orders

UseCase1(1)

%

DougDoug

<<feature set>>

Ordering Products

UseCase1

UseCase2

UseCase3

UseCase4

UseCase5

UseCase6

(16)

0%

Dec 2002

MikeMike

<<feature set>>

Shipping Products

UseCase1

UseCase2

UseCase3

UseCase4

(4)

22%

Jan 2000

MartyMarty

<<feature set>>

Selling Products

Calculate the Total of a Sale

Asses the Fulfillment Timeliness of a Sale

Feature1

Feature2

Feature3

Feature4

Feature5

Feature6

Feature7

Feature8

Feature9

Feature10

(12)

27%

Dec 1999

FreedyFreedy

<<feature set>>

Accepting Payments

Feature1

Feature2

(2)

22%

Jan 1999

• Next level down (feature sets) Chief Programmer

# Features % Complete(color too) Due Date

Overdue!