Applied Software Project Management - PowerPoint PPT Presentation

Loading...

PPT – Applied Software Project Management PowerPoint presentation | free to download - id: 78d7b5-YzhjM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Applied Software Project Management

Description:

Applied Software Project Management Chapter 2 Software Project Planning [Modified version of Stellman and Greene s Chapter 2 s. Adapted for use only in the CS ... – PowerPoint PPT presentation

Number of Views:37
Avg rating:3.0/5.0
Slides: 17
Provided by: Sergiu152
Learn more at: http://www.cse.unr.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Applied Software Project Management


1
Applied Software Project Management
  • Chapter 2
  • Software Project Planning
  • Modified version of Stellman and Greenes
    Chapter 2 slides. Adapted for use only in the CS
    709B course at UNR, Spring 2012

2
Who Needs Software?
  • Most software is built in organizations for
    people with specific needs
  • A stakeholder is a anyone who has an interest (or
    stake) in the software being completed
  • A user is someone who will need to use the
    software to perform tasks
  • Sometimes stakeholders will be users but often
    the stakeholder will not use the software
  • For example, a senior manager (like a CEO or CTO
    in a company) will usually have a stake in the
    software that is built (since it affects the
    bottom line), even if she wont ever use it

3
Who Builds Software?
  • Software is typically built by a team of software
    engineers, which includes
  • Business analysts or requirements analysts who
    talk to users and stakeholders, plan the behavior
    of software and write software requirements
  • Designers and architects who plan the technical
    solution
  • Programmers who write the code
  • Testers who verify that the software meets its
    requirements and behaves as expected

4
Project Management
  • The project manager plans and guides the software
    project
  • The project manager is responsible for
    identifying the users and stakeholders and
    determining their needs
  • The project manager coordinates the team,
    ensuring that each task has an appropriate
    software engineer assigned and that each engineer
    has sufficient knowledge to perform it
  • To do this well, the project manager must be
    familiar with every aspect of software engineering

5
Identifying Needs
  • The project manager drives the scope of the
    project
  • The project manager should identify and talk to
    the main stakeholder(s)
  • The effective way to show stakeholders that their
    needs are understood and that those specific
    needs will be addressed is with a vision and
    scope document

6
Vision and Scope Document
  • A typical vision and scope document follows an
    outline like this one
  • Problem Statement
  • Project background
  • Stakeholders
  • Users
  • Risks
  • Assumptions
  • Vision of the Solution
  • Vision statement
  • List of features
  • Scope of phased release (optional)
  • Features that will not be developed

7
Vision and Scope Document
  • The vision and scope document items should be
    discussed with the stakeholders
  • It can be used as an agenda for an initial
    meeting
  • A lot of notes should be taken
  • The document is used to build consensus and acts
    also as a summary of discussions
  • After it is written it should be reviewed by
    every stakeholder, representative users, and
    members of the development team. Agreement by all
    is important.
  • Recommended extra reading Scott Berkun, The Art
    of Project Management, OReilly 2005.

8
Vision and Scope Document
  • Problem Statement
  • Project background
  • Problem, its reasons, brief history, prior
    attempts to address it, how a decision to tackle
    it was reached
  • Stakeholders
  • Bulleted list roles, titles, or names main
    needs for each
  • Users
  • Idem, but if many users, roles or titles should
    be used
  • Risks
  • Main potential risks, issues, external factors
  • Assumptions
  • Use Wideband Delphi estimation technique or a
    brainstorming session

9
Vision and Scope Document
  • Vision of the Solution
  • Vision statement
  • What the project is about, what is expected to
    accomplish
  • Should provide compelling justifications for
    funding
  • List of features
  • Feature cohesive area of the software that
    fulfills a specific need by providing a set of
    services or capabilities
  • Any software package can be broken down into
    features
  • Chose here the right level of granularity.
    Recommended about 10 features
  • For each feature name brief description
  • Scope of phased release (optional)
  • Sometimes it is useful to have the features
    implemented in 2 or 3 releases
  • A feature can also be divided over 2 releases,
    but that needs to be explained clearly
  • Features that will not be developed
  • Unrealistic or lower priority features should be
    listed here

10
Project Plan
  • The project plan defines the work that will be
    done on the project and who will do it. It
    consists of
  • A statement of work (SOW) that describes all work
    products that will be produced and a list of
    people who will perform that work
  • A resource list that contains a list of all
    resources that will be needed for the product and
    their availability
  • A work breakdown structure and a set of estimates
  • A project schedule
  • A risk plan that identifies any risks that might
    be encountered and indicates how those risks
    would be handled should they occur

11
Statement of Work
  • The statement of work (SOW) is a detailed
    description of all of the work products which
    will be created over the course of the project.
    It includes
  • A list of features that will be developed
  • A description of each intermediate deliverable or
    work product that will be built (with one
    paragraph description for each)
  • SRS, design and architecture specs, code and
    software packages, test plans and test cases,
    user acceptance plans, source code, executables,
    documentation, tutorials, user manuals, all other
    work products that will be created.
  • The estimated effort involved for each work
    product to be delivered

12
Resource List
  • The project plan should contain a list of all
    resources that will be used on the project.
  • A resource is a person, hardware, room or
    anything else that is necessary for the project
    but limited in its availability
  • The resource list should give each resource a
    name, a brief one-line description, and list the
    availability and cost (if applicable) of the
    resource

13
Estimates and Project Schedule
  • The project plan should also include estimates
    and a project schedule
  • A work breakdown structure (WBS) is defined. This
    is a list of tasks which, if performed, will
    generate all of the work products needed to build
    the software
  • An estimate of the effort required for each task
    in the WBS is generated
  • A project schedule is created by assigning
    resources and determining the calendar time
    required for each task
  • Estimates and project schedules will be discussed
    in detail in later slides

14
Risk Plan
  • A risk plan is a list of all risks that threaten
    the project, along with a plan to mitigate some
    or all of those risks
  • The project manager selects team members to
    participate in a risk planning session
  • The team members brainstorm potential risks
  • The probability (from 1 highly unlikely to 5
    very likely to occur) and impact (1 low impact
    to 5 huge impact) of each risk are estimated
  • A risk plan is constructed
  • The session normally takes about 2 hours

15
Risk Plan
  • To draw the risk plan
  • Brainstorm potential risks and make initially
    vague risks (the project might be delayed)
    concrete
  • For estimation, percentages can also be used
  • A simple technique for prioritization
  • Identify the top and bottom items (probability
    and respectively, impact) and give them values 5
    and, respectively, 1. Then assign all other items
    values from 1 to 5 based on comparison with these
    extremes
  • Also for prioritization, use probability x
    impact
  • Start mitigation plans for the highest priority
    items
  • For mitigation alter project plan (e.g., alter
    schedule), add additional tasks, plan for risks

16
Risk Plan Example
About PowerShow.com