Tai lieuCNTT cong nghe phan mem

LỜI NÓI ĐẦU Nhập môn Công Nghệ Phần Mềm môn học nhằm giúp cho sinh viên có kiến thức lĩnh vực công nghệ phần mềm Qua môn học sinh viên có nhìn khái quát qui trình phát triển phần mềm, hiểu biết thực giai đoạn qui trình phần mềm cụ thể dựa phương pháp, kỹ thuật trình thu thập yêu cầu, phân tích, thiết kế cài đặt, viết sưu liệu minh họa cụ thể tài liệu Mục tiêu tài liệu sinh viên hiểu yêu cầu công việc cần phải làm giai đoạn qui trình, để đảm trách công việc giai đoạn làm phần mềm nhóm dự án TÀI IỆU THAM KHẢO Software Engineering By Nguyễn Xuân Huy – Institue of Information Technology Nhập môn công nghệ phần mềm Nguyễn Tiến Huy – ĐH Khoa học Tự Nhiên A Discipline for Software Engineering Watts S Humphrey Quá trình phát triển phần mềm thống Nguyễn Tuấn Huy biên dịch –Nhà xuất thống kê Analyzing Requriements and Defining Solution Architechtures Ian Lewis – Bruce Nielson MCSD Analyzing Requirements Study Guide Tata McGraw-Hill Pusblishing Company Limited Software Engineering Roger S.PressMan Một số tài liệu tham khảo từ internet: Khoa CNTT ĐH KHTN, ĐH BKHN, ĐH Cần Thơ, số báo khoa học A Summary of Principles for User-Interface Design by Talin The Foundation for Verifiable Software Process Improvement Lecture Notes: Software Engineering I by Joey Paquet Chương 1: TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM CÁC KHÁI NIỆM CƠ BẢN 1.1 Phần mềm 1.1.1 Các khái niệm Chương trình máy tính trình tự thị để hướng dẫn máy tính làm việc nhằm hoàn thành công việc người yêu cầu Phần mềm hệ thống chương trình thực máy tính nhằm hỗ trợ nhà chuyên môn lĩnh vực chuyên ngành thực tốt thao tác nghiệp vụ Nhiệm vụ yếu phần mềm cho phép nhà chuyên môn thực công việc họ máy tính dễ dàng nhanh chóng so với thực công việc giới thực Hoạt động phần mềm mô lại họat động giới thực góc độ thu hẹp máy tính Quá trình sử dụng phần mềm trình người dùng thực công việc máy tính để hoàn tất công việc tương đương giới thực Lớp phần mềm hệ thống phần mềm lĩnh vực họat động Do lĩnh vực họat động nên phần mềm thường có cấu trúc chức (công việc mà người dùng thực máy tính) tương tự Mục tiêu ngành công nghệ phần mềm hướng đến xây dựng phần mềm có chất lượng mà cho phép xây dựng dễ dàng phần mềm từ phần mềm có sẵn kĩnh vực (thậm chí lĩnh vực khác) STT Lớp phần mềm Các phần mềm Hỗ trợ giải tập lượng giác, hình học, giải tích, số học, … Trò chơi cờ carô, cờ tướng, cờ vua, xếp hình, … Xếp lịch biểu thi đấu, thời khóa biểu, hội nghị, … Xét tuyển nhân sự, sinh viên lớp 10… Bình chọn Sản phẩm, cầu thủ, … Cho mượn sách, truyện, phim, … Bán hàng thuốc tây, vật liệu xây dựng, máy tính Quản lý thuê bao điện, điện thoại, nước, … Bảng 1.1: Các phần mềm lớp phần mềm tương ứng 1.1.2 Phân loại Phần mềm hệ thống phần mềm đảm nhận công việc tích hợp điều khiển thiết bị phần cứng đồng thời tạo môi trường thuận lợi để phần mềm khác người sử dụng thao tác khối thống mà không cần phải quan tâm đến chi tiết kỹ thuật phức tạp bên cách thức trao đổi liệu nhớ thiết bị lưu trữ, cách hiển thị văn lên hình, Phần mềm ứng dụng phần mềm dùng để thực công việc xác định Phần mềm ứng dụng gồm chương trình đơn giản chương trình xem ảnh, nhóm chương trình tương tác với để thực công vịệc chương trình xử lý tính, chương trình xử lý văn bản, 1.1.3 Kiến trúc phần mềm Sau có khái niêm phần mềm, tiếp sau sâu vào tìm hiểu cấu trúc chi tiết cấu trúc chi tiết thành phần bên phần mềm Phần mềm bao gồm thành phần: a) Thành phần giao tiếp (giao diện) Cho phép tiếp nhận yêu cầu việc muốn thực cung cấp liệu nguồn liên quan đến công việc từ thiết bị thu thập liệu (cân, đo nhiệt độ, tế bào quang học, …) Cho phép trình bày kết việc thực yêu cầu cho người dùng (kết công việc thực máy tính) điều khiển họat động thiết bị điều khiển (đóng mở cửa, bật mở máy…) Một cách tổng quát thành phần giao tiếp hệ thống hàm chuyên việc nhập/xuất liệu (hàm nhập/xuất) với hình thức trình bày tổ chức lưu trữ liệu tương ứng, mục tiêu hàm đưa liệu từ giới bên phần mềm vào bên ngược lại Tài liệu giới hạn xét đến giao tiếp với người sử dụng phần mềm có tên gọi cụ thể thành phần giao diện b) Thành phần liệu Cho phép lưu trữ lại (hàm ghi) kết xử lý (việc mượn sách kiểm tra hợp lệ, bảng lương tháng tính) nhớ phụ với tổ chức lưu trữ xác định trước (tập tin có cấu trúc, tập tin nhị phân, sở liệu) Cho phép truy xuất lại (hàm đọc) liệu lưu trữ phục vụ cho hàm xử lý tương ứng Một cách tổng quát thành phần liệu hệ thống hàm chuyên đọc ghi liệu (hàm đọc/ghi) với mô hình tổ chức liệu tương ứng Mục tiêu hàm chuyển đổi liệu nhớ nhớ phụ c) Thành phần xử lý Kiểm tra tính hợp lệ liệu nguồn cung cấp từ người dùng theo quy trình ràng buộc giới thực (chỉ cho mượn tối đa sách, lớp học có tối đa 50 sinh viên, …) Tiến hành xử lý cho kết mong đợi theo quy định tính toán có sẵn giới thực (quy tắc tính tiền phạt trả sách trễ, quy tắc tính tiền điện, quy tắc trả góp mua nhà…) theo thuật giải tự đề xuất (xếp thời khóa biểu tự động, nén ảnh…) Việc xử lý dựa liệu nguồn từ người sử dụng cung cấp (tính nghiệm phương trình bậc dựa hệ số nhập) liệu lưu trữ có sẵn (tính tồn kho tháng dựa phiếu nhập xuất lưu trữ …) hai (tính tiền phạt dựa ngày trả sách nhập vào thông tin loại sách lưu trữ …) tùy vào xử lý cụ thể Tương tự, việc xử lý cho kết dùng để xuất cho người dùng xem qua thành phần giao diện (trình bày nghiệm, xuất tiền phạt), hay lưu trữ lại qua thành phần liệu (sổ sách mượn độc giả …) hai (bảng lương, bảng tồn kho …) Một cách tổng quát, thành phần xử lý hệ thống hàm chuyên xử lý tính toán, biến đổi liệu Các hàm dùng liệu nguồn từ hàm thành phần giao diện (hàm nhập) hay thành phần liệu (hàm đọc liệu) kiểm tra tính hợp lệ (hàm kiểm tra) sau tiến hành xử lý (hàm xử lý) cần thiết kết mà trình bày cho người dùng xem qua hàm thành phần giao diện (hàm xuất) lưu trữ lại qua hàm thành phần liệu (hàm ghi) STT Thành phần Hàm Ý nghĩa Ghi Hàm nhập Hàm xuất Nhập yêu cầu, liệu nguồn Xuất kết xử lý Cần xác định hình thức nhập/xuất tổ chức liệu tương ứng Thành phần giao diện Kiểm tra tính hợp lệ Sử dụng hàm nhập, hàm Thành phần Hàm kiểm tra liệu đọc Sử dụng hàm nhập, xử lý Hàm xử lý Xử lý tính toán, phát sinh, biến hàm đọc, hàm xuất, hàm đổi liệu ghi Đọc liệu từ nhớ phụ vào Thành phần Hàm đọc Hàm nhớ Cần xác định cáchh thức liệu ghi Ghi liệu từ nhớ tổ chức lưu trữ liệu vào nhớ phụ Bảng 1.2: Danh sách hàm ý nghĩa tương ứng 1.2 Chất lượng phần mềm 1.2.1 Tính đắn Tính đắn phần mềm thể chổ sản phẩm thực đầy đủ xác yêu cầu người dùng Tính đắn cần phải hiểu theo nghĩa rộng chương trình cần phải thực trường hợp mà liệu đầu vào không hợp lệ Ví dụ, số chức phần mềm xếp tập tin có số lượng mẫu tin tùy ý theo cột tùy ý theo chiều tăng giảm trường hợp sau vi phạm tính đắn chương trình: Không thể thực (treo máy) tập tin rỗng (không có mẫu tin nào) Không thể thực thực cho kết sai mẫu tin có 100 cột có nhiều mẫu tin Không thể thực cho kết sai cột có chiều dài lớn 125 bytes Không thể xếp theo chiều tăng dần… Tính đắn sản phẩm phần mềm xác minh qua sau đây: Tính đắn thuật toán Tính tương đương chương trình với thuật toán Thuật toán chương trình lập không tương đương với thuật toán nên thực cho kết sai Tính đắn chương trình chứng minh trực tiếp văn chương trình Tính đắn khẳng định dần qua việc kiểm thử, việc áp dụng chương trình khoảng thời gian dài diện rộng với tần suất sử dụng cao 1.2.2 Tính tiến hóa Cho phép người dùng khai báo thay đổi qui định với phần mềm tùy theo thay đổi giới thực liên quan (thay qui định số sách mượn tối đa, công thức tính tiền phạt, công thức tính tiền điện…) Sản phẩm mở rộng, tăng cường mặt chức cách dễ dàng 1.2.3 Tính hiệu Tính hiệu sản phẩm phần mềm xác định qua tiêu chuẩn sau:  Hiệu kinh tế ý nghĩa, giá trị thu áp dụng sản phẩm  Tốc độ xử lý phần mềm (v) tính tỉ lệ khối lượng đối tượng cần phải xử lý (m) tổng thời gian (t) cần thiết để xử lý đối tượng  Sử dụng tối ưu tài nguyên máy tính (CPU, nhớ…) 1.2.4 Tính tiện dụng Sản phẩm phải tính đến yếu tố tâm lý sau người dùng:  Dễ học, có giao diện trực quan tự nhiên  Dễ thao tác,… 1.2.5 Tính tương thích Trao đổi liệu với phần mềm khác có liên quan (nhận danh mục sách từ tập tin Excel, gửi báo cáo tổng kết năm học đến phần mềm WinFax, …) Giao tiếp nội Giao tiếp bên 1.2.6 Tính tái sử dụng Sản phẩm phần mềm áp dụng cho nhiều lĩnh vực theo nhiều chế độ làm việc khác  Các phần mềm lớp  Các phần mềm khác lớp 1.3 Công nghệ phần mềm 1.3.1 Sự đời Vào năm 1950 máy tính đời thức (không dùng phòng thí nghiệm mà bắt đầu ứng dụng họat động xã hội) phần mềm đời với số lượng ỏi chủ yếu phục vụ cho lĩnh vực tính toán (đặc biệt quốc phòng) Đến năm 1960, trải qua 10 năm phát triển số lượng phần mềm tăng lên nhiều ứng dụng rộng rãi nhiều lĩnh vực Vào thời điểm phát sinh vấn đề mà chuyên gia gọi “cuộc khủng hoảng phần mềm” Cuộc khủng hoảng phần mềm thể yếu tố chính: Số lượng phần mềm tăng vọt (do phát triển phần cứng: tăng khả năng, giá thành hạ) Có nhiều khuyết điểm phần mềm dùng xã hội Thực không yêu cầu (tính toán sai, không ổn định…) Thời gian bảo trì, nâng cấp lâu, tốn chi phí cao, hiệu thấp Khó sử dụng Thực chậm Khó chuyển đổi liệu phần mềm … Để giải vấn đề hội nghị triệu tập đề bàn cách giải Hội nghị tiến hành xem xét, phân tích xác định nguyên nhân gây khủng hoảng phần mềm Kết luận sau: Việc tăng vọt số lượng phần mềm điều hợp lý điều tiếp diễn Các khuyết điểm phần mềm có nguồn gốc từ phương pháp, cách thức tiến hành xây dựng phần mềm: Cảm tính: người theo phương pháp riêng Thô sơ, đơn giản: tập trung vào việc lập trình mà quan tâm đến công việc cần làm khác trước lập trình (khảo sát trạng, phân tích yêu cầu, thiết kế…) Thủ công: công cụ hỗ trợ xây dựng phần mềm trình biên dịch Với kết luận trên, hội nghị đề xuất khai sinh ngành khoa học mới: Công nghệ phần mềm với nhiệm vụ nghiên cứu phương pháp tiến hành xây dựng phần mềm 1.3.2 Định nghĩa Công nghệ phần mềm lĩnh vực nghiên cứu tin học nhằm đề xuất nguyên lý, phương pháp, công cụ, cách tiếp cận phục vụ cho việc thiết kế, cài đặt sản phẩm phần mềm đạt đầy đủ yêu cầu chất lượng phần mềm Do trình tiến hóa ngành công nghệ phần mềm nên khái niệm thay đổi theo thời gian Hơn lĩnh vực nên khái niệm phụ thuộc nhiều vào quan điểm chủ quan người khác Cụ thể sau:  Bauer[1969]: việc thiết lập sử dụng nguyên lý công nghệ đắn để thu phần mềm cách kinh tế vừa tin cậy vừa làm việc hiệu máy thực  Ghezzi[1991]: lĩnh vực khoa học máy tính liên quan đến việc xây dựng phần mềm vừa lớn vừa phức tạp hay số nhóm kỹ sư  IEEE[1993]: Việc áp dụng phương pháp tiếp cận có hệ thống, lượng hóa phát triển, vận hành bảo trì phần mềm Nghiên cứu phương pháp tiếp cận dùng (1)  Sommervile[1995]: lĩnh vực liên quan đến lý thuyết, phương pháp công cụ dùng cho phát triển phần mềm  Kawamura[1995]: lĩnh vực học vấn kỹ thuật, phương pháp luận công nghệ học (lý luận kỹ thuật thực hóa nguyên lý, nguyên tắc xác định) toàn quy trình phát triển phần mềm nhằm nâng cao chất lượng sản xuất phần mềm  Pressman[1995]: môn tích hợp qui trình, phương pháp, công cụ để phát triển phần mềm máy tính Có thể định nghĩa tóm tắt công nghệ phần mềm sau: Công nghệ phần mềm nghành khoa học nghiên cứu việc xây dựng phần mềm có chất lượng khoảng thời gian chi phí hợp lý Mục tiêu nghiên cứu chia thành phần rõ nét: Xây dựng phần mềm có chất lượng Xây dựng phần mềm thời gian chi phí hợp lý 1.3.3 Đối tượng nghiên cứu Hướng đến việc xây dựng phần mềm có chất lượng nêu, ngành công nghệ phần mềm đưa đối tượng nghiên cứu chính: Qui trình công nghệ, Phương pháp phát triển, Công cụ môi trường phát triển phần mềm Qui trình công nghệ phần mềm: Hệ thống giai đoạn mà trình phát triển phần mềm phải trải qua Với giai đoạn cần xác định rõ mục tiêu, kết nhận từ giai đoạn trước kết chuyển giao cho giai đoạn kết tiếp Phương pháp phát triển phần mềm: Hệ thống hướng dẫn cho phép bước thực giai đoạn qui trình công nghệ phần mềm Công cụ môi trường phát triển phần mềm: Hệ thống phần mềm trợ giúp lĩnh vực xây dựng phần mềm Các phần mềm hỗ trợ chuyên viên tin học bước xây dựng phần mềm theo phương pháp với qui trình chọn trước Chương QUI TRÌNH PHÁT TRIỂN PHẦN MỀM Như nói để xây dựng phần mềm có chất lượng trình phát triển phải trải qua nhiều giai đoạn Mỗi giai đoạn có mục tiêu kết chuyển giao xác định Trình tự thực giai đoạn chu kỳ sống phần mềm Nói cách khác, chu kỳ sống phần mềm khoảng thời gian mà sản phẩm phần mềm phát triển, sử dụng mở rộng sản phẩm phần mềm không sử dụng Chu kỳ sống phần mềm phân chia phân chia thành pha như: xác định, phát triển, kiểm thử, bảo trì (vận hành) Phạm vi thứ tự pha khác tùy theo mô hình cụ thể 2.1 Các bước xây dựng phần mềm 2.1.1 Xác định Đây bước hình thành toán đề tài Ở bước thiết kế trưởng phân tích viên hệ thống phải biết vai trò phần mềm cần phát triển hệ thống, đồng thời phải ước lượng công việc, lập lịch biểu phân công công việc Bên cạnh phải biết người đặt hàng muốn Các yêu cầu cần phải thu thập đầy đủ phân tích theo chiều ngang (rộng) chiều dọc (sâu) Công cụ sử dụng chủ yếu giai đoạn lược đồ, sơ đồ phản ánh rõ thành phần hệ thống mối liên quan chúng với 2.1.2 Phát triển Dựa vào nội dung xác định được, nhóm phát triển phần mềm dùng ngôn ngữ đặc tả hình thức (dựa kiến trúc toán học) phi hình thức (tựa ngôn ngữ tự nhiên) kết hợp hai để mô tả yếu tố sau chương trình:  Giá trị nhập, giá trị xuất  Các phép biến đổi  Các yêu cầu cần đạt điểm chương trình Phần đặc tả quan tâm chủ yếu đến giá trị vào, không quan tâm đến cấu trúc nội dung thao tác cần thực Sau bước thiết kế bước triển khai đặc tả chương trình thành sản phẩm phần mềm dựa ngôn ngữ lập trình cụ thể Trong giai đoạn lập trình viên tiến hành cài đặt thao tác cần thiết để thực yêu cầu đặc tả Công việc cuối giai đoạn phát triển cần phải chứng minh tính đắn chương trình sau tiến hành cài đặt Tuy nhiên thông thường bước coi chương trình hộp đen Vấn đề đặt xây dựng cách có chủ đích tập liệu nhập khác để giao cho chương trình thực dựa vào kết thu để đánh giá chương trình Công việc gọi kiểm thử chương trình Công việc kiểm thử nhằm vào mục tiêu sau:  Kiểm tra để phát lỗi chương trình Lưu ý kiểm thử không đảm bảo tuyệt đối tính đắn chương trình chất quy nạp không hoàn toàn cách làm  Kiểm tra tính ổn định, hiệu khả tối đa chương trình Tùy theo mục đích mà người ta thiết kế tập liệu thử cho phủ hết trường hợp cần quan tâm 2.1.3 Bảo trì (Vận hành) Công việc quản lý việc triển khai sử dụng phần mềm vấn đề cần quan tâm qui trình phát triển phần mềm Trong trình xây dựng phần mềm, toàn kết phần tích, thiết kế, cài đặt hồ sơ liên quan cần phải lưu trữ quản lý cẩn thận nhằm đảm bảo cho công việc tiến hành cách hiệu phục vụ cho công việc bảo trì phần mềm sau Như công việc quản lý không dừng lại trình xây dựng phần mềm mà trái lại phải tiến hành liên tục suốt trình sống 2.2 Một số mô hình triển khai xây dựng phần mềm Có nhiều mô hình khác để triển khai bước trình phát triển phần mềm Mỗi mô hình chia vòng đời phần mềm theo cách khác nhằm đảm bảo qui trình phát triển phần mềm dẫn đến thành công Trong phần tài liệu tìm hiểu qua mô hình phát triển phần mềm tiêu biểu áp dụng 2.2.1 Mô hình thác nước Mô hình thác nước mô hình phổ biến áp dụng trình phát triển phần mềm Mô hình chia trình phát triển phần mềm thành giai đoạn nối tiếp Mỗi giai đoạn có mục đích định Kết cuả giai đoạn trước thông tin đầu vào cho giai đoạn sau Tùy theo qui mô phần mềm cần phát triển mà mô hình thác nước có biến thể khác sau:  Qui trình giai đoạn: Là qui trình đơn giản Theo qui trình việc phát triển phần mềm trải qua giai đoạn: o Xác định yêu cầu: Được tiến hành có nhu cầu việc xây dựng phần mềm - Mục tiêu: Xác định xác yêu cầu đặt cho phần mềm xây dựng - Kết nhận: Thông tin hoạt động giới thực - Kết chuyển giao: Danh sách yêu cầu (công việc thực máy tính) với thông tin miêu tả chi tiết yêu cầu (cách thức thực giới thực) o Lập trình (cài đặt): Được tiến hành sau kết thúc việc xác định yêu cầu - Mục tiêu: Tạo lập phần mềm mong muốn theo yêu cầu - Kết nhận: Danh sách yêu cầu thông tin có liên quan - Kết chuyển giao: Chương trình nguồn phần mềm với cấu trúc sở liệu tương ứng (nếu cần thiết) chương trình thực máy tính (chương trình nguồn biên dịch)  Qui trình giai đoạn: Là qui trình cải tiến qui trình giai đoạn cách bổ 10  Hệ thống phần mềm nên chứa mà vài ghi gãy gọn súc tích nhiều ghi chi tiết tương xứng cần thiết  Đảm bảo thay đổi chương trình tác động phần khai báo khối lệnh mà phản ánh cập nhật phần ghi Những ghi không xác tệ Lưu ý: luật tuân thủ cân nhắc luật áp dụng đồng cho tất hệ thống phần mềm phạm vi ứng dụng Việc ghi hệ thống phần mềm nghệ thuật giống phần thiết kế cài đặt hệ thống phần mềm 8.3.3 Cách thức trình bày bên Ngoài chọn tên ghi chú, khả đọc hệ thống phần mềm phụ thuộc vào cách thức trình bày bên Một số luật đề nghị cho hình thức trình bày chương trình:  Mỗi thành phần chương trình (components), khai báo (của kiểu liệu, biến, …) nên tách biệt phần khối lệnh  Phần khai báo nên có cấu trúc đồng thứ tự sau: hằng, kiểu  liệu, lớp, mô đun, phương thức thủ tục  Mô tả giao diện (danh sách tham số cho phương thức thủ tục) nên tách tham số nhập liệu, kết xuất nhập/xuất  Phần ghi chương trình nguồn nên tách bạch  Cấu trúc chương trình nên nhấn mạnh phần canh chỉnh lề (sử dụng phím tab cho từ đầu khối lệnh đến khối lệnh theo sau) 8.4 Đánh giá chất lượng công việc 8.4.1 Hiện thực tăng cường Ý tưởng việc thực tăng cường gần với việc trộn giai đoạn thiết kế cài đặt tách biệt hai giai đoạn mà mô hình qui trình phát triển phần mềm cổ điển đề Điểm nhấn mạnh phương pháp tìm thấy dựa thực nghiệm định thiết kế cài đặt có tác động lẫn tách bạch thiết kế khắt khe không đạt mục tiêu Trong nhiều trường hợp, có cài đặt định việc phân rã cấu trúc thiết kế chứng minh thõa mãn đầy đủ vấn đề Hiện thực tăng cường nghĩa sau bước thiết kế có liên quan đến kiến trúc, kiến trúc phần mềm hành thẩm định dựa trường hợp thực Sự tác động qua lại thành phần hệ thống cụ thể thiết kế (trong hình thức đặc tả giao diện) thẩm định Để làm điều này, thành phần hệ thống (hành vi xuất/ nhập chúng) mô hay thực tế hóa khuôn mẫu Nếu có nghi ngờ liên quan đến tính khả thi thành phần tiến trình thiết kế ngắt thành phần thực Chỉ thực nhúng chúng vào kiến trúc hệ thống trước kiểm tra tiến trình thiết tục hay kiến trúc chấp nhận tương ứng kiến thức thu thực thành phần 115 Hiệu phương pháp phụ thuộc vào việc mở rộng vào khả tích hợp thành phần hệ thống mà viết chuẩn mực khác hoàn chỉnh nhữn cấp độ khác nhau, toàn hệ thống để thực gần với thực tế Một vài thành phần hệ thống, ví dụ giao diện người dùng mô hình liệu thể dạng khuôn mẫu, thành phần khác từ thư viện thành phần có sẵn hay tồn thực hoàn chỉnh thể dạng mã nguồn thực thi thành phần hệ thống khác có sẵn đặc tả giao diện Đối với hợp lệ thiết kế hệ thống hành, lúc giao diện người dùng triển khai tương ứng khuôn mẫu cần kích hoạt 8.4.2 Đánh giá lại thiết kế chương trình (Design and Code Review) Với việc xem lại thiết kế chương trình, giúp hoàn chỉnh chất lượng hiệu công việc điều chỉnh thay đổi đơn lẻ trình phát triển phần mềm.Trong chương trình lớn, đòi hỏi xem xét lại yêu cầu, đặc tả, thiết kế, chương trình Giúp điều chỉnh thiếu sót, logic, cấu trúc, tính sáng tỏ Khi chương trình không rõ hay mơ hồ xáo trộn, thêm ghi tốt hay viết lại cách đơn giản làm cho chương trình dễ đọc dễ hiểu Việc làm tạo cho tự tin xuất hay trình bày cho bạn bè hay tập thể Mục đích review để đảm bảo chương trình tạo đạt chất lượng cao Một việc review kiểm duyệt, duyệt qua, xem xét mục riêng từ thiết dòng lệnh Review dùng yêu cầu, thiết kế, hồ sơ tài liệu, hay yếu tố sản phẩm Nhiều dự án phần mềm trải qua qúa trình phát triển giai đoạn kiểm thử Điều không hiệu Review thiết kế chương trình cách thức hiệu tìm sửa chữa thiếu sót Với review, tìm thiếu sót trực tiếp, tìm dấu hiệu Khi xem lại chương trình, biết nơi logic giả sử phải làm.Những sửa lỗi hoàn chỉnh xác Công việc review cho phép quay trở lại việc làm Nhóm phát triển nên ngồi lại với để đọc lại thiết kế chương trình, nghiên cứu, hiểu Sửa sai sót: logic, cấu trúc, tính rõ ràng Sau xem xét đánh giá, viết lại chương trình Chỗ không rõ ràng hay lộn xộn, thêm ghi viết lại hoàn chỉnh làm cho dễ đọc dễ hiểu Ví dụ minh họa Ví dụ: Xét phần mềm hỗ trợ giải tập phương trình đại só với yêu cầu: Soạn đề bài, Soạn đáp án, Giải tập, Chấm điểm Nhằm thể giai đoạn thực qui trình Giai đoạn 1: Xác định yêu cầu  Yêu cầu 1: Soạn đề với qui định Soạn đề  Yêu cầu 2: Soạn đáp án với qui định Soạn đáp án biểu mẫu Soạn đáp án  Yêu cầu 3: Giải tập với qui định Giải tập biểu mẫu Giải tập  Yêu cầu 4: Chấm điểm với qui định Chấm điểm Giai đoạn 2: 116 Sơ đồ luồng liệu cho công việc Soạn đề Sơ đồ luồng liệu cho công việc Soạn đáp án Sơ đồ luồng liệu cho công việc Giải tập Sơ đồ luồng liệu cho công việc Chấm điểm Giai đoạn 3: Phân tích yêu cầu chức Giai đoạn 4: Thiết kế phần mềm (đã trình bày phần kiến trúc phần mềm chương Thiết kế phần mềm) Giai đoạn 5: Thực phần mềm Hệ thống Lớp đối tượng: Tạo lập lớp đối tượng SACH_BAI_TAP, BAI_TAP theo mô tả phần thiết kế môi trường cụ thể (VIsual Basic, Visual C++, Java 117 Hệ thống giao diện: Tạo lập (vẽ) hình giao diện (màn hình chính, hình soạn đề bài, hình soạn đáp án, hình giải tập, hình chấm điểm) theo mô tả phần thiết kế môi trường cụ thể (Visual Basic, Visual C++, Java, v.v.) Hệ thông lưu trữ: Tạo cấu trúc sở liệu (các bảng SACH_BAI_TAP, BAI_TAP, BAI_GIAI, BUOC_GIAI) theo mô tả phần thiết kế môi trường cụ thể (Access, SQL Server, Oracle, v.v) Giai đoạn 6: Kiểm chứng phần mềm xem chương Kiểm thử 118 Chương KIỂM THỬ PHẦN MỀM Tổng quan Kiểm thử phần mềm tiến hành thí nghiệm để so sánh kết thực tế với lý thuyết nhằm mục đích phát lỗi Bộ thử nghiệm (test cases) liệu dùng để kiểm tra hoạt động chương trình Một kiểm thử tốt có khả phát lỗi chương trình Khi tiến hành kiểm thử, chứng minh tồn lỗi không chứng minh chương trình lỗi Nội dung thử nghiệm:  Tên môđun/chức muốn kiểm thử  Dữ liệu vào  Dữ liệu chương trình: số, xâu ký tự, tập tin,  Môi trường thử nghiệm: phần cứng, hệ điều hành,  Thứ tự thao tác (kiểm thử giao diện)  Kết mong muốn  Thông thường: số, xâu ký tự, tập tin, …  Màn hình, thời gian phản hồi  Kết thực tế Không gian thử nghiệm tập số thử nghiệm Không gian nói chung lớn Nếu vét cạn không gian thử nghiệm chắn qua phép kiểm tra đơn vị không lỗi Tuy nhiên điều không khả thi thực tế Do đề cập đến tính đắn phần mềm dùng khái niệm độ tin cậy Phương pháp kiểm thử cách chọn số thử nghiệm để tăng cường độ tin cậy đơn vị cần kiểm tra Hay nói cách khác phương pháp kiểm thử cách phân hoạch không gian thử nghiệm thành nhiều miền chọn số liệu thử nghiệm đại diện cho miền Như cần tránh trường hợp thử nghiệm rơi vào miền kiểm tra Yêu cầu kiểm thử  Tính lặp lại: o Kiểm thử phải lặp lại (kiểm tra xem lỗi sửa hay chưa) o Dữ liệu/trạng thái phải mô tả  Tính hệ thống: phải đảm bảo kiểm tra hết trường hợp  Được lập tài liệu: phải kiểm soát tiến trình/kết Các kỹ thuật kiểm thử 3.1 Phương pháp hộp đen (Kiểm thử chức năng) Phương pháp kiểm thử dựa đặc tả chức Do đó, tâm đến phát sai sót chức mà không quan tâm đến cách cài đặt cụ thể Với phương pháp có khả phát sai sót, thiếu sót mặt chức năng; sai sót giao diện môđun, kiểm tra tính hiệu quả; phát lỗi khởi tạo, lỗi kết thúc 119 Do kiểm thử trường hợp thực tế, chia không gian thử nghiệm dựa vào giá trị nhập xuất đơn vị cần kiểm tra Ứng với vùng liệu thiết kế thử nghiệm tương ứng đặc biệt thử nghiệm gía trị biên vùng liệu Để kiểm chứng chương trình giải phương trình bậc theo phương pháp hộp đen, phân chia không gian thử nghiệm thành vùng sau: Sau thử kiểm tra với thử nghiệm thiết kế, cần mở rộng thử nghiệm cho trường hợp đặc biệt như: biên số máy tính (32767,-32768), số không, số âm, số thập phân, liệu sai kiểu, liệu ngẫu nhiên a Phương pháp hộp trắng (Kiểm thử cấu trúc) Theo phương pháp này, chia không gian thử nghiệm dựa vào cấu trúc đơn vị cần kiểm tra Kiểm tra giao tiếp đơn vị để đảm bảo dòng thông tin vào đơn vị (đúng giá trị, khớp kiểu ) Kiểm tra liệu cục để đảm bảo liệu lưu trữ đơn vị toàn vẹn suốt trình thuật giải thực Ví dụ: nhập liệu sai, tên biến không đúng, kiểu liệu không quán, ràng buộc ngoại lệ Kiểm tra điều kiện biên câu lệnh if, vòng lặp để đảm bảo đơn vị chạy biên Kiểm tra để đảm bảo đường thực phải qua lần Con đường thực đơn vị chương trình dãy có thứ tự câu lệnh bên đơn vị thực kích hoạt đơn vị Ví dụ: P1 P2 l1 l1 120 l2 if (đk) l2 l3 else l3 l4 l4 Con đường thực p1 p2 sau: P1: l1  l2  l3  l4 Các giai đoạn chiến lược kiểm thử Đối với dự án phần mềm lớn, người tham gia chia thành nhóm:  Nhóm thứ nhất: gồm người tham gia dự án phát triển phần mềm Nhóm chịu trách nhiệm kiểm tra đơn vị chương trình để chắn chúng thực theo thiết kế  Nhóm thứ hai: độc lập gồm chuyên gia tin học không thuộc nhóm thứ Nhóm có nhiệm vụ phát lỗi nhóm thứ chủ quan để lại 4.1 Kiểm thử đơn vị Sử dụng kỹ thuật hộp trắng dựa vào hồ sơ thiết kế để xây dựng thử nghiệm cho khả phát lỗi lớn Vì đơn vị kiểm tra không chương trình đầy đủ, đơn vị gọi đơn vị khác gọi đến đơn vị khác nên dù chương trình hoàn tất đầy đủ đơn vị, không nên giả thuyết tồn tính đắn đơn vị khác mà phải xây dựng module giả lập đơn vị gọi tên driver đơn vị bị gọi stub Driver đóng vai trò chương trình nhập số thử nghiệm gởi chúng đến đơn vị cần kiểm tra đồng thời nhận kết trả đơn vị cần kiểm tra Stub chương trình giả lập thay đơn vị gọi đơn vị cần kiểm tra Stub thực thao tác xử lý liệu đơn giản in ấn, kiểm tra liệu nhập trả kết 121 4.2 Kiểm thử tích hợp Giai đoạn tiến hành sau hoàn tất công việc kiểm thử môđun riêng lẻ cách tích hợp môđun lại với Mục đích giai đoạn kiểm tra giao diện đơn vị, kiểm tra tính đắn so với đặc tả, kiểm tra tính hiệu Phương pháp thực chủ yếu sử dụng kiểm tra chức Các đơn vị tích hợp theo hai chiến lược: từ xuống (top-down) từ lên (bottom- up) 4.2.1 Trên xuống Thuật giải hướng tiếp cận gồm bước sau:  Sử dụng Module driver stub thay cho tất module trực tiếp module  Lần lượt thay stub lần module thực  Tiến hành kiểm tra tính đắn  Một tập hợp thử nghiệm hoàn tất hết stub  Kiểm tra lùi tiến hành để đảm bảo không phát sinh lỗi a) Ưu điểm Kiểm thử xuống kết hợp với phát triển xuống giúp phát sớm lỗi thiết kế làm giảm giá thành sửa đổi Nhanh chóng có phiên thực với chức Có thể thẩm định tính dùng sản phẩm sớm b) Nhược điểm Nhiều môđun cấp thấp khó mô phỏng: thao tác với cấu trúc liệu phức tạp, kết trả phức tạp… 4.2.2 Dưới lên Kiểm ta module trước không cần phải viết stub Thuật giả hướng là:  Các module cấp thấp nhóm thành nhóm (thực chức năng)  Viết driver điều khiển tham số nhập xuất  Bỏ driver gắn chùm vào module cao 122 a) Ưu điểm Tránh xây dựng môđun tạm thời phức tạp Tránh sinh kết nhân tạo (nhập từ bàn phím) Thuận tiện cho phát triển môđun để dùng lại b) Nhược điểm Chậm phát lỗi kiến trúc Chậm có phiên thực 4.3 Kiểm thử chấp nhận Kiểm thử chấp nhận tiến hành khách hàng, gọi alpha testing Mục đích nhằm thẩm định lại xem phần mềm có sai sót, thiếu sót so với yêu cầu người sử dụng không Trong giai đoạn liệu dùng để kiểm thử người sử dụng cung cấp 4.4 Kiểm thử beta Đây giai đoạn mở rộng alpha testing Công việc kiểm thử thực số lượng lớn người sử dụng Công việc kiểm thử tiến hành cách ngẫu nhiên mà hướng dẫn nhà phát triển Các lỗi phát thông báo lại cho nhà phát triển 4.5 Kiểm thử hệ thống Đến giai đoạn này, công việc kiểm thử tiến hành với nhìn nhận phần mềm yếu tố hệ thống thông tin phức tạp hoàn chỉnh Công việc kiểm thử nhằm kiểm tra khả phục hồi sau lỗi, độ an toàn, hiệu giới hạn phần mềm Ví dụ minh họa Ví dụ 1: Phần mềm quản lý thư viện giai đoạn kiểm thử, giai đoạn trước trình bày chương trước Giai đoạn 6: Kiểm chứng phần mềm hướng đối tượng  Kiểm tra tính đắn cá lớp đối tượng  Chuẩn bị liệu thử nghiệm: Nhập liệu thử nghiệm cho bảng THU_VIEN, 123 SACH, DOC_GIA, MUON_SACH  Kiểm tra: + Kiểm tra lớp đối tượng:  Kiểm tra lớp THU_VIEN (Tra cứu độc giả, Tra cứu sách)  Kiểm tra lớp DOC_GIA (Lập thẻ, cho mượn sách)  Kiểm trả lớp SACH (Nhận sách, Trả sách) + Kiểm tra phối hợp lớp đối tượng  Kiểm tra phối hợp lớp THU_VIEN lớp DOC_GIA (Lập thẻ sau Tra cứu độc giả)  Kiểm tra phối hợp lớp THU_VIEN lớp SACH (Nhận sách sau Tra cứu sách)  Kiểm tra phối hợp lớp DOC_GIA lớp SACH (Lập thẻ, Nhận sách, Cho mượn sách Tra sách)  Kiểm tra phối hợp lớp THU_VIEN, DOC_GIA lớp SACH Xác nhận khách hàng: Khách hàng sử dụng phần mềm để thực công việc so sánh kết sử dụng phần mềm với kết thực giới thực Ví dụ 2: Minh họa giai đoạn kiểm chứng phần mềm hỗ trợ giải tập phương trình đại số Giai đoạn 6: Kiểm chứng phần mềm  Kiểm tra tính đắn lớp đối tượng  Chuẩn bị liệu thử nghiệm: Chuẩn bị đề tài, đáp án, giải, điểm số có giới thực nhập điểm cho bảng SACH_BAI_TAP, BAI_TAP, BAI_GIAI, BUOC_GIAI  Kiểm tra: + Kiểm tra lớp đối tượng:  Kiểm tra lớp SACH_BAI_TAP (Tra cứu tập) - Kiểm tra lớp BAI_TAP (Soạn đề, Phát sinh đề, Soạn đáp án, Giải tập, Xem đáp án, Chấm điểm  Ghi chú: Cần phải kiểm tra công việc sau kiểm tra phối hợp công việc + Kiểm tra phối hợp lớp đối tượng: Kiểm tra phối hợp lớp SACH_BAI_TAP lớp BAI_TAP (Soạn đề thi sau tra cứu tập  Xác nhận khách hàng: Khách hàng sử dụng phần mềm để thực công việc so sánh kết sử dụng phần mềm với kết thực giới thực Sưu liệu Sưu liệu phần hệ thống phần mềm Cấu trúc sưu liệu người dùng hệ thống mô tả điều quan trọng việc tạo sưu liệu đạt chất lượng phải nhấn mạnh Phần cuối chương ý đến khả bảo trì, tính khả chuyển sưu 124 liệu Có hai lớp sưu liệu kết hợp với hệ thống máy tính Lớp sưu liệu người dùng mô tả làm để sử dụng hệ thống sưu liệu hệ thống mô tả thiết kế thực hệ thống Sưu liệu cung cấp với hệ thống hữu dụng giai đoạn sống hệ thống Tất sưu liệu cần có mục hiệu Một mục tốt, cho phép người dùng tìm kiếm thông tin họ cần, đặc tính hữu dụng cung cấp thường phần rối tạo sưu liệu Một mục cặn kẻ làm cho sưu liệu viết tệ sử dụng được, mục, cho dù sưu liệu viết tốt không người đọc sưu liệu có hiệu không 5.1 Sưu liệu người dùng Sưu liệu người dùng sưu liệu mô tả chức hệ thống, mà không tham chiếu đến chức thực Sưu liệu người dùng nên cấu trúc cho không thiết phải đọc hết tất sưu liệu trước bắt đầu dùng hệ thống Nó phải hợp với on-line help đơn giản để in văn help sưu liệu người dùng Có loại sưu liệu cho người dùng  Mô tả chức năng, giải thích hệ thống làm  Sưu liệu cài đặt, giải thích làm để install hệ thống chi tiết cho cấu hình phần cứng cụ thể  Giới thiệu, giải thích thuật ngữ đơn giản, làm để bắt đầu hệ thống  Tham chiếu, mô tả chi tiết tất tiện ích hệ thống, chúng sử dụng  Hướng dẫn người quản trị hệ thống (nếu cần), giải thích làm thể để ứng xử với trường phát sinh hệ thống sử dụng làm thể để thực bảo quản hệ thống backup hệ thống 5.1.1 Mô tả chức  Phác thảo yêu cầu hệ thống  Phác thảo mục đích người thiết kế hệ thống  Mô tả hệ thống làm gì?  Mô tả hệ thống làm gì?  Giới thiệu ví dụ minh họa nhỏ chỗ  Vẽ sơ đồ tốt 5.1.2 Bảng Giới thiệu  Cung cấp nhìn tổng quan hệ thống  Cho phép người dùng định hệ thống phù hợp với nhu cầu họ  Trình bày giới thiệu thông tin hệ thống  Mô tả làm để bắt đầu với hệ thống làm người thực sử dụng tiện ích chung hệ thống 125  Bảo người dùng hệ thống làm thể để tránh rắc rối họ làm sai 5.1.3 Bảng tham khảo  Bảng tham khảo hệ thống Sưu liệu định nghĩa cho cách sử dụng hệ thống  Bảng tham khảo nên hoàn chỉnh  Kỹ thuật mô tả chuẩn nên dùng để đảm bảo độ hoàn chỉnh đạt  Người viết bảng giả sử: o Người đọc quen với mô tả hệ thống phần giới thiệu o Ngưòi đọc dùng vài hệ thống hiểu khái niệm thuật ngữ  Phần tham khảo hệ thống nên mô tả: o Những báo cáo lỗi phát sinh hệ thống o Những tình lỗi phát sinh, phù hợp, hướng người dùng đến mô tả tiện ích gây lỗi  Chỉ mục cặn kẽ đặc biệt quan trọng phần Sưu liệu 5.1.4 Sưu liệu cài đặt Sưu liệu cài đặt nên cung cấp đầy đủ chi tiết làm để install hệ thống mô trường cụ thể Phải bao gồm mô tả thiết bị đọc máy mà hệ thống cung cấp định dạng, mã ký tự dùng, làm thông tin viết, tập tin tạo hệ thống Sưu liệu gồm mô tả:  Cấu hình tối thiểu đòi hỏi để chạy hệ thống  Tập tin cố định phải thiết lập  Làm để bắt đầu hệ thống Những tập tin phụ thuộc cấu hình phải thay đổi để thích ứng với hệ thống hệ thống máy chủ cụ thể Hướng dẫn cho quản trị hệ thống (cho hệ thống đòi hỏi người theo dõi tương tác)  Mô tả thông điệp phát sinh hình hệ thống, làm thể để ứng phó với thông điệp  Giải thích nhiệm vụ người theo dõi trì phần cứng Những tài liều dễ đế đọc khác  Danh sách tham khảo nhanh sẵn có tiện ích hệ thống làm thể để sử dụng chúng  Hệ thống on-line help 5.2 Sưu liệu hệ thống Sưu liệu hệ thống chứa tất sưu liệu mô tả trình thực hệ thông từ sưu liệu đặc tả đến kế hoạch test cuối  Tài liệu mô tả thiết kế  Sưu liệu mô tả thực  Sưu liệu mô tả việc kiểm thử Sưu liệu hệ thống cần thiểt để hiểu bảo trì hệ thống phần mềm 126 Sưu liệu nên cấu trúc mô tả tổng quan hướng người đọc đến mô tả hình thức chi tiết với khía cạnh hệ thống Một khó khăn sưu liệu hệ thống trì tính kiên định qua sưu liệu khác mô tả hệ thống Lưu vết thay đổi, cân nhắc sưu liệu nên thay kiểm soát hệ thống quản lý cấu hình Những thành phần sưu liệu hệ thống: Định nghĩa đặc tả yêu cầu kết hợp Trình bày đặc tả tất hệ thống làm yêu cầu phân rã thành nhóm chương trình tương tác với Sưu liệu không yêu cầu hệ thống thực với chương trình đơn lẻ Mỗi chương trình hệ thống, mô tả làm chương trình phân rã thành thành phần khẳng định đặc tả thành phần Mỗi đơn vị, mô tả thao tác Điều không cần mở rộng để mô tả hoạt động chương trình Mô tả kế hoạch kiểm thử (test plan) chi tiết làm đơn vị chương trình kiểm thử Một kế hoạch kiểm thử kiểm thử hợp kiểm tra tất đơn vị chương trình kết hợp với thực Một kế hoạch kiểm thử chấp nhận, vạch nối kết người dùng hệ thống Tài liệu nên mô tả kiểm thử phải thõa mãn trước hệ thống chấp nhận 5.3 Chất lượng sưu liệu Chất lượng sưu liệu quan trọng chất lượng chương trình Khi thông tin làm sử dụng hệ thống làm để hiểu tiện ích hệ thống bị giảm chất lượng Tạo sưu liệu tốt không dễ dàng không rẻ tiến trình khó tạo chương trình tốt Tiêu chuẩn sưu liệu nên mô tả xác sưu liệu bao gồm nên mô tả hệ thống ký hiệu dùng sưu liệu Với tổ chức, cần thiết lập chuẩn cho sưu liệu yêu cầu tất sưu liệu phải tuân thủ theo định dạng Những tiêu chuẩn sưu liệu bao gồm: + Mô tả định dạng trước chấp tất tài liệu + Đánh số trang cách thức ghi trang + Phương thức tham khảo tài liệu khác + Số đề mục đề mục Phong cách viết yếu tố tảng ảnh hưởng đến chất lượng sưu liệu khả người viết để xây dưng cách rõ ràng kỹ thuật soạn thảo xác Một số cách viết nên tránh dùng câu dài, mô tả phức tạp, lặp lại, thông tin tham chiếu toàn số chi tiết gơi nhớ cho người đọc v.v 127 5.4 Bảo trì sưu liệu Bởi hệ thống phần mềm cập nhật, sưu liệu kết hợp với hệ thống phải cập nhật tướng ứng với thay đổi hệ thống Tất sưu liệu kết hợp nên cập nhật thay đổi làm chương trình Giả sử thay đổi nhìn thấy người dùng, mô tả thực hệ thống cần phải thay đổi Nếu hệ thống thay đổi nhiều xác lỗi chương trình điều có nghĩa xem xét lại sưu liệu thiết kế kiểm thử sưu liệu thiết kế mức cao mô tả đặc tả yêu cầu Một vấn đề bảo trì sưu liệu lưu thể khác hệ thống bước với Giải pháp tốt cho vấn đề hỗ trợ bảo trì sưu liệu với công cụ phần mềm mà ghi nhận mối liên hệ sưu liệu, nhắc nhỡ kỹ sư phần mềm thay đổi sưu liệu có tác động đến sưu liệu khác, ghi nhận thay đổi sưu liệu Nếu thay đổi hệ thống tác động giao diện người dùng cách trực tiếp thêm tiện ích mở rộng tiện ích tồn 5.5 Các mẫu sưu liệu cho qui trình làm phần mềm 5.5.1 Xác định yêu cầu (SRS) Software Requirements Specifications (w/o Use Cases) Chuẩn IEE 830-1984 Giới thiệu 1.1 Mục đích 1.2 Phạm vi 1.3 Định nghĩa (định nghĩa, từ viết tắt) 1.4 Tài liệu tham khảo 1.5 Mô tả cấu trúc tài liệu Mô tả chung 2.1 Tổng quan sản phẩm 2.2 Chức sản phẩm 2.3 Đối tượng người dùng 2.4 Ràng buộc tổng thể 2.5 Giả thiết lệ thuộc Yêu cầu chi tiết 3.1 Yêu cầu chức 3.1.1 Yêu cầu chức 3.1.1.1 Giới thiệu 3.1.1.2 Dữ liệu vào 3.1.1.3 Xử lý 3.1.1.4 Kết 3.1.2 Yêu cầu chức 3.1.n Yêu cầu chức n 128 … b Thiết kế Sưu liệu cho giai đoạn thiết kế có mẫu thiết kế sau:  Thiết kế sở liệu (Database Design)  Thiết kế ràng buộc (Design Criteria)  Sưu liệu kiến trúc phần mềm (Software Architecture Document)  Thiết kế Thành phần (Components Design) 5.5.2 Mô tả thiết kế phần mềm (SDD) Software Design Descriptions Chuẩn IEEE 1016-1998 Introduction (Giới thiệu) Purpose (mục đích) Scope (Phạm vi) Definitions, acronyms, and abbreviations (Định nghĩa, viết tắt) References (Tham khảo) Decomposition description (Mô tả phân rã) Dependency description (Mô tả phụ thuộc) Interface description (mô tả giao diện) Detailed design (thiết kế chi tiết) 5.5.3 System Design Rationale Document (SDRD) Introduction (Giới thiệu) 1.1 Purpose of the document (Mục đích sưu liệu) 1.2 Design goals (Mục tiêu thiết kế đạt được) 1.3 Definitions, acronyms, and abbreviations 1.4 References (Tham khảo) 1.5 Overview (Tổng quan) Rationale for Current Software Architecture Rationale for Proposed Software Architecture 3.1 Overview (Tổng quan) 3.2 Rationale for Subsystem decomposition 3.3 Rationale for Hardware/software mapping 3.4 Rationale for Persistent data management 3.5 Rationale for Access control and security 3.6 Rationale for Global software control 3.7 Rationale for Boundary conditions Subsystem Services Glossary 129 [...]... khai các giải pháp - Hiểu sự ảnh hưởng của công việc tương lai - Đưa ra những quyết định hợp lý dựa trên thông tin xác thực Lập báo cáo Quản trị viên dự án, trưởng nhóm và thành viên nhóm phải: - Lắng nghe tin nhắn chuyển đến - Chấp nhận tin xấu và tốt - Hỗ trợ tích cực các thành viên trong nhóm để vượt qua trở ngại Trao đổi tình trạng dự án • Tập trung vào các thành tựu của các mục tiêu kinh doanh,