velociQ201.pptx

veloci-Q 201

Chinese version of veloci-Q is available on veloci-Q site. Plan is to extend to other languages based on internal/external customer requirements.

Wipro Confidential 2

Revision History

Version(x.yy)

Date of Revision

Description of Change Reason for Change

Affected Sections Approved By

2.0 Baseline version

2.1 Incorporated review comments Review comments Estimation, Planning Vidya

2.2 Incorporated review comments Review comments Estimation Vidya

2.3 Corrections Faculty Feedback Estimation Vidya

2.4 Corrections Faculty Feedback Estimation Vidya

2.5 29-Jan-2007 Group Specific Process & QIC agenda updated Impact analysis with Veloci-Q release

Slides 51, 107

3.0 18-May-07 Core veloci-Q and elearning changes Impact analysis with Veloci-Q release

Many Vidya

3.0 22-Jun-07 No change Impact analysis with June 07 veloci-Q release; version 24.0

Nil Vidya

3.1 25-Sep-07 Customer focus, Audit process, stop shipment, contract, role transition changes

Impact analysis with Sep 07 veloci-Q release; version 25.0

Slides 45, 84, 111, 132, 138, 139, 140, 141, 146

Vidya

3.2 18-Feb-08 Veloci-Q enhancements for VDM projects (all delivery processes)PDMR freeze datePPA process outputs

Impact analysis with Jan 08 veloci-Q release; version 26.0

Slides 18, 23, 29, 49, 50, 77, 84, 86, 88, 90, 91, 93, 95, 98, 103, 104, 113, 115, 117, 125, 131, 132, 133, 135, 136, 146

Vidya

Project initiation process updated Process updation Slide 53

Project categorization updation Better clarity and introduction of new CAT D

Slide 55

Note on Chinese version of veloci-Q Introduction of Chinese version of veloci-Q

Slide 1


Revision History

Version(x.yy)

Date of Revision



4.0 19th Sept 2008

Update the quality function chart Org Change announcement

Org Structure- Quality Function Kannan S

SEPG chart removed. Key functions of SEPG/SQA is listed

Review comment from SEPG

SEPG Key Function

Removed Engineering Group responsibilities from the SEPG Key Function

Org. Change SEPG Key Functions

Tools Group Function has been updated. Introduced Tools Lab separate slide. Enhanced the TUI slides and introduced TEUI

Review comments from SEPG/TG

Added after SEPG Function slide and Process and Tech slides

Introduced Program Org. Chart and the Responsibilities of the various roles under Program

Veloci-Q Release April 2008 ver 27.0

New slides after Project Manager

Added a point on usage of Engagement Risk assessment sheet for large programs

Veloci-Q rel april Slide-30- Responding to RFP

Introduced slides on Engagement Maturity definition


New slides under Project Execution

Introduced Staff Augmentation Veloci-Q Release April 2008 ver 27.0

New slides after Engagement Maturity

Introduced Managed Services slides – Definition & Introduction to ITIL


New slides after Staff Augmentation

Introduced Vertical / Service Line Governance Veloci-Q Release April 2008 ver 27.0

New slide after Auditable / Non-auditable engagements

Introduced Program Management – CAT D slide Veloci-Q Release April 2008 ver 27.0

New slide after Vertical/Service Line Governance

Removed the definition of CAT A – D points It is included as a separate new slide as per Veloci-Q Release April 2008 ver 27.0

Project Categorization Slide


Revision History

Version(x.yy)

Date of Revision



4.0 19th Sept 2008

Revamped the Project Initiation process chart Veloci-Q Release April 2008 ver 27.0

Project Initiation Diagram Slide Kannan S

Introduced Testing LCM as a separate slide and removed the testing LCM description


LCM Coversion Projects. New slide after LCM Maintenance Pjt

All Group Specific Processes have been updated All veloci-Q releases Group Specific Processes slide

Testing models were updated under Testing Projects column and all Group Specific Processes have been updated


Selection of LCM slide

Test automation Process Model and Localization Process Model slides has been introduced as part of Testing model


New slides after Testing (QA) Process Model

Points on Closure of code review comments, analysis on the review reports modified


Engineering Process – Construction slide

Added a new slide on Code Review and embedded the Code Review checklist


After construction slide

In Code Quality metrics remove one of the column on Recommended norms for C++ Java etc,.

Based on the internal review within SEPG

Construction – Code Quality Metrics slide

Updated the mandatory metrics for all Life Cycle and introduced for Release based, Prodn etc,.

veloci-Q releases Project Management Process – Key Metrics slide

Enhanced the metrics definition for maintenance projects, Production support

Veloci-Q release Project Management Process Metrics – Maintenance Projects / Service Prod support slide

Added a new slide for definition of testing metrics Veloci-Q Release April 2008 ver 28.0

Project Management Process Metrics – Testing Projects


Revision History

Version(x.yy)

Date of Revision



4.0 19th Sept 2008

Updated the Project Plan and PDMR templates Veloci-Q release Project Management Process Planning slide and PDMR Sample slide

Kannan S

Introduced Stop Shipment points Veloci-Q Release April 2008 ver 28.0

Slide added after Project Management Process- QIC/MRM slide

The project feedback tool path modified Ecube announcement Project Management Process – Customer Focus slide

PCI checklist has been reworded as PCI Report for development, maint and testing

Veloci-Q Release April 2008 ver 27.0And ver 28.0

Project Management Process – Audit Process slide and Project Performance Analysis slide


Project Manager – Role based Training

To enable understanding of Project Management, Support and Engineering Processes in veloci-Q

To ensure delivery performance and Customer satisfaction through Process Compliance.

VelociQ-101Reviews & TestingSoftware Configuration Management

Further Trainings for Project Management role

Metrics and Basic Statistics – E-learning

Advanced project management trainings covering the topics

Estimation Methodologies Effective Project Planning & Tracking Project Scheduling Risk Management PM Analytics

Note: If you have taken up this course as part of your curriculum at PM Academy, the further trainings/assessments will be communicated to you separately

Pre-RequisitesFor veloci-Q 201

Training Objectives

Going forward…


"Achieve Customer Satisfaction by providing Defect free Products and

Services on time."

Quality Policy


Organization Quality Objectives

Do things right the first time Satisfy customer expectations Possess state of the art technology Provide cost effective services Offer quality software products and services Deliver services on time Improve product quality, increase productivity and decrease cycle time Motivate all employees to participate in software process improvement Sustain Quality System to ISO 9001 standards Sustain CMMI Level 5, ISO 20000, TL 9000, AS 9100, ISO 13485 and

Automotive Spice certifications Apply Six Sigma methodologies for continuous improvement in identified

critical business processes and identified Wipro branded Products and Services


Organization structure – Mission Quality

Jagdish Ramaswamy

Wipro Technologies Wipro Infotech

Preya Kamat Pal

FS & E-Enabling

Babu Ramanathan

EAS,TIS & Testing ServicesGanesh

Arunachala

Service Functions

Sugathan Ramasubramanian

CMT,PES,EDS,SEI,Japan &

China

S.M.Bala

Mfg, HC,E&U, ES –Enabling,

Retail, Transportation &

ServicesRajeev V.S

SQASEPG

Sugathan Ramasubramanian

Pre Sales Process

TBD

Sales Process

Bharadwaj H B

America & Europe

Bharadwaj H B

MQ Sub Functions

SQA Team

Joint CEOGirish Paranjpe

Joint CEOSuresh Vaswani

Wipro BPO

Devendra Malhotra

Wipro Way

Usha Rangarajan


SEPG / SQA - Key Functions

Software Engineering Process Group (SEPG)

Central function dedicated to co-ordinate quality related activities in the organization

Maintains the quality system- veloci-Q. Evaluates process improvement proposals

and implements them. Verifies process compliance through

mechanisms like audits and assessments. collates the metric trends across the

organization Develops process performance baselines Establishes organizational norms and

revises them on a periodic basis. Participates in external forums and is

involved in benchmarking initiatives.

Software Quality Assurance (SQA)

Identified at Vertical/Service Lines Consultancy to projects on Process and

quality Plan, organize and conduct QIC and SBU

MRM Customer satisfaction surveys are

conducted at SBU Assist in Internal Audits Train the practitioners in implementing the

quality system Review of project plan and project

performance analysis Stop the deliverable if there are critical non-

conformances Conduct surprise audits Approval of process tailoring


Where are we

PM Responsibilities, Authorities

PM Interfaces

Pre-Engagement Processes

Qualification Proposal Estimation Contract

Project Execution

Initiation Life Cycle Model Engineering Processes Project Management Processes

Planning Monitoring and Control Customer Focus Closure / PPA

Process, Techniques, Tools


Project Manager Responsibilities

Customer Interfacing & Management

At project initiation the project manager should make sure that the:• Statement of Work and the

proposal documents are reviewed.

• Estimates made and risks identified at the proposal stage are reviewed

• Contractual commitments critical to quality aspects are translated to project plans

During project execution, agreed and planned tasks are completed on time and as per the quality norms defined

Customer complaints are appropriately addressed and customer feedback sought for every execution

The project manager should also participate in pre-engagement activities, in preparing estimates and proposals

Project Execution & Management

Prepare project plan and execute the project as per the plan

• Identify appropriate Tools, Technology, Standards, Process and Guidelines

• Planning resources and Training for project team • Disaster Recovery Plan• Risk Management• Plan project configuration management• Tailoring

Allocate and monitor project activities Implementing projects such that the set

quality targets are achieved through implementation of CMMI Level 5

Ensure collection and analysis of metrics at project level and implement corrective /preventive actions based on analysis results

Plan and implement defect prevention activities at project level

Provide timely project status to TM Handle non-conforming items according

to procedures Perform project closure procedures on

completion of projects

People Management

Define clear objectives for team members

Manage team members problems & aspirations

Responsible for performance appraisals of team members

Plan trainings for team members

Reward & Appreciate good performance


Assign and monitor the tasks of the team members and Project Leaders

Authorize changes to items under configuration management

Recommend project deliverables for release Authorize training for project teams Authorize intermediate deliverables and patch

releases to client Recommend purchase of resources required for

project execution Identify Rewards and Recognition for the team

Project Manager - Authorities

Responsibilities and authorities

of a PM are defined in

Organization Structure Policy

in veloci-Q


Where are we


PM Interfaces



Project Execution





Project Manager Interfaces

Project Manager

SQAM

ExternalVendors

ProjectTeam

BDM

QC

TM SDH

Tools Consultant

Logistics

TED

Talent Transformation Customer


Roles and Responsibilities : PM interfacesTM

Prepare proposals Participate in

proposal/contract reviews Initiate project in

Organization database (SAP)

Plan and allocate human resources for projects

Approve the Plan documents (Project Plans)

Review project progress through Project Monitoring Reviews

Ensure timely delivery and quality of the product/ service

Ensure implementation of Quality Systems in project

Resolve customer complaints

Monitor quality goals Participate in Project

Performance analysis Update closure of project

in SAP Conduct performance

appraisals for PMs and review project teams performance appraisal

SQA

Review the project planReview Project Performance

Reports and update them on Project Data Bank

Provide adequate assistance to project teams in identifying and implementing new processes

Should take forward the QS changes training to the practitioners for implementing changes

QC

Co-ordinate and participate in work product reviews, configuration and test audits

Tracking of errors to closure

Maintain all review records

Prepare test plan and cases for final testing

Conduct final inspection and testing

Implement defect prevention activities

Collate quality related data and help in preparing PDMR

Obtain and analyse errors & defects, initiate corrective and preventive action

Analyse customer complaints, initiate corrective and preventive action

Stop delivery in case of quality issues

Test Lead

Assign work to test team members and monitor progress

co-ordinate preparation of test plan/design/ document, test-suite and user documentation

Report progress of test activities to the PM regularly

Ensure configuration management activities related to testing

Organise and execute code reviews for test programs

Identify and implement reusable test software

Team Members

Prepare design Code and unit test Write and modify user

documentation Build software as

assigned Code review Fix problems in code Work out a detailed

plan on the task assigned Review detailed

designs and test reports

* The above mentioned is not comprehensive list, please refer to veloci-Q for more details


Legend

Project Execution Flow – PM Role

TM initiates project in SAP

TM responsibility

PM responsibility

Project created in SAP will automatically be initiated in iPAT/eCube as Suspense

TM should close the project in SAP

On project completio

n

Project Execution Prepare Project Plan and execute the project as per the plan by

selecting appropriate life cycle model Project Monitoring, Perform metrics collection & analysis through

PDMR Defect Prevention activities, Risk management, Trainings Completion of project and release of project deliverables to customer.

Customer signoff should be obtained on deliverable Project specific feedback to be obtained from the customer Project Performance Analysis should be conducted. TM & SQA should

jointly verify & approve PPA


Program Organization Structure

Program Manager

Programs should be headed by Program ManagerIdentify one PM for every project or one PM for multiple projectsOverall management of onsite – offshore delivery for entire programPlan, Monitor and control program tasksHandle escalationsManage Customer expectationsReport Program level SLAsReview of all Wipro Deliverables


Roles and Responsibilities : Program

Business Analyst

Participate in requirements definition and analysis

Provide domain/business process leadership

Provide consultancy on domain/business process

Understanding of business processes and develop solutions

Participate in knowledge transition

Participate in client presentation for the solution part

Lead Architect

Participate in architectural boards

Provide Enterprise level architecture

Provide governance model

Provide architecture consulting

Build and Lead Architect teams

Interface with Senior Client Stakeholders

QA / Test Lead

Participate in project monitoring reviews and performance analysis

Review and approve Test Plan/Cases

Report progress of test activities to PM

Project Manager

Overall Management of the onsite-offshore delivery

Plan, monitor, control and execute project delivery tasks

Ensure compliances with Wipro and Client processes

Finalize project level SLAs with client

Review of all Wipro Deliverables

* The above mentioned is not comprehensive list, please refer to veloci-Q for more details

Onsite Manager

Single point of interface to Wipro Team

Clarifications on requirements

Obtain sign off of the final deliverables from the Customer Project Manager

Communicate the status of the project

Handle communication of change requests, review impact analysis and negotiate for sign-off

Communicate and resolve customer dependencies

Ensure availability and readiness of the environment for testing

Formation of steering committee for governance purposes

QM

Review of Project PlanReview Project

Performance AnalysisAssisting the project

teams

QC

Organize External reviewsImplement Defect

prevention activitiesParticipate in work product

reviews


Where are we


PM Interfaces



Project Execution





Pre-Engagement ProcessOverview

A lead or opportunity is identified by the sales team. This could be a new customer or opportunities from existing customers.

The lead is qualified to assess the risks in executing the engagement as a Fixed Price

Proposal preparation follows lead qualification. Estimation is carried out during proposal preparation

A detailed risk evaluation is done during the proposal stage which results in a risk score. Authority for Proposal sign off is based on Risk score and project value.

In order to get more details about the application or requirements, a study or due diligence exercise may be undertaken. This leads to a more accurate estimation and proposal

The final response to proposal document is prepared and submitted to customer.

Upon confirmation of order from customer, a formal contract to execute the project is signed with the customer.

The commitments and proposal details are handed over to the delivery team for project execution.


Fixed Price A fixed price contract between a service

provider and a customer has the following characteristics

Customer defines the scope & customer requirements are well defined

Service provider creates detailed estimates and plan based on requirements

The price is signed off contractually with terms & conditions

Wipro is responsible for project management and accountable for delivery and quality.

Team size and activity distribution not exposed to customer

A high risk/high reward option

Generic guidelines on Billing models

T&M: Time and Material In this approach customer pays for the

time spent by the outsourced team to develop the software.

Here customer is charged for additional services based on the people deployed and extensions in duration of service

Planning & monitoring transparent to the customer

Time sheets and status reports provided to customer to show progress

T&M with a cap (Periodic or monthly billing with a ceiling on the billed amount/revenue) are considered as T&M


VPre-Engagement ProcessLead Qualification

Lead Identification

New Leadsidentified by Sales Force

Proactive Proposals

By Delivery Teams

Opportunity entered in Sales Logix

Lead assigned to an RFP owner

Lead Qualification

Stage 1Carried out for new customers to assess

Financial position Capacity for annuity

business Other vertical specific

criteria

Stage 2

Carried out when value is greater than 250K USD.

Assessed for fixed price execution.


Lead Qualification done using Lead Qualification Checklist

Overall score value determines the further progress as follows :

Score Value from Qualification Checklist Approval Authority

< = 60 Technical Manager / Program Manager /Sales Support

> 60 and <= 85 Solution Delivery Head / Group Head> 85 Vertical Head

Lead QualificationDecision Matrix - FPP

NOTE: If the opportunity does not get approved for a Fixed Price execution, the opportunity for any other financial model like (T&M) for execution should be considered.


Virtual Delivery Model (VDM) refers to software development that involves teams spread across geographies; work on interdependent tasks and share responsibility of deliverables.

Some of the other acronyms used are GDD: Geographically Distributed DevelopmentGSD: Global Software Development

A note on Virtual Delivery Model (VDM)


VDM Qualification done to assess the capability of executing a project from multiple offshore locations.

VDM Qualification is done using VDM Qualification Checklist

Overall score value determines if the project could be executed from multiple offshore locations

Score Value from Qualification Checklist Approval Authority

< = 100 Technical Manager / Program Manager - Qualifies for VDM execution

> 100 and <= 200 Solution Delivery Head / Group Head is required for VDM execution

> 200 ORif there are major constraints with respect to customer approval and

SEZ/STPI regulations (first 2 rows of VDM qualification checklist are 5)

VDM is not recommended

Lead QualificationQualification for VDM execution

VDM Qualification Checklist


Where are we


PM Interfaces



Project Execution





Proposal team formed by the RFP

owner. Team could consist of

representatives of various practice,

horizontal or functional groups.

For new accounts, the Solution Delivery Head identifies the Technical Manager representative for the proposal who will provide the technical solution and the estimation for the proposal.

For a new customer, before we furnish information to the customer, a Non-Disclosure Agreement or NDA has to be signed. The Proposal Lead would send the NDA to the Business Finance Manager. The BFM would subsequently send it to Group Legal for review. On clearance from the Group Legal, the NDA is signed by the Authorized Signatory.

The BFM sends the signed NDA to the customer and obtains the customer signed copy.

• RFP/RFI/Business Case for proactive proposal

• Qualification ChecklistPrepare• Proposal• Estimate• Risk Assessment

Technical, Commercial,Legal Review

• Proposal• Risk Evaluation • Cost and effort

Estimation • Resource Loading

E-T-V-X E

T

X

V

Pre-Engagement Proposal - FPP


Pre-Engagement ProcessResponding to a RFI

Request For Information (RFI) - Customers seek more details about Wipro's service offerings and processes using a Request for Information or RFI.

The proposal lead prepares a scheduled timeline for the response and communicates the same to the proposal team. The RFI questions are assigned to specific owners / practice /horizontal/functions who are part of the proposal team.

The proposal team prepares answers to the RFI questions. The proposal lead collates all queries raised by the team and interfaces with the BDM and customer to get the necessary clarifications. The query clarifications received from customer is passed back to the proposal team.

The proposal lead collates the responses from the team and adds the executive summary. All the assumptions, issues and risks are logged in the Pre-Engagement Issues and Assumptions tracker.

The BDM reviews the RFI response document before sending it to the customer. The review should ensure completeness and accuracy on all the requirements of the RFI.


Pre-Engagement ProcessResponding to a RFP

The proposal lead prepares a schedule timeline for the response and communicates the same to the proposal team.

The proposal lead conducts a response kickoff meeting with the proposal team to discuss the approach, roles and responsibilities and the timelines. The Lead Qualification checklist is also reviewed by the team.

The proposal team studies the RFP and any other documents received from the customer to understand the scope of the opportunity and collate the questions for clarification.

The proposal lead co-ordinates with BDM and the customer in getting the queries clarified. Detailed estimates for the Effort and Resource are prepared. All assumptions and issues are logged in the Pre-engagement Issues and Assumptions tracker. BFM prepares the costing worksheet for the proposal based on the inputs provided in the estimation. The group legal representative derives the Legal Exposure rating, if the terms and conditions of the MSA are

being discussed. The proposal lead collates all the responses and adds the executive summary in response to Request For

Information. The proposal undergoes a peer review. The proposal team evaluates the risks using the Risk Evaluation Sheet and arrives at the risk score. The proposal

approval authority is decided based on the risk score. For Large Programs with annual run rate of USD 5Mn or more, the Engagement Risk Assessment Sheet is to be

prepared and made available during the SOW review. For a new account, the BDM reviews the proposal document before sending it to the customer. The review should

ensure completeness and accuracy on all the requirements of the RFP. For an existing account, the proposal is reviewed by the Technical Manager. The commercial section is reviewed

by BFM. The BDM or Technical Manager should fill the proposal review template, as applicable and send it to the owner. The proposal and all review records should be maintained by the TM


Where are we


PM Interfaces



Project Execution





Estimation Process Overview

Request for Proposal (New project)

Scope change (Re-estimation)

Estimation Process

• Understand requirements.

• Identify the following – Appropriate formal estimation

techniques to be used Project specific factors to be

considered Past project data/Best practices from

project data bank

• Compute the estimates for size, effort, cost and schedule.

• Document the assumptions made and the risks identified.

• Summarize the estimates in estimate summary form.

• The estimates are to be reviewed and approved by TM.

Estimation Worksheet

Costing Worksheet

Estimation Summary

For VDM projects, estimates for should address additional Link/ Infrastructure, resource cost and travel cost; if any.

Requirements for tools server and hardware should be identified estimated for.


Estimation ProcessProject Size Size is an absolute measure of software product. Eg. Lines of code,

number of features, etc

A size of a project is described using KLOC - Kilo Lines of Code. Function Points – External Interface files, logical tables, messages, etc

Some formal estimation techniques Work Breakdown Structure Function Points Feature Points Internet Points Domino Points UML Use Case Points


Estimation Process Some Formal Estimation Techniques Work Break Down Structure

This is a bottom up estimation technique. The project tasks are decomposed into smaller components until actual activities are defined in sufficient detail. The individual activities are estimated for effort, schedule and cost. The sum total of individual estimates gives the project estimates.

Function PointsThis estimation technique is based on estimating software by quantifying the functionality based on logical design. The number of function points are described in terms of number of number of inputs, outputs, etc. Function Points remain constant regardless who develops the software or what language the software is developed in.

Feature PointsSimilar to function points but considers the number of algorithms used in the application and slightly modifies some of the weightages used in function point estimation.

Internet PointsInternet Points are designed for estimating a web, internet, or intranet project. They are similar to function points, but with a better recognition of the types of web pages to be created.

Domino PointsThis methodology is used for software development projects using Lotus Domino development methods. It describes a system’s functionality in terms of Forms, Navigators, Pages, and Views.

UML Use Case PointsUse-Case Points are used for development projects using the Rational Unified Process. They assume that the Use-Case scenarios are defined in accordance with the Rational methodology and Rational sponsored training/literature.

Wipro developed estimation methodsFor some technology areas where there are no specified estimation techniques, Wipro has developed specific estimation methods for size estimation. For example,

Business Intelligence & Data Warehousing Method – Size UOM is Data Warehousing Unit (DWU) SAP and Oracle Apps – Delivery Unit (DU)


Estimation Process Guidelines - Estimation Technique Selection

Technology Estimation TechniqueClient Server/GUI Function PointsWeb Based Use Case/Internet Points /Function PointsEmbedded/Real time Systems/Systems Software

WBS/Feature Points

Telecom WBS/Feature Points

Mainframe WBS

Lotus Domino Domino Points

Rational Unified Process UML Use Case Points


Estimation ProcessEstimating Project Size

Effort can be computed from size using –

Productivity Norms

Constructive Cost Model (COCOMO) – Effort is estimated using the project size (in KSLOC) and a factor that is computed based on the complexity of the project.

Cost Expert – Given the project type and size as inputs, the tool estimates the effort based on quantitative models derived from a database of previous projects.

Overall Productivity NormsSystem Software 0.4 kloc/pw

Client Server 0.35 Kloc/Pw4 FP/Pw

Web based 0.4 Kloc/Pw80 LOC/Day 3.84 FP/Pw

Telecom 0.205 Kloc/pw41 LOC/Day

Mainframe 0.33 Kloc/Pw66 LOC/Day3.84 FP/Pw

CUT Productivity NormsLanguage: ASPTechnology: IISF/E: HTML, Java Script, VB Script

1.2 Kloc/Pw 240 LOC/Day FP- 5 FP/Pw

Language: JavaTechnology: NAS, F/E: HTML, JavaScript

0.55 Kloc/Pw 110 LOC/Day 4 FP/pw

Language: C 0.5 Kloc/Pw 100 LOC/Day

Language:SL1 Technology:Telecom

0.15 Kloc/Pw

COBOL/CICS/IMS 0.5 Kloc/Pw 100 LOC/Day


Estimation ProcessWork Breakdown Structure Work Break Down Structure

This is a bottom up estimation technique. The project tasks are decomposed into smaller components until actual activities are defined in sufficient detail. The individual activities are estimated for effort, schedule and cost. The sum total of individual estimates gives the project estimates.

Development of inventory system

Requirements Gathering Design CUT Testing

Module A Module B

HLD

Detailed Design

Coding

Unit Test

Peer Review

HLD Review

Detailed Design Review

Coding

Unit Test

Peer Review

Example 1 – Activity based WBS

Rework Rework


Order Management

Warehouse Management Reports Testing

Requirements Gathering

Design

Code and Unit Test

Example 2 – Functionality Based WBS

Testing

Project Management


Project Management Process – EstimationWork Breakdown Structure


Requirements Gathering Design CUT Testing

Module A Module B

HLD

Detailed Design

Coding

Unit Test

Peer Review

HLD Review

Detailed Design Review

Coding

Unit Test

Peer Review

Example 1 – Activity based WBS The activities are broken into sub-activities

which are further broken down thereby arriving at a tree structure.

The activities at each level are entered in a table. The tables are classified as

Root – Main project Activity Branch – Next Level of activities Leaf – Lowest level of activities

Each table is provided with an unique ‘Activity Table ID’.

The estimates at each level are added to arrive at the estimates at root table.

Estimates at leaf level are arrived at using the following approaches

Activity wise estimate Three Time Estimate Using conversion factors

Root

Branch

Leaf

Branch


Estimation Process WBS – Activity Wise Estimate - Example

Estimation Process(SAC Method)

Table Level:

Root/ Branch Activity Table ID: 131

Parent Activity Table ID: 13 Serial No.:

Parent Activity Description: CUT Phase

Sl. No.

Description Efforts(PD)

Sub-Activity Table ID

1 Program Specification & test case preparation

27 1311

2 Coding 60 1312

3 Review 12 1313

4 Testing 90 1314

Sum Total of Efforts for Activities 188 pd

Note: The value in the ‘Sum Total...’ row should get posted to the appropriate ‘Sl. No.’ of the ‘Parent Table ID’.The value in the ‘Efforts’ column of each row will be the value of ‘Sum Total...’ row of the table referred in ‘Sub-Activity Table ID’.

Page 1

Sub-Activities

Parent Activity Table ID: 1311 Serial No. :

Parent Activity Description: Program Specification & Test Cases Preparation

Efforts Classification:Person Days (PD) / Lines of Code (LOC) / Simple-Average-Complex (S-A-C)

Description PD / LOC / S-A-C

Value ( If Three Time Estimates is

not used)Mandatory for

S-A-C

Three Time Estimates

( Pessimistic, Optimistic & Most

Probable )

1 Program 1 S 2 pd

2 Program 2 C 10 pd

3 Program 3 C 10 pd

4 Program 4 A 5 pd

Page Total

Sum Total for the Activity 27 pdFormula for Three Time Estimate : (Pessimistic + Optimistic + 4 * Most Probable ) / 6

Page 2

S-A-C to Person Days

S A C

2 pd 5 pd 10 pd


Estimation Process WBS – Three Time Estimate - Example

Parent Activity Table ID: 411 Serial No. :

Parent Activity Description: Coding

Efforts Classification:Person Days (PD) / Lines of Code (LOC) / Simple-Average-Complex (S-A-C)

Description Three Time Estimates ( Pessimistic, Optimistic & Most Probable )

O(kloc) P(kloc) MP(kloc)

1 Program 1 1.2 1.8 1.4

2 Program 2 2 2.8 2.2

3 Program 3 2 2.4 2.2

Sum total 5.2 7 5.8for Three Time Estimate : (Pessimistic +Optimistic

+ 4 * Most Probable ) / 6 5.9 kloc

Page 2

Table Level:

Root/ Branch Activity Table ID: 41

Parent Activity Table ID: 13 Serial No.:

Parent Activity Description: CUT Phase

Sl. No.

Description Efforts(PD)

Sub-Activity Table ID

1 Program Specification & test case preparation

27 411

2 Coding 30 412

3 Review 12 413

4 Testing 90 414

Sum Total of Efforts for Activities 158 pd

Note: The value in the ‘Sum Total...’ row should get posted to the appropriate ‘Sl. No.’ of the ‘Parent Table ID’.The value in the ‘Efforts’ column of each row will be the value of ‘Sum Total...’ row of the table referred in ‘Sub-Activity Table ID’.

Page 1

LOC to Person Days(CUT Productivity Norms)

200 LOC per Day

Effort for 5.9 kloc= 29.5 days


Wipro Developed Estimation MethodsData Warehouse Unit (DWU)

A Business Intelligence & Data Warehouse project typically consists of one or more of these three major development components.

Data Warehouse Databases ETL Process Analysis and Reporting Process

Each of the above components requires a different kind of tool for its development. Hence the size a project will have multiple unit of measures based on the tool or the development component.

A standard unit of measurement for various tools and the conversion factor into a common unit of measurement has been derived. This common unit of measurement is Data Warehousing Unit (DWU).

A Data Warehousing Unit is an equated measure, arrived at, based on Wipro's own experience of executing Data Warehouse projects. It is an equated size of 1 person day of code and unit testing effort as on 1st January 2005. With this point in time as a reference, conversion factors between multiple units of measure in a Data Warehouse project with the standard Data Warehousing Unit, has been derived.


Wipro Developed Estimation MethodsEnterprise Application Integration Unit (EAIU)

A typical EAI project will have one or more of the following four major work items: Interfaces Message Transformations Business Process Model, and Adapters

The above work items are measured as: Interface Points for Interfaces Transformation Points for message transformations Modeling Points for Business Process Model, and COTS points for Adapters

A common sizing measure, Enterprise Application Integration Unit is defined to have an Enterprise Application Integration work items independent software sizing measure.

An Enterprise Application Integration Unit is an equated measure, arrived at, based on Wipro's own experience of executing Enterprise Application Integration projects. It is an equated size of 1 person day of code and unit testing effort as on 1st June 2005. With this point in time as a reference, conversion factors between multiple units of measure in an Enterprise Application Integration project with the standard Enterprise Application Integration Unit, has been derived.

1 Enterprise Application Integration Unit is equivalent to the Development and Unit test effort for An Interface having size 6 interface points OR A message transformation having size 11 Transformation points OR A process model having size 7 modeling points OR Adapters having size 4 COTS points


Estimation Process Counting Lines of Code – Points to be Considered

In case of Multiple Language, each language is counted separately Delimiters are to be use for Source Code termination While counting Source code use 'Executable Statements' and 'data definitions' Macro instructions and unique expansions are to be counted Unique reusable modules are counted separately Changed code is counted separately from new code Deleted code is counted separately Support code is counted separately from product code Test case code is counted separately from product code Do not count commentary lines or information appended to executable lines for informational purposes The following are to be counted -

Verbs or action statements, such as assignments, print commands, conditionals and loops Equations and mathematical expressions Procedure definitions Each formal parameter within a procedure Procedure labels Unexpanded macro calls Expanded macro instructions

Clearly identify and explain the specific counting rules you have selected


Estimation Process Factors – Effort Estimate

Effort DistributionTypical effort distribution for each phase of development (To be customized based on project needs)

Conventions

Re-use Code reuse Use of reusable

components Effort for

customizing reusable code/component

Productivity Norms Basic formula to calculate

effortEffort = Size / Productivity Norm

Productivity norms availability – VelociQ, Industry norms

Technology Type of technology

used Wipro’s expertise –

New technology or familiar technology

Experience/Skill level of

Team

Tools and Methodology use Effort savings due to

usage of tools Tools learning effort Tools set up effort

EFFORT ESTIMATE

Factors to be considered

RisksIncorporate suitable contingency based on risks identified

Requirement Collection & Analysis

8 -11%

Design & PS 12 - 16%

Code & Unit Test

35 – 42%

Testing 16 - 22%

Proj Mgmt 9 - 12%

1 Day 8 hours

1 week 40 hours

1 month 166.67 hours

1 month 20.8 days

1 year 2000 hours


Estimation Process Factors – Schedule Estimate

Realistic SchedulingAfter arriving at the elapsed time, based on the total effort and considering 5 days effort per week, a more realistic schedule can be worked out:

Holidays per year – Approx 9Personal leave – average 10 / employeeTraining – 10 per employee

Y = (19/12)* X, Where X is the elapsed time in months (arrived at by effort estimation, considering 5 working days per calendar week).

This factor ‘Y’ is added to ‘X’ to get the realistic schedule.

Team Related

Appraisals Team Meetings Skills Trainings Boot Camps Team Building Activities

Holidays

Personal Leave

Training

Customer Related

TeleconsV-ConsCustomer VisitsPresentationsOn-site Travel

SCHEDULE ESTIMATE


Project Management

Milestone Reviews Audits &

Assessments


Estimation Process Factors – Cost Estimate

COST ESTIMATE


Video/Teleconfer

enceCost

Costing Worksheet template available in veloci-Q is to be used to calculate cost estimate.

Communication Link

User Training

Travel Cost

Warranty Support

Effort

Acceptance Support

Effort

Software CostsHardware

Costs

Experience Level of Resources

Miscellaneous Costs


Where are we


PM Interfaces


Qualification Proposal Estimation Due Diligence, Contract, Hand Over

Project Execution





Pre-Engagement Process Due Diligence

Due Diligence is a study conducted to validate the assumptions made in preparing the proposal and to obtain more information about the applications that are in scope for outsourcing. Through this study, the needs of the Business, Technical, Process, HR, Legal and financial aspects of the outsourcing are also validated.

Due Diligence should typically be conducted after the first submission of the proposal response for the Request for Proposal and when the customer has short-listed the vendors for the bid or for an existing customer when the Statement of Work preparation is in progress.

Due Diligence is typically carried out onsite at the customer's premises and is facilitated by a questionnaire that is used to specify the information to be gathered regarding the applications.


Contract Overview

Contract - A business agreement between organization and the customer, forming the basis for project execution.

Contain the terms and conditions of services to be rendered by the organization.

Should be reviewed by technical, finance and legal group before submitting to customer.

Non-disclosure agreement signed at the start of interaction with the customer

Contract documents can be categorized asMaster ContractLetter of Intent Project Specific Contracts

TM to ensure that the PMs and the Team Members are aware of the responsibilities and obligations of the Company as specified in the Contract documents.


Contract Documents

All contract documents are to be subject to document control.Contract documents shall be retained until the Contractual obligations are fulfilled or as required by statutory obligations, whichever is later. In case of internal projects, requirements Specification approved by TM shall be treated as a Contract.

Letter of Intent (LOI) Used in absence of Master Agreement to serve as contractual documents. It is an email or letter from customer indicating acceptance of proposal. TM should raise an internal Work Order and get it approved by the Vertical

Head. It is valid for 90 days

Statement of Work (SOW) Signed for each project in the account. Includes the following –

Scope, Assumptions, Critical Dependencies, Risks Identified, Execution Plan, Environment, Project Management, Project Schedule, Deliverables, Change Control, Quality System Details, Acceptance Criteria and Acceptance Procedure, Warranty/Post Delivery Support, Service Level Agreement, Payment Milestones and other Commercial Terms

The change Management clause in SoW should consider - Definition of Minor & major changes, Cumulative impact of CRs, Impact of assumptions and out of scope elements, Delay in customer response/ deliverables, Deemed acceptance clause, Acceptance criteria

Clauses in SOW overrides MSA clauses. Specific attention should be paid to overriding clauses

Master Agreement Could be Master Business Agreement

(MBA) / Master Delivery Agreement (MDA) / Master Service Agreement (MSA) / Umbrella Agreement (UA)

Finalized at the account level. Contains negotiated general terms and

conditions Includes legal aspects like Limitation of

Liability, Indemnity, Confidentiality, IP, etc Includes commercial clauses - Payment

term, Warranty, Billing Hours, Billing Rates (optional)

Signing authority is determined by group legal

Copy of Master Contract and Contract Review Record are retained by BFM till contractual obligations are fulfilled or as required by

statutory requirements, whichever is later.


Liability Any contract gives rise to several liabilities Liability is the onus to do or not do something Liability is capped and limited to controllable activities

Damages Compensation for failure to meet any liability Direct Damages - Only liability for damages of direct nature (ie. caused as a direct result of us not

doing a required act or on doing an act not required) is acceptable to us Indirect damages – Liability for indirect damages (which arise indirectly on account of any direct

failure) is not acceptable to us. Egs. of Indirect damages – consequential, special, exemplary, punitive, lost income or profits, substitution costs, loss or harm to reputation, business interruptions, etc.

Year-on-Year Improvements/ Continuous Improvements Obligation to provide “continuous improvement” is risky Year-on-Year obligation should not be linked to financial payment All commitments on Year-on-Year improvements contractually committed should be converted to

Metrics

Over Time Billing Daily Overtime, Weekend/Holiday Over Time and On-call /24 by 7 – will require a premium billing

over normal rates

Contract Management – cont …ContractContractual Commitments


Other Billing clauses Travel for short term trips Training hours

Warranty Is an obligation for the organization to remedy a problem in workmanship for a prescribed period

at no charge Recommended warranty – 30 days Warranty in excess of 30 days – to be costed in the proposal Warranty restricted to Fixed Price engagements

Acceptance Clauses for acceptance of deliverables Have “deemed accepted” clauses to force clients to act on deliverables within a reasonable time.

Dispute Resolution Clauses for resolution of disputes – Mechanism, Jurisdiction

Contract Management – cont …ContractContractual Commitments

Note: In case of VDM projects,There should not be any prohibitory clause for multi-location delivery or restriction on delivery from any particular location.Avoid putting restrictive clause for a particular location or multiple locations for project execution. It would be better if delivery location is not specified

in MSA.Only new projects should start in new SEZ locations. The SOW date for the project should be after the STP/SEZ start date


Pre-Engagement Process Hand Over

Once the contract negotiations are completed and the customer is ready to sign the contract, the proposal details are handed over to the project delivery teams.

The proposal lead should collate all the details related to the proposal and prepare a hand-over docket. The docket includes

The customer's organization structure and contact points. Our understanding of the customer's business and their vision. A detailed note on the applications or Technology or Platforms that will be covered as part of Handover. Request for Proposal or Questionnaire or Email communications related to clarifications. Wipro response, presentations. Commitments, Concessions and assumptions made. Final version of the Estimation, Resource loading, costing sheets and Proposal. VDM Qualification checklist (if applicable)

Hand-over sessions are conducted to explain the Request for Proposal, proposal response, assumptions, schedule, questionnaire and other details of the engagement. In case of VDm projects, all location leads should participate in the handover sessions.

The project manager should revisit the assumptions and the estimates, and document his observations in the estimation summary form. In case of major discrepancies leading to a substantially different effort estimate, the same should be negotiated with the customer or approved by the Solutions Delivery Head or Vertical Head.

Project Manager should verify the assets being handed over and complete the Handover Checklist. The filled checklist should be sent to the SQA Manager and the SDH/TM. SDH/TM should approve the handover based on the checklist.

Project Execution


Where are we


PM Interfaces



Project Execution





Engagement Maturity

L1 – Staff AugmentationWipro augments the customer team by providing resources with specified skill sets and expertise

L2 – Co-Managed EngagementsWipro is responsible for portions of work within ambit of larger roadmap/team managed by customer with clear handoff points

L3 – Managed ServicesWipro owns end-to-end life cycle with contractually committed SLAs and metrics, accepts specific responsibilities and risks

L4 – ConsultingPartnering with customers to define business and IT transformational initiatives or responding to regulatory needs


Staff Augmentation Engagements

Activities include-

Resource Request and Analysis Provision of resources to client to be identified by BDM or DM Based on the resource request from client, DM to evaluate the fitment of the candidate

Contract Master Service Agreement to include a section on Staff Augmentation engagements with all

the respective mandatory clauses Engagement Initiation

Project to be initiated on SAP as Non-auditable and to be tagged as L1 engagement model Assignment details to be updated on Staff Augmentation Tracker

Resource Activity Record Resource to fill in the timesheets and submission of the status reports to the client Record of activities to be submitted on weekly bases to DM

Follow-up of Placement Staff Augmentation Engagement Metrics – Resource Fulfillment metrics and Resource

Performance metrics Close the Assignment

Engagements where Wipro deploys the resources of specified skill sets and expertise and are managed by the Customers are termed as Staff Augmentation Engagements.


“Managed Services” Definition

Outcome based agreements typically include o Business Level Agreements (BLA)/

Service Level Agreements (SLA)o Operational Level Agreements (OLA) and

underpinning contracts (UC)o Provisions for performance, security, efficiency,

accountability, response times, and relevant upgrades.

Managed Application Services include management of portfolio of any or all of

o Maintenance (typically unplanned activities such as break fix/ incident handling, enhancements)

o Support (typically planned activities such as monitoring, routine support activities, preventive maintenance) which may also include development, migration and integration and testing.

Managed IT infrastructure Services include

management of portfolio of any or all ofo Maintenance o Support and management of various IT services that are

related to infrastructure support which may include planning, design, implementation, migration of all or part of the enterprise IT infrastructure (data center, client/ desktop, help desk and connectivity/network etc.)

Outsourced management of IT Services, accepting specific responsibilities and risks, governed by outcome based agreement while delivering value to customers

MANAGED SERVICES ENGAGEMENT

Managed Application Serviceso Custom Application Management Services (includes Application

Development & Maintenance)o ERP/Packaged Implementation Serviceso Application Testing Services

(Testing & QA Application Outsourcing) o Database Administration Services

Managed Infrastructure Serviceso LAN Serviceso WAN Serviceso Storage Serviceso Desktop Serviceso Remote Network Management Serviceso Data Centre Serviceso Web and Application Hosting Serviceso Database Administration Services

Service Desk– Event based services

NOT A MANAGED SERVICES ENGAGEMENTo Small developments and maintenance projectso Standalone development, maintenance, testing, porting,

migration projects


Introduction to ITIL

ITIL - Framework IT Infrastructure Library (ITIL) was developed by CCTA (now

called OGC) for UK Govt. in 1980

By mid-1990 ITIL has been recognized as the world de-facto

standard for Service Management

ITIL focuses on providing high quality services with a specific

focus on Customer relationships

Both in service delivery and operational perspective, ITIL has a

strong relationship with ISO9000

IT Infrastructure Library (ITIL), version 2, was released in 2000

The current version 3 was released in 2007

itSMF (IT Service Management Forum) has been setup to

promote industry best practice in IT service management and

updates to ITIL

Offers certification of consultants and practitioners

Source of good practice (Integrated, process based & best

practice) in Service Management

Used by organizations worldwide to establish and improve

capabilities in service management

Offers a body of knowledge useful for achieving the standard

ISO 20000 – StandardFirst adopted as BS15000

ISO acceptance of BS15000 standards in January 2006 as ISO 20000

Provides a formal and universal standard for IT Service Management

It for organizations seeking to have their service management

capabilities audited and certified

Probably TIS’s GCC is the first to be recommended for ISO 20000

certification

Standard to be achieved and maintained

ITIL Foundation

PD 005

ISO 20000 - 2

ISO 20000 - 1

Specification for Service management

Code of Practice for SM

Management Guidance Booklet

Certification

Process Definition

ITIL Foundation

PD 005

ISO 20000 - 2

ISO 20000 - 1

Specification for Service management

Code of Practice for SM

Management Guidance Booklet

Certification

Process Definition


Why ITIL for Managed Services

The Support Problem – Reality Check Constant Fire Fighting Interrupt driven Repeat incidents / problems Over Dependency on some staff Unrecorded changes Poor quality of MIS No Processes or poor integration between

processes Low /Poor Customer Confidence No Structured customer support

ITSM - objectives Align IT services with the ever changing

needs of the business Improve the quality of IT services Reduce the long-term cost of service

provision Service Management is all about the

delivery of customer focused IT service using a process-oriented approach

Working according to ITIL helps us in being Sox compliant.

Uses CMMi and ISO 9000 best practices

Good Service management is not Rocket Science ! Its about a standard set of integrated processes for delivering a consistent service to the

business It ensures there are no misunderstandings between the service provider and customer It enables problems to be identified and fixed faster It ensures there is no duplication of information and resources

The End RESULT Reduced Costs

Improved Service Happy Customers.


Project Execution Auditable and Non-auditable Engagements

Auditable Engagements

All projects offshore or onsite where Wipro is responsible for project management

Internal projects

Non-Auditable Engagements

Onsite/ Offshore staff augmentation projects that is projects where the project management is customer's responsibility

Projects which are less than 4 weeks in duration and 1 to 2 person months of effort

All maintenance/ production support/ service projects with Team size <= 2

Consulting Assignments

All projects are tagged as auditable or non-auditable in SAP


Vertical / Service Line Governance

Category A Projects with 70% of team Size from Service Line PM should be from the service line Service line Delivery Manager should be responsible for Project Delivery SQA from service line will be responsible for the Process Quality Assurance

Category B Projects with 50 - 70% of team Size from Service Line PM will be from Vertical Vertical Delivery Manager should be responsible for project delivery, customer satisfaction and operational parameters Service line should be responsible for Product Quality SQAs from vertical will be accountable for Process Quality Assurance

Category C Teams completely staffed by verticals or shared between vertical and service line Vertical Delivery Manager should be responsible for project delivery, customer satisfaction and operational parameters SQAs from vertical will be accountable for Process Quality Assurance

Category D Engagements with related projects and the contract having an annual run rate in excess of USD 5 Mn Sub-programs under the program can be from vertical or multiple service lines Staff a Program Manager and Delivery Manager from verticals Delivery Manager will be responsible for the overall governance of the program Single SQA should be identified at the Program level


Program Management – CAT D

CAT D-PROGRAMS

Sub-Program 1 Sub-Program 2 Sub-Program n

Identity a Program Manager & Delivery Manager.Single SQA responsible for a Program

If Team Size >70%- staff Project Manager from Service Line

Engagements having an annual run rate of 5 Mn USD will qualify for a PROGRAM

Programs could be sub-divided into multiple projects which are related and achieve specific objectives

Projects could span to different technologies SDH designates a Delivery Manager and a Program

Manager Delivery Manager will be responsible for overall

governance and the success of the program Program Manager owns the Integrated Project Plan Inter-dependencies to be identified and the

dependency tracker to be updated SQA will be identified at the program level

Programs could typically be: Supplier/Vendor Management System Integration Hardware and Software

Development Large Projects involving horizontals

Integrated Project Planning and Large Program Organization structure guideline would guide the PM in Program initiation and execution


Project ExecutionProject Categorization

Development Projects

LARGE - Projects which have >= 400pw of effort

SMALL - Projects which have < 400 pw of effort

Maintenance & Support

LARGE - Projects which have team size of 20 or more and >1 year duration

SMALL - Projects which have team size < 20 or duration <= 1year

veloci-Q defines more stringent Project Management processes / Tools and Techniques for Large Projects


Project / Program Initiation Process

Receipt of PO

Initiation in SAP by TM

Engagement – Staff Aug (L1)

Engagement –Managed

Services (L3)

Engagement – Co-Managed

(L2)

Engagement – Consulting (L4)

Non-Auditable Projects

Projects <4 weeks

and 1-2 person

month of effort

Y

N

Auditable Projects

Category to be

Auditable

Effort >400 PWOR

Maint / Appln Support pjt Team Size

>=20 and >1 year duration

Follow SMALL Project Process

Follow LARGE Project Process

Y

Engagement should be flagged off based on the Engagement Maturity level

N

Internal Projects should also be considered A

CAT – BService line - accountable for Product Quality Assurance;Verticals- accountable for Project governance

CAT – Aservice line should be accountable for Project governance

CAT – CStaffed by Verticals and Horizontals where Service line owns no major effort

CAT – DPrograms

Portfolio of related projects with interdependent activities, managed together to achieve specific objectives.Verticals- accountable for governance of Programs

Maint/Prodn Support/

Service PjtTeam Size

<=2

Y

SQAM Approv

alYN

N

Y

If Annual

Run rate > 5 Mn USD

Y

N If Service

Line involve

d

70% Staffing

from Service

Line

50 - 70% Staffing

from Service

Line

Y

YY

N

N

Vertical owned projects

N


Project Initiation Process

Y

Is the PM already

Trained in E-Cube for his/her earlier

Project?

PM/SQA/TM Nominates the Project in KNET Portal for E-Cube Training and Project Initiation in E-Cube

N

Project Data in SAP and nomination details in KNet is verified and the Project is initiated in E-Cube. Project type would be Set as SUSPENSE, Logins are activated for PM/TM. Default Timesheets (via email) are enabled for the Team from next day

Mail sent to PM on Project Initiation

Training is not Required and the Project is marked for Initiation in E-

Cube

PM is expected to clear the assessment

available online. After this the Project would be marked for Initiation in

E-Cube

Project is ready for Setup and Plan in E-

Cube

PM selects valid life cycle model

A


Types of projects

Development Projects which involve Ground up development of software Feature Enhancements to existing software/applications

Application support and maintenance projects involve Bug fixing Minor enhancements Adhoc services Production support activities

Testing Projects which involve Test design and development Execution of testing Building test automation scripts and executing them

Conversion Projects which involve Database conversion Platform conversions Language Upgrades

veloci-Q provides life cycle process models for the above project types. They can be customized to address customer needs and provide a good review mechanism on process and deliverables.


Where are we


PM Interfaces



Project Execution

Initiation Life Cycle Models Engineering Processes Project Management Processes




Life Cycle ModelsDevelopment Projects


V Process model and Waterfall process model are applicable for development type of projects. Both these models expect that project requirements be clearly specified.

Projects where Requirements are evolving choose 2I process model. Here the product is built over a set of iterations and increments

The Rational Unified Process (RUP) may be used for development of new products or major enhancements to existing software products more suitable for projects following OOAD methodology. The process is well suited for projects which use the Rational suite of tools

Agile ( XP ) - eXtreme Programming as it is commonly known is a methodology that should be used for development of new products where the requirements volatility is high.

Please Note :1. Re-engineering projects should adopt development process model2. All sizeable enhancements to existing applications which are beyond 3 person months of effort should

adopt one of the above process models


Life Cycle Models Application Maintenance and Support Projects

Application Maintenance and Support ProjectsRelease based Maintenance process model caters to the needs of projects

involved in the bug fixing and minor enhancements. Bug fixes and enhancements

may have predefined SLAs, or estimate for each request or can be allocated to

releases

Production Support process model is applicable to projects, which involve

activities such as: resolving incidents, handling scheduled jobs, job cycle

monitoring, software upgrades, server support activities and enhancements for

systems which are in production.

The Service Process Model is predominantly applicable to projects where the

nature of service requests are Heterogeneous like enhancements to existing

system, analysis of problems, preparation and review of documents, Product build

Cycle and reverse engineer code.


Life Cycle Models Testing Projects

Testing Projects Testing (QA) Process Model This process model addresses pure Testing projects and will

help projects, which handle repetitive Test cycles. The projects involved in Test Design and

Test Execution can use this process model.

Test Automation Process Model is applicable to projects, which involves in only test

automation using automated test tools. This model includes automation assessment phase,

planning, design and development of automated test script.

Localization Testing Process Model is predominantly applicable to projects involved in

internationalization, translation and localization testing of products or applications.

Performance Process Model is similar to Testing (QA) model but customized to suit to the

project involved in performance testing activities

Mainframe Testing Process Model is similar to Testing (QA) process model having

customized checklists/templates/guidelines suitable to Mainframe Testing projects.


Conversion or Porting Projects The Conversion Process Model is applicable for Conversion and Porting projects in which

components of a software system are modified from one language/platform to another, while

delivering the same business or end-user functions. The projects could be doing a platform

conversion, language up gradation or database conversion

Application Transition Process Model This is a pre-cursor to the Maintenance or Production support process. A project or a set of

applications which are to be outsourced for maintenance and support undergo the Application

Transition process and then get into steady state support

Life Cycle Models contd…


These processes are introduced based on the business / technology needs of the organization. These

processes inherit the features of models like V Process model, 2I process model and tailored as per the

project needs.

Group Specific Processes

Tailored at the business level to suit the type of work done

Enhances specificity and reduces the scope of tailoring repeatedly

Meets customers requirements Enhances practitioner ownership Can be maintained at the Group Account level Group specific processes can be piloted, test run

and broad-based on approval from Quality group.

Group specific processes in veloci-Q are

Business Intelligence & Data Warehousing Process Model

Enterprise Application Integration Technology Infrastructure Services VSBU Specific Processes Enterprise Application Service Business Solutions Division Lifeline Process Model Medical Devices Specific Processes Avionics Defense & Satellite Communications Automotive Electronics Enterprise Security Services Learning Solutions

Engineering Design Services gMSBU specific processes Managed Services Portals and Content Management Semiconductor IP Solution Oracle Retail Practice Railway Applications


Selection of Life Cycle Models


Application Maintenance and Support Projects

Conversion/ Porting Projects

Service Projects

Testing Projects

KAP and Transition

Waterfall Process Model

Release based Maintenance Process Model

Conversion/ Porting Process Model

Service Process Model

Testing (QA) Process Model

Application Transition Process Model

V Process Model Production Support Process Model

Automation Test Process Model

2I Process Model XP Process Model Localization Test Process Model

Iterative Process Model

RUP Model Performance Process Model

XP Process Model Mainframe Testing Model

RUP Model

Group Specific Processes

Business Intelligence & Data Warehousing Process Model

Technology Infrastructure Services

VSBU Specific Processes

Avionics Defense & Satellite Communications

Medical Devices Specific Processes

Automotive Electronics

Enterprise Security Services

Industrial Automation and Avionics

Semiconductor IP Solution

Railway Applications

Enterprise Application Integration

Enterprise Application Service

Business Solutions Division

Learning Solutions

Engineering Design Services

gMSBU specific processess

Managed Services

Portals and Content Management

Oracle Retail Practice


Waterfall Process Model

The Waterfall Lifecycle model also known as the "classical lifecycle" or the "linear sequential model" is recommended for Small development projects.

Development progresses through analysis, design, coding, testing and maintenance phases sequentially

Requirement analysis phase begins after successful demonstration of feasibility of the project.

Design starts after requirements analysis is complete

Coding begins after the completion of design activity

Testing starts after coding is completed

System is installed after successful completion of testing


V Process Model

The V-Process model is recommended for

large development projects Small development projects

involving mission critical systems.

The salient features are: Test planning and development

is done along with the development phases of RS, FS and Design.

Acceptance planning is done during RS phase

System test plan is done during the FS phase

Integration test plan is done during the Design / Detailed Design phase


2I Process Model

2I that is iterative and incremental process model is recommended for projects where requirements are evolving and cannot be frozen at the beginning of the project

The life cycle is made up of a sequence of iterations. Each iteration has all the phases of a development project that is requirement analysis, design, construction, testing, and release.

An increment is a small and manageable part of the system (subsystem). An iteration can have multiple increments constructed in it

Thus, an increment adds functionality/subsystems to the system, while an iteration refines previous subsystems

Chose this model for • Applications Using Object Oriented

concepts • Phased Delivery • Internet and Distributed Applications • Componentization of Applications • Applications That Integrate Multiple

Systems • Applications Using Reusable

Components and Frameworks • Most important decisions, those that

involve new technologies, functionality and architecture need to be made early.


2I Process ModelLarge Projects – Mandatory Activities

Requirements Phase During requirements elicitation, VOC tool should be used to analyze requirements Sub-system level requirements should be derived and documented in RS Table review with the client is mandated for review of requirements specification. A requirements management tool should be used by the project for managing requirements

Functional Specifications Phase A functional specifications phase should be carried out after the RS phase. In this phase the requirements

should be analyzed and detailed functional specifications should be prepared. A prototype or proof of concept should be carried out to assess the technical feasibility of complex

requirements.

Architectural Design Phase Failure Mode Effect Analysis that is FMEA technique should be applied to design and design risks should

be identified and addressed. Preparation of sanity test plan and test cases for testing the core functionalities to be delivered.

Construction Phase A build coordinator should be identified for the project to the build activities. A build plan should be

prepared. After each build, appropriate code quality metrics should be analyzed and build completion report should be prepared.

After a successful build, sanity testing should be conducted. Code that has successfully completed sanity testing should be released for integration and system testing.

Integration and System Testing Phase Build should be performed on System tested code post fixing the defects logged in System testing. Sanity

testing should be conducted on completion of system testing before releasing the deliverables to the customer.


eXtreme Programming or XP as it is commonly known is a methodology is recommended for

Development of new products or major enhancements to existing software products.

Release Based maintenance projects

Salient featuresXP is a time boxed iterative, incremental methodology. Timeboxing implies start and end time of an iteration are fixed while the contents can vary. Customer decides on the priority while team decides on the effort. XP also puts increased stress on engineering discipline.XP recommends 15 core practices

XP Process Model


XP Process ModelKey Practices

Release planning game Developers and QA estimate the effort required for implementing the stories or the features. Based on the estimates, customer selects the stories that can add maximum value to the application, to be implemented in a release.

Iteration planning game Customer selects the stories for the iteration. The individual stories are broken into tasks and the task lengths are estimated by the developers.

Small and frequent releases Evolutionary delivery. Each request cycle is short with specific functionality that is added to the software, which can be used by the customer.

Simple Design Focus is on the design for that particular iteration or release instead of speculative design.

Test First Write unit test cases first and then the code to make the test pass. All unit test cases should pass before the code is checked in.

Refactoring Simplify and clean the code and design, without changing the functionality. This is also called “continuous design improvement”.

Pair programming Two programmers sit together on a computer to code. When one programmer is coding, the other termed as observer, is intended to perform real-time code review as well as think about the big picture.

Collective ownership No single owner for any piece of code. Anyone can fix any piece of code if required.

Continuous Integration Code that is checked-in to the repository is compiled and all test cases are run automatically preferably on a daily basis.

Sustainable pace A team should be able to continue working on the project forever with the same energy levels.

On-site customer Customer(s) is to be available with the development team for the complete life cycle to provide clarifications on stories.

Coding Standards Due to frequent refactoring, swapping partners in pair programming and collective code ownership, common coding standards is necessary.

Retrospectives A meeting to discuss lessons learnt and best practices from previous iterations and suitable action is identified and implemented. Metrics from the previous iteration are also analyzed as part of the retrospective. All these feed into the next iteration planning.

Daily Standups A short meeting held everyday during an iteration in which inputs from each team member on key questions – What happened yesterday? What is the plan for today? Are there any roadblocks? – Any new tasks discovered? Any lessons to share?

Metaphor Used to explain the system being developed in simple terms. Helps the team to have a common view of the project objective.


The Rational Unified Process (RUP) is primarily applicable for development of new products or major enhancements to existing software products. RUP prescribes Iterative development process and more suitable for projects following OOAD methodology .

Typically the RUP model consists of the following phases: Inception, Elaboration, Construction, Transition

The salient features of the model are:Supports projects following OOAD and

UML Provide flexibility to execute projects in

iteration It is based on the best practices of

Software Development

Rational Unified Process (RUP)


Life Cycle Model selection for Development Projects - Guidelines

Parameter Waterfall V-Process 2I XP RUP

Requirements Volatility Low Low High High Medium

Requirements Clarity High High Medium Low Medium

Development type Bespoke Bespoke / Product Product

Bespoke / Product / Feature enhancements

Bespoke

Availability of Business users Low Medium

High and tapers to Medium

MediumHigh and tapers to Medium

Criticality of the Project Low High Medium Low High

Complexity – Technical & Business Low, Low Medium, Low High, High High, Medium Medium,

High

Size Low High High Medium High

Customer Involvement through Life cycle Low Low Medium High Low


Application Maintenance & Support ProjectsApplication Transition Process Model

The first task in an application maintenance and support project is the transition of application and process knowledge from the customer or existing vendor team to Wipro team.

Wipro team will have to gain an understanding of the applications that need to be supported and the current maintenance processes followed.

The application transition model provides a systematic way for carrying out this activity.

On completion of application knowledge transition, the project should select one of the application maintenance and support process models based on the kind of support services to be provided.


Application Maintenance & Support ProjectsRelease Based Maintenance Process Model

The release based maintenance Life Cycle model is applicable for projects that work on bug fixes and enhancements of an existing application.

The salient features are - The fixes and enhancements are

made as part of planned scheduled releases.

The releases could be time boxed with scope changing based on the inflow of bugs/enhancements

The scope could be determined during the initial release planning phase and the release schedules fixed accordingly.

For Enhancements that are more than three person month effort, the PM should initiate a separate sub-project of development type.


Production Support Process Model

Production Support Process model is used for projects which involve support of a large set of applications or products on field.

The activities in such a project could be –

Resolving incidents which may or may not need code fixes

Monitoring batch cycles and jobs

Performing scheduled tasks Building enhancements.

Production Support projects are usually governed by Service Level Agreements.


Service Process Model is used for projects where the activities supported are heterogeneous in nature.

The service requests being handled are typically development activities which could be one or more non consecutive phases of the development life cycle.

The different types of services provided could be:

Code and Unit Testing Requirements Analysis Proof of Concept Tools Evaluation Benchmarking Performance Tuning Analysis and Consultancy Testing of programs Design services Document Review

Service Model should not be used when the ownership of the maintenance of a product or application lies with the support team.

Service Process Model


This process model will help projects, which handle one time testing, projects with repetitive QA cycle and Test certification projects.

Salient Features of this model are:

Test RequirementsTest Design Test Execution Release and AcceptanceSpecific templates and checklists to

capture Test Requirements and Test Development.

Quality goals and Metrics that are suitable for Testing projects.

The process can be tailored to address cases where customer has provided test suites and the project team is required to execute the tests.

Testing (QA) Process Model


This process model is for the projects involved in test automation activities only.

The salient features of this model are: ROI calculation template Questionnaire specific to

automation assessment Checklist for automation projects Specific templates to evaluate the

automation tools, to design the automation framework and to develop the automation scripts

Automation Scripting Guidelines

Test Automation Process Model


This process model is for the projects involved in localization/internationalization testing activities only.

The phases of this model are:

Internationalization Translation Localization Testing

This process model has specific templates/ checklists/ guidelines to capture localization testing requirements

Localization Process Model


Where are we


PM Interfaces



Project Execution





Engineering Process Requirements

Reviewed Contract, SOW or RFP

Requirements Process During Requirements study or elicitation, projects should use

the requirements elicitation checklist to ensure capture all types of requirements.

Requirements could be functional / non-functional. Requirements traceability should be maintained for all

requirements throughout project execution by the PM The project should budget 5% Requirements Analysis effort in

case the Requirements are supplied by the customer Usage of Requirement Management tool is mandated for large

development projects and VDM projects. The RS should include user and system requirements Operational concepts and scenario of the product to be

identified Requirements are validated using simulation, prototypes, proof

of concept where ever required etc. For VDM projects, requirements should be analyzed for

dependencies using tools like DSM to enable work partitioning to all locations.

Formal approval of RS document should be obtained from customer.

Once base-lined, changes to the Requirements are handled through change requests

• Requirement

Specification• Bi-directional

traceability matrix

Use Voice of Customer (VOC), Quality Function Deployment (QFD) techniques for capturing, prioritizing and translating customer's Critical-To-Quality (CTQ) requirements

Requirements Management tools provide the Bidirectional Traceability features. Requisite Pro, Doors, Caliber RM are some of the RM tools.

Requirement Gathering Techniques

Interviews Focus Groups Surveys Brainstorming sessions

Process – SummaryGather Organize Clarify &

consolidatePrioritizeArticulate

RequirementsResolve ConflictsValidate

Requirements


Engineering ProcessRequirements Gathering - Techniques

Interviews

Purpose:Used to learn about a particular segment. Very effective when we discover new customer segments and do not have a hypothesis as to their needs.

Advantages: Very focused Excellent for clarification &

definition of terms Can be conducted

telephonically or in person Flexibility High response rate Forms the basis for focus

group interviews

Challenges: Time consuming More costly to conduct Can be influenced by

interviewer bias Typically smaller samples Positive response bias Questions have to be well

defined

Focus Groups

Purpose:Primarily used to gather a collective point of view from several key stake holders at same time to test if a certain hypothesis concerning their needs is true.

Advantages: Very focused Excellent for clarification &

definition of terms Can be conducted with

various segments Flexibility High response rate

Challenges: Time consuming Moderate Cost Can be influenced by

moderator bias Typically smaller samples Group can be influenced

by dominant personalities

Surveys

Purpose:Often used to measure customer needs and priorities on a scale large enough to draw statistically valid information to base business decisions upon.

Advantages: Access to a large audience Getting diverse views Helps in arriving at

statistical conclusions

Challenges: Selecting the audience Framing the right

questions Getting adequate response

Brainstorming

Purpose:Used to generate, clarify,

validate and consolidate ideas.

Advantages: Very focused Lots of ideas

generated in a short time

Generates buy in as every one has contributed

Team effort

Challenges: Setting the context Setting the ground

rules Suspending judgment Final short listing of

ideas Need expert facilitator

who is good in encouraging and moderating participants


Engineering ProcessRequirements Gathering – Technique Selection

Characteristic Mail PhonePhone

AutomatedCall Back

In-PersonGroup

SessionsWritten

Electronic

Data CollectionCosts Low Moderate Moderate High Moderate Low

Time Required To Collect

High Low Medium High Medium Low

Response Data Moderate High Moderate High High High

Interviewer Bias None Moderate None High Low None

AcceptableLength Of Survey

LongShort

(Maximum15 Minutes)

MediumMedium

(Maximum 45Minutes)

LongShort (One

Screen Or Page)

Ability To Obtain Open-Ended Responses

Low Low Low High High Medium

PerceivedAnonymity

High Low High Low Moderate None


Engineering ProcessRequirements Analysis Tools

Use of VOC

VOCT can be used to better understand requirements from the customer – Both explicit and implicit requirements.

Preferably entire team should participate in capturing the requirements in VOCT.

VOCT can be used only to complex requirements which needs clarifications or more understanding.

Use of QFD

QFD can be used to measure the requirements quantitatively.

QFD will be used to prioritizing the requirements.

Based on the QFD, team can identify the CTQs

VOCT

QFD


Requirements in Integrated Project

Here RS document can be used as System Requirements Specification

Separate subsystems RS (e.g., Hardware and Software) documents may be derived from the System Requirements.

In case separate subsystem RS documents are not prepared, the documented requirements need to be classified sub-system wise.

The sub-system integration requirements need to be captured and documented.

Engineering Process Requirements

Acceptance Criteria

Acceptance criteria is part of RS It consists of

List of all deliverables Target environment of the Acceptance Test Approving authority for Acceptance Criteria External dependencies which might affect the

Acceptance Test Location where Acceptance Test is carried out

If RS is provided by customer without the acceptance criteria, then document the acceptance criteria and obtain customer signoff.

Handling User Interface related Requirements

Prototype to be planned for handling for bringing clarity on user interface requirements

Check if the interface is consistent with similar products

Verify if the navigation within the screen and between screens are good

Capture requirements related to GUI, screens, navigation, standards being followed etc.

Bi-directional Traceability Matrix

The bi-directional traceability matrix helps to trace requirements through design, code and test cases.

This document is prepared in the requirements phase The relevant sections are updated in the subsequent

phases of the project. Benefits It can be found if all the requirements have been

addressed in the design, construction and testing phases Impact of changes to requirements can be analyzed When a test case fails, all the requirements that have

failed due to this can be traced.


Engineering Process – RequirementsOperational Concepts and Scenarios

An "Operational Concept" is a general description of the way in which an entity (product, product component or project deliverable) is used or operates.

An "Operational scenario" is a description of possible sequence of events that includes the interaction of the product with its components, environment and users.

Operations scenarios are used- To evaluate requirements To design and develop the system To develop validation test cases


Engineering Process – RequirementsOperational Concepts & Scenarios: Case Study

Following are the 4 requirements for audit server module for a security product, which secures the web applications.Requirement 1: XML Configuration file updationRequirement 2: Support for email and SMS messagingRequirement 3: Case sensitiveness for all repository entity.Requirement 4: Support for third party log analysis tool (Sawmill)

Operational concepts and scenario helps in validating the requirements.

Operational concepts and scenario for the above requirements:

Requirement 11. When the audit server is

up, it should provide GUI for configuration file update.

2. After all the information is filled and submitted the changes should be automatically in the XML file.

3. The new configuration should be effective when the server restarts.

Requirement 21. When event of

specified audit level, such as “unauthorized access attempted”, occurs, an email should be sent to administrator

2. An SMS mobile message should be sent to administrator.

Requirement 3

1. Role, resources, user id etc should be case sensitive.

For example, User name Ajay & ajay should be taken as 2 different users.

Requirement 4

1. From audit server log selection screen, when log statistics button is pressed, the control should transfer to Sawmill GUI.

2. All the Sawmill GUI options of analyze logs should be available to user


Engineering Process Design

Requirement Specifications / Functional Specifications

Design Process

Design involves translating business/ functional requirements into technical solution

Develop design alternatives and document in Design Alternatives Template

Establish operating concepts and scenarios for each alternatives

Evaluate design alternatives using Pugh Matrix tool

Select the most effective designDesign can be articulated using High level

(Architectural) Design and Detailed Design( Program specification) OR Comprehensive Design that includes architectural design and Program specifications

Establish traceability from requirements to design and update Bidirectional Traceability matrix

Review Design documents using Table review method

Obtain customer approval for the design

• High Level Design document

• Detailed Design document

• Bidirectional traceability matrix

For VDM projects, critical section of design

should be developed by a team in one location and development should not be split across multiple

Table reviews of these critical sections should be done with co-located teams.

Where review team members are not co-located, collaboration tools should be used to make the review effective.


Engineering Process Design - Tools

Pugh Matrix

Technique used to evaluate design process

Provides insight to the details of requirements

Ensures requirements translation into high level design

Easy for evaluating concepts

Helps in understanding design problems

Input for DFMEA

Design Failure Mode Effective Analysis (DFMEA)

Technique used to identify risk associated with Design

Helps identify the ways in which a Design can fail to meet critical customer requirements

Lists the risk of specific causes

Identify actions to improve design

Document the rationale behind product/ process design changes

FMEAPugh Matrix


Engineering Process Construction

• Program Specification or Design documents

• Plan documents

Construction Process • Construction involves translating Design to source code

Program Specification or Design Document / Plan documents forms the basis for development of code – Inputs

While developing Source code, effective methods such as structured programming, Object oriented programming, automatic code generation, code reuse and design patterns should be used

Coding standards (veloci-Q / Customer provided) and Naming conventions to be followed

The PM should decide the scope of code review – entire code or code for critical modules.

Static analyzer tools should be used to assess compliance of code to coding standards.

Generic code review checklist should be customized

Errors found during code review should be analyzed and measures to reduce defects should be taken.

Closure of all code review comments prior to completion of cut phase / delivery

Analyse code review reports

Prepare any associated documentation (if any) such as user documentation, etc.

If any changes to the design are identified in this phase, they should be recorded in Design Implementation Changes Form. The consolidated list of changes to design should be implemented as a single change request at the end of construction phase.

For VDM projects, changes should be communicated across all locations

• Unit Test Error Log

• Unit Test Plan

• Code Review Form

• User Manual

• Unit tested and Reviewed code


Engineering Process – ConstructionCode Review

Code Review Checklist

Review the Critical module code or the complete developed code as identified in the Design document

Usage of Static Analyzer tools to assess the compliance of the code to the coding standards

High priority defects reported should be tracked to closure and maintained as part of code review records

Closure of defects forms the exit criteria for CUT Phase


Engineering Process – ConstructionCode Quality Metrics

Code quality metrics should be captured for the source code developed. When any of the metric exceeds the suggested norms, the developer should refine the code and recheck the metrics.

Tools are available for measuring the Code Quality Metrics. When the code is run through the tool, Code Quality Metrics are captured.

Refer to OTMUS (On-line Tools Monitoring Usage System) for details about the tools available for measuring Code Quality Metrics

Note: Refer veloci-Q for the latest organization norms for these metrics.

Code Quality Metric

Indicates

Cyclomatic Complexity

Indicates the complexity of the

program

Efferent Coupling Indicates the dependency of the

class on other classes

Depth in inheritance tree

Indicates the distance of the

class to the root of the inheritance

tree.

Number of methods per class

Number of methods in a class

including constructors

Number of attributes per class

Number of attributes in a class


Engineering Process – ConstructionUnit Testing

• Source Code

Unit Testing Process

Once the source code is developed, it should be unit tested. Unit test plan and test cases should be prepared.

Suitable unit testing tools should be used to reduce unit testing effort and improve test efficiency.

Test the source code to ensure actual results match the expected results – Stubs and drivers may be created if required for effective testing

Errors found during unit testing should be logged and fixed.

The unit tested code should be made available for build.

Build co-ordinator should perform the build as per build plan.

On successful completion of build, sanity testing should be performed.

After sanity testing is successfully completed, the code should be released to the testing team for integration and system testing.

• Unit Test Error Log

• Unit Test Plan

• User Manual

• Unit tested and Reviewed code

Build can be performed - During Construction phase On completion of Construction

Phase During the testing phases On Completion of each of the

testing phases Before release to the production.

During project planning, a build co-ordinator should be identified for the project

The project manager in consultation with the build co-ordinator should prepare the build plan.

The frequency of builds for Construction phase and subsequent Integration and System Testing phases should be identified in the Build Plan.

For VDM projects, build Plan should define

how builds would be done across locations.

Periodicity of location builds and a central build

The process for handling failures at both levels of build


Engineering Process – ConstructionBuild Process – Full Life Cycle Project


Engineering Process Test Development

Requirements/ Functional Specifications

Test Development Test development involves

establishing a Test approach, developing test cases, test scripts/ code

Ensure independency of test case development

Test plan involves planning for various types of testing

Test Plan captures the requirement traceability information from the input documents like RS, FS and Design

Test plan highlights the techniques, tools and assumptions used for testing and specify the Test Completion Criteria.

For VDM projects, test plans & test cases development should get aligned to modules/use cases being developed in particular location.

• Test Plan• Test Cases• Test Scripts / Code

Development Projects Unit Test Plan explains

functionalities to be tested during unit testing

The Integration Test Plan (ITP) describes the interfaces between various units that are to be tested during Integration Testing

The System Test Plan (STP) explains the features and functionalities that are to be tested during System Testing

The Acceptance Test Plan explain the features and functionalities that are to be tested during Acceptance phase

Maintenance and Conversion Projects

Maintenance Projects – individual bug fixes testing and Regression testing for major releases

Conversion Projects – Regression and Acceptance testing activities are carried out


Engineering Process Testing

• Program Specification or Design documents

• Plan documents

Testing Process Set up test data and test environment for integration and

system testing. Execute the integration and system test cases. Use

appropriate testing tools. Record the defects in test log or test report. The defects should be analyzed and fixed. The status

should be informed to the testing team. The testing team will have to retest the defects and ensure

that no additional errors are introduced into the system. At the end of integration and system testing, QC should do

a test audit and record the observations in test audit report.

TM/PM should review the test audit report and give approval for release.

Acceptance test defects reported by customer should be logged as post delivery defects or field errors and fixed.

On completion of acceptance testing, customer sign-off should be obtained.

DOE and Orthogonal Array Technique can be used for testing process

• Review • Unit Test Error Log• Unit Test Plan• Code Review• User Manual• Unit tested and

Reviewed code

Guidance can be taken from tools group for identification of appropriate testing tools.

For VDM projects, a centralized bug tracking tool such as Test Director, Bugzilla, etc is recommended for tracking testing defects.


Engineering Process Testing

Using Orthogonal Arrays for Testing The Orthogonal Array (OA) based testing is a systematic, statistical way of

testing the software Orthogonal Arrays could be applied in User Interface testing, System Testing,

Regression Testing, Configuration Testing, Performance Testing

Benefits Provides uniformly distributed coverage of

the test domain Concise test set with fewer test cases is

created All pair-wise combinations of test set created Arrives at complex combinations of all the

variables Simpler to generate and less error prone than

test sets created manually Reduces testing cycle time


Engineering Process Reviews

Document ReviewCode ready for review

Review Process Reviewer to conduct reviews to find

defects in the work product. Reviewer to categorize findings and

review details in the review form. Author to do the rework on the work

product to fix the defects. Reviewer to verify the changes made

and ensure review comments are closed,

Use automated tools wherever required for code review

Reviewed document/codeReview Form

Table Review Review process consists of two phases, Review

preparation followed by Table review. Table review follows typically Fagan's method of

inspection. Review is a planned meeting Review items to be sent in advance for

reviewers preparation Review members have assigned roles as

Reader, Reviewer, Recorder and moderator/Review Team Leader (RTL).

Reviewers come prepared with all identified issues

Review preparation effort vs review effort is a key measure which demonstrates effectiveness of reviews.

Conclusion of review recorded in Review form Defects which are identified during table review

and not during preparation are termed as phantom defects.

Mandated for RS, Plan, Design and Test plans

Peer ReviewCan be through either on-line review or one to one reviews.

One or more persons other than the author should review

Review members send their comments through mail or review form

Conducted for code and test case review

Types of reviews Table Review Peer Review

For VDM Projects,For review of critical deliverables

such as project plan, architecture, design, etc, the review team should involve representatives from all locations.

It is recommended that work products are reviewed at the location where they are developed.


Engineering Process Release

Contract, Requirements Specification, Completed work product

Release Process Product for release could be a software work product such as

intermediate deliverable or final project deliverables Work product Releases can be of the following types: In a development project Release of intermediate deliverables Patch releases Final release

In a Maintenance project Patch Releases / Individual MR release Maintenance Releases

• Review Form

Intermediate Release Releases are made during the

life cycle of the project These could be contractually

planned deliverables or releases made on request of the customers for demo or evaluation purpose

A release process should be evolved by the Project Manager for the intermediate releases

Patch Release

Post release defects fixed and released as patches in development projects

After a formal release in a maintenance projects, fixes are delivered as patches

Formal release

Any work product contractually agreed as a final deliverable should follow formal release process

A group of MRs tied to a Release date in a maintenance project – should follow Formal Release


Engineering ProcessFormal Release Process

Work Item forRelease

Pre-Release• QC ensures

• Test Audit• Config. Audit• Installability Check OK

• PM ensures• Documents are updated• Prepare Release Note• Document known bugs

Release

• Release Review team set up

• Review team reviews Test Audit and Config audit reports

• Release note should be reviewed

• Release review summary should updated

• Could be released through electronic transfer after necessary security checks

• Release Note should accompany the released work product

Release Note

Maintain release records

Update PDMR, PMR Update Release

Review summary form

Release Note

Post Release• Post Release process to be defined• Capturing of post delivery defects• Effective handling of post release

defects• Onsite/offshore release defects• Configuration Management/

Baselining• Schedule for Project Performance

Analysis

Post Release Plan

Test audit ensures that Testing is done as per Test plan & Test cases, Errors detected are resolved, log of the tests conducted is available.

Config audit ensures integrity of the work product.

In case of VDM projects, Release plan should cover

Release from a central location and / or

Release from multiple locations

Test Audits should cover all locations involved in the release


Engineering Process Maintenance Projects

Impact Analysis Impact analysis of the MRs to be

carried out Simulate the bug Identify the source of bug Identify solution – Could be a

code fix or a data fix

Regression Testing Regression test plan

should describe the test activities

Criteria for performing the test to be documented

Regression test to be carried out when access to the complete product source code is available

Test reports to be prepared

Release & Acceptance Fixes should be verified

before release MRs in the release should

have its corresponding impact analysis as part of the deliverables

Release process for individual bug fixes and major releases should be defined in Maintenance plan

Implementation Implement the changes as per impact

analysis Do code fix or data fix as per

maintenance plan

Engineering Processes for Maintenance Projects Impact Analysis Implementation Regression Testing Release & Acceptance


Where are we


PM Interfaces



Project Execution



Planning Process Overview Project Shared Vision Process Performance Model Project Metrics Definition Main & Sub Process Goals Defect Prevention Activities

Configuration Management Document Control Disaster Recovery System Administration Risk Management Process Tailoring

Metrics Collection & Analysis Project Monitoring PDMR and PMR Revenue Recognition QIC and MRM Customer Focus

Project Performance Analysis Project Closure Archival PM transition


Project Management Process – PlanningProcess Tailoring

Veloci-Q has approved set of life cycles, procedures, guidelines, templates and checklists

All the processes may not be applicable for a project. Also some processes may be required to meet project needs. This process of deviating from the approved processes is known as process tailoring.

Processes can be tailored at group or account level – Account level tailoring

Points to be considered while tailoring Requirements of the new process Adequacy of new process to meet project needs Definition of ETVX for each phase/activity

of the new process Impact of tailoring on organizational quality

requirements

Project Specific tailoring should be documented in project plan

The project specific tailoring should be reviewed by SQA and approved by TM.


Project Management Process – PlanningOVERVIEW

• Contract (SOW/MBA)

• Requirement Specifications

• Initial estimates

Planning Process

• Review contract, RS and initial estimates – In case of discrepancies get approval of client/Vertical Head

• Derive project shared vision and team charter

• Tailor the chosen project life cycle model for project needs

• Identify the risks associated with the project and arrive at mitigation and contingency plans

• Identify the methodologies, tools and techniques to be used

• Identify metrics that needs to be tracked

• Identify the configuration management activities for the project

• Identify defect prevention activities

• Identify issues that require a structured decision analysis and document them in decision tracker.

Project Plan Contents Project Overview Project Development and Target

environment Resource Plan VDM Plan (For VDM projects only) Training Plan Tools and Methodology Plan Milestone and Project Monitoring Plan Development and Quality Process plan Metrics Plan Defect Prevention Plan Configuration Management Plan Disaster Recovery Plan Back-up Details Risk Management Plan Standards and Guidelines

• Project Plan

• Project Schedule

• Risk Management Plan

• Communication Management plan

• Decision Tracker

• Master List of Documents

NOTEProject Plan is reviewed by

SQA and approved by TM

Project Plan should be approved within 3 weeks of project initiation.

Projects greater than 75pw of effort should use a planning tool such as MS Project

Projects of more than 6 months duration or having a team size above 10 should,

Conduct a project kick-off meeting - Project vision, goals and objectives must be shared.

Manage main process objectives by identifying and monitoring sub-process metrics

VDM guidelines in veloci-Q provides detailed guidelines for execution of VDM projects


Project Management Process - PlanningPre-requisites

Prior to start of Planning Activities, Project Manager should - Review the contract, requirement specifications and initial estimates

Review the initial estimate assumptions.

Estimation summary form should be revisited.

Reassess the risks identified at proposal stage. All open risks should be updated in risk plan.

Differences/Issues/Concerns, if any, should be discussed with TM and client.


Project Management ProcessDerive Project Shared Vision

Example

Vision of an ODC is “At this ODC our endeavor is to be customer’s first partner of choice through technology leadership and synergy”.

Project shared vision of a project in this ODC is “To show continuous improvement in productivity, deliver good quality and value added services in the journey towards providing turnkey solutions”.

Ensure 100% SLA Adherence for Acceptance and Resolution of Incidents

>=15% Productivity Improvement

Project Manger should

Derive project shared vision from organization shared vision

Involve team members in deriving project shared vision

Conduct kick –off meeting and share the vision, goals and objectives of the project with all the project stake holders.

Communicate the project shared vision periodically to the team to reinforce the relevance of the shared vision in performing individual and team activities and tasks.

Organization’s shared vision

Business Plan for the year

Vertical-wise Operating Plan and business targets for the year

Goals & objectives of TM

Goals & objectives of Project Manager

Organization Shared Vision

Organization’s guiding principles Mission & Values

Organization’s Shared Vision

Vertical’s G&O

Organization’s process performance baselines,

Customer Needs

Project Needs

PROJECT SHARED VISION

Sub-process performance goals

Main Process performance goals

Goals & objectives of Team


Project Management ProcessWipro’s Process Performance Model

Customer Perception

and Feedback

ratings

Schedule Deviation

Field Error Rate

Productivity

Size

Effort Deviation

Phase Containment

Defect Removal Efficiency

Team Size

Technology

Team Profile

Tools Usage

Re-use%

Requirements Volatility

Reviews

Testing

DefectDensity

Rework Effort


Project Management ProcessProject Metrics Definition

Metrics Definition Process

Main process performance metrics are derived from Project Shared Vision Customer CTQ Business objectives Organization’s process

performance baselines Process Performance Models

Sub-process metrics - Metrics that are needed to be captured to track main process performance metrics are identified

The key metrics specified for the life cycle and the sub-process metrics are the metrics that need to be tracked for the project.

The necessary data to compute the project metrics need to be captured in the project.

Establish Sub process

performance metrics

Establish Main process performance

metrics

Organisation process

performance baselines

Projects shared vision

Business

objectives

Customer CTQs

Process Performance

models

Project Specific

Quantitative Goals

PDBQFD

Contract / Customer Specific

SLA


Project Management Process Key Metrics


Mandatory Metrics Schedule Deviation Effort Deviation* Equivalent Offshore Effort Deviation (Applicable for

FPP Projects) Requirements Volatility CUT Productivity* Phase Containment Code Review Rate* Test Case Efficiency* Manual Test Case Development Productivity Manual Test Case Execution Productivity Automation Test Case Execution Productivity Test Case Coverage Defect Density Defect Removal Efficiency Unit Test Case Density ST Code Coverage % Residual defects predicted Review Effort Overall Productivity Post Delivery Defect Rate

Recommended Metrics Phantom Error Rate

Recommended Cost of Quality Metrics Appraisal Cost Preventive Cost Internal Failure Cost External Failure Cost Performance Cost Cost of Quality Cost of Poor Quality

Note 1 - Metrics Definition procedure in veloci-Q provides a detailed definition of the metrics with their formulae, data to be collected, source of data, intent and type of metrics and the units of measure

Note 2 - For VDM projects, the metrics marked with *, needs to be captured and tracked at location level and rolled up to the project level.

Conversion Projects

Mandatory Metrics Schedule Deviation Effort Deviation* Equivalent Offshore Effort Deviation Requirements Volatility Overall Productivity Conversion Productivity* Phase Containment Code Review Rate Test Case Efficiency Defect Density* Defect Removal Efficiency Post Delivery Defect Rate Unit Test Case Density ST Code Coverage % resdual defects predicted Review Effort %

Recommended Metrics Phantom Error Rate

Recommended Cost of Quality Metrics Appraisal Cost Preventive Cost Internal Failure Cost External Failure Cost Performance Cost Cost of Quality Cost of Poor Quality


Project Management Process Key Metrics

Maintenance Projects

Mandatory MetricsRelease Level: Release Schedule Deviation Backlog Reduction Percentage Post Release defect rates

Bug-Fix: Backlog management* Age of Open Bugs* Sustenance Productivity Fixes / FTE Overall Bug Fix Productivity* Not on Time Index* Rejection Index* Internal Rejection Index

Enhancements: Schedule Deviation Effort Deviation Mean Schedule Performance Defect density for Enhancements Post Delivery Defect Rate Overall Productivity

Recommended Metrics Mean time to fix Average Resolution Time

Service Projects

Common Metrics Service Not on time Index* Service Rejection Index* Defect Removal Efficiency Backlog management index

Service Specific MetricsCode & Unit Testing CUT Productivity Review Effort %age Code error rateAnalysis & Consultancy Productivity Review Effort %age Analysis error rateTesting Test Execution Productivity Test Case Coverage MR/SR/Defect Rejection Ratio MR/SR/Defect Slippage RatioDesign Service Productivity Review Effort %age Design Error Rate

Note 1 - Metrics Definition procedure in veloci-Q provides a detailed definition of the metrics with their formulae, data to be collected, source of data, intent and type of metrics and the units of measure

Note 2 - For VDM projects, the metrics marked with *, needs to be captured and tracked at location level and rolled up to the project level.

Production Support

Mandatory Metrics

Incidents / Tickets Management-

Back Log Management Index Incident / Ticket Fix Productivity Incident Rejection /Re-open index Incident Inflow rate Backlog Duration

Response and Related Norms-

Response compliance Recovery compliance Resolution compliance

Scheduled Tasks

Critical Job execution compliance

Critical Application Availability

Critical application availability

Testing Projects

Mandatory Metrics Schedule Deviation Effort Deviation*

Test Case Design/ Development Manual Test Case Development

Productivity Automated Test Scripting

Productivity Requirements Coverage Requirement Volatility % Review Effort

Test Execution Manual Test Case Execution

Productivity* Automation Test Case Execution

Productivity* Test Case Coverage* Test Case Effiectiveness* Defect Rejection Ratio Defect Slippage Ratio Defect Detection Rate Defect Detection Efficiency % Test Audit Effort

Test Automation Automation Percentage ROI on Automation

Cost of Quality Metrics for Testing Projects

Appraisal cost/Effort Preventive costs/Effort Internal Failure cost/Effort External failure cost/Effort Performance cost/effort Cost of quality Cost of poor quality


Project Management Process Metrics – Development & Conversion Projects

METRIC DEFINITION FORMULAPROJECT MANAGEMEN

T METRICS

Schedule Deviation

Difference between actual end date and planned end date expressed as % of planned duration

Effort Deviation Difference between actual effort and planned effort expressed as % of planned effort

Requirements Volatility

Ratio of requirements changed to total number of requirements expressed as %

PRODUCTIVITYMETRICS

Overall Productivity

Ratio of product size to total project effort ( Added+Modified) LOC to overall effort – includes Tool generated code and Reused lines of code

CUT Productivity(Development projects only)

Ratio of code size to effort for CUT phase( Added+Modified) LOC to CUT effort – includes Tool generated code and Reused lines of code

Conversion Productivity(Conversion projects only)

Ratio of number of modified (Converted + Added) LOC to effort in Conversion phase

(Actual End date – Planned End date) * 100Planned Duration

(Actual Effort – Planned Effort) * 100

Planned Effort

(Requirements Added + Modified + Deleted) * 100

Number of Original Requirements

Product SizeTotal Effort

Product SizeCUT Effort

Number of LOC modified

Conversion Phase Effort



METRIC DEFINITION FORMULA

PROCESS AND PRODUCT QUALITY METRICS

Phase Containment

% of defects found in a phase to total defects uncovered in the same phase and subsequent phases

Code Review Rate

Rate of code reviewed per hour

Test Case Efficiency

Ratio of test cases failed to total test cases executed expressed as %

Defect Density Ratio of total errors + defects to size of the product


Number of in-process errors found prior to release to total number of errors & defects

Post Delivery Defect Rate

Ratio of number of defects reported by the customer during acceptance testing and warranty to actual size of product delivered.

(Errors found in RS review) * 100

RS Errors found + RS defects found in all subsequent phases

LOC reviewed

Elapsed Time

(No. of test cases failed) * 100

Total no. of test cases executed

Errors + Defects

Product Size

In-Process defects * 100

(In-process defects + Post delivery defects)

Acceptance + Warranty Defects

Product Size

Note: Few sample metrics have been defined here. Refer to veloci-Q-Metrics definition procedure, for the complete list of metrics and their description



METRIC DEFINITION FORMULA

COST OF

QUALITY

METRICS

% Appraisal Cost / Effort

Ratio of sum of effort expended in first time test development, testing, reviews (RS, Design, Code) and process audits to total project effort expressed as %.

% Preventive Costs / Effort

Ratio of sum of effort expended in defect prevention, root cause analysis, quality improvement activities and technical/software engineering training to total project effort expressed as %.

% internal Failure Cost / Effort

Ratio of in-process rework effort (re-reviews, bug fix, re-test, documentation rework to total project effort expressed as %.

% External Failure Cost / Effort

Ratio of rework effort in fixing acceptance defects to total project effort expressed as %.

% Performance Cost / Effort

Ratio of sum of efforts expended in RS, design, implementation and project management effort to total project effort expressed as %.

Cost of Quality Ratio of sum of Appraisal, preventive, internal failure, external failure costs to total project effort

(Test development + Testing + Project Planning + Process Audits + Work Item Review Efforts) * 100

Total Project Effort

(Defect Prevention Activities + RCA + quality improvement activities +technical + s/w engineering training Efforts) * 100


In-Process rework effort * 100


Acceptance rework effort * 100


(RS + Design + Implementation Effort) * 100


(Appraisal + Preventive + Internal Failure + External Failure Costs)



Project Management Process Metrics – Maintenance Projects

METRIC DEFINITION FORMULARelease Level MetricsRelease Schedule Deviation

Difference between the actual end date and planned end date expressed as % of planned duration. If the release is in-progress then consider the projected end date

Backlog Reduction Percentage

Ratio of number of backlog differences between the last release and current release to the backlogs in the last release expressed as %

Bug Fix MetricsSustenanceProductivity

Ratio of number of bugs serviced with/without code fix to total effort

Overall Bug fix Productivity

Ratio of number of bugs serviced with code fix to effort spent on bugs with code fix

Not-on-time Index Ratio of number of requests not delivered on time (as per resolution time norms) to total number of requests delivered expressed as %

Rejection Index Ratio of number of requests rejected by customer to total number of requests delivered expressed as %

= (Actual (Projected) end date-Planned end date) * 100

Planned duration

Backlogs during the last release

(Backlogs during the last release - Backlogs during the current release ) *100

Number of bugs serviced with/without code fix

Total Effort

Bugs serviced with or without code fixTotal team size

(Number of requests not delivered on time) * 100

Total number of requests delivered

(Number of requests rejected) * 100Total number of requests delivered


Project Management Process Metrics – Maintenance Projects

METRIC DEFINITION FORMULAEnhancementsSchedule Deviation Difference between actual end date and

planned end date expressed as % of planned duration

Effort Deviation Difference between actual and planned effort expressed as % of planned effort

Post Delivery Defect Rate

Ratio of number of defects reported by the customer during acceptance testing and warranty to actual size of product delivered.

Overall Productivity

Ratio of enhancement size to total enhancement effort

(Actual End date – Planned End date) * 100Planned Duration

Acceptance + Warranty Defects

Product Size

Actual effort- Planned effort *100

Planned effort

Equivalent Enhancement Size

Total effort



Project Management Process Metrics – Service / Production Support Projects

METRIC DEFINITION FORMULAServiceService Not on time Index*

Ratio of no. of service requests not delivered as per time commitment to customer on time (as per resolution time norms) to total no. of SRs / MRs Delivered

Service Rejection Index*

Ratio of no. of SRs/MRs rejected by customer to total no. of SRs/MRs delivered in a given period of time expressed as %


Ratio of in-process errors found prior to release to total no. of errors and defects expressed as %

Backlog management index

Ratio of SRs delivered during the month to the SRs received during the month expressed as %

Production SupportIncident / Ticket Fix Productivity

Ratio of incidents fixed to effort for fixing

Incident Rejection /Re-open index

Ratio of rejected or re-opened incidents to the no. of incidents resolved

No. of SRs which have exceeded the committed schedules *100

Total no. of SRs delivered

No. of SRs/MRs rejected*100

Total no. of SRs/MRs delivered

No. of in-process errors found prior to release to client * 100

Total No. of error and defects found

No of SRs delivered during the month * 100

Number of SRs received during the month

No. of incidents resolved Total effort spent

No. of rejected or re-opened incidents No. of incidents resolved



Project Management Process Metrics – Testing Projects

METRIC DEFINITION FORMULAManual Test Case Development Productivity

No of Manual Test Cases Developed per person per Hour

Manual Test Case Execution Productivity

No of Manual Test Cases Executed per Person per Hour

Defect Slippage Ratio

No. of defects slipped during testing which resulted in field error, or defects raised by the customer in the same functional area

Defect Detection Efficiency

Efficiency of identifying defects over total actual effort spent till date during test execution

Defect Rejection Ratio

No. of Defects rejected by the customer out of the total Defects raised during testing

Total Number of Manual Test Cases DevelopedTotal Effort spent on Manual Test Case Design

and Development in PW or PHrs

Total no. of Manual Test Cases ExecutedTotal Effort spent for Manual Test Case

Exec. in PW or PHrs


Total number of defects rejected by customer Total

number of defects raised during testing

* 100

* 100No of Defects Reported by CustomerNo Defects raised - No of Defects rejected + No of Defects Reported by Customer

Total valid Defects capturedTotal Actual Effort for Test Execution


Project Management Process Main & Sub Process Goals – Examples Main Process Goal

10% improvement in productivity

Sub-Process Goal Identify the factors that need to be controlled to achieve the main process goal. Arrive at an action plan for achieving sub-process objectives. Conduct RCA for any deviations in sub-process goals. Implement corrective and preventive actions.

Main Process Goal Sub-Process Goals

Project Norm Action Plan

10% improvement in productivity

Increase re-use Reuse % - 10% Identification of appropriate re-usable components from Knet Design for re-use

Increase tools usage

Increase by atleast 15%

Identification of additional tools for code generation

Reduce Rework effort

10% Strengthen reviews in RS and Design phases Look Ahead Meeting in Design & CUT phases Daily build mechanisms Write scripts for automating tasks – code generation, test data setup, etc


Project Management Process Main & Sub Process Goals – Examples Main Process Goal

Post Delivery Defect Rate < 0.1 defects / KLOC

Sub-Process Goal Identify the factors that need to be controlled to achieve the main process goal. Arrive at an action plan for achieving sub-process objectives. Conduct RCA when there is a deviations in sub-process goals. Implement corrective and preventive actions.

Main Process Goal

Sub-Process Goals Project Norm Action Plan

Post Delivery Defect Rate < 0.1 defects/KLOC

Improve test case efficiency

> 20% Increase test cycles till the target test case efficiency is achieved

Increase code coverage

At-least 80% Develop additional test cases to increase code coverage while testing Use Orthogonal Arrays for test case development

Increase unit test case density

Atleast 1 UTC for 30 LOC

Increase number of test cases to enhance coverage of paths in the program code


Project Management ProcessDefect Prevention Activities

Conduct Look Ahead MeetingsPlanned Meetings that are to be conducted at the start of a phase. The following topics should be discussed

Adoption of tools and best practices from other projects Prevention of common defects

Classify & Prioritize using Pareto analysis Arrive at corrective and preventive action plans

Issues/Concerns of previous projects/phases

Identify triggers for Root Cause AnalysisTriggers could be

Deviation in project metrics Customer complaints Audits and assessment results

Conduct Root Cause Analysis Usage of fish bone diagram tool recommended.

Identify corrective and preventive actions

Track effectiveness of corrective and preventive actions in project monitoring reviews


Project Management ProcessConfiguration Management

Proposal/SOW/Contract

Project Documents/ Source Code/ Tools

Configuration Management Process

Identify Configuration Items

Use appropriate Configuration Management tools

Identify phases at which baselines are created. Create an initial baseline of all CIs at the beginning of the project.

Record baselined CIs along with version number in Baseline Record (BR).

Changes to baselined items should be subjected to Change Control process. Traceability matrix should be to be updated. CR qualification checklist should be used by all FPP projects.

The Approval authority for changes to Requirements is TM. The approval authority for all other work products changes is PM

Identify mechanism for taking back-ups of the CIs.

Captured in the “Configuration Management Plan” section of Project Plan.

Regular Configuration audits are to be performed by QC. The findings are to be recorded in Software Configuration Audit Report (SCAR).

Baseline Record (BR)

Change Control Register (CCR)

Project Plan

Software Configuration Audit Report (SCAR)

Change Request Qualification Checklist

Items that impacts the deliverables / Changes to an item that needs to be controlled are identified as Configuration Items (CI)

Configuration Items (CI) typically includes: Requirement Specification, Functional Specification, Design Documents, Code, Test Plans, Test Scripts, Installation Scripts, Reusable components, Test Cases, Test Reports and User Manuals

For VDM projects, Usage of CM tools is mandated. The CM tool should support

multisite setup with synchronizations across the locations.

The change control board should have representation from all locations. The responsibility of each location should be documented in the project plan.

Overall change management responsibility should remain with the PM.

CM audits should cover all locations


Project Management Process Document Control

Project Documents

Project Quality Records

Customer/Third Party supplied documents

Document Control Process

Classify project documents as Public Internally Restricted Confidential Very Confidential

Provide a unique document identified for all project documents. Document Identifier should be of the format <project code>/AAA-BBB.XX.YY where AAA is document type, BBB – optional field, XX.YY is version number.

Follow version control mechanism for changes to project documents

Maintain the master list of documents

Version controlled project documents

Master List of document

Document Classification Public – Non-sensitive

information available for external release. Eg. Press Note

Internally Restricted – Information available to employees, contractors & trainees. Eg – Test Plan

Confidential – Information that is sensitive within the company and available to only a group of people. Eg. Project Plan

Very Confidential – Extremely sensitive information and available to only a few named information. Eg. Team member appraisal

Version ControlDocuments initially prepared are

considered as Draft.On review, it is versioned and the version

number is incremented until it is approved. It then becomes an Approved Document.

The version number should be changed when there is a significant change. Otherwise, a revision change should be made.

Earlier document must be marked as Superseded

Master List of DocumentsAll documents used in the project

must be included in the master list of documents

Every revision of the documents must be updated in the master list of documents.

The Master List of Documents should be used to identify the latest version of the documents.

Information Classification recommendation

Very Confidential – Contracts, sales proposals, project proposals to the client, security audit results/report, top management important decisions/discussions, network configuration records, firewall rules

Confidential - All the engineering work products of project, customer provided work products, veloci Q

Internally restricted – TEDWEB, KNet, Process Database, Best Practices

Public - Newsletters, Technical Papers


Project Management ProcessDisaster Recovery

List of critical IT Systems

Contractual terms/business requirements for disaster recovery

Disaster Recovery Process

Identify critical IT systems for the project.

Classify levels of disaster Asset level failure Site level failure City level failure

Identify teams for disaster recovery Crisis Management Team System Recovery Team Restoration team

Develop recovery strategies for each level of failure and document in disaster recovery plan.

Share the disaster recovery plan with the disaster recovery teams.

For VDM projects, the disaster recovery plan should consider all locations.

Test the disaster recovery plan through mock

disasters.

Disaster Recovery Plan

Levels of Disaster Asset Level Failure Any disruption to the project due to failure of any individual IT system or asset.

Site Level FailureNon-availability of the location in which the project is running.

City Level FailureNon-availability of the city in which the project has been running at the mentioned location

Disaster Recovery Teams

Crisis Management TeamIn case of a disaster they do an initial assessment of the damage, declare a disaster and notify the concerned stakeholders.

System Recovery TeamInitiates restoration activities at recovery site. This included set up of project servers, communication link and re-install data from back-ups.

Restoration TeamDetermines what is salvageable from the disaster site with the help of central support teams. They also help in determining if the project can continue at the same site.


Project Management Process – PlanningSystem Administration

System Administration Activities

User account management

Security related activities

Capacity planning & change management

Housekeeping activities

Back up

Other activities

User Account Management Create unique IDs for users in

the project Ensure project user ID is the

same as Wipro user ID Have fixed login attempts for

users before the account gets locked

Delete project user ID when user moves to another project or resigns

Security Follow client defined security

practices Where there are no specific client

specified practices, follow Wipro’s ISMS policies

Keep system passwords in a safe place in a sealed envelope

Enable idle time-out for the system Privileged accounts (root,

administrated) should be accessed by authorized persons only

Obtain client approval for remote dial up connectivity to ODC

Monitor system logs

Capacity Planning and Change Management

Monitor system performance for capacity planning

Maintain configuration details for all system resources

Record system/software changes before and after an upgrade

OS up gradations must be adequately planned and reviewed before implementation

Housekeeping Expired system environments /

folders should be reused or deleted.

Delete temporary files, log files regularly for better utilization of disk space

Communicate the maximum storage space to all users

Back up Identify critical files for back up Determine type (full, incremental,

differential) and periodicity for back up.

Label all back up media and store in a safe place

Maintain back up and restoration log

Other Activities Protect all servers with latest

anti-virus scan engine Latest DAT (signature ) files

information should be available in central server

Log incidents related to security breaches in SIR link in TEDWEB.


Project Management Process – PlanningRisk Management

Milestone reviews

Risk Identification

Checklist

Risks identified

at proposal

stage

Past Project

data

Identify Project Risks

Evaluate, Prioritize &

Quantify Risk

Develop mitigation & contingency

plans

Continuously monitor & reassess

risks

Brainstorm with

stakeholders

Probability of & Impact

of Risk

FMEA tool

Project Monitoring

Review

Look Ahead

Meetings

Risk Management Process Identify Project Risks using

Risk Identification checklist Past project data Risks identified at proposal stage Discussions/brainstorming sessions with stakeholders VDM qualification checklist (for VDM projects)

Evaluate risk based on the probability and impact such as Cost, Schedule and Technical aspects – Usage of FMEA tool is recommended

Probability of risk is quantified as High (9), Medium (3) and Low (1). Impact is quantified as High (9), Medium (3) and Low (1).

Develop Mitigation Plan – Actions to be taken to minimize occurrence of risk.

Develop Contingency plan – Actions to be taken when risk becomes a reality

Mitigation & Contingency plans are mandatory for quantified as 27 (probability * impact).

Communicate Risks to stakeholders (Customers, affected groups)

Continuously monitor & re-assess risks Project Monitoring Reviews Milestone reviews Look Ahead Meetings


Project Management Process – PlanningProject Plan Example

Development Project Plan - Large Projects

Development Project Plan - Small Projects


Project Management Process – PlanningRevisions to Project Plan

Some of the triggers for Revisions to Project PlanScope ChangesProcess changes due to internal audits and assessmentsVeloci-Q releasesRevisions to organization normsRCA findings

Project Plan document should be version controlled. All the versions must be maintained.

Revisions impacting effort, schedule, cost and deliverables should be approved by customer.

Any revisions to the following sections of the project plan should be reviewed by SQA and approved by TM Development and quality process plan Defect Prevention Plan Metrics Plan Project Specific Tailoring


Project Management ProcessPlanning for Development/Conversion projects

Identify best practices, past project learnings and reusable components from knowledge repository.

Identify the appropriate tools & methodologies to be used.

Revisit the estimates prepared during the pre-engagement stage.

Revisit the risks identified during the pre-engagement stage and update the risk management plan if any new risks are identified.

Document the stakeholders’ information in the communication management plan.

Prepare the overall schedule using MS-Project. If a project activity is outsourced, then include Vendor/Supplier schedules.

Update training planner and tracker with the training needs for each member of the team.

Identify the disaster recovery plan and document the same.

Update decision tracker with key decisions and the rationale behind them.

Prepare the project plan. The project plan should be reviewed by SQA manager and approved by technical manager.

For Large Projects Derive the project shared vision based on the organization shared vision and the project objectives. Define the project team structure with their roles and responsibilities. The team should include:

Leads from the individual practices, if multiple technologies are involved. An architect A design team with designers A quality co-ordinator An independent testing team

Conduct a project kick-off meeting involving the key stakeholders and the project team. The project shared vision, project’s goals & objectives and the team charter should be discussed.

Based on the project shared vision and customer critical to quality parameters, main and sub-process goals should be derived. The norms and action plans to achieve the sub-process goals and consequently the main process goals should be arrived at.

A table review should be conducted to review the project plan.


Project Management ProcessPlanning for Maintenance Projects

The planning for maintenance projects are typically done during the parallel perform phase of knowledge transition.

Identify the team structure with their roles and responsibilities for steady state.

Conduct a project kick-off meeting involving the project stakeholders. The project vision, goals and objectives and team charter should be shared.

Prepare the maintenance plan and execution process document (EPD) for the project.

The maintenance plan is used for internal tracking and monitoring. It includes – Resource plan, metrics, defect prevention plan and project specific tailoring.

The Execution Process Document covers aspects that are of interest to Wipro as well as the customer. It covers – Project organization, Program governance, Processes, Customer Metrics and Service Level Agreements, Status Reporting, Release Plan and Acceptance Plan.

Identify best practices, past project learnings and reusable components from knowledge repository.

Identify project risks and update the risk management plan.

Document the stakeholders’ information in the communication management plan.

Identify the disaster recovery plan and document the same.


Document the approach for handling enhancements to the application. Enhancements less than 3 person months of effort can be treated as a maintenance request. Enhancements that exceed 3 person months of effort must follow the development life cycle.

The maintenance plan should be reviewed by SQA Manager and approved by technical manager.

At the beginning of a release cycle, the maintenance release plan should be prepared. It should include release specific details such as enhancements, bug fixes planned for the release, schedules, release level metrics and release level risk plan. A look ahead meeting should be conducted before kick-starting the release.


Project Management ProcessPlanning for Service Projects

The planning for service projects are usually starts during the parallel perform phase of knowledge transition.

Identify the team structure with their roles and responsibilities for steady state

Identify the different types of services that would be rendered and the activities to be performed for the service type.

Refer the service guidelines in veloci-Q for the comprehensive list of service types and the typical activities performed for each service type.

If the service to be provided does not fit into any of the pre-defined types then - Identify the new service type Identify the activities for the new service type

Identify best practices, past project learnings and reusable components from knowledge repository

Identify project risks and update the risk management plan

Document the stakeholders’ information in the communication management plan

Identify the disaster recovery plan and document the same

Obtain consultation from Tools group regarding the tools planned to be used in the project.


Prepare the service plan for the project.

The service plan is used for internal tracking and monitoring. It includes – Resource plan, metrics, tools plan, training plan, defect prevention plan and project specific tailoring.

The service plan should be reviewed by SQA Manager and approved by technical manager.


Project Management ProcessPlanning for Production Support Projects

The planning for production support projects are usually starts during the parallel perform phase of knowledge transition.

Identify the team structure with their roles and responsibilities for steady state. Identify the different types of services that are in scope. Identify best practices, past project learnings and reusable components from knowledge repository. Identify project risks and update the risk management plan. Document the stakeholders’ information in the communication management plan. Identify the disaster recovery plan and document the same. Obtain consultation from Tools group regarding the tools planned to be used in the project. Update decision tracker with key decisions and the rationale behind them.

Prepare the production support project plan and execution process document (EPD) for the project.

The production support project plan is used for internal tracking and monitoring. It includes – Resource plan, tools plan, training plan, metrics, defect prevention plan and project specific tailoring.

The Execution Process Document covers aspects that are of interest to Wipro as well as the customer. It covers: Definitions of the services that are in scope. Project organization, communication process, program governance should be described in the EPD. The detailed work flow for each type of activity like incident, hot fix and enhancements. The work flow should typically include end to end implementation from

receipt till delivery, implementation environment, review and testing process, release processes and client acceptance processes. Criteria for enhancements in scope of the Production Support engagement should be established. Configuration management plan and Build process. SLA as per the contract. Status reporting for customer. Commitment being made towards the process improvement should be described.

The production support project plan should be reviewed by SQA Manager and approved by technical manager.

A customer sign-off should be obtained on the Execution Process Document(EPD).


Project Management ProcessPlanning aspects for VDM ProjectsTeam Structure One senior lead should be identified for every location to take care of local issues within project team. Typical expectation of a location lead role is like a tech lead for the project where he / she should be guiding the team in terms of

Design/implementation, project management for the location and deliverables from the location.

Governance The project governance structure should facilitate communication, coordination and control aspects for a VDM projects. The approach for inter-location co-ordination, communication and escalation should be established.

Work Partitioning Work partitioning should be done keeping minimal dependencies across locations, so that communication and co-ordination overheads are

reduced. Work may be partitioned based on use cases, modules, applications, phases and technology. DSM tool should be used to identify independent blocks of work (with minimal interdependencies) and partition work accordingly. If locations are in different time zones, the time difference aspects should be taken care during capacity planning. In case the production support/24*7 support, the hand-shake mechanism between the shifts should be worked out. The integrated project plan should maintain the location details of each task. Dependencies across locations should be identified and tracked

in the MPP. Location-wise detailed work plans should be prepared and assigned to the team. Effort should be logged against the assigned work plans

regularly. PM should track effort logging on a weekly basis. Integrated MPP, defects, action log and consolidated query log should be accessible at all locations for real-time updation.

Communication The project governance structure should facilitate communication, coordination and control aspects for a VDM projects. Some of the following practices help to reduce communication gaps amongst the team and enhance transparency in the project.

Daily standup meetings between location leads Weekly location-wise status reporting Common issue tracker Real time updation of MPP task status and dependency tracker Consolidated query log


Project Management ProcessPlanning aspects for VDM Projects…contdInfrastructure / Environment Configuration management tools that support multi-site configuration management such as Clear Case, VSS anywhere, CVS is to be

budgeted for. Tools should be planned for centralized requirements management and defect tracking. PM should plan for automated daily build mechanisms and integration of work packets developed across locations. License restrictions should be checked for usage at various locations or centers. Some vendors do not allow the deployment of their licenses

at client locations. Back up of central and location specific servers should be planned A KM micro-site can be created for better collaboration. Features such as discussion boards, status lists and others can aid in knowledge

sharing.

Teaming PM should plan for weekly v-con meetings with the teams from all locations. TM/PM should plan for regular travel (Once in 2 months recommended) to other locations – The cost, logistics and communication aspects of

the travel should be planned.

Training PM should plan for project trainings for teams at all locations. The trainings could be domain, technical, mandatory trainings, etc. Use of virtual

classrooms, v-cons, desktop sharing options is recommended to enhance training effectiveness. An induction plan and knowledge transfer plan should be in place for new members joining the team & members moving out of the project.

Note: VDM guidelines in veloci-Q provides detailed guidelines for execution of VDM projects


Project Management Process Metrics Collection and Analysis

Metrics Collection Collect metrics as specified in metrics plan

Basic data to be collected for development & conversion projects are schedule, effort, defect and product size.

Basic data to be collected by maintenance & service projects are number of requests serviced, not-on-time requests, rejected requests and effort for bug fixes.

Collect all customer reported problems/ complaints and classify them as Fatal, Major, Minor and reported in PDMR.

Classify defects based on severity levels as Fatal/Major/Minor.

Consolidate the data collected in work plans, review forms, test reports, defect tracking tools, etc and report in PDMR.

PDMR needs to be frozen by 3rd calendar day of every month.

Metrics AnalysisPerform metrics analysis of the data collected, periodically to guide decisions on project activities.

Use statistical tool like control charts and trend analysis for metrics analysis.

Perform Root Cause Analysis for any deviations in metrics norms.

Document the action items in PMR and track to closure.

At the end of the project or on completion of 1 year, conduct Project Performance Analysis and document the findings in Project Performance Report.

Metrics Analysis is performed at project, account, group and organizational levels.

Data collected at projects are analyzed at various levels of the organization to review the effectiveness of quality system.Vertical Level – Quality Improvement Councils - MonthlyVertical/Group Level – Domain Management Review Meetings – Half yearlyOrganizational Level - Management Review Meetings - Yearly


Project Management Process Project Monitoring

Work Plan

Previous month PMR

Updated PDMR

Status Reports

Monitoring - Project Level Project progress against planned Effort,

schedule and cost Risk reassessment Pending change requests Defect prevention and configuration

management activities Requirement of resources Status of project specific and mandatory

trainings Critical/Outstanding issues to be

addressed by customer Status of previous PMR’s action items Effectiveness of preventive & corrective

actions Issues/Concerns to be highlighted to

senior management

Project MonitoringReport (PMR)

PDMR of all projects in the account

PMR of all projects in the account

Monitoring - Account Level Projects deviating from norm Issues/ Risks not resolved at project level Customer Complaints & Commendations Project specific customer feedback

Account Status Report (ASR)


PDMR sample

PM should allocate detailed tasks to the location leads. Location leads in turn should assign the tasks to the individual team members for execution.

Daily standup meetings with PM and location leads should be conducted. The focus of this meeting should be highlight issues and take suitable decisions/actions.

PM should ensure the team updates the effort against the assigned work plans regularly. Effort logging should be tracked on a weekly basis.

Location-wise metrics should be computed and analyzed. For any location, when any metrics deviates from the norms, suitable corrective/preventive actions should be taken.

PM should conduct weekly v-con meetings with the teams from all locations. The focus of this meeting should beASR: In case the projects in the account are spread across multiple locations, location specific risks and issues at an account level

should be addressed.

Monitoring aspects for VDM projects

Note: VDM guidelines in veloci-Q provides detailed guidelines for execution of VDM projects

PDMR - Maintenance Project

PDMR - Development Large Projects


Project Management Process PDMR and PMR

PL/PM to prepare the work plans for project activities consisting of Planned start date, end date; planned effort and assigned to.

The work plan is updated with actual data when the task is completed.

At the end of the month, PM generates Project Data & Metrics Report (PDMR) and Project Monitoring Report (PMR).

PDMR captures Quantitative data of projects like Schedule, Effort, metrics, Size & Productivity and Process & Product quality metrics

PMR captures Qualitative information of projects like lessons learnt, Risks and Concerns

PDMRs should be frozen by 3rd calendar day of every month.

TM conducts Project Monitoring Review. The updated PDMR and previous month PMR should be used for the review.

Project Plan revisions if required are identified

Corrective and preventive actions are identified if the project performance deviates significantly from the plan.

Account status report is generated for the account using PDMR and PMR of all projects in the account.


Revenue Recognition

Revenue Recognition based on Percentage of Cost (POC) completion method But considering non effort costs only about 5-10%, revenue recognition based on

ratio of efforts only Revenue Recognition separately done for onsite and offshore Revenue recognized as

Contract Value * Effort expended .[Effort expended + Bal effort to go + contingency]

Contingency percentage on balance to go same as that taken during estimation

Project Management Process PDMR – Relevance of POC – Only for FPP


Sample Profit statement ( Month 1 )Project Value Plan

Equiv offshoreConsumedtill last month

Consumed this month

Balance to go

Total projected effort

P1 1000000 400 200 40 160 400

P2 200000 80 20 20 40 80

Cost per equiv month 2000

Revenue already recognised

P1 500000

P2 50000

Revenue this month

P1 100000

P2 50000

Total revenue 150000

Cost this month

P1 80000

P2 40000

Total Cost 120000 Profits 30000

Margin 20%

Project Management Process Sample Profit Statement – Month 1


Project Value PlanEquiv offshore

Consumedtill last month

Consumed this month

Balance to go


P1 1000000 400 240 40 40 320

P2 200000 80 40 20 20 80



P1 600000

P2 100000

Revenue this month

P1 200000

P2 50000


Cost this month

P1 80000

P2 40000

Total Cost 120000 Profits 130000

Margin 52%



Project Value PlanEquiv offshore

Consumedtill last month

Consumed this month

Balance to go


P1 1000000 400 280 120 0 400

P2 200000 80 60 20 0 80



P1 800000

P2 150000

Revenue this month

P1 200000

P2 50000


Cost this month

P1 240000

P2 40000

Total Cost 280000 Profits -30000

Margin -12%



Project Management Process Customer Focus

Customer Feedback

Transactional Survey

Done at a project level Feedback is obtained from customer project

manager – At the end of the project or after a major release.

The feedback form consists of mandatory questions and customizable questions.

Customer provides quantitative feedback provided on a 7 point scale.

There is a provision to enter qualitative comments as well as suggestions/improvement areas.

For development projects – Should be obtained after a major release or at the end of the project

For maintenance projects – At lease once a year and at the time of project closure

PM should analyze the comments. Improvements should be planned and tracked to closure

Annual Survey

Rolled out across the customer base of the organization once every year.

Objective of this survey is to measure the customer satisfaction based on the expectations, assess the health of the relationship, derive strategic inputs at the account level and organization level

The customer perception on the core value proposition being delivered to them is also determined.

Administered to 3 levels of hierarchy in the customer organization – CXO, Senior level & Middle level management

Feedback obtained on a 7-point scale. Conducted by SEPG or independent third

party agency. Action plans based on Customer experience

should be identified and tracked to closure.

Project specific feedback is now part of the ecube tool http://ecube.wipro.com


Project Management Process Project Performance Analysis

Project Performance Analysis

• Actual Project performance results

• Deviation from quality & productivity goals

• Distribution of effort, defects

• Review & Test Effectiveness

• Best Practices (Tools, Technology, Process, Management, Re-Use, DP)

• Experiences, lessons learnt from the project

• Customer complaints/Commendations

• Corrective and preventive actions

• Project plan should be updated based on learning from PPA

Updated PDMR

Release documents

Post Release Plan

Project Performance Analysis should be conducted within one month after the final release.

Projects spanning for more than a year, pseudo PPA should be conducted at least once a year.

Project Performance Report

Modified PDMR, PMR

CMMi-PA rating checklist

PCI based Report (Development, Maintenance & Testing)

Decision tracker

Project feedbackFor VDM projects, During pseudo-PPA,

location-wise project performance is to be analyzed and location-specific/project level improvement action plans arrived at.

Best practices & learnings from multi-site project execution should be captured.


Project Performance Report : Sample

Microsoft Word Document


Project Management Process Project Closure

Contract

Release review records

PDMR

Post Release Plan

Project Closure process• Adhere to Post Release Plan and meet all

contractual obligations

• Obtain Customer Sign-off at the end of the Acceptance Phase

• Obtain project specific customer feedback

• Update PDMR

• Conduct Project Performance Analysis & prepare Project Performance Report

• Review and approval of PDMR and PPR by SQA and TM

• Take Disaster Recovery backup

• SAP to be updated with project closure details by TM

• SQA to upload Project Performance Report onto PDB

• Send Project files for Archival

Project Performance Analysis Report

Project Team members should update their resume in HRWEB.

TM/PM should release all team members through organizational database.


Project Management Process Archival

Project Documents

Archival process• Copy project related documents to a CD for

archival

• Typical documents for archival – Proposal, contract file, acceptance letter, minutes of important teleconferences, project plan, specification documents (RS, FS, design), test documents, approval emails, customer sign-off emails.

• Items which have customer restrictions or contractual obligations or IP rights should be retained with project team and not archived.

• List all the documents contained in the archival CD in the archival transmission note.

• Submit the archival transmission note and the archival CD to ISD.

• In case only hard copies of the document are available, they can be sent to ISD. They would be scanned and archived.

Archival transmission note

Archival CD


Project Management Process PM Transition

New PM identified

PM Transition process TM to communicate the change of PM to

client.

Existing PM should prepare the plan for transition.

Plan for transition to include Handing over of project documents Status update in the role Enabling access to project infrastructure

such as servers, etc Overlapping period Transition review and completion dates

Role based transition review checklist to be used as an input for preparing Transition plan

New PM to conduct role based audit and audit findings to be updated in transition plan.

On completion of overlapping period, supervisor to review the transition.

SQA to verify the effectiveness of transition and sign-off.

Transition Plan

Transition Review checklist

Candidate Release Checklist

Applicability

The Role transition process is applicable to critical roles like PM, TM, QC, PL/TL, SQAM


Project Management Process QIC and MRM

Meeting Level Frequency Participants AgendaMRM Wipro

TechnologiesYearly Vice Chairman, President, Vertical Heads,

Group Vertical Heads, SBU Heads, Functional Heads, SQA Managers, SEPG Head, Tools Group Head, GEO Heads

Metrics Analysis and Metrics TrendCSAT Analysis and Customer ComplaintsSix Sigma reviewAudit/Assessment findingsMetrics Norms RevisionNew Quality InitiativesNew standards, statutory/regulatory requirementsUpdates from functional groupsUnresolved issues of Domain MRM

Domain MRM

Vertical/Business Unit

Once in 6 months

Vertical Heads, Group Vertical Heads, SBU Heads, Functional Heads, SQA Managers, SEPG Head, Tools Group Head, SQA team of the vertical

Metrics Analysis CSAT Analysis and Customer ComplaintsSix Sigma reviewAudit/Assessment findingsVertical Metrics Norms RevisionIdentification of process improvementsUnresolved issues of QIC

QIC Vertical/Group Monthly Vertical Head, SBU Head, TMs, PMs, SQA team

Exceptions in project related activities Customer Complaint AnalysisSix Sigma reviewAudit/Assessment findingsReview of Training EffectivenessUpdate from SEPG and Tools groupIdentification of process improvementsPresentations on lessons learnt from closed projects and new projects initiated.Significant process deviation and process implementation issues.Escalations regarding resource requirements


Project Management Process QIC and MRM

Apart from common agenda, other quality related issues can also be discussed in QIC and MRM.

Projects are reviewed before the QIC to determine the adequacy / rigor of review and testing. Stop shipment notice could be issued to projects with inadequate review / testing rigor in the QIC.

Problems and process improvement suggestions are prioritized. Task forces are formed to work on analysis and implementation aspects.

The proceedings are minuted. The action items, person responsible and target completion date are documented to be tracked to closure.

The task force teams analyze the problem/process improvement and present recommendations.

Upon approval in the relevant forums (QIC or MRM), the recommendations are implemented.

Updations (if required) are made to the quality system.


Project Management Process Audits & Assessments - Types


Internal Quality Audit Plan

Organizational level audit is conducted by SEPG and vertical level audit is conducted by SQAM.

An audit plan consisting of audit schedule, focus areas, selected projects is prepared.

An audit team with a lead auditor is formed. The auditor should audit the assigned projects on the agreed audit date.

The audit would primarily cover key focus areas and verify compliance to the quality system/tailored project specific process.

The non conformances and observations are noted.

The auditor should prepare an audit report comprising of – Audit Coverage, NCs, Observations, Rating, Overall health status, Best Practices & Areas of improvement

The auditor could recommend stop shipment if critical non-conformances are found or review/testing rigor is inadequate in the project.

Upon receipt of audit report, the auditor should do an RCA for the NCs and identify corrective actions.

SQAM should verify NC closure and send it to SEPG for formal closure of NC.

Audit Kit

PCI Based Report (Development, Maintenance & Testing)

CMMi Rating Checklist

Audit Report

Recommendation Tracker

Internal Audit ProcessProject Management Process Audit Process

Code Quality Audits

The focus of code quality audits would be Non Functional Requirements

as applicable to the code Effectiveness of code review

process Effectiveness of unit testing

process Effectiveness of tools usage -

static analyzers, unit testing tools, code complexity measurements etc.


Project Management Process Stop Shipment

SQAM has the authority to Stop Shipment of the project deliverables for the following scenarios:

Critical or major non-conformances with adverse impact on quality of product/service delivery observed during the reviews/audits

Review / testing rigor is inadequate in the reviewed/audited projects.

Inadequate compliance to code quality assurance processes • Absence of approved coding standards or lack of adherence to coding standards• Lack of usage of static analyzers where applicable • Inadequate review & analysis of code review reports• Non-closure of code review comments prior to completion of CUT phase / delivery


Where are we


PM Interfaces



Project Execution



Planning Process Overview Project Shared Vision Process Performance Model Project Metrics Definition Main & Sub Process Goals Defect Prevention Activities

Configuration Management Document Control Disaster Recovery System Administration Risk Management Process Tailoring

Metrics Collection & Analysis Project Monitoring PDMR and PMR Revenue Recognition QIC and MRM Customer Focus

Project Performance Analysis Project Closure Archival PM transition


Tools GroupKey Functions

Tools Group Services Improved ResultsChallenges

Evaluation

Comparison

Central Tools Repository

Effective Usage Planning

Training & Tools Lab

Hand Holding

Effective Usage Tracking

Results

Effective usage resulting in quality and productivity gains

Faster tool deployment

Shorter Learning Curve

Scope based usage planning

Availability of tool at lower cost

Selection of right tool

No time to know features

Does not know what and how much to use

User needs a tool

Dexterity and higher Effort


Tools GroupTools Lab

Skill Building• Facility to enhance your skills on tools

Explore Tools• Access suitability of existing tools for your project

Open 8 x 5• Project team members can access lab facilities 8x5

Remote access• Project teams can access lab facilities from their

workstations (backbone)

License for all standards tools• All licensed tools hosted by Tools group will be

available to work on

R&D Technical Support• Tools experts available at hand for any clarification

in the Lab

Availability• Tools Lab in Chennai, Hyderabad and Bangalore

Self paced Learning• Learn software engineering tools at your own

convenience and free of cost.


Tools GroupWipro Internal Tools Development

Wiprostyle for Java

For code Perfection• Tailored to verify veloci -Q standards• Online Real time error detection• Seem less integration with ANT and

eclipse• Customizable to project specific

needs• Absolutely free

Wipro Accelerator

Design tool for accelerated development• Integrated on eclipse IDE• Single tool for both design and coding• Fully compatible with UML 1.4• Supports MOF 2.0• Code Generation• Round trip engineering• Design Documentation

Wipro Code Checker

Quality C/C++ code• Online indication of violation

Code review process integration• Rule Customization• Individual/Group level quick fix• Standalone and eclipse plug in version• Results view


PROCESS TECHNIQUES TOOLS

Project Initiation - SAP

RS & FS (Requirement) Requirement Elicitation (Voice of Customer), Requirement Prioritization (Kano Analysis)

DOORS, Requisite Pro, Caliber RM

Project Planning/Project Management

Estimation (WBS, Delphi), Sequencing (DSM), Critical Path Analysis, Risk Management Techniques

Cost Expert, MS Project, eCube, FMEA

Design OOAD, SSAD, Class Diagrams, Sequence Diagrams, Use Cases, Data Flow Diagrams etc

Rational Rose, ER Win, ER Studio, Enterprise Architect, PUGH Matrix, Tradeoff Matrix, Design FMEA

Implementation (CUT) - Purify, Dev Partner Studio, JTest & JProbe, Code Complexity Measurement Tools, Code Generation Tools (Optimal J, RRD, JBuilder, Sun One Studio, WSAD)

Test Development Orthogonal Array Test Director, Rational Test Manager

Integration Testing - Test Director, Rational Test Manager

System Testing - Test Director, Rational Test Manager, Win runner, Silk Test, Rational Robot

Release & PPA, Acceptance Testing

- -

Project Closure - eCube, SAP

Reviews Table Review, Online Review Code Review (JStyle, JTest, Code Wizard & C++ Test)

Configuration Management VSS, Clearcase, CVS, PVCS

Metrics Pareto, Fishbone, Control Charts, Hypothesis Testing, Correlation, Regression

Statistical Tools like Minitab

Process, Techniques and Tools


Tools GroupHow to Avail Tools Group Services?

Access Tools website for• List of tools, More information on tools , comparison reports, Newsletters, White papers, case studies and much more…• Domain wise/Category wise/Location wise Tools contact person

Contact tools group at [email protected]

Tools Group WebsiteLog any queries on tools

through the Tools Helpdesk

Internal Tools

Our Services

More information on Tools


CONFIDENTIAL© Copyright 2007 Wipro Ltd 169

TUI (Tools Usage Index) modelSalient Features

Tools usage Index is an indicator for measuring the tools usage in a project by looking at importance (weightage) of a specific tool, in each phase, to the scope of the project.

The tool categories , weightages and mandatory values for all project types in the TUI model is in line with the life cycle /practices.

The Project Manager would plan all the applicable tools against various categories in the “Tools plan” section of Ecube. Flexibility is requested if non tools are applicable in a mandatory category.

PM to get the tools plan approved from Tools Group. Tools Plan review from Tools Group is an independent workflow in Ecube. Once the Tools Plan is approved the Planned TUI is baselined for the project. PM to mark “Is Usage completed” as “yes” in the tracking page in Ecube when the usage of

the tool is complete for the entire project. PM to mark “Is usage completed” as “usage in progress” when the tool has been started to

use in the project. Actual Index is calculated based on the values of “Is Usage completed” entered against the

categories in the Tracking page and the scope that was defined when the tools plan was approved.



TUI ModelTools planning

•PM to plan for tools in Tools plan (which has Tools categories with different weightage and mandate ) ;post review and approval of the TP by Tools group planned Planned index gets baselined for the project.

•Planned Index =Total weight age of planned Tools /Total weight age of tools in scopei.e. Planned Index = (Sum of weightages for categories where planned =‘Yes’)/ ( Sum of weightages for categories where

Mandatory=‘Yes’+ sum of weightages forcategories where mandatory =“No” but planned = “Yes”) Sum of weightages for categories

where planned =‘Yes’ =0.10 + 0.05 + 0.15 + 0.05 + 0.05

+ 0.05 = 0.45 Sum of weightages for categories

where Mandatory=‘Yes’ =0.10 + 0.05 + 0.15 + 0.05 + 0.05

= 0.40 sum of weightages for categories

where mandatory =“No” but planned = “Yes”

=0.05 (Project Specific Tools)

Planned Index = 0.45 / (0.05 + 0.40) = 1


TUI ModelTools Tracking

In progress TUI, will account for 50% of the category weightage

Actual TUI =0.05+0.025+0.05+0.15+0.05/ 0.65 (TUI Scope) = 0.325/0.65 =0.5 or 50%

Will account for 100% of the category weightage



TEUI model creation : (Tools effective usage index) model ( applicable for only dev >400PW)

Tools Effective Usage Index is to assess how effectively the tools are used against software engineering criteria against each tool category to improve the productivity and product quality.

The individual category of tools has been given weightage as per the importance of the tool Weightage is distributed further against the software engineering criteria under each category.

Tools Effective Usage Index is an indicator for effectiveness of the actual tools usage in a project.

Actual tools usage against the software engineering criteria specified against each category to make sure all the applicable aspects/best practices of each tool are used.

TEUI is introduced for large development projects for focusing on tools usage effectiveness.



Requirements Management Tools

Wt :10

Requirements Organization

Traceability Baseline,Impact analysis and change control

SCM and repository management tools

Wt : 5

Identification, storage and management of CI with Change history for all CIs

Baseline ,Version/ change control with appropriate tagging and labeling ,Release management

Branching and merging for parallel development

Automated Build

Design and Code Generation Tools

Wt :5 Wt : 15

Automated build

Design modeling/diagrams

Code generation

Reverse engg.

Code Review Tools Unit Level performance and Memory Analysis Tools

Wt : 10 Wt : 5

Configuration of velociQ /customer approved standards

Online code review /Code review through daily OR weekly automated build

Resolution of violations till closure

Code profiling /response time

Deadlock and thread analysis

Memory profiling to identify memory leaks

Memory analysis to reduce multiple calls for memory allocationDe allocation

Unit/System/Functionality Testing Tools

Wt : 15

Test case design

Test execution

Test Defects closure

Code and test coverage

System Performance Testing Tools

Wt: 10

Response time analysis

Load and stress analysis

Debugging and Defect closure

Database Management Tools Defect Management

Wt : 10 Wt : 5

DB Design Code /query Gen.

PL/ SQL code review

Query performance tuning/optimization

Bug/Incident reporting

Bug/Incident assignment and tracking

Bug/Incident closure

Tools categories, Weight ages and S/W engineering Criteria in TEUI model

Deployment -Wt: 5

Environment set up and validation mechanism for all target deployments

Identification of dependencies and mitigation of risks due to external interfaces

Readiness for emergency fixes



Tools planning

•PM to plan for tools in Tools plan (which has Tools categories with different weightage and mandate ) ;post review and approval of the TP by Tools group planned index gets baselined for the project.

•Planned Index =Total weight age of planned Tools /Total weight age of tools in scopei.e. Planned Index = (Sum of weightages for categories where planned =‘Yes’)/ ( Sum of weightages for categories where

Mandatory=‘Yes’+ sum of weightages forcategories where mandatory =“No” but planned = “Yes”) Sum of weightages for categories

where planned =‘Yes’ =0.10 + 0.05 + 0.15 + 0.05 + 0.05

+ 0.05 = 0.45 Sum of weightages for categories

where Mandatory=‘Yes’ =0.10 + 0.05 + 0.15 + 0.05 + 0.05

= 0.40 sum of weightages for categories

where mandatory =“No” but planned = “Yes”

=0.05 (Project Specific Tools)

Planned Index = 0.45 / (0.05 + 0.40) = 1



Tools tracking section from Ecube with same example continued:

In this case PM has marked Usage completed = “Yes” for two categories.Tools Group will provide rating for these two categories.

Tools tracking by PM (Continued)



Guidelines to PMs for marking “Is usage complete” = yes

Is Usage completed marked as When to mark

Usage in progress Starting usage of the tool

Yes on completion of usage of at least one software engineering criteria against the tool category for a module /project/ iteration.

TEUI ModelTools Tracking



Actual Index = (0.03+0+0+0.01+0.015+0+0.015)/0.45 (TUI Scope) =0.07/0.45 = 0.156 (Approx 16%)

The Tool Category Prime would mark “to be revisited” if the Tool has been used partially either with respect to the features of the tool or the usage of the tool in the project.

TEUI ModelTools usage rating by Tools group

Thank You

velociQ201.pptx

Documents

annual run

parent table

daily standup

activity table

month p1 p2

equiv month

staff augmentation

3rd calendar