Kĩ nghệ phần mềm cách tiếp cận của người thực hành tập 3

SQA bao gồm I các phưcaig pháp phân tích, ửiiết kế, mã hoá và kiểm thử, 2 các cuộc họp kĩ thuật chính thức được áp dụng trong mỉÀ bước kĩ nghệ phần niềm; 3 chiến lược kiểm ủiử nhiẻũ bôn

SOFTWARE ENGINEERING

LỜI GIỚI THIỆU•

Quyển sách kĩ nghệ phẩn mềm, cách tiếp cận của người thực hành” của tiến sĩ Roger s Pressman đã được tái bản lần thứ ba vào năm 1992 So với lần xuất bản đẩu (1982), sách lần ưíi bản sau cùng

đậ được hiêu chỉnh bổ sung nhiều kiến thức mới, hiên đại của lĩnh vực kĩ nghệ phần mém

Nội dung của sách khá phong phú, khá hoàn chỉnh, bao quát hầu hết các vấh để chính yếu của lã nghệ phần mẻm

Tiến sĩ Pressman không nhũng là một nhà khoa học tôn tuổi

có uy tín về các phương pháp, công cụ Id nghệ phần mếm mà còn là

một nhà sư phạm đạn dày kinh nghiệm Các nội dung đã được tác giả

trình bày một cách hê thống, có tính khoa học và sư phạm cao

Ghính vì lẽ đó, sách có thể phục vụ thích hợp sát tìiục đông đảo bạn đọc Đây là một tài liệu quý, giúp các giáo viôn Đại học có thể tham khảo để bi<ỗn soạn các giáo trinh giảng dạy một loạt các chuyên đề bậc Đại hiọc và sau Đại học về kỉ nghệ phần mểm Sinh viên, học viên cao h(ọc, các chuyên gia phát triển phần mềm có thể tìm thấy trong sách nứũẻu kiến thức cơ bản, chuẩn mực giúp họ nắm vững các nội dung đang được giảng dạy tại các trường Đại học Các câu hỏi cuổi mỗi chiFcfng được soạn khá công phu, giúp người đọc tự kiểm tra kiến thức của mình và qua đó giúp họ hệ UiCằig hoá một cách toàn diện, củng cố và nâng cao hiểu biết sâụ sắc hơn vẻ kĩ nghệ phần mềm

Hiện nay sô' lượng giáo trình có chất lượng cao phục vụ sát

thực chuyên ngành c<^g nghệ thông tin tại các tritóíng Đại học còn rất hiếm hoi Bản dịch là lĩiột đóng góp có giá trị góp phần vào sự

nghiệp đào tạo cán bổ Công nghê thông tin

Xin đuợc giới thiệu với đông đảo bạn đọc

HỒ Sĩ ĐÀM KHOA CÔNG NGHỆ THÔNG TIN ĐẠI HỌC QUỐC GIA HÀ NỘI

;<1 mghI phXm mImi

Cách tiếp cận của người thực hành

Tác giả: Tiến sĩ Roger s Pressman

Nhà xuất bẳn: McGraw-Hill, Inc

Xuất bản lẩn thứ 3 có sửa chữa và bổ sung; 1982,1987,1992

"Roger Pressman đã viết một cuốn sách hướng dẫn gọn gàng cho ỉĩnh vực lã nghệ phẩn mềm cho cả sinh viên CNTT lẫn người làm phẩn mềm và các nhà quản lí hành nghề CNTT hay cẩn tới việc thực hành CNTT."

Phần raểm IEEE

"Đây là cuốn sách giáo khoa hiện đại cổ điển, rõ ràng và có thẩm quyền về k ĩ nghệ phần mềm, với rất nhiều tranh vẽ, câu hỏi và tài liệu tham khảo Tôi xin giới ihiệu nó cho bất kì ai muốn hỏi Kĩ nghệ phần mềm là gì và bây giờ nó đang ỏ đâu?"

ACM Computing Reviews

"Một biên bản mới nhất, một xử lí sâu sắc về tiến t ìn h kĩ nghệ phần mém."

Byte Book Club

LỜI TÁC GIÀ

Trong hai thập kỉ qua, kĩ ngliệ phán mểm dã di tổi một ki nguyân mới Ngày nay người ta thừa Iihận nố là một bộ môn hợp f ^ p , một iĩnh vực nghiẽn cÃi xứng dáng, một khảo cứu cố ý ưiúc và một sự trành luận sổi nổi Trong loàn bộ ngành công nghiệp, "kĩ sư phẩQ tnẻm" dâ thay thế cho "ngưỉri

lạp ưình" xem như một tên gọi c ^ g việc Cắc phương pháp, ửiù tục và côag

cụ kỉ nghệ phần mểm đã dược chấp nhận thành công qua Tấi nhiểu loại úng dụng công nghiệp Các nhà quản lí và ngxẩn hành nghé CNTT déu nhận ra

nhu cầu vẻ một cách tiếp cận có kỉ luật hơn tới việc phát ư ỉ ^ phẩn mẻm.Nhưng các vâh dổ dược thảo luận &x>ng các lẩn xuất bản úỉứ nhất thứ hai của sắch này vẫn còn lại với chứng ta Nhiéu cá nhân và cốag ti vẫn còn phát ưiển ỊÌìin mém một cách tuỳ tiện Nhiéu,nhà chuyôn môn vk sinh

viên vẫn chua biết tói các phươtỉg {dỉáp hỉệB đại Và kết quả là chất ỉượng p h ^ mém chúng ta sản xuất ra bị ảnh hiiốag Bên cạnh dó, ưanh luận

và tbko luận sôi nổi vé bản chấỉ thực của cách úếp cận Iđ nghệ phần mẻm

vẫn tiếp tục Mạt khác, trạng thái của kĩ nghệ phần mém văn dang được nghiôncứu

Lần xuất bản tìiứ ba của cuốn Kĩ nghệ phán mềm : Cách tiếp cận của người thực hành giổng như hai lẩn dầu dự định dành cho cả sùỉh viên lăn

những người hành nghổ CNTT và vẫn duy ừì định dạng còng phong cách

như các Ĩẩn trưổc Quy>ển sách vẫn còn duy ưì như một cŨỐn sách hướng dẫn

cho cắc nhà chuyên in^n công nghiêp và sách nhập môn nâng cao cho sinh viên các nâm cuối bậc đại học và nâm đầu bậc cao học

Giống lứiư các lầĩa xuâì bảii tnRÍc, các phương pháp Id nghệ phẩn mém được trình hhy Uieo trìah tự thời gian chúng được áp dụng trong khi phát triển phầii mém Tuy Iihiên lẩn xuất bản ửỉứ ba này còn láttn ohiéu điéu hơú

ch! là việc cập nhật đcm giản Quyển sắch đã duợc tái cấu ưúc lại áé ưiích vói sự phát triển vuợt bâc ưong lĩnh vực này và dể tửìấn mạnh vào những

phương pháp và cồng cụ kĩ nghê phán tnẻm quan ưọng Thay vì duy tiì một quad diéni vòng dời chật chẽ, lẩn xuấỉ bản này tiinh bày các hoạt d^ig tổòg quát dã dược thục hiệii bất kể tới khu^ cảidỉ iđ D^iệ phần mém dã dược chọn

Các chương vản còn dược giữ lại như các lần xuát bản tniớc thì cũng dược duyệt xét lại và cập nhật dể phản ánh khu30ih huóng và kĩ tíiuật hiộn

thời Nliiều mục mới chủ chổi đã được thôin vào cho các chươttg vể kí ngliộ

hệ tlĩống máy lính, cơ bản về phâii tích yêu cầu, thiết kế hướng dòng dữ liệu, thiết k ế hướiig sự ViỊi, thiết kế thời giaii ihực, đảm bảo clìấl lượng phầii inểin,

kĩ llìuậl kiểm ihử phần ĩĩiẻm và bảo trì Bốn cạnlì Iiliữiig cải biên này, láiii chươiig mới đã dược thêm vào cho lần xuất bản ihứ ba

ơiưcnig Iiguyôn gốc ban dầu về quản lí dự án phầii mềin đã được bỏ đi

và tliay thế bởi ba chươiig mới vể cách đo, ưóc lượng và lập kê ỉioạch dự án

phẩn mềm Một chương mới vể phân tích có cấu Iníc trình bày các kí pháp

và cách liếp cậii tới cả lAOng ứíig dụng qui uớc ỉẫn thời gian thực Chưmig

về phâii tích hướng sự vậi và mô hình hoá áữ liệu nêu ra cách xử lí chi liếí

cho các kĩ thuật mô liình hoá mới và quaii trọng uày

^ Nâm chương hiệu có vé ihiết kê' phần mềm đã được tang cuờng thêm với một chuơQg mới vể thiết kế giao diện người dùng Quản lí cấu hình phẩiì mểm - một chủ dể dã trờ thành then chốt cho viêc phái triển phẩn mẻm thành công - bây giờ dược xử lí Uong một chương tách biệt Vai trò của tự dộng hoá trong kĩ nghệ phẩn mém dược xem xét ưong hai chương mói vể kĩ nghệ phán 0iểtn cổ máy tính trợ giúp (CA^) Một chương nhấn mạnh vào công cụ phẩn mẻm và ứng dụng của chúng còn chương kia thảo luậxi vé các môi tniờng và kho CASE lích hợp Chương cuối (cũng mới) nhìn hướng tới thế kỉ ưiứ hai mươi mốt và xem xét ỉại những thay dổi sẽ ảnh hưỏng tói cách tiếp cận của chúng ta tới iđ nghệ phẩn mềm

Nhiẻu thí dụ, vấii dể và điểm cẩn dào sâu mới dã dược bổ sung vào và mục “Đọc thêm” dã được mở rộng và cập nhật cho mọi chương

Cuốn sách gồm 24 chưcSỉg cho lẩn xuất bản thú ba này, được chia thành nãm phẩn Điẻu này dược thực hiện dể gối gọn các chủ dể và ượ giúp

cho giảng viên, những người không có đủ thòi gian dạy cả cuốn sách troug một học Id Hiần I - F1iần mẻm - Tiến trình và việc quản lí nó" ưình bày

một bàn luận Uỉấu dáo vé các y/ấn để quản lí dự án phẩn mém Phẩn ỉĩ -

"F1iân tích bệ thổng và các yêu cầu phần mểm" - bao gổm nãm chưcmg bao quát các vâh dé cơ bản của phân tích và các phương pháp inô lùnh hoá yêu cầu và kí pháp Phần in - 'Thiết kế và cài đạt phần mểm" - ưình bày mội bàn luận sâu sác vể thiết kế phẩn mẻm, nhấh mạiứi tới các định mức thiết kế

cơ bản dẫiỉ tớỉ hệ tíiống chất lượng cao và các phương pháp thiết kế dể dịch một mô hình phân tích ứiành giải pháp pháiỉ mểm Phần IV - "Đảin bảo,

kiểm chứng và duy trì từứi icần vẹn phân mém" - nh ^ niạnh vào các lioạt

động được úng dụiig dể đảm bảo chăt Itíợng ưong suốt tiẽh trình Id nghệ phần tném Phẩn V - "Vai trò của tự động hoá" - ứiảo luận vẻ tác động của

CASE (Id nghẹ phần mém với máy tửih hỗ trợ) lên ú€a trình phát tríển phần

mểm

Việc tổ chúc Uieo năm phần của lán xu* bản ứìứ ba nàygiứp cho giảng viên chùm" các chủ dẻ dựa trôn ứiời gian giảng dạy và nhu cẩu của

siiứi vién Có ttó xây dựiìg một giáo trình toàn bộ cho một học phần xung quanh một hay nhiéu phẩn trong năin phần này Chảng hạn, **giáo trìỉih thiết kế" có thể nhối mạnh riêng vào phần III; “giáo trình phương pháp*' có thể trìiứi bày các chương đưcK’ tuyển lựa từ các phẩn n, III, IV và V; còn “giáo trìiih quản If’ sẽ nliấii mạnh vào các phẩii I và rv Bàiig cách lổ chúc lẩn

xuát bảỉi úìó ba theo cách tiày, tôi có ý định cung cấp cho các giảiig viẽn một

sô' phương án ỉựã chọn giảng (lạy.

Sách Hướng dẩn gidĩtíị viên cho lần xuất bảỉi thứ ba của cuốn Kĩ nghệ phán mềm : Cách tiếp cận ctta người thực Ịìành cũng dã có do nhà xuất bản MxGraw-HiIl cung cấp Sách Hướng dần gidng viên trình bày các gợi ý đé

thực hiện nhiểu kiểu giáo trình kĩ nghệ phần ir^m, hưóng dẫn nhiểu khuyến cáo cho các dự án phẩn inểin có liêu quan tổi một giáo trình, tiinb bày các giải pháp cho vấn dé dược tuyển lựa và các nguồn tham khảo tới cắc tài liệu giảng dậy bổ siing^ dể tạo irên một "hệ thống'' cho việc giảng dạy id nghê phẩn mểm

Van dàn lả nghê phẩn mểm vẫn tiếp tục rộng mở với một tỉ lệ bùng nổ

Một lẩn nũa, i(À xin cắm ơn nhiểu tác giả sắcb« bắo, tạp chí, nhũĩìg ngưỉri dã

cung cấp cho cắi nhìn sáng suốt, các ý iMỜag mới và những bình ỉuận trong suốt thập kỉ qua Nhiểu nguời dã dược ũ&u trích dẫn trong cắc chương

sách Tất cả dểu có công do sự dóng góp của họ vào lĩnh vục tiến ưiển nhanh chỏng này Tôi cũng muốn cám ơn nhữi^ người dã đọc duyệt lại cho lẩn

xuất bản ửíứ ba, James Cross, Đại học Auburn; Mahesh Dodavỉ, đại học

Iowa; William s Junk, Đại học Idaho; và Laurie Werth, Đại học Texas Những đống gốp và phô bình của họ là vổ giá

Nội dung của I&I xuất bảii thứ ba này của cuốn Kĩ nghệ phần mềm : Cách tiếp cận cùa ngiười thực ỉìành đã được làm sác nét thêm bỏi hàng tram

nhà chuyên mồn công nghiệp, giáo sư đại học và sinh viôn, những ngưỉri dã dùng nhữug lần xuất hản thứ nhất và thứ hai của cuốn sách này và dã bỏ thM gian để trao dổi các gợi ỷ, phê bình và ý tưỏDg của họ Đôn cạnh dó tổi cũng xin cám ơn riêng với nhiều khách hàng công nghâip tiong toàn Bấc NG và

Châu Âu, lứiững người chác chán đã dạy cho tồi lihỉểu hơn những ^ tôi có

thể dạy cho họ

Cuối cùng, tôi xin cám ƠĨI Barbara, Mathew và Michael vì đẩ dung thớ cho lịch biểu du hành của tôi, dã hiểu biết vể nhiĩng ỉàm việc tại van phòng và vảii cồn tiếp tục cổ vũ lồi cho việc xuất bản tiếp vổ “cuốn sách này"

Roger s Pressman

ĐẢM BẢO, KIỂM CHÚNG VÀ

BẢO TRÌ TÍNH TOÀN VẸN

PHẦN MỀM

chííi ư! Đảm bào chất lượng phẩn mềm (SQA) là ràột “hoạt đỌng che ô” được áp dụng trong toàn bộ tiến trình Id nghệ phần mềm SQA bao gồm (I) các phưcaig pháp phân tích, ửiiết kế, mã hoá và kiểm thử, (2)

các cuộc họp kĩ thuật chính thức được áp dụng trong mỉÀ bước kĩ

nghệ phần niềm; (3) chiến lược kiểm ủiử nhiẻũ bôn; (4) kiểm soát tư liệu phần mém và những thay đổi thực hiện trên đó; (5) thủ tục đảm bảo tuân thù với các chuẩn phát triển phần mểm (khi áp dụng đuợc);

và (6) các cơ chế đo đạc và báo cáo

Trong chưimg này, chúng ta sẽ xem xét ý nghĩa của ứiuật ngữ hay bị lảng tránh “chất ỉu ạig phần mềm,” và thảo luận vẻ các thủ tục

và biện pháp giúp đảm bảo rằng chất lượng ià kết quả tự nhiân của Iđ nghẹ phẩn mỗn

17.1 CHẤT LƯƠNG PHẨN MỂM VẢ VIẺC ĐẢM BẢO CHẤT LƯƠNG PHẨN MỂM

Ngay cả người phát triển phẩn mềm chán ngán nhất cũng sẽ đổng ý rằng phẫn tnểm chất lượng cao là một mục tiêu quan trọng Nhưng làm sao chúng ta định nghĩa được chất lượng? Mội người khôi hài có lần đã nói, “Mọi chương trình đều làm đúng một cái gì đó , nhưng cố thể lại không phải là cái mà ta muốn làm ra đố thõi.”

Đã có nhiẻu định nghĩa vẻ chất lưạig phần mềm được đề nghị trong văn đàn Với mục tiêu của chúng ta, chất lượng phần mềm được định nghĩa như sau:

Việc tuân ưiủ các yêu cầu chức năỉig và sự hoàu thiện dã dược phát biểu tưòng tninb, các chuẩn phát triển dã duạc tư liệu hoá tường minh, và cắc dậc tnmg khổng tưỈHỉg minh được trổng dợi từ tít cả các phẩn mểm dã dược phắt triển theo cắch chuyỗn nghiệp

Có câu hỏi nhỏ rằng định nghĩa trôn có thể được sửa đổi hay mở r(tog thêm không Trong thực tế, một định nghĩa quả quyết vé chất lưcng phẩn mẻm có thể phải tranh luận vô tận Với mục đích của cuốn sách này, định nghĩa trên phục vụ để nhấh mạnh ba điểm quan trọng:

1 Các yẽu cầu phần mểm là nẻn tảng để từ đố tiến hành đo đạc

chất lượng Việc thiếu tuân thủ các yẽu cầu này là thié^ chất

lượng

2 Các chuẩn đặc biệt xác định ra một tập các tiều chuẩn phát triển

hướng dẫn cách thức phần mểm được sản xuất tíieo cổng nghệ Nếu những tiêu chuẩn này không được tuân theo thì kết quả gần như chắc chắn là thiếu chất lưcng

3 Có một tập các yêu cấu không tường minh thường không được để

ý tới (như mong muốn bảo trì tốt) Nếu phần mém tuân thủ các yêu cầu tường minh nhung lại không đáp ứng các yêu cẩu không tuờng minh thì chất lượng Ịrfiần mém vẫn còn có phần đáng ngờ

ơ iấ t ỉượng phẩn mểm là một sự trộn lẫn phúc tạp các nhãn tố sẽ thay đổi qua nhũng úng dụng và khách hàng khác nhau, nhũng người yêu cẩu chúng Trong các mục sau đây, các nhân tố chất lượng phần mểm sẽ đuợc xác định và các hoạt động con người cẩn thiết để đạt tới chúng sẽ được mô tả r5

Ỉ7.1.1 Các nhàn tố chất lượng phán mém

Các nhân tô' ảnh hưởng tới chất lượng phần mểm có thể được phân loại thành hai nhóm chính: ( 1) các nhân tố có thổ trực tiếp đo (như lỗi/ KLOC/ đơn vị thời gian) và (2) các nhân tố chỉ có thể đo đưcK một cách gián tiếp (như tính sử dụng hay tính bảo trì) Trong

mỗi trường h(^ đếu phải có cách đo ơ iúng ta phải so sánh phần mềm (tài liệu, chưcmg trình và dữ liệu) với một cái mổc nào đó và đi

tới một chỉ dẫn vé chất lượng

McCall và đồng nghiệp của mình đã đẻ nghị một phân loại hữu

ích vể các nhân tố ảnh huởng tới chất ỉượng phần mém Các nhân tố chất lượng phán tnềm này, được vẽ trong Hình 17.1, hội tụ vào ba

khía cạnh quan trọng của sản phẩm phẩn mẻm : các đặc trung vận hành của nó, khả năng của nó trải qua thay đổi và tính thích nghi của

nó với môi trường mới

Tham khảo tới các nhân tố được viết trong Hình 17.1, McCall đưa ra những mô tả sau đây:

Tính đúng đắn Pliạm vi mà trong đó chương trình thoả mãn đặc tả

của nó và thoả mản các mục đích công việc của khách hàng

Tính ùn cậy Phiam vi trong đó chương trình được tr<^g đợi tìiục

hiện chức năng d ự kiến của nó với độ chứứi xác được yêu cầu [Cũng nên lưu ý rằng các định nghĩa khác, đầy đủ hctti vể độ tín cậy đã được đẻ nịẹhỊ (xem Mục 17.6).]

Tinh hiệu quà Khối lượng tài nguyên tính toán và mã chương

trình cần tới để thực hiện chức năng của nó

Tính toàn vẹn Phạm vi trong đó việc thâm nhập vào phần mẻm

hay dữ liệu của những người không có quyền có thể được kiảĩi

so ái.

Tính sử dụng dược Nỗ lực cần có để học, vận hành, chuẩn bị cái

vào, và hiểu cái ra của chương trĩnh

Tính bào trì đượí' Nỗ lực cẩn có để định vị và ẩh (finh lỗi trong

chuơng trình [Đây là một định nghĩa rất hạn chế (xem Chươrìg20).]

(Có tỉiế dùng lại một phẩn mém không?) Tửih Uỗn tác

(Cố ưiể giao tiếp vời hệ thống khác khâng?)

T ùihđiỉngdin (Nó c6 ÌẰm đ i ^ tối muốn kbOng?)

Tỉnh tin cẠy (Nố có hìồn cbạy đthig kbổng?)

hiệu qui (Liệu nó có chạy dược phần cứng của tồi không?) Itn h to in v ẹn (liỆu nó có an toàn không?)

Tính hOu dụng ( l i ^ cố phàl nó được thiét kế cho nguời dừag kbOng?)

Hình 17.1 Các nhân tố chất lượng của McCall

Tính mềm dẻo Nỗ iực cẩn cố để thay đổi một chương trình đang

vận hành.•

Tính ìdểm thử được Nỗ lục cần có để kiểm thử một chương trình

để đảm bảo rằng nố thục hiẽn đúng chúc năng dự định

Tính khả chuyểrt Nỗ lục cẩn có để truyén chương trình từ môi

ưuờng hộ thống phẩn cứng và/hoặc phẩn mém này sang môi ưuờng khác

Tính tái dụng Phạm vị trong đố một chuơng trình (hay bộ phạn

của chucmg trình) có thể được dùng iại ticmg các úng dụng khác -

có liẽn quan uM việc đống gối và phạm vi các chúc nãng chuông

= C/ X nil + X + + c„ X m„.

với /•', là nhân tố chất lượng phần mềm, c„ là hệ số hổi qui còn m„ là

độ đo tác động lên nhân tố chất lượng EHều không may là nhiều độ

đo được McCall định nghĩa thì chỉ được đo một cách chủ quan Các

độ đo có ữiể cho dirói dạng một đanh sách kiểm đuợc dùng để “xỂ^ hạng” các thuộc tính đặc biệt của phẩn mẻm Lược đồ xếp hạng do McOdl đề nghị là tíieo Uiang tỉ lệ tìlr 0 (thấp) tói lò (cao) Các độ đo sau đây đuợc dùng trong lược đổ xếp hạng:

Kiểm toán được Có thể kiém tra dễ dàng việc tuân thù các

chuẩn

Độ chính xác Độ chính xác của tính toán và điéu khiển.

Tính phổ biến liên lạc Mức độ sử dụng các giao diện, giao ứiức

và giải thông chuẩn

Tính đầy đủ Mức độ theo đó việc cài đạt đầy đủ cho chức năng

yêu cẩu đã được đạt tới

Tinh súc tích Đô gọn của chương trtnh duứi dạng số dòng mẵ Tinh nhất quán Việc dùng các Id thuật thiết kế và tư liệu thống

nhất trong toàn bộ chương trình

Phổ biến dữ liệu Việc đùng các cấu tróc và kiểu dữ liệu chuẩn

trong toàn bộ chương triinh

Dung lỗi Những hỏng hóc xuất hiện khi chương trình gặp phải

một lỗi được chấp nhận

Hiệu quả thực hiện Hiộu năng khi chạy của chương trinh.

Tính mà rộng được Mức độ theo đó ứũết kế kiến trúc, dữ liệu

hay thủ tục có thể đuợc mở rộng

Tính tổng quát Độ rộng rãi của ứng dụng tiềm năng của các

thành phần chương trình

Độc lập phơn cứỉìg Mức độ theo đó phần mểm tách biệt được

với phần cứng nó vận hành

Sử dụng máy móc Mức độ theo đó chương trình điéu phổi thao

tác của riêng nó và xác định các lỗi xuất hiện

Tính mô đun Sự độc lập chức năng (Chương 10) của các thành

Độc lập hệ thống phẩn mềm Mức độ theo đó chương trình đuợc

độc lập vổi các tính năng ngôn ngữ lập trình, các đăc trưng hệ điéu hành và những ràng buộc môi trường không chuẩn khác

Tính theo dõi được Khả năng theo dõi dấu vết của một biểu diễn

thiết kế hay tíiành phần chương ưình thực sự so với yêu cẩu

Huấn luyện Mức độ theo đó phần mềm trợ giúp làm cho người

dùng mới dùng được hệ tíiổng

Mốì quan hệ giữa các nhân tố chất lượng phần mém và các độ đo được liệt kê ở trẽn được vẽ trcaig Bảng 17.1 Cần phải lưu ý rầng trọng

số cho mỗi độ đo phụ thuộc vào sản phẩm và míS quan tâm cục bộ.Các nhân tố chất lượng được McCall và đổng nghiệp mô tả biểu thị cho một trong một số các “danh sách kiểm” đã được gợi ý cho chất iưạng phần mềm Hewlett-Packard đã phát triển một tập các nhân tố chất luọng phần mềm được viết tất là FURPS cho ưnh chức năng, tfnh sử dụng, ưnh tín cậy, hiệu năng và tfnh hỗ trợ Các nhân tố chất ỉư ^ g FURPS được rút ra tuỳ ý từ công trình trước đây, xác định các thuộc tính sau đây cho mỗi một trong năm nhân tố chính:

• Tính chức năng (Functionality) được thẩm định bằng cách ước

lượng tập tính năng và những khả năng của chương trình, títth tổng quát của các chức năng được bàn giao, và tfnh an toàn của toàn thể hộ thống.

Tinh dùng được (Usability) được thẩm định thông qua việc xem

xét nhân tô' con người (Chương 14), tính thẩm mĩ toàn phẩn, tính nhất quán và tư liệu

Tinh tin cậv (Reliability) được đánh giá bằng cách đo tần sổ và

độ nghiêm trọng của sai hỏng, độ chính xác cùa kết quả đưa ra, thời gian trung bình giữa các lần sai hỏng (MTBF), khả năng phục hổi sai hỏng, và khả năng đoán trước được của chương trình

Hiệu năng (Performance) được đo bằng cách đánh giá tốc độ xử

lí, thời gian đáp ứng, tiêu tốn tài nguyên, hiệu suất và hiệu quà

Các nhân tố chất luợng và các thuộc tính FURPS được mô tả ô trên có thể được dùng để thiết lập các độ đo chất lượng CỈK) từng bước trcng tiến trình kĩ nghệ phần mềm Grady và Caswell gọi ý mM ma trận (Hình 17.2) để hướng dẫn trong việc thu tíĩập các cách đo FỦRrè đơn giản

Điéu tra/ Đăc Thiết kế C^iđặt KiÃn thử Hỗ trợ tả

#Người dùng % Đạc tả % thiếl kế bao % tính #ftV> đích duyộl xét được bao hàiTì hàm trong mâ năng duợc cáo vẻ đặc tả hay bản trong thiết kế hoá kiểm thử vấnđé mẫu

# Tlìay đổi dặc tả do yôu

# người dùng % Unh nàng bị đuợc kiểm nguời dùng

thử theo

hoạt

Jà ^

z náng cạnh thay đổi nếu ngưõ^ dùng xét

khác

#giao diện

hàng đích alpha

u với sản phẩm

hiện cổ

dùngưỉngquan nguời dtog HPWn

tXOŨR

# nguời dùng % xếp hạng % xếp hạng # thay đổi #nguờỉ đích duyệt xéi ỉthiết kế khi so theo người sản phẩm dùng đặc tả hay bản ^sánh với mục dùng trong sau kiém hiểu

% xếp hạng ^ tíiay đổi tài nghiộin % xếp

u kế hoạch tài ìliệu sử dụng % xếp hạng hạng ứ ì c o

o*

% iiêu bởi người ỉbản máu sau theo tiếp thị tính sử

Q dùng đích íkhi xét duyệt sản phảìì, tài dụng từ

phồng thi nghiộm

% xếp hạng theo kí&n thử taichd

o

Q dưọc của bản mẫu gốc duyột xét mọi thay đổi

do có lôi

% xếp hạng

thiết kế khi so sánh vớí các lĩìuc đích

% mã thay đổi

do độ tin cậy đưọc phát hiện trong họp xét duyộl

% mă bị bao

phủ bởi các trường hợp kiểm thử

# khiếm khuyết / KNCSS trong

mổ dun kiểm thử

MTTF (MTBF)

% kiổm

thử số giờ tin cậy

# ktũếni khuyếự IK giờ

# khiếin khuyết toàn bộ

tỉ ỉệ khiếm khuyết Uiiổckhi dưa ra diểm kiểm tra

#Báo cáo vâh

đề dã biết

# khiếm khuyếỉ / KNCSS

mổ hình hoá

Kiểm thử hiệu nảng đạí duợc

% của dự kiến

dược mổ hình

đạt tới mục ti6u hoàn tíiiộn khi xem xét tới môi tmờng được Idểm thử

% mă đuợc

kiểm tíìừ với dãy hoàn thiện

cố mục đích (hê Ihống) (mô đun)

và hiện trường

# chẩn (It)án/

phục hổi những thay dổi bơi CPF

và cái vào hiện iruừng

M TTR mục đích (Ihời — gian)

M TrCrnục đích (thời gian) thời gian huấn luyộn Bộ kiểm thử, dùng tài liệu

Tưtmgtư

Hình 17.2 Các độ đo FURPS về chất lượng phần mềm

17.1.2 Đảm bảo chất lượng phán mém

Việc đảm bảo chất lượng là một hoạt động bản chất cho bất Iđ doanh nghiệp nào sân xuất ra sản phẩm cho người tiêu dùng Trước thế kỉ hai mươi, việc đảm bảo chất lượng là trách nhiệm duy nhất của người chế tạo, người xây dựng nên sản phẩm Việc đảm bảo chất lượng và chức nang kiổm soát được Bell Labs lần đầu tiên đưa vào năm 1916 và nhanh chóng lan rộng trong toàn ngành chế tạo trên thế giới Ngày nay, mọi cOng ti đểu có cơ chế đảm bảo chất lượng trong sản phẩm của mình Trong thực tế, các tuyên bố rõ ràng về mối quan tâm của công li đối với chất lượng đã trở ứiành một mánh khoé tiếp thị trong thập kỉ qua

Lịch sử của đảm bảo chất lượng trong phát triển phần mềm đi song song với lịch sử của chất lượng về chế tạo phần cứng Trong những ngày đầu của tin học (những năm 1950 và 1960), chất lutffig là trách nhiệm duy nhất của người lập trình Các chuẩn về đảm bảo chất lượng cho phần mềm đã được đưa vào ưong nhũng hợp đồng phát triển phần mẻm quân sự trtmg những năm 1970 và đã nhanh ch<^g lan rộng vào việc phát triển phẩn mềm trong thế giới thương mại

Đảm bảo chất lượng phần mểm (SQA) là một “mảu hình hành động có hệ thống và có kế hoạch”, điẻu hay được đòi hỏi để đảm bảo chất lượng trong phẩn mềm Phạm vi của trách nhiệm đảm bảo chất lượng có thể được đặc trưng tốt nhất bằng việc diễn giải một khẩu hiệu thương mại ô tô có thời rất phổ biến: “Chất lượng ià Công việc

số 1 Ngụ ý cho phần mềm là ở chỗ nhiều người khác nhau trong tổ chức có trách nhiệm đảm bảo chất lượng phần mềm - kĩ sư phần mềm, người quản ư dự án, khách hàng, người bán hàng, và những cá nhân phục vụ trong nhóm SQA

Nhóm SQA phục vụ như đại diện tại nhà cho khách hàng Tức là, những người thực hiện SQA phải nhìn vào phần mềm tíieo quan điểm của khách hàng Phần mềm cố đáp ứng thích hợp cho các nhân tố chất lượng đã nêu trtmg Mục 17.1.1 không? Việc phát triển phần mẻm cố được hướng dẫn theo các chuẩn đã thiết lãp tmớc ỉchổng? Các kỉ luật kĩ thuật có thực hiện đúng vai trò của chdng như một phẩn

của hoạt động SQA không? Nhóm SQA cố gắng trả lời cho những

câu hỏi này và câu hỏi khác để đảm bảo chất lư ^ g phần mểm được duy trì

17.L3 Các hoạt động SQA

Viộc đảm bảo chất lượng phần mém bao gổm nhiẻu nhiệm vụ liên kết với bẩy hoạt đtog chính: (1) áp dụng các phương pháp kĩ thuật, (2) tiến hành các cuộc xét duyệt la thuật chính thức, (3) laểm tíiử phần mềm, (4) buộc tôn trọng các chuẩn, (5) kiểm soát ữiay đổi, (6) đo, và (7) lưu giữ và báo cáo kết quả ghi lại

Oiất lượng phần mém được thiết kế bên trong sản phẩm hay hệ thống Nó không bị ép buộc theo sự kiện Bởi ư do này, SQA thực tế

bắt đầu với tập các phương pháp và công cụ k ĩ thuật để giúp cho

người phân tích đạt tới đăc tả chất lượng cao còn người thiết kế thì phát triển thiết kế chất lượng cao Việc đo chất lượng đặc tả và Uiiết

kế đã được ứiảo luận tới trong cuốn sách này (xem Chương 6 và 10)

Một khi đặc tả (hay bản mẫu) và thiết kế đã đuợc tạo ra, thì mỗi bản này phải được t h ^ định vể chất lưcng Hoạt động trung tâm đi

kèm với viẹc thẩm định chất lucng là cuộc họp xét duyệt Ẩã thuật chính thức xét duyệt Id ứiuật chính thức (FTO) là nici cuộc họp mang phong cách riông đxiợc nhốm kĩ thuật tiến hành với mục tiôu

duy nhất là phát hiện ra vấn để chất lượng Trong nhiẻu tình huống, các cuộc họp xét duy^ tỏ ra hiệu quả cũng như việc kiám thử để

hiộn ra khiếm khuyết trong phẩn mềm Các cuộc họp xét duyệt sẽ được thảo luận trong Mục 17.2

Kiểm thử phán mềm lổ hợp một chiến lược nhiếu bước với một

loạt các phương pháp thiết kế các tnxờng hcỊ) kiểm thử giúp đảm bảo phát hiện ra lỗi một cách có hiệu quả Nhiều nguời phát tnển phẩn mềm hay dùng việc kiểm thử phần mềm như “lưới an toàn” đảm bảo chất lượng Tức là, người phát triển giả thiết rằng phép kiểm thử toàn

bộ sẽ làm lộ ra hầu hết các lỗi, do đó làm nhẹ bớt nhu cầu về các hoạt động SQA khác Điẻu không may là kiểm thử, dù có được thực hiện rất tốt đi chăng nũfa, cũng không hiệu quả như ta trông đợi vẻ mọi lổp iỗi Việc kiểm thử phẩn mềm được thảo luận chi tiết trong Chương 18

và 19 ’

Mức độ tíieo đó các chuẩn và các thủ tục lứnh thúc đuợc áp

dụng cho tiến tiình kĩ nghệ phẩn mẻm thay đổi tuỳ theo công ti Trong nhiẻu ưuỉAig hợp chuẩn do khách hàng hay y£u cầu qui định chi phối Trong những hoàn cảnh khác chuẩn là việc tự áp đạt Nếũ các chuẩn chính thức (viết ra) có tồn tại thì một hoạt động SQA phải được thiết lập để đảm bảo rằng chúng được tuân theo Một thẩm định

vể sự tuân thủ chuẩn có thể đuợc nguời phát triển phần mềm tiến hành xem như một phần của cuộc họp kĩ thuật chứứi ÚIÚC hay, trong tình huống đòi hỏi có kiểm chứng độc lập vể sự tuân thủ thì nhóm

SQA có ứiể tiến hành việc kiểm toán riêng của mình.

Một mốĩ đe doạ chính đốì với chất luợng phần mềm phát ãn h từ

một nguồn có vẻ lành manh: Iiỉiữiig thay đổi Mọi thay đổi với phần

mềm đều mang tiồm năng đưa vào lỗi hay tạo ra hiệu quả phụ làm lan

tniyổn lc^i Tiến trình kiểm soát thav đổi (một hoạt đ ^ g là bộ phận

của viộc quàn lí cấu hình phần mềm, ChuPơng 21) đóng góp trực cho chất lượng phần mềm bàng cách hỉnh thúc hoá các yêu cầu thay đổi, ưóc lượng bản chất ứiay đổi, và kiểm soát tác động của thay đổi Kiểm soát thay đổi đuợc áp dụng trong khi phát triển phẩn mềm và sau đó, trong giai đoạn bảo trì phần mềm

Đo đạc là một hoạt động vốn thuộc vào bất kì bộ môn ỉđ ứiuật

nào Một mục đích quan trọng của SQA là theo dỗi chất luợng {^ần mẻm và thẩm định tác dụng cua những thay đổi phuong pháp iũẬn và thủ tục lên chất lượng phần mềm đã đuợc cải tiến Để hoáĩi thành điẻu

này, các độ đo phần mẻm phải được thu thập lại Độ đo phẩn mềm bao gồm một phạm vi rộng những cách đo hướng kĩ thuật và quản lí

và được thảo luận trong Mục 17.4

Liat giữ và ghi lại bàn ỵ/ii cho việc đảm bảo chất lượng phần

mềm đưa ra các thủ tục để thu thập và phát tán thông tin SQA Kết quả của các cuộc họp xét duyệt, kiểm tòán, kiểm soát thay đổi, kiểm thử và những hoạt động SQA khác phải trở thành một phần của bản ghi lịch sử cho một dự án và phải được phân phát cho nhóm phát triển trôn cơ sở điều-cần-phải- biết Chẳng hạn, kết quả của từng cuộc họp xét duyệt kĩ thuật chính thức đcs với thiết kế thủ tục đirợc ghi lại và

có thể được đạt vào “cặp giấy” có chứa tất cả các thông tin Iđ thuật và SQA vé một mô đun

Họp xét duyệt phần mềm là “bộ lọc” cho tiến tiình Id nghệ phần mềm Tức là cuộc họp xét duyệt được áp dụng tại nhiẻu điểm trong khi phát triển phần mém và phục vụ để phát hiện ra những khiếm khuyết và rổi có thể loại bỏ Họp xét duyệt phục vụ việc “thanh lọc” các hoạt động Id nghẹ phần mểm mà chúng ta gọi là phân tích, Uiiết

kế và mã hoá Freedman và Weinberg thảo luận vẻ nhu cầu cho các cuộc họp xét duyệt này theo cách sau:

Cônạ việc kĩ thuật cần tối viộc xét đuyột với cùng ỉí do như bút cìắ cần

cổ láy: Là con người thi pỊtíỉi phạm lỗi lầm Lí do tìiứ hai mà chúng la

cẩn tới các cuộc họp xét duyệt kĩ thuật là ở chỏ mạc dầu mọi ngiiỉri dều giỏi khi bắt một sô ỉỏi của clưnh mình, thì phẩn lÓQ lóp cắc lỏi ỉại thoát khỏi người sắng tạo còn dẻ dàng hơn ỉà ửioát khỏi bất Id ai khắc Tiến

tiiiứi xét duyệt, do vậy, \h viộc trả lời cho lèn cầu nguyên của Raber

Burns:

‘*ưóc gì một quyén nâng nằo dó cho chúiig ta

thấy dược bản thân mình như ngưòi khác thíy chứng ta/'

Họp xét duyệi - bất kì xét duyệt gì - cũng ỉầ cách dừng sự da dạng của nhóm nguởi đé:

ỉ Chi ra những cải tiến cần thiết trong sản phẩm của riêng một người hay nỊỘt nhótn;

2 Xắc nhận những phẩn của sản phẩm troDg dó việc cải tiến hoạc

không mong muốn lioạc không cần thiết;

3 Đạt tới công Irình kĩ thuật đều hơii, liay ít nhẫt cOng dẽ dự kiến

hơn, cliất lượng hơri là có thể được đạt tới mà không có xét duyệl, dể

làin cho công việc kĩ thuftt dễ sử dung hcm

Có nhiéu kiểu xél , duyệt khác nhau có thể được tiến hành như một phần của kĩ nghệ phần mềm Mỗi kiểu đều có vỊ trí của nó Cuộc họp không chính thức xung quanh quán nước cũng là một dạng của xét duyệt, nếu các vấh đề kĩ thuật được thảo luận tới Một tiinh bầy chính thức vế thiết kế phần mềm cho thính giả khách hàng, cấp quản

lí và các nhân viên kĩ thuật cũng là một dạng xét duyột Tuy nhiẽn, trong cuốn sách này, chúng ta tập trung vào các cuộc xét duyệt Id

thuật chính ửiức - đôi khi vẫn được gọi là walkthrough (thảo trình)

Một cuộc xét duyệt lã thuật chính thức là một bộ lọc có hiệu quả theo quan điểm đảm bảo chất lưcng EHrợc tiến hành bẻã các lã sư phẩn mềm (và nhOng nguời khác) cho các kĩ sư phần mềm, FTR là một phương tiện có hiệu quả để tăng cường chất luợng phẩn mểm

17.2.Ỉ Tác động chi phí của khiếm khuyết phần mềm

Lợi ích hiển nhiên của các cuộc họp xét duyệt Id ứiuật chính

Uiức là việc phát hiện sớm những khiếm khuyết phần mềm để cho

từng khiếm khuyết một cố thể được sửa đổi tniớc khi thục hiện bước tiếp trong tiến trình lã nghệ phần mềm Oiảng hạn, một số nghiên cứu công nghiệp chỉ ra rằng các hoạt động thiết kế đua vào ticmg khoảng 50 đến 65 phần trăm tất cả các lỗi (khiếm khuyết) trong giai đoạn phát triển của tiến trình kĩ nghệ phần mém Túy nhiôn các Id thuật họp xét duyệt chúih thức đã cíu ra đến 75 phần trám hiệu quả về những thiếu sót thiết kế còn chưa bao quát hết Bằng cách phát hiện

và loại bỏ một số phần trăm lớn những sai sót này, tiári trình xét duyôt

đã rút gọn chủ yếu chi phí cho các buớc kế tiếp trong giai đoạn phát triển và bảo trì

Để minh hoạ cho tác động chi phí của việc phát hiện lỗi sớm, chúng ta xem xét một loạt các chi phí tương đổi làm cơ sở cho đữ bệu chi phí thực tại đối với các dự án phần mềm lớn Giả sử rằng một lỗi không được phát hiện ra trong ứiiết kế sẽ tốn 1,0 đơn vị tiển tệ đổ sửa chữa So tương đối chi phí này thì cùng lỗi đó khổng đ ii^ phát hiện

ra trước khi kiểm thử bắt đầu sẽ tốn 6,5 đơn vỊ; trong giai đoạn kiểm

thử tốn 15 đơn vị; và sau khi bàn giao thì tốn khoảng chừng 60 đến

100 đơn vị

\1 1 2 Khuếch dại và loại bỏ khiếm khuyết

Mô hình khuếch dợi khiếm khuyết có ửíể được dùng để minh hoạ

cho việc phát sinh và phát hiện lỗi trong thiết kế sơ bộ, thiết kế chi tiết và bước mã hoá của tiến trình kĩ nghệ phần mềm Mô hình này được minh hoạ theo sơ đổ trong Hình 17.3 Hộp biểu Uụ cho bước phát triến phần mềm

Hình 17.3 Mô hình khuếch đại lỗiTrong bước này, lỗi có ứiể ngẫu nhiôn đuợc sinh ra Việc xét duyệt có thể không phát hiện đuợc lỗi mới và lỗi từ các bước tnrớc, gây ra một số lỗi bị bỏ qua Troìg một số ưường h<3 ), lỗi hị bỏ qua từ

các bước trước còn bị khuếch đại lên (khuếch đm ưieo hệ sổ x) bởi

cỡng việc hiện tại Việc phân chia hộp này biểu diẻn ưirng đặc tnmg

và hiôu quả phần trăm cho việc phát hiện lỗi, một chúc năng của tính hiệu suất của xét duyệt

Hình 17.4 minh hoạ cho một thí dụ giả Uiiết về khuếch đại khiếm khuyết đóì vói tiến trình phát triển phẩn mềm trong đó không tiến hành một xét duyệt nào cả Tham khảo trên hình vẽ, mỗi bước kiểm ứỉử được giả thiết làm lộ ra và sửa đuợc 50 phần trăm tất cả các lỗi xảy tới mà không đưa thâm vào bất kì lỗi mới nào (một giả thiết lạc quan) Mười Ichiếin khuyết Uiiết kế sơ bộ được khuếch đại ứiành

94 lỗi trước khi việc kiểm thử bắt đầu Miròi hai khiếm khuyết sau đó

lộ ra trẽn hiện trường

lìiiét kế ban đẩu

nuế« k ế chi liết

Kiểm UiừphỄ chuẩn

iQÃn ưiử hệ úiòng

ỊM§Ỉ^S:ẩ

Lỗi Ẩn

Hình 17.4 Khuếch đại lỗi — khững qua xét duyệtHình 17.5 xem xét cùng nhOng dSẻu kiện này ngoại trừ rằng các cuộc họp xét duyệt thiết kế và mã hoá được tìến hành như một phẩn của từng bước phát triển Trong truờng hợp này, 10 lỗi thiết kế sơ bộ được khuếch đại thành 24 lỗi truớc khi việc kiểm thử bắt đầu Chỉ bã khiếm khuyết còn tổn tại vổ sau Nhớ lại chi phí tương đ<fi Uôn kết vói việc phát hiện và sửa lỗi, ta có thể ửũết lập chi phí toàn bộ (có tfnh và không tính họp xét duyệt cho thí dụ giả thiết của chúng ta)

Tliiết kế ban đầu

Tham khảo đến Bảng 17.2 có tìiể thấy rằng chi phí toàn bộ cho việc phát triển và bảo trì khi xét duyệt đuọc tiến hành là 783 đơn vị chi phí Khi không tiến hành xét duyột, chi phí toàn bộ là 2177 đơn vị

- nhiéu gẩn gấp ba ỉẩn

Để tiến hành xét duyệt, người phát triển phải dành thời gian, công sức và tiền bạc Tuy nhiên, kết quả của úư dụ vừa nêu trên để lại chút hoài nghi rằng chúng ta đâ găp phải tình huống “trả giá bây giờ hay trả nhiều hoti về sau.” Các cuộc họp lũ thuật chính ứiức (cho các hoạt động thiết kế và kĩ tìiuật khác) đưa ra một fch lợi biểu diễn ưiấy được về chi phí Cho nôn cẩn tiến hàxứi chúng

Không thông qua xét duyệt

2177

Bảng 17.2 Tương quan chi phí phát triển

17.3 HOP XÉT DUYẺT KĨ THUĂT CHĨNH THỨC (FTm

Họp xét duyệt kĩ Uiuật chính thức là một hoạt động đảm bảo chất lượng phần mẻm do những người hành nghề Iđ nghê phần mềm Uiực hiện Mục tiêu của FTR là (1) phát hiện ra lỗi theo chức năng, logic hay cài đạt cho bất kì biểu diễn nào của phần mềm, (2) kiểm chứng rằhg phần mềm duới các cuộc họp xét duyệt đáp ứng được các yêu cầu của nó, (3) đảm bảo rằng phần mềm đã được biểu diễn theo các chuẩn địnỉí sẵn, (4) đạt tới phần mềm được phát triển một cách đéu đạn, và (5) làm cho các dự án được quản lí tốt hơn Bên cạnh đó, FTR phục vụ như một nền tảng huấn luyện, làm cho các kĩ sư tập sự quan sát được các cách tiếp cận khác nhau tới việc phân tích, thiết kế và cài đạt phần mém FTIÍ cũng phục vụ cho việc khởi xướng hỗ trợ và tiếp tục vì một số người trở nôn quen thuộc với những bộ phận phần mẻm đến mức họ có thổ không thấy cái gì khác

FTR thực tế là một lớp các cuộc xét duyệt bao gồm tỉuỉo triiúi, giám định, xét duyệt quay vòng và những ứíẩm định Iđ ưiuât theo

nhóm nhỏ khác cho phần mềm Mỗi FTR đéu được tiến hành như một cuộc họp và sẽ tíiành công níu nó được vạch kế hoạch, điều khiển và tham dự đúng đắn Trong những đoạn sau đây, những hướng dẫn

tưcttig tự như hướng dẫn cho thảo trình được trtnh bày như cách xét

duyệt kĩ thuật chúứỉ thúc đại diện

• Thời hạn của cuộc họp xét duyệt nên ít hơn 2 giờ

Với những ràng buộc trên, hiển nhiên là FTR nên hội tụ vào một phần riêng biệt (và nhỏ) của toàn bộ phần mềm Chẳng hạn, thay vì

cố gắng xét duyệt toàn bộ thiết kế thì cuộc họp thảo trình được tiến hành cho từng mô đun hay nhóm nhỏ các mô đun Bằng cách làm hẹp

sự tập trung, FTR có khả năng cao hơn trong việc phát hiện ra lỗi

Sự tập trung của FTR là vào sản phẩm - thành phần của phẩn mềm (tức là một phần của đặc tả yẽu cẩu, một mổ đun chi tiết, một bản in mã gốc cho mô đun) Cá nhân đã phát triến sản phẩm này

- người sản xuất - báo cho người phụ trách dự án rằng sản phẩm đã

hoàn chỉnh và rằng cần có họp xét duyệt Người phụ trách dự án tiếp xúc với người chủ toạ xét duyệt, người đánh giá sản phẩm về tính sẩn sàng, phát sinh ra các bản sao sản phẩm và phân phát chúng cho hai hay ba ngưòd duyệt để chuẩn bị trước Mỗi người duyệt đều được dự kiến dành khoảng 1 đến 2 tiếng xét duyệt sản phẩm, ghi lại lưu ý và ngoài ra cũng trở nên quen thuộc hơn công việc Song song với việc

đó, người chủ toạ xét duyệt cũng xem xét sản phẩm và lập chương trình nghị sự cho cuộc họp xét duyệt về cơ bản được lập lịch cho ngày hổiTi sau

Cuộc họp xét duyệt có người chủ toạ xét duyệt, ưft cả những người duyệt và người sản xuất Một trong những người duyệt giữ vai

trò thư kí, tức là người ghi lại (viết ra) mọi váh đẻ quan trạig nẩy sinh

trong cuộc xét duyẽt FTR bắt đầu với một thảo luận vé chuông trình nghị sự và một giới ứũộu tóm tắt của người sản xuất Rổi người sản xuất tiến hành “thảo trình” vể sản phẩm, giải tìưch vể chất liệu, trcHig Ichi những nguời duyệt nêu ra các văh đẻ dựa u^n sự chuẩn bị trước của mìnhT Khi các ván đề hợp lô hay đuậc jM t hiện ứủ thư kí sẽ ghi lại từng lưu ý

Vào cu<fi việc xét duyệt, tất cả nhũng nguời tham dự FTR đều phải quyết định liệu cố ( 1) chấp tứiận sản phẩm mà khổng sửa đổi ^ ứiôm, (2) bác bỏ sản phẩm do có lỗi nghiêm trọng (một khi đã được sửa thì phải thực hiện cuộc xét duyệt khác), hay (3) chấp nhận sản phẩm tạm thời (những ỉỗi nhỏ đã gập và phải được sửa, nhung

cẩn cuộc xét duyệt thêm) Khi quyết định được ban bố thì cả các

thàiứì viẽn FTR hoàn thành việc kí tắt, chỉ ra sự tham dự của họ vào

trong cuộc xét duyệt và sự nhất trí của họ với phát kiến của nhóm xét duyệt

17.3.2 Báo cáo xét duyệt và cất giữ biên bản

Trong FTR, người duyệt (người ghi biên bản) tích cực ghi lại tất

cả các ván đề đã được nêu ra Những vẵh đề này được tá n tắt vào

cuối cuộc họp xét duyệt và danh sách các vấn đề xét duyệt được tạo

ra Bên canh đó, một báo cáo tóm tắt xét duyệt cũng đuợc hoàn tất

Một báo cáo tóm tắt xét duyệt trả lời cho ba câu hỏi:

1 Cái gì được xét duyệt?

2 Ai xét duyệt nó?

3 Những phát kiến và kết luận là gì?

Báo cáo tóm tắt xét duyệt có dạng như được minh hoạ trong Hình 17.6a Nói chung, dạng Irang đt^n giản này (có thể có đính kèm) trở thànli một phẩn của bản ghi lịch sử dự án và có ứíể được phân phát cho người phụ trách dự án và các bên quan tâm khác

lìáo cáo !óni tát I k > p xé! tluyệl kĩ thuật

Tên cuốc hop xét duvẻt

D ự án: sỏ' hiộu xét duyêl:

Tẽn sáii phẩtn:

Sản phẩiĩi dược xét duyệt:

Người sảii xuất:

Mồ tả váii tát:

Sản phẩm đươc duvẽt: (viết lừng khoản mục tách biệl)

Nlìóm duvẽt: (viết rõ người chù loạ và thư kí)

Đánh giá sảii phẩm:

Chấp nliận: uhư ( ) với sửa đổi nhò

Kỉiông cliấp lứiận: sủa đổi chínli ( ) sửa đổi phụ ( )

Xét duyệt chưa hoàn tất (giải thích sau đó)

Các tài liéu bổ sung đửĩh kèm:

Danh sách víãỉ dể Sản phảĩi chứ giải

sách kiểm các khoản mục lùiitlì dộng sẽ hướng dẫn người sản xuất về những sửa đổi cần tiến hành Một danh sách vấn đề tương ứng với báo cáo tóm lất điRx; vẽ trong Hình 17.6b.

Sô' hiệu xét duyệt:

“rơi vào lối cũ.”

17.3.3 Hướng dẫn xét duyệt

Hướng dẫn để tiến hành các cuộc xét duyệt kĩ thuật chính thức phải được ứiiết lập trước, được phân phát cho tất cả ngưòã duyệt, được nhất tn rồi tuân thủ Cuộc xét duyệt không được kiểm soát thì thưồíig

có thể còn tồi tệ hơn là không có cuộc xét duyệt nào

Sau đây là biểu diỗn cho một tập tối thiểu những hướng dẫn vổ họp xét duyột kĩ thuật chính thírc:

ì Xét cluvệí sởn phẩm, klìỏníỊ xét duyệt người sản xitất.

Cuộc FTR bao gổm con người và bản ngã Được tiến hành đúng đắn, F n^ để lại cho mọi người thaiĩ) dự một tình cảm nồng hậu vé thành tiai Đưi?c tiến hành khỗng đúng thì FTR có thể mang hơi

hướng cùa cuộc điẻu tra Lỗi lầm có ứiể được chỉ ra một cách nhẹ nhàng; tinh thẩn của cuộc họp nên ứìoáng đẵng và xây dựng; nội dung khỡng nôn ^ây bốì r(fi hay bị xem thường Người chủ toạ xét duyệt nên tiến hành cuộc họp xét duyệt để đảm bảo rằng tình thẩn và thái độ đúng mực đirợc duy trì và nên lập tức dừng cuộc xét duyệt nếu bắt đầÌi mất điểũ Ichiển.

2 Lập chương trĩnh nghị sự và duy trì nó.

Một trong những căn bệnh chính của lĩiọi kiểu họp hành là bị sa

đà Cuộc FTR phải được giữ đúng đường và ửieo lịch biếu Người chủ

toạ xét duyệt có đặc quyền trách nhiệm duy trì lịch họp và không nôn

sợ phải huých ngưòi khác khi xuất hiện sự sa đà

3 Hạn chế tranh luận và bác bỏ

Khi một váh đé được nguời duyệt nôu ra, có thể không có sự đổng ý chung vé tác động của nó Thay vì mất thời gian tranh luân về câu hỏi, nôn ghi lại vái đề để thảo luận thêm bên ngoài

4 Phát biểu lĩnh vực vấn đê' nhưiĩg không cô'giải quyết mọi vấn đê đã ghi lại.

Họp xét duyột không phải là phiên giải quyết vấn để Giải pháp cho vấh đé thường được người sản ;cuất hoàn thành một mình hay với

sự giúp đỡ của một cá nhân khác Việc giải quyết vấn đề nên được hoãn lại cho tới sau cuộc họp xét duyột

5 Ghi biên bán.

m

Đôi khi một ý tưởng hay cho thư kí là viết các lưu ý lên bảng tường để cho chữ viết và sự ưu tiên có ưiể thu hút những người duyệt khác vào ứiông tin được ghi lại

6 Hạn chế số người tham dự và nhấn mạnh vào việc chuẩn bị trước.

Hai người thì tốt hơn m ộ t, nhưng 14 người lại chưa chắc đã tốt hơn 4 người Bạn hãy giữ số người tham dự ở mức tối thiểu Tuy nhiên, tất cả thành viôn nhóm duyệt đểu phải chuẩn bị trước Những lời nhận xét viết ra nên được người chủ toạ xét duyệt nhấn mạnh (đưa

ra chỉ dẫn rằng người duyột đã xem xét tài liệu)

7 Xây dựng danh sách kiểm cho từng sàn phẩm cồ thể được xét duyệt.

Daiứi sách kiểm giúp người chủ toạ xét duyệt cấu trúc cuộc họp

FTJi và giúp từng người duyệt tập trung vào các vấh đề quan ưọng Danh sách kiểm nên được xĩiy dịmg chõ tài liệu phân tích, thiết kế,

mã hoá và thậm chí cả tài liệu kiểm thử Một tập hợp các danh sách kiểm xét duyộl đại diộn được trình bầy trong Mục 17.3.4

8 Cấp phát tài iHỉiívêii và lịrlì thời gian cho FTR.

Đổ xét duyệt có hiệu quả, phải lập lịch cho FTR như các nhiệm

vụ trong tiến trình kĩ nghệ phần mẻm Bôn cạnh đó, thời gian được lên lịch để chừa cho những sửa đổi không tránh khỏi sẽ xuất hiện như kết quả của FTR

9 Tiến hành huấn luyện có V nghĩa cho tất cả người duyệt.

Để tăng hiệu quả, mọi thành viên xét duyệt đéu nên có một sự huấn luyộn chính thức nào đó Việc huấn luyện nên nhấn mạnh cả về các vấn đẻ liên quan tới xử lí và hiệu quả tâm ư của người duyệt Freedman và Weinberg ước lượng đường cong học tập 1 tháng cho 20 người dự định tham gia có hiệu quả vào các cuộc xét duyệt

10 Xét duyệt lại các lẩn xét duyệt trước đây.

Việc phỏng vắn có thể có ích lợi trong việc làm lộ ra ván đề với bản thân tiến trình xét duyệt, sản phẩm đầu tiên cần được xét duyệt

có thể là bản thân những huớng dẫn xét duyệt

17.3.4 Danh sách kiểm của xét duyệt

Các cuộc họp xét duyệt kĩ thuật chính thức có thể được tiến hành trong ưitig buớc trong tiến trình kĩ nghệ phần mẻm Trong mục này, chúng ta trình bầy một danh sách kiểm ngắn gọn có tíiể đ i ^ <Klng để thẩm định sản phẩm vốn được dẫn ra như m à phần của sự ịáiát triển phần mẻm Danh sách kiểm này không định bao hàm, mà đưa ra một điểm khởi đầu cho từng lần xét duyệt

Kĩ nghệ hệ thống Bản /Jặr tà hệ thống cấp phát các chức năng

và hiệu năng cho nhiều phắn tử hẹ thống Do đó, việc xét duyệt hệ thống bao gồm nhiều khu wrc có thể tập trung vào lĩnh vực quan tâm riông cìia chúng Các nhóm kĩ nghệ phần mểm và kĩ nghô phần cứng lập trang vào việc cấp phát phần mềm và phần cứng tương ứng Việc

đảm bào chất lượng thẩm định các yôu cầu hợp lệ mức hệ Ihống và 'dịch vụ lại hiộn trường xem xét lại các yêu cẩu để chẩn đoán Một khi tất cả các cuộc họp xét duyệt đã được liến hành thì mội cuộc họp xét duyột lớn hưn, với đại diện lừ mọi khu vực, sẽ đirợc tiến hằnh để đảm bảo sự trao đổi các mối quan lâm từ đầu Danh sách sau đây bao quái một số ữnh vực quan tâm quan trọng hcĩn:

1 Các chức năng chính đã được xác định theo mộl cách không mơ

hồ và chắc chắn chưa?

2 Giao diện giữa các phần tử hệ Uiống đã đưạ: xác định chưa?

3 Các giới hạn hiệu năng đã được thiết lập cho hộ thống như một tổng thể và cho từng phần tử chưa?

4 Các ràng buộc thiết kế đã được thiết lập cho từng phần tử chưa?

5 Giải pháp tốt nhất đã được chọn lựa chưa?

6 Giải pháp có khả thi vé măt Id thuật không?

7 Cơ chế làm hợp lệ và kiểm chứng hộ tháng đã được thiết lập chưa?

8 Có sự nhất quán trong tất cả các phần tử hệ thống không?

Lập kế hoạch dự án phán mém Việc lãp kế hoạch dự án phần mém thẩm định rủi ro và xây dụng các ước lượng vé tài nguyôn, chi phí,lịch biểu dựa trên việc cấp phát phần mém đã được thiết lập như một phần của hoạt động lã nghệ hệ thống Danh sách kiểm sau đây là

áp dụng được:

1 Phạm vi phần mềm có được xác định không mơ hổ và chắc chắn không?

2 Có rõ ràng vẻ thuật ngữ không?

3 Tài nguyên có thích hợp cho phạm vi không?

4 Tài nguyên có sẵn sàng để dùng không?

5 Các rủi ro trong mọi phạm trù quan trọng đã được xác định chưa?

6 Kế hoạch quản lí rủi ro có chưa?

7 Các nhiệm vụ có được xác định và sắp tuần tự đúng không? Liệu

có cơ chế song song Ihoả đáng với những tài nguyên có sẵn không?

8 Cơ sở cho việc ước lượng chi phí có hợp lí không? Việc ước lưiíng chi phí có được phát triển bằng cách dùng hai frfiương pháp độc lập không?

9 Dữ liệu chất lượng và hiệu năng lịch sử có được dùng không?

10 Những sai biệt trong các ước lượng đã được điều hoà chưa?

11 Ngân sách và hạn chót lập sẵn có hiện thực không?

12 Lịch biểu có nhất quán không?

Phân tích vêu cáu phần mềm Cuộc họp xét duyệt phân tfch các yêu cầu phẩn mềm tập trung vào tính theo dõi được đcfi với các yêu cầu hệ thống, tính nhất quán và tính đúng đắn của mô hình phân tích Một số FTR được tiến hành đối với yêu cầu của hộ thống lớn và có thể được tăng thêm bởi các cuộc xét đuyột và uớc lượng bản mẫu cũng như cuộc họp với khách hàng Các chủ đé sau đây được xem xét trong FTR đốì vdi việc phân tích:

1 Việc phân tích miền ứiông tin có đẩy đủ, nhất quán và chính xác không?

2 Vễứỉ đẻ có được phân hoạch đầy đủ không?

3 Các giao diện bên ngoài và bên trong có đuợc xác định đúng không?

4 Mô hình dữ liệu có phản ánh đúng sự vật dữ liệu, các thuộc tính

và mối quan hệ của chúng không?

5 Tất cả các yêu cầu có theo dõi được với mức hệ thống không?

6 Việc làm bản mẫu có được tiến hành cho ngitòi dùng/ khách hàng không?

7 Liệu hiệu năng có đạt được trong những ràng buộc bị áp đạt bởi các phần tử hệ thống khác không?

8 Các yêu cầu có nhất quán với lịch biểu, tài nguyên và ngân sách không?

9 Các liêu chuẩn hợp lệ có đầy đủ không?

Thiết kê' phẩn nicm Việc xél duyôl Ịhiếl kế phần mẻm tập irung vào thiết kế dữ liêu, thiết kế kiến tnic, và thiết kế thủ tục Nói chung,

hai kiểu xét duyột thiết kế thường đưcx; liến hành, ỵẻí duyệt thiết k ế sơ

bộ thẩm định việc dịch các yêu cầu Ihành thiêì kế dữ liệu và kiến trúc Xét duyột Ihứ hai, thường được gọi là lluìo trình thiết kê, tập trung

vào tính đúng đắn thủ tục của thuât toán khi chúng được cài đạt bên trong các mô đun chương trình Danh sách kiểm sau đây là có ích cho từng việc xét duyệt:

Đốì vói xét duyệt thiết kế sơ bộ:

1 Các yôu cầu phẩn mềm có được phản ánh trong kiến trúc phẩn mếm không?

2 Tính mô đun có đạt được hiệu quả không? Các mô đun có độc lập

vẻ chúc năng không?

3 Kiến trúc chương trình có rút ra điểm chung không?

4 Các giao diện có được xác định cho các mô đun và phẩn tử hệ thống ngoài không?

5 Cấu trúc dữ liệu có nhất quán với miền thông tin không?

6 Cấu trúc dữ liộu có nhất quán với yêu cầu phần mềm không?

7 Tính bảo trì đã được xem xét tái chưa?

8 Các nhân tố chất luợng (Mục 17.1.1) đã đuợc thẩm định tường minh chưa?

Với cuôc thảo trình thiết k ế :

1 Thuật toán có thực hiện được chúc năng mong muốn không?

2 Thuật toán có đúng đắn về logic không?

3 Giao diện có nhất quán với thiết kế kiến trúc không'?

4 Độ phức tạp logic có hợp ư không?

5 Giải quyết lỗi và “chống lỗi” đã được xác định chưa?

6 Các cấu trúc dữ liệu cục bộ có được xác định đúng không?

7 Các kết cấu lập trình có cấu trúc có được dùng xuyên suốt

8 Chi tiết thiết kế có thuân theo ngôn ngữ cài đạt khổng?

9 Cái nào được dùng: hệ điều hành hay các tfnh nãng {diụ thuộc ngôn ngữ?

10 Logic ngược hay hợp thành được dùng?

11 Tính bảo trì cố đuợc xem xét tới ld ỉ( ^ ?

Mă hoá Mặc dẩu mã hoá là kết quả tự nhiẽn cơ giới của thiết kế thù tục, lỗi vẫn có thể bị đưa vào khi thiết kế được dịch vào trong ngôn ngữ lập trình Điều này đặc biệt đúng nếu ngôn ngữ lập trình không hỗ trợ trực tiếp cho các cấu trúc dữ liộu và điéu khiển trong thiết kế Cuộc thảo trtnh mã hoá có thể là một phương tiện có hiệu quả để làm lộ ra những lỗi địch này Bản danh sách kiểm sau đây giả thiết rằng cuộc thảo trình thiết kế đã được tiến hành và rằng tính đúng đắn của tìiuật toán đã đuợc thiết lập như một phần của ứiiết kế FTR

1 Thiết kế có được dịch đúng thành mã không? (Kết quả của thiết

kế thủ tục phải có sẩn trong cuộc họp xét duyệt này.)

2 Có lỗi chính tả hay gõ sai không?

3 Có dùng đúng các qui ước ngôn ngữ không?

4 Có sự tuân thủ với các chuẩn mã hoá về phong cách ngốn ngữ, chú ứưch, giới thiệu về mô đun không?

5 Các chú thích có sai hay mơ hổ không?

6 Các kiểu dữ ỉiẽu và khai báo dữ ỉiệu cố đúng k ỉ ^ g ?

3 Các chức năng chính đã được biểu diễn sớm chưa?

4 Kế hoạch kiểm thử có nhất quán vói kế hoạch dự án tổng thê không?

5 LỊch kiểm thử đã được xác định tuờng minh chưa?

6 Các tài nguyên và công cụ kiểm ứíử đã được xác định và có sẩn không?

7 Cơ chế lưu giữ bản ghi kiểra thử đã được thiết lập chưa?

8 Các bộ khiển trình (driver) và cuống (stub) đã đuợc xác định và công việc phát triển chúng đã được lập lịch chưa?

9 Việc kiểm thử ứng suất (stress) cho phần mềm đã được xác định chữa?

Vdi thủ tục tóểm thừ

1 Cả hai phép kiểm thử hộp đen và hộp trắng (xem Qiương 18) đã được xác định chưa?

2 Tất cả các con đường logic độc lập đã được kiểm thử hết chưa?

3 Các trường hợp kiểm thử đã được xác định và liệt kê vói kết quả trông đ ậ chưa?

4 Việc giải quyết lỗi có được Idểni thử không?

5 Các giá trị biên có được kiểm thừ khổng?

6 Thời gian và hiệu năng có được kiểm thử không?

7 Các biến động chấp nhận được từ kết quả mong đợi đã được xác định chưa?

Bôn cạnh các cuộc họp xét duyệt kĩ thuật chính thức và danh

sách kiểm xét duyệl được lưu ý ở trên, các cuộc xét đuyột (với danh sách kiểm tương ứng) có thể được tiến hành để thẩm định tính sẵn sàng của cơ chế dịch vụ hiện (rường cho phần mẻiĩi sản phẩm, để ước lưiỊTng tính đẩy đù và tính hiệu quả của huấh luyện, để thẩm định chất lượng của tài liệu kĩ thuật và người dùng, và đổ điều tra tính áp dụng được và tính sẩn có của công cụ phần mềm.

Bảo trì Danh sách kiểm xét duyệt cho phát triển phẩn mềm là

hợp lệ tương đương cho giai đoạn báo tri phần mềm (Chương 20)

Bôn cạnh tất cả các câu hỏi được đạt ra trong danh sách kiểm trước, các xem xét đặc biệt sau đây nôn được nhớ trong đẩu:

1 Hiệu quả phụ liên kết với sự thay đổi đã được xem xét tới chưa?

2 Yêu cầu vể tìiay đổi đã được làm tài liệu, đánh giá và chấp thuận chưa?

3 Liệu ửiay đổi, một khi được thực hiện, đã được làm tài liệu và báo cáo cho tất cả các bên quan tâm chưa?

4 FTR thích hợp đã được ũến hành chưa?

5 Họp xét duyệt chấp nhận cuối cùng đã được tiến hành để đảm bảo

rằng tất cả phẩn mềm đã được cập nhạt, kiểm ứiử và ứiay thế đúng chưa?

Riần đầu chương này chúng ta đã thảo luận vẻ một tập các nhân

tố chất luợng cho “^ ê c đo” chất lượng phẩn mềm (Mục 17.1.1) Qiúng ta cố gắng phát triển cách đo chính xác vế chất luợng Ịdiẩn mểm và đôi khi thất vọng bởi bản chất chủ quan của hoạt điại^ này Cavano và McCall ứiảo luận vẻ únh huđng này;

Viộc xác định chất luợng là nliân tô' chủ chốt trong các sự kiện hàng ngày - thi nếm rượu, sự kiện thể Ihao [như thể dục], thi tài, V.V Trong nhũng tìiứi huổng này, chất lượng được đánh giá theo cách trực tiếp và nển tảiig nhất: so sánli các sự vậí cạnh lứiau trong các diẻu kiên đổng nhất và với các kliái niệm dịiih sẵii Rượii có thể đuọc đánh giá theo độ trong, mầu sác, hucnig vị, liiùi vị V V Tuy nliiên, kiểu dánh này rất chủ quan, dể có được giá trị nào trong đó thì nó phải do một chuyên gia tiến hàiili