Axiomatic Product Development Lifecycle
4
Axiomatic product development lifecycle From Wikipedia, the free encyclopedia The Axiomatic Product Development Lifecycle (APDL) in systems engineering is a model developed by Bulent Gumus in 2005. [1] This new model is based on the Axiomatic design method developed by MIT Professor Nam P. Suh since the 1990s [2] ; 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. 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 sol ution 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. Axiomatic product development lifecycle - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Axiomatic_product_development_lifecycle 1 of 4 8/15/2010 3:36 PM
description
Introduction to the new science of Axiometric Design
Transcript of Axiomatic Product Development Lifecycle
Axiomatic product development lifecycleFrom Wikipedia, the free encyclopedia
The Axiomatic Product Development Lifecycle (APDL) in systems engineering is a model developed by Bulent Gumus in2005.[1] This new model is based on the Axiomatic design method developed by MIT Professor Nam P. Suh since the 1990s [2];hence it inherits the benefits of applying the Axiomatic Design to product development. The Axiomatic Design method isextended to cover the whole product development lifecycle including the test domain and new domain characteristic vectors areintroduced 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 productdevelopment team throughout the development effort as well as to help capture, maintain, and manage the productdevelopment knowledge. The APDL model aims to improve the quality of the design, requirements management, changemanagement, project management, and communication between stakeholders as well as to shorten the development time andreduce the cost.
OverviewFor the purposes of managing development lifecycle knowledge and supporting different development lifecycle activities suchas requirements and change management throughout the whole product development lifecycle, one new domain and four newcharacteristic 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 thePhysical Domain. The SC hierarchy represents the physical architecture of the system or the product tree. The method forcategorizing the components with respect to system physical architecture varies with each organization. A general portrayalused 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 asDesign Structure Matrixes (DSM), change management, component-based cost management and impact analysis as well ascapturing structural information and requirement traceability.
Axiomatic product development lifecycle - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Axiomatic_product_development_lifecycle
1 of 4 8/15/2010 3:36 PM
Another difference between the AD and the APDL model is that in the APDL model the PVs describe the processes to producethe SCs, not the DPs. Another addition to the AD method is the input constraint (IC) vector that exists in the functional domainalong with the functional requirement (FR) vector. The IC vector is used to capture the input constraints (IC), which are specificto overall design goals and imposed externally by the customer, by the industry, or by government regulations. The ICs arederived from the CNs and then updated based on the other rules and regulations that the product has to comply with but notmentioned in the Customer Domain. This new vector helps establish the relationships between ICs and the CNs and also helpsallocate the ICs to the DPs. The mapping between the ICs and DPs may require the decomposition of the ICs to allocatespecific ICs to the lower level DPs. This mapping is used in evaluating the design solutions to assess if the proposed designsatisfies the allocated ICs.
The component test cases (CTCs), that are used to verify that the corresponding component satisfies the allocated FRs andICs, 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 (includingsubsystems) must be tested before it is integrated into the system to make sure that the requirements and constraints allocatedto 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 functionalrequirements 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 therequirements are achieved by the system. IEEE (1990) defines functional testing as “(1) Testing that ignores the internalmechanism of a system or component and focuses solely on the outputs generated in response to selected inputs andexecution conditions. (2) Testing conducted to evaluate the compliance of a system or component with specified functionalrequirements.”
APDL Domain ContentsCustomer domain
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.
Axiomatic product development lifecycle - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Axiomatic_product_development_lifecycle
2 of 4 8/15/2010 3:36 PM
The input constraints (ICs) are imposed externally by the customer, by industry standard, or by government regulations andthey 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 thespecified 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 hierarchicalcollection of the SCs forms the system physical architecture. SCs are either produced or selected from commercially availablealternatives.
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) documentare satisfied by the system.
The component/unit test cases (CTCs) are used to verify that the SCs (either subsystems or components) satisfy the allocatedFRs 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-downapproach 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.
References
Axiomatic product development lifecycle - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Axiomatic_product_development_lifecycle
3 of 4 8/15/2010 3:36 PM
^ Bulent Gumus (2005). Axiomatic Product Development Lifecycle (APDL) Model. PhD Dissertation, TTU, 2005, http://etd.lib.ttu.edu/theses/available/etd-11282005-154139/unrestricted/Gumus_Bulent_Diss.pdf
1.
^ Suh (1990). The Principles of Design, Oxford University Press, 1990, ISBN 0-19-504345-62.
Further readingB. 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 AnAvionics System”, Integrated Design and Process Technology Conference, June 2006.B. Gumus and A. Ertas, “Requirements Management and Axiomatic Design”, Journal of Integrated Design and ProcessScience, Vol. 8 Number 4, pp. 19–31, Dec 2004.Suh, Complexity: Theory and Applications, Oxford University Press, 2005, ISBN 0-19-517876-9Suh, Axiomatic Design: Advances and Applications, Oxford University Press, 2001, ISBN 0-19-513466-4
Retrieved from "http://en.wikipedia.org/wiki/Axiomatic_product_development_lifecycle"Categories: Engineering concepts | Evaluation methods | Manufacturing | Quality | Systems engineering
This page was last modified on 11 July 2009 at 12:04.Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms ofUse for details.Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
Axiomatic product development lifecycle - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Axiomatic_product_development_lifecycle
4 of 4 8/15/2010 3:36 PM
