1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e 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.

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 Chapter 10 System Engineering

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

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 Business Process Engineering (BPE)  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

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 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 4GTs, testing * Software engineers usually do not participate in the upper two levels of BPE

6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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

7 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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

8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Business Area Analysis (BAA)  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

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

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

11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Product Engineering  Described as the task of translating a customer’s desires for a set of capabilities into a working product.  Involves the following steps:  Requirements Engineering  Analysis  Design

12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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

13 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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

14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 System Modeling  Building a hierarchical system model that has a system context diagram (SCD) as its root followed by a system flow diagram (SFD)  The engineer needs to consider a number of restraining factors:  Assumptions that reduce the number of variations  Simplifications  Limitations that help to bound the system  Constraints  Preferences

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

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