I Các mô hình phát triển phần mềm Mô hình thác nước– Waterfall Model Do nhà khoa học Mỹ W.W.Royce đưa năm 1970 Quá trình phát triển phần mềm coi dòng chảy trải qua pha: yêu cầu, phân tích, thiết kế, cài đặt, tích hợp bảo trì Các pha mô hình thác nước bao gồm: • Phân tích xác định yêu cầu • Thiết kế hệ thống phần mềm • Cài đặt kiểm thử đơn vị • Tích hợp kiểm thử hệ thống • Vận hành bảo trì Năm pha phải thực cách tuần tự; kết thúc pha trước, thực pha Nhược điểm mô hình thác nước khó khăn việc thay đổi pha thực Thích hợp yêu cầu tìm hiểu rõ ràng thay đổi giới hạn cách rõ ràng suốt trình thiết kế Mô hình xây dựng tiến triển Ý tưởng xây dựng mẫu thử ban đầu đưa cho người sử dụng xem xét; sau đó, tinh chỉnh mẫu thử qua nhiều phiên thoả mãn yêu cầu người sử dụng dừng lại Có hai phương pháp để thực mô hình này: - Phát triển thăm dò: mục đích để làm việc với khách hàng để đưa hệ thống cuối từ đặc tả sơ ban đầu Phương pháp thường bắt đầu thực với yêu cầu tìm hiểu rõ ràng sau đó, bổ sung đặc điểm đề xuất khách hàng Cuối cùng, yêu cầu người sử dụng thoả mãn lúc xây dựng xong hệ thống - Loại bỏ mẫu thử: mục đích để tìm hiểu yêu cầu hệ thống Phương pháp thường bắt đầu với yêu cầu không rõ ràng thông tin Các mẫu thử xây dựng chuyển giao tới cho người sử dụng Từ đó, ta phân loại yêu cầu thực cần thiết lúc mẫu thử không cần thiết Như vậy, mẫu thử có tác dụng để làm sáng tỏ yêu cầu người sử dụng Nhược điểm: thiếu tầm nhìn quy trình; hệ thống thường hướng cấu trúc nghèo nàn; yêu cầu kỹ đặc biệt (Ví dụ: ngôn ngữ để tạo mẫu thử nhanh chóng) Chỉ nên áp dụng với hệ thống có tương tác mức độ nhỏ vừa; phần hệ thống lớn; hệ thống có thời gian chu kỳ tồn ngắn Công nghệ phần mềm dựa thành phần Dựa kỹ thuật tái sử dụng cách có hệ thống; hệ thống tích hợp từ nhiều thành phần tồn thành phần thương mại COTS (Commercial-off-the-shelf) Các trạng thái quy trình bao gồm: - Phân tích thành phần sẵn có - Điều chỉnh yêu cầu - Thiết kế hệ thống với kỹ thuật tái sử dụng - Xây dựng tích hợp hệ thống Mô hình phát triển lặp lại tăng them Dựa ý tưởng thay phải xây dựng chuyển giao hệ thống lần chia thành nhiều vòng, tăng dần Mỗi vòng phần kết chức yêu cầu Các yêu cầu người sử dụng đánh thứ tự ưu tiên Yêu cầu có thứ tự ưu tiên cao vòng phát triển sớm Ưu điểm: - Sau lần tăng vòng chuyển giao kết thực cho khách hành nên chức hệ thống nhìn thấy sớm - Các vòng trước đóng vai trò mẫu thử để giúp tìm hiểu thêm yêu cầu vòng - Những chức hệ thống có thứ tự ưu tiên cao kiểm thử kỹ Mô hình xoắn ốc Được đề xuất năm 1988 Là kết hợp khía cạnh mô hình Bản chất mô hình xoắn ốc tên gọi nó, khái quát dần đến chi tiết Trong mô hình này, quy trình phát triển phần mềm biểu diễn vòng xoắn ốc Mỗi vòng lặp đại diện cho pha trình phần mềm Vòng tập trung tính khả thi, vòng kế lo định nghĩa yêu cầu, thiết kế, pha xem cố định vòng xoắn Mỗi vòng có phần tương ứng với pha Các pha quy trình phát triển xoắn ốc bao gồm: - Thiết lập mục tiêu: xác định mục tiêu cho pha dự án - Đánh giá giảm thiểu rủi ro: rủi ro đánh giá thực hành động để giảm thiểu rủi ro - Phát triển đánh giá: sau đánh giá rủi ro, mô hình xây dựng hệ thống lựa chọn từ mô hình chung - Lập kế hoạch: đánh giá dự án pha mô hình xoắn ốc lập kế hoạch Nhận xét: - Là cách tiếp cận thực tế cho việc phát triển phần mềm quy mô lớn Phần mềm tiến hóa theo đường xoắn ốc, từ tổng quan đến chi tiết, nên người phát triển khách hàng hiểu rõ có phản ứng thích hợp với rủi ro mức tiến hóa - Tuy nhiên cần ý mô hình lựa chọn tốt cho dự án Và thân chưa áp dụng rộng rãi mô hình thác nước, hay mô hình làm mẫu Chương 2: Quy trình xây dựng phần mềm Quy trình phần mềm - Quy trình làm phần mềm (software process – quy trình phần mềm) trình tạo phần mềm Quy trình kết hợp mô hình vòng đời phần mềm, công cụ sử dụng quan trọng hết người xây dựng nên phần mềm II Các hoạt động quy trình phần mềm Quy trình phần mềm gồm hoạt động bản: - Đặc tả: chức hệ thống ràng buộc vận hành hệ thống cần phải xác định cách đầy đủ chi tiết - Thiết kế cài đặt: phần mềm xây dựng phải thoả mãn đặc tả - Đánh giá: phần mềm phải đánh giá thẩm định để đảm bảo thoả mãn tất yêu cầu - Cải tiến: phần mềm cần phải cải tiến điều chỉnh để phù hợp với thay đổi yêu cầu hệ thống Với mô hình khác hoạt động tổ chức theo cách khác Ví dụ, mô hình thác nước, chúng tổ chức cách Trong mô hình tiến triển, hoạt động gối lên Trong phần tiếp sau đây, nghiên cứu cụ thể hoạt động Đặc tả phần mềm Đặc tả phần mềm (hay gọi kỹ thuật xác định yêu cầu) quy trình tìm hiểu định nghĩa dịch vụ yêu cầu ràng buộc trình vận hành xây dựng hệ thống Quy trình xác định yêu cầu bao gồm bốn pha chính: - Nghiên cứu khả thi: công nghệ, lợi nhuận, Kết việc nghiên cứu khả thi xác định có nên tiếp tục xây dựng hệ thống hay không - Phân tích rút yêu cầu: quy trình đưa yêu cầu hệ thống thông qua số phương pháp như: quan sát hệ thống tại, vấn thảo luận với người sử dụng, phân tích nhiệm vụ, phân tích tài liệu hệ thống cũ … - Đặc tả yêu cầu: tư liệu hoá thông tin thu thập Có hai loại yêu cầu cần xác định: + Yêu cầu người sử dụng: yêu cầu ngôn ngữ tự nhiên bổ sung thêm cho biểu đồ dịch vụ mà hệ thống cung cấp ràng buộc vận hành + Yêu cầu hệ thống: tài liệu có cấu trúc mô tả chi tiết chức năng, dịch vụ ràng buộc vận hành hệ thống Yêu cầu hệ thống định nghĩa cần phải xây dựng, trở thành hợp đồng khách hàng nhà thầu - Đánh giá yêu cầu: kiểm tra lại yêu cầu xem chúng có thực tế, thống nhất, đầy đủ Nếu phát lỗi ta phải chỉnh sửa lỗi Thiết kế phần mềm cài đặt Thiết kế phần mềm trình thiết kế cấu trúc phần mềm dựa tài liệu đặc tả Hoạt động thiết kế bao gồm công việc sau: - Thiết kế kiến trúc: Các hệ thống cấu thành lên hệ thống cần xây dựng mối quan hệ chúng xác định tư liệu hoá - Đặc tả trừu tượng: với hệ thống con, phải có đặc tả dịch vụ ràng buộc vận hành - Thiết kế giao diện: với hệ thống con, giao diện với hệ thống khác phải thiết kế tư liệu hoá - Thiết kế thành phần: dịch vụ cung cấp cho thành phần khác giao diện tương tác với chúng phải thiết kế - Thiết kế cấu trúc liệu: cấu trúc liệu sử dụng để cài đặt hệ thống phải thiết kế cách chi tiết cụ thể - Thiết kế thuật toán: Các thuật toán sử dụng để cung cấp dịch vụ phải thiết kế chi tiết xác Cài đặt quy trình chuyển đổi từ tài liệu đặc tả hệ thống thành hệ thống thực, vận hành phải loại bỏ lỗi chương trình Lập trình hành động cá nhân, quy trình lập trình chung Người lập trình phải thực số kiểm thử để phát lỗi chương trình loại bỏ quy trình gỡ lỗi Đánh giá phần mềm Đánh giá phần mềm hay gọi thẩm tra đánh giá (V&V - Verification and validation) sử dụng để hệ thống thực theo đặc tả thoả mãn yêu cầu khách hàng Đánh giá phần mềm bao gồm công đoạn: kiểm tra, xem xét lại, kiểm thử hệ thống Kiểm thử hệ thống tức cho hệ thống thực trường hợp có liệu thật lấy từ tài liệu đặc tả hệ thống Quy trình kiểm thử gồm pha sau: - Kiểm thử thành phần (đơn vị): thành phần kiểm thử cách độc lập, thành phần chức đối tượng nhóm thực thể gắn kết với - Kiểm thử hệ thống: kiểm thử toàn hệ thống - Kiểm thử chấp thuận: kiểm thử liệu khách hàng để kiểm tra hệ thống có đáp ứng tất yêu cầu khách hàng hay không Khi chuyển giao hệ thống cho khách hàng quy trình kiểm thử beta thực Khách hàng thông báo lỗi cho đội dự án Những lỗi chỉnh sửa tiếp tục kiểm thử beta chuyển giao thực cho khách hàng Cải tiến phần mềm Khi yêu cầu hệ thống thay đổi theo thay đổi yêu cầu nghiệp vụ phần mềm phải cải tiến thay đổi để hỗ trợ khách hàng Thông thường chi phí để bảo trì cải tiến thường đắt nhiều so với chi phí xây dựng phần mềm III Các nguyên tắc làm phần mềm Đảm bảo tính đắn - Chính xác mục tiêu, chức đề xuất giai đoạn thiết kế (thuật toán đúng) - Tính tương đương chương trình thuật toán - Tính chương trình (kiểm thử áp dụng thời gian đủ lớn tần suất sử dụng cao) - Phải có luận chứng kết xác nhận tính đắn chương trình Tính khoa học - Khoa học cấu trúc - Khoa học nội dung - Khoa học hình thức, thao tác - Khoa học thể việc thong báo lỗi Tính đầy đủ : Đánh giá qua chức phần mềm cung cấp - Đảm báo tính đối xứng - Đảm bảo tính tiêu chuẩn - Đảm bảo tính toàn vẹn Tính độc lập : cần nên độc lập với thiết bị, cấu trúc nội dung đối tượng, Dễ phát triển IV Yêu cầu hệ thống Các yêu cầu hệ thống phần mềm thường chia thành ba loại: yêu cầu chức năng, yêu cầu phi chức yêu cầu miền ứng dụng Tuy nhiên, thực tế khó phân biết ba loại yêu cầu cách rõ ràng Yêu cầu chức Yêu cầu chức mô tả hệ thống làm Nó mô tả chức dịch vụ hệ thống cách chi tiết Đặc điểm yêu cầu chức năng: Tính mập mờ, không rõ ràng yêu cầu: Vấn đề xảy yêu cầu không xác định cách cẩn thận Các yêu cầu mập mờ người xây dựng người sử dụng hiểu theo nhiều cách khác Tính hoàn thiện quán: Về nguyên tắc, yêu cầu phải chứa tất mô tả chi tiết xung đột đối ngược yêu cầu Tuy nhiên, thực tế khó đạt điều Yêu cầu phi chức Không đề cập trực tiếp tới chức cụ thể hệ thống; Thường định nghĩa thuộc tính như: độ tin cậy, thời gian đáp ứng, yêu cầu lưu trữ …và ràng buộc hệ thống như: khả thiết bị vào/ra, giao diện … Một số yêu cầu phi chức có liên quan đến quy trình xây dựng hệ thống Ví dụ: chuẩn sử dụng, công cụ CASE, ngôn ngữ lập trình … Các yêu cầu phi chức hạn chế yêu cầu chức Nhưng không thoả mãn hệ thống không sử dụng Các yêu cầu phi chức xuất yêu cầu người sử dụng, ràng buộc ngân sách, sách tổ chức sử dụng hệ thống, yêu cầu tương thích phần cứng phần mềm tác nhân khác Do đó, phân loại yêu cầu phi chức sau: Các yêu cầu sản phẩm xác định ứng xử sản phẩm như: hiệu năng, khả sử dụng, độ tin cậy … sản phẩm - Các yêu cầu tổ chức: yêu cầu lấy từ sách quy tắc khách hàng tổ chức sử dụng hệ thống - Các yêu cầu ngoài: xác định từ tác nhân hệ thống - Nói chung, khó xác định xác khó thẩm tra yêu cầu phi chức mập mờ Do đó, tài liệu đặc tả yêu cầu, người ta thường bổ sung mục tiêu - Mục tiêu hữu ích người phát triển hệ thống truyền tải mong muốn người sử dụng hệ thống Còn với yêu cầu phi chức thẩm định yêu cầu kiểm thử cách khách quan - Tuy nhiên, nhiều trường hợp thường xảy xung đột yêu cầu phi chức hệ thống phức tạp - Được xác định từ miền ứng dụng hệ thống phản ánh thuộc tính ràng buộc miền ứng dụng Nó yêu cầu chức phi chức - Nếu yêu cầu miền ứng dụng không thoả mãn hệ thống không làm việc - Một số vấn đề liên quan đến yêu cầu miền ứng dụng: + Khả hiểu được: yêu cầu biểu diễn ngôn ngữ lĩnh vực ứng dụng + Ẩn ý: Các chuyên gia có hiểu biết lĩnh vực họ họ cách xây dựng yêu cầu miền ứng dụng cách rõ ràng, mang tính kỹ thuật Một số kỹ thuật đặc tả yêu cầu hệ thống a) Ngôn ngữ tự nhiên Ngôn ngữ tự nhiên thường sử dụng để viết đặc tả yêu cầu hệ thống yêu cầu người sử dụng Tuy nhiên, yêu cầu hệ thống thường chi tiết yêu cầu người sử dụng nên đặc tả ngôn ngữ tự nhiên thường gặp số vấn đề sau: - Không rõ ràng: Người đọc người viết yêu cầu phải giải thích từ theo nghĩa Ngôn ngữ tự nhiên có chất mập mờ nên để đạt yêu cầu khó khăn - Quá mềm dẻo: với vấn đề có nhiều cách khác để đặc tả - Thiếu khả mô-đun hoá: cấu trúc ngôn ngữ tự nhiên không tương xứng với cấu trúc yêu cầu hệ thống b) Đặc tả ngôn ngữ hướng cấu trúc Sử dụng ngôn ngữ hướng cấu trúc yêu cầu người viết đặc tả tuân theo mẫu định nghĩa trước Tất yêu cầu viết theo chuẩn thuật ngữ sử dụng bị hạn chế Ưu điểm phương pháp đạt mức độ diễn tả cao ngôn ngữ tự nhiên mức độ đồng lại bị lạm dụng đặc tả c) Đặc tả dựa biểu mẫu (Form-based) Đặc tả dựa biểu mẫu định nghĩa chức thực thể, mô tả đầu vào nơi xuất phát nó, mô tả đầu nơi đến Đặc tả dựa biểu mẫu rõ thực thể cần thiết, điều kiện trước sau (nếu thích hợp), ảnh hưởng chức d) Biểu đồ trình tự Biểu đồ trình tự biểu diễn trình tự kiện xảy người sử dụng tương tác với hệ thống Nếu ta đọc biểu đồ từ đầu đến cuối ta thấy thứ tự hành động thực V Thiết kế tổng thể tổ chức hệ thống Thiết kế tổng thể Thiết kế tổng thể có tên gọi khác thiết kế kiến trúc, thiết kế logic, thiết kế mức cao Quy trình thiết kế nhằm xác định hệ thống cấu tạo nên hệ thống đề xuất framework giúp điều khiển hệ thống giao tiếp chúng gọi quy trình thiết kế kiến trúc Kết quy trình thiết kế đặc tả kiến trúc phần mềm Thiết kế kiến trúc pha sớm quy trình thiết kế hệ thống Thiết kế kiến trúc thường thực song song với số hành động đặc tả Nó bao gồm có việc phát thành phần hệ thống giao tiếp chúng Ưu điểm thiết kế kiến trúc: Giao tiếp người tham dự vào dự án xây dựng hệ thống: kiến trúc hệ thống thường sử dụng làm tâm điểm buổi thảo luận họ Phân tích hệ thống: tức phân tích để xác định liệu hệ thống có thoả mãn yêu cầu phi chức hay không Tái sử dụng với quy mô lớn: kiến trúc tái sử dụng nhiều hệ thống Các đặc điểm kiến trúc hệ thống: Hiệu năng: hạn chế thao tác phức tạp tối thiểu hoá giao tiếp Bảo mật: sử dụng kiến trúc phân lớp với nhiều kiểm soát chặt chẽ lớp sâu An toàn Sẵn dùng Có khả bảo trì Trong trình thiết kế kiến trúc xảy xung đột mặt kiến trúc sau: Sử dụng nhiều thành phần lớn tăng hiệu giảm khả bảo trì Nếu liệu bị dư thừa cải thiện tính sẵn dùng làm cho việc bảo mật khó khăn Hạn chế thuộc tính có liên quan đến tính an toàn có nghĩa có nhiều giao tiếp làm giảm hiệu Thiết kế kiến trúc quy trình sáng tạo khác biệt quy trình phụ thuộc vào loại hệ thống xây dựng Tuy nhiên, quy trình thiết kế dựa định sau: Kiến trúc ứng dụng chung có sử dụng lại hay không? Hệ thống phân tán nào? Những phong cách kiến trúc thích hợp? Hệ thống phân rã thành mô-đun nào? Chiến lược điều khiển sử dụng? Cách đánh giá thiết kế kiến trúc Kiến trúc tư liệu hoá nào? Sau mô hình kiến trúc bản: Mô hình cấu trúc tĩnh: mô tả thành phần hệ thống Mô hình quy trình động: biểu diễn quy trình cấu trúc hệ thống Mô hình giao diện: định nghĩa tập hợp giao diện hệ thống Mô hình quan hệ: biểu diễn quan hệ hệ thống Mô hình phân tán: biểu diễn cách cài đặt hệ thống máy tính Tổ chức hệ thống Tổ chức hệ thống phản ánh chiến lược sử dụng để cấu trúc hệ thống Trong trình thiết kế kiến trúc hệ thống, hoạt động phải thực xây dựng mô hình tổ chức hệ thống Có phương pháp tổ chức hệ thống thường sử dụng: - Kho liệu dùng chung - Server dịch vụ dùng chung (client-server) - Phân lớp máy trừu tượng Kho kiệu dùng chung Các hệ thống phải trao đổi liệu làm việc với cách hiệu Việc trao đổi liệu thực theo hai cách : - Dữ liệu chia sẻ lưu CSDL trung tâm kho liệu tất hệ thống truy nhập - Mỗi hệ thống bảo trì CSDL truyền liệu cách tường minh cho hệ thống khác Nếu số lượng liệu dùng chung lớn mô hình kho liệu dùng chung thường sử dụng phổ biến Ưu điểm mô hình là: - Đây phương pháp hiệu để chia sẻ số lượng lớn liệu - Các hệ thống không cần quan tâm tới hoạt động liên quan đến liệu như: lưu, bảo mật,… có quản lý trung tâm thực nhiệm vụ Tuy nhiên, việc sử dụng kho liệu dùng chung có số nhược điểm sau: - Tất hệ thống phải chấp nhận mô hình kho liệu - Việc cải tiến liệu phức tạp tốn - Khó phân tán cách hiệu - Không có giới hạn cho sách quản lý cụ thể Mô hình client – server Là mô hình hệ thống hệ thống bao gồm tập hợp server cung cấp dịch vụ client truy nhập sử dụng dịch vụ Các thành phần mô hình bao gồm: - Tập hợp server cung cấp dịch vụ cụ thể như: in ấn, quản lý liệu… - Tập hợp client truy nhập đến server để yêu cầu cung cấp dịch vụ - Hệ thống mạng cho phép client truy cập tới dịch vụ mà server cung cấp Client phải biết tên server dịch vụ mà server cung cấp Nhưng server không cần xác định rõ client có client Client tạo yêu cầu tới server chờ server trả lời Ưu điểm mô hình client - server là: - Phân tán liệu rõ ràng; - Sử dụng hệ thống kết nối mạng cách hiệu chi phí dành cho phần cứng rẻ hơn; - Dễ dàng bổ sung nâng cấp server Nhược điểm mô hình client - server là: - Không phải mô hình liệu dùng chung nên hệ thống sử dụng tổ chức liệu khác Do đó, việc trao đổi liệu không hiệu - Quản lý server không thống nhất, dư thừa - Không đăng ký tên dịch vụ tập trung Điều làm cho việc tìm kiếm server dịch vụ khó khăn Mô hình phân lớp Tổ chức hệ thống thành nhiều lớp lớp cung cấp tập dịch vụ Mỗi lớp coi máy trừu tượng (abstract machine) mà ngôn ngữ máy định nghĩa dịch vụ mà lớp cung cấp Do đó, mô hình thường sử dụng để mô hình hoá giao diện (interface) hệ thống Mô hình phân lớp hỗ trợ phát triển hệ thống theo kiểu tăng vòng nhiều lớp khác Khi giao diện lớp thay đổi lớp liền kề bị ảnh hưởng VI Cài đặt tích hợp Cài đặt tích hợp từ xuống (top-down) Trong phương pháp cài đặt theo kiểu xuống (top-down implementation and inergration),nếu module A có lời gọi đến module B A cài đặt kiểm thử trước B Để kiểm thử A B cần cài đặt dạng Stub Sau A cài đặt cài đặt stub B mở rộng thành cài đặt thực Ví dụ sơ đồ hình 9.1.thì thứ tự cài đặt kiểm thử a,b,c,d,e,f,g,h,i,j,k,l,m.Trước hết a cài đặt Sau b,c,d cài đặt dang stub a kiểm thử, sau kiểm thử a đến lượt stub b,c d mở rộng thành cài đặt thực e,f,g cài đặt duới dang stub vậy,khi cài đặ module mức k sơ đồ hình ta cần cài đặt module mức k+1 dạng stub Quá trình kiểm thử dừng lại tất module cài đặt kiểm thử Cài đặt tích hợp từ lên(bottom-up) Phương pháp cài đặt tích hợp theo kiểu lên (bottom-up) thực ngược lại với phương pháp xuống Đầu tiên module mức (hay gọi mức cao nhất) nói chiều cao cây) cài đặt kiểm thử Sau module mức phía cài đặt kiểm thử với module mức Cứ module mức cài đặt kiểm thử trình hoàn tất Có thể thấy phương phap bottom-up có ưu điểm phương pháp top-down chỗ tạo cài đặt dạng stub (các module tầng thường phải thử với driver).Tuy nhiên có nhược điểm lớn: Nếu lỗi phát muộn, tức mức gần gốc chẳng hạn, lúc toàn phần phải xem xét lại VII Kiểm thử hệ thống Kiểm thử pha thiếu trình phát triển hệ thống Kiểm thử giúp cho người xây dựng hệ thống khách hàng thấy hệ thống thoả mãn yêu cầu đề hay chưa Quy trình kiểm thử gồm hai pha: - Kiểm thử thành phần: kiểm thử thành phần riêng biệt Do người xây dựng thành phần tự thực Việc kiểm thử kế thừa từ kinh nghiệm người xây dựng - Kiểm thử hệ thống: kiểm thử tập thành phần tích hợp với để tạo hệ thống hệ thống Thông thường đội kiểm thử độc lập thực Việc kiểm thử dựa tài liệu đặc tả hệ thống Kiểm thử hệ thống bao gồm tích hợp thành phần tạo hệ thống hệ thống con; sau đó, kiểm thử hệ thống tích hợp Kiểm thử hệ thống gồm pha: - Kiểm thử tích hợp: đội kiểm thử truy nhập vào mã lệnh hệ thống Hệ thống cần kiểm thử coi thành phần tích hợp với - Kiểm thử độc lập: đội kiểm thử kiểm thử hệ thống đầy đủ để chuyển giao, coi hệ thống hộp đen Kiểm thử thành phần (hay gọi kiểm thử đơn vị) quy trình kiểm thử thành phần riêng lẻ hệ thống Đây quy trình phát khiếm khuyết Thành phần kiểm thử là: - Chức phương thức đối tượng - Lớp đối tượng với thuộc tính phương thức - Thành phần kết hợp với giao diện định nghĩa trước để truy nhập tới chức Thiết kế trường hợp kiểm thử : Mục đích thiết kế trường hợp kiểm thử tạo tập hợp mẫu kiểm thử có khả đánh giá hiệu phát khiếm khuyết Các phương pháp thiết kế trường hợp kiểm thử: - Kiểm thử dựa yêu cầu - Kiểm thử phân hoạch - Kiểm thử hướng cấu trúc (hoặc kiểm thử hộp trắng) - Kiểm thử đường Kiểm thử dựa yêu cầu : Một nguyên tắc kỹ thuật xác định yêu cầu yêu cầu hệ thống phải có khả kiểm thử Kiểm thử dựa yêu cầu kỹ thuật kiểm thử hợp lệ, ta phải xem xét yêu cầu đưa tập mẫu thử cho yêu cầu Kiểm thử phân hoạch : Dữ liệu đầu vào kết đầu thường rơi vào lớp khác nhau, tất thành viên lớp có quan hệ với Mỗi lớp thường phân hoạch miền ứng dụng mà chương trình chạy theo cách thích ứng với thành viên lớp Các trường hợp kiểm thử lựa chọn từ phân hoạch Kiểm thử hướng cấu trúc (kiểm thử hộp trắng) : Kiểm thử hướng cấu trúc đưa trường hợp kiểm thử dựa theo cấu trúc chương trình Những hiểu biết chương trình sử dụng để xác định trường hợp kiểm thử bổ sung Kiểm thử đường : Mục tiêu kiểm thử đường nhằm đảm bảo tập hợp mẫu thử đường qua hệ thống thực lần Điểm bắt đầu kiểm thử đường biểu đồ luồng chương trình, gồm nút biểu diễn nhánh chương trình cung biểu diễn luồng điều khiển Tự động kiểm thử : - Kiểm thử pha có chi phí cao - Có nhiều công cụ hỗ trợ kiểm thử giúp giảm thời gian chi phí - Một số loại công cụ hỗ trợ tự động kiểm thử: Quản lý kiểm thử: giúp quản lý chương trình kiểm thử lưu vết liệu kiểm thử, kết mong muốn … Bộ tạo liệu kiểm thử Oracle: tạo dự đoán kết kiểm thử Bộ so sánh file: so sánh kết chương trình kiểm thử Bộ tạo báo cáo Bộ phân tích động: bổ sung mã lệnh cho chương trình để đếm số lần thực câu lệnh Bộ giả định VIII Bảo trì tái kỹ Bảo trì phần mềm Bảo trì phần mềm hoạt động chỉnh sửa chương trình sau đưa vào sử dụng Lý : - Các yêu cầu hệ thống thường thay đổi hệ thống xây dựng môi trường thay đổi Vì vậy, hệ thống chuyển giao không thoả mãn yêu cầu - Các hệ thống có gắn kết chặt chẽ với môi trường Khi hệ thống cài đặt môi trường định làm thay đổi môi trường thay đổi yêu cầu hệ thống - Các hệ thống phải bảo trì chúng muốn phần hữu ích môi trường nghiệp vụ Phân loại kiểu bảo trì: - Bảo trì sửa lỗi: thay đổi hệ thống để sửa lại khiếm khuyết nhằm thoả mãn yêu cầu hệ thống - Bảo trì tích hợp hệ thống vào môi trường vận hành khác - Bảo trì để bổ sung chỉnh sửa yêu cầu chức hệ thống: chỉnh sửa hệ thống cho thoả mãn yêu cầu Các nhân tố ảnh hưởng đến chi phí bảo trì: - Sự ổn định đội dự án: chi phí bảo trì giảm nhân viên đội dự án không thay đổi - Những trách nhiệm cam kết: người xây dựng hệ thống không cam kết trách nhiệm bảo trì để bắt buộc họ phải thiết kế lại cho thay đổi tương lai - Kỹ nhân viên: nhân viên bảo trì thường kinh nghiệm hiểu biết miền ứng dụng họ bị hạn chế - Tuổi thọ cấu trúc chương trình: tuổi thọ cấu trúc chương trình bị xuống cấp chúng trở lên khó hiểu thay đổi nhiều Chi phí bảo trì thường lớn chi phí xây dựng gấp từ đến 100 lần phụ thuộc vào ứng dụng Chi phí bảo trì bị ảnh hưởng tác nhân kỹ thuật phi kỹ thuật Nếu bảo trì nhiều, làm thay đổi cấu trúc phần mềm làm cho việc bảo trì trở lên khó khăn Phần mềm có tuổi thọ cao phải cần chi phí cao (vì sử dụng ngôn ngữ chương trình dịch cũ …) Tái kỹ nghệ hệ thống Tái kỹ nghệ hệ thống kỹ thuật cấu trúc lại viết lại phần toàn hệ thống thừa kế mà không thay đổi chức Tái kỹ nghệ giúp giảm rủi ro trình xây dựng phần mềm rủi ro xảy cao giúp giảm chi phí Quy trình tái kỹ nghệ bao gồm hoạt động sau: - Dịch mã nguồn: chuyển mã lệnh thành ngôn ngữ - Kỹ nghệ ngược: phân tích chương trình để tìm hiểu - Cải thiện cấu trúc chương trình - Mô-đun hoá chương trình: tổ chức lại cấu trúc chương trình - Tái kỹ nghệ liệu: thu dọn cấu trúc lại liệu hệ thống Các nhân tố ảnh hưởng tới chi phí tái kỹ nghệ: - Chất lượng hệ thống tái kỹ nghệ - Các công cụ hỗ trợ tái kỹ nghệ - Mức mở rộng cần thiết việc chuyển đổi liệu - Những nhân viên có kỹ tái kỹ nghệ hệ thống