University Web Services (UWS)

To request a feature, first look at the Feature Development Queue to see if the feature has already been developed or requested. If the feature is not already available or in the development queue, then submit the feature request using the Feature Request Form. Please use a descriptive title and provide a brief explanation that includes the problem the feature is intended to solve. Please include technical requirements, examples, etc. if you have them. The feature request is saved in the UWS development queue as “pending”. UWS reviews feature requests on a weekly basis and will contact you for additional information if needed.

UWS reviews new feature requests on a weekly basis. UWS will consolidate features requests if the functionality of a new feature request overlaps with an existing request. If the feature is technical possible and hasn’t already been developed, they will change the status from “1. Proposed” to “2. In Queue”. If the feature request is considered critical, UWS will notify SDAT via email with a version release recommendation and proposed release date. If it is not critical, SDAT will prioritize features on a monthly basis.

1. development.ucdenver.edu

1. Almost all development and testing is done on this development server. Prototypes can be evaluated on this server by the SDAT. During this phase, the server deployment field is set to on development: building. Although this server is a good place for testing the functionality of a given feature, it should not be considered a faithful copy of the production server.
1. Testing
1. Testing on development includes standard web development procedures such as browser testing. During this phase, the server deployment field is set to on development: QA
2. If the feature or bug has any potential to affect college or department websites, a rigorous test of all school/college/department themes will be performed.
3. Once a feature is completed and signed off on by the web production manager and the SDAT, the server deployment field is set to on development: approved for staging.
2. Communication
1. SDAT and the larger campus community can monitor the progress of the feature throughout the development phase by reviewing the specific queue item. Prototypes may also be available to look at on the development server.

2. staging.ucdenver.edu

1. Whereas the development server sees a high amount of development activity, staging serves as a near mirror copy of the production server with no development to be done. Tests performed on staging are less about feature function, and instead more about disruption of the user experience on the public facing website. Again, the impact that the feature/bug may have on websites throughout the community are evaluated. When all tests have been completed, the server deployment field is set to on staging: approved for production.
1. Communication
1. The communication phase on staging is essential. The feature is poised to be launched, and the content it contains or interacts with should be essentially the same as production. SDAT can officially review the feature or bug and provide any critical feedback before the feature launches. If it is to be delayed for any reason, it’s back to the drawing-board on development, and the process starts over.

3. www.ucdenver.edu

1. When the feature or bug fix reaches production, all major testing and revisions should havve already been completed. It is tested briefly one more time, and all essential files are checked in published. This will be done at a time when public traffic is minimal.
1. Communication
1. One more communication will be tranmitted two days prior to launch.

Once a set of issues and features have been tested on the staging server and approved for the production server, the UWS Web Developer sends the Review and Release Date Communication to the SDAT Group and UWS Support Team announcing the launch date and requesting feedback within 4 days. The UWS Web Developer also schedules a meeting with the support team that day to train them on the new features.

Once the support team is familiar with the new functionality they create a print and web based training guide for each feature, craft a feature release announcement that will be sent to the UCD website users email list and posted on the UWS website that briefly explains why the features were developed, how it benefits the users and when they will be released and schedules classroom training sessions to train users on the new features.

1. Feature Release Roadmap Report
   Once features have been approved, prioritized and added to the UWS development queue, users can view the feature release roadmap anytime on the UWS website. This roadmap is a live report of the development queue and reflects the order in which the UWS development team works on features. Features will be organized into release versions. UWS typically schedules one to two release versions ahead. Scheduling more than 2 versions ahead often proves to be inaccurate because the development queue frequently changes due to unforeseen technical issues, new feature requests and existing feature reprioritization.
2. SDAT Review and Release Date Notification
   Once a set of issues and features have been tested on the staging server and approved for the production server, the UWS Web Developer sends the Review and Release Date Communication email to SDAT announcing the launch date and requesting feedback within 4 days. SDAT will have 4 days to report issues back to the UWS web developer.
   In special circumstances the UWS web developer will send a Critical Review and Release Date email notification to SDAT asking for their feedback within 2 days if the feature or issue is considered critical and needs to be expedited. If no issues are reported, the UWS web developer will begin the process for releasing the feature on the production server.
3. Feature Release Notification
   Once a set of issues and features have been tested and released on the Production Server (www.ucdenver.edu), the UWS web developer notifies the UWS Support team. The UWS Support team releases the feature documentation and training materials on the UWS website and sends the Feature Release Notification email to all MOSS users and SDAT.