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 - 10:50:47 GMT