Module 2

What is Project?
A project is a group of tasks that need to complete to reach a clear result. A project also defines as a
set of inputs and outputs which are required to achieve a goal. Projects can vary from simple to
difficult and can be operated by one person or a hundred.

Projects usually described and approved by a project manager or team executive. They go beyond
their expectations and objects, and it's up to the team to handle logistics and complete the project on
time. For good project development, some teams split the project into specific tasks so they can
manage responsibility and utilize team strengths.

What is software project management?

Software project management is an art and discipline of planning and supervising software projects. It
is a sub-discipline of software project management in which software projects planned, implemented,
monitored and controlled.

It is a procedure of managing, allocating and timing resources to develop computer software that
fulfills requirements.

In software Project Management, the client and the developers need to know the length, period and
cost of the project.

Prerequisite of software project management?

There are three needs for software project management. These are:

1. Time
2. Cost
3. Quality

It is an essential part of the software organization to deliver a quality product, keeping the cost within
the client’s budget and deliver the project as per schedule. There are various factors, both external and
internal, which may impact this triple factor. Any of three-factor can severely affect the other two.

Project Manager
A project manager is a character who has the overall responsibility for the planning, design,
execution, monitoring, controlling and closure of a project. A project manager represents an essential
role in the achievement of the projects.

A project manager is a character who is responsible for giving decisions, both large and small
projects. The project manager is used to manage the risk and minimize uncertainty. Every decision the
project manager makes must directly profit their project.

1
Role of a Project Manager:
1. Leader

A project manager must lead his team and should provide them direction to make them understand
what is expected from all of them.

2. Medium:

The Project manager is a medium between his clients and his team. He must coordinate and transfer
all the appropriate information from the clients to his team and report to the senior management.

3. Mentor:

He should be there to guide his team at each step and make sure that the team has an attachment. He
provides a recommendation to his team and points them in the right direction.

Responsibilities of a Project Manager:

1. Managing risks and issues.
2. Create the project team and assigns tasks to several team members.
3. Activity planning and sequencing.
4. Monitoring and reporting progress.
5. Modifies the project plan to deal with the situation.

Project Management Process

Project Management is a discipline about planning, monitoring, and controlling software projects,
identifying the scope, estimating the work involved, and creating a project schedule. Along with it
is also responsible to keep the team up to date on the project’s progress and handle problems and
discuss solutions.
The Project Management Process consists of the following 4 stages:
 Feasibility study
 Project Planning
 Project Execution
 Project Termination

2
Feasibility Study:
A feasibility study explores system requirements to determine project feasibility. There are several
fields of a feasibility study including economic feasibility, operational feasibility, and technical
feasibility. The goal is to determine whether the system can be implemented or not. The process of
feasibility study takes as input the required details as specified by the user and other domain-
specific details. The output of this process simply tells whether the project should be undertaken or
not and if yes, what would the constraints be. Additionally, all the risks and their potential effects
on the projects are also evaluated before a decision to start the project is taken.
Project Planning:
A detailed plan stating a stepwise strategy to achieve the listed objectives is an integral part of any
project.
Planning consists of the following activities:
 Set objectives or goals
 Develop strategies
 Develop project policies
 Determine courses of action
 Making planning decisions
 Set procedures and rules for the project
 Develop a software project plan
 Prepare budget
 Conduct risk management
 Document software project plans
This step also involves the construction of a work breakdown structure(WBS). It also includes size,
effort, schedule, and cost estimation using various techniques.
Project Execution:
A project is executed by choosing an appropriate software development lifecycle model(SDLC). It
includes a number of steps including requirements analysis, design, coding, testing and
implementation, testing, delivery, and maintenance. There are a number of factors that need to be
considered while doing so including the size of the system, the nature of the project, time and budget
constraints, domain requirements, etc. An inappropriate SDLC can lead to the failure of the project.
Project Termination:
There can be several reasons for the termination of a project. Though expecting a project to terminate
after successful completion is conventional, at times, a project may also terminate without
completion. Projects have to be closed down when the requirements are not fulfilled according to
given time and cost constraints.
Some of the reasons for failure include:

 Fast-changing technology
 Project running out of time
 Organizational politics
 Too much change in customer requirements
 Project exceeding budget or funds
Once the project is terminated, a post-performance analysis is done. Also, a final report is published
describing the experiences, lessons learned, and recommendations for handling future projects.
Conclusion
Project management is a procedure that requires responsibility. The project management process
brings all of the other project tasks together and ensures that the project runs smoothly. As a result,
the project management team should have a thorough awareness of all project management
procedures as well as the tools that can be used for each one.

Project size estimation techniques

Estimation of the size of the software is an essential part of Software Project Management. It helps
the project manager to further predict the effort and time which will be needed to build the project.

3
Various measures are used in project size estimation. Some of these are:

 Lines of Code
 Number of entities in ER diagram
 Total number of processes in detailed data flow diagram
 Function points
1. Lines of Code (LOC): As the name suggests, LOC count the total number of lines of source
code in a project. The units of LOC are:

 KLOC- Thousand lines of code

 NLOC- Non-comment lines of code
 KDSI- Thousands of delivered source instruction
The size is estimated by comparing it with the existing systems of the same kind. The experts use it
to predict the required size of various components of software and then add them to get the total
size.
It’s tough to estimate LOC by analysing the problem definition. Only after the whole code has been
developed can accurate LOC be estimated. This statistic is of little utility to project managers
because project planning must be completed before development activity can begin.
wo separate source files having a similar number of lines may not require the same effort. A file
with complicated logic would take longer to create than one with simple logic. Proper estimation
may not be attainable based on LOC.
The length of time it takes to solve an issue is measured in LOC. This statistic will differ greatly
from one programmer to the next. A seasoned programmer can write the same logic in fewer lines
than a newbie coder.
Advantages:

 Universally accepted and is used in many models like COCOMO.

 Estimation is closer to the developer’s perspective.
 Simple to use.
Disadvantages:

 Different programming languages contain a different number of lines.

 No proper industry standard exists for this technique.
 It is difficult to estimate the size using this technique in the early stages of the project.
2. Number of entities in ER diagram: ER model provides a static view of the project. It describes
the entities and their relationships. The number of entities in ER model can be used to measure the
estimation of the size of the project. The number of entities depends on the size of the project. This
is because more entities needed more classes/structures thus leading to more coding.
Advantages:

 Size estimation can be done during the initial stages of planning.

 The number of entities is independent of the programming technologies used.
Disadvantages:

 No fixed standards exist. Some entities contribute more project size than others.
 Just like FPA, it is less used in the cost estimation model. Hence, it must be converted to LOC.
3. Total number of processes in detailed data flow diagram: Data Flow Diagram(DFD)
represents the functional view of software. The model depicts the main processes/functions
involved in software and the flow of data between them. Utilization of the number of functions in
DFD to predict software size. Already existing processes of similar type are studied and used to

4
estimate the size of the process. Sum of the estimated size of each process gives the final estimated
size.
Advantages:

 It is independent of the programming language.

 Each major process can be decomposed into smaller processes. This will increase the accuracy
of estimation
Disadvantages:

 Studying similar kinds of processes to estimate size takes additional time and effort.
 All software projects are not required for the construction of DFD.
4. Function Point Analysis: In this method, the number and type of functions supported by the
software are utilized to find FPC(function point count). The steps in function point analysis are:

 Count the number of functions of each proposed type.

 Compute the Unadjusted Function Points(UFP).
 Find Total Degree of Influence(TDI).
 Compute Value Adjustment Factor(VAF).
 Find the Function Point Count(FPC).
The explanation of the above points is given below:

 Count the number of functions of each proposed type: Find the number of functions
belonging to the following types:

 External Inputs: Functions related to data entering the system.

 External outputs: Functions related to data exiting the system.
 External Inquiries: They lead to data retrieval from the system but don’t change the
system.
 Internal Files: Logical files maintained within the system. Log files are not included
here.
 External interface Files: These are logical files for other applications which are
used by our system.
 Compute the Unadjusted Function Points(UFP): Categorise each of the five function
types like simple, average, or complex based on their complexity. Multiply the count of
each function type with its weighting factor and find the weighted sum. The weighting
factors for each type based on their complexity are as follows:
Function type Simple Average Complex

External Inputs 3 4 6

External Output 4 5 7

External Inquiries 3 4 6

Internal Logical Files 7 10 15

External Interface
Files 5 7 10

5
 Find Total Degree of Influence: Use the ’14 general characteristics’ of a system to find the
degree of influence of each of them. The sum of all 14 degrees of influence will give the TDI.
The range of TDI is 0 to 70. The 14 general characteristics are: Data Communications,
Distributed Data Processing, Performance, Heavily Used Configuration, Transaction Rate, On-
Line Data Entry, End-user Efficiency, Online Update, Complex Processing Reusability,
Installation Ease, Operational Ease, Multiple Sites and Facilitate Change.
Each of the above characteristics is evaluated on a scale of 0-5.

 Compute Value Adjustment Factor(VAF): Use the following formula to calculate VAF
VAF = (TDI * 0.01) + 0.65

 Find the Function Point Count: Use the following formula to calculate FPC
FPC = UFP * VAF
Advantages:

 It can be easily used in the early stages of project planning.

 It is independent of the programming language.
 It can be used to compare different projects even if they use different technologies(database,
language, etc).
Disadvantages:

 It is not good for real-time systems and embedded systems.

 Many cost estimation models like COCOMO uses LOC and hence FPC must be converted to
LOC.

Estimation Techniques
Estimation is the process of finding an estimate, or approximation, which is a value that can be used
for some purpose even if input data may be incomplete, uncertain, or unstable.
Estimation determines how much money, effort, resources, and time it will take to build a specific
system or product. Estimation is based on −

 Past Data/Past Experience

 Available Documents/Knowledge
 Assumptions
 Identified Risks
The four basic steps in Software Project Estimation are −

 Estimate the size of the development product.

 Estimate the effort in person-months or person-hours.
 Estimate the schedule in calendar months.
 Estimate the project cost in agreed currency.

Observations on Estimation

 Estimation need not be a one-time task in a project. It can take place during −
o Acquiring a Project.
o Planning the Project.
o Execution of the Project as the need arises.

6
  Project scope must be understood before the estimation process begins. It will be helpful to
have historical Project Data.
 Project metrics can provide a historical perspective and valuable input for generation of
quantitative estimates.
 Planning requires technical managers and the software team to make an initial commitment as
it leads to responsibility and accountability.
 Past experience can aid greatly.
 Use at least two estimation techniques to arrive at the estimates and reconcile the resulting
values. Refer Decomposition Techniques in the next section to learn about reconciling
estimates.
 Plans should be iterative and allow adjustments as time passes and more details are known.

General Project Estimation Approach

The Project Estimation Approach that is widely used is Decomposition Technique. Decomposition
techniques take a divide and conquer approach. Size, Effort and Cost estimation are performed in a
stepwise manner by breaking down a Project into major Functions or related Software Engineering
Activities.
Step 1 − Understand the scope of the software to be built.
Step 2 − Generate an estimate of the software size.
 Start with the statement of scope.
 Decompose the software into functions that can each be estimated individually.
 Calculate the size of each function.
 Derive effort and cost estimates by applying the size values to your baseline productivity
metrics.
 Combine function estimates to produce an overall estimate for the entire project.
Step 3 − Generate an estimate of the effort and cost. You can arrive at the effort and cost estimates by
breaking down a project into related software engineering activities.
 Identify the sequence of activities that need to be performed for the project to be completed.
 Divide activities into tasks that can be measured.
 Estimate the effort (in person hours/days) required to complete each task.
 Combine effort estimates of tasks of activity to produce an estimate for the activity.
 Obtain cost units (i.e., cost/unit effort) for each activity from the database.
 Compute the total effort and cost for each activity.
 Combine effort and cost estimates for each activity to produce an overall effort and cost
estimate for the entire project.
Step 4 − Reconcile estimates: Compare the resulting values from Step 3 to those obtained from Step
2. If both sets of estimates agree, then your numbers are highly reliable. Otherwise, if widely
divergent estimates occur conduct further investigation concerning whether −
 The scope of the project is not adequately understood or has been misinterpreted.
 The function and/or activity breakdown is not accurate.
 Historical data used for the estimation techniques is inappropriate for the application, or
obsolete, or has been misapplied.
Step 5 − Determine the cause of divergence and then reconcile the estimates.

Estimation Accuracy

Accuracy is an indication of how close something is to reality. Whenever you generate an estimate,
everyone wants to know how close the numbers are to reality. You will want every estimate to be as

7
accurate as possible, given the data you have at the time you generate it. And of course you don’t
want to present an estimate in a way that inspires a false sense of confidence in the numbers.
Important factors that affect the accuracy of estimates are −
 The accuracy of all the estimate’s input data.
 The accuracy of any estimate calculation.
 How closely the historical data or industry data used to calibrate the model matches the
project you are estimating.
 The predictability of your organization’s software development process.
 The stability of both the product requirements and the environment that supports the software
engineering effort.
 Whether or not the actual project was carefully planned, monitored and controlled, and no
major surprises occurred that caused unexpected delays.
Following are some guidelines for achieving reliable estimates −

 Base estimates on similar projects that have already been completed.

 Use relatively simple decomposition techniques to generate project cost and effort estimates.
 Use one or more empirical estimation models for software cost and effort estimation.
Refer to the section on Estimation Guidelines in this chapter.
To ensure accuracy, you are always advised to estimate using at least two techniques and compare the
results.

Estimation Issues

Often, project managers resort to estimating schedules skipping to estimate size. This may be because
of the timelines set by the top management or the marketing team. However, whatever the reason, if
this is done, then at a later stage it would be difficult to estimate the schedules to accommodate the
scope changes.
While estimating, certain assumptions may be made. It is important to note all these assumptions in
the estimation sheet, as some still do not document assumptions in estimation sheets.
Even good estimates have inherent assumptions, risks, and uncertainty, and yet they are often treated
as though they are accurate.
The best way of expressing estimates is as a range of possible outcomes by saying, for example, that
the project will take 5 to 7 months instead of stating it will be complete on a particular date or it will
be complete in a fixed no. of months. Beware of committing to a range that is too narrow as that is
equivalent to committing to a definite date.
 You could also include uncertainty as an accompanying probability value. For example, there
is a 90% probability that the project will complete on or before a definite date.
 Organizations do not collect accurate project data. Since the accuracy of the estimates depend
on the historical data, it would be an issue.
 For any project, there is a shortest possible schedule that will allow you to include the required
functionality and produce quality output. If there is a schedule constraint by management
and/or client, you could negotiate on the scope and functionality to be delivered.
 Agree with the client on handling scope creeps to avoid schedule overruns.
 Failure in accommodating contingency in the final estimate causes issues. For e.g., meetings,
organizational events.
 Resource utilization should be considered as less than 80%. This is because the resources
would be productive only for 80% of their time. If you assign resources at more than 80%
utilization, there is bound to be slippages.

8
Estimation Guidelines

One should keep the following guidelines in mind while estimating a project −
 During estimation, ask other people's experiences. Also, put your own experiences at task.
 Assume resources will be productive for only 80 percent of their time. Hence, during
estimation take the resource utilization as less than 80%.
 Resources working on multiple projects take longer to complete tasks because of the time lost
switching between them.
 Include management time in any estimate.
 Always build in contingency for problem solving, meetings and other unexpected events.
 Allow enough time to do a proper project estimate. Rushed estimates are inaccurate, high-risk
estimates. For large development projects, the estimation step should really be regarded as a
mini project.
 Where possible, use documented data from your organization’s similar past projects. It will
result in the most accurate estimate. If your organization has not kept historical data, now is a
good time to start collecting it.
 Use developer-based estimates, as the estimates prepared by people other than those who will
do the work will be less accurate.
 Use several different people to estimate and use several different estimation techniques.
 Reconcile the estimates. Observe the convergence or spread among the estimates.
Convergence means that you have got a good estimate. Wideband-Delphi technique can be
used to gather and discuss estimates using a group of people, the intention being to produce an
accurate, unbiased estimate.
 Re-estimate the project several times throughout its life cycle.
COCOMO Model
Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines of
Code. It is a procedural cost estimate model for software projects and is often used as a process of
reliably predicting the various parameters associated with making a project such as size, effort, cost,
time, and quality. It was proposed by Barry Boehm in 1981 and is based on the study of 63 projects,
which makes it one of the best-documented models. The key parameters which define the quality of
any software products, which are also an outcome of the Cocomo are primarily Effort & Schedule:
 Effort: Amount of labor that will be required to complete a task. It is measured in person-
months units.
 Schedule: Simply means the amount of time required for the completion of the job, which is, of
course, proportional to the effort put in. It is measured in the units of time such as weeks,
months.
Different models of Cocomo have been proposed to predict the cost estimation at different levels,
based on the amount of accuracy and correctness required. All of these models can be applied to a
variety of projects, whose characteristics determine the value of constant to be used in subsequent
calculations. These characteristics pertaining to different system types are mentioned below.
Boehm’s definition of organic, semidetached, and embedded systems:
1. Organic – A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in the past and also the
team members have a nominal experience regarding the problem.
2. Semi-detached – A software project is said to be a Semi-detached type if the vital
characteristics such as team size, experience, knowledge of the various programming
environment lie in between that of organic and Embedded. The projects classified as Semi-
Detached are comparatively less familiar and difficult to develop compared to the organic ones
and require more experience and better guidance and creativity. Eg: Compilers or different
Embedded Systems can be considered of Semi-Detached type.
3. Embedded – A software project requiring the highest level of complexity, creativity, and
experience requirement fall under this category. Such software requires a larger team size than

9
 the other two models and also the developers need to be sufficiently experienced and creative to
develop such complex models.
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model
4. Basic Model –
E = a (KLOC)b
time = c (Effort)d

Personrequired = Effort / time

1. The above formula is used for the cost estimation of for the basic COCOMO
model, and also is used in the subsequent models. The constant values a,b,c and d
for the Basic Model for the different categories of system:
Software Projects a b c d

2.
Organic 4 1.05 2.5 0.38

3.
Semi Detached 0 1.12 2.5 0.35

3.
Embedded 6 1.20 2.5 0.32

The effort is measured in Person-Months and as evident from the formula is

dependent on Kilo-Lines of code. The development time is measured in months.
These formulas are used as such in the Basic Model calculations, as not much
consideration of different factors such as reliability, expertise is taken into account,
henceforth the estimate is rough. Below is the C++ program for Basic COCOMO
1. Intermediate Model – The basic Cocomo model assumes that the effort is only a
function of the number of lines of code and some constants evaluated according to
the different software systems. However, in reality, no system’s effort and schedule
can be solely calculated on the basis of Lines of Code. For that, various other factors
such as reliability, experience, Capability. These factors are known as Cost Drivers
and the Intermediate Model utilizes 15 such drivers for cost estimation.
Classification of Cost Drivers and their attributes: (i) Product attributes –
 Required software reliability extent
 Size of the application database
 The complexity of the product
 Run-time performance constraints
 Memory constraints
 The volatility of the virtual machine environment
 Required turnabout time
 Analyst capability

10
 Software engineering capability
 Applications experience
 Virtual machine experience
 Programming language experience
 Use of software tools
 Application of software engineering methods
 Required development schedule
2. Detailed Model – Detailed COCOMO incorporates all characteristics of the
intermediate version with an assessment of the cost driver’s impact on each step of
the software engineering process. The detailed model uses different effort multipliers
for each cost driver attribute. In detailed cocomo, the whole software is divided into
different modules and then we apply COCOMO in different modules to estimate
effort and then sum the effort. The Six phases of detailed COCOMO are:
1. Planning and requirements
2. System design
3. Detailed design
4. Module code and test
5. Integration and test
6. Cost Constructive model
Work Breakdown Structure
A Work Breakdown Structure includes dividing a large and complex project into simpler,
manageable and independent tasks. The root of this tree (structure) is labelled by the Project name
itself. For constructing a work breakdown structure, each node is recursively decomposed into
smaller sub-activities, until at the leaf level, the activities becomes undividable and independent. It
follows a Top-Down approach.
Steps:
 Step-1: Identify the major activities of the project.
 Step-2: Identify the sub-activities of the major activities.
 Step-3: Repeat till undividable, simple and independent activities are created.

Construction of Work Breakdown Structure:

Firstly, the project managers and top level management identifies the main deliverables of the
project. After this important step, these main deliverables are broke down into smaller higher-level

11
tasks and this complete process is done recursively to produce much smaller independent tasks. It
depends on the project manager and team that upto which level of detail they want to break down
their project.
Generally the lowest level tasks are the most simplest and independent tasks and takes less than two
weeks’ worth of work. Hence, there is no rule for up to which level we may build the work
breakdown structure of the project as it totally depends upon the type of project we are working on
and the management of the company. The efficiency and success of the whole project majorly
depends on the quality of the Work Breakdown Structure of the project and hence, it implies its
importance.
Uses:
 It allows to do a precise cost estimation of each activity.
 It allows to estimate the time that each activity will take more precisely.
 It allows easy management of the project.
 It helps in proper organisation of the project by the top management.
Activity Network in Software Engineering

Activity Network:
An activity network shows the different activities making up a project, their estimated
durations, and their interdependencies.

Activity on Node (AON):

In this representation, each activity is represented by a rectangular (some use circular) node and the
duration of the activity is shown alongside each task in the node.

Activity on Edge (AOE):

In this representation tasks are associated with the edges. The edges are also annotated with the task
duration. The nodes in the graph represent project milestones. Activity networks were originally
represented using activity on edge (AOE) representation.

What is the Critical Path Method in Project Management?

Critical Path Method (CPM):

12
A path in the activity network graph is any set of consecutive nodes and edges in this graph from the
starting node to the last node. A critical path consists of a set of dependent tasks that need to be
performed in a sequence and which together take the longest time to complete.
A critical task is one with zero slack time. A path from the start node to the finish node containing
only critical tasks is called a critical path. CPM is an algorithmic approach to determine the critical
paths and slack times for tasks.

Quantities of Critical Path Method (CPM):

Minimum time (MT): It is the minimum time required to complete the project. It is computed by
determining the maximum of all paths from start to finish.
Earliest start (ES): It is the time of a task is the maximum of all paths from the start to this task. The
ES for a task is the ES of the previous task plus the duration of the preceding task.
Latest start time (LST): It is the difference between MT and the maximum of all paths from this task
to the finish. The LST can be computed by subtracting the duration of the subsequent task from the
LST of the subsequent task.
Earliest finish time (EF): The EF for a task is the sum of the earliest start time of the task and the
duration of the task.
Latest finish (LF): LF indicates the latest time by which a task can finish without affecting the
completion time of the project. A task completed beyond its LF would cause a project delay. LF of a
task can be obtained by subtracting the maximum of all paths from this task to finish from MT.
Slack time (ST): The slack time (or float time) is the total time that a task may be delayed before it
will affect the end time of the project. The slack time indicates the ”flexibility” in the starting and
completion of tasks. ST for a task is LS-ES and can equivalently be written as LF-EF

What is Project Evaluation Review Technique (PERT)?

A PERT chart is a network diagram that allows project managers to create project schedules. They’re
used in the Program Evaluation Review Technique (PERT) to represent a project timeline, estimate
the duration of tasks, identify task dependencies and find the critical path of a project.

PERT charts are used by project managers to create realistic schedules by coordinating tasks and
estimating their duration by assigning three time estimates for each; optimistic, most likely and
pessimistic. This makes PERT charts useful when planning projects where the duration of activities is
uncertain.

When Should I Use a PERT Chart?

Use PERT charts during the planning phase of a project. They can help you determine the project’s
critical path and the ideal time to start or finish tasks, which allows you to know which tasks need to
be prioritized when creating your project schedule.

As noted, PERT charts show the dependent tasks in your project. These are tasks that can’t start or
finish until another task starts or finishes. Knowing which tasks are dependent helps you prevent
delays by planning ahead to make sure these dependent tasks are scheduled in the order they need to
be completed.

Also, when planning a project, having an accurate forecast of its duration is crucial for resource
scheduling. The PERT chart is a tool that can help you estimate the amount of time you’ll need to
complete the project. It’s also very helpful when you’re working on more complex or larger projects.

13
How Does a PERT Chart Work?

A PERT chart is made up of nodes and directional arrows. Nodes are numbered boxes or circles. They
represent an event or milestone in the project. The arrows are the tasks or activities that must be done
before moving on to the next event or milestone.

Therefore, a PERT chart works by visualizing the project’s tasks and dependencies. This provides an
overview of the project timeline, including which tasks are essential to complete to deliver a
successful project. With this information, project managers can develop a viable project plan that
meets deadlines and stays within budget.

How to Make a PERT Chart in 4 Steps

Creating a PERT chart shouldn’t be an overwhelming process, even if you decide to draw your PERT
diagram and do the calculations yourself. Here are some simple steps to create a PERT chart:

1. Break down Your Project Scope

Begin by identifying the project milestones and then identify the individual tasks required to achieve
them. Then, figure out the sequence of your project tasks and their dependencies.
You should have a list of milestones, tasks and their dependencies. You’ll need these elements to
create your PERT chart, either manually or using project management software.

2. Create Your PERT Chart

Now that you have the information that you need, you can now make the PERT diagram—we’ll show
you a PERT chart example in the section below!
During this phase, you’ll need to sequence your tasks using the PERT diagram and estimate the time
required to complete each task.

3. Estimate Your Project Duration

Now that you have drafted a PERT diagram and added task details, it’s time to add the estimated
durations of all tasks to create a project schedule. If you’re drawing your PERT diagram, you’ll use
the PERT chart formula to do so.
If you use ProjectManager’s Gantt chart, you’ll automatically create an interactive project schedule
that lets you identify task dependencies, set due dates, estimate your project duration, find the critical
path and much more.

4. Find the Critical Path & Slack

Once you have a PERT chart that has your project tasks, their durations and due dates, you can
calculate the critical path and identify any possible slack. At last, you have your PERT chart!
Remember, this project management chart is a living document that must be returned to and revised as
the project progresses

.PERT Chart Example

14
Let’s move these concepts from abstraction to reality. To better understand the power of a PERT chart
in
project management, let’s make one together. For our PERT chart example, we’ll create a project
around building a website. The PERT chart will allow us to visualize our project’s activities and
milestones to quickly uncover the critical path.

To begin our PERT example, we’re going to identify all the activities that make up the project and
determine the immediate predecessors for each. We’ll list them as shown in the table below.

Next, we figure out how long all the activities will take. The amount of time you estimate with the
PERT chart formula should be added to the arrows as shown in our PERT chart example. We used
weeks as our time unit, but it could be days or months, depending on your project.

Once we have a time estimate for each task, we can draw our PERT diagram. We start with the first
node which is the “kick-off meeting” in our example. Then we represent the initial activities with
arrows and connect them to their corresponding milestone nodes. We continue the process until we
get to the final milestone node of our project.

15
Pro tip: A PERT chart is a great way to help you estimate simply and more accurately. Estimates can
be overly optimistic or pessimistic, but using a PERT chart will find the most realistic estimate.

To implement a PERT chart:

 Identify the different tasks needed to complete a project. Make sure to add these in the right
order and indicate the duration of each task.
 Create a network diagram. Use arrows to represent the activities and use nodes as milestones.
 Determine the critical path and possible slack.

Advantages of PERT

Here are several benefits of using PERT in project management:

1. It helps maximize the use of resources.

2. It makes project planning more manageable.
3. It’s useful even if there is little or no previous schedule data.
4. It enables project managers to better estimate or determine a more definite completion date.

Disadvantages of PERT

Like any other method, PERT comes with its share of limitations:

1. In complex projects, many find PERT hard to interpret, so they may also use a Gantt Chart,
another popular method for project management.
2. It can be tedious to update, modify, and maintain the PERT diagram.
3. It entails a subjective time analysis of activities and, for those who are less experienced or are
biased, this may affect the project’s schedule.

16
What Is a Gantt Chart?
A Gantt chart is a commonly used graphical depiction of a project schedule. It's a type of bar chart
showing the start and finish dates of a project's elements such as resources, planning, and
dependencies.

Henry Gantt (1861-1919), an American mechanical engineer, designed the Gantt chart.1

KEY TAKEAWAYS

 A Gantt chart is a visualization that helps in scheduling, managing, and monitoring specific
tasks and resources in a project.
 It consists of a list of tasks and bars depicting each task's progress.
 The horizontal bars of different lengths represent the project timeline, which can include task
sequences, duration, and the start and end dates for each task
 It's the most widely used chart in project management.
 Gantt charts are used in heavy industries for projects like building dams, bridges, and
highways, as well as software development and building out of other goods and services.

Understanding Gantt Charts

The Gantt chart is the most widely used chart in project management. These charts are useful in
planning a project and defining the sequence of tasks that require completion. In most instances, the
chart is displayed as a horizontal bar chart.

Horizontal bars of different lengths represent the project timeline, which can include task sequences,
duration, and the start and end dates for each task. The horizontal bar also shows how much of a task
requires completion.

The length of the bar is proportional to the time necessary for a task’s completion. The project tasks
are represented on the vertical axis.

A Gantt chart helps in scheduling, managing, and monitoring specific tasks and resources in a
project. The chart shows the project timeline, which includes scheduled and completed work over a
period. The Gantt chart aids project managers in communicating project status or plans and also
helps ensure the project remains on track.

Benefits of a Gantt Chart

The chart identifies tasks that may be executed in parallel and those that can't be started or finished
until others are complete. It can help detect potential bottlenecks and identify tasks that may have
been excluded from the project timeline.

The chart depicts things like task slack time or additional time for completion of a task that shouldn't
delay the project; noncritical activities that may be delayed; and critical activities that must be
executed on time.

Gantt charts can be used in managing projects of all sizes and types. These may include
building infrastructures like dams, bridges, and highways. They may also include software
development and other technologies. Project management tools, such as Microsoft Visio, Project,
SharePoint, and Excel, or specialized software, such as Gantto or Matchware, can help in designing
Gantt charts.

17
Example of a Gantt Chart
Company A is taking on a project to install new software on the servers of a large investment bank.
Company A decides to create a Gantt chart to help manage the project and its different components.

The project's tasks that require completion include conducting research, selecting a software product,
testing the software, and installing it. These tasks appear as vertical lines on the Gantt chart. A
milestone of the project is selecting the software.

The project's duration is 40 days as agreed upon between Company A and the investment bank. Each
task takes 10 days to complete, and each task is dependent on the previous task. A critical activity is
testing the software in the development and test environments.

The task start and end dates, duration, and milestones appear as horizontal bars on the Gantt chart.
The percentage of work completed for each task also is displayed on the horizontal bars. Using the
Gantt chart will help Company A map out the tasks along a timeline to reach full completion in 40
days.

What Are Gantt Charts Used for?

Gantt charts help visualize various tasks and projects that occur simultaneously within an
organization, and how far along they have progressed. They are used by management to plan and
schedule such projects so that resources can be allocated in an optimal way and that projects that are
prioritized can finish before less important ones begin.

Who Was Henry Gantt?

Henry Gantt was a social scientist and management consultant who also held a degree in mechanical
engineering. He worked in the field of scientific management, developing methods to streamline and
increase the productivity of corporations and their workforce. He created the Gantt chart in the 1910s

18
to help supervisors understand the progress of their labor force and to ensure tasks were on
schedule.1

What Are the Components of a Gantt Chart?

A Gantt chart can vary in complexity and depth, but will always have three key components:
activities or tasks that are to be done, running along the y-axis; milestones or progress stages
indicated along the x-axis (either on the top or bottom of the chart); and progress bars, denoted as
horizontal bars, denoting how far along each task is at any given point.

Requirements Analysis
Requirement analysis is significant and essential activity after elicitation. We analyze, refine, and
scrutinize the gathered requirements to make consistent and unambiguous requirements. This activity
reviews all requirements and may provide a graphical view of the entire system. After the completion
of the analysis, it is expected that the understandability of the project may improve significantly.
Here, we may also use the interaction with the customer to clarify points of confusion and to
understand which requirements are more important than others.

The various steps of requirement analysis are shown in fig:

(i) Draw the context diagram: The context diagram is a simple model that defines the boundaries
and interfaces of the proposed systems with the external world. It identifies the entities outside the
proposed system that interact with the system. The context diagram of student result management
system is given below:

19
(ii) Development of a Prototype (optional): One effective way to find out what the customer wants
is to construct a prototype, something that looks and preferably acts as part of the system they say
they want.

We can use their feedback to modify the prototype until the customer is satisfied continuously. Hence,
the prototype helps the client to visualize the proposed system and increase the understanding of the
requirements. When developers and users are not sure about some of the elements, a prototype may
help both the parties to take a final decision.

Some projects are developed for the general market. In such cases, the prototype should be shown to
some representative sample of the population of potential purchasers. Even though a person who tries
out a prototype may not buy the final system, but their feedback may allow us to make the product
more attractive to others.

The prototype should be built quickly and at a relatively low cost. Hence it will always have
limitations and would not be acceptable in the final system. This is an optional activity.

(iii) Model the requirements: This process usually consists of various graphical representations of
the functions, data entities, external entities, and the relationships between them. The graphical view
may help to find incorrect, inconsistent, missing, and superfluous requirements. Such models include
the Data Flow diagram, Entity-Relationship diagram, Data Dictionaries, State-transition diagrams, etc.

(iv) Finalise the requirements: After modeling the requirements, we will have a better understanding
of the system behavior. The inconsistencies and ambiguities have been identified and corrected. The
flow of data amongst various modules has been analyzed. Elicitation and analyze activities have
provided better insight into the system. Now we finalize the analyzed requirements, and the next step
is to document these requirements in a prescribed format.

Software Requirement Specifications

The production of the requirements stage of the software development process is Software
Requirements Specifications (SRS) (also called a requirements document). This report lays a
foundation for software engineering activities and is constructing when entire requirements are
elicited and analyzed. SRS is a formal report, which acts as a representation of software that enables

20
the customers to review whether it (SRS) is according to their requirements. Also, it comprises user
requirements for a system as well as detailed specifications of the system requirements.

The SRS is a specification for a specific software product, program, or set of applications that perform
particular functions in a specific environment. It serves several goals depending on who is writing it.
First, the SRS could be written by the client of a system. Second, the SRS could be written by a
developer of the system. The two methods create entirely various situations and establish different
purposes for the document altogether. The first case, SRS, is used to define the needs and expectation
of the users. The second case, SRS, is written for various purposes and serves as a contract document
between customer and developer.

Characteristics of good SRS

Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS. SRS
is said to be perfect if it covers all the needs that are truly expected from the system.

2. Completeness: The SRS is complete if, and only if, it includes the following elements:

(1). All essential requirements, whether relating to functionality, performance, design, constraints,
attributes, or external interfaces.

(2). Definition of their responses of the software to all realizable classes of input data in all available
categories of situations.

Note: It is essential to specify the responses to both valid and invalid values.

(3). Full labels and references to all figures, tables, and diagrams in the SRS and definitions of all
terms and units of measure.

21
3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements described
in its conflict. There are three types of possible conflict in the SRS:

(1). The specified characteristics of real-world objects may conflicts. For example,

(a) The format of an output report may be described in one requirement as tabular but in another as
textual.

(b) One condition may state that all lights shall be green while another states that all lights shall be
blue.

(2). There may be a reasonable or temporal conflict between the two specified actions. For example,

(a) One requirement may determine that the program will add two inputs, and another may determine
that the program will multiply them.

(b) One condition may state that "A" must always follow "B," while other requires that "A and B" co-
occurs.

(3). Two or more requirements may define the same real-world object but use different terms for that
object. For example, a program's request for user input may be called a "prompt" in one requirement's
and a "cue" in another. The use of standard terminology and descriptions promotes consistency.

4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted. In case there is a method used
with multiple definitions, the requirements report should determine the implications in the SRS so that
it is clear and simple to understand.

5. Ranking for importance and stability: The SRS is ranked for importance and stability if each
requirement in it has an identifier to indicate either the significance or stability of that particular
requirement.

Typically, all requirements are not equally important. Some prerequisites may be essential, especially
for life-critical applications, while others may be desirable. Each element should be identified to make
these differences clear and explicit. Another way to rank requirements is to distinguish classes of
items as essential, conditional, and optional.

6. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly obtain
changes to the system to some extent. Modifications should be perfectly indexed and cross-
referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-effective
system to check whether the final software meets those requirements. The requirements are verified
with the help of reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it
facilitates the referencing of each condition in future development or enhancement documentation.

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement explicitly referencing its source in
earlier documents.

22
2. Forward Traceability: This depends upon each element in the SRS having a unique name or
reference number.

The forward traceability of the SRS is especially crucial when the software product enters the
operation and maintenance phase. As code and design document is modified, it is necessary to be able
to ascertain the complete set of requirements that may be concerned by those modifications.

9. Design Independence: There should be an option to select from multiple design alternatives for
the final system. More specifically, the SRS should not contain any implementation details.

10. Testability: An SRS should be written in such a method that it is simple to generate test cases and
test plans from the report.

11. Understandable by the customer: An end user may be an expert in his/her explicit domain but
might not be trained in computer science. Hence, the purpose of formal notations and symbols should
be avoided too as much extent as possible. The language should be kept simple and clear.

23