CSE403 Software Engineering, Autumn 1999

Gary Kimura

 

Lecture #2 Notes

Models

 

1)      Models of SWE

a)      Today we’ll look at why have a model

b)      The goals of a model

c)      Look at a few models

d)      What was NT’s model

2)      Why have a model

a)      Software has become vital in our everyday life

b)      Software programs are large complicated beasts

i)        NT started out small.  Today not one single person can grasp all of NT.

c)      A model recognize that SWE is more than just programming

d)      Recognize product life cycles

i)        Various requirements specification phases

ii)       Design phases

iii)     Coding and testing phases

iv)     Maintenance phase (bug fixes and revisions)

e)      A model helps recognize and define the division of labor

i)        Individual responsibilities (program managers, software design engineers, UI designers, testers, product support, internationalization, marketing, etc.)

ii)       How big should a team be (look at MMM)

iii)     Parallel work efforts

iv)     Does a one person team need a model

f)        Provide a common means of communication between all involved parties

g)      Documentation is vital

i)        Comments in the code is not sufficient documentation

ii)       Dave Cutler’s NT design workbook is now part of the Smithsonian

3)      Why not have a model

a)      Avoids bureaucracy

b)      Cost of an inadequate or improperly applied model

i)        Build the wrong product

ii)       Build something that doesn’t work

iii)     Build something that cannot be tested

iv)     Build something that cannot be maintained

v)      Not take into account personnel changes, and requirement changes

4)      Goals of a good model

a)      The obvious “Provide a framework for building a solidly engineered product”

b)      A paradigm that adds discipline and order to software development

c)      Provides a formal mechanism to clarify, track, and modify the product requirements throughout the product life cycle

d)      Provide a guideline for engineers to use in the product life cycle

e)      Provide feedback into the development cycle

f)        Compel engineers to want to use it

i)        Doesn’t get in the way

ii)       Convinces them that they will build a better product

iii)     Be easy to understand and use

g)      Keep everyone organized

h)      Many more “common sense” reasons

5)      First a simple model (waterfall)

a)      What it is

b)      What it tried to accomplish

i)        Account for more than programming

ii)       Feedback between phases

c)      Benefits

d)      Limitations

i)        Limited feedback increases risk

ii)       A requirement change can have a major cost downstream

6)      Boehm’s Spiral model

a)      What it is

b)      What it tried to accomplish

i)        Recognize that SWE is a process of iterative refinement

ii)       Allow for alternate designs and implementations

c)      Benefits

d)      Limitations

7)      Many more models

8)      Lessons from the models

a)      Each trying to capture or dictate how a project should be run

b)      Even a good properly applied model cannot fix a flawed design

c)      Not any model offers the 100% solution

d)      Often borrowing from one or more model is necessary

e)      Just as SWE is full of compromises so is using a SWE model

9)      The NT Experience

a)      Daily builds

i)        Incremental and clean builds

ii)       Catch build errors

iii)     Without daily builds entropy would rule

b)      Dog food

i)        NT developers ran the latest build on their own system.

ii)       Performance and functional inadequate features were usually taken care of in a timely fashion

iii)     Broken pieces had to get fixed

c)      Maintenance cost including maintaining compatibility between releases

i)        In NT 5.0 compatibility is now a huge burden. 

(1)   Maintaining old API sets

(2)   Apps that improperly used the API set in earlier releases

ii)       Unforeseen interaction between pieces also increases maintenance costs

(1)   Small changes break seemingly unrelated things, for example the handle table change in NT 5.0

(2)   Controlling kernel stack usage is always hard

(3)   MP performance problems crop up constantly when two pieces interact