Atjaunināt sīkdatņu piekrišanu

E-grāmata: Method Framework for Engineering System Architectures [Taylor & Francis e-book]

, (SEI, Pittsburgh, Pennsylvania, USA), (SEI, Pittsburgh, Pennsylvania, USA), , (SEI, Pittsburgh, Pennsylvania, USA),
  • Formāts: 518 pages, 5 Tables, black and white; 78 Illustrations, black and white
  • Izdošanas datums: 20-Nov-2008
  • Izdevniecība: Auerbach
  • ISBN-13: 9780429191619
Citas grāmatas par šo tēmu:
  • Taylor & Francis e-book
  • Cena: 177,87 €*
  • * this price gives unlimited concurrent access for unlimited time
  • Standarta cena: 254,10 €
  • Ietaupiet 30%
  • Formāts: 518 pages, 5 Tables, black and white; 78 Illustrations, black and white
  • Izdošanas datums: 20-Nov-2008
  • Izdevniecība: Auerbach
  • ISBN-13: 9780429191619
Citas grāmatas par šo tēmu:
The architects of todays large and complex systems all too often struggle with the lack of a consistent set of principles and practices that adequately address the entire breadth of systems architecture. The Method Framework for Engineering System Architectures (MFESA) enables system architects and process engineers to create methods for effectively and efficiently engineering high-quality architecture for systems, subsystems, and software components.

Meets the Needs of Specific Projects

The book begins by documenting the common challenges that must be addressed by system architecture engineering. It explores the major principles answering these challenges and forming the basis of MFESA. Next, the authors introduce MFESA, including its primary goals, inputs, tasks, outputs, and assumptions. Then they describe the fundamental concepts and terminology on which the systems architecture engineering is founded. This is followed by a description of each of the ten system architecture engineering tasks including associated goals and objectives, preconditions, inputs, steps, postconditions, work products, guidelines, and pitfalls.

Finally, the book documents the relationship between quality and architecture, explains the quality model underlying MFESA, and provides a summary of MFESA method framework, as well as a list of points to remember and future directions planned for MFESA.

Explains Specific Rationales

Organized as a handy desk reference, this book harnesses more than 100 years of the authors combined professional experience to provide extensive guidelines, best practices, and tips on avoiding possible pitfalls. It presents a direct rationale of why steps are taken, how things can go wrong, and guidance for how and when to tailor the model for a systems specific context.

CRC Press is pleased to announce that The Method Framework for Engineering System Architectures has been added to Intel Corporations Recommended Reading List. Intels Recommended Reading program provides technical professionals a simple and handy reference list of what to read to stay abreast of new technologies. Dozens of industry technologists, corporate fellows, and engineers have helped by suggesting books and reviewing the list. This is the most comprehensive reading list available for professional computer developers.
List of Figures
xvii
List of Tables
xxi
Foreword xxiii
Preface xxvii
Introduction
1(12)
To Begin
1(1)
Why This Book Is Needed
2(2)
Why System Architecture Is Critical to Success
4(5)
Why System Architecture Engineering Is Critical to Architecture
9(2)
A Common System Architecture Engineering Method Is Insufficient
11(2)
System Architecture Engineering Challenges
13(26)
Introduction
13(1)
General Systems Architecture Engineering Challenges
13(10)
Challenges Observed in System Architecture Engineering Practice
23(7)
Industry Has a Poor Architecture Engineering Track Record
24(1)
Many Architecture Defects Are Found during Integration and Testing
24(1)
Processes Are Inconsistent in Practice
25(1)
Architectural Representations Are Often Missing, Incomplete, Incorrect, or Out of Date
25(1)
Architectural Models Are Treated as the Sole Architectural Representations
26(1)
Architectural Models Are Often Not Understandable
26(1)
Architecture Engineering Underemphasizes Specialty Engineering Focus Areas
27(1)
How Good Is ``Good Enough''?
27(1)
Because We Lack Sufficient Adequately Trained and Experienced Architects, They Must Sometimes Perform Tasks for Which They Are Unqualified
28(1)
Architects Use Multiple Inconsistent Architecture Engineering Methods
29(1)
Architecture Engineering Methods Are Incompletely Documented
29(1)
Architects Rely Too Much on Architectural Engineering Tools
29(1)
The Connection between the Architecture and the Design It Drives Is Weak
30(1)
Challenges Observed in Systems Architecture Engineering Methods
30(7)
Current System Architecture Engineering Methods Are Incomplete
31(1)
Current Methods Do Not Scale Up
31(1)
Current Methods Assume ``Greenfield'' Development
31(1)
Current Methods Overemphasize Architecture Development over Other Tasks
31(1)
Current Methods Overemphasize Functional Decomposition for Logical Structures
32(1)
Current Methods Overemphasize Physical Decomposition for Physical Structures
32(1)
Current Methods Are Weak on Structure, View, and Focus Area Consistency
32(1)
Current Methods Codify Old Processes
33(1)
Current Methods Emphasize the Waterfall Development Cycle
33(1)
Current Methods Confuse Requirements Engineering with Architecture Engineering
33(1)
Current Methods Underemphasize Support for the Quality Characteristics
34(1)
Current Methods Assume That ``One Size Fits All''
35(1)
Current Methods Produce Only a Single Architectural Vision
35(1)
Current Methods Overly Rely on Local Interface Specifications
36(1)
Current Methods Lack an Underlying Ontology
36(1)
Current Methods Confuse Architecture and Architecture Representations
36(1)
Current Methods Excessively Emphasize Architectural Models over Other Architectural Representations
36(1)
Current Methods Overemphasize the Points of View of Different Types of Experts
37(1)
Reasons for Improved Systems Architecture Engineering Methods
37(1)
Summary of the Challenges
38(1)
System Architecture Engineering Principles
39(10)
The Importance of Principles
39(1)
The Individual Principles
40(7)
Summary of the Principles
47(2)
MFESA: An Overview
49(32)
The Need for MFESA
49(2)
MFESA Goal and Objectives
51(1)
What Is MFESA?
51(10)
Ontology
52(1)
Metamodel
52(4)
Repository
56(1)
Method Components: Tasks
57(3)
Method Components: Architectural Workers
60(1)
Metamethod
61(1)
Inputs
61(5)
Outputs
66(1)
Assumptions
66(1)
The Number and Timing of System Architecture Engineering Processes
67(1)
Relationships with Other Disciplines
67(9)
Requirements Engineering
68(3)
Design
71(1)
Implementation
71(1)
Integration
71(1)
Testing
71(1)
Quality Engineering
72(1)
Process Engineering
72(1)
Training
72(1)
Project/Program Management
73(1)
Configuration Management
73(1)
Risk Management
74(1)
Measurements and Metrics
74(1)
Specialty Engineering Disciplines
75(1)
Guidelines
76(2)
Summary
78(3)
MFESA Components
79(1)
Goal and Objectives
79(1)
Inputs
79(1)
Tasks
79(1)
Outputs
80(1)
Assumptions
80(1)
Other Disciplines
80(1)
Guidelines
80(1)
MFESA: The Ontology of Concepts and Terminology
81(56)
The Need for Mastering Concepts and Their Ramifications
81(1)
Systems
81(11)
System Architecture
92(3)
Architectural Structures
95(5)
Architectural Styles, Patterns, and Mechanisms
100(2)
Architectural Drivers and Concerns
102(4)
Architectural Representations
106(3)
Architectural Models, Views, and Focus Areas
109(13)
Architecture Work Products
122(3)
Architectural Visions and Vision Components
125(1)
Guidelines
126(5)
Pitfalls
131(4)
Summary
135(2)
Plan and Resource the Architecture Engineering Effort
137(16)
Introduction
137(1)
Goal and Objectives
137(1)
Preconditions
138(1)
Inputs
138(2)
Steps
140(1)
Postconditions
141(1)
Work Products
142(2)
Guidelines
144(2)
Pitfalls
146(5)
Summary
151(2)
Steps
151(1)
Work Products
151(1)
Guidelines
152(1)
Pitfalls
152(1)
Identify the Architectural Drivers
153(18)
Introduction
153(1)
Goal and Objectives
153(1)
Preconditions
154(1)
Inputs
155(1)
Steps
156(3)
Postconditions
159(1)
Work Products
159(1)
Guidelines
160(2)
Pitfalls
162(6)
Summary
168(3)
Steps
168(1)
Work Products
168(1)
Guidelines
169(1)
Pitfalls
169(2)
Create the First Versions of the Most Important Architectural Models
171(20)
Introduction
171(2)
Goal and Objectives
173(1)
Preconditions
174(1)
Inputs
174(1)
Steps
175(1)
Postconditions
176(1)
Work Products
177(1)
Guidelines
177(6)
Pitfalls
183(4)
Summary
187(4)
Steps
187(1)
Work Products
188(1)
Guidelines
188(1)
Pitfalls
188(3)
Identify Opportunities for the Reuse of Architectural Elements
191(14)
Introduction
191(1)
Goal and Objectives
192(1)
Preconditions
192(1)
Inputs
193(1)
Steps
193(2)
Postconditions
195(2)
Work Products
197(1)
Guidelines
197(1)
Pitfalls
198(4)
Summary
202(3)
Steps
203(1)
Work Products
203(1)
Guidelines
203(1)
Pitfalls
203(2)
Create the Candidate Architectural Visions
205(14)
Introduction
205(1)
Goal and Objectives
206(1)
Preconditions
206(1)
Inputs
206(1)
Steps
207(1)
Postconditions
208(1)
Work Products
208(1)
Guidelines
209(2)
Pitfalls
211(4)
Summary
215(4)
Steps
216(1)
Work Products
216(1)
Guidelines
216(1)
Pitfalls
216(3)
Analyze Reusable Components and Their Sources
219(14)
Introduction
219(1)
Goal and Objectives
220(1)
Preconditions
220(1)
Inputs
221(1)
Steps
221(1)
Postconditions
222(1)
Work Products
223(1)
Guidelines
223(1)
Pitfalls
224(6)
Summary
230(3)
Steps
231(1)
Work Products
231(1)
Guidelines
231(1)
Pitfalls
231(2)
Select or Create the Most Suitable Architectural Vision
233(12)
Introduction
233(1)
Goal and Objectives
234(1)
Preconditions
234(1)
Inputs
234(1)
Steps
235(2)
Postconditions
237(1)
Work Products
237(1)
Guidelines
238(2)
Pitfalls
240(3)
Summary
243(2)
Steps
243(1)
Work Products
243(1)
Guidelines
244(1)
Pitfalls
244(1)
Complete the Architecture and Its Representations
245(12)
Introduction
245(1)
Goals and Objectives
246(1)
Preconditions
246(1)
Inputs
247(1)
Steps
247(3)
Postconditions
250(1)
Work Products
250(1)
Guidelines
251(1)
Pitfalls
252(2)
Summary
254(3)
Steps
255(1)
Work Products
255(1)
Guidelines
255(1)
Pitfalls
255(2)
Evaluate and Accept the Architecture
257(22)
Introduction
257(1)
Goals and Objectives
257(2)
Preconditions
259(1)
Inputs
259(1)
Steps
259(3)
Postconditions
262(1)
Work Products
263(1)
Guidelines
263(4)
Pitfalls
267(8)
Summary
275(4)
Steps
275(1)
Work Products
276(1)
Guidelines
276(1)
Pitfalls
277(2)
Maintain the Architecture and Its Representations
279(14)
Introduction
279(1)
Goals and Objectives
280(1)
Preconditions
280(1)
Inputs
281(1)
Steps
282(1)
Invariants
283(1)
Work Products
284(2)
Guidelines
286(2)
Pitfalls
288(3)
Summary
291(2)
Steps
291(1)
Work Products
291(1)
Guidelines
292(1)
Pitfalls
292(1)
MFESA Method Components: Architectural Workers
293(46)
Introduction
293(2)
System Architects
295(12)
Definitions
296(1)
Types of System Architect
296(1)
Responsibilities
297(3)
Authority
300(1)
Tasks
300(1)
Profile
301(1)
Personal Characteristics
301(1)
Expertise
302(1)
Training
303(1)
Experience
303(1)
Interfaces
303(2)
Guidelines
305(1)
Pitfalls
305(2)
System Architecture Teams
307(10)
Types of Architecture Teams
307(2)
Responsibilities
309(1)
Membership
310(1)
Collaborations
311(2)
Guidelines
313(2)
Pitfalls
315(2)
Architectural Tools
317(18)
Example Tools
317(1)
Types of Architecture Tools
318(10)
Relationships
328(1)
Guidelines
328(3)
Pitfalls
331(4)
Architecture Worker Summary
335(4)
System Architects
335(1)
System Architecture Teams
336(1)
Architecture Tools
336(3)
MFESA: The Metamethod for Creating Endeavor-Specific Methods
339(16)
Introduction
339(1)
Metamethod Overview
340(1)
Method Needs Assessment
341(5)
Number of Methods Determination
346(1)
Method Reuse Type Determination
346(1)
Method Reuse
346(1)
Method Construction
346(1)
Method Documentation
347(1)
Method Verification
348(1)
Method Publication
348(1)
Guidelines
348(2)
Pitfalls
350(2)
Summary
352(3)
Architecture and Quality
355(42)
Introduction
355(1)
Quality Model Components and Their Relationships
356(4)
Internal Quality Characteristics
360(3)
External Quality Characteristics
363(10)
Quality Requirements
373(2)
Example Quality Requirements
374(1)
Architectural Quality Cases
375(5)
Quality Case Components
376(1)
Architectural Quality Case Components
376(2)
Example Architectural Quality Case
378(2)
Architectural Quality Case Evaluation Using QUASAR
380(8)
Work Products
386(2)
Guidelines
388(1)
Pitfalls
389(5)
Summary
394(3)
Conclusions
397(18)
Introduction
397(1)
Summary of MFESA
397(3)
MFESA Components
397(1)
Overview of the MFESA Tasks
398(2)
Key Points to Remember
400(5)
System Architecture and System Architecture Engineering Are Critical
400(1)
MFESA Is Not a System Architecture Engineering Method
400(1)
Quality Is Key
401(1)
Architectural Quality Cases Are Important
402(1)
Capture the Rationales
403(1)
Stay at the Right Level
403(1)
Reuse Significantly Affects Architecture Engineering
403(1)
Architecture Is Never Finished
404(1)
Beware of Ultra-Large Systems of Systems
404(1)
Future Directions
405(7)
The Future Directions of System Architecture Engineering
405(1)
Trends in Systems and System Engineering
405(2)
Trends in System Architecture Engineering, Architects, and Tools
407(3)
The Future Directions of MFESA
410(1)
MFESA Organization
410(1)
Informational Web Site
410(1)
Method Engineering Tool Support
411(1)
Final Thoughts
412(3)
Appendix A: Acronyms and Glossary 415(16)
Appendix B: MFESA Method Components 431(10)
Appendix C: List of Guidelines and Pitfalls 441(8)
Appendix D: Decision-Making Techniques 449(10)
Annotated References/Bibliography 459(8)
Index 467
Donald G. Firesmith, Peter Capell, Dietrich Falkenthal, Charles B. Hammons, DeWitt T. Latimer IV, Tom Merendino