Text book: Software Project Management by Bob Hughes and Mike Cotterell, 4 th ed. Unit – 1: Introduction to Software Project Management (SPM) LECTURE 1 1.1 Definition of Software Project Management (SPM) Software Project Management (SPM) is an activity of organizing, planning and scheduling of Software Projects. 1.2 Software Projects versus other types of project The following characteristics of software project which make them different from other projects: Invisibility Complexity Conformity Flexibility 1.3 Activities covered by software project management (SPM) The following activities are: The feasibility study Planning Project execution
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Text book: Software Project Management by Bob Hughes and Mike Cotterell, 4th ed.
Unit – 1: Introduction to Software Project Management (SPM)
LECTURE 1
1.1 Definition of Software Project Management (SPM)
Software Project Management (SPM) is an activity of organizing, planning and
scheduling of Software Projects.
1.2 Software Projects versus other types of project
The following characteristics of software project which make them different from other
projects:
Invisibility
Complexity
Conformity
Flexibility
1.3 Activities covered by software project management (SPM)
The following activities are:
The feasibility study
Planning
Project execution
The feasibility/Plan/execution cycle as shown in the figure:
Fig: Feasibility/Plan/execution cycle
1. The feasibility study
We study that whether the project have worth or not, it mean that it has a
valid business case.
2. Planning
First, we formulate the outline plan for the whole project then later we will
go for the detail and accurate plan.
3. Project execution
The execution of a project contains the design and implementation sub-
phases.
LECTURE 2
1.4 Categorizing Software Projects
The software projects can be broadly divided into two categories:
Information systems versus embedded systems
The difference is that in the former case, the system interface with the organization eq.
stock control system, whereas in the later case, the systems interface with a machine eq.
the air conditioning equipment in a building.
Objective versus products
Feasibility study
Plan
Project execution
How we do it?
Do it?
Is it worth doing?
A project might be to create a project, the details of which have been specified by the
client. On the other hand, the project may be required to meet certain objectives.
1.5 Requirement specification
The following are:
Functional requirements
These define what the end-product of the project is to do.
Quality requirements
There will be other attributes of the attributes of the application to be implemented that
do not relate so much to what the system is to do but how to do it, eq. response time.
Resource requirements
A record of how much the organization is willing to spend on the system.
These are also called non-functional requirements.
LECTURE 3
1.6 What is Management?
The management involves the following activities:
Planning
Organizing
Staffing
Directing
Monitoring
Controlling
Innovating
Representing
1.7 Management control
It involves setting the objectives for a system and then monitoring the system.
The figures explain the whole system:
This will involves the local manages in data collection. Data processing will be needed
to transform this raw data into useful information. The making decisions/plans will be
useful to take decision whether it will be complete on time or not. It also considers other
aspects. The project manager can move staff from particular branches. This is modeling
the consequences of a potentials solution. Several different proposals could be modeled
in this way before one was chosen for implementation.
It can be seen that a project plan is dynamic and will need constant adjustment during the
execution of a project.
Fig: The project control cycle
The real
world
Data collection
Data processing
Making decisions /
plans
Implementation
Define objective
Modeling
Actions
Data
Information
Decisions
LECTURE 4
Requirement specification
The following are:
Functional requirements
These define what the end-product of the project is to do.
Quality requirements
There will be other attributes of the attributes of the application to be implemented that
do not relate so much to what the system is to do but how to do it, eq. response time.
Resource requirements
A record of how much the organization is willing to spend on the system.
These are also called non-functional requirements.
Categorizing Software Projects
The software projects can be broadly divided into two categories:
Information systems versus embedded systems
The difference is that in the former case, the system interface with the organization eq.
stock control system, whereas in the later case, the systems interface with a machine eq.
the air conditioning equipment in a building.
Objective versus products
A project might be to create a project, the details of which have been specified by the
client. On the other hand, the project may be required to meet certain objectives.
Text book: Software Project Management by Bob Hughes and Mike Cotterell, 4th ed.
Unit -2 Stepwise Project planning
LECTURE 5
2.1 Introduction
A major principle of project planning is to plan in outline first and then in more
detail as the time to carry out an activity approaches.
An outline of stepwise planning activities is:
Select project
Identify project scope and objectives
Identify project infrastructure
Analyze project characteristics
Identifies project product and activities
Estimate effort for each activity
Identify activity risks
Allocate resources
Review/publicize plan
Execute plan/lower levels of planning
2.2 Selecting a project
The project must be worthwhile such that it should have priority over other projects. This
evaluate of the merits of projects could be part of strategic planning.
2.3 Identify project scope and objectives
The following activities are:
Identify objectives and practical measures of the effectiveness in meeting those
objectives.
Establish a project authority
Stakeholder analysis – identify all stakeholders in the project and their interests
Modify objectives in the light of stakeholder’s analysis
Establish methods of communication with all parties
LECTURE 5
2.4 Identify project infrastructure
The following activities are:
Identify relationship between the project and strategic planning
Identify installation standards and procedures
Identify project team organization
2.5 Analysis project characteristics
The following activities are:
Distinguish the project as either objective- or product-driven
Analysis other project characteristics (including quality-based ones)
Identify high-level risks
Take into accounts user requirements concerning implementation
Select development methodology and life-cycle approach
Review overall resource estimates
LECTURE 6
2.6 Identify project products and activities
The following activities are:
Identify and describe project products (or deliverables)
The products will form the hierarchy. The main product will have sets of
component products which in turn may have sub-component products and
so on. This relationship can be documented in a Product Breakdown
Structure (PBS). It is shown as in the figure.
Fig. A framework of a product breakdown structure for a system development task
Document generic product flows
Some products will need one or more other products to exist first before
they can be created. For example, a program design must be created before
the program can be written and the program specification must exist
before the design can be concerned. These relationships can be shown by
the Product Flow Diagram (PFD). It is shown as in figure.
Project products
System products
Module products
Management products
Module design
documents
Module code
Progress report
Overall specification
Integration case
Tested integration software
Fig. A framework of a PFD for a software development task
Recognize product instances
There may be delayed to later in the product when more information is
known.
Produce ideal activity network
It is explained by an example of activities network.
User requirements
Overall system specification
Integration system test cases
Module design
Module code
Integrated/tested software
Fig. An example of an activity network
Modify the ideal to take into account need for stages and checkpoints
There might be a need to modify this by dividing the project into stages
and introduces checkpoint activities. These are activities which draw
together the products activities to check that they are compatible.
There could be some key attributes, or milestones, which represent the
completion of important stages of the project of which they would want to
take particular note.
2.7 Estimate effort for each activity
The following activities are:
Carry out bottom-up estimates
At this point, estimates of the staff effort required, the probable elapsed
time and the non-staff resources needed for each activity will need to be
produced.
Effort is the amount of work that needs to be done.
Elapsed time is the time between the start and end of a task.
Revise plan to create controllable activities
Design integration teat cases
Specify overall system
Code module A
Design module B
Code module B
Design module A
Test integrated software
Try to make activities about the length of the reporting period used for
monitoring and controlling the project.
LECTURE 7
2.8 Identify activity risks
The following activities are:
Identify and quantify activity-based risks
A project plan will be based on a huge number of assumptions. So,
identifications of risks are very important factor. If it will not take very
seriously, the project may be delayed and costly.
Plan risk reduction and contingency measures where appropriate
We can avoid or at least reduce some of the identified risks. On the other
hand, contingency plans specify action that is to be taken if a risk
materializes.
Adjust overall plans and estimates to take account of risks
We may change our plans, by adding new activities which reduce risks
2.9 Allocate resources
Identify and allocate resources
The staff available for the project are identified and are allocated to tasks
Revise plans and estimates to take into account resource constraints
Some staff may be needed for more than one task at the same time and an
order of priority is established.
2.10 Review/publicize plan
Review quality aspects of the project plan
Each task should have quality criteria. These are quality checks that have
to be passed before the activity can be ‘signed off’ as completed.
Document plans and obtain agreement
The plans should be carefully documented and all the parties must agree to
the commitment required for the plan.
Text book: Software Project Management by Bob Hughes and Mike Cotterell, 4th ed.
Unit-3 Project Evaluation and Estimation
LECTURE 8
Cost-benefit analysis
It mainly comprise two steps
Identify and estimating all of the costs and benefits of carrying out the
project and operating the delivered application.
Expressing these costs and benefits in common units
We need to evaluate the net benefit, that is, the difference between the
total benefit and the total benefit and the total cost of creating and
operating the system.
We can categorize cost according to where they originate in the life of the
project. These are:
Development costs
Setup costs
Operational costs
Cash flow forecasting
A cash flow forecast will indicate when expenditure and income will take place. It is as
shown in the figure:
Fig: Typical product life cycle cash flow
LECTURE 9
Cost-benefit evaluation techniques
The following cost-benefit evaluation techniques are:
Net profit
The net profit of a project is the difference between total costs and the total
income over the life of the project.
Payback period
The payback period is the time taken to break even or pay back the initial
investment.
Return on investment
The return on investment (ROI), also known as the accounting rate of return
(ARR), provides a way of comparing the net profitability to the investment
required.
Average annual profit
ROI = --------------------------- * 100
Total income
Net present value
The calculation of net present value is a project evaluation technique that takes
into account the profitability of a project and the timing of the cash flows that are
produced.
The present value of any future cash flow may be obtained by applying the
following formula
Value in year t
Present value = -----------------------
(1+r) t
Where r is the discount rate and t is the number of years into the future that the
cash flow occurs.
Internal rate of return
The internal rate of return (IRR) attempts to provide a profitability measures as a
percentage return that is directly comparable with interest rates.
Risk evaluation
The following things are:
Risk identification and ranking
In any project evaluation we should attempt to identify the risks and quantify their
potential effects. One common approach to risk analysis is to construct a project
risk matrix utilizing a checklist of possible risks and to classify each risk
according to its relative importance and likelihood.
Risk and net present value
Where a project is relatively risky it is common practice to use a higher discount
rate to calculate net present value.
Cost-benefit analysis
A more sophisticated approach to the evaluation of risk is to consider each
possible outcome and estimate the probability of its occurring and the
corresponding value of the outcome. The value of the project is then obtained by
summing the cost or benefit for each category.
Risk profile analysis
By study the results of a sensitivity analysis we can identify those factors that are
most important to the success of the project. There are a number of risk analysis
applications available and produce the risk profiles of the type.
Using decision trees
The analysis of a decision tree consists of evaluating the expected benefit of
taking each path from a decision point (It is denoted by D). The expected value of
each path is the sum of the value of each possible outcome multiplied by its
probability of occurrence. This is shown as in the figure:
Fig. A Decision Tree
LECTURE 10
Selection of a an appropriate project approach
The selection of a particular process model could add new products to the Project
Breakdown Structure (PBS) or new activities to the activity network. This will generate
inputs for identify the products and activities of the project.
Choosing technologies
An outcome of project analysis will be the selection of the most appropriate
methodologies and technologies. Methodologies include approaches like Unified
Software Development Process (USDP), Structure System Analysis and Design Method
(SSADM), and Human-Centered Design, while technologies include appropriate
application-building and automated testing environments.
The some of the steps of the project analysis are:
Identify project as either objectives-driven or product-driven
D
Extend
Replace
Expansion
No expansion
Expansion
No expansion
0.2
0.8
0.2
0.8
In objective-driven project, we define the general software solution that is to be
implemented, while in product-driven project, the product to be created is defined
before the start of the product.
Analysis other project characteristics
The following point will arise:
Is a data-oriented or process-oriented system to be implemented?
Will the software that is too produced be a general tool or application
specific?
Are there specific tools available for implementing the particular type of
application?
Is the system to be created safety critical?
What is the nature of the hardware/software environment in which the
system will operate?
Identify high-level project risks
The following uncertainty will occur:
Product uncertainty
Process uncertainty
Resource uncertainty
Take into account user requirement concerning implementation
Select general life-cycle approach
Some approaches are:
Control systems
Information systems
General tools
Specialized techniques
Hardware environment
Safety-critical systems
Choice of process models
The word ‘process’ is used to emphasize the idea of a system in action. In order to
achieve an outcome, the system will have to execute one or more activities. A major part
of the planning will be choosing development methods and slotting them into an overall
process model.
Structure methods
The principle behind structure method is ‘get it right first time’. The structure methods
are made up of sets of steps and rules which generate system products such as use case
diagrams. Some of them are rapid application development (RAD), waterfall model etc.
LECTURE 11
The RAD Model
Rapid application development (RAD) is an incremental software development process
model that emphasizes an extremely short development cycle. The RAD model is a”
high-speed” adaptation of the linear sequential model in which rapid development is
achieved by using component-based construction. The RAD approach encompasses the
following phases:
Business modeling
Data modeling
Fig: The Process
Process modeling
Application generation
Testing and turnover
Like all process models, the RAD approach has drawbacks:
For large but scalable projects, RAD requires sufficient human resources to create
the right number of RAD teams.
RAD requires developers and customers who are committed to the rapid-fire
activities necessary to get a system complete in a much abbreviated time frame. If
commitment is lacking from either constituency, RAD projects will fail.
Not all types of applications are appropriate for RAD. If a system cannot be
properly modularized, building the components necessary for RAD will be
problematic. If high performance is an issue and performance is to be achieved
through tuning the interfaces to system components, the RAD approach may not
work.
RAD is not appropriate when technical risks are high. This occurs when a new
application makes heavy use of new technology or when the new software
requires a high degree of interoperability with existing computer programs.
LECTURE 12
The Spiral Model
The spiral model, originally proposed by Boehm, is an evolutionary software process
model that couples the iterative nature of prototyping with the controlled and systematic
aspects of the linear sequential model.
A spiral model is divided into a number of framework activities, also called task regions.
Typically, there are between three and six task regions. Figure 2.8 depicts a spiral model