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

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

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

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)

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

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

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

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

First a simple model (waterfall)

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

Boehm’s Spiral model

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

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

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

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

Next time Thursday in section Friday Form groups Due Friday (via email to garyki, will, and jcwu) 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 What is a user mode heap Basic group organization