Software Project Management and

Information Systems
Unit -1 : Overview of Software Project Planning: Software Project, Categorization of
software Project, Introduction to Stepwise Project Planning, Project Scope,
Infrastructure, Resource Allocation, Project Plan Execution.
Estimation: Software Project Estimation, Decomposition Techniques- Software Sizing,
Problem Based estimation, LOC based estimation, Function Point based estimation,
Process Based estimation, Cost Benefit analysis, Cost Estimation Models, Selection of
Technologies.

Unit-2 : Project Scheduling: Basic Concepts, Project Scheduling- Basic Principles,

Relationship between People and Effort, Task Network, Scheduling, Gantt and PERT
charts, Staffing, Project monitoring and control.
Software configuration management: Concepts and definitions, Need and importance
of SCM, Benefits of SCM, The SCM Process, Plan preparation with case study,
Infrastructure setup, Team Training, System Operation, System Maintenance, System
Retirement. Configuration Baselines, Interface Control, Metrics change control –
Submitting Change Request, Request Analysis, Request Disapproval and Request
Approval Configuration Control Tool.

Unit-3 Information and information systems: Concept of Information system,

Components of information system,Transaction Processing System (TPS) - Office
Automation System (OAS), Management Information System (MIS) - Decision Support
System (DSS) and Group Decision Support System (GDSS)-Expert System(ES)
Unit 4 : Concepts of Planning & Control: Concept
of organizational planning, The Planning Process,
Computational support for planning, Characteristics
of control process, The nature of control in an
organization. Information System Planning:
Information System Development, Analysis, Design,
Testing, Evaluation & Implementation.

Unit 5 : Manufacturing and Service Systems,

Information systems for Accounting, Finance,
Production and Manufacturing, Marketing and
HRM functions - IS in hospital, hotel,
bank ,Enterprise Resources Planning (ERP):
Features, selection criteria, merits, issues and
Software Project
A Software Project is the complete procedure of
software development from requirement gathering to
testing and maintenance, carried out according to the
execution methodologies, in a specified period of time
to achieve intended software product.
 Characteristics of a Project
Non-routine tasks are involved
Planning is required
Specific objectives are to be met or specified product
is to be created
Pre-determined time span
Work is carried out for someone other than yourself
Work involves several specialisms
Work is carried out in several phases
Resources that are available are constrained
Project is large or complex
 Categorizing Software Projects
Information Systems vs. Embedded Systems
Objectives vs. Product
Information System versus Embedded
Systems:
  Information Systems helps in office day to day processes
and embedded system are used to control machines.
 An embedded system or an industrial system can be a
process control system such as maintaining air conditioning
equipment in a company.
 Examples of Information system are A stock control
system, transaction processing system, knowledge
management system, learning management system,
database system etc.
 While Embedded systems control Microwave oven, AC,
Mp3 Player, Digital Camera, Washing Machine etc.
Projects may be distinguished by whether their aim is to
produce a product or to meet certain objectives.

A project might be to create a product the details of which

have been specified by the client. The client has the
responsibility for justifying the product.

On the other hand, the project might be required to meet

certain objectives.

One example of this is where a new information system is

implemented to improve some service to users inside or
outside an organization.

The subject of an agreement would be the level of service

rather than the characteristics of a particular information
system.
Stepwise Project planning
Step 0: Select Project

Step 1: Identify project scope and objectives

Step 1.1 : Identify objectives and practical measures of the effectiveness in meeting those
objectives
Step 1.2 : Establish  a project authority
Step 1.3 : Stakeholder analysis - identify all stakeholders in the project and their interests.
Step 1.4 : Modify objectives in the light of stakeholder analysis.
Step 1.5 : Establish methods of communication with all parties.

Step 2 : Identify project infrastructure

Step 2.2 : Identify installation standard and procedures
Step 2.3 : Identify project team organization

Step 3 : Analyse project characteristics

Step 3.1 : Distinguish the project as either objectives- or product-driven.
Step 3.2 : Analyse other project characteristics
Step 3.3 : Identify high-level project risks
Step 3.4 : Take into account use requirements concerning implementation
Step 3.5 : Select development methodology and life-cycle approach
Step 3.6 : Review overall resource estimates
Step 4 : Identify project products and activities
Step 4.1 : Identify and describe project products
Step 4.2 : Document generic product flows
Step 4.3 : Recognize product instances
Step 4.4 : Produce ideal activity network
Step 4.5 : Modify the ideal to take into account need for stages and checkpoints

Step 5 : Estimate effort for each activity

Step 5.1 : Carry out bottom-up estimates
              - distinguish carefully between effort and elapsed time
Step 5.2 : Revise plan to create Controllable activities 
              - breakup very long activities into a series of smaller ones
              - bundle up very short activities

Step 6 : Identify activity risks

Step 6.1 : Identify and quantify activity based risks 
              - damage if risk occurs
              - likelihood if risk occuring
Step 6.2 : Plan risk reduction and contingency measures
              - risk reduction : activity to stop risk occuring
              - contingency : action if risk does occurs
Step 6.3 : Adjust overall plans and estimates to take account of risks
Step 7 : Allocate resources
Step 7.1 : Identify and allocate resources
Step 7.2 : Revise plans and estimates to take into account resource constraints

Step 8 : Review/ Publicize plans

Step 8.1 : Review quality aspects of the project plan
Step 8.2 : Document plans and obtain agreement

Step 9 and 10 : Execute plan. Lower levels of planning

Project Scope

Project scope is the part of project planning that

involves determining and documenting a list of
specific project goals, deliverables, tasks, costs and
deadlines.

The documentation of a project's scope is called

a scope statement or terms of reference.

It explains the boundaries of the project, establishes

responsibilities for each team member and sets up
procedures for how completed work will be verified
and approved.
 Resource allocation
A resource is a necessary asset whose main role is to
help carry out a certain task or project. A resource can
be a person, a team, a tool, finances, and time. Most
projects require many different resources to be
completed.

Resources should be assessed and allocated before a

project begins. Poor resource planning can result in
running out of resources midway through a project or
delaying deadlines in delivering the final product or
service.
PSE | Section-D /529
 Project Plan Execution

PSE | Section-D /529

 Estimations
Estimation: Software Project Estimation, Decomposition Techniques- Software
Sizing, Problem Based estimation, LOC based estimation, Function Point based
estimation, Process Based estimation, Cost Benefit analysis, Cost Estimation Models,
Selection of Technologies.
 Lines of Code (LOC)

LOC is the simplest among all metrics available to estimate project size. This metric
is very popular because it is the simplest to use.

Using this metric, the project size is estimated by counting the number of source
instructions in the developed program.
Size Estimation
Function Point Analysis
Function point metric was proposed by Alan Albrecht
while working for IBM, recognized the problem in size
measurent in the 1970s . This metric overcomes many of
the shortcomings of the LOC metric

One of the important advantages of using the function

point metric is that it can be used to easily estimate the
size of a software product directly from the problem
specification.

The conceptual idea behind the function point metric is

that the size of a software product is directly dependent on
the number of different functions or features it supports.
14 factors for calculating Complexity adjustment factor with scale 0 to 5
The COCOMO model is a single variable software cost estimation
model developed by Barry Boehm in 1981.
software development project can be classified into one of the following
three categories based on the development complexity
Organic: A development project can be considered of organic type, if the
project deals with developing a well understood application program, the
size of the development team is reasonably small, and the team members
are experienced in developing similar types of projects.
 Semidetached: A development project can be considered of
semidetached type, if the development consists of a mixture of
experienced and inexperienced staff. Team members may have limited
experience on related systems but may be unfamiliar with some aspects
of the system being developed.
 Embedded: A development project is considered to be of embedded
type, if the software being developed is strongly coupled to complex
hardware, or if the stringent regulations on the operational procedures
exist.
COCOMO
The basic model aims at estimating, in a quick and rough fashion, most of the small to
medium sized software products. Three modes of software development are considered
in this model: organic, semidetached and embedded.

In the organic mode, a small team of experienced developers develops software in a very
familiar environment. The size of the software development in this mode ranges from
small (a few KLOC) to medium (a few tens of KLOC), while in other two modes the
size ranges from small to very large (a few hundreds of KLOC).
 Basic COCOMO

The basic model aims at estimating, in a quick and rough fashion, most of the
small to medium sized software products.

Three modes of software development are considered in this model: organic,

semidetached and embedded.

In the organic mode, a small team of experienced developers develops software

in a very familiar environment. The size of the software development in this
mode ranges from small (a few KLOC) to medium (a few tens of KLOC), while
in other two modes the size ranges from small to very large (a few hundreds of
KLOC).
Assume that the size of an organic type
software product has been estimated to be
32,000 lines of source code.

Assume that the average salary of software

engineers be Rs. 15,000/- per month.

Determine the effort required to develop the

software product and the nominal
development time.
Solution

From the basic COCOMO estimation formula for organic software:

Effort = 2.4 х (32)1.05 = 91 PM

Nominal development time = 2.5 х (91)0.38 = 14 months

Cost required to develop the product = 14 х 15,000 = Rs. 210,000/-

 Intermediate COCOMO

•Computes software development effort as a function of

program size and set of 15 Cost Drivers

•Cost Driver: A multiplicative factor that determines the

effort required to complete the software project.

Very Very Extra

Low Nominal High
Low High High
Cost Drivers

Product • Required Software Reliability (RELY)

• Database Size (DATA)
Attributes • Product Complexity (CPLX)

• Execution Time Constraint (TIME)

Computer • Main Storage constraint (STOR)

Attributes •
•
Virtual Machine volatility (VIRT)
Computer turnaround time (TURN)

• Analyst Capability (ACAP)

Personnel •
•
Application Experience (AEXP)
Programmer Capability (PCAP)
Attributes •
•
Virtual Machine Experience (VEXP)
Programming language Experience (LEXP)

Project • Modern programming practices (MODP)

• Use of Software tools (TOOL)
Attributes • Required development schedule (SCED)
• Multiply all 15 Cost Drivers to get Effort Adjustment
Factor(EAF)

• E(Effort) = ab(KLOC)bb * EAF(in Person-Month)

• D(Development Time) = cb(E)db (in month)

• SS (Avg Staff Size) = E/D (in persons)

• P (Productivity) = KLOC/E (in KLOC/Person-month)

Project ab bb cb db
Organic 3.2 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32
 Effort multipliers for different cost drivers.
RATING
Cost Drivers Very Low Normal High Very
Low High
Product Attributes
RELY, required reliability .75 .88 1.00 1.15 1.40
DATA, database size .94 1.00 1.08 1.16
CPLX, product complexity .70 .85 1.00 1.15 1.30
Computer Attributes
TIME, execution time constraint 1.00 1.11 1.30
STOR, main storage constraint 1.00 1.06 1.21
VITR, virtual machine volatility .87 1.00 1.15 1.30
TURN, computer turnaround time .87 1.00 1.07 1.15
Personnel Attributes
ACAP, analyst capability 1.46 1.19 1.00 .86 .71
AEXP, application experience 1.29 1.13 1.00 .91 .82
PCAP, programmer capability 1.42 1.17 1.00 .86 .70
VEXP, virtual machine experience 1.21 1.10 1.00 .90
LEXP, Programming language 1.14 1.07 1.00 .95
experience
Project Attributes
MODP, modem programming 1.24 1.10 1.00 .91 .82
practices
TOOL, use of SW tools 1.24 1.10 1.00 .91 .83
SCHED, development schedule 1.23 1.08 1.00 1.04 1.10
 A new project with estimated 400 KLOC embedded system has to be developed.
Project manager hires developers of low quality but a lot of experience in
programming language. Calculate the Effort, Development time, Staff size &
Productivity.

Cost Drivers Very Low Nominal High Very High Extra High
Low
AEXP 1.29 1.13 1.00 0.91 0.82 --
LEXP 1.14 1.07 1.00 0.95 -- --

EAF = 1.29 * 0.95 = 1.22

400 LOC implies Embedded System

Effort = 2.8*(400)1.20 * 1.225 = 3712 * 1.22 = 4528 person-months

Development Time = 2.5 * (4528)0.32 = 2.5 * 14.78 = 36.9 months

Avg. Staff Size = E/D = 4528/36.9 = 122 persons

Productivity = KLOC/Effort = 400/4528 = 0.0884 KLOC/person-month
 Unit-2

Project Scheduling: Basic Concepts, Project Scheduling- Basic

Principles, Relationship between People and Effort, Task Network,
Scheduling, Gantt and PERT charts, Staffing, Project monitoring and
control.
Software configuration management: Concepts and definitions, Need
and importance of SCM, Benefits of SCM, The SCM Process, Plan
preparation with case study, Infrastructure setup, Team Training, System
Operation, System Maintenance, System Retirement. Configuration
Baselines, Interface Control, Metrics change control –Submitting
Change Request, Request Analysis, Request Disapproval and Request
Approval Configuration Control Tool.
Project Scheduling

• Schedule estimation and staff requirement estimation

may be the most important activities after cost
estimation.
• The goal of schedule estimation is to determine the total
duration of the project and the duration of the different
phases.
• Once we have the estimates of the effort and time
requirement for the different phases, a schedule for the
project can be prepared. This schedule will be used later
to monitor the progress of the project.

• Schedule : A schedule is the mapping of tasks into time.

Each task has a start and an end time. Thus the deadline
 Scheduling Techniques

Scheduling can be done using two methods

• Bar Charts : Gantt Charts

• Network Diagram : PERT( Program Evaluation and Review

Technique). CPM (Critical Path Method)
 Gantt Chart

•Henry L Gantt (1861 – 1919) around 1917 developed a system of bar

charts for scheduling and reporting progress of a project. These charts
latter were known as Gantt Charts.

•It is a pictorial representation specifying the start and finish time for
various tasks to be performed in a project on a horizontal time-scale.

• A conceptually simple and effective scheduling technique is the

Gantt chart, which uses a calendar-oriented chart to represent the
project schedule.

• Each activity is represented as a bar in the calendar, starting from the

starting date of the activity and ending at the ending date for that
activity.
Gantt charts was devised by Henry Gantt (1917). It represents project
schedule with respect to time periods. It is a horizontal bar chart with
bars representing activities and time scheduled for the project activities.
 Draw back of Gantt
Chart

• The main drawback of the Gantt chart is that it does not

depict the dependency relationships among the different
activities.

• Hence, the effect of slippage in one activity on other

activities or on the overall project schedule cannot be
determined.

• However, it is conceptually simple and easy to

understand, and it is heavily used. It is sufficient for small
and medium-sized projects.
 Network Planning Models

•These project scheduling techniques model the projects

activities and their relationship as a network.
•In the network time flows from left to right.
•These techniques were originally developed in the 1950s . Two
well known techniques are Critical path method and Program
evaluation review technique
CPM Model
Activity Float : The difference between an activity earliest
start date and its latest start date is known as activity float. It
is a measure of how much the start or completion of an activity
may be delayed without affecting the end date of the project.
Any activity with a float of zero is critical in the sense that any
delay in carrying out the activity with delay the completion date
of the project as a whole

Activity Span – Difference between the earliest start date

and the latest finish date and is the measure of the maximum
Precedence Network
Forward Pass
The forward pass is carried out to calculate the earliest dates on which
each activity may be started and completed
Backward Pass
The second stage in the analysis of a critical path network is to
carry out a backward pass to calculate the latest date at which
each activity may be started and finished without delaying the
end date of the project. In calculating the latest dates, we
assume that the latest finish date for the project is the same as
the earliest finish date- That is, we wish to complete the project
as early as possible.
Identifying Critical Path
There will be at least one path through the network that
defines the duration of the project. This is known as the
critical path . Any delay to any activity on this critical path
will delay the completion of the project
PERT
PERT was developed to take account of the uncertainty surroundings
estimates of task duration.
The method is very similar to the CPM Technique (indeed many
practitioners use the term PERT and CPM interchangeably) but,
instead of using a single estimate for duration of each task. PERT
requires three estimates.
• Most likely time (m) : The time we would expect the task to take
under normal circumstances. We shall denote this by letter m
•Optimistic time (a) : The shortest time in which we could expect
complete the activity, barring outright miracle. We shall use the
letter a to denote this.
•Pessimistic time (b) : The worst possible time allowing for all
reasonable eventualities but excluding act of God and warfare) as
they say in most insurance exclusion clauses. We shall denote this
by b
•Pert then combines these three estimates to form a single expected duration te using
the formula
Using expected durations
The expected durations are used to carry our a forward pass through a network
using the same method as the CPM technique. In this case, however , the
calculated event dates are not the earliest possible dates but the dates by which we
expect to achieve those events.
To add two standard deviation we must add their squares and then find the square
root of the sum
For event 5 there are two possible path B+E . Total standard deviatoin for path
B+ E is
√(0.332 + 0.502) = 0.6 and that for path F IS 1.17.
Calculating the Z values

The Z-Values is calculated for each node that has a target date. It is equivalent to
the number of standard deviation between the nodes expected and target dates. It
is calculated using the formula

Z= T-Te / S

Where te is the expected date and T the target date

 Earned Value Analysis
Earned value analysis is the project management tool that is used to
measure project progress.

Earned value (EV) is a way to measure and monitor the level of

work completed on a project against the plan

We can calculate the EV of a project by multiplying the percent

complete by the total project budget. For example, let’s say you’re
60% done, and your project budget is $100,000, then your earned
value is $60,000

In Earned Value Analysis (EVA) everything is measured and

reported as money or monetary equivalent. The project team
determines an equivalence between Scope, Schedule, Cost to do
this.
Earned Value Indicator

•Planned Value or Budgeted Cost of work schedule (BCWS)

•Earned Value (EV) or Budgeted cost of work performed
(BCWP)
•Actual Cost (AC) or Actual cost of work performed (ACWP)
Cost Variance (CV) – Difference between the budgeted cost
and the actual cost of the completed work

For a given time(t), the cost variance is calculated

CV=EV-AC

A negative CV Means he project is over cost

Schedule Variance (SV) : Indicates the degree to which the

value of completed work differs from that planned
SV=EV-PV
Negative SV Means the project is behind schedule

CPI Cost performance Index : Defined as ratio of earned

value to actual cost
CPI=EV/AC
Schedule performance Index (SPI)

Ratio of earned value to that of planned value

SPI=EV/PV
Monitoring and Control