Giáo trình Nhập môn công nghệ phần mềm giúp cho sinh viên nắm được quá trình phát triển một phần mềm một cách hiệu quả, mang tính công nghiệp và hiểu được những khái niệm cơ bản thuộc lĩnh vực này. Trên cơ sở đó sinh viên có định hướng đúng đắn khi học tập nghiên cứu các môn khác cũng như đi sâu vào nghiên cứu và thực hành làm phần mềm. Mời các bạn cùng tham khảo nội dung phần 2 giáo trình.
Chƣơng THIẾT KẾ Mục đích Trình bày q trình thiết kế phần mềm, thiết kế kiến trúc, thiết kế giao diện Bên cạnh q trình thiết kế phần mềm theo phương pháp hướng đối tượng trình bày Yêu cầu + Biết hoạt động thiết kế sản phẩm + Hiểu nguyên lý thiết kế + Hiểu nguyên tắc thiết kế giao diện + Vận dụng vào môn Phân tích thiết kế hệ thống Cũng phần phân tích đặc tả yêu cầu, phần không tách riêng phần thiết kế theo phương pháp hướng đối tượng thành chương giáo trình mà đưa vào thành mục chương Tuy mục dài không làm cho bố cục giáo trình cồng kềnh Khái niệm thiết kế phần mềm 1.1.Khái niệm Có thể định nghĩa thiết kế trình áp dụng kỹ thuật nguyên lý để tạo mô hình thiết bị, tiến trình hay hệ thống đủ chi tiết mà theo chế tạo sản phẩm vật lý tương ứng với Trong phân tích nhằm trả lời câu hỏi vấn đề (What?), thiết kế nhằm trả lời câu hỏi làm (How to do?) Bản chất thiết kế phần mềm trình chuyển hóa yêu cầu phần mềm thành biểu diễn thiết kế Từ mô tả quan niệm tồn phần mềm, việc làm mịn (chi tiết hóa) liên tục dẫn tới biểu diễn thiết kế gần với cách biểu diễn chương trình nguồn để ánh xạ vào ngơn ngữ lập trình cụ thể 102 1.2 Tầm quan trọng 1.2.1 Vai trò Tạo mơ hình cài đặt phần mềm, phương tiện trao đổi thông tin để đảm bảo chất lượng Tầm quan trọng thiết kế phần mềm phát biểu từ “chất lượng” Thiết kế nơi chất lượng phần mềm nuôi dưỡng trình phát triển: cung cấp cách biểu diễn phần mềm xác nhận chất lượng, cách mà chuyển hóa cách xác yêu cầu khách hàng thành sản phẩm hay hệ thống phần mềm cuối Thiết kế phần mềm công cụ giao tiếp làm sở để mơ tả cách đầy đủ dịch vụ hệ thống, để quản lý rủi ro lựa chọn giải pháp thích hợp Thiết kế phần mềm phục vụ tảng cho bước kỹ nghệ phần mềm bảo trì: - Khơng có thiết kế có nguy sản sinh hệ thống không ổn định - hệ thống thất bại Một hệ thống phần mềm khó xác định chất lượng chừng chưa đến bước kiểm thử Thiết kế tốt bước quan trọng để đảm bảo chất lượng phần mềm 1.2.2 Thiết kế chất lƣợng • Thiết kế phải thỏa yêu cầu tường minh ngầm định • Thiết kế phải dễ hiểu, dễ đọc hỗ trợcho việc tạo code, test hỗ trợ phần mềm • Thiết kế phải cung cấp hình ảnh đầy đủ phần mềm, xác định liệu, chức hành vi Nếu khơng có thiết kế; thiết kế tồi dẫn đến: làm tăng cơng sức mã hóa tăng cơng sức bảo trì 1.3 Quá trình thiết kế Thiết kế phần mềm trình chuyển đặc tả yêu cầu dịch vụ thông tin hệ thống thành đặc tả hệ thống phần mềm Thiết kế phần mềm trải qua số giai đoạn sau: 103 Nghiên cứu để hiểu vấn đề Không hiểu rõ vấn đề khơng thể có thiết kế hữu hiệu Chọn (hay số) giải pháp thiết kế xác định đặc điểm thơ nó.Chọn giải pháp phụ thuộc vào kinh nghiệm người thiết kế, vào cấu kiện dùng lại vào đơn giản giải pháp kéo theo Nếu nhân tố khác tương tự nên chọn giải pháp đơn giản Mô tả trừu tượng cho nội dung giải pháp Trước tạo tư liệu thức người thiết kế cần phải xây dựng mô tả ban đầu sơ khai chi tiết hóa Các sai sót khiếm khuyết mức thiết kế trước phát phải chỉnh sửa trước lập tư liệu thiết kế Kết hoạt động thiết kế đặc tả thiết kế Đặc tả đặc tả trừu tượng, hình thức tạo để làm rõ yêu cầu, đặc tả phần hệ thống phải thực Khi trình thiết kế tiến triển chi tiết bổ sung vào đặc tả Các kết cuối đặc tả thuật toán cấu trúc liệu dùng làm sở cho việc thực hệ thống 1.4 Các hoạt động thiết kế phần mềm Các nội dung thiết kế là: - Thiết kế kiến trúc: Xác định hệ tổng thể phần mềm bao gồm hệ quan hệ chúng ghi thành tài liệu - Đặc tả trừu tượng: đặc tả trừu tượng cho hệ dịch vụ mà cung cấp ràng buộc chúng phải tuân thủ - Thiết kế giao diện: giao diện hệ với hệ khác thiết kế ghi thành tài liệu; đặc tả giao diện không mơ hồ cho phép sử dụng hệ mà khơng cần biết thiết kế nội - Thiết kế thành phần: dịch vụ mà hệ cung cấp phân chia cho thành phần hợp thành - Thiết kế liệu: thiết kế chi tiết đặc tả cấu trúc liệu (các mô hình giới thực cần xử lý) dùng việc thực hệ thống - Thiết kế thuật toán: thuật toán dùng cho dịch vụ thiết kế chi tiết đặc tả 104 Quá trình lặp lại thành phần hợp thành hệ xác định ánh xạ trực tiếp vào thành phần ngơn ngữ lập trình, chẳng hạn gói, thủ tục hàm Hình 4.1 Các hoạt động thiết kế phần mềm Hình 4.2 Hoạt động thiết kế sản phẩm tƣơng ứng Các vấn đề liên quan đến thiết kế liệu thiết kế thuật toán đề cập kỹ lưỡng môn học Nhập môn sở liệu mơn học Phân tích thiết kế thuật tốn, nên thường giáo trình mơn học Cơng 105 nghệ phần mềm không sâu vào phần vừa nói trên, mà vào hoạt động thiết kế thiết kế kiến trúc thiết kế giao diện… 1.5 Mô tả thiết kế Một thiết kế phần mềm mơ hình mơ tả đối tượng giới thực có nhiều thành phần mối quan hệ chúng với Việc mô tả thiết kế cần đảm bảo thực yêu cầu: - Làm sở cho việc triển khai chương trình - Làm phương tiện giao tiếp nhóm thiết kế hệ - Cung cấp đủ thơng tin cho người bảo trì hệ thống Thiết kế thường mô tả hai mức: thiết kế mức cao (high level design) thiết kế chi tiết (low level design) Thiết kế mức cao hay thiết kế kiến trúc ra: - Mơ hình tổng thể hệ thống - Cách thức hệ thống phân rã thành module - Mối quan hệ (gọi thực lẫn nhau) module - Cách thức trao đổi thông tin module (giao diện, liệu dùng chung, thông tin trạng thái) Tuy nhiên thiết kế mức cao không thứ tự thực hiện, số lần thực module, trạng thái hoạt động bên module Nội dung module thể mức thiết kế chi tiết Các cấu trúc sở thiết kế chi tiết hay gọi thiết kế thuật toán là: - Cấu trúc - Cấu trúc rẽ nhánh - Cấu trúc lặp Mọi thuật toán mơ tả dựa cấu trúc Có ba loại hình mơ tả thường sử dụng thiết kế: - Dạng văn phi hình thức: Mô tả ngôn ngữ tự nhiên thông tin khơng thể hình thức hóa thơng tin phi chức Bên cạnh cách 106 mô tả khác, mô tả văn thường bổ sung để làm cho thiết kế đầy đủ dễ hiểu - Các biểu đồ: Các biểu đồ dùng để thể mối quan hệ thành phần lập lên hệ thống mơ hình mô tả giới thực Việc mô tả đồ thị thiết kế có lợi tính trực quan cho tranh tổng thể hệ thống Trong thời gian gần đây, người ta xây dựng ngôn ngữ đồ thị dành riêng cho thiết kế phần mềm với tên gọi: ngôn ngữ mơ hình hóa thống (Unified Modeling Model - UML) Tại mức thiết kế chi tiết, có số dạng biểu đồ hay sử dụng flow chart, JSP, Nassi-Shneiderman diagrams - Giả mã (pseudo code): Hiện nay, giả mã công cụ được-a chuộng để mô tả thiết kế mức chi tiết Các ngôn ngữ thuận tiện cho việc mơ tả xác thiết kế, nhiên lại thiếu tính trực quan Dưới ví dụ sử dụng giả mã: Procedure Write Name if sex = male write "Mr." else write "Ms." endif write name end Procedure Nói chung ba loại biểu diễn sử dụng thiết kế hệ thống Thiết kế kiến trúc thường mô tả đồ thị (structure chart) bổ sung văn phi hình thức, thiết kế liệu lôgic thường mô tả bảng, thiết kế giao diện, thiết kế cấu trúc liệu chi tiết, thiết kế thuật tốn thường mơ tả mã giả (pseudo code) 1.6 Nguyên lý thiết kế Thiết kế khơng bị bó buộc vào cách nhìn hạn chế nào, cần lựa chọn từ giải pháp 107 Cho phép lần ngược lại mơ hình phân tích • Các module yêu cầu không thiết phải tương ứng 1-1, phải kiểm tra thỏa mãn yêu cầu Không nên tạo lại thiết kế (giải pháp) có, mà cần tái sử dụng tối đa chúng Mơ hình thiết kế (giải pháp) nên tiến gần đến mơ hình giới thực (bài tốn) Biểu diễn thiết kế phải qn có tính tích hợp: • + Thiết kế nhiều người tiến hành song song + Phải thống cách biểu diễn, thống giao diện Thiết kế cần có cấu trúc để dễ hiểu, dễ thay đổi, tức phải module hóa, phân cấp Thiết kế khơng phải mã hóa, thiết kế ln có mức trừu tượng mã hóa, để đảm bảo dễ hiểu, dễ thay đổi Thiết kế cần đánh giá chất lượng tạo ra, thể qua tính kết dính, tính ghép nối, hiệu thuật tốn… Thiết kế cần thẩm định để tránh lỗi mang tính hệ thống thiếu chức năng, chức không rõ, mâu thuẫn 1.7 Chất lƣợng thiết kế Khơng có cách hay để xác định thiết kế tốt Tiêu chuẩn dễ bảo trì tiêu chuẩn tốt cho người dùng Một thiết kế dễ bảo trì thích nghi với việc cải biên chức việc thêm chức Một thiết kế phải dễ hiểu việc sửa đổi có hiệu ứng cục Các thành phần thiết kế phải kết dính (cohesive) theo nghĩa tất phận thành phần phải có quan hệ logic chặt chẽ, thành phần ghép nối (coupling) với lỏng lẻo Ghép nối lỏng lẻo dễ thích nghi, nghĩa dễ sửa đổi để phù hợp với hoàn cảnh Tiêu chí chất lƣợng Cần thiết lập tiêu chí kỹ thuật để đánh giá thiết kế tốt hay khơng: 108 + Thiết kế cần có kiến trúc tốt: cấu thành từ mẫu (pattern), thành phần có đặc trưng tốt, dễ tiến hoá + Thiết kế mơđul hố cho thành phần chức + Chứa biểu diễn tách biệt về: liệu, kiến trúc, giao diện, thành phần, môi trường + Liên kết qua giao diện làm giảm độ phức tạp liên kết môđul với hệ thống mơi trường Để xem thiết kế có tốt hay không, người ta tiến hành thiết lập số độ đo chất lượng thiết kế Một số độ đo: •- Cohesion: mức độ liên kết thành phần module •- Coupling: mức độ ghép nối module - Understandability: tính hiểu •- Adaptability: tính thích nghi 1) Sự kết dính (Cohesion) Sự kết dính module độ đo tính khớp lại với phần module Nếu module thực chức logic thực thể logic, tức tất phận module tham gia vào việc thực cơng việc độ kết dính cao Nếu nhiều phận không tham gia trực tiếp vào việc chức logic mức độ kết dính thấp Thiết kế tốt độ kết dính cao Khi dễ dàng hiểu module việc sửa chữa module khơng (ít) ảnh hưởng tới module khác mức kết dính theo thứ tự tăng dần sau đây: a Kết dính gom góp: cơng việc khơng liên quan với nhau, song lại bị bó vào module b Kết dính logic: thành phần thực chức tương tự logic chẳng hạn vào/ra, xử lý lỗi, đặt vào module 109 c Kết dính thời điểm: tất thành phần hoạt hóa lúc, chẳng hạn thao tác khởi tạo bó lại với thành phần hoạt động thời điểm (ví dụ: hàm khởi tạo;đọc liệu, cấp phát nhớ ) d Kết dính thủ tục: phần tử module ghép lại dãy điều khiển Các thành phần thực hiên theo thứ tự xác định (ví dụ: tính lương bản, tính phụ cấp, tính bảo hiểm) e Kết dính truyền thơng: tất phần tử module thao tác liệu vào đưa liệu Các thành phần truy cập đến tập liệu:, chẳng hạn tính tốn thống kê (tính max, min, mean, varian ) f Kết dính tuần tự: module, đầu phần tử đầu vào phần tử khác Output thành phần input thành phần g Kết dính chức năng: Mỗi phần module cần thiết để thi hành chức Các thành phần góp phần thực chức Các lớp kết dính khơng định nghĩa chặt chẽ luôn xác định Một đối tượng kết dính thể thực thể đơn: tất phép tốn thực thể nằm thực thể Vậy xác định lớp kết dính là: h Kết dính đối tượng: phép tốn liên quan đến thay đổi, kiểm tra sử dụng thuộc tính đối tượng, sở cung cấp dịch vụ đối tượng 2) Sự ghép nối (Coupling) Ghép nối độ đo nối ghép với đơn vị (module) hệ thống Hệ thống có nối ghép cao module phụ thuộc lẫn lớn Hệ thống nối ghép lỏng lẻo module độc lập tương đối độc lập với dễ bảo trì Các module ghép nối chặt chẽ chúng dùng biến chung chúng trao đổi thông tin điều khiển (ghép nối chung ghép nối điều khiển) Ghép nối lỏng lẻo đạt bảo đảm thông tin cục che dấu module module trao đổi thông tin thông qua danh sách 110 tham số (giao diện) xác định Có thể chia ghép nối thành mức từ chặt chẽ đến lỏng lẻo sau: a Ghép nối nội dung: hai hay nhiều module dùng lẫn liệu nhau, mức xấu nhất, thường xẩy ngôn ngữ mức thấp dùng liệu toàn cục hay lạm dụng lệnh GOTO Ví dụ (ghép nối nội dung): 10 k =1 20 gosub 100 30 if y > 120 goto 60 40 k = k+1 50 goto 20 60 print k, y 70 stop 100 Y =3*k*k+7*k-3 110 return b Ghép nối chung: số module dùng biến chung, xẩy lỗi thao tác liệu, khó xác định lỗi module gây Ví dụ: (minh họa ghép nối chung) c Ghép nối điều khiển: module truyền thông tin điều khiển để điều khiển hoạt động module khác Ví dụ: Procedure PrintRec is begin Display Name (name, 111 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ụ : • 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) Ví dụ: Dưới lược đồ triển khai mô tả hệ thống quản lý thời khóa biểu 197 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ể hoá 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: Requirements Engineering, Architecting, Design, Implementation, Testing, Software Deployment, and Maintenance 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 tồ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ì 198 - 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 199 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 ngun 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 200 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 Như 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 7.1 Qui trình quản lý bảo trì 201 Để đá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 q 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 soá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ế, code, test, 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) 202 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, q 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 7.2 Các hoạt động bảo trì 3.4 Chi phí bảo trì 203 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 7.1 Bảng thống kê chi phí cho q 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) 204 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 Quá 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, …) 205 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 206 + 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 7.2 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 nguyên 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 207 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 tốn logic bị thay đổi - Việc thay đổi thiết kế chuyển thành thay đổi lớn chương trình 208 - 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 209 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 lược đồ 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ì 210 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 211 ... Mức độ hỗ trợ công cụ - Dễ dịch thiết kế sang chương trình, - Có trình biên dịch hiệu quả, - Khả chuyển chương trình gốc, - Dễ bảo trì + Miền ứng dụng ngơn ngữ ? ?- Lập trình hệ thống ? ?- Nghiệp vụ,... đoạn thực thi mức vật lý trình xây dựng phần mềm Tiến trình lập trình liên lạc thơng qua ngơn ngữ lập trình Lập trình bước cốt lõi tiến trình kỹ nghệ phần mềm Sản phẩm phần mềm tốt có phân tích... kế thuật toán đề cập kỹ lưỡng môn học Nhập môn sở liệu môn học Phân tích thiết kế thuật tốn, nên thường giáo trình mơn học Cơng 105 nghệ phần mềm khơng sâu vào phần vừa nói trên, mà vào hoạt