Đảm bảo chất lượng phần mềm bài giảng cho sinh viên ngành công nghệ thông tin phạm thị hoài thương

Nói cách khác, khối lượng công việcđược thực hiệntrong suốt thờikỳ dự án đòi hòi sự tham gia của nhiều ngườinềnmuốndự án hoàn thành đúng thời hạn.- Để thực hiệnđược dự án cần có nhiều ch

ĐẢM BẢO CHẤT LƯỢNG PHẦN MÈM

Phan Thị Hoài Phương

Hà NỘI-2010

Giói thiệu

Trước Iihừng thách thức trong quá trình phát triển phần mềm, việc đàm bão chất lượng phần mềm (SoftwareQualityAssurance-SQA) là hết sức quan trọng, đòi hòiphàinghiên cím một cách nghiêm túc để thực thi hiệu quà Tài liệu này cmig cấp nhừng kiếnthức cơ bản về chất lượng phần mềm, đàm bão chất lượng trong một dự án phát triểnphần mềm Qui trinhxây dựnghệ thống đàm bào chất lượngphần mềm cùng đirợc trinhbày trong nội dưng bài giăng Qua đó, sinh viên hiểu được cách thức xây dựng một hệthống đâm bão chất hrợng phần mềm và vai trò của nhùng thành viên trong hệ thống Một số chuẩn đàmbàochất lượng cũng đượcgiới thiệu trong nhùngchtrơng cuối Thông qua nội dimg bài giăng sinh viên cũng sẽ nắm được kỳ năng rà soát và kiểm thử phần mềm

Tài liệu được soạn phần lớn dựa trên cuốn sách Software Quality! Assurance From Theory to Implementation của Daniel Galin và một A tài liệu về kỳ nghệ phần mềm,nhằmhỗ trợ cho sinh viên gặp khó khăn khi đọc cá *ài liệu nguyên gốc tiếngAnh

Nội dung bài giảng đượcxây dựngtrong bây chươiK

Chuông 1 Khái niệm về chất lượng pT>n n> 'I và các V U to chất lượng phần mềm

Nhùng khái niệm mở đầu của ‘ ă. ';èu được gi thiệu trong chương 1 Bất đầu vớikhái niệm phần mềm, chấtlượngf hần m ụ và đàmbão chất lượng phần mềm, phần tiếp theo phân tíchcác yếu tố chất niọ •’ phần rm

Chuông 2 Các thành phân ha * lượng phẩn mềm tiền dự án

Chương này trình bày những X ; dung hên quan đến nhữngthànhphần đâm bào chất lượng phần mềm tiều dự án bao gôm việc rà soát họp đồng, kế hoạch phát triển dự ánphần mềmvà kể hoạch chất lượng phần mềm

Chuông 3 Các thành phần SQA trong vòng đòi dự án

Chương 3 đề cập đến các thành phần đàm bào chất lượng phần mềmtrong vòng đời

dự án phần mềm Nhừng nội dung được trình bày hong chương này bao gồm : phân tích một số mô hình phát triển phần mềm phồ biển, các phương pháp rà soát, bào trì phần mềm và các công cụ CASE Riêngkiểmthửphầnmềm là bước quan trọng sè được trinhbày riêng ởchương 4

Chưong 4 Kiêm thử phần mềm

Chương 4 đề cập đến kiểm thừ phần mềm Nhùng nội dung được trinh bày trongchương này bao gồm : khái niệm cơ bàn, các mức kiểm thừ, các kỳ thuật kiểm thừ, vàquá trình kiểm thừ

Chương 5 Phân loại các phần mềm phục vụ kiêm

Chương 5 đề cập đến các loại thành phần được dùng trong kiểm thử phần mềm Nhùng nội dnng đrrợc trình bày trong chương này bao gồm : các phần mềmphục vụ kiểm thử và thư viện JUnitđượcsử dụng rộng rãi trong kiềm thử đơn vịcho ngôn ngừlập trinh Java

Chương 6 Các thành phần cơ bản của chất lượng phần mềm

Các thành phầncơ bân của chất lượng phần mềmbao gồm các thủtục (procedure), chidần (instruction), khuôn mầu (templates), checklists (danhmục kiểm tra) Đóchinh là nộidung được trình bày trong phần đầu của chương 6 Phần tiếp theo sè trình bày các hoạtđộng đàm bào chất lượng phần mềm khác như : đào tạo và cấpchímg chi, ngănngừa vàsữalỗi, quàn lý cấu hìnhvà kiểm soát tàiliệu

Chương 7 Các thành phần quản lý chất lượng phần mềm

Ngoài yếu tổ kỳ thuật, trong các dự án phát trier phân mềm hiện đại, yểu tổ quản lýđóng vai trò hết sức quan trọng Chương 7 trÌỊ?’ấ b các vấn đề liên quan đến quản lý chất lượng phầrr mềm ulnr: điều khiển tiếuđô dự án, đọ O chất lượng phần mềm, chiphíchất lượng phần mềm

Chương 8 Các chuân, chứng chỉ v' hoạt động I 'ib giá

Chương này đề cập tới các chum qua ’v chất lượng như ISO 9001 và ISO 9000-3,CMM và CMMI và các chir.1t tiẽi rình dựỀ như IEEE/EIA Std 12207, IEEE Std 1012, IEEE Std 1028

Chương 9 Tô chức đê đảm ba 'hất lượng

Trongnhùngtổ chức lớn, quàn lý nguồn nhân lực là một yếu tố quyết đinh sự thành công Chương 9 đề cập đến các tácnhân tham gia vào hệ thốngđàmbào chất lượng phần mềm, vai trò,trách nhiệm của mồi tác nhàn được phân tích cụ thềtrong từng đề mục của chương

Phụ lục

Truth bày vềcác lỗi thường gặpkhiviết chương trinh

MỤC LỤC

Giới thiệu 2

Chương 1 Kháiniệm về chấtlượng phần mềmvà các yếutổ chất lượng phần mềm 8

1.1 Đặc điềmcùa phần mềm vàmôi trường phát triển phần mềm 8

1.2 Khái niệm phần mềm 11

1.3 Lỗi phần mềm và phàn loại nguyên nhân gây ra lỗi phần mềm 12

1.3.1 Lỗiphầnmềm 12

1.3.2 Nguyên nhân gây ra lỗi phần mềm 12

1.4 Định nghĩa chất lượng phần mềmvà đãmbào chấthrợug phần mềm 15

1.5 Nhừng mục tiêuđảmbảo chất lượng phần mềm 15

1.6 Phàn loại yêu cầu phần mềm ứng VỚI các yếu tố chấtlượng phần mềm 16

Chương 2 Các thành phần chất lượng phần mềmtiềndự án 20

2.1 Rà soáthợp đồng 20

2.1.1 Tiên trìnhrà soáthợpđôngvà các birớc thực hiện 20

2.1.2 Các mục tiêu rà soáthợp đồng 21

2.1.3 Thực thi rà soáthợp đồng 24

2.1.4 Nlùmg kliókhãn của thực hiệnxem lại hơnđồngcho cácđề xuất chính 25

2.1.5 Khuyểncáo cho việc thực hiện duyệt Ịsl nhưng hợpđồng chinh 26

2.1.6 Cácđổi tượng rà soáthợp đồng 27

2.1.7 Rà soáthợpđồngcho các dự án nụ bộ 27

2.2 Các kế hoạch phát triền và kế hoạc’ 'hất lượng 30

2.2.1 Những mục tiêu của kế hoa- h phe ‘rìểnvà kếiioạcli chất hrợug 31

2.2.2 Các thành phần của kế lv ạch phátti ' 31

2.2.3 Các thành phần của lơ 11L 'h chất lượn 35

2.2.4 Các kế hoạch phát trờn và K ^oạch chất lượng cho các dự án nhỏvà các dự án nội bộ 38

Chương 3 Các thành pb1 SQA ong vòng đờidự án 41

3.1 Tích hợp các hoạt đt r nất lượng trong vòng đờidựán 41

3.1.1 Phiĩơngphápphát ■ An phần mềmtruyền thống và các phươngpháp khác41 3.1.2 Các yếutổ ânh hưởng oạt động đàm bão chất hrợng phần mềm 51

3.1.3 Xác minh, thẩmđịnh và đánh giá chất lượng 52

3.2 Rà soát 53

3.2.1 Mục tiêu rà soát 53

3.2.2 Nlùmg rà soát thiết kể hìnhthiĩc 54

3.2.3 Các rà soát ngang hàng (peer review) 56

3.2.4 Các ý kiếncủa chuyên gia 57

3.3 Đàm bão chất lượng cùa cácthành phần bão trì phần mềm 59

3.3.1 Giới thiệu 59

3.3.2 Cơ sởcho chấthrợngbảo trìcao 61

3.3.3 Các thành phần chấthrợng phần mềmtiền bào trì 64

3.3.4 Các côngcụ đàmbão chất krợug bào trì phần mềm 68

3.4 Các CASE tool và ảnh hường của nó lêuchàt hrợng phần mèm 77

3.4.1 Kháiniệm CASE tool 77

3.4.2 Đónggóp cùa CASE tool chochấthrợng sản phẩm phần mềm 79

3.4.3 Đónggóp của CASE tool chochấthrợng bâo trì phầnmềm 81

3.4.4 Đónggóp của CASE tool choquàn lýdự án 82

3.5 Đàmbào chất lượngphầnmềmcủa các yến tổ bên ngoài cìmgtham gia 82

3.5.1 Nlrirng thàiili phan bên ngoài đóng góp vào dự án phần mềm 82

3.5.2 Rủi ro và lợi íchcủa giới thiệu người tham dự ngoài 83

3.5.3 Nhưng mục tiêu đảmbão chấtlượng về sự đóng gópngười thamgia bên ngoài 84 3.5.4 Các công cụ đàmbão chàtlượng nhùng đónggóp của các thànhviên đóng góp bên ngoài 85

Chương 4 Kiểmthử phần mềm 86

4.1 Một sốkhái niệm cơ bàn 86

4.1.1 Ví dụ về lỗi phần mềm 86

4.1.2 Đặc tà và lỗi phần mềm: 87

4.1.3 Kiềmthừ và tiếntrinh kiểm thừ 88

4.1.4 Các mức kiểm thử 90

4.1.5 Một sổ thuật ngừ 91

4.2 Các cấp độ kiểm thử 94

4.2.1 Kiềmthừ đơn vị - Unit Testing 95

4.2.2 Kiềmthừtíchhợp - Integration Testing 95

4.2.3 Kiểmthừ hệ thông - System Testing 100

4.2.4 Kiểm thừchấp nhận - Acceptance T,Si ự» 101

4.3 Các kỳ thuậtkiểmthử 102

4.3.1 Kiềmthừhộpđen - Black-box ’Sting 102

4.3.2 Kiểmthừhộp trắng - White box ’ting (WB X) 108

4.3.3 Kiểmthừgiatăng - Inci'f mental Tes g 1 lố 4.3.4 Thread Testing 116

4.3.5 Bàng tómtắtTesting Levels Techniques 116

4.4 Quá trìnhkiểm thừ 116

4.4.1 Xác địnhtiêr huẩn c ất lượng phầnmềm phù hợp 116

4.4.2 Lập kế hoạchCL fe'xí 119

4.4.3 Thiết kếkiểmthừ ">t design) 121

4.4.4 Tiến trìnhtest 124

4.4.5 Thiết kếtrường họp kiểmthừ(Test Case Design) 125

Chương 5 Phân loại các phần mềmphục vụkiểmthừ 127

5.1 Phầnmềmphục vụ kiểmthừ 127

5.1.1 Phầnmềm hỗ trợviếttài liệu 127

5.1.2 Phầnmềmquàn lý lỗi 127

5.1.3 Công cụ kiềmthửựrđộng 129

5.2 Unittest và thưviện JUnit 133

5.2.1 Tống quan về Unit Testing 133

5.2.2 Tổng quanthư viện Juuit 135

Chương 6 Các thành phần cơ bân của chất lượng phần mềm 139

6.1 Thủ tục, chi dầu vàcácthiết bị hỗtrợ chấthrợug 139

6.1.1 Cácthủ tục và clù dần 139

6.1.2 Chuẩn bị, thực thivà cập nhậtcác thủtục vàchi dần 142

6.1.3 Khuôn mầu(templates) 143

6.1.4 Danh mục kiềmtra (Checklists) 146

6.2 Đàotạođộingũvà cấp chứng chi 148

6.2.1 Mục tiêu của đào tạovà cấp clnhigchi 149

6.2.2 Tièn trình đàotạovà câp chímg clii 149

6.2.3 Xác định yêu cầukiếnthứcchuyên mônvà sự cần thiết củađàotạo và cập nhật 150 6.2.4 Xác địnhnhững nhu cầu đào tạovà cập nhật (updating) 150

6.2.5 Lên kế hoạch đàotạovà clnrơng trình cập nhật 151

6.2.6 Định nghíacác vị trí yêu cầucấp cluing chi 151

6.2.7 Lên kế hoạch các tiếntrình cấp chứngchi 152

6.2.8 Phânphổi các chương trình đào tạovà cấpchímg chi 153

6.2.9 Nlnrng công việctiếp theo cùa việc đào tạovàcap chimg chi 153

6.3 Các hành động sửa lỗivà phòng ngừa 154

6.3.1 Định nghía hoạt động sửa lồivà phòng ngừa 154

6.3.2 Tiến trình hành động sửa lỗi và phòngngừa 154

6.3.3 Thu thập, phân tích thông tiu 155

6.3.4 Phát triển cácgiài pháp và thực thi 155

6.3.5 Tổ chức các hành động phòng ngừa và sửa lỗi 156

6.4 Quàn lýcấuhình 157

6.4.1 Các thành phần cấuhình phần mềm 157

6.4.2 Quàn lý cấu hình phần mềm 157

6.4.3 Kiểmsoát sựthayđổiphầnmềm 157

6.4.4 Kiềmsoát quàn lý cấu hìnhpb' mêm 158

6.4.5 Các công cụ máy tính quản ’4- câu ;uli phân mem 159

6.5 Kiểm soáttài liệu 159

6.5.1 Các tài liệu kiểm soát/à nghi chất L Jiig 159

6.5.2 Danh sách các tàiliệu được I U11 soát 160

6.5.3 Chuẩn bị, phê chueu ’ưutrừVu 'm hồitài liệu kiểm soát 160

Chương 7 Các thành pb'Ằ quàn Ịchấtlượngphần mềm 163

7.1 Điềukhiểntiến độ G m 163

7.1.1 Các thành phần đìu khiển tiếnđộ dựán 163

7.1.2 Điêu khiên tiên độ cu -ác dự án nộibộvà cácthành phàn bên ngoài 163

7.1.3 Thực till kiểm soát tiến độ dự án 163

7.1.4 Các công cụ kiềmsoáttiến độ phần mềm 164

7.2 Độ đo chất hrợng phần mềm 165

7.2.1 Các mục tiêu đo lường phần mềm và phân loại các độ đo 166

7.2.2 Các độ đo tiếntrình 167

7.2.3 Các độ đo sàn phẩm 170

7.2.4 Thực hiệnđo chất lượng phần mềm 172

7.2.5 Nliìrng giới hạn củacác độ đo phân mềm 173

7.3 Giá thành cùa chấthrợng phần mềm 174

7.3.1 Các mục tiêu tính giáthànhcác độ đo chất lượng phần mềm 174

7.3.2 Mô hình truyền thống tính giá chấtlượng phần mềm 174

7.3.3 Mô hình mờ rộng tínhgiáchất lượng phaumềm 175

7.3.4 Các vấn đề hong áp dụng tính giá các độ đo chất lượng phần mềm 177

Chương 8 Các chuẩn, chửngchivà hoạtđộng đánh giá 178

8.1 Cácchuẩn quàn lýchất lượng 178

8.1.1 Phạm vi củacác chuânquăn lý chàt hrợug 178

8.1.2 ISO 9001 và ISO 9000-3 178

8.1.3 Các mỏ hìnhtăng trưởng khà năng - phương pháp đánh giá CMM và CMMI 180 8.2 Các chuẩn tiến trình dự án SQA 181

8.2.1 IEEE/EIAStd 12207- các tiến trịnh vòng đời phần mềm 182

8.2.2 IEEE Std 1012 - xác minh và thẩm định 184

8.2.3 IEEE Std 1028 - rà soát 185

Chương 9 Tổ chức đề đàmbào chất lượng 187

9.1 Giới thiệu 187

9.1.1 Cơ cấu tổ chức phát triển phần mềm 187

9.1.2 Killing tổ chức phát triền phầnmềm 187

9.2 Quàn lý và vai trò cùa quàn lý trong đămbào chất lượng phần mềm 188

9.2.1 Các hoạtđộngđàmbão chất lượng của quảnlý mức cao nhất 188

9.2.2 Nhùng trách nhiệmquàn lý phòng ban 190

9.2.3 Nliừng trách nhiệm quàn lý dự án 191

9.3 Đơn vị SQA vàcáctác nhàu khácfrong hệ thống SQA 192

9.3.1 ĐơnvịSQA

9.3.2 Nliìrng ủy viên SQAvà nhiệmvụ

9.3.3 Hội đồng SQAvà nhiệmvụ

9.3.4 Nliiệm vụ và phương thức hoạtđội ọcừ Tàiliệu tham khảo

Phụlục

192

193

194

a hiđànSQA 194

' 197

198

Chương 1 Khái niệm về chất lượng phần mềm và

1.1 Đặc điêm của phần mềm và môi trường phát triển phần mềm

Có thề nói phần mềm là một sản phẩm đặc biệt, nó không giống như các sân phẩmcông nghiệp khác nênngười ta thường gọi là phát triển phần mềm Đềphân biệt sự khác nhau giữa sân phẩm phần mềm VỚI các sàn phẩm khác ta sẽ xemxétba đặc điểm sau :(1) Độ phức tạp cùa sàn phẩm : Độ phức tạp của sàn phẩm có thể được đo bằng sổlượng phrrơng thức vận hành của sàn phẩm Một sàn phẩm công nghiệp thậm chí

là một máy tiên tiến cùngkhông cho phép nhiều hơn vài trăm phương thức vậnhành Trong khi đó, một gói phần mềm có thể có tới hàng triệu khà năng vậnhành Do đó, vấn đề đảm bảo vô số kliả năng vận hành được xác định và pháttriềnđúnglà một thách thứcchính của công nghiệp phần mềm

(2) Tính trực quan cùa sânphầm : Trong khi cár san phẩm công nghiệp có thể nhìn thấy được, thi các sàn phẩm phần mềm đều 3hình Hầu hết các nhược điểm củamột sàn phầm công nghiệp đều có thể phát k 1 trong tiến trình sản xuất Hơnnừa, rất dề dàng nhận thấy được sụ uyết thiểu" phần nào đó trong một sàn phẩm công nghiệp ( ví dụ : nk ứi ôtc 'hông có cửa sổ ) Trái lại, các nhượcđiểm trong các sản phẩm pLc mềm (đưọ< '"71 tnr trong các đìa mềm hay CD)đều không nhìn thấy được vivạ_ thực tế la các phần của một gói phần mềm có thể thiếu ngay hr đầu

(3) Tiến trình sàn xuàt ohíi triển phân mềm : Các pha trong tiến trinh sãn xuấtmột sàn phẩm

- Phát triểnsản phàm : trongsân xuấtcông nghiệp, người thiết kế và các nhàn viên đăm bão chất lượng kiểm tra nguyênmầu để phát hiện các khuyết điềm cuả chúng Trong sản xuất phần mềm, các chuyên giađâm bão chất lượng và đội phát triển có xu hướng tìm ra các lỗi săn phẩm vốn có Kết quà cuối cùng của pha này là một nguyên mầu đà đượcphê chuẩn, sần sàngđẻ sân xuất

- Lập kế hoạch sàn xuất sàn phấm : tại pha này, trong các ngành công nghiệp, tiến trình sàn xuất và các công cụ được thiết kế và chuẩn bị.Một số dòng sàn phẩm đặcbiệt cầu phảiđược thiết kể và xây dựng Do

đó, pha này đà tạo thêm cơ hội xem xét sân phẩm, và có thể phát hiện

ra các khuyết điểm đà bị người rà soát và kiểm thử bò qua trong phaphát triều Ngược lại, đây là pha khôug yêu cầu troug tiếu trình sàn xuất phần mềm, bời việc sân xuất các bàn copy phần mềm và in các

sách hướng dần phần mềm được thực hiện tự động Điều nàyđược áp dụngchobất kỳ sàn phẩm phần mềm nào, từnhỏ tớilớn.

Săn xuất : Trong pha này, các thủ tục đãm bão chất lượng trong săn xuất công nghiệp được áp dụng để phát hiện lỗi sân xuất Các khuyết điểm trong sản phẩmđược phát hiện ra ở giai đoạn đầu tiên của quátrình sàn xuất có thể được hiệu chinh bằng một thay đổi trong thiết kế sản phẩm hoặc nguyên liệu, hay trong các công cụ sàn xuất Nhờ đó

có thể tránh được các khuyết điềm này trong các sàn phẩm được sản xuất trong tươnglai Ngirợc lại, nhtr đà nói ờ phần trước, việc sân xuấtphần mềm đơn giãnclũ làsao chép các sản phẩm và incác sách hướng dần, do đó việc phát hiện các khuyếtđiềmcùa sàn phẩm rất khókhăn

Kỳ nghệ phần mềm đà có nliừng bước phát hiển đáng kể và vượt qua nhiều giai đoạnkhủng hoãng Những kết quà nghiên cứu vềkỳ nghệ phần mềmđà giúp các tổ chức pháttriển phần mềm một cách chuyên nghiệp hơn Môi ■’ròng phát triều phần mềm cũng mang nhùng nét đặc trưng riêng Với bày đặc trư tg sau ta có thê hiểu rò hơn vê môi trường phát triền cùng như môi trường bào trìphm1 'm chuyênnghiệp:

(1) Các điềukiện hợp đồng : Là kết quà ~ủa các can ’’ết và điều kiện trong bân hợpđồng giữa nhà phát triển phần IIV’UVi háchhàng, các họat động bào tù và pháttriền phầnmềm cần đương đầ' với các vân •

- Một danh sách các y< cầu chức năng được xác định mà phần mềm đượcphát Iiei àcông Vã bão tri nó phảithực hiện

- Ngânsáci hrafi

- Thời gian biểu I ủn

Nhà quàn lý việc phát triển phần mềm và bào trì dự án cầu nỗ lực lớn trong việc giám sátcác hoạtđộngđểđạtđược các yêu cầucùa hợp đồng

(2) Mối quan hệ khách hàng - nhà cung cấp : Trong suốtquá trình phát triểnvà bàotrì phần mềm, các hoạtđộngđềunằm dướisự giámsát cùa khách hàng Đội dự ánphải hợp tác liêu tục với khách hàug : để xem xét các yêu cầu thay đổi, để thào luậu nliừng gì khách hàng không bằng lòng về các kliía cạnh khách nhau của dự

án, và để đạt được sự chấp thuận cho các thay đổi theo sáng kiến của đội pháthiểu

(3) Yêu cầu làm việc theo nhóm : 3 nhâu tổ thường thúc đầy việc thành lập một đội

dự ánthayvì giao dự án cho một chuyên gia :

- Các yêu cầu về thời gian biểu Nói cách khác, khối lượng công việcđược thực hiệntrong suốt thờikỳ dự án đòi hòi sự tham gia của nhiều ngườinềnmuốndự án hoàn thành đúng thời hạn.

- Để thực hiệnđược dự án cần có nhiều chuyên ngành khác nhau

Sự rà soát lại và hỗ trợ lần nhau cùa các chuyên gia sẽ làm tăng chất lượng dự án

(4) Hợp tác và phối hợp với các đội phần mềm khác : Đẻ thực hiện được các dự án,đặc biệt là các dự án có quymô lớn, cần nhiềuhơn một đội dựán Đâylà điều rất phổbiến trong công nghiệpphần niềm Trong các trườnghợp như thế, cóthề đòihói phải hợp tác với:

- Các đội phát triển phần mềm khác trong cùng mộttổ chức

- Các đội phát hiểu phần cứng trong cùngmột tồ chức

- Các độiphát hiểu phần cứng và bần mềm của các nhàcung cấp khác

- Các đội phát hiển phần cúng và ph mềm cùa khách hàng - nliừngngười thamgiamột phần I li sự phát hì dựán

(5) Các giao diệu với các hệ thốp- ohầu mềm 'ác ■ Ngàyuay, hầu hếthệ thổug phầu mềm đều có các giao diệr VỚI ’" gói phầr mềm khác nhau Các giao diệu uàycho phépcác dừ liệu d’’ ■ 'lạng điệx ừ được“chày” giừacác hệ thốngphần mềm

Có thểđịnh nghía c 'cloại J ao diệuc 111111 sau đây ■

- Các giao Ũ1 đầu vào - uơi các hệ thốug phầu mềm khác truyền dừ liệutớihệ thổnt '!iần mềmcủabạn

- Các giao diệu đầu ra - uơi hệ thống phần mềm của bạntruyền dừ liệu

đà đượcxữ lý tới các hệ thống phần mềmkhác

- Các giao diệnđầu vào và đầu ra tới cácbàng điều khiếu của máy, uhưtrong các hệ thống kiểm soát thí nghiệm và các hệ thống y tế, thiết bịchế biểu kim loại

(6) Sự cần thiết phải tiếp tục thực hiện một dự án mặc dù thành viên đội có sự thayđổi : Việc các thành viên trong đội rời khỏi đội trongthời gian phát triều dự án làkhá phổ biển, do việc thăng chứcvới các côngviệc cấp cao hơn, chuyển sang một thành phố khác Người lành đạo đội phãi thay thế các thành viên trong đội bờicác nhân viên khác hoặc bời một nhân viênmới được tuyền dụng Khôngkể đếnbao nhiêu nỗ lực cần đầu tư vào việc đào tạo một thành viên mới, việc thayđổithành viênsè kéotheo thời gian thực hiệu dự án sèthay đổi

(7) Sự cần thiết phải tiếp tựcthực hiện việc bào tù phần mềmtrongmột thời giandài:Cáckhách hàng mua hoặc phát triển một hệ thống phần mềm mong đợi sètiếp tục

sử dụng nó trong một thời gian dài, thường là n'r 5-10 năm Trong suốt thời kỳ dịch vụ, cuối cùng cũng cần tới sựbão hi Trong hầu hết trường hợp, dịch vụ bàotiì cần được cung cấp tiực tiếp bởi nhà phát hiển Trong trường hợp các phần mềm đirợc phát triển “trong nhà”, các khách hảng “nội bộ” sè cìuig chia sẻ vấn

đề bào trì phần mềm trong suốt thời kỳ dịch vụ cùa hệ thống phần mềm

1.2 Khái niệm phần mềm

Phầnmềmbao gồm những thành phầnsau đây:

- Chương trinh máy tính

- Các thủhie

- Tàiliệu liêu quan

- Dừ liệu cần thiết cho sự vận hành của If l ng

Mồi thành phần phần mềm đều có chức nã 2 nêng va ''ất lượng của chúng đóng gópvào chất lượng chung của phần mềm và Hoti hầu mềm I mrsau:

1 Chươngtrình máy tính đượr 'n thiết là h ' iihiên vi chúng giúp máy tính vậnhành thựctlú các yêu cầun|ug dụ

2 Những thủ tục được 3 'u để dịu 'ghìa theo một thứ tự và lịchbiền của một chương trình khi Tc thi phương thức được triển khai và người chịu tráchnghiệmcho thực thi Ch I oạtđộng cần thiết choviệc tác độngvào phần mềm

3 Nliiều kiều tài liệu là cần ■ ;ếỉ cho người phát triển, người sử dụng và người có nhiệm vụ duy trì Tài liệu phát hiểu (báo cáo yêu cầu, báo cáo thiết kế, mô tãchương trìuh, v.v) cho phép sựphối hợp và cộugtác hiệu quà giừa các thành viêutroug đội ugũ phát triển và hiệu quã trong việc xem lại và rà soát cá sàn phẩm lậptrìnhvà thiếtkế Tài liệu sử dụng(thường là hướng dầu sừ dụug) cuug cấp một sựmiêu tã cho ứug dụng sần sàngvà nhùng phương pháp thích hợpcho họ sử dụng.Tàiliệu bào tri (tài liệu cho người phát triển) cung cấp chođộibão tri tất cànhừng thông tin yêu cầu về mà nguồnvà công việc và cấu trúc cho từngmodule Thôngtin này được sử dụng để tim nguyên nhàn lỗi (bugs) hoặc thay đổi hoặc bổ sung thêm vào phần mềm có sẵn

4 Dừ liệu bao gồm các tham số đầuvào, mà nguồn và danh sách têuthích hợp vớiphầnmềm đề đặc tà nhùng cái cầnthiết cho ngườisừ dụng thaotác với hệthống Một kiều khác của dừ liệu cầu thiết là chuẩn dừ liệu test, sữ dụng để sách định rò nhữngthứ thayđổi không mong muốn hong mà nguồn hoặc dừliệuphầnmềm đà từng xảy ra vànhững loại sự cố phần mềmnào cóthể được lường trước

1.3 Lỗi phần mềm và phân loại nguyên nhân gây ra lỗi phần mềm

- Fault: Là các errors mà uó gây ra hoạt độug không chính xác cùa phầumềm troug một ứng dụug cụ thể

- Failures: Các faults trở thành failures chi khi chúug được “activated” đó là khi ugười dùng cố gắng áp dụng các phần mềm cụ thể đó bị faulty Do đó, nguồn gốc của bất kìfailure uào là một errors

Việc phát lúệura lỗi là cần thiết, nlnnr 'm ra uguyt 41311 gây lỗi đểtránh lỗi trougtương lai mới thực sự quan trọng Chín 'guyt nhân gày a lỗi phầu mềm thống kê sau đây đà đượctông kẽt sau uluêu uăm p niêncứu :

1 Định nghĩa yêu cầu lồi

2 Lồigiao tiếp giừa Lnaci àug và nt ới phát triển

3 Sựthiếu rò ràng cu yêu cầu phầu mềm

4 Lỗi thiết kế logic

5 Lỗi coding

6-Khôug phù hợp với tài liệu và chi thị coding

7 Thiểu sót troug quá trinh kiểmthử

8 Lồi thùựic

9 Lỗi tài liệu

Nội dung cụ thể mỗi nguyên nhânđược xác định như sau:

- Định nghĩa các yêu cầu bị lỗi

Việc xác định các lỗi yêu cầu, thường do khách hàng, là một trong ulrừng uguyên uhâuchính của các lỗi phần mềm Các lỗr phổ biếu uhất loại uày là:

■ Saisót troug định rrghìa các yêu cầu

■ Không có các yêu cầu quan trọng.

■ Không hoàu chinh đụili nghĩa các yêu cầu

■ Bao gồm các yêu cầu kliôug cần thiết, các chức năng mà không thực sự cần thiết trong tương lai gần

- Các lỗi trong giao tiếp giữa khách hàng và nhà phát triên

Hiểu lầm trong giao tiếp giừa kháchhàng và nhà phát triển là nguyên nhân bổ sung chocác lỗi im tiên áp dụng trong giai đoạn đầu cùa quá trình phát triển:

■ Hiểu sai các chi dần của khách hàng như đã nêu trong các tài liệu yêu cầu

■ Hiểu sai các yêu cầu thay đổi của khách hàng được trình bày với nhà phát triển bằng văn bân trong giai đoạn phát triển

■ Hiểu sai của các yêu cầu thay đồi của khách hàug được trình bày bằng lời nóivới nhà phát triển trong giai đoạn phát triển

■ Hiểu sai về phàn ứng của khách hàng đối với c '.c X’U đềtlúết kế trình bày củanhà pháthiển

Thiểu quan tâm đến các đề nghị của kb'ch H y đề cập ẽen yêu cầu thay đỏi và kháchhàug trảlời chocác câuhòi nêu ra bí nhà phát tnd -hổn một phần của nhà phát triển

- Sai lệch có chủ ý từ các yêu cầu phần m

Trong một sổ trường hợp -ac UL phát trie, có thề cố tình đi chệch khỏi các yêu cầubong tài liệu, hành động thu ’P gây ra lỗi phần mềm Các lồi bong nhùng trường hợpnày là sản phẩm phụ cùa Cc thay đổi Các tình huống thường gặp nhất là:

■ Phát triển các module phần mềm Các thành phần sửdụng lại lấy từ một dự án hước đó

mà không cần phân tích đầy đù về những thay đổi và thích nghi cần thiết để thực hiệnmột cách chính xác tất cà các yêu cầumới

■ Dothời gian hay áp lực ngân sách, nhà pháttriền quyết địnhbò qua một phần của các yêu cầu các chức năng trong một nỗ lực để đối phó với nhùng áp lực này

■ Nhà phát biền-khời xướng, không được chấp thuận các cãi tiến cho phần mềm,mà không có sự chấp thuận của khách hàng, thườngxuyên bỏ qua các yêu cầu có vẻ nhỏ đổivới nhà phát triển Như vậy những thay đổi "nhỏ" có thề, cuối cùng, gây ra lỗi phần mềm

- Các lỗi thiết kế logic

Lỗiphần mềm có thề đi vào hệ thống khi các chnyên gia tliiểt kếhệ thống-các kiến trác sirhệ thống, kỳ sư phần mềm, các nhàphân tích, w - Xàydựng phần mềm yên cầu Cáclỗi điển hình bao gồm:

+ Địnhnghía các yêu cầu phần mềm bằng các thuật toán sai lầm

+ Quy trình định nghía có chứa trìnhựr lồi

+ Sai sót trongcác địnhnghĩa biên

+ Thiếu sót trong cáctrạngthái hệ thống phần mềm được yêu cầu

+Thiếu sót trong định nghía các hoạt động trái pháp luật hong hệ thống phần mềm

- Các lỗi coding

Một loạt các lý do các lập trình viên có thể gây ẩXcác lồi code Những lý do nàybao gồm sự hiểu lầm các tài liệutlũết kể, ngôn ’.gi -ai sót trong ngôn ngữ lập trình, saisót hong việc áp dụng các CASE và các cô’ g cạ phát ẩn khác, sai sóttrong lựa chọn

dừ liệu

- Không tuân thủ theo các tài liệu ng * dẫn va 5 hóa

Hầu hết các đơn vị phát triển có lei liệu X ớng dẫn và tiêu chuẩn mà hóa riêng của mình

để xác định nội dung, trình tự va tịnh dạng -ùa vãn bàn, và code tạo ra bởi các thành viên Để hồ trợyêu cầu này, VrẢvị phát triều và công khai các mầu và hướng dần màhóa Các thành viên của nhóm p '<■ triển, đơn vị được yêu cầu phải thực lúện theo các yêu cầunày

- Thiếu sót trong quá trình thử nghiệm

Thiếu sót trong quá trình thừnghiệm ànhhưởng đến týlệ lỗi bằng cách đểlại một số lỗilớn hơn không bị phát lúện hoặc không phát hiện đúng Nhừug kết quà yếu kém hr các nguyên nhân sau đây:

■ Ke hoạch thử nghiêmchưa hoàn chinh để lại phần không được điều chình của phần mềm hoặc các chức năng ứngdụng và các trạng thái của hệthống Failures trong tài liệu

và báo cáo phát hiệnsai sót và lỗi lầm

■ Nếu không kịp thời phát hiện và sửa chừa lỗi phần mềm theo như của chi dầukhôngphù hợp hong nhừug lý do cho lỗi này

■ Không hoàn chinh sửa chừacác lỗi được pháthiệndosơsuất hay thời gian áp lực

- Các lỗi thủ tục

Các thủ tục trực tiếp cho người sử dụng đối với các hoạt động là cần thiết ở mỗi bước cùa quá trình.Chúng có tầm quantrọngđặc biệt hong các hệ thống phầnmềm phức tạp, nơi các tiến trình đượctiến hành một vài bước, mỗi bước trong sốđó có thể cónhiềukiểu dữ liệuvà cho phép kiểm tra các kết quà hung gian

- Các lỗi về tài liệu

Các lỗi về tào liệulà vấn đề của các đội phát triển và bão tri đều có saisót trongtài liệu thiết kế và trong tàiliệu hướng dần tích hợp trong thâncủa phần mềm Nliừng lỗi này có thề là nguyên nhân gàyra lỗi bổ sung trong giai đoạn phát triển tiếp và trong thời gian bàotrì

Cầnnhấnmạnhrằng tất cà các nguyên nhàn gâyra lỗiđều là con người, công việc củacác nhà phân tíchhệ thống, lập hình, kiểm thừ phần F.WX?, các chuyêngia tài liệu, vàthậmchí cả các khách hàng và đại diệncùa họ

1.4 Định nghĩa chất lượng phần mề ’ 1 và đảm m chất lượng phần mềm

Theo IEEE, chấtlượng phần mề’Jdượcdị nghĩa như sau :

Chất lượngphần mềm là:

■ Mức độ mà một hệ thong moB phần ho., uột tiến trình đạt được yêu cầu dà đặc tâ

■ Mức độ mà một hệ thôn,- th '.nh phần hoặc một tiến trình đạt được những nhu cầu

hay mong đợi của khách ha> hoặc người sử dụng.

Ban đầu đàm bão chất lượng pnầii mềm có mục tiêu đạt được các yêu cầuđề ra, hiynhiên thực tế phát triển phần mềmtòn tại rất nhiều ràng buộc đòihỏi người phát triền cầntốiưuhóa công tác quăn lý

TheoDaniel Galin, kháiniệm đâm bão chất lượng phần mềm được xác định như sau :

Đăm bão chất lượng phần mềm ìà một tập các hoạt dộng dà dược lập kế hoạch và cỏ

hệ thong, cần thiết dê cung cap đầy dù sự tin cậy vào quy trình phát triền phần mềm hay quy trình bão trì phần mềm cùa săn phẩm hệ thong phần mềm phù họp với các yêu cầu

chức năng kỳ thuật cùng như với các yêu cầu quàn lý mà giữ cho lịch biêu và hoạt dộng trong phạm vi ngàn sách.

1.5 Những mục tiêu đảm bảo chất lượng phần mềm

Phát triển phần mềm luôn đi đôi với bào tri, vi vậy các hoạt động bảo đăm chất lượng phần mềm đều có mối liên quan chặt chẽ đến bào trì Nhưng mục tiêu đăm bão

chất lượng phần mềm tương ứng với giai đoạn phát triền và bào tri được xác định cụ thểnhư sau :

- Phát triên phần mềm (hướng tiến trình)

1 Đảm bào một mức độ chấp nhận đượcrằng phần mềmsèthực hiện được các yêu cầuchức năng

2 Đảmbào một mức đọ cấp nhận đượcrằng phần mềmsèđáp ímg đtrợc các yêu cầuvềlịch biểu và ngân sách

3 Thiết lậpvà quàn lý các hoạtđộng để cảithiệnvà nâng cao hiệuquà của phát triển phần mềmvà các hoạt độngSQA

- Bảo trì phần mềm (hướng sản phâm)

1 Đảmbào một mức độ chấp nhậu đượcrằng các hoạtđộngbảo trì phần mềm sèđáp ứng được các yêu cầu chức nâng

2 Đâmbảo một mức đọ cấp nhận đượcrằng các \os dộng bão trì phần mềm sè đáp ímg đượccác yêu cầu về lịch biểu và ngân sách

3 Thiết lậpvà quàn lý các hoạtđộng để 'ri thi và nâng C.10hiệuquà của bão tri phần mềm

1.6 Phân loại yêu cầu phần mềm Tg vói các yếu to chất lượng phần mềm

Đà có nhiềutác già rihiên L 11 về các J entố chất lượng phần mềm từ cácyêu cầu

cả nó Theo thời gian có the Va niệm về việc đàm bào chất hrợug phần mềm có phần thay đổi, tuy nhiên mô hình các > tố đãm bào chất lượngphầnmềm cùa McCallra đờivào những năm 70 cùa thế kỳ trước vầu còn được nhiều người nhắc đến như là cơ sờ tham chiếu các yêu cầu phần mềm Sau McCall cũng có một sổ mô hình được qưan tàmnhư mô hình do Evans, Marciuiak do hay mô hình cùa Deutsch và Willis, tuy nhiêu nhùng mô lùnli này chi bổ sung haysữa đổi một vài yếutố chấtlượng Theo McCall, các yểu tố chấthrợug phần mềmđược chia làm ba loại:

- Các yếu tố hoạt động cùa săn phẩm bao gồm tính chính xác, tin cậy, hiệu quà, tính toànvẹn, sừ dụng được

- Các yếu tố rà soát baogồm tínhbào trì,linh hoạt, có thể test được

- Các yếu tố chuyển giao bao gồm tính khà chuyển, có khã năng sử dụng lại, có khànâng giao tác

Hình Cây mô hình yếu tồ ch -ơngphần I theo McCall

Chi tiết các thuộctính được phân tích mư sau :

(1) Các yếu tố vận hành sản ị lấin chínhxấc, độ tincậy, tính hiệu quà, tính toàn vẹn và khả năng sử dp’-c, -ỢC :

Sự chính xác : Các I 'u c?H về độ chính xác được xác định trong một danh sáchcácđầu ra cần thiết cùa ' thốngphần mềm, nhtr màn hìnhhiểuthị truy vấn số drrcủa kháchhàng trong một 1 thống thông tin kế toán bán hàng Các đạc tả đầu rathường là đa chiều, một số chiều thông dụng là :

o Nhiệmvụ đầu ra (ví dụ : bàn in hóa đơn báu hàng, hay đèn báo động đỏkhi nhiệt độ tăng lên trên 250 độ F)

o Độ chinh xác yêu cầu của các đầura này; chủng có thể bị ảnh hưởng bấtlợi bời cáctính toán không chính xác hay các dừ liệu không chính xác

o Tinh đầy đủ cùa thông thi đầu ra; chúngcó thể bị ãnh hưởng bất lợi bờidữ liệu không đầy đủ

o Up-to-dateness cùa thông tin (xác định bằng thời giangiừa sựkiệnvà việcxemxét hệ thống phần mềm

o Độ sần sàng của thông tin (thời gian đáp ímg : được định nghía là thời gian cầu tlúết đểcóđược các thôugtiu yêu cầu)

o Các chuẩn choviệc code và viếttài liệu cho hệ thống phần niềm.

- Độ tin cậy : Các yêu cầu về độ tin cậy giãi quyết các lỗi đẻ cung cấp dịch vụ.Chiìngxác định tỷ lệ lồi hệthống phần mềmtối đa chophép, các lỗi này có thể làlỗi toàn bộ hệ thống hoặcmột hay nhiều chứcnăng liêngbiệt củanó

- Tính hiệu quà : Cácyêu cầuvề tính hiệu quà giãi quyếtvấnđề về các tài nguyên phầncímg cần thiếtđể thực hiệntất cà các chứcnăng cùa hệthống phần mềm với

sự phù hợp của tất cả các yêu cầu khác Các tài nguyên phần cứng chính được xem xét ờ đây là khã năng xử lý của máy tính (được đo bằng MIPS - triệulệnh/giây; MHz - hiệu chu kỳ/giây ); khà năng lưu hừ dừ liệu (dung lượng bộnhớ, dung lượng đìa - được đo bằng MBs, GBs, TBs ) và khã năng huyền dĩrliệu (thường được đobằng MBPS, GBPS ) Các yêu cầu này có thề bao gồm càcác giá tiị tối đa tài nguyên phần cứng được sừ dụng trong hệ thống phần mềm Một yêu cầu khác về tính hiệu quã đó là thời gian giữa các lần phài sạc điện đốivới các hệ thốngnằmhên các máy tính xách Gy ùay các thiết bị diđộng

- Các yêu cầu về tính toàn vẹn giải quyr caw 'ấn đề về bào mật hệ thống phần mềm, các yêu cầu này đề ngăn chặn ;ự huy cập ri phép, để phân biệt giừa phần lớn nhân viên chi được phép xem tho tinvới mt c nhóm hạn chế những ngườiđượcphép thêm vàthay đổi dr liệu

- Các yêu cầu về klià năiiị sử dụ ■ được sẽ đưa ra phạm vi của tài nguyênnhân lực cần thiết để đào ta" XX nhân V1L ’VỚÍ và để vận hành hệ thống phần mềm.(2) Các yếu tổ về rà soa mphẩm : bào trì được, linh độngvà kiểmtra được :

- Khả năng bào tri được : s vêu cầu về kliã năngbào trì được sè xác định người dùngvà nhân viênbảo trì pnãi nỗ lực thế nào để xác địnhđược nguyênnhân củacác lồi phần mềm, để sửa lỗi vàđể xác nhận việc sửa lỗi thành công Các yêu cầucủa yếu tố này nói tới cấu trúc modul của phầnmềm, tài liệu chươngtrinh nội bộ

và hướng dầnsử dụng của lập trình viên

- Tính linh động : Các yêu cầu về tính linh động cũng baogồm cã các klià năngvà

nồ lực cần thiết đểhỗ trợ các hoạt động bão tri Chúng gồm các nguồn lực (man- day) cần thiết để thích nghi với một gỏi phần mềm, với các khách hàng trongcùng nghề, với các mức độ hoạt động khác nhau, với các loại sàn phẩm khác nhau Các yêu cầu về yếu tổ này cùng hỗ trợcác hoạt động bão trì trởnên hoànhão, như thay đối và bồ sung vào phần mềm để tăng dịch vụ của nó và đề thíchnghivới các thay đổitrong môi trường thương mạivàkỳthuật của công ty

- Kliànăng test được : Các yêucầu về khànăng kiểm tra được nói tới việc kiểmtra

sự vận hành có tốt hay không của các hệ thống thông tin Các yêu cầu về khã

năng kiểm tra đrrợc liên quan tới các tính năng đặc biệt hong chương trinh giúpngười tester dễ dàng thực hiện công việc của mình hơn, ví dụ như đưa ra các kếtquã trung gian Các yêu cầu về kliã năng kiểm tra được liên quan tới vận hànhphần mềm bao gồm các chuẩn đoán tự động được thực hiện bời hệ thống phần mềm trước khi bắt đầu hệ thống, để tìm hiền xem có phải tất cà các thànhphần của hệthống phầnmềmđều làmviệc tốthay không, và để có mộtbăn báo cáo về các lồi đà đrrợc phát hiện Một loại khác của yêu cầu này là việc check các dự đoán tự động, được các kỳ thuậtviên bảo tri sử dụng để phát hiện nguyên nhân gây lồi phần mềm.

(3) Các yếu tổ về chuyển giao săn phẩm : tính hniđộng (khà năng thíchnghi với môi trường),kliã năng tái sử dụng và khà năng cộng tác được :

- Tinh lưu động : các yêu cầu về tính lưu động nói tới khả năng thích nghi của hệthống phầnmềm với các môi trường khác, bao gồmphần cứng khác, các hệ điềuhành khác Các yêu cầu này đòihòi các phầr uivin cơ bàn có thể tiếp tục sữ dụng độc lạphoặc đồng thời trong cáctrường ly p 'a dạng

- Khả năng tái sử dụng : Các yêucầu ’ ê kứả năng n sữ dụng nói tới việc sửdụng các modul phần mềm trong một dự -a. mới đang < ược phát triển mà các modul này ban đầu được thiết kế clr một dự31 ’'hác Các yêu cầu này cùng cho phépcác dự án tương lai có thể sử I gg một mo ill đà có hoặc một nhóm các modulhiện đang được phát tri ’1 Tái Sb ’’ing phần mềm sè tiết kiệm tài nguyên pháttriền, nít ngán thời Man pL K triển và ạora các moduls chất lượng cao hơn Chất lượng modul cao hc là 'lựa tiên giâ định rằng hầu hết các lỗi phần mềm đềuđược phát hiện bởi các at động đàm bão chất lượng phần mềm thực hiện trênphần mềm ban đầu, bời ni mg người sừ dụng phần mềm ban đầu và trong suốt nliừng lần tái sử dụng trước của nó Các vấn đề về tái sử dụng phần mềm đà hở thành một phần trong chuần công nghiệp phần mềm (IEEE, 1999)

2.1.1 Tiến trình rà soát hợp đồng và các f thực hiện

Có khá nhiều tình huống có thể giúp một công ty phu mềm (“nhà cung cấp”) ký hợpđồng với một khách hàng Phổ biến nhất là:

• Tham gia trong một cuộc Au thầu

• Đưa ra bàn phác thảo dựa trc vêu cầu đề xuất (RFP-Request For Proposal) của khách hàng

• Nhậnmộtđật hàht Armột khách hàngcùa công ty

• Nhậnmột yẻu cầuhr b< tronghoặc hr phòng ban khác hongmộttổ chức

Rà soát hợp đồng là một thành phần của SQA đrrợc nghi ra để hướng dần xem xét lại những bàn dự thào cùa nhùng tài liệu đề xuất và hợp đồng Nếu có thể, rà soát lại hợpđồng còn cung cấp sự giám sát nhùng hợpđồng được thực hiện với những đối tác dự ántiềm năng và cácnhà thầuphụ Tiến trình ra soátcóthểđược chia thành hai giai đoạn:

• Giai đoạn 1: rà soát lại bàn dự thào đề xuất trước khi giao cho khách hàngtiềm năng (“rà soát bàn dự thào đề xuất”) Giai đoạn này rà soát lại bản dự thào cuối cùng và nhùng cơ sờ đề xuất: nhùng tài liệu yêu cầu cùa kháchhàng, chi tiết yêu cầu thêm cùa khách hàng và dự diễn giải các yêu cầu, các ước lượng chiphí và tài nguyên, những hợp đồng hiện tại hoặc là nliừng bàn

dự thào hợp đồng của nhà cungcấp với các đổi tác và nhà thằn phụ

• Giai đoạn 2: rà soát lại bân dự thào hợp đồng trước khi kí (“rà soát bàn dự thào hợp đồng”) Giai đoạn nàyrà soát lại bàn dự thào hợp đồng dựa trên đề

xuất và sự hiểubiết (bao gồm cà uhừng thay đối) đà đạt được trong quá trinhthương thào hợp đồng.

Quá trình rà soát có thể bắt đầu kill những tài liệu dự thào liên quan đà hoàn thành Nliừng cá nhân thực hiện rà soátphải xemxétkì lường bàu dựthảotrong kin đề cập đếnmột phạm vi toàn diện các đổi tượng đang rà soát Một danh sách kiểm tra là rất him íchcho việc đàm bảoxemxét hết các vấn đề liênqưan

Sau khi hoàn thành giai đoạn rà soát, việc cầnthiết nhìmg sự thay đỗi, cáithêm vàovà sựhiệu chình phải được thông báo bời đội đề xuất(sao kill rà soát bản dự thào đề xuất) vàbời ban phụ trách về luậtpháp (saukhi rà soátlại bàn dự thảo hợp đồng)

2.1.2 Các mục tiêu rà soát hợp đồng

- Những mục đích của công việc rà soát bân dự thảo đề xuất

Mục đích của việc rà soát bàn dự thào đề xuất là để drill bảo rằng nhưng hoạt động sau đượcthực hiệnmộtcáchthòa đáng

1) Những yêu cầucùakhách hàng đà đi ợc gia híchchi tiết và có chú giải

Nhừngtài liệu yêu cầuđề xuất (RFPt và L riig tài liệu ,ongnghệ tương tự cóthể quáchungchung và mơ hồ cho những mục tiêu Ci dự án Kếtquà là có nhiều chi tiết cầnđược thêm vào từ khách hànr„ Vi ' giải thích chi tiết những yêu cầu mập mờ vànhững cập nhật của chúng ’iân được t : lại trong một tài liệu riêng biệt đà được sự chấp nhận của cà khách hàng \ công ti p anmềm

2) Lựa chọn nhùng Px ’^ng pháp thực hiệndự ánđà được kiểmtra

Thông thường, những lựa chọi .0 triển vọng và phù hợp mà tiên đó thề hiện một đềxuất thì đã được xem xét đầy đủ (nếu tất câ) bởi đội đề xuất Điều kiện này đậc biệt muốn đề cập đến việc hoàn thành thay thế bao gồmtái sử dụng phần mềm, và nhừng quan hệ đối tác hoặc là thầu lại với nhưng công ti mà có hiểu biết chuyênmôn hoặc nhân viêncó chuyên môncóthểđàmbào những điều klioàn của đề xuất

3) Nhữngkhía cạnh hình thức của mối quan hệ giừa khách hàng và công ti phần mềm pliãiđược ghi rò

Đề xuất nên địnli nghía nhưngthủtục bao gồm:

• Sự giaotiếp vớikháchhàng và nhìmg kênh giao diện

• Việc chuyển giao dự án và tiêu chuẩn được chấp nhận

• Tiến trình phê chuẩnphahìnhthức

• Phương tlứrc tiếp theo khách hàng thiết kế và kiểmtra

• Thủ tục khách hàng thayđổi yên cần

4) Xác địnhnliừng rủi ro khi phát triển

Nhừug nil ro khi phát triển, nlnrkhông đủ kiến thức chuyên môn liên quan đến lình vực nghiệp vụ cùa dự án hoặc cách sử dụng nhùng công cụ phát triềnyêu cầu, cầnđượcxác địnhvà giãi quyết

5) Ước lượng đầy đủ nhùngtàinguyênvà thờigian biểucủa dự án

Việc ước lượng tàinguyên đề cập đến độingũ nhân viên chuyên nghiệp và ngân sáchcùa dự án, bao gồm cả clú phí cho các nhà thầu con Việc ước lượng thời gian nêuđưa vàonhững yêu cầu về thời giancùa tất cà nhùng bên tham giavào dự án

Lưu ý

Trong một vài tìnhhuống, một nhà cung cấp cố V Ưnghị cung cấp một chi phí thấp, xem xét các yếu tố như tiềm năng bán hàng " ong trường hợp này, khi mà đề xuấtdựatrên ước lượng thực tế của thời gian, Ị1„ an sa, và khả nâng chuyên môn, những tổn thất phát sinh được coi là một mất' át có thể tư được, không phải là một hợpđồng thấtbại

6) Kiểm ha uãng lực của óng dối với dựán

Việc kiềm tra này nên XC111 A đếnnănt ực chuyên môn cùng nhir là khâ năng sẵn sàng của những thành » 'n troi gđội được yêu cầu và nhữngklià năng phát triển trongthời gianđãđược lập lịch

7) Kiểm ha uãng lực của k ^ach hàng để đápứngnhừug yêu cầu củaminh

Việc kiểm tra này đề cập đến khâ năng tài chính và tố chức của khách hàng, nhưtuyển dụng và đào tạo nhàn sự, cài đặt phần címg yêu cầu và nâng cấp các thiết bịliênlạc

8) Định nghía đối tác và nhà thầu phụ tham gia

Điều này bao gồm các vấn đề bão đảm chất lượng, lịch trình thanh toán, phân phối thunhập, lợi nhuận của dự án, và hợp tácgiữa quân lý dự án vàcácđội

9) Định nghía và bão vệ quyển sở hữu

Yếu tố này có tầm quan trọng trong trường hợp tái sữ dụng phần mềm, khi việc có thêm một gói mới vào hoặc có tái sừ dụng phần mềm lúện nay trong tưoiig lai haykhông cần phãi đượcquyết định Nó cũng đề cập đến việc sử dụng các file độc quyền cùacác dừ liệu quan họngcho hoạt động của hệ thống và các biện phápan ninh

Nhùng mụctiêu cùa rà soát lại bàn dự thảo đề xuấtđược tổng kết trong bàng sau:

Nhùng mục tiêucủa việc rà soát bản dự thào đề xuất

9 mục tiêu của việc rà soát bân dự thào đề xuât đám bão rằng những hành động sau đàyđược thực hiệumộtcách thòa đáng:

1 Nliừng yêu cầucùa khách hàng đà được giải thích chi tiết và có chú giãi

2 Lựa chọn nhùng phương pháp thực hiện dự án đà được kiểmtra

3 Nhùng khía cạnh hình thức cùa mối quan hệ giừa khách hàng và công ti phần mềmphảiđược ghirò

4 Xác địnhnhừug rủi ro khi phát triều

5 Ước lượng đầy đủ nhùng tài nguyên và thời gian biểu cùa dự án

6 Kiểm tra năng lực cùa công ti đối với dự án

7 Kiềm tra năng lực của khách hàng để đẩ± ứng8 mg yêu cầucủaminh

8 Định nghía đối tác và nhàthầu phu thờ sia

9 Định nghía và bão vệ quyển r hừu

- Những mục tiêu của rà soá' thảo họ Ấ ^ồng.

Nlrừng mục tiêucùa việclã ''át b ndự thào hợp đồngđể đàmbảoràng nhũng hoạt động sau đâyđược thực hiệu một ca< fhòa đáug:

1) Không có vấn đềchưarò ra.ig nào vẫn còn lại trong dự thào hợp đồng

2) Tất cà nhữngthòa thuận đạt được giừa các kháchhàng và công ty phải đượcgiải tlúch đầy đủ và chính xác trong hợp đồng và phụ lục của nó Nhừng hiềnbiếtnàyđược dùng để giãi quyết tất cã các vấn đề chưa rò ràng và khác biệt giữa kháchhàng và công ty mà đà đượcđưa ra cho đến nay

3) Không có sự thay đồi, bồ sung, hoặc thiếu sót nào không được thão luận và sựthoâ thuận nên được đưa vào dự thào hợp đồng Việc thayđối, dù cốý hay không,

cỏ thẻ dẫn đến sựbổ sung đáng kề và những nhiệm vụ bất ngờ trong một bộ phận của nhà cung cấp

Nlrừng mục tiêucủa việc rà soát lại dự thão hợpđồngcóthể đượctổng kếttrong bàng 5.2

Nlrừng mục tiêucủa việc rà soátdự thào họp đồng

Ba mục tiêu cùa việc rà soát dự thào hợp đồng nhằm đàm bào nhìmg hoạt động sau đàyđượcthực hiện một cáchthòa đáng:

1) Không có vấn đềchưarò ràng nào vần còn lại trong dự thào hợp đồng

2) Mọi thóa thuận đà đạt được sau khi xem xét những đề xuất phãi được chú giãi mộtcách chínhxác

3) Không có sựthayđối,bổ sruig,hoặc thiếu sót đưa vào bàn dựthảohợp đồng

2.1.3 Thực thi rà soát hợp đồng

Duyệthợp đồngkhác nhau vềđộ lớn của chúng, tùy thuộc vào các đặc tính của dự án

đề xuất Phức tạp này có thề là kỳ thuật hoặc tổ chức Theo đó, mức độ khác nhau củanguồn lực chuyên môn được điều chinh phù hợp cho 'hừng duyệt hợp đồng khác nhau Những nguồn lực chuyênmônđặcbiệtcầuthiết ch 'ihừngđề xuất chính

- Những yêu tố ảnh hường tới phạm vicủamột L ăndu> hợp đồng

Các yếu tố quan trọng nhất của dự án xác đụ mức độ C11 nợp đồngnỗ lực xem xét lại yêu cầu là:

■ Độ lớncùa dựán, thường được 10 bãi sácnguồnlực man-month

■ Kỳ thuậtphức tạp cùa dự á

■ Trình độ và sự hiểu biet W n’ an viên có kinh nghiệm trong 1Ũ111 vực của dự án Sựhiềnbiết với các lình vực dự án ' thường xuyên được liênkết với khả năng tái sử dụng phần mềm; trong trường hợp có thế tái sử dụng phần mềm là cao, mức độ duyệt được giãm xuống

■ Tổ chức dự án phức tạp Càng với số lượng lớn của các tổ chức (nghía là, các đối tác, nhà thầuphụ, và khách hàng) tham gia các dự án, thì càng yêu cầu công sire rà xoát hợpđồnglớn hơn

Do đó chủng tôi có thể cho rằng "đơn giãn" việc duyệt hợp đồng sè được thực hiện bời một người xem, họ sè tập trung vào mộtvài chù đề và đầu tư ít thời gian để xem lại Tuy nhiên, hợp đồng quy mô lớn có thể yêu cầu sự thamgia của một đội để nghiên cứu một loạt các vấn đề, một quá trình đòi hỏi sựđầutư cùa nhiều giờ làm việc

- Tác nhân thực thi duyệt hợp đồng

Nhiệmvụduyệt lại hợp đồng có thề được hoàn thành bởi các cánhân khác nhau, được liệt kê ở đây theothứ ựr tăngdần thông quasựphức tạp của dựán:

■ Các nhà lành đạo hoặc thành viênkhác của nhóm đề xuất

■ Các thành viên của độiđề xuất

■ Một đội ngù nhân viên chuyên gia bênngoài hoặc nhàn viên của công ty nhùng ngườikhông phài làmột thành viên củanhómđềxuất

■ Một nhóm các chuyên gia bên ngoài Thòng thường, một nhóm rà soát lại hợp đồng bao gồm các chuyên gia bên ngoài được mời đếnđể đưa ra cácđề xuấtchuyên môn đậcbiệt Các chuyên gia có thể được mời đếnđểrà soát lại hợp đồng trong các tổ chức pháttriển phần mềm nhò do khôngthể tim thấy dữ các nhân viên thích hợp trongđội ngũnhânviêncủa họ

- Thực hiệnrà xoát lại họp đồng cho đề xuất chính

Đề xuất chính được đề nghị cho các dự án đặc hu bởi ít nhất một sổ các yếu tố sau:quy mô dự án rất lớn, kỳ thuật rất cao và p'iức tạp, Ill vực chuyên môn mới, tổ chứcphức tạp cao (nhận ra bời một số lượng ’ớn íl tổ chức, r.ghìa là, đối tác, nhà thầu phụ,

và khách hàng, tham gia mộtphần h ’'g dự án na, Thực hiệuquá trình rà soát lại họpđồng cho một dự án lớn thường l ên qik đểu đáng kể đến khó khăn cùa một tổ chức Một sổ con đường đểvượt qua m ng khó k an được đề nghị ờ đày, sau sự xem lại củacác yếu tổ giớithiệu nhiều ki khan chomột hoành thành mịn của nhiệm vụ

2.1.4 Những khó khãn của t.iực hiện xem ỉại hợp đồng cho các đề xuất

chính

Hầu hết mọi người đều đồng ý rằng xem xẻt lại hợp đồng là một thù ựic chính chogiàmnguy cơthất bại cùa dựán lớn về căn bân, việc rà soát hợpđồng là khó khãn, đặcbiệt là đối với những tình huống rà soát các yêu cầu đề xuất chính

■ Áp lực thời gian Cà hai giai đoạn của việc xem xét họp đồng, đề nghị xem xét lại dự thào và xemxétdự thào hợpđồng thường đượcthực hiệnkhinhómđềxuấtlà dưới áp lựcđáng kề về thời gian Kết quà là, mồi giai đoạn của việc xem lại hợp đồng phải được hoàn tất trong vòng một vài ngày để giúp cho người tiếp theo điều chinh các văn bãuđược diễnra

■ Quy tắc duyệtlại hợp đồug yêu cầu phải làm việc chuyêunghiệp Chuyêu nghiệp hiệusuất của mỗi giai đoạn của việc xem lại hợp đồng yêu cầu sự đầu tư chuyên nghiệpđáng

kể của các chuyên gia (sổ lượng thời gian yêucầu khác nhau, tất nhiên, tùy theo bàn chất củadự án)

■ Các thànhviêntiềm năng bong nhóm rà soát Hợp đồng đều rấtbận rộn Những thành viên tiềm năng của đội duyệt hợp đồng thườnglà nhân viên cấp caovà các chuyên gia và

họthường camkết thực lúệnthường xuyên nhiệm vụ của họ tại tất cà thời gian được xem

là cần thiết Các chuyên gianhàn rỗi có thể do đó là một vấn đề hậu cần quan trọng

2.1.5 Khuyến cáo cho việc thực hiện duyệt lại những hợp đồng chính

Một kế hoạchxem lại hợp đồngmột cách cần thập quyết định thành công của nhóm rà soáthợpđồng Các bướcsau đây đượcthực hiện ue điềukiệncho quy trình rà soát

■ Các hợp đồng nên đrrợc rà soát theo lịch :uh Xem Xv ’»1 các hoạt động rà soát hợpđồng nên được đưa vào lịchtrình clnưa bị đề X \ để lại đầy đủ thời giancho việc xemlại vàchinh tiếp theosè đượcthực ùiệi

■ Một nhóm thực hiện rà soh lạ! ác hợp G Làm cho nó có thế làm việc theo nhóm

để phân phổicác khốihrựn^, ông /iệc giữa các thành viên trong nhóm sao cho mồi thành viên của đội xem lại hợp đồng fhể có đùthời gianđể làm (có thề bao gồm việc chuẩn

bị một bản báo cáo bằng văn bàn ma tóm tắt củaminhulừmgpháthiện và kiến nghị)

■ Lành đạo của đội rà soát hợp đồng nêu đượcbổ nhiệm Điều quantrọng là trách nhiệmcho các tổ chức, quàn lý và kiểm soát các các hoạt động rà soáthợp đồng được xác định, thích hợp 11011 bằng cách bốnhiệm một lànhđạo cùa đội Cáihoạtđộng của các lành đạođộibao gồm:

- Tuyển dụng của các thànhviêntrongđội

- Phânphối các nhiệm vụ rà soátgiừa các thành viêncủa nhóm nghiên cím

- Phổihợp giừacác thành viên của đội duyệt

- Phổi hợp giừacác độituyểnxemxétvà đề xuất

- Theo dòi các hoạt động, đặc biệt làviệc tuânthù theo lịch biểu

- Tổng kết những pháthiệnvàphân phổichúng tớ nhómđề nghị

Lim ý:

Theo xem lại hợp đồng có thể áp đặt một kliối lượng công việc đáng kể và bổ sung

áp lực vào các nhóm đề xuất, nghi nênđược trao cho khi nó có thể được thích hợp đểtránh không tiếu hành rà soát hợp đồng Tìnhhuống có thể xảy ra với các dự án quy mônhò, hoặc dự án quymô chi phí vừa và nhỏ Các thủ ựic rà soát hợp đồngnên được xácđịnh thànhnhững loại dự án mà rà soát lại hợp đồng là không bẳt buộc Đối với các loại khác được định nghĩa dự án "đơn giàn" , nó khuyến cáo rằng quyền được trao cho một người quàn lý cao cấp để đưara quyết định để xem ở đàu để thực hiệnxem lại

2.1.6 Các đoi tượng rà soát hợp đồng

Duyệt hợp đồug đtrợc thực hiện bởi nhiều đối tươag dựa tre^ iệc đánh giá mục tiêu cùa họp đồng Bảng kiểm mục (checklist) là công cụ hữu ích cho m ọ lúp đội xem ‘ dể tổ chức công việc của minh và đạt được nhiều thông tin của những vấn đề liên 'n Rt ' ng là rất nhiều vấn đề trên các danh sách này là không thích hợp đối với bất kỳ dự án cụ thể ’’ại cùng một\A’ điềm, ngay cá một danh sách kiểm tra toàn diện có thề loại trừ một số vấn đề quan t- mg « ';ên quan đến một đề xuất dự án đã định Đây là nhiệm vụ cùa đội rà soát hợp đồng, nhưng đặc biêi là của C 'thà lãnh đạo, để xác định danh sách các vấn đề thích hợp cho các để xuất dự án cụ thể.

2.1.7 Rà soát hợp đồng V / các dự án nội bộ

Một số lượug đáng kề, nếu klit 3phãi lả đa sổ, các dự án phần mềmlà dự án các dự

án nội bộ - dự án "trong nhà" - được thựchiện bời một bộ phận cùa một tồ chức cho một

bộ phận của tổ chức đó Trong trưởng hợp như vậy, việc đơn vị phát triểnphần mềm lànhà cung cấp, trong khi các đơn vị khác có thể được coi là khách hàng Thường xuyên,

dự ánphát triển phần mềmnội bộ không dựa trẻnnhữnggi sè được xemlàmột mối quan

hệ đầy đủ khách hàng -nhà cung cấp Trong nhiều trường hợp, các dự án này được dựa trên các thỏa thuận chung,với thiện chí đóng vai trò quan trọng trong mối quan hệ giừahai đơn vị Nó sau rằng các đơn vị đang phát triển sè thực hiện chi một đoạn ngắn và

"nhẹ" duyệt hợp , hoặc không ai cả

Bảng : Chuẩndự án nội bộ vàkháchhàng trong cùngtổ chức

Thậtkhông may, mối quan hệ lò’ thu 'ơ được đà.c tnnrg bời không đủ tlú nghiệm các yêu cầu của dự án, lịch biểu, X 'yên vàI ’’ttriển các rủi ro Kếtquã là, nhùng vẩn đềsau đây cókliã năng xảyra

(1) Quá trinhđịnh nghía khôngti xứng với yêu cầu dự án

(2) Nghèo nàn trong việc đánh giá yêu cầu

(3) Thời khóa biểu /lập lịch trình nghèo nàn

(4) Không tương xímg nhận thức về nhưng nguy cơ về rủi ro

Theo danh sách này cho thấy, chúng ta có thể dễ dàng kết luậnrằng “in hourse”, thựchiện dự án cho các khách hàng nội bộ đượcnhiều dễ bị thất bại hơn là những hợp đồng

dự án bên ngoài

Có thể kết hiận rằngmối quan hệ khách hàng-nhà cung cấp và việc xem lạihọp đồng

đó được chửng minh là có hiệu quâ cho các dự án bên ngoài nên được áp dụng cho các

dự án nội bộ Các cơ hội tráuli nên trên nhùng vấn đề tiềm năng có thể được cài thiệnđáng kểbằng cách thực hiệnthủựic đó sè xác định:

■ Một đề xuất phù hợp cho dự án nội bộ

■ Áp dụng mộttiếntrinhxemlạihợpđồng đủng cáchcho các dự án nộibộ

■ Thòa thuận thíchđáng giừa các kháchhàngnội bộ và các nội bộ nhàcung cấp

- Nhược điếm cùa "các mối quan hệ lỏng" nội bộ dự án

Xung đột được gây ra bờicác yêu cầu cho việc thêm ngân sách

Thờikhóa biểu /lập lịch

nguy cơ về rủi ro

Chưa chuẩn bị cho nhừng rủi rocùa dự án và nhùng hậu quàcùa chúng

Sự khởi đầu chậmchạm củanhàu lực đẻ khắc phục khókhăn

2.2 Các kế hoạch phát triển và kế hoạch chất lượng

Hày tường tượng ràng bạn vừa được bố nhiệm làm người đứng đầu một dự án khálớn Nlnr là thường xày ra trong ngành công nghiệp phần mềm, bạn chịu nhiều áp lựckinh khủng về thời gian từ ngày đầu tiêu Bởivì bạn đà là thành viên cùa đội đề xuất và tham giavào hầu hết các cuộc họp với đại diệncủa khách hàng, bạn có tự tin rằngbạn đà biết tấtcà nhùng gi là cầnthiếtcho công việc Bạn định đề nghị sử dụng kế hoạch và tài liệu nội bộ mà đội đà chuẩn bị như bàn kế hoạch về phát triển và chất hrợug Bạn đã chuẩn bị đểdựavào các tài liệu này bời vi bạn biết rằng cácđề nghịvàước lượng của nó, bao gồmcã thời gianbiểu, yêucầunghiệp vụ, danh sáchcác tài liệu dự án,đánh giá thiết

kế dựkiến, và danh sách các lùi ro khiphát triểnthông qua xem xét kỳ lường bởi nhómxemxét lại hợp đồng

Vì vậy bạn có một chút thất vọng ràng tạithờiđiềm rất quan trọng này của dự án,phòng quản lý phát triển yêu cầu bạn ngay lập tứcchuẩn bị cáckếhoạch phát triển dự ánmới và liêng biệt ("Kế hoạchphát triển") và các kí- hoạch chất lượng ("Kế hoạch chất lượng") Khi bạn cho rằng đề nghị hoàn thành ’ đ p lục của nó có thề phục vụ như làcác kế hoạch yêu cầu, người quản lí nhấn mmh rằng L ~ó thề cập nhật, với các chủ đềmớivà toàn diện hơn đế đàm bào đầy đủ nhai 'a kế hoạch Bằng cách này," ngườiquản

lý đề cập gần như là sang một bên ", <ưug quên -Ig khoảngthời gian bây tháng hr ghra các việc chuẩn bị đề nghị và ký '_et^ •n đồng Đè, như là một khoảng thời gian chết hong dự án của chúng ta "

Bạn nên mongmir rằng 1 gười quàn lý cùa bạn là đúng Công sức và vốn đầu hĩtrong việc chuẩn bị các kế ht 'k phát triển và chất lượngchắc chắn sè mang lại lợi ích Bạn có thể nhậu ra rằngmột số I ’nb viêu trong đội sè kliôug sẵusàug tại các ugày theo thời giaubiểu do chậm trề trong việc hoàu thàuh công việc hiện tại của họ, hay rằng các công ty hr vấn đà đồng ý cung cấp hồ trợ chuyên môn trong một lình vực chuyên môn hoá cao và quan trọng đà bị thiệt hại nặng và bị phá sản trong thời gian ngắn Đây chi làhai trong các loại của các vấn đề có thể nãy sinh

Tổngkết lại, dựáncần các bản kế hoạch về phát triển vàchất hrợnguhirsau:

• Phải dựa trên các đềnghị sơ khai mà đà được kiểm ha lại một cáchkỳ lượng vàcập nhật liên tục

• Phãi toàn diệu hơu so với đề ughị phê duyệt, đặc biệt là với quau điểm về thời giaubiểu, đánh giá tài nguyên,đáuh giá lùi ro và phát triển

• Bao gồm bổ sung các đối tượng vắng mặthr đề nghị phê duyệt

• Chúng ta đà chuẩn bị ở giai đoạn đầu của dự án để có thể cành báo về khó khautrongviệc lập kế hoạch, tiền năng thiếu nhân viên,các nhântố phát triển, các vấn

đề với các cuộc họp tại các mốc quan trọng trong hợp đồng, nhùng rủi ro pháttriển được sừa đồi,

Ke hoạch pháthiển và chất lượng là những yếu tố chínhcần thiết cho việc tuân thù các tiêu chuẩn dự án với 9000.3 Đây Cling là một yếu tổ quan trọng trong Capability MaturityModel (CMM)để đánh giá sự trưởng thành cùa tố chức phát triển phần mềm

2.2.1 Những mục tiêu của kế hoạch phát triển và kế hoạch chất lượng

Ke hoạch, như là một quá trình, có nhiều mục tiêu,mỗimục tiêu trong số đó có nghía

là đẻ chuẩn bị đầy đủ trên cơsở sau đây:

1) Các hoạt động lập thời gian biểu phát triển sè dần đến thành công và kịp thời gian hoàn thành dựán, và ước lượngđược nguồn nhân lực, yêu cầu và ngân sách

(2) Các thành viên đội tuyển dụng và việc phân bồ nguồn lực phát triển (theo lịch trinhhoạtđộngvà yêu cầuước lượng nguồn nhân lực)

(3) Giải quyết các rin ro phát triển

(4) Càiđậtcác hoạt độngđược yêu cầu của SQư

(5) Cung cấpviệc quàn lý với dừliệucần rhit pề kiểm soa Jự án

2.2.2 Các thành phần của kế /1 'c/zphát 1, /í

Cãn cứ vào tài liệu đề nghi hoạch hát triển cùa dự án là chuẩn bị sần sàng

để hoàn thành các mục tier trên < ic yếu tố au đây áp dụng cho các thành phần của dự

án khác nhau bao gồm kế 110 h rùát triển dự án

(1) Sản phẩm dự án:

Ke hoạch phát triều bao gồmcác sân phầmsau:

■ Tài liệu thiết kế chi tiết xác định ngày hoàn thành, chỉ ra nliừug gi được chuyển giao cho khách hàng ("phân phối")

■ Sănphẩm phần mềm(xác định ngày hoàn thành và cách cài đặt)

■ Đào tạo nghiệp vụ(chirò ngày tháng,người tham gia vàcác site)

(2) Giao diện dự án:

Dự án bao gồmcác giao diện:

■ Giao tiếp với các gỏiphầnmềm hiện có (giao diện phần mềm)

■ Giao tiếp với các phần mềm khác và / hoặc nhóm phát triển phần cứng đang làm việc trên cùng một hệ thống,dự án (tức là, hợp tác và phối hợp liên kết)

■ Giao tiếp với phần címghiện tại(giao diện phần cứng).

(3) Phương pháp luận và công cụ phát triển dự án được áp dụng ờ mỗi giai đoạn của dự án.

Chi dấn thực hiện

Khi dành giá sự phù họp cùa dự án với các phương pháp và công cạ phát trỉên dược đề xuất, chúng ta cùng nên đưa vào kinh nghiệm chuyên môn cùa dội ìigù nhân viên, bao gồm cà nhân viên cùa nhà thầu phụ, thậm chi nếu tạm thời.

Hoạtđộngmô tảbao gồm:

(a) Ước tính về thời gian của hoạt (ựng Nh <ĩ ước tứih phụ thuộc nhiều vào kinhnghiệmthuđược trong cácdự án tn’o dó

(b)Chuỗi các hoạt động hợp lý ‘■’■ong đó X 'ĩ hoạt động được thực hiện, bao gồm mô tã

sự phụ thuộc của hoạt động vào các hoạt động trước đó đà hoàn thành,(c) Các kiều nguồn lực chu) ' rr JU cần tlúết và ước lượngcần bao nhiêunguồn lực cầnthiếtchoh'mg hoạtđộng

Chi dân thực hiện:

Các hoạt động SQA, như xem xét lại thiết kế và test phần mềm, nên được bao gồm trong

các hoạt động dự án theo lịch trình Việc này cùng được áp dụng cho các hoạt động thiết

kế và chinh sữa mà Không có kế hoạch các hoạt động này có thè gây ra sự chậm trê unanticipated trong việc khởi xướng các hoạt động tiếp theo.

Một số phương pháp có sần cho việc lập lịch biểu và trình bày bằng hình ânh (đồ họa)quá trinh phát triền Một trong những phương pháp phổ biếu nhất là sử dụng biểu đồGantt, hiểutlụ các hoạtđộngkhác nhau bời các thanh ngang có độdàiti lệ thuận với thờigian của hoạt động Các thanh đại diện cho các hoạt động của mình, và được đặt theo chiều dọc, theo kếhoạch và bắt đầukếtluận của chúng Một vài công cụ trên máy vi tính

cóthề chuẩn bị cácbiểu đồ Gantt, thêm vào đề cung cấpmộtdanh sách các hoạtđộng bời thờigian cần thiết đề bắtđầuvà kết thiìc của chímg, V V

Thêm một phương pháp lập kế hoạch nâng cao, như CPM và Pert, cả hai đền thuộc loạiphân tích con đường quan trọng, có trình tự phụ thưộc vào thời gianhoạtđộng thêm vào.Chúng chophép tính toán thời gian sớm nhất và muộnnhất được chấpnhận cho mồi hoạtđộng Sựkhác nhan giừa các thời gianbắt đần phụthuộc vào tính linh hoạt của các hoạtđộngđược lậplịch Đặc biệt chú ý đếncác hoạtđộng thiếuthời gianbiểu linh hoạt (đượcgọi là các hoạt động “critical path”), và hoàn thành vội vàng có thể gây chạm trề trongviệc ký kếtcủa toànbộ dự án.

Một số gói phần mềm, sử dụng kết hợp các phương pháp, hỗ trợ việc lập kế hoạch, báocáo và theo dõi thời gian biểu của dự án Mộtví dụvề một gói phần mềm của loại hìnhnày là dự Microsoft Project ™ Để thào luận chi tiếthơn vềviệc lập lịch, hàythamkhão các sách viết về quànlý dựán

■ Sổthàrili viêncủanhóm cần thiè cho hmg thời kỳ, theo các hoạtđộngđà được lập lịch

Dự kiến các độisè bắt đầu hoạt động của họ vào các thời điềm khác nhau, và kích thướcđội của họ có thể khác nhau tại mỗi khoảng thời gian, tùy thuộc vào các hoạt động đà được lập kế hoạch

■ Têu của các nhà lành đạo đội và các thành viên nhóm Nhùng khó khăn được dự kiến

sè phát sinh đổi với việc giao lâu dài của nhân viên đề các đội vì sự thay đổi trong tậpunanticipated hiện tạicủa họ

Vi vậy, tên cùa các nhân viên được yêu cầugiúp theo dòi sự tham gia của họ như thành viêncủa nhóm

Chi dân thực hiện:

Tỉnh săn có ìân dài cùa nhàn viên dự án nên dược kiêm tra cân thận Chậm lại trong hoàn thành nhiệm vụ trước đây có thê dân đến sự chậm trê trong việc gia nhập nhóm dự

án, trong dó tăng nìi ro không họp lại được tại các mốc quan trọng cũa dự án Ngoài ra,

nhân viên bốc hơi "" gây ra bời chức và / hoặc các chương trình khuyến mại, hiện tượng

đó là đặc biệt thường xuyên trong ngành công nghiệp phần mềm, có thê gây ra tình trạng thiếu nhân viên, Vỉ vậy, ước lượng khà năng săn có cùa nhân viên nên được kiêm tra định kỳ đê tránh những "ngạc nhiên" Cành báo sớm về tình trạng thiếu nhân viên bất khâ kháng, làm cho nó dê dàng đê giãi quyết vấn dề hon.

(8) Các nhân tố phát triên:

Các nhân tố phát triển bắt bnộc bao gồm phần cứng, phần mềm và công cụ phát triểnphần cứng, không gian văn phòng, và các mặt hàng khác Đối với h'mg nhân tố, khoáng thời gian cần thiếtchoviệc sửdụng nó nên được ghi trên thời gianbiểu

■ Các khoảng trổngcông nghệ - Thiếukiến I ’C chuyên 11 11 phù hợp và đầy đùvà kinhnghiệm để thực hiệucác nhu cầu của CUC hợpđoi nháttriền

■ Thiếu nhân viên - hụt Unanticif tedc đội ngũ miânviênchuyênnghiệp

■ Sự phụ thuộc lần nhau cữd ca< 'ếu tố to \ưc - Các khã năng của các nhà cung cấpphần cứng hoặc phần mềm ’ưiyê’.dụng của nhà thầu phụ, ví dụ,họ sẽ không thực hiệunghía vụ của họ nhir trên thời g a biểu

Hệ thống hoạt động quân lý rủi ro -lén được kliời xướng để đổi phó với chúng Quytrinhquân lý rủi ro bao gồm các hoạt động sau đày: nhận biết rủi ro, đánh giá rủi ro, lập kế hoạch hành động quân lý rủi ro (RMAs), thực hiện RMAs, và giámsátcác RMAs

Phầnmềm RMAs được đưa vào kế hoạch pháttriều

Tầm quan trọng ngày càng tăng của phần mềm quãn lýrủi ro được thể hiện trong môhình xoắn ốc của cácvòng đời phầnmềm Để đối phó với các loại rủi ro, một giai đoạnđặc biệt dành riêng đề đánh giá rủi ro phần mềm được chi định cho mỗi chu kỳ xoắnốc(Boehm, 1988, 1998)

(10) Các phưong pháp Idem soát:

Để kiểm soát việc thực hiện dự án, quàn lý dự án và quân lý phòng áp dụng một loạt các giám sát thực tiễn khi chuẩn bịbáo cáo tiến độ vàphốihợp với các cuộchọp

(11) Ước lượng chi phí dự án:

ước lượng chiphí dự án là dựa hên đề xuất dựtoánchiphí, sau đólà xemxét kỳ hĩờng

vê sựliênquan tiếp tụccủa chủng dựahên các số ước lượngtài nguyên cậpnhậtconngười, thương lượnghợp đồngvớinhàthầu phụ và nhà cung cấp, và V V Ví dụ, một phần của dựán, kế hoạch sè được thựchiệu bời một nhóm phát hiểunội bộ,cần phảiđượcthực hiện bời một nhà thầuphụ, do độ chưasẵn sàngcủa đội Một sự thayđổicủabàu chất này thường đirợc tham gia vàomột ngân sách bổ siuig đáng kể

2.2.3 Các thành phần của kế hoạch chat lượng

Tất cà hay một sổ mục sau đây, tùy thuộc vào các dự án, bao gồm các thành phần củamột kế hoạch quản lýchất lượngdựán :

(1) Những mục tiêu của quản lý chất lượng

Thuật ngìr “quality goals” dùng để chi các yêu cầu chất lượng thực chất cùa việc pháthiển hệ thống phần mềm Đơn vị định lượng được ưa thích hơn so với các đơn vị định tính khi lựa chọn mục tiêu chất lượng, bời chúng cung cấp cho nhà phát hiền các đánhgiá khách quan hơn về hiệu suất phầu mềm trong c.iOt quá trinh pháttriển tiếu trinh vàkiểm thừ hệthống Tuy nhiên, không chì có mô+ k ' mục tiêu thích ứng với tất cả Cácthểthaythế chất lượng với đơn vị định hrợnp: di'ợc mil họa trongvídụ sau đây

Vi dụ

Một hệ thống phần mềmphục v> ?ccông việt phòng của mộtnhà máy săn xuấtđiện được phát triểu.Hệ thổi g trợ _ 'úp công việc văn phòng ( HDS - Help desksystem) được dự địnhhc,.t g 100 gij 'Si tuần Đội quản lý chấthrợugphần mềm được yêu cầu chuẩn ự -ước danh sách các mục tiêu chất lượng định lượng phùhọpvới nhìmg yêu cầu che ’ươngnhấtđịnh, như thểhiện trong bàng sau

HDS qualitative

requirements (yêu cầu

chất lượng)

Các mục tiêu định lượng chất lượng liên quan

HDS: thân thiệu với

người sử dụng

Một thao tác mới trợgiúpcông việc vãn phòng có thể họcchi tiết theo một khóa học kéo dàiít hơn 8 giờ, và làm chủhoạt độngtrong ít hơn5 ngày làm việc

HDS: rất tin cậy HDS luôn sần sàng trên 99,5% (thời gian chết của HDS

không được quá 30 phút mỗi tuần)

HDS: hoạt động liêntục Thời gian phục hồi hệ thống không được quá 10 phút

trong trường hợp HDS bị lỗi

HDS: có hiệu quà cao Một thao tác HDS phải có khà năng xừ lý ít nhất 100 yêu

cầucủa khách hàng trong 8 giờ thayđồi

Nliừiig mục tiêu chấtlượng phảiphàn ánh nhùngtiêu chí chínhđược chấp nhận vàđược chi ra trongtài liệu yêu cầu của khách hàng( ví dụ các tài liệu RFP) Nhưvậy,những mục tiêuchấtlượng như là đơn vị các thành công cùa cácyêu cầu chấtlượngcủakháchhàng

(2) Ke hoạch đánh giá hoạt động

Kể hoạhquàn lý chất lượng phải cung cấp lột Qc h sáchđầyđủ tất cà các kế hoạchđánh giá hoạt động:đánh giá thiết kế (P 'Ign Reviev -DRs), kiểmtra thiết kể,kiểm tra mà (code) , vớinhững xác địnhS ’ chó '*ug hoạtđọng :

• Phạm vi đánh giá hoạt dọi

• Các loại hìnhđánh giá 1'oạtđọ

• Lập lịch đánh g;d 110 động ( L ợc định nghía bởi độ ưu tiên và các hoạtđộng thành công 'ra ti'htrình dựán)

• Đơn vị, hệ thốngtíchhợp hay hoàn chinhđềkiểmtra

• Các loại hình cùa hoạt động kiềm thừ sè đtrợc thực hiện, bao gồm các đậcđiểm kỳ thuậtcùa các lầnkiềmthửphầnmềmtrênmáy tính được ápdụng

• Lịch lịch cho kế hoạch kiểm thừ ( được định nghĩa bời thứ tự im tiên của nó

và nhùng hoạtđộng thành công của tiến hình dự án)

• Các thủtục cụ thể được áp dụng

• Ai chịu háchnhiệmthực hiện kiểm tra

(4) Ke hoạch kiêm thử sự chấp nhận cho phần mềm phát triển bên ngoài

Một danh sách đầy đủ của kế hoạch kiểm thử sự chấp nhậu cho phầnmềm phát triểnbên ngoài phâiđược ciuig cấp trong kể hoạch quăn lý chấthrợngbao gồm cácmục :(a) Phầnmềmđượcmua

(b) Phầnmềmđượcpháttriểnbời các nhà thầuphụ

Các thành phần của quản lý chất lượr phần mền.

1 Danh sách các mục tiêucbn lượng

2 Đánh giá các hoạt đônọ

3 Kiểmthừphầnu 'U

4 Kiềmthừsự chấp nhận hàn mềm phát triển bêu ngoài

5 Các công cụvà thủtrie quàn lý cấu hình

* Tài liệu quản lý chất lượng, sự phê duyệt và định dạng của nó

Quăn lý chất lượng có thể được chuẩn bị như một phần của kế hoạch phát triềnhay như một tài liệu độc lập Trong một số trường hợp, kế hoạch được chia thành một số tài liệu bời hạng mục , như kếhoạchDR, kế hoạchkiểm thử, và kế hoạch kiểmtra sự chấp nhậuphần mềmphát triển bên ngoài Đánh giá và chấpthuận củakế hoạch quân lý chấtlượngnên được tiếu hành theo thùtục chuẩncủa tổ chức cho các kế hoạch nhir vậy

2.2.4 Các kế hoạch phát triên và kế hoạch chất lượng cho các dự án nhỏ

và các dự án nội bộ

Việc các nhà lành đạo dự án cố gắng tránh khỏi những “rắc rối”trong qná trình chuẩnbị

kể hoạch phát triển và quàn lý chất hrợng là điều tụ nhiên Điều này phản ánh xu hướng tránh việc “làm việc quan liêu” và kiềmsoát chung chung mà khách hàng có thể dự tính thựchiện Xu hướng này đặc biệt thường thấy trong2 trường hợp : các dự án nhó và các

dự ánnội bộ Sự chuẩn bị kế hoạch cho các dự án như vậy sè đượcthào hiận trong 2 phần sau

- Ke hoạch phát triên và quản lý chất lượng cho các dự án nhỏ

■ một dự án chi có thời hạn 40 ngày, có thể được thực hiện bởi một chuyên gia vàhoàn thành trong 12 tuần, với 1 man-days có phâi chuẩn bị lập kể hoạch quăn lýchất lượng vàphát triển toàn thể ?

■ một dự án được thực hiện bởi 3 chuyên gia vỡ' tống vốn là 30 man-days và hoànthành trong 5 mần, đòihòiphái lập kế hoạch lOàu thể?

Cầu làm rò ràngcác thùtục lập kế hoạch qua ’ýchất lượngvà phát triểnáp dụng cho các dự án lớn có thể sẽ không ár dỊũig đưọ 'ho các dự án nhò Các thừ ựicđặc biệt là cầnthiết Các thủ tục rày X địnhcách xái quyết các dự án nhưtrongcáccân hòi trên vớiviệc chú ’jngtới các ’ hoạch :

(1) trường hợpkhông cầu1'.pK ’mạch quàn ychất lượng và phát triển Ví dụ các

dự ánđòi hỏi khoản? 1J man-c ’S

(2) trường hợp việc _nuẩn ị cáckế 11 ạch phụ thưộc vào quyết định của lành đạo

dự án Ví dụ : m dự ùnđòi hỏi dưới 50 man-days mà không có rủi ro quan họng đà được xác Qx ■' Trong hườnghợp này có thể qưyếtđịnh rằng việc lập

kế hoạch là không cằn xiềt Một ví dụ khác : một dự án nhỏ nhưng phức tạpcầu được hoàn thành trong 30 ngày, trong đó sè có một liiuli phạt nghiêm trọng khi không hoàn thành đúng thời gian Trong trường hợp này, lập kếhoạch là cần thiết để đối phó VỚI những khó khăncủa dựán

(3) Trường hợpviệc lập kế hoạch phát triểnvà qưânlý chấtlượng làbắt bưộc

• Ke hoạch phát triển :

■ Các sản phẩm dự án,chi ra“sự phân phối”

■ Các điểmchuẩn của dự án

■ Các lùi rotrongviệc phát triển

■ Ước lượnggiá thànhdựán

• Ke hoạch quản lý chất lượng :

■ Mục tiêu chất hrợngMột số lợi ích cùa các dự ánnhó được lập kếhoạch so với các dự án khôngđược lập kế hoạchcó thểđượcxác định, thậmchí cho các kế hoạch“sưygiảm”:

(1) Sự hiển biết đầy đũvà triệtđể hơn các nhiệm vụ để cóthểhoànthànhchúng(2) Trách nhiệmlớn hơn có thểđược phân công

(3) Dề dàng hơn cho người quàn lývà khách hàng trong việc chia sé quyền kiềm soátdự án vàsớm phát lúệnra các sựchậmtrễ không mong muốn

(4) Hiểubiếttốthơn về các yêu cầu và thời gian biểu được đặt ra giừa ngườipháthiềnvà khách hàng

- Ke hoạch phát triển và quản lý chất lượng đối vói các dự án nội bộ

Các dự án nội bộ là các dự án dự định dành cho các bộ phận khác trong tổ chứchoặc cho toàn bộ tồ chức, hoặc dùng các dự án này trong việc phát triển các gói phần mềm cho thị trường phần mềm Nhìn chung, tất cã các dự án loại này sè không có sự tham gia của các khách hàng bênngoài trong việc phát hiền dự án Các dự án nội bộ có quy mô vừa hoặc lớn Tuy nhiên, ngay cà trong trường hợp này cùng có xu hướng tránh việc chuẩn bịcác kếhoạch phát triển và quàn lý chất hrợug một cáchđầy đủ Ví dụ sau minh họa hậu quà tiêu cực của mộtdự án nộibộ khôrế dược lập kế hoạch :

Bộ phậntiếp thị cùa công ty Toyware, rọt c <ĩty sàn xuất hò chơi vi tinh mới,

đà có kế hoạch tung ra thị hường “Super - Monster 20(a - tròchơi vi tính mới cùa công

ty - trong mùa Giáng sinh sắp tới Bộ phán p ' triển phầr mềm cho rằngviệc xây dựng

hò chơi nên được bắt đầu ngay lập ti« để hoàn I Tih dự ánđúng thời gian Do đó, việcchuẩn bị mộtbuổi thào luận giừa ’ọp '1 tiếp thị V oộ phận phát triển; và các kế hoạchphát triển và quàn lý chất hrợnp Hrôugđtự xem làcầnthiết Bộ phận phát triển ước tính ngân sách khoảng 240 oop£và V i được CL 8ỳển giao Theo lịch tiếp thị, kiểm thử hệthống phải được hoàn thám, •’rớ', 1 tháng 10 đề bộ phận tiếp thị thực hiện các yêu cầuxúc tiến và quàng cáo chiến dịj Tongmùa bán hàng của dịp Giáng sinh Khi dự án tiếntriển, nó có thểcó một sự chậm tix Vào cuối tháng 6, người ta nhận ra 3 tháng chậm trề

là không thề tránh khỏi Các hoạt động quảng cáo diễn ra trước 30.6 trở thành vô nghía.Cuối cùng, dự ánhoán thànhvào cuối tháng 2 Giá thành cùa dự án vượtđáng kể - thực

tể chi phí vượt quá385 000$ -nhưng thiệt hại lớn nhất là công tymất cơ hộikhai thác thịtrường mùa Giáng sinh Tuần tiước, quàn lý công tyquyểt định sètránh tất cà các dự ánnội bộ phát triển tròchơi vi tính trong tươnglai

Ví dụ này cho thấy rò rànglà việc chuẩnbị các kế hoạch phát triển và quàn lý chắt lượng toàn bộ cho cácdự ánnội bộ - kề cà việc giámsát thường xưyẻu - có thể rất có lợi cho việc thực hiện các dự án nội bộ

Bộ phận phát triển phần mềm có thể đạt được những thuận lợi sau đây với việc chuẩn bị kế hoạch :

(1) Tránh vượt quá ngân sách Điều này có tầm quan trọng đặc biệt trong việc đàm bão lợi nhuận

(2) Tránh thiệt hại cho các dự áu khác do các chuyên gia tham gia vào dự án nội

bộ bị chậm trề nên chưa thể tham giavào dự án khác

(3) Tránh trường hợp mất thị trường, đặc biệt liên quanđến danh tiếng cùa công

ty, do các dự án nội bộ chậm trề kéo theo các dựán bên ngoài phụ thưộc vào

nócũng bị trề

Khách hàng nộibộ có thể có nhưng thuận lợi sau :

(1) ít trề hon và ngân sáchítbị vượt qưá hơn

(2) Kiểm soát tốt hơn quá trình phát triển, trongđỏ có việc xác đụih sự chậm trềsớm hơn, hr đó cóthể tìm cách giài quyết nguyên nhân của chúng

(3) ít thiệt hại chậm trề nội bộ hơn

Tồ chức có thềcó nhừng lợi ích sau:

(1) Giãm rủi romất thị hường do sàn phẩm bị trễ

(2) Giảmrủi ro bị kiện do hoàn thành các SP.X phẩm bị muộn, vì thế, giảm thiệthại vì vi phạm hợp đồng

(3) Giãm nguy cơ danh tiếng của công t_ bịàn 'nrờng

Giảm rủi ro phải bổ sung ngân sách