Thực tế một vài yêu cầu bảo hành có thể đòi hỏi không được thay đổi thiết kế của phần mềm hoặc mã chương trình, mà chỉ cần chỉ ra sự thiếu rõ ràng trong tài liệu của người sử dụng.. Tron[r]
(1)CHƯƠNG 7
BẢO TRÌ PHẦN MỀM
VÀ QUẢN LÝ THAY ĐỔI PHẦN MỀM
Bảo trì giai đoạn cuối chu trình phát triển phần mềm Các chương trình máy tính thay đổi- phải mở rộng, sửa lỗi, tối ưu hố, theo thống kê bảo trì chiếm đến 70% tồn cơng sức bỏ cho dự án phần mềm Do vậy, bảo trì hoạt động phức tạp lại vơ cần thiết chu trình sống sản phẩm phần mềm để đảm bảo cho phần mềm phù hợp với người sử dụng
Do nhu cầu phát triển hệ thống thơng tin, hay khơng muốn nói khơng thể có hệ thống thơng tin khơng có thay đổi suốt chu trình sống Để trì tính đắn, trật tự giai đoạn bảo trì quản lý thay đổi phần mềm hoạt động cần thiết song song
7.1 HOẠT ĐỘNG BẢO TRÌ PHẦN MỀM VÀ PHÂN LOẠI
Bảo trì phần mềm phức tạp chia hoạt động bảo trì làm bốn hoạt động sau:
1 Bảo trì hiệu chỉnh
Cơng việc bảo trì cần phải thực việc kiểm tra chương trình tránh mội lỗi ẩn chứa bên hệ phần mềm lớn Trong sử dụng bất kỹ chương trình lớn nào, lỗi báo lại cho người phát triển
Bảo trì hiệu chỉnh q trình phân tích hiệu chỉnh hay nhiều lỗi chương trình
2 Bảo trì tiếp hợp
Hoạt động thứ hai diễn thay đổi thường xuyên môi trường Những hệ phần cứng dường công bố theo chu trình 24 tháng lần Những hệ điều hành hay phiên hệ cũ đặn xuất hiện; thiết bị ngoại vi thành phần hệ thống khác liên tục nâng cấp thay đổi Thời gian hữu dụng phần mềm ứng dụng mặt khác lại dễ dàng vượt qua thời hạn mười năm, lâu môi trường hệ thống phát triển
(2)3. Bảo trì hồn thiện
Hoạt động thứ ba diễn phần mềm hoàn tất thành công Hoạt động chiếm hầu hết cơng sức tiêu tốn cho việc bảo trì phần mềm Lúc sử dụng, yêu cầu khả mới, thay đổi chức có, mở rộng tổng quát người dùng gửi đến
Để thỏa mãn yêu cầu phát triển người sử dụng, ta tiến hành bảo trì hồn thiện
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ì
7.2 ĐẶC ĐIỂM CỦA 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, vầ 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 để hồn thành giai đoạn bảo trì tính tồn vẹn
một 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
7.2.1 Bảo trì có cấu trúc bảo trì khơng cấu trúc.
(3)với tài liệu nghèo nàn bên Những đặc điểm tế nhị cấu trúc phần mềm, cấu trúc liệu toàn cục, giao diên hệ thống,hoạt động ràng buộc thiết kế thường khó sáng tỏ hay bị hiểu lầm Các thay đổi lặt vặt thường xuyên làm cho mã khó đánh giá Các kiểm tra hồi quy (lặp lại kiểm tra trước để đảm bảo thay đổi không tạo lỗi phần mềm hoạt động) thực lưu kiểm tra Chúng ta tiến hành phép bảo trì khơng cấu trúc phải trả giá (khi lãng phí cơng sức gây tâm trạng thất vọng) Sự trả giá kèm với phần mềm không phát triển theo phương pháp đắn
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 ácc 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ấ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
7.2.2 Giá thành bảo trì
Theo thống kê, giá thành cho việc bảo trì phần mềm tăng lên cách đặn suốt 20 năm qua Trong năm 1970, bảo trì chiếm đến 35 đến 40 phần trăm kinh phí phần mềm dành cho tổ chức hệ thống thông tin.Tỷ lệ nhảy tới số 60 vào năm 1980 Và nhiều cơng ty chi 80% kinh phí cho việc bảo trì vào năm 1990
Chi phí cho việc bảo trì rõ ràng Tuy nhiên chi phí khác khó thấy gây mối quan tâm lớn hơn:
Một chi phí khó xác định việc bảo trì phần mềm hội phát triển
bị bỏ qua tài nguyên có sẵn dành cho nhiệm vụ bảo trì
Sự khơng hài lịng người dùng yêu cầu hợp lý cho việc
sửa chữa hay sửa đổi không ý cách hợp lý
Việc suy giảm chất lượng nói chung lỗi tạo thay đổi
phần mềm bảo trì
Một yêu cầu làm ngắt quãng trình phát triển nhân viên
buộc tiến hành cơng việc bảo trì
(4)là chi phí cho việc phát triển trị giá $25.00 dịng lệnh trị giá tới $1000.00 cho việc bảo trì dịng lệnh
Cơng sức cho việc bảo trì phân chia thành thao tác làm việc: phân tích, ước lượng, thay đổi thiết kế, sửa chữa chương trình nguồn thao tác lặp lại: việc cố gắng hiểu chương trình nguồn làm gì, cố gắng sáng tỏ cấu trúc liệu, thuộc tính giao diện, giới hạn việc thực hiện, Biểu thức cung cấp mơ hình cho cơng việc bảo trì:
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:
7.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 ln ln 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
bản Các thay đổi không tư liệu hóa
Khó theo dõi trình xử lý tạo phần mềm
Thường xuyên gặp nhiều khó khăn việc tìm hiểu chương trình
người khác viết Những khó khăn tăng lên số thành phần cấu Cài đặt
Kiểm thử Bảo trì
(5)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ì 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 liên quan tới sai lệch mức độ cao 7.3 CƠNG VIỆC BẢO TRÌ PHẦN MỀM VÀ MỘT SỐ HIỆU ỨNG LỀ 7.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
7.3.1.1 Yếu tố kiểm soát
Khả bảo trì bao gồm nhiều yếu tố Sự thiếu cẩn trọng việc thiết kế, viết chương trình nguồn, kiểm tra có ảnh hưởng tiêu cực đến việc bảo trì có kết phần mềm Cấu hình yếu có tác động tương tự, chí bước kỹ thuật xây dựng phần mềm xem xét cách cẩn thận Thêm vào nhiều yếu tố khác liên quan tới phương pháp phát triển phần mềm, như:
Chất lượng hiệu đội ngũ phần mềm Cấu trúc hệ thống dễ hiểu
Dễ dàng kiểm soát hệ thống
Dùng ngơn ngữ lập trình chuẩn Dùng hệ điều hành chuẩn Dùng cấu trúc chuẩn tài liệu Dùng tài liệu kiểm tra Phương tiện gỡ rối kèm
Dùng máy tính tốt để thực việc bảo trì
(6)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
7.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õ
7.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 u cầu tới người quản lý hệ thống để đánh giá người quản lý hệ thống thành viên nhóm nhân viên kỹ thuật Những nhân viên có trách nhiệm phần nhỏ chương trình sản phẩm Khi môth yêu cầu đánh giá, người ủy quyền quản lý việc thay đổi phải định hhành động thực tiếp
Cơ cấu miêu tả phục vụ cho việc thiết lập phạm vi trách nhiệm cơng việc bảo trì Người kiểm soát người ủy quyền quản lý việc thay đổi người nhóm quản lý chuyên gia kỹ thuật cao cấp
7.3.2.2 Báo cáo
(7)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 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,
7.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
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ì
7.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
(8) 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ì
7.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:
7.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
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
7.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
(9)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 yêu cầu bảo hành địi hỏi khơng thay đổi thiết kế phần mềm mã chương trình, mà cần thiếu rõ ràng tài liệu người sử dụng Trong trường hợp nổ lực bảo trì tập trung vào tài liệu
7.4 MỘT SỐ HÌNH THỨC BẢO TRÌ PHẦN MỀM 7.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 nữa,
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
nữa
Đừ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
(10) 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
7.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 khơng phải 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ữ đặc tả Do tổ chức ngược phần mềm q 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 q 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ý
7.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,và
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ế
hiện làm cho việc bảo hành tương lai dễ dàng
Bởi khuôn mẫu phần mềm tồn tại, suất phát triển chương trình
chắc 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
và 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
hiện 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
(11)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
7.4.4 Chiến lược phần mềm thành phần
Như đặc tính cổ điển bảo hành phần cứng tháo bỏ phần hỏng thay phụ tùng Một khái niệm gọi nguyên mẫu phần mềm dẫn tới việc phát triển phụ tùng cho chương trình
Nguyên mẫu phần mềm q trình mơ hình hóa yêu cầu dùng hay nhiều mức chi tiết, bao gồm mơ hình làm việc Các tài nguyên dự án xếp đặt để sản xuất phiên phần mềm mô tả theo yêu cầu phải nhỏ Phiên nguyên mẫu làm cho người dùng, người thiết kế quản trị xem lại phần mềm Quá trình tiếp tục đề nghị, với phiên chạy chuẩn bị sẵn sàng phát hành sau vài lần làm lại
Nếu mức nguyên mẫu khác phát triển, có phụ tùng phần mềm sử dụng nhận yêu cầu bảo trì hiệu chỉnh Ví dụ module phân tích thiết kế thực theo hai cách khác có giao diện bên 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
7.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õ u cầu mình,
Các thay đổi yêu cầu, thiết kế, chương trình, giao diện, phần cứng phần mềm phải mua Phần lớn thay đổi bắt nguồn từ bên tổ chức phát triển ứng dụng, kích hoạt từ tác nhân bên 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ý 7.5.1 Các thủ tục quản lý thay đổi
(12)Dưới ví dụ trình thao tác yêu cầu thay đổi đặc tả chức năng:
Tạo yêu cầu mở Khai báo file tác động
Phê chuẩn file thời gian chi phí chủ, người sử dụng ký
Hoàn thiện danh sách kiểm soát thay đổi người điều hành dự án File tài liệu liên quan đến thay đổi Nếu tài liệu chương trình bị thay
đổi, xác định ngày mục cập nhật hoàn thiện Nếu thủ tục thử nghiệm bị thay đổi, xác định ngày mà việc sửa đổi xảy
Mẫu yêu cầu đóng file chủ/người sử dụng thơng qua Tóm tắt ngày tháng, 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 yêu cầu chức thơng qua đóng băng ứng dụng hoạt động Các thay đổi phải chịu điều khiển thay đổi: chúng thêm vào danh sách yêu cầu thay đổi để xem xét tương lai trừ thiết kế khẩn cấp
Một thủ tục điều khiển thay đổi yêu cầu người sử dụng phải đệ trình lời yêu cầu thay đổi thức cho người điều hành dự án:
Người sử dụng gửi cho người điều hành dự án người chủ mẫu yêu
cầu thay đổi
Người điều hành dự án kỹ sư phần mềm triển khai khai báo tự động
Vào lúc đó, danh sách kiểm soát người điều hành dự án dùng để xác định tất hoạt động thay đổi cơng việc có liên quan tới u cầu
Yêu cầu thay đổi thảo luận với chủ sử dụng để vạch thay đổi
(13) 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 yêu cầu yêu cầu đóng
Người điều hành dự án kỹ sư phần mềm định nghĩa tác động tiến
trình chi phí thay đổi Sau thay đổi bàn bạc với người sử dụng Dựa thương lượng với người sử dụng, thay đổi gán ưu tiên hoạt động, chi phí tiến trình thay đổi
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 hồ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
7.5.2 Ghi định theo thời gian
(14)7.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
Câu hỏi
1 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ì?
3 Các hoạt động bảo trì phần mềm yếu? Các khó khăn hoạt động bảo trì?
(15)TÀI LIỆU THAM KHẢO
1 Ngô Trung Việt, Kỹ nghệ phần mềm - dịch, Nhà xuất Giáo dục, 1999 Đồ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
3 Lê Đức Trung, Công nghệ phần mềm, Nhà xuất Khoa học Kỹ thuật, 2002
4 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
5 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
6 Roger S Pressman Ph.D, Software engineering a practitioner's - 5th,
McGraw-Hill book Co.-Singapore, 2001
7 Yourdon, E Software reuse, Application development strategies, Vol 6, No 12, December 1994, pp.1-16
8 Sommerville I., Software engineering - 4th, Addison Wesley, 1995.