1

Software Engineering II - Exercise

Bernd Bruegge Helmut Naughton

Applied Software Engineering Technische Universitaet Muenchen

http://wwwbrugge.in.tum.de

April 29th 2009

Software Project Management Plan

2

Date for the final exam

•  To be determined next week

3

Decision time

•  Can we reschedule exercises for WBS and Scheduling?

•  Change 1: WBS Exercise Wednesday May 27 -> Friday May 29, 14:00-15:30

•  Change 2: Scheduling Exercise Wednesday June 3 -> Friday June 5, 14:00-15:30

4

Basic Definitions: Project and Project Plan •  Software Project:

•  All technical and managerial activities required to turn over the deliverables to the client

•  A software project has a specific duration, consumes resources and produces work products

•  Management categories to complete a software project: •  Tasks, Activities, Functions

•  Software Project Management Plan (SPMP): •  The controlling document for a software project •  Specifies the technical and managerial approaches to

develop the software product •  Companion document to requirements analysis

document: Changes in either may imply changes in the other document

•  Also interdependent with the system design document •  The SPMP may be part of the project agreement.

5

Project: Functions, Activities and Tasks

UML

Function

Function Project

Activity

Task

Activity Activity

Activity Activity Activity

Task Task Task

A project has a duration and consists of project functions, activities and tasks

6

Tasks, Activities and Project Functions (UML Class Diagram)

Task

* Work

Activity

Project Function «invariant»

duration = project.duration

Project

duration

duration

7

Project Function Definition Project Function: An activity or set of activities that span the duration of the project (called Workflow in the Unified Process model)

Function

Function Project

Activity

Task

Activity Activity

Activity Activity Activity

Task Task Task

8

Examples of Project Functions

•  Configuration Management •  Documentation •  Quality Control (V&V: verification and validation) •  Training •  Testing •  Project management activities

Project functions in the IEEE 1058 standard (IEEE Standard for Software Project Management Plans) are called Integral processes in the IEEE 1074 standard (IEEE Standard for Developing a Software Project Life Cycle Process). Sometimes also called cross-development processes.

UML

9

Tasks

Function

Function Project

Activity

Task

Activity Activity

Activity Activity Activity

Task Task Task

•  Smallest unit of work subject to management •  Small enough for adequate planning and tracking •  Large enough to avoid micro-management

10

Tasks •  Smallest unit of management accountability

•  Atomic unit of planning and tracking •  Tasks have finite duration, need resources, produce tangible

result (documents, code, models) •  Specification of a task: Work package

•  Name, description of work to be done •  Preconditions for starting, duration, required resources •  Work product to be produced, acceptance criteria for it •  Risk involved

•  Completion criteria •  Includes the acceptance criteria for the work products

(deliverables) produced by the task.

11

Heuristics for Determining Task Sizes

•  Finding the appropriate task size is problematic

•  Todo lists from previous projects

•  During initial planning a task is necessarily large

•  You may not know how to decompose the problem into tasks at first

•  Each software development activitity identifies more tasks and modifies existing ones

•  Tasks must be decomposed into sizes that allow monitoring

•  Depends on nature of work and how well task is understood.

•  Work package should corresponds to a well defined work assignment for one participant for a week

12

Action Item •  Definition Action Item: A task assigned to a person (or in certain cases

a role) to be done by a certain time •  What?, Who?, When? •  Heuristics for Duration: be done within two week or a week

•  Definition Todo: An action item that is missing either the person/role or the deadline

•  Examples of todos: •  “Unit test class Foo”, “Develop the project plan for our project”.

•  Example of action items: •  “Bob posts the next agenda for the context team meeting before May, 12th,

noon” •  “The test team develops the test plan by Sep 18th”

•  Action items should be reviewed regularly (at least once a week) •  Status section in the meeting agenda.

13

Activities

Function

Function Project

Activity

Task

Activity Activity

Activity Activity Activity

Task Task Task

• Major unit of work with precise dates • Consists of smaller activities or tasks • Culminates in project milestone.

14

Activities

•  Major unit of work •  Culminates in major project

milestone: •  Internal checkpoint (not be

externally visible) •  External checkpoint,

synchronization with the client •  Scheduled event used to

measure progress •  A milestone often produces a

project baseline: •  Formally reviewed work product •  Under change control (change

requires formal procedures)

•  Activitites may be grouped into larger activities:

•  Establishes hierarchical structure for project (phase, step, ...)

•  Allows separation of concerns •  Precedence relations often

exist among activities

15

Work package, Product, Baseline, Deliverable

•  Work Package: •  A specification for the work to be accomplished in an activity or task

•  Work Product: •  Any tangible item that results from a project function, activity or task.

•  Project Baseline: •  A work product that has been formally reviewed and agreed upon. •  A project baseline can only be changed through a formal change

procedure •  Project Deliverable:

•  A work product to be delivered to the customer

16

Project Agreement (in traditional management approaches)

•  Project Agreement: In traditional management, the document written for a client that defines:

•  the scope, duration, cost and deliverables for the project. •  the exact items, quantities, delivery dates, delivery location.

•  Client: Individual or organization that specifies the requirements and accepts the project deliverables.

•  Deliverables: Work Products to be delivered to the client •  Documents •  Demonstrations of functions •  Demonstration of nonfunctional requirements •  Demonstrations of subsystems

•  The form of a project agreement can be a contract, a statement of work, a business plan, or a project charter.

17

IEEE Std 1058-1998: Standard for Software Project Management Plans (SPMP)

•  What it does: •  Specifies the format and contents of software project

management plans. •  It provides a standard set of abstractions for a project manager

or a whole organization to build its set of practices and procedures for developing software project management plans

•  Abstractions: Project, Function, Activities, Tasks

•  What it does not do: •  It does not specify the procedures or techniques to be used in

the development of the plan •  It does not provide examples

18

Project Agreement, Problem Statement, SPMP

Client (Sponsor) Project Manager Project Team

Project Agreement

Problem Statement Software Project

Management Plan (SPMP)

19

Pros and Cons of Project Plans

•  Advantages: •  Very useful to kick off a software project (to establish the goals,

organize the teams, and start with development) •  Useful also for software projects if the outcome is predictable

or when no major change occurs.

•  Disadvantages: •  Of limited value to control software project when the outcome is

unpredictable or when unexpected (“unusual”) events occur in the project that change the project context.

•  Examples of unexpected events: •  Appearance of new technology which was unknown at project

start. •  A visionary scenario turns out to be not implementable •  Company is merged with another one during the project

20

Project Documentation

•  Even in modern, agile project management styles, project documentation is important

•  Beneficiaries of well written documentation: •  The customer has a reference detailing the project to

be used for reviews or further projects •  The developing company can also use old project

documentation for planning future projects

•  Best practice: The Software Project Management Plan

IEEE Standard 1058-1998

http://standards.ieee.org/reading/ieee/std_public/description/se/1058-1998_desc.html

21

Structure of a Software Project Management Plan (*)

Front Matter 1. Overview 2. References 3. Definitions 4. Project organization 5. Managerial process plans 6. Technical process plans 7. Supporting process plans 8. Additional plans Back Matter

(*) The template in figure 13-14 in the textbook is out of date

22

SPMP: Front Matter

•  Title page •  Signature page •  Change history •  Preface •  Table of contents •  List of figures •  List of tables

23

SPMP Clause 1: Overview

•  1.1 Project Summary •  1.1.1 Purpose, scope and objectives

Concise summary of purpose, scope and objectives, integration with other projects, reference to requirements etc.

•  1.1.2 Assumptions and constraints Schedule, budget, resources, software to be reused/incorporated, technology to be employed, interfaces to other products

•  1.1.3 Project deliverables List of work items with delivery dates, locations and quantities (also includes delivery media and packaging & handling)

•  1.1.4 Schedule and budget summary Only itemization of major work activities here

•  1.2 Evolution of the SPMP Plans for anticipated and unanticipated change

24

SPMP Clause 2 + 3: References + Definitions

•  2. References •  Complete list of all documents and other sources of information

references in the SPMP (has to include author, title, report number, date, author, path/name for electronic access and publisher etc.)

•  3. Definitions •  Define all terms and acronyms required to properly understand the

SPMP

25

SPMP Clause 4: Project organization

•  4.1 External interfaces •  Organizational boundaries between project and external

entities (parent, subcontractor, others…)

•  4.2 Internal structure •  Interfaces among the units of the software development team.

Interfaces between project and supporting entities. Lines of authority, responsibility and communication within a project.

•  4.3 Roles and responsibilities

•  State and nature of major work activities and support processes and organizational units responsible for them. Often depicted in matrix form.

26

SPMP Clause 5: Managerial process plans

•  5.1 Start-up plan •  5.1.1 Estimation plan

Cost and schedule with estimation methods, tools and techniques. •  5.1.2 Staffing plan

Number of staff by required skill level, phase, duration. Staff sources. •  5.1.3 Resource acquisition plan

Resource acquisition process for equipment, training, transportation, facilities etc.

•  5.1.4 Project staff training plan Types of training, number of personnel to be trained, entry and exit criteria for training, training method. Both for technical and managerial training.

27

SPMP Clause 5: Managerial process plans

•  5.2 Work plan •  5.2.1 Work activities

Work breakdown structure with work packages detailing needed resources, estimated duration, work products to be produced, predecessor, successor, etc.

•  5.2.2 Schedule allocation Depicts time-sequencing constraints and opportunities for concurrency. Techniques include Gantt and PERT charts etc.

•  5.2.3 Resource allocation Detailed itemization of resources allocated to each major work activity. This includes personnel, tools, facilities, administrative support etc.

•  5.2.4 Budget allocation Breakdown of necessary resource budgets for each major work activity. Costs for personnel, travel, meetings, tools, etc.

28

SPMP Clause 5: Managerial process plans

•  5.3 Control plan •  5.3.1 Requirements control plan

Controls changes to project requirements •  5.3.2 Schedule control plan

Measure progress of work completed and corrective measures •  5.3.3 Budget control plan

Measure cost of work completed and comparison with budget •  5.3.4 Quality control plan

Quality control mechanisms (v&v, reviews, audits, etc.) •  5.3.5 Reporting plan

Reporting mechanisms, format, information flows •  5.3.6 Metrics collection plan

Methods, tools and techniques for collecting and retaining project metrics.

29

SPMP Clause 5: Managerial process plans

•  5.4 Risk management plan •  Identify, analyze and prioritize project risk factors. Describe

procedures for contingency planning and methods for tracking risk factors.

•  5.5 Closeout plan

•  Staff reassignment, archiving project materials, post-mortem debriefing plan, preparation for lessons learned and analysis of project objectives archived.

30

SPMP Clause 6: Technical process plan

•  6.1 Process model •  Flow of information and work products among activities and

functions. Timing of deliverables, reviews, milestones etc.

•  6.2 Methods, tools and techniques •  Development methodologies, programming languages, tools

and techniques etc. to be used in the project.

•  6.3 Infrastructure plans •  Development environment (workstations, LAN, software tools

etc.). Also includes policies, procedures, standards etc.

•  6.4 Project acceptance plan

•  Objective criteria for determining acceptability of deliverables.

31

SPMP Clause 7: Supporting process plans

•  7.1 Configuration management plan •  Configuration accounting, control, status accounting,

evaluation, release management, change management etc.

•  7.2 Verification and validation plan •  Traceability, milestone review, progress review, peer review,

prototyping, simulation, modeling

•  7.3 Documentation plan •  Deliverable and non-deliverable documentation products

•  7.4 Quality assurance plan

•  Analysis, inspection, review, audit, assessment

32

SPMP Clause 7: Supporting process plans

•  7.5 Reviews and audits •  Schedule, resources, methods and procedures

•  7.6 Problem resolution plan •  Reporting, analyzing, prioritizing and processing software

problems

•  7.7 Subcontractor management plan •  Selecting and managing subcontractors

•  7.8 Process improvement plan •  Periodical assessment of the project to determine areas for

improvement and implementing improvement plans.

33

SPMP: Clause 8 & Back Matter

•  8. Additional plans •  Plans required to satisfy product requirements and contractual

terms (safety, privacy, security requirements, user training, integration, data conversion, system transition, maintenance etc.)

•  Back Matter • Annexes

•  Includes directly or by reference – provided supporting details that could detract from the SPMP if included in its body.

•  Index •  Index of key terms and acronyms.

34

Observations about planning

•  What type of model does the template defined by IEEE 1058-1998 represent?

•  Object model (UML class diagram) •  What is missing from an object model for

planning? •  Dynamic behavior - when do we do planning?

(UML sequence diagrams, activity diagrams and state machine diagrams)

•  Different approaches to planning: •  Traditional: Plan at the start of a project, then the plan is

fixed (at least for an iteration) [Royce, 1998] •  Transitional: Plan in parallel with the system design

(evolution of the architecture) [Paulish, 2002] •  Agile: Plan continuously during the project duration

(incremental and iterative refinement) [Cohn, 2006]

35

Readings

•  Information on topics covered today •  Bruegge/Dutoit, Chapter 14: Project Management •  Standard for Software Project Management Plans [IEEE

Std 1058-1998] •  Walker Royce, Software Project Management: A Unified

Framework, Addison-Wesley, 1998 •  Daniel J. Paulish, Architecture-Centric Software Project

Management: A Practical Guide, Addison-Wesley, 2002 •  Mike Cohn, Agile Estimating and Planning, Prentice Hall,

2006

36

Homework

•  Task: •  Choose a large software project and write an SPMP for

that project based on IEEE 1058-1998 •  Find (write) an (idealized) plan •  Do post-mortem analysis using information available

on the internet if necessary

•  You can work in teams with up to 6 participants •  Submission date is July 1st 2009, 2PM

37

If you cannot think of a suitable project

•  Organizing a hiking trip •  Organizing a wedding •  Organizing a reunion with your classmates •  Celebrating the end of SE II – POM

All of these are acceptable (even though they do not have anything to do with software engineering)

•  Or maybe you would like to take up a bigger challenge…

38

Example 1: Heathrow Terminal 5

39

Example 2: Airbus A380

40

Example 3: Toll collect

41

Example 4: Dolli (2)

42

Homework

•  Task: •  Choose a large software project and write an SPMP for

that project based on IEEE 1058-1998 •  Find (write) an (idealized) plan •  Do post-mortem analysis using information available

on the internet if necessary

•  You can work in teams with up to 6 participants •  Submission date is July 1st 2009, 2PM •  Oral presentation of these plans on July 1st 2009

in the exercise session

43

Summary •  Software engineering is a problem solving activity

•  Developing quality software for a complex problem within a limited time while things are changing

•  The system models addresses the technical aspects

•  Object model, functional model, dynamic model

•  Other models address the management aspects •  WBS, Schedule •  Task models, Issue models, Cost models

•  Important terms •  Software lifecycle, Project, Activity, Function, Task, WBS,

SPMP

•  This was an introduction to the managerial issues in software engineering

•  We will elaborate on many of these concepts in more detail as we go along through the lectures.