دسترسی نامحدود
برای کاربرانی که ثبت نام کرده اند
دانلود کتاب The Method Framework for Engineering System Architectures
دانلود کتاب چارچوب روش برای معماری سیستم های مهندسی
مشخصات کتاب
The Method Framework for Engineering System Architectures
ویرایش: [1 ed.] نویسندگان: Donald G. Firesmith, Peter Capell, Charles B. Hammons, DeWitt Latimer, Tom Merendino, Dietrich Falkenthal سری: ISBN (شابک) : 1420085751, 9781420085754 ناشر: Auerbach Publications سال نشر: 2009 تعداد صفحات: 466 [482] زبان: English فرمت فایل : PDF (درصورت درخواست کاربر به PDF، EPUB یا AZW3 تبدیل می شود) حجم فایل: 5 Mb
قیمت کتاب (تومان) : 48,000
در صورت تبدیل فایل کتاب The Method Framework for Engineering System Architectures به فرمت های PDF، EPUB، AZW3، MOBI و یا DJVU می توانید به پشتیبان اطلاع دهید تا فایل مورد نظر را تبدیل نمایند.
توجه داشته باشید کتاب چارچوب روش برای معماری سیستم های مهندسی نسخه زبان اصلی می باشد و کتاب ترجمه شده به فارسی نمی باشد. وبسایت اینترنشنال لایبرری ارائه دهنده کتاب های زبان اصلی می باشد و هیچ گونه کتاب ترجمه شده یا نوشته شده به فارسی را ارائه نمی دهد.
توضیحاتی در مورد کتاب چارچوب روش برای معماری سیستم های مهندسی
معماران سیستم‌های بزرگ و پیچیده امروزی اغلب با فقدان مجموعه‌ای از اصول و شیوه‌های منسجمی دست و پنجه نرم می‌کنند که به اندازه کافی کل وسعت معماری سیستم‌ها را مورد توجه قرار دهد. چارچوب روش برای معماری سیستم های مهندسی (MFESA) معماران سیستم و مهندسان فرآیند را قادر می سازد تا روش هایی را برای مهندسی موثر و کارآمد معماری با کیفیت بالا برای سیستم ها، زیرسیستم ها و اجزای نرم افزار ایجاد کنند. نیازهای پروژه‌های خاص را برآورده می‌کند این کتاب با مستند کردن چالش‌های رایجی که باید توسط مهندسی معماری سیستم مورد توجه قرار گیرد، آغاز می‌شود. اصول اصلی پاسخگویی به این چالش ها و تشکیل اساس MFESA را بررسی می کند. در مرحله بعد، نویسندگان MFESA را شامل اهداف اولیه، ورودی ها، وظایف، خروجی ها و مفروضات آن معرفی می کنند. سپس مفاهیم و اصطلاحات اساسی که مهندسی معماری سیستم ها بر اساس آن ها بنا شده است را شرح می دهند. در ادامه شرحی از هر یک از ده وظیفه مهندسی معماری سیستم شامل اهداف و مقاصد مرتبط، پیش شرط ها، ورودی ها، مراحل، شرایط پسا، محصولات کاری، دستورالعمل ها و مشکلات ارائه می شود. در نهایت، این کتاب رابطه بین کیفیت و معماری را مستند می کند، مدل کیفیت زیربنایی MFESA را توضیح می دهد، و خلاصه ای از چارچوب روش MFESA، و همچنین لیستی از نکاتی که باید به خاطر بسپارید و جهت های آینده برنامه ریزی شده برای MFESA را ارائه می دهد. منطق‌های خاص را توضیح می‌دهد که به‌عنوان یک مرجع میز کار مفید سازمان‌دهی شده است، این کتاب بیش از 100 سال تجربه حرفه‌ای ترکیبی نویسندگان را برای ارائه دستورالعمل‌های گسترده، بهترین شیوه‌ها و نکاتی برای اجتناب از دام‌های احتمالی به کار می‌گیرد. این یک منطق مستقیم از چرایی برداشتن گام‌ها، نحوه انجام کارها، و راهنمایی برای چگونگی و زمان مناسب کردن مدل برای زمینه خاص یک سیستم ارائه می‌کند. CRC Press با خوشحالی اعلام می کند که چارچوب روش برای معماری سیستم مهندسی به لیست خواندن توصیه شده شرکت اینتل اضافه شده است. برنامه Reading Recommended Intel به متخصصان فنی فهرست مرجع ساده و مفیدی از مطالبی که باید بخوانند تا با فناوری‌های جدید آشنا شوند، ارائه می‌کند. ده‌ها فن‌آور صنعت، همکاران شرکت‌ها و مهندسان با پیشنهاد کتاب‌ها و بررسی فهرست کمک کرده‌اند. این جامع ترین لیست خواندنی است که برای توسعه دهندگان رایانه حرفه ای موجود است.
توضیحاتی درمورد کتاب به خارجی
The architects of today’s 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 system’s specific context. CRC Press is pleased to announce that The Method Framework for Engineering System Architectures has been added to Intel Corporation’s Recommended Reading List. Intel’s 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.
فهرست مطالب
Appendix D: Decision-Making Techniques......Page 0
The Method Framework for Engineering System Architectures......Page 3
Concise Table of Contents......Page 5
Contents......Page 7
List of Figures......Page 16
List of Tables......Page 19
Foreword......Page 20
Goals and Objectives......Page 23
Scope......Page 24
Intended Audiences......Page 25
MFESA Flexibility......Page 26
Organization of This Reference Book......Page 27
How to Read and Use This Reference Book......Page 28
Acknowledgments......Page 29
1.1 To Begin …......Page 30
1.2 Why This Book Is Needed......Page 31
1.3 Why System Architecture Is Critical to Success......Page 33
1.4 Why System Architecture Engineering Is Critical to Architecture......Page 38
1.5 A Common System Architecture Engineering Method Is Insufficient......Page 40
2.2 General Systems Architecture Engineering Challenges......Page 41
2.3 Challenges Observed in System Architecture Engineering Practice......Page 51
2.3.2 Many Architecture Defects Are Found during Integration and Testing......Page 52
2.3.4 Architectural Representations Are Often Missing, Incomplete, Incorrect, or Out of Date......Page 53
2.3.6 Architectural Models Are Often Not Understandable......Page 54
2.3.8 How Good Is “Good Enough”?......Page 55
2.3.9 Because We Lack Sufficient Adequately Trained and Experienced Architects, They Must Sometimes Perform Tasks for Which They Are Unqualified......Page 56
2.3.12 Architects Rely Too Much on Architectural Engineering Tools......Page 57
2.4 Challenges Observed in Systems Architecture Engineering Methods......Page 58
2.4.4 Current Methods Overemphasize Architecture Development over Other Tasks......Page 59
2.4.7 Current Methods Are Weak on Structure, View, and Focus Area Consistency......Page 60
2.4.10 Current Methods Confuse Requirements Engineering with Architecture Engineering......Page 61
2.4.11 Current Methods Underemphasize Support for the Quality Characteristics......Page 62
2.4.13 Current Methods Produce Only a Single Architectural Vision......Page 63
2.4.17 Current Methods Excessively Emphasize Architectural Models over Other Architectural Representations......Page 64
2.5 Reasons for Improved Systems Architecture Engineering Methods......Page 65
2.6 Summary of the Challenges......Page 66
3.1 The Importance of Principles......Page 67
3.2 The Individual Principles......Page 68
3.3 Summary of the Principles......Page 75
4.1 The Need for MFESA......Page 77
4.3 What Is MFESA?......Page 79
4.3.2 Metamodel......Page 80
4.3.3 Repository......Page 84
4.3.3.1 Method Components: Tasks......Page 85
4.3.3.2 Method Components: Architectural Workers......Page 88
4.4 Inputs......Page 89
4.6 Assumptions......Page 94
4.7 Relationships with Other Disciplines......Page 95
4.7.1 Requirements Engineering......Page 96
4.7.5 Testing......Page 99
4.7.8 Training......Page 100
4.7.10 Configuration Management......Page 101
4.7.12 Measurements and Metrics......Page 102
4.7.13 Specialty Engineering Disciplines......Page 103
4.8 Guidelines......Page 104
4.9 Summary......Page 106
4.9.4 Tasks......Page 107
4.9.8 Guidelines......Page 108
5.2 Systems......Page 109
5.3 System Architecture......Page 120
5.4 Architectural Structures......Page 123
5.5 Architectural Styles, Patterns, and Mechanisms......Page 128
5.6 Architectural Drivers and Concerns......Page 130
5.7 Architectural Representations......Page 134
5.8 Architectural Models, Views, and Focus Areas......Page 137
5.9 Architecture Work Products......Page 150
5.10 Architectural Visions and Vision Components......Page 153
5.11 Guidelines......Page 154
5.12 Pitfalls......Page 159
5.13 Summary......Page 163
6.2 Goal and Objectives......Page 165
6.4 Inputs......Page 166
6.5 Steps......Page 168
6.6 Postconditions......Page 169
6.7 Work Products......Page 170
6.8 Guidelines......Page 172
6.9 Pitfalls......Page 174
6.10.2 Work Products......Page 179
6.10.4 Pitfalls......Page 180
7.2 Goal and Objectives......Page 181
7.3 Preconditions......Page 182
7.4 Inputs......Page 183
7.5 Steps......Page 184
7.7 Work Products......Page 187
7.8 Guidelines......Page 188
7.9 Pitfalls......Page 190
7.10.2 Work Products......Page 196
7.10.4 Pitfalls......Page 197
8.1 Introduction......Page 198
8.2 Goal and Objectives......Page 200
8.4 Inputs......Page 201
8.5 Steps......Page 202
8.6 Postconditions......Page 203
8.8 Guidelines......Page 204
8.9 Pitfalls......Page 210
8.10.1 Steps......Page 214
8.10.4 Pitfalls......Page 215
9.1 Introduction......Page 217
9.3 Preconditions......Page 218
9.5 Steps......Page 219
9.6 Postconditions......Page 221
9.8 Guidelines......Page 223
9.9 Pitfalls......Page 224
9.10 Summary......Page 228
9.10.4 Pitfalls......Page 229
10.1 Introduction......Page 231
10.4 Inputs......Page 232
10.5 Steps......Page 233
10.7 Work Products......Page 234
10.8 Guidelines......Page 235
10.9 Pitfalls......Page 237
10.10 Summary......Page 241
10.10.4 Pitfalls......Page 242
11.1 Introduction......Page 244
11.3 Preconditions......Page 245
11.5 Steps......Page 246
11.6 Postconditions......Page 247
11.8 Guidelines......Page 248
11.9 Pitfalls......Page 249
11.10 Summary......Page 255
11.10.4 Pitfalls......Page 256
12.1 Introduction......Page 257
12.4 Inputs......Page 258
12.5 Steps......Page 259
12.7 Work Products......Page 261
12.8 Guidelines......Page 262
12.9 Pitfalls......Page 264
12.10.2 Work Products......Page 267
12.10.4 Pitfalls......Page 268
13.1 Introduction......Page 269
13.3 Preconditions......Page 270
13.5 Steps......Page 271
13.7 Work Products......Page 274
13.8 Guidelines......Page 275
13.9 Pitfalls......Page 276
13.10 Summary......Page 278
13.10.4 Pitfalls......Page 279
14.2 Goals and Objectives......Page 280
14.5 Steps......Page 282
14.6 Postconditions......Page 285
14.8 Guidelines......Page 286
14.9 Pitfalls......Page 290
14.10.1 Steps......Page 298
14.10.3 Guidelines......Page 299
14.10.4 Pitfalls......Page 300
15.1 Introduction......Page 301
15.3 Preconditions......Page 302
15.4 Inputs......Page 303
15.5 Steps......Page 304
15.6 Invariants......Page 305
15.7 Work Products......Page 306
15.8 Guidelines......Page 308
15.9 Pitfalls......Page 310
15.10.2 Work Products......Page 313
15.10.4 Pitfalls......Page 314
16.1 Introduction......Page 315
16.2 System Architects......Page 317
16.2.2 Types of System Architect......Page 318
16.2.3 Responsibilities......Page 319
16.2.5 Tasks......Page 322
16.2.6.1 Personal Characteristics......Page 323
16.2.6.2 Expertise......Page 324
16.2.6.5 Interfaces......Page 325
16.2.8 Pitfalls......Page 327
16.3.1 Types of Architecture Teams......Page 329
16.3.2 Responsibilities......Page 331
16.3.3 Membership......Page 332
16.3.4 Collaborations......Page 333
16.3.5 Guidelines......Page 335
16.3.6 Pitfalls......Page 337
16.4.1 Example Tools......Page 339
16.4.2 Types of Architecture Tools......Page 340
16.4.4 Guidelines......Page 350
16.4.5 Pitfalls......Page 353
16.5.1 System Architects......Page 357
16.5.3 Architecture Tools......Page 358
17.1 Introduction......Page 360
17.2 Metamethod Overview......Page 361
17.3 Method Needs Assessment......Page 362
17.7 Method Construction......Page 367
17.8 Method Documentation......Page 368
17.11 Guidelines......Page 369
17.12 Pitfalls......Page 371
17.13 Summary......Page 373
18.1 Introduction......Page 375
18.2 Quality Model Components and Their Relationships......Page 376
18.3 Internal Quality Characteristics......Page 380
18.4 External Quality Characteristics......Page 383
18.5 Quality Requirements......Page 393
18.5.1 Example Quality Requirements......Page 394
18.6 Architectural Quality Cases......Page 395
18.6.2 Architectural Quality Case Components......Page 396
18.6.3 Example Architectural Quality Case......Page 398
18.7 Architectural Quality Case Evaluation Using QUASAR......Page 400
18.7.1 Work Products......Page 406
18.8 Guidelines......Page 408
18.9 Pitfalls......Page 409
18.10 Summary......Page 414
19.2.1 MFESA Components......Page 416
19.2.2 Overview of the MFESA Tasks......Page 417
19.3.2 MFESA Is Not a System Architecture Engineering Method......Page 419
19.3.3 Quality Is Key......Page 420
19.3.4 Architectural Quality Cases Are Important......Page 421
19.3.7 Reuse Significantly Affects Architecture Engineering......Page 422
19.3.9 Beware of Ultra-large Systems of Systems......Page 423
19.4.1.1 Trends in Systems and System Engineering......Page 424
19.4.1.2 Trends in System Architecture Engineering, Architects, and Tools......Page 426
19.4.2.2 Informational Web Site......Page 429
19.4.2.3 Method Engineering Tool Support......Page 430
19.5 Final Thoughts......Page 431
A.1 Acronyms......Page 433
A.2 Glossary......Page 434
B.1.1 Architecture Process Work Products......Page 448
B.1.2 Architectures and Their Components......Page 450
B.1.3 Architectural Representations......Page 451
B.2.2 Tasks......Page 452
B.2.3 Techniques......Page 453
B.3.1 Architects......Page 454
B.3.3 System Architecture Tools......Page 455
MFESA Ontology of Concepts and Terminology (Chapter 5)......Page 457
Task 2: Identify the Architectural Drivers (Chapter 7)......Page 458
Task 4: Identify Opportunities for the Reuse of Architectural Elements (Chapter 9)......Page 459
Task 6: Analyze Reusable Components and Their Sources (Chapter 11)......Page 460
Task 9: Evaluate and Accept the Architecture (Chapter 14)......Page 461
Task 10: Maintain the Architecture and Its Representations (Chapter 15)......Page 462
MFESA Metamethod (Chapter 17)......Page 463
Decision-Making Techniques (Appendix D)......Page 464
D.1 Decision Alternatives Determination......Page 465
D.2 Decision Criteria Determination......Page 466
D.3.1 Subjective Scaling......Page 467
D.4 Decision Rule Determination......Page 468
D.4.2 Filtering Based on Relative Importance......Page 469
D.7 Guidelines......Page 470
D.8 Pitfalls......Page 471
D.9 Summary......Page 473
D.9.3 Pitfalls......Page 474
Annotated References/Bibliography......Page 475
نظرات کاربران
کتاب های تصادفی
دانلود کتاب Sports Cardiology: Exercise in health and cardiovascular disease
دانلود کتاب COGENERACION : diseno, operacion y mantenimiento de plantas de cogeneracion.
دانلود کتاب Using Technology With Classroom Instruction That Works
