Introduction to Software Engineering - CSA2030

1. Introduction to Software Engineering - CSA2030 Dr. Ernest Cachia Department of Computer Science & A. I.

2. Introduction • Generic definition: “The building of software systems” (coined ~1960s). • D. L. Parnas[1987]: “The multi-person construction of multi-version software”. • Software engineering includes programming but is NOT programming. • Therefore…good programmers are not necessarily good software engineers! (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

3. Summary of Course(cont…) • The aim of this course is to acquaint attendees with some of the fundamental principles of the “still-teething” science of software engineering (SE) • The location and relation of SE with respect to other Computer Science disciplines will be clearly explained (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

4. (...cont.)Summary of Course • It is hoped that this course will highlight the major trends, approaches and techniques used in the development of “sound” software systems. (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

5. Who should you be? • You should be equipped with the following: • Interest in the subject area in general • Basic programming skills (nothing fancy) • Normal understanding of structured programming principles (e.g. CSA1010) • Ability to think in a structured manner • Ability to adhere to discipline in your actions • Ability to keep an open mind in the face of radically new approaches (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

6. Software Engineering overview • The final goal of SE is to build a complete multi-application (usually commercial) software system of considerable complexity and of partial, ideally full, “provability”. • To attain such pretentious aims SE must also be able to effectively bring together the efforts of more than one individual to focus on (usually) one common system. (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

7. The situation (till very lately) • Programming made substantial advances: • Algorithm theory and studies • Data structure theory • Programming language design and application • Introduction of structured programming • Application and design of 4th Generation languages • BUT…programming only is not enough for the development of large software systems! (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

8. A (then) emerging problem • Software development done solely using traditional programming techniques • Computers become more popular - fast • Their potential is better recognised • Software demands become more serious • Software sophistication rockets • Sophistication requires more complex s/w • Complex s/w is generally large in size • Programming is targeted at user-specific small-scale problems (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

9. Comprehend its feasibility Define it clearly as possible structure (architecture) I/O and constraints working parameters function Design its overall structure Design its components Design its integration Implement (actually build) it Test it (according to the specified working parameters) Install it Test it (on site/in function) Maintain it The engineering approach (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

10. A specific example • Building a tuner (or any electronic device): • must specify ALL component working parameters and tolerance levels • rules to correctly locate components on board • ALL specs are standardised • ALL specs are universally understood • Building any software component: • we do not even know which exactly are the parameters that need to be specified (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

11. Available tools (h/w and s/w) • Hardware: • Measuring instruments (meters, probes, scopes, etc.) • Proven mathematical relationships • Adequate established specification standards • Software: • Sparse limited mathematical (formal) tools • Loads of subjective experience and judgment (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

12. Software Engineering in context • SE is only a small part of System Engineering • Most modern systems are made up of elements other than simply software • Software on its own is like a mind without a body - it cannot do anything physical • SE only effects the software component of any real-world system (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

13. Diagrams of SE context The system Flight control system wires sensors All system components that are not software indicators controlling software buttons servo mechanisms software component recording media alarms computer h/w (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

14. Software Engineering roots (cont…) • Main idea: Make the machine do something usefull BUT a while ago the application of computers was limited • Therefore there was a 1-to-1 (personal) relationship between user and machine to make it do only user-specific tasks • eg. Solve an equation, manipulate an array, etc. • Often ONLY THE USER WAS THE PROGRAMMER (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

15. (...cont)Software Engineering roots(cont…) • With the introduction of High-level Languages the idea of a “programmer” was created - now the user need not be the machine’s programmer • Nevertheless only specific user-requested tasks were still being programmed • eg. a program for John’s problem would very likely not interest Mary at all. (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

16. (...cont)Software Engineering roots(cont…) • This separation of concerns introduced the notion of task specification with its associated mis-interpretation problems • The mid 60s saw the first attempts to build large scientific/commercial systems • OS360 (operating system for IBM 360 mainframe family machines) • UNIX (originally written in assembly language) (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

17. (...cont)Software Engineering roots • Due to this flurry of activity in the mid 60s serious problems started to emerge regarding the state of software development • The main realisation was that virtually everything associated with computing had a sound scientific basis - apart from software! • Coining of the terms “Software Engineering” and “Software Crisis” (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

18. Problematic areas • Tasks not well (or at all) understood by everyone taking part in the global solution • Very large communication overheads - often exceeding actual coding • Coding very subjective (according to indivdual’s style) • Changes in requirements (however small) often created repercussions throughout every part of the system (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

19. When copying is right • Large complex systems were being created continually by engineers with relative ease • eg. bridges, factories, plants, aircraft, etc. • These systems seemed to be much more reliable than software systems • Why not emulate the way in which they are constructed? Why apply basic engineering practices to software development also? (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

20. Basic Engineering Practices • Process monitoring and management • Process organisation and delegation • Application of specific tools • Availability/creation of proven theories • Application of specific methodologies • Development of standardised techniques (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

21. The way ahead • The importance of software will always increase (well at least never decrease) • In the 60s the balance of h/w and s/w costs was roughly 96% to 4% - no one really took software seriously • In the early 90s it was 25% to 75% and rising • In 1985 $140 billion spent on software development • In 1995 $750 billion (estimated) (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

22. The basic requirements for a good programmer • Knowledge of data structures and algorithms • Knowledge of at least one (preferably more) programming languages in popular use • A minimal ability to abstractly visualise a specific task COMPARE THESE WITH…. (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

23. The basic requirements for a good software engineer • Be a decent programmer • Understand requirements & translate them into precise specifications • Interface with the user on a non-technical basis • Flexible in his/her application background • Handle abstraction levels with ease • Be able to create different models • Have good planning/delegation abilities and be able to easily communicate his/her thoughts (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

24. Summary • The very nature of software itself has and will change (progress?) • Ways and means of developing better software will result in better harnessing the potential of computing • The mastery of any process will only lead to an improvement in the quality of its product • Better quality usually breeds better productivity (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

25. Attempting to qualify software • Very difficult if done un-scientifically • Akin to qualifying human thought/reasoning • Large amount of factors effecting s/w quality • Large amount of aspects to a s/w product • Very easy to qualify incorrectly • Considerable degree of subjectivity in s/w product • S/w product prone to direct (un-specified) modification (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

26. Some general aspects of s/w • Its development process • Its end-products (with all their representative attributes) • Its interaction with humans (users, developers, process managers, vendors, etc.) • The nature of the real-world process it is to model/simulate • End-user feedback (on s/w product) (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

27. Some quality aspects of software • Quality means different things to different people • User (reliable, efficient, simple to use, etc.) • Producer (maintainable, verifiable, portable, etc.) • Manager (productive and controlled dev., etc.) • Main categories of s/w qualities are: • External (observable by system users) • Internal (structure used to obtain ext. qualities) (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

28. The process makes the product • Process: “A series of activities undertaken to achieve a stipulated entity” • Product: “An entity resulting from a given process” • Quality applies to both process and product • A software product (typically) • Implementation (executable/s) • User manuals • “Source” code • Requirements statement/Design plan/Test data (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

29. Correctness (i/s) Reliability (e/s/p) Robustness (e/s/p) Efficiency (e/s/p) User friendliness (e/s) Verifiability (i/s) Maintainability (i/s/p) Reusability (i/s) Portability (e/s) Understandability (i/s) Interoperability (i/s) Productivity (p) Timeliness (p) Visibility (p) Important s/w process & product qualities “e”- external quality; “i”- internal quality “s”- product quality; “p”- process quality (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

30. Classification of s/w systems • Batch Processing systems • On-line systems • Real-Time systems • Embedded systems • Distributed systems Quality for each of the above can take on a different meaning. (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

31. transaction 1 transaction 2 . . . Processing and remote database transaction n pre-processing and local storage Batch-Processing systems • Important aspects: • Data integrity • Data availability • Data security • Transaction efficiency • HCI effectiveness • Main elements: • Data • Database • Transaction • Security (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

32. Main elements: Result time limits Time-slicing Security Important aspects: Response time range Stimulii to results relationships Communication design/security HCI design terminal 1 terminal 2 local switching (no processing) . . . Remote processing terminal n On-line systems (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

33. Main elements: Stringent timing Control I/O specifications Safety Important aspects: Response timing relationships Response time to activity relationships Control protocol design Safety mechanisms HCI design User control panel(s) User control panel(s) User control panel(s) Controlling computer Controlled devices Controlled devices Controlled devices Real-Time systems (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

34. Main elements: Stringent timing Control I/O specifications System dependency Safety Important aspects: Response timing relationships Response time to activity relationships Control protocol design Safety mechanisms system being controlled Embedded systems Software component Internal control (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

35. Main elements: Process communication Process distribution Data distribution Network links Important aspects: Communication protocols Logical to physical process and data mapping Link reliability Individual process dependencies Data replication and redundency process 1 process n computer or processor 1 computer or processor n process 2 computer or processor 2 Distributed systems doing one task (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

36. Correctness • At the basis of many other s/w qualities • eg. Reliability and robustness • verifyability and performance • Relative to s/w functional specifications • Is a mathematical property • Must show equivalence between s/w and its specification • Experimental (through testing) • Analytical (through formal verification) • Usage of statically analytic tools (HL-languages and modules of them) (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

37. system specification system design system implementation High-level programming language Correctness example standard libraries (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

38. Reliability • Considered to be a relative quality • Direct consequence to system dependability • In its complete form considered to be “ideal” • Guarantees non-existant / disclaimers many • Should imply correctness (not vice-versa) • Assumes (ideally) correctly specified requirements (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

39. Robustness • Should always be considered never ignored • Not a specifiable quality (usually) • Help in better understanding the process being modelled (eg. sky-scraper technology) • Depends considerably on the system’s nature • Not included in system specification (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

40. Efficiency • Direct result of reliability and robustness • Considered to be a relative quantity • Can “make or break” a system • Highly dependent on technology • Effects system scalability • Generically measured in terms of extremes of algorithm time/space/etc. requirements • Should be addressed BEFORE system implementation (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

41. Efficiency evaluation techniques • Generic: Processing time, required space, data traffic, inter-process message traffic. • Measurement: External system monitors for data collection and subsequent evaluation. • Analysis: Application of queuing theory concepts to analyse model of actual system. • Simulation: Build a use a model to actually perform the same actions as the system. (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

42. User friendliness aspects • Please note THREE MAIN types of users: The software The “normal” user The “operator” user The “experienced” user (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

43. User friendliness • How a system appeals to (different) users • Very subjective software quality • Human-Computer Interface is very relevant • Software configuration issues (easy?) • Performance is also relevant to “friendliness” • GUI desgin issues (should be taken seriously) • Standardisation increases user friendliness (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

44. Verifiability • Ease of software quality checking • Not all qualities are of equal verifiability • Could form part of user requirements • Generally implies understandability • Should be an implicit value in development (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

45. Maintainability • Applies to “released” products • Eats up around 65 to 75% of total s/w development costs • Existing software does not “ware out” - it evolves! • Existing sotware can be improved upon • Not akin to hardware maintenance • S/w maintenance can be classified as: • Corrective (sorting out persistent errors - 25%) • Adaptive (due to changes in working env. - 20%) • Perfective (improve system fuctionality - 55%) (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

46. Aspects of maintainability • Repairability (ease of defect correction) • Exists at different levels (like old & modern h/w) • Direct consequence of good (modular) design • Funtional localisation aids repairability • Orthogonal to reliability • Evolvability (change/improve functionality) • Should undergo normal s/w development process • Requires in-depth study of original system • Should not deteriorate in time (i.e. after successive releases) (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

47. Reusability • Using existing products to construct new ones • Important but not often used quality • Directly impacts on evolvability • Some examples: • The UNIX shell (command language interpreter) • Programming language routine libraries • Packages, routines, widgets, etc. in X windows • Human knowledge reuse (?) • Considered a measure of general development process maturity (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

48. Levels of software reuse usage Application-specific level 100% 85% Domain-specific level 85% Information Management Personnel Logistics 20% Domain-independent level Utilities, abstract data struc., GUI functions, PL libraries, system services, I/O functions, generic database services, etc. 20% 0% (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

49. Benefits gained by reuse • Lower development costs • Higher productivity (reduced cycle time) • Lower training costs • Easier maintenance • Lower risk (higher reliability) • Better interoperability • Better portability (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta

50. Internal and external resue “Reuse” library software software Another system software Development team (C) Dr. Ernest Cachia, 1997 Dept. of Computer Science and A. I., University of Malta