software project management

unit III
 chapter 9-Identifying the Tasks
and Activities
the software development life cycle models will
be done through a series of checklists. Once the
project manager has decided on a life cycle
model, these checklists can be used to identify
tasks and activities.
 Characteristics of Tasks and Activities

Activity An element of work performed during

the course of a project.An activity normally has
an expected duration, an expected cost, and
expected resource requirements. Activities can
be subdivided into tasks.
Task A generic term for work that is not
included in the WBS but that potentially could
be a further decomposition of work by the
individuals responsible for that work. Also, the
lowest level of effort on a project.
Meaningful Label
Many developers seem to believe that the SPMP is just
one large task called do it. But that is not a very
descriptive label, and we know that software
development is more than that (a lot more). So, we
want to describe the work with more accuracy and
meaning. The most obvious requirement for an activity
ID is that it should clearly describe the work to be done.
Optimal Activity Size
Just how big is a unit of work? "Optimal" for software
development projects
means whatever fits the scale and scope of the current
project.
source
The source depends on whether there is any
project precedent. If neither you nor your
organization has done a project like this before or
has any other history to draw from, then the
detailed work steps to create it must be invented.
The Activity ID Process
There are really only two ways that tasks and
activities are identified for a project: They are
part of a pre-existing WBS for a software
development life cycle, or they are invented anew
for a unique development project situation.
 chapter 10-Software Size and Reuse
Estimating
There are two major steps in determining how long a
project will take and how much it will cost. The first is to
estimate its size; the second is to use size along with other
environmental factors to estimate effort and its associated
cost.

Software size has been defined in terms of lines of code

(LOC), function points, feature points, number of bubbles
on a data flow diagram (DFD), a count of
process/control specifications (PSPECS/CSPECS), number of
module boxes on a structure chart, number of major
entities and/or relationships on an entity
 The SEI CMM and Estimating
The Software Engineering Institute (SEI) Capability
Maturity Model (CMM)
The software planning process includes steps to
estimate the size of the software work products and
the resources needed, produce a schedule,identify and
assess software risks, and negotiate commitments.
Iterating through these steps may be necessary to
establish the plan for the software project
Problems and Risks with Estimating Software Size
When performance doesn't meet the estimate, there
are two possible causes: poor performance or poor
estimates.(10 points)
 The Risks of Estimating
There are ways to diminish the effects of size estimation risks, all of which
are good project management practices in any case:
● Produce a WBS, decomposed to the lowest level possible, to use in a
"divide and conquer" approach; small components are easier to
estimate.
● Review assumptions with all stakeholders, including operations,
maintenance, and support departments.
● Wherever possible, do the research into past organizational
experiences instead of just guessing. This can often be done in the
absence of historical data. Anecdotal evidence can be illuminating.
● Stay in close communication, using a common language, with
developers working on other components of the system (perhaps in
parallel).
● Update estimates at frequent intervals, as shown in Figure 10-
2.Estimation accuracy does improve over the course of the life cycle.
● Use multiple size estimating methods to increase confidence.
● Educate software development staff in estimation methods.
The Effects of Reuse on Software Size
Many software programs are derived from previous programs.
This may result in savings of cost and/or time, and it may result in
increased quality. But reuse can also cost more, take longer, and
yield lower quality.
Reuse terminology includes:
● New code code developed for a new application without
including large portions of previously written code
● Modified code code developed for a previous application that
is suitable for a new application after a modest amount of
modification
● Reused code code developed for a previous application that is
suitable for a new application without change of any kind
● Legacy code code developed for a previous application that is
believed to be of use for a new application
 COST ESTIMATION
Whenever we develop a software project, main questions that arise in
our mind is how much it will cost to develop and how much time it will
take for development. These estimates are necessary and needed before
initiating development.
The main topics of these debates are of given below :
Which model of cost estimation should be used?
Whether or not to measure software size in source lines of code
or function points.
What constitutes a good estimate?
• Following are the attributes that Good Software Cost
Estimate Contains :
• It is simply conceived i.e. planned and supported by project
manager, architecture team, development team, and test team
responsible for performing work and task.
• All the stakeholders generally accept it as ambitious but realizable.
• It is based on a well-defined and efficient cost model of software
on a credible basis.
• It is also based on a similar project experience database that
includes and contains similar processes, relevant technologies,
relevant environments, relevant quality requirements, and all
similar people.
• It is also defined and explained in much amount of detail so that
all of its key risks are simply understood and probability of success
is objectively assessed.
 Effort Measures
• By "effort" in the software estimation process, we mean the amount of person-effort, or labor, that will be required
to perform a task. It can be measured in any units, as long as the unit is kept consistent. However, the de facto
standard is staff-hours (person-hours), staff-days (person-days), or, most commonly, staff-months (person-months).
• Software development tasks (design, code, test)
• - Additional development tasks (requirements, system)
• - Support tasks (CM, QA, management)
• - Tasks requiring additional labor (documents, etc.)
• • Additional dollar costs (travel, equipment, etc.)
• • Size estimate for software
• • Historical data on effort and productivity
• • High-level schedule
• • Process and methods
• • Programming language
• • Operating system for target system
• • Staff experience level
• Simple effort calculation is based on historical data: Size x Historical Productivity = Effort Regardless of what unit is
measured, reliance on good historical data is the best way to achieve accuracy.
• Suppose that historical data showed the following productivity:
• For complex software: 4 SLOC
• For simple software: 8 SLOC
 Software Engineering | 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.
• These characteristics pertaining to different system types are mentioned below. Boehm’s definition of
organic, semidetached, and embedded systems:
• 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 of 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.
– Basic COCOMO Model
– Intermediate COCOMO Model
– Detailed COCOMO Model
• Basic Model –
• The above formula is used for the cost estimation of for 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 system:
• E=a(KLOC)b
• TIME= C(EFFORT )d
• PERSONREQUIRED=EFFORT/TIME
• Intermediate 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 on the basis of Lines of Code. For that, various other factors
such as reliability, experience, Capability. These factors are known as Cost Drivers and
the Intermediate Model utilizes 15 such drivers for cost estimation. Classification of
Cost Drivers and their attributes: (i) Product attributes –
– Required software reliability extent
– Size of the application database
– The complexity of the product
– Run-time performance constraints
– Memory constraints
– The volatility of the virtual machine environment
– Required turnabout time
– Analyst capability
– Software engineering capability
– Applications experience
– Virtual machine experience
– Programming language experience
– Use of software tools
– Application of software engineering methods
– Required development schedule
• Detailed Model – Detailed COCOMO incorporates all
characteristics of the intermediate version with an
assessment of the cost driver’s impact on each step of the
software engineering process. The detailed model uses
different effort multipliers for each cost driver attribute. In
detailed cocomo, the whole software is divided into
different modules and then we apply COCOMO in different
modules to estimate effort and then sum the effort. The Six
phases of detailed COCOMO are:
– Planning and requirements
– System design
– Detailed design
– Module code and test
– Integration and test
– Cost Constructive model
 COCOMO II Model

• COCOMO-II is the revised version of the original Cocomo (Constructive Cost Model) and is
developed at University of Southern California. It is the model that allows one to estimate the
cost, effort and schedule when planning a new software development activity.
• . End User Programming:
Application generators are used in this sub-model. End user write the code by using these
application generators.
Example – Spreadsheets, report generator, etc.
• Intermediate Sector:
• Application Generators and Composition Aids –
This category will create largely prepackaged capabilities for user programming.
• (b). Application Composition Sector –
This category is too diversified and to be handled by prepackaged solutions. It includes GUI,
Databases, domain specific components such as financial, medical or industrial process
control packages.
• (c). System Integration –
This category deals with large scale and highly embedded systems.
• Infrastructure Sector:
This category provides infrastructure for the software development like
Operating System,Database Management System, User Interface
Management System, Networking System,etc.
• Stage-I:
It supports estimation of prototyping. For this it uses Application
Composition Estimation Model. This model is used for the prototyping
stage of application generator and system integration.
• Stage-II:
It supports estimation in the early design stage of the project, when we
less know about it. For this it uses Early Design Estimation Model. This
model is used in early design stage of application generators,
infrastructure, system integration.
• Stage-III:
It supports estimation in the post architecture stage of a project. For this
it uses Post Architecture Estimation Model. This model is used after the
completion of the detailed architecture of application generator,
infrastructure, system integration.
 SLIM estimating model.
• It is one of the first algorithmic models for estimating software project costs. It is based on Norden-
Rayleigh function and is commonly used for large projects. SLIM also uses historical data from past
projects for estimation. It also uses and considers other project parameters, characteristics, attributes and
KLOC for its estimation calculation.

Total Life cycle effort (years) = ( LOC / ( C * t4/3 )) * 3

t is development and C is technology constant which is determined from tools, language, methods, quality
features etc. This make SLIM dependent on C which is a disadvantage.
• Advantages of SLIM estimating model.
• Advantages of SLIM estimating model:

1. It provides a set of software development management tools that support the entire program life cycle.
2. Offers value-added planning.
3. It simplifies strategic decision making.
4. Supports "what-if" analysis.
5. It allows report and graph generation.
6. To consider the development constraints on both the cost and effort linear programming is used.
7. It has a few parameters which are required to generate an estimate over the COCOMO'81 and
COCOMO'II
• Disadvantages of SLIM estimating model.
• Disadvantages:

a. Works best on large projects.

b. The software size needs to be estimated in advance in order to use this model.
c. Estimates are extremely sensitive to the technology factor.
d. Model is also sensitive to size estimate.
e. Tool is considered to be fairly complex.
f. It works for Waterfall life cycle that doesn’t cover up spiral model.
 SLIM: A Mathematical Model
In mathematical modeling, the emphasis is
on matching the data to the form of an existing
mathematical function. In the early 1960s, Peter V.
Norden of IBM concluded that research and
development projects exhibit well-defined and
predictable staff loading patterns that fit the
mathematical formula for a Rayleigh distribution.
 chapter 12-Assigning Resources
Organizational Planning
The project manager is responsible for the
planning necessary to staff the project, which
includes the functions of:
• Identifying and documenting the project roles
and skills needed;
• Assigning responsibilities to individuals;
• Establishing reporting relationships.
 Identifying and Documenting the Project Roles and Skills
Needed

The project manager has to decide who does what and who decides
what on the project.
Types of Roles
• Database designers;

• Configuration management experts;

• Human interface designers;

• Webmasters;

• Quality assurance (QA) specialists;

• Network specialists;

• System architects;

• Programming language experts (C, C++, Java, etc.);

• Buildmasters;

• Test engineers.
 Characteristics of Roles
• Responsibility The obligation to perform an
assigned activity with or without detailed
guidance or specific authority.
• Authority The right to perform, command, or
make decisions.
• Accountability Assuming a liability for an
activity or something of value in a project.
consider a test engineer.
Responsibilities might include:
Collaborating with architects and designers;
Designing the test case;
Generating test data;
Running unit and regression test suites;
Reporting results.

Authority might be granted within the project

organization to include:
Participating in design and inspection meetings;
Exercising final authority for all test-related activities;
Authorizing component builds;
Reporting official test results and product quality metrics.
Accountability for the test engineers may be
defined as quantifiable and easily measured
parameters such as:
• Number of design and inspection meetings
attended;
• Quantity and quality of tests prepared and
executed;
• Percentage of successful component builds
using components passing a quality gate;
• Accuracy and timeliness of reported test
results and product quality metrics.
Assigning Responsibilities to Individuals

Comprehending Roll-On and Roll-Off

The project manager must also develop a roll-on
and roll-off plan for each of the resources
needed.
Resource Assignment Strategy
Fitting a Person to a Role
Developing the Project Staffing Management
Plan
As resource assignments that consider job and
team fit, career plans, and project needs are
made to activities in the WBS, a project-staffing
plan takes shape.
The staffing management plan contains information about
skill, amount needed, schedule timing, and how the staffing
will be done for each type of role. It may be formal or informal,
highly detailed or broadly framed, based on the needs of the
project and the organizational maturity of the organization.

If the resources must be searched for and hired into the team,
search professionals will want to have a staffing pool
description available, which contains such information as:
• Skills and competencies needed;

• Experience level desired;

• Cost (salary) targets;

• Personal characteristics and interests for team fit;

• Availability requirements.
 Establishing Reporting Relationships
When the staffing management plan has been started and
assignment of people to roles has been done, the project
manager can then define the reporting relationships
expected to carry out the project's activities.
Responsibility Assignment Matrix
The RAM clearly identifies an individual's responsibilities
and roles for work products and activities. It
defines who does what for the project activities, and it can
easily be expanded into a work product progress tracking
sheet.
Resource Leveling

Project Management Resource Activities During

Execution
Three kinds of interfaces need attention: personal,
organizational, and system. The personal interface
deals with all conflicts involving people in or
related to the project.