Software Project Spectrum

• In software engineering, the management spectrum

describes the management of a software project.
• The management spectrum focuses on the four P’s;
people, product, process and project. Here, the
manager of the project has to control all these P’s to
have a smooth flow in the progress of the project and
to reach the goal.
• The four P’s of management spectrum are
• People
• Product
• Process
• Project
 Software Project Spectrum

A. People
• The most important component of a product and
its successful implementation is human resources.
• In building a proper product, a well-managed team
with clear-cut roles defined for each person/team
will lead to the success of the product.
• We need to have a good team in order to save our
time, cost, and effort.
• Some assigned roles in software project planning
are project manager, team leaders, stakeholders,
analysts, and other IT professionals.
 Software Project Spectrum

• B. Product
As the name inferred, this is the deliverable or the
result of the project.
• The project manager should clearly define the
product scope an objective to ensure a successful
result.
• Also need to consider technical, management
constraint as well as consider alternate solution of
the product.
• Without all this information it is impossible to
define or calculate accurate estimate of the cost,
budget or efforts.
 Software Project Spectrum

C.Process
-In every planning, a clearly defined process is the
key to the success of any product.
-It regulates how the team will go about its
development in the respective time period.
-The Process has several steps involved like,
documentation phase, implementation phase,
deployment phase, and interaction phase.
-process involves a number of different task,
milestone, work products and quality assurance
point.
 Software Project Spectrum

D. The Project:-
• In this phase, the project manager plays a critical
role.
• They are responsible to guide the team members
to achieve the project’s target and objectives,
helping & assisting them with issues, checking on
cost and budget, and making sure that the project
stays on track with the given deadlines.
 Metrics Size Estimation

• Estimation of the size of the software is an essential part

of Software Project Management.
• It helps the project manager to further predict the effort
and time which will be needed to build the project.
• Various measures are used in project size estimation.
Some of these are:

• Lines of Code
• Number of entities in ER diagram
• Total number of processes in detailed data flow diagram
• Function points
 Metrics Size Estimation

1. Lines of Code (LOC): As the name suggests, 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.
 Metrics Size Estimation

• It’s tough to estimate LOC by analyzing the problem definition.

• Only after the whole code has been developed can accurate LOC be
estimated.
• This statistic is of little utility to project managers because project
planning must be completed before development activity can begin.
• Advantages:
Universally accepted and is used in many models like COCOMO.
• Estimation is closer to the developer’s perspective.
• Simple to use.
• Disadvantages:
Different programming languages contain a different number of
lines.
• No proper industry standard exists for this technique.
• It is difficult to estimate the size using this technique in the early
stages of the project.
 Metrics Size Estimation

2.Function Point Analysis: In this method, the number

and type of functions supported by the software are
utilized to find FPC(function point count).
It is not possible to measure the functionality directly.
Hence using other direct measures, it is necessary to
derive it indirectly.
• Function points are basically derived with the help of
an empirical relationship depending upon countable
(direct) measures regarding the information domain
of software and software complexity assessments.
 Metrics Size Estimation

• Five information domain characteristics are

determined and counts are provided. These are as
follow
- External Inputs: Functions related to data
entering the system.
– External outputs: Functions related to data exiting the
system.
– External Inquiries: They lead to data retrieval from the
system but don’t change the system.
– Internal Files: Logical files maintained within the system.
Log files are not included here.
– External interface Files: These are logical files for other
applications which are used by our system.
 Metrics Size Estimation

Once these data have been collected, a complexity value is

associated with each count. Organizations that use function point
methods develop criteria for determining whether a particular entry
is simple, average, or complex. Nonetheless, the determination of
complexity is somewhat subjective.
 Metrics Size Estimation

• To compute function points (FP), the following

relationship is used:
• FP=count total [0.65+0.01 E(Fi)]
• (where count total is the sum of all FP entries)
• The Fi (i = 1 to 14) are "complexity adjustment
values" depending upon responses to the
following given fourteen questions: 1. Does there
is need of reliable backup and recovery to the
system? 2. Is there any requirement of
communications? 3. Are there distributed
processing functions? 4. Is performance critical?
 Cocomo model

• COCOMO-II is the revised version of the original

Cocomo (Constructive Cost Model)
• It is the model that allows one to estimate the
cost, effort and schedule when planning a new
software development activity.
• The first level presented an original rough
estimate .
• The second level modifies this using a several
project and process multipliers and the most
detailed level created estimates for different
stages of the project
 Cocomo model

• COCOMO 1 thinks that the software would be

developed according to a waterfall process using
standard programming languages like C.
• To take these modifications into account , the
COCOMO II model identifies different approaches
to software development like prototyping .
• COCOMO II helps in development of a spiral
model and embeds number of sub - models that
create increasingly whole estimates .
Different formula for different type of product
Cocomo model
 Cocomo model

The application - composition model

• It was established into COCOMO II to maintain the
estimation of effort needed for prototyping
projects .
• It depends on an estimate of weighted
application points also called as object points
separated by a standard estimate of application -
point productivity .
• The estimate is then changed according to the
complexity of developing every object point .
• PM=(NAP*(1*%reuse/100)/PROD
 Cocomo model

The early design model

• This model is used at the time of early stages of the system design
after the requirements have been established .
• Estimates are depend on function points , which are then changed
to number of lines of source code .
• Estimates can be completed after the user have been agreed .
• requirement Depend on standard formula for algorithmic models .
• Effort = A x Size B x M
• The multiplier M in COCOMO II is depends simplified collection of
seven projects and process characteristics that influence the
estimate .
• Ex of 7 characteristics are platform difficulty ( PDIF ) , personnel
capability ( PERS ) , personnel experience ( PREX ) . schedule
( SCED ) etc
• M=2.94*SIZE B*M
 Cocomo model

The reuse model:-

• Reuse model is used to calculate the effort needed to integrate
reusable software or program code that are automatically created
by design or program translation tools .
• COCOMO II considers reused code to be of two types . Black - box
code is code that can be reused without knowing the code or
making modification to it .
• The development effort for black - box code is taken to be zero .
Code that has to be adapted to combine it with new code is called
white - box code .
• Some development effort is needed to reuse this because it has to
be known and changed before it can work accurately in the system .
• The formula for effort estimation is : PM Auto = ( ASLOC x AT /
100 ) / ATPROD Where , AT - percentage of adapted code that is
automatically created
 Risk management

• Risk is possibility of suffering loss

• Type of risk
1. Schedule risk:
2. Budget risk
3. Operational risk
4. Technical /functional risk
5.
 RMMM

• Risk Mitigation is a problem avoidance activity ,

• Risk Monitoring is a project tracking activity ,
• Risk Management includes contingency plans that risk will occur .
• The goal of the RMMM plan to identify as many potential risks as
possible .
• Risk is a potential problem it might happen , it might not .
• To determine the potential risks checklists are used .
• These checklists help to identify potential risks in a generic sense .
• The project will then be analyzed to determine any project -
specific risks .
• When all risks have been identified , they will then be evaluated to
determine their probability of occurrence .
• Plan is used to identify risk, track risk.
 RMMM

• The Risk Management:

• The risk management process can be broken down
into two interrelated phases ,
i. risk assessment ii. risk control
• These phases are further broken down .
• Risk assessment involves risk identification , risk
analysis , and risk prioritization .
• Risk control involves risk planning , risk mitigation , and
risk monitoring .
• It is essential that risk management be done iteratively
, throughout the project , as a part of the team's
project management routine .
 RMMM

Risk Mitigation
• Related to risk planning , through risk mitigation , the team
develops strategies to reduce the possibility or the loss impact of
a risk .
• Risk mitigation produces a situation in which the risk items are
eliminated or otherwise resolved .
Risk avoidance :-
• When a lose - lose strategy is likely , the team can opt to eliminate
the risk is an example of a risk avoidance strategy is the team
opting not to develop a product or a particularly risky feature .
Risk protection
The organization can buy insurance to cover any financial loss should
the risk become a reality .
Alternately , a team can employ fault tolerance strategies , such as
parallel processors , to provide reliability insurance . Risk planning and
 RMMM

Risk Monitoring :-
• After risks are identified , analyzed , and prioritized , and actions are
established , it is essential that the team regularly monitor the
progress of the product and the resolution of the risk items , taking
corrective action when necessary .
• This monitoring can be done as part of the team project management
activities or via explicit risk management activities .
• Often teams regularly monitor their " Top 10 risks " . Risks need to be
revisited at regular intervals for the team to reevaluate each risk to
determine when new circumstances caused its probability and / or
impact to change .
• At each interval , some risks may be added to the list and others taken
away . Risks need to be reprioritized to see which are moved " above
the line " and need to have action plans and which move " below the
line " and no longer need action plans .
• A key to successful risk management is that proactive actions are