1. CSE403 Software Engineering Autumn 2001 Gary Kimura Lecture #2 October 3, 2001

2. Today Finish Monday’s lecture 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 –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 later versions of NT compatibility is 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 –Form groups –Due Friday (via email to garyki, will) is a list of group members and list of the top three risks your group foresees –Only one email per group please –Be sure to CC everyone in your group so we have their email addresses Friday –Project overview –Basic group organization