Software Engineering Preview

1
sysc-4800 Software Engineering

• Software Engineering Preview

2
Software Engineering Preview

• Definitions
• Software Failures
• History and Context
• Software Development Myths
• Principles
• Software Development Processes

3
Definitions of SW Engineering

• Parnas 1987
• Multi-person construction of multi-version
  software
• Software Engineering means the construction of
  quality software with a limited budget and a
  given deadline in the context of constant change
• Software Engineering IEEE-93
• The application of a systematic, disciplined,
  quantifiable approach to the development,
  operation, and maintenance of software that is,
  the application of engineering to software.
• Highlights the difference between programming and
  software engineering

4
Definitions of SW Engineering (cont.)

• Canadian Standards Association
• The systematic activities involved in the
  design, implementation and testing of software to
  optimize its production and support
• Lethbridge-2004
• Software engineering is the process of solving
  the customers problems by the systematic
  development and evolution of large, high-quality
  software systems within cost, time and other
  constraints.
• Customers problems The goal of every software
  engineering project
• Systematic An engineering process based on
  well-understood techniques.
• Large Implies complexity beyond the
  capabilities of a single person
• Constraints Engineering is and always has been
  done within constraints , both physical and
  economics.

5
The Engineer in SW Engineering

• Engineers design products following well-accepted
  practices which normally involve the application
  of science, mathematics and economics
• As professionals, engineers assumes a duty of
  personal responsibility to the public and
  society, and a code of ethics.
• The society includes the customer (ie. meeting
  economic and time constraints)

6
Scope of SW Engineering

• SE is part of a much larger system design
  activity
• Telephone switching systems, power plants,
  banking systems, hospital admin systems
• Doing SE right requires a much larger look at
  system engineering issues
• Important then entities and activities within
  the system, its boundary and interface with other
  systems and users
• Understanding the application and user needs is
  key
• Decide what activity should be supported by the
  system and how
• Having a technical understanding of the system to
  be developed is not enough
• Many domains, where very different software
  systems must be developed, with emphasis on
  different priorities
• time-to-market (telecom), safety (aerospace, NASA
  Shuttle), maintainability (telecom, banking)

7
Importance of SW Engineering

• Software is pervasive in our lives, in most
  systems surrounding us - we take it for granted!
• US 500 Billion world-wide in 1995
• This includes critical systems that affect our
  well-being and our lives
• Many reported stories of poor software
  engineering practices leading to catastrophes

8
Software Quality Lethbridge

• External Characteristics
• Usability
• Efficiency
• Reliability
• Maintainability
• Reusability
• Internal Characteristics Impact maintainability
  and reliability
• Comments
• Code Complexity Nesting depth, branches, complex
  programming

Short term
Engineering is tradeoffs
Long term
9
Types of Software Lethbridge

• Custom Developed specifically for the customer
• typically used by a few users of little use to
  others
• developed in-house or by contracting
• Generic Performs functions on general-purpose
  computers
• Used by many people
• Sold on open market (cheaper)
• Usually a poor match when used for specific needs
  of organization.
• COTS/ shrink-wrapped
• Embedded Run on specific hardware devices, sold
  in the consumer market

• Real-Time
• Must react immediately to environment
• Key design issues are responsiveness and safety
• Data-Processing
• Key design issues are organization of data and
  functions available for use to manipulate the data

Orthogonal views a system can be both
10
Types of Software Pressman

• System Software Written to service other
  programs.
• Heavy interaction with H/W
• Concurrency, complex data
• Determinate vs indeterminate
• Application Standalone programs that service
  specific (business) need.
• Scientific Number Crunching algorithms.
• Embedded Run on specific hardware devices, with
  a focus on control

• Product-Line
• Specific capability for use by many different
  customers
• Web Application
• Content and computation provider for distributed
  end-users
• Integrated with corporate databases and business
  processes.
• Artificial Intelligence
• Non-numerical algorithms for complex problems not
  suited to computation.

11
Types of Software Projects Lethbridge

• Evolutionary Modify an existing system
• Often called maintenance
• Not just fixing bugs, but adding new (often
  significant) features hence project evolution
• Corrective Simply defect fixes
• Adaptive Adapt to changes in environment
• Quick Tax 2001, 2002, 2003 (New tax laws each
  year)
• Enhancement Adding new features
• Re-engineering Changing internally without
  affecting users.
• Greenfield Develop a brand-new system from
  scratch
• Not constrained by design decisions of previous
  developers
• Frameworks Plug together existing components
• Framework specifically designed to be reused in
  various product lines
• Contains most functionality, but must be adapted
  to particular customer.

Which kind of project do you think you will work
on?
12
SE Stakeholders Lethbridge

• Developers are only one of the stakeholders in a
  SE Project
• Users Use the end-product
• Appreciate software that is easy to learn,
  improves their working conditions
• Customers Order and pay for the software
• Increase profits or run business better
• Development Managers Manage the developers
• Please the customer while spending the least
  money.
• One person may take on multiple roles.

13
Activities Involved

• Knowledge acquisition
• Understand the application domain, the system
  requirements
• Modeling (the blue-print of the software
  engineer)
• Way to cope with complexity, e.g., UML
• Problem solving
• Find an acceptable solution within constraints
• Documentation
• The rationale behind decisions need to be
  captured, in order to be able to deal with change

14
SE Activities and Roles (Pfleeger, 1998)
15
Software Engineering Preview

• Definitions
• Software Failures
• History and Context
• Software Development Myths
• Principles
• Software Development Processes

16
Examples of SE Failures

• Soyuz spacecrafts descent from the ISS on May
  3rd 2003
• Halfway back to Earth, for no apparent reason,
  the computer had suddenly begun searching for the
  ISS as if to dock with it.
• Ariane 5 Flight 501
• The space rocket was destroyed. Cause poor
  specifications, usage testing, and exception
  handling.
• Therac-25
• Radiation therapy and X-ray machine killed
  several patients. Cause unanticipated,
  non-standard user inputs.
• NASA mission to Mars (Mars Climate Orbiter
  Spacecraft, 1999)
• Incorrect conversion from imperial?metric leads
  to loss of Mars satellite
• Denver Airport
• Late delivery of software for the baggage system
  delays the opening of the airport by 16 months
• US study (1995)
• 81 billion US spend per year for failing
  software development projects
• Although many success stories, there is much room
  for improvement

17
Ariane 5 ESA Launcher
18
Ariane 5 Press Release, June 96

• Paris, 4 June 1996, ESA/CNES Joint Press Release,
  ARIANE 501
• The first launch of Ariane 5 did not result in
  validation of Europe's new launcher. It was the
  first flight test of an entirely new vehicle each
  of whose elements had been tested on the ground
  in the course of the past years and months.
• Of an entirely new design, the launcher uses
  engines ten times as powerful as those of the
  Ariane-4 series. Its electronic brain is a
  hundred times more powerful than that used on
  previous Ariane launchers. The very many
  qualification reviews and ground tests imposed
  extremely tough checks on the correctness of all
  the choices made. There are, however, no absolute
  guarantees. A launcher's capability can be
  demonstrated only in flight under actual launch
  conditions.
• A second test already scheduled under the
  development plan will take place in a few months'
  time. Before that, everything will have to be
  done to establish the reasons for this setback
  and make the corrections necessary for a
  successful second test. An inquiry board will be
  set up in the next few days. It will be required
  to submit, by mid-July, an entirely independent
  report identifying the causes of the incident and
  proposing modifications designed to prevent any
  further incidents.
• Ariane 5 is a major challenge for space
  activities in Europe. The skills of all teams
  involved in the programme, coupled with the
  determination and solidarity of all the
  political, technical and industrial authorities,
  make us confident of a successful outcome.

19
Ariane 5 Root Cause

• Source ARIANE 5 Flight 501 Failure, Report by
  the Inquiry Board
• A program segment for converting a floating point
  number to a signed 16 bit integer was executed
  with an input data value outside the range
  representable by a signed 16 bit integer.
• This run time error (out of range, overflow),
  which arose in both the active and the backup
  computers at about the same time, was detected
  and both computers shut themselves down.
• This resulted in the total loss of attitude
  control.
• The Ariane 5 turned uncontrollably and
  aerodynamic forces broke the vehicle apart.
• This breakup was detected by an on-board monitor
  which ignited the explosive charges to destroy
  the vehicle in the air.
• Ironically, the result of this format conversion
  was no longer needed after lift off.

20
Ariane 5 Lessons Learned

• Rigorous reuse procedures, including systematic
  usage-based re-testing
• Adequate exception handling strategies (backup,
  degraded procedures?)
• Clear, complete, documented specifications (e.g.,
  preconditions, post-conditions)
• Note this was not a complex, computing problem,
  but a deficiency of the software engineering
  practices in place

21
Software Engineering Preview

• Definitions
• Software Failures
• History and Context
• Software Development Myths
• Principles
• Software Development Processes

22
Brief History of SW Engineering

• Early on, software systems were few, rather small
  and developed by highly knowledgeable and
  motivated individuals
• In the late 1960s, larger systems were developed
  (e.g., OS 360) and difficulties were often
  encountered
• OS 360 the operating system of the IBM 360
  computer family

• Developing large software systems is not just a
  matter of
• pouring more resources into it
• putting more instructions together

• Problems
• High communication overhead
• Staff turnover
• Change management

• SW development was recognized as an engineering
  discipline

23
Historical perspective of SW Engineering

• Read the opening sentence in your text Dutoit
• The term software engineering was coined in 1968
  as a response to the desolate state of the art of
  development quality software on time and within
  budget. . More often that not, the moon was
  promised, lunar rover built and a pair of square
  wheels delivered.
• Braude The production of automobiles was
  revolutionized by Henry Fords observation that
  parts could be standardized, so that cars of a
  given model could use any instance of each
  required part. The reduction in cost made
  automobiles more affordable
• We now expect to reuse ideas, architectures,
  designs or code from one application to build
  others.
• Only modular applications have potentially
  reusable parts.
• Reusability of developer knowledge

24
Relationships with other Disciplines

• Programming languages
• Programming languages are the central tools used
  in the software development
• Compilers, support SE concepts (modularity
  features, specification vs. implementation)
• Operating systems
• First really large systems to be implemented,
• Many concepts used in Software Engineering were
  invented while trying to design OS
• levels of abstractions, layered architectures and
  virtual machines, facilities for handling
  concurrency, process management, memory
  management, etc.
• Data bases
• Notion of data independence, use data without
  knowing the representation of data, build in
  solution for concurrent access of data, etc.
• Theoretical models
• Specification (formal) representations (FSM, PN),
  denotational semantics to describe language
  semantics, complexity theory

25
Relationships with other Disciplines (cont.)

• Artificial intelligence
• New architectures and solutions to develop
  software solutions under the presence of
  uncertainty
• Help support certain programming tasks (program
  assistant), natural language processing
• Management science
• Project scheduling, resource planning, people
  management, project tracking, technology
  assessment
• Systems engineering
• Study of complex systems,
• Software is often the component of a much larger
  system (concepts such as objects and activities
  of the system, system boundary, etc)
• Software Engineering is a multi-disciplinary
  domain

26
Pfleeger, 1998
27
Software Engineering Preview

• Definitions
• Software Failures
• History and Context
• Software Development Myths
• Principles
• Software Development Processes

28
Management Myths

• State-of-the-art tools are the solution
• A fool with a tool is still a fool
• Getting behind schedule resolved by hiring
  additional programmers
• adding people to a late software project makes
  it later

29
Customer myths

• A general statement of objectives is sufficient
  to begin writing programs - we can fill in
  details later.
• Problems
• Poor up-front definition is the mayor cause of
  failed software efforts
• Detailed description of function, performance,
  interfaces, design constraints and validation
  criteria essential
• Thorough communication between customer and
  developer needed
• Changes can be easily accommodated because
  software is flexible
• Problem
• Impact of change varies with introduction time -
  late changes are expensive
• Changes happen as a fact of life
• Myths that lead to false expectations by the
  customer and result in dissatisfaction with the
  developer

30
The impact of change
Cost to change
31
Practitioners myths

• Once we write a program and get it to work, our
  job is done
• 50-70 of all effort after first delivery
• Until I get the program running, I really have
  no way in assessing its quality
• inspections reviews
• The only deliverable for a successful project is
  the working program
• documentation (users, maintenance), e.g., UML
  Analysis and Design Models

32
Software Engineering Preview

• Definitions
• Software Failures
• History and Context
• Software Development Myths
• Principles
• Software Development Processes

33
Characteristics of todays software development

• Development of large complex systems
• Software systems must fulfill the requirements of
  many users (or usage conditions)
• Number of persons involved in the development
  gtgtgtgt 1
• Distributed development is now commonplace
• Same place, same city (Kanata-Downtown)
• Same country (Ottawa-Vancouver), same continent
• Ottawa-Vancouver-England-Australia
• Software systems are expected to live long and be
  used by many people

34
What are the problems?

• Increased quality demands on software products
• High cost and time pressure
• Shorter time to market
• Coordination problems within the projects
• Scarce resources (e.g., qualified personnel)

35
Software Engineering Principles

• There are a number of general principles
  underlying and driving all software engineering
  techniques
• They aim at dealing with the inherent complexity
  of software and help achieve quality goals, e.g.,
  reliability, evolvability
• I will refer to these principles throughout the
  course.

• Rigor and formality
• Separation of concerns
• Modularity
• Abstraction

• Anticipation of change
• Generality
• Incrementality

36
Rigor and Formality

• More reliable products, control costs, increase
  our confidence in the product
• Rigor well-defined, repeatable, technically
  sound steps (based on method, technique)
• Formality, the highest degree of rigor, require
  the software process to be driven by mathematical
  laws
• No need to be always formal - tradeoff
• Rigor and formality apply to both the SW process
  and product
• The UML notation is an example of a (semi-)formal
  notation. It brings rigor to the way we do
  analysis and design.

37
Separation of Concerns

• Decompose a complex problem into simpler problems
• Concerns may be separated in time (e.g., life
  cycle phases), qualities, product views (e.g.,
  UML views), product parts (subsystems,
  components)
• However, many interdependencies among decisions
  in SE
• UML diagrams ? different views of the system

38
Modularity

• Software systems are decomposed into simpler
  pieces modules, components
• High cohesion and low coupling within/among
  components
• Allow reuse, easier understanding, team work,
  etc.
• Ideally, SW development could be based on
  composing reusable components

39
Abstraction

• Identify important aspects and ignore
  non-relevant details for the task at hand
• Equations, formalisms are forms of abstractions
  from reality, in all engineering disciplines
• Software specifications and design
  representations abstract away from programming
  details
• Programming languages abstract away from
  hardware details

40
Anticipation of Change

• Software undergoes change constantly
• How to account for potential change and limit the
  side effects?
• Impact on design strategy
• Layered architecture
• e.g., user interface, business or application
  logic, database management system
• Design patterns
• Manage versions and revisions (Configuration
  management)
• Process changes, e.g., personnel turnover
  Analysis and Design documentation

41
Generality

• General solutions mean more software reuse
• Software solutions general to a given application
  domain
• Different forms
• libraries, executable components, frameworks
  (e.g., JavaCC)
• Database management systems, spreadsheets, text
  processing and numerical analysis libraries
• Overhead, acquisition cost versus reliability,
  reuse
• Large, expanding COTS market (Components Of The
  Shelf) in the software industry

42
Incrementality

• Stepwise development gt early subsets of an
  application
• Early feedback from customers, users
• Initial requirements often not stable and fully
  understood
• Incrementality requires special care for managing
  documents, programs, test data, etc. of
  successive versions (configuration management)

43
Software Engineering Preview

• Definitions
• Software Failures
• History and Context
• Software Development Myths
• Principles
• Software Development Processes

44
The Software Process

• Software Engineering IEEE-93
• The application of a systematic, disciplined,
  quantifiable approach to the development,
  operation, and maintenance of software that is,
  the application of engineering to software.
• A Software Process is a series of predictable
  steps to follow to create a timely, high-quality
  result.
• Provided stability, control, organization
• Can be adapted to individual process needs (not
  rigid, can be agile)
• eg. only documentation relevant to product need
  be created

45
Survey of Some Process Models

• Waterfall Model
• Phased-Release Model
• Spiral Model
• Unified Process
• Agile Process
• All have the afore-mentioned activities and roles

46
Waterfall Model

• In principle, a phase should not start until the
  previous phase has finished (has been approved).
• Problems
• Real projects rarely follow the sequential flow
• Difficult for stakeholder to state all the
  requirements once and for all
• Stakeholders must have patience working version
  of software comes late in process.

Requirement definition
Specification
Design
Implementation
Integration deployment
Maintenance
47
Phased-Release Model

• Principle
• Linear sequences of the waterfall process, with
  each sequence producing an operational
  deliverable.
• The incremental model delivers a series of
  releases, called increments.
• Suggests that all requirements are finalized
  early during process.

Phase 1
Design
Implementation
Requirement definition
Integration deployment
Specification
Phase 2
Planning
Design
Implementation
Integration deployment
48
Spiral Model

• Incremental and Iterative
• Idea
• start by developing a prototype following a
  mini-waterfall model.
• Prototype serves to gather requirements.
• Each increment is reviewed and evaluated.

49
Unified Process

• Iterative and Incremental, Use-case driven,
  Architecture centric
• Phases
• Inception The core idea is developed into a
  product vision. We review and confirm our
  understanding of the core business drivers. We
  want to understand the business case for why the
  project should be attempted. Product feasibility
  and project scope.
• Elaboration The majority of the Use Cases are
  specified in detail and the system architecture
  is designed. "Do-Ability" of the project. We
  identify significant risks and prepare a
  schedule, staff and cost profile for the entire
  project.
• Construction Produces a system complete enough
  to transition to the user. The design is refined
  into code.
• Transition The goal is to ensure that the
  requirements have been met to the satisfaction of
  the stakeholders. Other activities include site
  preparation, manual completion, and defect
  identification and correction. The transition
  phase ends with a postmortem devoted to learning
  and recording lessons for future cycles.

50
Unified Process (cont.)
Activities
Time
51
Agile Model

• Key Assumptions
• Difficult to predict software requirements
• Difficult to predict analysis, design,
  construction, and testing
• Design and construction should be interleaved
• How can we design a process that can manage
  unpredictability?
• Process adaptability.
• Example Extreme Programming (XP)
• 4 phases Planning (stories), Design (prototype
  solutions), Coding (pair programming,
  re-factoring), Test
• The tests are the specification
• Communication paramount (small team,
  knowledgeable programmers?)

52
Software Lifecycle in Textbook
53
Before the Life Cycle Problem Statement

• The problem statement is developed with the
  client as a description of the problem addressed
  by the system at the highest level
• Other words for problem statement
• Statement of Work
• A good problem statement describes
• The current situation
• The functionality the new system should support
• The environment in which the system will be
  deployed

Breugge
54
Current Situation The Problem To Be Solved

• There is a problem in the current situation
• Examples
• The response time when playing letter-chess is
  far too slow.
• I want to play Go, but cannot find players on my
  level.
• What has changed? Why can address the problem
  now?
• There has been a change, either in the
  application domain or in the solution domain
• Change in the application domain
• A new function (business process) is introduced
  into the business
• Example We can play highly interactive games
  with remote people
• Change in the solution domain
• A new solution (technology enabler) has appeared
• Example The internet allows the creation of
  virtual communities.

Breugge
55
ARENA The Problem

• The Internet has enabled virtual communities
• Groups of people sharing common of interests but
  who have never met each other in person. Such
  virtual communities can be short lived (e.g
  people in a chat room or playing a multi player
  game) or long lived (e.g., subscribers to a
  mailing list).
• Many multi-player computer games now include
  support for virtual communities.
• Players can receive news about game upgrades, new
  game levels, announce and organize matches, and
  compare scores.
• Currently each game company develops such
  community support in each individual game.
• Each company uses a different infrastructure,
  different concepts, and provides different levels
  of support.
• This redundancy and inconsistency leads to
  problems
• High learning curve for players joining a new
  community,
• Game companies need to develop the support from
  scratch
• Advertisers need to contact each individual
  community separately.

Breugge
56
ARENA The Objectives

• Provide a generic infrastructure for operating an
  arena to
• Support virtual game communities.
• Register new games
• Register new players
• Organize tournaments
• Keeping track of the players scores.
• Provide a framework for tournament organizers
• to customize the number and sequence of matchers
  and the accumulation of expert rating points.
• Provide a framework for game developers
• for developing new games, or for adapting
  existing games into the ARENA framework.
• Provide an infrastructure for advertisers.

Breugge
57
Summary

• Software engineering is
• the engineering-like development of a software
  system
• as the solution to a users problem
• applying the right techniques / methods / tools
• Software engineering is necessary for developing
  complex but reliable software
• A good software engineering practice help to
  develop software in large teams