1.1. Risk Management
1.2. Proposal
1.3. Contract

2.1. Project Startup Form.
2.2. Resource Request Form
2.3. Task Allocation Form

3.1. Software Requirement Specification
3.2. Change Request

4.1. Software Development Plan
4.2. Project Plan
4.3. Quality Plan
4.4. Configuration Plan
4.5. Backup Plan

5.1. Detail Design Document
5.2. Detail Design Document (Excel File)
5.3. Report Design Document
5.4. Technical Architecture Document

6.1. Test Plan & Report

7.1. Implementation Plan
7.2. Installation Manual
7.3. User Manual
7.4. Technical Manual
7.5. User Acceptance Certificate

8.1. Customer Feedback Form
8.2. Project Closure Report

The purpose of this form is to list any risks that are present or foreseen in the project.
The risk can arise from various sources internal or external to the company.
You can list a risk even before the project is acquired by DSS (The risk at sales / marketing stage etc.) these risks have to be mentioned in this document.
This documents needs to be used and maintained throughout the existing or non-existing project (even if a project has not been acquired).

The purpose of this document is to create standard proposal for clients who have requested for a proposal.
The proposal has information about the suggested hardware / software.
Payment terms, deliverables etc. are mentioned.

The purpose of this document is to have an understanding between the client and DSS in terms of payment, payment schedule, the scope of work, terms and conditions of the project and other clauses.

To initiate a Project after the contract has been sent and official go-ahead has been given to execute the project.
To generate a Project ID for the Project in discussion.
This Project ID will be used throughout the SDLC process and with all other documents in this project.
To officially appoint a Project Manager / Project Leader / Programmers who would be executing the project.
To inform them about the controlling / reporting person for the duration of the Project.
To pick resources from the Common Pool of resources and as and when they are required and allocated to a project.

To discuss the Resources requirements necessary for the execution of the Project.
After the project start up has been done, PM and Sr. Manager discuss the resources required for the execution of the project with the necessary skill sets.
They also identify the period of resource requirement (from what date to what date).
Once the resource is no longer required, the same can be de-allocated from the project wherein the costs will not be accounted in the project.
The Project Manager also indicates the necessary Hardware, Software, Database and Tools required for a smooth execution of the Project.

The purpose of this document is to allocate work to team members and to track the activities allocated to them through this form.
This Form is used throughout project are various stages and is allocated to all the team members in the project.
Task Allocation form can be used as & how the tasks are allocated to the programmers (monthly, weekly, daily…. Etc).
Task allocation can be for a minimum of 1 day.
In case of extreme cases a separate Task Allocation form can be filled.

To generate an overall understanding of the existing system.
SRS should try touching upon the Present system and there is advantages of it – Functionally / IT Scenario-wise.
SRS can also touch upon other areas like System & Communication Requirements, System security, Constraints, Dependencies etc.
The SRS has to be submitted to the client and an approval is required.

This form will be used to request changes to software and documents.
It is a Formal request to change a base lined work product.
This request comes to DSS from the Client once the SRS is been approved any changes to it is done through the change request from.

Commonly known as “SDP”. It is a single point of reference to compile important plans related to a project.
Hence it will help the management to know the overall plan for a project at any point of time. SDP is project wise.
After the project start up the project manager will prepare the necessary documents required for the project.
And file it into one BOX file called “Software Development Plan”.
This file will essentially contain the following documents:
• Project Plan
• Quality Plan
• Configuration Management Plan
• Backup Plan
• Test Plan
• Implementation Plan
If the SDP file spans across multiple box files then the subsequent files may contain volume number. For example, SDP Vol 2, SDP Vol 3 etc…
The documents mentioned in the SDP will be explained detail as we move forward with the SDLC phase.

All projects consist of three major phases:
Build the plan
Track and manage the project
Close the project
The more successful these phases are, the greater your chance of a successful project. Hence, a Project Plan is needed.
The project plan helps the project manager to track, monitor his project and the schedule new task or plan any new changes or enhancement in the project plan.

Quality plan is a project specific document that defines the organization, resources, activities, tools and reports required for quality assurance.
Document standards designed for each project – no two projects would be the same.
It’s a guide to conform to standards.
Allows user of specific quality controls.
Can be updated as the project evolves.
Important organisational tool – what, who & when.
To document the quality objective of a project and how these objectives are achieved.
To define the structure of the team that would be developing the Project and the responsibility that each of them.
To mention the records that would be generated as documentary evidence of achieving quality objectives.
The milestones mentioned in this documents needs to be maintained as per the project plan cause as the delivery of milestones changes, the effectives have to be seen on the Quality plan too.

In this document you are going to define the project structure for eg.
Where you are going to have the customer related documents, where are you going have the project plan, who is going to maintain the directory structure, what file names will be assigned to weekly status report (internal) etc.
What is mentioned in this document has to be followed electronically throughout the project life cycle.

The purpose of this plan is to define the strategy for taking backups during the documentation & development phase of your project.
This document has two parts:
• Part 1 – Backup Plan
• Part 2 – Backup Log
Usually the plan will be defined once at the start of the project, which will hold true for the entire life cycle of the project, but it may be updated as and when there is a change in the backup plan.
The printout of backup log should be taken for a project and it should be manually updated every time a backup is taken.
The backup log with have things like User name, Date, Backup from M/c, Backup Zip filename, Description, Storage location, Virus check, date of deletion, Sign, Checked by etc.

The Detail Design Document is also known as ‘DDD’.
To give the maximum details of the system to the Developer / Programmer.
DDD would give the Developer the complete information including the flow / validations of the Entities in discussion.
The user can define the Software Architecture diagram and represent the system.
The user can also sub divide the Architecture diagram into Module / Section wise.
What are the common Libraries that would be followed in the Application?
The information of the Variables that are being referenced can be given for more clarity.

This is the excel file wherein the details the table decription and table details are mentioned.

This document is for the application report purpose.
All reports and design in this documents.

Commonly known as “TAD”. It will help to know the software / hardware / network setup required at the client’s place to run the new application.
This document also serves the purpose of knowing the issues related to current / proposed IT scenarios.
The basis for preparing this document could be the technical specification requirement given by the client.
In absence of the technical specification requirement, the MoM’s on technical issues with the client can be referred for preparing this document.

To gather all the information necessary to plan and control the test effort for the given Project. To record the results based on the test plan prepared.
Test plan and result would help minimizing the errors carried down to the implementation stage.
Test Results are updated at the time of testing of an application.

Defining an appropriate schedule for installation and training. Organizing, and managing tasks and resources during implementation.
To accomplish a defined objective, usually within constraints on time, resources or cost. Implementation plan is to be prepared for every project and for complete project.
It should contain all the aspects involved from the start till the end of implementation.
This documents has to be sent to the client so that all the necessary requirement for a successful implementation are taken care of.

This document will explain the step by step procedure to the client on how to install and setup the application/project.
Is prepared for the application/product that is going to be delivered to the Client.
The installation manual should be ready before implementation.
The installation manual must explain how to setup, install and configure the application/product.
If the application has to be installed on different platforms, please explain different procedures to be followed for installation on each platform.

The purpose of the User Manual is to guide the user to how to use the system.
User Manual should explain the various screens & functionality existing in the system in detail.
The user manual should be delivered along with or just after the implementation of the system.
The user manual must explain the functional flow of the system with reference to the user.
Any up gradation to the system should result on a new release of the user manual with an increase in the version no.

This document explains the technical details of the project for e.g. Database and Screen level details.
This document is prepared for the client on request so that in future the client can maintain or upgrade the application/product on their own.
The technical manual is the only technical documents for the client to maintain the application/product on their own.

This is an important document that is required by DSS.
This document is the proof, evidence and a certificate from the client to DSS for acceptance of modules, applications, product, documents etc.

The purpose of the Customer Feedback Form is to gauge the quality of output from the client’s perspective in order to improve in subsequent deliveries.
This way DSS will improves its inaction as well as the output expected by the client.
And overall it will help DSS to improve as it grows.
Form will be prepared for all projects to be delivered to the client.
The Customer Feedback Form can be filled in by the client as a hard copy or as a soft copy.
This document too is an important proof/evidence as we receive feedback from the client.

To formally close a Project.
To de-allocate the resources those are a part of the Project.
To release the Hardware if any held specific to the Project.
To document the lessons learnt from this project this will be a guideline for the future projects so that these are well taken care of.
This document will be prepared once DSS has received the User Application Certificate from the Client on the whole project and it will be forwarded to the Billing Department for billing.
With this document the project is said to be finally close.
A project can also been closed if the project has been terminated by the client / DSS due to any reasons but despite of that this document need to be prepared.