tailieunhanh - Adamsen, Paul B. - Frameworks for Complex System Development [CRC Press 2000] Episode 1 Part 7

Tham khảo tài liệu 'adamsen, paul b. - frameworks for complex system development [crc press 2000] episode 1 part 7', kỹ thuật - công nghệ, cơ khí - chế tạo máy phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả | chapter 7 A Potpourri of SDF-Derived Principles Whether we will philosophize or we won t philosophize we must philosophize. Aristotle If I wished to punish a province I would have it governed by philosophers. Frederick II the Great The following principles have been derived during the course of study that lead to the development of the SDF described in the preceding chapters. These principles or heuristics have been collected under several broad categories none of which are absolute. I. General A system architect is responsible to define the interfaces internal to his her system but he she may not have control over those interfaces external to his her system. A sound architecture and a successfully managed program consider the total context within which the system must function over its full life cycle. It is not sufficient to develop an architecture for a deployed system that does not consider all contexts in which the system must function manufacturing integration and test deployment initialization normal operations maintenance operations special modes and states and disposal activities. II. Risk Acceptable risk is a key criterion in deciding to move from one activity to the next. The challenge is to quantify risk in an accurate and meaningful way. 2000 CRC Press LLC Allocation of resources is a key basis by which to measure and monitor risk. Risk in a system development activity can result from insufficient margin in technical cost and or schedule allocations. Program risk increases exponentially with requirements instability. Because upper-level requirements drive lower-level designs and requirements and because the number of system elements increases exponentially down the program hierarchy a few unstable top-level requirements can affect many lower-level system elements. Risk is difficult to manage if it has not been identified. In conceptual architecting the level of detail needed is defined by the confidence level desired or the