Járműipari kutatás és fejlesztés folyamata

Transcription

1 Járműipari kutatás és fejlesztés folyamata Hetedik előadás Sorozatfejlesztés lépései, résztvevői, feladatai 2 R&D V-model, Requirement management, Test Management, ASPICE

2 A Target V-Model The V-model is a term applied to a range of models, from a conceptual model designed to produce a simplified understanding of the complexity associated with systems development to detailed, rigorous development lifecycle models and project management models. Definition The V-model is a graphical representation of the System development lifecycle. It summarizes the main steps to be taken in conjunction with the corresponding deliverables within validation framework. The V represents the sequence of steps in a project life cycle development. It describes the activities to be performed and the results that have to be produced during product development. The left side of the "V" represents the decomposition of requirements, and creation of system specifications. The right side of the V represents integration of parts and their validation. 2 2

3 V-Model based development process Target Requirements & Test Management have to be applied overall levels Vehicle Principle Top-Down - Requirements-Driven Design and Testing Test Level 5 System Product Subassembly Component 3 Test Level 4 Test Level 3 Test Level 2 Test Level 1 3

4 V-model based development V-Model Objectives The V-model provides guidance for the planning and realization of projects. The following objectives are intended to be achieved by a project execution: Minimization of project risks: The V-model improves project transparency and project control by specifying standardized approaches and describing the corresponding results and responsible roles. It permits an early recognition of planning deviations and risks and improves process management, thus reducing the project risk. Improvement and guarantee of quality: As a standardized process model, the V-Model ensures that the results to be provided are complete and have the desired quality. Defined interim results can be checked at an early stage. Uniform product contents will improve readability, understandability and verifiability.* Reduction of total cost over the entire project and system life cycle: The effort for the development, production, operation and maintenance of a system can be calculated, estimated and controlled in a transparent manner by applying a standardized process model. The results obtained are uniform and easily retraced. Improvement of communication between all stakeholders: The standardized and uniform description of all relevant elements and terms is the basis for the mutual 4 understanding between all stakeholders. Thus, the frictional loss between user, acquirer, supplier and developer is reduced. 4

5 Architecture for System/Product Development System/Product Development System/Product Development process focus of the integrated parts and defines the interfaces of the sub-disciplines Electronic Hardware Embedded Software Development Development 5 Mechanics Development Valid for mechatronic products Technical disciplines development process handled separate due to heavily deviating technical content 5

6 PDC architecture is applicable to systems as well as single product development. System PDC Same process are valid for System developed with no separate HW/SW/ME process needed Additional interace definition to the sub-system integration HW SW MT Product A PDC HW SW 6 PL3 ME Product B PDC HW SW ME Each product of the system is developed acc. to same processes If relevant: software is developed acc. to specific SW process hardware is developed acc. to specific HW process mechatronic is developed acc. to specific ME process Requirements Management and Test Management 6

7 Example: Architecture for Electronic Products development process flow chart Product A PDC PL3 PDC HW SW ME ME HW SW PDC 7 7

8 V Model Based Development PDP Architecture for System/Product Development with programmable electronic System/Product Development Electronic Hardware Embedded Software Development Development Mechanics Development PL3 8 8

9 V Model Based Development PDP Architecture for systems or product development. System PDC System is developed acc. to PDC no separate HW/SW/ME process needed + Requirements Management and Test Management HW SW MT Product A PDC HW SW 9 PL3 ME Product B PDC HW SW ME Each product of the system is developed acc. to PDC If relevant: software is developed acc. to specific SW process hardware is developed acc. to specific HW process mechatronic is developed acc. to specific ME process + Requirements Management and Test Management 9

10 V Model Based Development Example:Electronic Products PL3 PDC Product A PDC HW SW ME ME HW SW PDC 10 10

11 V Model Based Development V model Principle Top-Down - Requirements-Driven Design and Testing Vehicle System Product Subassembly Component 11 Test Level 5 Test Level 4 Test Level 3 Test Level 2 Test Level 1 11

12 Processes Perform AE Workshop Evalauate technial feasibility (serial dev experience) 12 Feedback input requirements(cust., LL, Legal, Std.) Create system requirement Plan and specify test (testability) Create concept alternatives (példa from AE vs. Serial) achive concept decision Det. product risks Create draft Design specification Prepare sample planning Design A sample Create requirement specification Plan and specify development test Update product risk Create design specification Built B samples Execute and review test Finalise serial design Update product risk Plan and specify validation test Built C samples Achive vendor tooling Execute and review tests Perforem technical release Perforem product Approval (homologaition) Support production Initial sample test Roles Serial maintenence 12 Execute A sample test

13 Requirement Management PDC integrates detailed steps for Requirements Management & Test Management TCM Elicit and evaluate Input Requirements (RQ 1) describes the necessary steps and documents for collection and review of external requirements (from customers, standards and laws). TPD Create Requirement Specification (RQ 2) translate Input Requirements Specification (RQ1) into internal KB requirements written and introduces further descriptions and terminology that are specific to KB. TPD Create Design Specification (RQ 3) translate a RQ2 Requirements Specification into a description of a solution. TPD Plan and specify tests (RQ 4) process steps and documents for test planning and test specification to ensure the functional safety and the quality of the development results 13 TPD Execute and review tests describes how to execute tests based on the planned and specified Test Cases and test Specifications.

14 Requirement Management Purpose of Requirement Management 14 14

15 Requirement Management Requirement Management A A 15 15

16 Requirement Management Requirement Management 16 16

17 Requirement Management Requirement Management Tracebility is a key to confirmance and compilance Input requ. System requ. Design requ. Component Product / Stytem 17 17

18 Requirement Management A A A 18 18

19 Requirement Management Requirement Management A A 19 19

20 Requirement Management Requirement Management 20 20

21 Requirement Management Categories of Requirements Safety-related requirements: Safety functions are descriptions that directly reduce the hazards identified in the FHA. The safety-related requirements will be derived from the Failure Hazard Assessment (FHA) on system level. The descriptions are developed using the general rules of requirements development to ensure there quality. Safety requirements shall be identified with the Safety Related attribute to enable filtering of all these specific requirements within the general requirements database. For safety related requirements the attribute ASIL should be defined. FMEA-related requirements: FMEA-related requirements are requirements which should be considered in the FMEA. FMEA-related requirements should be aligned with the corresponding functions within the FMEA

22 Requirement Management Categories of Requirements Cross-customer and customer-specific requirements: Cross-customer requirements should be considered at more then one customer. Functional and non-functional requirements: Functional Requirements are describing actions on individual parts or on the systems. Non-functional requirements describe quality or how well the system does something, not what it does. They can be used in conjunction with functional requirements to specify the action of the system or device more fully

23 Requirement Management Requirement management tasks in detailes Baseline of Requirement Specification Negotiate and agree Input Requirement Specification with customer Elicit and store external customer and non-customer requirements Evaluate Input Requirements and identify deviation Review the evaluated requirements and communicate the result to the customer Secure traceability to Requirement Specification RQ2 Baseline of Requirement Specification possible? Baseline of requirement Specification possible? Derive and describe Requirement Specification based on Input Requirement Specification Describe and assign safety related requirements Review the Requirement Specification Secure requirements and FMEA consistency Secure traceability of Requirement Specification with RQ 1, RQ 3 and Test Specification Change of Requirement Specification (RQ 2) and Design Specification (RQ 3) 23 23

24 Requirement management detailed process Document handling process Document workflow in RM tool No Start Start of new Project Yes Stakeholder Identification Document Workflow shown on the chart below All Item has his own workflow defined in the tool Define Project Scope and Goal Elicitation Requirements Specification Analysis Review Document Complete No Yes 24 End 24 24

25 RM Review/ Validation Process Quality Criteria of Requirements

26 RM Review/ Validation Process Quality measures related to individual requirements statements

27 Test Strategy Objective Test strategy of the projects defines what to test on which test level in order to ensure the as early as possible identificatoin of teh problem To achieve approval of a system/product/subassembly (hardware/software/mechanical) or its preceding prototypes for specific releases during product development

28 A Requirement Management Product Verification / Validagtoin Tracebility is a key to confirmance and compilance Component Product / Stytem 28 28

29 Test Management Intentions of TM Improvement of - Test planning - Test documentation - Traceability from requirement to test Reuse of Test cases (in different projects, test teams, at different test benches, etc.) Easy and customised reporting (for whole project, for single releases, for components, for test teams, etc.) Overview of test coverage, requirement coverage, passed/failed percentage, etc. Support of: - Manual online testing - Manual offline testing 29 - Automated testing 29 2

30 Overview Integration V-Model Integration to the V-Model RQ1: External Requirements RQ2: External + internal Requirements RQ3: Technical Solutions System-Test RQ4: Test Specification Integration-Test 30 Module-Test 30 30

31 Overview Principle of Test Management Test Plans n Test Requests n Test planning Test Sessions n Test execution Test Suites Test Cases n n Test Steps n Test specification 31 31

32 Technical Release Principle Review technical correctness and completeness and document deviations of the product/system with respect to use cases and failure modes Product Release Document created by: Protocol Document ID: Product: Product ID: (CVS or customer name) <Name> Baseline/ Revision: Sample Use Status: Sequence Electronic Hardware ID: (A/B/C/Series) A-Sample Software ID: Release Type: Data Set:: Viewing Project Name: Project No: Customer: (Name) Objective To achieve approval of a system/product/subassembly (hardware/software/mechanical) or its preceding prototypes for specific releases during product development. based on: Subassembly/ ID/ Rev Drawing ID/ Rev.: Supplier No.: Use Status: Release Protocol ID: released for: Comment: Related Documents: Document ID: Revision: Document ID: Revision: DVP&R: Safety Case: Use Restrictions: Comment: Release: Date: not approved (approved/ not approved)) Restriction (parts/ time): Summary: The Product <Name> (A-Sample status) was tested and not approved. It must not be used on Viewing. 32 Signatures: Function: Name / Dept./ Signature Date Function: Name / Dept./ Signature Date N/A N/A N/A N/A N/A 32

33 ASPICE ASPICE 33 33

34 ASPICE ASPICE 34 34

35 ASPICE ASPICE 35 35

36 ASPICE ASPICE 36 36

37 ASPICE ASPICE 37 37

38 ASPICE ASPICE 38 38

39 REFINED: V-Model for ASPICE with Roles Vehicle System Product (Subsystem) Subassembly Component Iterates for each potentially shippable increment Test Level 5 Test Level 4 Test Level 3 Test Level 2 Test Level

40 REFINED: V-Model for ASPICE with Roles Vehicle System Product (Subsystem) Subassembly Component Iterates for each potentially shippable increment Test Level 5 Test Level 4 Test Level 3 Test Level 2 Test Level

41 Köszönöm a figyelmet 41 41