iup process description 1.0 en

8/14/2019 IUP Process Description 1.0 En

1/24

Quality Management System

Confidential TL-CO-PO 0.4

IVC Unified ProcessIUP-PD

Version: 1.0

Issued Status: Draft

Issued Date:

Owner: IUP Process Team

Author: Pham Thi Phuong Lan

Location: CMMI-L3 Repository

Confidential Class: IVC Confidential

Date:

Approved by: Takeda Yoichi

Signature:


2/24

Quality Management System Code: IUP-PD

Issued Date: IVC Unified Process

Version: 1.0

Copyright ISB Vietnam Corporation.(IVC)

IUP-Process Description 1.0-EN.doc

Confidential

Page i

Review Information

Reviewer Name Role Required / Suggested Comment

Phuong Dao Technical Manager Required

Sang Tan Project Manager Required

Tuan Nguyen Project Manager Required

Tam Nguyen Project Leader Required

Approval Information

Approver Name RoleDate

(mm-dd-yyyy)Revision Comment

Sang Tan SPI Head

Takeda Yoichi Managing Director 1.0 Final approval

Revision History

RevisionDate

(mm-dd-yyyy) Description Revised byReviewer

Date(mm-dd-yyyy)

0.1 03-06-2007 First Version Lan Pham Phuong Dao,

Sang Tan,

Tuan Nguyen,Tam Nguyen

03-26-2007

0.2 03-27-2007 - Add essential activityImplement prototypes for thesystem into part 3.2.4 ofDefinition Phase.

- Update introduction text in allphases to focus on their primarygoals.

- Update part 5.2 Individual rolesto separate Team Lead in projectand Leader at company-level.

- Add some notes into part 5.3Team Structure for guidanceclearly on structure.

- Add part 5.4 Staffing Rules forguidance on how to staffmembers into a project.

Lan Pham Phuong Dao,

Sang Tan,

Tuan Nguyen,

Tam Nguyen,

Duy Truong

0.3 08-30-2007 - Modify IUP overview flow

- Modify [5. Project TeamStructure]

Lan Pham

1.0 First approval


3/24



Version: 1.0



Confidential

Page ii

TABLE OF CONTENT1 Introduction.........................................................................................................................................1

1.1 Purpose .......................................................................................................................................11.2 Scope ..........................................................................................................................................11.3 Acronyms & Abbreviations ..........................................................................................................11.4 Definitions....................................................................................................................................11.5 References ..................................................................................................................................21.6 Templates / Forms ......................................................................................................................2

2 IUP Overview.......................................................................................................................................33 IUP Lifecycle .......................................................................................................................................5

3.1 Phase: Initiation...........................................................................................................................53.1.1 Objectives.......................................................................................................................53.1.2 Entry Criteria ..................................................................................................................53.1.3 Input ...............................................................................................................................63.1.4 Output.............................................................................................................................63.1.5 Exit Criteria.....................................................................................................................63.1.6 Flow of Activities ............................................................................................................63.1.7 Essential Activities .........................................................................................................8

3.2 Phase: Definition .........................................................................................................................83.2.1 Objectives.......................................................................................................................83.2.2 Entry Criteria ..................................................................................................................83.2.3 Input ...............................................................................................................................83.2.4 Output.............................................................................................................................83.2.5 Exit Criteria.....................................................................................................................93.2.6 Flow of Activities ............................................................................................................93.2.7 Essential Activities .......................................................................................................11

3.3 Phase: Execution ......................................................................................................................113.3.1 Objectives.....................................................................................................................113.3.2 Entry Criteria ................................................................................................................113.3.3 Input .............................................................................................................................113.3.4 Output...........................................................................................................................113.3.5 Exit Criteria...................................................................................................................123.3.6 Flow of Activities ..........................................................................................................123.3.7 Essential Activities .......................................................................................................143.4 Phase: Transition ......................................................................................................................143.4.1 Objectives.....................................................................................................................143.4.2 Entry Criteria ................................................................................................................143.4.3 Input .............................................................................................................................143.4.4 Output...........................................................................................................................143.4.5 Exit Criteria...................................................................................................................143.4.6 Flow of Activities ..........................................................................................................143.4.7 Essential Activities .......................................................................................................16

3.5 Phase: Retirement ....................................................................................................................163.5.1 Objectives.....................................................................................................................163.5.2 Entry Criteria ................................................................................................................163.5.3 Input .............................................................................................................................163.5.4 Output...........................................................................................................................16


4/24



Version: 1.0



Confidential

Page iii

3.5.5 Exit Criteria...................................................................................................................163.5.6 Flow of Activities ..........................................................................................................163.5.7 Essential Activities .......................................................................................................17

4 Software Project Types & Sizes......................................................................................................184.1 Project Types ............................................................................................................................184.1.1 New application development ......................................................................................18

4.1.2 Enhancement / Upgrading ...........................................................................................184.2 Project Sizes .............................................................................................................................18

5 Roles & Team Structure in IUP .......................................................................................................185.1 Team roles ................................................................................................................................185.2 Individual roles ..........................................................................................................................195.3 Team Structure..........................................................................................................................195.4 Staffing Rules............................................................................................................................20

TABLE OF FIGURESFigure 1. Phases and Iterations...................................................................................................................1Figure 2. IVC Unified Process Overview .....................................................................................................3Figure 3. IUP Lifecycle.................................................................................................................................5Figure 4. Initiation Phase Overview.............................................................................................................7Figure 5. Definition Phase Overview .........................................................................................................10Figure 6. Execution Phase Overview ........................................................................................................13Figure 7. Transition Phase Overview ........................................................................................................15Figure 8. Retirement Phase Overview.......................................................................................................17Figure 9. Team Structure...........................................................................................................................20


5/24



Version: 1.0



Confidential

Page 1/13

1 Introduction

1.1 Purpose

This document describes the overview of unified process that is used as standard process forsoftware development to all the software projects in IVC, hereafter called IUP IVC Unified Process.

The reader can find here how to use the processes in combination during the whole SoftwareDevelopment Life Cycle. Besides, project types and project team structure are also defined in thisdocument.

1.2 Scope

IUP is applied to all internal and external software projects in IVC.

1.3 Acronyms & Abbreviations

No. Acronyms Description

1 QA Quality Assurance

2 QC Quality Control

3 SQA Software Quality Assurance

1.4 Definitions

Baseline: a reviewed and approved release of artifacts that constitutes an agree basis for furtherevolution or development that can be changed only through a formal procedure, such asConfiguration and Change Management.

Iteration: is a distinct sequence of activities with a baselined plan and valuation criteria resulting in arelease (internal or external). See Figure 1 for example.

Quality Gate: is the check-point at phase-end to decide to move or not move to next phase.

Milestone: is the point at which an iteration formally ends, correspond to a release point.

Phase: is a period of time between two major project milestones, during which a well-defined set ofactivities is met, work product are completed, and decisions are made to move or not move into thenext phase. A phase consists of a set of discipline-based activities those are combined variousproportions, depending on its characteristics and objectives.

Figure 1. Phases and Iterations

Release: a subset of end-product that is the object of evaluation at a major milestone. A release is astable, executable version of product, together with any artifacts necessary to use this release, suchas release notes or installation instruction, manuals. A release can be internal or external. Aninternal release is used only by the development organization, as part of a milestone, or for a

demonstration to customers or users. An external release (or delivery) is delivered to end-users. Arelease is not necessary a complete product, but can just be a part of it.

Retirement

E1

Initiation Definition Execution Transition

Iterations

Phases

I1 D1 D2 E2 E3 T1 T2

Gate Milestone

R1


6/24



Version: 1.0



Confidential

Page 2/13

Discipline: is a collection of related activities that are related to a major 'area of concern'. Thedisciplines mentioned here are also the processes such as Project Management process,Requirement Development process.

1.5 References

Rational Unified Process (RUP), Version 2003.06.12.01

Project Management process, version 1.0

Supplier Agreement Management process, version 1.0

Risk Management process, version 1.0

Requirement Development process, version 1.0

Analysis & Design process, version 1.0

Implementation process, version 1.2

Testing process, version 1.0

Delivery process, version 1.0Decision Analysis & Resolution process, version 1.0

Configuration Management process, version 1.0

Change Request Management process, version 1.0

Software Quality Assurance process, version 1.0

Measurement & Analysis process, version 1.0

1.6 Templates / Forms

No. Artifact Name Description ChargeRequired

(Y/N)

Template

1 Tailoring Checklist Used to input thetailoring informationfrom the processeswith specifying tailoringcriteria.

POs Y TL-IUP-TailoringChecklist 0.5-EN.xlt

2 SelectionDevelopment ModelGuideline

Used to guide user onhow to select thedevelopment modelbased on somespecific projectscharacteristics.

IUPprocessteam

Y IUP- SelectionDevelopmentModel Guideline1.0-EN.doc


7/24



Version: 1.0



Confidential

Page 3/13

2 IUP Overview

SoftwareQuality

Assurance

Measurement&

Analysis

Figure 2. IVC Unified Process Overview

Phases and Disciplines

Phases Description Related Disciplines

Initiation Primarily goal of this phase is to achieveconcurrence among all stakeholders on

the objectives for the project, address allsignificant businesses and requirementsrisks, and to ensure that the project isworth doing and possible to do.

This phase also provides a stable basisplans for going to next phases.

- Project Management,

- Requirement Development,

- Analysis and Design,- Delivery,

- Testing,

- Configuration Management,

- Software Quality Assurance,

- Measurement & Analysis

- Risk Management

- Supplier Agreement Management

Definition This phase aims to baseline therequirements and the architecture of the

system to provide a stable basis for thebulk of the design and implementationeffort in the execution phase.


- Change Request

- Risk Management- Requirement Development,

- Analysis and Design,

- Testing,



- Measurement & Analysis

- Supplier Agreement Management

- Implementation

Execution The goal of this phase is to complete the

development of system ready to deliver tothe customer based on the baselineddesigns.


- Change Request- Risk Management




8/24



Version: 1.0



Confidential

Page 4/13

Phases Description Related Disciplines

- Measurement & Analysis,

- Implementation,

- Testing

Transition The goal of this phase is to deliver theproduct and associated deliverables tothe customers, maintain the product whileit is being used by the customer. Doappropriate fix patches and/or deliverenhanced releases as needed.


- Change Request

- Risk Management




- Implementation,

- Testing,

- Delivery

Retirement Goal of this phase is to bring the project

to an end when the product is accepted toclose by customer and managers.




- Testing

Disciplines Overview

No. Disciplines Description

1 Project Management Discipline for estimating, planning, monitoring, controllingand managing all the project activities.

2 Requirement Development Discipline for developing, maintaining and managingcustomer requirements.

3 Analysis and Design Discipline for analyzing and designing the software productbased on its requirements specifications.

4 Implementation Discipline for implementing and integrating the softwareproduct based on its design.

5 Testing Discipline for testing the software product against itsrequirements and customers expectations.

6 Delivery Discipline for delivery the package of software product tocustomer.

7 Configuration Management Discipline for ensuring the integrity of work products throughthe project lifecycle.

8 Software QualityAssurance

Discipline for assuring the adherence of project process andthe work products conform to the defined standards.

9 Risk Management Assist the Project Leader to develop and execute a plan toidentify project risks as early as possible and to periodicallyre-assess and manage those risks.

10 Supplier AgreementManagement

Manage the acquisition of products from suppliers for whichthere exists a formal agreement.


9/24



Version: 1.0



Confidential

Page 5/13

Beside those above processes, there are some processes are joined in the project to support forother activities such as:

No. Disciplines Description

1 Decision Analysis and

Resolution

Support the project team to provide a methodology and

framework for formal decision making.

2 Measurement and Analysis Develop and sustain a measurement capability that is usedto support management information needs in the project.

3 IUP Lifecycle

The software lifecycle of the IUP is decomposed over time into five sequential phases. There is firstfour phases concluded by a major milestone; the fifth phase, also the last one, would have theremained tasks in project done successfully leading to an end.

At each phase-end an assessment is performed to determine whether the objectives of the phase

have been met. A satisfactory assessment allows the project to move to the next phase. So, there isessentially a span of time between two major milestones to complete all remained tasks of currentphases.

Figure 3. IUP Lifecycle

3.1 Phase: Initiation

Prior to this phase, the Sales department has obtained the initial engagement with the customer, andreceived high level expectation for the product or solution from customer. These initial requirementsshall be transferred to the Project Managers of appropriate sections, Business Application (BA)section and Mobile (MB) section, for an analysis on ensuring that the project is both worth doing andpossible to do.

This phase focuses mainly on the achievement of the concurrence among all stakeholders on theobjectives for the project.

3.1.1 Objectives

Address all potential risks to the project.

Establish the project's software scope and boundary conditions, product acceptance criteria andwhat is intended to be in the product and what is not.

Estimate the overall cost and effort for the entire project, and also determine the masterschedule.

Achieve the commitment of stakeholders on project lifecycle, estimated development effort andresources.

Then obtain the required resources for the project in case the project is continued.

3.1.2 Entry Criteria

Customers engagement is established via the Project Order Sheet.

High level expectations for the product are specified by the customer.


10/24



Version: 1.0



Confidential

Page 6/13

3.1.3 Input

Project Order Sheet

High level requirements

3.1.4 Output Project Estimation

Baselined plans including Project Plan, Risk Management Plan, SQA Plan, MA Plan, DeliveryPlan, CM Plan, Test Plan

Requirements documents as: Vision, Business Process Model, Requirement Allocation, outlineof SRS, Use-cases

Some design documents as: Selected Technical Solution, Software Conventions

Risk List, Risk Log

CM Audit Report

NCs Tracking List

Project Start Report

Project Detail Schedule

Some work products are from the monitoring and controlling activities such as: Weekly Report,Project Labor Cost, Commitment Log, and Issues Log.

3.1.5 Exit Criteria

The estimation and master schedule for project is accepted by customer.

Project is accepted to continue.

A kick-off meeting is hold formally.

The complete Project Detail Schedule, at least for the first iteration, is reviewed and approvedby Senior Manager.

Project Resource Request is accepted by Senior Manager.

Project repository and all requested resources for the project are ready for going to the nextphase.

3.1.6 Flow of Activities


11/24

QualityManagementSystem

Code:IUP-PD

IssuedD

ate:

IVC

Unified

Process

Version:1.0

Copyright

ISBVietnamCorporation.

(IVC)

IUP-ProcessDescription

1.0-EN.doc

Confidential

Page7/20

Figure4.

InitiationPhaseOverview


12/24



Version: 1.0



Confidential

Page 8/20

3.1.7 Essential Activities

Create project repository in file server.

Analyze problem to have the Vision, Business Process Model, and initial Requirements

Allocation. Define the system from those above requirements document to have an outline of SRS and

Use-cases. These will be the input for the estimation activities.

Do estimation and master schedule for the project.

Obtain the agreement and commitment from customer and relevant stakeholders on theestimation and master schedule.

If the project is accepted to be continued, others required plans are developed such as ProjectPlan, Risk Management Plan, SQA Plan, MA Plan, Delivery Plan, CM Plan, Test Plan.

Then select the technical solution for developing project, and develop software conventions tobe ready for the next phase.

Beside, the project activities is also monitored and controlled from the early in this phase.

At the end of this phase, the leader shall conduct a kick-off meeting to inform the information toproject members and also start project formally.

Among the activities for ending phase, a detail schedule is also prepared for next phase by theleader.

3.2 Phase: Definition

The overriding goal of the definition phase is to baseline the architecture of the system to provide astable basis for the execution phase. This does not give an action schedule only, but also aperspective of the product to-be-built to project team.

3.2.1 Objectives

Complete planning for the project, and develop a detail schedule.

Hold a project kick-off meeting.

Obtain a deep understanding of the customers requirements to develop software requirementsspec.

Develop the design documents.

Gain the approval on those documents to provide a stable basis to the next phase.


Estimation and master schedule are agreed and accepted by customer and all stakeholders.

The complete Project Detail Schedule, at least for the first iteration, is reviewed and approvedby Senior Manager.

Project repository and all requested resources for the project are ready for going to the nextphase.

3.2.3 Input

Baselined Plans

Project Detail Schedule

Business Process Model

Requirements Allocation

3.2.4 Output

Change Requests


13/24



Version: 1.0



Confidential

Page 9/20

Project plans and schedule are updated or revised upon to the approved change requests.

Updated Requirements Allocation.

Baselined requirements that contain complete documents of Vision, Business Process Model,SRS, and Use-cases.

Baselined design documents that contain System Architecture, System Design, Detail Design,and Database Design.

Implementation Model

Testing documents such as: System Test Cases, Integration Test Cases, Test Data, and TestScript if any.

Updated of Risk List, Risk Log

CM Audit Report

NCs Tracking List

MA Report

Milestone Report


3.2.5 Exit Criteria

Project plan is approved.

Project kick-off meeting is held.

Software requirements spec, System design, Detail design are validated and approved.

Detail schedule, required resources and environment needed for upcoming project phase areavailable.



14/24


15/24



Version: 1.0



Confidential

Page 11/20


Request resources as needed for the project.

Develop the project plan, then review and gain the approval on it.

Hold the project kick-off meeting.

Make a detail schedule based upon the approved project plan.

Collect and analyze the customers requirements to develop SRS, and Use-cases.

Develop the system design and a part or entire the detail design documents to ensure the inputfor implementation in first iteration of next phase.

Implement and test the prototypes of system as required for a demonstration to customer.

3.3 Phase: Execution

The execution phase covers mainly for entire manufacturing process of the product, including most ofthe implementation and testing efforts to produce the product based upon the designs in Definitionphase.

3.3.1 Objectives

Update design document as necessary.

Plan for system/subsystem integration.

Implement the product as designed.

Test the product components and/or entire product.

Create the builds of product for deployment to customer.

Finalize the support materials such as user manual, installation guide.


The software requirements spec and system design and/or detail design are validated andapproved.

Detail schedule for this phase, required resources and environment needed are available.

3.3.3 Input

Baselined requirements (contain complete documents of Vision, Business Process Model, SRS,and Use-cases)

Baselined design documents (contain System Architecture, System Design, Detail Design, andDatabase Design)

Integration Test Cases, Test Data, and Test Script if any.

Baselined plans and schedule.

3.3.4 Output

Change Requests

Project plans and schedule are updated or revised upon to the approved change requests.

Updated Requirements Allocation.

Baselined code (build of subsystem).

Unit Test Log, Code Review Checklist, Code Inspection Log.

Bugs Tracking List, Test Result Report.


CM Audit Report


16/24



Version: 1.0



Confidential

Page 12/20

NCs Tracking List

MA Report

Milestone Report

Some work products are from the monitoring and controlling activities such as: Weekly Report,

Project Labor Cost, Commitment Log, and Issues Log.

3.3.5 Exit Criteria

Test design is approved.

The implemented product is tested passed and delivered to customer.

Support materials are finalized and available.

Detail schedule, required resources and environment needed for upcoming project phase areavailable.



17/24


Code:IUP-PD

IssuedD

ate:

IVC

Unified

Process

Version:1.0

Copyright


(IVC)


1.0-EN.doc

Confidential

Page13/20

Figure6.

ExecutionPhaseOverview


18/24



Version: 1.0



Confidential

Page 14/20


Update system design and detail design for the product components as necessary.

Make plan for system integration.

Compose test cases, test scripts, and prepare test data for implement testing.

Implement the product components based on the design documents.

Perform unit test for product components and all modules.

Integrate product components and execute the integration test to product.

Fix all defects found to ensure that the integrated product is ready for every delivery.

Deliver components and/or build of product.

Finalize the support materials.

3.4 Phase: Transition

The primary goal of Transition phase is to ensure that the software product is delivered to its enduser successfully.

This phase also includes maintaining the product and making some minor adjustments based onuser feedback. Any major changes or adjustments from end-user should lead to a new developmentcycle begins with an Initiation phase, or Definition phase, etc.

3.4.1 Objectives

To deploy the product and associated deliverables to the customer.

Maintain and support to make the product passed the acceptance test.


Final product and associated deliverables are available.

The final product meets all acceptance criteria defined in the initiation phase.

3.4.3 Input

Baselined code

Baselined plans including Delivery Plan

All deliverables

3.4.4 Output

Delivery Package (Release Notes, support materials, source code files, etc.)

Bugs Tracking List, Test Result Report.


CM Audit Report

NCs Tracking List

MA Report, Milestone Report


3.4.5 Exit Criteria

Product is accepted by customer.



19/24


Code:IUP-PD

IssuedD

ate:

IVC

Unified

Process

Version:1.0

Copyright


(IVC)


1.0-EN.doc

Confidential

Page15/20

PL

CC

QC

CC

SQA

PL

PL

SQA

DP

PL

Start

End

Project

maintenace

act.

Identify&

analyzerisk

-Risklist

-Risklog

Changes

requestmgt

Change

reques

t

1

-Projectplan

-Projectdetail

schedule

1

Integrate

system

Manage

baseline

s

Newbaseline

(code)

WP

evaluation

NCstrackinglist

Manage

baseline

s

Newbaseline

(Delivery)

CMaud

it

-CMplan

-CMauditCL

CMauditreport

Phase-end

re

viewCL

NCs

trackinglist

Phase-end

meeting

Project

records,data

Milestone

report

Monitor&

contro

l

projec

t

Projectprogress,

data

-Weeklyreport

-Issueslog

-Commitmentlog

-Projectlaborcost

-Unittestlog

-Newversionof

system

-Systemdesign

-Integrated

subsystem

Test

execution

Newversionof

system

-B

ugstrackinglist

-T

estresultreport

-T

estplan

-T

estcases

-T

estdata

-T

estscripts

Newversionof

system

Supp

ortmaterials

Provide

measurement

results

-MAplan

-Project

records,data

MAreport

Create&deliver

thedeliverypac.

-Deliveryplan

-Deliverables

-Deliverytracking

(updated)

-Deliverypackage

Receive

feedbackfrom

customer

Deliverypackage

Deliverytracking

(updated)

Phase-end

review

Monitor

risk

Control

risk

Figure7.

TransitionPhaseOverview


20/24



Version: 1.0



Confidential

Page 16/20


Complete support materials.

Execute system test to the entire product.

Make a release notes.

Package all and deliver them to customer for acceptance test.

Get user feedback.

Fix defects and create the final product that passed the acceptance test.

3.5 Phase: Retirement

The Retirement phase completes all project activities, and archives the project data preparing forbringing it to an end.

3.5.1 Objectives

Bring the project to an end.

Collect measurement data for improvement.


Final product is accepted by the customer.

3.5.3 Input

SQA Plan,

SQA Evaluation Report,

NCs Tracking List

MA Plan,

Project data, records,

Bugs Tracking List,

Test Result Report

3.5.4 Output

Customer Evaluation Survey,

SQA Summary Report,

Project End Report,

Project Index.

3.5.5 Exit Criteria

All project activities are done successfully.

A project post-mortem is held.

Measurement data is collected and evaluated by Project Manager/Director.

Project end report is reviewed and evaluated by Project Manager/Director.



21/24



Version: 1.0



Confidential

Page 17/20

Figure 8. Retirement Phase Overview


Make detail schedule for closure project.

Collect all measurement data.

Archive all project documents and data into project defined repository.

Make a project end report for evaluation from Manager/Director.

Hold a project post-mortem meeting.


22/24



Version: 1.0



Confidential

Page 18/20

4 Software Project Types & Sizes

4.1 Project Types

There are two types of project at IVC, including: new application development, and enhancement/upgrading application.

4.1.1 New application development

There are two types of new application development project:

1. Designing and developing new application based on provided requirements from customer.

2. Implementing new application based on requirements spec and design documents provided bythe customer.

4.1.2 Enhancement / Upgrading

There are three types of the enhancement/upgrading project:

1. Adding new functions or updating functions of an existed software product.

2. Converting coding language of an existed source code to another one.

3. Port to another environment.

4.2 Project Sizes

There are three standard sizes for software project at IVC:

Size (man-month) Project Level Description

>= 75 A Large project

>= 15 and < 75 B Medium project

< 15 C Small project

5 Roles & Team Structure in IUP

There are two kinds of roles involve in the IUP: team roles, and individual roles.

5.1 Team roles

A team role consists of several individual roles that work closely in a specific aspect of the projectactivities, such as: project management, development, testing, etc.

There are six team roles involved on the project activities as following:

Project Management Team: is responsible for managing project activities. The scope ofmanagement is at:

- Project-level: managing the overall project plan, and accountable for the project scope,major milestones, resources, and expenses of the project.

- Team-level: managing the activities of team members, which is responsible for a specificfunctional area assigned by Project Manager/Project Leader.

Development Team: is responsible for implementing the product and realization of an integratedproduct based on customers requirements.


23/24



Version: 1.0



Confidential

Page 19/20

Testing Team: is responsible for testing of the product which is developed by Developmentteam.

Deployment Team: is responsible for package the product and all required deliverables into adeployment unit, and deploy the product successfully.

Product Support Team: is responsible for technical supporting and maintaining the productduring its production time.

Software Quality Assurance Team: is responsible for evaluating the adherence of the processand the compliances to quality standards of IVC from the project team. This team officiallybelongs to QA department and has an independent reporting channel between QA teammembers and section Managers/Director.

5.2 Individual roles

An individual role performs specific tasks that he/she is responsible to as assigned in the project byProject Manager/Project Leader.

There are some individual roles in a project team as following:

Project Leader: belongs to the Project Management Team, at project-level. This role isresponsible for managing, monitoring and controlling all of project activities directly.

Team Lead: belongs to the Project Management Team, at team-level. This role is assigned byProject Manager/Project Leader. Upon to specific team roles, this role will have its specific name.See figure 4 of Team Structure for detail.

Developer: belongs to Development Team, also could be a member of Deployment Team, andProduct Support Team as assigned by Project Leader.

Quality Control: belongs to Testing Team.

Quality Assurance: belongs to Software Quality Assurance Team.

Interpreter: is responsible for supporting project team in translation.

Aside from these individual roles, there are three roles which have impacts to the project at someaspect of management, technical consulting, quality of the project, including:

Project Manager:plays role as Management Reviewer who is responsible mainly for:

- Evaluating project planning, whether the project can be cancelled or not.

- Evaluating project assessment artifacts at major review points in the project lifecycle toaccept for the entrance into next phase or not.

Technical Manager: consults techniques for the project as required. This role could belong to

Product Support Team as well.

QA Leader: consults and supports SQA team to control the quality of project in adherence of theprocess, and qualified work products to standards.

QC Leader: consults and supports QC team in testing activities of project.

Refer to specific job description for more detail.

5.3 Team Structure

The project team structure is described in the figure as below:


24/24



Version: 1.0

Development Lead

(Development Team)

Support Lead

(Product Support

Team)

Deployment Lead

(Deployment Team)

Project Leader

QC Lead

(Testing Team)

QA Lead

(SQA Team)

Development

Team

Product Support

Team

Deployment

Team Testing Team SQA Team

Project Team

Support

Section Manager

(Project Manager)

QA Leader

Technical

Manager

QC Leader

Figure 9. Team Structure

Note: in the above structure, some notices are paid attention to as below:

Technical Manager, Project Manager, QC Leader and QA Leader are all positions atcompany-level.

Project Leader is a role which is turned up when there is a new project. This role could beplayed by the Project Leader who is officially at this position in company or a person who hasqualified to be assigned to project only.

Development Lead, Support Lead, Deployment Lead, QC Lead, and QA Lead are roleswhich are just turned up in a project only. When the project is end, these roles are also off.

Not all of the above team roles always required for every project. Depending on the project size andscope, one or several team roles may not be established. But there are four team roles areindispensables, including:

Project Management Team

Development Team

Testing Team

Software Quality Assurance Team

Normally, large and medium sized projects would have team structure as above. This helps tomonitor, manage and control these kinds of project without difficulty.

5.4 Staffing Rules

1. Developer who belongs to the Development Team could be assigned as member of DeploymentTeam, and Product Support Team, but MUST NOT be assigned as a QC/QA who belongs toTesting Team/SQA Team, and vice versa.

2. If there is only one QC assigned to the project, he/she would also play the role of QC Lead in theproject. Otherwise, QC Lead in a project should be assigned by QC Leader.

3. If there is only one QA assigned to the project, he/she would also play the role of QA Lead in theproject. Otherwise, QA Lead in a project should be assigned by QA Leader.

iup process description 1.0 en

Documents