Applied Software Project Management

Slides:



Advertisements
Similar presentations
Systems Analysis and Design 9th Edition
Advertisements

Risks  All projects have some degree of risk  Risks are issues that can cause problems  Delay in schedule  Increased project costs  Technical risk.
CSCU 411 Software Engineering Chapter 2 Introduction to Software Engineering Management.
Systems Analysis and Design 9th Edition
Project Plans CSCI102 - Systems ITCS905 - Systems MCS Systems.
Requirements Analysis CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 7, 2003.
Project Planning Dr. Jane Dong Electrical and Computer Engineering.
SE 555 Software Requirements & Specification Requirements Management.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Why Software.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Project Management Session 7
4. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Explain the elements of project management and the responsibilities of a.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Lesson 2: Software Project Planning
Planning. SDLC Planning Analysis Design Implementation.
Release & Deployment ITIL Version 3
Typical Software Documents with an emphasis on writing proposals.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management greene.com 1 Applied Software.
Software Testing Lifecycle Practice
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 3rd Edition Copyright © 2009 John Wiley & Sons, Inc. All rights.
Applied Software Project Management Andrew Stellman & Jennifer Greenehttp:// Applied Software Project Management Chapter 1: Introduction.
Project Management Chapter 3. Objectives Become familiar with estimation. Be able to create a project workplan. Understand why project teams use timeboxing.
Best Practices By Gabriel Rodriguez
Project Management : Techniques and Tools (60-499) Fall 2014 / Winter 2015.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Recap from last week Understand organizations, including the four frames, organizational structures. Explain why stakeholder management and top management.
Chapter 14 Information System Development
FCS - AAO - DM COMPE/SE/ISE 492 Senior Project 2 System/Software Test Documentation (STD) System/Software Test Documentation (STD)
Estimation Chapter 3 Applied Software Project Management, Stellman & Greene.
Software Project Planning Chapter 2 Applied Software Project Management, Stellman & Greene.
Software Development Process and Management (or how to be officious and unpopular)
Software Requirements The starting point of software development “He kept changing the requirements on us” 1 540f07reqelic4sep4.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Project Scope Management Project management Digital Media Department Unit Credit Value : 4 Essential Learning time : 120 hours.
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
Ch 4 - Learning Objectives Scope Management You should be able to: n Discuss the relationship between scope and project failure n Describe how strategic.
Applied Software Project Management LESSON 3: ESTIMATION Applied Software Project Management 12:02:37 PM 1.
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 What is Solution Assessment & Validation?
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Initiation Project Management Minder Chen, Ph.D. CSU Channel Islands
Module 5 Session 5.2 Visual 1 Module 5 Refining Objectives, Scope, and Other Project Parameters Session 5.2 Reviewing the PAR and refining key project.
Requirements Document Work Breakdown Structure. Schedule DateTooicAssignment 1-Oct-08work breakdown/features breakdown 8-Oct-08agile methodsrequirements.
Slide 1ICT 327 Management of IT ProjectsSemester 2, 2004 Topic 11 Executing & Controlling Projects.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System A Use Case Primer Organizing.
Rational Unified Process (RUP)
Unit – I Presentation. Unit – 1 (Introduction to Software Project management) Definition:-  Software project management is the art and science of planning.
Project Management Processes for a Project Chapter 3 PMBOK® Fourth Edition.
Defining and Managing Project Scope. MOV Scope Phases Time Estimates Resources Tasks Schedule Budget Sequence Project Planning Framework.
The Project Management Process Groups
Information Technology Project Management, Seventh Edition.
Slide 1ICT 327 Management of IT ProjectsSemester 1, 2005 Topic 3 Executing & Controlling & Closing Projects.
Scrum CS These outstanding slides were created by Kevin Schenk, BS in Computer Science, Purdue University, 2012.
Chapter Five Project Planning.
IFS 231 Business Analysis LECTURE 2 The Business Case.
Office 365 Security Assessment Workshop
Project Management PTM721S
Use Cases Discuss the what and how of use cases: Basics Benefits
Scrum CS These outstanding slides were created by Kevin Schenk, BS in Computer Science, Purdue University, 2012.
Scrum CS These outstanding slides were created by Kevin Schenk, BS in Computer Science, Purdue University, 2012.
Scrum CS These outstanding slides were created by Kevin Schenk, BS in Computer Science, Purdue University, 2012.
Chapter 3: The Project Management Process Groups: A Case Study
Project Management Process Groups
Applying Use Cases (Chapters 25,26)
Applied Software Project Management
Software Testing Lifecycle Practice
Introduction to Project Management
Executive Project Kickoff
Presentation transcript:

Applied Software Project Management Chapter 2 Software Project Planning [Modified version of Stellman and Greene’s Chapter 2 slides. Adapted for use only in the CS 709B course at UNR, Spring 2012] http://www.stellman-greene.com

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 won’t ever use it http://www.stellman-greene.com

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 http://www.stellman-greene.com

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 http://www.stellman-greene.com

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 http://www.stellman-greene.com

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 http://www.stellman-greene.com

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, O’Reilly 2005. http://www.stellman-greene.com

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 http://www.stellman-greene.com

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 http://www.stellman-greene.com

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 http://www.stellman-greene.com

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 http://www.stellman-greene.com

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 http://www.stellman-greene.com

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 http://www.stellman-greene.com

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 http://www.stellman-greene.com

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 http://www.stellman-greene.com

Risk Plan Example http://www.stellman-greene.com