se lect13 btech

of 112 /112
Deliverables by Phase

Upload: iiita

Post on 12-Nov-2014




0 download

Embed Size (px)




Page 1: Se lect13 btech

Deliverables by Phase

Page 2: Se lect13 btech


Deliverables by Phase





Coding andDebugging


Deployment &Maintenance

Possible Deliverables by Phase Concept Document Statement of Work (SOW) Project Charter RFP & Proposal

Requirements Document (Software Requirements Specification) Work Breakdown Structure (WBS)

Functional Specification ( Top Level Design Specification) Entity Relationship Diagram Data Flow Diagram

Detailed Design Specification Object Diagrams Detailed Data Model

Coding Standards Working Code Unit Tests

Acceptance Test Procedures Tested Application

Maintenance Specification Deployed Application

Project Development Plan (Software Development Plan ) Baseline Project Plan Quality Assurance Plan Configuration Management Plan Risk Management Plan

Integration Plan Detailed SQA Test Plan SQA Test Cases

User Documentation Training Plan

Page 3: Se lect13 btech

Risk management

Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project.

A risk is a probability that some adverse circumstance will occur. Project risks affect schedule or resources Product risks affect the quality or performance of the

software being developed Business risks affect the organisation developing or

procuring the software

Page 4: Se lect13 btech

Software risksRisk Risk type DescriptionStaff turnover Project Experienced staff will leave the

project before it is finished.Management change Project There will be a change of

organisational management withdifferent priorities.

Hardware unavailability Project Hardware which is essential for theproject will not be delivered onschedule.

Requirements change Project andproduct

There will be a larger number ofchanges to the requirements thananticipated.

Specification delays Project andproduct

Specifications of essential interfacesare not available on schedule

Size underestimate Project andproduct

The size of the system has beenunderestimated.

CASE tool under-performance

Product CASE tools which support theproject do not perform as anticipated

Technology change Business The underlying technology on whichthe system is built is superseded bynew technology.

Product competition Business A competitive product is marketedbefore the system is completed.

Page 5: Se lect13 btech

The Risk Management Process

• Risk identification– Identify project, product and business risks

• Risk analysis– Assess the likelihood and consequences of these


• Risk planning– Draw up plans to avoid or minimise the effects of the


• Risk monitoring– Monitor the risks throughout the project

Page 6: Se lect13 btech

The risk management process

Risk avoidanceand contingency


Risk planning

Prioritised risklist

Risk analysis

List of potentialrisks




Page 7: Se lect13 btech

Risk identification

• Technology risks

• People risks

• Organisational risks

• Requirements risks

• Estimation risks

Page 8: Se lect13 btech

Risks and risk types

Risk type Possible risksTechnology The database used in the system cannot process as many

transactions per second as expected.Software components which should be reused contain defectswhich limit their functionality.

People It is impossible to recruit staff with the skills required.Key staff are ill and unavailable at critical times.Required training for staff is not available.

Organisational The organisation is restructured so that different managementare responsible for the project.Organisational financial problems force reductions in the projectbudget.

Tools The code generated by CASE tools is inefficient.CASE tools cannot be integrated.

Requirements Changes to requirements which require major design rework areproposed.Customers fail to understand the impact of requirementschanges.

Estimation The time required to develop the software is underestimated.The rate of defect repair is underestimated.The size of the software is underestimated.

Page 9: Se lect13 btech

Risk analysis

• Assess probability and seriousness of each risk• Probability may be

– very low– low– moderate – high or very high

• Risk effects might be – catastrophic – serious– Tolerable – insignificant

Page 10: Se lect13 btech

Risk analysis

Risk Probability EffectsOrganisational financial problems force reductionsin the project budget.

Low Catastrophic

It is impossible to recruit staff with the skillsrequired for the project.

High Catastrophic

Key staff are ill at critical times in the project. Moderate SeriousSoftware components which should be reusedcontain defects which limit their functionality.

Moderate Serious

Changes to requirements which require majordesign rework are proposed.

Moderate Serious

The organisation is restructured so that differentmanagement are responsible for the project.

High Serious

The database used in the system cannot process asmany transactions per second as expected.

Moderate Serious

The time required to develop the software isunderestimated.

High Serious

CASE tools cannot be integrated. High TolerableCustomers fail to understand the impact ofrequirements changes.

Moderate Tolerable

Required training for staff is not available. Moderate TolerableThe rate of defect repair is underestimated. Moderate TolerableThe size of the software is underestimated. High TolerableThe code generated by CASE tools is inefficient. Moderate Insignificant

Page 11: Se lect13 btech

Risk planning

Consider each risk and develop a strategy to manage that risk

Avoidance strategies The probability that the risk will arise is reduced

Minimisation strategies The impact of the risk on the project or product will

be reducedContingency plans

If the risk arises, contingency plans are plans to deal with that risk

Page 12: Se lect13 btech

Risk management strategies

Risk StrategyOrganisationalfinancial problems

Prepare a briefing document for senior management showinghow the project is making a very important contribution to thegoals of the business.


Alert customer of potential difficulties and the possibility ofdelays, investigate buying-in components.

Staff illness Reorganise team so that there is more overlap of work andpeople therefore understand each other’s jobs.


Replace potentially defective components with bought-incomponents of known reliability.


Derive traceability information to assess requirements changeimpact, maximise information hiding in the design.


Prepare a briefing document for senior management showinghow the project is making a very important contribution to thegoals of the business.


Investigate the possibility of buying a higher-performancedatabase.

Underestimateddevelopment time

Investigate buying in components, investigate use of a programgenerator.

Page 13: Se lect13 btech

Risk monitoring

• Assess each identified risks regularly to decide whether or not it is becoming less or more probable

• Also assess whether the effects of the risk have changed

• Each key risk should be discussed at management progress meetings

Page 14: Se lect13 btech

Risk factors

Risk type Potential indicatorsTechnology Late delivery of hardware or support software, many

reported technology problemsPeople Poor staff morale, poor relationships amongst team

member, job availabilityOrganisational organisational gossip, lack of action by senior

managementTools reluctance by team members to use tools, complaints

about CASE tools, demands for higher-poweredworkstations

Requirements many requirements change requests, customercomplaints

Estimation failure to meet agreed schedule, failure to clearreported defects

Page 15: Se lect13 btech

Software Measurement & Matrices

Page 16: Se lect13 btech


Software Measurement Objectives

– Assessing status• Projects• Products for a specific project or projects• Processes• Resources

– Identifying trends• Need to be able to differentiate between a healthy project and one

that’s in trouble

– Determine corrective action• Measurements should indicate the appropriate corrective action, if

any is required.

Page 17: Se lect13 btech


Software Measurement Objectives

• Types of information required to understand, control, and improve projects:– Managers

• What does the process cost?• How productive is the staff?• How good is the code?• Will the customer/user be satisfied?• How can we improve?

– Engineers• Are the requirements testable?• Have all the faults been found?• Have the product or process goals been met?• What will happen in the future?

Page 18: Se lect13 btech


The Scope of Software Metrics

– Cost and effort estimation– Productivity measures and models– Data collection– Quality models and measures– Reliability models– Performance evaluation and models– Structural and complexity metrics– Capability-maturity assessment– Management by metrics– Evaluation of methods and tools

Page 19: Se lect13 btech


The Scope of Software Metrics

• The Scope of Software Metrics – some details– Possible productivity model




Reliability Defects FunctionalitySize

Personnel Resources Complexity





Env Cnstrst

Problem difficulty

Page 20: Se lect13 btech


The Scope of Software Metrics• The Scope of Software Metrics – some

details– Software quality model

Use Factor Criteria

Product Operation

Product Revision











Device Efficiency




Device Independence






Page 21: Se lect13 btech

Direct and Indirect Matrices

Page 22: Se lect13 btech


Measurement Basics

• Direct and Indirect Measurement– Direct measure – relates an attribute to a number or

symbol without reference to no other object or attribute (e.g., height).

– Indirect measure• Used when an attribute must be measured by combining

several of its aspects (e.g., density)

• Requires a model of how measures are related to each other

Page 23: Se lect13 btech


Measurement Basics

• Direct and Indirect Measures for Software – examples– Direct

• Length or source code (lines of code)• Duration of testing process• Number of defects discovered during test• Time a developer spends on a project

– Indirect• Programmer productivity (LOC/workmonths of effort)• Module defect density (number of defects/module size)• Defect detection efficiency (# defects detected/total defects)• Requirements stability (initial # requirements/total # requirements)• Test effectiveness ratio (number of items covered/total number of items)• System spoilage (effort spent fixing faults/total project effort)

Page 24: Se lect13 btech

Quality Models and Measures

Page 25: Se lect13 btech

Software product quality metrics

• The quality of a product:

- the “totality of characteristics that bear on its ability to satisfy stated or implied needs”.

Metrics of the external quality attributes producer’s perspective: “conformance to

requirements” customer’s perspective: “fitness for use”

- customer’s expectations

Page 26: Se lect13 btech

Quality metrics

• Two levels of software product quality metrics:

Intrinsic product quality

Customer oriented metrics

Page 27: Se lect13 btech

Intrinsic product quality metrics:

Reliability: number of hours the software can run

before a failure

Defect density (rate):

number of defects contained in software, relative

to its size.

Customer oriented metrics:

Customer problems

Customer satisfaction

Page 28: Se lect13 btech

Intrinsic product quality metrics

Reliability --- Defect density

• Correlated but different!

• Both are predicted values.

• Estimated using static and dynamic models

Defect: an anomaly in the product (“bug”)

Software failure: an execution whose effect is not conform to software specification

Page 29: Se lect13 btech


Reliability metrics:

MTBF (Mean Time Between Failures)

MTTF (Man Time To Failure)

Page 30: Se lect13 btech

MTBF (Mean Time Between Failures):

the expected time between two successive failures of a system

expressed in hours

a key reliability metric for systems that can be repaired or restored

(repairable systems)

applicable when several system failures are expected.

For a hardware product, MTBF decreases with the its age.

Page 31: Se lect13 btech

MTTF (Man Time To Failure):

the expected time to failure of a system

in reliability engineering metric for non-repairable systems

non-repairable systems can fail only once; example, a satellite is not repairable.

Mean Time To Repair (MTTR): average time to restore a system after a failure

When there are no delays in repair: MTBF = MTTF + MTTR

Software products are repairable systems!

Reliability models neglect the time needed to restore the system after a failure.

with MTTR =0 MTBF = MTTF

Availability = MTTF / MTBF = MTTF / (MTTF + MTTR)

Page 32: Se lect13 btech

3.1.2. Defect rate (density)

Number of defects per KLOC or per Number of Function Point,

in a given time unit


“The latent defect rate for this product, during next four years, is 2.0

defects per KLOC”.

Crude metric: a defect may involve one or more lines of code

Lines Of Code

-Different counting tools

-Defect rate metric has to be completed with the counting method for LOC!

-Not recommended to compare defect rates of two products written in

different languages

Page 33: Se lect13 btech

Reliability or Defect Rate ?


often used with safety-critical systems such as: airline traffic control systems,

avionics, weapons.

(usage profile and scenarios are better defined)

Defect density:

in many commercial systems (systems for commercial use)

• there is no typical user profile

• development organizations use defect rate for maintenance cost and

resource estimates

• MTTF is more difficult to implement and may not be representative of all


Page 34: Se lect13 btech

Customer Oriented Metrics

Customer Problems MetricCustomer Problems Metric

Customer problems when using the product:

valid defects, usability problems, unclear documentation, user errors.

Problems per user month (PUM) metric:


TNP: Total number of problems reported by customers for a time period

TNM: Total number of license-months of the software during the period

= number of install licenses of the software x number of months in the period

Page 35: Se lect13 btech

3.2.2. Customer satisfaction metrics

Often measured on the five-point scale:1. Very satisfied2. Satisfied3. Neutral4. Dissatisfied5. Very dissatisfied IBM: CUPRIMDSO (capability/functionality, usability, performance, reliability,

installability, maintainability, documentation /information, service and overall)

Hewlett-Packard: FURPS (functionality, usability, reliability, performance and service)

Page 36: Se lect13 btech

Management, Control & Reporting QA

Project Concept & DefinitionProject Concept & Definition

Phase or StagePhase or Stage










Benefit Tracking & ManagementBenefit Tracking & Management

Documentation ControlDocumentation Control

Risk ManagementRisk ManagementIssue ManagementIssue Management

Scope & Change ControlScope & Change ControlConfiguration ManagementConfiguration Management

Team building, Collaboration and Internal CommunicationTeam building, Collaboration and Internal CommunicationOrganisational Change ManagementOrganisational Change Management

External CommunicationExternal CommunicationProcurement & AccountingProcurement & Accounting

Subcontractor ManagementSubcontractor Management

Quality ManagementQuality Management

Benefit DeliveryBenefit Delivery

Overview of Project Management




Page 37: Se lect13 btech

Project Management

• Project Failures

• Project Successes

Page 38: Se lect13 btech

Project Failure

• Identify reasons that project fail

Page 39: Se lect13 btech

Reasons for Project Failure

1. Poor project and program management discipline2. Lack of executive-level support3. No linkage to the business strategy4. Wrong team members5. No measures for evaluating the success of the project6. No risk management7. Inability to manage change

Page 40: Se lect13 btech

Project Success Criteria

• On time

• On budget

• Meeting the goals that have been agreed upon

Page 41: Se lect13 btech

Iron Triangle

Page 42: Se lect13 btech

Seven Traits of Good Project Managers

Trait 1Enthusiasm for the project

Trait 2Ability to manage change effectively

Trait 3A tolerant attitude toward ambiguity

Trait 4Team – building and negotiating skills

Page 43: Se lect13 btech

Seven Traits of Good Project Managers

Trait 5A customer-first orientation

Trait 6Adherence to the priorities of business

Trait 7Knowledge of the industry or technology

Page 44: Se lect13 btech

Project Management

• Project Management– The “application of knowledge, skills, tools and

techniques to project activities to meet project requirements.”

• 9 Knowledge areas

Page 45: Se lect13 btech

Integration Management

• Fitting everything together

• Planning

• Project Changes

Page 46: Se lect13 btech

Project Scope Management

• Clear scope statement

• Prevent scope creep

Page 47: Se lect13 btech

Project Time Management

• Time and Schedule– Planning– Managing

Page 48: Se lect13 btech

Project Cost Management

• Manage costs– Out of your control– Competing projects

Page 49: Se lect13 btech

Project Quality Management

• Planning quality

• Enforcing quality

• Checking quality control

Page 50: Se lect13 btech

Project Human Resource Management

• Organizational planning

• Staff acquisition

• Making a team

Page 51: Se lect13 btech

Project Communications Management

• Communication plan

Page 52: Se lect13 btech

Project Risk Management

• Risk management plan

Page 53: Se lect13 btech

Project Procurement Management

• Acquisition and contract management

Page 54: Se lect13 btech

Project Life Cycle

Page 55: Se lect13 btech

SMART goals

• S – Specific

• M – Measurable

• A – Agreed upon

• R – Realistic

• T – Time related

Page 56: Se lect13 btech

Risk management

• Identify– Sources of risk

• Funding

• Time

• Staffing

• Customer relations

• Project size and/or complexity

• Overall structure

• Organizational resistance

• External factors

Page 57: Se lect13 btech

Work Breakdown Structure (WBS)

• Breaks large project into manageable units– Total project– Subprojects– Milestones (completion of an important set of work

packages)– Major activities (summary tasks)– Work packages (tasks, activities, work elements)

Page 58: Se lect13 btech


Work Breakdown Structure

Page 59: Se lect13 btech


• Helps to:– Identify all work needing to be done – Logically organize work so that is can be scheduled– Assign work to team members– Identify resources needed– Communicate what has to be done– Organize work using milestones

Page 60: Se lect13 btech


• Budget = People + Resources + Time

Page 61: Se lect13 btech

Direct & Indirect Costs

• Direct costs – Directly attributed to the project

• Indirect costs– Shared amongst other projects

Page 62: Se lect13 btech

Types of Budgeting

• Bottom-up

• Top-Down

• Phased

Page 63: Se lect13 btech

Project Time ManagementProject Time Management

Page 64: Se lect13 btech


Complexity of Scheduling Project Activities

• Large number of activities

• Precedence relationships

• Limited time of the project

Page 65: Se lect13 btech

Importance of Project SchedulesImportance of Project Schedules

Managers often cite delivering projects on time as one of their biggest challenges

Average time overrun from 1995 CHAOS report was 222%

Time has the least amount of flexibility; it passes no matter what

Schedule issues are the main reason for conflicts on projects, especially during the second half of projects

Page 66: Se lect13 btech

Conflict Intensity over the Life of A ProjectConflict Intensity over the Life of A Project











Early Phases Middle Phases End Phases



ct In






Technical opinions



Personality conflicts

AverageTotal Conflict

Page 67: Se lect13 btech

Project Time Management ProcessesProject Time Management Processes

Project time management involves the processes required to ensure timely completion of a project, including: Activity definition Activity sequencing Activity duration estimating Schedule development Schedule control

Page 68: Se lect13 btech

Where Do Schedules Come From? Where Do Schedules Come From?

Defining Activities:Project schedules grow out of the basic

documents that initiate a projectProject charter includes start and end dates and

budget information

Activity definition involves developing a more detailed PLANS and supporting explanations to understand all the work to be done

Page 69: Se lect13 btech

Activity SequencingActivity Sequencing

Involves reviewing activities and determining dependenciesMandatory dependencies: inherent in the nature of

the work; hard logicOptional dependencies: defined by the project

team; soft logic

We must determine dependencies in order to use critical path analysis

Page 70: Se lect13 btech

Project Network DiagramsProject Network Diagrams

Project network diagrams are the preferred technique for showing activity sequencing

A project network diagram is a schematic display of the logical relationships among, or sequencing of, project activities

Page 71: Se lect13 btech

Activity-on-Arrow (AOA) Network DiagramActivity-on-Arrow (AOA) Network Diagram

Page 72: Se lect13 btech

Arrow Diagramming Method (ADM)Arrow Diagramming Method (ADM)

Also, called activity-on-arrow (AOA) project network diagrams

Activities are represented by arrowsNodes or circles are the starting and ending

points of activitiesCan only show finish-to-start dependencies

Page 73: Se lect13 btech

Process for Creating AOA DiagramsProcess for Creating AOA Diagrams

1. Find all of the activities that start at node 1. Draw their finish nodes and draw arrows between node 1 and those finish nodes. Put the activity letter or name and duration estimate on the associated arrow

2. Continue drawing the network diagram, working from left to right. Look for bursts and merges. Bursts occur when a single node is followed by two or more activities. A merge occurs when two or more nodes precede a single node

3. Continue drawing the project network diagram until all activities are included on the diagram that have dependencies

4. As a rule of thumb, all arrowheads should face toward the right, and no arrows should cross on an AOA network diagram

Page 74: Se lect13 btech


Project Planning When Activity Times are Known

• Inputs– list of the activities that must be completed – activity completion times– activity precedence relationships

Page 75: Se lect13 btech


Project Planning When Activity Times are Known continued

• Outputs– graphical representation of project– time to complete project– identification of critical path(s) and activities– activity and path slack– earliest and latest time each activity can be started – earliest and latest time each activity can be completed

Page 76: Se lect13 btech



Activity Time Preceded ByA 10 --B 7 --C 5 AD 13 AE 4 B,CF 12 DG 14 E

Page 77: Se lect13 btech


Network Diagram

Page 78: Se lect13 btech


Early Start and Finish Times

Page 79: Se lect13 btech


Latest Start and Finish Times

Page 80: Se lect13 btech


Activity Slack Time

TES = earliest start time for activity

TLS = latest start time for activity

TEF = earliest finish time for activity

TLF = latest finish time for activity

Activity Slack = TLS - TES = TLF - TEF

Page 81: Se lect13 btech

Precedence Diagramming Method (PDM)Precedence Diagramming Method (PDM)

Activities are represented by boxesArrows show relationships between

activitiesMore popular than ADM method and used

by project management softwareBetter at showing different types of


Page 82: Se lect13 btech

Task Dependency TypesTask Dependency Types

Page 83: Se lect13 btech

Activity Duration EstimatingActivity Duration Estimating

After defining activities and determining their sequence, the next step in time management is duration estimating

Duration includes the actual amount of time worked on an activity plus elapsed time

People doing the work should help create estimates, and an expert should review them

Page 84: Se lect13 btech

Schedule DevelopmentSchedule Development

Schedule development uses results of the other time management processes to determine the start and end date of the project and its activities

Ultimate goal is to create a realistic project schedule that provides a basis for monitoring project progress for the time dimension of the project

Important tools and techniques include Gantt charts, PERT analysis, and critical path analysis

Page 85: Se lect13 btech


Gantt Chart

Page 86: Se lect13 btech

Critical Path Method (CPM)Critical Path Method (CPM)

CPM is a project network analysis technique used to predict total project duration

A critical path for a project is the series of activities that determines the earliest time by which the project can be completed

The critical path is the longest path through the network diagram

Page 87: Se lect13 btech

Finding the Critical PathFinding the Critical Path

First develop a good project network diagram

Add the durations for all activities on each path through the project network diagram

The longest path is the critical path

Page 88: Se lect13 btech

Determining the Critical PathDetermining the Critical Path

Page 89: Se lect13 btech

More on the Critical PathMore on the Critical Path

If one of more activities on the critical path takes longer than planned, the whole project schedule will slip unless corrective action is taken

Misconceptions:The critical path is not the one with all the critical

activities; it only accounts for timeThere can be more than one critical path if the

lengths of two or more paths are the sameThe critical path can change as the project


Page 90: Se lect13 btech

Using Critical Path for Schedule Trade-offsUsing Critical Path for Schedule Trade-offs

Knowing the critical path helps you make schedule trade-offs

Free slack or free float is the amount of time an activity can be delayed without delaying the early start of any immediately following activities

Total slack or total float is the amount of time an activity may be delayed from its early start without delaying the planned project finish date

Page 91: Se lect13 btech

Techniques for Shortening a Project ScheduleTechniques for Shortening a Project Schedule

Shortening durations of critical tasks by adding more resources or changing their scope

Crashing tasks by obtaining the greatest amount of schedule compression for the least incremental cost

Fast tracking tasks by doing them in parallel or overlapping them

Page 92: Se lect13 btech

Shortening Project SchedulesShortening Project Schedules



Original schedule

Page 93: Se lect13 btech


What are Gantt and PERT?

Gantt and PERT charts are both “CPM” (Critical Path Method) tools to:

• manage the tasks involved in big and complex projects

• let project managers organise time, people, equipment and money

• ensure the right people and equipment are in the right place and the right time

• allow managers to monitor the progress of a project

Page 94: Se lect13 btech


Gantt Basics

• Basically, a timeline with tasks that can be connected to each other

• Note the spelling!

• It is not all-capitals!

• Can be created with simple tools like Excel, but specialised tools like Microsoft Project make life easier

Page 95: Se lect13 btech


Making a Gantt chart

• Step 1 – list the tasks in the project

Page 96: Se lect13 btech


Making a Gantt chart

• Step 2 – add task durations

Page 97: Se lect13 btech


Making a Gantt chart

• Step 3 – add dependencies (which tasks cannot start before another task finishes)

Page 98: Se lect13 btech



•The arrows indicate dependencies.

•Task 1 is a predecessor of task 2 – i.e. task 2 cannot start before task 1 ends.

•Task 3 is dependent on task 2. Task 7 is dependent on two other tasks

•Electrics, plumbing and landscaping are concurrent tasks and can happen at the same time, so they overlap on the chart. All 3 can start after task 4 ends.

•Task 9 has zero duration, and is a milestone

Page 99: Se lect13 btech


Making a Gantt chart

• Step 4 – find the critical path

The critical path is the sequence of tasks from beginning to end that takes the longest time to complete.

Any task on the critical path is called a critical task.

No critical task can have its duration changed without affecting the end date of the project.

Page 100: Se lect13 btech


PERT basics

• PERT is an acronym so it’s in capital letters• Gantt is a name, so only has an initial capital• In Gantt chart, the length of a task’s bar is

proportional to the length of the task. This rarely applies to PERT charts.

• There are a few different “flavours” of PERT and Gantt charts…

Page 101: Se lect13 btech


PERT charts

This PERT chart follows the “Activity on Arrow” style.

•The tasks are shown by arrows. Task name are shown by letters, in this case.

•The circles are called nodes. The nodes indicate the start or end of tasks.

•Task durations are the shown by the numbers.

Page 102: Se lect13 btech


‘Activity on Node’ style PERT

Activity on Node is a different flavour of PERT: this time the nodes are tasks, and the arrows are merely connectors.

The examiners prefer very simple PERT charts – sometimes hybrid beasts that defy categorisation.

Page 103: Se lect13 btech




Page 104: Se lect13 btech


• 1: Which tasks are on the critical path?• 2: What is the slack time for tasks C, D and G?• 3: Task C is delayed by one day. What impact would

this have on the completion date of the project? Why?• 4: Task A will be delayed by 2 days because some

equipment has arrived late. If the project manager wants to finish the project on time he will need to shorten the duration of one or more of the tasks. How can he achieve this?

• 5: The project manager reduces the durations of tasks D and F by one day each. How will this affect the finishing date of the project?

Page 105: Se lect13 btech


1: Which tasks are on the critical path?


Possible paths:

A,B,C,E,I = 2+3+1+4+3 = 13 days

A,B,D,F,I = 2+3+3+3+3 = 14 days

A,G,H,I = 2+2+5+3 = 12 days

Page 106: Se lect13 btech


2: What is the slack time for tasks C, D and G?

Path C,E = 5 days, Path D,F = 6 days

Path B,C,E = 8 days. Path B, D, F = 9 days

Path G, H = 7 days.

Difference (slack) = 1 day for tasks C or E compared to D,F

So G & H have 2 days’ slack between them.

B,C or E have 1 day’s slack.

B,D,F have no slack.

TASKS C and D…


Page 107: Se lect13 btech


3: Task C starts one day late. What impact would this have on the completion date of the project? Why?

No impact, because task C has one day’s slack (as discovered in previous question!)

Page 108: Se lect13 btech


4: Task A will be delayed by 2 days because some equipment has arrived late. If the project manager still wants to finish the project within the original time frame, he will need to shorten the time for one or more of the tasks. What steps can he take to reduce the number of days allocated to a task?

The answer has NOTHING to do with the chart! Just say how jobs can be finished more quickly, e.g. bringing in extra workers from slack tasks, working longer hours, working weekend, streamlining work practices, automating tasks etc.

Page 109: Se lect13 btech


• 5: The project manager decides to reduce the time needed for tasks D and F by one day each. How effective will this reduction be in achieving his aim of maintaining the original finish time for the project?

It is only partially effective. Reducing tasks D and F by one day each means the path A,B,D,F,I is now 12 days long. However, path A,B,C,E,I is still 13 days so it becomes the longest path, and therefore becomes the new critical path.

The project is now 13 days long instead of 14, a saving of only one day.

Page 110: Se lect13 btech
Page 111: Se lect13 btech

Project Management Software

• There are a number of project management software tools available to help in the planning and control of large software development projects. – E.g. MS Project is a CASE software tool for Project


• Most tools include functions to plan, schedule and control, but decision-making still has to be done by the project manager.

Page 112: Se lect13 btech

Project Management Software

• Benefits of project management software:– Calculate project schedule– Resource smoothing – Automatic generation of reports and charts

• Limitations of project management software– Allocation of resources to tasks– Estimation of tasks durations– Make decisions