Controls, Auditing, and Security Analysis

Contact Martin Modell   Table of Contents


Security of data, physical plant, and processing controls are the major areas which affect business systems.  They may make the difference between acceptable and unacceptable systems proposals, and between successful and unsuccessful systems.  Additionally, any development project analysis must examine current security procedures and determine the need for any enhancements to them.

This chapter discusses the concepts of security and controls, the areas where they are most needed, the determination of security and control requirements, and their impact on the final system proposal.   The chapter also includes discussions of configuration management, change management, system administration and disaster preparedness.


The topics of security, auditing, and controls analysis are usually overlooked during the analysis process.  The logical relationship between the three topics is sufficiently tight that they can be treated in one unit; however, they are also different in many respects.  Security is the more all-inclusive topic, with auditing and controls being the tools used to ensure that security is maintained.  Many areas of security have already been treated in previous chapters, and much of the information gathered during the functional, process, and data analysis phases applies to the evaluation of security requirements of the firm and of specific applications.

Although security should be an ongoing concern for the firm, most firms do not address these issues until the information systems environment has migrated to the third stage of the data processing growth curve and often it is well into the third stage.  Thus an analyst working within a first or second stage environment, or even in an early third stage environment, should pay careful attention to this area of analysis (Figure 21.1), since it is in these early stages that security is most likely to be minimal or lacking altogether.

The analyst should also remember that the firm may not be in the same place on the growth cycle in all areas (especially in the personal computer area), and thus each security analysis should be undertaken with the particular growth stage of the particular user and implementation environment in mind.

What Is Security?

Security relates to protecting the firm's records and resources from unauthorized access, modification, or other interference.  It includes an analysis of ownership, access, modification, and use, as well as a determination of what protective or restrictive measures must be taken to ensure adequate protection of the firm's files.  Whereas the bulk of systems analysis concentrates on determining which processing activities are being done and which should be done, security analysis concentrates on who should or should not be doing those processing activities and when those activities should or should not be done.  This examination should not necessarily be carried out from the perspective of functional needs, although they obviously play a critical part in this area of analysis.

We tend to think of security in terms of preventing physical entry; however, by extension it can also be viewed as preventing logical entry as well.  In the business environment this determines who should be allowed to access, modify, and remove business records.  It is immaterial whether these records are physical or automated.  Security is also concerned with record retention and safekeeping.  Generally any analysis of security requirements involves answering a series of questions relating to "who can do what with what."

Securing the firm's data and information resources may also entail examining the physical resources which allow access to those data.  These resources include printer facilities, data storage (both machine readable and hardcopy), and data access facilities (the most obvious of these being terminals and personal computers).

Generally speaking, security can be said to include (see Figure 21.2)

  1. Those procedures which ensure that the correct people perform the proper actions at the proper times and use the proper resources to do so
  2. Those procedures which ensure that those persons who are not authorized to perform certain actions or use certain resources are restricted or otherwise prohibited from doing so
  3. Those procedures which ensure that authorized persons do not perform authorized actions or use authorized resources at unauthorized times, or for unauthorized reasons
  4. Those procedures which detect and record any violations of the above three items

Security Analysis

Security analysis thus involves making a determination of what must be done, when it must be done, how it must be done, what is needed to do it, and who should be doing it.  Security analysis also includes an examination of the physical access points to data.

Security analysis usually begins with an evaluation of securable resources.  This is done on the assumption that the more sensitive, valuable, or irreplaceable the resource, the greater the effort which should be expended securing it.

The first set of questions thus involves the material to be secured.  Generally this involves an inventory of the firm's files and the records within those files.  Included in this inventory should be

  1. All original source documents
  2. All internal documents and forms
  3. All reports for both internal and external use
  4. All manual and automated files
  5. All copies of all manual and automated files<
  6. All manuals, product descriptions, schematics, drawings, etc.
  7. All memoranda and correspondence files

This inventory should be as complete as possible, and most of the information should already be available from the environmental analysis documentation.  Each item in the inventory should be annotated as to

  1. The source of the material
  2. The official owner of the material (not necessarily the source)
  3. A list of those persons or units who are authorized to access, modify, and otherwise use the material
  4. The time or conditions under which it can be destroyed or thrown away<
  5. The name of the person or unit that is authorized to destroy it

In some cases there may be more than one person or unit involved in each of the above; in this case, all names should be listed.

Once such an inventory has been completed, the next step is an examination of each of these files and records to determine if they need to be secured.  Not everything within the files of the firm needs to be secured, and security may not be needed all the time.  For instance, quarterly financial reports need to be secured before publication but not afterward.  Likewise, prior to publication, manuscripts should be secured from non-employees, but not after.

This determination of security needs should be done on an item-by-item basis and should evaluate

  1. Is the material available from other sources or is it wholly generated within the firm?
  2. Is the material protected by license, patent, copyright, nondisclosure agreement, contract, or other legal mechanism? If so, does the license, patent, etc., belong to the company or to someone or some organization outside the firm?
  3. Does the firm have any existing method of classifying documents, files, and records? If so, does this item fall within that security program?
  4. If no such program exists, does the analyst need to devise such a program for the user area? The depth and extent of the security requirements are dependent upon the user area management and the nature of the work done by the unit.  Not all areas of the firm have security requirements.  In some cases the security need may be minimal, and in others, such as product development, personnel and payroll, etc., it may be extensive.
  5. Is the content of the material such that it warrants security? For instance, employee payroll lists with names and salaries are usually considered very sensitive information; however, statistical reports on payroll are normally not sensitive.  Reports containing product costs or specifications are usually sensitive unless such information is otherwise publicly available.
  6. Is the nature of the information on the document such that its disclosure would be damaging, embarrassing, or otherwise detrimental to the company?
  7. Is the nature of the material such that the company is legally precluded from disclosing it, such as employee medical information?
  8. Is the nature of the material such that disclosure of it to unauthorized persons might place the firm in a position where it could be open to a lawsuit?

The answers to these questions should provide the analyst and the user manager with enough information to determine and classify those documents which need to be secured.  The classification scheme can be as simple or as complex as is necessary to obtain the desired level of security awareness.

Once the classification process is complete, the analyst needs to determine how to achieve the desired level of security.  Since most of the firm's resources, especially its data resources, should be used in conjunction with legitimate, that is, authorized, activities, the analyst should next cross-reference the documents and resources to the activities and procedures which use them and make a determination as to whether those uses agree with the security profiles established for the documents.  For instance,

  1. Are the persons who perform the activities with those documents authorized to do so?
  2. Are the activities being performed in the correct and established time frames?
  3. Are the activities being performed in the documented and authorized manner?

For each activity which includes a secured document, have procedures been established to ensure that the security of the documents are both known and maintained? Are there procedures established to ensure that document security classification is clearly established? Have all procedures which use secured documents been modified to ensure that they include actions which ensure that the security of the documents is maintained when they are not actively being used?

The actions to be taken with respect to these questions may include any or all of the following:

  1. A set of rubber stamps
  2. Nondisclosure agreements or other similar documents<
  3. Locking file cabinets
  4. Restricted copy and distribution procedures for certain material
  5. Restricted use of copier and other duplicating facilities
  6. Sign-out--sign-in procedures
  7. On-premises vaults
  8. Off-premises storage

Physical Access Security

It is not enough just to secure the data.  The analyst must also determine whether access to the terminals which provide access to the data has also been secured. 

  1. Are the terminals in a physically secured place?
  2. Do the terminals have locking mechanisms?
  3. Does the telecommunications system provide facilities for sign-on and password security facilities?
  4. Have these facilities been implemented?
  5. Are they enforced?

In many firms employees are assigned sign-on codes and passwords.  Many times these codes and passwords are simple and easy to remember.  In many cases these codes are written on the terminals themselves or in plain view.  For those applications which require access security, these items should be examined carefully and more stringent procedures should be initiated where necessary.

Personal Computer Security

Because of the great ease with which data can be loaded into or unloaded from these machines and because of the extreme portability and small size of floppy disks, data security becomes a grave issue in those environments where user systems are developed for the personal computer.

The issue becomes even more critical in a network environment where the ability to download or upload data to and from a mainframe and transfer data, files and documentation form machine to machine, from network to network, and country to country, is as easy as retrieving data from the machine’s own hard drive. Although much of the software for personal computers is copy-right protected by the vendors, the simplicity of the data access methods offered by the machines allows almost anyone with even a limited amount of knowledge to read and copy data and software.  The copy protection mechanism of the software does not extend to the files the software resides on and anyone with a version of the baseline software can access any user file.

Some packages permit the data files to be secured, but here again, the protection is often rudimentary at best.  Although encryption of data (the scrambling and encoding of the data so that it is unreadable without the decryption mechanism or code key) is possible, many firms do not insist upon it, and the difficulty of using these techniques is such that many users dispense with it altogether even where it is available.

The ability of many personal computer users to bypass the protection mechanisms of the vendor software packages, and the ease with which they do so, makes any data security mechanism seem almost transparent.

Aside from these issues, a firm's lack of standards and its inability to enforce those standards compound the problems of personal computer data security.

System Administration

System administration is that set of processes and activities designed to ensure that the network systems operate efficiently.  System Administration is responsible for the following actions:

  1. Installation and removal of all system software
  2. Installation and removal of all network software
  3. Installation and removal of all workstation software
  4. Maintenance of all network servers<
  5. Back up and  restoration (if, necessary) of all network files
  6. Maintenance of the network configuration
  7. Installation and removal of all network peripheral equipment
  8. Upgrade and or maintenance of all network software
  9. Upgrade and or maintenance of all server software
  10. Maintenance of all network documentation
  11. Installation and maintenance of all network services (e.g. E-mail, Internet connection accounts)
  12. Maintenance of all network related security (e.g. Passwords, access accounts)
  13. Installation and removal of all network related hardware
  14. Installation and removal of all server related hardware and equipment


Unlike security analysis, which seeks to determine the importance of the firm's files and to determine what protective measures, if any, must be applied, controls analysis seeks to determine what measures are needed to ensure that the protective measures are being followed and that the necessary work of the firm is completed accurately.  Controls serve two functions:

  1. to ensure that security mechanisms are being followed and
  2. to ensure that the data and resources being secured are correct and accurate in the first place.

Whereas security analysis and its resulting measures are administrative in nature, controls analysis is mainly an accounting function.

Controls are used to ensure that

  1. All documents in a group of documents have been processed correctly
  2. Generated reports are numerically accurate
  3. All steps in a predefined series have been taken and completed satisfactorily
  4. Physical counts match calculated counts
  5. Certain actions are taken at the prescribed time
  6. Actual costs are kept within budget
  7. Information passed from workstation to workstation is accurate
  8. Staffing counts are kept within predefined levels
  9. Actual actions match planned actions
  10. Actual results match planned results

In all of the above cases, the goal is to ensure that what is actually done matches expectations and that the information upon which actions are predicated is accurate.

Normally, controls are applied to actions which

  1. Are very complex
  2. Involve a large number of steps
  3. Involve a large number of items
  4. Involve high cost
  5. Are highly susceptible to error
  6. Require a large number of people or units to complete

Controls are very similar to quality assurance tests in that the intent is to ensure that all actions have been taken correctly.  Normally controls are built into the actual processing steps of an activity; they usually involve verification of manual or automated actions by persons other than those who performed the original actions.

Controls may be applied item by item, such as rechecking order or invoice line item extensions and totals, or they may be applied to groups of documents together, such as generating a grand total of order totals and checking them against a manually generated total.

In our discussion of batch processing, we talked of batch controls (Figure 21.3).  These are control totals, which may be in the form of total dollars, total items, total documents, or some other procedure.  These totals are accumulated before the data are processed and are compared to the totals from the machine-generated reports.  If the totals agree, the batch is assumed to be in balance; if they do not agree, the individual items are examined to determine whether an item was missed or entered incorrectly.  When the error is found, the item is corrected and the entire batch is then resubmitted for processing.

Totals are also generated across batches to ensure that all batches are entered.  Since most systems generate large reports, financial or otherwise, most reports have one or more levels of totals.  They may be totals of numeric columns, total items, etc.  If the report is exceptionally large, there may be several levels of subtotals within the body of the report.  These are usually at logical breaks in the data and are usually taken at some change in the major report sequence field.  Aside from providing information to the report recipient, they also provide a mechanism for checking the report's accuracy and completeness, either on a manual or automated basis.

This type of totaling procedure is also used when files are processed to ensure that the proper number of transactions of each type have been processed, and that records have not been either added to or deleted from the file erroneously.

Controls may also take the form of checklists and signature sheets, where certain information is recorded as steps are completed.  This might include start and stop times, item counts, operator or clerk initials, batch numbers, machine meter readings, verifier or checker initials, supervisor initials, etc.  Figure 21.4 is a sample batch header form.

The analyst, working with the user and with the work and process flow analysis documents, as well as with the documents themselves, must determine where errors can originate and must devise procedures which can prevent the errors from or detect those errors that do occur.

In other instances, the analyst may have to determine methods for controlling the process themselves.  This may entail the creation of control logs or carrier documents which will accompany the documents being processed.  Figure 21.5 shows a sample batch control form.

The process of determining which controls to impose is very similar to a checks and balances operation.  For instance, controls should ensure that the people who perform a certain activity are not the same ones who check it or that testing or sampling procedures are devised which check work in progress.  In some cases, separate subsystems or activities may have to be devised for ensuring that proper controls are in place.  These controls could entail summary reports, comparison reports, variance reports, exception reports, statistical analysis, or in extreme cases duplication of processing.

Controls may also take the form of "audit trails" (Figure 21.6), which are reports or files generated from the business transactions of the firm.  Each transaction and activity is recorded as it is processed.  Each file add, change, and delete, each file access, each program execution, and each document processed is recorded or logged.  This ensures that if there were a need to re-create a portion of the work, there would be sufficient information, i.e., a "trail," to do so.  It also ensures that if there were a need to determine whether an activity was performed, who performed the activity, or when the activity was performed, there would be sufficient information available to make such a determination.

Most, if not all, DBMS products offer optional logging of transactions to the databases which they maintain.  Many make this type of logging mandatory, in that the DBMS will not operate without logging files.  Most telecommunications systems also offer logging of the on-line transactions processed by them, as well as logs of all file accesses and changes.  Most products offer security facilities, and access violations are logged to these files as well.

The type and extent of the controls to be imposed will often depend upon the nature and sensitivity of the work being performed, on the ability to reproduce the work should it prove to be defective or in error, or on the impact on the firm if any error should continue to be undetected.

To illustrate, it may be acceptable for errors to appear on internal documents, but totally unacceptable for the same type of error to appear on a document which is to be sent to the customer.  Again, it may be acceptable for costs to be slightly in error when work is being done internally (such as is common with internal information systems charge-back systems) but unacceptable when pricing an item for sale to a customer.

Aside from the above reasons for establishing control mechanisms, one of the major reasons for controls is improvement of the auditability of the firm's operations by both internal and external accounting functions.  These types of controls are usually applied to all activities

  1. Where cash, checks, or other monetary instruments are involved
  2. Which are reflected on the firm's books, balance sheets, or profit-and-loss statements
  3. Where company employees are handling customer funds
  4. Where real loss to the firm could occur
  5. Where the firm could incur liability if errors are not detected
  6. Where assets or resources of the firm which have real value are being handled.
  7. That ensure that the security and integrity of the firm's files and records are maintained.

Auditing and Auditability

All firms and organizations, both publicly and privately owned, governmental, charitable, profit making, or not-for-profit, must maintain books of accounts which record all business activities; transactions of a monetary nature; and acquisition, use, and disposal of inventory, raw materials, work in process, machinery, buildings and land, furniture and other supplies, stock, etc.  In short all assets and liabilities.  Periodically the status of these accounts must be reported to the various governmental entities for purposes of tax assessment, licensing, etc.  In the case of corporations, partnerships, etc., stockholders and regulatory bodies must receive reports on the financial status of the firm on a periodic basis.

The books of accounts or other records are normally prepared for the firm either by the management of each user area or by the internal accounting areas, although in some cases outside accounting firms may perform this work.  Regardless of who prepares the account books, the work of verifying and validating their accuracy and the related accounting functions is usually performed by external or "public accounting" firms, or by certified public accountants (CPAs) who are charged with the responsibility of making sure that such reporting is complete and accurate.  These certifications are required by and are acceptable to the various agencies to whom the reports must be made.

These accountants or auditors use various techniques to perform this verification and validation, in most cases relying on the records which result from the controls imposed by the firm for these purposes.  In many cases they will run their own tests, reports, etc., to ensure that their results match those provided by the firm.

If in their examination they determine that the controls or records are unacceptable or insufficient to properly verify or validate the business transactions, the auditors may ask that certain additional controls be imposed to assist them in their activities.  These controls may take the form of new reports or additions to existing reports.  Auditors may also impose requirements on the firm to retain original records for certain periods of time, to retain copies of critical transactions, to generate duplicates of various files and to undertake similar activities, and the analysts may be required to assist the auditors in this work.  The analyst must be sure that any statements of requirements include the system verification requirements of the auditors.

The Concept of Time

Time is a vital concept which must be kept in mind during the analysis process, more specifically the changes which occur over time, time dependencies, and the concept that certain things while changing over time may need to be retained as of a certain point in time.  The passage of time implies changes in state and in conditions.  Things which are valid now may not be valid a few moments from now.  These effects of time are incorporated into the data which are stored as a result of business activity and are also incorporated into the things which trigger certain business activities.

Examples of the importance of time are

  1. The price of a product is stored in a file along with other descriptive information about the product.  This file could be a product catalog, or it could be a information systems file.  When an order is placed, it may be for a specific product at today's price, at the price when it is shipped, at a price to be determined, or at a price which existed yesterday.  Which price is associated with that product line item on the order depends upon what the business rules state or upon the agreements made between the sales department and the customer.
  2. An invoice is prepared and sent to the customer.  It states an invoice total and may or may not reflect specific terms, such as "2/10 net 30," which means that if the invoice is paid within 10 days, the customer may deduct a discount of 2 percent; however, from the eleventh day on the terms are the net of the invoice.

    That same invoice, once mailed, begins to age.  The firm needs certain follow-up procedures, at the 10-day point, the 30-day point, the 60-day point (when the invoice is past due), at the 90-day point, etc.  Payments against the invoice may be received at any time after invoice mailing.  That payment may reflect discounted price, the net price, or the net price plus penalty charges (if any) for late payments.  The firm must be able to determine what payment is expected, at what times, and how to evaluate payments received.  At each of these points different actions need to be taken, all of which depend upon remembering two points in time: invoicing date and today's date.

  3. Employee reviews, salary actions, project schedules, and delivery schedules all require different actions depending upon the dates involved.

Time must be factored into data storage considerations, processing considerations, and most schedules.  These time equations must be incorporated into how long it takes to perform an action, how much time can be expected to pass before a response is forthcoming, and when the final action must be taken.

The analyst must determine just how critical the time factor is in the user area and to the user work schedule.  The time factor can be measured in terms of seconds, minutes, hours, days, weeks, months, etc.  Some schedules are fixed, others are highly flexible.  The clerk on the phone with the customer needs information instantaneously, but the correspondence secretary may have information response times of hours and perform in a perfectly satisfactory manner.

Another area where time is relevant is in the controls and audit trails of the firm.  Each transaction should be stamped with the date and time as it enters the firm.  All changes to the books and records of the firm should also be dated to reflect when the change was made.  All reports and documents should be dated, and in some cases time stamped to indicate when they were created or received into the firm.

In some cases only the item itself need be dated; in others it may be necessary to date the entire record with "from" and "to" effective dates and to store those records in historical files or archive files.

The analyst should determine the existence of, and the need for, any historical files or archiving of records as the firm's procedures and activities are analyzed.  In many cases new history files may be needed or the procedures for updating old ones may need to be revised.  In all cases the analyst should pay attention to these filing systems and to the material stored in them.

Some of the questions which should be asked when analyzing existing filing and archiving procedures are

  1. When was this file established?
  2. Under what conditions is it used?
  3. How often is it used?
  4. Under what conditions and how often is material deleted from the files?
  5. Of what use is the information in the file?
  6. Does the filing system have an index or reference system? Can information be easily obtained from the files?
  7. Is the index or reference system kept up-to-date?
  8. Is the need for this information still valid?
  9. Does the information in this file exist elsewhere, and can this information be duplicated easily?
  10. What controls exist to track material added to or removed from the files?
  11. Can the material be easily identified as to the time period when it originated?

Configuration Management

Configuration management is that set of processes and procedures which track and manage the structure of things, specifically hardware, software and documentation.  Configuration management when applied to information systems manages hardware, software (system and applications) and documentation.  In short all items which are subject to change and all items where knowledge of version, interoperability, interconnectivity or simple replacement or repair becomes important.

A Definition:

A configuration is a specific arrangement of items assembled for a particular purpose.

On a very simplistic basis all things are composed of elemental items, components and final assemblies.  For instance, a tire, a wheel, a car. 

Elemental items should be meaningful within a given context.  For instance: within the context of automobile manufacture, the meaningful elemental item is the tire, not the rubber, metal mesh and other chemicals which were used to manufacture the tire.  Within the context of tire manufacture the metal mesh, chemicals and rubber are meaningful elemental items.

Components, or assemblies are groups of elemental items assembled in a specific manner to accomplish a specific purpose.  Components may be designed or assembled for use within a single context, or may be designed or assembled for use in many different contexts.  Components may be combined into larger more complex components.

Final assemblies consist of all components in the completed product.  A final assembly is the sum total of the specific versions of the specific elemental items, grouped into specific components, and assembled in a particular manner.  This final assemble may also be referred to as a Configuration Item.

Final assemblies decompose into components.  Components decompose into other components and finally into elemental items.  The lowest level of a configuration is an elemental item

A Configuration Item may or may not include hardware, but it should always include requirements analysis, design, production and operational documentation.

A Configuration Item may be frozen in time, usually after review, approval and implementation.  This frozen configuration is referred to as a baseline.  A baseline is a known  is a frame of reference against which to measure all subsequent change, and may be used to determine if a change has been made.  The baseline forms a known starting point for beginning additional change, for making repairs and for assessing problem causes.

Configuration management helps assure that a known operational program was generated from an identified piece of source code, and that a specific version of the product is supported by a specific version of the documentation.  Configuration management ties all products across the life cycle to each other and ensures that the final product can be traced back to the original requirements.  It also ensures that what is produced is what was agreed to at each review point.

A configuration is associated with a specific product or item, and an item may have many separate configurations.  Configurations are maintained at many different levels and almost every item from the elemental unit to the final assembly should be supported by a configuration.

To Illustrate:

There are many levels of configurations and configurations can be documented at many points in the item life cycle.  Some configuration points are:

  1. As Designed
  2. As Specified
  3. As Built
  4. As Installed
  5. As Modified

Each configuration from design to installation can be slightly different from its predecessor. At some point, usually after installation a configuration is selected as a baseline. 

A Definition

A baseline is an item or collection of items of a particular shape and form used as a reference.   A baseline configuration is a reference point for evaluating modifications and enhancements and a starting point for making those changes.  This baseline is normally considered the “official” version of an installed and operational Configuration Item.

  1. Copies of the complete Bill of materials for the Configuration Item
  2. Copies of the bill of Materials explosion for the Configuration Item, annotated with model and serial number of each component and each elemental item
  3. Manufacturer name of each instance of each component and each elemental item<
  4. Date of manufacture of each instance of each component and each elemental item<
  5. Time of manufacture of each instance of each component and each elemental item
  6. Place of manufacturer of each instance of each component and each elemental item
  7. Raw materials source of each instance of each component and each elemental item
  8. Method of manufacture of each instance or construction of each component and each elemental item
  9. Model number of each instance of each component and each elemental item
  10. Serial Number of each instance of each component and each elemental item<
  11. Installation documentation for each unique instance of each component and elemental item,
  12. Repair, Maintenance and replacement options and copies of all repair, maintenance and replacement documentation for each unique instance of each component elemental item
  13. Replacement and substitutions list for each unique instance of each component and elemental item
  14. Repair, maintenance and replacement options and restrictions list
  15. Copies of all requirements and specifications documentation for each unique instance of each component each elemental item
  16. Copies of all operational documentation for each separately usable component (e.g. mouse, hard drive, monitor, CD-ROM Drive, etc.)
  17. Copies of all blueprints or design  documents for each unique instance of each component and elemental item
  18. List of Engineering Changes for each unique instance of each component and elemental item
  19. Copies of all test results, if appropriate for each unique instance of each component and elemental item
  20. Copies of all inspection documentation for each unique instance of each component and elemental item
  21. Copies of all review and approval documentation for each unique instance of each component and elemental item
  22. Copies of all training materials for each separately operable, usable or user maintainable repairable or replaceable  component and elemental item
  23. List of options available along with pre-and co-requisite for each unique instance of each component and elemental item
  24. Electronic copies of all analysis, design, specification, review, verification and construction models developed using Computer-Aided Design/Computer Aided Manufacturing (CAD/CAM) tools associated with each separately identifiable, traceable and modifiable component and elemental item
  25. Version model and serial number of each Computer-Aided Design/Computer Aided Manufacturing (CAD/CAM) tool used during the analysis, specification, design, development and implementation of each separately identifiable, traceable and modifiable component and elemental item

Software Configuration Item information can include any or all of the following:

  1. Copies of all requirements documentation for the software Configuration Item
  2. Copies of all specifications documentation for the Software Configuration item.
  3. Identification of each separately identifiable, traceable and modifiable software component
  4. Version and release identification for each separately identifiable, traceable and modifiable software component
  5. Version and release identification for each separately identifiable, traceable and modifiable group of software components
  6. Date of code submission for each separately identifiable, traceable and modifiable software component
  7. Version and release identification of associated code for each separately identifiable, traceable and modifiable software component.
  8. Electronic copies of each piece of associated code for each separately identifiable, traceable and modifiable software component.
  9. Identification of the version and release of the language processor or other code generation software for each use of each software component
  10. Operating system requirements for each separately identifiable, traceable and modifiable software component
  11. Central processing unit requirements and specifications for each software component
  12. Peripheral requirements and specifications  for each software component
  13. Identification and specifications of each data input item for each separately identifiable, traceable and modifiable software component
  14. Identification and specifications of each interface with any other software components within the same Software Configuration item for each separately identifiable, traceable and modifiable software component
  15. Identification and specifications of each interface with any other software components or with other Software Configuration items external to the  Software Configuration Item for each separately identifiable, traceable and modifiable software component
  16. Copies of all operational documentation for each separately useable software component (e.g. Input screen, query, report, etc.
  17. Copies of all requirements and specifications documentation for each separately identifiable, traceable and modifiable software component
  18. Copies of all installation documentation for each unique instance of each separately installable software component
  19. Copies of all training materials associated with each separately operable or usable software component
  20. Repair, Maintenance and replacement options and copies of all repair, maintenance and replacement documentation for each unique instance of each software component.
  21. Replacement and substitutions list for each unique instance of each separately identifiable traceable and modifiable software component
  22. Copies of all design documents for each unique instance of each separately identifiable, traceable and modifiable software component
  23. List of Engineering Changes or code modification  history for each unique instance for each separately identifiable, traceable and modifiable software component
  24. Copies of all test results, if appropriate for each unique instance for each separately identifiable, traceable and modifiable software component
  25. Copies of inspection documentation for each unique instance for each separately identifiable, traceable and modifiable software component
  26. Copies of all review and approval documentation for each unique instance for each separately identifiable, traceable and modifiable software component
  27. List of options available along with pre-and co-requisite for each unique instance for each separately identifiable, traceable and modifiable software component
  28. Electronic copies of all analysis, design, specification, review, verification and construction models developed using CASE tools associated with each separately identifiable, traceable and modifiable software component.
  29. Version model and serial number of each CASE tool used during the analysis, specification, design, development and implementation of each separately identifiable, traceable and modifiable software component.

Configuration management can be restricted documentation only in which case the configuration manager will maintain strict control of each version of each documentation item.  Documentation configuration management can include each separately identifiable and traceable version of each:

  1. Design document
  2. Analysis document
  3. Requirements document
  4. Specifications document
  5. Project management plan and schedule document
  6. Memoranda
  7. Incoming and outgoing letter and other correspondence
  8. Incoming mail and outgoing facsimile transmission (fax)
  9. Formal and informal presentation
  10. Installation manual or document
  11. Maintenance and repair document
  12. User Guide
  13. Training guide
  14. Training material item

Change Management

Change management is closely associated with configuration management.  Change management is that set of controls and processes designed to ensure that:

  1. Only approved changes are applied
  2. That the impact of any given change is fully assessed
  3. Any change is applied to all necessary and affected components
  4. That all necessary configuration changes are recorded
  5. That all changes are fully documented
  6. That all organizational units which might be affected by a given change are notified and have approved of the proposed change
  7. That all proposed changes are scheduled in advance and that a proposed change does not impact another change already in process
  8. That all changes to documentation or program code are clearly identified
  9. That all models associated with the changed components are modified and updated to reflect the change.
  10. That the component or elemental unit to be changed is checked out from the baseline

 “Checking out” from a baseline, entails flagging the item (e.g. piece of code, documentation, component) such that no other person may used it for purposes of changing it.   This ensures that concurrent changes are not made to the same component by different unrelated projects.  It also alerts other projects that a change is being made to a specific component and that they must expect those changes, and not plan other changes until the item is “checked in” to the configuration.  Once a changed item is “checked in” a new configuration is established. and this new configuration replaces the previous configuration as the official baseline.

Change management is also responsible for maintaining a change history for every component.  For each change the following information should be recorded:

  1. Name of the person responsible for the change
  2. Description of the change
  3. Components or items involved in the change
  4. Description of the circumstances or conditions which necessitate for the change
  5. Description of any items that might be impacted by the change
  6. Description of the potential impact of the change on any user area and a description of that impact
  7. Description of any risks associated with this change
  8. Description of the actions that will be taken to mitigate the risks of associated with the change
  9. Description of the plan to be followed and the actions to be taken if the change does not work (The plan to back out the change)
  10. Date the change was requested
  11. Date the change was approved
  12. Date the change was schedule for completion
  13. Date the change was actually completed
  14. Date the change was tested
  15. Description of the tests and the test results
  16. Date the testing was approved
  17. Date the new baseline was established
  18. Description of the changes to each checked-out component
  19. Description of any new or deleted items involved in the change
  20. Copies of all documentation changes necessitated by the change
  21. Copies of any new training materials necessitated by the change

Each proposed change should be preceded by a notification to all users that the change has proposed.  It should request users to submit a statement describing the impact (or lack of impact) of the change on them.  Copies of all user impact statements should be included in the change documentation  package.  Copies of all user notifications and distribution lists should also be included.

Disaster/Emergency Preparedness

Disaster/emergency preparedness is that set of processes, activities and plans designed to ensure that the firm is prepared for events that are disruptive to the conduct of the business. Business disruptions can be minor or major.  Disaster plans must accommodate any type of disruption and have a plan in place to ensure that business activities resume as normally as possible in the minimum amount of time.

The following events constitute business disruptions:

  1. Power outages or major power reductions
  2. Communications disruptions (e.g. Communications line disruptions, solar flares)
  3. Weather related business disruptions (e.g. Rain or snow storms, floods, hurricanes)
  4. Personnel related business outages (e.g. Strikes, riots, wide-spread illness)
  5. Outbreak of hostilities causing a disruption in business
  6. Software related business outages (e.g. Software virus infection,
  7. Hardware related business outages

A Business Recovery plan should be in place containing the following information:

  1. A management chart of organization designating responsibilities in the event of a business disruption incident
  2. Designation of personnel empowered to verify the existence of a business disruption incident
  3. Names and contact telephone numbers and alternates for all persons who must respond in the case of business disruption incident
  4. A “phone tree” designating personnel to be called, order or contact, and responsibility for notification
  5. A list of critical applications
  6. A list of critical files and the location of the primary or back up copies of each file
  7. A schedule of critical file backups, for each critical application
  8. A schedule of system file backups
  9. The location of all critical files, or copies of critical files maintained in case of a business disruption incident
  10. A list of all forms and special supplies required for each critical application
  11. The location of the stock maintained in case of a business disruption incident
  12. A list of critical documentation for each application
  13. The location of each item of critical documentation
  14. A description of the minimum hardware configuration necessary to run the critical applications
  15. The location of any spare parts or supplies maintained in case of a business disruption incident
  16. The names and contact numbers of critical operational, data entry and verification personnel for each application
  17. The names and contact numbers of critical operations and support personnel
  18. The names, addresses, names of contact personnel and contact phone numbers for any business disruption incident hot-sites (pre-arranged locations where the firm’s applications can be run)
  19. A manual of any special processes or procedures to be followed in the event of a business disruption incident
  20. The names, addresses, contact names, and contact numbers of non-company personnel to be contacted in the event of a business disruption incident
  21. The names, addresses, and phone numbers of persons or companies responsible for providing transportation for personnel, supplies and files to the hot-site, if necessary
  22. The names, addresses, and contact names and phone numbers of hotels or motels to be used in the even of a business disruption incident
  23. The names, addresses, contact names, and phone numbers of any non-company locations where arrangements have been made for business resumption activities to occur.
Contact Martin Modell   Table of Contents
A Professional's Guide to Systems Analysis, Second Edition
Written by Martin E. Modell
Copyright © 2007 Martin E. Modell
All rights reserved. Printed in the United States of America. Except as permitted under United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a data base or retrieval system, without the prior written permission of the author.