What Software Engineering Process is best suited for Embedded Projects

The waterfall model is, IMHO, not realistic. I also think that Rapid-Prototyping and engineering do not mix. I also steer clear of anything that starts with the word "Rational", especially if it involves UML. I have no comment on the others.

Whatever process you choose, in my opinion the two most important things to do are:

1. Make sure that the project is divided into a number of sub-components, each of which has a *minimal* and *carefully defined* interface with the other sub-components.
2. Build and maintain an automated test suite, and test everything as you go. The test suite should be a deliverable.

Of course, you are free to disagree vehemently with my opinions. :-)

Tanya

None of them. The most important thing about a project of this size is the TEAM of PEOPLE. You need to ensure a culture which promotes team work, values and empowers people. Without this, none of the above methods will do you any good.

Ian

And it doesn't make any difference how good the people are if there isn't a clear understanding of the goal(s) of the project. ["We're making very good time but we don't know where we're going!"]

Hi Tanya

Just some questions and points to add to your comment

Why is waterfall waterfall model unrealistic. ?

What do you mean by Rapid-Prototyping and engineering dont't mix ?

What is wrong with Rational ?

Aggress 100% but i would add 2 points to that

1. People are able to communicate with each other
2. Software chages and new feature are allowed during the project

Hi Ian You still need some sort of guidlines , no matter how good the people can get along, just because you have a good enviroment that does not mean you will delivery on time!

Every company that i have worked for so far have a guidline on how Software Engineering Process works, are you saying you are working for companied who do not use any Software Engineering Process ?

As i described in my opening thread A peoject with 15-20, working in different locations here you need a CVS or RCS or clearcase or SourceSafe this is a process with in Software Engineering. OK if you are a student don't answer.

On the contrary, the very lack of rules gives the flexibility necessary to deliver on time.

Absolutely. Not only that, we have no formal quality system and yet people come to us just because we can deliver high quality results faster than anyone else. And this applies to all disiplines, not just software.

Ian

Good people, of course, first make sure they understand the goals. More importantly they make sure the customer understands the goals, what will be delivered and what will not be delivered.

Ian

Ian

I have some sympathy with this argument. In my experience quality assurance systems are excellent at assuring all your documentation etc conforms but, usually, have little impact upon product quality.

Mike Harding

The model does not really matter. So long as you have a clear idea of what you require as deliverables at each stage of development and have recorded the process you use (simple ISO9001 requirement often stated as "write what you do and do what you write").

Secondly, ensure that you have a secure repository for the project documentation and that you make someone responsible for keeping it in order. A CVS or RCS system will help electronically if you wish to go that route.

Thirdly, have a system by which problems get reported and then proven to be fixed before it ships (no more than one problem per report or it becomes a nightmare very rapidly). Change management is very important and you need to impose that no-one makes a change to production code unless they have a written work instruction to do so. Combined with this, of course, is regular technical review, run properly and given a level of status that management and marketing cannot overrule the outcome of the review reccommendations.

Finally, subscribe to Jack Ganssle's newsletter "The Embedded Muse" which contains a lot of useful stuff. Even Jack's books would be useful I think. If you visit Jack's web-site I think you will find a lot of the back-issues of the newsletter. No. 85 was quite a good one. Of course, keep asking questions in here and if you need some help with formulating your procedures I have some templates that can give you a good start.

Exactly. One client's senior management had decided a new prototype would be shown at a particular exhibition three months hence. Their quality system would not permit them to complete any project is such a short timeframe.

Ian

Amen to that. You can make a case that the quality assurance system is necessary, but it is not sufficient.

faster

Posted like true "programmers". I hope that none of you guys are designing software for life critical systems in space or control software for nuclear power plants. As long as you are designing web sites and shopping carts, lack of a formal quality system is fine. As soon as it becomes control software upon which expensive equipment or human lives rely, then you see the demand for quality control in software development.

I'll give you two examples from past experience, both from the telecom industry. One was being part of a team of around 15-20 people in Motorola. It was further subdivided into a "platform" team, application team, validation team, and network management team. 4-5 people worked on hardware, 4-5 people worked in validation, 2 on network management stuff, and up to 8 on telephony apps. It followed the V-model, where, after the requirements were written, then the validation team worked on a test plan to test each requirement, while the developers continued on with architecture and coding. THIS WAS THE MOST STABLE PRODUCT I'VE EVER SEEN.

Now fast forward to my days in Ericsson at Menlo Park, CA. It seemed to follow NO process, and at best, it was best approximated to Extreme Programming. There were several small builds, with each subsequent build creating more bugs. This project took two years to stabilize. (Is it stable now? who knows). Quality sucked, the validation team had no requirements to work with, so all they did was load the system with calls. The product was unstable so much that companies didn't buy that telephony system, and chose Cisco's or Avaya's instead. This led to the inevitable closure of that branch and it was moved to Ericsson's headquarters in Europe. I'm sure Ericsson is a disciplined company. Many big companies are disciplined, except for when they buy startups whose half-cooked source code was written by code cowboys and hackers.

I agree with the earlier reply that the waterfall model is not real and just seen in textbooks. I worked with the V-model, and I trust the resultant quality from such a process discipline.

-Mike

But make sure the documentation gets updated properly. Making the updates a chore to do ensures that it won't get done. If the person in charge of the documentation doesn't have much day to day interaction with the people doing the actual work, things will get out of sync. If there's an approvals process for updating the docs, then the updates will either be late or not get done.

It is not uncommon for upper management to feel that everything is documented properly and accurately only to find out later that nothing matches.

Also realize that the end result of all this may be that you can quickly and accurately figure out where things went wrong, but it might not help you prevent things from going wrong in the first place. Amazing and spectacular failures are usually created with a well thought out process and are nearly always well documented.

After integration occurs the person that fixed the bug should again sign off on the ready-to-ship code. If the person reporting the bug is in-house, they should sign off on it too. It's much too common an error to have the modules work perfectly but then fail mysteriously when integrated together.

There should be a real traffic cop that has control over what gets into a release and what doesn't. Feature creep and endless last minute bug fixes can ruin a well planned project; yet this is a regular occurance. This traffic cop should have veto power even over more senior people or the marketting department. At one company I was at this position rotated with each release, so that the same person wasn't always the most hated person in R&D.

I worked for a medical diagnosis device company, and there was a lot of quality control and processes. Things were _still_ buggy, and management _still_ put on the pressure to cram more into a release than should fit. Though the creeping feature pressure was at the front end of the release rather than at the last minute.

No matter how good or dedicated engineers are it is essential that the team agree on a set of guidelines or policies to drive the software process. If the team is good the guidelines and policies will be adjusted accordingly for the situation. It goes without saying.

The waterfall model assumes several distinct stages: requirements gathering, requirements analysis, high level design, detailed design, coding, etc..., each leading on to the next. In the real world, customers change requirements right through the project, even during coding.

From what I have seen, rapid prototyping seems to be a fancy name for trying to solve a problem without thinking about it properly first. Engineers shouldn't do that.

I hate tools that automatically generate code from high level design, and I associate these with Rational. Basically, they are great time wasters that don't work. Further, they deprive engineers of the pleasure of exercising their creativity, with the result that they lose pride and interest in the project. As for UML, the last time I looked at it I couldn't see a simple, obvious way to clearly represent the key elements in a real time design. Things like tasks, interrupt service routines, critical timing requirements, semaphores, FIFOs, messages, blocking with or without timeout, etc.

See my comments on the waterfall model, above.

Tanya

Hi Bob

How are the process implemented in a Nuclear plant or medical equipment ,well I know in Germany there is a tiff that will certify the software. Did you use the following general process e.g.

Stage 1 Requirements Stage 2 Specification Stage 3 Design Stage 4 Implication Stage 5 Test

Agree with you 100% you go some smart guy or girle who promise the customer something that they will delivery that is unrealistic in the time frame. In that case one just wants it to work a little bit.