Chapter SIX Implementation, Testing and Pragmatics Making it a reality.
-
Upload
harriet-bruce -
Category
Documents
-
view
221 -
download
5
Transcript of Chapter SIX Implementation, Testing and Pragmatics Making it a reality.
![Page 1: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/1.jpg)
Chapter SIX Implementation, Testing and
Pragmatics
Making it a reality
![Page 2: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/2.jpg)
Topics
DocumentationCoding, Testing and inspectionOthers
Installation Training Maintenance
2
![Page 3: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/3.jpg)
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
![Page 4: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/4.jpg)
Documentation4
![Page 5: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/5.jpg)
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
![Page 6: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/6.jpg)
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
![Page 7: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/7.jpg)
Coding and Testing7
![Page 8: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/8.jpg)
Coding
Translating the design specification in to a working system (a reality)
Two important issues Coding style
To make readable and maintainableAdding 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
![Page 9: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/9.jpg)
Software Testing
Testing is the process of exercising aA software/program with the specific intent of finding errors prior to delivery to the end user.Testing is Verification and Validation
“Are we building the right system?”“Are we building the system right ?”
![Page 10: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/10.jpg)
What Testing Shows
errorserrors
requirements conformancerequirements conformance
performanceperformance
an indicationan indicationof qualityof quality
![Page 11: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/11.jpg)
Who Tests the Software?
developer independent tester
Understands the system
but, will test "gently"
and, is driven by "delivery"
Must learn about the system,but, will attempt to break it
and, is driven by quality
![Page 12: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/12.jpg)
12
Cont…
A failure is an unacceptable behaviour exhibited by a system The frequency of failures measures the reliability An important design objective is to achieve a very low
failure rate and hence high reliability. A failure can result from a violation of an explicit or
implicit requirement
A defect is a flaw in any aspect of the system that contributes, or may potentially contribute, to the occurrence of one or more failures could be in the requirements, the design and the code It might take several defects to cause a particular failure
An error is a slip-up or inappropriate decision by a software developer that leads to the introduction of a defect
![Page 13: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/13.jpg)
13
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.
![Page 14: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/14.jpg)
Software Testing
Methods
Strategies
white-boxmethods
black-box
methods
![Page 15: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/15.jpg)
White-Box Testing
... our goal is to ensure that all statements and conditions have been executed at least once ...
![Page 16: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/16.jpg)
16
Cont…
Also called ‘Glass-box testing’ or ‘structural’ testing
Testers have access to the system design They can
Examine the design documents View the code Observe at run time the steps taken by algorithms and
their internal data Individual programmers often informally employ
glass-box testing to verify their own code
![Page 17: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/17.jpg)
Black-Box Testing
requirementsrequirements
eventseventsinputinput
outputoutput
![Page 18: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/18.jpg)
18
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
![Page 19: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/19.jpg)
19
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.
![Page 20: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/20.jpg)
20
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.
![Page 21: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/21.jpg)
21
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.
![Page 22: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/22.jpg)
22
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.
Independent testing is performed by a separate group. They do not have a vested interest in seeing as many test
cases pass as possible. They develop specific expertise in how to do good
testing, and how to use testing tools.
![Page 23: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/23.jpg)
23
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.
![Page 24: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/24.jpg)
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.
![Page 25: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/25.jpg)
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.
![Page 26: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/26.jpg)
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.
![Page 27: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/27.jpg)
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.
![Page 28: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/28.jpg)
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
![Page 29: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/29.jpg)
Summary
Introduction Understanding motivations and basic concepts
Terminologies , concepts, processes, approaches
Modeling using UML Understanding modeling tools in software
development Types, categories and structure
Requirement elicitation Collecting and organizing users requirement-
WHAT- User needs From function, class, and interface points of view
29
![Page 30: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/30.jpg)
Cont…
Requirement Analysis Analyzing and modeling requirements-WHAT
System In terms of Function, Logic and Objects (classes)
System and object design Specifying the new system-HOW
At an architecture level and detail design level
Implementation, testing and Pragmatic Making it a reality
Coding, testing and documentation
30
![Page 31: Chapter SIX Implementation, Testing and Pragmatics Making it a reality.](https://reader030.fdocuments.in/reader030/viewer/2022032612/56649ee65503460f94bf67df/html5/thumbnails/31.jpg)
End of The chapter and the course
31