SOFTWARE ENGINEERING 2

Module 5
Architectural Design
and Implementation
• Apply the fundamentals of software construction as outlines in this course
to an actual software development project.
• Interpret key practical construction considerations such as design,
languages, coding, testing, quality and reuse.
• Discuss the issue of Software Quality and the activities present in a typical
Quality Management process
• Discuss the challenges in software development
• Understand software testing
• Employ correct testing terminology throughout the testing process.
• Execute specific software tests with well-defined objectives and targets.
• Execute program and test evaluations.
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.

Slide 4 of 48
LOW LEVEL SOFTWARE 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
• 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
• Improving code and design

Slide 5 of 48
WHY IS SOFTWARE CONSTRUCTION IMPORTANT?

Some Reasons
• Construction is a large part of software development
• Construction is the central activity in software development
• With a focus on construction, the individual programmer’s productivity
can improve enormously
• Construction’s product, the source code, is often the only accurate
description of the software

Slide 6 of 48
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?

Slide 7 of 48
WHAT IS SOFTWARE QUALITY ?
• Formal Definitions
• A Practical One
• 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.)

Slide 8 of 48
QUALITY IS A COLLECTION OF DIFFERENT
FACTORS
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

Slide 9 of 48
CHALLENGES IN SOFTWARE DEVELOPMENT
• Reliability [correctness + robustness]
It should be easier to build software that functions correct, and
easier to guarantee what it does.
• Reusability [modifiability + extendibility]
It should build less software!
Software should be easier to modify.
• Functionality [+ usability]
Ensure that the software does what the user expects and does this
in an easy to use way.

Slide 10 of 48
SOFTWARE CONSTRUCTION STRATEGIES

• TOP-DOWN  High-level to low-

level; user interface
to detail logic
• BOTTOM-UP  Reverse of the above

• MIDDLE-OUT  Some of both

Slide 11 of 48
QUALITY AND SOFTWARE CONSTRUCTION
• Functionality [+ usability]
• Build software as early as possible and give it to the user
• As often as possible
• Reliability [correctness + robustness]
• Run and test the software
• As often as possible
• Reusability [modifiability + extendibility]
• Redesign and improve the source code
• As often as possible

Slide 12 of 48
CONSTRUCTION PROCESS INFRASTRUCTURE

Slide 13 of 48
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.

Slide 14 of 48
TEST PLANS
The goal of test planning is to establish the list of tasks which, if
performed, will identify all of 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.

Slide 15 of 48
TEST PLAN OUTLINE

Slide 16 of 48
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 are very similar to use cases, in
that they are step-by-step narratives which define a specific interaction between
the user and the software.
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
Test cases must be repeatable.
Good test cases are data-specific, and describe each interaction necessary to
repeat the test exactly.
Slide 17 of 48
TEST CASES – GOOD EXAMPLE

Slide 18 of 48
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

Slide 19 of 48
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.
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.

Slide 20 of 48
TEST EXECUTION
When is testing complete?
– No defects found
– Or defects meet acceptance criteria outlined in test plan

Slide 21 of 48
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.
 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.

Slide 22 of 48
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?
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.

Slide 23 of 48
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.

Slide 24 of 48
TEST AUTOMATION
Test automation is a practice in which testers employ a software
tool to reduce or eliminate repetitive tasks.
 Testers either write scripts or use record-and-playback to
capture user interactions with the software being tested.
 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
executed only a few times.

Slide 25 of 48
OVERVIEW OF 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, text execution, and the resultant data collection and evaluation

Slide 26 of 48
OVERVIEW OF SOFTWARE TESTING STRATEGIES
Generic characteristics of all software testing strategies:
1. Testing begins at the module level and works "outward" toward the
integration of the entire computer-based system
2. Different testing techniques are appropriate at different points in time
3. Testing is conducted by the developer of the software and (for large projects)
an independent test group
4. Testing and debugging are different activities, but debugging must be
accommodated in any testing strategy

Slide 27 of 48
VERIFICATION AND VALIDATION
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?”

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?”

Slide 28 of 48
ORGANIZING FOR SOFTWARE TESTING

Misconceptions in Software testing:

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.

Slide 29 of 48
 SOFTWARE TESTING STRATEGY
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.

Slide 30 of 48
SOFTWARE TESTING STRATEGY

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.

Slide 31 of 48
 UNIT 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

Slide 32 of 48
UNIT TESTING PROCEDURES
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

Slide 33 of 48
INTEGRATION TESTING
• Integration testing: technique for constructing the program
structure while at the same time conducting tests to uncover
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

Slide 34 of 48
TOP-DOWN TESTING
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

Slide 35 of 48
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.)

Slide 36 of 48
TOP-DOWN 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

Slide 37 of 48
BOTTOM-UP TESTING
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

Slide 38 of 48
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.

Slide 39 of 48
VALIDATING TESTING
• 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

Slide 40 of 48
VALIDATING TESTING
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

Slide 41 of 48
SYSTEM TESTING
• 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.

Slide 42 of 48
RECOVERY TESTING
• A system 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.

Slide 43 of 48
SECURITY TESTING
• 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.

Slide 44 of 48
STRESS TESTING
• 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

Slide 45 of 48
PERFORMANCE TESTING
• 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

Slide 46 of 48
Laplante, Phillip A. (2018). Requirements engineering for software systems. CRC Press, Taylor & Francis
Group.
Alagic, Suad (2017). Software Engineering: Specification, Implementation, Verification [e-book].
Leach, Ronald (2016). Introduction to software engineering. CRC Press, Taylor & Francis Group.
Ahmed, Ashfaque (2016). Foundations of software engineering. CRC Press, Taylor & Francis Group
Pressman. (2015). Software Engineering 8th Ed. New York: McGraw-Hill.