Professional Documents
Culture Documents
Object Oriented SAD-Chapt 6
Object Oriented SAD-Chapt 6
Making it a reality
Topics
Documentation
Coding, Testing and inspection
Others
Installation
Training
Maintenance
2
Introduction
Pragmatics concerned with how the system
design process we have done so far would
be linked to the reality or how it is would
give sense or meaning to the stakeholders.
These issues will cover Coding, testing
along with documentation and object
oriented benefit realization.
3
Documentation
4
Documentation
There are various types of documentations
required in object oriented Software engineering
System Documentation: detailed information about a
system’s design specifications, its inner workings, and its
functionality.
User Documentation: written or other visual information
about an application system, how it works, and how to use
it. User documentation is often in the form of online help,
sometimes with Web connections for further information.
5
Cont…
The system documentation can be for internal or
external to the system being developed.
Internal System Documentation: comments in source code,
generated during the coding process or automatically by software
compilers or documenters are internal to the system.
External System Documentation: outcomes of all
diagrams, including use cases, design classes, activity
and sequence diagrams, etc are categorized under this
sub category.
6
Coding and Testing
7
Coding
Translating the design specification in to a working
system (a reality)
Two important issues
Coding style
To make readable and maintainable
Adding as much comments as possible, use combination
of uppercase and lower case in naming …
Programming language selection
A language that supports features required
For a web based applications vs window based
8
Software Testing
Testing is the process of exercising a
A software/program with the specific intent
of finding errors prior to delivery to the end
user.
requirements conformance
performance
an indication
of quality
Who Tests the Software?
12
Effective and Efficient Testing
To test effectively, you must use a strategy that
uncovers as many defects as possible.
To test efficiently, you must find the largest possible
number of defects using the fewest possible tests
Testing is like detective work:
The tester must try to understand how programmers and designers
think, so as to better find defects.
The tester must not leave anything uncovered, and must be
suspicious of everything.
It does not pay to take an excessive amount of time; tester has to
be efficient.
13
Software Testing
white-box black-box
methods methods
Methods
Strategies
White-Box Testing
16
Black-Box Testing
requirements
output
input events
Cont…
Testers provide the system with inputs and observe the
outputs
They can see none of:
The source code
The internal data
Any of the design documentation describing the system’s
internals
18
Writing Formal Test Cases and Test
Plans
A test case is an explicit set of instructions designed to
detect a particular class of defect in a software system.
A test case can give rise to many tests.
Each test is a particular running of the test case on a
particular version of the system.
19
Test plans
A test plan is a document that contains a complete set of test cases for a
system
Along with other information about the testing process.
The test plan is one of the standard forms of documentation.
If a project does not have a test plan:
Testing will inevitably be done in an ad-hoc manner.
Leading to poor quality software.
The test plan should be written long before the testing starts.
You can start to develop the test plan once you have developed the
requirements.
20
Information to include in a formal test
case
A. Identification and classification:
Each test case should have a number, and may also be given a descriptive title.
The system, subsystem or module being tested should also be clearly indicated.
The importance of the test case should be indicated.
B. Instructions:
Tell the tester exactly what to do.
The tester should not normally have to refer to any documentation in order to
execute the instructions.
C. Expected result:
Tells the tester what the system should do in response to the instructions.
The tester reports a failure if the expected result is not encountered .
D. Cleanup (when needed):
Tells the tester how to make the system go ‘back to normal’ or shut down after
the test.
21
The roles of people involved in testing
The first pass of unit and integration testing is called
developer testing.
Preliminary testing performed by the software developers who do
the design.
22
Testing performed by users and clients
Alpha testing
Performed by the user or client, but under the supervision of the
software development team.
Beta testing
Performed by the user or client in a normal work environment.
Recruited from the potential user population.
An open beta release is the release of low-quality software to the
general population.
Acceptance testing
Performed by users and customers.
However, the customers do it on their own initiative.
23
Finally
Software testing is four steps procedure
Initially, tests focus on each component individually,
ensuring that it functions properly as a unit.
makes heavy use of white-box testing techniques,
exercising specific paths in a module's control
structure to ensure complete coverage and maximum
error detection.
Cont…
Next, components must be assembled or integrated to
form the complete software package.
Integration testing addresses the issues associated with the
dual problems of verification and program construction.
Black-box test case design techniques are the most prevalent
during integration, although a limited amount of white-box
testing may be used to ensure coverage of major control
paths.
Cont…
After the software has been integrated (constructed), a
set of high-order tests are conducted. Validation
criteria (established during requirements analysis)
must be tested.
Validation testing provides final assurance that software
meets all functional, behavioral, and performance
requirements.
Black-box testing techniques are used exclusively during
validation.
Cont….
The last high-order testing step falls outside the
boundary of software engineering and into the broader
context of computer system engineering. Software,
once validated, must be combined with other system
elements (e.g., hardware, people, databases).
System testing verifies that all elements mesh properly
and that overall system function/performance is
achieved.
Others
Installation
Putting the system in to work
Direct/phased/parallel/ one site
Training
Enabling end users and technical personals to work and
mange the system/software
For whom and how much?
Maintenance
Providing continuous support as long as the
software/system is alive.
Adaptive/perfective/corrective
28
Summary
Introduction
Understanding motivations and basic concepts
Terminologies , concepts, processes, approaches
Requirement elicitation
Collecting and organizing users requirement- WHAT- User
needs
From function, class, and interface points of view
29
Cont…
Requirement Analysis
Analyzing and modeling requirements-WHAT System
In terms of Function, Logic and Objects (classes)
30
End of Chapter 6
and
End of the Course
31