Systems Development Life Cycle (SDLC) Standard

PRINT DISCLAIMER: Official version of this document is accessible in the online policy library at https://policyoffice.ku.edu/. Printed copies may not reflect the most recent updates.

DOCUMENT TYPE:

Policy

PURPOSE:

The purpose of the Systems Development Life Cycle (SDLC) Standards is to describe the minimum required phases and considerations for developing and/or implementing new software and systems at the University of Kansas.

APPLIES TO:

University employees (faculty, staff, and student employees), students, and other covered individuals (e.g., University affiliates, vendors, independent contractors, etc.) that do any type of software or systems development work under the auspices of the University.

In the event a KU Department or Unit chooses to seek an exemption for reasons such as inability to meet specific points, tasks, or subtasks within the SDLC Policy or Standards, a SDLC Review Committee, comprised of representatives from across campus as designated by Information Technology, will convene in order to assess the specific merits of the exemption request(s) while still adhering to the main principles behind the SDLC Policy and Standards.

CAMPUS:

Edwards, Lawrence

POLICY STATEMENT:

All systems and software development work done at the University of Kansas shall adhere to industry best practices with regard to a Systems (Software) Development Life Cycle. These industry standard development phases are defined by ISO/IEC 15288 and ISO/IEC 12207. The minimum required phases and the tasks and considerations within these Systems development phases are outlined below. All of the following sub-tasks and considerations, as listed in the below respective standard development phases, are mandatory if the system or software development deals with Level 1 data in any way. Otherwise, the sub-tasks and considerations are recommended steps within the required standard development phases.

System Initiation

  • A need or opportunity is defined.
  • Concept proposal is made.
  • An initial feasibility study is conducted.
  • A project charter (if necessary) is formulated.

System Requirements Analysis

  • Analyze user needs and develop user requirements.
  • Create a detailed Functional Requirements Document.
  • Break down the system, process, or problem into discrete units or modules and utilize diagrams and other visual tools in order to analyze the situation or need.
  • Any security requirements must be defined.

System Design

  • This phase transforms the requirements into a Design Document.
  • The functions and operations of the system or software being designed are described in detail.
  • A risk analysis should be done between the System Requirements and System Design phases.
  • A final design review should be done to ensure the design addresses practicality, efficiency, cost, flexibility, and security.

System Construction (Procurement)

  • This phase entails the transformation of the detailed design documents into a finished product or solution.
  • Manual and automated testing at a unit or module level is done throughout this phase by the system or software developers. Security considerations are taken into account during testing.
  • A third-party product may be utilized as a system or software solution if it best fits the user requirements and is more practical from a budgetary and/or resource perspective. However, all of the next phases should be followed regardless of whether the solution was developed in-house or purchased.

System Testing and Acceptance

  • This phase should validate or confirm that the developed system or software meets all functional requirements as captured during the System Requirements Analysis phase.
  • Representatives separate from the development group should conduct internal Quality Assurance (QA) testing.
  • Representative(s) from the user group should conduct user acceptance testing.
  • Documentation during testing should detail and match testing criteria to specific requirements.
  • While unit and module testing should be done throughout the entire SDLC, this phase entails holistic testing of the finished product and the final acceptance testing by the user(s).
  • Final security assessment testing is now conducted.
  • Any problems identified during the previous phases must be resolved or remediated before implementation.

​​​​​​​​​​​​​​System Implementation

  • The finished, tested, and user-accepted system or software is moved from the testing environment to production.
  • All tools, code, or access mechanisms used for development or testing of the system or software must be removed from the software that is being moved into a production environment.
  • Any necessary user training should be done prior to or during this phase.

System Maintenance

  • This phase is the ongoing life of the system or software. Unlike the other phases, this phase only ends when the system or software is decommissioned.
  • A customer/user support structure and any other necessary operational support processes should be in place.
  • Any planned changes to the system or software should be scheduled, communicated, and documented.
  • Continuous security penetration testing is conducted on the system or software throughout its life cycle at regularly scheduled intervals.
  • Mandatory security testing is conducted when any major configuration or architecture change is made.

EXCLUSIONS OR SPECIAL CIRCUMSTANCES:

Exceptions to these standards and associated policy shall be allowed only if previously approved by the KU SDLC Review Committee and such approval documented and verified by the Chief Information Officer.

CONSEQUENCES:

Faculty, staff, and student employees who violate these University standards may be subject to disciplinary action for misconduct and/or performance based on the administrative process appropriate to their employment.

Students who violate these University standards may be subject to proceedings for non-academic misconduct based on their student status.

Faculty, staff, student employees, and students may also be subject to the discontinuance of specified information technology services based on standards violation.

CONTACT:

Office of the Chief Information Officer
1001 Sunnyside Avenue 
Lawrence, KS 66045
785-864-4999
kucio@ku.edu

APPROVED BY:

Chief Information Officer

APPROVED ON:

2009-12-01

EFFECTIVE ON:

2009-12-01

REVIEW CYCLE:

Annual (As Needed)

RELATED STATUTES, REGULATIONS, AND/OR POLICIES:

Systems Development Life Cycle (SDLC) Policy

Data Classification and Handling Policy

Data Classification and Handling Procedures Guide

Privacy Policy, General

Information Technology Security Policy

Information Access Control Policy

Acceptable Use of Electronic Information Resources

RELATED OTHER:

ISO/IEC 15288:2008 - Systems and software engineering (System life cycle processes)

ISO/IEC 12207:2008 - Systems and software engineering (Software life cycle processes)

DEFINITIONS:

These definitions apply to these terms as they are used in this document.

Design Document is a written description of a software product, that a software designer writes in order to give a software development team an overall guidance of the architecture of the software project.

Functional Requirements Document is a document or collection of documents that defines the function(s) of a software system or its components. A function is described as a set of inputs, the behavior, and corresponding outputs.

Industry best practices are well-defined methods that contribute to a successful step in product development.

Quality Assurance (QA) testing provides an objective, independent view of the software through various testing tools and methodologies, to allow the University to appreciate and understand the risks at implementation of the software.

Security Assessment testing utilizes automated and/or manual means to assess the security of an application or system. While similar to QA testing, the focus of this testing is to find potential security vulnerabilities and threats before full implementation.

University affiliates are the people and organizations associated with the University through some form of formalized agreement.

User acceptance testing is the process to obtain confirmation by a representative or representatives of the user group that the current software product meets the requirements as defined in the Systems Requirements Analysis phase of the SDLC.

User group is the end-user population of the software or system that is being developed or purchased; those that initiated the SDLC process or who will be actively utilizing the end product.

CHANGE HISTORY:

03/25/2025: Migration to TeamDynamix from Drupal.
01/26/2022: Updated contact section.
10/16/2014: Policy formatting cleanup (e.g., bolding, spacing).
10/08/2010: Updated to clarify System Testing procedure.

Was this helpful?
0 reviews
Print Article

Related Articles (7)

Acceptable Use of Electronic Information Resources
This policy outlines the expectations for the use of electronic information resources at the University of Kansas.
Data Classification and Handling Policy
Information is a valuable University asset and is critical to the mission of teaching, research, and service to Kansans.Determining how to protect and handle information depends on a consideration of the information’s type, importance, and usage.Classification is necessary to understand which security practices should be used to protect different types of information. The more protected the information needs to be, the more practices are required.
Data Classification and Handling Procedures Guide
This Procedures Guide for the University community was created to help you effectively manage information in your daily mission-related activities. Determining how to protect & handle information depends on a consideration of the information’s type, importance, and usage. These procedures outline the minimum level of protection necessary when performing certain activities, based on the classification of the information being handled. Classification is necessary to understand which security p
Information Access Control Policy
To ensure the security and integrity of university data and information assets as well as safeguard the information of its constituents. All Kansas University technology resources will adhere to a uniform access control standard and framework.
Information Technology Security Policy
This Information Security Policy (“Policy”) defines the security requirements that everyone who works or studies at KU Lawrence campus and all reporting units is expected to be familiar with and consistently follow. These security measures are set forth to avoid problems that affect the Confidentiality, Integrity, and Availability of information and systems at the University.
Privacy Policy, General
To set forth requirements regarding information entrusted to the University by the public and members of the KU community.
Systems Development Life Cycle (SDLC) Policy
The purpose of the Systems Development Life Cycle (SDLC) Policy is to describe the requirements for developing and/or implementing new software and systems at the University of Kansas and to ensure that all development work is compliant as it relates to any and all regulatory, statutory, federal, and /or state guidelines.