ISBN-13: 9780470007655 / Angielski / Twarda / 2007 / 360 str.
ISBN-13: 9780470007655 / Angielski / Twarda / 2007 / 360 str.
This book focuses on systems analysis, broadly defined to also include problem formulation and interpretation of proposed alternatives in terms of the value systems of stakeholders. Therefore, the book is a complement, not a substitute to other books when teaching systems engineering and systems analysis. The nature of problem solving discussed in this book is appropriate to a wide range of systems analyses. Thus the book can be used as a stand-alone book for teaching the analysis of systems. Also unique is the inclusion of broad case studies to stress problem solving issues, making How to Do Systems Analysis a complement to the many fine works in systems engineering available today.
"[The] book is solidly grounded in the application of theory .A very comprehensive book that junior or student systems analysts would find helpful for fundamental concepts." ( The Computer Journal, January 2009)
" a real–world view of systems and how best to analyze them recommended." (CHOICE, December 2007)
Preface.
A Personal Note from William T. Scherer.
A Personal Note from William F. Gibson.
A Personal Note from Scott F. Ferber.
Original Preface from Jack Gibson.
Acknowledgments.
1. Introduction.
1.1 What is a System?
1.2 Terminology Confusion.
1.3 Systems Analysis Equals Operations Research Plus Policy Analysis.
1.4 Attributes of Large–Scale Systems.
1.5 Intelligent Transportation Systems (ITS): An Example of a Large–Scale System.
1.6 Systems Integration.
1.7 What Makes a Systems Analysis Different?
1.8 Distant Roots of Systems Analysis.
1.9 Immediate Precursors to Systems Analysis.
1.10 Development of Systems Analysis As a Distinct Discipline: The Influence of RAND.
Historical Case Study: IIASA (A).
Exercises.
Case Study: Fun at Six Flags?
Historical Case Study: IIASA (B).
2. Six Major Phases of Systems Analysis.
2.1 The System Analysis Method: Six Major Phases.
2.2 The Goal–Centered or Top–Down Approach.
2.3 The Index of Performance Concept.
2.4 Developing Alternative Scenarios.
2.5 Ranking Alternatives.
2.6 Iteration and the Error–Embracing Approach.
2.7 The Action Phase: The Life–Cycle of a System.
Exercises.
Case Study: Methodologies or Chaos? Part A.
Case Study: Methodologies or Chaos? Part B.
Case Study: Wal–Mart Crisis!
3. Goal Development.
3.1 Seven Steps in Goal Development.
3.2 On Generalizing the Question.
3.3 The Descriptive Scenario.
3.4 The Normative Scenario.
3.5 The Axiological Component.
3.6 Developing an Objectives Tree.
3.7 Fitch s Goals for Urbanizing America: An Example of Objectives Tree Construction.
3.8 Content Analysis of Fitch s Goals.
3.9 Validate.
3.10 Iterate.
Case Study: Distance Learning in the Future?
Historical Case Study: Goals of 4C, Inc.
4. The Index of Performance.
4.1 Introduction.
4.2 Desirable Characteristics for an Index of Performance.
4.3 Economic Criteria.
4.4 Compound Interest.
4.5 Four Common Criteria for Economic Efficiency.
4.6 Is there a Problem with Multiple Criteria?
4.7 What is Wrong with the B–C Ratio?
4.8 Can IRR be Fixed?
4.9 Expected Monetary Value.
4.10 Nonmonetary Performance Indices.
Exercises.
Case Study: Sky High Airlines
Case Study: Bridges Where to Spend the Security Dollars?
Case Study: Measuring the Process and Outcomes of Regional Transportation Collaboration.
Case Study: Baseball Free Agent Draft.
5. Develop Alternative Candidate Solutions.
5.1 Introduction.
5.2 The Classical Approach to Creativity.
5.3 Concepts in Creativity.
5.4 Brainstorming.
5.5 Brainwriting.
5.6 Dynamic Confrontation.
5.7 Zwicky s Morphological Box.
5.8 The Options Field/Options Profile Approach.
5.9 Computer Creativity.
5.10 Computer Simulation: a Tool in Option Development.
5.11 Why a Dynamic Simulation for Creating Options?
5.12 Context–Free Simulation Models?
5.13 Bottom–Up Simulation or Top–Down?
5.14 Lessons from the Susquehanna River Basin Model.
5.15 The Forrester Urban Model (FUM) and Societal Values.
5.16 Extensions and Variations.
5.17 Where to go from Here?
Exercises.
Case Study: Winnebago.
Case Study: Distance Learning in the Future?
Historical Case Study: Real–Time Television Link with Mars Orbiter.
Historical Case Study: A Highway Vehicle Simulator.
RFP from DOT.
6. Rank Alternative Candidates.
6.1 Introduction.
6.2 Rating and Ranking Methods.
6.3 Condorcet and Arrow Voting Paradoxes.
6.4 A MultiStage Rating Process.
6.5 Decision Analysis.
6.6 Basic Axioms of Decision Theory.
6.7 Properties of Utility Functions.
6.8 Constructing a Utility Curve.
6.9 Some Decision Analysis Classic Examples.
6.10 Estimation Theory in Decision Analysis.
6.11 Some Practical Problems with Decision Analysis.
6.12 Practical Trade Studies.
Exercises.
Case Study: Training Center Location.
Case Study: Corporate Headquarters Location.
Case Study: Business School Selection.
7. Iteration and Transition.
7.1 Iteration.
7.2 Segment and Focus.
7.3 The Transition Scenario.
7.4 The Gantt Chart.
7.5 Interaction Matrices.
7.6 The Delta Chart.
7.7 The Audit Trail.
7.8 Cost of Failure to Stay on Schedule.
7.9 Responsibilities of Major Actors.
7.10 Sign–Offs by Cooperating Groups.
Exercises.
8. Management of the Systems Team.
8.1 Introduction.
8.2 Personal Style in an Interdisciplinary Team.
8.3. Out–Scoping and In–Scoping in a System Study.
8.4 Building the Systems Team.
8.5 Tips on Managing the Team.
8.6 Functional or Project Management?
8.7 How to Make an Effective Oral Presentation.
8.8 How to Write a Report.
9. Project Management.
9.1 Introduction.
9.2 Project Management Versus Process Management.
9.3 The Hersey–Blanchard Four–Mode Theory.
9.4 Relation of Management Style to Project Management.
9.5 Preliminary Project Planning.
9.6 Dealing with Conflict in Project Management.
9.7 Life–Cycle Planning and Design.
9.8 PERT/CPM Program Planning Method: An Example.
9.9 Quality Control in Systems Projects.
Case Study: Project Management.
10. The 10 Golden Rules of Systems Analysis.
10.1 Introduction.
10.2 Rule 1: There Always Is a Client.
10.3 Rule 2: Your Client Does Not Understand His Own Problem.
10.4 Rule 3: The Original Problem Statement is too Specific: You Must Generalize the Problem to Give it Contextual Integrity.
10.5 Rule 4: The Client Does Not Understand the Concept of the Index of Performance.
10.6 Rule 5: You are the Analyst, Not the Decision–Maker.
10.7 Rule 6: Meet the Time Deadline and the Cost Budget.
10.8 Rule 7: Take a Goal–Centered Approach to the Problem, Not a Technology–Centered or Chronological Approach .
10.9 Rule 8: Nonusers Must be Considered in the Analysis and in the Final Recommendations.
10.10 Rule 9: The Universal Computer Model is a Fantasy.
10.11 Rule 10: The Role of Decision–Maker in Public Systems is Often a Confused One.
References.
Index.
John E. Gibson, PhD, was the Commonwealth Distinguished Professor of Systems Management at the School of Engineering and Applied Science, University of Virginia, Charlottesville. He was the past dean of engineering at two universities: The University of Virginia and Oakland University. His research was in manufactruring strategy and management and in total quality leadership. Dr. Gibson received his PhD from Yale University.
William T. Scherer, PhD, is Professor in the Department of Systems and Information Engineering at the University of Virginia where he teaches courses on systems engineering. He has authored and co–authored numerous publications on intelligent decision support systems, combinatorial optimization, and stochastic control. He is an associate editor for International Abstracts in Operations Research and reviewer for Operations Research, Annals of Operations Research, and IEEE Trans–actions on Intelligent Transportation Systems (ITS). He has held the Lucien Carr III Professorship of Engineering, recognition of his excellence in undergraduate education.
Many systems engineering books describe the systematic process of developing, designing, and deploying large–scale complex systems, yet fail to present the fundamental systemic thinking needed to conceive complex systems and solve complex socio–technical problems. Rather than delve into the formal processes of systems engineering, this unique book emphasizes the underlying systems analysis component and associated though processes. Systems analysis focuses on problem definition and offers a unique book emphasizes the underlying systems analysis component and associated though processes. Systems analysis focuses on problem defining and offers a unique perspective on problem solving in all type so f domains. How to Do systems Analysis describes an approach that is appropriate for large–scale, complex systems in diverse disciplines. More specifically, How to Do Systems Analysis:
An eye–opening, thought–provoking reference for professionals in field that need input from systems engineering, such as telecommunications, transportation,m business consulting, and health care, this book is also a stimulating text for senior undergraduate and graduate students in systems engineering and systems analysis courses.
1997-2024 DolnySlask.com Agencja Internetowa