Software Project Management

Project management is the discipline of defining

and achieving targets while optimizing the use of
resources(time , money , people , material , energy
, space etc.)
Why is Software Project Management important?

•Manage Budget
•Improve Productivity
•Manage Risks
•Customer Satisfaction
•Careful Resource Management
 Activities of Project Management
Project management plan begins with a set of
activities that are involved in the development.
Overview of the project
Project deliverables
Managerial processes
Technical processes
Work packages
Schedule of the project
Budget estimation
 Characteristics of Project
Planning of process is required.
Clear objective have to be specified.
Project must have a predetermined time span.
Involves different phase of work.
Resources used on the project are constrained.
 Software Development Life Cycle
1. Requirement Analysis
2. Feasibility Study
3. Designing
4. Coding
5. Testing
6. Deployment
7. Maintenance
 Project Management Methodologies

Project management methodologies are a set of

guiding principles and processes used to
plan ,manage and execute projects.
The project management methodology you choose
determines how work is prioritized and
completed.
Waterfall Methodology
Agile Methodology
 Waterfall Methodology
• Waterfall is a top down approach to project management
• During the early stages of a Waterfall project , project
managers outline all the steps to the project upfront ,
including the schedule, scope and budget.
• Waterfall involves investing a significant amount of time
planning at the beginning stages of the project to set
requirements and minimize the risk of problems arising
later on during the process.
• With waterfall , the current phase of the project must be
completely finished before moving to the next phase.
 Agile Methodology
• At a very basic level , Agile allows your
company and teams to work in short burst on
very particular deliverables.
• At the end of the short burst of time called an
“iteration”.
• This allows teams to adjust their focus pivot
when a customer changes their mind in the
middle of the product build, and change priorities
as expectations and feature requirements change.
Categorization of Software Projects
• Different characteristics of a project could
affect the way in which it should be planned
and managed.
• Some of these are:
• Compulsory vs voluntary users
• Information systems vs embedded systems
• Objective driven development vs product
driven development.
 Compulsory vs voluntary system

• Compulsory User: ID card based attendance

system is compulsory systems.

• voluntary system : MS word, MS power point ,

Games, Google like system as the organization
may or may not use these application system.
This is called voluntary system
Information systems vs embedded systems

• Information systems : Any data in or out system

like stock control , Document management
system , are called information system.
• embedded systems : system which
automatically controls the temperature in
buildings, sequencing in a washing machine,
window or linux like operating system in a
computer are called embedded system.
 Objective driven development vs product
driven development
• Objective driven development: It is satisfy a
specific goal.
• Ex. A patient registration system in a hospital
to avoid long queue at the receptions , to make
20 % profit etc.
• Product driven development: To produce a
software product meant for multiple users at
multiple geographical locations around the
world are called product driven projects.
 Setting objectives
• Objective refers to the end results which are
to be accomplished by an organization
through their plan or strategy over a specific
period of time.
• Project objective should be SMART.
 Objectives should be SMART
• S-Specific: The goal should target a specific area of
improvement or answer a specific need. Define your
objectives clearly and detail.
• Think of the five words(why, what, when , where and
who)
 Why: are you proposing thing?
 What:approach will you adopt to reach the desired goal?
 When:will you conduct the particular project?
 Where: will you implement the project?
 Who: will be the doing a particular thing in a project?
 Objectives should be SMART
• M-Measurable: State the measures and performance
specifications you will use to determine whether you
have met your objectives.
• A-Achievable: choose objectives that the team has a
reasonable expectation of successfully completing.
• R-Relevant: Set objectives the project team believes
it can achieve. Relevant objectives align with group or
company goals.
• T-Time Constrained: there is defined point in time by
which the objective should be achieved.
 Management Principles
• Planning – Deciding what is to be done.
• Organizing- Making Arrangements.
• Staffing - Selecting the right people for the job.
• Directing- Giving Instructions.
• Monitoring- Checking on progress.
• Controlling – Taking action to remedy hold-up
• Innovating –Coming up with new solutions.
• Representing –Liaising with clients , users,
developers ,suppliers.
 Management Control
• A management control is concerned with
 Coordination
 Resource allocation
 Motivation
 Performance measurement.
Project portfolio management

• Project portfolio management is management

process which helps the organization to
acquire information and sort out projects
according to a set of criteria.
Objective of Project Portfolio Management

When it comes to the objectives the following

factors need to be outlined
• Need to create a descriptive document which
contains vital information such as name of project,
estimated timeframe , cost and business objectives.
• The project needs to be evaluated on a regular basis
to ensure that the project is meeting its target and
stays in its course.
• Selection of the team members who will work
towards achieving the project’s objective.
Benefits of project portfolio management

• Greater adaptability towards change.

• Constant review and close monitoring brings
about a higher return.
• Identification of dependencies is easier to
identify .this will eliminate some inefficiency
from occurring.
Cost benefit Evaluation Techniques
• Project Cost benefit evolution usually requires
comparing costs and benefits from different time
periods.
• Cash flow forecasting can be compared for
different projects based on
• Net profit
• Payback period
• Return on Investment
• Net present value
 Process

Identification of Cost and Benefit

Evaluation of Cost and Benefit

Choice of System
 • Cost Benefit Evaluation Techniques

1. Pay Back Analysis 2. Net Present Analysis 3. Return on

investment

• Pay Back Analysis = Investment Requirement/ Net annual cash in flow

• Net Present Value = Net Period Cash in flow / (1+r)^n

Cash in flow= Benefit - Cost

• Return on investment = (estimated life time benefit – estimated life time

cost)/estimated life time cost
Cost benefit Evaluation Techniques
• Net profit: Net profit of a project is the difference
between the total costs and the total income over the
life of the project.
• Payback Period: The time taken to break even or pay
back the initial investment.
• Return on investment(ROI): Also known as the
accounting rate of return (ARR) provides a way of
comparing the net profitability to the investment
required.
• ROI= (average annual profit/total investment)*100
Cost benefit Evaluation Techniques
• Net Present value(NPV): The calculation of
net present value is a project evaluation
technique that takes into account the
profitability of a project and the timing of cash
flows that are produced
 Risk Evaluation
• Project Risk: prevent the project from being
completed successfully.
• Business risks: prevent the project from being
profitable.
Risk Evaluation Process
 Risk identification and ranking
• Approach: constructing project risk matrix utilizing a
checklist of possible risks and classify according to
its relative importance and likelihood.
• The table illustrates a basic project risk matrix listing
some of the business risk for a project with their
importance and likelihood classified as high(H),
Medium(M), low(L)or exceedingly unlikely(_)
Project risk matrix for an e commerce
application
 Risk and Net present value
• If project is relatively risky , then use higher
discount rate to calculate NPV .
• Reasonably safe project : additional 2% risk
premium
• Fairly risky project: additional 5% risk premium.
• Risk are generally categorized using scoring
methods … and risk premiums can be designated
for each category.. Some means of considering
risk…
 Cost benefit analysis
• It is required to consider each possible outcome.
• Estimate the probability of its occurring and the
corresponding value of the outcome.
• Instead of single cash flow consider set of cash flow
forecast
• Each with an associated probability of occurring.
• The value of the project is then obtaining by
summing the cost or benefit for each possible
outcome weighted by its corresponding probability .
 Risk profit Analysis
• This make use of “risk profile” using
sensitivity analysis.
• It compares the sensitivity of each factor of
project profile varying parameters which affect
the project cost benefits.
Using Decision Trees
 Strategic Program Management
• Strategic Project Management defines how a
project may benefit a company’s efficiency
and strategic plan as a whole.

• It is the process of thinking about your

strategic plan.
 Tasks of Strategic Program Management

• The Strategic program manager will work

across a variety of business and technical
teams as needed to
• Manage resources
• Schedules
• Financials
• Adhere to stage gate quality
• Ensure successful and on time project delivery
Strategic Program Management Process
Step wise Project Planning
 Step wise Project Planning
• Planning is the most difficult process in
project management. The framework
described is called the Stepwise method to
help to distinguish it from other methods.
 Step 0 and Step 1
• Step 0: Select Project
• Step 1: Identify project scope and objectives

• Step 1.1 : Identify objectives and practical measures of the effectiveness in meeting
those objectives

• Step 1.2 : Establish a project authority

• Step 1.3 : Stakeholder analysis - identify all stakeholders in the project and their
interests.

• Step 1.4 : Modify objectives in the light of stakeholder analysis.

• Step 1.5 : Establish methods of communication with all parties.

 Step 2
• Step 2 : Identify project infrastructure

• Step 2.2 : Identify installation standard and procedures

• Step 2.3 : Identify project team organization

 Step 3
• Step 3 : Analyze project characteristics
• Step3.1:Distinguish the project as either objectives- or
product-driven.
• Step 3.2 : Analyze other project characteristics
• Step 3.3 : Identify high-level project risks
• Step 3.4 : Take into account use requirements concerning
implementation
• Step 3.5 : Select development methodology and life-cycle
approach
• Step 3.6 : Review overall resource estimates
 Step 4
• Step 4 : Identify project products and activities

• Step 4.1 : Identify and describe project products

• Step 4.2 : Document generic product flows

• Step 4.3 : Recognize product instances

• Step 4.4 : Produce ideal activity network

• Step 4.5 : Modify the ideal to take into account need for stages and
checkpoints
 Step 5
• Step 5 : Estimate effort for each activity

• Step 5.1 : Carry out bottom-up estimates - distinguish

carefully between effort and elapsed time.

• Step 5.2 : Revise plan to create controllable activities- breakup

very long activities into a series of smaller ones- bundle up
very short activities
 Step 6
• Step 6 : Identify activity risks
• Step 6.1 : Identify and quantify activity based risks -
damage if risk occurs- likelihood if risk occurring

• Step 6.2 : Plan risk reduction and contingency measures -

risk reduction : activity to stop risk occurring -
contingency : action if risk does occurs

• Step 6.3 : Adjust overall plans and estimates to take

account of risks
 Step 7
• Step 7 : Allocate resources

• Step 7.1 : Identify and allocate resources

• Step 7.2 : Revise plans and estimates to take into account

resource constraints
 Step 8,9,10
Step 8 : Review/ Publicize plans

Step 8.1 : Review quality aspects of the project plan

Step 8.2 : Document plans and obtain agreement

Step 9 and 10 : Execute plan. Lower levels of

planning
 Software Process
• Software process is the set of activities and
associated outcome that produce a software
product.

• Software engineers mostly carry out these

activities .
 Activities of Software Process
• There are four key process activities which are
common to all software processes . These
activities are:
1. Software Specification
2. Software Development
3. Software Validation
4. Software evolution
1. Software Specification: The functionality of the
software and constraints on its operation must be
defined.

2. Software Development: The software to meet

the requirement must be produced.

3. Software Validation: The software must be

validated to ensure that it does what the customer
wants.

4. Software Evolution: The software must evolve

to meet changing client needs.
 The Software Process Model
• A software process model is an abstract
representation of the development process.

• Software process model specify the stages and

order of a process .

• Software process model is a representation of

the order of activities of the process and the
sequence in which they are performed.
A model will define the following :
• The task to be performed.

• The input and output of each task.

• The pre and post conditions for each task.

• The flow and sequence of each task.

 Goal of Software Process Model
• The goal of software process model is to
provide guidance for controlling and
coordinating the task to achieve the end
product and objectives as effectively as
possible.
 Factors in choosing a software process
• You need to keep the following factors in mind when
selecting your software process model.
• Project Requirement: Before you choose a model,
take some time to go through the project
requirements and clarify them alongside your
organization’s or team’s expectations. Will the user
need to specify requirements in detail after each
iterative session? Will the requirements
change during the development process?
•
• Project size
• Consider the size of the project you will be working on. Larger projects mean bigger
teams, so you’ll need more extensive and elaborate project management plans.

• Project complexity
• Complex projects may not have clear requirements. The requirements may change
often, and the cost of delay is high. Ask yourself if the project requires constant
monitoring or feedback from the client.

• Cost of delay
• Is the project highly time-bound with a huge cost of delay, or are the timelines flexible?

• Customer involvement
• Do you need to consult the customers during the process? Does the user need to
participate in all phases?

• Familiarity with technology

• This involves the developers’ knowledge and experience with the project domain,
software tools, language, and methods needed for development.
• Project resources
• This involves the amount and availability of funds, staff, and other resources.
 Types of software process model
• Agile Model
• RAD Model
 Agile Model
• Agile process model" refers to a software
development approach based on iterative
development.
• Agile methods break tasks into smaller iterations.
• The project scope and requirements are laid down at
the beginning of the development process.
• Plans regarding the number of iterations, the duration
and the scope of each iteration are clearly defined in
advance.
• Each iteration is considered as a short time "frame" in the
Agile process model, which typically lasts from one to four
weeks.

• The division of the entire project into smaller parts helps to

minimize the project risk and to reduce the overall project
delivery time requirements.

• Each iteration involves a team working through a full software

development life cycle including planning, requirements
analysis, design, coding, and testing before a working product
is demonstrated to the client.
 Phases of Agile model
• Following are the phases in the Agile model
are as follows:
• Requirements gathering
• Design the requirements
• Construction/ Iteration Testing
• Quality Assurance
• Deployment
• Feedback
Phases of Agile model
• 1. Requirements gathering: In this phase, you must define
the requirements. You should explain business opportunities
and plan the time and effort needed to build the project. Based
on this information, you can evaluate technical and economic
feasibility.

• 2. Design the requirements: When you have identified the

project, work with stakeholders to define requirements. You
can use the user flow diagram or the high-level UML diagram
to show the work of new features and show how it will apply
to your existing system.
• 3. Construction/ iteration: When the team defines the requirements, the
work begins. Designers and developers start working on their project,
which aims to deploy a working product. The product will undergo
various stages of improvement, so it includes simple, minimal
functionality.

• 4. Testing: In this phase, the Quality Assurance team examines the

product's performance and looks for the bug.

• 5. Deployment: In this phase, the team issues a product for the user's
work environment

• 6. Feedback: After releasing the product, the last step is feedback. In this,
the team receives feedback about the product and works through the
feedback.
 RAD Model
• RAD stands for Rapid Application Development model.
• This helps in developing the software in short span.
• This model puts less emphasis on planning tasks and more emphasis on
development and coning up with a prototype.
• The initial activity starts with the communication between customer and
developer for gathering requirements.
• Then the requirement are divided into groups.
• Planning is more important to work together on different modules.
• In this the components or functions are developed in parallel as if they
were mini project.
• The developments are time boxed delivered and then assembled into a
working system.
• The most vital point for this model to be successful is to make sure that the
prototypes developed are reusable.
 The various phases of RAD are as follows:

• 1.Business Modeling: The information flow among business

functions is defined by answering questions like
• what data drives the business process,
• what data is generated,
• who generates it,
• where does the information go,
• who process it and so on.
• 2. Data Modeling: The data collected from business modeling is
refined into a set of data objects (entities) that are needed to
support the business.
• The attributes (character of each entity) are identified,
• the relation between these data objects (entities) is defined.
• 3. Process Modeling: The information object defined
in the data modeling phase are transformed to achieve
the data flow necessary to implement a business
function. Processing descriptions are created for
adding, modifying, deleting, or retrieving a data
object.
• 4. Application Generation: Automated tools are
used to facilitate construction of the software; even
they use the 4th GL techniques.
• 5. Testing & Turnover: Many of the programming
components have already been tested since RAD
emphasis reuse. This reduces the overall testing time.
But the new part must be tested, and all interfaces
must be fully exercised.
 When to use RAD Model?

• There is a need to create a system that can be

modularized in 2 3 months of time.
• It should be used if there is high availability of
designers for modeling and the budget is high
enough to afford their cost of automated code
generating tools.
• RAD should be chosen only if resources with
high business knowledge are available.
 Advantage of RAD Model

• Reduced development time.

• Increase reusability of component
• Encourages customer feedback
• Changing requirements can be accommodated.
 Disadvantage of RAD Model

• It required highly skilled designers.

• All application is not compatible with RAD.
• For smaller projects, we cannot use the RAD
model.
• On the high technical risk, it's not suitable.
 DSDM (Dynamic System Development
Model)
• DSDM works on same principle of agile development including
continuous user/ customer involvement.

• Framework of DSDM is an iterative and incremental approach that was first

conceived in 1994 when project manager using another agile framework Rapid
Development Model RAD .

• Dynamic System Development Method is a framework largely based around

Rapid Application Development (RAD) .

• It focuses on information system projects that are characterized by tight

schedules and budgets.

• The method’s primary aim is to deliver business needs and real time benefits.
DSDM also make sure that benefits are clear has feasible solution , with solid
foundation already in place before a project is started.
 The method has a four phase framework
namely:
1. Feasibility and business study.

2. Functional model/ prototype iteration

3. Design and build iteration.

4. Implementation.
• Feasibility and business study:
• In this phase the problem is defined and the technical
feasibility of the desired application is verified.

• It is also checked whether the application is suitable

for Rapid Application Development (RAD) approach
or not.

• The business requirements are specified at a high level

and the information requirements out of the system are
identified. Once this is done, the basic architectural
framework of the desired system is prepared.
• Functional model/ prototype iteration:
• The main focus in this phase is on building the
prototype iteratively and getting it reviewed from the
users to bring out the requirements of the desired
system. The prototype is improved through
demonstration to the user, taking the feedback and
incorporating the changes. Prototyping follows these
steps:
• Investigate
• Refine
• Consolidate
• Design and build iteration:
• This phase stresses upon ensuring that the prototypes
are satisfactorily and properly engineered to suit their
operational environment.

• The software components designed during the

functional modeling are further refined till they
achieve a satisfactory standard.

• The product of this phase is a tested system ready for

implementation.
• Implementation.
• In this phase the users are trained and the system is
actually put into the operational environment.
• At the end of this phase, there are four possibilities:
1. Everything was delivered as per the user demand, so no
further development required.
2. A new functional area was discovered, so return to business
study phase and repeat the whole process
3. A less essential part of the project was missed out due to time
constraint and so development returns to the functional model
iteration.
4. Some non-functional requirement was not satisfied, so
development returns to the design and build iterations phase.
The eight principles of DSDM are as follows:

1. Focus on the business need.

2. Deliver on time
3. Collaborate.
4. Never compromise quality.
5. Build incrementally from firm foundations.
6. Develop iteratively
7. Communicate continuously and clearly
8. Demonstrate control
 Disadvantages of DSDM
• Costly to implement
• Not be suitable for small organizations or one
time projects
 Extreme programming
• It is the type of Agile Development we
develop software with small team where the
software requirements changes rapidly.

• XP is summed up or based on twelve practices.

 Practices of XP
1. The planning process
2. Small Releases
3. Metaphor: use resemblance technique
4. Simple Design
5. Testing: make the test cases before implementation
6. Refactoring: change the design if features increase
7. Pair Programming: use standard naming convention
8. Collective ownership
9. Continuous Integration
10. 40 Hour Week
11. Onsite Customer
12. Coding Standard:
 Benefits of XP Programming
• Close contact with the customer
• No unnecessary programming work
• Stable software through continuous testing
• Error avoidance through pair programming
• No overtime teams work at their own pace.
• Changes can be made at short notice
• Code is clear and comprehensive at all time.
.
 XP Steps
1. Code Review: Code review detects and corrects
errors efficiently. It suggests pair programming
as coding and reviewing of written code carried
out by a pair of programmers who switch their
works between them every hour.
2. Testing: Testing code helps to remove errors
and improves its reliability . XP suggest test
driven development to continually write and
executes test cases . in this approach test cases
are written even before any code is written.
3.Incremental development: incremental
development is very good because customer
feedback is gained and based on this
development team come up with new
increments every few days after each iteration.
4. Simplicity: Simplicity makes it easier to
develop good quality code as well as to test
and debug it.
5. Design: Good quality design is important to
develop a good quality software . So every
body should design daily.
6. Integration Testing: it helps to identify bugs
at the interfaces of different functionalities .
Extreme programming suggest that the
developers should achieve continuous
integration by building and performing
integration testing several times a day.
 Managing Interactive Processes
• Managing People
• Act as project leader
• Liaison with stakeholders
• Managing human resources
• Setting up reporting hierarchy etc.
 Managing Interactive Processes
• Managing Project
• Defining and setting up project scope
• Managing project management activities
• Monitoring progress and performance
• Risk analysis at every phase
• Take necessary step to avoid or come out of
problems
• Act as project spokesperson
 Basics of Software Estimation
• Estimation determines how much money, effort,
resources, and time it will take to build a specific
system or product.
• Estimation is based on −
1. Past Data/Past Experience
2. Available Documents/Knowledge
3. Assumptions
4. Identified Risks
 Basics of Software Estimation
• The need for historical data
• Collect similar historical data /project data
• ISBSG contain from 4800 projects
• Parameters to be estimated
• Effort: in work month (wm)/person months(pm)
• Duration: in months
• Measure of work
• Size of the project – how many modules are there ,
lines of code , function point
• Vary based on the difficulty of software , experience of
developers , use of CASE tools
 Size of software project
SLOC: Source lines of codes
• Simple
• No precise definition comment lines
• Difficult to estimate at start of a project Accurate
• Only a code measure other life cycle activities
• Programmer dependent coding style
• Does not consider code complexity
2. FP: Function Point
Complex compared to SLOC
Accurate than SLOC
• Effort and Cost Estimation Techniques

• Algorithmic model: effort drivers

• Expert judgment : advice of the knowledgeable staff
• Analogy : with similar completed projects
• Parkinson : staff effort available
• Price to win: sufficiently low estimate to win a
contract
• Top down: overall estimate is broken down for tasks
• Bottom up: estimate of tasks are aggregated
 Bottom up estimating
• WBS
• Calculate effort for each activity
• Adding up the calculated effort for each activity to get an
overall estimate.
• More preferred when there is no historical data available .
• Procedural code oriented approach
• Envisage the number and type of software module in the final
system
• Estimate the SLOC of each identified module.
• Estimate the work content taking into account complexity and
technical difficulty
• Calculate the work days effort
 Top Down Approach
• Similar analogy to estimate the rough cost to build a
house.

• Effort = system size x productivity rate

• Productivity – varies with expertise

• Productivity = effort / size
 COSMIC Full Function Points:
• COSMIC function points are a unit of measure of software
functional size.

• The size is a consistent measurement (or estimate) which is very

useful for planning and managing software and related activities.

• The process of measuring software size is called functional size

measurement (FSM).

• Function points are used to compute a functional size measurement

(FSM) of software. The cost (in dollars or hours) of a single unit is
calculated from past projects.
• In COSMIC FFP measurement method, which is aimed at
measuring the functional size of software, only those
functional user requirements allocated to software are
considered.
• For instance : the functional user requirements in this example
are allocated to three distinct pieces, each exchanging data
with another through a specific organization:
– One piece of the software lies at the application level and
exchanges data with the software's users, and the second piece lies
at the operating system level.
– In turn, this second piece of the software exchanges data with a
third piece lying at the device driver level.
– This last piece then exchanges data directly with the hardware.
• The COSMIC FFP measurement method associates the
functional user requirements for each piece with a specific
layer. Each layer possesses an intrinsic boundary for which
specific users are identified.
 COCOMO II Model
• Developed by Barry Boehm.
• Revised version of original COCOMO.
• It includes 3 stages

1. Application Composition estimation

2. Early design estimation.
3. Post architecture estimation
• Application Composition Estimation Model

• Focus on those applications which can be quickly

developed using interoperable components.

• Ex : GUI , database management , control packages for

specific domains.

• Can also be used during prototyping phase of an

application.

• Size is estimated using object points

• 1. Screens 2. Reports 3. 3GL components
• Steps for Effort Estimation:
1. Assess object counts
• Estimate the number of screens, reports and 3G
components.

2. Classify complexity level of each object

• Classify each object into simple , medium , difficult
category.
• Classify screen on basis of views, sources
• Reports on the basis of sections , sources
 Screen on basis of views

Number of views Tab

Number & Sources of Data Tables
contained

Total < 4 Total <8 Total 8+

(<2 server) (2-3 server) (>3 server)
(<3 client) (3-5 client) (> 5 client)

<3 Simple Simple Medium

3-7 Simple Medium Difficult

>8 Medium Difficult Difficult

 Reports on the basis of section

Number of Section Tab

Number & Sources of Data Tables
contained(Reports
)
Total < 4 Total <8 Total 8+
(<2 server) (2-3 server) (>3 server)
(<3 client) (3-5 client) (> 5 client)

0 or 1 Simple Simple Medium

2 or 3 Simple Medium Difficult

4+ Medium Difficult Difficult

3. Assign complexity weight to each object
• Depending on the category of the object
Object Type Tab COMPLEXITY WEIGHT
MEDI

SIMPLE MEDIUM DIFFICULT

SCREEN 1 2 3

REPORT 2 5 8

3GL - - 10
COMPONENT
4. Determine Object Points
• Add all these complexity weight to get (Total)
object points.

5. Compute new object points

• NOP=( (object point)*(100-% reuse))/100
6. Calculate productivity rate(PROD):
• Calculate depending on the past projects data

Developer Experience, PROD= (NOP/PM)

capability, CASE Maturity
capability
Very low 4

low 7

Nominal 13

High 25

Very High 50
7. Compute Effort in Person Months
• Effort = NOP / PROD person months