NHẬP MÔN CÔNG NGHỆ PHẦN MỀM

NGUYỄN THẾ DŨNG NHẬP MÔN CÔNG NGHỆ PHẦN MỀM Trƣờng Đại học Sƣ phạm - Đại học Huế Huế, tháng 11 năm 2014 Giáo trình viết Nguyễn Thế Dũng, giảng viên Khoa Tin học, Trường Đại học Sư phạm Đại học Huế Giáo trình dùng để giảng dạy học tập học phần: Nhập môn Công nghệ phần mềm Mã số: TINS4392 Lời nói đầu Nhập mơn Cơng nghệ phần mềm mơn học bắt buộc khung chương trình hầu hết sinh viên ngành Sư phạm Tin học Hiện có nhiều tài liệu mơn học Tuy chúng phần lớn trình bày dạng sách chuyên khảo, sinh viên khó khăn việc học mơn Bên cạnh với đặc thù sinh viên ngành Sư phạm, nên việc học tập mơn học mang nặng tính lý thuyết sinh viên Ngay từ đầu giáo trình, chúng tơi đưa mục tiêu tóm tắt nội dung học phần mà khung chương trình quy định để làm rõ mục đích cần đạt học mơn học sinh viên Sư phạm Tin học so với sinh viên ngành chuyên Công nghệ phần mềm Cuối chương mục, đưa vào phần ôn tập chương câu hỏi tập nhằm giúp sinh viên dễ học tập có nhìn rộng thực tiễn hay vấn đề mở mà giáo trình chưa đề cập đến giới hạn khn khổ Do khung chương trình, phần quản lý dự án phần mềm tách riêng thành học phần gồm tín chỉ, nên giáo trình khơng bao gồm phần thường thấy số giáo trình khác Giáo trình chia thành chương Chương Tổng quan công nghệ phần mềm; Chương Qui trình phát triển phần mềm; Chương Phân tích đặc tả yêu cầu; Chương Thiết kế; Chương Lập trình; Chương Kiểm thử; Chương Triển khai bảo trì Trong trình biên soạn giáo trình này, chúng tơi có tham khảo số tài liệu số tác giả khác nhằm mang lại kiến thức phong phú, phù hợp cho sinh viên, chưa kịp liên hệ với tác giả Mong Thầy, học sinh viên mà niệm tình bỏ Tác giả chân thành cảm ơn thầy cô Hà Viết Hải, Lê Văn Tường Lân, Nguyễn Thị Hồng Anh… góp ý cho thảo tận tình Đồng thời xin chân thành cảm ơn quý Thầy Cô khác giúp đỡ nhiều Chúng gửi lời cảm ơn đến nhiều bạn sinh viên giúp sưu tầm tư liệu làm sở để hoàn thành giáo trình Giáo trình khơng tránh khỏi thiếu sót đặc biệt thiếu cập nhật thông tin mơn học có tính thời cơng nghệ Rất mong góp ý, đánh giá, nhận xét quý Thầy Cô, bạn Sinh viên… để giáo trình hồn thiện Xin chân thành cảm ơn Huế, ngày 10 tháng 09 năm 2014 Nguyễn Thế Dũng Khoa Tin học – ĐHSP Huế zungnguyen2003@yahoo.com http://sites.google.com/site/nguyenthedunghue/ Dưới trích dẫn mục tiêu tóm tắt nội dung học phần khung chương trình đào tạo giáo viên Tin học Trung học phổ thông Bộ Giáo dục Đào tạo ban hành năm 2007 Mục tiêu học phần NHẬP MÔN CÔNG NGHỆ PHẦN MỀM Giúp cho sinh viên nắm trình phát triển phần mềm cách hiệu quả, mang tính cơng nghiệp hiểu khái niệm thuộc lĩnh vực Trên sở sinh viên có định hướng đắn học tập nghiên cứu môn khác sâu vào nghiên cứu thực hành làm phần mềm Tóm tắt nội dung học phần NHẬP MƠN CƠNG NGHỆ PHẦN MỀM Nội dung mơn học bao gồm: quy trình xây dựng đánh giá phần mềm; vận dụng để xây dựng phần mềm cỡ nhỏ đáp ứng thực tế công việc đề án MỤC LỤC CHƢƠNG TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM 11 Một số khái niệm 11 Nhân tố người phân loại nghề nghiệp công nghệ phần mềm 17 Sản phẩm phần mềm – đặc trưng phân loại 25 Chƣơng QUI TRÌNH PHÁT TRIỂN PHẦN MỀM 31 Qui trình phát triển phần mềm 31 Mơ hình phát triển phần mềm 37 Trợ giúp tự động hoá phát triển 49 Chƣơng PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU 52 Đại cương phân tích đặc tả yêu cầu 52 Phân tích đặc tả yêu cầu 56 Ngun lý phân tích mơ hình hóa 69 Đặc tả yêu cầu 76 Thẩm định yêu cầu 78 Làm mẫu q trình phân tích 79 Định dạng đặc tả yêu cầu 82 Quản lý yêu cầu 84 Phân tích đặc tả yêu cầu theo mơ hình tiến trình hợp (Unified Process Model) 86 Chƣơng THIẾT KẾ 105 Khái niệm thiết kế phần mềm 105 Thiết kế hướng chức 116 Thiết kế kiến trúc 121 Thiết kế giao diện người dùng 130 Thiết kế thủ tục 135 Thiết kế hướng đối tượng 137 Chƣơng LẬP TRÌNH 153 Khái niệm 153 Ngơn ngữ lập trình 154 Phong cách lập trình 156 Kỹ thuật lập trình 158 Lập trình hướng hiệu thực 160 Chƣơng KIỂM THỬ 163 Đại cương kiểm thử phần mềm 163 Các mức độ kiểm thử 165 Các hoạt động kiểm thử 169 Chiến thuật kiểm thử phần mềm 171 Kỹ thuật kiểm thử 174 Kiểm thử hướng đối tượng 180 Chứng minh tốn học tính đắn chương trình 182 Chƣơng TRIỂN KHAI VÀ BẢO TRÌ 191 Triển khai phần mềm 191 Hiện thực triển khai phần mềm xây dựng theo mơ hình hướng đối tượng 195 Bảo trì 200 DANH MỤC BIỂU BẢNG Hình 1 Các thành phần phần mềm 12 Hình Kỹ nghệ phần mềm 15 Hình 2.1 Vịng đời phát triển hệ thống 31 Hình 2 Các giai đoạn sản phẩm giai đoạn tƣơng ứng 33 Hình Mơ hình thác nƣớc 39 Hình Mơ hình xoắn ốc 43 Hình Mơ hình tăng trƣởng 44 Hình Mơ hình RAD 46 Hình 2.7 Mơ hình phát triển dựa cấu phần 47 Hình Các hoạt động phân tích đặc tả yêu cầu 57 Hình Qui trình xác định yêu cầu 60 Hình 3 Mơ hình xoắn ốc qui trình xác định yêu cầu 61 Hình Qui trình nắm bắt yêu cầu 65 Hình Các mơ hình bƣớc mơ hình hóa u cầu 71 Hình Ký pháp DFD 72 Hình Tiến trình phân tích thiết kế hƣớng đối tƣợng 87 Hình Mơ hình use-case cho toán quản lý học tập trung tâm 94 Hình Các hoạt động thiết kế phần mềm 108 Hình Hoạt động thiết kế sản phẩm tƣơng ứng 108 Hình Số lƣợng module chi phí tích hợp module 119 Hình 4 Mơ hình kiến trúc liệu tập trung 122 Hình Kiến trúc khách dịch vụ (Client-Server Architecture) 123 Hình Mơ hình kiến trúc phân tầng 124 Hình Kiến trúc gọi trả lại 125 Hình Mơ hình điều khiển quảng bá 126 Hình Mơ hình điều khiển hƣớng ngắt 126 Hình 10 Tạo kiến trúc từ biểu đồ DFD 127 Hình 11 Phân hoạch dọc kiến trúc 128 Hình 12 Phân hoạch ngang kiến trúc 128 Hình 13 Chuyển đổi luồng chuyển đổi 129 Hình 14 Chuyển đổi luồng giao dịch 130 Hình 15 Các bƣớc thực thiết kế giao diện 131 Hình Các mức độ kiểm thử 166 Hình Mơ hình chữ V 166 Hình Các hoạt động kiểm thử 169 Hình Mơ hình chữ V 172 Hình Ký hiệu thành phần 196 Hình Quan hệ liên kết node 199 Hình Qui trình quản lý bảo trì 203 Hình Các hoạt động bảo trì 205 Bảng Các giai đoạn kiểm thử công việc tƣơng ứng 167 Bảng Bảng thống kê chi phí cho trình bảo trì (nguồn [8]) 206 Bảng Các độ đo đƣợc sử dụng bảo trì 209 BẢNG ĐỐI CHIẾU THUẬT NGỮ VIỆT – ANH Phần mềm Software Kỹ thuật hệ thứ Fourth generation technique Phần cứng Hardware Bàn thợ Workbenches Công nghệ phần Software mềm Technology Đo điểm chuẩn Benchmarking Kỹ nghệ mềm Phương pháp Joint phát triển ứng dụng Application Design phần Software Engineering CASE Computer-Aided Software Engineering Sơ đồ phân rã chức Function Decomposition Diagram Đặc tả yêu cầu Software phần mềm Requirement Specification Mơ hình tiến trình Unified Process hợp Model Bảo trì Maintenance Luồng giao dịch Transaction Flow Thiết kế kiến trúc Architectural Design Mẫu hình thức Stereotype Cài đặt Implementation Kiểm thử Testing Dò mã Code browser Triển khai phần Software mềm Deployment 10 Mỗi Node có nhiều component Kết nối node Chúng ta cần quan hệ liên kết node để mô tả cấu hình kết nối Ví dụ : Hình Quan hệ liên kết node • Component Instance Mỗi Component Instance thể component (trong component diagram) cài đặt Node Thuộc tính Component Instance gồm: số thành phần (Cardinality); thành phần (Component) • Quan hệ thành phần gồm: Quan hệ Node Node Quan hệ Node Component Instance Quan hệ Component Instance Component Instance • Các loại quan hệ gồm: Kết hợp Node (Node Association); quan hệ phụ thuộc (Dependency) 199 Ví dụ: Dưới biểu đồ triển khai, mơ tả hệ thống quản lý thời khóa biểu Hiện thực triển khai tập trung vào xây dựng thành phần chạy thư viện, module mã nguồn, trang HTML, Các thành phần mã nguồn cụ thể hố số lớp thiết kế viết ngơn ngữ lập trình khác Cuối triển khai thành phần chạy thiết bị tính tốn Bảo trì 3.1 Khái niệm bảo trì Quy trình phát triển phần mềm có nhiều giai đoạn, bảo trì (Maintenance) giai đoạn cuối vòng đời hệ thống phần mềm Bảo trì nhằm nâng cấp tính phần mềm, làm cho phần mềm hoạt động an toàn Bảo trì phần mềm thay đổi sản phẩm phần mềm nhằm sửa lỗi, cải thiện hiệu suất thuộc tính khác nhằm giúp phần mềm thích ứng với mơi trường Một câu hỏi đặt cần bảo trì phần mềm? thường có: - Bảo trì định kì 200 - Bảo trì gặp cố, hay đối tác thay đổi yêu cầu phần mềm - Sửa đổi (Fixing) + Làm đúng: xác định loại bỏ lỗi + Thích nghi: sửa đổi để đáp ứng thay đổi hệ điều hành, phần cứng, hệ quản trị sở liệu - Nâng cấp (Enhancing) + Hoàn thiện: thay đổi đáp ứng yêu cầu người dùng + Ngăn ngừa: thay đổi để nâng cao tính thích nghi phần mềm Có thể khái quát lên thành hình thái bảo trì sau: – Tu chỉnh – Thích hợp – Cải tiến – Phịng ngừa Bảo trì để tu chỉnh bảo trì khắc phục khiếm khuyết có phần mềm Do số nguyên nhân điển hình sau: – Kỹ sư phần mềm khách hiểu nhầm – Lỗi tiềm ẩn phần mềm sơ ý lập trình viên kiểm thử chưa bao quát hết – Vấn đề tính phần mềm: khơng đáp ứng yêu cầu nhớ, tệp, thiết kế sai, biên tập sai – Thiếu chuẩn hóa phát triển phần mềm (trước đó) Một số khuyết điểm thường gặp:  Lỗi thiết kế  Lỗi logic  Lỗi mã hóa (Coding)  Một số khuyết điểm xảy lỗi xử lý liệu lỗi hoạt động hệ thống 201 Lỗi thiết kế xuất thay đổi, cập nhật làm cho phần mềm hoạt động khơng cịn xác, khơng đầy đủ, truyền đạt sai hay yêu cầu thay đổi bị hiểu sai Lỗi logic cho việc kiểm thử sai đưa kết luận sai, thực không theo thiết kế chi tiết kỹ thuật liệu không kiểm tra đầy đủ Lỗi mã hóa người mã hóa thực không quy tắc chi tiết thiết kế không tuân thủ theo quy tắc logic mã nguồn Bảo trì để thích hợp tu chỉnh phần mềm theo thay đổi mơi trường bên ngồi nhằm trì quản lý phần mềm theo vịng đời Thay đổi phần mềm thích nghi với mơi trường công nghệ phần cứng, môi trường phần mềm Những nguyên nhân thay đổi là: - Thay đổi phần cứng (ngoại vi, máy chủ, .) - Thay đổi phần mềm (môi trường) thay đổi hệ điều hành - Thay đổi cấu trúc tệp mở rộng sở liệu Môi trường đề cập đến tất ảnh hưởng, hành động thay đổi bên làm cho biến phần mềm khơng cịn xác như: Quy tắc kinh doanh, sách phủ, mơ hình làm việc… Ví dụ: Chính phủ có tác động đến sách tiền tệ, ngân hàng phải thay đổi hệ thống để phù hợp với loại tiền tệ Bảo trì để cải tiến việc tu chỉnh hệ phần mềm theo yêu cầu ngày hoàn thiện hơn, đầy đủ hơn, hợp lý Những nguyên nhân chính: - Do muốn nâng cao hiệu suất nên thường hay cải tiến số phương thức - Mở rộng thêm chức cho hệ thống - Cải tiến quản lý kéo theo cải tiến tư liệu vận hành trình tự cơng việc - Thay đổi người dùng thay đổi thao tác 202 Có thể nói bảo trì để cải tiến quan tâm đến việc cải tiến chức hoạt động để tăng hiệu suất hệ thống tăng cường giao diện người dùng Bảo trì để phịng ngừa cơng việc tu chỉnh chương trình có tính đến tương lai phần mềm mở rộng thay đổi Với loại bảo trì này, quan tâm tới hoạt động nhằm tăng cường khả bảo trì hệ thống cập nhật tài liệu, giấy tờ, ghi hay cải thiện cấu trúc hệ thống Thực thiết kế phần mềm phải tính đến tính mở rộng nó, nên thực tế ta gặp bảo trì phịng ngừa phần mềm thiết kế tốt 3.2 Quy trình chung trình quản lý bảo trì phần mềm - Khách hàng thay đổi yêu cầu phần mềm - Bên chịu trách nhiệm bảo trì chuyển thành yêu cầu bảo trì (Maintenance Request) chuyển cho người quản lí q trình bảo trì (Maintenance manager) - Bộ phận quản lý bảo trì chấp nhận việc bảo trì chuyển tài liệu mã nguồn (source code) cho lập trình viên - Lập trình viên chỉnh sửa tài liệu mã nguồn cho phù hợp với yêu cầu mới, sau chuyển ngược lại cho phận quản lý bảo trì giao cho khách hàng Hình Qui trình quản lý bảo trì 203 Để đáp ứng yêu cầu bảo trì (Maintance Request) cần thực công việc sau: Chuẩn bị loại độ đo như: số dòng lệnh thêm vào hay bị thay đổi, thời gian thực bảo trì, Đảm bảo yêu cầu chấp nhận Hiểu kĩ vấn đề đặt để bảo trì Phân loại yêu cầu: sửa đổi hay nâng cấp Quyết định xem có cần thiết kế lại mức cao hay khơng Thiết kế sửa đổi yêu cầu Kế hoạch chuyển đổi từ thiết kế cũ Đánh giá ảnh hưởng việc sửa đổi lên ứng dụng Triển khai sửa đổi 10 Thực kiểm thử đơn vị cho phần thay đổi 11 Tiến hành kiểm thử tăng dần (regression) 12 Thực kiểm thử hệ thống với khả 13 Cập nhật tài liệu cấu hình, yêu cầu, thiết kế kiểm thử Trong trình bảo trì thường xảy khía cạnh mặt quản lý thường khó xác định thu hồi vốn Xét mặt tiến trình, cần phối hợp mở rộng để đáp ứng yêu cầu bảo trì mở rộng Ở góc độ kỹ thuật cần kiểm sốt tất ảnh hưởng thay đổi thường chi phí cho việc kiểm thử bảo trì lớn 3.3 Hoạt động bảo trì Những hoạt động bảo trì phần mềm: Quá trình bảo trì phần mềm bao hàm cơng việc q trình phát triển phần mềm: phân tích, thiết kế, lập trình, kiểm thử, tài liệu hóa Ngồi ra, có hoạt động khác đặc thù có bảo trì: Transition: chuỗi hoạt động quản lý đặt mà phần mềm chuyển tiếp từ người phát triển (developer) đến người bảo trì phần mềm (maintainer) 204 Chấp nhận hay từ chối yêu cầu sửa đổi (Modification Request acceptance/rejection): dựa vào thơng số kích thước, khả thực độ phức tạp yêu cầu thay đổi, trình bảo trì từ chối hay chấp nhận yêu cầu thay đổi Modification Request and Problem Report Help Desk: chức hỗ trợ người dùng cuối việc đánh giá độ ưu tiên, xác định chi phí chuyển hướng yêu cầu họ nhận Service Level Agreements: Thực thỏa thuận ghi hợp đồng bảo trì mức độ bảo trì Dưới hình ảnh tóm lược tiến trình hoạt động bảo trì, bao gồm: - Thiết kế để bảo trì - Xác định phạm vi bảo trì - Xác định loại bảo trì - Phát triển kế hoạch bảo trì - Đánh giá chi phí - Thực bảo trì Hình Các hoạt động bảo trì 3.4 Chi phí bảo trì 205 Theo thống kê ngành công nghiệp phần mềm cho thấy chi phí bảo trì ngày tăng cao nhiều so với chi phí phát triển phần mềm Bảng Bảng thống kê chi phí cho trình bảo trì (nguồn [8]) Hoạt động Hiểu yêu cầu xác định chức cần sửa đổi hay thêm vào Thay đổi thiết kế Phân tích ảnh hưởng trình diễn Triển khai thay đổi thành mã nguồn Thay đổi thông tin cấu hình Đánh giá (persondays) 2-5 1–4 1–4 1-4 2–6 Hoạt động Đánh giá (person-days) Dịch tích hợp 2-3 Kiểm thử chức thay đổi Kiểm thử trình diễn 2-4 Đưa báo cáo kết Tổng kết 2–4 14 - 35 3.5 Kỹ thuật bảo trì Chúng ta quan tâm đến hai loại hình bảo trì là: + Bảo trì có tái kỹ nghệ + Bảo trì khơng tái kỹ nghệ Các lựa chọn đưa không tiếp tục bảo trì: Thay • Mua thay • Xây dựng thay (tái kỹ nghệ, phát triển kiến trúc mới, thay pha) Phối hợp: hệ thống cũ phần tích hợp hệ thống Bao gói: hệ thống cũ sử dụng server cho hệ thống Những kĩ thuật bảo trì phầm mềm, gồm: 3.5.1 Hiểu chƣơng trình (Program Comprehension) 206 Lập trình viên dành thời gian thích đáng cho việc đọc hiểu chương trình để thực thi thay đổi lên chương trình Sử dụng công cụ “code browser” Tài liệu đặc tả rõ ràng súc tích giúp nhiều cho việc hiểu chương trình 3.5.2 Reverse engineering Reverse engineering hiểu q trình phân tích hệ thống để xác định thành phần liên quan hệ thống mối liên hệ chúng nhằm tạo thể hệ thống dạng khác hay cấp độ trừu tượng cao Khả kĩ thuật phác thảo luồng đồ thị xử lý chương trình từ mã nguồn 3.5.3 Tái kỹ nghệ (Re-engineering) Tái kỹ nghệ (Re-engineering) q trình gồm vịng xoắn ốc có sáu hoạt động sau đây: Phân tích tổng quát (Inventory analysis); Tái cấu trúc tư liệu (Document restructuring); Reverse engineering; Tái cấu trúc mã (Code restructuring); Tái cấu trúc liệu (Data restructuring) Tiến triển công nghệ (Forward engineering) Có thể xem tái kỹ nghệ (Re-engineering) xem xét thay đổi phần mềm để tái thiết dạng Bao gồm thực thi với định dạng Q trình có liên quan đến việc hệ thống kế thừa (legacy) có phải làm dễ bảo trì 3.6 Mơ hình quy trình bảo trì phần mềm Mơ hình quy trình bảo trì phần mềm cịn gọi quy trình thay đổi yêu cầu mềm (Software Change Request) Theo tiêu chuẩn IEEE 1219-98, ta có mơ hình bao gồm giai đoạn sau : Modification Request: yêu cầu thay đổi xuất phát từ nhiều lý (xuất lỗi, môi trường để hệ thống thực thi thay đổi, người dùng cần thêm tính năng, …) 207 Classification & Identification: phân loại yêu cầu thay đổi sửa chữa (repair) nâng cấp (enhancement) xác định rõ thay đổi cần thực Analysis: phân tích thay đổi, ảnh hưởng thay đổi lên hệ thống cũ (chú ý: thay đổi nhỏ ảnh hưởng tồn hệ thống) Design: thiết kế cho phù hợp thay đổi Implementation: thực thay đổi source code System Test: thực việc kiểm thử lại chức thay đổi, kiểm thử hồi quy toàn hệ thống Acceptance Test: thực kiểm thử để phân phối cho khách hàng Delivery: phân phối Với chuẩn ISO/IEC 14764-00, có mơ hình sau: Process Implementation: + Phát triển kế hoạch bảo trì + Thiết lập thủ tục cho yêu cầu thay đổi + Thực thi quy trình quản lý tinh chỉnh phần mềm Problem and Modification Analysis: + Xây dựng bước đầu việc phân tích + Kiểm tra vấn đề + Phát triển tùy chọn cho việc thực thi thay đổi + Tài liệu hóa kết + Chấp thuận cho tùy chọn chỉnh sửa Modification Implementation: + Thực phân tích chi tiết + Phát triển code thực test thay đổi Maintenance Review/Acceptance: + Tiến hành xem xét lại 208 + Chấp thuận chỉnh sửa 3.7 Lƣợng hóa Các độ đo sử dụng bảo trì + Số dịng lệnh + Chi phí người-tháng để thực hoạt động bảo trì + Số lỗi Bảng Các độ đo đƣợc sử dụng bảo trì Mục tiêu Câu hỏi Độ đo đƣợc lựa chọn (theo IEEE) Có vấn đề ảnh Mật độ lỗi hưởng khách hàng? Thời gian trung bình xảy lỗi Tỷ lệ số lỗi phát hiện/số lỗi sửa qua bảo trì Thỏa mãn tối đa khách hàng Thời gian để thay đổi Kết thúc sửa lỗi vấn đề? Thời gian trung bình yêu cầu để sửa lỗi Khoảng thời gian sửa lỗi Thời gian trung bình để sửa lỗi Chỗ mấu chốt? Hiệu suất sửa lỗi nhân viên Trung bình người-tháng để phát hiện/sửa chữa lỗi Hiệu máy tính Thời gian trung bình (CPU) lỗi Tối ưu hóa Tài ngun sử dụng + Nỗ lực thời gian tiêu tốn cho lỗi chi phí đâu? lịch trình + Nỗ lực thời gian tiêu tốn cho 209 việc lập kế hoạch + Nỗ lực thời gian tiêu tốn cho đòi hỏi thêm khách hàng + Nỗ lực thời gian tiêu tốn cho báo cáo lỗi + Nỗ lực thời gian tiêu tốn cho sửa chữa + Nỗ lực thời gian tiêu tốn cho nâng cấp Tối thiểu Lỗi phát chủ • Số đầu vào đầu hóa số lỗi yếu đâu? module • Độ phức tạp 3.8 Một số hiệu ứng lề công việc bảo trì (xem [10]) Sửa đổi phần mềm cơng việc dễ dẫn đến hiệu ứng lề không mong đợi, ta thường gặp ba loại hiệu ứng lề sau: 3.8.1 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 210 - Các thay đổi ảnh hưởng đến việc chạy thử trường hợp biên 3.8.2 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 cịn phù hợp với liệu lỗi có khả xảy 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 3.8.3 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ẽ 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 giảm tồ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 u cầu bảo hành địi hỏi khơng thay đổi thiết kế phần mềm 211 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 TỔNG KẾT Các vấn đề phương án triển khai, đóng gói sản phẩm, lập tài liệu hướng dẫn Các biểu đồ triển khai trình thực triển khai phần mềm thực theo mơ hình hướng đối tượng đưa Các qui trình, loại hình bảo trì, hoạt động bảo trì, chi phí bảo trì hiệu ứng lề … chuẩn trình bảo trì đề cập Các vấn đề quản lý cấu hình thay đổi phần mềm cần quan tâm trình bày mơn học Quản lý dự án phần mềm Lời kết sách Trước thực tập cuối sách, xin có lời để kết lại sách Hy vọng học môn học Công nhệ phần mềm, bạn không nghĩ tựa học nghề … mổ thịt rồng! Câu hỏi tập Tích hợp? Lập kế hoạch tích hợp? Các nhân tố ảnh hưởng trình tự tích hợp? Quan hệ chi phí tích hợp chi phí module? Chuyển giao phần mềm? Các hoạt động chuyển giao phần mềm? Bảo trì phần mềm gì? Hoạt động bảo trì phần mềm yếu? Trình bày chuẩn IEEE 840-1992 bảo trì? Các khó khăn hoạt động bảo trì ? Các độ đo sử dụng hoạt động bảo trì ? 10 Tìm hiểu việc lập hồ sơ bảo trì theo chuẩn IEEE 840-1992 tìm kiếm hồ sơ mẫu cho bảo trì mạng Internet 11 Trình bày hiệu ứng lề bảo trì 12 Tìm hiểu thêm cách tính chi phí cho bảo trì 212 TÀI LIỆU THAM KHẢO [1] Nguyễn Văn Vỵ, Nguyễn Việt Hà, Giáo trình kỹ nghệ phần mềm, NXB Đại học quốc gia Hà Nội, 2008 [2] Nguyễn Văn Vỵ, Phân tích thiết kế hệ thống thơng tin đại, Hướng cấu trúc hướng đối tượng, NXB Thống kê, 2002 [3] Ngô Trung Việt, Nhập môn Kỹ nghệ phần mềm, NXB Khoa học Kỹ thuật, 2003 [4] Eric S Raymond, The Art of Unix Programming, 2003 [5] Mike Gancarz, The Unix Philosophy, Digital Press, 1994 [6] R Pressman, Software Engineering: A Practioner’s Approach 6th, Ed., McGraw-Hill, 2004 [7] Sommerville, Software Engineering 7th Ed., Addison-Wesley, 2004 [8] Nguyễn Ngọc Bình, Nhập mơn Kỹ nghệ phần mềm, ĐHCN – ĐHQG Hà Nội, 2010 [9] Khoa Công nghệ Thông tin, ĐHBK Thành phố Hồ Chí Minh, Bài giảng Cơng nghệ phần mềm, 2012 [10] Lê Văn Tường Lân, Công nghệ phần mềm, ĐHKH Huế, 2009 213 ... tả hệ th? ??ng th? ?nh hệ th? ??ng th? ??c thi Thiết kế nhằm th? ??c đặc tả th? ?nh cấu trúc phần mềm Cài đặt nhằm chuyển cấu trúc th? ?nh chương trình th? ??c thi Thiết kế bao gồm: Đặc tả trừu tượng; Thiết kế đối... trợ th? ?c đẩy mạnh mẽ tiến công ngh? ??, khoa học kỹ thuật Một ngh? ?a phổ th? ?ng khác từ “công nghiệp” "hoạt động kinh tế quy mơ lớn, sản phẩm (có th? ?? phi vật th? ??) tạo trở th? ?nh hàng hóa" Theo ngh? ?a... đối tượng liệu; Thiết kế hệ 34 th? ??ng; Thiết kế kiến trúc; Thiết kế giao diện; Thiết kế th? ?nh phần; Thiết kế cấu trúc liệu; Thiết kế giải thuật… Lập trình giai đoạn chuyển thiết kế th? ?nh chương trình,