1

Software Project Management

Indu SharmaHOD(CSE)

CPTC,Rajsamand

2

Introduction Project Management is an integrated part of

software development. It refers to manage the complete software

project. The goal is to provide the necessary support for

development to proceed smoothly and reduce any development problem. Its basic task is to ensure that, once a development process is chosen, it is implemented optimally.

Effective s/w project management focuses on the 4 P’s: The People, The Product, The Process, and The Project.

3

IntroductionI. The People:

People-intensive SEI has developed a “People Management-

Capability Maturity Model” (PM-CMM): This model defines the key practice areas for

s/w people: recruitment, selection, performance management, training, compensation, career development, organization and work design, and team/culture development.

Team leaders: Motivation, Innovative, Problem solving, influence and team building.

4

IntroductionII. The Product:

Product objectives: Overall goals (from the customer’s point of view) without considering how these goals will be achieved.

Scope: identifies its primary data, functions, and behaviors.

Alternative Solutions: Once the project objectives and scope are understood, alternative solutions are considered. The alternative solutions enable managers to select a “best” approach, given the constraints imposed by the delivery deadlines, budgetary restrictions, personnel availability, technical interfaces etc.

5

IntroductionIII. The Process:

The way in which we produce the software. Provides a framework from which a

comprehensive plan for s/w development can be established.

Problem is to select the appropriate process model.

The project manager must decide which process model is appropriate for:

The customer who have requested the product The characteristics of the product itself, and The projcect environment in which the s/w team

works.

6

IntroductionIV. The Project:

In order to manage successful s/w projects, we must understand what can go wrong and how to do it right. Ten signs that indicate the project is in danger:

i. S/w people don’t understand their customer’s need.

ii. The product scope is poorly defined.iii. Changes are managed poorly.iv. The chosen technology changes.v. Business needs change (or ill defined).

7

Introductionvi. Deadlines are unrealistic.vii. Users are resistant.viii. Sponsorship is lost ( or was never properly

obtained)ix. The project team lacks people with appropriate

skills.x. Managers avoid practices and lessones learned.

8

Introduction Five commonsense approach to avoid problems to

s/w projects: Start on the right foot:

Working hard to understand the problem. Building the right team and giving the team

autonomy, authority, and technology needed to the job.

Maintain Momentum: Good start and then slowly disintegrate To maintain momentum, the project manager

must provide incentives, should emphasize quality in every task it performs etc.

Track progress: Progress is tracked as work products.

9

Introduction Make smart decisions:

Keep it simple. Use of existing s/w components Decide to avoid custom interfaces when

standard approaches are available. Decide to identify and then avoid obvious

risks. Decide to allocate more time than you think is

needed to complex or risky tasks.

10

Introduction Conduct a postmortem analysis:

Establish consistent mechanism for extracting lessons learned for each project.

Evaluate the planned and actual schedules, collect and analyze s/w project metrics, get feedback from team members and customers, and record finding is in written form.

11

Activities The activities in the management

process for a project can be grouped broadly into three phases: Project planning Project Monitoring & Control Project Termination

12

Project Planning Project management begins with planning,

which is the perhaps most critical project management activity.

Lack of proper planning is sure ticket to failure for a large s/w project.

A s/w plan is usually produced before the development activity begins and is updated as development proceeds and data about progress of the project becomes available.

13

Project Planning The major issues project planning

addresses are:I. Process PlanningII. Effort estimationIII. Project scheduling and staffingIV. Configuration Management PlanV. Quality PlansVI. Risk ManagementVII. Project Monitoring plans

14

I Process Planning For a project during planning, a key

activity is to plan and specify the process that should be used in the project.

It means the various stages in the process, the entry criteria for each stage, the exit criteria, the verification activities that will be done at the end of the stage.

Some standard process model may be used as a standard process and tailored to suit the needs of the project.

15

II Effort Estimation For a given set of requirements it is

desirable to know how much it will cost to develop the s/w and how much time the development will take. These estimates are needed before development is initiated.

The primary reason for cost and schedule estimation are: Cost and benefit analysis Project monitoring and control More practical use: bidding for s/w projects

16

Effort Estimation Because the s/w development is labour-

intensive(i.e. human resources), most cost estimation procedures focuses on estimating effort in terms of Person-Months(PM).

Effort and schedule estimation is required to answer the questions like: Is the project late? Are there cost overruns? When is the project likely to complete? What staffing level is required during different

phases?

17

Effort Estimation To achieve reliable effort estimation in terms of

cost , a no. of options arise:a) Delay estimates until late in the project.

Not practical, as cost estimation must be provided “up-front”

b) Base estimates on similar projects that have already been completed Can work reasonably well, if the current project is

quite similar to past efforts.c) Use relatively simple decomposition techniques to

generate project cost and effort estimation.d) Use one or more empirical models for s/w cost and

effort estimation.(c) And (d) are viable approaches to s/w project

estimation.

18

Measure, Measurement, Metrics and Indicators Although, the terms measure, measurement,

and metrics are often used interchangeably, but it is important to note the subtle differences between them.

Measure: A measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attributes of a product or process.

Measurement: Measurement is the act of determining a measure.

Metric: A quantitative measure of the degree to which a system, component, or process possesses a given attribute.

19

Measure, Measurement, Metrics and Indicators Example:

When a single data point has been collected (e.g., the number of errors uncovered in the review of a single module), a measure has been established. Measurement occurs as the result of the collection of one or more data points (e.g., a number of module reviews are investigated to collect measures of the number of errors in each module). A software metric relates the individual measures in some way (e.g., the average number of errors found per review).

20

Measure, Measurement, Metrics and Indicators A software engineer collects measures

and develops metrics so that indicators will be obtained. An indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself.

An indicator provides insight that enables the project manager or software engineers to adjust the process, the project, or the process to make things better.

21

Measure, Measurement, Metrics and Indicators For example, four software teams are working on a

large software project. Each team must conduct design reviews but is allowed to select the type of review that it will use. Upon examination of the metric, errors found per person-hour expended, the project manager notices that the two teams using more formal review methods exhibits an errors found per person-hour expended that is 40% higher than the other teams. Assuming all parameters are equal, this provides the project manager with an indicator that formal review methods may provide a higher return on time investment than another, less formal review approach. She may decide to suggest that all teams use the more formal approach.

22

Metrics Because the s/w has not physical

attributes, conventional metrics are not much help in designing metrics of s/w. A number of metrics have been proposed to quantify things like the size, complexity, and reliability of a s/w product. A s/w metrics relates the individual

measures in some way.Eg. Avg lines of code: KLOC per moduleAvg number of errors found per module

23

Metrics There are three types of metrics:

Product Metrics: Product metrics are used to quantify characteristics of the product being developed i.e. Software. Eg. Size, complexity, performance, efficiency, portability, reliability etc.

Process Metrics: Process metrics are used to quantify characteristics of the process being used to develop the s/w. Eg. Effort required in the process, time to produce the product, effect of development techniques and tools, no. of defects found during testing etc.

24

Metrics Project Metrics: are used for strategic

purposes. That is, project metrics and indicators derived from them are used by a project manager and a software team to adapt project work flow and technical activities.

Two purpose: First, to minimize the development schedule by

making necessary adjustments in order to avoid delays and alleviate potential risks and problems.

Secondly, these metrics are used to assess the product quality on a regular basis and modify the technical issues if required. As the quality improves, the number of errors and defects are reduced, which in turn leads to a decrease in the overall cost of a software project.

25

Metrics Values of metrics can be measured

directly or indirectly. Directly:

eg. Distance can be directly measured. eg. Size of the s/w (LOC), cost,

execution speed etc. Indirectly:

eg. Distance = speed * time eg. Reliability has to be estimated

from other possible measurements, quality, complexity, maintainability etc.

26

Decomposition Techniques Decomposition techniques take a “divide and

conquer” approach to s/w project estimation. Decomposition techniques are used to estimate cost

and effort by decomposing the complete project problem into subsequent parts. Now, first these parts or subdivisions are solved one-by-one and after their solutions can be combined to form a whole.

The s/w size is the most important factor that effects the cost. LOC and FP-Based are distinct estimate techniques for s/w size.

If a direct approach is chosen, size can be measured in LOC. If an indirect approach is chosen, size is represented in FP.

27

LOC-Based Estimation It simply refers to the no. of lines of the

delivered source code. Eg. 5000 KLOC LOC

From this a set of simple size-oriented metrics can be developed: Errors / KLOC, Defects / KLOC, $ / KLOC

Other Metrics: Errors / person-month LOC / Person-month $ / page of documentation

28

LOC-Based Estimation Advantages:

Simple to measure It can be determined uniquely by automated tools

once the project is completed. Drawbacks:

It is defined on code. For example it can’t measure the size of specification.

It characterize only one specific view of size, name length, it takes no account of functionality or complexity.

Bad s/w design may cause excessive line of code It is language dependent.