Hugendubel.info - Die B2B Online-Buchhandlung 

Merkliste
Die Merkliste ist leer.
Bitte warten - die Druckansicht der Seite wird vorbereitet.
Der Druckdialog öffnet sich, sobald die Seite vollständig geladen wurde.
Sollte die Druckvorschau unvollständig sein, bitte schliessen und "Erneut drucken" wählen.
E-BookEPUB2 - DRM Adobe / EPUBE-Book
464 Seiten
Englisch
John Wiley & Sonserschienen am05.04.20222. Auflage
MODEL-BASED SYSTEM ARCHITECTURE
AN UP-TO-DATE EXPLORATION OF THE NEWEST STANDARDS AND BEST PRACTICES IN SYSTEM ARCHITECTING
In the newly revised Second Edition of Model-Based System Architecture, a team of expert engineers deliver a detailed and authoritative review of the practice of system architecture in organizations that use models to support the systems engineering process. In the book, readers will find introductions to the fundamentals of architecting systems and using models to assist the architecting process.
The latest edition offers refreshed content based on ISO 15288:2015 and a renewed focus on the role of the system architect. New chapters on systems-of-systems, and cyber-physical systems, and system architect tools offer guidance to practicing professionals on how to apply the presented concepts in the real-world.
In addition to the latest definitions of the architecture governance and evaluation processes described in ISO 42020 and 42030, the book provides: A thorough introduction to the value of systems architecting, definitions of system architecture, and model-based system architecture
Comprehensive explorations of model governance, architecture descriptions, patterns, and principles, and the roles of typical architecture stakeholders
Practical discussions of Agile approaches to systems architecture, the FAS Method, and architecture frameworks
In-depth examinations of systems architecting work and necessary soft skills for systems architects
Modeling of system architectures with SysML including a brief overview of SysML v1 and an outlook to SysML v2

Perfect for system architects and system engineers, Model-Based System Architecture will also earn a place in the libraries of students and researchers studying functional architectures.


TIM WEILKIENS is Executive Board Member of Oose, a German engineering consultancy, and a co-author of the SysML specification.

JESKO G. LAMM is a Senior Systems Engineer in the European hearing healthcare industry.
STEPHAN ROTH is a coach, consultant, and trainer for systems and software engineering at oose. He is a certified systems engineer (GfSE)®- Level C.
MARKUS WALKER is Elevator System Architect in the CTO Division at Schindler Elevator. He is an INCOSE Certified Systems Engineering Professional (CSEP).mehr
Verfügbare Formate
BuchGebunden
EUR153,50
E-BookPDF2 - DRM Adobe / Adobe Ebook ReaderE-Book
EUR122,99
E-BookEPUB2 - DRM Adobe / EPUBE-Book
EUR122,99
E-BookEPUB2 - DRM Adobe / EPUBE-Book
EUR122,99
E-BookPDF2 - DRM Adobe / Adobe Ebook ReaderE-Book
EUR122,99

Produkt

KlappentextMODEL-BASED SYSTEM ARCHITECTURE
AN UP-TO-DATE EXPLORATION OF THE NEWEST STANDARDS AND BEST PRACTICES IN SYSTEM ARCHITECTING
In the newly revised Second Edition of Model-Based System Architecture, a team of expert engineers deliver a detailed and authoritative review of the practice of system architecture in organizations that use models to support the systems engineering process. In the book, readers will find introductions to the fundamentals of architecting systems and using models to assist the architecting process.
The latest edition offers refreshed content based on ISO 15288:2015 and a renewed focus on the role of the system architect. New chapters on systems-of-systems, and cyber-physical systems, and system architect tools offer guidance to practicing professionals on how to apply the presented concepts in the real-world.
In addition to the latest definitions of the architecture governance and evaluation processes described in ISO 42020 and 42030, the book provides: A thorough introduction to the value of systems architecting, definitions of system architecture, and model-based system architecture
Comprehensive explorations of model governance, architecture descriptions, patterns, and principles, and the roles of typical architecture stakeholders
Practical discussions of Agile approaches to systems architecture, the FAS Method, and architecture frameworks
In-depth examinations of systems architecting work and necessary soft skills for systems architects
Modeling of system architectures with SysML including a brief overview of SysML v1 and an outlook to SysML v2

Perfect for system architects and system engineers, Model-Based System Architecture will also earn a place in the libraries of students and researchers studying functional architectures.


TIM WEILKIENS is Executive Board Member of Oose, a German engineering consultancy, and a co-author of the SysML specification.

JESKO G. LAMM is a Senior Systems Engineer in the European hearing healthcare industry.
STEPHAN ROTH is a coach, consultant, and trainer for systems and software engineering at oose. He is a certified systems engineer (GfSE)®- Level C.
MARKUS WALKER is Elevator System Architect in the CTO Division at Schindler Elevator. He is an INCOSE Certified Systems Engineering Professional (CSEP).
Details
Weitere ISBN/GTIN9781119746676
ProduktartE-Book
EinbandartE-Book
FormatEPUB
Format Hinweis2 - DRM Adobe / EPUB
FormatFormat mit automatischem Seitenumbruch (reflowable)
Erscheinungsjahr2022
Erscheinungsdatum05.04.2022
Auflage2. Auflage
ReiheWiley Series in Systems Engineering and Management
Seiten464 Seiten
SpracheEnglisch
Dateigrösse21861 Kbytes
Artikel-Nr.9123274
Rubriken
Genre9201

Inhalt/Kritik

Leseprobe

3
Better Productsâ-âThe Value of Systems Architecting

When driving down to the beach in a nice new car, we may enjoy how well this car grabs the road, and if mentally not yet ready for the beach, we might ask ourselves which department in the car company is responsible for the driver's feeling that the car grabs the road. Is it the suspension design unit or the department with all the steering experts? We believe that all these departments alone cannot make us feel that the car grabs the road, because to do so, the car manufacturer has to see the car as a system, as a collection of things that interact with each other and with the driver and the road [166]. Systems architecting will ensure that the interactions between components are controlled in a proper way and that components are designed to fit each other.
3.1 The Share of Systems Architecting in Making Better Products

The example of the car that grabs the road was given by J.N. Martin [166]. We extend this example by speculating what would happen if different developers of car components were asked whose merit it is that the car grabs the road. As a reply, maybe the car manufacturer's suspension department and steering experts as well as the tire companies would claim that they are the ones, by making the best possible suspension, steering, tires, etc., but in contrast to this, consider the following example by Russell L. Ackoff: Suppose we bring one of each of these [many existing types of automobiles] into a large garage and then employ a number of outstanding automotive engineers to determine which one has the best carburetor. When they have done so, we record the result and ask them to do the same for engines. We continue this process until we have covered all the parts required for an automobile. Then, we ask the engineers to remove and assemble these parts. Would we obtain the best possible automobile? Of course not. [5, p. 18].

Since systems architecting is concerned with making components fit together instead of making them the best each on its own, we believe that systems architecting is an approach that will help an organization think, develop, produce, and maintain better products.
3.2 Benefits that can be Achieved

When talking of better products, then better can have two different meanings:
More satisfying or even more enjoyable for customers (as shown with the grabs the road example).
More profitable for the organization.

Of course, the first aspect may lead to the second one because products that are perceived well by the customer have the potential to become best-sellers and thus to generate profit for the organization.

It cannot be stated in general whether an organization sees it as most beneficial to minimize development cost, production cost, or maximize user satisfaction or certain quality measures. In the end, trade studies will determine the optimum trade-offs between these different criteria and probably many more. Systems architecting is the activity that will produce well-founded trade studies, because it is right in between the requirements analysis work and the solution space that is framed by the development of different system elements. Figure 3.1 illustrates this based on the example of system-level trade studies across the subsystems of the system-of-interest. Systems architecting can enable a top-down realization of business goals, requirements, quality criteria and product strategies into solutions. This is almost independent from whether a completely new system is developed (a very rare case) or whether an existing system needs to evolve further, by architecting increments to an existing solution. The only difference is that constraints from the existing solution will enter trade studies in systems architecting in the latter case, via the expertise from subsystem development.

It is via this top-down approach that usability, maintainability, reliability, etc. can be designed into the system and that concepts like design for user experience [100] or design to market [261] can be realized.

Figure 3.1 Systems architecting plays a major role in breaking down requirements to solutions and in optimizing solutions, for example, by finding good trade-offs.
3.2.1 Benefit for the Customer

Different kinds of businesses have different customers: While the consumer goods industry targets millions of individual consumers, subcontractors target industries whose suppliers they are. Despite the variety of customers addressed by different industries, we believe that any system developer will increase customer satisfaction with investments into systems architecting.

The good news for industrial customers of subcontractors is: We expect change requests and risk management to work very smoothly on a well-architected system with a proper architecture description in place. For example, we have seen cases in which the impact of a change could be easily analyzed, based on the architecture description, and since the system architecture captures dependencies inside the system, we also expect it to help analyzing how uncertainty in one area of the system may lead to risks in other areas. Being able to manage risk based on the knowledge of the system architecture is indeed a potential sales driver, if we believe in one of the conclusions of J.P. Monat's article Why Customers Buy [176]: customers' perception of risk seems to be an important factor in the purchasing decision.

The good news for consumers of mass products is: We expect a properly architected system to have a good chance of working as expected in the market place, because systems architecting can allow for thinking the different modes of operation into it instead of just testing them into it. Furthermore, well-defined interface descriptions may offer a basis for planning the systematic review or testing of component interactions in order to find flaws. This is particularly interesting with regard to discovering rare cases for which interfaces are not prepared. Well-documented architecture also enables continuous reassessment of quality, e.g. by means of reviews. Hence, there is a good basis for preventing flaws introduced by continuous changes during product improvements. This in turn may lower the threshold for continuous changes with the purpose of continuous product improvement.

Last but not least, the properly architected system has a good chance of achieving an attractive cost-benefit ratio, because the organization that developed the system and the production facility producing it could save development and production cost, as it will be explained in Section 3.2.2.
3.2.2 Benefit for the Organization

The standard ISO/IEC/IEEE 42010:2011 [114] declares that each system exhibits an architecture. In other words, every system development produces system architecture. The question is whether the system architecture evolves implicitly or whether it is explicitly defined.

The precondition for the benefits to be discussed is an explicit way of systems architecting, where system development and its strategic planning explicitly involves system architecture processes. In case these are not yet established, there will be an initial investment into architecture work, before the organization can harvest the expected benefits.

Once an organization has established systems architecting as an integral part of system development, it should see the predictability and efficiency of system development increase and it should see cost decrease.

Predictability should be obtained because system architecture supports planning, risk management, and other activities with system-wide scope:
Planning is supported, because the knowledge about the system's architecture enables a completeness check of the work breakdown for the development work and the identification of dependencies between work packages. It is also supported because the order of integration and the needed verification can be planned and optimized according to knowledge about the system architecture.
Risk management is supported, e.g. because the system architecture determines the contribution of subsystems to the performance of the system-of-interest and thus needs to be known for quantifying the influence of risks in subsystem development on the overall risk profile of system development. This is applicable for both project risk (the risk of project failure or deviation from its objectives) and product risk (the risk of undesirably or even dangerously wrong product performance).
Staying in control of cyber-security will only be possible if the system-of-interest as a whole is architected for security, because intruders will find its weakest spot to attack it. Since the weakest spot may be an interface or a certain interaction pattern of several components, it is important to consider the system as a whole when foreseeing security measures and allocating them to the system's entities.
Technologies based on artificial intelligence (AI) will require the validation of data used for training the AI, but maybe also the continuous collection of data about the performance of the AI itself. This requires governance across the system about the acquisition and aggregation of data to stay in control of data validity and availability. Control is also necessary about the impact of the...
mehr