Principles of Engineering System Design Dr T Asokan

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

Principles of Engineering System Design Dr T Asokan
Principles of Engineering System Design Dr T Asokan
Use-Cases.
Database System Concepts and Architecture
Lecture 8: Testing, Verification and Validation
Chapter 10 Software Testing
Principles of Engineering System Design Dr T Asokan
Information System Audit : © South-Asian Management Technologies Foundation Chapter 4: Information System Audit Requirements.
Software Quality Assurance Plan
Systems Analysis and Design Feasibility Study. Introduction The Feasibility Study is the preliminary study that determines whether a proposed systems.
Object-Oriented Software Construction Bertrand Meyer 2nd ed., Prentice Hall, 1997.
CMMI – Continuous as well as staged model CMMI capability levels – Incomplete, performed, managed, defined, quantitatively managed, optimized Example.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Client/Server Databases and the Oracle 10g Relational Database
Software Testing and Quality Assurance
Lecture 13 Revision IMS Systems Analysis and Design.
SIM5102 Software Evaluation
Nov. 14, 2007 Systems Engineering ä System ä A set or arrangement of things so related as to form a unity or organic whole. ä A set of facts, principles,
Introduction to Software Engineering Dr. Basem Alkazemi
Managing Information Systems Information Systems Security and Control Part 2 Dr. Stephania Loizidou Himona ACSC 345.
System Engineering Instructor: Dr. Jerry Gao. System Engineering Jerry Gao, Ph.D. Jan System Engineering Hierarchy - System Modeling - Information.
Network security policy: best practices
Functional Testing Test cases derived from requirements specification document – Black box testing – Independent testers – Test both valid and invalid.
Unit 3a Industrial Control Systems
Software Testing Verification and validation planning Software inspections Software Inspection vs. Testing Automated static analysis Cleanroom software.
Dr. Pedro Mejia Alvarez Software Testing Slide 1 Software Testing: Building Test Cases.
Computer Programming and Basic Software Engineering 4. Basic Software Engineering 1 Writing a Good Program 4. Basic Software Engineering.
Team Members Lora zalmover Roni Brodsky Academic Advisor Professional Advisors Dr. Natalya Vanetik Prof. Shlomi Dolev Dr. Guy Tel-Zur.
Lesson 8-Information Security Process. Overview Introducing information security process. Conducting an assessment. Developing a policy. Implementing.
1 Object-Oriented Testing CIS 375 Bruce R. Maxim UM-Dearborn.
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
SCOTT KURODA ADVISOR: DR. FRANZ KURFESS Encouraging Secure Programming Practice in Academia.
1 BTEC HNC Systems Support Castle College 2007/8 Systems Analysis Lecture 9 Introduction to Design.
11 SECURITY TEMPLATES AND PLANNING Chapter 7. Chapter 7: SECURITY TEMPLATES AND PLANNING2 OVERVIEW  Understand the uses of security templates  Explain.
Information Systems Analysis and Design
FCS - AAO - DM COMPE/SE/ISE 492 Senior Project 2 System/Software Test Documentation (STD) System/Software Test Documentation (STD)
Engineering System Design
Testing Basics of Testing Presented by: Vijay.C.G – Glister Tech.
RELATIONAL FAULT TOLERANT INTERFACE TO HETEROGENEOUS DISTRIBUTED DATABASES Prof. Osama Abulnaja Afraa Khalifah
BE-SECBS FISA 2003 November 13th 2003 page 1 DSR/SAMS/BASP IRSN BE SECBS – IRSN assessment Context application of IRSN methodology to the reference case.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
1 Chpt. 12: INFORMATION SYSTEM QUALITY, SECURITY, AND CONTROL.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development 3.
Information System Audit : © South-Asian Management Technologies Foundation Chapter 10 Case Study: Conducting an Information Systems Audit.
1 CMPT 275 High Level Design Phase Modularization.
IT Risks and Controls Revised on Content Internal Control  What is internal control?  Objectives of internal controls  Types of internal controls.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Slide 1 Security Engineering. Slide 2 Objectives l To introduce issues that must be considered in the specification and design of secure software l To.
IS2210: Systems Analysis and Systems Design and Change Twitter:
Software Quality Assurance and Testing Fazal Rehman Shamil.
 Software Testing Software Testing  Characteristics of Testable Software Characteristics of Testable Software  A Testing Life Cycle A Testing Life.
HNDIT23082 Lecture 09:Software Testing. Validations and Verification Validation and verification ( V & V ) is the name given to the checking and analysis.
Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Hibatűrő rendszerek tervezési mintái Segédfóliák az Autonóm.
Software Engineering Lecture 10: System Engineering.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Troubleshooting Windows Vista Lesson 11. Skills Matrix Technology SkillObjective DomainObjective # Troubleshooting Installation and Startup Issues Troubleshoot.
Week#3 Software Quality Engineering.
INFORMATION SYSTEMS SECURITY AND CONTROL.
PREPARED BY G.VIJAYA KUMAR ASST.PROFESSOR
Information Systems Development
Chapter 11 Designing Inputs, Outputs, and Controls.
Chapter 11: Software Configuration Management
Architecture Concept Documents
Security Engineering.
Systems Analysis and Design in a Changing World, 6th Edition
Chapter 11: Software Configuration Management
Reliability and Safety
System Reengineering Restructuring or rewriting part or all of a system without changing its functionality Applicable when some (but not all) subsystems.
Presentation transcript:

Principles of Engineering System Design Dr T Asokan

INTRODUCTION TO SYSTEMS DESIGN Functional Decomposition using IDEF0 diagram: Example

Example: Unified Data REcording System - UDARE Objectives: Online recording and compilation of attendance for students/staff/faculty on day ‐ to ‐ day basis. Real time analysis of slot ‐ wise engagement of students/faculty. Serve as a real time data base for leave/salary/scholarship computation. Serve as a real time data base for students’ feedback on courses/ feedback analysis. Serve as a real time centralized data base for fees records of all students. A real time data base for venue allocation/time slots for year long Lit ‐ Soc activities happening in the institute

Use U-Dare Services Provide U- Dare Services Request Services Students StaffFaculty Maintenance personnel Software regulations Main server Internet server

A-0 Context diagram

Provide utility services (A4)

Data search request User Identity Authentication (A1) Accept user request/provid e feedback (A2) Control operation (A3) Provide utility services (A4) Maintenance and repair (A5) Feedback Display data Provide navigation services Proper functioning Enable cashless transaction UDARE SYSTEM Network databasePower supply Navigation request Cashless transaction request Maintenance services A0 diagram:

Data search request Process request (A31) Search for data (A32) Extract data (A33) Feedback Provide navigation details Transaction details Display information UDARE Network databasePower supply Navigation request Cashless transaction request A3 diagram:

A32 diagram: Network database Power supply Connect to the network (A321) Login and password Search for desired data in the network database (A322) Extract data from the network UDARE

A32 diagram:

A322 diagram Network database Power supply Find the category of the information asked by the user A3321 Connect to the network Collect data from the corresponding category (academic/ administrative/ general) A3322 Extract data UDARE

A11 PROVIDE U-DARE SERVICE User identity Authentication Accept user request/ provide feed back Control operation Provide services Maintenance and repair Process requestSearch data Extract data Connect to network Search for data in database Find the category of infunction asked by user Collect data Lower-level function A31211 A31212 A31213A31221 A31222 A31223 A3122 A3121 A3211A3212 A3213 … A321 A331 Level-3 function A332 A311 A312 A31 A33A32 A12 … A21A22A23 A1 A2 A3 A4 A5 Level-2 function Level-1 function A41A42 A43 …. A51 A52 A53 … A322

Common mistakes in Developing Functional Architecture Including external systems and their functions Choosing the wrong name for a function Creating a decomposition of a function that is not a partition of that function Violating the law of conservation of inputs, outputs, or controls

Finishing the Functional Architecture Defining System errors and the failure modes and inserting functionality to detect the errors and recover Inserting appropriate functionality for some combination of built-in-self-test (BIST) and external testability

Error detection Functions Failure: Deviation in behavior between the system and its requirements Error : A subset of the system state, which may lead to system failure. Fault: a defect in the system that can cause an error. Fault tolerance is the ability of a system to tolerate faults and continue performing.

Fault tolerance can be achieved only for those errors that are observed. Functions associated with fault tolerance are: Error detection Damage confinement Error recovery Fault isolation and reporting

Error detection is defining possible errors, deviations in the subset of the system’s state from the desired state, in the design phase before they occur, and establishing a set of functions for checking for the occurrence of each error. –Type checks, range checks, timing checks Damage confinement is protecting the system from the possible spread of failure to other parts of the system. Firewalls

Error recovery attempts to correct the error after the error has been detected and the errors extent defined. Backward recovery, forward recovery Fault isolation and reporting attempts to determine where in the system the fault occurred that generated the error.

Functions for error detection, damage confinement, error recovery, and fault isolation and reporting should be included in the functional architecture. These functions should be defined for each state variable of the system.

Tracing Requirements to functional Architecture All elements of the set of input/output requirements should be traced to appropriate functions that have been defined in the functional decomposition

Tracing Requirements to Functional Architecture

Functional model review Once a functional model is developed, it should be reviewed by individuals that have substantial knowledge of the system’s functioning This review should : Try alternative decompositions Disaggregate the functions differently Reevaluate functional dominance in terms of feedback and control Catch interface errors

Summary Need for functional modelling Procedure De-composition and composition Hately-Pirbhai Template IDEF0 modelling Evaluation- Scenario tracing Fault tolerance Requirement mapping