Iso Folder Work Flow

ISO WORKFLOW

I hope this document make you understand a little on the work flow. Please bear the spellings and grammatical errors below.

NOTE: This Document will have the detailed description about the ISO work flow of the project from its start phase to till its End. Here it follows,

As I have mentioned “ISO MAIN FOLDER STRUCTURE.doc” under Project folder there are three subfolders Code, Documents and Third party controls. Here is the Explanation for the three Subfolders in details.

DOCUMENT FOLDER STRUCTURE

1. WORK SIGNED ORDER:  The WORK SIGNED ORDER FORM is first and foremost step to follow in ISO.

 In the Work Order form, Internal Management people either the PM or TL should fill the form with following details such as, Scope of the Work, Location of work and resources, Period of Performance, Deliverables Schedule, Applicable Standards, Acceptance Criteria, Special / Technical Requirements.

 This form has to send to the Client End and if they satisfied with the condition mentioned then they will sign the contract. (Or in the call they will discuss the possibilities and based on that they will act on that).

 The form should be a Hardcopy and softcopy should be in the repository.

BY ARTHIEVISWA

Page 1

ISO WORKFLOW

2. KICK-OFF MEETING:  Once the Work Order is signed then we will proceed with the Kick-off Meeting. For this meeting we should prepare the checklist called Project Kick-off Meeting Checklist.  This Checklist will contain question such as, Name of the project, Project Code for the project, Project Client Name, No of Resources for the project, Designation for the team member, TL, PM for the Project, Software to be used, and Hardware Used, etc.

 This Checklist should not be changed. And also this is not for entire project. If you want to split the project into phase, for each phase this will be the flow. And also we can have one Kick-off checklist for the project. This all depends on the Organization.

3. TEAM MEMBER LIST:  Once the Meeting is done then update the Kickoff checklist in the central repository and prepare the Team Member List for the Project. In that list it should have, Name, Designation, Resource start date, Resource End date, Resource Released by, Training Undergone, Reason for Training, and Effectiveness on Training.

4. RISK ASSESSMENT AND IDENTIFICATION PLAN:  Then need prepare the Risk that will happen for the project. So there is document called Risk Assessment and Identification form. This Risk identification and Assessment should happen for each release and to be clear this should happen when ever we start a new phase or new release.

 Risk Identification will have Area of Risk such as Development Team Related, Project Attributes, Business Problem Attributes, User Attributes, and Any

BY ARTHIEVISWA

Page 2

ISO WORKFLOW other Related Risk encountered. So the each phase it has the Risk Impact which will have High (8), Medium (4), Low (2).

 Risk Assessment will have Type of Risk, Probability, Impact, Weightage, and Mitigation Plan.

 In Probability we have three terms such as, Remote (0.1to 0.2- Definition: Unlikely though convincible), Occasional0.3to0.4- Definition: Could Occur sometime), Probable (0.5to0.7- Definition: An event to be expected), Frequent (0.8to0.9- Definition: a Very chance of occurrence).

 Impact will be taken from the Risk Identification form.

 Weightage will be calculated by the calculation Probability*Impact. NOTE: If the Weightage is >=1 then there should be Mitigation Plan.

 This has to be reviewed by TL or PM.

5. PROJECT MANAGEMENT PLAN:  This is a highly important document for the ongoing project. In Short we will call this document as PMP. In this document will have, Definition, acronyms if any, References (documents given by the client requirement document), Change History,

 Note: Change History, I need to explain this clearly. This is really important to keep track of the changes that happen to this document. Not only to this Project Test Plan, System Specification Document. Here it will have the Date, Document version number, Change Description, Reason for Change, Time spent in hours. Whenever you are preparing at first the Document version will be 0.1, Change description will be Initial Draft by name (whom have prepared the document first). Once the preparation is over PMP has to be reviewed. So after review the Document version number is changed to 1.0 and change Description will be Initial PMP or

BY ARTHIEVISWA

Page 3

ISO WORKFLOW Document by name (whom did the review changes, note the name of the person who did changes after the PMP was reviewed).

 Introduction: Scope, Development Plan: Project Life cycle, Development Phase, Schedule, Project Organization Chart, Assumption and Dependencies, Resource Management: Hardware, Software, Human Resources, External Requirements, Training Requirements, Project Management: Project Tracking, Status Reporting, Teleconferencing, Escalation Process, Document and Records Maintenance, Backup and Restoration. Risk Management: Risk Identification, Risk Assessment, Quality Plan: Acceptance Criteria, Test Strategies, Reviews and Audits, Tools and Techniques, Standards and Practices, Metrics plan, Configuration Management Plan: Configuration Area and Directory Structure, Configurable items: Deliverables, NonDeliverables, Hardware/Software, Customer Supplied items, Change Control, Configuration Audit, Implementation Support, Customer Feedback, Project Closure.

 The Document will have the workflow that we are currently following. For example, Under Quality plan we have Testing Strategies, we have mention in PMP say that Functional testing and its description, Adhoc testing and its description. So here we are just informing the outsiders or the ISO Auditors that is the methods we are following in testing. This is applicable for all.

 The Review has to done before we start of the development by TL or PM and there is one more document for review as PMP Review Checklist.

6. PROJECT TEST PLAN:  This Document is mainly for the Testing Team and the method that we follow in testing. This Document short form as PTP.

 Note: You can ask why already we have given the entire details in PMP and why again same information in PTP? The answer is you would have heard about the SDLC and STLC phase right? The same cycle we are using here, as a tester we should follow the STLC cycle.

BY ARTHIEVISWA

Page 4

ISO WORKFLOW  The Content in PTP is, Definition, acronyms if any, References (documents given by the client requirement document), Change History, Introduction, Scope, Test Strategies, Performance Criteria, Test Environment: Hardware, Software, Risk Assessment and Identification, Roles and Responsibilities, Human Resource Requirements: Human Resource, Test Schedule, Test Tool Used, Acceptance Criteria, Test case Storage Area, Test Data.

 The PTP will contain the information on Testing and the Members in Testing Team.

 PTP has to be reviewed before we start of the development phase by Testing TL or PM and one more document for review is PTP Review Checklist.

7. PROJECT MILESTONE:  Project Milestone is the basic plan for every Release. This document will have Schedule time, Deliverables (High Level) and also make a table and explain the deliverables for that Release and the estimation hours for the milestone.  Milestone can be prepared by a separate document or we can include this in the PMP directly under schedule.

8. SOFTWARE REQURIMENT SPECIFICATION:  This Document will have all the client requirements. Simpler way we can say that we are clubbing all the client requirements into a single document called Software Requirement Specification Document. This document is in short called as SRS document.  This has Definition, Acronyms and abbreviation, Reference, Change History, Introduction: Scope, Product Perspective: User Characteristics, General Constraints, Assumption and Dependencies, Risks, Requirement Architecture, Requirement List: Module 1, Module 2, to Module n, External Interface Requirements: Hardware Requirements, Software Requirements, Communication Interface, User Interfaces, Performance BY ARTHIEVISWA

Page 5

ISO WORKFLOW Requirements, Special Characteristics, Help, Other Requirements: Site Adaptation Requirements, Safety Requirements, Packaging, Traceability Matrix.  The Review has to be done for this document before we start up the development phase. For review there is one more document as SRS Review Checklist.  Important, if we are really in need the entire client requirement into a single document we can go for SRS. Or we can have the same client requirements and do the review for those documents as RS (Requirement Specification) review checklist. If it is RS document then whenever we receive a requirement from client we need to do the Review for it.  Hmm, I understand what is running in your mind now, suppose if we have problem with the document or something that has to be added or to be changed in that. Ok we have added or changed how to be intimate that to client, Is that we have to follow any process for that? Yes, suppose if we have any changes in the document, we have Change Request Form, in this form we need to fill all the additional changes and have to send it to client for approval. Then we will have the discussion on that and finally we will come up with the final requirements.

9. REQUIREMENT TRACABLITY MATRIX:  This Document is very important for the process. It’s really useful in tracing the requirement and along with that also useful for finding if there any test case to those particular requirements.  In short we call this document as RTM which has, Requirements Document, Path to the Document, Test Case Document, To be released in, Released in, Status, Comments.  Status: Which is a dropdown and has the list of Partial Requirement, Partial Test Case, Completed, No test Case Needed.

10. STATUS REPORT:  Status is mandatory that at the end of the week both the Development Team and Testing Team needs to update the work list that they have done in that week.

BY ARTHIEVISWA

Page 6

ISO WORKFLOW  TL of each team has to send this to TL or PM and they need to review will send it back to client.  To be noticed we have Status Report form or we can use Mail for those even.

11. MINUTES OF MEETING:  This will be done only when we have Conference call or on – call with client. Whatever Client or we discuss that has to be taken done by the recorder (person who take down the important points on the call).  This in short we will call as MOM. There is separate form for this to fill in which it has, Team attended the meeting, Topics discusses, Learning. Note: In Review checklist we classify the mistakes into Major and Minor. “From 1 to 11 are the important things that have to happen if we started with the New project or New phase or New Release.”

DEVELOPMENT WORK:  For Development Team first they will get the Database Table that has to be updated in Documents-> Design folder.  Organization rule is that the project should have at least two Code Review per week. It is process that one developer has to review the code done by another developer. It is to check whether we follow the coding guidelines by our Organization or client side. TESTING WORK:  First we need to start with the Test Scenario once we get the specification. Test Scenario will have, Test Scenario Steps, Test data, Status.  Test Scenario will have the all kind of events. For Example, Take if we need to go Jammu and Kashmir A to Kanyakumari B. There will be so many routes from A to B. That follow is called as Test Scenario.  Once we done with the Test Scenario, TL of Testing Team have to Review the Test Scenario. That review document named it as Test Scenario Review Checklist.  Next is Test Case, Test case will have Test Case Description, Test data, Expected Result, Actual Result, Status and Remarks.

BY ARTHIEVISWA

Page 7

ISO WORKFLOW  Once we done with the Test Case, TL of Testing Team have to Review the Test case. That review document named it as Test Case Review Checklist.  If we need to write Positive, negative Test case follows the same template in different sheet or we can write both in the same test case.  Next is Manual Test Script, This will have Test Script Description, Status, and Remarks. This will be the sanity/End to End test case where will cover only the mail functionality and the work flow of the project.  Once we done with the Test Script, TL of Testing Team have to Review the Test Script. That review document named it as Test Script Review Checklist.

Before releasing the project, we need to two steps, they are, RELEASE COMMITTEE MEETING:  This meeting will happen a week prior to the release. 

This formal meeting in which we discuss about the deliverables and will it been delay or can deploy the build on time, what all the external devices used. This has to be maintained in a separate sheet named, Release Committee meeting checklist.

CONFIGURATION AUDIT:  After Release Committee meeting we will go for Configuration Audit. This audit will happen a week prior to the release.  This is the audit which has to done by Configuration Controller of another project. There will be some set of question to check whether the configuration items are stable enough before delivering the build.

At the time of Release, RELEASE NOTE:  During the deployment, Release Notes has to be prepared. This will have the Modules in the project, Bug fixes, unresolved bugs, Future Enhancements.  This Release Notes has to be mailed to Client at the time of deployment.

BY ARTHIEVISWA

Page 8

ISO WORKFLOW Two days after Deployment, PHASE REVIEW MEETING:  This meeting will have all the team members and will be discussing about the current status of the release, deliverables, any new risk, steps to overcome the risk, deliverables for the next release and date for the next release, Learning and lesson learnt from the previous release.

PROJECT MATRIX:  In this matrix we will calculate the Schedule variance, Effort variance, Testing Efficiency, Review Variance.  In this matrix we will calculate percentage of the particular phase or release.  Schedule variance is calculated by the total number of days. ie. Start date to End date of the particular phase or release.  Effort Variance is calculated by the total number of timing. ie. Start date (9 hours of work) to end date (9 hours of work of the particular phase or release  Testing Efficiency is calculated by the Total number of defects by our side/[customer defects+ Total number of Defects by our side]/100. COMMON THING INSIDE PROJECT:  If the team member is moving out of the office or to other project they need to fill the Activity Handover form, in which the team member who will be moving out has to fill the pending tasks and the name of the member he handing over to(to some person in the same project). In short we will call this as RCA.  The organization will have target, for example, if the organization is set the testing percentage as 80, but in one of the release we scored below that we need to fill the Root Cause analysis form. In that we have Problem, Correction, Root Cause analysis, Corrective action.  Problem: The actual problem.  Correction: What was your immediate action on that problem?  Root Cause Analysis: Why the problem had occurred.  Corrective action: What will be your procedure to never ever come this kind of problem or preventive action (for future use?) .

BY ARTHIEVISWA

Page 9

ISO WORKFLOW  After one month is RCA has to be reviewed by TL.  This form has to be filled when we are moving out of the ISO Process. We need to fill this form not only for Testing, if we fail do the review or schedule variance is low or if we didn’t meet up with the effort variance or if we got less percentage from customer feedback. CAR – Audit, I will explain this later, if we gone for ISO certification we need to be very careful on this. So I will explain this later. Finally, need to tell you about the “Closure Document” called as “Project Closure Report”. This document will be prepared at the end of the project.

CODE FOLDER STRUCTURE This Code folder is only for developers. DATABASE BACKUP: The project database has to store here. The database has to be updated in separate folder as per release date.

DEVELOPMENT: All the program code for each layer will be updated here.

OLD RELEASE: The old release folder will have all the “released” code or exe file into that in separate folder with the release date to that folder.

PRODUCTION: This folder will have the current version of the build. Once we started off with the new release, from that start time to end time whatever the build it will be in the production folder for testing.

BY ARTHIEVISWA

Page 10

ISO WORKFLOW UAT: During the time of deployment we will update the build into that folder. So that client QA can easily do the testing. And they will update the defects in that tracker.

--------------- -------------------“THE END AND YOUR BEGIN NOW “---------------------------

BY ARTHIEVISWA

Page 11