Software Engineering

1
Software Engineering

• "Programming today is a race between software
  engineers striving to build bigger and better
  idiot-proof programs, and the Universe trying to
  produce bigger and better idiots. So far, the
  Universe is winning."    
•  Rich Cook.

2
Objectives

• Review software engineering functions
• Measurable, predictable, repeatable
• Review the system development life cycle (SDLC)
• Waterfall Model
• Incremental Development Model
• Review program verification and validation
• Testing and debugging techniques
• Reading Reference Brookshear Chapter 6

3
So we know about

• Computer Fundamentals
• Overview of what computers are made of.
• How to represent data Binary Encoding
• How to represent instructions Machine Language
• What CPU does in each machine cycle Program
  Execution
• OS
• How each program becomes a CPU process that is
  scheduled and managed
• How memory and files are managed
• How external devices are controlled and managed
• Components of an Algorithm
• Values, Variables, Instructions, Sequence,
  Selection, Iteration, Procedure, Documentation
• Programming Language (Chapter 5, TBD next)
• Three main programming paradigms
• Traditional Programming Concepts
• Variables, Data Types, Data Structure,
  Assignment, Selection, Iteration
• So we know how to program. Is that sufficient to
  develop reliable and efficient software for all
  purposes?

4
Software Engineering Definition

• Software A method of implementing large projects
  in a reliable and efficient manner
• Examples software for banking, stock exchange,
  space probe control, toll charge, operating
  system, games
• Engineering A formal structured process with
  standard set of tools and techniques
• A formal structured process of developing and
  implementing large software projects using
  standard set of tools and techniques.
• Important goal zero error tolerance and 100
  accuracy

5
Software Engineering problems

• Software Engineering requires a clear
  understanding of the problems encountered when
  building large software systems
• Complete comprehension of the system is beyond
  the capabilities of any single person
• Several teams of people are required to
  coordinate and implement the project
• Long periods of time are required to release a
  reliable product

6
Software Engineering Framework

• Software Engineering seeks to build an
  engineering framework for software development
• Measurable
• Quantitative processes with practical measures
• Predictable
• In terms of resource requirements, schedule and
  reliable results
• Repeatable
• Able to perform over and over by simply following
  the established set of rules and conditions

7
Software Engineering Commonality

• Software Engineering is somewhat like other
  engineering disciplines. For example, A bridge
  chief engineer
• spends a lot of time surveying the area and
  drawing plans first
• learning about what raw materials he can reliably
  use (steel, concrete etc)
• designing the bridge to the last minute detail
• Supervising the actual construction
• Once the bridge is built the job is done

8
Software Engineering Singularity

• Software Engineering is quite unlike other
  engineering disciplines. For example, A bridge
  engineer
• Has standardized tools for building, that have
  been tested and proven to be reliable
• Has specific tools and techniques for measuring
  the strength and reliability of the system being
  built
• Cannot go back and change the design once the
  bridge is built

9
Software Engineering is Unique

• Software has unique features, therefore, software
  engineering is distinct from other engineering
  disciplines
• Pre-fabricated components.
• Zero tolerance to error
• Re-usable components.
• Pre-fabricated components
• Used regularly in most engineering
• Off the shelf parts for automobiles
• Requires high degree of standardization among
  components to achieve interchangeability
• Software tends to be unique
• Little use of standardized components

10
Software Engineering is Unique

• Tolerances
• Traditional engineering disciplines are concerned
  about precise tolerances
• Not every instance of a standardized part is
  identical, but all are good enough, e.g. within
  a specified tolerance
• Software engineering is concerned about the
  accuracy of the result
• Programs are expected to work 100 of the time,
  not 99.9999999 of the time

11
Software Engineering is Unique

• Measurements
• The properties of a traditional engineering
  product are measurable
• Physical dimensions of an object
• Mean time between failures of a machine
• The properties of software are very difficult to
  measure
• Software doesnt wear out
• Software doesnt have physical dimensions
• Software either gets the job done right or it
  doesnt!

12
Software Engineering is non-traditional

• Software Engineering lacks the scientific
  foundation found in traditional engineering
• Traditional engineering is based on scientific
  laws of physics, chemistry, and other fields
• Software engineering has no such corresponding
  fundamental science

13
Software Engineering Studies

• Practical
• Some software engineers focus their efforts on
  developing methodologies that can help
  contemporary computer professionals
• Theory
• Some software engineers focus their efforts on
  finding underlying principles upon which future
  methodologies can based

14
SLC

• Software Life Cycle
• Software never wears out
• Software is created according to some
  specification
• Software is used as many times as needed
• Software is modified if the specifications change
• Software is retired if the specifications change
  too much to permit effective modification

15
SLC
Development
Use
Modification
16
SDLC

• Software Development Life Cycle
• The details of the process used to develop
  software, e.g. a subset of the SLC
• Often consists of these steps
• Analysis (problem definition and solution
  statement)
• Design (algorithm development)
• Implementation (creating a program)
• Testing (making sure the program works)

17
Components of SDLC

• Define the problem clearly
• Analyze the problem

• Design an algorithm
• top-down / bottom-up design

• Code (Implement) the algorithm
• Test the code

• Document the system

18
Development ApproachWater-Fall Model (Old)
Analysis
Design
Implement
Test

• Requires that each stage be entirely complete
  before beginning next stage.

19
Traditional SDLC Analysis

• Analysis
• Identify the needs of the user
• Interviews or market analysis
• Establish functional specifications
• What is the input data?
• What is the required output?
• What are the performance requirements?
• Analysis focuses on what needs to happen and sets
  the goals of the system

20
Analysis Techniques

• Read the problem very carefully
• Do you have enough information?
• Ask questions
• Need to know
• Output
• Input
• Processing

21
Analysis Output

• Identifying the output is critical
• output determines input
• Identify nouns and adjectives
• Underline or circle important information
• Print the name
• Display the order total

22
Analysis Input

• Determined by the output
• What is needed?

23
Analysis Processing

• What steps are required to produce the output
  given the input?
• Look for verbs (or mathematical expressions)
• Calculate, Add, Subtract, Look Up, Average

INPUT
PROCESSING
OUTPUT
24
Analysis Example 1

• Identify the output, input, and processing
• Calculate average temperature for a day
• Calculate annual commission for a salesman based
  on sales
• Sales gt 50,000 ? 10 commission
• Sales gt 10,000 ? 5 commission
• Sales lt 10,000 ? 1 commission

25
Defining Diagram Table

• A table that describes the basic operations of
  your program
• Processing details are not shown
• These are documentation and thinking tools for
  humans, not precise specifications

26
Defining Diagram for Example 1
27
Analysis Example 2
A program is required to read in a customers
account balance (current at the beginning of the
month), a total of all the withdrawals the
customer made for the month and a total of all
the deposits the customer made for the
month. Total Deposits minus Total Withdrawals is
subject to 1 federal tax each month     Calculate
and display the customers new monthly account
balance.
28
Example 2 One Possible Answer
29
Requirements Analysis

• Purpose Perform Requirements Analysis
• Who Groups of 2-3
• Task Develop defining diagrams for the following
  problem
• Product A defining diagram
• Time 5 minutes

30
In Class Exercise
Each day the sales made during the day at the
BYTE CO. are totaled. The total sales amount is
recorded on a sheet of paper along with the
date.   You have been given a stack of these
papers and have been asked to count the total
number of days in which the total sales for the
day was equal to or below 1,000.
31
Traditional SDLC Design

• Design
• What steps are required to produce the output
  from the specified input?
• What are the algorithms that will be used?
• How will the process be broken down into smaller
  steps?
• Design focuses on how the system will accomplish
  the specified goals, and, on the structure of the
  system

32
Modularization

• Jargon for dividing a large program into smaller,
  more manageable pieces called routines,
  functions, procedures (and many other names)
• Requires understanding how to break a large task
  into smaller tasks

33
Why Create Routines?

• Reduces complexity
• Break a big problem into smaller programs
• Limits the effects of changes
• Makes code easier to maintain
• Isolate mistakes and debugging
• Avoid duplicating code
• Allows for ability to share and reuse code

34
Structure Charts

• A structure chart is a graphical way of
  representing a functional design
• The chart shows the structure or hierarchy of
  your program, i.e. which functions call which
  other functions
• All functions in the program are listed

35
Calculate Wages

• Basic calculation
• wage hours_worked 12
• Function
• Calculate wages for all employees using the wage
  calculation

36
Structure Charts
Process wages for all employees
Main routine calls a sub-routine to get its task
done
Calculate a wage for one employee
The sub-routine that does the actual wage
calculation, one employee at a time, when called
37
Structure Charts

• Design process is top-down
• Processes on the upper levels call lower level
  processes never the other way around
• Good function names often will be a verb followed
  by a noun
• Get_Input
• Calculate_Invoice

38
Modularity

• Top-down analysis and design.
• Break problem down into manageable sub-problems
  (or modules)
• Example

Select people in address book
Send invites
Contact invited people
Hold a party
Decide on menu
Prepare food
Go shopping
Cook
Find songs on CD
Select music
Create a new CD with selections

39
Modularity pictorial charts

• Top-down analysis and design.
• The manageable sub-tasks (a.k.a modules) are
  compiled into a top-down chart with specific
  structure.
• The modules are given a specific name based on
  their function, conventionally, a verb_Noun
  format and enclosed in rectangles
• They are laid out top to bottom with connecting
  lines indicating the flow of subtask

40
Modularity Structure Chart
Plan a party
Prepare food
Select music
Decide on menu
Go shopping
Cook
Create shopping list
Drive to shops
Buy groceries

• Pictorial representation of a modular structure
• each module represented by a rectangle
• arrows represent dependencies between modules

41
Golden Rule 1
Design Top-Down, but always build Bottom-Up.

• Code and test the simplest components first.
• Test each component before using them to make
  sure they work
• Then use those components to build more complex
  components.

42
Coupling

• Modular design is effective as long as changes in
  one module does not, inadvertently or otherwise,
  affect other modules
• i.e., we are looking to maximize independence
  between modules
• Coupling refers to interdependence among
  routines/modules
• Independent routines that do not share variables
• Interdependent routines that share variables
• Degree of interdependence reflects degree of
  shared data used by the routines
• Loosely coupled routines share little or no data

43
Structure Charts vs. Class Diagrams

• Structure charts are for representing procedural
  organization
• Class diagrams (in OOP) are for representing
  classes, objects and the relationships between
  the classes.
• Standard notational system has been developed for
  representing OO design
• Example UML Unified Modeling Language

44
Coupling Control and Data

• Working against the notion of module-independence
  is that there must be some connection between
  modules for them to form a coherent system.
• The links and dependencies between modules are
  classified as
• Control coupling
• when one module passes control to another
• Examples function call, return
• Data coupling
• sharing of data between modules.
• Examples function parameters, return values

45
Example Data Coupling
Structure Chart showing Data Coupling for
Internet Mail Order business
Oversee website
Customer Info
Completed order
Customer Info
Completed order
Process Incoming Customer Order
Process Order
Oversee Browsing
46
Another Example Data Coupling
Structure chart with labels showing data coupling
goShopping (place, menu ) list
createGroceryList( menu ) driveTo (place )
buyItems (list )
place
menu
goShopping
list
list
place
menu
createGroceryList
buyItems
driveTo

47
Ideal Coupling

• Aim maximize module independence by minimizing
  coupling.
• Use of global variables (not constants) is a form
  of implicit data coupling dangerous!
• It is NOT recommended to have global variables in
  your program.

48
Object Oriented Approach Advantage

• Minimizing Data Coupling is inherent in OO
  approach
• Collect routines, methods that manipulate a
  particular data item into a single module viz.,
  the object
• Inter module coupling then becomes inter object
  communication, implemented via control coupling

49
Cohesion

• Cohesion
• Refers to how closely the statements of a
  function are related, i.e. is the function
  focused at only one activity?
• Module strength is another term for cohesion the
  aim always is to have high modular cohesion

50
Cohesion

• Internal binding within function, i.e. degree of
  relatedness of a modules internal parts.
• Logical or Weak Cohesion
• Internal elements perform activities that are
  logically similar. (E.g.. I/O function
  communication with outside world)
• Functional or Strong Cohesion
• all parts or elements are geared towards the same
  single activity
• Aim high intra-module cohesion

51
Example Cohesive
Procedure Contact (company, message, mode )
if (mode is by fax) sendFax ( company ,
message) else if (mode is by email)
sendEmail ( company , message)
Cohesive.
52
Example Non-Cohesive
Procedure Contact ( company , message , mode )
if (mode is by fax) sendFax ( company
, message) else if (mode is by email)
sendEmail ( company , message)
printAddressBook ( )
Not cohesive.
53
Example Internet Mail Order ? Order Form
Processing
54
Golden Rule 2
Modules in a well-structured program are highly
cohesive and loosely coupled.

• The size of the data coupling corresponds roughly
  to the level of the module in the hierarchy.

55
Dataflow Diagrams (DFD)

• Pictorial representation of data paths
• origin (data source, could be external)
• destination (data sink, data storage)
• processing points (location of data manipulation,
  modules)
• Various symbols have specific meaning
• Bold double line for data source/sink
• Arrows for data paths
• Circles/bubbles for locations of data
  manipulation
• See fig 6.10, page 285, text book.

56
Dataflow diagrams (DFD)

• Emphasize the data (information) to flow through
  system.
• (rather than procedures to be executed as is
  done by structure charts)
• Though DFD is designed with imperative paradigm
  in mind, it works well for Object Oriented
  approach as well.
• By following data paths, discover where data
  units are merged, split, or altered.

57
Dataflow diagram showing data paths
Recipes
Prepare Menu
Menu
Name, Address
Address
Prepare Grocery List
List
Cost
Shop
58
Arrows Data Paths
Recipes
Prepare Menu
Menu
Name, Address
Address
Prepare Grocery List
List
Cost
Shop
59
Recipes
Prepare Menu
Menu
Name, Address
Address
Prepare Grocery List
List
Cost
Shop
Boxes External Data Sources and Sinks
60
Circles, Ovals (Bubbles) Processing Points
Recipes
Prepare Menu
Menu
Name, Address
Address
Prepare Grocery List
List
Cost
Shop
61
Heavy Straight Lines Data Storage
Recipes
Prepare Menu
Menu
Name, Address
Address
Prepare Grocery List
List
Cost
Shop
62
You (the Processor) are not included in the
diagram! Also, it represents the data and its
processing, but, not the modules as in structure
chart.
Recipes
Prepare Menu
Menu
Name, Address
Address
Prepare Grocery List
List
Cost
Shop
63
DFD Quick Overview
This diagram is from SmartDraw.com
64
DFD Example
This diagram is from SmartDraw.com
65
Self-Study DFD Insurance Claims Example
This diagram is from SmartDraw.com
66
Entity-Relationship Diagram

• Another tool a pictorial representation of
  entities within the system and their relationship
• One-to-one
• One-to-many
• Many-to-many
• See fig 6.11 and 6.12 page 286, text book
• This pictorial tool is very useful in designing
  Relational Database Management Systems (RDBMS)

67
Traditional SDLC Implementation

• Implementation
• Implementation consists creating programs to run
  in a specific computer environment
• Programming language
• Operating system
• Hardware components
• Users

68
Traditional SDLC Testing

• Testing
• Testing is done to ensure that the results is
  what is needed
• Verification testing is done to ensure that the
  program adheres to the functional specifications
• Validation testing is done to ensure that the
  functional specifications meet the needs of the
  user

69
Testing

• Glass Box testing techniques utilize a knowledge
  of program structure and design to identify
  specific conditions to be tested
• Black Box testing techniques focus on input and
  output, and ignore the internal details of how
  the program functions

70
Black Box Testing

• Black box testing is concerned with program
  behavior from a user perspective
• Functional specifications are used to identify
  appropriate test data
• Boundary value analysis
• Condition testing
• Redundancy testing
• The programmer specifies in advance what output
  is expected for each set of input data

71
Black Box or Functional Testing

• A software testing technique where the internal
  workings of the item being tested are not known
  by the tester.
• The tester only knows the inputs and what the
  expected outcomes should be and not how the
  program arrives at those outputs.
• The tester does not ever examine the programming
  code and does not need any further knowledge of
  the program other than its specifications.

72
Black Box or Functional Testing

• The advantages of this type of testing include
• The test is unbiased because the designer and the
  tester are independent of each other.
• The tester does not need knowledge of any
  specific programming languages.
• The test is done from the point of view of the
  user, not the designer.
• Test cases can be designed as soon as the
  specifications are complete.
• The disadvantages of this type of testing
  include
• The test can be redundant if the software
  designer has already run a test case.
• The test cases are difficult to design.
• Testing every possible input stream is
  unrealistic because it would take a inordinate
  amount of time therefore, many program paths
  will go untested.

73
Black Box Testing Boundary value analysis

• Boundary Value Analysis is to be used where an
  input domain is specified.
• Test cases will be created to test the boundary
  of the domain.
• Both boundary values are tested, as well as
  values directly above and below these.
• The purpose of Boundary Value Analysis is to test
  for off-by-one or fencepost errors where the
  whole domain may not be covered.
• Example For the input domain of 1,2,3,4,5,6,7,
  it would be necessary to test with the values
  0,1,2,6,7 and 8 to satisfy Boundary Value Analysis

74
Black Box Testing Redundant Conditional Checks

• Redundant Checks make sure you catch the odd
  functional behavior in more than one possible
  situation, revealing mismatches
• Verify each component and then verify the entire
  software this seems redundant, but, has greater
  probability of catching major errors
• Often, choosing test cases is very challenging
  and it will not be clear whether the selected
  test cases can uncover a particular error
• Does not discover extraneous use cases
  ("features")

75
Black Box Test Plan

• A test plan for a black box test consists of
  paired input and output specifications, usually
  in table form

76
Black Box Testing Procedure

• Identify test data from the programs functional
  specification
• Calculate expected results
• Run the program for each set of test data
• Record the actual results
• Verify expected and actual results match

77
Glass Box Testing

• Glass box testing uses a similar test plan, but
  input data is derived using a knowledge of how
  the program works
• Pareto analysis is used to test the most
  error-prone sections of the program
• Basis path testing is used to ensure that every
  instruction in the program is executed
• But not every possible sequence

78
Glass Box/White Box/Clear Box/Open Box

• A software testing technique where explicit
  knowledge of the internal workings of the item
  being tested are used to select the test data.
• Unlike Black Box testing, white box testing uses
  specific knowledge of programming code to examine
  outputs.
• The test is accurate only if the tester knows
  what the program is supposed to do. He or she can
  then see if the program diverges from its
  intended goal.
• White box testing does not account for errors
  caused by omission, and all visible code must
  also be readable.
• For a complete software examination, both white
  box and black box tests are required.

79
Glass Box/White Box/Clear Box/Open Box

• The focus is on Thoroughness. Every statement in
  the component is executed at least once.
• Four types of white-box testing
• Statement Testing
• Loop Testing
• Path Testing
• Branch Testing

80
Beta Testing

• Beta Testing
• This method is increasingly in use nowadays for
  shrink-wrapped software aimed at the PC market.
• The goal is to get real user feedback on how the
  software performs and what needs to be improved
  like better UI, or, more options in the menu etc.

81
Beta Testing

• Beta test is the second phase of software testing
  in which a sampling of the intended audience
  tries the product out.
• Beta is the second letter of the Greek alphabet,
  Alpha is the first.
• Originally, the term alpha test meant the first
  phase of testing in a software development
  process like unit testing, component testing,
  and system testing.
• Beta testing can be considered "pre-release
  testing."
• Beta test versions of software are now
  distributed to a wide audience on the Web partly
  to give the program a "real-world" test and
  partly to provide a preview of the next release.

82
Documentation

• System Documentation explains the internal
  technical details of how the software is
  implemented so that it can be maintained later in
  its life cycle
• User Documentation explains the features of the
  software from a user perspective to serve as a
  manual for the non-technical user.

83
Provable Programs

• Some programs can not be empirically tested
  before the real execution
• Calculate the largest prime number
• Land a spacecraft on Mars
• Control a heart pacemaker

84
Provable Programs

• Some programming languages have been developed to
  allow programs to be proven using mathematical
  techniques
• Inductive or deductive proof techniques
• More than a language issue
• Program verification requires proving the
  language implementation is correct
• Provability is an area of ongoing research

85
Traditional SDLC Advantage

• When using a traditional SDLC, it is far cheaper
  to fix a problem in earlier phases than in later
  phases
• Problems found during analysis often can be
  resolved for less than 1/1000th the cost that
  would be required if the same problem were
  discovered during testing
• The best way to fix a bug is to avoid a bug

86
Traditional SDLC Disadvantage

• However, validation problems are often undetected
  until the user sees the system during testing
• User requirements may have been misunderstood
• Users may have been mistaken about their
  requirements
• Requirements may have changed during development
• Or any number of other issues may arise
• When waterfall model is not good anymore, what do
  we do?

87
Non-Traditional SDLC

• Several attempts have been made to address
  problems perceived with the traditional system
  development processes using the waterfall model
• Incremental Development
• Rapid Prototyping
• Computer-Aided Software Engineering

88
Incremental Development Model
Analysis
Design
Implement
Test

• Increments from simplified version with limited
  functionality to complete system.
• At each stage prototype.

89
Incremental Development

• Incremental development builds a complex system
  piece by piece
• Initial release of the product has a few
  functions that have been fully implemented
• Additional functions are added over time
• The early functions allow some aspects of the
  users requirements to be met while waiting for
  the entire system
• The users can provide on-going feedback based on
  experience with the early versions

90
Prototyping

• Construction of simplified version of parts of
  the proposed system that can be analyzed before
  further development.
• Types of items that can be prototyped
• screen and report format,
• database and file structures,
• system protocols, etc.

91
Rapid Prototyping

• Prototype systems are incomplete versions of the
  entire system
• All functions are partially implemented so that
  the user can get a feel for how the final
  system will work known as the skeletal system
• Prototypes allow a fine tuning of user
  requirements at little cost
• As and when the skeletal system is refined and
  upgraded, it is like adding body to the skeletal
  system, till final full form is reached.

92
Open-Source Development

• A rather popular ad hoc technique for developing
  software
• A form of evolutionary prototyping
• public evolutionary prototyping is a better
  description, actually
• It is an extension of beta-testing (See section
  6.6 textbook page 289)
• Rather than beta-testers reporting the problem,
  they suggest fixes or patches for it that is
  open code and available for all
• Example Linux OS

93
Common aspects of SW Engineering

• Tasks
• project planning (cost, schedule, personnel)
• project management
• documentation
• prototyping and simulation
• interface design
• programming
• testing
• Useful Tool Computer-Aided Software Engineering
  (CASE) Tools

94
CASE

• Computer Aided Software Engineering
• CASE procedures utilize special software tools to
  provide integrated project management,
  requirements analysis, and implementation
• CASE software can often generate source code
  based on a precise specification of user
  requirements, essentially automating much of the
  design and implementation phases

95
Summary

• Modularity is crucial for developing large
  software projects
• Defining Diagram is a useful Analysis tool
• Structure charts and dataflow diagrams are useful
  Design tools
• Golden Rule 1Design top-down, but build
  bottom-up
• Golden Rule 2 Design Highly Cohesive and
  Loosely Coupled modules
• Incremental Model for SDLC is popular as we build
  incrementally, using prototypes, with provision
  to go back and revise/redesign the previous stage