Re: Version Control in Embedded Systems

I disagree - "making best use of the language" is not a factor. Writing reliable code often involves using a *subset* of the language. This is especially true of C++, which is poorly suited to embedded work and has many constructs that simply have no place in embedded work.

Again I disagree. I write object-oriented C (and assembler) all the time. Design is separate from coding - except with languages like C++ where the distinction is blurred. (Is this a good thing? Discuss ;).)

Steve

true

I repeat that field-upgrading is *not* always appropriate for embedded products. (See my earlier post.)

In many cases a better use of available cash is to get the code right in the first place. A bug that renders a product non-functional should never be shipped - period. Field-upgradability should *never* be an excuse for sloppy work.

Steve

The optimum development team size is one.

John

For a project requiring several man-millenia of effort?

By no means all embedded software efforts are of low enough complexity to be handled by a single person. Nor are the various aerospace, transportation, nuclear or medical regulatory agencies likely to be sympathetic to the argument that you can provide an IVV capability or guarantee QA independence/oversight with a team of one.

Hi, Paul:

Paul E. Bennett escribió en comp.software.config-mgmt:

Yes, there is: it's call "the compiler".

The surgeon approach works because:

1/ They are working in a very narrow place (so communication problems are minimized) 2/ They are working on a very repetitive and specialized manner, so surprises and "conflicts" go to a minimum (the chances of the anaesthesist jumping for the scalpel crying "me! me! I'll open his belly!" are quite reduced)

I bet that's not the usual environment for a development team (and yes, it has been tried to mimic the advantages of the surgical teams into the programming field: the XP two programmers per PC and trying to specialize the members of the team and the project tasks so overlap is minimum has been tried with varied success).

--
SALUD,
Jesús
***
jesus_navarro@undominio.net
***

In article , Fred Bloggs writes

There are many systems that must not have an update capability. Yesterday (Thursday 7th August 2003) I was asked to specify an OTP part because for security reasons it must NOT be field upgradeable. This is for a state of the art system (for next seasons F1 cars) And yes it will be on a CAN network.

There are many systems such as control systems for safety related equipment, security equipment etc that do not want any way of upgrading the code because the code shipped MUST be as certified.

Changes are not permitted. In fact many have to use a specified version of the compiler.

As for "web accessible" some of the development areas I visit are not permitted web access (for safety and security) let alone their projects. Besides many of the projects don't have room for web access. I assume you mean Internet access. A small but important distinction.

Not a dinosaur just working in more professionals area than you are.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

nk

is

ood

th is

crop

we

tand

o

, but

t of

To be sure, Koushik, a developer does the integration testing. My point w= as that=20 one can't simply blame a programmer when his/her work is going to integra= te with=20 other system components. There may be integration or system level issues = beyond=20 his knowledge. He/she may well do the integration test and have to fix a = problem=20 in code he/she created or changed. But that does not necessarily imply th= at he=20 or she should have fixed the problem at unit test if the problem arose be= causse=20 of integration or system issues. Does that make my point clearer?

Dwain

--=20 Dwain Wilder Bear Meadow Folk Instruments

Hypocrisy is the homage vice pays to virtue. =97Fran=E7ois de La Rochefoucauld