Software Engineering

Practice is the collection of concepts ,

principles, methods, and tools that a
software engineer calls upon a daily
basis.
The Essence of Practice
Understand the problem (Communication
and analysis)
1. Plan a solution (modeling and software
design)
2. Carry out the plan (code generation)
3. Examine the result for accuracy (testing
and quality assurance)
UNDERSTANDING THE PROBLEM

 Who has a stake in the solution to the problem?

 What are the unknowns?
 Can the problems be compartmentalized?
 Can the problem be represented graphically?
PLAN THE SOLUTION

 Have you seen similar problems before?

 Has a similar problem been solved?
 Can subproblems be defined?
 Can you represent a solution in a manner that leads
to an effective implementation?
CARRY OUT THE PLAN

 Does the solution conform?

 Is each component part of the solution probably
correct?
EXAMINE THE RESULT

 Is it possible to test each component part of the

solution?
 Does the solution produce results that conform to the
data, function, features, and behavior that are
required?
CORE PRINCIPLES

 The reason it all exists. Provide value to the user.

 Maintain the vision.
 What you reproduce , someone else will have to
consume. (implement knowing someone else will
have to understand what you are doing)
 Be open to the future
 Plan ahead for reuse
 Think!
COMMUNICATION PRACTICES

 Listen
 Prepare before you communicate
 Someone should facilitate the activity
 Face to Face communication is best
 Take notes and document decisions
 Strive for collaborations
 Stay focused
 If something is unclear, draw a picture
 Once you agree, move on. If you can’t agree, move
on.
 Negotiation must be win win.
PLANNING PRACTICE

 Understand the scope

 Involve the customer in planning
 Recognize that planning is iterative
 Estimate based on what you know
 Consider the risk
 Be realistic.
 Adjust granularity as you define the plan
 Define how you intend to ensure quality
 Describe how you intend to accommodate change.
 Always keep track of the plan and make changes as
required.
 WHH principles

Why is the system being developed ?
 What will be done ?
 When will it accomplished ?
 Who is responsible for the function ?
 Where are they organizationally located ?
 How will the job be done technically and managerially ?
 How much of each resource is needed ?
ANALYSIS MODELING PRACTICE

 The information domain must be understood

 Functions of the software must be defined clearly
 Behavior of system must be defined clearly
 The models that depict information, function, and
behavior must be partitioned in a manner that
uncovers detail in a layered fashion.
 Analysis task should move from essential information
toward implementation detail.
 Analysis should be clear enough to convert it into
design model
DESIGN MODELING PRACTICE

 Design should be traceable.

 Consider the architecture of the system to be built.
 Design of data is as important as processing
functions.
 Interfaces must be designed with
 User interfaces should be tuned to needs of the end-
user.
 Component level design should be functionally
independent – Single mindedness
 Components should be loosely coupled
 Design representations should be easily
understandable – contradicts formal mathematical
 Design is iterative
 Construction Practices
CODING PRINCIPLES
PREPARATION

 Understand the problem

 Understand basic design principles and concepts
 Pick a programming language that meets the needs
of the software being built
 Select a programming environment that makes you
work easier
 Create sets of unit tests
CODING PRINCIPLES
CODING

 Select data structure that meet the needs of design

 Keep conditional logic as simple as possible
 Use meaningful variable names
 Follow local coding standards
 Write code that is self-documenting,
 Create a visual layout, i.e. indenting, better have a
tool do it for you
CODING PRINCIPLES
VALIDATION

 Conduct a code walkthrough when appropriate

 Perform unit tests, correct errors you uncovered
 Refactor code
TESTING PRINCIPLES
Testing is a process of executing a program with the
intent of finding an error
A good test case is one that has a high probability of
finding as-yet undiscovered error
A successful test case is one that uncovers an as-yet
undiscovered error.
PRINCIPLES
All tests should be traceable to customer requirements
 Test should be planned long before testing begins
 80% of all errors uncovered during testing is
traceable to 20 percent of all program components
 Testing should begin “in the small” and progress
toward testing “in the large”
 Exhaustive testing is not possible.
DEPLOYMENT PRINCIPLES

 Customer expectations for the software must be

managed
 A complete delivery package should be assembled
and tested.
 A support regime must be established before the
software is delivered
 Appropriate instructional material must be provided
to end-users.
 Buggy software should be fixed first, delivered later.
 Requirements Specification

– Goal
 To provide a representation of the software
for the customer’s review and approval
• What will be the business impact of the software ?
• What the customer wants exactly ?
• How end user will interact with the system ?
– Developed as a joint effort between the
developer and the customer
– Serve as basis for review for both
customer and developer
– Culmination of requirements analysis
 Specification Principles

– Separate functionality from

implementation
– Process-oriented systems specification
language is required
– Specification must encompass the
system of which the software is a
component
– Specification must include the
environment in which the system
operates
 Specification Principles

– System specification must be a cognitive

model
– Specification must be operational
– System specification must be tolerant of
incompleteness and augmentable
– Specification must be localized and
loosely coupled
Software Requirements Specification (SRS)

 Includes Requirements Definition &

Specification
 Principles: [Heninger 80]

– Should specify external system behavior

– Should specify implementation constraints
– Should by easy to change
– Should serve as reference tool for maintenance
– Should record forethought about system lifecycle
– Should characterize acceptable responses to
undesired events
Software Requirements Specification (SRS)

 System Models
– Information Model
– Functional Model
– Behavioral Model
 Functional Requirements Definition
 Non-functional Requirements Definition
 System Evolution
 Requirement Specification
 Validation Criteria
 Bibliography
 Appendix & Glossary
 Requirements Analysis

– Many types of analysis methods

 Structured Analysis
 Object-Oriented Analysis

– Each method has techniques for

representing
 Data

 Processing/Function

 Control/Behavior

– Each technique/notation is used to model

one or more types for information
 Analysis Methods

 Viewpoint Oriented Analysis

– Stakeholders perspectives
– Conflict resolution
 Method Based Analysis
– Data-flow based analysis methods
– Object-Oriented analysis methods
 Analysis Models

 Data processing model

– Data Flow Diagrams
 Composition model
– Entity-Relationship Diagrams
 Stimulus-response model
– State Transition Diagrams
 Classification model
– Object Model
 Analysis Stage

 Requirements

– Application oriented
 Specifications

– Technically oriented
 Software requirements document
 Design Stage

 Methodologies and tools (discussed

later)
 Human interface (psychology and
ergonomics)
 Implementation Stage

 Create system from design

– Write programs
– Create data files
– Develop databases
 Roleof “software analyst” versus
“programmer”
 Testing Stage

 Validation testing
– Confirm that system meets
specifications
 Defect testing
– Find bugs
 Software Engineering Methodologies

 Waterfall
Model
 Incremental Model

– Prototyping (Evolutionary vs.

Throwaway)
 Open-source Development
 Extreme Programming
 Modularity

 Procedures -- Imperative paradigm

– Structure charts
 Objects -- Object-oriented paradigm
– Collaboration diagrams
 Components -- Component
architecture
Figure 7.3 A simple structure chart
Figure 7.4 The structure of
PlayerClass and its instances
Figure 7.5 A simple collaboration
diagram
Figure 7.6 A structure chart including
data coupling
 Coupling versus Cohesion

 Coupling

– Control coupling
– Data coupling
 Cohesion

– Logical cohesion
– Functional cohesion
Figure 7.7 Logical and functional
cohesion within an object
 Tools of the Trade

 Data Flow Diagram

 Entity-Relationship Diagram

– One-to-one relation
– One-to-many relation
– Many-to-many relation
 Data Dictionary
Figure 7.9 A simple entity-relationship
diagram
Figure 7.10 One-to-one, one-to-many,
and many-to-many relationships between
entities of types X and Y
 Unified Modeling Language

 Use Case Diagram

– Use cases
– Actors
 Class Diagram
Figure 7.11 A simple use case
diagram
Figure 7.12 A simple class diagram
Figure 7.13 A class diagram depicting
generalizations
System models are abstract descriptions of
systems whose requirements are being
analysed

Objectives
 To explain why the context of a system
should be modelled as part of the RE process
 To describe

– Behavioural modelling (FSM, Petri-nets),

– Data modelling and
– Object modelling (Unified Modeling
Language, UML)
 System modelling
 System modelling helps the analyst to
understand the functionality of the system and
models are used to communicate with customers
 Different models present the system from
different perspectives
– External perspective showing the system’s
context or environment
– Behavioural perspective showing the
behaviour of the system
– Structural perspective showing the system or
data architecture
 System models weaknesses

 They do not model non-functional

system requirements
 They do not usually include information
about whether a method is appropriate
for a given problem
 They may produce too much
documentation
 The system models are sometimes too
detailed and difficult for users to
understand
 Model types
 Data processing model showing how the data is
processed at different stages

 Composition model showing how entities are composed

of other entities

 Architectural model showing principal sub-systems

 Classification model showing how entities have

common characteristics

 Stimulus/response model showing the system’s

reaction to events
 Process models

 Process models show the overall

process and the processes that are
supported by the system
 Data flow models may be used to
show the processes and the flow of
information from one process to
another
 Behavioural models

 Behavioural models are used to describe the

overall behaviour of a system
 Two types of behavioural model
– Data processing models that show how data is
processed as it moves through the system
– State machine models that show the systems
response to events
 Both of these models are required for a
description of the system’s behaviour
 Data-processing models
 Data flow diagrams are used to model the
system’s data processing
 These show the processing steps as data flows
through a system

 IMPORTANT part of many analysis methods

 Simple and intuitive notation that customers

can understand
 Show end-to-end processing of data
 Data flow diagrams

 DFDs model the system from a functional

perspective
 Tracking and documenting how the
data associated with a process is helpful to
develop an overall understanding of the
system
 Data flow diagrams may also be used in
showing the data exchange between a
system and other systems in its
environment
 Data Flow Diagrams

– Producer/Consumer
External of information
Entity outside the bounds
of the system
Process – Transformer of
information
– Data item or
Data collection of data
Item
items
Data Store
– Repository of data
stored for one or
more processes
A simple dataflow diagram
State Machine Diagrams

– Represent states
State
of the system

– Transitions
between states;
activities that
trigger state
change
 State machine models

 State Machine models the behaviour of the

system in response to external and internal
events
 They show the system’s responses to
stimuli so are often used for modelling real-
time systems
 State machine models show system states
as nodes and events as arcs between these
nodes. When an event occurs, the system
moves from one state to another
 Statecharts are an integral part of the UML
 Semantic data models
 Used to describe the logical structure of
data processed by the system
 Entity-relation-attribute model sets out
the entities in the system, the relationships
between these entities and the entity
attributes
 Widely used in database design. Can
readily be implemented using relational
databases
 No specific notation provided in the UML
but objects and associations can be used
 Object models
 Object models describe the system in terms
of object classes
 An object class is an abstraction over a set of
objects with common attributes and the services
(operations) provided by each object
 Various object models may be produced
– Inheritance models
– Aggregation models
– Interaction models
 Object models
 Natural ways of reflecting the real-world entities
manipulated by the system
 More abstract entities are more difficult to model
using this approach
 Object class identification is recognised as a
difficult process requiring a deep understanding of
the application domain
 Object classes reflecting domain entities are
reusable across systems
 The Unified Modeling Language
 Devised by the developers of widely used object-
oriented analysis and design methods
 Has become an effective standard for object-oriented
modelling
 Notation
– Object classes are rectangles with the name at the
top, attributes in the middle section and
operations in the bottom section
– Relationships between object classes (known as
associations) are shown as lines linking objects
– Inheritance is referred to as generalisation and is
shown ‘upwards’ rather than ‘downwards’ in a
hierarchy
 OBJECT-ORIENTED ANALYSIS
 Earlier, we saw a number of different software
lifecycle models.
 Similarly, there exists different ways to develop
object oriented (OO) software.
 We will start with a very basic OO waterfall model
as given in the textbooks. That model is ok, if
there is no (relational) database and the software
is not that big.
 Later, we will study why this is typically only
good for small non-database software.
 We will also study how large-scale database-
driven OO software should be developed.
 Object Analysis And Design
 The goal is to start from the requirements, and to
come up with a description of the software
(classes with their attributes and methods) which
can be implemented in a fairly straightforward
way.
 Usually we talk about “analysis model” and
“design model”.
 Analysis model is something which, in principle,
describes the system in OO terms, but we would
not want to implement it as such, for reasons such
as efficiency and maintainability.
 Design model is something we want to implement.
 Object Analysis
 Goal: Start from the requirement specification and come up
with
– A description of the classes (commonly a class diagram, to
be introduced later)
– A description on how the use cases are to be executed
using these classes (with some other UML diagrams such
as sequence diagrams, also to be introduced later).
 Methods:
– “Meditation” which more or less means “no methods”.
– Requirement specification text analysis. <- In these slides!
– Analysis of all possible technical documentation of an old
system or other existing systems.
– Possibly separate analysis of the domain (e.g. banking).
 Product Design

 Specifies materials
 Determines dimensions &
tolerances
 Defines appearance
 Sets performance standards
 An Effective Design Process

 Matches product/service characteristics

with customer needs
 Meets customer requirements in simplest,
most cost-effective manner
 Reduces time to market - haste vs. speed
to market
 Minimizes revisions - quality designed
into the product
Stages in the Design Process
 Idea Generation — Product Concept - can you
create your own market? What role does the
voice of the customer play in idea generation?
 Feasibility Study — Performance Specifications
 Preliminary Design — Prototype - testing and
redesign
 Final Design — Final Design Specifications
 Process Planning — Manufacturing
Specifications - make to order/stock –
assembly line?
 The Design Process
Idea Feasibility
generation study Performance
Product or
service concept specifications

Suppliers Customers Form design

R&D
Revising and testing
Marketing Competitors
prototypes

Functional Production
design design

Design Manufacturing
New product or specifications or delivery
service launch specifications

Pilot run
Final design and final tests
& process plans
 Risk Analysis

1. Identify the Hazards

2. Assess hazards to determine risks.
3. Develop controls and make risk
decisions.
4. Implement controls.
5. Supervise and evaluate.
 Preliminary Design
How will it look?
 Create form & functional design
 Build prototype
 Test prototype
 Revise prototype
 Retest
 Functional Design
(How the Product Performs)

 Reliability
 Probability product performs intended
function for specified length of time

 Maintainability
 Ease and/or cost or
maintaining/repairing product
 Design Teams

Preferred solution = cross functional teams

 Marketing, manufacturing,
engineering
 Suppliers, dealers, customers
 Lawyers, accountants,
insurance companies
 Concurrent Design

 Improves quality of early design

decisions
 Decentralized - suppliers complete
detailed design
 Incorporates production process
 Scheduling and management can be
complex as tasks are done in parallel
 include the customer in the
process!!
 Design for Six Sigma
 Define – the goals of the design activity
 Measure – customer input to determine
what is critical to quality from the
customers’ perspective – what are
customer delighters? What aspects are
critical to quality?
 Analyze – innovative concepts for products
and services to create value for the
customer
 Design – new processes, products, and
services to deliver customer value
 Verify – new systems perform as expected
 Design Review

 Failure Mode and Effects Analysis

(FMEA)
 A systematic approach for analyzing
causes & effects of failures
 Prioritizes failures
 Attempts to eliminate causes
 Value Analysis
(Value Engineering)
Is there value added?
 Ratio of value / cost
 Assessment of value :
1. Can we do without it?
2. Does it do more than is required?
3. Does it cost more than it is worth?
4. Can something else do a better job
5. Can it be made by less costly method, tools,
material?
6. Can it be made cheaper, better or faster by
someone else? Should we contract it out?
 Design for Environment

 Design from recycled material

 Use materials which can be recycled
 Design for ease of repair
 Minimize packaging
 Minimize material & energy
used during manufacture,
consumption & disposal
 green laws in Europe -
 Examples

 Recycling of oil
 carpets in land fills - 4 billion pounds
in land fills annually
 Xerox and Hewlett-Packard - pay for
return of printer cartridges on larger
printers
Quality Function Deployment (QFD)

 Translates the “voice of the

customer” into technical design
requirements
 Displays requirements in matrix
diagrams
 First matrix called “house of quality”
 Series of connected houses
 Design for Robustness
 Product can fail due to poor design
quality
 Products subjected to many conditions
 Robust design studies
 Controllable factors - under designer’s
control
 Uncontrollable factors - from user or
environment
 Designs products for consistent
performance
 Consistency is Important

 Consistent errors are easier to

correct than random errors
 Parts within tolerances may yield
assemblies which aren’t
 Consumers prefer product
characteristics near their ideal
values
ER Diagram for the Company
Database
 ER Model Concepts: Entities
and Attributes
 Entities - Specific Objects or Things in the Mini-world that
are Represented in the Database
– EMPLOYEE John Smith
– Research DEPARTMENT
– Productx PROJECT
 Attributes are Properties Used to Describe an Entity
e.g., an EMPLOYEE Entity may have a Name, SSN, Address,
Sex, Birthdate
 A Specific Entity (Instance) has a Value for Each of its
Attributes
– Specific Employee Entity May Have Name=‘John Smith’,
SSN=‘123456789’, Address=‘731 Fondren, Houston,
TX’, Sex=‘m’, Birthdate=‘09-jan-55’
 One-to-many(1:N) or Many-to-one (N:1)

EMPLOYEE WORKS_FOR DEPARTMENT

r1
e1   d1

e2  r2

e3  r3  d2

e4  r4
d3
e5  
r5
e6 
r6
e7 
r7
 MANY-TO-MANY(M:N)
r9
r1
e1   d1

e2  r2

e3  r3  d2

e4  r4
d3
e5  
r5
e6 
r6
e7 
r8 r7
 One-to-One Relationship
 Each Instance of One Entity Class E1 Can Be Associated
with Exactly One Instance of Another Entity Class E2 and
Vice Versa.
 Example:
– Each Employee Can Work in Exactly One Project and
Each Project Employs Exactly One Employee
Employee Project
Employee No Duration Project No
Name Name

1 1
EMPLOYEE WORKS ON PROJECT

Title Salary Responsibility Budget

One-to-One WORKS_ON Relationship
WORKS_ON
Relationship Instances

EMPLOYEE Set PROJECT Set

 Many-to-One Relationship
 Each Instance of One Entity Class E1 can be
Associated with Zero or More Instances of Another
Entity Class E2, but Each Instance of E2 can be
Associated With at Most 1 Instance of E1
 Example :
– Each Employee Can Work in Exactly One Project
Each Project Can Employ Many Engineers

Employee Project
Employee No Duration Project No
Name Name

N 1
EMPLOYEE WORKS ON PROJECT

Title Salary Responsibility Budget

One-to-Many WORKS_ON
Relationship
 Many-to-Many Relationship
 Each Instance of One Entity Class Can Be Associated with
Many Instances of Another Entity Class, and vice versa
 Example:
– Each Employee Can Work in Many Projects
Each Project Can Employ Many Employees

Employee Project
Employee No Duration Project No
Name Name

N M
EMPLOYEE WORKS ON PROJECT

Title Salary Responsibility Budget

Many-to-Many WORKS_ON
Relationship
 Structural Constraints
 Structural Constraints on a Relationship are One Way to
Express the Semantics of a Relationship
 Cardinality Ratio (of a Binary Relationship): 1:1, 1:N,
N:1, or M:N
– Shown by Placing Apropos Number on the Link
 Participation Constraint (on Each Entity Type):
– Total (Called Existence Dependency) or Partial
– Shown By Double Lining The Link
 NOTE:
– Easy to Specify for Binary Relationship Types
– Do Not Be Misled by Obscure Notations to Specify
Above Constraints for Higher Order Relationships
 E-R Diagrams
Employee Project
Employee No Duration Project No
Name Name

EMPLOYEE WORKS ON PROJECT

Title Salary Responsibility Budget NoEmp

Address
Location

Apt. # City

Street #