Software Development Life Cycles

Software Development Life Cycles

Post by Not M » Mon, 08 Oct 2001 20:20:30



Anyone know any guidelines available on the web for choosing a life cycle
model? I'm particularly interested in whether or not the waterfall is best
for safety-critical embedded systems.
 
 
 

Software Development Life Cycles

Post by Sara Have » Wed, 10 Oct 2001 08:22:39


From what I've been reading, the traditional, waterfall lifecycle works best
when detailed requirements prior to design is fact vs. fiction and when you
can accurately predict the end result of the system prior to coding.
Traditional lifecycles depend on minimal change of each previous phase of
the cycle.  Once the requirements are documented, reviewed and approved,
that's it.  Once coding is complete and turned over for testing, any
variance from the approved design becomes a bug.  This lifecycle applies
when the quality of the product drives the implementation date.

If the requirements aren't nailed down and you're not exactly sure how the
system will look once fully constructed, you're better off going with an
iterative approach.  If you do a search on 'Agile Testing' or 'SCRUM' or
'Rational Unified Approach' you'll get the idea of what the new breed of
lifecycle is all about.  The focus is on integrated development teams of
testers, developers and users who's mantra is 'Test early, test often.'
There is more interaction with the product than documentation.  This
lifecycle is flexible and fast to support time to market drivers.  Quality
is not sacrificed but deferred.  Anamolies are prioritized and implemented
in daily or weekly builds of the applicaiton or system.

This is just a summary of two approaches.  I'm hoping it will either help
you arrive at a decision or lead you to some expert advice.

Sara


Quote:> Anyone know any guidelines available on the web for choosing a life cycle
> model? I'm particularly interested in whether or not the waterfall is best
> for safety-critical embedded systems.


 
 
 

Software Development Life Cycles

Post by Vladimir Trushki » Wed, 10 Oct 2001 16:43:36



...

Quote:>  Quality is not sacrificed but deferred.

Sorry I can't get that. How can it be? Deferred implies sometime it will be
fixed but when? After user starts complaining on it? I think this is too
late.
 
 
 

Software Development Life Cycles

Post by Russell Walla » Wed, 10 Oct 2001 21:23:16


On Tue, 9 Oct 2001 10:43:36 +0300, "Vladimir Trushkin"




>...
>>  Quality is not sacrificed but deferred.

>Sorry I can't get that. How can it be? Deferred implies sometime it will be
>fixed but when? After user starts complaining on it? I think this is too
>late.

Well, the point is that for most projects, you're not going to get the
same level of reliability as is required for safety-critical embedded
software, simply because the customer isn't going to be willing to pay
for that. On the other hand, they probably are going to request lots
of additional features long after the initial specs were drawn up. You
go for the best quality you can achieve under these constraints. It's
about giving the customer what they want.

--
"How many roads must a man walk down?"

http://www.esatclear.ie/~rwallace

 
 
 

Software Development Life Cycles

Post by Kalynnda Bere » Wed, 10 Oct 2001 22:03:13



>On Tue, 9 Oct 2001 10:43:36 +0300, "Vladimir Trushkin"



>>...
>>>  Quality is not sacrificed but deferred.

>>Sorry I can't get that. How can it be? Deferred implies sometime it will be
>>fixed but when? After user starts complaining on it? I think this is too
>>late.

>Well, the point is that for most projects, you're not going to get the
>same level of reliability as is required for safety-critical embedded
>software, simply because the customer isn't going to be willing to pay
>for that. On the other hand, they probably are going to request lots
>of additional features long after the initial specs were drawn up. You
>go for the best quality you can achieve under these constraints. It's
>about giving the customer what they want.

>--
>"How many roads must a man walk down?"


Yes, but the original poster asked about SAFETY-CRITICAL systems.  So,
reliability, quality, safety, etc. are not something that can be DEFERRED!  
Yes, I'm shouting a bit.

XP, SCRUM, and the other agile processes are not for everything.  So please,
do not recommend them for safety-critical development.  I might be driving
that car, flying through that airport, or using that new computer-controlled
laser surgery device.  I'd rather they were developed much more formally, so
that my confidence in them would be higher.

To the original poster:

As far as other non-agile lifecycles, consider the spiral, incremental
development, or evolutionary lifecycles.  They are all "heavyweight" (as
opposed to the lightweight or agile processes), but are also more flexible
than the waterfall.  Incremental development is not new to the agile
processes, nor is responding to changing requirements.  But in a
safety-critical application, the majority of the requirements should be nailed
down early!    

Depending on the venue of the safety-critical application, you may have
limited lifecycle choices.  Look at any imposed standards you must meet.  If
no standards define the lifecycles you can choose, consider what other
products in your venue are using.  Do you need to create a safety-case?  If
so, are there any lifecycles that will make your job easier (or more
difficult)?  If you are in the DOD, FAA, automotive, or other area, you may
well have defined lifecycle choices - and choosing one outside of that list
may be difficult.  If you work for/with NASA, email me and we'll talk.


 
 
 

Software Development Life Cycles

Post by Not M » Wed, 10 Oct 2001 23:14:05





> > Anyone know any guidelines available on the web for choosing a life
cycle
> > model? I'm particularly interested in whether or not the waterfall is
best
> > for safety-critical embedded systems.

> My first question would be what type of "safety-critical embedded
> system", and whether these are subject to regulatory approvals that
> might already impose or restrict the choice of development
> methodology?

I work mainly in the military & aerospace field. Civillian aeronautical
application are much more tightly regulated when it comes to safety. The UK
MOD lays down lots of rules but doesn't really enforce them. Both civillian
& military applications often include displays eg instrumentation panell for
pilots, displays of information for users of systems & terminals for input
of information. One project I worked on used the waterfall life cycle for
developing the guts of the system, but had a simuilation of the displays
which users were encouraged to constantly play with and change, while the
design, coding & testing of the rest of the system took place, My personal
feeling is that the exact form in which data is to be displayed need not be
fixed at the requirements stage, but the content should be.
 
 
 

Software Development Life Cycles

Post by Not M » Wed, 10 Oct 2001 23:48:47




says...

> As far as other non-agile lifecycles, consider the spiral, incremental
> development, or evolutionary lifecycles.  They are all "heavyweight" (as
> opposed to the lightweight or agile processes), but are also more flexible
> than the waterfall.  Incremental development is not new to the agile
> processes, nor is responding to changing requirements.  But in a
> safety-critical application, the majority of the requirements should be
nailed
> down early!

> Depending on the venue of the safety-critical application, you may have
> limited lifecycle choices.  Look at any imposed standards you must meet.
If
> no standards define the lifecycles you can choose, consider what other
> products in your venue are using.  Do you need to create a safety-case?
If
> so, are there any lifecycles that will make your job easier (or more
> difficult

I don't know what you mean by a "safety-case", but your suggestions on life
cycles models was very helpful. Thank you.
 
 
 

Software Development Life Cycles

Post by David Gillo » Thu, 11 Oct 2001 01:45:59



> I work mainly in the military & aerospace field. Civillian aeronautical
> application are much more tightly regulated when it comes to safety. The UK
> MOD lays down lots of rules but doesn't really enforce them.

'Enforcing' the 'rules' is the responsibility of your QA department.
Your quality plan should define your processes in accordance with the
standards you are required to work to. Your QA representatives should
monitor your compliance with them via the audits defined within the plan
and auditors from MOD/DERA/QinetiQ should monitor their performance of
those audits.

My experience of the relative rigour of military and civilian aerospace
safety critical work is that there is no practical difference.

Quote:> Both civillian
> & military applications often include displays eg instrumentation panell for
> pilots, displays of information for users of systems & terminals for input
> of information.

Displays are rarely safety critical (I'm aware of one exception),
they're more generally mission critical in my experience, which leads to
less rigorous development standards (though still incredibly rigorous by
the standards of the software industry in general).

--

David Gillon

 
 
 

Software Development Life Cycles

Post by JRSte » Thu, 11 Oct 2001 07:49:17




Quote:>Anyone know any guidelines available on the web for choosing a life cycle
>model? I'm particularly interested in whether or not the waterfall is best
>for safety-critical embedded systems.

I only know of one life-cycle model.

Waterfall and cyclical are development paradigms.

I don't know of anything specific to safety regarding them in either
case, sorry.

J.

 
 
 

Software Development Life Cycles

Post by Vladimir Trushki » Thu, 11 Oct 2001 16:52:50



> On Tue, 9 Oct 2001 10:43:36 +0300, "Vladimir Trushkin"



> >...
> >>  Quality is not sacrificed but deferred.

> >Sorry I can't get that. How can it be? Deferred implies sometime it will
be
> >fixed but when? After user starts complaining on it? I think this is too
> >late.

> Well, the point is that for most projects, you're not going to get the
> same level of reliability as is required for safety-critical embedded
> software, simply because the customer isn't going to be willing to pay
> for that. On the other hand, they probably are going to request lots
> of additional features long after the initial specs were drawn up. You
> go for the best quality you can achieve under these constraints. It's
> about giving the customer what they want.

Yes I know there are always trade-offs. But...

In order to prioritise issues you must find them first. Cutting off testing
resources and test a bit here and a little there is not right method to
achieve or at least to getting closed to this goal. So I am still quite
sceptical about the reliability of new agile methods paying not enough
professional attention to testing. Some even can't publish field studies
despite of being used for years!

Best Wishes,
Vladimir

 
 
 

Software Development Life Cycles

Post by Andrew Gab » Thu, 11 Oct 2001 23:24:08





> > Anyone know any guidelines available on the web for choosing a life cycle
> > model? I'm particularly interested in whether or not the waterfall is best
> > for safety-critical embedded systems.

> My first question would be what type of "safety-critical embedded
> system", and whether these are subject to regulatory approvals that
> might already impose or restrict the choice of development
> methodology?

In my experience it is rare for regulatory authorities or the
standards they may mandate to restrict the development methodology,
and common for developers to believe that they do. What is true that
the level of discipline required may make some of the more, er,
'flexible' methods highly inefficient. This tends to make the
waterfall model or slow iteration (3-6 month blocks) more cost
effective. Note also that the classical spiral model starts with
prototyping cycles and ends with one or more waterfalls.


> I don't know what you mean by a "safety-case", but your suggestions on life
> cycles models was very helpful. Thank you.

You may like to look at
http://www.dsto.defence.gov.au/esrl/itd/safety/

This standard (AusDoD) takes a pragmatic view of safety and
concentrates on the safety goals (described in the Safety Case -
like a business case). How you meet these goals is more or less your
own affair, but you need to be able to show that you have.

What this standard recognises is that there are different
methodologies, different techologies and different levels of
criticality, so that the approach will vary with a number of
different factors. Some previous standards have been so prescriptive
that they have virtually made any software do difficult and
expensive to write that they have effectively been ignored (rather
than use a Turing Machine).

Andrew
--
Andrew Gabb
[Canb:1-9 Oct, Syd:10-12 Oct, Canb:02 626-51010, AH:02 6297-5531]

phone: +61 8 8342-1021, fax: +61 8 8269-3280
-----

 
 
 

Software Development Life Cycles

Post by Russell Walla » Fri, 12 Oct 2001 06:09:11




>Yes, but the original poster asked about SAFETY-CRITICAL systems.  So,
>reliability, quality, safety, etc. are not something that can be DEFERRED!  
>Yes, I'm shouting a bit.

>XP, SCRUM, and the other agile processes are not for everything.  So please,
>do not recommend them for safety-critical development.

Yes, of course. I wasn't recommending them for safety-critical work;
sorry if that wasn't clear.

Quote:>I might be driving
>that car, flying through that airport, or using that new computer-controlled
>laser surgery device.  I'd rather they were developed much more formally, so
>that my confidence in them would be higher.

Me too :)

--
"How many roads must a man walk down?"

http://www.esatclear.ie/~rwallace

 
 
 

Software Development Life Cycles

Post by Deepa Ahluwal » Sat, 13 Oct 2001 18:50:17


You can checkout the following article:

http://www.eventhelix.com/RealtimeMantra/DesigningRealtimeSoftware.htm

We have found that waterfall used incrementally works fairly well in embedded
system development. In this approach, the whole project is divided into
sub-releases and each sub-release runs its own waterfall.

Deepa
---
www.EventHelix.com - Realtime & Embedded System Resources

 
 
 

Software Development Life Cycles

Post by Not M » Sun, 14 Oct 2001 20:54:35




> > I work mainly in the military & aerospace field. Civillian aeronautical
> > application are much more tightly regulated when it comes to safety. The
UK
> > MOD lays down lots of rules but doesn't really enforce them.

> 'Enforcing' the 'rules' is the responsibility of your QA department.
> Your quality plan should define your processes in accordance with the
> standards you are required to work to. Your QA representatives should
> monitor your compliance with them via the audits defined within the plan
> and auditors from MOD/DERA/QinetiQ should monitor their performance of
> those audits.

Internal QA regualrly gets *led upon by project management in commercial
organisations..QA say 'you must do this' & project management say 'there
isn't the money in the budget' or 'if we do that we won't meet our delivery
date', so of course they always win the argument.  However, I've been on a
project where Airbus Industrie carried out an audit, and the management felt
it was incredibly rigerous. Therefore, the management were very careful to
ensure that procedures were properly followed. At least one QA guy I knew
put the deteriorating QA standards on MOD contracts down to the fact that
the MOD no longer carries out its own quality audits of contractors, because
their wages are so low they can't get the staff.

Quote:

> My experience of the relative rigour of military and civilian aerospace
> safety critical work is that there is no practical difference.

> > Both civillian
> > & military applications often include displays eg instrumentation panell
for
> > pilots, displays of information for users of systems & terminals for
input
> > of information.

> Displays are rarely safety critical (I'm aware of one exception),
> they're more generally mission critical in my experience, which leads to
> less rigorous development standards (though still incredibly rigorous by
> the standards of the software industry in general).

Yikes! What about altitude display for aircraft? Get that wrong & you could
fly into the side of a mountain. What about correctly displaying the
distance to enemy troop concentrations? If that's not correct the artillery
could end up firing on your own troops or innocent civillians. If I put my
mind to it I'm sure I could think of lots of examples.
 
 
 

Software Development Life Cycles

Post by Robert C. Mart » Tue, 16 Oct 2001 06:32:19




Quote:>Anyone know any guidelines available on the web for choosing a life cycle
>model? I'm particularly interested in whether or not the waterfall is best
>for safety-critical embedded systems.

Waterfall is not the best, under any circumstances.  There are cases
where waterfall can work well; but there is always a better choice.

I suggest you take a look at www.agilealliance.org, and then at
www.controlchaos.com, and www.extremeprogramming.org.  They may give
you some advice regarding the choice of a lifecycle.

Robert C. Martin    | "Uncle Bob"              | Software Consultants

PO Box 5757         | Tel: (800) 338-6716      | your projects done.
565 Lakeview Pkwy   | Fax: (847) 573-1658      | www.objectmentor.com
Suite 135           |                          | www.XProgramming.com
Vernon Hills, IL,   | Training and Mentoring   | www.junit.org
60061               | OO, XP, Java, C++, Python|

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

 
 
 

1. Definitions for Life, Shelf-life,life-cycle,...

We are currently working on a glossary for safety, quality, reliabilty and
maintainability for software for the intelligent transportation systems.

Please advise of definitions supported by the majority of your societal
disciplines in software, provide sources (e.g. IEEE, ISO, etc.) if
possible.

Life Cycle

Shelf Life

Transition

Retirement

Service LIfe

Life Span

I realize some of these are "stretching" the current hardware based
technical terms to fit (poorly) over software and software based systems,
but if they exist we are bound to consider honoring them.  Therefore if
you can provide a source then those terms will be better considered.

Thank you for your help...

--
        eine Flucht nach Vorn machen = make a retreat forward
 Truth arises from disagreement amongst friends (D. Hume (Scotland))
 Loved and Missed, so Work Together and Rejoice, Phillipians 4:1-13
 Archibald McKinlay, VI   McKinlay & Associates    St Louis, MO, USA

                       Definitely my own opinions
       Software can kill you...or at least what it controls can

2. Help with centralized mail hub problem

3. Software Dev. Life Cycle & Usability

4. Are there any MDL programming books?

5. software life cycle model

6. StarFighter

7. Software life cycle metrics

8. Sending to a domain via one relay only

9. Software life cycle - TBOOM

10. Software Dev. Life Cycle & Usability

11. Software Life Cycle Distribution

12. Announcing The Agile Life - a free ezine on the human side of software development

13. Life cycle of UNIFACE