Standard operating procedures for software development

Blog Project Plan Standard operating procedures for software development

Standard operating procedures for software development

  • March 6th, 2020

  • Project Plan


This describes the process for managing software projects within the company from requirements development through to the delivery and maintenance of the project results. These projects include internal projects and projects are done for the end customers.


This SOP is to be applied to all software development projects.


  • Software Development – Activities that produce or enhance software and its documentation, including the testing and distribution of software that is developed.

  • Project – A software development activity that occurs within a specific timeframe and produces specific, documented results.

  • Project Manager – The individual who has been assigned primary responsibility for the management of the project.

  • Customer – The person or entity for whom the project is performed.

  • Deliverable – The project results to be delivered to the customer.

  • Requirements – A list of expected results for the project, stated as the minimum functionality and performance that is acceptable.

  • Task – A software development activity, intended to satisfy a portion of the requirements, which is assigned to a developer.

  • Developer – A programmer who has been assigned a task for the project.

  • Peer Developer – A programmer who has not been assigned a task, but is able to perform code review, testing, and other quality assurance functions.

  • Issue Tracking System – A system for recording tasks and software bugs, and which allows the progress of these items to be tracked.

  • Pivotal Tracker – The web-based issue tracking system.

  • Codacy – The web-based code review system.


Software requirements

Each project must have a software requirements document that describes the expected functionality, the interface, and any regulatory constraints for the software.

This document will be revised during project development by mutual agreement of the project manager and the customer, in consultation with the developers who are working on the project.

  • The initial requirements document should be completed within one month of project initiation.

  • Mandatory sections for the requirements document are as follows:

    • Purpose.

    • Scope.

    • Definitions and Abbreviations.

    • Overview.

    • Intended Users.

    • Constraints (e.g. regulatory policies that must be adhered to).

    • Requirements Specification (each item is to be numbered).

    • Design Details.

    • References.

    • Appendices.

  • The customer must approve the requirements document by either signing the document itself or by signing a contract to which the document is appended (internal projects do not require a signature).

  • All revisions to the requirements that occur after the initial signature must be done in accordance with contracts that are in force for the project and must be accompanied by signatures from both the project manager and the customer.

Design documentation

  • Elements of the design that are necessary in order to fulfill the software requirements, and cannot be changed without modifying the requirements, must be described within the requirements document itself.

  • The documentation must describe, as a minimum:

    • How the major components of the software interact with each other

    • How end-user data will be modified by the software

  • All design documents, including those that are not part of the requirements document, are to be filed with the requirements document.

Task management and issue tracking

The web-based application Pivotal Tracker is used to assign tasks to software developers, to keep track of ongoing software maintenance, and to record software bugs that have been discovered.

  • The project manager will assign tasks to software developers through Pivotal Tracker, where each project task should:

    • State the project name, and refer to the requirements document.

    • Give the date when the task is to be completed.

  • Developers may, where it improves their own ability to track their progress, add additional tasks to Pivotal Tracker that are sub-tasks of larger manager assigned tasks.

  • All bugs reported by the customer are to be entered into Pivotal Tracker, including:

    • The date when the bug was reported.

    • The software version number in which the bug was discovered.

    • The severity of the bug.

  • A weekly meeting must be held at which all active developers will report their progress on their tasks.

  • The developer must notify the project manager when they mark a manager-assigned task as resolved within Pivotal Tracker.

Implementation and unit tests

The developer is to implement the software and write unit tests that demonstrate that the software fulfills the requirements.

  • The source code for each assigned development task should be accompanied by a sufficient number of unit tests to allow the developer to demonstrate that the requirements have been met.

  • Unit tests should wherever possible, be able to run as a batch job without a user present.

    • The purposes of a unit test are to:

    • Ensure that data is processed as per the requirement specification.

    • Ensure that the software is stable, i.e. does not freeze or crash when presented with a range of inputs.

  • Allow continuous retesting of existing features as new features are added.

  • The source code for unit tests is to be stored with the project source code itself, in a subdirectory called “Testing”.

Code review

Code review is a quality assurance practice whereby one developer reads another developer’s source code.

  • Upon completion of a task, the tasked developer must request a code review via the Codacy web interface.

  • This request should be made to a peer developer, or to the manager.

  • If the manager is assigned a code review, then the manager may:

    • Perform the code review.

    • Re-assign the code review to a peer developer.

Internal release and user testing

The purpose of an internal release is to make the software available for testing.

  • The manager makes the decision for an internal release to be produced.

  • The developer compiles the software to create an application, and stores it in a location that can be accessed by others.

  • The project manager and the developer create a testing document together, which describes the software functions to be tested.

  • One or more people are given the testing document and the software application, perform the activities stated in the testing document, and record the results.

  • Depending on the results, new bugs may be added to Pivotal Tracker, and developer tasks previously marked as complete may be marked as incomplete.

Internal project auditing

Internal project auditing ensures that appropriate quality control measures have been applied to the software prior to delivery.

  • The project manager must verify that:

    • The software meets all of the requirements stated in the requirements document.

    • No constraints stated in the requirements document have been violated.

    • All project tasks have been completed.

    • Sufficient testing has been performed.

  • If any unmet requirements cannot be satisfied prior to the project deadline, the project manager must immediately communicate this fact to the customer and request either a modification to the project timeline or modification to the requirements.

Delivery of results

Delivery of the results may occur several times during a project, depending on whether delivery milestones are specified for the project, or whether the customer is to participate in the ongoing evaluation of the project results. The following steps must be followed whenever a delivery occurs:

  • The project manager assigns a version number to the software prior to delivery.

  • The project manager, or a developer to whom the project manager has assigned this duty, creates a deliverable package that contains the project results.

  • A copy of the deliverable package is stored at the Cain Core office for a period of not less than five years.

  • The project manager delivers the package to the customer.

  • The customer will perform acceptance testing on the software to ensure that it meets the requirements, and will communicate any concerns to the project manager.

  • The project manager will decide if additional deliveries or contractual amendments are necessary in order to address the concerns of the customer.

Software maintenance

Software maintainability refers to the ability to modify the software after delivery to the customer.

  • Software maintenance activities include:

    • Ongoing testing of the software after delivery.

    • Fixing bugs that have been found in the software.

    • Deploying the software on new platforms.

    • Re-using portions of the software in new projects.

    • Storage of the software and its documentation.

  • The project manager retains responsibility for maintaining the project for six months following delivery or longer if stipulated by the contract with the customer.

  • Following this six-month period, project maintenance becomes a shared responsibility of all qualified project managers.

  • Software is to be maintained for a minimum of 1 year, meaning that it must be possible to modify and re-deliver the project results within this period.


Project Manager / Project Coordinator

  • The initial draft of the requirements document.

  • Iterate drafts of requirements document with Customer.

  • Approval of requirements document.

  • Task assignment.

  • Reassignment of tasks with insufficient progress.

  • Schedule meetings.

  • Internal audit prior to delivery.

  • Delivery.


  • Iterate drafts of requirements document with Project Manager

  • Approval of requirements document.

  • Acceptance testing of delivered results.


  • Implementation and code testing.

  • Code documentation.

  • Reporting progress to Project Manager.

  • Assigning code reviews to Peer Developers.

  • Internal releases of software.

Peer Developers

  • Code reviews, when assigned.

  • User-level testing of software.