System Analysis

Sentinel’s approach to a successful system is to first provide the system analysis for a project prior to any programming taking place.  This method not only protects Sentinel from misleading or misquoting a system to a client, but also protects the client by identifying all the proper requirements for the system. At the completion of the System Analysis phase, the system requirements document will be given to the customer for review and a date will be set to meet and review the project.  Any items changed or missed requirements will be modified in accordance with the customer’s application requirements.   Additions outside of the original scope of the proposal will be re-quoted to keep the project moving forward.  Sentinel will not precede with the next phase until the project leader signs off on the final system requirements document.  Once the system requirements document has been signed off, the Program Analysis phase will begin and the project time line will be modified in accordance with the final system requirements document.

In conjunction with our client’s representatives cognizant of the system requirements, the Sentinel representatives will provide the following services to produce the Detail Functional Specifications Document:

  • A complete review of overall system requirements. 
  • Assistance on any hardware evaluations not resolved at proposal time. 
  • Interface to hardware and vendors. 
  • Preparation and draft for final systems overview documentation. 
  • Preparation of system flow in narrative and/or chart formats. 
  • Definitions for transaction record layouts for the portable or fixed terminal programs. 
  • File layouts for verification tables or down load tables for local verification to the devices. 
  • The printer label formats and media selection for bar code label printers.

Program Analysis

The Program Analysis phase produces the System Specification Document.  This document contains each program’s user interface, business rules, and all the logic necessary for a programmer to complete their task.  Program specifications will include the following and will be in relative detail to program complexity:

  • Create the objective and general statement or purpose of the programs.
  • Create a prototype of the screens that the users will be interfacing to.
  • Create the narrative with statement of program functions and its relationship to system objective.  The input and/or output description for each transaction to include name and fields referenced in it.  Definition of file layouts with tabular representation or file contents with detailed file characteristics, field descriptions, standard names, field formats, etc.  The detailed program logic with editing criteria, decision tables, header specifications, overall program structure.
  • Provide a detailed definition of functions, calculations, arrays, or mathematical operations that are performed for the programs.
  • Provide a definition of processing with the necessary steps in narrative and/or chart format.  Inclusion of all label formats, screen layouts, and source documents prepared during systems analysis that are indigenous to programming.
  • A final review with the customer before any programming begins.

Sentinel will not proceed with the Programming phase until the customer project leader signs off on the final System Specification document.

Programming/Unit Testing

The programmer will write the program based upon the requirements that are defined in the System Specification document.  Industry standard techniques are used in the coding of the program.  As each program is being written, it is also tested using the debugger/emulator that is build into the SBS-CASE Tools™ IDE (Interactive Development Environment).  The program is tested in isolation and not in relation to the rest of the system.  Any variations of the actual code from the System Specification are noted and must be approved by the customer’s project leader.  Any other type of variations is noted so that the analyst can go back and update the System Specification at the completion of the testing phases.  We call our System Specification a “living” specification because it is updated through out the entire process.

System/Integrated Testing

The actual application is compiled and is distributed to the mobile devices or the client PC’s.  Each program is tested independent of each other and then tested as part of an integrated system.  The testing procedures used are based upon the System Specification document.  Any program deficiencies or variations from the approved System Specification are noted and sent back to the development team to be fixed and then retested.  Any requested changes to the System Specification are noted on a RFC (request for change) document.  If any RFC’s were submitted, they are reviewed by the steering committee and the appropriate action is taken based upon the committee’s recommendations.

User Acceptance Training

The User Acceptance Testing (UAT) document is authored by the customer and should be based upon the System Specification document.  The actual UAT is performed by the customer with the assistance of the SBS project leader, and any program deficiencies or variations from the approved System Specification are documented.  At the completion of the UAT the document is reviewed by the customer and Sentinel.  The appropriate actions are taken on each point after the review.  Once the user approves the UAT, then the next phase can begin.

Training

Training can be performed in various ways.  We normally perform the “train the trainer” method.  The Sentinel representative will train the customers trainer based upon the System Specification document.  The trainer normally takes detail notes on their copy of the System Specification document and then uses these notes to author the operations documentation and a training guide if necessary.  These documents are normally written by the customer but can be written by Sentinel if the customer wishes.  These documents are then used to assist in training the operators.

Staging and Kitting

Hardware is shipped to the Sentinel service center.  The first step is to stage and configure a single unit by installing the product software on it, then installing the application software on it.  Sentinel makes the installation a simple and easy process by creating cab files that perform the drudgery that is normally accompanied by an installation. The last step, is the configuration of the device itself .  This may entail network settings, scanner settings, power settings and so on.  Once the test unit is successfully running, the application and the configuration steps are then documented in the “Staging and Configuration Guide.”    The rest of the devices are then setup following the Staging and Configuration Guide.

 The guide also contains other useful information about the device such as battery management and …

Implementation

The hardware is delivered and the product software and licenses are installed.  The application is distributed to all devices and another test takes place according to the implementation plan.  Once the system performs according to the implementation plan then the user will be requested to sign the System Acceptance document.