Introduction and Course Outline CSCI 5801 Software Engineering

Introduction and Course Outline CSCI 5801: Software Engineering

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-rise office 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

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!

Complexity leads to Failures

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

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

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”

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

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

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.

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.

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

Developers must act Professionally • Participating in decision making • Listening to and understanding other viewpoints Consensus • 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

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”

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

Customers and developers speak different languages • Example: Medical record system (customer is physician practice) 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 • How do you know what the system should really do? • How do you know if it is actually working?

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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?

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

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