Softenr-4

Software Engineering

Project Management &

Estimation

Chapter-24: Project Management

•

_Objectives

– _SPM

– _{Team organization}

– _{Project management Activities} – _{Risk Management}

3

Project

• _{Definition: A group of tasks performed in a} definable time period in order to meet a specific set of objectives

• _{Project Features:}

– _{likely to be unique (one-time program)}

– _{have specific start and end time (life cycle)}

– _{have work scope that can be categorized into}

definable tasks

4

The Four P’s

• _{People — the most important element of a}

successful project

• _{Product — the software to be built}

• _{Process — the set of framework activities and}

software engineering tasks to get the job done

• _{Project — all work required to make the}

5

Software Teams

How to lead?

How to organize?

How to motivate? How to collaborate?

6

A Simple Project

“Plan for a friendly match” People ?

7

Management

8

Definition of Project Management

• _{The planning, organizing, directing, and}

9

Software Teams

• _{the difficulty of the problem to be solved}

• _{the size of the resultant program(s) in lines of code or function}

points

• _{the time that the team will stay together (team lifetime)} • _{the degree to which the problem can be modularized}

• _{the required quality and reliability of the system to be built} • _{the rigidity of the delivery date}

• _{the degree of sociability (communication) required for the}

project

Assembling a team

• _{May not be possible to appoint the ideal people to work on a}

project

– _{Project budget may not allow for the use of highly-paid staff;} – _{Staff with the appropriate experience may not be available;}

– _{An organisation may wish to develop employee skills on a software}

project.

• _{Managers have to work within these constraints especially when}

there are shortages of trained staff.

Groupcomposition

In creating a group for assistive technology development, Alice is aware of the

importance of selecting members with complementary personalities. When interviewing potential group members, she tried to assess whether they were task-oriented, self-oriented, or interaction-oriented. She felt that she was primarily a self-oriented type because she considered the project to be a way of getting noticed by senior

management and possibly promoted. She therefore looked for one or perhaps two interaction-oriented personalities, with task-oriented individuals to complete the team. The final assessment that she arrived at was:

Project

Activity or set of activities that span the duration of the

Project

For instance :

Project management Documentation , Training

Quality Control (Verification and validation) Configuration Management

Smallest unit of work subject to management

Small enough for adequate planning and tracking

Large enough to avoid micro management

13

Project Management Activities

• _{Establish project objectives}

• _{Defining work requirement}

• _{Determining work timing}

• _{Establishing resource availability and} requirements

• _{Establishing a cost baseline}

14

Project Management Activities

(Continued)

• _{Freezing the baseline plan} • _{Tracking the actual costs}

• _{Comparing the progress and cost to the} baseline plan

• _{Evaluating performance}

• _{Forecasting, analysing and recommending}

15

The Process

• _{Once a process framework has been established} – _{Consider project characteristics}

– _{Determine the degree of rigor required}

– _{Define a task set for each software engineering}

activity

• _{Task set =}

– Software engineering tasks

– Work products

– Quality assurance points

The Project

• Projects get into trouble when …

– Software people don’t understand their customer’s needs.

– _{The product scope is poorly defined.} – Changes are managed poorly.

– The chosen technology changes.

– _{Business needs change [or are ill-defined].} – _{Deadlines are unrealistic.}

– Users are resistant.

– _{Sponsorship is lost [or was never properly obtained].} – The project team lacks people with appropriate skills.

Project Management Concerns

staffing?

cost estimation?

project scheduling?

project monitoring? other resources?

customer communication? risk assessment?

product quality?

To Get to the Essence of a Project

• _{Why is the system being developed?} • _{What will be done?}

• _{When will it be accomplished?} • _{Who is responsible?}

• _{Where are they organizationally located?} • _{How will the job be done technically and}

managerially?

• _{How much of each resource (e.g., people,}

software, tools, database) will be needed?

Resources of A Company

• _Money

• _Manpower

• _Equipment

• _Facilities • _Materials

Project Management Skills

• _{Communication Skills}

• _{Organizational Skills} • _{Team Building Skills} • _{Leadership Skills}

• _{Coping Skills}

Project Plan Elements

• _{Project Objective & Scope} • _Schedule

• _{Team Organization}

• _{Project Standards and Procedures} • _{Documentation Plan}

• _{Quality Assurance Plan}

• _{Resource Management Plan}

Examples of common project,

product, and business risks

Risk Affects Description

Staff turnover Project Experienced staff will leave the project before it is finished.

Management change Project There will be a change of organizational management with different priorities.

Hardware unavailability Project Hardware that is essential for the project will not be delivered on schedule.

Requirements change Project and product There will be a larger number of changes to the requirements than anticipated.

Specification delays Project and product Specifications of essential interfaces are not available on schedule.

Size underestimate Project and product The size of the system has been underestimated. CASE tool

underperformance

Product CASE tools, which support the project, do not perform as anticipated.

Technology change Business The underlying technology on which the system is built is superseded by new technology.

Product competition Business A competitive product is marketed before the system is completed.

The risk management process

• _{Risk identification}

– Identify project, product and business risks;

• _{Risk analysis}

– _{Assess the likelihood and consequences of these}

risks;

• _{Risk planning}

– Draw up plans to avoid or minimise the effects of the risk;

• _{Risk monitoring}

– Monitor the risks throughout the project;

The risk management process

Organizational Paradigms

random paradigm—structures a team loosely and depends on individual initiative of the team members

closed paradigm—structures a team along a traditional

28

29

Hierarchical Planning System

1. Goals must be specified.

2. Identifying the set of required activities to achieve the goals.

3. Each activities and events can be

30

Planning Steps

1. Establish objectives 2. Develop a plan

3. Construct project planning diagram

4. Identify timing duration of each activity in planning diagram

31

Establish Objectives

• _{State objectives}

– _{Project start/end dates}

– _Budgets

– _{Technical results}

• _{List milestones}

• _{Milestone: a scheduled event for which some person}

is held accountable and which is used to measure and control progress.

32

Develop A Plan

• _{List activities}

• _{Develop Work Breakdown Structure (WBS): The WBS}

reflects the decomposition of a project into subtasks down to the level for effective planning and control.

• _{Determine relationships of activities}

– _{job precedence/succession}

WBS of a simple project

Design Test plan

Code Test

Project

Code A Code B

•Each activity has a duration and consumes resources. •Each activity has a constraint(example: one must be finished before the other starts; so activities are

35

Example of WBS: “Holiday”

holiday

travel documents

passport tickets

insurance

booking

choose

resort confirm brochures

household

36

List of activities

•Booking:

• get brochures • choose resort • make booking • confirm booking •Travel documents:

• check passport • book tickets • get insurance

•Household:

• feeding the cat! •This is a simple example:

• inoculations • visas

38

Program Evaluation and Review

Technique (PERT) diagram

•The numerical number represents the duration of each activity.

•PERT is mainly concerned with time of each activity and interrelations among activities.

Design 15

Test plan 10

Test 15

Code A 18

Activity-on-Arrow (AOA) Diagram

G

1

2 5

3

4

6

B

C A

F E

D

Activity Precedence

Activity Immediate

Predecessor

Duration

A - 2

B - 1

C - 3

D A 2

E B,C 4

F C 5

44

Critical Path Method (CPM)

• _{By drawing a network diagram, you can figure out}

the critical path of your project.

• _{The critical path is the longest path through the}

network. If something falls behind schedule on the

critical path, the whole project falls behind schedule unless time is made up elsewhere.

• _{It’s easier to adjust other activities (allocate}

45

Terms

• _{Activity - A task or job which takes time & use up}

resources

Represented by labeled arrow A

• _{Event - An instantaneous point representing the start or}

finish of an activity Represented by node

• _{Slack time: indicates that the corresponding activity may}

consume more than its estimated time, or start later than the earliest possible start time, without affecting the total duration of the project.

• _{Critical path: a path that has activities without any slack}

time

46

What is Scope?

• _{Software scope describes}

– _{the functions and features that are to be delivered to}

end-users

– _{the data that are input and output}

– _{the “content” that is presented to users as a consequence of}

using the software

– _{the performance, constraints, interfaces, and reliability that}

bound the system.

• _{Scope is defined using one of two techniques:}

• _{A narrative description of software scope is developed after}

communication with all stakeholders.

47

Problem Decomposition

• _{Sometimes called partitioning or problem}

elaboration

• _{Once scope is defined …}

– _{It is decomposed into constituent functions}

– _{It is decomposed into user-visible data objects}

or

– _{It is decomposed into a set of problem classes}

• _{Decomposition process continues until all}

48

A Good Manager Measures

process

process

measurement

measurement

What do we

What do we

use as a

use as a

basis?

basis?

•

• size?size?

•

• function?function?

49

Software Process Improvement

SPI

Improvement goals

Process metrics

50

Why Do We Measure?

• _{assess the status of an ongoing project} • _{track potential risks}

• _{uncover problem areas before they go “critical,”} • _{adjust work flow or tasks,}

• _{evaluate the project team’s ability to control}

Some suggested metrics

• Plot planned and actual staffing levels over time

• Record number & type of code and test errors

• Plot number of resolved & unresolved problem reports over time

• Plot planned & actual number of units whose V&V is completed over time:

a) design reviews completed b) unit tests completed

c) integration tests completed

Plot software build size over time

• Plot average complexity for the 10% most complex units over time

(using some suitable measure of complexity)

• Plot new, modified and reused SLOCs over time SLOC = Source Lines Of Code

• Plot estimated schedule to completion based on deliveries achieved

Typical Project Metrics

• _{Effort/time per software engineering task} • _{Errors uncovered per review hour}

• _{Scheduled vs. actual milestone dates}

• _{Changes (number) and their characteristics} • _{Distribution of effort on software}

53

Process Metrics

• _{Quality-related}

– focus on quality of work products and deliverables

• _{Productivity-related}

– Production of work-products related to effort expended

• _{Statistical SQA data}

– error categorization & analysis

• _{Defect removal efficiency}

– propagation of errors from process activity to activity

• _{Reuse data}

54

Typical Size-Oriented

Metrics

• _{errors per KLOC (thousand lines of code)} • _{defects per KLOC}

• _{$ per LOC}

• _{pages of documentation per KLOC} • _{errors per person-month}

• _{errors per review hour} • _{LOC per person-month}

55

Typical Function-Oriented

Metrics

• _{errors per FP (thousand lines of code)} • _{defects per FP}

• _{$ per FP}

56

Why Opt for FP?

• _{Programming language independent}

• _{Used readily countable characteristics that are}

determined early in the software process

• _{Does not “penalize” inventive (short)}

implementations that use fewer LOC that other more clumsy versions

• _{Makes it easier to measure the impact of}

57

Object-Oriented Metrics

• _{Number of scenario scripts (use-cases)} • _{Number of support classes (required to}

implement the system but are not immediately related to the problem domain)

• _{Average number of support classes per key class}

(analysis class)

• _{Number of subsystems (an aggregation of classes}

58

Measuring Quality

• _{Correctness — the degree to which a program}

operates according to specification

• _{Maintainability—the degree to which a}

program is amenable to change

• _{Integrity—the degree to which a program is}

impervious to outside attack

• _{Usability—the degree to which a program is}

59

WebApp Project Metrics

• _{Number of static Web pages (the end-user has no control over the}

content displayed on the page)

• _{Number of dynamic Web pages (end-user actions result in}

customized content displayed on the page)

• _{Number of internal page links (internal page links are pointers that}

provide a hyperlink to some other Web page within the WebApp)

• _{Number of persistent data objects}

• _{Number of external systems interfaced} • _{Number of static content objects}

60

Defect Removal Efficiency

where:

E is the number of errors found before delivery of the software to the end-user

D is the number of defects found after delivery.

61

Metrics for Small Organizations

• time (hours or days) elapsed from the time a request is made until evaluation is complete, t_queue.

• effort (person-hours) to perform the evaluation, W_eval.

• time (hours or days) elapsed from completion of evaluation to assignment of change order to personnel, t_eval.

• effort (person-hours) required to make the change, W_change. • time required (hours or days) to make the change, t_change. • errors uncovered during work to make change, E_change.

62

Establishing a Metrics Program

• _{Identify your business goals.}

• _{Identify what you want to know or learn.} • _{Identify your subgoals.}

• _{Identify the entities and attributes related to your subgoals.} • _{Formalize your measurement goals.}

• _{Identify quantifiable questions and the related indicators that you}

will use to help you achieve your measurement goals.

• _{Identify the data elements that you will collect to construct the}

indicators that help answer your questions.

• _{Define the measures to be used, and make these definitions}

operational.

63

Comparing LOC and FP

Programming LOC per Function point

Language avg. median low high

Ada 154 - 104 205

Assembler 337 315 91 694

C 162 109 33 704

C++ 66 53 29 178

COBOL 77 77 14 400

Java 63 53 77

-JavaScript 58 63 42 75

Perl 60 - -

-PL/1 78 67 22 263

Powerbuilder 32 31 11 105

SAS 40 41 33 49

Smalltalk 26 19 10 55

SQL 40 37 7 110

Summary

• _{Software project Management involves}

planning and risk management .

• _{Typical metrics help to estimate cost and effort}

• _{FP & LOC are used to do estimation for a project}