This document outlines the 10 step process for software project planning. It begins with selecting the project and identifying its scope and objectives. It then covers identifying the project infrastructure, analyzing project characteristics, and identifying products and activities. Steps also include estimating effort for each activity, identifying risks, allocating resources, and reviewing/publicizing the plan. Execution then involves lower level planning. The document also discusses software effort estimation techniques such as algorithmic models, expert judgment, analogy, and top-down and bottom-up approaches.

1. SOFTWARE PROJECT
MANAGEMENT
Prof. Kanchana Devi V

2. 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

3. 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

5. 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.

6. 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

7. 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.

8. 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.

9.  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.

10. 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)

11. 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.

12. Fragment of Product Flow
Diagram

13. …
 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.

14. Example of Activity Network

15.  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.

16. 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

17. 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

18. 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.

19. Step 8: Review/ Publicize plan
 8.1 Review quality aspects of the project plan
 8.2 Document plans and obtain agreement

20. Steps 9 and 10: Execute
plan/Lower levels of planning
 Provisional plans for more distant tasks has
to be performed

21. Software Effort Estimation
 Successful project is that the system is
delivered on time and within budget and
with the required quality.

22. Software effort estimation
Difficulties in Software estimation
 Subjective Nature of estimating
 Political Implications
 Changing Technology
 Lack of homogeneity of project experience

23. Project Data
Note:
SLOC - Source Number of Lines of Code
WM -Work in Month

24. 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.

25. 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

26. 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.

27. 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

28. 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.

29. 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

30. Euclidean Distance

31. 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”

32. Measure of Work
 Measure such as SLOC ( Source Lines of Code)
 KLOC ( Thousand Lines of Code)

33. 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)

34. Albrecht Complexity Multipliers

35. IFPUG File Type Complexity

36. 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

37. Model of Transaction
Data Store
ProcessFrom User Return to
User
Input Output

38. 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

39. 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)