Chapter 13 Project Control process Instrumentation 12272021 1

Chapter 13 - Project Control & process Instrumentation 12/27/2021 1

Overview n n n n Introductory Remarks 13. 1 The Seven Core Metrics 13. 2 Management Indicators 13. 2. 1 Work & Progress 13. 2. 2 Budgeted Cost & Expenditure 13. 2. 3 Staffing & Team dynamics 13. 3 Quality Indicators 13. 3. 1 Change Traffic & Stability 13. 3. 2 Breakage & Modularity 13. 3. . 3 Rework & Adaptability 13. 3. 4 MTBF & Maturity 13. 4 Life-Cycle Expectations 13. 5 Pragmatic Software Metrics 13. 6 Metrics Automation 12/27/2021 2

Introductory Remarks n n The progress toward project goals & the quality of the software products must be measurable throughout the software development cycle Metrics Values provide important perspective for managing the process The most useful metrics are extracted directly from the evolving artifacts Objective analysis & automated data collection are crucial to the success of any metrics 12/27/2021 3

Introductory Remarks The Primary theme of a modern software Development process tackle the central management issues of complex software n n n Getting the design right by focusing on the architecture first Managing risk through iterative development Reducing the complexity with component techniques Making software progress & quality tangible through instrumented change Management Automating the overhead & bookkeeping activities through the use of round-trip engineering & integrated environment Fourth item is the subject of this chapter 12/27/2021 4

Introductory Remarks The goals of software metrics are to provide the development team & the management team with following n n n An accurate assessment of the progress date Insight into the quality of the evolving software products A basis for estimating the cost & schedule for completing the product with increasing accuracy over time 12/27/2021 5

The Seven Core Metrics The core metrics are classified into two groups n Management Indicators Work & Progress ( Work performed over time ) Budgeted Cost & Expenditures ( Cost Incurred over time ) Staffing & Team dynamics ( Personnel changes over time ) n Quality Indicators Change traffic & Stability ( Change traffic over time ) Breakage & Modularity ( Average breakage per change over time ) Rework & Adaptability (Average rework per change over time ) Mean time between failures & maturity (Defect rate over time ) 12/27/2021 6

Management Indicators I Work & Progress Various activities of an iterative development project can be measured by defining a planned estimate of the work in an objective measure then tracking progress against that plan Each major organization team should have at least one primary progress perspective that it is measured against. The default perspective of the metrics would be as follows n n Software Architecture team : Use case demonstrated Software development team : SLOC under baseline change management, SCO s closed Software Assessment team : SCO s opened, test hours executed, evaluation criteria met Software management team : Milestones completed 12/27/2021 7

Management Indicators II Budgeted Cost & Expenditures Modern software processes are amenable to financial performance measurement through an earned value approach which provides highly detailed cost & schedule insight. The basic parameters of an earned value system are n n n Expenditure Planned spending profile for a project over its planned schedule ( this profile tracks the staffing ) Actual Progress The technical accomplishment relative to the planned progress underlying the spending profile Actual Cost The actual spending profile for the project over its actual schedule 12/27/2021 8

Management Indicators n Earned Values The value that represents the planned cost of the actual progress Cost Variance The difference between the actual cost & the earned values + values : Over budget situations - values : Under budget situation Schedule Variance The difference between the planned cost & the earned values + values : Behind schedule situations - values : ahead-of schedule situation 12/27/2021 9

Management Indicators III Staffing & Team dynamics An iterative development should start with a small team until the risks in the requirements & architecture have been suitably resolved. Depending on the overlap of the iterations & other project-specific circumstances staff can be varied Generally in certain projects maintenance team will be smaller than development team For commercial product development the size of maintenance & development teams may be the same 12/27/2021 10

Management Indicators When long-lived continuously improved products are involved maintenance is just continuous construction of new & better releases. Tracking actual versus planned staffing is a necessary & well-understood management metric Increases in staff can slow overall project progress as new people consume the productive time of existing people in coming up to speed 12/27/2021 11

Inception Elaboration Construction Transition Effort 5% Effort 20% Effort 65% Effort 10% Schedule 30% Schedule 50% Schedule 10% Staffing Project Schedules Typical Staffing Profile 12/27/2021 12

Quality Indicators The four quality indicators are based primarily on the management of software change across evolving baselines of engineering data Change traffic & stability is a indicator of progress & quality where as remaining three metrics focus more on quality of the product I Change Traffic & stability Change traffic is defined as the number of software change orders ( SCO ) opened & closed over the life cycle Stability is defined as the relationship between opened versus closed SCO’s 12/27/2021 13

Quality Indicators II Breakage & Modularity Breakage is defined as the average extent of change which is the amount of software baseline that needs rework Modularity is the average breakage trend over time. This indicator provides insight into the benign or malignant character of the software change 12/27/2021 14

Quality Indicators III Rework & Adaptability Rework is defined as the average cost of change which is the effort of analyze, resolve & retest all changes to software baselines Adaptability is defined as the rework trend over time This metric provides insight into rework measurement. In a mature iterative development process, earlier changes ( architecture changes ) are expected to require more rework than later changes ( implementation changes ) 12/27/2021 15

Quality Indicators III MTBF & Maturity MTBF is the average usage time between software faults. i. e MTBF is computed by dividing the test hours by the number of type 0 & type 1 SCOs Maturity is defined as the MTBF trend over time. Early insight into maturity requires that an effective test infrastructure be established. 12/27/2021 16

Life-cycle Expectations n n There are no mathematical or formal derivation for using the seven core metrics however there are specific reasons for selecting them The quality indicators are derived from the evolving product than from the artifacts. They provide insight into the waste generated by the process. Scrap & rework metrics are a standard measurement perspective of most manufacturing processes They recognize the inherently dynamic nature of an iterative development process. The combination of insight from the current value & the current trend provides tangible indicators for management action. 12/27/2021 17

Metric Progress Inception Elaboration Construction Transition 5% 25% 90% 100% Architecture 30% 90% 100% Application <5% 20% 85% 100% Expenditures Low Moderate High Effort 5% 25% 90% 100% Schedule 10% 40% 90% 100% Staffing Small team Ramp up Steady Varying Stability Volatile Moderate Stable Architecture Volatile Moderate Stable Application Volatile Moderate Stable 50% - 100% 25% - 50% <25% 5%-10% <15% <5% Modularity Architecture >50% Application >80% 12/27/2021 > 50% >80% <25% <10% 18

Metric Adaptability Inception Elaboration Construction Transition varying Benign Architecture varying Moderate Benign Application Varying moderate Benign Prototype Fragile Usable Robust Architecture Prototype Usable Robust Application Prototype Fragile Usable Robust Maturity 12/27/2021 19

Pragmatic Software Metrics The Basic characteristics of a good metrics are as follows n n n It is considered meaningful by the customer, manager & performer It demonstrates quantifiable correlation between process perturbations & business performance It is objective & unambiguously defined It display trends It is a natural by-product of the process It is supported by automation 12/27/2021 20

Metrics Automation n There are many ways to automate the project control activities of software projects. A Software project control panel (SPCP) that maintains on-line version of the status of evolving artifacts provides a key advantage for managing against plan. The idea is to provide a display panel that integrates data from multiple sources to show the current status of some aspects of the project. Example The software manager want to see a display with overall project value A test manager may want to see a display focused on metrics specific to on upcoming beta release. A development managers may be interested only in data concerning the subsystems & components for which they are responsible 12/27/2021 21

Metrics Automation n n n The Software project control Panel (SPCP) can support standard features such as Warning lights Thresholds Variable scales Digital formats Analog formats to present an overview of the current situation. This automation support can Improve management insight into progress & quality trends Improve the acceptance of metrics by the engineering team 12/27/2021 22

Metrics Automation To implement a complete SPCP it is necessary to define & develop the following n n n Metrics primitives : indicators, trends, comparisons & progressions A graphical user interface (GUI) : GUI support for software project manager role & flexibility to support other roles Metrics collection agents : Data extraction from environment tools that maintain the engineering notation for the various artifacts sets Metrics data management server : Data management support for populating the metrics display of the GUI & storing data extracted from agents Metrics definition : Actual metrics representation for all activities Actors : The monitor & the Administrator 12/27/2021 23

Metrics Automation n n n n Specific monitors ( called roles ) include Project managers Software development team leads Software Architects Customers for each role there is specific panel configuration & scope of data presented. Each role performs the same general use cases, but with a different focus Monitor Defines panel layouts from existing mechanisms Graphical objects Linkage to project data Queries data to be displayed at different level of abstraction 12/27/2021 24

Metrics Automation Administrator n Installs the system n Defines new mechanisms n Graphical objects n Linkages n Handling archiving functions n Defines composition & decomposition structures for displaying multiple levels of abstraction The whole display is called panel. Within a panel are graphical objects which are types of layouts( such as dials & bar charts ) for information. Each graphical object display METRIC 12/27/2021 25

Metrics Automation A Panel typically contains a number of graphical objects positioned in a particular geometric layout. A metric shown in a graphical object is labeled with the metric type, summary level & the instance name. n n Metrics can be displayed in two modes : Value & Graph Metrics can be displayed with or without control values A Control value is an existing expectation that is used for comparison with dynamically changing metric Metrics may display data in the formats that are binary, digital & enumerated type Metrics also provides a mechanisms that can be used to summarize a condition associated with another metrics or relation between metrics & other associated control values 12/27/2021 26