Chapter 11, Project Management

Object-Oriented Software Engineering
Conquering Complex and Changing Systems
Chapter 11, Project Management
Outline

Concepts and terminology Purpose of Software Project Management Plans Structure of a Project Management Plan Project responsibilities Team structures Project planning Work breakdown structure Communication Management Dependencies Schedule Project Management Tools
Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2
Bernd Bruegge & Allen Dutoit
Reference:
Bruegge&Dutoit, Chapter 12
http://notesbruegge.in.tum.de/PAID2/schedule/ProjectManagement011599.pdf
What is not covered in this lecture?

Communication Management, Meeting Management Bruegge & Dutoit, Chapter 4
http://notesbruegge.in.tum.de/PAID2/schedule/ProjectCommunication112598.pdf
Cost estimation
Reference: Software engineering economics, Barry Boehm, Prentice Hall 1981
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
Laws of Project Management
Projects progress quickly until they are 90% complete. Then they remain at 90% complete forever. When things are going well, something will go wrong. When things just cant get worse, they will. When things appear to be going better, you have overlooked something. If project content is allowed to change freely, the rate of change will exceed the rate of progress. Project teams detest progress reporting because it manifests their lack of progress.
How it should go
Requirements Analysis Design
Implementation
System Testing
Delivery and Installation
How it often goes

Requirements Analysis
D E L A Y Vaporware
6
Software Project Management Plan
Software Project:
All technical and managerial activities required to deliver 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:

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. SPMP may be part of project agreement.
Project Agreement
Document written for a client that defines:

the scope, duration, cost and deliverables for the project. the exact items, quantities, delivery dates, delivery location.
Can be a contract, a statement of work, a business plan, or a project charter. Client: Individual or organization that specifies the requirements and accepts the project deliverables. Deliverables (= Work Products that will be delivered to the client):
Documents Demonstrations of function Demonstration of nonfunctional requirements Demonstrations of subsystems
Project Agreement vs Problem Statement

Client (Sponsor) Manager Project Team
Problem Statement Project Agreement

Software Project Management Plan
Project Management Activities (continued on next slide)

Initiation Problem statement definition
Initial top-level design
Initial milestones planning
Team formation
Communication infrastructure setup
Project kickoff
10
Project kickoff Steady state
Status monitoring
Risk management
Project replanning
Project agreement
Termination
Installation
Client acceptance test
Postmortem
11
Project: Functions, Activities and Tasks

f1:Function p:Project f2:Function
a1:Activity
a2:Activity
a3:Activity
a2.1:Activity
a2.2:Activity
a2.3:Activity
t1:Task
t2:Task
t3:Task
t4:Task
12
Functions
Activity or set of activities that span the duration of the project

a1:Activity
a2:Activity
a3:Activity
a2.1:Activity
a2.2:Activity
a2.3:Activity
t1:Task
t2:Task
t3:Task
t4:Task
13
Functions
Examples:
Project management Configuration Management Documentation Quality Control (Verification and validation) Training
Question: Is system integration a project function?

Mapping of terms: Project Functions in the IEEE 1058 standard are called Integral processes in the IEEE 1074 standard. We call them cross-development processes
14
Tasks
f1:Function
p:Project f2:Function
a1:Activity
a2:Activity
Smallest unit of work subject to management
a2.1:Activity
a2.2:Activity
Small enough for adequate planning and tracking

Large enough to avoid micro management
15
t1:Task
t2:Task
t3:Task
Tasks
Smallest unit of management accountability

Atomic unit of planning and tracking Finite duration, need resources, produce tangible result (documents, code)
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.
16
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 activity identifies more tasks and modifies existing ones
Tasks must be decomposed into sizes that allow monitoring

Work package usually corresponds to well defined work assignment for one worker for a week or a month. Depends on nature of work and how well task is understood.
17
Examples of Tasks

Unit test class Foo Test subsystem Bla Write user manual Write meeting minutes and post them Write a memo on NT vs Unix Schedule the code review Develop the project plan Related tasks are grouped into hierarchical sets of functions and activities. Action item
18
Action Item

Definition: A task assigned to a person that has to be done within a week or less Action items
Appear on the agenda in the Status Section (See lecture on communication) Cover: What?, Who?, When?
Example of action items:

Florian unit tests class Foo by next week Marcus develops a project plan before the next meeting Bob posts the next agenda for the Simulation team meeting before Sep 10, 12noon. The VIP team develops the project plan by Sep 18
19
Activities
a1:Activity
a2:Activity
Major unit of work with precise dates Consists of smaller activities or tasks
a2.1:Activity
a2.2:Activity
t1:Task
t2:Task
t3:Task
Culminates in project milestone.

20
Activities

Major unit of work Culminates in major project milestone:

Internal checkpoint should not be externally visible Scheduled event used to measure progress
Activities may be grouped into larger activities:

Establishes hierarchical structure for project (phase, step, ...) Allows separation of concerns Precedence relations often exist among activities (PERT Chart)
Milestone often produces baseline:

formally reviewed work product under change control (change requires formal procedures)
21
Examples of Activities
Major Activities:
Planning Requirements Elicitation Requirements Analysis System Design Object Design Implementation System Testing Delivery
Activities during requirements analysis:

Refine scenarios Define Use Case model Define object model Define dynamic model Design User Interface
22
Structure of a Software Project Management Plan

Front Matter 1. Introduction 2. Project Organization 3. Managerial Process 4. Technical Process 5. Work Elements, Schedule, Budget Optional Inclusions
23
SPMP Part 0: Front Matter

Title Page Revision sheet (update history) Preface: Scope and purpose Tables of contents, figures, tables
24
SPMP Part 1: Introduction

1.1 Project Overview
Executive summary: description of project, product summary
1.2 Project Deliverables

All items to be delivered, including delivery dates and location
1.3 Evolution of the SPMP

Plans for anticipated and unanticipated change
1.4 Reference Materials

Complete list of materials referenced in SPMP
1.5 Definitions and Acronyms
25
SPMP Part 2: Project Organization

2.1 Process Model
Relationships among project elements
2.2 Organizational Structure

Internal management, organization chart
2.3 Organizational Interfaces

Relations with other entities
2.4 Project Responsibilities

Major functions and activities; nature of each; whos in charge
26
Process Model
Shows relationships among

Functions, activities, tasks Milestones Baselines Reviews Work breakdown structure Project deliverables Sign-offs
Visualization of process model Project Management Aids

MS Project (Microsoft) MAC Project (Claris) EasyTrak (Planning Control International)
27
Example of an Organization Chart
Client
Management
Consultants
Cross-functional Teams
Development Teams
Architecture HCI Web Master Documentation Configuration Mgt
Logbook Maintenance Vehicle Travel VIP
Infrastructure Team
28
Project Roles

Planner Analyst Designer Programmer Tester Maintainer Trainer Document Editor Web Master Configuration Manager
Group leader Liaison Minute Taker Project Manager
29
Project Roles
Management roles
Organization and execution of the project within constraints. Examples: project manager, team leader.
Development roles
Specification, design and construction of subsystems. Examples: Analyst, system architect, implementor.
Cross functional roles

Coordination of more than one team. Example: API Engineer, configuration manager, tester
Consultant roles
Support in areas where the project participants lack expertise. Examples: End user, client, application domain specialist ( problem domain), technical consultant (solution domain).
Promoter roles
Promote change through an organization.
Promoter Roles

Promoters are self appointed individuals who identify themselves with the outcome of the project. They are member of the corporate organization and may not necessarily be directly involved with the project. Instead, they are interfaces to the rest of the corporate organization. Because of the power, knowledge of technology, or familiarity with the projects processes, they are able to promote and push specific changes through the organization.
31
Power Promoter

Also called executive champion Pushes the change through the existing organizational hierarchy. not necessarily at the top of the organization, but must have protection from top level management, otherwise project opponents might be able to prevent the success of the project. Tasks: constantly identify difficulties, resolve issues, and communicate with the project members, especially with the developers. Example at project level: Project Manager. Example at corporate level: Chief Executive Officer (CEO).
32
Knowledge Promoter

Also called the technologist, Promotes change arising in the application domain or the solution domain. Usually associated with the power promoter. Tasks: Acquire information iteratively, understand the benefits and limitations of new technologies, and argue its adoption with the other developers. Example at project level: System architect.
Reports to project manager Does not have any direct subordinate in the reporting hierarchy Has final say over all technical decisions in the system.
Example at corporate level: Chief Technical Officer (CTO).
33
Process Promoter

The process promoter has intimate knowledge of the projects processes and procedures. The process promoter is in constant interaction with the power promoter to get consensus on the overall goals. Tasks: Bridge between the power and knowledge promoters, who often do not speak or understand the same language. Example at project level: Development lead. Responsible for the administrative aspects of a project, including planning, milestones definition, budgeting and communication infrastructure. Example at corporate level: Chief Information Officer (CIO
34
Project Management: Hierarchical Project Organization

Control Flow Information Flow
Chief Executive First Level Manager (Front-Line Manager)
Project Members
A wants to talk to B: Complicated Information Flow A wants to make sure B does a certain change: Complicated Controlflow
Basis of organization: Complicated information and control flow across hierarchical boundaries
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 35
Example of Hierchical Organization: Chief Programmer Team

Chief Programmer
Assistant Chief Programmer
Senior Programmer
Librarian
Administration
Tester
Junior Programmer
36
Another Project Organization: Egoless Programming Team (Weinberg)

Analyst
Tester
Programmer
Designer
Librarian
37
Project-Based Project Organization

Project Leader Coaches Subsystem Team A Subsystem Team Subsystem Team B Team Members
A wants to talk to B: Communication Flow A wants to make sure B does a certain change: Decision Flow
Basis of organization: Nonlinear information flow across dynamically formed units

Associations in organizational structures

Reporting association:
Used for reporting status information
Decision association
Used for propagating decisions
Communication association
Used for exchanging information needed for decisions (e.g., requirements, design models, issues).
39
Observations on Management Structures
Hierarchical structures
Reports, Decides and Communicates-With all mapped on the same association Do not work well with iterative and incremental software development process Manager is not necessarily always right
Project-based structures
Reports, Decides and Communicates-Withare different associations Cut down on bureaucracy reduces development time Decisions are expected to be made at each level Hard to manage
40
Hierarchical Structure
Projects with high degree of certainty, stability, uniformity and repetition.

Requires little communication Role definitions are clear
When?
The more people on the project, the more need for a formal structure Customer might insist that the test team be independent from the design team Project manager insists on a previously successful structure
41
Project-Based Structure
Project with degree of uncertainty

Open communication needed among members Roles are defined on project basis
When?
Requirements change during development New technology develops during project
42
Assigning Responsibilities To People

Team A To Do List for the Project Item 1 Item 2 Role 1 Item 1 Item 2 Item 9 Role 2 Item 4 Item 5 Item 7 Person A Role 1 Role 2
Item 3 Item 4
Item 5 Item 6 Item 7 Item 8 Item 9
Person B
Role 3 Item 3 Item 6 Item 8
Role 3
43
Possible Mappings of ToDos to People

One-to-One
Ideal but often not worth to be called a project
Many-to-Few
Each project member assumes several roles ("hats") Danger of overcommittment Need for load balancing
Many-to-"Too-Many"
Some people don't have significant roles Bystanders Loosing touch with project
44
Team Formation
Top level Design

Rough Subsystem Decomposition (before requirements analysis) Done during Predevelopment phase
Team Formation done after Top Level Design Heuristics:

One team for each subsystem One cross-functional task per team 5-7 members per team
Be prepared to iterate the team formation after system design when the subsystem decomposition is baselined
45
Project Roles: Coach

Listen to gripes from individual teams Review weekly team reports Attend weekly project meetings Schedule and prepare meetings with client Insist that guidelines are followed Assign presentations (in-class project meetings, client review, client acceptance test) Resolve conflicts if they cannot be resolved otherwise
46
Project Role: Group leader
Responsible for intra-group communication (Meeting Management: Primary Facilitator)

Run the weekly project meeting Post agenda before meeting Define and keep track of action items (who, what, when) Measure progress (Enforce milestones) Deliver work packages for the tasks to the project management Present problems and status of team to project manager
The group leader has to be rotated among members of the team.
47
Group Leader: Create an Agenda

Purpose of Meeting Desired Outcome Information Sharing Information Processing Meeting Critique
Action Items (Check Previous Meeting)
Issues (Check Previous Meeting & BBoards)

Project Role: Liaison
Responsible for inter-group communication

Make available public definitions of subsystem developed by the team to the architecture teams (ensure consistency, etc) Coordinate tasks spanning more than one group with other teams
Responsible for team negotiations Examples: API Engineer, Configuration manager
49
Project Role: Planner

Plans and tracks the activities of an individual team and has the following responsibilities. Define project plan for team:
PERT chart, resource table and GANTT chart showing work packages Enter project plan into project management tool
Make project plan available to management Report team status to project manager No explicit planner in PAID. Responsibilities assumed by coaches
50
Project Role: Document Editor

Collect, proofread and distribute team documentation Submit team documentation to architecture team Collect agendas Take minutes at meetings
51
Web Master

Maintain team home page Keep track of meeting history Keep track of design rationale
52
Web Master:
Publish Meeting Information on Team Homepage

Must contain Agenda, minutes, action items and issues Possibilities:
One HTML document per meeting, with anchors (maintained by one role) Separate HTML documents for Agenda, Minutes, etc (maintained by several roles) Agenda Agenda Agenda Minutes Minutes Minutes Action Items Action Items Action Items Issues Issues Issues
Date 9/9/96 9/16/96
http://cascade1.se.cs.cmu.edu/ 15-413/homePagesTeams/UserInterface/www/index.htm
SPMP Part 3: Managerial Processes

3.1 Management Objectives and Priorities
Philosophy, goals and priorities
3.2 Assumptions, Dependencies, Constraints

External factors
3.3 Risk Management

Identifying, assessing, tracking, contingencies for risks
3.4 Monitoring and Controlling Mechanisms

Reporting mechanisms and formats, information flows, reviews
3.5 Staffing Plan

Needed skills (what?, how much?, when?)
54
Examples of Assumptions

There are enough cycles on the development machines Security will not be addressed There are no bugs in Together-J, the CASE Tool recommended for the project A demonstration of the Starnetwork system will be given by the client
55
Examples of Dependencies

The database team depends on the EPC database provided by DaimlerChrysler The automatic code generation facility in the CASE tool depends on JDK. The current release of Together-J supports only JDK 1.1.6
56
Examples of Constraints

The length of the project is 3 months. limited amount of time to build the system The project consists of beginners. It will take time to learn how to use the tools Not every project member is always up-to-date with respect to the project status The use of UML and a CASE tool is required Any new code must be written in Java The system must use Java JDK 1.1.6
57
Risk Management
Risk: Members in key roles drop the course.

Contingency: Roles are assigned to somebody else. Functionality of the system is renegotiated with the client.
Risk: One subsystem does not provide the functionality needed by another subsystem.
Contingency: ?
Risk: The project is falling behind schedule.

Contingency: Extra project meetings are scheduled.
Risk: Ibutton runs only under JDK 1.2

Contingency: ?
58
SPMP Part 4: Technical Process

4.1 Methods, Tools and Techniques
Computing system, development method, team structure, etc. Standards, guidelines, policies.
4.2 Software Documentation

Documentation plan, including milestones, reviews and baselines.
4.3 Project Support Functions

Plans for functions (quality assurance, configuration management).
59
SPMP Part 5: Work Elements

5.1 Work Packages (Work breakdown structure)
Project decomposed into tasks; definitions of tasks
5.2 Dependencies
Precedence relations among functions, activities and tasks
5.3 Resource Requirements

Estimates for resources such as personnel, computer time, special hardware, support software.
5.4 Budget and Resource Allocation

Connect costs to functions, activities and tasks.
5.5 Schedule
Deadlines, accounting for dependencies, required milestones
60
Creating Work Packages
Work Breakdown Structure (WBS) (Section 5.1)

Break up project into activities (phases, steps) and tasks. The work breakdown structure does not show the interdependence of the tasks
The identification of the work breakdown structure is an instance of object identification and associating these objects
61
WBS Trade-offs

Work breakdown structure influences cost and schedule Thresholds for establishing WBS in terms of percentage of total effort:
Small project (7 person-month): at least 7% or 0.5 PM Medium project (300 person-month): at least 1% or 3 PMs Large project (7000 person-month): at least 0.2 % or 15 PMs
Determination of work breakdown structure is incremental and iterative

WBS Schedule
Source: Software Engineering Economics, Barry W. Boehm p. 47, Prentice Hall, N.J., 1981
Cost
(Time, $$)
62
Dependencies and Schedule (SPMP Section 5.2 + 5.5)

An important temporal relation: must be preceded by Dependency graphs show dependencies of the tasks (hierarchical and temporal)
Activity Graph:

Nodes of the graph are the project milestones Lines linking the nodes represent the tasks involved
Schedule Chart (MS-Project):
Nodes are tasks and milestones Lines represent temporal dependencies
Estimate the duration of each task Label dependency graph with the estimates
63
Project Management Tools for Work Packages
Visualization Aids for Project Presentation

Graphs (Schedule), Trees (WBS) Tables (Resources)
Task Timeline
Gantt Charts: Shows project activities and tasks in parallel. Enables the project manager to understand which tasks can be performed concurrently.
Schedule Chart (PERT Chart)

Cornerstone in many project management tools Graphically shows dependencies of tasks and milestones
PERT: Program Evaluation and Review Technique A PERT chart assumes normal distribution of tasks durations Useful for Critical Path Analysis CPM: Critical Path Method
Project: Building a House
Activity 1: Landscaping the lot Task 1.1: Clearing and grubbing Task 1.2: Seeding the Turf Task 1.3: Planting shrubs and trees Activity 2: Building the House Activity 2.1 : Site preparation Activity 2.2: Building the exterior Activity 2.3: Finishing the interior Activity 2.1 : Site preparation Task 2.1.1: Surveying Task 2.1.2: Obtaining permits Task 2.1.3: Excavating Task 2.1.4: Obtaining materials
Activity 2: Building a House, ctd
Activity 2.2: Building the exterior Task 2.2.1: Foundation Task 2.2.2: Outside Walls Task 2.2.3: Exterior plumbing Task 2.2.4: Exterior electrical work Task 2.2.5: Exterior siding Task 2.2.6: Exterior painting Task 2.2.7: Doors and Fixtures Task 2.2.8: Roof
Activity 2.3 : Finishing the Interior Task 2.3.1: Interior plumbing Task 2.3.2: Interior electrical work Task 2.3.3: Wallboard Task 2.3.4: Interior painting Task 2.3.5: Floor covering Task 2.3.6: Doors and fixtures
66
Activity Graph for Activity Building a House

STAR T Build Outside Wall 1.2 1.1 1.3 Buy Materials 1.4 Lay Foundation 2.1 Build Outside Install Exterior Plumbing 2.3 Install Exterior Electrical 2.4 Install Exterior Siding 2.5 Paint Exterior 2.6 Install Exterior Doors 2.7 Install Flooring Install Roo ng 2.8 2.6
Surveying Excavation
Wall
2.2
Install Interior P lumbing 3.1 Install Interior Elec tric al 3.2 Install Wallboard 3.3 3.4 3.6 Paint Interior 3.5 Install Interior Doors
FINISH
67
PERT Chart Example for "Building a House"

12/3/94 12/21/94 Install Interior Plumbing 1/11/95 Install Wallboard 1/22/95 Paint Interior 0 11 1/22/95 Install Flooring 8/27/94 8/27/94 START 0 0 8/27/94 Request Permits 0 15 12/3/94 Start Time 8/29/94 Legend Slack Time Duration
Building a House:
MS Project PERTcy Chart with Duration of Activities (Pfleeger 2.3)
0 12
Install Interior Electrical
0 15
0 9
2/8/95 Install Interior Doors 0 7
9/17/94 Survey ing
10/1/94 Excava tion
10/15/94
Buy Material
11/5/94 Lay Founda tion Build Outside Wall 0 20 1/19/95
0 18 Install Roofing 1/19/95
2/16/95 FINISH
12 3
0 10
0 10
0 15
12 9 1/12/95 Paint Exterior 12 5 12/17/94 12/31/94 15 6
0 Install 0 Exterior Doors
Install Exterior Plumbing 12 10 12 10
Install Exterior Electrical

12 8
Install Exterior Siding
0 0
68
Slack Time and Critical Path
Slack Time
Available Time - Estimated (Real) Time for a task or activity Or: Latest Start Time - Earliest Start Time
Critical Path
The path in a project plan for which the slack time at each task is zero.
The critical path has no margin for error when performing the tasks (activities) along its route.
69
How do you become a good project planner?

Establish a project plan

Start with the plan based on your experience with the last project(s)
Keep track of activities and their duration Determine difference between planned and actual performance Make sure to do a post-mortem
Lessons learned Ask developers for feedback Write a document about what could have been improved
70
Writing the SPMP

Example full SPMPs OWL project

http://cascade1.se.cs.cmu.edu/15-413/courseDocs/spmpF96.html
JAMES project
http://cascade1.se.cs.cmu.edu/JAMES/J_courseDocs/SPMP/SPMP1. 0.html
71
Project Management Heuristics

Make sure to be able to revise or dump a project plan

Complex system development is a nonlinear activity
If project goals are unclear and complex use team-based project management. In this case
Avoid GANTT charts and PERT charts for projects with changing requirements Dont look too far into the future
Avoid micro management of details Dont be surprise if current project management tools dont work:
They were designed for projects with clear goals and fixed organizational structures
72
Project Management Summary
Get agreement among customers, managers and teams

Problem statement Software project management plan Project agreement Make sure agreement allows for iteration
Organization Structures SPMP Project planning

Start with work breakdown structure (WBS) Identify dependencies and structure: Tasks, activities, functions
Tools and Techniques

GANTT, Dependency graph, Schedule, Critical Path Analysis Be careful with tools in projects with a lot of change
73

Chapter 11, Project Management

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Chapter 11, Project Management

Caricato da

Copyright:

Formati disponibili

Object-Oriented Software Engineering

Conquering Complex and Changing Systems

Chapter 11, Project Management

Bernd Bruegge & Allen Dutoit

What is not covered in this lecture?

Reference: Software engineering economics, Barry Boehm, Prentice Hall 1981

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Laws of Project Management

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Delivery and Installation

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

How it often goes

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Software Project Management Plan

Software Project Management Plan:

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Document written for a client that defines:

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Project Agreement vs Problem Statement

Problem Statement Project Agreement

Software Project Management Plan

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Project Management Activities (continued on next slide)

Initial top-level design

Initial milestones planning

Communication infrastructure setup

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Project kickoff Steady state

Client acceptance test

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Project: Functions, Activities and Tasks

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Activity or set of activities that span the duration of the project

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Question: Is system integration a project function?

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Smallest unit of work subject to management

Small enough for adequate planning and tracking

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Smallest unit of management accountability

Specification of a task: Work package

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Finding the appropriate task size is problematic

Tasks must be decomposed into sizes that allow monitoring

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Example of action items:

Bernd Bruegge & Allen Dutoit