Difference between Set-based development and Point-based development
Last updated: May 21, 2024 Read in fullscreen view
- 02 Nov 2023 Differences between software walkthrough, review, and inspection
- 15 Feb 2024 What is a Cut-Over in Software Development?
- 27 Oct 2020 8 principles of Agile Testing
- 09 Oct 2022 Key Advantages and Disadvantages of Agile Methodology
- 21 May 2022 "Fail Fast, Fail Often, Fail Forward" is the answer to Agile practices of software success
1. Point-Based Design
Figure 1: Unstable time frame for point-based design
2. Set-Based Development
Set-based design, often written as simply SBD, is the practice of keeping design options flexible for as long as possible during the development process.
Set-based design is a design, analysis, and decision-making practice characterized by:
-
Not selecting a particular values for design decisions but rather analyzing the full set of possibilities, not as a finite collection of a few points, but as an infinite set of points.
-
Rather than trying to “pick the best”, instead trying to “eliminate the weak”.
-
Not selecting a particular design and then analyzing its performance, but rather analyzing the drivers of performance and limits on feasibility and using that knowledge to identify more desirable parts of the design space (of the full set of possibilities).
Set-based design allows teams to maximize flexibility, cost, and speed: Designs stay flexible throughout the development process. The team can adjust to new information as needed. Costs stay low because teams work to test assumptions before investing in technical solutions.
3. Set-Based vs. Point-Based Development
Task | Point-based Design | Set-based Design |
Search: How to find solutions | Iterate an existing idea by modifying it to achieve objectives and improve performance. Brainstorm new ideas. | Design a feasible design space, then constrict it by removing regions where solutions are proven to be inferior. |
Communication: Which ideas are communicated | Communicate the best idea. | Communicate sets of possibilities that are not Pareto (80/20 principle) dominated. |
Integration: How to integrate the system. | Provide teams design budgets and constraints. | Look for intersections that meet total system requirements. |