Management Spectrum:

-->
Effective software project management focuses on the four P’s: people, product,
process, and project.
People:
- Focus on your team: Train, communicate, and support them well.
- Use models like People CMM to improve how you attract, develop, and retain your
workforce.
Product:
- Know what you want to achieve with your product and define its scope before
starting the project. This helps in realistic planning and progress tracking.
- Consider alternative solutions and identify constraints to accurately estimate
costs, assess risks, and plan tasks and schedules.
Process:
- Have a clear plan for developing your software, breaking it down into manageable
tasks. This keeps things organized and ensures everyone knows what to do.
- Adapt your development framework to fit your project's characteristics and team
needs, incorporating quality assurance and configuration management throughout.
Project:
- Plan and control your software project carefully to manage its complexity
effectively.
- Learn from past mistakes and understand what makes projects succeed to avoid
failure.
- Develop a common-sense approach to planning, monitoring, and controlling your
project.

Metrics for Size Estimation:

Line of Code(LOC):
This metric is very popular because it is the simplest to use.
Using this metric, the project size is estimated by counting the number of source
instructions in the developed program.
Obviously, while counting the number of source instructions, lines used for
commenting the code and the header lines should be ignored.
Estimation is dependent on programming language. For different programming language
lines of code will vary.

Ex:
In this example, the size estimation for a mechanical CAD software is based on
dividing the software into major functions and estimating the lines of code (LOC)
for each function.
Function Estimated LOC
User interface 500
2D Geometric Analysis 1,000
3D Geometric Analysis 1,500
Database Management 800
Graphics Display 1,200
Peripheral Control 400
Design Analysis 2,000
Total Estimated LOC 7,400

Line of code metrics for size estimation: LOC count the total number of lines of
source code in a project.
The units of LOC are:
KLOC- Thousand lines of code
NLOC- Non-comment lines of code
KDSI- Thousands of delivered source instruction
The size is estimated by comparing it with the existing systems of the same kind.
The experts use it to predict the required size of various components of software
and then add them to get the total size.
Parameters to count LOC:
1. count only executable lines.
2. count executable lines plus data definitions.
3. count executable lines, data definitions and comments.
4. count physical lines on input screen.
Consider the following example for counting LOC:
KCSI: thousands changed source instructions.
KSSI: thousands shipped source instructions.
First Release of Product Y
KCSI = KSSI = 50 KLOC
Defects/KCSI = 2.0
Total number of defects = 2.0 × 50 = 100
Second Release,
KCSI = 20
KSSI = 50+ 20 (new and changed lines of code) -4 (assuming 20% are changed lines of
code) = 66
Defect/KCSI = 1.8 (assuming 10% improvement over the first release).
Total number of additional defects = 1.8 x 20 = 36.
Third Release,
KCSI=30
KSSI = 66+30 (new and changed lines of code) -6 (assuming 20% of changed lines of
code) = 90.
Targeted number of additional defects (no more than previous release) = 36.
Defect rate target for the new and changed lines of code: 36/30= 1.2 defects/KCSI
or lower.

Advantages:
1)Universally accepted and is used in many models like COCOMO.
2)Estimation is closer to the developer’s perspective.

Disadvantages:
1)Different programming languages contain a different number of lines.
2)No proper industry standard exists for this technique.
3)It is difficult to estimate the size using this technique in the early stages
of the project.

Function Point(FP):
Function Point (FP) is a metric that simplifies software size estimation. Here's a
simplified explanation:

- The size of a software product depends on the number of functions or features it

has. More features mean a larger size.
- Each function takes input and produces output.
- For example, in a Library Automation Software, the "issue book" feature takes the
book's name as input and displays its location and available copies.
- Counting input and output data values gives an indication of the number of
functions.
- Besides functions, size also depends on files and interfaces.
- Function Point is computed in two steps:
1. Calculate the Unadjusted Function Point (UFP) using the counts of inputs,
outputs, inquiries, files, and interfaces.
2. Adjust the UFP using a Technical Complexity Factor (TCF), considering factors
like transaction rates and response time requirements.
- TCF refines UFP by summing up the influence of 14 factors. The resulting sum
determines TCF, which varies from 0.65 to 1.35.
- Finally, FP is calculated as the product of UFP and TCF.

Project Cost Estimation.

Software cost estimation is the process of predicting the effort required to
develop a software system. Project cost estimating is the
process of predicting the total cost of the tasks, time, and resources required to
deliver a project's scope of work. There are three
approaches of project estimation, they are:
i) Heuristic
ii) Analytical
iii) Empirical

i) Heuristic:

Heuristic cost estimation is about learning from past projects to estimate cost for
new ones. It involves finding similar previous projects and adjusting for
differences. There are two types: single variable and multi variable models.

Single variable model:

- These estimates project's characteristics based on one known aspect, like size.
- Formula: Estimated Parameter= c1 * ed1
- Example : COCOMO
- Constants( c1 and d1) are derived from past project.

Multi variable model:

- These estimates project's characteristics based on multiple aspects.
- Formula: Estimated Parameter = c1 *e1d1+c2 * e2d2+...
- Constants(c1,c2,d1,d2) are derived from past project.
- It tends to be more accurate as it considers several project aspects, which
influence cost differently.

ii) Analytical:

Analytical estimation techniques start with basic assumptions about a project,

unlike empirical or heuristic methods. They have a scientific basis. Halstead’s
software science is an example. It uses simple assumptions to derive results,
particularly useful for estimating software maintenance efforts. It's more
effective than empirical and heuristic techniques for predicting such efforts.
Halstead's Software Science measures size, development effort, and cost of software
products using primitive program parameters to calculate program length, potential
value, volume, effort, and development time.

Example:
Let us consider the following C program:
main( )
{
int a, b, c, avg;
scanf(“%d %d %d”, &a, &b, &c);
avg = (a+b+c)/3;
printf(“avg = %d”, avg);
}
The unique operators are: main,(),{},int,scanf,&,“,”,“;”,=,+,/, printf
The unique operands are: a, b, c, &a, &b, &c, a+b+c, avg, 3, “%d %d %d”,
“avg = %d”
Therefore, n1 = 12, n2 = 11
Estimated Length = (12*log12 + 11*log11)
=(12*3.58 + 11*3.45)
=(43+38) = 81
Volume = Length*log(23)
=81*4.52
=366
iii) Empirical:
- Empirical estimation uses past data to guess project details.
- It's based on previous projects and educated assumptions.
- Software size helps estimate how much effort is needed.
- It's like making an educated guess based on experience.
- Experience with similar projects helps make better guesses.
- Over time, it's become more structured in its approach.