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

6d6f3a30c7a249f781c57ed0d555dc21.ppt

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

Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 R. Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e 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 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 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

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 15

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 16

Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 R. Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e 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 17

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 18

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 19

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 20

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 21

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 22

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 23

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 24

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 25

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 26

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 27

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 28

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 29

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 30

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 31

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 32

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 33

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 34

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 35

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 36

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 37

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 38

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 39

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 40

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 41

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 42

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 43

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 44

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 45

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 46

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 47

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 48

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 49

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 50

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 51

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 52

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 53

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 54

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 55

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 56

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 57

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 58

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 59

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 60

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 61

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 62

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 63

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 64

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 65

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 66

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 67