SENG521 (Fall SENG 521 Software Reliability & Testing Operational Profiles (Part 5b) Department of Electrical & Computer Engineering,

Slides:



Advertisements
Similar presentations
Medical Device Software Development
Advertisements

10 Software Engineering Foundations of Computer Science ã Cengage Learning.
1 Software Engineering Lecture 11 Software Testing.
Information Systems Analysis and Design
[Insert Project Name] Detailed Design Review (DDR) [Insert Date of DDR] Centers for Medicare & Medicaid Services eXpedited Life Cycle (XLC)
Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
© 2005 by Prentice Hall Chapter 4 System Testing & Implementation Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph.
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer.
Overview of Software Requirements
1 Lecture 5 Introduction to Software Engineering Overview  What is Software Engineering  Software Engineering Issues  Waterfall Model  Waterfall Model.
System Development Life Cycle (SDLC)
Chapter 9 Database Design
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
SENG521 (Fall SENG 521 Software Reliability & Testing Defining Necessary Reliability (Part 3b) Department of Electrical & Computer.
SDLC and Related Methodologies
Managing Projects
Object-Oriented Analysis and Design
The Project AH Computing. Functional Requirements  What the product must do!  Examples attractive welcome screen all options available as clickable.
Chapter 7 Requirement Modeling : Flow, Behaviour, Patterns And WebApps.
Exam examples Tor Stålhane. The A scenario – 1 We are working in a small software development company – 10 developers plus two persons in administrative.
System Implementation. System Implementation and Seven major activities Coding Testing Installation Documentation Training Support Purpose To convert.
1 Building and Maintaining Information Systems. 2 Opening Case: Yahoo! Store Allows small businesses to create their own online store – No programming.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa USE CASES In this lecture: Use cases - What are use.
1 BTEC HNC Systems Support Castle College 2007/8 Systems Analysis Lecture 9 Introduction to Design.
Cmpe 589 Spring Software Quality Metrics Product  product attributes –Size, complexity, design features, performance, quality level Process  Used.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
ITEC224 Database Programming
Fall CIS 764 Database Systems Engineering L21: Status Project Reviews Testing.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 21. Review ANALYSIS PHASE (OBJECT ORIENTED DESIGN) Functional Modeling – Use case Diagram Description.
 Chapter 6 Architecture 1. What is Architecture?  Overall Structure of system  First Stage in Design process 2.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
Requirements Documentation CSCI 5801: Software Engineering.
Database Administration COMSATS INSTITUTE OF INFORMATION TECHNOLOGY, VEHARI.
TESTING FOR THE RELIABILITY OF A SOFTWARE SARAT CHANDRA YADAVALLI CSC 532 TERM PAPER.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
UML-1 8. Capturing Requirements and Use Case Model.
Topics Covered Phase 1: Preliminary investigation Phase 1: Preliminary investigation Phase 2: Feasibility Study Phase 2: Feasibility Study Phase 3: System.
 An Information System (IS) is a collection of interrelated components that collect, process, store, and provide as output the information needed to.
Requirements Analysis
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
Software Engineering Lecture 8: Quality Assurance.
Requirement Analysis SOFTWARE ENGINEERING. What are Requirements? Expression of desired behavior Deals with objects or entities, the states they can be.
ECE 448 Lecture 6 Finite State Machines State Diagrams vs. Algorithmic State Machine (ASM) Charts.
1 Unified Modeling Language Michael K. Wildes University of California, Riverside – Extension Program Presentation 2.
Systems and User Interface Software. Types of Operating System  Single User  Multi User  Multi-tasking  Batch Processing  Interactive  Real Time.
Lecturer: Eng. Mohamed Adam Isak PH.D Researcher in CS M.Sc. and B.Sc. of Information Technology Engineering, Lecturer in University of Somalia and Mogadishu.
SENG521 (Fall SENG 521 Software Reliability & Testing Preparing for Test (Part 6a) Department of Electrical & Computer Engineering,
1 Week 5 Software Engineering Fall Term 2015 Marymount University School of Business Administration Professor Suydam.
SDLC and Related Methodologies
Information Systems Development
Medical Device Software Development
Software Project Configuration Management
System.
ITEC 3220A Using and Designing Database Systems
Architecture Concept Documents
System Development Life Cycle (SDLC)
Summary: The Systems Development Life Cycle
System Development Life Cycle (SDLC)
Information Systems Development
Verification and Validation Unit Testing
Personal Software Process Software Estimation
Programming Languages
System Development Life Cycle (SDLC)
Analysis models and design models
SDLC and Related Methodologies
Presentation transcript:

SENG521 (Fall SENG 521 Software Reliability & Testing Operational Profiles (Part 5b) Department of Electrical & Computer Engineering, University of Calgary B.H. Far ( )

SENG521 (Fall Review: Operational Profile Operational Profile Operational Profile is the set of disjoint operations (i.e., a major system logical task of short duration, which returns control to the system when complete and whose processing is substantially different from other operations. ) and their probabilities of occurrences. From engineering point of view, one usually starts with examining the work process and defines operational profiles for the software (and/or hardware) system that implements activities of the work process. System operational profile System operational profile must be developed for all of its important operational modes.

SENG521 (Fall How to: Procedure 1.Determine operational modes. 2.Identify initiator of operations. 3.Select representation. 4.Create functions/operations list. 5.Determine occurrence rate of individual operations of attribute values. 6.Determine occurrence probabilities by dividing individual occurrence rate by total occurrence rates.

SENG521 (Fall 1. Operational Modes Determine all possible operational modes and select only the most critical ones based on various factors such as: Time (time of year, day of week, time of day) Different user types (customer or user) Users experiences (novice or expert) Operational conditions (online retail sale mode, overload mode, continuous operation mode) Reduced system capability Criticality (shutdown mode for nuclear power plants)

SENG521 (Fall 2. Operation Initiators Possible system initiators (Actors in Use Cases): Users of the system Users of the system (anyone who initiates an event on the system, including system administrators, customer type and user type) External systems External systems (other systems interfaced with the system under development) System’s own controller System’s own controller (administrative and/or maintenance tasks: audits, backups, etc.)

SENG521 (Fall 3. Select Representation Use tabular representation if there are only a few attributes for each operation Use graphical representation if most of the operations are described by multiple attributes. It is possible to select a mixed mode of representation or converting between the two representations.

SENG521 (Fall 4. Operations List Break down each operation mode into the operations it needs. Number of operations Explicit vs. implicit operations Initial operations list Environmental variables Final operations list

SENG521 (Fall 4.1 No. of Operations The cost of reliability and testing is directly proportional to the total number of operations. Usually between 20 and a few hundreds. This number increases by the project size, operation mode, number of key input variables, etc. Usually better to reduce this number to reflect the most important operations that can cover all situations of substantially different processing.

SENG521 (Fall 4.2 Explicit or Implicit /1 Key input variable: Key input variable: is a variable that is common to input state of two or more operations and whose value is needed to differentiate among those operations. Implicit Profile: Implicit Profile: Expressed in terms of a sequence of sub profiles each representing a key input variable and its conditional probability. Explicit Profile: Explicit Profile: Expressed in terms of sequence of values for all its key input variables. It is usually easier to express in implicit form.

SENG521 (Fall 4.2 Explicit or Implicit /2 Example: Implicit profile: Input variable AInput variable B valueprobabilityvalueprobability A10.6B10.7 A20.3B20.2 A30.1B30.1 Example: Explicit Profile: A1B10.42A1B20.12A1B30.06 A2B10.21A2B20.06A2B30.03 A3B10.07A3B20.02A3B30.01

SENG521 (Fall 4.3 Initial Operations List Initial operations list is a tentative list of operations usually separated by the operation modes and operation initiators Sources (and documents) helpful to determine the initial operations: system requirements (prime source) Use Cases, functional models work process flow diagrams draft user manuals previous releases or former versions of the software prototypes

SENG521 (Fall 4.4 Environment Variables Environmental variables describe the conditions that affect the way the program runs (the control path it takes and the data it accesses) Example: traffic load, hardware configuration, operating system configuration Some of the environment variables may map to operation modes List up all the environmental variables that might cause the program to respond in different ways and then decide which one of these would likely have a major effect on the program.

SENG521 (Fall 4.5 Final Operations List /1 Final operation list is decided based on analysis of initial operation lists and narrowing the list down using data on operation modes environmental variables key input variables dependencies among input variables If correlation between some operations exists (i.e., occurrence of one depends on occurrence of the other) better to merge the operations

SENG521 (Fall 4.5 Final Operations List /2 Distinguish between function and operation may become necessary Some functions (implementing substantially different tasks) may be mapped to a few operations (implementing substantially different processing, code path) Example: “relocate a telephone” function in switching system may map to “removal” and “install” operations

SENG521 (Fall 5. Occurrence Rates /1 Occurrence rates are decided for each operation mode based on field data (if available), system logs, manual data collection and experience. If correlation between some operations is discovered at this stage it is better to merge the operations.

SENG521 (Fall 5. Occurrence Rates /2 Example: Call management system

SENG521 (Fall 6. Occurrence Probabilities Occurrence probabilities are determined by dividing individual occurrence rate for each operation by total occurrence rates.