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





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


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



• 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



• 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



• 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



• 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.



• 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



• 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?



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- 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?



• 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



• 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!



• 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



• 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



• 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?


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


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


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


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



• 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



• 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



• 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



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


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




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


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




P Review integration testcases N, O, G 1

Q Perform integrationtests P, J 1

R Perform UserAcceptance Test Q, M 2


P Review integration testcases N, O, G 1

Q Perform integrationtests P, J 1

R Perform UserAcceptance Test Q, M 2



• 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


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


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


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




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


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



- 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



- Correctness Check: LST(M1) = 0


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


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


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


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


AGENDAAGENDA








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


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


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



• 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



• 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


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.


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. …


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


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


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


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


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


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

convener: houman younessi

Documents

project schedule

project estimate

projectsoftware project

project milestone

actual project plan

hrsweek1 person month

scheduled task

effortidentify tasks