<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 7, 2019 at 7:17 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I am currently busy working through the ECSS standard documents (that is real fun work). They want to know what design method was used to develop the software product (RTEMS in our case). Do you have an idea what the design method was to develop RTEMS? What about Extreme Programming although it was invented after the original RTEMS development?<br>
<br>
<a href="http://www.itinfo.am/eng/software-development-methodologies/#chapter5" rel="noreferrer" target="_blank">http://www.itinfo.am/eng/software-development-methodologies/#chapter5</a></blockquote><div><br></div><div>I wanted the cobwebs to clear before answering.</div><div><br></div><div>In retrospect, the development did look more like Extreme Programming or Test Driven Development.</div><div><br></div><div>We used a spiral methodology. Thankfully it was introduced in 1986 so I can be confident</div><div>that I am not projecting. [Note: I met Boehm once years ago.]</div><div><br></div><div><a href="https://en.wikipedia.org/wiki/Spiral_model">https://en.wikipedia.org/wiki/Spiral_model</a> <br></div><div><br></div><div>The way we implement Spiral it is more or less an agile approach. Each spiral just h as</div><div>a well defined goal. The development tasks/schedule are geared to that goal. I like to</div><div>think of Spiral is Agile with well-defined points on the trail. Some agile projects get</div><div>hung up on sprints and burn down lists and forget to ensure that all of the steps are</div><div>actually headed in the right direction.</div><div><br></div><div>Each increment of work in the original Army funded effort had a clearly defined goal</div><div>and funding for each step was always less than a year. That would make a big goal</div><div>but there might be multiple spirals defined within that "funding line". We had to have</div><div>deliverables which met the contract requirements but there was a serious focus</div><div>on "always working" and potential incremental release points.</div><div><br></div><div>Tests were written along the way and regression testing was critical. As a feature </div><div>was added or something was optimized, the test base had to pass. Just like now, </div><div>if you break a test with a change, you either fix your change or justify the test needs to change.</div><div><br></div><div>There were agile traits to this because we did adapt plans when a new version</div><div>or RTEID or ORKID dropped. You have to remember that we did that initial POSIX<br>thread support was added to host GNU Ada applications. But they didn't have </div><div>Ada tasking yet. So there was "agility" in responding to their evolving set of</div><div>methods needed.</div><div><br></div><div>But the terms agile, XP, and TDD didn't exist yet. Back then, it was simply</div><div>a matter of having spirals defined with realistic goals and being flexible enough</div><div>to change the next spiral if something changed.</div><div><br></div><div>I'm a bit cynical about these terms because really you are just wanting to meet</div><div>the customer needs in the best possible manner. If the world or their desires</div><div>change along the way, you should adapt to that. Using regression tests, small</div><div>well-defined steps, etc. is just smart project management. No matter what you </div><div>call it.</div><div><br></div><div>If I need to dig out the RTEMS history box to answer questions, I can. But hopefully</div><div>I still have the living brain cells required to answer them. :)</div><div><br></div><div>--joel</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : +49 89 189 47 41-16<br>
Fax : +49 89 189 47 41-09<br>
E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>