We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byNelson Ade
Modified about 1 year ago
© 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
© 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
© 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
© 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
© 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
© 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
© Dr. Ernest CachiaSlide 7 Desirable algorithm properties Clear Unambiguous Alterable Correct (with respect to basic formally provable principles) Easy to comprehend functionality (relatively)
© 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)
© Dr. Ernest CachiaSlide 9 Therefore: SOFTWARE MUST BE ADEQUATELY ENGINEERED RATHER THAN SIMPLY THOUGHT UP AND WRITTEN (hence the term “Software Engineering”)
© 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
© 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!
© 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.
© 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.
© 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.
Requirements (selected from Ian Sommerville slides for “Software Engineering”)
CS 461: Artificial Intelligence Introduction Instructor: Sayera Hafsa.
Lecture 5: Requirements Engineering Dr Valentina Plekhanova University of Sunderland, UK
1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Critical Systems Development IS301.
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 4 Slide 1 Requirements Engineering u Establishing what the customer requires from a software.
IOS103 OPERATING SYSTEM VIRTUAL MEMORY. Objectives At the end of the course, the student should be able to: Define virtual memory; Discuss the demand.
STRONG METHOD PROBLEM SOLVING. Human experts are able to perform at a high level because they know a lot about their areas of expertise. This fact is.
Structured Design The Structured Design Approach (also called Layered Approach) focuses on the conceptual and physical level. As discussed earlier: Conceptual.
Advanced Software Engineering by Prof. Dr Jan Pajak Topic ASE-1 Introduction.
1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Critical Systems Validation IS301.
PLANNING THE AUDIT Individual audits must be properly planned to ensure: Appropriate and sufficient evidence is obtained to support the auditors opinion;
Basic SDLC Models. Agenda SDLC definition Waterfall SDLC V-Shape SDLC Spiral SDLC RUP SDLC Agile methods.
UNIT V: LEARNING. LEARNING Learning from Observation Inductive Learning Decision Trees Explanation based Learning Statistical Learning methods Reinforcement.
Unit-V -SOFTWARE QUALITY. To develop and deliver robust system, we need a high level of confidence that Each component will behave correctly Collective.
Testing Relational Database. Overview Once the design of a database system has been completed, the developers are ready to move into the implementation.
Introduction to Programming Logic Instructor: Professor Stephen Osborne.
Copyright © 2005 Finetix LLC All Rights Reserved Test Driven Development and Mock Objects DevSession July Chris Donnan-
Evaluation of User Interface Design Evaluation is very important in User Interface Design and it is generally considered that there is no way round evaluation.
Artificial Intelligence 17. Genetic Programming Course V231 Department of Computing Imperial College © Simon Colton.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 1 Slide 1 Chapter 1 Introduction.
Introduction to Logic and Prolog Sabu Francis, B.Arch (Hons)
© Gerald Kotonya and Ian Sommerville 2010 Requirements Validation.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 1 Chapter 29 Configuration Management.
Agent Based Software Development Michael Luck, Ronald Ashri and Mark dInverno Chapter 4: Methodologies and Modeling Languages.
Introduction to Project Management session 1. Project management Over the course we will look at: Projects and their features. The project Life Cycle,
5 Why’s Overview. Five Why’s Preparation ProblemRoot Cause Corrective Actions Root Cause analysis Tools: Ishikawa Charts (Fish Bone) Design of Experiments.
A Framework for Network Visualisation Progress Report Report to IST-063/RWS-010 by the IST-059/RTG-025 Working Group on Framework for Network Visualisation.
Nica Valentin–Danut SEM 2012 Service system fundamentals: Work system, value chain, and life cycle.
Help Desk Procedures Topic: Tasks of the Help Desk Operator Written by Greg Webb while at Information Technology, Sydney Institute of Technology. Current.
Project Management in Team Software Projects The primary challenge of project management is to achieve all of the goals of the project charter while adhering.
© 2016 SlidePlayer.com Inc. All rights reserved.