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

1. 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ấtkhác nhau trong thực tế vì hai lý do. Đầu tiên, các chuyên gia phần mềm cũnglà con người, do đó sẽmắc những sai lầm. Thứ hai, yêu cầu củakhách hàng có thể thay đổi trong khi phần mềm được phát triển.

2. 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ộngchỉcólànđườngchoxebuýt , thịtrưởngvùngkhuyến khích "park and ride”. Mỗi xe buýt là có một máy bánvé, yêucầu: chỉ chấp nhận tiềnlàđô la, sử dụng một thuật toán nhận dạng hình ảnh, máybánvé phảichính xác, đápứngnhanh. Chínhvìthế, phầnmềmlàm qua 4 Episode ,mớixemnhưkháhoànhảobằngmôhìnhtiếnhóa.

3. 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.

4. Chương 2: Các mô hình vòng đời của phần mềm 2.3Lessons of the Winburg Mini Case Study Một kếhoạchthự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êucầ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ếtquả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.

5. Chương 2: Các mô hình vòng đời của phần mềm 2.4Teal Tractors Mini Case Study Teal Tractors mua một công ty máy kéo ở Canada. Việc quản lý củacôngtyTeal Tractors quyết định rằng, để tiết kiệm tiền, các hoạt động ở Canada được tích hợp vớicá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ớixuấthiện hay thayđổi. phải được mở rộng để xử lý hai loại tiền tệ khác nhau. Việcthay đổ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ínhvìthế, ta phảicó 1 môhìnhthíchứngvớitrạngtháithayđổithườngxuyên, làmôhìnhlặpvàtăngdần.

6. Chương 2: Các mô hình vòng đời của phần mềm 2.5 Iteration and Incrementation (lặpvàtăngdần) Môhìnhtươngtựnhưcác mô hình tiến hóa hoặcmôhìnhthácnước (nhưgiảđịnh). Việcsảnxuấtraphiênbảnnàyđếnphiênbảnkháctừcáctàiliệu ban đầuđếntàiliệuchỉnhsửahoànchỉnh, giúpngàycàngphùhợpvớimụctiêuđềra.Gọilàlặp. Nhữnghạnchếcủaluật Miller: mỗichúng ta chỉtậptrungkhoảng 7 chunks tại 1 thờiđiểm. Nêntấtcảyêucầucũngkhôngthểlàmhếttrong 1 khoảngthờigian. Chínhvìthế, thờiđiểmnày ta làm 7 yêucầuquantrọngnhất; thờigiansaulàmtiếp 7 cáiquantrọngtiếptheothứtự. Việcsảnxuấtphầnmềmtuântheomôhìnhtăngcũngvậy. Sảnphẩmtừng bướcđượccảitiến. Lăpvàtăngcótỉlệrấtkhácnhau ở mỗithờiđiểmtrongchukyphầnmềm. Vàlênkếhoạch, làmtàiliệu, kiểmthửluônluônthựchiệnxuyênsuốt.

7. Chương 2: Các mô hình vòng đời của phần mềm Trongthựctế, lặpvàtăngkếthợpvớinhau. Mộttàiliệucuối được xây dựng qua từngmảnh (tăng), và mỗilầntăng đi quanhiều phiên bản (lặp).

8. Chương 2: Các mô hình vòng đời của phần mềm 2.6 Nhìnlạitrườnghợpnghiêncứunhỏ ở Winburg: ta thấy Các mô hình lặp và tăng không yêu cầu mỗi luồngphảiđược thực hiện trong mỗi phầntăng. Cácluồngcóthểchấmdứtbấtkỳlúcnàokhithấythựchiệnkhôngđạt. Ba mũi tênđứtđoạn của mô hình tiến hóa, chỉrằngmỗiphầntăngnàyđượccấu thànhtừbảo trì cácphầntăng trước đó.

9. Chương 2: Các mô hình vòng đời của phần mềm 2.7 Rủirovàcáckhíacạnhkháccủalặpvàtăng. Một cách khác để nhìn vàomôhình lặp vàtăngdầnlà các dự án như một toàn thể được chia thành các tiểu dự án nhỏ hơn (hoặctươngứngvớinhữngphầntă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

10. 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ệckiể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ầnmềm. Cáckiếntrúcnàycó tínhchấtmởrộngliên tụcđể kết hợp các phầntăng tiếp theo. Giúpnângcaochấtlượngtrongkiểmthửvàbảotrì. Dễthayđổiyêucầucholàhợplý. 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 (ápdụngvàothựctếkhiđangcònpháttriểnvàbảotrì). Có bằng chứng thực nghiệm rằng môhìnhlặp và tăngdầnđãlàmviệctốttrongnhiềudựán.

11. 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

12. 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ảotrìkhó, nhưngcầnthiếtkhibắtđầudựán, hay giúplựachọnmôhìnhphầnmề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.

13. 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ởinhóm đảm bảo chất lượng phần mềm (SQA). Kiểmthử 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ểmyế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ảnphẩmthựckhôngđúngyêucầukhách. Vìthế, UML rađời, đểvẽlạicácthông tin trongtàiliệuchokháchhiểu.

14. 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ặtchứ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ổntuyítsửđổilạivìrútkinhnghiệmtừmẫuthử. 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.

15. 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ậptrungđể cài đặt phần “fix” trongphần mềm được giới hạn cho các thành viên của nhóm nòng cốt. Nhómthànhviênngoàichỉgiúptìmlỗi. Lỗiđasốlàsai. Phươngchâmraphiênbả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ỏamãnmụ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útchuyêngiaphầnmềmthamgia. 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àmthìthànhcônglắm: firefox, Linux…

16. 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ăngdầ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ỗinhiệmvụ do 1 cặplậptrìnhlà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ủacá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.

17. 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ồ.

18. 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útkếtmộ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ạnxâydựng: mỗicôngđoạnthựchiệnbởi 1 sốnhómnhỏthựchiện song song. Khihoànthành, sẽgomlạivàđóngbăng, chuyển qua côngđoạnmớichodùcólỗiphátsinh ở côngđoạntrướ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 đủ.

19. 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ậtkhácvớimẫuthử ở môhìnhmẫ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 đó

20. Chương 2: Các mô hình vòng đời của phần mềm 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; độingũtàinghềcaochophântíchrủiro; đ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. Mẫuthử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ềunhấtlà ở khâuphântíchrủirovàpháttriển, bảomậtsảnphẩmnhư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.

21. Chương 2: Các mô hình vòng đời của phần mềm 2.10 Comparison of Life-Cycle Models

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

23. 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.

24. Chương 15: More on UML 15.2 Sơ đồ lớp

25. Chương 15: More on UML 15.2.1 Aggregation

26. Chương 15: More on UML 15.2.2 Multiplicity

27. Chương 15: More on UML 15.2.3 Composition

28. Chương 15: More on UML 15.2.4 Generalization

29. Chương 15: More on UML 15.2.5 Association

30. 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).

31. 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.

32. Chương 15: More on UML 15.5 Stereotypes (Mẫu rập khuôn)

33. Chương 15: More on UML 15.6 Sơ đồ tương tác

34. Chương 15: More on UML 15.7 Biểu đồ trạng thái

35. Chương 15: More on UML 15.8 Sơ đồ hoạt động

36. Chương 15: More on UML 15.9 Packages 15.10 Sơ đồ thành phần

37. Chương 15: More on UML 15.11 Sơ đồ triển khai

38. 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.

39. 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.

40. 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.

41. 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.

42. 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ử.

43. 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.

44. 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.

45. 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 đó.

46. 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.

47. 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.

48. 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.

49. 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.

50. 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.