• Skip to content
• Skip to main navigation
• Skip to global navigation

Information Technology

Application Development Guidelines

Specifications for bringing Developer Projects into the UWSP Production Environment (such as CIS 480 Projects and others done by non-AIS, non-I.T. Staff)

Production Environment Defined

Production Environment refers to applications to be used by some element of the UWSP Community (dept. unit, group, etc.), which are intended to run on and to be backed up on I.T. (and in some cases, AIS) Supported Hardware.  Specifically, this refers to 2 machines: APPSRV1 and SQLSRV1.  APPSRV1 is intended for web-related support and SQLSRV1 is intended for database support.  This does not refer to the simple creation of web pages to display department or unit content, but to more elaborate applications intended to support office management, resource management, decision support, registration and record-keeping – in general, applications which go beyond the simple display of content, or that involves the extended use of scripting/programming, and that are done by non-professional programmers.

Informing Clients of limitations in I.T./A.I.S. Support

Developer teams are responsible for informing clients that the individuals involved in developing a project are solely responsible for its support, and that there is no intent on the part of the CIS Department, Administrative Information Systems, or Information Technology to be involved in the product’s functional support once the development team is no longer available.

The Developer team is responsible for informing clients that I.T. will provide limited resource support.  If the application is proven to be stable and reliable, I.T.’s support will include providing server space, electricity, an emergency power source, air conditioning, and backup.  Doing so does not imply that I.T. will provide application repairs or changes.

Developer teams are responsible for informing clients that application-failure leading to server/network difficulties – such as consistently crashing the host machine, some programming flaw, consuming an inordinate amount of the internet bandwidth, machine memory, or CPU cycles - which result in problems for others and/or their applications – will result in I.T. providing adequate notice prior to terminating the offending application’s availability.  The department or unit using the application is responsible for providing resources to repair the application in such a way as to eliminate any problems it had been causing.

Databases

All Projects requiring the use of a database will use the version of SQLServer supported by Information Technology at the time of the project’s completion.  Currently, the campus uses SQLServer 2000.  However, thought should be given to potential issues that may result from the campus moving to future versions of SQLServer.

Reasons for using SQLServer include

SQLServer is far more robust than Access Access can be configured as the interface for working with SQLServer for users with limited skills SQLServer doesn’t need additional drivers to function in our environment and there are few if any economic costs associated with its use.

Please note that Oracle can be used instead of SQLServer for those projects directly related to AIS, and sanctioned by AIS

Also, this does not mean that every application using a database requires the use of SQLServer and that Access should never be used.  This stipulation to use SQLServer is only related to the kind of complex applications described in the section above on the Production Environment.  The point is, if the application involves accessing a database that will hold thousands of records, or that will involve many users accessing the database at one time, or where security and stability are significant issues, SQLServer is a better choice.

Since stored procedures provide a potential for hacking into a system, all stored procedures should be written to eliminate these potentials.  A literature review on the topic of stored procedures and security concerns should provide useful information insofar as this topic is concerned.

To minimize the number of ODBC connections that need to be managed and maintained, all connections should be done via connection strings and requests for ODBC connections will be handled on a case-by-case basis.

Each semester in which a course for student developers is offered, the instructor or a designee will gather information on the number of databases required to accommodate projects intended for the production environment.  Required information will include individuals authorized to access the data.  I.T. will create/provide one user account per database for use in active server page connection strings (used for accessing the db).  For developers engaged in a project not related to a course, the person for whom the project is being developed will make this request.

Operating Systems

All projects designed for broad campus audiences will function on both the Mac and PC Platforms.  Linux, Unix, or operating systems other than Apple and Windows are not supported.

Web Server for ASP’s

All projects will use the version of IIS currently supported by the campus.  For now, that means IIS 5 - FrontPage Extensions will not be installed on the production machine dedicated to active server pages.

Web Server for HTML-related Content

If more appropriate, content pages based in HTML can be stored on the campus web server, in the web site associated with the developing department.  This includes allowances for client-side scripting and dynamic content.

Browser Checks

All projects designed for broad campus audiences should function in current versions of Netscape and Internet Explorer, however, they must function adequately in the current and previous versions of Internet Explorer (back to 4.01).

ADA Compliance

Here is a “snippet” of the information appearing at http://www.uwsp.edu/it/policies/adapolicy.htm:

In response to the need to ensure that University of Wisconsin-Stevens Point Web pages are accessible to persons with disabilities navigating at our web site, we will make every attempt to provide reasonable accommodations for qualified individuals with disabilities. The features that provide power and elegance for some users will present potential barriers for users with sensory impairments. For example, the indiscriminate use of graphic images and video restrict access for users with visual impairments, and the use of audio and non-captioned video may restrict access for users with hearing impairments, the use of frames can negate the usefulness of “screen readers.”

Essential Information: In order not to create an undue burden on UWSP Web authors, the University of Wisconsin-Stevens Point requires that the "essential information" in official (not UWSP personal or class-generated pages) campus Web pages be in text format, so that the material can be read intelligently by screen readers. Essential information may include, but not be limited to:

         Contact, address information (name, phone, address, e-mail, etc.)

         Date and Calendar information (class syllabus, calendar of events, due dates, etc.)

         Admissions, degree or course requirements

         Grading policies

         Navigational elements

However, it is understood that much content will be offered only in multimedia formats, such as simulations, or graphics and photos, or sound files, where it is not reasonable or possible to provide a text equivalent. In such cases, each multimedia element will have an "Alt" tag with a brief description of that element.

Securing Sites - securing passwords

For those sites set up for restricted use, authors must invoke SSL by linking to secured sites using the “https” method instead of the “http” method.  This ensures that SSL is invoked prior to the user being challenged for their logon and password.  For more information, see http://www.uwsp.edu/it/i3ru/restrict/

Development to Production

The development and production environments will be set up so as to mimic each other, but different rules will apply in each environment.

The development environment - supplied by the department/unit doing the development - will likely allow for things “blowing up” and likely allow those developing to learn from their mistakes.  The production environment will be highly controlled in ways that promote efficient use of resources, reduce potentials for downtime, and promote a stable, predictable, secure environment.  In general, production environments are more conservatively constructed than development environments.

To this end, assume that the production environment will NOT allow for use of “beta” products, recently released or soon to be released products, non-mainstream products, or anything that would jeopardize those values listed in the previous paragraph.  It would not be wise to develop an application that depends on an installation of “extra” software in order for the application to function.  An example of “extra software” that some non-AIS, non-I.T developers have used, and that will not be supported in the production environment is Crystal Reports.

I.T. will basically support software items that are available to universities as a result of state site licenses with vendors.  Some examples include contracts with Microsoft, Adobe and Macromedia.

The production server will seldom if ever be a home for new releases of software.  It has been our experience that it is “wise” to wait until the first service/hot packs have been issued before installing a piece of software on production machines.  Although there may be value in installing the “latest and greatest” on development machines for learning purposes, doing so may cause problems because the “latest and greatest” will not be available on production machines until the product has developed a bit of a history.

Like most corporations, UWSP I.T. will “upgrade” when it appears that there is a significant enough benefit to the institution to warrant the amount of effort expended in carrying out the upgrade process.

While Administrative Permissions may be granted in certain instances on the Development Servers, only I.T. and/or A.I.S. staff members will have Administrative Permissions on production servers.

When a project has been completed, and the client and the instructor have both “signed off” on it, I.T. and/or A.I.S Staff will assist in moving the application from the Development to the Production Environment.

Training for Application Users/Documentation

Developer teams will be responsible for developing training sessions and materials so that the parties for which an application is being developed can maintain those items that the application needs in order to function properly.  I.T. would suggest that the department for which the application has been done have these items in hand before signing off on the Development Team’s work.

In addition, all documentation must be available at the site where the application exists.  One way of doing this would be to set up a folder called “documentation” that holds the documentation created for the project, and provide the department or unit with appropriate permissions for making use of that documentation.

Lastly, we would like all student/non-AIS, non-IT developers to provide department or unit heads with a copy of this document, prior to starting on the project.