Post on 30-Dec-2015
transcript
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• 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
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)
• How do you know what the system should really do?• How do you know if it is actually working?
PhysiciansUnderstand medicine, needs of practiceDo not understand software development ideas or terminology
Developers Understand programming and software developmentDo not understand medical terminology, needs of practice
???
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
• Part of larger-scale system of users and other external entities
• Must correctly interact with all
Software in Context
Registration System
Students
Registrars
Faculty and advisors
Transcript database
Course inventory database
Financial software used by Bursar’s office
University web site
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
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!
HardwareDevelopment
Software
Maintenance
1955 1970 1985
100
60
20
Per
cen
t o
f to
tal c
ost
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
Single developer1 -2 weeks
100s of lines of code
5 -20 person-hours
University course programming project
10,000 – 50,000
person-hours
Commercial software products
10 – 100s of developers
3 months – 1 year
10,000 – 1,000,000 of lines of code
This course meant to fill in the gap
Single developer1 -2 weeks
100s of lines of code
5 – 20 person-hours
University course programming project
10,000 – 50,000
person-hours
Commercial software products
10 – 100s of developers
3 months – 1 year
10,000 – 1,000,000 of lines of code
300 – 500person-hours
Software Engineering project
4 -7 developers
12 weeks
1,000s of lines of code
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