Axiomatic product development lifecycle
Encyclopedia
The Axiomatic Product Development Lifecycle (APDL) in systems engineering
is a model developed by Bulent Gumus in 2005. This new model is based on the Axiomatic design
method developed by MIT Professor Nam P. Suh since the 1990s ; hence it inherits the benefits of applying the Axiomatic Design to product development. The Axiomatic Design method is extended to cover the whole product development lifecycle
including the test domain and new domain characteristic vectors are introduced such as the input constraint and system component vectors.
The objectives of APDL model are to guide the designers, developers, and other members of a transdisciplinary product development team throughout the development effort as well as to help capture, maintain, and manage the product development knowledge. The APDL model aims to improve the quality of the design, requirements management, change management, project management, and communication between stakeholders as well as to shorten the development time and reduce the cost.
A characteristic vector for the system components (SCs), that provide the design solution stated in the DPs, is defined in the Physical Domain. The SC hierarchy represents the physical architecture of the system or the product tree. The method for categorizing the components with respect to system physical architecture varies with each organization. A general portrayal used by Eppinger (2001) is system, subsystem, and component, although further categories are available, such as the system, segment, element, subsystem, assembly, subassembly, and part (NASA, 1995).
The SC vector and the SC hierarchy (system physical architecture) makes it possible to perform such analysis and activities as Design Structure Matrixes (DSM), change management, component-based cost management and impact analysis as well as capturing structural information and requirement traceability.
Another difference between the AD and the APDL model is that in the APDL model the PVs describe the processes to produce the SCs, not the DPs. Another addition to the AD method is the input constraint (IC) vector that exists in the functional domain along with the functional requirement (FR) vector. The IC vector is used to capture the input constraints (IC), which are specific to overall design goals and imposed externally by the customer, by the industry, or by government regulations. The ICs are derived from the CNs and then updated based on the other rules and regulations that the product has to comply with but not mentioned in the Customer Domain. This new vector helps establish the relationships between ICs and the CNs and also helps allocate the ICs to the DPs. The mapping between the ICs and DPs may require the decomposition of the ICs to allocate specific ICs to the lower level DPs. This mapping is used in evaluating the design solutions to assess if the proposed design satisfies the allocated ICs.
The component test cases (CTCs), that are used to verify that the corresponding component satisfies the allocated FRs and ICs, are defined in the {CTC} characteristic vector in the test domain. Component test is defined by IEEE Std. 610.12-1990 as “Testing of individual hardware or software components or groups of related components.” Each system component (including subsystems) must be tested before it is
integrated into the system to make sure that the requirements and constraints allocated to that component are all satisfied.
At the end of the system development, the system must be tested to make sure that the system satisfies all of the functional requirements defined in the functional specification document. The functional test cases (FTCs) are stored in the {FTC} characteristic vector in the test domain. Functional test is a glass (white) box test and its purpose is to prove that the requirements are achieved by the system. IEEE (1990) defines functional testing as “(1) Testing that ignores the internal mechanism of a system
or component and focuses solely on the outputs generated in response to selected inputs and execution conditions. (2) Testing conducted to evaluate the compliance of a system or component with specified functional requirements.”
The customer needs (CNs) that the customer seeks in a product or system, voice of the customer.
Functional domain
The functional requırements (FRs) completely characterize the functional needs of the design solution (i.e., software, organization, etc.) in the functional domain.
The input constraints (ICs) are imposed externally by the customer, by industry standard, or by government regulations and they set limits for acceptable DPs.
Physical domain
The design parameters (DPs) are the elements of the design solution in the physical domain that are chosen to satisfy the specified FRs. DPs can be conceptual design solutions, subsystems, components, or component attributes.
The system components (SCs) are the physical entities that provide the design solution described as DPs. The hierarchical collection of the SCs forms the system physical architecture. SCs are either produced or selected from commercially available alternatives.
Process domain
Process variables (PVs) that characterize the process to produce (i.e. manufacture, implement, code, etc.) the SCs.
Test domain
The functional test cases (FTCs) are used to verify that the FRs documented in the requirement specification (RS) document are satisfied by the system.
The component/unit test cases (CTCs) are used to verify that the SCs (either subsystems or components) satisfy the allocated FRs and design ICs.
The APDL model proposes a V-shaped process to develop the detail design (DPs and SCs), PVs and CTCs with a top-down approach and to complete the PVs, CTCs, and FTCs and produce and test the product with a bottom-up approach.
Note
The APDL model is also called as
Systems engineering
Systems engineering is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed over the life cycle of the project. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more...
is a model developed by Bulent Gumus in 2005. This new model is based on the Axiomatic design
Axiomatic design
Axiomatic design is a systems design methodology using matrix methods to systematically analyze the transformation of customer needs into functional requirements, design parameters, and process variables....
method developed by MIT Professor Nam P. Suh since the 1990s ; hence it inherits the benefits of applying the Axiomatic Design to product development. The Axiomatic Design method is extended to cover the whole product development lifecycle
Product life cycle management
Product life-cycle management is the succession of strategies used by business management as a product goes through its life-cycle. The conditions in which a product is sold changes over time and must be managed as it moves through its succession of stages.Product life-cycle Like human beings,...
including the test domain and new domain characteristic vectors are introduced such as the input constraint and system component vectors.
The objectives of APDL model are to guide the designers, developers, and other members of a transdisciplinary product development team throughout the development effort as well as to help capture, maintain, and manage the product development knowledge. The APDL model aims to improve the quality of the design, requirements management, change management, project management, and communication between stakeholders as well as to shorten the development time and reduce the cost.
Overview
For the purposes of managing development lifecycle knowledge and supporting different development lifecycle activities such as requirements and change management throughout the whole product development lifecycle, one new domain and four new characteristic vectors are added to the existing AD domains and characteristic vectors.A characteristic vector for the system components (SCs), that provide the design solution stated in the DPs, is defined in the Physical Domain. The SC hierarchy represents the physical architecture of the system or the product tree. The method for categorizing the components with respect to system physical architecture varies with each organization. A general portrayal used by Eppinger (2001) is system, subsystem, and component, although further categories are available, such as the system, segment, element, subsystem, assembly, subassembly, and part (NASA, 1995).
The SC vector and the SC hierarchy (system physical architecture) makes it possible to perform such analysis and activities as Design Structure Matrixes (DSM), change management, component-based cost management and impact analysis as well as capturing structural information and requirement traceability.
Another difference between the AD and the APDL model is that in the APDL model the PVs describe the processes to produce the SCs, not the DPs. Another addition to the AD method is the input constraint (IC) vector that exists in the functional domain along with the functional requirement (FR) vector. The IC vector is used to capture the input constraints (IC), which are specific to overall design goals and imposed externally by the customer, by the industry, or by government regulations. The ICs are derived from the CNs and then updated based on the other rules and regulations that the product has to comply with but not mentioned in the Customer Domain. This new vector helps establish the relationships between ICs and the CNs and also helps allocate the ICs to the DPs. The mapping between the ICs and DPs may require the decomposition of the ICs to allocate specific ICs to the lower level DPs. This mapping is used in evaluating the design solutions to assess if the proposed design satisfies the allocated ICs.
The component test cases (CTCs), that are used to verify that the corresponding component satisfies the allocated FRs and ICs, are defined in the {CTC} characteristic vector in the test domain. Component test is defined by IEEE Std. 610.12-1990 as “Testing of individual hardware or software components or groups of related components.” Each system component (including subsystems) must be tested before it is
integrated into the system to make sure that the requirements and constraints allocated to that component are all satisfied.
At the end of the system development, the system must be tested to make sure that the system satisfies all of the functional requirements defined in the functional specification document. The functional test cases (FTCs) are stored in the {FTC} characteristic vector in the test domain. Functional test is a glass (white) box test and its purpose is to prove that the requirements are achieved by the system. IEEE (1990) defines functional testing as “(1) Testing that ignores the internal mechanism of a system
or component and focuses solely on the outputs generated in response to selected inputs and execution conditions. (2) Testing conducted to evaluate the compliance of a system or component with specified functional requirements.”
APDL Domain Contents
Customer domainThe customer needs (CNs) that the customer seeks in a product or system, voice of the customer.
Functional domain
The functional requırements (FRs) completely characterize the functional needs of the design solution (i.e., software, organization, etc.) in the functional domain.
The input constraints (ICs) are imposed externally by the customer, by industry standard, or by government regulations and they set limits for acceptable DPs.
Physical domain
The design parameters (DPs) are the elements of the design solution in the physical domain that are chosen to satisfy the specified FRs. DPs can be conceptual design solutions, subsystems, components, or component attributes.
The system components (SCs) are the physical entities that provide the design solution described as DPs. The hierarchical collection of the SCs forms the system physical architecture. SCs are either produced or selected from commercially available alternatives.
Process domain
Process variables (PVs) that characterize the process to produce (i.e. manufacture, implement, code, etc.) the SCs.
Test domain
The functional test cases (FTCs) are used to verify that the FRs documented in the requirement specification (RS) document are satisfied by the system.
The component/unit test cases (CTCs) are used to verify that the SCs (either subsystems or components) satisfy the allocated FRs and design ICs.
The APDL model proposes a V-shaped process to develop the detail design (DPs and SCs), PVs and CTCs with a top-down approach and to complete the PVs, CTCs, and FTCs and produce and test the product with a bottom-up approach.
Note
The APDL model is also called as
- The Transdisciplinary System Development Lifecycle (TSDL) model.
- The Transdisciplinary Product Development Lifecycle (TPDL) model.
Further reading
- B. Gumus, A. Ertas, D. Tate and I. Cicek, Transdisciplinary Product Development Lifecycle, Journal of Engineering Design, 19(03), pp. 185–200, June 2008. DOI: 10.1080/09544820701232436.
- B. Gumus, A. Ertas, and D. TATE, “Transdisciplinary Product Development Lifecycle Framework And Its Application To An Avionics System”, Integrated Design and Process Technology Conference, June 2006.
- B. Gumus and A. Ertas, “Requirements Management and Axiomatic Design”, Journal of Integrated Design and Process Science, Vol. 8 Number 4, pp. 19–31, Dec 2004.
- Suh, Complexity: Theory and Applications, Oxford University Press, 2005, ISBN 0-19-517876-9
- Suh, Axiomatic Design: Advances and Applications, Oxford University Press, 2001, ISBN 0-19-513466-4