When such a new system is called for, ESI follows a systems development life cycle (SDLC) methodology as outlined below. The more expansive the system, the more closely these guidelines are followed. The general outline, in process order, follows:
|Project planning, feasibility study:||Establishes a high-level view of the intended project and determines its goals.|
|Systems analysis, requirements definition:||Refines project goals into defined functions and operation of the intended application.|
|Systems design:||Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, and other documentation.|
|Implementation:||The actual system code is written.|
|Integration and testing:||Brings the various modules together into a testing environment to check for functionality, errors, bugs, and interoperability.|
|Acceptance, installation, deployment:||The final stage of initial development, where the software is put into production and executes actual business processes.|
|Maintenance:||Changes, correction, additions, moves to a different computing platform and more.|
Processing Requests for Services
Lehigh’s ESI department utilizes a product known as Request Tracker (RT), a widely used open source system, to initiate, document and monitor users’ requests for services. The RT system is set up to mirror the structure of the university’s departments. Request queues have been established for each of the Banner’s modules which include student, financial aid, human resources/payroll, finance, advancement and Luminis. Primarily, data stewards, data managers or assigned designates have the authority to make a service request utilizing the RT application. The Director and Manager of ESI see all such requests. In addition, senior project specialists within ESI; see all requests that come under their purview. Correspondence applicable to each request is also handled through the RT system. In this way, all relevant information regarding requests for services is managed in a central location.
Requests generally fall into three categories: enhancements to existing purchased systems, new stand-alone subsystems, and interfaces between disparate systems. For the first category, an attempt is made to minimize the impact that the enhancement has on the software package. If the implemented enhancement is beneficial, it may be forwarded to the vendor for possible inclusion with their baseline code. For the latter two categories of requests, an application will ultimately be developed and deployed utilizing the aforementioned systems development lifecycle standards.
If a service request calls for the modification of an existing Banner program or any application maintained by ESI, the original version of the code is maintained, and a copy of it is created which will be the starting point for requested changes. These modified modules are identified by a unique name and/or presence in a unique directory on the applicable server. As applicable, ESI staff also document their changes within the code itself.
A complete copy (or copies) of the production environment is available to programmers and users for comprehensive testing. These systems reside on separate servers so as to have no impact on the production environment. Once a system modification or enhancement has demonstrated satisfactory results, it may be further tested by the initiator of the service request. As appropriate, the system modification is migrated to the production environment by authorized ESI staff members.