Information Technology Services

Development Methodology

The purpose of this document is to define practical standard procedures and guidelines to be followed during the course of all projects undertaken by the Banner Support Group within Management Information Systems (MIS) at The University of North Carolina at Greensboro (UNCG). The focus of this document centers around projects. For this document, a project is defined as an item placed on the Project Schedule maintained by the Applications Development Manager (ADM).

This document augments the existing MIS Policies and Procedures manual. Frequently, references are made to that manual within this document.

• Project Startup
• Analysis
• Design
• Development
• Testing
• Implementation
• Project Close

Project Startup

• Project Initiation
  MIS Projects typically are initiated when MIS clients request services via the MIS request form. Projects may also be initiated by other means, such as from within MIS or by clients requesting an MIS staff member to participate on a workgroup or taskforce.
• Priority
  Projects are prioritized primarily using input from MIS client management. Project priorities may change for a variety of reasons.
• Analyst/Programmer(s) Assigned to Project
  The ADM will assign an analyst and a programmer(s) to each project. The analyst and the programmer may or may not be the same person. These assignments may not occur immediately upon receipt of a request. In some cases, an analyst may be assigned and work may begin on a project before a programmer is assigned.
• Project Title Assigned
  The ADM and the analyst will assign a project title. This will be a brief descriptive call name for the project. It should be used when referencing the project.
• Analyst's Primary Responsibilities
  • acts as the leader for the project
  • is responsible for the overall management of the project
  • develops overall documentation for the project
  • documents activities and milestones for the project
  • acts as the primary liaison between MIS and the client
  • informs the ADM at least weekly of the status of the project
  • sees to implementation of new objects into pre-production and production
  • oversees the project from beginning to end
• Programmer's Primary Responsibilities
  • participates in most if not all project discussions
  • may develop program specific documentation
  • informs the project analyst of the status of tasks
• Establish Project Documentation Folder
  (Refer to MIS Policies and Procedures manual sections 2.1 through 2.3.2)
  Those involved with the project should retain documentation for the project in an orderly manner by using a folder or binder or any other appropriate means.
  
• Analyst Will Notify Client of Actual Start Date
  This date may be different than the scheduled start date.

Analysis

(Refer to MIS Policies and Procedures manual sections 3.1 - 3.5.2)

• Analyst Holds Primary Responsibility for Project Analysis
  When appropriate, the programmer assigned to the project should play an active role in the project analysis under the leadership of the analyst. The programmer should be included in discussions with clients whenever possible. The ADM should be included when appropriate.

Design

• Design Document
  (Refer to MIS Policies and Procedures manual sections 2.4.1 - 2.4.3 & 3.6 - 3.6.6)
  The analyst will develop a design document for all but the very simplest projects. This documentation should include but is not limited to:
  • title
  • background
  • overview
  • interfaces to other systems
  • process descriptions
  • batch process parameters
  • naming conventions of input files and any output generated other than standard report name
  • file layouts of ascii files used as input or output
  • psuedo-code
  
  

  The design document must be discussed with and approved by the ADM, analyst, and clients. The design for projects of a more complex nature should be formally presented to clients and management.

• Estimate Number of Days to Complete
  The analyst and programmer(s) should develop a new estimate of number of days to complete the project and have it approved by the ADM. This will be reflected on the project schedule.

Development

(Refer to MIS Policies and Procedures manual sections 3.8.1 & 4.1.2 & 4.4 - 4.12.3)

• Development Occurs in Development Environment
  Before modification of any existing programs, compare development version to production and pre-production versions. Differences should be resolved before proceeding. Also, look to see if any new versions of the programs are available.
• Save Development Files in Secure Personal Area
  New/modified programs/scripts should also be saved in developers personal share area located at ATHENA::DEVSHAREVOL:[SHARE...]. Work-in-progress stored in the Development Banner Code Tree could be inadvertently destroyed by others with access to the development environment. This will allow for someone to find and use a developer's work-in-progress in the case where the developer is unexpectedly out of work.
• Language Specific Documentation Available for the Following:
  
  • SQR
  • Forms
  • Database Objects

Testing

(Refer to MIS Policies and Procedures manual sections 3.10.8 & 4.13)

• Security
  

  New processes or forms must be set up in Banner security. If a new object is created, execute the GZANOBJ script to put object in Banner Security for UGDEV1.

• Test applications thoroughly in Development Environment
  
  • Ensure batch processes run properly from Banner Job Submission
  • Ensure forms run properly from the Banner Forms environment
  • Review batch log files
  • Allow clients to review any output or forms
• Request a database refresh if necessary
  

  A refresh of the UGDEV1 database should be anticipated and planned ahead of time. A message should be sent to the BWMIS-L listserv to allow MIS staff to prepare for the refresh. Consent from all Banner support staff is not necessary but would be best. Approval from the ADM is required for a refresh of UGDEV1. The DBA should send notification about when a refresh will occur to BWMIS-L at least one day before the refresh.

• Prepare migration request
  

  The analyst is responsible for developing a migration request. This request will be used by quality control and the ADM for reviewing purposes and eventually by the DBA to migrate into pre-production and production. Include all of the following that apply:

  • environments to migrate from/to (either Development to Pre-production -OR- Pre-production to Production)
  • SQR process (includes .COM, .SQR, generate a .SQT, copy jobsub parameters)
  • form, form description, menu placement (added to GURJOBS? table, menu)
  • other files to copy, delete (retire), rename, generate
  • scripts to execute for creating/recreating database objects
  • scripts/programs to be executed for conversion purposes
  • whether or not to copy job submission parameters
  • Banner security class(es) for testing purposes. User contact should be able to tell us the Banner class, but it may help to look in the X:\Banner\Documentation\Security folder at the security spreadsheets.
  • timing/scheduling issues
  • any other necessary or helpful information as appropriate.
• Ready for review
  

  The analyst should notify the ADM that a project is ready for review. The implementation statement should be included with this notification.

• Quality Control
  

  The ADM may ask that work be reviewed by a Quality Control coordinator. If so, the Quality Control coordinator will review the work and report findings to the ADM.

• Notification to analyst/programmers
  

  If any issues arise during the review process, the ADM will discuss those issues with the analyst/programmers. If necessary, rework should occur.

• ADM Approval
  

  Once all issues have been resolved with development work, the ADM will inform the analyst/programmers that it has been approved. The ADM will then initiate the migration to pre-production.

Implementation

• Migrate from Development to Pre-production
  
  1. After development work has been approved, the ADM will forward the implementation statement written by the analyst to the DBA via email.
  2. The DBA installs into pre-production and notifies the ADM and analyst via email.
  3. The analyst notifies client that testing is ready to begin in pre-production.
  4. The analyst helps client as necessary to understand and test the new features.
  5. The analyst contacts the client approximately once a week to ensure the enhancement is being tested.
  6. The client notifies analyst via email that the application has been tested and is ready to migrate to production.
  7. Analyst forwards message from client to ADM via email that the applications have been tested and are ready to migrate to production.
  8. The ADM will then initiate the migration to pre-production with the DBA.
  9. Executable's and SQR .SQT files will not be copied into a new environment. These types of files will be regenerated in the new environment. Source code requiring compilation will be compiled in its own environment. This will help to ensure that executable code is synchronized with the source code in that environment.
• Migrate from Pre-production to Production
  
  1. After development work has been approved by the client, the ADM will forward the implementation statement written by the analyst to the DBA.
  2. The DBA installs into production and notifies ADM and Analyst with CC to client.
  3. The analyst follows up with client reminding them that security may need to be set up and requesting the client to check out the application in the production environment and notify us of the results.
  4. Client notifies analyst of results via email.
  5. Analyst forwards message from client to ADM that the applications have been tested and are ready to be moved to production.
  6. ADM will move final copy of project documentation to the UNCG documentation area and mark the project closed.

Project Close

(Refer to MIS Policies and Procedures manual sections 3.9.3 & 3.10.9)

• Project analyst notifies client, ADM, and anyone else that may have an interest that the project is considered complete.