Building the Domain

With plans in hand, time and cost to build are finally clear. The next question is whether to develop inhouse or to outsource. Either way it plays, a team is assembled. Analysts, designers, programmers, artists, testers, and network engineers all come together to make the new domain and its applications sing. This is usually the longest part of the project cycle.

Building a Web Application

Beginning with a Concept
Analyzing Use Requirements
Designing the Domain
Building the Domain
People and Money

return to the leakyboat


A functional specification describes how a domain and its applications will work, what it will look like, and why it should be built. A technical specification describes how a domain and its applications will be built, and what technology options are appropriate for its planned implementation and use.

It seems like an awful lot of time and effort has gone into talking and planning to get to this point. The concept has been fully explored and articulated. Each process that might be incorporated into the domain and its applications has been examined and described. And then the processes have been reassembled into a designed logical environment that is described in  a functional specification and a technical specification .

For the first time in this process, it becomes possible with this information to set some reliable estimate as to how much total time and cost will have to go into this effort. The question of time and cost is usually asked long before this point. But if it is answered before this point, that strongly suggests that there is a reality and two perceptions of that reality, one belonging to the developer and another belonging to the developer's client. Moreover, it suggests that it is entirely possible that the reality and two perceptions might have very little in common.


How to know whether the correct platforms and tools were selected? Adherence to standards is the best guideline. This has become particularly important in large enterprise projects in which there may be many phases over time, many developers over time, many interfaces with other systems, broad diversity among client systems. It is equally valid for smaller projects as well. Using standards for development goes beyond tools and platforms, and includes understandings within the development team as to how work will be performed and documented.

At this juncture, nothing of the domain has been built (prototypes excepted). But there is a specific documented understanding of what structures and functions will be built for the first iteration (or "first release") and how they will be built. There is a specific documented understanding of what pages will exist and how they will be reached. There is a specific documented understanding of what controls (buttons, fields, links, etc.) exist on every page and what processes they will trigger when they work as well as when they fail. There is a specific documented understanding of data entry requirements and output options as well as the process that yields the results. Everything about the first iteration version of the domain has been thought out and documented.  Technology platforms and development tools have been selected. 

Want a fixed bid? Fixed bids are only possible and realistic when all time and cost risk factors have been removed from the project undertaking. Competent detailed functional and technical specifications of the domain serve to remove that risk for developers. Otherwise, one should expect to pay an hourly rate -- or a fixed bid padded beyond all reasonable limits.

Now, a major decision must be made. One possible option is to develop the project internally. Another possible option is to convert the documentation into a  Request for Proposal (RFP) and to put the project up for bid . Outsourcing development is increasingly more common these days, particularly for companies that have a core business that is other than information technology. Whether the project is internalized or outsourced, the process will likely continue as described below.

Project planning can now be realistically developed into a phased project plan by defining objectives, tasks, resource requirements, and budgets for time and cost. The results of this effort are reviewed, accepted and approved by stakeholders and business principals. The functional specification should by now have undergone careful reviews by the subject matter experts and sign-offs should be collected.

The development phase is ready to begin.

There is not much that can be said about the development period in a general sense (except for what may be described below). Each project is different. The development phase of any project tends to be the longest part of the overall project period.

With respect to hosting the domain, there is often the question as to whether the web server(s) should be maintained in-house or outsourced with a hosting service provider. Without examining all the pros and cons, a good argument can be made that installing a development server in-house makes sense during development and that outsourcing the production server just prior to deployment testing makes the most sense. But, again, this varies according to the circumstances.

The development of creative design (i.e., the specifics of user interface and "look and feel") can now be initiated in earnest. Actually, the creative talent on the development team should have been drawn into project (if not outsourced) during the design phase to contribute to the discussion of user interface design. But if they become involved at the beginning of the development period, this is usually OK.

In the final stages of preparation for development,  development servers for the web, development application software, and the RDBMS environment are installed and configured.  The chore to develop the domain and its applications is now turned over to the programmers and artists.

Progress evaluation points along project timelines are commonly associated with junctures of completion and are referred to as "milestones".

The analysts and designers begin to shift their attention to the testing routines that will verify that the domain is being built to their designs. If the project has been outsourced, then it is the documentation of the business analysis that forms the basis of quality assurance (QA) testing. Since development is the portion of the project that takes the longest period of time, this time should be marked by  regular periodic reviews of progress .


As development of the domain approaches completion, QA testing against completed components turns into a full time effort and begins to test longer processes involving multiple components and session sequences. If necessary, a greater portion of developer time, as required, is devoted to correcting faults recorded in the QA effort. Hosting arrangements must be finalized and production servers are installed and configured for deployment in the beta testing phase of the project.

The domain is moved onto production servers upon completion of the development period. Beta testing begins with users who have not been involved with the design and development of the domain although they will work with both explicit test scripts and more vague figure-out-how-this-is-done scenario problems. Faults continue to be cleaned up. If not already begun, training and documentation development commences.

When the domain is launched, full attention is directed to monitoring its operation and ensuring its stability. This is because new and unknown users bring new and unknown use variables into play.

Also known as "brain farts"...

The development team conducts a project postmortem to reflect on the project effort. When the lessons of the first iteration have been noted, then the list of functions that did not make it into the first version spec is pulled out and reviewed. That list is combined with the list of all the ad hoc "wouldn't it be cool if we..."  flashes of genius  that threatened to undo the plans and bloat the scope of the first version during its development period.

And the road to the next version begins. After a small celebration, of course...

Before leaving this topic altogether, it might be worthwhile to review some thoughts about the people involved, the skills they should possess, and the formula for calculating time and cost.

Return to Top.

web application development, outsource, functional specification, technical specification, development time, development cost, prototype, standards, request for proposal, rfp, fixed bid price, project planning, project budget, creative design, look and feel, quality assurance testing, project milestones, hosting, brain fart