What Software Engineering Process is best suited for Embedded Projects

Well I wouldn't _assert_ that it's impossible (hence the question mark) to fully test _all_ real time systems but, certainly, with many larger systems it's next to impossible.

Others have mentioned the huge number of possible pathways etc but if you add to those the asynchronous nature of external real world events both to the currently executing instruction and to each other I fail to see how those can all, sensibly, be tested

Some years ago I had a small project using a PIC with one external interrupt. The PIC had an internal bug which caused it to miss the external interrupt if that interrupt occurred during T2 of a particular instruction. I don't know how that sort of issue could be tested for?

Mike Harding

In any project you need the following requriments:

1. You know the System you are designing
2. Knowledge of CPU used inside out
3. Tools that you can test in real time
4. Before you design the system make sure it can be tested and it will work and the system output will work
5. No point in using UML if the devlopers do not know it
6. Same tools should be used within the project
7. If purchasing 3 party products, make sure they work and you are not the Beta test for product purchased
8. Keep it simple at the start of the project.
9. Not a standard, to many RTOS and To many tools that do not work
10. Managers who can not communicate with people
11. Feed back to devloper and customers

Hi Mike , your term "code cowboys" and "hackers" is great

But i find it hard to belive that Ericsson ( the Bigest telcoms in swedded ) follow no Proces, Is that the same in Sweeden ?

That is like saying Siemens of Germany have no Process, GE and Motorola of USA has no process Nokia of Finland has no process

What do you mean by keeping interface to a minimal ?

What do you mena by device independant test fixture ?

Thanks Gerald

I can not belive this:

Who keeps comeing back ? Can you give me more back ground of what you do because if you work in the car industry projects are under 6 months Add on's or new features to a project Manager have no skills No buget for Process Company is going bankrupt

Then i can understand where you are coming form.

Um. Haven't you just partially defined a process?

There seems to be some confusion here between Process, Model and Methodology. They are being used as thought they were interchangeable terms and they are not.

I'm not going to start a definition war here, but see any SW Engineering textbook for clarification of terms. Cheers TW

All of those companies are HUGE. They have no universal process that applies to all groups in all countries.

Consider that these companies have research divisions separate from product creation divisions, departments acquired through buying out smaller companies and startups, internal political rivalries, etc.

Yes i know in every sheep field there are always one or 2 black sheeps

... snip ...

No, there are usually one or two sheep, one side of which we know to be black :-).

A process contain Methods, for example there when you devlope one component you could this a process, a method is this case is the requriments, interface, codeing and testing

Another example of a process is when you deliver to customer a example of methods are Verifaction reports, Feature passed as stated in the Requriments e.t.c

Dude, you'll get much more respect and credibility if you could spell

Not only do you top post and seem unable to construct a sentence using the correct tenses AND you're rude to boot but...

Gerald is posting from an Amsterdam server (that's in The Netherlands btw) so his first language is probably Dutch therefore he's writing in a second language which he does very well and, I suspect, a bloody site better than you could write in Dutch or any other language. In addition I'll bet Gerald speaks at least one other language too? How many do you speak?

The parochialism of some Americans never ceases to amaze me!

Mike Harding

I taught my Real-Time Fundamentals course in Amsterdam last year and the people who brought me over there from my home in Canada were great. They all spoke English fluently, which made my job a whole lot easier since I don't speak a word of Dutch. All the merchants I dealt with also spoke English.

As an instructor and former manager of software developers I've had to work with people from all cultures with varying levels of command of the English language. Spelling and grammar mistakes are the norm but you just look beyond that because they're doing a heck of a lot better communicating with me in English than I could communicate with them in their native language. Besides, I'm no English major myself.

Although I definitely know the difference between their, there and they're, I still make slipups, and I get mad at myself, but I hope nobody shoots me for it. :-)

I do ask that people taking my course notify me of even the smallest typo in the material because I find my own errors especially annoying.

...Tom

Keep to the subject

However, the example given was a prototype for demo purposes; in that case, the appropriate thing to do would be to waive QA. If the finished product is intended for safety-critical jobs, then of course run it through formal QA (_as well as_, not _instead of_ making sure the programmers know what they're doing) before putting it into actual service.

No, the correct thing to do with anything that's not been through QA is to throw it away. Go and build a proper one to a proper process if it's anything other than a toy.

You can't retrofit quality.

pete

As usual many people seem to think that having a proces guarantees quality. it doesn't. As I said right at the beginning of this thread the team of people and the culture in which they operate is far more important. No matter how good the process, garbage in, garbage out still applies.

Ian

That may well be; but with a good quality system you'll, at least, have excellent documentation :)

Mike Harding

Excellent documentation for a perhaps a poor implementation. But at least it makes a starting point for making it right.

Doug

quality.