HistoryViewLinks to this page 2012 September 24 | 02:53 pm

Contents


Status

This document is a Working Draft.

Introduction

This scenario illustrates the Monitoring and Controlling use case. Refer to the EMS 1.0 Primer for other scenarios.

Monitoring and control is a key project management process. In this process, the development team selects a set of metrics to use to monitor the health and progress of the project. These metrics are often referred to as Key Performance Indicators (KPI). The team develops estimates for these metrics and measures them throughout the course of the project. Project managers (or team leads) monitor these measurements and compare them to the estimates. If the measurements differ significantly from the estimates, then the project manager must diagnose the root cause and take corrective action.

Overview

In Act 1 of this scenario, the Tsunami 1.0 project has just been approved and Priyanka Malhotra has been assigned as its project manager. Priyanka sets up the new project in TaskPhocus, the project management tool used for software development projects at BrainTwistors Corp. TaskPhocus is an EMS 1.0 service consumer.

In Act 2, Priyanka meets with her development team and they decide to monitor defect arrival rate as a KPI for the project. The team wants to ensure that their defect prevention and quality assurance processes are working well and want to know as early as possible when the defect arrival rate gets too high or too low. If the rate is too high then their defect prevention processes may not working well. Similarly, if the rate is too low, then their quality assurance processess may not be working well.

Priyanka contacts Syd Ethan, the software estimator, and asks him to estimate the defect arrival rate over the lifecycle of the project. Syd produces this estimate using Guestimator 101, the software estimation tool, and stores it in MetricServer, the EMS 1.0 service provider. Syd then reviews the estimate with Priyanka and the development team. Priyanka accepts the estimate and adds it to the project baseline.

TaskPhocus has some built-in reporting capability. Priyanka customizes her dashboard by adding a report that shows the current measured defect arrival rate and compares it to the estimate.

In Act 3, coding and testing begins. The development and quality assurance teams report defects to TaskPhocus. Priyanka starts her workdays by viewing the defect dashboard and taking any corrective action necessary. When Priyanka views this report, TaskPhocus calculates the current defect arrival rate by running a query against its internal defect tracking database, gets the defect arrival estimate from MetricServer, and combines the results into a report for Priyanka.

All of the interactions in this scenario are illustrated in a Summary sequence diagram.

This scenario is described in more detail in the following pages:

  • Act 1. Setup - Priyanka sets up the Tsunami 1.0 project in TaskPhocus.
  • Act 2. Estimation - Priyanka works with the development team and the software estimator to establish defect arrival rate as a KPI for the project.
  • Act 3. Execution - Priyanka monitors the defect arrival rate every day and takes corrective action when the actuals differ significantly from the estimate.
  • Summary - All of the interactions are summarized.

Category:EMS Primer


Categories