Professional PHP5 (Programmer to Programmer Series)
ISBN: N/A
EAN: N/A
EAN: N/A
Year: 2003
Pages: 182
Pages: 182
As mentioned previously, both waterfall and spiral approaches are consistent in their insistence that all development must have a specification phase, followed by a design phase, followed by a build phase, followed by a testing phase.
The difference lies in how much specification, design, build, and testing is done with each iteration, and the size of the chunks in which it is done.
However, the words specification, design, build, and testing are very much open to interpretation. Let's examine a little more closely now how you might implement each phase, regardless of whether you have chosen a waterfall or spiral approach to your project.
For the sake of clarity of language, we assume that you have adopted a waterfall approach for your project and hence describe the phases in application to an entire project rather than an individual component; however, if a spiral approach has been adopted, you can apply exactly the same methodology to each component in your spiral.
The specification phase is, in many respects, the hardest part of any project; often much trickier than the build process itself. This is particularly true if you are assigned to build a slightly mundane system a front-end to a simple database, for example. The task of development is not exactly challenging; the task of getting it right for the client the first time is a lot harder.
This phase is about ensuring that you know what you're planning to build and, more important, that the client knows what it is you're planning to build and that it matches the client's original business requirements as closely as possible. The easiest approach to adopt here is to produce paper specifications for the project a functional specification and a technical specification.
The Functional Specification for a project describes in detail the functionality of the system at a predesign level. It should be written in plain English and not place too much emphasis on or provide a rationale behind technology-led decisions. As a rule, you should roughly follow your pitch document, if you wrote one, and reproduce the brief in some detail here. It provides an excellent starting point for seeking affirmation from the client that the terms of reference for the project remain the same.
This is where the similarities with your pitch end, however. All the detail that we earlier implored you not to include in your pitch document should be included here. Remove any ambiguity from areas you would rather not repeat in case you get it wrong. Getting the level of detail right is a fine balancing act. Too much, and the document becomes unreadable; too little, and there is too much scope for interpretation or later disagreement over functionality.
With this in mind, try to be clear in any areas you think may be open to interpretation. For example, if you use the phrase "the user will be able to upload photographs to associate with his or her profile,'' the client is unlikely to latch onto the fact that you have omitted the number of photographs, or what format they may be in. When a scenario crops up of a user's wishing to upload eight hundred. PCX files but your application cannot support it, you may be in trouble. Instead, try to use phrases such as "the user will be able to upload a maximum of eight photographs in JPEG format to associate with his or her profile.''
By the same token, however, mind-numbing detail should be avoided because that kind of level of detail could cause temporary paralysis in even the most patient of clients. If you find yourself using the sentence "The page will have a home button which, when pressed, will take the user to the home page,'' you're guilty.
The litmus test for whether a specification is on the money is whether you could give it to five different teams of competent development and design staff and in each five cases have roughly the same thing built. At the same time, though, you should leave open to interpretation any decisions that may best be left to a later phase or to others on the project; "The page will have a home button positioned at 124 pixels from the left side of the screen'' should be avoided, because this decision should be left to a senior designer during the design phase.
In your functional specification, try to lay out the document as clearly as possible. The following is a suggested layout from start to finish:
Replication of the client's brief, in not more than half a page, in your own words.
An explanation as to what this document provides, what is expected of the client, and what other documents you will deliver as part of the specification process. Be clear at this stage that this is a document you expect the client to physically sign off on before you move forward.
Explain in not more than half a page a top-line summary of your proposed solution, and list the components it is likely to entail.
For each component, provide a detailed explanation of its functionality, including typical usage walkthroughs for dummy users.
Provide diagrams if you genuinely feel it will improve clarity; otherwise, avoid them. No matter how hard you stress that they are only diagrams, clients invariably interpret them as completed designs, with predictable consequences. The same pitfall is equally true with page maps, which we will meet later in the next section.
Complete the document with an explanation as to what the client needs to do next if they want to ask questions or make changes, or want to sign off the document. Explain the next stages after the document has been signed off, and gently advise that previously agreed delivery milestones are all subject to timely agreement to this document.
In practice, you will require at least two or three iterations of the specification before the client is happy. Indeed, you should be wary of any client who signs off a specification on the first attempt; nine times out of ten it implies the client hasn't read it.
If the Functional Specification describes what you plan to do, the Technical Specification describes how you plan to do it.
The level of detail you need to include here will vary dramatically from client to client. Generally, if the client themselves has an IT department taking a keen interest in the project, you will need to provide an exhaustive level of detail right down to your coding practices. Otherwise, you can normally get away with providing:
Suggested language for build, with rationale and explanations, and comparisons and rejections of other, rival languages
Suggested database platform, with rationale and explanations, and comparisons and rejections of other database platforms
Suggested operating system for Web and database servers, again, with comparisons to other platforms and reasons for their rejection
Explaining the hosting and deployment plans for the project (if any), going into detail on bandwidth requirements, and so on, where appropriate.
An explanation as to what this document provides, what is expected of the client, and what other documents you will deliver as part of the specification process. Be clear that this technical specification relates directly to the functionality the client has already signed off on in the functional specification.
If you have chosen to adopt a spiral process for your project, it is not necessary to provide a technical specification for every traversal of your spiral. Instead, provide a single technical specification at the start of the project, and explain to the client that this specification relates to the implementation of all individual components to follow.
With many clients, especially those not equipped with their own technology department, this document may prove to be quite alien. You have two choices: go to great lengths to explain the document in detail with them to ensure that they are happy with the decisions you've made, or let them sign it blindly, which they may be more than happy to do. Sometimes the latter decision is easiest; after all, clients will feel they are paying you to tell them what is technically sound, not ask their permission.
The word design may prove to be misleading here. It relates both to graphic design and to software design but, of course, the two are very different disciplines and you should be aware of the distinction. Yet it is almost inevitable that the client will want to see some individual graphic designs for the key components of the project as soon as possible.
It is absolutely fine for the senior designer on a project to take responsibility for and produce these designs, as long as it is done closely in consultation with the lead architect to ensure the technical feasibility of what is being proposed. Skilled senior designers will be aware of technical limitations and hence require less guidance when designing for the Web.
Once again, expect to produce a few iterations of the designs before you get it exactly right. This can be immensely tricky, too; the client will have his or her own unique vision of what is desirable and may struggle to articulate it to you as a supplier. All the client will know is that what you have produced is not what is wanted, and he or she will not hesitate to make this clear to you.
Sometimes it can be useful when presenting designs to a client to allow the senior designer to present the designs themselves, possibly, even, with a laptop loaded with graphics and RAD software so that suggested changes can be made in front of the client; the reaction "that's it, that's how I want it'' can be most gratifying as well as commercially useful.
With the key designs signed off on, it is a very useful exercise to produce what is known as a Creative Specification, or style guide. This document is not normally presented to the client for inspection, although if the client is very protective of branding or has in-house graphics staff, it may not be a bad idea.
The traditional purpose of this document is to communicate the artistic vision of the senior designer to more junior studio artists, and to ensure that any future design work carried out on the project is consistent with that vision, too.
Its likely content will include details of fonts, colors, layout, logos, backgrounds all the components that make up the broader artistic vision, such that if a request such as "produce me a button that says Add to Basket'' is made, the button that is made will look exactly as the senior designer would want.
Possibly the most controversial component of the design phase is the Page Map. Essentially a wire-frame, black-and-white model of a given page in the user's Web browser, it attempts to articulate the user interface without communicating any facets of the design. It allows the UI to be approved separately from the graphic design, when commercial or political pressures mean this could be useful, or when no specific graphic design has been produced for this page.
In addition, it can be given to the development team, alongside the Creative Specification, such that they can directly commission studio artists and client-side developers to produce designs and HTML needed to deliver some particular component.
In practice, however, page maps have two major pitfalls. First, it is often difficult to separate the concepts of user interface and design in the client's head. This can mean that presenting page maps to a client can be a tiresome and stress-inducing task, because they will perceive your wire-frame diagrams to be the finished look and feel and will balk at the prospect. Obviously, you need to make it clear exactly what you are presenting.
Second, the remit for actually producing page maps is hard to define. Graphic designers are rarely experts at producing "interfaces'' per se and are often loathe to use Visio and other packages required to produce these deliverables. Project managers are usually far too busy. The result is that the task often falls on the shoulders of the lead architect. Given that the role of imparting a vision for the production of particular components to software architects and engineers is at the heart of the remit of the lead architect anyway, the arguments for documenting this vision are weakened.
Again, another piece of documentation that you may or may not want to present to the client for approval is the Software Architecture plan. This is often called a ten-point plan because it is generally a series of short, punchy bullet points outlining the best approach to the actual project or component in hand, instead of being a prose-heavy document.
The production of this document is very much the remit of the lead architect, who will normally produce it well after the Technical Specification has been approved and signed off on. As such, it will not concern itself with technology choices, hardware, hosting, and so forth. Rather, it will concentrate on issues such as database schema, object models, and implementation of design patterns such as MVC.
He or she will communicate the document to his or her software architects, who will in turn interpret it as they see fit. In theory, the "architectural vision'' should cascade down to software engineers working beneath them, too.
With all design parameters agreed upon, the build process itself can commence. There is no written documentation to accompany this phase, but a few points are worth keeping in mind:
Always maintain both development servers and a staging server, as well as the production server. These do not necessarily have to be separate physical servers, but it is vitally important that you can release partly completed stages of development to the client so that the client can witness the progress you are making.
Try to adapt a programming methodology, if one is appropriate to your project. These are discussed in more detail in the next major section of this chapter, "Programming Methodologies and Practices.''
It is the responsibility of the lead architect to manage the build process and ensure that his or her team delivers all components on time and at the required standard so that he or she can deliver the entire system to the project manager as a completed package, rather than piecemeal.
Always maintain fastidious version control. Later in this book you'll learn about CVS, a free solution to this often problematic issue.
Having built the solution, it is vital for you to conduct suitable testing, both to assure yourself of the quality of what you have produced, and to reassure the client that he or she doesn't have to perform exhaustive testing.
The testing you conduct should always be accompanied with written reports detailing your findings. For obvious reasons, you should not release these reports until you are 100 percent happy that the testing has been a complete success.
Functional testing ensures that the product works exactly as expected, both that it fulfills the specification exactly and that it is free from errors or malfunction. Be systematic; test each area of functionality relentlessly, using a number of different data sets and/or input parameters. Record your findings systematically, too, to in effect demonstrate a check in the box next to each distinct feature.
Of course, you should always stress to your development team that it is vital to "test as they go'' as far as possible, and never turn in code they know to be seriously buggy. You may consider using a bug-tracking system such as Mantis (www.mantisbt.org) to maintain a centralized repository of bugs as each is discovered, assign the bugs to developers, and annotate them appropriately.
If the application you are building is likely to be high traffic either now or at some point in the future, it makes sense to know how much it can take before it falls over.
Load testing can be conducted only if you can deploy the application onto a realistic environment, usually the production server. There is no point in testing your application on your Xeon-driven Linux development server if you know you'll be forced to deploy onto a Sun box running Solaris. A number of packages are available, the most popular of which is probably LoadRunner, from Mercury Interactive. Similar results, however, can be achieved using a suite of custom-built test scripts.
The key to load testing is to never be afraid to turn the volume up as high as it will go until the speakers explode. Simply knowing that the client's traffic expectations can be handled is good, but knowing exactly how much more they can handle beyond that is even better. The client will be gratified if you can provide an exact figure, such as "the site will handle one thousand simultaneous users with no problems.''
Having produced a thoroughly documented, well-designed, fully tested piece of software, it is vital to arrange a proper handover meeting with the client. This is the client's final sign-off either for the whole project or for this component, depending on the process you adapted in the previous section.
During the handover process, you should endeavor to ensure that the client is fully comfortable with the inner workings of the finished product. An element of training may be required as a result. Also, remember what you're there to do hand over the project. Presenting the client with a CD containing a copy of the source code can have a symbolism that is hard to measure.
It is almost inevitable that small change requests will crop up during the handover process. Later in the chapter we look at how to handle them.