1 / 17

Software Engineering Overview

Software Engineering Overview. 23 January. Software Engineering Overview. What is engineering? Why is software engineering different than other engineering disciplines? Is software engineering different than computer science? programming?

cece
Télécharger la présentation

Software Engineering Overview

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. Software Engineering Overview 23 January

  2. Software Engineering Overview • What is engineering? • Why is software engineering different than other engineering disciplines? • Is software engineering different than • computer science? • programming? • How similar or different are software engineering projects?

  3. Engineering • Turning ideas into reality • Creating something useful from other things using science and math

  4. Software Engineering vs. Other Engineering Disciplines • Maturity • Roman aqueducts 2000 years ago • Software engineering 50 years ago • Startup costs • Barriers to entry • Rate of change

  5. What’s in a Name? • Software engineer • Computer scientist • Programmer • Coder • Developer • Designer • Architect

  6. Different Types of Projects • Consider 4 different types of systems • COMP 523 projects • Productivity suites • Commercial web sites • Airplane systems • Pacemakers • How do they differ in criticality? • What does that mean for the development process?

  7. Expectations of Software Engineering(Watts Humphrey) • Predetermine quantitative quality goals • Accumulate data for use in later projects • Keep all work visible • Design, program and test only against requirements • Measure and achieve quality goals

  8. Keeping Work Visible: Documentation • What will be implemented • Customer: contract, requirements, “glossy” • User: manuals • How it will be implemented • Project plan • The code • The test plan • What people will do • How you will manage code and documents

  9. Documentation Principles • Need to reflect changes • Version control • Need to keep all documents synchronized • Single owner • Only say it once

  10. Quality Management Principles • Customer focus • Leadership • Involvement of people • Process approach • System approach to management • Continual improvement • Factual approach to decision making • Mutually beneficial supplier relationships http://www.iso.ch/iso/en/iso9000-14000/iso9000/qmp.html

  11. Customer Focus • Organizations depend on customers • Understand needs, requirements, expectations • Increases market share • Implies • Market research • Customer understanding throughout the organization • Measuring satisfaction

  12. Involvement of People • Essence of the organization • “Buy in” • Two way street • Treating people with respect • They will take on ownership of responsibility • Encourage a collaborative environment

  13. Software Engineering Fundamental Steps • Requirements • Design • Implementation • Integration • Test (elaborated versions to be covered later)

  14. Processes • Differ by how often you do the steps • Points on the spectrum • Differences in overhead • Three fundamental models • Waterfall • Spiral • Iterative

  15. Waterfall • Do it once • Traditional model • Used for large next version releases, especially when tightly coupled changes • Pros • Simple documentation management • Clean design phase • Cons • Least flexibility • No early feedback

  16. Spiral • Few iterations • Each iteration adds new requirements • Used often for projects with less well defined requirements • Pros • Adaptation to changes based on risks • Good customer interaction • Early version • Limited iterations provide phase structure • Cons • Document maintenance

  17. Iterative • Many iterations • Each iteration is on a fixed cycle • Typically weekly • Used for projects with lots of small independent, but well understood, changes • Pros • Fast feedback on problems • Very adaptable to any changes • Lots of versions to work with • Cons • Document maintenance • Code maintenance • Requires good automation

More Related