Software Development Lifecycle

Policy 14.10

Related Policies

I. Reason for Policy

The purpose of this policy is to define a standardized Software Development Lifecycle (SDLC) for the ITS team at Dakota State University. This ensures that software development and changes are performed securely, consistently, and in compliance with university requirements.
This policy also supports compliance with NIST standards, including:

• NIST SP 800-53 Rev. 5: System and Services Acquisition (SA), Configuration Management (CM), and System & Information Integrity (SI).
• NIST Cybersecurity Framework (CSF): Protect (PR.DS-7, PR.IP-3), Detect (DE.CM-8), and Respond (RS.MI-3).

Scope: This policy applies to all ITS development, including:

• SQL code, including stored procedures and queries that support production integrations and reporting.
• Microsoft SQL Server databases supporting .NET applications.
• PowerShell and other automation scripts.
• Web and console based custom applications.
• CMS and enterprise systems development.
• Requests, projects, and approvals managed in TeamDynamix (TDX).

II. Definitions

1. CIO (Chief Information Officer). Campus Chief Information Officer/Vice President of Technology is the department head for the DSU (Dakota State University) technology department.
2. Change Approver (TDX). ITS Leaders that are designated to authorize production deployments.
3. ITS. Information Technology Services. The official technology department for Dakota State University and subsumed departments.
4. SDLC. Software Development Lifecycle
5. Unit Testing. The process of testing individual units or modules of a software system to ensure they function correctly and meet the specified requirements, before integrating them into the larger system.
6. User Acceptance Testing: A process where actual end-users test the completed software system to validate that it meets their requirements and functions as expected in a real-world environment.

III. Statement of Policy

1. DSU ITS Leadership shall be responsible for developing and maintaining the SDLC policy and ensuring compliance.
2. All units/departments shall engage in software development activities in coordination with ITS and must adhere to the SDLC policy.
3. Faculty and Staff stakeholders shall propose a new system requirement to augment their capabilities in delivering services to the university via designated TDX request forms.
4. Developers shall build solutions, conduct unit testing, and document the code.
5. All systems and software development work done at DSU shall adhere to industry best practices with regards to Software Development Life Cycle.
6. DSU’s software development lifecycle policy can include up to nine phases. Not every system requires that each phase be subsequently executed and may be tailored to accommodate the unique aspects of a specific system.
   1. Initiation: The Initiation Phase of a project begins when stakeholders recognize the need to enhance a business process through information technology. The objectives of this phase are to
      1. Identify and validate an opportunity to improve the University's business outcomes or address a deficiency.
      2. Identify key assumptions and constraints for potential solutions.
      3. Recommend exploring alternative concepts and methods to meet the needs.
      4. Formulate a project charter to start the project (if necessary).
   2. Feasibility: The Feasibility Phase is the initial investigation, or brief study of the problem to determine whether the systems project should be pursued. ITS has implemented a Project Request workflow that helps evaluate the project and approve/deny it based on criteria including cost/benefit analysis, risk, and capacity.
      1. It shall investigate the practicality of a proposed solution.
      2. It shall identify the context through which the project addresses the requirements expressed in the Business Case.
      3. If the project is pursued, this phase will produce a project plan and budget estimates for future stages of development.
   3. Requirements Analysis Phase: This phase shall formally define the detailed functional user requirements using high-level requirements identified in the first two Phases. This phase can include any or all the following steps based on scope:
      1. Break down the system, process, or problem into discrete units or modules and utilize diagrams and other visual tools to analyze the situation or need.
      2. Any security requirements, such as data protection, access controls, or compliance with industry standards, must be clearly defined and documented to ensure that the proposed solution incorporates appropriate security measures from the outset.
      3. Complete business process reengineering of the functions to be supported, e.g., verify what information drives the business process, what information is generated, who generates it, where the information goes, and who processes it.
      4. Develop the test and evaluation requirements that will be used to determine acceptable system performance.
      5. Requirements and documentation shall be stored in the TDX project as attachments or “Cards” based on the project methodology chosen.
   4. Design Phase: During the Design Phase, the functional requirements identified in the previous phase are translated into a comprehensive Design Document or included in TDX card documentation where agile project methodology is used. This phase provides a detailed description of the functions, operations, and processes that the system or software being designed should contain.
      1. Determine the operating environment in which the system or software will function.
      2. Specify the hardware, software, and infrastructure requirements necessary for the successful operation of the designed solution.
      3. The Design Document shall define the major subsystems of the system or software, along with their input and output.
      4. If the new system involves migrating existing data, a conversion plan should be developed during this Phase.
      5. Developers shall create database schemas and ERD diagrams if necessary.
      6. A final design review shall be conducted to ensure that the design addresses practicality, efficiency, cost, flexibility, and security requirements.
   5. Development /Procurement Phase: The Development Phase involves translating the detailed requirements and design specifications into actual system components or code.
      1. Code shall be developed in approved non-production environments.
      2. As individual components or modules are developed, they shall undergo rigorous unit/module testing to ensure their usability and functionality.
      3. Code must be versioned and stored in approved repositories.
      4. Security testing should also be integrated into the overall testing process to identify and mitigate potential vulnerabilities or security risks in the developed components.
      5. After the individual components are developed and tested, all these components shall be integrated into a complete system.
      6. Integration testing is conducted to ensure the proper integration and interoperability of various components.
      7. When a third-party product best aligns with user needs and proves more cost-effective or resource-efficient, it can serve as a system or software solution.
      8. Adherence to all ensuing development phases remains mandatory, irrespective of whether the solution originated in-house or through procurement.
      9. Peer code reviews are encouraged for significant changes. If it is not feasible based on the skillsets available within the team, development managers can approve based on documentation review.
      10. Static Code Analysis (SCA) is not currently in use but will be a future compliance objective based on availability of funds to procure the software. Until implemented, developers will rely on manual review and secure coding checklists.
   6. Testing Phase: This phase shall validate or confirm that the developed system meets all functional requirements as captured during the Requirements Analysis phase.
      1. Faculty/Staff stakeholders conduct User Acceptance Testing (UAT).
      2. Test environments shall be used to conduct UAT.
      3. Documentation during testing should detail and match testing criteria to specific requirements.
      4. While unit and module testing are done throughout the entire SDLC, this phase shall conduct testing of the finished product.
      5. Final security assessment testing shall also be conducted in this phase.
      6. No code will be moved to production without UAT approvals stored in TDX tickets or projects.
   7. Implementation Phase: This phase involves: 
      1. An approved TDX Change request is required for any production deployment. That request shall include a description of the change, UAT results, the deployment plan, rollback procedures, and the scheduled change window.
      2. Installation of the necessary hardware and software components in the production environment.
      3. Integration of the system into the daily work processes and business functions it is intended to support.
      4. Comparison of the system's performance against the performance objectives and benchmarks established during the initial planning phase to meet the desired performance standards.
      5. Users shall be provided with the necessary training to effectively utilize the new system or software.
      6. Users shall be notified about the implementation timeline and any changes or updates that may impact their workflow.
      7. Removing all tools, code, or access mechanisms used for development or testing of the system or software, when moving the finished system or software from the testing environment to the production environment to ensure a secure and controlled production environment.
   8. Maintenance Phase: During this phase, the system or software remains in operation, supporting the organization's ongoing needs.
      1. Unlike other phases, this phase continues until the system or software is eventually decommissioned or retired.
      2. This phase shall have a robust user support structure and necessary operational support. Processes shall be established to ensure smooth system operation and address any issues or concerns that may arise during this phase.
      3. Any planned changes, updates, or modifications to the system or software should be carefully scheduled, communicated to stakeholders, and thoroughly documented for future reference.
      4. To maintain the system's security posture, continuous security penetration testing should be conducted at regular intervals throughout the system's lifecycle.
      5. Whenever a major configuration or architectural change is made to the system or software, mandatory security testing shall be performed to ensure that such changes do not introduce new security risks or vulnerabilities.
   9. Disposal Phase: When information systems become obsolete, or are no longer usable, it is important to ensure that they are disposed of
      1. Emphasis shall be given to proper preservation of the data processed by the system so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies for potential future access.
      2. Build a disposal / transition plan to ensure that all stakeholders are aware of future plans for the system and its information.
      3. Sanitize media according to the guidelines in NIST SP 800-88
      4. Dispose of hardware and software.

Exclusions

None

Exceptions

If an exemption from this policy is required, an SDLC Policy Exemption Form needs to be submitted, and it needs to clearly articulate the reason for the exemption. An operational risk assessment will be conducted by ITS to identify the risks associated with this exemption. All exceptions to this policy shall be approved by the CIO.

IV. Procedures (Major)

1. Separation of Environments: All development work must exhibit a clear separation between production, development, and testing environments. At a minimum, there should be a defined distinction between the development/testing and production environments, unless prohibited by licensing restrictions or granted an exception. This separation allows for better management and security of production systems while allowing greater flexibility in pre-production environments.
2. Restricted Access to Production: Where the separation of environments has been established, development and QA/testing staff must not be permitted access to production systems unless their respective job duties/descriptions absolutely require such access.
3. Removal of Development Access Paths: All application/program access paths utilized during development or testing, other than the formal user access paths, must be deleted or disabled before software is moved into the production environment.
4. Comprehensive Documentation: Documentation must be maintained and updated throughout all phases of development, from initiation through implementation and ongoing maintenance. Security considerations should be noted and addressed across all phases.
5. Development Oversight for Sensitive Data: All software and web applications that create, manage, use, or transmit Highly sensitive/Restricted data, as defined by the Data Classification Policy, must be developed and maintained solely by ITS. Other development work involving internal and public data may be undertaken outside of ITS, provided this policy standards are followed.
6. Continuous Improvement:
   1. Thes SDLC Policy will be reviewed annually.
   2. Metrics will be tracked (e.g. defect raters, change success rates).
   3. As resources allow, additional controls such as static code analysis and automated testing will be adopted.

V. Related Documents, Forms, and Tools

NIST 800-64 Revision 2 - Security Considerations in the System Development Life Cycle

NIST 800-37 Revision 2 - Risk Management Framework for Information Systems and Organizations

NIST SP 800-53 Rev. 5 - System and Services Acquisition, Configuration Management, System Integrity

NIST Appendix/Control Crosswalk

VI. Policy History

Adopted: 02/09/2026