Software Project Management

Software Project

Management

•

Project:

ƒ

unique process, consisting of a set of

coordinated and controlled activities with

start and finish dates, undertaken to achieve

an objective conforming to specific

requirements, including the constraints of

time, cost and resources.

ƒ ISO 9000:2005 - Quality management systems - Fundamentals and

Software Project

Management

Phases

•

Definition

goals, players, stakeholders, resources, constraints, deliverables, success-criteria

•

Planning

work-breakdown-structure, work-packages, activities,

package/activity relations, resource planning, scheduling

•

Execution

monitoring, evaluation, correcting actions, communication

•

Closing

Definition phase

•

Fundamental goals

(correspondence to organization‘s

goals, commitment, top-management support)

•

Outcomes

(„deliverables”)

•

Players

participants, stakeholders, project organization

structure

•

Success-criteria

•

Resource estimation

•

Timing, scheduling

Planning phase

ƒ

Work Breakdown Structure

(well-defined activities, responsibilities, milestones)

ƒ

Pert Chart

(logical activity structure, dependencies, overlapping)

ƒ

Gantt Chart

(timing, SS, FS, FF dependencies)

ƒ

Critical Path

(slack-times, ASAP, ALAP scheduling)

ƒ

Resource Planning

(human, tangible, tools, cost, cashflow)

Planning phase

•

Work Breakdown Structure

ƒ

The development of a WBS divides the overall project

into an interconnected set of manageable components.

Typically, the WBS is a product oriented structure that

provides a scheme for identifying and organizing the

logical units of work to be managed, which are called

“work packages.”

Planning phase

•

Pert chart

ƒ

The Program Evaluation and Review Technique

(PERT) is a network model that allows for

randomness in activity completion times.

Planning phase

•

PERT planning involves the following steps:

1.

Identify the specific activities and milestones.

2.

Determine the proper sequence of the activities.

3.

Construct a network diagram.

4.

Estimate the time required for each activity.

5.

Determine the critical path.

Planning phase

•

Dependencies

•B

•A • Start to finish (SF)

• B can finish only if A started

•A •B • Start to start (SS)

• B can start only if A started

•A •B • Finish to start (FS)

• B can start only if A ended

•A •B • Finish to finish (FF)

Planning phase

•

Determine the following quantities for

each activity:

ƒ

ES - Earliest Start time

ƒ

EF - Earliest Finish time

ƒ

LS - Latest Start time

ƒ

LF - Latest Finish time

ƒ

D – Duration

Planning phase

•

Critical Path: the longest possible continuous pathway

taken from the initial event to the terminal event. It

determines the total calendar time required for the

project; and, therefore, any time delays along the

critical path will delay the reaching of the terminal

event by at least the same amount.

•

Critical Activity: An activity that has total float equal

to zero. Activity with zero float does not mean it is on

critical path.

Planning phase

ƒ

Work Breakdown Structure

(well-defined activities, responsibilities, milestones)

ƒ

Pert Chart

(logical activity structure, dependencies, overlapping)

ƒ

Gantt Chart

(timing, SS, FS, FF dependencies)

ƒ

Critical Path

(slack-times, ASAP, ALAP scheduling)

ƒ

Resource Planning

(human, tangible, tools, cost, cashflow)

Planning phase

ƒ

Work Breakdown Structure

(well-defined activities, responsibilities, milestones)

ƒ

Pert Chart

(logical activity structure, dependencies, overlapping)

ƒ

Gantt Chart

(timing, SS, FS, FF dependencies)

ƒ

Critical Path

(slack-times)

ƒ

Resource Planning

(human, tangible, tools, cost, cashflow)

Planning phase

-Resource Planning

•1. •2. •3. •4.

•

Over allocation

•

Time

•Resources

•

Availability

Planning phase

-Resource Planning

•1. •2. •3. •4. •Resources

•

Availability

Planning phase

ƒ

Work Breakdown Structure

(well-defined activities, responsibilities, milestones)

ƒ

Pert Chart

(logical activity structure, dependencies, overlapping)

ƒ

Gantt Chart

(timing, SS, FS, FF dependencies)

ƒ

Critical Path

(slack-times)

ƒ

Resource Planning

(human, tangible, tools, cost, cashflow)

Categories

I. prepare alternative solutions

II. prevention techniques III. negligible Monitoring in execution phase

Risk Management

Impact High Medium Low

High Medium Low Likelihood of occurrence

Category I.

Category II.

Category III.

Execution phase

ƒ

monitoring

(how to measure progress, data acquisition,

evaluation, plan-fact comparison)

ƒ

difference-analysis

(reasoning, impact prediction)

ƒ

intervention

ƒ

modification of plan

Execution phase

•

Project monitoring, controlling:

ƒ

Progress is primarily determined by comparing

actual work product and task attributes,

effort, cost, and schedule to the plan at

prescribed milestones or control levels within

the project schedule or work breakdown

Closing phase

ƒ

Evaluation: measuring and evaluation success

factors

ƒ

Summarizing experiences

(most efficient way to learn: analyze your mistakes)

ƒ

Declaration: Project is closed

Inception Elaboration Construction Transition

User use-cases

High level package structure

Developer use-cases, communication diagrams

Class diagrams

Coding modules, integration

not constant intensity

Incremental controlled iteration

I E C T I E C T I E C T round 1 round 2 round 3

OO development lifecycle

Problems

ƒ

Project Plan requires some progress in analysis

Where is project planning in the lifecycle<

Anywhere at the beginning of the first I phase

Costs not more, than 5 – 10 % of the total

budget

ƒ

How to estimate?

ƒ

What organizational structure is efficient?

ƒ

How to manage the phases and

Estimation

ƒ

Imprecise (25% tolerance), but enough for go/no go

decision

ƒ

make this decision as soon as possible at minimal

cost (disappointing to spend 30 % of the budget to

decide go/no go)

ƒ

Necessary estimations

ƒ Size: line of code, function-point, n. of modules, n. of classes ƒ Workload: manmonth

ƒ Duration: month

ƒ Efficiency: size / workload

Estimation (cont)

Factors: language, toolset,

reuse, skills, previous

experiences...

Sources:

ƒ Our earlier experiences ƒ Experts

Based on:

ƒ system analogy ƒ package analogy ƒ Parametric model

COCOMO (Constructive Cost Model) family: routine task – direct data

Organizational structure

Project-leader Quality-assurance Domain expert Customer-representative Tester team Chief system-architect Development manager Chief developer Toolsmith

Package 1 team Package 2 team Package n team

Phases, phase-transitions

ƒ

Inception - Elaboration transition

Requirement inspection

ƒ

Elaboration – Construction transition

Architectural plan inspection

ƒ

Construction – Transition

Operational test

ƒ

End of transition

Hints for project

managers

For the sake of success

ƒ

Take care of the team

ƒ

Stay focused, keep the project in moving

Refuse late good ideas

– I: accept ideas, define priority for them

– E: take into consideration, analyze impact

– C: only critical problems

Project statistics

• Smaller (less complex) • Shorter periods

• Less people to manage

31,0% 40,0% 28,0% 52,7% 33,0% 46,0% 16,2% 27,0% 26,0% 0% 20% 40% 60% 80% 100% 1994 1996 1998 Failed Problematic Success

Success factors

Involving user

20%

Top manager (CEO) support

15 %

Clear business goals

15 %

Experienced project management

15 %

Small milestones

10 %

Clear requirements

5 %

Talented programmers

5 %

Leadership

5 %

Fail factors

Incomplete requirement 13.1%

Lack of user involvment 12.4%

Shortage in resources 10.6%

Too ambitious goals 9.9%

Lack of CEO support 9.3%

Changing requirements 8.7% Lack of design 8.1% Lapse of interest 7.5% Lack of IT management 6.2% Incompetence in technologie 4.3% Others 9.9%