ICS 52: Introduction to Software Engineering

1
ICS 52 Introduction to Software Engineering

• Winter Quarter, 2002
• Dan Frost
• Lecture Notes
• Partially based on lecture notes written by
  Richard N. Taylor, David S. Rosenblum, and André
  van der Hoek. Duplication of course material for
  any commercial purpose without the written
  permission of the lecturers is prohibited.

2
Please define Software Engineering
Software Programs, procedures,
documentation associated with a computer
system - Multi-person -
Multi-version Engineering Designing and
carrying through by skillful or artful
contrivance. - Anticipating difficulties
- Defining an end - Making a plan -
Carrying out a plan
3
What is Software Engineering?

• A discipline whose aim is the production of
  fault-free software, delivered on-time and within
  budget, that satisfies the users needs.
  Furthermore, the software must be easy to modify
  when the users needs change. --
  Schach

4
The five Ps

• People - who develop, manage, and run the
  software
• Product - the software itself
• Project - the activity of creating the software
• Process - the manner in which the project
  proceeds
• Professionalism - the attitude of all involved

5
What is similar to Software Engineering?

• Throwing a party.
• Building a house or building.
• Getting married.
• Writing a textbook.
• Creating laws.
• Any complex project involving many people and
  multiple phases.

6
Software Engineering like Architecture?

• Architecture Requirements, sketch, blueprints,
  construction
• Strengths of analogy
• Phasing of activities
• User input and review, mostly for reqs and sketch
• User only minimally involved in construction
• Weaknesses of analogy
• Lots of domain knowledge on the part of the
  consumer
• 10,000 years of know-how
• Progress easily measurable

7
Software Engineering like Legislation?

• Legislation Commission, committee, congress,
  bureaucracy
• Strengths of analogy
• Intangible product
• Unforeseen consequences
• Difficult to measure progress
• Laws get "patched"
• Importance of careful reviews highlighted
• Weakness of analogy
• Difficult to test laws
• Legislation not executed predictably

8
Programming and Software Engineering
Programming
Software Engineering
9
Differences from Programming

• Software Engineering includes
• determining what to build
• eliciting requirements from user(s)
• organizing teams to build systems cooperatively
• software architecture
• analysis and design of modules
• testing
• lifecycle system engineering
• documentation

10
Matters of Scale

• Choose appropriate technique for problem
• elephant gun to kill a fly?
• fly-swatter to ward off an elephant?

11
Components of Software Engineering

• Science empirical studies theories
  characterizing aggregate system behavior (e.g.
  reliability)
• Management organizing teams, directing
  activities, correcting problems
• Human factors / psychology user task
  understanding and modeling ergonomics in user
  interface design
• Engineering tradeoffs, canonical solutions to
  typical problems, skill and art
• A common quip pick any two
• Good, soon, cheap
• Scalability, functionality, performance

12
The goal of Software Engineering

• High quality software -- what does that mean???
• Desirable software qualities
• Correctness - behaves according to specifications
• Reliability - can be depended on
• Robustness - behaves reasonably in
  unanticipated circumstances.
• Performance - uses resources economically
• User friendliness - human users find it easy to
  use
• Maintainability - conducive to corrective,
  adaptive, and perfective maintenance
• Repairability - conducive to correction of
  defects
• Evolvability, Reusability, Portability

13
BYPASS - parking permits at UCI

• Buy Your Permit Automatically Sans Standing in
  line
• Use touch tone phones, credit cards
• Permit manufacturer ships permits directly to
  student
• Design principles
• Dont ask customers for information already
  provided to other departments
• Dont ask customers for information they cant
  reasonably be expected to have
• Customers should not have to wait in line
• Eliminate or contract out paper handling
• http//www.parking.uci.edu/streamline.htm

14
Principles of Software Engineering

• Rigor and formality
• Separation of concerns
• Modularity
• Abstraction
• Anticipation of change
• Generality
• Incrementality

These principles apply both to product and to
process.
15
Separation of Concerns 1

• Divide problem into parts that can be dealt with
  separately.
• example automobile power flow systems from
  engine to drive train to tires.
• example networks (OSI) application
  presentation (byte-order, packing) session (data
  format) transport (TCP, buffer sizes) network
  (IP, routing) data link (packets with check sums
  and addresses) physical (twisted pair).
• example Java source, Java class files, Java
  virtual machine, operating system, machine
  language.

16
Separation of Concerns 2

• Separate in time
• Process Requirements, design, programming,
  testing, implementation . . .
• Product e.g. Tele enter rooms into system, then
  quarters courses, later students select classes
• Separate qualities
• Product example correctness and efficiency
• Process example management, technical, support,
  artistic, marketing . . .
• Management issues
• separation of responsibilities, expertise

17
Modularity

• Dividing into simpler parts
• Permits separation of concerns
• deal with each module in isolation (ignore rest
  of system)
• deal with overall system (ignore module details)
• Promotes reuse
• Promotes understandability
• Modules should have high cohesion and low
  coupling
• high cohesion all elements within are strongly
  related
• low coupling modules are largely independent of
  each other

18
Abstraction

• Ignore details, identify important aspects
• Divide problem into relevant parts and irrelevant
  details, and ignore the irrelevant parts (more
  important and less important with respect to the
  current set of problem solving objectives)
• divide and conquer vertically
• example programming languages
  (count increment)

19
Why Software Engineering?

• Save money -- make money!
• Complex systems are interesting
• Develop better products
• More helpful to users
• More reliable
• Develop products better
• Faster time to market
• More maintainable

20
Software Process

• A set of activities and associated results which
  lead to the production of a software process.
• Four fundamental activities
• Software specification
• Design and implementation
• Validation
• Evolution
• Think about differences for generic
  (shrink-wrapped) and bespoke (custom-made).

21
Product and Process

• Products can be sold, bring in revenue
• Process retained by company
• Company culture
• Determines key properties of your products
• A key factor in the cost / reliability /
  up-to-dateness of the product
• E.g. Just-in-time, Quality is job 1
• Which is the more important product or process?

22
Some more software activities

• Assigning tasks to programmers.
• Canceling the project.
• Not canceling the project.
• Maintaining a list of known bugs.
• Deciding what programming language to use.
• Training users.
• Planning the system before programming begins.
• Writing documentation.
• Determining that the users needs are being met.
• Determining that meeting the users need is
  cost-effective.
• Deciding to build a new software system.

23
Process and Product

• Which is possible?
• Good process --gt good product
• Good process --gt bad product
• Bad process --gt good product
• Bad process --gt bad product
• In studying Software Engineering, we focus on
  both process and product

24
Processes

• The goal of a production process is to make
  production reliable, predictable, and efficient.
• Software production is intellectual, not amenable
  to automation
• The shoemakers children go barefoot.
• Software is malleable, unstable, constantly
  changing
• Constraints on a process
• Time, Cost, Qualities (repeatable? teachable?)

25
Software Production Process

• All steps from initial idea to delivery,
  maintenance, final retirement.
• Software has a life cycle.
• A software process model is an abstraction of the
  process.
• Waterfall model
• Evolutionary development
• Formal development
• Re-use based development
• Spiral
• More later

26
Requirements Engineering (the Activity)

• System engineering v. software engineering
• What role does software play within the full
  solution?
• Trend more in software
• 21st century The Software Century
• Contract model v. participatory design
• Contract carefully specify requirements, then
  contract out the development. Can contract out
  requirements. RFP
• Participatory customers, users, users' agents,
  and software staff work together throughout
  development

27
Several types of requirements

• User requirements
• What services the system will provide
• System requirements
• More detail, more precise
• May serve as a contract
• Software design specification
• Oriented to implementation team
• Classes, modules, data structures, algorithms

28
Requirements Specification (the Document)

• Purpose
• Serve as the fundamental reference point between
  builder and buyer/user/"consumer " (contract)
• Define capabilities to be provided, without
  saying how they should be provided
• Define constraints on the software to guide the
  implementers
• e.g. performance, platforms, language

29
Requirements Specification (the Document)

• Characteristics
• Unambiguous
• Requires precise, well-defined notations/language
• Complete any system that satisfies it is
  acceptable
• Verifiable (testable)
• No implementation bias (external properties only)
• "One model, many realizations"

30
Lifecycle Considerations for Req. Document

• Serve as basis for future contracts, new versions
• Reduce future modification costs
• Identify items likely to change
• Identify fundamental assumptions
• Structure document to make future changes easy
• e.g. have a single location where all concepts
  are defined

31
Requirements requirements

• Specify only external system behavior
• Specify constraints on implementation
• Easy to change
• Serve as a reference during maintenance
• Record forethought about system lifecycle
• Characterize responses to undesired events

32
Why spend a lot of time on Requirements?
One of the best-known folk theorems of software
engineering is that 60 to 75 of
conventional software projects are either never
completed or rejected by their intended users.
If that range is anywhere near true (and Ive
never met a manager of any experience who
disputes it) then more projects than not are
being aimed at goals which are either (a) not
realistically attainable, or (b) just plain
wrong. -- Eric S. Raymond, The Cathedral and The
Bazaar
33
Requirements Volatility
Source David Alex Lamb, Software Engineering,
Planning for Change Prentice Hall, 1988
34
Requirements Specification - Contents

• Application context
• Describe the situation in which the software will
  be used. How will the situation change as a
  result of the project?
• Identify all things (objects, processes, other
  software, hardware, people) that the system
  affects.
• Develop an abstraction for each of those things,
  characterizing their properties and behaviors
  which are relevant to the software system.
  ("World model.")
• Identify likely changes.
• Identify assumptions.

35
Requirements Specification - Contents

• Functional requirements ("features")
• Identify all functions, features, objects,
  information, etc. that the system provides.
• Develop an abstraction for each of those
  concepts, characterizing their properties and
  functions which are relevant to the user.
• What is the system supposed to do?
• What information does the system need?
• What is supposed to happen when something goes
  wrong?

36
Requirements Specification - Contents

• Performance requirements speed, space
• Environmental requirements platform, language,
  ...
• Subsets/supersets -- versions, implementation
  order
• Expected changes and fundamental assumptions
• Definitions reference documents
• Acceptance test plan

Always a thorny issue how completely should the
user interface be specified?
37
Requirement Specification

• Functional approach
• List of features
• Input - output pairs
• Potentially a shopping list
• World model approach
• Object oriented
• Place the system in context
• Organizes the document

38
Techniques for Requirements Analysis

• Conduct interviews
• Build and evaluate prototypes
• Identify important objects
• Construct glossaries
• Separate concerns
• Focus on structure
• Abstraction and hierarchical decomposition
  modularity
• Use precise notation (be careful with diagrams!)
• Ask yourself
• Is it testable? Complete? Consistent?

39
Different Circumstances, Different Techniques

• Finite state machines
• telephone systems
• coin-operated machines
• Numerical systems
• matrix inversion package
• Rapid Application Development
• based on high-level languages or database
  languages
• drag and drop, visual form design, choices
  selected from lists
• typically used by non-technical users (who
  havent studied Software Engineering!)

40
Acceptance Test Plan

• Part of the requirements specification?
• An operational way of determining consistency
  between the requirements specification and the
  delivered system
• If the system passes the tests demanded by this
  plan, then the buyer has no (legal, moral) basis
  for complaint
• Develop a plan for testing
• Functional properties
• Performance properties
• Adherence to constraints

41
V-Model of Development and Testing Activities
Specify Requirements
Execute System Tests
Requirements Review
System/Acceptance Tests Review
Develop System/Acceptance Tests
Design
Execute Integration Tests
Integration Tests Review/Audit
Design Review
Develop Integration Tests
Execute Unit Tests
Code
Unit Tests Review/Audit
Code Review
Develop Unit Tests
42
Incremental Development of Tests

• Acceptance test plan (and tests)
• develop during requirements analysis
• Integration test plan (and tests)
• develop during system architecture and detailed
  design specification
• Unit test plan (and tests)
• develop during implementation