The planning phase of a project includes the key “upstream” areas of requirements development, quality assurance planning and architecture. A thorough planning phase is of key importance to the overall health of a project. This is illustrated in the image below and through industry research that shows an error in the planning phase, such as a requirements or architecture error, may cost 50-200 times as much to correct late in the project as it does to correct close to the time in which it was originally made.



Requirements Development

Requirements Development consists of gathering, specifying and analyzing requirements. This phase should include direct communication with end users whenever possible. It may also include User Interface (UI) prototyping and development of a style guide. Because UI is so fundamental to the flow of the application, changes to the UI can lead to dramatic design changes in the underlying software. Thus, UI is a critical element of requirements development. Depending on the complexity of the project, prototyping may be extended to demonstrate functionality.

The final deliverable from this phase is requirements documentation, which includes use cases as well as system and other non-user requirements. Use cases are an exceptionally important deliverable from this phase, as they are the basis for both end-user documentation as well as functionality test cases. Use cases are simply a convenient way to describe the functionality of a system from the perspective of the people who will use that system. Each use case specifies the actions that a user may take and the responses that the system provides to those actions, without saying how those actions are performed. The how is defined in the architecture and detailed design phases. Data and business rule definition are part of the use case development process.

Quality Assurance Plan

The Quality Assurance plan defines the scope and approach of testing. This plan includes technical reviews and relevant testing activities, which are further defined in the Testing section below. Quality Assurance is often thought of simply as functionality testing, which begins after coding is complete. However, such an approach is both limited and potentially costly. An industry rule of thumb states that each hour of upstream (i.e., early in the process) quality assurance activities will save 3-10 hours of downstream costs.

System Architecture

System Architecture is a high level specification of how the project requirements will be met. It provides the technical structure for the project by covering issues such as overall program organization, notation, change scenarios and strategy, components that can be leveraged from existing code or purchased from a third party, design approaches to standard functional areas, and requirements mapping.

Design of the application should flow out of the use cases specified during the requirements development and the high-level system architecture. During this phase, the application is defined and documented on a detailed technical level so that all of the requirements will be met. This should include data modeling, which is the definition of how the data necessary for the application will be stored in a database. An object model should be created to define the software components. Also, the system architecture defining the physical design (including specifications for servers and their roles) should be created. Several people review technical specifications to ensure the quality of the design. Design is still an upstream activity, and like the requirements phase, offers greater leverage on the development schedule than subsequent activities.

On larger projects, Design may be broken down into two distinct phases, High Level Design and Detailed Design. High Level Design specifies the overall Architecture required to meet the overall requirements of the system. During this phase all the major components of the system are defined. During detailed design, each major component of the system undergoes another iteration of design making sure all the technical details for its implementation are fleshed out.

During the construction phase the development team plans (pseudocode and code design), creates, unit tests, and debugs the application source code. Coding standards are enforced during technical reviews that occur at pre-defined milestones in the construction phase. In addition to coding standards, technical reviews will evaluate application scalability and maintainability relative to the project’s objectives. Change control is a key element of an effective construction phase.

Types of Testing

A brief overview of different types of testing is set out below. The types that are applicable and included in the scope of the project will be set out in the Quality Assurance Plan in the Project Planning phase. Activities applicable to several of these testing types may overlap with each other (such as functionality, system and end-to-end). Typically, all projects will include unit and system testing.

Type of Testing	Testing Description
Unit	Testing of particular functions and code modules, done during the Construction phase.
Functionality	Tests are based on requirements and functionality. Not based on any knowledge of internal design or code.
System	Testing that is based on overall requirements specifications; covers all combined parts of the system.
End-to-End	The “macro” end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
Data Load	Tests the system’s ability to accommodate the required cumulative volume of data over a period of time. Measures system response time as the volume of data in the system increases. Data Load Testing overlaps somewhat with Performance Testing
Stress	Testing application under heavy loads to determine at what point the system degrades or fails. This test is generally executed using testing tools to simulate large numbers of users. System components are monitored during the tests to help identify and anticipate failure points.
Performance	Measures system performance while modeling “real-world” conditions. Allows determination of average response times of typical users under normal conditions.
Security	Testing how well the application protects against unauthorized internal or external access, willful damage, etc.
Compatibility	Testing how well software performs in a particular hardware/software/operating system/network/etc. environment. The requirements outline the specific platforms, browsers, etc. the application will be tested on.
Acceptance/User Acceptance	Final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time. Acceptance period defined in project plan. Parameters for acceptance defined in Planning phase.
Usability	Usability testing measures whether users are able to find and do what they need with reasonable effort and within a reasonable period of time. It helps establish how users perform specific tasks and interact with specific elements of the interface, and how satisfied they feel about each of these interactions. In addition, usability testing can provide significant ROI for an application that will include user support features. By improving usability upfront, ongoing user support costs can be lowered.

Defect Tracking

The QA team uses an internal tracking tool, DevTrak, to track defects found during testing. A defect indicates that the site does not work as specified or is otherwise expected to work. Defects are recorded and tracked until they are closed. As defects are identified, a severity and a priority is assigned by QA based on established criteria.

The deployment phase involves moving the developed software to the production environment. The Lead Developer for a project is responsible for writing a code release plan that details all steps necessary to move the application from the development environment to all applicable subsequent environments (including stage). This plan is reviewed in a meeting with the System Administrator and any other team members that is be involved in the deployment prior to the release to the next environment. All production moves require approval from the client and project manager.

Change control is a management practice that permeates all phases of a software development project. It applies to the practice of placing important work products, such as Use Cases, Technical Design, Quality Assurance Plan, Test Cases, Source Code, Assets, and Code Release Plans under change control. It also applies to a systematic process for addressing change wherein changes are identified, justified, and quantified and assessed for impact to schedule, budget and product quality. Pre-determined stakeholders then make change decisions on the basis of this information. The formality of the process will vary from project-to-project, depending on factors such as project size, scope and duration, and should be determined at the outset of the Planning phase of the project.

While many aspects of the software development process described above are implicitly risk reduction activities, several explicit risk management activities and concepts are worth noting. Each project should have some portion of its budget set aside for risk management activities. This may include time for activities such as creating and updating a Top Ten Risks List, assessing risks, and communicating (including documentation) these assessments to stakeholders. The primary risk management tool is the Top Ten Risks List, which is created and maintained on a consistent basis (approximately once a week) by the project team. This list includes a description of the risk, priority (current and historical) and resolution status.