1 / 16

CSE403 Software Engineering Autumn 2001

CSE403 Software Engineering Autumn 2001. Gary Kimura Lecture #2 October 3, 2001. Today. Finish Monday’s lecture 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.

tmeyer
Télécharger la présentation

CSE403 Software Engineering Autumn 2001

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related