Motivations. Case Study. Reference documents for the presentation

Transcription

1 Case Study Basic V Introduction &V Case Engineering Study Engineering approach for the design of commercial aircraft AGENDA Motivation SYSTEMS ENGINEERING concerns Presentation of the INCOSE document describing an application of s Engineering in the commercial aircraft domain Current status of the document Conclusions Reference documents for the presentation ANSI/EIA standard Version 1.1: es for Engineering a system INCOSE document: Framework for the Application of s Engineering in the Domain of the development of complex Motivations Observation: Despite the progress made through the deployment of project management and program management approach since 1945 following observations have been made on many programs: major delays problems with quality overcost

2 Chaos report - extract NASA study (1985) Factors of success Factors of failure Costs during feasibility/definition phases in % of development costs 40% Needs / / Specifications 48% % 23% Technique / Technologies Project / Resources 11% 9% Final excess cost % % Electronic data manager 8% -20 Motivations / conclusion The conventional Engineering approach leads to a vision of the product as the sum of optimized /systems s Engineering relies on this knowledge to propose a vision of the product as a system optimized in its environment SYSTEMS ENGINEERING concerns What is s Engineering s engineering is an interdisciplinary approach used to control the development of complex systems. This approach starts with the definition of customer needs, the identification of product functionalities and their validation very early in the cycle. s engineering integrates these disciplines to place them at the disposal of specialized groups so that they can perform team work facilitated by a structured, multi-level development integrating activities from the feasibility phase to operational support. s engineering simultaneously considers the technical and economic aspects of all stakeholders in order to supply the end customer with a quality product which meets his needs. MIL STD 499A Engineering Management MIL STD 499A Engineering Management The evolution of s Engineering standards MIL STD 499B s Engineering EIA 632 s Engineering EIA-ANSI 632 es for Engineering a 98 IEEE 1220 Application & Management of s Engineering 94/95 ISO s Engineering Life cycle es > 2000

3 Key Concepts for s Engineering includes both End and Enabling Building Blocks are the basic unit of a s are developed in layers Consistent and complete set of es At each level, assess needs by considering all stakeholders to optimize the correct choice of any solution What means in s Engineering Notion of End and Enabling performs End Operation al Consists of performs Enabling Associated The diagram below (EIA 632) implicitly includes those developing, producing, testing, using, supporting and ensuring the extension of life as well as those training... The Building Block concept Layer Concept of Enabling Possible product breakdown

4 REQUIREMENTS OF OTHER STAKEHOLDERS Generic approach of requirements engineering in a s approach applied to each layer PURCHASER REQUIREMENTS SYSTEM REQUIREMENTS allocated allocated LOGICAL SOLUTION REPRESENTATION derived derived DERIVED REQUIREMENTS allocated allocated PHYSICAL SOLUTION REPRESENTATION source of DESIGN SOLUTION defined by Consistent and complete set of es (EIA 632) Request Plans, Directives & Status Technical Management Planning Assessment & Supply Supply Solution Realization Implementation Transition to Use s Outcomes & Feedback Technical Evaluation SPECIFIED REQUIREMENTS s Analysis Verification End The baseline applicable to the project Presentation of the INCOSE document describing a s Approach for the design of commercial aircraft: Framework for the Application of s Engineering in the Domain What You ll Find in the Guidelines 1.0 Introduction 2.0 Domain 8 p 3.0 Life Cycle Framework 7p 4.0 Relationships 12p 5.0 Architecture 8p 6.0 s Engineering Management 6p 7.0 Verification Plan 1p 8.0 Test Plan 1p Appendix A - Linkage to Guidelines/Standards Appendix B - Acronyms Appendix C - References Appendix D - 12p Appendix E - Glossary Appendix F- Comments Form s approach applied to the characterization of the commercial aircraft domain 1.0 Introduction 2.0 Domain 3.0 Life Cycle Framework 4.0 Relationships 5.0 Architecture 6.0 s Engineering Management 7.0 Verification Plan 8.0 Test Plan Air Transport Airports Air Traffic Pax & Cargo s Worldwide Air Transport Things That Fly Places to Depart From & Return To Traffic Things That Handle Pax & Cargo

5 Decisive factors for the design of a commercial aircraft Breakdown and Boundary Natural, Ecological Land, Oceans Atmosphere Climate Fauna & Flora Sciences Physics Economic Economic Structure of Customers: Airlines External Suppliers, Others Distribution of Resources Political, Legal, Policy Regulatory Infrastructure Legal Infrastructure Political Infrastructure aircraft End The (Engineering, etc.) system Test (Flight Test, Lab Test) World Air Transport The Overall Environment Air Transport Customer Airlines External Suppliers Regulatory agencies,... Enabling Training (Pilot training, etc) Technical Capability Existing Base Operational Practices State of Technology Cultural, Personal Public awareness Demographic features Views/biases of power brokers Subsystem Subsystem (Propulsion, Airframe, Avionics, Environmental, Crew Accommodations, Electrical, Interiors, Auxiliary) ion (Manufacture, Assembly) Deployment (Acceptance, etc.) Support (Fueling, Spares, Maintenance, Modification) Air Transport Architecture Air Transport Life Cycle Framework Enterprise Based Life Cycle Relationships Environmenta l Air Conditionin g Avionics Auto Flight Electrical Electrical Interiors Crew Accommodations Mechanical Flight s Propulsion Fuel Auxiliary Auxiliary Airframe Fuselage Other operational Elements Ground Starting Equipment Flight Deck Crew Enterprise Based Life-cycle Business Opportunity Study Business Opportunity Life-cycle Feasibility Study Project Go-Ahead Project Critical Project Full Scale First Delivery Cabin Pressure Ice & Rain Protection Oxygen Pneumatic Communica -tions Indicating & Recording Navigation Shipside Lighting Passengers Accommodations Water, Waste Lavs,Galley s & Plumbing Emergency Provisions Signs & Lights Hydraulic Landing Gears Pylon / Structure Plant Stablizer Wing Preliminary Concept Study Feasibility Study Concept Engineering Life-cycle Prototype Simulation Preliminary Preliminary Detailed Detailed First ion Article ion/sustaining Operational Deployment Upgrades Life Cycle Stages Relationship ANSI / EIA 632 JCAWG Guidelines Assessment of Opportunities Investment Decision Assessment of Opportunities and Marketing Investment Management Planning Technical Management Assessment Concept Subsystem and Pre- Deployment Life Cycle and Subsystem Request Plans & Agreement Directives & Supply Solution ion Outcomes & Feedback Deployment, Operations, Support, and ion Sustaining Outcomes Analysis Technical Evaluation Verification

6 The Operational Top-Level Provide and Distribute Communications Plan, Generate and Movement Provide Crew, Passenger, and Cargo Environment and Services Detect and Analyze Conditions for Flight Distribute Information Generate and Manage Internal and Manage s Materials Provide Airframe Movement and Attachment Capability Provide Containment and Internal Support Relationships between, and Verification in the Domain End Requirement and/or Verification B A C D Requirement Status of the document Draft Version 1.2a published in July 2000 Document is available at Next revision planned for Jan 2004 Introduction (1) In a customer focused organisation, successful product development must capture the views (i.e. the requirements) of all the interested parties (i.e. the stakeholders). In order to ensure that the developed product will satisfy the needs of the users of the product the requirements must be analysed for consistency and completeness. management is introduced to ensure that requirements are made widely available to the development team and that traceability information is maintained throughout the project hierarchy and through to verification. have traditionally been expressed using natural language and are likely to continue to be for some considerable time. The appearance of CASE tools which allow the expression of abstract or absolute engineering concepts in forms other than natural language have only served to complicate the requirements management activities, particularly in the area of traceability. Introduction (2) Whycapture requirements? Because they dictate what is required of a product in order for it to be accepted by potential customers. e.g. manufacturing, maintenance, ground crew, airlines, regulatory bodies etc. We need to elicit requirements which will satisfy the customer (and end users). We need to make the requirements widely available to the project team such that there is a common understanding of the problem domain. Whyanalyse requirements? How? To reduce the risk that we may be starting How? with an incomplete or inconsistent set of requirements i.e. to ensure that all the requirements of the proposed product are established at each level of abstr. To identify the key requirements i.e. the primary design drivers. The problem here is that customers might not know what their requirements are. To be successful in the market place we may have to guide the customers by illustration of what they could have. This is achieved by considering the views of the customers and users of the product. The provision of a common repository for requirements, distributed according to some managerial constraints ensures the project team have the necessary visibility. This is achieved by producing a model(s) of the requirements and reviewing the model with the stakeholders. Decisions must be made which may compromise some requirements - a trade off analysis is performed to balance conflicting requirements e.g. cost with performance What is the purpose of requirements management? To ensure that a complete set of the technical and managerial requirements of the product to be developed is available throughout the project lifecycle. To provide traceability between project requirements and implementation and verification at each level of abstr and between requirements at different levels of abstr. To ensure and be able to demonstrate that the correct product is delivered and that the product is developed within appropriate constraints. Introduction (3) How? This is achieved by providing a repository for the requirements and managing the issue status of different views of these requirements throughout the project. This allows impact analysis to be performed (forwards and backwards) which in turn facilitates the management of change, risk and non-conformance throughout the lifecycle. This is achieved by the inspection of traceability throughout the system development: between requirements at different levels between requirements and their realisation at each level between requirements and their verification at each level This is achieved by linking requirements to product variants and by baselining the requirements repository

7 End- Enabling- ion Test Deployment Training Support What is a requirement? Requirement structure & richness Example: BNEY-SER When producing requirements in Word document, developer shall use isef CARE Macro V5 or any isef tool agreed by BNE. REQUIREMENT RATIONALE STAKEHOLDER Emitted_by Supported_by Conditioned_by Associated_with Result_from Verified_by Allocated_to ASSUMPTION RISK TRADE_OFF Element definition Minimum Required example elements 1 Actor/initiator of This is the subject of Mandatory developer the sentence 2.Condition This define the when producing requirements /Assumption for conditions under which in Word document the takes place 3. Action This is a verb Mandatory shall use 4. Constraints of This qualifies the 5. Object of This is the thing acted Mandatory isef CARE Macro V5 upon by the actor 6. Object Refinement This qualifies the object or any isef tool agreed by (or source) BNE VERIFICATION PROCEDURE PRODUCT 7. Action Refinement (or destination) 8. Other / additional info This further qualifies the Non requirement material Most requirements should have 5-7 elements Relation between development level and product breakdown Complex product Airlines needs End- Main Comp. Main Comp. Main Comp. Main Comp. or system or system or system or system Thanks for you Attention Major Comp Item The result of architecting the product at one level is a set of sub- description at lower level Always have a SE view, if not the whole, think of the framework Sub-item