SPM Unit I & II

Software Project Management
Copyright © PROF. GUFRAN QURESHI

9029120671 / 7021047199
Mumbai University Course Code: USIT501

9029120671 / 7021047199
Unit I
Ch 1: Introduction to Software Project Management: Introduction, Why is Software Project Management
Important? What is a Project? Software Projects versus Other Types of Project, Contract Management and
Technical Project Management, Activities Covered by Software Project Management, Plans, Methods and
Methodologies, Some Ways of Categorizing Software Projects, Project Charter, Stakeholders, Setting
Objectives, The Business Case, Project Success and Failure, What is Management? Management Control,
Project Management Life Cycle, Traditional versus Modern Project Management Practices.
Ch 2: Project Evaluation and Programme Management: Introduction, Business Case, Project Portfolio
Management, Evaluation of Individual Projects, Cost–benefit Evaluation Techniques, Risk Evaluation,
Programme Management, Managing the Allocation of Resources within Programmes, Strategic Programme
Management, Creating a Programme, Aids to Programme Management, Some Reservations about
Programme Management, Benefits Management.
Ch 3: An Overview of Project Planning : Introduction to Step Wise Project Planning, Step 0: Select
Project, Step 1: Identify Project Scope and Objectives, Step 2: Identify Project Infrastructure, Step 3: Analyse
Project Characteristics, Step 4: Identify Project Products and Activities, Step 5: Estimate Effort for Each
Activity, Step 6: Identify Activity Risks, Step 7: Allocate Resources, Step 8: Review/Publicize Plan, Steps 9
and 10: Execute Plan/Lower Levels of Planning.
Ch-1 Introduction to Software Project
Management
Definition:- Software project management is an art and discipline of planning and supervising software projects. It is a
sub-discipline of software project management in which software projects planned, implemented, monitored and
controlled.
• It is a procedure of managing, allocating and timing resources to develop computer software that fulfills requirements.
• In software Project Management, the client and the developers need to know the length, period and cost of the project.
Prerequisite:
There are three needs for software project management. These are:
• Time
• Cost
• Quality
It is an essential part of the software organization to deliver a quality product,

keeping the cost within the client’s budget and deliver the project as per schedule.
There are various factors, both external and internal, which may impact this triple
factor. Any of three-factor can severely affect the other two.

Need / Importance of SPM
1. To control scope of project & manage change: Although the project deliverables are defined at the outset of the project,
small changes in project deliverables are common.
2. To deliver projects on time & within budget: Once return once investments (ROI) is established it is for the project
manager to ensure that the project schedule & budget are adhered to else the project will fail to deliver the expected results.
3. To ensure the focus of the project team: It is the responsibility of the project manager to ensure that the project team
focuses on the right tasks by using a clear & concise project charter & that there are no interferences.
4. To collect user requirement from disparate sources: The project manager at the initiation phase should collect user
requirement, project constraints and conduct a feasibility study to build a strong business case justification.
5. To define the critical path to optimally complete the project: By using the critical path method technique the project
manger is able to identify the critical path & thus ensure the successful completion of the project.
6. To provide a process for estimating project resources, time and costs: Solid project management tools & techniques
enable the project manager to correctly estimate the project resources requirement, completion time & likely expenditure.
7. To communicate project progress, risks and changes: The stakeholders of the project need to be kept updated on the
project progress, hurdles encountered & changes incorporated.
8. To explore project assumptions: A good project manager has to delve deeper into user requirements, project constraints &
management expectations to understand the hidden project requirements.
9. To prepare for unexpected project issues: Howsoever, one may be prepared there are bound to be a few issues which may
suddenly surface. Hence, the project manager should always be prepared with an alternate plan.
10. To document the knowledge gained from the project: The last phase of the project involves the documentation of all that
has been learnt at each phase in the project which will provide guidance to other project manager in other projects.
What is a Project?
Definition: A project can be defined as a temporary endeavour undertaken to accomplish a unique product, services or
results. Project can be sequences of task which is planned from beginning to end bounded by time, resources, and required
result.
 A project is a group of tasks that need to complete to reach a clear result. A project also defines as a set of inputs and outputs which are
required to achieve a goal. Projects can vary from simple to difficult and can be operated by one person or a hundred.
 Projects usually described and approved by a project manager or team executive. They go beyond their expectations and objects , and it's up
to the team to handle logistics and complete the project on time. For good project development, some teams split the project into specific
tasks so they can manage responsibility and utilize team strengths.
Attributes:
a. Time frame: Because a project is a temporary endeavour, it must have a definite beginning and end. Many projects begin on a specific date
and the date of completion is estimated.
b. Purpose: An IT Project can produce any number of results such as a system, a software package, or a recommendation based on a study.
Therefore a project’s goal must be to produce something tangible and of value to the organization.
c. Ownership: The project must provide something of value to an individual or group who will own the project product after it is completed.
Determining who owns this project is not always easy.
d. Resources: IT project require time, money, people, and technology. Resources provide the means for achieving a project’s goal and also act
as a constraint.
e. Roles: IT Projects require different individuals with different skills set, they are listed below.
1. Project Manager: She/he is responsible for ensuring that all of the project management and technical development processes are in place
and being carried out properly.
2. Project sponsor: The project sponsor may be the client, customer, or organizational resources manager who will act as champion for the
project.
3. Subject matter experts: The subject matter expert may be user or client who has specific knowledge, expertise, or insight in a specific
functional area.
4. Technical Expert: Technical expert is needed to provide a technical solution to organization problems.
Software projects versus other types of project
Many of the techniques of general project management are applicable to software project management, but Fred
Brooks pointed out that the products of software projects have certain characteristics that make them different.
One way of perceiving software project management is as the process of making visible that which is invisible.
Invisibility: When a physical artifact such as a bridge or road is being constructed the progress being made can
actually be seen. With software, progress is not immediately visible.
Complexity: Per dollar, pound or euro spent, software products contain more complexity than other engineered
artifacts.
Flexibility: The ease with which software can be changed is usually seen as one of its strengths. However this
means that where the software system interfaces with a physical or organizational system, it is expected that, where
necessary, the software will change to accommodate the other components rather than vice versa. This means the
software systems are likely to be subject to a high degree of change.
Conformity: Software project are based on logical work, while other are based on physical work. Software
developers have to conform to the requirements of human clients.

Project Management versus Contract Management
Project Management:
 Project management is important because it brings leadership & direction to projects.
 Good project management ensures that the goals of project closely align with the strategic goals of the business.
 It ensures what is being delivered, is right, and will deliver real value against the business opportunity.
 It ensures proper expectations are set around what can be delivered, by when, and for how much.
 It ensures the quality of whatever is being delivered, consistently hits the mark.
Contract Management:
 The client organization will appoint a project manager to supervise the contract.
 Project manager will be able to delegate many technical oriented decisions to the contractors.
 The project manager will not be concerned about estimating the effort needed to write individual software components.
 The overall project is fulfilled within budget and on time.
 Supplier side-project managers are concerned with more technical management issues.

Activities covered by Software Project Management
Definition:- Software project management is an art and discipline of planning and supervising software projects. It
is a sub-discipline of software project management in which software projects planned, implemented, monitored and
controlled.
A software project is not only concerned with the actual writing of software.
Three successive processes
Feasibility Study, Planning, Project Execution
Feasibility Study
Prospective project is worth starting
Information is gathered about the requirements of the proposed application.
Requirements elicitation can at least initially be complex and difficult.
Planning
A large project would not do all detailed planning right at the beginning.
Formulate an outline plan for the whole project a detailed one for the first stage and more detailed planning of the later
stages.
Feasibility study
How
do we
Is it do it?
worth Plan
doing? Do
it!
Project execution
Project execution
The execution of a project often contains design and implementation sub phases.
Design is thinking and making decisions about the precise form of the products that the project is to create.
Planning and design can be confused because at the most detailed level, planning decisions are influenced by design
decisions.

Categories of Software Projects
I] Custom Software Projects:
 Custom software (also known as bespoke software or tailor-made software) is software that is specially developed for some
specific organization or other user.
 As such, it can be contrasted with the use of software packages developed for the mass market, such as commercial off-the-
shelf (COTS) software, or existing free software.
 Custom software development is the process of designing, creating, deploying and maintaining software for a specific set of
users, functions or organizations.
 Custom software is built to fit company’s specifications and business needs and is different from traditional off-the-shelf
software which is available to a larger audience.
 The custom-made software which is available to companies is more
secured. As the custom software is developed only to suit particular
enterprises, it will be used only by those individuals in the company.
 The custom-made software is more sizeable than ready-made application.
The custom-made application is developed on a long-term basis. They can
conveniently scale this software to meet the business requirements.
II] Distributed Computing Projects:

 Distributed computing is a model in which components of a
software system are shared among multiple computers to improve
efficiency and performance.
 According to the narrowest of definitions, distributed computing is limited
to programs with components shared among computers within a limited
geographic area.
 Distributed computing is a computing concept that, in its most general
sense, refers to multiple computer systems working on a single problem.
 In distributed computing, a single problem is divided into many parts, and
each part is solved by different computers.
 Distributed systems are inherently scalable as they work across different
machines and scale horizontally. Distributed systems are also inherently
more fault tolerant than single machines.
III] Free Software Projects
 “Free software” means software that respects users' freedom and
community. Roughly, it means that the users have the freedom to run,
copy, distribute, study, change and improve the software. Thus, “free
software” is a matter of liberty, not price.
 Use: Free Software can be used for any purpose and is free of restrictions
such as license expiry or geographic limitations.
 Study: Free Software and its code can be studied by anyone, without
non‐disclosure agreements or similar restrictions.
 Share: Free Software can be shared and copied at virtually no cost.
 Improve: Free Software can be modified by anyone, and these improvements can be shared publicly.
IV] Software hosted on CodePlex
 CodePlex was Microsoft's free, open source project hosting site, which ran from 2006 through 2017.
 CodePlex.com has been archived into this read-only, lightweight website.
 In 2012, CodePlex hosted more than 28,000 projects. Microsoft had been perceived as an opponent of open source early
in the new century, but that has changed with the company's growing embrace of the concept. Copyright © PROF. GUFRAN QURESHI
Project Charter (Contract)
 A project charter is the statement of scope, objectives and people who are participating in a project. It begins the process of
defining the roles and responsibilities of those participants and outlines the objectives and goals of the project. The charter
also identifies the main stakeholders and defines the authority of the project manager.
 A project charter names the project manager and defines the authority of the project manager. It gives the project manager th e
power to utilize organizational resources to accomplish the project objectives.
 The project charter is not only a tool that is used for planning projects but also a communication mechanism that acts as a
reference. A well-planned project with an effective communication plan will definitely bring in success for the project
undertaken at hand.
Benefits:
 Helps determine project value: help you determine if it’s worthwhile to
carry out or propose the project.
 Saves time down the road: the time you take at the beginning is time you
won’t need to spend trouble-shooting and negotiating if you’ve already
addressed these areas in the project charter.
 Gives you budget clarity: ensure that funding is available and will be
released on time. Settle your spending authority and budgets prior to starting
the project.
 Helps you give clear guidelines to your team: The milestones and criteria
for measurement give invaluable guidance to your team as you begin to brief
out the project.
 Inspires confidence: gives the team assurance that they’re working under an
effective and well-organized project manager. Copyright © PROF. GUFRAN QURESHI
Elements of Project Charter
Depending on company culture and on the person ahead of writing the company charter, the points that comprise it can
vary. Typically, however, it’s composed of the following sections:
 Project Overview – Consists of the project name, author of the charter, creation date, project manager, project charter
purpose, and charter version.
 Project Details – here you can add a detailed project description which includes the mission, the general scope of the
project, the key stakeholders, and clients.
 Project Scope – a range of companies prefer including the project scope within the Project Details section. However, if the
project is large enough, a completely separate section helps us better visualize the project scope. You would also include
points such as objectives, goals, deliverables, out of scope deliverables, benefits, assumptions, risks, and constraints.
 Project Team Organization – here you’d include a list of all team members that would take part in implementation. You can
also include their contact details and their role in the project.
 Project Resource Planning – this can include all resources starting from staff, non-human resources up to finances.
 Project Communication Plan – it is generally a good idea to set up a communication plan to consistently revise changes and
assure alignment of goals and objectives. The project rarely goes the way it’s intended; oftentimes, you’ll have to make
some changes to the project charter along the way. Meaning, you should establish a communication plan, bi-weekly
meetings, for example, to check on whether the project is going according to the charter or not.
 Project Timeline – it’s important to have an idea on what the timeline for your project is. Your management, or possibly the
client, will want to know whether the project is on schedule, and a timeline is a good way to estimate that.
 Signatories – the list of signatories to the project

Stakeholders
 A stakeholder is either an individual, group or organization who is impacted by the outcome of a project. They have an
interest in the success of the project, and can be within or outside the organization that is sponsoring the
project. Stakeholders can have a positive or negative influence on the project.
 It includes normally the members of a project team: project managers, project sponsors, executives, customers, or users. If
a project is small in size, the number of stakeholders can be small. However, if it is large and expanded to a large area, one
may have a huge number of stakeholders, including communities or the general public.
Types:
 Internal Stakeholders: As the name suggests, these are the people involved in a project from within. They include: Sponsor,
internal customer or client(internal need of organization), project team, program or portfolio manager, management.
 External Stakeholders: These stakeholders are not directly involved but are engaged from outside and are affected by the
project outcome. They include: External customer or client(contract from external party), end user, subcontractor, supplier,
government, local communities, media.
 One of the keys to a successful project is successfully managing the relationships
between everyone involved - the stakeholders. There are three processes involved:
1. Identify the Project Stakeholders: This involves identifying the people, groups,
or organizations that could impact or be impacted by a decision, activity, or
outcome of the project.
2. Analyze their potential involvement with the project: This is the process that
develops appropriate management strategies to effectively engage stakeholders
throughout the project.
3. Manage their engagement with the project: This is the process that
communicates and works with stakeholders to meet their needs and expectations,
address issues as they occur, and support stakeholder engagement.
Setting Objectives (for Projects)
 Objectives are the project “Road Map . . . “ Objectives define a set of supporting actions to ensure the broader goals are
accomplished. Objectives are your action plan or high level road map. They are specific steps or tasks that must be
completed to reach the goal.”
 Objectives are concrete statements describing what the project is trying to achieve. The objective should be written at a low er
level, so that it can be evaluated at the conclusion of a project to see whether it was achieved or not. Goal statements are
designed to be vague (uncertain). Objectives should not be vague. A well-worded objective will be Specific, Measurable,
Attainable/Achievable, Realistic and Time-bound (SMART).
 An example of an objective statement might be to “upgrade the helpdesk telephone system by
December 31 to achieve average client wait times of no more than two minutes”.
 Note that the objective is much more concrete and specific than the goal statement.
 The objective is measurable in terms of the average client wait times the new phone system is
trying to achieve.
 We must assume that the objective is achievable and realistic.
 The objective is time-bound, and should be completed by December 31.
 Objectives can often be set under three headings:
1. Performance and Quality: In more recent years the concept of total quality management has come to the fore, with the
responsibility for quality shared by all staff from top management downwards.
2. Budget: The project must be completed without exceeding the authorised expenditure. Financial sources are not always
inexhaustible and a project might be abandoned altogether if funds run out before completion.
3. Time to Completion: Actual progress has to match or beat planned progress. All significant stages of the project must take
place no later than their specified dates, to result in total completion on or before the planned finish date.
The Business Case
Definition: The business case is a process to critically examine the opportunities, alternatives, project stages and financial
investment in order to make a recommendation for the best course of action that will create business value.
Steps for Developing the Business Case:

Step 1: Confirm the opportunity
Describe the situation and the business opportunity that your proposal will impact. This will include the background to project,
the investment logic and the high-level business requirements.
Step 2: Analyse and develop shortlisted options
Identify the alternative approaches and select three or four options to analyse. Gather information about each alternative, analyse
the options and develop the shortlisted options.
Step 3: Evaluate the options
Evaluate how the alternatives will deliver on the business objectives, then select the preferred option, taking into account the
strategic and financial value created and the risks.
Step 4: Implementation strategy
Create the implementation plan for the preferred option, detailing how to achieve the business objectives, who will be
accountable for each milestone, and how to mitigate the project risks.
Step 5: Recommendation
Confirm the recommended option. Create the business case documents and present the business case recommendation to the
board and management team for approval to proceed.
Steps in Developing MOV Copyright © PROF. GUFRAN QURESHI
Definition: The first phase of a project begins with conceptualizing the project’s goal and overall measure of success called the
Measurable Organizational Value (MOV). The Measurable Organizational Value (MOV) is the goal of the project and is used to
define the value that your project will bring to your client. To provide real value to an organization, a project must align with
and support the organization’s vision, mission, and strategy.
Steps for Developing the MOV:
1. Identify the desired area of impact: A project can have an impact on an organization in many different ways. (Customer,
Strategic, Financial, Operational, Social)
2. Identify the desired value of the project: Once the desired area of impact is identified, the next step involves determining
the desired value the project can bring to the organization.
3. Develop an appropriate metric: Once there is agreement as to the value the project will bring to the organization, the next
step is to develop a metric, or set of metric, that:
a. Provides the project team with a performance target or directive
b. Sets expectations among all stakeholders
c. Affords a means for evaluating whether the project is a success later on.
4. Set a time frame for achieving the MOV: Once you have identified the area of impact, value to the organization, and an
appropriate metric, you need to set a time frame for achieving the MOV. Keep in mind that this time frame may not
coincide with the scheduled completion of the project work.
5. Verifying with stakeholders: Getting the metric value and time frame verified and approved from the stakeholders adds
value to claims made in the business case.
6. Summarize the MOV in a clear, concise statement or table: Once the impact and value to the organization are verified and
agreed upon by all the project stakeholders, the MOV should be summarized in a single statement or table. Summarizing
the MOV provides an important chance to get final agreement and verification, provides a simple and clear directive for the
project team, and sets explicit expectations for all project stakeholders.
Project Success and Failure
The Best Projects:
A project was considered to be in the “Best” category if it met all of the following criteria:
1. A total cost that was lower than the industry average for similar projects by 10 percent or more
2. An execution duration or overall cycle time that was industry average or faster
3. Safety performance that included no fatalities, and
4. No serious operational problems during startup or in the first 12 months of operation
5. The Best Projects were, on average, 18 percent lower in cost, 8 percent faster in cycle time (total length of the project) and
10 percent faster in execution.
The Worst Projects:

A project was considered to be in the “Worst” category if it met all of the following criteria:
1. A total cost that was higher than the industry average for similar projects by 20
percent or more, and
2. An execution or cycle time duration that was slower than industry average by 20
percent or more
3. The Worst Projects were, on average, 42 percent higher in cost, 49 percent slower in
cycle time, and 29 percent slower in execution.
Triple Constraints of Project Management

1. Cost: The financial constraints of a project, also known as the project budget
2. Scope: The tasks required to fulfill the project’s goals
3. Time: The schedule for the project to reach completion
Management & Management Control
Definition: Management is a process of planning, decision making, organizing, leading, motivation and controlling the human
resources, financial, physical, and information resources of an organization to reach its goals efficiently and effectively.
Functions:
1. Planning: It is the basic function of management. According to KOONTZ, “Planning is deciding in advance - what to do,
when to do & how to do. It bridges the gap from where we are & where we want to be”.
2. Organizing: It is the process of bringing together physical, financial and human resources and developing productive
relationship amongst them for achievement of organizational goals.
3. Staffing: It is the function of manning the organization structure and keeping it manned. Staffing has assumed greater
importance in the recent years due to advancement of technology, increase in size of business, complexity of human
behavior etc.
4. Directing: It is that part of managerial function which actuates the organizational methods to work efficiently for
achievement of organizational purposes.
5. Controlling: It implies measurement of accomplishment against the
standards and correction of deviation if any to ensure achievement of
organizational goals.
Management Control: Management control describes the means by which

the actions of individuals or groups within an organization are constrained to
perform certain actions while avoiding other actions in an effort to achieve
organizational goals. A management function aimed at achieving defined
goals within an established timetable, and usually understood to have three
components: (1) setting standards, (2) measuring actual performance, and
(3) taking corrective action.
Project Management Lifecycle
The project management life cycle is a series of activities that are necessary to fulfill project goals or objectives. These activities
may go by different names, depending on the methodology, but tend to be similar in nature.
Phases:
1. Project Goal: This is where a project starts. The purpose of this phase is to define the project in a larger sense. Here, the
project manager starts with a kick-off meeting with a client(s) to understand the goals and objectives and most importantly,
their expectations from it.
2. Project Plan: Once you’ve defined all the objectives, it’s time to develop a roadmap for everyone to follow. It involves
setting goals and describing job-responsibilities to the project members. Many project managers set S.M.A.R.T goals to
make the process achievable.
Specific: To set specific goals and have an answer for every what, who, where, which, when, and how.
Measurable: To define criteria that can be used to measure the success of a goal.
Attainable: To identify what it will take to achieve those goals.
Realistic: To set goals that are actually doable and achievable in the given time.
Time-bound: To create a timeframe to achieve every goal.
3. Project Plan Execution: This is the phase when the project starts taking it shape.
As a lot of things are happening while executing a project, maybe that’s why it’s
referred to as meat of the project. This phase is also called implementation phase.
4. Project Evaluation: Project evaluation is a systematic and objective assessment
of an ongoing or completed project. The aim is to determine the relevance and
level of achievement.
5. Project Closure: This phase represents the completed project. It is the last phase
of project management that is also called post-mortem or follow-up phase.
Development of Agile Copyright © PROF. GUFRAN QURESHI
Agile project management is the process by which projects can be managed and implemented in small chunks of work. Agile
projects deliver value in small deliveries of product, and they are called "Features". Projects during Agile Project Management
are managed in five stages, called the Agile Life Cycle. The stages are: Envision, Speculate, Explore, Adapt, and Close.
Agile Phases
In general, the way that the Agile project management process works can be
summarized in the phases below:
1. Envision – create the product vision and scope for the customers as well as
determine who will be involved in the project
2. Speculate – this is an extension of the “Envision” phase where teams gather the
initial broad requirements for a product/service and develop an iteration plan
based on the vision
3. Explore – work on the project deliverables with a focus on flow, aiming to get
feedback from the customer as fast as possible
4. Adapt – review delivered results and adapt as necessary to current conditions
5. Close – conclude the project, pass along key findings
Benefits:
1. Serialized Process: Iterative approach with task broken into small increments. (step by step)
2. Planning far in advance: Plan for what we know and we have left sufficient allowance in our plans for what we don’t
know. (any changes that will come in future)
3. Project Timeline: It allows the development team to get feedback from the customer throughout.
Limitations:
1. Lack of Visibility: Teams don’t realize they are behind schedule. (They have sufficient time left as they are going fast)
2. Static Requirements: Scope is never closed; Continual reassessment of requirement priorities by the business.
Principles of Agile
1. Satisfy the Customer: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome Change: Welcome changing requirements, even late in development. Agile processes harness change for the
customer's competitive advantage.
3. Deliver Frequently: Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Work Together: Business people and developers must work together daily throughout the project. It makes sense for the
customer to become part of the team.
5. Build Projects: Build projects around motivated individuals. Give them the environment and support they need, and trust
them to get the job done.
6. Face-To-Face Time: The most efficient and effective method of conveying information to and within a development team
is face-to-face conversation.
7. Measure of Progress: Working software is the primary measure of progress. When you make working software the
primary measure of progress you promote it to the primary focus of the project.
8. Sustainable Development: Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely.
9. Continuous Attention: Continuous attention to technical excellence and good design enhances agility. While an elegant
design is meaningful even more valuable is a solution that will span the test of time.
10. Keep It Simple: Nearly 30% of the functionality we build is seldom or never used. Agile is ruthless about cutting
functionality that does not lend value.
11. Organized Teams: The best architectures, requirements, and designs emerge from self-organizing teams. Self-organizing
teams that are cross functional as well.
12. Reflect for Effectiveness: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly. We've all been on projects that end with an AAR, After Action Review. Copyright © PROF. GUFRAN QURESHI
Agile SDLC Model Traditional SDLC Model
The model is very flexible and can easily adapt the Such models lack flexibility and it is
Model Principle
project to the customer’s needs and expectations. challenging to implement changes in a project
It is suitable for projects of all sizes – from small It can be used for all types of project. However,
Project Size to large-scale. All can benefit from the flexible it makes little allowance for human errors and
Agile SDLC model. changes in development later are challenging.
Successful work is measured by the delivered Success is evaluated by conformity to the

Success Measurement
working software. original plan.
The changes are welcomed and accepted at any It is challenging to accept changes later on in
Adaptability
stage of project development the development process.
Traditional SDLC models require intensive

Documentation Agile doesn’t require a lot of documentation.
documentation.
Has many iteration cycles – as many as needed for

Iteration Cycles The number of iterations is limited.
the product.
There is minimal planning required in the pre- Planning should be completed before the
Original Planning development phase, as any changes can be made development starts, as changes are difficult to
later on in the development process. make in later stages of development.
Ch-2 Project Evaluation and Programme Management
The Business Case:
Definition: The business case is a process to critically examine the opportunities, alternatives, project stages and financial
investment in order to make a recommendation for the best course of action that will create business value.
Feasibility studies can also act as a ‘business case’
Provides a justification for starting the project
Should show that the benefits of the project will exceed development, implementation and operational costs
Needs to take account of business risks
A business case captures the reasoning for initiating a project or task. It is often presented in a well-structured written
document, but may also come in the form of a short verbal agreement or presentation.
A business case is the justification for some activity (e.g. a project) undertaken by your organisation. It weighs up the
timescales, costs and risks of doing the activity against the benefits to be gained. Think of it as weighing up the pros and cons
and then taking a sensible decision. Therefore, business case also known as Cost-Benefit analysis.
Why have a business case?

• Projects should not just start on a whim or because of vanity – although a lot of money has been wasted over the years
on such projects.
• For business organisations, justification for a project usually takes a commercial form i.e. evaluating how much money
could be made from the investment. For example, investing money in developing a new software app to bring first to
market, might be deemed to bring certain monetary benefits (in terms of sales) which exceeds the costs of investment.
Project Portfolio Management
Definition: Project portfolio management (PPM) refers to a process used by project managers and project management
organizations (PMOs) to analyze the potential return on undertaking a project.
It is the centralized management of the processes, methods, and technologies used by project managers and project
management offices (PMOs) to analyze and collectively manage current or proposed projects based on numerous key
characteristics.
Objectives:
• The 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 players, who will work towards achieving the project's objectives.
Benefits:
• Greater adaptability towards change.
• Constant review and close monitoring brings about a higher return.
• Management's perspectives with regards to project portfolio management is seen as an 'initiative towards higher return'.
Therefore, this will not be considered to be a detrimental factor to work.
• Identification of dependencies is easier to identify. This will eliminate some inefficiency from occurring.
• Helps to concentrate on the strategies, which will help to achieve the targets rather than focusing on the project itself.
Evaluation of Individual Projects
Definition: It is the process of evaluating individual projects to select the ones to be implemented, so that the broader
objectives of the organization can be fulfilled. The criteria used for selecting a project are similar to the criteria used for
making a choice in any other aspect of business.
The models to help in deciding on projects are sophisticated but will represent only a part of the reality. The decision will
ultimately have to be taken by the entrepreneur or the manager, and these models will only aid the decision-making process.
1.Profitability: The most commonly used metric to select projects is their profitability. Some entrepreneur would like to use
the rate of return or the discounted cash flows as their criteria of choice. Many others prefer to use the payback period as the
metric to compare projects.
2. Competitive Necessity: This is the priority when the project is chosen based on what seems most essential to maintain the
company’s competitive position in the market.
3. Operating Necessity: Sometimes, a project has to be undertaken because it is vital to continue the business operations of
the company.
4. Scoring: To overcome the shortcomings of using just profitability for selecting a project, a number of decision criteria are
taken into account in a scoring model. Scoring models can vary in their complexity and information requirements.

Cost-Benefit Evaluation Techniques
Definition: Cost-benefit analysis (CBA) is the standard way of evaluating the economic benefits of any project. It is
a technique used to compare the total costs of a programme / project with its benefits, using a common metric (most
commonly monetary units). This enables the calculation of the net cost or benefit associated with the programme.
 It is one of the important and common way of carrying “economic assessment” of a proposed information system.
 This is done by comparing the expected costs of development and operation of the system with its benefits.
 So it takes an account:
• Expected cost of development of system
• Expected cost of operation of system
• Benefits obtained
 Assessment is based on:
• Whether the estimated costs are executed by the estimated income.
• And by other benefits
 For achieving benefit where there is scarce resources, projects will be prioritized and resource are allocated effectively.
 The standard way of evaluating economic benefits of any project is done by “cost benefit analysis”

• Cost benefit analysis comprises of two steps:
• Step-1: identifying and estimating all of the costs and benefits of carrying out the project.
• Step-2: expressing these costs and benefits in common units.
• Step-1:
– It includes
• Development cost of system.
• Operating cost of system.
• Benefits obtained by system.
– When new system is developed by the proposed system, then new system should
reflect the above three as same as proposed system.
• Example: sales order processing system which gives benefit due to use of new
system.
• Step-2:
– Calculates net benefit.
– Net benefit = total benefit - total cost.
– (cost should be expressed in monetary terms).

Three types of cost:
• Development costs: includes salary and other employment cost of staff involved.
• Setup costs: includes the cost of implementation of system such as hardware, and also file conversion, recruitment
and staff training.
• Operational cost: cost require to operate system, after it is installed.
Three categories of benefits:

1) Direct benefits: directly obtained benefit by making use of/operating the system.
Example: reduction of salary bills, through the introduction of a new, computerized system.
2) Assessable indirect benefits: these benefits are obtained due to updation / upgrading the performance of current
system. It is also referred as “secondary benefits”.
Example: “use of user – friendly screen”, which promotes reduction in errors, thus increases the benefit.
3) Intangible benefits: these benefits are longer term, difficult to quantify. It is also referred as “indirect benefits”.
Example: enhanced job interest leads reduction of staff turnover, in turn leads lower recruitment costs.

Cash Flow Forecasting
 A cash flow forecast is a plan that shows how much money a business expects to receive in, and pay out, over a given
period of time.
 A cash flow forecast is a projection of an organisations future financial position based on anticipated payments and
receivables. The process of deriving a cash flow forecast is called cash flow forecasting.
 The main goal of a cash flow forecasting is to assist with managing liquidity within an organisation and ensuring that the
business has the necessary cash to meet its obligations and avoid funding issues, essentially better management of
working capital. Underneath the high level goal of liquidity management, there are often a number of reasons why
companies set up a cash flow forecasting process, these include:
• Covenant forecasting and half / full year reporting visibility.
• Interest and debt reduction.
• Short term liquidity planning.
• Long Term Planning / Budgeting Purposes (e.g. 3 year plan)
 A cash flow forecast is a document that helps estimate the amount of money that’ll move in and out of your business. It
also includes your projected income and expenses. Cash flow forecasts typically cover the next 12 months, but can also be
used for shorter periods of time – like a week or a month.
Year Project A Project B Project C
0 (Year the project is implemented) -5,00,000 -7,00,000 -6,00,000
1 2,00,000 2,00,000 1,50,000
2 2,00,000 3,00,000 2,50,000
3 2,00,000 3,25,000 2,50,000
Net Profit 1,00,000 1,25,000 50,000Copyright © PROF. GUFRAN QURESHI
Cost Benefit Evaluation Techniques
It consider
• the timing of the costs and benefits
• the benefits relative to the size of the investment
Common method for comparing projects on the basic of their cash flow forecasting.
1) Net profit
2) Payback Period
3) Return on investment
4) Net present Value
5) Internal rate of return
I] Net Profit
 Net Profit calculated by subtracting a company's total expenses from total income showing what the company has
earned (or lost) in a given period of time (usually one year). It also called net income or net earnings or bottom line.
Net profit=total incomes-total costs
 Net profit tells you your true bottom line – how much money you’re actually left with at the end of the day
 This is a simple method of calculating the total benefits of the projects. However, this method does not show profit
relative to the size of the investment.
E.g. (Refer Cash Flow Forecasting)
II] Payback/Payout Period
Definition: The payback period also called the payout method is the time taken to recover the initial investment or is the
length of time required for cumulative incoming returns to equal the cumulative costs of an investment.
The payback period refers to the amount of time it takes to recover the cost of an investment.
Payback period is the time required to recover the initial cost of an investment. It is the number of years it would take to
get back the initial investment made for a project.
PBP = Year previous to BEP + Total Cash Outflow – Cumulative cash inflow previous to BEP
X 12 months
Cash inflow during breakeven year
Advantages
• It is simple and easy to calculate.
• It is also a seriously flawed method of evaluating investments
Disadvantages
• It attaches no value to cashflows after the end of the payback period.
• It makes no adjustments for risk.
• It is not directly related to wealth maximisation as NPV is.
• It ignores the time value of money.
• The "cut off" period is arbitrary.
Ex: M/s A Ltd has to invest Rs. 5 lakhs in project A or Project B. The estimated inflows of each project are as follows:
Year Project A Project B

1 1,80,000 2,50,000
2 1,10,000 1,50,000
3 1,50,000 1,00,000
4 1,80,000 1,10,000
Solution:
Year Project A CIF Cumulative Project B Cumulative
1 1,80,000 1,80,000 2,50,000 2,50,000
2 1,10,000 2,90,000 1,50,000 4,00,000
3 1,50,000 4,40,000 1,00,000 5,00,000
4 1,80,000 6,20,000 1,10,000 6,10,000
PBP = Year previous to BEP + Total Cash Outflow – Cumulative cash inflow previous to BEP
X 12 months
Cash inflow during breakeven year
Project A = 3 years + 500000 – 440000
X 12 months = 3 years 4 months (or) 3.33 years
180000
Project B = 3 years Copyright © PROF. GUFRAN QURESHI
III] Return on Investment (ROI)
Definition: The return on investment also called the accounting or average rate of return (ROR) is a performance measure used to
evaluate the efficiency of an investment or compare the efficiency of a number of different investments.
It provides a way of comparing the net profitability to the investment required.
A high ROI means the investment's gains compare favourably to its cost. As a performance measure, ROI is used to evaluate the efficiency
of an investment or to compare the efficiencies of several different investments.
ROI (%) = Avg. Net Profit X 100

Cash outflow
Advantages
• It relates net income to investments made in a division giving a better measure of divisional profitability.
• ROI helps in making comparison between different business units in terms of profitability and asset utilization.
Disadvantages
• It takes no account of the timing of the cash flows.
• Rate of returns bears no relationship to the interest rates offered or changed by bank.

Ex: M/s A Ltd has to invest Rs. 5 lakhs in project A or Project B. The estimated inflows of each project are as follows:
Year Project A Project B

1 1,80,000 2,50,000
2 1,20,000 1,50,000
3 2,50,000 1,00,000
4 1,80,000 1,10,000
Solution:
Year Project A CIF Project B CIF
1 1,80,000 2,50,000
2 1,20,000 1,50,000
3 2,50,000 1,00,000
4 1,80,000 1,10,000
Total 7,30,000 6,10,000
ROI (%) = Avg. Net Profit X 100
Cash outflow
Project A (%) = 730000/4 100 = 36.5% Project B (%) = 610000/4
X X 100 = 30.5%
500000 500000 Copyright © PROF. GUFRAN QURESHI
IV] Net Present Value (NPV)
 Net present value is used in Capital budgeting to analyze the profitability of a project or investment. It is calculated by
taking the difference between the present value of cash inflows and present value of cash outflows over a period of
time.
 As the name suggests, net present value is nothing but net off of the present value of cash inflows and outflows by
discounting the flows at a specified rate.
 If the present value of the cash inflows is greater than the present value of the cash outflows, the project is
acceptable i.e. NPV>0, accept and NPV<0, reject.
NPV = Present Value CIF – Present Value COF
Advantages
1. Net present value method is a tool for analyzing profitability of a particular project. It takes into consideration time
value of money.
2. Net present value takes into consideration all the inflows, outflows and risk involved. Therefore NPV is a
comprehensive tool taking into consideration all aspects of the investment.
Disadvantages
1. The main limitation of Net present value is that the rate of return has to be determined. If a higher rate of return is
assumed, it can show false negative NPV, also if a lower rate of return is taken it will show the false profitability of
the project and hence result in wrong decision making.
2. NPV cannot be used to compare two projects. Considering the fact that many businesses have a fixed budget and
sometimes have two project options, NPV cannot be used for comparing the two projects because of the size of the
projects. Copyright © PROF. GUFRAN QURESHI
Ex: M/s A Ltd has to invest Rs. 5 lakhs in project A assuming discounting factor 15%. The estimated inflows of project are
as follows:
Year Project A
1 1,00,000
2 2,00,000
3 1,50,000
4 2,00,000
Solution:
Year Project A CIF PV @ 15% PVCIF
1 1,00,000 0.8696 86960
2 2,00,000 0.7561 151220
3 1,50,000 0.6575 98625
4 2,00,000 0.5717 114340
Total 451145
NPV = Present Value CIF – Present Value COF

Project A = 451145 – 500000 = (48855)
Comment: Since NPV is negative, the project is not feasible. Copyright © PROF. GUFRAN QURESHI
V] Internal Rate of Return (IRR)
 Internal rate of return (IRR) is the discount rate that makes the net present value of all cash flows (both positive and
negative) equal to zero for a specific project or investment.
 In other words, if we computed the present value of future cash flows from a potential project using the internal rate
as the discount rate and subtracted out the original investment, our net present value of the project would be zero.
 Once the internal rate of return is determined, it is typically compared to a company’s hurdle rate or cost of capital. If
the IRR is greater than or equal to the cost of capital, the company would accept the project as a good investment.
Advantages
1. The first and the most important thing is that the internal rate of return considers the time value of money when
evaluating a project..
2. The most attractive thing about this method is that it is very simple to interpret after the IRR is calculated. If the IRR
exceeds the cost of capital, then accept the project, but not otherwise.
Disadvantages
1. IRR assumes that the cash flows are reinvested at the same rate as the project, instead of the cost of capital. Hence,
IRR may not give a true picture of the profitability.
2. IRR works only for investments that have an initial cash outflow (the purchase of the investment) followed by one or
more cash inflows. IRR can't be used if the investment generates interim negative cash flows.

Example of Calculating IRR
It might be easier to look at an example than to keep explaining it. Let’s look at Tom’s Machine Shop. Tom is considering
purchasing a new machine, but he is unsure if it’s the best use of company funds at this point in time. With the new
$100,000 machine, Tom will be able to take on a new order that will pay $20,000, $30,000, $40,000, and $40,000 in
revenue.
Solution:
Let’s calculate Tom’s minimum rate. Since it’s difficult to isolate the discount rate unless you use an excel IRR calculator.
You can start with an approximate rate and adjust from there. Let’s start with 8 percent.
As you can see, our ending NPV is not equal to zero. Since it’s a positive number, we need to increase the
estimated internal rate. Let’s increase it to 10 percent and recalculate.
As you can see, Tom’s internal return rate on this project is 10 percent. He can compare this to other investing
opportunities to see if it makes sense to spend $100,000 on this piece of equipment or investment the money in
another venture.

Risk Evaluation Copyright © PROF. GUFRAN QURESHI
Definition: Risk evaluation is the process of identifying and measuring risk. It is a fundamental business practice that can be applied t o
investments, strategies, commercial agreements, programs, projects and operations.
1. Risk evaluation is meant to decide whether to proceed with the project or not, and whether the project is meeting its objectives.
2. It is the determination of risk management priorities through establishment of qualitative and/or quantitative relationships between
benefits and associated risks.
3. Risk occurs: a) When the project exceed its original specification. b) Deviations from achieving it objectives and so on.
Basic concepts in Risk Management:

I] What is Software Risk?
1. Software risk encompasses the probability of occurrence for uncertain events and their potential for loss within an organization.
2. Risk management has become an important component of software development as organizations continue to implement more
applications across a multiple technology, multi-tiered environment.
3. Typically, software risk is viewed as a combination of robustness, performance efficiency, security and transactional risk propagated
throughout the system.
4. Software risk exists because the
future is uncertain and there are
many known and unknown
things that cannot be
incorporated in the project plan.
5. A software risk can be of two
types:-
a. Internal risks that are within the
control of the project manager.
b. External risks that are beyond
the control of project manager.
II] Concept of Proactive and Reactive risk strategies:
a. Reactive risk strategies:
1. Reactive risk strategy is a response based risk management approach, which is dependent on accident evaluation and audit
based findings.
2. This strategy attempts to reduce the tendency of the same or similar accidents which happened in past being repeated in
future.
3. This strategy solely depends on past accidental analysis and response.
4. This strategy does not have any predefine layout rules.
5. These risks have a smaller impact on the project.
b. Proactive risk strategies:
1. Proactive risk strategy is an adaptive, closed-loop
feedback control strategy based on measurement
and observation.
2. This strategy attempts to reduce the tendency of
any accident happening in future by identifying the
boundaries of activities, where a breach of the
boundary can lead to an accident.
3. This strategy combines a mixed method of past,
present and future prediction before finding
solutions to avoid risks.
4. This strategy have a predefine layout rules.
5. These risks have a great impact on the project
deployment.
III] Risk Management (RM) Process
 Risk management process is nothing but a series of steps that help identify and migrate the risks for the successful closure of
a project. If done correctly and sincerely, construction risk management will reduce not only the likelihood of an event
occurring, but also the magnitude of its impact.
 In the simplest terms, Risk management process is taking preemptive actions to avoid and minimize any kind of jeopardy to a
project in future.
Process:
1. Risk Identification: Risk identification is the process of determining which risks may affect the project and documenting
their characteristics. The key benefit of this process is documentation of existing risks and the knowledge and skills offered
by the project team anticipate risk events.
2. Risk Assessment / Analysis: After all the probable risks have been identified, their valuation is done based on qualitative
and quantitative methods. With risk assessment method, available information is used to extricate the frequency of
occurrence and the level of consequences in risk management.
3. Risk Response: After identification and assessment of the risks are done, available options to avert the risks are marked and
discussed in case they ever crop up in future. Risk response is further subcategorized into Risk avoidance, Risk transfer, risk
mitigation and risk acceptance depending upon the nature of the risks.
4. Risk monitoring and control: Risk
monitoring and control is the process
of identifying, analyzing, and planning
for newly discovered risks and
managing identified risks. Monitoring
and control is done throughout the life
of the project.
Risk Identification Copyright © PROF. GUFRAN QURESHI
Definition: Risk identification is the process of determining which risks may affect the project and documenting their
characteristics. The key benefit of this process is documentation of existing risks and the knowledge and skills offered by
the project team anticipate risk events.
Process:
There are five core steps within the risk identification and management process. These steps include risk identification, risk
analysis, risk evaluation, risk treatment, and risk monitoring.
1. Risk Identification: The purpose of risk identification is to reveal what, where, when, why, and how something could affect
a company’s ability to operate. For example, a business located in central California might include “the possibility of
wildfire” as an event that could disrupt business operations.
2. Risk Analysis: This step involves establishing the probability that a risk event might occur and the potential outcome of each
event. Using the California wildfire example, safety managers might assess how much rainfall has occurred in the past 12
months and the extent of damage the company could face should a fire occur.
3. Risk Evaluation: Risk evaluation compares the magnitude of each risk and ranks them according to prominence and
consequence. For example, the effects of a possible wildfire may be weighed against the effects of a possible mudslide.
Whichever event is determined to have a higher probability of happening and causing damage, it would rank higher.
4. Risk Treatment: Risk treatment is also referred to as Risk Response Planning. In this step, risk mitigation strategies,
preventative care, and contingency plans are created based on the assessed value of each risk. Using the wildfire example,
risk managers may choose to house additional network servers offsite, so business operations could still resume if an onsite
server is damaged. The risk manager may also develop evacuation plans for employees.
5. Risk Monitoring: Risk management is a non-stop process that adapts and changes over time. Repeating and continually
monitoring the processes can help assure maximum coverage of known and unknown risks.
Risk Identification Techniques / Tools Copyright © PROF. GUFRAN QURESHI
Techniques:
There are several tools available that can help the project manager in identifying risks.
1. Documentation Reviews: The standard practice to identify risks is reviewing project related documents such as lessons
learned, articles, organizational process assets, etc.
2. SWOT: SWOT, or strengths, weaknesses, opportunities, threats, is another tool to help with identifying risks. Begin with
strengths and determine what those are as related to the project (though this can work on an organization-level, too). Next,
list the weaknesses or things that could be improved or are missing from the project. This is where the likelihood of
negative risk will raise its head, while positive risk come from the identification of strengths. Opportunities are another
way of referring to positive risks and threats are negative risks.
3. Brainstorming: Brainstorming is done with a group of people who focus on identification of risk for the project. A
brainstorming session is one in which the project team sits together and thinks up with as many risks as possible.
4. Delphi Technique: A team of experts is consulted
anonymously. A list of required information is sent to experts,
responses are compiled, and results are sent back to them for
further review until a consensus is reached.
5. Assumption Analysis: Identification of different assumptions
of the project and determining their validity, further helps in
identifying risks for the project.
6. Root Cause Analysis: Root causes are determined for the
identified risks. These root causes are further used to identify
additional risks.
Risk Assessment Copyright © PROF. GUFRAN QURESHI
Definition: Risk assessment is a step in a risk management procedure. Risk assessment is the determination of quantitative or
qualitative value of risk related to a concrete situation and a recognized threat. Risk assessment involves measuring the
probability that a risk will become a reality.
The procedure for analysis is to conduct the qualitative analysis and once the risk qualifies then quantitative analysis is carried
out.
I] Qualitative Risk Analysis:
1. Qualitative risk analysis is the process of assessing individual project risk characteristics - the probability of occurrence and
the impact they would have on a project if happening - against a scale.
2. The main purpose of the qualitative risk analysis
is prioritizing risks according to their probability
and impact. A project can be exposed to a large
number of different risks.
3. Qualitative risk analysis is carried out using a
risk matrix also called as a probability-impact
matrix.
4. The scale used for the analysis groups project
risks into three or more categories according to
their impact, such as low, medium and high.
5. The risk can impact numerous project elements:
budget, schedule, deliverables, scope or
available resources. The risk probability can be
evaluated using the same categories or expressed
as a percentage (0% to 100%) or odds (0 to 1).
6. The scale can be customized to fit organizational
needs and then used across all projects within an
organization for consistency.
II] Quantitative Risk Analysis:
1. Quantitative risk analysis is a numeric estimate of the overall effect of risk on the project objectives such as cost and
schedule objectives. The results provide insight into the likelihood of project success and is used to develop contingency
reserves.
2. It uses verifiable data to analyse the effects of risk in terms of cost overruns, scope creep, resource consumption, and
schedule delays.
3. Quantitative Risk Analysis uses available relevant and verifiable data to produce a numerical value which is then used to
predict the probability (and hence, acceptability) of a risk event outcome.
4. Main advantages of a quantitative approach is to determine the probability of achieving a specific project objective.
5. A ranking of risks based on their probability and quantum impact is created.
a. Project communication plan: Risk status needs to be communicated to all those concerned. The identification, analysis
and action needs to be communicated.
b. Enterprise risk procedure: Organizations may devise their own rules, procedures and policies when it comes to dealing
with risks. In such cases the project manager will be required to follow these rules.
c. Organizational process assets: There are chances that the organization may have implemented a similar project in the past.
In such case, the project plan back then may prove to be useful in identifying and managing risks.
Cost-Benefit Analysis and Risk Analysis

1. A cost-benefit analysis (CBA) is the process used to measure the benefits of a decision or taking action minus the costs
associated with taking that action.
2. A CBA involves measurable financial metrics such as revenue earned or costs saved as a result of the decision to pursue a
project.
3. A CBA can also include intangible benefits and costs or effects from a decision such as employee morale and customer
satisfaction.
4. CBA provides a sophisticated approach to the evaluation of risk. This approach considers each possible outcome and the
probability of it occurring and the corresponding value of its outcome.
Risk Profile Analysis Copyright © PROF. GUFRAN QURESHI
1. A risk profile is an evaluation of an individual's willingness and ability to take risks. It can also refer to the threats to which
an organization is exposed. A risk profile is important for determining a proper investment asset allocation for a portfolio.
Organizations use a risk profile as a way to mitigate potential risks and threats.
2. A risk profile identifies the acceptable level of risk an individual is prepared and able to accept. A corporation's risk pro file
attempts to determine how a willingness to take on risk (or an aversion to risk) will affect an overall decision-making
strategy. The risk profile for an individual should determine that person's willingness and ability to take on risk. Risk in this
sense refers to portfolio risk.
3. Risk Capacity: Risk capacity is the quantitative measure of taking a risk. It
maps your current and future financial position which includes factors like
income, savings, expenses, and liabilities. With these factors evaluated, the rate
of returns required to reach your Financial goals is determined. In simple words,
it is the level of the financial risk you can think of affording.
4. Risk Required: Risk required is determined by your risk capacity. It is the risk
associated with the returns needed to reach your financial targets with available
resources. Risk required educates you about what you could potentially be
taking on with a certain investment. It gives you an honest perception and a
clear picture about the type of the risk you are about to take.
5. Risk Tolerance: Risk tolerance is the level of risk you are comfortable with. It
is simply your willingness to accept the fluctuations in the market that may or
may not occur in order to achieve your financial objectives.
Decision Trees Copyright © PROF. GUFRAN QURESHI
1. A decision tree analysis is a specific technique in which a diagram (in this case referred to as a decision tree) is used for the
purposes of assisting the project leader and the project team in making a difficult decision.
2. In project management, a decision tree analysis exercise will allow project leaders to easily compare different courses of
action against each other and evaluate the risks, probabilities of success, and potential benefits associated with each.
3. The decision tree analysis technique allows you to be better prepare for each eventuality and make the most informed
choices for each stage of your projects.
4. It’s important to note that a proper decision tree has four main elements: decision nodes, chance nodes, end nodes, and
branches. Let’s briefly explore each of these individually.
a. Decision Nodes: A decision node, represented on our decision tree diagram as a square, indicates a choice that needs to
be made.
b. Chance Nodes: A circle represents a chance
node and is used to signify uncertain
outcomes. These nodes are used when future
results are not guaranteed.
c. End Nodes: End nodes, like the name suggests,
represent the end of a diagram and illustrates
a final outcome.
d. Branches: Lastly, we have branches. Branches
are what connect the nodes together. Each
branch represents a potential choice and
should be clearly labeled
Programme Management Copyright © PROF. GUFRAN QURESHI
Definition: Program management or programme management is the process of managing several related projects, often with the
intention of improving an organization's performance.
 Program management may provide a layer above the management of projects and focuses on selecting the best group of projects,
defining them in terms of their objectives and providing an environment where projects can be run successfully.
 Programme Management enables the successful implementation of your organisation’s business transformation strategy through an
overarching approach to projects and project delivery across the organisation.
Benefits:
Keeps the focus on the big picture. The Programme Manager acts as an orchestrator to ensure that all the activity going on across
multiple projects continues to support the overall business transformation goal.
Puts control back in your hands. Our Programme Managers ensure that your projects are logically planned and executed, and ensure
that each project is controlled, thereby minimising any risks.
Makes the best use of your resources. A Programme Manager
holds a view of how all people are being utilised, and is able to plan
activities around availability to best maximise everyone’s time.
Gives you consistency across projects. Every Project Manager
brings their own flavour to their work, and it is easy for a single
project to operate in isolation from the rest of your business.
Reduce your costs. Projects can be costly. Managing your projects
across a planned programme of work can allow you to reduce your
overall costs, by making best use of resources, sharing information
across projects, aligning deliverables and cross project dependencies
and minimising overall risk.
Maximise your benefits. The Programme Manager will actively
take responsibility for ensuring that the scoped benefits are realised.
Project Vs Program Copyright © PROF. GUFRAN QURESHI
Programme Management Framework Copyright © PROF. GUFRAN QURESHI
Definition: Program management or programme management is the process of managing several related projects, often with the intention of
improving an organization's performance.
 Programme management is a technique that allows organisations to run multiple, related projects concurrently to obtain significant benefits
from them as a group.
 A project management framework consists of the processes, tasks, and tools used to take a project from start to finish. It encompasses all the
key components required for planning, managing, and governing projects.
There are eight important areas in the programme management framework:
1. Vision: Vision is the high level strategy or idea to drive the organisation towards a
goal, benefit or other desired outcome.
2. Aims and objectives: The aims and objectives is a more detailed statement that
explains exactly what is required. This provides a point of reference to go back to
when renewed focus is required.
3. Scope: The scope gives boundaries to the programme explaining what exactly it is
that will be delivered.
4. Design: Design is the way in which the projects that make up the programme are put
together. In this process the programme manager considers which projects have
dependencies on others, therefore which should come first, can run concurrently, and
those that come last.
5. Approach: The approach is the way the programme will be run. It is dependent on
many factors and it is left to the skill of the programme manager to decide the most
effective way.
6. Resource management: Resource management looks at the scheduling and
allocation of resources. Short term and longer-term views should be taken.
7. Responsibilities: Responsibilities identifies and allocates responsibility for each area
of the programme. Every member of the programme must clearly understand his or
her roles and the roles of the other team members.
8. Benefits realization: Benefits realisation is the process at the end of the programme
by which the benefits identified at the beginning of the programme and measured.
Stages in Programme Management Copyright © PROF. GUFRAN QURESHI
There are four important stages in the programme management. These stages take the programme from initiation, based on strategy and a desire
for change, right through to the final realisation of a defined business objective or benefit.
1. Programme Identification: This is a high level process where the strategy
and direction of the organisation are decided. It is from this that the
programmes required to realise these strategies are determined. A document
for each programme is produced outlining the business case, alignment to
strategy, scope and the expected business objective or benefits.
2. Programme Planning: The planning stage is where the design of the
programme takes place. The programme manager in establishing the
programme will:
i. Define clear objectives.
ii. Agree an approach.
iii. Agree roles and responsibilities with the team.
iv. Set-up communication channels.
v. Agree priorities of the projects that make up the programme.
vi. Complete project planning.
vii. It is important at this stage to identify adequate levels of resource for the
early projects and identify the requirements for later projects.
3. Programme Delivery: At this stage, the individual project managers run
the identified projects. The programme manager's responsibility at this stage
is to monitor progress, assess risks and report progress to the steering
committee or leadership.
4. Programme Closure: Like projects, programmes have a finite life and are
closed once they achieve their defined business objective or benefit. Before
the programme is closed, the programme manager must demonstrate to the
steering committee or leadership that the desired benefits have been
realised, often called 'benefits realisation'.
Managing the Allocation of Resources within Programmes
Definition: Resource allocation is the process of assigning and scheduling available resources in the most effective and
economical manner. Programmes will always need resources and resources are scarce. The task therefore lies with the
programme manager to determine the proper timing of those resources within the project schedule.
1. Know Your Scope: The clearer the programme scope is, the better you’ll be able to figure out how to allocate your
resources. Therefore, take the time to get the full picture of the programme prior to doing any resource allocation.
2. Identify Resources: Before you can allocate resources, you have to have them. So, you have to see who’s currently
available, what equipment you’re going to need or purchase and where are you going to perform the tasks for this
programme, and is that space available.
3. Know Your Resource Dependencies: One way to allocate resources is by not having to allocate them at all. This isn’t as
mystical as it might sound. It involves something far less magical and more practical, planning.
4. Track Time: You always want to keep a close eye on time, how your team is working and if they’re being efficient. To do
this you must keep track of your team’s workload. That requires the right tools to give you real-time data collected on one
page where you can both see and schedule ahead when needed.
5. Use Tools: Project management software, like ProjectManager.com, is a great asset to managing your resources more
productively. With an online tool, you get project data instantly updated.
6. Don’t Over-allocate: Many managers over-allocate, whether because of poor planning or an inability to say no, which
doesn’t help. Instead of bringing in the programme on time and within budget, over-allocation threatens team burnout.
7. Be Realistic: Remember when we mentioned comparing your estimated to actual utilization? This is where that process
helps keep you properly allocated. Using a tool, like ProjectManager.com, is also key to getting an accurate sense of how
the project is going.

Strategic Programme Management
The strategic programme management consists of six interrelated managerial tasks:
I] Stakeholder Analysis: Stakeholders are those who can affect or be affected by the programmes. Stakeholder analysis
though not a lengthy process is a tricky one as it requires the management to identify the conflicting expectations of different
stakeholders and their power and influences on the organization.
II] Vision, Mission and Objectives:

1. Vision: Sets the purpose of the business organization. It also states the direction of where it attempting to go.
2. Mission: The mission statement outlines how the vision to be translated into reality. It also states what is to be done to
achieve the vision.
3. Objectives: These are quantifiable targets which will enable management to gauge the success of the strategy. It enables
measuring the success of the strategy
 Analysis of Factors influencing Strategy Formulation
a. Environment Analysis: Government policies, change in customer attitude,
technology change. It is important that the organization be watchful for these forces
and predicts the environment in which it might have to operate.
b. Firm Analysis: Very important that the firm identifies its own resources and analyses
them for their ability to deliver. Firms should allocate and utilize resources in the
most efficient manner to get maximum return on investment.
c. Industry Analysis: It is important that the strength of the competitors is analysed.
The size and trends of the industry also need to be taken into account.
d. Product Analysis: The business needs to analyse the competitive position of its
products in the context of the development in the market. Copyright © PROF. GUFRAN QURESHI
III] SWOT Analysis: SWOT analysis combines the analysis of the firm’s internal and external environment. The strengths,
weaknesses, of the firm are in context of the opportunities and threats. The aim of this analysis is to achieve an optimum match
of the firm’s resources with the environment with the objective of attaining competitive advantage.
IV] Generate Strategic Options: Strategic options are generated based on the analysis undertaken so far. The strategies
generated should be able to provide the firm competitive advantage, explore alternative strategic direction & alternative
methods to employ strategies.
V] Evaluating Strategic Options: It is very difficult to identify which strategic option to select despite all the analysis.
Strategic management is considered to be more an art than science. Despite all this the decision maker should resort to the
various qualitative and quantitative techniques available to finalize the strategy.
VI] Implementation, Monitoring and Review: At the implementation stage the strategy has to be clubbed with the
operational plan, organization chart, clear job description, procedures and manuals, budgets and control systems. Budgets
ensure that execution as per plan. Budgetary objectives and constant monitoring ensure that strategic objectives are
accomplished.

Creating a Programme Copyright © PROF. GUFRAN QURESHI
Definition: A program is created to manage a number of related projects, each contributing to the overall business objective,
where it’s efficient to manage them together to get the desired outcome.
I] Programme Mandate: The programme mandate is the first stage of a programme. The purpose of the program mandate is to
describe the required outcomes from the program, based on the strategic and policy objectives. It is also called the strategic or
embryonic business case in some organizations.
II] Programme Brief: The purpose of the program brief is to assess whether the program is viable and achievable. It is also
referred to as the outline business case. Information stated here evolves into many documents including the vision statement, risk
and issue register, and business case in the “defining a program” process.
III] The Vision Statement: The purpose of the vision statement is to provide details on how “defining a program” process will
be undertaken. A small team will undertake this planning and a programme manager with similar experience will be appointed to
handle the day-to-day responsibilities of the programme.
IV] The Blueprint:
 Blueprint is expanded and developed from vision and represents
the desired future state. Blueprint is a model of future
organisation, its working practices and processes, the information
it requires and technology it needs.
 It also presents a gap analysis from the current state to future
state. This helps teams to effectively explore the alternative
approaches to deliver the new capability.
 The purpose of a blueprint statement is to specify and ensure the
coherence of the entire future state and the solution set that will
lead to that future.
Aids to Programme Management Copyright © PROF. GUFRAN QURESHI
I] Dependency Diagrams: All program managers must track the dependencies that exist between the projects which make up
their program. The easiest way to do this is by using a Dependency Diagram.
A Dependency Diagram allows us to visualise the critical cross-project dependencies throughout the duration of the program. The
Dependency Diagram should not be confused with the Program Plan, which shows the milestones of the different projects and the
points at which benefits can start to be realised during the program.
A dependency diagram provides two key benefits to you as a program manager:
1. It allows you to ensure the complex network of project interdependencies is coordinated and synchronised.
2. It allows you to track that work packages produced by the different project teams are integrated.
In this example we can see that in order for the advertising agency to be briefed by the Marketing team, they must have the
final Hardware and Software designs. As the Hardware and Software teams are different project teams, before the designs are
given to marketing they will be checked for consistency by the Quality Assurance team.
During a program, a program manager will spend a large portion
of their time tracking and coordinating project interdependencies,
and the Dependency Diagram is the key tool use for doing this.
Types-
1. Finish to Start: When one task must finish so the next task can
begin.
2. Start to Start: When two tasks can start at the same time.
3. Start to Finish: Second task in the relationship cannot finish
until the first task starts but the second task can finish at
anytime after the first task starts.
4. Finish to Finish: Two tasks can start at any time but must finish
at the same time.
II] Delivery Planning: The delivery plan of project deliverables is a strategic element for every Project Manager.
The goal of every project is, in fact, to produce a result that serves a specific purpose. With the word “purpose”, we can mean
the most disparate goals: a software program, a chair, a building, a translation, etc.
 In essence, all planned activities should be directly related to the production of a deliverable. The Project Manager must have
in mind what the delivery plan of the deliverables is.
 Any project activity that does not directly contribute to the production of a product should be restructured or removed from
the project plan.
 Regardless of how many tasks have been completed by the project manager and his team, until a deliverable is not produced
and accepted by the client, the project team may not be paid!
Some Reservations about Programme Management

 Programme management has a much broader context than project management. According to Project Management Institute
(PMI), “A Program is a group of related projects managed in a coordinated manner to obtain benefits and control not
available from managing them individually.”
 The objective of program management is to optimize the resource utilization among projects and reduce the friction to
increase the organization’s performance.
 This means that in a program, you will have multiple projects, which are either
similar or related to each other, and you manage them at a higher level.
 Programs may also include elements of related work outside of the scope of
individual projects within the program.
 Project management addresses the management of the project; while program
management helps you set the project management processes and measure the
project results.
Benefits Management Copyright © PROF. GUFRAN QURESHI
Definition: Benefits management is a structured approach for maximising good business outcomes for an organisation as a result
of change. It is fundamental to effective programme and project management and successful delivery.
 Benefits management involves identifying, planning, measuring and tracking benefits from the start of the programme or
project investment until realisation of the last projected benefit.
 It aims to make sure that the desired benefits are specific, measurable, agreed, realistic and time bounded. The term benefits
management is often used interchangeably with the term benefits realisation.
 Benefits management is the common thread between programme
and project delivery and successful change management.
 The approach to programme, project and change management
needs to be benefit driven to ensure maximum value from the
investment in change.
 Ultimately an organisation’s approach to benefits realisation
needs to be integrated within corporate planning to ensure a
strong management focus beyond implementation of the
programme or project.
Ch-3 An Overview of Project Planning Copyright © PROF. GUFRAN QURESHI
Definition: Project planning refers to everything you do to set up your project for success. It is the process you go through to
establish the steps required to define your project objectives, clarify the scope of what needs to be done and develop the task
list to do it.
Project planning is at the heart of the project life cycle, and tells everyone involved where you’re going and how you’re going
to get there.
The purpose of the project planning phase is to:
 Establish business requirements.
 Establish cost, schedule, list of deliverables, and delivery dates.
 Establish resources plans.
 Obtain management approval and proceed to the next phase.
Project planning:
 guides the execution of the project, coordinating the activities.
 facilitates better communication between the project stakeholders.
 provides a means of tracking and monitoring the progress.
 provides a detailed documentation regarding planning decisions.
Project planning is of significant importance for the success of the project.

 Careful planning helps prevent costly mistakes.
 Good planning is the key to meet the project objectives within defined time
and budget.
Introduction to Step Wise Project Planning Copyright © PROF. GUFRAN QURESHI
 Planning is the most difficult process in project management.
 The planning phase is when the project plans are documented,
the project deliverables and requirements are defined, and the
project schedule is created.
 It involves creating a set of plans to help guide your team through
the implementation and closure phases of the project.
 The plans created during this phase will help you manage time,
cost, quality, changes, risk, and related issues.
 The framework described is called the Stepwise method to help to
distinguish it from other methods.
 Each step of project planning has different activities to perform.
Activities within Steps:
Step 0: Select project.
Step 1: Identify project scope and objectives.
Step 2: Identify project infrastructure.
Step 3: Analyze project characteristics.
Step 4: Identify project products and activities.
Step 5: Estimate effort for each activity.
Step 6: Identify activity risks.
Step 7: Identify activity risks.
Step 8: Review / Publicize plan.
Step 9: Execute plan.
Step 10: Lower level of planning
Step 0 : Select project – This is called step 0 because in a way of project planning, it is outside the main project planning
process. Possibility study suggests us that the project is worthwhile or not. While feasibility study suggests that there is a
business case for the project, it would still need to be established that it should have priority over other projects. This evaluation
can be part of project portfolio management.
Step 1 : Identify project scope and objectives – Project scope management includes the processes required to ensure that the
project includes all the work required, and only the work required, to carry out the project successfully. The activities in this step
ensure that all parties to the project agree on the objectives and are dedicated to the success of the project.
Step 1.1: Project Scope Initiation Process: In this process the project sponsor gives the project manager the authority and
resources to define the project scope.
Step 1.2: Project Scope Planning Process: The project scope planning process identifies what work is and is not part of the
project. It primarily settles the boundaries of the project work. It is essential to also identify what is not a part of the project work
to avoid future problems.
Step 1.3: Project Scope Definition Process: The project scope definition process identifies the project deliverables and the
product deliverables. Project deliverables is the work that needs to be accomplished to deliver a product with specific features
and functions.
Step 1.4: Project Scope Verification Process: The scope verification process checks the scope for accuracy and completeness.
The scope boundaries and deliverables should be agreed upon by the project sponsor and project manager.
Step 1.5: Project Scope Change Control: The change control process has to approve the change to initiate amendments in
project schedule and budget. The project scope change control process also protects the scope boundaries from expanding
unnecessary due demands of additional features and functions to the project scope.
Step 2 : Identify Project Infrastructure – Projects are rarely carried out in a vacuum. There is usually some kind of
infrastructure into which the project must fit. Where the project managers are new to the organization, they must find out the
precise nature of this infrastructure.
Step 2.1: Identify relationship between the project and strategic planning.
Step 2.2: Identify installation standards and procedures.
Step 2.3: Identify project team organization.
Project Infrastructure refers to the organisational structure, processes, tools,

techniques and training an organisation puts in place to make projects more
successful.
Organisational Structure – Organisational structure including such support
mechanisms as project management office, project recruiting function,
financial monitoring area etc. It also covers lines of communication and
escalation.
Processes – Typically methodologies, checklists and guidelines.
Tools – Software and templates.
Techniques – Repeatable processes such as kick off meetings, PIRs (Post
Implementation Reviews), analysis techniques, etc.
Training – Formal and informal training and reference documentation.

Step 3 : Analyze Project Characteristics – The general purpose of this part of planning operation is to ensure that the appropriate
methods are used for the project. The project manager needs to analyse the project characteristics and this can be done through the
project charter. It is the time to draft the project charter (Contract).
The Project Charter serves as a road map for the project manager and states the goals that are to be achieved from the project.
A Project Charter gives a clear definition of the project, its attributes, the end results and the project authorities.
The Project Charter Covers

• Documenting the project’s MOV: Although the project’s MOV was included in the business case, it is important that the MOV be
clearly defined and agreed upon before developing or executing the project plan. At this point, the MOV must be cast in stone. Once
agreed upon, the MOV for a project should not change.
• Defining the project infrastructure: The project charter defines all of the people, resources, technology, methods, project
management processes, and knowledge areas that are required to support the project. In short, the project charter will detail everything
needed to carry out the project.
• Summarizing the details of the project plan: The project charter should summarize the scope, schedule, budget, quality objectives,
deliverables, and milestones of the project. It should serve as an important communication tool that provides a consolidated source of
information about the project that can be referenced throughout the project life cycle.
• Defining roles and responsibilities: The project charter should not only identify the project sponsor, project manager, and project
team, but also when and how they will be involved throughout the project life cycle. In addition, the project charter should specify the
lines of reporting and who will be responsible for specific decisions.
• Showing explicit commitment to the project: In addition to defining the roles and responsibilities of the various stakeholders, the
project charter should detail the resources to be provided by the project sponsor and specify clearly who will take ownership of the
project’s product once the project is completed.
• Setting out project control mechanisms: Changes to the project’s scope, schedule, and budget will undoubtedly be required over the
course of the project. But, the project manager can lose control and the project team can lose its focus if these changes are not managed
properly. Therefore, the project charter should outline a process for requesting and responding to proposed changes.
Elements / Components of the Project Charter Copyright © PROF. GUFRAN QURESHI
The project charter is used to authorize a project manager and to give an overview of a project to the key stakeholders that do not like to go into
the details of your project.
1. Background (Introduction): Always start with an introduction telling the reader what is this project all about. It doesn’t have to be long
where it can be a summary of a few lines of sentences.
2. Goals (Objective): State the objective of your project. This can also be the output of your project of what your project will produce at the
end of it.
3. Stakeholders (Roles & Responsibilities): Key stakeholders such as project sponsor, project manager, and your functional manager
shouldn’t be out of your identification process. If you foresee the needs of other key stakeholders such as your directors, include them as
well in here.
4. Measurable Organizational Value (MOV): Although the project’s MOV was included in the business case, it is important that the MOV
be clearly defined and agreed upon before developing or executing the project plan. At this point, the MOV must be cast in stone. Once
agreed upon, the MOV for a project should not change.
5. Milestones (Scope): Having scope in your charter gives an overview to your busy stakeholders to know what you want to deliver in the
project by just glance over. Break the high-level requirements into key milestones that your key stakeholders want to see.
6. Project Budget: Money has always been the main concern of your stakeholder. You might not have the most accurate project budget now
because you might be relying on past project experience and a rough estimate to come out with a project budget.
7. Constraints: Includes your constraints of the project over here. It is important to keep your stakeholders updated about every potential
problem so that they could contribute a little to help.
8. Risks: Even at the initialization stage, you should be able to identify some high-level risk of the project. A risk is the uncertainties that
could potentially turn out to be an issue in your project as your project moves on.
9. Assumptions: Whatever you assume will have or will not have, document them. For instance, you could have assumption such as
“sufficient hardware servers are prepared by the client for this project” can be used to ensure your stakeholders are aware o f this.
10. Communications plan: A key event such as kick-off meeting, project progress update, project plan update and etc should be mentioned in
your communication plan of how often it will happen and who will be involved when such communication occurred.
11. Approval: A project charter without approval basically means nothing because no one recognized it. You need at least your project sponsor
to sign off on that document in order for you to be officially authorized as the project manager of that project.
Step 4 : Identify Project Products and Activities – The more detailed planning of the individual activities now takes place.
The longer term planning is broad and in outline, while the more immediate tasks are planned in some detail.
Project Product / Deliverables: The next step after the development and approval of the project scope statement is project
planning. The primary requirement for project planning is the Work Breakdown Structure (WBS) for which the approved
project scope statement is required.
 The project scope statement defines all the project deliverables. These defined deliverables are then clubbed together to form
the Delivery Definition Table (DDT).
 The DDT contains the sequence of the delivery of the deliverables. The DDT is then used to create the Delivery Structure
Table which contains the work packages which is then further used to create the Work Breakdown Structure.
 Thus, WBS is similar to Bill of Material (BOM), wherein a product is broken into its smallest component for which
estimation of time and cost is possible.
 The idea behind WBS is to divide each component till its reaches its smallest component, the work package.
Benefits of WBS
 It details the work required to complete the project
 It breaks down the key project deliverables into smaller portions so that they can be understood by the group and then
parceled out to the necessary parties.
 It defines who the necessary parties will be who are going to complete the work packages or perform the tasks involved.
 It facilitates the quick development of a schedule by allocating effort estimates to specific sections of the WBS.
Developing the WBS

Developing the work breakdown structure means defining the relationships between the project goals, deliverables and scope.
Usually this process is about creating a detailed decomposition of work planned for completion into smaller, more manageable
and measurable component. Developing the work breakdown structure involves the following steps:
• Identify project deliverables based on stakeholder requirements.
• Define the amount of work necessary for producing the deliverables.
• Create a high-level decomposition of work using the above information.
• Specify the high-level decomposition by smaller, more manageable pieces of work to create separate work packages.
Process:
1. The Company Project Manager shall approve Basis of Design Documentation and develop Project Execution Plan as basis
for developing WBS and assigning Codes of Accounts (COA).
2. Based on approved Basis of Design and PEP Project Control Manager/Project Service Manager shall coordinate with
Project Cost Control and Scheduler to develop WBS and assign Codes of Account (COA)
3. Project Cost Control shall validate and formalize
SAP/Oracle COA interface.
4. Project Manager shall approve WBS coding.
5. Project Cost Control shall re-classify the Approved
Budget into the WBS structure at the summary level.
6. Project Control Manager and Project Cost Control will
further breakdown the summary WBS/budget into the
detailed project budget for Sub-Projects.
7. Project Control Manager and Project Manager shall
approve WBS/budget breakdown.
Project Activities:
1. Project Planning: It is a set of multiple processes, or we can say that it is a task that performed before the construction of
the product starts.
2. Scope Management: It describes the scope of the project. Scope management is important because it clearly defines what
would do and what would not.
3. Estimation management: This is not only about cost estimation because whenever we start to develop software, but we
also figure out their size(line of code), efforts, time as well as cost.
4. Scheduling Management: Scheduling Management in software refers to all the activities to complete in the specified order
and within time slotted to each activity. Project managers define multiple tasks and arrange them keeping various factors in
mind.
5. Project Resource Management: In software Development, all the elements are referred to as resources for the project. It
can be a human resource, productive tools, and libraries.
6. Project Risk Management: Risk management consists of all the
activities like identification, analyzing and preparing the plan for
predictable and unpredictable risk in the project.
7. Project Communication Management: Communication is an
essential factor in the success of the project. It is a bridge
between client, organization, team members and as well as other
stakeholders of the project such as hardware suppliers.
8. Project Configuration Management: Configuration
management is about to control the changes in software like
requirements, design, and development of the product.
Step 5 : Estimate Effort for Each Activity – There are three early estimates that are needed for a project--effort, duration, and
cost. Of the three, effort hours must be estimated first. Once you understand the effort that's required, you can assign reso urces
to determine how long the project will take (duration) and then you can estimate labor and non-labor costs.
Process:
1. Determine how accurate your estimate needs to be. Typically, the more accurate the estimate, the more detail is needed, and
the more time that is needed.
2. Create the initial estimate of effort hours for each activity and for the entire project. There are many techniques you can use
to estimate effort including task decomposition (Work Breakdown Structure), expert opinion, analogy, Pert, etc.
3. Add specialist resource hours. Make sure you have included hours for part-time and specialty resources. For instance, this
could include freelance people, training specialists, procurement, legal, administrative, etc.
4. Add project management time. This is the effort required to successfully and proactively manage a project. In general, add
15% of the effort hours for project management.
5. Add contingency hours. Contingency is used to reflect the uncertainty or risk associated with the estimate. If you're asked to
estimate work that is not well defined, you may add 50%, 75%, or more to reflect the uncertainty.
6. Calculate the total effort by adding up all the detailed work components.
7. Review and adjust as necessary. Sometimes when you add up all the components, the estimate seems obviously high or low.
Step 6 : Identify Activity Risks – Risk is an integral part of an IT projects and therefore risk identification at the earliest
becomes all the more critical.
Risk identification is an iterative process, wherein the project manger and his team are always on the lookout for risk that may
sneak into the project or may have already sneaked in.
Risk identification needs to be done throughout the project lifecycle, because as the project develops new risk is likely to
emanate and pose a threat to the project.
Risk components:
 Performance risk—the degree of uncertainty that the product will meet its requirements and be fit for its intended use.
 Cost risk—the degree of uncertainty that the project budget will be maintained.
 Support risk—the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance.
 Schedule risk—the degree of uncertainty that the project schedule will be maintained and that the product will be delivered
on time.
Step 7 : Allocate Resources – Resource allocation is the process of assigning and scheduling available resources in the most
effective and economical manner. Projects will always need resources and resources are scarce. The task therefore lies with the
project manager to determine the proper timing of those resources within the project schedule.
Steps for allocating resources:
1. know the scope – to know what is your project about, what you will need to achieve it, and to be able to properly allocate
resources;
2. identify resources – to know which tools, equipment, etc. you will need it completing the project;
3. track time – to have a deep analysis of the progress and current situation as well as be able to control it in the real-time;
4. don’t look only at the big picture – the process of working on a project is not done with task allocation. Once you allocate
resources you have to keep track of all of them. If you lose at least one tiny detail, your project may fail;
5. don’t over-allocate – because your team will experience burnout and their productivity will significantly drop.
Step 8 : Review / Publicize Plan –

 Review quality aspects of the project plan
1. Each task should have quality criteria.
2. These quality checks have to be passed before the activity can be “signed off” as completed.
 Document plans and obtain agreement
1. Plans should be carefully documented.
2. All the parties to the project must understand and agree on the plan.
Step 9 & 10 : Execute Plans and Lower Levels of Planning –

1. Once the project is started, plans will need to be drawn up in greater detail for each activity as it becomes due.
2. The project plans need to be executed in order to bring the project to reality.
3. The project execution group is entrusted with the task of undertake the work defined in the project plan.
4. The execution task involves coordination people and resources as well as integrating and performing activities in
accordance with the project plan.
5. Detailed and lower level of planning of the soon stages will need to be delayed because more information will be available
nearer the start of the stage.
6. It is necessary to make provisional plans for the more distant tasks.
Unit II
Ch 4: Selection of an Appropriate Project Approach: Introduction, Build or Buy? Choosing
Methodologies and Technologies, Software Processes and Process Models, Choice of Process Models,
Structure versus Speed of Delivery, The Waterfall Model, The Spiral Model, Software Prototyping, Other
Ways of Categorizing Prototypes, Incremental Delivery, Atern/Dynamic Systems Development Method,
Rapid Application Development, Agile Methods, Extreme Programming (XP), Scrum, Lean Software
Development, Managing Iterative Processes, Selecting the Most Appropriate Process Model.
Ch 5: Software Effort Estimation: Introduction, Where are the Estimates Done? Problems with Over- and
Under-Estimates, The Basis for Software Estimating, Software Effort Estimation Techniques, Bottomup
Estimating, The Top-down Approach and Parametric Models, Expert Judgement, Estimating by Analogy,
Albrecht Function Point 12 Analysis, Function Points Mark II, COSMIC Full Function Points, COCOMO II:
A Parametric Productivity Model, Cost Estimation, Staffing Pattern, Effect of Schedule Compression, Capers
Jones Estimating Rules of Thumb.

Ch-4 Selection of an Appropriate Project Approach
Definition: It is concerned with choosing the right approach to a particular project: variously called technical
planning, project analysis, methods engineering and methods tailoring.
 According to a recent survey as little as 29 percent of IT projects undertaken in the government sector and 45 percent in
the private sector were successful in relation to budget, functionality and timeliness.
 There are various project selection methods practised by the modern business organizations. These methods have different
features and characteristics. Therefore, each selection method is best for different organizations.
 Although there are many differences between these project selection methods, usually the underlying concepts and
principles are the same.
 Most of the IT projects are plagued by time and cost overruns. Projects that do not complete on time and within budget can
act as a milestone around the neck pulling the company away from the projected trajectory of growth.
 The “90/90 Rule” of project management goes like this: the first 90 percent of a project takes 10 percent of the time and
effort; the remaining 10 percent of the project takes the other 90 percent of the time and effort.
Build or Buy
Every project manager is faced with the eternal dilemma of whether to
build a business solution from scratch or buy an off the shelf application
to meet the needs of the organization.
The decision whether to build or buy can be made in six steps:
Step 1 : Validate the business need

To compete successfully, managers need to focus on validating that a business need exists prior to deciding upon the enabling
technology and that the need can be readily associated with one of the organization's strategic goals or objectives. Project
manager need to provide an estimated return on investment (ROI) or added value, along with how ROI will be measured.
Step 2 : Identify core business requirements
A core business requirement is one that must be supported by the solution to continue. If a requirement can be only partially
met or not addressed by a solution, it is not a core requirement. It takes effort to identify these requirements, and involving the
right business people determines the success of the process.
Step 3 : Identify architectural requirements
It is extremely important to identify any architectural requirements or standards that a solution must support before determining
if a Commercial off-the-shelf [COTS] or custom solution is the best choice.
Step 4 : Examine existing solutions
At this point, a business need has been pinpointed, ROI has been estimated, and both core business and architectural
restrictions have been identified. Leaders should now take a good look at existing systems.
Step 5 : Do you have in-house skills to support a custom solution?
The major factor that significantly reduces the ROI of a custom solution (and in many cases, ultimately causes the endeavor to
fail) is the lack of available personnel with proper skill sets. It takes many skills to design and deploy a business solution that is
both scalable and extensible.
Step 6 : Does a COTS solution fit your needs?
Although the initial short-term cost of implementing COTS-based solutions is often significantly more than a custom solution,
it has been experience that a COTS solution will usually provide the best ROI over the long term.
Choosing Methodologies and Technologies

 An outcome of project analysis will be the selection of the most appropriate methodologies and technologies.
 Methodologies include techniques like the various flavours of object-oriented (OO) development, SSADM (Structured
Systems Analysis & Design Method) and JSP (Jackson Structured Programming) while technologies might include an
appropriate application-building environment, or the use of knowledge-based system tools.
 As well as the products and activities, the chosen technology will influence the following aspects of a project:
 the training requirements for development staff;
 the types of staff to be recruited;
 the development environment - both hardware and software;
 system maintenance arrangements.
 Methodologies are sets of principles, procedures and techniques that help set up a functional project management process.
 A methodology is a model, which project managers employ for the
design, planning, implementation and achievement of their project
objectives. There are different project management methodologies
to benefit different projects.
 For example, there is a specific methodology, which NASA uses to
build a space station while the Navy employs a different
methodology to build submarines. Hence, there are different project
management methodologies that cater to the needs of different
projects spanned across different business domains.
Software Processes and Process Models

Software Process: A software process (also knows as software methodology) is a set of related activities that leads to the
production of the software. These activities may involve the development of the software from the scratch, or, modifying an
existing system.
Any software process must include the following four activities:
1. Software specification (or requirements engineering): Define the main functionalities of the software and the constrains around
them.
2. Software design and implementation: The software is to be designed, produced and implemented as per the specifications.
3. Software verification and validation: The software must conforms to it’s specification and meets the customer needs.
4. Software evolution (software maintenance): The software is being modified to meet customer and market requirements changes.
A process also includes the process description, which includes:
Products: The outcomes of the an activity. For example, the outcome of architectural design maybe a model for the software
architecture.
Roles: The responsibilities of the people involved in the process. For example, the project manager, programmer, etc.
Pre and post conditions: The conditions that must be true before and after an activity. For example, the pre condition of the
architectural design is the requirements have been approved by the customer, while the post condition is the diagrams describing the
architectural have been reviewed.
Software Process Models: A software process model is a simplified representation of a software process. Each model
represents a process from a specific perspective.
 These generic models are abstractions of the process that can be used to explain different approaches to the software development.
They can be adapted and extended to create more specific processes.
 Some methodologies are sometimes known as software development life cycle (SDLC) methodologies, though this term could also
be used more generally to refer to any methodology.
Choice of Process Models
 The software process model framework is specific to the project. Thus, it is essential to select the software process model according
to the software which is to be developed.
 The software project is considered efficient if the process model is selected according to the requirements. It is also essential to
consider time and cost while choosing a process model as cost and/or time constraints play an important role in software
development.
 The basic characteristics required to select the process model are project type and associated risks, requirements of the pro ject, and
the users.
 One of the key features of selecting a process model is to understand the project in terms of size, complexity, funds available, and
so on.
 In addition, the risks which are associated with the project should also be considered. Note that only a few process models
emphasize risk assessment.
 Based on their experience built over the years project managers have identified twenty criteria that influence the choice of process.
These criteria have been grouped into four broad categories namely: Personnel, Problem, Product & Resources.
Structure v/s Speed of Delivery

 A structured method would mean one which consists of steps, method and rules which when applied would generate system
products. Now each product emanating from such a well defined method would itself be well defined.
 However, the problem with such methods is that they are more time consuming and expensive than other approaches.
 The final outcome of such a system is an error prone and more maintainable system. This kind of method is preferred on larger
projects where it is possible to maintain a balance of costs and benefits.
 Many customers are more interested in getting working applications delivered quickly and at lower cost e.g. RAD and find the
structured approach cumbersome, time consuming and unnecessarily expensive.
 A simpler approach to speeding up delivery is to deliver less. It means that the entire project is broken into a series of small
increments each delivering project deliverables which comprises of useful project functionality.
Waterfall Model
 Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of the project.
 In "The Waterfall" approach, the whole process of software development is divided into separate phases. In this Waterfall model,
typically, the outcome of one phase acts as the input for the next phase sequentially.
The following illustration is a representation of the different phases of the Waterfall Model.
The sequential phases in Waterfall model are −
1. Requirement Gathering and analysis − All possible requirements of the system to be developed are captured in this phase and
documented in a requirement specification document.
2. System Design − The requirement specifications from first phase are studied in
this phase and the system design is prepared. This system design helps in
specifying hardware and system requirements and helps in defining the overall
system architecture.
3. Implementation − With inputs from the system design, the system is first
developed in small programs called units, which are integrated in the next phase.
Each unit is developed and tested for its functionality, which is referred to as Unit
Testing.
4. Integration and Testing − All the units developed in the implementation phase
are integrated into a system after testing of each unit. Post integration the entire
system is tested for any faults and failures.
5. Deployment of system − Once the functional and non-functional testing is done;
the product is deployed in the customer environment or released into the market.
6. Maintenance − There are some issues which come up in the client environment.
To fix those issues, patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the
customer environment.
Spiral Model
 Spiral model is one of the most important Software Development Life Cycle models, which provides support for Risk
Handling.
 In its diagrammatic representation, it looks like a spiral with many loops. The exact number of loops of the spiral is
unknown and can vary from project to project. Each loop of the spiral is called a Phase of the software development process.
Each phase of Spiral Model is divided into four quadrants as shown in the figure. The functions of these four quadrants are
discussed below-
1. Objectives determination and identify alternative solutions (Planning): Requirements are gathered from the customers
and the objectives are identified, elaborated and analyzed at the start of every phase. Then alternative solutions possible for
the phase are proposed in this quadrant.
2. Identify and resolve Risks (Risk Analysis): During the second quadrant all the possible solutions are evaluated to select
the best possible solution. Then the risks associated with that solution is identified and the risks are resolved using the best
possible strategy. At the end of this quadrant, Prototype is built for the best possible solution.
3. Develop next version of the Product (Development & Testing): During the
third quadrant, the identified features are developed and verified through testing.
At the end of the third quadrant, the next version of the software is available.
4. Review and plan for the next Phase (Evaluation): In the fourth quadrant, the
Customers evaluate the so far developed version of the software. In the end,
planning for the next phase is started.
Advantages:
1. High amount of risk analysis hence, avoidance of Risk in enhanced.
2. Good for large and mission-critical projects.
Disadvantages:
1. Can be a costly model to use.
Software Prototyping
 A prototype is a version of a system or part of the system that’s developed quickly to check the customer’s requirements or
feasibility of some design decisions.
 So, a prototype is useful when a customer or developer is not sure of the requirements, or of algorithms, efficiency, business
rules, response time, etc.
 In prototyping, the client is involved throughout the development process, which increases the likelihood of client
acceptance of the final implementation.
 This model can be successfully used for developing user interfaces, high technology software-intensive systems, and
systems with complex algorithms and interfaces. It is also a very good choice to demonstrate the technical feasibility of the
product. The phases of a prototype are:
1. Establish objectives: The objectives of the prototype should be made explicit from the start of the process. Is it to validate
system requirements, or demonstrate feasibility, etc.
2. Define prototype functionality: Decide what are the inputs and the expected output from a prototype. To reduce the
prototyping costs and accelerate the delivery schedule, you may ignore some functionality, such as response time and
memory utilization unless they are relevant to the objective of the prototype.
3. Develop the prototype: The initial prototype is developed that includes
only user interfaces.
4. Evaluate the prototype: Once the users are trained to use the prototype,
they then discover requirements errors. Using the feedback both the
specifications and the prototype can be improved. If changes are
introduced, then a repeat of steps 3 and 4 may be needed.
Advantages: The customers get to see the partial product early in the life
cycle. This ensures a greater level of customer satisfaction and comfort.
Disadvantages: Costly w.r.t time as well as money.
Other Ways of Categorizing Prototypes
 The most important reason for having a prototype is that there is a need to learn about an area of uncertainty. For any prototype it is
essential that the project managers define at the outset what it is intended to learn from the prototype.
 This has a particular relevance to student projects. Students often realize that the software that they are to write as part of their
project could not safely be used by real users. They therefore call the software a 'prototype'. However, if it is a real prot otype then
they must:
a. specify what they hope to learn from the prototype;
b. plan how the prototype is to be evaluated;
c. report on what has actually been learnt.
 Prototypes may be used to find out how a new development technique can be used. Different projects will have uncertainties at
different stages. Prototypes can therefore be used at different stages.
 A prototype might be used, for instance, at the requirements gathering stage to pin down requirements that seem blurred and
shifting. A prototype might, on the other hand, be used at the design stage to test out the users' ability to navigate through a
sequence of input screens.
Extent to which Prototyping is to be done
It would be unusual for the whole of the application to be prototyped. The prototyping
might take one of the following forms, which simulates only some aspects of the target
application.
1. Mock-ups: A mock-up is a visual way of representing a system aspect. A mock-up
shows how the system is going to look like. But still, a mock-up is not clickable.
2. Simulated Interaction: Interaction between the user and the system is simulated
to a certain request. However, the interaction is a simulated one and has limited
scope.
3. Partial Prototype:
a. Vertical – some of the features of the system are prototyped fully.
b. Horizontal – all features of the system are prototyped but not fully.
Incremental Delivery
 Incremental process model is also known as successive version model.
 First, a simple working system implementing only a few basic features is built and then that is delivered to the customer. Then
thereafter many successive iterations/ versions are implemented and delivered to the customer until the desired system is rel eased.
 Incremental development is based on the idea of developing an initial implementation, exposing this to user feedback, and evo lving
it through several versions until an acceptable system has been developed.
 The activities of a process are not separated but interleaved with feedback involved across those activities.
 Each system increment reflects a piece of the functionality that is needed by the customer. This means that the customer can
evaluate the system at early stage in the development to see if it delivers what’s required.
Advantages over Waterfall Model:
1. The cost of accommodating changing customer requirements is reduced. The amount of analysis and documentation that has to be
redone is much less than that’s required with waterfall model.
2. It’s easier to get customer feedback on the work done during development than when the system is fully developed, tested, and
delivered.
3. More rapid delivery of useful software is possible even if all the functionality hasn’t been included. Customers are able to use and
gain value from the software earlier than it’s possible with the waterfall model.
Disadvantages of Incremental Delivery:
1. Documentation of each version produced needs to be done which is a costly affair.
2. Not easy for managers to measure and monitor the progress.
3. Each phase of an iteration is rigid and do not overlap each other.
Incremental Model can be a plan-driven or agile, or both:
 Incremental development is one of the most common approaches. This approach can be
either a plan-driven or agile, or both.
 In a plan-driven approach, the system increments are identified in advance, but, in the
agile approach, only the early increments are identified and the development of later
increments depends on the progress and customer priorities.
Atern / Dynamic Systems Development Method (DSDM)
 DSDM is an agile software development methodology. It is an iterative, incremental approach that is largely based on the Rapi d
Application Development (RAD) methodology. The method provides a five-phase framework consisting of:
1. Feasibility Study: It establishes the essential business necessities and constraints related to the applying to be designed then
assesses whether or not the application could be a viable candidate for the DSDM method.
2. Business Study: It establishes the use and knowledge necessities that may permit the applying to supply business value;
additionally, it is the essential application design and identifies the maintainability necessities for the applying.
3. Functional Model Iteration: It produces a collection of progressive prototypes that demonstrate practicality for the client. The
intent throughout this unvarying cycle is to collect further necessities by eliciting feedback from users as they exercise the
paradigm.
4. Design and Build Iteration: It revisits prototypes designed throughout useful model iteration to make sure that everyone has been
designed during a manner that may alter it to supply operational business price for finish users. In some cases, useful model
iteration and style and build iteration occur at the same time.
5. Implementation: It places the newest code increment (an “operationalized” prototype) into the operational surroundings. It ought
to be noted that: (a) the increment might not 100% complete or,
(b) changes are also requested because the increment is placed into place.
In either case, DSDM development work continues by returning to the useful
model iteration activity. https://airfocus.com/glossary/
Advantages: what-is-dynamic-systems-
1. Projects are delivered on time, whilst still allowing flexibility. development-method/
2. Progress can be easily understood across the organization.
3. Business cases are at the core of the DSDM model, ensuring delivered
projects have real business value.
Disadvantages: Large management overhead and costly implementation makes
this unsuitable for small organizations.
How Does DSDM Help to Overcome Development Pitfalls?
Many systems fall short of meeting the needs of the users and purpose they were designed for, causing the system to either be
abandoned or overhauled. There are a number of ways this may happen:
1. Failure to meet the purpose / solve the problem it was designed for - DSDM allows for user testing all through the
development process, thus allowing developers to get prompt feedback on the usability and suitability of the product.
2. Cost outweighs benefits, or cost is too high altogether - In DSDM, a Business Study is done at the beginning of the
project, greatly decreasing the likelihood of late surprises in the financial realm.
3. Poor communication between involved parties - DSDM stresses communication and collaboration between all interested
parties - developers, users, etc.
4. The users finds the program either too hard to use that it does not work as expected - DSDM allows for user testing
all through the development process, thus allowing developers to get prompt feedback on the usability and suitability of the
product.
5. Hidden flaws surface in the system due to poor design or implementation - In DSDM, prototyping helps to ensure that
the system is designed correctly and that everyone knows how it will work. Unit testing helps to uncover hidden bugs, and
incremental development allows for user testing all through the development process.
6. Users resist the instantiation of the system, either for political
reasons, or a lack of commitment to it - In DSDM, since the users
are actively involved in the development of the system, they are more
likely to embrace it and take it on.
7. The system is in-flexible and/or un-maintainable, and unable to
adapt to change - Since DSDM emphasizes flexibility in design, this
is not likely to happen with DSDM.
Core Concepts in DSDM
1. Active User Involvement: The people who will be using the product must be actively involved in its development. This important
in order for the product to end up being useful to the people who will be using it.
2. The Team Must Be Empowered to Make Decisions: The team should be able to make rapid and informed decisions, without
having to cut through red tape to get those decisions approved.
3. Frequent Releases: DSDM focuses on frequent releases. Frequent releases allow for user input at crucial stages in the product's
development. They also ensure that the product is able to be released quickly at all times.
4. Iterative Development, Driven by User Feedback: The development is the system is done in iterations, which allows for
frequent user feedback, and a partial but prompt solution to immediate needs, with more functionality being added in later
iterations.
5. Changes Must Be Reversible: All products should be in a fully known state at all times. This allows for backtracking if a certain
change does not work out well.
6. Requirements are Initially Defined at a High Level: High-level requirements are worked out at the beginning of the project,
before any coding, leaving the details to be worked out during the course of the development.
7. Fitness for Business Purpose is the Goal: Meeting the business need is more important than technical perfection.
8. Integrated Testing: Testing is done at every step of the way, to ensure that the product
being developed is technically sound and does not develop any technical flaws, and that
maximum use is made of user feedback.
9. Collaboration and Cooperation are Essential: Collaboration and cooperation between
all interested parties are essential for the success of the project. All involved parties (not
just the core team) must strive together to meet the business objective.
10. 20% / 80% Rule: DSDM assumes that 80% of the solution can be developed in 20% of
the time that it would take to produce the total solution. DSDM focuses on this 80%,
leaving another 20% for later revisions. DSDM assumes that not all of the requirements
for the final solution are known to begin with, so it is likely that the final 20% of non-
essential features are likely to be flawed anyway.
Rapid Application Development
 The RAD (Rapid Application Development) model is based on prototyping and iterative development with no specific
planning involved. The process of writing the software itself involves the planning required for developing the product.
 RAD model distributes the analysis, design, build and test phases into a series of short, iterative development cycles.
Following are the various phases of the RAD Model –
1. Business Modeling: The business model for the product under development is designed in terms of flow of information
and the distribution of information between various business channels.
2. Data Modeling: The information gathered in the Business Modeling phase is reviewed and analyzed to form sets of data
objects vital for the business. The attributes of all data sets is identified and defined. The relation between these data objects
are established and defined in detail in relevance to the business model.
3. Process Modeling: The data object sets defined in the Data Modeling phase are converted to establish the business
information flow needed to achieve specific business objectives as per the business model.
4. Application Generation: The actual system is built and coding is done by using automation tools to convert process and
data models into actual prototypes.
5. Testing and Turnover: The overall testing time is reduced in the RAD
model as the prototypes are independently tested during every iteration.
Advantages:
• More productivity with fewer people.
• Time between prototypes and iterations is short.
• It is adaptable and flexible to changes.
Disadvantages:
• Only suitable for projects which have a small development time.
• More complex to manage when compared to other models.
• When technical risk is high, it is not suitable.
Agile Methods
 Agile Methodology is a people-focused, results-focused approach to software development that respects our rapidly changing
world. It’s centered around adaptive planning, self-organization, and short delivery times. It’s flexible, fast, and aims for
continuous improvements in quality, using tools like Scrum and eXtreme Programming.
 AGILE methodology is a practice that promotes continuous iteration of development and testing throughout the software
development lifecycle of the project. Both development and testing activities are concurrent unlike the Waterfall model.
 Agile is a process by which a team can manage a project by breaking it up into several stages and involving constant
collaboration with stakeholders and continuous improvement and iteration at every stage. The Agile methodology begins with
clients describing how the end product will be used and what problem it will solve. This clarifies the customer's expectations
to the project team.
1. Faster, smaller. Traditional software development relied on phases like outlining the requirements, planning, design,
building, testing, and delivery. Agile methodology, by contrast, looks to deploy the first increment in a couple weeks and the
entire piece of software in a couple months.
2. Communication. Agile teams within the business work together daily at every stage
of the project through face-to-face meetings. This collaboration and communication
ensure the process stays on track even as conditions change.
3. Feedback. Rather than waiting until the delivery phase to gauge success, teams
leveraging Agile methodology track the success and speed of the development
process regularly. Velocity is measured after the delivery of each increment.
4. Trust. Agile teams and employees are self-organizing. Rather than following a
manifesto of rules from management intended to produce the desired result, they
understand the goals and create their own path to reach them.
5. Adjust. Participants tune and adjust the process continually, following the KIS
or Keep It Simple principle.
Extreme Programming (XP) Copyright © PROF. GUFRAN QURESHI
 Extreme Programming (XP) is a methodology for creating software within a very unstable environment. It allows flexibility
within the modelling process.
 Extreme Programming technique is very helpful when there is constantly changing demands or requirements from the
customers or when they are not sure about the functionality of the system.
 Extreme Programming is one of several popular Agile Processes. It has already been proven to be very successful at many
companies of all different sizes and industries world wide.
 Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative
team. The team self-organizes around the problem to solve it as efficiently as possible.
 Extreme Programming involves −
1. Writing unit tests before programming and keeping all of the tests running at all times. The unit tests are automated and
eliminates defects early, thus reducing the costs.
2. Starting with a simple design just enough to code the features at
hand and redesigning when required.
3. Programming in pairs (called pair programming), with two
programmers at one screen, taking turns to use the keyboard.
While one of them is at the keyboard, the other constantly
reviews and provides inputs.
4. Integrating and testing the whole system several times a day.
5. Putting a minimal working system into the production quickly
and upgrading it whenever required.
6. Keeping the customer involved all the time and obtaining
constant feedback.
Scrum Copyright © PROF. GUFRAN QURESHI
 Scrum is a framework for developing, delivering, and sustaining products (or, more generally, things of value) in complex
domains and environments.
 Scrum is an agile project management methodology or framework used primarily for software development projects with
the goal of delivering new software capability every 2-4 weeks.
 It is a proven approach for building high value products in an iterative and incremental way using teamwork and empirical
process.
 Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various
processes and techniques.
 The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component
within the framework serves a specific purpose and is essential to Scrum’s success and usage.
Scrum Theory
Scrum is founded on empirical process control theory, or empiricism. Three pillars uphold every implementation of empirical
process control: transparency, inspection, and adaptation.
1. Transparency: Significant aspects of the process must be visible to those responsible for the
outcome. Transparency requires those aspects be defined by a common standard so
observers share a common understanding of what is being seen.
2. Inspection: Scrum users must frequently inspect Scrum artifacts and progress toward a
Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that
inspection gets in the way of the work. Inspections are most beneficial when diligently
performed by skilled inspectors at the point of work.
3. Adaptation: If an inspector determines that one or more aspects of a process deviate outside
acceptable limits, and that the resulting product will be unacceptable, the process or the
material being processed must be adjusted. An adjustment must be made as soon as possible
to minimize further deviation.
Lean Software Development Copyright © PROF. GUFRAN QURESHI
 Lean Software Development (LSD) is an agile framework based on optimizing development time and resources, eliminating waste, and ultimately
delivering only what the product needs.
 LSD method is based on the principle "Just in time production". It aims at increasing speed of software development and decreasing cost.
 The Lean approach is also often referred to as the Minimum Viable Product (MVP) strategy, in which a team releases a bare-minimum version of its
product to the market, learns from users what they like, don’t like and want to be added, and then iterates based on this feedback.
 LSD actually borrows its philosophy from the manufacturing industry, which originated the lean development process as a way to optimize production
and assembly lines to minimize waste and maximize customer value.
 In fact, it was originally called the Toyota Production System, because automaker Toyota invented this approach in the middle of the twentieth century
as a way to streamline its production of cars and eliminate wasted time and resources.
1. Eliminate Wastes: To maximize value, We must minimize Waste. For software systems, Waste can take the form of partially done work, delays,
hand-offs, unnecessary features etc.
2. Empower the team: Rather than taking a micromanagement approach, we should respect team members superior knowledge of the technical steps
required on the project and let them make local decisions to be productive and successful.
3. Deliver Fast: We can maximize the project Return on investment (ROI) by quickly delivering valuable software and iterating through designs. We
find the best solution through the Rapid Evolution of options
4. Optimize the Whole: We aim to see the system as more than the sum of its parts. We go beyond the pieces of the project and look for how it aligns with the
organization. As part of optimizing the whole, we also focus on forming better inter-group relations.
5. Build quality in: Lean development doesn’t try to “test-in” quality at the end; instead, we
build quality into the product and continually assure quality throughout the development
process, using techniques like refactoring, continuous integration and unit testing.
6. Defer Decisions: We balance early planning with making decisions and committing to
things as late as possible. For example, this may mean re-prioritizing the backlog right up
until it is time to plan an iteration, or avoiding being tide to an early technology-bounded
solution.
7. Amplify Learning: This concept involves facilitating communication early and often,
getting feedback as soon as possible, and building on what we learn. Software projects are
business and technology learning experiences, so we should start soon and keep learning .
Managing Iterative Processes Copyright © PROF. GUFRAN QURESHI
Booch supports the iterative and incremental development of a system. He defines two processes describing the layout of Object
Oriented development:
Macro process
1. Establish core requirements (conceptualization).
2. Develop a model of the desired behavior (analysis).
3. Create an architecture (design).
4. Evolve the implementation (evolution).
5. Manage post delivery evolution (maintenance).
Micro process
1. Identify the classes and objects at a given level of abstraction.
2. Identify the semantics of these classes and objects.
3. Identify the relationships among these classes and objects.
4. Specify the interface and then the implementation of these classes and objects.
 In principle, the micro process represent the daily activity of the individual developer,
or of a small team of developers. Here the analysis and design phases are intentionally
blurred.
 The macro process serves as the controlling framework of the micro process. It
represents the activities of the entire development team on the scale of weeks to months
at a time.
 The basic philosophy of the macro process is that of incremental development: the
system as a whole is built up step by step, each successive version consisting of the
previous ones plus a number of new functions.
Selecting the most Appropriate Process Model Copyright © PROF. GUFRAN QURESHI
 The software process model framework is specific to the project. Thus, it is essential to select the software process model according to
the software which is to be developed.
 The software project is considered efficient if the process model is selected according to the requirements. It is also essential to
consider time and cost while choosing a process model as cost and/or time constraints play an important role in software development.
 The basic characteristics required to select the process model are project type and associated risks, requirements of the project, and the
users.
 One of the key features of selecting a process model is to understand the project in terms of size, complexity, funds available, and so
on. In addition, the risks which are associated with the project should also be considered.
 It is possible to use two different approaches for the construction and installation of an application. However, this is not possible with
the evolutionary approach where both the construction and installation need to be evolutionary.
 The table below will give us a brief idea of which process model is to be used in the given conditions:
Factors Waterfall V-Shaped Evolutionary Prototyping Spiral Iterative and Incremental Agile
Unclear User Requirement Poor Poor Good Excellent Good Excellent
Unfamiliar Technology Poor Poor Excellent Excellent Good Poor
Complex System Good Good Excellent Excellent Good Poor
Reliable system Good Good Poor Excellent Good Good
Short Time Schedule Poor Poor Good Poor Excellent Excellent
Strong Project Management Excellent Excellent Excellent Excellent Excellent Excellent
Cost limitation Poor Poor Poor Poor Excellent Excellent
Visibility of Stakeholders Good Good Excellent Excellent Good Excellent
Skills limitation Good Good Poor Poor Good Poor
Documentation Excellent Excellent Good Good Excellent Poor
Component reusability Excellent Excellent Poor Poor Excellent Poor
Ch-5 Software Effort Estimation
Definition: In software development, effort estimation is the process of predicting the most realistic amount of effort
(expressed in terms of person-hours or money) required to develop or maintain software based on incomplete, uncertain and
noisy input.
 Estimation techniques are of utmost importance in software development life cycle, where the time required to complete a
particular task is estimated before a project begins.
 Estimation is the process of finding an estimate, or approximation, which is a value that can be used for some purpose even
if input data may be incomplete, uncertain, or unstable.
 Effective software project estimation is one of the most challenging and important activities in software development.
Proper project planning and control is not possible without a sound and reliable estimate. As a whole, the software industry
doesn’t estimate projects well and doesn’t use estimates appropriately. We suffer far more than we should as a result and we
need to focus some effort on improving the situation.
 Under-estimating a project leads to under-staffing it (resulting in staff burnout),
under-scoping the quality assurance effort (running the risk of low quality
deliverables), and setting too short a schedule (resulting in loss of credibility as
deadlines are missed).
 For those who figure on avoiding this situation by generously padding the
estimate, over-estimating a project can be just about as bad for the organization!
If you give a project more resources than it really needs without sufficient scope
controls it will use them. The project is then likely to cost more than it should (a
negative impact on the bottom line), take longer to deliver than necessary
(resulting in lost opportunities), and delay the use of your resources on the next
project.
Where are the Estimates Done? Copyright © PROF. GUFRAN QURESHI
 Before the estimation process begins the scope of the project needs to be understood. It is helpful to have historical data
in the form of project metrics at hand. Project metrics provide valuable input for the generation of quantitative estimates.
 Contrary to the belief that estimation is a one time task it is an ongoing process that is conducted at various stages of the
project. The primary stages at which estimating is done are as follows:
1. Strategic Planning: Strategic planning is the process of documenting and establishing a direction of your small
business—by assessing both where you are and where you're going. The strategic plan gives you a place to record your
mission, vision, and values, as well as your long-term goals and the action plans you'll use to reach them.
2. Feasibility Study: A feasibility study is an analysis that takes all of a project's relevant factors into account—including
economic, technical, legal, and scheduling considerations—to ascertain the likelihood of completing the project
successfully.
3. System Specification: The System Requirements Specification (SRS) (also known as a Software Requirement
Specification) document describes all data, functional and behavioral requirements of the software under production or
development.
4. Evaluation of Suppliers Proposals: The proposal evaluation techniques refer to the process of reviewing the proposals
given by the suppliers to support the contract award decisions of the buyer and the project team.
5. Project Planning: It is the process you go through to establish the steps required to define your project objectives,
clarify the scope of what needs to be done and develop the task list to do it..
Problems with Over and Under Estimates Copyright © PROF. GUFRAN QURESHI
 Given the number of variables and the volatile project environment no estimate is going to perfect even when the project
manager is provided with project metrics from historical projects. Thus, it is unlikely that the estimate will be right in the
first place.
 For any project task, it is unlikely that your estimate of how long it will take will be perfect. So, is it worse to overestimate
the time it will take to complete a task or underestimate it?
Cost of overestimation:
1. Overestimation creates the problem that the estimate become self-fulfilling. The task takes longer than it would have done
with a more accurate estimate in place.
2. There are two ideas behind this linked to how people behave. Firstly, Student’s Syndrome states that people often won’t
start working until very close to a deadline. Secondly, Parkinson’s Law states that work expands to fill the time available.
3. Therefore, if you have a task with overestimated length, the impact is the task might take longer than it ‘should’ do.
Costs of underestimation:
1. If a task is assumed to take long time than it actually needs, one of
two things will happen. Either the task gets done at lower quality, or
the task doesn’t get done on time and any tasks dependent on it are
pushed out.
2. Whilst obviously accurate estimates are the best outcome, over-
estimation is less bad than underestimation.
3. Underestimation can impact dependencies and the overall quality of
the project. Overestimation may be wasteful for the resources on a
particular task, but it is less likely to impact other tasks or overall
quality.
The Basis of Software Estimating Copyright © PROF. GUFRAN QURESHI
 The basis of estimates is an important tool in project management. It involves estimators and project managers to calculate the total
cost needed for the entire project. It is used to support proposals, bidding and executing a project.
 Effective software project estimation is an important activity in any software development project. One of the main reasons software
programs fail is our inability to accurately estimate software size.
 Because we almost always estimate size too low, we do not adequately fund or allow enough time for development. Poor size
estimates are usually at the heart of cost and schedule overruns.
 All estimates are made based upon some form of analogy: Historical Analogy, Expert Judgment, Models, and Rules-of-Thumb. The
role these methods play in generating an estimate depends upon where one is in the overall life-cycle.
Step 1: Gather and Analyze Software Functional & Programmatic Requirements: In this step we Analyze and refine software
requirements, software architecture, and programmatic constraints.
Step 2: Define the Work Elements and Procurements: The purpose of this step is to define the work elements and procurements for
the software project that will be included in the software estimate.
Step 3: Estimating the size of the project: Estimating the size of the software to be developed is the very first step to make an effective
estimation of the project. A customer's requirements and system specification forms a baseline for estimating the size of a software.
Step 4: Estimating the Effort: When we are finished with the size estimation process, the next step is to estimate the effort based on
the size. The estimation of effort can be made from the organisational specifics
of the software development life cycle.
Step 5: Estimating Schedule: After estimating the efforts, estimating the project
schedule from the effort estimated is the next step in the estimation process. The
schedule for a project will generally depend on human resources involved in a
process.
Step 6: Estimating the cost: To estimate the total cost of the software project is the
purpose of this step. The cost of a project is derived not only from the estimates of
effort and size but from other parameters such as hardware, travel expenses,
telecommunication costs, training cost etc. should also be taken into account.
Software Effort Estimation Techniques Copyright © PROF. GUFRAN QURESHI
Barry Bochm in his classic work on software effort models, identified the main ways of deriving estimates of software
development effort as:
1. Algorithmic models - which use 'effort drivers' representing characteristics of the target system and the implementation
environment to predict effort;
2. Expert judgement - where the advice of knowledgeable stall" is solicited;
3. Analogy - where a similar, completed, project is identified and its actual effort is used as a basis for the new project;
4. Parkinson - which identifies the staff effort available to do a project and uses that as the 'estimate';
5. Price to win - where the 'estimate' is a figure that appears to be sufficiently low to win a contract;
6. Top-down - where an overall estimate is formulated for the whole project and is then broken down into the effort required
for component tasks;
7. Bottom-up - where component tasks are identified and sized and these individual estimates are aggregated.
 Clearly, the 'Parkinson' method is not really an effort prediction method, but a
method of setting the scope of a project. Similarly, 'price to win' is a way of
deciding a price and not a prediction method.
 On these grounds. Boehm rejects them as prediction techniques although they
might have some value as management techniques. There is, for example, a
perfectly acceptable engineering practice of 'design to cost' which is one example
of the broader approach of 'design by objectives'.
Bottom-Up Estimate Copyright © PROF. GUFRAN QURESHI
 Bottom-up estimating is a project management technique in which the people who are going to do the work take part in the
estimating process.
 Typically those people are the employees, vendors and other project team members. They work with you, the project
manager, to develop estimates for tasks in the work breakdown structure (WBS).
 Setting the estimates of the amount of work, duration and cost at the task level lets you combine them into estimates of
higher-level deliverables and the project as a whole.
 Bottom-up estimating tends to develop a higher level of project team commitment than other types of estimates (like
parametric and analogous).
Advantages:
1. Increased Company-Wide Communication: When every employee actively participates in the decision-making process,
the overall communication among members of the organization will increase significantly.
2. Build Morale: All members of the business community will feel included and valued, which fosters a supportive and
communicative environment where employees can thrive and grow together.
3. Increased Collaboration: Employees of all levels are granted the opportunity
to discuss problems, bounce ideas off of one another, and build trust across
departments.
Disadvantages:
1. Bogging Down of Employees: Employees can be taken away from their own
tasks and pulled into larger projects, causing them to lose precious time.
2. Inaccurate Reflections of Data: A variety of people working on the same
projects simultaneously can cause skewed results and inaccurate decisions in the
long term.
The Top-down Approach and Parametric Models Copyright © PROF. GUFRAN QURESHI
 “Top-down” means that all the project objectives, guidelines, information, plans, and fund processes are established by
management, and expectations are communicated down to each project participant.
 A "top-down" approach is where an executive decision maker or other top person makes the decisions of how something
should be done.
 Companies utilize the top-down approach in order to assess, determine, and implement business decisions made by upper
executives.
 The processes are streamlined and communicated to lower rank employees, who carry out these tasks.
Advantages:
1. Decreased Risk: Since the highest level of management is also usually the most informed and most knowledgeable about
the business, there is a decreased risk involved in the decision-making process.
2. Strong Management: The upper authorities in a company will be able to determine best practices and reach goals easier
with decisions created and enforced at the highest ranks of a business.
3. Good Organization: Tasks are determined and filtered down company lines without any confusion because business
goals are set by upper management and will not be affected by outside opinions.
Disadvantages:
1. Limited Creativity: Employees are siloed (isolated) in their responsibilities
and are unable to contribute to the overall goals of the company —
sometimes leading to frustration and a lack of motivation to perform.
2. Slow Response to Challenges: When a challenge arises as a result of a
decision, it can take time for upper management to establish a solution
because there are limited minds contributing to decisions.
Algorithmic / Parametric Models Copyright © PROF. GUFRAN QURESHI
 A parametric model is a set of related mathematical equations that incorporates variable parameters. A scenario
is defined by selecting a value for each parameter.
 Software project managers use software parametric models and parametric estimation tools to estimate their projects'
duration, staffing and cost.
 This technique can produce higher levels of accuracy depending upon the sophistication and the underlying data built into
the model.
 In order for parametric models to have any validity they must be based on or proven using actual project data.
 The prime advantage of these models is that they are objective, repeatable, calibrated and easy to use, although calibration
to previous experience may be a disadvantage when applied to a significantly different project.
Expert Judgement
 Expert Judgment is a term that refers a specifically to a technique in which judgment is made based upon a specific set of
criteria and/or expertise that has been acquired in a specific knowledge area, or product area, a particular discipline, an
industry, etc.
 It is quite often recommended as one among the best tools and techniques in the project management processes.
 Experts are treated as assets in any organization and provide inputs to planning and estimating any activity as their
opinions are considered to be crucial.
 The experts can be stakeholders or customers. Expert Judgment is one of the best accepted approaches and most useful too
during the planning phases of many activities.
 The approach not only saves the time during the planning but also highlights risks to be considered while executing. It also
improves the quality of the estimates and provides accurate forecasts.
 Experts’ opinions are considered throughout the risk management processes to reduce the impact of the project risks.
 Expert judgment is inevitable during the project life cycle and sorted across all knowledge areas in effective project
management.
Estimating by Analogy Copyright © PROF. GUFRAN QURESHI
 Analogous estimating is a common technique in project management to determine cost, schedule or resource estimates.
 It is often used in situations where a rough estimate meets the needs of the stakeholders or at a time when not many details are
known about a project.
 Applying the technique involves the selection of similar projects, the processing of historical data and compilation of the
estimate(s).
 Analogous estimating is the act of using former projects to estimate how long or how much a current project will take or cost. In
other words, it is a technique that centers on comparison.
 These areas are covered in this 5-step guide to analogous estimating.
1. Identify Similar Projects: The first step is to identify projects or types of work that are similar to the current endeavor. Some
companies have databases where they store data on historical projects, including their scope, complexity, efforts and time needed
for their completion.
2. Gather Historical Data and Experience: Once you have found similar projects or experts, you will have to gather the relevant
data. A data set for analogous estimations typically consists of a combination of cost, time and resources-related information.
3. Compare Characteristics of Projects: Select the projects with characteristics that
are similar to your project. You can do this by applying expert judgment or – in case of a
larger number of previous projects – by developing a kind of scoring system.
4. Select the Type of Analogous Estimate: Decide whether your result should be a one-
point estimate, a ratio estimate, a range or a three-point estimate. In the latter case, you
might also consider using the triangular or PERT method to determine a final estimate.
5. Choose the Value(s) that Fit for Your Current Project: Once you have decided about
the type of value that you are going to estimate, you need to pick the right reference
project(s). For a range estimate, you will typically choose the lowest and highest value,
respectively, from projects similar to yours.
Albrecht / IFPUG Function Point Analysis Copyright © PROF. GUFRAN QURESHI
 Function point analysis is a standard method for measuring software development from the user's point of view. It provide a
standardized method for measuring the various functions of a software application.
 FP (Function Point) is the most widespread functional type metrics suitable for quantifying a software application. It is
based on five users identifiable logical "functions", which are divided into two data function types and three transactional
function types.
 For a given software application, each of these elements is quantified and weighted, counting its characteristic elements,
such as file references or logical fields.
Let us now understand how to apply the Albrecht’s Function Point method. Its procedure is as follows −
Determine the number of components (EI, EO, EQ, ILF, and ELF)
1. EI − The number of external inputs. These are elementary processes in which derived data passes across the boundary
from outside to inside. In an example library database system, enter an existing patron's library card number.
2. EO − The number of external output. These are elementary processes in which derived data passes across the boundary
from inside to outside. In an example library database system, display a list of books checked out to a patron.
3. EQ − The number of external queries. These are elementary processes with both input and output
components that result in data retrieval from one or more internal logical files and external interface files.
In an example library database system, determine what books are currently checked out to a patron.
4. ILF − The number of internal log files. These are user identifiable groups of logically related data
that resides entirely within the applications boundary that are maintained through external inputs.
In an example library database system, the file of books in the library.
5. ELF − The number of external log files. These are user identifiable groups
of logically related data that are used for reference purposes only, and
which reside entirely outside the system. In an example library database
system, the file that contains transactions in the library's billing system.
Calculation of Function Point (FP) Copyright © PROF. GUFRAN QURESHI
Step-1: F = 14 x scale
Scale varies from 0 to 5 according to character of Complexity Adjustment Factor (CAF).
0 = No Influence, 1 = Incidental, 2 = Moderate, 3 = Average, 4 = Significant, 5 = Essential.
Step-2: Calculate Complexity Adjustment Factor (CAF).
CAF = 0.65 + (0.01 x F)
Step-3: Calculate Unadjusted Function Point (UFP). Table (Required)
FUNCTION UNITS LOW AVG HIGH
EI 3 4 6
EO 4 5 7
EQ 3 4 6
ILF 7 10 15
EIF 5 7 10
Multiply each individual function point to corresponding values in TABLE.
Step-4: Calculate Function Point.

FP = UFP x CAF
Example:
Given the following values, compute function point when all complexity adjustment factor (CAF) and weighting factors are
average.
User Input = 50
User Output = 40
User Inquiries = 35
User Files = 6
External Interface = 4
Solution:
Step-1: As complexity adjustment factor is average (given in question), hence, scale = 3
F = 14 x 3 = 42
Step-2: Calculate Complexity Adjustment Factor (CAF).
CAF = 0.65 + (0.01 x 42) = 1.07
Step-3: As weighting factors are also average (given in question) hence we will multiply each individual function point to
corresponding values in TABLE.
UFP = (50x4) + (40x5) + (35x4) + (6x10) + (4x7) = 628
Step-4:
Function Point = 628 x 1.07 = 671.96
Example:
Given the following values, compute function point when all complexity adjustment factor (CAF) is Essential.
User Input = 30 (simple)
User Output = 25 (Average)
User Inquiries = 20 (Average)
User Files = 10 (Simple)
External Interface = 12 (High)
Solution: Function Point = 654.75
Example:
Given the following values, compute function point when all complexity adjustment factor (CAF) is Moderate.
User Input = 20 (High)
User Output = 45 (Low)
User Inquiries = 30 (Average)
User Files = 40 (Low)
External Interface = 9 (High)
Solution: Function Point = 734.7
Function Point Mark II Copyright © PROF. GUFRAN QURESHI
 Mark II is a size estimation technique of a software product. It belongs to the class of functional point group of
measurements.
 Traditionally, software size was measured in terms of the number of source code lines (SLOC or KLOC). The amount of
SLOC had a direct association with the relative size of software. Mark II is also known as Mark II Function Point Analysis.
 Functional size measurement technique is the only ISO standardised technique, that enables measuring the size of the Users
Functional Requirements.
 Functional requirements are of an independent nature , hence it can measured irrespective of any other non-functional or
technical requirements. It is therefore an efficient technique to measure the effective of a software product.
Mark II FPA (Functional Point Analysis) counting rules:

1. Define the boundary count -The logical line that separates a user from the system is called the boundary. It simply
determines the rules for user's entry and exit in the system.
2. Identify logical transactions -The number of logical transactions are counted.
3. Identify and Categorise Data Entity Types -Entities are the components that convey a meaningful information to the user.
4. Count the data: Count the input data element types, the data entity types
referenced and output data element types. It specifies the rules to enlist the total
number of input types its references and prepare a complete report of the same.
5. Count the functional size -Now when the objects in the system and the
transactions are identified, they can be considered for finding the functional size of
the system. The functional size of the system is counted as the number of input/exit
transactions between the user and the system.
COSMIC Full Function Points Copyright © PROF. GUFRAN QURESHI
 COSMIC function points are the unit of measure of software functional size. The process of measuring software size is
called functional size measurement (FSM).
 COSMIC functional size measurement is applicable to business, real-time and infrastructure software at any level of
decomposition.
 It is independent of the technology or processes used to develop the system. It is an ISO standard. It is a refined
improvement over its predecessors (IFPUG and Mark II FP).
 The COSMIC FFP measurement method defines an explicit model of software functionality, derived from the functional
user requirements.
 Four types of data movement-ENTRY, EXIT, READ, and WRITE-are defined within this model. They form the basis for
defining the standard unit of functional size.
1. Entry: An ENTRY (E) is a movement of the data attributes found in one data group from the user side of the software
boundary to the inside of the software boundary. An ENTRY (E) does not update the data it moves.
2. Exit: An EXIT (X) is a movement of the data attributes found in one data
group from inside the software boundary to the user side of the software
boundary.An EXIT (X) does not read the data it moves.
3. Read: A READ (R) refers to data attributes found in one data group.
Functionally, a READ sub-process brings data from storage, within reach
of the functional process to which it belongs.
4. Write: A WRITE (W) refers to data attributes found in one data group.
Functionally, a WRITE sub-process sends data lying inside the functional
process to which it belongs to storage.
COCOMO II: A Parametric Productivity Model Copyright © PROF. GUFRAN QURESHI
 COCOMO-II is the revised version of the original Cocomo (COnstructive COst MOdel) and is developed at University of
Southern California by Barry Boehm. It is the model that allows one to estimate the cost, effort and schedule when planning
a new software development activity.
 COCOMO-II is an alternative to include components of uncertainty according to level of information available.
 It is a parametric model that establishes mathematical equations that describe the relationships between software size -
primary cost factor usually represented in terms of function points - and other secondary factors that look to identify features
of a product, process, people and platform. These factors are known as cost drivers.
 The model provides a complete framework to determine local productivity factors based on time & effort data in past projects.
 It consists of three sub-models:
1. End User Programming: Application generators are used in this sub-model. End user write the code by using these
application generators. Example – Spreadsheets, report generator, etc.
2. Intermediate Sector:
(a). Application Generators and Composition Aids – This category will create
largely prepackaged capabilities for user programming. Their product will have
many reusable components. Typical firms operating in this sector are Microsoft,
Lotus, Oracle, IBM, Borland, Novell.
(b). Application Composition Sector – This category is too diversified and to be
handled by prepackaged solutions. It includes GUI, Databases, domain specific
components such as financial, medical or industrial process control packages.
(c). System Integration – This category deals with large scale and highly
embedded systems.
3. Infrastructure Sector: This category provides infrastructure for the software development like Operating System,
Database Management System, User Interface Management System, Networking System, etc.
Cost Estimation Copyright © PROF. GUFRAN QURESHI
 Cost estimation in project management is the process of forecasting the financial and other resources needed to complete a
project within a defined scope.
 Cost estimation accounts for each element required for the project—from materials to labor—and calculates a total amount
that determines a project’s budget.
Elements of cost estimation in project management:
There are two key types of costs addressed by the cost estimation
process:
1. Direct costs: These are the costs associated with a single area,
such as a department or this particular project itself. Examples
of direct costs include fixed labor, materials and equipment.
2. Indirect costs: These are costs incurred by the organization at
large, such as utilities and quality control.
 In a classical view of software estimation process, the software requirements are the primary input to the process and also
form the basis for the cost estimation.
 Cost driver is anything that may or will affect the cost of the software. Cost driver are things such as design methodology,
skill-levels, risk assessment, personnel experience, programming language or system complexity.
 In a classical view of the estimation process, it will generate three outputs - efforts, duration and loading. The following is
a brief description of the outputs:
a. Manpower loading - number of personnel (which also includes management personnel) that are allocated to the project
as a function of time.
b. Project duration - time that is needed to complete the project.
c. Effort - amount of effort required to complete the project and is usually measured in units as man-months (MM) or
person-months (PM).
Staffing Pattern Copyright © PROF. GUFRAN QURESHI
 Once the effort required to develop a software has been determined, it

is necessary to determine the staffing requirement for the project.
 Putnam first studied the problem of what should be a proper staffing
pattern for software projects.
 He extended the work of Norden who had earlier investigated the
staffing pattern of research and development (R&D) type of projects.
In order to appreciate the staffing pattern of software projects,
Norden’s and Putnam’s results must be understood.
Norden’s Work
 Norden studied the staffing patterns of several R & D projects. He found that
the staffing pattern can be approximated by the Rayleigh distribution curve (as
shown in fig). It specifies the relationship between applied effort and delivery
time for a software project.
 Norden represented the Rayleigh curve by the following equation:
E = K/t² x t x e-t² / 2 t²d
d
Where E is the effort required at time t. E is an indication of the number of
engineers (or the staffing level) at any particular time during the duration of the
project, K is the area under the curve, and td is the time at which the curve attains
its maximum value.
It must be remembered that the results of Norden are applicable to general R & D
projects and were not meant to model the staffing pattern of software development
projects. It is also called Putnam-Norden-Rayleigh curve or PNR curve.
Putnam’s Work
 Putnam studied the problem of staffing of software projects and found that the software development has characteristics
very similar to other R & D projects studied by Norden.
 He too observed that the Rayleigh-Norden curve can be used to relate the number of delivered lines of code to the effort
and the time required to develop the project.
 By analyzing a large number of army projects, Putnam derived the following expression:
L = Ck K1/3 td 4/3
The various terms of this expression are as follows:
• K is the total effort expended (in PM) in the product development and L is
the product size in KLOC.
• td corresponds to the time of system and integration testing. Therefore, td can
be approximately considered as the time required to develop the software.
• Ck is the state of technology constant and reflects constraints that impede the
progress of the programmer. Typical values of Ck = 2 for poor development
environment (no methodology, poor documentation, and review, etc.), Ck = 8
for good software development environment (software engineering principles
are adhered to), Ck = 11 for an excellent.
 The exact value of Ck for a specific project can be computed from the historical data of the organization developing it.
 Putnam suggested that optimal staff build-up on a project should follow the Rayleigh curve. Only a small number of
engineers are needed at the beginning of a project to carry out planning and specification tasks. As the project progresses
and more detailed work is required, the number of engineers reaches a peak. After implementation and unit testing, the
number of project staff falls.
Effect of Schedule Compression Copyright © PROF. GUFRAN QURESHI
Schedule compression is a technique used in project management to shorten an already developed schedule. This might be done
to meet an update delivery date, a new opportunity or schedule delay. It’s done without changing the scope of the
program. There are two techniques that are commonly used in schedule compression. These are:
1. Crashing
2. Fast Tracking
Crashing
 Crashing assigns more resources to an activity to decrease the overall
time to complete it.
 The cost benefits of this activity have to be explored in order to make
it a useful technique.
 The trade-off between cost and schedule must be understood to get the
best possible schedule compression.
Fast Tracking
 Fast Tracking is the process of executing activities or phases that were
originally schedule sequential in parallel.
 Activities can be overlapped, started earlier than proposed, start
activities that require different resources, and maybe combined
activities in the schedule.
 This process does add risk to the schedule and program and must be
executed with care.
Capers Jones Estimating Rules of Thumb Copyright © PROF. GUFRAN QURESHI
Capers Jones in the year 1996 formulated simple rules based on his experience in estimating various parameters of large
software projects.
The objective behind formulating these rules was to provide the project manager with estimating rules which would be easy to
use and yet provide him with a fairly good idea of the various aspects of the project.
Rules Formulated by Capers Jones
 Rule 1: SLOC Function Point Equivalence - SLOC technique helps in developing better understanding of the size of the
project and also estimating several other project parameters. However, when it comes to estimating the size of the project
the function point analysis is used on account of its advantages. Thus, it becomes necessary for the project manager to
determine SLOC measure from its function point measurement.
 Rule 2: Project Duration Estimation - Function points raised to the power 0.4 predicts the approximate development time
in calendar months. E.g. If the size of a project is estimated by 325 function points i.e. approximately 40,000 SLOC then the
completion time for the project would be approximately 10 months.
 Rule 3: Rate of Requirement Creep - Requirement creep is the increase in the requirements of the user and these keep on
increasing for a variety of reasons as the project progresses. User requirements creep in at an average rate of 2% per month
from the design through coding phases.
 Rule 4: Defect Removal Efficiency - Each software review, inspection or test step will find
and remove 30% of the bugs that are present. Defect removal steps at various stages of the
project development ensure that the final product is reliable.
 Rule 5: Project Manpower Estimation - The size of the software in function points divided
by 150 predicts the approximate number of personnel required for developing the application.
 Rule 6: Software Development Effort Estimate - The approximate number of staff months
required to develop software is given by the software development time multiplied by the
number of personnel required.

SPM Unit I &amp; II

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SPM Unit I &amp; II

Uploaded by

Copyright:

Available Formats

Software Project Management

Copyright © PROF. GUFRAN QURESHI

Mumbai University Course Code: USIT501

It is an essential part of the software organization to deliver a quality product,

Copyright © PROF. GUFRAN QURESHI

Copyright © PROF. GUFRAN QURESHI

Copyright © PROF. GUFRAN QURESHI

Copyright © PROF. GUFRAN QURESHI

II] Distributed Computing Projects:

Copyright © PROF. GUFRAN QURESHI

Steps for Developing the Business Case:

The Worst Projects:

Triple Constraints of Project Management

Management Control: Management control describes the means by which

Successful work is measured by the delivered Success is evaluated by conformity to the

Traditional SDLC models require intensive

Has many iteration cycles – as many as needed for

Why have a business case?

Copyright © PROF. GUFRAN QURESHI

Copyright © PROF. GUFRAN QURESHI

Copyright © PROF. GUFRAN QURESHI

Three categories of benefits:

Copyright © PROF. GUFRAN QURESHI

Year Project A Project B

ROI (%) = Avg. Net Profit X 100

Copyright © PROF. GUFRAN QURESHI

Year Project A Project B

NPV = Present Value CIF – Present Value COF

Copyright © PROF. GUFRAN QURESHI

Copyright © PROF. GUFRAN QURESHI

Basic concepts in Risk Management:

Cost-Benefit Analysis and Risk Analysis

Copyright © PROF. GUFRAN QURESHI

II] Vision, Mission and Objectives:

Copyright © PROF. GUFRAN QURESHI

Some Reservations about Programme Management

Project planning is of significant importance for the success of the project.

Project Infrastructure refers to the organisational structure, processes, tools,

Copyright © PROF. GUFRAN QURESHI

The Project Charter Covers

Developing the WBS

Step 8 : Review / Publicize Plan –

Step 9 & 10 : Execute Plans and Lower Levels of Planning –

Copyright © PROF. GUFRAN QURESHI

Step 1 : Validate the business need

Choosing Methodologies and Technologies

Software Processes and Process Models

Structure v/s Speed of Delivery

Step-4: Calculate Function Point.

Mark II FPA (Functional Point Analysis) counting rules:

 Once the effort required to develop a software has been determined, it

You might also like

SPM Unit I & II

SPM Unit I & II