QUẢN LÝ CÁC GIAI ĐOẠN XÂY DỰNG HTTT

Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống CHƢƠNG 5: QUẢN LÝ CÁC GIAI ĐOẠN XÂY DỰNG HTTT Chương trình bày nội dung trọng tâm: - Chương trình bày tóm tắt số vấn đề việc phải làm giai đoạn xây dựng hệ thống thông tin tổ chức, kinh nghiệm thực dự án tin học - Cung cấp số kiến thức chắt lọc từ môn Quản lý dự án phần mềm có liên quan đến kiến thức mơn Phân tích thiết kế hệ thống thơng tin nhằm bổ trợ tốt học sinh, sinh viên tốt nghiệp công tác đơn vị phát triển phần mềm 5.1 QUẢN LÝ GIAI ĐOẠN LẬP KẾ HOẠCH, XÁC ĐỊNH YÊU CẦU Về mục tiêu dự án cần đạt được: Phân tích mục tiêu phải đạt dự án thực dựa sơ đồ hệ thống vấn đề lập trước đó, gồm việc:  Mơ tả tình hình tương lai vấn đề giải quyết;  Những trạng thái mong muốn khả thi trạng thái có vấn đề trước  Lập sơ đồ phân cấp hệ thống mục đích Sau bước trên, mục đích trọng tâm mục đích mức cao dự án bước đầu xác định Về giải pháp: Các giải pháp thay trạng xác lập dựa sơ đồ hệ thống vấn đề sơ đồ hệ thống mục đích dự án vừa xây dựng nên Việc lựa chọn giải pháp tối ưu thực cách so sánh chúng số phương diện Về yếu tố gây rủ ro cho dự án: Phân tích yếu tố nhạy cảm giúp ta tránh hay làm yếu yếu tố tương lai chưa biết yếu tố gây rủi ro dự án Nhưng cho phép xác định (bằng tính tốn) thay đổi số hiệu kinh tế hay số sinh lợi dự án gây thay đổi hay vài thơng số liên quan Đó yếu tố gây rủi ro cho dự án Tất nhiên, thông số đầu vào lựa chọn để khảo sát phải thông số mà giá trị chúng có khả thay đổi thực thực tế Mặt khác, việc phân tích tác động yếu tố rủi ro số kinh tế giải pháp khác cho phép ta chọn giải pháp rủi ro Cách thức quản trị dự án hệ thống thông tin Triển khai dự án hệ thống thông tin (HTTT) doanh nghiệp trình phức tạp, lơi nhiều người tham gia huy động nhiều nguồn lực, phải xử lý nhiều tình phát sinh Nói chung, quản trị dự án bao gồm trình: Lập kế hoạch; Giám sát việc thực dự án; đánh giá dự án Trong đó: Lập kế hoạch dự án gồm cơng đoạn chính: Phân tích/Chuẩn bị lập kế hoạch lập kế hoạch chi tiết Giáo viên biên soạn: Nguyễn Trần Phương 117 Trường Trung học Kinh tế Kỹ thuật Hòa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống Các yếu tố quan trọng lập kế hoạch dự án: Có yếu tố cần quan tâm, là: Con người, vấn đề dự án, mục tiêu dự án, giải pháp yếu tố rủi ro Về người: Con người yếu tố quan trọng dự án Các đối tượng người hiểu cá nhân, nhóm người hay tổ chức có liên quan hình thức tới dự án Để phân tích đối tượng nên phân chia thành nhóm tùy theo đặc điểm mối liên quan họ với dự án Phải làm rõ phân nhóm mối liên quan nhóm cá nhân dự án Về vấn đề dự án: Bất dự án thực nhằm giải (hay nhiều) vấn đề tồn thực trạng Phân tích vấn đề nhằm đánh giá đắn đầy đủ vấn đề dự án, đặt mối quan hệ nhân với tình hình thực tại, để xác định xác mục tiêu mà dự án định đạt tới giải pháp thực Mặt khác, phân tích vấn đề cần làm rõ hạn chế thời gian, nhân lực ngân sách thực dự án Những dự án nhỏ (số người sản xuất từ đến 20) dự án phần mềm tổ chức tốt thành đội phát triển nhỏ Qui mô lý tưởng đội phát triển khoảng bốn đến sáu người sản xuất Hầu hết dự án tổ chức thành đội ngũ với đội ngũ giao phó chức đặc thù phạm vi dự án Các loại dự án khác đòi hỏi loại cấu đội ngũ khác chẳng hạn đội ngũ nhà lập trình trung cấp địi hỏi lãnh đạo đội ngũ kỹ thuật đội ngũ chuyên gia địi hỏi lãnh đạo đội ngũ hành Đó trách nhiệm người quản lý dự án việc chọn lựa cấu thích ứng cho dự án Giám sát Đánh giá dự án: Bao gồm xác định phương pháp đánh giá (hiệu kinh tế, kết thực so với kế hoạch ) tổ chức công việc đánh giá Giám sát việc thực dự án khâu quan trọng q trình quản trị dự án, có ảnh hưởng tác dụng trực tiếp tới thành công dự án Vì vậy, địi hỏi tham gia người cương vị quản lý, mà cịn người thực cơng việc dự án, chí tất thành viên tham gia thực dự án Ba điểm mấu chốt để công việc giám sát dự án thực hiệu : o Thống phương thức thực công việc giám sát trao đổi thơng tin thích hợp thực tế, cho thành viên tham gia công việc thực dễ dàng, nhanh chóng xác o Phát sớm tốt sai lệch so với kế hoạch nhiệm vụ quan trọng, chủ chốt tìm nguyên nhân sai lệch o Có biện pháp điều chỉnh thích hợp khả thi để đảm bảo đạt mục tiêu dự án Còn việc đánh giá dự án nhằm đánh giá cách định lượng hiệu dự án (được quy hiệu kinh tế); Mức độ thành công/Thất bại dự án Quá trình đánh giá dự án gồm: Giáo viên biên soạn: Nguyễn Trần Phương 118 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống o Xác định tiêu số cần đánh giá; o Xác định phương pháp đánh giá sử dụng; o Kiểm tra nguồn cung cấp liệu đầu vào cần thiết; o Thu thập liệu thực tính tốn; o Đánh giá kết thu rút kết luận cần thiết; o Bổ sung thêm số đánh giá khác (nếu cần) Các phương pháp đánh giá dự án chủ yếu dựa tiêu kinh tế Bốn phương pháp thường dùng là: o Phân tích chi phí - lợi nhuận; o Tương quan thu - chi; o Giá trị tư bản; o Lãi suất (tỉ suất thu hồi) nội tại; Nội dung trình tự tiến hành tổng quát cho đánh giá dự án nói chung Tuy nhiên, tùy theo yêu cầu cụ thể đặc trưng dự án cần tiến hành phần số nội dung Ngồi ra, tiến hành công việc đánh giá giai đoạn định dự án 5.1.1 Xây dựng nhóm Phần đề cập đến vấn đề quản lý người chủ yếu vấn đề liên quan đến dự án phần mềm Về thảo luận khái quát phương pháp quản lý động viên người theo mơ hình tổ chức đề xuất đây: Trưởng quản lý dự Phó quản lý dự án Kỹ sư hệ thống Đội phát triển Nhóm thử nghiệm độc lập Bảo hiểm chất lượng Đội phát triển Thư ký Khống chế cấu hình Đội phát triển n Hình 5.1: Mơ hình cấu tổ chức để triển khai dự án tin học Những tổ chức khối tháp tạo nên trật tự rõ ràng xác định cụ thể cá nhân biết cương vị cương vị người họ Khi đề bạt qui chế đóng vai trị chủ yếu hình thành động Do tổ chức khối tháp có hiệu Nhiều yếu tố khác Giáo viên biên soạn: Nguyễn Trần Phương 119 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống hình thành động ý thức hoàn thành khen ngợi q trọng Mặc dù đề bạt qui chế khơng phải luôn động hiệu nhất, người quản lý dự án từ bỏ công cụ quản lý tổ chức khối tháp thường tốt Cơ cấu đội ngũ: Những đội ngũ lớn hạn chế khả lãnh đạo đội hoạt động người sản xuất tăng tổng phí quản lý hạn chế dính líu kỹ thuật lãnh đạo đội vào dự án Các đội ngũ đem lại cho người quản lý dự án nhiều lợi điểm, bao gồm : o Quản lý dễ dàng tốt : Cơ cấu đội ngũ hỗ trợ việc uỷ nhiệm thẩm quyền o Trao đổi thông tin ý kiến hiệu làm quen rộng đội ngũ với nhiệm vụ thành viên Trong dự án nhỏ, có đồng mạnh với dự án lớn, dự án lớn người sản xuất có xu hướng cảm thấy họ số nhiều người mà đóng góp họ cho dự án tiến hành khơng hay Dự án nhỏ điều ngược lại đội ngũ gắn bó hơn, tận tụy Lãnh đạo đội: Lãnh đạo đội ngũ coi kênh thơng tin người quản lý dự án với thành viên đội Điều khơng có nghĩa khơng có thơng tin trực tiếp người quản lý cấp dự án với thành viên đội Dù thơng tin trực tiếp điều hẳn làm cho mục đích cấu đội bị thất bại: Uỷ nhiệm thẩm quyền trách nhiệm hiệu Vai trò lãnh đạo đội : o Đại diện quản lý dự án thông qua uỷ nhiệm thẩm quyền o Đại diện đội trước người quản lý dự án o Đại diện đội trước đội dự án khác chức tổ chức Người lãnh đạo đội có trách nhiệm khác, tuỳ theo thể loại cấu đội Hình 5.2 cho thí dụ hai cấu đội khác (những cấu đội bàn sau) Mọi lãnh đạo đội lãnh đạo hành khơng phải tất lãnh đạo đội lãnh đạo kỹ thuật đội ngũ kỹ sư trưởng đòi hỏi khả lãnh đạo kỹ thuật theo địi hỏi thành viên kỹ thuật Cả đội ngũ dân chủ đội ngũ kỹ sư trưởng đòi hỏi khả lãnh đạo đội hành Đội trưởng Đội viên Đội viên Đội viên Giáo viên biên soạn: Nguyễn Trần Phương Đội viên 120 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống Hình 5.2.a: Tổ chức đội phát triển theo kiểu dân chủ Đội trưởng Đội viên Đội viên Đội viên Đội viên Hình 5.2.b: Tổ chức đội phát triển theo kiểu kỹ sư trưởng Các đội dân chủ: Nghiêm túc mà nói, đội dân chủ khơng có lãnh đạo, chức vai trò lãnh đạo đội điều phối viên nhiều hơn, đội dân chủ, lãnh đạo đội giành phần nhỏ thời gian họ cho việc sau: o Việc đại diện đội thông tin với quản lý dự án đội khác o Phối hợp hoạt động đội o Sử lý nhiệm vụ hành chínhkhác báo cáo, lập trình giám sát hoạt động Mọi định kỹ thuật đội dân chủ đội thực lãnh đạo đội triệu tập họp vấn đề gay cấn cấp thiết đưa thảo luận Nhưng thành viên đội tham gia trình định chịu trách nhiệm đầu Các đội dân chủ thường thích ứng cho nhóm nhà sản xuất thâm niên có kinh nghiệm Theo vai trị lãnh đạo đội giảm tổng phí hành cách giao nhiệm vụ hành đội cho thành viên Cơ cấu đội dân chủ đặc biệt khơng thích hợp cho nhóm hỗn hợp, hay nhóm bao gồm chủ yếu người sản xuất niên Trong hai trường hợp đó, vai trị lãnh đạo rõ ràng cần thiết Các đội kỹ sư trưởng: Đội kỹ sư trưởng (cũng gọi đội lập trình) tiến hành lãnh đạo đội phát triển Vai trị lãnh đạo đội vừa điều phối viên (như trường hợp đội dân chủ) vừa hướng dẫn dự án phức tạp, lãnh đạo đội yêu cầu giành đến 50% thời gian vào hoạt động kỹ thuật hành Hoạt động lãnh đạo đội kỹ sư trưởng là: o Giao nhiệm vụ trách nhiệm cho thành viên đội o Giám định công việc thành viên đội o Góp ý hướng dẫn thành viên đội o Hoạt động hành phối hợp (tương tự lãnh đạo đội dân chủ) Giáo viên biên soạn: Nguyễn Trần Phương 121 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống Các đội kỹ sư trưởng thích ứng cho đội hỗn hợp đội chủ yếu có người sản xuất có thâm niên hay khơng có kinh nghiệm chức lãnh đạo đội với tư cách người quản lý hàng đầu phải đào tạo thích hợp kỹ thuật quản lý Các đội kỹ sư trưởng thành cơng đội người sản xuất đàn anh có kinh nghiệm vai trị thường khơng cần thiết cấu vận dụng cho đội kỹ sư có kinh nghiệm việc người lãnh đạo đội có kỹ quản lý lại quan trọng gấp hai khơng đụng chạm phát triển thành viên đội người lãnh đạo đội Về mặt này, lãnh đạo đội ngũ người chun mơn có kinh nghiệm lại khó lãnh đạo đội ngũ người vào nghề Các đội chuyên gia: Đội ngũ chuyên gia đội ngũ nhỏ thành lập để giải vấn đề đặc thù dự án Một đội ngũ chuyên gia thành lập trình phát triển dự án có vấn đề phức tạp nảy sinh sau đội giải tán vấn đề giải (thường dự án gia cơng phần mềm người ta hay áp dụng mơ hình này) Trong số trường hợp, đội chuyên gia hỗ trợ dự án suốt chu kỳ phát triển Mục tiêu đội chuyên gia tập trung giám định lĩnh vực riêng dự án Lấy thí dụ, ta xét hệ thống thủ quĩ ngân hàng tự động có hai hệ thống phụ chủ yếu : Conputer trung tâm ngân hàng thủ quỹ tự động từ xa Kế hoạch phát triển cho hai hệ thống phụ giao việc phát triển hệ phụ cho đội riêng qui mô dự án khơng thể đảm bảo có đội hợp riêng Cả hai đội sử dụng mô thực thử nghiệm hợp hệ thống phụ ban đầu Kết hai hệ thống phụ hợp với nhau, thông tin hai hệ thống khơng có Trong tình có nguy hai đội tìm kiếm vấn đề cơng việc đội Cho dù hai đội hợp tác với tốt, khác biệt thực (hay thiết kế) làm cho vấn đề khó giải kịch trình bắt đầu trở nên phức tạp, điều trở thành mối quan ngại chủ yếu cho người quản lý dự án Với trường hợp thế, người quản lý dự án nên định thành lập đội chuyên gia để giải vấn đề thông tin Đội dự án hai kỹ sư dự án chung hai đội Sau đội chuyên gia tập trung cố gắng vào việc giải vấn đề nhanh tốt Trong hai đội tiếp tục hoạt động phát triển khác Sau vấn đề thông tin hai hệ thông phụ giải quyết, đội chuyên gia thể giải tán số mặt, đội thử nghiệm độc lập đội bảo hiểm chất lượng coi đội chuyên gia Các đội thử nghiệm độc lập lúc đầu hoạt động giai đoạn hợp thử nghiệm chu kỳ phát triển Đội bảo hiểm chất lượng thí dụ đội chuyên gia hoạt động xuyên suốt chu kỳ phát triển dự án Đội chuyên gia thường có kỹ sư có kinh nghiệm cao trường hợp điều chắn đội tổ chức đội dân chủ Trong thí dụ trước, đội đội dân chủ hay chuyên gia thơng tin đàn anh lãnh đạo 5.1.2 Bố trí nhân sự, phân công nhiệm vụ Giáo viên biên soạn: Nguyễn Trần Phương 122 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống Rõ ràng cấu tổ chức dự án tuỳ thuộc loại dự án phát triển Một số vấn đề phải xem xét : Qui mô dự án : Dự án lớn, tổ chức mơ hình quan trọng Những dự án lớn có tổng phí thơng tin phối hợp đáng kể người địi hỏi nhiều chức hỗ trợ Dự án phát triển phần mềm/phần cứng: Việc phát triển liên tiếp phần cứng phần mềm không dễ dàng Việc lập kế hoạch, hợp thử nghiệm lại phức tạp địi hỏi nhóm hỗ trợ tận tụy Các hệ thống tin cậy cao: Bất hệ thống nhạy cảm với vấn đề độ tin (như hệ thống quân hay cứu nạn) đòi hỏi cố gắng chủ yếu bảo hiểm chất lượng Chất lượng nhận định quan trọng nhiều sản phẩm phần mềm đưa thị truờng (thí dụ chương trình thơng tin) Những loại dự án địi hỏi tổ chức bảo hiểm chất lượng riêng Cơ cấu tập đoàn: Tổ chức dự án phụ thuộc nhiều vào cấu tổng thể công ty dự án phát triển Nhiều chức hỗ trợ dự án nhóm tập trung hố cơng ty cung cấp Trên thực tế, dịch vụ dịch vụ tài văn phòng pháp lý thường tổ chức bà hay tập đoàn cung cấp Các G.đốc dự án Giám đốc dự án A Các G.Đ Chức Giám đốc dự án B Giám đốc thử nghiệm GĐ bảo hiểm chất lượng TN Đội thử nghiệm Đội thử nghiệm GĐ cơng trình phần mềm Đội bảo hiểm chất lượng Đội bảo hiểm chất lượng Đội Đội Đội Đội Đội Đội Hình 5.3: Biểu đồ tổ chức Cơ cấu tập đoàn thường định hai loại tổ chức dự án bản: Ma trận hay khối tháp Hình 5.3 mơ tả cấu tổ chức ma trận (so sánh với Giáo viên biên soạn: Nguyễn Trần Phương 123 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống cấu khối tháp hình 5.1 sơ đồ rút gọn hình 5.4).Trong tổ chức ma trận tập đoàn, người quản lý dự án quản lý hoạt động kỹ thuật đội ngũ dự án dính líu anh hay chị vấn đề nhấn phi kỹ thuật (thí dụ duyệt lương, đề bạt, đào tạo) Có nhiều cách tổ chức dự án phần mềm Dự án lớn cấu tổ chức trở nên gay cấn Những dự án tổ chức tồi gieo rắc lộn xộn lộn xộn dẫn đến dự án thất bại NGƯỜI QUẢN LÝ DỰ ÁN ĐỘI PHÁT TRIỂN DỰ ÁN CÁC CHỨC NĂNG TRỢ GIÚP DỰ ÁN Hình 5.4: Biểu đồ tổ chức dự án lớn phần mềm/ phần cứng Hình 5.5 mơ tả cấu dự án bên người quản lý dự án có chức tổng quát phát triển hỗ trợ Trưởng quản lý dự án Phó quản lý dự án Kỹ sư hệ thống Đội phát triển Nhóm thử nghiệm độc lập Thư ký Bảo hiểm chất lượng Đội phát triển Hình 5.5: Biểu đồ tổ chức dự án phần mềm Giáo viên biên soạn: Nguyễn Trần Phương 124 Khống chế cấu hình Đội phát triển n Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống Hình 5.6 Mô tả biểu đồ tổ chức chi tiết kể chức hỗ trợ chủ yếu Cơ cấu tổ chức thích ứng với dự án lớn (với nhân 20) Những dự án nhỏ khơng địi hỏi phó quản lý dự án hay nhóm kiểm tra cấu hình bảo hiểm chất lượng riêng biệt Những dự án lớn (nhân từ 40 người trở lên) thường quản lý dễ dàng phân dự án thành dự án phụ Trưởng quản lý dự án Phó quản lý dự án Kỹ sư hệ thống Nhóm thử nghiệm độc lập Đội Bảo hiểm chất lượng Đội phát triển Đội phát triển Đội Thư ký Đội Đội Đội Khống chế cấu hình Đội phát triển n Đội Đội Đội Hình 5.6: Biểu đồ tổ chức dự án phần mềm/phần cứng lớn Đội Bên cạnh việc phát triển dự án phần mềm cịn có q trình qui hoạch, tổ chức, tuyển nhân sự, giám sát, kiểm tra lãnh đạo dự án phần mềm Hiếm nhiệm vụ quản lý cách chặt chẽ Trên thực tế nhiều hoạt động kiểm tra giám sát ủy thác cho nhóm hỗ trợ dự án Những nhóm hỗ trợ khơng giám định cho quản lý dự án kỹ sư phát triển nhiệm vụ hỗ trợ Họ thực nhiệm vụ tốt cách tập trung cố gắng họ vào chức hỗ trợ đặc trưng Có nhiều loại chức hỗ trợ dự án Dịch vụ thư ký, hỗ trợ hành xuất cung cấp tài liệu thí dụ chức hỗ trợ khơng kỹ thuật; Thử nghiệm, kiểm tra cấu hình, cơng nghệ hệ thống quản lý hội nhập bảo hiểm chất lượng thí dụ chức hỗ trợ kỹ thuật Dự án lớn phức tạp lại đòi hỏi chức hỗ trợ nhiều Chẳng hạn, dự án lớn thường có tổ chức kiểm tra chất lượng dự án nhỏ chia xẻ chức với dự án khác Tương tự, nhiều tổ chức trì nhóm thử nghiệm độc lập mà vai trò thử nghiệm sản phẩm phần Giáo viên biên soạn: Nguyễn Trần Phương 125 Trường Trung học Kinh tế Kỹ thuật Hòa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống mềm trước đưa dự án lớn, nhóm thử nghiệm độc lập phận đội dự án tham gia thử nghiệm qui hoạch thử nghiệm xuyên suốt chu trình phát triển 5.1.3 Lập kế hoạch tiếp cận vấn đề Nhiều đối tượng phức tạp xem đối tượng đơn giản hợp thành Một thí dụ thích hợp hố chất hình thành từ nhiều phân tử khác phân tử tạo thành phối hợp nhiều nguyên tử khác Các nguyên tử thân phân chia được coi phần tử nhỏ hoá chất Theo cách đó, tương tự cho dự án phức tạp phân thành thành phần đơn giản Trong tồn dự án khó quản lý thành phần dễ xử lý dự án phần mềm phân thành thành phần nhỏ nhằm dự tính tốt khối lượng công việc nhằm điều khiển hoạt động đội phát triển khác Việc phân giải dự án phần mềm nhiệm vụ người quản lý dự án phần mềm Các phương pháp phân giải khác nhau, tuỳ theo mục tiêu thực người quản lý dự án Việc phân tích dự án theo chức khơng phân tích thiết kế Phân tích chức chia dự án thành thành phần theo cách nhìn người dùng phân tích thiết kế chia dự án thành thành phần hay mơ đun lập trình Nói tóm lại Phương pháp “Chia để trị” Tinh chế bước một: Theo trực giác khơng hợp lý tìm cách minh định thành phần dự án bước Rõ ràng qui trình lặp cung cấp nhiều chi tiết hơn, dể sử dụng Những phương pháp lặp thuộc loại gọi tinh chế bước phân giải tiếp tục tinh chế bước kế tục Giáo viên biên soạn: Nguyễn Trần Phương 126 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống 5.3.4 Đặc tả thử nghiệm cho cá thể Những số bảng 5.12 lấy từ sơ đồ chung có nhấn mạnh đến qui hoạch phần mềm (yêu cầu thiết kế) thử nghiệm Những hệ thống xử lý liệu thương mại, trừ số ngoại lệ, cịn phải tiêu phí khối lượng đáng kể thời gian phát triển pha lập trình thử nghiệm đơn vị Các hệ thống thời gian thực thường phức tạp nhiều bao gồm tích hợp bao quát phần cứng/phần mềm Điều thơng thường địi hỏi qui hoạch nhiều tích hợp thử nghiệm nhiều Bảng 5.12 Phần trăm dự tích thời gian hao phí pha phát triển phần mềm chủ yếu Qui mã thử nghiệm thể thử hoạch đơn vị nghiệm Xử lý liệu thương mại 25% 40% 35% Các hệ thống thời gian thực 35% 25% 40% Các hệ thống quân 40% 20% 40% Đặc tả trường hợp thử nghiệm, mô tả chi tiết thử nghiệm mức thấp cho cá thể Vào cuối pha này, nhiều chưa biết dự án lại trở nên biết, tạo nên cải tiến đáng kể dự tốn kế hoạch phát triển thơng số phát triển dự án khác tài nguyên lịch tích hợp trường hợp thử nghiệm thực cho pha thử nghiệm, lập kế hoạch kế hoạch phát triển dự án cập nhật coi giai đoạn kế hoạch đáng tin cậy nhiều Theo thế, song song với thiết kế hệ thống, hoạt động sau tiến triển :  Nền tảng, tích hợp phát triển thiết lập bao gồm thiết bị yêu cầu cho phát triển tích hợp hệ thống  Dự tốn cải tiến đáng kể  phân tích rủi ro dự án duyệt xét lại cập nhật  Lịch phát triển hệ thống cập nhật Mọi thông tin đưa vào việc sửa đổi chủ yếu kế hoạch phát triển dự án Thử nghiệm đơn vị người lập trình tiến hành modul cá thể sau modul mã hố 5.3.5 phân tích rủi Xử lý rủi ro đầu tư cho CNTT: Có nhiều dự án CNTT dự báo thành công thẩm định phân tích kinh tế trên, triển khai dự án lại gặp nhiều trục trặc, gọi rủi ro Vì vậy, ngồi phân tích kinh tế, cần thực quản lý rủi ro dự án Quản lý rủi ro bao gồm: Xác định phân tích dạng rủi ro, đưa giải pháp để giảm thiểu rủi ro điều chỉnh ước tốn lợi ích chi phí cho phù hợp Có hai cách ứng phó với rủi ro: Khắc phục hậu xảy dự báo rủi ro để có biện pháp phòng ngừa trước Cần kết hợp biện pháp Phòng ngừa rủi ro cách hiệu hơn, thực Giáo viên biên soạn: Nguyễn Trần Phương 154 Trường Trung học Kinh tế Kỹ thuật Hòa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống Để phịng ngừa rủi ro: Đầu tiên phải có nhận thức khái lược chúng, dựa thông tin thu từ bước thực trước Kết quả, đưa bảng liệt kê phân loại sơ rủi ro gặp dự án giai đoạn triển khai khác Tiếp đến, rủi ro phân tích “nhạy cảm”, tức xác định xác suất xảy phạm vi ảnh hưởng xảy chúng, để điều chỉnh giải pháp dự báo ảnh hưởng kinh tế dự án Vì vậy, phân tích rủi ro cần đưa vào kết đánh giá dự án Phân tích rủi ro có tầm quan trọng đặc biệt triển khai dự án HTTT, dự án lớn phức tạp Việc phân tích rủi ro cần chuẩn bị trước vấn đề dự liệu đòi hỏi đánh giá vấn đề nhằm: Dự toán xác suất vấn đề xảy Dự toán sáo động vấn đề tới dự án Quy cho mức độ nghiêm trọng vấn đề Một cách đơn giản hiệu để tính mức độ nghiêm trọng vấn đề dự liệu là: Gán số kỳ vọng 10 xác suất vấn đề xảy ra, với 10 điểm xác suất cao, xác suất thấp (thí dụ nhân xác suất với 10) Gán số 10 vào tác động vấn đề với dự án 10 biểu thị tác động cao tác động thấp Nhân trị giá có bước (1) với giá trị có bước (2) để tính mức độ nghiêm trọng cho vấn đề Dưới ví dụ: Bảng 5.13: Ví dụ cách tính mức độ nghiêm trọng TT Vấn đề Chậm giao máy tính để phát triển Bộ nhớ khơng đủ Khơng có chun gia hệ điềuhành Thời gian đáp ứng hệ thống chậm Thuyên chuyển nhân cao Truyền thông chậm Chậm giao hệ thống phụ sở liệu 5.4 QUẢN LÝ GIAI ĐOẠN THỰC HIỆN Giáo viên biên soạn: Nguyễn Trần Phương 155 Kỳ vọng 5 Tác động 2 8 Nghiêm trọng 30 25 15 40 16 27 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống Pha thiết kế Pha thực thi Pha tích hợp T Hình 5.14 : Sự gối đầu pha 5.4.1 Phát triển mã nguồn Trong pha thực hiện, mơ đun phần mềm mã hố thử nghiệm đơn vị ban đầu tiến hành Thử nghiệm đơn vị người lập trình tiến hành mơ đun cá thể sau mơ đun mã hố Sau mơ đun phận kiểm tra chất lượng phần mềm phê chuẩn đệ trình phận kiểm tra cấu hình Sau phận kiểm tra cấu hình chuyển mơ đun để hợp Đặc tả thiết kế chi tiết cấu trúc tốt dẫn đến việc lập mã tương đối trơn chu thẳng băng (Điều thuyết minh qua nhiều cố gắng để phát triển máy sinh mã tự động tạo lập mã từ đặc tả thiết kế, điều hầu hết cơng cụ phân tích thiết kế sinh mã nguồn) Theo việc lập mã (hay lập trình) đầu nhận thức đồng nghĩa với phát triển phần mềm, trở thành pha riêng rẽ chu trình phát triển phần mềm Trên thực tế pha thực lại không pha dài Một kinh nghiệm thơng thường đề dự tính pha chu trình phát triển phần mềm sử dụng cách phân chia theo tỉ lệ 40 – 20 - 40 công sức thời gian (bảng 5.12) Điều có nghĩa khoảng 40% thời gian giành cho đặc tả (yêu cầu thiết kế ) 20% cho thực (lập trình thử nghiệm đơn vị) 40% cho tích hợp thử nghiệm xu hướng chung tìm cách giảm 20% dành cho thực tăng 40% dành cho đặc tả ? Một khía cạnh lập luận đằng sau tiếp cận giai đoạn phát triển sớm tốn giai đoạn sau Các pha đặc tả thường có nhân lực thấp thiết bị phát triển pha thực Cũng thường chứng minh công sức giành nhiều cho yêu cầu thiết kế, pha tích hợp dễ dàng hiệu Pha thực cầu nối pha thiết kế tích hợp hệ thống thường gối đầu rõ rệt với hai pha (hình 5.14) Tình trạng gối đầu thường xảy nhiều phận thiết kế hệ thống thực tương đối nhanh để Giáo viên biên soạn: Nguyễn Trần Phương 156 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống lại số vấn đề thiết kế bỏ ngỏ thời gian Trong trường hợp gối đầu rút ngắn đáng kể lịch phát triển Tình trạng gối đầu pha thiết kế thực đòi hỏi phải thận trong việc đảm bảo mơ đun thiết kế hồn chỉnh phê chuẩn để thực sớm Có rủi ro thay đổi chậm sau thiết kế mơ đun địi hỏi phải lập mã lại Theo lãng phí tài ngun Cũng có rủi ro thiết kế thay đổi mã không thay đổi Dù rủi ro thường nắm bắt tốt Với qui hoạch khống chế kiểm tra cấu hình tốt vấn đề khắc phục 5.4.2 Xây dựng kế hoạch bảo trì Mặt khác pha thực hiện, tình trạng gối đầu lập mã ích hợp thường rủi ro qui hoạch đắn tiết kiệm thời gian tuyệt hảo Trình tự thực mô đun phải qui hoạch tốt đảm bảo chúng đưa theo trình tự u cầu để tích hợp Điều có nghĩa sai lầm thực định vị q trình tích hợp hồi tiếp lại pha thực Pha thực bao gồm hoạt động sau :  Phát triển mã phần mềm  Chuẩn bị cho tích hợp thử nghiệm hệ thống (giai đoạn sau)  Phát triển kế hoạch bảo trì Ngồi mã viết số tư liệu khác phát triển pha bao gồm :  Sổ ghi người lập trình dẫn ghi lại định lập mã thử nghiệm đơn vị giải pháp cho vấn đề thực  Kế hoạch bảo trì thu thập tư liệu, kể tư liệu cốt yếu cần thiết cho việc bảo trị hệ thống  Các ban đầu tư liệu cho người dùng, kể sổ tay tham khảo hướng dẫn cho người điều hành Trong pha thực hiện, dự án bước vào thời kỳ hoạt động khẩn trương Nhiều hoạt động khác diễn bao gồm:  Pha thiết kế hoàn tất sớm trình pha thực  Nền tích hợp định vị việc tích hợp bắt đầu  Nền thử nghiệm (môi trường thiết bị thử nghiệm) định vị để chuẩn bị cho việc thử nghiệm hệ thống  Các tình rủi ro trở thành thực kế hoạch dự phịng bất trắc đưa vào hoạt động  Kế hoạch dự án duyệt lại cập nhật 5.4.3 Lập sổ ghi giải pháp cho mơ đul thử nghiệm Lấy lại ví dụ quản lý khách sạn điều dễ thấy modul có trình bày bao gồm: Tài liệu dùng cho thiết kế Giáo viên biên soạn: Nguyễn Trần Phương 157 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống Các qui định liên quan Văn đặc tả sơ bộ/Chi tiết Các loại sơ đồ Sơ đồ luồng liệu Sơ đồ lớp Sơ đồ logic CSDL Các thuộc tính Các thuộc tính Thuộc tính trừu tượng Giao diện – Báo cáo Giao diện - Biểu mẫu Danh sách biến cố hành vi Đây q trình thử nghiệm đầu tiên, điều quan trọng nhà thiết kế thường lập trình viên mức đỉnh thường bỏ quên việc ghi chép tỉ mỉ kết trình thiết kế: Đầu vào, đầu ra, tên modul giới hạn cho phép thực modul để làm tài liệu cho bàn giao cho giai đoạn tiếp 5.4.4 Xây dựng trợ giúp cho ngƣời dùng cuối Xây dựng trợ giúp có tầm quan khơng thể khơng quan tâm, phân tích rủi ro coi rủi ro kế hoạch đối phó bất ngờ lập từ trước Đối với dự án nhỏ thiết kế khơng chun phần chẳng quan tâm, mà thường nhầm lẫn trình chuyển giao đào tạo nhà phát triển thực Hầu hết phần mềm công ty Việt Nam yếu phần lý mà phần mềm không tồn lâu thị trường Có vài cách xây dựng trợ giúp cho người dùng cuối;  Trợ giúp ngữ cảnh  Trợ giúp chức  Tạo kênh thơng tin trợ giúp 5.4.5 Nhất thể hóa phần, tất cả, rà sốt lỗi mã thể hóa Để tạo chất lượng cho hệ thống Pha thường phân làm hai pha riêng biệt song song : Pha tích hợp pha thử nghiệm dự án lớn, phân chia thường cần thiết đặc biệt việc thử nghiệm nhóm riêng biệt độc lập tiến hành (đội ngũ thử nghiệm độc lập) làm việc sát cánh với người sản xuất dự án nhỏ, điều hợp lý đằng sau phối hợp hai hoạt động vào pha tích hợp khơng thể thành cơng khơng có thử nghiệm rộng rãi tiến hành song song Do hai hoạt động đội ngũ thực hiện, thường tốt phối hợp chung pha Có nhiều kỹ thuật phương pháp tích hợp:  Từ xuống Giáo viên biên soạn: Nguyễn Trần Phương 158 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống Tiếp cận xuống đòi hỏi cốt lõi hệ thống (thường modul điều hành trung tâm) phải thực trước Rồi chúng phối hợp hệ thống cực nhỏ sử dụng thủ tục chưa có nội dung thay cho modul cha thực Những thử tục rỗng mã trả lại giá trị cố định chẳng có tính lơgic cả, thường gọi cuống Sau cuống thay dần modul thực, theo cách xây dựng tăng tiến có kế hoạch tốt hệ thống lần từ hệ thống đưa mới, lại tăng thêm nhiều chức  Từ lên Tiếp cận từ lên modul cá thể cấp thấp (ví dụ : - điều khiển đầu vào đầu ra, định khuôn,dạy thao tác,dữ liệu, đối thoại người dùng, máy v.v ) gép chúng thành nhóm lúc lớn toàn hệ thống ghép lại Cách tiếp cận lên khuyên dùng làm tích hợp dễ hiểu, hầu hết trường hợp cách tiếp cận xuống dễ tự nhiên Dù thực tế, hầu hết chiến lược tích hợp hệ thống thành cơng phối hợp cách tiếp cận xuống lác đác đôi chỗ theo cách tiếp cận từ lên Một cách tiếp cận lý thú khác gọi  Từ Tích hợp từ (indide out integration) thông thường phát triển hệ sở liệu lớn cấu trúc file nội xây dựng trước sau logic xử lý liệu cuối giao diện với người Tiếp cận tốt hệ thống mặt logic tầng chức điểm yếu giao diện với người lại thường tích hợp cuối Điều địi hỏi viết mã thử nghiệm tạm thời để đầu duyệt xét lại Do thử nghiệm thường chậm khó so với tiếp cận từ ra.Việc thử nghiệm bắt đầu việc tích hợp tiếp tục tới cuối hệ thống bàn giáo cho khách hàng 5.4.6 Xây dựng kế hoạch dự phòng cho rủi Bảng 5.15 Ví dụ bảng ngẫu nhiên TT Vấn đề Thuyên chuyển nhân cao Chậm giao máy tính để phát triển Chậm giao hệ thống phụ sở liệu Không có chuyên gia hệ điều hành Nghiêm trọng Giáo viên biên soạn: Nguyễn Trần Phương 40 30 27 25 Kế hoạch đối phó bất ngờ Tiền thưởng hồn thành dự án thắng lợi Yêu cầu làm ca đêm hệ thống phát triển dự án khác Thiết kế mô hệ thống phụ sở liệu dùng để tích hợp Bố trí chuyên gia hệ điều hành ngồi cơng ty th làm tư vấn 159 Ngƣời theo dõi Hoàng Tùng Bùi Phương Thị Lê Nghiệp Văn Nguyễn Văn Thiện Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống Truyền thông chậm Thời gian đáp ứng hệ thống chậm Bộ nhớ không đầy đủ 16 15 Hợp đồng với công ty phát triển gói truyền thơng nhị phân thích nghi cho gói với dự án Cho vào điều khoản thỏathuận nâng cấp CPU hợp đồng mua máy tính (khơng xem xét) Quách Nghĩa công Trân Khang Duy Thực kế hoạch đối phó bất ngờ Các kế hoạch đối phó bất ngờ thực trường hợp sau: Vấn đề liệu diễn hay xảy đến đến nơi Kế hoạch đối phó bất ngờ địi hỏi chuẩn bị trước Nói chung, kế hoạch đối phó bất ngờ nhìn nhận theo kế hoạch, hành động xếp vào ngăn kéo để phòng dùng đến sau Dù sao, vài trường hợp, kế hoạch thực trước vấn đề dự liệu xảy phát triển mô trường hợp việc giao hợp phần định bị chậm trễ Sau đó, hợp phần giao hạn mơ bị bỏ 5.4.7 Quyết tốn khâu hồn thiện Đối với khách hàng: Đến giai đoạn nhà phát triển dự án cần phải yêu cầu toán dự án theo hợp đồng (một phần hợp đồng) để trả chi phí cho hạng mục phát triển Đối với nhà phát triển: Thực công tác thẩm định hạng mục phát triển Phương pháp xác minh vấn đề có lẽ đề nghị sau: Các hoạt động SQA (nhóm đảo bảo chất lượng phần mềm) việc giám định duyệt lại, chọn lựa kiểm tra cấu hình tùy thuộc cách mà SQA thích ứng với dự án đặc trưng Qui mơ dự án thường yếu tố định Những hướng dẫn sau bàn đến số thông số cần xem xét cho loại dự án khác lập kế hoạch SQA  Trong dự án nhỏ, có nhiều hoạt động SQA người quản lý dự án thực Điều bao gồm tổ chức giám định duyệt lại kiểm toán, đánh giá lựa chọn công cụ phát triển, lựa chọn vận dụng tiêu chuẩn  Các thủ tục thử nghiệm thử nghiệm tốt đội riêng biệt độc lập tiến hành (xin tham khảo chi tiết tiêu chuẩn có giáo trình Cơng nghệ phần mềm Quản lý dự án phần mềm ĐHQG Hà Nội) Quyết định chỗ giám định hoạt động thử nghiệm ủy thác cho SQA tùy thuộc nhiều yếu tố, kể độc lập đội SQA, qui mơ dự án tính phức tạp dự án Giáo viên biên soạn: Nguyễn Trần Phương 160 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống Khi việc thử nghiệm đội thử nghiệm độc lập tiến hành dính líu SQA tối thiểu Trong hầu hết trường hợp khác, trách nhiệm đội SQA lập kế hoạch giám định thử nghiệm hệ thống  Về hướng dẫn chung, thường không nên để thành viên đội phát triển thực SQA Dù sao, dự án nhỏ thường xác minh chi phí kỹ sư bố trí SQA Vấn đề giải có kỹ sư SQA chịu trách nhiệm cho hai hay ba dự án nhỏ (với dự án tài trợ phần đóng góp dịch vụ SQA) Khả kiểm tra chất lượng phần mềm hiệu trực tiếp với chất lượng đặc điểm yêu cầu phần mềm Kiểm tra chất lượng đòi hỏi chi tiết không mơ hồ nhiều đặc điểm yêu cầu chất lượng phần mềm tốt 5.5 QUẢN LÝ GIAI ĐOẠN THỬ NGHIỆM 5.5.1 Thực việc thể hóa  Thử nghiệm tích hợp : Thực máy tích hợp hệ thống  Thử nghiệm độc lập : Thực nhóm thử nghiệm bên để đảm bảo thử nghiệm khách quan không thiên lệch  Thử nghiệm lắp đặt: Điều bao gồm thử nghiệm hồn thiện chung Địi hỏi mà phiên hệ thống lắp đặt môi trường điều hành Nhiều hệ thống bao gồm thử nghiệm lắp đặt để đảm bảo hệ thống lắp đặt thành công 5.5.2 Thực thử nghiệm An pha, Bê ta, Thử nghiệm thu Các thử nghiệm tiến hành hệ thống môi trường thực (không phải thử nghiệm phịng thí nghiệm test) Các thử nghiệm phần mềm bao gồm:  Thử nghiệm đơn vị  Thử nghiệm hợp  Thử nghiệm hệ thống phụ  Thử nghiệm hệ thống  Thử nghiệm suy thoái Và thử nghiệm quan trọng  Thử nghiệm alpha: Thử nghiệm hệ thống khơng có liệu sống  Thử nghiệm beta: Thử nghiệm hệ thống có sử dụng liệu sống có giám sát thường xuyên để chỉnh lý vấn đề phát sinh  Thử nghiệm nghiệm thu: Đây cột mốc cuối dự án hồn tất thắng lợi có nghĩa nghiêm thu khách hàng sản phẩm phát triển Vào lúc kết thúc pha tích hợp thử nghiệm tư liệu phải đầy đủ sẵn sàng để giao bao gồm :  Tài liệu bảo trì  Tài liệu người dùng cuối  Mọi tài liệu phát triển cập nhật  Tài liệu thử nghiệm báo cáo thử nghiệm Giáo viên biên soạn: Nguyễn Trần Phương 161 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống 5.5.3 Lập báo cáo thử nghiệm Người quản lý dự án cần thông tin khách quan thông tin thường thu thập từ báo cáo đội thử nghiệm độc lập như:  Các báo cáo bảo hiểm chất lượng có tiêu chí sau:  Tồn khía cạnh đặc điểm sản phẩm phần mềm có khả đáp ứng nhu cầu đề ra: Chẳng hạn thích hợp với đặc điểm kỹ thuật  Mức độ mà phần mềm có phối hợp mong muốn thuộc tính  Mức độ mà khách hàng hay người dùng nhận thức phần mềm đáp ứng kỳ vọng hợp thể họ  Các đặc điểm hợp thể phần mềm xác định mức độ mà phần mềm sử dụng đáp ứng kỳ vọng khách hàng  Khả sản phẩm phần mềm để đáp ứng yêu cầu đặc dụng Chất lượng phải đo theo nghĩa kỳ vọng khách hàng Người quản lý dự án phải coi việc thực kiểm tra chất lượng q trình khách quan, mang tính hệ thống  Báo cáo thử nghiệm gồm bốn thành phần:       Qui hoạch thử nghiệm Mô tả thử nghiệm Tiến hành thử nghiệm Kết thử nghiệm Tiêu chuẩn thử nghiệm Các yếu tố mức độ chi tiết thông tin tư liệu yêu cầu Mặc dù báo cáo nguồn thông tin có ích, khơng có thay tiếp xúc trực tiếp người quản lý dự án nhân lực phát triển Nhưng nói chuyên thường xun khơng thức với người sản xuất nguồn thông tin tuyệt hảo đặc biệt tiến hành bầu khơng khí khơng thức (và khơng phải văn phịng người quản lý dự án) Người quản lý dự án phải trì cảnh giác thường xuyên với sai lầm thường gọi ''hội chứng 90/50'' khẳng định ''phải 50% thời gian để hồn thành 90% cơng việc 50% thời gian phụ thêm để hồn thành số 10% cơng việc cịn lại'' Điều có nghĩa người sản xuất dự án bắt đầu khoe khoang sớm họ ''hầu xong'' nhiệm vụ họ, bất hạnh có khác biệt lớn ''hầu xong'' với ''xong'' Xong nhiệm vụ - viết tài liệu toán vài vấn đề cuối - thường lại lâu dự kiến người phát triển Có điều hoạt động tạo số kết qủa nhãn tiền Người phát triển có xu hướng (sai lầm) kết hợp công việc với kết Do đấy, người quản lý có nhiều thơng tin người sản xuất hỏi họ dự tính xong cơng việc khơng hỏi họ hồn thành cơng việc 5.5.4 Đánh giá mức độ các lỗi sinh Giải pháp khắc phục Khi ủy thác SQA (nhóm đảo bảo chất lượng phần mềm) bao gồm hoạt động kiểm tra cấu hình, nguồn yêu cầu bao gồm nguồn yêu cầu cho kiểm tra cấu hình Việc hịa đồng SQA kiểm tra cấu hình không Giáo viên biên soạn: Nguyễn Trần Phương 162 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống phổ biến loại trừ số ủy nhiệm hoạt động phải nhân lên Nên nhớ với dự án nhỏ, việc hịa đồng hai nhóm đơn giản có nghĩa phó thác hai nhiệm vụ cho người Mặc dù nhiều công cụ phổ biến cho kiểm tra chất lượng kiểm tra cấu hình, có cơng cụ đặc biệt định cho kiểm tra chất lượng Sau số cơng cụ hỗ trợ chung có ích việc hỗ trợ hoạt động SQA:  Tiện ích tư liệu  Cơng cụ thiết kế phần mềm  Hỗ trợ tìm sai (Chương trình gỡ rối)  Các xử lý trước cấu thành  Bộ so sánh hồ sơ  Những phân tích cấu  Những kiểm toán tiêu chuẩn  Những mơ  Những phân tích thi công  Những giám sát thực  Những công cụ hợp chất CASE số công cụ khác có thị trường  Những kích thích thử nghiệm  Những phát trường hợp thử nghiệm Những cơng cụ hỗ trợ kiểm tra chất lượng giai đoạn phát triển phần mềm Các hỗ trợ tư liệu cung cấp phần viết tư liệu tự động, kiểm tra tả sưu tập chuyên ngành (Thesaurus) v.v xử lý trước cấu thành có ích việc tiêu chuẩn hóa liệt kê mã lẫn cung cấp cảnh báo bổ sung thời gian biên dịch mà biên dịch thường bỏ qua Những cảnh báo sớm liên quan đến vấn đề thời gian thực mơ phỏng, phân tích thời gian thực giám sát thực cung cấp Thử nghiệm thấu đáo hệ thống phần mềm thường tự động thực nhờ phát hệ thử nghiệm thực thử nghiệm tự động 5.5.5 Lập ngân sách cuối dự án Song song với tích hợp thử nghiệm, hoạt động quản lý không phát triển sau diễn :  Lập ngân sách cuối dự án, phí tổn cho thay đổi (phát minh) xác định hoạt động dự phòng rủi ro đánh giá ngân sách cập nhật  Việc huấn luyện tiến hành cho người dùng, người vận hành, khách hàng, người lắp đặt, đội ngũ bảo trì đội tiếp thị  Địa điểm lắp đặt chuẩn bị hạ tầng có sở cho phần cứng thiết bị đặc biệt lập kế hoạch lắp đặt  Qui mô đội ngũ phát triển giảm 5.5.6 Lắp đặt, tích hợp hệ thống đào tạo ngƣời vận hành Hai hoạt động khác song song với bảo trì là:  Duy trì thơng tin cập nhật  Cập nhật lớp huấn luyện người dùng Giáo viên biên soạn: Nguyễn Trần Phương 163 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống Khơng giống bảo trì phần cứng, khơng có hoạt động lại làm cho phần mềm trở lại trạng thái ban đầu Điều trái lại hồn tồn đúng: Mục tiêu sửa đổi phần mềm sửa đổi phần mềm bao gồm đặc điểm phát triển phần mềm Những điều sửa đổi cần mô tả, thiết kế, thực hồ nhập thử nghiệm thức tất nhiên, sửa đổi cần tài trợ nhân lực vật lực Do để thực giai đoạn bảo trì coi loạt dự án phần mềm nhỏ Kiểm tra cấu hình đặc biệt quan trọng thời gian bảo trì để quản lý thay đổi với phần mềm kiểm tra đợt phát hành phiên hệ thống Điều đảm bảo đợt phát hành định kỳ có trật tự phần mềm tránh hỗ trợ phiêu lưu khơng cố định trở thành ác mộng cơng trình Quản lý dự án tiến hành từ phát triển sản phẩm phần mềm sang giai đoạn bảo trì bảo trì địi hỏi đội nhỏ nhiều quản lý kiểu khác Trên thực tế, nhóm bảo trì thiết lập để bảo trì nhiều sản phẩm với quản lý chung, khống chế cấu hình kỹ thuật lắp đặt trường bảo trì tư liệu Tư liệu cần cập nhật giai đoạn bao gồm :      Tư liệu phát hành phiên Các báo cáo vấn đề Mọi tư liệu phát triển Mọi tư liệu người dùng Nhật ký bảo trì báo cáo dịch vụ khách hàng Bảo trì tiếp đọc chừng sản phẩm phầm mềm lắp đặt hoạt động Khi hệ thống già đi, kế hoạch chuẩn bị cho dự án phát triển thay cho hệ thống lão hoá Vào lúc đó, cố gắng bảo trì giảm tới mức tối thiểu kỳ vọng sửa đổi yêu cầu hiệu chỉnh sai số kỹ thuật có hệ thống 5.6 QUẢN LÝ GIAI ĐOẠN BẢO TRÌ Khái qt chung: Giai đoạn bảo trì bắt đầu khách hàng chấp nhận sản phẩm cần có thay đổi sản phẩm mã nguồn, tài liệu, hướng dẫn sử dụng…hay gọi tiến triển Sự cần thiết bảo trì: Trong chu trình sống phần mềm bảo trì giai đoạn cuối chu trình ta cần phải nói bảo trì giai đoạn vơ cần thiết vì: Khi thực quà trình nghiện cứu số lượng phần mềm lớn khó tránh khỏi sai sót Vì vậy, ta cần phải hiệu chỉnh lỗi đặt tả, thiết kế, tài liệu, mã nguồn hay dạng khác Trong đó, hiệu chỉnh chiếm khoảng 17.5% Về khâu hoàn thiện cần cần tới bảo trì khoảng 60.5% sai sót Nên ta cần phải thay đổi mã lệnh nhằm hoàn thiện hiệu sản phẩm Sau hoàn thiện đưa vào sử dụng để dạt hiệu cao ta cần bảo trì để phần mềm thích ứng khoảng 18% thay đổi nhằm tácđộng lại thay đổi Giáo viên biên soạn: Nguyễn Trần Phương 164 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống môi trường mà sản phẩm vận hành Khách hàng phải chịu khoảng chi phí Ngồi dạng kể cịn có khoảng 4% dạng khác Ví dụ: Khách hàng yêu cầu thêm số chức hay sửa đổi sản phẩm để tăng tốc độ xử lý nhằm để hoàn thiện Hay thay đổi trình biên dịch, hệ điều hành phần cứng để thích ứng Những quan tâm nhà lập trình bảo trì: Do trình bảo trì thật cần thiết nên đặt địi hỏi nhà lập trình bảo trì sau: Hồn thành thuật ngữ nhà lập trình bảo trì (maintenance prgrammer – MP) để nhóm lập trình viên thực cơng tác bảo trì phần mềm Bảo trì giai đoạn cuối chu kì phần mềm nên coi khía cạnh khó khăn nhất, nhiều thách thức sản phẩm phần mềm đụng chạm đến tất giai đoạn tiến trình dựng phần mềm Địi hỏi từ thực tế cho thấy cơng ty thường xem nhẹ cơng tác bảo trì hay giao cơng đoạn bảo trì cho lập trình viên Khi dễ nảy sinh trường hợp MP không đủ kinh nghiệm kỹ lần vết tốt việc xác định xác vị trí lỗi Bởi số trường hợp lỗi nảy sinh người sử dụng hướng dẫn sử dụng khơng xác lỗi mã nguồn gây Lỗi hồi qui địi hỏi khả quan sửa chửa lỗi có quan tâm đến lỗi khác sản phẩm Các nhà lập trình bảo trì cần phải chuẩn bị tài liệu chi tiết cho toàn sản phẩm mô-đun riêng biệt sau sửa chữa xong để cơng tác bảo trì cho lần sau sử dụng lại Và thực tế bảo trì xem dịch vụ hậu thuẫn nhằm giữ khách hàng cách cung cấp dịch vụ bảo trì tốt nhanh Đó chuẩn mực cấn có tất cơng ty kinh doanh phần mềm Quản lý bảo trì: Xây dựng chế cho phép có thay đổi sản phẩm thực việc bảo trì Lãnh đạo nhóm SQA - Nhóm đảo bảo chất lượng phần mềm [QLDAPM.ĐHQG] nhóm phát triển phần mềm phải độc lập Quản lý chặt việc báo cáo lỗi tránh việc sai sót thơng tin ban đầu cách:  Yêu cầu người sử dụng điền thông tin lỗi chức  Các báo cáo lỗi phải đủ thơng tin để MP tái tạo lại lỗi xảy Quản lý uỷ quyền thay đổi tên sản phẩm:  Xác định lỗi, thay đổi mã nguồn, cố định mã nguồn  Khó khăn thử qui hồi sản phẩm  Cập nhật tài liệu để phản ánh thay đổi  Có thể cập nhật liệu đặt tả thiết kế  Tạo phiên cần thiết  Chuyển đến nhóm SQA để xác nhận lại (nhưng không can thiệp vào công việc lập trình viên) Giáo viên biên soạn: Nguyễn Trần Phương 165 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống Bảo đảm cơng tác bảo trì:  Việc bảo trì cần phải thực nhiều lần  Tạo nhiều phiên để việc thẩm tra kiểm thử xác  Có kế hoạch bảo trì suốt trình phần mềm  Ghi nhận cẩn thận thông tin kỹ thuật để tái tạo sử dụng cần  Tài liệu phải hoàn tất hiệu chỉnh chu đáo, phản ánh xác thành phần phiên hành Vấn đề lặp lại cơng tác bảo trì:  Do khách hàng thường xun thay đổi yêu cầu nên việc bảo trì phải thay đổi thường xuyên tuỳ theo yêu cầu  Nên đưa mơ hình làm việc cụ thể có thay đổi phải trả thêm chi phí phát sinh Bảo trì phần mềm hƣớng đối tƣợng: Cơng tác bảo trì phần mềm hướng đối tượng có ưu nhược điểm sau: Ưu điểm: Dễ dàng bảo trì đối tượng do:  Các khái niệm độc lập với nên dễ dàng xác định vị trí lỗi, nhằm thực hiệu chỉnh hay nâng cao tuỳ theo yêu cầu  Các thay đổi tác động bên đối tượng nên giảm thiểu lỗi hồi quy Nhược điểm:  MP phải nghiên cứu tồn thừa kế  Khó khăn cài đặt ngơn ngữ lập trình hướng đối tượng vấn đề đa hình động  Khi lần vết nhà thừa kế liên tục có lớp có thay đổi tạo khó khăn đáng kể So sánh kỹ bảo trì kỹ phát triển: Khả Kỹ bảo trì Xác định nguyên nhân Hiệu chỉnh gây lỗi Thực hiệu chức mà khơng có Hồn thiện, thích ứng tài liệu thích hợp Nắm vững vấn đề liên Đòi hỏi quan giai đoạn Kỹ phát triển Kiểm thử tích hợp kiểm thử phát triển Đặc tả, thiết kế , cài đặt tích hợp, kiểm thử Địi hỏi Kiểm thử giai đoạn bảo trì: Khó khăn phải nắm vững toàn sản phẩm Cách tiến hành:  Sử dụng tình kiểm thử để đảm bảo sản phẩm vận hành tốt sau có cập nhật  Thay đổi số tình kiểm thử Giáo viên biên soạn: Nguyễn Trần Phương 166 Trường Trung học Kinh tế Kỹ thuật Hòa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống  Lưu trữ tồn tình kiểm thử với kết cần đạt tương ứng  Sử dụng kiểm thử hồi quy Đánh giá giai đoạn bảo trì: Sử dụng cách đánh giá cho giai đoạn liên quan q trính phát triển Ngồi cịn có:  Số lượng báo cáo lỗi  Phân loại lỗi theo độ khó kiểu lỗi  Thơng tin trạng thái hành báo cáo lỗi CÂU HỎI CHƢƠNG : Câu 5.6.1.1: Thuật ngữ “nhà lập trình bảo trì” có ý nghĩa nào? Câu 5.6.1.2: Bảo trì phần mềm hướng đối tượng gì? Tại bảo trì phần mềm hướng đối tượng cho dễ? Câu 5.6.1.3: Sử dụng kiểm thử hồi qui ? Nếu khơng có q trình khơng ? Câu 5.6.1.4: Giai đoạn bảo trì giai đoạn cuối chu trình sống phần mềm nói bảo trì có ảnh hưởng đến giai đoạn khác hay không ? Câu 5.6.1.5: Trong phần đánh giá phải đánh giá theo độ khó kiểu lỗi ? Câu 5.6.1.6: Nếu phần mềm game sau mua sử dụng thời gian xảy lỗi phần đồ hoạ có tốn chi phí bảo trì hay khơng ? Câu 5.6.1.7: Làm xác định điểm dừng cho bảo trì ? GỢI Ý TRẢ LỜI CÁC BÀI TẬP Trả lời câu 5.6.1.1: Nhà lập trình bảo trì lập trình viên thực cơng tác bảo trì có lỗi xảy hay có yêu cầu từ khách hàng Trả lời câu 5.6.1.2: Bảo trì phần mềm hướng đối tượng cơng tác bảo trì phần mềm mang tính chất hướng đối tượng Đây vấn đề đươc cho dễ cómthuận lợi định xảy lỗi dễ tìm kiếm khắc phục khơng sợ lỗi hồi qui Trả lời câu 5.6.1.3: Kiểm thử hồi qui thực cơng tác bảo trì phát lỗi giai đoạn ta phải sửa chữa lúc đo ta phải kiểm tra lại giai đoạn khác lỗi giai đoạn trước gây lỗi cho phần Nếu khơng có q trình cơng tác bảo trì khơng đảm bảo chất lượng phần mềm hoàn hảo yêu cầu đặt Trả lời câu 5.6.1.4: Theo mơ hình thác nước hình 3.2 chương 3(chu trình sống phần mềm) dã thấy rõ bảo trì có quan hệ với giai đoạn khác.Vd:Có khách hàng mua phần mềm ta viết sử dụng sau thời gian họ yêu cầu ta sửa đổi cấu trúc cho phù hợp với thời điểm hành cơng tác bảo trì đươc thực thay đổi theo yêu cầu khách hang dã phải làm việc sửa đổi giai đoạn khác Trả lời câu 5.6.1.5: ta thực bảo trì cần phải xác định lỗi xảy nguyên nhân từ đâu lỗi khách hang sử dụng cần xác định thêm độ khó để biết chi phí khắc phục mà khách hàng phải chịu Trả lời câu 5.6.1.6: Vì phần mềm bạn mua sử dụng sau khoảng thời gian nên MP phải xác đinh lại lỗi mã nguồn hay người sử dụng Giáo viên biên soạn: Nguyễn Trần Phương 167 Trường Trung học Kinh tế Kỹ thuật Hịa Bình – Ngành Cơng nghệ Thơng tin - Mơn Phân tích & Thiết kế hệ thống mã nguồn gây lỗi bạn cấp phần mềm không lỗi đáp ứng yêu cầu bạn Ngược lại bạn phải trả chi phí cho hoạt động bảo trì Trả lời câu 5.6.1.7: Đối với tất phần mềm có quyền nhà cưng cấp ký với người sử dụng hợp đồng thời gian bảo hành điều khoản cơng tác bảo hành.Vì nói điểm dừng bảo hành chinh thời gian bảo hành vấn đề cần phải biết điều khoản bảo hành TÀI LIỆU THAM KHẢO [GTPTTK.ĐHQG] - Đào Kiến Quốc, Giáo trình phân tích thiết kế hệ thống thơng tin tin học hóa, Hà Nội 2000 [QLDAPM.ĐHQG] - Quản lý dự án phần mềm, Khoa Công nghệ Thông tin Đại học Quốc gia Hà Nội [TĐQ&NMS.PTTK] – Trần Đình Quế, Nguyễn Mạnh Sơn, Phân tích thiết kế hệ thống thông tin, Học viện Công nghệ Bưu Viễn Thơng Tham khảo nhiều tác giả - www.moet.gov.vn - Phân tích thiết kế hệ thống tin học Tham khảo nhiều tác giả - www.quantrimang.com - Phân tích thiết kế hệ thống tin học Giáo viên biên soạn: Nguyễn Trần Phương 168