Process documentation
Process documentation describes the course of the software project, from creation to the end of software maintenance. It serves as an authoritative guide in the development of the system and ensures that internal knowledge is retained. The goal of process documentation is to structure and organize the software development process. At the same time, it helps to make the project more transparent and reduces the administrative effort. Types of process documentation are detailed below.

Project plan and schedules [Mandatory]
Project plans and schedules are usually created before the project starts and are continuously updated during the software development process. A project plan defines the project’s scope, schedule, deliverables, milestones and tasks and may take different forms depending on the implementation methodology used.  

 Where  a waterfall methodology is used the plan may include a detailed work breakdown structure that breaks down the project scope into the project phases and deliverables that leads to the final product. In the agile approach which is the main methodology used for software projects in Government institutions, planning happens iteratively and documentation includes product roadmaps, project backlog, release plans and sprint plans. 

 Project plans and schedules can be documented in a suitable tool used by the institution.

Progress reports [Mandatory]
A project status or progress report is a document that describes the progress of a project within a specific period and compares it against the project plan. Project managers use status reports to keep stakeholders informed of progress and monitor costs, risks, time and work. 

 

 The work that’s been completed 

 The plan for what will follow 

 The summary of the project budget and schedule 

 A list of action items 

  Any issues and risks, and what’s being done about them 

 

 Frequency of the project progress reports can be varied based on the nature of the project and stakeholder requirements. For most projects weekly and monthly progress reports are submitted to different stakeholders. Progress reports can be documented and tracked using a suitable tool.

Change control documents [Mandatory]
A software change request document should be filled out when a change needs to be made to a software system. It should detail the person and department requesting the change, nature of the change requested, why it is needed and how it will affect other parts of the system. It should be approved by relevant stakeholders based on the agreed change control process for the project. A change request can be made during the implementation process before the software gets into production or can be requested during the life of the software as the needs of the institution evolve.

Software support issue logs and reports [Mandatory]
During the life of the software users may raise support requests based on issues encountered while using the software.  A support issue log is used to track such requests and includes details of the requester, date raised, details of the issue, analysis of the issue and action required, issue classification based on impact  and resolution status of the issue (open or closed). Support reports can then be generated showing a summary of issues raised during a period of time and their status which can be used to assess the effectiveness of the support process. Support Issue logs and reports can be documented through a suitable help desk tool