John McCleary, University of California, San Diego

This presentation discusses the aspects and benefits of rapidly developing and implementing web-based services with limited resources, and our success with tools that support collaborative development. You will gain an understanding of the benefits UCSD experienced with providing project ownership to the client, sharing developmental tasks, using tools that support collaborative efforts, minimizing costs, and leveraging resources. Our developmental goals are to deliver complex Web services quickly. Collaboration and tool building play primary roles in this effort. We hope that you can relate this material to your own service goals and potentially benefit from similar solutions. We will focus on two aspects of product development: the collaborative process and the use of tools that support collaborative development.

From the larger perspective, we are participating in a collaborative process by sharing our approaches, methodologies, and ideas at this conference. At a campus level, when we ask for support, opinions, ideas, and feedback, we collaborate. Technical designers and developers have historically been expected to fully understand the functional issues of a given project, design and develop it innovatively, and deliver it ahead of time with all the unspoken details accounted for. They have typically been guilty of delivering what was asked for but not what was wanted. Why? Because they didn't, and couldn't, understand the real tasks and nuances of these tasks, and their customers didn't know what or how to ask for it. The era of the classic analyst is almost gone.

So how are IT professionals meeting goals and satisfying real functional needs at a time when the technology and business cycles change more quickly than project estimates can accommodate? How can they deliver solutions to problems that change before the solution can be created?

Collaborative development can manage customer expectations and meet development goals. It enlists the customer as a principal part of the development team. They not only assist in the product design, but they actually do product design. The design team also enlists input from the actual end-users of the products. Typically designers are too close to the technology, and too close to the product or service, so this type of design support structure is necessary.

It works because of ownership. The functional support office OWNS the product being developed and actually contributes to the product. They become the functional analysts and the functional developer. They will help to make sure that it is acceptable. The end user provides the most valuable interface design review because they know nothing of the technology, but they do know what they want to do and what works and what doesn't. The technical staff concentrates on what they do best: deploying technology to solve problems.

How do you maximize this style of Rapid Application Development? You develop and utilize tools that foster collaborative work styles. You develop products that can be modified by the functional support staff instead of programmers. You develop environments that allow simultaneous development of the user interface and the process logic.

The resultant processes are often reusable for other projects, and minimize the need for programmers to become involved for content and presentation.

At the University of California, San Diego, we used a collaborative approach in the development and deployment of new Web-based services. We developed a Web application delivery platform that provides a content and delivery framework for these services.

While application servers and development products can be licensed from the commercial market, most are proprietary, have their own development language, and can quickly become cost burdens for campuses with budgetary constraints. UCSD chose to adapt and develop tools in-house, use languages in the public domain, and use support environments that do not limit use to particular equipment or vendors.

The Web Application Delivery platform, called "GenericLink" was developed by the Strategic Projects team and was written in Perl and SybPerl running under Unix. GenericLink manages the general look and feel of the product web site, access security, state maintenance, and audit files. It provides a common development environment and encourages consistent development practices by the programming staff. GenericLink makes the "cloning" of services relatively easy. Clients are encouraged to participate in the development process by taking ownership of the site content while programmers concentrate on the back-end services.

This platform has spawned a group of services on campus known as the "link" family. StudentLink provides access to student and course-related information for use by Students, Faculty, and Staff. FinancialLink provides access to financial reporting, access to the campus ledger, support for departmental accounting and budgeting, and access to other business and financial services such as Purchasing. EmployeeLink provides access to Human Resource services such as history data, time entry, access to employee information by departments, merit entry, as well as various reports that were previously printed and distributed. TravelLink will provide support to Faculty and Staff that must travel by providing access to travel bureaus, airline reservations, and central travel accounting. DataLink will provide access to the campus data warehouse via standardized reports as well as customizable SQL queries.

To provide access to these services, the "Link" platform calls other specified custom programs which access campus databases (Sybase/SQL), the IBM Enterprise server, or other Web content.

An example of a collaborative model using GenericLink

StudentLink was the initial development project, and was a collaborative effort with the Registrar's Office. Student's were also involved closely with design and testing, and also participated directly in the programming of the product.

The "Link" program manages the general look and feel, manages security and state, maintains audit files, provides a common development environment, and encourages consistent development practices. The functional specialist concentrates on the content to be presented (hopefully addressing the service-based needs of the student), and the programmers concentrate on the back-end programming to properly access and display data based on the user's actions.

This brings the 3 areas together: the end user of the services, the service provider, and the technical developer. This arrangement allows for development of look-and-feel and content with the end-user. The programmers simultaneously develop the back-end processes to support the user needs. The product typically meets or exceeds expectations because everyone has an understanding of the issues, and participated in the project schedule.

Cara Fladd, University of California, San Diego

As different offices on campus began to investigate the possibilities available with the Internet, UCSD's Registrar's Office and Administrative Computing formed the StudentLink Project Team. With members from both offices, we were able to supply the campus with a new medium for information in September 1996. Since then we have released four versions of StudentLink, each one building on the older ones and providing more information and applications.

Students are able to view their entire academic history, addresses on record, holds, billing statements, classes and wait lists, and general personal information. In addition to viewing data about themselves, students also have the ability to update their addresses, emergency contacts, publication restrictions, and enroll via StudentLink. Authorized faculty and staff can view student information, view and download class rosters and majors lists, and send e-mail to class rosters and majors.

StudentLink has been well received by the campus. Students, faculty, and staff are sending comments and suggestions for enhancements. The StudentLink Project Team is continuing to work together to provide these serves quickly.

When we decide to make more information available on StudentLink, the first step is to determine from where the information should be obtained. If the information is general static data, a document is created and maintained on the Registrar's server. For example, registration fees are updated quarterly; the documents are simple html files and do not require any programming. For dynamic information, such as class enrollment, addresses, and holds, the information will be provided via extracts from the mainframe or data warehouse. Requests for the new applications are then made to the StudentLink programmers.

From the requests, the StudentLink programmers create the new applications. New features are modeled after current applications when applicable. Once the programmers have made substantial progress with the new features, I am given access for testing. I am responsible for verifying that all information being displayed is accurate, complete, and displayed in a logical manner. At this time, I work with the programmers to add, delete, and modify the development version in order to obtain a complete product. Others in the Registrar's Office are also asked to test new features, based on their expertise of the information being displayed.

One of the StudentLink administrative features is a statistics log. This page allows me to monitor the usage of the features. As new applications are added to StudentLink, the statistics log is modified to incorporate the monitoring of the new features. I am also able to track the access to the applications, get information about the users, and see peak access times.

Both sides have responsibilities when releasing new features and upgrading versions. We work together to verify that the new features work correctly once they are released into production and to also verify that all parts of the older versions continue to function appropriately.

I am able to make changes to StudentLink, by adding, deleting, and changing information that may not be associated with a particular application. I have access to modify the developmental version to test the look and feel, prior to making changes in production. I have the ability to turn applications on and off, as well as the ability to add temporary text required during certain times of the quarter.

I also monitor the StudentLink Administrator e-mail address. The e-mail address is located at the bottom of every StudentLink page and with this medium the users are able to tell us what the like, what they don't like, and what they would like to see provided. We determine whether the suggestions are appropriate for this medium and whether we can provide the information. The team is always evaluating the status of all requests and working to provide more services to the campus via StudentLink.

We have been able to meet the demands of the campus because we work together and everyone has a part in the process.

Presentation site:
www-act.ucsd.edu/demos/cause97

John McCleary
Administrative Computing and Telecommunications
University of California, San Diego
[email protected]
www-act.ucsd.edu

Cara Fladd
Office of the Registrar
University of California, San Diego
[email protected]
www-reg.ucsd.edu