Mục đích của tài liệu Đề cương môn học 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 các kiến thức cơ bản về: nguyên tắc, phương pháp luận, quy trình và các kỹ thuật để xây dựng cũng như bảo trì các sản phẩm phần mềm.
TRƢỜNG ĐẠI HỌC SƢ PHẠM KỸ THUẬT HƢNG YÊN KHOA CƠNG NGHỆ THƠNG TIN ĐỀ CƢƠNG MƠN HỌC PHÂN TÍCH THIẾT KẾ PHẦN MỀM Trình độ đào tạo: Cao đẳng Ngàng đào tạo: Công nghệ Thông tin Hƣng Yên – Tháng năm 2011 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 LỜI MỞ ĐẦU MỤC LỤC CHƢƠNG 1: TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM 1.1 Một số khái niệm 1.2 Nhân tố người phân loại nghề nghiệp 10 1.2.1 Nhân tố người ngành công nghiệp phần mềm 10 1.2.2 Phân loại nghề nghiệp 10 1.3 Sản phẩm phần mềm – đặc tính phần loại 16 1.3.1 Các đặc tính phần mềm 17 1.3.2 Phân loại phần mềm 18 1.4 Một số mơ hình xây dựng phần mềm 21 1.4.1 Mơ hình tuyến tính (The linear sequential model) 21 1.4.2 Mơ hình mẫu (Prototyping model) 22 1.4.3 Mơ hình xoắn ốc (The spiral model) 23 1.4.4 Mơ hình thác nước 24 1.4.5 Mơ hình phát triển dựa thành phần 25 1.5 Phương pháp phát triển phần mềm 25 1.6 Vai trò người dùng giai đoạn phát triển phần mềm 26 1.7 Tiêu chuẩn sản phẩm phần mềm 27 1.7.1 Tính 27 1.7.2 Tính khoa học 28 1.7.3 Tính tin cậy 28 1.7.4 Tính kiểm thử 28 1.7.5 Tính hữu hiệu 28 1.7.6 Tính sáng tạo 28 1.7.7 Tính an tồn 29 1.7.8 Tính tồn vẹn 29 1.7.9 Tính đối xứng đầy đủ chức 29 1.7.10 Tính tiêu chuẩn tính chuẩn 29 1.7.11 Tính độc lập 30 1.7.12 Tính dễ phát triển, hoàn thiện 30 1.7.13 Một số tính chất khác 30 1.8 Quản lý dự án phần mềm 30 1.8.1 Các hoạt động chuẩn bị dự án 30 1.8.2 Lập kế hoạch dự án 31 1.8.3 Nghiên cứu tính khả thi dự án 32 1.8.4 Lựa chọn giải pháp 33 1.8.5 Giám sát kiểm soát 35 1.8.6 Quản lý nhân 40 1.9 Hồ sơ sản phẩm phần mềm 40 CHƢƠNG 2: KHẢO SÁT - PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU 41 2.1 Tìm hiểu – xác định yêu cầu 41 2.1.1 Khảo sát, tìm hiểu yêu cầu 41 2.1.2 Đánh giá yêu cầu 43 2.2 Phân tích yêu cầu 44 2.3 Đặc tả yêu cầu 46 2.3.1 Đặc tả yêu cầu 46 2.3.2 Nguyên lý đặc tả 48 2.4 Tư liệu hóa yêu cầu phần mềm 49 2.5 Đặc tính liệu kỹ thuật để thu thập liệu 51 2.5.1 Đặc tính liệu 51 2.5.2 Các kỹ thuật để thu thập liệu cho ứng dụng 54 CHƢƠNG 3: THIẾT KẾ PHẦN MỀM 64 3.1 Đặc điểm trình thiết kế phần mềm 64 3.2 Các hoạt động trình thiết kế phần mềm 66 3.3 Nền tảng thiết kế phần mềm 69 3.3.1 Trừu tượng (abstraction) 69 3.3.2 Làm mịn (Refinement) 70 3.3.3 Tính module 70 3.3.4 Kiến trúc phần mềm 70 3.3.5 Che dấu thông tin 72 3.3.6 Thiết kế module 73 3.4 Chất lượng thiết kế 73 3.4.1 Sự kết dính 73 3.4.2 Sự ghép nối 74 3.4.3 Sự hiểu 74 3.4.4 Sự thích nghi 75 3.4.5 Một số yêu cầu thiết kế 76 3.5 Chiến lược thiết kế 77 3.5.1 Thiết kế hướng chức 78 3.5.2 Thiết kế hướng đối tượng 79 3.6 Thiết kế kiến trúc cho ứng dụng mô hình cho thiết kế ứng dụng 80 3.6.1 Thiết kế kiến trúc ứng dụng 80 3.6.2 Các mơ hình thiết kế ứng dụng 81 3.7 Thiết kế giao diện người dùng 84 3.7.1 Nhân tố người 84 3.7.2 Phong cách tương tác người - máy 85 3.7.3 Thiết kế giao diện người - máy 85 3.7.4 Hướng dẫn thiết kế giao diện 87 CHƢƠNG 4: CÀI ĐẶT PHẦN MỀM 90 4.1 Phong cách cài đặt chương trình 90 4.1.1 Tài liệu chương trình 90 4.1.2 Khai báo liệu 92 4.1.3 Xây dựng câu lệnh 92 4.1.4 Vào 92 4.2 Nền tảng ngơn ngữ lập trình 93 4.2.1 Kiểu liệu, định nghĩa kiểu liệu kiểm tra kiểu liệu 93 4.2.2 Chương trình 94 4.2.3 Cấu trúc điều khiển 95 4.2.4 Vào liệu 96 4.2.5 Quản lý nhớ 97 4.2.6 Quản lý lỗi 97 4.3 Các đặc trưng ngôn ngữ cài đặt 97 4.4 Hiệu chương trình tầm quan trọng 98 4.5 Một số vấn đề cải tiến hiệu suất 99 4.5.1 Tốc độ xử lý 99 4.5.2 Không gian nhớ 99 4.5.3 Lựa chọn hệ thống phần cứng 100 4.6 Công cụ trợ giúp phân loại 100 4.6.1 Công cụ CASE 100 4.6.2 Phân loại công cụ CASE 103 CHƢƠNG 5: KIỂM TRA CHẤT LƢỢNG PHẦN MỀM 111 5.1 Độ tin cậy phần mềm 111 5.1.1 Chất lượng phần mềm việc đảm bảo chất lượng phần mềm 111 5.1.2 Độ tin cậy phần mềm 113 5.2 Kiểm tra chiến lược kiểm tra phần mềm 117 5.2.1 Đặc điểm kiểm tra phần mềm 117 5.2.2 Chiến lược kiểm tra phần mềm 120 5.3 Kỹ thuật kiểm thử phần mềm đặc điểm 124 5.3.1 Khái niệm 124 5.3.2 Đặc điểm kiểm thử 124 5.3.3 Kế hoạch thử nghiệm 126 5.3.4 Phân loại số công cụ kiểm thử tự động 126 CHƢƠNG 6: BẢO TRÌ PHẦN MỀM VÀ QUẢN LÝ THAY ĐỔI PHẦN MỀM 128 6.1 Hoạt động bảo trì phần mềm phân loại 128 6.1.1 Bảo trì hiệu chỉnh 128 6.1.2 Bảo trì tiếp hợp 128 6.1.3 Bảo trì hồn thiện 128 6.1.4 Bảo trì phịng ngừa 129 6.2 Đặc điểm bảo trì phần mềm 129 6.2.1 Bảo trì có cấu trúc bảo trì khơng cấu trúc 129 6.2.2 Giá thành bảo trì 130 6.2.3 Một số vấn đề khác 131 6.3 Cơng việc bảo trì phần mềm số hiệu ứng lề 132 6.3.1 Khả bảo trì 132 6.3.2 Các cơng việc bảo trì 133 6.3.3 6.4 Một số hiệu ứng lề cơng việc bảo trì 135 Một số hình thức bảo trì phần mềm 137 6.4.1 Bảo trì mã chương trình xa lạ 137 6.4.2 Công nghệ phản hồi công nghệ tái sử dụng 137 6.4.3 Bảo trì phịng ngừa 138 6.4.4 Chiến lược phần mềm thành phần 139 6.5 Quản lý thay đổi phần mềm 139 6.5.1 Các thủ tục quản lý thay đổi 139 6.5.2 Ghi định theo thời gian 142 6.5.3 Quản lý thay đổi tài liệu 142 TÀI LIỆU THAM KHẢO 143 CHƢƠNG 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 số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 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 hố đượ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 hố 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à cịn 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 số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, 10 Để 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ì hồn thiện 6.1.4 Bảo trì phịng ngừa 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, khơng thể 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ì hồ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ì 6.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 tồ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 6.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) 129 thực khơng 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 Nếu có cấu hình phần mềm hồ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 tồ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 6.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 ngun 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 130 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ì: M = p + K* exp(c-d) với M = tồ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 khơng có 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 khơng có phương pháp 6.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ó khơng thể 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 131 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 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 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 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 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 ln liên quan tới sai lệch mức độ cao 6.3 Cơng việc bảo trì phần mềm số hiệu ứng lề 6.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 6.3.1.1 Yếu tố kiểm số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ì 132 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 6.3.1.2 Đánh giá định lƣợng 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 6.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õ 6.3.2.1 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 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 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 133 ủ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 6.3.2.2 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 u cầu bảo trì cịn 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 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ì hồn thiện u cầu chi tiết thảo Đơn yêu cầu bảo trì người kiểm số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 ngồi coi sở để đề kế hoạch cơng việc bảo trì Ngồ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, 6.3.2.3 Lƣu giữ hồ sơ Thường khơng có đầy đủ hồ sơ cho tất giai đoạn chu kỳ sống phần mềm Thêm 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 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 134 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ì 6.3.2.4 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ì 6.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: 6.3.3.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 135 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 6.3.3.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 6.3.3.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 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 136 6.4 Một số hình thức bảo trì phần mềm 6.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: 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 6.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 cịn giữ 137 đặ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à cịn 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ý 6.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 đề cị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à: 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 khn 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 hồ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 138 6.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 Ngun mẫu phần mềm q trình mơ hình hóa 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 Q 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 ngồi 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 Mặc dù chiến lược phụ tùng thay cho phần mềm khác thường chút, khơng có chứng tỏ tốn kém, tính đến chi phí cho tất chu kỳ sống phần mềm 6.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 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 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 ý thích nảy người sử dụng cho phép thực yêu cầu hợp lý 6.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ụ q trình thao tác yêu cầu thay đổi đặc tả chức năng: Tạo yêu cầu mở 139 Khai báo file tác động Phê chuẩn file thời gian chi phí chủ, người sử dụng ký Hồ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, q 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 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 khơng có ư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 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 140 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 số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 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 tất tài liệu có liên quan thay đổi Thực thay đổi: nhiệm vụ hồn thành, xố 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 u cầu 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 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 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ệ hố 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 q 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 141 6.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ữ q 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 6.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 142 Chương Bảo trì phần mềmvà TÀI LIỆU7: THAM KHẢO quản lý thay đổi phần mềm Ngô Trung Việt, Kỹ nghệ phần mềm - dịch, Nhà xuất Giáo dục, 1999 Đoàn Văn Ban, Phân tích thiết kế lập trình hướng đối tượng, Trung tâm Khoa học Tự nhiên Công nghệ Quốc gia,1996 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 Lê Đức Trung, Những viên ngọc kỹ thuật lập trình - dịch, Trung tâm Tin học Điện tử Phương Đông, 1992 Roger S Pressman Ph.D, Software engineering a practitioner's - 5th, McGraw- Hill book Co.-Singapore, 2001 Yourdon, E Software reuse, Application development strategies, Vol 6, No 12, December 1994, pp.1-16 Sommerville I., Software engineering - 4th, Addison Wesley, 1995 Eldon Wig, Industry Software engineering course - VCIT project, Intellitec Consulting Inc., Hà Nội 10/1999 143 ... 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 Để... dụng 54 CHƢƠNG 3: THIẾT KẾ PHẦN MỀM 64 3.1 Đặc điểm trình thiết kế phần mềm 64 3.2 Các hoạt động trình thiết kế phần mềm 66 3.3 Nền tảng thiết kế phần mềm 69 3.3.1... trình trình độ đại học thực nhiệm vụ bên ngồi 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 ln ln tham