Systems Development Life Cycle (SDLC) Standard
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.
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.
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.
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.
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.
Office of the Chief Information Officer
1001 Sunnyside Avenue
Lawrence, KS 66045
785-864-4999
kucio@ku.edu
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.
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.
