Please enable JavaScript.
Coggle requires JavaScript to display documents.
SCALING UP THE PERSONAL SOFTWARE PROCESS - Coggle Diagram
SCALING UP THE PERSONAL SOFTWARE PROCESS
Using Abstractions
Intellectual "Ork involves three elements: memory, skill. and method.
By using chunks, chess masters could store entire patterns of information in short-term memory.
With experience, you build a richer collection of larger constructs and can quickly judge where and how to use them.
As we refine our processes and build families of known and repeatable methods, we can also learn how to scale up our processes.
The Stages of Product Size
Stage 0: very small program elements,
written by programmers alone
Stage l: small programs, or modules, designed,
implemented, and tested by programmers alone
Stage 2: larger programs, or components, that typically involve teams of
developers who develop and integrate multiple
Stage-I modules into larger Stage 2-component programs
Stage 3: very large projects that involve multiple teams controlled and directed by a central project management
Stage 4: massive multisystems that involve many autonomous or loosely federated projects
Other potential implications of the PSP are security, privacy, and integrity.
Developing Large-scale Programs
Such prototypes should be developed with explicit objectives and should concentrate on total system understanding. Once you understand the system, you can start work on the components.
All large-scale software development strategies start with a high-level design and then subdivide the svstem into comoonents.
This designer or team then either designed the principal system components themselves or had sufficient influence to ensure they were designed consistently with the system concept.
The intelligence problem concerns the need to organize information about these large and dynamic systems. Even if each part's design is fully documented, system behavior likely will not be.
A Potential Problem with Abstractions
You could subdivide an entire system into parts and still not have usefully partitioned the work.
While having such objects may help, part definition does not replace the need for system design. To have useful scalability, you must not only meet the requirements of physical scalability but also captuœ significant system function in the parts.
The Development Strategy
The development strategy connects your PSP to the overall project and provides the framework for disintegrating and reintegrating the product.
This strategy has the principal advantage of being easy to define and to implement. It only needs test scaffolding for special cases, and there is little to rebuild or redesign between cycles. One disadvantage is that there may be no easy way to exhaustively test the behavior of each slice.
The principal advantage of the functional enhancement strategy is that it builds a working system at the earliest point.
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.
This is an appropriate strategy for a layered System or for the kernel portion of the fast-path or functional enhancement strategies. It has the advantages that the system is built in small steps and that it provides con siderable flexibility in the order in which elements are added.
One potential problem with all these strategies is that some critical function may not be developed until the later development cycles. This in turn has the double problem of delaying exposure to the principal project risks and of testing the most complex element for the first time in the full system context.
PSP3
PSP3 starts with a requirements and planning step that produces a conceptual design for the overall system, estimates its size, and plans the development work.
In high-level design, you identify the product's natural divisions and devise a cyclic strategy. If some pieces are much larger than you prefer, you may adopt a special approach for that part.
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. Producing them earlier could also waste your time because they are often affected by subsequent development cycles.
Test development can reveal design problems as well as operational and user issues. Common problem areas are exception handling, responses to user errors, and out-of-limit conditions. Other issues concern the need for test data, special test modes, user scenarios, and test support facilities. The advantage of early test planning and development is that both force you to think about the product from a testing perspective.
After each cycle, you reassess the work to determine status and to reevaluate the plan. 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.
The size of software projects has increased rapidly for over 30 years. The products you develop in the future are thus likely to be much larger than today's. Because a process that is optimum for a small program will not likely be so for one five to 10 times larger, you will probably have to change your development process.
This strategy defines cycle contents as bite-sized elements that are separately designed and implemented in development cycles. Each cycle is progressively unit tested and integrated, and, at the end, you have the integrated, complete program ready for system integration or system test.