1 / 20

Introduction to Software Engineering

Learn about the importance of software engineering in the face of increasing size and complexity of software systems. Understand the inherent and accidental complexity of software and discover the dominant discipline and tradeoffs involved in software development.

cgillespie
Télécharger la présentation

Introduction to Software Engineering

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. CSED191 컴퓨터공학소개Software EngineeringIntroduction & Overview CSE 99 서광열, CSE 05 김윤수

  2. Why Software Engineering?(김윤수 발표)

  3. Why Software Engineering? • Increasing Size • Increasing Complexity Software systems are like cathedrals; first we build them and then we pray - S. Redwine

  4. Software Size & Complexity 50 lines per page Double sided 500 pages/ream (2inches) NT5.0 = Statue of Libery Reference: UW CSE584(Winter 2001) Software Engineering Lecture Note 1

  5. “The Software Crisis” We cannot produce or maintain high-quality software at reasonable price and on schedule Gibb’s Scientific American article

  6. Inherent & Accidental Complexity • Frederick P. Brooks : Two kinds of Complexity • Inhrent Complexity: Cannot hope to reduce • Accidental Complexity: Hope to reduce • Some of the inherent complexity comes from the incredible breadth of software we build • However, not always easy to distinguish between these two kinds of complexity Reference: No Silver Bullet, Essence and Accidents of Software Engineering by Frederick P. Brooks, Jr.

  7. Dominant Discipline As the size of the software system grows, the key discipline changes – Stu Feldman

  8. Software Observations! • Ideas borrowed from David Notkin, a professor of UW • The question is What happens in a real software project?

  9. Don’t assume similarity among software systems Nuclear power system shutdown vs Reliability of educational game program Design of a sorting algorithm vs Design of event-based GUI system • Assume differences until proven • Not doing so causes a tremendous amount of confusion in the degree of applicability of different research approaches, tools, etc

  10. Intellectual tools dominate software tools in importance • How you think is more important than the notations, tools, etc that you use • EX: Information Hiding • EX: Design Pattern

  11. Estimating benefits is easier than estimating costs • “If only everyone only built software my way, it’d be great” is a common misinterpretation • EX: The formal methods community • EX: Many methodologists • At the same time, estimating costs and benefits is extremely hard

  12. Programming languages ensure properties distant from the ones we want • Programming languages help a lot, but they do not solve inhrent problems • EX: Contravariant type checking in ML has significant benefits, but it does not eliminate all errors in ML programs

  13. Tradeoffs are key • We always choose in favor of hard criteria(e.g., performance) over soft criteria(e.g., extensibility) • Brooks’ Golden Rule doesn’t really work NO!

  14. We know why now. Then What is Software Engineering? (서광열 발표)

  15. Software Engineering Definition IEEE Definition (1993) Software Engineering: • The application of a systematic, disciplines, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software. (2) The study of approaches as in (1).

  16. Software engineering is a “wicked problem” • cannot be easily defined so that all stakeholders agree on the problem to solve; • require complex judgements about the level of abstraction at which to define the problem; • have no clear stopping rules; • have better or worse solutions, not right and wrong ones; • have no objective measure of success; • require iteration-every trial counts; • have no given alternative solutions-these must be discovered; • often have strong moral, political or professional dimensions. Reference: Representing Hard-to-Formalise, Contextualised, Multidisciplinary, Organisational Knowledge - Simon Buckingham Shum

  17. Software Goals & Principles • Goals • Productivity • Quality • Desirable Properties • Understandability • Modifiability • Maintainability • Reusability • Testability • Reliability • Principles • Abstraction • Modularlization • Information Hiding • Encapsulation • Hiearchy • Decomposition • Refinement Reference: An Introduction to Software Engineering 포항공대 소프트웨어 공학 연구실

  18. Software Engineering Topics • General • Requirements and specification • Design • Evolution (maintenance, reverse engineering, reengineering) • Analyses and tools (static and dynamic) • Quality assurance and testing • Others • Metrics and measurement • CASE • Software process - CMM, ISO 9000, etc. • Specific methodologies • UML • Software engineering for specific domains (real-time, the web, etc.)

  19. Classic Books “A classic is something everyone wants to have read, but nobody wants to read.” - Mark Twain • Read anything by Brooks, Jackson & Parnas • “The Mythical Man-month” by Brooks

  20. Q&A

More Related