UNIT - 3 Managing Software Project

Que-1. Enlist and discuss the types of Risks.

A software project can be concerned with a large variety of risks. In order to be adept to
systematically identify the significant risks which might affect a software project, it is
essential to classify risks into different classes. The project manager can then check which
risks from each class are relevant to the project.

There are three main classifications of risks which can affect a software project:

1. Project risks
2. Technical risks
3. Business risks

1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel,
resource, and customer-related problems. A vital project risk is schedule slippage. Since the
software is intangible, it is very tough to monitor and control a software project. It is very
tough to control something which cannot be identified. For any manufacturing program, such
as the manufacturing of cars, the plan executive can recognize the product taking shape.

2. Technical risks: Technical risks concern potential method, implementation, interfacing,

testing, and maintenance issue. It also consists of an ambiguous specification, incomplete
specification, changing specification, technical uncertainty, and technical obsolescence. Most
technical risks appear due to the development team's insufficient knowledge about the
project.

3. Business risks: This type of risks contain risks of building an excellent product that no one
need, losing budgetary or personnel commitments, etc.

Other risk categories

1. 1. Known risks: Those risks that can be uncovered after careful assessment of the
project program, the business and technical environment in which the plan is being
developed, and more reliable data sources (e.g., unrealistic delivery date)
2. 2. Predictable risks: Those risks that are hypothesized from previous project
experience (e.g., past turnover)
3. 3. Unpredictable risks: Those risks that can and do occur, but are extremely tough to
identify in advance.

Que 2 Explain COCOMO model for project estimation

• COCOMO (Constructive Cost Estimation Model) was proposed by Boehm

• According to Boehm, software cost estimation should be done through three stages:
o Basic COCOMO,
o Intermediate COCOMO, and
o Complete COCOMO
Basic COCOMO Model

• The basic COCOMO model gives an approximate estimate of the project parameters
• The basic COCOMO estimation model is given by the following expressions
• Effort=a1+(KLOC)a2 Tdev=b | PM 1*(Effort)b2 Months

• KLOC is the estimated size of the software product expressed in Kilo Lines of Code,
• a1, a2, b1, b2 are constants for each category of software products,
• Tdev is the estimated time to develop the software, expressed in months,
• Effort is the total effort required to develop the software product, expressed in person
months (PMs).

Project a1 a2 b1 b2
Organic 2.5 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

• The effort estimation is expressed in units of person-months (PM)

• It is the area under the person-month plot (as shown in fig.)
• An effort of 100 PM
o does not imply that 100 persons should work for 1 month
o does not imply that 1 person should be employed for 100 months
o it denotes the area under the person-month curve (fig.)

(Figure: Person Month Curve)

• Every line of source text should be calculated as one LOC irrespective of the actual
number of instructions on that line
• If a single instruction spans several lines (say n lines), it is considered to be nLOC
• The values of a1, a2, b1, b2 for different categories of products (i.e. organic,
semidetached, and embedded) as given by Boehm
• He derived the expressions by examining historical data collected from a large
number of actual projects
 • Insight into the basic COCOMO model can be obtained by plotting the estimated
characteristics for different software sizes
• Fig. shows a plot of estimated effort versus product size
• From fig. we can observe that the effort is somewhat superlinear in the size of the
software product
• The effort required to develop a product increases very rapidly with project size

(Figure: Efforts vs Product Size)

• The development time versus the product size in KLOC is plotted in fig.
• From fig., it can be observed that the development time is a sublinear function of the
size of the product
• i.e. when the size of the product increases by two times, the time to develop the
product does not double but rises moderately
• From fig., it can be observed that the development time is roughly the same for all the
three categories of products

(Figure: Development Time vs Size)

• Effort and the duration estimations obtained using the COCOMO model are called as
nominal effort estimate and nominal duration estimate
• The term nominal implies that
 • if anyone tries to complete the project in a time shorter than the estimated duration,
then the cost will increase drastically
• But, if anyone completes the project over a longer period of time than the estimated,
then there is almost no decrease in the estimated cost value

Que 3 Explain Software metrics used for software cost estimation.

Size-Oriented Metrics

• Derived by normalizing (standardizing) quality and/or productivity measures by

considering the size of the software produced
• Thousand lines of code (KLOC) are often chosen as the normalization value
• A set of simple size-oriented metrics can be developed for each project
o Errors per KLOC (thousand lines of code)
o Defects per KLOC
o $ per KLOC
o Pages of documentation per KLOC
• In addition, other interesting metrics can be computed, like
o Errors per person-month
o KLOC per person-month
o $ per page of documentation
• Size-oriented metrics are not universally accepted as the best way to measure the
software process
• Opponents argue that KLOC measurements
o Are dependent on the programming language
o Penalize well-designed but short programs
o Cannot easily accommodate nonprocedural languages
o Require a level of detail that may be difficult to achieve

Function Oriented Metrics

• Function-oriented metrics use a measure of the functionality delivered by the

application as a normalization value
• Most widely used metric of this type is the Function Point
o FP = Count Total * [0.65 + 0.01 * Sum (Value Adjustment Factors)]
• Function Point values on past projects can be used to compute,
o for example, the average number of lines of code per function point

Object-Oriented Metrics

• Conventional software project metrics (LOC or FP) can be used to estimate object-
oriented software projects
• However, these metrics do not provide enough granularity (detailing) for the schedule
and effort adjustments that are required as you iterate through an evolutionary or
incremental process
• Lorenz and Kidd suggest the following set of metrics for OO projects
o Number of scenario scripts
o Number of key classes (the highly independent components)
o Number of support classes
Use Case Oriented Metrics

• Like FP, the use case is defined early in the software process, allowing it to be used
for estimation before significant (valuable) modeling and construction activities are
initiated
• Use cases describe (indirectly, at least) user-visible functions and features that are
basic requirements for a system
• The use case is independent of programming language, because use cases can be
created at vastly different levels of abstraction, there is no standard “size” for a use
case
• Without a standard measure of what a use case is, its application as a normalization
measure is suspect (doubtful).
o Ex., effort expended / use case

Que 3 Explain Project Scheduling Process. Also Explain Gantt Chart in detail.

• Software project scheduling is an action that distributes estimated effort across the
planned project duration by allocating the effort to specific software engineering
tasks.
• It is important to note, however, that the schedule evolves over time.
• During early stages of project planning, a macroscopic schedule is developed.
• • This type of schedule identifies all major process framework activities and the
product functions to which they are applied.

Scheduling Principles

1 Compartmentalization The product and process must be decomposed

into a manageable number of activities and
tasks
2 Interdependency Tasks that can be completed in parallel must be
separated from those that must completed
serially
3 Time allocation Every task has start and completion dates that
take the task interdependencies into account
4 Effort validation Project manager must ensure that on any given
day there are enough staff members assigned to
completed the tasks within the time estimated
in the project plan
5 Defined Every scheduled task needs to be assigned to a
Responsibilities specific team member
6 Defined outcomes Every task in the schedule needs to have a
defined outcome (usually a work product or
deliverable)
7 Defined milestones A milestone is accomplished when one or more
work products from an engineering task have
passed quality review
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

(Figure: Gantt chart)

• 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. This allows you to see at a glance:
o What the various activities are
o When each activity begins and ends
o How long each activity is scheduled to last
o Where activities overlap with other activities, and by how much
o The start and end date of the whole project

Que 5 Explain RMMM

• The RMMM PLAN documents all work performed as part of risk analysis and used
by the project manager as part of the overall project plan
• Some software teams do not develop a formal RMMM document, rather each risk is
documented individually using a Risk information sheet (RIS)
• In most cases, RIS is maintained using a database system.
• So Creation and information entry, priority ordering, searches and other analysis may
be accomplished easily.
• The format of RIS is describe in diagram
• RMMM - Mitigation, Monitoring, and Management
• An effective strategy for dealing with risk must consider three issues
o Risk mitigation is a problem avoidance activity
o Risk monitoring is a project tracking activity
o Risk management includes contingency plans that risk will occur

Que 6 Draw the Time-line chart for the Library Management System
Que 7 Write short notes on 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, months.
Different models of Cocomo have been proposed to predict the cost estimation at different
levels, based on the amount of accuracy and correctness required. All of these models can be
applied to a variety of projects, whose characteristics determine the value of constant to be
used in subsequent calculations. These characteristics pertaining to different system types are
mentioned below. Boehm’s definition of organic, semidetached, and embedded systems:
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, 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 of Semi-Detached type.
 3. 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
4. develop such complex models.
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model

Que 8 Draw the Time-line chart for the Hospital Management System.

Que 9. Explain Risk Management.

Risk generally results from uncertainty. In organizations this risk can come from uncertainty
in the market place (demand, supply and Stock market), failure of projects, accidents, natural
disasters etc. There are different tools to deal with the same depending upon the kind of risk.
Ideally in risk management, a risk prioritization process is followed in which those risks that
pose the threat of great loss and have great probability of occurrence are dealt with first.
Refer to table below:

IMPACT ACTIONS

Considerable Must Manage and Extensive

SIGNIFICANT
Management Required Monitor Risks Management essential

Risk are bearable to Management effort Management effort

MODERATE
certain extent worthwhile required

Accept but monitor Manage and Monitor

MINOR Accept Risks
Risks Risks

LOW MEDIUM HIGH

LIKELIHOOD
The above chart can be used to strategize in various situations. The two factors that govern
the action required are the probability of occurrence and the impact of the risk. For example a
condition where the impact is minor and the probability of occurrence is low, it is better to
accept the risk without any interventions. A condition where the likelihood is high and the
impact is significant, extensive management is required. This is how a certain priority can be
established in dealing with the risk.
Apart from this, typically most of the organizations follow a risk management cycle. Refer
diagram below:

According to this cycle there are four steps in the process of risk management. The first step
is the assessment of risk, followed by evaluation and management of the same. The last step
is measuring the impact.
Risk identification can start at the base or the surface level, in the former case the source of
problems is identified. We now have two things to deal with the source and the problem.
Risk Source: The source can be either internal or external to the system. External sources are
beyond control whereas internal sources can be controlled to a certain extent. For example,
the amount of rainfall, weather over an airport etc!
Problem: A problem at the surface level could be the threat of accident and casualty at the
plant, a fire incident etc.
When any or both of the above two are known beforehand, certain steps can be taken to deal
with the same.
After the risk/s has been identified then it/they must be assessed on the potential of criticality.
Here we arrive upon risk prioritization.
In generic terms ‘Likelihood of Occurrence × Impact’ = Risk.
This is followed by development of a risk management plan and implementation of the same.
It comprises of the effective security controls and control mechanisms for mitigation of risk.
A more challenging risk to organizational effectiveness is the risk that is present but
cannot be identified. For example a perpetual inefficiency in the production process
accumulates over a certain period of time and translates into operational risk.
Que 10 Explain 4 P’s of Effective Project Management in detail

Productive Team Communication

Conducting regular status meetings and building a rapport with the project team are critical to
achieving success. These meetings should be about more than reviewing the status of tasks—
they’re an opportunity to discuss challenges and risks. Multiple perspectives contribute to a
more comprehensive product and can help resolve any problems that arise. To build team
rapport, I ask for a member to share a joke or funny story at the conclusion of every meeting.
This levity is especially important when managing a virtual team: We may not be in the same
room, but we can still have fun together. After the meeting, I distribute meeting minutes and
action items, to ensure accountability and progress.

Positive and Negative Client Communication

No one likes to give a client bad news. But delivering both the good and the bad gives the
project manager credibility with a client. Being direct and up front with a client about delays
or problems leads to open and honest communication, which promotes a healthy and trusting
relationship. It also gives the client the opportunity to provide a different perspective and
identify solutions while addressing schedule delays, budget concerns or the resolution of
risks. If there is bad news, project managers should frame it as an opportunity to assess what
is going on, and then reset the client’s expectations through a new plan. Don’t deliver bad
news empty-handed; offer options to your client and guide him or her to the most appropriate
option.

3. Persistence

More often than not I’m nicknamed “Hound” while managing a project. While some might
be offended by this, I claim the name as a badge of honor. Whether you’re nudging your team
members or your client, persistence pays off (though sometimes it takes longer than you’d
like). The action item list that comes out of weekly status meetings, for example, is a good
tool to hold your team or client accountable. Of course, reminders—whether delivered in
person, via email or over the phone—are a go-to mechanism to prod people and encourage
ontime delivery.

4. Passion

If you exude passion, your team members are more likely to follow suit. Leading by example
matters when managing projects: It is easier to emulate a passionate project manager than a
disgruntled one. But be careful not to be emotional; always lead with a calming demeanor.

Que 10 Discuss Software Project Management and W5HH Principle in brief.

Software project management is an art and discipline of planning and supervising software
projects. It is a sub-discipline of software project management in which software projects
planned, implemented, monitored and controlled.

It is a procedure of managing, allocating and timing resources to develop computer software

that fulfills requirements.
W5HH principle

• Why is the system being developed? All stakeholders should assess the validity of
business reasons for the software work. Does the business purpose justify the
expenditure of people, time, and money?
• What will be done? The task set required for the project is defined.
• When will it be done? The team establishes a project schedule by identifying when
project tasks are to be conducted and when milestones are reached.
• Who is responsible for a function? The role and responsibility of each member of the
software team are defined.
• Where are they located organizationally? Not all roles and responsibilities reside
within software practitioners. The customer, users, and other stakeholders also have
responsibilities.
• How will the job be done technically and managerially? Once the product scope is
established, management and technical strategy for the project must be defined.
• How much of each resource is needed? The answer to this question is derived by
developing estimates based on the answers to earlier questions.

que 12. What is the purpose of timeline chart?

The main objective of timelines is to demonstrate a sequence of actions within a particular

time interval. Although timelines cover a great period of time, it is not very detailed.
Nevertheless, it is possible to add images, data, or figures.

A timeline chart makes it easier to conceptualize a process or a sequence of events. It can

make it easier for you to understand the intricacies of a project or why something seems to
take so long to accomplish.

Educators may find timelines a useful strategy for a variety of educational purposes. They
can be used to record events from a story or a history lesson in a sequential format. They can
help students keep events in chronological order as they write summaries.