Download - Convener: Houman Younessi
1
Convener: Houman Younessi
Convener: Houman Younessi
Software Engineering Management
Software Engineering Management
Course # CISH-6050Course # CISH-6050
Lecture 5: Lecture 5:
Software Process & Project Management Part 2
Software Process & Project Management Part 2
05/30/200905/30/2009
2 CISH-6050 - Software Engineering Management
AGENDAAGENDA
• 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
• 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
3 CISH-6050 - Software Engineering Management
Software Project SchedulingSoftware 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
• 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
4 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
5 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
6 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
7 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
8 CISH-6050 - Software Engineering Management
Software Project Scheduling …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.
• 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.
9 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
10 CISH-6050 - Software Engineering Management
Software Project Scheduling …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?
• 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?
11 CISH-6050 - Software Engineering Management
Software Project Scheduling …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?
• 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?
12 CISH-6050 - Software Engineering Management
Software Project Scheduling …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?
• 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?
13 CISH-6050 - Software Engineering Management
Software Project Scheduling …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 hours10,000 / 1872 = 5.34 years / 5 FTE = 1.0710,000 / 157 = 63.7 months / 5 = 12.7
• 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 hours10,000 / 1872 = 5.34 years / 5 FTE = 1.0710,000 / 157 = 63.7 months / 5 = 12.7
14 CISH-6050 - Software Engineering Management
Software Project Scheduling …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!
• 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!
15 CISH-6050 - Software Engineering Management
Software Project Scheduling …Software Project Scheduling …
• Schedule vs. Cost vs. Requirements- Software Development Project is a three
legged stool:1. Schedule2. Cost3. 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
• Schedule vs. Cost vs. Requirements- Software Development Project is a three
legged stool:1. Schedule2. Cost3. 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
16 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
17 CISH-6050 - Software Engineering Management
Software Project Scheduling …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?
• 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?
18 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
19 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
20 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
21 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
22 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
23 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
24 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
25 CISH-6050 - Software Engineering Management
Software Project Scheduling …Software Project Scheduling …
Activity List for Software ProjectActivity Description Predecessors Duration
A Analyze Reqmnts - 1B Redesign existing
components A 6C Design new
components A 3D Define unit interfaces C 1E Implement new code C 6F Develop integration plan C 2G Develop communication
plan F 2
Activity List for Software ProjectActivity Description Predecessors Duration
A Analyze Reqmnts - 1B Redesign existing
components A 6C Design new
components A 3D Define unit interfaces C 1E Implement new code C 6F Develop integration plan C 2G Develop communication
plan F 2
26 CISH-6050 - Software Engineering Management
Software Project Scheduling …Software Project Scheduling …
Activity List for Software ProjectActivity Description Predecessors Duration
I Develop integrationenvironment F 2
J Test integrationenvironment I 1
K Modify existing code B, D 5L Complete unit testing E, K 1M Verify unit test results L 1N Update documentation E, K 2O Develop integration test
cases F 1
Activity List for Software ProjectActivity Description Predecessors Duration
I Develop integrationenvironment F 2
J Test integrationenvironment I 1
K Modify existing code B, D 5L Complete unit testing E, K 1M Verify unit test results L 1N Update documentation E, K 2O Develop integration test
cases F 1
27 CISH-6050 - Software Engineering Management
Software Project Scheduling …Software Project Scheduling …
Activity List for Software ProjectActivity Description Predecessors Duration
P Review integration testcases N, O, G 1
Q Perform integrationtests P, J 1
R Perform UserAcceptance Test Q, M 2
Activity List for Software ProjectActivity Description Predecessors Duration
P Review integration testcases N, O, G 1
Q Perform integrationtests P, J 1
R Perform UserAcceptance Test Q, M 2
28 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
29 CISH-6050 - Software Engineering Management
2
B
5
3
4
1
13
11
8
109
A
(1)
(6)
(1)(5)
(1)
(6)
(3)
(2)
(2)
(1)
(1)
(0)
(1)
K
ED
C
N
O
F
Q
P
ML
Activity Network for Software Project
7
6
12
(2)
G(2)(1)
HJ
I
(1)
(2)
R
30 CISH-6050 - Software Engineering Management
Software Project Scheduling …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:
• 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:
AB
C1
EST LST
31 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
32 CISH-6050 - Software Engineering Management
2
B
5
3
4
1
13
11
8
109
A
(1)
(6)
(1)(5)
(1)
(6)
(3)
(2)
(2)
(1)
(1)
(0)
(1)
K
ED
C
N
O
F
Q
P
MLEST
Network with EST
7
6
12
(2)
G(2)(1)
HJ
I
(1)
(2)
R8
6
4
10
14
8
13127
18
16
15
33 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
34 CISH-6050 - Software Engineering Management
2
B
5
3
4
1
13
11
8
109
A
(1)
(6)
(1)(5)
(1)
(6)
(3)
(2)
(2)
(1)
(1)
(0)
(1)
K
ED
C
N
O
F
Q
P
ML
EST
Network with EST/LST
7
6
12
(2)
G(2)(1)
HJ
I
(1)
(2)
R0
8
6
4
10
14
8
13127
18
16
15
LST
14
14
15
15
16
186
12
12
14
7
1
35 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
36 CISH-6050 - Software Engineering Management
2
B
5
3
4
1
13
11
8
109
A
(1)
(6)
(1)(5)
(1)
(6)
(3)
(2)
(2)
(1)
(1)
(0)
(1)
K
ED
C
N
O
F
Q
P
ML
EST
Project Critical PathA-B-K-N-P-Q-R
7
6
12
(2)
G(2)(1)
HJ
I
(1)
(2)
R
0
8
6
4
10
14
8
13127
18
16
15
LST
14
14
15
15
16
186
12
12
14
7
1
37 CISH-6050 - Software Engineering Management
Software Project Scheduling …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
• 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
38 CISH-6050 - Software Engineering Management
AGENDAAGENDA
• 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
• 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
39 CISH-6050 - Software Engineering Management
Software Quality AssuranceSoftware 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
• 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
40 CISH-6050 - Software Engineering Management
Software Quality Assurance …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
• 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
41 CISH-6050 - Software Engineering Management
Software Quality Assurance …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
• 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
42 CISH-6050 - Software Engineering Management
Software Quality Assurance …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
• 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
43 CISH-6050 - Software Engineering Management
Software Quality Assurance …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
• 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
44 CISH-6050 - Software Engineering Management
Software Quality Assurance …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.
• 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.
45 CISH-6050 - Software Engineering Management
Software Quality Assurance …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. …
• 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. …
46 CISH-6050 - Software Engineering Management
Software Configuration ManagementSoftware 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
• 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
47 CISH-6050 - Software Engineering Management
Software Configuration 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
• Key Software Configuration Management (SCM) Tasks:- Configuration Control- Change Management- Revisions- Versions- Deltas- Conditional Code- Configuration status accounting, audit &
reviews, and records retention
48 CISH-6050 - Software Engineering Management
Software Configuration 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
• 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
49 CISH-6050 - Software Engineering Management
Subcontract ManagementSubcontract 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
• 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
50 CISH-6050 - Software Engineering Management
ReferencesReferences
• 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
• 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
51 CISH-6050 - Software Engineering Management
References …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
• 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