Вы находитесь на странице: 1из 39

SOFTWARE PROJECT

MANAGEMENT

Prof. Kanchana Devi V


Project Planning
 Step 0: Select Project
 Step 1: Identify Project Scope & Objectives
 Step 2: Identify Project Infrastructure
 Step 3: Analyse Project Characteristics
 Step 4: Identify Project Products & Activities
 Step 5: Estimate Effort for Each Activity
Project Planning- Continued…
 Step 6: Identify Activity Risks
 Step 7: Allocate Resources
 Step 8: Review/ Publicize Plan
 Step 9 & 10: Execute Plan/Lower Level
Planning
Step 0: Select Project
 It is outside the main project planning
process.
 A feasibility study might suggest that there is
a business case for the project.
Step 1 : Identify Project Scope and
Objectives
 1.1 Identify objectives and measures of
effectiveness in meeting them
 1.2 Establish a project authority
 1.3 Identify Stakeholders
 1.4 Modify objectives in light of stakeholder
analysis adding new features
 1.5 Establish methods of communication with
all parties
Step 2 : Identify Project Infrastructure

2.1 Establish relationship between project and


strategic planning
 Compliance with enterprise architecture.
2.2 Identify installation standards and procedures
 Define development procedures, Normal stages in software life
cycle.
 Change control and Configuration Management
2.3 Identify project team organization
 Decision about grouping business analysts and software
developers.
Step 3 : Analyze Project
Characteristics
 Ensure appropriate methods are used for
project.
 3.1 Distinguish project either objective or
product driven
 3.2 Analyze other project characteristics
 System will be safety critical, where human life could be
threatened.
 3.3 Identify high level project risks
 Most risks attributed to operational or development
environment.
 3.4 Take into account user requirements
concerning implementation.
 Client may have own procedural requirement
 3.5 Select development methodology and
life-cycle approach
 3.6 Review overall resource estimate
 Re-estimate the effort and other resources required to
implement the project.
Step 4 : Identify project products and
activities
 Longer term planning is broad and in outline,
while more immediate tasks are planned in
detail.

 4.1 Identify and describe project


products(deliverables)
 4.2 Document generic product flows
 A program design must be created before program can be
written
 Program specification must exist before design can be
commenced.
 Relationships can be portrayed in Product Flow Diagram(PFD)
Product Description Contains
 Name/Identity of the product
 Purpose of the product
 Derivation of the product
 Composition of the product
 Relevant Standards
 Quality criteria that define whether the
product is acceptable.
Fragment of Product Flow
Diagram

 4.3 Recognize product instances
 Component software modules in the software to be
built.
 4.4 Produce ideal activity network
 Resources are available for both software modules
to be developed in parallel.
Example of Activity Network
 4.5 Modify the ideal to take into account
need for stages and checkpoints
 Dividing the project into stages and introducing
checkpoint activities.
 Checkpoint activities are often useful milestones.
 Activity with no duration that indicates the start or
end of group of activities.
Step 5 : Estimate Effort for each
Activity
 5.1 Carry out bottom up estimates.
 Estimates
of effort, cost and duration will already have
been done.
 5.2 Revise plan to create controllable activities.
 System testing involving longer time
Step 6: Identify Activity Risks

 6.1 Identify and Quantify activity based risks.


 6.2 Plan risk reduction and contingency
measures where appropriate
 6.3 Adjust overall plans and estimates to take
account of risks
Step 7 : Allocate resources

 7.1 Identify and Allocate Resources


 Type of staff needed for each activity and provisionally
allocated for each tasks.
 7.2 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 order of priority to be established.
 Decisions made will have an effect on overall duration of
project.
Step 8: Review/ Publicize plan

 8.1 Review quality aspects of the project plan

 8.2 Document plans and obtain agreement


Steps 9 and 10: Execute
plan/Lower levels of planning

 Provisional plans for more distant tasks has


to be performed
Software Effort Estimation
 Successful project is that the system is
delivered on time and within budget and
with the required quality.
Software effort estimation
Difficulties in Software estimation

 Subjective Nature of estimating


 Political Implications
 Changing Technology
 Lack of homogeneity of project experience
Note:
SLOC - Source Number of Lines of Code

Project Data WM - Work in Month


Where are estimates done?
 Estimates are carried out at various stages of
software project.
 Strategic Planning
 Decide priority to each project.
 Feasibility Study
 Benefits of potential system
 System Specification
 Detailed requirement analysis at design stage.
 Evaluation of Suppliers Proposals
 Tender Management
 Project Planning
 Detailed estimates of smaller work components during
implementation.
Software Effort Estimation
Techniques
 Algorithmic Models
 Expert Judgment
 Analogy – Similar Completed Project
 Parkinson – Staff Effort available to do project
 Price to Win – Sufficiently low to win a contract.
 Top-down – Overall estimate is formulated
 Bottom-up – Individual components are
aggregated
Bottom-up Estimating
 Work Breakdown Structure
 Assumptions about characteristics of final
system
 Number and Size of software modules.
 Appropriate at detailed stages of project
planning.
 When a project is completely novel or no
historical data available.
Top-down Approach and
Parametric Models
 Effort = (system size ) * (productivity rate)
 System size in the form of KLOC
 Productivity rate 40 days per KLOC
 Software module to be constructed is 2 KLOC
 Effort = 2 * 80 = 160 days

Note:
KLOC- Thousands of Lines of Code
Expert Judgment
 Asking for estimate of task effort from
someone who is knowledgeable about either
application or development environment.
 Experts use the combination of informal
analogy approach where similar projects
from past are identified and bottom up
estimating.
Estimating by Analogy
 Called “Case Based Analogy”
 Estimator identifies completed projects
source cases with similar characteristics to
new project (target case)
 Effort of the source case used as base
estimate for target.
 TOOL – ANGEL software tool
 Measuring Euclidean Distance between the
cases
Euclidean Distance
Problems with Over and Under
Estimates
 Parkinson’s Law
 “Given an easy target staff will work less hard”

 Brook’s Law
 Effort required to implement a project will go up
disproportionately with the number of staff assigned
to the project
 “ Putting more people on a late job makes it later”
Measure of Work
 Measure such as SLOC ( Source Lines of Code)
 KLOC ( Thousand Lines of Code)
Albrecht Function Point Analysis

 Top - down method devised by Allan


Albrecht(IBM)
 Developed the idea of Function Points(FPs)
 Basis of function point analysis has five
components:
 External Input Types
 External Output Types
 External Inquiry Types – US spelling inquiry
 Logical Internal File Types – Data store
 External Interface File Types – To & Fro (BACS)
Albrecht Complexity Multipliers
IFPUG File Type Complexity
Function Points Mark II
 Sponsored by CCTA(Central Computer and
Telecommunications Agency)
 Mark II – Improvement and replacement in
Albrecht method
 In Albrecht method
 Information
Processing Size is measured in
UFPs(Unadjusted Functional Points)
 Then TCA(Technical Complexity Adjustment) is
applied
Model of Transaction

Data Store

Input Output
From User Process Return to
User
For each transaction UFPs are
calculated
 UFAs = Wi * (number of input data element types)+
We * (number of entity types referenced)+ Wo *
(number of output data element types)
 Wi We Wo are weightings derived by asking
the developers the proportions of effort
spent.
 FP counters use industry averages which are:
 Wi = 0.58
 We = 1.66
 Wo = 0.26
COSMIC Full Function Points
 Cosmic deals with decomposing the system
architecture into hierarchy of software layers.
 Inputs and outputs are aggregated into data
groups
 Each data group brings together data items that
relate to the same object of interest
 Groups can be moved in 4 ways:
 Entries(E)
 Exits(X)
 Reads ( R)
 Writes(W)

Вам также может понравиться