Transcript Introduction and Course Outline

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
Developers
Understand medicine,
needs of practice
Do not understand
software development
ideas or terminology
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
Students
Financial software used
by Bursar’s office
University web site
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 – 100s of
developers
5 -20
person-hours
3 months – 1 year
Single developer
1 -2 weeks
100s of lines of
code
10,000 – 1,000,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
5 – 20
person-hours
Single developer
1 -2 weeks
100s of lines of
code
University course
programming project
300 – 500
person-hours
10 – 100s of
developers
4 -7 developers
3 months – 1 year
12 weeks
1,000s of lines of
code
Software Engineering
project
10,000 – 1,000,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