Introduction and Course Outline

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

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 DefinitionSoftware 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 100s 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 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
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 Bursars 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 customers 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/obje
  cts
• 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
Commercial software products
Software Engineering project
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