What Software Engineering Process is best suited for Embedded Projects

It was said tongue in cheek of course but probably what I should have said was "conforming documentation" which is no guarantee of excellence.

Mike Harding

Reply to
Mike Harding
Loading thread data ...

If features are mostly independent, you may be able to reduce the number of testcases (or increase the guaranteed coverage) by testing many pairs simultaneously. For example, 19 on/off features. 2^^19 combinations, 171 pairs of features. But you can cover all 171 pairs with 10 testcases, like so:

1a 2b 3a 4b 5b 6a 7a 8a 9a 10a 11a 12a 13b 14a 15b 16b 17a 18a 19a 1b 2a 3b 4a 5a 6b 7b 8b 9b 10b 11b 12b 13a 14b 15a 16a 17b 18b 19b 1a 2a 3a 4b 5a 6a 7b 8a 9b 10a 11a 12a 13a 14b 15a 16b 17b 18a 19b 1b 2b 3b 4a 5b 6b 7a 8b 9a 10b 11b 12b 13b 14a 15b 16a 17a 18a 19a 1a 2a 3a 4a 5b 6a 7a 8b 9a 10b 11a 12a 13a 14b 15a 16a 17a 18b 19a 1a 2b 3b 4b 5a 6b 7b 8a 9b 10a 11b 12b 13b 14a 15b 16b 17a 18b 19b 1b 2b 3a 4a 5b 6b 7a 8a 9a 10b 11a 12b 13a 14a 15a 16b 17b 18b 19b 1b 2a 3b 4b 5a 6a 7b 8b 9a 10a 11b 12a 13b 14b 15b 16a 17b 18a 19a 1a 2a 3b 4b 5a 6b 7a 8a 9b 10b 11a 12a 13b 14a 15a 16a 17a 18a 19a 1a 2b 3a 4a 5b 6a 7b 8b 9b 10a 11b 12b 13a 14b 15b 16b 17b 18b 19a

The number of testcases grows with the log of the number of independent features. There are tools for generating such sets of testcases. (I just wrote one,

formatting link
I have a hammer. I've been looking for nails.)

Reply to
Bob Jenkins

Can you define independent in this context?

Ian

Reply to
Ian Bell

Yes, but I am not interested in well documented garbage.

Ian

Reply to
Ian Bell

Except that is treating the symptoms not the disease.

Ian

Reply to
Ian Bell

Well, copious documentation, anyway.

--
Trevor Barton
Reply to
Trevor Barton

That may be so, and I agree that its a mistaken belief. However, without a process you don't even have a way of measuring quality.

TW

Reply to
Ted Wood

I agree and I do not think I ever said there should not be a process. However, the second great quality myth is that one process suits all situations.

Ian

Reply to
Ian Bell

As with US DoD projects documented to MIL-STD requirements?

Reply to
Everett M. Greene

Yes: If a testcase is expected to test many separate pairs of features, then all of the features in it must be exercised.

Two ways for some features not to be exercised are errors and comments. If an error is raised, it may be raised before some features are hit, so any pairs involving unhit features aren't tested. For example syntax errors in SQL will prevent any data access from being tested. A comment, something like the or commands in HTML, will cause most inner commands to be ignored, so any pairs involving inner commands won't be tested.

The tools AETG and jenny allow lists of restrictions, that is, features that should not appear together in any testcase. That allows a set of testcases to be generated that will avoid those feature combinations that are known to raise errors or otherwise cause trouble. A couple dozen restrictions aren't bad, but zillions would be awkward to handle. Thus, "mostly" independent. Any restrictions need to be tested separately. The tools can cover triples as well as pairs, but pairs seem to be what people actually shoot for. ALLPAIRS is another such tool, but it doesn't handle restrictions, and it only covers pairs.

Reply to
Bob Jenkins

As an aside; whilst this thread has been in progress and I have been arguing that quality systems are very overrated I have discovered that a (electronic) product I own whose sole function is that of life saving in dire situations and is designed and manufactured by a company who proudly proclaim ISO9002 and a TQM Programme, and said product has been in production for at least five years, has a major design flaw which could easily render it useless on that single occasion it may be required to perform it's task. Looks like a quality system didn't work in this case. I'll provide full details at a later date.

Mike Harding

Reply to
Mike Harding

I am not in the least surprised. one of the things we used to do was a design audit for other companies, mainly when they were having problems with a product. Because any effect can have a large number of causes is was piintless to postulate causes from known effects. So we created a set of basic good design and engineering judgement criteria and measured the design against them. This allowed us to identify design weaknesses. We found a very high correlation between these and observed faults i.e if the design weaknesses were addressed the faults were fixed.

The reason I say this is that many of the products we examined were developed in companies with full blown QA systems and they had just as many occurences of design weaknesses as those developed elsewhere. Which leads me to the quality myth #3 which is that is eleimnates design errors and/or promotes good design.

Ian

Reply to
Ian Bell

For some industries there is a web-site where such anomolies are reported and recorded. The Chemical Industry is one such. Perhaps there should be similar for other industries. I will try and dig up a link or two.

To add to your myths list #4 could be "the level of quality is proportional to the thickness of the QA manual". This myth I know is a falsehood from personal experience. Mainly, with very large QA manuals no-one can be bothered to read them.

By far the best way of ensuring quality and integrity of your final product is to conduct decent technical reviews at regular intervals. Usually this will be the completion of a stage of development for the design, or the production of a component. Any reasonably complex product will have undergone several thousand reviews by the time it is released to the market.

Technical Reviews do not have to occupy innordinate amounts of time. They can be as brief as 5 minutes or up to 2 hours (they should not be longer than this - if they are you are dealing with something that is more complex than you should be reviewing at one time).

Keep the process simple (so that everyone can remember it) and apply it at all times. To answer the question about whether or not one process can be applied to all situations; yes it can so long as it is a simple process that has an affinity with the hierarchy of the projects you are dealing with and can be simply managed while leaving a good audit trail.

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

How can you demand the Engineers to validate there code ? Is there not another way such as Scipt interface ? or ?

Reply to
Gerald Maher

Yeah, there IS a way to get perfect, known-good code at the push of a button, with no apparent human intervention. Actually, two ways:

  1. Time travel.
  2. Magic.

If you don't have access to either of these technologies, I suggest you persuade your "engineers" to get involved in code validation.

Reply to
Lewin A.R.W. Edwards

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.