SEWDL

MODULE 4
Syllabus content
• Management Spectrum
• 4Ps (people, product and process)
• Process and Project metrics
• Software Project Estimation:
• LOC,
• FP,
• Empirical Estimation Models - COCOMO Model,
• Project scheduling:
• WBS,
• Defining a Task Set for the Software Project,
• Timeline charts,
• Tracking the Schedule
Management Spectrum
• Software engineering involves the systematic design, development, testing,
and maintenance of software systems.
• Effective management is crucial to ensure the success of software projects.
• The management spectrum in software engineering covers various aspects,
including project management, team management, and process
management.
• successful software engineering management requires a combination of
technical expertise, interpersonal skills, and a deep understanding of the
software development process.
• Different methodologies and approaches can be combined to create a
management strategy that aligns with the specific needs of the project and
the organization.
Effective software project management focuses on the four Ps: people,
product, process, and project.

The order is not arbitrary.

By addressing these four areas holistically, project managers can create

a well-rounded management strategy that covers the essential aspects
of software project development.
Balancing these dimensions requires effective communication,
collaboration, and coordination among team members, stakeholders,
and project management.
People:
• This aspect focuses on managing the human
resources involved in the project.

• It includes activities such as defining roles

and responsibilities, assembling the right
team with the required skills, fostering a
collaborative and motivating work
environment, providing training and
professional development opportunities,
and addressing any interpersonal or team-
related challenges.
Product:
• Managing the product aspect involves defining,
designing, and delivering the software product
that meets the stakeholders' requirements and
expectations.
• This includes tasks such as gathering and
prioritizing requirements, creating a detailed
design, ensuring proper coding and testing
practices, and validating that the final product
aligns with the intended functionality and quality
standards.
Process:
• The process dimension focuses on defining and
optimizing the software development processes used
throughout the project's lifecycle.
• This involves selecting an appropriate development
methodology (such as Agile, Waterfall, or hybrid
approaches), establishing coding standards,
implementing version control systems, setting up
testing practices, and ensuring that the team follows
best practices for efficient and high-quality
development.
Project:
• Managing the project itself involves the
traditional project management activities. This
includes planning the project's scope, defining
milestones and deliverables, estimating
resources and timeframes, creating a project
schedule, monitoring progress, identifying and
mitigating risks, and ensuring that the project
stays on track and within budget.
• Effective project management ensures that the
project's goals are achieved while managing
constraints and changes.
 • Barry Boehm's "W5HH" principle is a concept used in software
project management to guide the gathering and clarification of
requirements.
• The principle is a mnemonic that stands for "Who, What, When,
Barry Where, Why, How, How Much."
• It serves as a checklist of essential questions to ensure that project
Boehm's requirements are well-defined and thoroughly understood before
the development process begins. Here's what each part of the
"W5HH" principle entails:

principle • Who:
• This question refers to the stakeholders or users who will interact
with the software. It's important to identify the people or groups
that the software will serve and consider their specific needs, roles,
and responsibilities.
• What:
• What functionalities and features does the software need to
provide? Defining the specific requirements and desired outcomes is
crucial to understanding what the software should accomplish.
• When:
• This question refer to to the timeline and deadlines for the
project. Understanding the time constraints helps in setting
realistic expectations and planning the development process
accordingly.

• Where:
• Where will the software be used? Whether it's a web
application, desktop software, or mobile app, the platform and
environment can impact design and functionality
considerations.

• Why:
• Understanding the underlying reasons for developing the
software helps in aligning the project with the overall goals and
objectives. It ensures that the project's purpose is clear and
justified.
• How:
• How will the software be developed? This question
relates to the technical aspects, development
methodologies, tools, and technologies that will be used
to build the software.

• How Much:
• This question is about the budget and resources required
for the project. It involves estimating costs, resources,
and potential risks associated with the development
process.
Process and Project Metrics
• Process metrics are collected across all projects and over
long periods of time. Their intent is to provide a set of
process indicators that lead to long-term software
process improvement

• Project metrics enable a software project manager to (1)

assess the status of an ongoing project, (2) track
potential risks, (3) uncover problem areas before they go
“critical,” (4) adjust work flow or tasks, and (5) evaluate
the project team’s ability to control quality of software
work products.
Need of Process and Project Metrics
• Project and process metrics are essential in software engineering for a
variety of reasons, all aimed at improving the development process,
ensuring project success, and delivering high-quality software
products.
• project and process metrics are necessary tools in software
engineering for effective project management, quality assurance, risk
mitigation, decision-making, and continuous improvement.
• They enable organizations to deliver software products on time,
within budget, and with the desired level of quality while
continuously optimizing their development processes.
Software measurement
• s/w measurement is an ability to measure attributes of s/w and s/w
development process so that the s/w engineering activities can be
improves
• Software measurement is the process of quantitatively assessing various
attributes of a software product, software development process, or
software project.
• It involves the collection, analysis, and interpretation of data to better
understand and manage software-related activities.
• The primary goal of software measurement is to provide objective and
actionable information for decision-making, process improvement, and
quality assurance in the field of software engineering.
Software measurement

Direct measure
Cost and efforts , line of
code ,Execution speed and
Software defects

measurement Indirect measure

Functionality, quality,
Reliability, Efficiency,
maintainability , complexity
Size-Oriented Metrics
• Size-oriented software metrics are a category of metrics used in
software engineering to measure various aspects of a software
system's size or complexity.
• These metrics focus on quantifying the size of the software in
terms of lines of code, number of modules, or other related
measures.
• Size-oriented metrics provide insights into the software's
overall complexity, potential maintenance efforts, and potential
risks.
Lines of Code (LOC)
• Lines of Code (LOC) is one of the simplest and
most widely used size-oriented software
metrics.
• It measures the total number of lines of source
code in a software module, program, or system.
• While it's a straightforward metric to calculate,
it has its limitations and should be used
alongside other metrics for a more
comprehensive understanding of software
complexity and quality.
 • Disadvantages:
• Advantages:

• Doesn't Account for Complexity: LOC doesn't

• Simple and Easy to Measure: consider the complexity of the code or the logic
Calculating LOC is relatively involved. Two pieces of code with the same LOC
easy and doesn't require count might have different complexities.
complex tools or analysis. • Language Dependency: Different programming
• Common Baseline: It provides a languages have varying syntax and conventions,
common baseline for which can affect LOC counts. This makes cross-
comparing the size of different language comparisons less meaningful.
software components or • Code Duplication: LOC doesn't distinguish between
projects. original code and duplicated code. Duplicated code
can inflate the LOC count without adding real value.
• Quick Estimations: LOC can be
used for quick estimations of • Focus on Quantity over Quality: Emphasizing LOC
development effort and project can lead to "code bloat," where developers
prioritize writing more code rather than writing
timelines.
efficient, maintainable code.
Function Points (FP)
• Function Points (FP) is a size-oriented software metric used to measure the
functional size of a software application based on the functionality it delivers to
users.
• It's designed to provide a more comprehensive view of a software system's size
and complexity compared to simple metrics like lines of code (LOC).
• FP quantifies the software's value from the user's perspective rather than just its
implementation details.
• Function Points take into account various aspects of the software's functionality,
such as inputs, outputs, inquiries, files, and external interfaces.
• These aspects are classified and assigned weights based on their complexity.
• The final Function Point count is calculated by summing the weighted values of
these different aspects.
Counting Components:
• External Inputs (EI): These are user inputs that affect the behavior of the
software. Each input is counted and assigned a complexity weight.
• External Outputs (EO): These are user-visible outputs produced by the software.
Each output is counted and assigned a complexity weight.
• External Inquiries (EQ): These are user-initiated inquiries that require the
software to retrieve information. Each inquiry is counted and assigned a
complexity weight.
• Internal Logical Files (ILF): These are logical groupings of data maintained by the
software. Each logical file is counted and assigned a complexity weight.
• External Interface Files (EIF): These are external data or control interfaces used by
the software. Each interface file is counted and assigned a complexity weight.
Measurements Parameters Examples

1.Number of External Inputs(EI) Input screen and tables

2. Number of External Output (EO) Output screens and reports

3. Number of external inquiries (EQ) Prompts and interrupts.

4. Number of internal files (ILF) Databases and directories

5. Number of external interfaces (EIF) Shared databases and shared routines.

Calculate Unadjusted Function Point
(UFP).
 Calculating Adjusted
Function Point
• value adjustment factor ( VAF) which is used as a multiplier of the
unadjusted function point count in order to calculate the adjusted
function point ( AFP) count of an application

0 - No Influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential
24
• Evaluate the 14 GSCs on a
scale of 0–5 to determine
the DI for each GSC
description.
• Add the DIs for all 14 GSCs
to produce the total degree
of influence (TDI).
• Use the TDI in the following
equation to compute VAF.
• VAF = (TDI × 0.01) + 0.065
• The final adjusted function
point is calculated as,
• AFP = UFP × VAF
25
Function Points provide several
benefits:
• User-Centric: Function Points focus on the functionality that users
interact with, making them valuable for estimating user satisfaction
and value.
• Language Independence: Unlike LOC, Function Points are independent
of programming language and coding style, making them suitable for
comparing projects in different languages.
• Estimation: Function Points can be used for estimating development
effort, project timelines, and resource allocation.
• Performance Measurement: By tracking Function Points delivered over
time, development productivity and project success can be assessed.
Functional Point Line of Code

A measure of the software's functionality A measure of the size of the source code,
based on user requirements and features. typically in terms of lines, statements, or
instructions.

It is measured in function points, which It is measured in lines, such as source lines

represent units of functionality. of code (SLOC) or physical lines of code.

It is less dependent on the programming It is highly dependent on the programming

language used, as it's based on language, as different languages have
functionality. varying levels of conciseness.

It focuses on what the software does from a It focuses on the physical size and
user's perspective and its functionality. complexity of the codebase.
COCOMO Model
• Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number of
Lines of Code.
• It is a procedural cost estimate model for software projects and is often used as a
process of reliably predicting the various parameters associated with making a
project such as size, effort, cost, time, and quality.
• It was proposed by Barry Boehm in 1981 and is based on the study of 63 projects,
which makes it one of the best-documented models.
• The key parameters which define the quality of any software products, which are also
an outcome of the Cocomo are primarily Effort & Schedule:
• Effort: Amount of labor that will be required to complete a task. It is measured in person-
months units.
• Schedule: Simply means the amount of time required for the completion of the job, which is, of
course, proportional to the effort put in. It is measured in the units of time such as weeks, and
months.
• 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.
• 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
environment lie in between that of organic and Embedded. The projects classified as
Semi-Detached are comparatively less familiar and difficult to develop compared to the
organic ones and require more experience and better guidance and creativity. Eg:
Compilers or different Embedded Systems can be considered Semi-Detached types.
• Embedded – A software project requiring the highest level of complexity, creativity, and
experience requirement fall under this category. Such software requires a larger team
size than the other two models and also the developers need to be sufficiently
experienced and creative to develop such complex models.
• In short-
• Organic
• Relatively small , simple s/w project
• Small teams
• Good application experience to less rigid requirements
• Semidetached
• Mixed experience levels
• Mix of rigid and less than rigid requirements
• Embedded
• Project with tight h/w , s/w , operational constraints
Basic COCOMO model
• Estimation done using line of code
• E = ab (KLOC) bb
• D = cb (E) db
• P=E/D
• Where,
• E is efforts in person month
• D is development time in months
• KLOC is kilo line of code
• 1 KLOC = 1000 LOC
• P is total no of person required to accomplish project
For the coefficients ab ,bb ,cb ,db For three modes are as below

s/w projects ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
• Estimation of development EFFORT
• Organic : Effort = 2.4(KLOC) 1.05 PM
• Semi-detached : Effort = 3.0(KLOC) 1.12 PM
• Embedded : Effort = 3.6(KLOC) 1.20 PM

• Estimation of development TIME

• Organic : D = 2.5(Effort) 0.38 Months
• Semi-detached : D = 2.5(Effort)0.35 Months
• Embedded : D = 2.5(Effort) 0.32 Months
Total persons required= E/D
• Using cocomo estimate time for
following
1. Organic 100,000 LOC
2. Semidetached 2000 LOC
3. Embedded 30,000 LOC
Calculate effort , time , total persons
required
Intermediate COCOMO
• It is an extension to basic COCOMO model.
• This estimation model makes use of set of “cost driver attributes” to
compute cost of software.
• Effort multipliers for each cost driver is as given in following table.
• The product of all multipliers result in “effort adjustment factor”(EAF)
• The basic COCOMO model assumes that effort and development time
are functions of the product size alone.
• However, a host of other project parameters besides the product size
affect the effort required to develop the product as well as the
development time.
• Therefore, in order to obtain an accurate estimation of the effort and
project duration, the effect of all relevant parameters must be taken
into account.
• The intermediate COCOMO model recognizes this fact and refines the
initial estimate obtained using the basic COCOMO expressions by
using a set of 15 cost drivers (multipliers) based on various attributes
of software development.
• In general, the cost drivers can be classified as being attributes of the following
items:
• Product: include the inherent complexity of the product, reliability
requirements of the product, etc.
• Computer: include the execution speed required, storage space required etc.
• Personnel: include the experience level of personnel, programming capability,
analysis capability, etc.
• Development Environment: Development environment attributes capture the
development facilities available to the developers. An important parameter that
is considered is the sophistication of the automation (CASE) tools used for
software development.
• Formula for effort calculation can be
E= ai (KLOC) bi * EAF
• The duration and person estimate values are same as in Basic
COCOMO

• Values for ai and bi for various classes of s/w project are –

Software ai bi
project
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
• Consider a project having 30000 LOC which is an embedded s/w
with critical area hence reliability is high.
• The estimation can be
• E= ai (KLOC) bi * EAF
as reliblity is high , EAF = 1.15(product attribute)
Ai =2.8
Bi =1.20
E = 2.8 (30) 1.20 * 1.15
= 191 pm
D = Cb (E) db
= 2.5 (191)0.32
= 13 months
P = E/D =191 / 13 =15 persons
Complete COCOMO
• It uses same equations for estimations as intermediate model but
detailed model can estimate E,D,P of each of development phases,
subsystems , modules
• The experimentation with different development strategies is allowed
in this model
 • The 4 phases are
• Requirement planning and product designing (RPD)
• Detailed design (DD)
• Code and unit test (CUT)
• Integrate and test (IT)
• Effort multipliers for detailed COCOMO model are
Phases v.Low Low Nominal High v. High

RPD 1.80 0.85 1.00 0.75 0.55

DD 1.35 0.85 1.00 0.90 0.75

CUT 1.35 0.85 1.00 0.90 0.75

IT 1.50 1.20 1.00 0.85 0.70

Advantages of the COCOMO model:

• Provides a systematic way to estimate the cost and effort of a

software project.
• Can be used to estimate the cost and effort of a software project at
different stages of the development process.
• Helps in identifying the factors that have the greatest impact on the
cost and effort of a software project.
• 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:
• 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.
• 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.
• Does not provide a precise estimate of the cost and effort of a
software project, as it is based on assumptions and averages.
• For a project of 2000KLOC of semi detached type project with highly
capable programmers(0.86) , with high reliability(1.15) and moderate
use of software tools(1.00)
• calculate efforts, time, no.of people required
• Calculate cost of project based on efforts if salary of person is Rs.
15000/month
Assume the size of an organic type
software product has been estimated to
50000LOC.
Assume the average salary of Software
engineer is Rs. 10000 per month.
Determine the cost and effort required to
develop the software and nominal
development time.
 Assume the size of an organic type software product has been
estimated to 50000LOC.
Assume the average salary of Software engineer is Rs. 10000 per
month.
Determine the cost and effort required to develop the software
and nominal development time.
• Given = 50000 LOC = 50KLOC , Salary of Employee = Rs. 10000
• Effort = 2.4(KLOC) 1.05 per-month
• Development time = 2.5(Effort) 0.38 months
• The given software type is organic hence
• Effort = 2.4(50) 1.05 person month = 146person- month
• Development time = 2.5(146) 0.38 months = 16.61=17 months
• Number of person required for development = Effort/Development time =
146/17 = 8.5= 9 persons
• Cost Required = Development time * Salary of employee per month * no. of
persons = 17 * 10000 * 9 = Rs. 1530000
 WBS
 A work breakdown structure is a key project deliverable that
organizes the team's work into manageable sections.
 The Project Management Body of Knowledge (PMBOK) defines
the work breakdown structure as a "deliverable oriented
hierarchical decomposition of the work to be executed by the
project team."
 The work breakdown structure (WBS) is a useful tool for
developing the project plan and links the project’s scope to the
schedule and budget.
 WBS
 The work breakdown structure visually defines the scope
into manageable chunks that project team can
understand, as each level of the work breakdown
structure provides further definition and detail.
 It is an outline of what work is to be performed.
 In WBS, much larger tasks are broken down to
manageable chunks of work.

54
 WBS
 In the process of breaking down the tasks, one can break them
down into different levels of detail.
 One can detail a high-level task into ten sub-tasks while
another can detail the same high-level task into 20 sub-
tasks.
 These chunks can be easily supervised and estimated.

SPM PPT - compiled by Prof.Deepali S 55

 Work
Packages
 The WBS decomposes, or subdivides, the project into smaller
components and more manageable units of work called work
packages.
 Work packages provide a logical basis for defining the
project activities and assigning resources to those
activities so that all the project work is identified.
 A work package makes it possible to develop a project plan,
schedule, and budget and then later monitor the project’s
progress. SPM PPT - compiled by Prof.Deepali S 56
 work
package
 A work package may be
viewed as a hierarchy that
starts with the project itself.
 The project is then
decomposed into
phases,
 with each phase having one
or more deliverables as
defined in the deliverable
definition table and
deliverable structure chart.

SPM PPT - compiled by Prof.Deepali S 57

 Deliverables and
Milestones
 A milestone is a significant event or achievement that provides
evidence that that deliverable has been completed or that a phase is
formally over.
 Deliverables and milestones are closely related, but they are not the
same thing.
 Deliverables can include such things as presentations or

• reports, plans, prototypes, and the final application system.

 A milestone, on the other hand, must focus on an achievement.
 Milestones can keep the project team focused.
 Milestones also reduce the risk of a project.
 Milestones can also provide a mechanism for quality control.

SPM PPT - compiled by Prof.Deepali S 58

The 100% Rule for a Work
Breakdown Structure
 The 100% Rule is an essential part of
work breakdown structure methodology.
 Applying the 100% Rule, the top level of a
work breakdown structure is the totality of
the project, and lower levels categorize
greater detail in a top-down structure
under the first level.

SPM PPT - compiled by Prof.Deepali S 59

 WBS-
RULES
 In general, there are a few "rules" used for
determining the smallest task chunk.
 In "two weeks" rule, nothing is broken down smaller
than two weeks worth of work.
 This means, the smallest task of the WBS is at least two-
week
long.
 8/80 is another rule used when creating a WBS.
 This rule implies that no task should be smaller than 8 hours
of work and should not be larger than 80 hours of work.

SPM PPT - compiled by Prof.Deepali S 60

SPM PPT - compiled by Prof.Deepali S 61
What is a Gantt Chart?
• A Gantt chart, commonly used in project management,
is one of the most popular and useful ways of showing
activities (tasks or events) displayed against time.
• On the left of the chart is a list of the activities and
along the top is a suitable time scale.
• Each activity is represented by a bar; the position and
length of the bar reflects the start date, duration and
end date of the activity.