# Presentation: 027705

## Disciplined Software Engineering Lecture #11

**Software Engineering Institute**
**Carnegie Mellon University**
**Pittsburgh, PA 15213**
**Sponsored by the U.S. Department of Defense**

## Lecture #11 Overview 

**Scaling up the Personal Software Process**
**scalability principles**
**handling software complexity**
**development strategies**
**The cyclic PSP**
**Software inspections**

## What is Scalability?

**A product development process is scalable when the methods and techniques used will work equally well for larger projects.**
**Scalability typically**
**applies over small product size ranges**
**is limited to similar application domains**
**does not apply to unprecedented systems**
**does not work for poorly managed projects**
**is unlikely to apply where the engineering work is undisciplined**

## Scalability Principles

**Scalability requires that the elements of larger projects behave like small projects.**
**The product design must thus divide the project into separably developed elements.**
**This requires that the development process consider the scale of projects that individuals can efficiently develop. **

## Scalability Stages

**We can view software systems as divided into five scalability stages.**
**These scalability stages are**
**stage 0 - simple routines**
**stage 1 - the program**
**stage 2 - the component**
**stage 3 - the system**
**stage 4 - the multi-system**

## Scalability Stage 0

**Stage 0 is the basic construct level.  It concerns the construction of loops, case statements, etc.**
**Stage 0 is the principal focus of initial programming courses.**
**At stage 0, you consciously design each programming construct.**
**When your thinking is preoccupied with these details, it is hard to visualize larger constructs.**

## Scalability Stage 1

**Stage 1 concerns small programs of up to several hundred LOC.**
**Movement from stage 0 to stage 1 naturally occurs with language fluency.  You now think of small programs as entities without consciously designing their detailed constructs.**
**As you gain experience at stage 1, you build a vocabulary of small program functions which you understand and can use with confidence.**

## Scalability Stage 2

**Stage 2 is the component level.  Here, multiple programs combine to provide sophisticated functions.  Stage 2 components are typically several thousand LOC.**
**The move from stage 1 to stage 2 comes with increased experience.  You can now conceive of larger programs than you can possibly build alone.  **
**At stage 2, system issues begin to appear: quality, performance, usability, etc.**

## Scalability Stage 3

**Stage 3 systems may be as large as several million LOC.  Here, system issues predominate.**
**the components must work together **
**the component parts must all be high quality **
**The move from stage 2 to stage 3 involves**
**handling program complexity**
**understanding system and application issues**
**working in a team environment**
**At stage 3, the principal emphasis must be on program quality.**

## Scalability Stage 4

**Stage 4 multi-systems may contain many millions of LOC.  **
**multiple semi-independent systems must work together.  **
**quality is paramount.  **
**The move from stage 3 to stage 4 introduces large scale and distributed system issues as well as problems with centralized control.**
**Stage 4 requires semi-autonomous development groups and self-directing teams. **

## Scalability Conditions - 1

**To be scalable**
**the process must be managed**
**the project must be managed**
**the product must be managed**
**A managed process should**
**be defined**
**divide the work into separable elements**
**effectively integrate these elements into the final system**

## Scalability Conditions - 2

**For a managed project**
**the work must be planned**
**the work must be managed to that plan**
**requirements changes must be controlled**
**system design and system architecture must continue throughout the project**
**configuration management must be used**

## Scalability Conditions - 3

**For a managed product**
**defects must be tracked and controlled**
**integration and system testing must be done **
**regression testing is used consistently**
**Product quality must be high**
**module defects should be removed before integration and system test**
**the module quality objective should be to find all defects before integration and system test (i.e. miss less than 100 defects per MLOC) **

## The Scalability Objective

**The scalability objective is to develop large products with the same quality and productivity as with small products.**
**Scalability will only apply to tasks that were done on the smaller project.**
**Since the new tasks required by the larger project require additional work, productivity will generally decline with increasing job scale.**

## The Scope of Scalability - 1

**Small **
**Projects**

**Medium**
**Projects**

**Large **
**Project**

## The Scope of Scalability - 2

**In scaling up from the module level to the component level**
**you seek to maintain the quality and productivity of the module level work**
**the component level work is new and thus cannot be scaled up**
**In scaling up to the product level**
**you seek to maintain the quality and productivity of the component level work**
**the product level work is new and thus cannot be scaled up**

## Managing Complexity - 1

**Size and complexity are closely related.**
**   **
**While small programs can be moderately complex, the critical problem is to handle large programs.**
**The size of large programs generally makes them very complex.**

## Managing Complexity - 2

**Software development is largely done by individuals**
**they write small programs alone**
**larger programs are usually composed of multiple small programs**
**There are three related problems: ways to**
**develop high quality small programs**
**enable individuals to handle larger and more complex programs**
**combine these individually developed programs into larger systems**

## Managing Complexity - 3

**The principal problem with software complexity is that humans have limited abilities to**
**remember details**
**visualize complex relationships**
**We thus seek ways to help individuals develop increasingly complex programs**
**abstractions**
**architecture**
**reuse**

## The Power of Abstractions - 1

**People think in conceptual chunks**
**we can actively use only 7 +/- 2 chunks**
**the richer the chunks, the more powerful our     thoughts**
**This was demonstrated by asking amateur chess players to remember the positions of chess men in a game   **
**they could only remember 5 or 6 pieces**
**experts could remember the entire board**
**for randomly placed pieces, the experts and amateurs did about the same**

## The Power of Abstractions - 2

**Software abstractions can form such chunks if**
**they are precise**
**we fully understand them**
**they perform exactly as conceived**
**Some potential software abstractions are**
**routines**
**standard procedures and reusable programs**
**complete sub-systems**

## The Power of Abstractions - 3

**To reduce conceptual complexity, these abstractions must**
**perform precisely as specified**
**have no interactions other than as specified**
**conceptually represent coherent and self-    contained system functions**

## The Power of Abstractions - 4

**When we think in these larger terms, we can precisely define our systems.**
**We can then build the abstractions of which they are composed.**
**When these abstractions are then combined into the system, they are more likely to perform as expected.**

## The Power of Abstractions - 5

**The principal limitations with abstractions are**
**human developers make specification errors **
**abstractions frequently contain defects**
**most abstractions are specialized **
**This means that we are rarely able to build on other people’s work.**
**Our intellectual ability to conceive of complex software systems is thus limited by the abstractions we ourselves have developed.**

## Architecture and Reuse - 1

**A system architectural design can help reduce complexity because it**
**provides a coherent structural framework**
**identifies conceptually similar functions**
**permits isolation of subsystems**
**A well structured architecture facilitates the use of standard designs**
**application specifics are deferred to the lowest level**
**where possible, adjustable parameters are defined **

## Architecture and Reuse - 2

**This enhances reusability through the use of standardized components. **
**These precisely defined standard components can then be used as high-level design abstractions.**
**If these components are of high quality, scalability will more likely be achieved.**

## Feature-Oriented Domain Analysis - 1

**Feature-Oriented Domain Analysis was developed by the Software Engineering Institute (SEI).  It is an architectural design method that**
**identifies conceptually similar functions**
**categorizes these functions into classes**
**defines common abstractions for each class**
**uses parameters wherever possible**
**defers application-specific functions **
**permits maximum sharing of program elements**

## Feature-Oriented Domain Analysis - 2

**An example of feature-oriented domain analysis**
**define a system output function**
**the highest level composes and sends messages**
**the next lower level defines printers, displays, etc.**
**the next level handles printer formatting**
**the next level supports specific printer types**

## Development Strategies - 1

**A development strategy is required when a system is too large to be built in one piece**
**it must then be partitioned into elements**
**these elements must then be developed**
**the developed elements are then integrated into the finished system**

## Development Strategies - 2

**The strategy **
**defines the smaller elements**
**establishes the order in which they are developed**
**establishes the way in which they are integrated**
**If the strategy is appropriate and the elements are properly developed**
**the development process will scale up**
**the total development is the sum of the parts plus system design and integration **

## Some Development Strategies

**Many development strategies are possible.**
**The objective is to incrementally build the system so as to identify key problems at the earliest point in the process. **
** **
**Some example strategies are **
**the progressive strategy**
**the functional enhancement strategy**
**the fast path enhancement strategy**
**the dummy strategy**

## The Progressive Strategy

**2nd**
**Enhancement**

**1st**
**Enhancement**

**1st**
**Enhancement**

**1st**
**Module**

**1st**
**Module**

**1st**
**Module**

**The Progressive Strategy**

**In the progressive strategy, the functions are developed in the order in which they are executed.  This permits relatively simple testing and little scaffolding or special test facilities.**

**In**

**Out**

**Out**

**Cycle 1**

**Cycle 2**

**Cycle 3**

**In**

**In**

**Out**

## Functional Enhancement

**With functional enhancement, a base system must first be built and then enhanced.  The large size of the base system often requires a different strategy for its development.**

**4th**
**Functional**
**Enhancement**

**2nd**
**Functional**
**Enhancement**

**3rd**
**Functional**
**Enhancement**

**Core System**

**Ist**
**Functional**
**Enhancement**

## Fast Path Enhancement

**In fast path enhancement,**
**the high performance loop**
**is built first, debugged, and measured.  **
**When its performance is **
**suitable, functional **
**enhancements are made.**
**Each enhancement is**
**measured to ensure that**
**performance is still**
**within specifications.**

## The Dummy Strategy

**With the dummy strategy, a core system is first built with dummy code substituted for all or most of the system’s functions.**
**These dummies are then gradually replaced with the full functions as they are developed.**

## The Cyclic PSP - 1

**The cyclic PSP provides a framework for using a cyclic development strategy to develop modest sized programs.  **
**It is a larger process that contains multiple PSP2.1-like cyclic elements.**
**The PSP requirements, planning, and postmortem steps are done once for the total program.**

## The Cyclic PSP Flow

**The Cyclic PSP Flow**

**Specifications**

**Product**

## The Cyclic PSP - 2

**High-level design partitions the program into smaller elements and establishes the development strategy.**
**The process ends with integration and system test, followed by the postmortem.**
**The development strategy determines the cyclic steps**
**element selection**
**the testing strategy**
**it may eliminate the need for final integration    **

## The Team Software Process - 1

**To further increase project scale, a team development process is typically required.**
**This identifies the key project tasks**
**relates them to each other**
**establishes entry and exit criteria**
**assigns team member roles**
**establishes team measurements**
**establishes team goals and quality criteria**

## The Team Software Process - 2

**The team process also provides a framework within which the individual PSPs can relate, it**
**defines the team-PSP interface**
**establishes standards and measurements**
**specifies where and when to use inspections **
**establishes planning and reporting guidelines**
**Even with the PSP, you should request team support for inspections.**
**Initially consider using design inspections to improve PSP yield.**

## Inspections - 1

**Inspections are the most cost-effective technique known for improving software quality and reducing development time and cost.**
**Inspections help to**
**motivate better work**
**ensure effective team communication**
**maintain a dedication to excellence**

## Inspections - 2

**The objectives of inspections are to**
**find defects at the earliest possible point **
**ensure that all parties agree on the work**
**verify that the work meets defined criteria**
**formally complete a task**
**provide data**
**Inspections can be used for any software product element, for example**
**requirements, specifications, design, code**
**test materials**
**documentation**

## The Inspection Process - 1

**Inspections follow a formally structured process.**
**Checklists and standards are developed for each inspection type.**
**The inspection is conducted by technical people for technical people.  Managers do not attend.**

## The Inspection Process - 2

**Planning**

**Briefing**
**Meeting**

**Preparation**

**Inspection**
**Meeting**

**Follow-**
**up**

**Manager**
**Producer**
**Moderator**

**Moderator**
**Producer**
**Reviewers**

**Reviewers**

**Moderator**
**Recorder**
**Producer**
**Reviewers**

**Moderator**
**Producer**

## The Inspection Process - 3

**The reviewers prepare in advance.**
**The inspection meeting focuses on identifying problems, not on resolving them.**
**Inspection data are gathered and entered into an inspection database for tracking and analysis.**

## Inspection Roles - 1

**The moderator **
**leads the inspection process**
**maintains a focus on problem identification rather than problem solution**
**ensures that the identified problems are resolved **
**submits the inspection report**
**The producer (the developer who did the work) **
**produces the review materials **
**answers questions **
**resolves the identified problems**

## Inspection Roles - 2

**The reviewers **
**attend the inspection kick-off meeting**
**review the work in advance**
**attend the inspection meeting**
**raise issues and questions about identified defects or other concerns**
**The recorder **
**documents the identified issues and notes the person responsible for resolving them**
**records all relevant data**

## Assignment #11

**Read Chapter 11 in the text.**
**Using PSP3, develop program 10A to calculate 3-parameter multiple-regression parameters and prediction intervals for a data set.  Use program 5A to calculate the t distribution.  Three periods are allowed for this assignment.**
**Read and follow the program specifications in Appendix D and the process description and report specifications in Appendix C.**

## Multiple Regression - 1

**Suppose you had the following data on 6 projects**
**development hours required**
**new, reused, and modified LOC   **
**Suppose you wished to estimate the hours for a new project you judged would have 650 LOC of new code, 3,000 LOC reused code, and 155 LOC of modified code.**
**How would you estimate the development hours and the prediction interval?**

## Multiple Regression - 2 

**Prog#        New       Reuse     Modified      Hours**
**                     ****w             x                y                 z**
**1                 1,142    1,060            325              201**
**2                    863       995              98                98**
**3                 1,065    3,205              23              162**
**4                    554       120                0                54**
**5                    983    2,896            120              138**
**6                    256       485              88                61**
**Sum           4,863     8,761           654              714**
**Estimate       650     3,000           155             ???**

## Multiple Regression - 3

**Multiple Regression - 3**

**Multiple regression provides a way to estimate the effects of multiple variables when you do not have separate data for each.**
**1.  You would use the following multiple **
**     ****regression formula to calculate the estimated **
**     ****value**

## Multiple Regression - 4

**Multiple Regression - 4**

**2.  You find the Beta parameters by solving the **
**     ****following simultaneous linear equations **

## Multiple Regression - 5

**Multiple Regression - 5**

**3.  When you calculate the values of the terms, **
**     ****you get the following simultaneous linear **
**     ****equations**

## Multiple Regression - 6

**Multiple Regression - 6**

**4.  Then you diagonalize using Gauss’ method.  **
**     ****This successively eliminates one parameter **
**     ****at a time from the equations by successive **
**     ****multiplication and subtraction to give **

## Multiple Regression - 7

**Multiple Regression - 7**

**5.  Then you solve for the Beta terms**

## Multiple Regression - 8

**Multiple Regression - 8**

**6.  Determine the prediction interval by solving**
**     ****for the range with the following equation**
**7 -  Calculate the variance as follows**

## Multiple Regression - 9

**Multiple Regression - 9**

**8.  The variance evaluates to the following**
**9.  The terms under the square root are**

## Multiple Regression - 10

**10.  The value of the t distribution for a 70% **
**       ****prediction interval, n=6, and p=4 is found **
**       ****under the 85% column and two degrees of **
**       ****freedom in Table A2.  It is 1.386.**
**11.  The square root is then evaluated as **
**       ****follows**

## Multiple Regression - 11

**12.  The final estimate is then**
**z = 6.71+0.0784*650+0.0150*3,000+0.2461*155**
**   ****= 140.902 hours**
**13.  The prediction interval of 38.846 hours **
**        ****means the estimate is from 102.1 to 179.7 **
**        ****hours.**

## Messages to Remember from Lecture 11 - 1

**1.  Scalable software processes provide **
**     ****important productivity and planning benefits.**
**2.  Scalability requires that the process be **
**     ****defined, well managed, and of high quality.**

## Messages to Remember from Lecture 11 - 2

**3.  The PSP focus on yield management helps **
**     ****to achieve scalability.**
**4.  The use of abstractions, architectures, and **
**     ****reuse will also help make a process scalable.**