Alabama's Public Liberal Arts University

Computer Services

Examples and Instructions
for Application Service/Change Requests
(SIS, FAM, HRS, FRS or Self Service Products)

 

Service Request Process

Please read these instructions to determine the type of change you are requesting.

System Modifications
Data Base Value Changes and/or Additions
New Screens
Menus
New Fields
Focus Program (Focexec)
Self Service Products Web Pages


System Modifications

Systems modifications should be rare and only used in cases where University policy and/or procedures cannot be changed.

  1. The user sends the system modification request to the Applications Manager using the Service/Change Request Form.
     
  2. The Applications Manager logs the request and assigns the investigation of the request to a programmer.
     
  3. The programmer analyses the following:
     
    1. the difficulty of making the change
       
    2. the implications for future TOSes
       
    3. Impact to other programs
       
  4. On of three things will occur, depending on the application affected.
     
    1. If it is a SIS+ application, the programmer meets with SIS+ at its regularly scheduled meeting to present his/her findings.
       
    2. If it is a FRS application, the programmer first meets with person making the request and the immediate supervisor, if necessary.
       
    3. If it is a HRS application, the programmer first meets with the person making the request and the immediate supervisor, if necessary.
       
  5. If approved, the programmer will then draw up the plan and present it to the requestor for approval  and sign off.
     
  6. The supervisor at the Vice Presidential level will be informed of the modification and its implications and asked to sign off on the request.
     
  7. The modification is made.
     
  8. The user signs off.

Data Base Value Changes and/or Additions

Database value changes are simply the creation or addition of new values for fields already created.  This is a simple change and can be handled in a few steps.

  1. A DBD change request is made via the Service/Change Request Form to the Applications Manager.
     
  2. The request is logged.
     
  3. The request is acknowledged and an estimated time for entry is sent to the requestor.
     
  4. The Applications Manager or one of the programmers will make the change.
     
  5. A DBD cycle is run.
     
  6. The user is notified that the change has been made.

New Screens

The creation of a new screen occurs only when a clear case is made for a new screen.  This is not due to the difficulty of creating a screen but the difficulty of moving too many of them when TOSes are applied.  Therefore, the creation of a new screen is not to be entered into lightly.  The following procedures should be followed:

  1. The user makes the request for a new screen to the Applications Manager via the Service/Change Request Form OR
     
  2. The user and/or one of the programmers feels strongly that the addition of a new screen would be of great benefit to the user.
     
  3. The request is logged.
     
  4. The Applications Programming Team meets:
     
    1. The need for the screen is discussed thoroughly.
       
    2. If accepted, a plan is drawn up to create the new screen.
       
    3. A programmer is assigned.
       
    4. A notice is sent to the user that the screen will be created and an estimated date of completion is included.
       
    5. The immediate supervisor of the user is informed that a change is taking place.
       
    6. The screen is created.
       
    7. The user signs off.

Menus

Menus are created when users want to automate requests, such as focus requests and batch requests.  When menus are created, the responsibility for the results is on the programming staff rather than on the user.  While the programming staff does not mind the responsibility, it often does not understand the information the user desires.  Therefore, menus to automate processes will be discouraged.  When they are used, there will be detailed documentation of the programs (focexec and batches) they are running.  The procedures for modifications will apply to menus.

New Fields

Sometimes users need new fields to enter data that is not provided on the system.  The system applications make allowance for this by having filler available for this very purpose.  Flags are also available to be used when possible.  Flags will be the first priority to creating new fields.  The procedures are as follows.

  1. The user requests the change from the Applications Manager via the Service/Change Request Form.
     
  2. The request is logged.
     
  3. The Applications Team meets to discuss the request.
     
  4. The team decides on the best course of action.
     
  5. The appropriate programmer is assigned to the task.
     
  6. The user is informed that the field will be created and asked to send any values associated with the field.  The user is given an estimated date of completion.
     
  7. The fields are created and noted in the online database and programming in the appropriate application.
     
  8. The user signs off.

Focus Program (Focexec)

Focus programs are used to create reports and/or to make mass changes to a field.

  1. The user requests the change from the Applications Manager via the Service/Change Request Form.
     
  2. The request is logged.
     
  3. The appropriate programmer is assigned to the task.
     
  4. The programmer contacts the requestor to confirm his/her understanding of the request. The user is given an estimated date of completion.
     
  5. The focexec is created and tested with the user.
     
  6. The user signs off on the request.

Self Service Products Web Pages

Sometimes users need or want changes to the preset Self Service web pages.

  1. The user requests the change from the Applications Manager via the Service/Change Request Form.
     
  2. The request is logged.
     
  3. The webmaster is assigned to the task.
     
  4. The webmaster contacts the requestor to confirm his/her understanding of the request.  The user is given an estimated date of completion.
     
  5. The webpage is changed or created and tested with the user.
     
  6. The user signs off on the request.

 

Updated December 2004