This is great point you have brought out. I worked on the industrial safety system products following IEC 61508 and that standard also says the same thing. The independent assessor & approver TUV told us the same...the person writing the code shall not test. Also, the person writing the test plan shall not execute the test. I am from the electronics circuit design & FPGA back ground. My difficulty in understanding Agile is, in electronics design we cannot so incremental developments like it says in Agile....completing backlogs in sprints lasting for only two-three weeks and can't demonstrate a working product to the customers. Hardware development for safety critical system would be even tougher to execute (or won't make any sense) in this way.
I'm not at all sure that "spiral VS. agile" is the right way to frame the debate, considering how disparate the two approaches are, and I doubt whether many of us who have done heavily safety-critical projects ever get close enough to "agile" to know it very well at all. Nonetheless I could offer one comment, one of the "pluses" that's been touted for agile is that the code developer does the unit testing himself because he's the "best qualified" to understand the routine he's trying to code. This used to be common too in the older military coding standards like MIL-STD-1679 (I think that's the #, been awhile) but this is in direct contradiction to the premise of something like DO-178C where the notion is you specifically need different people writing the tests so you get "separation of responsibility" and the testing MUST be done by different people, so the critical part of writing the test code MUST be done "through a different pair of eyes". It kind of seems like in this example the advocates of agile don't even have the correct mindset to address the critical issues, and I would submit that if you took a closer look this type of "critical discrepancy" would likely be found throughout the process. I believe the two approaches at best (as currently defined at least) are barely compatible but I'd be willing to listen to an argument to the contrary.
This is a good topic and there could be a constructive and fruitful debate on it. I have worked on several safety projects and mostly functional safety per IEC 61508. A few years back, nobody questioned the process and it followed kind of spiral model or iterative waterfall or what ever you call it as. We spent several months in doing the FMEAs to understand the failure modes well, before starting the real development work. There were many reviews, especially by independent assessor. The project took almost double the time compared to if it were a normal project. Now a days with the popularity of Agile development, management perspective has got changed. Recently we were asked to think about executing a safety project with Agile development rigor...we could not figure out how it benefits...the project eventually did not get management focus, may be due to other reasons too. But I am not seeing any safety project being executed following Agile development.
Even if it is not a safety critical product, did somebody apply Agile development to hardware development successfully?
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.