Transcript Chương 2: Các mô hình vòng đời của phần mềm

Chương 2: Các mô hình vòng đời của phần
mềm
2.1 Sự phát triển phần mềm trên lý thuyết:
Phát triển phần mềm rất khác nhau trong thực tế vì hai lý do. Đầu tiên, các chuyên
gia phần mềm cũng là con người, do đó sẽ mắc những sai lầm. Thứ hai, yêu cầu
của khách hàng có thể thay đổi trong khi phần mềm được phát triển.
Chương 2: Các mô hình vòng đời của phần
mềm
2.2 Winburg Mini Case Study
• Để giảm ùn tắc giao thông, thiết lập một hệ thống giao thông công cộng chỉ có
làn đường cho xe buýt , thị trưởng vùng khuyến khích "park and ride”. Mỗi xe
buýt là có một máy bán vé, yêu cầu: chỉ chấp nhận tiền là đô la, sử dụng một
thuật toán nhận dạng hình ảnh, máy bán vé phải chính xác, đáp ứng nhanh.
• Chính vì thế, phần mềm làm qua 4 Episode ,mới xem như khá hoàn hảo bằng
mô hình tiến hóa.
Chương 2: Các mô hình vòng đời của phần
mềm
• Mô hình thác nước cũng có thể áp dụng. Nhưng không hiểu thị sự kiện thay đổi
rõ hơn mô hình tiến hóa.
• Mô hình tiến hóa có lợi thế hơn trên mô hình thác nước. Vì có đầy đủ tài liệu
trong 4 Episode.
Chương 2: Các mô hình vòng đời của phần
mềm
2.3 Lessons of the Winburg Mini Case Study
• Một kế hoạch thực hiện kém (sử dụng không cần thiết các con số chính xác gấp
đôi) và quyết định sử dụng một thuật toán quá chậm.
• Chỉ có một phiên bản là có sự thay đổi yêu cầu được thực hiện bởi khách hàng
(là sự cần thiết phải tăng độ chính xác).
• Tại sao thay đổi rất nhiều để có một sản phẩm phần mềm cần thiết? Đầu tiên,
các chuyên gia phần mềm là con người và do đó có thể gây những sai lầm. Thứ
hai, một sản phẩm phần mềm là kết quả của một mô hình của thế giới thực và
thế giới thực là liên tục thay đổi.
Chương 2: Các mô hình vòng đời của phần
mềm
2.4 Teal Tractors Mini Case Study
Teal Tractors mua một công ty máy kéo ở Canada. Việc quản lý của công ty Teal
Tractors quyết định rằng, để tiết kiệm tiền, các hoạt động ở Canada được tích hợp
với các hoạt động ở Mỹ. Điều đó có nghĩa rằng phần mềm đã được thay đổi trước
khi nó được hoàn thành:
- phải được sửa đổi để xử lý các khu vực bán hàng bổ sung.
- phải được mở rộng để xử lý những khía cạnh mới xuất hiện hay thay đổi.
- phải được mở rộng để xử lý hai loại tiền tệ khác nhau.
Việc thay đổi các sản phẩm ở giai đoạn này tương tự như cố gắng để sửa chữa một
sản phẩm phần mềm vào cuối vòng đời của nó.
Chính vì thế, ta phải có 1 mô hình thích ứng với trạng thái thay đổi thường xuyên,
là mô hình lặp và tăng dần.
Chương 2: Các mô hình vòng đời của phần
mềm
2.5 Iteration and Incrementation (lặp và tăng dần)
• Mô hình tương tự như các mô hình tiến hóa hoặc mô hình thác nước (như giả
định).
• Việc sản xuất ra phiên bản này đến phiên bản khác từ các tài liệu ban đầu đến
tài liệu chỉnh sửa hoàn chỉnh, giúp ngày càng phù hợp với mục tiêu đề ra. Gọi là
lặp.
• Những hạn chế của luật Miller: mỗi chúng ta chỉ tập trung khoảng 7 chunks tại
1 thời điểm. Nên tất cả yêu cầu cũng không thể làm hết trong 1 khoảng thời
gian. Chính vì thế, thời điểm này ta làm 7 yêu cầu quan trọng nhất; thời gian
sau làm tiếp 7 cái quan trọng tiếp theo thứ tự. Việc sản xuất phần mềm tuân theo
mô hình tăng cũng vậy. Sản phẩm từng bước được cải tiến.
• Lăp và tăng có tỉ lệ rất khác nhau ở mỗi thời điểm trong chu ky phần mềm. Và
lên kế hoạch, làm tài liệu, kiểm thử luôn luôn thực hiện xuyên suốt.
Chương 2: Các mô hình vòng đời của phần
mềm
• Trong thực tế, lặp và tăng kết hợp với nhau. Một tài liệu cuối được xây dựng
qua từng mảnh (tăng), và mỗi lần tăng đi qua nhiều phiên bản (lặp).
Chương 2: Các mô hình vòng đời của phần
mềm
2.6 Nhìn lại trường hợp nghiên cứu nhỏ ở Winburg: ta thấy
• Các mô hình lặp và tăng không yêu cầu mỗi luồng phải được thực hiện trong mỗi phần
tăng.
• Các luồng có thể chấm dứt bất kỳ lúc nào khi thấy thực hiện không đạt.
• Ba mũi tên đứt đoạn của mô hình tiến hóa, chỉ rằng mỗi phần tăng này được cấu thành từ
bảo trì các phần tăng trước đó.
Chương 2: Các mô hình vòng đời của phần
mềm
2.7 Rủi ro và các khía cạnh khác của lặp và tăng.
• Một cách khác để nhìn vào mô hình lặp và tăng dần là các dự án như một toàn
thể được chia thành các tiểu dự án nhỏ hơn (hoặc tương ứng với những phần
tăng).
• Mỗi lần lặp có thể được xem như là một mô hình thác nước nhỏ nhưng đầy đủ.
Mô hình lặp và tăng có thể được xem như là một loạt liên tiếp các mô hình thác
nước
Chương 2: Các mô hình vòng đời của phần
mềm
Mô hình lặp đi lặp lại và tăng có nhiều thế mạnh:
Cung cấp nhiều cơ hội để việc kiểm tra sản phẩm phần mềm là chính xác. Do đó tiết kiệm tiền
Sự vững mạnh của kiến ​trúc cơ bản có thể được xác định tương đối sớm trong chu kỳ phần mềm.
- Các kiến trúc này có tính chất mở rộng liên tục để kết hợp các phần tăng tiếp theo.
- Giúp nâng cao chất lượng trong kiểm thử và bảo trì.
- Dễ thay đổi yêu cầu cho là hợp lý.
Các mô hình lặp và tăng cho phép chúng tôi giảm thiểu rủi ro sớm.
Chúng tôi luôn luôn có một phiên bản làm việc được của phần mềm (áp dụng vào thực tế khi đang
còn phát triển và bảo trì).
Có bằng chứng thực nghiệm rằng mô hình lặp và tăng dần đã làm việc tốt trong nhiều dự án.
Chương 2: Các mô hình vòng đời của phần
mềm
2.8 Managing Iteration and Incrementation
Thoạt nhìn, các mô hình lặp và tăng hình 2.4 và 2.5 sẽ hoàn toàn hỗn loạn. Ngược
lại, mô hình lặp và tăng tổ chức như nhóm mô hình thác nước và là mô hình thác
nước được áp dụng liên tục
Chương 2: Các mô hình vòng đời của phần
mềm
2.9 Other Life-Cycle Models
2.9.1 Code-and-Fix Life-Cycle Model
• Không có yêu cầu hoặc thông số kỹ thuật, hoặc bất kỳ nổ lực ở khâu thiết kế mà chỉ
là ném mã lại với nhau và làm lại nhiều lần, đủ cần thiết để đáp ứng khách hàng.
• Hoạt động tốt trên các bài tập lập trình ngắn, hoàn toàn không đạt yêu cầu cho các
sản phẩm.
• Chi phí là thực sự lớn, bảo trì khó, nhưng cần thiết khi bắt đầu dự án, hay giúp lựa
chọn mô hình phần mềm.
• Mô hình Code-and-Fix là cách dễ nhất để phát triển phần mềm và là cách tồi tệ nhất.
Chương 2: Các mô hình vòng đời của phần
mềm
2.9.2 Waterfall Life-Cycle Model
• Giai đoạn không hoàn tất cho đến khi các tài liệu cho giai đoạn đó đã được hoàn
thành và các sản phẩm của giai đoạn đó đã được phê duyệt bởi nhóm đảm bảo chất
lượng phần mềm (SQA).
• Kiểm thử tiến hành liên tục trong suốt quá trình phần mềm. Đặc biệt, trong quá trình
bảo trì.
• Điểm mạnh: phương pháp xử lý kỷ luật thực thi.
• Điểm yếu: tài liệu kỹ thuật thường được viết bằng một phong cách mà khách hàng
là không quen thuộc. Sản phẩm thực không đúng yêu cầu khách. Vì thế, UML ra
đời, để vẽ lại các thông tin trong tài liệu cho khách hiểu.
Chương 2: Các mô hình vòng đời của phần
mềm
2.9.3 Rapid-Prototyping Life-Cycle Model
• Một mẫu nhanh là một mô hình làm việc, về mặt chức năng tương đương với
một tập hợp con của sản phẩm.
• Các thành viên của nhóm phát triển sử dụng các mẫu thử nghiệm nhanh để xây
dựng các tài liệu đặc tả.
• Thiết kế tương đối ổn tuy ít sử đổi lại vì rút kinh nghiệm từ mẫu thử.
• Giảm bớt sự cần thiết phải sửa chữa các thiết kế trong hoặc sau khi thực hiện.
Chương 2: Các mô hình vòng đời của phần
mềm
2.9.4 Open-Source Life-Cycle Model
• Tập trung để cài đặt phần “fix” trong phần mềm được giới hạn cho các thành viên
của nhóm nòng cốt. Nhóm thành viên ngoài chỉ giúp tìm lỗi. Lỗi đa số là sai.
• Phương châm ra phiên bản: “phát hành sớm, phát hành thường xuyên”.
• Phiên bản ban đầu được làm lại cho đến khi nó thỏa mãn mục tiêu sản phẩm. Theo
đó, trong một dự án mã nguồn mở, nói chung không có chi tiết kỹ thuật hoặc thiết
kế.
• Thu hút chuyên gia phần mềm tham gia.
• Mô hình nguồn mở đã rất thành công khi được sử dụng cho các dự án phần mềm cơ
sở hạ tầng nhất định.
• Khi đã làm thì thành công lắm: firefox, Linux…
Chương 2: Các mô hình vòng đời của phần
mềm
2.9.5 Agile Processes
• Lập trình cực hạn [Beck, 2000] là một cách tiếp cận mới gây tranh cãi, phát
triển phần mềm dựa trên mô hình lặp và tăng dần.
• Việc xây dựng được đề xuất chia thành các phần nhỏ hơn gọi là nhiệm vụ. Mỗi
nhiệm vụ do 1 cặp lập trình làm. Sau đó, các nhiệm vụ này được tích hợp vào
phiên bản hiện tại của sản phẩm.
• Các thành viên trong nhóm thay đổi mã code của các đối tác hàng ngày, nếu có
thể, học hỏi từ các thành viên khác, làm tăng mức độ kỹ năng của tất cả mọi
người.
• Ngoài ra, cặp lập trình luôn luôn không làm việc tốt với các cá nhân nhút nhát
hay độc đoán, hoặc với hai lập trình viên thiếu kinh nghiệm.
• Một nguyên tắc lập trình cực hạn là để giảm thiểu số lượng các tính năng,
không cần thiết phải xây dựng một sản phẩm mà không có nhiều hơn những gì
khách hàng thực sự cần.
Chương 2: Các mô hình vòng đời của phần
mềm
• Tiến trình Agile đặc trưng bởi sự ít nhấn mạnh về phân tích và thiết kế.
• Cung cấp phần mềm làm việc được 1 cách thường xuyên, tốt nhất là mỗi 2 hoặc
3 tuần nhờ sử dụng: “timeboxing”, “cuộc họp đứng”.
• Cả hai timeboxed và “cuộc họp đứng” là trường hợp của hai nguyên tắc cơ bản
làm nền tảng cho tất cả các phương pháp Agile: truyền thông, và đáp ứng nhu
cầu của khách hàng càng nhanh càng tốt.
• Thành công trong một số dự án quy mô nhỏ.
• Dữ liệu sơ bộ cho thấy rằng cấu trúc lại có thể tiêu thụ một tỷ lệ lớn của tổng
chi phí. Tuy nhiên, các thí nghiệm đã chỉ ra rằng các đặc tính nhất định của Tiến
trình Agile làm việc tốt: phát triển của mã code chất lượng cao hơn trong một
thời gian ngắn hơn. Một số tính năng áp dụng cho tương lai.
• Phù hợp khi yêu cầu khách hàng mơ hồ.
Chương 2: Các mô hình vòng đời của phần
mềm
2.9.6 Synchronize-and-Stabilize Life-Cycle Model
• Giai đoạn phân tích yêu cầu được thực hiện bằng cách phỏng vấn nhiều khách
hàng tiềm năng cho gói phần mềm và rút kết một danh sách các tính năng ưu
tiên cao nhất cho khách hàng.
• Sản phẩm được chia thành ba hay bốn công đoạn xây dựng: mỗi công đoạn thực
hiện bởi 1 số nhóm nhỏ thực hiện song song. Khi hoàn thành, sẽ gom lại và
đóng băng, chuyển qua công đoạn mới cho dù có lỗi phát sinh ở công đoạn
trước.
• Mô hình vòng đời có thể được sử dụng thậm chí nếu các dữ liệu kỹ thuật ban
đầu là không đầy đủ.
Chương 2: Các mô hình vòng đời của phần
mềm
2.9.7 Spiral Life-Cycle Model
•
Một cách để giảm thiểu một số loại rủi ro là xây dựng một nguyên mẫu.
•
Mẫu thử nghiệm kỹ thuật khác với mẫu thử ở mô hình mẫu.
•
Nếu không thể giảm thiểu tất cả các rủi ro đáng kể ở giai đoạn đó, dự án chấm dứt ngay lập tức sau đó
Chương 2: Các mô hình vòng đời của phần
mềm
•
•
•
Mẫu thử có thể được sử dụng hiệu quả để cung cấp thông tin về các lớp rủi ro nhất định.
Chi phí nhiều nhất là ở khâu phân tích rủi ro và phát triển, bảo mật sản phẩm như hình.
Góc phần tư phía dưới bên phải của mô hình xoắn ốc tương ứng với mô hình thác nước.
• Những hạn chế trên các ứng dụng
của mô hình xoắn ốc: mô hình
được thiết kế dành riêng cho phát
triển nội bộ của phần mềm ở quy
mô lớn; đội ngũ tài nghề cao cho
phân tích rủi ro; điểm yếu lớn của
mô hình xoắn ốc, cũng như mô
hình thác nước và mô hình tạo
mẫu nhanh, là giả định rằng phần
mềm được phát triển trong giai
đoạn rời rạc.
Chương 2: Các mô hình vòng đời của phần
mềm
2.10 Comparison of Life-Cycle Models
Chương 2: Các mô hình vòng đời của phần
mềm
Chương 15: More on UML
15.1 UML không là 1 phương pháp luận
UML là một ngôn ngữ mô hình hợp nhất, viết tắt Unified Modeling Language. Như
là 1 ngôn ngữ, UML sử dụng để mô tả phần mềm phát triển như thế nào, bằng việc
sử dụng sơ đồ truyền thống hoặc bất cứ sơ đồ hướng đối tượng nào: UP (Unified
Process). Hay UML là 1 tập các ký hiệu, không là phương pháp luận. Các ký hiệu
này sử dụng kết hợp với bất cứ phương pháp luận nào.
Chương 15: More on UML
15.2 Sơ đồ lớp
Chương 15: More on UML
15.2.1 Aggregation
Chương 15: More on UML
15.2.2 Multiplicity
Chương 15: More on UML
15.2.3 Composition
Chương 15: More on UML
15.2.4 Generalization
Chương 15: More on UML
15.2.5 Association
Chương 15: More on UML
15.3 Notes
Khi chúng ta muốn chú thích trong sơ đồ UML, chúng ta đặt trong
note (hình chữ nhật bên phải phía trên). Đường kẻ đứt đoạn từ ghi
chú đến đối tượng cần chú giải (trong hình 15.a).
Chương 15: More on UML
15.4 Sơ đồ use-case
Một sơ đồ use-case là 1 tập hợp các trường hợp sử dụng có trong hệ
thống. Trong hình 15.11 chỉ ra rằng 1 Manager là 1 trường hợp đặc
biệt của Employee và có mối quan hệ generalization.
Chương 15: More on UML
15.5 Stereotypes (Mẫu rập khuôn)
Chương 15: More on UML
15.6 Sơ đồ tương tác
Chương 15: More on UML
15.7 Biểu đồ trạng thái
Chương 15: More on UML
15.8 Sơ đồ hoạt động
Chương 15: More on UML
15.9 Packages
15.10 Sơ đồ thành phần
Chương 15: More on UML
15.11 Sơ đồ triển khai
Chương 6: Testing
6.1 Những vấn đề về chất lượng
6.1.1 Đảm bảo chất lượng phần mềm
• Vai trò nhóm SQA là thử nghiệm các sản phẩm của nhà phát triển
là chính xác.
• Đảm bảo chất lượng phần mềm chỉ là thử nghiệm cuối cùng cho
mọi công việc hoặc kết thúc của quá trình phát triển theo tiêu
chuẩn mà nhóm SQA định ra.
• Vai trò của nhóm SQA là đảm bảo chất lượng của quá trình làm
phần mềm và do đó đảm bảo chất lượng của sản phẩm.
Chương 6: Testing
6.1.2 Sự độc lập trong quản lý
• Nhóm SQA và nhóm phát triển phải độc lập với nhau.
• Nếu cùng làm trong 1 nhóm, thì mỗi thành viên sẽ phải quản lý 2
công việc cùng lúc. Khi đó, việc đảm bảo chất lượng sẽ giảm.
Ngoài ra, nếu độc lập với nhau, nhóm SQA có thêm 1 người quản
lý, giúp việc đảm bảo có chuyên môn cao.
Chương 6: Testing
6.2 Kiểm thử không dựa trên thực nghiệm
6.2.1 Walkthroughs
• Walkthroughs và Inspections là hai loại ý kiến​​. Sự khác biệt cơ bản giữa chúng
là walkthroughs có bước ít hơn và ít chính thức hơn so với kiểm tra.
• Một nhóm Walkthrough nên bao gồm 4-6 cá nhân: 1 người chịu trách nhiệm
phác thảo các đặc tả kỹ thuật, 1 quản lý có trách nhiệm trong khâu phân tích, 1
đại diện khách hàng, 1 đại diện nhóm thiết kế, 1 đại diện của nhóm SQA làm
chủ đội thử nghiệm.
• Các thành viên của nhóm Walkthroughs nên có càng nhiều kinh nghiệm kỹthuật
càng tốt bởi vì họ thường tìm những lỗi quan trọng.
• Phân phối đọc trước tài liệu để phát hiện khó hiểu, hay kiểm tra không chính
xác.
Chương 6: Testing
6.2.2 Managing Walkthroughs
Có 2 cách thực hiện walkthroughs: tham gia điều khiển của các thành
viên trong nhóm SQA với tài liệu để thấy lỗi 1 cách chính xác; cách
thứ 2 là tiến hành rà soát điều khiển tài liệu. Cách 2 phát hiện nhiều
lỗi hơn.
Chương 6: Testing
6.2.3 Inspections
• Inspection là giám định, kiểm tra phần thiết kế và lập trình.
• Mục đích của viêc giám định là tìm kiếm, phát hiện lỗi trong tài liệu, không
phải cách khắc phục lỗi.
• Có bảng liệt kê các lỗi có thể xảy ra.
• Có bảng ghi thống kê các khuyết điểm.
• Đội giám định sử dụng bảng liệt kê các câu hỏi để hỗ trợ trong việc tìm ra các
khuyết điểm.
• Việc giám định gồm 5 bước: xem xét tổng quát, chuẩn bị, giám định, xem xét
lại, theo dõi.
• Quá trình giám định tốn nhiều thời gian hơn kiểm thử.
Chương 6: Testing
6.2.4 Comparison of Inspections and Walkthroughs
• Walkthroughs phát hiện khuyết điểm 1 cách có phương pháp.
• Inspections tìm kiếm phát hiện lỗi trong tài liệu, không khắc phục lỗi. Chi tiết,
tốn thời gian hơn. Có 1 danh sách kiểm tra lỗi.
• Walkthroughs là 1 quá trình gồm 2 bước: sự chuẩn bị, tiếp theo phân tích tài
liệu. Còn Inspections là 1 quá trình 5 bước: tổng quan, chuẩn bị, kiểm tra, làm
lại và theo dõi, và sau mỗi bước các thủ tục được hợp thức hóa. Ví dụ của việc
hợp thức hóa đó là phương pháp phân loại lỗi và sử dụng thông tin đó trong
việc kiểm tra các văn bản của những workflow thành công cũng như việc kiểm
tra của những sản phẩm tương lai.
Chương 6: Testing
6.2.5 Nhận xét điểm mạnh và điểm yếu
Có 2 ưu điểm chính của 1 bài nhận xét, đánh giá (hướng dẫn hoặc kiểm tra). Thứnhất, 1 bài
nhận xét có hiệu quả là phát hiện ra lỗi, thứ 2 là, lỗi được phát hiện sớm trong software
process, trước khi chúng trở nên tốn kém để sửa chữa. Ví dụ, lỗi thiết kế được phát hiện
trước khi đưa vào triển khai, và các lỗi code được tìm thấy trước khi bản phác thảo được
thực hiện trên sản phẩm.
Tuy nhiên, hiệu quả của 1 bài đánh giá có thể giảm nếu phần mềm là ko đầyđủ, phù hợp.
• Thứ nhất, phần mềm quy mô lớn là rất khó để đánh giá, trừ khi nó bao gồm nhiều thành
phần nhỏ hơn và phần lớn là độc lập với nhau. Ưu điểm của mô hình hướng đối tượng là:
nếu thực hiện 1 cách chính xác thì kết quả sản phẩm là tậphợp của nhiều thành phần độc lập.
• Thứ 2, 1 nhóm đánh giá thiết kế đôi khi tham khảo các bản phác thảo phân tích, nhóm
đánh giá mã code cần thường xuyên truy cập vào các tài liệu thiết kế. Trừ khi, các tài liệu
của các workflow trước đó được hoàn thành, cập nhật để phản ánh các phiên bản hiện tại
của dự án.
6.2.6 Thước đo cho Inspections là: số trang trong tài liệu.
Chương 6: Testing
6.3 Kiểm thử dựa trên thực nghiệm
Người ta đã khẳng định rằng thực nghiệm là một minh chứng rằng lỗi ("bugs")
không được thể hiện.Mặc dù một số tổ chức chi tiêu lên đến 50% ngân sách phần
mềm của họ cho thực nghiệm.
Lý do cho mâu thuẫn này là đơn giản. Dijkstra nói rằng, nếu một sản phẩm được
thực hiện với dữ liệu thử nghiệm và đầu ra là sai, sau đó sản phẩm chắc chắn có
chứa một lỗi.Tuy nhiên, nếu đầu ra là chính xác, khi đó vẫn có thể là một lỗi trong
sản phẩm, thông tin duy nhất có thể được rút ra từ đó là kiểm tra cụ thể sản phẩm
chạy chính xác trên tập hợp các dữ liệu thử nghiệm đó.
Chương 6: Testing
6.4 What Should Be Tested?
6.4.1 Tính tiện dụng
Tiện ích là mức độ nhu cầu của người dùng được đáp ứng khi một sản phẩm được
sử dụng đúng theo tài liệu đặc tả. Nói cách khác, một sản phẩm được hoạt động
một cách chính xác với các trạng thái của tài liệu đặc tả. Người sử dụng có thể
kiểm tra, ví dụ, sản phẩm được sử dụng dễ dàng, cho dù sản phẩm sử dụng tất cả
các chức năng, và chi phí cho sản phẩn là cạnh tranh so với các sản phản khác trên
thị trường.
Không phân biệt cho dù sản phẩm là chính xác hay không, những vấn đề quan
trọng phải được kiểm tra. Nếu chi phí cho sản phẩm không hợp lý và sau đó là ko
có người mua nó, trừ khi sản phẩm dễ sử dụng, nếu ko nó sẽ không được sử dụng
hoặc nó sẽ được sử dụng không chính xác. Vì vậy, khi cân nhắc mua một sản phẩm
hiện có (bao gồm cả phần mềm đóng gói), tiện ích của sản phẩm phải được kiểm
tra , và nếu sản phẩm không thành công , thử nghiệm nên dừng lại.
Chương 6: Testing
6.4.2 Độ tin cậy
Một khía cạnh khác của một sản phẩm phải được thử nghiệm là độ tin cậy của nó.
Nhắc lại rằng thất bại là không thể chấp nhận, trong những điều kiện cho phép, xảy
ra do hậu quả của một lỗi. Khi một sản phẩm thất bại, vấn đề quan trọng là phải
mất bao lâu, trung bình, để sửa chữa nó (có nghĩa là thời gian để sửa chữa). Giả sử
rằng các phần mềm chạy trên một hệ thống thông tin liên lạc không thành công nó
sẽ xóa sạch cơ sở dữ liệu. Tốt nhất, thực sự đáng tin cậy khi thực hiện, cơ sở dữ
liệu được kiểm soát cuối cùng.
Chương 6: Testing
6.4.3 Tính vững chắc
Vấn đề kiểm tra tính mạnh mẽ của sản phẩm. Mặc dù rất khó khăn để định nghĩa
chính xác, mạnh mẽ của chức năng của một số yếu tố, chẳng hạn như phạm vi của
điều kiện hoạt động, khả năng kết quả không thể chấp nhận được với đầu vào hợp
lệ, và sự chấp nhận khi đầu vào sản phẩm không hợp lệ. Một sản phẩm với một loạt
các điều kiện hoạt động cho phép là mạnh hơn so với một sản phẩm hạn chế hơn.
Để kiểmtra cho khía cạnh này, dữ liệu thử nghiệm được cố ý nhập vào không đáp
ứng yêu cầu kĩ thuật, và thử nghiệm xác định làm thế nào sản phẩm phản ứng xấu.
Chương 6: Testing
6.4.4 Tính thực thi
Tính thực thi là một khía cạnh của sản phẩm phải được kiểm tra. Điều đó là cần
thiết để biết mức độ hạn chế của sản phẩm trong thời gian phản hồi lại hoặc trong
yêu cầu về không gian. Vídụ, một hệ thống điều khiển lò phản ứng hạt nhân có thể
phải lấy mẫu nhiệt độ của lõi và xử lý dữ liệu 10/1 giây. Nếu hệ thống không đủ
nhanh để xử lý ngắt các cảm biến nhiệt độ 10 lần trong một giây, thì sau đó dữ liệu
bị mất, và không có cách nào có thể phục hồi dữ liệu, trong thời gian tiếp theo hệ
thống nhận được dữ liệu nhiệt độ, nó sẽ là nhiệt độ hiện tại, nhiệt độ không đọc
được sẽ bị bỏ qua. Nếu lò phản ứng đang đứng trên bờ vực của cuộc khủng hoảng,
sau đó điều quan trọng là tất cả các thông tin có liên quan đều nhận được và xử lý
như đã nêu trong các thông số kỹ thuật. Với tất cả các hệ thống thời gian thực, hiệu
quả hoạt động phải đáp ứng tất cả các eo hẹp về thời gian được liệt kê trong các chi
tiết kỹ thuật.
6.4.5 Tính đúng đắn
Hậu quả của lỗi yêu cầu kỹ thuật là không tầm thường. Sau tất cả, đúng đắn của
một sản phẩm vô nghĩa nếu yêu cầu kỹ thuật của nó là không chính xác.
Chương 6: Testing
6.6 Who Should Perform Execution-Based Testing?
Nên là người khác kiểm thử code của một ai đó. Khi lỗi xảy ra, ai viết người đó
sửa. Nhóm SQA sẽ đảm nhiệm trọng trách này. Tuy nhiên, cũng có hạn chế khi
người khác kiểm thử là khó tìm lỗi theo bài bản, hoặc có những lỗi còn tồn động.
Chính vì thế, bảo trì mới cần cho suốt quá trình triển khai.
6.7 When Testing Stops
Sau khi sản phẩm đã được bảo trì thành công trong nhiều năm, nó cuối cùng có thể
mất đi tínhhữu dụng của nó và được thay thế bởi một sản phẩm hoàn toàn khác
nhau, giống như cách thay thế van điện tử bằng bóng bán dẫn. Ngoài ra, một sản
phẩm vẫn có thể hữu ích, nhưng chi phí thay đổi phần cứng mới hoặc chạy theo
một hệ điều hành mới, nhiều chi phí xây dựng một sản phẩm mới, bằng cách sử
dụng bản cũ như một nguyên mẫu. Vì vậy, cuối cùng, các sản phẩm phần mềm
được ngừng hoạt động và loại bỏ. Chỉ vào thời điểm đó, khi phần mềm đã được bỏ
đi không thể thay đổi, đó là thời gian để dừng thử nghiệm.