Standards & Guidelines: Software Development / Production Support Process Introduction This document outlines the processes by which

software development and production support activities will be conducted. It is a general guideline that identifies the major steps in these processes and the sequence by which they will be accomplished. New Development Process New development projects will be initiated when service requests are received from functional customers or project directors for technical upgrades. 1. Technical project management staff will enter the requests into the established service request system and circulate copies to the project directors, lead analysts and developers who will evaluate the request for resource requirements. The appropriate developers/lead analysts will enter time estimates for development and testing along with any comments for decision making/ approval and prioritization. Time estimates should be completed by the appropriate developer/lead within 1 day of receiving the request. Time for DBA migrations will be entered by the developer/lead as 1 day, unless it is a major migration or modification of the database. For those situations, forward the request to the DBA group for the time estimate. New requests go to service.requests@oit.gatech.edu and are entered into ADAM (http://www.adam.gatech.edu/) Change Control Review Board or team lead must approve service requests. If additional materials are included, note location in comments section.

2. Developers will be assigned tasks for the project by the lead analyst and/or project director after the appropriate review board or lead analyst approves the service requests. These tasks will encompass both development and testing. The lead analyst should use MS Project for tracking the progress of projects where appropriate. The tasks must have due dates and the technical specifications documented.

3. When new applications or major enhancements are requested that have complex visual components, the lead analyst will develop a prototype from the functional customers design requirements. 4. When the developer has completed the unit testing, they will turn over the completed module folder to the lead analyst prior to requesting migration to the test environment. The cross tester may participate in the unit testing or do formal testing as outlined below.

Page 1 of 5

07/11/2003

Standards & Guidelines: Software Development / Production Support Process 5. The lead analyst will follow guidelines defined in Lead Analyst Responsibilities prior to migration of the module. The Lead Analyst Responsibilities document has references to these items: Migration Email Generator (MEG, located at http://www.meg.gatech.edu/), Module Folder Guidelines, and Revision Control System Instructions (RCS, located at http://aswan.gatech.edu/docs/eis/standards/rev_con.pdf).

6. The EIS Management Group determines what must be tested by RADAR. If RADAR is not engaged, then a cross tester is assigned to formally test the modules. The developer and/or lead analyst submits a Test Request Form (http://www.eis.gatech.edu/radar/testform.htm) and then turns over the documentation folder to the RADAR group or designated cross tester. 7. The RADAR/designated cross tester will schedule a time for a brief turnover meeting when he/she is ready to begin testing the module. These meetings need only be long enough to convey essential information to the tester but may result in additional meetings as testing progresses. For larger or complex projects where appropriate, the team leader conducts a peer code and object review. 8. The team lead requests module migration to the test environment by completing the Migration Email Generator (MEG) form and sending it to migrations@oit.gatech.edu with copies to project director, lead analyst, developer, tester and appropriate functional customer. 9. The tester will ensure the functional accuracy of the process, as well as compliance with EIS guidelines/standards (see the Test Plan Template and Standards documents). The tester will track any problems found in testing in the trouble reporting and tracking system or via email. The tester and developer will work together to resolve all issues. The tester will inform the developer, lead analyst and/or project director of all issues when the testing is complete. Signoff email is required by lead analyst or developer upon successful completion of testing. 10. The lead analyst will review the module and the test results. When the lead analyst is satisfied with the module folder, he/she will notify the functional customer and also turn over the operational documentation to the functional customer. Note: Vendor standards must be followed for code developed locally. If developer or tester is unsure of how standards/guidelines should be followed, they should discuss their concerns with the lead analyst and the project director. 11. After the functional customer has been notified, there may be a turnover meeting, if needed. Make sure that the customer understands how to test and has a test plan for ensuring that a module meets their business needs. All problems found by the functional customer should be

Page 2 of 5

07/11/2003

Standards & Guidelines: Software Development / Production Support Process reported back to the developer via email. Once the functional customer is satisfied that all testing is completed and the module is working as expected then a request is sent to the lead analyst stating they have approved the module to be migrated to production. The turnover meeting optional but all other items are required. Operation documentation may be necessary and is required for any process run by FDP.

Production Fix Process The following procedures will be used when a problem is discovered in a production system. A production system is defined as any system that has been approved to process live data for Institute business by the functional customer. 1. Anyone who discovers an error in production software or data may report the problem to the appropriate lead analyst or project director. This notification may be verbally, via email or an entry in Remedy. The lead or project director will enter the problem in ADAM for a programming error to get a change control number and/or submit via email a PRODSUPP Change Log for a data issue. 2. If the problem is software related, the lead analyst assesses the problem and assigns it to the appropriate developer. If the problem is data related, the lead analyst can obtain the PRODSUPP password from a project director with documented functional approval. 3. When the developer resolves a problem related to a programming error, they should follow steps 4 through 11 above with the following exceptions: a. Include a note in the migration message identifying this as a production fix indicating the Change Control Request number. b. If software related, leads or project directors will mark the ADAM entry as fixed when the functional customer approves the item. The customers email approval message can be used to cut and paste into the ADAM resolution. If data related, leads or project directors will follow the steps for use of PRODSUPP. c. If the problem was entered in Remedy, the lead must mark the Remedy request as completed.

Page 3 of 5

07/11/2003

Standards & Guidelines: Software Development / Production Support Process

Page 4 of 5

07/11/2003

Standards & Guidelines: Software Development / Production Support Process

Page 5 of 5

07/11/2003