Transcript Slide 1

Software Engineering
Management
Course # CISH-6050
Lecture 5:
Software Process & Project
Management Part 2
Convener:
Houman Younessi
1
05/30/2009
AGENDA
• SW-CMM Level 2: Software
Process & Project Management
- Requirements Management
- Project Tracking & Oversight
- Project Planning
 Project Estimation
 Project Scheduling
- Software Quality Assurance (SQA)
- Software Configuration Management
- Sub-contract Management
2
CISH-6050 - Software Engineering Management
Software Project Scheduling
• Software Project Activities
-
Finalize requirements
Estimate project – size and effort
Identify tasks and resource
Schedule and track the project
• Software project scheduled by
allocating resource over planned
product development phase
3
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Basic principles guiding project
scheduling:
- Compartmentalization – tasks & activities
- Interdependency – between tasks &
activities
- Time Allocation – tasks and activities
scheduled must be allocated work units
- Effort Validation – ensure resources aren’t
overbooked for multiple tasks
4
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Basic principles guiding project
scheduling …
- Defined Responsibilities – every
scheduled task is assigned resource
- Defined Outcomes – every scheduled
task has a defined outcome
- Defined Milestones – every task should
be associated with a project milestone
5
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Mapping Effort to Schedule
- Once the effort for a project has been
estimated, a schedule can be derived
- Example:
 36 Person Month (PM) project
 1 Person could take ~ 3 years
 6 People could take ~ 6 months
 36 People can’t do it in 1 month
6
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Mapping Effort to Schedule …
- Once effort is fixed, some flexibility can
be gained by adding resource to the
project
- A schedule can always be extended by
only using fewer resources
- Threshold when adding resource:
 At some point, adding more resource
is no longer productive; more time
spent educating new members
7
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Basic Effort vs. Schedule Concepts,
applying productivity:
- 1 Person Year (PY) = 2080 Hours
(52 weeks * 40 hrs/week)
- 1 Person Month (PM) = 174 Hours
(52 weeks/12 * 40 hrs)
- 100% productivity = 40 hrs/week writing
code; no lunch, no meetings, etc.
- 90% productivity = 36 hrs/week writing
code; 4 hrs for mtgs, lunch, etc.
8
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• For high level discussions on
determining project schedule,
assume 100% productivity:
- Example: 36 PM with 6 resource will take
about 6 months to complete
• Then, estimates are mapped to
actual project plan, where
productivity has to be considered:
- Ex: 36 PM with 6 resource may actually
take 6.7 PM with 90% productivity
9
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Example:
- Project Estimate is 10,000 hours
- Effort: PY = 4.81; PM = 57.5 PM
- 1 Full Time Equivalent (FTE), working at
100% productivity (40 hrs/week) would
take how long to complete the project?
10
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Example:
- Project Estimate is 10,000 hours
- Effort: PY = 4.81; PM = 57.5 PM
- 1 Full Time Equivalent (FTE), working at
100% productivity (40 hrs/week) would
take how long to complete the project?
 57.5 PM or 4.8 Years
- 5 FTE working 100% productivity would
take how long to complete the project?
11
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Example:
- Project Estimate is 10,000 hours
- Effort: PY = 4.81; PM = 57.5 PM
- 5 FTE working 100% productivity would
take how long to complete the project?
 11.5 PM or almost 1 year
 57.5/5 = 11.5; 4.8/5 = .96
- 5 FTE working 90% productivity would
take how long to complete the project?
12
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Example:
- Project Estimate is 10,000 hours
- Effort: PY = 4.81; PM = 57.5 PM
- 5 FTE working 90% productivity would take
how long to complete the project?
 12.7 PM or 1.1 Year
 90% productivity (36 hrs/week),
1 PY = 1872 hours; 1 PM = 157 hours
10,000 / 1872 = 5.34 years / 5 FTE = 1.07
10,000 / 157 = 63.7 months / 5 = 12.7
13
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• What if project schedule doesn’t fit
customer’s schedule or dead line?
- Ensure schedule based on historical data
from development organization
- Refine project scope (de-scope)
- Suggest phased approach
- Consider adding more resource & funding
- Avoid unrealistic promises
- Meet with customer to discuss options –
expectations management!
14
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Schedule vs. Cost vs. Requirements
- Software Development Project is a three
legged stool:
1. Schedule
2. Cost
3. Requirements
- If try to shorten one leg (i.e. bring in the
schedule or reduce the cost), the stool will
topple!
- If one leg is adjusted, adjust the other two
accordingly
15
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Distributing Effort over software
development phases
- Actual effort for each phase depends on
development model being used
- Traditional models – less time in reqmnts &
more time in development & test
- OO models – more time in design, less
time in development
- 40-20-40 Guideline: 40% front end
analysis; 20% dev; 40% system test
16
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• People Challenges when considering
resource, effort, and schedule:
-
Resource productivity
Educational background & experiences
Teamwork
Manager, project manager relationship with
resource & team
- Working environment
- Organizational turnover – new resource
always being rotated into group?
17
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Common software project scheduling
problems:
- Assuming best scenario case – everything
will go well
- Confusing expended effort with actual
project progress
- Never asking customer to wait longer
- Poorly monitored schedule progress
- Assuming every bug is the last one
- Automatically adding more resource when
schedule slips
18
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Considerations when scheduling
project: resource vs. months:
- Cost varies as product of staff & months,
but progress usually does not
- For partitionable tasks – add more resource
to bring in schedule
- When task can’t be partitioned, adding
more resource usually has no effect on
schedule
- Partitionable tasks with communication
between subtasks - diminishing returns
19
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Brooks’ Law: “Adding manpower to a
late software project makes it later.”
- How long a project takes depends on
sequential constraints
- Amount of resource to be effectively used
depends on independent subtasks
- Training & repartitioning tasks diverts
resource from other tasks
- Can always derive a longer schedule from
reduced resource, but usually not a shorter
schedule by adding resource
20
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Determining Critical Path in the
project schedule:
- In building the project plan, tasks and
subtasks are identified – usually in 2 week
or less durations / components
- Resource are assigned to the tasks, with
estimated start and stop dates (duration)
- Some tasks can be done in parallel, while
other tasks are dependent and must be
done sequentially
- A critical path exists through the project
21
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Critical Path:
- Working Definition: Set of activities, any
one of which, if not completed within their
allocated schedule, will result in a schedule
slippage for the entire project
- Activities on the critical path of a project
have no “slack time” in their duration
- Always at least one critical path from the
start to the end of project
22
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Critical Path (CP) …
- More than one critical path may exist in a
project
- Sometimes, there may appear to be more
than one critical path, but true critical paths
will have the same duration
- On rare occasions, every task is on the
critical path – i.e. all tasks are sequential
- Scheduling tools automatically calculate
CP, but there is a method behind the tool
23
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Critical Path Method:
-
Make a list of activities, with dependencies
Identify effort and duration for each activity
Organize activity list into Network diagram
Include milestones, placing activities after
predecessors
- Organize in time sequence, annotating with
activity identity and duration
- Add milestones if necessary
- Refine diagram elements for readability
24
CISH-6050 - Software Engineering Management
Software Project Scheduling …
Activity List for Software Project
Activity Description
Predecessors
A
Analyze Reqmnts
B
Redesign existing
components
A
C
Design new
components
A
D
Define unit interfaces
C
E
Implement new code
C
F
Develop integration plan
C
G
Develop communication
plan
F
25
Duration
1
6
3
1
6
2
2
CISH-6050 - Software Engineering Management
Software Project Scheduling …
Activity List for Software Project
Activity Description
Predecessors
I
Develop integration
environment
F
J
Test integration
environment
I
K
Modify existing code
B, D
L
Complete unit testing
E, K
M
Verify unit test results
L
N
Update documentation
E, K
O
Develop integration test
cases
F
26
Duration
2
1
5
1
1
2
1
CISH-6050 - Software Engineering Management
Software Project Scheduling …
Activity List for Software Project
Activity Description
Predecessors
P
Review integration test
cases
N, O, G
Q
Perform integration
tests
P, J
R
Perform User
Acceptance Test
Q, M
27
Duration
1
1
2
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Critical Path Method:


Make a list of activities, with dependencies
Identify effort and duration for each activity
Organize activity list into Network diagram
Include milestones, placing activities after
predecessors
 Organize in time sequence, annotating with
activity identity and duration
 Add milestones if necessary
 Refine diagram elements for readability
28
CISH-6050 - Software Engineering Management
Activity Network for Software Project
I
5
3
F
(2)
(2) (2) G
O
(1)
H
6
(3)
2
8
(0)
A
(1)
13
(1) J
C
1
7
(1)
D (1)
(6) E
B
P
N
4
(2)
(1)
M
L
9
(5)
29
11
Q
(6)
K
R (2)
10
(1)
(1)
CISH-6050 - Software Engineering Management
12
Software Project Scheduling …
• Annotate activity network by
assigning each activity:
-
Earliest Start Time (EST)
Latest Start Time (LST)
EST and LST are shown at the milestones
Represents the earliest start time and latest
times for completion for that milestone:
EST
LST
B
A
1
C
30
CISH-6050 - Software Engineering Management
Software Project Scheduling …
• Establish EST at each milestone:
-
Set EST at M1 = 0
Work left to right computing EST(Mi) for all I
Consider each activity AJ ending at Mi
EST(Mi) = MAX [EST(AJ) + DUR(AJ)]
 Mi = any Milestone
 M1 is project start; MN is project
completion
 AJ represents any activity
 DUR(AJ) is duration for activity AJ
31
CISH-6050 - Software Engineering Management
Network with EST
6
8
I
5
4
3
F
(2)
(2) (2) G
O
C
(3)
A
1
0
(1)
(1)
14
8
(6) E
B
N
EST
4
(2)
(1)
7
M
L
9
(5)
12
32
R (2)
11
Q
(6)
K
15
P
(1)
D (1)
1
J
(1)
(0)
8
2
13
H
6
18
7
10
(1)
(1)
13
CISH-6050 - Software Engineering Management
12
16
Software Project Scheduling …
• Establish LST at each milestone:
-
Set LST(MN) = EST(MN)
Work right to left computing LST(Mi) for all I
Consider each activity AJ starting at Mi
LST(Mi) = MIN [LST(MEND) - DUR(AJ)]
 Mi = any Milestone
 MEND is milestone at end of any given AJ
 AJ represents any activity
 DUR(AJ) is duration for activity AJ
- Correctness Check: LST(M1) = 0
33
CISH-6050 - Software Engineering Management
Network with EST/LST
6
12
8
I
5
4
6
3
F
(2)
(2) (2) G
O
A
1
0
(1)
0
8 14
2
1
14 14
H
6
8
(0)
N
EST LST
4
(2)
(1)
7
(5)
7
M
L
9
12 12
34
R (2)
11
Q
(6)
K
15 15
P
(1)
(6) E
B
J
(1)
D (1)
1
18 18
7
13
(1)
C
(3)
14
10
(1)
(1)
13 15
CISH-6050 - Software Engineering Management
12
16 16
Software Project Scheduling …
• Identifying Critical Path (CP) in
Network Diagram:
- CP is set of activities where EST = LST and
there is no slack time
- Usually represent CP as set of activities on
the CP: A-B-D-E-K
- Always at least one critical path
- May be more than one CP with no slack time
- Slipping any activity on the CP will mean a
slip in the entire project schedule
35
CISH-6050 - Software Engineering Management
Project Critical Path
A-B-K-N-P-Q-R
4
6
3
6
12
8
I
5
F
(2)
(2) (2) G
O
A
1
0
(1)
0
8 14
2
1
14 14
H
6
8
(0)
N
EST LST
4
(2)
(1)
7
(5)
7
M
L
9
12 12
36
R (2)
11
Q
(6)
K
15 15
P
(1)
(6) E
B
J
(1)
D (1)
1
18 18
7
13
(1)
C
(3)
14
10
(1)
(1)
13 15
CISH-6050 - Software Engineering Management
12
16 16
Software Project Scheduling …
• Critical Path – Additional Thoughts:
- Today, most organizations use project tools
to identify and manage the critical path
- Concept is still the same – tool calculates
the CP based on milestones, duration,
dependencies, etc.
- Generally, tools will produce a Gantt Chart or
Bar Chart that identifies activities, durations,
and critical path(s) through the project
37
CISH-6050 - Software Engineering Management
AGENDA
• SW-CMM Level 2: Software
Process & Project Management
- Requirements Management
- Project Tracking & Oversight
- Project Planning
 Project Estimation
 Project Scheduling
- Software Quality Assurance (SQA)
- Software Configuration Management
- Sub-contract Management
38
CISH-6050 - Software Engineering Management
Software Quality Assurance
• Software Quality (from Pressman):
- Conformance to explicitly stated functional
and performance requirements, explicitly
documented standards, and implicit
characteristics that are expected of all
professionally developed software
• Software requirements are foundation
from which quality is measured
• Specified standards define a set of
development criteria from which
quality is measured
39
CISH-6050 - Software Engineering Management
Software Quality Assurance …
• SQA ensures that:
-
Appropriate development methodology used
Projects use standards and procedures
Independent reviews & audits conducted
Documentation for maintenance & upgrades
Documentation done during development,
not after
- Change control processes are in place
- Testing emphasizes all high risks areas
- Each task successfully completed before
starting next task
40
CISH-6050 - Software Engineering Management
Software Quality Assurance …
• SQA ensures that …
- Deviations from Standards and Procedures
are exposed
- Project is auditable by external professionals
- Quality control work is performed against
standards
- The SQA plan and software development
plan are compatible
41
CISH-6050 - Software Engineering Management
Software Quality Assurance …
• SQA can be members of existing
development team or separate group
• SQA plan created during project
planning and reviewed by all members
• SQA Plan should include:
- Evaluations to be performed
- Audits & reviews; Standards
- Error reporting procedures; SQA documents
to be produced
42
CISH-6050 - Software Engineering Management
Software Quality Assurance …
• Some DoD contracts may require
Independent Verification & Validation
org (IV&V)
• If no IV&V org, V&V part of SQA tasks
• Verification:
- “Are we building the product right?”
- Check: program conforms to its specs
• Validation:
- “Are we building the right product?”
- Check: application meets user requirements
43
CISH-6050 - Software Engineering Management
Software Quality Assurance …
• The Testing Process:
-
Unit Testing
Module Testing
Subsystem Testing
System Testing
Acceptance Testing
• Testing plan identifies:
- Testing process; requirements traceability;
schedule; function to be tested; recording
process; constraints; HW & SW; etc.
44
CISH-6050 - Software Engineering Management
Software Quality Assurance …
• Lots of literature, books, and
information available on SQA and
testing methodologies
• Testing Methodologies:
-
White Box Testing
Basis Path Testing
Control Structure Testing
Black Box Testing
GUI Testing
Etc. …
45
CISH-6050 - Software Engineering Management
Software Configuration Management
• Change management – fundamental
activity of Software Engineering
• Changes to requirements drives
changes to design, to code, to test,
etc.
• Configuration Management:
- Development and application of procedures
and standards for managing an evolving
systems product
46
CISH-6050 - Software Engineering Management
Software Configuration Management ..
• Key Software Configuration
Management (SCM) Tasks:
-
Configuration Control
Change Management
Revisions
Versions
Deltas
Conditional Code
Configuration status accounting, audit &
reviews, and records retention
47
CISH-6050 - Software Engineering Management
Software Configuration Management ..
• Role of SCM:
-
Establish baselines and control versions
Track change requests & problem reports
Screen, prioritize, & authorize changes
Perform trend analysis:
 Requirements changes
 Size growth of evolving product
 Testing progress
 Incremental release content
 Errors: new, fixed, continuing
48
CISH-6050 - Software Engineering Management
Subcontract Management
• Purpose of Subcontract Management
is to select qualified software
subcontractors & manage them
effectively:
- Selecting a qualified subcontractor
- Establishing commitments (contract)
 Activities to be performed; dates; basis
for managing contract, etc.
- Tracking & reviewing subcontractor’s
performance and results
49
CISH-6050 - Software Engineering Management
References
• P. Jalote, Software Project Management in Practice, Addison-Wesley,
Boston, MA, 2002
• R. L. Glass, Facts and Fallacies of Software Engineering, Addison-Wesley,
Boston, MA, 2003
• N. E. Fenton, S. L. Pfleeger, Software Metrics: A Rigorous & Practical
Approach, PWS Publishing Company, Boston, MA, 1997
• H. Zuse, A Framework of Software Measurement, Walter de Gruyter, New
York, NY, 1997
• D. Yardley, Successful IT Project Delivery: Learning the Lessons of Project
Failure, Addison-Wesley, Boston, MA, 2002
• R. S. Pressman, Software Engineering: A Practitioner's Approach, 5th ed.,
McGraw-Hill, New York, 2001
• W. S. Humphrey, Managing the Software Process, Addison-Wesley,
Reading, MA, 1989
• I. Sommerville, Software Engineering, 5th ed., Addison-Wesley, Reading,
MA, 1995
50
CISH-6050 - Software Engineering Management
References …
• M. Paulk, C. V. Weber, B. Curtis, M. B. Chrissis, The Capability Maturity
Model: Guidelines for Improving the Software Process, Addison-Wesley,
Boston, MA, 1995
51
CISH-6050 - Software Engineering Management