software project management 3

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. Size of the s/w (LOC), cost, execution speed etc.

Indirectly: 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.

27

Decomposition Techniques The project planner begins with a bounded

statement of software scope and from this statement attempts to decompose software into problem functions that can be estimated individually.

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.

28

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, $ / KLOC

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

29

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.

30

FP(Function Points)-Based Estimation

The basis of function points is that the “functionality” of a system, that is, what the system performs, is the measure of the system. For computing the FPs:

1. Compute the count of five different parameters, namely:

No. of user inputs, no. of user outputs, no. of user inquires, no. of files, and no. of external interfaces

According to FP approach, these five parameters capture the entire functionality of a system.

31

FP(Function Points)-Based Estimation No. of user inputs (or External Input):

Each unique input that is given as input to the application from the outside is considered of external input type and is counted. Eg. Forms, files etc.

No. of user outputs (or External Output): Each unique output that leaves the system boundary is counted as a external output type. Eg. reports, screens, error messages etc.

32

FP(Function Points)-Based Estimation No. of user inquiries ( or External inquiry):

Include queries, where a query is defined as an input-output pair where the input caused the output to be generated immediately. Each input-output pair is counted as an external inquiry type.

No. of files (or Logical internal files): Each logical group of data used and maintained by the application is counted as logical internal file type.

33

FP(Function Points)-Based Estimation No. of external interface (or External

Interface File): Files that are passed or shared between applications are counted as external interface file type.

2. Now, the above five functional units are ranked according to their complexity i.e. low, average, or high using a set of perspective standards. Organizations that use FP methods develop criteria for determining whether a particular entry is simple, average, or complex.

34

FP(Function Points)-Based Estimation Eg. A logical internal file is simple, if it

contains a few record types, complex if it has many record types, and average if it is between.

3. Once the counts for all five different types are known for all three different complexity classes, the Unadjusted Function Point (UFP) is calculated using predefined weights for each function type as shown in table.

35


complexity multiplier

function points

number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces

measurement parameter

3 4 3 7 5

countweighting factor

simple avg. complex

4 5 4 10 7

6 7 6 15 10

= = = = =

count-total

X X X X X

36

FP(Function Points)-Based Estimation4. To compute FP, the following

relationship is used:FP = UFP * [0.65 + 0.01 * (Fi) ]Or FP = UFP * CAFWhere CAF is Complexity Adjustment

Factor and CAF = 0.65 + 0.01 * (Fi)The Fi (i=1 to 14) are “complexity adjustment

values” based on to the following questions:

37


1. Does ths system require reliable backup and recovery?

2. Are data communication required?3. Are there distributed processing functions?4. Is performance critical?5. Will the system run in an existing, heavily

utilized operational environment?6. Does the system require on-line data entry?7. Does the on-line data entry require the input

transaction to be built over multiple screens or operations?

8. Are the master files updated on-line?

38

FP(Function Points)-Based Estimation9. Are the inputs, outputs, files, or inquiries

complex?10. Is the internal processing complex?11. Is the code designed to be reusable?12. Are conversion and installation included in

the design?13. Is the system designed for multiple

installations in different organizations?14. Is the application designed to facilitate chang

and ease of use by the user?

39

FP(Function Points)-Based Estimation The degree of influence of each of

these factors is taken to be from 0 to 5 representing the six different levels i.e. 0 -> No 1 -> Insignificant2 -> Moderate 3 -> Average4 -> Significant 5 -> Strong

40


Once function points have been calculated, they are used in a manner analogous to LOC as a way to normalize measures for software productivity, quality, and other attributes: Errors per FP Defects per FP $ per FP Pages of documentation per FP FP per person-month

41

FP(Function Points)-Based Estimation Advantages:

It is not restricted to code Language independent The definition of FPs depends only on

information available from specifications, whereas the size in KLOC can’t be directly determined from specifications.

The necessary data is available early in a project and thus only a detailed specification is needed.

More accurate than estimated LOC.

42

FP(Function Points)-Based Estimation Drawbacks:

Subjective counting Hard to automate and difficult to compute Ignore quality of output Oriented to traditional data processing

applications It does not take into account the algorithmic

complexity of a software. That is, the function point metric implicitly assume that the effort required to design and develop any two functionalities of the system is same.

43

Problems1. Consider a project with the following

functional units: No. of user inputs=50 No. of user outputs =40 No. of user enquiries =35 No. of user files =06 No. of external interfaces =04Assuming all complexity factors and weighing factors are average. Compute the function points for the project.

44

Problems2. An Application has the following:

10 low external inputs, 12 high external outputs, 20 low internal logical files, 15 high external interface files, 12 average external inquiries, and a value of complexity adjustment factor of 1.10.what are the unadjusted and adjusted function point counts?

45

Empirical Estimation Models Empirical means based on

observations and experiments not on theory.

An empirical model for computer softwares is used to predict effort as a function of LOC or FP. Effort (E) = a * (KLOC) b

46

The COCOMO Model –I (The Constructive Cost Model): Most widely used and discussed cost estimation

model in the industry. Produced by B. W. Bohem in 1981. COCOMO is a hierarchy of s/w cost estimation

models, which include, basic, intermediate, and detailed sub models.

It was based on the data of 63 completed projects. Size 5000 LOC to more than 10,00000 LOC. Project Complexity: simple, general applications to

complex real time applications. COCOMO-I COCOMO-II

47

The COCOMO Model-I This approach implies that size is the primary

factor for cost; other factors have a lesser effect.

This model estimates the total effort in terms of person-months.

In COCOMO, projects are categorized into three categories, based on project size, nature of project, development environment etc.: Organic, Semidetached, and Embedded

48

The COCOMO Model-I Organic: These projects have the following

characteristics: Small product size (less than 50,000 LOC) Small, in-house development team. Development team has experienced in application area. Requirements are less stringent (i.e. Negotiable, informal) Minimal communication overhead. Stable development environment. Minimal schedule pressure. Existing, proven technology is used.

Examples: simple business systems, simple inventory management systems, and data processing systems.

Pay roll etc.

49

The COCOMO Model-I Semidetached: These systems fall between the

other two types and have the following characteristics:

Size may range typically 50 – 300 KLOC Medium size team. Development team personnel is mix of experienced and

inexperienced in the application area and development environment.

Mix of relaxed and rigid specification on function and performance requirements, interfaces and product acceptance criteria.

Moderate schedule pressure. Eg.: developing a new OS, a database management

system, simple transaction processing systems etc.

50

The COCOMO Model-I Embedded: These projects have the following

characteristics: Size may range over 300 KLOC. Large project team. Very little previous experience. Requirements are stringent for such aspects as interfacing and

reliability. Product must operate within time constraints on internal and

external interface service, processing and interrupt service. Product must meet rigid, formal quality standards. Extensive testing required. These systems have tight constraints from the environment (s/w,

h/w, and people). Leading edge technology employed. Strong schedule pressure. Other system components developed concurrently with s/w. Eg.: Avionic systems, real-time systems etc.

51

The Basic COCOMO Model It is very simple to use. This model aims at estimating, in a quick and

rough fashion, most of small to medium sized s/w projects.

The effort, cost, and development time to develop an application can be calculated by using the following equations:

Effort (E) = Ab (KLOC) Bb in (Person-Months) Development time (D) = Cb (E) D

b in (Months) E-> Effort is the total effort required to develop the

software product, expressed in Person-Months (PMs) D->Development Time in Months The coefficients Ab, Bb, Cb, Db are given in table:

52

The Basic COCOMO ModelProject Ab Bb Cb Db

Organic 2.4 1.05 2.5 0.38

Semidetached

3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

53

When Effort and development time is known, the average staff size to complete the project may be calculated as follows: Average Staff Size (SS) = E / D Persons

When project size is known the productivity level may be calculated as: Productivity (P) = KLOC / E KLOC/PM

The Basic COCOMO Model

54

Problem 3Assume that the size of an organic type software product has been estimated to 32,000 lines of source code. Assume that the average salary of software developers is Rs. 15,000 per month. Determine the effort required to develop the software product, the nominal development time, and the cost to develop the product.

55

Intermediate COCOMO Model The basic model allowed for a quick and rough

estimate, but it resulted in a lack of accuracy. Bohem introduced an additional 15 different

attributes called cost driver attributes. These factors depend on product, computer, personnel and technology attributes (called project attributes).

Cost drivers are used to adjust the nominal cost of a project to the actual project environment, hence increasing the accuracy of the estimate.

See figure: Effort Multiplier for different cost drivers.

56

Effort Multiplier for different cost drivers.

57

Intermediate COCOMO Model Now, the Efforts and development time

can be calculated as: Initial Effort (Ei) = Ai * (KLOC)B

i Compute Effort Adjustment Factor (EAF) EAF

= Multiplication of all 15 cost drivers (Typical values for EAF range from 0.9 to 1.4)

Final Effort Estimation (E) = EAF * Ei Development Time (D) = Ci (E) D

i The coefficients Ai, Bi, Ci, Di are given in

the table on next slide.

58

Intermediate COCOMO Model

Project Ab Bb Cb Db

Organic 3.2 1.05 2.5 0.38

Semidetached

3.0 1.12 2.5 0.35

Embedded 2.8 1.20 2.5 0.32

59

Detailed COCOMO Model Detailed COCOMO incorporates all characteristics

of the intermediate version with an assessment of the cost driver’s impact on each phase of the development process. This helps in determining the manpower allocation for each phase of the project.

The phases are: Requirements and Product Design

Plans and requirements System Design

Detailed Design Code & Unit Test Integration & Test

60

Detailed COCOMO Model Effort for a phase is a defined

percentage of the overall effort. The percentage of total effort spent in a

phase varies with the type and size of the project.

The percentage for an organic software project are given in Table:

Using this table, the estimate of the effort required for each phase can be determined from the total effort estimate.

61

Detailed COCOMO ModelPhase Size

Small2 KLOC

Intermediate 8 KLOC

Medium32 KLOC

Product design 16 16 16Detailed Design 26 25 24Code & Unit Test

42 40 38

Integration & Test

16 19 22

62

COCOMO-II Revise version of the COCOMO-I. Since its formulation (COCOMO-I), there

have been many changes in software engineering practice and COCOMO-II is designed to accommodate different approaches to software development.

Use of tools & techniques, Reuse, GUI builders etc.

63

COCOMO-II Like its predecessor, COCOMO-II is

actually a hierarchy of estimation models. COCOMO-II model hierarchy:

Application Composition Model – used at the early stages of the process;

Early Design Stage Model – used once requirements have been stabilized and basic software architecture are available;

Post Architectural Stage Model – used during the actual development of the software.

64

The Application Composition Model Supports prototyping projects and

projects where there is extensive reuse. Takes CASE tool use into account. This model uses Object-Points

(alternatively named Application Points). Like FPs the object point is an indirect s/w measure that is computed using: Screens (at the user interface) Reports, and Components likely to be required to build

application.

65

The Application Composition Model Steps for the estimation of effort

in Person-Months:1. The first step is to count all of the

object points in the application.2. The next step is to weight them

according to the table on next slide.

66

The Application Composition Model

Object Type Complexity WeightSimple Mediu

mDifficult

Screen 1 2 3Report 2 5 83 GL Component

- - 10

67


3. Multiply each object by its weight and sum over all objects to give the Total Object Point Count.

68


Object Type Count

Complexity Weight Object Point Count

Simple

Medium

Difficult

Screens X 1 2 3 =

Reports X 2 5 8 =

3 GL Components

X - - 10 =

Total Object Point Count (Object Points) =

69

The Application Composition Model4. Compute the New Object Point (NOP): When

component based development or general s/w reuse is to be applied, the percentage or reuse(% reuse) is estimated and the object-point count is adjusted as below:

NOP=(Object-points) * [(100 - % reuse) / 100] 5. Determine the Productivity Rate (PROD): To

derive an estimate of effort based on computed NOP value, a “Productivity Rate” must be derived. Table on next slide presents the productivity rate. PROD=NOP/person-month

70


The productivity rate for different levels of developer experience and development environment maturity is given by this table:

Developer’s experience/capability

Very Low

Low Nominal

High Very High

Environment maturity/capability

Very Low

Low Nominal

High Very High

PROD 4 7 13 25 50

71


6. Compute the effort in PM as:Estimated effort = NOP/PROD

72

The Early Design Stage Model This model uses the equation of the form:

Effort = A * (Size)B * MHere, A-> a constant representing the nominal productivity, provisionally set to 2.5B -> Scale factor. It depends on the novelty of the project, development flexibility, team management skills, and process maturity.Size -> Size of the s/w

M -> Multipliers reflect the capability of the developers, the non-functional requirements, the familiarity with the development platform, etc.(7 cost drivers)

73

The Early Design Stage Model There are 7 cost drivers

1. RCPX - product reliability and complexity;2. RUSE - the reuse required;3. PDIF - platform difficulty;4. PREX - personnel experience;5. PERS - personnel capability;6. SCED - required schedule;7. FCIL - the team support facilities.

M = PERS * RCPX * RUSE * PDIF * PREX * FCIL * SCED; The degree of influence of each of these factors is taken

to be from 1 to 6 representing the six different levels i.e. 1 -> Very Low2 -> Low3 -> Nominal 4 -> High5 -> Very High 6 -> Extra High

74

The Post Architecture Model It is the most detailed estimation

model and assumes that the system architecture is known, and the information on various cost drivers of the system is available.

There are 17 cost drivers. They are

75

The Post Architecture Model1. Reliability Required (RELY).2. Database Size (DATA).3. Product Complexity (CPLX).4. Required Reusability (RUSE).5. Documentation (DOCU).6. Execution Time Constraint (TIME).7. Main Storage Constraint (STOR).8. Platform Volatility (PVOL).9. Analyst Capability (ACAP).10. Programmers Capability (PCAP).11. Personnel Continuity (PCON).12. Analyst Experience (AEXP).13. Programmer Experience (PEXP).14. Language & Tool Experience (LTEX).15. Use of Software Tools (TOOL).16. Site Locations & Communication Technology between Sites (SITE).17. Schedule (SCED).

76

Delphi Cost Estimation This strategy is not based on the use of

models and prototypes to assess the cost of s/w or system. It is based on the subjective assessment by group meetings.

In this method a group of people discusses the problem of estimation and finally converges on a consensus estimate.

The Delphi technique can be adapted to s/w cost estimation in the following manner:

77

Delphi Cost Estimation1. The coordinator provides each estimator with a

system definition and estimation form.2. The estimators study the definition, and the

coordinator calls a group meeting so that estimators can discuss estimation issues with the coordinator and one another.

3. Estimators complete their estimates anonymously.4. The coordinator prepares a summary of the

estimates.5. The coordinator calls a group meeting to focus on

issues where the estimates vary widely.6. Estimators complete another estimate, again

anonymously. The process is iterated for as many rounds as necessary.

78

Automated Estimation Tools The decomposition techniques and

empirical estimation models are available as part of a wide variety of s/w tools.

The automated estimation tools allow the planner to estimate cost and effort and to perform “what-if” analyses for important project variables such as delivery date or staffing.

Automated tools perform the following six generic functions:

79

Automated Estimation Tools1. Sizing of project deliverables:

Work products include: The external representation of s/w (eg. Screen, reports) The s/w itself (e.g. KLOC). Functionality (EG. FPs). Descriptive information (e.g. documents)

2. Selecting project activities: The appropriate process framework.

3. Predicting staff levels:4. Predicting software efforts:

Estimation tools use one or more models that relate the size of the project deliverables to the effort required to produce them.

5. Predicting s/w costs:6. Predicting s/w schedules:

80

Factors affecting the s/w engineering productivity1. Application domain experience:

Knowledge of the application domain is essential for effective s/w development. Engineers who already understand a domain are likely to be the most positive.

2. Process quality: The development process used can have a significant

effect on productivity.3. Project Size:

The larger a project, the more time required for team communications. Less time is available for development so individual productivity is reduced.

4. Technology support: Good support of technology such as CASE tools,

supportive configuration management system etc. can improve productivity.

81

Factors affecting the s/w engineering productivity5. Working Environment:

A quiet working environment such as privacy (programmer requires an area where they can concentrate and work without interruption), outside awareness, personalization (the ability to rearrange the workplace to suit working practices and to personalize that environment is important).

82

Solution Problem1We know

FP = UFP * [0.65 + 0.01 * (Fi) ]UFP=50*4+40*4+35*4+6*10+4*7

=200+160+140+60+28=628(Fi)=14*3=42

CAF=0.65+0.01*42=1.07FP = UFP * CAF=628*1.07=672

83

Solution Problem 2We know

FP = UFP * [0.65 + 0.01 * (Fi) ]UFP=10*3+12*7+20*7+15*10+12*4

=30+84+140+150+48=452CAF=1.10FP = UFP * CAF=452*1.10=497.2

84

Solution Problem 2From the basic COCOMO estimation for

organic software:Effort (E) = Ab (KLOC) Bb

= 2.4 * (32)1.05 = 91 PMDevelopment time (D) = Cb (E) D

b =2.5 * (91)0.38 = 14 months

Cost required to develop the product=91*15,000 = Rs. 13,65,000

software project management 3

Education