Preaload Image

 

7.   System Development Policy

Software development requires a consistent process for designing and implementing applications. Implementation of consistent methodology, change of management, security policies, testing procedures, delivery, and maintenance strategies are key to managing expectations and costs associated with custom application development.

Purpose

The purpose of the Systems Development Policy is to describe the requirements for developing and/or implementing new softwares and systems at the University of Gondar and to ensure that all system development works comply with the standards.

Scope

This policy applies to all the University’s staffs and contractors that develop, deploy or support systems/softwares to support the University’s functions. However, this policy does not apply to software developments within the University for academic or educational purposes, for example, for students’ final year projects.

Policy Statements

  • The ICT Directorate shall be responsible for contracting system development projects planned to be implemented at UoG, except technology transfer projects;
  • The ICT Directorate shall be responsible for developing, monitoring, and maintaining all system development projects of the University. However, any staff member of the University can involve in developing a software/system for the University through internal (e.g. Technology Transfer Grants) and external grants;
  • All softwares under this policy shall comply with the Cyber Security Policy;
  • All developed or acquired softwares shall, where necessary, contain a provision for technical support and upgrades;
  • All the University’s Colleges, Departments and Units shall, where necessary,  make use of open-source softwares based on a risk-based assessment as referenced in the Cyber Security Policy;
  • All the University’s  Colleges, Departments, and Units undertaking the development or acquisition of any software shall ensure compliance with this policy and plan for end-user training;
  • All softwares developed in-house that run on production systems shall be developed according to the established processes and procedures which shall be developed and updated by the IAC (specified in the governance framework section);
  • All system development project proposals of the University shall be reviewed and recommended by the IAC;
  • The IAC shall review and recommend all completed system development projects of the University for handover to ICT Directorate;
  • At a minimum, system development project activities and tasks should address the following activity areas:
  • Project Initiation/Definition
  • Risk Assessment
  • Functional and Non-functional User Requirements,
  • Systems Design
  • System Development that includes coding or Customized Off-the-Shelf (COTS) Software Development/Acquisition
  • Quality Assurance
  • Documentation and Training
  • Systems Testing and Acceptance
  • Deployment, and
  • Maintenance.
  • The IAC shall review and recommend the flexibility to determine the means and details of methodology implementation with the provision that whatever development and delivery mechanism chosen addresses each of the major project elements listed above, is consistent, and is applied across the University;
  • All COTS and custom application production systems must have a role-based access control system to restrict system access privileges to users. Systems shall have designated access control administrators who manage system-wide privileges for user roles.  Should the access control administrator also be a regular user of the system, they shall have two role-based accounts–one for administrative access and one for user-based access;
  • There shall be a separation between production and non-production application environments to reduce the risks of unauthorized access or changes and aid in supporting methodology execution. The three operational environments are as follows:
    • Development: The development environment is predominantly accessed by application programmers creating and testing new functionality, functional enhancements, and bug fixes.  Developers have full control over this environment and it is not considered to be a “stable” code platform as active development is occurring within the logical instance. Once enhancements have been unit-tested and certified for quality assurance, they shall be moved to a stable testing environment. The following policy and procedure apply to the development environment:
      • Software development staffs shall not be permitted to have access to production systems and related data unless they are triaging a production outage;
      • Development systems must not contain sensitive or confidential information and shall be populated with test or dummy data;
      • Access to program source codes shall be restricted to authorized personnel and managed using enterprise configuration management and versioning software.
    • Test: This environment more closely mimics the production environment. Quality assurance and user acceptance test personnel operate in this environment to test enhancements and bug fixes scheduled for release into production. The environment is continually refreshed with test data and new functionality until such a point the release is deemed stable and ready for promotion into production. The following policy and procedure apply to the test environment before applications are promoted to production:
      • Application-program-based access paths other than the production access paths must be deleted or disabled;
      • Software debugging code must be removed;
      • Test User IDs and passwords must be removed;
      • All pre-production code shall be reviewed and certified prior to release to identify any potential coding vulnerability;
      • Code changes shall be reviewed by individuals other than the original code author and by individuals knowledgeable about code-review techniques and coding practices;
      • Results of testing are reviewed and approved by the ICT Directorate before release;
      • The requirement for code reviews applies to all custom codes (both internal and public-facing), as part of the change management promotion processes;
      • Code reviews and use-case tests shall be conducted by knowledgeable internal personnel or third parties;
      • Public-facing web applications are also subjected to additional controls to address on-going threats and vulnerabilities after implementation;
      • Development and systems staffs will move programs from development into production on a structured release schedule communicated to users and approved by the ICT Directorate;
      • Software developers shall not be permitted to move programs into the production environment directly unless expressly authorized by the ICT Directorate.
    • Production: This is the operational environment for the current release of the application. The production environment is subjected to stringent change management processes and procedures to limit risk and functional downtime to systems.
  • The three operational environments ensure that security and stability are rigorously maintained for the production system while development and test environments maximize software development productivity.
  • Data Ownership: All production systems must have designated program Data Owners and Data Custodians/Stewards for the critical information they process and act on.  Program owners ultimately control the release of new softwares into production-based on testing results.  The following applies to Program Data Owners:
    • Acceptance sign off is required to promote pre-release test code into production;
    • Test results shall be reviewed and provided prior to written approval;  moving new software or software updates into production;
    • Data owners shall also review and approve data migrations or system integrations from one application system to another.
  • Quality Assurance: Managing the quality of the delivery methodology is key to the success of application development execution. The following procedures shall be implemented (e.g. in relation to software delivery):
  • The development of all softwares shall be supervised and monitored by the IAC and shall include security requirements, a periodic independent security review of the environment, certified security training for software developers, and ad-hoc code reviews;
  • Applications shall be securely designed, coded, and maintained per industry-accepted security standards and comply with applicable statutory, regulatory, legal, and business requirements;
  • Data input and output integrity routines (i.e., reconciliation and edit checks) shall be implemented for application interfaces and databases to prevent manual or systematic processing errors or corruption of data;
  • Quality assurance procedures shall include systematic monitoring and evaluation of softwares developed, outsourced, or acquired by the ICT directorate;
  • Quality evaluation and acceptance criteria for information systems, upgrades, and new versions shall be established and documented;
  • Tests of the system(s) shall be carried out both during development and prior to acceptance to maintain security;
  • Test data shall be carefully selected, protected, and controlled;
  • IAC shall have a clear oversight capacity in the quality testing process with the final product being certified as fit for its desired purpose;
  • Procedures shall control the risks related to production software and hardware changes that may include applications, systems, databases, and network devices requiring patches, service packs, and other updates and modifications.  This includes the following:
    • Separate three-tiered operational environments shall exist with enforced accesses controls;
    • Discrete separation of responsibilities shall exist between development, test, and production environments;
    • Production data shall not be used for testing or development purposes;
    • Processes shall exist for the removal of test data and accounts before production systems become active (where appropriate).
  • Change control procedures shall exist for security patches and software modifications including:
    • Change Impact Documentation,
    • Authorized Change Approvals,
    • Pre-release functional testing to verify that the change does not adversely impact system security, and
    • Roll-back procedures.