Tải bản đầy đủ (.pdf) (83 trang)

Xây dựng giải pháp đánh giá chất lượng phần mềm trong công ty gia công phần mềm cho thị trường nhật

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.72 MB, 83 trang )

ĐẠI HỌC QUỐC GIA TP. HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC BÁCH KHOA

ĐINH HOÀI VŨ

XÂY DỰNG GIẢI PHÁP ĐÁNH GIÁ
CHẤT LƯỢNG PHẦN MỀM TRONG
CÔNG TY GIA CÔNG PHẦN MỀM
CHO THỊ TRƯỜNG NHẬT
Chuyên ngành: Hệ Thống Thông Tin Quản Lý
Mã số: 60.34.48

LUẬN VĂN THẠC SĨ

Thành phố Hồ Chí Minh tháng 6 năm 2011


ĐẠI HỌC QUỐC GIA TP. HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC BÁCH KHOA

ĐINH HOÀI VŨ

XÂY DỰNG GIẢI PHÁP ĐÁNH GIÁ
CHẤT LƯỢNG PHẦN MỀM TRONG
CÔNG TY GIA CÔNG PHẦN MỀM
CHO THỊ TRƯỜNG NHẬT
Chuyên ngành: Hệ Thống Thông Tin Quản Lý
Mã số: 60.34.48


LUẬN VĂN THẠC SĨ

Thành phố Hồ Chí Minh tháng 6 năm 2011


CƠNG TRÌNH ĐƢỢC HỒN THÀNH TẠI
TRƢỜNG ĐẠI HỌC BÁCH KHOA –ĐHQG -HCM
Cán bộ hƣớng dẫn khoa học :TS. Huỳnh Tƣờng Nguyên

Cán bộ chấm nhận xét 1 : TS. Nguyễn Văn Minh Mẫn

Cán bộ chấm nhận xét 2 :TS. Nguyễn Chánh Thành

Luận văn thạc sĩ đƣợc bảo vệ tại Trƣờng Ðại học Bách Khoa, Đại Học Quốc Gia
Tp. HCM ngày 5 tháng 9 năm 2011
Thành phần Hội đồng đánh giá luận văn thạc sĩ gồm:
1. TS. Nguyễn Đức Thái (CT)
2. TS. Nguyễn Văn Minh Mẫn (PB1)
3. TS. Nguyễn Chánh Thành (PB2)
4. TS. Huỳnh Tƣờng Nguyên (UV)
5. TS. Nguyễn Thanh Hùng (TK)
Xác nhận của Chủ tịch Hội đồng đánh giá LV và Bộ môn quản lý chuyên ngành
sau khi luận văn đã đƣợc sửa chữa (nếu có).
Chủ tịch Hội đồng đánh giá LV

Bộ môn quản lý chuyên ngành

TS. Nguyễn Đức Thái

PGS. TS. Đặng Trần Khánh



TRƢỜNG ĐH BÁCH KHOA TP. HCM
PHÕNG ĐÀO TẠO SĐH
____________________

CỘNG HÕA XÃ HỘI CHỦ NGHĨA VIỆT NAM
Độc lập - Tự do - Hạnh phúc
_______________________

Tp. HCM, ngày 30 tháng 6 năm 2011

NHIỆM VỤ LUẬN VĂN THẠC SĨ
Họ tên học viên: Đinh Hoài Vũ ..................................................... Phái: Nam ....................
Ngày, tháng, năm sinh: 26/11/1977 ............................................... Nơi sinh: Đăk Lăk........
Chuyên ngành: Hệ Thống Thông Tin Quản Lý ............................. MSHV: 09320857 ........
I. TÊN ĐỀ TÀI:

XÂY DỰNG GIẢI PHÁP ĐÁNH GIÁ CHẤT LƢỢNG PHẦN MỀM TRONG
CÔNG TY GIA CÔNG PHẦN MỀM CHO THỊ TRƢỜNG NHẬT
II. NHIỆM VỤ VÀ NỘI DUNG:
Xác định, phân tích những vấn đề liên quan đến việc quản lý chất lƣợng trong công ty gia
công phần mềm cho thị trƣờng Nhật để xây dựng phƣơng pháp quản lý, đánh giá chất lƣợng
hợp lý, từ đó xây dựng hệ thống thông tin hiện thực phƣơng pháp đánh giá chất lƣợng này.

III. NGÀY GIAO NHIỆM VỤ:14/02/2011
IV. NGÀY HOÀN THÀNH NHIỆM VỤ: 30/06/2011
V. CÁN BỘ HƯỚNG DẪN: TS. Huỳnh Tƣờng Nguyên
CÁN BỘ HƯỚNG DẪN


(Họ tên và chữ ký)

CHỦ NHIỆM BỘ MÔN
QUẢN LÝ CHUYÊN NGÀNH

KHOA QUẢN LÝ
CHUYÊN NGÀNH

(Họ tên và chữ ký)

(Họ tên và chữ ký)


LỜI CÁM ƠN
Xin chân thành cảm ơn thầy Huỳnh Tƣờng Nguyên đã tận tình hƣớng dẫn, định
hƣớng và tạo điều kiện thuận lợi để hoàn thành luận văn. Xin cảm ơn cô Võ Thị
Ngọc Châu và các bạn lớp MIS 2009 đã đóng góp nhiều ý kiến quý giá.
Đặc biệt cảm ơn các bạn nhân viên công ty Cube System Việt Nam đã sử dụng và
kiểm thử chƣơng trình, cung cấp và nhập dữ liệu thực tế để hệ thống có thể kiểm
chứng.
Mong rằng kết quả của luận văn này góp một phần nhỏ trong việc nâng cao chất
lƣợng phát triển phần mềm cho công ty Cube System Việt Nam nói riêng và các
cơng ty gia cơng phần mềm nói chung.

TP Hồ Chí Minh ngày 30 tháng 6 năm 2011
Đinh Hoài Vũ

i



TĨM TẮT
Trong phát triển phần mềm, quy trình quản lý chất lƣợng là một khâu quan trọng và
tốn nhiều công sức. Đặc biệt, đối với ngành gia công phần mềm cho thị trƣờng Nhật,
với đặc tính đề cao chất lƣợng của ngƣời Nhật, việc quản lý chất lƣợng của các công
ty nhận gia công vẫn chƣa đạt yêu cầu.
Phần đánh giá chất lƣợng là cơng đoạn quan trọng và khó khăn nhất trong quản lý
chất lƣợng. Quan trọng vì mấu chốt của quản lý chất lƣợng là phải đánh giá đƣợc
chất lƣợng. Chúng ta cần đánh giá đƣợc để biết chất lƣợng đạt hay khơng, có vấn đề
chỗ nào, và cần phải điều chỉnh quy trình ở chỗ nào. Tuy nhiên, chất lƣợng là khái
niệm trừu tƣợng, mang tính chất định tính, rất khó để định lƣợng hóa để đánh giá.
Trong thực tế, có rất nhiều mơ hình và cơ sơ lý thuyết hƣớng dẫn định lƣợng hóa và
đánh giá chất lƣợng, vấn đề chủ yếu là làm sao xây dựng, thu thập các thơng tin để
định lƣợng hóa chất lƣợng một cách hợp lý cho tổ chức.
Trong ngành gia công phần mềm, bên gia công chỉ thực hiện một số cơng đoạn
trong trong quy trình phát triển phần mềm, nên việc đánh giá chất lƣợng cũng phải
điều chỉnh cho phù hợp.
Luận văn này dựa trên đặc điểm của ngành gia cơng phần mềm và mơ hình đánh giá
chất lƣợng ISO-9126 để xây dựng mơ hình đánh giá chất lƣợng phù hợp, từ đó phát
triển một hệ thống đánh giá chất lƣợng phù hợp với tổng thể quy trình hoạt động
hiện hữu của công ty. Đặc điểm cơ bản của hệ thống này đƣợc mô tả nhƣ sau :
 Xây dựng các đặc tính chất lƣợng và mơ hình để thống kê thơng tin và đánh giá
đặc tính chất lƣợng đó theo lý thuyết của ISO-9126.
 Chuẩn hóa lại quy trình phát triển phần mềm để lấy đƣợc những thơng tin thích
hợp, dựa trên những thơng tin sẵn có đó để định lƣợng hóa chất lƣợng nhằm
giảm thiểu thời gian và công sức.
 Chất lƣợng đƣợc đánh giá theo thời gian thực: từng công việc nhỏ trong dự án
đƣợc đánh giá trong lúc cơng việc đó đƣợc thực hiện. Điều này giúp cho việc
đánh giá chất lƣợng đƣợc xuyên suốt và khách quan.
 Chất lƣợng đánh giá có quan tâm đến đặc điểm gia công phần mềm, phản ánh
đƣợc vấn đề chất lƣợng các giai đoạn trƣớc khi đƣa qua gia công.


ii


ABSTRACT
In software development, quality management is quite important and takes much
effort. Especially, in the software subcontracting industry for Japanese market, the
subcontractors’ quality management has not yet met the Japanese high quality
requirement.
In quality management, the quality assessment is the most important and difficult.
It’s important because the key of quality management is to assess whether the
quality is good or not, where the problem happens, where need to have action. It’s
difficult because quality is an abstract and qualitative. It’s hard to quantify the
evaluation. There are many models and theoretical basis of guidance quantifying
and assessing the quality but the problem is how to build and collect information to
quantify the quality reasonably.
In the software subcontracting industry, the subcontractors only execute some
phases in the whole software development process. So the quality assessment must
be adjusted suitably
This thesis is based on nature of software subcontracting industry and quality
assessment model ISO-9126 to build a suitable quality assessment model and then
develop a quality assessment system for software-subcontracting companies. Basis
characteristics of the system are described as below:
 Building quality characteristics and model to collect statistical information and
assess them according to the theory of ISO-9126.
 Standardizing software development process to collect suitable information.
Based on that, quantifying the quality to reduce time and effort.
 The quality is assessed by real time. Each small task in the project will be
evaluated during it’s performed. This helps the quality assessment smooth and
objective.

 The quality of assessment takes into account the software subcontracting
characteristics and reflects quality problems of the phases before
subcontracting.

iii


-1-

MỤC LỤC
DANH MỤC CÁC TỪ VAY MƯỢN, VIẾT TẮT............................................................ 4
CHƯƠNG 1 GIỚI THIỆU .......................................................................................... 6
1.1

Tổng quan .................................................................................................................................................. 6

1.1.1

Vấn đề nghiên cứu ............................................................................................................................ 6

1.1.2

Mục tiêu nghiên cứu.......................................................................................................................... 7

1.1.3

Đối tƣợng và phạm vi nghiên cứu ..................................................................................................... 7

1.1.4


Phƣơng pháp nghiên cứu ................................................................................................................... 7

1.1.5

Nội dung luận văn ............................................................................................................................. 8

1.2

Tình hình gia cơng phần mềm từ thị trường Nhật Bản ......................................................................... 8

1.3

Các vấn đề trong gia công phần mềm cho Nhật ................................................................................... 10

1.4

Chiến lược phát triển ngành GCPM...................................................................................................... 12

1.5

Công đoạn phát triển trong GCPM ....................................................................................................... 13

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT CỦA ĐỀ TÀI ..................................................... 16
2.1

Phương pháp đánh giá chất lượng ......................................................................................................... 16

2.1.1

Định nghĩa đánh giá chất lƣợng ...................................................................................................... 16


2.1.2

Đánh giá chất lƣợng theo phƣơng pháp GQM ................................................................................ 17

2.1.3

ISO – 9126 ...................................................................................................................................... 19

2.2

Cơ sở lý thuyết của đề tài ........................................................................................................................ 22

CHƯƠNG 3 GIẢI PHÁP ĐÁNH GIÁ CHẤT LƯỢNG ............................................. 26
3.1

Các công việc trong dự án....................................................................................................................... 26

Luận văn thạc sĩ – MIS khoá 2009


-23.1.1

Phát triển phần mềm........................................................................................................................ 26

3.1.2

Q&A ................................................................................................................................................ 26

3.1.3


Review ............................................................................................................................................ 27

3.1.4

Kiểm thử ......................................................................................................................................... 27

3.1.5

Quản lý thay đổi .............................................................................................................................. 28

3.1.6

Tóm tắt ............................................................................................................................................ 28

3.2

Các thơng tin mơ tả đặc tính dự án ........................................................................................................ 29

3.2.1

Số dòng mã nguồn ........................................................................................................................... 30

3.2.2

Q&A ................................................................................................................................................ 30

3.2.3

Review ............................................................................................................................................ 32


3.2.4

Tài liệu kiểm thử ............................................................................................................................. 34

3.2.5

Kiểm thử ......................................................................................................................................... 34

3.2.6

Thay đổi đặc tả ................................................................................................................................ 36

3.2.7

Tóm tắt ............................................................................................................................................ 37

3.3

Xây dựng chỉ tiêu đánh giá chất lượng .................................................................................................. 38

3.3.1

Tính hồn thiện ............................................................................................................................... 40

3.3.2

Khả năng chịu lỗi ............................................................................................................................ 40

3.3.3


Tính bảo trì ...................................................................................................................................... 42

3.4

Phương pháp đánh giá chất lượng ......................................................................................................... 45

3.4.1

Đánh giá trên chỉ tiêu chất lƣợng .................................................................................................... 45

3.4.2

Đánh giá nội dung từng công đoạn ................................................................................................. 47

3.4.3

Đánh giá thời gian thực ................................................................................................................... 48

CHƯƠNG 4 HỆ THỐNG ĐÁNH GIÁ CHẤT LƯỢNG ............................................ 50

Luận văn thạc sĩ – MIS khoá 2009


-34.1

Mơ hình .................................................................................................................................................... 50

4.1.1


Hiện trạng (AS-IS) .......................................................................................................................... 50

4.1.2

Mơ hình mới (TO-BE) .................................................................................................................... 51

4.1.3

Kiến trúc .......................................................................................................................................... 53

4.1.4

Cơ sở dữ liệu ................................................................................................................................... 55

4.2

Các chức năng của hệ thống ................................................................................................................... 56

4.2.1

Danh sách các chức năng ................................................................................................................ 56

4.2.2

Sơ đồ lƣu chuyển màn hình ............................................................................................................. 58

4.3

Người sử dụng .......................................................................................................................................... 58


CHƯƠNG 5 ĐÁNH GIÁ VÀ HƯỚNG PHÁT TRIỂN .............................................. 60
5.1

Ứng dụng thực tế ..................................................................................................................................... 60

5.1.1

Thông tin dự án ............................................................................................................................... 60

5.1.2

Đánh giá chất lƣợng ........................................................................................................................ 61

5.2

Đánh giá hệ thống .................................................................................................................................... 68

5.3

Hướng phát triển ..................................................................................................................................... 71

TÀI LIỆU THAM KHẢO ............................................................................................ 73
PHỤ LỤC .................................................................................................................. 75
LÝ LỊCH TRÍCH NGANG .......................................................................................... 76

Luận văn thạc sĩ – MIS khoá 2009


-4-


DANH MỤC CÁC TỪ VAY MƯỢN, VIẾT TẮT
No. Thuật ngữ

Giải thích

1

Bug

Lỗi đƣợc phát hiện khi kiểm thử

2

Code

Mã nguồn

3

Comment

Chú giải. Ở đây nói đến các lời giải thích giúp mã nguồn
dễ hiểu hơn

4

CMMI

Capability Maturity Model Intergration, là một chuẩn
trong quản lý quy trình phát triển phần mềm


5

Database

Cơ sở dữ liệu

6

Firmware

Thuật ngữ thỉnh thoảng đƣợc dùng để biểu thị những phần
mềm cố định, thƣờng là khá nhỏ, để điều khiển nội quan
nhiều thiết bị điện tử

7

FP

Function point, điểm chức năng, đơn vị trong một phƣơng
pháp ƣớc lƣợng phần mềm, cũng có tên là Function point

8

GCPM

Gia công phần mềm

9


IPA

Information technology Promotion Agency, Tổ chức xúc
tiến công nghệ thông tin của Nhật

10

IT

Information technology, chỉ cơng nghệ thơng tin nói
chung

11

JIPDEC

Japan Institute for Promotion of Digital Economy and
Community, Tổ chức phát triển công nghệ thông tin Nhật
Bản

12

LAN

Mạng nội bộ

13

LOC


Line of code, số dòng mã nguồn

14

Module

Các thành phần trong hệ thống

15

Offshore

Chỉ việc giao gia công phần mềm ra nƣớc ngồi

16

Package

Phần mềm đóng gói

17

PDCA

Plan – Do – Check – Action, chu trình quản trị khép
kín Hoạch định – Thực hiện – Kiểm tra – Khắc phục

Luận văn thạc sĩ – MIS khoá 2009



-518

Q&A

Question & Answer (hỏi và đáp), chỉ việc giao tiếp giữa
bên nhận gia cơng và khách hàng trong q trình phát
triển phần mềm

19

Review

Xác nhận, kiểm tra lại các đoạn mã nguồn, và kiểm tra các
sai sót trong thiết kế. Khác với kiểm thử, review không
thực thi các đoạn code để kiểm tra mà chỉ xem xét trên
nội dung mã nguồn và bản thiết kế

20

Schedule

Lập lịch, là kế hoạch, thời gian biểu của quá trình phát
triển phần mềm

21

SVN

Subversion, là một phần mềm mã nguồn mở dùng để quản
lý và kiểm tra các phiên bản mã nguồn khác nhau trong

quá trình phát triển phần mềm

22

Task

Công việc trong dự án, thƣờng gán với việc viết mã
nguồn, thiết kế từng thành phần trong hệ thống

23

Test

Kiểm thử, thực thi các đoạn mã nguồn, kiểm tra mã nguồn
viết có đúng theo thiết kế khơng

24

Test kết hợp

Kiểm thử việc các bộ phận riêng rẽ kết hợp với nhau có
thực hiện đúng nhƣ thiết kế khơng

25

Test unit

Kiểm thử từng chức năng, bộ phận riêng rẻ trong hệ thống

26


Testcase

Các kịch bản đƣợc viết để thực hiện khi kiểm thử

27

Video
conference

Hội nghị hợp thơng qua truyền hình từ xa

28

V-model

Một mơ hình trong phát triển phần mềm

29

Web server

Máy chủ phục vụ hệ thống thông tin trên nền tảng WEB

30

Wikipedia

Là một bách khoa tồn thƣ nội dung mở bằng nhiều ngơn
ngữ trên Internet

Bản tiếng Việt : />Bản tiếng Anh : />
Luận văn thạc sĩ – MIS khoá 2009


-6-

CHƯƠNG 1

GIỚI THIỆU

1.1 Tổng quan
1.1.1 Vấn đề nghiên cứu
Quản lý chất lƣợng là một quy trình quan trọng trong phát triển phần mềm.
Theo wikipedia[16], chất lƣợng phần mềm bao gồm hai khái niệm khác biệt
nhƣng có liên quan với nhau.
Chất lượng chức năng
Phản ánh việc phần mềm thỏa mãn các yêu cầu chức năng của đặc tả hệ thống
như thế nào.
Chất lượng cấu trúc
Phản ánh việc phần mềm hội đủ các yêu cầu “ phi chức năng” như khả năng bảo
trì, sự ổn định hay khơng.
Đánh giá chất lƣợng phải đánh giá trên cả hai mặt này. Đối với chất lƣợng chức
năng, cơng việc đánh giá có thể dể dàng hơn, chất lƣợng chức năng có đảm bảo
hay khơng có thể đánh giá thông qua việc đối chiếu giữa chức năng thực tế của hệ
thống và yêu cầu đặc tả của bản thiết kế.
Đánh giá chất lƣợng cấu trúc là phần khó khăn trong quản lý chất lƣợng bởi vì các
khái niệm về sự ổn định, khả năng bảo trì là các khái niệm trừu tƣợng, khó có thể
định lƣợng và đánh giá.
Cũng theo khái niệm định nghĩa trên wikipedia[17], gia công phần mềm
(outsourcing) là chuyển giao một phần công việc ra bên ngồi làm nhằm mục đích

cắt giảm chi phí hoặc có thể tập trung nguồn lực vào các cơng việc quan trọng
hơn.
Vì vậy gia cơng phần mềm cũng tƣơng tự nhƣ các loại hình gia cơng khác, bên
nhận gia cơng khơng phát triển tồn bộ sản phẩm mà chỉ làm một bộ phận hoặc
một cơng đoạn trong tồn quy trình phát triển sản phẩm.
Cơng ty nhận gia cơng phần mềm ngồi những khó khăn nói chung trong quản lý
chất lƣợng, do đặc điểm chỉ gia công một phần nhỏ trong quy trình phát triển
Luận văn thạc sĩ – MIS khoá 2009


-7phần mềm, các cơng ty này khó có thể áp dụng các mơ hình quản lý chất lƣợng
phổ biến hiện có.
Đề tài này nghiên cứu những vấn đề quản lý và đánh giá chất lƣợng trong công ty
gia công phần mềm cho thị trƣờng Nhật để tìm ra giải pháp quản lý chất lƣợng
phù hợp.
1.1.2 Mục tiêu nghiên cứu
Đề tài này có mục tiêu xây dựng đƣợc hệ thống đánh giá chất lƣợng thõa mãn các
tiêu chí sau.
 Định lƣợng, đánh giá đƣợc chất lƣợng, đƣa ra những yếu tố quan trọng từ đó
có thể cải thiện đƣợc chất lƣợng.
 Giảm thiểu chi phí quản lý chất lƣợng.
 Phù hợp với các công ty gia công phần mềm, đặc biệt cho thị trƣờng Nhật.
1.1.3 Đối tượng và phạm vi nghiên cứu
Đối tƣợng nghiên cứu của đề tài là quy trình phát triển phần mềm và môi trƣờng
liên quan của một công ty nhỏ gia công phần mềm cho thị trƣờng Nhật. Cụ thể
nhƣ sau.
 Phƣơng pháp và tình hình quản lý chất lƣợng dự án trong công ty gia công
phần mềm nhỏ, có trụ sở tại cơng viên phần mềm Quang Trung.
 Các đặc điểm, cách làm việc của khách hàng Nhật liên quan đến công ty này.
Đề tài tập trung nghiên cứu phần đánh giá chất lượng trong quy trình quản lý

chất lƣợng.
1.1.4 Phương pháp nghiên cứu
Đề tài đƣợc thực hiện theo ba bƣớc
Khảo sát, phân tích
Phân tích đặc điểm của việc gia công phần mềm cho khách hàng Nhật, khảo sát
các phƣơng pháp đánh giá chất lƣợng hiện có.

Luận văn thạc sĩ – MIS khố 2009


-8Đề xuất mơ hình
Đề xuất mơ hình đánh giá chất lƣợng phù hợp với công ty gia công phần mềm
nhỏ cho thị trƣờng Nhật.
Xây hệ thống thông tin
Xây dựng hệ thống thơng tin theo mơ hình đề xuất và kiểm chứng kết quả.
1.1.5 Nội dung luận văn
Luận văn gồm 5 chƣơng.
Chƣơng 1 trình bày bối cảnh hình thành và tính cấp thiết của đề tài, nội dung và
mục tiêu nghiên cứu.
Chƣơng 2 phân tích các lý thuyết liên quan đến đánh giá chất lƣợng, đặc điểm gia
công phần mềm và đƣa ra hƣớng đi của đề tài.
Chƣơng 3 đề xuất một mơ hình, giải pháp đánh giá chất lƣợng cụ thể dựa trên nội
dung phân tích của chƣơng 2.
Chƣơng 4 xây dựng hệ thống thông tin đánh chất lƣợng theo mơ hình đề xuất ở
chƣơng 3.
Chƣơng 5 thực hiện việc kiểm thử hệ thống trên dự án thực tế, đƣa ra kết quả
đánh giá và hƣớng mở rộng của đề tài.
1.2 Tình hình gia cơng phần mềm từ thị trường Nhật Bản
Với nền kinh tế phát triển và dân số đang lão hóa, nhu cầu gia cơng phần mềm ở
nƣớc khác của Nhật ngày càng cao. Theo khảo sát của tổ chức xúc tiến công nghệ

thông tin của Nhật (IPA – Information technology Promotion Agency) trên hơn một
ngàn công ty thì vào năm 2012, tổng sản lƣợng gia cơng phần mềm của ngành công
nghệ thông tin Nhật Bản đƣợc dự đoán là 119,563 triệu Yên (tƣơng đƣơng 1,2 tỷ
USD)

Luận văn thạc sĩ – MIS khoá 2009


-9-

140,000
120,000
Triệu Yên

100,000
80,000
60,000
40,000
20,000

0
2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012

Biểu đồ 1-1) Thống kế chi phí GCPM của IPA, Nhật bản, năm 2009[1]

Việt Nam là quốc gia đứng thứ tƣ trong số các nƣớc làm gia công phần mềm nhiều
nhất cho thị trƣờng Nhật, sau Trung Quốc, Ấn Độ và Philipine. Cũng theo khảo sát
của tổ chức xúc tiến công nghệ thông tin của Nhật Bản, thực hiện trong năm 2010
về đối tác gia công phần mềm, Việt Nam vƣợt qua cả Ấn độ, đứng thứ 2 về số
lƣợng đối tác gia công (85% doanh nghiệp Nhật Bản đƣợc khảo sát có quan hệ

gian cơng phần mềm với Trung Quốc, 18% có quan hệ với Việt Nam, và 15% với
Ấn Độ)[2].

Luận văn thạc sĩ – MIS khoá 2009


- 10 Quốc gia

2003

2004

2006

2007

Trung Quốc

26,280

33,241

48,535

57,537

56,476

59,542


Mỹ

4,988

5,147

169

2,628

2,794

2,253

Úc

2,626

3,133

0

4,459

4,247

2,830

Philipin


2,494

2,117

1,550

4,262

4,604

3,640

Ấn Độ

6,312

4,255

14,093

20,631

20,806

6,538

Anh

1,827


2,126

Pháp

834

548

Việt Nam

30

216

430

1,258

3,867

3,297

Hàn Quốc

1,871

1,415

1,450


1,220

939

755

4

1,163

1,219

1,022

Đức

2008

2009

54

EU
Khác

1,644

499

1,677


2,669

6,131

4,721

Tổng

48,960

52,697

67,908

95,827

101,083

124,598

Bảng 1-1) Thống kê chi phí gia cơng phần mềm của Nhật Bản (đơn vị: triệu Yên) [3]

Tuy nhiên tổng doanh thu của Việt Nam mới chỉ chiếm có phần nhỏ, nhỏ hơn rất
nhiều lần so với Trung Quốc.
Việt Nam
Ấn Độ
4%
9%


Hàn Quốc
1%

Philipin
5%

Trung Quốc
81%

Biểu đồ 1-2) Tỉ lệ doanh thu gia công phần mềm cho Nhật ở châu Á năm 2009[3]

1.3 Các vấn đề trong gia cơng phần mềm cho Nhật
Ngồi lợi thế lớn nhất là giá rẻ, các yếu tố quan trọng khác liên quan đến gia công
Luận văn thạc sĩ – MIS khoá 2009


- 11 phần mềm nhƣ tiếng Nhật, trình độ kỹ thuật, khả năng kiểm soát chất lƣợng của
Việt Nam đều yếu hơn so với Trung Quốc và Ấn Độ[4].
Cũng theo khảo sát của IPA[5] về những khó khăn gặp phải khi gia công phần mềm
tại Việt Nam, từ năm 2008 cho đến 2010, ngoài các vấn đề kỹ thuật và bảo mật
tƣơng đối đƣợc cải thiện đáng kể, các vấn đề khác, đặc biệt là khâu quản lý chất
lƣợng, không có nhiều tiến triển. Trong khi đó giá nhân cơng lại có xu hƣớng tăng
lên.
Chất lượng khó
quản lý
80
Vấn đề chính trị

60


Giao hàng trể

40
2008

20
Giá nhân công
tăng

0

Giao tiếp kém

2009
2010

Kỹ thuật yếu kém

Văn hóa khác biệt
Vấn đề bảo mật

Biểu đồ 1-3) Thống kê các vấn đề khó khăn trong gia cơng phần mềm tại Việt Nam [5]

Vấn đề chính trị

Giá nhân cơng
tăng

Chất lượng khó
quản lý

70
60
50
40
30
20
10
0

Giao hàng trể
2008
Giao tiếp kém

2009
2010

Kỹ thuật yếu kém

Văn hóa khác biệt
Vấn đề bảo mật

Biểu đồ 1-4) Thống kê các vấn đề khó khăn trong gia cơng phần mềm tại Trung Quốc [5]

Luận văn thạc sĩ – MIS khoá 2009


- 12 1.4 Chiến lược phát triển ngành GCPM
Đối tác gia cơng phần mềm chính của Nhật Bản là Trung Quốc và Ấn Độ. Các đối
tác này ngày càng lớn mạnh trở thành đối thủ cạnh tranh trực tiếp, đồng thời việc
phụ thuộc vào nhiều một quốc gia dẫn đến nhiều rủi ro khi có những bất ổn về kinh

tế và chính trị. Do đó Nhật đã bắt đầu và đang gia công với các đối tác khác Trung
Quốc, trong đó có Việt Nam.
Trong giai đoạn đầu, chúng ta cạnh tranh bằng các yếu tố chi phí, sự hỗ trợ ngành IT
của chính phủ. Tuy nhiên ƣu thế về chi phí hiện nay khơng cịn nữa. Kinh tế Việt
Nam ngày càng phát triển, cộng với lạm phát gia tăng, chi phí vận hành cơng ty,
lƣơng cho nhân viên cũng tăng đáng kể. Đơn giá một tháng cho một kỹ sƣ trong các
công ty gia công phần mềm thị trƣờng Nhật giao động từ 1500~2000USD (Đây là
đơn giá do các đối tác Nhật phải trả). Chi phí này so với Trung Quốc khơng khác
biệt bao nhiêu, trong khi đó trình độ tiếng Nhật, khả năng kỹ thuật và đặc biệt sự sẵn
sàng của nguồn nhân lực họ hơn chúng ta rất nhiều.
Khơng thể cạnh tranh về giá, chúng ta phải có các chiến lƣợc cạnh tranh hợp lý khác.
Ngoài sự hỗ trợ của chính phủ về việc đào tạo nguồn nhân lực IT, các trung tâm
ngoại ngữ đào tạo tiếng Nhật cho các kỹ sƣ, mỗi cơng ty cần phải có những hƣớng
đi riêng để giữ chân khách hàng cũ và thu hút khách hàng mới.
Nƣớc Nhật nổi tiếng là một nƣớc khắt khe về chất lƣợng. Những sản phẩm của Nhật
từ hàng tiêu dùng cho đến các mặt hàng điện tử, hệ thống máy móc cơng nghiệp đều
có chất lƣợng tuyệt đối. Vì vậy, đối với các đối tác gia công, họ cũng yêu cầu chỉ
tiêu chất lƣợng rất cao.
Theo nhƣ khảo sát của IPA trình bày ở trên, Trung Quốc cũng gặp vấn đề quản lý
chất lƣợng giống nhƣ Việt Nam. Đây là cơ hội để chúng ta có thể tạo đƣợc lợi thế
cạnh tranh giành thị phần gia công phần mềm cho Nhật Bản.
Liên quan đến vấn đề chất lƣợng, CMMI là một trong số các tiêu chuẩn phổ biến
và quan trọng. Tuy nhiên, để xây dựng quy trình quản lý chất lƣợng theo CMMI
và lấy đƣợc chứng chi này, chí phí rất lớn. Hơn nữa nguồn lực và quy mơ của
cơng ty phải đạt đến trình độ nhất định mới có thể áp dụng đƣợc quy trình quản lý
CMMI [6].
Do đó, các cơng ty gia cơng phần mềm vừa và nhỏ cần phải tự xây dựng một quy
Luận văn thạc sĩ – MIS khoá 2009



- 13 trình quản lý chất lƣợng cho riêng mình.Với số lƣợng nhân viên vừa phải, cơng
ty có thể dễ dàng tổ chức lại quy trình làm việc, tìm ra phƣơng pháp quản lý chất
lƣợng hiệu quả, đặc biệt là cách thức chứng minh cho khách hàng thấy các sản
phẩm của cơng ty là đảm bảo chất lƣợng, từ đó tạo lòng tin từ khách hàng, nâng cao
ƣu thế cạnh tranh.
Quản lý chất lƣợng là một quy trình, từ việc thiết kế quy trình, lên kế hoạch các
cơng việc cần thực hiện cho đến kiểm tra kết quả và điều chỉnh phƣơng hƣớng.
PDCA (Plan – Do – Check – Action), tạm dịch là Hoạch định – Thực hiện – Kiểm
tra – Khắc phục là chu trình chuẩn, khép kín, đƣợc áp dụng cho việc quản trị,
thƣờng đƣợc nhắc đến trong lĩnh vực quản lý chất lƣợng [7].
PLAN
Lên kế hoạch

DO
Thực hiện cơng việc

ACTION
Tối ƣu, điều chỉnh

CHECK
Kiểm tra kết quả

Hình 1-1) Chu trình PDCA

Trong chu trình PDCA , khâu kiểm tra là khâu rất quan trọng, có yếu tố quyết định.
Kiểm tra để đảm bảo quy trình hợp lý, kiểm tra để biết chất lƣợng đang ở mức nào,
có những vấn đề gì, cần làm gì để cải thiện chất lƣợng.
Để kiểm tra đƣợc chất lƣợng, cần phải đánh giá chính xác đƣợc chất lƣợng. Chất
lƣợng là khái niệm trừu tƣợng, có tính chất định tính nên rất khó trong việc đánh giá,
vấn đề không quản lý đƣợc chất lƣợng chủ yếu nằm ở chỗ không nắm đƣợc chất

lƣợng đang ở mức độ nào, tốt xấu nhƣ thế nào. Đề tài này sẽ tìm kiếm giải pháp
đánh giá chất lƣợng phần mềm, xây dựng hệ thống hỗ trợ định lƣợng chất lƣợng.
1.5 Cơng đoạn phát triển trong GCPM
Khi nói đến gia cơng, ta nghĩ ngay đến các cơng việc có giá trị thấp. Chỉ các cơng
việc “cấp thấp”, có giá trị gia tăng thấp đƣợc đƣa đi gia công, các công đoạn “cao
cấp”, có giá trị gia tăng cao vẫn phải đƣợc thực hiện ở cơng ty chính.

Luận văn thạc sĩ – MIS khoá 2009


- 14 Ví dụ trong ngành may mặc, từ khi định hƣớng sản phẩm đến thiết kế mẫu áo, có
thể kể cả khâu chọn vải, cắt khuôn do công ty chính thực hiện, chỉ có các phần nhƣ
vắt sổ, thêu hình, may đƣợc đƣa đi gia cơng. Sau khi may xong, khâu kiểm tra chất
lƣợng, phân phối lại do công ty chính thực hiện.
Một ví dụ khác là Iphone của Apple, mẫu mã, chức năng điện thoại, kể cả cấu hình
của các con chip do các kỹ sƣ của Apple thiết kế, công việc sản xuất gia công ở Hàn
Quốc, lắp ráp các thiết bị hồn chỉnh đƣợc gia cơng ở Trung Quốc.
Ngành gia công phần mềm cũng tƣơng tự nhƣ vậy, cơng việc đƣợc gia cơng nƣớc
ngồi là những công việc đơn giản, cần nhiều công sức hơn là sự sáng tạo. Trong
mơ hình phát triển phần mềm V-model, các công đoạn thiết kế, xây dựng kiến trúc
phần mềm, triển khai và bảo trì cho khách hàng do các công ty Nhật thực hiện.
Công việc đƣợc gia công là thiết kế chi tiết, hiện thực mã nguồn và kiểm thử trên
từng thành phần.

Cơng đoạn đƣợc giao gia cơng

Hình 1-2) V-model - />
Luận văn thạc sĩ – MIS khoá 2009



- 15 -

Đặc tả hệ thống
100
Những việc khác

80

Thiết kế cơ bản

60
40
Nghiên cứu kỹ
thuật

20

Thiết kế chi tiết

0

Việt Nam

Test hệ thống

Test kết hợp

Trung Quốc

Lập trình


Test đơn vị

Biểu đồ 1-5) Thống kê các công đoạn được gia công năm 2010 [8]

Chất lƣợng phần mềm phụ thuộc vào tồn cả q trình phát triển phần mềm, từ việc
lấy yêu cầu khách hàng cho đến thiết lập môi trƣờng cho hệ thống. Một phần mềm
bắt đầu từ một thiết kế chất lƣợng kém không thể cho ra sản phẩm có chất lƣợng tốt,
dù các kỹ sƣ lập trình có trình độ kỹ thuật cao đến mấy. Vì gia cơng phần mềm chỉ
làm một phần trong quy trình phát triển phần mềm nên cần phải xác định phƣơng
pháp đánh giá chất lƣợng hợp lý phản ánh đƣợc sự liên quan giữa các quy trình,
đánh giá đƣợc chính xác chất lƣợng cơng việc đƣợc gia cơng, phần công việc mà
công ty đảm nhận .

Luận văn thạc sĩ – MIS khoá 2009


- 16 -

CHƯƠNG 2

CƠ SỞ LÝ THUYẾT CỦA ĐỀ TÀI

2.1 Phương pháp đánh giá chất lượng
2.1.1 Định nghĩa đánh giá chất lượng
Để đánh giá chất lƣợng cần phải xác định các đặc tính chất lượng, các yếu tố phản
ánh đặc tính này, yêu cầu chất lƣợng đối với các đặc tính này (tiêu chí đánh giá),
phương pháp đo và cách đánh giá (đánh giá giữa tiêu chí và kết quả đo). Vấn đề
quan trọng là phải xác định đƣợc thuộc tính phản ánh các đặc tính u cầu, định
lƣợng hóa đƣợc các thuộc tính này để có thể đo lƣờng và đánh giá.


Product
Đo
lƣờng

Phép
đo

Giá trị ðo
Thuộc
tính

Giá trị ðo
Thuộc
tính

Thuộc
tính

Giá trị ðo

Hình 2-1) Khái niệm đo lường [9]

Thuộc tính (attribute) là các tính chất vật lý hoặc trừu tƣợng của một thực thể, có
thể đo lƣờng đƣợc.
Đo lƣờng (measurement) là dùng các phép đo để gán một giá trị cho thuộc tính của
thực thể.
Phép đo (metric) là cách thức đo lƣờng đƣợc định nghĩa trƣớc.
Giá trị các phép đo (measure) là con số hoặc một sự phân loại cho một thuộc tính
qua các phép đo.


Luận văn thạc sĩ – MIS khoá 2009


- 17 Yếu tố đo
lường

Ví dụ

Thuộc tính –
Attribute

Mã nguồn, bản thiết kế
Thao tác của chƣơng trình, thời gian sử dụng

Đo lƣờng –
Gán thuộc tính các giá trị nhƣ con số, màu sắc, phân loại
Measurement Có nhiều cách đo: gián tiếp và trực tiếp, chủ quan và khách quan.
Phép đo –
Metric

Phải có scale (độ đo) xác định trong các phép đo. Ví dụ do độ lớn
chƣơng trình dùng số dịng mã nguồn, nhƣng số dịng mã nguồn
này phụ thuộc vào ngơn ngữ nên phải có scale thích hợp

Giá trị đo –
Meassure

Là các loại khác nhau của độ đo (scale)
Nominal (Rời rạc)

- Phân loại lỗi
Ordinal (Thứ tự)
- Thứ tự các thành phần tốt
Interval (Các khoảng) - Thang chia độ C, bách phân
Ratio (Tỉ lệ)
- Thời gian cần thiết
Absolute (Tuyệt đối) - Số dòng mã nguồn, số lỗi

Bảng 2-1) Các yếu tố trong đo lường [9]

2.1.2 Đánh giá chất lượng theo phương pháp GQM
Phƣơng pháp GQM (Goal – Question - Metric) do Basili et al.[10] đƣa ra năm 1994.
Mơ hình GQM là cấu trúc dạng cây phân cấp, bắt đầu bằng việc xác định mục tiêu,
đối tƣợng và quan điểm đo lƣờng (Goal). Từ mục tiêu đo lƣờng, các câu hỏi đƣợc
thiết lập để phân loại đánh giá các mục tiêu (Question). Cuối cùng một tập các dữ
liệu tƣơng ứng với từng câu hỏi đƣợc xây dựng để định lƣợng hóa kết quả của câu
hỏi (Metric).

Hình 2-2) Cây phân cấp trong mơ hinh GQM [11]

Luận văn thạc sĩ – MIS khoá 2009


- 18 Mơ hình này có thể sử dụng độc lập hoặc kết hợp với các phƣơng pháp khác để cải
tiến chất lƣợng phần mềm.

Hình 2-3) Luồng thơng tin trong mơ hình GQM [11]

GQM là phƣơng pháp hiệu quả trong việc định lƣợng hóa, đánh giá những yếu tố
có tính chất định tính, và rất phù hợp để đánh giá khái niệm trừu tƣợng nhƣ chất

lƣợng. Ví dụ để đánh giá hệ thống có bảo trì tốt hay khơng, chúng ta có thể đặt
các câu hỏi và phƣơng pháp đo nhƣ sau (tập các câu trả lời).
Question

Metric

Thời gian trung bình để sữa chữa một thành phần

> 10 tiếng
10 tiếng
<10 tiếng

Thời gian trung bình cần thiết để một lập trình viên mới
> 2 ngày
tham gia dự án đọc hiểu cấu trúc mã nguồn một thành phần 2 ngày
< 2 ngày

Luận văn thạc sĩ – MIS khoá 2009


×