Bài giảng Nhập môn Công nghệ phần mềm

185 trang phuongnguyen 6952

Download

Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Nhập môn Công nghệ phần mềm", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

bai_giang_nhap_mon_cong_nghe_phan_mem.pdf

Nội dung text: Bài giảng Nhập môn Công nghệ phần mềm

NHẬP MÔN CÔNG NGHỆ PHẦN MỀM TÀI LIỆU DÀNH CHO SINH VIÊNPTIT CÔNG NGHỆ THÔNG TIN TRẦN ĐÌNH QUẾ
Giới thiệu GIỚI THIỆU Mục tiêu của môn Công nghệ phần mềm là cung cấp cho sinh viên những kiến thức cơ bản về tất cả mọi hoạt động liên quan đến phát triển phần mềm và kiến thức cơ bản về UML trong phát triển phần mềm. Qua môn học này sinh viên có kỹ năng sử dụng công cụ phần mềm để thực hiện các pha trong quá trình phát triển phần mềm và qua đó nâng cao năng lực làm việc nhóm và kỹ năng mềm. Sinh viên tham dự lớp và thực hành đầy đủ đặc biệt tích cực tham gia thảo luận trình bày trên lớp là yêu cầu quan trọng. Nội dung bao gồm các kiểu hệ thống thông tin, các mô hình phát triển phần mềm, lập kế hoạch và quản lý dự án; các pha phát triển phần mềm từ xác định yêu cầu, phân tích, thiết kế đến lập trình – tích hợp; các kiến thức cơ bản về mô hình phần mềm với UML. Mở đầu: Các đặc trưng của phần mềm; Các dạng phần mềm; Các hoạt động trong phát triển phần mềm; Tiến hóa trong phát triển phần mềm Chương 2: Các pha trong phát triển phần mềm. Các tác nhân trong quá trình phát triển phần mềm; Pha xác định yêu cầu; Pha phân tích; Pha thiết kế; Pha cài đặt và tích hợp; Pha bảo trì Chương 3: Các mô hình vòng đời phần mềm Mô hình xây - sửa; Mô hình thác nước; Mô hình bản mẫu nhanh; Mô hình tiến hoá; Mô hình RUP; Mô hình xoắn ốc; So sánh các mô hình Chương 4: Kiểm chứng Vấn đề chất lượng phần mềm; Kiểm chứng phần mềm; Các phương pháp kiểm chứng; Công cụ kiểm chứng Chương 5: Lập kế hoạch và ước lượngPTIT Vấn đề lập kế hoạch và ước lượng dự án phần mềm; Ước lượng thời gian và chi phí; Các thành phần của việc lập kế hoạch dự án phần mềm; Lập kế hoạch cho các dự án phần mềm hướng đối tượng. Chương 6: Xác định yêu cầu Các kỹ thuật xác định yêu cầu; Bản mẫu nhanh; Đặc tả dựa trên bản mẫu nhanh; Sử dụng lại bản mẫu; Đặc tả với bản mẫu; Kiểm thử pha yêu cầu Chương 7: Các phương pháp phân tích truyền thống Viết tài liệu pha đặc tả; Đặc tả phi hình thức; Các kỹ thuật đặc tả nửa hình thức; Mô hình quan hệ thực thể; Máy trạng thái hữu hạn; Các kỹ thuật đặc tả hình thức; So sánh các kỹ thuật đặc tả; Kiểm thử pha đặc tả Chương 8: Phân tích hướng đối tượng 1
Giới thiệu Tổng quan về phân tích hướng đối tượng; Mô hình use case; Mô hình lớp; Mô hình hành động; Kiểm thử pha phân tích hướng đối tượng Chương 9: Thiết kế Tổng quan về pha thiết kế; Thiết kế hướng hành động; Phân tích dòng dữ liệu; Thiết kế hướng đối tượng Chương 10: Cài đặt và tích hợp Các phương pháp cài đặt và tích hợp; Kiểm thử pha cài đặt và tích hợp; Kiểm thử sản phẩm; Kiểm thử chấp nhận Chương 11: Bảo trì Pha bảo trì; Bảo trì hệ phần mềm hướng đối tượng TÀI LIỆU THAM KHẢO [1] Object-Oriented and Classical Software Engineering, Stephen R. Schach, Seventh Edition, Mc Graw Hill, 2008. [2] Giáo trình nhập môn UML, Huỳnh Văn Đức, Đoàn Thiện Ngân, NXB Lao động Xã hội, 2003. PTIT 2
Chương 3: Các mô hình vòng đời MỤC LỤC MỤC LỤC 3 CHƯƠNG 1: MỞ ĐẦU 7 1.2 CÁC KIỂU PHẦN MỀM 7 1.3 KHÍA CẠNH LỊCH SỬ 7 1.4 KHÍA CẠNH KINH TẾ 8 1.5 KHÍA CẠNH BẢO TRÌ 8 1.6 KHÍA CẠNH PHÂN TÍCH VÀ THIẾT KẾ 9 1.7 KHÍA CẠNH LẬP TRÌNH NHÓM 10 1.8 PHƯƠNG PHÁP HƯỚNG ĐỐI TƯỢNG 10 CHƯƠNG 2: CÁC PHA PHÁT TRIỂN PHẦN MỀM 13 2.1 TIẾN TRÌNH THÀNH PHẦN 13 2.2 SQA LÀ GÌ? 14 2.3 PHA YÊU CẦU 14 2.4 PHA ĐẶC TẢ 14 2.5 PHA THIẾT KẾ 15 2.6 PHA CÀI ĐẶT 16 2.7 TÍCH HỢP 16 2.8 CẢI TIẾN TIẾN TRÌNH PHẦN MỀM 16 CHƯƠNG 3 21 CÁC MÔ HÌNH VÒNG ĐỜI PHẦN MỀM 21 3.1 PHÁT TRIỂN PHẦN MỀM 21 3.1.1 Theo lý thuyết phát triển phần mềm: 21 3.1.2 Thực tế phát triển phần mềm 21 3.1.3 Bài toán Winburg Mini 21 3.2 MÔ HÌNH XÂY SỬA 22 3.3 MÔ HÌNH TIẾN HÓA 22 3.4 MÔ HÌNH BẢN MẪU NHANHPTIT 23 3.5. MÔ HÌNH LẶP VÀ TĂNG 24 3.6 MÔ HÌNH UP 28 3.7 MÔ HÌNH XOẮN ỐC 33 3.8 MÔ HÌNH MÃ NGUỒN MỞ 34 CHƯƠNG 4: KIỂM THỬ 37 4.1 VẤN ĐỀ CHẤT LƯỢNG PHẦN MỀM 37 4.1.1 Đảm bảo chất lượng phần mềm (SQA) 37 4.1.2. Độc lập trong quản lý 37 4.2 KIỂM CHỨNG PHẦN MỀM 38 4.3 CÁC PHƯƠNG PHÁP KIỂM CHỨNG 38 4.3.1. Kiểm thử không có sự thực thi 38 4.3.2 Kiểm thử có dựa trên sự thực thi 42 4.4 NHỮNG VẤN ĐỀ TRONG KIỂM THỬ 42 4.4.1 Cái gì nên được kiểm thử? 42 4.4.2 Kiểm thử và sự kiểm chứng tính chính xác 44 4.4.3 Sự kiểm chứng tính chính xác và kỹ nghệ phần mềm 45 4.4.4 Ai thực hiện kiểm thử phần mềm 46 4.4.5 Khi nào kiểm thử dừng 46 3
Chương 1: Mở đầu CHƯƠNG 5: LẬP KẾ HOẠCH VÀ ƯỚC LƯỢNG 48 5.1 VẤN ĐỀ LẬP KẾ HOẠCH VÀ ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM 48 5.2 ƯỚC LƯỢNG THỜI GIAN VÀ CHI PHÍ 49 5.2.1 Thước đo kích cỡ của sản phẩm phần mềm 49 5.2.2 Các kỹ thuật ước lượng chi phí 52 5.2.3 COCOMO trung gian 53 5.2.4 COCOMO II 55 5.2.5 Theo dõi ước lượng thời gian và chi phí 55 5.3 CÁC THÀNH PHẦN CỦA VIỆC LẬP KẾ HOẠCH PHÁT TRIỂN PHẦN MỀM 57 5.3.1Khung kế hoạch quản lý dự án phần mềm(SPMP) 57 5.3.2 Kế hoạch quản lý dự án phần mềm IEEE 57 5.3.3 Việc lập kế hoạch kiểm thử 58 5.3.4 Yêu cầu đào tạo 58 5.3.5 Các chuẩn tài liệu 58 5.3.6 Công cụ CASE cho việc lập kế hoạch và ước lượng 59 5.4 KIỂM THỬ VIỆC LẬP KẾ HOẠCH 59 5.5 LẬP KẾ HOẠCH CHO CÁC DỰ ÁN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG 59 CHƯƠNG 6: PHA XÁC ĐỊNH YÊU CẦU 60 6.1 XÁC ĐỊNH YÊU CẦU CỦA KHÁCH HÀNG 60 6.2 TỔNG QUAN VỀ LUỒNG CÔNG VIỆC XÁC ĐỊNH YÊU CẦU 60 6.2.1 Hiểu lĩnh vực ứng dụng 61 6.2.2 Mô hình nghiệp vụ 61 6.2.3 Các use case 63 6.2.4 Các yêu cầu ban đầu 65 6.3 PHA XÁC ĐỊNH YÊU CẦU CỔ ĐIỂN 65 6.4 BẢN MẪU NHANH 66 6.5 NHÂN TỐ CON NGƯỜI 66 6.6 SỬ DỤNG LẠI BẢN MẪU NHANH 67 6.7 CÁC CÔNG CỤ CASE CHO XÁC ĐỊNH YÊU CẦU 67 6.8 CÁC THƯỚC ĐO CHO XÁCPTIT ĐỊNH YÊU CẦU 68 6.9 NHỮNG THỬ THÁCH CHO PHA XÁC ĐỊNH YÊU CẦU 68 6.10 CASE STUDY CHO PHA XÁC ĐỊNH YÊU CẦU 68 6.10.1 Bài toán 68 6.10.2 Xây dựng sơ đồ use case tổng quan 70 6.10.3 Mô tả các use case 71 CHƯƠNG 7: CÁC PHƯƠNG PHÁP PHÂN TÍCH TRUYỀN THỐNG 75 7.1 YÊU CẦU TÀI LIỆU ĐẶC TẢ 75 7.2 CÁC PHƯƠNG PHÁP ĐẶC TẢ 76 7.2.1 Đặc tả phi hình thức 76 7.2.2 Phân tích hướng cấu trúc 77 CHƯƠNG 8: PHƯƠNG PHÁP PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG 79 8.1 LUỒNG CÔNG VIỆC PHÂN TÍCH 79 8.2 VIỆC TRÍCH RÚT CÁC LỚP THỰC THỂ 79 8.3 PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG CHO BÀI TOÁN THANG MÁY 80 8.4 MÔ HÌNH HÓA CHỨC NĂNG 80 8.5 MÔ HÌNH HÓA LỚP THỰC THỂ 82 8.5.1 Trích rút danh từ 82 4
Chương 1: Mở đầu 8.5.2 CRC Cards 84 8.7 KIỂM THỬ TRONG PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG 86 8.8 CÁC CÔNG CỤ CASE CHO PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG 90 8.9 CASE STUDY CHO PHA PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG 90 8.9.1. Các scenario 90 8.9.2 Trích các lớp thực thể 94 8.9.3 Viết lại các scenario 96 CHƯƠNG 9: PHA THIẾT KẾ 97 9.1 TỔNG QUAN VỀ PHA THIẾT KẾ 97 9.1.1 Dữ liệu và các hành động 97 9.1.2 Thiết kế và trừu tượng 97 9.1.3 Thiết kế 98 9.1.4 Kiểm thử trong pha thiết kế 99 9.1.5 Kỹ thuật hình thức cho thiết kế chi tiết 100 9.1.6 Kỹ thuật thiết kế hệ thống thời gian thực 100 9.1.7 Công cụ CASE cho thiết kế 101 9.1.8 Thước đo cho thiết kế 101 9.1.9 Những thách thức của pha thiết kế 102 9.2 THIẾT KẾ HƯỚNG HÀNH ĐỘNG 102 9.3 PHÂN TÍCH VA THIẾT KẾ DÒNG DỮ LIỆU 103 9.3.1 Phân tích dòng dữ liệu 103 9.3.2 Thiết kế dòng dữ liệu 108 9.4 THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 108 9.5 CASE STUDY CHO PHA THIẾT KẾ 111 9.5.1 Thiết kế cơ sở dữ liệu 112 9.5.2 Thiết kế dùng bean thay cho control 114 9.5.3 Thiết kế dùng control DAO và thực thể thuần 122 9.5.4 Thiết kế theo MVC cải tiến, dùng control DAO và thực thể thuần 129 CHƯƠNG 10: PHA CÀI ĐẶT VÀ TÍCH HỢP 136 10.1 CÁC PHƯƠNG PHÁP CÀIPTIT ĐẶT VÀ TÍCH HỢP 136 10.1.1 Luồng công việc cài đặt 136 10.1.2 Tích hợp 145 10.2 KIỂM THỬ PHA CÀI ĐẶT VÀ TÍCH HỢP 149 10.2.1 Luồng công việc kiểm thử cài đặt 149 10.2.2 Kiểm thử tích hợp 162 10.4 KIỂM THỬ CHẤP NHẬN 163 10.5 CASE STUDY CHO PHA CÀI ĐẶT: VIẾT TEST CASE 163 10.5.1 Test case cho modul thêm phòng mới của khách sạn 163 10.5.2 Test case cho modul sửa thông tin phòng của khách sạn 166 10.5.3 Test case cho modul đặt phòng 168 CHƯƠNG 11: PHA BẢO TRÌ 177 11.1 PHA BẢO TRÌ SAU KHI CHUYỂN GIAO 177 11.1.1 Tại sao bảo trì sau khi chuyển giao là cần thiết 177 11.1.2 Người lập trình bảo trì sau khi chuyển giao yêu cầu những gì? 177 11.1.3 Quản lý bảo trì sau khi chuyển giao 179 11.1.4 Bảo trì sau khi chuyển giao với kỹ năng phát triển 181 11.1.5 Kỹ nghệ ngược 181 5
Chương 1: Mở đầu 11.1.6 Công cụ CASE cho bảo trì sau khi chuyển giao 182 10.1.7 Thước đo của bảo trì sau khi chuyển giao 182 10.1.8 Những thách thức của bảo trì sau khi chuyển giao 182 11.2 BẢO TRÌ HỆ PHẦN MỀM HƯỚNG ĐỐI TƯỢNG 183 11.3 KIỂM THỬ PHA BẢO TRÌ 184 PTIT 6
Chương 1: Mở đầu CHƯƠNG 1: MỞ ĐẦU 1.1 ĐẶC TRƯNG CỦA PHẦN MỀM Phần mềm không mòn Phần mềm được phát triển mà không được sản xuất theo nghĩa thông thường Mặc dù công nghiệp phần mềm đang hướng đến phát triển dựa trên thành phần nhưng phần lớn phần mềm phát triển dựa theo yêu cầu của khách hàng. Cho đến nay những đặc trưng của phần mềm vẫn còn là vấn đề tranh cãi. Chính điều này thể hiện sự chưa trưởng thành của ngành học CÔNG NGHỆ PHẦN MỀM. 1.2 CÁC KIỂU PHẦN MỀM Phần mềm hệ thống: Tập hợn các Chương trình được viết để phục vụ các chương trình khác, tương tác với phần cứng (ví dụ, biên dịch, trình soạn thảo, HĐH ) Phần mềm thời gian thực: Phần mềm điều phối/phân tích kiểm soát, đáp ứng thời gian Phần mềm nghiệp vụ: Các phần mềm tính lương, kế toán, quản lý kho Phần mềm khoa học và công nghệ: Các ứng dụng trong thiên văn, sinh học phân tử, điều khiển tàu con thoi, Phần mềm nhúng: Nằm trong bộ nhớ chỉ đọc điều khiển các sản phẩm và hệ thống Phần mềm máy tính cá nhân: Xử lý văn bản, đồ họa máy tính Phần mềm trên Web Phần mềm trí tuệ nhân tạo: Dựa trên những kỹ thuật của Trí tuệ nhân tạo như hệ chuyên gia. Nhận xét: Hiện nay web được xemPTIT là môi trường phổ biến để xây dựng giao diện với người sử dụng cho nhiều hệ thống phần mềm trên mạng. 1.3 KHÍA CẠNH LỊCH SỬ Năm 1967 nhóm NATO đưa ra thuật ngữ Công nghệ phần mềm (Software Engineering). Năm 1968 Hội nghị Software Engineering ở Garmisch, Đức đưa ra mục đích là giải quyết “Cuộc khủng hoảng phần mềm”: - Phần mềm hoàn thành không đúng thời hạn - Chi phí vượt dự toán ban đầu - Phần mềm còn nhiều lỗi Tại sao không thể sử dụng kỹ nghệ xây cất như xây dựng cầu để xây dựng các hệ điều hành? - Thái độ đối với việc sập cầu/hệ điều hành - Thông tin về CNPM thường không đầy đủ, không chắc chắn - Độ phức tạp 7
Chương 1: Mở đầu - Bảo trì Công nghệ phần mềm không thể xem giống như các kỹ nghệ thông thường khác. 1.4 KHÍA CẠNH KINH TẾ CNPM và khoa học máy tính (tương tự như hóa học và kỹ nghệ hóa) - Khoa học có phần thực nghiệm và lý thuyết: Phần thực nghiệm của Hóa học là thí nghiệm còn của khoa học máy tính là lập trình. - Khoa học máy tính nghiên cứu những sách khác nhau để tạo ra phần mềm. Nhưng kỹ sư phần mềm chỉ quan tâm kỹ thuật có ý nghĩa kinh tế. - Ví dụ: Phương pháp mã hóa mới KTmới (lập trình hướng thành phần) nhanh hơn phương pháp đang sử dụng hiện thời KTcũ (lập trình hướng đối tượng) là 10%. Chúng ta nên sử dụng phương pháp mới hay không? Câu trả lời thông thường là: Tất nhiên! Câu trả lời Công nghệ phần mềm: xét hiệu quả của KTmới. 1.5 KHÍA CẠNH BẢO TRÌ Vòng đời phần mềm: Một loạt các pha mà phần mềm phải trải qua từ khám phá các khái niệm đến loại bỏ hoàn toàn. Mô hình vòng đời - Pha yêu cầu - Pha đặc tả - Pha thiết kế - Pha cài đặt - Pha tích hợp - Pha bảo trì PTIT - Loại bỏ Bảo trì: Mọi thay đổi đối với sản phẩm một khách hàng đã đồng ý sản phẩm thỏa mãn tài liệu đặc tả. Phần mềm tốt được bảo trì khác với phần mềm tồi bị loại bỏ Các dạng bảo trì” - Bảo trì sửa lỗi [17,5%]: sửa chữa lỗi nhưng đặc tả không đổi - Bảo trì nâng cao: sửa chữa theo thay đổi của đặc tả. Bảo trì hoàn thiện [60,5%]: thêm chức năng để cải tiến sản phẩm. Bảo trì thích nghi [18%]: thay đổi phần mềm để đáp ứng thay đổi của môi trường như quy định chính phủ, CPU, công nghệ mới Ví dụ 1: Tỷ lệ thuế GTGT thay đổi từ 6% đến 7% - C++ const float salesTax =6.0; - JAVA 8
Chương 1: Mở đầu public static float salesTax = 6.0; Ví dụ 2 Tổ chức y tế thay đổi Hoạt động thay đổi Ví dụ 3 Các hệ thời gian thực/hệ nhúng Thế giới thực thay đổi hệ thay đổi Chi phí cho các pha: Nguồn dữ liệu của các năm 1976-1981 Hewlett-Packard (1992) - 60-80% nguồn nhân lực để phát triển và nghiên cứu dành cho bảo trì - 40-60% chi phí phần mềm dành cho bảo trì Nhiều tổ chức dành 80% thời gian và công sức chop ha bảo trì [Yourdon, 1996] Kết luận: Bảo trì là pha tốn kém nhiều thời gian và chi phí 1.6 KHÍA CẠNH PHÂN TÍCH VÀ THIẾT KẾ 60 đến 70% lỗi của phần mềm là những lỗi do đặc tả và thiết kế Dữ liệu của Kelly, Sherif andPTIT Hops [1992] về chương trình không gian liên hành tinh của Nasa - 1,9 lỗi trên một trang đặc tả - 0,9 lỗi trên một trang thiết kế - 0,3 lỗi trên một trang chương trình nguồn Dữ liệu của Bhandari et al. [1994]: Lỗi trong cuối pha thiết kế của phiên bản mới của sản phẩm - 13% lỗi từ phiên bản trước - 16% lỗi trong pha đặc tả mới - 71% lỗi trong pha thiết kế mới Kết luận: Xây dựng những kỹ thuật sinh ra thiết kế và đặc tả tốt hơn là một vấn đề quan trọng trong công nghệ phần mềm. Chi phí cho việc phát hiện và sửa chữa lỗi: 9
Chương 1: Mở đầu 1.7 KHÍA CẠNH LẬP TRÌNH NHÓM Phần cứng rẻ, khả năng tăng, kích thước giảm Phần mềm lớn, đắt. Nhiều phần mềm quá lớn nên một người không thể phát triển được trong thời gian có hạn. Ví dụ: Lan và Minh viết code cho hai Mô đun p và q với mô đun p gọi q. Khi viết p Lan đã viết một hàm gọi q với 5 đối số. Minh cũng code q với 5 đối số nhưng thứ tự khác Lan. - Compiler của C không thể phát hiện sai sót đó - Java chỉ có thể phát hiện khi biến khác kiểu nhưng nếu cùng kiểu thì không thể phát hiện 1.8 PHƯƠNG PHÁP HƯỚNG ĐỐI TƯỢNG Trước năm 1975, phần lớn các tổ chức phần mềm có những kỹ thuật riêng, cá nhân có cách làm việc riêng. Giữa những năm 1975-1985: Phương pháp cấu trúc đạt nhiều thành công ban đầu. Kỹ thuật cấu trúc phù hợp với chương trình 5.000 đến 50.000 dòng mã. Hạn chế của phương pháp cấu trúc: - Không phù hợp với phần mềm lớn (> 50.000 dòng lệnh) - 80% chi phí và sức lựcPTIT dành cho bảo trì nhưng cách tiếp cận của phương pháp cấu trúc không giải quyết được vấn đề này. Đặc trưng của phương pháp cấu trúc: - Hướng hành động (máy trạng thái hữu hạn, sơ đồ dòng dữ liệu); hay - Hướng dữ liệu (sơ đồ quan hệ thực thể, phương pháp Jackson); - Không cả hai Phương pháp hướng đối tượng: Cả hai dữ liệu và hành động đều quan trọng như nhau Đối tượng: Thành phần phần mềm kết hợp cả hai dữ liệu và các hành động thực hiện trên dữ liệu đó. Ví dụ: Quản lý trương mục ngân hàng - Dữ liệu: tiền gửi vào, rút ra - Hành động: gửi vào, rút ra, xác định tiền gửi vào rút ra Phương pháp lập trình hướng đối tượng khác phương pháp cấu trúc 10
Chương 1: Mở đầu - Ẩn dấu thông tin - Thiết kế dựa trên trách nhiệm - Ảnh hưởng đối với bảo trì và phát triển Phương pháp hướng đối tượng: Một đối tượng gửi message đến một đối tượng khác để yêu cầu hành động/phương pháp. Từ phân tích đến thiết kế - Phương pháp cấu trúc: Tạo “xóc” giữa phân tích (what) và thiết kế “how” - Phương pháp hướng đối tượng: (chuyển pha “êm dịu” nên giảm được sai sót) Các đối tượng đưa vào ngay từ đầu của vòng đời. Đối tượng được đề xuất trong pha thiết kế, được xây dựng trong pha thiết kế, được mã hóa trong pha lập trình. - Phân tích hệ thống: XácPTIT định điều cần phải làm WHAT - Thiết kế xác định cách làm HOW: thiết kế kiến trúc xác định các mô đun và thiết kế chi tiết từng mô đun. Lợi ích của HĐT: - Phân tích hướng đối tượng: Xác định cái gì phải thực hiện và xác định các đối tượng - Thiết kế hướng đối tượng: Xác định cách thực hiện hành động và xây dựng các đối tượng. So sánh phương pháp cấu trúc và phương pháp hướng đối tượng 11
Chương 1: Mở đầu Kết luận: Công nghệ phần mềm: ngành học nhằm nghiên cứu cách sản xuất ra phần mềm thỏa mãn nhu cầu khách hàng, không có lỗi, giao đúng thời hạn và trong chi phí hạn định. Công nghệ phần mềm xem xét các pha của vòng đời phần mềm và phân phối các khía cạnh khác nhau của tri thức con người từ kinh tế, kỹ thuật đến khoa học xã hội, tâm lý Phương pháp hướng đối tượng được xem là cách tiếp cận phổ biến trong phát triểnphần mềm hiện nay. PTIT 12
Chương 2: Các pha phát triển phần mềm CHƯƠNG 2: CÁC PHA PHÁT TRIỂN PHẦN MỀM 2.1 TIẾN TRÌNH THÀNH PHẦN Tiến trình phần mềm là “phương cách” sản xuất ra phần mềm. Tiến trình phần mềm nghiên cứu các cách kết hợp: - Mô hình vòng đời - Các công cụ CASE - Các cá nhân xây dựng phần mềm - Các công nghệ Tiến trình phần mềm = Khía cạnh kỹ thuật + Khía cạnh quản lý Các tổ chức khác nhau có những tiến trình phần mềm khác nhau. - Khâu viết tài liệu (quan trọng/không quan trọng) - Chi phí dành cho kiểm thử (1/2 chi phí/không quan trọng) - Tập trung khaua nghiên cứu, phát triển phần mềm. Khâu bảo trì dành cho người khác. Vì sao như vậy? - Thiếu kỹ năng về kỹ nghệ phần mềm - Nhiều người quản lý phần mềm thiếu kiến thức về bảo trì và phát triển phần mềm (do đó trễ hạn!) - Quan điểm về quản lýPTIT (giao đúng hạn hay kiểm tra kỹ trước khi giao) - Phụ thuộc vào cá nhân Có pha kiểm thử không? KHÔNG có pha kiểm thử. Vì sao? Kiểm thử là hoạt động thực hiện trong mọi pha của sản xuất phần mềm. Check = test Testing: Thương được hiểu sau khi coding Kiểm tra (Varification): Thực hiện vào cuối mỗi pha Kiểm chứng (Validation): Thực hiện trước khi giao sản phẩm cho khách hàng Có pha viết tài liệu không? KHÔNG có pha viết tài liệu Mọi pha phải được viết tài liệu trước khi khởi đầu một pha mới. Một số lý do: - Tài liệu bị hoãn lại thì sẽ không bao giờ hoàn thành - Cá nhân chịu trách nhiệm trong pha trước có thể đã chuyển sang bộ phận khác. 13
Chương 2: Các pha phát triển phần mềm - Sản phẩm thường xuyên thay đổi trong khi phát triển vì thế ta cần tài liệu để ghi lại điều này. Ví dụ, thiết kế thường phải sửa đổi trong khi cài đặt. Việc sửa đổi như vậy chỉ có thể thực hiện được khi có tài liệu của nhóm thiết kế. Kiểm thử và viết tài liệu được tiến hành trong mọi pha của tiến trình phần mềm. 2.2 SQA LÀ GÌ? Nhóm đảm bảo chất lượng phần mềm (SQA: Software quality assurance): - Có trách nhiệm đảm bảo sản phẩm được xây dựng đúng (theo đặc tả) và theo đơn đặt hàng. - Nhóm SQA phải đóng đúng vai trò ngay từ đầu của tiến trình và hoạt động trong mọi pha của tiến trình phần mềm. - SQA kiểm tra với khách hàng xem phiên bản cuối cùng thỏa mãn hoàn toàn chưa. 2.3 PHA YÊU CẦU Tiến trình phát triển phần mềm bắt đầu khi khách hàng tiếp xúc với công ty phần mềm và cho rằng: Phần mềm có khả năng thích hợp với khách hàng và giá thành hợp lý. Khám phá khái niệm: - Trong lần gặp đầu tiên, khách hàng phát họa sản phẩm mà họ hình dung. Theo quan điểm của người phát triển, mô tả này không rõ ràng, không hợp lý, mâu thuẫn hay không thể xây dựng phần mềm như thế được. - Người phát triển xác định nhu cầu và ràng buộc của khách hàng Kiểm thử pha yêu cầu: Làm bản mẫu nhanh: là mẫu phần mềm kết hợp nhiều chức năng của sản phẩm cuối cùng nhưng bỏ qua những khía cạnh mà khách hàng không thấy được như cập nhật file hay xử lý lỗi. PTIT Bản mẫu nhanh phải được kiểm tra bởi khách hàng và người sử dụng. Bản mẫu nhanh có thể thay đổi cho đến khi khách hàng và người sử dụng cho rằng nó có những chức năng mà họ mong muốn. Viết tài liệu pha yêu cầu: Tài liệu pha yêu cầu: - Có bản mẫu: Bản mẫu nhanh. Bản ghi thỏa thuận với khách hàng và người sử dụng về cơ sở xây dựng và sửa đổi bản mẫu. - Không có bản mẫu (nhóm quyết định không xây dựng bản mẫu): Mô tả nhu cầu khách hàng. Tài liệu này phải được khách hàng, người sử dụng và nhóm phát triển kiểm tra trước khi nhóm SQA xem xét. 2.4 PHA ĐẶC TẢ Khi khách hàng cho rằng nhóm phát triển hiểu được yêu cầu, nhóm đặc tả viết tài liệu đặc tả để mô tả chức năng của sản phẩm (những gì sản phẩm cần có + ràng buộc). 14
Chương 2: Các pha phát triển phần mềm Đặc tả bao gồm những input của sản phẩm và output được yêu cầu Ví dụ: Khách hàng cần tính bảng lương thì input bao gồm mức trả cho mỗi nhân viên, thông tin từ hồ sơ cá nhân để tính thuế và output là số lương thuế, chi bảo hiểm, Yêu cầu của đặc tả - Không nhập nhằng: không sử dụng thuật ngữ như tiện lợi, đầy đủ chức năng, nhanh, 98% - Đầy đủ: Thể hiện mọi yêu cầu của khách hàng - Phi mâu thuẫn: không chứa mâu thuẫn - Theo dõi được (Traceability): có thể lần theo phán đoán trong đặc tả trở lại phán đoán đưa ra bởi khách hàng trong pha yêu cầu. Nếu đặc tả được trình bày đúng phương pháp, có đánh chỉ số, thì nhóm SQA sẽ ít gặp khó khăn. Nếu có bản mẫu thì phán đoán liên quan của đặc tả phải theo dõi được đến bản mẫu. Môt khi đặc tả được hoàn thành và đã thông qua thì hình thành kế hoạch quản lý quá trình sản xuất phần mềm (SPMP : The software product management plan). Yêu cầu kế hoạch: - SPMP cần nêu lên thời gian thực hiện, chi phí cho từng pha, gán trách nhiệm cá nhân cho từng pha, thời hạn hoàn thành cho mỗi pha. - Mô hình vòng đời nào sẽ sử dụng, cấu trúc tổ chức, kỹ thuật và CASE sử dụng, lịch tình, chi phí Kiểm thử pha đặc tả: Nguồn gốc chính của lỗi trong các phần mềm đã phân phối đến nay là những lỗi trong tài liệu đặc tả và những lỗi này chỉ được phát hiện khi tổ chức khách hàng sử dụng nó. Duyệt xét lại (Review): là cách tốt nhất để kiểm tra đặc tả. Mục đích là xác định đặc tả có đùng không. Nhóm SQA chủPTIT trì cuộc họp với đại diện nhóm đặc tả và khách hàng. 2.5 PHA THIẾT KẾ Đặc tả - What Thiết kế - How Giữ lại quyết định thiết kế - Thời điểm kết thúc - Cho nhóm bảo trì - Thiết kế nên mở (open-ended) Thiết kế kiến trúc : Phân rã sản phẩm thành mô đun Thiết kế chi tiết: Thiết kế các mô đun: cấu trúc dữ liệu, thuật toán Kiểm thử pha thiết kế Tài liệu viết sao cho dễ theo dõi Duyệt tài liệu 15
Chương 2: Các pha phát triển phần mềm 2.6 PHA CÀI ĐẶT Cài đặt thiết kế chi tiết thành chương trình Kiểm thử pha cài đặt: Rà soát Các test case - Test không hình thức (desk checking) - Test hình thức (Formal testing) do nhóm SQA 2.7 TÍCH HỢP Kết hợp các mô đun và kiểm thử toàn bộ sản phẩm Tài liệu pha tích hợp Mã nguồn có chú thích Các test cases 2.8 CẢI TIẾN TIẾN TRÌNH PHẦN MỀM Bắt đầu từ Bộ Quốc Phòng Mỹ Software Engineering Institue (SEI) Vấn đề: - Quản lý tiến trình phần mềm kém Cải tiến tiến trnfh phần mềm - Capability maturity model (CMM) - ISO 9000-Series - ISO/IEC 15504 PTIT CMM: Capability Maturity Model Không phải mô hình vòng đời Tập các chiến lược cải tiến tiến tình phần mềm - SW-CMM for software - P-CMM for human resource (“people”) - SE-CMM for systems engineering - IPD-CMM for integrated product development - SA-for software acquisition Các chiến lược được thống nhất thành CMMI (Capability maturity model integration) SW-CMM • A strategy for improving the software process – Put forward in 1986 by the SEI – Fundamental idea: – Improving the software process leads to • Improved software quality 16
Chương 2: Các pha phát triển phần mềm • Delivery on time, within budget – Improved management leads to • Improved techniques • Five levels of “maturity” are defined – Organization advances stepwise from level to level Level 1: Initial Level • Ad hoc approach – Entire process is unpredictable – Management consists of responses to crises • Most organizations world-wide are at level 1 Level 2: Repeatable Level • Basic software management – Management decisions should be made on the basis of previous experience with similar products – Measurements (“metrics”) are made – These can be used for making cost and duration predictions in the next project – Problems are identified, immediate corrective action is taken Level 3: Defined Level • The software process is fully documented – Managerial and technical aspects are clearly defined – Continual efforts are made to improve quality, productivity – Reviews are performed to improve software quality – CASE tools are applicable now (and not at levels 1 or 2) Level 4: Managed Level • Quality and productivity goalsPTIT are set for each project – Quality, productivity are continually monitored – Statistical quality controls are in place Level 5: Optimizing level • Continuous process improvement – Statistical quality and process controls – Feedback of knowledge from each project to the next Kết luận: 17
Chương 2: Các pha phát triển phần mềm Tiến trình chính • Có các tiến trình chính (key Process Area) cho mỗi mức • Mức 2: – Quản lý yêu cầu – Lập kế hoạch dự án – Theo dõi dự án – Quản lý cấu hình – Bảo đảm chất lượng • So sánh – Mức 2: Phát hiện và sửa lỗi – Mức 3: Ngăn chặn lỗi Kinh nghiệm • Cần: – 3 đến 5 năm để từ mức 2 lên mức 2 – 1.5 đến 3 năm từ mức 2 lên mức 3 • Original idea: Defense contracts would be awarded only to capable firms • Profitability – Hughes Aircraft (Fullerton, CA) spent $500K (1987–90) • Savings: $2M per year, moving from level 2 to level 3 – Raytheon moved from level 1 in 1988 to level 3 in 1993 • Productivity doubled • Return of $7.70 per dollar invested in process improvement Other SPI Initiatives PTIT • Other software process improvement (SPI) initiatives: – ISO 9000-series – ISO/IEC 15504 ISO 9000 • Set of five standards for industrial activities – ISO 9001 for quality systems – ISO 9000-3, guidelines to apply ISO 9001 to software – There is an overlap with CMM, but they are not identical – Not process improvement – Stress on documenting the process – Emphasis on measurement and metrics – ISO 9000 is required to do business with the E.U. – Also by many U.S. businesses, for example, GE – More and more U.S. businesses are ISO 9000 certified 18
Chương 2: Các pha phát triển phần mềm ISO/IEC 15504 • Original name: Software Process Improvement Capability dEtermination (SPICE) – International process improvement initiative – Started by British Ministry of Defence (MOD) – Includes process improvement, software procurement – Extends and improves CMM, ISO 9000 – Framework, not a method • CMM, ISO 9000 conform to this framework – Now referred to as ISO/IEC 15504 – Or just 15504 for short Process Improvement Data • SEI report on 13 organizations in the original study • They used a variety of processPTIT improvement techniques, not just SW–CMM 19
Chương 2: Các pha phát triển phần mềm PTIT 20
Chương 3. Các mô hình vòng đời phần mềm CHƯƠNG 3 CÁC MÔ HÌNH VÒNG ĐỜI PHẦN MỀM 3.1 PHÁT TRIỂN PHẦN MỀM 3.1.1 Theo lý thuyết phát triển phần mềm: Theo lý tưởng, phần mềm được phát triển: tuyến tính và bắt đầu từ con số 0 3.1.2 Thực tế phát triển phần mềm Trong thực tế, phát triển phần mềm hoàn toàn khác: Người phát triển có thể mắc lỗi trong quá trình phát triển phần mềm Yêu cầu của khách hàng thayPTIT đổi trong khi hệ thống phần mềm đang được xây dựng 3.1.3 Bài toán Winburg Mini Episode 1: Phiên bản đầu tiên được cài đặt Episode 2: Tìm ra các lỗi . Hệ thống phần mềm được xây dựng quá lâu bởi vì việc sử lỗi cài đặt . Thay đổi trong cài đặt được bắt đầu. Episode 3: Thiết kế mới được chấp nhận . Thuật toán nhanh hơn được sử dụng Episode 4: Các yêu cầu thay đổi . Yêu cầu độ chính xác cao hơn Kết luận: Một vài năm sau, những vấn đề này lại xảy ra lại xảy ra 21
Chương 3 Các mô hình vòng đời phần mềm Mô hình tin hóa cho bài toán Winburg Mini 3.2 MÔ HÌNH XÂY SỬA Không thiết kế Không đặc tả . Bảo trì là ác mộng Là cách dễ dàng nhất để phát triển phần mềm Là cách đắt nhất PTIT 3.3 MÔ HÌNH TIẾN HÓA Đặc trưng bởi . Các vòng lặp phản hồi . Hướng tài liệu . Mô hình thác nước không biểu hiện thứ tự các sự kiện Thuận lợi . Tài liệu 22
Chương 3 Các mô hình vòng đời phần mềm . Bảo trì dễ dàng Bất lợi . Tài liệu đặc tả o Joe và Jane Johnson o Mark Marberry 3.4 MÔ HÌNH BẢN MẪU NHANH Mô hình tuyến tính “Nhanh” PTIT Mô hình tiến hoá 23
Chương 3 Các mô hình vòng đời phần mềm Mô hình cây tiến hóa cho bài toán Winburg Mini Thứ tự của các sự kiện được chỉ ra rõ ràng Kết thúc của mỗi Episode: . Có một đường cơ sở chỉ rõ tập các tài liệu phải được hoàn thiện Chẳng hạn: . Đường cơ sở ở cuối Episode 3 là: o Các yêu cầu , Tài liệu phân tích , Tài liệu thiết kế 3, cài đặt 3 1 1 Các bài học rút ra từ bài toán Winburg Mini Trong thực tế, phát triển phần mềm nhiều hỗn độn hơn bài toán Winburg mini. Thay đổi luôn luôn cần thiết . Hệ thống phần mềm là một mô hình của thế giới thực và nó luôn luôn thay đổi . Chuyên gia phần mềm là con người nên có thể mắc lỗi trong quá trình phát triển phần mềm PTIT 3.5. MÔ HÌNH LẶP VÀ TĂNG Trong thực tế, chúng ta không thể nói về “pha phân tích” . Mặc dù, các thao tác của pha phân tích trải rộng xuyên suốt vòng đời phần mềm. Tiến trình phát triển phần mềm là lặp . Mỗi phiên bản kế tiếp tiến gần với hệ thống đích hơn phiên bản trước đó. Luật Miller: Ở bất cứ thời điểm nào, chúng ta chỉ có thể tập trung vào khoảng 7 chunks ( tương ứng 7đơn vị thông tin) Để xử lý lượng thông tin lớn hơn yêu cầu sử dụng bước làm mịn theo kiểu bậc thang . Tập trung vào các khía cạnh quan trọng nhất hiện thời . Các khía cạnh trì hoãn thường ít quan trọng hơn . Cuối cùng mọi khía cạnh đều được xử lý nhưng theo thứ tự mức độ quan trọng hiện thời Đây là tiến trình tăng 24
Chương 3 Các mô hình vòng đời phần mềm Lặp và tăng được sử dụng chung với các mô hình khác. . Không có Episode nào mà chỉ có pha “xác định yêu cầu” hoặc “pha thiết kế” . Có nhiều thể hiện ở mỗi pha PTIT Số lượng của sự gia tăng sẽ thay đổi – không phải là 4 Và số lượng vòng lặp cũng thay đồi không phải luôn bằng ba. Các pha cổ điển với các workflow Các pha tuần tự không có trong thế giới thực Mặc dù có 5 workflow (luồng công việc) chính được thực hiện ở trên toàn vòng đời phát triển phần mềm . Luồng công việc xác định yêu cầu - Requirements workflow . Luồng công việc phân tích - Analysis workflow . Luồng công việc thiết kế - Design workflow . Luồng công việc cài đặt - Implementation workflow . Luồng công việc kiểm thử - Test workflow 25
Chương 3 Các mô hình vòng đời phần mềm Các luồng công việc Cả năm luồng công việc chính được thực hiện trên toàn bộ vòng đời phần mềm Tuy nhiên, ở mỗi một thời điểm có một luồng công việc chiếm ưu thế. Chẳng hạn: . Ở đầu mỗi vòng đời phát triển phần mềm o Luồng công việc đặc tả yêu cầu chiếm ưu thế . Ở cuối mỗi vòng đời phát triển phần mềm o Luồng công việc cài đặt và kiểm thử chiếm ưu thế Các hoạt động lập kế hoạch và viết tài liệu được thực hiện xuyết suốt vòng đời phát triển phần mềm Xem xét lại bài toán Winburg Mini Mô hình cây tiến hóa đã được thêm vào mô hình vòng đời lặp và tăng Luồng kiểm thử đã bị bỏ quên – mô hình cây tiến hóa giả sử rằng kiểm thử liên tục PTIT Đối với quá trình tăng: . Mỗi Episode tương ứng với một sự gia tăng . Không phải mỗi sự gia tăng đều bao gồm mọi luông công việc . Sự gia tăng B không được hoàn thiện . Những đường nét đứt biểu diễn sự bảo trì o Episodes 2, 3: Bảo trì sửa lỗi o Episode 4: Bảo trì hoàn thiện chức năng Rủi ro và những khía cạnh khác của mô hình lặp và tăng Chúng ta có thể xem xét toàn bộ dự án như là một tập các dự án nhỏ (quá trình tăng) Mỗi dự án nhỏ gồm . Tài liệu yêu cầu . Tài liệu phân tích 26
Chương 3 Các mô hình vòng đời phần mềm . Tài liệu thiết kế . Tài liệu cài đặt . Tài liệu kiểm thử Tập tài liệu cuối cùng là sản phẩm phần mềm hoàn thiện Trong suốt dự án nhỏ:During each mini project we . Mở rộng các tài liệu (Sự gia tăng); . Kiểm tra tài liệu (luồng công việc kiểm thử); và . Nếu cần, thay đổi các tài liệu liên quan (vòng lặp) Mỗi vòng lặp có thể được xem xét như là một mô hình vòng đời thác nước nhỏ nhưng hoàn thiện Trong suốt mỗi vòng lặp chúng ta lựa chọn một phần của hệ thống phần mềm Trong mỗi phần đó cần thực hiện: . Pha xác định yêu cầu cổ điển . Pha phân tích cổ điển . Pha thiết kế cổ điển . Pha cài đặt cổ điển Điểm mạnh của mô hình vòng đời lặp và tăng Có nhiều sự tối ưu cho việc kiểm tra tính đúng đắn của sản phẩm . Mỗi vòng lặp có tích hợp luồng công việc kiểm thử . Các lỗi có thể được phát hiện và sửa chữa sớm Sự mạnh mẽ của kiến trúc có thể được xác định sớm trong vòng đời . Kiến trúc – các mô đun thành phần khác nhau và cách chúng kết hợp với nhau . Sự mạnh mẽ - có khả năng xử lý việc mở rộng và thay đổi mà hệ thống không bị tách thành từng mảnhPTIT Chúng ta có thể giảm bớt rủi ro sớm hơn . Lúc nào cũng vậy rủi ro luôn liên quan tới quá trình phát triển phần mềm và bảo trì Chúng ta có một phiên bản hệ thống phần mềm đang làm việc . Khách hàng và người dùng có thể thử nghiệm với phiên bản này để xác định cái họ cần thay đổi . Mức độ thay đổi: các phiên bản từng phần đưa ra để làm cho sự giới thiệu sản phẩm mới tới tổ chức khách hàng dễ dàng hơn. Có bằng chứng thực nghiệm chứng tỏ mô hình vòng đời làm việc Các bản tường trình CHAOS của nhóm Standish đã chỉ ra phần trăm phần mềm thành công tăng 27
Chương 3 Các mô hình vòng đời phần mềm Lý do của sự suy giảm của các dự án thành công năm 2004 bao gồm: . Nhiều dự án lớn trong năm 2004 hơn năm 2002 . Sử dụng mô hình thác nước . Thiếu sự quan tâm của người dùng . Thiếu sự hỗ trợ từ những người điều hành lâu năm Việc quản lý lặp và tăng Mô hình vòng đời lặp và tăng là tập hợp các mô hình thách nước bởi vì mô hình vòng đời lặp và tăng là mô hình thác nước, được áp dụng liên tiếp Mỗi sự gia tăng là mộ dự án nhỏ theo mô hình vòng đời thác nước 3.6 MÔ HÌNH UP Cho đến gần đây, ba phươngPTIT pháp luận hướng đối tượng thành công nhất: . Phương pháp của Booch . Jacobson’s Objectory . Rumbaugh’s OMT Năm 1999, Booch, Jacobson, và Rumbaugh đã công bố phương pháp luận phân tích và thiết kế hướng đối tượng hoàn thiện, đó là sự hợp nhất của ba phương pháp tách biệt. . Tên đầu tiên : Rational Unified Process (RUP) . Tiếp theo: Unified Software Development Process (USDP) . Tên được sử dụng ngày nay: Unified Process (for brevity) Quy trình hợp nhất không phải là một chuỗi các bước xây dựng hệ thống phần mềm . Không tồn tại phương pháp luận “một phù hợp với tất cả” . Có sự khác biệt lớn giữa các loại phần mềm Quy trình hợp nhất là một phương pháp luận có thể thích hợpThe Unified Process is an adaptable methodology . Nó phải được chỉnh sửa tùy theo từng phần mềm cụ thể được phát triển 28
Chương 3 Các mô hình vòng đời phần mềm UML là đồ họa . Một bức tranh đáng giá ngàn từ Các biểu đồ UML cho phép kỹ sư phần mềm giao tiếp nhanh hơn và chính xác hơn Quy trình hợp nhất là một kỹ thuật mô hình hóa . Một mô hình là một tập các biểu đồ UML biểu diễn các khía cạnh khác nhau của sản phẩm phần mềm mà chúng ta muốn phát triển UML là viết tắt của ngôn ngữ mô hình hợp nhất (Unified Modeling Language) . UML là công cụ được sử dụng để mô hình hệ thống phần mềm đích. Bốn quá trình tăng mang tên: . Pha khởi đầu – Inception Phase . Pha khảo sát tỉ mỉ - Elaboration phase . Pha xây dựng - Construction phase . Pha chuyển giao - TransitionPTIT phase Các pha của tiến trình hợp nhất là tăng Theo lý thuyết, số lượng quá trình tăng là bất kỳ . Trong thực tế, quá trình phát triển thường gồm 4 quá trình tăng Mỗi bước thực hiện trong tiến trình hợp nhất được chia thành . Một trong 5 luồng công việc chính và cũng có thể . Một trong bốn pha Tại sao mỗi bước phải được xem xét hai lần? Luồng công việc . Là ngữ cảnh kỹ thuật của một bước Pha . Là ngữ cảnh nghiệp vụ của mỗi bước Pha khởi đầu Mục đích của pha này là xác định liệu sản phẩn phần mềm đã đề xuất có thể làm được về mặt tài chính 29
Chương 3 Các mô hình vòng đời phần mềm 1. Hiểu được lĩnh vực xây dựng phần mềm 2. Xây dựng mô hình nghiệp vụ 3. Phân định phạm vi của dự án đã đề xuất . Tập trung vào tập con của mô hình nghiệp vụ mà đã được bao phủ bởi sản phẩm phần mềm đề xuất 4. Bắt đầu thực hiện những trường hợp nghiệp vụ ban đầu Các câu hỏi cần được trả lời bao gồm: . Có phải sản phẩm phần mềm đề xuất ước tính chi phí hiệu quả? . Bao lâu sẽ thu được vốn đầu tư?? . Về mặt giải pháp, chi phí sẽ lấy từ đâu nếu công ty quyết định không phát triển sản phẩm phần mềm đã đề xuất? . Nếu sản phẩm phần mềm không được bán trên thị trường thì có phải việc nghiên cứu thị trường cần thiết được thực hiện không? . Sản phẩm phần mềm được đề xuất có thể được chuyển giao đúng thời gian không? . Nếu sản phẩm phần mềm được phát triển để hỗ trợ các hoạt động của tổ chức khách hàng, cái gì sẽ bị ảnh hưởng nếu sản phẩm phần mềm được chuyển giao muộn? . Những rủi ro nào liên quan đến việc phát triển phần mềm? . Những rủi ro này có thể giảm nhẹ đi như thế nào? o Có phải đội phát triển sản phẩm phần mềm đã đề xuất là những người có kinh nghiệm? o Có phải sản phẩm phầnmềm này cần phần cứng mới? o Nếu như vậy, thì có phải có một rủi ro thì sản phẩm phần mềm đề xuất sẽ không được chuyể giao đúng thời gian? o Có phải có mộtPTIT cách để giảm nhẹ rủi ro, đó là bằng cách đưa ra phần cứng sao chép dự phòng từ nhà cung cấp khác?? o Các công cụ phần mềm cần được yêu cầu (chương 5)?Are software tools (Chapter 5) needed? o Có phải chúng luôn sẵn có? o Có phải chúng có tất cả những chức năng cần thiết? Tất cả các câu trả lời đều được yêu cầu ở cuối pha khởi đầu để trường hợp nghiệp vụ khởi đầu có thể được tạo ra Nắm được phiên bản đầu tiên của trường hợp nghiệp vụ là mục đích nói chung của pha khởi đầu Các phiên bản đầu tiên kết hợp chặt chẽ . Bản miêu tả phạm vi của sản phẩm phần mềm . Chi tiết về mặt tài chính . Nếu sản phẩm phần mềm được đề xuất có thể được kinh doanh thì trường hợp nghiệp vụ sẽ bao gồm: 30
Chương 3 Các mô hình vòng đời phần mềm o Đưa ra kết hoạch thu nhập, ước lượng thị trường, ước lượng chi phí ban đầu . Nếu sản phẩm phần mềm được sử dụng nội bộ thì trường hợp nghiệp vụ bao gồm o Phân tích lợi nhuận và chi phí ban đầu Các rủi ro: Có ba loại rủi ro chính: . Rui ro kỹ thuật o Xem ở slide trước đó . Rủi ro do xác định yêu cầu không đúng o Được giảm nhẹ đi bằng việc thực hiện luồng công việc đặc tả yêu cầu một cách chính xác . Rủi ro do thực hiện kiến trúc không đúng o Kiến trúc không thể đủ mạnh mẽ Làm giảm nhẹ ba loại rủi ro . Các rủi ro cầnd được xếp hạng để những rủi ro quan trọng được làm giảm nhẹ trước Công việc này kết thúc các bước của pha khởi đầu đối với luồng công việc xác định yêu cầu Luồng công việc phân tích, thiết kế Một phần nhỏ luồng công việc phân tích có thể được thực hiện trong suốt pha khởi đầu . Thông tin cần thiết cho thiết kế kiến trúc cần được trích rút. Theo đó, một phần nhỏ luồng công việc của thiết kế cũng được thực hiện Luồng công việc cài đặt Cài đặt nói chung dược thựcPTIT hiện trong suốt pha khởi đầu Tuy nhiên, đôi khi proof-of- concept-prototype được xây dựng để kiểm thử tính khả thi của việc xây dựng mỗi phần của sản phẩm phần mềm Luồng công việc kiểm thử Luồng công việc kiểm thử gần như bắt đầu ở giai đoạn đầu của pha khởi đầu . Mục đích để đảm bảo rằng các yêu cầu được xác định một cách chính xác Lập kế hoạch ở pha khởi đầu Bắt đầu pha khởi đầu không có đủ thông tin để lập kế hoạch cho toàn bộ quá trình phát triển phần mềm . Việc lập kế hoạch duy nhất được thực hiện ở đầu dự án là việc lập kế hoạch cho chính pha khởi đầu Cùng với lý do đó, việc lập kế hoạch duy nhất được thực hiện ở cuối pha khởi đầu là bản kế hoạch cho pha tiếp theo (pha khảo sát tỷ mỉ) Tài liệu của pha khởi đầu Những sản phẩm chuyển giao ở pha khởi đầu bao gồm:: 31
Chương 3 Các mô hình vòng đời phần mềm . Phiên bản đầu tiên của mô hình lĩnh vực họat động . Phiên bản đầu tiên của mô hình nghiệp vụ . Phiên bản đầu tiên của tài liệu xác định yêu cầu . Phiên bản sơ bộ của tài liệu phân tích . Phiên bản sơ bộ của kiến trúc . Danh sách ban đầu về các rủi ro . Đưa ra các use case . Lập kế hoạch cho pha khảo sát tỉ mỉ . Phiên bản đầu tiên của các trường hợp nghiệp vụ Pha khảo sát tỉ mỉ Mục đích của pha khảo sát tỉ mỉ là làm mịn những yêu cầu ban đầu . Làm mịn kiến trúc . Giám sát rủi ro và làm mịn độ ưu tiên của chúng . Làm mịn trường hợp nghiệp vụ . Đưa ra kế hoạch quản lý dự án Các hoạt động chính của pha khảo sát tỉ mỉ là làm mịn hoặc khảo sát tỉ mỉ các pha trước đó Những công việc của pha khảo sát tỉ mỉ bao gồm: . Tất cả nhưng hoàn thành luồng công việc xác định yêu cầu . Thực hiện một cách trực quan luồng công việc phân tích toàn thể . Bắt đầu thiết kế kiến trúc Sản phẩm chuyển giao của pha khảo sát tỉ mỉ bao gồm: . Mô hình lĩnh vực hoàn thiện . Mô hình nghiệp vụ hoàn thiện . Các tài liệu xác địnhPTIT yêu cầu hoàn thiện . Các tài liệu phân tích hoàn thiện . Phiên bản cập nhật kiến trúc . Danh sách cập nhật các rủi ro . Kế hoạch quản lý dự dán (cho những phần còn lại của dự án) . Trường hợp nghiệp vụ hoàn thiện Pha xây dựng Mục đích của pha này là đưa ra phiên bản chất lượng – sẵn sàng họat động đầu tiên của sản phẩm phần mềm . Đôi khi gọi đây là sự phát hành phiên bản beta Pha này tập trung vào những công việc . Cài đặt và . Kiểm thử o Kiểm thử đơn vị của các mô đun 32
Chương 3 Các mô hình vòng đời phần mềm o Kiểm thử tích hợp của các hệ thống con o Kiểm thử sản phẩm của toàn hệ thống Sản phẩm chuyển giao của pha xây dựng bao gồm: . Sổ tay người dùng ban đầu và các sổ tay khác . Tất cả các tài liệu được tạo ra(các phiên bản phát hành beta) . Kiến trúc hoàn thiện . Danh sách rủi ro đã được cập nhật . Kế hoạch quản lý dự án (Cho những phần còn lại của dự án) . Nếu cần thiết cập nhật trường hợp nghiệp vụ Pha chuyển tiếp Mục đích của pha chuyển tiếp là đảm bảo yêu cầu của khách hàng được đáp ứng . Lỗi trong sản phẩm phẩn mềm được sửa . Tất cả các sổ tay được hoàn thiện . Cố gắng tìm ra những rủi ro mà trước đó chưa được nhận dạng Pha này hướng tới những phản hồi từ phía mà phát hành beta được cài đặt Sản phẩm chuyển giao của pha chuyển tiếp bao gồm: . Tất cả các tài liệu được tạo ra (các phiên bản cuối cùng) . Các sổ tay hoàn thiện 3.7 MÔ HÌNH XOẮN ỐC Là mô hình bản mẫu nhanh kết hợp với phân tích rủi ro đi kèm ở mỗi pha Đặc điểm chính của mô hình xoán ốc: Nếu các rủi ro không được làm giảm bớt, thì dự án bị kết thúc ngay lập tức. PTIT Mô hình xoắn ốc đầy đủ: Ở trước mỗi pha là các giải pháp và phân tích rủi ro Theo sau mỗi pha là: Đánh giá và lập kế hoạch cho pha tiếp theo Chiều bán kính: Chi phí tích lũy cho đến hiện tại Chiều góc: sự đi lên theo vòng ốc 33
Chương 3 Các mô hình vòng đời phần mềm Điểm mạnh của mô hình xoắn ốc: Dễ dàng thay đổi mức độ kiểm thử Không phân biệt giữa phát triển và bảo trì Điểm yếu của mô hình xoắn ốc: Chỉ phù hợp với những phần mềm lớn Chỉ phù hợp với những phần mềm nội bộ 3.8 MÔ HÌNH MÃ NGUỒN MỞ Hai pha không hình thức Đầu tiên, một các nhân xây dựng một phiên bản đầu tiên . Đưa phiên bản này lên Internet (ví dụ: SourceForge.net) Sau đó, nếu có sự quan tâm PTITvề dự án này . Phiên bản đầu tiên sẽ được tải về một cách rộng rãi . Người dùng trở thành người đồng phát triển . Sản phẩm được mở rộng Điểm chính: Các cá nhân nhìn chung làm việc tình nguyện đối với dự án mã nguồn mở trong thời gian rảnh rỗi của họ Các hoạt động trong pha phi hình thức thứ hai . Báo cáo và sửa lỗi o Bảo trì sửa lỗi . Thêm các chức năng mới o Bảo trì hoàn thiện chức năng o Điều chỉnh phần mềm ở môi trường mới o Bảo trì thích hợp o Pha phi hình thức thứ hai chỉ bao gồm bảo trì sau khi đã chuyển giao sản phẩm 34
Chương 3 Các mô hình vòng đời phần mềm o Từ “người đồng phát triển” trong slide trước có thể thay thế bằng từ “đồng bảo trì” Mô hình vòng đời bảo trì sau khi chuyển giao sản phẩm Sản phẩm mã nguồn đóng được bảo trì và kiểm thử bởi nhân viên . Người dùng có thể đưa ra bản tường trình sự thất bại của phần mềm (failure) nhưng không bao giờ đưa ra được lỗi mã nguồn (fault) (vì mã nguồn không sẵn có) Phần mềm mã nguồn mở nhìn chung được bảo trì bởi người tình nguyện viên không lương . Người dùng được khuyến khích đưa ra bản tường trình về sự thất bại của phần mềm (failure) cũng như lỗi mã nguồn (fault) Nhóm chính . Số lượng nhỏ những người bảo trì tận tụy với sở thích, thời gian và những kỹ năng cần thiết để đưa ra những báo cáo lỗi mã nguồn đã được cố định(“fixes”) . Họ chịu trách nhiệm quản lý dữ án . Họ có quyền cài đặt lại những lỗi đã cố định Nhóm ngoại vi PTIT . Users who choose to submit defect reports from time to time Các phiên bản mới của phần mềm mã nguồn đóng được phát hành thường xuyên một năm một lần . Sau khi đã được kiểm thử cẩn thận bởi nhóm quản lý chất lượng phần mềm Các phát hành của nhóm chính của một phiên bản mới của sản phẩm mã nguồn mở được đưa ra ngay khi sẵn sàng . Có thể là một tháng hoặc thậm chí là một ngày so với với phiên bản trước đó . Nhóm chính thực hiện kiểm thử tối thiểu . Kiểm thử mở rộng được thực hiện bởi các thành viên của nhóm ngoại vi trong suốt thời gian sử dụng phần mềm . “Phát hành sớm và thường xuyên” Phiên bản làm việc đầu tiên được đưa ra khi sử dụng: . Mô hình bản mẫu nhanh; . Mô hình xây và sửa; và 35
Chương 3 Các mô hình vòng đời phần mềm . Mô hình mã nguồn mở Sau đó: . Mô hình bản mẫu nhanh o Phiên bản đầu tiên bị bỏ qua . Mô hình xây và sửa và mô hình vòng đời mã nguồn mở o Phiên bản ban đầu trở thành phiên bản đích Do đó, trong dự án mã nguồn mở, nhình chung không có đặc tả và không có thiết kế Một số dự án mã nguồn mở đã thành công như thế nào khi không có đặc tả hoặc thiết kế? Sản phẩm mã nguồn mở đã thu hút được một số chuyên gia phần mềm tốt nhất trên thế giới . Họ có thể xây dựng các chức năng hiệu quả mà không cần đặc tả hoặc thiết kế Tuy nhiên, cuối cùng thì sự phát triển sản phẩm mã nguồn mở cũng dừng lại khi mà nó không có sự bảo trì nữa Mô hình vòng đời mã nguồn mở bị hạn chế trong khả năng ứng dụng của nó Nó có thể thành công cực độ đối với những dự án cơ sở hạ tầng như . Hệ điều hành (Linux, OpenBSD, Mach, Darwin) . Trình duyệt Web (Firefox, Netscape) . Trình biên dịch (gcc) . Máy chủ Web (Apache) . Hệ thống quản lý dữ liệu (MySQL) Không thể phát triển mã nguồn mở một sản phẩm phần mềm mà chỉ được sử dụng trong tổ chức thương mại . Các thành viên của cả nhóm chính và nhóm ngoại vi đều luôn luôn là những người dùng của phần mềm PTITđang được phát triển Mô hình vòng đời mã nguồn mở không không thể áp dụng được trừ khi sản phẩm đích được xem xét bởi một số lượng lớn người dùng vì sản phẩm đó có ích cho họ. Khoảng một nửa dự án mã nguồn mở trên Web không thu hút được các nhóm phát triển vào làm việc cho dự án Even where work has started, the overwhelming preponderance will never be completed Nhưng khi mô hình mã nguồn mở đã làm việc thì đối khi nó cũng đem lại thành công đáng kinh ngạc . Những sản phẩm mã nguồn mở được kể ở slide trước đã đước sử dụng bởi hàng triệu người dùng 36
Chương 4. Kiểm thử CHƯƠNG 4: KIỂM THỬ 4.1 VẤN ĐỀ CHẤT LƯỢNG PHẦN MỀM Phần mềm thỏa mãn ở một mức độ nào đó các đặc tả của nó Mỗi chuyên gia phần mềm có trách nhiệm đảm bảo công việc của họ là chính xác o Chất lượng phải được xây dựng từ ban đầu 4.1.1 Đảm bảo chất lượng phần mềm (SQA) Các thành viên của nhóm SQA phải đảm bảo những người phát triển thực hiện công việc đạt chất lượng cao o Ở cuối mỗi luồng công việc o Khi sản phẩm được hoàn thiện Thêm vào đó, đảm bảo chất lượng phải được áp dụng o Trong mỗi tiến trình . Ví dụ: cácPTIT chuẩn 4.1.2. Độc lập trong quản lý Phải độc lập về quản lý giữa o Nhóm phát triển o Nhóm SQA Mỗi nhóm không được phép vượt quá quyền hạn sang các nhóm khác Quản lý lâu năm hơn phải quyết định liệu o Chuyển giao sản phẩm đúng thời hẹn nhưng có lỗi xảy ra o Hoặc kiểm thử hơn nữa và chuyển giao sản phẩm muộn hơn Những quyết định phải xem xét đến sự quan tâm của khách hàng và tổ chức phát triển 37
Chương 4: Kiểm thử 4.2 KIỂM CHỨNG PHẦN MỀM Có hai kiểu : Kiểm thử không có sự thực thi và kiểm thử có dựa trên sự thực thi “V & V” o Xác minh (Verification) . Xác định nếu luồng công việc được hoàn thiện chính xác Determine if the workflow was completed correctly o Thẩm định (Validation) . Xác định nếu toàn bộ sản phẩm đáp ứng các yêu cầu đưa ra (Determine if the product as a whole satisfies its requirements) o Thuật ngữ “xác minh” cũng được sử dụng cho kiểm thử không có sự thực thi. 4.3 CÁC PHƯƠNG PHÁP KIỂM CHỨNG 4.3.1. Kiểm thử không có sự thực thi Nguyên lý cơ bản o Chúng ta không nên tự mình rà soát công việc của mình o Có sự hiệp lực trong nhóm 4.3.1.1 Rà soát lướt qua (Walkthrough) Đội rà soát lướt qua bao PTITgồm từ 4 đến 6 thành viên Nó bao gồm đại diện của o Đội chịu trách nhiệm cho luồng công việc hiện thời o Đội chịu trách nhiệm cho luồng công việc tiếp thep o Nhóm SQA Rà soát lướt qua được nói trước bởi sự chuẩn bị o Danh sách các mục . Các mục không hiểu . Các mục mà xuất hiện ở dạng lỗi Quản lý rà soát lướt qua: Đội rà soát lướt qua được đại diện SQA làm chủ trì 38
Chương 4: Kiểm thử Trong rà soát lướt qua chỉ phát hiện lỗi, không sửa o Việc sửa lỗi được thực hiện bởi một ủy ban và có khả năng dẫn đến chất lượng thấp o Chi phí sửa lỗi của ủy ban là quá cao o Không phải tất cả các hạng mục được đánh dấu thực tế đều sai o Rà soát lướt quat không nên kéo dài quá 2 tiếng o Cũng như không có thời gian sửa lỗi 4.3.1 .2 Kiểm tra kỹ lưỡng (Inspection) Quá trình kiểm tra kỹ lưỡng gồm 5 bước hình thức o Tổng quan o Chuẩn bị, với mục đích thống kê các loại lỗi o Kiểm tra kỹ lưỡng o Sửa lỗi o Theo dõi Đội kiểm tra gồm 4 thành viên o Người điều tiết (Moderator)PTIT o Một thành viên trong đội thực đang thi luồng công việc hiện hành o Một thành viên của đội sẽ thực hiện luồng công việc tiếp theo o Một thành viên của nhóm SQA Những vai trò đặc biệt được đảm nhiệm bởi o Người điều tiết (Moderator) o Người đọc (Reader) o Người ghi chép (Recorder) Thống kê lỗi: Các lỗi được ghi chép lại cẩn thận o Ví dụ: 39
Chương 4: Kiểm thử . Chính hoặc phụ Các lỗi đựoc ghi chép theo các kiểu lỗi o Ví dụ các lỗi thiết kế: . Không phải tất cả các mục đã được bàn bạc . Các lý lẽ hình thức và thực tế không tương ứng với nhau Đối với mỗi luồng công việc xác định, chúng ta so sánh tỷ lệ lỗi hiện thời với tỷ lệ lỗi của những sản phẩm trước Nếu thấy số lượng lỗi không cân xứng với tài liệu o Thiết kế lại từ ban đầu là cách tốt nhất Thực hiện chuyển những thống kê lỗi tới luồng công việc tiếp theo o Chúng ta có thể không phát hiện được tất cả các lỗi của mỗi kiểu cụ thể trong quá trình kiểm tra kỹ lưỡng hiện tại Thống kê quá trình kiểm tra kỹ lưỡng Quá trình kiểm tra kỹ lưỡng IBM đã chỉ ra: o 82% lỗi được phát hiện (1976) o 70% lỗi được phát hiện (1978) o 93% lỗi được phátPTIT hiện (1986) Chuyển hệ thống (Switching system) o Giảm 90% chi phí trong việc phát hiện lỗi (1986) JPL o 4 lỗi chính, 14 lỗi phụ trong 2 giờ (1990) o Tiết kiệm $25,000 trong mỗi quá trình kiểm tra kỹ lưỡng o Số lượng lỗi đã giảm theo hàm số mũ trong mỗi pha (1992) Cảnh báo Thống kê lỗi chưa bao giờ được sử dụng để đánh giá hiệu năng o “Killing the goose that lays the golden eggs” 40
Chương 4: Kiểm thử Công cụ cho kiểm tra kỹ lưỡng : Tỷ lệ kiểm tra kỹ lưỡng (ví dụ: số trang thiết kế được kiểm tra trên 1giờ) Mật độ lỗi (ví dụ: số lỗi trên nghìn dòng lệnh (KLOC) được kiểm tra) Tỷ lệ phát hiện lỗi ( ví dụ: số lỗi được phát hiện trên 1 giờ) Hiệu năng phát hiện lỗi ( ví dụ: số lượng những lỗi chính, lỗi phụ được phát hiện trong 1 giờ) Có phải tăng 50% tỷ lệ phát hiện lỗi thì đồng nghĩa với o Chất lượng giảm? Hoặc o Quá trình kiểm tra kỹ lưỡng hiệu quả hơn? 4.3.1.3 So sánh giữa rà soát lướt qua và kiểm tra kỹ lưỡng Lướt qua o Hai bước, tiến trình không hình thứcprocess . Chuẩn bị . Phân tích Kiểm tra kỹ lưỡng o 5 bước, tiến trình hiènh thức . Tổng quanPTIT . Chuẩn bị . Kiểm tra kỹ lưỡng . Sửa lỗi . Theo dõi 4.3.1.4 Những điểm mạnh và điểm yếu của các loại rà soát Rà soát có thể rất hiệu o Các lỗi được phát hiện sớm ở trong quá trình phát triển phần mềm Rà soát ít hiệu quả nếu quá trình không đầy đủ o Những phần mềm phạm vi lớn bao gồm những phần nhỏ và độc lập với nhau 41
Chương 4: Kiểm thử o Tài liệu của những luồng công việc trước phải được hoàn thiện và luôn có sẵn 4.3.2 Kiểm thử có dựa trên sự thực thi Các tổ chức sử dụng tới 50% ngân sách dự án để kiểm thử o Nhưng phần mềm được chuyển giao thường xuyên xảy ra lỗi Dijkstra (1972) o “Kiểm chương trình có thể là cách rất hiệu quả để chỉ ra các lỗi nhưng không có khả năng để chỉ ra sự vắng mặt của chúng”.(“Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence”) 4.4 NHỮNG VẤN ĐỀ TRONG KIỂM THỬ 4.4.1 Cái gì nên được kiểm thử? Chúng ta cần kiểm thử tính chính xác, tiện ích, tính đáng tin, tính mạnh mẽ và hiệu năng 4.4.1.1 Tính chính xác Một phần mềm chạy chính xác nếu nó thỏa mãn đặc tả của nó Tính chính xác của các đặc tả o Đặc tả không chính sách đối với một yêu cầu sắp xếp: PTIT o Hàm trickSort đã thỏa mãn đặc tả này: o Đặc tả chính xác: 42
Chương 4: Kiểm thử o Về mặt kỹ thuật, tính chính xác là không cần thiết (chẳng hạn như trình biên dịch C++) và không đầy đủ (ví dụ như : trickSort) 4.4.1.2 Tiện ích Sản phẩm phần mềm đáp ứng ở một mức nào đó yêu cầu của người dùng o Ví dụ: . Tính dễ sử dụng . Các chức năng hữu ích . Có hiệu quả trong chi phí 4.4.1.3 Tính đáng tin Đo tần suất và tính quan trọng của các thất bại (failure) o Thời gian trung bình giữa những lần chức năng không thực hiện o Thời gian trung bình để sửa o Thời gian và chi phíPTIT để sửa chữa kết quả của một thất bại trong hệ thống phần mềm 4.4.1.4 Tính mạnh mẽ Một chức năng của o Một dãy các điều kiện hoạt o Khả năng các kết quả không được chấp nhận với đầu vào hợp lệ o Ảnh hưởng của đầu vào không hợp lệ 4.4.1.5 Hiệu năng Những ràng buộc về thời gian và không gian được đáp ứng ở một mức độ nào đó Phần mềm thời gian thực được đặc trưng bởi những ràng buộc thời gian thực Nếu dữ liệu bị mất bởi vì hệ thống quá chậm 43
Chương 4: Kiểm thử o Không có cách để phục hồi dữ liệu đó 4.4.2 Kiểm thử và sự kiểm chứng tính chính xác Sự kiểm chứng tính chính xác là một phương pháp khác đối với kiểm thử có dựa trên sự thực thi Ví dụ về sự kiểm chứng tính chính xác o Đoạn code đã chứng minh sự chính xác o Biểu đồ luồng tương ứng với đoạn code trên PTIT o Thêm vào : đặc tả đầu vào, đặc tả đầu ra, số lượng vòng lặp và sự xác nhận 44
Chương 4: Kiểm thử 4.4.3 Sự kiểm chứng tính chính xác và kỹ nghệ phần mềm Ba chuyện tưởng tượng trong chứng minh tính chính xác o Kỹ sư phần mềm không đủ kiến thức toán học để kiểm chứng . Hầu hết các nghành khoa học máy tính hoặc biết hoặc có thể học toán học đã yêu cầu cho kiểm chứng o Việc chứng minh yêu cầu chi phí rất cao trong thực tế . Khả năng kinhPTIT tế được xác định từ phân tích lợi nhuận và chi phí o Việc chứng minh quá khó khăn . Nhiều sản phảm phần mềm không bình thường đã được chứng minh thành công . Các công cụ giống như chứng minh định lý có thể sẽ hữu ích Những khó khăn khi chứng minh tính chính xác o Chúng ta có thể tin vào cách chứng minh định lý không? o Chúng ta tìm các đặc tả đầu vào, đầu ra, số lượng vòng lặp như thế nào? 45
Chương 4: Kiểm thử o Chuyện gì sẽ xảy ra nếu các đặc tả là sai? o Chúng ta có thể chưa bao giờ chắc chắn rằng các đặc tả hoặc hệ thống xác minh là chính xác Sự kiểm chứng tính chính xác là một công cụ kỹ nghệ phần mềm quan trọng, thích hợp với: o Khi cuộc sống con người đang lâm nguy (When human lives are at stake) o Khi đã được chỉ ra bởi phân tích lợi nhận – chi phí (When indicated by cost– benefit analysis) o Khi rủi ro của việc không phân tích quá lớn (When the risk of not proving is too great) Sự kiểm chứng không hình thức có thể cải thiện chất lượng của phần mềm o Sử dụng những câu lệnh assert 4.4.4 Ai thực hiện kiểm thử phần mềm Lập trình là xây dựng Kiểm thử là phá huỷ o Một kiểm thử thành công tìm ra một lỗi Vì thế, những người lập trìnhPTIT không nên kiểm thử chính tài liệu mã của họ viết Giải pháp: o Người lập trình thực hiện kiểm thử không hình thức o Sau đó nhóm SQA thực hiện kiểm thử một cách hệ thống o Người lập trình gỡ lỗi mô đun đó Tất cả các trường hợp kiểm thử phải o Được lập kế hoạch bằng tay trước đó, bao gồm đầu ra mong muốn và o Được giữ về sau 4.4.5 Khi nào kiểm thử dừng Chỉ khi sản phẩm phần mềm không thể thay đổi (Only when the product has been irrevocably discarded) 46
Chương 4: Kiểm thử PTIT 47
Chương 5. Lập kế hoạch và ước lượng CHƯƠNG 5: LẬP KẾ HOẠCH VÀ ƯỚC LƯỢNG 5.1 VẤN ĐỀ LẬP KẾ HOẠCH VÀ ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM Trước khi bắt đầu xây dựng phần mềm, việc lập kế hoạch cho toàn bộ quá trình phát triển một cách chi tiết là cần thiết Việc lập kế hoạch được thực hiện liên tục trong suốt quá trình phát triển và bảo trì sau khi chuyển giao o Việc lập kế hoạch ban đầu là không đủ o Việc lập kế hoạch phải được thực hiện trong suốt dự án o Việc lập kế hoạch chi tiết có thể diễn ra sớm nhất có thể sau khi các đặc tả hoàn thiện PTIT Độ chính xác của ước lượng tăng khi tiến trình phần mềm thực hiện được nhiều Ví dụ o Chi phí ước lượng 1 triệu đô la trong suốt luồng công việc xác định yêu cầu . Chi phí thực tế có thể nằm trong khoảng ($0.25M, $4M) o Chi phí ước lượng 1 triệu đô la ở cuối luồng công việc xác định yêu cầu . Chi phí thực tế có thể nằm trong khoảng ($0.5M, $2M) o Chi phí ước lượng của 1 triệu đô la ở cuối luồng công việc phân tích (thời gian thích hợp sớm nhất) . Chi phí thực có thể nằm trong khoảng ($0.67M, $1.5M) 48
Chương 5: Lập kế hoạch và ước lượng Mô hình là cũ (1976) o Kỹ thuật ước lượng đã cải tiến o Nhưng hình dạng của đường cong này là giống với ban đầu 5.2 ƯỚC LƯỢNG THỜI GIAN VÀ CHI PHÍ Uớc lượng thời gian chính xác là cần thiết Ước lượng chi phí chính xác là cần thiết o Chi phí bên trong, bên ngoài Có quá nhiều thay đổi trong việc ước lượng chính xác chi phí hoặc thời gian Nhân lực Sackman (1968) đo sự khác PTITbiệt lên đến 28-1 giữa các cặp lập trình viên(Sackman (1968) measured differences of up to 28 to 1 between pairs of programmers ) o Ông so sánh sự kết hợp của các cặp lập trình viên êề mặt . Kích cỡ phần mềm . Thời gian thực thi sản phẩm . Thời gian phát triển . Thời gian viết mã . Thời gian gỡ lỗi Những thành viên nhân viên cốt yếu có thể từ bỏ trong suốt dự án 5.2.1 Thước đo kích cỡ của sản phẩm phần mềm a- Số lượng dòng mã (LOC, KDSI, KLOC) Một thước đo khác o Số dòng mã nguồn (KDSI) Mã nguồn chỉ là một phần nhỏ của nỗ lực phát triển toàn bộ phần mềm (Source code is only a small part of the total software effort ) Những ngôn ngữ khách nhau dẫn đến chiều dài mã lệnh khác nhau LOC không được dùng để xác định ngôn ngữ phi thủ tục (như LISP) 49
Chương 5: Lập kế hoạch và ước lượng Các đếm dòng lệnh không rõ ràng o Số dòng lệnh có thể thực thi? o Những định nghĩa dự liệu? o Những lời chú thích? o Các câu lệnh JCL? o Dòng lệnh đã được thay đổi/ xóa? Không phải mọi thứ được viết ra đều chuyển giao cho khách hàng Bộ sinh bản ghi, màn ảnh, GUI có thể sinh hàng nghìn dòng lệnh trong mỗi phút LOC chỉ được biết chính xác khi phần mềm được hoàn thiện Do đó, ước lượng dựa trên LOC nguy hiểm gấp đôi o Để bắt đầu tiến trình ước lượng, LOC trong phần mềm đã hoàn thiện phải được ước lượng o Sau đó, ước lượng LOC được sử dụng để ước lượng chi phí của phần mềm b- FFP Được sử dụng đối với ước lượng chi phí của một phần mềm xử lý dữ liệu cỡ trung bình Ba thành phần cấu trúc cơ bản của pâần mềm xử lý dữ liệu o Các tệp o Các luồng o Các tiến trình Với số lượng tệp (Fi), số luồng (Fl), và số tiến trình (Pr) o Kích thước (s), chi phí (c) được xác định bởi S = Fi + Fl + Pr C = b S Hằng số b (hiệu năng hoặc năng suất) thay đổi từ tổ chức này đến tổ chức khác Tính hiệu lực và tính tin cậy của thước đo FFP được chứng minh bằng cách sử dụng cùng một mục đích o Tuy nhiên, thước đo này không bao giờ được mở rộng đối với cơ sở dữ liệu PTIT c- Điểm chức năng (Function Points) Dựa trên số lượng đầu vào (Inp), đầu ra (Out), các câu hỏi(Inq), các tệp chính (Maf), các giao diện (Inf) Đối với bất kỳ sản phẩm nào, số điểm chức năng được xác định bằng . FP = 4 Inp + 5 Out + 4 Inq + 10 Maf + 7 Inf Đây là một trường hợp quá đơn giản của một tiến trình 3 bước Bước 1. phân loại mỗi thành phần của phần mềm (Inp, Out, Inq, Maf, Inf) thuộc loại đơn giản, trung bình, hoặc phức tạp o Gán số lượng thích hợp các điểm chức năng o The sum gives UFP (unadjusted function points) 50
Chương 5: Lập kế hoạch và ước lượng Bước 2. Tính toán nhân tố độ phức tạp về mặt kỹ thuật (technical complexity factor -TCF) o Gián giá trị từ 0 (không có mặt) tới 5 (ảnh hưởng mạnh mẽ từ đầu đến cuối) đối với mỗi nhân tố thuộc 14 nhân tô như tỷ giá giao dịch, tính khả chuyển PTIT Thêm 14 con số o Đưa ra mức độ ảnh hưởng tổng thể (DI) TCF = 0.65 + 0.01 DI Nhân tố độ phức tạp về mặt kỹ thuật nằm trong khoảng từ 0.65 tới 1.35 Bước 3. Số lượng điểm chức năng được tính bằng FP = UFP TCF Phân tích về điểm chức năng Các điểm chức năng thường tốt hơn KDSI – nhưng có một vài vấn đề xảy ra 51
Chương 5: Lập kế hoạch và ước lượng Giống như FFP, bảo trì có thể được đo một cách thiếu chính xác Có thể thay đổi o Số lượng các tệp, luồng và các tiến chình o Số lượng đầu vào, đầu ra, câu hỏi, các tệp chính và các giao diện Theo lý thuyết, có thể thay đổi tất cả các dòng mã với việc thay đổi số lượng các dòng mã (In theory, it is possible to change every line of code with changing the number of lines of code) Các điểm chức năng Mk II Thước đo này đã được đưa ra để tính toán UFP một cách chính xác hơn Chúng ta chia nhỏ phần mềm thành các giao tác thành phần, mỗi giao tác thành phần gồm đầu vào, tiến trình và đầu ra Các điểm chức năng Mark II được sử dụng rộng rãi trên thế giới d- COCOMO 5.2.2 Các kỹ thuật ước lượng chi phí a- Những đánh giá của chuyên gia nhờ sự tương tự (Expert judgment by analogy) Các chuyên gia so sánh sản phẩm đích với những sản phẩm đã hoàn thiện o Sự ước chừng có thể dẫn tới ước lượng chi phí sai o Các chuyên gia có thể thu thập lại những thiếu xót của các phần mềm đã hoàn thiện PTIT o Các chuyên gia con người có nhiều xu hướng (Human experts have biases ) o Tuy nhiên, kết quả của sự ước lượng bởi một nhóm lớn các chuyên gia có thể chính xác Kỹ thuật Delphi đôi khi được sử dụng để đạt được sự đồng thuận nhất trí b- Phương pháp dưới lên Chia sản phẩm phần mềm thành những thành phần nhỏ hơn o Các thành phần nhỏ có thể không dễ ước lượng hơn o Tuy nhiên, có chi phí mức tiến trình Khi sử dụng mô hình hướng đối tượng o Sự độc lập của các lớp có ở đây (The independence of the classes assists here) o Tuy nhiên, những tương tác giữa các lớp làm rắc rối tiến trình ước lượng c- Các mô hình ước lượng chi phí thuật toán (Algorithmic cost estimation models ) Một thước đo được sử dụng như đầu vào đối với mô hình để tính toán chi phí và thời gian o Mô hình thuật toán không thiên vị, do đó tốt hơn hẳn ý kiến chuyên gia o Tuy nhiên, ước lượng chỉ tốt bằng những giả định tiềm ẩn (However, estimates are only as good as the underlying assumptions ) 52
Chương 5: Lập kế hoạch và ước lượng Ví dụ o SLIM Model o Price S Model o COnstructive COst MOdel (COCOMO) 5.2.3 COCOMO trung gian COCOMO bao gồm 3 mô hình o Mô hình ước lượng vĩ mô đối với toàn bộ sản phẩm phần mềm o COCOMO trung gian o Mô hình ước lượng vi mô xem xét chi tiết phần mềm Chúng ta nghiên cứu COCOMO trung gian Bước 1. Ước lượng chiều dài của phần mềm trong KDSI Bước 2. Ước lượng chế độ phát triển phần mềm (có tổ chức (organic), nửa tách rời (semidetached), nhúng(embedd)) Ví dụ: o Phần mềm không phức tạp (chế độ organic) 1.05 . (Công sức danh nghĩa)Nominal effort = 3.2 ´ (KDSI) person-months Bước 3. Tính toán công sức danh nghĩa Ví dụ: o Phần mềm có tổ chức (Organic product) o 12,000 câu lệnh được chuyển giao (12 KDSI) (đã ước lượng) 1.05 o (Công sức danh nghĩa )Nominal effort = 3.2 ´ (12) = 43 person-months Bước 4. Nhân giá trị danh nghĩa với 15 lần chi phí phát triển phần mềm (Step 4. Multiply the nominal value by 15 softwarePTIT development cost multipliers ) Ví dụ: 53
Chương 5: Lập kế hoạch và ước lượng o Phần mềm xử lý giao tiếp dựa trên bộ vi xử lý cho mạng chuyển tiền điện tử với độ tin cậy, hiệu năng, lịch phát triển và các yêu cầu giao diện cao (Microprocessor-based communications processing software for electronic funds transfer network with high reliability, performance, development schedule, and interface requirements ) Bước 1. Ước lượng chiều dài của phần mềm sản phẩm o 10,000 câu lệnh được chuyển giao (10 KDSI) Bước 2. Ước lượng chế độ phát triển o Chế độ phức tạp (“nhúng”-“embedded”) Bước 3. Tính công sức danh nghĩa 1.20 o (Công sức danh nghĩa)Nominal effort = 2.8 ´ (10) = 44 person-months Bước 4. Nhân giá trị danh nghĩa với 15 lần chi phí phát triển phần mềm o Product of effort multipliers = 1.35 (Software development effort multipliers) PTIT Do đó, Ước lượng công sức cho dự án 1.35 x 44 = 59 person-months. Ước lượng công sức cho dự án (59 person-months) được sử dung là đầu vào cho công thức bổ sung đối với o Chi phí đô la o Lịch biểu phát triển o Phân phối pha và hoạt động o Chi phí máy tính o Chi phí bảo trì hàng năm o Các mục liên quan COCOMO trung gian đã được xác nhận với một mẫu lớn (Intermediate COCOMO has been validated with respect to a broad sample ) Giá trị thực nằm trong khoảng 20% giá trị dự đoán và khoảng 68% thời gian o COCOMO trung gian là phương thức ước lượng chính xác nhất về thời gian của nó 54
Chương 5: Lập kế hoạch và ước lượng Vấn đề chính o Nếu ước lượng số lượng dòng mã của sản phẩm đích là sai, thì mọi thứ đều sai 5.2.4 COCOMO II 1995 đã mở rộng COCOMO 1981 với sự kết hợp o Hướng đối tượng o Mô hình vòng đời hiện đại o Bản mẫu nhanh o Ngôn ngữ thế hệ thứ tư o Phần mềm COTS COCOMO II phức tạp hơn nhiều so với phiên bản đầu Có 3 mô hình khác nhau o Mô hình kết hợp ứng dụng đối với các pha ban đầu (Application composition model for the early phases) . Dựa trên các điểm đặc trưng (tương tự với điểm chức năng) o Mô hình thiết kế sớm . Dựa trên các điểm chức năng o Mô hình hậu kiến trúc (Post-architecture model) . Dựa trên các điểm chức năng hoặc KDSI Mô hình công sức COCOMO cơ bản là b o effort = a ×(size) o COCOMO trung gian . Ba giá trị đối với (a,b ) o COCOMO II . b thay đổi dựa vào giá trị của các biến xác định COCOMO II hỗ trợ sử dụng lại COCOMO II has 17 multiplicative cost drivers (was15) o Seven are new PTIT It is too soon for results regarding o The accuracy of COCOMO II o The extent of improvement (if any) over Intermediate COCOMO 5.2.5 Theo dõi ước lượng thời gian và chi phí Sử dụng bất cứ phương thức ước lượng nào thì việc theo dõi cũng là quan trọng Công việc được làm o Những tài nguyên để thực hiện công việc đó Số tiền để chi trả cho công việc đó Các tài nguyên Các tài nguyên cần thiết cho phát triển phần mềm: o Con người o Phần cứng o Phần mềm hỗ trợ Việc sử dụng các các loại tài nguyền với thời gian Đường cong Rayleigh miêu tả một cách chính xác việc giả định về tài nguyên 55
Chương 5: Lập kế hoạch và ước lượng Tòan bộ kế hoạch phát triển phần mềm phải là một hàm thời gian Các loại công việc Chức năng dự án o Công việc được thự thi xuyên suốt dự án o Ví dụ: . Quản lý dự án . Điểu khiển chất lượng Hoạt động (activity) o Công việc liên quan tới một pha cụ thể o Đơn vị chính của côngPTIT việc, o Với ngày tháng bắt đầu và kết thúc chính xác, o Giả định về thời gian và o Các sản phẩm công việc như ngân sách, thiết kế, lập lịch, mã nguồn, hoặc sổ tay người dùng Nhiệm vụ (task) o Các hoạt động bao gồm tập các nhiệm vụ (đơn vị nhỏ nhất của công việc có thể quản lý được) Sự hoàn thành của các sản phẩm công việc Mốc quan trọng (Milestone): là ngày mà sản phẩm công việc được hoàn thiện Nó phải chuyển qua và thực hiện rà soát bởi o Các thành viên trong đội o Quản lý o Khách hàng Khi sản phẩm công việc được rà soát và được đồng ý, thì nó trở thành một phiên bản cơ sở Gói công việc Sản phẩm công việc, cùng với 56
Chương 5: Lập kế hoạch và ước lượng o Biên chế các yêu cầu o Thời gian o Tài nguyên o Gán trách nhiệm cho các cá nhân o Tiêu chấp nhận sản phẩm công việc o Ngân sách chi tiết là hàm thời gian, chỉ định . Các chức năng dự án . Các hoạt động 5.3 CÁC THÀNH PHẦN CỦA VIỆC LẬP KẾ HOẠCH PHÁT TRIỂN PHẦN MỀM 5.3.1Khung kế hoạch quản lý dự án phần mềm(SPMP) Có 3 cách để xây dựng SPMP Một cách tốt nhất là chuẩn IEEE 1058.1 o Chuẩn được chấp nhận rộng rãi o Nó được thiết kế để sử dụng với tất cả các loại sản phẩm phần mềm o Nó hỗ trợ cải thiện tiến trình . Many sections reflect CMM key process areas o Là lý tưởng đối với quy trình hợp nhất . Có những phẩn để điều khiển các yêu cầu và quản lý rủi ro Một trong những phần không được áp dụng trong các phần mềm cỡ nhỏ o Ví dụ: kế hoạch quản lý nhà thầu phụ 5.3.2 Kế hoạch quản lý dự án phần mềm IEEE PTIT 57
Chương 5: Lập kế hoạch và ước lượng 5.3.3 Việc lập kế hoạch kiểm thử SPMP phải chỉ ra rõ ràng những gì kiểm thử phải làm Việc theo dõi kiểm tra là cần thiết Tất cả các trường hợp kiểm thử hộp đen có thể được phác thảo ra sớm nhất có thể sau khi các đặc tả hoàn thiện 5.3.4 Yêu cầu đào tạo “Chúng ta không cần lo lắng về việc đào tạo đến tận khi phần mềm hoàn thiện, và sau đó chúng ta có thể đào tạo người dùng” Việc đào tạo nhìn chung được yêu cầu bởi các thành viên của nhóm phát triển, bắt đầu với đào tạo trong việc lập kế hoạch phần mềm Một phương thức phát triển phần mềm mới đòi hỏi phải đào tạo mọi thành viên trong nhóm phát triển Việc giới thiệu các công cụ phần cứng hoặc phần mềm của bất cứ loại nào đều đòi hỏi phải có đào tạo Những người lập trình có thể yêu cầu đào tạo về các hệ điều hành và/hoặc ngôn ngữ cài đặt Việc đào tạo chuẩn bị tài liệu có thể được yêu cầu Các thao tác máy tính đòi hỏi phải được đào tạo 5.3.5 Các chuẩn tài liệu Số lượng tài liệu được sinh ra bởi một phần mềm? o Phần mềm thương mại bên trong IBM (50 KDSI) . 28 trang tài liệu trên KDSI o Phần mềm thương mại cùng kích cỡ . 66 trang tài liệu trên KDSI o IMS/360 Version 2.3 (about 166 KDSI) . 157 trang tài liệu trên KDSI o [TRW] với 100 giờ sử dụng cho hoạt động viết mã, 150-200 giờ được sử dụng cho các hoạt động liên quanPTIT tới việc viết tài liệu Lập kế hoạch Điều khiển Tài chính Kỹ thuật Mã nguồn Những lời chú thích với mã nguồn Ưu điểm của các chuẩn tài liệu Giảm hiểu lầm giữa các thành viên trong đội Trợ giúp SQA Chỉ những nhân viên mới phải học các chuẩn Các chuẩn trợ giúp những người lập trình bảo trì Việc chuẩn hóa là quan trọng đối với các sổ tay người dùng Là một phần của tiến trình lập kế hoạch o Các chuẩn phải được thiết lập đối với tất cả các tài liệu Sản phẩm là tài liệu 58
Chương 5: Lập kế hoạch và ước lượng 5.3.6 Công cụ CASE cho việc lập kế hoạch và ước lượng Rất cần thiết để có o Một bộ xử lý từ, và o Một bảng tính Hiện nay có công cụ COCOMO and COCOMO II Công cụ quản lý trợ giúp việc lập kế hoạch và giám sát o MacProject o Microsoft Project 5.4 KIỂM THỬ VIỆC LẬP KẾ HOẠCH Chúng ta phải kiểm tra tòan bộn SPMP o Đặc biệt chú ý tới ước lượng thời gian và chi phí 5.5 LẬP KẾ HOẠCH CHO CÁC DỰ ÁN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Phần mềm hướng đối tượng bao gồm các phần độc lập với nhau Do đó, việc lập kế hoạch phần nào dễ dàng hơn Việc lập kế hoạch toàn bộ nhiều hơn tổng việc lập kế hoạch của các Chúng ta có thể sử dụng COCOMO II Tuy nhiên, sử dụng lại bao gồm những sai sót trong ước lượng chi phí và thời gian o Sử dụng lại những thành phần sẵn có trong suốt quá trình phát triển o Sản phẩm của các thành phần để sử dụng lại trong tương lai Những công việc này theo các hướng đối nghịch nhau Dữ liệu mới hơn: việc lưu trữ vượt quá chi phí PTIT 59
Chương 6. Pha xác định yêu cầu CHƯƠNG 6: PHA XÁC ĐỊNH YÊU CẦU 6.1 XÁC ĐỊNH YÊU CẦU CỦA KHÁCH HÀNG Hiểu sai o Chúng ta phải xác định những gì khách hàng muốn “Tôi biết bạn tin rằng bạn đã hiểu những gì bạn nghĩ là tôi đã nói, nhưng tôi không chắc bạn nhận ra rằng những gì bạn nghe không phải là điều mà tôi muốn nói!” (“I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!”) Chúng ta phải xác định những gì khách hàng cần Rất khó để người phân tích một hệ thống để hình dung ra một sản phẩm phần mềm và các chức năng của nó o Vấn đề này khó hỏi khách hàng Một người phân tích hệ thốngPTIT có kinh nghiệm cần làm rõ những thông tin thích hợp cho khách hàng Khách hàng là nguồn duy nhất của thông tin này Giải pháp: o Thu thập những thông tin ban đầu từ khách hàng o Sử dụng những thông tin ban đầu giống như đầu vào của quy trình hợp nhất o Theo sát các bước của quy trình hợp nhất để xác định các nhu cầu thực của khách hàng 6.2 TỔNG QUAN VỀ LUỒNG CÔNG VIỆC XÁC ĐỊNH YÊU CẦU Mục đích của luồng công việc xác định yêu cầu Để trả lời câu hỏi: 60
Chương 6: Pha xác định yêu cầu o Sản phẩm phần mềm phải có khả năng làm được những gì? Nội dung về luồng công việc xác định yêu cầu Đầu tiên, hiểu được lĩnh vực ứng dụng o Môi trường cụ thể mà sản phẩm phần mềm đích hoạt động Thứ hai, xây dựng một mô hình nghiệp vụ o Mô hình các tiến trình nghiệp vụ của khách hàng Thứ ba, sử dụng mô hình nghiệp vụ để xác định các yêu cầu khách hàng Lặp lại các bước trên Các định nghĩa Tìm ra các yêu cầu của khách hàng o Thu thập các yêu cầu o Các phương thức bao gồm phỏng vấn và điều tra Làm mịn và mở rộng những yêu cầu ban đầu o Phân tích yêu cầu 6.2.1 Hiểu lĩnh vực ứng dụng Mỗi thành viên của đội phát triển phải trở nên quen thuộc với lĩnh vực ứng dụng o Thuật ngữ chính xácPTIT là cần thiết Xây dựng thuật ngữ o Một danh sách các từ kỹ thuật được sử dụng trong lĩnh vực ứng dụng và ý nghĩa của nó 6.2.2 Mô hình nghiệp vụ Một mô hình nghiệp vụ là sự miêu tả các tiến trình nghiệp vụ của một tổ chức Mô hình nghiệp vụ đưa ra cách hiểu về toàn bộ nghiệp vụ của khách hàng o Tri thức này là cần thiết để đưa ra lời khuyên cho khách hàng về mặt tính toán Các nhà phân tích hệ thống cần thu thập một cách hiểu chi tiết về các loại tiến trình nghiệp vụ khác nhau. o Các kỹ thuật khác nhau được sử dung, ban đầu là phỏng vấn 61
Chương 6: Pha xác định yêu cầu 6.2.2.1 Phỏng vấn Đội xác định yêu cầu cần gặp gỡ khách hàng và người dùng để thu thập được những thông tin liên quan Có hai loại câu hỏi: o Câu hỏi kết thúc đóng (Close-ended question)syêu cầu một câu trả lời cụ thể o Câu hỏi kết thúc mở (Open-ended questions) khuyến khích người được phỏng vấn nói thẳng ý kiến của mình Có hai kiểu phỏng vấn o Trong cuộc phỏng vấn có cấu trúc, các câu hỏi đã được lập kế hoạch cụ thể từ trước và thường là những câu hỏi kết thúc đóng o Trong cuộc phỏng vấn không cấu trúc, các câu hỏi được đưa ra để phản ứng lại những câu trả lời đã nhận được, thường xuyên là câu hỏi với kết thúc mở Việc phỏng vấn là không dễ dàng o Một cuộc phỏng vấn mà không có cấu trúc sẽ không sinh ra thông tin liên quan o Người phỏng vấn phải quen thuộc với lĩnh vực ứng dụng o Người phỏng vấn phải sẵn sàng tiếp thu cái mới ở mọi lúc (The interviewer must remain open-minded at all times) Sau khi phỏng vấn, người phỏngPTIT vấn phải chuẩn bị một bài tường trình đã được viết ra o Nên đưa một bản sao của bản tường trình cho người được phỏng vấn 6.2.2.2 Các kỹ thuật khác Phỏng vấn là kỹ thuật chính Một bản thăm dò ý kiến rất hữu ích khi lấy ý kiến của hàng trăm người. Kiểm tra các định dạng nghiệp vụ mà chỉ ra cách khách hàng thực hiện những công việc nghiệp vụ (Examination of business forms shows how the client currently does business ) Quan sát trực tiếp những người công nhân thực hiện những nhiệm vụ của họ có thể là một cách rất hữu ích o Máy quay là một phiên bản hiện đại của kỹ thuật này o Nhưng, cần rất nhiều thời gian để phân tích các băng video 62
Chương 6: Pha xác định yêu cầu o Những người công nhân có thể xem máy quay vì sự xâm phạm tùy tiện đời sống riêng tư 6.2.3 Các use case Một use case mô hình tương tác giữa sản phẩm phần mềm với người dùng sản phẩm phần mềm đó (tác nhân - actors) Ví dụ: Hình 6.1: Biểu diễn một use case Một tác nhân là một thành viên của thế giới bên ngoài sản phẩm phần mềm Thường rất dễ dàng nhận dạng ra tác nhân o Một tác nhân thường là một người dùng của hệ thống sản phẩm phần mềm Nhìn chung, một tác nhân đóng vai trò đối với hệ thống sản phẩm phần mềm. Vai trò này gồm: o Là một người dùng; hoặc o Là một khởi đầu; hoặcPTIT o Là một người nào đó đóng vài trò quan trọng trong use case Một người dùng của hệ thống có thể giữ nhiều hơn một vai trò Ví dụ: Một người khách hàng (Customer) của ngân hàng có thể là o Một người vay tiền hoặc o Một người cho mượn Ngược lại, một tác nhân có thể tham gia vào nhiều use case Ví dụ: một người vay tiền (Borrower)có thể là một tác nhân trong o Use case Borrow Money ; o Use case Pay Interest on Loan 63
Chương 6: Pha xác định yêu cầu o Use case Repay Loan Principal Tác nhân người vay tiền (Borrower)có thể đại diện cho hàng nghìn khách hàng của ngân hàng Một tác nhân không cần thiết phải là một con người Ví dụ: hệ thống thông tin thương mại điện tử phải tương tác với hệ thống thông tin công ty thẻ tín dụng o Hệ thống thông tin công tin thẻ tín dụng là một tác nhân từ quan điểm của hệ thống thương mại điện tử o Hệ thống thương mại điện tử là một tác nhân của hệ thống thông tin công ty thẻ tín dụng Vấn đề dễ xảy ra khi xác định các tác nhân o Nạp chồng tác nhân Ví dụ: Hệ thống phần mềm bệnh viện o Một use case có tác nhân Y tá (Nurse) o Một use case khác có tác nhân Nhân viên Y khoa ( Medical Staff) o Tốt hơn: . Các tác nhân::PTIT Bác Sỹ và Y tá (Physician and Nurse) Về mặt giải pháp: o Tác nhân Nhân viên Y khoa (Medical Staff ) với hai sự chuyên môn hóa: Bác sỹ và Y tá (Physician and Nurse) Hình 6.2: Quan hệ giữa các tác nhân 64
Chương 6: Pha xác định yêu cầu 6.2.4 Các yêu cầu ban đầu Những yêu cầu ban đầu dựa trên mô hình nghiệp vụ đầu tiên Sau đó chúng được làm mịn Các yêu cầu là động – có sự thay đổi thường xuyên o Duy trì một danh sách những yêu cầu quan trọng, cùng với các use case của các yêu cầu đã được phê chuẩn bởi khác hàng Có hai loại yêu cầu Yêu cầu chức năng chỉ rõ hành động mà sản phẩm phần mềm phải có khả năng thực hiện o Thường được biểu diễn về mặt các đầu vào và đầu ra Các yêu phi chức năng chỉ rõ những đặc trưng của hệ thống sản phẩm phần mềm, như o Những ràng buộc về môi trường o Thời gian đáp ứng o Tính đáng tin Những yêu cầu chức năng được xử lý như là một phần của luồng công việc xác định yêu cầu và phân tích Một số yêu cầu phi chức năng phải phải chờ đến tận đến luồng công việc thiết kế o Thông tin chi tiết choPTIT những yêuc hầu phi chức năng không có sẵn cho đến tận khi luồng công việc phân tích và xác định yêu cầu hoàn thành 6.3 PHA XÁC ĐỊNH YÊU CẦU CỔ ĐIỂN Không phải thực hiện pha xác định yêu cầu cổ điển trong “xác định yêu cầu hướng đối tượng” o Luồng công việc xác định yêu cầu không phải làm gì khi sản phẩm phần mềm được xây dựng Tuy nhiên, phương pháp này được biểu diễn trong chương này là o Hướng mô hình và do đó o Hướng đối tượng Phương pháp cổ điển để xác định yêu cầu 65
Chương 6: Pha xác định yêu cầu o Làm rõ các yêu cầu o Phân tích yêu cầu o Xây dựng bản mẫu nhanh o Khách hàng và người dùng trong tương lai thử nghiệm với bản mẫu nhanh 6.4 BẢN MẪU NHANH Xây dựng nhanh (“rapid”) o Sự hoàn thiện có thể được bỏ qua Chỉ đưa ra những chức năng chính Nhấn mạnh chỉ những gì mà khách hàng xem o Kiểm tra lỗi, cập nhật tệp có thể được bỏ qua Mục đích: o Để cung cấp tới khách hàng cách hiểu của sản phẩm phần mềm Bản mẫu nhanh được xây dựng để thay đổi o Ngôn ngữ cho bản mẫu nhanh bao gồm 4GLs và ngôn ngữ đã được thông dịch 6.5 NHÂN TỐ CON NGƯỜI Khách hàng và những người dùng có ý định sử dụng hệ thống phải tương tác với giao diện người dùng PTIT Giao diện máy tính – con người (Human-computer interface HCI) o Bảng chọn, không dòng lệnh (Menu, not command line) o “Trỏ và nhấp”(“Point and click” ) o Cửa sổ, biểu tượng, bảng chọn kéo xuống (Windows, icons, pull-down menus) Nhân tố con người phải được xem xét o Tránh bảng đơn dài dòng o Cho phép mức thay đổi mức độ thành thạo của giao diện o Tính đồng đều của hình thức là quan trọng ( Uniformity of appearance is important) 66
Chương 6: Pha xác định yêu cầu o Tâm lý tiến bộ so với cảm giác chung (Advanced psychology vs. common sense?) Bản mẫu nhanh của giao diện người máy của õỗi sản phẩm phần mềm là bắt buộc 6.6 SỬ DỤNG LẠI BẢN MẪU NHANH Việc sử dụng lại bản mẫu nhanh là về bản chất là mô hình xây và sửa Những thay đổi được đưa ra để xây dựng phần mềm o Đắt (Expensive) Bảo trì khó vì không có tài liệu đặc tả và tài liệu thiết kế Những ràng buộc về thời gian thực khó đáp ứng Một cách để đảm bảo rằng bảng mẫu nhanh được bỏ qua o Cài đặt bản mẫu nhanh bằng một ngôn ngữ khác so với ngôn ngữ đã lựa chọn cho sản phẩm đích(Implement it in a different language from that of the target product) Mã được sinh ra có thể được sử dụng lại Chúng ta có thể giữ lại một cách an toàn (các phần của bản mẫu nhanh ) bản mẫu nhanh nếu o Điều này được chuẩn bị trước o Những phần của bản mẫu nhanh đã qua kiểm tra kỹ lưỡng của nhóm SQA o Tuy nhiên, đây khôngPTIT phải là một bản mẫu nhanh cổ điển ( “classical” rapid prototyping) 6.7 CÁC CÔNG CỤ CASE CHO XÁC ĐỊNH YÊU CẦU Chúng ta cần các công cụ đồ họa cho các biểu đồ UML o Dễ dàng để thay đổi các biểu đồ UML o Tài liệu được lưu trong các công cụ và luôn có sẵn Các công cụ như vậy đôi khi rất khó sử dụng The diagrams may need considerable “tweaking” Nhìn chung, điểm mạnh có nhiều ảnh hưởng tốt hơn điểm yếu (Overall, the strengths outweigh the weaknesses) Các môi trường CASE đồ họa được mở rộng để trợ giúp UML 67
Chương 6: Pha xác định yêu cầu o System Architect o Software through Pictures Các môi trường CASE hướng đối tượng bao gồm o IBM Rational Rose o Together o ArgoUML (open source) 6.8 CÁC THƯỚC ĐO CHO XÁC ĐỊNH YÊU CẦU Volatility and speed of convergence are measures of how rapidly the client’s needs are determined Số lượng thay đổi được đưa ra trong suốt chuỗi con các pha Những thay đổi được đề xướng bởi những người phát triển o Quá nhiều thay đổi có thể đồng nghĩa với việc quy trình không hoàn thiện o Nhữung thay đổi được đề xướng bởi khách hàng o Thay đổi san phẩm phần mềm cuối cùng 6.9 NHỮNG THỬ THÁCH CHO PHA XÁC ĐỊNH YÊU CẦU Nhân viên của tổ chức khách hàng thường cảm giác bị đe dọa bởi máy tính Những thành viên đội xác địnhPTIT yêu cầu phải có khả năng thương lượng o Yêu cầu của khách hàng có thể phải thu hẹp phạm vi Nhân viên chính của tổ chức khách hàng không thể có thời gian cho những cuộc thảo luận cốt yếu và sâu sắc Linh hoạt và khách quan là cốt yếu 6.10 CASE STUDY CHO PHA XÁC ĐỊNH YÊU CẦU 6.10.1 Bài toán Khách hàng đến dặt hàng chúng ta xây dựng một phần mềm quản lí khách sạn với yêu cầu như sau (đây có thể coi như là một bản mô tả yêu cầu của khách hàng bằng ngôn ngữ tự nhiên): 68
Chương 6: Pha xác định yêu cầu Phần mềm dạng ứng dụng cho máy tính cá nhân, chỉ có nhân viên lễ tân, nhân viên bán hàng, quản lí khách sạn được sử dụng Nhân viên lễ tân có thể tìm phòng trống theo yêu cầu trực tiếp của khách, checkin cho khách đã đặt phòng hoặc đặt phòng trực tiếp, checkout cho khách và in hóa đơn thanh toán cho khách Nhân viên bán hàng có thể tìm phòng trống và đặt phòng theo yêu cầu của khách. Quản lí có thể : thêm/sửa/xóa thông tin phòng, xem các báo cáo doanh thu theo thời gian/theo phòng/theo loại phòng, xem báo cáo tỉ lệ phòng trống theo thời gian/theo phòng/theo loại phòng, xem báo cáo khách hàng đặt nhiều theo thời gian/theo nguồn gốc khách hàng. Thông tin về khách sạn bao gồm : tên, địa chỉ, số sao, mô tả (bao gồm mô tả bằng text và bằng hình ảnh). Trong khách sạn có nhiều phòng, mỗi phòng được mô tả bằng các thông tin : tên phòng (duy nhất, để phân biệt các phòng), loại phòng, giá niêm yết, các loại dịch vụ đi kèm, mô tả phòng. Mỗi khách hàng, khi đến ở hoặc đặt phòng, sẽ được lưu các thông tin bao gồm số CMND (số passport nếu là người nước ngoài), loại giấy tùy thân (CMND, passport), họ tên đầy đủ, địa chỉ, số điện thoại, ghi chú về phục vụ đặc biệt như cho người khuyết tật, ăn chay Mỗi phòng có thể được đặt/ở bởi nhiều khách hàng khác nhau tại những thời điểm khác nhau. PTIT Mỗi khách hàng có thể đặt/ở nhiều phòng khác nhau tại những thời điểm khác nhau. Tại một thời điểm, chỉ có một khách ở trong một phòng, và xác định một giá phòng cụ thể. Khách hàng chỉ có thể đặt phòng nếu phòng đó còn trống trong suốt thời gian khách hàng muốn đặt. Khách hàng có thể thanh toán nhiều lần cho đến ngày trả phòng. Mỗi lần thanh toán, lễ tân sẽ in hóa đơn cho lần thanh toán đó bao gồm các thông tin : họ tên và địa chỉ khách hàng, số phòng, ngày đến, ngày đi, giá phòng, các dịch vụ đi kèm (mỗi dịch vụ bao gồm tên dịch vụ, đơn vị tính, đơn giá, tổng tiền), số tiền thanh toán. Khách hàng có thể hủy đặt phòng (miên phí) nếu hủy trước ngày đến. Nếu khách hàng hủy sau ngày đặt thì khách hàng bị lưu vào danh sách đen và có thể bị từ chối đặt phòng trong các lần tiếp theo. 69
Chương 6: Pha xác định yêu cầu 6.10.2 Xây dựng sơ đồ use case tổng quan Mục đích của bước này là xây dựng một bản mô tả yêu cầu của khách hàng bằng ngôn ngữ kỹ thuật (UML). Xác định các actor có thể có của hệ thống: Actor là người dùng trực tiếp: người quản lí khách sạn (manager), nhân viên bán hàng (saller), nhân viên lễ tân kiêm luôn thủ quỹ để nhận thanh toán (receptionist) Actor là người dùng gián tiếp: Khách hàng (client), mặc dù không trực tiếp sử dụng và thao tác trên phần mềm, nhưng một số chức năng phải có mặt khách hàng mới thực hiện được như: đặt chỗ, checkin, checkout, thanh toán. Các chức năng liên quan đến các actor: Người quản lí khách sạn (Manager): quản lí thông tin phòng và khách sạn (room manage), tạo và xem các loại báo cáo (create report) Nhân viên bán hàng (Saller): giao dịch với khách hàng (Client) qua điện thoại để đặt chỗ (Book a room) hoặc hủy đặt chỗ (Cancel a booking) Nhân viên tiếp tân (Receptionist): giao dịch trực tiếp với khách hàng (Client) tại quầy để đặt chỗ (Book a room), hủy đặt chỗ (Cancel a booking), nhận Checkin, Checkout và thanh toán cho khách hàng. Khách hàng (Client): có thểPTIT đặt phòng/hủy phòng (Book a room/Cancel a Booking) trực tiếp tại quầy với nhân viên lễ tân hoặc đặt/hủy qua điện thoại với nhân viên bán hàng. Checkin, Checkout và thanh toán tại quầy với nhân viên lễ tân. Như vậy nhóm dự án thu được sơ đồ use case tổng quan như sau: 70
Chương 6: Pha xác định yêu cầu PTIT Hình 6.3: Sơ đồ use case tổng quan của hệ thống 6.10.3 Mô tả các use case Mục đích của bước này là mô tả chi tiết các use case đã xác định được trong sơ đồ tổng quan. a. Use case Room manage Hình 6.4: Use case room manage 71
Chương 6: Pha xác định yêu cầu Mô tả: Use case này cho phép người quản lí (Manager) quản lí các thông tin về phòng khách sạn như thêm, sửa, xóa b. Use case Create report Hình 6.5: Use case tạo báo báo Mô tả: Use case này cho phép người quản lí (Manager) tạo và xem cáo báo cáo thống kê theo một khoảng thời gian nhất định (tuần, tháng) theo các tiêu chí khác nhau (doanh thu, tỉ lệ phòng trống, ) c. Use case Book a room PTIT Hình 6.6: Use case đặt phòng Mô tả: Use case này cho phép Khách hàng có thể đặt phòng. Có hai cách đặt phòng: đặt gián tiếp thông qua điện thoại với Nhân viên bán hàng (Saller, tương ứng với use case Book via phone), hoặc đặt trực tiếp tại quầy thông qua Nhân viên lễ tân (Receptionist, tương ứng với use case Book on site). Để thực hiện được use case này, phải thực hiện use case Tìm phòng trống. d. Use case Cancel a Booking 72
Chương 6: Pha xác định yêu cầu Hình 6.7: Use case hủy đặt phòng Mô tả: Use case này cho phép Khách hàng có thể hủy đặt phòng. Có hai cách hủy đặt phòng: hủy gián tiếp thông qua điện thoại với Nhân viên bán hàng (Saller, tương ứng với use case Cancel via phone), hoặc hủy trực tiếp tại quầy thông qua Nhân viên lễ tân (Receptionist, tương ứng với use case Cancel on site). e. Use case Checkin HìnhPTIT 6.8: Use case nhận phòng Mô tả: Use case này cho phép Nhân viên lễ tân (Receptionist) cập nhật trạng thái một khách hàng (Client) thành đã nhận phòng khi khách hàng đến nhận phòng. f. Use case Checkout 73
Chương 6: Pha xác định yêu cầu Hình 6.9: Use case trả phòng Mô tả: Use case này cho phép Nhân viên lễ tân (Receptionist) cập nhật trạng thái một khách hàng (Client) thành đã trả phòng khi khách hàng trả phòng. Use case này cũng đồng thời thực hiện việc thanh toán và in hóa đơn cho khách hàng. g. Use case Payment PTIT Hình 6.10: Use case thanh toán tiền phòng Mô tả: Use case này cho phép Nhân viên lễ tân (Receptionist) thực hiện thanh toán và in hóa đơn cho khách hàng, khi khách hàng có thanh toán trước hoặc khi khách hàng trả phòng. 74
Chương 7. Các phương pháp phân tích truyền thống CHƯƠNG 7: CÁC PHƯƠNG PHÁP PHÂN TÍCH TRUYỀN THỐNG 7.1 YÊU CẦU TÀI LIỆU ĐẶC TẢ Pha phân tích/đặc tả Kết quả của pha đặc tả thể hiện ở tài liệu. Tài liệu đặc tả là hợp đồng giữa khách hàng và người phát triển. Yêu cầu của tài liệu đặc tả: - Phía khách hàng: rõ ràng và dễ hiểu nên tài liệu phải có mức độ hình thức vừa đủ để khách hàngcó thể hiểu được. - Phía người phát triển: đầy đủ và chi tiết vì nó là nguồn thông tin để sử dụng trng phác thảo thiết kế. Vì vậy, tài liệu đặc tả phải phản ánh đúng yêu cầu khách hàng và là bản hợp đồng giữa khách hàng và nhóm phát triển nên không thẻ thiết sót, mâu thuẫn và nhập nhằng. Tài liệu đặc tả Tài liệu đặc tả là hợp đồng giữa khách hàng và người phát triển. Nó mô tả rõ ràng điều gì sản phẩm cần phải làm và ràng buộc đối với sản phẩm. Các ràng buộc: - Giá thành và thời gian - Chạy song song: chạy được cùng với phần mềm khách trong môi trường hiện thời - Tính khả chuyển: sảnphẩm phải chạy được trên phần cứng khác có cùng hệ điều hành hay chạy được cho nhiều hệ điều hành khác nhau. - Tính tin cậy được: ví dụ, nếu sản phẩm sử dụng để theo dõi nạn nhân thì nó phải chạy trong 24h/ngày. - Đáp ứng nhanh: 95%PTIT câu hỏi phải trả lời trong vòng 0,25 giây. Đối với hệ thời gian thực phải là 100% (thật vô ích nếu 95% trường hợp phần mềm thông báo kịp thời <0,25 giây, cho phi công rằng tên lửa đang đến). Các quy tắc chấp nhận: - Khách hàng và người phát triển cần đưa ra các trường hợp kiểm thử. - Nếu sản phẩm qua được kiểm thử và sản phẩm thực sử thỏa mãn đặc tả và nhóm đã hòan thành công việc. - Ví dụ trường hợp kiểm thử: Dựa trên ràng buộc và khách hàng cung cấp dạng dữ liệu cần xử lý. Khi nhóm phát triển hiểu đầy đủ vấn đề thì sẽ tiến hành xây dựng chiến lược giải quyết. Chiến lược giải quyết là cách tiếp cận chung khi xây dựng sản phẩm Ví dụ: Sử dụng cơ sở dữ liệu online/sử dụng các tệp truyền thông Các bước xây dựng chiến lược: 1. Tìm các chiến lược: Không quan tâm về ràng buộc trong tài liệu đặc tả 75
Chương 7: Các phương pháp phân tích truyền thống 2. Đánh giá và sửa đổi từng chiến lược: so với ràng buocọ của khách hàng (một kỹ thuật là dùng bản mẫu) 3. Xác định một hay vài chiến lược thỏa mãn ràng buộc. Lưu giữ các chiến lược loại bỏ. 4. Chọn chiến lược khả thi: Khách hàgn đưa ra quy tắc lựa chọn và nhóm phát triển đề xuất chiến lược chọn. 7.2 CÁC PHƯƠNG PHÁP ĐẶC TẢ Các phương pháp đặc tả được xếp thành 3 loại: Phi hình thức, nửa hình thức, hình thức. Đặc tả bằng ngôn ngữ tự nhiên là phi hình thức Các phương pháp nửa hình thức: - Kỹ thuật đặc tả của Gane và Sarse - Mô hình quan hệ thực thể - Kỹ thuật của Demarco, Yourdon, Các phương pháp hình thức - Máy hữu hạn trạng thái - Đặc tả Z (dựa trên logic toán, lý thuyết tập hợp) - Mạng Petri 7.2.1 Đặc tả phi hình thức Xét ví dụ trong một tài liệu đặc tả: “If sales for current month are below target sales, then report is to be printed, unless difference between target sales and actual sales is less than half of difference between target sales and actual sales in previous month, or if difference between target sales and actual sales for the current month is under 5%” Ý nghĩa của đặc tả phi hình thức:PTIT 1. Chỉ tiêu doanh thu vào thánh Một là $ 100.000, doanh thu thực sử chỉ là $ 64.000 (kém 36%). Báo cáo được in ra. 2. Chỉ tiêu doanh thu tháng Hai là $120.000, doanh thu thực sự là $100,000 (kém 16,7%). Như vậy, khác biệt % của tháng Hai nhỏ hơn nửa của khác biệt % tháng trước. Không in báo cáo và quản lý tin rằng có cải tiến. 3. Tháng ba chỉ tiêu là $100,000 nhưng doanh thu thực sự là $98,000, chỉ 2% dưới đích (<5%) nên không in báo cáo. Vấn đề là gì? Đặc tả chỉ nói sự khác biệt giữa chỉ tiêu doanh thu và doanh thu thực sự mà không nói sự khác biệt %. Phán đoán cuối cùng nói là tỷ lệ %? Tài liệu trên không rõ ràng, không thể hiện ý muốn của khách hàng. Ngôn ngữ tự nhiên không phải là phương tiện tốt để viết tài liệu đặc tả. Tuy nhiên nhiều tổ chức vẫn sử dụng ngôn ngữ tự nhiên đặc biệt đối với các sản phẩm thương mại. Lý do: 76
Chương 7: Các phương pháp phân tích truyền thống - Các chuyên gia phần mềm chưa được đào tạo cẩn thận. - Quản lý bị áp lực bởi khách hàng - Quản lý không sẵn lòng đầu tư vào đào tạo 7.2.2 Phân tích hướng cấu trúc Sử dụng biểu đồ để đặc tả phần mềm là một kỹ thuật quan trọng trong những năm 1970. Ba kỹ thuật biểu đồ quen thuộc: DeMarco (1978), Gane và Sarsen (1979) , Yourdon và Constantine (1979). Ba kỹ thuật đều tốt và tương đương như nhau. Trước đây nhiều công ty phần mềm ở Mỹ sử dụng chúng trong các sản phẩm thương mại. Các tiếp cận của Gane và Sarse hiện thời được sử dụng rộng rãi để thiết kế hướng đối tượng trong công nghiệp. Ví dụ: Cửa hàng phần mềm Beta mua phần mềm từ các nhà cung cấp khác nhau và bán cho dân chúng. Cửa hàng có phần mềm thông thường nhưng muốn có phần mềm khác thì phải yêu cầu. Cửa hàng bán lẻ ra hàng tháng 300 sản phẩm với giá trung bình $250. Mặc dù thương vụ thành công nhưng nhiều người khuyên Beta nên tin học hóa. Câu hỏi: Nên tin học hóa lĩnh vực nào? Thu/chi hay bán trên mạng? Hiểm họa tiềm tang của nhiều cách tiếp cận thông thường “trước hết đưa ra giải pháp và sau đó xem xét vấn đề nảy sinh”. Phương pháp của Gane và Sarsen được sử dụng để phân tích yêu cầu của khách hàng theo kỹ thuật 9 bước Kỹ thuật 9 bước: 1. Xây dựng DFD và mịn hóa từng bước 2. Quyết định cái gì cần tin học hóa và như thế nào 3. Xác định chi tiết dòngPTIT dữ liệu 4. Xác định logic của tiến trình 5. Xác định các kho dữ liệu //nội dung và định dạng 6. Xác định các nguồn vật lý 7. Xác định các đặc tả Input và Output 8. Xác định kích cỡ 9. Xác định yêu cầu phần cứng Bước 1: Xây dựng Sơ đồ dòng dữ liệu: Sơ đồ dòng dữ liệu DFD chỉ ra logic của dòng dữ liệu tức là điều gì xảy ra. DFD sử dụng 4 ký hiệu cơ bản như hình sau: 77
Chương 7: Các phương pháp phân tích truyền thống DFD biểu diễn bừng hình vẽ mọi khía cạnh logic của dòng dữ liệu. Hình trên là minh hóa lần thứ nhất. Điều chủ yếu là DFD biểu diễn dòng thông tin, gói hàng nào khách hàng cần không phải quan trọng. PTIT 78
Chương 8. Phương pháp phân tích hướng đối tượng CHƯƠNG 8: PHƯƠNG PHÁP PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG 8.1 LUỒNG CÔNG VIỆC PHÂN TÍCH Mục đích: có 2 mục đích chính Để hiểu sâu hơn về các yêu cầu Mô tả các yêu cầu theo một cách thức nhất định để tạo điều kiện thuận lợi cho việc thiết kế và cài đặt sau đó có khả năng bảo trì được. Ba kiểu lớp chính: Các lớp thực thể: mô hình thông tin lưu trữ lâu dài, chẳng hạn như: lớp account và lớp investment. Ký hiệu UML của lớp thực thể: Lớp thực thể Các lớp biên: mô hình những tương tác giữa hệ thống phần mềm với môi trường. Lớp biên nhìn chung gắn liền với đầu vào hoặc đầu ra hoặc giao tiếp với các tác nhân. Ví dụ: lớp Investments Report và lớp Mortgages Report. Ký hiệu UML của lớp biên: Lớp biên Các lớp điều khiển: mô hình những tính toán và những thuật toán phức tạp. Ví dụ: lớp Estimate Funds for Week. Ký hiệu UML của lớp điều khiển:PTIT Lớ p điều khiển 8.2 VIỆC TRÍCH RÚT CÁC LỚP THỰC THỂ Thực hiện theo ba bước sau một cách lặp và tăng dần: Việc mô hình hóa chức năng (hay còn gọi là mô hình hóa Use-Case): Xác định các kết quả khác nhau được đưa ra bởi hệ thống phần mềm. Biều diễn các thông tin đó dưới dạng các kịch bản của tất cả các Use-Case (mỗi kịch bản là một thể hiện của Use Case). Mô hình hóa lớp: Xác định các lớp thực thể và các thuộc tính của các lớp. Sau đó, xác định các mối quan hệ qua lại và các tương tác giữa các lớp. Biểu diễn thông tin này bằng biểu đồ lớp. 79
Chương 8: Phương pháp phân tích hướng đối tượng Mô hình hóa động: Xác định các hành động được thực hiện bởi hoặc đối với mỗi lớp thực thể hoặc các lớp con. Biểu diễn thông tin này dưới dạng các biều đồ trạng thái. Trong thực tế, ba bước trên không được thực hiện một cách tuần tự. Khi nào có một sự thay đổi ở một biểu đồ thì tương ứng sẽ có sự sửa đổi ở hai biểu đồ kia. Do đó, ba bước của phân tích hướng đối tượng được thực hiện song song một cách có hiệu quả. 8.3 PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG CHO BÀI TOÁN THANG MÁY Một hệ thống được cài đặt để điều khiển n thang máy trong một tòa nhà với m tầng. Việc di chuyển thang máy giữa các tầng phải tuân theo những ràng buộc sau: Một là, mỗi thang máy có m nút, mỗi nút tương ứng với một tầng. Các nút này sáng lên khi được bấm và khi đó thang máy sẽ di chuyển tới tầng tương ứng mới số ghi trên nút. Và khi thang máy tới tầng đó thì nút đó sẽ hết sáng và trở lại bình thường. Hai là, ngoại trừ tầng đầu tiên và tầng trên cùng, các tầng khác đều có hai nút, một nút để yêu cầu thang máy đi lên và một nút yêu cầu thang máy đi xuống. Những nút này sẽ sáng lên khi được bấm. Và nút đó trở lại bình thường khi thang máy tới tầng tương ứng, sau đó thang máy sẽ di chuyển theo hướng được yêu cầu sau đó. Ba là, nếu thang máy không nhận được yêu cầu đi lên hoặc đi xuống, thì nó vẫn ở nguyên tầng đó và đóng cửa. 8.4 MÔ HÌNH HÓA CHỨC NĂNG Một Use-Case miêu tả về những chức năng mà hệ thống phần mềm xây dựng. Một Use-Case đưa ra một miêu tả chung về chức năng toàn thể. Còn các kịch bản là những thể hiện cụ thể của các Use-Case. Các kịch bản cần được xem xét cẩn thận để có một cái nhìn toàn diện đối với hệ thống đích được xây dựng. Use-Case miêu tả tương tác giữa hệ thống và các tác nhân (những người dùng bên ngoài). Đối với bài toán thang máy, chỉ có hai Use-Case là : Ấn nút ở thang máy và Ấn nút ở mỗi tầng. Sử dụng UML để biểu diễn Use-Case cho bài toán thang máy như hình 8.1 PTIT Hình 8.1 Các use case của bài toán thang máy Những tương tác có thể giữa người dùng và các lớp đó là: một người dùng nhấn nút tháng máy và ra lệnh cho thang máy di chuyển tới một tầng nào đó hoặc một người dùng nhấn nút để yêu cầu thang máy dừng lại ở một tầng cụ thể. Với mỗi một chức năng nói chung ta có thể đưa ra 80
Chương 8: Phương pháp phân tích hướng đối tượng một số lượng lớn các kịch bản khác nhau, mỗi một kịch bản biểu diễn một tập các tương tác . Hình 8.2 mô tả kịch bản chuẩn, nó bao gồm một tập các tương tác giữa người dùng và các thang máy tương ứng với cách mà thang máy được sử dụng. Hình 8.2 được xây dựng sau khi đã quan sát tỉ mỉ những tương tác giữa người dùng với thang máy (chính xác hơn là với các nút của thang máy và các nút của các tầng). 15 sự kiện đã được đánh số miêu tả chi tiết gồm: hai tương tác giữa người dùng A và các nút của hệ thống thang máy (sự kiện 1 và sự kiện 7) và các thao tác của thang máy (sự kiện 2 đến 6 và 8 đến 15). Hai sự kiện người dùng A bước vào thang máy và người dùng A ra khỏi thang máy không được đánh số sự kiện. Những mục như vậy được xem như là những bình luận thêm, người dùng A không tương tác với các thành phần của hệ thống thang máy khi đã bước vào thang máy hoặc rời khỏi thang máy. 1. Người dùng A nhấn nút đi lên của tầng ba để yêu cầu thang máy và người dùng A muốn đi lên tầng 7. 2. Nút đi lên của tầng ba sáng lên. 3. Thang máy đến tầng 3. Trong thang máy đang có người dùng B, người dùng B đã vào thang máy từ tâng 1 và yêu cầu lên tầng 9. 4. Nút đi lên của tầng 3 trở lại trạng thái bình thường. 5. Cửa thang máy mở ra. 6. Máy bấm giờ bắt đầu. Người dùng A bước vào thang máy. 7. Người dùng A nhấn nút 7 của thang máy . 8. Nút 7 của thang máy sáng lên. 9. Cửa thang máy đóng lại sau một thời gian vượt quá thời gian quy định của máy bấm giờ. 10. Thang máy lên tới tầng 7. 11. Nút 7 của thang máy trở lại trạng thái bình thường. 12. Cửa thang máy mở và cho phép người dùng A ra khỏi thang máy. 13. Máy bấm giờ bắt đầu. Người dùng A bước ra khỏi thang máy. 14. Cửa thang máy đóng lại sau một thời gian quy định. 15. Thang máy đi tiếp tục lên tầng 9 theo yêu cầu trước đó của người B. PTIT Hình 8.2 Kịch b ản chu ẩn cho bài toán thang máy Trái lại, hình 8.3 là một kịch bản ngoại lệ. Nó miêu tả những gì xảy ra khi người dùng nhất nút đi lên ở tầng 3 nhưng thực sự muốn đi xuống tầng 1. Kịch bản này được xây dựng bởi việc quan sát các hành động của nhiều người trong thang máy. 81