Software SOP - 2019

STANDARD OPERATING PROCEDURE
SOFTWARE DEPARTMENT
DOCUMENT NO: CYB/SOFT/SOP/001/18

CLASSIFICATION : INTERNAL USE ONLY
DOCUMENT TYPE :
DOCUMENT CODE : CYB/SOFT/SOP/001/18
STANDARD OPERATING PROCEDURE Revision: 04 Issue: 02
Page 2 of 27
DEPARTMENT : SOFTWARE Date: JUNE 2019
Prepared By Date Signature

Godwin Agbon 20/02/2018
Godwin Agbon 24/06/2019
Reviewed By Date Signature

Okosodo Evans 26/06/2019
Joe Onwubuya 07/05/2018
Approved By Date Signature

Stanley Oduah 08/05/2018
Stanley Oduah 26/06/2019
Revision Number 04 Date of Issue: June 2019
This item is the property of CYBERSPACE for sole use by the COMPANY to carry out its operation. It shall not be transferred
to third parties without the written permission of the management .
DOCUMENT TYPE :
Page 3 of 27
Table of Contents
1.0 INTRODUCTION...........................................................................................................................2
2.0 SCOPE...............................................................................................................................................2
3.0 DEPARTMENTAL/PROCESS QUALITY OBJECTIVES.............................................2
4.0 INTERNAL COMMUNICATION..............................................................................................2
5.0 DEPARTMENT / OPERATION MEETINGS.....................................................................2
6.0 INFRASTRUCTURES NEEDED............................................................................................2
7.0 DOCUMENT ARCHIVING........................................................................................................2
8.0 PROCESS DESCRIPTION.......................................................................................................2
8.1 Project Management........................................................................................................6
8.2 Requirements Gathering & Analysis......................................................................9
8.3 System Architecture & Design.................................................................................11
8.4 Coding/Development....................................................................................................13
8.5 Software Testing and Deployment..........................................................................16
8.6 Sytem Support..................................................................................................................18
8.7 Change Request................................................................................................................20
8.8 Servers Monitoring..........................................................................................................22
8.9 Internal Requisitions.....................................................................................................25
9.0 APPENDIX I: ORGANOGRAM FOR SOFTWARE GROUP.........................................27
DOCUMENT TYPE :
Page 4 of 27
1.0 Introduction
Software department develops and implements a Quality management system to

demonstrate its ability to consistently provide software products and services that meet or
exceed customers’ expectation and regulatory body requirements, and to address customers’
satisfaction through the effective application of the system, including continual
improvement and the prevention of nonconformity in accordance with international
standards and best global industry practice.
2.0 Scope
The scope of these processes covers software products and activities being carried out by
Software Department, as contained in the following key milestones that represent
chronological steps we use for software development, deployment and maintenance.
 Request initiation (Request sources includes: Marketers, Software Group,

Direct Customer Request, Stakeholders, Others)
 Software Requirements
 Software analysis, planning and design
 Coding (Development)
 Testing
 Deployment
 System Support/Maintenance
3.0 Departmental/Process Quality Objectives
 To ensure that at least 80% of our projects are completed within each project
schedule timelines.
DOCUMENT TYPE :
Page 5 of 27
 To ensure that 80% of our software documents are in compliance with Capability
Maturity Model Integration (CMMI) standards templates.
 To create and implement at least one innovative solution yearly.
 To continually improve the quality of our products and services by ensuring that
customers’ complaints and incidents are resolved within 48hours.
4.0 Internal Communication
The department ensures adequate Internal communication and information flow using
various methods such as:
 Emails
 Telephones discussions
 One-on-one meetings
 Staff/team meetings
 Weekly/Monthly Reports
 And other communication means as applicable and as approved by the
management.
5.0 Department / Operation Meetings
Departmental meeting holds at least once in a month. The meeting could be

postponed to another day due to emergency presentation/meeting with a customer. It
is usually a brainstorming session, knowledge sharing or/and a forum for software
projects review.
Minutes of the meeting are fully documented and maintained in the department
intranet portal for future reference.
6.0 Infrastructures Needed
The infrastructures required by the department to achieve results are as follows:
DOCUMENT TYPE :
Page 6 of 27
 Good workspace and associated utilities (chair, tables, shelves, AC, etc.)
 Necessary hardware: PCs, Laptops, Servers, etc.
 Software: Microsoft Office Suite, Microsoft operating systems, Linux operating
systems and different development tools such as Visual Studio, SQL
Management Studio, Visual Studio Team Services and Android Studio, Flutter.
 Supporting services such as Internet and LAN.
7.0 Documents Archiving
Department projects artifacts and other softcopy documents are kept in SharePoint
repository. TFS and Visual Studio Team Services are used to keep application source codes
and other development logs.
Other hard copy documents such as filled job orders are kept in shelve. Electronic means of
approval shall be accepted where necessary (Electronic Copies)
8.0 Process Description
8.1 Project Management
Process Objective: This process is to ensure software projects are delivered to time, scope
and quality.
Process Inputs:
 Go-ahead mail from Business Managers
 Job Order / Clients Requirements
 Statement of Work (SOW)
Process Control: List the process controls e.g.
 Project Schedule
 Minutes of Meeting (MOM)
 Project Status Report
DOCUMENT TYPE :
Page 7 of 27
Process Owner: Project Manager
Related Documentation: List related documents for the process
 Minutes of Meeting (MOM)
 Project Schedule
 Project Plan
 Project Status report
Resources Needed:
 Manpower
 PCs
 Microsoft Office Tools
Process Output:
 Successful completion of project in line with the project schedule
 Satisfied Customer
Retained Documented Information:
 Archived emails
 Project management schedule
Key process indicators (PCI):
 Number of projects completed with Signed off
 Project Schedule Variance (80% completed within scheduled time)
DOCUMENT TYPE :
Page 8 of 27
Risks:
SN RISK CONTROL/MITIGANT Opportunity
1 Lack of sufficient - Phase implementation based Employment of

resources to on priority technically sound staff
implement the request to improve productivity
- Pull resources from other
project based on priorities
- Contract out or do joint

implementation with partner.
2 Failure of working - Have standby backups Discovery of more

tools electrically or durable working tools
otherwise
Process Steps:
SN PROCESS RESPONSIBLE
1 Initiate project Project Manager
2 Define Project Scope and create Project Plan Project Manager (PM),
Development Team
3 Determine technology and work tools to be Project Manager (PM),

used for the project Development Team
4 Allocate resources and assign teams to Project Manager (PM),

project. Development Team
5 Executing. The project manager ensures that Project Team

the project executed from start to finish
6 Monitoring and Controlling. The project Project Manager

manager tracks project deliverables, monitor
and report on the progress of the project
7 Perform project closing activities and send Project Manager
DOCUMENT TYPE :
Page 9 of 27
project closure report.
8.2 Requirements Gathering and Analysis
Process Objective:
 To ensure client’s needs and wants are appropriately and fully (100%) captured and
managed throughout software project life cycle.
Process Inputs:
 Job order / SOW/Email
 Identification of needs based market trend
Process Control:
 Evaluation and validation of the client’s requirements
 Track and monitor requirements
 PM reviews and ensured projects artifacts are updated
Process Owner:
 Project Manager
Related Documentation:
 Email for project initiation or invite
 Job order
Resources Needed:
 Manpower
 Work tools (software and hardware)
Process Output:
 Software Requirement Specification document (SRS)
 Requirement definition list in TFS
DOCUMENT TYPE :
Page 10 of 27
 Software specification document (SRS)
 Requirement definition list in TFS
Key process indicators (PI):
 All (100%) customer’s requirements (functional and non-functional) are complete,

consistent and well captured in SRS document.
Risks:
1 Incomplete, -Validation of requirement by NA

ambiguous or client sign off
contradictory
requirements
2 High Requirements -Ensure client sign off on new More revenue for the
Volatility requirements company
-Ensure subsequent sprint

product backlog captures the new
requirement
Process Steps:
1 Study and understand the customer Project Manager/SME

requirements
2 Conduct requirements elicitation using personal PM/ SME

interview, meetings, questionnaires, brainstorming
sessions, use case of business case analysis.
DOCUMENT TYPE :
Page 11 of 27
3 Study existing artifacts from customer systems PM/ SME
4 Identify the queries related to the requirements and PM/ SME

resolves the queries after discussion with the
customer
5 Prepare Requirements Specification Document, to PM/SME
fully capture and prioritize the requirements
6 Requirements validation: Review SRS with the PM/ SME

customers and get approval that the specified
requirements are valid, complete, and correct.
8.3 System Architecture and Design
Process Objective: To provide 100% transformation of requirement specifications into

detailed designs that provide functionalities of the system components and how they work
together to provide desired system.
Process Inputs:
 Software requirement specification (SRS)
 Requirement Definition List
 Statements of Work (SOW)/Job order
Process Control:
 Approved SRS
 Continuous joint design session
Process Owner: Team Lead
 Project Management Documents
 Software Requirement Specification
 Design Documents
DOCUMENT TYPE :
Page 12 of 27
Resources Needed:
 Project Plan Document
 Team Lead
 Project Team
 Internet / Networking facilities
Process Output:
 Technical Design Document (TDD)
- Design Document
- Updated Software Requirement Specification
Key Process Indicator (PI):
 100% representation of functional software requirements in the system design
Risks
1 Unclear or Incomplete The design document to be NA

Design Document validated against SRS by team
lead
2 Use of non-agreed To ensure compliance, there Ability to learn other

design methodology. should be approval of design design options
documents by head of
department
Process Steps
DOCUMENT TYPE :
Page 13 of 27
1 The team studies the SOW/Software requirement Project team

specifications (SRS) to understand the
requirements for the proposed system
2 Based on the requirements, identify and evaluate Project team
all the possible design possibilities using several
sketches and diagrams. The best design option is
selected
3 The selected design is developed in details with Project team
technical aspects of required functionalities
defined (Process Flow diagram, entity relationship
diagram, Database Schema, Use case Scenario,
Architecture Overview etc.).
4 Design document and system architecture Project team
diagram are produced
8.4 Coding / Development
Process Objective:
To ensure 100% implementation of design and software requirements specification to

produce fit for purpose functional application.
Process Inputs:
 Software requirement specification (SRS)
 Design Documents
Process Control:
 Approval of design specifications by stakeholders
 Code Review done by development lead
 Project and Milestones review meeting
 Maintaining risks logs
Process Owner:
 Development Lead
DOCUMENT TYPE :
Page 14 of 27
 Design Document
 Coding Standards
Resources Needed:
 Visual Studio Team Services (TFS)
 Microsoft Visual/Android Studio
 SQL Management Studio
 Development Team
 Team Lead
 Internet / Networking facilities
Process Output:
 Functional Application from Integrated Code
 Updated Code in TFS
Key process indicator (PI):
 Functioning application with 100% implementation of the design specification.
Risks
1 Unrealistic timelines for The project team should set a -Lessons learnt to
Coding realistic timelines for coding arrive at more
accurate timelines in
the future.
2 Resignation of key One person cannot be on a The chance to test the

developers project alone. Backup is always backup resource
available
3 Incomplete system design The project team should ensure NA

that the system design is done
in line with our agreed design
DOCUMENT TYPE :
Page 15 of 27
methodology.
4 Inconsistent code Team lead to ensure code review NA

is conducted at least once every
two weeks to ensure compliance
with company coding standards
5 Provision of backup tools like Discovery of more

Sudden malfunctioning
external hard drive and durable working tools
of development tools mandatory use of TFS.
PROCESS STEPS
1 Develop code/modules as per design document Developer
2 Ensure coding standards are followed while Lead Developer, Developer

developing code
3 Perform unit testing and fix defects as per test Developer

cases
4 Perform code review and points out defects for fix Lead Developer
if any
5 Perform smooth Integration of build components Developer

as provided in the design document
6 Ensure updated integrated codes are updated in Lead Developer, Developer

TFS
8.5 Software Testing and Deployment
Process Objective: To ensure that the system/solution is fit for purpose and severe bugs
does not exist in production (0% Error).
Process Inputs:
DOCUMENT TYPE :
Page 16 of 27
 Application Under Test (AUT)/Integrated Code
Process Control:
 Review of testing milestones during review meeting, including defects raised
 Ensure all identified internal defects are fixed to reduce number of external
defects that customer will report
 Ensure closure report is sent via email
Process Owner:
 Test lead
 Test Case Document
 Bug/Test Incident Report
 Test Summary/Closure Report
Resources Needed:
 Team Foundation Server
 Telerik /Appium Studio
 Test Lead
 Deployment Team
 PCs, Internet and LAN
Process Output:
 Quality Software Product
 Test summary report
DOCUMENT TYPE :
Page 17 of 27
Key process characteristics (TAT/SLA/PI):
- Quality Product delivered in line with the client’s requirements and project schedule
Risks
1 Insufficient availability of The SRS, Design use cases NA

required documents to the and flow must be available to
tester the test team beforehand.
2 Lack of proper documentation Requirement documents NA

should be legible clearly
/ambiguous requirements worded, and specific.
(Business Requirements,
Software Requirement
Specification, Use Cases)
3 Software builds/Application Development team should do Improvement in the

Under Test (AUT) is handed detailed unit testing. design component
over to the test team with an and unit testing
unanticipated high number of skills
internal bugs/defects
4 Deployed application does not Ensure UAT is signed off the learnt improve ways
cover full requirements of the customer before release and to deploy app to
customer go-live meet customers
expectation
PROCESS STEPS
1 Analyze Requirements using SRS Test team
2 Design test cases Test team
3 Execute test cases (Test implementation) Test team
4 Report incidents/bugs to development team. Test team
DOCUMENT TYPE :
Page 18 of 27
5 Fix Incidents/bugs Developer(s)
6 Do a retest and regression testing (validation of Test team

defect fixes)
7 Complete User Acceptance Testing Test team/Client
8 Close test and sign off (UAT) Test team/Client
9 Deploy solution/deliver product to client Deployment team
8.6 System Support
Process Objective: To ensure 99% smooth operations for clients using our software by
eliminating or reducing downtime.
Process inputs:
 Customer’s request
 Maintenance update
Process Control:
 Customer’s feedback
 Tester’s feedback
 Response to customers complains (via email/phone call)
Process Owner:
 Support staff
 E-mail/Ticketing Log/Issues Log
Resources needed:
 Support staff
DOCUMENT TYPE :
Page 19 of 27
 Workstation/Equipment
Process Output:
 Satisfied customer
 Acceptable working solution
Key process characteristics (TAT/SLA/PI):
 Response to client issues/request within 48 hours.
 Archived e-mails
 Issues Log
Risks
1 Insufficient resources Prioritize support activities Employment of

technically sound staff
to improve productivity
2 Work tools may Substitute work tools should be Discovery of more

malfunction available durable working tools
3 Improper training of Proper training of the trainer, use NA

end users of feedback form and validation
of the training content
Process Steps
1 Send complaints to support via e-mail/phone. Customer/Client
2 Support staff gets details from email Support Staff
3 Support staff offers direct level support based on Support/SME
DOCUMENT TYPE :
Page 20 of 27
details from the email.
If the case is resolved, send completion message

to client, otherwise escalate by raising change
request.
8.7 Change Request
Process Objective: To ensure client’s features request/issues are resolved within the agreed
turnaround time with the client.
Process inputs:
 Fault calls from clients
 Client’s request
 Continuous improvement suggestions
Process Control:
 Review of the changes to determine if it is major, minor or quick fix.
 Approval of change prior to implementation
Process Owner: Change Control Board (CCB)
 Request email
 Change request form
Resources needed:
 Change Control Board
 Deployment Team
 Work Equipment
DOCUMENT TYPE :
Page 21 of 27
Process Output:
 Satisfied customer
 Working Application
 Archived emails and other artifacts
 Filled change request forms
Key process indicators (TAT/SLA/PI):
 Updated application that meets customer’s new requirements fully
Risks
1 Lack of available - Phase implementation based - Employment of

resources to on priority technically sound
implement the request staff to improve
- Pull resources from other productivity
project based on priorities
2 Failure of working - Availability of alternative - Discovery of more

tools electrically or working tools and regular durable working
otherwise backup tools
3 Lack of proper - Ensure there is roll-back plan - NA

regression testing with full backup.
- Undergo thorough regression

and functional testing
Process Steps
1 Request for change received via email. Developer/Support Staff
2 Analyze the task to determine level of change Change Control Board (CCB)
DOCUMENT TYPE :
Page 22 of 27
3 Assign tasks to developer Unit Head
4 Consider purpose of change and its potential Change Control Board (CCB)
consequence to the QMS
5 Ensure availability of resources Unit Head
6 Implement Change Development Team
7 Conduct Regression testing Test Analyst
8 Deploy updated solution Deployment Team
9 Communicate changes and feedback to Developer / Support Staff

customers and other stakeholders
8.8 LTE Servers Monitoring
Process Objective:
 To ensure 98% availability of all LTE Billing Servers and Infrastructures for good
service delivery.
Process Inputs:
 Servers
 Network Equipment (Router, switch, etc.)
Process Control:
 Weekly Availability Report
 Visit to server room for physical routine check
 Availability of support personnel during maintenance period
 Application Monitoring Software (Porta-Monitor & Manage Engine)
Process Owner:
DOCUMENT TYPE :
Page 23 of 27
 Operation Personnel - Billing Unit
 LTE Server Infrastructure Spreadsheet
 LTE Server Infrastructure Architecture
Resources Needed:
 Manpower
 Application Monitoring Software (Porta-Monitor & Manage Engine)
 Server
 Network Equipment
Process Output:
 Up and running servers/services
 LTE Server Infrastructure Spreadsheet
 LTE Server Infrastructure Architecture design
 Availability Report
- Services Up and Running 24/7/365 days
Risks:
1 Non availability of - Provision of Generator and Discovery of another

stable power supply source of power supply
DOCUMENT TYPE :
Page 24 of 27
UPS
2 Non Availability of - Provision of LAN to access the Discovery of offline

stable internet server and services methods of application
deployment
3 Malfunction of cooling - Regular maintenance of the NA

system cooling systems
- Routine check of server room
Process Steps:
Local LTE Server

1 Monitoring of server continuously for Billing Engineer
availability
2 Billing Personnel login into Manage Engine Billing Engineer

each day to check for alarms for Capacity
Utilization thresholds.
3 If there is any resource over utilized, purchase Billing Engineer

request is made to upgrade the resource
4 Receive purchase new resource parts and Billing Engineer
installed on the servers within period stated in
Change request form
DOCUMENT TYPE :
Page 25 of 27
8.9 Internal Requisition
Process Objective: To ensure work items, project funds and/or infrastructure

resources are made available seamless at right time.
Process inputs:
 Requisition form from department (Via intranet/manual)
Process Control:
 Validation of employee (only valid staff can make requisition)
 Approvals from concerned members
Process Owner:
Staff who makes requisition
 E-mail
 Application on SharePoint
 Physical application on memo pad
Resources needed:
 Line managers, Requesting Staff
 Procurement Officer
 Store Officer
 IT / work equipment
Process Output:
 Approved request
 Requested Item
DOCUMENT TYPE :
Page 26 of 27
 Request Archive in SharePoint/Memo pad request archive in

Account/Procurement
 To ensure that all requested items are fully approved and are made available
seamless at right time.
Risks
1 Delay in requisition  Constant reminder of approval NA

approval task to those responsible for
it.
 Possibility of delegating
pending task to another
person
Process Steps
1 Requisition raised by a staff in the department by Requesting Staff

manually using the memo pad/form.
2 Approval of the request by hand signature Line manager
3 Second level approval of the requisition is done Head of Department
4 Third level approval of the requisition is done ED, DFA
5 Procurement received the request for processing Procurement Officer
6 Good Issues Note is signed to take delivery of the Requesting Staff, Store
resource from store Officer
DOCUMENT TYPE :
Page 27 of 27
9.0 APPENDIX I: ORGANOGRAM FOR SOFTWARE GROUP
Executive
Director
Head of
Department/
Manager
Service Delivery
Manager (SDM)
Unit Head, Unit Head,

Unit Head, Unit Head,
Financial Unit Head, Digital Project
Enterprise Technology Educational/Lea
Automation Advert/SocialCog Management/Qu
(FINTECH)/Billing rning
ality Assurance
Assistant Assistant Assistant Assistant Assistant

Manager, Senior Manager, Senior Manager, Senior Manager, Senior Manager, Senior
Programmers, Programmers, Programmers, Programmers, Programmers,
Assistant Assistant Assistant Assistant Assistant
Programmers Programmers Programmers Programmers Programmers

Software SOP - 2019

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Software SOP - 2019

Загружено:

Авторское право:

Доступные форматы

STANDARD OPERATING PROCEDURE

DOCUMENT NO: CYB/SOFT/SOP/001/18

Prepared By Date Signature

Godwin Agbon 24/06/2019

Reviewed By Date Signature

Joe Onwubuya 07/05/2018

Approved By Date Signature

Stanley Oduah 26/06/2019

Revision Number 04 Date of Issue: June 2019

Software department develops and implements a Quality management system to

 Request initiation (Request sources includes: Marketers, Software Group,

3.0 Departmental/Process Quality Objectives

4.0 Internal Communication

5.0 Department / Operation Meetings

Departmental meeting holds at least once in a month. The meeting could be

6.0 Infrastructures Needed

The infrastructures required by the department to achieve results are as follows:

7.0 Documents Archiving

8.0 Process Description

8.1 Project Management

 Go-ahead mail from Business Managers

 Job Order / Clients Requirements

 Statement of Work (SOW)

Process Control: List the process controls e.g.

 Minutes of Meeting (MOM)

 Project Status Report

Process Owner: Project Manager

Related Documentation: List related documents for the process

 Minutes of Meeting (MOM)

 Project Status report

 Microsoft Office Tools

 Successful completion of project in line with the project schedule

Retained Documented Information:

 Project management schedule

Key process indicators (PCI):

 Number of projects completed with Signed off

 Project Schedule Variance (80% completed within scheduled time)

SN RISK CONTROL/MITIGANT Opportunity

1 Lack of sufficient - Phase implementation based Employment of

- Contract out or do joint

2 Failure of working - Have standby backups Discovery of more

1 Initiate project Project Manager

3 Determine technology and work tools to be Project Manager (PM),

4 Allocate resources and assign teams to Project Manager (PM),

5 Executing. The project manager ensures that Project Team

6 Monitoring and Controlling. The project Project Manager

7 Perform project closing activities and send Project Manager

project closure report.

8.2 Requirements Gathering and Analysis

 Job order / SOW/Email

 Identification of needs based market trend

 Evaluation and validation of the client’s requirements

 Track and monitor requirements

 PM reviews and ensured projects artifacts are updated

 Email for project initiation or invite

 Work tools (software and hardware)

 Software Requirement Specification document (SRS)

 Requirement definition list in TFS

Retained Documented Information:

 Software specification document (SRS)

 Requirement definition list in TFS

Key process indicators (PI):

 All (100%) customer’s requirements (functional and non-functional) are complete,