.NODE

Appendix G Sample Inspection Plan

OVERVIEW

CI:

Project:

Project Manager:

 

Date Of Inspection

 


PRODUCED FOR SAMPLE EXECUTIVE CONSULTANT GROUP

INTRODUCTION

This software inspection plan has been produced in conjunction with the current work we are carrying out for the Sample Executive Consultant Group to produce a Web-based interactive system to replace the existing computer system still in use. The purpose of the plan is to ensure SAMPLE are confident with the nature, scope, and level of the work being undertaken, that it adheres to the objectives of SAMPLE as per the original specification details, that the system produced will stand up by itself as a product that will work well in the marketplace for the client and candidate community, and that it will demonstrate to the SAMPLE competition that the organization is a worthy challenge to the marketplace . Further, it is the purpose of this work to demonstrate to SAMPLE that the output can stand the test of time by being rigorously produced to an industry standard, is maintainable , scalable, and a cost-effective business component.

A software inspection document needs to demonstrate that the product being worked on is relevant to the criteria as specified by the client. In this respect, this document needs to show that a methodology is being proposed that will ensure that the following criteria as specified by the SAMPLE senior management group have been met. In our original project plan, we detailed the provisions required to deliver the requirements of SAMPLE. These were, in brief:

  • To provide the SAMPLE Group with an interactive, secure, Webenabled database application for the placement of candidates with client organizations.
  • To review current hardware, software, and security facilities at client premises and propose changes required to accommodate the secure Web application just mentioned.
  • To redesign the client's database to provide facilities in keeping with the secure Web application just mentioned.

Therefore, to ensure that this work is being productively actioned, the software inspection plan detailed here is proposed to give SAMPLE the confidence to monitor and review work completed to date, and work to be completed for the duration of this project. The software inspection is not a static process; rather, it is to continue for the life of the project, and as such SAMPLE are strongly urged to play a key role in the establishment of the inspection team ” see below.


SCOPE OF THE SOFTWARE INSPECTION

As covered in the above introduction, the aim of this document is to demonstrate that the product being worked on is relevant to the criteria as specified by the client. It is also the aim to ensure that the software being built matches the design and development standards as outlined by the development project. To this end, the code needs to be inspected against a checklist of the project development standards.

The scope of this inspection is basically the overall development project and all that it encompasses. To facilitate this we will need the following documents as input into the inspection process:

  • Complete and definitive user requirements document
  • Complete and definitive list of development standards

To ensure that the inspection is comprehensive, a representative sample of code will be taken at regular intervals and delivered to the inspection team. To make this more acceptable and understandable, the section code will represent a specific part of the product (e.g., candidate entry).

The inspection of the code itself will ensure that the representative section of code:

  • Meets the documentation standards for the project
  • Meets the variable naming standards for the project
  • Meets the general development standards for the project
  • Meets maintainability standards for the project
  • Is logically sound compared to the user requirements for the section of the product that it represents
  • Is in line with the ethics and working practices of the customer
  • Is compatible with the hardware requirements laid down on/by the customer

There will also be an inspection of the database structure to ensure that it meets the customer requirements. The database will be expected to:

  • Meet the database normalization standards for the project
  • Meet the database naming conventions for the project
  • Be sized according to the expected growth of the product
  • Contain the necessary elements to meet all the customer needs as defined in the user specification
  • Have field sizes that meet the needs of the user specification document


SOFTWARE INSPECTION TEAM

It is important that the team that constitutes the inspection process is made up from a vertical slice of the organizations involved in the project. As already mentioned, the software inspection process is to involve more than just the validation and verification of the computer code being produced. To date, a number of significant findings have been encapsulated and recorded in a number of key documents, and all of this information is appropriate for inspection if we are to do full justice to the project being undertaken. To this end then, the inspection process needs to address:

Area to Address

Items to Examine

Appropriate Team

Computer code:

Database interfaces

Web front-end code

Database language code

Application code

Technical

Risk data:

Risk documents

Risk

Environmental data:

Working locations (for computer storage)

Risk

Planning information:

Project plan

Management

User requirements:

Requirements documents

Management

Technical requirements:

Technical requirements documents

Modeling specifications

Technical

Quality requirements:

Quality Plans

Risk

The Team profiles for the above inspection work are recommended thus:

Team

Membership

Team ID

Executive panel

Mary Sample - SAMPLE representative

Steve Hyman - Consultant representative

A. N. Other - independent

EP

Technical [a]

Sam Wilson - chair and chief moderator

Martin Long - author and project consultant

A. N. Other - reader/inspector

T

Risk [b]

John Small - chair and chief moderator

Martyn Davies - author and project consultant

A. N. Other - reader/inspector

R

Management [b]

Mary Sample - chair and chief moderator

Mike Kennedy - project consultant and scribe

A. N. Other - reader/inspector

M

[a] Note that we have already identified both a database team and a Web team in our project plan. These teams will be linking into this inspection process as it progresses.

[b] Note that we have already identified a security and reports team in our project plan. This team will be linking into this inspection process as it progresses.

The role of the Executive group is to oversee the work of the three other groups and report back to the project executive ” as identified in the Quality documentation reported on in a previous stage of this project.


INSPECTION PROCESS

The inspection process is to last for the duration of the project. We have already provided a breakdown of the key project deliverables in terms of activity. Reproduced below is an appraisal of that work with the relevant inspection work added:

Based on the detailed plan (Above), the following analysis of the software inspection is given:

Inspection Procedure

The approach to documentation inspection will be the same as program inspection. This is a generic process designed to aid continuity to the inspection process.

Figure G1 presents the overall approach we will be adopting for both documentation inspection and program inspection.

click to expand
Figure G1: Software Inspection Steps

Each of the key steps in the inspection procedure are broken down thus:

  • Work products: These can be anything to be considered under the remit of software inspection. This is not just computer code. A document used to define a computer system such as a requirements document or a technical specification could be submitted for inspection.
  • Planning: The definition or roles and responsibilities for the inspection process.
  • Overview: To be given by the author(s) of the work product to be inspected.
  • Preparation: All involved in the inspection need to have a copy of what is to be inspected and some time to Sampleome familiar with t. This preparation stage is useful for independent evaluation prior to consensus of the group . An inspector will bring to this stage any checklists he or she may have.
  • Meeting: A meeting for all the inspectors to get together to consider their findings and continue any detection of defect work. The defect list will be produced.

    ID

    Activity

    Milestone

    Deliverable

     

    High-Level Design

    A1

    Requirements specification

    Requirements defined

    URD

         

    SRD

    A2

    Architectural design

    Architecture design completed

    System architecture

    A3

    User requirements analysis

    User requirements fully understood

    Base requirements for sizing

    A4

    Hardware sizing exercise

    Hardware and database requirements analysis

    H/w sizing doc DB sizing doc

    SI 1

    Full Inspection - Benchmarking Function

     

    Technology

    A5

    Formal hardware specification

    Required hardware

    Procurement form

    A6

    Purchase hardware

    Hardware delivered

    Hardware

    A7

    Purchase software

    Software delivered

    Software

    SI 2

    Partial Inspection

     

    Security design

    A8

    Interface design

    Interface design complete

    Interface specification

    A9

    Component design

    Component design complete

    Component specification

    A10

    Data structure design

    Data structure design complete

    Database map Entity relationship diagram

    A11

    Algorithm design

    Algorithm design complete

    Algorithm specification

    SI 3

    Partial Inspection

     

    Database Design

    A12

    Component design

    Component design complete

    Component specification

    A13

    Data structure design

    Data structure design complete

    Data structure specification

    A14

    Algorithm design

    Algorithm design complete

    Algorithm specification

    SI 4

    Partial Inspection

     

    Web Design

    A15

    Abstract specification

    Abstract spec complete

    Software specification

    A16

    Interface design

    Interface design complete

    Interface specification

    A17

    Component design

    Component design complete

    Component specification

    A18

    Algorithm design

    Algorithm design complete

    Algorithm specification

    SI 5

    Partial Inspection

     

    Reports Design

    A19

    Requirements gathering

    Requirements analysis complete

    Report requirements

    A20

    Interface design

    Interface design complete

    Interface specification

    A21

    Component design

    Component design complete

    Component specification

    A22

    Data structure design

    Data structure design complete

    Data structure specification

    A23

    Algorithm design

    Algorithm design complete

    Algorithm specification

    SI 6

    Partial Inspection

     

    Database coding

    A24

    Create tables and queries

    Database created

    Database report

    A25

    Migrate test data

    Migration complete

    Migration report

    A26

    Develop stand-alone prototype

    Prototype complete

    Demonstrate prototype

    SI 7

    Partial Inspection

     

    Web Coding

    A27

    Site design

    Site design complete

    Site design report

    A28

    Look and feel

    Look and feel complete

    Look and feel report

    A29

    User interface - forms

    User interface complete

    UI report

    A30

    Database connectivity

    Database connectivity complete

    Database connectivity report

    A31

    Develop Web-enabled prototype

    Prototype complete

    Demonstrate prototype

    SI 8

    Full Inspection

     

    Reports Coding

    A32

    Reports design

    Reports design complete

    Reports design report

    A33

    User interface

    Reports UI complete

    Reports UI report

    A34

    Develop reports prototype

    Prototype complete

    Demonstrate prototype

    SI 9

    Partial Inspection

     

    Testing and Integration

    A35

    Unit testing

    Unit testing complete

    Unit test report

    A36

    Component testing

    Component testing complete

    Component test report

    A37

    Integration testing

    Integration testing complete

    Integration test report

    A38

    End-to-end testing

    End-to-end testing complete

    End-to-end test report

    A39

    Load testing

    Load testing complete

    Load test report

    A40

    User testing

    User testing complete

    User test report [a]

    A41

    Acceptance testing

    Acceptance testing complete

    Acceptance test report

    SI 10

    Partial Inspection

     

    User Documentation

    A42

    Produce user documentation

    Documentation complete

    User documentation

    SI 11

    Partial Inspection

     

    User Training

    A43

    Train users

    User training complete

    Training report

     

    User Sign-Off

    A44

    Produce sign-off document

    Sign-off doc complete

    Sign-off document

    A45

    Acquire signatures

    Document signed

    Signed document

    [a] A user test report has been produced and is associated with this paper under Appendix G1. The report highlights the findings of the first pass of user acceptance and the corrective actions coming out of that first pass. An extensive human computer interface (HCI) exercise has been carried out as part of this process, and this information is provided in the report in Appendix G1.

    ID

    Action

    Activity

    Team(s)

    SI 1

    Full Inspection - Benchmarking function

    To apply a full software inspection to all completed components to date constituting the project. All architectural plans, specifications, and objectives will have been delivered by this stage, and it is important that an inspection for benchmarking purposed takes place. This is benchmarking for the purposes of software inspection; that is, ensuring the process is sound and consigned, and that all four groups in the inspection process are calibrated and understand their terms of reference.

    Any computer code produced by this stage in whatever format will also be inspected.

    T, R, M

    SI 2

    Partial Inspection

    To test the details of the hardware delivery - delivery documentation, configuration details, and software specification ” against delivery details.

    T, R

    SI 3

    Partial Inspection

    To test the database specification against beta production, the interface production against user requirements, and general math between algorithmic functions. Also to ensure that component approach is sound and integrated.

    T

    SI 4

    Partial Inspection

    Ensure continuity between findings from SI 3 and work in SI 4.

    T

    SI 5

    Partial Inspection

    To test the specification documentation for the Web interface aspect of the project and measure against stated deliverables as specified in the original user requirements and technical requirements.

    T, R, M

    SI 6

    Partial Inspection

    To ensure that the reporting measures adhere to those in keeping with the SAMPLE existing criteria and continuity between reports, reporting mechanisms, time scales , and scopes are all in tandem with each other.

    M, R

    SI 7

    Partial Inspection

    Database integrity checking, integration with Web aspect of project and adherence to existing SAMPLE standards. Also adherence to rules identified as part of SI 6.

    T, D

    SI 8

    Full Inspection

    Measure aspect of prototype in relation to look and feel, database connectivity, site navigation, human computer interface, quality, and overall adherence to SAMPLE standards.

    T, R, M

    SI 9

    Partial Inspection

    High-level inspection for overall context, integration with SAMPLE business approach. Also appraise results of work against outcomes of SI 6

    T, M

    SI 10

    Partial Inspection

    High-level inspection in relation to risk assessment of work completed to date, and appraisal of that work in relation to SI 6 and SI 9.

    R, M

    SI 11

    Final Inspection

    Inspection prior to sign-off. Executive Board inspection of SI 10 outputs, exception analysis, and identification of post-implementation review work.

    M, EB

  • Further "value-added" work: A chance for any improvements to be discussed.
  • Rework : The author(s) start any reworking based on the defect list(s).
  • Re-inspection: If necessary, the whole process or part of it will be repeated until all the defects have been eradicated, or a number suitable to pass the criteria set by the organization.
  • Causal analysis: As an option, the inspection process may identify some underlying causes of some of the defects.
  • Follow-up: Anything identified by the inspection team as requiring necessary follow-up work.


CONTINUING PROCESSES

As a result of this inspection, it is likely that some follow-up work will be required. This work needs to be monitored by the inspection team to ensure that all standards and needs are addressed throughout the life cycle of the project. Also, as change requests or other impacts on the product are encountered throughout the life cycle of the project, it will be necessary to ensure that no regression to the previous pre-inspection state of the code takes place as part of the resultant changes. As such, it is recommended that the following continuing processes are put into place:

  • Regular random inspections of suspect code
  • Monitoring revisits to code requiring follow-up work
  • Regression inspections of code affected by change requests or other similar project impacts

It is also recommended that a chosen representative of the inspection team report back regularly to the project manager as to the state of the project code with regard to standards and user requirements to ensure that control of the process is maintained .


SUMMARY

As a summary, the author would like to point out the following:

  1. This document was produced in conjunction with Sample Executive Consultant Group and must be signed by their representative to indicate acceptance of the aims of the document and the process it represents.
  2. The inspection team will be made up of a cross-functional team to ensure that all aspects of the development are represented.
  3. The process will originally focus on a first inspection of the requirements to ensure that they are complete and in a format that the inspection team can work with when inspecting the code.
  4. A continuing process will remain in force for the life cycle of the project.
  5. The continuing process will encompass follow-on actions from inspected code as well as regression inspections for highly modified code as a result of change requests or other such project impacts.
  6. The inspection team is responsible to the project manager and should ensure that he or she is aware of the status of the inspections at all times.
  7. Regular reporting will be in place between the inspection team and the project manager.

In short, this inspection is in place to protect the needs of the developers, the overall project team, and the customer. Its main aim is to ensure that the product delivered to the customer is what he requires, how he requires it, and written to a maintainable standard to ease the path of future upgrade, modification, and problem resolution.






Software Configuration Management
Software Configuration Management
ISBN: 0849319765
EAN: 2147483647
Year: 2006
Pages: 235
Authors: Jessica Keyes
Similar book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net