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