Until the Japanese started programming "in the large," the terms
"software" and
"engineering" were pretty much mutually exclusive after 1965. Until the
Nipponese brought in a 15-Million-line software task within schedule and under
budget, nobody believed it could be done. It was another case of the Japanese
simply doing what the Americans had, for two decades, told everyone was the
right way to do it, though. ... nothing new ... just do it right.
Dick
----- Original Message -----
From: "Jeffrey S. Sharp" <jss(a)subatomix.com>
To: <classiccmp(a)classiccmp.org>
Sent: Saturday, December 15, 2001 9:50 AM
Subject: Re: "Geeks" and licensing
On Sat, 15 Dec 2001, Jim Davis wrote:
IMHO: All software development should be
performed as such:
1) Requirements - what should it do, and not do. Spin this till
everybody signs off.
2) Prelim design - Ok, a rough outline of the design, data structures
and control/data flow defined here.
3) Detailed design - Define all the modules and their function, break it
down.
4) Test plan - integrate testing into detailed design, make it unit
testable. a unit is somthing that has input and output and side
effects, like a function.
5) Finally, coding - build modules in parallel with test code.
6) Unit testing - verify that modules comply with detailed design.
7) Integration testing - hook it all together, make sure it works, apply
test plan developed in step 4 for fully integrated aplication.
Do 1-3 until marketing decides what they want,4-7 until you find no
errors.
And possibly add some planning where you use historical data and basic
statistics to figure out how big the product will likely be, how long it
will take, and what resources need to be allocated to complete it.
For safety critical, you should /have to perform
statement and
decision coverage in step 6 and 7 and the detailed design should have
a one-to-one corespondence with the detailed design document. Jim
Davis.
The software process course I just got out of also heavily pushed peer
review of designs and code as a way to filter out defects before testing.
These have their benefits, but I remain unconvinced of their status as the
great panacea of software engineering that the course touted them as.
For a little bit of on-topic goodness, what is the group's opinion on the
trend of software engineering quality starting from ancient times? Have
we improved (practially, not academically) or worsened?
--
Jeffrey S. Sharp
jss(a)subatomix.com