Software Engineering II - Exercise

Size: px

Start display at page:

Download "Software Engineering II - Exercise"

Maria Wilson
6 years ago
Views:

1 Software Engineering II - Exercise April 29 th 2009 Software Project Management Plan Bernd Bruegge Helmut Naughton Applied Software Engineering Technische Universitaet Muenchen 1

2 Date for the final exam To be determined next week 2

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 3

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. 4

5 Project: Functions, Activities and Tasks A project has a duration and consists of project functions, activities and tasks Project Function Function Activity Activity Activity Activity Activity Activity Task Task Task Task UML 5

6 Tasks, Activities and Project Functions (UML Class Diagram) duration Project duration Work * Task Activity Project Function «invariant» duration = project.duration 6

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) Project Function Function Activity Activity Activity Activity Activity Activity Task Task Task Task 7

8 Examples of Project Functions Configuration Management Documentation Quality Control (V&V: verification and validation) Training Testing Project management activities UML 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. 8

9 Tasks Project Function Function Activity Activity Activity Activity Activity Activity Task Task Task Task Smallest unit of work subject to management Small enough for adequate planning and tracking Large enough to avoid micro-management 9

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. 10

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 11

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, 12 th, noon The test team develops the test plan by Sep 18 th Action items should be reviewed regularly (at least once a week) Status section in the meeting agenda. 12

Major unit of work with precise dates Consists of

13 Activities Project Function Function Activity Activity Activity Activity Activity Activity Task Task Task Task Major unit of work with precise dates Consists of smaller activities or tasks Culminates in project milestone. 13

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 14

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 15

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. 16

17 IEEE Std : 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 17

18 Project Agreement, Problem Statement, SPMP Client (Sponsor) Project Manager Project Team Problem Statement Project Agreement Software Project Management Plan (SPMP) 18

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 19

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

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 in the textbook is out of date 21

22 SPMP: Front Matter Title page Signature page Change history Preface Table of contents List of figures List of tables 22

23 SPMP Clause 1: Overview 1.1 Project Summary Purpose, scope and objectives Concise summary of purpose, scope and objectives, integration with other projects, reference to requirements etc Assumptions and constraints Schedule, budget, resources, software to be reused/incorporated, technology to be employed, interfaces to other products Project deliverables List of work items with delivery dates, locations and quantities (also includes delivery media and packaging & handling) Schedule and budget summary Only itemization of major work activities here 1.2 Evolution of the SPMP Plans for anticipated and unanticipated change 23

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 24

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. 25

26 SPMP Clause 5: Managerial process plans 5.1 Start-up plan Estimation plan Cost and schedule with estimation methods, tools and techniques Staffing plan Number of staff by required skill level, phase, duration. Staff sources Resource acquisition plan Resource acquisition process for equipment, training, transportation, facilities etc 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. 26

27 SPMP Clause 5: Managerial process plans 5.2 Work plan Work activities Work breakdown structure with work packages detailing needed resources, estimated duration, work products to be produced, predecessor, successor, etc Schedule allocation Depicts time-sequencing constraints and opportunities for concurrency. Techniques include Gantt and PERT charts etc Resource allocation Detailed itemization of resources allocated to each major work activity. This includes personnel, tools, facilities, administrative support etc Budget allocation Breakdown of necessary resource budgets for each major work activity. Costs for personnel, travel, meetings, tools, etc. 27

28 SPMP Clause 5: Managerial process plans 5.3 Control plan Requirements control plan Controls changes to project requirements Schedule control plan Measure progress of work completed and corrective measures Budget control plan Measure cost of work completed and comparison with budget Quality control plan Quality control mechanisms (v&v, reviews, audits, etc.) Reporting plan Reporting mechanisms, format, information flows Metrics collection plan Methods, tools and techniques for collecting and retaining project metrics. 28

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. 29

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. 30

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 31

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. 32

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. 33

34 Observations about planning What type of model does the template defined by IEEE 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] 34

35 Readings Information on topics covered today Bruegge/Dutoit, Chapter 14: Project Management Standard for Software Project Management Plans [IEEE Std ] 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,

36 Homework Task: Choose a large software project and write an SPMP for that project based on IEEE 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 1 st 2009, 2PM 36

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 37

38 Example 1: Heathrow Terminal 5 38

39 Example 2: Airbus A380 39

40 Example 3: Toll collect 40

41 Example 4: Dolli (2) 41

42 Homework Task: Choose a large software project and write an SPMP for that project based on IEEE 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 1 st 2009, 2PM Oral presentation of these plans on July 1 st 2009 in the exercise session 42

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. 43

Software project management. ITNP090 Object Oriented Software Design. Management activities. Software Management Challenges

Software project management. ITNP090 Object Oriented Software Design. Management activities. Software Management Challenges Software project management ITNP090 Object Oriented Software Design Dr Andrea Bracciali Module Co-ordinator 4B86 abb@cs.stir.ac.uk Concerned with activities involved in ensuring that software is delivered