Bài giảng Công nghệ phần mềm Học viện Nông nghiệp Việt Nam

MỤC LỤC MỤC LỤC DANH MỤC BẢNG BIỂU DANH MỤC HÌNH ẢNH 10 Hình 8-1 Chi phí việc phát triển phần mềm khơng có phương pháp 169THUẬT NGỮ VIẾT TẮT 12 LỜI NÓI ĐẦU 14 Chương 1: MỞ ĐẦU 15 1.1 LỊCH SỬ HÌNH THÀNH VÀ PHÁT TRIỂN 15 1.1.1 Q trình tiến hóa phần mềm 15 1.1.2 Sự đời công nghệ phần mềm 16 1.2 MỘT SỐ KHÁI NIỆM CƠ BẢN TRONG LĨNH VỰC CÔNG NGHỆ PHẦN MỀM 17 1.2.1 Khái niệm phần mềm 17 1.2.2 Khái niệm công nghệ phần mềm 18 1.2.3 Sự khác giữa công nghệ phần mềm và khoa học máy tính 18 1.2.4 Tiến trình phần mềm 18 1.2.5 Mơ hình tiến trình phần mềm 19 1.2.6 Chi phí cơng nghệ phần mềm 20 1.2.7 Phương pháp công nghệ phần mềm 20 Bảng 1.1 Các thành phần mơ hình hệ thống 20 1.2.8 CASE - Các công cụ công nghệ phần mềm 21 1.2.9 Những tḥc tính phần mềm tốt 21 Bảng 1.2 Các thuộc tính phần mềm 21 1.2.10 Những thách thức bản lĩnh vực phát triển phần mềm 22 1.3 MỘT SỐ VẤN ĐỀ VỀ ĐẠO ĐỨC CỦA CÁC CHUYÊN GIA CNTT 22 1.3.1 Những mối quan hệ cần phải quản lý chuyên gia công nghệ thông tin 23 1.3.2 Những quy tắc đạo đức chuyên gia CNTT 25 CÂU HỎI ÔN TẬP 27 Chương 2: TIẾN TRÌNH PHẦN MỀM 28 2.1 MƠ HÌNH TIẾN TRÌNH PHẦN MỀM 28 2.1.1 Mơ hình thác nước 29 2.1.2 Phát triển tiến hóa 31 2.1.3 Công nghệ phần mềm hướng thành phần 32 2.2 TIẾN TRÌNH LẶP 33 2.2.1 Mơ hình gia tăng 34 2.2.2 Mơ hình xoắn ớc 35 2.3 CÁC HOẠT ĐỘNG TRONG TIẾN TRÌNH 36 2.3.1 Đặc tả phần mềm 37 2.3.2 Thiết kế và thực thi phần mềm 38 2.3.3 Thẩm định phần mềm 40 2.3.4 Cải tiến phần mềm 42 2.4 RUP – TIẾN TRÌNH SẢN XUẤT PHẦN MỀM CỦA RATIONAL 42 2.5 KỸ NGHỆ PHẦN MỀM CÓ MÁY TÍNH TRỢ GIÚP (CASE) 44 CÂU HỎI ÔN TẬP 45 Chương 3: QUẢN LÝ DỰ ÁN PHẦN MỀM 46 3.1 CÁC KHÁI NIỆM CƠ BẢN 46 3.1.1 Khái niệm dự án 46 3.1.2 Các đặc trưng dự án 47 3.1.3 Quản lý dự án 47 3.2 QUẢN LÝ DỰ ÁN THEO PHƯƠNG PHÁP PHÁT TRIỂN TRUYỀN THỐNG 48 3.2.1 Các hoạt động quản lý dự án 48 3.2.2 Lập kế hoạch dự án 49 Bảng 3.1 Các kiểu kế hoạch cần cho dự án 50 a) Tiến trình lập kế hoạch dự án 50 b) Cấu trúc kế hoạch dự án 51 c) Các mốc quan trọng sản phẩm bàn giao 52 3.2.3 Lập lịch dự án 52 a) Tiến trình lập lịch 52 3.2.4 Phương pháp công cụ lập lịch 53 Bảng 3-2 Bảng liệt kê công việc dự án đánh dấu 54 Bảng 3.3 Bảng phân công công việc 58 3.3 QUẢN LÝ RỦI RO ĐỐI VỚI DỰ ÁN PHÁT TRIỂN PHẦN MỀM 58 3.3.1 Khái niệm rủi ro 58 Bảng 3.4 Bảng phân loại rủi ro 59 3.3.2 Tiến trình quản lý rủi ro 59 a) Xác định rủi ro 60 Bảng 3.5 Bảng đánh giá số tình rủi ro 61 Rủi ro 61 Khả xảy 61 Ảnh hưởng 61 Vấn đề tài chính của tổ chức gặp khủng hoảng và phải giảm ngân sách cho dự án 61 Thấp 61 Rất nghiêm trọng 61 Không thể thành lập một đội ngũ nhân viên có những kỹ theo yêu cầu 61 Cao 61 Rất nghiêm trọng 61 Những nhân viên quan trọng bị ốm và không thể làm việc tại những thời điểm quan trọng 61 Trung bình 61 Nghiêm trọng 61 Các thành phần phần mềm được sử dụng lại có chứa những khuyết điểm làm hạn chế khả của hệ thống 61 Trung bình 61 Nghiêm trọng 61 Việc thay đổi yêu cầu đòi hỏi phải thiết kế lại những công việc chính 61 Trung bình 61 Nghiêm trọng 61 Tổ chức được cấu trúc lại và thay đổi người quản lý dự án 61 Cao 61 Nghiêm trọng 61 Cơ sở dữ liệu sử dụng hệ thống không thể xử lý nhiều giao dịch tại cùng một thời điểm 61 Thấp 61 Khủng khiếp 61 Ước lượng: thời gian cần thiết để phát triển quá ngắn 61 Cao 61 Nghiêm trọng 61 Bảng 3.6 Các yếu tố rủi ro 62 3.4 KẾT THÚC DỰ ÁN 63 3.5 CẤU TRÚC TÀI LIỆU QUẢN LÝ DỰ ÁN 63 CÂU HỎI ÔN TẬP 64 Chương 4: XÁC ĐỊNH VÀ ĐẶC TẢ YÊU CẦU PHẦN MỀM 65 4.1 TỔNG QUAN VỀ YÊU CẦU PHẦN MỀM 65 4.1.1 Khái niệm yêu cầu phần mềm 65 4.1.2 Phân loại yêu cầu phần mềm 66 A) YÊU CẦU CHỨC NĂNG 67 B) YÊU CẦU PHI CHỨC NĂNG 68 Thuộc tính 70 Thước đo 70 Tốc độ 70 Số giao dịch được xử lý/giây 70 Thời gian trả lời một sự kiện/người dùng 70 Thời gian làm mới màn hình 70 Kích thước 70 M Bytes 70 Dung lượng bộ nhớ ROM/RAM 70 Tính dễ sử dụng 70 Thời gian huấn luyện 70 Số màn hình trợ giúp 70 Độ tin cậy 70 Thời gian trung bình kiểm soát lỗi 70 Phần trăm thời gian hệ thống không thực hiện 70 Tỷ lệ lỗi xảy 70 Tính sẵn sàng 70 Sức kháng cự 70 Thời gian để khởi động lại sau một lỗi 70 Phần trăm của các sự kiện phát sinh lỗi 70 Xác suất của việc sai lệch dữ liệu có lỗi 70 Tính khả chuyển 70 Lựa chọn ngôn ngữ cho giao diện phần mềm 70 Lựa chọn hệ thống cho việc cài đặt phần mềm 70 HÌNH 4.4 VÍ DỤ VỀ CÁC U CẦU PHI CHỨC NĂNG 71 4.2 TIẾN TRÌNH KỸ NGHỆ YÊU CẦU 72 4.2.1 Khảo sát hệ thống phân tích tính khả thi 72 4.2.2 Tiến trình phát phân tích yêu cầu 72 4.2.3 Các phương pháp phát yêu cầu 74 4.2.4 Các kỹ thuật phân tích yêu cầu 76 A) TIẾP CẬN YÊU CẦU ĐỊNH HƯỚNG CÁCH NHÌN (VIEWPOINT) 76 B) KỸ THUẬT XÁC ĐỊNH YÊU CẦU HƯỚNG CÁCH NHÌN VORD (VIEWPOINT ORIENTED REQUIREMENT DEFINITION) 77 C) KỸ THUẬT PHÂN TÍCH YÊU CẦU DỰA TRÊN MƠ HÌNH 77 D) CÁC CÁCH BIỂU DIỄN CỦA MƠ HÌNH PHÂN TÍCH 79 Bảng 4.2 Biểu diễn mơ hình nghiệp vụ theo cách tiếp cận 79 4.2.5 Ví dụ phân tích phát yêu cầu 80 A) VÍ DỤ PHÂN TÍCH HƯỚNG CẤU TRÚC 80 HÌNH 4.7 BIỂU ĐỒ NGỮ CẢNH CỦA HỆ THỐNG 80 Bảng 4.3 Danh sách hồ sơ liệu sử dụng 80 81 Bảng 4.4 Mô tả chi tiết chức rút tiền 81 4.3 ĐẶC TẢ YÊU CẦU PHẦN MỀM 82 4.3.1 Khái niệm 82 4.3.2 Các phương pháp đặc tả 83 4.3.3 Cấu trúc tài liệu đặc tả 84 Chương 5: UML – XÂY DỰNG VÀ THIẾT KẾ CÁC MƠ HÌNH HỆ THỐNG 87 5.1 GIỚI THIỆU VỀ UML 87 5.1.1 Mơ hình hóa hệ thống phần mềm 87 5.1.2 Lịch sử hình thành và phát triển 88 5.1.2 UML và giai đoạn phát triển hệ thống 89 5.2 MỘT SỐ MƠ HÌNH UML DÙNG TRONG PHÂN TÍCH VÀ THIẾT KẾ 89 5.2.1 Mơ hình ngữ cảnh 89 5.2.2 Mơ hình trường hợp sử dụng (USE-CASE) 91 Bảng 5.1 Bảng thông tin mô tả Use-case 93 5.2.3 Mơ hình lớp đới tượng 93 5.2.4 Mô hình (Sequence diagram) 98 5.2.5 Mơ hình trạng thái máy 100 Chương 6: THIẾT KẾ PHẦN MỀM 103 6.1 TỔNG QUAN VỀ THIẾT KẾ PHẦN MỀM 103 6.1.1 Giới thiệu chung 103 a Khái niệm thiết kế 103 b Vai trò thiết kế 104 c Một số khái niệm thiết kế 104 6.1.2 Thiết kế phần mềm 105 a Tiến trình thiết kế 105 b Các hoạt động sản phẩm thiết kế 106 c Biểu diễn thiết kế 107 d Các giai đoạn thiết kế 107 6.1.3 Các chiến lược và phương pháp thiết kế 108 a Thiết kế hướng chức 108 b Thiết kế hướng đối tượng 109 6.1.4 Chất lượng thiết kế và giải pháp đảm bảo chất lượng 109 a Sự kết dính 109 b Sự ghép nối 110 c Tính hiểu 111 d Sự thích nghi 112 e Một số hướng dẫn thiết kế 112 6.2.1 Khái niệm – tầm quan trọng thiết kế kiến trúc 114 a Khái niệm 114 b Vai trò tầm quan trọng kiến trúc 114 c Kiến trúc đặc điểm hệ thống 114 6.2.2 Các định thiết kế kiến trúc 115 a Tái sử dụng mẫu kiến trúc 116 b Phát triển sử dụng mơ hình kiến trúc 116 6.2.3 Tổ chức hệ thống 117 a Mơ hình kho liệu 117 b Mơ hình máy khách/chủ (client/server) 118 c Mơ hình máy ảo/phân tầng 119 6.2.4 Các mơ hình điều khiển 121 a Điều khiểu tập trung 121 b Mơ hình điều khiển dựa kiện 123 6.2.5 Tiến trình thiết kế kiến trúc 124 a Cấu trúc hệ thống 125 b Phân chia module 126 6.3 THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 128 6.3.1 Một số đặc điểm bản thiết kế hướng đối tượng 128 a Chiến lược thiết kế hướng đối tượng 128 b Đặc điểm thiết kế hướng đối tượng 128 6.3.2 Đối tượng và lớp đối tượng 129 a Khái niệm đối tượng lớp đối tượng 129 b Trao đổi thông tin lớp đối tượng 129 c Khái quát hóa kế thừa lớp đối tượng 130 6.3.3 Tiến trình thiết kế hướng đới tượng 131 a Giới thiệu hoạt động trạm thời tiết 131 b Mơ hình ngữ cảnh mơ hình sử dụng 132 Bảng 6.1 Mô tả use-case 132 c Thiết kế kiến trúc 133 d Xác định đối tượng hệ thống 134 e Xây dựng mô hình thiết kế 136 f Đặc tả giao diện đối tượng 140 6.3.4 Cải tiến và tái sử dụng bản thiết kế 141 Chương 7: KIỂM THỬ PHẦN MỀM 144 7.1 GIỚI THIỆU CHUNG 144 7.1.1 Mục tiêu kiểm thử 145 7.1.2 Tiến trình kiểm thử phần mềm 145 7.2 KIỂM THỬ HỆ THỐNG 147 7.2.1 Kiểm thử tích hợp 147 7.2.2 Kiểm thử phát hành 149 7.2.3 Xây dựng kịch bản kiểm thử hệ thống 150 7.2.4 Kiểm thử hiệu 151 7.3 KIỂM THỬ THÀNH PHẦN 152 7.3.1 Kiểm thử lớp đối tượng 152 7.3.2 Kiểm thử giao diện 153 7.4 THIẾT KẾ TRƯỜNG HỢP KIỂM THỬ (TEST CASE DESIGN) 155 7.4.1 Kiểm thử dựa yêu cầu 155 7.4.2 Kiểm thử phân vùng 156 Bảng 7.1 Các phân hoạch tương đương cho chương trình tìm kiếm 159 7.4.3 Kiểm thử cấu trúc 159 Bảng 7.2 Các trường hợp kiểm thử cho thuật tốn tìm kiếm nhị phân 161 7.4.4 Kiểm thử đường (path testing) 161 7.5 CÔNG CỤ KIỂM THỬ TỰ ĐỘNG 162 Chương 8: BẢO TRÌ PHẦN MỀM VÀ QUẢN LÝ THAY ĐỔI 166 8.1 PHÂN LOẠI HOẠT ĐỘNG BẢO TRÌ PHẦN MỀM 166 8.1.1 Bảo trì hiệu chỉnh 166 8.1.2 Bảo trì cải tiến 166 8.1.3 Bảo trì hoàn thiện 166 8.1.4 Bảo trì phòng ngừa 167 8.2 ĐẶC ĐIỂM CỦA BẢO TRÌ PHẦN MỀM 167 8.2.1 Bảo trì có cấu trúc và bảo trì khơng cấu trúc 167 8.2.2 Giá thành bảo trì 168 8.2.3 Mợt sớ khó khăn khác bảo trì 169 8.3 CƠNG VIỆC BẢO TRÌ PHẦN MỀM VÀ MỘT SỐ HIỆU ỨNG LỀ 170 8.3.1 Khả bảo trì 170 8.3.2 Các cơng việc bảo trì 171 8.3.3 Một số hiệu ứng lề cơng việc bảo trì 173 8.4 MỘT SỐ HÌNH THỨC BẢO TRÌ PHẦN MỀM 174 8.4.1 Bảo trì mã chương trình xa lạ 174 8.4.2 Công nghệ phản hồi và công nghệ tái sử dụng 175 8.4.3 Bảo trì dự phịng 175 8.4.4 Chiến lược phần mềm thành phần 176 8.5 QUẢN LÝ THAY ĐỔI PHẦN MỀM 176 8.5.1 Các thủ tục quản lý thay đổi 176 8.5.2 Ghi định theo thời gian 178 8.5.3 Quản lý thay đổi tài liệu 178 CÂU HỎI ÔN TẬP 179 DANH MỤC BẢNG BIỂU Bảng 1-1 Các thành phần mơ hình hệ thớng 15 Bảng 1-2 Các tḥc tính phần mềm 16 Bảng 3-1 Các kiểu kế hoạch cần cho dự án 44 Bảng 3-2 Bảng liệt kê công việc dự án và đánh dấu 49 Bảng 3-3 Bảng phân công công việc 53 Bảng 3-4 Bảng phân loại rủi ro 54 Bảng 3-5 Bảng đánh giá mợt sớ tình h́ng rủi ro 56 Bảng 3-6 Các yếu tố rủi ro 57 Bảng 4-1 Thước đo định lượng tḥc tính phi chức 64 Bảng 4-2 Cách mơ hình nghiệp vụ theo cách tiếp cận 74 Bảng 4-3 Danh sách hồ sơ dữ liệu sử dụng 75 Bảng 5-1 Bảng thông tin mô tả Use-case 89 Bảng 6-1 Mô tả một use-case 129 Bảng 7-1 Các phân hoạch tương đương cho chương trình tìm kiếm 157 Bảng 7-2 Các trường hợp kiểm thử cho thuật tốn tìm kiếm nhị phân Error! Bookmark not defined DANH MỤC HÌNH ẢNH Hình 1-1 Phần trăm chi phí giai đoạn tiến trình phần mềm 16 Hình 2-1 Mơ hình thác nước 25 Hình 2-2 Mơ hình phát triển phần mềm theo kiểu tiến hóa 27 Hình 2-3 Mơ hình phát triển hướng thành phần 28 Hình 2-4 Mơ hình phát triển gia tăng 30 Hình 2-5 Mơ hình xoắn ớc 32 Hình 2-6 Các giai đoạn phân tích yêu cầu 33 Hình 2-7 Các hoạt đợng tiến trình thiết kế 35 Hình 2-8 Tiến trình kiểm thử 36 Hình 2-9 Kế hoạch kiểm thử kết nối với hoạt động phát triển phần mềm 37 Hình 2-10 Tiến trình cải tiến sản phẩm phần mềm 38 Hình 2-11 Mơ hình tiến trình RUP 39 Hình 3-1 Tiến trình triển khai mợt dự án 44 Hình 3-2 Tiến trình lập kế hoạch thực dự án 47 Hình 3-3 Các cợt mớc tiến trình xác định yêu cầu 48 Hình 3-4 Tiến trình lập lịch cho hoạt đợng dự án 49 Hình 3-5 Các ký pháp sơ đồ mạng 50 Hình 3-6 Tiến trình lập lịch biểu sơ đồ mạng 50 Hình 3-7 Sơ đồ mạng cơng việc 53 Hình 3-8 Biểu đồ Gantt lịch trình dự án Error! Bookmark not defined Hình 3-9 Biểu đồ khới lịch trình công việc Error! Bookmark not defined Hình 3-10 Tiến trình quản lý rủi ro 57 Hình 4-1 Yêu cầu người dùng yêu cầu hệ thống 63 Hình 4-2 Đới tượng đọc những tài liệu đặc tả khác 63 Hình 4-3 Các kiểu yêu cầu phi chức 66 Hình 4-4 Ví dụ u cầu phi chức 68 Hình 4-5 Tiến trình phát phân tích yêu cầu Error! Bookmark not defined Hình 4-6 Tiến trình phương pháp VORD 74 Hình 4-7 Biểu đồ ngữ cảnh hệ thống 77 Hình 4-8 Mơ tả u cầu mợt chức sơ cấp 77 Hình 4-9 Ma trận thực thể - chức 78 Hình 4-10 Biểu đồ trường hợp sử dụng mức cao 78 Hình 4-11 Biểu đồ trường hợp sử dụng mức cao 78 10 c = đánh giá mức đợ phức tạp được tính cho việc thiếu thiết kế cấu trúc và dữ liệu; d = đánh giá mức độ hiểu biết phần mềm Mơ hình cho thấy cơng việc giá thành tăng lên theo cấp sớ mũ một phương pháp phát triển phần mềm cỏi được sử dụng (tức là thiếu sót cơng nghệ phần mềm), hoặc mợt người hay mợt nhóm dùng phương pháp khơng có giá trị để bảo trì phần mềm Chi phí cho bảo trì phần mềm được phát triển không phương pháp được minh hoạ hình 8.1: Bảo trì Kiểm thử Cài đặt Hình 8.1 Chi phí việc phát triển phần mềm khơng có phương pháp 8.2.3 Mợt số khó khăn khác bảo trì Hầu hết vấn đề liên quan tới bảo trì phần mềm liên quan tới sai lệch cách xây dựng phát triển phần mềm Sự thiếu sót việc điều khiển tổ chức hai giai đoạn mợt chu trình phần mềm gần luôn tạo vấn đề giai đoạn ći Nhiều vấn đề kinh điển liên quan tới việc bảo trì phần mềm được trình bày đây: - Rất khó hoặc khơng thể theo dõi tiến hóa phần mềm qua phiên bản - Các thay đổi không được tư liệu hóa - Khó theo dõi được q trình xử lý được tạo phần mềm viết - Thường xun gặp nhiều khó khăn việc tìm hiểu chương trình người khác Những khó khăn tăng lên sớ thành phần cấu hình phần mềm giảm Nếu có chương trình nguồn khơng có tài liệu hướng dẫn khơng nên tìm hiểu phần mềm Những người viết phần mềm thường khơng có mặt để giải thích Chúng ta khơng thể trơng cậy vào những giải thích cá nhân nhà phát triển phần mềm việc bảo trì được u cầu Các tài liệu xác khơng có hay thiếu trầm trọng Phải thừa nhận phải có tài liệu phần mềm bước đầu tiên, tài liệu phải hiểu được phù hợp với chương trình lại chuyện khác Phần lớn phần mềm không thiết kế để thay đổi, trừ sử dụng phương pháp thiết kế dùng khái niệm phân tách chương trình thành module đợc lập Việc thay đổi phần mềm sẽ khó khăn dẫn đến xu hướng sai 169 Việc bảo trì phần mềm khơng được coi một công việc dễ dàng mà công việc bảo trì phần mềm ln liên quan tới sai lệch mức đợ cao 8.3 CƠNG VIỆC BẢO TRÌ PHẦN MỀM VÀ MỘT SỐ HIỆU ỨNG LỀ 8.3.1 Khả bảo trì Khả bảo trì phần mềm coi khả hiểu, hiệu chỉnh, tiếp hợp hoặc thêm vào khả phát triển Khả bảo trì chìa khóa để dẫn đến phương pháp thiết kế xây dựng phần mềm a) Yếu tố kiểm sốt Khả bảo trì bản bao gồm nhiều yếu tố Sự thiếu cẩn trọng việc thiết kế, viết chương trình nguồn, kiểm tra có ảnh hưởng tiêu cực đến việc bảo trì có kết quả mợt phần mềm Cấu hình yếu có tác đợng tương tự, chí cả bước kỹ thuật xây dựng phần mềm được xem xét mợt cách cẩn thận Thêm vào nhiều yếu tố khác liên quan tới phương pháp phát triển phần mềm, như: - Chất lượng hiệu quả đội ngũ phát triển phần mềm - Cấu trúc hệ thớng dễ hiểu - Dễ dàng kiểm sốt hệ thớng - Dùng ngơn ngữ lập trình ch̉n - Dùng hệ điều hành chuẩn - Dùng cấu trúc chuẩn tài liệu - Dùng được tài liệu kiểm tra - Phương tiện gỡ rối kèm - Dùng được máy tính tớt để thực việc bảo trì Các yếu tớ được đưa phản ánh những đặc điểm phần cứng chương trình nguồn được dùng việc phát triển phần mềm Những yếu tố khác cần thiết để có được phương pháp ch̉n, chương trình nguồn ch̉n Có thể, yếu tớ quan trọng tác đợng tới khả bảo trì kế hoạch cho khả bảo trì Nếu coi phần mềm là mợt hệ thống thành phần sẽ phải chịu những thay đổi khơng tránh được, hợi tạo những phần mềm có khả bảo trì sẽ tăng thực b) Đánh giá định lượng Khả bảo trì, chất lượng hay đợ tin cậy là hết sức khó xác định Tuy nhiên đánh giá khả bảo trì gián tiếp việc xem xét tḥc tính cơng việc bảo trì đánh giá được là: - Thời gian nhận biết vấn đề - Thời gian trễ công việc hành - Thời gian lựa chọn cơng cụ bảo trì - Thời gian phân tích vấn đề 170 - Thời gian xác định thay đổi - Thời gian hiệu chỉnh (hay sửa đổi) thực - Thời gian chạy thử cục bộ - Thời gian chạy thử tổng thể - Thời gian tổng kết bảo trì - Tổng thời gian cơng việc bảo trì Mỗi đánh giá thực tế dữ liệu cung cấp cho người quản lý cùng với số hiệu quả công việc 8.3.2 Các công việc bảo trì Những nhiệm vụ liên quan tới việc bảo trì gồm: tổ chức bảo trì được thiết lập; thủ tục ghi nhận đánh giá được miêu tả một loạt thứ tự chuẩn bước cho yêu cầu bảo trì phải được định nghĩa Thêm vào đó, mợt thủ tục lưu trữ hồ sơ cho hoạt đợng bảo trì được thiết lập và bản tổng kết những tiêu chuẩn đánh giá được vạch rõ a) Cơ cấu bảo trì Mặc dù những tổ chức bảo trì ch̉n khơng cần được thiết lập, ủy thác trách nhiệm cần thiết kể cả với tổ chức phát triển phần mềm nhỏ Những yêu cầu bảo trì được chuyển qua cho người kiểm sốt cơng việc bảo trì từ chuyển tiếp yêu cầu tới người quản lý hệ thống để đánh giá, người quản lý hệ thống thành viên nhóm nhân viên kỹ thuật Những nhân viên này có trách nhiệm mợt phần nhỏ chương trình sản phẩm Khi một yêu cầu được đánh giá, người được ủy quyền quản lý việc thay đổi phải định hành động được thực Cơ cấu được miêu tả phục vụ cho việc thiết lập phạm vi trách nhiệm đối với công việc bảo trì Người kiểm sốt người ủy quyền quản lý việc thay đổi là mợt người mợt nhóm quản lý và chun gia kỹ thuật cao cấp b) Báo cáo Tất cả yêu cầu việc bảo trì phần mềm cần được trình bày theo một chuẩn Người phát triển phần mềm thường cung cấp mợt đơn u cầu bảo trì cịn được gọi báo cáo lỗi phần mềm Báo cáo được người sử dụng điền vào yêu cầu công việc bảo trì Nếu xuất mợt lỗi, bản mơ tả đầy đủ tình h́ng dẫn đến lỗi bao gồm dữ liệu, đoạn chương trình yêu cầu khác phải được điền đầy đủ vào bản báo cáo Nếu yêu cầu bảo trì bảo trì cải tiến hay bảo trì hồn thiện mợt u cầu chi tiết sẽ được thảo Đơn yêu cầu bảo trì sẽ được người kiểm sốt bảo trì và người quản lý hệ thống xem xét phần trước nêu Đơn u cầu bảo trì được thiết lập từ bên ngồi được coi sở để đề kế hoạch cơng việc bảo trì Ngoài ra, nợi bộ quan phần mềm một báo cáo thay đổi phần mềm được tạo Báo cáo cơng sức địi hỏi để thỏa mãn mợt đơn yêu cầu bảo trì, trạng thái ban đầu yêu cầu sửa đổi, mức ưu tiên yêu cầu, dữ liệu cần cho việc sửa đổi c) Lưu giữ hồ sơ 171 Thường đầy đủ hồ sơ cho tất cả giai đoạn chu kỳ sống một phần mềm Thêm nữa khơng có hồ sơ việc bảo trì phần mềm Do đó, thường khó tiến hành cơng việc bảo trì có hiệu quả, khơng có khả xác định tính chất chương trình khó xác định được giá bảo trì phần mềm Các thơng tin cần phải lưu giữ hồ sơ bảo trì thường là: - Dấu hiệu nhận biết chương trình - Sớ lượng câu lệnh chương trình nguồn - Sớ lượng lệnh mã máy - Ngơn ngữ lập trình được sử dụng - Ngày cài đặt chương trình - Sớ chương trình chạy từ cài đặt - Số lỗi xử lý xảy - Mức và dấu hiệu thay đổi chương trình - Sớ câu lệnh được thêm vào chương trình nguồn chương trình thay đổi - Sớ câu lệnh được xóa khỏi chương trình nguồn chương trình thay đổi - Sớ người sử dụng cho lần sửa đổi - Ngày thay đổi chương trình - Dấu hiệu kỹ sư phần mềm - Dấu hiệu đơn yêu cầu bảo trì - Kiểu bảo trì - Ngày bắt đầu và kết thúc bảo trì - Tổng sớ người dùng cho việc bảo trì d) Xác định giá bảo trì Việc xác định giá trị bảo trì thường phức tạp thiếu thông tin Nếu tiến hành việc lưu giữ hồ sơ tiến hành mợt sớ cách đánh giá việc thực bảo trì Theo chuyên gia đánh giá việc thực bảo trì dựa vào: - Sớ lượng trung bình lỗi xử lý cho mợt lần chạy chương trình - Tổng số người dùng cho loại bảo trì bảo trì - Sớ lượng trung bình thay đổi theo chương trình, theo ngơn ngữ lập trình, theo kiểu - Sớ trung bình người cho mợt dịng lệnh được thêm vào xóa - Sớ trung bình người cho mợt ngơn ngữ lập trình - Thời gian trung bình cho việc bảo trì mợt đơn u cầu bảo trì - Tỷ lệ phần trăm kiểu bảo trì 172 8.3.3 Mợt số hiệu ứng lề cơng việc bảo trì Sửa đổi phần mềm công việc nguy hiểm, ta thường gặp ba loại hiệu ứng lề sau: a) Hiệu ứng lề việc thay đổi mã nguồn Một thay đổi đơn giản tới một câu lệnh đơn đem lại mợt hậu quả thảm khốc Mặc dù không phải ảnh hưởng tiêu cực, việc sửa lỗi dẫn đến vấn đề phức tạp Mặc dù tất cả thay đổi mã lệnh chương trình tạo lỗi, tập hợp thay đổi sau gây nhiều lỗi - Mợt chương trình bị xóa hay thay đổi - Mợt dịng nhãn bị xóa hay thay đổi - Mợt biến bị xóa hay thay đổi - Các thay đổi để tăng khả thực - Việc mở và đóng file bị thay đổi - Các phép toán logic bị thay đổi - Việc thay đổi thiết kế chuyển thành thay đổi lớn chương trình - Các thay đổi ảnh hưởng đến việc chạy thử trường hợp biên b) Hiệu ứng lề việc thay đổi liệu Trong trình bảo trì, việc sửa đổi thường được tiến hành đối với phần tử riêng rẽ cấu trúc dữ liệu Khi dữ liệu thay đổi, việc thiết kế phần mềm sẽ khơng cịn phù hợp với dữ liệu và lỗi có khả xảy Hiệu ứng lề dữ liệu xảy là kết quả việc thay đổi cấu trúc dữ liệu Các thay đổi dữ liệu sau thường gây lỗi: - Định nghĩa lại số cục bộ và số địa phương - Định nghĩa lại cấu trúc bản ghi hay cấu trúc file - Tăng hoặc giảm kích thước một mảng - Thay đổi dữ liệu tổng thể - Định nghĩa lại cờ điều khiển trỏ - Xếp lại tham số vào hay tham sớ chương trình Hiệu ứng lề dữ liệu được hạn chế tài liệu thiết kế mô tả cấu trúc dữ liệu cung cấp một lời dẫn tham khảo đến phần từ dữ liệu, bản ghi, file cấu trúc khác module phần mềm c) Hiệu ứng lề việc thay đổi tài liệu Việc bảo trì thường tập trung vào cấu hình phần mềm khơng tập trung riêng vào việc sửa đổi mã Sự ảnh hưởng tài liệu xảy thay đổi chương trình nguồn mà khơng thay đổi tài liệu thiết kế và tài liệu hướng dẫn sử dụng Bất cứ lúc nào có thay đổi luồng dữ liệu, cấu trúc phần mềm, thủ tục hay bất cứ có liên quan, tài liệu kỹ thuật phải được cập nhật 173 Tài liệu thiết kế phản ánh không trạng thái phần mềm có lẽ cịn tồi tệ khơng có tài liệu Hiệu ứng lề xảy lần bảo trì sau đó, việc nghiên cứu không kỹ tài liệu kỹ thuật, dẫn tới đánh giá sai đặc tính phần mềm Đới với người sử dụng, phần mềm tớt có tài liệu hướng dẫn sử dụng chúng Các hiệu ứng lề tài liệu được giảm bản toàn bợ cấu hình được xem xét trước phát hành phiên bản phần mềm tiếp sau Thực tế một vài yêu cầu bảo hành địi hỏi khơng được thay đổi thiết kế phần mềm hoặc mã chương trình, mà cần thiếu rõ ràng tài liệu người sử dụng Trong những trường hợp nỗ lực bảo trì tập trung vào tài liệu 8.4 MỘT SỐ HÌNH THỨC BẢO TRÌ PHẦN MỀM 8.4.1 Bảo trì mã chương trình xa lạ Các chương trình được gọi mã chương trình xa lạ nếu: nữa - Khơng mợt thành viên phịng kỹ thuật tiếp tục phát triển chương trình - Khơng tiếp tục áp dụng lý thuyết phát triển, tồn vấn đề thiết kế nghèo nàn tài liệu (theo tiêu chuẩn ngày nay) - Cấu trúc khối chưa được thiết kế theo tiêu chuẩn, khái niệm thiết kế có cấu trúc chưa được áp dụng Dưới một số đề nghị hữu dụng cho người quản trị hệ thớng phải bảo trì chương trình xa lạ: - Nghiên cứu chương trình trước bạn bị đặt vào "chế độ khẩn cấp" Cố gắng thu nhận được nhiều thông tin sở càng tớt - Cớ gắng làm quen với tồn bợ luồng điều khiển chương trình; trước hết bỏ qua chi tiết mã chương trình Sẽ có ích vẽ riêng sơ đồ cấu trúc sơ đồ luồng hoạt đợng mức cao, chưa có bản nào tồn - Đánh giá tình hình hợp lý tài liệu có; bổ sung thêm lời thích bản thân bạn vào chương trình nguồn bạn thấy cần thiết - Sử dụng tốt danh sách dẫn tham khảo, bảng ký hiệu trợ giúp khác thường được chương trình dịch cung cấp - Thực sửa đổi chương trình với ý lớn Lưu ý tới kiểu dạng chương trình tất cả chỗ Đánh dấu chương trình những lệnh bạn sửa - Đừng loại bỏ chương trình trừ bạn chắc chắn khơng được sử dụng nữa - Đừng cố sử dụng chung biến tạm thời vùng nhớ làm việc mà có sẵn chương trình Thêm biến riêng bạn để tránh rắc rối - Giữ bản ghi chép chi tiết (về hoạt đợng bảo trì và kết quả) - Tránh nóng vợi vơ ý ném chương trình cũ và viết lại - Thực kiểm tra lỗi 174 8.4.2 Công nghệ phản hồi công nghệ tái sử dụng Công nghệ phản hồi -Reverse engineering- đối với phần mềm đơn giản Trong nhiều trường hợp, chương trình được tổ chức ngược khơng phải tḥc nhà cạnh tranh mà tḥc bản thân cơng ty Bí mật cần khám phá khơng cịn giữ được đặc tả Do đó, tổ chức ngược đới với phần mềm q trình phân tích chương trình cớ gắng biểu diễn lại chương trình mức độ trừu tượng cao mã nguồn Tổ chức lại là q trình khám phá thiết kế Các cơng cụ công nghệ phản hồi lấy dữ liệu, kiến trúc, thông tin thiết kế thủ tục từ chương trình tồn Cơng nghệ tái sử dụng, Re-engineering, không đơn phát thông tin thiết kế mà cịn dùng thơng tin để biến đổi hoặc tổ chức lại hệ thống tồn với mục đích cải thiện chất lượng Trong nhiều trường hợp, phần mềm ứng dụng lại chức hệ thống tồn Nhưng thời điểm, nhà phát triển phần mềm phải thêm chức và/hoặc cải thiện xử lý 8.4.3 Bảo trì dự phịng Bảo trì dự phịng phần mềm máy tính mợt vấn đề cịn được tranh cãi Thay đợi nhận được yêu cầu bảo trì, tổ chức phát triển hay bảo trì chọn mợt chương trình mà: - Sẽ được sử dụng một số năm định trước; - Hiện được sử dụng tốt; - Dễ bị thay đổi hoặc nâng cấp tương lai gần Thoạt đầu ý kiến đề nghị phát triển lại mợt chương trình lớn một phiên bản làm việc tồn ta thấy dường lãng phí Nhưng xem xét điểm sau: - Chi phí để bảo trì mợt dịng mã lệnh lớn 20 tới 40 lần chi phí cho phát triển ban đầu dịng lệnh - Thiết kế lại cấu trúc phần mềm, với sử dụng khái niệm thiết kế làm cho việc bảo hành tương lai dễ dàng - Bởi khn mẫu phần mềm tồn tại, suất phát triển chương trình chắc sẽ cao mức trung bình nhiều - Người sử dụng làm quen với phần mềm Vì vậy, địi hỏi và hướng thay đổi tìm dễ dàng nhiều - Các công cụ CASE dành cho reverse engineering re-engineering sẽ thực tự động một số phần cơng việc - Mợt cấu hình phần mềm sẽ tồn hồn thành bảo trì phịng ngừa Khi một tổ chức phát triển phần mềm bán phần mềm là mợt sản phẩm, bảo trì phịng ngừa được xem "phiên bản mới" chương trình Nhiều hãng phát triển phần mềm lớn có từ 500 tới 2000 sản phẩm chương trình phạm vi trách nhiệm Các chương trình được xếp theo thứ tự ưu tiên xem xét lại ứng cử cho bảo trì phịng ngừa 175 8.4.4 Chiến lược phần mềm thành phần Như đặc tính cổ điển bảo hành phần cứng tháo bỏ phần hỏng và thay phụ tùng Một khái niệm được gọi là nguyên mẫu phần mềm dẫn tới việc phát triển phụ tùng cho chương trình Nguyên mẫu phần mềm là mợt q trình mơ hình hóa u cầu người dùng một hay nhiều mức chi tiết, bao gồm cả mơ hình làm việc Các tài ngun dự án được xếp đặt để sản xuất phiên bản phần mềm được mô tả theo yêu cầu phải nhỏ Phiên bản nguyên mẫu làm cho người dùng, người thiết kế quản trị xem lại được phần mềm Q trình sẽ tiếp tục được đề nghị, với phiên bản chạy chuẩn bị sẵn sàng phát hành sau vài lần làm lại Nếu mức nguyên mẫu khác được phát triển, có mợt bợ phụ tùng phần mềm được sử dụng nhận được u cầu bảo trì hiệu chỉnh Ví dụ mợt module phân tích được thiết kế thực theo hai cách khác có giao diện bên ngồi Mợt phiên bản module có được sử dụng phần mềm làm việc Nếu module hỏng, mợt phụ tùng được thay Mặc dù chiến lược phụ tùng thay cho phần mềm có vẻ khác thường mợt chút, khơng có chứng tỏ tớn kém, tính đến chi phí cho tất cả chu kỳ sớng phần mềm 8.5 QUẢN LÝ THAY ĐỔI PHẦN MỀM Các ứng dụng thường xuyên phải thiết kế lại phân cơng mợt nhóm quản lý mới, dự án vượt ngân sách, ứng dụng chậm có nhiều lỗi, thiếu tin tưởng chủ sử dụng việc kỹ sư phần mềm hiểu rõ yêu cầu Các thay đổi yêu cầu, thiết kế, chương trình, giao diện, phần cứng hoặc phần mềm phải mua Phần lớn thay đổi bắt nguồn từ bên tổ chức phát triển ứng dụng, được kích hoạt từ tác nhân bên ngồi, ví dụ thay đổi luật Việc quản lý thay đổi ứng dụng giúp cho nhóm triển khai bỏ qua những ý thích chợt nảy người sử dụng cho phép thực yêu cầu hợp lý 8.5.1 Các thủ tục quản lý thay đổi Quản lý điều khiển thay đổi có hiệu lực từ sản phẩm được chấp nhận hoàn thiện dự án kết thúc Trước tiên, sản phẩm công việc sở được tạo lập để đưa vào quản lý Một sản phẩm công việc sở một sản phẩm được coi là hoàn thiện và sở cho cơng việc khác nhóm triển khai dự án Ví dụ như, mợt tài liệu sở bản quy định yêu cầu chức sau được chấp nhận người sử dụng Dưới ví dụ mợt q trình thao tác yêu cầu thay đổi một đặc tả chức năng: - Tạo yêu cầu mở; - Khai báo file tác động; - Phê chuẩn file thời gian chi phí người quản lý, người sử dụng ký; - Hoàn thiện danh sách và kiểm soát thay đổi người điều hành dự án File tài liệu liên quan đến thay đổi Nếu tài liệu hoặc chương trình bị thay đổi, xác định ngày 176 mục cập nhật hoàn thiện Nếu thủ tục hoặc thử nghiệm bị thay đổi, xác định ngày mà việc sửa đổi xảy Mẫu yêu cầu đóng file được chủ/người sử dụng thơng qua - Tóm tắt ngày tháng, q trình chi phí Trước tiên, tài liệu sở được giữ nguyên, sau thêm vào yêu cầu thay đổi Khi quy định chức được cập nhật để điều tiết thay đổi, được đóng băng lại cơng việc lại tiếp tục Ba yêu cầu trước được thêm vào ứng dụng chúng không làm thay đổi ứng dụng nhiều Chúng bị bỏ qua sau ứng dụng được thực Các thay đổi phân loại theo mợt sớ cách: - Thứ nhất, chúng được phân theo kiểu loại bỏ lỗi, cải tiến thực hoặc thay đổi chức năng; - Thứ hai, thay đổi phân loại thành yêu cầu và lựa chọn; - Thứ ba, phân theo độ ưu tiên khẩn cấp, lệnh với một ngày kết thúc yêu cầu, lệnh với ngày bắt đầu yêu cầu hoặc ưu tiên thấp Thông thường, kiểu loại bỏ lỗi khẩn cấp theo yêu cầu, thay đổi chức bảo dưỡng lệnh theo yêu cầu cải tiến thực lựa chọn khơng có ưu tiên Việc biết được loại u cầu thay đổi định xem liệu có cần phải chịu điều khiển thay đổi hay không Các thay đổi khẩn cấp thường phá vỡ thủ tục điều khiển thay đổi công việc thực chúng lại được tài liệu hoá sau thay đổi kết thúc Tất cả loại thay đổi khác phải tuân theo điều khiển thay đổi Ví dụ thay đổi yêu cầu chức xảy bất cứ lúc nào, quy định u cầu chức được thơng qua đóng băng ứng dụng hoạt đợng Các thay đổi phải chịu điều khiển thay đổi: chúng được thêm vào danh sách yêu cầu thay đổi để xem xét tương lai trừ là mợt thiết kế khẩn cấp Một thủ tục điều khiển thay đổi u cầu người sử dụng phải đệ trình mợt lời yêu cầu thay đổi thức cho người điều hành dự án: đổi - Người sử dụng gửi cho người điều hành dự án người chủ một mẫu yêu cầu thay - Người điều hành dự án kỹ sư phần mềm triển khai một khai báo tự đợng Vào lúc đó, danh sách kiểm sốt người điều hành dự án được dùng để xác định tất cả hoạt đợng thay đổi cơng việc có liên quan tới yêu cầu Yêu cầu thay đổi được thảo luận với chủ sử dụng để vạch thay đổi ưu tiên, tiến trình và chi phí - Thoả thuận được thức hố chủ sử dụng thơng qua thay đổi tiến trình chi phí - Sử dụng khai báo tác đợng, ứng dụng và tất cả tài liệu có liên quan được thay đổi Thực thay đổi: nhiệm vụ hồn thành, xố nhiệm vụ danh sách kiểm sốt người điều hành dự án - Chủ sử dụng thơng qua việc đóng u cầu và u cầu được đóng Người điều hành dự án kỹ sư phần mềm định nghĩa tác đợng tiến trình chi phí thay đổi Sau đó, thay đổi được bàn bạc với người sử dụng Dựa thương lượng với người sử dụng, thay đổi được gán một ưu tiên hoạt đợng, chi phí tiến trình được thay đổi 177 - Yêu cầu, ngày dự định hoạt động, thay đổi tiến trình tăng chi phí được thêm vào mợt file q trình dự án Các thay đổi được quản lý mợt nhân viên điều khiển thay đổi, mợt người có nhiệm vụ bảo dưỡng trình dự án bản ghi điều khiển thay đổi, hàng tháng in một bản báo cáo điều khiển thay đổi Một tệp điều khiển thay đổi chứa tất cả yêu cầu, thư từ tài liệu thay đổi Một yêu cầu thay đổi mở được tạo yêu cầu được đưa và một số lượng thay đổi được gán Yêu cầu thay đổi mở nằm tệp yêu cầu được hoàn thành, đóng và được báo cáo Khi thay đổi được thực hiện, mục có ảnh hưởng được cập nhật, bao gồm tư liệu tương ứng, mã nguồn chương trình, Mợt danh sách kiểm soát người điều hành dự án được dùng để loại bỏ hoạt động được yêu cầu Tài liệu được nhân viên điều khiển thay đổi sắp xếp phân phới cho những người có quan tâm Ngày hoàn thành thay đổi được đưa vào file điều khiển thay đổi Thay đổi được xác định được đóng báo cáo tình trạng tới và yêu cầu mở được chuyển từ file điều khiển thay đổi sang Dựa tổ chức này, người điều hành hệ thớng theo dõi u cầu thay đổi dự án để nhận biết thành công nhóm u cầu Chi phí thay đổi chung một năm thường được sử dụng một tiêu để xem ứng dụng có triển vọng hay cần vứt bỏ hay cần công nghệ hố lại Trong những trường hợp này, cả chi phí số lượng yêu cầu thay đổi được theo dõi thơng qua q trình điều khiển thay đổi Các báo cáo tổng kết dự án thay đổi một thời kỳ định, hoặc so sánh theo thời kỳ được triển khai 8.5.2 Ghi định theo thời gian Khi bắt đầu một dự án, người điều hành dự án kỹ sư phần mềm định sử dụng công cụ để lưu trữ q trình định Có nghĩa dùng công cụ điện tử hoặc một phiên bản viết tay định được trì dạng văn bản Với công cụ điện tử, bản điện tử được lưu trữ Với công cụ ghi tay, phiên bản cũ được cập nhật đổi tên một tài liệu thay đổi Ví dụ như, quy định chức cơng ty ABC được đặt tên ABCFS-mmddyy, ABC cơng ty, FS viết tắt quy định chức (Functional Specification) mmddyy ngày tháng năm Phần ngày tháng tên sẽ thay đổi một thay đổi quan trọng nào tài liệu Thủ tục quản lý thay đổi sẽ được nói đến phần 8.5.3 Quản lý thay đổi tài liệu Các thay đổi tài liệu được xác định mợt bảng nội dung thay đổi đầu tài liệu Bảng nội dung thay đổi bao gồm ngày hiệu lực, phần bị ảnh hưởng tài liệu mợt tóm tắt thay đổi Mục đích bảng nợi dung thay đổi là để tóm tắt tất cả thay đổi cho người đọc Các thay đổi nên được đánh dấu đỏ văn bản để xác định được bộ phận thay đổi Nếu nội dung cũ quan trọng được đưa vào ý, được ghi ngày tháng được dán nhãn phiên bản trước Cần nhớ bạn phải giữ tài liệu phiên bản cũ để dùng cho q trình phát triển 178 CÂU HỎI ƠN TẬP Có loại hoạt đợng bảo trì? Khi thực bảo trì phần mềm, những yếu tớ nào được đánh giá là quan trọng? Việc bảo trì phần mềm gây những hiệu ứng gì? Hãy nêu hình thức bảo trì Hãy nêu những thủ tục bản quản lý thay đổi Yếu tố nào là quan trọng quản lý thay đổi? 179 BÀI TẬP HỆ THỐNG CHO THUÊ ĐĨA TỰ ĐỘNG AL2010 Một công ty cho thuê đĩa DVD muốn mở rộng mạng lưới kinh doanh nhiều điểm khác cách lắp đặt hệ thống máy cho th tự đợng có tên AL2010 Các hệ thớng này sẽ được lắp đặt những trung tâm thương mại nhỏ, trung tâm vui chơi giải trí Các hệ thớng máy này phải đợc lập, truy cập 24/24h và dễ sử dụng Công ty can thiệp vào hệ thống máy những trường hợp đặc biệt Còn để xác nhận xem hệ thống máy hoạt động tốt hay không và một vài hoạt đợng bảo trì thường xun khác được thực từ xa thơng qua mợt đường tín hiệu riêng Khơng có mới liên hệ giữa hệ thớng máy khác được lắp đặt địa điểm khác AL2010 lưu trữ được tối đa 100 đĩa DVD Việc lựa chọn đĩa DVD để đưa vào hệ thớng máy tính nhân viên chi nhánh thực hiện, thông qua một danh sách phim mà cơng ty có Danh sách này lên tới hàng nghìn bản ghi và cơng ty đưa một danh sách phim phát hành tháng Việc nhận và trả đĩa nhân viên chi nhánh được thực qua bưu điện, những đơn đặt hàng đặc biệt được thực qua bưu điện Hình thức giao diện của các hệ thống máy tự động Về mặt vật lý, hệ thống máy này gần giống hệ thống ATM, nhân viên công ty mở được máy để sửa chữa Ở đằng sau máy, có đường giây, mợt đường điện và mợt đường tín hiệu Người sử dụng tiếp xúc với mặt trước máy: (1) màn hình cảm ứng; (2) cửa sổ đĩa DVD; (3) cửa đưa thẻ vào Màn hình đới diện với người sử dụng Đầu đĩa DVD nằm bên màn hình, chỗ đưa thẻ vào nằm bên tay phải màn hình AL2010 đưa những phiên bản mới, phần mềm phải có khả đáp ứng yêu cầu này với chi phí thấp Hệ thớng máy tự động được cung cấp một công ty khác, có tích hợp mợt thẻ có khả xử lý CPU và có cả chức lưu trữ dữ liệu giớng mợt máy tính Cơng ty có nhu cầu xây dựng một hệ thống phần mềm nhúng AL2010 để thực được tất cả chức cho thuê đĩa DVD và cho phép bảo trì hệ thớng (chủ yếu là bảo trì từ xa) Các hoạt đợng bảo trì khơng liên quan đến dự án Tuy nhiên, thẻ khách hàng lại được cung cấp một tổ chức khác Trong thẻ có mợt thẻ nhớ để lưu số thẻ, thông tin khách hàng và số tiền cịn lại thẻ Giao diện khách hàng Màn hình cảm ứng cho phép người sử dụng: - Xem danh sách phim có máy, với phim có tóm tắt, poster, đạo diễn và diễn viên phim - Xem danh sách phim mà cơng ty sở hữu và đặt trước muốn (chức này cung cấp cho những người có thẻ khách hàng) - Xem danh sách phim được nhiều người mượn tuần và năm 180 - Mượn một hoặc nhiều phim - Yêu cầu một hoặc nhiều phim - Nạp tiền vào thẻ - Truy cập vào thông tin khác tài khoản khách hàng Ngay người sử dụng đưa thẻ khách hàng vào, tên, sớ tài khoản và tình trạng thẻ phải được hiển thị Giao diện phải được khách hàng giao tiếp với máy giai đoạn nào (ví dụ lựa chọn phim hay tiến hành bước để mượn DVD) và cho phép quay trở lại bước trước Danh sách phim mà công ty sở hữu là lớn, khách hàng tìm kiếm theo thứ tự ABC, theo loại phim, theo tên đạo diễn, tên diễn viên Khách hàng có thẻ hệ thớng u cầu một bộ phim nằm danh sách phim mà công ty sở hữu (danh sách này được cài đặt AL2010) Cơng ty cập nhật danh sách phim, công việc này được thực từ xa, một tháng một lần vào ban đêm ngắt Một giao dịch được thực không 10 phút Nếu thời gian này, hệ thống sẽ tự Giao diện của người quản trị máy Người quản trị máy AL2010 truy nhập vào một giao diện riêng họ việc nhập vào mật mã, giao diện này cho phép: - Rút hoặc nhiều đĩa từ máy - Bỏ vào máy một hoặc nhiều đĩa - Thu được những thơng tin tình trạng hoạt đợng máy (ví dụ: sớ lượng đĩa có máy, tỷ lệ yêu cầu bị huỷ bỏ, tỷ lệ thuê đĩa, tiền phạt, tiền thu được, số lượng đĩa bị hỏng, tình trạng hỏng ) - Xem xét yêu cầu khách hàng - Xem đĩa bị hỏng - Xác định giá cho thuê đĩa (tùy thuộc vào loại phim, phim hay cũ ) Khi người quản trị kết nối với máy AL2010 (bằng mật mã), chức hệ thống phải hiển thị và có thơng báo có đĩa tình trạng bị hỏng Khách hàng thường xuyên Khách hàng đăng ký, họ muốn một hoặc nhiều thẻ khách hàng, thẻ này được cung cấp người bán hàng nơi đặt máy (để mua được thẻ này phải trả tiền qua thẻ ATM) Ban đầu, thẻ phải có tới thiểu 100.000 đồng Thời gian sử dụng thẻ là không giới hạn Máy AL2010 cho phép nạp tiền vào thẻ khách hàng từ thẻ ngân hàng Cụ thể hơn, khách hàng đưa thẻ khách hàng vào máy, sau đưa thẻ ngân hàng, nhập mật khẩu thẻ ngân hàng xác định số tiền sẽ nạp cho thẻ Số tiền này tối thiểu là 20.000 và tối đa là 200.000 Thẻ khách hàng phải luôn có mợt sớ tiền tới thiểu để trì tình trạng hoạt động thẻ Tất cả thông tin thao tác nạp tiền vào thẻ phải được lưu trữ thẻ năm 181 Hệ thớng khơng quản lý được sớ tiền cịn lại thẻ, nên trường hợp bị thẻ sẽ không được bồi thường tiền Điều này giúp cho một khách hàng sở hữu nhiều thẻ khác nhau, cho người khác mượn thẻ Mỗi thẻ khách hàng có lưu những thơng tin mang tính lịch sử danh sách phim được mượn thẻ này (thơng tin này có ích để chủ sở hữu thẻ kiểm duyệt được thông tin trường hợp cho người khác mượn thẻ) Tuy nhiên chức này huỷ bỏ khách hàng thấy khơng cần thiết Nếu khách hàng thuê 20 đĩa một tháng, họ sẽ có thêm 50.000 tiền khuyến mại vào tài khoản thẻ Mượn đĩa phim Khách hàng mượn đĩa thẻ khách hàng hoặc thẻ ngân hàng, tiền phải trả tuỳ thuộc vào thời gian mượn và tình trạng phim (phim phát hành hay phim cũ) Nhìn chung, giá tiền thuê đĩa sử dụng thẻ ngân hàng sẽ cao là sử dụng thẻ khách hàng Đới với khách hàng có thẻ khách hàng mợt lần mượn tới đa là phim, với người sử dụng thẻ ngân hàng được mượn đĩa/1 lần Trả đĩa Khi trả đĩa, trước tiên khách hàng phải đưa vào thẻ khách hàng hoặc thẻ ngân hàng, sau đưa vào đĩa DVD Hệ thớng sẽ kiểm tra tình trạng đĩa Nếu đĩa tình trạng tớt, hệ thống sẽ trả lại tiền đặt cọc vào tài khoản, ngược lại khơng được trả lại tiền Hệ thớng kiểm tra xem người mượn có mượn thời hạn đăng ký hay khơng Nếu q, hệ thớng sẽ tính tốn tiền phạt tuỳ theo sớ ngày q hạn Số tiền này sẽ bị trừ vào tiền đặt cọc Sớ tiền thẻ khách hàng âm Khách hàng có ngày để nạp tiền vào thẻ, không tiền thẻ ngân hàng sẽ tự động bị trừ, trường hợp này sẽ phải thêm tiền phạt Người mượn khai báo tình trạng hỏng cuả đĩa Trong trường hợp này, đĩa DVD sẽ khơng được mượn nữa và tình trạng hỏng hóc này sẽ được thông báo đến kỹ thuật viên để xem xét, đĩa không bị hỏng, khách hàng sẽ được trả lại tiền Nếu mã đĩa bị hỏng, khách hàng phải thông báo đến người quản lý hệ thống (địa và số điện thoại được ghi máy AL2010) CÂU HỎI ÔN TẬP Hãy xây dựng đội dự án và viết bản kế hoạch dự án để phát triển hệ thống phần mềm AL2010 Viết bản đặc tả phần mềm cho hệ thống AL2010 Với hệ thớng ta sử dụng mơ hình kiến trúc nào? Hãy phân tích và xây dưng mơ hình kiến trúc cho hệ thớng phần mềm AL2010 Phân tích và thiết kế hệ thống phần mềm AL2010 theo phương pháp hướng đối tượng Xây dựng kế hoạch kiểm thử và kịch bản kiểm thử để kiểm thử hệ thống AL2010 182 TÀI LIỆU THAM KHẢO [1] Project Management Institute (2000) A guide to the Project Management Body of Knowledge 2000 Edition, Newtown Square, Pennsylvania USA [2] Nguyễn Việt Hà (2007) Bài giảng nhập môn kỹ thuật phần mềm, Đại học Quốc gia Hà nội [3] Philippe Lalanda (2008) Cours de Génie Logiciel Introduction, Université Joseph Fourier - Grenoble [4] Nguyễn Văn Vị, Nguyễn Việt Hà (2010) Giáo trình Kỹ nghệ phần mềm, NXB giáo dục Việt Nam, 2010 [5] Huỳnh Văn Đức, Đoàn Thiện Ngân (2004) Giáo trình nhập mơn UML, NXB Lao đợng Xã hợi [6] Thạc Bình Cường, Nguyễn Đức Mận (2011) Kiểm thử bảo đảm chất lượng phần mềm, NXB Đại học Bách Khoa Hà Nội [7] Ngô Trung Việt (2005) Phương pháp luận quản lý dự án CNTT, NXB Khoa học kỹ thuật [8] Dương Kiều Hoa, Tơn Thất Hịa An (2003) Phân tích thiết kế hệ thống thông tin với UML, NXB Đại học Huế [9] Nguyễn Hữu Quốc (2007) Quản lý dự án, Học viện cơng nghệ bưu viễn thơng [10] Ian Sommerville (2006) Software Engineering 8th Edition, Addsion Wasley 183 ... bản sau công nghệ phần mềm: Những vấn đề công nghệ phần mềm: giới thiệu khái quát lịch sử hình thành và phát triển công nghệ phần mềm, những khái niệm bản liên quan đến công nghệ phần mềm Tiến... bản giữa loại phần mềm này là: đối với phần mềm dùng chung, tổ chức phát triển phần mềm sẽ kiểm soát việc đặc tả phần mềm, với những phần mềm riêng, 17 việc đặc tả phần mềm thường được... HỎI ÔN TẬP Khủng hoảng phần mềm là gì? Vì khủng hoảng phần mềm lại dẫn tới đời ngành công nghệ phần mềm? Hãy trình bày những khái niệm bản lĩnh vực công nghệ phần mềm Các chuyên gia CNTT