Subject :Software Engineering

Unit 2

Line of Code (LOC): is any line of text in a code that is not a comment or
blank line, and also header lines, in any case of the number of statements or
fragments of statements on the line. LOC consists of all lines containing the
declaration of any variable, and executable and non-executable statements

Features of Lines of Code (LOC)

 Change Tracking: Variations in LOC as time passes can be tracked to analyze
the growth or reduction of a codebase, providing insights into project
progress.
 Limited Representation of Complexity: Despite LOC provides a general idea
of code size, it does not accurately depict code complexity. It is possible for
two programs having the same LOC to be incredibly complex.
 Ease of Computation: LOC is an easy measure to obtain because it is easy to
calculate and takes little time.
 Easy to Understand: The idea of expressing code size in terms of lines is one
that stakeholders, even those who are not technically inclined, can easily
understand.
Advantages of Lines of Code (LOC)
 Effort Estimation: LOC is occasionally used to estimate development efforts
and project deadlines at a high level. Although caution is necessary, project
planning can begin with this.
 Comparative Analysis: High-level productivity comparisons between several
projects or development teams can be made using LOC. It might provide an
approximate figure of the volume of code generated over a specific time
frame.
 Benchmarking Tool: When comparing various iterations of the same program,
LOC can be used as a benchmarking tool. It may bring information on how
modifications affect the codebase's total size.
Disadvantages of Lines of Code (LOC)
 Challenges in Agile Work Environments: Focusing on initial LOC estimates
may not adequately reflect the iterative and dynamic nature of development in
agile development, as requirements may change.
 Not Considering Into Account External Libraries: Code from other libraries or
frameworks, which can greatly enhance a project's overall usefulness, is not
taken into account by LOC.
 Challenges with Maintenance: Higher LOC codebases are larger codebases
that typically demand more maintenance work.

KLOC (Thousands of Lines of Code): is a metric used to estimate

the size, effort, cost, and complexity of a software project by measuring its source
code in thousands of lines. It helps in planning and tracking, often used with
models like COCOMO, but its effectiveness is debated because counting methods
(including comments/blanks) vary, and it doesn't fully capture quality or
complexity, leading to calls for more detailed metrics like Source Lines of Code
(SLOC) or Function Points.

Size: A simple count of the program's physical or logical lines of code.

Effort Estimation: Used to predict the person-months needed for development
(Effort =

a×(KLOC)ba cross open paren cap K cap L cap O cap C close paren to the b-th
power
𝑎×(𝑎𝑎𝑎𝑎)𝑎
).
Productivity: Calculated as KLOC divided by effort (KLOC/Person-Months).
Defect Density: Can be used to gauge quality (Defects per KLOC).

Software Cost Estimation : is a systematic process used to forecast the

amount of effort (person-hours or person-months), duration (calendar time), and
financial cost required to develop, deploy, and maintain a software product. It is a
foundational step in the software project management lifecycle, ensuring that
stakeholders can make informed decisions and that projects are delivered on time,
within budget, and with the desired quality.
This process involves analyzing various factors such as project scope, complexity,
team expertise, tools, technologies, and risks to generate realistic and data-driven
estimates that help in effective project planning, budgeting, scheduling, and resource
allocation.

Objectives of Software Cost Estimation

 Optimize Resource Allocation: Determine the number and type of personnel,
tools, and infrastructure needed for the project.
 Assess Project Feasibility: Estimate whether the software project can be
completed within the available time, budget, and resources.
 Support Budget Planning: Provide a financial forecast to help stakeholders
allocate appropriate funds and avoid unexpected expenses.
 Minimize Risks: Identify potential cost related risks early in the project and plan
strategies to mitigate them.
 Improve Decision-Making: Provide project managers and stakeholders with data
driven insights for informed planning and execution.
 Aid in Project Scheduling: Help in setting realistic timelines by estimating the
duration required for each development phase.
Components of Software Cost Estimation
 Project Size : Measured in terms of Lines of Code (LOC) or Function Points
(FP), the overall size of the project directly influences the effort and time needed
for development.
 Project Complexity : Projects with higher complexity demand more time,
specialized expertise, and careful planning, which can significantly impact cost.
 Technology and Tools : The cost of software tools, platform licenses, and any
special hardware can increase the project’s total expenditure.
 Risk and Uncertainty : Factors such as unclear requirements, use of unfamiliar
technologies, or an inexperienced team can introduce risks, which may lead to
higher costs.
 Development Duration :The total time required to design, develop, test, and
deploy the software contributes to overall cost estimation.
 Team Size and Skill Level : The number of developers and their experience
levels affect labor costs. Highly skilled professionals usually require higher
compensation.
Steps in the Cost Estimation Process
 Initial Assessment by Project Leaders : Project managers and technical leads
evaluate project goals, constraints, and business needs.
 Risk and Trade-off Analysis: Key stakeholders identify potential risks, explore
alternative approaches, and assess trade offs to determine feasible paths forward.
 Cost Modeling Initiation: Cost modelers are given a target budget or cost limit
aligned with business goals (e.g., "We must deliver this for $X").
 Development of the Cost Estimate: Using inputs like risk factors, resource needs,
and project complexity, modelers generate a realistic cost estimate.
 Justification and Documentation: The final estimate is presented with a clear
rationale explaining how the cost was derived and why it is justified.
Purpose of Cost Estimation in Software Projects
 Project Planning and Scheduling: Helps decide how many developers are needed
and creates a realistic timeline for completing the project.
 Tracking Progress: Allows project managers to monitor whether the work is
moving in the right direction and take action if things go off track.
 Optimizing Resource Usage: Ensures that resources like labor, tools, and
materials are used efficiently to reduce waste and improve productivity.
 Support for Contract Discussions: Provides a solid basis for discussing and
agreeing on project costs, timelines, and responsibilities between different
parties.
 Better Team Communication: Builds a shared understanding of the financial
aspects of the project, encouraging clear and honest communication among
stakeholders.
 Time and Effort Management: Helps estimate how long different tasks will take
and how resources should be allocated, which directly impacts the overall project
schedule.
Common Cost Estimation Techniques
Technique Description

Expert Judgment Based on experience and intuition of experts.

 Technique Description

Analogous Estimation Based on costs from previous similar projects.

Top-Down Estimation Estimate the total cost, then divide among components.

Bottom-Up Estimation Estimate cost for each module and sum up.

COCOMO model A mathematical model using inputs like LOC and complexity.

Function Point Analysis Measures software by functionality delivered to the user.

The Constructive Cost Model (COCOMO):

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.
It is a Software Cost Estimation Model that helps predict the effort, cost, and
schedule required for a software development project.

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.
The key parameters that define the quality of any Software Product, which are
also an outcome of COCOMO, are primarily effort and schedule.

Types of Projects in COCOMO Model

In the COCOMO model, software projects are categorized into three types based
on their complexity, size, and the development environment. These types are:

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.

Structure of COCOMO Model

The Six phases of detailed COCOMO are
1. Planning and requirements: This initial phase involves defining the scope,
objectives, and constraints of the project. It includes developing a project plan
that outlines the schedule, resources, and milestones
2. System design: : In this phase, the high-level architecture of the software
system is created. This includes defining the system’s overall structure,
including major components, their interactions, and the data flow between
them.
3. Detailed design: This phase involves creating detailed specifications for each
component of the system. It breaks down the system design into detailed
descriptions of each module, including data structures, algorithms, and
interfaces.
4. Module code and test: This involves writing the actual source code for each
module or component as defined in the detailed design. It includes coding the
functionalities, implementing algorithms, and developing interfaces.
5. Integration and test: This phase involves combining individual modules into a
complete system and ensuring that they work together as intended.
6. Cost Constructive model: The Constructive Cost Model (COCOMO) is a
widely used method for estimating the cost and effort required for software
development projects.

Types of COCOMO Model

There are three types of COCOMO Model:

Basic COCOMO Model

The Basic COCOMO model is a straightforward way to estimate the effort

needed for a software development project. It uses a simple mathematical formula
to predict how many person-months of work are required based on the size of the
project, measured in thousands of lines of code (KLOC).
It estimates effort and time required for development using the following
expression:
E = a*(KLOC)b PM
Tdev = c*(E)d
Person required = Effort/ Time
Where,
E is effort applied in Person-Months
KLOC is the estimated size of the software product indicate in Kilo
Lines of Code
Tdev is the development time in months
a, b, c are constants determined by the category of software project
given in below table.
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 software projects are:
 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. For organic mode,

 effort = 2.4 × (400)1.05 ≈ 1295 person-month.
 dev. time = 2.5 × (1295)0.38 ≈ 38 months.
2. For semi-detach mode,
 effort = 3 × (400)1.12 ≈ 2462 person-month.
 dev. time = 2.5 × (2462)0.35 ≈ 38 months.
3. For Embedded mode,
 effort = 3.6 × (400)1.20 ≈ 4772 person-month.
 dev. time = 2.5 × (4772)0.32 ≈ 38 months.

Intermediate COCOMO 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
(multipliers) and the Intermediate Model
utilizes 15 such drivers for cost estimation.
Classification of Cost Drivers and their Attributes:
The cost drivers are divided into four categories
Product attributes:
 Required Software Reliability extent
 Size of the application database
 The complexity of the product
Hardware attributes:
 Run-time performance constraints
 Memory constraints
 The volatility of the virtual machine environment
 Required turnabout time
Personal attributes:
 Analyst capability
 Software engineering capability
 Application experience
 Virtual machine experience
 Programming language experience
Each of the 15 such attributes can be rated on a six-point scale ranging from
"very low" to "extra high" in their relative order of importance. Each attribute has
an effort multiplier fixed as per the rating. Table give below represents Cost
Drivers and their respective rating:
The Effort Adjustment Factor (EAF) is determined by multiplying the
effort multipliers associated with each of the 15 attributes.
The Effort Adjustment Factor (EAF) is employed to enhance the estimates
generated by the basic COCOMO model in the following expression:
Intermediate COCOMO Model equation:
E = a*(KLOC)b * EAF PM
Tdev = c*(E)d
Where,
 E is effort applied in Person-Months
 KLOC is the estimated size of the software product indicate in
Kilo Lines of Code
 EAF is the Effort Adjustment Factor (EAF) is a multiplier used to
refine the effort estimate obtained from the basic COCOMO
model.
 Tdev is the development time in months
 a, b, c are constants determined by the category of software
project given in below table.
The constant values a, b, c, and d for the Basic Model for the different categories
of the software projects are:
 Software a b c d
Projects

Organic 3.2 1.05 2.5 0.38

Semi-
3.0 1.12 2.5 0.35
Detached

Embedded 2.8 1.20 2.5 0.32

Detailed COCOMO Model

Detailed COCOMO goes beyond Basic and Intermediate COCOMO by diving

deeper into project-specific factors. It considers a wider range of parameters, like
team experience, development practices, and software complexity. By analyzing
these factors in more detail, Detailed COCOMO provides a highly accurate
estimation of effort, time, and cost for software projects. It's like zooming in on a
project's unique characteristics to get a clearer picture of what it will take to
complete it successfully.
1. NASA Space Shuttle Software Development: NASA estimated the time and
money needed to build the software for the Space Shuttle program using the
COCOMO model. NASA was able to make well-informed decisions on
resource allocation and project scheduling by taking into account variables
including project size, complexity, and team experience.
2. Big Business Software Development: The COCOMO model has been widely
used by big businesses to project the time and money needed to construct
intricate business software systems. These organizations were able to better
plan and allocate resources for their software projects by using COCOMO's
estimation methodology.
Advantages of the COCOMO Model
1. Systematic cost estimation: Provides a systematic way to estimate the cost and
effort of a software project.
2. Helps to estimate cost and effort: This can be used to estimate the cost and
effort of a software project at different stages of the development process.
3. Helps in high-impact factors: Helps in identifying the factors that have the
greatest impact on the cost and effort of a software project.
4. Helps to evaluate the feasibility of a project: This can be used to evaluate the
feasibility of a software project by estimating the cost and effort required to
complete it.
Disadvantages of the COCOMO Model
1. Assumes project size as the main factor: Assumes that the size of the software
is the main factor that determines the cost and effort of a software project,
which may not always be the case.
2. Does not count development team-specific characteristics: Does not take into
account the specific characteristics of the development team, which can have a
significant impact on the cost and effort of a software project.
3. Not enough precise cost and effort estimate: This does not provide a precise
estimate of the cost and effort of a software project, as it is based on
assumptions and averages.

Software Quality Assurance (SQA) :

is simply a way to assure quality in the software. It is the set of activities that
ensure processes, procedures as well as standards are suitable for the project and
implemented correctly. It is a process that works parallel to Software
Development. It focuses on improving the process of development of software so
that problems can be prevented before they become major issues. Software
Quality Assurance is a kind of Umbrella activity that is applied throughout the
software process.

Quality
Quality in a product or service can be defined by several measurable
characteristics. Each of these characteristics plays a crucial role in determining
the overall quality.
Generally, the quality of the software is verified by third-party organizations
like international standard organizations .

Elements of Software Quality Assurance (SQA)

 Standards: The IEEE, ISO, and other standards organizations have produced a
broad array of software engineering standards and related documents. The job
of SQA is to ensure that standards that have been adopted are followed and
that all work products conform to them.
 Reviews and audits: Technical reviews are a quality control activity performed
by software engineers for software engineers. Their intent is to uncover errors.
Audits are a type of review performed by SQA personnel (people employed in
 an organization) with the intent of ensuring that quality guidelines are being
followed for software engineering work.
 Testing: Software testing is a quality control function that has one primary
goal to find errors. The job of SQA is to ensure that testing is properly planned
and efficiently conducted for primary goal of software.
 Error/defect collection and analysis : SQA collects and analyzes error and
defect data to better understand how errors are introduced and what software
engineering activities are best suited to eliminating them.
 Change management: SQA ensures that adequate change management
practices have been instituted.
 Education: Every software organization wants to improve its software
engineering practices. A key contributor to improvement is education of
software engineers, their managers, and other stakeholders. The SQA
organization takes the lead in software process improvement which is key
proponent and sponsor of educational programs.
 Security management: SQA ensures that appropriate process and technology
are used to achieve software security.
 Safety: SQA may be responsible for assessing the impact of software failure
and for initiating those steps required to reduce risk.
 Software's Portability: Software's portability refers to its ability to be easily
transferred or adapted to different environments or platforms without needing
significant modifications. This ensures that the software can run efficiently
across various systems, enhancing its accessibility and flexibility.
 Software's Usability: Usability of software refers to how easy and intuitive it
is for users to interact with and navigate through the application. A high level
of usability ensures that users can effectively accomplish their tasks with
minimal confusion or frustration, leading to a positive user experience.
 Software's Reusability: Reusability in software development involves
designing components or modules that can be reused in multiple parts of the
software or in different projects. This promotes efficiency and reduces
development time by eliminating the need to reinvent the wheel for similar
functionalities, enhancing productivity and maintainability.
 Software's Correctness: Correctness of software refers to its ability to produce
the desired results under specific conditions or inputs. Correct software
behaves as expected without errors or unexpected behaviors, meeting the
requirements and specifications defined for its functionality.
 Software's Maintainability: Maintainability of software refers to how easily it
can be modified, updated, or extended over time. Well maintained software is
structured and documented in a way that allows developers to make changes
efficiently without introducing errors or compromising its stability.
  Software's Error Control: Error control in software involves implementing
mechanisms to detect, handle, and recover from errors or unexpected
situations gracefully. Effective error control ensures that the software remains
robust and reliable, minimizing disruptions to users and providing a smoother
experience overall

 Risk management : The SQA organization ensures that risk
management activities are properly conducted and that risk-related
contingency plans have been established.

SQA (Software Quality Assurance) Plans : are formal documents

outlining the processes, standards, tools, and responsibilities to ensure software
meets quality requirements throughout its lifecycle, going beyond mere testing to
include design reviews, code control, problem reporting, and consistent
methodologies, all aimed at preventing defects and ensuring customer satisfaction.
A good plan defines quality objectives, specifies testing strategies (like white
box, performance, automated), details roles, and establishes procedures for audits
and risk management.

Components of an SQA Plan

 Purpose & Scope: Defines the plan's goals, what it covers, and its references (like
SRS, ISO standards).
 Roles & Responsibilities: Clearly states who does what in the QA process.
 Standards & Processes: Outlines the procedures, techniques, and quality metrics
used.
 Tools & Methodologies: Specifies the tools (e.g., testing tools, CI/CD) and
methods (e.g., multi-testing strategy).
 Code Control: Details how source code is managed and controlled.
 Problem Reporting: Defines the process for logging, tracking, and resolving
defects.
 Reviews & Audits: Schedules formal technical reviews, checkpoints, and audits.
 Records & Metrics: How quality data is collected, maintained, and reported.
 Importance of SQA plan :
 Proactive Risk Management: Identifies and mitigates risks early, preventing costly
defects.
 Consistency & Standardization: Ensures uniform quality across projects and teams.
 Customer Satisfaction: Delivers reliable software that meets or exceeds
expectations.
 Efficiency: Provides a framework for faster, more predictable releases.

Activities in an SQA Plan

 SQA Activities: Creating the plan, defining checklists, performing reviews.
 Formal Technical Reviews (FTRs): Evaluating designs and prototypes.
 Multi-Testing Strategy: Using various testing methods.
 Process Adherence: Monitoring compliance with established processes.
 Continuous Improvement: Regularly improving the quality process.

Verification : is the process of checking that software achieves its goal

without any bugs. It is the process to ensure whether the product that is developed
is right or not. It verifies whether the developed product fulfills the requirements
that we have. Verification is static testing. Verification means Are we building
the product right?

Validation : is the process of checking whether the Software Product is up to

the mark, or in other words product has high-level requirements. It is the process
of checking the validation of the product i.e., it checks whether what we are
developing is the right product. It is a validation of the actual and expected
products. Validation is dynamic testing. Validation means Are we building the
right product?

Project Evaluation and Review Technique (PERT) :

 is a procedure through which activities of a project are represented in its
appropriate sequence and timing. It is a scheduling technique used to schedule,
organize and integrate tasks within a project. PERT is basically a mechanism for
management planning and control which provides blueprint for a particular
project. All of the primary elements or events of a project have been finally
identified by the PERT.
In this technique, a PERT Chart is made which represent a schedule for all the
specified tasks in the project. The reporting levels of the tasks or events in the
PERT Charts is some what same as defined in the work breakdown structure
(WBS).

A PERT chart is a project management tool used to plan and schedule tasks,
illustrating the sequence and timing of project activities. The PERT chart is used
to schedule, organize and co-ordinate tasks within the project. the objective of
PERT chart is to determine the critical path, which comprises critical activities
that should be completed on schedule. This chart is prepared with the help of
information generated in project planning activities such as estimation of effort,
selection of suitable process model for software development and decomposition
of tasks into subtasks.
Main components of a PERT chart:
 Nodes: it represents the task or milestones. every node represents the task
name and may also show duration of the task.
 Arrows: it indicates the direction or sequence of task and also dependencies
between them. suppose an array from A to B, then task A must be completed
before task B.
 Time Estimation: It estimates the time duration to complete the task.
 Critical Path: The critical path is the largest path in project management that
always results in the shortest time to complete the project.
 Milestones: It is Key point in the project timeline that represent significant
events or deadlines.
PERT Chart Working:
A PERT chart used to plan and visualize tasks in a project. It breaks down the
project into individual tasks and shows the sequence in which they must be
completed. Each task is represented by a node, and arrows indicate the
dependencies between tasks. By analyzing the chart, teams can identify the
critical path, which helps determine the shortest time to complete the project and
allocate resources effectively.

Create a PERT chart:

To create a PERT chart, we can follow the below steps:

Step 1: Identify Project Tasks

List all the tasks required to complete the project. Identifying tasks means listing
all the steps needed to complete a project. Start by figuring out what the main
goal is, then break it down into smaller actions. Ask team members for ideas and
use clear action words for each task.

Step 2: Define task dependencies

Defining task dependencies means figuring out which tasks must be completed
before others can start. Look at your task list and identify connections by asking
if one task relies on another. This helps you establish the order of work, ensuring
everything is done in the right sequence.

Step 3: Estimate Timeline

Estimating the timeline involves figuring out how long each task will take to
complete. For each task, think about the quickest time it could be done
(optimistic), the longest it might take (pessimistic), and the most likely time it
will actually take. This gives you a better idea of the overall project duration and
helps with planning.

Step 4: Calculate Critical Path

Calculate Critical Path means finding the longest sequence of tasks that
determines the shortest time to complete the project. Identify which tasks can’t be
delayed without affecting the overall project deadline, helping you focus on
what’s most important.

Step 5: Manage task progress

It involves tracking how each task is going. Regularly check if tasks are on
schedule, address any delays, and adjust plans if needed. This ensures the project
stays on track and any issues are resolved quickly.

Characteristics of PERT Chart

The main characteristics of PERT are as following:
 It serves as a base for obtaining the important facts for implementing the
decision-making.
 It forms the basis for all the planning activities.
 PERT helps management in deciding the best possible resource utilization
method.
 PERT take advantage by using time network analysis technique.
 PERT presents the structure for reporting information.
 It helps the management in identifying the essential elements for
the completion of the project within time.
 It specifies the activities that from the critical path.
 It describes the probability of completion of project before the specified date.
 It describes the dependencies of one or more tasks on each other.
 It represents the project in graphical plan form.
Advantages of PERT Chart
It has the following advantages:
 Estimation of completion time of project is given by the PERT.
 It supports the identification of the activities with slack time.
 The start and dates of the activities of a specific project is determined.
 It helps project manager in identifying the critical path activities.
 PERT makes well organized diagram for the representation of large amount of
data.
Disadvantages of PERT Chart
It has the following disadvantages:
 The complexity of PERT is more which leads to the problem in
implementation.
 The estimation of activity time are subjective in PERT which is a major
disadvantage.
 Maintenance of PERT is also expensive and complex.
 The actual distribution of may be different from the PERT beta distribution
which causes wrong assumptions.
 It under estimates the expected project completion time as there is chances
that other paths can become the critical path if their related activities are
deferred.

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.

find the critical path in a project:

 Step 1: Identify all tasks required to complete the project
 Step 2: Determine the sequence of tasks
 Step 3: Estimate the duration of each task
 Step 4: Draw a network diagram
 Step 5: Identify the critical path
 Step 6: Calculate the float
 Step 7: Monitor the critical path

The table given below contains the activity label, its respective duration (in
weeks), and its precedents. We will use the critical path method to find the
critical path and activities of this project.

Activity Duration (in weeks) Precedents

A 6 -

B 4 -
 Activity Duration (in weeks) Precedents

C 3 A

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 Representation:

 Activity label is the name of the activity represented by that node.

 Earliest Start is the date or time at which the activity can be started at the
earliest.
 Earliest Finish is the date or time at which the activity can be completed at the
earliest.
 Latest Start is the date or time at which the activity can be started at the latest.
 The latest Finish is the date or time at which the activity can be finished at the
latest.
 Float is equal to the difference between the earliest start and latest start or
earliest finish and latest finish.
Activity-On-Node diagram:

Generalized Activity Normalization Time Table (GANTT)

Chart: is type of chart in which series of horizontal lines are present that show
the amount of work done or production completed in given period of time in
relation to amount planned for those projects. It is horizontal bar chart developed
by Henry L. Gantt (American engineer and social scientist) in 1917 as production
control tool. 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 Gantt chart is to emphasize scope of individual tasks. Hence set
of tasks is given as input to Gantt chart. Gantt chart is also known as timeline
chart. It can be developed for entire project or it can be developed for individual
functions. In most of projects, after generation of timeline chart, project tables are
prepared. In project tables, all tasks are listed in proper manner along with start
date and end date and information related to it.

Gantt 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.
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.
Disadvantages :
 Sometimes, using Gantt chart makes project more complex.
 The size of bar chart dost not necessarily indicate amount of work done in
project.
 Gantt charts and projects are needed to be updated on regular basis.
 It is not possible or difficult to view this chart on one sheet of paper. The
software products that produce Gantt chart needed to be viewed on computer
screen so that whole project can be seen easily.

Applications :
There are several professions, where use of gantt chart is very beneficial. Some of
them are given below:
 Advertising Manager -
Advertising Managers generally controls and supervises end result of
advertising companies, scheduling advertisements in different media, etc.

 Operations Manager -
Operations Managers generally control and handle resources that are essential
for company operations.

 Project Manager -
Project Managers generally motivates project teams, collaborate with team
members, schedule task and complete that on time, and report to stakeholders,
etc.

Example :
Nowadays, there are many companies and teams that use Gantt chart to plan,
schedule, and execute their projects. Some of them are consulting agencies,
manufacturing companies, Marketing teams, Construction companies, etc. Below
is an example of Gantt chart:
Technical Review : In a review i.e. also known as technical review, a work
product is especially examined for defects by several individuals other than the
person who actually produced it. In this, work product is defined as an essential
and important deliverable that is created during requirements, design, coding, or a
testing phase of software development.

Software Inspection : These are considered as the most formal type of

review. These are usually conducted after artifact fulfills predefined exit criteria
(like a particular requirement is implemented).

Difference between Software Inspection and Technical Review :

Issue Technical Review Software Inspection

It usually determines the

suitability i.e. the quality of
It usually determines the
being right of a work product for
suitability i.e. the quality of being
Objective its intended use. But beyond
right of a work product for its
that, it also searches for
intended use.
anomalies i.e. unexpected results
by examination through
Issue Technical Review Software Inspection

educated inspectors.

In technical review, minimum of

two persons are required for work.
Each of them can perform In inspection, additional roles
different roles. Since the scope is that are required are the Author
Roles different additional persons like and the Reader. The roles are
customer representatives or separated explicitly and can not
management representatives can be assumed by one person.
participate, but this is never
regarded as a role in the process.

Inspection reporting forms,

Hardware performance data,
Inspection checklists, all of
these are additional inputs and
some of these inputs are optional
The inputs are mostly similar to also. The reporting form and
that of the inspection. It is needed inspection checklist are
Input
to be observed that checklists are mandatory but hardware product
not mentioned i.e. not required. specification is optional. The
wording of the standard usually
suggests that checklists are not
mandatory, but a table in the
appendix of standard makes
them mandatory.

Formal inspection report, formal

defect summary, and a defect list
along with classified defects are
Action Item List and a record of
the outputs. The main emphasis
Output the technical review are the only
is only on providing a standard
output.
output of errors that are found
which also might allow
statistical evaluations.
 Issue Technical Review Software Inspection

In this, it is explicitly stated that

Entry the meeting usually needed to be
Criteria for In this, no special criteria are re-scheduled if the inspection
the mentioned. leader somehow finds out that
Meeting the participants are not really
prepared well.

Defined roles need to be kept

explicitly. The material will be
Described rules of a review
Meeting presented by the reader and not
meeting are usually kept.
the author. The other roles are
also needed to kept formally.

The decision is needed to be

made simply to accept the work
product, close the inspection,
Outcome Defined review report is being
but usually require a rework,
of the generated as the outcome of the
reject the work product, and
Meeting meeting.
require a re-inspection after the
rework is done at the end of the
inspection.

Project scheduling:

A schedule in your project's time table actually consists of sequenced activities and
milestones that are needed to be delivered under a given period of time. Project
schedule simply means a mechanism that is used to communicate and know about
that tasks are needed and has to be done or performed and which organizational
resources will be given or allocated to these tasks and in what time duration or time
frame work is needed to be performed. Effective project scheduling leads to success
of project, reduced cost, and increased customer satisfaction. Scheduling in project
management means to list out activities, deliverables, and milestones within a
project that are delivered. It contains more notes than your average weekly planner
notes. The most common and important form of project schedule is Gantt chart.

Process : The manager needs to estimate time and resources of project while
scheduling project. All activities in project must be arranged in a coherent sequence
that means activities should be arranged in a logical and well-organized manner for
easy to understand. Initial estimates of project can be made optimistically which
means estimates can be made when all favorable things will happen and no threats or
problems take place. The total work is separated or divided into various small
activities or tasks during project schedule. Then, Project manager will decide time
required for each activity or task to get completed. Even some activities are
conducted and performed in parallel for efficient performance. The project manager
should be aware of fact that each stage of project is not problem-free. 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.
The project schedule is represented as set of chart in which work-breakdown
structure and dependencies within various activities are represented. 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.
 Advantages of Project Scheduling : There are several advantages provided by
project schedule in our project management:

 It simply ensures that everyone remains on same page as far as tasks get
completed, dependencies, and deadlines.
 It helps in identifying issues early and concerns such as lack or unavailability of
resources.
 It also helps to identify relationships and to monitor process.
 It provides effective budget management and risk mitigation.

Milestones :
 Planning & Analysis: Project Kick-off, Requirements Gathering Complete, Feasibility Study
Approved.

 Design: System Design Sign-off, UI/UX Wireframes Approved, Database Schema Finalized.

 Development (Implementation): First Working Prototype, Core Feature Set Complete, Key
Integrations (e.g., Payment Gateway) Done, Alpha Release.

 Testing: Unit Testing Complete, Integration Testing Passed, User Acceptance Testing (UAT)
Sign-off, Beta Release.

 Deployment: Application Deployed to Production, Go-Live.

 Post-Launch: Post-Deployment Review, First Major Update (v1.1) Ready.

Purpose of Milestones
 Track Progress: Signal significant progress to stakeholders and management.

 Risk Management: Help identify bottlenecks and potential delays early.

 Decision Points: Indicate when reviews, approvals, or resource shifts are needed.

 Motivation: Provide smaller, achievable goals, reducing stress and boosting team morale.

 Deliverable Markers: Often coincide with the delivery of key project outputs.