Remember the old story of the blind men and the elephant? Each felt a different part of the animal and came away with a different description. The process of building a Web site is much like that. To some people it is an exercise in programming. To others it is a marketing activity.
Still others are primarily interested in the graphics. To the corporate attorney, the Internet is a seething mass of pornography and cybercrime, loaded with risk for the corporate client.
In fact, the best way to produce a high-quality Web site is to use a small team. This chapter shows one way of putting that team together and how they should divide up the work.
Web design begins with concept. In many ways, it parallels the video design process given in Chapter 36, "The Third Dimension: VMRL" (see Fig. 38.1).
Figure 38.1 : The site development process.
The development team begins by preparing a Web treatment that describes the goal of the site and the general allocation of the pages. If the development of the site is being contracted out, the treatment can be in the form of a proposal from the development organization.
Once the treatment is approved, the team works to identify specific
material for each page. In some cases, the client may supply copy
and graphics from existing collateral materials and internal information.
In many cases at least part of the content will be developed specifically
for the site, and the development team will want to have an art
director and copywriter available.
| Note |
Most organizations that want their site professionally developed contract the work out to Web site developers and publishers. Even in those organizations which are large enough to support a full-time development team, it is in the best interests of the team to think of themselves as "contractors," having to satisfy an in-house client to get paid. (The alternate model, "employees," all too often suggests that everyone gets paid whether the work is any good or not.) In this chapter, the term "client" is used to cover customers of a contractor as well as in-house clients. |
Once the content is in place, a mock-up of each page is prepared for a storyboard. Storyboards show the layout of page elements, graphics, and a draft of the copy. By the time the storyboards are complete, most of the work of the art director and copywriter is done. The technical staff takes over to produce HTML and CGI scripts to implement the concepts in the storyboards.
The finished site is tested thoroughly. Each page is validated, and all the links exercised. Any CGI must be tested in the manner typically used for software. Once the site is completely tested, it is installed and announced.
Many firms find that putting together a team of a half-dozen or more in-house people to build a Web site is not efficient. They may want to consider contracting all or part of the job out. The good news is that with the Internet it's easier than ever to put together a virtual team so that each person complements the others.
Chapter 1, "How to Make a Good Site Look Great," introduces the idea of a Web site having goals and objectives. Recall that the goal has to do with the purpose of putting up the site in the first place. Objectives are measurable milestones that can be tied to a schedule.
The Web producer should understand the goals of the site. Web producers are not necessarily the best people to write the HTML or code the CGI. They don't have to write the copy or prepare the artwork. But they must know whether or not some element of the site will support the site's goals.
If the site is being developed internally, the producer may also be the corporate sponsor. If not, the producer and the corporate sponsor will work closely together since the sponsor provides the budget and the access. Many Web sites are created to carry out marketing objectives. Recall the principle that "Content Is King." While the marketing management group may control the team, they must recognize that the Web is a different kind of medium: Web site visitors demand far more content than is possible in a print ad or in a 60-second radio or TV spot.
In fact, many Web sites look more like a mix between public relations and technical support. They contain detailed information on the people, products, and services#Óffered. Some of this information is meant to sell the product. Other information is aimed at people who are already customers to give them a better experience as a user of the company's products.
Getting this information and getting it put up in a public place is guaranteed to trigger the corporate immune response. The Web producer and the corporate sponsor must have enough political clout in the company to pry the content loose from the empire and get it onto the site.
The Web designer is the person responsible for actually developing the site. Web designers typically report directly to the producer. All other members of the team except the quality specialist, the members of the Red Team, and the legal advisor report to the Web designer. See Figure 38.2 for an organization chart of a typical Web team.
Figure 38.2 : Typical organization of a Web team.
| Note |
By design, Red Team members are not an integral part of the development organization. They are independent reviewers who provide feedback similar to the ultimate users of the site. More information on how to set up and use a Red Team is given in Chapter 2, "Reducing Site Maintenance Costs Through Testing and Validation," as well as in the section of this chapter entitled "Red Team Testing." |
The Web Designer is ultimately responsible for the site style guide, which is developed in concert with the technical director, the art director, and the copywriter.
The art director is responsible for all visual content of the site. This responsibility not only includes graphics but also page layout, background colors or images, and any high-end products such as TIFF files, EPS, video, and VRML.
The technical director is responsible for every part of the site that touches the computer. This responsibility includes HTML coding standards (and possibly the HTML coding itself), server-side includes, CGI, and any "helper" applications such as batch files or log analyzers.
The technical director should be prepared to offer alternatives when working with the creative talent. If the copywriter has a 15-page brochure to put up, the technical director may suggest breaking it into several related pages.
The team's wordsmith is responsible for every nonvisual part of the site that doesn't touch the computer. The copywriter and the art director must work closely to develop content that enhances the site. The technical director balances the creative talents with a dose of reality-some things are best done a certain way on a computer.
In all but the largest companies, configuration management is an additional duty for one of the existing team members. This means that it is most likely to be left to slide when the schedule gets tight. It is the responsibility of the Web designer to make sure that this important duty is not neglected. One way to do this is to assign the task to a technical assistant working under the supervision of the technical director. (The use of technical assistants is discussed later in this chapter.)
The creative talent and the technical director are free to explore and experiment as much as they wish-until it is time to put the finished product together. Once the site goes into test, it should be placed under configuration control and checked into the team's version-control system. Once there, pieces of the site can be "checked out" by the person responsible for it, modified, and checked back in. The configuration management specialist helps the rest of the team document these configuration changes.
The quality assurance (QA) specialist is more than a tester. Quality assurance specialists know that quality cannot be "tested" into a product. A quality product is the result of a quality process. If the organization has written "best practices," the QA specialist helps ensure that the team is trained in those practices.
If the processes need improvement, the QA specialist is there with a process improvement proposal (PIP) to capture the recommendation for staffing by the process management team.
Whereas the QA specialist is not just a tester, there is a time and place to test. A Web site can be tested in four different ways.
A good team develops a certain level of "group think." This effect can be positive-members learn to anticipate what others will think about a given subject-but it can also be negative. Some teams call this negative effect "drinking our own bath water." The team gets so close to the project that they lose the ability to look at the work objectively.
The Red Team is formed by the Web producer. Once the site storyboards are prepared, and the copy and graphics are at least roughed out, the page mock-ups are posted on the walls of the production team's workspace and the production team goes home.
Red Team reviews are often scheduled to start on a Friday evening and run through Saturday evening to avoid disrupting the work schedule. The Web producer stays around to welcome and orient the Red Team. Then, typically, the Web producer leaves as well, and the Red Team is alone with the draft Web site.
The Red Team consists of fellow professionals and representatives of the target audience. They are not a focus group: they are colleagues who bring a fresh perspective to the work of preparing the site. The Red Team reviews the storyboard for each page. They read the copy, examine the graphics, and try to determine whether the site will meet its objectives.
The leader of a good Red Team makes a special effort to ensure that the review does not turn into a rout. The leader knows that it's easy to criticize and makes sure that each Red Team member who makes a comment is ready to work with the production team to improve the site.
If the Red Team has worked over the weekend, they come in Monday morning to brief the production team. The members of the Red Team each explain their comments. But the production team remains in control; they are free to accept, reject, or modify any Red Team comment.
After the debriefing, members of the Red Team remain on-site for as long as it takes the production team to assimilate their comments and make any changes.
Red Team testing is primarily about getting the concepts right. Once the Red Team departs, the production team finalizes any changes and generates the final copy, the HTML, and the graphics. Any CGI scripts, databases, or other files that are needed are produced by the technical director, possibly with help from staff members.
Team members are each responsible for checking their own work, a process called "unit test." For an HTML coder, unit test consists of running the pages through one or more validators. A typical combination is to test the page with KGV, with Weblint, and then with DoctorHTML.
To a programmer, unit test includes getting the program to compile and work correctly. Chapter 25 of Code Complete by Steve McConnell (Microsoft Press, 1993) contains a wealth of recommendations about unit test.
Once a page or a program passes unit test, it is checked in to the version-control system and turned over to the configuration management specialist.
When enough CGI code and HTML pages are checked in to test a function, the QA specialist checks out a read-only version of the modules associated with that function and exercises them in accordance with the unit test plan. For example, the QA specialist might fill out an HTML form that asks for a person's name and verifies that that person's name is added to a mailing list.
In addition to checking functionality, the QA specialist does stress testing. Stress testing ensures that the system works as well with bad data as it does with good data. If a field is supposed to be filled in, the tester leaves it blank. If a field is supposed to contain numbers, the tester puts in letters. If the field is set up to handle 10 characters, the tester puts in 20.
To anticipate stress testing, the programmer should do "white box" testing during unit test. Chapter 4 of Writing Solid Code by Steve Maguire (Microsoft Press, 1993) describes this process in detail. As part of white box testing, the programmer uses the debugger to step through every path in the code.
The programmer should pay particular attention to the program's interface to the outside world since that is where most defects occur. These defects are often introduced by a mismatch between an HTML form and the CGI it calls. The CGI program should state clearly any restrictions on its input and then handle them gracefully if someone does violate its input assumptions.
When the system appears to work correctly (even when presented with bad data), it is time for load testing. The QA specialist arranges to have as many users as possible log in to an alpha release of the site, possibly on a private, heavily instrumented server, and exercise the site as intensively as possible for as long as possible. This testing has two objectives:
| Note |
During software development, it is common to add trace, print, and debug statements (depending upon the language) to give the programmer visibility into the internal workings of the code. Such statements are called instrumentation and are customarily removed or disabled when the production version of the software is released. |
Load testing uncovers resource shortages. Does the program run out of memory? Does it start paging to virtual memory, eating up time? Do two users looking for the same data contend in the database? Do some kinds of queries take unusually long?
When all defects uncovered by functional testing, stress testing, and load testing have been closed, the site is ready for the transition into beta testing. During beta testing, the site is visited regularly by a group of "friendly evaluators" who report any defect or anomaly found.
During this time, the QA specialist puts together a set of regression tests (which should be automated) so that as the site is changed during maintenance, the maintainers can always ensure that the site is as solid as it was when it first came out of production.
When the number of defects reported per unit time drops low enough to suggest that the site is ready for release, all the components of the site are packaged into a "gold release," placed on the live server, and announced.
One way to keep morale and team efficiency high is to use technical assistants (TAs) to leverage the technical and creative talent. Typical instructions to the talent are, "If a task does not need your specialized training or experience, don't do it. Show a TA how to do it and get back to work." Similarly, TAs are told to be proactive-to look for work being done by other team members and see if they can learn how to take it over.
Once TAs have learned a process, their next step is to write that process up, have it approved by the team member who taught them, and put the new process description in a process file. The next time that work must be done by a TA, the TA goes to the process file, gets a copy of the process, and follows it-without taking time away from another team member. If TAs find a defect in a process description or come up with a better way, they submit a PIP and get it changed.
When the site has been released, it becomes the responsibility of the maintenance team. In some organizations, some members of the original production team become the maintenance team. Other organizations contract out the development of the site and do the maintenance in-house. Still others contract out both production and maintenance.
Every Web team should have a legal advisor. This person may or may not be the corporate attorney. If the corporate attorney is not knowledgeable about specific aspects of Internet law, then portions of this work should be contracted out.
The legal advisor should be prepared to consult on:
Here is a summary of issues that may come up during contract talks
between an outside Web developer and a prospective client. Note
that this material is not legal advice. Contact your legal advisor
to find out how these and other issues may affect your Web site.
| Tip |
Most negotiators and attorneys agree that you should work with a written agreement. They also agree that if you have to resort to that agreement, the job has gone horribly wrong. The primary purpose of a written agreement is to get each party's assumptions stated explicitly and work them into agreement-not to have a "piece of paper" to fall back upon if the job goes badly. |
Agree ahead of time what it means to be "done." A typical
provision is to start with a statement of work or requirements
document, which becomes part of the agreement. Then, when the
work is done, submit the finished product to the client and give
them a specified time period to review it.
| Note |
The Statement of Work (also called a SOW), the requirements document, and the specification are closely related documents. On many projects they may be the same piece of paper. On other projects it is useful to get started with a relatively informal Statement of Work which describes the work to be done (for example, a fifteen-page Web site for marketing widgets). Then, as the team's first task, the SOW is refined into a Requirements Document that lists and numbers each element of work (such as, "SYS-14: The Site shall allow visitors to request more nformation by leaving their name, address, day or nighttime phone number, and (optionally) their e-mail address"). The SOW is usually referenced in the agreement as being a binding document. Once the Requirements Document is approved by the customer, it may replace the SOW as the most specific binding document. The complete set of requirements (whether expressed in a Requirements Document or a SOW) is the project' specification. |
If it "does not substantially conform" to the requirements in the requirements document, the client must issue a written deficiency notice showing how the product fails to conform. Otherwise, the client should expect an invoice. The developer should be given a fixed amount of time to cure the deficiencies and resubmit the work. Typically, final payment is withheld until both parties agree that the work is done.
On a job of any length, the developer and the client will find ways to improve on the original specification. These new ideas should be written in change orders. In general, they should be accumulated until the rest of the work (that is not affected by the change orders) is substantially complete.
The client can then review the proposed change orders and send any of them back to the developer for a quote. If the client approves the quote, the change orders are incorporated into the agreement and the developer makes the changes.
Is the developer supposed to finish the site and hand it in on a floppy disk? Is the developer to install it on the client's server or on the developer's computer? Be sure these issues are clear before the work begins.
The developer and the client enter into an agreement. They both believe the project can be completed in a few weeks. But with one thing and another, and lots of little change orders, they're still working on the site a year later! Many attorneys advise that both parties agree on a "drop dead date" in the contract: regardless of what happens, the contract expires, say, a year after the work starts. Maybe this applies to your site. Check with your attorney.
Whether it's just a scanned copy of the client's logo or several hours with the corporate president to understand the company's vision, there are many details involved in getting a good site up. To avoid grief later, agree up front on who supplies which pieces of art, who writes the copy, and who approves the page layout. Figure out what should happen if the client does not deliver what is promised in a timely manner and get the agreement in writing.
Each party should identify a project manager. These two individuals should meet at least once a week during the project period, with the developer giving status and progress reports to the client. In this way, no one has any unpleasant surprises and if resources need to be reallocated to advance the task, they can be.
Of course, the agreement should specify how much the developer gets paid and the conditions under which invoices can be submitted. Is there a deposit up front? Are there progress payments? Is a cash discount available? Are any out-of-pocket expenses reimbursable?
Consider having a tax attorney or a CPA review this part of the agreement. In the U.S., the IRS gets aggressive from time to time in defining who is an employee and who is a contractor. Make sure that the agreement is set up in such a way that it accurately describes the relationship between the two parties.
Many small businesses do much of their work on a handshake and
a check. This practice has little to recommend it. Get a good
accounting system (inexpensive bookkeeping systems are available
for all popular computers). Make sure both parties understand
the time the client has to pay the invoice and what happens if
it doesn't get paid.
| Tip |
Books are written about the pitfalls of accounts receivable. If you are a businessperson as well as a Webmaster, read one of them. |
| Caution |
Use cash discounts wisely. Some clients (particularly large firms with unwieldy bookkeeping departments) sign up for a cash discount (say, 2 percent if paid within 10 days), then take 30 to 40 days to pay but still pay the discounted invoice. You have been warned. |
What happens if the site is not up on schedule? Is there lost revenue? Is it promoting a special event that has already happened? If the work is not done one time, the client can reasonably ask for "liquidated damages." Be aware of this and agree in writing to just how those damages are to be computed.
What taxes are applicable to this work? Who pays them? In many parts of the world, there are a variety of excise taxes, sales taxes, and value-added taxes to be considered. These can be applied at the national, regional, or any of several local levels.
Which taxes apply to this work can depend on fine points in the wording of the agreement and of the requirements document. Get a good tax attorney or CPA to advise you on this one and get the decision recorded in the agreement.
It's happened before. The project is nearly done. The developer is about to invoice. Then the client refuses to pay, takes the finished pages from their browser's cache, and puts them up on a local server. It doesn't happen very often and there are two sides to every story.
Still, be sure the agreement spells out exactly who owns the finished product. If the client owns it, specify exactly when the title transfers to them. Many developers show the client a copy of the site on paper or on a laptop but do not make it available to a browser for exactly the reasons given above. Again, you have been warned.
Do you reuse code when you build a new project? Most people do, and most clients have no objection. Just be sure the terms of the reuse are addressed in the agreement so no one has any unpleasant surprises.
On many development jobs, the developers have access to detailed information about the client's operations: billing data, client lists, and the like. Sign a nondisclosure agreement not to disclose the client's proprietary and confidential data except in certain conditions (for example, the information becomes publicly known or the information becomes so old that it is irrelevant).
You've looked at the licenses that come with popular shrink-wrapped software. You've concluded that no software comes with any warranty. Why should Web sites be any different? Be careful here. Unless you specifically disavow a warranty, there may be an implied warranty of merchantability. Details depend on local laws.
Many attorneys advise a developer to provide a warranty ensuring that the product conforms to the specifications in the statement of work (as amended by signed change orders). Other firms like to include the warranty in a maintenance agreement. Will the client have the source code? Will they make any modifications? Under what conditions do you want the warranty to become void? Work out the details with your attorney and the client.
Even with good agreements, disputes arise. In most jurisdictions, going to court can be a lose-lose proposition for both parties. Consider whether you want to include provision for arbitration in case of a dispute. Such a paragraph could save both parties a lot of time and money.
Determine whether you want arbitration to be the exclusive remedy or whether either party can pursue the matter in the courts if they are unhappy with an arbitrated decision. Also decide if you want to keep the team working while a dispute is before an arbitrator. Agree on these details with the other party: your attorney will know how to get the language right for your circumstances and jurisdiction.
What happens if the client goes bankrupt or, for some other reason, can't or won't proceed with the project? What happens if the developer can't proceed? Is the developer entitled to all of the fee? Some of it? Your attorney will have some ideas on this subject. Spell it out and get it into the agreement.
If you put art or copy on the client's site, and someone later steps in and claims that you have infringed on their copyright, who pays? Likewise, if the client supplies some of the material and someone later claims it's hers, who defends whom? Are there any limits to the liability: could a developer be sued for $1,000,000 for a job they were paid $4,000 to do? Work with your attorney. Spell it out, agree on it, and get it in writing.
Would you like to announce the site to the press and maybe showcase your role in the development? Some clients welcome the publicity, but ask first and put the general principle into the agreement so no one is surprised.
Once the agreements are signed and the work portioned out, an effective team uses them as guidelines but not as restrictions.
To make sure every member of the team is committed to a successful completion, get team members involved early in developing the proposal and the requirements document.
Many site development jobs collapse because the overall size of the job was not fully appreciated. During the negotiation period, estimate the size of the job in terms of pages and HTML lines per page, and programs-including the number of objects, methods, and lines of code per method.
There are plenty of good estimation techniques to produce a labor estimate given an estimated number of source lines of code (SLOC) and some other factors. The hard part is getting to the SLOC estimate.
Use a Wideband Delphi method to estimate the size of the finished site. Wideband Delphi is described in Chapter 22 of Barry Boehm's Software Engineering Economics (Prentice-Hall, 1981) and works like this:
Figure 38.3 : Wideband Delphi size estimate.
| Tip |
To prepare their estimate, HTML authors should count one SLOC for every HTML attribute in a tag. The art director and the copywriter prepare their own estimates for art and copy, respectively. |
Use the output of the Wideband Delphi as input to a model for
estimating labor. For HTML pages, PROBE (described in Chapter 5
of Watt's Humphrey's A Discipline for Software Engineering,
Addison Wesley, 1995) is appropriate. For programs, both PROBE
and the Product Level Estimates from Intermediate COCOMO (also
from Boehm, Chapter 8) are appropriate.
| Tip |
For best results, use both COCOMO and PROBE. The results should be consistent. If they diverge widely, explore the differing assumptions of both models and try to resolve them. Failing that, pick the one that seems best and proceed. |
| Tip |
Keep a database of projects. Compare actual performance against estimated performance. Over time, "calibrate" both PROBE and COCOMO to your organization. |
Once the project is under way, organize the work around the task, not around the workday. Some people would rather work 12 hours of their choosing than 8 hours of the company's. Allow the team to define their own work patterns, as long as the delivery schedule is met. If possible, tie at least part of each team member's compensation to the whole team's success.
Team members should work in pairs. Even an expert like an artist, a programmer, or a copywriter should have someone else on the team who knows what they know. This way, in a pinch (perhaps if someone is out sick for a day) the momentum is not lost.
For every functional area, identify someone else who is knowledgeable in this area and could be pulled in if needed. Sometimes these people come from the Red Team. Or they might be technical specialists who can be brought in on contract (the goal is to keep these people at arms length unless there is a disaster).
If someone leaves the team on a long-term basis before the project is finished, this second-level backup can be activated to join the team. Between the primary backup and this second-level backup, the original team members' duties are reassigned with minimal schedule slip. Figure 38.4 shows a typical working arrangement of a "double-backed" team.
Figure 38.4 : A "double-backed" team.
The tools in COCOMO and PROBE allow each component of the schedule to be estimated in detail. During the planning activity, prepare a work breakdown structure (WBS) and allocate time to each task and subtask based on the estimates that come out of COCOMO and PROBE. Continue decomposing tasks until most subtasks have about 6 to 10 hours of work associated with them.
Put the WBS into a project management system such as Microsoft Project. This software allows the project manager to look at the data in many different ways.
Allocate tasks to each team member by weeks and days. With this level of detail, team members each know what they must accomplish each day. At the end of the week, the team leader (typically the Web designer) meets with the client (typically the Web producer) to report progress.
Since the team is motivated to meet deadlines, and deadlines come up every day and every week, tasks that are not being done get high visibility quickly. Peer pressure and the deadline effect tend to keep the project moving forward.
In an environment such as this chapter describes, a small team can do a great deal of work quickly. The team is encouraged to think about everything they do every day and evaluate it against the criteria, "Does it advance the task?" Many of the time-wasters and much of the office politics common in the workplace disappear, at least temporarily.
The intense, task-oriented environment is not for everyone. If the long-term, it's not for anyone. Use these techniques to bring a specific project in quickly and on-schedule, but do not attempt to make this environment the norm. Personal goals and career development do not survive this kind of pressure-cooker environment.
The worldwide emphasis on quality in recent years has led to two conclusions. First, a quality product is the result of a quality process. Second, quality products are built by people who care about quality. These two conclusions are not as disparate as they might seem.
Much of the recent work at the Software Engineering Institute (SEI) at Carnegie-Mellon University is applicable to HTML coding and nearly all of it is applicable to CGI programming. SEI has identified five levels of "process maturity" in an organization. These five levels are arranged in a hierarchy called the Capability Maturity Model (CMM) (see Fig. 38.5.).
The first level of the CMM is called the initial (or chaotic) level. An organization at Level 1 does not have processes. Employees each do what seems best to them. If they do it right, the project succeeds. If they later leave, their experience goes with them. If they get it wrong, the project fails, and in many corporate environments, there is an attempt to "punish" the wrongdoers. Most software development organizations are at Level 1.
With some effort (SEI provides a number of concrete recommendations), an organization can move to Level 2. At Level 2, processes are repeatable. Configuration management is practiced. QA is emphasized. Projects and tasks are planned and tracked. Requirements are managed; changes are documented. Thus, the procedures described in this chapter help move a Level 1 organization to Level 2.
Once processes are repeatable, they must be made explicit. Level 3 organizations begin to be aware of their focus on processes. Processes are defined and form the basis for periodic peer reviews of the work product. Team members are trained on the defined processes. If a project should fail, the emphasis is on finding out which processes went wrong, rather than on "punishing" anyone.
Figure 38.5 : The Capability Maturity model.
At Level 4, organizations are actively measuring processes against defined goals. Thus, processes are managed. Organizations must take care at this level: the measuring can be threatening to the people who work on the process. Management must assure that the measurement is done to improve the process.
At Level 5 (which few organizations have reached), the focus is on continuous process optimizing. Preliminary results suggest that Level-5 organizations develop software at a fraction of the cost and in a fraction of the time of Level-1 organizations.
More important, organizations at Level 2 and above have processes that are increasingly repeatable. Organizations may not always succeed but they have some idea why they failed. Eventually, they can improve the process to minimize the likelihood of failure.
In his book, Managing the Software Process (Addison-Wesley, 1989), Watts Humphrey of SEI describes each level of the CMM in detail. Humphrey estimates that most organizations would take a year to two years to move from any given level to the next. Thus, most organizations would need around seven years to go from Level 1 to Level 5-once they recognize their lack of process and determine to advance up the CMM.
Humphrey acknowledges that small teams might proceed through the CMM at a faster pace. Humphrey's follow-up book, A Discipline for Software Engineering (Addison-Wesley, 1995), describes how to learn the concepts of software process at the personal level.
Humphrey defines five levels of the Personal Software Process (PSP0, PSP0.1, PSP1, PSP2, and PSP3.0) and shows how, in a classroom and laboratory setting, individuals who devote just one day a month for four months to learning these techniques can bring substantial benefits to their organization.
Note that the seven PSP levels are cumulative. While it may be tempting to spring forward to PSP3.0 (and there is a lot to like about that level), the wise programmer or HTML coder starts with PSP0 and works forward in the manner outlined by Humphrey.
Each level within PSP is characterized by four script components:
The process script is a top-level script. It shows the three other steps (planning, development, and postmortem) at that level.
The planning script at each level includes the development of the requirements statements for each page or program. Rough mock-ups are prepared for pages; traditional requirements documents are prepared for programs. At the end of the planning step, the organization has an estimate of the resources needed to finish the job.
The development script includes four steps:
Given a set of requirements (such as those negotiated between a client and a developer), the design activity produces detailed storyboards for each page and software design documents for the programs. Many of the object-oriented design techniques are appropriate for CGI development since their notation is often understandable by people not trained in software engineering.
For HTML pages, "coding" constitutes coding the page in HTML and folding in the content provided by the art director and the copywriter. For CGI programs, "coding" has its usual meaning. Use of Perl5 allows the object-oriented concepts from the previous step to be preserved in the code.
For CGI programs, "compiling" has its usual meaning, though with languages like Perl the actual execution is a bit different than with, say, C++. For HTML pages, "compiling" translates to "validation," using any of the methods outlined in Chapter 2, "Reducing Site Management Costs Through Testing and Validation."
Finally, test (including unit test, functional test, stress test, and load test) is performed on the compiled or validated code.
The final PSP step, postmortem, is a process-measurement step. The programmer identifies where defects came from and how they were discovered. The programmer compares the size of the program and the time needed with the original estimates. These differences are used to calibrate the model for future projects.