The scope of the business process is determined by the complexity and uniqueness of the project as well as the risk and cost associated with incorrect assumptions or misunderstandings. For example, custom application development projects need significant documentation to ensure we understand the requirements, the users and how they will interact with the system, and the workflow involved prior to starting the actual programming. However, web design projects need little documentation but rely primarily on the development of multiple prototypes. Design is, by its very nature, a subjective and visual process where written descriptions do not enhance the process.
The business process for various types of projects is shown below, starting with the most simple and advancing in complexity.
Website Design
An assessment meeting is held for every project request between the Web Development Team's Project Manager and the site managers. Ideally, the assessment meeting should define:
- Whether this is a redesign of an existing site or a new site
- If a redesign, is a new or revised site structure required prior to design
- The purpose and intended audience
- The size and complexity
- Any other special requirements that need to be considered
If a site structure is required, the first three levels will need to be developed before the design process can begin. Site requirements will be detailed in an email message from the Project Manager to the site owners. Once these requirements and a rough cost have been agreed to, design prototypes of the homepage and at least one lower-level page will be developed and made available on our development server for review and feedback. This is a cyclical process where the design is refined based on feedback and revisions until a final design is accepted.
Once the prototype has been finalized, the actual site will be built on our development server, allowing review and feedback at all points along the way. The site owners decide when the site is ready to be launched. We will work with the technical staff who will be hosting the site to migrate it to the production environment. This could involve integration with the NIH search engine and requests for a specific URL.
Event Registration Systems
At the assessment meeting, examples of previous registration systems are presented as possible models. The site owners select fields and options from a variety of different forms, and a prototype of the form is created and then refined using the same cyclical process as described above.
The back-end database is also modeled after a previous registration system that most closely fits the needs of the new system. Changes are made to create the views required for the management of attendee data.
FileMaker Pro Development
A project assessment meeting is held to capture the high-level scope of the system being requested, including sample outputs if available. A Project Definition Report (PDR) is developed by the Project Manager detailing the objectives, system requirements, and users and their roles, as well as the level of effort and estimated cost.
Once the PDR is approved, generally by an email message from the project sponsor, the FileMaker Pro developer works with the end users to understand the business needs and develop a prototype that builds over time into the production system based on review and revision from the end users.
Content Management Systems
A kick-off meeting is held so the CMS development team can meet the content owners of the site and describe the development process. The Systems Analyst begins the discovery stage by walking thru the current site and/or proposed site structure and developing the Information Architecture (IA), describing the relationship of the sections of the site and the type of content to appear on various pages (forms for input, summary of content from other pages, links to external sources, etc.). The Analyst will interview content owners to understand specific business requirements and specialized content. He will deliver a Project Definition Document (PDD) along with the IA that will spell out exactly what functionality will be included as part of the fixed-fee project. It will also identify areas of additional development outside of the standard scope.
If a site redesign is requested, the designer will be involved using the process as described in the Web Design section above. The new site design will need to be finalized before CMS development can begin.
All documentation, HTML templates, and custom graphics will be given to the CMS developer who then builds the site in our development environment. Status meetings are held with the site owners to review progress and clarify requirements throughout the development process. The CMS developer will build the site framework which will include enough of the site content to demonstrate and/or test how certain custom features are implemented.
Once the skeleton of the site is done, it is migrated to the testing/training server. A training class is held for all content authors who will be responsible for editing content on the new site. At that time, the site owners will develop a list of all users and the level of access they will need. The site will be migrated to the authoring environment, where those authorized users will be able to add and edit content, either from the previous static site or from new sources. We have support staff available to assist you with the data migration task if required.
Once the site owners determine that the site is ready to go into production, we will work with the Hosting Services Branch (HSB), the NIH Search Engine group, and others to bring up the new site using an existing URL from an old site or a newly-created URL.
Web Application Development
The first step in a new custom web application project is identical to that of a FileMaker Pro project -- an assessment meeting is held to determine the high-level requirements of the system, and a Project Definition Report (PDR) is delivered to the system owner. Once the project has been approved, the Systems Analyst will meet with process experts as defined by the system owner to gather the documentation and details necessary to generate a System Requirements Specification (SRS) document. This document is a more detailed technical document that can include screen mock ups, field validation requirements, and specific business rules for each screen. A meeting is held with the system owners to review the document to make sure all business requirements have been addresses and understood.
The SRS is used by the user interface designer, database modeler, and the application programmers to build the initial prototype. The designer will refine the screen mock ups and deliver HTML templates to the application developer to incorporate into the system prototype. As with the previous cases, this is an iterative process where end-user feedback is incorporated into successive versions of the prototype until all requirements have been satisfied.
Once the final prototype has been built, a period of user acceptance testing should be held so that the end users can work with the new system using real-world scenarios to ensure that it performs as expected. This also helps to uncover and eliminate any bugs.
After user acceptance testing, we will work with the technical staff who will be hosting the application and/or database. This may involved integration with the NIH Single Sign-on, security certificates, or other security measures as needed.
After implementation, the system moves into maintenance mode. System owners will be given access into our change request management system so that they may request updates, enhancements, or bug fixes that are assigned and tracked to ensure all issues are addressed in a timely fashion.