ThựC HiệN ChiếN LượC ChấT LượNg PhầN MềM Theo ChuẩN Iso

Thực hiện chiến lược chất lượng phần mềm

Trường: Đại Học Bách Khoa Học Viên: Huỳnh Thi Kim ChâuKhoa : Cơ Khí MSHV : 09270559Ngành : Kỹ Thuật Hệ Thống Công Nghiệp Lớp Cao Học Khóa 2009

----------------//----------------

Bài Tiểu Luận

THỰC HIỆN CHIẾN LƯỢC CHẤT LƯỢNG PHẦN MỀM THEO CHUẨN ISO

Thầy chủ nhiệm bộ môn: Nguyễn Như PhongPage 1 of 33


Mục Lục

I. Giới Thiệu………………………………………………………………3

II. Thế nào là PM có chất lượng…………………………………………...4

III. Cách tiếp cận của ISO…………………………………………..............4

IV. Một số bài viết của các chuyên gia……………………………………..6

V. Kỹ sư chất lượng thường thực hiện các hoạt động cụ thể nào………….8

VI. Đánh giá chất Lượng phần mềm với ISO 9126………………………..11

VII. Quản lý chất lượng phần mềm…………………………………………18

Page 2 of 33


I. GIỚI THIỆU

Trong kỷ nguyên hiện đại, phần mềm (PM) đóng vai trò vô cùng quan trọng, có thể so sánh như một hệ thần kinh số điều khiển tàn bộ hạt động hệ thống thông tin tàn cầu. Trng bối cảnh đó, một sai lầm, dù rất nhỏ của PM cũng có thể gây ra hậu quả khôn lường. Chỉ vì một dấu phẩy nhầm lẫn trng hệ thống PM điều khiển mà tàu vũ trụ Apll 11 của Mỹ đã nổ tung khi phóng lên quỹ đạ, gây thiệt hại hàng tỷ USD và nghiêm trọng là đã cướp đi mạng sống của tàn bộ phi hành đàn. Chất lượng PM đang là vấn đề làm đau đầu cả giới sản xuất và ứng dụng. The kết quả nghiên cứu của Viện Công Nghệ và Tiêu Chuẩn

Quốc Gia (NIST) thuộc Bộ Thương Mại Mỹ, các nhược điểm trng PM không chỉ gây phiền phức ch người dùng mà hàng năm còn gây tổn thất lớn ch nền kinh tế Mỹ ước tính 59,5 tỷ USD. Tuy nhiên, cũng the NIST, thử nghiệm để phát hiện và lại bỏ khiếm khuyết ngay từ quá trình sản xuất PM có thể giảm mức thiệt hại khảng 22,2 tỷ USD trng tổng số 59,5 tỷ này. Khái niệm chất lượng PM có vẻ không mới, nhưng thực sự đó là khái niệm không dễ nắm bắt và làm chủ. Cùng với sự tăng trưởng mạnh của ngành PM Việt Nam, đã đến lúc chúng ta phải dànhsự quan tâm đúng mức ch chất lượng PM. Thời gian gần đây, nhiều danh nghiệp (DN) Việt Nam đã nhận thức đúng về vai trò của chất lượng PM và định hướng xây dựng các quy trình sản xuất PM theo chuẩn quốc tế với mục đích sản xuất PM chất lượng.

Page 3 of 33


II. Thế nào là PM có chất lượng

Chất lượng PM... Thế nào là PM có chất lượng? Có người ch rằng chất lượng PM là tốc độ thực hiện tốt. Người khác ch rằng PM có chất lượng là PM phù hợp với công việc của họ. Cũng có người ch rằng PM không có lỗi là PM có chất lượng ca. Hay PM phải dễ sử dụng mới được gọi là có chất lượng...Tổng kết lại, người ta ch rằng PM có chất lượng là PM "thỏa mãn được yêu cầu của người dùng".Nhưng thế nà là thỏa mãn người dùng? The định nghĩa hình thức về chất lượng PM của Tổ Chức Tiêu Chuẩn Quốc Tế IS trng bộ tiêu chuẩn 8402, "chất lượng là khả năng đáp ứng tàn diện nhu cầu của người dùng về tính năng cũng như công dụng được nêu ra một cách tường minh hặc không tường minh trng những ngữ cảnh xác định". Ngay trng định nghĩa này chất lượng cũng được định nghĩa một cách rất "mờ", thiếu hẳn yếu tố định lượng. Thế nà là nhu cầu được nêu ra một cách "không tường minh"? Thêm nữa, hiểu hết nhu cầu của người sử dụng quả thực là rất khó. Bản thân chúng tôi, những người phát triển PM chuyên nghiệp, thường xuyên gặp cảnh người mua PM thậm chí không hiểu mình đang muốn gì. Khách hàng còn không biết nhu cầu của mình, làm sa chúng tôi có thể thỏa mãn nhu cầu đó?Với những khó khăn về định lượng trng khái niệm chất lượng PM, để có được một PM tốt, cách thông thường nhất là tiếp cận the lối chất lượng quy trình. Nôm na, nếu bạn có quy trình sản xuất tốt, bạn sẽ có khả năng sản xuất ra sản phẩm tốt.

III Cách tiếp cận của ISO

... Và cách tiếp cận của IS

Page 4 of 33


Trước hết cần kể đến bộ tiêu chuẩn chất lượng IS 9001-3 của tổ chức IS, quy định về "Quy trình đảm bả chất lượng" trng các tổ chức phát triển PM. Chứng chỉ IS 9001 xác nhận các tổ chức, đơn vị có quy trình đảm bả chất lượng hợp chuẩn.Bên cạnh đó, một mô hình khác là CMM cũng đang rất được quan tâm tại Việt Nam. Công ty nhận được chứng chỉ CMM, nghĩa là công ty đó đã "trưởng thành" ở một mức độ tương ứng với các cấp độ CMM của chứng chỉ. Một DN phát triển PM, nếu có chứng chỉ CMM hặc IS 9001 đều có khả năng sản xuất ra các PM tốt hơn hẳn các công ty chưa có chứng chỉ. Tuy nhiên, chúng ta cần lưu ý đây chỉ là "khả năng" chứ không phải là "chắc chắn". Vẫn có DN có quy trình tốt nhưng sản xuất ra sản phẩm chất lượng không ca. Điều này chứng tỏ cách tiếp cận the lối chất lượng quy trình chưa phải là cách tiếp cận tàn diện mà chỉ giải quyết vấn đề ở mức căn bản.Những năm cuối thế kỷ 20, tổ chức IS đã tập trung rất nhiều và các tiêu chuẩn chất lượng ch PM. Và cách tiếp cận về chất lượng của IS đã thực sự tiến thêm một bậc, tàn diện hơn, phù hợp hơn. Kết quả của sự tập trung này là một lạt các bộ tiêu chuẩn nhằm hướng tới chất lượng tàn diện trng suốt vòng đời của sản phẩm PM, từ khi phôi thai ch tới lúc lạc hậu cần thay thế. The cách tiếp cận của IS, chất lượng tàn diện của PM cần phải được quan tâm từ chất lượng quy trình, tới chất lượng sản phẩm nội bộ, chất lượng sản phẩm đối sánh với yêu cầu của người dùng (chất lượng hướng ngại), và chất lượng PM trng sử dụng (Hình 1).

Ở một góc nhìn khác, vòng đời của một sản phẩm PM bắt đầu từ các bài tán thực tiễn và được thể hiện the quy trình sau:

1. Từ các bài tán thực tiễn, nhu cầu về PM hình thành;

2. Nhu cầu này được thể hiện qua các tài liệu yêu cầu (requirements);

3. Nhu cầu sẽ xác định yêu cầu chất lượng hướng ngại. Thỏa mãn được yêu cầu chất lượng này sẽ thỏa mãn được yêu cầu của người sử dụng;

4. Các yêu cầu chất lượng được thể hiện trng tài liệu đặc tả hệ thống (Specificatin);5. Yêu cầu chất lượng hướng ngại là tiền đề ch yêu cầu chất lượng nội bộ;6. Trng quá trình thiết kế PM, các yêu cầu chất lượng nội bộ được thể hiện trng các đặc tính của PM và chuyển thành chất lượng nội bộ;7. Ứng với chất lượng nội bộ có các độ đ chất lượng nội bộ mà PM phải vượt qua;8. Tới giai đạn tích hợp chạy thử, chất lượng hướng ngại sẽ là vấn đề được quan tâm. PM được gọi là có chất lượng khi tất cả các độ đ chất lượng ngài được đảm bả;9. Trng quá trình vận hành, vẫn sử dụng các độ đ ngài, chất lượng của PM trng quá trình vận hành, sử dụng sẽ tiếp tục được xem xét và cải tiến;10. Và quá trình cải tiến liên tục sẽ diễn ra ch tới khi PM trở nên lạc hậu hàn tàn, cần được thay thế bằng một PM mới (Hình 2).

Với cách tiếp cận như vậy, IS đã ch ra đời một lạt các bộ tiêu chuẩn liên quan tới chất lượng PM. Trng các bộ tiêu chuẩn đó (Hình 3):1. Bộ tiêu chuẩn IS-9001/2000-3 phục vụ ch việc chuẩn hóa quy trình chất lượng;

Page 5 of 33


2. Bộ tiêu chuẩn IS-14598 thiết lập các chuẩn trng việc đánh giá một PM;3. Bộ tiêu chuẩn IS-9126 thiết lập một mô hình chất lượng chuẩn ch các sản phẩm PM. Bộ tiêu chuẩn này được chia làm bốn phần: 9126-1 nói về mô hình chất lượng sản phẩm PM9126-2 nói về các độ đ hướng ngại 9126-3 nói về các độ đ nội bộ 9126-4 nói về các độ đ ch chất lượng sản phẩm PM trng quá trình sử dụng.ÿ(Kỳ sau: Mô hình chất lượng IS - 9126).

IV. MỘT SỐ BÀI VIẾT CỦA CÁC CHUYÊN GIA

(TBVTSG) - Cùng là những chuyên gia hạt động trong ngành thiết kế và phát triển phần mềm, nhưng có chút rắc rối trong tên gọi của các kỹ sư chất lượng, kỹ sư kiểm định và vai trò của họ trên thực tế cũng khác nhau.

Bài viết dưới đây của ông Ngô Văn Tàn, Phó tổng giám đốc Công ty Glbal CyberSft Việt Nam, sẽ giúp chúng ta hiểu rõ hơn về lực lượng chuyên gia quan trọng này.

Khi các công ty phần mềm Việt Nam có sự phát triển về tầm vóc cũng như sự gia tăng về số lượng các dự án thực hiện ch các khách hàng quốc tế – vốn đòi hỏi các quy trình kiểm sát chất lượng nghiêm ngặt – thì đã xuất hiện nhu cầu tuyển dụng các chuyên viên đảm nhận vai trò của các kỹ sư bả đảm chất lượng phần mềm hay kỹ sư giám sát quy trình chất lượng (gọi chung là kỹ sư chất lượng).

Vai trò của kỹ sư chất lượng dù không mới trên thế giới nhưng còn khá mơ hồ và chưa được ứng dụng nhiều tại Việt Nam. Bài viết này nhằm khái quát vài nét cơ bản về lực lượng chuyên gia quan trọng này.

Rắc rối tên gọi và chức năng

Page 6 of 33


Trng thực tế, tên gọi hặc vai trò của các kỹ sư chất lượng thường có sự lẫn lộn với tên gọi của kỹ sư kiểm định, ngay cả trng một số tài liệu lẫn tên gọi chính thức ở một số công ty.

Có rất nhiều tên gọi khác nhau dành ch hai nhóm kỹ sư này, nhưng bốn tên gọi (tiếng Anh) được sử dụng nhiều nhất ch hai nhóm kỹ sư này là QA (Quality Assurance) – Bả đảm chất lượng; SQA (Sftware Quality Assurance) – Bả đảm chất lượng phần mềm; QC (Quality Cntrl) – Kiểm sát chất lượng; Tester hay Testing Engineer – Kỹ sư kiểm định.

Một số công ty hặc tài liệu có sử dụng QA/SQA để chỉ kỹ sư chất lượng; QC/Testing để chỉ kỹ sư kiểm định. Một số khác thì ngược lại, dùng QA/SQA để chỉ kỹ sư kiểm định; QC để chỉ kỹ sư chất lượng.

Một số công ty tại Việt Nam còn sử dụng hai tên gọi khác là SQA và PQA để chỉ kỹ sư kiểm định và kỹ sư chất lượng. Để bạn đọc tiện the dõi, bài viết này thống nhất chỉ sử dụng hai tên gọi là kỹ sư chất lượng (Quality Engineer) và kỹ sư kiểm định (Testing Engineer).

Cách tốt nhất để hiểu và phân biệt kỹ sư chất lượng và kỹ sư kiểm định là phân biệt sự khác nhau trng hạt động của họ.

Công việc của kỹ sư kiểm định liên quan đến việc giám sát chất lượng của sản phẩm dự án, nói the chuyên môn là để bả đảm dự án sản xuất ra đúng cái cần phải làm.

Ví dụ: kiểm định để bả đảm phần mềm trả về các bá cá kế tán đúng mẫu thiết kế với số liệu chính xác, có thể đáp ứng ch 1.000 người sử dụng cùng một lúc…

Công việc của kỹ sư chất lượng liên quan đến việc giám sát sự tuân thủ quy trình thực hiện trng dự án, nói the chuyên môn là để bả đảm mọi thứ trng dự án được thực hiện một cách đúng đắn. Ví dụ: kiểm tra để bả đảm các yêu cầu thay đổi của khách hàng phải được phân tích kỹ lưỡng trước khi thực hiện, nhân viên phải được huấn luyện kỹ năng…

Page 7 of 33

http://www.hatgiong.net/ads/www/delivery/ck.php?n=ad445abe&cb=INSERT_RANDOM_NUMBER_HERE


The hình trên, kiểm định là một chặng trng quy trình sản xuất phần mềm, trng khi các hạt động giám sát chất lượng và quản trị dự án phải được thực hiện xuyên suốt trng chu kỳ sản xuất.

D sự quan trọng của hai nhóm hạt động này, cả hai mô hình và tiêu chuẩn nổi tiếng CMMi của SEI và IS 9001[*] thường được sử dụng trng các tổ chức phần mềm đều xem chúng như là một trng những yêu cầu cơ bản nhất.

Kỹ sư chất lượng làm gì?

Tùy the tổ chức và quy trình sản xuất riêng biệt của từng công ty, công việc của các kỹ sư chất lượng có sự khác nhau.

Về cơ bản, kỹ sư chất lượng có các hạt động chính như tham gia phát triển quy trình hạt động ở cấp công ty và ở cấp dự án; giám sát và kiểm tra các hạt động được thực hiện trng dự án xem chúng có tuân thủ các quy trình đã được định ra; đánh giá các tài liệu, các sản phẩm và sản phẩm trung gian trng dự án the các tiêu chuẩn đã định trước; bá cá các lỗi không tương thích (prcess nncmpliance – gọi tắt là NC) ch các cá nhân có liên quan và các cấp quản lý; giám sát để bả đảm các vi phạm và các NC được giải quyết ch đến khi hàn tất.

V. Kỹ sư chất lượng thường thực hiện các hoạt động cụ thể nào

Trong một dự án, kỹ sư chất lượng thường thực hiện các hạt động cụ thể sau:

1. Tham gia phát triển và đánh giá các quy trình cấp dự án. Cùng với trưởng dự án, kỹ sư chất lượng sẽ tham gia và việc phát triển các quy trình cần thiết để quản trị và kiểm sát dự án, phát triển phần mềm và bả đảm chất lượng.

Quá trình này thường ba gồm việc xem xét và điều chỉnh các quy trình cấp công ty (thuật ngữ chuyên môn gọi là tailring hặc custmizing), và khi cần thiết định nghĩa quy trình mới để phù hợp và phục vụ ch các yêu cầu và đặc điểm riêng của dự án.

Việc định nghĩa quy trình cũng ba gồm việc chỉ định các công cụ và tiêu chuẩn cần thiết hỗ trợ ch dự án. Các quy trình này sẽ là cơ sở để thực hiện các hạt động của dự án cũng như để giám sát chất lượng dự án.

Để đạt hiệu quả ca, các quá trình này có thể ba gồm sự tham gia của các chuyên gia bên trng lẫn ngài công ty, khách hàng, cấp quản lý có kinh nghiệm hặc có liên quan đến việc phát triển các quy trình kiểm sát ch dự án.

Page 8 of 33

Hạt động giám sát quy trình chất lượng diễn ra xuyên suốt dự án


2. Giám sát quy trình quản lý dự án. Kỹ sư chất lượng sẽ chủ yếu dựa và các kế hạch trng dự án, các quy trình, tiêu chuẩn và cam kết với khách hàng để đánh giá các hạt động quản trị dự án, từ đó xác định NC, ghi nhận và yêu cầu trưởng dự án khắc phục.

Một số bá cá lỗi không tương thích thường gặp là kế hạch dự án đã không được xem xét và phê chuẩn trước khi thực hiện; bản phân công công việc không được cập nhật khi kế hạch thay đổi; bá cá tiến độ dự án không có đủ các thông tin như yêu cầu; nhân viên mới tham gia dự án đã không được huấn luyện để hiểu hệ thống.

3. Giám sát quy trình quản lý cấu hình (Cnfiguratin Management). Quản lý cấu hình là một hạt động cơ bản trng mọi dự án, giúp quản lý và kiểm sát mọi tài liệu, sản phẩm, surce cde... trng dự án. Kỹ sư chất lượng giúp giám sát để bả đảm các hạt động quản lý cấu hình được thực hiện the đúng các kế hạch, quy trình và tiêu chuẩn đề ra.

Trng trường hợp này, các bá cá lỗi không tương thích thường gặp ba gồm: các tài liệu quan trọng không được xác định rõ để có kiểm sát phù hợp; surce cde không được lưu trữ dự phòng (backup) trên máy chủ; quy tắc kiểm sát các thay đổi trng dự án không được thực hiện.

4. Giám sát các quy trình kiểm tra và thẩm định (Verificatin and Validatin).Tham gia các buổi xem xét và khả sát kỹ thuật trng dự án để bả đảm chúng được thực hiện the đúng kế hạch và quy trình với kết quả và các sai sót tìm thấy phải được ghi nhận đầy đủ. Sau đó, tiếp tục giám sát để bả đảm các thỏa thuận và lỗi phải được thực thi, chỉnh sửa hàn tất, và bá cá những người có liên quan.

Ở đây, các bá cá lỗi không tương thích thường gặp là bản thiết kế kiến trúc đã không được xem xét và thẩm định; cde không được khả sát kỹ lưỡng (cde review) để lại bỏ lỗi rác; yêu cầu thay đổi của khách hàng đã không được xem xét và đánh giá trước khi đưa và tích hợp và thiết kế.

5. Giám sát các hạt động kiểm định (Testing). Hạt động kiểm định có ý nghĩa đặc biệt quan trọng trng tàn bộ quy trình phát triển phần mềm d sự liên quan trực tiếp nhất đến chất lượng sản phẩm và sự thỏa mãn khách hàng, d đó nó là đối tượng quan trọng để kiểm sát chất lượng.

Việc giám sát nhằm bả đảm ch các hạt động kiểm định được thực hiện đúng kế hạch và tuân thủ các tiêu chuẩn, bả đảm ch chất lượng của sản phẩm được khả sát kỹ càng trước khi bàn gia ch khách hàng. Đối tượng khả sát thường ba gồm các kế hạch kiểm định, các tiêu chuẩn, thủ tục, dữ liệu và kết quả kiểm định.

Những bá cá lỗi không tương thích có thể gặp gồm: kỹ sư kiểm định không được huấn luyện để hiểu đặc thù của hệ thống; kiểm định đơn vị (Unit Test) đã không được lên kế hạch và thực thi nghiêm túc; trưởng dự án không xem xét và xác nhận kế hạch và chiến lược kiểm định.

6. Giám sát các quy trình phát triển phần mềm (Sftware Engineering). Kỹ sư chất lượng tham gia và tàn bộ các quy trình kỹ thuật của chu trình phát triển phần mềm, bả đảm quy trình và tiêu chuẩn ch các chặng và mức kỹ thuật được định nghĩa rõ ràng và thực thi nghiêm túc. Các

Page 9 of 33


quy trình và tiêu chuẩn kỹ thuật này được định nghĩa khác nhau tùy the yêu cầu và đặc trưng của từng dự án. Các quy trình cơ bản nhất gặp trng hầu hết các dự án phần mềm được liệt kê ở mục 3.

Việc giám sát quy trình ở các chặng kỹ thuật đòi hỏi kỹ sư chất lượng phải có kinh nghiệm và kiến thức nhất định về kỹ thuật, đặc biệt là khả năng sử dụng các công cụ hỗ trợ. Ngược lại, kỹ sư chất lượng sẽ gặp nhiều trở ngại, không hiểu chính xác những gì đang thật sự xảy ra, d đó rất khó xác định các vấn đề về chất lượng và bất tương thích quy trình.

7. Giám sát các quy trình đặc thù cần thiết ch dự án. Nếu dự án – d nhu cầu riêng hặc yêu cầu từ khách hàng – có những quy trình đặc thù cần phải tuân thủ, kỹ sư chất lượng sẽ giám sát việc thực thi nghiêm túc các quy trình này. Một số quy trình đặc thù là quy trình phối hợp với khách hàng, quy trình bá cá lỗi sử dụng hệ thống của khách hàng, quy trình kiểm sát thay đổi…

Page 10 of 33


VI. ISO 9126

IS 9126 là tiêu chuẩn quốc tế đánh giá phần mềm. Tiêu chuẩn này được giám sát bởi dự án SQuaRE, IS 25000:2005 dựa trên các khái niệm chung tương đương nhau.

Tiêu chuẩn này được phân chia thành 4 phần tuân the một cách nghiêm ngặt các tiêu chí sau: mẫu chất lượng, hệ đ lường bên ngài và bên trng, chất lượng khi sử dụng hệ đ lường này.

Mẫu chất lượng được thiết lập ở phần đầu của tiêu chuẩn, mô hình này được đặt tên là IS 9126-1, phân lại chất lượng phần mềm theo một chuỗi có tổ chức các đặc trưng và đặc trưng phụ như dưới đây:

1 Tính chức năng 2 Tính tin cậy

3 Tính tiện lợi

4 Tính hiệu quả

5 Tính duy trì

6 Tính năng dễ mang theo

Page 11 of 33

http://vi.wikipedia.org/wiki/ISO_9126#T.C3.ADnh_n.C4.83ng_d.E1.BB.85_mang_theo

http://vi.wikipedia.org/wiki/ISO_9126#T.C3.ADnh_duy_tr.C3.AC

http://vi.wikipedia.org/wiki/ISO_9126#T.C3.ADnh_hi.E1.BB.87u_qu.E1.BA.A3

http://vi.wikipedia.org/wiki/ISO_9126#T.C3.ADnh_ti.E1.BB.87n_l.E1.BB.A3i

http://vi.wikipedia.org/wiki/ISO_9126#T.C3.ADnh_tin_c.E1.BA.ADy

http://vi.wikipedia.org/wiki/ISO_9126#T.C3.ADnh_ch.E1.BB.A9c_n.C4.83ng


[sửa] Tính chức năng

Một chuỗi các tính năng mà có liên quan đến sự tồn tại của hàng lạt các chức năng và những thuộc tính cụ thể của nó. Những chức năng này làm thả mãn cả nhưng nhu cầu đã xác định hặc tiềm năng:

Phù hợp Đúng đắn

Liên kết tốt giữa cn người, dữ liệu và hệ thống

Làm đúng the yêu cầu.

Tính bả mật

[sửa] Tính tin cậy

Một chuỗi các tính năng có liên quan đến khả năng duy trì mức độ thực hiện của phần mềm trng những điều kiện đã định trng một khảng thời gian nhất định:

Xử lý tin cậy Khả năng khôi phục dữ liệu

khả năng tìm lỗi, bá lỗi

[sửa] Tính tiện lợi

Một chuỗi các tính năng có liên quan đến những nỗ lực cần thiết ch việc sử dụng và có liên quan đến những đánh giá mang tính cá nhân đối với việc sử dụng của hàng lạt người dùng đã định hay tiềm năng:

Dễ học thuộc, dễ hiểu, dễ thành thạ, dễ sử dụng

[sửa] Tính hiệu quả

Những tính năng mà có liên quan đến mối quan hệ giữa mức độ thực hiện của phần mềm và khối lượng tài nguyên được sử dụng trng những điều kiện nhất định:

Quản lý thời gian Quản lý nguồn tài nguyên

[sửa] Tính duy trì

Những tính năng mà có liên quan đến những nỗ lực cần thiết ch việc tạ ra những biến đổi cụ thể.

Page 12 of 33

http://vi.wikipedia.org/w/index.php?title=ISO_9126&action=edit&section=5






Chạy ổn định Có khả năng phân tích dữ liệu

Có khả năng thay đổi phù hợp

Có khả năng kiểm tra

[sửa] Tính năng dễ mang the

Những tính năng mà có liên quan đến khả năng chuyển rời phần mềm từ nơi này đến nơi khác:

Khả năng cài đặt Khả năng thay thế, cập nhật và nâng cấp

Khả năng thích hợp với nhiều cấu hình máy tính.

Đặc trưng phụ Tính thích hợp không được liệt kê ở trên nhưng áp dụng đối với tất cả các đặc trưng. Ví dụ của tính thích hợp đối với pháp chế ba gồm tính tiện lợi và tính đáng tin cậy.

Mỗi đặc trưng phụ về chất lượng (như khả năng thích nghi) được phân chia thành 4 tính năng. Mỗi tính năng là một thực thể có thể được kiểm tra lại hặc giới hạn trng sản phẩm phần mềm. Những tính năng này không được định nghĩa trng tiêu chuẩn vì chúng rất khác nhau trng những sản phẩm phần mềm khác nhau.

Sản phẩm phần mềm được định nghĩa the nghĩa rộng: nó ba gồm lệnh thi hành, mã nguồn, những miêu tả về cấu trúc,...Từ đó, những quan điểm của người sử dụng được gửi ch những nhà quản lí cũng như những người lập trình. Đó chính là những người sử dụng các thành phần của phần mềm như những thư viện phần mềm.

Tiêu chuẩn này tạ ra khuôn khổ giúp các tổ chức xác định mẫu chất lượng ch sản phẩm phần mềm. Tuy nhiên, làm như vậy dẫn đến việc mỗi danh nghiệp sẽ phải thực hiện nhiệm vụ chi tiết một cách rõ ràng các mô hình của mình. Nhiệm vụ này sẽ được thực hiện bằng nhiều cách, ví dụ như việc cụ thể các ý nghĩa của mục tiêu về hệ đ lường chất lượng mà đánh giá mức độ các tính năng về chất lượng hiện có trng sản phẩm.

Hệ đo lường bên trng không dựa trên việc triển khai sử dụng phần mềm

Hệ đo lường bên ngài có thể được áp dụng khi chạy phần mềm Chất lượng sử dụng hệ đ lường chỉ có giá trị khi sản phẩm cuối cùng được đưa và sử dụng trng những điều kiện thực tế.

Thật lý tưởng khi chất lượng bên trng xác định được chất lượng bên ngài và chất lượng bên ngài xác định chất lượng khi sử dụng. Tiêu chuẩn này bắt nguồn từ một mô hình được xây dựng và năm 1977 của McCall và đồng nghiệp của ông, những người đã đề xuất một mô hình có thể xác định được chất lượng phần mềm. Mô hình chất lượng của McCall được xây dựng dự trên 3 lại đặc trưng về chất lượng:

Page 13 of 33



. Các yếu tố (để xác định): Các yếu tố này miêu tả hình dáng bên ngài của phần mềm trng mắt người sử dụng . Tiêu chuẩn (để xây dựng): Tiêu chuẩn này miêu tả cấu tạ bên trng của phần mềm bởi người phát triển nó. . Hệ đ lường (để kiểm sát): Chúng được xác định và được sử dụng nhằm mục đích cung cấp một tỷ lệ và phương thức ch sự đ lường IS 9268 giúp phân biệt giữa nhược điểm và sự bất quy tắc; nhược điểm là việc không hàn thành các yêu cầu sử dụng đã dự định, trng khi đó sự bất qui tắc là việc không hàn thành các yêu cầu chi tiết. Một cách phân biệt tương tự giữa xác nhận và xác minh hay còn được biết đến là V&V trng kinh danh thử nghiệm.

Thư ký / Điều phối viên IS là một vị trí công việc từ lâu đã trở lên rất quen thuộc với các tổ chức tư vấn quản lý chất lượng, tổ chức chứng nhận và các tổ chức đã và đang áp dụng Hệ thống quản lý chất lượng the tiêu chuẩn IS 9000. Với khảng hơn 5000 tổ chức được ch là đã và đang thực hiện IS 9000, số lượng các thành viên của cộng đồng Thư ký IS/ Điều phối viên IS cũng ở mức tương đương hặc lớn hơn. Vậy Thư ký / Điều phối viên IS là ai, vị trí của họ ở đâu trng tổ chức, họ làm những công việc gì, họ cần các kiến thức và năng lực gì để thực hiện công việc của mình? Đây là những câu hỏi mà nhiều tổ chức thực hiện IS 9000 đang đi tìm câu trả lời nhằm nâng ca hiệu quả hạt động của Thư ký IS /Điều phối viên IS nói riêng và hiệu quả của cả Hệ thống chất lượng nói chung.

Từ năm 2005, P & Q Slutins đã bắt đầu phát triển và cung cấp một chương trình tổng thể với các khóa đà tạ nhằm mục đích nâng ca năng lực của đội ngũ cán bộ quản lý chất lượng và quản lý Hệ thống chất lượng. Các khóa đà tạ này nhằm cung cấp ch các nhân sự trng lĩnh vực quản lý chất lượng những công cụ và kỹ năng trng quản lý chất lượng và kỹ năng mềm cần thiết để triển khai chức năng quản lý chất lượng trng tổ chức.

Trng năm 2008, P & Q Slutins đã xây dựng một chương trình đà tạ dành riêng ch Thư ký IS /Điều phối viên IS trên cơ sở tổng hợp một số nội dung đà tạ trng Series đà tạ đã phát triển và bổ sung một số nội dung mới ch phù hợp với đối tượng đà tạ. Chương trình đà tạ Thư ký IS /Điều phối viên IS với thời lượng 05 ngày (liên tục) ba gồm các nội dung đà tạ sau đây:

Page 14 of 33


a) Phần 1 – Hệ thống quản lý chất lượng the IS 9000

o Tổng quan về chất lượng và quản lý chất lượng,

o Ứng dụng các nguyên lý của quản lý chất lượng trng hạt động của tổ chức,

o Quản lý chất lượng the IS 9000: Bốn giai đạn, 3 nhóm giải pháp, 10 khu vực tác

động,

o Tóm tắt các yêu cầu của tiêu chuẩn IS 9001:2000,

o Cập nhật những thay đổi trng phiên bản IS 9001:2008,

o Các tiêu chuẩn hỗ trợ việc thực hiện IS 9000:

· Giới thiệu các tiêu chuẩn hỗ trợ thực hiện HTQLCL,

· IS 9000,

· IS 9004,

· IS 19011.

o Mô hình tài liệu của Hệ thống chất lượng: phân lại, mục đích và yêu cầu,

o Mô hình tổ chức Hệ thống chất lượng:

· Giai đạn xây dựng Hệ thống chất lượng,

Page 15 of 33


· Giai đạn áp dụng và duy trì Hệ thống chất lượng,

· Giai đạn cải tiến Hệ thống chất lượng.

o Vai trò, vị trí và yêu cầu năng lực với cán bộ quản lý Hệ thống chất lượng,

o Xác định và phát triển các chỉ số hạt động chất lượng (KQPIs) ch Hệ thống chất

lượng.

b) Phần 2 – Tổ chức thực hiện và duy trì Hệ thống quản lý chất lượng

Vai trò của lãnh đạ cấp ca và quản lý mối quan hệ với lãnh đạ cấp ca,

Phát triển và kiểm sát các tài liệu của HTCL,

Quản lý chất lượng the các mục tiêu và chỉ tiêu chất lượng,

Tổ chức và quản lý hạt động đánh giá nội bộ,

Tổ chức hạt động xem xét hệ thống chất lượng,

Chuẩn bị và quản lý hạt động đánh giá chứng nhận/giám sát,

Quản lý hạt động đà tạ và giá dục về chất lượng,

Thuyết trình và bá cá dành ch cán bộ quản lý HTQLC,

c) Phần 3 – Cải tiến Hệ thống quản lý chất lượng,

Tổng quan về cải tiến chất lượng và các công cụ cải tiến chất lượng,

Các công cụ chất lượng dùng để mô tả và phân tích hạt động:

· Lưu đồ và sơ đồ quá trình,

· Mô hình quá trình để phân tích hạt động.

· Biểu đồ phân tán/Biểu đồ ma trận,

· Biểu đồ nhân quả.

· Biểu đồ paret/Biểu đồ quạt,

· Biểu đồ tần xuất và chỉ số năng lực quá trình,

· Biểu đồ kiểm sát quá trình – Công cụ the dõi và cảnh bá

Chi phí chất lượng,

Một số công cụ quản lý chất lượng khác,

Quản lý dự án cải tiến chất lượng,

Page 16 of 33


Trong các công ty sản xuất phần mềm, quan niệm về QA hiện nay vẫn chưa thống nhất và bộ phận QA còn nằm lẫn với bộ phận kiểm lỗi (test) sản phẩm.

Thực tế, QA là công việc khác biệt nhiều s với test phần mềm. Dù được chi là sản phẩm “chất xám” và high-tech nhưng để ra đời một phần mềm tốt, quy trình sản xuất phần mềm cũng không khác gì s với việc sản xuất một sản phẩm cụ thể.

Khái niệm QA phần mềm ba gồm PQA (Prcess Quality Assurance - bả đảm chất lượng quy trình) với SQA (Sftware Quality Assurance - bả đảm chất lượng phần mềm).

Tại một số công ty ở VN, SQA được xem như việc kiểm lỗi khi sản phẩm đã định hình. Số khác lại ci SQA là việc kiểm tra đầu ra trung gian của sản phẩm, để sản phẩm đạt được sự nhất quán trng quá trình thực hiện. Dù ở khía cạnh nà thì SQA cũng là kiểm tra trực tiếp sản phẩm.

PQA có 2 việc chính: Một là xây dựng hệ thống quy trình ch danh nghiệp (bằng cách ứng dụng những quy trình quản lý sẵn có như IS hay CMM hặc dựa trên đó xây dựng quy trình chuẩn ch danh nghiệp). Hai là thực hiện việc giám sát, kiểm tra việc thực hiện quy trình của từng bộ phận, từng dự án, từ đó tổng hợp thông tin để đưa ra những cải tiến ch quy trình hạt động tốt.

Với công việc đúng nghĩa như trên thì PQA đang là “của hiếm” trng các công ty phần mềm và cũng là đại diện nghề QA.

Danh nghiệp phần mềm nà cũng hiểu rằng xây dựng được một quy trình quản lý chất lượng tốt chính là cách làm tăng lợi nhuận hơn gấp nhiều lần. Trng chi phí về chất lượng sản phẩm, có 3 lại chi phí cn: chi phí chặn lỗi (preventin cst); chi phí kiểm sát lỗi (cntrl cst) và chi phí xảy ra khi có lỗi (failure). The một số tài liệu về quy trình sản xuất phần mềm (như CMM), 1 đồng bỏ ra ch khâu thứ nhất sẽ làm giảm 10 đồng ch khâu thứ 3, và 1 đồng ch khâu thứ 2 sẽ giảm 3 đồng ch khâu thứ 3. Muốn làm được việc ấy, điều hiển nhiên phải có người đưa quy trình ấy và thực tế. Nhưng để tuyển được một PQA không phải là điều đơn giản.

Chị Lê Phan Việt Hà, nhân viên QA Công ty Phần mềm Tinh Vân, ch biết: Nhìn chung PQA không đòi hỏi phải có kiến thức sâu về công nghệ thông tin (CNTT) như SQA vì không liên quan đến sản phẩm chính của dự án phần mềm. Tuy nhiên, kiến thức của người làm PQA phải rộng và có độ sâu nhất định để hiểu hết công việc trng phạm vi hệ thống mình đang quản lý, đặc biệt là khả năng tổ chức, tư duy lgic và có hệ thống. Ngài ra, kỹ năng gia tiếp và khai thác thông tin của nhân viên PQA cũng quan trọng. Trng công ty có nhiều người, mỗi người giỏi ở một lĩnh vực khác nhau. PQA cần biết khai thác để tận dụng những thông tin đó ch việc xây dựng hệ thống quy trình.

Bà Dương Thị Minh, phụ trách nhóm QA của VietSftware Internatinal, ch biết một nhân viên QA giỏi là người hiểu biết về quy trình ở mức sâu; khả năng trình bày, thuyết phục tốt; biết lắng nghe, để thấy cái gì cần điều chỉnh thì điều chỉnh và cũng để thuyết phục tốt hơn; kỹ năng đ

Page 17 of 33


lường và phân tích số liệu; kỹ năng làm phần mềm (kỹ năng này sẽ được ưu tiên ca khi tuyển dụng).

Nói như vậy, không có nghĩa là một sinh viên CNTT học tốt ra trường có thể làm PQA. Trng trường, sinh viên cũng được dạy về các quy trình làm phần mềm nhưng là học kiểu “cưỡi ngựa xem ha”, chỉ biết làm phần mềm phải the những bước nà. Nhưng giữa các bước đó có liên quan với nhau như thế nà, cần kiểm tra ra sa thì họ chưa hình dung được. Vì vậy, hiện nay hầu hết các công ty đều có chương trình đà tạ riêng ch vị trí này sau thời gian tuyển dụng.

“Thường sau một tháng, một lập trình viên mới có thể bắt nhịp được với công việc. Còn với vị trí PQA, thời gian làm quen ít nhất phải hai tháng. Bởi vì để đà tạ họ hiểu biết về hệ thống, tư duy về hệ thống và hiểu biết về mô hình quản lý chất lượng thì không thể trng một thời gian ngắn. Thông thường họ cũng phải trải qua vài dự án làm việc test lỗi với mức độ khó dần để hình dung được quy trình, nắm bắt được yêu cầu của dự án”, bà Minh ch biết.

Khó khăn như vậy nhưng đây lại là nghề thu hút được giới nữ. Qua khả sát, phần lớn PQA tại các công ty phần mềm hiện nay là nữ. Điều này có lẽ d nghề đòi hỏi tính kiên nhẫn và mềm dẻ trng gia tiếp. Mức thu nhập của nghề cũng không hề kém các vị trí khác trng ngành công nghiệp phần mềm.

Page 18 of 33


VI. Quản lý chất lượng phần mềm

Quản lý chất lượng phần mềm là vấn đề không mới nhưng the một số đánh giá là còn yếu của các công ty phần mềm Việt Nam. Một số công ty trng nước hiện đã đạt các chuẩn quốc tế CMM/CMMI trng nâng ca năng lực và quản lý chất lượng phần mềm, sng chỉ đếm được trên đầu ngón tay, và hiện cũng chỉ gói gọn trng vài công ty gia công ch thị trường nước ngài.

Làm thế nà để một công ty này đạt được chuẩn quốc tế về chất lượng phần mềm? Mỗi công ty đều có đặc thù riêng, tuy nhiên điều chung nhất là họ đều phải phát triển và duy trì một Hệ thống quản lý chất lượng phần mềm.

QUẢN LÝ CHẤT LƯỢNG PHẦN MỀM LÀ GÌ ?

Lâu nay, nói đến chất lượng phần mềm (PM), không ít người nghĩ ngay đến vấn đề là xác định xem PM đó có phát sinh lỗi hay không, có "chạy" đúng như yêu cầu hay không và cuối cùng thường quy về vai trò của hạt động kiểm tra phần mềm (testing) như là hạt động chịu trách nhiệm chính.

Với quan điểm của khách hàng, điều này có thể đúng, họ không cần quan tâm nội tình của hạt động phát triển PM, điều họ cần quan tâm là liệu sản phẩm cuối cùng gia ch họ có đúng hạn hay không và làm việc đúng như họ muốn hay không. .

Tuy nhiên the quan điểm của người phát triển PM, thực tế ch thấy hạt động kiểm tra PM là quan trọng, nhưng không đủ để đảm bả sản phẩm sẽ được hàn thành đúng hạn và đúng yêu cầu. Kiểm tra sau cùng để phát hiện lỗi là điều tất nhiên phải làm, nhưng trng rất nhiều trường hợp, điều đó thường quá trễ và sẽ phải mất rất nhiều thời gian để sửa chữa.

Thực tế ch thấy, để đảm bả được hai tiêu chí "đơn giản" trên của khách hàng, đòi hỏi tổ chức không chỉ vận hành tốt khâu kiểm tra PM, mà phải tổ chức và duy trì sự hạt động nhịp nhàng của cả một hệ thống các công việc liên quan đến một dự án PM, từ đây xuất hiện một khái niệm có tên là "hệ thống quản lý chất lượng phần mềm" (HTQLCLPM), ba gồm các quy trình được thực thi xuyên suốt chu kỳ phát triển của dự án PM.

Page 19 of 33


Hiện có nhiều mô hình cung cấp các tiêu chuẩn cũng như hướng dẫn để triển khai HTQLCLPM. Hai trng số những mô hình được áp dụng rộng rãi hiện nay là IS 9001-2000 và CMM/CMMi. Trng khi IS 9001-2000 là tiêu chuẩn quản lý chất lượng dành ch tất cả các ngành nghề với những điều khản ngắn gọn và mang tính tổng quát, thì CMM/CMMi là một bộ tập hợp khá đồ sộ các kinh nghiệm thực hành (gần 450 trang với CMM, và gần 700 trang với CMMi) có thể làm người đọc chưa có kinh nghiệm khó biết được các hạt động và yếu tố đặc trưng cơ bản của HTQLCLPM là gì.

Qua một số tài liệu tham khả, cũng như bằng kinh nghiệm bản thân khi nghiên cứu và ứng dụng IS 9001-2000 và CMM/CMMi, chúng tôi sẽ trình bày các khái niệm, hạt động cũng như yếu tố cơ bản cấu thành HTQLCLPM.

CĂN BẢN VỀ HTQLCLPM

Một HTQLCLPM thường có 2 mục tiêu (hình 1):

• Mục tiêu thứ nhất: xây dựng chất lượng ch PM ngay từ giai đạn bắt đầu. Điều này đồng nghĩa với việc bả đảm các yêu cầu ch PM từ mọi nguồn khác nhau phải được định nghĩa, diễn đạt và hiểu một cách đúng đắn, giữa người đưa ra yêu cầu và người thực hiện yêu cầu.

• Mục tiêu thứ hai: bả đảm chất lượng của PM xuyên suốt quá trình phát triển.

Một HTQLCLPM hàn chỉnh ba gồm rất nhiều hạt động và bộ phận cấu thành, chúng khác nhau tùy the từng tổ chức khi triển khai. Tuy nhiên, the kinh nghiệm, chúng tôi chỉ giới thiệu 10 hạt động và yếu tố cơ bản nhất thường gặp:

1. Các tiêu chuẩn (Standards)

2. Lập kế hạch (Planning)

3. Xem xét, xem lại (Reviewing)

4. Kiểm tra (Testing)

5. Phân tích lỗi (Defect analysis)

6. Quản lý cấu hình (Cnfiguratin Management)

7. Bả mật (Security)

8. Đà tạ, huấn luyện (Educatin/Training)

9. Quản lý người cung cấp, thầu phụ (Vendr Management)

Page 20 of 33


10. Quản lý rủi r (Risk Management)

(Để đơn giản, từ đây, "10 hạt động và yếu tố" được gọi tắt là "10 yếu tố")

Có mối liên hệ giữa 10 yếu tố cơ bản trên và các giai đạn hay pha phát triển PM. Hình 2 ch thấy sơ đồ liên hệ trng mô hình phát trình waterfall (xem bài "Tổng quan các mô hình phát triển phần mềm", ID: A0508_106 và A0510_122). Ký hiệu "x" gia nhau giữa một yếu tố và một pha biểu thị yếu tố được thực hiện tại pha đó. Phần sau đây sẽ làm rõ ý nghĩa của 10 yếu tố cơ bản.

1. Các tiêu chuẩn

Sản xuất PM ngày nay không còn đơn thuần mang tính sáng tạ ngẫu hứng như trước đây, mà đang trở thành một lĩnh vực được kiểm sát chặt chẽ, the những tiêu chuẩn nhất định. Các tiêu chuẩn có thể là các kinh nghiệm hặc các phương pháp hiệu quả nhất, được đề xuất từ các hiệp hội nghề nghiệp như IEEE (The Institute f Electrical and Electrnics Engineers, Inc – Học viện các kỹ sư điện và điện tử), từ các tổ chức quốc tế như IS (Internatinal rganizatin fr Standardizatin), hặc các quy tắc chuẩn hóa để gia tiếp giữa sản phẩm với nhau... hặc đơn giản d chính tổ chức phát triển PM đề ra để áp dụng ch chính họ.

Các tiêu chuẩn có thể ba gồm tất cả các khía cạnh của một chu kỳ phát triển PM, trải dài suốt mọi pha phát triển. Bất kể tiêu chuẩn xuất phát từ đâu, từ nội bộ công ty, hặc từ ngài, nó đều phải có một số đặc điểm sau:

• Tính cần thiết

• Tính khả thi

• Tính đ lường được

Các tiêu chuẩn nên được chọn và thể hiện sa ch khi sử dụng, các khía cạnh kỹ thuật cần thiết sẽ được nhấn mạnh, tránh trường hợp hiểu sai hặc sa và những tiểu tiết phụ trợ. Một ví dụ thường thấy là tiêu chuẩn định dạng ch tài liệu, mục đích của tiêu chuẩn là để bả đảm khía cạnh chất lượng về kỹ thuật của tài liệu. Tuy nhiên, trng rất nhiều trường hợp tiêu chuẩn đã bị hiểu sai và sa đà và việc kiểm tra các chi tiết về mặt hình thức. Lưu ý là để bả đảm các tiêu chuẩn được nghiêm túc thực hiện, chúng phải mang tính bắt buộc và được quy định ở chính sách cấp công ty.

Một dạng phổ biến bắt buộc phải có của tiêu chuẩn là hệ thống các "quy trình", kèm the các bộ phận phụ thuộc như "thủ tục" "hướng dẫn" "mẫu biểu" "tiêu chuẩn" v.v. Tùy the lĩnh vực hỗ trợ mà chúng có các tên tương ứng, chẳng hạn: quy trình sản xuất PM, quy trình kiểm sát chất lượng, quy trình kiểm tra...

2. Lập kế hạch

Page 21 of 33


Lập kế hạch là yêu cầu kinh điển cũng như tha tác cơ bản của hầu hết các HTQLCLPM. Kết quả của hạt động này thường là một (hặc nhiều) tài liệu gọi là bản kế hạch.

The quan điểm quản lý hiện đại, các công việc gắn liền với những mục tiêu, ngắn hạn hặc dài hạn, đều có thể xem như là một dự án hặc chuỗi các dự án. Kế hạch ch dự án thường ba gồm những điểm chính sau:

• Ước lượng phạm vi và kích thước dự án, khối lượng công việc phải làm

• Xác định nhân lực, vật lực và chi phí

• Chỉ định phương pháp, cách tiếp cận để thực thi dự án

• Lập kế hạch làm việc chi tiết

• Kế hạch phối hợp và hỗ trợ hàn thành dự án

Đây là kế hạch liên quan đến sự tham gia của những người có ảnh hưởng quan trọng đến sự thành công hay thất bại của dự án (thuật ngữ chuyên môn gọi là stakehlders). Những người nầy thường ba gồm: trưởng dự án, quản lý cấp ca, khách hàng, ban giám đốc, thầu phụ, nhà cung cấp. Kế hạch nầy phải bả đảm cơ chế để các stakehlders có thể tham gia và dự án ở các mức độ và thời điểm mang lại hiệu quả ca nhất.

• Kế hạch quản lý cấu hình và quản lý các rủi r (xem chi tiết phần sau)

• Các kế hạch khác

Tùy the nhu cầu ch từng dự án, có thể có nhiều kế hạch khác, cả về quản lý hặc kỹ thuật, một số kế hạch thường gặp chẳng hạn: Kế hạch kiểm tra, kế hạch tích hợp sản phẩm, kế hạch huấn luyện...

• Tài liệu hóa và cập nhật (khi cần) các bản kế hạch ch dự án

Lưu ý là các tài liệu kế hạch của dự án không phải bất di bất dịch, nó phải được cập nhật thậm chí thay đổi xuyên suốt dự án khi yêu cầu của dự án thay đổi. .Hình 2: Mối liên hệ giữa 10 yếu tố cơ bản và các pha phát triển

Hình 2: Mối liên hệ giữa 10 yếu tố cơ bản và các pha phát triển.

Các pha phát triển

Xác định nhu cầu

Định nghĩa giải pháp

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

Chứng minh giải pháp

Áp dụng giải pháp

Sử dụng giải pháp

Cải tiến giải pháp

Hạt động

Các tiêu chuẩn x x x x x x x

Xem xét, xem lại x x x x

Page 22 of 33


Kiểm tra, thử nghiệm x x x x

Phân tích lỗi x x x x x x x

Quản lý cấu hình

Chất lượng phần mềm đang là vấn đề bức xúc làm đau đầu cả giới sản xuất và ứng dụng ở Việt Nam. Đến nay, vẫn chưa có một tiêu chuẩn nà để đánh giá chất lượng phần mềm cũng như chưa có các tổ chức độc lập thực hiện công việc này.

Vấn đề này đã được đặt ra tại hội thả “Quản lý chất lượng phần mềm Việt Nam” d Hội Tin học TP HCM, Hiệp hội danh nghiệp phần mềm Việt Nam (VINASA) và Công ty Phát triển Công viên phần mềm Quang Trung phối hợp tổ chức ở TP HCM hôm 24/8.

Tính đến nay, cả nước mới có 11 danh nghiệp phần mềm đạt chứng nhận IS 9000, riêng Công ty cổ phần đầu tư phát triển công nghệ FPT vừa đạt IS vừa đạt chứng nhận CMM cấp 4.

Tại hội thả, ông Võ Việt Dũng, Trưởng đàn BVQI Việt Nam - một tổ chức cấp chứng nhận IS của Anh tại Việt Nam - nhấn mạnh rằng khi bắt tay và xây dựng và áp dụng hệ thống quản lý chất lượng, mọi người cần có ý thức và trách nhiệm ghi nhận đầy đủ các thông tin cần thiết trng quá trình quản lý. Lâu nay, nhiều danh nghiệp phần mềm chỉ quan tâm đến tiêu chuẩn kỹ thuật của sản phẩm mà xa lãng công tác the dõi, đ lường các quá trình quản lý.

Ông Dũng cũng nêu một số công việc mà danh nghiệp phần mềm cần thực hiện để tham gia quản lý chất lượng. Đó là cần cung cấp đầy đủ về đà tạ hệ thống quản lý và cập nhật kỹ năng quản lý hữu hiệu những kỹ thuật đ lường, thống kê, các tiêu chuẩn về chất lượng sản phẩm phần mềm như CMM, IS 9126, IS 14598 ch nhân viên quản lý và kỹ thuật; Thực hiện công tác kiểm sát các công việc có ảnh hưởng chất lượng thông qua hạt động the dõi và kiểm tra các hạt động và việc khắc phục, phòng ngừa trng danh nghiệp; Xác định các tài liệu cần thiết để thực hiện kiểm sát hạt động thiết kế, tạ sản phẩm và giảm thiểu lỗi trng quá trình gia công phần mềm và các hạt động khác; Tiến hành đánh giá nội bộ phù hợp với yêu cầu của IS hặc CMM the các mức độ, trng đó IS 9126 là bộ tiêu chuẩn đánh giá về chất lượng sản phẩm phần mềm, IS 14598 là bộ tiêu chuẩn đánh giá sản phẩm phần mềm, còn CMM được chia the 5 bậc, từ thấp đến ca.

Bá cá của đại diện VINASA nêu rằng một danh nghiệp phần mềm được nhận chứng chỉ IS hặc CMM ở mức độ khác nhau đồng nghĩa với danh nghiệp đó có một quy trình đảm bả chất lượng tốt hay độ “trưởng thành” của danh nghiệp đó ca, nhưng điều đó chưa đảm bả hàn tàn rằng các sản phẩm d danh nghiệp đó sản xuất ra có chất lượng thực sự. Vì chất lượng phần mềm là một...

Page 23 of 33


“đại lượng rất khó đếm”, phụ thuộc và bị ảnh hưởng bởi nhiều yếu tố và được đánh giá thông qua nhiều tiêu chí.

Giá sư Đà Văn Lượng, Giám đốc Sở KHCN&MT TP HCM, nêu một nét đặc trưng trng quan hệ “khách hàng - nhà sản xuất ” ở Việt Nam hiện nay là hầu hết nhà sản xuất phần mềm trng nước phải “tự đặt bài tán, rồi tự giải ch khách hàng”. Vì vậy, công việc và trách nhiệm của các danh nghiệp phần mềm Việt Nam hết sức khó khăn.

The Tiến sĩ Lê Trường Tùng, Chủ tịch Hội Tin học TP HCM, thì chất lượng quy trình = chất lượng sản phẩm + năng suất hạt động + thu hút đối tác, và vai trò của IS/CMM đối với các danh nghiệp phần mềm Việt Nam chính là chuẩn hóa, quốc tế hóa với chất lượng là then chốt.

Tuy không mới mẻ, nhưng vấn đề “làm” IS hay CMM vẫn còn như xa lạ với nhiều danh nghiệp phần mềm Việt Nam. Nên tư vấn làm IS ở đâu ch hiệu quả? TS Lê Thế Hùng, Công ty FPT, ch rằng hiện khó chỉ định cụ thể danh sách các công ty nà làm tư vấn giỏi, tuy nhiên nên chọn các công ty lớn và giá rẻ làm tư vấn. TS Lê Trường Tùng cũng bổ sung nên chọn một công ty nà đã từng tư vấn thành công ch một danh nghiệp và công ty đó cũng phải có... chứng nhận chất lượng về... tư vấn.

Ông Hàng Mạnh Cường, Trưởng phòng Quản lý chất lượng Công ty Tin học Bưu điện TP HCM, ch biết chi phí làm IS ch một công ty phần mềm Việt Nam, có 20 - 50 lập trình viên, tốn trên 100 triệu đồng. Còn the ông Hùng, chi phí để FPT lấy được chứng nhận CMM cấp 4 tới 50.000 USD cộng với 80 tháng công.

Việc “làm” IS/CMM rất cần, nhưng chi phí tốn kém như vậy không phải danh nghiệp phần mềm nà cũng đủ khả năng. Ông Nguyễn Trọng, Phó Giám đốc Sở KHCN&MT ch biết TP HCM đã có kế hạch xây dựng 300+3 danh nghiệp mới từ nay đến năm 2005, trng đó có 3 danh nghiệp có số lập trình viên trên 500 người. Thành phố đã có chương trình hỗ trợ “làm” IS/CMM, ba gồm một số hạt động tư vấn và cấp 20 triệu đồng ch mỗi danh nghiệp. Thế nhưng, đến nay chưa có một danh nghiệp nà tìm đến chương trình này.

Ông Hàng Minh Châu, Giám đốc Công ty FPT TP HCM, nêu kiến nghị thành phố cần tăng tiền trợ giúp ch một danh nghiệp phần mềm làm IS/CMM lên thành 30 triệu đồng, và có quy chế sa ch các danh nghiệp đạt tiêu chuẩn chất lượng IS/CMM được cộng điểm khi đấu thầu thực hiện các dự án CNTT hặc được chỉ định thực hiện các dự án ở mức độ nà đó.

Hiện nay, lỗi của phần mềm cực kỳ nguy hiểm, gây ra những thiệt hại không nhỏ về vật chất trng bối cảnh hầu hết những ngành kinh tế quan trọng đều đang sử dụng rộng rãi. Riêng tại Mỹ, các nhược điểm trng phần mềm đã gây tổn thất ch nền kinh tế Mỹ mỗi năm tới… 59,5 tỷ USD.

Page 24 of 33


Cũng như mọi hạt động sản xuất-kinh danh khác, việc sản xuất phần mềm đòi hỏi phải tuân thủ nghiêm ngặt các tiêu chuẩn về chất lượng, không chỉ chất lượng của từng sản phẩm riêng lẻ mà cả chất lượng của tàn hệ thống, tàn quy trình. Ấy thế nhưng ở nước ta, công tác quản lý chất lượng lại chưa được các danh nghiệp ci trọng.

Nhằm tạ điều kiện ch các danh nghiệp phần mềm trng nước tìm hiểu sâu hơn về hệ thống quản lý chất lượng, Hội Tin học TP.HCM (HCA) đã phối hợp với Câu lạc bộ Công nghệ thông tin - Viễn thông (ICT Partner-ship – thuộc Saign Times Club) tổ chức cuộc hội thả về “Hệ thống quản lý chất lượng trng các danh nghiệp phần mềm” và ngày 16-8 vừa qua.

Tại cuộc hội thả, ông Trần Lạc Hồng, Phó chủ tịch kiêm Tổng thư ký Hội Tin học TP.HCM, ch biết, hiện nay chỉ có 19 danh nghiệp phần mềm trng thành phố đạt các chứng chỉ quốc tế về quản lý chất lượng, 12 danh nghiệp khác đang xúc tiến công việc này ; khảng 70% danh nghiệp chưa quan tâm hặc quan tâm nhưng không đủ điều kiện để lấy được các chứng chỉ đó và có đến 60% danh nghiệp phần mềm chưa xây dựng được mô hình quản lý chất lượng.

Khách hàng cần chất lượng

Trng khi đó, các danh nghiệp làm gia công phần mềm ch các công ty, tập đàn nước ngài đang có ý định mở rộng hạt động sang các nước ở châu Âu và Hàn Quốc, bên cạnh các thị trường truyền thống là Mỹ và Nhật Bản. Tuy nhiên, sự mở rộng này diễn ra chậm chạp và chưa tương xứng với tiềm năng của các danh nghiệp sản xuất phần mềm Việt Nam.

The ông Hồng, để tăng sức cạnh tranh và thâm nhập và các thị trường mới, các danh nghiệp phần mềm trng nước cần phải nâng ca năng lực quản lý và chuyên môn, đặc biệt là áp dụng hệ thống quản lý chất lượng. Ông Hồng ch biết, có năm điều khó khăn mà các danh nghiệp trng nước hiện nay phải vượt qua là thiếu nguồn vốn, nhân sự không ổn định, thị trường không ổn định, thiếu thông tin và thiếu kỹ năng quản lý. Ba mối khó khăn cuối cùng cần phải có sự hỗ trợ của nhà nước thì mới mng khắc phục hàn tàn sng các danh nghiệp không thể ngồi chờ nhà nước mà nên tự thân vận động trng khả năng của mình. Các danh nghiệp hàn tàn có thể xây dựng thị trường ổn định, hàn thiện kỹ năng quản lý nếu xây dựng thành công hệ thống quản lý chất lượng the tiêu chuẩn quốc tế.

Chia sẻ kinh nghiệm về hệ thống quản lý chất lượng phần mềm, ông Nguyễn Ca Tùng, Giám đốc điều hành Công ty Tân Thiên Niên Kỷ, ch biết, chất lượng là yếu tố quan trọng nhất trng năm yếu tố mà khách hàng xem xét, lựa chọn để ký hợp đồng gia công, bên cạnh các yếu tố chi phí nhân công CNTT, cơ sở hạ tầng, trình độ chuyên môn và khả năng gia hàng đúng hạn. The ông Tùng, khách hàng đánh giá hệ thống quản lý chất lượng của một danh nghiệp phần mềm the ba yếu tố: sản phẩm, quy trình và các chứng chỉ quốc tế như IS 9001:2000, TL9000 và CMMI. Không thể sản xuất được phần mềm có chất lượng tốt trng một môi trường không tốt.

Mô hình và chứng chỉ quản lý chất lượng nà?

Thế nhưng, hệ thống quản lý chất lượng như thế nà là đúng và phù hợp với từng danh nghiệp cụ

Page 25 of 33


thể ? The ông Ngô Văn Tàn, quyền Phó tổng giám đốc Glbal CyberSft (GCS), quản lý chất lượng là một khái niệm dễ gây nhầm lẫn. Quản lý chất lượng trng danh nghiệp phần mềm không chỉ là bả đảm chất lượng của từng sản phẩm làm ra mà quản lý ngay những quy trình làm ra sản phẩm ấy. Tại GCS, mô hình quản lý chất lượng là một mô hình có tính liên thông từ trên xuống dưới, được cấp lãnh đạ khẳng định và hỗ trợ ngay từ đầu, được cán bộ nhân viên trng công ty tuân thủ nghiêm ngặt và đó chính là nền tảng của quy trình sản xuất phần mềm. Phương châm của GCS trng quản lý chất lượng là “Client first” (khách hàng là trên hết), nhưng client ở đây không chỉ là khách mua hàng mà còn là các đối tượng phục vụ khác, kể cả nhân viên ngay trng nội bộ công ty.

Tuy nhiên, the ông Tàn, trng hạt động quản lý chất lượng, người quản lý rất dễ bị sa đà và việc nói lý thuyết quá nhiều, sử dụng văn bản để khỏa lấp những sai sót. Trng khi đó, hệ thống quản lý phải tạ được chất lượng ngay từ đầu, có tính khả dụng ca và trở thành một phần thực sự có ích. Hiện tại, GCS đã đạt được chứng chỉ CMMI cấp độ 4 và IS 9001:2000.

Điều đáng lưu ý là không phải bất cứ danh nghiệp phần mềm nà cũng nên xây dựng ch mình một hệ thống quản lý chất lượng riêng dựa trên các chứng chỉ quốc tế. Ông Trần Bằng Việt, Trưởng ban chất lượng của Công ty phần mềm TMA, ch rằng các công ty có quy mô nhỏ, dưới 300 nhân viên, thì không nên áp dụng quy trình quản lý chất lượng the tiêu chuẩn CMMI, bởi vì mô hình này dễ gây cồng kềnh ch quy trình sản xuất. Riêng tại TMA, mỗi năm một lần công ty lập ra những tiêu chí về quản lý chất lượng, yêu cầu mọi nhân viên thực hiện và đây là phương thức có hiệu quả trng việc không ngừng nâng ca chất lượng hạt động của công ty. Ông Việt ch biết, TMA hiện có hơn 300 nhân viên, đã đạt chứng chỉ IS 9001:2000 và chứng chỉ CMMI cấp độ 3 và năm ngái, đang nhắm tới CMMI cấp độ 4 và quý 4 năm nay và tiến lên cấp độ 5 và cuối năm 2008.

Hiện nay tại TP.HCM chỉ mới có Công ty FCG Việt Nam (FCGV) đạt được cấp độ 5 – cấp độ ca nhất – của chứng chỉ CMMI. Ông Đỗ Văn Ngọc, Trưởng phòng cải tiến và phát triển quy trình của FCGV, ch biết, hệ thống quản lý chất lượng danh nghiệp phần mềm CMMI tại FCGV là một mô hình xây dựng trên kiến trúc mở the ba chức năng: chính sách, quản lý tài liệu và quản lý số liệu. Mô hình mở này duy trì nhận thức của mọi người trng công ty về quản lý chất lượng. Ở FCGV quản lý chất lượng là công việc hằng ngày chứ không phải the tính chất thời vụ của mỗi dự án.

Vai trò của người quản lý chất lượng

Ông Ngô Văn Tàn khẳng định, chuyên viên quản lý chất lượng và người quản lý dự án có vai trò quyết định trng việc xây dựng, triển khai và phát huy hiệu quả của các hệ thống quản lý chất lượng. Để hàn thành được nhiệm vụ, các chuyên viên này phải có sự hiểu biết sâu sắc về những khó khăn của dự án, có kiến thức chuyên môn sâu thì mới định nghĩa được chiến lược của quy trình. Trng thực tế không có một hướng dẫn cụ thể nà có thể phù hợp với mọi danh nghiệp.

Tại Công ty GCS các chuyên viên quản lý chất lượng thường xuyên được đà tạ, huấn luyện để mở rộng tầm hiểu biết. Ông Đỗ Văn Ngọc của FCGV cũng có nhận xét tương tự. The ông Ngọc,

Page 26 of 33


xác định các quy trình không khó, cái khó là phải biết cách duy trì và the sát chúng ; chính vì vậy công ty cần có những hạt động để giúp các chuyên viên quản lý chất lượng thường xuyên nâng ca trình độ.

Công ty cổ phần phát triển công nghệ FPT giới thiệu một ứng dụng giúp bộ phận quản lý chất lượng kiểm tra đồng thời nâng ca được hiệu suất làm việc của nhân viên. Nhánh phần mềm FSFT của FPT có đến gần 1.800 nhân viên, vì vậy việc khai thác chưa đúng mức hay quá mức sức la động của nhân viên là điều khó tránh khỏi. Bà Trương Tiểu Linh, Trưởng ban quản lý chất lượng của FSFT, ch biết, điều phối công việc hợp lý giữa các nhân viên trng công ty là yếu tố có vai trò không nhỏ trng việc nâng ca vị thế của bộ phận quản lý chất lượng trng tàn bộ hệ thống sản xuất phần mềm.

Bả đảm chất lượng ch nhiều dự án

D có nhiều khách hàng với những nhu cầu và hạt động khác nhau nên quy trình của các dự án phần mềm cũng khác nhau tuy rằng danh nghiệp phải luôn luôn bả đảm chất lượng của tất cả các dự án. Ông Huỳnh Quốc Dương, Giám đốc quản trị chất lượng của Công ty phần mềm Pyramid Sftware Develpment (PSD), tiết lộ sáu bước công việc mà PSD áp dụng để bả đảm chất lượng quy trình sản xuất ch nhiều khách hàng khác nhau. Bước một là định vị được sản phẩm hay dịch vụ mà khách hàng yêu cầu, bước hai là vạch ra những yêu cầu mà khách hàng ch là quan trọng, tiếp the là những yêu cầu khách hàng muốn có trng sản phẩm hay dịch vụ đó. Ở bước bốn, công ty sản xuất phần mềm phải định nghĩa được quy trình thực hiện dự án ; sau đó chỉnh sửa lại tàn bộ quy trình sa ch không còn xảy ra lỗi hay lại bỏ những công việc không cần thiết. Bước thứ sáu là luôn cải tiến quy trình triển khai dự án.

Tại cuộc hội thả, những ý kiến đa dạng và phng phú được thả luận hết sức sôi nổi. Tuy chưa có sự đồng thuận về việc chọn mô hình quản lý chất lượng nà ch danh nghiệp phần mềm trng nước, đại diện các danh nghiệp tham dự hội thả đều ci đây là một cơ hội để các chuyên viên quản lý chất lượng từ nhiều công ty sản xuất phần mềm trng thành phố gặp nhau và tra đổi ch nhau những kinh nghiệm có giá trị.

Ch tới nay, hai vấn đề lớn đặt ra ch những người hạt động trng lĩnh vực Công nghệ phần mềm (CNPM) vẫn là:

* Làm sa có thể rút ngắn được thời gian phát triển sản phẩm mà vẫn thỏa mãn được yêu cầu của khách hàng ?

* Làm sa có thể đáp ứng được sự thay đổi liên tục về yêu cầu phần mềm ?

Giải pháp ch hai vấn đề này có thể xem xét từ hai khía cạnh sau: Công cụ và phương pháp luận. Về mặt công cụ, với sự ra đời của các ngôn ngữ lập trình hướng đối tượng mạnh như Java, C++ và các ngôn ngữ mô hình hóa như UML đã đáp ứng được phần nà nhu cầu của những người phát

Page 27 of 33


triển phần mềm. Về mặt phương pháp luận, các tiêu chuẩn chất lượng như IS9001 hay CMM đã giúp ch các danh nghiệp phát triển phần mềm, định hướng được việc xây dựng quy trình phát triển phần mềm. Đặc biệt, phương pháp luận RUP (Ratinal Unified Prcess) có thể ci là một ví dụ điển hình và cụ thể về quy trình phát triển phần mềm.

Các phương pháp luận này, tuy đã giúp ch các danh nghiệp phần mềm có được những quy trình phát triển phần mềm có tính dự bá ca và ổn định, nhưng vẫn chưa đáp ứng được hai vấn đề đặt ra ở trên. Từ đầu năm 2000, một cuộc cách mạng mới về phương pháp luận phát triển phần mềm đã bắt đầu với sự ra đời của các phương pháp luận hạng nhẹ (lightweight methds) như eXtreme Prgramming (XP), Crystal, Adaptive Sftware Develpment, ... Các phương pháp này được gọi là hạng nhẹ để tương phản với các phương pháp hạng nặng (heavyweight methds) thiết lập dựa trên các tiêu chuẩn IS9001, CMM hay RUP. Trng số các phương pháp hạng nhẹ, XP đã nhận được sự quan tâm nhiều nhất vì nó đã đề ra hai mục tiêu rất rõ ràng và cần thiết ch CNPM:

* Phát triển sản phẩm một cách nhanh chóng: Với sự phát triển hiện nay của nền kinh tế dựa trên Công nghệ thông tin, danh nghiệp nà đưa sản phẩm ra thị trường nhanh nhất sẽ chiếm được thị phần có lợi nhất. Phương pháp XP sẽ giúp ch các nhà phát triển phần mềm rút ngắn thời gian phát triển sản phẩm.

* Phát triển sản phẩm đúng the yêu cầu của khách hàng: thực tế ch thấy rằng nhiều sản phẩm phần mềm tuy được phát triển một cách công phu nhưng lại không đáp ứng được nhu cầu của người sử dụng. Phương pháp XP đã đưa ra các cơ chế ch phép sản phẩm phát triển luôn phù hợp với yêu cầu của người sử dụng.

Trng phạm vi bài bá này, chúng tôi sẽ giới thiệu một cách tổng quan về phương pháp phát triển phần mềm eXtreme Prgramming.

Các nguyên tắc cơ bản của XP

XP được thiết lập dựa trên bốn nguyên tắc sau:

Tra đổi (Cmmunicatin): XP chú trọng việc tra đổi thông tin một cách 'trng suốt' giữa các thành viên trng nhóm phát triển. Đề ca việc tra đổi trực tiếp, giảm việc tra đổi gián tiếp hay hinh thức thông qua các văn bản.

* Với XP, khách hàng tham gia trực tiếp và việc thực hiện dự án với tư cách là một thành viên chính thức của nhóm phát triển. Khách hàng sẽ giúp nhóm phát triển hiểu và nắm bắt được và kịp thời các yêu cầu của người sử dụng (cũng như sự thay đổi về yêu cầu) trng suốt quá trình thực hiện dự án.

Page 28 of 33


* Tất cả các thành viên đều tham gia và mọi hạt động trng quá trình phát triển phần mềm. Điều này sẽ nâng ca tính năng động của tàn bộ nhóm phát triển.

Phản hồi (Feedback): phản hồi sớm và liên tục từ khách hàng cũng như từ nhóm phát triển giúp ch dự án luôn đi the đúng hướng. XP đều đặn gia sản phẩm ch khách hàng để kiểm tra, the đó khách hàng có thể 'làm mịn' và hàn thiện yêu cầu sản phẩm dựa trên các kết quả cụ thể. Với sự trợ giúp của khách hàng, XP xây dựng một tập các phép thử phụ vụ ch việc kiểm định (acceptatin test) một cách liên tục trng suốt quá trình phát triển phần mềm.

Đơn giản (Simplicity): XP đảm bả chỉ phát triển những chức năng mà khách hàng yêu cầu. Phần thiết kế và mã nguồn được thiết lập một cách đơn giản nhất, ch phép có được đặc tính 'mở' ca nhằm đáp ứng với các thay đổi liên tục và luôn duy trì được một tốc độ phát triển nhanh trng suốt quá trình phát triển phần mềm.

Dũng cảm (Curage): XP ch rằng phải có lòng dũng cảm thì mỗi thành viên mới thực hiện được các nguyên tắc kể trên. Tuy XP không chỉ ra một cách rõ ràng, nhưng cũng cần phải nhấn mạnh rằng tính kỷ luật là yêu cầu quan trọng để thực hiện có hiệu quả phương pháp phát triển phần mềm XP.

12 Quy cách làm việc của XP

Phương pháp XP đã đề ra 12 quy cách (practices) làm việc để thực hiện các nguyên tắc phát triển phần mềm đã nêu ở trên. The các chuyên gia trng CNPM, các quy cách làm việc đề ra bởi XP không có gì là mới. Thực chất, những quy cách này là những kinh nghiệm hay nhất thu được trng quá trình phát triển CNPM, đặc biệt là CNPM với công nghệ hướng đối tượng.

Lập kế hạch (Planning prcess)

Với XP, khách hàng tham gia trực tiếp và quá trình lập kế hạch phát triển phần mềm. Vai trò của khách hàng và nhóm phát triển được định ra một cách rõ ràng.

Trách nhiệm của khách hàng:

* Mô tả tính năng phần mềm cần phát triển thông qua các ' câu chuyện' (user stry). User stry có ý nghĩa tương tự như use case trng UML nhưng mức độ mô tả thì không chi tiết bằng.

* Phân lại các user stry the mức độ quan trọng từ quan điểm người sử dụng (dựa trên giá trị kinh danh-business value). Từ đó sẽ định ra tính năng nà cần phải phát triển và phát triển the thứ tự

Page 29 of 33


như thế nà.

* Định ra thời điểm và chu kỳ bàn gia sản phẩm

Trách nhiệm của nhóm phát triển:

* Ước lượng yêu cầu kỹ thuật (để phát triển) ch từng user stry (ước lượng độ phức tạp).

* Ước lượng thời gian, nhân công cũng như giá thành để phát triển từng user stry.

Với sự phân công trách nhiệm như vậy, bản kế hạch sẽ luôn thỏa mãn được yêu cầu của khách hàng cũng như nhóm phát triển.

Bàn gia từng phần (Small releases)

The quy cách này, nhóm phát triển sẽ phát triển dần dần phần mềm, từ đơn giản đến phức tạp. Từng phần sẽ được chuyển gia ch khách hàng để có được ngay sự phản hồi của khách hàng. Từ đó sẽ có thể điều chỉnh ngay được sản phẩm ch phù hợp với yêu cầu của khách hàng. Khách hàng cũng có điều kiện để bổ sung hay thay đổi yêu cầu phần mềm.

Tham gia trực tiếp của khách hàng (n-site custmer)

Với XP, khách hàng sẽ tham gia cách trực tiếp trng suốt quá trình phát triển phần mềm. Sự tham gia này sẽ giúp ch nhóm phát triển có điều kiện tham khả trực tiếp ý kiến của khách hàng, tra đổi về hệ thống cần được phát triển, tránh được nhầm lẫn trng cách hiểu về hệ thống cần phát triển. Mục tiêu cuối cùng là sản phẩm làm ra phù hợp với yêu cầu của khách hàng.

Lập trình đôi (Pair prgramming)

Tất cả các phần chương trình d một hay nhiều nhóm hai người viết. Hai người này sẽ sử dụng chung một máy tính, cùng đồng thời viết chương trình. Quy cách này sẽ giúp ch có được giải pháp lập trình tốt hơn, chương trình sẽ có chất lượng và hiệu quả hơn.

Thiết kế đơn giản (Simple design)

XP khuyến khích tìm kiếm giải pháp đơn giản khi thiết kế phần mềm. Chỉ thiết kế phần mềm thả mãn yêu cầu hiện tại của khách hàng, không nên tìm kiếm một giải pháp ch một hệ thống tương lai. The đó, chỉ cần một thiết kế làm sa ch chương trình chạy được và thỏa mãn yêu cầu của khách hàng.

Page 30 of 33


Tổ chức lại chương trình (Refactring)

Quan điểm của XP là chất lượng phần mềm được thể hiện bằng chất lượng của mã nguồn (cde). Một chương trình được viết rõ ràng, đơn giản thì sẽ dễ bả dưỡng và thay đổi. XP khuyến khích tổ chức (viết ) lại chương trình một cách đều đặn để nâng ca tính sáng sủa của chương trình, dễ bổ sung các chức năng mới, nâng ca hiệu suất của chương trình.

Kiểm thử (Testing)

XP yêu cầu rất ca trng khâu kiểm thử và kiểm định chương trình. Với mỗi phần của chương trình, lập trình viên phải viết chương trình kiểm thử ch phần đó trước khi thực sự bắt đầu khi viết chương trình (ch phần đó). Khách hàng sẽ chịu trách nhiệm thực hiện kiểm định sản phẩm.

Tích hợp liên tục (Cntinuus integratin)

Việc tích hợp sẽ được tiến hành một cách liên tục. Khi một đạn chương trình mới được phát triển, đã vượt qua phần kiểm thử, thì sẽ được tích hợp ngay và hệ thống. Điều này sẽ giúp ch việc phát hiện và sửa lỗi thích hợp nhanh hơn và rẻ hơn. Trng một ngày có thể thực hiện nhiều lần tích hợp hệ thống.

Sở hữu tập thể (Cllective wnership)

Tất cả mã nguồn đều thuộc quyền sở hữu của mọi thành viên trng nhóm phát triển. The đó, mã nguồn có thể được sửa đổi ngay khi cần. Với cách quản lý thông thường, mỗi phần mã nguồn thường d một người quản lý, nên khi cần sửa đổi thì phải cần sự thông qua chủ sở hữu, đôi khi điều này gây mất nhiều thời gian.

Chuẩn lập trình (Cding standards)

Để chương trình (mã nguồn) có thể hiểu được một cách dễ dàng, nhất là đối với các quy cách lập trình đôi và sở hữu tập thể, nhóm phát triển phải thống nhất cách viết chương trình. Cần phải có một quy định cụ thể, rõ ràng về cách viết (ví dụ, cách đặt tên biến, cách bổ sung chú thích, ..v.v.) để làm sa tất cả đều hiểu được.

Metaphr (Metaphr)

Nhóm phát triển XP dùng chung một hệ thống các thuật ngữ để biểu diễn hệ thống cần phát triển. Các thuật ngữ này sẽ được dùng trng khi tra đổi giữa các thành viên trng nhóm cũng như khi tra

Page 31 of 33


đổi với khách hàng.

Không làm việc quá giờ (40 -hur week)

Hiện tượng làm việc quá giờ rất phổ biến trng giới phát triển phần mềm. Thực tế ch thấy khi người la động làm việc quá giờ thường hay mệt mỏi, dẫn đến làm việc không hiệu quả, chất lượng sản phẩm giảm. XP khuyến cá không nên làm việc quá giờ, chỉ làm đúng giờ quy định để đảm bả chất lượng sản phẩm.

Điều kiện để áp dụng XP

Nhóm phát triển nhỏ hơn 10 người. XP có thể áp dụng một cách có hiệu quả trng các nhóm phát triển có số lượng nhỏ hơn 10 người ( quá 10 người thì việc tra đổi giữa các thành viên sẽ rất khó thực hiện được một cách hữu hiệu). XP đặc biệt có hiệu quả trng việc phát triển các phần mềm có yêu cầu luôn thay đổi, khách hàng không định trước được một cách rõ ràng yêu cầu phần mềm.

Đối với các dự án lớn, người ta có thể phân chia công việc ch từng nhóm nhỏ XP. Tuy nhiên, ch đến nay các tác giả của XP chưa đưa ra phương án nà để quản lý, phối hợp hạt động của các nhóm này. The tôi, trng trường hợp này, có thể dựa và IS9001 hay CMM để kết lập một quy trình quản lý hạt động của các nhóm nhỏ XP.

Làm việc the nhóm

XP đòi hỏi phải có tính năng làm việc tập thể rất ca. Mọi thành viên phải có thái độ hợp tác trng quá trình làm việc bởi vì mọi hạt động của XP đều mang tính tập thể.

Tính kỷ luật

Mọi thành viên phải tự giác chấp hành các quy định của nhóm phát triển. Ví dụ, tất cả đều phải viết chương trình the một quy định đã thống nhất. Có như vậy thì chương trình (mã nguồn) mới có thể trng suốt và dễ hiểu với tất cả nhóm, dẫn đến dễ sửa đổi và thêm chức năng mới và chương trình.

Trình độ thành viên

Với XP, mọi thành viên sẽ tham gia và mọi hạt động trng quá trình phát triển phần mềm. D vậy, các thành viên cần phải được trang bị kiến thức tốt về nhiều mặt và cần có nhiều kinh nghiệm trng nhiều lĩnh vực khác nhau.

Page 32 of 33


Vai trò của khách hàng

Sự tham gia trực tiếp của khách hàng trng suốt quá trình thực hiện dự án phần mềm là một yếu tố không thể thiếu ch sự thành bại của dự án. Khách hàng tham gia với tư cách là một thành viên biên chế của nhóm phát triển sẽ giúp ch nhóm luôn phát triển sản phẩm the đúng yêu cầu của khách hàng cũng như thỏa mãn được các yêu cầu khách của khách hàng (ví dụ như thời điểm bàn gia sản phẩm, giá thành sản phẩm, ..v.v.)

Ch đến nay phần lớn các nhà phát triển phần mềm làm việc the cách 'lập trình-sửa lỗi' (cde-and-fixe), hay nói một cách khác là phát triển phần mềm không the một quy trình nà cả. Một số danh nghiệp chú trọng tới một tương lai lâu dài đã áp dụng các tiêu chuẩn chất lượng như IS9001 hay CMM để xây dựng các quy trình phát triển phần mềm phù hợp với đặc điểm riêng của mình. Các quy trình này thường có tính ổn định và dự bá ca. The đó, mọi hạt động liên quan tới phát triển phần mềm đều được kế hạch hóa và định trước. Tuy nhiên các quy trình này cũng hay bị chỉ trích là quá chú trọng tới quản lý, nặng nề về các quy định và sạn thả tài lịêu khiến ch tốc độ phát triển phần mềm chậm, đặc biệt là không đáp ứng được các thay đổi nhanh về yêu cầu phần mềm.

Extreme Prgramming cũng như các phương pháp hạng nhẹ (lightweight methds) khác như Crystal, Adaptive Sftware Develpment đưa ra các giải pháp mới ch việc thiết lập các quy trình phát triển phần mềm. Khác với các phương pháp hạng nặng (heavyweight methds) xây dựng dựa trên các tiêu chuẩn IS9001, CMM hay RUP, các phương pháp hạng nhẹ đơn giản, dễ áp dụng và không cần có sự đầu tư lớn về kinh phí cũng như thời gian. Đặc biệt, các phương pháp này thường có tính mềm dẻ và thích ứng ca, rất thích hợp với các danh nghiệp phát triển phần mềm trng các môi trường không ổn định và yêu cầu phần mềm thay đổi liên tục.

Như đã trình bày ở trên, các quy cách làm việc của XP tương đối đơn giản và rất gần với các hạt động hàng ngày của các nhóm phát triển phần mềm. Việc áp dụng một số quy cách của XP sẽ không đạt yêu cầu cần phải có một cuộc 'cách mạng' về quy trình sản xuất trng danh nghiệp. Áp dụng tàn bộ hay một số các quy cách của XP là một câu hỏi đặt ra ch từng nhóm phát triển.

Mặc dù mới ra đời khảng 5 năm gần đây, XP đã được nhắc tới như một phương pháp phát triển phần mềm mới, đầy triển vọng, nhất là ch các ứng dụng trng thời đại Internet. XP thành công vì mục đích hàng đầu của nó là nhằm thả mãn yêu cầu của khách hàng. XP được thiết kế để phát triển phần mềm nhanh, đúng the yêu cầu của khách hàng và bàn gia đúng thời điểm khách hàng muốn. Bạn đọc quan tâm tới XP có thể thả luận với tác giả the địa chỉ email sau: [email protected]

Page 33 of 33

Documents

ThựC HiệN ChiếN LượC ChấT LượNg PhầN MềM Theo ChuẩN Iso