software development process

Project Management Review Procedure

Project Management Review Procedure

The purpose of the procedure is to define adequate mechanism for periodic and event driven Project Management Review (PMR). PMR helps in having project status data in a uniform format, which is to be used for analysis & finding trends in the project management cycle.

Plan for PMR

PM shall plan for PMR on monthly basis. The PMR shall be attended by :

AM, PM ,SQAG, Project Team (Mandatory) Global delivery Head ,Head BE , Support functions (Optional)

Prepare for PMR

PM shall prepare for PMR based on the below mentioned agenda : Review of action item from last PMR Project execution status w.r.t Project plan Review Relevant stakeholders involvement Review of D&Q Plan (Inclusive of sub plans) Monitoring the process/sub process performance in the project Review of High Priority risks & Issues Review of Causal Analysis corrective and preventive action Effectiveness/Assessment of process compliance Decision Analysis action items if any Status of DMAIC projects and process improvement activities Project VOC / Customer feedback Any other areas of Concern

The concerned SQAR will verify and approve the PMR Presentation followed by the AM Approval.

Conduct & Track PMR

The PM shall conduct PMR ( Refer PMR checklist CHK-31) The PM shall record the actions arising out of the PMR in the respective tracking sheet. AM, PM & SQAR tracks the action items till their closure.PM shall keep the PMR presentation in project central repository for future reference and usage.

Number of PMR action items identified Number of PMR action item open

Global Delivery Head Head Business Excellence Support Functions Account Managers Project Managers Project Team SQAG

PMR Action Items PMR Presentation

Periodic Reviews and Audits are conducted in order to ensure Process Compliance

Software Configuration Management Procedure

Software configuration management (SCM) is a project control procedure for management of software products in order to ensure product integrity and traceability throughout the projects life cycle.

Preparation of the SCM Plan PM shall prepare the SCM Plan ( Part of the D&Q plan)

PM shall identify the Software configuration control board (SCCB) consist of Configuration Controller (CC), PM, AM & Client (Optional)

Identify Configurable items

To maintain accountability, integrity, Visibility, traceability, reproducibility , PM shall identify the configurable item (C.Is) based on the following criteria :

Products that are delivered to the customer

Internal work products like SRS, SAD, HLD, Data flow diagrams, Test cases

Acquired products from the customer like tools, standards, templates, test data

Other items that are used in creating and describing these work products like records and reports

Process performance Model outputConfiguration Control

The CC shall provide the appropriate access rights to the team depending on the role of the team members

The CC shall review and ensure that the configuration of CIs is being controlled throughout project life cycle to maintain the integrity and correctness of CIs. All CIs shall be labeled & commented properly

CC shall maintain a log of changes and reasons for changes as appropriate. These details could be viewed through revision history of CIs using configuration tool

In case the code is being managed by both customer and Birlasoft, the team will maintain and baseline the code on which we are working as a back up and history

In case the team is working directly on client instance & Birlasoft team is restricted to keep copy of code then in that case project team will maintain and manage all other documents except code in configuration tool

Change Control

The changes in CIs are consequences of one of the following:

Requirement change request (RCR)

Problem report (PR)

Defects

All the RCR/PR are handled as per the change management procedure (BSL/PRO/10)

Configuration status accounting

Configuration status accounting is a means of recording, managing and reporting the changes to software items during the entire life cycle of the project.

CC shall prepare the below mentioned reports to maintain status accounting

Change request summary and status (Q252)

Problem report summary and status (Q252)

Results of software baseline audits

Configuration Audits

SQA Lead conducts SCM audit (Part of PHI template) PM conduct Baseline audit using Baseline audit Checklist.

Backup and Recovery The frequency for taking backups will be defined in the SCM plan in the DNQ plan usually as follows :

Daily Back up

Incremental Back Up

Full back of all CIs on deliveryReview & approval of SCM Plan SCM Plan shall be reviewed by :

PM (With similar domain experience)

Account Manager

SQAG

Customer (optional)

PM shall incorporate any modifications/changes evolved as a result of review and obtain approval from concerned AM.

Effort spent in SCM activities

NCs reported for SCM Audit.

Status of RCR/PR

Business Excellence Process Group (BEPG) SQAG Project Team Project Manager Account Manager Configuration Controller (CC)

Support Functions

Senior Management

Approved D & Q plan. Configuration item status accounting reports

SCM Audit Report


Risk Management Process

This Risk Management process defines the steps for risk identification & managing risks in a project.

This process details out steps for how to identify the risk, prioritizes the risk factors according to both the probability and the consequence of failure and develops a risk management plan to implement strategies to deal with those risks.

Risk Identification

PM Identifies the risks associated with cost, schedule, and performance in all appropriate life cycle phases in a project.

Typical risk identification methods include the following:

Examine each element in work breakdown structure

Interview subject matter experts and stakeholders

Review risk related to similar products available in Organization Project database (OPD)

Examine lessons-learned documents or databases

FMEA (Failure Mode Effect Analysis)

Taxonomy Based Risk Identification (Birlasoft/CHK/48)

Risk Sources & Categories

Following are some of the Risk Sources needs to be considered while identifying the risks associated with the project.

Estimates

Technology

Resource

Suppliers

Customer

Process

Requirements

Design

Coding

Testing

Categorize risk to provide a mechanism for organizing risks as well as ensuring appropriate scrutiny and management attention under following heads Schedules

Cost

Performance

Risk Parameters

Parameters for evaluating, categorizing, and prioritizing risks include the following :

Probability of occurrence (Scale 1,3,9 (Low, Medium, High))

Severity if risk takes place (Scale 1,3,9 (Low, Medium, High))

Detectability (Scale 9,3,1 (Low, Medium, High))

The risks identified are analyzed, categorized and prioritized based on the Risk Priority Number (RPN) and updated in D & Q Plan.

Risk Mitigation Plan

PM Prepares the risk mitigation & Contingency plan for a given risk which includes techniques and methods used to avoid, reduce, and control the probability of occurrence of the risk, the extent of damage incurred should the risk occur or both.

PM have options for handling risks typically include alternatives such as the following:

Risk avoidance: Changing or lowering requirements while still meeting the users needs

Risk control: Taking active steps to minimize risks

Risk transfer: Reallocating design requirements to lower the risks

Risk monitoring: Watching and periodically reevaluating the risk for changes to the assigned risk parameters

Risk acceptance: Acknowledgment of risk but not taking any action often, especially for high risks, more than one approach to handle risk is generated.

Review of Risks

PM shall review the risk management plan periodically to re-examine & update the existing risk mitigation and contingency plan (If required) Risk management strategy is reviewed with relevant stakeholders to promote commitment and understanding. Risk Management plan is reviewed in team & management reviews.

Threshold of Risks

PM shall identify the threshold limits for all identified risk in D&Q Plan.

The categories of risks for which the expected total RPN value is between Baseline and 2 X base line value is reviewed in PMR or in event driven meetings.

The categories of risks for which the total RPN value is above 2 X base line value shall be reviewed by Global Delivery Head.

Risk Priority Numbers (RPN) Risk identified at early stages No of planned Risk No. of actual Risk Effort spent on identification and analyzing of risks Effort spent on Risk management planning

Tower Head

Account Manager

Project Manager COE (Center of Excellence) Presales

Business Excellence

Support Functions

Sales

Pre Sales team

Global Delivery Head

Risk Management Plan


Sales Procedure

This procedure applies to the Sales team across all geographies.

Market Segmentation The sales team along with Pre-Sales would define the Market Segmentation for Geography to market using SWOT analysis.

Create tool kit for each of the service offerings.

Create brochures/presentations for domain/technology segmentation

Lead GenerationLead Generation would happen through the following :

Cold Calling

Campaigns

Events

Internet Events/Webinars

The lead information is entered in Siebel CRM OD workflow application(WINGS) by BRM

Direction Setting Call

Direction Setting Call begins from qualified lead getting into a mature stage of Opportunity. The pre-requisite for this call is where strategic or tactical direction is required. (Refer Direction Setting Call Procedure for details)

Closing process

The sales team would close the deal as per Approved OAP Guidelines as per Authorization manual from finance team.

Estimations received from pre-Sales are taken. No changes to estimates can be made by Sales

The deal details are updated in WINGS system.

Handshake with Delivery

Sales team will hand over the documents using Handover-Takeover Sales to Delivery Checklist with following details :

RFP

Proposal

Contract copy/MSA copy

Signed SOW

Deal Qualification Sheet

Account Management Plan

Account Management

Sales team will map the Customer account using Account Business Plan covering :

Organization Structure

Technology Stack of the client

Client business

Competition Analysis

Past History

SWOT Analysis

Contract/SOW Review

Contract/SOW review must be carried by Legal, Business Excellence Delivery before signing of the contract using Contract review checklist for Legal/Technical as per the SOW review Procedure

Every time an extension or revised scope, addendum is submitted for review.

Number of leads Generated. Number of direction Setting Calls (DSC)

Number of Leads successfully realized.

Sales / BRM Global Delivery Head

Presales Team

Account Manager

Business Excellence

Filled Estimation sheet Account Business Plan

Approved OAP

Sales process shall be audited as per the Internal Quality Audit Procedure

Metrics Procedure

The scope of this process covers the description of all the standardized metrics across the organization, intent & use of these metrics and the Storage procedures. It also covers the analysis methods for each metric, their interpretation and communication to identified persons.

Measurement objectives Organizational objectives are identified as the Big Y. Client Specific objectives are established at the time of startup of every project and hence they are generally distinct for each project. Projects measurement objectives are derived from organizational objectives, client specific objectives and objectives identified by project team.

The key objectives of the measurements are

Measuring and monitoring the performance Effective decision-making Completing the project successfully within given targets Provide baselines and benchmarks for the future projects to have better estimates and predictions Data to assess process stability and capability Identify opportunities for improvement

Data Collection and Storage PM shall collect & store the metrics data as per defined frequency as mentioned in D&Q Plan. SQAR shall review & validate the metrics data using the integrated checklist in Baseline sheets. BEPG shall consolidate and verify the metrics data shared by SQAG. BEPG Shall store Organisation capability baseline (OCB) data in Centralized repository as per BEPG Plan.

Analysis and Results

Assess the collected data based on the following Criteria :

Verity Synchronicity Consistency

PM shall prepare the control chart for each metric and interprets the results.

Communicate the results

Metrics coordinator shall communicate the Project Metrics Results at organizational level as per defined frequency.

Transition Strategy

The Projects shall transit from the old baselines to the New Revised baselines whenever there is a new capability baseline released & update their project goals accordingly.

Effort spent in Metrics data collection and analysis Corrective and Preventive actions taken based on the metrics analysis.

Business Excellence Process Group (BEPG) SQAG Project Team Project Manager Account Manager Senior Management

Updated Project Development/Maintenance/QA Baseline sheet Released organization capability Baseline Reports


System Support and Administration

The purpose of this procedure is to describes the process of system support and administration in order to have a control on hardware (H/W) and software (S/W) in the organization.

The system support also includes preventive maintenance of machines, virus and identification checking, and backup archival & retrieval of software.

Management of Hardware and Software

System Admin team maintains details of Hardware Allocation as per User resource form (Q227) filled by the user during receipt of the hardware.

Every user will be allocated not more than ONE machine. Only servers may remain unallocated to any particular user, but may be allocated to Projects.

Support on Hardware and Software

Employee can log service request by using Maximo Helpdesk

The helpdesk service engineer shall attend the problem & provide resolution within defined SLA.

A monthly analysis report shall be generated from and maintained by the System Administration.

Track of all pending calls is kept and is followed up with service agencies by the system admin team.

Software Backup and Restore

During installation of software, the software librarian shall issue only backed up media & update Software issue register. System admin team shall take daily differential and full backup of central VSS server on every Friday.

PM shall be responsible to ensure that proper backup / archive is taken on off-line secondary storage media.

PM shall ensure that whenever there is an environment change, structural change in the database, the backup of the server is taken.

The configuration controller of the project will be responsible for taking the regular backups and maintaining the backup log (wherever VSS tool is not used)

The backed-up media is maintained by system admin team in a fireproof location.

Archival and Retrieval

PM shall submit two copies of the product/software/application for archival form (Q224)to the software librarian on completion of the project.

The archives shall be maintained for a period not less than 3 years or as stated in the Project contract.

Whenever a need arises for the software/product/application from the archival, form Q285 shall be filled up to retrieve the material.

System Checking for Viruses

System Admin Team shall do virus checking on all computers, and if found shall clean the virus.

The results of virus checking shall be filled up in virus checking form (Q236) by the Helpdesk team and the signature of the user shall be taken.

System Security Employee can access Organisation resources by obtaining their user ID to logon to the network and systems.

Every employee shall abide by the companys Acceptable Use Policy

All systems should be protected with power on passwords

Floppy disk drives & all sorts of removable media is restricted in the premises.

Preventive Maintenance

Preventive Maintenance shall be carried out once in six months as per the schedule prepared by Site Manager Systems.

The System admin team shall randomly check to verify the correctness and effectiveness of preventive maintenance done by the external vendor & record his observations in preventive maintenance verification form Q234.

Server uptime

Project support/software complaint resolution time

LAN uptime

Leased line uptime

Internet connectivity uptime

All Birlasoft Employees

Completed archival/retrieval form (Q224) Completed H/W, S/W resource requisition form (Q227) H/W and S/W release form (Q295)

Completed hardware stock entry register (Q228) Completed software stock entry register (Q229) Completed preventive maintenance form (computers) (Q231) Preventive maintenance form (printers) (Q232) Preventive maintenance form (Hubs & switches) (Q233) Preventive maintenance verification (Q234) System correctness and identification (Q235) Virus checking form (Q236)

The System administration and Support Process shall be audited as per the Internal Quality Audit procedure

Project Initiation and Planning Process

The objective of this procedure is to describe the process of Project Initiation in project start-up phase. It includes the activity of having Tollgate Reviews within the Project Start up time. It is also required that the affected groups are informed about the project initiation through project initiation mail through ESA.

Project Initiation & planning Project shall complete Project initiation and planning activities at the start of the Project as mentioned below :

Execution of Process performance model for development projects and large enhancements in Maintenance projects Identification of Risks for the Project along with its Risk priority number (RPN) Preparation of Project Plan and approval from Client Review of Statement of work (SOW) which includes Business Excellence and Legal Review Set up of Project in PPM 7.1/Kintana Identification of Project Goals & SLAs of the project Preparation of PDSP & DnQ plan. PDSP should have all the tailoring which are required for the project Identification of Change Management Process & Templates Project Kick Off Meeting with the objective of sharing information & taking commitment from the project participants on scope, risks, methodology, delivery schedule etc.

Tollgates- Check for Process Adherence Tollgate 0 happens on the 5th working Day of Project Initiation in ESA Tollgate 1 happens on the 15th working Day of project Initiation in ESA Project Initiation Mailer is received to all the relevant stakeholders & the Process owner SQAG maintains a tracker for scheduling for Tollgate 0 & 1 Tollgate Review Dashboard is released by the Process owner telling the status of the Tollgates Tollgate 1 is NA for Staff Augmented Services (SAS) Projects

Release of Dashboards

Stakeholders shall receive Tollgate Review Dashboard within 1 day of the Tollgate reviews Stakeholders shall receive Monthly Tollgate Review Dashboard in first week of every Month Stakeholders shall receive an Escalation Dashboard for the Projects which have not cleared the Tollgates within the SLA timelines in first week of every month

Process level Sigma Value at Organization level

Tower Leaders Account Manager Project Managers SQAG

Tollgate Zero and One are Cleared


Customer Complaint ProcessA Complaint is defined as a response/feedback from customer wherein the customer expresses his unhappiness or reports unsatisfactory performance by the product/services supplied to him. This document describes the process to be followed on receipt of a customer complaint.

Documenting the Complaint

The recipient of a customer complaint shall document the complaint on the Customer Complaint Form (Q268).

The recipient of the complaint shall send an acknowledgement of the complaint to the customer .

Complaint Handling

The Department/Project/Account concerned shall take remedial/corrective action depending on the nature of the complaint .

The Department/Project/Account taking actions shall write the corrective and preventive actions on the complaint form (Q268).

The resolution/reply of the complaint shall be sent to the customer, with a copy to Head Business Excellence.

Identifying Corrective and Preventive Actions

The Department/Project/Account attending to the customer complaint shall conduct root cause analysis and should take suitable corrective and preventive actions in adherence to the Causal analysis procedure.

Complaint Followup and Tracking

PM, AM and Department Head shall follow up for closure of the customer complaint for department /project/Account respectively.

Delays in closure of the complaint shall be escalated. Closure SLAs and Escalation mechanism needs to be referred as per Escalation Management process.

SQAR shall audit the project for tracking of closure of the customer complaints.

Total number of customer complaints

Number of customer complaints where the resolution time exceeds the defined SLAs

CXO Tower Leaders Global Delivery Head Marketing Team

Account Manager

BRM/Sales

COE Leaders

GEO Leaders

Business Excellence

VOC Champion

Causal Analysis form

Corrective and Preventive action

Closed customer complaint

The Customer Complaint Process shall be audited as per the Internal Quality Audit procedure

Estimation ProcessEstimation process applies to the process of estimating size, effort and cost required for executing any or all phases of software development project. This estimation process is applied during the Proposal Preparation and at any time the estimate is required to be revised during the project life cycle.

Determine the Scope of Work/Requirements During Proposal stage , identify scope and measure in terms of functional/business areas, performance criteria and constraint. At proposal stage, identified ESTIMATOR prepares the level 0 estimates& reviewed by the respective identified REVIEWER from COE. During the execution of the project, the PM revisits the estimate and after review shares it with the client The requirements are decomposed into functions during the execution of the project which is a Level 1 estimate

Effort Estimation Effort is estimated on basis of the organizational productivity (when estimated through FP/ UC point methods) or through the complexity method for each of the COE when size factor is not used Consider the following factor while doing estimate: Expertise available in the target business area Expertise available in the target technical environment Training requirements specific to the project Dependencies on the client for input documents, feedback and approval etc. Potential idle time based on activity interdependency Impact of project size, project complexity and project schedules on project management / Quality Assurance & Control activities. Impact of Risk on estimated efforts

Document the basis of the productivity Determine phase wise effort Duration is arrived from the effort and the resources who will be allocated for the project

Resource/Cost Estimation On the basis of skills/grade of professionals, travel/onsite stay/communication Hardware and software costs DQT template is used to arrive at the cost estimation

Documenting the Estimates Estimation Sheet has to be prepared by selecting the models in QMS applicable for the project/proposed project once all the factors have been analyzed

Different for Maintenance Projects/ QA projects

Review and Approval of Estimation Sheets Approved by COE Head, Tower Head at the proposal stage

Reviewed by the Account Manager and COE Reviewer at execution stage

Review carried out in accordance with the Review procedure (BSL\ENG\01) Review comments are recorded in Estimation Review log (TPL 278 Estimation Model Review Log) Approval after review comments are incorporated

Effort spent on preparing estimation sheet, OAP sheet Additional risks identified

Account Manager Project Manager COE (Center of Excellence) Team Leaders Presales

Reviewed & Approved Estimation sheet


Statement of Work (SOW/Contract/MSA) ProcessThis Process identifies the applicability and impact of the contractual clausesbefore it is sent to theClient for formal signoff.This process also ensure reviewfromlegal and technical coverage perspective.

Receive the Purchase Order (PO) from the Client

The BRM /Sales SPOC communicate the high level details of the project and share the Purchase Order to the Account Manager.

BRM shall prepare Master Service Agreement (MSA) which will be duly reviewed by Head - Legal.

Sales/BRM shall provide the filled up commitment log for all verbal/ additional commitments made to the client to the delivery team.

Project Initiation in ESA AM shall request for project code creation to Business Excellence. Business Excellence team shall create project code based on prerequisites as follows : Billing base PO has to be shared as evidence for Billing base by AM PM shall provide the ESA snap shot to PMO for validation For New Win MSA review record by Legal DQT Sheet along with approvals as per the Executive Summary and Approval tab, it shall be shared with *DQT repository group in which BRM/sales person has to be in loop. PM shall share the name of the Account to ESA SPOC

Handover Takeover activity closure with Sales and Delivery The HOTO shall take place between Sales and Delivery within 2 working days of Project Initiation in ESA. BRM shall handover Proposal, DQT, MSA, MSA review record by Legal and the communication mails between client to AM as part of the HOTO.

SOW creation by Delivery PM shall prepare the SOW by taking inputs from the BRM/Sales SPOC. The SOW has to be created before Tollgate 0 which is conducted within 5 days of Project Initiation in ESA . AM shall perform self review of SOW from Technical, Legal, Financial and Business perspective. PM shall incorporates the review comments and the comments are tracked to closure. For the New Win , the solution shall be reviewed by the COE. AM shall share the self reviewed SOW with the Business Excellence SPOC and Legal team for review. BE & Legal team share the review comments inthe Contract Review Log template. PM shall incorporate all review comments & track them towards closure

Deliver & Sign off BRM sends the reviewed & approved copy of final SOW to the Client for signoff. SOW is signed off by the Client. From Birlasoft, the SOW is signed off by Sales SPOC with the signature

Number of SOW received for review before client sign off

Number of SOW received for review after client sign off Number of SOW received after delivery sign off to Legal and technical review.

Number of defects observed.

Number of defects closed.

Number of SOW sent tothe client without verification of review records

Number of SOW sent tothe client after verification of review records

Tower Head Account Manager Project Manager Head Legal Business Excellence Business relationship Manager (BRM) Pre Sales team

Contract/SOW review records -Technical Contract/SOW review records Legal Contract/SOW review process monitoring Dashboard Contract/SOW (SOW)updated with review comments

Contract/SOW Issue Tracker

Periodic Reviews and Audits are conducted in order to ensure Process Compliance.

Causal Analysis & Resolution Process This procedure defines the methodology of identifying and analyzing the causes of defects and other problems during the execution of the projects and taking suitable actions to correct those types of defects and problems to prevent them from recurring.

Triggers for Causal Analysis Customer complaint Defect trend analysis at organization level Output of process performance model (PPM) Non compliances found during process audits Total no. of Change request raised are more than five If top risks affect the Project goals At Project phase end After each review/test cycle At project closureState the Problem Project team shall Collect the data for causal analysis and Document the problem in the Causal Analysis form (Q272)Conduct Causal Analysis Conduct the causal analysis using causal analysis techniques as per Causal analysis guidelines (Birlasoft/GUD/06) Identify all the causes of the problem in the Causal analysis form (Q272). Out of all the Identified causes, identify the root causes using PPM and use process performance baselines for predicting most likely root cause. Identify corrective and preventive action (CAPA),prioritize their implementation. Conduct cost benefit analysis to achieve intended results. Update Project define software process (PDSP) for changes in project defined process and OSSP (organization standard software Process)for bringing organization level process improvements.Tracking and Evaluation of Actions Use PPM to determine if the change has positively contributed to meet process performance Objectives. Pre Causal and Post Causal data is evaluated statistically to validate that change is significant. All CAPA shall be tracked for their effectiveness on a weekly basis by monitoring their trends. Based on the positive trend, CAPA can be further analyzed & implemented at the organization level. Analyze anticipated and Actual benefits by implementation of CAPA.CAPA Organization level improvement CAPA may result in process improvement, which can be taken as the Process Improvement Proposal using six sigma technique.Defect Analysis at Project level :PM shall do the project level defect analysis on the basis of: Severity of the defects Technical classification of defects Causewise classification of the defectsDefect Analysis at Organization level Metrics team will analyze the defect data at the organizational level for all the buckets such as SDLC, Maintenance and QA. Metrics team shall prepare the Defect Prevention Plan for each quarter & track the Defect Prevention Strategies at the organizational level. Metrics team shall conduct the causal analysis on the most common cause of defect for the different buckets on quarterly basis, as per Defect Prevention plan.

Review of Corrective & Preventive Action Business Excellence shall present the statistical report on effectiveness of CAPA during Management Reviews. Metrics team shall disseminate the knowledge and actions taken though this process and management reviews across the organization.

Effort spent on causal analysis Reduction in rework effort Process performance before and after Causal Analysis


Corrective and preventive actions Defect Analysis Reports (SDLC, Maintenance, QA) Corrective and preventive actions result disseminated Pre Causal and Post Causal Data

The Causal Analysis & Resolution Process shall be audited as per the Internal Quality Audit procedure

Management Review Process

This procedure defines the system to review the continuous suitability and effectiveness of the quality system as related to companys business activities as well as to set objectives and goals for qualitative improvements.Management Reviews and Frequency

Management Reviews shall take the form of a meeting to be presided over by Center Head at each location Center heads shall inform all the participants. Management Review Meeting shall be attended by the following:

1. Location Level : Centre SQAG SPOC Head of Functions (Delivery Groups, HR Resourcing, System Support and Administration, Training) for respective location Account Managers -Projects2. Corporate Level : CEO, CFO, Head HR, Tower Heads, GEO Heads, Delivery Heads, Function Heads, BE Leaders will preside of the session.

Representatives of respective Functions should attend the meeting in absence of any one of the above

Global Delivery Head shall allow any other person to attend the meeting, if so requested, by any of the designated participants.

Management Review Meeting AgendaCenter Head shall prepare the agenda of MRM in consultation with Head of Functions atleast one week in advance The agenda shall normally comprise of : Review of open items from last meeting Operation of the company in relation to the status of implementation of the QMS Organization capability Baselines against defined targets Causal Analysis Findings Trends/ Predictive Analysis from Process Performance Models Summary of assessment of internal audits conducted Statistical data on customer complaints & their redresses Training Needs Evaluation reports of Projects (current / closed) during the period Corrective & Preventive Actions taken Policy Issues Status of Defect Prevention activities Decision Analysis action items if any Status of DMAIC projects and process improvement activities Any other areas of Concern MR is responsible to highlight non-conformances that are contributing to in-ordinate delays in its closure.

Minutes of Meeting Center Head shall ensure that the minutes of Management review meeting along with actions items recorded. Copies of minutes shall be made available to all designated participants. Head of respective functions are responsible for timely and effective implementation of actions. These actions shall be reviewed in the next meeting.

Tracking of Closure of Action Item Center Head shall keep the track of the closure of Action Items as discussed in Management Review Meeting. Deviations are to be escalated to Global Delivery Head in next Management Review Meeting.

Number of Non compliances raised in MRM

Number of open and closed action points of MRM

Number of participants present and absent in the MRM

CXO MC Members Global Delivery Head Head of Functions Management Representative (MR) SQAG SPOC Account Manager COE Head Tower Leader

Minutes of Meeting with Action Items Management Review Presentation

The Management review procedure shall be audited as per the Internal Quality Audit Procedure

Handing/Taking over of ChargeThis Procedure describes the method of handling the Handing/Taking Over of Charge method at organization level. It also caters to special situations where only taking over of charge happens on account of the absence of handing over employee.

Assign resource for taking of chargeAccount Manager shall define the scope and extent of transfer. He shall identify the replacement who will take charge from the outgoing employee.Handing/Taking over of charge

The outgoing employee shall fill form Q219 to report all issues / concerns, pending work, list of hardware / software and documents being handed over within the scope of the transfer.

The outgoing employee provides orientation to the incoming employee on important issues.

The incoming employee needs to ensure that he stands apprised of all issues / concerns and relevant data is taken by him is in order.

Both employees shall review and sign the completed form Q219.

In case of handing over includes multiple people, then separate Q219 should be filled for each incoming employee.

Taking over of charge

In case outgoing employee is not available for handing over the responsibilities, then AM shall assigns the incoming employee all the necessary responsibilities including issues and open work items.

The incoming employee shall identify & discuss risks/issues along with AM for mitigation strategy.

Incoming employee shall sign form Q219.

Risk Assessment

Identify risk which affects the project execution due to change in responsibilities as per the risk management procedure.

AM Shall approve the form Q 219.

Inform Customer

Inform the customer the change in responsibilities with complete information about the incoming employee. (Applicable for A4 and above)

Appraisal

AM along with PM shall do performance appraisal as per organization practice.

IF PM is the outgoing employee, then he shall appraise all team members before leaving the project.

Relieving of responsibilities

On completion of all formalities ,employee is relieved of all responsibilities and confidentiality issues if any.

Maintenance of Q219

The incoming employee shall maintain form Q219 in the project file.

Effort spent on handing/taking over in any project.

No. of handing/taking over that took place in any project .


Complete & signed Handing/taking over form Q219

Appraisal forms Q271 (If applicable)

The Handing/Taking over of Charge procedure shall be audited as per the Internal Quality Audit procedure

Decision Analysis and ResolutionDecision analysis is a process by which one can select the best option out of different alternatives available based on certain parameters. Not every decision is significant enough to have a formal evaluation process as this process is costly. This procedure also explains approach, Methods for decision analysis and how to select the best from different alternatives.

Identify Areas for Decision analysis

Some of the areas where there may be a need for formal decision analysis :

Risks with High exposure Selecting the architecture Use of reusable components Selecting suppliers Any big business decisions where cost is very high

Plan for the Decision Analysis & Resolution (DAR)

DAR activities are planned in D&Q Plan for successfully identifying the best solution Identify the relevant stakeholder along with their roles and responsibilities.

Identify Alternative Solutions Take input from different stakeholders Document rationale for evaluating identified alternatives

Select Criteria for Evaluation

Identify the evaluation criteria which are going to impact the decision into the following three categories :

Functional requirements Non functional requirements Legal requirements

Select Evaluation Methods

Few options for evaluation are as follows : Brainstorming method Voting/Survey method Prototyping Simulation Decision Tree Process performance model

Comparative Evaluation of Alternatives Identify, evaluate and document all the assumptions. If process performance Model is used for identifying best alternative, it statistically evaluates the alternatives. Evaluate identified alternatives based on the evaluation criteria and the methods. Identify the weightage for each factor based on the priority and importance. Calculated the scores by summing up the multiplied weight and rated value for all the parameters Select the best solution from different alternatives. Document the rationale for selecting the best solution Identify the risks associated with implementing this new solution

Approve the solution Take the approval from the relevant stakeholders who are going to get impacted by the decision

No. of Decisions taken by using formal Decision analysis process Effort spent in conducting DAR

Project Managers Account Managers Business Excellence Senior Management Global Presales

Rationale for selecting the best alternative

Decision analysis matrix (Filled template)


Document Change & ControlThe purpose of this procedure is to define and lay out the guidelines for initiation, authorization & implementation of change requests for all in Quality Management System (QMS).QMS includes Quality Manual, Policy, Process Handbook, Procedures, Templates, Guidelines, Checklists, Standards, Tools, Forms Training Material and Sites)

Initiate Change Request Employee raise request to Business Excellence Process Group (BEPG ) through On-line QMS Feedback System available at Kmantra Changes to QMS are triggered through :

Improvement suggestion proposed by any employee. Analysis & recommendations of software process assessments Analysis of Defectprevention /Causal analysis activities. Inputs from Learning database at organization level. Result & analysis of project tailoring database at organization level Analysis of project tailoring database at organization level Analysis of Process and product measurement data Process improvement Initiative (Six sigma Projects) Internal / External audit/assessment results Incorporate Industry best practices Internal Business Excellence team review

Review and Approval of Change Request

BEPG evaluates all the document change requests and process improvements as per Document Generation Procedure Based on the impact analysis BEPG accept/reject/deferred the change request & update the requestor accordingly.

Change in Process Document

Head BEPG shall assign the approved change request to BEPG team member/SME for detailed impact analysis and modification of affected process artifact.

Assigned team member shall checks out assigned document from Working folder in VSS and make changes as per the change request.

Author is required to update version number & modification history detailing the specific changes made in the document.

The modified document is then subjected to Peer review/SME review as per the Procedure Index (Q319).

QMS Training material is updated appropriately to reflect the changes done in the QMS.

The review comments are logged in Q205/Defect Tracker and tracked towards closure.

Baseline of Process Document CC shall baseline the reviewed and approved artifact in VSS & on KMANTRA and update the QMS Release Note (Q320) for the new/updated documents with the latest Version.Release of QMS Management Representative (MR) approves QMS Release Note (Q320), which includes the details of all baseline artifact available in QMS. QMS release is done periodically and communicated to all employees through mail along with the QMS Release Note (Q320) & Deployment Plan. BEPG shall plan and conduct awareness sessions to ensure implementation of the newly added/modified documents in the projects.

Number of Change request received


Approved & baseline Artifact in QMS

Training Material

The Document Change & Control Procedure shall be audited as per the Internal Quality Audit procedure

Product Integration ProcedureThis process defines the sequence for integrating various modules/ Product components in an orderly manner to ensure that the end product meets all the requirements specified by the customer.

Integration Sequence

Project Team shall

Identify the Product components to be integrated and the verification of the same. Identify alternative product integration sequence if there are more than one layer of integration. Apply Decision analysis and resolution (DAR) technique & choose the best sequence (Refer DAR procedure)

Integration Environment

Project Team shall

Apply DAR technique for taking the decision of Integration environment to make, reuse, buy results Create Integration environment if it is not acquired & need to be maintained throughout the integration as per the future needs. Product integration process

PM shall prepare product integration plan , which shall capture product integration environment, criteria, all interfaces, steps of integration, criteria for validating and evaluating product component for e.g. Levels of testing, verification of interfaces, &final integrated products are to be validated and delivered.

SME shall review the product integration plan.

PM shall update the review comments & get it verified by SME.

Assembling Product component

Project team Shall

Perform the assembly sequence as per Product Integration plan Perform evaluation of the assemble product components & record results. Deploy and deliver the product as per deployment plan.

Number of defects Captured

Account Manager Project Manager Team Leader Project TeamSQAR

Product Product Integration plan DAR Records


User Documentation Procedure

The Purpose of this procedure is to prepare Documentation that guides users in installing, operating and managing software product being developed.

Preparation of User Documentation

Project Team Shall Study the SRS & HLD Document to design the User Manual with all the Screens and Reports to be used as per client approved template. Team Member shall prepare Online Help using the tool to facilitate quick reference while working on the developed software product.

The Team Member shall prepare the Installation guide using the tool to facilitate installation, operation covering the following, Hardware Configuration Operating System Application Software Networking Pre-requisite data Troubleshooting Operating the system etc.

Review/Testing of User Documentation

The PM/TL shall review the user documents, as per guidelines for Review (BSL/ENG/01) for the following, Style and Grammar Complete coverage of functionality as per Software Requirement Specifications Test the document by installing and running the software using the documents.The PM/TL shall record the observations and defects using defect Tracker /Q205.

Closure & Verification of Defects

The Team Member shall close the defects and record the closure in the Review Form.

The PM/TLshall verify the closure of Defects. The review report is closed by the PM/TL when all the defects have been rectified.

Baseline the User documentationConfiguration controller baselines User documentation after PMs approval.

Total number of defects in the User Documents

Effort spent in preparing the User Documents

Review Effort

Rework Effort

Project Manager

Team Leader Project Team

Testing Team

Configuration Controller Technical Writer

User Manual

Installation Guide Online Help Bundle Quick Reference sheets Updated Review Records (Q205)


Maintenance Procedure

Maintenance Procedure

The purpose of the Maintenance process is to manage the maintenance projects in the organization. This may include all kinds of tasks associated with the maintenance projects that is enhancement, bug fixing and production support

Bug Fix and Production Support Project Team shall1. Analyze, collect and elicit stakeholder/client needs2. Perform Size estimation for the work packet as per the estimation procedure PM review the impact analysis and assign the work packet to the appropriate team member Team member shall perform coding as per the code generation procedure Project team shall review and test the piece of code as per the review and testing procedure using review checklist (BSL/CHK/61) Project team updates the requirement traceability matrix form (Q284)

Enhancement tasks

PM shall decide & follow below mentioned steps depending upon the scope in the project and the deliverables to the client as per the task order Project team analyze the work packet Size estimation is performed as per the estimation procedure PM shall assign the work packet to the appropriate team member Prepare design as per the design procedure. System and Integration test plans will also be prepared (if applicable). Design review shall be done Perform Coding as per the code generation procedure Integrate modules and interfaces, if applicable, as per Product Integration procedure Perform code review will be done as per the review procedure Perform Testing as per the testing strategy mentioned in the D&Q plan. The Project team updates the requirement traceability matrix form (Q284) mapping all the requirements to suitable sections.Project Data Analysis (Applicable in all scenarios ) Project team shall record the project related data for Delivery Variance, Effort Variance, Review Efficiency, Testing Efficiency &client specific metrics (If any) as per project baseline template for Maintenance project

PM shall analyze the data trends and document the interpretation in the respective sheet of the Project Baselines templates.

Project Team shall perform causal analysis and take corrective action for any data point found beyond the targeted control limits as defined in the Project objectives & Goals sheet (Project baseline template)

Effort spent in completing the work packet Rework effort Review Effort Testing Effort

Account Manager Project Manager Team Leader Project Team Testing TeamSQAR

Updated Work Packet


Implementation ProcedureThis procedure describes the procedure for installing and commissioning the software product and getting an approval from the client on successful running of the system .The procedure also describes the training activity for the end users so as to facilitate them in using the software product at the clients environment.

Installing and Commissioning the Software Product

Project team Shall

Port, convert or migrate the data to the accepted system as per the contractual obligations.Install software & commissioned in the customers environment by creating different directories and placing the files in them as per the Installation guide. Track all defects to closure using Q205. Follow Change Management Procedure for any changes reported during the Installation & commissioning.

Update User Documentation

Update the user manuals and installation guide on completion in this phase.(If applicable)

User Training User Training will be conducted only if it is part of contract. Define the scope/objective in terms of : Complete System Module/Sub-system Installation procedure/manual Prepare the User Training Schedule Prepare the Training Material Conduct training as per the schedule and take feedback from participants. Take corrective action based on the feedback provided by the participants.

Sign Off from Client

PM shall be responsible for obtaining a sign off from client indicating software product has been accepted. PM shall ensure VOC of the project is raised and received.

Implementation Schedule (Planned Vs Actual). Effort spent in implementation. Rework effort. No. of defects found in implementation phase.

Account Manager Project Manager Project Team Client

User Documentation (If applicable)Training material (If applicable)Acceptance Sign-off communication (From Client)


Early Warning Process The purpose of this process is to act as a proactive alert mechanism for delivery function, wherein engagement and project level issues/Risks are proactively identified and informed to the Senior management and ensure corrective / prevention actions are taken.Business excellence team shall publish the consolidated report/ Dashboard to highlight early warnings effectively at appropriate levels and track them towards closure.

Early Warning/Escalation Identification:

SQAG Tower Leaders identify the early warnings based on the below mentioned parameters:

Customer Escalation through any channel

VOC less than 4

Contracts/SOW not available

Missing SLA target in Production Support project

Missing milestones

No Plan available

Tollgate failure

High impact Risk

Audit NC not getting closed within Target Date

VOC not received

Requirements not agreed by client

PMR not done

If PHI Trend is dropping

SOW review comments not closed

FIR Failure

Customer Complaints

SQAG Tower Leader collates, categorizes early warnings as per ROY methodology (Red Escalation to CEO, Orange to Global Delivery Head, Yellow to Tower leader).

Tower Level Dashboards:

SQAG Tower Leader publishes the dashboard on weekly basis to Tower Leader.

Monitoring and Review

Tower Leader reviews the dashboard published by SQAG Tower Leader and shares updates if any.

CXO Level Dashboard

SQAG Leader publishes consolidated dashboard on a weekly basis, in cases where issues need CXO level attention.

CXO Level Dashboard includes all the issues from all towers which are categorized as Red/Orange.

Global Delivery Head reviews the issue with respective stakeholders on weekly basis.

Escalation of Issue from One Level to Next Level:

All customer escalations are tracked at least at GDH level till the time issue comes under control. For any Early Warning/ Escalation, If there is no update provided by PM/ AM for 3 subsequent weeks, it will be escalated to next level radar for review. Any open issue with aging >30 days at one level should be moved to next level. However it can be moved back to earlier level if reviewer recommends.

Issue Resolution:

For removal of escalations from the escalation dashboard, PM/AM shares the evidence for the closure of the escalation; SQA Tower Leader verifies the evidence and removes it from the dashboard.

Number of early warning issue reported by BRM/AM/SQAG Issue Resolution Rate

Global Delivery Head Tower leader

Business Excellence

CXO

Delivery

Project Manager

Account Manager

Sales / BRM

Support Function

Updated early warning Dashboard Quarterly Analysis

Learnings

The Early Warning Process shall be audited as per the Internal Quality Audit procedure

Client Visit ProcessThis procedure defines the client visit process at Birlasoft premises at all India location offices. This procedure describes the activities to be performed, roles and responsibilities, and data to be generated, collected and recorded.This procedure is needed to ensure that all new/ existing client visits handled with consistency and coordination among all support and delivery function as needed.

Client Visit Planning Phase Sales/BRM shall identify the client key objective & expectation from Birlasoft as Per (TPL-304-client key objective mapping)

BRM shall take the cost approval from their respective Tower Head.

BRM & AM shall specify any additional requirement for prospective client if any. Sales team/ AM shall prepare the detail client visit agenda and share with all the relevant stakeholders.

Sales/BRM shall prepare Dossier and agenda for the client visit (TPL-303-Client Visit Agenda) and share with relevance stakeholders.

Admin team shall prepare the logistics plan and share it with Presales/ AM/ BRM for review.

BRM/AM/ Presales shall decide on client visit modalities and presentation content. They shall inform all the relevant stakeholders for the key presentation support required from them.

AM/ BRM shall decide the master of the ceremony who will be responsible for:

Agenda with the visitors

Checkpoints during the mid sessions

Summarizing the various action points

Mobilization Phase BRM/Sales shall collate all the presentation and ensure that final presentation is as per the corporate presentation format as suggested by Branding / Marketing team.

Admin SPOC shall share the logistic requisition form with the sales team to confirm visit requirement. (Refer Q376-Client visit logistic requisition form)

BRM/AM/ Presales shall coordinate for a dry run of presentation to ensure Key Messages that have been identified & shall be delivered by the various Stakeholders as per stated objective and expectation for the client visit.

The master of ceremony/BRM shall ensure that all presentations are complementing and covering the agenda as per client expectation.

BRM shall set for Business Lunch /Dinner discussion agenda and send invites to intended participants.

If Live Experience / Bay visit / Facility walkthrough visit is involved, BRM shall communicate it to all relevant stakeholder including delivery and admin SPOC.

All stakeholders should provide their commitment for the client visit. The presentation should be shared as per the SLA Matrix.

Conduct Phase

Sales team will present the dossier and sets the refined agenda with Client on his arrival.

BRM/Master of ceremony will presents Company Overview, Enterprise Direction followed by presentation session by stakeholders as per the detailed agenda

BRM/AM/Master of ceremony will present the Gifts and Memorabilia presentation

Sales/BRM SPOC will identify Actionable Items from the Client Visit and shares them with relevant stakeholder.

Follow Up Phase Sales/BRM shall prepare the detailed Client Visit Report and shares the same with Management / Tower Leads.

BRM/Admin lead shall take the formal feedback from the client during wrap up session..

Sales/BRM shall monitors and tracks to closure all Actionable Items. Information is shared with Sales and Client.

Presales/ BRM/AM Stores the Client Visit Presentations, Client visit Reports and Feedback in centralized repository maintained by Presales team. All approved presentations shall be uploaded at Kmantra for future reference.

Customer Satisfaction Index

Return on Investment

Sales/BRM

Presales

Account Manager

Project Manager

Delivery team

Administration team

Marketing team

Delivery team

COE

Practices

Human Resources

Business Excellence

Client Visit Detail agenda

Client feedback form

Presentations shared by Delivery/COE/support functions

The Client Visit Processshall be audited as per the Internal Quality Audit procedure

Acceptance Testing ProcedureThis procedure describes the methodology of performing acceptance testing. It details out the activities involved in acceptance testing including identifying the resources and environment for acceptance testing, providing support for acceptance and getting the final signoff from the client .This procedure also describes the method of handling problems detected during the acceptance phase and to take corrective action accordingly

Plan for VerificationProject team Shall,

Select the product component for verification.

Identify most suited Process Performance Model for Acceptance testing (Manual / Automated) so that Project defined goal can be achieved.

Identify the verification environment to ensure it can be carefully controlled to provide for replication, analysis of results, and re-verification of problem areas.

Application Set-up

The Project team shall set up the hardware servers, installation and configuration of the operating system in consultation with the client. The Project team shall install the Software product. Setup Database, create user logins (If applicable) Ensure that the baseline Integrated sub-systems/modules are installed

Conduct Acceptance Testing and Reporting Testing is performed as per the Acceptance Test Plan. The client shall performs the testing with the approved test cases. The status is reported to the Project Manager/Program Manager as per the plan

Defect Reporting and Recording Project team shall record the details of all failed cases by recording in defect tracking tool review /Q205 execution. Update Acceptance test cases for the missing scenarios, change requests or inconsistencies if any, and update the RTM accordingly.

Closure of Defects

Project team shall close the defects as per the identified corrective actions. PM analyzes and identifies the corrective action for the defects and update test plan (TPL-25-testplan) and test cases (Q217) if required.The Review Team shall verify the closure of Defects.

PM shall analyze the defect data at Phase end or at the end of each iteration and corrective action shall be identified and tracked.

Change Control

Any changes initiated by the client needs to be recorded as change requests, and the change control procedure needs to be followed (Refer Birlasoft/PRO/10).

Bi-Directional Requirement Traceability Matrix

The Project team updates horizontal and vertical traceability matrix form (Q284).

Update User Documents

The user documents e.g. (SRS document, HLD, LLD) including the user Manuals are updated based on changes /defects found during Acceptance testing.

Acceptance or Sign Off from Client

Project Manager shall be responsible for obtaining a sign off from client indicating software product has been accepted.

Total number of defects found in the application Total effort spent in Acceptance Testing Total duration/time spent in Acceptance Testing Rework Effort Defect Density at UAT

Account Manager Project Manager Project Team SQAR Testing Team Configuration Controller Client

Tested and updated Software product Defect Test Report /Review record (Q205) Acceptance Sign-off communication (From Client)


System Testing ProcedureThe System testing procedure describes the steps followed after successful integration testing is completed & all the unit processes making up the subsystem have been successfully integrated.

System Testing include Regression Testing, Performance Testing, User Interface Testing, Load Testing, Volume Testing, Stress Testing and Security Testing.

Plan for Verification

Project team Shall,

Select the product component for verification.

Identify most suited Process Performance Model for System testing (Manual / Automated) so that Project defined goal can be achieved.

Identify the verification environment to ensure it can be carefully controlled to provide for replication, analysis of results, and re-verification of problem areas.Configure Testing Environment Ensure that the baseline Integrated sub-systems/modules are installed

Configure the servers

Populate Master data (if applicable)

Hand-over the system to the Testing TeamConduct Testing and Reporting Testing Team Member shall conduct the System Testing as per the System test cases .The TM shall record the actual results using Test Cases (Q217) Testing Team shall perform the various categories of System Testing (Refer guidelines for Testing Birlasoft/GUD/24)Defect Reporting and RecordingTesting team shall record the details of all failed cases by recording in defect tracking tool review /Q205 execution.Testing Team shall provide detailed description of all the failed case in the Defect Tracker. Team is also responsible for filling the complete defect details including defect type classification. Testing team shall prepare the Test Report using Test Cases (Q217)

Closure of Defects

Project team shall close the defects as per the identified corrective actions. Corrective action may also result in updating test plan (TPl-25) & System test cases (Q217) The Review Team shall verify the closure of Defects.

Configuration Controller shall baseline the System Test Code based on PMs approval.




Total number of weighted defects in the application Rework Effort Effort spent in Test Execution Schedule for System testing

Account Manager Project Manager Project Team SQAR Testing Team Configuration Controller

Baselined Source code System Test Cases (Q217) Updated User Documents Defect Test Report /Review record (Q205)


Integration Testing ProcedureThe Integration testing procedure describes the steps for testing the functional integration between the Unit Process/modules. It also tests the data flow between them.

Plan for Verification

Project team Shall,

Select the product component for verification. Identify most suited Process Performance Model for Unit testing (Manual / Automated) so that Project defined goal can be achieved.

Identify the verification environment to ensure it can be carefully controlled to provide for replication, analysis of results, and re-verification of problem areasConfigure Testing Environment

Configure the operating system Install the Software Configure the servers Populate Master data (if applicable) Build the application and install the same Hand-over the system to the Testing Team

Conduct Testing and Reporting

Run process performance Model & take decision on whether Integration Testing will be manual or automated and accordingly Unit Test Cases and Test Script will be prepared.

The Testing Team Member shall conduct the Integration Testing as per the Test Cases .The TM shall record the actual results using Test Cases (Q217)

Defect Reporting and Recording

Testing team shall record the details of all failed cases by recording in defect tracking tool review /Q205 execution. Testing Team shall provide detailed description of all the failed case in the Defect Tracker. Team is also responsible for filling the complete defect details including defect type classification. The Testing team shall prepare the Test Report using Test Cases (Q217)

Closure of Defects

The Project team shall close the defects as per the identified corrective actions.

The Review Team shall verify the closure of Defects.

Configuration Controller shall baseline the Integration Tested Code based on PMs approval.




Schedule of Integration Testing Effort spent in rework Number of defects captured Number of defects in a particular functionality/Module. Effort spent in Test Execution.

Account Manager Project Manager Project Team SQAR Testing Team Configuration Controller

Baselined Source code Integration Test Cases Updated User Documents Review record (Q205)


Preparation of Test Cases ProcedureThis procedure is followed during the Requirement and Design Phase of the Project and covers preparation of System Test Cases (STC) and Integration Test Cases (ITC).

Identification of ITC & STCProject team shall,

Study the HLD Document and the Functional Model to understand the functionality of the integrated sub-systems Determine the Functional dependency between the Unit Processes based on the SRS & HLD document. Identify the interfaces and data inflow and outflow of each sub-system. Identify the key principles, features, and phases for product or product-component validation throughout the life of the project. Determine which categories of user needs (operational, maintenance, training, or support) are to be verified and validated.

Preparation of ITC

The Project team shall prepare the ITC(Q217) taking into account the following : Correctness Functionality Logic Error, Exceptions and Boundary Conditions Adherence to Standards and Guidelines for Test Cases (BSL/GUD/24)Preparation of STC The Project team shall prepare the STC,taking into account the following : Sub-system functionality and interfaces mentioned in HLD document. All the requirements in the Software Requirements Specifications have been met. Other requirements like performance, security, error recovery, maintainability, portability and compatibility etc.Review of ITC & STC The Integration and System Test Cases shall be reviewed by the PM/TL, as per Test case Review Checklist. The Review Team shall record the findings in PPM/client specific tool/Q205. The Project team shall close the defects as per the identified corrective actions.

Closure of Defects The Review Team shall verify the closure of Defects.

Configuration Controller shall baseline the ITC &STC based on PMs approval.

PM shall analyze the defect data at Phase end or at the end of each iteration and corrective action shall be identified and tracked. Bi-Directional Requirement Traceability Matrix

The Project team updates RTM(Q284) to ensure Test Case coverage and completeness with respect to SRS & HLD.

Approval & Baseline CodePM reviews the final Code & submit to client for review. Configuration controller baselines Code document after approval.

Effort spent in preparing the ITC &STC. Effort spent in review Total number of defects in the Integration test Cases Total number of defects in the System Test Cases Effort spent in Rework.

Account Manager Project Manager Team Leader Project Team Testing TeamConfiguration Controller

Baselined Integration Test Cases Baselined System Test Cases Review Records (Q205)


Unit Testing ProcedureThe Objective of the Unit testing is to ensure the steps to be followed to confirm that it meets the functional requirements as specified in Program Specifications.This procedure covers : Testing of the user interface to ensure that information properly flows into and out of the program unit under testing.

Examine the local data structure to ensure that data stored temporarily maintains its integrity during all steps in Test Case execution.

Test boundary conditions to ensure that the program operates properly at boundaries established to limit or restrict processing.

Plan for verification

Project team shall,

Select the product component for verification. Identify most suited Process Performance Model for Unit testing (Manual / Automated) so that Project defined goal can be achieved.

Identify the verification environment to ensure it can be carefully controlled to provide for replication, analysis of results, and re-verification of problem areas.

ConductUnit Testing

The Configuration Controller shall move the Code to the Review/Testing area for Unit Testing, on approval from PM/TL. Conduct Unit Testing as per the Unit Test Cases as per the guidelines BIRLASOFT/GUD/24.

Prepare the Test Report using Test Cases (Q217).

Defect Reporting and Recording

The Team Leader/Member other than developer of program code will :

Understand the functional specifications in HLD/LLD Document, program specifications and unit test cases to understand the flow of the process.

Update the unit test cases for the missing scenarios or inconsistencies if any, and update the Requirement traceability Matrix accordingly.

TL/ TM will record defects using Defect Tracker/ Q205.

The Configuration Controller shall move the code to the Working area for update of code on approval from PM/TL.

Closure of Defects

Developer will update the program code and close the defects in the Defect Tracker for the test cases executed as per test cases (Q217)

Developer will update the review comments and resubmit it for verification to review team.

Developer will ensure the closure and verification of the defects by performing another cycle of unit Testing.



The Project team updates the requirement traceability matrix form (Q284) mapping all the requirements to suitable sections.


Schedule of Testing (Planned vs. Actual) Effort spent in Unit Testing Effort spent in rework Number & type of defects captured Number of Unit Test Cycles

Account Manager Project Manager Team Leader Project Team Testing Team SQAR

Unit tested & baselined code Review Log (Q205)


Code Generation ProcedureThis procedure applies to the Coding and integration of the product (Code generation, Code Walkthrough, Code Review and product integration).

Code Generation

Project team Shall,

Identify most suited Process Performance Model for generating code, so that Project defined goal can be achieved.

Project team should check the reusable components repository for the existing components that can be re- used in the project.

Project team write the program using program template and coding standards as defined for the project.

Compile the program code.

Code Review Review team shall review the Code ,RTM & method resulted from Process Performance model execution.

Review is performed as per the code review checklist (BSL/CHK/07) and traceability matrix for fulfillment of requirements.

The review team will record defects using Defect Tracker/ Q205.

The Project team will update the review comments and resubmit it for verification to review team.

The review team ensures the closure and verification of the defects.


The Project team updates the traceability matrix form (Q284) mapping all the requirements to suitable sections.

Tollgate Reviews

Conduct Tollgate4, phase1 at 20% completion of coding. Conduct Tollgate 4 Phase 2 at 80 % completion of coding.


Schedule of Code (Planned vs. Actual) Effort spent in review of Code Effort spent in rework Number of defects captured Review Efficiency Tollgate SLA adherence

Account Manager Project Manager Team Leader Project Team Technical SME

Reviewed & Updated code Integrated product Review Log (Q205)


Low Level Design ProcedureLow Level Design (LLD) Process focuses on detailing on the data structures and algorithmic representation as presented in HLD. The system is broken down into procedures/programs. The logical design is done for every program and Program Specifications document is prepared.

Define Low Level Design

Project team Shall,

Identify most suited Process Performance Model for developing the LLD, so that Project defined goal can be achieved.

Project team finalizes the physical structure of entities, optimizes the design by de-normalization, and details out the physical data elements using HLD.

The Project team prepares program specification as per specified format. (Refer TPL-15-LLD & TPL-16-LLD)It contains details about different views such as database states/modes, logical, functional, environment, build and security.(Refer Security Guidelines for Web Applications)Unit Test Cases and Test Scripts

Run process performance Model & take decision on whether Unit Testing will be manual or automated and accordingly Unit Test Cases and Test Script will be prepared.

Prepare Unit test plan and test cases using Q217 to cover the functionality of the program unit as per LLD.

Exercise all independent paths through the control structure to ensure that all statements in the code get executed at least once.

Test all error-handling paths.(Refer guidelines on testing for preparation of test cases and scripts)


The Project team updates the traceability matrix form (Q284) mapping all the requirements to suitable sections in the Low Level Design Document.

Low Level Design Review Review team shall review the LLD ,RTM & method resulted from Process Performance model execution.

Review is performed as per the LLD checklist (BSL/CHK/07) and traceability matrix for fulfillment of requirements.

The review team will record defects using Defect Tracker/ Q205.

The Project team will update the review comments and resubmit it for verification to review team.

The review team ensures the closure and verification of the defects.

Approval & Baseline HLDPM reviews the final LLD & submit to client for review. Configuration controller baselines LLD document after approval.

Effort spent in LLD (Planned vs. Actual) Schedule of LLD (Planned vs. Actual) Effort spent in review of LLD Effort spent in rework Number of defects captured

Account Manager Project Manager System Analyst Team Leader Project Team

Program Specification Unit Test Cases and Test Scripts Physical data elements (Technical Package) Review record (Q205)


High Level Design ProcedureThis procedure describes how High Level Design (HLD) is prepared (confirming to the addressed agreed standards as mentioned in the D&Q plan), reviewed and approved.

Select and Develop Product-Component Solution

Project team Shall

Identify most suited Process Performance Model for developing the HLD, so that Project defined goal can be achieved. Define alternative solution and selection criteria using Decision Analysis and Resolution (Refer DAR procedure) Define an initial set of architecturally significant elements to be used as the basis for analysis. Define an initial set of analysis mechanisms for all non functional requirement including Safety, Security, Performance etc.(Refer to Design Security Guidelines)

Prepare the HLD with below details :

Define the Run-time Architecture Define Distribution Define Sub System Design Implement the Product Design


The Project team updates the traceability matrix form (Q284) mapping all the requirements to suitable sections in the High Level Design Document.

Prepare System and Integration Test Plan

The Project Team prepares the System Test plan, Integration Test plan ( TPL-25-Testplan) & Integration test cases (Q217) and takes the sign off from the client

Design Review Review team shall review the HLD ,RTM & method resulted from Process Performance model execution. The review team will record defects using Defect Tracker/ Q205 . The Project team will update the review comments and resubmit if for verification to review team. The review team ensures the closure and verification of the defects.

Approval & Baseline HLD PM reviews the final HLD & submit to client for review. Configuration controller baselines HLD document after approval.

High Level Design effort Review Effort Number of review comments Rework effort

Account Manager Project Manager System Analyst Team Leader Project Team

High level design (HLD) Updated Requirement Bi Directional -Traceability Matrix System Test Plan and Test Cases Integration Test Plan and Test Cases


Requirement Specification ProcedureThis procedure describes how requirements are gathered, analyzed and elicited. The main objective of the requirement analysis is to produce a document that properly specifies all requirements of the customer. This process is applicable to SDLC projects >300 person hrs.

Develop and Understand Customer Requirements

PM Shall

Identify most suited Process Performance Model for developing the Requirement so that Project Defined Goal can be achieved. Prepare Requirement Gathering Plan (Refer requirement Gathering guideline for details)

Prepare Stakeholder request gathering template to identify Stakeholders need and map it to the customer requirement.

Develop and establish product requirement Align the project team in their understanding of the system and take the commitments on the requirement.

Identify and select Architecture for the system using Architecture Lab Guideline. Develop bi-directional traceability matrix using form Q284 which will be used for identification of dependencies and for managing the requirement. Identify the security requirement (Refer Security Guideline)

Analyzing and validating the requirement

Analyze requirements to ensure that they are complete, feasible, realizable, and verifiable by taking QFD methodology and by defining Integration test cases. Update Requirement validation kit along with details of validation results

Preparation and Approval of Software Requirement Specification (SRS)

The Project Team prepares the SRS document as per the Template. PM shall identify the most suitable SDLC Process Performance model in order to achieve project goals. The Project team prepares the Acceptance test & take customer approval (If applicable) PM shall review and approve the SRS & Acceptance test plan and submits to the customer for sign off (If applicable)

Baseline the Document

Configuration controller shall baselines the approved SRS & acceptance test plan.Re estimation of Size

The team shall re-estimate the size of the requirements& use estimation checklist to review the estimates. PM shall use re-estimated value to calibrate the process performance model to calibrate the same.Requirement Tollgate During requirement Phase-there are two tollgate reviews

a) Tollgate 2, Phase1 (Requirement gathering),b) Tollgate 2, Phase2 (Requirement Analysis and validation)

In case the Toll Gate 2 Phase1/Phase2 is not cleared, it would be highlighted in the Prewarning dashboard.

Effort spent in Requirement Analysis Defects found during the Review No. of change request received Review Effort Rework Effort Effort spent during Requirement Tollgate

Account Manager Project Manager System Analyst Business analyst Solution Architect SQAR

SRS Document Modification of Estimation, if applicable Accepted Change request by the client Modified D&Q Plan Filled Requirement Gathering Plan Filled Requirement Validation kit Executed Requirement Engineering Tollgate Check List


Review ProcedureThe purpose of Review procedure is to define the process of planning, organizing, conducting and recording the activities related to review of a software item or product and the associated documents.

Plan for Review

PM shall

Plan for 100% peer reviews and formal inspection on selected sample (based on criticality and complexity)

Identify Work product to be reviewed in D&Q Plan

Identify and define verification method in D&Q Plan to ensure that the verification environment is available when necessary

Identify reviewers (Subject Matter Experts) for Planning, RA and Design phases.

Schedule the review meeting, select the meeting place and inform the review team.

Share review kit including, work product, checklist, or Standards etc. to the reviewers.

Preparation Phase

The reviewer(s) reviews the work product and will prepare their comments/defects, recommendations and questions on the work product to be discussed at the review meeting.

For code reviews the team would prepare project specific code review checklist.

Review of Work Product

The author will initiate the review meeting, and will clarify the issues raised by the review team member(s) on the work product.

The review team will record the review comments using Defect tracking tool Defect Tracker or client supplied tool or the review form Q205.

Review Team fills in review recommendation, other metrics and authorizes a verifier to verify closure of defects identified.

The Review Leader assigns comments / defects for closure, to the respective author(s).

The Author and the Review Team will resolve defects raised during the review.

The Author will discuss with the Review Leader to resolve the open issues (If any)

Rework Phase

The author reworks on the defect/comments of the work product as recorded in Defect Tracker or the review form Q205.

Defect Closure Phase

Author will close the review comment and share it with Review team.

The designated verifier from review team shall approve the closure of defects recorded in Defect Tracker/Q205.

Root Cause analysis of defects

The Review Leader in discussion with review team will analyze the cause of defect and complete the Defect Origin column by writing the stage / phase responsible in defect tracking tool/Q205.

Size of the product (KLOC/# of pages/no. of functions) Size and composition of the review team Preparation time per reviewer Length of the review meeting Types and number of defects found and fixed Rework effort Actual effort expended on reviews Vs. Planned Number of products reviewed Vs total number of products

Whole Organization

Review Form (Q205) Updated work product


Project Management ProcessSoftware Project Management is an umbrella activity within software engineering. It begins before any technical activities are initiated and continues throughout the definition, development and maintenance of software projects.

The purpose of this document is to describe the processes, procedures, guidelines and templates that should be followed to effectively manage a software project.

The key project management activities performed in this process areas are as follows :

Contract Review

Project initiation

Development of Plan

Planning and preparing for a phase

Task assignment and monitoring

Tracking and re-planning

Re-estimation

Metrics collection Phase end review

Project closure

Status reporting

Project failure

Effort spent in Project Management activities (Estimated Vs. Actual)

Number of Failed projects in a quarter

Account Manager

Project Manager Tower Leader

Global Delivery Head

COE Leaders

Business Excellence

D&Q Plan

SCM Plan

Metrics

Project Process Capability