Bài giảng Công nghệ phần mềm: Phần 1 ĐH Phạm Văn Đồng

(NB) Bài giảng Công nghệ phần mềm: Phần 1 cung cấp những thông tin như tổng quan về phần mềm và các lớp phần mềm, kiến trúc các thành phần của phần mềm, công nghệ phần mềm, vòng đời phát triển phần mềm, xác định yêu cầu, phân tích và đặc tả yêu cầu.

TRƯỜNG ĐẠI HỌC PHẠM VĂN ĐỒNG KHOA CÔNG NGHỆ THÔNG TIN  PHẠM THỊ MINH THƯƠNG BÀI GIẢNG CÔNG NGHỆ PHẦN MỀM Dành cho sinh viên bậc Đại học chuyên ngành Công nghệ thông tin Quảng Ngãi, tháng 12 năm 2018 TRƯỜNG ĐẠI HỌC PHẠM VĂN ĐỒNG KHOA CÔNG NGHỆ THÔNG TIN  PHẠM THỊ MINH THƯƠNG BÀI GIẢNG CÔNG NGHỆ PHẦN MỀM Dành cho sinh viên bậc Đại học chuyên ngành Công nghệ thông tin TÀI LIỆU LƯU HÀNH NỘI BỘ Bài giảng Cơng nghệ phần mềm MỤC LỤC LỜI NĨI ĐẦU Chương MỞ ĐẦU 1.1 PHẦN MỀM VÀ CÁC LỚP PHẦN MỀM 1.1.1 Phần mềm 1.1.2 Đặc trưng phần mềm 1.1.3 Các lớp phần mềm 1.1.4 Phân loại phần mềm 1.2 KIẾN TRÚC CÁC THÀNH PHẦN CỦA PHẦN MỀM 1.2.1 Thành phần giao tiếp (giao diện) 1.2.2 Thành phần liệu 1.2.3 Thành phần xử lý 1.3 CÔNG NGHỆ PHẦN MỀM 1.3.1 Lịch sử đời 1.3.2 Định nghĩa mục tiêu 1.3.3 Chất lượng phần mềm 10 1.3.4 Các đối tượng nghiên cứu 12 1.4 VÒNG ĐỜI PHÁT TRIỂN PHẦN MỀM 12 1.4.1 Giai đoạn xác định 12 1.4.2 Giai đoạn phát triển 13 1.4.3 Giai đoạn bảo trì 13 1.5 QUY TRÌNH CƠNG NGHỆ PHẦN MỀM 14 1.5.1 Quy trình giai đoạn 14 1.5.2 Quy trình giai đoạn 15 1.5.3 Quy trình giai đoạn 16 1.5.4 Quy trình giai đoạn 17 1.5.5 Quy trình giai đoạn 18 1.6 MÔ HÌNH TIẾN TRÌNH PHẦN MỀM 19 1.6.1 Mơ hình thác nước – Waterfall model 20 1.6.2 Mô hình mẫu thử – Prototyping model 21 1.6.3 Mơ hình xoắn ốc – Sprial model 22 1.6.4 Mơ hình tăng trưởng 24 1.6.5 Mơ hình chữ V 25 1.6.6 Các công nghệ hệ thứ (Fourth Generation Techniques – 4GT) 26 Bài giảng Cơng nghệ phần mềm 1.7 PHƯƠNG PHÁP, CƠNG CỤ PHÁT TRIỂN PHẦN MỀM 27 1.7.1 Phương pháp xây dựng phần mềm 27 1.7.2 Công cụ môi trường phát triển phần mềm 30 1.8 CÂU HỎI TRẮC NGHIỆM, BÀI TẬP THẢO LUẬN 31 Chương XÁC ĐỊNH YÊU CẦU, PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU 32 2.1 MÔ TẢ YÊU CẦU 32 2.1.1 Tên công việc 32 2.1.2 Người thực 33 2.1.3 Thời gian, địa điểm 33 2.1.4 Cách thức tiến hành quy định liên quan 33 2.2 PHÂN LOẠI YÊU CẦU 34 2.2.1 Yêu cầu chức 34 2.2.2 Yêu cầu phi chức 36 2.3 CÁC BƯỚC XÁC ĐỊNH YÊU CẦU 37 2.3.1 Khảo sát trạng 37 2.3.2 Lập danh sách yêu cầu 39 2.4 PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU 41 2.4.1 Đại cương 41 2.4.2 Nghiên cứu khả thi 42 2.4.3 Các nguyên lý phân tích 43 2.4.4 Phân tích có cấu trúc 44 2.4.5 Phân tích hướng đối tượng 46 2.4.6 Đặc tả yêu cầu phần mềm 48 2.5 MƠ HÌNH HĨA U CẦU 51 2.5.1 Mơ hình luồng liệu 52 2.5.2 Các bước lập sơ đồ luồng liệu 52 2.6 LÀM BẢN MẪU TRONG QUÁ TRÌNH PHÂN TÍCH 54 2.6.1 Các bước làm mẫu 54 2.6.2 Lợi ích hạn chế phát triển mẫu 55 2.7 CÂU HỎI TRẮC NGHIỆM, BÀI TẬP THẢO LUẬN 56 Chương THIẾT KẾ PHẦN MỀM 58 3.1 TỔNG QUAN 58 3.1.1 Khái niệm thiết kế phần mềm 58 3.1.2 Tầm quan trọng 59 3.1.3 Kết thiết kế phần mềm 60 Bài giảng Công nghệ phần mềm 3.1.4 Phương pháp thiết kế phần mềm 62 3.1.5 Thiết kế phần mềm yêu cầu chất lượng 63 3.1.6 Chất lượng thiết kế 65 3.2 THIẾT KẾ DỮ LIỆU 69 3.2.1 Tổng quan 69 3.2.2 Kết thiết kế liệu 69 3.2.3 Quá trình thiết kế 70 3.2.4 Thiết kế liệu yêu cầu chất lượng 70 3.3 THIẾT KẾ GIAO DIỆN 75 3.3.1 Tổng quan 75 3.3.2 Kết thiết kế 76 3.3.3 Phân loại hình giao diện 77 3.3.4 Quá trình thiết kế 77 3.3.5 Nguyên tắc thiết kế giao diện người dùng Jakob Nielsen 77 3.4 THIẾT KẾ HƯỚNG CHỨC NĂNG 80 3.5 THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 80 3.5.1 Cách tiếp cận 80 3.5.2 Các đặc trưng 81 3.5.3 Cơ sở thiết kế hướng đối tượng 81 3.5.4 Các bước thiết kế 82 3.5.5 Ưu, nhược điểm thiết kế hướng đối tượng 83 3.6 CÂU HỎI TRẮC NGHIỆM, BÀI TẬP THẢO LUẬN 83 Chương CÀI ĐẶT, KIỂM THỬ VÀ BẢO TRÌ PHẦN MỀM 84 4.1 CÁC NGÔN NGỮ LẬP TRÌNH 84 4.1.1 Các đặc trưng 84 4.1.2 Lựa chọn ngơn ngữ lập trình 86 4.1.3 Phong cách lập trình 86 4.2 KIỂM THỬ PHẦN MỀM 88 4.2.1 Khái niệm kiểm thử 88 4.2.2 Mục tiêu giới hạn 90 4.2.3 Các loại kiểm thử 90 4.2.4 Các mức độ kiểm thử 97 4.2.5 Những lỗi phần mềm 102 4.2.6 Nguyên tắc kiểm thử 104 4.2.7 Thiết kế test case 105 Bài giảng Công nghệ phần mềm 4.2.8 Lập kế hoạch tài liệu kiểm thử 108 4.3 BẢO TRÌ PHẦN MỀM 108 4.3.1 Hoạt động bảo trì phần mềm phân loại 108 4.3.2 Đặc điểm bảo trì phần mềm 110 4.4 CÂU HỎI TRẮC NGHIỆM, BÀI TẬP THẢO LUẬN 112 TÀI LIỆU THAM KHẢO 114 Bài giảng Cơng nghệ phần mềm LỜI NĨI ĐẦU Ngày nay, Công nghệ phần mềm tới kỷ nguyên mới, lĩnh vực nghề nghiệp “có sức đề kháng” cao với tình trạng suy thối kinh tế Điều cho thấy tiềm ngành công nghệ phần mềm lĩnh vực công nghệ thông tin nói riêng thị trường nhân nói chung Bài giảng Công nghệ phần mềm biên soạn theo nội dung phân phối chương trình Trường Đại học Phạm Văn Đồng xây dựng Nội dung giảng Công nghệ phần mềm bao gồm chương với thời lượng 30 tiết, cung cấp cho sinh viên kiến thức phát triển phần mềm, từ phần mềm đặt hàng sản xuất phần mềm đưa vào sử dụng Quá trình trải qua giai đoạn: xác định yêu cầu, phân tích đặc tả yêu cầu, thiết kế, cài đặt, kiểm thử, bảo trì; tương ứng với giai đoạn có phương pháp cơng cụ hỗ trợ theo Mặc dù thân có cố gắng biên soạn giảng không tránh khỏi thiếu sót, mong nhận nhiều ý kiến đóng góp bạn đọc, đồng nghiệp sinh viên Bài giảng có sử dụng tư liệu đồng nghiệp Bài giảng Công nghệ phần mềm Chương MỞ ĐẦU Thời lượng: 07 tiết lý thuyết Kết thúc chương này, sinh viên có thể: - Biết kiến trúc lớp phần mềm - Hiểu phải đời Công nghệ phần mềm - Biết mơ hình phát triển phần mềm - Biết phương pháp, công cụ phát triển phần mềm 1.1 PHẦN MỀM VÀ CÁC LỚP PHẦN MỀM 1.1.1 Phần mề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 hồn thành cơng việc người 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ụ Trong đó, - Lĩnh vực chun ngành: Các lĩnh vực mặt đời sống, xã hội: Giáo dục, Y tế, Kinh doanh,… - Nhà chuyên môn: Người phận tham gia vào hoạt động lĩnh vực tương ứng - Thao tác nghiệp vụ: Các công việc nhà chuyên môn giới thực lĩnh vực tương ứng Nhiệm vụ 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 hoạt động giới thực góc độ thu hẹp máy tính Q trình sử dụng phần mềm q trình người dùng thực cơng việc máy tính để hồn tất công việc tương đương giới thực Quá trình gồm bước: - Bước 1: Chọn công việc muốn thực hiện, chẳng hạn Thuê băng đĩa Trả băng đĩa… - Bước 2: Cung cấp liệu liên quan đến công việc cần thực Bài giảng Công nghệ phần mềm - Bước 3: Xem kết việc thực công việc thơng qua hình kết hay báo biểu in 1.1.2 Đặc trưng phần mềm Đặc trưng phần mềm khác với đặc trưng phần cứng, nên việc phát triển phần mềm gặp nhiều khó khăn chi phí cho phần mềm cao Dưới yếu tố tạo phức tạp trình phát triển sử dụng bảo trì phần mềm a Phần mềm khơng chế tạo theo nghĩa cổ điển Phần mềm thiết kế, phát triển phần cứng, khơng định hình trước Chỉ phát triển xong người ta có sản phẩm cụ thể hiểu có hiệu hay khơng Giá thành phần cứng chủ yếu bị chi phối giá thành nguyên vật liệu tương đối dễ kiểm soát Trong đó, giá thành phần mềm chủ yếu tập trung vào chi phí nhân cơng Q trình phát triển phần mềm phụ thuộc vào người (hiểu biết, khả vận dụng, kinh nghiệm cách thức quản lý) tiến hành phát triển điều kiện môi trường (kỹ thuật, xã hội) đa dạng không ngừng thay đổi Do đó, khó ước lượng chi phí hiệu phần mềm b Phần mềm khơng hỏng thối hóa theo thời gian Phần mềm không cảm ứng tác động môi trường vốn gây cho phần cứng bị mòn cũ đi, thối hóa theo thời gian Thực tế, phần mềm trải qua thời gian sử dụng cần phải thay đổi (bảo trì) đề đáp ứng nhu cầu thay đổi tổ chức sử dụng Mỗi thay đổi, phần mềm xuất thêm số khiếm khuyết tránh, điều làm cho số lỗi tiềm ẩn phần mềm tăng lên Dần dần, phần mềm bị thoái hóa tỷ lệ sai hỏng ngày cảng tăng lên đến mức gây nên thiệt hại chấp nhận Việc bảo trì phần mềm phức tạp nhiều có chất khác hẳn so với bảo trì phần cứng phức tạp hệ thống phần mềm khơng có sẵn phần thay cho phận bị lỗi Chúng ta không thay phận bị lỗi có sẵn mà thực phải tạo module Do đó, thơng thường có nhà sản xuất phần mềm bảo trì (sửa chữa) hỏng hóc Bài giảng Cơng nghệ phần mềm c Phần lớn phần mềm xây dựng từ đầu, lắp ráp từ thành phần có sẵn - Phần mềm khơng có danh mục thành phần cố định phần cứng - Phần mềm thường đặt hàng theo đơn vị hoàn chỉnh, theo yêu cầu riêng khách hàng - Phần mềm lắp ráp theo khn mẫu có sẵn Yêu cầu với phần mềm thay đổi theo mơi trường cụ thể mà xây dựng Môi trường phần mềm (gồm phần cứng, phần mềm nền, người tổ chức) định dạng từ trước lại thay đổi thường xuyên 1.1.3 Các lớp phần mềm Lớp phần mềm hệ thồng phần mềm lĩnh vực hoạt động Do lĩnh vực hoạt độ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 lĩnh vực (thậm chí lĩnh vực khác) Bảng 1 Các phần mềm lớp phần mềm tương ứng STT Lớp phần mềm Các phần mềm Trò chơi Cờ ca rơ, cờ tướng, tetris,… Bán hàng Thuốc tây, vật liệu xây dựng, máy tính,… Cho mượn Sách, truyện, phim, Quản lý học sinh Mầm non, trung học, trung tâm,… 1.1.4 Phân loại phần mềm Chúng ta chia phần mềm theo miền ứng dụng thành loại sau: a Phần mềm hệ thống - Là tập hợp chương trình viết để phục vụ cho chương trình khác - Xử lý cấu trúc thơng tin phức tạp xác định (trình biên dịch, trình soạn thảo, tiện ích quản lý tệp) - Đặc trưng tương tác chủ yếu với phần cứng máy tính Bài giảng Cơng nghệ phần mềm kỹ thuật có đủ đảm bảo thực giải pháp công nghệ dự định áp dụng hay không Khả thi kỹ thuật thường lĩnh vực khó thâm nhập giai đoạn phân tích Điều thực chất tiến trình phân tích xác định nhu cầu cần tiến hành song song với việc xác nhận tính khả thi kỹ thuật Các xem xét thường gắn với tính khả thi kỹ thuật bao gồm: - Rủi ro xây dựng: liệu phần tử hệ thống thiết kế cho đạt chức hiệu suất cần thiết thỏa mãn ràng buộc phân tích khơng - Có sẵn tài nguyên: có sẵn nhân viên cho việc xây dựng phần tử hệ thống xét không? Các tài nguyên cần thiết khác (phần cứng phần mềm) có sẵn cho việc xây dựng hệ thống không? - Công nghệ: công nghệ liên quan đạt tới trạng thái sẵn sàng hỗ trợ cho hệ thống chưa? c Khả thi pháp lý Nghiên cứu đưa phán việc có hay khơng xâm phạm, vi phạm pháp luật hay khó khăn pháp lý từ việc xây dựng vận hành hệ thống Tính khả thi pháp lý bao gồm phạm vi rộng mối quan tâm kể hợp đồng, nghĩa vụ pháp lý, vi phạm vô số bẫy pháp lý khác mà thường nhân viên kỹ thuật tới Trong nước, vấn đề khả thi pháp lý chưa coi trọng cách mức có số luật liên quan đến CNTT bảo hộ quyền d Tính khả thi hoạt động Đánh giá tính khả thi việc vận hành hệ thống Trong phương án người ta cần xem xét hệ thống vận hành trơi chảy hay không khuôn khổ tổ chức điều kiện quản lý mà tổ chức (người dùng, khách hàng) có Mức độ phương án xem xét tới nghiên cứu khả thi thường bị giới hạn ràng buộc chi phí thời gian 2.4.3 Các nguyên lý phân tích Người ta xây dựng số phương pháp phân tích đặc tả phần mềm Những người nghiên cứu xác định vấn đề nguyên nhân chúng, 43 Bài giảng Công nghệ phần mềm xây dựng quy tắc thủ tục để vượt qua chúng Mỗi phương pháp có ký pháp quan điểm riêng Tuy nhiên, tất phương pháp có quan hệ với tập hợp nguyên lý bản: - Miền thông tin vấn đề phải biểu diễn lại hiểu rõ - Các mơ hình mô tả cho thông tin, chức hành vi hệ thống cần phải xây dựng - Các mô hình (và vấn đề) phải phân hoạch theo cách để lộ chi tiết theo kiểu phân tầng (hay cấp bậc) - Tiến trình phân tích phải từ thông tin chất hướng tới chi tiết cài đặt Bằng cách áp dụng nguyên lý này, người phân tích tiếp cận tới vấn đề cách hệ thống Miền thông tin cần phải xem xét cho người ta hiểu rõ chức cách đầy đủ Các mơ hình dùng việc trao đổi thông tin dễ dàng theo cách ngắn gọn Việc phân hoạch vấn đề sử dụng để làm giảm độ phức tạp Những cách nhìn nhận từ góc độ chất góc độ cài đặt phần mềm cần thiết để bao hàm ràng buộc logic yêu cầu xử lý áp đặt nên ràng buộc vật lý phần tử hệ thống khác áp đặt nên 2.4.4 Phân tích có cấu trúc Phân tích có cấu trúc hoạt động xây dựng mơ hình Bằng cách dùng ký pháp cho phương pháp phân tích có cấu trúc, tạo mơ hình mô tả luồng nội dung thông tin (dữ liệu điều kiện), phân hoạch hệ thống theo chức năng, hành vi mô tả chất nội dung phải xây dựng Cơ chế phân tích có cấu trúc sau: a Tạo mơ hình luồng liệu Mơ hình luồng liệu (Data Flow Diagram - DFD) cho phép xem toàn sơ đồ luồng liệu bên hệ thống, cách thức liệu xử lý bên hệ thống Có nhiều mức chi tiết khác Khi DFD làm mịn tới mức chi tiết người phân tích thực phân rã chức hệ thống, đồng thời việc làm mịn DFD phát sinh làm mịn tương ứng liệu chuyển qua tiến trình nằm ứng dụng b Tạo mơ hình luồng điều khiển 44 Bài giảng Cơng nghệ phần mềm Đối với nhiều kiểu ứng dụng xử lý liệu, DFD tất điều cần thiết để có nhìn ý nghĩa u cầu phần mềm Tuy nhiên, tồn lớp ứng dụng rộng rãi hơn, điều khiển kiện thay liệu, tạo thơng tin điều khiển không báo cáo hay hiển thị, xử lý thông tin với mối quan tâm chủ yếu thời gian hiệu Những ứng dụng đồi hỏi mơ hình luồng điều khiển (Control Flow Diagram – CFD) bên cạnh DFD c Đặc tả điều khiển Đặc tả điều khiển (Control Specification – CSPEC) biểu diễn cho hành vi hệ thống theo hai cách khác CSPEC chứa biểu đồ chuyển trạng thái (State Transition Diagram – STD) đặc tả cho hành vi Nó chứa bảng kích hoạt chương trình (PAT) – đặc tả tổ hợp cho hành vi Bằng cách nghiên cứu STD, người kỹ sư phần mềm xác định hành vi hệ thống điều quan trọng xác định liệu có lỗ hổng hành vi đặc tả không Một kiểu biểu diễn hành vi kích hoạt tiến trình PAT PAT biểu thị cho thơng tin chứa hồn cảnh tiến trình, trạng thái Tức bảng chi tiến trình mơ hình luồng gọi đến kiện xuất PAT dùng bảng hướng dẫn cho người thiết kế, người phải xây dựng cách điều hành kiểm sốt tiến trình biểu diễn mức CSPEC mô tả hành vi hệ thống, khơng cung cấp thông tin cách làm việc tiến trình xem kết hành vi d Đặc tả tiến trình Đặc tả tiến trình (Process Specification – PSPEC) dùng để mô tả cho tiến trình mơ hình luồng xuất mức cuối việc làm Nội dung đặc tả tiến trình bao gồm đoạn văn tường thuật, ngơn ngữ thiết kế chương trình (PDL) mơ tả thuật tốn xử lý, phương trình tốn học, bảng, biểu đồ hay lược đồ Bằng cách đưa PSPEC kèm với tiến tình mơ hình luồng, người kỹ sư phần mềm tạo “mini đặc tả’ dùng bước việc tạo đặc tả yêu cầu phần mềm dùng hướng dẫn cho việc thiết kế thành phần chương trình cài đặt cho tiến trình 45 Bài giảng Cơng nghệ phần mềm 2.4.5 Phân tích hướng đối tượng Phân tích có cấu trúc đưa khung nhìn đầu vào – xử lý – đầu yêu cầu Dữ liệu xem xét riêng rẽ từ xử lý chuyển liệu Hành vi hệ thống, quan trọng chiếm vị trí thứ yếu phân tích có cấu trúc Phương pháp phân tích hướng đối tượng (Object Oriented Analysis – OOA) hình thành thập niên 80 dựa ý tưởng lập trình hướng đối tượng Phương pháp phát triển, hoàn thiện phổ dụng Nó dựa số khái niệm sau: Đối tượng (Object): gồm liệu thủ tục tác động lên liệu Đóng gói (Encapsulation): khơng cho phép tác động trực tiếp lên liệu đối tượng mà phải thông qua phương pháp trung gian Lớp (Class): tập hợp đối tượng có chung cấu trúc liệu phương pháp Kế thừa (Heritage): tính chất kế thừa đặc tính cho phép định nghĩa lớp từ lớp có cách thêm vào liệu mới, phương pháp kế thừa đặc tính lớp cũ a Các thành phần chung cho mơ hình OOA Monarchi Puhr xác định tập thành phần mô tả chung xuất OOA Các thành phần tĩnh cấu trúc tự nhiên xác định đặc tính nắm giữ suốt vòng đời ứng dụng Các thành phần động tập trung vào điều khiển có ý nghĩa với xử lý kiện thời gian Các thành phần sau xác định: - Khung nhìn tĩnh lớp ngữ nghĩa: Yêu cầu đánh giá lớp rút phần mơ hình phân tích Các lớp tồn suốt vòng đời ứng dụng thừa kế dựa ngữ nghĩa yêu cầu khách hàng - Khung nhìn tĩnh thuộc tính: Các lớp phải mô tả rõ ràng Các thuộc tính liên kể với lớp cung cấp mơ tả lớp, phương thức thích hợp với lớp - Khung nhìn tĩnh mối quan hệ: Các đối tượng nối với theo nhiều cách Mơ hình phân tích phải mơ tả quan hệ từ phương thức xác định 46 Bài giảng Cơng nghệ phần mềm - Khung nhìn hành vi: Mối quan hệ xác định tập hành vi thích hợp với kịch sử dụng hệ thống Các hành vi thực cách xác định dãy phương thức - Khung nhìn động liên lạc: Các đối tượng liên lạc với dựa loại kiện gây chuyển trạng thái hệ thống - Khung nhìn động điều khiển thời gian: Tính tự nhiên thời gian kiện gây chuyển trạng thái phải mô tả b Trường hợp sử dụng Dựa yêu cầu người dùng, người kỹ sư phần mềm tạo tập kịch xác định luồng sử dụng cho hệ thống Kịch thường gọi trường hợp sử dụng (Use Case – UC) Để tạo trường hợp sử dụng, người phân tích xác định kiểu đối tượng (hay thiết bị) khác sử dụng hệ thống hay sản phẩm Các tác nhân mơ tả vai trò mà người hay thiết bị đảm nhận hệ thống Cần phải ý tác nhân người sử dụng không giống Người sử dụng đóng vai trò khác sử dụng hệ thống, tác nhân mơ tả lớp hay thực thể đảm nhận vai trò Khi xác định xong tác nhân, ta phát triển trường hợp sử dụng UC mô tả tác nhân tương tác với hệ thống, Jacobson đề nghị trường hợp sử dụng nên trả lời câu hỏi sau: - Các tác nhân thực công việc hay chức nào? - Các tác nhân tạo ra, thay đổi thông tin hệ thống nào? - Các tác nhân có thơng báo cho hệ thống thay đổi môi trường bên ngồi hay khơng? - Tác nhân muốn thơng tin từ hệ thống? - Tác nhân có muốn thơng báo thay đổi không mong đợi không? Mỗi trường hợp sử dụng cung cấp kịch rõ ràng tương tác tác nhân hệ thống cần phát triển theo cách tương tự Cần xem xét cẩn thận UC, có thành phần mơ hồ, phải xem lại UC để phát vấn đề 47 Bài giảng Công nghệ phần mềm c Các mơ hình khác Sinh viên tự nghiên cứu tài liệu OOA 2.4.6 Đặc tả yêu cầu phần mềm Tài liệu xác định yêu cầu mô tả hướng khách hàng viết ngôn ngữ khách hàng Khi dùng ngơn ngữ tự nhiên khái niệm trừu tượng Tài liệu đặc tả yêu cầu (đặc tả chức năng) mô tả hướng người phát triển, kaf sở hợp đồng làm phần mềm Nó khơng phép mơ hồ, không dẫn đến hiểu nhầm khách hàng người phát triển Với yêu cầu mơ hồ người phát triển thực cách rẻ khách hàng khơng muốn Do khách hàng đòi hỏi sửa đổi chức phần mềm gần hồn thiện khiến cho chi phí tăng chậm thời điểm bàn giao Chi phí cho sửa sai sót phát biểu yêu cầu lớn, đặc biệt sai sot phát bắt đầu xây dựng hệ thống Theo số thống kê 85% mã phải viết lại thay đổi yêu cầu 12% lỗi phát năm đầu sử dụng đặc tả u cầu khơng xác Do đó, việc đặc tả xác u cầu mối quan tâm đặt lên hàng đầu Có hai phương pháp đặc tả là: - Đặc tả phi hình thức: cách đặc tả ngôn ngữ tự nhiên - Đặc tả hình thức: cách đặc tả ngôn ngữ nhân tạo (ngôn ngữ đặc tả), cơng thức biểu đồ Đặc tả phi hình thức (ngôn ngữ tự nhiên) thuận tiện cho việc xác định u cầu nhiều khơng thích hợp với đặc tả u cầu vì: - Khơng phải lúc người đọc người viết đặc tả ngôn ngữ tự nhiên hiểu từ - Ngôn ngữ tự nhiên mềm dảo yêu cầu liên quan đến biểu diễn hình thức hồn tồn khác người phát triển không nhận mối liên quan - Các yêu cầu khó phân hoạch cách hữu hiệu hiệu việc thay đổi xác định cách kiểm tra tất u cầu chức khơng phải nhóm yêu cầu liên quan 48 Bài giảng Công nghệ phần mềm Các ngơn ngữ đặc tả (đặc tả hình thức) khắc phục hạn chế trên, nhiên đa số khách hàng lại không thông thạo ngôn ngữ Thêm ngơn ngữ đặc tả hình thức thường phục vụ cho nhóm lĩnh vực riêng biệt việc đặc tả hình thức cơng việc tốn thời gian Một cách tiếp cận bên cạnh đặc tả hình thức người ta viết giải ngôn ngữ tự nhiên để giúp khách hàng dễ hiểu Tuy nhiên, thực tế có nhiều loại đặc tả: đặc tả thuật toán, đặc tả cú pháp, đặc tả qua sơ đồ,… a Các nguyên lý đặc tả Đặc tả xem tiến trình biểu diễn Mục đích cuối đặc tả yêu cầu biểu thị cho dẫn tới việc cài đặt phần mềm thành công Balzer Goldman đề nghị nguyên lý đăch tả tốt Nguyên lý 1: Phân tách chức với cài đặt Đặc tả mô tả điều mong muốn, khơng phải cách thực (cài đặt) Dạng đặc tả sử dụng dạng hàm toán học: Với tập liệu đầu vào cho, tạo tập liệu đầu đặc biệt Kết hàm toán học không bị ảnh hưởng môi trường bao quanh Nguyên lý 2: Cần ngôn ngữ đặc tả hệ thống hướng tiến trình Xét tình mơi trường động thay đổi ảnh hưởng tới hành vi thực thể mà có tương tác với mơi trường Hành vi khơng thể biểu diễn dạng hàm toán học đầu vào Thay thế, cần phải sử dụng cách biểu diễn khác – cách mơ tả hướng tiến trình, đặc tả đạt cách xác định mơ hình thao tác mong muốn đạt hệ thống dạng công việc đáp ứng chức kích thích khác từ môi trường Nguyên lý 3: Đặc tả phải bao gồm hệ thống có phần mềm thành phần Một hệ thống bao gồm thành phần tương tác Chỉ bên hoàn cảnh hệ thống toàn tương tác thành phần hành vi thành phần riêng xác định Nói chung, hệ thống mơ hình hóa tập hợp vật tích cực thụ động Những vật có liên quan lẫn 49 Bài giảng Công nghệ phần mềm qua thời gian mối quan hệ vật thay đổi Mối quan hệ động đưa kích thích cho vật tích cực, gọi tác nhân, đáp ứng Sự đáp ứng gây thay đổi thêm nữa, tạo thêm kích thích tác nhân đáp ứng lại Nguyên lý 4: Đặc tả phải bao gồm môi trường mà hệ thống vận hành Tương tự, mơi trường mà hệ thống vận hành tương tác với phải xác định Nguyên lý 5: Đặc tả hệ thống phả mơ hình nhận thức Đặc tả hệ thống phải mơ hình nhận thức khơng phải mơ hình thiết kế hay cài đặt Nó phải mơ tả hệ thống cộng đồng người sử dụng cảm nhận thấy Các vật mà thao tác phải tương ứng với vật lĩnh vực đó; tác nhân phải mơ hình cho cá nhân, tổ chức trang thiết bị lĩnh vực đó; hành động họ thực phải mơ hình cho hoạt động thực tế xuất lĩnh vực Nguyên lý 6: Đặc tả phải thể tính vận hành Đặc tả phải đầy đủ hình thức để dùng việc xác định liệu cài đặt đề nghị có thỏa mãn đặc tả cho trường hợp kiểm thử tùy ý không Tức là, với kết việc cài đặt tập liệu chọn cách tùy ý, phải dùng đặc tả để xác định tính hợp lệ cho kết Điều kéo theo đặc tả, đặc tả hoàn toàn cách thức, hành động sinh hành vi, số hành vi phải có cài đặt đề nghị Do đó, theo nghĩa mở rộng, đặc tả phải thể tính vận hành Nguyên lý 7: Đặc tả chấp nhận dung sai tính khơng đầy đủ Khơng đặc tả đầy đủ hồn tồn Mơi trường tồn thường phức tạp cho điều Một đặc tả mơ hình – trừu tượng hóa – tình thực (hay mường tượng) đo Do đo, khơng đầy đủ Ngun lý 8: Đặc tả phải cục hóa ghép lỏng lẻo Yêu cầu thường xuyên thay đổi nên đặc tả có nhiều thay đổi Với nhiều thay đổi xuất cho đặc tả, điểm mấu chốt nội dung cấu trúc chọn để làm phù hợp hoạt động Yêu cầu cho phù hợp thơng tin bên 50 Bài giảng Cơng nghệ phần mềm đặc tả phải cục hóa cho phần nhỏ (một cách lý tưởng) cần phải sửa đổi thông tin thay đổi, chỗ đặc tả cần cấu trúc (ghép) cách lỏng lẻo phần thể thêm vào hay loại bỏ cách dễ dang, cấu trúc điều chỉnh cách tự động b Các mức trừu tượng đặc tả Các đặc tả thể vài mức trừu tượng khác với mối liên quan mức Mỗi mức nhắm đến đối tượng đọc khác nhau, dựa vào họ đánh giá thiết kế nhà phát triển phần mềm Các mức là: Mức 1: Định yêu cầu Được thể ngôn ngữ tự nhiên dịch vụ mà hệ thống phải cung cấp Phần phải viết cho dễ hiểu khách hàng người quản lý hợp đồng, người mua sản phẩm phần mềm người sử dụng Kỹ thuật đặc tả phi hình thức thích hợp cho mức đặc tả Mức 2: Đặc tả yêu cầu Tài liệu nêu dịch vụ cách chi tiết Tài liệu đơi gọi tài liệu đặc tả chức Yêu cầu đặc tả mức phải xác đến mức làm sở cho hợp đồng nhà phát triển phần mềm khách hàng Đồng thời cần viết cho dễ hiểu nhân viên kỹ thuật nơi mua phần mềm nơi phát triển hệ thống Kỹ thuật đặc tả hình thức thích hợp cho mức đặc tả vậy, nhiên tùy thuộc vào trình độ kiến thức khách hàng Tốt ta dùng loại hỗn hợp để đặc tả Mức 3: Đặc tả phầm mềm/đặc tả thiết kế (đây mô tả trừu tượng cho phần mềm) Dùng làm sở cho việc thiết kế thực thi Cần thể quan hệ rõ ràng tư liệu đặc tả yêu cầu Ta phải xác định rằng: đối tượng đọc chủ yếu kỹ sư phần mềm người sử dụng người quản lý Kỹ thuật đặc tả hình thức hồn tồn phù hợp cho mức đặc tả 2.5 MƠ HÌNH HĨA U CẦU Các mô tả yêu cầu giai đoạn xác định yêu cầu mô tả chủ yếu thông tin liên quan đến việc thực nghiệp vụ giới thực chưa thể rõ 51 Bài giảng Công nghệ phần mềm nét việc thực nghiệp vụ máy tính Mơ tả thơng qua văn dễ gây nhầm lẫn không trực quan Mục tiêu mơ hình hóa: Cho phép ta hiểu cách chi tiết ngữ cảnh vấn đề cần giải cách trực quan chất (thông tin cốt lõi) yêu cầu Kết quả: Cho mơ hình mơ tả lại tồn hoạt động hệ thống thực Mỗi phương pháp phân tích đưa kiểu sơ đồ hay mơ hình để xây dựng hệ thống 2.5.1 Mơ hình luồng liệu Có nhiều quan điểm khác tạo nhóm ký pháp đồ họa khác để thể DFD Tuy nhiên, quan điểm có số đặc điểm sau: - Trong DFD mức 0, tác nhân ngồi chủ yếu tạo thơng tin cho hệ thống tiêu thụ thông tin hệ thống sinh - DFD mức phân rã thành DFD mức Các tiến trình biểu diễn DFD mức làm mịn thêm mức thấp Việc làm mịn cho DFD tiếp tục tiến trình thực chức dễ dàng, cài đặt thành phần chương trình Trong phân tích u cầu, người kỹ sư phần mềm phát số khía cạnh hệ thống thay đổi hay nâng cao tròn tương lai chưa xác định rõ Một cách khác, người phân tích làm việc phần mềm có để tìm thay đổi Trong hai trường hợp, DFD cho phép dễ dàng cô lập lĩnh vực thay đổi Bằng việc hiểu rõ luồng thông tin qua biên giới lĩnh vực thay đổi, người ta có chuẩn bị tốt cho việc thay đổi tương lai, hay tiến hành thay đổi mà không làm đảo lộn phần tử khác hệ thống 2.5.2 Các bước lập sơ đồ luồng liệu Có nhiều hướng tiếp cận để tạo lập DFD Sau số hướng tiếp cận a Hướng tiếp cận từ xuống Quá trình thực theo hướng tiếp cận sau: - Lập DFD mức - Phân rã DFD mức Có hai cách phân rã: 52 Bài giảng Cơng nghệ phần mềm + Phân rã xử lý phần mềm thành nhiều xử lý định luồng liệu tương ứng luồng liệu + Phân rã luồng liệu nhập xuất thành nhiều luồng liệu định xử lý tương ứng với luồng liệu - Quá trình kết thúc đạt đến sơ đồ tiếp tục phân rã (sơ đồ lá) Đánh giá: Tiếp cận thích hợp với phần mềm có số lượng người dùng, số lượng yêu cầu (nếu ngược lại DFD mức phức tạp khó lập xác) Tiếp cận đặc biệt thích hợp với loại phần mềm mà lý mà hệ thống yêu cầu chưa xác định rõ từ đầu Thơng thường cách tiếp cận sử dụng b Hướng tiếp cận từ lên Quá trình thực theo hướng tiếp cận sau: - Lập DFD mức cao Các sơ đồ không tiến hành phân rã thành sơ đồ có cấp lớn + Tích hợp sơ đồ để tạo lập sơ đồ có cấp nhỏ hơn, thơng thường sơ đồ chọn tích hợp theo tiêu chí cụ thể: người sử dụng, loại yêu cầu Có hai cách tích hợp: + Tích hợp xử lý sơ đồ cấp k vào sơ đồ cấp k-1 giữ nguyên luồng liêu sơ đồ cấp k + Tích hợp đồng thời xử lý luồng liệu sơ đồ cấp k để tạo lập sơ đồ cấp k-1 - Quá trình kết thúc đạt đến DFD mức Đánh giá: Tiếp cận thích hợp với phần mềm có hệ thống yêu cầu chi tiết, cụ thể có quy mơ u cầu (số lượng người dùng, số lượng yêu cầu) thuộc mức trung bình Tiếp cận khó khăn quy mơ u cầu lớn chưa thật rõ ràng chi tiết 53 Bài giảng Công nghệ phần mềm c Hướng tiếp cận phối hợp Quá trình thực theo hướng tiếp cận sau: - Lập DFD mức k theo tiêu chí xác định (sơ đồ cho người dùng, sơ đồ cho phận, sơ đồ cho loại yêu cầu…) - Phân rã DFD mức k thành nhiều DFD mức k+1, tiếp tục đạt sơ đồ - Tích hợp DFD mức k thành DFD mức k-1, tiếp tục đạt DFD mức Đánh giá: Tiếp cận thích hợp cho phần mềm có quy mô yêu cầu lớn, phức tạp Tiếp cận sử dụng thường xuyên thực tế 2.6 LÀM BẢN MẪU TRONG Q TRÌNH PHÂN TÍCH Đối với hệ thống phức tạp, nhiều không nắm yêu cầu khách hàng, khó đánh giá tính khả thi hiệu hệ thống Một cách tiếp cận trường hợp xây dựng mẫu Bản mẫu vừa dùng để phân tích u câu vừa tiến hóa thành sản phẩm cuối 2.6.1 Các bước làm mẫu Xây dựng mẫu gồm bước sau: Bước 1: Đánh giá yêu cầu phần mềm xác định liệu phần mềm cần xây dựng có xứng đáng để làm mẫu không Không phải tất phần mềm đưa tới làm mẫu Ta xác định số nhân tố làm mẫu: lĩnh vực ứng dụng, độ phức tạp ứng dụng, đặc trưng khách hàng đặc trưng dự án Để đảm bảo tính tương tác khách hàng với mẫu, phải đảm bảo điều kiện: - Khách hàng phải cam kết dùng tài nguyên để đánh giá làm mịn mẫu - Khách hàng phải có khả đưa định yêu cầu cách kịp thời 54 Bài giảng Công nghệ phần mềm Bước 2: Với dự án chấp thuận được, người phân tích xây dựng cách biểu diễn vắn tắt cho yêu cầu Trước bắt đầu xây dựng mẫu, người phân tích phải biểu diễn miền thơng tin lĩnh vực, hành vi chức vấn đề xây dựng cách tiếp cận hợp lý tới việc phân hoạch Có thể ứng dụng nguyên lý phân tích tảng (phân tích top-down) phương pháp phân tích yêu cầu Bước 3: Sau duyệt xét mơ hình u cầu, phải tao đặc tả thiết kế vắn tắt cho mẫu Việc thiết kế phải xuất trước bắt đầu làm mẫu Tuy nhiên thiết kế tập trung chủ yếu vào vấn đề thiết kế liệu kiến trúc mức đỉnh không tập trung vào thiết kế thủ tục chi tiết Bước 4: Phần mềm mẫu tạo ra, kiểm thử làm mịn Bản mẫu nên xây dựng cách nhanh chóng với chi phí nhỏ Một cách lý tưởng, mẫu nên lắp ráp từ khối chức (thư viện) có Có thể dùng ngơn ngữ bậc cao hay công cụ tự động để xây dựng mẫu Bước 5: Khách hàng đánh giá làm mịn yêu cầu Bước cốt lõi cách tiếp cận làm mẫu Chính đâu mà khách hàng xem xét cách biểu diễn cài đặt cho yêu cầu phần mềm, gợi ý thay đổi làm cho phần mềm đáp ứng tốt với nhu cầu thực tế Bước 6: Lặp lại bước tất u cầu hình thức hóa đầy đủ hay mẫu tiến hóa thành phần mềm hồn thiện 2.6.2 Lợi ích hạn chế phát triển mẫu Phát triển mẫu đem lại lợi ích sau: - Sự hiểu lầm người phát triển phần mềm người sử dụng phần mềm nhận thấy rõ chức hệ thống trình diễn - Sự thiếu hụt dịch vụ người dùng phát - Sự khó sử dụng nhầm lẫn dịch vụ người dùng thấy rõ sửa lại 55 Bài giảng Công nghệ phần mềm - Đội ngũ phát triển phần mềm tìm u cầu khơng đầy đủ không kiên định họ phát triển mẫu - Một hệ thống hoạt động (mặc dù hạn chế) chứng thuyết minh cho tính khả thi tính hữu ích ứng dụng cho nhà quản lý - Bản mẫu dùng làm sở cho việc viết đặc tả sản phẩm Mặc dù mục tiêu chủ yếu việc tạo mẫu để phát triển, thẩm định yêu cầu phần mềm, có lợi ích khác nhau: - Dùng để huấn luyện người sử dụng từ trước hệ thống phân phối - Dùng q trình thử nghiệm hệ thống Điều nghĩa trường hợp thử vừa dùng cho thử mẫu vừa cho thử hệ thống Kết khác có nghĩa có sai sót Tạo mẫu kỹ thuật giảm bớt rủi ro Một rủi ro lớn việc phát triển phần mềm sai sót mà đến giai đoạn cuối phát việc chỉnh sửa vào thời điểm tốn Kinh nghiệm cho thấy việc tạo mẫu giảm bớt số vấn đề đặc tả yêu cầu giá tổng cộng việc phát triển thấp ta phát triển mẫu Hạn chế cách tiếp cận mẫu là: - Để đơn giản hóa việc tạo mẫu người ta bỏ qua yêu cầu phức tạp Sự thật tạo mẫu vài phần quan trọng hệ thống đặc điểm an toàn-nguy kịch - Các yêu cầu phi chức độ tin cậy, độ an tồn hay hiệu thường khơng biểu thị đầy đủ mẫu - Do tính chưa hồn thiện chức năng/hiệu năng, người dùng không dùng mẫu y cách dùng hệ thống thực hoạt động Do đó, chất lượng đánh giá khách hàng nhiều không cao 2.7 CÂU HỎI TRẮC NGHIỆM, BÀI TẬP THẢO LUẬN Chọn câu trả lời nhất: Câu 1: Cái sau loại yêu cầu phần mềm (a) Yêu cầu chức nghiệp vụ (b) Yêu cầu phi chức (c) Yêu cầu chức hệ thống (d) Yêu cầu phức tạp Câu 2: Kỹ thuật sau kỹ thuật khảo sát trạng 56 Bài giảng Công nghệ phần mềm (a) Quan sát (b) Phỏng vấn (c) Mơ hình luồng liệu (d) Thu thập thông tin, tài liệu Câu 3: DFD viết tắt (a) Data Flow Diagram (b) Descriptive Functional Design (c) Data Flow Design (d) Tất sai Câu 4: OOA viết tắt (a) Object Oriented Analysis (b) Object Oriented Aim (c) Tất sai (d) Aim Oriented Analysis Giải thích tầm quan trọng yêu cầu Nêu cho ví dụ loại yêu cầu Giả sử anh/chị nhà phát triển người dùng hài lòng với mẫu thử mà anh/chị làm Hơn nữa, người dùng muốn mua lại mẫu thử để sử dụng cho công việc thực tế Trong trường hợp này, anh/chị phản hồi sao? 57 ... giảng Công nghệ phần mềm MỤC LỤC LỜI NÓI ĐẦU Chương MỞ ĐẦU 1. 1 PHẦN MỀM VÀ CÁC LỚP PHẦN MỀM 1. 1 .1 Phần mềm 1. 1.2 Đặc trưng phần mềm 1. 1.3... HỌC PHẠM VĂN ĐỒNG KHOA CÔNG NGHỆ THÔNG TIN  PHẠM THỊ MINH THƯƠNG BÀI GIẢNG CÔNG NGHỆ PHẦN MỀM Dành cho sinh viên bậc Đại học chuyên ngành Công nghệ thông tin TÀI LIỆU LƯU HÀNH NỘI BỘ Bài giảng. .. 12 1. 4 VÒNG ĐỜI PHÁT TRIỂN PHẦN MỀM 12 1. 4 .1 Giai đoạn xác định 12 1. 4.2 Giai đoạn phát triển 13 1. 4.3 Giai đoạn bảo trì 13 1. 5 QUY TRÌNH CƠNG NGHỆ PHẦN