IAM deliverables
Each IAM project should have the deliverable communicated to the client during each of the following phases:
Pre Kick Off
SOW
Kick Off
Project Plan
Pre Development
Business Process Document
Functional Requirement Document
Use Case Suite
Architecture Document
Development
Design document
UAT
Test Suite
Release Notes
Demo Scripts
Production Deployment
Organizational Manual
Release Plan
Release Playbook
Project Sign Off
Project Sign Off
SOW
The Statement of Work "SOW" is the document that is going to define and capture the work that needs to be performed during the project. It will list the work activities as well as deliverable expected and timeline.
Project Plan
The project plan should reflect the different phases identified within the SOW.
Each of the phases should have sub tasks identified. Each of those sub tasks should have a deliverable (document, code...) affiliated to it.
We will use each of those sub tasks as a "Task" in JIRA so we can track accordingly the status/progress of the project.
Business Process Document
The Business Process document, will details the different business process that can be applied to the client. This document only talk about business process. It will be high level processes.
The business process document will reflect for example the "Data Model", the different "State Model" of users.
An example of different processes for a company can be any of the following:
Create user process
Create admin user process
Modify user process
Create role process
Modify role process
Delete role process
Create resource process
Modify resource process
Delete resource process
Assign role/resource process
Revoke role/resource process
........
Each of the processes listed in the document need to be followed by an "Activity Flow" that will represent the different steps of each of the Processes.
Functional Requirement Document
The functional requirement document will set the base of the Scope work that is going to be performed within the project.
This document will need to obtain sign off by the client before starting any development work.
Some of the key components of this document are the foll9owing:
Attribute level process flow
Schema Mapping (Attribute Dictionary)
Mapping tables
Connected systems requirements (define source and target)
List of Roles and Resources
............
Use Case Suite
The Use Case Suite or Use Cases document, is the document that will refer to all the use cases that will apply to the project.
A use Case is a list of steps that define an interaction between a role (authors / actors) and a system.
The different steps that are required for each of the use cases are:
Use case number
Primary actor
Secondary actor (if applicable)
trigger event
preconditions
post conditions
brief description
basic flow
exceptions (if applicable)
variations
Architecture Document
The Architecture Document reflect the physical or virtual architecture.
It need to include the following:
Solution architecture (representation of physical and virtual server and connectivity between each of them)
Option available for the solution architecture (for example fail over option)
Network state
Specification needed for each of the environments agreed within the scope (usually DEV, QA, Prod)
server role
CPU\RAM
Hard Disk
OS
Network
Design document
Each of the connected systems will have an individual design document.
We also need to have an IDV Design Document that will reflect:
IDV Schema
Notes
Attribute mappings
Bellow is an example of a IDV Design Document created for the Norwalk project.
Norwalk Health IDV Design Document.docx
Each of the connected systems design documents need to have the following:
Schema mapping
List of policies
explanation of the policies
explanation of the business logic
Filter
Bellow is an example of a Design Document created for the DCFS project.
LA CAFE - Novell IDM RACF Driver Design Document v 1 0 0.docx
I design document will also be needed for the workflows if applicable.
Bellow is an example of a Workflow Design Document created for the DCFS project.
LA CAFE - CAFE Role Workflow Document.docx
Test Suite
A test case is a set of conditions under which a tester will determine whether the application/driver is working according to the design.
The test case Suite reflect all the test cases for each of the systems implemented within the project.
Each of the test cases need to have all of the following:
Test case number
test case requirement
test case name
pre-requirements
test case objectives
status (Pass, failed, not run)
retest date
notes
Bellow is an example of a Test Suite created for the DCFS project.
Workflow Test Case Document.xlsx
Release Notes
Demo Scripts
Organizational Manual
The organizational manual will reflect the different path and account information related to the clients environment.
For example we will be listing the following items:
path to eDirectory
path to configuration files
admin account information
user application admin account information
drivers account information
remote loader account information
......
Release Plan
The Release Plan, is a checklist of of all the elements/deliverable that need to be completed prior to planning a deployment in production environment.
Each of those elements/ deliverable will need to be marked as completed, passed before moving forward in the project.
Release Playbook