Software Development - Shawlands Academy

Document Sample
Software Development - Shawlands Academy Powered By Docstoc
					Software Development
          Chapter 4
  Software Testing and Tools
►   Software testing involves a series of processes to verify that :
    §   The finished product meets the original specification
    §   The software is robust
    §   The software is reliable
►   Testing can only find errors in a program, not prove there are
►   Testing should be systematic
►   Test data needs to be planned and the test process needs to
    record a test log
►   The actual test data selected depends on the test strategy
                   Test Strategies

►   Recapping testing methods..

    §   Module Testing, on all components
    §   Integration Testing, where the components function as an entity
    §   System Testing or Black Box Testing
    §   Acceptance Testing or Beta Testing, ensuring that the system is
        ready for operational use

►   Software testing is a complex and expensive issue
                            Test Approaches

► There are a number of different testing approaches:
      By scope                By purpose            By life-cycle phase

      Component testing       Correctness testing   Requirements testing

      Module testing          Performance testing   Design testing
      Integration testing     Reliability testing   Acceptance testing

      System testing          Security testing      Maintenance testing

• Testing ‘by scope’ starts at the component level then proceeds
through each phase until the final system is tested as a whole
• Testing ‘by purpose’ entails the whole reason for testing. It makes
sure the program is correct and runs to the original specification
• Testing ‘by life-cycle’ phase include the final software development
test, acceptance testing where the software is sold to the client

►   Components are sometimes called units
►   They are the building blocks of software applications
►   They are defined as pieces of software such as sub-routines or
    procedures that can be compiled and executed on their own
►   A component will be the work of a single programmer and they will also
    test the code at a basic, White Box, level
                Component Testing
►   With White Box testing component code is seen and it is the
    workings of the code that are tested
►   The component can be tested in Static or Dynamic mode
    § In static mode the component does not require to be executed. A
      detailed catalogue of reviews and inspections is compiled for each
        ► Inspections contain a precise framework for rigorously checking component
          documentation and code
    § In dynamic testing the component program is executed using test values
      for normal, extreme and exceptional cases
►   Modules are a collection of dependant components or procedures designed
    to be part of the main program
►   They are not complete programs in themselves, they can not run
►   It often happens that a module becomes ready for testing before the main
    program. It is common practice to write a small program, called a Driver or
    Test-Harness to run the module and supply it with test data
►   Driver programs are commercially available
►   A stub is a module that has the appropriate interface but does not contain a
    lot of code
►   It might contain no more than a line of code to display what the module will
    do when its complete
►   The system as a whole is laid out using stubs to ensure that the overall
    structure is correct
►   Stubs are then converted into fully functional modules
                      Module Testing
►   Modules are created and tested within their sub-systems
►   When all modules have been tested the sub-system as a whole is tested then
    sub-systems are brought together and the whole program is tested
►   At system level the type of testing is Black Box Testing
►   Black box testing takes the program specification as the sole source of test
►   One advantage of this is that developers who test a system can be different
    from those who create it
       Module Test Progression
►   The testing process involves feedback
►   Testing might indicate errors in a module which would need debugged
    and tested again
►   The usual strategy is to test software twice

    The module is first tested within the company, this is Alpha Testing
               It is followed by Acceptance or Beta Testing
                     Alpha Testing

►   Alpha testing can be regarded as ‘Does the software work?’
►   This is the stage in the development cycle where the software
    is first able to run
►   This testing takes place on the software developers premises
►   Alpha testing is done for 2 reasons;
    § To reassure the clients the software is working
    § To find errors that can only be found in operational use
►   Alpha testing is performed on an early version of the code,
    that might not have all intended functionality
►   Alpha testing should be conducted with as much
    independence from the development team as possible
      Beta (Acceptance) Testing

►   This is for the client to say ‘yes we will pay for the software’
►   Beta testing is the highest level of testing in the software development
    cycle and is done prior to commercial release
►   It confirms that the program is as near to correct as possible
►   The software is tested by independent users who log and report back to
    the development team, this process might be iterative if errors have to
    be corrected
►   The functionality delivered in beta test releases might not be the final
►   A bug is a fault in a program that causes it to function abnormally
►   Debugging is the process of locating and fixing errors
►   Programs that help to do this are called debuggers
►   Most software development tools offer debugging tools
►   Using a compiler the first task of the debugging tool is to link the object code
    to source code to locate the error
►   The part of the compiler responsible for this is the Link-Loader
                   Debugging Tools
►   With the debugging features activated a program will run
    slower, so it is only used when necessary
►   Debugging tools usually take the form of:
    §   Dry Runs
    §   Trace Tools
    §   Watch Statements
    §   Break Points
                                Dry Run
►   Bugs can be difficult to locate and correct, the temptation is to tweak the
    code until it runs correctly, however this can lead to more errors
►   If a bug does not become apparent a dry run is conducted
►   A dry run is based on the listing of the code that the programmer works
    through manually
►   A Trace Table is used to store and display program variables as the logic of
    the algorithm unfolds, the actual output can then be checked against the
►   Dry runs are used for locating logic errors and is only practical for simple
                         Pupil task

Name and describe two methods of locating errors in a puzzle software.

Set breakpoints (1) – used to stop execution of the program at
predefined point (1)

Trace tables (1) – used to record the contents of a variable during
manual execution (1)

Dry run (1) – stepping through each line of code manually recording
variables (1)
                          Trace Tools
►   Some programming languages have TRACE facilities as a debugging feature
►   Tracing gives access to otherwise invisible information about a program
    execution allowing the programmer to step through the program line by line
    and stop at points to examine variable content
►   More enhanced tools allow investigation of memory locations and the
    content of the stack
►   Programs that use large numbers of procedures use the stack to store all
    their procedure calls
►   Using trace a program will run slower
                  Program Watch
►   A watch takes an identifier and displays its values as the program
►   The programmer steps through the code one line at a time and the
    variable being traced is display on a watch screen
►   Many programmers prefer to put in watches in the form of output
    statements that cause the value of the variable to be displayed at
    points in a program where a bug exists
►   A draw back of program watching is the number of lines of code
    increase as does programming time
►   A break point is a marker set within the code of a program to halt program
    execution at a predefined spot
►   The statement responsible will be highlighted and can be inspected while
    the program is temporarily interrupted
►   The program then continues to completion or until another breakpoint is
►   Breakpoints are often used with traces
                  Pupil task

The project team is ready to beta test the software.

(i) Give two reasons why beta testing is necessary.

(ii) Name the two groups involved at this stage and
     describe the role of each group.
i) • Checks software is reliable on the client’s computer.
• Checks client is happy with software and allows increased
reliability of testing.
• Allows client an opportunity to check that software meets
• Allows programmers to observe the clients using the
software determining success of user interface etc.

(ii) • End users − provide feedback
• Programming team − maintenance
                           CASE Tools
                Computer Aided Software Engineering

►   It refers to the collection of software programs that are designed to
    automate the development cycle
►   The implementation of new systems requires many different complex tasks
    to be organised and completed correctly and efficiently
►   Information generated has to be kept in synchronisation
►   The use of CASE tools eases the task of coordinating these activates from
    analysis to implementation
Computer-Aided Software Engineering (CASE), in the field of
Software Engineering is the scientific application of a set of tools
and methods to a software system which is meant to result in
high-quality, defect-free, and maintainable software products.
It also refers to methods for the development of
information systems together with automated tools that can be
used in the software development process
                 Types of CASE Tools
►       Basic categories of CASE tools are available:
    §      Diagramming tools that represent data models according to system
    §      Screen and Report Generators for creating system specifications.
    §      Data Dictionaries that contain a history of changes made to a system
    §      Code Generators to be able to generate code from data Diagrams
    §      Documentation generators that make the code more readable.
            Development of CASE
►   Sine the early days of writing software there has been a need for
    automated tools to help the software developer
►   As computer became more powerful ad the software that ran on them
    grew larger and more complex, power tools with increasing functionality
    were required
          Categories of CASE Tools
►   CASE tools can be divided into two main groups
    § Those that deal with the first three parts of the system development life
      cycle (preliminary investigation, analysis, and design) and are referred to
      as Front-End CASE Tools or Upper CASE Tools
    § Those that deal mainly with the implementation, testing and installation
      are referred to as Back-End CASE Tools or Lower CASE Tools
                 Upper CASE Tools
►   These are basically general-purpose analysis and design specification
►   During the initial stages of system development, analysts have to
    determine system requirements and analyse this information to design
    the most effective system
►   Computerised CASE tools allow for changes to be made automatically,
    very quickly and accurately
►   Data Dictionaries are data processing systems products that are
    specifically designed to hold, maintain and organise information
►   They have facilities for producing a variety of reports
►   They allow developers to be more productive
►   The goal of a CASE tool is to refine the analysis and design stages to
    allow automated production of code, around 75%
                Data Dictionaries

►   A data dictionary is an automated tool for collecting and
    organising detailed information about system components
►   A data dictionaries main facility is to document data
    elements, records, programs, files, users etc
►   They also have the facility to cross-reference all system
    components and contain details of:
    §   Systems environment
    §   Audit trails
    §   Reports
    §   Forms
    §   Functions
    §   Processes
               Lower CASE Tools

►   These focus on the architecture of the system and its implementation and
►   These tools are effective in helping with the generation of the program
    code and are referred to as Code Generators
►   A code generator is a tool that enables automatic generation of code
    from the analysis and design specifications
►   Generating code this way ensures that all code is produced with identical
    naming conventions
                     Code Generators
►   Code generators produce a high quality of code that is easy to maintain and
    is portable
►   They are able to interact with Upper CASE tools to aid in the development of
              Document Generators
►   A further enhancement to CASE tools is document generators
►   A document generator is a CASE tool that generates technical documentation
    from source code comments
►   The comments that are produced conform to a standard format
         Object-Oriented CASE

►   CASE tools are well supported in object-oriented
    programming systems (OOPS)
►   Earlier problems with OOPS focussed on models created for
    software development systems and their different notations
►   This was overcome by the use of UML, Unified Modelling
    Language, which is a new standard for producing diagrams
    and charts
►   All current CASE tools have now adopted UML for specifying,
    visualising and constructing software systems

►   CASE tools offer automatic code generation from the UML
►   This tool produces a framework for the code which contains
    objects and classes. An Executable Prototype is produced
    § This is an executable source code program obtained directly from UML
►   One of the main features in UML is Reverse Engineering
    where existing source code is reversed engineered into a set
    of UML diagrams
                      Rational Unified Process
►   In conjunction with UML developers also employ RUP
►   This is a development process to deliver best practices during each stage
    of a project
►   Using RUP risks are lowered during all stages
                   Advantages of CASE
►   Increase Speed
     § CASE tools provide automation and reduce the time to complete tasks
►   Increased Accuracy
     § CASE tools can provide on-going debugging and error checking which is vital for
        early defect removal
►   Reduced Costs and Maintenance
     § Overall system quality improves using CASE. There is also better
        documentation so the net effort and cost involved is reduced
►   Better Documentation
     § Using CASE tools vast amounts of documentation are produced. An important
        aspect is CASE Repository, this is a developers database with information
        relating to the projects stored. It can be regularly updated
►   Better Communication
     § Information generated from one tool can be passed to another, allowing for
        important information to be passed efficiently and effectively
      Limitations Of CASE Tools

Although CASE tools are becoming more popular user can be
subject to some limitations:

►   Choice
    § Over 1000 CASE tools exist and choosing one is difficult, a major
      project in itself
►   Costs
    § CASE tools are not cheap. Hardware, software, training and
      consulting are all factors in the total cost equation
►   Training
    § Users need time to learn the technology. A CASE consulting
      industry has evolved to support uses of CASE tools
                  Pupil task

Describe two benefits of using Computer-Aided Software
Engineering (CASE) tools.

• Computerised generation of graphical designs and information
shared across the system would be monitored.
• Automated data dictionaries.
• Tools to track dependencies.

Do not allow compilers, editors, debuggers or other software
development type answers

Shared By: