"Geeks" and licensing

From: Richard Erlacher <edick_at_idcomm.com>
Date: Sat Dec 15 11:06:28 2001

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_at_subatomix.com>
To: <classiccmp_at_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_at_subatomix.com
>
>
Received on Sat Dec 15 2001 - 11:06:28 GMT