Introduction to Software engineering
Lecture 2 - Software engineering as a process
Jim Briggs, 7 October 1998
Read Sommerville chap 1, Davis chaps 1 & 6.
Computers are being used in more and more products.
Hardware is becoming cheaper. Now economically viable to perform heavy computational applications.
As problems are scaled up, can not simply scale up solutions. Analogy with road bridge over estuary and footbridge over stream.
Fundamental difference caused by increase in scale: system cannot easily be understood by one person and details held in that person's head. Formal techniques of specification and design are necessary. Each stage of the project must be properly documented and carefully managed.
Common factor in definitions of software engineering: systems built by teams. Software engineer must be able to communicate, both orally and in writing. "Software" not only programs, but must include documentation necessary to install, use, develop and maintain programs.
Term "software engineering" first used in 1960s - problems of coping with 3rd generation hardware. New techniques and methods needed. No better now. Exponential growth means that still the software techniques lag behind the hardware developments.
Well engineered software
Like other engineering disciplines SE not just about producing products, but producing them in the most cost-effective way. Cannot ignore cost considerations.
Common attributes of well-engineered software:
Problem is to attain optimum level of these attributes given that some are exclusive (e.g. efficient may mean less maintainable).
Trade-offs - which is most important in given system? Need to make explicit - not the software designers role to decide. Relationships between attributes not linear.
Software development is a process.
Several different models of the process have been developed:
Figure 1 Basic waterfall model (Sommerville, p5)
Figure 2 With feedback loops (Sommerville, p8)
Figure 3 Once "operational" (Sommerville, p9)
Figure 4 Boehm's spiral model (Sommerville, p15)
More on waterfall method
Stages not usually totally distinct; overlap and interact. E.g. problem with requirements might be spotted during design phase, design problem during coding, etc.
Software process therefore not a linear model but involves a series of iterations of the stages [add feedback arrows to waterfall diagram].
However, frequent iterations make it difficult to identify checkpoints for management purposes ("signing off", planning, estimation). Often tendency is to freeze part of the development, such as the specification, and continue with later stages. Any subsequent problems are left for (i) future resolution, (ii) ignored, or (iii) programmed around. Can lead to bad structure.
At the system testing phase, the developer must convince the customer that the system meets the requirements. However, verification and validation (V&V) are in all the earlier stages as well. V&V often identifies information that has to be fed back into earlier stages.
In operation, errors and omissions in the original requirements are discovered, program and design errors come to light, and the need for new functionality is identified. Modifications are thus necessary - this is "maintenance". Not just error correction - requirements may change. Effectively the development process (or part of it) is repeated many times.
The waterfall model has been criticised. It does not adequately recognise iteration in the software process, and it implies that specifications should be frozen at an early stage.
Figure 5 Davis's symmetrical waterfall model (Davis, p10)
(Sometimes known as evolutionary prototyping).
Develop an initial implementation, let the customer see it, and refine until happy.
Most appropriate for systems where it is difficult or impossible to establish detailed system requirements. Mainly used in AI/expert system applications where since we don't understand how humans carry out tasks we cannot set out a specification of how the computer will do it!
Key to success is rapid system iterations so that changes can be incorporated and demonstrated as quickly as possible. LISP and PROLOG are frequent implementation languages.
V&V is different from waterfall model. Verification is nonsense (no req spec). Validation shows adequacy (subjective) rather than correctness (objective).
Does not fit in with normal management structures (regular deliverables, etc.). Not cost-effective to produce much documentation. Tends to result in systems whose structure is not well-defined. Maintenance is therefore often difficult and costly, particularly when maintainers are not the original developers. Can less skilled developers be used effectively for this mode of development?
Evolutionary prototype evolves into final product and must therefore exhibit all quality attributes of final product.
"It is impossible to retrofit quality, maintainability and reliability!" [Davis]
"Most researchers who advocate quick and dirty prototypes that later evolve into working production systems are just that, researchers; they do not appreciate the incredible effort required during the design stage to generate a design that can withstand the punishments of the real world and stay operational and maintainable."
Compromise might be to do initial stages via exploratory programming to determine detailed requirements. Then throw that away and construct a new system using the waterfall method.
Characteristics of a throwaway prototype - build it quick and dirty - ignore:
Use of prototype shows up inconsistencies and ambiguities between developer and user.
Can aid user to understand their own problem. Can help "involve" user actively in development - may lead to better reception for final system.