project management n.
Skip this Video
Loading SlideShow in 5 Seconds..
Project Management PowerPoint Presentation
Download Presentation
Project Management

Loading in 2 Seconds...

play fullscreen
1 / 118

Project Management - PowerPoint PPT Presentation

  • Uploaded on

Project Management. PART - II. Software Project Management. Organising, planning and scheduling software projects. Concerned with activities involved in ensuring that software is delivered on time within the budget in accordance with the requirements.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

Project Management

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software project management
Software Project Management
  • Organising, planning and scheduling software projects.
  • Concerned with activities involved in ensuring that software is delivered
    • on time
    • within the budget
    • in accordance with the requirements.
  • While project management was traditionally applied to the management of projects only, it is now being deployed to help organizations manage all types of change.
  • It begins before any technical activity is initiated and continues throughout the rest of the phases of software development.
management activities
Management Activities
  • Proposal writing
  • Project planning and scheduling
  • Project costing
  • Project monitoring and reviews
  • Personnel selection and evaluation
  • Report writing and presentations
the management spectrum
The Management Spectrum
  • Effective Software Project Management focuses on four P’s:





the management spectrum1
The Management Spectrum
  • People (recruiting, selection, performance management, training, compensation, career development, organization, work design, team/culture development)
  • Product (product objectives, scope, alternative solutions, constraint tradeoffs)
  • Process (framework activities populated with tasks, milestones, work products, and QA points)
  • Project (planning, monitoring, controlling)
  • The most important contribution in a software project is made not by the system or the tools but by the people.
  • The human element is very vital in software project management.
  • The success of a project depends on selecting the right kind of people with the right kind of talent.
  • Depending on their roles and responsibilities, people involved in a software project can be categorized into the following main categories:
    • Senior manager
    • Project manager
    • Software Engineer
    • Customer
    • End user
  • Senior managerswho define the business issues that often have significant influence on the project.
  • Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work.
  • Practitioners/Software Engineers who deliver the technical skills that are necessary to engineer a product or application.
  • Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome.
  • End-users who interact with the software once it is released for production use.
software teams
Software Teams

How to lead?

How to collaborate?

How to organize?

How to motivate?

How to create good ideas?

team leader
Team Leader
  • The MOI Model
    • Motivation. The ability to encourage (by “push or pull”) technical people to produce to their best ability.
    • Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product.
    • Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.
software teams1
Software Teams

The following factors must be considered when selecting a software project team structure ….

  • 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.
avoid team toxicity
Avoid Team Toxicity
  • A frenzied work atmosphere in which team members waste energy and lose focus on the objectives of the work to be performed.
  • High frustration caused by personal, business, or technological factors that cause friction among team members.
  • “Fragmented or poorly coordinated procedures” or a poorly defined or improperly chosen process model that becomes a roadblock to accomplishment.
  • Unclear definition of roles resulting in a lack of accountability and resultant finger-pointing.
  • “Continuous and repeated exposure to failure” that leads to a loss of confidence and a lowering of morale.
agile teams
Agile Teams
  • Team members must have trust in one another.
  • The distribution of skills must be appropriate to the problem.
  • A team member may have to be excluded from the team, if team cohesiveness is to be maintained.
  • Team is “self-organizing”
    • an adaptive team structure
    • uses elements of Constantine’s random, open, and synchronous paradigms
    • significant autonomy.
broad categories of team organization
Broad Categories of Team Organization
  • There can be three broad categories of team organizations:
    • Democratic Decentralized (DD)
    • Controlled Decentralized (CD)
    • Controlled Centralized (CC)
democratic decentralized dd
Democratic Decentralized (DD)
  • This kind of team has a horizontal level of communication where there will be no permanent leader as such.
  • A person to coordinate and monitor tasks will be appointed for short durations and then replaced by others who may coordinate different tasks.
  • Decisions are generally made by group consent.
  • This kind of team structure is best for difficult problems.
  • Job satisfaction and high morale can be achieved by implementing this kind of team structure.
controlled decentralized cd
Controlled Decentralized (CD)
  • This kind of team has a proper leader who coordinates specific tasks and secondary leaders who are responsible for subtasks.
  • Problem solving is still a group activity but the team leader divides implementation of solutions among subgroups.
  • Communication within subgroups and individuals is horizontal. However, along the control hierarchy, vertical communication also exists.
  • This kind of team structure is suitable for simple problems and is found to produce fewer defects.
controlled centralized cc
Controlled Centralized (CC)
  • A team leader manages top-level problem solving and internal team coordination.
  • Communication between the leader and team members is vertical.
  • This kind of team structure is also suitable for simple problems and is found to produce fewer defects.
what structure can be used and when
What Structure can be used and When?
  • For solving simple problems
    • A centralized structure is more suitable since it completes faster than a decentralized one.
  • For solving difficult problems
    • A decentralized structure is suitable since decentralized teams generate more and better solutions than individuals.
  • For large projects
    • Since the performance of a team is inversely proportional to the amount of communication that must be conducted, very large projects can be addressed by teams with a CC or CD structure where sub-grouping can be easily accommodated.
  • For high morale and job satisfaction
    • The DD team structure results in high morale and job satisfaction and are therefore good for teams that will be together for a long time.
what structure can be used and when1
What Structure can be used and When?
  • For solving problems with low modularity
    • The DD team structure is best applied to problems with relatively low modularity because of the higher volume of communication needed. When high modularity is possible (and people can do their own thing), the CC or CD structure will work well.
  • CC and CD teams have been found to produce fewer defects than DD teams, but these data have much to do with the specific quality assurance activities that are applied by the team.
  • Decentralized teams generally require more time to complete a project than a centralized structure and at the same time are best when high sociability is required.
second p product
Second P - Product

Customers and software developers must meet

  • To define objectives and scope of the project.
  • To consider alternative solutions and to select the best possible approach.
  • To identify technical and management constraints.
  • Objectives identify the overall goals for the product (from the customers’ point of view) without considering how these goals will be achieved.
  • Scope identifies the primary data, functions and behaviors that characterize the product, and more important, attempts to bound these characteristics in a quantitative manner.
the product scope
The Product Scope
  • Scope
      • Context.How does the software to be built fit into a larger system, product, or business context and what constraints are imposed as a result of the context?
      • Information objectives.What customer-visible data objects are produced as output from the software? What data objects are required for input?
      • Function and performance.What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed?
  • Software product scope must be unambiguous and understandable at the management and technical levels.
second p product1
Second P - Product
  • If scope and objectives are not defined, then it will be impossible:
  • To define a reasonable and accurate estimate of cost.
  • To assess possible risks
  • To define a manageable project schedule.
problem decomposition
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


    • It is decomposed into a set of problem classes
  • Decomposition process continues until all functions or problem classes have been defined
third p the process
Third P – The Process
  • The project manager must decide which process model is appropriate for:
    • The customers who have requested the product and the people who will do the work
    • The characteristics of the product itself
    • The project environment in which the software team works.
  • When a process model has been selected, define a preliminary project plan on the set of common process framework activities.
the process
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
      • Milestones
the 4 th p the project
The 4th P - The Project
  • For a successful project, we must understand what can go wrong
  • 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.
    • Managers [and practitioners] avoid best practices and lessons learned.
common sense approaches to projects
Common Sense Approaches to Projects
  • Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objectives and expectations.
  • Maintain momentum. The project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team’s way.
  • Track progress. For a software project, progress is tracked as work products (e.g., models, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity.
  • Make smart decisions. In essence, the decisions of the project manager and the software team should be to “keep it simple.”
  • Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project.
critical practices
Critical Practices
  • The Airlie Council (a team of software engineering experts chartered by the US Department of Defense to help develop guidelines for the best practices in software project management and software engineering) have developed a list of critical software practicesthat are used by and considered critical by, highly successful projects and organizations whose performance is much better than industry averages.
  • In an effort to enable a software organization to determine whether a specific project has implemented critical practices, the Airlie Council has developed a set of questions for a project.
critical software practices
Critical Software Practices
  • Formal risk management – What are the main risks for this project? What is the probability of the risks turning into a problem and what is the impact if it does?
  • Metric-based project management - Do we have a metrics program to give early indications of evolving problems?
  • People-aware program management – What is the average staff turnover for the past three months for each of the suppliers/developers involved in the development of software for this system?
  • Empirical cost and schedule estimation – What is the estimated size of the application software (excluding system software) that will be delivered into operation and how was it derived?
  • Defect tracking against quality targets – Is there a mechanism to periodicallytrack and report the number of defects found by each inspection?
project planning
Project Planning
  • Planning is deciding in advance:
    • what to do
    • how to do it
    • when to do it
    • who is to do it
  • The project plan sets out:
    • the resources available to the project;
    • the work breakdown;
    • a schedule for the work.
project planning1
Project Planning
  • Probably the most time-consuming project management activity.
  • Continuous activity from initial concept through to system delivery
  • Plans must be regularly revised as new information becomes available
  • Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget.
steps to project planning
Steps to Project Planning
  • Determination of the Software Scope
  • Estimation of the Resources Required.
  • Project Estimation
  • Decisions

Each resource is specified with four characteristics:

    • Description of the resource
    • a statement of availability
    • chronological order of time, and
    • duration of time that the resource will be applied.
  • Software Scope:
    • Already discussed
  • Resources:
objectives of project planning
Objectives of Project Planning

Human Resources:

  • Human resource estimation is done by evaluating scope and selecting skills required to complete the process of development.
  • While larger projects and organizations can afford a large number of people, in smaller organizations with relatively smaller projects, the same people will perform all the roles.

Re-useable Software Resources:

  • Software resources are primarily reusable building blocks.
  • These can be divided into four categories as described below:
    • Fully experienced components
    • Partial experience components
    • Off-the-shelf components
    • New components
fully experienced components
Fully Experienced Components
  • These are the specifications, designs, code or test data that were developed for previous projects and are similar to the software that is to be built.
  • The team members are fully experienced in the application area represented by these components.
  • Not only will the time required to develop the project be lesser but also modifications required for such fully-experienced components will carry less risk.
partial experience components
Partial Experience Components
  • These are the specifications, designs, code or test data that were developed for previous projects and are somewhat similar to the software that is to be built but require substantial modifications.
  • The team-members are not very well experienced in the application area represented by these components.
  • Hence, these kinds of components will carry more risk. However, since the team has at least some experience on a similar project, the time taken for this will not be substantial.
off the shelf and new components
Off-the Shelf and New Components
  • Off-the-shelf components
    • These are the components that can be acquired from a third party or may have been developed internally for a past project.
    • These components are ready to use and do not require any modification.
  • New components
    • Since these components do not exist in any form, new components have to be built by the team.
    • This is very time-consuming.
other resources
Other Resources
  • Other resources could be
    • The infrastructure in terms of hardware and software required to implement the project.
    • The platform or the operating system,
    • The necessary hardware components,
    • And additional software utilities that may be required – all come under this category.
measure metrics and indicator
Measure, Metrics, and Indicator
  • Measure -- Provides a quantitative indication of the extent, amount, dimensions, capacity, or size of some product or process attribute.
  • 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 for each).
  • Metric -- A quantitative measure of the degree to which a system, component, or process possesses a given attribute.
  • Software Metrics -- refers to a broad range of measurements for computer software.
  • A software metric relates the individual measures in some way (e.g., the average number of errors found per review or the average number of errors found per person-hour expended on reviews).
  • Indicator -- a metric or combination of metrics that provide insight into the software process, a software project, or the product itself.

Process Indicator

  • enable insight into the efficacy of an existing process.
  • to assess the current work status.
  • Goal -- to lead to long-term software process improvement.

Project Indicator

  • assess the status of an ongoing project
  • track potential risks
  • uncover problem areas before they “go critical”.
  • adjust workflows or tasks.
  • evaluate the project team’s ability to control the product quality.
process metrics and software process improvement
Process Metrics and Software Process Improvement


Customer characteristics

Business conditions




Development environment

  • What to measure?
    • errors uncovered before release.
    • defects delivered to and reported to end users.
    • work products delivered.
    • human effort expended.
    • calendar time expended.
    • schedule conformance.
  • At what level of aggregation?
    • By team?
    • Individual?
    • Project?
person month
Person Month
  • Person month is the amount of time one person spends working on the software development project for one month.
  • This number is exclusive of holidays and vacations but accounts for weekend time off.
  • The number of person months is different from the time it will take the project to complete; this is called the development schedule.
    • "A project may be estimated to require 50 PM of effort but have a schedule of 11 months."
  • To translate percent effort into person months, use this formula:

% Effort x # Months Pay x % Appointment = Person Months


Professor XYZ has an appointment for nine months. He will expend 10 percent of his effort on a postgraduate project for the academic year, and 66 percent effort in teaching undergraduate students for three months. Person months are calculated as follows:

lines of codes loc
Lines of Codes (LOC)
  • Length of a software system is measured in terms of lines of code (LOC).
  • This model assumes that there is a linear relationship between system size and volume of documentation.
  • LOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate programming productivity or effort once the software is produced.
  • Broadly speaking, there are two types of LOC:
  • Physical LOC: A count of lines in the text of the program's source code including comment lines.
  • Logical LOC: Logical LOC attempts to measure the number of "statements", but their specific definitions are tied to specific computer languages (one simple logical SLOC measure for C-like programming languages is the number of statement-terminating semicolons).
  • Some organizations do not count Blank and comments lines. However, some organizations also include blank lines unless the lines of code in a section consists of more than 25% blank lines. In this case blank lines in excess of 25% are not counted toward lines of code.
loc based estimation
LOC Based Estimation
  • Let us take one simple instance where different categories of programming tasks involved in the project are mapped with the estimated lines of code and approximate person-days to complete each task.
  • Effort is calculated based on the assumption that a person will write one KLOC of code per day.
  • The total effort as we can conclude from the table would be approximately 45 person days

for (i=0; i<100; ++i)




/* Now how many lines of code is this? */

In this example, we have:

4 physical LOC

2 logical LOC

1 comment line

a model of project metrics
A Model of Project Metrics
  • Every project should measure
  • Inputs—measures of the resources (e.g., people, environment) required to do the work.
  • • Outputs—measures of the deliverables or work products created during the software engineering process.
  • •Results—measures that indicate the effectiveness of the deliverables.
software metrics
Software Metrics
  • Direct Measures:
    • Cost and effort applied.
    • Lines of Code (LOC) produced.
    • Execution speed
    • CPU utilization
    • Memory size
    • Defects reported over certain period of time.
  • Indirect Measures:
    • Functionality, quality, complexity, efficiency, reliability, maintainability.
size oriented metrics
Size-Oriented Metrics
  • are derived by normalizing quality and/or productivity measures by considering the “size” of the software that has been produced.
  • Lines of Codes often as normalization value.









alpha 12,100 24 168 365 134 29 3

beta 27,200 62 440 1224 321 86 5

gamma 20,200 43 314 1050 256 64 6

. . . . .

. . . . .

. . . . .


typical size oriented metrics
Typical Size-Oriented Metrics
  • Errors per KLOC
  • Defects per KLOC
  • Dollars/rupees per KLOC
  • Pages of documentation per KLOC
  • Errors per person month
  • LOC per person month
  • Dollars per page of documentation.
function oriented metrics
Function-Oriented Metrics
    • Use “functionality” to measure
    • Derived from “function point (FP)”
    • Using an empirical relationship
    • Based on countable (direct) measure of SW information domain and assessments of software complexity.
  • Use of Function-Oriented Metrics
    • Measuring scale of a project
    • Normalizing other metrics, e.g. $/FP, errors/FP
function point fp
Function Point (FP)
  • Function Point Analysis was developed first by Allan J. Albrecht in the mid 1970s.
  • It was an attempt to overcome difficulties associated with lines of code as a measure of software size.
  • It is designed to estimate and measure the time, and thereby the cost, of developing new software applications and maintaining existing software applications.
  • Function Point count can be applied to development projects, enhancement projects and existing applications as well.
  • It is also useful in comparing and highlighting opportunities for productivity improvements in software development.
function point
Function Point

Five Major Components of FP Analysis

  • Number of user inputs: Each user input that provides distinct application oriented data to the software is counted. Inputs should be distinguished from inquiries, which are counted separately.
  • Number of user outputs: Each user output that provides application oriented information to the user is counted. In this context output refers to reports, screens, error messages, etc. Individual data items within a report are not counted separately.
  • Number of user inquiries: An inquiry is defined as an on-line input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted.
function point1
Function Point

Five Major Components of FP Analysis

  • Number of Files: Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file) is counted.
  • Number of External Interfaces: All machine readable interfaces (e.g., data files on storage media) that are used to transmit information to another system are counted.
function point2
Function Point
  • Evaluating Complexity:
  • Using a complexity table, each of the 5 basic entity is evaluated as :
    • low
    • average
    • high
  • Complexity table uses 3 attributes for decisions
    • # of Record Element Types (RET): e.g. employee data type, student record type etc.
    • # of unique attributes (fields) or Data Element Types (DET) for each record : e.g. name, address, employee number, and hiring date would make 4 DETs for employee data type.
    • # of File Type Referenced (FTR): e.g an external payroll record file that needs to be accessed etc.
function point3
Function Point

For Logical Files and External Interfaces (DATA):

# of RET1-19 DET20-50 DET50+ DET

1 Low Low Ave

2 -5 Low Avg High

6+ Avg High High

For Input/Output/Query (TRANSACTIONS):

# of FTR1-4 DET5 -15 DET16+ DET

0 - 1 Low Low Ave

2 Low Avg High

3+ Avg High High

5 Basic Entity Types uses the RET, DET, and FTRfor Complexity Evaluation

function point calculation
Function Point Calculation
  • Function points are computed by completing the following table:

Weighting Factor

Measurement parameter count simple average complex

number of user inputs 3 4 6 =

number of user outputs  4 5 7 =

# of user inquiries 3 4 6 =

number of files 7 10 15 =

# of external interfaces5 7 10 =


function point calculation1
Function Point Calculation

Then use the following formula:

where TCF is called the Technical Complexity Factor

which is computed as

In the above equation, (Fi), i= 1,2,3, ... are called the

Complexity Adjustment Values. See the next slide for

its computation.


errors per FP

defects per PF

Dollars per FP

pages of Documentation per FP

FP per person month.

function point calculation2
Function Point Calculation

The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the following questions:

1. Does the system require reliable backup and recovery?

2. Are data communications 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?

9. 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 change and ease of use by the user?

function point calculation3
Function Point Calculation
  • Once function points have been calculated, the following
  • attributes may be calculated:
  • Errors per FP
  • Defects per FP
  • $ per FP
  • Pages of documentation per FP
  • FP per person month.

Computing Function Points:

Rate each factor on a scale of 0 to 5

example 1
Example 1


3 simple X 2 = 6

4 average X 4 = 16

1 complex X 6 = 6


6 average X 5 = 30

2 complex X 7 = 14


5 complex X 15 = 75


8 average X 4 = 32


3 average X 7 = 21

4 complex X 10 = 40

Count Total= 240

example 11
Example 1

Continuing our example . . .

Complex internal processing = 3

Code to be reusable = 2

High performance = 4

Multiple sites = 3

Distributed processing = 5

Fi = 17


FP = Count Total X [0.65 + (Fi X 0.01)]

= 240 X [0.65 + ( 17 X 0.01)]

= 240 X [0.82]

= 197


But how long will the project take and how much will it cost?

  • Suppose programmers in our organization average 18 function points per month. Thus . . .

197 FP divided by 18 = 11 person-months

  • If the average programmer is paid Rs. 5,200 per month (including benefits), then the [labor] cost of the project will be . . .

11 person-months X Rs. 5,200 = Rs. 57,200

example 2
Example 2

Requirement: ability or functionality to add a new employee to the system.

  • Data: employees information involves:
    • Three external files. Each has a different Record Element Type (RET):
    • Employee Basic Information has employee data records
      • Each employee record has 55 fields (1 RET and 55 DET) - AVERAGE
    • Employee Benefits records
      • Each benefit record has 10 fields (1 RET and 10 DET) - LOW
    • Employee Tax records
      • Each tax record has 5 fields ( 1 RET and 5 DET) - LOW
  • Transaction:Adding a new employee involves 1 input transaction which involves 3 file types referenced (FTR) and a total of 70 fields (DET). So for the 1 input transaction the complexity is HIGH.

Note that the minimum value of Fi = 0 and its maximum value is 70,

which shows that 0.65  TCF  1.35. Assume that TCF = 1.15

FP = Count_totalTCF = 23  1.15 = 26.45

  • Total_Count:
    • 1 external interface (average) = 7
    • 1 external interface (low) = 5
    • 1 external interface (low) = 5
    • 1 input (high) = 6

Count_total = 7 + 5 + 5 + 6 = 23

Calculate the Technical Complexity Factor (TCF):

function point extensions
Function Point Extensions

Feature Points:

  • Feature Point method was introduced by Capers Jones in 1986 for Software Productivity Research Inc.
  • Feature Point measure accommodates applications in which algorithmic complexity is high such as real time software, systems software, embedded software.
  • Algorithm is defined as the set of rules which must be completely expressed to solve a significant computational problem.
3d function point
3D Function Point
  • Data Dimension:
    • The data dimension is evaluated in much the same way as described earlier. Counts of retained data (the internal program data structure; e.g., files) and external data (inputs, outputs, inquiries, and external references) are used along with measures of complexity to derive a data dimension count.
  • Functional Dimension:
    • The functional dimension is measured by considering “the number of internal operations required to transform input to output data.
    • “transformation” is viewed as a series of processing steps that are constrained by a set of semantic statements.

Control Dimension:

The control dimension is measured by counting the number of transitions between states.

3d function point1
3D Function Point
  • Functional dimension
    • transformation is viewed as a series of processing steps and semantic statements that cooperate to transform one set of input data into a set of output data.
    • semantic statements: the predicated and the pre- and post-conditions for each step of the process.
    • Input and output do not necessarily refer to the input and output transactions that are part of the data dimension.
    • Processing that changes only the structure, format, or order of the data is not a transformation.
3d function point2
3D Function Point
  • Control Dimension:

Control dimension is measured by summing the counts of both states and transitions.

    • A state is a set that contains one and only one- value for each condition of interest in the application. Any time the value of any data element in the internal data structure changes, the state of the application also changes.
    • A transition is a valid path from one state to another, or to the same state

State Transition Diagram

full and start


invoke manage-copying




invoke read-op-input

copies done

invoke read-op-input

making copies

reloading paper


invoke reload paper


invoke problem-diagnosis

not jammed

invoke read-op-input

problem state


Weight Factor


measurement parameter








3 +


4 +


6 =



4 +


5 +


7 =



3 +


4 +


6 =

Internal Data


7 +


10 +


15 =

External Data


5 +


7 +


10 =



7 +


10 +


15 =



N/A +


3 +


N/A =

Total 3D Function Point

Weights to Calculate 3 D Function Point


Compute 3D function point value for an embedded system with following characteristics.

  • Internal data structures = 6,
  • External data structures = 3,
  • No. of user inputs = 12,
  • No. of user outputs = 60,
  • No. of user enquiries = 9,
  • Transformation = 36,
  • Transition = 24

Assuming the complexity of the above counts is average.


Measurement Parameter Count Weight Functional Count

No: of user inputs 12 3 36

No: of user outputs 60 5 300

No: of user enquiries 9 4 36

Internal data structures 6 10 60

External data structures 3 7 21

Transformations 36 5 180

Transitions 24 - 24

Count Total657

Nowassume that 14 questions have been counted and are equal to

Fi (i= 1,2,3,….,14) = 42

First we shall compute function points:

an example of fp based estimation
An Example of FP based Estimation

Consider the following Table

complexity adjustment values factors
Complexity Adjustment Values/factors
  • backup and recovery 4
  • Data communications 2
  • Distributed processing 0
  • Performance critical 4
  • Existing operating environment 3
  • On-line data entry 4
  • Application designed for change 5
  • Total 52

Complexity factor =

= 0.65+0.01×52 = 1.17

  • FP estimate = count_total

= 318  1.17 = 372

If average productivity is 6.5 FP/PM and labour rate = $8000,

cost per FP= 372$8000/6.5 = $457,000

reconciling different metrics
Reconciling different metrics

The following table provides rough estimates of the average number of lines of code required to build one function point in various programming languages:

software productivity
Software Productivity
  • A measure of the rate at which individual engineers involved in software development produce software and associated documentation.
  • This is determined by dividing the total size of the finished product by the total effort of all the programmers.
  • Its unit is LOC/personal day or FP/personal day.

The lower level the language, the more productive the programmer

    • The same functionality takes more code to implement in a lower-level language than in a high-level language.
  • The more verbose the programmer, the higher the productivity
    • Measures of productivity based on lines of code suggest that programmers who write verbose code are more productive than programmers who write compact code.

Company XYZ spent the following effort for each life cycle phase of the latest project (see Table). Calculate the effort in terms of LOC/programmer-day and in terms of function points/programmer day. The function point estimate was 50 unadjusted function points. The finished project included 950 lines of code.

Effort during phases


Total Effort = 65

Productivity = LOC/Total Efforts

= 950/65

= 14.6 LOC/programmer’s day.

measures of software quality
Measures of Software Quality
  • Correctness:
    • Is the degree to which the software performs its required function. The most common measure for correctness is defects per KLOC.
  • Maintainability:
    • the ease that a program can be corrected.
    • adapted if the environment changes.
    • enhanced if the customer desires changes in requirements.
    • based on the time oriented measure mean time to change.
measures of software quality1
Measures of Software Quality
  • Integrity:
    • To measure a system’s ability to withstand attacks (both accidental and intentional) on its security threat and security . It is defined as,
  • Usability:

- an attempt to quantify “user friendliness”.

    • Physical/intellectual requirement to learn.
    • time required to become moderately efficient.
    • The net increase in productivity.
    • User attitude towards system.
measures of software quality2
Measures of Software Quality
  • Defect Removal Efficiency:

A Quality Metric That Provides Benefit at Both the Project and Process Level

DRE = E / ( E + D )

E = # of errors found before delivery of the software to the end user

D = # of defects found after delivery

  • More generally,

DREi = Ei / ( Ei + Ei+1 )

Ei = # of errors found during SE activity i

summary view
Summary View

Software Engineering process

Software project

Data Collection


Software product

Metrics Computation





software equation
Software Equation

The software equation is a dynamic multivariable model that assumes a specific distribution of effort over the life of a software development

The equation has the following form:


E = effort in person months or person years.

t = project duration in months or years.

B = Special skills factor. For KLOC (5, 15) use B = 0.16, for KLOC > 70, use B = 0.39

P = Productivity parameter.

LOC = Lines of Code.


The productivity parameter reflects:

• Overall process maturity and management practices

• The extent to which good software engineering practices are used

• The level of programming languages used

• The state of the software environment

• The skills and experience of the software team

• The complexity of the application

Typical values of the productivity parameter might be P = 2,000 for development of real-time embedded software; P = 10,000 for telecommunication and systems software; P = 28,000 for business systems applications.


To simplify the estimation process and use a more common form for their estimation model, Putnam and Myers in 1992 suggested a set of equations derived from the software equation. Minimum development time is defined as

tmin = 8.14 (LOC/P)0.43

in months for tmin > 6 months

E = 180 Bt3

in person-months for E ≥ 20 person-months

Example: Let P = 12000 and LOC = 33200, compute tmin and E.

Solution: tmin = 12.6 calendar months,

E = 58 person-months.

  • You have been asked to develop a business system application in 6 months time. Using software equation calculate the effort required to complete the software if the total Loc are equal to 15000.
  • Consider the following parameters for the system development.

for small program KLC = 5 to 15 ………………… B = 0.16

for program greater than = 70 KLOC ……………B = 0.39

for embedded software P = 2000

for Telecomm and system software P = 10000

  • for Business application P = 28000


LOC = 15000

B = 0.16

P = embedded software = 2000

P = Telecomm & System software = 10000

P = Business application = 28000

t = 6 months = 0.5 years


E = BL3 / P3 t4

for Embedded software,

E = 0.16 (15000)3 = 1080 person year

(2000)3 (0.5)4


for Telecomm & System software,

E = 0.16 (15000)3 = 8.64 person years (10000)3 (0.5)4

for Business application,

  E = 0.16 (15000)3 = 0.39 person year

(28000)3 (0.5)4

cocomo model

COCOMO (Constructive Cost Model) was introduced by Barry Boehm and is one of the most frequently used cost models.

It consists of three different models of increasing complexity and level of detail.

It is well documented, available in the public domain and supported by public domain and commercial tools.

It has been widely used and evaluated in a range of organisations.

cocomo model1
  • COCOMO categorizes software projects being developed into three modes:
    • Organic,
    • Semi-detached and
    • Embedded.
organic mode
Organic Mode
  • Considerably small, simple software projects developed by small teams with good application experience with not-so-rigid requirements, fall into the organic mode.
  • Most people connected with this sort of projects have experience in working with related systems within the organization and have a thorough understanding of how the system under development will contribute to the projects goals.
semi detached mode
Semi-Detached Mode
  • An intermediate software project, where teams with mixed experience levels must meet a mix of rigid and less than rigid requirements, is categorized as semi-detached mode.
  • The semi-detached mode of software development represents an intermediate stage between organic and embedded modes.
  • Intermediate may mean:
    • Intermediate level of project characteristics.
    • A mixture of organic and embedded characteristics.
embedded mode
Embedded Mode
  • A software project that must be developed within a set of tight hardware, software and operational constraints is categorized under embedded mode.
  • The product must operate within a strongly fixed model of hardware, software and procedures.
cocomo model2
  • Basic Formulas:
    • The number of KLOC in Person Months as:

E = a(KLOC)b

    • The estimate of development schedule in months as:

DS = c(E)d

    • Number of Persons = PM/DS
  • COCOMO – I Model (Organic):

a = 2.4, b = 1.05, c = 2.5, d = 0.38.

  • COCOMO – II Model (Semi-Detached):

a = 3.0, b = 1.12, c = 2.5, d = 0.35

  • COCOMO – III Model (Embedded):

a = 3.6, b = 1.20, c = 2.5, d = 0.32

cocomo example
COCOMO - Example

Assume that you have been contacted by an Organization to develop CAD Software. After applying the size-oriented metrics an estimate of 33200 LOC is established. Using COCOMO model develop an effort, duration and no-of-person for CAD software. Consider the

a = 2.4, b = 1.05, c = 2.5, d = 0.35


E= 2.4 (33.2) ^ 1.05 = 94.93 person months

DS = 2.5 (94.93) ^ 0.35 = 12.30 months

No. of persons = 94.93 = 7.7 = 8 persons


cocomo example 2
COCOMO – Example 2
  • The project can be considered as an organic mode software project, where
    • Effort = E = 2.4 (KLOC) 1.05 = 2.4 (45)1.05 = 129 man months
  • Schedule = Time required
    • DS= 2.5 (E) 0.38 = 2.5 (129)0.38 = 16 person months

The In House systems department has received a request from the raw material stores to develop a program to keep track of raw materials. This would be similar to the program already developed successfully and running at the finished goods store. An initial study has determined that the size of the program will be 45,000 KLOC. Calculate an estimate of the effort and schedule.


make or buy decision
Make or Buy Decision
  • It is not always feasible to develop the software in-house.
  • There may be cost related reasons for this.
  • For instance, it may be less expensive to acquire the software rather than to develop it from scratch.
  • The decision to outsource the project or develop it in-house is a very critical one.
  • In case it is decided that the software has to be acquired instead of being developed in-house, a number of options may be considered.
  • Software may be purchased off-the shelf or acquired, modified and then integrated or custom built by an external source.
  • The steps involved in purchasing software externally are defined by the complexity of the software to be purchased and the end cost.
make or buy decision1
Make or Buy Decision
  • The figure below represents the project leader in a state of dilemma – to make or to buy.
guidelines in getting hold of expensive software products
Guidelines in getting hold of expensive software products
  • Build a specification for function and performance of the desired software with measurable characteristics whenever possible.
  • Estimate the cost involved in developing the required software in-house and estimate the delivery date.
  • Select three or four candidate applications that meet our specification or select reusable software components that will assist in constructing the required application.
  • Develop a comparison matrix that presents a detailed comparison of key features and functions or conduct benchmark tests to compare candidate software.
  • Evaluate each software package or component based on past product quality, vendor support, product direction reputation and so on.
  • Obtain the opinions of other users of the software.

Finally, the decision to build or purchase is made based on the following conditions:

    • Which of the delivery dates is the earliest - that of the acquired software product or that of the internally developed software?
    • Will the cost of acquisition plus the cost of customization be less than the cost of developing the software internally?
    • Will the cost of external maintenance support be less than the cost of internal support?
decision tree analysis
Decision Tree Analysis

All concepts can be described better using statistical methods like Decision Tree Analysis.

decision tree analysis1
Decision Tree Analysis
  • For example, to build a system from scratch, assume that there is a 60% chance of the job being too complex and 40% chance that the job will be easy.
  • Let us assume that it may cost $570K to build the software using the complex strategy and 650K to build using the simple development efforts.
  • Therefore, the estimated cost to build the software from scratch would be:
    • Expected cost build = 0.60 (570K)+0.40(650K)=602K
    • where, 0.60 and 0.40 are the path probabilities for complex and simple development strategies respectively.
  • Similarly, estimated costs for reuse, buying and contracting the software can be computed as follows:
    • Expected cost reuse=0.25(320K) + 0.75[0.3 (210K)+ 0.7(350K)]=311K
    • where, 0.25,0.75, 0.30 and 0.70 are the probabilities for various paths.
  • Expected cost buy=0.60(300K) + 0.40(400K)=340K
    • where, 0.60 and 0.40 are the probabilities for various paths.
  • Expected cost contract=0.7(400K)+0.3(500K)=430K
    • where, 0.70 and 0.30 are the probabilities for various paths.
decision tree analysis2
Decision Tree Analysis
  • Let us assume the need for a software project called Project A.
  • The project manager and his team may either build the system from scratch or acquire the software using the available schemes such as full experience and reusable components discussed earlier.
  • The formula to calculate costs depending upon activity and its complexity is as follows:

Expected cost activity = (path probability) activity x (estimated path cost) activity


Calculate the software cost for building, reusing, buying, and contracting a software system by considering the following decision tree diagram. What decision would you like for this kind of software system?


Formula: Expected cost =  (path probability) i x (estimated path cost) i


Expected cost (build) = (0.3) (380) + (0.7) (450) = 429

Expected cost (reuse)= (0.4) (275) + 0.6 [(0.2) (310) + (0.8) (490)]

= 382.4

Expected cost (buy) = (0.3) (210) + (0.6) (400) = 303

Expected cost (contract) = (0.6) (350) + (0.4) (500) = 410


Based on the probability and projected costs that have been given in tree, the lowest expected cost is in the “buy” option.

  • Outsourcing is the term used to describe the allocation of the software development responsibilities to a third party.
  • This is generally done to reduce costs and at the same time obtain higher quality of product.
  • However, outsourcing is not always feasible. There is a darker side to it as well.
  • It can mean dislocation of people, unwanted long term contractual relationships with third party vendors and numerous other disadvantages.
  • Only after the benefits to be gained are clearly outlined and the risks that may occur are understood and managed, should the company proceed with outsourcing.
reasons for outsourcing
Reasons for Outsourcing
  • Following are some well-researched reasons when and why a company should go in for outsourcing:
  • Improve the company focus
    • By letting an outside expert focus on the intricate details, the company can improve its focus on other broader issues.
    • Outsourcing is even considered as a management tool by many companies.
  • Gain access to world-class capabilities
    • By making use of third party vendors to provide solutions through outsourcing, a company gains access to better capabilities, even excellent capabilities. This is because the vendors are specialized in their skills and experience.
    • They may have worked for a number of years with similar clients and similar projects, which will make it very easy for them to implement their skills.
  • Free the resources for other purposes
    • Most organizations have limits on the resources available to it.
    • There is always a need to ensure that its limited resources are utilized in the most valuable areas.
    • Outsourcing allows an organization to redirect its resources from less-important activities towards more important activities, which have greater returns in serving the customer.
reasons for outsourcing1
Reasons for Outsourcing
  • Reduce and control operating costs
    • Many a times, building software in-house will incur more expenses because there may be new software to be installed; new systems to be purchased and a host of such expenses come into picture.
    • Here, outsourcing can come to the rescue and reduce operating costs.
  • Resources are not available internally
    • Not all companies have access to the required resources within the organization. In such cases, they can go in for outsourcing.
    • Take an instance of an organization expanding its operations into a new geographical location. In this case, outsourcing is a feasible and important alternative to building the needed capability from the ground up.
  • Functions are too difficult to manage or control
    • If functions are too complex, the time taken to understand and develop them may be too long. In such situations, it is far more feasible to outsource the work to a third-party who is well versed with similar functionalities and does the work faster rather than developing the software in-house.