The degree of oversight and interaction by the contracting organi- zation with the vendor should be identifi ed. This should include the

P LANNING

Class 4. Major design change (e.g., a change in interface design or naviga- tion approach) that will be immediately noticeable to one or more categories

5. The degree of oversight and interaction by the contracting organi- zation with the vendor should be identifi ed. This should include the

naming of a vendor liaison and the identifi cation of the liaison’s responsi- bilities and authority, the defi nition of quality review points as development proceeds, and the vendor’s responsibilities with respect to interorganiza- tional communication.

pre23291_ch05.indd 105

pre23291_ch05.indd 105 1/2/08 3:45:44 PM1/2/08 3:45:44 PM

All the information developed during these steps should be organized into a re- quest for quote that is transmitted to candidate vendors.¹⁴

How Do We Select Candidate Outsourcing Vendors?

In recent years, thousands of Web design companies have emerged to help busi- nesses establish a Web presence and/or engage in e-commerce. Many have be- come adept at the WebE process, but many others are little more than neophytes.

In order to select candidate Web developers, you must perform due diligence. You should: (1) interview past clients to determine the Web vendor’s professionalism, ability to meet schedule and cost commitments, and ability to communicate effec- tively, (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 face-to-face meeting may provide substantial insight into the “fi t” between the contractor and vendor.

How Can We Assess the Validity of Price Quotes and the Reliability of Estimates?

Because relatively little historical data exist and the scope of WebApps is notori- ously fl uid, estimation is inherently risky. For this reason, some vendors will embed substantial safety margins into the cost quoted for a project. This is both under- standable 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 justifi es 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 worth considering.

What Level of Project Management Will Be Needed?

The formality associated with project management tasks (performed by both the vendor and the contracting organization) is directly proportional to the size, cost, and complexity of the WebApp. For large, complex projects, a detailed proj- ect schedule that defi nes work tasks, software quality assurance checkpoints,

14 If WebApp development work is to be conducted by an internal group, nothing changes! The project is initiated in basically the same manner.

pre23291_ch05.indd 106

pre23291_ch05.indd 106 1/2/08 3:45:45 PM1/2/08 3:45:45 PM

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 im- portant. Mechanisms for quality and change management should be explicitly de- fi ned. Methods for effective communication between the contractor and the vendor should be established.

How Do We Assess the Schedule and Manage Scope?

WebApp development schedules span a relatively short period of time. Therefore, the development schedule should have a fi ne granularity. That is, work tasks and minor milestones should be scheduled on a daily time line. This fi ne granularity allows both the contracting organization and the vendor to recognize schedule slippage before it threatens the fi nal completion date.

Because it is highly likely that the scope will change as a WebApp project moves forward, the WebE process model is adaptable and incremental. This allows the vendor’s 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 sec- ond increment commences, the 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.

W he re We’ ve B e e n . . . W here We’ re G oi ng

The planning activity for Web engineering begins with a consideration of the proj- ect scope and leads to an understanding of business context, informational ob- jectives, WebApp functionality, system constraints, and performance issues. This information is derived from work products produced during the communication activity.

An overall project plan provides a road map for the delivery of all WebApp in- crements, but the planning activity itself focuses on the tasks and work products to be produced for a specifi c increment. It also addresses the risk, quality, and change management mechanisms that will be applied as an increment is produced.

Planning is performed by all members of the WebE team and is coordinated by the team leader. Good WebE teams tend to jell and avoid the toxic characteristics that can create problems whenever a group of people work together.

Once planning is completed, technical work begins with the modeling activity.

In the chapters that follow, we examine many different aspects of modeling as it is applied to WebApps.

pre23291_ch05.indd 107

pre23291_ch05.indd 107 1/2/08 3:45:45 PM1/2/08 3:45:45 PM

R e fe re nc e s

[Bec99] Beck, K., Extreme Programming Explained: Embrace Change, Addison- Wesley, 1999.

[Bro95] Brooks, M., The Mythical Man-Month, Anniversary Edition, Addison- Wesley, 1995.

[Coc01] Cockburn, A., and J. Highsmith, “Agile Software Development: The People Factor,” IEEE Computer, vol. 34, no. 11, November 2001, pp. 131–133.

[Dem98] DeMarco, T., and T. Lister, Peopleware, 2nd ed., Dorset House, 1998.

[Jac98] Jackman, M., “Homeopathic Remedies for Team Toxicity,” IEEE Software, July 1998, pp. 43–45.

[Jef01] Jeffries, R., et al., Extreme Programming Installed, Addison-Wesley, 2001.

[Kid00] Kidder, T., The Soul of a New Machine, Back Bay Books (reprint edition), 2000.

[Pic01] Pickering, C., “Building an Effective E-Project Team,” E-Project Manage- ment Advisory Service, Cutter Consortium, vol. 2, no. 1, 2001, www.cutter.com/

content/project/fulltext/summaries/2001/01/index.html (accessed July 24, 2007).

[Qui01] Quibeldey-Cirkel, K., “Checklist for Web Site Quality Assurance,” Quality Week Europe, 2001.

[Ree99] Reel, J. S., “Critical Success Factors in Software Projects, IEEE Software, May, 1999, pp. 18–23.

[Ros07] Rosenberg, S., Dreaming in Code, Crown Publishers, 2007.

[Sch02] Schwaber, K., “Agile Processes and Self-Organization,” Agile Alliance, 2002, www.agilealliance.org/system/article/fi le/784/fi le.pdf (accessed July 24, 2007).

[Wei86] Weinberg, G., On Becoming a Technical Leader, Dorset House, 1986.

[Wil99] Williams, L., and R. Kessler, “All I Really Need to Know about Pair Programming I Learned in Kindergarten,” University of Utah, 1999, http://

collaboration.csc.ncsu.edu/laurie/Papers/Kindergarten.PDF (accessed July 24, 2007).

[Zah94] Zahniser, R., “Timeboxing for Top Team Performance,” Software Develop- ment, March 1994, pp. 35–38.

pre23291_ch05.indd 108

pre23291_ch05.indd 108 1/2/08 3:45:46 PM1/2/08 3:45:46 PM

109

T

he written or spoken word is a wonderful and expressive vehicle for communication, but it is not necessarily a precise way to represent the content or functions to be delivered by a WebApp. Natural language can be ambiguous, contradictory, or unclear. Consider the following requirement: “Full product information should only be available to reg- istered users.” Apart from the lack of clarity about what is meant by “full product information,” it is unclear when and how users might be recog- nized by the system as “registered,” and even what is meant by “avail- able.” Should unregistered users be able to know that the extra informa- tion exists but not be able to see it? Or should they not even be allowed to know that it exists?

Modeling helps address this problem by using a combination of text, graphical, and diagrammatic forms to depict content and function, archi- tecture and component detail, interfaces, navigation, and aesthetics in ways that are relatively easy to understand and, more important, straight- forward to review for correctness, completeness, and consistency.

In Chapter 3 we discussed modeling briefl y and stated that it is an activity that creates one or more conceptual representations of some aspect of the WebApp to be built. As shown in Figure 6.1, modeling in the WebE process fl ow involves two main actions: analysis and design.

Before we focus on these actions and consider what “conceptual repre- sentations” might be relevant to them, we’ll look at the concept of mod- eling a little more closely.