Full Life Cycle Web Development

5

Full Life Cycle software development is a gradual process followed in software development. It is also called the software life cycle. Today, this involves teams of experts in various fields such as analysts, testers, architects, programmers, and even end users and a broader definition includes the CMMi (Capability Maturity Model Integration). The main importance of these techniques is to set goals for deliverables and manage expectations of the clients.

The general deliverables in this process include a requirements document, a system design, coding and testing. Each one of these four phases can easily be performed by different contractors is done correctly. The key is that each sets up what is needed to move to the next step.

In a more detailed description of each phase, we have the following phases:

1. Needs Analysis - This step involves careful and thorough review and study the client's needs. It requires a good working experience in the SE (Software Engineering) to the critical understanding of the requirements (stated or expected).

The deliverable here is a high-level requirements document focused on the needs of the customer. It covers what is necessary to accomplish and the problems to be solved.

2. System Specifications - This stage establishes the Systems Architecture Design. For web systems, this usually includes the languages that will be used and which web browsers and database technology will be used. There are usually details on other technologies such as third party software integrations.

In this day and age, we generally include large players like FaceBook and easier integrations like Twitter. With over 700 social networking sites out there as of March 2009 and the list is growing fast. Integrating 4 or more of these applications into your web site is a great strategy for getting large participation in your web site community.

The deliverable here is a system requirements document. But this is still not detailed enough to build a testing process at the end of the full life cycle development process.

3. Functional Specifications - If you think of a web site with multiple pages and multiple sections on each page, each may be tied to a different application on the back end. What you see could be just the tip of the iceberg. Ads on each web page on just one web site might be tied to a different set of ads accessed from different web applications on various combinations of web sites. One small area of a web page could be a very sophisticated application that you don't really see - you just see something on the page. If you think of a web site as just something you see (a graphic or design) you may be missing the beauty of what is really going on and why the application is so powerful.

The functional specifications go into great detail about what each part of each section of each page on a web site does and how it interacts with other components of other web sites. The deliverable here is a functional requirements document.

4. Design Specifications - this is where we put everything above together into a design specification document. Many developers can build an application without this, but correctly written, it should actually simplify and speed up development (coding and implementation). It gives the developer(s) an easy reference guide as to how everything works together.

5. Coding and Implementation - At this point, the coders start coding each component and putting them together into something that can be tested.

6. Testing - Ideally we have at least three working environments - a development area, a testing area and a production area so that developers can continue to develop while completed work is being tested in the test area. It your web site is already up - if it exists so people can access it - then fully tested (approved) components can be released one at a time onto the production site.

One of the tricks to recognizing a properly written requirements document is that each requirement is written so that it specifies that the application "will" do this or that. It should translate easily into test cases which read "Does the application" do this and that.

One of the tricks I have been using for many years is to include some flexibility in our contracts so that some requirements must be delivered and some can be deferred to another major release in case there are issues that come up that affect the delivery date. I generally write these in this way because customers generally think of changes or additions and even deletions of the agreed requirements.

Setting up a contract to specify that 70% of the requirements absolutely must be completed and 30% can be deferred allows for this kind of flexibility. The ploy I usually use to get this into the contract is usually some kind of minimum contract amount for the 70% and a bonus for the 30% completed in the current phase. When the changes, additions and deletions are requested, we usually swap some of the existing requirements for the new requests. Using this technique, we find that customers are always happy and we can still deliver on time, under budget and be flexible.

Another part of the development process is creating documentation. We tend to break this up into the technical documentation mentioned above, and the user documentation that goes into user manuals and training. Videos, screen captures and testing processes can be built directly into any application. In this case, they would be part of the requirements.