Скачать презентацию Supplementary Slides for Software Engineering A Practitioner s Approach Скачать презентацию Supplementary Slides for Software Engineering A Practitioner s Approach

338c8a3866936731764c97a0a26842bf.ppt

  • Количество слайдов: 200

Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Part Three copyright © 1996, Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Part Three copyright © 1996, 2001 R. S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 1

Chapter 10 System Engineering These courseware materials are to be used in conjunction with Chapter 10 System Engineering These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 2

The Hierarchy These courseware materials are to be used in conjunction with Software Engineering: The Hierarchy These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 3

Business Process Engineering uses an integrated set of procedures, methods, and tools to identify Business Process Engineering uses an integrated set of procedures, methods, and tools to identify how information systems can best meet the strategic goals of an enterprise focuses first on the enterprise and then on the business area creates enterprise models, data models and process models creates a framework for better information management distribution, and control These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 4

The BPE Hierarchy Information strategy planning (ISP) strategic goals defined success factors/business rules identified The BPE Hierarchy Information strategy planning (ISP) strategic goals defined success factors/business rules identified enterprise model created Business area analysis (BAA) processes/services modeled interrelationships of processes and data Application Engineering a. k. a. . . software engineering modeling applications/procedures that address (BAA) and constraints of ISP Construction and delivery using CASE and 4 GTs, testing These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 5

Information Strategy Planning Management issues define strategic business goals/objectives isolate critical success factors conduct Information Strategy Planning Management issues define strategic business goals/objectives isolate critical success factors conduct analysis of technology impact perform analysis of strategic systems Technical issues create a top-level data model cluster by business/organizational area refine model and clustering These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 6

Defining Objectives and Goals Objective—general statement of direction Goal—defines measurable objective: “reduce manufactured cost Defining Objectives and Goals Objective—general statement of direction Goal—defines measurable objective: “reduce manufactured cost of our product” Subgoals: decrease reject rate by 20% in first 6 months gain 10% price concessions from suppliers re-engineer 30% of components for ease of manufacture during first year objectives tend to be strategic while goals tend to be tactical These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 7

Business Area Analysis define “naturally cohesive groupings of business functions and data” (Martin) perform Business Area Analysis define “naturally cohesive groupings of business functions and data” (Martin) perform many of the same activities as ISP, but narrow scope to individual business area identify existing (old) information systems / determine compatibility with new ISP model define systems that are problematic defining systems that are incompatible with new information model begin to establish re-engineering priorities These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 8

The BAA Process admin. manufacturing sales QC distribution acct eng’ring Process Flow Models Data The BAA Process admin. manufacturing sales QC distribution acct eng’ring Process Flow Models Data Model Process Decomp. Diagram Matrices e. g. , entity/process matrix These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 9

Product Engineering These courseware materials are to be used in conjunction with Software Engineering: Product Engineering These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 10

Requirements Engineering Elicitation — determining what the customer requires Analysis & negotiation — understanding Requirements Engineering Elicitation — determining what the customer requires Analysis & negotiation — understanding the relationships among various customer requirements and shaping those relationships to achieve a successful result Requirements specification — building a tangible model of requirements These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 11

Requirements Engineering System Modeling — building a representation of requirements that can be assessed Requirements Engineering System Modeling — building a representation of requirements that can be assessed for correctness, completeness, and consistency Validation — reviewing the model Management — identify, control and track requirements and the changes that will be made to them These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 12

Product Architecture Template These courseware materials are to be used in conjunction with Software Product Architecture Template These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 13

Architecture Flow Diagram These courseware materials are to be used in conjunction with Software Architecture Flow Diagram These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 14

Chapter 11 Analysis Concepts and Principles These courseware materials are to be used in Chapter 11 Analysis Concepts and Principles These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 15

What Are the Real Problems? the customer has only a vague idea of what What Are the Real Problems? the customer has only a vague idea of what is required the developer is willing to proceed with the "vague idea" on the assumption that "we'll fill in the details as we go" the customer keeps changing requirements the developer is "racheted" by these changes, making errors in specifications and development and so it goes. . . These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 16

Software Requirements Analysis identify the “customer” and work together to negotiate “product-level” requirements build Software Requirements Analysis identify the “customer” and work together to negotiate “product-level” requirements build an analysis model focus on data define function represent behavior prototype areas of uncertainty develop a specification that will guide design conduct formal technical reviews These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 17

Requirements Gathering Facilitated Application Specification Techniques Software Engineering Group Customer Group These courseware materials Requirements Gathering Facilitated Application Specification Techniques Software Engineering Group Customer Group These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 18

FAST Guidelines participants must attend entire meeting all participants are equal preparation is as FAST Guidelines participants must attend entire meeting all participants are equal preparation is as important as meeting all pre-meeting documents are to be viewed as “proposed” off-site meeting location is preferred set an agenda and maintain it don’t get mired in technical detail J. Wood & D. Silver These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 19

Quality Function Deployment Function deployment determines the “value” (as perceived by the customer) of Quality Function Deployment Function deployment determines the “value” (as perceived by the customer) of each function required of the system Information deployment identifies data objects and events Task deployment examines the behavior of the system Value analysis determines the relative priority of requirements These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 20

Use-Cases A collection of scenarios that describe thread of usage of a system Each Use-Cases A collection of scenarios that describe thread of usage of a system Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way Each scenario answers the following questions: What are the main tasks of functions performed by the actor? What system information will the actor acquire, produce or change? Will the actor inform the system about environmental changes? What information does the actor require of the system? Does the actor wish to be informed about unexpected changes These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 21

The Analysis Process build a prototype the problem requirements elicitation develop Specification Review create The Analysis Process build a prototype the problem requirements elicitation develop Specification Review create analysis models These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 22

Analysis Principle I Model the Data Domain define data objects describe data attributes establish Analysis Principle I Model the Data Domain define data objects describe data attributes establish data relationships These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 23

Analysis Principle II Model Function identify functions that transform data objects indicate how data Analysis Principle II Model Function identify functions that transform data objects indicate how data flow through the system represent producers and consumers of data These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 24

Analysis Principle III Model Behavior indicate different states of the system specify events that Analysis Principle III Model Behavior indicate different states of the system specify events that cause the system to change state These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 25

Analysis Principle IV Partition the Models refine each model to represent lower levels of Analysis Principle IV Partition the Models refine each model to represent lower levels of abstraction refine data objects create a functional hierarchy represent behavior at different levels of detail These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 26

Analysis Principle V Essence begin by focusing on the essence of the problem without Analysis Principle V Essence begin by focusing on the essence of the problem without regard to implementation details These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 27

Davis’ Principles Understand the problem before you begin to create the analysis model. Develop Davis’ Principles Understand the problem before you begin to create the analysis model. Develop prototypes that enable a user to understand how human-machine interaction will occur. Record the origin of and the reason for every requirement. Use multiple views of requirements. Prioritize requirements. Work to eliminate ambiguity. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 28

The Analysis Model Data Model Functional Model Behavioral Model These courseware materials are to The Analysis Model Data Model Functional Model Behavioral Model These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 29

Chapter 12 Analysis Modeling These courseware materials are to be used in conjunction with Chapter 12 Analysis Modeling These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 30

Analysis Modeling: Where to Begin? A statement of scope can be acquired from: the Analysis Modeling: Where to Begin? A statement of scope can be acquired from: the FAST working document A set of use-cases the statement of scope must be “parsed” to extract data, function and behavioral domain information These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 31

Statement of Scope a relatively brief description of the system to be built indicates Statement of Scope a relatively brief description of the system to be built indicates data that are input and output and basic functionality indicates conditional processing (at a high level) implies certain constraints and limitations These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 32

Identifying Objects and Operations define “objects” by underlining all nouns in the written statement Identifying Objects and Operations define “objects” by underlining all nouns in the written statement of scope producers/consumers of data places where data are stored “composite” data items define “operations” by double underlining all active verbs processes relevant to the application data transformations consider other “services” that will be required by the objects These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 33

Data Modeling and Entity Relationship (E-R) Diagramming These courseware materials are to be used Data Modeling and Entity Relationship (E-R) Diagramming These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 34

Why Data Modeling? examines data objects independently of processing focuses attention on the data Why Data Modeling? examines data objects independently of processing focuses attention on the data domain creates a model at the customer’s level of abstraction indicates how data objects relate to one another These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 35

What is a Data Object? Object —something that is described by a set of What is a Data Object? Object —something that is described by a set of attributes (data items) and that will be manipulated within the software (system) each instance of an object (e. g. , a book) can be identified uniquely (e. g. , ISBN #) each plays a necessary role in the system i. e. , the system could not function without access to instances of the object each is described by attributes that are themselves data items These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 36

Typical Objects external entities (printer, user, sensor) things (e. g, reports, displays, signals) occurrences Typical Objects external entities (printer, user, sensor) things (e. g, reports, displays, signals) occurrences or events (e. g. , interrupt, alarm) roles (e. g. , manager, engineer, salesperson) organizational units (e. g. , division, team) places (e. g. , manufacturing floor) structures (e. g. , employee record) These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 37

Data Objects and Attributes A data object contains a set of attributes that act Data Objects and Attributes A data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the object: automobile attributes: make model body type price options code These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 38

What is a Relationship? relationship —indicates “connectedness”; a What is a Relationship? relationship —indicates “connectedness”; a "fact" that must be "remembered" by the system and cannot or is not computed or derived mechanically several instances of a relationship can exist objects can be related in many different ways These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 39

ERD Notation One common form: object 1 (0, m) relationship (1, 1) object 2 ERD Notation One common form: object 1 (0, m) relationship (1, 1) object 2 attribute Another common form: object 1 relationship (0, m) (1, 1) object 2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 40

Building an ERD Level 1—model all data objects (entities) and their “connections” to one Building an ERD Level 1—model all data objects (entities) and their “connections” to one another Level 2—model all entities and relationships Level 3—model all entities, relationships, and the attributes that provide further depth These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 41

The ERD: An Example Customer (1, 1) places (1, m) request for service (1, The ERD: An Example Customer (1, 1) places (1, m) request for service (1, 1) standard task table (1, 1) work selected from (1, w) tasks materials generates (1, n) (1, w) (1, i) work order (1, 1) consists of lists These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 42

Creating a Flow Model These courseware materials are to be used in conjunction with Creating a Flow Model These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 43

The Flow Model Every computer-based system is an information transform. . input computer based The Flow Model Every computer-based system is an information transform. . input computer based system output These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 44

Flow Modeling Notation external entity process data flow data store These courseware materials are Flow Modeling Notation external entity process data flow data store These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 45

External Entity A producer or consumer of data Examples: a person, a device, a External Entity A producer or consumer of data Examples: a person, a device, a sensor Another example: computer-based system Data must always originate somewhere and must always be sent to something These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 46

Process A data transformer (changes input to output) Examples: compute taxes, determine area, format Process A data transformer (changes input to output) Examples: compute taxes, determine area, format report, display graph Data must always be processed in some way to achieve system function These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 47

Data Flow Data flows through a system, beginning as input and be transformed into Data Flow Data flows through a system, beginning as input and be transformed into output. base height compute triangle area These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 48

Data Stores Data is often stored for later use. sensor # report required sensor Data Stores Data is often stored for later use. sensor # report required sensor #, type, location, age look-up sensor data sensor number type, location, age sensor data These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 49

Data Flow Diagramming: Guidelines all icons must be labeled with meaningful names the DFD Data Flow Diagramming: Guidelines all icons must be labeled with meaningful names the DFD evolves through a number of levels of detail always begin with a context level diagram (also called level 0) always show external entities at level 0 always label data flow arrows do not represent procedural logic These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 50

Constructing a DFD—I review ERD to isolate data objects and grammatical parse to determine Constructing a DFD—I review ERD to isolate data objects and grammatical parse to determine “operations) determine external entities (producers and consumers of data create a level 0 DFD These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 51

Level 0 DFD Example user video source processing request digital video processor requested video Level 0 DFD Example user video source processing request digital video processor requested video signal monitor NTSC video signal These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 52

Constructing a DFD—II write a narrative describing the transform parse to determine next level Constructing a DFD—II write a narrative describing the transform parse to determine next level transforms “balance” the flow to maintain data flow continuity develop a level 1 DFD use a 1: 5 (approx. ) expansion ratio These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 53

The Data Flow Hierarchy x a p 1 a c d level 1 b The Data Flow Hierarchy x a p 1 a c d level 1 b P p 2 level 0 f p 4 p 3 y e g 5 b These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 54

Flow Modeling Notes each bubble is refined until it does just one thing the Flow Modeling Notes each bubble is refined until it does just one thing the expansion ratio decreases as the number of levels increase most systems require between 3 and 7 levels for an adequate flow model a single data flow item (arrow) may be expanded as levels increase (data dictionary provides information) These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 55

DFDs: A Look Ahead analysis model Maps into design model These courseware materials are DFDs: A Look Ahead analysis model Maps into design model These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 56

Behavioral Modeling and Process Specification These courseware materials are to be used in conjunction Behavioral Modeling and Process Specification These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 57

Behavioral Modeling events Outside world behavior Application These courseware materials are to be used Behavioral Modeling events Outside world behavior Application These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 58

The States of a System state—a set of observable circumstances that characterizes the behavior The States of a System state—a set of observable circumstances that characterizes the behavior of a system at a given time state transition—the movement from one state to another event—an occurrence that causes the system to exhibit some predictable form of behavior action—process that occurs as a consequence of making a transition These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 59

Behavioral Modeling make a list of the different states of a system (How does Behavioral Modeling make a list of the different states of a system (How does the system behave? ) indicate how the system makes a transition from one state to another (How does the system change state? ) indicate event indicate action draw a state transition diagram These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 60

State Transition Diagram Notation state event causing transition action that occurs new state These State Transition Diagram Notation state event causing transition action that occurs new state These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 61

State Transition Diagram full and start invoke manage-copying reading operator commands full invoke read-op-input State Transition Diagram full and start invoke manage-copying reading operator commands full invoke read-op-input copies done invoke read-op-input making copies reloading paper empty invoke reload paper jammed invoke problem-diagnosis problem state not jammed invoke read-op-input These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 62

The Control Model the control flow diagram is The Control Model the control flow diagram is "superimposed" on the DFD and shows events that control the processes noted in the DFD control flows—events and control items—are noted by dashed arrows a vertical bar implies an input to or output from a control spec (CSPEC) — a separate specification that describes how control is handled a dashed arrow entering a vertical bar is an input to the CSPEC a dashed arrow leaving a process implies a data condition a dashed arrow entering a process implies a control input read directly by the process control flows do not physically activate/deactivate the processes—this is done via the CSPEC These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 63

Control Flow Diagram These courseware materials are to be used in conjunction with Software Control Flow Diagram These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 64

Control Specification (CSPEC) The CSPEC can be: state transition diagram (sequential spec) state transition Control Specification (CSPEC) The CSPEC can be: state transition diagram (sequential spec) state transition table combinatorial spec decision tables activation tables These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 65

Guidelines for Building a CSPEC list all sensors that are Guidelines for Building a CSPEC list all sensors that are "read" by the software list all interrupt conditions list all "switches" that are actuated by the operator list all data conditions recalling the noun-verb parse that was applied to the software statement of scope, review all "control items" as possible CSPEC inputs/outputs describe the behavior of a system by identifying its states; identify how each state is reach and defines the transitions between states focus on possible omissions. . . a very common error in specifying control, e. g. , ask: "Is there any other way I can get to this state or exit from it? " These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 66

Process Specification (PSPEC) bubble PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts These Process Specification (PSPEC) bubble PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 67

A Design Note PSPEC one or more ”components A Design Note PSPEC one or more ”components" in the software design These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 68

Creating Mini-Specs Software Specification These courseware materials are to be used in conjunction with Creating Mini-Specs Software Specification These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 69

Real-Time Analysis Methods each introduces its own notation, but all propose an approach for Real-Time Analysis Methods each introduces its own notation, but all propose an approach for representing control and separating it from data provide a mechanism for specifying events, states, and distributed processing begin at the analysis level and work to derive processor assignments, tasks and program architectures These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 70

Real-Time Analysis & Design Methods Gomaa, H. , Software Design Methods for Concurrent and Real-Time Analysis & Design Methods Gomaa, H. , Software Design Methods for Concurrent and Real-Time Systems, Addison-Wesley, 1995. Harel, D. et al, "STATEMATE: A Working Environment for the Development of Complex Reactive Systems, IEEE Trans. Software Engineering, vol. 16, no. 3, April, 1990, pp. 403 -414. Hatley, D. J. and I. A. Pirbhai, Strategies for Real-Time System Specification, Dorset House, 1987. Selic, B. , G. Gullekson, and P. Ward, Real-Time Object. Oriented Modeling, Wiley, 1994. Shumate, K. and M. Keller, , Software Specification and Design—A Disciplined Approach For Real-Time Systems, Wiley 1992. Ward, P. T. and S. J. Mellor, Structured Development for Real-Time Systems, 3 volumes, Yourdon Press, 1985, 1986. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 71

The Data Dictionary These courseware materials are to be used in conjunction with Software The Data Dictionary These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 72

Building a Data Dictionary These courseware materials are to be used in conjunction with Building a Data Dictionary These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 73

Data Dictionary Notation These courseware materials are to be used in conjunction with Software Data Dictionary Notation These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 74

Data Dictionary Example These courseware materials are to be used in conjunction with Software Data Dictionary Example These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 75

Writing the Software Specification Everyone knew exactly what had to be done until someone Writing the Software Specification Everyone knew exactly what had to be done until someone wrote it down! These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 76

Specification Guidelines These courseware materials are to be used in conjunction with Software Engineering: Specification Guidelines These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 77

Specification Guidelines These courseware materials are to be used in conjunction with Software Engineering: Specification Guidelines These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 78

Specification Guidelines These courseware materials are to be used in conjunction with Software Engineering: Specification Guidelines These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 79

Chapter 13 Design Concepts and Principles These courseware materials are to be used in Chapter 13 Design Concepts and Principles These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 80

Analysis to Design These courseware materials are to be used in conjunction with Software Analysis to Design These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 81

Where Do We Begin? modeling Prototype Spec Design These courseware materials are to be Where Do We Begin? modeling Prototype Spec Design These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 82

Design Principles The design process should not suffer from ‘tunnel vision. ’ The design Design Principles The design process should not suffer from ‘tunnel vision. ’ The design should be traceable to the analysis model. The design should not reinvent the wheel. The design should “minimize the intellectual distance” [DAV 95] between the software and the problem as it exists in the real world. The design should exhibit uniformity and integration. The design should be structured to accommodate change. The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Design is not coding, coding is not design. The design should be assessed for quality as it is being created, not after the fact. The design should be reviewed to minimize conceptual (semantic) errors. From Davis [DAV 95] These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 83

Fundamental Concepts abstraction—data, procedure, control refinement—elaboration of detail for all abstractions modularity—compartmentalization of data Fundamental Concepts abstraction—data, procedure, control refinement—elaboration of detail for all abstractions modularity—compartmentalization of data and function architecture—overall structure of the software Structural properties Extra-structural properties Styles and patterns procedure—the algorithms that achieve function hiding—controlled interfaces These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 84

Data Abstraction door manufacturer model number type swing direction inserts lights type number weight Data Abstraction door manufacturer model number type swing direction inserts lights type number weight opening mechanism implemented as a data structure These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 85

Procedural Abstraction open details of enter algorithm implemented with a Procedural Abstraction open details of enter algorithm implemented with a "knowledge" of the object that is associated with enter These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 86

Stepwise Refinement open walk to door; reach for knob; open door; walk through; close Stepwise Refinement open walk to door; reach for knob; open door; walk through; close door. repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 87

Modular Design These courseware materials are to be used in conjunction with Software Engineering: Modular Design These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 88

Modularity: Trade-offs What is the Modularity: Trade-offs What is the "right" number of modules for a specific software design? module development cost of software module integration cost optimal number of modules These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 89

Sizing Modules: Two Views These courseware materials are to be used in conjunction with Sizing Modules: Two Views These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 90

Functional Independence These courseware materials are to be used in conjunction with Software Engineering: Functional Independence These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 91

Architecture “The overall structure of the software and the ways in which that structure Architecture “The overall structure of the software and the ways in which that structure provides conceptual integrity for a system. ” [SHA 95 a] Structural properties. This aspect of the architectural design representation defines the components of a system (e. g. , modules, objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods. Extra-functional properties. The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics. Families of related systems. The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability to reuse architectural building blocks. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 92

Information Hiding module controlled interface • algorithm • data structure • details of external Information Hiding module controlled interface • algorithm • data structure • details of external interface • resource allocation policy clients "secret" a specific design decision These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 93

Why Information Hiding? reduces the likelihood of “side effects” limits the global impact of Why Information Hiding? reduces the likelihood of “side effects” limits the global impact of local design decisions emphasizes communication through controlled interfaces discourages the use of global data leads to encapsulation—an attribute of high quality design results in higher quality software These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 94

Chapter 14 Architectural Design These courseware materials are to be used in conjunction with Chapter 14 Architectural Design These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 95

Why Architecture? The architecture is not the operational software. Rather, it is a representation Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: (1) analyze the effectiveness of the design in meeting its stated requirements, (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and (3) reduce the risks associated with the construction of the software. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 96

Data Design refine data objects and develop a set of data abstractions implement data Data Design refine data objects and develop a set of data abstractions implement data object attributes as one or more data structures review data structures to ensure that appropriate relationships have been established simplify data structures as required These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 97

Data Design—Component Level 1. The systematic analysis principles applied to function and behavior should Data Design—Component Level 1. The systematic analysis principles applied to function and behavior should also be applied to data. 2. All data structures and the operations to be performed on each should be identified. 3. A data dictionary should be established and used to define both data and program design. 4. Low level data design decisions should be deferred until late in the design process. 5. The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure. 6. A library of useful data structures and the operations that may be applied to them should be developed. 7. A software design and programming language should support the specification and realization of abstract data types. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 98

Architectural Styles Each style describes a system category that encompasses: (1) a set of Architectural Styles Each style describes a system category that encompasses: (1) a set of components (e. g. , a database, computational modules) that perform a function required by a system, (2) a set of connectors that enable “communication, coordination and cooperation” among components, (3) constraints that define how components can be integrated to form the system, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts. Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 99

Data-Centered Architecture These courseware materials are to be used in conjunction with Software Engineering: Data-Centered Architecture These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 100

Data Flow Architecture These courseware materials are to be used in conjunction with Software Data Flow Architecture These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 101

Call and Return Architecture These courseware materials are to be used in conjunction with Call and Return Architecture These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 102

Layered Architecture These courseware materials are to be used in conjunction with Software Engineering: Layered Architecture These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 103

Analyzing Architectural Design 1. Collect scenarios. 2. Elicit requirements, constraints, and environment description. 3. Analyzing Architectural Design 1. Collect scenarios. 2. Elicit requirements, constraints, and environment description. 3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements: • module view • process view • data flow view 4. Evaluate quality attributes by considered each attribute in isolation. 5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. 6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 104

An Architectural Design Method customer requirements An Architectural Design Method customer requirements "four bedrooms, three baths, lots of glass. . . " architectural design These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 105

Deriving Program Architecture These courseware materials are to be used in conjunction with Software Deriving Program Architecture These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 106

Partitioning the Architecture “horizontal” and “vertical” partitioning are required These courseware materials are to Partitioning the Architecture “horizontal” and “vertical” partitioning are required These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 107

Horizontal Partitioning define separate branches of the module hierarchy for each major function use Horizontal Partitioning define separate branches of the module hierarchy for each major function use control modules to coordinate communication between functions function 3 function 1 function 2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 108

Vertical Partitioning: Factoring design so that decision making and work are stratified decision making Vertical Partitioning: Factoring design so that decision making and work are stratified decision making modules should reside at the top of the architecture decision-makers workers These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 109

Why Partitioned Architecture? results in software that is easier to test leads to software Why Partitioned Architecture? results in software that is easier to test leads to software that is easier to maintain results in propagation of fewer side effects results in software that is easier to extend These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 110

Structured Design objective: to derive a program architecture that is partitioned approach: the DFD Structured Design objective: to derive a program architecture that is partitioned approach: the DFD is mapped into a program architecture the PSPEC and STD are used to indicate the content of each module notation: structure chart These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 111

Flow Characteristics Transform flow Transaction flow These courseware materials are to be used in Flow Characteristics Transform flow Transaction flow These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 112

General Mapping Approach isolate incoming and outgoing flow boundaries; for transaction flows, isolate the General Mapping Approach isolate incoming and outgoing flow boundaries; for transaction flows, isolate the transaction center working from the boundary outward, map DFD transforms into corresponding modules add control modules as required refine the resultant program structure using effective modularity concepts These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 113

Transform Mapping These courseware materials are to be used in conjunction with Software Engineering: Transform Mapping These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 114

Factoring These courseware materials are to be used in conjunction with Software Engineering: A Factoring These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 115

First Level Factoring main program controller input controller processing controller output controller These courseware First Level Factoring main program controller input controller processing controller output controller These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 116

Second Level Mapping These courseware materials are to be used in conjunction with Software Second Level Mapping These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 117

Transaction Flow incoming flow action path T These courseware materials are to be used Transaction Flow incoming flow action path T These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 118

Transaction Example fixture servos fixture setting operator commands process operator commands report display screen Transaction Example fixture servos fixture setting operator commands process operator commands report display screen robot control software assembly record in reality, other commands would also be shown These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 119

Refining the Analysis Model 1. write an English language processing narrative for the level Refining the Analysis Model 1. write an English language processing narrative for the level 01 flow model 2. apply noun/verb parse to isolate processes, data items, store and entities 3. develop level 02 and 03 flow models 4. create corresponding data dictionary entries 5. refine flow models as appropriate. . . now, we're ready to begin design! These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 120

Deriving Level 1 Processing narrative for Deriving Level 1 Processing narrative for " process operator commands" noun-verb parse Process operator command software reads operator commands from the cell operator. An error message is displayed for invalid commands. The command type is determined for valid commands and appropriate action is taken. When fixture commands are encountered, fixture status is analyzed and a fixture setting is output to the fixture servos. When a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screen. When robot control switches are selected, control values are sent to the robot control system. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 121

Level 1 Data Flow Diagram These courseware materials are to be used in conjunction Level 1 Data Flow Diagram These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 122

Level 2 Data Flow Diagram These courseware materials are to be used in conjunction Level 2 Data Flow Diagram These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 123

Transaction Mapping Principles isolate the incoming flow path define each of the action paths Transaction Mapping Principles isolate the incoming flow path define each of the action paths by looking for the "spokes of the wheel" assess the flow on each action path define the dispatch and control structure map each action path flow individually These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 124

Transaction Mapping These courseware materials are to be used in conjunction with Software Engineering: Transaction Mapping These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 125

Isolate Flow Paths These courseware materials are to be used in conjunction with Software Isolate Flow Paths These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 126

Map the Flow Model These courseware materials are to be used in conjunction with Map the Flow Model These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 127

Refining the Structure Chart These courseware materials are to be used in conjunction with Refining the Structure Chart These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 128

Interface Are Designed intermodular interface design driven by data flow between modules external interface Interface Are Designed intermodular interface design driven by data flow between modules external interface design driven by interface between applications driven by interface between software and non-human producers and/or consumers of information human-computer interface design driven by the communication between human and machine These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 129

Chapter 15 User Interface Design These courseware materials are to be used in conjunction Chapter 15 User Interface Design These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 130

Interface Design Easy to learn? Easy to use? Easy to understand? These courseware materials Interface Design Easy to learn? Easy to use? Easy to understand? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 131

Interface Design Typical Design Errors lack of consistency too much memorization no guidance / Interface Design Typical Design Errors lack of consistency too much memorization no guidance / help no context sensitivity poor response Arcane/unfriendly These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 132

Golden Rules Place the user in control Reduce the user’s memory load Make the Golden Rules Place the user in control Reduce the user’s memory load Make the interface consistent These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 133

Place the User in Control Define interaction modes in a way that does not Place the User in Control Define interaction modes in a way that does not force a user into unnecessary or undesired actions. Provide for flexible interaction. Allow user interaction to be interruptible and undoable. Streamline interaction as skill levels advance and allow the interaction to be customized. Hide technical internals from the casual user. Design for direct interaction with objects that appear on the screen. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 134

Reduce the User’s Memory Load Reduce demand on short-term memory. Establish meaningful defaults. Define Reduce the User’s Memory Load Reduce demand on short-term memory. Establish meaningful defaults. Define shortcuts that are intuitive. The visual layout of the interface should be based on a real world metaphor. Disclose information in a progressive fashion. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 135

Make the Interface Consistent Allow the user to put the current task into a Make the Interface Consistent Allow the user to put the current task into a meaningful context. Maintain consistency across a family of applications. If past interactive models have created user expectations, do not make changes unless there is a compelling reason to do so. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 136

User Interface Design Models System perception — the user’s mental image of what the User Interface Design Models System perception — the user’s mental image of what the interface is User model — a profile of all end users of the system System image — the “presentation” of the system projected by the complete interface Design model — data, architectural, interface and procedural representations of the software These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 137

User Interface Design Process These courseware materials are to be used in conjunction with User Interface Design Process These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 138

Task Analysis and Modeling All human tasks required to do the job (of the Task Analysis and Modeling All human tasks required to do the job (of the interface) are defined and classified Objects (to be manipulated) and actions (functions applied to objects) are identified for each task Tasks are refined iteratively until the job is completely defined These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 139

Interface Design Activities 1. Establish the goals and intentions for each task. 2. Map Interface Design Activities 1. Establish the goals and intentions for each task. 2. Map each goal/intention to a sequence of specific actions. 3. Specify the action sequence of tasks and subtasks, also called a user scenario, as it will be executed at the interface level. 4. Indicate the state of the system, i. e. , what does the interface look like at the time that a user scenario is performed? 5. Define control mechanisms, i. e. , the objects and actions available to the user to alter the system state. 6. Show control mechanisms affect the state of the system. 7. Indicate how the user interprets the state of the system from information provided through the interface. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 140

Design Evaluation Cycle These courseware materials are to be used in conjunction with Software Design Evaluation Cycle These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 141

Chapter 16 Component-Level Design These courseware materials are to be used in conjunction with Chapter 16 Component-Level Design These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 142

Component-Level Design the closest design activity to coding the approach: review the design description Component-Level Design the closest design activity to coding the approach: review the design description for the component use stepwise refinement to develop algorithm use structured programming to implement procedural logic use ‘formal methods’ to prove logic These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 143

Stepwise Refinement open walk to door; reach for knob; open door; walk through; close Stepwise Refinement open walk to door; reach for knob; open door; walk through; close door. repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 144

The Component-Level Design Model represents the algorithm at a level of detail that can The Component-Level Design Model represents the algorithm at a level of detail that can be reviewed for quality options: graphical (e. g. flowchart, box diagram) pseudocode (e. g. , PDL). . . choice of many programming language decision table conduct walkthrough to assess quality These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 145

Structured Programming for Procedural Design uses a limited set of logical constructs: sequence conditional Structured Programming for Procedural Design uses a limited set of logical constructs: sequence conditional — if-then-else, select-case loops — do-while, repeat until leads to more readable, testable code important for achieving high quality, but not enough These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 146

A Structured Procedural Design These courseware materials are to be used in conjunction with A Structured Procedural Design These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 147

Program Design Language (PDL) These courseware materials are to be used in conjunction with Program Design Language (PDL) These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 148

Why Design Language? These courseware materials are to be used in conjunction with Software Why Design Language? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 149

Chapter 17 Software Testing Techniques These courseware materials are to be used in conjunction Chapter 17 Software Testing Techniques These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 150

Software Testing is the process of exercising a program with the specific intent of Software Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 151

Testability Operability—it operates cleanly Observability—the results of each test case are readily observed Controlability—the Testability Operability—it operates cleanly Observability—the results of each test case are readily observed Controlability—the degree to which testing can be automated and optimized Decomposability—testing can be targeted Simplicity—reduce complex architecture and logic to simplify tests Stability—few changes are requested during testing Understandability—of the design These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 152

What Testing Shows errors requirements conformance performance an indication of quality These courseware materials What Testing Shows errors requirements conformance performance an indication of quality These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 153

Who Tests the Software? developer Understands the system but, will test Who Tests the Software? developer Understands the system but, will test "gently" and, is driven by "delivery" independent tester Must learn about the system, but, will attempt to break it and, is driven by quality These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 154

Exhaustive Testing loop < 20 X 14 There are 10 possible paths! If we Exhaustive Testing loop < 20 X 14 There are 10 possible paths! If we execute one test per millisecond, it would take 3, 170 years to test this program!! These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 155

Selective Testing Selected path loop < 20 X These courseware materials are to be Selective Testing Selected path loop < 20 X These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 156

Software Testing black-box methods white-box methods Methods Strategies These courseware materials are to be Software Testing black-box methods white-box methods Methods Strategies These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 157

Test Case Design Test Case Design "Bugs lurk in corners and congregate at boundaries. . . " Boris Beizer OBJECTIVE to uncover errors CRITERIA in a complete manner CONSTRAINT with a minimum of effort and time These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 158

White-Box Testing . . . our goal is to ensure that all statements and White-Box Testing . . . our goal is to ensure that all statements and conditions have been executed at least once. . . These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 159

Why Cover? logic errors and incorrect assumptions are inversely proportional to a path's execution Why Cover? logic errors and incorrect assumptions are inversely proportional to a path's execution probability we oftenbelieve that a path is not likely to be executed; in fact, reality is often counter intuitive typographical errors are random; it's likely that untested paths will contain some These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 160

Basis Path Testing First, we compute the cyclomatic complexity: number of simple decisions + Basis Path Testing First, we compute the cyclomatic complexity: number of simple decisions + 1 or number of enclosed areas + 1 In this case, V(G) = 4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 161

Cyclomatic Complexity A number of industry studies have indicated that the higher V(G), the Cyclomatic Complexity A number of industry studies have indicated that the higher V(G), the higher the probability or errors. modules V(G) modules in this range are more error prone These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 162

Basis Path Testing Next, we derive the independent paths: 1 Since V(G) = 4, Basis Path Testing Next, we derive the independent paths: 1 Since V(G) = 4, there are four paths 2 3 4 5 7 8 6 Path 1: Path 2: Path 3: Path 4: 1, 2, 3, 6, 7, 8 1, 2, 3, 5, 7, 8 1, 2, 4, 7, 2, 4, . . . 7, 8 Finally, we derive test cases to exercise these paths. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 163

Basis Path Testing Notes you don't need a flow chart, but the picture will Basis Path Testing Notes you don't need a flow chart, but the picture will help when you trace program paths count each simple logical test, compound tests count as 2 or more basis path testing should be applied to critical modules These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 164

Loop Testing Simple loop Nested Loops Concatenated Loops Unstructured Loops These courseware materials are Loop Testing Simple loop Nested Loops Concatenated Loops Unstructured Loops These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 165

Loop Testing: Simple Loops Minimum conditions—Simple Loops 1. skip the loop entirely 2. only Loop Testing: Simple Loops Minimum conditions—Simple Loops 1. skip the loop entirely 2. only one pass through the loop 3. two passes through the loop 4. m passes through the loop m < n 5. (n-1), n, and (n+1) passes through the loop where n is the maximum number of allowable passes These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 166

Loop Testing: Nested Loops Start at the innermost loop. Set all outer loops to Loop Testing: Nested Loops Start at the innermost loop. Set all outer loops to their minimum iteration parameter values. Test the min+1, typical, max-1 and max for the innermost loop, while holding the outer loops at their minimum values. Move out one loop and set it up as in step 2, holding all other loops at typical values. Continue this step until the outermost loop has been tested. Concatenated Loops If the loops are independent of one another then treat each as a simple loop else* treat as nested loops endif* for example, the final loop counter value of loop 1 is used to initialize loop 2. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 167

Black-Box Testing requirements output input events These courseware materials are to be used in Black-Box Testing requirements output input events These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 168

Equivalence Partitioning user queries FK output input mouse formats prompts picks data These courseware Equivalence Partitioning user queries FK output input mouse formats prompts picks data These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 169

Sample Equivalence Classes Valid data user supplied commands responses to system prompts file names Sample Equivalence Classes Valid data user supplied commands responses to system prompts file names computational data physical parameters bounding values initiation values output data formatting responses to error messages graphical data (e. g. , mouse picks) Invalid data outside bounds of the program physically impossible data proper value supplied in wrong place These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 170

Boundary Value Analysis user queries FK output input mouse formats prompts picks input domain Boundary Value Analysis user queries FK output input mouse formats prompts picks input domain data output domain These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 171

Other Black Box Techniques error guessing methods decision table techniques cause effect graphing These Other Black Box Techniques error guessing methods decision table techniques cause effect graphing These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 172

Chapter 18 Software Testing Strategies These courseware materials are to be used in conjunction Chapter 18 Software Testing Strategies These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 173

Testing Strategy unit test system test integration test validation test These courseware materials are Testing Strategy unit test system test integration test validation test These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 174

Unit Testing module to be tested results software engineer test cases These courseware materials Unit Testing module to be tested results software engineer test cases These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 175

Unit Testing module to be tested interface local data structures boundary conditions independent paths Unit Testing module to be tested interface local data structures boundary conditions independent paths error handling paths test cases These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 176

Unit Test Environment driver interface local data structures Module boundary conditions independent paths error Unit Test Environment driver interface local data structures Module boundary conditions independent paths error handling paths stub test cases RESULTS These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 177

Integration Testing Strategies Options: • the “big bang” approach • an incremental construction strategy Integration Testing Strategies Options: • the “big bang” approach • an incremental construction strategy These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 178

Top Down Integration A B F top module is tested with stubs G stubs Top Down Integration A B F top module is tested with stubs G stubs are replaced one at a time, "depth first" C as new modules are integrated, some subset of tests is re-run D E These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 179

Bottom-Up Integration A B G drivers are replaced one at a time, Bottom-Up Integration A B G drivers are replaced one at a time, "depth first" C D F E worker modules are grouped into builds and integrated cluster These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 180

Sandwich Testing A B F Top modules are tested with stubs G C D Sandwich Testing A B F Top modules are tested with stubs G C D E Worker modules are grouped into builds and integrated cluster These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 181

High Order Testing validation test system test alpha and beta test other specialized testing High Order Testing validation test system test alpha and beta test other specialized testing These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 182

Debugging: A Diagnostic Process These courseware materials are to be used in conjunction with Debugging: A Diagnostic Process These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 183

The Debugging Process test cases new test regression cases tests suspected causes corrections identified The Debugging Process test cases new test regression cases tests suspected causes corrections identified causes results Debugging These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 184

Debugging Effort time required to correct the error and conduct regression tests time required Debugging Effort time required to correct the error and conduct regression tests time required to diagnose the symptom and determine the cause These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 185

Symptoms & Causes symptom and cause may be geographically separated symptom may disappear when Symptoms & Causes symptom and cause may be geographically separated symptom may disappear when another problem is fixed cause may be due to a combination of non-errors cause may be due to a system or compiler error symptom cause may be due to assumptions that everyone believes symptom may be intermittent These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 186

Consequences of Bugs infectious damage catastrophic extreme serious disturbing mild annoying Bug Type Bug Consequences of Bugs infectious damage catastrophic extreme serious disturbing mild annoying Bug Type Bug Categories: function-related bugs, system-related bugs, data bugs, coding bugs, design bugs, documentation bugs, standards violations, etc. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 187

Debugging Techniques brute force / testing backtracking induction deduction These courseware materials are to Debugging Techniques brute force / testing backtracking induction deduction These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 188

Debugging: Final Thoughts 1. Don't run off half-cocked, think about the symptom you're seeing. Debugging: Final Thoughts 1. Don't run off half-cocked, think about the symptom you're seeing. 2. Use tools (e. g. , dynamic debugger) to gain more insight. 3. If at an impasse, get help from someone else. 4. Be absolutely sure to conduct regression tests when you do "fix" the bug. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 189

Chapter 19 Technical Metrics for Software These courseware materials are to be used in Chapter 19 Technical Metrics for Software These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 190

Mc. Call’s Triangle of Quality Maintainability Flexibility Testability PRODUCT REVISION Portability Reusability Interoperability PRODUCT Mc. Call’s Triangle of Quality Maintainability Flexibility Testability PRODUCT REVISION Portability Reusability Interoperability PRODUCT TRANSITION PRODUCT OPERATION Correctness Usability Efficiency Integrity Reliability These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 191

A Comment Mc. Call’s quality factors were proposed in the early 1970 s. They A Comment Mc. Call’s quality factors were proposed in the early 1970 s. They are as valid today as they were in that time. It’s likely that software built to conform to these factors will exhibit high quality well into the 21 st century, even if there are dramatic changes in technology. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 192

Formulation Principles The objectives of measurement should be established before data collection begins; Each Formulation Principles The objectives of measurement should be established before data collection begins; Each technical metric should be defined in an unambiguous manner; Metrics should be derived based on a theory that is valid for the domain of application (e. g. , metrics for design should draw upon basic design concepts and principles and attempt to provide an indication of the presence of an attribute that is deemed desirable); Metrics should be tailored to best accommodate specific products and processes [BAS 84] These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 193

Collection and Analysis Principles Whenever possible, data collection and analysis should be automated; Valid Collection and Analysis Principles Whenever possible, data collection and analysis should be automated; Valid statistical techniques should be applied to establish relationship between internal product attributes and external quality characteristics Interpretative guidelines and recommendations should be established for each metric These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 194

Attributes simple and computable. It should be relatively easy to learn how to derive Attributes simple and computable. It should be relatively easy to learn how to derive the metric, and its computation should not demand inordinate effort or time empirically and intuitively persuasive. The metric should satisfy the engineer’s intuitive notions about the product attribute under consideration consistent and objective. The metric should always yield results that are unambiguous. consistent in its use of units and dimensions. The mathematical computation of the metric should use measures that do not lead to bizarre combinations of unit. programming language independent. Metrics should be based on the analysis model, the design model, or the structure of the program itself. an effective mechanism for quality feedback. That is, the metric should provide a software engineer with information that can lead to courseware materials are to be used conjunction with Thesea higher quality endinproduct Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 195

Analysis Metrics Function-based metrics: use the function point as a normalizing factor or as Analysis Metrics Function-based metrics: use the function point as a normalizing factor or as a measure of the “size” of the specification Bang metric: used to develop an indication of software “size” by measuring characteristics of the data, functional and behavioral models Specification metrics: used as an indication of quality by measuring number of requirements by type These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 196

Architectural Design Metrics Architectural design metrics Structural complexity = g(fan-out) Data complexity = f(input Architectural Design Metrics Architectural design metrics Structural complexity = g(fan-out) Data complexity = f(input & output variables, fan-out) System complexity = h(structural & data complexity) HK metric: architectural complexity as a function of fan-in and fan-out Morphology metrics: a function of the number of modules and the number of interfaces between modules These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 197

Component-Level Design Metrics Cohesion metrics: a function of data objects and the locus of Component-Level Design Metrics Cohesion metrics: a function of data objects and the locus of their definition Coupling metrics: a function of input and output parameters, global variables, and modules called Complexity metrics: hundreds have been proposed (e. g. , cyclomatic complexity) These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 198

Interface Design Metrics Layout appropriateness: a function of layout entities, the geographic position and Interface Design Metrics Layout appropriateness: a function of layout entities, the geographic position and the “cost” of making transitions among entities These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 199

Code Metrics Halstead’s Software Science: a comprehensive collection of metrics all predicated on the Code Metrics Halstead’s Software Science: a comprehensive collection of metrics all predicated on the number (count and occurrence) of operators and operands within a component or program These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 200