Guidelines for Developing Policies and Procedures

Note: I developed this based on ISO guidelines for Computer Systems. This can be modified/ simplified for PERC's use.

Matt: I think it's a good idea to draw on the experience of others when developing guidelines, thanks for putting this up. Below I've commented on the general structure of the document, not so much the content. We of course need to distinguish between WC and IT Admin.

Guidelines for Developing Policies and Procedures

Policy definition

1. Purpose of the policy 2. Scope of the policy 3. Definition of terms used in the policy 4. References - links 5. Procedure for executing the policy 6. Change Control 7. Effective date

Example :

PROCEDURE : SOFTWARE LOADING, SOFTWARE UPGRADATION, ACCESS RIGHTS OF COMPUTER SYSTEMS DOCUMENT CODE :  PERC/WC/1.1                                 EDITION :  1 ISSUE DATE            :    10/07/03                                   REVISION NUMBER : 00 EFFECTIVE DATE :    01/08/03                                   PAGES :  01 to 03

SOP (Standard Operating Procedures) for software loading, software upgradation, access rights for the system, files, programs : 1.0 Purpose :    To define the procedure for loading new software into a computer system, upgrading of existing software on a computer system, access rights of the system and programs & files stored on it.

Matt: having a purpose for guidelines is a good idea, and something that I missed. But I think that what we've got here is indications for using the guidelines, rather than the purpose for having the guidelines. The purpose to me would something like "This policy ensures that the perc computers remain secure and functional and to ensure that the documentation provides people maintaining the computers with enough information." etc etc.

Lakshmi: Purpose as defined in ISO is the purpose of this document. As you suggested it can be modified to describe the action instead which would be more appropriate for PERC.

2.0 Scope :  This procedure applies to all computer systems in PERC

3.0 Definitions : Software : is a set of instructions to be performed by the computer to get the desired output. User       : is a person who actually operates on the computer system. System   : is synonymous to unit/terminal, which is allotted a unique System Number.

4.0 References :
 * ISO 9001

Matt: I think that 2 3 and 4 above can be consolidated into more of a general "project descriptions" except perhaps a seperate section for "links".

Lakshmi: Since 2 3 and 4 deal with different points, I am not sure how it can be consolidated. But we could give it a try.

5.0  Software Standards : All system software and standard packages used in the company are Open Source In-house tuning of software is specific to PERC's requirements Any software obtained from a third party for our specific requirements, have been legally purchased and are maintained by the seller.

6.0 Procedure :

6.1 : Loading of software The Web Committee members will take care of loading of software in the existing computer systems or newly acquired systems. No software can be loaded on any system, without the knowledge of the Web Committee.

6.2: Softwares required Web Committee and the PERC Coordinator, together will decide on what softwares are essential for PERC's functions.

6.3 : Standard & Specific softwares Standard softwares that are loaded on all computer systems are : Windows 95 operating software, Microsoft Office 2000, Lotus Smartsuite 97, Anti-virus software. In addition to these if any specific software is needed, it is loaded only on those systems.

6.4 : Upgradation of software The WEB Committee will decide if the standard software have to be upgraded to the next version. If it is necessary to upgrade, Web Committee will take care of upgrading the software, testing and getting the users acquainted with the new software.

 6.5 : Operating the computer systems The PERC Volunteers are the authorized users of the computer systems. The Coordinator or Web Committee gives each volunteer a login and password. When the system is not in use, the system should be switched off by the user or user should log out of the system if it is on LAN.

Matt: This all seems good stuff.

6.6 : Passwords and changes 6.6.1 User is advised to change password once in six months for security reasons.

6.7 : File and Directory level security on the local harddisk and LAN server harddisk 6.7.1 Each user in the company requiring the services of the Local Area Network, is
 * issued a unique logon name and they have their own password. The access to
 * the directories and files on the server are restricted to their area of use.

6.7.2 On stand alone systems, when the file is of highly confidential nature, a file level password is given to ensure that the contents are not tampered with or unauthorized persons do not open the file. 6.7.3 There are mainly two types of files : text files and data files. Any changes to be made to the data files have to be done through the given software program that creates the data file. The changes to the text file has to be done only by the creator of the file. 6.7.4 Under a windows NT workstation operating system, access rights to  users are given to read, write, change or delete files. Directory level rights are given to users on the LAN. Deletion of directories or files can be done only  by  Coordinator or the Web Committee Chair. Changes in files can be done by the creator of the file.

6.8 : Program entry security 6.8.1 : In-house Open Source software used by PERC, have a entry level password which are known only to the user. 6.8.2 : The user enters the software by giving the password. On completing the operations the user should quit the application to ensure that system is ready for the next user.

Matt: All this security stuff seems to me should be in a different guideline (Using perc software etc.)

Lakshmi: That's a good idea

Effective Dates :

This procedure comes into effect from 01/08/03 (i.e first of August 2003 A.D) at 00.00hrs (midnight of 31/07/03 and 01/08/03).

Change Control :

Any change in this document shall be made only in accordance with the systems document PERC/WC/1.1

-

Suggested SOPs for WC:

1. SOP for Software Loading & Upgradation 2. SOP for Access Rights to Computer Systems and Software 3. SOP for Validation & Verification of Software Covers - software developed in house (requirements, desigining, programming, testing, implementation, validation, verification, maintenance) - software developed by outside party (testing, implementing, validation, verification, source code, maintenance) - documenting test results - monitoring & verifying the systems (maintenance, upgradation)

4. SOP for Data & file operations Covers - data entry (authorization) - data modification (authorization) - data deletion (authorization) - file versions (SOP, Batch Sheets, authorization) - file deletions (authorization)

5. SOP for Archives Covers - taking backups (media, how stored, where stored) - storing archives (old versions, period of storing, where stored, how stored) - restoring from backups (speed of recovery)

6. SOP for WC's responsibilities in projects involving other committees

7. SOP for WC's own projects

-

Data for each system to be maintained

SYSTEM DETAILS

System No - Location - Configuration -

Software Loaded -   Name                 Purpose used for

System Used For -

Security Levels -

Does the system have a start up password ?

If Yes, Who are aware of it?

Who is authorized to open it?

Are the password noted down anywhere?

Who is authorized to take printouts?

Who has the authorization to copy files, transfer files from one system to another, take backups into floppies?

Authorization for Changes -

Who is authorized to make changes in files ? : Are changes made documented?

Purpose of this System in future -

What controls are intended in future -

Correction in files /data : Deletions  of files / data :

Additions of files / data : No.of copies Printed :

Backup System -

What is your present system ?

Where are archives stored?

Is the present system adequate ?

Any additional Comments :

 Developement Cycle

The iterative development cycle is a spiral that passes repeatedly through four phases

1. Plan. In this phase, you are trying to understand your users and their needs, as well as how you want to address those needs.

2. Implement. During implementation, you build a prototype to test the solutions you developed during the planning phase.

3. Measure. Now it's time to see how users react. How long does it take them to understand your solution? How long does it take them to do their work? What problems do they encounter? It is important to understand that measurements must be both objective and subjective; time on task is important, but if a user takes more time because the tools enable him or her to do a superior job, then you must be able to weigh improved quality of work against increased time on task.

4. Learn / Feedback. This is the analysis phase, where you decide which parts of your prototype are doing well, and which parts are not.. This takes you back to planning.

Matt: Ok, this development cycle makes sense on an abstract level, and I understand that the perc uses something similar to this, but I am still not sure how to translate the above cycle into specific action.

Peter: Looks like a good organizational structure.I am collecting the various projects now and will organize them into a wiki page with this structure in mind.