Table of Contents

1 Overview .................................................................................................................................................... 3
2 Scope of this Document ........................................................................................................................... 3
3 Definitions .................................................................................................................................................. 4
4 Tools........................................................................................................................................................... 5
4.1 SharePoint ........................................................................................................................................... 5
5 Projects Managed Through the SDLC Process...................................................................................... 5
6 Prototyping ................................................................................................................................................ 6
7 Job Titles, Roles, and Conflicts of Interest............................................................................................. 7
8 The Full SDLC ............................................................................................................................................ 7
9 Phase 1: Horizon ....................................................................................................................................... 9
9.1 Process Step: Concept Proposal ......................................................................................................... 9
10 Phase 2: Plan ........................................................................................................................................... 10
10.1 Process Step: Vision & Scope / Functional Specification .................................................................. 10
10.2 Process Step: Project Plan ................................................................................................................ 11
10.3 Process Step: Review Functional Specs ........................................................................................... 11
10.4 Process Step: Design......................................................................................................................... 12
10.5 Process Step: Technical Specification ............................................................................................... 13
10.6 Process Step: Training Plan............................................................................................................... 13
10.7 Process Step: Functional & Structural Test Plans ............................................................................. 14
10.8 Process Step: Impact, Capacity & Monitoring Plans .......................................................................... 14
10.9 Process Step: Release Plan .............................................................................................................. 15
10.10 Process Step: Review Plans .............................................................................................................. 15
11 Phase 3: Develop..................................................................................................................................... 17
11.1 Process Step: Write Code .................................................................................................................. 17
11.2 Process Step: Unit Test ..................................................................................................................... 17
11.3 Process Step: Collect Unit Testing Results........................................................................................ 18
11.4 Process Step: Incremental Review .................................................................................................... 18
12 Phase 4: QA ............................................................................................................................................. 18
12.1 Process Step: Code Review .............................................................................................................. 19
12.2 Process Step: Build ............................................................................................................................ 19
12.3 Process Step: Release to Development ............................................................................................ 20
12.4 Process Step: Release to QA ............................................................................................................ 20
12.5 Process Step: Execute Test Plans ..................................................................................................... 20
12.6 Process Step: Training Doc ............................................................................................................... 21
12.7 Process Step: User Acceptance and Training ................................................................................... 21
13 Phase: Deploy.......................................................................................................................................... 23
13.1 Process Step: Release Approval ....................................................................................................... 23
13.2 Process Step: Release to Production ................................................................................................ 23
13.3 Process Step: Confirm ....................................................................................................................... 23
13.4 Process Step: Project Metrics ............................................................................................................ 24
14 Rapid SDLC Patterns .............................................................................................................................. 25
14.1 SDLC for Content Modifications and Tasks ....................................................................................... 25
14.2 SDLC for Production Data Change .................................................................................................... 28
14.3 SDLC for Release Management Wrapper ......................................................................................... 28
14.4 SDLC for Research ............................................................................................................................ 29
15 Other Process Patterns .......................................................................................................................... 31
15.1 Process Pattern for Account Changes ............................................................................................... 31
Appendix A: SharePoint Alignment with the SDLC .................................................................................... 32
1 SDLC Notes in SharePoint ..................................................................................................................... 32
1.1 Automated Notes ............................................................................................................................... 32
1.2 Manually Entered Notes ..................................................................................................................... 32
2 Project Status in SharePoint .................................................................................................................. 35
Appendix B: Roles and Responsibilities Throughout the SDLC ............................................................... 37
Appendix C: Documents Used Throughout the SDLC................................................................................ 41
Overview

A formal Software Development Life Cycle (SDLC) will provide the following benefits:

• Traceable progress toward completion of projects for audit compliance

• Shared methodology across the Information Systems team for identifying, designing, assuring quality, and
deploying technology projects
• Explicit and shared knowledge of a project’s progress toward completion using common and well-defined
language
• Reduction of the risk of project failure because risk factors are identified prior to code being written:
o technical and management issues
o realistic expectations of what the project will and will not accomplish are set
o resource needs and availability
o integration with multiple systems
• Documentation through all phases of the life cycle

While the SDLC will initially require extra work, once committed to practice, the technology team will enjoy a more
efficient process and a higher rate of success.

Scope of this Document

This document describes elements of UDC’s SDLC. It defines core terms, describes how the SDLC process
integrates with SharePoint as its tracking tool, and walks through a detailed narrative that all projects follow. The
document also covers topics related to Projects Managed through the SDLC Process; Prototyping; and, Job Titles,
Roles, and Conflicts of Interest.

The full process flow is designed to contain a finite number of “atomic” or self-contained process steps that flow in a
coherent manner. This design should allow for the removal of process steps in a manner that could itself result in a
coherent flow. In fact, after the full process is described, some rapid development patterns are identified that allow
for speedier completion of tasks like web site content modifications and other small tasks.

This document does not dictate the structures of the various components of the Information Systems teams
(Architecture, Infrastructure, Services, etc.). Rather it attempts to describe process steps in terms of staff acting in
specific Roles for completing each process step.

This document refers to several additional documents that are integral to successful completion of the SDLC process
flow. However, this SDLC document does not describe those documents in full detail. In some cases, templates for
these documents still need to be developed.

This document presupposes that End Users in the business initiate the SDLC process by making a request to
Information Systems; however, this document does not limit the manner in which such requests are initially recorded
and reacted to. In addition, it’s encouraged that members of the Information Systems team ought to themselves
propose projects, though a true project Sponsor in the organization must be identified prior to project initiation.

This document does not address prioritization of projects. Rather, ongoing prioritization is something addressed in
meetings between Business Analysts and members of the Business itself. Should competition remain unresolved,
the chain of escalation is through the Director of the Program Management Office, up to the Chief Information Officer,
then ultimately to the Chief Executive Officer.
Additional items that are outside the scope of this document include:

• Hardware testing performed by the IT Operations team.

• Configuration management by the IT Operations team.
• A dependency map of which applications rely on other applications and servers.
• Architecture and software development coding standards.
• Project Management process.
• Bug tracking and resolution process.

Definitions

Roles A Role identifies who is responsible for tracking, completing, or documenting a

process step in the SDLC. Other responsibilities for individuals placed in these roles
are documented in the various Technology teams’ operational manuals.
Process A repetitive and organized sequence of steps performed by more than one human
participant.
Process Step A Process Step is a specific set of actions to produce a quantifiable result.
Activities Activities are work actions to be performed during a process step.
Milestones Milestones are indicators that a significant point in the life cycle has been achieved.
Additionally, milestones may reflect completion of a process step. Some milestones
indicate the failure of a process step. In these cases, the project will return to some
previous step in the SDLC, or else a Technology Manager may elect to stop the
project altogether.
Approvals Approvals Indicate that a Process Step is completed successfully, approved by an
individual acting in an appropriate Role, and the project can then proceed through
subsequent steps in the SDLC.
Deliverables Deliverables are various artifacts, like documents and code, which are collected
throughout the SDLC. All project documentation is attached to SharePoint under the
Documents tab for each project.
AUDIT The abbreviations “AUDIT “used throughout this document is short for Audit.
Documentation detailing Audit requirements can be found in the Technology Services
Operations Manual.
Project A project is a non-repetitive activity that has a well-defined beginning and end, a clear
set of deliverables, involves the utilization of a significant amount of resources
(people and/or capital), and typically lasts more than 1 week.

For the purposes of UDC, the following database/environments correspond with environments mentioned here:

BILD Development

BPRD OA

PROD Production
Tools

SharePoint

The SDLC will be tracked through SharePoint for all applications projects, hosted at
http://sharepoint.udc.edu/Banner/default.aspx. This document only describes how the SDLC is tracked in
SharePoint. More detail on formalized use of SharePoint will be supplied in a separate document.

Recording SDLC Notes in SharePoint

For each Approval or Milestone action within the SDLC that is entered into SharePoint, it is very important to note a
specific comment related to that action. Auditors review the SDLC, Notes, Documents, History, Contacts, and
Display areas of random projects to determine the level to which Technology is AUDIT compliant. Therefore, all
entries in SharePoint require explicit and precise language because the ultimate audience is the Auditor, and the
Auditor is guided only by what is entered for each project. The Auditor cannot rely upon verbal narratives or
interviews with Technology staff to make a determination of compliance on a project-by-project basis.

Examples of Explicit Comments:

Action Comment
AUDIT Workflow Not Needed Uses Banner as supported interface for changing a student’s status to fix
the problem.
Approval: Functional Specification I approve the specification as articulated in the project Description
Approval: Functional Specification I approve the specification as articulated in Notes
Approval: Functional Specification I approve the specification as articulated in the Document titled
DocumentName.doc.
Milestone: Change Request Project suspended to allow re-write of Functional Specification.
Milestone: Failed Quality Assurance See defect report under Documents.

SharePoint Reviews

Technology Management will also conduct periodic reviews of the Approvals and Milestones in order to:

• Proactively determine AUDIT compliance

• Compile project delivery metrics
• Assess training needs in the event of project problems or failures during the Quality Assurance and User
Acceptance process steps.

Projects Managed Through the SDLC Process

The SDLC process is in part adopted as a means for controlling changes to systems and data.

In some cases the SDLC process is not followed. Whenever this occurs, the Technology Manager must add the
AUDIT Workflow Not Needed action in the SDLC Notes and include a specific comment justifying this
designation.

The SDLC process is not followed whenever:

 • Any interaction with systems and/or data occurs through a supported application interface. Supported
application interfaces are those interfaces that End Users can interact with directly, and that do not require
the intervention of Information Systems team members. Supported application interfaces are most often
graphical in nature, and deployed on an End User’s desktop machine. Banner INB/SSB, Luminis, Workflow
as well as Blackboard are all examples of these interfaces. Supported application interfaces are those
applications that have already been adopted by the organization and have been historically demonstrated to
reliably allow End User interaction with systems and/or data.

or

• The application being modified is not a member of the list below.

The SDLC process must be followed whenever one or more of the following occurs:

• change will be introduced into systems, data, and/or supported application interfaces because a Developer
is delivering a coded solution for any of the following applications (see Application Description Worksheets
for more specific information, including locations of Development, QA, and Production environments):
o Banner
o eCollege
o Blackboard
o Workflow
o Luminis
o Evisions
o BDMS
• change will be introduced into systems and/or data due to the scheduling of new automated jobs or changes
in the schedule of existing automated jobs
• a new application is being produced
• a new Banner Product, Module is being implemented (e.g. Banner Accounts Receivable, or Grants Modules
for Banner Finance)
• A new system Interface is needed.
• Upgrades to any systems listed above.

Prototyping

The SDLC process is in part adopted as a means for controlling changes to project scope after the Sponsor has
understood and authorized the utilization of Information Systems team resources. It is also in part adopted to control
costs associated with the full development of the business solution. As such, the SDLC process may employ the use
of prototyping:

• in the Vision and Scope phase as a means for determining the overall feasibility of initiating a project.
• in the Conceptual Solutions, Functional Specification or Design phases as a means for better isolating one
particular programming approach over another. Such comparison can be made to help identify project risks
and costs based upon difficulty of implementation. Such risks can then be mitigated early in the SDLC
process.

Prototyping is, at its core, a means for gathering information by simulating the production environment. It is most
often used when it is costly to follow a person’s activities in the normal work environment. Prototyping is often used
in conjunction with other tools (a camera to monitor end user activity or a program to monitor keystrokes and mouse
clicks) to collect empirical data rather than interview-based responses from users.
Prototyping can be costly, so a viable alternative is to use a low-fidelity representation for a project, such as
wireframes of a proposed user interface.

In the context of this SDLC, prototyping is a means for early Developer involvement in a project that helps identify
potential solutions at reasonable cost. Keep in mind, however, that prior to the End User authorizing the Functional
Specification, project scope can change. Therefore, prototyping at too early a stage and over too long a duration
introduces uncontrolled cost into the project definition process, so prototyping ought to be used judiciously.

Finally, Prototyping in this SDLC context should not be confused with a completely different type of SDLC. Some
Information Systems shops follow a rapid application development pattern centered on Prototyping. This pattern
engages Developer, End User, and Business Analyst in an iterative solution refinement process that ultimately spirals
to project completion while rapidly reacting to changes in project scope based upon direct user feedback. The UDC
SDLC does not support this alternate pattern.

Job Titles, Roles, and Conflicts of Interest

The reader should understand this document makes a clear distinction between Job Titles and Roles. As the
example below demonstrates, a staff person holding the Tech Services Associate job title can act in the roles of
Trainer, Business Analyst, and Project Manager on the same project. An Application Developer can engage in the
roles of Technical Lead and Developer at the same time. However, a conflict of interest is present if the same
Application Developer also performs his or her own code review. Therefore, some other individual on the Information
Systems team must do the Code Review process step.

As a general rule of thumb, a Conflict of Interests is present whenever one individual acts as both the author and the
approver of any one Deliverable for a given project, be it Documentation or Code.

Tech Services
JOB TITLES

Associate
Application Application Colleague System
Developer 1 Developer 2 Administrator

IT Operations Technical Lead/

ROLES

Trainer Business Analyst End User QA Analyst Architect Code Reviewer Release Manager Project Manager
Lead Developer

The Full SDLC

The following image displays the full SDLC process, with roles and phases.
 The Software Development Life Cycle
Trainer Business Analyst End User QA Analyst Architect IT Operations Technical Lead/ Code Reviewer Release Manager Project Manager
Lead Developer
Horizon
Concept Proposal Phase

Plan
Vision & Review Phase
Scope Functional Design
Specs
Functional Project
Specification Plan
Technical
Specification

Impact,
Functional &
Training Capacity &
Structural Release Plan
Plan Monitoring
Test Plans Plan

Review
Plans

Develop
Write Code Phase

Collect Unit
Incremental Review Testing Unit Test
Results

QA
Code Phase
Training Build
Review
Doc(s)

Release to
Dev

Release to
QA
Execute
Test Plans

User Acceptance and Training

Deploy
Release Release to Phase
Approval Prod Project
Metrics
Confirm
Phase 1: Horizon

The Horizon phase identifies a need or opportunity within a business unit or OIT. The Horizon phase is initiated by a
senior business stakeholder or from Technology leadership. Activities include:

• Preliminary feasibility analysis

• High-level requirements capture
• Business alignment
• Identification and assignment of planning resources
• Identification of Business Sponsor and Technology Manager

Trainer Business Analyst End User QA Analyst Architect IT OPerations Technical Lead/ Code Reviewer Release Manager Project Manager
Lead Developer
Horizon
Concept Proposal Phase

Process Step: Concept Proposal

During this step the Business Analyst captures the Sponsor’s high-level requirements, vision of the solution, scope
and limitations of the project, and the business context in which the finished project will operate.

Activities

• The Technology Manager enters the project into SharePoint. The following fields are filled out:
o Project status is entered in SharePoint as Horizon
• Technology leadership identifies the Project Manager, and the Business Analyst enters the Project Manager
under the Contacts tab for the project.
• The Business Analyst writes the Concept Proposal document:
o Works with the Stakeholder(s) and Project Manager as required
o May consult with the Developers as needed.

Deliverables

• Concept Proposal (Business Analyst)

• Prototype (optional) (Developer)

Approvals

• Business Analyst adds the Approval: Project Initiation action in the SDLC Notes for SharePoint
item.
• Sponsor adds the Approval: Concept Proposal action in the SDLC Notes.
Phase 2: Plan

The Plan phase comprehensively identifies the details of the project. Activities include:

• Estimate Resources, Budget and ROI. Obtain Executive approval if necessary

• Define deliverables, project dependencies, and development milestones.
• Sign-off: Requirements definition, deliverables list, milestones and end-user resource commitment

Trainer Business Analyst End User QA Analyst Architect IT Operations Technical Lead/ Code Reviewer Release Manager Project Manager
Lead Developer
Horizon
Concept Proposal Phase

Plan
Vision & Review Phase
Scope Functional Design
Specs
Functional Project
Specification Plan
Technical
Specification

Impact,
Functional &
Training Capacity &
Structural Release Plan
Plan Monitoring
Test Plans
Plan

Review
Plans

Process Step: Vision & Scope / Functional Specification

Using the Concept Proposal document as a guide, the Business Analyst creates a Vision and Scope document and
Functional Specification document. (Note: on projects of smaller size or duration, the Technology Manager will not
require a Vision and Scope document.) Whenever required, creation of the Vision and Scope document is a highly
collaborative effort between Business Analyst and project Sponsor. Although there is no explicit approval required,
the Business Analyst must obtain sufficient buy-in during the creation of the Vision and Scope before proceeding to
the Functional Specification. (Approval for Vision and Scope is implied in 10.3 Process Step: Review Functional
Specs where the Sponsor approves the Functional Specification.)

The Functional Specification document focuses on the business needs and targets Trainer, End User, QA, and
Developer as the audience. Sponsor approval of the Functional Specification forms a contract for project scope, and
allows the team to begin work on other planning documents.

Activities

• Business Analyst changes project status in SharePoint to Planning.

o Business Analyst enters Project Manager into SharePoint.
• The Business Analyst writes the Vision and Scope (including resource identification of people and dollars)
and/or Functional Specification.
o Works with the stakeholder(s), Technical Lead (if required) and Project Manager (if required)
• The Project Manager begins tracking the project
o An initial Project Plan document may be uploaded into SharePoint.
• The Project Manager identifies personnel who will be needed to complete the project. At a minimum, the
End User, Sponsor, QA Analyst and Trainer must be identified.
• The exercise of creating the Vision and Scope and/or Functional Specification allows the Business Analyst
to clearly identify the SDLC Design Pattern for the project, and could also allow an articulation of whether or
 not AUDIT Workflow is required for the project. The Business Analyst therefore makes the following
changes in SharePoint:
o (Optional) AUDIT compliance review status is identified if it is known at this time.
▪ If AUDIT is not required: the Technology Manager adds the AUDIT Workflow Not
Needed action to the release notes, and provides a detailed comment justifying this
designation.
o (Required) SDLC Design pattern is identified (either full project lifecycle, or one of the rapid SDLCs)

Deliverables

• Vision and Scope (optional) (Business Analyst)

• Functional Specification (Business Analyst)
• Prototype (optional) (Developer)

Process Step: Project Plan

Creating a Project Plan begins by identifying the project’s work breakdown structure (WBS), which divides the project
work into manageable tasks and logically orders them to ensure a smooth evolution between tasks. Specific
milestones are then identified in the WBS, the number of which depends on the size of the project. Milestones serve
to signify key events and to draw management attention to them. Once the WBS is defined, resources are assigned
to each element of work. Then, an estimate of the time required for each item to be completed is supplied. This plan
then becomes the schedule, which is adjusted through the life of the project as required, and which is used to track
progress. Project Plan tracking and maintenance is an activity which continues through the remaining phases of the
project. A core responsibility for the Project Manager, therefore, includes continual collaboration with the Release
Management team in order to accurately represent project delivery dates within the Release Calendar.

Activities

• The Project Manager collaborates with the Business Analyst, Technical Lead, and Developers to produce
the WBS.
• The Project Manager collaborates with the Business Analyst to identify development milestones.
• The Project Manager collaborates with the Business Analyst to assign resources to work elements.
• The Developers supply estimates of the time required for each work element.
• As work is completed, Developers report their completed work to the Project Manager, and supply estimates
on how much more time will be needed to complete an unfinished task in order that the Project Manager
may adjust the plan accordingly.
• The Project Manager communicates with all team members on the project in order to adjust the project plan
through the project lifecycle as required.

Deliverable

• Project Plan (Project Manager)

Process Step: Review Functional Specs

The Sponsor and Business Analyst review and agree to the content of the Functional Specification prior to any
additional planning effort. Hereafter, changes identified in scope require review and potential rewrite of these
foundational documents, or amendment to scope in a separate Change Request document.
Approval

• The Sponsor notes the approval in SharePoint SDLC Notes as Approval: Functional
Specification.

Process Step: Design

The Design Step identifies how the project deliverable will exist within the business. This is a highly collaborative
step that brings together team members acting in Architect, IT Operations Lead, and Technical Lead/Developer roles.
Moreover, different Technology teams will contribute a variable amount of resources depending on the size of the
project.

It’s important to note that Design activities can conclude by gathering evidence that it may be too costly
(either in dollars, man-hours, or impact to systems) to honor the Sponsor’s request. In these situations,
individuals engaged in the Design process can recommend that the Sponsor be informed, and that the
project itself return to the Concept Proposal phase.

During this step, the Design Worksheet is completed to identify development and production environments and their
configuration, system interdependencies, infrastructure requirements, architecture best practices, and other specifics.
All new systems require that an initial and complete Design Worksheet be created. Existing systems, however, will
already have Design Worksheets available. Most enhancements or small projects on existing systems need only
refer to the existing Design Worksheet. Where changes are made to existing systems, an abbreviated Design
Worksheet will be attached to the original worksheet as an addendum, listing only items that are different and
relevant to the new project.

Activities

For larger initiatives:

• The Technical Lead and Architect review the Functional Specification and are informed by additional context
contained in the Vision and Scope and/or Concept Proposal documents. The Technical Lead/Architect
identifies existing systems or proposes new systems, code, best practices, factories, or other assets that will
fulfill the business requirements stated in the Functional Specification. The supporting Infrastructure
dependencies and requirements are specified and additional risks and proposals for mitigation are identified.
This information is summarized in the Design Worksheet.
• The Technical Lead submits the Design Worksheet for Architecture team review to determine conformance
to Architecture Group principles.
• The Architect includes a recommendation to either Build or Buy based on Design Worksheet, Vision &
Scope, and Function Specification document data.
• The Architect may provide multiple potential solutions to consider, with high level costs vs. risk analysis
• The Project Manager continues refining the Project Plan and associated timelines as the Technical Lead
locks down effort associated with programming tasks.
• The Project Manager supplies all planning documents, including those related to design, to the Infrastructure
Group so they will be informed of system requirements and can confirm the envisioned design requirements.
• The Infrastructure Lead devises a Capacity and Monitoring Plan for the system and identifies metrics.
• The Infrastructure Lead identifies Server, Network, and Security impacts.

Smaller-sized initiatives presumably require less attention from Architecture and Infrastructure teams, leaving the
Services team in a nearly or completely self-sufficient mode until QA and deployment is required. For medium to
smaller initiatives:
 • The Developer reviews the Functional Specification and is informed by additional context contained in the
Vision and Scope document, and the Conceptual Design document. The Architect/Developer proposes a
solution(s) that is summarized in the Design Worksheet.
• The Developer submits the Design Worksheet to the Development Manager for the project. An Architect
from the Architecture team may optionally be consulted.
• The Project Manager continues refining the Project Plan and associated timelines as the Developer locks
down effort associated with programming tasks.
• The Project Manager may optionally request assistance from the Infrastructure team in order to help
determine application location and deployment assistance.

Deliverables

• Conceptual Design Document (Technical Lead/Architect)

• Design Worksheet (Technical Lead/Architect or Developer)
• Solution recommendation (Technical Lead/Architect)
• Prototype (optional) (Developer)

Approval

• Depending upon project size, the Technical Lead, Architect or Development Manager enters Approval:
Design Worksheet into the SDLC Notes in SharePoint upon review and acceptance of the Design
Worksheet.

Process Step: Technical Specification

The Technical Specification is a document required for large or complex projects; it supplies the technical details to
support the broad requirements identified in the Design Worksheet document.

Activities

• The Technical Lead documents results of the Design process in a Technical Specification document that
includes detail defining the programming tasks, resources and time, risks and mitigation, system design,
supporting infrastructure requirements, database and other system dependencies, etc. This is a living
document that will last through delivery. This is to include future development artifacts unknown at this
stage.
• The Project Manager documents all programming tasks and time estimates for completion of each task in
the Project Plan.

Deliverables

• Technical Specification (Technical Lead)

Approvals:

• Depending upon project size, the Technical Lead, Architect or Development Manager enters Approval:
Technical Specification action in the Release Notes.

Process Step: Training Plan

The Trainer uses the Functional Specification as the guide for creating a Training Plan document.
Activities

• Trainer writes the training plan and uploads the document into SharePoint.

Deliverables

• Training Plan (Trainer).

Approvals

• Business Analyst approves the training plan.

Process Step: Functional & Structural Test Plans

The QA Analyst uses the Functional Specification as a guide for creating the Functional Test Plan. In addition,
informed by the Technical Specification and the inner workings of the technical solution, the QA Analyst designs a
test plan for measuring performance characteristics of the solution.

Activities

• QA Analyst writes the Functional Test Plan and uploads the document into SharePoint.
• The QA Analyst writes the Structural Test Plan and uploads the document into SharePoint.
• The Project Manager updates the project plan with QA tasks and associated time estimates for executing
the Functional and Structural test plans

Deliverables

• Functional Test Plan (QA Analyst).

• Structural Test Plan (QA Analyst)

Approvals

• QA Manager approves Functional and Structural Test Plans.

Process Step: Impact, Capacity & Monitoring Plans

Infrastructure is responsible for determining impact to servers, networks, and security. In addition, Infrastructure is
engaged to insure that appropriate capacity planning and monitoring will be in place upon delivery of the solution.

Deliverables

• Backup Plan (if needed) (IT Operations Lead)

• Server, Network, Storage, and Security report (IT Lead)
• Capacity Plan (IT Operations Lead)
• Monitoring Plan (IT Operations Lead)

Approvals

• IT Manager approves all planning documents

 • IT Manager notifies Architecture.

Process Step: Release Plan

The Release Manager uses the Functional Specification as a guide for creating an initial draft of the Release Plan.

Activities

• Release Manager writes a draft of the Release Plan and uploads the document into SharePoint.

Deliverables

• Release Plan (Release Manager).

Process Step: Review Plans

The Technology Manager reviews and insures that the various foundational documents and planning documents are
in order and ought to result in the desired project outcomes. The Technology Manager then authorizes the Business
Analyst to engage the Sponsor and reviews the Functional Specification, Training Plans, and Functional Test Plan
documents.

Activities

• At the beginning of this step, the Business Analyst changes the project status in SharePoint to Spec /
Approval.
• The project Sponsor reviews the Functional Specification, Training Plan, and Functional Test plan
o If the planning documents are not approved:
▪ If the Sponsor still wants the project to progress: then the Business Analyst corrects any
deficiencies in the Functional Specification, and allows the Trainer and QA Analyst to
make changes to their foundation documents as well, until the Sponsor approves. No
notation is made in SharePoint as the planning documents are being modified.
▪ If the Sponsor chooses not to re-engage Information Systems in the project, then the
Business Analyst marks the project status on SharePoint as Suspended or Cancelled
(as directed).
• The Technology Manager and Development Manager review all deliverables and determine if the project is
ready to move to the Develop Phase.

Approvals

• The project Sponsor approves the Functional Specification, Training Plan, and Functional Test plan
• The Sponsor notes the approval in SharePoint SDLC Notes as Approval: User Acceptance
(Planning).
• The Technology Manager enters Approval: Proceed to Develop Phase in SharePoint. Changes
made after this approval can be tremendously expensive, and the articulation of any change must be
formally included in a Change Request document.

Milestones

• By the end of this step, the Business Analyst changes the project status to:
o Execution, if the Sponsor and Technology Manager indicate that the project will proceed.
o Suspended, if the Sponsor or Technology Manager indicate the project needs re-definition or
change.
o Cancelled, if the Sponsor indicates the project is no longer needed.
Phase 3: Develop

Development is characterized by the engagement of Developers for coding the solution based upon details provided
in the Functional and Technical Specifications. The QA Analyst collects the results of Developers unit testing in order
to adjust functional and structural test plans as the solution is being coded. The Project Manager manages changes
to timelines and tasks in the Project Plan based upon the daily progress made by the Developers. For large projects,
The Business Analyst and End User will conduct incremental reviews as development occurs to ensure that the
requirements are being correctly implemented, and to confirm the vision of the End User.

Trainer Business Analyst End User QA Analyst Architect IT Operations Technical Lead/ Code Reviewer Release Manager Project Manager
Lead Developer

Project Develop
Write Code Plan Phase

Collect Unit
Incremental Review Testing Unit Test
Results

Process Step: Write Code

Developers engage in writing code in order to solve the identified business needs. The Technical Lead then hands off
unit tests for QA

Activities

• If, prior to this process step, the AUDIT Compliance requirement was not known, then it must be articulated
before this step can proceed. The Business Analyst therefore makes the following changes in SharePoint:
o (Required) AUDIT compliance review status is identified.
▪ If AUDIT is not required: the Technology Manager adds the AUDIT Workflow Not
Needed action to the release notes, and provides a detailed comment justifying this
designation
• The Business Analyst updates the project status as Execution.
• Developers write code
• Project Manager updates the schedule as communicated by the Technical Lead

Deliverables

• Code (Developers)

Process Step: Unit Test

Developers perform unit tests of their code as solutions and/or components of solutions are completed.

Activities

• Developers perform units tests on code and document results

• QA Analysts review unit test results and update functional and structural test plans as appropriate.
Deliverables

• Packaged Code Release (Developer)

• Code Review Instructions (Developer)
• Code Promotion Instructions, if required (Developer)
• Supplemental Testing Instructions (Developer)
• Supplemental Training Instructions, if required (Developer)

Process Step: Collect Unit Testing Results

QA Analysts collect unit-testing results and update functional and structural test plans as appropriate. The type of
information passed from the Developer to the QA Analyst should not include specific data that might bias the
orientation of the QA Analyst and affect the validity of quality assurance.

Activities

• QA Analysts review unit test results and update functional and structural test plans as appropriate.

Deliverables

• Updated Functional Test Plan (QA Analyst)

• Updated Structural Test Plan (QA Analyst)

Process Step: Incremental Review

For very large projects it may be appropriate to give the End User the opportunity to approve development
incrementally to be sure work is aligned with specifications. Additionally, end users may require standalone functional
elements of the system, complete with the front-end user interface (UI) and dummy data, in order to confirm the UI
flows as envisioned.

Activities

• Business Analyst communicates with End User and controls expectations throughout the incremental
review.
• End User reviews and approves development.
• Trainer may attend for better understanding.

Phase 4: QA

Code Reviewer, Release Manager, QA Analyst, Trainer, and End User participate in assuring that the solution
provided meets expectations from a functional perspective as well as from an overarching systems stability
perspective.
 Trainer Business Analyst End User QA Analyst Architect IT Operations Technical Lead/ Code Reviewer Release Manager Project Manager
Lead Developer

Project Develop
Write Code Plan Phase

Collect Unit
Incremental Review Testing Unit Test
Results

QA
Code Phase
Training Build
Review
Doc(s)

Release to
Dev

Release to
QA
Execute
Test Plans

User Acceptance and Training

Process Step: Code Review

The Code review process maintains consistency, best practices, and assists in early detection of code that may have
an adverse effect on existing and ancillary applications. Project code review is a proactive way to fix bugs, and
defects early in a software product development cycle.

The person performing the code review role cannot be the same person who developed the code.

Activities

• At the beginning of this phase, the Business Analyst marks the project Status in SharePoint as Waiting
for Code Review.
• The Code Reviewer examines for defects, both in implementation and design, and tracks actions in the code
review worksheet (for large projects) or in the Notes section (for small projects).

Deliverables

• Code Review Worksheet (Code Reviewer)

Approvals:

• Upon completion of the code review, the Code Reviewer creates a note in SharePoint stating Approval:
Code Review, and states exactly where the code review notes are (Documents or Notes).

Process Step: Build

For some technologies where a code compile is not required, this process step will be omitted.

Activities

• The Release Manager compiles the code and checks for errors.
Deliverables

• Compiled code (Release Manager)

Process Step: Release to Development

For some technologies where a code compile is not required or no isolated Development environment exists, this
process step will be omitted.

Activities

• Release Manager communicates with IT operations to determine readiness, especially on new or large
projects.
• The Release Manager deploys the application in the shared Development environment, when appropriate
for the given technology.

Deliverables

• Application code deployment in Development environment. (Release Manager)

Process Step: Release to QA

For some technologies where a code compile is not required or no isolated QA environment exists, this process step
will be omitted.

Activities

• At the beginning of this phase, the Business Analyst marks the project Status in SharePoint as Waiting
for QA Release.
• The Release Manager deploys the application in the QA environment, and reviews any dependencies. He
or she changes the project Status to Released to QA.

Deliverables

• Application code deployment in QA. (Release Manager)

Process Step: Execute Test Plans

During this step, the QA Analyst executes the tests identified during the planning phase. Either the QA Analyst will
certify that the deliverables have been met according to expected results articulated in the test plan, or the QA
Analyst will reject the project and request further project definition and/or programming resolution.

Activities

• At the beginning of this phase, the Business Analyst marks the project Status as Quality Assurance.
• If the project does not meet the requirements of the test plan, the QA Analyst will enter a Milestone:
Failed Quality Assurance action in the Release Notes. The QA Analyst will return the project to the
Technical Lead or Developer for defect resolution. If any planning documents change as a result, then
Architecture and IT Operations are notified, and re-engaged in the Planning process.
Deliverables

• Test plan results (QA Analyst)

• The Final Release Date is set (Project Manager)
• QA Analyst notifies IT Operations of any performance data, and requests network tests when necessary.

Approvals:

• If the project passes the QA process step, the QA Analyst enters an Approval: Quality Assurance
action into the SDLC Notes and the project continues through subsequent steps in the SDLC.

Process Step: Training Doc

In this step the Trainer creates the user training documentation. This process step will be omitted in many cases.

Activities

• The Trainer delivers a final Training Document or End User Manual to end users who will be interacting with
the application. Subsequent training could occur in a formal course or informally through the delivery of the
documents at the beginning of the Deploy phase.

Deliverables

• Training Document (Trainer)

Process Step: User Acceptance and Training

The Business Analyst, Trainer, and/or QA Analyst engage the project Sponsor. Where training is required, training is
given to the business users. In any event, the Sponsor will be asked to approve the results of the project.

It’s important to note that User Acceptance and Training activities can conclude with some aspects of the
project remaining unfulfilled or off target as promised in the Functional Specification. In these situations,
individuals engaged in the acceptance process can recommend that the project itself return to the Write
Code phase so that any issues can be fixed. As an additional subtlety, if the project does deliver the
requirements asserted by the Functional Specification, then the individuals engaged in the acceptance
process can elect to fill out a Change Request form, and incur the cost associated with potential change in
Design.

Activities

• The QA Analyst shares the results of testing with the End User
o If bugs are present, the End user may decide to either:
▪ Reject the deliverable and move the project back to the Develop phase, or
▪ Accept the deliverable and release with a “known bug.”
• The Sponsor and stakeholders are given access to the system in order to approve the new functionality.
o If the user does not approve the project, it is possible that a Change Request will result.
Approvals:

• If the Sponsor approves, the Sponsor adds an Approval: User Acceptance (QA) to the Release
Notes of SharePoint item, with specific reference to the stakeholder and verifiable reference, such as the
text of an email message.
• A Technology Team manager adds an Approval: System Change action to the Release Notes.
Phase: Deploy

During the deploy phase the team deploys the core technology and site components, stabilizes the deployment,
transitions the project to operations and support, and obtains final customer approval of the project. Stabilizing
activities may continue during this period as the project components are transferred from a test environment to a
production environment.

Trainer Business Analyst End User QA Analyst Architect IT Operations Technical Lead/ Code Reviewer Release Manager Project Manager
Lead Developer

Project Deploy
Release Release to Plan Phase
Approval Prod
Project
Confirm Metrics

Process Step: Release Approval

The IT Operations team reviews project deliverables to insure system changes will not compromise uptime.

Activities

• The IT Operations Lead performs a final review of documentation for the project, including QA results and
performance test results. He or she also insures that hardware and firewall requirements are implemented,
and that IT Operations staff is ready for production release.

Approvals

• The IT Operations Lead adds an Approval: IT Release Approval action into the SDLC Notes.

Process Step: Release to Production

In this Step, the solution is released to the live production environment.

Activities

• At the beginning of this phase, the Business Analyst marks the project Status as Waiting for
Production Release.

Milestones:

• Upon step completion, the Release Manager changes the project Status to Released to Production.

Process Step: Confirm

The confirm step is final confirmation that the product is working as expected in the production environment.
Approvals:

• The QA Analyst confirms that the project is functioning in the Production environment, and adds an
Approval: Confirmed in Production action to the Release Notes.
• The project Sponsor confirms that the project is functioning in the Production environment, and adds an
Approval: User Acceptance (Production) action to the Release Notes.
• The Business Analyst marks the project Status in SharePoint as Completed.

Process Step: Project Metrics

Project metrics are delivery measures that identify the final output of a project as compared to the planning estimates.
Project metrics provide statistics by which the Technology Services Group may identify and track the Service Level
Agreement with the business. Projects will be measured by the following metrics:

Metric Description
Requirements Traceability Requirements Traceability measures whether the agreed upon scope of the
project was delivered as expected.
Schedule Adherence Schedule Adherence measures the percentage of milestones completed in
agreement with the schedule.
Budget Adherence Budget Adherence measures the project’s adherence to the established budge

Details on project metrics and scoring techniques will be detailed in the Technology Services Operations Manual.

Activities

• The Project Manager records project performance and supplies a standard score for each metric on the
project.
Rapid SDLC Patterns

The SDLC Pattern for each project is identified by a Technology Manager within SharePoint. As new patterns
emerge that differ from the “Full” pattern, they will be added to this section of this document.

SDLC for Content Modifications and Tasks

The SDLC for Content Modifications and Tasks is for small changes that are commonly made to a variety of UDC’s
web sites, and for “mini-projects” that are completed in a relatively short period of time.

The Software Development Life Cycle

Trainer Business Analyst End User QA Analyst Architect IT Operations Technical Lead/ Code Reviewer Release Manager Project Manager
Lead Developer

Horizon
Phase

Plan
Functional Specification Phase

Review
Functional Design
Specs

Functional
Release Plan
Test Plans

Review
Plans

Develop
Write Code Phase

Collect Unit
Incremental Review Testing Unit Test
Results

QA
Code Phase
Build
Review

Release to
Dev

Release to
QA
Execute
Test Plans

User Acceptance

Deploy
Release to Phase
Prod

Confirm

Process Steps

• AUDIT compliance review status is identified.

o If AUDIT is not required: the Technology Manager adds the AUDIT Workflow Not Needed
action to the release notes, and provides a detailed comment justifying this designation.
• The SDLC Design Pattern for SharePoint item is identified as Content Modifications and Tasks.
 • Project Status is marked as Planning. Depending upon the complexity of the change, the Functional
Specification may be located in SharePoint Description for easily summarized work effort, Notes for
moderate work effort, or Documents as a rich text document.
• The End User reviews the Functional Specification and adds the Approval: Functional Specification
action to the SDLC Notes.
• Design will occur only for complicated web site modifications; i.e., where wholesale page layout
changes occur, a Design process step may be required. In such a case the Design Worksheet needs to
be completed by the Developer and an Approval: Design Worksheet action needs to be added to
SharePoint by the Technical Lead. If either a Content Modification or Task requires consultation with an
IT Lead or an Architect, then the project is likely a better candidate for the Full SDLC.
• The QA Analyst creates a brief Functional Test Plan.
• The Release Manager tracks the modification at least enough to know if the modification or task can
participate in a partial code promotion or if it requires a full application build to be released. If the
Release Manager determines that a full application build is required, then the task should likely go
through the Full SDLC process.
• Project Status is changed to Spec/Approval. The End User approves work summary and design by
adding the Approval: User Acceptance (Planning) action to the SDLC Notes.
• Project Status is changed to Execution. The Develop Phase follows the pattern for all status changes,
approvals, milestones, and documents articulated in the Full SDLC process, except that any Trainer or
Project Manager involvement is omitted.
• Project Status is changed to Waiting for Code Review. The QA Phase follows the pattern for all status
changes, approvals, milestones, and documents articulated in the Full SDLC process, except that any
Trainer or Project Manager involvement is omitted.
• Project Status is changed to Waiting for Production Release. The Deploy Phase follows the pattern for
all status changes, approvals, milestones, and documents articulated in the Full SDLC process, except
that any Project Manager involvement is omitted.

Approvals

• Approval: Functional Specification (End User)

• Approval: Design Worksheet [optional] (Technical Lead/Architect or Development Manager)
• Approval: User Acceptance (Planning)
• Approval: Code Review (Code Reviewer)
• Status Change: Released to QA (Release Manager)
• Approval: Quality Assurance (QA Analyst)
• Approval: User Acceptance (QA) (End User)
• Approval: System Change (Technology Manager)
• Status Change: Released to Production (Release Manager)
• Approval: Confirmed in Production (QA Analyst)
• Approval: User Acceptance (Production) (End User)

Documents

• A rich text Functional Specification document will likely include screen captures and additional details about
how the layout, wording, or pictures on a web page or pages are to be affected. (Business Analyst)
• Conceptual Solution Design (Architect)
• Design Worksheet (Developer)
• Functional Test Plan (QA Analyst)
• Release Plan (Release Manager)
• Code Review Instructions (Developer)
• Code Promotion Instructions (Developer)
• Supplemental Testing Instructions (Developer)
• Code Review Worksheet (Code Reviewer)
SDLC for Production Data Change

Production Data Changes are those data changes that occur directly in a production database environment in order
to correct a deficiency that might be directly impacting a student’s experience due to missing or incorrect data.

Process Steps

• The SDLC Design Pattern for SharePoint item is identified as Production Data Change.
• Project Status is marked Planning, and the Business Analyst places a brief description in the Description
field of a SharePoint item that details what data change will fix the issue to be resolved.
• The Business Analyst directs the Sponsor to read and approve SharePoint item description by placing
his/her Approval: Functional Specification action in the SDLC Notes tab.
• Project Status is changed to Execution. A database update/insert/delete statement ode is written, unit
tested, and executed against the QA environment wherever possible to insure the desired results will be
met.
• A Code Reviewer is asked to assure that the database statement will have the desired effect, and places
his/her Approval: Code Review in the SDLC Notes of SharePoint item.
• The Technology Manager enters his/her Approval: System Change action in the SDLC Notes of
SharePoint item.
• The DBA, acting in the Release Manager role, executes the database statement against the production
database and changes SharePoint item status to Released to Production.
• The Sponsor is directed to check the production environment and determine if the change has had the
desired affect. If so, the Sponsor adds his/her Approval: User Acceptance (Production) action to
the SDLC Notes of SharePoint item.
• The Business Analyst changes the project Status to Completed.

Approvals

• Approval: Functional Specification (Sponsor)

• Approval: Code Review (Code Reviewer)
• Approval: System Change (Technology Manager)
• Approval: User Acceptance (Production) (Sponsor)

Documents

• none

SDLC for Release Management Wrapper

The purpose of the Release Management Wrapper pattern is to allow an individual acting in the Release Manager
role to monitor and ultimately deploy SharePoint items identified as components of a release into the QA and
Production environments. Release Management Wrapper projects utilize the Dependencies tab in SharePoint to
identify components of a release to one system environment or another. Components of a release have their own
specific SDLC Patterns to follow, so the Release Management Wrapper pattern contains very few approvals and
AUDIT-related requirements.

Process Steps

• The SDLC Design Pattern for SharePoint item is identified as Release Management Wrapper.
 • Project Status is marked Planning, and the Release Manager (acting in the Business Analyst role) places
a brief description in the Description field of a SharePoint item that details the types of changes the target
system will undergo when identified components are released. SharePoint item will remain in this status as
components are identified and entered in the Dependencies tab for SharePoint item.
• The Release Manager indicates that components are released into the QA environment by changing the
project status to Released to QA.
• Quality Assurance personnel change the item status to Quality Assurance during the QA phase.
• When the dependent components all successfully make it through the Quality Assurance phase, a
Technology Manager adds an Approval: System Change action to the SDLC Notes.
• The Release Manager changes the item status to Waiting for Production Release.
• Once all the project components are released into the production environment, the Release Manager
changes the project status to Released to Production.
• Quality Assurance Analysts confirm that all components are successfully operating in the production
environment and a Lead Analyst adds the Approval: Confirmed in Production action to the SDLC
Notes.
• The Release Manager changes the project Status to Completed.

Approvals

• Approval: System Change (Technology Manager)

• Approval: Confirmed in Production (Lead QA Analyst)

Documents

• Release Plans (Release Manager)

• Release History Reports from SSCM (Release Manager)
• Release Worksheet (completed for both QA and Production environments) (Release Manager)

SDLC for Research

The purpose of the Research pattern is to allow the Architecture team to track progress related to the identification
and analysis of new software implementations. The Research pattern may also be used when determining
implementation path for removing an existing system from Technology’s portfolio of supported systems, or when
creating a roadmap for combining more than one system into other existing systems for the purpose of simplifying the
supported systems portfolio. Research efforts may require the creation of prototypes or other proofs-of-concept;
however, the ultimate implementation of Research projects will become projects unto themselves. Research projects
typically result in the Technical Specification or technology recommendations of other projects.

Process Steps

• The SDLC Design Pattern for SharePoint item is identified as Research.

• A Technology Manager approves the research to be conducted by adding the Approval: Project
Initiation action to the SDLC Notes.
• The Technology Manager conducts a project definition meeting to determine the scope of research to be
conducted and documents the scope in a Vision and Scope document. The Technology Manager adds the
Approval: Concept Proposal action to the SDLC Notes.
• The Lead Architect for the project changes the project status to Execution.
• As findings are shaped into recommendations and a Technical Specification is produced from the research
efforts, the Technical Specification is added as a document within the project. The Technology Manager
reviews the specification and ultimately adds the Approval: Technical Specification to the SDLC
Notes.
 • Additional findings related to hardware requirements, cost, licensing, staff requirements and schedule for
implementation, etc. are added to the set of documents collected during the research process. Once the
findings of the project are completely vetted through all levels of Technology Management, and potential
Stakeholders in the organization are informed as to findings, the Technology Manager adds an Approval:
User Acceptance (Planning) to the SDLC Notes.
• The Lead Architect changes the project Status to Completed. Technology team leadership subsequently
determines the best set of follow-up projects to add to SharePoint in order to implement the findings from
this Research project.

Approvals

• Approval: Project Initiation (Technology Manager)

• Approval: Concept Proposal (Technology Manager)
• Approval: Technical Specification (Technology Manager)
• Approval: User Acceptance (Planning) (Technology Manager)

Documents

• Various
Other Process Patterns

Some Technology team efforts are not part of the Software Development Life Cycle per se. However, they are still
managed using language common to this document or are managed using SharePoint.

Process Pattern for Account Changes

Account Changes represent changes to application-level user accounts for applications like D3, Banner,
PowerFAIDs, and Luminis. They follow a limited number of SDLC process steps, approvals, and milestones.

Process Steps

• All account changes require AUDIT Compliance review.

• The SDLC Design Pattern for SharePoint item is identified as Account Change or Account Change
Removal.
• For new accounts or changes to existing accounts:
o Project Status is marked as Planning. The Functional Specification is detailed in either the
Project Description in SharePoint or under Notes. In addition, the HR-initiated Employee
Onboarding or Exiting document is attached to the Documents are of SharePoint.
o The End User reviews the Functional Specification and adds the Approval: Functional
Specification action in the SDLC Notes.
• User Acceptance in this case only consists of the Entitlement Team Manager adding the Approval:
System Change action in the SDLC Notes. Project Status is marked as Execution.
• An Entitlement Team staff person acts in the role of Release Manager and makes the account modification.
The staff person adds the Status Change: Release to Production action to the SDLC notes.
Project Status is marked as Quality Assurance.
• Actions are confirmed by an Entitlement team member and the End User. The End User adds the
Approval: User Acceptance (Production) action to the SDLC Notes. Project Status is marked as
Completed.

Approvals

• Approval: Functional Specification (skipped for account removals) (End User)

• Approval: System Change (Director)
• Milestone: Release to Production

Documents

• HR-initiated Employee Onboarding or Exiting (Human Resources)

Appendix A: SharePoint Alignment with the SDLC

1 SDLC Notes in SharePoint

Actions and comments related to the Software Development Life Cycle are added to every project under the SDLC
Notes tab in SharePoint.

Automated Notes

Because Project Status changes and the posting of Project Documents are an integral part of the SDLC, an SDLC
note is automatically added when the following events occur:

• Whenever a document is uploaded to the project, a Document Upload action is appended as an SDLC note.
The document name is noted in the comment for this note.
• Whenever the project Status or Status Detail is changed (fields visible on the project Display tab), a Status
Change: status action is added to the SDLC notes. The specific action added indicates the status change that
was made (for example: Status Change: Horizon), and the Status Detail is recorded as a comment.

Manually Entered Notes

Please note that all manually entered SDLC notes require a sufficiently detailed comment targeted to Technology
team members and Auditors attempting to determine the overall status of the project in the SDLC.

Note Summary Responsible Meaning

AUDIT Workflow Not Technology Banner, D3, and projects of a large size all require AUDIT rigor.
Needed Manager When a Technology Manager indicates the AUDIT Workflow Not
Needed designation, this is an explicit indication to Auditors that the
project is out of scope for AUDIT. This designation does not mean,
however, that the SDLC practices in this document are not followed.
Approval: Project Business Analyst The Technology Manager indicates that the initial business needs
Initiation assessment and Vision and Scope for the project are approved, and
that the project can proceed through subsequent steps in the SDLC.
Approval: Concept Sponsor
Proposal
Approval: Sponsor The Project Sponsor indicates that the project and its associated
Functional foundational documents are understood, that the scope of the
Specification project is fixed, and that the project can proceed. If the project
documents include a Vision and Scope, then this approval suffices
for both Functional Specification and Vision and Scope.
Approval: Design Technical Lead, The responsible person indicates that costs and details associated
Worksheet Architect or with project implementation are understood, and that Developers
Development and/or money can be assigned to the project.
Manager
Approval: Technical Development
Specification Manager
Approval: User Sponsor
Acceptance
(Planning)
Approval: Proceed Technology
to Develop Phase Manager
Approval: Code Code Reviewer A staff person acting in the Code Reviewer role under the Contacts
Review tab of the project has reviewed the code and found that it follows
standards, that it adheres to the approach articulated in the Design
Specification, and that it generally accomplishes the goals set forth
in the Functional Specification.
Milestone: Failed QA Analyst The QA Analyst assigned to the project under the Contacts tab in
Quality Assurance SharePoint indicates that the project does not meet the expectations
articulated in either the Functional or Structural Test Plans. The
project is returned to some previous step in the SDLC, depending
upon the severity of the problems identified.
Approval: Quality QA Analyst The QA Analyst assigned to the project under the Contacts tab in
Assurance SharePoint indicates that the project meets the expectations
articulated in the test plans. The project progresses through
subsequent steps in the SDLC.
Approval: User Sponsor The project Sponsor assigned to the project under the Contacts tab
Acceptance (QA) in SharePoint indicates that he or she has tested, in partnership with
a QA or Business Analyst, the project implementation in the QA
environment; and that he or she accepts the results of the
implementation. The project progresses through subsequent steps
in the SDLC.
Approval: System Technology The Technology Manager reviews the approvals, milestones, and
Change Manager documents associated with the project to date, and indicates that the
project can be promoted to the production environment.
Approval: IT IT Operations
Release Approval Lead
Approval: QA Analyst The QA Analyst verifies that the project is operating as expected in
Confirmed in the production environment.
Production
Approval: User Sponsor The project Sponsor verifies that the project is operating as
Acceptance expected in the production environment.
(Production)
Deny (generic) Anyone Any person can indicate that the project cannot move forward until
some issue is fixed. A specific comment should indicate the reason
the project is being temporarily stopped. This particular action is
best handled by changing the Project Status on the Display tab to
Suspended, and including an appropriate Status Detail.
Deny: Fixed by Business Analyst Technology team members can indicate that a particular project is
Other Project being cancelled because the business need was already addressed
by a different project. When this action is invoked, the comment
must include the Project Id of the project that accomplished the
business goal.
Milestone: Change Business Analyst During the course of a project, scope may change for several
Request reasons. When scope changes, the Business Analyst must
document the change in a Change Request document. The
Business Analyst notes that the Change Request has been
received, and includes a comment in the SDLC note to indicate how
the Change Request is to be honored. Possible scenarios for
honoring a Change Request include:

• Canceling the project by changing the project Status to

Cancelled and including an appropriate Status Detail.
• Changing the project Status to Suspended, and including a
Status Detail that indicates whether changes need to occur
in Design, foundational documents, etc.
Project Status in SharePoint

Status Description/Usage
Horizon Formerly Undefined.

• Identification of need/opportunity within Business or IT.

• Preliminary feasibility analysis. Business Alignment.
• Identify and assign Planning Resources.

Planning • Clearly define Business Sponsor and IT Leader.

• Estimate Resources, Budget and ROI. Obtain SIP Approvals if Necessary.
• Define Milestones (2 - 7), Deliverables, Other Project Dependencies.
• Sign-off: Requirements definition, deliverables list, milestones and user resources
commitment.

Spec/Approval • Sponsor review of foundational documents.

• Sponsor sign-off.

Waiting for Formerly Future.

Resources
• Planning Stage completed. Budget Available and approved for spending
• Project Ready to start/resume as resources become free
• Commission Project when resources ready and dependencies fulfilled
• Size of "Waiting" stage determines project backlog in labor/week

Waiting on • Project is suspended because project Sponsor is not available to participate, or they
Origin are gathering additional information.

Execution Formerly In Production.

• Currently in Progress. Size of Execution SharePoint equals available resources.

• Prioritization process may affect speed and resources allocated for execution.
• Projects may move back to waiting if depleted from resources but still viable.

Waiting for Code • Code Reviewers use this status daily to search for projects that are assigned to them.
Review
Waiting for QA • Release Managers use this status daily to search for projects that are assigned to
Release them.

Released to QA • A Release Manager has indicates that the code has been promoted to the QA
environment.

Quality • QA team is executing test plans. QA Analysts use this status daily to search for
Assurance projects that are assigned to them.

Waiting for • Release Managers use this status daily to search for projects that are assigned to
Production them.
Release
Released to • The Release Manager indicates that the project has been released to the production
Production environment.

Completed Formerly Live.

• Project completion accepted by Business Sponsor and deliverables produced

• User signs off project acceptance
• Resources are freed up for other uses

Maintenance • Project is repetitive, sys admin style task like weekly Banner maintenance, daily review
of logs, etc.

Suspended Formerly Started but Pending.

• The project is on hold until issues identified during Planning, Waiting, or Execution
states are resolved.

Canceled Formerly Dead.

• The project has ceased and will not be re-instated. If similar business needs require a
Technology solution, an entirely new project is created in SharePoint.

Closed (Do Not This project status is deprecated. Do not use it.
Use)
Appendix B: Roles and Responsibilities Throughout the SDLC

Role Description
Technology A Technology Manager role is filled by a Technology Services Director, Director of Infastructure,
Manager Director of Release Management, Executive Director of Services, or above.

Responsibilities:

• SDLC Note Action: AUDIT Workflow Not Needed

• Chooses the SDLC Design pattern for a given project.
• Approval; Proceed to Develop Phase
• Approval: System Change

Development A Development Manager role is filled by a Technology Services individual responsible for
Manager managing a group of Developers.

Responsibilities:

• Approval: Design Worksheet

• Approval: Technical Specification

Business The Business Analyst Role is typically filled by a Technology Services Director or Technology
Analyst Services Associate. The Business Analyst is responsible for initial problem identification and
business need analysis, full life cycle ownership of project data in Display tab on SharePoint, full
life cycle communication to end user/project Sponsor about project status and progress, and
participates in User Acceptance and Training.

Responsibilities:

• All Status changes in SharePoint.

• Document: Concept Proposal
• Approval: Project Initiation
• Document: Vision and Scope (optional)
• Document: Functional Specification

Project The Project Manager manages timelines, coordinates resources, and manages documents
Manager associated with the project. The project manager must continually collaborate with the Release
Management team throughout the project planning process in order to accurately represent
project delivery dates within the Release Calendar.

Responsibilities:

• Project Plan

Technical A Technical Lead may be assigned from the Developer team, should the size of the project
Lead warrant one. The Technical Lead becomes a liaison between Architect, Project Manager, and
 Business Analyst for communicating the Developer team progress, roadblocks, successes, etc.

The Technical Lead is responsible for acting as an escalation point for project resource issues,
determining response to scope changes, and potentially managing effects of Change Requests.
He or she is also responsible for crafting Design pursuant to standards and frameworks
identified for the enterprise architecture. The Technical Lead responds to the Business Analyst’s
Functional Specification with a Technical Specification when the size of the project merits one.

Responsibilities:

• Document: Design Worksheet (depends on project size)

• Approval: Design Worksheet (watch for conflict of interests: the author and approver of
the Design Worksheet cannot be the same person)
• Approval: Technical Specification (watch for conflict of interests: the author and
approver of the Technical Specification cannot be the same person)

Architect In larger projects, an Architect will be assigned from the Architecture team. This individual still
essentially acts as the Technical Lead for the project.

The Architect is responsible for acting as an escalation point for project resource issues,
determining response to scope changes, and potentially managing effects of Change Requests.
He or she is also responsible for crafting Design pursuant to standards and frameworks
identified for the enterprise architecture. The Architect responds to the Business Analyst’s
Functional Specification with a Technical Specification when the size of the project merits one.

Responsibilities:

• Document: Build versus Buy Recommendation (depends on project size)

Developer The Developer is responsible for writing code and performing unit tests on code.

Responsibilities:

• Standardized in-line comments in code.

• Comments in source code control database.
• Unit Test results communication to QA Analyst
• Document: Design Worksheet
• Document: Code Review Instructions
• Document: Code Promotion Instructions
• Document: Supplemental Testing Instructions
• Document: Supplemental Training Instructions

IT The IT Lead is a member of the Infrastructure team.

Operations
Lead Responsibilities:

• Document: Backup Plan

• Document: Server, Network, Storage, and Security Report
• Document: Capacity Plan
• Document: Monitoring Plan
 • Approval: IT Release Approval

Trainer The Trainer is responsible for creating training documentation and for end-user training.

Responsibilities:

• Document: Training Plan

• Document: Training Document / User Manual

Code Depending upon the size of a project, the Code Reviewer may be an Architect on the
Reviewer Architecture team or a Development Manager or a peer Developer from the Services team.

Responsibilities:

• Reviewing code written by Developers

• Document: Code Review Worksheet
• Approval: Code Review

Release The Release Manager is a staff person on the QA and Release Management team. To control
Manager for conflict of interests, the Release Manager ought never to develop code on the systems that
he or she is responsible for releasing code to, except under extreme and well-monitored
circumstances.

Responsibilities:

• Code builds and compiles

• Application configuration management
• Strategic bundling of release components (multiple projects in one release)
• Code promotion to QA and Production environments
• Document: Release Plan
• Status Change: Released to QA
• Status Change: Released to Production

QA Analyst The QA Analyst is a staff person on the QA and Release Management team. To control for
conflict of interests, the QA Analyst cannot be a Developer responsible for writing code.

Responsibilities:

• Documenting testing procedures

• Executing test plans
• Reporting the results of testing
• Collecting the results of Developer unit tests in order to appropriately inform the overall
testing process.
• Document: Functional Test Plan
• Document: Structural Test Plan
• Approval: Quality Assurance
• Milestone: Failed Quality Assurance
• Approval: Confirmed in Production
End User The End User is the project originator or Sponsor. The business need that he or she articulates
Stakeholder ultimately determines the scope of a project. A project Sponsor may appoint a Stakeholder to
Sponsor serve as the primary “end user,” to review and approve the project documentation and
deliverables. The End User also ultimately determines whether or not a project will be accepted.
The End User can change the scope of a project by formally making a Change Request through
the Business Analyst.

Responsibilities:

• Initiating the project

• Requesting changes to scope
• Collaborating with all members assigned to project to guarantee successful completion
• Approval: Concept Proposal
• Approval: Functional Specification
• Approval: User Acceptance (Planning)
• Approval: User Acceptance (QA)
• Approval: User Acceptance (Production)
Appendix C: Documents Used Throughout the SDLC

Following is a high level summary of each document in the SDLC. More specific instructions on the content and
creation of each template will be supplied in a separate document.

Document Name: Document Owner What the document describes:

Concept Business Analyst Very brief identification of the basics of the project.
Proposal

Vision & Scope Business Analyst What is the product and why do we need it?

Functional Business Analyst What will the product do/how will it work?
Specification
Functional Specification can include:

• Workflow diagrams (if user workflow)

• Process Flow diagram (if multi-tier or if new process)
• Integration diagrams (if multi-system)
• Security specification (if new system)

Project Plan Project Manager How the work will be done, who will do it, and how long will it
take?

The work breakdown structure of the project with time estimates

and resource assignments.

Design Technical How does the product fit into existing systems, and conform to
Worksheet Lead/Architect or department and company standards?
Developer
Used to identify development and production environments and
their configuration, system interdependencies, infrastructure
requirements, architecture best practices, and other specifics.
All new systems require that an initial and complete Design
Worksheet be created. Existing systems, however, will already
have Design Worksheets available. Most enhancements or
small projects on existing systems need only refer to the
existing Design Worksheet. Where changes are made to
existing systems, an abbreviated Design Worksheet will be
attached to the original worksheet as an addendum, listing only
items that are different and relevant to the new project.

Can include:

• Dependency diagrams

Build versus Buy Architect Will we build the application in-house or purchase a solution
Recommendation from an external vendor?

Technical Technical What are the details of system design, configuration, and
Specification Lead/Architect integration?
Training Plan Trainer How will end users be instructed on the new product?

Functional Test QA Analyst How will it be verified that the product performs as required?
Plan

Structural Test QA Analyst How will it be verified that the product is built to accommodate
Plan load and growth?

Backup Plan IT Lead

Server, Network, IT Lead Security content will include firewall needs, ports per server.
Storage, and
Security Report

Capacity Plan IT Lead

Monitoring Plan IT Lead Includes physical plan for server groups updated, and shows
flow.

Release Plan Release Manager How will the product be deployed to the production
environment?

Unit Tests Developer Results of the tests that a developer conducts on incremental
Results elements of code functionality to be sure it works.

Code Review Developer Identifies the pieces of code that must be reviewed, where the
Instructions pieces reside. Relays other pertinent information to the Code
Reviewer.

Code Promotion Developer Provides instructions to the Release Manager for moving the
Instructions code into the QA and Production environments. Includes any
additional steps that may need to be performed to compile or
execute the code. If security modifications are necessary for
End Users to access the new process, a note is made in this
document. (A new SharePoint is created specifically to address
the security requirement and change.)

Supplemental Developer Identifies and Provides suggestions to QA Analysts for effective

Testing testing of the code. Caution is taken not to bias the QA Analyst.
Instructions

Supplemental Developer Identifies pertinent information needed by the Trainer.

Training
Instructions

Code Review Code Reviewer Is the code bug-free, structured properly, and written in
Worksheet accordance with design standards?

Training Trainer Documentation to be distributed to the end user describing how

Document to use the product (i.e.: help files, training manual, user manual)

Change Request Business Analyst Identifies the change requirements requested to the product
Form after the planning documents have been agreed to.

Change Technical Lead Identifies how the change request affects changes to the
Modification Design and Technical Specifications, and to the already
produced code.

Test Results QA Analyst Which elements of the product have passed tests and which
Summary have failed.