INFORMATION AND

SOFTWARE ASSURANCE
AND SECURITY
 MODULE 1
INTRODUCTION TO
SOFTWARE ENGINEERING
• Importance of software engineering
• Different layers of software engineering
• Challenges in developing software
• Perspective on quality for software
• Different members of the development team
 Part 1
Module 1 Submodule 1
 Module 1
Submodule 1
Software Engineering Definitions and Layers

• Importance of software engineering

• Different layers of software engineering
The term software engineering was popularized during
the 1968 NATO Software Engineering Conference (held in
Garmisch, Germany) by its chairman F.L. Bauer, and has
been in widespread use since.

The field of SE aims to find answers to the many

problems that software development projects are likely
to meet when constructing large software systems.
Such systems are complex
• because of their sheer size,
• because they are developed by a team involving
people from different disciplines, and
• because they will be modified regularly to meet
changing requirements, both during development and
after installation.
The software developed is according to:
Accepted industry practice, with good quality control,
adherence to standards, and in an efficient and timely
manner.

The term software engineering refers to a systematic

procedure that is used in the context of a generally
accepted set of goals for the analysis, design,
implementation, testing and maintenance of software
According to IEEE SOFTWARE ENGINEERING is the
application of a systematic, disciplined, quantifiable
approach to the development, operation, and
maintenance of software.

The discipline of software engineering encompasses

knowledge, tools, and methods for defining software
requirements, and performing software design, software
construction, software testing, and software
maintenance tasks.
SOFTWARE ENGINEERING also draws on knowledge from
fields such as computer engineering, computer science,
management, mathematics, project management, quality
management, software ergonomics, and systems
engineering.
This is according to the author Ronald Leach.
• The software produced should be efficient, reliable,
usable, modifiable, portable, testable, reusable,
maintainable, interoperable, and correct.
• SWEBOOK (Software Engineering Body of
Knowledge) , 2013 defines these characteristics as the
following
The software produced should be:
• Efficient – software made in expected time and
within resources
• Reliable – software performs as expected
• Usable – software can be used properly
• Modifiable – software can be easily changed as
requirement changes
The software produced should be:
• Portable – system can be ported to other
computers without major rewriting of the software
• Testable – software can be easily tested
• Reusable – software can be used again in other
projects
The software produced should be:
• Maintainable – software can be easily
understood and changed overtime if problems
occur
• Interoperable – software can interact with other
systems properly
• Correct - the program produces the correct
output
Software Engineering:
focusing on computer as a
problem-solving tool

Relationship between
computer science and
software engineering

Figure 1.1
Relationship between computer science and software engineering
Over the past years
• Technology has advanced rapidly
• Ordering of food, clothes, or even transportation is done
through smartphones, while on the phone and en route to
your next destination
• With this example, software has grown to provide
humanity with endless opportunities
More complex is the system, the more is the
programming skill needed.

In a nutshell, software engineering is developing

complex software end products by professionals within
time and budget.

Software engineering is often viewed as layered.

 Part 2
Module 1 Submodule 1
 SOFTWARE ENGINEERING IS A
LAYERED TECHNOLOGY AS FOLLOWS:

Figure 1.2
Software engineering layers
SOFTWARE ENGINEERING LAYERS
QUALITY FOCUS
The bedrock that supports software engineering. Any
engineering approach must rest on an organizational
commitment to quality.

Figure 1.2
Software engineering layers
SOFTWARE ENGINEERING LAYERS
PROCESS
It is the glue that holds the technology layers
together and enables rational and timely
developments of computer SW.

Figure 1.2
Software engineering layers
 SOFTWARE ENGINEERING LAYERS
PROCESS
Process defines a framework that must be established for
effective delivery of SW engineering technology.

Figure 1.2
Software engineering layers
 SOFTWARE ENGINEERING LAYERS
PROCESS
It forms the basis for
• management control of software projects
• establishes the context (technical
methods applied)
• Work products (models, documents,
data, reports, form, etc.) are produced, Figure 1.2
• milestones are established, Software engineering layers

• quality is ensured, and change is properly

managed
SOFTWARE ENGINEERING LAYERS
METHODS
• Provide the technical how-to’s for building SW.

Figure 1.2
Software engineering layers
SOFTWARE ENGINEERING LAYERS
METHODS
• Encompasses a broad array of tasks that include
communication, requirements analysis, design
modeling, program construction, testing, and
support.

Figure 1.2
Software engineering layers
SOFTWARE ENGINEERING LAYERS
METHODS
• Rely on a set of basic principles that govern
each area of the technology and include
modeling activities and other descriptive
techniques.

Figure 1.2
Software engineering layers
SOFTWARE ENGINEERING LAYERS
TOOLS
Provide automated and semi automated support
for the process and the methods.

Figure 1.2
Software engineering layers
SOFTWARE ENGINEERING LAYERS
TOOLS
When tools are integrated so that information
created by one tools can be used by another, a
system for the support of SW development, called
CASE (Computer-Aided Software Engineering), is
established

Figure 1.2
SOFTWARE ENGINEERING LAYERS

Figure 1.2
Software engineering layers
 END OF
MODULE 1
SUBMODULE 1

References:
• Pressman, R. S. (2015). Software engineering: a practitioners approach.
New York, NY: McGraw-Hill
• Douglass, B. P. (2016). Agile systems engineering. Waltham, MA: Morgan
Kaufmann.
• Leach, R. J. (2016). Introduction to software engineering. Boca Raton:
Chapman & Hall/CRC.
• Laplante, P. A. (2018). Requirements engineering for software and
systems. Boca Raton: CRC Press.
 END OF
MODULE 1
SUBMODULE 1

References:
• Pressman, R. S. (2015). Software engineering: a practitioners approach.
New York, NY: McGraw-Hill
• Douglass, B. P. (2016). Agile systems engineering. Waltham, MA: Morgan
Kaufmann.
• Leach, R. J. (2016). Introduction to software engineering. Boca Raton:
Chapman & Hall/CRC.
• Laplante, P. A. (2018). Requirements engineering for software and
systems. Boca Raton: CRC Press.
 Part 1
Module 1 Submodule 2
 Module 1
Submodule 2

• The challenges in developing software

• The perspective on quality for software
• Different members of the development team
CHALLENGES IN DEVELOPING SOFTWARE

1. Developing/large/complex software application

CHALLENGES IN DEVELOPING SOFTWARE

2. Effort intensive

This Photo by Unknown Author is licensed under CC BY-

NC-ND
CHALLENGES IN DEVELOPING SOFTWARE

3. High cost (in case the solution is unsuccessful)

This Photo by Unknown Author is licensed under CC BY-NC

This Photo by Unknown

Author is licensed under CC
BY-SA
CHALLENGES IN DEVELOPING SOFTWARE

4. Long development time

This Photo by Unknown Author is licensed under CC BY-

SA-NC

This Photo by Unknown Author is licensed under CC BY-NC-

ND
CHALLENGES IN DEVELOPING SOFTWARE

5. Changing needs for users

This Photo by Unknown Author is licensed under CC BY-SA-NC This Photo by Unknown Author is licensed
under CC BY-SA-NC
CHALLENGES IN DEVELOPING SOFTWARE

6. High risk of failure, reasons of user acceptance,

performance and maintainability

This Photo by Unknown Author is licensed under

CC BY-SA-NC

This Photo by Unknown Author is licensed under CC BY-SA

WHAT IS GOOD SOFTWARE?
PERSPECTIVE ON QUALITY

Dr. David A. Garvin, PhD, a professor of Business

Administration Harvard Business school identified
5 major approaches of defining quality
• The transcendent view
• The product-based view
• The user-based view
• The manufacturing-based view
• The value-based view
 QUALITY: TRANSCENDENT

Transcendent
➢ Quality is an innate excellence (cannot be
defined exactly
➢ Quality is simple, unanalysable recognized only
through experience
 QUALITY: PRODUCT-BASED

Product-Based
➢ Quality is precise, measurable variable in the
components and attributes of a product
➢ Reflects the presence or absence of such
measurable and desired product attributes
 QUALITY: USER-BASED

User-based
➢ Goods that best satisfies user preferences have
the highest quality
 QUALITY: MANUFACTURING
BASED

Manufacturing based
➢ Conformance to requirements
➢ Preventing defects (less expensive than
repair/rework)
➢ Products that follows specification are of high
quality
 QUALITY: VALUE-BASED

Value Based
➢ Provides quality product at an acceptable price
or conformance at an acceptable cost
➢ This approach is becoming the more prevalent
 Part 2
Module 1 Submodule 2
 WHAT IS GOOD SOFTWARE?
• Good software engineering must always include
a strategy for producing quality software
• Three ways of considering quality
– The quality of the product
– The quality of the process
– The quality of the product in the context of
the business environment
 WHAT IS GOOD SOFTWARE?
THE QUALITY OF THE PRODUCT

✓ Users judge external characteristics (e.g., correct functionality,

number of failures, type of failures)
✓ Designers and maintainers judge internal characteristics (e.g.,
types of faults)
✓ Different stakeholders may have different criteria
✓ Need quality models to relate the user’s external view to
developer’s internal view
WHAT IS GOOD SOFTWARE?
THE QUALITY OF THE PRODUCT

• Classic model of software quality factors was suggested by McCall

(McCall et al., 1977)
• McCall’s factors consists of 11 software quality factors
• Similarly models suggested by Deutsch and Willis (1988) and
Evans and Marciniak (1987)
• All these models do not differ substantially from McCall’s model
• McCall factor model provides a practical, up-to-date method for
classifying software requirements (Pressman, 2000).
McCall’s Quality Model

1. Correctness
2. Reliability
3. Efficiency
4. Integrity
5. Usability
6. Maintainability
7. Flexibility
8. Testability
9. Portability
10. Reusability
11. Interoperability
The model was grouped into three categories (product operation
factors, product revision factors, product transition factors)

Correctness
Product
operation factors

Reliability

Efficiency

Maintainability Integrity

Product revision
factors Usability
Flexibility
McCalls Quality
Model

Testability
Portability

Reusability
Product
transition factors
Interoperability

Figure 1.1 McCalls Quality Model

WHAT IS GOOD SOFTWARE? THE
QUALITY OF THE PRODUCT

• These qualities are also subdivided based on the external and

internal qualities
• External quality is the quality of the finished product, the quality
as it appears to the external world, as it comes of the end of the
assembly line. These are factors that are clearly visible to end
users.
• Internal quality is the quality of the product as it is being
constructed, while it is on the assembly line. It is concerned with
internal technical issues of the software
WHAT IS GOOD SOFTWARE? THE
QUALITY OF THE PRODUCT
• In general, users of the software only care about external
qualities, but it is the internal qualities – which deal largely with
the structure of the software – that help developers achieve
external qualities
External quality Integrity
Reliability
Usability
Correctness
Internal quality Efficiency
Maintainability
Testability
Flexibility
Interoperability
Reusability
Portability
Figure 1.2 External and Internal Qualities of Software
What Is Good Software?
The QUALITY OF THE PROCESS

• Quality of the development and maintenance process is as

important as the product quality
• The development process needs to be modeled
• Modeling will address questions such as
– Where to find a particular kind of fault
– How to find faults earlier
– How to build in fault tolerance
– What are alternative activities
What Is Good Software?
The QUALITY OF THE PROCESS

• This is similar to the process called software quality

management (SQM)
• SQM is a management process that aims to develop and
manage the quality of the software in such a way so to best
ensure that the product meets the quality standards expected
by the customer while also meeting any necessary regulatory
and developer requirements is any
What Is Good Software?
The QUALITY OF THE PROCESS

• The following are the Quality management activities that can

ensure the quality of the software

1. Quality assurance
2. Quality planning
3. Quality control
What Is Good Software?
The QUALITY OF THE PROCESS

• The following are the Quality management activities that can

ensure the quality of the software

Quality assurance
– sets up an organized and logical set of organizational
processes and deciding on that software development
standards
– industry best practices paired with those organizational
processes, software developers stand a better chance of
producing higher quality software.
What Is Good Software?
The QUALITY OF THE PROCESS

• The following are the Quality management activities that can

ensure the quality of the software

Quality planning
- Quality planning works at a more granular, project-based level,
- defining the quality attributes to be associated with the output
of the project, and
- how those attributes should be assessed.
What Is Good Software?
The QUALITY OF THE PROCESS

• The following are the Quality management activities that can

ensure the quality of the software

Quality control
- The quality control team tests and reviews software at its
various stages to ensure quality assurance processes and
standards at both the organizational and project level are being
followed.
WHAT IS GOOD SOFTWARE?
THE QUALITY IN THE CONTEXT OF THE
BUSINESS ENVIRONMENT
• Models for process improvement
– SEI’s Capability Maturity Model (CMM)
– ISO 9000
– Software Process Improvement and Capability
dEtermination (SPICE)
WHAT IS GOOD SOFTWARE?
THE QUALITY IN THE CONTEXT OF THE
BUSINESS ENVIRONMENT

✓ Business value is as important as technical value

✓ Business value (in relationship to technical value)
must be quantified
✓ A common approach: return on investment (ROI)
– what is given up for other purposes
✓ ROI is interpreted in different terms: reducing
costs, predicting savings, improving productivity,
and costs (efforts and resources)
 Part 3
Module 1 Submodule 2
REASONS FOR SOFTWARE FAILURE

• schedule slippage (software is not really

time)
• cost overruns ( the software was abandoned
in the middle because of the high costing
requirement)
• does not solve user's problem (not useful)
• poor quality
• poor maintainability
WHAT LEADS TO SUCH PROBLEMS

• No planning of development work

• Deliverables to user not identified
• Poor understanding of user requirement
• No control of review (review and control
systematically ; cost time and resources)
• Technical incompetence (the need to
understand the changes in technologies, new
tools and techniques in recent trends in
technologies )
• Poor understanding of cost and effort both from
user and the developer.
CHALLENGES FACING SOFTWARE
ENGINEERING

• Legacy challenge.
• Heterogeneity challenge.
• Delivery challenge.
WHO DOES SOFTWARE ENGINEERING?

• Customer: the company, organization, or

person who pays for the software system
• Developer: the company, organization, or
person who is building the software system
• User: the person or people who will actually
use the system
Who Does Software Engineering? (cont.)

Participants (stakeholders)
in a software development
project
MEMBERS OF THE DEVELOPMENT TEAM

• Requirement analysts: work with the customers to identify and

document the requirements
• Designers: generate a system-level description of what the system is
suppose to do
• Programmers: write lines of code to implement the design
• Testers: catch faults
• Trainers: show users how to use the system
• Maintenance team: fix faults that show up later
• Librarians: prepare and store documents such as software
requirements
• Configuration management team: maintain correspondence among
various artifacts
MEMBERS OF THE DEVELOPMENT TEAM

Typical roles played by the members of a development

team
 END OF
MODULE 1
SUBMODULE 2

References
• http://www.onquality.info/wp-content/uploads/2010/04/5qualitydef-1.png
• https://www.tutorialspoint.com/software_quality_management/software_quality_management_factors.
htm
• https://resources.saylor.org/wwwresources/archived/site/wp-content/uploads/2012/11/Software-
quality-definitions-and-strategic-issues.pdf
• https://en.wikipedia.org/wiki/Software_quality_management
• https://searchsoftwarequality.techtarget.com/definition/Capability-Maturity-Model
• https://asq.org/quality-resources/iso-9000
• https://en.wikipedia.org/wiki/ISO/IEC_15504
• https://dzone.com/articles/the-challenges-of-legacy-software
• https://codersera.com/blog/challenges-software-developers-face-today/
 INFORMATION AND
SOFTWARE ASSURANCE
AND SECURITY
 MODULE 2
SOFTWARE DESIGN

• Software Architecture types, levels and documentation

• Object modeling terms and concepts, including objects,
attributes, methods, messages, classes, and instances
• Create an Entity Relationship Diagram, Data flow diagram,
Unified Modeling Language, Use Case diagram, Sequence
diagram, and Activity diagram
 MODULE 2
Submodule 1
Concept of Software Architecture

• Software Architecture types, levels and documentation

• Object modeling terms and concepts, including objects,
attributes, methods, messages, classes, and instances
 PART 1
Of Submodule 1 in
Module 2
 SOFTWARE ARCHITECTURE

• Software architecture is commonly used to

describe the organization of software systems.
• An architecture is the definition of the key elements
that constitute a system, their relationships, and
any constraints.
• Generally speaking, architectures of software-
based systems can be classified into several
categories:
 SOFTWARE ARCHITECTURES CATEGORIES:

1. Business architecture
2. Physical architecture
3. Logical architecture
4. Functional architecture
5. Software architecture
6. Technical architecture
7. System architecture
8. Deployment architecture
 SOFTWARE ARCHITECTURES CATEGORIES:

1. Business architecture
- describes the structure of the business tasks performed
by the organization
- these are created by business analysts
 SOFTWARE ARCHITECTURES CATEGORIES:

2. Physical architecture
- describes the structure of the hardware platform(s) or
network(s) on which the system will operate
- physical architecture of a system
 SOFTWARE ARCHITECTURES CATEGORIES:

3. Logical architecture
- describes the structure of the business and application objects.
- Is often part of an object-oriented view of a system.
- Is often created by an object analyst
 SOFTWARE ARCHITECTURES CATEGORIES:

4. Functional architecture
- describes the structure of the potential use cases and the
requirements from a user’s point of view.
- Is often part of an object-oriented view of a system
 SOFTWARE ARCHITECTURES CATEGORIES:

5. Software architecture
- describe the structure of the system into layers, such as
OSI (Open systems interconnection) or layered
architecture of UNIX operating system.
- decomposed to client and server
 SOFTWARE ARCHITECTURES CATEGORIES:

6. Technical architecture
- describes the structure of the major interfaces in the software
architecture.
- Elements include
1. application programming interfaces (APIs),
2. middleware,
3. database management systems,
4. graphical user interfaces, and
5. other glueware or bridgeware needed to interface
components
 SOFTWARE ARCHITECTURES CATEGORIES:

6. Technical architecture
- Decisions to use CORBA, DCOM, Java RMI, or
RPC or even cloud computing, with a protocol such
as HTTP, SOAP, REST, or JSON, would be
reflected in this type of system architecture
 SOFTWARE ARCHITECTURES CATEGORIES:

7. System architecture
- describes the structure of the business, application, and
technical objects and their relationships.
- the description is often created by a systems analysts
 SOFTWARE ARCHITECTURES CATEGORIES:

8. Deployment architecture
- describes the structure of the mapping of the system and
technical architectures onto the physical architecture.
- It includes two views:
1. a static view of the basic files that will be necessary
2. a dynamic view of the concurrent processes and threads,
and the mechanisms for their synchronization and communication.
 SOFTWARE ARCHITECTURES CATEGORIES:

8. Deployment architecture
- a thread on a particular computer or to have an autonomous
agent performing computation would be reflected in this type of
architecture
 SOFTWARE ARCHITECTURE IMPORTANCE

• Software architecture are an enabler for

communication between stakeholders
• The architecture highlights early design
decisions that will have a profound impact on
all software engineering work that follows
 ARCHITECTURAL DESIGN
• The software must be placed into context
• The design should define the external entities (other systems,
devices, people) that the software interacts with and the nature of
the interaction
• A set of architectural archetypes should be identified
• An archetype is an abstraction (similar to a class) that represents
one element of system behavior
• The designer specifies the structure of the system by defining and
refining software components that implement each archetype
 DATA DESIGN (Data modeling concepts)

At the architectural level …

• Design databases to support the application
architecture
• Design of methods for ‘mining’ the content of
multiple databases
• Navigate through existing databases to extract
information.
• Design of a data warehouse
 ENTITY RELATIONSHIP DIAGRAM

• Entity-relationship diagram (ERD) represents all

data objects entered, stored, transformed, and
produced within an application
 ENTITY OR ENTITY TYPES
• An ERD is consists of entities or data objects, data attributes
and relationships with the entities.

• An entity or an entity type or a data object is a representation

of something that has several different properties (attributes)
that must be understood by software. It is anything that produce
or consumes information
 ENTITY OR ENTITY TYPES
Entities:
• Entity instance–person, place, object, event, concept
(often corresponds to a row in a table)
• Entity Type–collection of entities (often corresponds to
a table)
 ENTITY OR ENTITY TYPES
Example of entity or entity types
- A person or a car
- both can have different properties or attributes

Attribute–property or characteristic of an entity or relationship type (often

corresponds to a field in a table)

Figure 2.1
Example of an entity
 RELATIONSHIPS
Entities are connected to one another in different ways.

Example:
- A person and a car

Figure 2.2a A basic connection between data and objects

Figure 2.2b Relationships between data objects
 RELATIONSHIPS

Relationships:
• Relationship instance–link between entities (corresponds to
primary key-foreign key equivalencies in related tables)
• Relationship type–category of relationship…link between entity
types
a) Relationship type
(Completes)

b) Relationship
instances

Figure 2.3
Illustration of relationship types and relationship instances
 PART 2
Of Submodule 1 in
Module 2
 RELATIONSHIPS

• Relationships can have attributes

• Two entities can have more than one type of
relationship between them (multiple
relationships)
• Associative Entity–combination of relationship
and entity
 RELATIONSHIPS
One-to-One (1:1)
• Each entity in the relationship will have exactly one related entity
One-to-Many (1:M) or Many-to-One (M:1)
• An entity on one side of the relationship can have many related entities, but
an entity on the other side will have a maximum of one related entity
Many-to-Many (M:M)
• Entities on both sides of the relationship can have many related entities on
the other side
RELATIONSHIPS (one to many)

A patient history is A patient must have recorded

recorded for one and only at least one history, and can
one patient have many

Figure 2.4
ERD: one to many relationship
RELATIONSHIPS (many to many)

A project must be assigned to at An employee can be assigned to

least one employee, and may be any number of projects, or may not
assigned to many be assigned to any at all

Figure 2.5
ERD: many to many relationship
 RELATIONSHIPS (one to one)

A person is
married to at most
one other person,
or may not be
married at all

Figure 2.6
ERD: one to one relationship
 RELATIONSHIPS
Degree of a relationship is the number of entity types that participate
in it

• Unary Relationship
• Binary Relationship
• Ternary Relationship
 RELATIONSHIPS(Unary)

Entities of
One entity two
related to different Entities of three
another of different types
types related related to each
the same to each other
entity type other

Figure 2.7
ERD: Unary relationship
RELATIONSHIPS(Binary)

Figure 2.8
ERD: Unary relationship
RELATIONSHIPS(Ternary)

Figure 2.9
ERD: Unary relationship
 STRUCTURED DESIGN
A mapping technique, called structured design is often characterized
as a data flow-oriented design method because it provides a
convenient transition from a data flow diagram to software
architecture.
• The transition from information flow (represented as a DFD) to
program structure is accomplished as part of a six step process.
 STRUCTURED DESIGN
These six step processes are:
(1) the type of information flow is established,
(2) flow boundaries are indicated,
(3) the DFD is mapped into the program structure,
(4) control hierarchy is defined,
(5) the resultant structure is refined using design measures and
heuristics, and
(6) the architectural description is refined and elaborated.
 DATA FLOW DIAGRAM

• A data flow diagram (DFD) is a graphical

representation of the "flow" of data through an
information modeling its process aspects.
• A DFD shows what kinds of information will be input
to and output from the system, where the data will
come from and go to, and where the data will be
stored.
 DATA FLOW DIAGRAM

• The DFD takes an input-process-output

view of a system. Data objects are
represented by labeled arrows, and
• Transformations are represented by
circles (also called bubbles).
 DATA FLOW DIAGRAM

• The DFD is presented in a hierarchical

fashion.
• Subsequent data flow diagrams refine the
context diagram, providing increasing detail
with each subsequent level.
DFD SYMBOLS

Figure 2.10
Data flow diagram symbols
 CREATING A SET OF DFD
Here are simple guidelines
(1) the level 0 data flow diagram should depict the software/system as a
single bubble;
(2) primary input and output should be carefully noted;
(3) Refinement should begin by isolating candidate processes, data
objects, and data stores to be represented at the next level;
(4) all arrows and bubbles should be labeled with meaningful names;
(5) information flow continuity must be maintained from level to level, and
(6) one bubble at a time should be refined
 Before we proceed to diagram 0, lets discussed what
SafeHome does.

• The SafeHome security function enables the homeowner to

configure the security system when it is installed, monitors all
sensors connected to the security system, and interacts with the
homeowner through the Internet, a PC, or a control panel.
• During installation, the SafeHome PC is used to program and
configure the system.
• Each sensor is assigned a number and type, a master password
is programmed for arming and disarming the system, and
telephone number(s) are input for dialing when a sensor event
occurs.
 Before we proceed to diagram 0, lets discussed what
SafeHome does.

• When a sensor event is recognized, the software invokes an

audible alarm attached to the system. After a delay time that is
specified by the homeowner during system configuration
activities, the software dials a telephone number of a monitoring
service, provides information about the location, reporting the
nature of the event that has been detected.
 Before we proceed to diagram 0, lets discussed what
SafeHome does.

• The telephone number will be redialed every 20 seconds

until telephone connection is obtained.
• The homeowner receives security information via a
control panel, the PC, or a browser, collectively called an
interface. The interface displays prompting messages and
system status information on the control panel, the PC, or
the browser window. Homeowner interaction takes the
following form . . .
EXAMPLE:
SAFEHOME SECURITY FUNCTION
Diagram 0

Figure 2.11
DFD: Diagram 0

Nouns are either external entities (boxes), data or control objects (arrows), or data stores (double lines).
EXAMPLE:SAFEHOME SECURITY
FUNCTION Diagram 1

Figure 2.12
DFD: Diagram 1
EXAMPLE:
SAFEHOME SECURITY FUNCTION
Diagram 2

Figure 2.13
DFD: Diagram 2
 END OF
MODULE 2
SUBMODULE 1

References:
• Pressman, R. S. (2015). Software engineering: a practitioners approach.
New York, NY: McGraw-Hill
• Douglass, B. P. (2016). Agile systems engineering. Waltham, MA: Morgan
Kaufmann.
• Leach, R. J. (2016). Introduction to software engineering. Boca Raton:
Chapman & Hall/CRC.
• Laplante, P. A. (2018). Requirements engineering for software and
systems. Boca Raton: CRC Press.
 MODULE 2
Submodule 2
Software Design Tools

• Unified Modeling Language

• Use Case diagram
• Sequence diagram
• Activity diagram
 Part 1
Module 2 Submodule 2
UNIFIED MODELING LANGUAGE
 UNIFIED MODELING LANGUAGE
• Unified Modeling Language (UML) is “ a standard language for
writing blueprints. UML may be used to visualize, specify,
construct, and document the artifacts of a software-intensive
system”
 Just as building architects create blueprints
 Software architects create UML diagrams
 UNIFIED MODELING LANGUAGE
Two main types of diagrams in the UML
1. Structural Diagram are used to describe the relationship
between classes.
2. Behavioral Diagram can be used to describe the interaction
between people and the thing we refer to as a use case, or how
the actors use the system.
 UNIFIED MODELING LANGUAGE
 It all begins with the construction of a model.
 A model is an abstraction of the underlying problem. The domain is the
actual world from which the problem comes.
 Models consist of objects that interact by sending each other messages.
Think of an object as "alive." Objects have things they know (attributes)
and things they can do (behaviors or operations). The values of an
object's attributes determine its state.
 Classes are the "blueprints" for objects. A class wraps attributes (data)
and behaviors (methods or functions) into a single distinct entity. Objects
are instances of classes.
OBJECTS CONCEPTS

Figure 2.14
Example of an object Parent
OBJECTS CONCEPTS

Figure 2.15
Example of an object Child
OBJECT CONCEPTS AND TERMS

Figure 2.16 Student object and Instructor object

Attributes
• If objects are similar to nouns, attributes are similar
to adjectives that describe the characteristics of an
object
• Some objects might have a few attributes; others
might have dozens state
Methods

• A method defines specific tasks that an object

can perform
• Just as objects are similar to nouns and
attributes are similar to adjectives, methods
resemble verbs that describe what and how an
object does something
USE CASE
 USE CASE DIAGRAM
• Use case diagrams describe what a system does from
the standpoint of an external observer. The emphasis is on
what a system does rather than how.
• Use case diagrams are closely connected to scenarios. A
scenario is an example of what happens when someone
interacts with the system. Here is a scenario for a
managing user digital files.
 USE CASE DIAGRAM EXAMPLE
• Let us say, there is a software application for managing digital music files,
similar to Apple’s iTunes software.
• Some of the things the software might do include:
✓ Download an MP3 music file and store it in the application’s library.
✓ Capture streaming music and store it in the application’s library.
✓ Manage the application’s library (e.g., delete songs or organize them in
playlists).
✓ Burn a list of the songs in the library onto a CD.
✓ Load a list of the songs in the library onto an iPod or MP3 player.
✓ Convert a song from MP3 format to AAC format and vice versa.
 USE CASE DIAGRAM EXAMPLE
• A use case describes how a user interacts with the
system by defining the steps required to accomplish a
specific goal (e.g., burning a list of songs onto a CD).
• A use case provides a big picture of the functionality of
the system.
USE CASE DIAGRAM EXAMPLE

Figure 2.17
Example of Use case diagram
USE CASE DIAGRAM EXAMPLE

Figure 2.18
A use case representing
duplicated activity
SEQUENCE DIAGRAM
 SEQUENCE DIAGRAM
• A sequence diagram is used to show the dynamic
communications between objects during execution of a task. It
shows the temporal order in which messages are sent between
the objects to accomplish that task.
• Sequence diagrams can be used to show the interactions in one
use case or in one scenario of the software system.
SEQUENCE DIAGRAM

Figure 2.19
Example of sequence diagram of a drawing program
 SEQUENCE DIAGRAM

Figure 2.20
Example of sequence diagram of a drawing program with loops
 Part 2
Module 2 Submodule 2
SEQUENCE DIAGRAM

Figure 2.21
Special features included in a sequence diagram
SEQUENCE DIAGRAM: another example

Figure 2.22
Another example of sequence diagram
ACTIVITY DIAGRAM
 ACTIVITY DIAGRAM
• A UML activity diagram depicts the dynamic behavior of a
system or part of a system through the flow of control between
actions that the system performs.
• It is like a flowchart except that an activity diagram can show
concurrent flows.
 ACTIVITY DIAGRAM
• Components:
- action node (rounded rectangle) – tasked performed
by the software system
- flow of control (arrows) – arrow between two action
nodes indicate that the first node will be performed
following the second node
- initial node (solid black dot) – starting point
 ACTIVITY DIAGRAM
- final node (a black dot surrounded by a black circle) –
end of activity
- separation of activities (fork) – consists of one arrow
pointing to it and two or more arrows pointing out
 ACTIVITY DIAGRAM
- synchronization of concurrent flow of control (join) –
a horizontal black bar with two or more incoming arrows
and one outgoing arrow
- decision node (diamond with incoming arrow and two
or more outgoing arrows) – corresponds to a branch in
the flow control based on a condition. Each outgoing
arrow is labeled with a guard (a condition inside square
brackets)
ACTIVITY DIAGRAM

Figure 2.23
Example of an activity diagram
 ACTIVITY DIAGRAM
• Often, the exact division of labor does not matter. But if you do
want to indicate how the actions are divided among the
participants, you can decorate the activity diagram with
swimlanes.
• Swimlanes, as the name implies, are formed by dividing the
diagram into strips or “lanes,” each of which corresponds to one
of the participants.
ACTIVITY DIAGRAM

Figure 2.24
Example of an activity diagram
with swimlanes
 ACTIVITY DIAGRAM
An Activity Diagram resembles a horizontal flowchart that shows the actions
and events as they occur. Activity diagrams show the order in which the
actions take place and identify the outcomes.
Diagram Purpose
• Activity Diagram is typically used for modeling the logic captured in a
specific use case in a use case diagram. Activity diagram can also be
used to model a specific Actor's workflow within the entire system. Activity
diagram can also be used independent of use cases for other purposes
such as to model business process of a system, to model detailed logic of
business rules etc. Activity diagram shows all potential sequence flows in
an activity.
ACTIVITY DIAGRAM EXAMPLE

Figure 2.25
Another example of an activity diagram
 END OF
MODULE 2
SUBMODULE 2

References:
• Pressman, R. S. (2015). Software engineering: a practitioners approach.
New York, NY: McGraw-Hill
• Douglass, B. P. (2016). Agile systems engineering. Waltham, MA: Morgan
Kaufmann.
• Leach, R. J. (2016). Introduction to software engineering. Boca Raton:
Chapman & Hall/CRC.
• Laplante, P. A. (2018). Requirements engineering for software and
systems. Boca Raton: CRC Press.
 INFORMATION AND
SOFTWARE ASSURANCE
AND SECURITY
 MODULE 3

SOFTWARE CONSTRUCTION AND TESTING

• Software construction in the context of software development

• How software is constructed
• Good qualities of a software
• Test plan, test cases and test execution
• Application of the software quality are based on internal and external factors
• Software that meets the standard
 PART 1
Of Submodule 1 in
Module 3
 Module 3

Submodule 1
Introduction to Software construction
and testing
• Software construction in the context of software
development
• Software is constructed
• Good qualities of a software
• Test plan, test cases and test execution
SOFTWARE CONSTRUCTION
SOFTWARE CONSTRUCTION is a fundamental act of
software engineering: the construction of working
meaningful software through a combination of coding,
validation, and testing (unit testing) by a programmer.
SOFTWARE CONSTRUCTION
Construction Activities
Problem
Definition

Corrective
Detailed Design Maintenan
ce
Requirements
Development

Construction Coding and

Planning Debugging Integration

Integration
Software Testing
Architectur Unit Testing
e

System
Testing

Figure 3-1
Construction activities are shown inside the gray circle
DETAILED TASKS INVOLVED IN CONSTRUCTION
• Verifying that the groundwork has been laid so
that construction can proceed successfully
• Determining how your code will be tested
• Designing and writing classes and routines
• Creating and naming variables and named
constants
• Selecting control structures and organizing
blocks of statements
DETAILED TASKS INVOLVED IN CONSTRUCTION
• Unit testing, integration testing, and debugging
your own code
• Reviewing other team members’ low-level
designs and code and having them review yours
• Polishing code by carefully formatting and
commenting it
• Integrating software components that were
created separately
• Tuning code to make it smaller and faster
WHY IS SOFTWARE CONSTRUCTION
IMPORTANT?
Some Reasons
• Construction is a large part of
software development
WHY IS SOFTWARE CONSTRUCTION
IMPORTANT?
Some Reasons
• Construction is the central activity
in software development
WHY IS SOFTWARE CONSTRUCTION
IMPORTANT?

Some Reasons
• With a focus on construction, the
individual programmer’s
productivity can improve
enormously
WHY IS SOFTWARE CONSTRUCTION
IMPORTANT?

Some Reasons
• Construction’s product, the source
code, is often the only accurate
description of the software
WHY IS SOFTWARE CONSTRUCTION
IMPORTANT?

Some Reasons
• Construction is the only activity
that’s guaranteed to be done
SOFTWARE CONSTRUCTION STRATEGIES

High-level to low-
• TOP-DOWN
level; user interface
to detail logic
• BOTTOM-UP Reverse of the above

• MIDDLE-OUT Some of both

 QUALITY AND CONSTRUCTION

GOAL
• The goal of software construction is to build a product
that satisfies the quality requirements
• “Good enough software” Not excellent software !
IT’S ALL ABOUT QUALITY
• How do you ensure that the software
• does what it should?
• does it in the correct way?
• does it robust?
• is reliable?
• is easy to use?
• is easy to change?
• is easy to correct?
• is easy to test?
 WHAT IS SOFTWARE QUALITY ?

Formal Definitions
• The totality of features and characteristics of a product or
service that bear on its ability to satisfy stated or implied
needs. (ISO 8402: 1986, 3.1)
• The degree to which a system, component, or process
meets specified requirements. (IEEE)
• A product that satisfies the stakeholders needs (Compliant
Product + Good Quality + Delivery Within
Budget/Schedule.)
 SOFTWARE QUALITY

• Software has both external and

internal quality characteristics.
External characteristics are
characteristics that a user of the
software product is aware of,
including
QUALITY IS A COLLECTION OF “…ILITIES”
Quality Description
reliability the ability to operate error free

reusability the ability to use parts of the software to solve other

software problems

extendibility the ability to have enhancement changes made easily

understandability the ability to understand the software readily, in
order to change/fix it (also called maintainability)
efficiency the speed and compactness of the software
usability the ability to use the software easily
testability the ability to construct and execute test cases easily
portability the ability to move the software easily from one
environment to another
functionality what the product does

Table 3.1 Quality and its description

QUALITY AND SOFTWARE CONSTRUCTION
• Reliability [correctness + robustness]
It should be easier to build software that functions correctly, and
easier to guarantee what it does.
Run and test the software as often as possible
• Reusability [modifiability + extendibility]
It should build less software!
Software should be easier to modify.
Redesign and improve the source code as often as possible
• Functionality [+ usability]
Ensure that the software does what the user expects and does this
in an easy to use way.
Build software as early as possible and give it to the user as often
as possible
 PART 2
Of Submodule 1 in
Module 3
TESTING QUALITY
Quality means “conformance to requirements”
✓The best testers can only catch defects that are contrary
to specification.
✓Testing does not make the software perfect.
✓If an organization does not have good requirements
engineering practices then it will be very hard to deliver
software that fills the users’ needs, because the product
team does not really know what those needs are.
SOFTWARE TESTING
• The goal of software testing is to discover defects in
software, not to show that none are present.
• That is, software testing cannot prove that software is
correct (meets its specifications) for any realistic
system.
• The best defense against residual software errors is
proper design and coding practice.
SOFTWARE TESTING
• The goal of the testing process is to uncover faults
left by the developers.
• The goal of the development process is to enable
the developers to produce a satisfactory version of
the software within budget and on schedule.
• Thus, the two goals are somewhat in opposition.
Balancing them is one of the goals of the project
management.
SOFTWARE TESTING
• Automated software testing can be the following:
- Simple shell commands
- Test harnesses
- Or large as CASE (Computer aided software
engineering)
• Software testing can be open source or commercial
software testing tools
THREE ESSENTIALS OF SYSTEMATIC
TESTING
• Test Scripts
• Test Harnesses
• Test Plans

• These three essentials are presented in increasing

order of complexity
THREE ESSENTIALS OF SYSTEMATIC
TESTING: Test Script
• A test script is nothing more than a simple, elegant
way of providing a smooth way of getting data into an
existing program unit.
THREE ESSENTIALS OF SYSTEMATIC
TESTING: Test Harness
• A test harness provides a set of input values for the
arguments to a function and produces a systematic
way of saving and examining the function’s output on
these inputs.
• This is a typical feature of many modern IDEs and
nearly all CASE tools.
THREE ESSENTIALS OF SYSTEMATIC
TESTING: Test Plan
• A test plan is more than a collection of test cases and
a database to contain the results of these test cases.
• It is a strategy for systematically examining the
software to detect faults, then analyzing these faults
and determining an appropriate set of actions.
TEST PLANS
The goal of test planning is to establish the list of tasks which, if performed,
will identify all the requirements that have not been met in the software.
The main work product is the test plan.
✓The test plan documents the overall approach to the test. In many
ways, the test plan serves as a summary of the test activities that will
be performed.
✓It shows how the tests will be organized, and outlines all of the
testers’ needs which must be met in order to properly carry out the
test.
✓The test plan should be inspected by members of the engineering
team and senior managers.
TEST PLAN OUTLINE
TEST PLAN OUTLINE
TEST PLAN OUTLINE
TEST PLAN OUTLINE
TEST PLAN OUTLINE
TEST PLAN OUTLINE
TEST PLAN OUTLINE
TEST PLAN OUTLINE
TEST PLAN OUTLINE
ELEMENTS THAT CAN AFFECT A TEST
PLAN
• There should be a precise list of requirements that must be
tested
• The test plan must be consistent with the goals of the
organization
• After the essential requirements are tested, the next set of test
cases should consider the cases that most users are likely to
want.
• Next is to test the features that are very unlikely to be
encountered in practice
ELEMENTS THAT CAN AFFECT A TEST
PLAN
• The test plan should specify the operational environment
• The plan must allocate enough time to used for testing
• The plan must have adequate hardware and software resources
for testing
• There must be sufficient amount of available free computing
cycle resources used for testing
ELEMENTS THAT CAN AFFECT A TEST
PLAN
• The plan must address the available tools that can be used for
testing data analysis
• The plan must take account of any existing standards and
practices manual
• The plan must consider the type of software (OO, procedural,
mixed)
TEST PLAN
• The important thing is that a realistic plan must be
developed and followed during the software’s
testing. The plan may be influenced by the
organization’s typical software practices.
 TEST AUTOMATION
Test automation is a practice in which testers employ a software tool
to reduce or eliminate repetitive tasks.
▪ This can save the testers a lot of time if many iterations of testing
will be required.
▪ It costs a lot to develop and maintain automated test suites, so it
is generally not worth developing them for tests that will execute
only a few times.
 TEST CASES
A test case is a description of a specific interaction
that a tester will have in order to test a single
behavior of the software.
TEST CASES
• A typical test case is laid out in a table, and includes:
• - A unique name and number
• - A requirement which this test case is exercising
• - Preconditions which describe the state of the software
before the test case (which is often a previous test case that must
always be run before the current test case)
• - Steps that describe the specific steps which make up the
interaction
• - Expected Results which describe the expected state of the
software after the test case is executed
 PART 3
Of Submodule 1 in
Module 3
TEST CASES
•Test cases must be repeatable.
•Good test cases are data-specific and
describe each interaction necessary to repeat
the test exactly.
TEST CASES – GOOD EXAMPLE

Table 3.2 Good example of a test case

TEST CASES – BAD EXAMPLE
Steps 1. Bring up search and replace
2. Enter a lowercase word from the
document in the search term field.
3. Enter a mixed case word in the
replacement field.
4. Verify that case sensitivity is not turned
on and execute the search
Expected 1. Verify that the lowercase word has been
Results replaced with the mixed-case term in
lowercase
Table 3.3 Bad example of a test case
 SMOKE TESTS
• A smoke test is a subset of the test cases that is typically
representative of the overall test plan.
• Smoke tests are good for verifying proper deployment or other
non-invasive changes.
• They are also useful for verifying a build is ready to send to test.
• Smoke tests are not substitute for actual functional testing.
 TEST EXECUTION
The software testers begin executing the test plan after the programmers deliver
the alpha build, or a build that they feel is feature complete.
▪ The alpha should be of high quality—the programmers should feel that it is ready
for release, and as good as they can get it.
 TEST EXECUTION
There are typically several iterations of test execution.
▪ The first iteration focuses on new functionality that has been added since
the last round of testing.
▪ A regression test is a test designed to make sure that a change to one
area of the software has not caused any other part of the software which
had previously passed its tests to stop working.
▪ Regression testing usually involves executing all test cases which have
previously been executed.
▪ There are typically at least two regression tests for any software project.
 DEFECT TRACKING
The defect tracking system is a program that testers use to record and track
defects. It routes each defect between testers, developers, the project
manager and others, following a workflow designed to ensure that the defect
is verified and repaired.
▪ Every defect encountered in the test run is recorded and entered into a
defect tracking system so that it can be prioritized.
 DEFECT TRACKING
• The defect workflow should track the interaction between the testers
who find the defect and the programmers who fix it. It should ensure
that every defect can be properly prioritized and reviewed by all of the
stakeholders to determine whether or not it should be repaired. This
process of review and prioritization referred to as triage.
TEST ENVIRONMENT AND PERFORMANCE
TESTING
Project manager should ask questions regarding desired
performance as early as the vision and scope document
– How many users?
– Concurrency? Peak times?
– Hardware? OS? Security?
– Updates and Maintenance?
TEST EXECUTION
When is testing complete?
– No defects found
– Or defects meet acceptance criteria outlined in test plan

Table 3.4 Acceptance criteria from a test plan

TEST ENVIRONMENT AND PERFORMANCE
TESTING
Adequate performance testing will usually require a large
investment in duplicate hardware and automated performance
evaluation tools.
– ALL hardware should match (routers, firewalls, load
balancers)
– If the organization cannot afford this expense, they should
not be developing the software and should seek another
solution.
 END OF
MODULE 3
SUBMODULE 1

References:
• Code Complete by Steven McConnell
• Introduction to software engineering by
Ronald Leach
• Software Engineering 9 by Ian
Sommerville
 Module 3

Submodule 2
Types of Software Testing

• Different Software Testing Techniques

 PART 1
Of Submodule 2 in
Module 3
• Software testing strategies integrates software test case
design techniques into a well-planned series of steps that
result in the successful construction of software.

• A testing strategy must always incorporate test planning,

test case design, test execution, and the resultant data
collection and evaluation
Generic characteristics of all software testing strategies:
1. Conduct an effective technical reviews
2. Testing begins at the component level and works
“outward” toward the integration of the entire system
3. Different testing techniques for different software
engineering approaches
Generic characteristics of all software testing strategies:
4. Testing is conducted by the developer.
For large project ➔ independent test group
5. Testing and debugging are different activities, but
debugging must be accommodated in any testing strategy
 VERIFICATION AND VALIDATION
• Software Testing is often referred to as verification and
validation (V&V)
• Verification refers to the set of activities that ensure that
software correctly implements a specific function, i.e.

• It asks the question: “Are we building the product

right?”
 VERIFICATION AND VALIDATION
• Validation refers to a different set of activities that ensure
that the software that has been built is traceable to
customer requirements, i.e.

• It asks the question: “Are we building the right

product?”
• From the point of view of the builder, testing can
be considered (psychologically) destructive.
• So the builder treads lightly, designing and
executing tests that will demonstrate that the
program works, rather than uncovering errors.
• Unfortunately, errors will be present. And, if the
software engineer doesn’t find them, the customer
will!
1. That the developer of software should not do any
testing at all;
2. That the software should be "tossed over the wall"
to strangers who will test it mercilessly;
3. That testers get involved with the project only
when the testing steps are about to begin.
SOFTWARE TESTING STRATEGY

Figure 3.2 Spiral Software process

1. A strategy for software testing moves outward along the spiral.
2. Unit testing begins at the vortex of the spiral and concentrates on
each unit of the software as implemented in the source code.
3. Testing progresses by moving outward along the spiral to integration
testing, where the focus is on the design and the construction of the
software architecture.
4. Validation testing is next encountered, where requirements
established as part of software requirement analysis are validated
against the software that has been constructed.
5. Finally, at system testing, where the software and other system
elements are tested as a whole.
SOFTWARE TESTING STRATEGY
In a procedural point of view, testing is a series of four steps that are
implemented sequentially
1. Unit tests: focuses on each module and makes heavy use of
white box testing
2. Integration tests: focuses on the design and construction of
software architecture; black box testing is most prevalent with
limited white box testing.
3. High-order tests: conduct validation and system tests. Makes
use of black box testing exclusively.

Figure 3.3 Sequential steps in testing

• Unit testing focuses verification effort on the smallest unit
of software design - the module.

• Using the detail design description as a guide, important

control paths are tested to uncover errors within the
boundary of the module

• The unit test is always white box-oriented

UNIT TESTING

Figure 3.4 Unit Test

1. Because a module is not a stand-alone program, driver and/or stub
software must be developed for each unit test.
2. A driver is nothing more than a " main program" that accepts test
case data, passes such data to the module (to be tested), and prints
the relevant results.
3. Stubs serve to replace modules that are subordinate (called by) the
module to be tested. A stub or "dummy subprogram" uses the
subordinate module's interface, may do nominal data manipulation,
prints verification of entry, and returns.
4. Drivers and stubs also represent overhead
UNIT TESTING PROCEDURES

Figure 3.5 Unit Test Environment

• Integration testing: technique for constructing the program
structure while at the same time conducting tests to
uncover errors associated with interfacing

Objective: combine unit-tested modules and build a program

structure that has been dictated by design.
Two-types: Top-Down integration; Bottom-up Integration
• Top-down integration testing is an incremental approach
to construction of the software architecture.

• Modules are integrated by moving downward through the

hierarchy
INTEGRATION PROCESS
1. The main control module is used as a test driver and stubs are
substituted for all modules directly subordinate to the main control
module
2. Subordinate stubs are replaced one at a time with actual modules
3. Tests are conducted as each module is integrated
4. On the completion of each set of tests, another stub is replaced with
the real module
5. Regression testing (i.e., conducting all or some of the previous tests)
may be conducted to ensure that new errors have not been
introduced
TOP-DOWN TESTING
For the below program structure, the following test cases may be
derived if top-down integration is conducted:

•Test case 1: Modules A and B are integrated

•Test case 2: Modules A, B and C are integrated
•Test case 3: Modules A., B, C and D are integrated (etc.)

Figure 3.6 Unit Test Environment

• There is a major problem in top-down integration: inadequate testing
at upper levels when data flows at low levels in the hierarchy are
required
Solutions to the above problem
1. Delay many test until stubs are replaced with actual modules; but this can
lead to difficulties in determining the cause of errors and tends to violate the
highly constrained nature of the top-down approach
2. Develop stubs that perform limited functions that simulate the actual
module; but this can lead to significant overhead
3. Perform bottom-up integration
1. Low-level modules are combined into clusters (sometimes
called builds) that perform a specific software subfunction
2. A driver (a control program for testing) is written to
coordinate test case input and output
3. The cluster is tested
4. Drivers are removed and clusters are combined moving
upward in the program structure
 BOTTOM-UP TESTING
Test case 1: Modules E and F are integrated
Test case 2: Modules E, F and G are integrated
Test case 3: Modules E., F, G and H are integrated
Test case 4: Modules E., F, G, H and C are integrated (etc.)
Drivers are used all round.
• Validation testing: ensuring that software functions in a
manner that can be reasonably expected by the customer.
• Achieve through a series of black tests that demonstrate
conformity with requirements.
• A test plan outlines the classes of tests to be conducted,
and a test procedure defines specific test cases that will be
used in an attempt to uncover errors in conformity with
requirements.
• A series of acceptance tests (include both alpha and beta
testing) are conducted with the end users
Alpha testing
1. Is conducted at the developer's site by a customer
2. The developer would supervise
3. Is conducted in a controlled environment

Beta testing
1. Is conducted at one or more customer sites by the end user of the
software
2. The developer is generally not present
3. Is conducted in a "live" environment
• Ultimately, software is only one component of a
larger computer-based system.
• Hence, once software is incorporated with other
system elements (e.g. new hardware, information),
a series of system integration and validation tests
are conducted.
• System testing is a series of different tests whose
primary purpose is to fully exercise the computer-
based system.
• Although each system test has a different purpose,
all work to verify that all system elements have
been properly integrated and perform allocated
functions.
•A recovery test that forces software to fail in a variety of
ways and verifies that recovery is properly performed.

•If recovery is automatic, re-initialization, check-pointing

mechanisms, data recovery, and restart are each evaluated
for correctness
•If recovery is manual, the mean time to repair is evaluated to
determine whether it is within acceptable limits.
•Security testing attempts to verify that protection
mechanisms built into a system will in fact protect it from
improper penetration.

•Particularly important to a computer-based system that

manages sensitive information or is capable of causing
actions that can improperly harm (or benefit) individuals
when targeted.
•Stress Testing is designed to confront programs with
abnormal situations where unusual quantity frequency, or
volume of resources are demanded

•A variation is called sensitivity testing;

Attempts to uncover data combinations within valid input classes that may cause
instability or improper processing
• This mode of testing seeks to test the run-time
performance of software within the context of an integrated
system.
• Extra instrumentation can monitor execution intervals, log
events (e.g., interrupts) as they occur, and sample machine
states on a regular basis
• Use of instrumentation can uncover situations that lead to
degradation and possible system failure
 END OF
MODULE 3
SUBMODULE 2

References:
• Software Engineering 7th edition by Roger S. Pressman
 PART 2
Of Submodule 2 in
Module 3
• Top-down integration testing is an incremental approach
to construction of the software architecture.

• Modules are integrated by moving downward through the

hierarchy
TOP-DOWN TESTING
For the below program structure, the following test cases may be
derived if top-down integration is conducted:

•Test case 1: Modules A and B are integrated

•Test case 2: Modules A, B and C are integrated
•Test case 3: Modules A., B, C and D are integrated (etc.)

Figure 3.6 Integration Testing

• There is a major problem in top-down integration: inadequate testing
at upper levels when data flows at low levels in the hierarchy are
required
Solutions to the above problem
1. Delay many test until stubs are replaced with actual modules; but this can
lead to difficulties in determining the cause of errors and tends to violate the
highly constrained nature of the top-down approach
2. Develop stubs that perform limited functions that simulate the actual
module; but this can lead to significant overhead
3. Perform bottom-up integration
1. Low-level modules are combined into clusters (sometimes
called builds) that perform a specific software subfunction
2. A driver (a control program for testing) is written to
coordinate test case input and output
3. The cluster is tested
4. Drivers are removed and clusters are combined moving
upward in the program structure
 BOTTOM-UP TESTING
Test case 1: Modules E and F are integrated
Test case 2: Modules E, F and G are integrated
Test case 3: Modules E., F, G and H are integrated
Test case 4: Modules E., F, G, H and C are integrated (etc.)
Drivers are used all round.
• Validation testing: ensuring that software functions in a
manner that can be reasonably expected by the customer.
• Achieve through a series of black tests that demonstrate
conformity with requirements.
• A test plan outlines the classes of tests to be conducted,
and a test procedure defines specific test cases that will be
used in an attempt to uncover errors in conformity with
requirements.
• A series of acceptance tests (include both alpha and beta
testing) are conducted with the end users
Alpha testing
1. Is conducted at the developer's site by a customer
2. The developer would supervise
3. Is conducted in a controlled environment

Beta testing
1. Is conducted at one or more customer sites by the end user of the
software
2. The developer is generally not present
3. Is conducted in a "live" environment
• Ultimately, software is only one component of a
larger computer-based system.
• Hence, once software is incorporated with other
system elements (e.g. new hardware, information),
a series of system integration and validation tests
are conducted.
• System testing is a series of different tests whose
primary purpose is to fully exercise the computer-
based system.
• Although each system test has a different purpose,
all work to verify that all system elements have
been properly integrated and perform allocated
functions.
•A recovery test that forces software to fail in a variety of
ways and verifies that recovery is properly performed.

•If recovery is automatic, re-initialization, check-pointing

mechanisms, data recovery, and restart are each evaluated
for correctness
•If recovery is manual, the mean time to repair is evaluated to
determine whether it is within acceptable limits.
•Security testing attempts to verify that protection
mechanisms built into a system will in fact protect it from
improper penetration.

•Particularly important to a computer-based system that

manages sensitive information or is capable of causing
actions that can improperly harm (or benefit) individuals
when targeted.
•Stress Testing is designed to confront programs with
abnormal situations where unusual quantity frequency, or
volume of resources are demanded

•A variation is called sensitivity testing;

Attempts to uncover data combinations within valid input classes that may cause
instability or improper processing
• This mode of testing seeks to test the run-time
performance of software within the context of an integrated
system.
• Extra instrumentation can monitor execution intervals, log
events (e.g., interrupts) as they occur, and sample machine
states on a regular basis
• Use of instrumentation can uncover situations that lead to
degradation and possible system failure
 END OF
MODULE 3
SUBMODULE 2

References:
• Software Engineering 7th edition by
Roger S. Pressman
INFORMATION AND SOFTWARE
ASSURANCE AND SECURITY
 MODULE 4

SYSTEM INTEGRATION

• To understand the overall framework for system

integration management as it relates to the other
project management knowledge areas and the system
life cycle
• To explain project plan execution, its relationship to
project planning, the factors related to successful
results, and tools and techniques to assist in project
plan execution
 Module 4

Submodule 1
Overview of System Integration

• To understand the overall framework for system

integration management as it relates to the other
project management knowledge areas and the system
life cycle
• The term “integration” refers to the software-
development activity in which you combine separate
software components into a single system.
• For small projects, integration might be shorter as
compare to larger projects that takes weeks or
months
• Order of building classes or components affects the
order in which you can integrate them.
• Construction and integration of software should be
done in a correct order.
• When it is done in a wrong order, its harder to code,
harder to test and harder to debug
• None of it will work until all of it works, it can seem as
though it will never be finished
• Easier defect diagnosis
• Fewer defects
• Less scaffolding
• Shorter time to first working product
• Shorter overall development schedules
• Better customer relations
• Improved morale
• Improved chance of project completion
• More reliable schedule estimates
• More accurate status reporting
• Improved code quality
• Less documentation
• Service-oriented Architecture (SOA)
is a way of developing distributed
system consisting a stand-alone web
services that may be executing on
distributed computers in different
geographical regions
• What is distributed systems?
• A Distributed system is a collection
of computers that appears to be a
single system
• It allows hardware and software
resources to be shared
• Supports concurrency with multiple
processors running on different
computers on the network
Figure 4.1 Distributed System
• SOA is an approach to create an
architecture based upon the use of
services, where a service may carry
out some small functions such as
producing data or validating a
customer
• A Web service is a computational or
information resource that may be
used by another program, and it
allows a service provider to provide a
service to an application (service
requestor) that wishes to use the
service.
Figure 4.2 Service Oriented Architecture
SERVICE-ORIENTED ARCHITECTURE IS AN
ARCHITECTURAL STYLE
• Derived from the client-server architectural
style.
• Clients (service consumers or requesters)
and servers (service providers) connected
by a service “bus”.
• Services defined using formal interfaces
(contracts).
• Service bus supports point-to-point
and messaging styles of
communication.
• Support for system qualities, e.g.,
security and transaction management.
WEB SERVICES
• Services provided in a SOA deployed
over the web.
 1960 - 1980 1990 - 2000 2010 – 2050

•Organization Focus •Process Focus •Distributed Functions

•Mainframe Centric •Client Server •Data Centric
•Internal Use •Partial Connectivity •Universal
•Unique Data •EDI File Transfer Interoperability
•Real-time Connectivity
• A Service is a reusable component.
• A Service changes business data
from one state to another.
• A Service is the only way how data
is accessed.
• If you can describe a component in
Web Service Description Language
(WSDL), it is a Service.
 )

• What operations the service supports

and the format of the messages that
are sent and received by the service.
• How the service is accessed - that is,
the binding maps the abstract
interface onto a concrete set of
protocols.
• Where the service is located. This is
usually expressed as a URI (Universal
Resource Identifier).
WSDL service definition

Intro XML namespace declarations

Type declarations
Abstract interface Interface declarations
Message declarations

Concrete Binding declarations

implementation Endpoint declarations
• A WSDL documents describes a web
service.
• It specifies the location of the service,
and the methods of the service using
these major elements:
Element Description

<types> Defines the (XML Schema) data types used by the web
service
<message> Defines the data elements for each operation

<portType> Describes the operations that can be performed and the

messages involved.
<binding> Defines the protocol and data format for each port type
• The <portType> element defines a web service, the
operations that can be performed, and the messages
that are involved.
• The request-response type is the most common
operation type, but WSDL defines four types:
Type Definition

One-way The operation can receive a message but will not return a
response
Request-response The operation can receive a request and will return a
response
Solicit-response The operation can send a request and will wait for a response

Notification The operation can send a message but will not wait for a
response
• One-way operation example:
• A request-response operation example:
• WSDL
bindings
defines the
message
format and
protocol
details for a
web service.
• A request-
response
operation
example:
• SOAP is an application communication protocol
• Is a format for sending and receiving messages
• Is platform independent
• Is based on XML

XML stands for eXtensible Markup Language much like

HTML. It was designed to store and transport data. Its
self-descriptive.
 END OF
MODULE 4
SUBMODULE 1

References:
• Code Complete by Steven McConnell
• Concise guide to software engineering from fundamentals to
application methods by Gerard O’Regan
• Open source software for SOA, IONA Technologies A-Trenaman-
SOA.pdf
• https://www.w3schools.com/xml/xml_wsdl.asp
• https://www.w3schools.com/xml/xml_soap.asp
• https://www.w3schools.com/xml/xml_whatis.asp
 Module 4

Submodule 2

Structure & Specification of System Integration

• To explain project plan execution, its relationship to

project planning, the factors related to successful
results, and tools and techniques to assist in project
plan execution
WEB SERVICE COMPOSITION
Is the mechanism for combining and reusing
existing Web services to create new Web services.

The two web service compositions are:

1.Service choreography
2.Service orchestration
SERVICE ORCHESTRATION
• WS-BPEL is an XML-based language for workflow
specification.
• WS-BPEL is an “orchestration” language.
• Service orchestration defines the sequence and
conditions in which one Web service invokes other
Web services.
• Can be used to create a composite service out of
other services.
SERVICE CHOREOGRAPHY
• WS-CDL is an XML-based language for describing
service “choreography”.
• Choreography defines the allowable message
exchanges between services.
• It is targeted for composing interoperable, peer-to-
peer collaborations between any type of participant
ORCHESTRATION VS. CHOREOGRAPHY

ORCHESTRATION CHOREOGRAPHY
A Single Director In Defines Interaction.
Control.
ORCHESTRATION VS. CHOREOGRAPHY

Orchestration
within
services

Choreography
between
services

Slide 39 of 28
CHOREOGRAPHY PERSPECTIVE
ORCHESTRATION PERSPECTIVE
ORCHESTRATION AND CHOREOGRAPHY
End of service
composition
LEGACY SYSTEM SERVICES
• Legacy systems are old software systems
• Organizations rely on obsolete technology but are
still essential to the business
• Not cost effective to rewrite or replace these
systems
• Many organizations would like to use them in
conjunction with more modern systems

Slide 45 of 28
LEGACY SYSTEM SERVICES
• An important application of services is to provide
access to functionality embedded in legacy systems.
• Legacy systems offer extensive functionality and this
can reduce the cost of service implementation.
• External applications can access this functionality
through the service interfaces.

Slide 46 of 28
LEGACY SYSTEM SERVICES
• Some services provided:
1. A maintenance service. This includes operations to
retrieve a maintenance job according to its job
number, priority, and geographical location and
upload details of maintenance.

Figure 4.2 Services providing access

to a legacy system
Slide 47 of 28
LEGACY SYSTEM SERVICES
• Some services provided:
2. A facilities service. This includes operations to add
and delete new equipment and to modify existing
equipment information

Figure 4.2 Services providing access

to a legacy system

Slide 48 of 28
LEGACY SYSTEM SERVICES
• Some services provided:
3. A logging service. This includes operations to add
new request for service, delete maintenance
requests, and query status of outstanding requests

Figure 4.2 Services providing access

to a legacy system
Slide 49 of 28
CREATING WEB SERVICES FROM LEGACY
CODE
1. Salvaging the legacy code
2. Wrapping the salvaged code and
3. Making the code available as
web service

Slide 51 of 28
• First, locate code worth reusing
• Here a domain expert is required
• Can be supported by automated reverse
engineering tools
• The function processes of business operations are
ways to identify variables or functions.
• There is a n:m relationship between code blocks and
business operations

Slide 52 of 28
• Next step is extract that code and reassemble it as a
separate module with its own interface.
• The by product of this code reengineering process is
a documentation of the existing business operation.
• With the use of data flow tree, it is possible for the
user to decide whether an existing operation,
implemented within a legacy system is worth
reusing

Slide 53 of 28
• Once business operation has been located,
documented and found worthy of reuse, the next
step is to wrap it.
• Provide components extracted from legacy code
with WSDL interface.

Slide 54 of 28
Slide 55 of 28
• Third and last step is to link the web services to the
overlying business processes.
• Proxy component
• On the application server there is a scheduler that
receives incoming messages, determines the web
service and forwards the WSDL contents to a
particular service

Slide 56 of 28
 MAJOR PITFALLS WITH SYSTEM INTEGRATION
PITFALL DESCRIPTION
What is expected has The experience shows that the implemented
delay elements always do not arrive in the expected order
and the tests never proceed or result as foreseen;
therefore, the integration strategy should allow a
great flexibility.
Big-bang not The "big-bang" integration technique is not
appropriate appropriate for a fast detection of faults. It is thus
preferable to verify the interfaces progressively all
along the integration.
Integration plan too The preparation of the integration activities is
late planned too late in the project schedule, typically
when first implemented elements are delivered.
 PROVEN PRACTICES WITH SYSTEM INTEGRATION
PRACTICE DESCRIPTION
Start earlier development The development of assembly tools and verification and
of means validation tools can be as long as the system itself. It should be
started as early as possible as soon as the preliminary design is
nearly frozen.
Integration means seen as The development of integration means (assembly tools,
enabling systems verification, and validation tools) can be seen as enabling
systems, using system definition and system realization
processes . These projects can be led by the project of the
corresponding system-of-interest, but assigned to specific
system blocks, or can be subcontracted as separate projects.
Use coupling matrix A good practice consists in gradually integrating aggregates in
order to detect faults more easily. The use of the coupling
matrix applies for all strategies and especially for the bottom up
integration strategy.
Integration and design The integration responsible should be part of the design team.
teams
 END OF
MODULE 4
SUBMODULE 2

References:
• Software Engineering 7th edition by Roger S. Pressman
• https://en.wikipedia.org/wiki/Service_choreography\
• software engineering 9th edition by Ian Sommerville
• Wrapping legacy software for reuse in a SOA by Harry M. Sneed