Software Engineering: Spring Term 2016 Marymount University School of Business Administration Professor Suydam
Software Engineering: Spring Term 2016 Marymount University School of Business Administration Professor Suydam
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’
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)
• 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
• 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
19
Unit Test
Functional Test
Unit Test
20
• Divide the input into several groups,
deemed “equivalent” for purposes of
finding errors.
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)
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 Testing
• Partially Cost-effective • Finds errors cheaper, but
• Can be applied to intermediate correcting them is expensive
artifacts • Can only be applied to code
• Catches defects early • Catches defects late (after
• Helps disseminate knowledge implementation)
about project and best practices • Necessary to gauge quality
30
Formal Methods Static Analysis
• Mathematical techniques used to • Examination of static structures of
prove that a program works design/code for detecting error-prone
• Used for conditions (cohesion --- coupling)
requirements/design/algorithm • Automatic program tools are more
specification
• Prove that implementation conforms useful
to spec • Can be applied to:
• Pre and Post conditions Intermediate documents (but in
• Problems: formal model)
Require math training Source code
Not applicable to all programs Executable files
Only verification, not validation • Output needs to be checked by
Not applicable to all aspects of programmer
program (e.g. UI or
maintainability)
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
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
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
36