1. Software Engineering Spring Term 2017 Marymount University
School of Business Administration
Professor Suydam
Week 9
Chapter 9 Implementation
Chapter 10 Testing & Quality Assurance
Case Study (CS) 3

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

3. Plan for March Classes

4. Chapter 9 Implementation

5. Implementation: Characteristics (think of this in terms of writing a program)
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

6. Implementation: Style issues
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 !!

7. Implementation: Debugging & Assertions
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

8. Implementation: Performance Optimization & Refactoring
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

9. Chap 9 Review Questions - Answers
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:

10. Chap 9 Review Questions -- Answers
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:
Extract method – A process that turns a code fragment into its own method;
substitute algorithm – A process that replaces the body of a method;
move method – A process that moves an algorithm from one class to another where it makes more sense;
extract class – a process that divides into two. Page:

11. Chapter 10 Testing & Quality Assurance

12. Quality
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”

13. Faults and Failures
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)

14. Testing 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
Testing can NOT prove product works 100%- - - even though we use testing to demonstrate that parts of the software works
Not always
done !
Who tests
Programmers
Testers/Req. Analyst
Users
Why test
Acceptance (customer)
Conformance (standard, laws, etc.)
Configuration (user vs. developer)
Performance, stress, security, etc.
What is tested
Unit Code testing
Functional Code testing
Integration/system testing
User interface testing
How (test cases designed)
Intuition
Specification based (black box)
Code based (white-box)
Existing cases (regression))

15. Progression of Testing
Unit Test .
Functional Test
Component Test
System/Regression
Test

16. Equivalence Class Partitioning
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.

17. Boundary Value Analysis (A Black-Box technique)
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.

18. Path Analysis White-Box technique Two tasks
Analyze number of paths in program
Decide which ones to test
Decreasing coverage:
Logical paths
Independent paths
Branch coverage
Statement coverage

19. Linearly Independent Set of Paths

20. Total # of Paths and Linearly Independent Paths

21. Combinations of Conditions
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.

22. Testing 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)

23. Testing Defect Seeding Stop Testing 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!

24. Inspections and Reviews
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
Planning
Overview
Preparation
Rework
Follow-Up
Focused on finding defects
Output: list of defects
Team of:
3-6 people
Author included
People working on related efforts
Moderator, reader, scribe

25. Inspections vs Testing
Inspections vs Testing & Formal Methods Summary
Inspection
Testing
Partially Cost-effective
Can be applied to intermediate artifacts
Catches defects early
Helps disseminate knowledge about project and best practices
Finds errors cheaper, but correcting them is expensive
Can only be applied to code
Catches defects late (after implementation)
Necessary to gauge quality
Formal & Static Methods Summary
Formal Methods
Static Analysis
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)
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

26. Chap 10 Review Questions - Answers
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:

27. Review Questions -- Answers
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

28. Review Questions -- Answers
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:

29. Review Questions -- Answers
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:
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,
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, Page:

30. Review Questions -- Answers
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:
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

31. Case Study 3 UML & Textbook Appendix C
MP3 App C UML Diagrams
MP3 App C UML DFD
Example 2, pg 312

32. Case Study 3
SRS w/UML -- Update SRS with text references to UML Appendices.
Appendix A.
UML DFD:
¤ Context data flow diagram (Top Process DFD) (5%) ¤ Level 0 DFD (15%) ¤ Level 1 (5%) and Level 2 (5%) DFD for at least one process (all levels linked).
Appendix B. UML diagrams including:
¤ static structure (class) diagram(10%)
¤ state chart diagram (10%)
¤ sequence diagram (10%)
¤ deployment diagram (10%)
¤ component diagram (10%)
¤ collaboration diagram (10%)
¤ activity diagram (10%)

33. DFD vs Database Model Diagram (former E-R Diagram) vs Data Flow Diagram
Use for DFD
Database Model Diagram (last implementation 2010) not in Visio 2013/2016

34. Reverse Engineer (Demonstration)
Must use MS Visio 2010 or MS Visio 2013 Professional –
features deprecated in MS Visio 2013 Standard.
Download Northwind Access Database
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

35. Reverse Engineer – Completed ER Diagram

36. Case Study 3 UML & Textbook Appendix C

37. Case Study 3 UML & Textbook Appendix C

38. Case Study 3 See link: CS3 App A & B Example
Also off Course Resources webpage> Software, Tutorials & Help>Week9

39. Case Study 3 UML Resources
CS3/MP3 Requirement/Weight
“Inside Visio 2013” Page
“UML Distilled”
Page
You Tube Video
Runtime (min:sec)
Data Flow Diagrams DFD
(Context, DFD0, DFD1, DFD2) (30%)
583
None
Context/DFD0
9:56
Static structure (class) diagram (10%)
593 36
Class Diagram
15:31
State chart diagram (10%)
598
108
State Chart Diagram
6:12
Sequence diagram (10%)
595 54
Sequence Diagram
11:17
Deployment diagram (10%)
601 98
Deployment Diagram
8:01
Component diagram (10%)
600
140
Component Diagram
17:51
Collaboration diagram (10%)
(Note: create from Sequence Diagram)
599
144
Collaboration Diagram
0:51
Activity diagram (10%)
596
118
Activity Diagram
6:15