Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 11: Scaling Up the Personal Software Process - Coggle Diagram
Chapter 11: Scaling Up the Personal Software Process
Using Abstractions
THE POWER OF ABSTRACTIONS
We can create ab- stractions and arbitrarily combine them into larger abstractions. Even if we know nothing about the internal structure of these abstractions, we can name and use them as long as we know all their important external specifications.
If we conform to the ca- pacities and capabilities of the systems we support, we can create whatever logi- cal structures we choose.
THE ELEMENTS OF INTELLECTUAL WORK
EXPERT MEMORY
Example: By using chunks, chess masters could store entire patterns of information in short-term memory. Amateur players lacked the large chunk vocabulary and instead filled their short-term memory ca- pacity of five to nine items withrecollections ofindividual pieces.
EXPERT SKILL
Building chunk vocabularies si just like building word vocabularies.
With experience, you build a richer collection of larger constructs and can quickly judge where and how to use them.
With this chunk vocabulary. we can think ni richer terms. This ni turn multiplies our abilities ot handle complexity.
THE POWER OF METHODS
Like large-scale systems, how- ever, theycan be decomposed into subprocesses.
By refining your processes and defining your methods, you will build a vocabulary of process chunks. With this, you get hte ability ot reason about and to design in- creasingly sophisticated processes.
The Stages of Product Size
The sizes of software tasks can be divided into the following general ranges:
Stage 0: very small program elements, written by programmers alone
Stage 0: very small program elements, written by programmers alone
Stage 1: small programs, or modules, designed, implemented, and tested by programmers alone
Stage 2: larger programs, or components, that typically involve teams of de- velopers who develop and integrate multiple Stage-1 modules into larger
Stage 2-component programs
Stage 3: very large projects that involve multiple teams controlled and di- rected by a central project management
Stage 4: massive multisystems that involve many autonomous or loosely federated projects
Developing Large-scale Programs
DIVIDE AND CONQUER
Al large-scale software development strategies start with a high-level design and then subdivide the svstem into components.
While this divide and conquer paradigm is generally satisfactory the principal risk with it is that development strategy may not be properly designed
The ethods of desintregation or integation then determine the efectiveness of the development strategy.
THE ESSENCE OF SCALABILITY
A software system si scalable if it can be disintegrated into smaller components, the components separately developed, and the system reintegrated.
This essence is not contained in its component parts. It must be created for the system and embodied in the way the parts work together as a coherent whole.
Establishing this essence is one principal challenge of scala- bility: to design large systems that do not look like loosely connected sets of
parts.
DESIGNING STAGE-4 MULTISYSTEMS
Most multisystem development efforts will likely interface with, adapt, Or extend some parts of large, existing systems.
The multisystem development process thus must include methods for modifying existing systems and the disciplines for understanding and controlling changes that span many system elements.
A Potential Problem with Abstractions
There are various ways to attack the scalability problem.
You could subdivide an entire system into parts and still not have usefully partitioned the work.
To have useful scalability, you must not only meet the re- quirements of physical scalability but also capture significant system function ni the parts.
The Development Strategy
THE PROGRESSIVE STRATEGY
Theprogressive strategy is the natural way to develop systems that are composed of a series of sequentially executing functions.
You first develop and test the op- erations that are performed first. You then add and test the next functions, and then the next, and so forth.
As each cycle is designed, implemented, and tested, the pipeline is gradually lengthened to include additional functions.
This strategy has the principal advantage of being easy to define and to mi - plement. It only needs test scaffolding for special cases, and there is little to re- build or redesign between cycles.
One disadvantage is that there may be no easy way to exhaustively test the behavior of each slice.
FUNCTIONAL ENHANCEMENT STRATEGY
The functional enhancement strategy defines an initial stripped-down system version, or kernel, and adds enhancements.
This is the common strategy for
follow-on enhancement of large systems.
The principal advantage of the functional enhancement strategy is that it builds a working system at the earliest point.
FAST-PATH ENHANCEMENT STRATEGY
The fast-path strategy is much like functional enhancement except that the initial skeletal system kernel is designed to demonstrate fast-path performance.
The principal advantage of fast-path enhancement is that it exposes timing problems at the earliest point. While the first system kernel may provide no recognizable external functions, performance can be measured and overall system performance estimated.
Its principal disadvantage, too, is the size of the first step.
THE DUMMY STRATEGY
The dummy strategy follows atop-down sequence. It starts with the high-level system functions
The principal disadvantage of the dummy strategy is that development may have to proceed quite far before useful system behavior is visible.
The advantages that the system is built in small steps and that it provides considerable flexibility in the order in which elements are added.
SELECTING A DEVELOPMENT STRATEGY
There is no one best strategy.
One potential problem with all these strategies is that some critical function may not be developed until the later development cycles.
he defects are then more easily identified and fixed.
PSP3
The principal role of PSP3 is to be an example of a personal process foundation for large-scale software development.
PSP must be capable of handling increased product complexity and must relate to the larger processes
REQUIREMENTS AND PLANNING
PSP3 starts with requirements and planning step that produces a conceptual design for the overall system, estimates its size, and plans the development work..
HIGH-LEVEL DESIGN
nI high-level design, you identify hte product's natural divisions and devise a cyclic strategy.
A good rule of thumb is to keep each cycle be- tween 100 and 300 lines of new and changed source code. These cycles often grow much larger than you expect,
After high-level design review, pro- ceed to cyclic development.
CYCLIC DEVELOPMENT
In cyclic development, first establish the specifications for the current cycle. You could develop these specifications during high-level design, but they are not needed before the development cycles.
During the cycles, the reviews and tests should be
as complete as possible. Each cycle is the foundation for the next,
The cyclic process is effective because it builds and tests new functions on a solid foundation.
TEST DEVELOPMENT AND REVIEW
Cyclic development includes a test development step.
It is rarely practical to de- velopthe unit tests before detailed design, but they must be developed before unit test.
Test development can reveal design problems as well as operational and user issues.
In cyclic testing, the first test will generally start with a clean slate. Each subsequent cycle then ads functions and progressively integrates them into the previously tested product.
REASSESS AND RECYCLE
If you are working on a project, you should also consider submitting a status report at the end of each cycle. If your data indicate significant deviations
from your original plan, adjust the plan and alert project management.