The software development process.

[David Brown]

["Followup-To:" header set to sci.electronics.design.]
On Thu, 14 Sep 2006 10:40:35 +0200,

The "truth" is another one I think.

The "truth" is yet another one I think.

Where I work, nobody except a few nerds like me have ever heard about
OpenOffice. Let alone the sectretaries who are the main users of office
software. When you tell them that there exist other programs to write
stuff (mostly single-page documents which, in big, colorful letters,
advise people to rinse their coffee cups after use or to shut the door)
they look at you funny because they have no idea what a "program" is.
They'd simply balk if they were told that now they were to use something
else. You'd probably get away with it if you replaced the Oo logo with
that of Word and did away with the splash screen. Then they'd think they
were working with just another version of Word.

robert

Exactly the point - if a company wants to switch to OpenOffice (or
StarOffice, if they are an American company and want to pay money so
that they have someone to sue), they should simply do the swap on the
company PCs. Most users will barely notice the difference - they have
no idea what the programs they use are called in the first place. When
asked what word processor they use, people will tell you it is "Windows
XP", or perhaps "Dell".

 

[Michael A. Terrell]

Exactly the point - if a company wants to switch to OpenOffice (or
StarOffice, if they are an American company and want to pay money so
that they have someone to sue), they should simply do the swap on the
company PCs. Most users will barely notice the difference - they have
no idea what the programs they use are called in the first place. When
asked what word processor they use, people will tell you it is "Windows
XP", or perhaps "Dell".

Most of the people I've worked with not only knew what software was
on their computer, they knew what rev it was, and most or all of the
information about the computer itself, because the "IdioT" department
liked to make changes without telling you. This conversation occurred
at a place I worked, between the production manager and "IT".

"Where is the computer off my desk? Don't worry, we moved all your
files. Where is the computer you took? You didn't transfer the dual
Black Box RS-485 card for the time clock system. Oh, that's what that
card was? You weren't authorized to have it, so we threw it away.
Can't you just go back to a sign in sheet?"


There was about 20% of the people who didn't care what they used, but
most of them were using older computers as 9600 baud terminals to the
Prime minicomputer used for MRP by manufacturing.

--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

 

[[email protected]]

For some reason, the Windows versions of PowerBasic require that all
subroutines be placed before PBMAIN, and PBMAIN is itself a formal
subroutine. So a program doesn't start "at the beginning."

John

Stopped wrestling with 'PB for windows' because of just that feature.
Saw it as a 'state of mind' and a glaring C derived inanity that should
have been handled by the compiler, hence transparent to the user.
Mr Zale there couldn't understand how such a trivial item could
possibly offend a customer who is 100% supportive of his DOS PB
product.
For the occasional windows fluff, I now use Purebasic.
john

 

[Hans-Bernhard Broeker]

[Note: Followup-To reduced --- why didn't any do this before?]

A straight extrapolation from Corsair's numbers to an MCU with 16 KiB of
RAM would give one error every 1300 years, which isn't worth losing much
sleep over.

If only build a couple dozen of the things to control model railways,
may be not. But imagine, just for a moment, you were doing a
mass-market product; say a million units in the field. That means you
get two of those faults in your user base every day. If those devices
control something critical, and you deliver the million units within
one year, you'll have injured someone within the three weeks after
start of production.

If that's not something to lose sleep over, what would be?

 

[Anton Erasmus]

Hi All,

Could you please advice how you provide the software development
process ?

I need some example to reference.

In my understanding is:

1. Specification list and discussion.
2. Solution and schedule proposed.
2.1 Critical task analysis
2.2 Other task list.
2.3 Schedule estimation.
3. Development and Test.
3.1 Finish critical task.
3.2 Development and test function block as unit.

4. System level / prodcut test

5. Mass production.

The book "Practical Software Requirements" by Benjamin L. Kovitz gives
a very good overview of a practical workable process in the context of
writing a workable Software Requirement.

Regards
Anton Erasmus

 

[Anton Erasmus]

Do you think so? Most of the bugs I see are in the coding. Is there a
spec that requires Word to corrupt files?

IMO the problem is probably that there is nothing in the spec that
says it should not corrupt files, hence since non-corruption of files
is not arequirement, the final product need not comply.
Often specs are bad not because they put silly things in, but because
they leave important things out.

[Snipped]

Regards
Anton Erasmus

 

[Paul E. Bennett]

With the more exotic "and such" being perhaps surprisingly common.
Cosmic rays and radioactive decay cause one flipped bit a week in a PC
with a gig of RAM, according to this:

http://corsairmemory.com/corsair/products/tech/trg-ecc.html

A straight extrapolation from Corsair's numbers to an MCU with 16 KiB of
RAM would give one error every 1300 years, which isn't worth losing much
sleep over. The Corsair document is a bit thin on technical details
though. Perhaps DRAM is more susceptible than SRAM and we needn't worry
at all for a typical MCU. Or perhaps SRAM is much more susceptible and
the probability of error is significant.

Does anybody have any proper numbers for 'random' errors in MCUs?

If we are going to talk about that stuff then we ought to be aware of the
effect of chip geometry and feature sizes in the susceptability factors.
One of my colleagues at work recently gave a talk on the subject and had
some figures. He has now, alas, transferred back to the Cadarache
establishment.

--
********************************************************************
Paul E. Bennett ....................<email://[email protected]>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

 

[John Larkin]

Do you think so? Most of the bugs I see are in the coding. Is there a
spec that requires Word to corrupt files?

IMO the problem is probably that there is nothing in the spec that
says it should not corrupt files, hence since non-corruption of files
is not arequirement, the final product need not comply.
Often specs are bad not because they put silly things in, but because
they leave important things out.

[Snipped]

Regards
Anton Erasmus

Heck, my copy if the PCI bus spec mentions nothing about boards not
being allowed to explode and kill people. Maybe in a later revision?

John

 

[Anton Erasmus]

On Fri, 8 Sep 2006 10:50:38 +0200, "Frithiof Andreas Jensen"


Whatever you do, choose a process with rapid prototyping and testing
that also allow room for the specification to be changed because the
majority of the bugs will be in the specification.

Do you think so? Most of the bugs I see are in the coding. Is there a
spec that requires Word to corrupt files?

IMO the problem is probably that there is nothing in the spec that
says it should not corrupt files, hence since non-corruption of files
is not arequirement, the final product need not comply.
Often specs are bad not because they put silly things in, but because
they leave important things out.

[Snipped]

Regards
Anton Erasmus

Heck, my copy if the PCI bus spec mentions nothing about boards not
being allowed to explode and kill people. Maybe in a later revision?

I probably should have added a smiley to my original comment.
I also doubt that if your board explodes when plugged into the PCI
bus, that it did conform to the spec in the first place. Also I dont
think one can specify that when something explodes it should not kill
people

To an experienced person , or someone that know what they are doing,
many things are "obvious". From all accounts MS neither wants or can
get either of these types of persons.

Regards
Anton Erasmus

 

[mc]

I probably should have added a smiley to my original comment.
I also doubt that if your board explodes when plugged into the PCI
bus, that it did conform to the spec in the first place. Also I dont
think one can specify that when something explodes it should not kill
people

Can the Army make a standard-conforming PCI-bus bomb if they want to?

 

[John Larkin]

On Fri, 08 Sep 2006 08:01:26 -0700, John Larkin

On Fri, 8 Sep 2006 10:50:38 +0200, "Frithiof Andreas Jensen"


Whatever you do, choose a process with rapid prototyping and testing
that also allow room for the specification to be changed because the
majority of the bugs will be in the specification.

Do you think so? Most of the bugs I see are in the coding. Is there a
spec that requires Word to corrupt files?

IMO the problem is probably that there is nothing in the spec that
says it should not corrupt files, hence since non-corruption of files
is not arequirement, the final product need not comply.
Often specs are bad not because they put silly things in, but because
they leave important things out.

[Snipped]

Regards
Anton Erasmus

Heck, my copy if the PCI bus spec mentions nothing about boards not
being allowed to explode and kill people. Maybe in a later revision?

I probably should have added a smiley to my original comment.
I also doubt that if your board explodes when plugged into the PCI
bus, that it did conform to the spec in the first place. Also I dont
think one can specify that when something explodes it should not kill
people

To an experienced person , or someone that know what they are doing,
many things are "obvious". From all accounts MS neither wants or can
get either of these types of persons.

Regards
Anton Erasmus

I've heard firsthand that MS has a lot of competant and dedicated
programmers. But the structure of Windows, as cobbled up by Bill and
pals (you couldn't use the word "designed" anywhere near Windows) make
the module interfaces an unholy mess, and the combination of thousands
of programmers, hundreds of millions of lines of code, and insane
vicious management means they *can't* really write code that works
properly. Look at Vista: it has more "features" than XP, uses far more
resources to implement Apple-wannabe cosmetics, is missing - after 7
years of work - major promised elements, and will no doubt be less
stable and more frustrating than XP when released.

Come to think of it, Apple does most of Microsoft's "design" these
days, and Google does the rest.

John

 

[John Larkin]

Can the Army make a standard-conforming PCI-bus bomb if they want to?

I wonder what the specification for a cluster bomb looks like? Must be
truly grim.

John

 

[werty]

Its about profits and jobs ( i heard that from Bill Gates )
Thus no one will ever sell nor use good s/w , it puts too
many people out of work . Nothing puts humans out of
work like a new computer ......

Long ago assemblers belabored the fundamental concept of a
Macro , Forth did the opposite and the concept of software
"leverage" was born . Some continued to evolve Forth for
the new hardware .
Its just a matter of time before Linux ,WXP ,UNIX ,C+ et al are
tossed .
and billions of $$ in Applications !

Its so simple , you dont want to think at a low level or an
"obtuse" level , you want it to be intuitive , so you create
an OpSys thats structured and simple . But if you listen
to C programmers or Linus , you'd think its really hard !
They're belaboring to keep their "job" .
When the new free OpSys arrives for the ARM , everyone gets the axe ,
Microsoft , Linus , GCC ,GNU , Millions of jobs , gone ....

Why use C when a scipting HLL produces an App in 15 minutes
without any bugs ?
It does this because there is no text , its a GUI , you put images
and icons together ....
Now you argue that no one can create number stuff with using
Fortran or I.E.E.E. 966 Floating point ec etc ....
Math is easy , especially if you stay away from the college grads
and people with software jobs .
How about asking a college professor how to create an OpSys ?
Well first ya gotta take my class where i'll tell ya which books ya
gotta
buy then you'll have to take 3 more classes where i'll tel ya to take
12 more classes .....and at the end where ya get ya diploma ,
and read my book which tells ya in da summary what i taught ya .

Gall ! a software author writes a book and in the Intro tells ya what
he will
teach you , in the body tells ya what you should know , but fails
to teach ya , and in the summary tells ya what he taught you !!!
Then says you're unteachable !! Like Albert Eistein , told by
his prof's , he would amount to nothing , he can't learn ...
Now same colleges want credit for part of his work .
We taught him everything he knows .......


Nothing more Luddite than software ! Nothing so easily obsoleted ..

Creating the first part of OpSys is called the insulation layer ,
it insulates you from the instruction set / Assembly code .
Everything else is so "human" and intuitive , it takes 15 minutes
to create an App . You cant create bugs , the kernel tells ya
immediately . Kernel does this cause its very structured which allows
the Kernel to think exactly like you do .
Do you want to [Allocate] 65KB of upper memory ?
There is no [allocate] in New Forth , everything is in a Dictionary .
Push 2 vars on the [STACK] ....
New Forth has auto VARS , you never have to think about
Locals/Globals,
all you do is move images around and the OpSys learns what TYPE they
are , so it knows all about managing what others force you to deal with
..
Like WXP and Linux force you to manage your own
Files/Folders/Objects.
New Forth manages ALL for you .

 

[David Ashley]

New Forth manages ALL for you .

Sir/Madame,

Pick a newsgroup and stick with it. This cross
posting looks awfully like flame-bait. Either you've got a valid
point to make but you're just inexperienced at doing it, or you're
just a vandal trying to insert chaos into the system.

If you've got all the answers, go raise some capital,
create this magical NewForth you're talking about, and
prove it's the answer to all our problems. I like passion but
it's easy to come off sounding like a nut case.

-Dave

 

[Joerg]

Hello Robert,

The "truth" is yet another one I think.

Where I work, nobody except a few nerds like me have ever heard about
OpenOffice. Let alone the sectretaries who are the main users of office
software. When you tell them that there exist other programs to write
stuff (mostly single-page documents which, in big, colorful letters,
advise people to rinse their coffee cups after use or to shut the door)
they look at you funny because they have no idea what a "program" is.
They'd simply balk if they were told that now they were to use something
else. You'd probably get away with it if you replaced the Oo logo with
that of Word and did away with the splash screen. Then they'd think they
were working with just another version of Word.

That can be very different. When I hired mine she became the
administrative assistant of our division, not just my secretary. This
way she was exposed to all kinds of other software. Of course, I made
sure I hired someone who would be a self-starter. Then I found out that
admins here in the western US are used to doing everything with Word and
Excel. So, I introduced the database concept to her. Now that our
company has been bought and neither of us is there anymore she does the
same thing in other companies, weening them off those dreaded Excel
calcs and into databases. And that does not have to be MS-Access.

 

[Frithiof Andreas Jensen]

I wonder what the specification for a cluster bomb looks like? Must be
truly grim.

Yup. I read the specs for a Swiss made hand grenade, this thing was
supposed to deliver 80 fragments per m^2 at two meters distance with
minimum energy of 50J each! I bet that hurt!!

 

[Boki]

The book "Practical Software Requirements" by Benjamin L. Kovitz gives
a very good overview of a practical workable process in the context of
writing a workable Software Requirement.

Regards
Anton Erasmus

I get it, thanks a lot for information.

Best regards,
Boki.