Hi

I will be working on a project and have to decided on the best suited
Software Engineering Process. The Project Description is: 15-20
people, HW and SW development, Message Based System, Different CPU
e.g. Intel, C167, PowerPC, DSP, Real time operating system, Working in
different location, Telecom project.

Software Engineering Process that are common are :

Waterfall model
Rapid-Prototyping Model
Operational Mode
Knowledge-Based Mode
V-Mode
Rational Unified Process
IEEE Model


What one is best suited ?

"Gerald Maher" <gerald.maher@waytohere.com> wrote in message
news:d084bb85.0311050021.7cbae0e8@posting.google.c om...
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

Gerald Maher wrote:

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

Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> writes:
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 ?


3. People are able to communicate with each other
4. 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.

Gerald Maher wrote:

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

Everett M. Greene wrote:

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

In article <d084bb85.0311050021.7cbae0e8@posting.google.com >
gerald.maher@waytohere.com "Gerald Maher" writes:

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.

--
************************************************** ******************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
************************************************** ******************

Mike Harding wrote:

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

Mike Harding <mike_harding1@nixspamhotmail.com> wrote:

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

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



gerald.maher@waytohere.com (Gerald Maher) wrote in message news:<d084bb85.0311050021.7cbae0e8@posting.google. com>...

peb@amleth.demon.co.uk ("Paul E. Bennett") writes:

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.

--
Darin Johnson
"Look here. There's a crop circle in my ficus!" -- The Tick

"Bob F." <bobf@phantom.com> writes:

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.

--
Darin Johnson
"Particle Man, Particle Man, doing the things a particle can"

Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> wrote in message
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.

"Gerald Maher" <gerald.maher@waytohere.com> wrote in message
news:d084bb85.0311051120.7ac06e1d@posting.google.c om...
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.

to solve a problem without thinking about it properly first. Engineers
shouldn't do that.

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.

<snip>

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.

Let me zip up my flame suit....there ok much better.

First, you need a domain expert, and the engineers will need to have a very
good understanding of what is trying to be achieved. Second, I suggest you
get QA or someone who's full time job is related to verification and
validation, involved at the beginning. They need to understand the problem
as well as the engineers (how else will they write good tests?).

Demand your engineers to validate their code with unit testing before it
gets released into a build. Don't let everyone dump their stuff into a
single development branch. Reserve a "stable" branch for QA to use, and
only add to it when QA is ready to test new features/fixes.

Don't expect anything great from tools that make UML diagrams. Keep the
paperwork to a minimum, and only document something if after reading it, an
engineer can say "Yeah, that is actually useful for me to know, and it'll
help me in 6 months when I come back to this area of the code".

Get your technical writer involved immediately. They need to underatand the
problem too, otherwise they'll be nagging your engineers later when they're
busy fixing bugs.

The most important thing is to push back as much scope and features as you
possibly can. Don't volunteer to prototype or demo anything unless it's
demanded. I can't stress enough how these activities distract engineers
from getting core functionality completed and tested. Demos tend to need
bells and whistles, and they generate new demands that marketing suddenly
seems to think is a must have for the first release. Stay focused on the
smallest subset of critical functions that you can get away with.

Now here's where I need the flame suit (and I am a developer btw). Every
developer should have the exact same environment. Everyone uses the same
tools, the same build scripts, etc. Get everyone their own dedicated
development box (separate from their R&D and general everyday tasks). Avoid
proprietary methods from the start. There will be a lot of whining over
IDEs and editors. Tell them to shut it and deal with it. Give them x
number of days to decide which tools they need to use, but after that,
everyone does it the same way. If you have to bring new people onto the
project, it will make things much easier to get them up to speed, and they
can get help from any of the team members, not the same guy over and over.

I guess to summarize:

1. Minimize scope
2. Mandate clear understanding of what is trying to be achieved by all
members of the team
3. Begin QA activities on day 1
4. All developers use the same tools/compilers/etc
5. Mandate unit testing before code is released to the QA branch
6. Don't release until it's stable (requires yelling at your boss)