Axiomatic product development lifecycle

From Wikipedia, the free encyclopedia

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 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.”

Figure: The APDL knowledge domains and the relationships Image:APDL_KnowledgeDomains.jpg

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 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.


[edit] 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
Languages