CMSC 345 Project Planning. Customer’s Perspective Do you understand my problem? Can you develop...

Preview:

Citation preview

CMSC 345

Project Planning

Customer’s Perspective Do you understand my problem? Can you develop and deliver a

system that will solve my problem? How long will it take? How much will it cost?

Project Deliverables Documents Demonstration of function Demonstration of subsystems Demonstration of accuracy Demonstration of extra-functional

properties: reliability, security, performance, etc.

Milestone = end of activity producing deliverable

Project Schedule Derived from deliverables Phases or stages of project Break into discrete activities that produce

deliverables Estimate time each activity will take Estimate number (and skills) of developers

needed to complete each activity Estimate other resources required for each

activity Timeline for activity begin/end and

corresponding delivery

PROJECT

PHASE 1 ACTIVITY 1.1ACTIVITY 1.2ACTIVITY 1.3:

PHASE 2

PHASE n

STEP 1STEP 2:

STEP 1STEP 2:

STEP 1STEP 2:

ACTIVITY 2.1ACTIVITY 2.2ACTIVITY 3.3:

Work Breakdown Structure Depicts project as set of discrete

pieces of work Customer can be informed which

activities are in progress and which milestones have been achieved

Does not show interdependencies and possible parallelism of work units

Build communications software

System planning (1.0) Coding (3.0)Testing(4.0)Delivery (5.0)

Top-level design (2.1)

Prototyping (2.2)

User interface (2.3)

Detailed design (2.4)

System design (2.0)

Review specification(1.1)

Review budget (1.2)

Review schedule(1.3)

Develop plan (1.4)

Activity Definition Precursor: events that must occur

before activity can begin Duration: length of time to complete

activity (estimated) Due date: date when activity must be

completed (e.g., contractual deadline) Endpoint: milestone and/or

deliverable

Activity Graph Depicts dependencies among activities Nodes are project milestones Directed edges are activities involved in

producing those milestones Shows what can be done simultaneously

(assuming sufficient personnel) Depend on understanding of parallel

nature of tasks. If work cannot be done in parallel, the (mostly straight) graph is not useful

Milestones in Building a House1.1 Survey complete1.2 Permits issued1.3 Excavation complete1.4 Materials on hand2.1 Foundations laid2.2 Outside walls complete2.3 Exterior plumbing

complete2.4 Exterior electrical work

complete2.5 Exterior siding

complete

2.6 Exterior painting done2.7 Exterior doors and

fixtures mounted2.8 Roof complete3.1 Interior plumbing done3.2 Interior electrical work

complete3.3 Wallboard in place3.4 Interior painting done3.5 Floor covering laid3.6 Interior doors and

fixtures mounted

1.11.2

1.3

1.4

2.1

2.22.3

2.4

2.5

2.7

2.62.8

3.2

3.3

3.1

3.5

3.6

3.4

START

FINISH

SurveyingRequest permits

Excavation

Buy materials

Lay foundation

Build outside wall

Install interior plumbing Install interior electrical

Install wallboardPaint interior

Installinterior doorsand fixtures

Install flooringInstall roofing

Install exterior plumbing

Install exteriorelectricalInstall exteriorsiding

Paint exterior

Install exteriordoors and fixtures

1.11.2

1.3

1.4

2.1

2.22.3

2.4

2.5

2.7

2.62.8

3.2

3.3

3.1

3.5

3.6

3.4

START

FINISH

315

10

10

15

20

1215

911

7

189

10

10

6

8

5

0

00

0

Project Personnel Differences Ability to perform the work Interest in the work Experience with similar applications Experience with similar tools or languages Experience with similar techniques Experience with similar development

environment Training Ability to communicate with others Ability to share responsibility with others Management skills

Two people 1 line of communication

Three people

Four people

Five people

3 lines of communication

6 lines of communication

10 lines of communication

:n people n(n-1)/2 lines of

communication

Meetings – Ugh! Purpose of meeting unclear Attendees unprepared Essential people absent or late Conversation veers away from purpose Some meeting participants argue,

dominate, or do not participate Decisions made not enacted

afterwards

Productive Meetings Clarify who should attend, when start

and end, and what accomplish Written agenda distributed in advance Moderator to keep discussion on track

and resolve conflicts Recorder records each action item and

ensures it is done Minimize number of meetings and

number of participants

Work Style Components The way your thoughts are

communicated and ideas gathered Extrovert – tell others your thoughts Introvert – ask for suggestions

The degree to which emotions affect decisions

Intuitive – base decisions on feelings Rational – examine facts; consider options

INTUITIVE

RATIONAL

INTR

OV

ER

TEX

TR

OV

ER

T

INTUITIVEINTROVERT:Asks othersAcknowledges feelings

INTUITIVEEXTROVERT:Tells othersAcknowledges feelings

RATIONALINTROVERT:Asks othersDecides logically

RATIONALEXTROVERT:Tells othersDecides logically

Work Styles Rational extrovert: judges

colleagues by results produced, efficiency is priority, good at making sound decisions quickly

Rational introvert: judges peers by busyness, accurate and thorough, gathers all information on subject

Work Styles (2) Intuitive extrovert: follows feelings

(professional judgment), assertive, creative, enjoys interaction

Intuitive introvert: sensitive, good listener, wants to make the right decision, examines relational dependencies and emotions

Implications of Work Styles Determine communication styles Understanding work styles can help

you be flexible in dealing with others Choice of workers for a task

Intuitive may prefer design & development (requiring new ideas)

Rational may prefer maintenance(analysis and attention to detail)

Project Organization Project organization based on

Backgrounds and work styles of members

Number of members Management styles of customers and

developers Flexibility of team members

Chief Programmer Team Chief: totally responsible for design and

development, supervises all others, does all design, assigns programming to others

Understudy: substitutes for chief when necessary

Librarian: maintains documentation, compiles and links code, performs preliminary testing as code submitted

Hierarchy minimizes communication

Chief programmer

Assistant chief programmer

Test teamAdministrationLibrarianSeniorprogrammers

Juniorprogrammers

Egoless Approach Everyone held equally responsible Criticism of process or product, but

not people involved Democratic - members vote on

decisions

Risks Unwanted event with negative consequences Risk impact: loss (of time, quality, money,

control, understanding, etc.) associated with event

Risk probability: likelihood that event will occur Risk control: ability to change outcome (minimize

or avoid impact) Risk exposure: impact * probability, must be

tracked over time Major risk sources:

Generic – common to all software projects Project-specific – threats for this project

Risk Reduction Strategies for risk reduction

Avoid the risk Transfer the risk Assume the risk

Boehm’s Top 10 Risks1. Personnel shortfalls – top talent, morale, team

building2. Unrealistic schedules and budgets – design to

schedule, incremental development, requirements scrubbing

3. Developing the wrong software functions – organizational analysis, prototyping, early user’s manuals

4. Developing the wrong user interface – prototyping, scenarios (use cases)

5. Gold plating – cost-benefit analysis, design to cost

Boehm’s Risks (cont’d)6. Continuing stream of requirements changes –

high change threshold, incremental development

7. Shortfalls in externally performed tasks – preaward audits, competitive design

8. Shortfalls in externally furnished components – inspections, compatibility analysis

9. Real-time performance shortfalls – simulation, instrumentation, tuning, modeling

10. Straining computer science capabilities – technical analysis, prototyping

Recommended