Management

Initially this page will be a compilation of three parts of old notes:

• Rationale Management
• Configuration Management
• Project Management

In time it will be trimmed down, reorganized, and made more succinct.

Rationale Management

References:

1. Bernd Bruegge and Allen H. Dutoit, "Object-Oriented Software Engineering", Third Edition, Chapter 12

An Overview of Rationale

Rationale captures the motivation behind a decision, and may include :

• The issue to be decided
• Alternatives that were considered
• The criteria used to judge alternatives
• Argumentation for and against various alternatives
• Decisions made as a result of discussions

Rationale Concepts

Example: Centralized Traffic Control

This running example is based on a centralized traffic control system for a railroad. The following figure shows the user interface from the pre-existing system:

Defining the Problem: Issues

Exploring the Solution Space: Proposals

Evaluating the Solution Space: Criteria and Arguments

Collapsing the Solution Space: Resolutions

Implementing Resolutions: Action Items

Examples of Issue-Based Models and Systems

There are many systems that have been proposed for managing rationale, most using similar concepts, some as commercial products.

Issue-Based Information System, IBIS

Decision Representation Language

Questions, Options, and Criteria

The NFR Framework

Rationale Activities: From Issues to Decisions

CTC System Design

Capturing Rationale in Meetings

The agenda for this meeting calls for the discussion of three issues, key of which is determining the access control policy, and how it is to be integrated with the notification service. ( The latter allows an operator to see what is happening on a given section of track. )

During the meeting three different proposals were presented and discussed, as shown here in the chronological minutes and in the following three design diagrams.

Structured minutes have the same information as the chronological meetings, but reorganized to make related items clearer to follow:

Capturing Rationale Asynchronously

Capturing Rationale when Discussing Change

Reconstructing Rationale

Managing Rationale

A manager is responsible for the following activities with respect to rationale management.

Documenting Rationale

Assigning Responsibilities

• Minute Taker
• Rationale Editor
• Reviewer
• Heuristics:
  • One minute taker per team
  • One rationale editor per project
  • Increase number of reviewers after delivery. ( Reassign developers while rationale is still fresh in their heads. )

Heuristics for Communicating about Rationale

• Name issues consistently
• Centralize issues
• Cross-reference issues and system elements
• Manage change

Issue Modeling and Negotiation

The Harvard method for negotiation tries to reduce antagonism by the following heuristics:

• Separate developers from proposals. A judgement about a proposal should not be seen as a judgement of the developer who made it.
• Focus on criteria, not proposals. Once everyone can agree on criteria, the criteria will determine the best proposal.
• Take into account all criteria, instead of maximizing a single one.

Conflict Resolution Strategies

Five Examples:

1. Majority wins
2. Owner has last word
3. Management is always right
4. Expert is always right
5. Time decides

Configuration Management

References:

1. Bernd Bruegge and Allen H. Dutoit, "Object-Oriented Software Engineering", Third Edition, Chapter 13

A lot of this section is based on a running example of an aircraft with multiple configurations, mostly differing by the length of their fuselage. The controls are "fly by wire", a.k.a. "virtual cockpit" or "virtual control panel", with the goal that each configuration fly the same way, to minimize cross training costs.

Configuration Management Concepts

Configuration Items and CM Aggregates

Promotions and Releases

• Promotions are put forth by developers for use by other developers, but not released to the general public.
• Releases have been much more thoroughly tested, and are made available to clients.

Repositories and Workspaces

• Repositories are central storage locations where "the company" stores completed versions of artifacts.
• Workspaces refer to the working directories where individual programmers store the files they are currently working on.

Versions and Variants

• Versions are generally intended to replace earlier versions.
• Variants are intended to remain permanently different, "in parallel" to other variants.

Version Identification Schemes

Changes and Change Sets

Configuration Management Tools

Configuration Management Activities

This running example is a tool for ordering parts from a parts dealer. Experts ( e.g. auto mechanics ) know exactly the parts they need, but novices ( e.g. laymen working on their own cars ) need more help and guidance.

Configuration Item and CM Aggregate Identification

Note that some items can be part of more than one aggregate.

( Source code, Test Materials, and Testing Manual omitted for brevity. )

Promotion Management

Different workspaces may have different versions of some items. Typically an older more stable version of code that other groups are developing, and the latest code under development for the code that this group is currently working on.

Release Management

Branch Management

• Most branches are temporary, with the intention of merging them back into the main branch once they are completed and tested.

Variant Management

• Variants are intended to remain permanently separated, which raises different issues.

Change Management

Managing Configuration Management

A manager is responsible for the following activities with respect to configuration management.

Documenting Configuration Management

Assigning Configuration Management Responsibilities

Planning Configuration Management Activities

Continuous Integration: Testing and Promotion Management

Project Management

References:

1. Bernd Bruegge and Allen H. Dutoit, "Object-Oriented Software Engineering", Third Edition, Chapter 14

An Overview of Project Management

Project Management Concepts

Tasks and Activities

Work Products, Work Packages, and Roles

Work Breakdown Structure, WBS

Task Model

• Critical Path Analysis from Wikipedia

Skill Matrix

The Software Project Management Plan

Classical Project Management Activities

Planning the Project

Developing the problem statement

Defining the top-level design

Identifying the work breakdown structure

Creating the initial schedule

Organizing the Project

Setting up the communication infrastructure

Identifying skills

Assigning management roles

Assigning technical roles

Dealing with skill shortages

Selecting team sizes

Assembling the teams

Kick-off meeting

Agreeing on project scope

Controlling the Project

Meetings

Metrics

Managing risk

14.4.4 - Terminating the Project

Accepting the system

Installation

Postmortem

14.5 - Agile Project Management Activities

14.5.1 - Planning the Project: Create Product and Sprint Backlogs

14.5.2 - Organizing the Project

14.5.3 - Controlling the Project: Daily Scrums and Burn Down Charts

14.5.4 - Terminating the Project: Sprint Reviews