1. CSE403 Software Engineering Autumn 2000
CSE 403 Autumn 2000
CSE403 Software Engineering Autumn 2000
Gary Kimura
Lecture #2
September 27, 2000
September 27, 2000

2. Today TA’s (Will Portnoy and Jia-Chi Wu) Subscribe to the email alias
Questions from Monday
Software lifecycles
Models

3. Models of Software Engineering
Why have a model
The goals of a model
Look at a few models
What was NT’s model

4. Why have a model Software has become vital in our everyday life
Software programs are large complicated beasts
NT started out small. Today not one single person can grasp all of NT.
A model recognize that Software Engineering is more than just programming
Recognize product life cycles
Various requirements specification phases
Design phases
Coding and testing phases
Maintenance phase (bug fixes and revisions)

5. More reasons to have a model
A model helps recognize and define the division of labor
Individual responsibilities (program managers, software design engineers, UI designers, testers, product support, internationalization, marketing, etc.)
How big should a team be (look at MMM)
Parallel work efforts
Does a one person team need a model
Provide a common means of communication between all involved parties
Documentation is vital
Comments in the code is not sufficient documentation
Dave Cutler’s NT design workbook is now part of the Smithsonian

6. Why not have a model Avoids bureaucracy
Cost of an inadequate or improperly applied model
Build the wrong product
Build something that doesn’t work
Build something that cannot be tested
Build something that cannot be maintained
Not take into account personnel changes, and requirement changes

7. Goals of a good model
The obvious “Provide a framework for building a solidly engineered product”
A paradigm that adds discipline and order to software development
Provides a formal mechanism to clarify, track, and modify the product requirements throughout the product life cycle
Provide a guideline for engineers to use in the product life cycle
Provide feedback into the development cycle

8. More goals of a good model
Compel engineers to want to use it
Doesn’t get in the way
Convinces them that they will build a better product
Be easy to understand and use
Keep everyone organized
Many more “common sense” reasons

9. First a simple model (waterfall)

10. More on the waterfall model
What it is
What it tried to accomplish
Account for more than programming
Feedback between phases
Benefits
Limitations
Limited feedback increases risk
A requirement change can have a major cost downstream

11. Boehm’s Spiral model

12. More on the spiral model
What it is
What it tried to accomplish
Recognize that Software Engineering is a process of iterative refinement
Allow for alternate designs and implementations
Benefits
Limitations

13. Lessons from the models
Each trying to capture or dictate how a project should be run
Even a good properly applied model cannot fix a flawed design
Not any model offers the 100% solution
Often borrowing from one or more model is necessary
Just as Software Engineering is full of compromises so is using a Software Engineering model
So take these models with a grain of salt and use only those parts that apply to your situation

14. The NT Experience Daily builds Dog food Incremental and clean builds
Catch build errors
Without daily builds entropy would rule
Dog food
NT developers ran the latest build on their own system.
Performance and functional inadequate features were usually taken care of in a timely fashion
Broken pieces had to get fixed

15. The NT Albatross
Maintenance cost including maintaining compatibility between releases is huge
With NT 5.0 compatibility is now a huge burden.
Maintaining old API sets
Apps that improperly used the API set in earlier releases
Unforeseen interaction between pieces also increases maintenance costs
Small changes break seemingly unrelated things, for example the handle table change in NT 5.0
Controlling kernel stack usage is always hard
MP performance problems crop up constantly when two pieces interact

16. Next time Thursday in section Friday Form groups
Due Friday (via to garyki, will, and jcwu) is a list of group members and list of the top three risks your group foresees
Only one per group please
Be sure to CC everyone in your group so we have their addresses
Friday
Project overview
What is a user mode heap
Basic group organization