Software Engineering

Spring Term 2016

Marymount University
School of Business
Administration
Professor Suydam

Week 8

1
March Class Plan
Case Study 3: Review/Discussion/Questions - All
Database Planning - Reverse Engineer
Chapter 9 Implementation
Chapter 10 Testing & Quality Assurance

2
3
MP3 App A UML DFD

4
5
See link: Course Resources webpage>
Software, Tutorials & Help>Week8

6
• Must use MS Visio 2010 – features deprecated in Visio starting with 2013.
• Download Northwind Access Database (http://www.focusconsulting.ws/MIT210SS16/classnotes/Nwind.accdb)
• Open Database Model Diagram template
 Select Database Tab
 Select Reverse Engineer tool
 Select Data Sources|MS Access Database|Next
 Select OK on UserID/Password dialog (no entry required)
 Navigate to Downloaded Nwinf.accdb and Select
 Check all “T:” boxes|Next |Next|Finish

WebEx Demo 7
8
9
• Introduction
• Implementation: transforming detailed design into valid program
• Detailed design may be done as part of implementation
 Faster
 Less cohesive and less organized
• Writing code, unit testing, debugging, configuration management
• Good Implementations
• Readability
• Maintainability
• Performance
• Traceability
• Correctness
• Completeness
• Other issues:
 Relative importance ?
 Tradeoffs ?
• Coding Guidelines
• Organization-specific
• Important for consistency
• Programmers can get used to them easily
• Usually mandate:
 Indenting, formatting
 Naming conventions (for files, variables etc)
 Language features to use or avoid
10
• Be consistent and highlight meaning
• Naming
 Convey meaning
 Be consistent
 Warning: If you can’t think of a good name chances are you don’t understand or the
design can be improved
 Multicultural issues
• Separating words, capitalization
 c_uses_this_style
 JavaUsesThisOne
• Indentation and Spacing
• Function/Method size -- When is it too big ? When to break ?
• File naming
• Error prone constructs
• Comments
• Types:
 Repeat of the code
 Explanation of the code
 Marker in the code
 Summary of the code
 Description of the code intent
 External references
• Keep up to date !! 11
• Locating and fixing errors in code.
• Errors noticed by testing, inspection, use.
• Four phases
 Stabilization (reproduction)
 Localization
 Correction
 Verification
• Heuristics:
 Some routines will have many errors
 Routines with an error tend to have more
 New code tends to have more error
 Particular ones: languages, parts, coders
• Tools
 Code comparators
 Extended checkers
 Interactive debuggers
 Special libraries
 Others: Profilers, pre/post conditions, test coverage
• Assertions
 Pre-condition: condition your module requires in order to work
 Post-condition: condition that should be true if your module worked
 Assertion: Executable statement that checks a condition and produces an error if it is not met
 Assertions supported by many languages
12
Performance Optimization
• Performance tradeoffs
 Readability ?
 Maintainability ?
• Correctness is usually more important
• Profiler: runs a program and calculates how much time it spends on each part
• Cost-benefit analysis
• Measure before ‘optimizing’

Refactoring - Improving your code style without affecting its behavior

• “Bad Smells”
 Duplicated code
 Long method
 Large class
 Switch statement
 Feature envy
 Intimacy
• Refactorings
 Extract method
 Substitute algorithm
 Move method
 Extract class 13
1. List and explain in your own words three characteristics of a good software
implementation.
Ans: Readability; maintainability; performance; traceability; correctness;
completeness.
Page: 188
2. Briefly discuss the issues associated with naming variables and procedures in a
program.
Ans: Try to highlight the meaning of your code in the name of the variables and
procedures for good identification of their purpose and to communicate to the
reader of the code.
Page: 189
3. List the four phases of the debugging process.
Ans: Stabilization (or reproduction), Localization, Correction, and Verification.
Page: 193-194
14
4. True or false: You should always optimize your code for performance. Why?

Ans: False – Do not worry about the performance of the code at the beginning of
development. Correctness and maintainability are the main focus at first. After
the program is finished, then turn attention to the performance.
Page: 195

5. List three “bad smells” signaling that your code probably should be refactored.

Ans: Duplicated code; long method; large class; switch statements; feature envy;
inappropriate intimacy.
Page: 196

6. List and briefly explain three of the refactorings mentioned in this chapter.

Ans:
a. Extract method – A process that turns a code fragment into its own method;
b. substitute algorithm – A process that replaces the body of a method;
c. move method – A process that moves an algorithm from one class to another
where it makes more sense;
d. extract class – a process that divides into two.
Page:196-197
15
16
• Quality Assurance (QA): activities designed to measure and improve quality in a
product --- and process

• Quality control (QC): activities designed to validate & verify the quality of the
product through detecting faults and “fixing” the defects

• Verification: checking the software conforms to its requirements (did the software
evolve from the requirements properly)

• Validation: checking software meets user requirements (fit to use)

• Error Detection
 Testing: executing program in a controlled environment and
“verifying/validating” output
 Inspections and Reviews
 Formal methods (proving software correct)
 Static analysis detects “error-prone conditions” 17
• Error: a mistake made by a programmer or software engineer which caused the
fault, which in turn may cause a failure

• Fault (defect, bug): condition that may cause a failure in the system

• Failure (problem): inability of system to perform a function according to its spec

due to some fault

• Fault or Failure
 severity (based on consequences)
 priority (based on importance of developing a fix which is in turn based on
severity)

18
• Activity performed for:
 Evaluating product quality
 Improving products by identifying defects and
having them fixed prior to software release.
• Dynamic (running-program) verification of program’s behavior on a finite set of test
cases selected from execution domain Not always
• Testing can NOT prove product works 100%- - - even though we use testing to done !
demonstrate that parts of the software works

Who tests Why test

• Programmers
• Testers/Req. Analyst
• Users
What is tested
• Unit Code testing
• Functional Code testing
• Integration/system testing
• User interface testing
• Acceptance (customer)
• Conformance (standard, laws, etc.)
• Configuration (user vs. developer)
• Performance, stress, security, etc.
How (test cases designed)
• Intuition
• Specification based (black box)
• Code based (white-box)
• Existing cases (regression))

19
Unit Test

Functional Test

Unit Test Component Test

.
. . . System/Regression
. Test
.
Component Test
Functional Test

Unit Test

20
 • Divide the input into several groups,
deemed “equivalent” for purposes of
finding errors.

• Pick one “representative” for each class

used for testing.

• Equivalence classes determined by

req./des. specifications and some
intuition

Equivalence class partitioning is most useful when the requirements are expressed as
a series of conditions. It is less useful when the requirements seem to call for loops.
For example, if we are testing a function that sums all the elements in an array or
vector, it would be hard to decide what the equivalence classes are, and there will be
much difference of opinion; however, the basic idea would still be useful.
• Past experiences show that “Boundaries” are error-prone
• Do equivalence-class partitioning, add test cases for boundaries (at boundary,
outside, inside)
 Reduced cases: consider boundary as falling between numbers
 If boundary is at 12, normal: 11,12,13; reduced: 12,13 (boundary 12 and 13)
• Large number of cases (~3 per boundary)

Note:
This technique produces a large number of test cases, even if only the reduced ones are considered.
In many cases you might need to reduce them even further by considering which cases are most important.
However, do not let the number of test cases become an excuse for not conducting a thorough test.

This technique is applicable only to ordinal variables—that is, those that can be sorted and organized in
intervals. Without this organization there are no special values that can be recognized as boundaries.
Fortunately, many programs deal mostly with this kind of data.
22
• White-Box technique
• Two tasks
1. Analyze number of paths in program
2. Decide which ones to test
• Decreasing coverage:
 Logical paths
 Independent paths
 Branch coverage
 Statement coverage

23
24
• Function of several related variables
• To fully test, we need all possible combinations (of equivalence classes)
• How to reduce testing:
 Coverage analysis
 Assess “important” (e.g. main functionalities) cases
 Test all pairs of relations (but not all combinations)

If all combinations are considered, then there will be 18

different classes (3 x 3 x 2), which is not a small number of test
cases. Using boundary value analysis, we may generate 12
cases for the age variable, 12 for the income variable, and 9 for
the region variable.
This would generate combinations of 12 x 12 x 9, or 1,296,
cases, which is definitely a large number of test cases.

Having more variables or more equivalence classes per variable

complicates the problem even more. It is clear that, for
integration and system testing, the number of test cases can
easily reach thousands or tens of thousands of test cases.

26
• Unit Testing
 Test each individual unit
 Usually done by the programmer
 Test each unit as it is developed (small chunks)
 Keep test cases/results around: 1) Allows for regression testing, 2)
Facilitates refactoring, 3) Tests become documentation !!
• Test-Driven Development
 Write unit-test cases BEFORE the code !
 Tests cases “are” / “becomes” requirements
 Forces development in small steps
 Steps: 1) Write test case & code, 2) Verify (it fails or runs), 3)
Modify code so it succeeds, 4) Rerun test case, previous tests, 5)
Refactor until (success and satisfaction)

27
• Defect Seeding
• Seed the program (component)
• Generate and scatter with “x” number of bugs &
• do not tell the testers.
• - set a % (e. g. 95%) of seed bugs found as stopping criteria
• Suppose “y” number of the “x” seed bugs are found
• If (y/x) > (stopping percentage); stop testing
• If (y/x) ≤ (stopping percentage), keep on testing
• Get a feel of how many bugs may still remain:
• Suppose you discovered “u” non-seeded bugs through
testing
• Set y/x = u/v ; v = (u * x)/y
• Then there is most likely (v-u) bugs still left in the
software.
• Stop Testing
• Simple answer, stop when: 1) All planned test cases are
executed, 2) All those problems that are found are fixed
• Other techniques:
• Stop when you are not finding any more errors
• Defect seeding -- test until all (or % of )the seeded bugs
found
• NOT -- when you ran out of time -- poor planning!
28
• Review: any process involving human testers reading and understanding a
document and then analyzing it with the purpose of detecting errors
• Walkthrough: author explaining document to team of people
• Software inspection: detailed reviews of work in progress, following Fagan’s
method.

Inspection
Steps Elements
1. Planning •Focused on finding defects
2. Overview •Output: list of defects
3. Preparation •Team of:
4. Inspection 3-6 people
5. Rework Author included
6. Follow-Up People working on related efforts
Moderator, reader, scribe

29
 Inspection
• Partially Cost-effective
• Can be applied to intermediate
artifacts
• Catches defects early
• Helps disseminate knowledge
about project and best practices
Testing
• Finds errors cheaper, but
correcting them is expensive
• Can only be applied to code
• Catches defects late (after
implementation)
• Necessary to gauge quality
30
 Formal Methods
• Mathematical techniques used to
prove that a program works
• Used for
requirements/design/algorithm
specification
• Prove that implementation conforms
to spec
• Pre and Post conditions
• Problems:
 Require math training
 Not applicable to all programs
 Only verification, not validation
 Not applicable to all aspects of
program (e.g. UI or
maintainability)
Static Analysis
• Examination of static structures of
design/code for detecting error-prone
conditions (cohesion --- coupling)
• Automatic program tools are more
useful
• Can be applied to:
 Intermediate documents (but in
formal model)
 Source code
 Executable files
• Output needs to be checked by
programmer

31
1. Consider the diagram shown in Figure 10.8.
a. How many logical paths are there? List them all.
b. How many paths are required to cover all the statements?
c. How many paths are required to cover all the branches?

Ans:
a. There are 4 logical paths. Path1: C1-S1-C2 Path2: C1-S1-C2-S3 Path3: C1-C2-S3
Path4: C1-C2
b. In this case 1 path, Path2: C1-S1-C2-S3, would cover all the statements.
c. In this case 2 paths, Path1: C1-S1-C2 and Path2: C1-S1-C2-S3, would cover all the
branches.

Page: 211-212
32
2. In code inspection, what would you set as the condition (e.g., how many
discovered defects) for re-inspection?
Ans: Both the number of problems found and the severity of the problems found would
be used as criteria for re-inspection of any code. Possibly, the past history of the
particular programmer whose work is been inspected could also add to the criteria.
Page: 201

3. List the four techniques discussed to perform verification and validation.

Ans: The four fundamental ones are: inspection/review, testing, formal prove of
correctness, and static analysis.
Page: 200

33
4. List two techniques you can use to perform validation—that is, to ensure your
program meets user requirements.
Ans: Inspections and user evaluation test are used for validation of requirements. The
confirmation of the correct software by the users of this software is the best
validation.
Page: 201

5. Briefly explain the concept of static analysis, and to which software products it can be
applied.
Ans: Static analysis, as reviews and inspections, examines the static structures of
executable and non-executable with the aim of detecting errors and error-prone
conditions. Some of the artifacts that static analysis applies are:
intermediate documents such as design document
source code
executable files
Page: 222-224 34
6. Briefly explain two different ways to decide when to stop testing.
Ans. One way is to use the ratio of seeded errors and real errors to discovered seeded
errors to discovered real errors to project or estimate the number of real errors
that may still be left. Use that estimate to decide if testing may be stopped.
Another way is to observe the problem discovery rate and the accumulative number
of problems discovered. As the accumulative problem discovered start to level
off, then one may start to consider stop testing.
Page: 218-219

7. Consider the simple case of testing 2 variables, X and Y, where X must be a

nonnegative number, and Y must be a number between 25 and 15. Utilizing boundary
value analysis, list the test cases.
Ans: Assuming that the variables X and Y are independent, then:
For variable X: we would have a test case for below boundary, -2.4, at the boundary, 0,
and within the boundary, +200.78.
For variable Y: we would have a test case for below the boundary, -7.3, at the lower
boundary, 15, within the boundary 20, at the upper boundary, 25, and above the
upper boundary, +1002.
Page: 207-208

35
8. Describe the steps involved in a formal inspection process and the role of a
moderator in this process.
Ans: Inspection process goes through several steps:
• Planning for the inspection
• Presentation of the overview of the work product to be inspected
• Preparation for the inspection by the inspectors
• Examining or inspecting the material
• Rework of the defective areas in material
• Follow-up and close out
Moderator is an important person that is appointed during the planning stage.
He/she will ensure that the inspection process is followed. Moderator also
presides over the actual examination of the material and act as the adjudicator
whenever necessary.
Page: 220-221

9. What is the difference between performance testing and stress testing?

Ans: In performance testing, the software is tested against the performance
requirements set by the requirements (e.g. x number of transactions/minute)
In Stress testing, the software is tested to see how and when it degrades beyond the
performance criteria set by the requirements.
Page: 204

36