Introduction and Course Outline - PowerPoint PPT Presentation

Loading...

PPT – Introduction and Course Outline PowerPoint presentation | free to view - id: 71cf0d-YWFhZ



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Introduction and Course Outline

Description:

Introduction and Course Outline CSCI 5801: Software Engineering – PowerPoint PPT presentation

Number of Views:68
Avg rating:3.0/5.0
Slides: 35
Provided by: Amya155
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com