Unit 3

Estimation & Scheduling

 Estimation for Software Projects:
The Project Planning Process
• The objective of software project planning is to provide a framework
that enables the manager to make reasonable estimates of resources,
cost, and schedule.
• In addition, estimates should attempt to define best-case and
worst-case scenarios so that project outcomes can be bounded.
• Therefore, the plan must be adapted and updated as the project
proceeds.
The Project Planning Process

• Step 1: This is an initial Stage in which scope and feasibility of the

project is determined.
This stage helps to identify the functions and features that can be
delivered to the end user.
• Step 2: Risk are identified and analysed.

• Step 3 : The required resources such as human resources ,

environmental resources and reusable software resources can be
determine.

• Step 4: the estimation for cost and efforts is made, In this stage the
problem is first decomposed, then using the size , function point use
cases the estimates are made.

Step 5: Using the scheduling tool or task networks the schedule for the
project is prepare.
Defining Software Scope and
Checking Feasibility
• Software scope describes -
the functions and features that are to be delivered to end-users
the data that are input and output
the “content” of the software that is presented to users.
the performance, constraints, interfaces, and reliability that bound the system.

• Scope is defined using one of two techniques:

A narrative description of software scope is developed after communication
with all stakeholders.
A set of use-cases is developed by end-users.
• Following are four dimensions of software feasibility. To ensure the
feasibility software project the set of questions based on these
dimensions has to be answered those are given beloved.
1. Technology
Is a project technical feasible>
Is the within state of art?
Are the defects to be reduced to a level that satisfies the application
need?
2. Finance
Is it financially feasible?
Is the development cost completed at a cost of software organization, its
client or market affordable?
Are the defects to be reduced to a level that satisfy the application need?
3. Time
Will Project’s time to market beat the competition?

4. Resource
Does the organization have the resources needed to succeed?

• Once the scope is understood, and feasibility have been identified the
next task is estimation of the resources required to accomplish the
software development effort.
Resources management
• The first task in project planning is to identified the scop and
feasibility of the project and the second task is to estimate the
recourses required to accomplished the software development
efforts.
• There are three major categories of software engineering resources –
1. People
2. Reusable software components
3. Development environment that is hardware and software tools.
Project Resources
• Characteristics of resources:

1. Description of resources
2. A statement of availability
3. Time when resources will be required.
4. Duration of the time that resource will be applied.
1. Human Resources(People)
• The project planner begins by evaluating software scope and selecting
the “skills” require to complete development.
• Both organizational position (such as manager, senior software and so
on) and the specialty (Database telecommunication, client-server ect.)
are specified for a relatively small project .
• A single individual may perform all software engineering task, by
consulting with the specialist whenever needed.
• For a large projects, software team may be geographically at different
locations. Hence the location of human resource is specified.
• The number of people required for a software project can be
determined only after an estimate of development effort is made.
2. Reusable software components

• Component based software engineering (CBE) emphasizes one

important characteristics and that is reusability.
• That means by creating and reusing some building blocks the software
development is done. Such a building blocks are called components.
• Following are some software resource categories that should be
consider at planning-
1. Off- the-shelf components(OTS Components)
Existing software acquired from a third party or has been develop
internally for the past project.
2. full experience components-
• The software to be build for the current project resembles the existing
specification, design, code or test data develop for past projects.
• Members of the current software team that have had full experience in
the application area represented by these components.

3. Partial experience components -

• In this category, existing specification as for the full experience
components but it required extensive modification.
• The member of software project team have limited experience in
application area.
• Fair degree of risk involvement is there while using the components
belonging to this category.
4. New components –
• According to need and specification of the current project the
software components can be build by the software team.
3. Development environment

• The software Engineering environment (SEE) incorporates hardware

and software tools and Network resources.
• Hardware provides a platform for using the tools required to produce
work product.
• These work product are the outcome of good software engineering
practice.
Software Project Estimation
To achieve reliable cost and effort estimates, a number of options arise:
• Delay estimation until late in the project
• Base estimates on similar projects that have already been completed
• Use relatively simple decompaction techniques to generate project
cost and efforts estimates
• Use one or more empirical models for software cost and effort
estimation
Software cost and effort estimation will never be an exact science. Too
many variables—human, technical, environmental, political—can affect
the ultimate cost of software and effort applied to develop it.
Decomposition Techniques
• Before an estimate can be made and decomposition techniques
applied, the planner must
Understand the scope of the software to be built
Generate an estimate of the software’s size
• Then one of two approaches are used
Problem-based estimation
Based on either source lines of code(LOC) or function
point(FP) estimates.
Process-based estimation
Based on the effort required to accomplish each task.
Software Sizing
• The accuracy of a software project estimate is predicated on a
number of things:
The degree to which planner has properly estimated the size of the
product to be built.
The ability to translate the size estimate into human effort, calendar
time & money.
The degree to which the project plan reflects the abilities of software
team.
The stability of product requirement and the environment that
supports the software engineering efforts.
• Approaches:
1.Direct
2.Indirect

• In the context of project planning, size refers to a quantifiable

outcome of the software project.
• If a direct approach is taken, size can be measured in LOC.
• If an indirect approach is chosen, size is represented as FP.
Software Sizing
Different approaches to the sizing problem:
1. Fuzzy logic sizing:
• This approach planner must identify - The type of application.
• Establish its magnitude on a qualitative scale and then refine the
magnitude within the original range
• Planner should also have access to historical database of the project so
that estimates can be composed to actual experience

2. Function point sizing:

• The planner develops estimates of the information domain
characteristics.
3. Standard component sizing:
• Software is composed of a number of different “standard
components” that are generic to a particular application area.
• For example, the standard components for an information system are
subsystems, modules, screens, reports, interactive programs, batch
programs, files, LOC, and object-level instructions.
• The project planner estimates the number of occurrences of each
standard component and then uses historical project data to
determine the delivered size per standard component.
• To illustrate, consider an information systems application.
• The planner estimates that 18 reports will be generated. Historical
data indicates that 967 lines of COBOL are required per report. This
enables the planner to estimate that 17,000 LOC will be required for
the reports component.
• 4. Change sizing:
• This approach is used when a project encompasses the use of existing
software that must be modified in some way as part of a project.
• The planner estimates the number and type (e.g., reuse, adding code,
changing code, deleting code) of modifications that must be
accomplished.
• Using an “effort ratio” for each type of change, the size of the change
may be estimated.
Problem-Based Estimation
• LOC and FP data are used in two ways during software project
estimation:
as estimation variables to “size” each element of the software
 as baseline metrics collected from past projects and used in
conjunction with estimation variables to develop cost and effort value
for a project.
• Baseline productivity metrics (e.g., LOC/pm or FP/pm) are then
applied to the appropriate estimation variable, and cost or effort for
the function is derived
• In general, the LOC/pm and FP/pm metrics should be computed by
project domain.
• LOC and FP estimation differ in the level of detail required for
decomposition with each value
• Historical LOC or FP data is then compared to S in order to cross-check
it.
• For LOC, decomposition of functions is essential and should go into
considerable detail (the more detail, the more accurate the estimate)
• The expected value for the estimation variable (size) S can be
computed as a weighted average of the optimistic [hopeful and
confident about the future] (Sopt), most likely[more likely than not :
probably] (Sm), and pessimistic [believe that the worst will happen]
(Spess) estimates.
S = (Sopt+ 4*Sm+ Spess)/6
LOC Based Estimation
• The LOC (Line of Code ) is a product size metric in software
engineering.
• the number of lines in the code are counted and based on the
number of lines the cost is calculated.
• There is no definite clear picture of how to count number of lines
because the length and complexity of the code is different in different
languages.
• It only depends on the length but not on complexity and functionality.
Example of LOC based
Estimation
• Estimation table for LOC method:
• The range of LOC estimation for 3D geometric analysis function is-
optimistic estimation: 4600 LOC,
Most likely estimation: 6900 LOC,
pessimistic estimation: 8600 LOC.
Applying Equation, the expected value for the 3D geometric analysis
function is –
S = (Sopt+ 4*Sm+ Spess)/6
= (4600 + 4*6900 + 8600)/6
= 6800 LOC
Example of LOC based
Estimation
• Assume estimated lines of code of a system is: 33,200 LOC
• Average productivity for system of this type is: 620 LOC/person-
month
• There are 6 developers
• Labor rate is: $ 800 per person-month
• Calculate the total effort and cost required to complete the above
project??
Way 1 :
• Total Effort = Total LOC/Productivity = 33200/620=53.54 ≈ 54 person-
months
• 6 developers
• Effort = Total Effort/6 = 54/6 = 9 months
• Total Cost = Total Effort * Labor Rate = 54 * 800 ≈ $43,200
Way :
• Total Effort = Total LOC/Productivity = 35000/670=52.23 ≈ 53 person-
months
• 7 developers
• Effort = Total Effort/6 = 53/7= 8 months
• Total Cost = Total Effort * Labor Rate = 53 * 600 ≈ $31,800
Way 2 :
• Cost per LOC = Labor Rate /Productivity=800/620=$1.29 ≈ $1.3

• Total Cost = Total LOC * Cost per LOC = 33,200* 1.3=$43160 ≈

$43,200

• Total Effort = Total Cost / Labor Rate = 43,200/800 = 54 person-

months
Disadvantages
• The LOC technique is language-dependent (i.e It depends on specific
type of language experienced).

• The effort required to calculate source lines of code. This may not be
the same for all languages.
Function Point
• Function points were developed as an alternative to lines of codes to
measure the size of software.

• FP focuses on the information domain values rather than software

functions.
Features of Function Point
• The total size of a software project is expressed in total function
points.
• It is independent of the computer language, development
methodology, technology, or capability of the project team
developing the software project.
• To calculate FP for a project, some components are required.
• The FP technique is a direct indicator or measurement of a software
application functionality from the user's perspective.
• It is the most popular technique used to estimate the size of a
software project. - The total size of a project is estimated in the term
of FP.
Example of FP
• To calculate FP

• Where,
FP: Total Function Points
CT: Count Total
Example of FP- Based
Estimation
• Decomposition for FP-based estimation focuses on information
domain, thus function point calculation table is created-
• Each of the complexity weighting factors is estimated, and the value
adjustment factor is computed
• The estimated number of adjusted FP is derived using following
formula:

FP estimation=FP count total*[Complexity adjustment Factor]

Complexity adjustment Factor = [0.65+(0.01*53)]=1.18

FP estimation= (320*1.18)=378
• A review of historical data indicates –
 Average Productivity for systems of this type is 6.5 FP/pm.
 Average labour rate of $8000 per month.

Calculation for cost per function point, total estimated project cost and
total effort
1. The cost per function point= (8000/6.5)=$1230.
2. The total estimated project cost =(378* 1230)=$464,940.
3. Total Estimated effort=(378/6.5)=58 person-months.
Example for counting function
point
• The weighting factors are identified for all functional units and
multiplied with the functional units accordingly. The procedure for the
calculation of Unadjusted Function Point (UFP) is given in table shown
.
• The procedure for the calculation of UFP in mathematical form is
given below:

5 3
UFP   Z ij wij
i 1 J 1
• Where i indicate the row and j indicates the column of Table
• Wij : It is the entry of the ith row and jth column of the table
• Zij : It is the count of the number of functional units of Type i that
have been classified as having the complexity corresponding to
column j.
• function point methods develop a criterion for determining whether a
particular entry is Low, Average or High.

FP = UFP * CAF
• Where CAF is complexity adjustment factor and is equal to [0.65 +
0.01 x ΣFi].
• UFP is Unadjusted Function Point (UFP)
Example 1:

An application has 10 low external inputs, 12 high external outputs, 20

low internal logical files, 15 heigh external interface files, 12 average
external inquiries and a value of complexity adjustment factor 1.10.
What are the unadjusted and adjusted function point counts?
• Solution
• Unadjusted function point counts may be calculated using as:

5 3
UFP   Z ij wij
i 1 J 1

UFP = 10 * 3 + 12 * 7 + 20 *7 + 15 * 10 + 12 * 4
= 30 + 84 +140 + 150 + 48
= 452
FP = UFP *CAF
= 452 x*1.10 = 497.2.
Example 2:
• Consider a project with the following functional units:
Number of user inputs = 50
Number of user outputs = 40
Number of user enquiries = 35
Number of user files = 06
Number of external interfaces = 04
• value of complexity adjustment factor 1.07 and weighting factors are
average. Compute the function points for the project.
• Solution
5 3
UFP   Z ij wij
i 1 J 1

UFP = 50 x 4 + 40 x 5 + 35 x 4 + 6 x 10 + 4 x 7
= 200 + 200 + 140 + 60 + 28 = 628

FP = UFP x CAF
= 628 x 1.07 = 672
Example: 3
Consider a project with the following parameters.
(i) External Inputs:
(a) 10 with low complexity
(b)15 with average complexity
(c) 17 with high complexity
(ii) External Outputs:
(d)6 with low complexity
(e) 13 with high complexity
(iii) External Inquiries:
(a) 3 with low complexity
(b) 4 with average complexity
(c) 2 high complexity

48
 (iv) Internal logical files:
(a) 2 with average complexity
(b)1 with high complexity
(v) External Interface files:
(c) 9 with low complexity
In addition to above, system requires
i. Significant data communication
ii. Performance is very critical
iii. Designed code may be moderately reusable
iv. System is not designed for multiple installation in different
organizations.
Other complexity adjustment factors are treated as average. Compute
the function points for the project.
49
 Solution: Unadjusted function points may be counted using table 2
Functional Count Complexity Complexity Functional
Units Totals Unit Totals
External 10 Low x 3 = 30
Inputs 15 Average x 4 = 60
(EIs) 17 High x 6 = 102 192
External 6
Low x 4 = 24
Outputs 0 Average x 5 = 0
(EOs) 13 High x 7 = 91 115

External 3
Low x 3 = 9
Inquiries 4 Average x 4 = 16
(EQs) 2 High x 6 = 12 37

External 0 Low x 7 = 0
logical 2 Average x 10 = 20
Files (ILFs) 1 High x 15 = 15 35
External 9
Low x 5 = 45
Interface 0 Average x 7 = 0
Files (EIFs) 0 High x 10 = 0 45

424
Total Unadjusted Function Point Count
50
 14

 F 3+4+3+5+3+3+3+3+3+3+2+3+0+3=41
i 1
i

CAF = (0.65 + 0.01 x ΣFi)

= (0.65 + 0.01 x 41)
= 1.06
FP = UFP x CAF
= 424 x 1.06
= 449.44

Hence FP = 449
51
Process Based Estimation

• In this technique, the process is decomposed into relatively size set of

tasks and the effort required to accomplish each task is estimated.

• Estimation starts with Identification from project scope

Example of Process based
Estimation

CC : Customer communication CE : Customer Evaluation

• The Percentage effort is calculated based on the total= 46

• For instance we get the total for the task Design as 20.50

• 20.50*100/46= 44% approximately

• The percentage efforts for all the software engineering tasks are
computed, based on average labor cost of $8000 per month
1. total estimated project efforts= 46 persons –month
2. Total estimated project cost(8000* 46)=$368000
Estimation with Use Case
• A Use-Case is a series of related interactions between a user and a
system that enables the user to achieve a goal.
• Use-Cases are a way to capture functional requirements of a system.
The user of the system is referred to as an ‘Actor’. Use-Cases are
fundamentally in text form.
• Use-Case Points – Definition: Use-Case Points (UCP) is a software
estimation technique used to measure the software size with use
cases. The concept of UCP is similar to FPs.
• The number of UCPs in a project is based on the following −
The number and complexity of the use cases in the system.
The number and complexity of the actors on the system.
Various non-functional requirements (such as portability,
performance, maintainability) that are not written as use cases.
The environment in which the project will be developed (such as the
language, the team’s motivation, etc.)
• Difficulties in developing estimations using use cases:
1. variety of ways
2. external view
3. complexity
4. Complex behaviour

• Task to complete before use case estimation:

level
Average length
Type of software
Rough system
Reconciling Estimates

• The results gathered from the various estimation techniques must be

reconciled to produce a single estimate of effort, project duration,
and cost.
LOC= 54 person-month
FP= 58 person-month
Process based= 46 person-month
• This means the project can be completed with the range from a low
of 46 person-months to high of 58 person-month.
• The Average estimates is 52 person-month.
Empirical Estimation Models
• Estimation models for computer software use empirically derived
formulas to predict effort as a function of LOC or FP
• Resultant values computed for LOC or FP are entered into
an estimation model
• The empirical data for these models are derived from a
limited sample of projects
• Consequently, the models should be calibrated to reflect local
software development conditions
COCOMO
• Stands for COnstructive COst MOdel
• Introduced by Barry Boehm in 1981 in his book “Software
Engineering Economics”
• Became one of the well-known and widely-used estimation models in
the industry
• It has evolved into a more comprehensive estimation model called
COCOMO II
• COCOMO II is actually a hierarchy of three estimation models that
focus the following area:
• Application composition model: Used during the early stages of
software engineering, when prototyping of user interfaces,
consideration of software and system interaction, assessment of
performance, and evaluation of technology maturity are paramount.

• Early design stage model: Used once requirements have been

stabilized and basic software architecture has been established.

• Post-architecture-stage model: Used during the construction of the

software
• As with all estimation models, it requires sizing information and
accepts it in three forms: object points, function points, and lines of
source code.
• The COCOMO II application composition model uses object points The
object point is an indirect software measure that is computed using
counts of the number of
screens (at the user interface),
reports, and
components likely to be required to build the application.
• The object point count is then determined by multiplying the original
number of object instances by the weighting factor in the figure and
summing to obtain a total object point count.
• When component-based development or general software reuse is to
be applied, the percent of reuse (%reuse) is estimated and the object
point count is adjusted:

where NOP is defined as new object points.

• To derive an estimate of effort based on the computed NOP value, a
“productivity rate” must be derived.
• Figure shows the productivity rate for different levels of developer
experience and development environment maturity.

• Once the productivity rate has been determined, an estimate of

project effort is computed using
• Example:

Consider a database application project with

1.The application has four screens with four views each and seven data
tables for three servers and four clients.
2.Application may generate two reports of six section each from seven
data tables for two servers and three clients.
• 10% reuse of object points.
Developer’s experience and capability in similar environment is low.
Calculate the object point count, New object point and effort to
develop such project.
Step-1:
Number of screens = 4
Number of records = 2

Step-2:
For screens,
Number of views = 4
Number of data tables = 7
Number of servers = 3
Number of clients = 4
by using above given information and table (For Screens),
Complexity level for each screen = medium
• For reports,
Number of sections = 6
Number of data tables = 7
Number of servers = 2
Number of clients = 3
by using above given information and table (For Reports),
Complexity level for each report = difficult
• Step-3:
By using complexity weight table we can assign complexity weight to
each object instance depending upon their complexity level.
Complexity weight for each screen = 2
Complexity weight for each report = 8
Step-4:
Object point count
= (Number of object instances) * (its Complexity weight)
= 4 * 2 + 2 * 8 = 24

Step-5:
%reuse of object points = 10% (given)
NOP = [object points * (100 - %reuse)]/100
= [24 * (100 -10)]/100 = 21.6
Step-6:
Developer’s experience and capability is low (given)
Using information given about developer and productivity rate table
Productivity rate (PROD) of given project = 7

Step-7:
Effort
= NOP/PROD
= 21.6/7
= 3.086 person-month

• Therefore, effort to develop the given project = 3.086 person-month.

Preparing Requirement
Traceability Matrix
• Requirement:
Requirement is a specification of a need or want. Sets
of requirements are used to capture the information needed to design,
build and test a process, service, product or system.

• Test Case:
Test Case is a document, which has a set of test data,
preconditions, expected results and postconditions, developed for a
particular test scenario in order to verify compliance against a specific
requirement.
Test Case Example
• to check an input field that can accept maximum of 10 characters
Traceability Matrix
• A Traceability Matrix is a document that co-relates any two-baseline
documents that require a many-to-many relationship to check the
completeness of the relationship.
• It is used to track the requirements and to check the current project
requirements are met.
Requirement Traceability Matrix
• Requirement Traceability Matrix is a document that maps and traces
user requirement with test cases.
• It captures all requirements proposed by the client and requirement
traceability in a single document, delivered at the conclusion of the
Software development life cycle.
• The main purpose of Requirement Traceability Matrix is to validate
that all requirements are checked via test cases such that no
functionality is unchecked during Software testing.
Template of RTM
SOFTWARE PROJECT
SCHEDULING
• Software project scheduling is an action that distributes estimated
effort across the planned project duration by allocating the effort to
specific software engineering tasks.
• The manager needs to estimate time and resources of project while
scheduling project.

• Problems arise during Project Development Stage :

People may leave or remain absent during particular stage of

development.
Hardware may get failed while performing.
Software resource that is required may not be available at present,
etc.
• To accomplish and complete project within a given schedule, required
resources must be available when they are needed. Therefore,
resource estimation should be done before starting development.

• Resources required for Development of Project :

Human effort
Sufficient disk space on server
Specialized hardware
Software technology
Travel allowance required by project staff, etc.
Basic Principles for software project scheduling:

Compartmentalization:
The project must be compartmentalized into a number of
manageable activities and tasks. To accomplish compartmentalization,
both the product and the process are refined.

Interdependency:
The interdependency of each compartmentalized activity or
task must be determined. Some tasks must occur in sequence, while
others can occur in parallel.
Time allocation.
Each task to be scheduled must be allocated some number of work units (e.g.,
person-days of effort). In addition, each task must be assigned a start date and a
completion date that are a function of the interdependencies and whether work
will be conducted on a full- time or part-time basis.

Effort validation.:
Every project has a defined number of people on the software team. As time
allocation occurs, you must ensure that no more than the allocated number of
people has been scheduled at any given time.

Defined responsibilities:
Every task that is scheduled should be assigned to a specific team
member.
Defined outcomes:
Every task that is scheduled should have a defined outcome. For
software projects, the outcome is normally a work product (e.g., the
design of a component) or a part of a work product. Work products are
often combined in deliverables.

Defined milestones:
Every task or group of tasks should be associated with a project
milestone.
A milestone is accomplished when one or more work products has
been reviewed for quality and has been approved.
Defining a Task for the Software
Project
• A task set is the work breakdown structure for the project
• No single task set is appropriate for all projects and process models
• It varies depending on the project type and the degree of rigor (based
on influential factors) with which the team plans to work
• The task set should provide enough discipline to achieve high
software quality
• But it must not burden the project team with unnecessary work
Types of Software Projects
• Concept development projects: Explore some new business concept
or application of some new technology

• New application development Project: Undertaken as a consequence

of a specific customer request

• Application enhancement Project: Occur when existing software

undergoes major modifications to function, performance, or
interfaces that are observable by the end user
• Application maintenance:
These are a kind of project that Correct, adapt, or extend
existing software application.

• Reengineering projects:
These are a project in which legacy systems are rebuilt
partly or completely.
A legacy system is outdated computing software and/or hardware that
is still in use.
Factors that influence the Project schedule

• Size of the project

• Number of potential users
• Application long life
• Stability of requirements
• Ease of customer/developer communication
• Maturity of applicable technology
• Performance constraints
• Project staff
• Reengineering factors
Task Network
• Task network also called an activity network
• It is a graphic representation of the task flow for a project. Node
corresponding to activities.
• It depicts task length, sequence, concurrency, and dependency.
• The project manager should be aware of interdependencies among
various task. It should be aware of all those task which lie on critical path.
• The critical path
A single path leading from start to finish in a task network
It contains the sequence of tasks that must be completed on schedule if
the project as a whole is to be completed on time.
 It also determines the minimum duration of the project
Task Set Example
• Defining scope : This task is defining a scope, goal or objective of the project.

• Planning: It include estimates for the schedule, cost and people for
completing the desire concepts.

• Evaluation of technology risks: It includes risk associated with the

technology used in the project.

• Concept implementation: It includes the concept implementation in the

same manner as expected by the end user.
Fig. Task Network
Scheduling with time line chart
• Time line chart also called a Gantt chart.
• It is simply used for graphical representation of schedule that helps to
plan in an efficient way, coordinate, and track some particular tasks in
project.
• The purpose of Time line chart is to emphasize scope of individual
tasks.
• Hence set of tasks is given as input to time line chart.
• It can be developed for entire project or it can be developed for
individual functions.
• Time line chart represents following things –

 All the tasks are listed at leftmost column.

The horizontal bars indicate or represent required time by
corresponding particular task.
When occurring of multiple horizontal bars takes place at same time
on calendar, then that means concurrency can be applied for
performing particular tasks.
The diamonds indicate milestones. (a significant stage or event in the
development.)
Time Line chart Example-
Advantages
Simplify Project –
Gantt charts are generally used for simplifying complex projects.

Establish Schedule –
It simply establishes initial project schedule in which it mentions who is going to do
what, when, and how much time it will take to complete it.

Provide Efficiency –
It brings efficiency in planning and allows team to better coordinate project activities.
Emphasize on scope –
It helps in emphasizing i.e., gives importance to scope of individual tasks.

Ease at understanding –
It makes it easy for stakeholders to understand timeline and brings clarity
of dates.

Visualize project –
It helps in clearly visualizing project management, project tasks involved.
Organize thoughts and Highly visible –
It organizes your thoughts and can be highly visible so that everyone in
enterprises can have basic level of understanding and have knowledge
about what’s happening in project even if they are not involved in
working.

Make Practical and Realistic planning –

It makes the project planning practical and realistic as realistic planning
generally helps to avoid any kind of delays and losses of many that can
arise.
Schedule tracking tools
• 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.
Benefits of Project Scheduling
Tools
• Defines work tasks: The project scheduling tool defines the work tasks
of a project.
• Time and resource management: It helps to keep the project on track
with respect to the time and plan.
• Cost management: It helps in determining the cost of the project.
• Improved projectivity: It enables greater productivity in teams as it
helps in smarter planning, better scheduling, and better task
delegation.
• Increased efficiency: The project scheduling tool increases speed and
efficiency in project development.
Microsoft Project
• Microsoft offers a Project Management tool named Microsoft Project
for Project Planning activities.
• It is simple to use Microsoft Projects for scheduling projects.
• It generates a variety of reports and templates as per Industry
standards.
• It can produce data in diagrams or charts in pictorial form.
• Themes and templates can be customized as per the user.
• It supports cloud services and can share data remotely with other
users.
Features:
• Creating the project schedule.
• Assigning resources to the task.
• Tracking the process.
• Managing the cost of the project.
• Analysis of the project.
• Automatic / Manual Scheduling for specific tasks or the entire project.
• To accomplish the tasks, deadlines are set.
Daily Activity Reporting and
Tracking (DART)
• DART Daily Activity Reporting Tool, enables you to track the changes
to record made by users.
• Many organizations use the DART tool which monitors the progress of
the software project.
• DART collects the project data and keeps track of the activities in the
process.
• DART which tracks the progress of the project is called an indicator
that computes the project plan.
• The DART is used to scale the software project stakeholders regarding
the performance and updates of the project.
Features:
• Defines work tasks and their Interdependencies.
• Provides the ability to dispatch the email with a summary of changes.
• Tracks the process and changes in the project plan.
• Analyzing the project plan.
• Manages budget for the project.