Chapter 4 Software Project Planning.pptx

Fundamentals of SE by Gadisa A. 1
Chapter 4
Software Project Planning

Software Project Planning
• Effective project management is crucial to the
success of any software development project.
• The main goal of software project management is to
enable a group of developers to work effectively
towards the successful completion of a project.
• project management involves use of a set of
techniques and skills to steer a project to success.

Software Project Management Complexities
• Management of software projects is much more
complex than management of many other types of
projects.
• Invisibility: Software remains invisible, until its
development is complete and it is operational.
• Anything that is invisible, is difficult to manage and
control.
• Invisibility of software makes it difficult to assess the
progress of a project and is a major cause for the
complexity of managing a software project.

• Changeability: Because the software part of any
system is easier to change as compared to the
hardware part, the software part is the one that gets
most frequently changed.
• Frequent changes to the requirements and the
invisibility of software are possibly the two major
factors making software project management a
complex task.

• Complexity: Even a moderate sized software has
millions of parts (functions) that interact with each
other in many ways data coupling, serial and
concurrent runs, state transitions, control
dependency, file sharing, etc.
• Uniqueness: Every software project is usually
associated with many unique features or situations.
• This makes every project much different from the
others.

• Exactness of the solution: Mechanical components
such as nuts and bolts typically work satisfactorily
as long as they are within a tolerance of 1 percent or
so of their specified sizes.
• However, the parameters of a function call in a
program are required to be in complete conformity
with the function definition.

• Team-oriented and intellect-intensive work:
Software development projects are akin to research
projects in the sense that they both involve team-
oriented, intellect-intensive work.
• In contrast, projects in many domains are labor-
intensive and each member works in a high degree
of autonomy.

Responsibilities of a Software Project Manager
• A software project manager takes the overall
responsibility of steering a project to success.
• The job responsibilities of a project manager ranges
from invisible activities like building up of team
morale to highly visible customer presentations.
• We can broadly classify a project manager’s varied
responsibilities into the following two major
categories:
• Project planning, and
• Project monitoring and control.

• Project planning: Project planning is undertaken
immediately after the feasibility study phase and
before the starting of the requirements analysis
and specification phase.
• Project planning involves estimating several
characteristics of a project and then planning the
project activities based on these estimates made.
• The initial project plans are revised from time to
time as the project progresses and more project data
become available.

• Project monitoring and control: Project
monitoring and control activities are undertaken
once the development activities start.
• The focus of project monitoring and control
activities is to ensure that the software development
proceeds as per plan.
• While carrying out project monitoring and control
activities, a project manager may sometimes find it
necessary to change the plan to cope up with specific
situations at hand.

Skills necessary for Managing
Software Projects
• A theoretical knowledge of various project
management techniques is certainly important to
become a successful project manager.
• Three skills that are most critical to successful project
management are the following:
1. Knowledge of project management techniques.
2. Decision taking capabilities.
3. Previous experience in managing similar projects.

Project Planning
• Once a project has been found to be feasible,
software project managers undertake project
planning.
• Project planning is undertaken and completed
before any development activity starts.
• However, for effective project planning, in addition
to a thorough knowledge of the various estimation
techniques, past experience is crucial.

Project Planning
• During project planning, the project manager
performs the following activities.
• Estimation: The following project attributes are
estimated.
• Cost: How much is it going to cost to develop
the software product?
• Duration: How long is it going to take to
develop the product?
• Effort: How much effort would be necessary to
develop the product?

Project Planning
• The effectiveness of all later planning activities
such as scheduling and staffing are dependent on
the accuracy with which these three estimations
have been made.
• Scheduling: After all the necessary project
parameters have been estimated, the schedules for
manpower and other resources are developed.
• Staffing: Staff organization and staffing plans are
made.

Project Planning
• Risk management : This includes risk
identification, analysis, and reduction planning.
• Miscellaneous plans: This includes making several
other plans such as quality assurance plan, and
configuration management plan, etc.
• Size is the most fundamental parameter based on
which all other estimations and project plans are
made.

Project Planning

The SPMP Document of Project
Planning
• Once project planning is complete, project
managers document their plans in a software project
management plan (SPMP) document.
• Listed below are the different items that the SPMP
document should discuss.
• This list can be used as a possible organization of
the SPMP document.

Planning
1. Introduction
a) Objectives
b) Major Functions
c) Performance Issues
d) Management and
Technical Constraints
2. Project estimates
e) Historical Data Used
f) Estimation Techniques
Used
g) Effort, Resource, Cost,
and Project Duration
Estimates
3. Schedule
a) Work Breakdown
Structure
b) Task Network
Representation
c) Gantt Chart
Representation
d) PERT Chart
Representation
4. Project resources
e) People
f) Hardware and Software
g) Special Resources

Planning
5. Staff organization
a) Team Structure
b) Management
Reporting
6. Risk management
plan
c) Risk Analysis
d) Risk Identification
e) Risk Estimation
f) Risk Abatement
Procedures
7. Project tracking and
control plan
a) Metrics to be tracked
b) Tracking plan
c) Control plan
8. Miscellaneous plans
d) Process Tailoring
e) Quality Assurance Plan
f) Configuration
Management Plan
g) Validation and Verification
h) System Testing Plan
i) Delivery, Installation, and
Maintenance Plan

Project Size Estimation Metrics
• Accurate estimation of project size is central to
satisfactory estimation of all other project
parameters such as effort, completion time, and
total project cost.
• The size of a project is obviously not the number of
bytes that the source code occupies, neither is it the
size of the executable code.
• The project size is a measure of the problem
complexity in terms of the effort and time required
to develop the product.

Project Size Estimation Metrics
• Currently, two metrics are popularly being used to
measure size
• lines of code (LOC) and
• function point (FP).
• Each of these metrics has its own advantages and
disadvantages.
• Based on their relative advantages, one metric may
be more appropriate than the other in a particular
situation.

Line of Code (LOC)
• LOC is possibly the simplest among all metrics
available to measure project size.
• This metric measures the size of a project by
counting the number of source instructions in the
developed program.
• One can possibly estimate the LOC count at the
starting of a project, only by using some form of
systematic guess work.

Line of Code (LOC)
• Systematic guessing typically involves the
following.
• The project manager divides the problem into
modules, and each module into sub-modules and so
on, until the LOC of the leaf-level modules are
small enough to be predicted.
• To be able to predict the LOC count for the various
leaf-level modules sufficiently accurately, past
experience in developing similar modules is very
helpful.

Shortcomings of the LOC
metric
• LOC is a measure of coding activity alone.
• A good problem size measure should consider the total
effort needed to carry out various life cycle activities (i.e.
specification, design, code, test, etc.) and not just the
coding effort.
• LOC count depends on the choice of specific
instructions:
• LOC gives a numerical value of problem size that can
vary widely with coding styles of individual
programmers.

metric
• LOC measure correlates poorly with the quality
and efficiency of the code:
• Calculating productivity as LOC generated per man-
month may encourage programmers to write lots of poor
quality code rather than fewer lines of high quality code
achieve the same functionality.
• LOC metric penalizes use of higher-level
programming languages and code reuse:
• A paradox is that if a programmer consciously uses
several library routines, then the LOC count will be
lower.

metric
• LOC metric measures the lexical complexity of a
program and does not address the more
important issues of logical and structural
complexities:
• a program incorporating complex logic would require
much more effort to develop than a program with very
simple logic.
• It is very difficult to accurately estimate LOC of
the final program from problem specification:
• The LOC count can accurately be computed only after
the code has fully been developed.

Function Point Metric
• Function point metric was proposed by Albrecht in
1983.
• This metric overcomes many of the shortcomings of
the LOC metric.
• it can easily be computed from the problem
specification itself.
• The size of a software product is directly
dependent on the number of different high-level
functions or features it supports.

Organizational and Team structures
1. Organization structure
• Usually, every software development organization handles
several projects at any time.
• Software organizations assign different teams of engineers
to handle different software projects.
• Each type of organization structure has its own advantages
and disadvantages so the issue “how is the organization as
a whole structured?” must be taken into consideration so
that each software project can be finished before its
deadline.

Organization structure
Functional format vs. Project format
• In the project format, the project development staff are
divided based on the project for which they work.
• In the functional format, the development staff are divided
based on the functional group to which they belong.
• In the functional format, different teams of programmers
perform different phases of a project.
• For example, one team might do the requirements
specification, another do the design, and so on.
• In the project format, a set of engineers is assigned to the
project at the start of the project and they remain with the
project till the completion of the project.

Organization structure
Project format Functional format

Team structures
1. Centralized – Control Team Organization
• Workers report to supervisor – who directly controls and is
responsible for their performance Specialists
• Standard management technique

Team structures
2. Decentralized – Control Team Organization
• Ring like management – lack of hierarchy
• Team members – same level, review each other‘s work and
responsible as a group
Software Engineer
Communication

Team structures
3. Mixed – Control Team Organization
• Combine the benefits of centralized and decentralized
organization
• Minimizing / avoiding their disadvantages
• Distinguishes the engineers into senior and junior ; senior leads a
group of juniors; senior report to a project manager

Scheduling
• The scheduling problem, in essence, consists
of deciding which tasks would be taken up
when and by whom.

Scheduling …….General Practices:
• On large projects, hundreds of small tasks must occur to
accomplish a larger goal
• Project manager’s objectives
• Define all project tasks
• Build an activity network that depict their interdependencies
• Identify the tasks that are critical within the activity network
• Build a timeline depicting the planned & actual progress of each
task
• Track task progress to ensure that delay is recognized “one day
at a time”
• To do this, the schedule should allow progress to be monitored
and the project to be controlled.

General Practices…..Cont’d
• SW project scheduling distributes estimated effort across the
planned project duration by allocating the effort to specific
tasks
• Scheduling for project can be viewed from two different
perspectives
• First, an end-date for release for a computer-based system
has already been established & fixed
• The sw organization is constrained to distribute effort
within the prescribed time frame
• Second, assume that rough chronological bounds have been
discussed but that the end-date is set by the SE organization
• Effort is distributed to make best use of resources and
an end-date is defined after careful analysis of the
software.

Basic Principles for Project Scheduling
• Compartmentalization
• The project must be compartmentalized into a number of
manageable activities, actions, & tasks; both the product &
process are decomposed
• Interdependency
• The interdependency of each compartmentalized activity,
action, or task must be determined
• Some task must occur in sequence while others can occur
in parallel
• Some actions or activities cannot commence until the work
product produced by another is available

• Time allocation
• Each task to be scheduled must be allocated some number of
work units
• In addition, each task must be assigned a start date and a
completion date that are a function of the interdependencies
• Start and stop dates are also established based on whether
work will be conducted on a full-time or part-time basis
• Effort validation
• Every project has a defined number of people on the team
• As time allocation occurs, the project manager must ensure
that no more than the allocated number of people have been
scheduled at any given time

• Defined responsibilities
• Every task that is scheduled should be assigned to a specific
team member
• Defined outcomes
• Every task that is scheduled should have a defined outcome for
SW projects such as a work product or part of a work product
• Work products are often combined in deliverables
• Defined milestones
• Every task or group of tasks should be associated with a project
milestone
• A milestone is accomplished when one or more work products
has been reviewed for quality and has been approved

Software Risk Management
• We Software developers are extremely optimists.
• We assume, everything will go exactly as planned.
• Other view
not possible to predict what is going to happen ?
Software surprises
Never good news
Risk Management

Risk
factor
management is required to reduce this surprise
Dealing with concern before it becomes a crisis.
Quantify probability of failure & consequences of failure.
Risk Management

What is risk ?
Tomorrow’s problems are today’s risks.
“Risk is a problem that may cause some loss
or threaten the success of the project, but which
has not happened yet”.
Risk Management

Risk management is the process of identifying
addressing and eliminating these problems before
they can damage the project.
Current problems &
Potential Problems
Risk Management

Typical Software Risk
•Capers Jones has identified the top five risk factors
that threaten projects in different applications.
1. Dependencies on outside agencies or factors.
• Availability of trained, experienced persons
• Inter group dependencies
• Customer-Furnished items or information
• Internal & external subcontractor relationships
Risk Management

2. Requirement issues
Uncertain requirements
Wrong product
or
Right product
badly
Either situation
results unhappy
customers.
in unpleasant surprises and
Risk Management

• Lack of clear product vision
• Lack of agreement on product requirements
• Unprioritized requirements
• New market with uncertain needs
• Rapidly changing requirements
• Inadequate Impact analysis of requirements changes
Risk Management

3. Management Issues
Project managers
plans, and
most
usually
people
write the risk management
to air
their
do not wish
weaknesses in public.
• Inadequate planning
• Inadequate visibility into actual project status
• Unclear project ownership and decision making
• Staff personality conflicts
• Unrealistic expectation
• Poor communication
Risk Management

4. Lack of knowledge
• Inadequate training
• Poor understanding of methods, tools,
and techniques
• Inadequate application domain experience
• New Technologies
• Ineffective, poorly documented or neglected
processes
Risk Management

5. Other risk categories
• Unavailability of adequate testing facilities
• Turnover of essential personnel
• Unachievable performance requirements
• Technical approaches that may not work
Risk Management

Risk
Management
Risk Management Activities
Risk
Assessment
Risk Control
Risk Identification
Risk Analysis
Risk Prioritization
Risk Management
Planning
Risk Monitoring
Risk Resolution
Fig. 9: Risk
Management
Activities
Risk Management

Risk Assessment
Identification of risks
Risk analysis involves
examining
how project
outcomes
might change with modification of risk input variables.
Risk prioritization focus for severe risks.
Risk exposure: It is the product of the probability of
incurring a loss due to the risk and the potential magnitude of
that loss.
Risk Management

Another way of handling risk is the risk avoidance. Do not do
the risky things! We may avoid risks by not undertaking
certain projects, or by relying on proven rather than
cutting edge technologies.
Risk Management

Risk Control
Risk Management Planning produces a plan for dealing with
each significant risks.
Y Record decision in the plan.
Risk resolution is the execution of the plans of dealing
with each risk.
Risk Management

Thank You!
End of the Chapter

Chapter 4 Software Project Planning.pptx

More Related Content

Similar to Chapter 4 Software Project Planning.pptx

More from gadisaAdamu

Recently uploaded

Chapter 4 Software Project Planning.pptx