Software

Engineering
Module 3
Project Scheduling and Tracking
 Project Schedule
• Tracking
Project Planning is an important activity performed by Project Managers.
• Project Managers can use the tools and techniques to develop, monitor, and
control project timelines and schedules.
• The tracking tools can automatically produce a pictorial representation of the
project plan.
• These tools also instantly update time plans as soon as new information is entered
and produce automatic reports to control the project.
• Scheduling tools also look into Task breakdown and Risk management also with
greater accuracy and ease of monitoring the reports.
• It also provides a good GUI to effectively communicate with the stakeholders of
the project.
 Features of Project Scheduling
• TimeTools
management: The project scheduling tools keep projects running the
way it is planned. There will be proper time management and
better scheduling of the tasks.

• Resource allocation: It provides the resources required for project

development. There will be proper resource allocation and it helps to
make sure that proper permissions are given to different individuals
involved in the project. It helps to monitor and control all resources
in the project.

• Team collaboration: The project scheduling tool improves team

collaboration and communication. It helps to make it easy to comment
and chat within the platform without relying on external software.

• User-friendly interface: Good project scheduling tools are designed to be

more user-friendly to enable teams to complete projects in a better
and more efficient way.
 Software Project Estimation
• Software project estimation approaches assist project managers in effectively estimating
critical project parameters such as cost and scope.

• PMs can then use these estimation strategies to give clients more accurate projections as
well as budget the funds and resources they’ll require for a project’s success.

• project estimation is a complex process that revolved around predicting the time, cost,
and scope that a project requires to be deemed finished.

• But in terms of software development or software engineering, it also takes the

experience of the software outsourcing company, the technique they have to utilize, the
process they need to follow in order to finish the project (Software Development Life
Cycle).

• Project Estimation requires the use of complex tools & good mathematical as well as
knowledge about planning.

• In most cases, the whole estimation process would cost the company rather considerable
cost & time at the very first stage of developing a brand new website, app, or software.
However, this will act as the stepping stone to make the final result more credible,
realistic, and customer-satisfying.

• Whether big or small, every project is advised to employ project estimation as a crucial
step to avoid unpredictable failure in the future.
 Estimations Take Place During A
• Project
There are six critical elements of a project that benefit from the use of project
estimating techniques.
• 1)Cost,2) Time,3) Size Or Scope,4) Risk,5) Resources,6) Quality

1) Cost:
• In project management, cost is one of the three primary constraints.
• The project will fail if you do not have sufficient funds to complete it.
• You can help set client expectations and ensure you have enough money to
complete
the work if you can accurately estimate project costs early on.
• Estimating costs entails determining how much money you’ll need and
when you’ll
need it.

2)Time:
• Another of the project’s three main constraints is the lack of time. It is critical for
project planning to be able to estimate both the overall project duration and the timing
of individual tasks.
• You can plan for people and resources to be available when you need them if you
estimate your project schedule ahead of time. It also enables you to manage
client expectations for key deliverables.
3) Size Or Scope:
• The third major project constraint is scope.
• The project scope refers to all of the tasks that must be completed in order to
complete the project or deliver a product.
• You can ensure that you have the right materials and expertise on the project by
estimating how much work is involved and exactly what tasks must be completed.
• Three sides of a triangle are often used to describe the three main constraints.
• This is because any changes to one constraint will inevitably have an effect on the
other two.
• You need to know the scope and schedule to accurately estimate the budget. If one
of the three estimates turns out to be higher or lower than you anticipated, the
other two are likely to be off as well.
4)
•
Risk:
Any unforeseen event that could positively or negatively impact your project is
referred to as project risk.
• Estimating risk entails predicting what events will occur during the project’s
life cycle and how serious they will be.
• You can better plan for potential issues and create risk management plans if you
estimate what risks could affect your project and how they will affect it.
5) Resources:
• The assets you’ll need to complete the project are known as
project
resources.
• Tools, people, materials, subcontractors, software, and other resources are
all examples of resources. Resource management ensures that you
have all of the resources you require and make the best use of them.
• It’s challenging to plan how you’ll manage resources without knowing
what you’ll need and when.
• This can result in people sitting around doing nothing or materials arriving
weeks after you need them.
 6) Quality:

• Quality is concerned with the completion of project deliverables.

• Products that must adhere to stringent quality standards, such as
environmental regulations, may require more money, time, and
other resources than those with lower standards.
• Estimating the level of quality required by the customer aids in the
planning and estimating the remaining five aspects of your project.
• Because all six project factors are interconnected, forecasts for one can
have an impact on forecasts for the other five.
 Software Project
Estimation
1. Lines of Code (LOC)
• The line of code (LOC) metric is any line of text in a code that is not a
comment or blank line, in any case of the number of statements or
fragments of statements on the line.
• LOC consists of all lines containing program header files, declaration of
any variable, and executable and non-executable statements.
• As Lines of Code (LOC) only counts the proportion of code, you can only
utilize it to compare or estimate projects that utilize the same language and
are programmed using the same coding standards.
 1. Lines of Code (LOC)
• Example of Line of Code :
So, now If LOC is simply a count of the number
of lines then the above function shown
contains 13 lines of code (LOC).

void selSort(int x[], int n) {

But when comments and blank lines are
//Below function sorts an in ignored, the function shown above contains 12
array
ascending order
lines of code (LOC).
int (i
for i, =
j,0;
min,
< ntemp;
- 1; i++)
i min = {
i; for (j + 1; j < n; j+
= i if +)
(x[j] < x[min])
min
temp==j;x[i];
x[i] =
x[min];
x[min] =
temp;
}
}
 Software Project
Estimation
• 2. Function Point (FP) :

• Function Point Analysis was initially developed by Allan J. Albrecht in

1979 at IBM and has been further modified by the International
Function Point User’s Group (IFPUG). Allan J. Albrecht gave
the initial definition.
• Functional Point Analysis gives a dimensionless number defined in
function points which we have found to be an effective relative
measure of function value delivered to our customer.
 Objectives of Functional Point
1. Analysis:
Encourage Approximation: FPA helps in the estimation of the work,
time and materials needed to develop a software project. Organizations
are
able to plan and manage projects more accurately when a common
2. measure
of functionality is available.
To assist with project management: Project managers can monitor and
manage software development projects with the help of FPA. Managers
are able to evaluate productivity, monitor progress, and make well-
3. informed decisions about resource allocation and project timeframes by
measuring the software’s functional points.
Comparative analysis: By enabling benchmarking, it gives businesses
the ability to assess how their software projects measure up to industry
standards or best practices in terms of size and complexity. This can be
4. useful for determining where improvements might be made and for
evaluating how well development procedures are working.
Improve Your Cost-Benefit Analysis: It offers a foundation for assessing
the value provided by the program in respect to its size and complexity,
which helps with cost-benefit analysis. Making educated judgements about
5. project investments and resource allocations can benefit from having
access to this information.
Comply with Business Objectives: It assists in coordinating software
development activities with an organization’s business objectives. It
 Types of Functional Point Analysis:
• There are two types of Functional Point Analysis:

1. Transactional Functional Type

• External Input (EI): EI processes data or control information that comes
from outside the application’s boundary. The EI is an elementary process.
• External Output (EO): EO is an elementary process that generates data
or
control information sent outside the application’s boundary.
• External Inquiries (EQ): EQ is an elementary process made up of an
input-output combination that results in data retrieval.

2. Data Functional Type

• Internal Logical File (ILF): A user-identifiable group of logically
related data or control information maintained within the boundary of the
application.
• External Interface File (EIF): A group of users recognizable logically
related data allusion to the software but maintained within the boundary
of another software.
2. Function Point (FP) :
Characteristics of Functional Point
Analysis:
• We calculate the functional point with the help of the number of
functions and types of functions used in applications. These are classified
into five types:

Measurement Parameters Examples

Number of External Inputs (EI) Input screen and tables

Number of External Output (EO) Output screens and reports

Number of external inquiries (EQ) Prompts and interrupts

Number of internal files (ILF) Databases and directories

Number of external interfaces Shared databases and shared

(EIF) routines
2. Function Point
• In the function point metric, the number and type of functions held up by the software are
(FP)
used :to find FPC (function point count).
• Example of function point :Calculation of Function Point (FP)
• Function Point (FP) is an element of software development which helps to approximate
the cost of development early in the process. It may measures functionality from user’s
point of view. Counting Function Point (FP):

• Step-1:F = 14 * scale

• Scale varies from 0 to 5 according to character of Complexity Adjustment Factor (CAF).

Below table shows scale:
1 - No Influence
2 - Incidental
3 - Moderate
4 - Average
5 - Significant
6 - Essential

• Step-2: Calculate Complexity Adjustment Factor (CAF).

CAF = 0.65 + ( 0.01 * F )
• Step-3: Calculate Unadjusted Function Point (UFP). TABLE (Required)
Function Units Low Avg High
EI 3 4 6

EO 4 5 7

EQ 3 4 6

ILF 7 10 15

EIF 5 7 10

Multiply each individual function point to corresponding values in TABLE.

• Step-4: Calculate Function Point.

FP = UFP * CAF
 • Example: Given the following values, compute function point when
all
complexity adjustment factor (CAF) and weighting factors are average.

User Input = 50, User Output = 40, User Inquiries = 35 ,User Files = 6
,External Interface = 4.
Ans:Explanation:
Step-1: As complexity adjustment factor is average (given in question),
hence,
scale = 3.
F = 14 * 3 = 42
Step-2:CAF = 0.65 + ( 0.01 * 42 ) = 1.07
Step-3: As weighting factors are also average (given in question) hence
we will multiply each individual function point to corresponding values in
[Link] = (50*4) + (40*5) + (35*4) + (6*10) + (4*7) = 628
Step-4:Function Point = 628 * 1.07 = 671.96
This is the required answer.
Ex.1 "Given the Following Values, calculate the Functional Point
when complexity adjustment factors are significantly complex product
and weighting factors are high.
• User input = 55
• User Output = 35
• User Enquires = 40
• User Files = 8
• External Interfaces = 5"
 2. Function Point (FP) :
• Both function point and LOC are measurement units for the size of the
software.
• The size of the software that is dependent on development is necessary to
come up with accurate estimates of the effort, cost, and duration
of a project.

• Most parametric estimation models such as the Constructive Cost Model

(COCOMO) accept size conveyed in either FP or LOC as an input.
Difference between LOC and Function
Point :
Function Point (FP) Line of Code (LOC)

Function Point metric is specification-

LOC metric is based on analogy.
based.

Function Point metric is language

LOC metric is dependent on language.
independent.

Function Point metric is user-oriented. LOC metric is design-oriented.

Function Point metric is extendible to Line

It is changeable to FP (i.e. backfiring)
of Code.

Function Point is used for data processing LOC is used for calculating the size of the
systems computer program

Function Point can be used to portray the LOC is used for calculating and comparing
project time the productivity of programmers.
Software Project Scheduling
Principles
• Software project scheduling can be defined as an activity that distributes
the estimated effort across the planned project duration by allocating
the effort to specific software engineering tasks. Simply one can
say that project schedule is a tool which communicates
1. What works has to be performed.
2. Who will perform the work.
3. Time duration within which that work needs to be completed.
 There are seven principles of software project
scheduling :
COMPARTMENTALIZATION :
• A given software project is compartmentalized into a number of manageable activities. The project
is divided into a number of small tasks.
INTERDEPENDENCY :
• Interdependent tasks are accomplished first. Certain tasks occur in sequence whereas other tasks
occur in parallel. Therefore tasks which occur in sequence has to be performed in a sequential order
since the output of one task will be the input of the next task. Other tasks can occur independently.
TIME ALLOCATION :
• Each and every task has to be assigned a specific time period i.e a start date and a completion
date based on whether the work will be performed in a full time or part time basis.
EFFORT VALIDATION :
• Every project is assigned to a software team. The project manager has to make sure that the effort
allocated should not be more than the number of people available to do the work.
DEFINED RESPONSIBILITIES :
• Each of the scheduled task is assigned to a specific member of the software team.
DEFINED OUTCOMES :
• Each task has a defined outcome. Work product is the outcome of a software project.
DEFINED MILESTONES :
• Every task is associated with a milestone. A milestone is an action or event marking a significant
change in development process.
Empirical Estimation Models - COCOMO,
COCOMO II Model
COCOMO Model
• Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e.,
the number of Lines of Code.
• The Cocomo Model 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 that define the quality of any software products, which are
also an outcome of the Cocomo are primarily Effort and schedule:
1) Effort: Amount of labor that will be required to complete a task. It is measured
in person-months units.
2) Schedule: This 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, and months.
 Types of COCOMO Model
1. Basic Model
• E = a(KLOC)^b
• Time = c(Effort)^d
• Person required = Effort/ time
• The above formula is used for the cost estimation of 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 the system:

Software
a b c d
Projects

Organic 2.4 1.05 2.5 0.38

Semi-
3.0 1.12 2.5 0.35
Detached

Embedded 3.6 1.20 2.5 0.32

 1. Basic Model
• 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, and
expertise is taken into account, henceforth the estimate is rough.
2. 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 based on
Lines of Code. For that, various other factors such as reliability, experience, and
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:
• 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
• Software engineering capability
• Application experience
• Virtual machine experience
• Programming language experience
• Use of software tools
• Application of software engineering methods
• Required development schedule
3. 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:
• Planning and requirements
• System design
• Detailed design
• Module code and test
• Integration and test
• Cost Constructive model
 Stages of COCOMO Model
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, and knowledge of the
various programming environments lie in between 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 better guidance and creativity.
Eg: Compilers or different Embedded Systems can be considered
Semi-Detached types.
3. Embedded
• A software project requiring the highest level of complexity, creativity, and
experience requirement falls under this category. Such software
requires a larger team size than the other two models and also the
developers need to be sufficiently experienced and creative to
develop such complex models.
 COCOMO-II
• COCOMO-II is the revised version of the original Cocomo (Constructive
Cost Model) and was developed at the University of Southern California. It
is the model that allows one to estimate the cost, effort, and schedule
when planning a new software development activity.
• Stages of COCOMO II
 COCOMO-II
1. Stage-I
• It supports estimation of prototyping. For this it uses Application
Composition Estimation Model. This model is used for the
prototyping stage of application generator and system integration.

2. Stage-II
• It supports estimation in the early design stage of the project, when
we less know about it. For this it uses Early Design Estimation
Model. This model is used in early design stage of application
generators, infrastructure, system integration.

3. Stage-III
• It supports estimation in the post architecture stage of a project. For
this it uses Post Architecture Estimation Model. This model is used
after the completion of the detailed architecture of application
generator, infrastructure, system integration.
 COCOMO I COCOMO II

COCOMO I is useful in the waterfall models of the software COCOMO II is useful in non-sequential, rapid development
development cycle. and reuse models of software.

It provides estimates that represent one standard deviation

It provides estimates of effort and schedule. around the most likely estimate.

This model is based upon the linear reuse formula. This model is based upon the non linear reuse formula

This model is also based upon the assumption of This model is also based upon reuse model which looks at
reasonably stable requirements. effort needed to understand and estimate.

Effort equation’s exponent is determined by 3 development

modes. Effort equation’s exponent is determined by 5 scale factors.

Development begins with the requirements assigned to the

software. It follows a spiral type of development.

Number of submodels in COCOMO I is 3 and 15 cost drivers In COCOMO II, Number of submodel are 4 and 17 cost
are assigned drivers are assigned

Size of software stated in terms of Object points, function

Size of software stated in terms of Lines of code points and lines of code
Estimation for agile: planning poker, user story
planning
• Estimation is the process of finding an estimate, or approximation.
• It is an Art of guessing.
• Estimation includes four main factors – money, effort, resources, and time
needed to build a specific system or product.
• There are many techniques available in today’s world for doing estimations
in an Agile Project.
• The main objectives for doing estimations include Relative Estimation,
discussions to get more information on items whose estimations need to
be done and ensuring the commitment and enthusiasm of the whole
team towards the tasks assigned to them.
 Agile Project Estimation Techniques
are:
1. Planning Poker:
• Planning Poker is the most famous Estimation technique in Agile.
• This technique makes sure that every member participates in the estimation and
shares his/her opinion.
• In this technique cards with numbers on them, are given to each member of the
team. The Product Owner reads the story, after which every member has to
hold the card showing the level of effort they will make for the user story.
• Discussion and Re-estimation go on until the whole team reaches a consensus.
• Planning Poker, also called “Scrum Poker,” is a consensus-based Agile planning
and estimating technique used to assess product backlogs, guessing how
much time and effort is needed to complete each of the backlog's initiatives.
• It's called “Poker” because everyone uses physical cards that resemble playing
cards.
 Planning Poker Estimation
Technique
In Planning Poker Estimation Technique, estimates for the user stories are derived by playing
planning poker. The entire Scrum team is involved and it results in quick but reliable estimates.
• Planning Poker is played with a deck of cards. As Fibonacci sequence is used, the cards have
numbers - 1, 2, 3, 5, 8, 13, 21, 34, etc. These numbers represent the “Story Points”. Each
estimator has a deck of cards. The numbers on the cards should be large enough to be visible to
all the team members, when one of the team members holds up a card.
• One of the team members is selected as the Moderator. The moderator reads the description of
the user story for which estimation is being made. If the estimators have any questions, product
owner answers them.
• Each estimator privately selects a card representing his or her estimate. Cards are not shown
until all the estimators have made a selection. At that time, all cards are simultaneously turned
over and held up so that all team members can see each estimate.
• In the first round, it is very likely that the estimations vary. The high and low estimators explain
the reason for their estimates. Care should be taken that all the discussions are meant for
understanding only and nothing is to be taken personally. The moderator has to ensure the same.
• The team can discuss the story and their estimates for a few more minutes.
• The moderator can take notes on the discussion that will be helpful when the specific story is
developed. After the discussion, each estimator re-estimates by again selecting a card. Cards are
once again kept private until everyone has estimated, at which point they are turned over at the
same time.
Repeat the process till the estimates converge to a single estimate that can be used for the story. The
number of rounds of estimation may vary from one user story to another.
 User Stories in Agile
• User stories are a key component of agile software development.
• They are short, simple descriptions of a feature or functionality from the
perspective of a user.
• User stories are used to capture requirements in an agile project and help
the development team understand the needs and expectations of the users.
some key characteristics of user stories:
1. User-centric: User stories focus on the needs of the user and what they
want to achieve with the software.
2. Simple: User stories are short and simple descriptions of a feature or
functionality.
3. Independent: User stories can stand on their own and do not rely on
other
user stories.
4. Negotiable: User stories are open to discussion and can be refined and
modified based on feedback from stakeholders.
5. Valuable: User stories provide value to the user and the business.
 some key characteristics of user
stories:
6. Estimable: User stories can be estimated in terms of time and effort required for implementation.

7. Testable: User stories can be tested to ensure they meet the needs of the user.

8. Prioritized: User stories are prioritized based on their importance to the user and the business goals.

[Link]: User stories are developed iteratively, allowing for feedback and changes throughout
the development process.

10. Consistent: User stories follow a consistent format, making them easy to understand and work
with.

11. Contextual: User stories are written in a way that provides context to the development team,
helping
them understand the user’s needs and goals.

12. Acceptance criteria: User stories have clear and specific acceptance criteria that define when
the story
is considered “done” and ready for release.

13. Role-based: User stories are written from the perspective of a specific user role, helping to
ensure that
the development team is building features that are relevant and useful to that user.
 Pattern of User Story:
• User stories are completely from the end-user perspective which follows
the Role-Feature-Benefi
• As a [ type of user ], I want [ an action ], so that [ some reason ]t pattern.
• For example :
As the project manager of a construction team, I want our team-
messaging app to include file sharing and information update so that my
team can collaborate and communicate with each other in real-time as a
result the construction project development and completion will be fast.
Writing User Stories :
User stories are from a user perspective. So when user stories are written,
users are given more importance during the process. Some points outlined
which are taken into consideration during writing user stories like
• Requirements
• Tasks and their subtasks
• Actual user
• Importance to user words/feedback
• Breaking user stories for larger requirements
 Agile Project Estimation Techniques
1. are:
Large/Uncertain/Small: This technique is for doing rough estimation
and it is simpler than the Bucket system technique. All the
items are categorized in Large/Uncertain/Small. First simple user
stories are chosen for estimation then more complex ones are
taken. It’s a good technique when comparable items are in the
Product Backlog.
2. Relative Estimation: In this technique, teams estimate user stories
according to one another rather than giving them exact numerical
values. For instance, they can state, without assigning specific point
values, that Story X is twice as complex as Story Y. This method
prioritizes selection and ranking while simplifying estimation.
3. Story Points: In this estimation technique, user stories are given story
points based on complexities, effort, and risk by teams. Story points
are a metric without units and can stand in for any comparable
value decided by the team. This method is adaptable and
frequently used alongside Planning Poker.
4. Estimation Based on Velocity: This technique states the amount of work
a team can accomplish in a sprint is measured by the team’s
velocity. Teams calculate the amount of user story points that
can commit to in the following sprint using their average velocity
over several sprints.
 Benefits of Agile
Estimation
Adaptability and Adaptivity
• An Agile approach is most appropriate for a moderately questionable climate. In that sort of climate:
• It is troublesome to precisely characterize the problem and plan for the arrangement exhaustively
from the beginning of the task.
• Flexibility and adaptability are fundamental to additionally characterize and open up the
requirement
and plan of the arrangement as the undertaking is in progress.
Imagination and Innovation
• In the profoundly cutthroat climate that we live in today, nobody needs to purchase normal,
regular items. Individuals expect a more significant level of greatness, and that requires
innovativeness and advancement. An Agile estimation approach underscores inventiveness and
advancement to amplify the business worth of the arrangement. A relative amount of emphasis on
arranging and control will, in general, boost innovativeness and advancement.
Time-to-Market
• An Agile estimation approach ordinarily brings about quicker opportunities to advertise because of
more limited startup times. A steady improvement effort will likewise permit early conveyance of no
less than a portion of the arrangement without the need for the completion of the whole task.
 Benefits of Agile
Lower Costs
Estimation
• An Agile estimation approach can bring down the expenses of a venture severally:
• Significantly diminished overhead coming about because of lessening pointless documentation and
control
necessities
• Higher usefulness of the venture group
• Reduced “include bulge” from utilizing a gradual advancement exertion and focusing on the
requirements. Utilizing that methodology, it will become clear when the project starts to arrive at a state
of unavoidable losses where the steady worth of the highlights no longer surpasses the gradual
improvement cost.

Worked on Quality
• In an Agile estimation project, quality is a fundamental piece of the improvement cycle as opposed to a
successive movement. The engineers realize that quality isn’t “another person’s duty.”
Consumer loyalty
• An Agile estimation approach should bring about higher consumer loyalty and more compelling
arrangements on the grounds that the client is intensely associated with giving criticism and
contributions all through the advancement cycle.
Representative Satisfaction
• An Agile approach should likewise bring about higher representative fulfillment from all
representatives that are occupied with the project since they are considerably more drawn in
to assume liability for their own work as a part of being engaged in a group.
Hierarchical Synergy
• An Agile estimation approach can work on authoritative collaboration by separating hierarchical
obstructions and fostering a feeling of trust and association around hierarchical objectives.
 Project scheduling: Timeline charts,
CPM, Fish-bone diagram
Timeline charts
• Timeline charts are highly versatile visual charts that are used to illustrate a set of
events chronologically.
• They're an excellent tool for conceptualizing event sequences or processes to gain
insights into the nuances of a project.
• That could include summarizing historical events, or any other time frame where
you need to measure minutes, hours, dates, or years.
• There are many potential use cases for timeline charts.
• For example, history students can use them to highlight important events to help
remember dates for an exam.
• Organizations can use them to break down complex projects into more manageable
stints.
• Researchers can also use them to keep track of the time between experiments.
• Although there are several different types of timeline charts available to choose
from, all timeline charts follow a similar structure.
• They will all include dates and descriptions, and some will also include images and
headers.
• [Link]
 Critical Path Method
• Critical Path Method (CPM) is a method used in project planning,
generally for project scheduling for the on-time completion of the project.
• It helps in the determination of the earliest time by which the whole
project can be completed.
• There are two main concepts in this method namely critical task and
critical path.
• It is the task/activity that can’t be delayed otherwise the completion of the
entire project will be delayed. It must be completed on time before
starting the other dependent tasks.
• It is a sequence of critical tasks/activities and is the largest path in the
project network. It gives us the minimum time which is required to
complete the entire project. The activities in the critical path are known
as critical activities and if these activities are delayed then the completion
of the entire project is also delayed.
 Benefits of using the critical path method
in project management:
1. Show the project schedule visually.
2. Highlight important tasks with CPM.
3. Use CPM to find and handle risks.
4. CPM helps the project team communicate better.
How to find the critical path in a project:
The table given below contains the Duration (in
Activity Precedents
weeks)
activity label, its respective duration (in
weeks), and its precedents. We will use the A 6 –

critical path method to find the critical B 4 –

path C 3 A

and activities of this project. D 4 B

E 3 B

F 10 –

G 3 E,F

H 2 C,D
Rules for Designing the Activity-
on- Node network diagram:

• A project network should have only one start node

• A project network should have only one end node
• A node has a duration
• Links normally have no duration
• “Precedents” are the immediate preceding
activities
• Time moves from left to right in the project
network
• A network should not contain loops
• A network should not contain dangles
 Node
1. Activity label is the name of the
activity represented by that Representation:
node.
2. Earliest Start is the date or time at
which the activity can be started at the
earliest.
3. Earliest Finish is the date or time at
which the activity can be completed at
the earliest.
4. Latest Start is the date or time at
which the activity can be started at the
latest.
5. The latest Finish is the date or time
at which the activity can be finished at
the latest.
6. Float is equal to the difference
between the earliest start and latest
start or earliest finish and latest
Activity-On-Node diagram:
 Forward Pass in Critical path in project
forward pass is carried out: to calculate the earliest dates on which each activity may be started and
management
The
completed.
1. Activity A may start immediately. Hence, the earliest date for its start is zero i.e. ES(A) = 0. It takes
6 weeks to complete its execution. Hence, earliest it can finish is week 6 i.e. EF(A) = 6.
2. Activity B may start immediately. Hence, the earliest date for its start is zero i.e. ES(B) = 0. It takes 4
weeks to complete its execution. Hence, the earliest it can finish is week 4 i.e. EF(B) = 4.
Activity F may start immediately. Hence, the earliest date for its start is zero i.e. ES(F) = 0. It
3. takes 10 weeks to complete its execution. Hence, the earliest it can finish is week 10 i.e. EF(F)
= 10.
Activity C starts as soon as Activity A completes its execution. Hence, the earliest week it can start
4. its execution is week 6 i.e. ES(C) = 6. It takes 3 weeks to complete its execution. Hence, the earliest
it can finish is week 9 i.e. EF(C) = 9.
Activity D starts as soon as Activity B completes its execution. Hence, the earliest week it can start
5. its execution is week 4 i.e. ES(D) = 4. It takes 4 weeks to complete its execution. Hence, the earliest
it can finish is week 8 i.e. EF(D) = 8.
Activity E starts as soon as Activity B completes its execution. Hence, the earliest week it can start
6. its execution is week 4 i.e. ES(E) = 4. It takes 3 weeks to complete its execution. Hence, the earliest
it can finish is week 7 i.e. EF(E) = 7.
Activity G starts as soon as activity E and activity F completes their execution. Since the activity
7. requires the completion of both for starting its execution, we would consider the MAX(ES(E), ES(F)).
Hence, the earliest week it can start its execution is week 10 i.e. ES(G) =
10. It takes 3 weeks to complete its execution. Hence, the earliest it can finish is week 13 i.e. EF(G)
= 13.
Activity H starts as soon as activity C and activity D completes their execution. Since the activity
8. requires the completion of both for starting its execution, we would consider the MAX(ES(C),
ES(D)). Hence, the earliest week it can start its execution is week 9 i.e. ES(H) =
9. It takes 2 weeks to complete its execution. Hence, the earliest it can finish is week 11 i.e. EF(H)
= 11.
Forward Pass in Critical path
in project management:
 Backward Pass in Critical path in project
management:
The backward pass is carried out to calculate the latest dates on which each activity may be started and
finished without delaying the end date of the project. Assumption: Latest finish date = Earliest Finish date
(of project).
• Activity G’s latest finish date is equal to the earliest finish date of the precedent activity of finish
according to the assumption i.e. LF(G) = 13. It takes 3 weeks to complete its execution. Hence, the
latest it can start is week 10 i.e. LS(G) = 10.
• Activity H’s latest finish date is equal to the earliest finish date of the precedent activity of finish
according to the assumption i.e. LF(H) = 13. It takes 2 weeks to complete its execution. Hence, the
latest it can start is week 11 i.e. LS(H) = 11.
• The latest end date for activity C would be the latest start date of H i.e. LF(C) = 11. It takes 3
weeks
to complete its execution. Hence, the latest it can start is week 8 i.e. LS(C) = 8.
• The latest end date for activity D would be the latest start date of H i.e. LF(D) = 11. It takes 4 weeks
to complete its execution. Hence, the latest it can start is week 7 i.e. LS(D) = 7.
• The latest end date for activity E would be the latest start date of G i.e. LF(G) = 10. It takes 3 weeks
to complete its execution. Hence, the latest it can start is week 7 i.e. LS(E) = 7.
• The latest end date for activity F would be the latest start date of G i.e. LF(G) = 10. It takes 10
weeks
to complete its execution. Hence, the latest it can start is week 0 i.e. LS(F) = 0.
• The latest end date for activity A would be the latest start date of C i.e. LF(A) = 8. It takes 6 weeks
to
complete its execution. Hence, the latest it can start is week 2 i.e. LS(A) = 2.
• The latest end date for activity B would be the earliest of the latest start date of D and E i.e. LF(B) =
7. It takes 4 weeks to complete its execution. Hence, the latest it can start is week 3 i.e. LS(B) = 3.
Backward Pass in Critical path in project
management:
• Identifying Critical Path: The critical path is the path that gives us or
helps us estimate the earliest time in which the whole project can
be completed. Any delay to an activity on this critical path will lead to a
delay in the completion of the entire project. To identify the critical
path, we need to calculate the activity float for each activity.
Activity float is the difference between an activity’s Earliest start
and its latest start date or the difference between the activity’s
Earliest finish and its latest finish date, and it indicates how much the
activity can be delayed without delaying the completion of the
entire project. If the float of an activity is zero, then the activity is
critical and must be added to the critical path of the project
network. In this example, activities F and G have zero float and hence, are
critical activities.
Identifying Critical Path:
 Fish-bone diagram
• Also called: cause-and-effect diagram, Ishikawa
diagram
• Variations: cause enumeration diagram, process
fishbone, time-delay fishbone, CEDAC (cause-and-
effect diagram with the addition of cards), desired-
result fishbone, reverse fishbone diagram

This cause analysis tool is considered one of the seven

basic quality tools. The fishbone diagram identifies
many possible causes for an effect or problem. It can
be used to structure a brainstorming session. It
immediately sorts ideas into useful categories.
 WHEN TO USE A FISHBONE DIAGRAM
• When identifying possible causes for a problem
• When a team’s thinking tends to fall into ruts

FISHBONE DIAGRAM PROCEDURE

• Materials needed: marking pens and flipchart or whiteboard.
• Agree on a problem statement (effect). Write it at the center right of the flipchart or
whiteboard. Draw a box around it and draw a horizontal arrow running to it.
• Brainstorm the major categories of causes of the problem. If this is difficult use generic
headings:
• Methods
• Machines (equipment)
• People (manpower)
• Materials
• Measurement
• Environment
• Write the categories of causes as branches from the main arrow.
• Brainstorm all the possible causes of the problem. Ask "Why does this happen?" As each
idea is given, the facilitator writes it as a branch from the appropriate category. Causes can
be written in several places if they relate to several categories.
• Again ask "Why does this happen?" about each cause. Write sub-causes branching off
the causes. Continue to ask "Why?" and generate deeper levels of causes. Layers of
branches indicate causal relationships.
• When the group runs out of ideas, focus attention to places on the chart where ideas are few.
 FISHBONE DIAGRAM EXAMPLE
• This fishbone diagram was drawn by a manufacturing team to try to
understand the source of periodic iron contamination. The team used the
six generic headings to prompt ideas. Layers of branches show thorough
thinking about the causes of the problem.
 FISHBONE DIAGRAM EXAMPLE
• For example, under the heading "Machines," the idea "materials of
construction" shows four kinds of equipment and then several
specific machine numbers.
• Note that some ideas appear in two different places. "Calibration" shows up
under "Methods" as a factor in the analytical procedure, and also
under "Measurement" as a cause of lab error. "Iron tools" can be
considered a "Methods" problem when taking samples or a
"Manpower" problem with maintenance personnel.
Thank
You!