Đề cương phân tích thiết kế phần mềm

LỜI MỞ ĐẦU Ngày nay, công nghệ phần mềm tới kỷ nguyên mới, tên gọi công việc "kỹ sư phần mềm" thay cho "người lập trình" Việc đặc tả yêu cầu, phát triển phần mềm, quản lý, bảo trì phần mềm hoạt động công nghệ phần mềm để tạo nên sản phẩm phần mềm cho người sử dụng Mục đích đề cương Phân tích thiết kế phần mềm nhằm cung cấp cho sinh viên công nghệ thông tin kiến thức về: nguyên tắc, phương pháp luận, quy trình kỹ thuật để xây dựng bảo trì sản phẩm phần mềm Do vậy, đề cương cung cấp kiến thức về: xác định yêu cầu phần mềm, đặc tả yêu cầu, phân tích, thiết kế, cài đặt phần mềm, kiểm thử phần mềm, bảo trì quản lý thay đổi phần mềm Để tiếp thu tốt kiến thức đề cương này, sinh viên cần nắm kiến thức trang bị năm thứ thứ hai như: Cở sở kỹ thuật lập trình, sở liệu quan hệ, cấu trúc liệu giải thuật số môn sở khác Mặc dầu có cố gắng song thân nhiều hạn chế nên đề cương không tránh khỏi thiếu sót, mong nhận ý kiến đóng góp bạn đọc Giáo trình có sử dụng tư liệu đồng nghiệp, tài liệu Công ty cổ phần điện tử tin học Việt Nam FSC MỤC LỤC BÀI 1: TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM 1.1 Một số khái niệm chung 1.2 Nhân tố người phân loại nghề nghiệp 1.2.1 Nhân tố người ngành công nghiệp phần mềm 1.2.2 Phân loại nghề nghiệp 1.3 Sản phẩm phần mềm – đặc tính phần loại 13 1.3.1 Các đặc tính phần mềm 14 1.3.2 Phân loại phần mềm 16 1.4 Phương pháp phát triển phần mềm 18 1.5 Vai trò người dùng giai đoạn phát triển phần mềm 18 1.6 Tiêu chuẩn sản phẩm phần mềm 19 BÀI 2: TIẾN TRÌNH PHÁT TRIỂN PHẦN MỀM 23 2.1.1 Mô hình tuyến tính (The linear sequential model) 23 2.1.2 Mô hình mẫu (Prototyping model) 23 2.1.3 Mô hình xoắn ốc (The spiral model) 24 2.1.4 Mô hình thác nước 25 2.1.5 Mô hình phát triển dựa thành phần 26 2.2 Quản lý dự án phần mềm 27 2.2.1 Các hoạt động chuẩn bị dự án 27 2.2.2 Lập kế hoạch dự án 28 2.2.3 Nghiên cứu tính khả thi dự án 29 2.2.4 Lựa chọn giải pháp 29 2.2.5 Giám sát kiểm soát 31 2.2.6 Quản lý nhân 35 2.3 Hồ sơ sản phẩm phần mềm 36 BÀI 3: KHẢO SÁT - PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU 38 3.1 Tìm hiểu – xác định yêu cầu 38 3.1.1 Khảo sát, tìm hiểu yêu cầu 38 3.1.2 Đánh giá yêu cầu 39 3.2 Phân tích yêu cầu 40 3.3 Đặc tả yêu cầu 42 3.3.1 Đặc tả yêu cầu 42 3.3.2 Nguyên lý đặc tả 44 3.4 Tư liệu hóa yêu cầu phần mềm 45 3.5 Đặc tính liệu kỹ thuật để thu thập liệu 47 3.5.1 Đặc tính liệu 47 3.5.2 Các kỹ thuật để thu thập liệu cho ứng dụng 50 Bài 4: Thực hành 01- Khảo sát phân tích yêu cầu 60 Bài 5: Thảo luận 01-Kỹ thuật khảo sát phân tích đặc tả yêu cầu 61 Bài 6: Thực hành 02 - Đặc tả yêu cầu 62 BÀI 7: THIẾT KẾ PHẦN MỀM (buổi 1) 63 7.1 Đặc điểm trình thiết kế phần mềm 63 7.2 Các hoạt động trình thiết kế phần mềm 65 7.3 Nền tảng thiết kế phần mềm 68 7.3.1 Trừu tượng (abstraction) 68 7.3.2 Làm mịn (Refinement) 69 7.3.3 Tính module 69 7.3.4 Kiến trúc phần mềm 69 7.3.5 Che dấu thông tin 71 7.3.6 Thiết kế module 72 7.4 Chất lượng thiết kế 72 7.4.1 Sự kết dính 72 7.4.2 Sự ghép nối 73 7.4.3 Sự hiểu 73 7.4.4 Sự thích nghi 74 7.4.5 Một số yêu cầu thiết kế 75 7.5 Chiến lược thiết kế 76 7.5.1 Thiết kế hướng chức 76 7.5.2 Thiết kế hướng đối tượng 77 Bài 8: Thực hành 03 - Thiết kế hệ thống hướng đối tượng 80 Bài 9: THIẾT KẾ PHẦN MỀM (buổi 2) 81 9.1 Thiết kế kiến trúc cho ứng dụng mô hình cho thiết kế ứng dụng 81 9.1.1 Thiết kế kiến trúc ứng dụng 81 9.1.2 Các mô hình thiết kế ứng dụng 81 9.2 Thiết kế Cơ sở liệu 84 9.3 Thiết kế giao diện người dùng 86 9.3.1 Nhân tố người 86 9.3.2 Phong cách tương tác người - máy 87 9.3.3 Thiết kế giao diện người - máy 87 9.3.4 Hướng dẫn thiết kế giao diện 89 Bài 10: Thực hành 04: Thiết kế sở liệu 91 Bài 11: Thảo luận 02: Thiết kế phần mềm 92 Bài 12: Thực hành 05 – Thiết kế đặc tả giao diện 93 BÀI 13: LẬP TRÌNH PHẦN MỀM 94 13.1 Phong cách cài đặt chương trình 94 13.1.1 Tài liệu chương trình 94 13.1.2 Khai báo liệu 96 13.1.3 Xây dựng câu lệnh 96 13.1.4 Vào 96 13.2 Nền tảng ngôn ngữ lập trình 97 13.2.1 Kiểu liệu, định nghĩa kiểu liệu kiểm tra kiểu liệu 97 13.2.2 Chương trình 98 13.2.3 Cấu trúc điều khiển 99 13.2.4 Vào liệu 100 13.2.5 Quản lý nhớ 100 13.2.6 Quản lý lỗi 101 13.3 Các đặc trưng ngôn ngữ cài đặt 101 13.4 Hiệu chương trình tầm quan trọng 102 13.5 Một số vấn đề cải tiến hiệu suất 102 13.5.1 Tốc độ xử lý 102 13.5.2 Không gian nhớ 103 13.5.3 Lựa chọn hệ thống phần cứng 103 13.6 Công cụ trợ giúp phân loại 103 13.6.1 Công cụ CASE 104 13.6.2 Phân loại công cụ CASE 107 Bài 14: Thực hành 06 – Lập trình phần mềm (buổi 1) 114 15.1 Độ tin cậy phần mềm 115 15.1.1 Chất lượng phần mềm việc đảm bảo chất lượng phần mềm 115 15.1.2 Độ tin cậy phần mềm 116 15.2 Kiểm tra chiến lược kiểm tra phần mềm 121 15.2.1 Đặc điểm kiểm tra phần mềm 121 15.2.2 Chiến lược kiểm tra phần mềm 124 15.3 Kỹ thuật kiểm thử phần mềm đặc điểm 127 15.3.1 Khái niệm 128 15.3.2 Đặc điểm kiểm thử 128 15.3.3 Kế hoạch thử nghiệm 129 15.3.4 Phân loại số công cụ kiểm thử tự động 130 Bài 16: Thực hành 07 – Lập trình phần mềm (buổi 2) 132 Bài 17: Thảo luận 03: Kiểm thử phần mềm 133 Bài 18: Thực hành 08 – Kiểm thử phần mềm 134 BÀI 19: BẢO TRÌ PHẦN MỀM VÀ QUẢN LÝ THAY ĐỔI PHẦN MỀM 135 19.1 Hoạt động bảo trì phần mềm phân loại 135 19.1.1 Bảo trì hiệu chỉnh 135 19.1.2 Bảo trì tiếp hợp 135 19.1.3 Bảo trì hoàn thiện 135 19.1.4 Bảo trì phòng ngừa 135 19.2 Đặc điểm bảo trì phần mềm 136 19.2.1 Bảo trì có cấu trúc bảo trì không cấu trúc 136 19.2.2 Giá thành bảo trì 137 19.2.3 Một số vấn đề khác 138 19.3 Công việc bảo trì phần mềm số hiệu ứng lề 139 19.3.1 Khả bảo trì 139 19.3.2 Các công việc bảo trì 140 19.3.3 Một số hiệu ứng lề công việc bảo trì 142 19.4 Một số hình thức bảo trì phần mềm 143 19.4.1 Bảo trì mã chương trình xa lạ 143 19.4.2 Công nghệ phản hồi công nghệ tái sử dụng 144 19.4.3 Bảo trì phòng ngừa 144 19.4.4 Chiến lược phần mềm thành phần 145 19.5 Quản lý thay đổi phần mềm 146 19.5.1 Các thủ tục quản lý thay đổi 146 19.5.2 Ghi định theo thời gian 148 19.5.3 Quản lý thay đổi tài liệu 148 TÀI LIỆU THAM KHẢO 149 BÀI 1: TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM Công nghệ phần mềm - Software Engineering - hoạt động bao gồm: phát triển, đưa vào hoạt động, bảo trì, loại bỏ phần mềm cách có hệ thống Các kỹ sư phần mềm cung cấp với kỹ thuật, công cụ nhằm phát triển hệ thống phần mềm Như vậy, công nghệ phần mềm lĩnh vực nghiên cứu tin học, nhằm đề xuất nguyên lý, phương pháp, công cụ, cách tiếp cận phương tiện phục vụ cho việc thiết kế cài đặt sản phẩm phần mềm có chất lượng Ngày nay, phát triển phần mềm ngày thực khó kiểm soát được; dự án phần mềm thường kéo dài vượt chi phí cho phép Những nhà lập trình chuyên nghiệp phải cố gắng hoàn thành dự án phần mềm cách có chất lượng, hạn chi phí cho phép Mục đích chương đưa nhận định tạo nên tranh sở phương pháp tiếp cận khác công việc tạo nên công nghệ phần mềm Các vấn đề cần làm rõ, chi tiết thêm trình bày chương tiếp sau giáo trình 1.1 Một số khái niệm chung Mục tiêu công nghệ phần mềm tạo phần mềm tốt, giảm đến tối thiểu may rủi gây cho người liên quan Trong trình đề cập, sử dụng thuật ngữ: Phần mềm (software): tập hợp câu lệnh viết nhiều ngôn ngữ lập trình, nhằm tự động thực số chức giải toán Công nghệ (engineering): cách sử dụng công cụ, kỹ thuật cách giải vấn đề Công nghệ phần mềm (software engineering): việc áp dụng công cụ, kỹ thuật cách hệ thống việc phát triển ứng dụng dựa máy tính Đó việc áp dụng quan điểm, tiến trình có kỷ luật lượng hoá được, có hệ thống để phát triển, vận hành bảo trì phần mềm Theo quan điểm nhiều nhà nghiên cứu, nhìn công nghệ phần mềm mô hình phân theo ba tầng mà tất tầng nhằm tới mục tiêu chất lượng, chi phí, thời hạn phát triển phần mềm Mô hình phân theo ba tầng công nghệ phần mềm mô tả sau: Ở tầng quy trình (process) liên quan tới vấn đề quản trị phát triển phần mềm lập kế hoạch, quản trị chất lượng, tiến độ, chi phí, mua bán sản phẩm phụ, cấu hình phần mềm, quản trị thay đổi, quản trị nhân (trong môi trường làm việc nhóm), việc chuyển giao, đào tạo, tài liệu; Tầng phương pháp (methods) hay cách thức, công nghệ, kỹ thuật để làm phần mềm: liên quan đến tất công đoạn phát triển hệ thống nghiên cứu yêu cầu, thiết kế, lập trình, kiểm thử bảo trì Phương pháp dựa nguyên lý cho tất lĩnh vực công nghệ kể hoạt động mô hình hoá kỹ thuật mô tả Tầng công cụ (tools) liên quan đến việc cung cấp phương tiện hỗ trợ tự động hay bán tự động cho tầng trình phương pháp (công nghệ) Qua sơ đồ trên, ta thấy rõ công nghệ phần mềm khái niệm đề cập không tới công nghệ công cụ phần mềm mà tới cách thức phối hợp công nghệ, phương pháp công cụ theo quy trình nghiêm ngặt để làm sản phẩm cóchất lượng Kỹ sư phần mềm (software engineer): người biết cách áp dụng rộng rãi kiến thức cách phát triển ứng dụng vào việc tổ chức phát triển cách có hệ thống ứng dụng Công việc người kỹ sư phần mềm là: đánh giá, lựa chọn, sử dụng cách tiếp cận có tính hệ thống, chuyên biệt, rõ ràng việc phát triển, đưa vào ứng dụng, bảo trì, thay phần mềm Do đặc điểm nghề nghiệp, người kỹ sư phần mềm phải có kỹ như:  Định danh, đánh giá, cài đặt, lựa chọn phương pháp luận thích hợp công cụ CASE  Biết cách sử dụng mẫu phần mềm (prototyping)  Biết cách lựa chọn ngôn ngữ, phần cứng, phần mềm  Quản lý cấu hình, lập sơ đồ kiểm soát việc phát triển tiến trình  Lựa chọn ngôn ngữ máy tính phát triển chương trình máy tính  Đánh giá định loại bỏ nâng cấp ứng dụng Mục tiêu kỹ sư phần mềm sản xuất sản phẩm có chất lượng cao phù hợp với quy trình phát triển chuẩn mực Việc phát triển (development): định phát triển sản phẩm phần mềm kết thúc sản phẩm phần mềm chuyển giao cho người sử dụng Việc sử dụng (operations): việc xử lý, vận hành ngày sản phẩm phần mềm Việc bảo trì (maintenance): thực thay đổi mang tính logic hệ thống chương trình để chữa lỗi cố định, cung cấp thay đổi công việc, làm cho phần mềm hiệu Việc loại bỏ (retirement): thường việc thay ứng dụng thời ứng dụng 1.2 Nhân tố người phân loại nghề nghiệp 1.2.1 Nhân tố người ngành công nghiệp phần mềm Đối với sản phẩn phần mềm, người hoàn thành mà kết lao động nhóm người-ta gọi nhóm phát triển phần mềm Mỗi thành viên nhóm không vị kỷ, thành lao động nhóm xen thành chung phải tuyệt đối trung thành với nhóm Như vậy, nhóm phát triển phần mềm gọi nhóm hợp lý? Sau vài yếu tố cần xem xét:  Nhóm có thành viên  Nhóm tổ chức  Tình hình thực tế thành viên nhóm  Môi trường, điều kiện mà nhóm làm việc, Mỗi thành viên nhóm phải có số kiến thức cần thiết tuỳ thuộc vào vai trò nhóm để phát triển phần mềm 1.2.2 Phân loại nghề nghiệp Yêu cầu phát triển Công nghệ Thông tin (CNTT) Việt nam đòi hỏi cần có người lao động tất ngành kinh tế biết sử dụng hữu hiệu CNTT công việc mình, đồng thời cần có người trực tiếp tham gia vào sản xuất, kinh doanh, vận hành CNTT Do cần có lớp người lao động sau:  Những người biết vận dụng sáng tạo CNTT vào nghiệp vụ chuyên môn  Những người tham gia quản lí vận hành hệ thống CNTT  Những người tham gia trực tiếp vào việc phát triển xây dựng sản phẩm CNTT, Việc phân loại nghề nghiệp hệ thống thông tin phân chia dựa vào tiêu chuẩn như: mức độ kinh nghiệm, loại hình công việc… * Mức độ công việc  Sơ cấp Nhân viên cán mức độ sơ đẳng trực tiếp giám sát chặt chẽ, họ làm công việc chuyên môn cấp độ tối thiểu Những cán mức độ sơ đẳng có kỹ năng, khả để tìm thông tin để mở rộng, thúc đẩy thông tin Thường phải khoảng hai năm để thực công việc đẳng cấp  Trung cấp Những cán có trình độ trung cấp hầu hết làm việc độc lập, yêu cầu trực tiếp số hoạt động Những người bắt đầu mức độ trung cấp có đến năm kinh nghiệm Thời gian trung bình cấp độ từ – năm  Cao cấp Các cán mức độ có trình độ định công việc kinh nghiệm kỹ thuật đào tạo, huấn luyện người khác Những nhân viên giám sát người khác, phụ thuộc vào quy mô, phức tạp dự án, họ thường xuyên có điều kiện tiên để lãnh đạo Những cán có từ – năm kinh nghiệm có năm để học kỹ Rất nhiều người kết thúc nghiệp học vấn họ cấp độ lưu lại vài năm để hoàn thành dự án, trở thành chuyên gia công nghệ ứng dụng  Lãnh đạo Những nhà lãnh đạo làm việc Họ kiêm tất nhiệm vụ giám sát Một người lãnh đạo thường gọi chuyên gia phụ trách dự án Những chuyên gia có kinh nghiệm, kỹ trình độ đại học có mong muốn quản lý vị trí  Chuyên gia kỹ thuật Chuyên gia kỹ thuật người có kinh nghiệm rộng rãi nhiều lĩnh vực Kinh nghiệm chuyên gia bao gồm phát triển ứng dụng, mạng, sở liệu hệ điều hành Các chuyên gia có trình độ quản lý, có bổn phận lực giống mà chịu trách nhiệm quản lý dự án Các chuyên gia làm việc vị trí hệ thống thông tin khoảng 10 năm lâu trì lâu dài cấp độ  Nhà quản lý Công việc quản lý cách độc lập, thể giá trị riêng cá nhân, mục tiêu tiến hành báo cáo, tường trình quản lý dự án Các nhà quản lý trở thành chuyên gia kỹ thuật theo định hướng họ có kinh nghiệm làm việc hầu hết họ có trách nhiệm cách quản lý Đối với nhà quản lý kỹ thuật việc phân chia đặc điểm công việc kế hoạch mục tiêu, giám sát, quản lý cá nhân, hoạt động liên lạc hoạt động quản lý dự án Sơ đồ mối liên hệ sau thể sau: Mối liên hệ đường nghề nghiệp cho mức khác * Loại hình công việc Ở đây, loại hình công việc bàn luận đến dựa vào cách phân loại gồm: phát triển ứng dụng, hỗ trợ ứng dụng, chuyên ngành kỹ thuật, nhân viên vấn đề khác  Phát triển ứng dụng Lập trình viên: Các lập trình viên chuyển đổi đồ án chi tiết kỹ thuật sang module mã tự kiểm tra đơn vị Các lập trình viên luân phiên chịu trách nhiệm phát triển ứng dụng bảo trì Những chuyên gia lập trình trình độ đại học thực nhiệm vụ bên việc lập trình Kỹ sư phần mềm: Một kỹ sư phần mềm thực chức nhà phân tích, nhà thiết kế lập trình viên Các phân tích gia trình độ đại học luôn tham gia vào tổ chức có cấp độ IS để lập kế hoạch nghiên cứu khả thi Các kỹ sư phần mềm làm ba việc – phân tích, thiết kế lập trình đứng lãnh đạo dự án quản lý dự án Một kỹ sư quản lý phần mềm sơ cấp thường dành nhiều thời gian lập trình kỹ sư có trình độ cao cấp lại tập trung vào việc lập kế hoạch, nghiên cứu khả thi, phân tích thiết kế Kỹ sư tri thức (KE): Các kỹ sư tri thức suy luận mô hình ngữ nghĩa từ chuyên gia để từ xây dựng hệ chuyên gia trí tuệ nhân tạo Các kỹ sư tri thức tương tự kỹ sư phần mềm chuyên môn hoá kỹ để áp dụng vào vấn đề trí tuệ nhân tạo Việc phát triển mô hình chương trình cấu trúc trí tuệ đòi hỏi khả quan sát, kỹ vấn sâu sắc, khả trừu tượng hoá vấn đề chuyên môn cá nhân để tạo ý thức lập luận thông tin cần thiết khả phát triển dự đoán thông tin tính xác với chuyên gia  Hỗ trợ ứng dụng Chuyên gia ứng dụng: Chuyên gia ứng dụng có vùng vấn đề chuyên môn hoá cho phép họ tham khảo ý kiến đội dự án loại ứng dụng cụ thể Ví dụ nhà phân tích cao cấp chuyển tiền thời gian thực phân chia thời gian dự án chuyển tiền nước quốc tế, biết trước quy tắc, luật lệ phải tuân theo ngân hàng dự trữ liên bang tổ chức chuyển tiền khác Quản trị liệu: Người quản lý liệu quản lý thông tin nguồn thống Với chức này, phận quản lý liệu giúp cho người sử dụng xác định tất liệu sử dụng, liệu có ý nghĩa trình thực chức công ty Những người quản lý liệu thiết lập bảo lưu chuẩn mực để thống liệu Khi liệu xác định, người quản lý liệu làm việc để định dạng xác định cấu trúc sở liệu để sử dụng với ứng dụng Với việc phát triển ứng dụng mới, người quản lý liệu làm việc với phận phát triển ứng dụng để định vị số liệu tự động với phận quản trị CSDL để cung cấp nhóm ứng dụng dễ dàng truy nhập sở liệu tự động hoá BÀI 19: BẢO TRÌ PHẦN MỀM VÀ QUẢN LÝ THAY ĐỔI PHẦN MỀM Bảo trì giai đoạn cuối chu trình phát triển phần mềm Các chương trình máy tính thay đổi- phải mở rộng, sửa lỗi, tối ưu hoá, theo thống kê bảo trì chiếm đến 70% toàn công sức bỏ cho dự án phần mềm Do vậy, bảo trì hoạt động phức tạp lại vô cần thiết chu trình sống sản phẩm phần mềm để đảm bảo cho phần mềm phù hợp với người sử dụng Do nhu cầu phát triển hệ thống thông tin, hay không muốn nói có hệ thống thông tin thay đổi suốt chu trình sống Để trì tính đắn, trật tự giai đoạn bảo trì quản lý thay đổi phần mềm hoạt động cần thiết song song 19.1 Hoạt động bảo trì phần mềm phân loại Bảo trì phần mềm phức tạp chia hoạt động bảo trì làm bốn hoạt động sau: 19.1.1 Bảo trì hiệu chỉnh Công việc bảo trì cần phải thực việc kiểm tra chương trình tránh mội lỗi ẩn chứa bên hệ phần mềm lớn Trong sử dụng bất kỹ chương trình lớn nào, lỗi báo lại cho người phát triển Bảo trì hiệu chỉnh trình phân tích hiệu chỉnh hay nhiều lỗi chương trình 19.1.2 Bảo trì tiếp hợp Hoạt động thứ hai diễn thay đổi thường xuyên môi trường Những hệ phần cứng dường công bố theo chu trình 24 tháng lần Những hệ điều hành hay phiên hệ cũ đặn xuất hiện; thiết bị ngoại vi thành phần hệ thống khác liên tục nâng cấp thay đổi Thời gian hữu dụng phần mềm ứng dụng mặt khác lại dễ dàng vượt qua thời hạn mười năm, lâu môi trường hệ thống phát triển Bảo trì tiếp hợp hoạt động sửa đổi phần mềm để thích ứng với thay đổi môi trường 19.1.3 Bảo trì hoàn thiện Hoạt động thứ ba diễn phần mềm hoàn tất thành công Hoạt động chiếm hầu hết công sức tiêu tốn cho việc bảo trì phần mềm Lúc sử dụng, yêu cầu khả mới, thay đổi chức có, mở rộng tổng quát người dùng gửi đến Để thỏa mãn yêu cầu phát triển người sử dụng, ta tiến hành bảo trì hoàn thiện 19.1.4 Bảo trì phòng ngừa 135 Bảo trì phòng ngừa hoạt động bảo trì diễn phần mềm thay đổi để cải thiện tính bảo trì hay độ tin cậy tương lai để cung cấp tảng tốt cho mở rộng sau Bảo trì phòng ngừa, hoạt động nhiều xa lạ giới phần mềm Các thuật ngữ dùng để mô tả ba hoạt động bảo trì Swanson đề xướng Thuật ngữ thứ tư thường dùng việc bảo trì phần cứng hay hệ thống vật lý khác Tuy nhiên cần ý điểm tương tự bảo trì phần mềm bảo trì phần cứng gây nhầm lẫn Phần mềm khác với phần cứng, tận dụng được, hoạt động bảo trì phần cứng chủ yếu - thay phận bị hỏng hóc hay gãy vỡ - không kể đến Trong thực tế hoạt động bảo trì, nhiệm vụ làm phần bảo trì tiếp hợp bảo trì hoàn thiện giống nhiệm vụ cần làm giai đoạn phát triển chu trình phần mềm Để tiếp hợp hay hoàn thiện, phải xác định yêu cầu, thiết kế lại, tạo mã kiểm tra phần mềm có Thông thường nhiệm vụ gọi bảo trì 19.2 Đặc điểm bảo trì phần mềm Bảo trì phần mềm gần giai đoạn bị coi nhẹ chu trình phần mềm Kiến thức bảo trì có so sánh với giai đoạn hoạch định phát triển Có số liệu nghiên cứu chế tạo tập trung vào đề tài này, phương pháp kỹ thuật đưa Để hiểu điểm chất bảo trì, xem xét vấn đề từ ba góc độ khác nhau:  Các hoạt động cần thiết để hoàn thành giai đoạn bảo trì tính toàn vẹn cách tiếp cận theo công nghệ phần mềm hiệu hoạt động đó, hay thiếu hụt  Chi phí kèm theo giai đoạn bảo trì  Các vấn đề thường gặp phải tiến hành bảo trì phần mềm 19.2.1 Bảo trì có cấu trúc bảo trì không cấu trúc Nếu thành phần có cấu hình phần mềm mã nguồn, hoạt động bảo trì bắt đầu với việc đánh giá chi tiết mã nguồn thường phức tạp với tài liệu nghèo nàn bên Những đặc điểm tế nhị cấu trúc phần mềm, cấu trúc liệu toàn cục, giao diên hệ thống, hoạt động ràng buộc thiết kế thường khó sáng tỏ hay bị hiểu lầm Các thay đổi lặt vặt thường xuyên làm cho mã khó đánh giá Các kiểm tra hồi quy (lặp lại kiểm tra trước để đảm bảo thay đổi không tạo lỗi phần mềm hoạt động) thực lưu kiểm tra Chúng ta tiến hành phép bảo trì không cấu trúc phải trả giá (khi lãng phí công sức gây tâm trạng thất vọng) Sự trả giá kèm với phần mềm không phát triển theo phương pháp đắn 136 Nếu có cấu hình phần mềm hoàn thiện, nhiệm vụ bảo trì bắt đầu việc đánh giá tài liệu thiết kế Sau xác định đặc điểm thuộc cấu trúc quan trọng, đặc điểm hoạt động giao diện Tính toàn vẹn sửa đổi hiệu chỉnh cần thiết đánh giá kế hoạch sửa đổi thiết lập Thiết kế thay đổi (sử dụng kỹ thuật phù hợp với điều bàn luận chương trước) nhận xét đánh giá Mã nguồn phát triển, sau tiến hành kiểm tra hồi quy sử dụng thông tin chứa phần "đặc tả kiểm tra" phần mềm lại phát hành Các mô tả phép bảo trì có cấu trúc tiến hành kết ứng dụng trước khoa học công nghệ phần mềm Mặc dù có mặt cấu hình phần mềm không đảm bảo vấn đề bảo trì nảy sinh, khối lượng công việc giảm bớt chất lượng chung thay đổi hiệu chỉnh cải thiện 19.2.2 Giá thành bảo trì Theo thống kê, giá thành cho việc bảo trì phần mềm tăng lên cách đặn suốt 20 năm qua Trong năm 1970, bảo trì chiếm đến 35 đến 40 phần trăm kinh phí phần mềm dành cho tổ chức hệ thống thông tin.Tỷ lệ nhảy tới số 60 vào năm 1980 Và nhiều công ty chi 80% kinh phí cho việc bảo trì vào năm 1990 Chi phí cho việc bảo trì rõ ràng Tuy nhiên chi phí khác khó thấy gây mối quan tâm lớn hơn:  Một chi phí khó xác định việc bảo trì phần mềm hội phát triển bị bỏ qua tài nguyên có sẵn dành cho nhiệm vụ bảo trì  Sự không hài lòng người dùng yêu cầu hợp lý cho việc sửa chữa hay sửa đổi không ý cách hợp lý  Việc suy giảm chất lượng nói chung lỗi tạo thay đổi phần mềm bảo trì  Một yêu cầu làm ngắt quãng trình phát triển nhân viên buộc tiến hành công việc bảo trì Chi phí cuối cho việc bảo trì giảm sút kinh khủng suất lao động (được đo theo số dòng lệnh -LOC- người tháng hay số tiền chi phí cho dòng lệnh) Sự giảm sút xuất tiến hành bảo trì phần mềm cũ Người ta ghi nhận giảm sút suất lao động theo tỷ lệ 40:1, có nghĩa chi phí cho việc phát triển trị giá $25.00 dòng lệnh trị giá tới $1000.00 cho việc bảo trì dòng lệnh Công sức cho việc bảo trì phân chia thành thao tác làm việc: phân tích, ước lượng, thay đổi thiết kế, sửa chữa chương trình nguồn thao tác lặp lại: việc cố gắng hiểu chương trình nguồn làm gì, cố gắng sáng tỏ cấu trúc liệu, thuộc tính giao diện, giới hạn việc thực hiện, Biểu thức cung cấp mô hình cho công việc bảo trì: 137 M = p + K* exp(c-d) với M = toàn công việc cho việc bảo trì; p = công việc làm (như miêu tả trên); K = số kinh nghiệm; c = đánh giá mức độ phức tạp tính cho việc thiếu thiết kế cấu trúc 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ũ phương pháp phát triển phần mềm cỏi sử dụng - tức thiếu sót công nghệ phần mềm, người hay nhóm dùng phương pháp giá trị để bảo trì phần mềm Chi phí cho bảo trì phần mềm phát triển không phương pháp minh hoạ hình sau: Chi phí việc phát triển phần mềm phương pháp 19.2.3 Một số vấn đề khác Hầu hết vấn đề liên quan tới việc 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 chu trình phần mềm gần luôn tạo vấn đề giai đoạn cuối Nhiều vấn đề kinh điển liên quan tới việc bảo trì phần mềm trình bày đây: Rất khó theo dõi tiến hóa phần mềm qua phiên Các thay đổi không tư liệu hóa Khó theo dõi trình xử lý tạo phần mềm Thường xuyên gặp nhiều khó khăn việc tìm hiểu chương trình người khác viết 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 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 mặt để giải thích Chúng ta trông cậy vào giải thích cá nhân nhà phát triển phần mềm việc bảo trì yêu cầu 138  Các tài liệu xá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 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, 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 khó khăn dẫn đến xu hướng sai  Việc bảo trì phần mềm không coi công việc dễ dàng mà công việc bảo trì phần mềm liên quan tới sai lệch mức độ cao 19.3 Công việc bảo trì phần mềm số hiệu ứng lề 19.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 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 soát Khả bảo trì 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 phần mềm Cấu hình yếu có tác động tương tự, chí bước kỹ thuật xây dựng phần mềm xem xé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 đội ngũ phần mềm  Cấu trúc hệ thống dễ hiểu  Dễ dàng kiểm soát hệ thống  Dùng ngôn ngữ lập trình chuẩn  Dùng hệ điều hành chuẩn  Dùng cấu trúc chuẩn tài liệu  Dùng tài liệu kiểm tra  Phương tiện gỡ rối kèm  Dùng máy tính tốt để thực việc bảo trì Các yếu tố đưa phản ánh đặc điểm phần cứng chương trình nguồn dùng việc phát triển phần mềm Những yếu tố khác cần thiết để có phương pháp chuẩn, chương trình nguồn chuẩ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 hệ thống thành phần phải chịu thay đổi không tránh được, hội tạo phần mềm có khả bảo trì tăng thực b Đánh giá định lượng 139 Khả bảo trì, chất lượng hay độ tin cậy khó xác định Tuy nhiên đánh giá khả bảo trì gián tiếp việc xem xét thuộc tính công việc bảo trì đánh giá được:  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 đề  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  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ế liệu cung cấp cho người quản lý với số hiệu công việc 19.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ì thiết lập; thủ tục ghi nhận đánh giá miêu tả; loạt thứ tự chuẩn bước cho yêu cầu bảo trì phải định nghĩa Thêm vào đó, thủ tục lưu trữ hồ sơ cho hoạt động bảo trì thiết lập tổng kết tiêu chuẩn đánh giá vạch rõ a Cơ cấu bảo trì Mặc dù tổ chức bảo trì chuẩn không cần thiết lập, ủy thác trách nhiệm cần thiết kể cho tổ chức phát triển phần mềm nhỏ Những yêu cầu bảo trì chuyển qua cho người kiểm soá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 có trách nhiệm phần nhỏ chương trình sản phẩm Khi môth yêu cầu đánh giá, người ủy quyền quản lý việc thay đổi phải định hhành động thực tiếp Cơ cấu miêu tả phục vụ cho việc thiết lập phạm vi trách nhiệm công việc bảo trì Người kiểm soát người ủy quyền quản lý việc thay đổi người nhóm quản lý chuyên gia kỹ thuật cao cấp b Báo cáo Tất yêu cầu việc bảo trì phần mềm cần trình bày theo tiêu chuẩn Người phát triển phần mềm thường cung cấp đơn yêu cầu bảo trì gọi báo cáo lỗi phần mềm Báo cáo người sử dụng điền vào yêu 140 cầu công việc bảo trì Nếu xuất hịên lỗi, mô tả đầy đủ tình dẫn đến lỗi bao gồm liệu, đoạn chương trình yêu cầu khác phải điền đầy đủ vào báo cáo Nếu yêu cầu bảo trì bảo trì tiếp hợp hay bảo trì hoàn thiện yêu cầu chi tiết thảo Đơn yêu cầu bảo trì người kiểm soát bảo trì người quản lý hệ thống xem xét phần trước nêu Đơn yêu cầu bảo trì thiết lập từ bên coi sở để đề kế hoạch công việc bảo trì Ngoài nội quan phần mềm báo cáo thay đổi phần mềm tạo Nó ra:các công sức đòi hỏi để thỏa mãn đơ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, liệu cần cho việc sửa đổi, c Lưu giữ hồ sơ Thường đầy đủ hồ sơ cho tất giai đoạn chu kỳ sống phần mềm Thêm 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ả xác định tính chất chương trình khó xác định 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:  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 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 dấu hiệu thay đổi chương trình  Số câu lệnh thêm vào chương trình nguồn chương trình thay đổi  Số câu lệnh 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 kết thúc bảo trì  Tổng số người dùng cho việc bảo trì 141 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 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 lần chạy chương trình  Tổng số người dùng cho loại 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 bảo trì  Số trung bình người cho dòng lệnh thêm vào xóa  Số trung bình người cho ngôn ngữ lập trình  Thời gian trung bình cho việc bảo trì đơn yêu cầu bảo trì  Tỷ lệ phần trăm kiểu bảo trì 19.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 câu lệnh đơn đem lại hậu thảm khốc Mặc dù ả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 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ở đó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 tiến hành phần tử riêng rẽ cấu trúc liệu Khi liệu thay đổi, việc thiết kế phần mềm không phù hợp với liệu lỗi có khả xảy 142 Hiệu ứng lề liệu xảy kết việc thay đổi cấu trúc liệu Các thay đổi liệu sau thường gây lỗi:  Định nghĩa lại số cục số địa phương  Định nghĩa lại cấu trúc ghi hay cấu trúc file  Tăng giảm kích thước mảng  Thay đổi 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ề liệu hạn chế tài liệu thiết kế mô tả cấu trúc liệu cung cấp lời dẫn tham khảo đến phần từ liệu, 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ế tài liệu hướng dẫn sử dụng Bất lúc có thay đổi luồng liệu, cấu trúc phần mềm, thủ tục hay có liên quan, tài liệu kỹ thuật phải cập nhật Tài liệu thiết kế phản ánh không trạng thái phần mềm có lẽ tồi tệ 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 giảm toàn cấu hình xem xét trước phát hành phiên phần mềm tiếp sau Thực tế vài yêu cầu bảo hành đòi hỏi không thay đổi thiết kế phần mềm mã chương trình, mà cần thiếu rõ ràng tài liệu người sử dụng Trong trường hợp nổ lực bảo trì tập trung vào tài liệu 19.4 Một số hình thức bảo trì phần mềm 19.4.1 Bảo trì mã chương trình xa lạ Các chương trình gọi mã chương trình xa lạ nếu:  Không 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 thiết kế theo tiêu chuẩn, khái niệm thiết kế có cấu trúc chưa áp dụng  Yourdon đưa 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ạ sau: 143  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 nhiều thông tin sở tốt  Cố gắng làm quen với toàn 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ẽ cho riêng bạn sơ đồ cấu trúc sơ đồ luồng hoạt động mức cao, chưa có tồn  Đánh giá tình hình hợp lý tài liệu có; bổ sung thêm lời thích 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 thường chương trình dịch và/hoặc assembler 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 chỗ Đánh dấu chương trình lệnh bạn sửa  Đừng loại bỏ chương trình trừ bạn chắn không sử dụng  Đừ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ữ ghi chép chi tiết (vê hoạt động bảo trì kết quả)  Tránh nóng vội vô lý ném chương trình cũ viết lại  Thực kiểm tra lỗi 19.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- phần mềm đơn giản Trong nhiều trường hợp, chương trình tổ chức ngược thuộc nhà cạnh tranh mà thuộc thân công ty Bí mật cần khám phá không giữ đặc tả Do tổ chức ngược phần mềm 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 trình khám phá thiết kế Các công cụ công nghệ phản hồi lấy 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à dùng thông tin để biến đổi 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ý 19.4.3 Bảo trì phòng ngừa Bảo trì phòng ngừa phần mềm máy tính vấn đề tranh cãi Thay đợi nhận yêu cầu bảo trì, tổ chức phát triển hay bảo trì chọn chương trình mà: 144  Sẽ sử dụng số năm định trước  Hiện sử dụng tốt  Dễ bị thay đổi nâng cấp tương lai gần Thoạt đầu ý kiến đề nghị phát triển lại chương trình lớn phiên làm việc tồn ta thấy dường phung phí Nhưng xem xét điểm sau:  Chi phí để bảo trì 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 khuôn mẫu phần mềm tồn tại, suất phát triển chương trình 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 hướng thay đổi tìm dễ dàng nhiều  Các công cụ CASE dành cho reverse engineering re-engineering thực tự động số phần công việc  Một cấu hình phần mềm tồn hoàn thành bảo trì phòng ngừa Khi tổ chức phát triển phần mềm bán phần mềm sản phẩm, bảo trì phòng ngừa xem "phiê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 xếp theo thứ tự ưu tiên xem xét lại ứng cử cho bảo trì phòng ngừa 19.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 thay phụ tùng Một khái niệm gọi 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 trình mô hình hóa yêu cầu dùng hay nhiều mức chi tiết, bao gồm mô hình làm việc Các tài nguyên dự án xếp đặt để sản xuất phiên phần mềm mô tả theo yêu cầu phải nhỏ Phiên nguyên mẫu làm cho người dùng, người thiết kế quản trị xem lại phần mềm Quá trình tiếp tục đề nghị, với phiê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 phát triển, có phụ tùng phần mềm sử dụng nhận yêu cầu bảo trì hiệu chỉnh Ví dụ module phân tích thiết kế thực theo hai cách khác có giao diện bên Một phiên module có sử dụng phần mềm làm việc Nếu module hỏng, phụ tùng lắp thay 145 Mặc dù chiến lược phụ tùng thay cho phần mềm khác thường chút, chứng tỏ tốn kém, tính đến chi phí cho tất chu kỳ sống phần mềm 19.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 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 mình, Các thay đổi yêu cầu, thiết kế, chương trình, giao diện, phần cứng 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, kích hoạt từ tác nhân bên ngoà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 ý thích nảy người sử dụng cho phép thực yêu cầu hợp lý 19.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 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ở tạo lập để đưa vào quản lý Một sản phẩm công việc sở sản phẩm coi hoàn thiện sở cho công việc khác nhóm triển khai dự án Ví dụ như, tài liệu sở quy định yêu cầu chức sau chấp nhận người sử dụng Dưới ví dụ trình thao tác yêu cầu thay đổi đặ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í chủ, người sử dụng ký  Hoàn thiện danh sách 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 chương trình bị thay đổi, xác định ngày mục cập nhật hoàn thiện Nếu thủ tụ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 chủ/người sử dụng thông qua  Tóm tắt ngày tháng, trình chi phí Trước tiên, tài liệu sở giữ nguyên, sau thêm vào yêu cầu thay đổi Khi quy định chức cập nhật để điều tiết thay đổi, đóng băng lại công việc lại tiếp tục Ba yêu cầu trướ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 cho đên sau ứng dụng thực Các thay đổi phân loại theo số cách 146  Thứ nhất, chúng phân theo kiểu loại bỏ lỗi, cải tiến thực thay đổi chức  Thứ hai, thay đổi phân loại thành yêu cầu lựa chọn  Thứ ba, phân theo độ ưu tiên khẩn cấp, lệnh với ngày kết thúc yêu cầu, lệnh với ngày bắt đầu yêu cầu ư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 ưu tiên Việc biết loại yê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 tài liệu hoá sau thay đổi kết thúc Tất 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 lúc nào, quy định yêu cầu chứ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 thêm vào danh sách yêu cầu thay đổi để xem xét tương lai trừ thiết kế khẩn cấp Một thủ tục điều khiển thay đổi yêu cầu người sử dụng phải đệ trình lời yêu cầu thay đổi thức cho người điều hành dự án:  Người sử dụng gửi cho người điều hành dự án người chủ mẫu yêu cầu thay đổi  Người điều hành dự án kỹ sư phần mềm triển khai khai báo tự động Vào lúc đó, danh sách kiểm soát người điều hành dự án dùng để xác định tất 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 thảo luận với chủ sử dụng để vạch thay đổi ưu tiên, tiến trình chi phí  Thoả thuận thức hoá 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 tất tài liệu có liên quan thay đổi  Thực thay đổi: nhiệm vụ hoàn thành, xoá nhiệm vụ danh sách kiểm soát người điều hành dự án  Chủ sử dụng thông qua việc đóng yêu cầu yêu cầu đó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 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 gán ưu tiên hoạt động, chi phí tiến trình thay đổi 147 Yêu cầu, ngày dự định hoạt động, thay đổi tiến trình tăng chi phí thêm vào file trình dự án Các thay đổi quản lý nhân viên điều khiển thay đổi, người có nhiệm vụ bảo dưỡng trình dự án ghi điều khiển thay đổi, hàng tháng in báo cáo điều khiển thay đổi Một file điều khiển thay đổi chứa tất yêu cầu, thư từ tài liệu thay đổi Một yêu cầu thay đổi mở tạo yêu cầu đưa số lượng thay đổi gán Yêu cầu thay đổi mở nằm file yêu cầu hoàn thành, đóng báo cáo Khi thay đổi thực hiện, mục có ảnh hưởng cập nhật, bao gồm tư liệu tương ứng, mã, Một danh sách kiểm soát người điều hành dự án dùng để loại bỏ hoạt động yêu cầu Tài liệu nhân viên điều khiển thay đổi xếp phân phối cho người có quan tâm Ngày hoàn thành thay đổi đưa vào file điều khiển thay đổi Thay đổi xác định đóng báo cáo tình trạng tới yêu cầu mở 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 yêu cầu thay đổi cúa dự án để nhận biết thành công nhóm yêu cầu Chi phí thay đổi chung năm thường sử dụng tiêu để xem ứng dụng có triển vọng hay cần vứt bỏ hay cần công nghệ hoá lại Trong trường hợp này, chi phí số lượng yêu cầu thay đổi theo dõi thông qua trình điều khiển thay đổi Các báo cáo tổng kết dự án thay đổi thời kỳ định, so sánh theo thời kỳ triển khai 19.5.2 Ghi định theo thời gian Khi bắt đầu 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ữ trình định Có nghĩa dùng công cụ điện tử phiên viết tay định trì dạng văn Với công cụ điện tử, điện tử lưu trữ Với công cụ ghi tay, phiên cũ cập nhật đổi tên tài liệu thay đổi Ví dụ như, quy định chức công ty ABC đặ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 Phần ngày tháng tên thay đổi thay đổi quan trọng tài liệu Thủ tục quản lý thay đổi nói đến phần 19.5.3 Quản lý thay đổi tài liệu Các thay đổi tài liệu xác định 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 tóm tắt thay đổi Mục đích bảng nội dung thay đổi để tóm tắt tất thay đổi cho người đọc Các thay đổi nên đánh dấu đỏ văn để xác định phận thay đổi Nếu nội dung cũ quan trọng đưa vào ý, ghi ngày tháng, dán nhãn phiên trước Cần nhớ bạn phải giữ tài liệu phiên cũ để dùng cho trình phát triển 148 Chương 7: THAM Bảo trì phần mềmvà quản lý thay đổi phần TÀI LIỆU KHẢO mềm Ngô Trung Việt, Kỹ nghệ phần mềm - dịch, Nhà xuất Giáo dục, 1999 Lê Đức Trung, Công nghệ phần mềm, Nhà xuất Khoa học Kỹ thuật, 2002 Khoa Công nghệ Thông tin - Đại học Khoa học Tự nhiên Hà Nội, Bài giảng nhập môn công trình học phần mềm, Hà Nội, 1997 Roger S Pressman Ph.D, Software engineering a practitioner's - 7th, McGraw- Hill book Co.-Singapore, 2014 Sommerville I., Software engineering - 9th, Addison Wesley, 2015 149 ... MỀM (buổi 1) 63 7.1 Đặc điểm trình thiết kế phần mềm 63 7.2 Các hoạt động trình thiết kế phần mềm 65 7.3 Nền tảng thiết kế phần mềm 68 7.3.1 Trừu tượng (abstraction)... Bài 9: THIẾT KẾ PHẦN MỀM (buổi 2) 81 9.1 Thiết kế kiến trúc cho ứng dụng mô hình cho thiết kế ứng dụng 81 9.1.1 Thiết kế kiến trúc ứng dụng 81 9.1.2 Các mô hình thiết kế ứng... lập trình Kỹ sư phần mềm: Một kỹ sư phần mềm thực chức nhà phân tích, nhà thiết kế lập trình viên Các phân tích gia trình độ đại học luôn tham gia vào tổ chức có cấp độ IS để lập kế hoạch nghiên