Axiomatic product development lifecycle

Last updated

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.

Contents

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.

Overview

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.

APDL Domains

Customer domain

Customer Needs (CN) are elements that the customer seeks in a product or system.

Functional domain

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.

Physical 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 domain

Process Variables (PV) identify and describe the controls and processes to produce SC.

Test domain

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.

See also

Related Research Articles

Systems engineering Interdisciplinary field of engineering

Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design, integrate, and manage complex systems over their life cycles. At its core, systems engineering utilizes systems thinking principles to organize this body of knowledge. The individual outcome of such efforts, an engineered system, can be defined as a combination of components that work in synergy to collectively perform a useful function.

Configuration management Process for maintaining consistency of a product attributes with its design

Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. The CM process is widely used by military engineering organizations to manage changes throughout the system lifecycle of complex systems, such as weapon systems, military vehicles, and information systems. Outside the military, the CM process is also used with IT service management as defined by ITIL, and with other domain models in the civil engineering and other industrial engineering segments such as roads, bridges, canals, dams, and buildings.

Systems design interfaces, and data for an electronic control system to satisfy specified requirements. Systems design could be seen as the application of systems theory to product development. There is some overlap with the disciplines of systems analysis, systems architecture and systems engineering.

Automotive engineering, along with aerospace engineering and naval architecture, is a branch of vehicle engineering, incorporating elements of mechanical, electrical, electronic, software, and safety engineering as applied to the design, manufacture and operation of motorcycles, automobiles, and trucks and their respective engineering subsystems. It also includes modification of vehicles. Manufacturing domain deals with the creation and assembling the whole parts of automobiles is also included in it. The automotive engineering field is research intensive and involves direct application of mathematical models and formulas. The study of automotive engineering is to design, develop, fabricate, and test vehicles or vehicle components from the concept stage to production stage. Production, development, and manufacturing are the three major functions in this field.

In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" refers to an explicit, highly objective/clear requirement to be satisfied by a material, design, product, or service.

Systems development life cycle Systems engineering term

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life-cycle, is a process for planning, creating, testing, and deploying an information system. The systems development life cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

Product lifecycle Duration of processing of products from inception, to engineering, design & manufacture

In industry, Product Lifecycle Management (PLM) is the process of managing the entire lifecycle of a product from its inception through the engineering, design and manufacture, as well as the service and disposal of manufactured products. PLM integrates people, data, processes and business systems and provides a product information backbone for companies and their extended enterprises.

Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.

Systems architect

The systems architect is an information and communications technology professional. Systems architects define the architecture of a computerized system in order to fulfill certain requirements. Such definitions include: a breakdown of the system into components, the component interactions and interfaces, and the technologies and resources to be used in its design and implementation.

The incremental build model is a method of software development where the product is designed, implemented and tested incrementally until the product is finished. It involves both development and maintenance. The product is defined as finished when it satisfies all of its requirements. This model combines the elements of the waterfall model with the iterative philosophy of prototyping.

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. Specifically, a set of functional requirements(FRs) are related to a set of design parameters (DPs) by a Design Matrix A:

(In the automation and engineering environments, the hardware engineer or architect encompasses the electronic engineering and electrical engineering fields, with subspecialities in analog, digital, or electromechanical systems.)

Digital Prototyping gives conceptual design, engineering, manufacturing, and sales and marketing departments the ability to virtually explore a complete product before it's built. Industrial designers, manufacturers, and engineers use Digital Prototyping to design, iterate, optimize, validate, and visualize their products digitally throughout the product development process. Innovative digital prototypes can be created via CAutoD through intelligent and near-optimal iterations, meeting multiple design objectives, identifying multiple figures of merit, and reducing development gearing and time-to-market. Marketers also use Digital Prototyping to create photorealistic renderings and animations of products prior to manufacturing. Companies often adopt Digital Prototyping with the goal of improving communication between product development stakeholders, getting products to market faster, and facilitating product innovation.

Functional safety is the part of the overall safety of a system or piece of equipment that depends on automatic protection operating correctly in response to its inputs or failure in a predictable manner (fail-safe). The automatic protection system should be designed to properly handle likely human errors, systematic errors, hardware failures and operational/environmental stress.

In the United States military integrated acquisition lifecycle the Technical section has multiple acquisition "Technical Reviews". Technical reviews and audits assist the acquisition and the number and types are tailored to the acquisition. Overall guidance flows from the Defense Acquisition Guidebook chapter 4, with local details further defined by the review organizations. Typical topics examined include adequacy of program/contract metrics, proper staffing, risks, budget, and schedule.

ISO 26262, titled "Road vehicles – Functional safety", is an international standard for functional safety of electrical and/or electronic systems that are installed in serial production road vehicles, defined by the International Organization for Standardization (ISO) in 2011, and revised in 2018.

Arcadia (engineering)

ARCADIA is a system and software architecture engineering method based on architecture-centric and model-driven engineering activities.

Predictive engineering analytics (PEA) is a development approach for the manufacturing industry that helps with the design of complex products. It concerns the introduction of new software tools, the integration between those, and a refinement of simulation and testing processes to improve collaboration between analysis teams that handle different applications. This is combined with intelligent reporting and data analytics. The objective is to let simulation drive the design, to predict product behavior rather than to react on issues which may arise, and to install a process that lets design continue after product delivery.

This article discusses a set of tactics useful in software testing. It is intended as a comprehensive list of tactical approaches to Software Quality Assurance (more widely colloquially known as Quality Assurance and general application of the test method.

Human Systems Integration (HSI) is an interdisciplinary managerial and technical approach to developing and sustaining systems which focuses on the interfaces between humans and modern technical systems. The objective of HSI is to provide equal weight to human, hardware, and software elements of system design throughout systems engineering and lifecycle logistics management activities across the lifecycle of a system. The end goal of HSI is to optimize total system performance and minimize total ownership costs. The field of HSI integrates work from multiple human centered domains of study include training, manpower, personnel, human factors engineering, safety, occupational health, survivability and habitability.

References

  1. Bulent Gumus (2005). Axiomatic Product Development Lifecycle (APDL) Model. PhD Dissertation, TTU, 2005, "Archived copy" (PDF). Archived from the original (PDF) on 2011-07-20. Retrieved 2008-01-22.{{cite web}}: CS1 maint: archived copy as title (link)
  2. Suh (1990). The Principles of Design, Oxford University Press, 1990, ISBN   0-19-504345-6

Further reading