Most materials discussing the phases of a software development project are intended for

the developers community. I decided to take a different look at the issue and help those
novices who are going to outsource a software development project to an outsource
service provider (OSP).

Software development isn't all about the code. In fact, coding is part of the overall project lifecycle.
The project phases that I'm going to review in this article are a slightly modified version of the
classical sequential model that is appropriate for a lot of projects. However, you shouldn't think that
this model is universal throughout the industry and that it can't be modified; on the contrary,
almost each business applying this model adapts it to the specific needs of real situations.

The typical software project includes the following phases:

1. Requirements Analysis and Definition. System Overview

2. Estimation

3. Functional Specification and UI Prototype

4. Software Architecture and Test Plan

5. Implementation (Coding) and Testing

6. Release. Delivery and Installation

7. Operation and Maintenance

Below you will find a brief description of these phases. Later on, we're going to publish a separate
article on each phase.

Requirements Analysis and Definition. System Overview

This phase begins with analyzing what exactly you want to have done. The system overview helps
you see the big picture of the project and understand which steps need to be carried out. You
should determine and document the vision for the target product or system; the user profile(s); the
hardware and software environment; the most important components, functions, or features the
software must have; the security requirements, etc. To aid in the needs analysis, it is sometimes
necessary to have prototypes created - or to have them created by professionals, for that matter.
All this can and often should be done in cooperation with your vendor.

The product of this stage is the general system requirements (and sometimes, draft user manual).
This document will be modified as the project is undertaken.

Estimation

This is a phase that is usually obscure to customers. Vendors tend to supply you with an estimate
itself, and that's it. Personally, I believe that customers may and should take more active part in the
estimation process. For example, you have to be able to select from different options discussing the
platforms, technologies, and tools that will be used for the target system. Also, make sure your
vendor does a research of the existing libraries and tools that can be used in the project. Remember
that an estimate should explicitly list what is included in the price, as well as why and how much
any additional features will cost. Never let the vendor baffle you with technical jargon and complex
details. Finally, if you are in doubt about the provided estimate, consult an expert; if the vendor
appears to try to take advantage of you, don't bargain with such a company - just say "thank you"
and look for another OSP. Outsourcing is risky by nature, so you can't afford to take chances with a
vendor like that.

The estimate isn't the only document that results from this phase. The project contract (or project
bid) and rough project schedule usually come into existence at this point, too.
Functional Specification and UI Prototype

A functional specification determines what exactly the target system must do and the premises for
its implementation. All requirements should be thoroughly defined and documented. The general
system requirements and other documents created in the first phase serve as input here.
Depending on the nature of the system, creating a UI prototype in this phase may be crucially
important for the success of the project.

If your company has appropriate experience, you can have the functional specification and UI
prototype created in-house. However, I recommend ordering the development of the specification
and UI prototype from your OSP. This will help you check the vendor's expertise; at the same time,
the vendor will have an opportunity to get a better idea of the project and get prepared for its
implementation.

Besides the functional specification and UI prototype, this phase may also result in creating an exact
project plan that contains the project schedule, milestones, and human resources.

Software Architecture and Test Plan

In this phase, it is necessary to determine the system components covering your requirements and
the way these components will work together. The software architecture design may be logically
divided into two parts: general design and detailed design. The general design consists of the
structural design, development strategy, and system design documentation. Working out the
general design, developers break the target system into high-level components and describe them
in the context of the whole system. When it comes to the detailed design, specification and
documentation on each component are developed. The general system requirements, functional
specification, and UI prototype serve as input for this phase.

Completing this phase, your vendor should produce the description of the software architecture, the
algorithmic structure of the system components and their specifications, the documentation of all
design decisions, and a thorough test plan.

Implementation (Coding) and Testing

The goal of this phase is building the target system based on the specifications developed in the
previous phases. Transferring the specification algorithms into a programming language, your
vendor creates and integrates the system components. Performing code reviews and test cases
worked out by the vendor's QA/QC division, as well as unit, integration, and system tests are other
key activities of this phase. Comprehensive testing and correcting any errors identified ensures that
components function together properly, and that the project implementation meets the system
specification.

Outsourcing a software development project, I advise you to have a project delivered and paid for
in parts. This is one of the best ways to minimize the risk for you and your vendor. If you aren't
satisfied with the way the project is being implemented, you can take to another vendor the
specification and the code that was previously delivered.

Release. Delivery and Installation

In the release phase, your vendor must transfer the target product or system to you. The key
activities usually include installation and configuration in the operational environment, acceptance
testing, and training of the users if necessary.

A crucial point here is formal acceptance testing which comprises a series of end-to-end tests. It is
performed to confirm that the product or system fulfills the acceptance requirements determined by
the functional specification.
After this phase is complete, the product or system is considered formally delivered and accepted. If
iterative development is used, the next iteration should be commenced.

Operation and Maintenance

The Operation and Maintenance phase begins once you have formally accepted the product or
system delivered by the vendor. The task of this phase is the proper functioning of the software. To
improve a product or system, it should be continuously maintained. Software maintenance involves
detecting and correcting errors, as well as extending and improving the software itself.

Conclusion

I'd like to conclude this article with a little advice. You shouldn't treat the documents resulting from
phases 1, 3, and 4 as a law that can't be amended. The system requirements, user manual,
functional specification, and even software architecture design often need to be updated and
modified throughout the course of the project implementation. Just be cautious that any changes
introduced in the documentation are consistent with your initial vision for the target product or
system. (Well, let's face it: the initial vision may eventually change as well.)