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
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.
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.
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.)
Copyright © 1999-2004 by Web Space Station®. All rights reserved.