1. © 2003 - Dr. Ernest CachiaSlide 1 Consider the nature of a computer as a tool –Non conventional in that it’s universal –Reasons for it being so (separation of entities) –The current computer organisation model (Von Neumann) To begin with... physical processing part abstract control part COMPUTING SYSTEM

2. © 2003 - Dr. Ernest CachiaSlide 2 The model parts Inference: The abstract control structure should basically conform to this model The current computer organisation model (Von Neumann) The processing part The data storage part The input/output part

3. © 2003 - Dr. Ernest CachiaSlide 3 Algorithm components Tightly based on the hardware organisation they are to control Processing (executive) components Data storage (memory) components Inputting (data receiving) components Outputting (data transmitting) components

4. © 2003 - Dr. Ernest CachiaSlide 4 Data In singular form, “datum”. Datum \Da"tum\, n.; pl. Data. [L. See 2d Date.] 1. Something given or admitted; a fact or principle granted; that upon which an inference or an argument is based; -- used chiefly in the plural.DataDate Webster’s Revised Unabridged Dictionary (1913) Data in its pure form is actually meaningless For data to convey meaning it must be given structure Information = Data + Structure

5. © 2003 - Dr. Ernest CachiaSlide 5 Abstract data controlling the hardware (i. e. software) No modern idea - has been around since Victorian era (Charles Babbage & Ada Lovelace) Renders a computing system different from other tools (universality) Forces a more formal definition of process models Must match human thought patterns Must be represent-able Must be understandable to both human and machine

6. © 2003 - Dr. Ernest CachiaSlide 6 The idea of an algorithm A possible informal definition –A stepwise description of time separated actions with respect to time which are required to perform a definite task Steps preceding the effective application of an algorithm –Conceive the task –Define the task –Specify the requirements Entities resulting from the effective application of an algorithm –The implemented system or a model of it –The system’s complete and matching documentation –The software’s full and matching description

7. © 2003 - Dr. Ernest CachiaSlide 7 Desirable algorithm properties Clear Unambiguous Alterable Correct (with respect to basic formally provable principles) Easy to comprehend functionality (relatively)

8. © 2003 - Dr. Ernest CachiaSlide 8 The “status quo” in computing Historically hardware has always developed at a faster rate than software This fact was not given real importance till the late 1980’s Hardware must be engineered to work at all while software need not Software is expected to contain bugs Software is fragile Your life could very well depend on software Conclusion: Software is at least as important as hardware (if not more in some aspects)

9. © 2003 - Dr. Ernest CachiaSlide 9 Therefore: SOFTWARE MUST BE ADEQUATELY ENGINEERED RATHER THAN SIMPLY THOUGHT UP AND WRITTEN (hence the term “Software Engineering”)

10. © 2003 - Dr. Ernest CachiaSlide 10 Some “disturbing” facts about software development in the late 1980s and early 1990s (1/2) Most software was never well planned from the start and was never designed using rigorous design methods Software was not quantifiable or qualify-able until its actual application Software was extremely fragile (i.e. unreliable) Software rarely fully matched its requirements

11. © 2003 - Dr. Ernest CachiaSlide 11 Some “disturbing” facts about software development in the late 1980s and early 1990s (2/2) Software development involved considerable duplication of effort The idea of software prototyping was to run the system and do a post-mortem check when it failed When software did work well and reliably there was a rush to find out why! Conclusion: Founding a discipline based on such ad hoc software development methods is not feasible!

12. © 2003 - Dr. Ernest CachiaSlide 12 High demand on software The demands and expectations from software is nowadays dramatically increasing by literally by the day. People are starting to appreciate the idea of fully reliable software. Particular critical areas include: Real-time embedded systems Safety-critical systems –High finance –Machine automation Life-critical systems –Civil –Military Any others I might have left out.

13. © 2003 - Dr. Ernest CachiaSlide 13 Strange sort of situation Machine hardware is generally well engineered (otherwise it probably wouldn’t work at all) Software is recognised to be crucial Software controls the functioning of machine hardware in an absolute sense Software is often not engineered well (or at all) Faulty software inevitably means machine (computer) “malfunction” People are happy to entrust their dearest possessions, and indeed, their life to computers or computer controlled systems.

14. © 2003 - Dr. Ernest CachiaSlide 14 The panic! In the mid 80s people began to worry about the sorry state of software development. By the late 80s this worry became a panic, the main reasons being: –The evident poor quality of software –The huge jump in reliability demand as software started to control even more critical aspects of society –The very poor choice (if any) of software design, verification and implementation standards People simply didn’t pay serious enough attention to software in the past - now that a crises was created, attention was “force-focused” on it.