AITS Project Management Life Cycle: Introduction
AITS Project Management Life Cycle
AITS – Portfolio Management Office - 2009
AITS Project Management Life Cycle: Introduction
Table of Contents
INTRODUCTION TO THE AITS – PROJECT MANAGEMENT LIFE CYCLE .......................................... 3
PMLC OVERVIEW ..................................................................................................... 5
SDLC OVERVIEW ..................................................................................................... 13
PROJECT TYPES
SOFTWARE DEVELOPMENT PROJECT ............................................................................... 4
1.0 Origniation Phase ........................................................................................ 6
2.0 Initiation Phase ........................................................................................... 8
3.0 Planning Phase ........................................................................................... 17
4.1 Analysis Phase ............................................................................................ 22
4.2 Design Phase .............................................................................................. 27
4.3 Construction Phase .................................................................................... 34
4.4 Testing Phase ............................................................................................. 42
4.5 Training Phase ............................................................................................ 48
4.6 Deployment Phase ..................................................................................... 50
5.1 Close Phase ................................................................................................ 56
5.2 Post-Close Phase ........................................................................................ 59
INDEX OF DELIVERABLES .................................................................................... 60
ANALYSIS PROJECT ................................................................................................. TBD
SOFTWARE UPGRADE PROJECT .................................................................................. TBD
HARDWARE INSTALLATION/UPGRADE PROJECT ............................................................. TBD
ROUTINE OS LEVEL MAINTENANCE PROJECT ................................................................ TBD
AITS Project Management Life Cycle: Introduction
AITS - Project Management Life Cycle: Introduction
The Portfolio Management Office (PMO) provides guidelines and standards for project management
in AITS. The PMO formed a working group to define the Project Management Life Cycle (PMLC) for
AITS led projects. The PMLC and standards have been developed to assist project managers in the
planning and execution of projects as well as to provide a documented, repeatable process to
enhance and standardize project execution and performance.
While we have attempted to define the PM process and deliverables ‘end-to-end’, the nature of the
project will dictate which elements are applicable to the respective project.
The PMO has identified five project types that should account for most of the projects managed by
AITS. Those project types are as follows:
Project Type
Description
Software Development Project
Full end-to-end analysis and development project.
Analysis Project
Project to assess feasibility and scope of a potential
implementation project. Deliverable is functional
specifications and an implementation project template.
Software Upgrade Project
Upgrade to existing software.
Hardware Installation / Upgrade
Project
Installation of new hardware or upgrade of current hardware.
Routine OS Level Maintenance
Project
Recurring periodic maintenance for operations / infrastructure.
In future a version of this documentation, PMO will provide documentation of the PMLC as it relates
to all of the project types identified above including pre-built project plan templates customized by
project type. As of this current version of the PMLC, the life cycle has been designed only for
software development projects.
For Software Development projects, we have worked with the Software Engineering Process Group
(SEPG) as they define the software development life cycle (SDLC). In order to maintain consistency in
the processes, deliverables and terminology between the PMLC and SDLC, we are sharing this
portion of the PMLC as a single document. As such, the SDLC documentation is extractable from the
overall PMLC documentation as a stand-alone document. In the context of the PMLC for the
software development, the PMLC adds the Origination and Initiation phases onto the front end of
the SDLC and the Post-close phase on the back end of the SDLC.
For reference throughout this documentation, below is a table which lists the various participant
roles and how they map to the current AITS organizational structure.
AITS Project Management Life Cycle: Introduction
Life Cycle Role
Participant
Analyst
Architecture, Technical, Functional, and Integration Analysts
Customer
Customers external to AITS, Customers within AITS
Deployment
Deployment Team, Architecture
Development
Architecture, Application and Report Developers, Data Modelers, Data
Base Administrators
EAC
Enterprise Architecture Committee
Operations
Application Support Team, EAI Team, Production Control Team, System
Administrators, Operations Team, Server Management, Storage Team
PMO
Portfolio Management Office
Project Manager
Project Manager
Project Sponsor
Project Sponsor
Quality Assurance
Quality Assurance Team
Security
Security Team, Architecture
AITS Project Management Life Cycle: Software Development Project
Project Type:
Software Development Project
AITS Project Management Life Cycle: Software Development Life Cycle 2.0
Page 6 of 67
AITS – Project Management Life Cycle – Software Development Projects
Project Management Life Cycle
1 Project
Origination
2 Project
Initiation
3 Project
Planning
4 Project Execution and Control
5 Project Closeout
Software Development Life Cycle
1 Origination
2 Initiation
3.0 Planning
4.1 Analysis
4.2 Design
4.4 Testing
4.5 Training
4.6
Deployment
5.1 Close
5.2 Post
Close
- ITPC Template
- Project Review
- Project Approval
- Project Creation
- Priority Setting
- Project Scheduling
-Discovery
meetings
-Stakeholder
analysis
- Communication
plan
- Project Charter
- Project Kick Off
-Communication
activities
- Project Plan in
Clarity
(WBS, Resources,
Estimates, and
Schedule)
- Project planning
meetings with
team
- PMO / SMT Sign-
Off
-Final project plan
review and
approval with team
-Baseline project
- Deployment Plan
- Business Rules
- DWG Design Collaboration
- Application Design
- Integration Design
- Conversion Strategy
- EAC Review
- Security Review
- Application Design Review
- Training Strategy
- Testing Strategy
-- Communicate
-Monitor, Control, and
Manage Change
- DWG Design
Collaboration
- Style Guides
- Service Guides
- Technical
Design
- EAC Review
- Security
Review
- Sensitive Data
Usage Form
- Technical Design
Review
- QA Master Test
Plan
- Training Plan
- Hardware /
Software Order
Communicate
-Monitor and Control
- Manage Change
Requests
- Technical Design Review
- QA Master Test Plan
- Training Plan
- Hardware / Software Order
Communicate
-Monitor and Control
- Manage Change Requests
- IITAA Checklist
- Training Environment
- Artifact Staging
- Training Security Setup
- Customer Training
-Communicate
-Monitor, Control, and
Manage Change
- Application
Deployment Checklist
- Artifact Staging
- Dress Rehearsal
- Change Control
- Event Notice
- System Deployment
- Production Readiness
Test
- Go / No Go Decision
- Communicate
-Monitor, Control, and
Manage Change
- Post Deployment
Review
- Environment Review
and Cleanup
- Stakeholder
Satisfaction Survey
- Post Project Review
- Final Project
Documentation Review
- Short Term Post
Project Support
- Production Support
- Post Project
Survey
4.3 Construction
- EAC Review
- Development
- System Test Plan
- Functional Test
- QA Test Cases / Scripts
- QA Functional Test
- Performance Test Plan
- Performance Test
- Security Scans
- Customer Test Plan
- Alpha Test
- Training Materials
- User Guides / Help Materials
- Communicate
-Monitor and Control
- Manage Change Requests
- Hardware / Software
Installation
- Infrastructure Deployment
- Development / Unit Test Cycle
- Show and Tell
- DWG Design
- Code Review
- Defect Management
Participants
Participants
Participants
Participants
Participants
Participants
Participants
Participants
Participants
- AAMT
- ADSD Managers
- Architecture
- COE Managers
- EAC
- ITPC
- ITPC
Subcommittees
- PMO
- Project Sponsor
- SMT
- UA Technology
Organizations
- AFM
- Analyst
- Architecture
- Customer
- Deployment
- Development
- Operations
- PMO
- Project Manager
- Project Sponsor
- Quality
Assurance
- Security
- UA Technology
Orgs
- Analyst
- Architecture
- Customer
- Deployment
- Development
- Operations
- PMO
- Project Manager
- Project Sponsor
- Quality Assurance
- Security
- SMT
- Technical Lead
- Analyst
- Architecture
- Customer
- Deployment
- Development
- Development Working
Group
- Operations
- Project Manager
- Project Sponsor
- Quality Assurance
- Security
- Training Team
- Analyst
- Architecture
- Customer
- Deployment
- Development
- Development Working Group
- Operations
- Project Manager
- Project Sponsor
- Quality Assurance
- Security
- Training Team
- Analyst
- Customer
- Deployment
- Development
- Project Manager
- Security
- Analyst
- Customer
- Deployment
- Development
- Operations
- Project Manager
- Project Sponsor
- Quality Assurance
- Security
- Analyst
- Architecture
- Customer
- Deployment
- Development
- Operations
- PMO
- Project Manager
- Project Sponsor
- Project Team
- Quality Assurance
- Security
- Customer
- PMO
- Project
Manager
- Project Sponsor
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Origination Phase
Page 7 of 67
Origination Phase
Prioritize Projects
Phase
Inputs
High Level
System
Requirements
Create ITPC Template
ITPC Template
ITPC Committee / Subcommittee Review
ITPC / AAMT
Review
Deployment
Security
Operations
Quality
Assurance
Development
Analyst
Customer
Project
Management
Schedule Projects
1.0 Origination
AITS
SDLC
Software Development
Life Cycle
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Origination Phase
Page 8 of 67
Phase 1: Origination
The purpose of the Origination Phase is to develop proposals for potential projects, route the proposals through the proper review
channels, and after review, if approved, schedule the projects based on priority and resource availability. Both ITPC and internal AITS
projects will pass through this phase, but will trigger different activities and key deliverables.
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Complete an ITPC
Level I or II
Template
An ITPC template should be completed for all ITPC and internal projects.
Internal project templates will be reviewed by SMT while ITPC projects will
follow the ITPC review and approval process. The templates are designed to
be self explanatory and can be located @
http://www.itpc.uillinois.edu/itpcprojsubmissions
If a client requires assistance with the creation a template or the work
estimate, a work request should be submitted to the Unicenter AITS-ADSD
work requests queue and an analyst will be assigned. The TAM functional
area leads will review all ITPC template estimates for reasonableness. All
assumptions made in creating the estimate should be clearly detailed in the
template. The project proposals should be reviewed at the weekly
Architecture / ADSD meetings and the results of this review should influence
the estimate. Projects should be further reviewed by this group in the
Design and Construction phases of the project.
Completed templates should be submitted to [email protected].
- Level I or II
Completed ITPC
Template with
Business Case and
Resource Estimates,
SOW Request (also
known as a Project
Proposal)
Project Sponsor (Owner)
UA Technology Organizations
Architecture
For a further
description of the ITPC /
Work Request process
please go to:
http://www.aits.uillinoi
s.edu/live/Site.xml?doc
ument=RequestWork.x
ml&focus=N5
Review Project to
Determine EAC
Involvement
The Project Review subcommittee will review projects that are proposed
under AITS and ITPC. The PMO/EAC liaison will meet with EAC leadership
and TAM leadership on a monthly basis to identify ITPC projects that may
benefit from early EAC involvement. By introducing the concept of
“architecture” early on it is the hope that decisions made during the project
will take architectural standards and policies into consideration.
- Project Proposal
(Completed ITPC
Template)
- Level of
Involvement by EAC
- Feedback to AITS
Management or
ITPC
Portfolio Management Office
(Owner)
Enterprise Architecture
Committee
TAM Leadership
https://intranet.uillinois
.edu/departments/pa/e
ac/ITPC%20%20EAC%20
Review/AITS_EAC_Proje
ctReviewSubcommittee.
pdf
Obtain AITS
Management
Group
Review/Approval
for AITS Internal
Projects
Project proposals (either in the form of completed ITPC templates or AITS
internal project proposals) related to technology projects or internal AITS
projects will be routed to the AITS Management Group (MG) by the PMO for
review at their next meeting. The project sponsor may be asked to attend
MG to present the proposal. The proposal may be approved and queued for
scheduling (if internal), approved to proceed to ITPC review (if technology),
rejected, or deferred with a request for additional information.
- Project Proposal
(either completed
ITPC Template or
AITS internal project
proposal)
- Project Approved /
Denied
Management Group (Owner)
Obtain ITPC
Subcommittee
Approval for ITPC
Projects
Completed ITPC templates will be routed to the appropriate functional ITPC
subcommittee (Finance, HR, or Student) for review at their next meeting.
ITPC subcommittees meet monthly. The proposal may be approved and
forwarded to ITPC for review, rejected, or deferred with a request for
additional information.
-Project Proposal
(completed ITPC
Template)
- Project Approved /
Denied
ITPC Subcommittee (Owner)
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Origination Phase
Page 9 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Obtain ITPC
Review/Approval
for ITPC Level II
Projects
Level 2 ITPC project proposals approved at the ITPC level will be routed to
the ITPC for review at their next meeting. ITPC meets quarterly. At this
meeting, level 2 templates may be approved, rejected, or deferred with a
request for additional information.
-Project Proposal
(completed ITPC
Template)
- Project Approved /
Denied
Illinois Technology Priorities
Committee (Owner)
Initial Project
Setup in Clarity
Using the approved project proposal as a guide, a member of the PMO will
initially set up the project in Clarity. This initial set up will include
placeholder project plan tasks to hold the effort by role in the project
template. Later when the project manager begins to construct the project
plan, the placeholder task should be discarded and replaced by the project
plan template derived from this PMLC/SDLC.
-Project Proposal
(completed ITPC
Template)
- Project Plan
Template
- Project Setup in
Clarity
Portfolio Management Office
(Owner)
Determine
Priority of AITS
Internal Projects
On a quarterly basis, MG will prioritize all ITPC technology projects and
internal AITS projects. Projects will be scheduled based on this prioritization
and resource capacity. Mandatory projects will be scheduled based on the
nature of the projects and production date requirements. MG will further
prioritize Internal and ITPC projects where conflicts exist in scheduling.
- Projects to be
scheduled in queue
- Priority List of
Projects
Management Group (Owner)
Determine
Priority of ITPC
Projects
On a quarterly basis, the functional ITPC subcommittees and ITPC will
prioritize all ITPC projects approved but not yet started within their
functional areas. Projects will be scheduled based on this prioritization and
resource capacity. Mandatory projects will be scheduled based on the
nature of the projects and production date requirements.
- Projects to be
scheduled in queue
- Priority List of
Projects
ITPC Subcommittee and ITPC
(Owner)
Set Project
Schedule
On a monthly basis, the project schedule for both internal and ITPC projects
is reviewed and adjusted based on project prioritization and resource
capacity. During this project scheduling process, managers review all
projects in flight do determine required adjustments as well as to provide
consistent communication regarding project status. After reviewing in flight
projects, the managers schedule projects in the queue based on the
provided priorities as well as the resource capacity available for new
projects. This schedule is further fine tuned based on collaboration with
representatives from all of the functional areas.
- Priority List of
Projects Resource
availability
information
- Monthly Project
Schedule
Portfolio Management Office
(Owner)
ADSD Managers
COE Managers
UA Technology Organizations
https://www.itpc.uillino
is.edu/ItpcProjectPriorit
ize
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Initiation Phase
Page 10 of 67
Initiation Phase
2.0 Initiation
Deployment
Security
Operations
Quality
Assurance
Development
Analyst
Project
Management
Customer
Phase
Inputs
Project
Proposal/
ITPC
Establish work and project
processes
Identify and plan for risks
Refine project scope
Identify impacts, dependencies,
&assumptions
Revise preliminary estimates
Identify project team
Identify stakeholders
Plan communication
Final project
charter
Final
communication
plan
Kick-off
meeting
Draft project
charter
Draft
communication
plan
Set up project
Discovery meeting
AITS
SDLC
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Initiation Phase
Page 11 of 67
Phase 2: Initiation
The purpose of the Initiation Phase is to develop the Communication Plan and Project Charter to formalize project goals and deliverables,
identify project participants and establish roles and responsibilities. The project team will review the Project Charter Communication
Plan at the Kick-Off meeting to provide all participants with a shared understanding of project expectations.
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Set up project
During project setup, the Project Manager introduces him/herself to the
primary team members and stakeholders as well as updates the Clarity
project and the SharePoint workspace for the project
-Project Proposal
(either the
completed ITPC
template or an AITS
internal project
proposal)
- Initial contacts
- Initial Clarity
updates
- Initial SharePoint
workspace
customization
Project Manager (Owner)
Initiating a Project
course and related
materials can be
found in the AITS
SharePoint
Document Library
under Methodology
> Project
Management
Lifecycle
Hold Discovery
Meetings
The purpose of the discovery meetings are to bring all the participants
together, introduce them to the project, and give team members a forum for
voicing their opinions early on in the process. The Discovery meetings
should review the project scope statement (taken from the project
proposal), identify missing team members and stakeholders, and the general
discussion of schedule, risks, and concerns.
-Project Proposal
- More complete list
of stakeholders,
updated risks and
issues, better
understanding of
scope, and thoughts
on schedule and
resources
Project Manager (Owner)
Project Sponsor
Customer
A template for the
Discovery Meeting
Agenda and Notes
can be found in the
AITS SharePoint
Document Library
under Methodology
> Project
Management
Lifecycle >
Templates and Forms
>
Project_Discovery_m
eeting_Agenda_and_
Notes_Template.dot
x
Identify
Stakeholders
Work with key project team members, customers, and project sponsor to
identify stakeholders and their expectations.
-Project Proposal
-Outputs from
Discovery Meetings
- Stakeholder
worksheet (not for
distribution)
Project Manager (Owner)
A worksheet for the
Stakeholder Analysis
can be found in the
AITS SharePoint
Document Library
under Methodology
> Project
Management
Lifecycle >
Templates and Forms
>
StakeholderWorkshe
et.dotx
Create
Communication
Plan
The Project Communication plan is created by the project team early in
project to indicate their agreement on how the team will communicate
important information during the project - status, meetings, issues,
deliverables access, and design/ document reviews. It is recommended that
this plan is completed early enough to be included for review at the Project
-Project Proposal
-Stakeholder Analysis
- Communication
Plan
Project Manager (Owner)
Project Sponsor
Customer
A template for the
Communication Plan
can be found in the
AITS SharePoint
Document Library
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Initiation Phase
Page 12 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Kick-off Meeting.
under Methodology
> Project
Management
Lifecycle >
Templates and Forms
> TEMPLATE-
ProjectCommunicati
onPlan.dotx
Create Project
Charter
The project charter acts to define a number of key project elements
including a project description, scope definition, and role/responsibility
definition. The documentation and review of these key project elements on
the front end of the project helps to avoid misunderstandings or confusion
later in the project and sets a baseline for high-level expectations.
The following are components of and are defined in the project charter:
Project scope
Work and project processes (includes change management
process)
Risks
Impacts, dependencies, & assumptions
Preliminary estimates
Project team
- Project Proposal
-Outputs from
Discovery Meetings
- Project Charter
Project Manager (Owner)
Project Sponsor
Customer
A template for the
Project Charter can
be found in the AITS
SharePoint
Document Library
under Methodology
> Project
Management
Lifecycle >
Templates and Forms
>
Project_Charter_Tem
plate.dotx
Conduct Project
Kick-off Meeting
The main goal of the project kick-off meeting is to familiarize the project
team with the project, review the project charter, change management and
communications plans and receive buy-in from all project participants.
Future meeting schedules will be defined and discussed and meeting
minutes will be documented.
For large or high risk projects there will be enhanced requirements regarding
project monitoring and control. The procedures as described in the next
section should be reviewed at the project kick-off meeting so there is an
understanding of these requirements as well.
- Project Charter
- Communication
Plan
- Meeting Minutes
-Final Project Charter
-Final
Communication Plan
-Initial draft of tasks
as inputs to planning
phase
Project Manager (Owner)
Project Sponsor
Customer
Analyst
Development
Quality Assurance
Security
Deployment
Operations
Architecture
UA Technology Organizations
Decision Support
Portfolio Management Office
A template for the
Project Kick-off
Meeting can be
found in the AITS
SharePoint
Document Library
under Methodology
> Project
Management
Lifecycle >
Templates and Forms
>
Project_Kickoff_Mee
ting_Agenda_and_N
otes_Template.dotx
Ongoing activity:
Communicate
(Implement
Communication
Plan)
Throughout the course of a project there are a number of recurring activities
related to communication. These include the activities identified in the
communication plan, which typically consist of:
Weekly project team status reports (Template provided which
offers a standardized agenda for status meetings throughout the
course of a project)
Maintaining SharePoint workspace with meeting agendas,
minutes, decisions, documentation, and status reports.
Project sponsor meetings for reviewing significant project plan
changes and progress
Informal communication: walk-abouts, hallway conversations,
and personal emails
There are enhanced processes and requirements regarding project
-Communication Plan
-Various
communication
outputs per the
Communication Plan
Project Manager (Owner)
Project Team
Portfolio Management Office
Templates for
various types of
meetings and
resulting notes can
be found in the AITS
SharePoint
Document Library
as well as guides to
using Clarity and
SharePoint
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Initiation Phase
Page 13 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
monitoring and control for large projects (those with greater than 5,000
hours of effort or $250,000) or any projects deemed of sufficient risk. These
should be identified in the project communication plan, but are outlined
here as well.
For these projects it is advisable that a Steering Committee or Oversight
Group be formed to monitor the project execution and collaborate on key
project decisions. Templates for Large Projects are included as follows:
Steering Committee Reporting Template – This is a reporting
package for periodic steering committee meetings and includes
standardized sections for:
o Project Timeline
o Significant Event Review
o Significant Risks / Issues
o Metric Tracking
o Change Request and Defect Tracking
o Budget Report
o Other
Large Project Budget Workbook – This is a multi-tabbed Excel
spreadsheet for tracking actual versus budgeted costs for
internal/external labor and non-labor items.
All projects of this nature will have a unique set of circumstances which will
require extensive customization of the communication plan.
Software Development Life Cycle documentation begins on the following page.
AITS Project Management Life Cycle: Software Development Life Cycle 2.0
Page 14 of 67
Software Development Life Cycle
Version 2.0
AITS Project Management Life Cycle: Software Development Life Cycle 2.0
Page 15 of 67
Overview
The purpose of a Software Development Life Cycle methodology is to provide a documented description of
how software is built by AITS. It describes the various phases of the development process and the activities
performed by individuals during each phase. It is not meant to be a cookbook approach to software
development, but a guide to the best practices and procedures used at AITS for various activities. As software
development projects are executed, the SDLC serves as reference to determine which activities are needed for
that particular project and provide detailed information on how to accomplish those activities; not every
activity listed defined within the SDLC is required by every project. Furthermore, the SDLC provides access to
the necessary templates and documented procedures associated with those activities.
The SDLC was developed by the Software Engineering Process Group (SEPG) established by AITS to identify
software development processes and practices at AITS that work well, need improvement, or don’t exist. This
group serves to prioritize the practices that require the most attention and identify the appropriate resources
to focus on the process improvements. The process owners are those groups who are the key participants of
the process. For more information regarding the SEPG and the approach used to develop the SDLC, refer to
the following documents:
AITS SDLC Approach
SEPG Guiding Principles
The SDLC is a constantly evolving collection of processes and templates and is meant to improve as better
ways of building software are identified. Questions or suggestions regarding the contents of this document
should be referred to the AITS SEPG (AITSSEP[email protected]).
How to Read This Document
The SDLC is comprised of eight major phases: Planning, Analysis, Design, Construction, Testing, Training,
Deployment, and Close. For each phase, this document provides a single page swim lane diagram that depicts
the various activities performed by the groups and a general order of events for the entire phase. Since the
software development process is fluid, the order of events may not always be the same and certain
components of a project may be in one phase while others are in a different phase. Following each diagram is
a matrix that provides a more detailed description of each activity in the phase and links to various processes,
procedures, and templates that further define that function. Each activity illustrated on the single page swim
lane overview has a corresponding entry in the subsequent matrix.
The following table defines the symbols used within the diagrams:
Symbol
Description
Activity Description
Represents an activity performed during the particular phase. If there are no arrows
in the beginning or end of the activity, then it is started and completed during the
phase. The activity may have many participants from various groups, but the
activity is shown within the lane of the primary owner of that activity. If there are
multiple groups that participate in this activity and is a major part of the group’s
responsibilities, then it may appear in multiple lanes.
Activity
Same as above, however, the arrows indicate that this activity is performed in the
previous phase and is carried over to the current phase.
AITS Project Management Life Cycle: Software Development Life Cycle 2.0
Page 16 of 67
Symbol
Description
Activity
Same as above, however, the arrows indicate that this activity is started in this
phase and is carried over to the next phase.
Activity
Same as above, however, the arrows indicate that this activity is performed in both
the previous phase and the next phase.
Review
Point
This represents a formal review step within the phase. The review points determine
if the work product is ready to move to the next phase.
Phase
Deliverable
This represents a document or deliverable that is produced as the result of the
activity. These are used as either final work products or inputs into other activities.
1
This symbol is used for on-page connectors to show hand-offs and dependencies
between activities between groups.
It is important that the SDLC documentation focus on the relationship between activities and owners of the
activities based upon role and functions instead of organizational structure. If the SDLC is tied closely to
organizational structures within AITS, then it susceptible to revisions whenever there are organizational
changes within AITS. It is also common for participants in a project to perform a particular role for one project
and a different role in another project. For example, a technical analyst may perform the duties of an analyst
and a project manager for one project and may serve as the customer in another. Therefore, it is important to
make these roles general in nature and not a byproduct of the current AITS organizational structure.
However, as organizational changes occur, the SDLC should be reviewed to ensure that the depiction of roles
and descriptions of activities are still accurate.
Within the matrix, key participants and owners have been identified who may participate in each activity.
There may be other participants within the activities that are not necessarily reflected in the high level process
documentation presented within the SDLC. As the project charter and project plan are developed, a detailed
assignment of resources will be done for the required activities using the SDLC documentation as an aid in
determining the proper resources to assign to a task.
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Planning Phase
Page 17 of 67
AITS – Project Management Life Cycle – Software Development Projects
Project Management Life Cycle
1 Project
Origination
2 Project
Initiation
3 Project
Planning
4 Project Execution and Control
5 Project Closeout
Software Development Life Cycle
1 Origination
2 Initiation
3.0 Planning
4.1 Analysis
4.2 Design
4.4 Testing
4.5 Training
4.6
Deployment
5.1 Close
5.2 Post
Close
- ITPC Template
- Project Review
- Project Approval
- Project Creation
- Priority Setting
- Project Scheduling
-Discovery
meetings
-Stakeholder
analysis
- Communication
plan
- Project Charter
- Project Kick Off
-Communication
activities
- Project Plan in
Clarity
(WBS, Resources,
Estimates, and
Schedule)
- Project planning
meetings with
team
- PMO / SMT Sign-
Off
-Final project plan
review and
approval with team
-Baseline project
- Deployment Plan
- Business Rules
- DWG Design Collaboration
- Application Design
- Integration Design
- Conversion Strategy
- EAC Review
- Security Review
- Application Design Review
- Training Strategy
- Testing Strategy
-- Communicate
-Monitor, Control, and
Manage Change
- DWG Design
Collaboration
- Style Guides
- Service Guides
- Technical
Design
- EAC Review
- Security
Review
- Sensitive Data
Usage Form
- Technical Design
Review
- QA Master Test
Plan
- Training Plan
- Hardware /
Software Order
Communicate
-Monitor and Control
- Manage Change
Requests
- Technical Design Review
- QA Master Test Plan
- Training Plan
- Hardware / Software Order
Communicate
-Monitor and Control
- Manage Change Requests
- Training Environment
- Artifact Staging
- Training Security Setup
- Customer Training
-Communicate
-Monitor, Control, and
Manage Change
- Application
Deployment Checklist
- Artifact Staging
- Dress Rehearsal
- Change Control
- Event Notice
- System Deployment
- Production Readiness
Test
- Go / No Go Decision
- Communicate
-Monitor, Control, and
Manage Change
- Post Deployment
Review
- Environment Review
and Cleanup
- Stakeholder
Satisfaction Survey
- Post Project Review
- Final Project
Documentation Review
- Short Term Post
Project Support
- Production Support
- Post Project
Survey
4.3 Construction
- EAC Review
- Development
- System Test Plan
- Functional Test
- QA Test Cases / Scripts
- QA Functional Test
- Performance Test Plan
- Performance Test
- Security Scans
- Customer Test Plan
- Alpha Test
- Training Materials
- User Guides / Help Materials
- Communicate
-Monitor and Control
- Manage Change Requests
- Hardware / Software
Installation
- Infrastructure Deployment
- Development / Unit Test Cycle
- Show and Tell
- DWG Design
- Code Review
- Defect Management
Participants
Participants
Participants
Participants
Participants
Participants
Participants
Participants
Participants
- AAMT
- ADSD Managers
- Architecture
- COE Managers
- EAC
- ITPC
- ITPC
Subcommittees
- PMO
- Project Sponsor
- SMT
- UA Technology
Organizations
- AFM
- Analyst
- Architecture
- Customer
- Deployment
- Development
- Operations
- PMO
- Project Manager
- Project Sponsor
- Quality
Assurance
- Security
- UA Technology
Orgs
- Analyst
- Architecture
- Customer
- Deployment
- Development
- Operations
- PMO
- Project Manager
- Project Sponsor
- Quality Assurance
- Security
- SMT
- Technical Lead
- Analyst
- Architecture
- Customer
- Deployment
- Development
- Development Working
Group
- Operations
- Project Manager
- Project Sponsor
- Quality Assurance
- Security
- Training Team
- Analyst
- Architecture
- Customer
- Deployment
- Development
- Development Working Group
- Operations
- Project Manager
- Project Sponsor
- Quality Assurance
- Security
- Training Team
- Analyst
- Customer
- Deployment
- Development
- Project Manager
- Security
- Analyst
- Customer
- Deployment
- Development
- Operations
- Project Manager
- Project Sponsor
- Quality Assurance
- Security
- Analyst
- Architecture
- Customer
- Deployment
- Development
- Operations
- PMO
- Project Manager
- Project Sponsor
- Project Team
- Quality Assurance
- Security
- Customer
- PMO
- Project
Manager
- Project Sponsor
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Planning Phase
Page 18 of 67
Planning Phase
3.0 Planning
Quality
Assurance
Development
Analyst
Project
Manager
Customer
Phase
Inputs
Project
Proposal /
ITPC
Project
Charter
AITS
SDLC
Software Development Lifecycle
Communication
Plan
Deployment
Security
Operations
Revised task list
Revised estimates
Schedule
Resource assignments
PMO review,
revisions and
approval
Final project
plan review and
approval
Application
Deployment
Plan
Develop Application Deployment Plan
Approved
project plan
Financial plan
Project planning
meeting with team
Develop
project
plan in
Clarity
Draft project
plan in Clarity
Communication
Monitor and Control
Baseline Project
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Planning Phase
Page 19 of 67
Phase 3.0 - Planning
The purpose of the Planning Phase is to develop a detailed and complete work plan for the project that can be used by all stakeholders as
a roadmap for project execution. The project proposal from Phase 1: Origination and the project charter from Phase 2: Initiation are
used as starting points to create the project plan and start the deployment planning process through identifying hardware and software
purchases that will need to be made in order for development to begin.
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
Develop Project
Plan
Creating the project plan provides a roadmap for effective project planning
and execution, and becomes a tool for monitoring progress throughout the
project. The project plan documents the project tasks, deliverables,
milestones, schedule, participants and budget and should facilitate
communication among project stakeholders. The project plan is a living
document that will be consulted and modified throughout the life of the
project as factors within and outside the project affect the project elements.
While the project plan is the ultimate responsibility of the project manager,
input from the entire project team and key client personnel will be required
for its development. The project plan is established and maintained in
Clarity. The activities described in this documentation will not be
applicable for all projects depending on the nature and size of a project. The
project manager will need to work with the project team, technical leads
and PMO to determine which tasks would not be applicable in certain
instances.
The project plan is recorded in a series of forms in Clarity. The following
activities are required to complete the project plan. Please note that these
activities are highly interdependent.
-- Task identification and organization (aka Work Breakdown Structure):
The Work Breakdown Structure (WBS) is a detailed hierarchal tree structure
of deliverables and tasks that need to be performed to complete a project.
Steps in creating the WBS would include:
o Identification of major steps and milestones
o Sequence the major steps
o Identify known dependencies between tasks and deliverables
o Identification of detailed steps and milestones
--Assigning resources to tasks : This activity includes identifying the project
participants and applying these resources or roles into the project plan
against the appropriate tasks and deliverables for which they will be
responsible. The staff assigned to a project may be identified early in the
project, before the project plan is developed or as a result of requirements
developed in the project plan and other planning. As early as possible,
project managers should consult with the respective team leads to identify
- Project Proposal
- Project Charter
- Project Plan
Template
- Within Clarity, the
following
information is
required to have a
project plan
1.Work Breakdown
Structure
2. Resources
assigned to tasks
3. Estimates
provided for each
task
5. Start and end
dates for the tasks,
and start, finish,
requested
implementation, and
implementation
dates for the project
6. Critical path for
project
7. Financial plan
(entered by the
PMO)
Project Manager (Owner)
Portfolio Management
Office
There are a number of
pre-populated project
plan templates available
in Clarity. Typically your
project will be set up
with one of these plans
as a starting point.
For more details on the
Project Manager’s
responsibilities during
the Planning Phase,
please see the Planning a
Project course materials
and related guides in the
Sharepoint Document
Library.
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle
Here is a link to the
PMLC/SDLC Project Plan
Template located in
Clarity.
https://clarity.apps.uillin
ois.edu/niku/app?action
=projmgr.projectProperti
es&id=5022276
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Planning Phase
Page 20 of 67
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
the resources to be assigned to their projects. Ideally, resources should be
identified prior to the project kick-off meeting in the initiation phase so that
they may participate and provide input early in the project. As these
individuals are identified, they should be documented in the project plan in
place of generic role placeholders (i.e. Application Developer, Technical
Analyst, etc…). A consideration in creating the project schedule and staffing
plan is that they are very interdependent. The availability of additional
resources may translate into a shortened project schedule. Conversely,
scarce resources may extend the project schedule. If there are dates in the
project schedule that are immovable, then resources must be allocated
accordingly to meet the required schedule. In the absence of hard
scheduling requirements, the project manager should adjust the project
schedule to fit the resources available to the project.
--Estimating effort for tasks : Once the WBS is defined, the project team
must estimate the effort needed to perform the tasks identified. Usually
there will already be a higher-level estimate that has been prepared as part
of the Project Proposal. While this estimate may be used as a reference, it
should not be the basis for the estimates in the project plan. The project
manager should develop the task effort estimates based on the team’s
knowledge of the project requirements, prior experience and the advice of
others on the project team and in the department. It is best to get
estimates from the team members that will be doing the work.
--Scheduling : Once the work has been defined and the required effort has
been estimated, the project manager will create the project schedule. The
project schedule should be developed by determining target start and
completion dates for the tasks and deliverables in the project plan.
--Financial planning: The financial plan details the project costs for external
resources, equipment, software, and expenses (such as travel and any other
project expenditures). For most ITPC projects an initial plan will be entered
into Clarity from the project proposal by the PMO. Actual expenditures will
be entered into Clarity to track against the budget by the PMO. These are
derived from general ledger detail reports on a monthly basis. For very large
projects, a separate detailed cost tracking spreadsheet may be used. The
PMO will provide help developing and maintaining spreadsheets like these
for large projects.
--Critical Path : Once the project plan is developed, the project manager
should identify the critical path in the project. The critical path is the
sequence of tasks/deliverables in a project where none of the
tasks/deliverables can be delayed without affecting the final project end
date. By identifying the critical path in a project, the project manager can
pay particular attention to and take needed actions toward the
tasks/deliverables on the critical path to avoid delays to the overall project
schedule. The critical path is driven by the project task dependencies and
milestones in the plan. A PMO team member will assist the project manager
in determining the project critical path if needed.
Project Planning
Meeting with
The goal of this meeting is to gather input from the project team on the
draft project plan. The goal is to review the tasks, deliverables, timelines
- Draft Project Plan
- Revised Project
Plan
Project Manager (Owner)
Portfolio Management
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Planning Phase
Page 21 of 67
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
Team
and resource assignments throughout the plan. Reviewing this as a group
will ensure understanding among all project participants regarding their
responsibilities, assigned deliverables and interdependencies between team
members and tasks assigned. This will also provide a forum for questions
and uncertainties to be discussed so everyone has shared expectations and
buy-in for the plan to move forward. The project plan should be revised if
necessary based on the feedback received from this meeting. Meeting
minutes should be documented to create a record of the participants and
major points of the meeting.
This meeting will be lengthy and allow more than an hour to go through all
the items on the agenda:
Verify WBS
Verify estimates
Verify assignments
Set due dates and schedules
The activities described in this documentation will not be applicable for all
projects depending on the nature and size of a project. The project manager
will need to work with the project team, technical leads and PMO to
determine which tasks would not be applicable in certain instances.
Prior to the project plan review by the full project team, the appropriate
TAM lead should review the project plan for completeness to ensure all
required and appropriate steps from the PMLC / SDLC are included in the
plan.
The project manager should receive and retain an email confirmation of this
review an approval.
Office
Project Sponsor
Customer
Project Team
PMO Review,
Revisions, and
Approval
The PMO will review the project plan, suggest revisions, and approve it.
For large projects or projects requiring additional rigor in monitoring and
control, AITS LT must approve the project plan and the PM will need to
provide a project presentation to AITS LT during the planning phase of the
project.
- Project Proposal
- Project Charter
- Communication
Plan
- Project Plan
- Revised Project
Plan
Project Manager (Owner)
Portfolio Management
Office
Final Project Plan
Review and
Approval (with
project team)
Once the plan is approved by the PMO, the Project Manager should have a
final project plan review and approval with the project team. This is a
formal meeting to ensure there is still agreement on the project plan.
-Project Plan
-Approved Project
Plan
Project Manager (Owner)
Portfolio Management
Office
Project Sponsor
Customer
Project Team
Create Project
Baseline
Once the project plan has been created and reviewed with the appropriate
project stakeholders, the project plan baseline should be created. The
project plan baseline creates a permanent record of the original project plan
so that performance against the plan can be measured and monitored
throughout the duration of the project. Monitoring performance against
the schedule and budget of a project can provide valuable feedback during a
project to allow for project plan adjustment and contingency planning.
Reflecting on project performance at the conclusion of a project can provide
effective feedback on the accuracy of estimating techniques and quality of
project planning. Once the project plan is complete and reviewed, upon the
advice of the project manager, the PMO will baseline the project plan in
- Project Plan
- Project Plan with
initial baseline
Project Manager (Owner)
Portfolio Management
Office
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Planning Phase
Page 22 of 67
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
Clarity. If the baselined estimates exceed approved estimates by 50% (Level
1) or 30% (Level 2), the project must go back to ITPC for additional review.
Also, for Level 1 projects, if the baseline estimate exceeds 60 days of effort
or $100,000, the project must go back to ITPC and AAMT for Level 2
approval. ITPC must also approve any material change in scope, defined as a
25% change in project duration or 10% change in resource requirements. If
in the course of a project, approved change requests alter the scope and
timing of the project plan, the plan may be re-baselined to track against the
modified plan.
Project status updates are due on the 1
st
and 15
th
of each month and are
reported in Clarity.
Develop the
Application
Deployment Plan
The Application Deployment Plan is a comprehensive deployment document
used throughout the project to prepare the development, test, and
production infrastructure and to gather data needed for the deployment
process. This document also identifies the hardware/software needs for the
new application as well as the logistics and delivery plans for such
components. Identification of these resources at this stage will allow the
Operations group to begin to plan for the acquisition or provisioning of the
equipment. In subsequent phases, this assessment will be refined and the
actual products will be ordered.
- ITPC Template
- Project Plan
- Application
Deployment Plan
Deployment (Owner)
Project Manager
Development
Application Deployment
Plan
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
pplicationDeploymentTe
mplate.docx
Communication
Throughout the course of a project there are a number of recurring activities
related to communication. These include the activities identified in the
communication plan, which typically consist of:
Weekly project team status reports (Template provided which
offers a standardized agenda for status meetings throughout the
course of a project)
Maintaining SharePoint workspace with meeting agendas,
minutes, decisions, documentation, and status reports.
Project sponsor meetings for reviewing significant project plan
changes and progress
Informal communication: walk-abouts, hallway conversations,
and personal emails
There are enhanced processes and requirements regarding project
monitoring and control for large projects (those with greater than 5,000
hours of effort or $250,000) or any projects deemed of sufficient risk. These
should be identified in the project communication plan, but are outlined
here as well.
For these projects it is advisable that a Steering Committee or Oversight
Group be formed to monitor the project execution and collaborate on key
project decisions. Templates for Large Projects are included as follows:
Steering Committee Reporting Template – This is a reporting
package for periodic steering committee meetings and includes
standardized sections for:
o Project Timeline
o Significant Event Review
-Communication
Plan
-Various
communication
outputs per the
Communication Plan
Project Manager (Owner)
Project Team
Portfolio Management
Office
Templates for various
types of meetings as well
as guides to using Clarity
and SharePoint can be
found in the Sharepoint
Document Library.
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Planning Phase
Page 23 of 67
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
o Significant Risks / Issues
o Metric Tracking
o Change Request and Defect Tracking
o Budget Report
o Other
Large Project Budget Workbook – This is a multi-tabbed Excel
spreadsheet for tracking actual versus budgeted costs for
internal/external labor and non-labor items.
All projects of this nature will have a unique set of circumstances which will
require extensive customization of the communication plan.
Monitor and
Control
Throughout the course of a project there are a number of recurring
activities related to keeping the project on track and making adjustments to
the plan when needed. At a minimum, these activities include:
Managing risks and issues in Clarity
Manage change requests (see note below)
Following up on tasks and enforcing schedule
Managing action items in SharePoint
Updating project plan in Clarity:
Tasks
Resources
Schedule
Complex or large projects may require additional monitoring effort. The
PMO can help in developing reports and tools to keep your project on
budget and on schedule.
Change requests
Change requests can be generated during the design, construction and
various testing phases. Change requests are defined as major feature or
functionality changes that the customer would like to have included in the
system but will impact the scope, budget, or schedule of the project. The
SDLC provides an iterative approach where requirements are further
defined and changes to the system are anticipated to some extent. For
larger changes, a more formal change request process should be followed.
Change requests are managed by a process that includes prioritizing the
request, estimating the amount of work required to include the request in
the system, and setting expectations regarding when the change request
work will be scheduled. Change requests require the re-initiation of the unit
testing, deployment, and detailed testing cycle.
- Project Charter
- Communication
Plan
-Project Plan
-Updated project
plan
-Risks, issues, and
change requests in
Clarity
-Action items in
SharePoint
Project Manager (Owner)
AFM
Portfolio Management
Office
The PMO Monthly
Checklist is a good guide
for monitoring and
controlling a project.
PMO Monthly Checklist
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle >
Guides >
UpdatingAProject-
PMOChecklist.pdf
In addition, please see
the course materials
available in the the
Sharepoint Document
Library.
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Design Phase
Page 24 of 67
Analysis Phase
Deployment
Security
Operations
Quality
Assurance
Development
Analyst
Phase
Inputs
4.1 Analysis
Customer
Project Manager
Application
Design
Develop Application Design
1
Develop Testing Strategy
Testing
Strategy
Schedule EAC Review
EAC
Review
Review Application Design
Conduct Security Review
Revise Application Deployment Plan
Conduct DWG Design Collaboration
EAC
Review
Needed?
Yes
Define Business Rules
Training
Strategy
1
Business
Rules
Application
Design
Review
Develop Training Strategy
Review Application Design
Project
Plan
Project
Charter
Application
Deployment
Plan
Application
Deployment
Plan
Application
Design
Develop Integration / Enterprise Objects Template
Integration
/ EO
Templates
Business
Rule Review
Conduct Baseline Access Control Review
Security
Review
Template
Access
Req /
Controls
AITS
SDLC
Software Development
Life Cycle
Communic-
ation Plan
Project
Proposal /
ITPC
Monitor and Control
Communication
Develop Conversion Strategy
Conversion
Strategy
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Design Phase
Page 25 of 67
Phase 4.1 – Analysis
The purpose of the Analysis Phase is to define and document the functional requirements and begin designing the system; this includes
defining the business rules for the application and reflecting those rules within the Application Design Document. The Development
Working Group (DWG) works with the development team to define the development strategy and identify the standard and approved
architectural components and services to be used. If the application requires a deviation from architectural standards or would benefit
from additional architectural input, then the Analyst will work with the EAC to schedule a review and use existing documents such as the
Application Design Document for the review. Testing and training strategy documents will be developed and the Application Deployment
Plan will continue to be refined. Security will be reviewed from both an application standpoint as well as access needs for the project
team.
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
Define Business
Rules
General business rules will be gathered and defined for the system. These
rules will reflect business processes and policies that must be supported
through the various components of the application. Each rule has a unique
identifier and will be referenced in the Application Design Documents. The
business rules will define both the rules that are within the scope of the
project and those rules that are outside of the scope of the project and
handled elsewhere. For smaller applications, the business rules may just be
defined within the Application Design Document.
- Project Proposal
- Project Charter
- Business Rules
Document
Analyst (Owner)
Customer
Business Rules Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
BusinessRulesTemplate.xlsx
Business Rule
Review
A review of the business rules will be held to review the completeness and
understanding of the business rules. The rules will be reviewed by the
analysts and developers to ensure their ability to translate the business rules
into concise specifications.
- Business Rules
Document
- Business Rules
Document
Analyst (Owner)
Customer
Development
Conduct DWG
Design
Collaboration
The Development Working Group (DWG) Design Collaboration is intended to
work with developers and analysts to determine design options and guide
the design of the technical solution for the project to meet system and
architectural standards at AITS. The DWG is comprised of senior application
developers, architects, EAI, ICC members, and analysts, and looks to
leverage reusability of components and services. The DWG helps to control
the introduction of new technology and methods into the developer toolkit.
The DWG will also work with the EAC (Enterprise Architecture Committee) to
put projects through the appropriate process. Members of the EAC meet
with analysts to determine if the projects require any monitoring or active
involvement by the EAC.
- Application Design
Document
- Application Design
Document
Development (Owner)
Analyst
Development Working
Group (DWG)
DWG Charter
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides > DWGCharter.docx
Develop
Application
Design
The documentation of functional requirements for the project is a
collaborative effort involving analysts, developers, and key client personnel.
This document is initially built during this phase and is iteratively enhanced
with more detailed information throughout the development life cycle.
- Project Proposal
- Project Charter
- Business rules
- DWG/EAC review
- Application Design
Document
Analyst (Owner)
Development
Customer
Application Design
Template
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Design Phase
Page 26 of 67
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
Functional requirements will be documented in an Application Design
Document that includes the following components:
Application Overview - A high level overview of business
processes and business requirements.
Application Flow Diagram - Displays impacts and actions for all
processes involved in the design.
User Access + Security - Specifies the various user groups that can
access the application.
Design Specifications - Detailed design for Web Applications,
Batch Applications, and Reports.
Data Dictionary - Provides a description of the data for each input
retrieved from a database table and output written to a database table.
results
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
ApplicationDesignTemplate.
docx
Develop
Integration
Overview/
Enterprise
Objects (EO)
Template
If it is determined that the application requires development of new EAI
integrations or new versions of existing integrations, Integration Overview
Templates will be produced for each new integration. If the integration
requires new enterprise objects to be produced, templates will be started
which will help identify and define the enterprise objects.
- Application Design
Document
- Integration
Overview Template
- Enterprise Objects
Template
Analyst (Owner)
Development
Integration Overview
Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
IntegrationOverviewTempla
te.docx
EO Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
EnterpriseObjectTemplate.d
ocx
Develop
Conversion
Strategy
Some implementations will require the conversion of data from existing
systems into the new system. During the Analysis and Design phases, the
source systems will be identified, the data selection criteria will be
determined and crosswalk s and business logic will be designed. The
acceptance criteria for the conversion will also be established with the
customer.
- Project Proposal
- Project Charter
- Business rules
- Application Design
- Conversion Strategy
Analyst (Owner)
Development
Project Manager
Conversion Process Guide
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle >
Guides >
ConversionProcessGuide.do
cx
Conduct EAC
Review
If it is determined that the EAC needs to be involved in a project, the analyst
will present the project at a regularly scheduled EAC meeting.
- Application Design
Document
- Application Design
Document
Analyst (Owner)
Architecture
Project Manager
Development
Security
Conduct Security
Review
The storage, handling, and usage of sensitive data, such as (but not limited
to) Social Security Numbers, will be examined to prevent data exposure. As
- Application Design
Document
- Security Review
Template
Analyst (Owner)
Project Manager
Security Review Template
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Design Phase
Page 27 of 67
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
sensitive data usage is identified, appropriate departmental approvals will
be obtained and functionality will be added to the application to minimize
the data exposure. If SSN is being used, review and approval by the
University SSN Committee is required. Data storage, handling and usage
requirements are documented in the Security Review Template.
- Business Rules
Security
Business Owners
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SecurityReviewTemplate.do
cx
Conduct Baseline
Access Control
Review
Access requirements to the different environments (databases, linux, unix,
etc.) should be identified early in the project. This includes new accounts
that need to be created, how access will be granted in development, QA,
production, etc. and any access logs that are delivered or need to be
created.
Controls should also be reviewed at this time, including vendor-delivered
controls, detective and/or corrective controls.
- Application Design
Document
- Access
Requirements
Template
- Access Control
Template
Analyst (Owner)
Project Manager
Security
Access Requirements
Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SecurityAccessRequirement
sTemplate.doc
Baseline Access Control
Review Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SecurityBaselineAccessCont
rolReviewForApplications.d
ocx
Conduct
Application
Design Review
The Application Design and Business Rules will be examined for
completeness; adherence to scope; and that client needs have been met.
Any deficiencies will be addressed to avoid rework later in the project.
- Application Design
Document
- Business Rules
- Revised Application
Design Document
Analyst (Owner)
Project Manager
Development
Customer
Develop Training
Strategy
The training strategy will define training objectives, roles, and
responsibilities. Additionally, the type of training, schedule, references,
dependencies and type of materials that will be required will be identified
during this stage. This is a high level description with specific details to be
added in a later process.
- Project Charter
- Business Rules
- Application Design
Document
- Training Strategy
Project Manager
(Owner)
Training Team
Customer
Training Strategy Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
TrainingStrategyTemplate.d
ocx
Develop Testing
Strategy
The testing strategy will identify the approach, goals, timeline, participants,
needs, and dependencies The strategy will define the overall goals and
execution but will leave the specific details to be defined in a later process.
- ITPC Template
- Application Design
Document
- Testing Strategy
Project Manager
(Owner)
Customer
Analyst
QA team
Testing Strategy Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
TestingStrategyTemplate.do
cx
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Design Phase
Page 28 of 67
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
Revise
Application
Deployment Plan
The initial Application Deployment Plan should be reviewed and updated as
needed. The new hardware and software requirements should be reviewed
and compared to the ITPC hardware/software template requirements.
Additional costs should be communicated back.
- Application
Deployment Plan
- Application
Deployment Plan
Deployment (Owner)
Development
Analyst
Application Deployment
Plan
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
pplicationDeploymentTempl
ate.docx
Communication
The various forums and communication mechanisms identified in the
communication plan continue to be performed as the project progresses. As
the project moves into new phases, additional types of communication
activities may become necessary and activities previously done may need to
evolve or be eliminated as participants change or the project focus shifts.
-Communication
Plan
-Various
communication
outputs per the
Communication Plan
Project Manager
(Owner)
Project Team
Portfolio Management
Office
Templates for various types
of meetings as well as
guides to using Clarity and
SharePoint can be found in
the Sharepoint Document
Library.
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle
Monitor and
Control
Throughout the course of a project there are a number recurring activities
related to keeping the project on track and making adjustments to the plan
when needed. At a minimum, these activities include:
Managing risks and issues in Clarity
Manage change requests
Following up on tasks and enforcing schedule
Managing action items in SharePoint
Updating project plan in Clarity:
Tasks
Resources
Schedule
Complex or large projects may require additional monitoring effort. The
PMO can help in developing reports and tools to keep your project on
budget and on schedule.
- Project Charter
- Communication
Plan
-Project Plan
-Updated project
plan
-Risks, issues, and
change requests in
Clarity
-Action items in
SharePoint
Project Manager
(Owner)
AFM
Portfolio Management
Office
The PMO Monthly Checklist
is a good guide for
monitoring and controlling
a project.
PMO Monthly Checklist
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle >
Guides > UpdatingAProject-
PMOChecklist.pdf
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Design Phase
Page 29 of 67
Design Phase
Operations
Deployment
Security
Quality
Assurance
Development
Analyst
Project
Manager
Customer
Develop Training Plan
Develop Style Guide
Develop Service Guide
Revise Application Design
Revise Application Design
Develop QA Master Test Plan
Complete Sensitive Data Usage Form
Application
Design
EAC
Review
Schedule EAC
Review
Conduct DWG Design Collaboration
EAC
Review
Needed?
Training
Plan
Style Guide
Sensitive
Data Use
Form
Application
Design
Application
Design
Review
Service
Guides
Revise Business Rules
Business
Rules
1
1
QA Master
Test Plan
Yes
Conduct Security Review
4.2 Design
Phase
Inputs
Training
Strategy
Business
Rules
Application
Design
Testing
Strategy
Project
Plan
Order New Hardware and Software
Revise Application Deployment Plan
Application
Deployment
Plan
Application
Deployment
Plan
2
2
Integration /
EO
Templates
Security
Review
Template
Access
Requirements
/ Controls
Develop Integration / Enterprise Objects Template
Integration/
EO
Templates
Access
Requirements
/ Controls
Security
Review
Template
AITS
SDLC
Software Development
Life Cycle
Communic
-ation plan
Monitor and Control
Communication
Manage Change Requests
CR Log
Revise Conversion Strategy
Conversion
Strategy
Conversion
Strategy
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Design Phase
Page 30 of 67
Phase 4.2 – Design
The purpose of the Design Phase is to develop and document detailed technical specifications for the application. The Application Design
Document developed during the Analysis phase is further refined and more detail is added to the specification. Other design specifications
such as integration templates, style guides, and service guides are produced as well. A master test plan is created that outlines the types
of testing that will be needed for the project. An EAC review will be held if determined necessary by the Development Working Group
(DWG). A detailed training plan is developed by the customer if the need exists. New hardware and software will be ordered if required by
the project.
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Revise
Application
Design
Document
The Application Design Document that was started during the Analysis phase
will be further refined to provide more technical details regarding the
application. The Design Specifications section will be augmented to include
detailed edits, business rules, pseudo code, screen action behaviors,
frameworks, etc.
- Application Design
Document
- Revised Application
Design Document
Analyst (Owner)
Development
Application Design Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
ApplicationDesignTemplate.do
cx
Revise Business
Rules
As designs become more detailed customers may update the business rules
for the system. The rules are reflected within the Application Design
Documents utilizing the unique identifier or for smaller applications, the
rules may be defined directly within the Application Design Document.
Major changes or additions of business rules may result in an increased
scope of the project. Changes to scope will be handled through the Change
Request Management process.
- Business Rules
Document
- Application Design
Document
- Business Rules
Document
Customer
Analyst (Owner)
Business Rules Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
BusinessRulesTemplate.xlsx
Conduct DWG
Design
Collaboration
The Development Working Group (DWG) Design Collaboration effort
provides continued support from the DWG team to address design issues
and changes in design approach. It continues to look to leverage reusability
of components and services and help control the introduction of new
technology and methods into the developer toolkit.
The DWG also recommends proceeding with EAC Reviews when deemed
necessary. An EAC Review may be necessary when analysis reveals that a
non-standard approach may be required in the construction of the technical
solution for the project or the overall complexity of the application warrants
a review. When an EAC Review is required, the DWG works with the
application developer to determine the appropriate documentation for the
EAC Review.
- Application Design
Document
- Application Design
Document
Development (Owner)
Analyst
Development Working
Group (DWG)
DWG Charter
AITS Intranet:
Documentation Library >
Methodology > SDLC > Guides
> DWGCharter.docx
Develop Style
Guide
For web applications, a Style Guide is developed which specifies the agreed
upon ‘look and feel’ of the Web components of the system. For application
consistency for users, Style Guides from previous systems in that functional
area should be used as a starting point. This will help keep application look
- Application Design
Document
- Style Guide
Analyst (Owner)
Development
Web Application Style Guide
AITS Intranet:
Documentation Library >
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Design Phase
Page 31 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
and feel consistent for users of multiple applications. When required, a link
to this document is included in the ATO.
Methodology > SDLC >
Templates and Forms >
WebApplicationStyleGuide.doc
x
Revise
Integration
Overview /
Enterprise
Objects (EO)
Templates
If it is determined that the application requires development of new EAI
integrations or new versions of existing integrations, Integration Templates
will be produced for each new integration. If documents were started in the
Analysis phase, then they will be revised as the Design phase progresses.
- Integration
Overview Template
- Enterprise Objects
(EO) Template
- Application Design
Document
- Integration
Overview Template
- Enterprise Objects
(EO) Template
Analyst (Owner)
Development
Integration Overview Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
IntegrationOverviewTemplate.
docx
EO Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
EnterpriseObjectTemplate.doc
x
Revise
Conversion
Strategy
Some implementations will require the conversion of data from existing
systems into the new system. During the Analysis and Design phases, the
source systems will be identified, the data selection criteria will be
determined and crosswalk s and business logic will be designed. The
acceptance criteria for the conversion will also be established with the
customer.
- Project Proposal
- Project Charter
- Business rules
- Application Design
- Conversion Strategy
Analyst (Owner)
Development
Project Manager
Conversion Process Guide
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle >
Guides >
ConversionProcessGuide.docx
Develop Service
Guide
A service is functionality developed by AITS and provided or access granted
to customers outside of AITS. Examples of services would be web services,
Java Library Files and JMS Objects. Customers of these services usually
have their own development staff.
As new services are identified during the design process, a service guide will
be produced. The Service Guide is used by subscribers of the service and
provides the necessary information for accessing and utilizing the service.
- Application Design
Document
- Service
Implementation
Guide
Analyst (Owner)
Development
Service Guide Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
ServiceGuideTemplate.docx
Sample Service Guide
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Examples>
SAMPLE_ServiceGuide.docx
Conduct EAC
Review
An initial or follow up EAC review will be scheduled if required. Changes that
result from the meeting will be documented in the Application Design
Document.
- Application Design
Document
- Application Design
Document
Enterprise
Architecture
Committee (EAC)
Analyst (Owner)
Project Manager
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Design Phase
Page 32 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Development
Conduct Security
Review
An initial review of security requirements may have been started in the
Analysis phase. As such, the Security Review, Access Control Review, and
Baseline Access Control Review templates should be reviewed and revised if
necessary. This process will help identify the storage, handling, and usage
of sensitive data, such as (but not limited to) Social Security Numbers, will be
examined to prevent data exposure. The findings in this review may
facilitate design adjustments. The review will also help establish
environment access and request processes needed for project team
members in the Development, Test, Training, and pre-production
environments.
- Application Design
Document
- Business Rules
Security
Project Manager
Analyst (Owner)
Security Review Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SecurityReviewTemplate.docx
Access Requirements
Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SecurityAccessRequirementsTe
mplate.doc
Baseline Access Control
Review Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SecurityBaselineAccessControl
ReviewForApplications.docx
Complete
Sensitive Data
Usage Form
If it has been identified that the application is using sensitive data (e.g., SSN)
and there are no alternatives to that data, then a SSN Acceptable Use
template must be completed and signed by the authorized department head
from the customer’s unit.
- Application Design
Document
- Business Rules
- SSN Acceptable Use
Template
Analyst (Owner)
Security
Project Manager
SSN Usage Guidelines
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides>
SSNGuidelinesForAITSDevelop
edApplications.docx
SSN Acceptable Use Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
AITSApplicationSSNAcceptable
UseTemplate.docx
Conduct Design
Review
The design will be examined for adherence to existing standards and
functional completeness. The review also provides the opportunity to refine
- Application Design
Document
- Application Design
Document
Analyst (Owner)
Customer
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Design Phase
Page 33 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
the Application Design prior to the beginning of construction. Any
deficiencies and refinements will need to be documented and corrected
before continuing with the product development.
- Service Guide
- Integration
Overview Template
- Enterprise Objects
(EO) Template
- Business Rules
- Style Guide
- Service Guide
- Integration
Overview Template
- Enterprise Objects
(EO) Template
Development
Project Manager
Quality Assurance
Security
Develop QA
Master Test Plan
The Quality assurance team will review and document with the project
manager the types of testing that QA has to offer and what will be needed
for the specific project.
The different types of testing are:
Functional Test - verify that the application is functioning
according to specifications.
Regression Test - test changes in software to make sure other
areas of application haven't been impacted.
Performance Test:
Load Testing: Measures response times, transaction rates, and
other time sensitive requirements associated with the application. The goal
of Performance testing is to verify that the performance requirements have
been achieved.
Stress Testing: identifies the peak load the system can handle. It
is intended to find errors due to low resources or competition for resources.
Low memory or disk space may reveal defects in the software that aren't
apparent under normal conditions.
Volume Testing: subjects the software to large amounts of data
to determine if limits are reached that cause the software to fail. Volume
testing also identifies the continuous maximum load or volume the system
can handle for a given period of time.
Configuration Test - Configuration testing verifies operation of
the software on different software and hardware configurations. This would
include testing of operating systems and browsers.
- Application Design
Document
- QA Master Test
Plan
Quality Assurance
(Owner)
Project Manager
QA Master Test Plan Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
QAMasterTestPlanTemplate.d
ocx
Develop Training
Plan
If a need for training has been identified a detailed training plan will be
developed based on the functional requirements.
- Training Strategy
- Application Design
- Business Rules
- Training Plan
Document
Customer (Owner)
Manage Change
Requests
Change requests can be generated during code design, construction and
various testing processes. Change requests are defined as features or
functions that the customer would like to have included in the system but
were not included in the specifications in the Application Design Document.
Change requests are managed by a process that includes prioritizing the
request, estimating the amount of work required to include the request in
the system, and setting expectations regarding when the change request
work will be scheduled. Change requests require the re-initiation of the unit
testing, deployment, and detailed testing cycle.
- Application Design
Document
- Change Request Log
Project Manager
(Owner)
Analyst
Customer
Change Request Log
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SoftwareChangeRequestLog.xl
sx
Change Request Form
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Design Phase
Page 34 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SoftwareChangeRequestTempl
ate.xlsx
Revise
Application
Deployment Plan
The Application Deployment Plan should be reviewed and updated as
needed.
At this stage the new components section should be fully documented, the
new infrastructure components identified and the logistics/delivery plans
completed. Also all new hardware should be ordered at this point.
- Application
Deployment Plan
- Application
Deployment Plan
Deployment (Owner)
Development
Analyst
Application Deployment Plan
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
pplicationDeploymentTemplat
e.docx
Order Hardware
/ Software
The project manager will work with operations to ensure that the hardware
and software required for development of the product are ordered.
- Application
Deployment Plan
- Hardware /
Software Order
Operations (Owner)
Project Manager
Communication
The various forums and communication mechanisms identified in the
communication plan continue to be performed as the project progresses. As
the project moves into new phases, additional types of communication
activities may become necessary and activities previously done may need to
evolve or be eliminated as participants change or the project focus shifts.
-Communication Plan
-Various
communication
outputs per the
Communication Plan
Project Manager
(Owner)
Project Team
Portfolio Management
Office
Templates for various types of
meetings as well as guides to
using Clarity and SharePoint
can be found in the Sharepoint
Document Library.
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle
Monitor and
Control
Throughout the course of a project there are a number recurring activities
related to keeping the project on track and making adjustments to the plan
when needed. At a minimum, these activities include:
Managing risks and issues in Clarity
Manage change requests
Following up on tasks and enforcing schedule
Managing action items in SharePoint
Updating project plan in Clarity:
Tasks
Resources
Schedule
Complex or large projects may require additional monitoring effort. The
PMO can help in developing reports and tools to keep your project on
budget and on schedule.
- Project Charter
- Communication
Plan
-Project Plan
-Updated project
plan
-Risks, issues, and
change requests in
Clarity
-Action items in
SharePoint
Project Manager
(Owner)
AFM
Portfolio Management
Office
The PMO Monthly Checklist is
a good guide for monitoring
and controlling a project.
PMO Monthly Checklist
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle >
Guides > UpdatingAProject-
PMOChecklist.pdf
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Construction Phase
Page 35 of 67
Construction Phase
4.3 Construction
Deployment
Security
Operations
Quality
Assurance
Development
Analyst
Project Manager
Customer
Phase
Inputs
Develop Application
Project
Plan
Access
Requirements
/ Controls
Training
Plan
Style Guide
Sensitive
Data Use
Form
Application
Design
Security
Review
Template
Integration /
EO
Templates
Service
Guides
Business
Rules
QA Master
Test Plan
Develop Performance Test Plan
Performance
Test Plan
Develop Training Materials
Perform Alpha Testing
Training
Materials
User
Guides
Customer
Test Plan
Develop Customer Test Plan
Develop User Guides / Help Materials
Monitor, Control, and Communicate
Manage Defects
Revise Application Design
Application
Design
Perform Functional Testing
Develop HTML
Code Application
Perform Unit TestsCode Bug Fixes
Deploy
Code Change Requests
Application
Design
EAC
Review
Schedule EAC
Review
Conduct DWG Design Collaboration
EAC
Review
Needed?
Code
Review
Execute Performance Test
Build Functional Test Cases and Automated Test Scripts
Configure / Deploy Infrastructure Components
Revise Application Deployment Plan
Application
Deployment
Plan
Perform Application Security Scans
Revised
Test
Cases
Create Application Technical Overview
Application
Technical
Overview
User
Show &
Tell
Revise Business Rules
Business
Rules
Application
Vulnerability
Reports
Test
Cases
Execute Functional Test Cases
Install / Configure Hardware and Software
Develop System Test Plan
System
Test Plan
Performance
Test Results
Test
Scripts
AITS
SDLC
Software Development
Life Cycle
1
1
Develop Customer Test Plan
Conduct Security Review
Access
Requirements
/ Controls
Security
Review
Template
Defect
Report
Application
Deployment
Plan
CR Log
Communic-
ation plan
Manage Change Requests
CR Log
Database Performance Review
Conversion
Strategy
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Construction Phase
Page 36 of 67
Phase 4.3 – Construction
The purpose of the Construction Phase is to build the application program code as specified in the Application Design Document. The
construction of the application is done in an iterative fashion with involvement from the customers and analysts who review the application
as it is being built and identify issues, gaps, and incomplete business rules through demonstration and actual use of the application. The
demonstration of the application with the customers occurs through Show and Tell sessions where developers exhibit the application
functionality to the customers. Testing preparation and execution also gets underway as functional test cases, customer test plans, and
performance test plans are built and executed during this phase. The testing is performed through functional testing by Quality Assurance
and the analysts and then by the customers in Alpha testing. Performance testing and Security Scans are done to initially identify any major
issues that need to be addressed quickly in order to minimize potential impacts to the application. In preparation for future phases, the
Application Deployment Plan is revised, and the customers begin to develop training materials, user guides, and help materials. An
Application Technical Overview (ATO) document is produced that serves to describe the components of the application and link the various
design documents and service guides together. The ATO will become a key document used in support of the application in the future. An
EAC review will be held if determined necessary by the Development Working Group (DWG) or if it has been previously decided that the
application should have periodic EAC touch points.
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Install / Configure
Hardware and
Software
Hardware and software needed to support the project will be installed at
this time. This may include hardware for development, test, and production.
- Hardware /
Software Order
Operations (Owner)
Configure and
Deploy
Infrastructure
Components
Infrastructure components will be built to support the application in the
operational environment. The various components could include: LDAP,
queries, topics, connections, router, proxy, and Tomcat.
- Application
Deployment Plan
Deployment (Owner)
Operations
Develop
Application
The Development and Unit Test Cycle includes several work components
and, as the name implies, is cyclical in nature.
Develop HTML – HTML code is written using the screen mock-ups
or wireframes as a guide.
Code Application - Application program code is written by the
development team in accordance with the Application Design Document and
ADSD coding standards.
Code Bug Fixes – During the code construction and various
testing processes, bugs in the application program code may be reported.
Bugs are defined as functions within the application program code that do
not match the specifications in the Application Design Document. These
bugs must be fixed within the application program code as part of the
project and within the project timeline. Bug fixes require the re-initiation of
the unit testing, deployment, and detailed testing cycle.
- Application Design
Document
- Application
Technical Overview
- Style Guides
- Service Guides
- Program Code
- AppWorx Chains
- Code Review
Documents
- Unit Test Results
Development (Owner)
Analyst
Customer
Application Development
standards
AITS Intranet:
Departments > ADSD -
Application Development and
Support > Shared Documents
> Development Standards
Documentation >
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Construction Phase
Page 37 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Code Change Requests – As change requests are identified the
change is scoped which includes reviewing project timelines, budgets, or
staffing levels that may need to be revised in order to accommodate the
change. Once approved, the change request is added to the designs and test
plans and is coded within the application.
Perform Unit Tests – Individual Application program code
components or programs are tested by the development team. As
components are successfully tested, related components are tested together
prior to QA testing, system testing, or customer testing.
Deploy – As unit testing progresses, the application is deployed to
a test or QA environment where in-depth QA or system testing can occur.
Customer Show and Tell – This is an opportunity to show clients
the progress being made in the construction of the program code. Feedback
from customers during the early stages of the code construction process is
critical to creating a system that the customers will be happy with at the
conclusion of the project.
Revise Business
Rules
As development and testing get underway, it may be determined that
business rules are missing or incorrect. The rules are maintained within the
Business Rules Document and are reflected within the Application Design
Documents. As rules are changed, added, or removed, the impact is
assessed and managed through the Change Request Management process.
- Business Rules
Document
- Application Design
Document
- Business Rules
Document
Customer
Analyst (Owner)
Business Rules Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
BusinessRulesTemplate.xlsx
Revise Application
Design Document
The Application Design Document that was started during the Analysis phase
will be updated throughout the development process. As changes or
clarifications are made, the document is updated and republished. Any
change that impacts the scope of the project must be sent through the
Change Request Management process. This document will be used as the
standard for determining defects within the Quality Assurance activities.
- Application Design
Document
- Revised Application
Design Document
Analyst (Owner)
Development
Application Design Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
ApplicationDesignTemplate.d
ocx
Conduct DWG
Design
Collaboration
The Development Working Group (DWG) Design Collaboration effort
provides continued support from the DWG team to address design issues
and changes in design approach. It continues to look to leverage reusability
of components and services and help control the introduction of new
technology and methods into the developer toolkit.
The DWG also recommends proceeding with EAC Reviews when deemed
necessary. An EAC Review may be necessary when analysis reveals that a
non-standard approach may be required in the construction of the technical
solution for the project or the overall complexity of the application warrants
a review.
- Application Design
Document
- Application Design
Document
Development (Owner)
Analyst
Development Working
Group (DWG)
DWG Charter
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides > DWGCharter.docx
Conduct EAC
Review
An initial or follow up EAC review will be scheduled if required. Changes that
result from the meeting will be documented in the Application Design
Document.
- Application Design
Document
- Application Design
Document
Enterprise Architecture
Committee (EAC)
Analyst (Owner)
Project Manager
Development
Security
Conduct Security
Security reviews began in the Analysis phase and has continued through
- Application Design
Security
Security Review Template
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Construction Phase
Page 38 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Review
Design and into Construction. The review continues to review the handling
and management of sensitive data, access and authorizations built into the
system and during construction will review any vulnerabilities that are
identified and can’t be resolved. The findings in this review may facilitate
design adjustments.
Document
- Business Rules
- Application
Vulnerability Reports
Project Manager
Analyst (Owner)
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SecurityReviewTemplate.doc
x
Access Requirements
Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SecurityAccessRequirements
Template.doc
Baseline Access Control
Review Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SecurityBaselineAccessContr
olReviewForApplications.doc
x
Perform Code
Review
The purpose of code reviews is to ensure that the code written by
application development is of high quality and that it adheres to ADSD
coding standards. Code reviews are usually held near the end of unit
testing, but they may be held at any stage of the code construction process,
depending on the complexity of the code. Code review notes contain
information about what was found during the code review, what code needs
to be fixed, and confirmation that the coding changes were completed.
- Program Code
- AppWorx Chains
- Unit Test Results
- Add code review
notes to Application
Design Document
Development (Owner)
Analyst
Security
Application Walkthrough
Guidelines
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides >
AITSDevelopmentWalkThrou
ghGuidelines.rtf
Develop
Application
Technical
Overview
The Application Technical Overview will provide a link to the Application
Design Document and other technical design documents that are needed to
develop the application.
Application Design Document – A product of the Analysis Phase, the
Application Design Document includes an overview of the application, a
high-level project timeline, an application flow diagram, user
access/security, design specifications, a data dictionary, and other
information critical to the proper understanding of the application that is to
be built. A link to this document is included in the ATO.
System Requirements – This section of the ATO includes information
- Application Design
Document
- Style Guides
- Service Guides
- Application
Technical Overview
Development (Owner)
Analyst
Application Technical
Overview Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
ApplicationTechnicalOvervie
wTemplate.docx
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Construction Phase
Page 39 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
about the internal architecture of the application, as well as the required
versions of Java, Tomcat, AppWorx, and Oracle.
Reusable Components – This section of the ATO identifies components
that can be reused in this application or that can be added to the internal
framework so that the component can be reused across applications.
Data Model + Schemas – This section of the ATO identifies the location
of the Data Model and specifies the database and schemas.
Screen Mock-Ups – This section of the ATO includes a link to the screen
mock-ups or wireframes for the Web components of the system.
Reports – This section of the ATO includes a list of the reports, with a
brief description, required for the system. When required, a link to the
report specifications document is included.
Accessibility Review Document – The Accessibility Review Document is
the summation of the customer accessibility requirements for the Web
components of the system. When required, a link to this document is
included in the ATO.
Integration Template – The Integration Template is a required
deliverable from integration analysis. When required, a link to this
document is included in the ATO.
Service Guide - When required, a link to this document is included in
the ATO.
Sensitive Data Usage Form – The Sensitive Data Usage Form identifies
sensitive data that must be used within the system and specifies the reasons
why the sensitive data must be used. When required, a link to this
document is included in the ATO.
Build QA
Functional Test
Cases and
Automated Test
Scripts
The Testing Team will develop detailed test cases that will identify the
business rules and functionality of the application that should be tested.
These test cases should be reviewed by the AITS Analyst assigned.
Automated test scripts can be developed when the development of the
application is almost complete. These test scripts will be utilized in the
future for regression testing.
- Application Design
Document
- Business Rules
- Test Cases
- Automated Test
Scripts
Quality Assurance
(Owner)
Analyst
QA Mater Test Plan Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
QAMasterTestPlanTemplate.
docx
QA Test Management Tool
Testers Guide
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides >
QA_TestManagementTool_T
estersGuide.docx
Execute
Functional Test
Cases
The Testing Team will execute the tests that were developed to test the
business rules and functionality of the application. The test results will be
documented and defects will be filed.
- Test Cases
- Test Scripts
- Revised Test Cases
Quality Assurance
(Owner)
Analyst
Development
QA Test Management Tool
Testers Guide
AITS Intranet:
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Construction Phase
Page 40 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Customer
Documentation Library >
Methodology > SDLC >
Guides >
QA_TestManagementTool_T
estersGuide.docx
Develop System
Test Plan
A system test plan will identify the high level activities necessary to
complete an overall end-to-end test of the system. Factors such as database
prep, set-up configuration, development timelines, processing requirements
and the timing of Dress Rehearsals need to be taken into consideration as
the plan is developed. Additional, detailed scenarios may need to be
created, in addition to the overall test plan.
- Application Design
Document
- System Test Plan
Analyst (Owner)
Guide for System Test Plans
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides >
SystemTestingOutline.docx
Perform
Functional Testing
As software completes unit testing, it is turned over to the analysts to
perform Functional Testing of the application. The testing is performed to
measure compliance to specifications and business rules as well as
adherence to specifications. As issues are identified, they are
communicated back to the developer and tracked in the Defect and Change
Request Management systems. This round of Functional Testing is done in
preparation of hand-off to the customers for testing.
- Business Rules
- Application Design
Document
- System Test Plan
Analyst (Owner)
Development
Functional Test Plan
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
Functional_Test_Plan_Templ
ate.xlsx
Develop
Performance Test
Plan
If performance testing is required for a project, the following needs to be
identified and documented:
o Purpose of the performance test
o URL of the application to test
o Exact steps that a user of the application would do in production do
o Database that will be used for the test and what type of access QA will
need
o Number of concurrent users
o Number of user Login IDs needed for test
o Determine how test environment hardware compares to production
o Determine Acceptance Criteria
QA will develop automated performance test scripts based on the
requirements specified in the performance test plan.
- Requirements for
Performance Test
- Performance Test
Plan
- Performance Test
Scripts (automated)
Quality Assurance
(Owner)
Project Manager
Analyst
Performance Test Questions
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
QAPerformanceTestQuestion
s.docx
Execute
Performance Test
Performance testing is done to ensure that the application performs under
peak volume times as periods of high load. The testing can be broken down
into these components:
Load Testing: Measures response times, transaction rates, and other time
sensitive requirements associated with the application. The goal of
Performance testing is to verify that the performance requirements have
been achieved.
Stress Testing: is intended to find errors due to low resources or competition
for resources. Low memory or disk space may reveal defects in the software
that aren't apparent under normal conditions. Other defects might results
- Performance Test
Plan
- Performance Test
Scripts (automated)
- Performance Test
Results
Quality Assurance
(Owner)
Operations
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Construction Phase
Page 41 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
from competition for shared resource like database locks or network
bandwidth. Stress testing identifies the peak load the system can handle.
Volume Testing: subjects the software to large amounts of data to
determine if limits are reached that cause the software to fail. Volume
testing also identifies the continuous maximum load or volume the system
can handle for a given period of time. For example, if the software were
processing a set of database records to generate a report, a Volume Test
would use a large test database and check that the software behaved
normally and produced the correct report.
Database
Performance
Review
During the process of testing, DBAs should enable monitors and perform
traces to look for any SQL statements which are poor performing and could
cause performance issues for the application or compromise the database.
The DBA’s generate and review reports of the most resource intensive
statements and notify developers of potential problems and possible tuning
options. The analyst, lead QA tester, or lead developers should notify the
DBA team when heavy testing will commence so that the monitoring can be
put in place.
Execution of test
plans
Performance
Problem
Notifications
Development (Owner)
Quality Assurance
Analyst
Perform
Application
Security Scans
Security testing is performed utilizing the AppScan software tool to check for
system vulnerabilities exposed by web applications. The Development team
will analyze the application vulnerabilities and Operations will analyze the
infrastructure vulnerabilities. All High and Medium vulnerabilities should be
resolved prior to implementation into production. The security group will
review the impact and risk of any medium or high vulnerabilities that cannot
be resolved prior to implementation in production.
For any scans conducted on vended or partner systems, there are
considerations that must be taken as to the impact and damage that could
be the result of the scan.
- Application
Technical Overview
- Application
Vulnerability Reports
Quality Assurance
(Owner)
Security
Development
Operations
Security Scanning Procedure
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides> Vulnerability Scans >
WebAppSecurityScanningPro
cess.docx
AppScan Testers Guide
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides> Vulnerability Scans >
AppScan_TestersGuide.docx
Customer Requirements and
Considerations
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides> Vulnerability Scans >
AppScanTestingConsideration
sAndRequirements.docx
Develop Customer
Test Plan
The customer will create a detailed test plan that will be used during testing
of the application. An essential element of the customer test plan is the
establishment of software acceptance criteria.
- Application Design
Document
- Customer Test Plan
Customer
Project Manager (Owner)
Analyst
Customer Test Plan
AITS Intranet:
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Construction Phase
Page 42 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Documentation Library >
Methodology > SDLC >
Templates and Forms >
Customer_Test_Plan_Templa
te.xls
Manage Defects
As defects are identified through testing, the defects are entered into a
tracking system where the steps to produce the defect are documented.
Each defect is uniquely identified and assigned a priority and a status. As
Developers correct a defect, the defect is retested and the status is
appropriately updated based upon the results.
Quality Assurance utilizes a formal defect management tools that is shared
with analysts and developers. For projects which do not go through Quality
Assurance, the defects are manually tracked.
- Application Design
Document
- Defect Report
Analyst (Owner)
Quality Assurance
Project Manager
QA Test Management Tool
Users Guide
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides >
QA_TestManagementTool_U
sersGuide.docx
QA Defect and Issue
Workflow
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides >
QAToolIssueWorkFlow.vsd
Execute Alpha
Test
After the analysts have done an initial round of testing, this is the customer’s
first opportunity to test the application and identify defects.
- Customer Test Plan
Customer (Owner)
Analyst
Develop Training
Materials
Training materials will be created for use in customer training sessions.
- Training Plan
Document
- Application Design
Document
- Training Materials
Customer (Owner)
Project Manager
Develop User
Guides / Help
Materials
User Guides and help materials will be created to aid in use of the product.
Common features and actions should be documented to allow the customer
to look at a reference material rather than reading the complete
documentation.
- Application Design
Document
- User Guides
Customer (Owner)
Revise Application
Deployment Plan
The Application Deployment Plan should be reviewed and updated as
needed. The work on the “Deployment Forms Checklist” section should
begin at this stage and t the developer begin building the migration
documents. Work on the Rollout plan should also begin in this phase.
- Application
Deployment Plan
- Application
Deployment Plan
Deployment (Owner)
Development
Analyst
Application Deployment Plan
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
pplicationDeploymentTempla
te.docx
Communication
The various forums and communication mechanisms identified in the
communication plan continue to be performed as the project progresses. As
the project moves into new phases, additional types of communication
activities may become necessary and activities previously done may need to
-Communication Plan
-Various
communication
outputs per the
Communication Plan
Project Manager (Owner)
Project Team
Portfolio Management
Office
Templates for various types
of meetings as well as guides
to using Clarity and
SharePoint can be found in
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Construction Phase
Page 43 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
evolve or be eliminated as participants change or the project focus shifts.
the Sharepoint Document
Library.
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle
Monitor and
Control
Throughout the course of a project there are a number recurring activities
related to keeping the project on track and making adjustments to the plan
when needed. At a minimum, these activities include:
Managing risks and issues in Clarity
Manage change requests (see note below)
Following up on tasks and enforcing schedule
Managing action items in SharePoint
Updating project plan in Clarity:
Tasks
Resources
Schedule
Complex or large projects may require additional monitoring effort. The
PMO can help in developing reports and tools to keep your project on
budget and on schedule.
- Project Charter
- Communication
Plan
-Project Plan
-Updated project
plan
-Risks, issues, and
change requests in
Clarity
-Action items in
SharePoint
Project Manager (Owner)
AFM
Portfolio Management
Office
The PMO Monthly Checklist
is a good guide for
monitoring and controlling a
project.
PMO Monthly Checklist
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle >
Guides > UpdatingAProject-
PMOChecklist.pdf
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Testing Phase
Page 44 of 67
Testing Phase
Operations
Deployment
Security
Quality
Assurance
Development
Analyst
Project Manager
Customer
Perform Functional Testing
Perform System Testing
Manage Defects
Revise Application Design
Application
Design
Develop Application
Code Application
Perform Unit TestsCode Bug Fixes
Deploy
Code Change Request
Revise Application Deployment Plan
Deployment
Plan
Performance
Test Report
Execute Performance Test
Execute Functional Test Cases
Perform Application Security Scans
Revised
Test Cases
Defect
Report
Application
Vulnerability
Reports
Review Application Vulnerability Reports
Monitor Performance Tests
Revise Application Technical Overview
Application
Technical
Overview
Customer
Sign-Off
Develop User Guides / Help Materials
User
Guides
Perform Functional Testing
Perform System Testing
4.4 Testing
Phase
Inputs
Performance
Test Plan
Project
Plan
Training
Materials
User
Guides
Application
Design
Application
Deployment
Plan
Defect
Report
CR Log
QA Master
Test Plan
Application
Technical
Overview
Customer
Test Plan
Application
Vulnerability
Reports
Build Functional Test Cases
Test
Cases
Develop Training Materials
Training
Materials
Test Cases
Business
Rules
System Test
Plan
Build Automated Test Scripts
Test
Scripts
AITS
SDLC
Software Development
Life Cycle
Perform IITAA Accessibility Testing
IITAA
Checklist
Communic-
ation Plan
Monitor, Control, and Communicate
Manage Change Requests
CR Log
Database Performance Review
Execute Mock Conversions
Compile Service Desk Documents
Service
Desk Docs
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Testing Phase
Page 45 of 67
Phase 4.4 – Testing
The purpose of the Testing phase is to have Quality Assurance, the analysts, and the customers engage in full end-to-end testing of the
application to make sure that it functions as specified. Testing was initially started in the Construction phase and focused on ensuring that
the major functionality was generally working and that there were no significant deficiencies in the specifications, performance, or security
of the application. The testing that occurs in the Testing phase is a more rigorous with emphasis on verifying that the application meets
the customers’ needs for production. The types of testing that occur include functional testing of the components performed first by
Quality Assurance and the analysts and then the customer; system testing of the components as they work together and interact with
other systems; performance testing to ensure that the application is able to properly function during periods of high demand or load;
security testing to eliminate any vulnerabilities within the application that may compromise the system or expose data to theft or loss; and
accessibility testing to verify that the application meets the Illinois Information Technology Accessibility Act (IITAA) standards. These
testing efforts are iterative and overlapping in nature and do not occur sequentially. As issues are discovered, they are categorized as
either defects or change requests to the system. Defects indicate that the application is not functioning as specified whereas change
requests indicate that the system needs to be enhanced to either provide additional functionality or modification to the functionality as
defined. The amount of development work during this phase should be minimized as much as possible in order to stabilize the product.
The Customers also utilize this time to finish building user guides and training materials.
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Build QA
Functional Test
Cases
The effort started during the Construction Phase to build functional test
cases continues into the Testing Phase. The functional test cases feed into
the functional testing performed by the Quality Assurance team.
- Application Design
Document
- Business Rules
- Test Cases
Quality Assurance
(Owner)
Analyst
QA Mater Test Plan Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
QAMasterTestPlanTemplate.
docx
QA Test Management Tool
Testers Guide
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides >
QA_TestManagementTool_T
estersGuide.docx
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Testing Phase
Page 46 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Build Automated
Test Scripts
The QA Specialist will be responsible for developing automated test scripts
to be used for regression tests in the future. A regression test is a test is
done to ensure that enhancements made or bug-fixes do not introduce new
errors into an application.
- Application Design
Document
- Business Rules
- Application
Technical Overview
- Automated Test
Scripts
Quality Assurance
(Owner)
Execute QA
Functional Test
Cases
This effort is started during the Construction Phase. The Testing Team will
execute the tests that were developed to test the business rules and
functionality of the application as defined by the specifications. The test
results will be documented and defects will be filed. The QA functional
testing should be complete or at least well underway prior to the customer
beginning their functional testing. The Testing Team will continue to
execute functional tests as changes and fixes are put into the application.
The customer should not be testing code that has not gone through QA.
- Test Cases
- Test Scripts
- Test Cases
Quality Assurance
(Owner)
Analyst
Development
Customer
QA Test Management Tool
Testers Guide
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides >
QA_TestManagementTool_T
estersGuide.docx
Perform IITAA
Accessibility
Testing
Applications developed by the University must adhere to the guidelines
established by the Illinois Information Technology Accessibility Act (IITAA).
Quality Assurance and Development review the application screens for
adherence to the guidelines and issues found are submitted as defects. This
review includes manual review of the HTML as well as navigating the
application using a screen reader tool.
- Application Design
Document
- IITAA Test Case
Checklist
Quality Assurance
(Owner)
Developer
Accessibility Development
Process Overview
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides >
ApplicationAccessibilityDevel
opmentProcess_Overview.do
cx
QA IITAA Validation Process
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides >
QA_IITAA_TestingValidation.
doc
QA IITAA Application
Checklist
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
QA_IITAA_AccessibilityCheckl
ist.xls
Execute Mock
Conversions
For systems requiring data to be converted from other systems into the new
system, mock conversions are executed to populate the new system with
converted data. This data should be used for testing of functionality as well
as for conversion verification. A series of mock conversions are executed in
- Conversion Strategy
- Application Design
Document
- Conversion results
Analyst (Owner)
Customer
Development
Conversion Process Guide
AITS Intranet:
Documentation Library >
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Testing Phase
Page 47 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
order to improve the data quality of the conversion and to practice the
process of executing the various scripts, programs, manual data entry, and
conversion reconciliation.
Methodology > Project
Management Lifecycle >
Guides >
ConversionProcessGuide.doc
x
Perform
Customer
Functional
Testing
As QA wraps up execution of the QA Functional Test Cases, the analyst
completes initial functional testing of the application, the customer then
begins their functional testing. As in the previous phase, the testing is
performed to measure compliance to specifications and business rules as
well as adherence to specifications. As issues are identified, they are
communicated back to the developer and tracked in the Defect and Change
Request Management systems.
- Business Rules
- Application Design
Document
-Customer Test Plan
Customer (Owner)
Analyst
Development
QA Tool Users Guide
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides >
QA_TestManagementTool_U
sersGuide.docx
Execute
Performance
Test
As started during the Construction Phase, the Performance Testing of the
application continues. As the testing continues, issues found are addressed
by Development and Operations. The Customer reviews test results and at
the end of the testing cycle acknowledges that system performance is
acceptable.
- Performance Test
Plan
- Performance Test
Scripts (automated)
- Test Results and
Approval
Quality Assurance
(Owner)
Analyst
Customer
Operations
Monitor
Performance
Tests
The Operations team monitors the system during performance tests
executed by the Quality Assurance team. Key factors such as memory and
CPU utilization, process counts, and system general health are monitored as
the tests occur.
- Performance Test
Plan
- Test Results and
Customer Review
Quality Assurance
(Owner)
Operations
Development
Database
Performance
Review
During the process of testing, DBAs should enable monitors and perform
traces to look for any SQL statements which are poor performing and could
cause performance issues for the application or compromise the database.
The DBA’s generate and review reports of the most resource intensive
statements and notify developers of potential problems and possible tuning
options. The analyst, lead QA tester, or lead developers should notify the
DBA team when heavy testing will commence so that the monitoring can be
put in place.
Execution of test
plans
Performance
Problem
Notifications
Development (Owner)
Quality Assurance
Analyst
Perform
Application
Security Scans
The security testing that started during the Construction Phase continues
and is completed during the Testing Phase. All high and medium
vulnerabilities will be corrected prior to production deployment. Any high or
medium vulnerabilities that are not able to be resolved prior to
implementation must be evaluated and approved as determined by Security,
Project Management, and Development.
- Application
Technical Overview
- Security Scan
Reports
Quality Assurance
(Owner)
Security
Development
Operations
Security Scanning Procedure
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides> Vulnerability Scans >
WebAppSecurityScanningPro
cess.docx
AppScan Testers Guide
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides> Vulnerability Scans >
AppScan_TestersGuide.docx
Customer Requirements and
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Testing Phase
Page 48 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Considerations
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides> Vulnerability Scans >
AppScanTestingConsideration
sAndRequirements.docx
Review
Application
Vulnerability
Reports
The Security team reviews the results of the Security Scans that are done.
The Security team provides input and assistance in prioritizing vulnerability
fixes as well as collaboration in identifying false positives.
- Application
Technical Overview
- Security Scan
Reports
Quality Assurance
(Owner)
Devlopment
Security
Manage Defects
The Defect Management Process started during the Construction phase is
continued during the Testing phase. Defects will continue to be classified
and fixed as prescribed. The defects remaining at the conclusion of the
Testing phase will be reviewed and used by the Customers as part of the
criteria in determining if the system is ready to proceed. In general, no
“critical” or “high” defects should be allowed to exist in the system as it is
deployed into production.
- Application Design
Document
- Defect Report
Analyst (Owner)
Quality Assurance
Project Manager
Development
Customer
QA Test Management Tool
Users Guide
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides >
QA_TestManagementTool_U
sersGuide.docx
QA Defect and Issue
Workflow
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides >
QAToolIssueWorkFlow.vsd
Revise
Application
Design
Document
The Application Design Document that was started during the Analysis phase
will be updated throughout the development process. As changes or
clarifications are made, the document is updated and republished. Any
change that impacts the scope of the project must be sent through the
Change Request Management process. This document will be used as the
standard for determining defects within the Quality Assurance activities.
- Application Design
Document
- Revised Application
Design Document
Analyst (Owner)
Development
Application Design Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
ApplicationDesignTemplate.d
ocx
Develop
Application
The Development and Unit Test cycle continues throughout the Testing
phase as defect corrections and change requests are placed into the code
base.
- Application Design
Document
- Application
Technical Overview
- Style Guides
- Service Guides
- Program Code
- AppWorx Chains
- Code Review
Documents
- Unit Test Results
Development (Owner)
Analyst
Customer
Application Development
standards
AITS Intranet:
Departments > ADSD -
Application Development and
Support > Shared Documents
> Development Standards
Documentation >
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Testing Phase
Page 49 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Perform System
Test
A Systems Test is both functional and technical in nature. This is “end to
end” testing verifying proper operation of the application in a simulated
environment. The goal is to ensure that the new or modified application has
not detracted or negatively impacted the overall system or service offered.
A formal customer acceptance test plan may be desired for projects of a
larger size and complexity. Typically AITS staff will gather with customers in a
room and conduct structured functional tests of the new software. The
duration of the testing may last anywhere from several hours to several
days. At culmination of the testing the intent is to receive a sign-off from the
customers that the software is ready for production.
- System Test Plan
- Test Results
Analyst (Owner)
Development
Customer
Guide for System Test Plans
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides >
SystemTestingOutline.docx
Revise
Application
Technical
Overview
The Application Technical Overview will be updated as a result of changes
that occurred during the Testing Phase.
- Application
Technical Overview
- Revised Application
Technical Overview
Document
Development (Owner)
Analyst
Application Technical
Overview Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
ApplicationTechnicalOvervie
wTemplate.docx
Develop User
Guides / Help
Materials
The User guides and help materials that were started during the
Construction Phase will continue to be developed by the Customers.
- Business Rules
- Application Design
Document
- User Guides
Customer (Owner)
Develop Training
Materials
Training material creation for use in customer training sessions continues
from the construction phase.
- Business Rules
- Training Plan
Document
- Application Design
Document
- Training Materials
Customer (Owner)
Project Manager
Obtain Customer
Sign-off
The customer reviews the results from the various testing efforts to confirm
that the system functions to specification and performs adequately. Sign-
off at this point allows the application to move into the Training Phase.
- Test Results
- Sign-off
Project Manager
(Owner)
Customer
Revise
Application
Deployment Plan
The Application Deployment Plan should be reviewed and updated as
needed. The Rollout Plan that was initially built during the Construction
Phase is augmented as development and testing continue throughout the
Testing Phase.
- Application
Deployment Plan
- Application
Deployment Plan
Deployment (Owner)
Development
Analyst
Application Deployment Plan
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
pplicationDeploymentTempla
te.docx
Compile Service
Desk Documents
In preparation for eventual deployment, the artifacts needed by the Service
Desk for support of the application will start to be compiled. The items
include chain notes, service ticket queues, FAQ’s and knowledge documents,
as well as a general overview of the application and any other special
support documents.
- Application
Deployment Plan
- Application Design
Document
- Chain notes
- Knowledge Docs
- FAQ’s
Project Manager
(Owner)
Analyst
Deployment
Application Deployment Plan
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
pplicationDeploymentTempla
te.docx
Manage Change
Change requests can be generated during code design, construction and
- Application Design
- Change Request Log
Project Manager
Change Request Log
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Testing Phase
Page 50 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Requests
various testing processes. Change requests are defined as features or
functions that the customer would like to have included in the system but
were not included in the specifications in the Application Design Document.
Change requests are managed by a process that includes prioritizing the
request, estimating the amount of work required to include the request in
the system, and setting expectations regarding when the change request
work will be scheduled. Change requests require the re-initiation of the unit
testing, deployment, and detailed testing cycle.
Document
(Owner)
Analyst
Customer
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SoftwareChangeRequestLog.x
lsx
Change Request Form
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SoftwareChangeRequestTem
plate.xlsx
Communication
The various forums and communication mechanisms identified in the
communication plan continue to be performed as the project progresses. As
the project moves into new phases, additional types of communication
activities may become necessary and activities previously done may need to
evolve or be eliminated as participants change or the project focus shifts.
-Communication Plan
-Various
communication
outputs per the
Communication Plan
Project Manager
(Owner)
Project Team
Portfolio Management
Office
Templates for various types
of meetings as well as guides
to using Clarity and
SharePoint can be found in
the Sharepoint Document
Library.
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle
Monitor and
Control
Throughout the course of a project there are a number recurring activities
related to keeping the project on track and making adjustments to the plan
when needed. At a minimum, these activities include:
Managing risks and issues in Clarity
Manage change requests (see note below)
Following up on tasks and enforcing schedule
Managing action items in SharePoint
Updating project plan in Clarity:
Tasks
Resources
Schedule
Complex or large projects may require additional monitoring effort. The
PMO can help in developing reports and tools to keep your project on
budget and on schedule.
- Project Charter
- Communication
Plan
-Project Plan
-Updated project
plan
-Risks, issues, and
change requests in
Clarity
-Action items in
SharePoint
Project Manager
(Owner)
AFM
Portfolio Management
Office
The PMO Monthly Checklist
is a good guide for
monitoring and controlling a
project.
PMO Monthly Checklist
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle >
Guides > UpdatingAProject-
PMOChecklist.pdf
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Training Phase
Page 51 of 67
Training Phase
4.5 Training
Deployment
Security
Operations
Quality
Assurance
Development
Analyst
Project Manager
Customer
Phase
Inputs
Perform Customer Training
Build Training Environment
Stage / Promote Software Artifacts
Establish Security
Training
Materials
User
Guides
Training
Plan
Application
Deployment
Plan
Business
Rules
Application
Deployment
Plan
Application
Deployment
Plan
Application
Deployment
Plan
Training
Feedback /
Surveys
AITS
SDLC
Software Development
Life Cycle
Access
Requirements
/ Controls
Access
Requirements
/ Controls
Communicate
Monitor and Control
Communic
-ation Plan
Project
Plan
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Training Phase
Page 52 of 67
Phase 4.5 – Training
The purpose of the Training Phase is for the customers to provide formal training to the end-users of the system. The training materials
have been built by the customers in earlier phases. The customers utilize the training materials, user guides, help documents, and any
other needed materials to train end-users on the functionality of the system as well as needed business processes associated with the
system. In preparation of the training, the Development, Security, and Deployment groups may need to build a separate training
environment which may include establishing separate databases with special data and training ids and roles. The Training Phase is not
always needed in every project and some customers may choose to not perform training or do so on an informal basis.
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
Build Training
Environment
In order to prepare for the training, a new environment may be needed. The
environment may consist of new databases, application servers or
deployments, AppWorx chains, new user ids and roles, and manufactured
training data. Furthermore, the environment may require scheduled
refreshes to restore training data for use in subsequent classes.
- Deployment Plan
Analyst (Owner)
Deployment
Development
Stage / Promote
Software
Artifacts
To support the training environment, the software components built for the
application are staged and promoted into the training environment. The
process is similar to what is followed for migration the application from
development to test and eventually to production. The deployment plan
previously built is utilized for this effort.
- Deployment Plan
Development (Owner)
Deployment
Manage Training
Environments
During training there are various coordination activities that may need to be
done to keep the training environment current or prepared for each training
iteration. Many times these activities require coordinating tasks performed
by the technical support team with the training classes being held by the
customer. These activities may include training database refreshes, loading
new users, coordinating of the deployment of the application or
infrastructure components to get changes or fixes into the training
environment, and/or serving as a point of contact for environment issues.
- Training Plan
Project Manager
(Owner)
Establish
Security
The Security team sets up any ids, roles, privileges, and access needed for
the trainers and participants. The security setup may mirror how it will be in
production or it may include granting of additional privileges to allow for
users to experience the full functionality of the system. Reusable generic ids
may also be used for training purposes.
- Deployment Plan
Analyst (Owner)
Security
Perform
Customer
Training
The Customer may hold training sessions with end-users of the systems to
teach the new functionality and business processes to them. The complexity
of the training may range from informal presentations to departmental staff
to formal on-campus training sessions with dedicated training staff. The
training materials and user guides previously constructed are used by the
Customers to perform the training.
- Business Rules
Document
- Training Plan
- Training Materials
- Training Feedback
and Surveys
Customer (Owner)
Analyst
Communication
The various forums and communication mechanisms identified in the
-Communication Plan
-Various
Project Manager
Templates for various types
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Training Phase
Page 53 of 67
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
communication plan continue to be performed as the project progresses. As
the project moves into new phases, additional types of communication
activities may become necessary and activities previously done may need to
evolve or be eliminated as participants change or the project focus shifts.
communication
outputs per the
Communication Plan
(Owner)
Project Team
Portfolio Management
Office
of meetings as well as guides
to using Clarity and
SharePoint can be found in
the Sharepoint Document
Library.
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle
Monitor and
Control
Throughout the course of a project there are a number recurring activities
related to keeping the project on track and making adjustments to the plan
when needed. At a minimum, these activities include:
Managing risks and issues in Clarity
Manage change requests (see note below)
Following up on tasks and enforcing schedule
Managing action items in SharePoint
Updating project plan in Clarity:
Tasks
Resources
Schedule
Complex or large projects may require additional monitoring effort. The
PMO can help in developing reports and tools to keep your project on
budget and on schedule.
- Project Charter
- Communication
Plan
-Project Plan
-Updated project
plan
-Risks, issues, and
change requests in
Clarity
-Action items in
SharePoint
Project Manager
(Owner)
AFM
Portfolio Management
Office
The PMO Monthly Checklist
is a good guide for
monitoring and controlling a
project.
PMO Monthly Checklist
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle >
Guides > UpdatingAProject-
PMOChecklist.pdf
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Deployment Phase
Page 54 of 67
Deployment Phase
Conduct Production Readiness Testing
Execute Dress Rehearsal
Execute Go Live
Roll Out
Build Roll Out Plan Prepare Environment
Migrate Artifacts
Conduct Production
Readiness Testing
Change
Control
Approval
Submit Change Control
Stage / Promote Software Artifacts
Revise Application Technical Overview
Application
Technical
Overview
Complete Application Deployment Checklist
Deployment
Checklist
Conduct Production Readiness Testing
Go / No Go
Decision
Execute Backout
1
No Go
1
Go
Application
Live
Establish Security
Stage / Promote Software Artifacts
4.6 Deployment
Deployment
Security
Operations
Quality
Assurance
Development
Analyst
Project
Manager
Customer
Phase
Inputs
Project Plan
Application
Deployment
Plan
Application
Technical
Overview
Access
Requirements
/ Controls
Communicate Event to Enterprise
AITS
SDLC
Software Development
Life Cycle
Communicate
Monitor and Control
Communic-
ation Plan
Service Desk Turnover
Service Desk
Docs
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Deployment Phase
Page 55 of 67
Phase 4.6 – Deployment
The purpose of the Deployment Phase is to practice the migration of the application and all of its associated components to a pre-
production environment and once that has been successful to follow the same process to migrate the application to production. Through
repeated practice of the migration, holes in the deployment plan as well as environmental differences are identified that could potentially
jeopardize the production roll-out. The roll-out into production should follow the same process as the dress rehearsals and should be
performed by the same individuals. The customers and analysts perform Production Readiness Testing (PRT) in the dress rehearsals and
production roll-out. PRT touches various pieces of functionality and configuration to verify that the migration of the components was
successful; it is not meant to be a regression test of the application. At the conclusion of the roll-out, the customer determines if the roll-
out is acceptable in production. If it is decided that the system is a No-Go, then back out procedures may be executed to remove the
application from production and restore the systems to their prior state.
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
Revise
Application
Technical
Overview
The Application Technical Overview will be updated and a final copy will be
produced.
- Application
Technical Overview
- Revised Application
Technical Overview
Document
Development (Owner)
Analyst
Application Technical
Overview Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
ApplicationTechnicalOverview
Template.docx
Complete
Application
Deployment
Checklist
The Developer completes the deployment checklist in preparation of
deploying the application into production.
- Application
Technical Overview
- Application
Deployment Plan
- Application
Checklist
Development (Owner)
Application Checklist
Procedure
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
Migration Forms>
CC_Application_Checklist.rtf
Report Checklist Procedure
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
Migration Forms>
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Deployment Phase
Page 56 of 67
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
CC_Report_Checklist.rtf
Stage / Promote
Software
Artifacts
For both dress rehearsals and migration to production, the software
components built for the application are staged and promoted into the dress
rehearsal and production environments. The process for the migrations
during the dress rehearsals and production migration should be as similar to
each other as possible. The deployment plan previously built is utilized for
this effort.
- Application
Deployment Plan
Development (Owner)
Deployment
Application Deployment
Process
AITS Intranet:
Documentation Library >
Methodology > SDLC > Guides>
ApplicationsDeploymentProces
s.docx
Execute Dress
Rehearsal
In advance of deploying the project to Production, rollout dress rehearsals
may be performed to validate the deployment plan and practice the
deployment processes. As part of the dress rehearsals, the following
activities occur:
- Build Rollout Plan
The primary focus of this step is to create a Rollout Plan. The Rollout Plan
documents all the various activities the participating groups need to
undertake during the time of deployment of the new or modified system.
The Deployment Plan that was previously built is used as the starting point
for the Rollout plan.
The information in the standard Rollout Plan includes the following:
Step Number
Task Description
Dependencies
Related Document
Comments
Hand-off / Notification
Responsibility
Duration in Minutes
Start Date and Time
Finish Date and Time
- Prepare Environment
The dress rehearsal environment is prepared or refreshed for the next dress
rehearsal. This may include refreshing one or more databases, restoring
Appworx chains from production, running jobs (such as paycalc) to place the
database in a similar state as what will be experienced during the rollout in
production. The goal is to prepare the environment to be as close to what
production will be like during the go-live rollout.
- Perform Roll Out
The roll out is the migration of and artifacts, conversions, and execution of
- Application
Deployment Plan
- Rollout Plan
- PRT Test Results
Deployment (Owner)
Project Manager
Customer
Analyst
Development
Quality Assurance
Security
Operations
Rollout Planning Process
AITS Intranet:
Documentation Library >
Methodology > SDLC > Guides>
WeeklyRolloutPlanningProcess
.docx
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Deployment Phase
Page 57 of 67
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
manual steps such as data entry to completely migrate the application into
the dress rehearsal environment. The steps for the deployment are
documented in the deployment plan.
- Conduct Production Readiness Testing
The Production Readiness Testing is executed by the customers or customer
proxy to validate the implementation in production. This PRT is done exactly
the same way in dress rehearsals as is done in production.
Submit Change
Control
Submitting a Change Control Request is the first step in the larger overall
process referred to as Change Management.
Change Control is the process that ensures that all changes are controlled.
This includes the submission, recording, analysis, decision making and
approval of the change.
Most ITPC and internal projects would be viewed as “Major changes”.
Major changes should always be wrapped in a comprehensive
documentation package that includes: appropriate user approvals; user
training and signoffs when appropriate; an attestation that testing has been
conducted, reviewed with the user, and accepted by the user; back-out
plans; a detailed roll-out plan that includes success criteria, decision point
documentation, escalation and notification procedures; etc. Major changes
shall be approved by a management person who is no more than one level
below a member of the Senior Management team, and the approval of a
major change should be accompanied by a formal review of the
documentation package.
- Rollout Plan
- Change Control
Project Manager
(Owner)
General Change Control
Procedures
AITS Intranet:
Documentation Library >
Methodology > SDLC > Guides>
AITSChangeControlManageme
ntGuide.docx
Application Procedures:
Process
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides>
CC_Application_Process.doc
x
Checklist
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
Migration Forms >
CC_Application_Checklist.rtf
Report Procedures:
Process
AITS Intranet:
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Deployment Phase
Page 58 of 67
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
Documentation Library >
Methodology > SDLC >
Guides>
CC_Report_Process.docx
Checklist
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
Migration Forms >
CC_Report_Checklist.rtf
Service Desk
Turnover
Prior to go live, the project team will meet with the Service Desk to review
the application and associated support items such as chain notes, ticketing
queues, FAQ’s, anticipated problems/questions, escalation procedures,
system documentation. Members of the project team may help in the
support transition by working at the Service Desk for a period of time after
the roll-out.
- Chain notes
- Knowledge Docs
- FAQ’s
Project Manager
(Owner)
Operations
Analyst
Deployment
Application Deployment Plan
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
pplicationDeploymentTemplat
e.docx
Communicate
Event to
Enterprise
Effective communication of a major event such as the deployment of a new
system or upgrade is not limited to just one phase step, but rather requires
activity at different times throughout several of the phases of the PMLC.
The communication process includes:
Add requested events to the deployment timeline
Work with the stakeholders through ESC/TAM to obtain approval prior
to approving the timeline
Review and approve the dates during the scheduling committee (based
on stakeholder feedback, business events, holidays, etc)
Publish the appropriate event on the AITS status page, which sends an
email to all list serve subscribers
Send an event notice based on the information in the Event Data
sheet.
Post the event progress on the go-live web site
Send final event notice that system is live
- Change Control
- Communications
Plan
- Event Notice
Project Manager
(Owner)
Migrate
Software
This step involves the deployment of new project artifacts to production.
Typical activities that occur during deployment might include:
- Rollout Plan
- Deployment
- Production System
Deployment (Owner)
Operations
Application Deployment Plan
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Deployment Phase
Page 59 of 67
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
Artifacts into
Production
Environment
Pre-Deployment Activities
Prepare CVS for Upgrade
Prepare LDAP / LDIF Files
Conduct System Shutdown
Perform Software Upgrade
Apply Patches and Modifications
Migrate Software Tree
Perform Miscellaneous Database Activities
Implement Configuration Changes
Implement Security Changes
Migrate AppWorx and Parameter Editor Items
Migrate Reports
Migrate AITS Developed Applications
Bring Up System for Production Readiness Test
Checklists
Development
Analyst
Customer
Project Manager
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
ApplicationDeploymentTempla
te.docx
Establish
Security
The Security team sets up any ids, roles, privileges, and access needed for
users and support staff in production. This may include bulk loads of users
and assignment of credentials as well as controlled on-going management of
credentials as users are added to the system. Typically users are loaded en
masse at go live, but user security will need to go through more formal
request and provisioning procedures as the application stabilizes in
production.
- Rollout Plan
- Security Access /
Controls
Security (Owner)
Access Requirements
Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SecurityAccessRequirementsTe
mplate.doc
Baseline Access Control
Review Template
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
SecurityBaselineAccessControl
ReviewForApplications.docx
Conduct
Production
Readiness
Testing
After the deployment of the new project artifacts to the dress rehearsal or
production environment, a Production Readiness Test (PRT) is performed to
ensure that all of the components migrated successfully and is operating and
that the deployment has not caused any unintended effects on system
operability. Normally, there are predefined scripts or subjects that are
tested during a PRT that touch as many of the areas of the system as
possible. PRT is performed by the customer or a proxy for the customer who
is able to make the decision to accept the application as it is in production.
PRT typically is geared to be executed in a short time frame and is not meant
to be a full regression test of the application.
- Rollout Plan
- PRT Test Plan
- PRT Results and
Sign-Off
Analyst (Owner)
Customer
Deployment
Make Go / No-
Go Decision
After production PRT is complete, the customer reviews the results of the
PRT and any known issues and makes a determination of whether the
- PRT Results and
Sign-Off
Project Manager
(Owner)
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Deployment Phase
Page 60 of 67
Activities
Description
Inputs
Outputs
Owner /
Participant
Links / Notes
system is ready to be opened up to all users. If there are issues that are
critical and prevent the system from going live, then the back out
procedures are executed.
Customer
Deployment
Execute Back Out
If the implementation of the application into production is unsuccessful and
a No-Go decision is made, then the Back Out Procedures documented within
the deployment plan are executed. This may include actions such as simply
shutting the application down or restricting access to it in production or it
may require a full back out of the source code, chains, configuration
settings, other deployed artifacts as well as restoring data. At the
completion of the backout, a Production Readiness Test is executed to
confirm that the production environment is back to the pre-rollout state.
- Deployment Plan
-Restored Production
System
Deployment (Owner)
Operations
Development
Analyst
Customer
Project Manager
Communication
The various forums and communication mechanisms identified in the
communication plan continue to be performed as the project progresses. As
the project moves into new phases, additional types of communication
activities may become necessary and activities previously done may need to
evolve or be eliminated as participants change or the project focus shifts.
-Communication Plan
-Various
communication
outputs per the
Communication Plan
Project Manager
(Owner)
Project Team
Portfolio Management
Office
Templates for various types of
meetings as well as guides to
using Clarity and SharePoint
can be found in the Sharepoint
Document Library.
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle
Monitor and
Control
Throughout the course of a project there are a number recurring activities
related to keeping the project on track and making adjustments to the plan
when needed. At a minimum, these activities include:
Managing risks and issues in Clarity
Manage change requests (see note below)
Following up on tasks and enforcing schedule
Managing action items in SharePoint
Updating project plan in Clarity:
Tasks
Resources
Schedule
Complex or large projects may require additional monitoring effort. The
PMO can help in developing reports and tools to keep your project on
budget and on schedule.
- Project Charter
- Communication
Plan
-Project Plan
-Updated project
plan
-Risks, issues, and
change requests in
Clarity
-Action items in
SharePoint
Project Manager
(Owner)
AFM
Portfolio Management
Office
The PMO Monthly Checklist is
a good guide for monitoring
and controlling a project.
PMO Monthly Checklist
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle >
Guides > UpdatingAProject-
PMOChecklist.pdf
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Close Phase
Page 61 of 67
Close Phase
4.7 Close
Deployment
Security
Operations
Quality
Assurance
Development
Analyst
Project
Manager
Customer
Phase
Inputs
Conduct Post Project Review Meeting
Provide Production Support
User Guides
Application
Design
Application
Technical
Overview
ITPC
Enhancement
Requests
Work
Requests
Organize and Store Final Project Documentation
Provide Production Support
Provide Short Term Post Project Suport
Production
Support
Requests
Conduct Stakeholder Satisfaction Survey
Gather Lessons Learned Close Project in Clarity
Project Plan
AITS
SDLC
Software Development
Life Cycle
Post Deployment Review
Security Review and Cleanup
Development Environment Cleanup
Decommission Application
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Close Phase
Page 62 of 67
Phase 5.1 – Close
The purpose of the Close Phase is to wrap up the project and move into production support mode. A post project review is held where
both activities that went well and areas of improvement are identified. The final documents for the project are stored and archived for
future reference. The Application Design, Technical Overview, and Service Guides remain living documents and are revised as changes
are made in the application. Once in production support mode, the application undergoes changes due to defect corrections or
enhancements that are requested in the system. Whenever these changes are made, various components of the SDLC may be used to
facilitate the implementation. As such, the SDLC is a continuous process and is not only followed for new application development.
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Post Deployment
Review
After completion of a formal rollout activity, the Deployment team conducts
a Post Deployment or Post Go-Live Review. Most rollouts occur over the
weekend and there is a standing Post Go-Live Review meeting set for
Tuesdays at 3:10 PM. All rollout participants are required to attend this
meeting and AITS Managers are encouraged to attend. The Deployment
Specialist who was involved in the planning and execution of the rollout will
prepare a Post Go-Live review document and share that with all the
participants. Issues and Concerns will be documented for future
Deployments.
Rollout Plan
Application
Deployment Plan
Post Go-Live Review
Document
Deployment (Owner)
Post Go-Live Review
Document
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
PostGoliveRolloutSummary
Template.docx
Development
Environment
Cleanup
After the project is complete and has been deployed to production, the
Deployment team will follow up with the appropriate staff to ensure any
infrastructure components are removed as defined in Post Deployment
section of the Application Deployment Plan.
Application
Deployment Plan
Deployment (Owner)
Application Deployment
Plan
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Templates and Forms >
ApplicationDeploymentTem
plate.docx
Environment
Review and
Cleanup
After the application is migrated to production and before the project is
closed, access granted to developers, testers and administrative IDs in QA,
DEV and TEST environments and distribution list/security groups needed
only for the project must be reviewed. The review should determine either
the
(1) access is needed for on-going support or
(2) access is not needed for on-going support and must be
removed.
Application
Deployment Plan
Security (Owner)
Security Post Project
Cleanup and Review
Checklist
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Forms and Templates >
SecurityPostProjectEnviron
mentReviewandCleanup.do
cx
Gather Lessons
Learned
Prior to the Post Project Review/Project Closing meeting, the project
manager will send a list of selected project team members and stakeholders
to receive a combined Lessons Learned and Stakeholder Satisfaction survey.
The results will be gathered by the PMO, entered into Clarity, and passed
onto the project manager so that results can be reviewed with the team
during the meeting.
The review of lessons learned is part of the post project review meeting
Lessons Learned
questions
Lessons learned
Project Manager
(Owner)
Questions that can be used
in addition to the survey to
gather Lessons Learned and
to help organize lessons
learned discussions can be
found in the SharePoint
Document Library.
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Close Phase
Page 63 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle >
Guides>
LessonsLearnedQuestions.p
df
Project Survey Process for
PMO
Conduct
Stakeholder
Satisfaction
Survey
Conducting the Stakeholder Satisfaction Survey will allow us to gather
feedback from customers as well as project team members in order to
continually improve our project delivery and customer service. The survey
will be sent to AITS and customer project participants as well as the
customer project leadership to gather feedback about the effectiveness of
the project management and the project itself. This survey is sent as part of
the lessons learned survey above. The project manager will request for the
PMO to send out the survey well in advance of the post project review
meeting. The results will be gathered by the PMO and passed onto the
project manager so that results can be reviewed with the team during the
meeting.
- Project Charter
- Stakeholder
Satisfaction Surveys
Project Manager
(Owner)
Portfolio Management
Office (Owner)
Project Sponsor
Customers
Project Team
Project Survey Process for
PMO
Conduct Project
Closing Meeting
Conducting the project closing meeting will allow the project team and the
customer project participants and leadership to gather one last time to
ensure that there are no outstanding issues or work. This will also provide a
forum to review lessons learned throughout the project. The project
manager will send an agenda to participants a week or more in advance of
the scheduled meeting. The project manager will include in the agenda any
lessons learned and results from the stakeholder satisfaction survey.
Participants will add additional items to the Lessons Learned section of the
agenda and return it to the project manager at least 3 days prior to the
meeting. The project manager will then compile the lessons learned
feedback for review during the meeting. PMO will maintain a repository of
lessons learned and will periodically communicate these to the department.
The Post Project Review agenda should include: 1) Outstanding items
2)Project performance against budget, schedule, and scope 3)Lessons
learned 4) Other topics, such as information from the ADSD Post Project
Review
- Stakeholder
Satisfaction Surveys
-Lessons Learned
- Post Project Review
Agenda
- Project Plan
Project Closing
Meeting Notes
Project Manager
(Owner)
Customer
Analyst
Development
Quality Assurance
Security
Deployment
Operations
Portfolio Management
Office
A template for the Project
Closing Meeting can be
found in the SharePoint
Document Library.
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle >
Templates and Forms >
TEMPLATE
ProjectClosingAgendaAndN
otes.dotx
Organize and
Store Final
Project
Documentation
Organizing and storing the final project documentation will ensure that all
documentation is in one central location. The purpose of doing this is to
provide a single location for project documentation archives. The PMO will
work with the project manager to ensure this work is completed.
Development documentation will remain with the application in the
appropriate CVS locations within the project or the documentation trees.
PMLC and SDLC
artifacts
- Final copies of all
project
documentation
- Stored Project
Documentation
Project Manager
(Owner)
Portfolio Management
Office
A guide to archiving project
and application data is
available in the SharePoint
Document Library.
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle >
Guides>
ArchivingProjectAndApplica
tionData.pdf
In addition, the table that
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Close Phase
Page 64 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
identifies all PMLC and SDLC
deliverables with initial and
ultimate locations is
available in the Document
Library.
AITS Intranet:
Documentation Library >
Methodology > Index of
Deliverables and Storage
Locations.xlsx
Ongoing activity:
Communicate
(Implement
Communication
Plan)
Throughout the course of a project there are a number of recurring activities
related to communication. These include the activities identified in the
communication plan, which typically consist of:
Weekly project team status reports (Template provided which
offers a standardized agenda for status meetings throughout the
course of a project)
Maintaining SharePoint workspace with meeting agendas,
minutes, decisions, documentation, and status reports.
Project sponsor meetings for reviewing significant project plan
changes and progress
Informal communication: walk-abouts, hallway conversations,
and personal emails
There are enhanced processes and requirements regarding project
monitoring and control for large projects (those with greater than 5,000
hours of effort or $250,000) or any projects deemed of sufficient risk. These
should be identified in the project communication plan, but are outlined
here as well.
For these projects it is advisable that a Steering Committee or Oversight
Group be formed to monitor the project execution and collaborate on key
project decisions. Templates for Large Projects are included as follows:
Steering Committee Reporting Template – This is a reporting
package for periodic steering committee meetings and includes
standardized sections for:
o Project Timeline
o Significant Event Review
o Significant Risks / Issues
o Metric Tracking
o Change Request and Defect Tracking
o Budget Report
o Other
Large Project Budget Workbook – This is a multi-tabbed Excel
spreadsheet for tracking actual versus budgeted costs for
internal/external labor and non-labor items.
All projects of this nature will have a unique set of circumstances which will
require extensive customization of the communication plan.
-Communication Plan
-Various
communication
outputs per the
Communication Plan
Project Manager
(Owner)
Project Team
Portfolio Management
Office
Templates for various types
of meetings and resulting
notes can be found in the
AITS SharePoint Document
Library under Methodology
> Project Management
Lifecycle > as well as guides
to using Clarity and
SharePoint
Provide Short
Providing short term post project support will ensure that any issues that
- Production Support
- Production Fixes
Analyst (Owner)
AITS Project Management Life Cycle: Software Development Life Cycle 2.0: Close Phase
Page 65 of 67
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Term Post
Project Support
arise with the product of the project can be addressed in a timely manner.
This will help AITS provide the best customer service possible. By tracking
the short term support as part of the original project rather than lumping
support hours in with all other support will allow us to track how successful
the initial implementation was. This task will remain an active task on the
project plan for one month following implementation.
Requests
and Documentation
Revisions
Development
Provide
Production
Support
Once the application is in production it moves into production support
mode. As defects are discovered or enhancements requested the
application continues to be revised. The work that is requested on the
application varies in size and scope and depending on the effort required,
new ITPC templates may be generated requiring project teams to work on
the application or small development efforts may be done using a single
resource. Components of the SDLC will be engaged dependent upon the size
of the development effort required and what is needed. The Application
Design Document, Application Technical Overview, and Service Guides will
all remain updated as application changes are implemented. Production
Support is an ongoing process and exists outside of the project.
- ITPC Templates
- Work Requests
- Application Design
Document
- Application
Technical Overview
- Service Guides
- Application Design
Document
- Application
Technical Overview
- Service Guides
Analyst (Owner)
Development
Deployment
Project Close in
Clarity
Once the project is completed, either the Project Management Office or the
project manager will close the project in Clarity following the instructions
provided in “Guide to closing a project in Clarity” document. This includes
updating all tasks, resolving and closing all risks/issues/changes, updating
the project properties page with final status, and updating the PMLC
lifecycle page.
Project Manager
(Owner)
A guide to closing a project
in Clarity is available in the
SharePoint Document
Library
AITS Intranet:
Documentation Library >
Methodology > Project
Management Lifecycle >
Guides>
ClosingAProjectInClarity.pdf
Decommission
Application
When an application has reached the end of its life, it will need to be
decommissioned. An application may be decommissioned due to a change
in business practices, expense, or the function of the application may be
performed by another system. Each application is unique, but there are key
steps that should be followed to disable the application, analyze the
components of the application, and then remove the pieces that comprise
the system. There may also be a need to convert or archive the data for
future reference.
- Application
Technical Overview
- Application Design
Document
- Service Guides
- Application
Technical Overview
Analyst (Owner)
Project Manager
Development
Deployment
Customer
Quality Assurance
Security
Deployment
Operations
Portfolio Management
Office
Application
Decommissioning Process
Guide and Checklist
AITS Intranet:
Documentation Library >
Methodology > SDLC >
Guides >
ApplicationDecommissionin
gProcess.docx
AITS Project Management Life Cycle: Software Development Life Cycle: Index of Deliverables
Page 66 of 67
Software Development Life Cycle documentation concludes on the previous page.
Phase 5.2: Post Close
Activities
Description
Inputs
Outputs
Owner / Participant
Links / Notes
Conduct Six
Month Post
Project Survey
Conducting the Six Month Post Project Survey will allow AITS to gather
customer feedback after the product has been in place for a significant
amount of time. It will also allow us to revisit the anticipated benefits of the
project in order to analyze the accuracy of the original estimates. The
survey will be sent by the PMO to the Customer six months after project
implementation. Results will be gathered and summarized, shared with the
project team and analyzed across all projects by the PMO staff.
- Project Charter
- Six Month Post
Project Surveys
Portfolio Management Office
(Owner)
Project Manager
Project Sponsor
Customer
Project Survey
Process
