Introduction to Software engineering

Lecture 2 - Software engineering as a process

Jim Briggs, 7 October 1998

Read Sommerville chap 1, Davis chaps 1 & 6.

Introduction

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:

  1. Maintainable - important that changes can be made without undue costs.
  2. Reliable - essential if to be of any use.
  3. Efficient - not wasteful of system resources (memory and processor cycles); though not necessary to squeeze last drop.
  4. Appropriate user interface - not difficult to use; take into account capabilities and background of intended users.

    5. 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 life-cycle

    Software development is a process.

    Several different models of the process have been developed:

  5. Most widespread: "waterfall" method. Process viewed as number of stages. After each stage is "signed off" proceed to next stage.

    6. Figure 1 Basic waterfall model (Sommerville, p5)

    Figure 2 With feedback loops (Sommerville, p8)

    Figure 3 Once "operational" (Sommerville, p9)

  6. Exploratory programming (evolutionary prototyping). Develop working system as quickly as possible then modify it until it performs adequately. Often used in AI systems development where detailed requirements cannot be formulated and notion of system correctness is difficult to gauge. (Goal is adequacy rather than correctness.)
  7. Prototyping (throwaway). Similar to EP in that first step is to develop a working system. However, purpose of that is to establish system requirements. Software then re-implemented to produce production-quality system.
  8. Formal transformation. Develop formal specification then transform it, using correctness-preserving transformations, to program. Experimental only.
  9. Assembly from reusable components. Process of assembly rather than creation.
  10. Boehm management lifecycle.

    11. Figure 4 Boehm's spiral model (Sommerville, p15)

    More on waterfall method

    Stages:

  11. Requirements analysis and definition. Establish system's services, constraints and goals established by consultation with customer/user. Once agreed, must be defined in manner understandable by both users and developers.
  12. System and software design. System design: which requirements are going to be done in hardware and which in software? Software design: how are functions of software system to be represented? Do in manner that makes easier the transformation into program(s).
  13. Implementation and unit testing. Software design realised as set of programs or program units in some programming language. Unit testing: verify that each unit meets its specification.
  14. System testing. Individual units integrated and tested as complete system to ensure that all requirements are met. Then deliver to customer.
  15. Operation and maintenance. System is installed and put to use. Maintenance involves correcting errors not discovered earlier, improving implementation of system units and enhancing services as requirements change.

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.

Definitions (Boehm):

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)

Exploratory programming

(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."

Throwaway prototyping

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:

  1. all exception conditions;
  2. error recovery;
  3. hardware or other external (e.g. DBMS) interfaces (simulate them);
  4. performance considerations;
  5. user interface (but not if modelling that is part of the reason for building the prototype).

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.