Design method of RTEMS?

Joel Sherrill joel at rtems.org
Wed Aug 7 19:43:47 UTC 2019


On Wed, Aug 7, 2019 at 7:17 AM Sebastian Huber <
sebastian.huber at 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.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190807/16404b6a/attachment-0002.html>


More information about the devel mailing list