1 / 34

Introduction and Course Outline

Introduction and Course Outline. CSCI 5801: Software Engineering. Introduction.

lynn
Download Presentation

Introduction and Course Outline

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. Introduction and Course Outline CSCI 5801: Software Engineering

  2. Introduction If you want to build a dog house, you can pretty much start with a pile of lumber, some nails, and a few basic tools, such as a hammer, saw, and tape measure. In a few hours, with little prior planning, you'll likely end up with a dog house that's reasonably functional... If you want to build a high-riseoffice building, it would be infinitely stupid for you to start with a pile of lumber, some nails, and a few basic tools. Because you are probably using other people's money, they will demand to have input into the size, shape, and style of the building.... You will want to do extensive planning, because the cost of failure is high. You will be just a part of a much larger group responsible for developing and deploying the building, and so the team will need all sorts of blueprints and models to communicate with one another.... -- Grady Booch, The Unified Modeling Language User Guide

  3. Why is Software Development Hard? • Millions of lines of code • Single failure  entire system fails • Hundreds of developers • Many of whom enter/leave project at different times • Requirement change rapidly • Software may be obsolete before it is completed Possibly most complex human activity ever!

  4. Complexity leads to Failures

  5. Complexity leads to Failures Catastrophic failures: • LA Air traffic control system shutdown (2004) • Counter exceeded maximum integer 232 • Northeast blackout (2003) • System deadlock due to simultaneous access to same data • Mars Rover Orbiter crash (1999) • Some software used metric while other used non-metric • USS Yorktown loses control of propulsion (1997) • Buffer overflow due to divide by zero

  6. Complexity leads to Failures Day-to-day failures: • Software takes too long to develop • More costly than expected • Not reliable enough • Does not do what users want or need • Difficult to maintain/modify as needs change The majority of commercial software projects started are never completed

  7. What is “Software Engineering” • Applying engineering principles to software development • Build software like we build bridges! • IEEE Definition:“Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software”

  8. Engineering Principles • Systematic • Clear process followed by all involved • Only way to coordinate 100’s of developers • Quantifiable • Can accurately measure/estimate key qualities • Cost and time to develop software • Correctness, reliability, usability of final product

  9. Engineering Principles • Disciplined • Commitment to quality by all involved • Developers, management, etc. • Ethics • Do not accept project that you do not have the skills to complete correctly • Do not release product until you know it meets standards

  10. ACM/IEEE Code of Ethics • PUBLIC • Software engineers shall act consistently with the public interest. • CLIENT AND EMPLOYER • Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest. • PRODUCT • Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. • JUDGMENT • Software engineers shall maintain integrity and independence in their professional judgment.

  11. ACM/IEEE Code of Ethics • MANAGEMENT • Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. • PROFESSION • Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. • COLLEAGUES • Software engineers shall be fair to and supportive of their colleagues. • SELF • Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

  12. Software Engineering is a Team Process • Many different types of developers involved • Programmers • Database designers • Web developers • User interface designers • Network engineers • Security experts • Management/budget • Technical writers • …and many more Must be able to communicate unambiguously Must be able to understand other viewpoints

  13. Developers must act Professionally • Participating in decision making • Listening to and understandingother viewpoints • Communicating ideas, needs, and potential problems • Keeping entire project in mind, not just your part • Assuming fair share of work • Doing your part of project correctly and on time Consensus

  14. Software Harder than Engineering • Much greater number of dimensions • Bridge that holds 200 tons will hold 100 tons • Performance f software on one example does not guarantee performance on any other • Problems much more poorly defined “Design a bridge to be built across this gorge based only on this picture”

  15. Understanding Customer Needs • Software products created for customers • Specifications created by client • Course registration system, medical record system… • Specifications based on what large set of users would like • Word processor, game, phone app… • Most frequent cause of failure: Not creating a product the customer wants or needs

  16. Customers and developers speak different languages • Example: Medical record system (customer is physician practice) • How do you know what the system should really do? • How do you know if it is actually working? Physicians Understand medicine, needs of practice Do not understand software development ideas or terminology Developers Understand programming and software development Do not understand medical terminology, needs of practice ???

  17. Stakeholders • System may have many users with different needs • Example: Course registration system • Students who use system to register • Advisors who approve registration • Department chairs who create sections • Registrars office who handles registration issues • Bursars office who handles payment • Maintenance personnel who upgrade system • Security personnel who enforce FERPA rules • Network engineers who implement distributed system • …and many others

  18. Software in Context • Part of larger-scale system of users and other external entities • Must correctly interact with all Students Financial software used by Bursar’s office Registration System Registrars University web site Faculty and advisors Transcript database Course inventory database

  19. Software Development Processes Major steps followed by all processes: • Feasibility study • Requirements Analysis • Architectural Design • Implementation and Testing • Product Delivery • Maintenance Done once in waterfall model Done multiple times in incremental/agile models

  20. Feasibility Studies “Should we build this system?” • Will it solve the customer’s problems? • Is it too costly? • Development costs • Hardware needed • User training • Maintenance • Do we have the expertise/personnel to successfully create the system?

  21. Requirement Analysis “What should the system do?” • Identification of stakeholders and needs • Elicitation of requirements • Documentation of requirements in manner understood by developers and customers • Validation of requirements • Prototyping

  22. Software Design “How should system work?” • Determination of overall system architecture • Decomposition into simpler modules/subsystems/objects • Formal design of interfaces between subsystems

  23. Implementation and Testing • Version control tools used to coordinate changes made by different developers • Testing done throughout process • Requirements validated for correctness • Test cases created during requirements phase • Regression testing/automated testing tools insure current version always correct • Test case results recorded for future reference

  24. Project Delivery • Acceptance Testing • Demonstrations of system to customer that product meets requirements • Beta testing by users • Installation • User training • …

  25. Maintenance • Different types of maintenance • Bug fixes • Adapting to new environments • Responding to evolution in requirements • 50% to 70% of resources spent on maintenance over lifetime of software

  26. Maintenance has become Greatest Expense! 100 Hardware Development 60 Percent of total cost Software 20 Maintenance 1955 1970 1985

  27. Maintenance • Bad decisions now increase maintenance costs later • Bad decisions in requirements  Changing software to meet actual customer needs • Bad decisions in design (not planning for reuse)  Harder to update software later • Bad decisions in coding/testing More bugs to fix later

  28. Academia vs. the Real World 10,000 – 50,000 person-hours 10 – 100s of developers 3 months – 1 year 10,000 – 1,000,000 of lines of code 5 -20 person-hours Single developer 1 -2 weeks 100s of lines of code University course programming project Commercial software products

  29. This course meant to fill in the gap 10,000 – 50,000 person-hours 10 – 100s of developers 3 months – 1 year 10,000 – 1,000,000 of lines of code 300 – 500person-hours 5 – 20 person-hours 4 -7 developers 12 weeks 1,000s of lines of code Single developer 1 -2 weeks 100s of lines of code University course programming project Software Engineering project Commercial software products

  30. Semester-long team project • Best way to learn software engineering is to do it in as real a circumstance as possible Learning software engineering without a project is like learning to swim like this

  31. Semester-long team project • Project specified by “customers” • Myself and/or other faculty • Details given during initial “kickoff” meeting • “Customers” available to clarify as needed • Project based on team sizes/abilities • Goal: learn how development works, not just spend days coding

  32. Individual projects during first half • Requirements Specification Document • Formal description of what system must do • Based on interviews with “customers” • System Architecture • Proposed decomposition of system into components • Formal description of how components interact • Both presented to entire class • Many different solutions to same problem • How could your proposal have been improved?

  33. Team project during second half 2 Stage incremental development • Most software created incrementally • Design/develop one major feature • Present system to “customers” • Get feedback for improvements to next feature • Refactor code, add other major feature • Present final system to customer

  34. Team Meetings 1 lecture per week free time for team meetings • Design decisions • Determine architecture, create APIs for interaction • Implementation and testing • Putting system together and testing regularly • Do not miss or be late for meetings! • Slows down entire team • Will be reflected in grades

More Related