Sr.

No. Chapter Details Nos. of

Session
Reference
Books
1. Project Management Framework
1.1 Overview of project Management
1.2 Project Organization
1.3 Planning a s/w project
1.4 Project management life cycle
1.5 Risk management
1.5.1 Identification of Risks
1.5.2 Risk Analysis
1.5.3 Risk Planning & Monitoring
6 2,3,6
2 S/w Project Estimation
2.1 Project Estimation
2.2 Different methods of estimation
(COCOMO model, Delphi cost estimation
etc.)
2.3 Function point analysis
6 2,3,4
3. Project Management Tools & Techniques
3.1 PERT & Gantt Charts
3.2 Introduction to Microsoft Project
56
4. Software Quality Management & Testing
4.1 Quality Assurance & Standards
4.2 Quality Planning
4.3 Quality control
4.4 Role of testing in Software
development
4.5 Testing Procedure
4.6 Defect Management
6 5,6
5. Configuration Management(CM)
5.1 CM planning
5.2 Change Management
5.3. Version and Release Management
5.4 Configuration Management Tools
6 2, 3,4,5
Syl. M.C.A. / 97
6. S/W Team Management
6.1 Characteristics of Performance
management
6.2 High performance Directive and
collaborative styles
6.3 Team Structure
6.4 Team Communication
6.5 Managing customer expectations
6.6 Group Behavior
54
1
7. Role of User in Projects
7.1 User role in project management
7.2 User role in various stages of S/W
Development
7.3 User role in System implementation
44
Reference Books:
1. Software Project management Edwin Bennatan
2. Software Engineering Roger S. Pressman
3. Software Engineering concepts Richard Fairley
4. Software Project Management S.A. Kelkar
5. Software Engineering IAN Sommerville
6. System Analysis and Design Methods Whitten, Bentley and Dittman

2
Chapter 1 - Project Management Framework

SOFTWARE PROJECT PLAN

provides an overview of the software engineering project.

1 Project scope

A description of the software is presented. Major inputs, processing functionality and

outputs are described without regard to implementation detail.

2 Major software functions

A functional decomposition of the software (for use during estimation and scheduling)
is developed here.

3 Performance/Behavior issues

Any special requirements for performance or behavior are noted here.

4 Management and technical constraints

Any special constraints that affect the manner in which the project will be conducted
(e.g., limited resources or 'drop dead' delivery date) or the technical approach to
development is noted here.

Umbrella Activities
z Software project management
z Formal technical reviews
z Software quality assurance
z Software configuration management
z Document preparation and production
z Reusability management
z Measurement
z Risk management

Project management life cycle

Software Project:

 All technical and managerial activities required to deliver the deliverables to the client.
 A software project has a specific duration, consumes resources and produces work
products.
 Management categories to complete a software project: Tasks, Activities, Functions

Software Project Management Plan:

 The controlling document for a software project.

 Specifies the technical and managerial approaches to develop the software product.
 Companion document to requirements analysis document:
Changes in either may imply changes in the other document.
3
The four phases of the project life cycle

PHASE I : Project Initiation

The first phase of a project is the initiation phase. During this phase a business problem or
opportunity is identified and a business case providing various solution options is defined.
Next, a feasibility study is conducted to investigate whether each option addresses the
business problem and a final recommended solution is then put forward. Once the
recommended solution is approved, a project is initiated to deliver the approved solution.
Terms of reference are completed outlining the objectives, scope and structure of the new
project, and a project manager is appointed. The project manager begins recruiting a project
team and establishes a project office environment. Approval is then sought to move into the
detailed planning phase.

Within the initiation phase, the business problem or opportunity is identified, a

solution is defined, a project is formed and a project team is appointed to build and deliver
the solution to the customer. Following figure shows the activities undertaken during the
initiation phase:

4
Project initiation activities:

1. Develop a business case: The trigger to initiating a project is identifying a business

problem or opportunity to be addressed. A business case is created to define the problem or
opportunity in detail and identify a preferred solution for implementation. The business case
includes:

• A detailed description of the problem or opportunity;

• A list of the alternative solutions available;
• An analysis of the business benefits, costs, risks and issues;
• A description of the preferred solution;
• A summarized plan for implementation.

An identified project sponsor then approves the business case and the required
funding is allocated to proceed with a feasibility study.

2. Undertake a feasibility study: At any stage during or after the creation of a business
case, a formal feasibility study may be commissioned. The purpose of a feasibility study is to
assess the likelihood of each alternative solution option achieving the benefits outlined in the
business case. The feasibility study will also investigate whether the forecast costs are
reasonable, the solution is achievable, the risks are acceptable and the identified issues are
avoidable.

3. Establish the terms of reference: After the business case and feasibility study have
been approved, a new project is formed. At this point, terms of reference are created. The
terms of reference define the vision, objectives, scope and deliverables for the new project.
They also describe the organization structure; and activities, resources and funding required
to undertake the project. Any risks, issues, planning assumptions and constraints are also
identified.

4. Appoint the project team: The project team are now ready to be appointed. Although a
project manager may be appointed at any stage during the life of the project, the manager
will ideally be appointed prior to recruiting the project team. The project manager creates a
detailed job description for each role in the project team, and recruits people into each role
based on their relevant skills and experience.

5. Set up a project office: The project office is the physical environment within which the
team is based. Although it is usual to have one central project office, it is possible to have a
virtual project office with project team members located around the world. A project office
environment should include:

• Equipment, such as office furniture, computer equipment, stationery and materials;

• Communications infrastructure, such as telephones, computer network, e mail, Internet
access, file storage, database storage and backup facilities;
• Documentation, such as a project methodology, standards, processes, forms and registers;
• Tools, such as accounting, project planning and risk modeling software.

6. Perform a phase review: At the end of the initiation phase, perform a phase review.
This is basically a checkpoint to ensure that the project has achieved its objectives as
planned.

5
PHASE II : Project Planning
"Once the scope of the project has been defined in the terms of reference, the project enters
the planning phase. This involves creating a:

• Project plan outlining the activities, tasks, dependencies and timeframes;

• Resource plan listing the labor, equipment and materials required;
• Financial plan identifying the labor, equipment and materials costs;
• Quality plan providing quality targets, assurance and control measures;
• Risk plan highlighting potential risks and actions to be taken to mitigate those risks;
• Acceptance plan listing the criteria to be met to gain customer acceptance;
• Communications plan describing the information needed to inform stakeholders;
• Procurement plan identifying products to be sourced from external suppliers.

At this point the project will have been planned in some detail and is ready to he executed.

"By now, the project costs and benefits have been documented, the objectives and scope
have been defined, the project team has been appointed and a formal project office
environment established. It is now time to undertake detailed planning to ensure that the
activities performed during the execution phase of the project are properly sequenced,
resourced, executed and controlled. The activities shown in Figure 3 are undertaken.

Figure 3: Project planning activities

1. Create a project plan: The first step in the project planning phase is to document the
project plan. A 'work breakdown structure' (WBS) is identified which includes a hierarchical
set of phases, activities and tasks to be undertaken to complete the project. After the WBS
has been agreed, an assessment of the level of effort required to undertake each activity
and task is made. The activities and tasks are then sequenced, resources are allocated and a
detailed project schedule is formed. This project plan is the key tool used by the project
manager to assess the progress of the project throughout the project life cycle.

2. Create a resource plan: Immediately after the project plan is formed, the level of
resource required undertaking each of the activities and tasks listed within the project plan
will need to be allocated. Although generic resource may have already been allocated in the
project plan, a detailed resource plan is required to identify the:

• Type of resource required, such as labor, equipment and materials;

• Quantity of each type of resource required;
• Roles, responsibilities and skill sets of all human resource required;
• Specifications of all equipment resource required;
• Items and quantities of material resource required.
"A schedule is assembled for each type of resource so that the project manager can review
the resource allocation at each stage in the project.

6
3. Create a financial plan: A financial plan is created to identify the total quantity of
money required to undertake each phase in the project (in other words, the budget). The
total cost of labor, equipment and materials is calculated and an expense schedule is defined
which enables the project manager to measure the forecast spend versus the actual spend
throughout the project. Detailed financial planning is an extremely important activity within
the project, as the customer will expect the final solution to have been delivered within the
allocated budget.

4. Create a quality plan: Meeting the quality expectations of the customer can be a
challenging task. To ensure that the quality expectations are clearly defined and can
reasonably be achieved, a quality plan is documented. The quality plan:

• Defines the term 'quality' for the project.

• Lists clear and unambiguous quality targets for each deliverable. Each quality target
provides a set of criteria and standards to be achieved to meet the expectations of the
customer.
• Provides a plan of activities to assure the customer that the quality targets will be met (in
other words, a quality assurance plan).
• Identifies the techniques used to control the actual quality level of each deliverable as it is
built (in other words, a quality control plan).

Not only is it important to review the quality of the deliverables produced by the
project, it is also important to review the quality of the management processes that
produced them. A quality plan will summarize each of the management processes
undertaken during the project, including time, cost, quality, change, risk, issue,
procurement, acceptance and communications management.

5. Create a risk plan: The next step is to document all foreseeable project risks within a
risk plan. This plan also identifies the actions required to prevent each risk from occurring,
as well as reduce the impact of the risk should it eventuate. Developing a clear risk plan is
an important activity within the planning phase, as it is necessary to mitigate all critical
project risks prior to entering the execution phase of the project.

6. Create an acceptance plan: To deliver the project successfully, you will need to gain
full acceptance from the customer that the deliverables produced by the project meet or
exceed requirements. An acceptance plan is created to help achieve this, by clarifying the
completion criteria for each deliverable and providing a schedule of acceptance reviews.
These reviews provide the customer with the opportunity to assess each deliverable and
provide formal acceptance that it meets the requirements as originally stated.

7. Create a communications plan: Prior to the execution phase, it is also necessary to

identify how each of the stakeholders will be kept informed of the progress of the project.
The communications plan identifies the types of information to be distributed to
stakeholders, the methods of distributing the information, the frequency of distribution, and
responsibilities of each person in the project team for distributing the information.

8. Create a procurement plan: The last planning activity within the planning phase is to
identify the elements of the project to be acquired from external suppliers. The procurement
plan provides a detailed description of the products (that is, goods and services) to be
acquired from suppliers, the justification for acquiring each product externally as opposed to
from within the business, and the schedule for product delivery. It also describes the process

7
for the selection of a preferred supplier (the tender process), and the ordering and delivery
of the products (the procurement process).

9. Contract the suppliers: Although external suppliers may be appointed at any stage of
the project, it is usual to appoint suppliers after the project plans have been documented but
prior to the execution phase of the project. Only at this point will the project manager have
a clear idea of the role of suppliers and the expectations for their delivery. A formal tender
process is undertaken to identify a short list of capable suppliers and select a preferred
supplier to initiate contractual discussions with. The tender process involves creating a
statement of work, a request for information and request for proposal document to obtain
sufficient information from each potential supplier and select the preferred supplier. Once a
preferred supplier has been chosen, a contract is agreed between the project team and the
supplier for the delivery of the requisite products.

10. Perform a phase review: At the end of the planning phase, a phase review is
performed. This is a checkpoint to ensure that the project has achieved its objectives as
planned."

PHASE III : Project Execution

This phase involves implementing the plans created during the project planning phase. While
each plan is being executed, a series of management processes are undertaken to monitor
and control the deliverables being output by the project. This includes identifying change,
risks and issues, reviewing deliverable quality and measuring each deliverable produced
against the acceptance criteria. Once all of the deliverables have been produced and the
customer has accepted the final solution, the project is ready for closure. The activities of
this phase are shown in Figure 4.

8
Project management execution activities

The execution phase is typically the longest phase of the project in terms of duration.
It is the phase within which the deliverables are physically constructed and presented to the
customer for acceptance. To ensure that the customer's requirements are met, the project
manager monitors and controls the activities, resources and expenditure required to build
each deliverable. A number of management processes as shown are undertaken to ensure
that the project proceeds as planned.

1. Build the deliverables: This phase involves physically constructing each deliverable for
acceptance by the customer. The activities undertaken to construct each deliverable will vary
depending on the type of project being undertaken. Activities may be undertaken in a
'waterfall' fashion, where each activity is completed in sequence until the final deliverable is
produced, or in an 'iterative' fashion, where iterations of each deliverable are constructed
until the deliverable meets the requirements of the customer. Regardless of the method
used to construct each deliverable, careful monitoring and control processes should be
employed to ensure that the quality of the final deliverable meets the acceptance criteria set
by the customer.

2. Monitor and control: While the project team is physically producing each deliverable,
the project manager implements a series of management processes to monitor and control
the activities being undertaken by the project team. An overview of each management
process follows.

3. Time Management: Time management is the process of recording and controlling time
spent by staff on the project. As time is a scarce resource within projects, each team
member should record time spent undertaking project activities on a timesheet form. This
will enable the project manager to control the amount of time spent undertaking each
activity within the project. A timesheet register is also completed, providing a summary of
the time spent on the project in total so that the project plan can always be kept fully up to
date.

4. Cost management: Cost management is the process by which costs/expenses incurred

on the project are formally identified, approved and paid. Expense forms are completed for
each set of related project expenses such as labor, equipment and materials costs. Expense
forms are approved by the project manager and recorded within an expense register for
auditing purposes.

5. Quality management: Quality is defined as the extent to which the final deliverable
conforms to the customer requirements. Quality management is the process by which
quality is assured and controlled for the project, using quality assurance and quality control
techniques. Quality reviews are undertaken frequently and the results recorded on a quality
review form.

6. Change management: Change management is the process by which changes to the

project scope, deliverables, timescales or resources are formally requested, evaluated and
approved prior to implementation. A core aspect of the project manager's role is to manage
change within the project. This is achieved by understanding the business and system
drivers requiring the change, identifying the costs and benefits of adopting the change, and
formulating a structured plan for implementing the change. To formally request a change to
the project, a change form is completed. The status of all active change forms should he
recorded within a change register.
9
7. Risk management: Risk management is the process by which risks to the project are
formally identified, quantified and managed. A project risk may be identified at any stage of
the project by completing a risk form and recording the relevant risk details within the risk
register.

8. Issue management: Issue management is the method by which issues currently

affecting the ability of the project to produce the required deliverable are formally managed.
After an issue form has been completed and the details logged in the issue register, each
issue is evaluated by the project manager and a set of actions undertaken to resolve the
issue identified.

9. Procurement management: Procurement management is the process of sourcing

products from an external supplier. Purchase orders are used to purchase products from
suppliers, and a procurement register is maintained to track each purchase request through
to its completion.

10. Acceptance management: Acceptance management is the process of gaining

customer acceptance for deliverables produced by the project. Acceptance forms are used to
enable project staff to request acceptance for a deliverable, once complete. Each acceptance
form identifies the acceptance criteria, review methods and results of the acceptance
reviews undertaken.

11. Communications management: Communications management is the process by

which formal communications messages are identified, created, reviewed and communicated
within a project. The most common method of communicating the status of the project is via
a project status report. Each communications message released is captured in a
communications register.

12. Perform a phase review: At the end of the execution phase, a phase review is
performed. This is a checkpoint to ensure that the project has achieved its objectives as
planned."

PHASE IV : Project Closure

Project closure involves releasing the final deliverables to the customer, handing over
project documentation to the business, terminating supplier contracts, releasing project
resources and communicating the closure of the project to all stakeholders. The last
remaining step is to undertake a post implementation review to quantify the level of project
success and identify any lessons learnt for future projects.

Following the acceptance of all project deliverables by the customer, the project will
have met its objectives and be ready for closure. Project closure is the last phase in the
project life cycle, and must be conducted formally so that the business benefits delivered by
the project are fully realized by the customer. The activities outlined in following figure

10
Project closure activities

1. Perform project closure: Project closure, or 'close out', essentially involves winding up
the project. This includes:

• Determining whether all of the project completion criteria have been met;
• Identifying any outstanding project activities, risks or issues;
• Handing over all project deliverables and documentation to the customer;
• Canceling supplier contracts and releasing project resources to the business;
• Communicating the closure of the project to all stakeholders and interested parties.

A project closure report is documented and submitted to the customer and/or project
sponsor for approval. The project manager is responsible for undertaking each of the
activities identified in the project closure report, and the project is closed only when all the
activities listed in the project closure
report have been completed.

2. Review project completion: The final activity within a project is the review of its
success by an independent party. Success is determined by how well it performed against
the defined objectives and conformed to the management processes outlined in the planning
phase. To determine how well it performed, the following types of questions are answered:

• Did it result in the benefits defined in the business case?

• Did it achieve the objectives outlined in the terms of reference?
• Did it operate within the scope of the terms of reference? 0 Did the deliverables meet the
criteria defined in the quality plan?
• Was it delivered within the schedule outlined in the project plan?
• Was it delivered within the budget outlined in the financial plan?

To determine how well the project conformed, an assessment is made of the level of
conformity to the management processes outlined in the quality plan. These results, as well
as a list of the key achievements and lessons learnt, are documented within a post-
implementation review and presented to the customer and/or project sponsor for approval."

Note how each phase described in the preceding pages ends with a Stage Gate or
Phase Review. A Phase review is defined as: "A checkpoint at the end of each Project phase
to ensure that a project has achieved its stated objectives and Deliverables as planned" (for
that phase).

1.5 Risk management

• Risk concern future happenings

• Risk is defined as an exposure to the change of injury or loss
• Possibility that something negative may happen
• S/W Projects negatives
i.e. Adverse effect on 1.Cost 2.Quality 3. Schedule
• Risk management is to minimize the impact of risk on above three.
• Risk management is generally done by the project management.

Risk management can be considered as dealing with the possibilities and actual occurrence
of these events that are not regular or commonly expected.

11
 • Commonly expected events: e.g. going on leave or some requirement changing –
such things are handled by normal project management.
• So in a sense, risk management begins where normal project management ends.
• It deals with events that are infrequent, some what out of the control of the project
management.
• The idea of risk management is to minimize the possibility of risks materializing if
possible, or to minimize the effect of risk actually materializing.
• The risk management has to deal with identifying the undesirable events that can
occur, the probability of their occurring, and the loss if an undesirable event does
occur.

What is Risk Management?

Risk management is the systematic process of managing an organization's risk

exposures to achieve its objectives in a manner consistent with public interest, human
safety, environmental factors, and the law. It consists of the planning, organizing, leading,
coordinating, and controlling activities undertaken with the intent of providing an efficient
pre-loss plan that minimizes the adverse impact of risk on the organization's resources,
earnings, and cash flows.

Risk Management

 Risk Assessment (figuring out what the risks are and what to focus on)
o - making a list of all of the potential dangers that will affect the project
o - assessing the probability of occurence and potential loss of each item listed
o - ranking the items (from most to least dangerous)

 Risk Control (doing something about them)
o - coming up with techniques and strategies to mitigate the highest ordered
risks
o - implementing the strategies to resolve the high order risks factors
o - monitoring the effectiveness of the strategies and the changing levels of risk
throughout the project
12
Risk Assessment has three elements:

1) Identify Uncertainties

Explore the entire project plans and look for areas of uncertainty.

2) Analyse Risks

Specify how those areas of uncertainty can impact the performance of the project,
either in duration, cost or meeting the users' requirements.

3) Prioritise Risks

Establish which of those Risks should be eliminated completely, because of potential

extreme impact, which should have regular management attention, and which are
sufficiently minor to avoid detailed management attention.

Risk Control has three elements, as follows:

1) Mitigate Risks.

Take whatever actions are possible in advance to reduce the effect of Risk. It is better
to spend money on mitigation than to include contingency in the plan.

2) Plan for Emergencies.

For all those Risks which are deemed to be significant, have an emergency plan in
place before it happens.

3) Measure and Control.

Track the effects of the risks identified and manage them to a successful conclusion.

13
Chapter 2 - Software Project Estimation
Project Estimation

• Sometimes several product options and associated costs are presented at the reviews.
This allows the customer to choose a cost-effective solution from a range of possible
solutions.
• Customers sometimes fund the analysis phase and the preliminary design phase on
separate contracts in order to arrive at accurate cost and schedule estimates.
• Contracts for analysis and preliminary design are sometimes awarded to multiple
software development organizations by the customer, who then chooses any
organization to develop the software product on the basis of the analysis and
preliminary design competitions.
Project Estimation Process

 Step 1: Gather & Analyze Software Functional & Programmatic Requirements

 In this step we Analyze and refine software requirements, software

architecture, and programmatic constraints.

 Step 2: Define the Work Elements and Procurements

 The purpose of this step is to define the work elements and procurements for
the software project that will be included in the software estimate.

14
 Step 3: Estimating the size of the project

 Estimating the size of the software to be developed is the very first step to
make an effective estimation of the project. A customer's requirements and
system specification forms a baseline for estimating the size of a software. At a
later stage of the project, a system design document can provide additional
details for estimating the overall size of software.

 Step 4: Estimating the Effort

 The estimation of effort can be made from the organizational specifics of the
software development life cycle. The development of any application software
system is more than just coding of the system. Depending on deliverable
requirements, the estimation of effort for project will vary. Efforts are estimated
in the number of man-months

 Step 5: Estimating Schedule

 The schedule for a project will generally depend on human resources involved
in a process. Efforts in man-months are translated to calendar months.

 Step 6: Estimating the cost

 The cost of a project is derived not only from the estimates of effort and size
but from other parameters such as hardware, travel expenses,
telecommunication costs, training cost etc. should also be taken into account.

 Step 7: Determination of Impact of Risk

 The purpose of this step is to identify the software project risks, to assess their
impact on the cost estimate, and to revise the estimates based on the impacts.

 Step 8: Validate and Reconcile the Estimate via Models and Analogy

 In this step, validation and reconciliation of the estimates are done through
Models and Analogy.

15
First, in addition to the main estimate which we have developed in the preceding steps,
obtain a second estimate, using one of the following:

- Alternate Estimate: Have a second person or team, with similar software experience,
generate independent estimates.

- Historical Analogies: Through historical data compare the estimates with previous
experience such as size, effort, and cost of similar software; size versus functions; size
versus effort and cost (development productivity); technology versus effort and cost.

- Model-Based Estimates: Model based estimates are done by the use of models which
we will discuss after these steps.

Secondly, have the responsible people for this step who are able to compare the main
estimates with the second estimates, resolve the differences, and refine the estimates until a
consensus estimate is reached. The lowest estimates should be given special scrutiny, as
experience has demonstrated that estimates are usually low. For specific information on
validating and reconciling estimates with models.

 Step 9: Review and Approve the Estimates

 In this step just take a review of the above size, effort, schedule, and cost
estimates and compare with the project budget and schedule and approve
software size effort, schedule, and cost estimates to obtain project and line
management approval.

Empirical Estimation Models

 In this model, empirically derived formulas are used to predict data that are a
required part of the software project-planning step.

 The empirical data are derived from a limited sample of projects.

 Resource models consist of one or more empirically derived equations. These

equations are used to predict effort (in person-month), project duration, or other
pertinent project data.

 There are four classes of resource models:

 Static single-variable models

 Static multivariable models

 Dynamic multivariable models

 Theoretical models

 The basic version of the Constructive Cost Model, or COCOMO, is an example of a

static-variable model.

16
Difficulties of estimating Software Projects:

Some of the difficulties of estimating are inherent in the very nature of software,
especially its complexity and invisibility. In addition, the intensely human activities which
make up system development cannot be treated purely mechanistic way. Other difficulties
include:

• Novel applications of software: With traditional engineering projects, it is often the

case that the system to be created is similar to one constructed previously but for a
different customer or in a different location. The estimates for such a project can
therefore be based on previous experience. With software, in major projects the
product will in some way be unique and will therefore be clouded with doubts and
uncertainties.

• Changing technology: For example the original maintenance billing system might
have been written in Cobol, while the new extension for group accounts that might be
developed using an application building environment such as that provided by Oracle.

• Lack of homogeneity of project experience: As we will see, effective estimating

should be based on information about how past projects have performed. It is
surprising how many organizations do not make this data available to staff and might
also find that even where the previous project data is available, it may not be that
useful.

Where are estimates done?

Estimates are carried out at various stages of a software project. At each stage the reasons
for the estimate and the methods used will vary.

• Strategic planning: At this stage, the costs of computerizing potential applications

and the benefits of doing so may need to be estimated to help decide what priority to
give to each project. Such estimates may also influence the numbers of various types
of development staff to be recruited by the organization.

• Feasibility study: That the benefits of the potential system will justify the costs.

• System specification: Most system development methodologies usefully distinguish

between the definition of the users' requirements and the design which documents
how those requirements are to be fulfilled. The effort needed to implement different
design proposals will need to be estimated. Estimates at the design stage will also
confirm that the feasibility study is still valid, taking into account all that has been
learnt during detailed requirements analysis.

• Evaluation of suppliers' proposals: Potential contractors considering a bid would

need to scrutinize the system specification and produce estimates on which to base
proposals. We may wish to question a proposal which seems too low: they might
wonder, for example, whether the proposer had properly understood the
requirements. If, on the other hand, the bids seem too high they might reconsider in-
house development.

17
Software effort estimation techniques:

Barry Boehm, in his classic work on software effort models, identified the main ways of
deriving estimates of software development effort as:

Algorithmic models: which use 'effort drivers' representing characteristics of the target
system and the implementation environment to predict effort.

Expert judgment: where the advice of knowledgeable staff is solicited

Analogy: where a similar, completed, project is identified and its actual effort is used as the
basis of the estimate for the new project.

Parkinson: Which identifies the staff effort available to do a project and uses that as the
'estimate‘.

Price to win: Where the 'estimate' is a figure that appears to be sufficiently low to WIn a
contract.

Top-down: Where an overall estimate is formulated for the whole project which is then
broken down into the effort required for component tasks.

Bottom-up: where component tasks are identified and sized and these individual estimates
are aggregated.

Bottom-up estimating:

Estimating methods can be generally divided into bottom-up and top-down approaches. With
the bottom-up approach the estimator breaks the project into its component tasks and then
estimates how much effort will be required to carry out each task.

• With a large project, the process of breaking down into tasks would be a repetitive
one: each task would be analyzed into its component sub tasks and these in turn
would be further analyzed.
• It is suggested that this is repeated until you get to components that can be executed
by a single person in about a week or two.
• The reader may wonder why this is not called a top-down approach, after all, you are
starting from the top and working down. Although this top-down analysis is an
essential precursor to bottom-up estimating, it is really a separate one that of
producing a Work Breakdown Schedule (WBS).

Work Breakdown Structure :

Expert judgment and group consensus are top-down estimation techniques. The work
breakdown structure method is a bottom-up estimation tool. A work breakdown structure is
a hierarchical chart that accounts for the individual parts of a system. A WBS chart can
indicate either product hierarchy or process hierarchy.

• The bottom-up part comes in adding up the calculated effort for each activity to get
an overall estimate.
• The bottom-up approach is most appropriate at the later, more detailed, stages of
project planning.
18
 • If this method is used early on in the project cycle then the estimator will have to
make some assumptions about the characteristics of the final system, for example the
number and size of software components.
• These will be working assumptions that imply no commitment when it comes to the
actual design of the application.
• Where a project is completely novel or there is no historical data available, the
estimator would be forced to use the bottom-up approach.

The top-down approach and parametric models:

• The top-down approach is normally associated with parametric (or algorithmic)

models.
• These may be explained using the analogy of estimating the cost of rebuilding a
house.
• This would be of practical concern to a house-owner who needs sufficient insurance
cover to rebuild their property if destroyed.
• Unless the house-owner happens to be in the building trade it is unlikely that he or
she would be able to work out how many bricklayer-hours, how many carpenter
hours, electrician-hours and so on would be required.
• Insurance companies, however, produce convenient tables where the house-owner
can find an estimate of rebuilding costs based on such parameters as the number of
flours and the floor space that a house has. This is a simple parametric model.

The effort needed to implement a project will be related mainly to variables associated
with characteristics of the final system. The form of the parametric model will normally be
one or more formulae in the form:

effort = (system size) X (productivity rate)

For example, system size might be in the form 'thousands of lines of code' (KLOC)
and have the specific value of 3 KLOC while the productivity rate was 40 days per KLOC.
These values will often be matters of judgment.

A model to forecast software development effort therefore has two key components.
The first is a method of assessing the size of the software development task to be
undertaken. The second assesses the rate of work at which the task can be done.

19
 Some parametric models, such as that implied by function points, are focused on
system or task size, while others, such are COCOMO, are more concerned with productivity
factors.
Where applications are not built using procedural code, the size drivers might be
different types of component. For example, where Microsoft Access is being used, an
estimator might count tables, forms, queries, reports and so on.

Expert Judgment:

This is asking for an estimate of task effort from someone who is knowledgeable
about either the application or the development environment. This method is often used
when estimating the effort needed to change an existing piece of software. The estimator
would have to carry out some kind of impact analysis in order to judge the proportion of
code that would be affected and from that derive an estimate.

Someone already familiar with the software would be in the best position to do this.
Some have suggested that expert judgment is simply a matter of guessing, but our own
research has shown that experts tend to use a combination of an informal analogy approach
where similar projects from the past are identified, supplemented by bottom-up estimating.

Estimating by analogy:

• The use of analogy is also called case-based reasoning.

• The estimator seeks out projects that have been completed (source cases) and that
have similar characteristics to the new project (the target case).

• The effort that has been recorded for the matching source case can then be used as a
base estimate for the target.

• The estimator should then identify any differences between the target and the source
and make adjustments to the base estimate to produce an estimate of effort for the
new project.

• This can be a good approach where you have information about some previous
projects but not enough to draw generalized conclusions about what might be useful
drivers or typical productivity rates.

Delphi Cost Estimation:

The Delphi technique was developed at the Rand Corporation in 1948 to gain expert
consensus. The Delphi technique can be adapted to software cost estimation in the following
manner.

1. A coordinator provides each estimator with the System Definition document and a form
for recording a cost estimate.

2. Estimators study the definition and complete their estimates anonymously. They may ask
questions of the coordinator, but they do not discuss their estimates with one another.

3. The coordinator prepares and distributes a summary of the estimators' responses, and
includes any unusual rationales noted by the estimators.
20
4. Estimators complete another estimate, again anonymously, using the result from the
previous estimate. Estimators whose estimates differ sharply from the group may be asked,
anonymously, to provide justification for their estimates.

5. The process is iterated for as many rounds as required. No group discussion is allowed
during the entire process.

Albrecht function point analysis:

This is a top-down method that was devised by Allan Albrecht when he worked for IBM.
Albrecht was investigating programming productivity and needed some way to quantify the
functional size of programs independently of the programming languages in which they had
been coded. He developed the idea of function points (FPs).

The basis of function point analysis is that computer-based information systems comprise
five major components, or 'external user types' in Albrecht's terminology, that are of benefit
to the users.

21
 • External input types are input transactions which update internal computer files.

• External output types are transactions where data is output to the user. Typically
these would be printed reports, as screen displays would tend to come under external
inquiry types.

• Logical internal file types are the standing files used by the system. The term 'file'
does not sit easily with modern information systems. It refers to a group of data that
is usually accessed together. It may be made up of one or more record types. For
example, a purchase order file may be made up of a record type PURCHASE-ORDER
plus a second which is repeated for each item ordered on the purchase order -
PURCHASE-ORDER-ITEM. In structured systems analysis, a Logical Internal File would
equate to a data store, while record types would equate to relational tables or entity
types.

• External interface file types allow for output and input that may pass to and from
other computer applications. Examples of this would be the transmission of accounting
data from an order processing system to the main ledger system or the production of
a file of direct debit details on a magnetic or electronic medium to be passed to the
Bankers Automated Clearing System (BACS). Files shared between applications would
also be counted here.

• External inquiry types are transactions initiated by the user which provide
information but do not update the internal files. The user inputs some information that
directs the system to the details required.

• The analyst has to identify each instance of each external user type in the projected
system. Each component is then classified as having either high, average or low
complexity. The counts of each external user type in each complexity band are
multiplied by specified weights (see table 1) to get FP scores which are summed to
obtain an overall FP count which indicates the information.

Multiplier

External user type Low Average High

External input type 3 4 6
External output type 4 5 7
Logical internal file type 7 10 15
External interface file type 5 7 10
External inquiry type 3 4 6

One problem with FPs as originally defined by Albrecht was that the question of
whether the external user type was of high, low or average complexity was rather
subjective. The International FP User Group (IFPUG) has now promulgated rules on how this
is to be judged. For example, in the case of logical internal files and external interface files,
the boundaries shown in table2 are used to decide the complexity level.

22
 Number of data types

Number of record types <20 20-50 >50

1 Low Low Average
2 to 5 Low Average High
>5 Average High High

Example:

A logical internal file might contain data about purchase orders. These purchase orders
might be organized into two separate record types: the main PURCHASE-ORDER details
namely purchase order number, supplier reference and purchase order date and then details
for each PURCHASE-ORDER-ITEM specified in the order, namely the product code, the unit
price and number ordered.

The number of record types for that file would therefore be 2 and the number of data
types would be 6. According to Table 2, this file type would be rated as 'low'. This would
mean that according to Table 1, the FP count would be 7 for this file.

• A Function point analysis now goes on to take into account the fact that the effort
required to implement a computer-based information system will relate not just to the
number and complexity of the features to be provided but also to the environment in
which the system is to operate.

• The technical complexity adjustment (TCA) calculation has had many problems. Some
have even found that it produces less accurate estimates than using the unadjusted
function point count. Because of these difficulties, we are going to omit further
discussion of the TCA.

Tables have been calculated to convert the FPs to lines of code for various languages.
For example, it is suggested that 91 lines of Cobol are needed on average to implement an
FP, while for C the figure is 128 and for Quick Basic it is 64. You can then use historical
productivity data to convert the lines of code into an effort estimate.

Function Points Mark II

• The Mark II method was originally sponsored by what was then the CCTA (Central
Computer and Telecommunications Agency, now the Office of Government Commerce
or OGC) which lays down standards for UK government projects. At one time this
Mark II approach seemed to be a good method to use with the structured systems
analysis and design method, SSADM, but some drawbacks to this became apparent.
The 'Mark II' label implies an improvement and replacement of the Albrecht method.
The Albrecht (now IFPUG) method, however, has had many refinements made to it
and FPA Mark II remains a minority method used mainly in the United Kingdom.

• As with Albrecht, the information processing size is initially measured in unadjusted

function points (UFPs) to which a technical complexity adjustment can then be applied
(TCA). The assumption is that an information system comprises transactions which
have the basic structure.

23
 For each transaction the UFPs are calculated:

Wi x (number of input data element types) +

We X (number of entity types referenced) +
Wo X (number of output data element types)

Wi, We and Wo are weightings that may be derived by asking developers what
proportion of effort has been spent in previous projects developing those parts of the
software that deal with processing inputs, accessing and modifying stored data and
processing outputs. From this it should be possible to work out the average hours of work
generated by instances of each type of element.

Mark II FPs follow the Albrecht method in recognizing that one system delivering the
same functionality as another may be more difficult to implement (but also more valuable
to the users) because of additional technical requirements. For example, the
incorporation of additional security measures would increase the amount of effort to
deliver the system. The original Albrecht FP method identified 14 technical complexity
adjustment factors - Mark II FPs identify five more factors:

. interfaces to other applications;

. special security features;
. direct access for third parties;
. user training features;
. documentation requirements.

The identification of further factors to suit local circumstances is encouraged. With

both the Albrecht and Symons methods, FPs can be counted for previous projects where
actual effort is known. If you have figures for the effort expended on past projects (in
work-days for instance) and also the system sizes in FPs, you should be able to work out
a productivity rate, as

productivity = size/effort

For new projects, the function points can be counted and then the effort can be
projected using the productivity rate derived above:

effort = size/productivity

COCOMO: a parametric model

Boehm's COCOMO (Constructive Cost Model) is often referred to in the literature on

software project management, particularly in connection with software estimating. The term
COCOMO really refers to a group of models.

Boehm originally based his models in the late 1970s on a study of 63 projects. Of these
only seven were business systems and so the models could be used with applications other
than information systems. The basic model was built around the equation

(effort) = c (size)k

24
 Where effort was measured in pm or the number of 'person-months' consisting of units
of 152 working hours, size was measured in kdsi, thousands of delivered source code
instructions, and c and k were constants.

The first step was to derive an estimate of the system size in terms of kdsi. The constants, c
and k (see table given below), depended on whether the system could be classified, in
Boehm's terms, as 'organic', 'semi-detached' or 'embedded'. These related to the technical
nature of the system and the development environment.

. Organic mode: This would typically be the case when relatively small teams developed
software in a highly familiar in-house environment and when the system being developed
was small and the interface requirements were flexible.

. Embedded mode: This meant the product being developed had to operate within very
tight constraints and changes to the system were very costly.

. Semi-detached mode: This combined elements of the organic and the embedded modes
or had characteristics which came between the two.

The exponent value k, when it is greater than 1. means that larger projects are seen
as requiring disproportionately more effort than smaller ones. This reflected Boehm's finding
that larger projects tended to be less productive than smaller ones because they needed
more effort for management and coordination.

Table: COCOMO constants

System Type c k

Organic 2.4 1.05

Semi-detached 3.0 1.12

Embedded 3.6 1.20

Boehm in fact found this, by itself, to be a poor predictor of the effort required and so
went on to develop the intermediate version of COCOMO which took into account 15 cost
drivers. In the intermediate model, a nominal effort estimate (pmnom) is derived in a similar
way as for the basic model.

The nominal estimate is then adjusted by a development effort multiplier (dem):

(pmest) = (pmnom) X (dem)

where dem is calculated by taking into account multipliers based on the effort drivers
in table given below.

These multipliers take into account such influences on productivity as Boehm's finding
that having a programming team fully conversant with the programming language to be
used could reduce the effort required to implement the project by up to 20% compared to a
25
team with a very low or initially non-existent familiarity with the programming language. In
fact, the biggest influence on productivity, according to Boehm, relates to the capabilities of
the implementation team.

As an example of the approach, an organization may decide to use the following

multipliers for assessing the effect of analyst capability (ACAP).

Very low 1.46

Low 1.19

Nominal 1.00

High 0.8

Very High 0.71

If the analysts involved in a project, taken as a whole, generally possess above-average

talent and productivity then the estimator might rate the ACAP as high and use a multiplier
of 0.8, effectively reducing the nominal estimate by 20%.

Table 5.7 COCOMO intermediate cost drivers

Driver type Code Cost driver

Product attributes RELY Required software reliability
DATA Database size
CPLX Product complexity
Computer attributes TIME Execution time constraints
STOR Main storage constraints
VIRT Virtual machine volatility - degree to
which the operating system changes
TURN Computer turnaround time
Personnel attributes ACAP Analyst capability
AEXP Application experience
PCAP Programmer capability
VEXP Virtual machine (Le. operating
system) experience
LEXP Programming language experience
Project attributes MODP Use of modern programming
practices
TOOL Use of software tools
SCED Required development schedule

26
 The overall dem is calculated by multiplying the multipliers selected for each cost
driver in Table 5.7 to create a single combined multiplier.

Attribute Very low Low Nominal High Very high

ACAP 1.46 1.19 1.00 0.86 0.71

AEXP 1.29 1.13 1.00 0.91 0.82

PCAP 1.42 1.17 1.00 0.86 0.70

VEXP 1.21 1.10 1.00 0.90

LEXP 1.14 1.07 1.00 0.95

COCOMO II:

A new family of models, COCOMO II, has been refined by Barry Boehm and his co-
workers. This approach uses various multipliers and exponents the values of which have
been set initially by experts. However, a database containing the performance details of
executed projects is being built up and periodically analyzed so that the expert judgements
can be progressively replaced by values derived from actual projects. The new models take
into account that there is now a wider range of process models in common use for software
development projects than in the late 1970s and early 1980s. As we noted earlier, estimates
are required at different stages in the system life cycle and COCOMO II has been designed
to accommodate this by having models for three different stages.

Application composition Here the external features of the system that the users will
experience are designed. Prototyping will typically be employed to do this. With small
applications that can be built using high-productivity application building tools, development
can stop at this point.

Early design Here the fundamental software structures are designed. With larger,
more demanding systems, where, for example, there will be large volumes of transactions
and performance is important, careful attention will need to be paid to the architecture to be
adopted.

Post architecture Here the software structures undergo final construction, modification
and tuning to create a system that will perform as required.

To estimate the effort for application composition, the counting of object points is
recommended by the developers of COCOMO II. This follows the function point approach of
counting externally apparent features of the software. It differs by focusing on the physical
features of the application, such as screens and reports, rather than 'logical' ones like entity
types. This is seen as being more useful whether requirements are being elicited via
prototypes.

27
 At the early design stage, FPs are recommended as the way of gauging a basic system
size. An FP count may be converted to a LOC equivalent by multiplying the FPs by a factor
for the programming language that is to be used.

The following model can then be used to calculate an estimate of person. months.

pm = A(size)(sf) X (em1) X (em2) X . .. (emn)

where pm is the effort in 'person-months', A is a constant (which was, in 1998, 2.45),

size is measured in kdsi (which may have been derived from an FP count as explained
above), and sf is exponent scale factor.

The scale factor is derived thus:

sf= 1.01 + 0.01 X Σ (exponent driver ratings).

The qualities that govern exponent drivers used to calculate the scale factor are listed
below. Note that the less each quality is applicable, the bigger the value give to the
exponent driver. The fact that these factors are used to calculate an exponent implies that
the lack of these qualities will increase the effort required disproportionately more on larger
projects.

• Precedentedness This quality refers to the degree to which there are precedents,
that is, similar cases in the past, for the project that is being planned. The greater the
novelty of the new system, the more uncertainty there is and the higher the value
given to the exponent driver.

• Development flexibility This is the degree to which the requirements can be met in
a number of different ways. The less flexibility there is, the higher the value of the
exponent driver.

• Architecture/risk resolution This relates to the degree of uncertainty there is

about the requirements. If they are not firmly fixed and are liable w change then this
would lead to a high value being given to this exponent driver.

• Team cohesion This reflects the degree to which there is a large dispersed team
(perhaps in several countries) as opposed to there being a small tightly knit team.

• Process maturity The more structured and organized the way the software is
produced, the lower the uncertainty and the lower the rating will be for this exponent
driver.

A new project has 'average/ novelty for the software supplier that is going to execute
it and is thus given a 3 rating on this account for precedentedness. Development feasibility
is high to the extent that this generates a zero rating, but requirements m~ changes
radically and so the risk resolution exponent is rated at 4. The team is very cohesive and
this generates a rating of 1/ but the software house as a whole tends to be very

28
• In the COCOMO II model the effort multipliers (em) are similar in nature to the
development effort multipliers (dem) used in the original COCOMO. There are seven
of these multipliers that are relevant to early design and sixteen that can be used at
the post architecture stage.

• Table 5.8 lists the effort multipliers for early design and Table 5.9 for post
architecture. Each of these multipliers may, for a particular application, be given a
rating of very low, low, nominal, high or very high. Each rating for each effort
multiplier has a value associated with it.

• A value greater than 1 means that development effort is increased, while a value less
than one causes effort to be decreased. The nominal rating means that the multiplier
has no effect on the estimate, Le. it is 1. The intention is that the ratings that these
and other values use in COCOMO II will be modified and refined over time as details
of actual projects are added to the database.

29
Chapter 3-Project Mgmt Tools & Techniques
Project Scheduling:
• Software project scheduling is an activity that distributes estimated effort across the
planned project duration by allocating the effort to specify software engineering tasks.
• Every project has a deadline to complete. So, software projects also have a deadline
to meet.
• To complete a software project within a time frame, proper scheduling should be
done.
• In other words, we can say that successful software projects are those that have been
successfully placed a schedule.
• A software project scheduling involves plotting project activities against a time frame.
• So, the scheduling is about developing a road map structure or a network based on
analysis of the tasks that must be performed to complete the projects.
• During early stages of project planning, a microscopic schedule is developed.
• This type of schedule identifies all major software-engineering activities and the
product functions to which they are applied.
• As the project gets under way, each entry on the macroscopic schedule is refined into
a detailed schedule.
• Here, specific software tasks are identified and scheduled.
• The scheduling objective is to define all project tasks, build a network that depicts
their interdependencies, identity the tasks that are critical within the network, ant
then track their progress.
• To accomplish this, the manager must have a schedule that has been defined at a
degree of resolution that enables the manager to monitor progress and control the
project.
• Program evaluation and review technique (PERT) and critical Path method (CPM) are
two project scheduling methods that are applied to software development.
• Both techniques are driven by information already developed in earlier project
planning activities.
• Gantt charts are a project control technique that can be used for several purposes,
including scheduling, budgeting and resources planning.
• A Gantt chart is a bar chart, with each bar is proportional to the length of time
planned for the activity. Inter task dependencies cannot be shown using these
techniques.
• PERT charts show tasks inter dependencies directly. It is organized by events and
activities or tasks.
• PERT controls time and cost during the project and also facilitate finding the right
balance between completing a project on time and completing it within the budget.
• Gantt and PERT charts are not mutually executive. Gantt charts are more effective
when you are seeking to communicate schedule.
• PERT charts are more effective when you want to study the relationships between
tasks.

o Bar Charts
 Milestone Chart
 Gantt Chart
o Mathematical Analysis
 Network Diagrams
 PERT
 CPM

30
Milestone Chart

• Sometimes called a “bar charts”

• Simple Gantt chart

– Either showing just highest summary bars

– Or milestones only

Bar Chart

Gantt Charts:

• The Gantt Charts first conceived by Henry L. Gantt in 1917, is the most
commonly used project scheduling and progress evaluation tool.

• A Gantt chart is a simple horizontal bar chart that depicts project tasks against
a calendar.

• Gantt chart is one of the simplest & oldest techniques for tracking project
progress.

• This is essentially an activity bar chart indicating scheduled activity dates and
durations frequently augmented with activity floats.

• Reported progress is recorded on the chart (normally by shading activity bars)

and a today cursor provides an immediate visual indication of which activities
are ahead or behind schedule.

• Each bar represents a named project task. The tasks are listed vertically in the
left hand column. The horizontal axis is a calendar time line.

31
 • Disadvantages
– Does not show interdependencies well
– Does not uncertainty of a given activity (as does PERT)
• Advantages
– Easily understood
– Easily created and maintained
• Note: Software now shows dependencies among tasks in Gantt charts
– In the “old” days Gantt charts did not show these dependencies, bar charts
typically do not

Network Diagrams:
• Developed in the 1950’s
• A graphical representation of the tasks necessary to complete a project
• Visualizes the flow of tasks & relationships

Mathematical Analysis:

• PERT
– Program Evaluation and Review Technique
• CPM
– Critical Path Method
• Sometimes treated synonymously
• All are models using network diagrams

Network Diagrams:
• Two classic formats
– AOA: Activity on Arrow
– AON: Activity on Node

32
 • Each task labeled with
• Identifier (usually a letter/code)
• Duration (in std. unit like days)
• There are other variations of labeling
• There is 1 start & 1 end event
• Time goes from left to right

Network Diagrams

• Two classic formats

– AOA: Activity on Arrow
– AON: Activity on Node
• Each task labeled with
• Identifier (usually a letter/code)
• Duration (in std. unit like days)
• There are other variations of labeling
• There is 1 start & 1 end event
• Time goes from left to right

PERT Chart:
• PERT which stands for Project Evaluation and Review Technique was developed
in the late 1950s to plan and control large weapons development projects for
the U.S. Navy.
• A PERT chart is a graphical network model that depicts a project task and the
relationship between these tasks.
• PERT was developed to make clear that independence between project tasks
before those tasks are scheduled.
• The boxes represents project tasks.
• The contents of the boxes can be adjusted to show various project attributes
such as schedule and actual start and finish times.
• The arrow indicate that one task is dependent on the start or completion of
another task.
• A sample PERT chart is illustrated in figure below.
• Program Evaluation and Review Technique
• Based on idea that estimates are uncertain
• Therefore uses duration ranges
• And the probability of falling to a given range
• Uses an “expected value” (or weighted average) to determine durations
• Use the following methods to calculate the expected durations, then use as
input to your network diagram

33
 • Start with 3 estimates
– Optimistic
• Would likely occur 1 time in 20
– Most likely
• Modal value of the distribution
– Pessimistic
• Would be exceeded only one time in 20

PERT Formula:
Combined to estimate a task duration

• Confidence Interval can be determined

• Based on a standard deviation of the expected time
• Using a bell curve (normal distribution)

• For the whole critical path use

PERT Example:

Description Planner 1 Planner 2

m 10d 10d
a 9d 9d
b 12d 20d
PERT time 10.16d 11.5d
Std. Dev. 0.5d 1.8d

• Confidence interval for P2 is 4 times wider than P1 for a given probability

• Ex: 68% probability of 9.7 to 11.7 days (P1) vs. 9.5-13.5 days (P2)

34
PERT
• Advantages
– Accounts for uncertainty
• Disadvantages
– Time and labor intensive
– Assumption of unlimited resources is big issue
– Lack of functional ownership of estimates
– Mostly only used on large, complex project
• Get PERT software to calculate it for you

Critical Path
• “The specific set of sequential tasks upon which the project completion date
depends”

– or “the longest full path”

• All projects have a Critical Path

• Accelerating non-critical tasks do not directly shorten the schedule

Critical Path Example

• Critical Path Method

– The process for determining and optimizing the critical path

• Non-CP tasks can start earlier or later w/o impacting completion date

• Note: Critical Path may change to another as you shorten the current

35
Forward Pass

• To determine early start (ES) and early finish (EF) times for each task

• Work from left to right

• Adding times in each path

• Rule: when several tasks converge, the ES for the next task is the largest of
preceding EF times

Example Step 2

36
Backward Pass

• To determine the last finish (LF) and last start (LS) times

• Start at the end node

• Compute the bottom pair of numbers

• Subtract duration from connecting node’s earliest start time

Example Step 3

Example Step 4

37
Slack & Reserve

• How can slack be negative?

• What does that mean?

• How can you address that situation?

Reserve Negative
Time Slack

Forward
Pass

A B

Backward
Pass

Start Project Due

Date Date

Network Diagrams

• Advantages
– Show precedence well
– Reveal interdependencies not shown in other techniques
– Ability to calculate critical path
– Ability to perform “what if” exercises

• Disadvantages
– Default model assumes resources are unlimited
• You need to incorporate this yourself (Resource Dependencies) when
determining the “real” Critical Path
– Difficult to follow on large projects

4 Task Dependency Types

• External Dependencies
• Outside of the project itself
• Ex: Release of 3rd party product; contract signoff
• Ex: stakeholders, suppliers, Y2K, year end
• Resource Dependencies
• Two task rely on the same resource
• Ex: You have only one DBA but multiple DB tasks
38
Task Dependency Relationships

• Finish-to-Start (FS)
– B cannot start till A finishes
– A: Construct fence; B: Paint Fence

• Start-to-Start (SS)
– B cannot start till A starts
– A: Pour foundation; B: Level concrete

• Finish-to-Finish (FF)
– B cannot finish till A finishes
– A: Add wiring; B: Inspect electrical

• Start-to-Finish (SF)
– B cannot finish till A starts (rare)

CPM vs. PERT

• Both use Network Diagrams

• CPM: deterministic
• PERT: probabilistic
• CPM: one estimate, PERT, three estimates
• PERT is infrequently used

Introduction to Microsoft Project:

• Microsoft Project (or MSP) is a project management software program

developed and sold by Microsoft which is designed to assist Project managers
in developing plans, assigning resources to tasks, tracking progress, managing
budgets and analyzing workloads.

• The first version, Microsoft project for windows v1.0, was started in 1987 on a
contract to a small external company.

• In 1988 the company was acquired by Microsoft, bringing, the development

project in-house where it was finished and released in 1990 as part of the
company's applications offerings for Microsoft Windows 3.0.

• Microsoft Project was the company's third Windows-based application, and

within a couple of years of its introduction WinProj was the dominant PC-based
project management software.

39
Feature description:

• Project creates budgets based on assignment work and resource rates.

• As resources are assigned to tasks and assignment work estimated, the
program calculates the cost equals the work times the rate, which rolls up to
the task level and then to any summary tasks and finally to the project level.
• Resource definitions (people, equipment and materials) can be shared between
projects using a shared resource pool.
• Each resource can have its own calendar, which defines what days and shifts a
resource is available.
• Resource rates are used to calculate resource assignment costs which are
rolled up and summarized at the resource level.
• Each resource can be assigned to multiple tasks in multiple plans and each
task can be assigned multiple resources, and the application schedules task
work based on the resource availability as defined in the resource calendars.
Enhancements:

• In later versions of Microsoft Office, Microsoft Project's capabilities

were extended with the introduction of Microsoft Office Project
Server and Microsoft Project Web Access.
• Project Server stores Project data in a central SQL-based database,
allowing users to display and update this data over the Internet.
• Web Access allows authorized users to access a Project Server
database across the Internet, and includes timesheets, graphical
analysis of resource workloads, and administrative tools.
What Can Microsoft Project Do For You?:

• As such it can do the calculations accurately for you. Imagine doing the forward pass
using calendar working days, taking into account national and company holidays!
Doing the backward pass is even more minded boggling and prone to error.

• It makes visible the parameters it needs (have I forgotten something?)

• It allows "what-ifs?" to make changes to the project and see the effect of those
changes before finalizing your plan and committing it to work.

• Once your plan is in action, it allows progress to be tracked so that you can make
adjustments to keep on target.

• And finally it is a tremendous aid to communication:

i. There are built-in reports to print.
ii. You can export to PowerPoint for presentations, to Word for detailed reports, to
Excel to do intricate cost analyses, and to Access' for manipulation of project data.
iii. You can send information by e-mail.
iv. You can pass information over networks and the Internet.

40
Tips for Working with Microsoft Project:

• Microsoft Project is a flexible software application for creating schedule graphics,

estimating resource requirements, analyzing task dependencies, and tracking project
progress.

• It can be used to provide a graphical presentation of your project schedule, where you
simply list the tasks and assign task durations or dates.

• While that approach may enable you to present a schedule picture to management, it
is not adequate for managing a project with any size, complexity, or risk.

• The method describe below provides a more comprehensive use of Microsoft Project,
using its resource management features to help you determine if you have a
reasonable plan.

In many project environments, managing staff resources and dealing with

unreasonable schedules are the bigger parts of achieving project success

Tips for Working with Microsoft Project:

Step 1:
• The first step in using MS-Project (MSP) is to assign the project start date.
• The project start' date will be the default start date for all tasks until you establish
dependency relationships.
• If you don't put in a start date, MSP will put in the current date.
• If yours is a long-term project, you may also want to adjust your project "Calendar“
at this time to compensate for holiday times.

Step 2:
• The next step is to write a list 'of tasks to fill the left column of the Gantt schedule
and organize them in a deliverable-oriented work breakdown structure (WBS).

Step 3:
• After the WBS and task list are defined, add resources and work estimates (hours).
Please do not input end dates or task durations!
• The software tool will only be useful for resource planning if you assign resources and
then enter work effort (in hours), and then let MSP determine the dates and
durations.

Step 4:
• The next step is to establish the dependencies or "precedence's" between the tasks.

Step 5:
• When you have iterated your plan so you feel that the task list is complete, the
dependencies are realistic, the staffing is feasible" the work estimates are valid, and
the overall schedule result is, acceptable then save the plan as a baseline.
• That will enable you to use the Tracking Gantt feature in the future to status your
project.
Step 6:
• Use the "View/Resource Usage" to look at projected expenditure of labor by skill
category for the duration of the project.
41
4. Software Quality Management & Testing
4.1 Quality Assurance & Standards
4.2 Quality Planning
4.3 Quality control
4.4 Role of testing in Software development
4.5 Testing Procedure
4.6 Defect Management

5. Configuration Management (CM)

5.1 CM planning
5.2 Change Management
5.3. Version and Release Management
5.4 Configuration Management Tools

6. S/W Team Management

6.1 Characteristics of Performance
management
6.2 High performance Directive and
collaborative styles
6.3 Team Structure
6.4 Team Communication
6.5 Managing customer expectations
6.6 Group Behavior

7. Role of User in Projects

7.1 User role in project management
7.2 User role in various stages of S/W
Development
7.3 User role in System implementation

42