I am hugely regretful for not running across this sooner! I’m also a software engineer thirsty for a better answer to quality management in software, and too have made connections to the quality management systems employed in automotive and other engineering disciplines. It also annoys me greatly that software development is not ubiquitously observed as an engineering discipline! At any rate, I share and commend your beliefs and ideas.

A couple general ideas though in response to “probability of method being correctly applied”: I think a lot of this is being solved through compiler innovations these days. Think templates in C++ or generics in C#. Also the notion of type inferencing and lambda expressions in both C# and now the C++0x standard, and the notion of co/contra-variance (think interface duality). Stuffing much of this down in the tooling allieviates both the expertise AND burden from the developer masses (if applied). Also, I’ve just as surely you have found patterns and principles to be effective vessels of better quality. The only thing lacking would be proof through numbers. Food for thought. For example, in SOLID principles, low cohesion is observed to improve robustness through a software lifecycle, just no hard data to prove it (yet).

On a more objective thought, the application of DFSS and the dreaded issue of data (or more abstractly, knowledge management) that Richard Durnall pointed out boils down to the tooling, I think. A data warehouse BI/OLAP approach to managing this data is the way to go. Then, you can manage your quality by shaping the grain of your Facts (what you want to measure), and let it continuously “feed” from the tooling output (IDE, compilers, build/test environments, etc). I also believe these “facts” will tie directly into the software methodology (some of which I would consider a component or subset of DFSS). Over time, I beleive the grain of the facts per the methodology will become apparent and just “come” with the tooling out of the box. Perhaps what we are talking about then would be a next-generation ALM system. (Whoever reads this and then builds one sucessfully – I have RIGHTS!)

Lastly, I see existing metrics in software such as in methodologies (e.g. story points), code metrics (maintainability index, cyclomatic complexity, class coupling, depth of inheritence, methods per interface/service, lines of code per method, parameters per method, types per component, etc), TDD (method pass/fail, test methods to product methods ratio) and so on to be actual contributors to DFSS metrics – effectively tying the entire SDLC together.

I’m curious about your thoughts about this and about DFSS for Software Engineering in general these days. Indeed I think the magnitude of this is much larger than most fathom, for software is silently spreading into the outer reaches of the universe – literally! Space craft, robotics, ECUs on cars, aircraft as you mention and perhaps one day nano-devices (which are little bros of classic robotics) – its everywhere.

Complex software is not at all deterministic. The code might not change over time (not always a reasonable assumption), but the execution of code can vary in unpredictable ways. Think of the Mandelbrot Set, generated by the simplest of programs:

Zn+1 = (Zn)^2 + C

Some algorithms and program structures are intrinsically non-deterministic. A goodly chunk of Computer Science has been devoted to distinguishing which ones *are* deterministic. Multi-process programs are especially difficult to design and verify, and the history of software engineering is littered with the corpses of expensive systems brought down by obscure race conditions.

Software always operates as part of a system, and noise can come from the analog part of the system i.e. the physical components that the software depends upon. Noise also comes from the operating environment. Software interacts with the world through inputs and outputs which are subject to the variation of the analog world. Software is designed to act upon data it expects, and can behave badly in response to data it doesn’t expect.

Probabilistic methods have been used in software design and verification since at least the 1960s. Software systems are often designed and tested in controlled environments that do not accurately model the conditions of the real world. Robust design techniques can be used to write more realistic specifications and discover unexpected interactions between the parts of a system.

tl;dr:

* Ideal programs running on ideal computers in an imperfect environment can be nondeterministic.
* Ideal programs running on imperfect computers in an ideal environment can be nondeterministic.
* Ideal programs running on ideal computers in an ideal environment can still be nondeterministic.

I found this through a Google search and at first I thought I was on the wrong page and then I though I was going to have something negative to say in response. But then I realised that this was all about software.

My interest in Robust design, DFSS and such is within the context of engineering design (mechanical, civil, electrical etc.). Within that context I have always thought of noise as being things like manufacturing operation randomness, wear, temperature changes and stuff like that. I always thought of software as being more precise. It’s not like the program comes out a little different each time it is copied or the code changes with time. So I am really fascinated by the application of methods that I think of as being probabilistic (robust design especially) in the software area. What is the randomness or uncertainty that you normally need to be robust against when developing software?

Thank you for your comment, and welcome!

For the most part, I’m talking about software products and services, and I should emphasize that I’m talking about applying methods that are associated with DFSS in the service of evolutionary design. Meaning that phases like Optimize are overlapping and continuous, prototypes are continuously built in testing and staging environments, and design improvements are continuously released into production as long as it remains profitable to do so.

From my point of view, evolutionary design is the goal, and DFSS provides a useful box of tools in service of that goal. How to manage evolutionary design is what we spend most of our time talking about here

While new process design may involve only a few of the organization’s functions or departments, the design of a new product or a new service has stakeholders throughout the company’s value creation process. Additionally, if errors or omissions in product design data are not addressed early, more costly changes are required later in the product development process.

The difference between product and service development is the level of detail and complexity mainly in the Optimize phase of the DFSS project. In product design projects, the Optimize phase is the phase when the design “becomes real.” First prototypes will be built; data must be collected on tangibles even if simulating the processes.

Advanced DFSS programs include a number of tools for the Optimize phase mainly for product design. Typical Six Sigma tools such as design of experiments may be advanced by robust design principles or mixture design concepts. It is however, critical to choose the right tool at the right time. This becomes especially important if Six Sigma is run in conjunction with Lean as sometimes stakeholders can become confused.

Some organizations consider going for Design for Six Sigma right away and not starting with process improvement (DMAIC). This seems attractive: DMAIC always means searching for problems that can be solved – and a lot of organizations (responsible persons?) do not want to admit to having problems.

Nevertheless, there are a number of good reasons for starting with DMAIC even in a creative or engineering environment: Budget-effective financial savings can be reported within a limited time frame, a number of projects can be executed simultaneously and internal success stories can be created, proving that Six Sigma works here!

Different parts of DFSS will straddle conventional software stages, some parts go to analysis, some to design, some to test. I dropped a hint about DFSS kanban in this post:

http://leansoftwareengineering.....nban-team/

I promise I’ll revisit the workflow/kanban topic