Web Development/PTM Training

The PTM_Training project was initiated by a work-order from professor Mdj of the College of Education at The University of Montana (hereinafter "client"), to be developed by the University Central Web Services team (hereinafter "agency"), headed by RobertB.^[1]

Project initiation

The development team consisted of:

• SteveM (application developer);
• AndrewL (application developer);
• RonaldS (system administrator for production servers);
• PattyZ (graphic designer); and
• StudentTeam (three to five undergraduate students under the supervision of SteveM and RobertB, to assist as needed on the project).

The work order specified that the project was to consist of a web-based "professional training interface" to be used by the College of Education (and potentially other institutions) to coordinate and develop opportunities for professional development among teachers.

All work on the project was conducted on the University campus facilities, using the development and production servers owned and maintained by the agency. The client agreed to pay agency for development and maintenance fees and the work was conducted according to a written memorandum of understanding (hereinafter "MOU") between the parties.

Project phases

The project phases (established and agreed upon in advance by RobertB, SteveM, and the client) consisted of the following:

• Definition stage
• Design stage
• Development stage
• Deployment stage
• Maintenance stage

Definition stage

Challenges

• Neither the work order nor the MOU contained a detailed feature set specification or existing example application to use as a reference.
• The client had some fairly novel ideas which would preclude a simple reuse of preexisting code assets.
• The client intended to use the output of the project for a presentation to other colleges and state agencies. This would put pressure on the project output to be "impressive" as well as "functional".
• The timing of the project initiation relative to the academic calendar essentially guaranteed that there would be staff turnover among the student workers.
• Some members of the StudentTeam had little or no prior experience in the areas where they would be helping out.

Advantages

• The agency had a fairly substantial mix of production assets and a reasonably-skilled staff. This meant that there was some flexibility in the choice of development tools and operating systems for the application developers.
• The novelty and profile of some aspects of the project meant that the development team was given some leeway by RobertB in establishing priorities and requesting additional resources if urgently needed. RobertB also took care to establish reasonable expectations with the client, thus the client allowed for some flexibility on the project deliverables as well.

Responses

• Because of the relative high profile of the project, it had to proceed despite the lack of a thoroughly defined project specification. The "definition" phase would have to be revisited from time to time. Because of this SteveM opted to proceed using an "incremental prototyping" strategy for the project.
• The technologies chosen by SteveM were selected primarily for maximum familiarity among available staff, ease of use, ease of prototyping and ease of migration to "production" infrastructure once the definition and design had solidified.

These included:

• Microsoft Access (design-stage database to be migrated to MSFT SQL server for production-stage);
• Allaire (now Macromedia) Cold Fusion Web application server;

Beginning of feature set specification

SteveM and AndrewL proceeded to work with the client to get precise definitions for required features.

After some iterative consultation with the client, it was agreed the following would be needed:

• A web application compatible with the latest release of the top two browsers in use for the latest version of Microsoft Windows;
• user accounts capable of logging in through the web;
• anonymous access through the web for limited features;
• administrative accounts capable of modifying aspects of the web app and managing user accounts, all through the web;
• a "skinnable" graphical application interface that could also be modified and managed by admin accounts;
• support for user activity audits, record-keeping, statistics and routine reporting;

SteveM concluded that the application would essentially consist of a mix of an online: 1) product catalog; 2) event management system; 3) course management system (with support for credits and "grading"); 4) role-based authentication system; and 5) discussion forum.

At the time of project initiation, there were no existing products or resources available that would meet the client expectations, thus justifying in-house development over off-the-shelf purchase.

Design stage

SteveM and AndrewL began design on a database schema. SteveM began on the skeleton framework for the web application. To further streamline development and increase chances of successful delivery, SteveM opted to code the using the "FuseBox" application framework for ColdFusion.

Halfway through the initial design stages. AndrewL was pulled into another project, thus significantly reducing his availability for PTM_Training. This required SteveM to assume complete responsibility for the design, and also required a lot more contemporaneous technical documentation, so that AndrewL could be kept up to speed on the system for times when he was available to help.

Development stage

SteveM worked primarily with the StudentTeam for the initial phases of development. At the end of the semester, the StudentTeam was significantly reduced.

Challenges

• The available student developers had little or no computer programming experience.

Responses

• Routine code review sessions were established by SteveM to keep track on the progress of the student developers. These code reviews included an opportunity for the students to re-allocate time and self-select, to the extent feasible, for tasks that more closely matched their abilities and preferences.
• Routine unit testing sessions were conducted on all code modules to ensure that there would be no data integrity problems. This was necessary because "live" use of the project had begun prematurely, and the database contained data that people actually cared about, the loss of which would not have been acceptable. Although this is against best practices. This was anticipated early on because of the nature and scope of the project as established in the definition phase.

Deployment stage

Deployment for the project consisted of a migration of the code-base to the production web server machine, and a transfer of the database contents and schema to the MSFT SQL Server host. The deployment was not difficult, however there were some "gotchas" related to name resolution and resource allocation differences between the development machines and the production servers. These were quickly tracked down and the code was re-factored to compensate.

Maintenance stage

Maintenance proved an ongoing element of the entire system development, but was, ironically enough, not a significant problem after the first deliverables on the project were deployed for use and made available to the client. Eventually, the client had a relatively fruitful demonstration of the project, and the code and resources were later bought by an outside company. SteveM and the client were the named authors of the system and received royalties for the purchased code-base. All further maintenance and extension of the code-base was managed by the outside company after an initial phase of consultation and review by SteveM, so they could be brought up to familiarity with the essential elements of the system.

Notes