Tải bản đầy đủ
CHƯƠNG 1 VỊ TRÍ VÀ VAI TRÒ CỦA KIỂM ĐỊNH PHẦN MỀM

CHƯƠNG 1 VỊ TRÍ VÀ VAI TRÒ CỦA KIỂM ĐỊNH PHẦN MỀM

Tải bản đầy đủ

Giai đoạn quy hoạch
Trong giai đoạn này dự án được nghiên cứu và học hỏi qua việc thu
thập thông tin (phỏng vấn người sử dụng hoặc nhân viên bảo quản các
chương trình, nghiên cứu tài liệu và quan sát hiện trường) để thu thập yêu cầu
đặt ra cho chương trình. Điều quan trọng cần rút ra khi giai đoạn này kết thúc
đó là:
-

Tính khả thi của công trình gồm: Khả thi về mặt kỹ thuật , tác vụ và
kinh tế. Liệu công trình có thể thực hiện được không và có phải giải
pháp kỹ thuật là giải pháp duy nhất cho công trình này hay không?

-

Một hồ sơ hoạch định yêu cầu và phạm vi của công trình.

Giai đoạn xác định
Khi hoàn thành giai đoạn này phải có: một hồ sơ nêu rõ ràng công trình
sẽ làm những gì, khi nào làm, làm cho ai và sẽ làm như thế nào. Sự bổ nhiệm
của các giám đốc dự án, chuyên gia kỹ thuật bao gồm kiến trúc, thiết kế phần
mềm, cơ sở dữ liệu và vai trò cũng như trách nhiệm của họ trong sự phát triển
của dự án. Đối tượng tham gia ở giai đoạn này gồm: những người chịu trách
nhiệm triển khai dự án (phía khách hàng), nhóm quản lý dự án (phía công ty
phát triển), nhân viên nghiệp vụ (người sử dụng), chuyên viên tin học (người
khảo sát)
Giai đoạn phân tích
Việc hiểu biết đầy đủ về các yêu cầu của phần mềm là điều chủ chốt
cho sự thành công của nỗ lực phát triển phần mềm. Nhiệm vụ của người phân
tích là một tiến trình khám phá làm mịn, mô hình hoá và đặc tả. Giai đoạn này
có sự tham gia của cả người phát triển và khách hàng (người sử dụng). Kết
quả của giai đoạn này là một danh sách chi tiết các yêu cầu của người sử
dụng. Đồng thời liệt kê chi tiết những dữ liệu liên quan trong các chương
trình.

Giai đoạn thiết kế
Trong khi giai đoạn phân tích dùng để trả lời cho các câu hỏi dự án sẽ
làm gì, khi nào làm, và làm cho ai thì giai đoạn thiết kế dùng để chỉ ra phương
hướng và cách phát triển của dự án. Giai đoạn này sẽ nêu ra những đòi hỏi kỹ
thuật về thiết kế và những công cụ để xây dựng phần mềm chẳng hạn như.
Net, C#, C++, Windows hay Unix cho hệ điều hành, Oracle hay MS SQL
Server cho cơ sở dữ liệu. Giai đoạn này rất quan trọng vì nó có ảnh hưởng
đến những giai đoạn sau như xây dựng (lập trình) và cài đặt phần mềm. Đối
tượng tham gia giai đoạn này: nhóm quản lý dự án, chuyên viên tin học.
Giai đoạn xây dựng
Giai đoạn này là lúc các kỹ sư thiết kế và lập trình viên dựa trên các
bản thảo từ giai đoạn thiết kế cùng nhau thảo các chương trình phần mềm cần
thiết cho sự hoàn thành của dự án qua đó thoả mãn yêu cầu của người sử
dụng. Ngoài ra cũng sẽ có sự tham gia của các chuyên viên kiểm tra và duyệt
xét (Quality Assurance) phần mềm trong giai đoạn này nhằm đảm bảo chất
lượng của sản phẩm phần mềm.
Giai đoạn kiểm định
Tiến trình kiểm định bao gồm việc
+ Phát hiện và sửa lỗi phần logic bên trong chương trình hay còn gọi là
lỗi lập trình.
+ Kiểm tra xem phần mềm có hoạt động như mong muốn không, tức là
phát hiện và sửa lỗi về chức năng như thiếu hụt, sai sót về chức năng; và kiểm
tra xem phần mềm có đảm bảo tính hiệu quả trong thực hiện hay không.
Giai đoạn bảo trì
Bao gồm các công việc sửa các lỗi phát sinh khi áp dụng chương trình
hoặc thích ứng nó với thay đổi trong môi trường bên ngoài (hệ điều hành mới,
thiết bị ngoại vi mới, yêu cầu người dùng) hoặc yêu cầu bổ sung chức năng
hay nâng cao hiệu năng cần có.

Giai đoạn cài đặt
Đây là giai đoạn cuối cùng trong chu kỳ phát triển dự án phần mềm. Giai
đoạn này đỏi hỏi các quy hoạch trong việc chuyển giao sản phẩm tới người sử
dụng và việc cài đặt các sản phẩm này trong môi trường làm việc của người sử
dụng. Trong giai đoạn này hệ thống được sử dụng chính thức. Người sử dụng
có nhiệm vụ ghi nhận và phản ánh tất cả những vấn đề khó khăn trở ngại trong
quá trình sử dụng phần mềm tới nhóm quản lý dự án để khắc phục kịp thời và
sẽ cho biết quyết định chấp nhận hay từ chối sản phẩm làm ra qua các khâu
kiểm tra và duyệt xét xem chương trình có thoả mãn các đòi hỏi theo các hồ sơ
lập ra từ các giai đoạn xác định và phân tích. Đối tượng tham gia giai đoạn
này: Nhóm quản lý dự án, người sử dụng, chuyên viên tin học.

Xác định

Hình 1.1: Quy trình phát triển phần mềm

1.1.2. Lỗi phần mềm

Có rất nhiều định nghĩa khác nhau về lỗi phần mềm, nhưng nhìn chung như
sau: “Lỗi phần mềm là sự không khớp giữa chương trình và đặc tả của nó.”
Dựa vào định nghĩa, chúng ta có thể thấy lỗi phần mềm xuất hiện theo ba
dạng chính như sau:
 Sai: Sản phẩm được xây dựng khác với đặc tả.
 Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản

phẩm được xây dựng.
 Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc

tả. Cũng có trường hợp yêu cầu này có thể là một thuộc tính sẽ được
người dùng chấp nhận nhưng khác với đặc tả nên vẫn coi là có lỗi.
Lỗi có thể xảy ra trong tất cả các công đoạn từ “Mô tả yêu cầu”, “Thiết
kế” đến “Lập trình”.
Từ công đoạn này chuyển sang công đoạn khác thường nảy sinh các sai
sót (do dư thừa hoặc thiếu theo mô tả yêu cầu).
Đến công đoạn kiểm định chúng ta sẽ phát hiện ra các hậu quả (các kết
quả không mong muốn).
Quá trình sửa lỗi bao gồm “phân loại lỗi”, “cô lập lỗi” (tìm ra nguyên
nhân và nơi gây lỗi), đề ra “giải pháp sửa lỗi” và cuối cùng là khắc phục lỗi.

1.1.3. Tại sao phần mềm có lỗi

Khác với sự cảm nhận thông thường, lỗi xuất hiện nhiều nhất không phải
do lập trình. Nhiều nghiên cứu đã được thực hiện trong các dự án từ rất nhỏ
đến các dự án rất lớn và kết quả luôn giống nhau. Số lỗi do đặc tả gây ra là
nhiều nhất, chiếm khoảng 80%. Có một số nguyên nhân làm cho đặc tả tạo ra
nhiều lỗi nhất. Trong nhiều trường hợp, đặc tả không được viết ra. Các
nguyên nhân khác có thể do đặc tả không đủ cẩn thận, nó hay thay đổi, hoặc
do chưa phối hợp tốt trong toàn nhóm phát triển. Sự thay đổi yêu cầu của
khách hàng cũng là nguyên nhân dễ gây ra lỗi phần mềm. Khách hàng thay
đổi yêu cầu không cần quan tâm đến những tác động sau khi thay đổi yêu cầu
như phải thiết kế lại, lập lại kế hoạch, làm lại những việc đã hoàn thành. Nếu
có nhiều sự thay đổi, rất khó nhận biết hết được phần nào của dự án phụ thuộc
và phần nào không phụ thuộc vào sự thay đổi. Nếu không giữ được vết thay
đổi rất dễ phát sinh ra lỗi.
Ví dụ: Trong đặc tả bài toán phân số:
1. Với việc đặc tả phi hình thức: Phân số là một cặp t/m, trong đó t là một

số nguyên, m là một số tự nhiên lớn hơn 0; t được gọi là tử số, m được
gọi là mẫu số của phân số.
2. Đặc tả hình thức là đặc tả trong đó sử dụng các ký hiệu toán học để mô

tả. Một phân số có thể được đặc tả như sau:
+ Phân số = {(t,m) | t Z, m N+}

Trong đó: N = {0, 1, 2, 3, …}
N+ = {1, 2, 3, …}
Z = {0, 1, 2, 3, …}

(*)

+ Phép chia hai phân số: (t1,m1):(t2,m2) = Reduce(t1 m2, t2 m1),

trong đó Reduce(t, m) = (t/d, m/d) với d = gcd(t, m). Hàm gcd là
hàm tìm ước số chung lớn nhất của hai số tự nhiên.
Đặc tả phép chia như trên là sai với đặc tả phân số (*). Chẳng hạn, thực
hiện chia hai phân số (1,3):(-2,5) = (5,-6), thì mẫu số trong trường hợp này lại
là một số âm, không đúng đặc tả.
Đây là một ví dụ đơn giản về việc đặc tả sai do không đủ cẩn thận. Với
các bài toán lớn thì việc đặc tả sẽ rất khó và dễ nhầm lẫn, sai sót.
Nguồn gây ra lỗi lớn thứ hai là thiết kế. Đó là nền tảng mà lập trình viên
dựa vào để nỗ lực thực hiện kế hoạch cho phần mềm.
Lỗi do lập trình gây ra cũng khá dễ hiểu. Ai cũng có thể mắc lỗi khi lập
trình. Thời kì đầu, phát triển phần mềm có nghĩa là lập trình, công việc lập
trình thì nặng nhọc, do đó lỗi do lập trình gây ra là chủ yếu. Ngày nay, công
việc lập trình chỉ là một phần việc của quá trình phát triển phần mềm, cộng
với sự hỗ trợ của nhiều công cụ lập trình cao cấp, việc lập trình trở nên nhẹ
nhàng hơn, mặc dù độ phức tạp phần mềm lớn hơn rất nhiều. Do đó, lỗi do
lập trình gây ra cũng ít hơn. Tuy nhiên, nguyên nhân để lập trình tạo ra lỗi lại
nhiều hơn. Dó là do độ phức tạp của phần mềm, do tài liệu nghèo nàn, do sức
ép thời gian hoặc chỉ đơn giản là những lỗi “không nói lên được”. Một điều
cũng hiển nhiên là nhiều lỗi xuất hiện trên bề mặt lập trình nhưng thực ra lại
do lỗi của đặc tả hoặc thiết kế.
Một nguyên nhân khác tạo ra lỗi là do bản thân các công cụ phát triển
phần mềm cũng có lỗi như công cụ trực quan, thư viện lớp, bộ biên dịch,…
1.1.4. Chi phí cho việc sửa lỗi

Bảo trì phần mềm thường là phần chi phí chính và kiểm định là hoạt
động chi phí đắt thứ hai, ước tính khoảng 40% chi phí trong quá trình phát
triển ban đầu của sản phẩm phần mềm .

Kiểm định và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của
vòng đời phần mềm. Tuy nhiên chi phí cho việc tìm và sửa lỗi tăng một cách
đáng kể trong quá trình phát triển.
Sự thay đổi một tài liệu yêu cầu khi duyệt lại lần đầu tiên là không đắt
nếu không nói là không đáng kể. Chi phí sẽ tăng lên nhiều hơn nếu các yêu
cầu thay đổi sau khi đã lập trình. Thay đổi yêu cầu lúc đó đồng nghĩa với việc
viết lại chương trình.
Việc sửa lỗi sẽ không còn đáng kể nếu người lập trình tự phát hiện lỗi
của mình. Không có sự liên quan đến chi phí khác. Họ không phải giải thích
lỗi cho bất kỳ người nào. Họ cũng không phải nhập lại lỗi đó vào cơ sở dữ
liệu lỗi và lưu vết lỗi. Người kiểm định và người quản lý không phải phải
duyệt lại tình trạng lỗi. Và lỗi đó không ảnh hưởng đến công việc của người
khác trong nhóm dự án.
Sửa một lỗi trước khi phát hành một phần mềm rẻ hơn rất nhiều so với
việc khắc phục nó sau khi đã phát hành.
Trong tài liệu Boehm [2], có trích dẫn kết quả nghiên cứu của IBM, GTE
và TRW, tổng kết rằng lỗi được phát hiện càng muộn thì chi phí cho việc sửa
lỗi càng lớn. Chi phí tăng theo hàm mũ như hình sau.

1.1.5. Kiểm định phần mềm.

Theo Glen Myers: Kiểm định là quá trình vận hành chương trình để tìm
ra lỗi.
Kiểm định phần mềm thường đồng nghĩa với việc tìm ra lỗi chưa được
phát hiện. Tuy nhiên, có nhiều bối cảnh kiểm định không bộc lộ ra lỗi. Kiểm
định phần mềm là quá trình thực thi một hệ thống phần mềm để xác định xem
phần mềm đó có đúng với đặc tả không và thực hiện trong môi trường như
mong đợi hay không.
Trên thực tế, hệ thống đang thực hiện khác biệt với việc duyệt lại mã
nguồn. Thông thường, người phát triển thực hiện việc đọc lại và phân tích mã
nguồn. Nói cách khác, kiểm định đòi hỏi một hệ thống chạy được. Đặc tả là
căn cứ chủ yếu hỗ trợ cho việc kiểm định. Nó xác định những hành vi đúng
và làm cho dễ dàng hơn trong việc xác định những hành vi không đúng. Mỗi
hành vi không đúng chính là một lỗi phần mềm. Nói chung, người phát triển
phải tự chẩn đoán nguyên nhân sinh lỗi trong mã nguồn.
Mục đích của kiểm định phần mềm là tìm ra lỗi chưa được phát hiện, tìm
một cách sớm nhất có thể và đảm bảo rằng lỗi đã được sửa, mà kiểm định
phần mềm không làm công việc chẩn đoán nguyên nhân gây ra lỗi đã được
phát hiện và sửa lỗi. Mục tiêu của kiểm định phần mềm là thiết kế tài liệu
kiểm định một cách có hệ thống và thực hiện nó sao cho có hiệu quả, nhưng
tiết kiệm được thời gian, công sức và chi phí.
1.2. Quy trình kiểm định phần mềm

Mục đích của kiểm định là thiết kế một chuỗi các trường hợp kiểm định
mà có khả năng phát hiện lỗi cao. Để cho việc kiểm định đạt được kết quả tốt
cần có sự chuẩn bị về kế hoạch kiểm định, thiết kế các trường hợp kiểm định
và các dữ liệu kiểm định cho các trường hợp. Đây chính là đầu vào cho giai
đoạn kiểm định. Và sản phẩm công việc của giai đoạn kiểm định chính là

“báo cáo kiểm định” mà tài liệu hóa tất cả các trường hợp kiểm định dã chạy,
dữ liệu đầu vào, đầu ra mong đợi, đầu ra thực tế và mục đích của kiểm định,
… (như Hình 1.3)

Hình 1.3: Kiểm định trong xử lý phần mềm
Qui trình kiểm định bao gồm một số giai đoạn:
1. Lập kế hoạch kiểm định. Bước đầu tiên là lập kế hoạch cho tất cả các

hoạt động sẽ được thực hiện và các phương pháp được sử dụng. Các chuẩn
IEEE 1012-1986 bao gồm các thông tin về tác giả chuẩn bị kế hoạch, danh
sách liệt kê của kế hoạch kiểm định.
Mục đích: Qui định về phạm vi, phương pháp, tài nguyên và lịch biểu
của các hoạt động kiểm định.
2. Giai đoạn bố trí nhân viên kiểm định. Việc kiểm định thường phải tiến
hành một cách độc lập và các nhóm độc lập có trách nhiệm tiến hành các họat
động kiểm định, gọi là các nhóm kiểm định.
3. Thiết kế các trường hợp kiểm định. Các trường hợp kiểm định là các
đặc tả đầu vào cho kiểm định và đầu ra mong đợi của hệ thống cùng với các
câu lệnh được kiểm định. Có một vài phương pháp thiết kế trường hợp kiểm
định và các qui tắc từ các nhà thiết kế kiểm định có kinh nghiệm. Tuy nhiên,
có hai chiến lược kiểm định cơ bản đó là:
+ Các phương pháp hộp đen để kiểm định dựa trên chức năng.
+ Các phương pháp hộp trắng để kiểm định dựa vào cấu trúc bên trong.

4. Xử lý đo lường kiểm định bằng cách thu thập dữ liệu. Ở đây, người
kiểm định không thể trực tiếp cải tiến chương trình mà họ chỉ có thể đánh giá
nó.Đánh giá sản phẩm phần mềm để xác nhận sản phẩm có thể sẵn sàng phát
hành được chưa? Mô hình của qui trình kiểm định phần mềm được thể hiện
trong hình 1.4.

Hình 1.4 – Qui trình kiểm định phần mềm
1.3. Lợi ích kinh tế của kiểm định phần mềm

Trong phát triển phần mềm, có nhiều chi phí tương ứng với sự kiểm định
các chương trình của chúng ta. Chúng ta cần lập kế hoạch cho các ca kiểm
định, cần viết các ca kiểm định, cần thiết lập các thiết bị thích hợp, cần thực
hiện các ca kiểm định một cách có hệ thống, tiếp tục các vấn đề đã xác định,
cần loại bỏ hầu hết các sai sót tìm được (thực tế, đôi khi chúng ta có thể tìm
thấy các sai sót có mức ưu tiên thấp trong mã nguồn và quyết định việc sửa
sai sót là quá đắt vì cần phải thiết kế lại, lập trình lại... Những sai sót này có
thể tồn tại trong sản phẩm sau khi phát hành). Khi chúng ta không tìm ra và
việc loại bỏ trước các sai sót thì tốn nhiều chi phí ứng với việc chuyển các sai
sót phần mềm tới khách hàng. Khi điều này xảy ra, khách hàng có thể mất
lòng tin vào công ty chúng ta và có thể rất tức giận. Họ cũng có thể mất rất
nhiều tiền nếu hệ thống của họ hỏng vì những sai sót của chúng ta. Và, các tổ
chức phát triển phần mềm phải sử dụng một lượng rất lớn tiền của để thu

được các thông tin cụ thể về những vấn đề của khách hàng và để tìm, sửa các
lỗi đó. Chúng ta cũng cần cân nhắc tiềm năng bị mất của mỗi dự án. Chất
lượng quan trong hơn nhiều đối với phần mềm rất cần sự an toàn như phần
mềm hàng không. Vì vậy, khi chúng ta cân bằng chi phí kiểm định so sánh
với chi phí lỗi phần mềm, chúng ta sẽ kiểm định phần mềm hàng không
chứ không kiểm định phần mềm trò chơi. Thực tế là các phần mềm cần ưu
tiên sự an toàn có thể sử dụng gấp 3-5 lần số kiểm định so với các phần
mềm khác. Để tối thiểu hóa chí phí kiểm định và chi phí lỗi phần mềm,
phải đề ra mục đích kiểm định là phát hiện càng nhiều sai sót với càng ít
kiểm định càng tốt. Kiểm định mọi tổ hợp đầu vào-đầu ra của hệ thống là
điều không thể; có quá nhiều hoán vị và tổ hợp. Là kiể m định viên, cần cân
nhắc lợi ích kinh tế của việc kiểm định và cố gắng viết các ca kiểm định mà
sẽ phát hiện ra càng nhiều sai sót trong phần mềm càng ít ca kiểm định
càng tốt.