Software

Engineering
 Day - 1
Topics:
Introduction
Feasibility Study

Requirement

Engineering Process

Planning Areas
 Introduction

Role of IT in Business

National and international competency

IT for Competitive advantage

To stay in market
To gain maximum profit

To provide quality product

 Data Vs Information

Data
Events entities

Information
Processed data
 Software Crisis

Reasons for Software crises

 Importance of Quality and
Processes
 What is software?
Computer programs and associated documentation such
as requirements, design models and user manuals.
Software products may be developed for a particular
customer or may be developed for a general market.
Software products may be
Generic - developed to be sold to a range of different
customers e.g. PC software such as Excel or Word.
Bespoke (custom) - developed for a single customer
according to their specification.
New software can be created by developing new programs,
configuring generic software systems or reusing existing
software.
 What is software engineering?
Software engineering is an engineering
discipline that is concerned with all aspects of
software production.
Software engineers should adopt a
systematic and organised approach to their
work and use appropriate tools and
techniques depending on the problem to be
solved, the development constraints and the
resources available.
 What is the
difference between software
engineering and computer science?
Computer science is concerned with
theory and fundamentals; software
engineering is concerned with the
practicalities of developing and delivering
useful software.
Computer science theories are still
insufficient to act as a complete
underpinning for software engineering
(unlike e.g. physics and electrical
engineering).
 IEEE Code of Ethics
The professional societies in the US have
cooperated to produce a code of ethical
practice.
Members of these organisations sign up to
the code of practice when they join.
The Code contains eight Principles related to
the behaviour of and decisions made by
professional software engineers, including
practitioners, educators, managers,
supervisors and policy makers, as well as
trainees and students of the profession.
 Code of ethics - principles
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.
 Code of ethicsprinciples
continued..
JUDGMENT
Software engineers shall maintain integrity and

independence in their professional judgment.

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.
 Code of ethics - principles
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.
 Ethical Dilemmas
Disagreement in principle with the
policies of senior management.
Your employer acts in an unethical way
and releases a safety-critical system
without finishing the testing of the
system.
Participation in the development of
military weapons systems or nuclear
systems.
 SDLC Phases
A set of activities whose goal is the development
or evolution of software.
Generic activities in all software processes are:
Specification - what the system should do and
its development constraints
Development - production of the software
system
Validation - checking that the software is what
the customer wants
Evolution - changing the software in response
to changing demands.
Feasibility Study
 Feasibility Study
A feasibility study is a study made before
committing to a project.

In production projects, the feasibility study

often leads to a budget request.

In research, a feasibility study is often in the

form of a proposal.
 Why Feasibility Study ?
A feasibility study leads to a decision:
go ahead
do not go ahead
think again
 Feasibility Study:
Planning and Resources
The feasibility study should include an :
Estimate the staffing and equipment needs, and the
preliminary timetable
Identify major decision points
Identify interactions with and dependences on
external systems
Provide a preliminary list of deliverables and
delivery dates
 The Decision
Maker's Viewpoint
A senior member of an organization must decide whether to begin
a major software project. What information is needed?
Client: Who is this project for?
Scope: What are the boundaries of the project?
Benefits: What are the benefits? Can they be quantified?
Technical: Is there at least one technical way to carry out the
project?
Resources: What are the estimates of staff, time, equipment, etc?
Alternatives: What are the options if the project is not begun?
 The Decision Maker's
Viewpoint Where are risks?
Technical
There must be an outline plan with a rough timetable
and staff allocation.
The plan must have a very large margin for
contingencies. (Projects typically require twice the staff
and/or time envisaged in the feasibility plan.)
External
Every system interacts with others. Are the others
committed to the necessary efforts?
Where are the external pressures and obstacles?
 Feasibility study Process
Based on information assessment (what is
required), information collection and report
writing.
Questions for people in the organisation
What if the system wasnt implemented?
What are current process problems?
How will the proposed system help?
What will be the integration problems?
Is new technology needed? What skills?
What facilities must be supported by the
proposed system?
 Feasibility study
ProcessAlternatives and Risks
A feasibility study should identify alternatives and risks.
Alternatives
Continue with current system, enhance it, or create new
one?
Develop in-house, or contract out? (How will a contract be
managed?)
Risk
What can go wrong?
How will problems be identified (visibility)?
Are there fall-back options?
 Feasibility study Process..
Give client appreciation of system:
Demonstration
Mock-up
Walk through
Outline budget:
n people for m months at $x per month
equipment, buildings, etc.
Phases/milestones:
Deliverables at approximate date
 Feasibility study Process..
Feasibility Report

A written document
For a general audience: client, financial management,
technical management, etc.
Short enough that everybody reads it.
Long enough that no important topics are skipped.
Details are often included in supporting documents.

It should be a well written, well presented document.

 Feasibility Study Criteria
A feasibility study needs to demonstrate that the proposed
system is technically feasible. This requires:
a rough outline of the requirements
a possible system design (e.g., database, distributed, etc.)
estimates of numbers of users, data, transactions, etc.
possible choices of software to be acquired or developed
These very rough numbers are fed into the provisional plan
that is used to estimate the staffing, timetable, equipment
needs, etc.
Domain Area
w.r.t to Economic feasibility.
 Domain
requirements problems
Understandability
Requirements are expressed in the language of
the application domain;
This is often not understood by software
engineers developing the system.
Implicitness
Domain specialists understand the area so well
that they do not think of making the domain
requirements explicit.
Requirement
Engineering Process
 What is a requirement?
It may range from a high-level abstract statement
of a service or of a system constraint to a detailed
mathematical functional specification.
This is inevitable as requirements may serve a
dual function
May be the basis for a bid for a contract -
therefore must be open to interpretation;
May be the basis for the contract itself -
therefore must be defined in detail;
Both these statements may be called
requirements.
 Elicitation and analysis
Sometimes called requirements elicitation or
requirements discovery.
Involves technical staff working with
customers to find out about the application
domain, the services that the system should
provide and the systems operational
constraints.
May involve end-users, managers, engineers
involved in maintenance, domain experts,
trade unions, etc. These are called
stakeholders.
 Types of requirement
User requirements
Statements in natural language plus diagrams of

the services the system provides and its

operational constraints. Written for customers.
System requirements
A structured document setting out detailed

descriptions of the systems functions, services

and operational constraints. Defines what should
be implemented so may be part of a contract
between client and contractor.
 Definitions and specifications
User requi r em en t defini t ion

1 . Th e soft ware m ust p rov ide a means of represent in g and

1 . accessin g e x t ern al fil es crea t ed b y ot h er t oo ls.

Syst em requir em en t s sp ecifi cat io n

1 .1 T he user sho uld be pr ov ided wit h facil it ies t o defi ne t h e t yp e of

1 .2 ext ern al files.
1 .2 Each ex t ern al fil e t yp e may have an asso cia t ed t oo l w h ich m a y be
1 .2 app lied t o t he fi le.
1 .3 Each ex t ern al fil e t yp e may be repr esent ed as a specific i co n on
1 .2 t h e users disp la y.
1 .4 Facilit i es sho ul d be p r o v ided fo r t he i co n represent in g an
1 .2 ex t ern al fil e t yp e t o be defined b y t he user.
1 .5 When a user sel ect s an icon r epr esent in g an e x t ern al fil e, t he
1 .2 effect of t hat select ion is t o ap ply t h e t oo l asso ci at ed wi t h t h e t yp e of
1 .2 t h e ext ernal file t o t he fi le represent ed by t he select ed i co n.
Requirements readers
 Functional and
non-functional requirements
Functional requirements
Statements of services the system should provide, how
the system should react to particular inputs and how
the system should behave in particular situations.
Non-functional requirements
constraints on the services or functions offered by the
system such as timing constraints, constraints on the
development process, standards, etc.
Domain requirements
Requirements that come from the application domain
of the system and that reflect characteristics of that
domain.
 Functional requirements

Describe functionality or system services.

Depend on the type of software, expected
users and the type of system where the
software is used.
Functional user requirements may be high-
level statements of what the system should
do but functional system requirements
should describe the system services in detail.
 Non-functional requirements

These define system properties and

constraints e.g. reliability, response time
and storage requirements. Constraints are
I/O device capability, system
representations, etc.
Non-functional requirements may be more
critical than functional requirements. If
these are not met, the system is useless.
 User requirements

Should describe functional and non-

functional requirements in such a way
that they are understandable by system
users who dont have detailed technical
knowledge.
User requirements are defined using
natural language, tables and diagrams
as these can be understood by all
users.
 Problems with NL specification
Ambiguity
The readers and writers of the requirement
must interpret the same words in the same
way. NL is naturally ambiguous so this is very
difficult.

Lack of modularisation
NL structures are inadequate to structure
system requirements.
 Alternatives to NL specification
Notation Description
Structured natural This approach depends on defining standard forms or templates to express the
language requirements specification.
Design This approach uses a language like a programming language but with more abstract
description features to specify the requirements by defining an operational model of the system.
languages This approach is not now widely used although it can be useful for interface
specifications.
Graphical A graphical language, supplemented by text annotations is used to define the
notations functional requirements for the system. An early example of such a graphical
language was SADT. Now, use-case descriptions and sequence diagrams are
commonly used .
Mathematical These are notations based on mathematical concepts such as finite-state machines or
specifications sets. These unambiguous specifications reduce the arguments between customer and
contractor about system functionality. However, most customers dont understand
formal specifications and are reluctant to accept it as a system contract.
 Structured
language specifications
The freedom of the requirements writer is limited
by a predefined template for requirements.
All requirements are written in a standard way.
The terminology used in the description may be
limited.
The advantage is that the most of the
expressiveness of natural language is maintained
but a degree of uniformity is imposed on the
specification.
 Form-based specifications
Definition of the function or entity.
Description of inputs and where they
come from.
Description of outputs and where they
go to.
Indication of other entities required.
Pre and post conditions (if appropriate).
The side effects (if any) of the function.
 Users of a requirements document
Specify the requirements and
System read them to check that they
meet their needs. They
customers
specify changes to the
requirements

Use the requirements

Managers document to plan a bid for
the system and to plan the
system development process

System Use the requirements to

Engineers understand what system is to
be developed

System test Use the requirements to

Engineers develop validation tests for
the system

System Use the requirements to help

maintenance understand the system and
Engineers the relationships between its
parts
 IEEE requirements standard
Defines a generic structure for a
requirements document that must be
instantiated for each specific system.
Introduction.
General description.
Specific requirements.
Appendices.
Index.
 Requirements
document structure
Preface
Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index
 Requirements validation

Concerned with demonstrating that the

requirements define the system that the
customer really wants.
Requirements error costs are high so
validation is very important
Fixing a requirements error after delivery
may cost up to 100 times the cost of fixing
an implementation error.
 Requirements checking
Validity. Does the system provide the functions
which best support the customers needs?
Consistency. Are there any requirements
conflicts?
Completeness. Are all functions required by the
customer included?
Realism. Can the requirements be implemented
given available budget and technology
Verifiability. Can the requirements be checked?
 Requirements
validation techniques
Requirements reviews
Systematic manual analysis of the
requirements.
Prototyping
Using an executable model of the system to
check requirements.
Test-case generation
Developing tests for requirements to check
testability.
 Requirements reviews
Regular reviews should be held while the
requirements definition is being formulated.
Both client and contractor staff should be
involved in reviews.
Reviews may be formal (with completed
documents) or informal. Good communications
between developers, customers and users can
resolve problems at an early stage.
 Review checks
Verifiability. Is the requirement
realistically testable?
Comprehensibility. Is the requirement
properly understood?
Traceability. Is the origin of the
requirement clearly stated?
Adaptability. Can the requirement be
changed without a large impact on
other requirements?
 Traceability
Traceability is concerned with the relationships
between requirements, their sources and the
system design
Source traceability
Links from requirements to stakeholders who proposed
these requirements;
Requirements traceability
Links between dependent requirements;
Design traceability
Links from the requirements to the design;
 A traceability matrix

Req. 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2

id
1.1 D R
1.2 D D D
1.3 R R
2.1 R D D
2.2 D
2.3 R D
3.1 R
3.2 R
 Requirements management
Requirements management is the process of
managing changing requirements during the
requirements engineering process and system
development.
Requirements are inevitably incomplete and
inconsistent
New requirements emerge during the process as
business needs change and a better understanding
of the system is developed;
Different viewpoints have different requirements and
these are often contradictory.
Planning Areas
 Planning Areas
This section allocates objectives, user
expectations and potential topics for
standards to planning areas. The
allocation is done at first level: process
and user. The purpose is to provide a
basis for a planning group to determine
a program of work.
 Planning Areas continued..
No. Area Objectives Expectations Existing Std
1 Software Testing P13, 14, 18, E1, 2, 4
20-24
2 Software P3, 8,10,19-21 E3, 4, 7 IEEE 1045, 1061
Measurement
3 Software Reliability P20, 21 E11 IEEE 982
4 API, PLs and SES P3 E11
5 LC for Non- P3, 4, 22 E1, 2, 7
traditional Dev.
6 Conformance P1-24 E13
Testing
7 Criticality P10-15, 20 E7, 18
8 Process Maturity P1-24 E7
09 Integral Processes P8-19 E1, 4, 5, 7, 9, 10 IEEE 730, 828, 829,
983, 1008, 1012,
 Planning Areas continued..
No. Area Objectives Expectations Existing Std
10 Software Testing P13, 14, 18, E1, 2, 4
20-24
12 Software P3, 8,10,19- E3, 4, 7 IEEE 1045, 1061
Measurement 21
13 Software Reliability P20, 21 E11 IEEE 982

14 API, PLs and SES P3 E11

15 LC for Non- P3, 4, 22 E1, 2, 7
traditional Dev.
16 Conformance P1-24 E13
Testing
17 Criticality P10-15, 20 E7, 18
 Fact finding Methods
Reading
Observatios
Asking staff
Questionaries
Interviews
Whom to interview
When to interview
Where to interview
What to interview
Software
Requirements Specification

Characteristics

Format
Checklist for Requirements
Checklist for
Requirements Continued.
 Case Study Demonstration
Requirements

Feasibility Study

Fact Finding Areas

Checklists
Thank you
 Day - 2

Topics
Software Analysis
Design Concepts
Functional Independence
S/W Architecture
How to Write Program Specifications
Software Analysis
 Software Analysis
To explain why the context of a system
should be modelled as part of the RE
process
To describe behavioural modelling, data
modelling and object modelling
To introduce some of the notations used
in the Unified Modeling Language (UML)
Data Model
(DRD)
 Data Model (DRD)
Data Procurement Document (DPD). A
compilation of all documents that describe the
data
requirements of a particular task or project for
contractual efforts.
Data Requirements Description (DRD). A
detailed description of a required data item,
including purpose, contents, format,
maintenance requirements, and submittal
requirements.
 Data-Processing Models
Data flow diagrams (DFDs) may be used
to model the systems data processing.
These show the processing steps as data
flows through a system.
DFDs are an intrinsic part of many
analysis methods.
Simple and intuitive notation that
customers can understand.
Show end-to-end processing of data.
 Data Model (DRD)
continued..
DATA REQUIREMENTS DESCRIPTION (DRD)
1. DPD NO.: 821ISSUE: BASIC 2. DRD NO.:
1.1.1.1-b
3. DATA TYPE: 1
4. DATE REVISED:
5. PAGE: 1/1
6. TITLE: Work Breakdown Structure (WBS) and
Dictionary
7. DESCRIPTION/USE: To organize the tasks to be
accomplished in this contract in a product-oriented
structure.
8. DISTRIBUTION: Per Contracting Officer's letter
9. INITIAL SUBMISSION: 30 days after contract
Authority to Proceed (ATP)
10. SUBMISSION FREQUENCY: N/A
 Data Model (DRD) continued..

11. REMARKS:
12. INTERRELATIONSHIP: SOW 1.1.1.1,
1.1.2.1 and 1.1.2.2; DRDs 1.1.1.1-g, 1.1.2.1-a,
and 1.1.2.2-a.
13. DATA PREPARATION INFORMATION:
13.1
SCOPE: The WBS shall encompass all the
products required to achieve all the
requirements of this contract.
 Data Model (DRD) continued..

13.2 APPLICABLE DOCUMENTS: None

13.3 CONTENTS: The WBS shall depict a
family tree composed of all the work required
by the contract. The dictionary contains a
concise description of contract tasks to be
performed and products to be delivered,
subdivided by WBS element.
 Data Model (DRD) continued..

13.4 FORMAT: The WBS tree is to be in

organization chart format and the associated WBS
narrative (WBS Dictionary) in text form and
arranged as stated in 13.3 of this DRD. The WBS
tree and dictionary shall be provided in both
electronic and hard copy form.
13.5 MAINTENANCE: The WBS and WBS
Dictionary shall be updated to reflect contract
changes as they affect the WBS coverage.
Revisions shall be incorporated by change page or
complete reissue.
Data Model
(DFD)
 Data Flow Diagram
A network representation of a system.
The system may be automated,
manual, or mixed. The DFD portrays
the system in terms of its component
pieces, with all interfaces among the
components indicated."- Tom DeMarco
Hence DFDs:
Focus on the movement of data
between external entities and
processes, and between processes and
data stores
 Example
Data Flow Diagram

data store

data flow process

external
entity
 Data Flow Diagrams
Used to perform structured analysis
to determine logical requirements
A graphical tool, useful for
communicating with users,
managers, and other IS personnel
Useful for analyzing existing as well
as proposed systems
A relatively simple technique to learn
and use
 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.
Order Processing DFD
Insulin pump DFD
 Data Model
(USE CASES)
 Object models and the UML
The UML is a standard representation devised by the
developers of widely used object-oriented analysis
and design methods.
It 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.
 Use Case Diagrams
Use Case Diagrams
A use case is a set of scenarios that describing an
interaction between a user and a system. A use case
diagram displays the relationship among actors and use
cases. The two main components of a use case diagram
are use cases and actors.

An actor is represents a user or another system that will

interact with the system you are modeling. A use case is
an external view of the system that represents some
action the user might perform in order to complete a task.
Use Case Diagrams
 Use cases
Use-cases are a scenario based technique in
the UML which identify the actors in an
interaction and which describe the
interaction itself.
A set of use cases should describe all
possible interactions with the system.
Sequence diagrams may be used to add
detail to use-cases by showing the sequence
of event processing in the system.
 Data Model
(CLASS DIAGRAMS)
 Class Diagrams

Class diagrams are widely used to describe the

types of objects in a system and their
relationships. Class diagrams model class structure
and contents using design elements such as classes,
packages and objects. 2 Class diagrams describe
three different perspectives when designing a system,
conceptual, specification, and
implementation.1 These perspectives become evident
as the diagram is created and help solidify the design.
Class diagrams also display relationships such as containment,
inheritance, associations and others.2 Below is an example of

an associative relationship:
Classes are composed of three things: a name, attributes,
and operations. Below is an example of a class.
Data Model
(ERD)
 Example 1

A publishing company produces scientific books on various

subjects. The books are written by authors who
specialize in one particular subject. The company
employs editors who, not necessarily being specialists in
a particular area, each take sole responsibility for
editing one or more publications. A publication covers
essentially one of the specialist subjects and is normally
written by a single author. When writing a particular
book, each author works with on editor, but may submit
another work for publication to be supervised by other
editors. To improve their competitiveness, the company
tries to employ a variety of authors, more than one
author being a specialist in a particular subject.
 Example 1 - Answer

concerns edited by
Subject Publication

is specialised in
is written by
Editor

Author
Author-
works with Editor employs
 Example 2
A General Hospital consists of a number of specialized
wards (such as Maternity, Paediatry, Oncology, etc). Each
ward hosts a number of patients, who were admitted on
the recommendation of their own GP and confirmed by a
consultant employed by the Hospital. On admission, the
personal details of every patient are recorded. A separate
register is to be held to store the information of the tests
undertaken and the results of a prescribed treatment. A
number of tests may be conducted for each patient. Each
patient is assigned to one leading consultant but may be
examined by another doctor, if required. Doctors are
specialists in some branch of medicine and may be
leading consultants for a number of patients, not
necessarily from the same ward.
 Example 2 Answer
specialised in
Ward Specialty

gives Tests

is admitted to
Test-Results specialised in
Treatment
follows devises
gets

is diagnosed diagnoses
Patient Diagnosis Doctor

recommends
assigned to
0
GP
Consultant
 Design
Concepts
Analysis to Design
 Design Principles
The design should be traceable to the analysis model.
The design should not reinvent the wheel.
The design should minimize the intellectual distance
between the software and the problem as it exists in the real
world.
The design should exhibit uniformity and integration.
The design should be structured to accommodate change.
The design should be structured to degrade gently, even when
aberrant data, events, or operating conditions are
encountered.
Design is not coding, coding is not design.
The design should be assessed for quality as it is being
created, not after the fact.
 Fundamental Concepts
abstractiondata, procedure
refinementelaboration of detail for all
abstractions
modularitycompartmentalization of data
and function
architectureoverall structure of the
software
Structural properties
Extra-structural properties
Data Abstraction

Door

manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism

Implemented as a data structure

Procedural Abstraction
open

details of enter
algorithm

implemented with a "knowledge" of the

object that is associated with enter
Stepwise Refinement
open

walk to door;
reach for knob;

open door; repeat until door opens

turn knob clockwise;
walk through; if knob doesn't turn, then
close door. take key out;
find correct key;
insert in lock;
end if
pull/push door
move out of way;
end repeat
 Modular Design
Easier to build, easier to change, easier to fix ...
 Architecture

The overall structure of the software and the ways in which

that structure provides conceptual integrity for a system.

Structural properties. This aspect of the architectural design

representation defines the components of a system (e.g., modules,
objects, filters) and the manner in which those components are
packaged and interact with one another. For example, objects are
packaged to encapsulate both data and the processing that
manipulates the data and interact via the invocation of methods .
Extra-functional properties. The architectural design description
should address how the design architecture achieves requirements
for performance, capacity, reliability, security, adaptability, and other
system characteristics.
 EXECUTIVE

Fan out
Depth

MODULE A MODULE B MODULE C MODULE D MODULE E MODULE F MODULE G

Module X Module Y Module Q Module R Module M Module N

Fan in

Module K Module L Module S Module T

Breadth
 Functional Independence

COHESION - the degree to which a

module performs one and only one
function.

COUPLING - the degree to which a

module is "connected" to other
modules in the system.
 Distributed systems
Virtually all large computer-based
systems are now distributed systems.
Information processing is distributed
over several computers rather than
confined to a single machine.
Distributed software engineering is
therefore very important for enterprise
computing systems.
 System Types
Personal systems that are not distributed and
that are designed to run on a personal computer
or workstation.
Embedded systems that run on a single
processor or on an integrated group of
processors.
Distributed systems where the system software
runs on a loosely integrated group of
cooperating processors linked by a network.
 Distributed system
characteristics
Resource sharing
Sharing of hardware and software resources.
Openness
Use of equipment and software from different vendors.
Concurrency
Concurrent processing to enhance performance.
Scalability
Increased throughput by adding new resources.
Fault tolerance
The ability to continue in operation after a fault has
occurred.
 Distributed system disadvantages
Complexity
Typically, distributed systems are more complex than
centralised systems.
Security
More susceptible to external attack.
Manageability
More effort required for system management.
Unpredictability
Unpredictable responses depending on the system
organisation and network load.
 Distributed systems
architectures
Client-server architectures
Distributed services which are called on by
clients. Servers that provide services are
treated differently from clients that use
services.
Distributed object architectures
No distinction between clients and servers.
Any object on the system may provide and
use services from other objects.
 Client-server architectures

The application is modelled as a set of

services that are provided by servers and a
set of clients that use these services.
Clients know of servers but servers need
not know of clients.
Clients and servers are logical processes
The mapping of processors to processes is
not necessarily 1 : 1.
 A client-server system

c2 c3 c4 c12
c11
Server p rocess

c1 s1 s4

c10
c5
Client p rocess
s2 s3 c9

c6
c7 c8
 Middleware
Software that manages and supports the
different components of a distributed system.
In essence, it sits in the middle of the system.
Middleware is usually off-the-shelf rather than
specially written software.
Examples
Transaction processing monitors;
Data converters;
Communication controllers.
 Thin and Fat clients
Thin-client model
In a thin-client model, all of the application
processing and data management is carried out
on the server. The client is simply responsible
for running the presentation software.
Fat-client model
In this model, the server is only responsible for
data management. The software on the client
implements the application logic and the
interactions with the system user.
Application layers
 Three-tier architectures
In a three-tier architecture, each of the
application architecture layers may
execute on a separate processor.
Allows for better performance than a thin-
client approach and is simpler to manage
than a fat-client approach.
A more scalable architecture - as demands
increase, extra servers can be added.
A 3-tier C/S architecture
An internet banking system

Client HTT P interaction

Web server Database server

Client
SQL query
Account serv ice Custo mer
SQL acco unt
p rov isio n
database
Client

Client
 Use of C/S Architectures
Arc hitecture Appli cations
Two-tier C/S Legacy system appli cations whe re separating appli cation p rocessing and
archit ecture with data manage ment is impractical.
thin c li ents Computationa ll y-intens ive appli cations such as compil ers wit h littl e or
no data management.
Data-intens ive appli cations (browsing and que rying) wit h littl e or no
appli cation processing .
Two-tier C/S App li cations whe re appli cation p rocessing is provided by o ff-the-shelf
archit ecture with software (e.g. M ic rosoft Exc el) on the cli ent.
fat cli ents App li cations whe re computationa ll y-intensive p rocessing of data (e.g.
data visua lis ation) is requir ed.
App li cations wit h relatively stable end -use r func tiona lit y u sed in an
env ir onment wit h well -establi shed system management.
Thre e-tier or Large scale applications with hund reds or thousand s of cli ents
multi -tier C/S App li cations whe re both the data and the appli cation are vo latil e.
archit ecture App li cations whe re data from multi ple sour ces are integrated.
 Why Architecture ?
The architecture is not the operational
software. Rather, it is a representation that
enables a software engineer to:
(1) analyze the effectiveness of the design
in meeting its stated requirements,
(2) consider architectural alternatives at a
stage when making design changes is still
relatively easy, and
(3) reduce the risks associated with the
construction of the software.
 Program Specifications
During detailed design, the view of the application
developed during the high level design is
broken down into modules/programs. Logic design is done
for every program and then
documented as program specifications. Also, for every
program, a unit test plan is created.
Some of the important activities in the detailed design
stage are to identify common routines
and programs (e.g. date validation routines), development
of skeleton programs, and
development of utilities and tools for productivity
improvement
Thank you
 Day - 3

Topics
Data Design
User interface Design
Software implementation
Software Maintenance
Software Development Life cycle
(Revised..)
Software process models
 Data Design
 Data Design

Refine data objects and develop a set of

data abstractions
Implement data object attributes as one
or more data structures
Review data structures to ensure that
appropriate relationships have been
established
Simplify data structures as required
 Data DesignComponent Level

1) The systematic analysis principles applied to

function and behavior should also be applied to data.
2) All data structures and the operations to be
performed on each should be identified.
3) The representation of data structure should be
known only to those modules that must make direct
use of the data contained within the structure.
4) A software design and programming language
should support the specification and realization of
abstract data types.
 Definition of 1NF
First Normal Form is a relation in which the intersection of
each row and column contains one and only one value.
There are two approaches to removing repeating groups
from unnormalized tables:

1. Removes the repeating groups by entering

appropriate data in the empty columns of rows
containing the repeating data.

2. Removes the repeating group by placing the

repeating data, along with a copy of the original
key attribute(s), in a separate relation. A primary
key is identified for the new relation.
 Full functional dependency

Full functional dependency indicates that if A and B

are
attributes of a relation, B is fully functionally
dependent on A if B is functionally dependent on A,
but not on any proper subset of A.

A functional dependency AB is partially

dependent if there is some attributes that can be
removed from A and the dependency still holds.
 Second Normal Form (2NF)
Second normal form (2NF) is a relation that is in
first normal form and every non-primary-key
attribute is fully functionally dependent on the
primary key.

The normalization of 1NF relations to 2NF involves

the
removal of partial dependencies. If a partial
dependency exists, we remove the function
dependent attributes from the relation by placing
them in a new relation along with a copy of their
determinant.
 Third Normal Form (3NF)
Transitive dependency
A condition where A, B, and C are attributes of a relation such that
if A B and B C, then C is transitively dependent on A via B
(provided that A is not functionally dependent on B or C).

Third normal form (3NF)

A relation that is in first and second normal form, and in which
no non-primary-key attribute is transitively dependent on the
primary key.
The normalization of 2NF relations to 3NF involves the removal
of transitive dependencies by placing the attribute(s) in a new
relation along with a copy of the determinant.
 Boyce - Codd
Normal Form (BCNF)

Boyce-Codd normal form (BCNF)

A relation is in BCNF, if and only if, every determinant
is a candidate key.

The difference between 3NF and BCNF is that for a functional

dependency A B, 3NF allows this dependency in a relation
if B is a primary-key attribute and A is not a candidate key,
whereas BCNF insists that for this dependency to remain in a
relation, A must be a candidate key.
 Fourth Normal Form (4NF)

Fourth normal form (4NF)

A relation that is in Boyce-Codd normal form and

Contains no nontrivial multi-valued dependencies.
Fifth Normal Form (5NF)

Lossless-join dependency
A property of decomposition, which ensures that no spurious
tuples are generated when relations are reunited through a
natural join operation.

Join dependency
Describes a type of dependency. For example, for a relation R
with subsets of the attributes of R denoted as A, B, , Z, a
relation R satisfies a join dependency if, and only if, every legal
value of R is equal to the join of its projections on A, B, , Z.
USER INTERFACE DESIGN

Input Design

Output Design
 The user interface
User interfaces should be designed to
match the skills, experience and
expectations of its anticipated users.
System users often judge a system by its
interface rather than its functionality.
A poorly designed interface can cause a
user to make catastrophic errors.
Poor user interface design is the reason why
so many software systems are never used.
 Human factors
in interface design
Limited short-term memory
People can instantaneously remember about 7 items of
information. If you present more than this, they are more
liable to make mistakes.
People make mistakes
When people make mistakes and systems go wrong,
inappropriate alarms and messages can increase stress
and hence the likelihood of more mistakes.
People are different
People have a wide range of physical capabilities.
Designers should not just design for their own capabilities.
People have different interaction preferences
Some like pictures, some like text.
 UI design principles
UI design must take account of the needs,
experience and capabilities of the system
users.
Designers should be aware of peoples
physical and mental limitations (e.g. limited
short-term memory) and should recognise
that people make mistakes.
UI design principles underlie interface
designs although not all principles are
applicable to all designs.
 Design principles
User familiarity
The interface should be based on user-oriented
terms and concepts rather than computer concepts. For
example, an office system should use concepts such as
letters, documents, folders etc. rather than directories,
file identifiers, etc.
Consistency
The system should display an appropriate level
of consistency. Commands and menus should have the
same format, command punctuation should be similar,
etc.
Minimal surprise
If a command operates in a known way, the user should
be able to predict the operation of comparable commands
 Design principles
Recoverability
The system should provide some resilience to
user errors and allow the user to recover from errors.
This might include an undo facility, confirmation of
destructive actions, 'soft' deletes, etc.
User guidance
Some user guidance such as help systems, on-line
manuals, etc. should be supplied
User diversity
Interaction facilities for different types of user should
be supported. For example, some users have seeing
difficulties and so larger text should be available
 Colour use guidelines
Limit the number of colours used and be
conservative in their use.
Use colour change to show a change in
system status.
Use colour coding to support the task that
users are trying to perform.
Use colour coding in a thoughtful and
consistent way.
Be careful about colour pairings.
 Error messages

Error message design is critically

important.
Poor error messages can mean that a user
rejects rather than accepts a system.
Messages should be polite, concise,
consistent and constructive.
The background and experience of users
should be the determining factor in
message design.
 User interface evaluation

Some evaluation of a user interface design

should be carried out to assess its
suitability.
Full scale evaluation is very expensive and
impractical for most systems.
Ideally, an interface should be evaluated
against a usability specification. However, it
is rare for such specifications to be
produced.
 SOFTWARE
IMPLEMENTATION
 Implementation

Implementation Strategy
Schedule
Training
Organization
Audit
 Software Implementation
Standards for programming
 Source Code Standards
Have to do everything possible to facilitate:
Readability
Maintainability
Correctness
Portability

Source Code Layout

Techniques that emphasize program structure
visibly:
Careful indentation
Tabbing to align similar items on sequential statements
Columning
White space
Use such techniques to maximize readability
Comments
Why use comments?
Problems with comments:

Identifiers
Identifiers are the names of things:
Variables, classes, functions, etc.
Identifiers are a primary form of
software documentation

Make identifiers meaningful

Symbolic Constants
Embedded literals are sometimes called Magic
Numbers

Program Constants &

Expressions
Do not forget expressions
Compile-time expressionsmake constants compute
themselves
Programming Practices
Alwaysdevelop your own or use a
published standard with any language
mentioned
 What is Software Maintenance?
IEEE91 Definition:
the process of modifying the software system
or component after delivery to correct faults,
improve performance or other attributes, or
adapt to a change in the environment.
SM is concerned with modifying software
once it is delivered to a customer
Major economic importance: 40 90% of
the total lifecycle costs
 What is Software Maintenance ?
Four categories:
1. Perfective maintenance: changes required as a result of
user requests (a.k.a. evaluative maintenance)
2. Adaptive maintenance: changes needed as a
consequence of operated system, hardware, or DBMS
changes
3. Corrective maintenance: the identification and removal of
faults in the software
4. Preventative maintenance: changes made to software to
make it more maintainable

The majority of SM is concerned with evolution deriving from

user requested changes.
 Software Maintenance:
The Root Problem
The root problem is complexity.
Sometimes complexity arises because a
system is migrated from hardware to
software in order to gain the additional
functionality found in software.
The combination of scale and application
complexity mean that it is infeasible for one
person alone to understand the complete
software system.
Software Life Cycle
and
Models
Software Development
Life Cycle(Revised.)
 Software Process

Software Process defines the way to

produce software. It includes
Software life-cycle model
Tools to use
Individuals building software
Software life-cycle model defines how
different phases of the life cycle are
managed.
 Phases of Software Life-cycle
Requirements
Specification (Analysis)
Design
Implementation
Integration
Maintenance
Retirement
 Requirements
Assumption
The software being considered is
considered economically justifiable.

Concept exploration
Determine what the client needs, not what
the client wants

Document - Requirements Document

 Specification (Analysis) Phase
From the customer requirements identify
what to build.

Specifications must not be

Ambiguous
Incomplete
Contradictory

Document Specification Document

 Design Phase
From the specification identify how to build.

Design involves two steps

Architectural Design Identify modules

Detailed Design Design each modules

Document Architecture Document, Design

Document
 Implementation Phase

Implement the detailed design in code.

Developer testing
Unit testing

Module testing

Document Commented source code

 Integration Phase
Combine the modules and test the
product as a whole.

Testing includes
Product testing

Acceptance testing

Document Test cases and test results

 Maintenance Phase
Any changes after the customer accepts the
system.

Maintenance phase is the most expensive

Lack of documentation

Regression testing

Document Documented Changes, Regression

test cases
 Retirement Phase
Good software is maintained
Sometimes software is rewritten from scratch
Software is now un-maintainable because
A drastic change in design has occurred
The product must be implemented on a totally new
hardware/operating system
Documentation is missing or inaccurate
Hardware is to be changedit may be cheaper to rewrite
the software from scratch than to modify it

True retirement is a rare event

Software Process
Model
 The waterfall model
The waterfall model derives its name due to the
cascading effect from one phase to the other as
is illustrated in Figure in next slide. In this
model each phase well defined starting and
ending point, with identifiable deliveries to the
next phase
Note that this model is sometimes referred to as
the linear sequential model or the software life
cycle.
 Incremental Model

Deliver elements of the product in stages

Each delivery adds functionality not
previously provided
Each delivery is an improvement to the
previous delivery
Each delivery must leverage off of existing
work without removing or destroying it
 The Incremental Model
Requirements

Global System Design

Detailed design Detailed design Detailed design

Implementation Implementation Implementation

Testing Testing Testing

Maintenance
 Spiral Model
Boehm (1988)
Incremental model with risk assessment
Risk driven rather than document driven
Spiral through
planning
risk analysis
engineering
customer evaluation
Spiral Model Redrawn
 Rapid Application
Development (RAD)

RAD, or rapid application development,

is an approach to systems development
that includes a method of development
as well as software tools
 RAD Phases

The three broad phases to RAD are :

Requirements planning
RAD design workshop
Implementation
 Requirements Planning Phase

Users and analysts meet to identify

objectives of the application or system
Oriented toward solving business
problems
 RAD Design Workshop

Design and refine phase

Use group decision support systems to help
users agree on designs
Programmers and analysts can build and
show visual representations of the designs
and workflow to users
Users respond to actual working prototypes
Analysts refine designed modules based on
user responses
 Implementation Phase
As the systems are built and refined, the
new systems or partial systems are tested
and introduced to the organization
When creating new systems, there is no
need to run old systems in parallel
Martin Approach to RAD
 When to Use RAD
RAD is used when:
The team includes programmers and
analysts who are experienced with it
There are pressing reasons for speeding up
application development
The project involves a novel ecommerce
application and needs quick results
Users are sophisticated and highly engaged
with the goals of the company
 Disadvantages of RAD

May try and hurry the project too much

Loosely documented
 The V-Model

Requirements Acceptance Test

System Design Integration Test

Detailed Design Module Test

Implementation
 Analysis of the V-Model

Improves testing strategies

Does not particularly improve:
sequential nature
feedback
developmental risk management
 The (Rapid) Prototyping Model

Goals:
to break away from the sequential
nature.
to speed up feedback.
to minimise risks
for both customer and developer
to be incomplete but executable.
to be cheap and fast.
 What is Prototyping?

A definition (A. Davis):

A prototype is a partial implementation of a

system, constructed primarily to enable
customer, end-user, or developer to learn
about the problem and/or its solution.
Types:
evolutionary / throw-away
horizontal / vertical
Discussion
Pros and Cons

Quiz
Thank you