Step Wise: An approach to planning

software projects

0 Select project
1 Identify project scope and objectives
1.1 Identify objectives and measures of
effectiveness in meeting them
• Correct definition of objectives.
• Identify measures of effectiveness
for your objectives.
1.2 Establish a project authority
A single overall project authority
needs to be established so that there
is unity of purpose among all those
concerned.
1.3 Identify stakeholders
1.4 Modify objectives in the light of
stakeholder analysis
• Based on the stakeholders
requirements, it might be
necessary to modify the project
objectives.
• E.g. Adding new features to the system.
• This has to be done in a controlled manner.
1.5 Establish methods of communication with all parties
• Communication between stakeholders is important in all kinds of projects
• It is more important to arrange for in a dispersed project.
• Communication plan
2 Identify project infrastructure
2.1 Establish relationship between project and strategic planning
• Technical framework within which the proposed new systems are to fit
• Hardware and software standards should be followed.
• The software or components to be created should be compatible with those created by previous projects and
with the existing HW and SW platforms.
2.2 Identify installation standards and procedures
• Identify standards and procedures related to the software project E.g. specifying quality checks needed at
each point of the project Life cycle
• The project manager should be aware of the Project planning and control standards.
• E.g How are hours spent by team members on tasks recorded on timesheets.
2.3 Identify project team organization
Example: A high level manager could decide that: software developers and business analysts could be in
different group
3 Analyse project characteristics
3.1 Distinguish the project as either objective- or product-driven
3.2 Analyse other project characteristics
3.3 Identify high-level project risks
3.4 Take into account user requirements concerning implementation
3.5 Select general life-cycle approach
3.6 Review overall resource estimates
4 Identify project products and activities
4.1 Identify and describe project products (including quality criteria)
• Identify all the products related to the project
Products can be:
• Deliverables.
 • Technical products (e.g. training material, operating instructions).
• Products for management and quality (e.g. planning documents).
Products will perform a hierarchy:
• Main products will have a set of components which in turn will have sub-components and so on.
• These relationships can be documented in a PBS product breakdown structure.

• Products (The result of an activity) can be:

• Created from scratch.
• Modified version of something.
• Document.
• Person.
• Not an activity.
Activity
• Training
• Testing
• Designing
• Documenting
Product Breakdown Structure.
• The tangible products are those at the bottom of the PBS that are not further subdivided.
• The boxes that are higher up are names of group of items.
• The products at the bottom of the PBS should be documented by Product Descriptions which contain.
• The name
• The purpose
• The derivation of the product. (What are the source products from which this product is derived?)
• The composition
• The form
• The standards
• Quality criteria of the product
4.2 Document generic product flows
• To document the relative order of the products.
• Some products will need other products to exist first before they can be
created.
• E.g.The program code to be written need the program design, the
program design needs the program specification.

• This can be portrayed in a PFD Product Flow Diagram.

• Flow is from top to bottom and and from left to right.
4.3 Recognize product instances
• Some fragments in the PFD relate to more than one instance of a
particular type of product.
 • We should try to identify each of those
instances.
4.4 Produce ideal activity network
• Activity network shows :
• The tasks that have to be carried out.
• Their order of execution for the
creation of a product.
• Activity networks don’t take account
of resource constraints.
4.5 Modify ideal to take into account need for
stages and checkpoints
5 Estimate effort for each activity
5.1 Carry out bottom-up estimates
• Some overall estimates of effort, cost and duration are already done in Step 3.6).
• Need to estimate staff effort, time for each activity, and other resources
5.2 Revise plan to create controllable activities
• Long activity: Break it down.
• Short activity: Combine multiple small activities into one.
• Ideal activity: Make the activity about the length of the reporting period
6 Identify activity risks
6.1 Identify and quantify activity-based risks
• Any plan is based on an assumption if the assumption is not correct this creates a risk to the plan.
For each risk identify: Importance, Likelihood and Damage.
6.2 Plan risk reduction and contingency measures where appropriate
For the identified risks:
• If (they didn’t happen) yet then try to:
• Avoid risks.
• Reduce some of them.
• If a risk materializes (happens) then
• Use a contingency plan.
6.3 Adjust plans and estimates to take account of risks
7 Allocate resources
7.1 Identify and allocate resources
• Type of staff needed for each activity is recorded.
• Staff availabilities are identified.
• Staff are provisionally allocated to task.
7.2 Revise plans and estimates to take account of resource constraints
• staffing constraints.
The product of Steps 7.1 and 7.2 would be a Gantt chart.
Gantt charts: unlike the activity network they give a clear picture of when activities will take place and highlights
which ones will be executed at the same time.
8 Review/publicize plan
8.1 Review quality aspects of project plan
• Each activity should have ‘exit requirements’ or sign off requirements
• Each activity should have quality criteria.
• Quality criteria: are quality checks that have to be passed before the product can be ’signed off’ as completed
8.2 Document plans and obtain agreement
• Plans should be properly documented.
• All parties understand and agree to the commitments in the plan
9/10 Execute plan/lower levels of planning
This may require the reiteration of the planning process at a lower level
• Plans will need to be more detailed for each activity as it becomes due.
• Detailed planning of later stages needs to be delayed because more information will be available nearer their start.
• But it is necessary to make provisional plans for more distant tasks.
 WATER PROTO ITERATIVE EVOLUT SPIRAL RAD
FALL TYPE EN IONARY
HANCEMENT

REQUIREMENT Based On Characteristics Of Requirements

Are requirements easily understandable and Y N N N N Y
defined?
Do we change requirements quite often? N Y N N Y N
Can we define requirements early in the cycle? Y N Y Y N Y
Requirements are indicating a complex system N Y Y Y Y N
to be built

DEVELOPMENT TEAM Based On Status Of Development Team

Less experience on similar projects? N Y N N Y N
Less domain knowledge (new to the Y N Y Y Y N
technology)
Less experience on tools to be used Y N N N Y N
Availability of training if required N N Y Y N Y

INVOLVEMENT OF USERS Based On User’s Participation

User involvement in all phases N Y N N N Y
Limited user participation Y N Y Y Y N
User have no previous experience of N Y Y Y Y N
participation in similar projects
Users are experts of problem domain N Y Y Y N Y

PROJECT TYPE AND RISK Based On Type Of Project With Associated Risk
Project is the enhancement of the existing N N Y Y N Y
system
Funding is stable for the project Y Y N N N Y
High reliability requirements N N Y Y Y N
Tight project schedule N Y Y Y Y Y
Use of reusable components N Y N N Y Y
Some problems with estimating
• Subjective nature of much of estimating: -People tend to underestimate the difficulty of small tasks and over-estimate that of
large ones
• Political pressures: -Different groups within an organization have different objectives
• Changing technologies: -The difficult to use the experience of previous projects on new ones.
• Lack of homogeneity of project experience: -Even where technologies have not changed, knowledge about typical task
durations may not be easily transferred from one project to another because of other differences between projects.
Parkinson’s Law: ‘Work expands to fill the time available’ . An over-estimate is likely to cause project to take longer than it
would otherwise
Brooks’ Law : ‘putting more people on a late job makes it later’.
Software Effort Estimation Techniques
● Algorithmic models: use ‘effort drivers’ representing characteristics of the target system and the implementation
environment to predict effort.
● Expert judgement: based on the advice of knowledgeable staff.
● Analogy: where a similar, completed, project is identified and its actual effort is used as the basis of the estimate.
● Parkinson: where the staff effort available to do a project becomes the ‘estimate’.
● Price to win: where the ‘estimate’ is a figure that seems sufficiently low to win a contract.
● Top-down: where an overall estimate for the whole project is broken down into the effort required for component tasks.
● Bottom-up: where component tasks are identified and sized and these individual estimates are aggregated.
FUNCTION POINT
5 3
UFP =  Z ij wij
i =1 J =1
FP = UFP * CAF
Where CAF is complexity adjustment factor and is equal to [0.65 + 0.01 x ΣFi]. The Fi (i=1 to 14)
COCOMO

E = ab ( KLOC) bb
D = cb ( E ) db

E KLOC
( SS ) = Persons ( P) = KLOC / PM
D E
Intermediate COCOMO equations

E = ai ( KLOC) * EAF bi D = ci ( E ) di

FUNCTION POINT THEORY

The five functional units are divided in
two categories:
(i) Data function types
▪ Internal Logical Files (ILF): A
user identifiable group of logical
related data or control
information maintained within
the system.
▪ External Interface files (EIF): A
user identifiable group of
logically related data or control information referenced by the system, but maintained within another system.
This means that EIF counted for one system, may be an ILF in another system.
(ii) Transactional function types
▪ External Input (EI): An EI processes data or control information that comes from outside the system. The EI is
an elementary process, which is the smallest unit of activity that is meaningful to the end user in the
business.
▪ External Output (EO): An EO is an elementary process that generate data or control information to be sent
outside the system.
▪ External Inquiry (EQ): An EQ is an elementary process that is made up to an input-output combination that
results in data retrieval.
Special features
➢ Function point approach is independent of the language, tools, or methodologies used for implementation;
i.e. they do not take into consideration programming languages, data base management systems, processing
hardware or any other data base technology.
➢ Function points can be estimated from requirement specification or design specification, thus making it
possible to estimate development efforts in early phases of development.
Step Wise: An approach to planning
software projects

0 Select project
1 Identify project scope and objectives
1.3 Identify objectives and measures of
effectiveness in meeting them
• Correct definition of objectives.
• Identify measures of effectiveness
for your objectives.
1.4 Establish a project authority
A single overall project authority
needs to be established so that there
is unity of purpose among all those
concerned.
1.3 Identify stakeholders
1.4 Modify objectives in the light of
stakeholder analysis
• Based on the stakeholders
requirements, it might be
necessary to modify the project
objectives.
• E.g. Adding new features to the system.
• This has to be done in a controlled manner.
1.5 Establish methods of communication with all parties
• Communication between stakeholders is important in all kinds of projects
• It is more important to arrange for in a dispersed project.
• Communication plan
2 Identify project infrastructure
2.1 Establish relationship between project and strategic planning
• Technical framework within which the proposed new systems are to fit
• Hardware and software standards should be followed.
• The software or components to be created should be compatible with those created by previous projects and
with the existing HW and SW platforms.
2.2 Identify installation standards and procedures
• Identify standards and procedures related to the software project E.g. specifying quality checks needed at
each point of the project Life cycle
• The project manager should be aware of the Project planning and control standards.
• E.g How are hours spent by team members on tasks recorded on timesheets.
2.3 Identify project team organization
Example: A high level manager could decide that: software developers and business analysts could be in
different group
3 Analyse project characteristics
3.1 Distinguish the project as either objective- or product-driven
3.2 Analyse other project characteristics
3.3 Identify high-level project risks
3.4 Take into account user requirements concerning implementation
3.5 Select general life-cycle approach
3.6 Review overall resource estimates
4 Identify project products and activities
4.1 Identify and describe project products (including quality criteria)
• Identify all the products related to the project
Products can be:
• Deliverables.
 • Technical products (e.g. training material, operating instructions).
• Products for management and quality (e.g. planning documents).
Products will perform a hierarchy:
• Main products will have a set of components which in turn will have sub-components and so on.
• These relationships can be documented in a PBS product breakdown structure.

• Products (The result of an activity) can be:

• Created from scratch.
• Modified version of something.
• Document.
• Person.
• Not an activity.
Activity
• Training
• Testing
• Designing
• Documenting
Product Breakdown Structure.
• The tangible products are those at the bottom of the PBS that are not further subdivided.
• The boxes that are higher up are names of group of items.
• The products at the bottom of the PBS should be documented by Product Descriptions which contain.
• The name
• The purpose
• The derivation of the product. (What are the source products from which this product is derived?)
• The composition
• The form
• The standards
• Quality criteria of the product
4.2 Document generic product flows
• To document the relative order of the products.
• Some products will need other products to exist first before they can be
created.
• E.g.The program code to be written need the program design, the
program design needs the program specification.

• This can be portrayed in a PFD Product Flow Diagram.

• Flow is from top to bottom and and from left to right.
4.3 Recognize product instances
• Some fragments in the PFD relate to more than one instance of a
particular type of product.
 • We should try to identify each of those
instances.
4.4 Produce ideal activity network
• Activity network shows :
• The tasks that have to be carried out.
• Their order of execution for the
creation of a product.
• Activity networks don’t take account
of resource constraints.
4.5 Modify ideal to take into account need for
stages and checkpoints
5 Estimate effort for each activity
5.1 Carry out bottom-up estimates
• Some overall estimates of effort, cost and duration are already done in Step 3.6).
• Need to estimate staff effort, time for each activity, and other resources
5.2 Revise plan to create controllable activities
• Long activity: Break it down.
• Short activity: Combine multiple small activities into one.
• Ideal activity: Make the activity about the length of the reporting period
6 Identify activity risks
6.1 Identify and quantify activity-based risks
• Any plan is based on an assumption if the assumption is not correct this creates a risk to the plan.
For each risk identify: Importance, Likelihood and Damage.
6.2 Plan risk reduction and contingency measures where appropriate
For the identified risks:
• If (they didn’t happen) yet then try to:
• Avoid risks.
• Reduce some of them.
• If a risk materializes (happens) then
• Use a contingency plan.
6.3 Adjust plans and estimates to take account of risks
7 Allocate resources
7.1 Identify and allocate resources
• Type of staff needed for each activity is recorded.
• Staff availabilities are identified.
• Staff are provisionally allocated to task.
7.2 Revise plans and estimates to take account of resource constraints
• staffing constraints.
The product of Steps 7.1 and 7.2 would be a Gantt chart.
Gantt charts: unlike the activity network they give a clear picture of when activities will take place and highlights
which ones will be executed at the same time.
8 Review/publicize plan
8.1 Review quality aspects of project plan
• Each activity should have ‘exit requirements’ or sign off requirements
• Each activity should have quality criteria.
• Quality criteria: are quality checks that have to be passed before the product can be ’signed off’ as completed
8.2 Document plans and obtain agreement
• Plans should be properly documented.
• All parties understand and agree to the commitments in the plan
9/10 Execute plan/lower levels of planning
This may require the reiteration of the planning process at a lower level
• Plans will need to be more detailed for each activity as it becomes due.
• Detailed planning of later stages needs to be delayed because more information will be available nearer their start.
• But it is necessary to make provisional plans for more distant tasks.
 WATER PROTO ITERATIVE EVOLUT SPIRAL RAD
FALL TYPE EN IONARY
HANCEMENT

REQUIREMENT Based On Characteristics Of Requirements

Are requirements easily understandable and Y N N N N Y
defined?
Do we change requirements quite often? N Y N N Y N
Can we define requirements early in the cycle? Y N Y Y N Y
Requirements are indicating a complex system N Y Y Y Y N
to be built

DEVELOPMENT TEAM Based On Status Of Development Team

Less experience on similar projects? N Y N N Y N
Less domain knowledge (new to the Y N Y Y Y N
technology)
Less experience on tools to be used Y N N N Y N
Availability of training if required N N Y Y N Y

INVOLVEMENT OF USERS Based On User’s Participation

User involvement in all phases N Y N N N Y
Limited user participation Y N Y Y Y N
User have no previous experience of N Y Y Y Y N
participation in similar projects
Users are experts of problem domain N Y Y Y N Y

PROJECT TYPE AND RISK Based On Type Of Project With Associated Risk
Project is the enhancement of the existing N N Y Y N Y
system
Funding is stable for the project Y Y N N N Y
High reliability requirements N N Y Y Y N
Tight project schedule N Y Y Y Y Y
Use of reusable components N Y N N Y Y
Some problems with estimating
• Subjective nature of much of estimating: -People tend to underestimate the difficulty of small tasks and over-estimate that of
large ones
• Political pressures: -Different groups within an organization have different objectives
• Changing technologies: -The difficult to use the experience of previous projects on new ones.
• Lack of homogeneity of project experience: -Even where technologies have not changed, knowledge about typical task
durations may not be easily transferred from one project to another because of other differences between projects.
Parkinson’s Law: ‘Work expands to fill the time available’ . An over-estimate is likely to cause project to take longer than it
would otherwise
Brooks’ Law : ‘putting more people on a late job makes it later’.
Software Effort Estimation Techniques
● Algorithmic models: use ‘effort drivers’ representing characteristics of the target system and the implementation
environment to predict effort.
● Expert judgement: based on the advice of knowledgeable staff.
● Analogy: where a similar, completed, project is identified and its actual effort is used as the basis of the estimate.
● Parkinson: where the staff effort available to do a project becomes the ‘estimate’.
● Price to win: where the ‘estimate’ is a figure that seems sufficiently low to win a contract.
● Top-down: where an overall estimate for the whole project is broken down into the effort required for component tasks.
● Bottom-up: where component tasks are identified and sized and these individual estimates are aggregated.
 Project Stakeholder Management
• The purpose of project stakeholder management is to:
• Identify all people or organizations affected by a
project
• To analyze stakeholder expectations
• To effectively engage stakeholders
• Projects often cause changes in organizations, and some people may lose their jobs when a project is completed.
• Project managers might be viewed as enemies if the project resulted in job losses for some stakeholders
Project Stakeholder Management Processes
 Identifying stakeholders: Identifying everyone involved in the project or affected by it, and determining the
best ways to manage relationships with them.
 Planning stakeholder management: Determining strategies to effectively engage stakeholders
 Managing stakeholder engagement: Communicating and working with project stakeholders to satisfy their
needs and expectations, resolving issues, and fostering engagement in project decisions and activities
 Controlling stakeholder engagement: Monitoring stakeholder relationships and adjusting plans and strategies
for engaging stakeholders as needed
Stakeholder Register
A stakeholder register includes basic information on stakeholders:
◦ Identification information: The stakeholders’ names, positions, locations, roles in the project, and contact
information
◦ Assessment information: The stakeholders’ major requirements and expectations, potential influences, and phases
of the project in which stakeholders have the most interest
◦ Stakeholder classification: Is the stakeholder internal or external to the organization? Is the stakeholder a
supporter of the project or resistant to it?
Issue Logs
Understanding the stakeholders’ expectations can help in managing issues
Issues should be documented in an issue log, a tool used to document, monitor, and track issues that need resolution
Unresolved issues can be a major source of conflict and result in stakeholder expectations not being met
Project Communications Management Processes
• Planning communications management: Determining the information and communications needs of the
stakeholders
• Managing communications: Creating, distributing, storing, retrieving, and disposing of project communications
based on the communications management plan
• Controlling communications: Monitoring and controlling project communications to ensure that stakeholder
communication needs are met
• Reporting Performance: Performance reporting keeps stakeholders informed about how resources are being used
to achieve project objectives
◦ Status reports describe where the project stands at a specific point in time
◦ Progress reports describe what the project team has accomplished during a certain period of time
◦ Forecasts predict future project status and progress based on past information and trends
 Conflict Resolution: - Conflicts arise due to differing opinions, conflicting interests, and diverse personalities within a
project team. Ignoring or mishandling conflicts can lead to decreased productivity, strained relationships, and
ultimately project failure.
Reasons why conflict resolution is essential:
1. Improved Team Collaboration: By addressing conflicts promptly and fairly, project managers create an
environment where team members can openly express their perspectives and work collaboratively towards shared
goals.
2. Enhanced Decision-Making: Constructive conflict resolution encourages the exploration of diverse viewpoints and
alternative solutions. This enables project teams to make informed decisions, considering a broader range of
possibilities and increasing the likelihood of optimal outcomes.
3. Increased Employee Satisfaction and Retention: Effectively resolving conflicts demonstrates that the concerns and
opinions of team members are valued. This fosters a sense of respect, satisfaction, and engagement, leading to
higher employee retention rates and a positive project culture.
4. Minimized Project Risks: Conflicts left unaddressed can escalate and disrupt project progress. By promptly
resolving conflicts, project managers mitigate potential risks, prevent delays, and maintain focus on project
objectives.
The Art of Negotiation: -Negotiation skills are vital for project managers when interacting with stakeholders, clients,
vendors, and team members.
Here's why strong negotiation skills are crucial:
1. Resource Acquisition: Project managers often need to secure resources, whether it's budget, staff, or equipment.
Effective negotiation skills enable you to advocate for project needs, present compelling arguments, and secure the
necessary resources to support project success.
2. Stakeholder Management: Negotiating with stakeholders helps manage their expectations, align project goals, and
address concerns. By understanding stakeholders' interests and effectively communicating project constraints,
project managers can foster positive relationships and gain stakeholder buy-in.
3. Conflict Resolution: Negotiation skills play a significant role in resolving conflicts among team members or
stakeholders. The ability to facilitate productive discussions, find common ground, and reach mutually beneficial
agreements can defuse tensions and promote harmonious relationships.
4. Scope and Change Management: Negotiation skills are invaluable when managing project scope and handling
change requests. By effectively negotiating changes, project managers can balance stakeholder expectations,
evaluate impacts, and maintain project feasibility.
Strategies for Conflict Resolution and Negotiation
• Active Listening: Actively listen to understand the perspectives, concerns, and underlying interests of all parties
involved. Seek to empathize and create an open, non-judgmental environment that encourages honest
communication.
• Collaboration and Compromise: Encourage collaborative problem-solving by involving all relevant parties in finding
mutually agreeable solutions. Foster a spirit of compromise and encourage the exploration of win-win scenarios
where possible.
• Mediation and Facilitation: As a project manager, act as a mediator or facilitator when conflicts arise.
Remain neutral, guide discussions, and ensure that all voices are heard and respected.
• Effective Communication: Clearly articulate your expectations, project goals, and rationale behind decisions.
Foster transparent and timely communication to address concerns and avoid misunderstandings.
• Preparation and Research: Before negotiations, gather relevant information, understand stakeholders' positions, and
anticipate potential points of contention.
Develop a negotiation strategy, including alternative options and potential compromises.
Customer Relationship Management: -Customer relationship management (CRM) is an approach to manage a
company's interaction with current and potential customers. It uses data analysis about customers' history with a
company to improve business relationships with customers, specifically focusing on customer retention and
ultimately driving sales growth.
Elements of Customer Relationship Management
1 Customer Service: - The customer service function in your company represents the front office functions that
interact with your customers.
2. Sales Force Automation: - A company’s sales department is constantly looking for sales opportunities with existing
and new customers. The sales force automation functionality of CRM software allows the sales teams to record each
contact with customers, the details of the contact and if follow up is required.
3. Campaign Management: -The sales team approach prospective customers in the hope of winning new business.
The approach taken by the sales team is often focused in a campaign, where a group of specific customers are
targeted based on a set of criteria.
Benefits of Customer Relationship Management
1. Better client relationships. The more you know, and remember, about clients (or customers) the more your clients
know you care about them. This enables you to forge a much stronger connection and a deeper relationship with
your clients.
2. Improved ability to cross-sell. The more you know about your clients' needs and wants the better able you are to
provide the solution to their next problem.
3. Improved efficiency in serving clients. The more you know about clients, the better able you are to serve them. If
everyone is using the CRM to record their customer interactions, EVERY client interaction, then others' are able to
serve the client with the knowledge of what has been previously discussed with the client.
4. Greater staff satisfaction The more knowledge your employees have the more empowered and engaged they are.
Having an accurate and up-to-date CRM that everyone uses and has access to helps employees solve client problems.
Doing so makes employees and clients happy.
5.Increased revenue and profitability Once everyone learns, and uses, the CRM productivity increases. You have the
ability to provide additional products and services to clients and client satisfaction increases.
6.Cost savings While the start-up of a CRM software is expensive and time-consuming, over time the benefits far
outweigh the costs. Members of the sales team are able to better schedule meetings with prospects in the same
geographic area.
Essential features of CRM
1. Customer’s Needs- An organization can never assume what actually a customer needs. Hence it is extremely
important to interview a customer about all the likes and dislikes so that the actual needs can be ascertained and
prioritized.
2. Customers Response- Customer response is the reaction by the organization to the queries and activities of the
customer. Dealing with these queries intelligently is very important as small misunderstandings could convey unalike
perceptions.
3. Customer Satisfaction- Customer satisfaction is the measure of how the needs and responses are collaborated and
delivered to excel customer expectation.
4. Customer Loyalty- Customer loyalty is the tendency of the customer to remain in business with a particular
supplier and buy the products regularly.
5. Customer Retention- Customer retention is a strategic process to keep or retain the existing customers and not
letting them to diverge or defect to other suppliers or organization for business.
6. Customer Complaints- Always there exists a challenge for suppliers to deal with complaints raised by customers.
7. Customer Service- In an organization Customer Service is the process of delivering information and services
regarding all the products and brands.
COCOMO BASIC MODEL
𝐸𝑓𝑓𝑜𝑟𝑡 = 𝑎[𝐾𝐿𝑂𝐶 ]𝑏 𝐷𝑒𝑣𝑒𝑙𝑜𝑝𝑚𝑒𝑛𝑡 𝑇𝑖𝑚𝑒 = 𝑐 [𝐸𝑓𝑓𝑜𝑟𝑡]𝑑
𝐸𝑓𝑓𝑜𝑟𝑡 𝐾𝐿𝑂𝐶
𝐴𝑣𝑒𝑟𝑎𝑔𝑒 𝑆𝑡𝑎𝑓𝑓 𝑆𝑖𝑧𝑒 = 𝐷𝑒𝑣𝑒𝑙𝑜𝑝𝑚𝑒𝑛𝑡 𝑇𝑖𝑚𝑒 𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑖𝑣𝑖𝑡𝑦 = 𝐸𝑓𝑓𝑜𝑟𝑡

COCOMO INTERMEDIATE MODEL

[
𝐸𝑓𝑓𝑜𝑟𝑡 = 𝑎 𝐾𝐿𝑂𝐶 ]𝑏 ∗ 𝐸𝐴𝐹
COCOMO DETAILED DEVELOPMENT MODEL
𝐴𝐹 = 0.4 ∗ 𝐷𝑒𝑠𝑖𝑔𝑛 𝐷𝑜𝑐𝑢𝑚𝑒𝑛𝑡𝑎𝑡𝑖𝑜𝑛 + 0.3 ∗ 𝐶𝑜𝑑𝑒
+ 0.3 𝐼𝑛𝑡𝑒𝑟𝑔𝑟𝑎𝑡𝑖𝑜𝑛 𝑎𝑛𝑑 𝑡𝑒𝑠𝑡𝑖𝑛𝑔

𝑆𝑖𝑧𝑒 𝐸𝑞𝑢𝑎𝑣𝑎𝑙𝑒𝑛𝑡 ∗ 𝐴𝐹
𝑆𝑖𝑧𝑒 𝐸𝑞𝑢𝑖𝑣𝑎𝑙𝑒𝑛𝑡 =
100
𝐸𝑓𝑓𝑜𝑟𝑡 𝑑𝑒𝑡𝑎𝑖𝑙𝑒𝑑 = µ𝑝 ∗ 𝐸𝑓𝑓𝑜𝑟𝑡 𝐷𝑒𝑣𝑒𝑙𝑜𝑝𝑚𝑒𝑛𝑡 𝑇𝑖𝑚𝑒 = 𝑇𝑝 ∗ 𝐸𝑓𝑓𝑜𝑟𝑡
FUNCTIONAL POINT
5 3
UFP =  Z ij wij
i =1 J =1 𝐶𝐴𝐹 = 0.65 + 0.01 ∗ ∑⬚
⬚ Fi
𝐹𝑢𝑛𝑡𝑖𝑜𝑛𝑎𝑙 𝑃𝑜𝑖𝑛𝑡 = 𝑈𝐹𝑃 ∗ 𝐶𝐴𝐹

PERT
( 𝑡𝑎+4∗𝑡𝑚+𝑡𝑏) 𝑡𝑏− 𝑡𝑎 2
𝑀𝑒𝑎𝑛 = 𝑉𝑎𝑟𝑖𝑎𝑛𝑐𝑒 = [ ]
6 6
( 𝑡𝑎 − 𝑡𝑏)
𝑆𝑡𝑎𝑛𝑑𝑎𝑟𝑑 𝐷𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛 =
6
𝑆𝑐ℎ𝑒𝑑𝑢𝑙𝑒 𝑇𝑖𝑚𝑒 − 𝐸𝑥𝑝𝑒𝑐𝑡𝑒𝑑 𝑇𝑖𝑚𝑒
𝑍=
𝑆𝑡𝑎𝑛𝑑𝑎𝑟𝑑 𝑑𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛 𝑜𝑓 𝐶𝑟𝑖𝑡𝑖𝑐𝑎𝑙 𝑝𝑎𝑡ℎ

Cost Variance (CV) = Earned value (EV) – Actual Cost (AC)

Schedule Variance (SV) = Earned value (EV) – Planned Value (PV)
Cost Performance Index (CPI) = Earned value (EV) / Actual Cost (AC)
Schedule Performance Index (SPI) = Earned value (EV) / Planned Value (PV)