Given the immediacy of WebApps, it is reasonable to ask: “Do we really need to spend time managing a WebApp effort? Shouldn’t we just let a...
Given the immediacy of WebApps, it is reasonable to ask: “Do we really need to spend time managing a WebApp effort? Shouldn’t we just let a WebApp evolve naturally, with little or no explicit management?” More than a few Web developers would opt for little or no management, but that doesn’t make them right!
Web engineering is a complicated technical activity. Many people are involved, often working in parallel. The combination of technical and nontechnical tasks that must occur (on time and within budget) to produce a high-quality WebApp represents a challenge for any group of professionals. In order to avoid confusion, frustration, and failure, planning must occur, risks must be considered, a schedule must be established and tracked, and controls must be defined. These are the core activities that we have called project management.
The WebE Team
The creation of a successful Web application demands a broad array of skills. Tilley and Huang address this issue when they state: “There are so many different aspects to [Web] application software that there is a (re)emergence of the renaissance person, one who is comfortable operating in several disciplines . . .” While the authors are absolutely correct, “renaissance” people are in relatively short supply; and given the demands associated with major WebApp development projects, the diverse skill set required might be better distributed over a WebE team.
WebE teams can be organized in much the same way as the software teams . However, the players and their roles are often quite different. Among the many skills that must be distributed across WebE team members are component- based software engineering, networking, architectural and navigational design, Internet standards/languages, human interface design, graphic design, content layout, and WebApp testing. The following roles should be distributed among the members of the WebE team:
Content developer and providers. Because WebApps are inherently content driven, one WebE team member role must focus on the generation or collection of content. Recalling that content spans a broad array of data objects, content developers and providers may come from diverse (non-software) backgrounds. For example, marketing or sales staff may provide product information and graphical images, media producers may provide video and audio, graphic designers may provide layout design and aesthetic content, copywriters may provide text-based content. In addition, research staff may be required to find and format external content for placement or reference within the WebApp.
Web publisher. The diverse content generated by content developers and providers must be organized for inclusion within the WebApp. In addition, someone must act as liaison between technical staff that engineers the WebApp and nontechnical content developers and providers. This role is filled by the Web publisher, who must understand both content and WebApp technology including HTML (or its next generation extensions, such as XML), database functionality, scripts, and general Web-site navigation.
Web engineer. A Web engineer becomes involved in a wide range of activities during the development of a WebApp including requirements elicitation; analysis modeling; architectural, navigational, and interface design; WebApp implementation; and testing. The Web engineer should also have a solid understanding of component technologies, client/server architectures, HTML/XML, and database technologies as well as a working knowledge of multi-media concepts, hardware/software platforms, network security, and
Web-site support issues.
Support specialist. This role is assigned to the person (people) who has responsibility for continuing WebApp support. Because WebApps continuously evolve, the support specialist is responsible for corrections, adaptations, and enhancements to the site, including updates to content, implementation of new procedures and forms, and changes to the navigation pattern.
Administrator. Often called the Web master, this person has responsibility for the day-to-day operation of the WebApp, including
• Development and implementation of policies for the operation of the WebApp.
• Establishment of support and feedback procedures.
• Implementation of security procedures and access rights.
• Measurement and analysis of Web-site traffic.
• Coordination of change control procedures.
• Coordination with support specialists.
The administrator may also be involved in the technical activities performed by Web engineers and support specialists.
Project Management
We considered each of the activities that are collectively called project management. Process and project metrics, project planning (and estimation), risk analysis and management, scheduling and tracking, SQA and SCM were all considered in some detail. In theory, most (if not all) of the the project management activities discussed in earlier chapters apply to WebE projects. But in practice, the WebE approach to project management is considerably different.
First, a substantial percentage of WebApps are outsourced to vendors who (purportedly) specialize in the development of Web-based systems and applications. In such cases, a business (the customer) asks for a fixed price quote for WebApp development from two or more vendors, evaluates competing quotes, and then selects a vendor to do the work. But what does the contracting organization look for? How is the competence of a WebApp vendor determined? How does one know whether a price quote is reasonable? What degree of planning, scheduling, and risk assessment can be expected as an organization (and its outsourcing contractor) embarks on a major WebApp development effort?
Second, WebApp development is a relatively new application area and there is little historical data to use for estimation. To date, virtually no WebE metrics have been published in the literature. In fact, relatively little discussion has emerged on what those metrics might be. Therefore, estimation is purely qualitative—based on past experience with similar projects. But almost every WebApp wants to be innovative— offering something new and different to those that use it. Hence, experiential estimation, although useful, is open to considerable error. Therefore, how are reliable estimates derived? What degree of assurance can be given that defined schedules will be met?
Third, estimation, risk analysis, and scheduling are all predicated on a clear understanding of project scope. And yet, the “continuous evolution” characteristic suggests that WebApp scope will be fluid. How can the contracting organization and the outsourcing vendor control costs and schedule when requirements are likely to change dramatically as a project progresses? How can scope creep be controlled, and more important, should it be controlled, given the unique nature of Web-based systems and applications? At this stage in the history of project management for WebApps, the questions precipitated by the differences just noted are not easy to answer. However, a few guidelines are worth considering.
Initiating a project. Even if outsourcing is the strategy to be chosen for WebApp development, an organization must perform a number of tasks before searching for an outsourcing vendor to do the work:
1. Many of the analysis activities should be performed internally. The audience for the WebApp is identified; internal stakeholders who may have interest in the WebApp are listed; the overall goals for the WebApp are defined and reviewed; the information and services to be delivered by the WebApp are specified; competing Web sites are noted; and qualitative and quantitative “measures” of a successful WebApp are defined. This information should be documented in a product specification.
2. A rough design for the WebApp should be developed internally. Obviously, an expert Web developer will create a complete design, but time and cost can be saved if the general look and feel of the WebApp is identified for the outsourcing vendor (this can always be modified during preliminary stages of the project). The design should include an indication of the type and volume of content to be presented by the WebApp and the types of interactive processing (e.g., forms, order entry) to be performed. This information should be added to the product specification.
3. A rough project schedule, including not only final delivery dates but also milestone dates, should be developed. Milestones should be attached to deliverable versions of the WebApp as it evolves.
4. The degree of oversight and interaction by the contractor with the vendor should be identified. This should include the naming of a vendor liaison and the identification of the liaison’s responsibilities and authority, the definition of quality review points as development proceeds, and the vendor’s responsibilities with respect to interorganizational communication.
All of the information developed during these steps should be organized into a request for quote that is transmitted to candidate vendors.
Selection of candidate outsourcing vendors. In recent years, thousands of “Web design” companies have emerged to help businesses establish a Web presence or engage in e-commerce. Many have become adept at the WebE process, but many others are little more than hackers. In order to select candidate Web developers, the contractor must perform due diligence: (1) interview past clients to determine the Web vendor’s professionalism, ability to meet schedule and cost commitments, and ability to communicate effectively; (2) determine the name of the vendor’s chief Web engineer(s) for successful past projects (and, later, be certain that this person is contractually obligated to be involved in your project); and (3) carefully examine samples of the vendor’s work that are similar in look and feel (and business area) to the WebApp that is to be contracted. Even before a request for quote is offered, a faceto- face meeting may provide substantial insight into the “fit” between contractor and vendor.
Assessing the validity of price quotes and the reliability of estimates. Because relatively little historical data exist and the scope of WebApps is notoriously fluid, estimation is inherently risky. For this reason, some vendors will embed substantial safety margins into the cost quoted for a project. This is both understandable and appropriate. The question is not “Have we gotten the best bang for our buck?” Rather, the questions should be
• Does the quoted cost of the WebApp provide a direct or indirect return on investment that justifies the project?
• Does the vendor that has provided the quote exhibit the professionalism and experience we require?
If the answers to these questions are, “Yes,” the price quote is fair.
The degree of project management you can expect or perform. The formality associated with project management tasks (performed by both the vendor and the contractor) is directly proportional to the size, cost, and complexity of the WebApp. For large, complex projects, a detailed project schedule that defines work tasks, SQA checkpoints, engineering work products, customer review points, and major milestones should be developed. The vendor and contractor should assess risk jointly and develop plans for mitigating, monitoring, and managing those risks that are deemed important. Mechanisms for quality assurance and change control should be explicitly defined in writing. Methods for effective communication between the contractor and the vendor should be established.
Assessing the development schedule. Because WebApp development schedules span a relatively short period of time (often less than one or two months), the development schedule should have a high degree of granularity. That is, work tasks and minor milestones should be scheduled on a daily timeline. This fine granularity allows both the contractor and the vendor to recognize schedule slippage before it threatens the final completion date.
Managing scope. Because it is highly likely that scope will change as a WebApp project moves forward, the WebE process model should be incremental . This allows the development team to “freeze” the scope for one increment so that an operational WebApp release can be created. The next increment may address scope changes suggested by a review of the preceding increment, but once the second increment commences, scope is again frozen temporarily. This approach enables the WebApp team to work without having to accommodate a continual stream of changes but still recognizes the continuous evolution characteristic of most WebApps.
These guidelines are not intended to be a foolproof cookbook for the production of low-cost, on-time WebApps. However, they will help both the contractor and the vendor initiate work smoothly with a minimum of misunderstandings.
SCM Issues for WebE
Over the past decade, WebApps have evolved from informal devices for information dissemination to sophisticated sites for e-commerce. As WebApps become increasingly important to business survival and growth, the need for configuration control grows. Why? Because, without effective controls, improper changes to a WebApp can lead to (1) unauthorized posting of new product information, (2) erroneous or poorly tested functionality that frustrates visitors to a Web site, (3) security holes that jeopardize internal company systems, and other economically unpleasant or even disastrous consequences.
The general strategies for software configuration management (SCM) are applicable, but tactics and tools must be adapted to conform to the unique nature of WebApps. Four issues should be considered when developing tactics for WebApp configuration management—content, people, scalability, and politics.
Content. A typical WebApp contains a vast array of content—text, graphics, applets, scripts, audio and video files, forms, active page elements, tables, streaming data, and many others. The challenge is to organize this sea of content into a rational set of configuration objects and then establish appropriate configuration control mechanisms for these objects. One approach is to model the WebApp content using conventional data modeling techniques , attaching a set of specialized properties to each object. The static or dynamic nature of each object and its projected longevity (e.g., temporary, fixed existence, or permanent object) are examples of properties that are required to establish an effective SCM approach. For example, if a content item is changed hourly, it has temporary longevity. The control mechanisms for this item would be different (less formal) than those applied for a forms component that is a permanent object.
People. Because a significant percentage of WebApp development continues to be conducted in an ad hoc manner, any person involved in the WebApp can (and often does) create content. Many content creators have no software engineering background and are completely unaware of the need for configuration management. The application grows and changes in an uncontrolled fashion.
Scalability. The techniques and controls applied to small WebApps do not scale upward well. It is not uncommon for a simple WebApp to grow significantly as interconnections with existing information systems, databases, data warehouses, and portal gateways are implemented. As size and complexity grows, small changes can have far-reaching and unintended effects that can be problematic. Therefore, the rigor of configuration control mechanisms should be directly proportional to application scale.
Politics. Who “owns” a WebApp? This question is argued in companies large and small, and its answer has a significant impact on the management and control activities associated with WebE. In some instances Web developers are housed outside the IT organization, creating potential communication difficulties. Dart suggests the following questions to help understand the politics associated with WebE: Who assumes responsibility for the accuracy of the information on the Web site? Who ensures that quality control processes have been followed before information is published to the site? Who is responsible for making changes? Who assumes the cost of change? The answers to these questions help determine the people within an organization who must adopt a configuration management process for WebApps.
Configuration management for WebE is in its infancy. A conventional SCM process may be too cumbersome. The vast majority of SCM tools lack the features that allow them to be adapted easily to WebE. Among the issues that remain to be addressed are
• How can we create a configuration management process that is nimble enough to accommodate the immediacy and continuous evolution of WebApps?
• How can we best introduce configuration management concepts and tools to developers who are completely unfamiliar with the technology?
• How can we provide support for distributed WebApp development teams?
• How can we provide control in a quasi-publishing environment where content changes on a nearly continuous basis?
• How can we attain the granularity required to control a large array of configuration objects?
• How can we incorporate configuration management functionality into existing WebE tools?
• How can we manage changes to objects that contain links to other objects?
• How can we best introduce configuration management concepts and tools to developers who are completely unfamiliar with the technology?
• How can we provide support for distributed WebApp development teams?
• How can we provide control in a quasi-publishing environment where content changes on a nearly continuous basis?
• How can we attain the granularity required to control a large array of configuration objects?
• How can we incorporate configuration management functionality into existing WebE tools?
• How can we manage changes to objects that contain links to other objects?
These and many other issues must be addressed before effective configuration management is available for WebE.
