1. S/W Project Management
Software Project Planning

2. Agenda Overview of phases of Software Project Management (SPM)
Software Project Planning
Project Content and deliverables
S/W Project Planning

3. Phases of SPM The software project management activities include:
Project planning and scheduling
Project cost
Project monitoring and reviews
Personnel selection and evaluation
Report writing and presentations
S/W Project Planning

4. Phases of SPM
The previous management activities are captured using the acronym POMA:
Planning
Organizing
Monitoring
Adjusting
S/W Project Planning

5. POMA Management Process
Planning Activities
Organizing Activities
Monitoring Activities
Adjustment Activities
S/W Project Planning

6. POMA Models the software management cycle
Software processes model development cycle
Applies software engineering knowledge
For example
Requirements elicitation
Software measurements
S/W Project Planning

7. POMA Not necessarily sequential
Activities within each category may overlap
Categories may overlap
For example, original plans may be adjusted during monitoring and adjustment activities.
S/W Project Planning

8. Planning
Set of activities used to develop a plan of attack for the project:
Description of software product i.e., artifact contents and deliverables.
The Software product attributes.
Project schedule.
Resources needed to meet project schedule.
Measurements used to gauge the status of the project.
Risk associated with project.
S/W Project Planning

9. Planning Points to note: Time consuming Important phase of SPM
Often rushed
Even with a well conceived plan changes are often necessary.
Experience is very helpful in developing a project plan. especially knowledge of organization.
S/W Project Planning

10. Organizing
Seeks to construct a software development based on the project plan.
Activities include:
Acquiring various skilled individuals needed for the project.
Defining the a process and a set of methodologies for the project.
Obtaining the tools to support the process and methodologies.
Creating a set of well-defined metrics to track and gauge the project.
S/W Project Planning

11. Organizing Issues of major concern:
Personnel are properly equipped to perform their designated task i.e.,
equipping personnel include obtaining tools and preparing facilities
educating personnel in using tools, methodology, and metrics
Allocation of adequate financial funding.
Team may include financial and personnel management.
“People management” aspect of organizing is critically important.
Morale affects productivity
S/W Project Planning

12. Monitoring Monitoring focuses on:
Consistently and regularly collecting measurements.
Analyzing the data.
Representing and presenting the data for a defined set of reports.
Making projections and making recommendations based on the analysis of the data.
Involves people management.
S/W Project Planning

13. Adjusting Adjustments are often necessary due to:
Changing software requirements
Discovery of an unfeasible design
Lost of skilled team members
Financial constraints
Adjustments may be made to:
Requirements
Schedule
Resources
Project content
It is very important to do a thorough risk analysis during the planning stage of the project
S/W Project Planning

14. Agenda Phases of Software Project Management (SPM)
Software Project Planning (POMA)
Project Content and deliverables
S/W Project Planning

15. Plan Content Varies depending on the type of software project.
All project plans must address:
What is the nature of the s/w project and what software artifacts are the desired deliverables?
What is the overall schedule and the associated major project milestones?
What are the required resources and their associated financial costs?
What are the known risks and the areas that are still unknown?
S/W Project Planning

16. Comprehensive Plan Problem and requirements
User problems needs and wishes
Product/Project Description
Complete scope of the project i.e., all project deliverables, and a description of each deliverable.
Product/Project Attributes
Description of the various attributes of deliverables and non deliverables as they pertain to the goals of the project e.g., quality. Identify metrics for the attributes.
Schedule
Sequence of tasks
Identification of milestones and deliverables
S/W Project Planning

17. Comprehensive Plan Cost Resources
Details in terms of some unit e.g., person-days, for each deliverable
Includes expenditures – tools, travel, training, communications
Resources
List of people needed and their skills
Complete set of tools
Special training
Software and hardware systems required
S/W Project Planning

18. Comprehensive Plan Process and Methods Risks
Description of the overall process and methods
Risks
List of potential problems
Assessed impact
Probability of occurrence
Plan to prevent risk from turning into a real problem
S/W Project Planning

19. Requirements Elicitation
Before the project can be initiated, software engineers need to:
identify the requirements of the project,
interfaces to related systems or subsystems.
Gathering s/w requirements is one of the most difficult task of any s/w project.
The software project manager needs to provide an environment conducive to proper requirements gathering and analysis.
Enough time and suitable skilled people
S/W Project Planning

20. Requirements Elicitation
Points to note:
Requirements must be understood and agreed upon by all the stakeholders.
Not just software engineers
Not understanding the s/w requirements of the project can be very costly.
Improper testing, quality issues
Customer requirements not met
Missed schedules
Consult domain experts is necessary.
The requirements document is a contract!!
S/W Project Planning

21. General requirements management activities
Agreeing on
and initiating
Reqs
Reqs
Elicitation
Reqs Analysis
and
Prototyping
(as needed)
Reqs
Review
Reqs
Specification
Agreeing and
“Signing Off”
S/W Project Planning

22. Requirements Analysis
Involves checking that the specification is correct, complete, consistent, unambiguous, and realistic.
Correct – accurately represents the client’s view of the system.
Complete – all possible scenarios are described including exceptional behavior.
Consistent – does not contradict itself.
Unambiguous – exactly one system is defined.
S/W Project Planning

23. Requirements Analysis
Software prototype - a s/w model created for the purpose of better understanding the requirements and the feasibility of the proposed solution.
Must have clearly specified schedules
To avoid repeated viewing and reviewing of prototypes
Define clear entrance and exit criteria.
Define scope of prototype activity.
Must be agree upon by everyone.
S/W Project Planning

24. Types of Requirements Major types of requirements:
The project deliverables
The needs satisfied by the deliverables (project)
Project deliverables
Requirements document
Design document
Source code
Executable code
Test scenarios
S/W Project Planning

25. Types of Requirements Project deliverables
Test cases with test data
User guide
Product reference manual
Test results and quality-related data
Process specification
Project plan
It is important to be informed of the practices of the organization.
S/W Project Planning

26. Types of Requirements Project needs and their characterization
This is the area where most s/w engineers, rather than the software project manager, should focus there energy.
The following items should be identified:
The functionality of the s/w
The nonfunctional requirements of the s/w
The interfaces that the s/w needs to interact with its users
S/W Project Planning

27. Review and Approval of Requirements
software project manager needs to ensure the first set of reqs (the deliverables) are clearly defined understood, prioritized, and agreed upon by the stakeholders.
All parties should formally “sign-off” on the deliverables.
include a final review of the requirements specification prior to sign-off.
S/W Project Planning

28. Prioritization of Requirements
Project reqs are sometimes initiated by solution providers internally.
These requirements are the most difficult to evaluate.
The requirements usually initiate during maintenance.
It is a good idea to have a prioritization procedure for both internal and external reqs.
Inputs from the various reqs sources are constantly coming in to the s/w organization and being captured, possibly by an automated tool.
S/W Project Planning

29. Requirements Prioritization
Sources
Development
Requirements
Prioritization
Support
Software
Product
Management
Board
List of
Reqs input to the
Product Plan
Reqs
Repository .
Customer
Consultant
S/W Project Planning

30. Prioritization of Requirements
Resources must be set aside for the following activities:
Regular review of inputs
Analysis of the valid inputs
Prioritization of the inputs
Response to both the accepted ideas and rejected ones
Formulation of the accepted reqs subset into actual reqs for the product plan.
S/W Project Planning