The general process of designing and developing a Web-based application is not significantly different from that for any software product. Before the project commences, it is important to assemble a good team that will be able to work well together throughout the project life cycle. For a Web application, this cycle consists of prototype, design, implementation and finally deployment. After describing the necessary individuals for a strong application team, this document provides an overview of the project development cycle before focusing on the design phase in this chapter, and development in the next.
Like any professional development effort, many skills are required to see a Web project through from concept to completion. Before leaping into coding, define the team members and the roles they will play. What follows is a list of typical roles (ordered alphabetically, not by importance); keep in mind that for large projects you may have several people allotted to each role, while for small projects one person may fulfill several roles.
The Developer is responsible for producing the code and logic behind the product. In the context of this guide, this may include Server Components, client- and server-side scripting, and HTML. There may be more than one type of developer on a project, perhaps one to create the HTML and another to add scripting. The distinction between "HTML experts" who create the HTML templates and "Programmers" who write code is becoming less distinct as the tools to create these elements improve and become easier to use.
The Database Administrator designs the schema, implements stored procedures, and helps the developers work with the database. As the database grows, the Database Administrator monitors the performance of the database, building (or rebuilding) indexes and performing checkpoints.
The Graphic Designer determines the look and feel, constructs the layout, and generates backgrounds, control (for example, button) artwork. Often the Graphic Designer will have considerable input into the user interface and will have to work closely with the User Interface Designer.
While not typically viewed as part of the development process, the Production role cannot be ignored. The purpose of this role is to integrate and maintain content, ensuring that, among other things, palettes and formatting are consistent. Content can come in many forms: graphics, sounds, videos, and even database content. Because of the latter, the Production role will often have to work closely with the Database Administrator to populate the database.
In the early phase of development, the Quality Assurance role makes sure that product development is progressing according to the requirements specification. Once the product reaches testable milestones, Quality Assurance performs product builds independent from the developers and reports bugs and other problems to the developers. This is an ongoing process, not something that occurs after development is "complete."
The User Interface Designer works closely with the User to build a product that is easy to understand and simple to operate. Like quality, this cannot be "added on" to a completed project and is therefore an integral part of the development process.
Every team needs a leader. Often the Team Lead role is the least glamorous of the lot, and involves maintaining the schedule, dealing with customer requests, enforcing the use of source code control and other software programming practices. Most importantly, the Team Lead makes sure that other team members have what they need to get their jobs done.
Depending on the kind of project – consulting, self-funded product work, etc. – the user role may be filled by internal team members or paying customers. The User's primary responsibility is to make sure that the rest of the team produces a product that meets the needs of the user.
Through the course of the application development cycle, different roles will be more prominent during each development phase. But it is important to have the entire team assembled and working together from the beginning of the project to ensure that the final product represents a cohesive and unified effort.
The design of a dynamic Web application proceeds along three closely related paths. Working from the prototype, the user interface should be refined to approximate its anticipated final state. This includes determining the navigational flow (storyboard) between the HTML pages comprising the site, specifying any required input and output mechanisms such as buttons or forms, constructing the page layout, and designing final artwork. Database design should commence during this phase as well for applications that are not interfacing with legacy data. This includes defining tables and indexes and designing stored procedures, all with an eye to optimal data throughput for the application. Bridging the gap between the HTML pages and the database is the design of the server-side script code, which specifies where and how database interaction should occur within the documents.
Throughout the design process, the user advocate should still be involved to verify that the design does not stray from the principles established in the prototype. This is also a good time to involve the quality assurance team in designing test plans.
The development cycle of a Web-based application is not significantly different from that of a client/server application. For ease of description, the development process is usually conceptualized in discrete phases, and this document follows that practice. Reality is not so simple, however. It is usually not possible, and frequently not desirable, to proceed in a linear fashion from prototype to design, and from design to implementation. The prototype may have to be revisited as the design process uncovers weaknesses; a portion of a design may need reworking when an idea is found to be technically unfeasible to implement. An inflexible commitment to marching ahead in the face of design flaws, finding ad hoc coding fixes instead of addressing the root problem, will almost certainly lead to an inferior end result.
Although creation of the prototype typically proceeds in a more ad hoc fashion than design or implementation, at least two teams should be assigned to this process: one that does the user interface design and actually builds the prototype, and one that acts as the end-user advocate. The latter team prevents the former from developing an application that revolves around implementation details like the database schema and focuses on ensuring that the application meets the end-user's needs.
Prototyping can be a difficult task, since there will be the temptation to focus on extraneous side issues, these primarily being:
Implementation activity closely parallels design activity. Using the prototype as a base, the HTML pages should be edited to incorporate final artwork and any user interface changes specified during the design phase. The database should be created if necessary, and stored procedures implemented. Server-side script code should be written and integrated into the HTML pages. Testing may begin as feasible.
The culmination of the application development cycle is its deployment in a production environment and release to the public. This is a fundamentally different activity from the other phases of the process.