“What’s the best order to follow for product development?” “What’s the difference between the V-model and the waterfall model?” “Is Agile the best choice for projects with frequent design changes?”
When working in mechanical design or system development, you’ll inevitably face questions like these. The development process isn’t just a set of rules designed to increase the number of meetings and documents. It’s a method for reducing design rework and achieving a balanced approach to quality, cost, and delivery (QCD).
In this article, after reviewing the basic flow of product development, we’ll compare the characteristics of the Waterfall, V-Model, W-Model, Spiral, and Agile development approaches and discuss how to choose between them. With mechanical designers in mind, we’ll also present an example of developing a device that combines hardware and software.
What Is a Development Process? First, Let’s Understand the Big Picture of Product Development
A development process is a framework for systematically advancing activities—from organizing requirements through design, prototyping, and evaluation—until the product is completed. While the necessary steps vary depending on the size of the device and the industry, general product development can be organized as follows.
| Phases | Main Decisions and Actions | Typical Deliverables |
|---|---|---|
| ① Planning and Requirements Definition | Whose problems are being solved, and what are the target costs and delivery dates? | Planning Document and Requirements Specifications |
| ② Concept Development and Basic Design | Product approach, configuration, major components, and technical feasibility | Concept diagrams and system configuration diagrams |
| ③ Detailed Design | Specify dimensions, tolerances, materials, circuits, control specifications, etc. | 3D CAD, Drawings, BOM, Design Specifications |
| ④ Prototyping and Assembly | Produce prototypes and integrate mechanical, electrical, and software components | Prototypes, Programs, Assembly Records |
| ⑤ Verification and Validation | Verify that the product meets specifications and is suitable for its intended use | Test results and evaluation reports |
| ⑥ Mass Production, Implementation, and Improvement | Establish manufacturing conditions, quality control, and procedures for maintenance and improvement | Process Specifications, Inspection Standards, and Change History |
For example, when developing a “compact blower with temperature control,” you first determine the required airflow, installation space, noise level, and cost. Next, you design the fan, sensors, control board, and enclosure, build a prototype, and evaluate factors such as temperature, noise, and durability.
The key point is that finalizing the drawings and ensuring the product is actually usable are two separate matters. If interim testing reveals that cooling performance is insufficient, the fan and airflow path must be redesigned. That is precisely why it is essential to clearly define at each stage “what needs to be verified before moving on to the next step.”
Even for small-scale projects, not all stages are omitted. While the format of reviews and the volume of documentation may be streamlined, it is still necessary to verify requirements, risks, and evaluations.
For insights on the mindset before starting development, see the related article “Before Development and Design.”
PDCA and Design Review (DR) Supporting the Development Process
The PDCA Cycle: Try, Measure, and Return to Design
PDCA is an improvement methodology that involves repeating the cycle of Plan → Do → Check → Act. While it is not a development model in itself, it can be applied to prototyping, evaluation, improvement, and process management.
For example, if the noise from a blower exceeds the standard, we formulate a hypothesis about the cause (Plan), modify the airflow path (Do), remeasure the noise (Check), and update the design specifications (Act). It is important to link the measurement results to the next design decision.
DR (Design Review): Determining Whether to Proceed to the Next Process
A DR (Design Review) is an activity in which stakeholders verify the design details and identify risks and unresolved issues. At major milestones in the process, it may also be conducted as a gate review to determine whether to proceed to the next process.
As a general rule, people with the expertise required for the agenda—such as those from design, manufacturing, quality assurance, procurement, and testing/evaluation—should be gathered. Rather than setting a fixed number of participants, prioritize ensuring that all roles necessary for making the decision are represented.
During a DR, at least the following five points should be verified:
- Compliance with Requirements: Are there any discrepancies between the requirements specifications and the design?
- Technical Feasibility: Is there a basis for aspects such as strength, thermal performance, vibration, and electrical safety?
- Unresolved Risks: Are the points of concern, countermeasures, responsible parties, and deadlines clearly defined?
- Verification Plan: What will be tested, under what conditions, and how will pass/fail be determined?
- Decision on Next Process Step: Approval, conditional approval, or rejection.
The value of a DR lies not in holding a meeting to report that “there were no issues,” but in making it a forum for quickly identifying problems and deciding on countermeasures. For more on constructive exchange of opinions, see the related articles “Collective Intelligence” and “DESC Communication Method.”
Differences Between Waterfall, V-Shaped, W-Shaped, Spiral, and Agile [Comparison Table]
When selecting a development process, it’s easier to make a decision by comparing the frequency of requirement changes, the impact of failure, prototyping costs, and delivery deadlines rather than focusing on “which model is newer.”
| Development Model | Characteristics of the Approach | Suitable Situations | Key Considerations |
|---|---|---|---|
| Waterfall | Proceeds in stages: requirements → design → implementation → evaluation | Projects where requirements are relatively stable and process management is desired | Misunderstandings in the early stages can lead to significant rework in later stages |
| V-Model | Links the design phase with corresponding verification and validation activities | Projects where quality requirements are clear and test traceability is critical | Effectiveness decreases if test planning falls behind |
| W-Model | Conduct reviews and test design in parallel starting from the requirements and design phases | Projects where you want to detect missing requirements or design flaws early | Requires man-hours for early review and verification activities |
| Spiral Model | Iterate through risk analysis, prototyping, and evaluation | Projects with high uncertainty or development risks, such as those involving new technologies | Risk management and iterative planning tend to become complex |
| Agile Development | Develop in small increments and obtain feedback in short cycles | Projects where requirements are prone to change and value can be delivered incrementally | Requires frequent integration, quality control, and consensus among stakeholders |
The V-model and W-model are often explained in conjunction with waterfall-style process management. Additionally, there are multiple ways to represent the process diagrams and terminology of the W-model. The table below organizes this information based on the concept of bringing verification forward from the design phase.
① What Is the Waterfall Model? A Development Methodology That Proceeds Through Phases in Sequence
The Waterfall Model is a development model that divides processes—such as requirements definition, design, implementation, and testing—into distinct phases and proceeds through them in sequence. By clearly defining completion criteria and deliverables for each phase, it facilitates the management of progress, quality, and cost.
One advantage is that it makes it easy to organize responsibilities, deliverables, and review schedules. It can also be used for developing equipment with a large number of parts or for projects where components are ordered from external manufacturers.
On the other hand, a disadvantage is that if requirement changes or fundamental issues are discovered late in the design phase, it requires significant revisions to drawings, molds, jigs, test conditions, and other elements.
Example from a design workplace: Development of a derivative model of an existing device with clearly defined dimensions, performance requirements, and delivery conditions. Milestones are set, and production proceeds after drawing approval. However, this does not mean there are absolutely no rework cycles during actual development.
② What Is the V-Model? A Method for Aligning Design and Testing
The V-model is an approach that places the specification and refinement of requirements and design on the left side, and the corresponding verification and validation on the right side.
For example, in the case of a blower unit, the correspondence is as follows:
| Decisions made by the design team | Corresponding key verifications |
|---|---|
| Customer’s intended use, required airflow, and noise requirements | Acceptance evaluation and validation in the operating environment |
| Overall unit configuration and control specifications | System testing |
| Connection specifications for fans, temperature sensors, and control boards | Integration and system testing |
| Detailed specifications for components, circuits, and programs | Component testing and unit testing |
The core of the V-model is determining “how to verify acceptance” at the design stage. It does not simply mean conducting all testing at the very end. Process names and test levels vary depending on the product type and standards.
③ What Is the W-Model? An Approach to Detecting Defects Starting from the Requirements and Design Stages
The W-model is often used to describe an approach that places a stronger emphasis on reviews, verification, and test design in upstream processes than the V-model does. It is characterized by “shifting left”—that is, verifying requirements and design documents before the actual product is completed.
Example from a design site: If you realize after a prototype is built that “the temperature sensor is poorly positioned and isn’t measuring the actual temperature,” you may have to redo the enclosure design or wiring harness.
Under the W-shaped model approach, activities such as reviewing sensor placement, performing thermal analysis, and confirming verification conditions are carried out during the conceptual and detailed design phases to minimize the need for rework. Early verification in this context includes verification conducted without running the actual unit, such as reviewing documentation and performing analyses.
④ What Is the Spiral Model? Repeating Prototyping While Assessing Risks
The spiral model is a development approach that progresses by repeating the cycle of planning → risk analysis → prototyping and development → evaluation, while managing risks. It is important not only to increase the number of prototypes but also to clearly identify “what is uncertain and which experiments will verify it.”
Example from a design setting: Development incorporating a new cooling structure. A phased validation process—such as first examining airflow with a simple prototype, then conducting thermal analysis and temperature tests, and finally designing the enclosure based on those results—is effective.
However, the iteration cycle varies depending on the project and the risks involved; it is not defined by a fixed period ranging from half a year to several years. For low-risk projects, this approach can sometimes result in excessive management costs.
⑤ What Is Agile Development? Building Value in Short Cycles
Agile is an approach that incorporates feedback from customers and users to enhance product value while adapting to change. Practical methods include Scrum, among others, and Agile does not equate to a single, specific process diagram.
Example from a design setting: This development approach involves first implementing measurement and display functions in a temperature control device, evaluating it in the field, and then gradually improving features such as alarm functions and data storage capabilities. By conducting verification in short cycles, it becomes easier to confirm usability and identify truly necessary functions.
While updating individual features is relatively easy in software development, mechanical components are subject to constraints such as tooling costs, procurement lead times, prototyping equipment, and safety testing. In hardware development, rather than applying short-cycle iterations to everything, it is more practical to apply them to components that are easier to iterate on, such as prototypes, control software, and user interfaces.
Furthermore, regression testing to verify that existing functions have not been broken with each change, configuration management, and consensus among relevant departments are essential.
[Practical Guide] Which Development Model Should Mechanical Designers Choose?
When in doubt, consider the following four perspectives.
- Are the requirements finalized?: If drawing specifications and customer requirements are stable, phased management is advantageous.
- Is the impact of failure significant?: If safety or regulatory compliance is critical, prioritize traceability between requirements and verification, as well as thorough reviews.
- Is there a high degree of technical uncertainty?: For unknown principles or new materials, early prototyping and risk verification are effective.
- Can the product be evaluated in stages?: Short-term iterations are well-suited for areas where it is easy to gather user feedback, such as software and UI.
| Examples of Development Projects | Examples of Suitable Approaches | Reason |
|---|---|---|
| Modifications to existing equipment with finalized specifications | Waterfall + DR | Easy to manage the scope of changes and processes |
| Control devices requiring high reliability | V-Model + Early Review | Maps requirements to verification items easily |
| Products with significant rework during the testing phase | Adopts the W-Model approach | Early confirmation of design documents and test specifications is effective |
| Cooling and drive systems based on new principles | Spiral model | Allows for repeated prototyping and risk analysis |
| Continuous improvement of user interfaces and control software | Agile development | Enables evaluation and improvement in small functional units |
In practice, a combination of approaches is effective. For example, while managing the entire system using the V-model, you can verify only new mechanisms through iterative prototyping and use an agile approach for improving the user interface.
5 Checkpoints to Reduce Design Re-work
- Do the requirements specifications include numerical values, conditions, and pass/fail criteria? (e.g., meets the required airflow at an ambient temperature of 35°C).
- Are the assumptions and rationale used for design decisions documented in drawings, calculation sheets, and test specifications?
- Have you considered the impact on connection points and surrounding components, not just individual parts?
- Have you assigned a responsible person, deadline, and completion criteria to issues identified in the DR?
- Have you planned a reassessment of the scope of impact and regression testing following the design change?
This book is also a useful reference.
Project Framework Encyclopedia: 85 Tools You Can Use for a Lifetime—From Conceptualization to Planning, Progress Management, and Organizational Management
Frequently Asked Questions (FAQ)
Q1. Are development process and development methodology the same thing?
Strictly speaking, they are different. A development process refers to the entire set of activities, such as requirements gathering, design, and verification, while development models—such as Waterfall and Spiral—define how those activities are carried out.
Q2. What is the difference between the V-model and the waterfall model?
The waterfall model is an approach that progresses through phases in a step-by-step manner. The V-model, in addition to this, emphasizes clarifying the requirements and design details along with the corresponding tests, and systematically conducting verification and validation.
Q3. Are physical tests unnecessary with the W-model?
No, they are not. While the W-model is based on the concept of early problem detection through upstream reviews and analysis, it is still necessary to verify performance, safety, and durability using actual hardware.
Q4. Can Agile be used in mechanical design?
It can be used in certain areas. Iteration is effective for conceptual prototyping, user interfaces, control software, and adjusting evaluation criteria. On the other hand, processes requiring molds or mass-production equipment should be planned with change costs in mind.
Summary: Choose an Approach That Reduces Rework Over a ‘Correct’ Development Model
In the development process, what matters is not “following a set of procedures,” but clarifying what decisions to make and what to verify at each stage.
- Waterfall: Manages processes and deliverables in stages.
- V-Model: Clarifies the relationship between requirements, design, and testing.
- W-Model: Brings reviews and verification forward from the requirements and design stages.
- Spiral Model: Reduces technical uncertainty through risk analysis and prototyping.
- Agile Development: Develop in small increments and improve based on feedback.
Choose an approach that suits your company’s development by considering not only product quality but also the number of prototypes, the impact of design changes, procurement lead times, and consensus-building with customers.
