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