avoli.comavoli.com/assets/docs/sdlc.doc · Web view(Six Sigma DMAIC & DFSS IDDOV) (Failure is NOT...

SDLC Enterprise Guide

(Six Sigma DMAIC & DFSS IDDOV)

(Failure is NOT an option – Stay Focused, Adapt to Change & Push Hard)

This living document serves as a means to guide Technology Delivery Managers / Project Managers through the administrative side of the SDLC, project repository, artifacts (mockups/charts/diagrams), content language translations, meeting invitations, attendees, remote bridge lines, agenda, meeting notes, deliverables, conclusions, action items and deadlines as a forced structured discipline.

()

Author: Eddie Drye

Table of Contents

5Phase 1 –Define / Needs Assessment / Requirements

5Project Scope: Define / Measure / Analyze, Develop Schedule

6DOCUMENT: Master Project Milestone Schedule

7Phase 2 – System Analysis / Refine Requirements

7Project Evaluation: Define / Measure / Analyze, Develop Plan

8Daily Morning Huddle (Quick Roll Call & Individual Work Task Review)

9Daily Work Session Meetings (Presentation Layer Discussions)

10Weekly Progress Meetings (Convey Progress – All Hands on Deck)

11DOCUMENT: Content Localization Form

12DOCUMENT: Business Requirements Document (BRD)

16Phase 3 – Design

16Analyze / Development (JAD Project Kickoff)

16DOCUMENT: Component Interface Sheet (Front End)

16DOCUMENT: Object Interface Sheet (Back End)

16JAD High Level Design (HLPP/HLD) Meeting

16Create Use Cases / Determine Time Estimates

16Document: Artifact & Development Schedule

16Document: Next Release / Enhancements – Development Schedule

16DOCUMENT: Software Evaluation Scorecard

16DOCUMENT: Hardware Evaluation Scorecard

16DOCUMENT: Execution Plan - HLD Mockups & LLD Proof of Concepts

16DOCUMENT: High Level Project Plan (HLPP/HLD)

16JAD Low Level Design (LLD) Meeting

16Create Acceptance Tests / Re-Affirm Time Estimates

16DOCUMENT: Low Level Design (LLD)

16JAD Pre-Development Design Meeting

16Design Deliverables / Marching Orders

16Technical Overview

16Phase 4 – Develop / Construction / Build

16Improve / Development (Code)

16Development Procedures Overview

16Progress Notes: Front End Development

16Progress Notes: Back End Development

16Progress Notes: Reports Development

16DOCUMENT: Test Plan (Test & Production)

16Milestones Meeting (Progress Report)

16Milestones Scripted Walkthrough MeetingS

16Milestones Pre-Test Overview

16Phase 5 – Testing & Quality Assurance

16Improve / Verification (Pre-Deployment to Test)

16Test Plan: Unit Tests / System Tests (To be utilized for Deployment to Test & Production)

16Testing Results & Signoff Meeting

16Post Staging (UAT) Testing

16Phase 6 – Deploy / Implementation Phase

16Improve & Control / Verification (Pre-Deployment to Production)

16Test Plan: Unit Tests / System Tests (To be utilized for Deployment to Test & Production)

16Production Testing Results & Signoff

16Post Production (PROD) Testing

16Phase 7 – Support

Bridge Line Information (Example Vendor: pgi.com)

Put your conference information below for easy reference.

Participant Information

Moderator Information

Company Name:

Bridge Line Number:

International:

Participant Code: #

Company Name:

Moderator:

Host Code: #

Using This Template

This template is intended for use as a foundation for requirements development in support of all Technology Projects. In agreement with using this template you agree to indemnify and hold Avoli harmless from it’s use. It is designed as a recommended guide that can be modified as necessary. The requested information and format captured within this document does not supersede good judgment nor does it necessarily dictate execution. Each change initiative must determine which sections are applicable based on the type of change.

To provide consistency for consumers of this document across the enterprise, do not delete any of the recommended sections. Instead, enter ‘Not Applicable’ or ‘N/A’ along with a short description of the reason for the decision within any of the Sections (where allowed) that do not apply or will not be used for your project.

1) Utilize this template to manage a SINGLE project (Why? Move through TOLL GATES quicker)

2) Search & Replace token tags with their appropriate values ( Ex: < Goals > )

3) Schedule dates will be built as you go as you Search & Replace each phase/step dates

4) If you do individuals wearing multiple hats their names should go into the roles they are performing

5) Phased DOCUMENTS are colored in GRAY

6) Each DOCUMENT should include < Project Name > in the event the document is distributed separately from the SDLC Guide.

7) Meeting Discussions, Conclusions, Action Items should be short, to the point and clear

8) DAILY and WEEKLY meeting pages are to be utilized from Phase 3 on

9) The Master Schedule is designed to meet most schedule needs. (Utilize other scheduling tools if needed)

10) Ensure artifacts such as MOCKUPS, CHARTS, DIAGRAMS, SCHEDULES may have HYPERLINKS directly to your repository folder

11) PRESENTATIONS should be external to this document and should tell the story

(Assume your user knows nothing about your application)

Terms

1) You acknowledge this document is distributed under Creative Commons

2) You will not hold Avoli, Inc. the owner nor its owners, investors, authors, associates responsible for any content or outcome from the use of this document.

3) You agree to keep Avoli logo in the header left justified, you agree to keep Avoli text, author name and version in the footer

Instructional Text

1) BLUE, ITALIC Text has been marked as hidden text. To toggle instructional text do the following:

Word 2003 – Select the Reveal Formatting option from the Format dropdown menu

Word 2007 – Click on the show/hide symbol ¶ on the ribbon/toolbar or (Ctrl + *)

2) Hidden text will not show in a printed document. To print hidden instructional text:

Word 2003: On the Tools menu, click Options, and then click the print tab. Within Include with Document, select hidden text option.

Word 2007: The Options command that was on the Tools menu was moved to be under the Office Button at the bottom. Click on Word Options, click Select Display, select print hidden text under printing options.

Project Management Tips

1) EFFECTIVENESS: Make the most of unscheduled time / Be results oriented / Use your strengths

2) YOUR VALUE: Keep a positive attitude / Present ideas clearly / Help your boss look good

3) SCHEDULING: Eliminate time wasters / Use available technology / Build in Flexibility

4) NEXT RELEASES: Utilize the Next Release / Enhancements – Development Schedule to keep track of next version tasks

5) WORK AREA: Keep a clean work desk (Put away confidential documents)

6) MEMOS: Keep it brief / To the point / Use correct form & Etiquette / Be accurate

7) ELIMINATE WORDS: Hope, Wish, Should, Maybe

8) INTERRUPTIONS: Keep a time limit / Walk through method / Sign on door / Schedule Regularly

9) REWARDS: Give verbal praise / Public recognition / Certifications / Time off

10) PROBLEM PEOPLE: Level set expectations / Course Redirection when needed / Reprimand when needed / Terminate if necessary

11) Any associate time worked around Dinner should prompt you to have Dinner delivered (Especially if associates have families) – Don’t be a cheap ass about it and pay them for additional hours work.

Deliverable Tips

1) Utilize developers who come to the table with a repository of generic code that they own and are willing to contribute

2) Utilize seasoned developers that have proven to operate effectively on their own with minimal direction

3) Replace associates early on that do not show a propensity to grasp the project quickly

4) Document changes and move dates accordingly (where possible)

5) Quickly adjust to change

6) Have morning / daily touch base meetings (See: Daily Morning Huddle / Daily Work Session sections)

Phase 1 –Define / Needs Assessment / Requirements

Initial Date: – [ Room Location ]

Targeted Completion Date:

Type of meeting

Project Scope: Define / Measure / Analyze, Develop Schedule

Bridge Line

International: Participant Code:

Required Attendees

(Project Owner), (Technology Delivery Manager)

(Project Manager), (Business Analyst)

Agenda

(Technology Delivery Managers Name) is the moderator.

1. Welcome / Introductions / Recognition / State Purpose

2. Review Goals, Requirements, Translations, and Absorbed Tasks etc.

Review

Project Name

owners name

Desired Completion Date

()

Business Case:

Potential Roadblocks:

TASK GOALS

Absorbed Tasks

SCOPE

Groups Affected:

Products Affected:

Programs Affected:

Countries Affected:

Systems/Applications Impacted (Integrated Release?)

Sys or App

Name

Impact / Cost

Owner

SYS

Requirements GUI (Interface) / DB (Database) / RPT (Reports)

GUI-1:

Rules

RULE-1:

MINUTES: Meeting NOTES / Subsequent Meeting Notes

Date

Discussions

Conclusions

Action Items (Take Aways)

Initial

1. Good morning/afternoon/roll call

2. Define goals/requirements, rules, timeline, systems, countries?

3. Do we ACCEPT the project?

1. Goals, timeline defined

2. Requirements, rules defined

3. Scope, content defined

4. We ACCEPT the project

· PM: Schedules Systems Analysis mtg

· PM: Creates Repository (Ex: Sharepoint) folder

· TDM: Create Master Schedule

DOCUMENT: Master Project Milestone Schedule

The following are the scheduled project steps and durations gauged as denoted in days or months.

Milestone dates are in GREEN. Also HLD Mockups are essential and LLD POCs (Proof of Concepts tell the story for easier toll gate passage)

√

SDLC Milestone Activity

Start

Finish

√

Phase 1 – Project Initiation / Needs Assessment

√

Create Master Project Milestone Schedule

Phase 2 – System Analysis

Project Evaluation Meeting

Create Content Localization Form (optional)

N/A

N/A

BRD Creation & Signoff (Toll Gate)

Phase 3 – System Design (JAD)

HLD Meeting

Hardware Capacity Planning (optional)

Software / Hardware Scorecards (optional)

Create Execution Plan HLD Mockups

Create Use Cases / Process Flow Diagrams

Create Data Flow Diagrams

HLPP/HLD Creation & Signoff (Toll Gate)

LLD Meeting

Create Execution Plan LLD POCs (optional)

Create Acceptance Tests

Create Component Interface Sheets

N/A

N/A

Create Schema Diagram & Schema Tables

LLD Creation & Signoff (Toll Gate)

Pre-Development Design Meeting

Phase 4 – Construction

Milestone Meetings (ongoing and conditional)

Demonstration Owner/Customer (Scripted Walkthroughs – Based on staged completion)

System Integration Testing (SIT Unit Tests)

Phase 5 – Testing & QA

Pre-Deployment to Test Meeting

Review Test Plan: Unit Tests / System Tests

UAT Testing & Signoff (Toll Gate)

Phase 6 – Implementation

Pre-Deployment to Production Meeting


Prod Testing & Signoff (Toll Gate)

Customer Training / Documentation

Phase 7 – Support

Ongoing Steady State Support / Enhancements

Ongoing

Legend

Milestone

Duration

Partial

Complete

Tested

SOS

Phase 2 – System Analysis / Refine Requirements



Type of meeting

Project Evaluation: Define / Measure / Analyze, Develop Plan

Bridge Line


Required Attendees



Agenda


1. Welcome / Introductions / Recognition / Quick Status / State Purpose

2. The purpose of this meeting is to create the BRD document from the Planning Phase results

Review

Project Name

owners name

Desired Completion Date

()

Business Case:

Potential Roadblocks:

TASK GOALS

Absorbed Tasks

SCOPE

Groups Affected:

Products Affected:

Programs Affected:

Countries Affected:

Systems/Applications Impacted (Integrated Release?)

Sys or App

Name

Impact / Cost

Owner

SYS

Validate Requirements – GUI (Interface) / DB (Database) / RPT (Reports)

GUI-1:

RULES

RULE-1:


Date

Discussions

Conclusions


Initial


2. Are we able to meet the needs?

3. Do we still ACCEPT the project?

1. System Analysis complete

2. We still ACCEPT the work

3. Develop our project schedules

· PM: Schedules BRD Meeting w/ BA

· TDM: Schedules DAILY/WEEKLY mtgs

· PM: HOLD PATTERN until BRD Signoff

Daily Morning Huddle (Quick Roll Call & Individual Work Task Review)

Initial Date: Daily Ongoing (See Calendar)


Type of meeting

Touch Base Meeting

Bridge Line


Required Attendees

(Technology Delivery Manager)

(Project Manager) , (Business Analyst)

(Front End Developer), (Back End Developer)

Optional Attendees

(Visual Designer), (Test Representative)

Agenda

(Technology Delivery Manager) is the moderator.

The purpose of this meeting is to individually discuss status and accept daily tasks

1. Roll call

2. Roundtable Discussions - Individually discuss your tasks completed & tasks being worked

a) If your behind discuss it

b) If you need assistance ask for it

c) If you have a problem discuss it

3. Accept assigned tasks / Govern yourself accordingly

MINUTES: Meeting NOTES / Subsequent Meeting Notes (Agile Iteration Release Changes)

Date

Phase

Discussions

Conclusions


Initial

Systems Analysis

1. Analyze what is to be done

2. Is everything feasible?

1. Our understanding is…

· PM: Takes notes

(Date)

BRD

1. Define BRD Requirements

2. Capture everything

1. BRD is ready for submittal

· TDM: Aims to get BRD signoff

(Date)

JAD Initial Meeting

1. Discuss interfacing, technology

2. Are there any roadblocks

1. Overall design understood

· PM: Takes notes

(Date)

HLPP/HLD

1. Everyone provides status

2. Ask for assistance if it’s needed

1. HLD on Schedule

· TDM: Aims to get HLD signoff

(Date)

LLD

1. Everyone provides status


1. LLD on schedule

· TDM: Aims to get LLD signoff

(Date)

Construction

1. Everyone provide status


1. Tasks ON/OFF schedule

· PM: Takes notes

(Date)

UAT Testing

1. Who is working testing issues?

2. Get TEST Signoff

1. Modify, Unit Test (scripts), Test

· TDM: Aims to get TEST signoff

(Date)

PROD Testing

1. Who is working testing issues?

2. Get PROJECT Signoff

1. Modify, Unit Test (scripts), Test

· TDM: Aims to get PROD signoff

(Date)

Project Signoff

1. Get Project signoff

2. Get Tech & Owner signoff

1. Get owner signoff

· TDM: Aims to get PROJECT signoff

Daily Work Session Meetings (Presentation Layer Discussions)

Initial Date: Daily Ongoing (See Calendar)


Type of meeting

Drive out GUI Look and Feel

Bridge Line


Required Attendees

(Project Owner), (Project Manager)

(Business Analyst), (Visual Designer)

Optional Attendees



Agenda

(Project Manager) is the moderator with (Project Owner) input.

The purpose of this daily meeting is to drive out the GUI (Graphical User Interface) look and feel.

1. Work visual design aspects with the owner

2. Work charts, reports with the owner

3. Discuss Phase/Milestone objectives and progress


Date

Phase

Discussions

Conclusions


Initial

BRD

1. Requirements / Business Rules

1. Finish the BRD

· BA: Work on the BRD

(Date)

System Design

1. Evaluate BRD Processes / Reqs

1. Leading up to HLPP/HLD

· PM: Translate BRD to design

(Date)

HLPP/HLD

1. Basic layout / Navigation Mockups

2. Overview of Processes / Flow

3. Overview of Exports / Reports

4. Screen by Screen Design Mockups

1. Owner asked for…

2. Agreement reached on…

· PM: To take action to ensure certain items are taken care of that may be brought up.

(Date)

LLD

1. Basic layout / Navigation POCs

2. Components / Gadgets

3. Exports / Reports / Feature Security

4. Screen by Screen Design POCs




(Date)

Construction

1. Basic layout / Navigation

2. Components / Gadgets

3. Exports / Reports / Feature Security

4. Screen by Screen Design




(Date)

UAT Deployment

1. Develop Test Plan

2. Determine Schedule

1. We can deploy

2. Everyone be available to test

3. Document any issues


(Date)

PROD Deployment

1. Refine Test Plan

2. Determine Schedule

1. We can deploy

2. Everyone be available to test

3. Document any issues


Weekly Progress Meetings (Convey Progress – All Hands on Deck)

Initial Date: Weekly Ongoing (See Calendar)


Type of meeting

Progress Overview

Bridge Line


Required Attendees




Optional Attendees

(Visual Designer), (Test Representative)

Agenda


The purpose of this weekly meeting is to provide oversight overview of the projects progress to management.

1. Welcome / Introductions / Recognition / State Purpose / Quick Status to Owner

2. Discuss Phase/Milestone objectives and progress

3. Where are we in the timeline?


Date

Phase

Discussions

Conclusions


Initial

BRD

1. BRD is a work in progress

1. Still defining requirements

· BA: Work on the BRD

(Date)

System Design

1. Evaluate BRD Processes / Reqs

1. Leading up to HLPP/HLD

· PM: Translate BRD to design

(Date)

HLPP/HLD

1. High Level Project Plan underway

2. We are on schedule

1. Still formulating overall High Level Project Plan (HLPP)

· PM: To complete HLPP/HLD

(Date)

LLD

1. We are making excellent progress

2. Soliciting input & feedback from functional leads and stakeholders

3. Base Schema exists


1. Meeting went well

2. Management pleased

3. Making good progress

4. Management has asked for…


(Date)

LLD

1. We are making very good progress

2. Schema tweaks continue

3. We are soliciting input and feedback from functional leads and stakeholders.

a) Daily working sessions

b) As well as Weekly mtgs






(Date)

Construction

1. The web site continues to take form as we develop more web pages

2. Test Data for Reports / Pages







(Date)

UAT Deployment

1. Refining Test Plan


1. N/A

· PM: Schedule Deployment/Test

(Date)

PROD Deployment

1. Refining Test Plan


1. N/A

· PM: Schedule Deployment/Test

DOCUMENT: Content Localization Form

Project Name

()

Purpose

The purpose of this document is to manage content that requires language translations. Automatic language translations should only be utilized as an initial translation step then finalized with manual translations.

Background

In protection of corporate brand all content must be approved to fit for use in the public sector and for language translations by country.

NOTE: This document should be completed in a timely manner as to NOT impact the project content translations.

Est. Go Live Date:

Project Manager:

Business Case:

New App / Web Site Page:

Email Alert (Message Gram):

NOTES

Take the content attached to this document and translate it into languages by country.

Note: Some countries would have the same base language (Ex: USA/Canada)

Milestone Name

See attached BRD, Screen Snapshots/Artifacts (Mockups)

SCOPE

Groups. Affected:

Products Affected:

Programs Affected:

Countries Affected: (Utilized for language translation sets)

* This section for content managers only *

Reviewed By

Date/Time Received

Date/Time Completed

Signature / Comment

Business Analyst

Content Manager

Creative Services

Owner

US Legal

International Legal

US Country Manager

DOCUMENT: Business Requirements Document (BRD)

This document describes what is expected from the development of this project.

pROJECT nAME

()

Project Owner

Revision History

Business Analysts

Date

Reason for Change (Page/Section)

Version

Creation of BRD

Cleanup BRD for Signoff

Nomenclature

aCRONYMs

dESCRIPTION

LOB

SOR

SCHEMA

BCP

HIGENE

MALFORMED

STALE

Line of Business

System of Record

Database structure as it relates to Databases, Tables, Indexes & Relations

Business Continuity Plan (Disaster Recovery)

Data Cleansing / Scrubbing

Invalid Data / Layout / Formatting

Data which is Old / Invalid / Non-Active

1.0 – Project Background

1.1 – Project Objective

1.2 – Scope (Broken down into sections)

1. LOB Interfacing

2. Back End Data Stores

3. Front End Interfaces

Groups Affected

Products Affected

Programs Affected

cOUNTRIES aFFECTED

Target Users

Systems Touched


1.3 – Success Metrics

Critical

Description

Current

Target

1. More efficient

Yes

2. Reduction in errors

Yes

3. Reduced Operating Costs

Yes

4. Decrease in man hours

Yes

5. Become Compliant

Yes

6. Integrate with other LOBs

Yes

7. Competitive Advantage

Yes

8. Reduce Paper

No

1.4 – Assumptions / Dependencies / Constraints

Raised by

Confirmed By

1. Dependency – Network will be available (Support)

2. Dependency – Systems will be available (Support)

3. Assumption – Funds will be available to complete the project

4. Assumption – Proper training of staff

5. Assumption – Systems will be backed up

6. Constraints – Offshore Developers command of the English language

7. Constraints – Offshore Developers ability to pick up terminology

8. Constraints – Offshore Developers ability to understand processes

9. Constraints – Offshore Developers ability to meet deadlines

10. Constraints – File Upload folder will exist

11. Constraints – File Upload folder will have appropriate permissions

12. Constraints – File Upload folder will have enough disk space

2.0 – User Requirements

2.1 – Actors / Roles

Project Owner ASSIGNED:

Will be responsible for stating their requirements as well as ensuring the BRD meets their requirements.

Technology Delivery Mgr ASSIGNED:

Will be responsible for the integration, cross-technical and multi-team coordination required to deliver technical services. Collaborate with leaders to gather requirements and monitor ongoing service levels and communications.

Project Manager ASSIGNED:

Will be responsible for the project from inception to completion. The project manager manages the project, people, milestones, content, translations, deliverables & owner to stay on track with original requirements.

Business Analyst ASSIGNED:

Will keep the Business Requirements Document updated with any functional changes that occur during the design process. Business Analysis should attend to answer any business rules questions that arise.

Front End Developer ASSIGNED:

Will be responsible to know his assignments and review and accept the time estimates. The developer should know if a Process Flow is required and be prepared to develop or modify the existing process flow. The developer will be required to prepare a Component Interface Sheet (Ex: Web Service) that is used to perform this responsibility.

Front End Architect ASSIGNED:

Architects lead the technical design. Review all processes making sure correct foundation is used including our best practices and established methodologies.

Back End Developer ASSIGNED:

Will be responsible to know his assignments and review and accept the time estimates. The developer will be required to prepare an Object Interface Sheet that is used to perform this responsibility.

Back End Architect ASSIGNED:

Architects lead the technical design. Review all processes make sure correct foundation is used including our best practices and established methodologies.

Content Manager ASSIGNED:

All content is identified for including content, emails, message grams, help screens and web pages. Content reviewed by Content Manager, Creative Services, Owner, US Legal, Intl Legal, Country mgr etc.

Testing Representative ASSIGNED:

They will be responsible for developing an understanding of any new process and preparing a test plan for the project.

Visual Designer ASSIGNED:

Creates all aesthetics in regards to visual presentation with images, flash etc. for creation/modification.

2.2 – Current Environment Assessment

Ex: Non Existing / Mainframe DB2 Green Screen …

2.0 – User Requirements

2.2 – Current Environment Assessment

Ex: Non Existing / Mainframe AS/400 DB2 Green Screen …

2.3 – Target Environment needs

Ex: Microsoft .Net C# / Microsoft SQL Server (version?) / Oracle (version?) …

2.4 – Usability Requirements GUI (Interface) DB (Database) RPT (Reports)

BRD Req#

HLD Task

Meet the Requirement

GUI-1

Ex: Secure Authentication

The user will be presented with a Login Page

GUI-2

Web Interface Front End

Web interface built to standards with appropriate navigation.

2.5 – Business Rules

BRD RULE#

HLD Rule

Description

RULE-1

Ex: Files will be processed every 30 minutes

Drop zone files will be scrubbed and saved

RULE-2

Ex: International Data is NOT allowed

Only US customer addresses allowed

2.4.1 – Data Management Impacts

Description of Impact

How will the use of information change as part of this initiative?

What business problem are we trying to solve?

Describe the type of information you require.

Are there regulations around how the information is retained?

Are there special requirements for the destruction of data?

Identify data elements that need to be added or changed?

Is there a need to report or share this information?

What information is being shared and with whom?

Identify information shared w/ other international functions.

Are there requirements to report on the quality of information?

What are known data quality issues that need to be addressed?

What quality requirements must the data meet?

What information is being shared and with whom?

3.0 – Engineering Requirements

3.1 – Current Technology Environment

3.2 – Target Technology Environment

Ex: Legacy IBM Servers / DB2 Database / Websphere / 10 megabit network (Coax) …

Ex: Windows Servers / Microsoft SQL Server / 100 megabit network / 1 gigabit backbone (fiber) …

3.3 – Functional Requirements

1. Servers to be configured with multiple 1 gigabit network cards

2. Servers to be on automatic backup (Auto-loaders)

3. Servers to be placed on UPS (RED Outlets)

4. Servers to have distinct colored network cables (Backbone = GREEN)

5. Servers to be setup on networked KVM switches

6. Any software hardware keys are to be secured to the back of the servers (if applicable)

3.4 – Other Technology Requirements

1. Single Sign-On Login Method (Ensures LDAP Active Directory user credential authentication)

2. Setup of MQ File Transfer / FTP File Transfer

3. Setup SMTP with automatic fail over to other SMTP addresses (Ensures emails go through)

3.4.1 – Design Considerations

Ex: Implement hardware network as a DMZ (Demilitarized Zone)

3.4.2 – Implementation Impacts

1. Hardware arrives on site late

2. Hardware doesn’t come configured as ordered

3. Hardware has compatibility issues with software or network

4. Capacity Planning estimates are wrong

Project Timeline

Orig Date

Proposed Go Live

Project Time Code

Repository

Business Analyst Signature

(Business Analyst)

Technology Signature


Owner Signature

(Project Owner)

Phase 3 – Design



Type of meeting

Analyze / Development (JAD Project Kickoff)

MEETING PREP

Prior to or during the formal kickoff meeting the (Project Manager) should discuss with

(Test Representative) if they should be available for the functional review of the project.

Bridge Line


Required Attendees



(Front End Architect), (Back End Architect)


(Visual Designer)

Optional Attendees

(Content Manager), (Test Representative)

Agenda

MEETING EMAIL ATTACHMENTS

Business Requirements Document (BRD)


The purpose of this meeting is to translate the Business Requirement Documents (BRD) into the how we’ll arrive at the solution. We will demonstrate how we will accomplish the requirements through a wire frame walk through (white board) of the business processes. No code is to be written before this meeting unless approved.

1. Welcome / Introductions / Recognition / State Purpose / Quick Status

2. (Technology Delivery Manager) reviews current system (if any)

3. (Content Manager) to give status of Content Localization Document

4. Review BRD Goals & Roles

5. Review Content Localization/Translations (if any) –

resource issues here

Training issues / software Needs

Remote location issues

None

None

None


Date

Discussions

Conclusions


Initial


2. Review BRD Goals/ Requirements

3. Do we know impacted systems & groups impacted?

4. Do we understand the content?

5. Does content need translations?

6. Do we have the resources?

7. Training or Software needs?

8. Remote location issues?

9. If there are no more comments or questions this meeting is adjourned, have a good remainder of your day

1. Roles confirmed (See: BRD)

2. Developers checkout programs (if we are modifying code)

· PM: Schedules JAD Meeting

· PM: Inserts Content Localization Form in repository

· (Front End Developer) to create Process Flow Charts & Component Interface Sheet

· (Back End Developer) to create Object Interface Sheet

· (Visual Designer) start artifact mockups

DOCUMENT: Component Interface Sheet (Front End)

This document describes components and their exposed methods.

pROJECT nAME

()

Purpose

The purpose of this document is to define components and their exposed methods for communicating purposes.

Object List

Component

Exposed Method Name

Syntax / Params

Return

Comment

SSO Web Service

Avoli.Security.Authenticate

strCookie = Avoli.Security.Authenticate (gUserID, gPassword)

Cookie (String) &

HTTP_Header Keys/Values

The return string a cookie and header values.

DOCUMENT: Object Interface Sheet (Back End)

This document describes components and their exposed methods.

pROJECT nAME

()

Purpose

The purpose of this document is to define objects/scripts and their exposed methods for communicating purposes.

Component List

Object

Params

Syntax

Return

Comment

sp_DataHigene

String dat

Sp_DataHigene (string dat)

Row Count (int)

Cleanse Data

JAD High Level Design (HLPP/HLD) Meeting



Type of meeting

Create Use Cases / Determine Time Estimates

Bridge Line


Required Attendees




Agenda


Business Requirements Document (BRD)

The purpose of this meeting is to create the High Level Design (HLD) with the Business Requirements (BRD) as the supporting document in estimating all aspects of the development. No code is to be written before this meeting unless approved.

(Project Manager) is the moderator with TDM present for oversight.


2. Utilize milestones from BRD for major HLD Use Case blocks

3. Talk through all Front End and Back End steps for each milestone for time estimates

4. Determine the projects “HLD Due Date” and “Go Live” date that our HLD will stay within (If able to do so)

PowerPoint

(Tell the Story)

GUI (Interface)

DB (Database)

RPT (Reports)

Presentations

Description (Assume your audience knows nothing)

GUI-1:

This reflects how we envision the interface main page will appear

(Click image to view)

1) PM is to share his desktop to all attendees (Ex: Windows Communicator)

2) Introduction

3) Core Milestone Features

See: repository folder


Date

Discussions

Conclusions


Initial


2. Follow BRD Requirements

3. Milestones

4. Develop Use Cases

5. Develop HLD from BRD Requirements

6. Determine Go Live date


DOCUMENT CREATION

1. HLPP/HLD Due Date:

2. Targeted Completion:

3. Estimated Go Live:

4. (Project Manager) creates the HLD from this meeting

· PM: To create HLPP/HLD with Developers

· PM: Handoff Execution Plan Document to to finish

· PM: Assigns Software/Hardware Scorecards & places orders when done

· TDM: Creates Development Schedule

· PM: Insert HLPP/HLD/BRD mods into repository folder

· PM: Schedules HLD Signoff Meeting

· HOLD PATTERN until HLPP/HLD Signoff

· PM: Schedule JAD LLD Meeting

Document: Artifact & Development Schedule

The following are the scheduled tasks and durations gauged as denoted in days or months.


√


Start

Finish

√

Phase 1 – Project Initiation / Needs Assessment

√

Phase 2 – System Analysis

√

Phase 3 – System Design (JAD)

HLD Meeting

Hardware Capacity Planning (optional)

Software / Hardware Scorecards (optional)

Create Execution Plan HLD Mockups

Create Use Cases / Process Flow Diagrams

Create Data Flow Diagrams

HLPP/HLD Creation & Signoff (Toll Gate)

LLD Meeting




N/A

N/A




Phase 4 – Construction

Milestone Meetings (ongoing and conditional)

GUI-1: Single Sign On/Logout (SSO component)

GUI-2: Master Page (index.aspx)

GUI-3: Site Map (sitemap.aspx)

Demonstration Owner/Customer (Scripted Walkthrough – Based on staged completion)

GUI-4: Search (search.aspx)

GUI-5: Settings (settings.aspx)


RPT-1: Report Builder (reportbuilder.aspx)

RPT-2: Reporting Gadgets (reports.aspx)


Phase 5 – Testing & QA




Phase 6 – Implementation





Phase 7 – Support

Legend

Milestone

Duration

Partial

Complete

Tested

SOS

Document: Next Release / Enhancements – Development Schedule

The following are the scheduled tasks and durations gauged as denoted in days or months.


√


Start

Finish

Next Release – Assessment

Task Review Meeting (Prioritize)







Next Release – Construction

Task1

Task2

Task3


Task4

Task5


Task6

Task7


Next Release – Testing & QA




Next Release – Implementation





Next Release – Support

Legend

Milestone

Duration

Partial

Complete

Tested

SOS

DOCUMENT: Software Evaluation Scorecard

(Req

irements)

Weight

Score

PoinTs

Notes

Ease of Use

2

2

8

Easy To use

Aesthetics

2

3

8

Could be better

Rapid Application Development

3

3

10

Fast RAD Tool

Features, Reporting & Analytics

2

2

8

Features are lacking

TOTAL SCORE

9

10

34

Reviewer:

Evaluated: (Date)

Software: C

Evaluation Criteria (Requirements)

Weight

Score

Points

Notes

Ease of Use

2

2

5

Could be better

Aesthetics

1

0

4

Disappointing

Rapid Application Development

3

2

10

Good RAD Tool

Features, Reporting & Analytics

2

1

8

Disappointing

TOTAL SCORE

8

5

27

Weight (3 = Essential / 2 = Desirable / 1 = Nice to have) Score (0 = does not meet / 1 = partially / 2 = meets / 3 = exceeds) Points (weight x score)

DOCUMENT: Hardware Evaluation Scorecard

Project Name

()

Usage

Hardware to be utilized to support storage and operability (Requirement: Rack Load Balanced, NAS Solution)

Software Evaluated

Hardware

Manufacturer

System

Item#

A

DELL

PowerEdge Rack

Rack 4U 910

B

HP

Integrity Rack

RX6600

C

IBM

iSeries

iSeries

RFP / RFI Scorecard

Reviewer:

Evaluated: (DATE)

Software: A


Weight

Score

Points

Notes

Desired Configuration

3

3

10

Surpasses Needs

Performance Indicators

3

3

10

Extremely High Benchmarks

Upgrade Path / Customization

3

3

10

Very Customizable

Network Capabilities

3

3

10

Utilizes Latest Capabilities

TOTAL SCORE

12

12

40

√ OUR SELECTION

Reviewer:

Evaluated: (Date)

Software: B


Weight

Score

PoinTs

Notes


1

3

10

Meets Needs


2

1

4

Average Benchmarks


3

3

10

Very Customizable


3

3

10

Utilizes Latest Capabilities

TOTAL SCORE

9

10

34

Reviewer:

Evaluated: (Date)

Software: C


Weight

Score

Points

Notes


3

1

2

Needs Not Met (Research)


2

1

3

Good Benchmarks (Research)


0

0

0

Vendor Non-Responsive


0

0

0

Vendor Non-Responsive

TOTAL SCORE

5

2

5

** Vendor site used for review

Weight (3 = Essential / 2 = Desirable / 1 = Nice to have) Score (0 = does not meet / 1 = partially / 2 = meets / 3 = exceeds) Points (weight x score)

DOCUMENT: Execution Plan - HLD Mockups & LLD Proof of Concepts

This document contains pages to be worked for HLD/LLD GUI Layout.

Project Name

()

urpose

The purpose of this document is to create HLD Mockups, LLD Proof of Concepts (POCs’) and track approvals.

Task Status (Ordered by Priority)

REQ#

Project/Sitemap Task

Rating

HLD Mockup % Complete

LLD POC % Complete

POC Tested

Content Reviewed

Owner Reviewed

Due Date

POC PAGE

GUI-1

SSO – Single Sign On Login & Logout

Easy

100%

100%

(Date)

(Date)

(Date)

login.html / logout.html

GUI-2

Welcome/Introduction

Easy

0%

0%

(Date)

(Date)

(Date)

index.html

GUI-3

Standard Layout

Easy

0%

0%

(Date)

(Date)

(Date)

index.html

GUI-4

Sitemap

Easy

0%

0%

(Date)

(Date)

(Date)

sitemap.html

GUI-5

Screen 1

Easy

0%

0%

(Date)

(Date)

(Date)

screen1.html

RPT-1

Report 1

Easy

0%

0%

(Date)

(Date)

(Date)

report1.html

GUI-6

Menu Builder

Moderate

0%

0%

(Date)

(Date)

(Date)

menubuilder.html

GUI-7

Lookup Table Admin

Moderate

0%

0%

(Date)

(Date)

(Date)

adminzips.html

GUI-8

User Admin

Moderate

0%

0%

(Date)

(Date)

(Date)

useradmin.html

GUI-9

Report Builder

Hard

0%

0%

(Date)

(Date)

reportbuilder.html

WEEKLY PROGRESS Meeting:

· (Project Manager) follows this task list and explains: “This is what the schedule looks like and this is where we are”

· (Front End Developer) takes HLD mockups and builds LLD Proof of Concepts via a Template

NOTE: We utilized a template for Proof of Concepts (POCs) so please understand when developed there may be some slight variations. We also reserve the right to use the POCs as Mockups.

DOCUMENT: High Level Project Plan (HLPP/HLD)

This document is the High Level Project Plan (HLPP) which lays out the High Level Design (HLD)

pROJECT nAME

() – (Project Owner)

Revision History

Business Analysts

Date


Version

Initial

Creation of LLD

Nomenclature

aCRONYMs

dESCRIPTION

LOB

SOR

SCHEMA

BCP

HIGENE

MALFORMED

STALE

Line of Business

System of Record







1.1 – Project Overview/Objective


1. LOB Interfacing

2. Security

3. Back End Data Stores

4. Front End Interfaces

5. Business Rules

6. Data Transmission / Integration

7. Data Retention

8. Backups

Groups Affected

Products Affected

Programs Affected

cOUNTRIES aFFECTED

Target Users

Systems Touched


BRD Req#

HLD Task


GUI-1



GUI-2




BRD RULE#

HLD Rule

Description

RULE-1



1.5 – Capacity Plan

EX: Determine hardware needs / scalability based on project requirements / needs analysis

SUPPORTING DOCUMENTS


2.0 – System overview / Artifacts

2.1 – Impacted Systems

This table summarizes the systems/areas impacted by this initiative and serves as an overview of the actions they need to perform for this initiative.

System Name

Description

Email Server

Automated emails are sent via SMTP on the Email Server. Additional load is acceptable.

2.2 – Systems Removed From Scope

The following systems/areas have participated in HLD meetings and have determined they have no impact (development or testing requirements) for this initiative.

System Name

Description

2.3 – Master Schedule (Attach to HLD)

Description

Author: (TDM)

This document highlights the principal activities and tasks and their estimated duration. It is an early communication tool for early buy-in with upper level management and external stakeholders. The schedule is also useful for facilitating team brainstorming during the initial phrases of the project to work out logistics.

2.4 – Chart (Attach to HLD)

Description

BRD Req#: GUI-1 - Process / Data Flow Diagram (Model): (Click image to view)

Author: (Project Manager)

1) Workflow

2) Integrated Systems

3) Data Processing

2.5 – Mockup (Attach to HLD)

Description

Author: (Visual Designer)

GUI-1:

Basic Layout: (Click image to view)

1) Standard Header

2) Standard Footer

3) 80% wide body area

4) Gallery containers

3.0 – Design Assumptions & Constraints

3.1 – Design Assumptions & constraints

HLD Req#

Assumption

Description

Confirmed By

Confirmed Date

GUI-1

Web Server must be operational

IT to implement server and Help Desk to support

DB-1

Database will always be operational


3.2 – Key Decisions

Decision & System

Confirmed By

Confirmed Date

Web Server will be Microsoft IIS (latest version)

3.3 – Key Risks

Failure Mode

Description & Systems

Failure Effect

Mitigation

HIGH

Browser works incorrectly from a support patch

Loss of Productivity

Rollback Patch

3.4 – Key Issues

Issue

Resolution Action

Resolved By

Date Resolved

4.0 – System Summary

4.1 – Design RequireMents

BRD Req#

Type (GUI/DB/RPT)

Requirement

GUI-1

4.2 – Use Cases

BRD Req#

Use Case

Complexity

Priority

GUI-1

4.3 – User Interface Screens / Pages (Site Map) – SEE Artifact: Execution Plan - HLD Mockups & LLD Proof of Concepts

BRD Req#

Screen Name

Field Name

Datatype

Validations

Link

Help Text

GUI-1

Index.aspx

POC: 3.3.1

POC: 3.3.1

4.4 – Reports

BRD Req#

Report name

Description

Frequency

Delivery

RPT-1

User Permissions

List of Permissions by User ID

Ad Hoc

Screen

Business Analyst

(Business Analyst)




(Project Manager)

Front ENd Architecture Signature

(Front End Architect)

Back ENd Architecture Signature

(Back End Architect)

JAD Low Level Design (LLD) Meeting



Type of meeting

Create Acceptance Tests / Re-Affirm Time Estimates

Bridge Line


Required Attendees




Agenda


Business Requirements Document (BRD) & High Level Project Plan (HLPP/HLD)

(Project Manager) is the moderator with TDM present.

The purpose of this meeting is to create the Low Level Design (LLD) with the Business Requirements (BRD) & HLD as our source in estimating all aspects of the development. No code is to be written before this meeting unless approved.


2. Utilize HLD Use Cases to create LLD Acceptance Testing tasks (1 to many)

3. Talk through all Front End and Back End steps for each milestone for time estimates

4. to develop ERD (Entity Relationship Diagram) Model for Schema

5. Determine LLD Due Date

6. Determine the projects “Go Live” date that our LLD will stay within


Date

Discussions

Conclusions


Initial


2. Follow HLPP/HLD

3. Talk through milestones

4. Create LLD Acceptance Tests

5. Re-Evaluate Go Live date

6. Discuss when DEV Hardware will be operational (See action items)


DOCUMENT CREATION

1. LLD Due Date:

2. Targeted Completion:

3. Estimated Go Live:

4. (Technology Delivery Manager) is to create the LLD from this meeting

· to develop ERD Diagram for Schema

· BA: Modifies BRD if needed & updates repository folder

· PM: Create LLD Acceptance Testing tasks with &

· PM: Insert LLD into repository

folder for review

· PM: Schedules LLD Signoff Meeting

· HOLD PATTERN until LLD Signoff

· PM: Schedules JAD Pre-Development to Design Meeting

· TDM: Ensures DEV Hardware/Software is installed

DOCUMENT: Low Level Design (LLD)

This document is the Low Level Design which drives out HLD as LLD subtasks

pROJECT nAME

() - (Project Owner)

Revision History

Business Analysts

Date


Version

Initial

Creation of LLD

Nomenclature

aCRONYMs

dESCRIPTION

LOB

SOR

SCHEMA

BCP

HIGENE

MALFORMED

STALE

Line of Business

System of Record







1.1 – Project Overview/Objective


1. LOB Interfacing (HLD Repetitive)

2. Security (HLD Repetitive)

3. Back End Data Stores (HLD Repetitive)

4. Front End Interfaces (HLD Repetitive)

5. Business Rules

6. Data Transmission / Integration

7. Data Retention

8. Backups

Groups Affected

Products Affected

Programs Affected

cOUNTRIES aFFECTED

Target Users

Systems Touched


HLD Req#

LLD Task


GUI-1



GUI-2




HLD RULE#

LLD Rule

Description

RULE-1



1.5 – Capacity Plan

EX: Determine hardware needs / scalability based on project requirements / needs analysis

SUPPORTING DOCUMENTS


2.0 – System overview / Artifacts

2.1 – Impacted Systems

This table summarizes the systems/areas impacted by this initiative and serves as an overview of the actions they need to perform for this initiative.

System Name

Description

Email Server

Automated emails are sent via SMTP on the Email Server. Additional load is acceptable.

2.2 – Systems Removed From Scope

The following systems/areas have participated in HLD meetings and have determined they have no impact (development or testing requirements) for this initiative.

System Name

Description

2.3 - POC’s (Attach to LLD)

Description

HLD Req#: GUI-1 - Visual Components (Click image to view)

Author: (Front End Developer)

1. Navigation Menu (top / right / footer columns)

2. Calendar / Quick Links / Folder Links (right)

3. Blog (body)

2.4 - Chart (Attach to LLD)

Description

HLD Req#: GUI-2 - SiteMap: (Click image to view)

Author: (Back End Developer)

Database Name:

1) Homepage

2) Top Level Navigation

3) Sub Navigation / Tabs

4) Security Levels Box

2.5 – Reports

HLD Req#

Report name

Description

Frequency

Delivery

RPT-1

User Permissions

List of Permissions by User ID

Ad Hoc

Screen

3.0 – Design Assumptions & Constraints

3.1 – Design Assumptions & constraints

HLD Req#

Assumption

Description

Confirmed By

Confirmed Date

GUI-1

Web Server must be operational


4.0 – Architecture / Artifacts

4.1 – Deployment View Description

Describes the breakdown of the proposed architecture solution and maps the business requirements.

Ex: Windows Web Server to house web site and Web Services, SQL Server to house back end Database, Core database is populated via data feeds

4.2 - Schema

Table Name

Field

DataType

Size

Default

Description

Validations

4.2.1 - Diagram (Attach to LLD)

Description

HLD Req#: DB-1 - Schema Relationship Diagram: (Click image to view)


Database Name:

Supporting Docs: Table Definitions / Foreign Keys / Procedures / Indexes

4.3 – Components / Third Party Tools

component

Description

Radionale

None

4.3.1 - Diagram (Attach to LLD)

Description

HLD Req#: GUI-1 - Class Diagrams: (Click image to view)


5.0 – System Interfaces

System Name

Description

None

Front ENd Architecture Signature

(Front End Architect)

Back ENd Architecture Signature

(Back End Architect)




(Project Manager)

JAD Pre-Development Design Meeting

Initial Date: [ Meeting Scheduled For ] – [ Room Location ]


Type of meeting

Design Deliverables / Marching Orders

Bridge Line


Required Attendees





Agenda


The purpose of the Technical Design meeting is to discuss design deliverable assignment.

(Front End Architect), (Back End Architect) leads the Design section of meeting. No code is to be written before this meeting unless approved.


2. Accept marching orders (Go Code)

Technical Overview

MINUTES: Meeting NOTES / subsequent Meeting Notes (Agile Iteration Release Changes)

Date

Discussions

Conclusions


Initial


2. Overview of goals/roles (SEE: BRD)

3. Report to your PM

4. Work with your Architect

5. Architect or Lead Developer takes over meeting

a. Process Flows (Front End)

b. Component Interface Sheets (Back End)

c. Review content localization

d. Are we modifying code?

e. Are we creating new code?

f. Repository of code usage

g. Validations identification

h. Coding Rules

i. Code Reviews

j. Code Repository

k. Stress Test Procedures

l. (Proves our Capacity Plan)


IDENTIFY RESPONSIBILITIES:

1. Component Interface Sheets - Assigned to: (Back End Developer)

2. Process Flow - Assigned to: (Front End Developer)

3. Content localization understood

4. Developers can start checking out code

5. JAD WORKSHEET (Next Page): verifies design steps

· BA: Modifies BRD if needed & updates repository folder

· PM: Works HLD/LLD modifications if BRD was & updates the repository

folder for review

· (Front End Developer) to create Process Flow Charts

· (Back End Developer) to create Component Interface Sheets

· (Back End Developer) to ensure performance tuning on database/hardware

· (Back End Developer) ensures BIGIP load balancing is utilized (large web sites)

· (Technology Delivery Manager) to email (Content Manager) CM Form with attachments (BRD, HLD, mockups, charts)

Phase 4 – Develop / Construction / Build



Type of meeting

Improve / Development (Code)

Bridge Line


REQUIRED Attendees

(Project Manager)


OPTIONAL Attendees

(Technology Delivery Manager), (Business Analyst)

Agenda

(Project Manager) is the moderator.

Formalized development process commences by which coding standards, developer testing, code review and deployment script disciplines are defined.


2. Follow Coding Procedures (Ask if you need mentoring)

3. Developer Testing (Test on your own)

4. Code Review (Try to keep excessive iterations of changes to a minimum)

5. Deployment Scripts (Ask if you need help on scripting your tests)

6. Take note of any Company Code Freeze dates that may impact development

7. Keep in mind any Integrate Testing with other systems

Development Procedures Overview


Date

Discussions

Conclusions


Initial


2. Overview of roles (See: BRD)

3. Report to PM

4. Use Architect / Lead if needed

5. Back End to hand off Component Interface Sheets to Front End

6. Front End to use Visual Designer for graphics as needed

7. Is there a Content Localization Form in route for signatures?

8. Checkout code (if any)

9. Backup Code reminder

10. Hide Confidential Documents



1. (Back End Developer) gives Component Interface Sheets to

(Front End Developer)

2. (Back End Developer) creates development script as they go

3. (Back End Developer) works on Stress Test Plan (See: Capacity Plan)

4. (Front End Developer) to utilize Component Interface Sheets

5. Developers to report Holdups / Critical issues to PM

· PM: Capture Progress (next page)

· PM: Schedules Milestones Meeting

· PM: Schedules Projector

Progress Notes: Front End Development

Activities


1. Front End developer to design GUI

2. Front End developer assists (Project Manager) to understand design and HLD mockups / LLD Proof of Concepts

3. Work through HLD Use Cases / LLD Acceptance Testing / Unit Testing (Unit Test Script)

4. Work through code review, code integration testing

5. Coding Practices:

a. Address any hard coding (There will be NONE)

b. Determine method names for back end calling components, methods, scripts etc.

c. Review Third Party tools (if any)

Action items (Agile Development Changes)

Assigned To

Target Date

Closed Date

· Meeting for MM/DD/YY –

REQ#

HLD Use Cases (For Test Plan)

LLD Acceptance Tests (For Test Plan)

Unit Testing (For Test Plan)

GUI-1

1. Use Case

1. Acceptance Test

1. Unit Test

Progress Notes: Back End Development

Activities


1. Back End developer to design Databases, Tables, Indexes, Stored Procedures, Scripts etc.


3. Work through code review, code integration testing

4. Understand basics of how front end calls your components, methods, scripts etc.

5. Coding Practices:

a. Address any hard coding (There will be NONE)

b. Determine templates to uses

c. Review Third Party tools (if any)


Assigned To

Target Date

Closed Date


REQ#

HLD Use Cases (For Test Plan)

LLD Acceptance Tests (For Test Plan )

Unit Testing (For Test Plan)

GUI-1

1. Use Case

1. Acceptance Test

1. Unit Test

Progress Notes: Reports Development

Activities


1. Front End developer to develop reports in the dictated reporting tool


3. Work through code review, code integration

4. Work through integration testing


Assigned To

Target Date

Closed Date


DOCUMENT: Test Plan (Test & Production)

This document contains test cases which are to be executed in priority order with Execution Plan as the baseline.

Project Name

()

Purpose

The purpose of this document is to monitor deployment to TEST as well as deployment to PROD.

Test Case StatuS (Ordered by Priority)

REQ#

Project/Sitemap Task

Rating

Build

Test Status

TEST Checked

PROD Checked

What to Test

Comment

Issues/ImpacT

Resolution

GUI-1

SSO – Single Sign On

& Logout

Easy

1.0

100%

(Date)

(Date)

1. Test good login

2. Test bad login

Standard Component

1. Tested Successful

GUI-2

Welcome/Introduction

Easy

1.0

0%

1. SEE: General Tests

Master Page

1. WIP

GUI-3

Standard Layout

Easy

1.0

0%


GUI-4

Sitemap

Easy

1.0

0%


GUI-5

Screen 1

Easy

1.0

0%


RPT-1

Report 1

Easy

1.0

0%


GUI-6

Menu Builder

Moderate

1.0

0%


GUI-7

Lookup Table Admin

Moderate

1.0

0%


GUI-8

User Admin

Moderate

1.0

0%


GUI-9

Report Builder

Hard

1.0

0%


GENERAL TESTS

1. Latency Testing: Page must load within 7 seconds/ Page does NOT hang

2. Functionality Testing: Navigation / Input

3. Functionality Testing: Database Functionality

a. Test any ON-Screen CRUD functionality

b. If no ON-Screen CRUD functionality exists modify test data in the database manually to ensure the database driven functionality works

c. Ensure correct data is being displayed correctly

4. Content Testing:

a. Content should stay within defined height/width locations

b. Content should NOT have font or color issues making it hard to read content

c. Test across standard browsers (Ex: IE6, IE7, IE8, IE9, Firefox)

5. Security Testing:

a. For the permissions is the functionality and content correct?

b. Test all permissions for the page ensuring the user sees the content/data they have privileges to see

6. GUI Testing:

a. User should NOT have to scroll horizontally the page content

b. Content should not overlap/overlay other content

c. Content should be aligned/spanned aesthetically

d. Page should consistently match other site pages in look and feel standards

1. Consistent Layout / Navigation / Header / Footer

2. Consistent Font / Consistent Color

7. Misc testing: Are there any features that do not work?

a. Test every control, every submit/cancel button

b. Test to ensure page functionality is operating correctly including links

c. Test Tab (tab index numbering)

Milestones Meeting (Progress Report)

Initial Date: [ Meeting Scheduled For ] – [ Room Location ]


Type of meeting

Milestones Scripted Walkthrough MeetingS

MEETING PREP

Test that you know how to utilize Live Meeting or optionally schedule a projector.

Bridge Line


Required Attendees


(Project Manager), (Test Representative)


Optional Attendees

(Business Analyst), (Content Manager)

Agenda

(Technology Delivery Manager) is the moderator utilizing a projector.

The purpose of this meeting is to hear milestone schedules and script our walk-through. (Project Owner) is to develop an understanding of how we are going to accomplish project requirements.


2. (Technology Delivery Manager) utilizes LIVE MEETING for walkthrough

3. works with (Content Manager)

4. Review Developer Responsibilities (Code Review Status / Content Status / Translation Status)

5. Review LLD Acceptance Testing (Only if we’re proceeding to Testing)

Milestones Pre-Test Overview


Date

Discussions

Conclusions


Initial


2. TDM asks to be guided through the product

3. Owner comments on the work already performed

4. Are there any questions?


MILESTONE SCHEDULE

(Technology Delivery Manager) asks if there are milestones NOT on schedule (If not why?)

NOT ON SCHEDULE

1.

ON SCHEDULE

1.

· PM: Schedules Pre-Deployment to Test

· TDM: Ensures PROD Hardware/Software is installed



Phase 5 – Testing & Quality Assurance



Type of meeting

Improve / Verification (Pre-Deployment to Test)

Bridge Line


Required Attendees

(Project Owner), (Business Analyst)

(Project Manager)


(Test Representative)

Optional Attendees


(Content Manager)

Agenda


The purpose of this meeting is to discuss our pre-deployment to test plan.


2. Deployment date confirmed (Are we on schedule to start System Integration Testing then set to deploy to Test??)

3. If ready to deploy: Developers to execute their individual unit test after the deployment

4. If ready to deploy: Everyone should be attentive to anything that can hold up the TEST QUEUE.

5. If ready to deploy: Review Rollback Procedures


Date

Readiness Assessment

Conclusions


Initial


2. Are there any outstanding items?

3. Are we ready to deploy?

4. Is hardware & environment ready to support the transactions?

5. Are we capable of monitoring and reporting on key metrics?

6. Are Facilities ready?

7. Do we have integrated testing?

8. What is our schedule?


scheduleD Testing

Start

End

System Integrated Testing

TEST Architect prep time

Date

Time

Date

Time

TEST Deployment

Date

Time

Date

Time


1. All Facilities, Hardware, Network, Staff are ready

Contingency Plan - (Anticipating the unforeseen)

1. Item

Risk Mitigation - (Strategies to managing risk)

1. Item

· PM: Start Integration Testing

· PM: Supply LLD Acceptance Tests to (Test Representative)

· & - Deploys scripts (if any)

· PM: Schedules Test Results Meeting

· TDM: Notifies everyone the deployment schedule

Test Plan: Unit Tests / System Tests (To be utilized for Deployment to Test & Production)

Utilize Test Plan Document



Testing Results & Signoff Meeting



Type of meeting

Post Staging (UAT) Testing

Bridge Line


Required

Attendees


(Project Manager)

(Front End Architect), (Back End Architect),



Optional

Attendees


(Content Manager)

Agenda

(Project Manager) is the moderator.

This meeting is to discuss what was uncovered by the Front End/Back End/Developers & Architects.

Modify test plan if needed (Did we learn anything that will help us in the Production Tests?)


Formal Testing Issues

PROBLEM IDENTIFICATION (Systemic etc.)

1.

Acceptance Testing Issues


1.

MINUTES: Meeting NOTES / Subsequent Meeting notes (Agile Iteration Release Changes)

Date

Discussions

Conclusions


Initial


2. Evaluate UAT Testing

3. Do we need to roll back or is everything 100% to proceed with the signoff


1. Item

2. Item

· Create: Testing Document (Front End & Back End) for (Test Representative)

a. Show Present Functionality

b. Show Changes Performed

c. Show Experimental Testing

· HOLD PATTERN - Testing Signoff

· PM: Schedules Pre-Deployment to Production Meeting

Testing Signature



(Project Manager)



Phase 6 – Deploy / Implementation Phase



Type of meeting

Improve & Control / Verification (Pre-Deployment to Production)

Bridge Line


Required Attendees

(Project Owner), (Test Representative)




Optional Attendees


(Content Manager)

Stated Agenda


The purpose of this meeting is to discuss our pre-deployment to production/live plan.


2. Deployment date confirmed (Are we on schedule to deploy to Production??)

3. If ready to deploy: PM is to perform Staff notification, Field, Business Partner, Owner notification / Training

4. If ready to deploy: PM is to perform Review Impact on Services and Systems, Rollback Procedures

6. If ready to deploy: Review Rollback Procedures

MINUTES: Meeting NOTES / Subsequent Meeting notes (Agile Iteration Release Changes)

Date

Discussions

Conclusions


Initial


2. Are there any outstanding items?

3. Are we ready to deploy?

4. Is hardware & environment ready to support the transactions?

5. Are we capable of monitoring and reporting on key metrics?

6. Are Facilities ready?

7. What is our schedule?


scheduleD Testing

Start

End

PROD Architect prep time

Date

Time

Date

Time

PROD Deployment


1. All Facilities, Hardware, Network, Staff are ready

Contingency Plan - (Anticipating the unforeseen)

1. Item

Risk Mitigation - (Strategies to managing risk)

1. Item

· PM: Supply Test Plan to (Test Representative)

· - Deploys scripts (if any)

· - Deploys scripts (if any)

· PM: Schedules Post Production Testing for Signoff

· TDM: Notifies everyone the deployment schedule

Test Plan: Unit Tests / System Tests (To be utilized for Deployment to Test & Production)

Utilize Test Plan Document



Production Testing Results & Signoff



Type of meeting

Post Production (PROD) Testing

Bridge Line


required Attendees


(Technology Delivery Manager), (Project Manager)

(Front End Architect), (Back End Architect),


(Test Representative), (Content Manager)

Optional Attendees

(Content Manager)

Background Activities

IMPORTANT: Developers need to be attentive knowing this project is NOT the only on in the TESTING QUEUE and that any failures could hold up other non-related projects.

is to inform (Project Owner) of status.

(Testing Manager) is to signoff after successful testing

Formal Testing Issues


1.

Acceptance Testing Issues


1.

MINUTES: Subsequent Meeting NOTES Meeting NOTES / Subsequent Meeting notes

Date

Discussions

Conclusions


Initial


2. Evaluate PROD Testing

3. Do we need to roll back?


1. Item

2. Item

· HOLD PATTERN until Production Testing Signoff

· TDM: Add Application to Enterprise Disaster Recovery List

· PM: Delegate Documentation

· PM: Train Customer

Lessons Learned

· Testing missed some areas that were impacted by our coding

· We need a repository of code to cut down on development times

Testing Signature

(Testing Manager)

Owner Signature (OPTIONAL)

(Project Owner)


(Project Manager)



Phase 7 – Support

Support Meetings / Modifications

Date

Discussions

Conclusions


Initial

1. Item

2. Item

1. Item

2. Item

· Action Item # 1

Modification History

Date

Ticket / Defect #

Modification

Requestor

Tested

Implemented

Initial

DEF-1

1. Item

2. Item

(Date)

(Date)

Support Lessons Learned

1. Do NOT hire anyone with command of the English language issues

2. Do NOT keep anyone who doesn’t grasp the project

3. We do NOT run an adult daycare so everyone should pull their own weight and ask questions if they need help

HAPPY PATH

Use Time Wisely

Combine Like Tasks

Monitor Tasks

Alert On Issues

On Time Delivery

Owner/Customer is included ONLY when sufficient progress is shown.

HAPPY PATH

Use Time Wisely

Combine Like Tasks

Monitor Tasks

Alert On Issues

On Time Delivery


HAPPY PATH

Use Time Wisely

Combine Like Tasks

Monitor Tasks

Alert On Issues

On Time Delivery


PAGE

Avoli.com IS-S.2.2 (Last revised: 2/14/11) PERFORMED AT THE DIRECTION OF COUNSEL ATTORNEY-CLIENT COMMUNICATION ATTORNEY WORK PRODUCT

Page 1 of 41

avoli.comavoli.com/assets/docs/sdlc.doc · Web view(Six Sigma DMAIC & DFSS IDDOV) (Failure is NOT...

Documents

Transcript of avoli.comavoli.com/assets/docs/sdlc.doc · Web view(Six Sigma DMAIC & DFSS IDDOV) (Failure is NOT...