Axiomatic Product Development Lifecycle (APDL) (also known as Transdisciplinary System Development Lifecycle (TSDL), and Transdisciplinary Product Development Lifecycle (TPDL) ) is a systems engineering product development model proposed by Bulent Gumus that extends the Axiomatic design (AD) method.[1][2] APDL covers the whole product lifecycle including early factors that affect the entire cycle such as development testing, input constraints and system components.
APDL provides an iterative and incremental way for a team of transdisciplinary members to approach holistic product development. A practical outcome includes capturing and managing product design knowledge. The APDL model addresses some weak patterns experienced in previous development models regarding quality of the design, requirements management, change management, project management, and communication between stakeholders. Practicing APDL may reduce development time and project cost.
APDL adds the Test domain and four new characteristics to Axiomatic design (AD): Input Constraints in the Functional Domain; Systems Components in the Physical Domain; Process Variables tied to System Components instead of Design Parameters; and Customer Needs mapped to Functional Requirements and Input Constraints.
APDL proposes a V-shaped process to develop the Design Parameters and System Components (detailed design). Start top-down with Process Variables (PV) and Component Test Cases (CTC) to complete the PV, CTC, and Functional Test Cases (FTC); And after build, test the product with a bottom-up approach.
Customer Needs (CN) are elements that the customer seeks in a product or system.
Functional Requirements (FR) completely characterize the minimum performance to be met by the design solution, product etc. FR are documented in requirement specifications (RS).
Input Constraints (IC) are included in the functional domain along with the FR. IC are specific to overall design goals and are imposed externally by CN, product users or conditions of use, such as regulations. IC are derived from CN and then revised based on other constraints that the product has to comply with but not mentioned in the Customer Domain.
The Design Parameters (DP) 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.
System Components (SC) provide a categorical design solution in the DP, where the categories represent physical parts in the Physical Domain. The SC hierarchy represents the physical system architecture or product tree. The method for categorizing varies. Eppinger portrays general categories as system, subsystem, and component Eppinger (2001). NASA uses system, segment, element, subsystem, assembly, subassembly, and part (NASA, 1995).
SC makes it possible to perform Design Structure Matrixes (DSM), change management, component-based cost management and impact analysis, and provides framework for capturing structural information and requirement traceability.
Process Variables (PV) identify and describe the controls and processes to produce SC.
A functional test consists of a set of Functional Test Cases (FTC). FTC are system tests used to verify that FR are satisfied by the system. Black-box testing is the software analog to FTC. At the end of the system development, a functional test verifies that the requirements of the system are met.
Component Test Cases (CTC) are a physical analog to White-box testing. CTC verify that components satisfy the allocated FRs and ICs. Each system component is tested before it is integrated into the system to make sure that the requirements and constraints allocated to that component are all satisfied.