SYE (Fach) / SYE (Lektion)

Diese Lektion wurde von 0mathew0 erstellt.

Lektion lernen

zurück  |  weiter 1 / 2

• 1 What is Systems Engineering ·         Interdisciplinary approach (fachübergreifende Methode/Herangehensweise) ·         Focuses on o   Understanding stakeholder needs.. §  Holistically (ganzheitlich) §  Concurrently (gleichzeitig) o   Exploring opportunities o   Synthesizing (aufbauen) o   Verifying, validating (überprüfen/bewerten) evolving solutions ·         Considering complete problem from concept to disposal (vom Konzept zum Verkauf)
• 2 Stakeholder Expectations consist of Specification of end state / product item to be produced Bounds of resources, time, performance, other constraints  Interaction: Thoughout the SE process
• 3 Constraint / Assumption Constraint is a condition (or requirement, or design feature) that MUST BE MET Assumption is a condition that the team assumes MUST BE MET
• 4 What is Holism and is the opposite ·         Holism (view) o   Parts of a whole are in intimate interconnection o   Parts cannot exist independently (unabhängig) ·         Reductionism o   Understanding complex things by reducing them to their parts and interactions
• 5 Overall categories of Systems ·         Natural ·         Social ·         Engineered à SE FOCUS
• 6 What is an engineered system ·         An engineering system is a complex socio-technical system that is designed, developed, and actively managed by humans in order to deliver value to stakeholders.
• 7 4 Types of engineered systems ·         Product system ·         Service system ·         Enterprise system ·         System of system capability
• 8 System of a System, element characteristics ·         Elements may be regarded as systems, with o   Operational independence from each other o   Managerial Independence from each other
• 9 Complexity Consisting of interdependent (ineinandergreifende) entities (instanzen) that respond to their local and global environments.   Weaver (1948) relates complexity to types of elements and how they interact. ·         Disorganized Complexity is found in a system with many loosely coupled, disorganized and equal elements, which possesses certain average properties such as temperature or pressure. Such a system can be described by “19th Century” statistical analysis techniques. ·         Organized Complexity can be found in a system with many strongly coupled, organized and different elements which possess certain emergent properties and phenomena such as those exhibited by economic, political or social systems. Such a system can not be described well by traditional analysis techniques.   Weaver's ideas about this new kind of complex problem are one of the foundational ideas of systems thinking.
• 10 Emergence ·         The principle that entities exhibit (vorweisen) properties which are meaningful only when attributed to the whole, not to its parts. ·         As individual parts, feathers, beaks, wings, and gullets do not have the ability to overcome gravity. Properly connected in a bird, however, they create the emergent behavior of flight.   ·         emergence from description: for a given object, some of its properties may be identified as emergent with respect to a description of the object in terms of interacting elements ·         emergence from change: if a set of given elements are allowed to interact, the resulting system may have properties that are not found in any one of the elements
• Anzeige
• 11 Systems Thinking Is a way of understanding complex situations by looking at them as combinations of systems.
• 12 Martin’s seven samurai of systems engineering ·         the context system o   contains the problem ·         the intervention system o   is the central focus for the development project o   auch (narrower) System of Interest, System to be built genannt ·         the realization system ·         the deployed system ·         collaborating systems ·         the sustainment system ·         competing systems
• 13 Intervention System Boundary Is a prerequisite (Vorraussetzung) for unambiguous (eindeutig) requirements. Boundaries must be clear!
• 14 SE abstraction levels Systems thinking System, Elements, Relationships, Emergence, Holism, Reductionism, System of Interest, Boundary, Context, Environment, Type of System Systems Approach (concurrent, iterative, recursive) Identify and Understand Problems and Opportunities Synthesize Possible Solutions Analysis and Selection between Alt. Solutions Implementing and Proving a Solution Deploying, Using, and Sustaining Systems Stakeholder Responsibility SE Processes System Design and Realization Processes System Management Processes
• 15 Project management Consists of (equal weight).. Systems Engineering Project Control   Project management is the function of planning, overseeing, and directing the numerous activities required to achieve the requirements, goals, and objectives of the customer and other stakeholders within specified cost, quality, and schedule constraints
• 16 NASA Process Groups (3) System Design Processes Technical Management Processes Product Realization Processes
• 17 System Design Processes (NASA) Not linked to a single phase of the life cycle, most active at Pre-A, A, B and C   Stakeholder Expectations Definition Identify the stakeholders of the system Find out how they intend to use the systems Technical Requirements Definition Logical Decomposition Design Solution Definition
• 17.1 Stakeholder Expectation Process activities Establish a list of stakeholders Elicit their expectations Establish operations concept Define stakeholder expectations in acceptable statements Analyze stakeholder expectations for measures of effectiveness Validate traceability of expectation statements Obtain stakeholder commitment to the validated expectations Baseline stakeholder expectations
• 17.2 Design Solution Process activities Define an alternative design solutions Analyze each alternative design solution Select best design solution alternative Generate full design description Verify the fully defined design solution Baseline design solution requirements and descriptions Initiate development of enabling products Initiate development of next lower level products
• 18 Product Realization Processes (NASA) ·         Product Integration o   is used for non-leaf products only ·         Product Implementation o   is used for leafs only ·         Product Verification ·         Product Validation ·         Product Transition
• 19 Technical Management Processes (NASA) ·         Technical Planning ·         Requirements Management ·         Interface Management o   especially important when efforts are divided among parties ·         Technical Risk Management ·         Configuration Management ·         Technical Data Management ·         Technical Assessment ·         Decision Analysis
• 19.1 Technical Planning Process establishes a plan for managing each of the common technical processes establishes a plan for identifying and defining the technical effort required to satisfy the project objectives
• 19.2 Requirements Management The requirements management process manages the Stakeholder expectations Technical product requirements (down to the lowest level product component requirements)
• 19.3 Technical Risk Management Identify Analyze Plan Track Control (Communicate, Deliberate and Document)
• 19.4 Configuration Management Process The purpose of the CM Process is to ensure that the configuration of a product is known and the configuration of a product is reflected in product information, that any product change is beneficial and that any product change is effected without adverse consequences, and that changes are managed
• 19.5 Technical Data Management Is used to plan for, acquire, access, manage, protect, and use data of a technical nature to support the total life cycle of a system
• 19.6 Technical Assessment Process help monitor technical progress of a project through Periodic Technical Reviews provide status information to support system design, product realization and technical management decisions
• 19.7 Decision Analysis Decision analysis offers individuals and organizations a methodology for making decisions.
• 20 SE Engine Recursive Use Applying processes to subsystems Applying processes in next phase (for refinement) All engineered systems Start with A need Discovery of an opportunity Evolve through Stages of development to final disposition
• 21 System level architecture ·         Development is a Creative, recursive, iterative process ·         Skills needed o   excellent understanding of project objectives and constraints o   knowledge of potential technical means of delivering end products
• Anzeige
• 22 Product Hierarchy tiers Tier = Layer in Hierachy Low number = high level of abstraction Tier 0 = Black Box
• 23 Objective of SE (NASA) system is designed, built, and operated so that it accomplishes its purpose.. Safely In the most cost-effective way possible
• 24 Cost Cost is the value of the resources needed to design, build, operate, and dispose of it.
• 25 Effectiveness Effectiveness is a quantitative measure of the degree to which the system’s purpose is achieved
• 26 Cost-Effectiveness Trade-Offs ·         To reduce cost at constant risk, performance must be reduced. ·         To reduce risk at constant cost, performance must be reduced. ·         To reduce cost at constant performance, higher risks must be accepted. ·         To reduce risk at constant performance, higher costs must be accepted.   A solution is cost-effective when lower cost, lower risk, or a better performance performance must be traded for at least one of the following: higher cost, higher risk, or less performance.
• 27 Success.. To successfully build a system, you need a project (or programm) To successfully complete a project (or programm) you neet Processes Life-Cycle Phases
• 28 Project life cycle Decompose the project life into more manageable pieces NASA basic project life cycle processes: Formulation & Implementation   Common life cycle phases Exploration Concept Development Production Support Utilization Retirement   à Life cycle phases are not tied to SE processes, entire SE processes are considered and applied at each stage of the life cycle (when appropriate!).
• 29 Baseline Set of requirements, design, or documents
• 30 NASA Phases Pre-Phase A Conceptual Study Discover opportunities, gain ideas, research Phase A Preliminary Analysis Establish initial baseline - compatible to organization’s strategy Phase B Definition Define detail, establish initial baseline- compatible to meet mission needs Phase C/D Design and Development C Complete detailed design, manufacture hardware, code software D integrate products, create system Phase E Operations Phase Meet initially identified need, maintain support for that need Phase F decommissioning/disposal, review, analyze returned data
• 31 Project – Process Unterschied Prozesse sind fortführend und wiederholbar Projekte sind einzigartig und temporär
• 32 NASA KDP (Key decision point) Scheduled event at which decision authority determines (reviews) readiness of a project/program/progress to processd to the next life cycle. Phases always end with a KDP   Outcomes: DisApproval for continuation Approval for continuation Follow-up: Request for more information Request for termination Direction to continue in the current phase Redirection of the project
• 33 INCOSE (Decision Gate) = International Council on Systems Engineering Decision Gate (=KDP) New activities are blocked if entry or exit criteria is not met If it is accepted, project management must explicitly accept the risk Basic criteria questions Does the project deliverable still satisfy the business case? Is it affordable? Can it be delivered when needed? Purposes Ensure an acceptable elaboration of the business and technical baselines Ensure that the next step is achievable with acceptable risk Continue to foster buyer and seller teamwork Synchronize project activities KDP decision gates authority to proceed final acceptance of the project deliverable
• 34 MOE - Measure of Effectiveness Measure by which stakeholders expectations will be judged Qualitative in nature – not able to be used as a design-to requirement Does not depend on solution
• 35 MOP - Measure of Performance Quantitative measure Helps ensure that an MOE will be satisfied
• 36 TPM – Technical Performance Measure Performance attribute that is controlled and monitored Significant descriptor of the system Relates directly to an MOE or MOP
• 37 Concepts of Operations (ConOps) How the system will be operated during life-cycle phases (to meet Stakeh. Expect.) Describes System characteristics from operational perspective
• What is a requirement A requirement is a statement that identifies a product, service or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability.
• Functional Requirement Defines what functions need to be implemented to accomplish (erreichen) the objectives
• Performance Requirements Defines how well the systems needs to perform (the functions)
• Interface Requirement Defines the boundary between the system and its environment

zurück  |  weiter 1 / 2