Axiomatic product development lifecycle

The Axiomatic Product Development Lifecycle (APDL) model was developed by Bulent Gumus in 2005. This new model is based on the Axiomatic Design method developed by MIT Professor Nam P. Suh (1991); 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.

APDL Explained:
For the purposes of managing development lifecycle knowledge and supportingdifferent development lifecycle activities such as requirements and change managementthroughout 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 designsolution stated in the DPs, is defined in the Physical Domain. The SC hierarchyrepresents 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 itpossible 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 APDLmodel 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 existsin the functional domain along with the functional requirement (FR) vector. The ICvector is used to capture the input constraints (IC), which are specific to overall designgoals and imposed externally by the customer, by the industry, or by governmentregulations. The ICs are derived from the CNs and then updated based on the other rulesand regulations that the product has to comply with but not mentioned in the CustomerDomain. This new vector helps establish the relationships between ICs and the CNs andalso helps allocate the ICs to the DPs. The mapping between the ICs and DPs mayrequire the decomposition of the ICs to allocate specific ICs to the lower level DPs. Thismapping 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 correspondingcomponent satisfies the allocated FRs and ICs, are defined in the {CTC} characteristicvector 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 relatedcomponents.” Each system component (including subsystems) must be tested before it isintegrated into the system to make sure that the requirements and constraints allocated tothat component are all satisfied.

At the end of the system development, the system must be tested to make sure thatthe system satisfies all of the functional requirements defined in the functionalspecification 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 itspurpose 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 systemor component and focuses solely on the outputs generated in response to selected inputsand execution conditions. (2) Testing conducted to evaluate the compliance of a systemor component with specified functional requirements.”

Figure: The APDL knowledge domains and the relationships

APDL Domain Contents:

Customer 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 designsolution (i.e., software, organization, etc.) in the functional domain.

The input constraints (ICs) are imposed externally by the customer, by industry standard, orby 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 domainthat are chosen to satisfy the specified FRs. DPs can be conceptualdesign solutions, subsystems, components, or component attributes.

The system components (SCs) are the physical entities that provide the design solutiondescribed as DPs. The hierarchical collection of the SCs forms thesystem physical architecture. SCs are either produced or selectedfrom 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 requirementspecification (RS) document are satisfied by the system.

The component/unit test cases (CTCs) are used to verify that the SCs (either subsystems orcomponents) 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 theproduct 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

*Bulent Gumus, 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
*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
*Suh, "The Principles of Design", Oxford University Press, 1990, ISBN 0-19-504345-6