Upload
griffin-williams
View
238
Download
0
Tags:
Embed Size (px)
Citation preview
S/W Project Management
Software Project PlanningSoftware Project Planning
Agenda
Overview of phases of Software Project Management (SPM)
Software Project Planning Project Content and deliverables
S/W Project Planning
2
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
3
Phases of SPM
The previous management activities are captured using the acronym POMA: Planning Organizing Monitoring Adjusting
S/W Project Planning
4
POMA Management Process
Planning Activities
Organizing Activities
Monitoring Activities
Adjustment Activities
S/W Project Planning
5
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
6
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
7
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
8
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
9
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
10
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
11
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
12
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
13
Agenda
Phases of Software Project Management (SPM)
Software Project Planning (POMA) Project Content and deliverables
S/W Project Planning
14
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
15
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
16
Comprehensive Plan
Cost Details in terms of some unit e.g., person-days,
for each deliverable Includes expenditures – tools, travel, training,
communicationsResources
List of people needed and their skills Complete set of tools Special training Software and hardware systems required
S/W Project Planning
17
Comprehensive Plan
Process and Methods 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
18
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
19
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
20
Agreeing on and initiating Reqs
Reqs Elicitation
Reqs Analysis andPrototyping
Reqs Review
Reqs Specification
Agreeing and“Signing Off”
(as needed)
General requirements management activities
S/W Project Planning
21
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
22
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
23
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
24
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
25
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
26
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
27
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
28
Development
Support
Customer
Consultant
ReqsRepository.
.
.
SoftwareProductManagementBoard
List of Reqs input to the Product Plan
RequirementsPrioritization
RequirementsSources
Requirements Prioritization
S/W Project Planning
29
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
30