CS3500 Software Engineering

1. CS3500 Software Engineering How does a “program” differ from a “software system”? Program System Tens to hundreds of lines of code Thousands to millions of lines of code Limited, easily acquired and unchanging specification Specifications complex, detailed and often change Usually implement single or few functions Multi-functional Usually written by 1 person in short time Designed/developed by many over months/years (Problems of teamwork, communication and conflict resolution) Limited/zero interface with other software Usually interfaces with other software (Problems of integration, different languages & standards, security issues, political ownership) Usually single-user Usually multi-user System testing much more difficult and time-consuming than program testing

2. CS3500 Software Engineering A System & its Components B 1 O1 A I1 c 2 3 e O2 8 4 FBC2 5 Controll -er d I2 6 7 f FBC1 FBC O = output I = Input FBC = Feedback Control

3. CS3500 Software Engineering • So – a system is a complex network of components which • interact, directly and/or indirectly, in such a way that the • stability of the parts and of the whole system is maintained over a set period of time. • We can distinguish between • Natural systems (e.g. solar system, ecosystems, physiological systems) and • Man-made systems (e.g. political, legal, administrative systems. and information systems.) We automatically assume that all man-made systems should be designed to deliver certain defined objectives.

4. CS3500 Software Engineering System Properties: • Man-made systems have five abstract properties: • Hierarchical structure • - within a system we can see a hierarchy of levels of • organisation, each more complex than the one below it • Emergent properties • - systems have characteristics which are meaningful only • when attributed to the whole, not to the individual parts • Communication • - all systems exhibit the phenomenon of information transfer • Control • - systems exist in environments whose conditions fluctuate.The control features of • a system use the end-results of communication to maintain steady-state conditions • as far as this is possible. • Objectives • - man-made systems are designed to serve a purpose and so must have well- • defined objectives

5. CS3500 Software Engineering Information Systems • Information systems have these 5 general system properties. • In addition, in an information system – • the components are data and processes which effect data • communication is achieved by the flow (movement) of data from one part of the system to another • control is achieved by the triggering of actions as a result of a data flow • So – • Components = data + processes acting on data • Communication = flows of data from one component to another • Control = pre-designed actions triggered by data flows

6. CS3500 Software Engineering Important! • It follows from the slides so far that a body of software code and • its associated hardware can only be considered to be a true “system” • when the key characteristics of • hierarchy • emergent properties • communication • control and • objectives have been incorporated into the design before any coding begins It follows that a competent software engineer should consider themself, first and foremost, to be a designer of robust stable systems. The role of the software engineer as a programmer is a secondary and subsequent one (although when you are racing to meet a deadline in your Team Software Project then it is just possible that you may forget this!)

7. CS3500 Software Engineering Software as a Product? • If we regard the end-result of the SD effort to • be a “product” then what characteristics would we expect it to have? • Specification of what product can and cannot do and conditions under which it will work properly – product capability • “How to use” ( anything from detailed user manual to label on package) • Warranty and related conditions • After-sales service (support, e.g. helpdesk, training, etc) • Design documentation (technical specifications used for servicing/modifying product during its life) • Test documentation (what tests were performed, test data, test results). (Test performance provides measures of product quality)

8. CS3500 Software Engineering Engineering • We know that physical products are: • designed, • manufactured and assembled using methods, • a plan and a schedule • tested to ensure and prove quality • The focus is QUALITY ! • The challenge that faces every software engineering • effort is to develop a software product that is truly • engineered in this way.

9. CS3500 Software Engineering The Traditional Engineering Sequence Analyse user needs Design product Supply to customer Build product Test product Service & maintenance

10. CS3500 Software Engineering The Traditional Way Because software engineering tried to copy the view of traditional physical engineering, it followed that it adopted a very linear/sequential approach to all of the activities involved in bringing a large piece of software and associated hardware to an end user.

11. CS3500 Software Engineering The Traditional Way • Because software engineering tried to copy the • view of traditional physical engineering, it • followed that it adopted a very linear/sequential • approach to all of the activities involved in bringing a • large piece of software and associated hardware to • an end user. • This failed to recognise that with software systems - • user requirements are neither quickly or easily acquired • software needs to change as the needs of users change

12. CS3500 Software Engineering Product Life-expectancy (1) End of product life Initial high number of faults Faultsreduced &keptto low level by servicing Over time, faults rise due to material fatigue (wear out)

13. CS3500 Software Engineering Product Life-expectancy (2) Initial high number of bugs (faults) Further maintenance of software not cost- effective Bugsreduced to a fairly low level by servicing Over time, bug level rises and good structure breaks down due to changes in successive versions

14. CS3500 Software Engineering Software – the Cost of Change The longer a “fault”* remains embedded in the developing system, the more expensive it is to remove it! * Fault = bug, error, misunderstanding, omission, inconsistency or any failure to match what is being designed & developed with user requirements

15. CS3500 Software Engineering Software System Origin (1) • Organisations acquire new software systems in 2 basic ways: • Designing & developing to suit the precise needs of users • Purchasing off-the-shelf software and then configuring the • components to fit with organisational processes

16. CS3500 Software Engineering Software System Origin (2)

17. CS3500 Software Engineering Software System Origin (3) Which Option? • Off-the-shelf systems/components do not usually match user requirements precisely. This may mean requirements must be modified. This can have very serious knock-on effects on people, on processes within the organisation and on other related sub-systems. • Custom-built software usually takes longer to build and costs more but is likely to give a more precise fit to user requirements.

18. CS3500 Software Engineering Software System Origin (4) Large complex systems usually consist of a mixture of off-the-shelf components and specially built components. (These may be designed and coded in-house or contracted to a software developer.) “Glueing” these different elements together to provide an operational system is unpredictable in terms of the difficulties encountered and the time and effort costs involved.