Appendix G Sample Inspection Plan

OVERVIEW

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:

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

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.

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.