Software Development Life Cycle and Secure Procedure

Version 1.2

For Students, Faculty, Staff, Guests, Alumni

Purpose

The purpose of this procedure is to describe the development or implementation of new software and systems at Fordham University and to ensure that all development work is compliant as it relates to all University, regulatory, statutory, federal, or state guidelines.

Scope

This IT document, and all policies referenced herein, shall apply to all members of the University community including faculty, students, administrative officials, staff, alumni, authorized guests, delegates, and independent contractors (the “User(s)” or “you”) who use, access, or otherwise employ, locally or remotely, the University’s IT Resources, whether individually controlled, shared, stand-alone, or networked.

Procedure Statement

As stated in the Secure Software Development Life Cycle Policy, a software development plan should address the areas of:

  • Preliminary analysis or feasibility study,
  • Security risk identification and mitigation,
  • Software and systems analysis,
  • General design,
  • Detail design,
  • Development,
  • Privacy by design,
  • Quality assurance and acceptance testing,
  • Implementation, and
  • Post-implementation maintenance and review.

Functional Specification

  1. When the Software Services and Information Architecture (SSIA) executive management (i.e., Sr. Directors, Directors) approves the request, the process moves to the Requirements Analysis and Design Phase. User acceptance test cases should be part of the Requirements Analysis and Design Phase.
  2. A Business Analyst/Manager (BA) meets with the requesting parties to clarify the requirements, scope, and desired outcomes to write a Functional Specification.
  3. The Functional Specification outlines:
    • the project/task name,
    • stakeholders,
    • approvers,
    • delivery dates,
    • overview,
    • scope,
    • process and development assumptions, and
    • details the requirements (i.e., security, functional, technical).
  4. Requests less than a week in duration are identified and tracked in the SSIA-approved project management tool.
  5. Requests requiring software development are reviewed by the technical team reviews who review the technical requirements with the BA.
  6. The technical requirements are refined and adjusted to meet the University standards and technical capabilities.
  7. The BA and technical resources (if needed) sign off on the specifications.
  8. Each party will be required to complete their initial review and sign-off within 48 hours of receipt of the technical requirements.
  9. The directors may designate a delegate an appropriate technical representative.
  10. The BA meets with the requesting party to review the refined specifications, and the requesting party provides their sign-off.
  11. When sign-off is received, the functional and technical (if needed) resources begin the development of the solution.

Acceptance Testing

Involved parties (i.e., developers, BAs, and SMEs) to develop cases for the unit and acceptance testing to ensure desired outcomes, quality assurance, and regression testing to existing and integrated processes. See the User Acceptance Test Cases Template and Sample.

Development

  1. Applications development or configuration is done in the Implementation phase.
  2. The work takes place in a development environment based on the functional specification using vendor-provided, standard development, quality assurance, and unit testing procedures. 
  3. Once development has reached an agreed to milestone, the solution is deployed to a TEST/QA environment.
  4. The Software Development Life Cycle Checklist must be completed by the appropriate parties and reviewed by the project manager or BA for completeness. Follow the SAS Programming Guidelines and Best Practices.

 User Acceptance Testing

  1. The BA and SME coordinate user acceptance during the Implementation Phase.
  2. The BA and SME exercise the various test cases and coordinate with appropriate parties to address any issues and eventually sign-off on the solution based on the results.
  3. Scheduled meetings with the requesting office, project manager, and BA are used to keep status and updates on the progress and address any issues that may surface during testing.
  4.  Any changes due to testing results or necessary functional adjustments are applied in DEV, deployed to TEST following the previously mentioned steps, and amended supporting documentation if needed.
  5. Once the solution is completed and verified in TEST, it is moved to PROD on the scheduled date, following the University standards for change management per the Change Control Policy.

Sign-off

All parties Sign-off for the Functional Specification, SDLC Check List, and User Acceptance in the Acceptance Sign-Off Document.

Definitions

IT Resources include computing, networking, communications, application, and telecommunications systems, infrastructure, hardware, software, data, databases, personnel, procedures, physical facilities, cloud-based vendors, Software as a Service (SaaS) vendors, and any related materials and services.

Related Policies and Procedures

Implementation Information

Review Frequency: Triennial
Responsible Person: AVP, Software Services & Information Architecture
Approved By: CISO
Approval Date: October 6, 2016

Revision History

Version: Date: Description:
1.0 06/01/2016 Initial document
1.1 08/13/2019 Updated procedure statement
1.2 11/19/2021 Updated procedure statement

 Need Help?


Walk-In Centers

McGinley 229 | RH
Lowenstein SL19A | LC

View Our Walk-In Hours