Công nghệ phần mềm chương 4

Bài giảng - Tiến hóa Phần mềm Phần - Tiến hóa phần mềm - Động lực tiến hóa phần mềm - Bảo trì phần mềm - Quản lý hệ thống kế thừa Tiến hóa phần mềm 1.1 Giới thiệu Tiến hóa phần mềm điều khơng thể tránh khỏi lí sau: - Những u cầu hình thành sử dụng phần mềm - Môi trường nghiệp vụ thay đổi - Các lỗi phần mềm cần phải sửa chữa - Máy tính thiết bị bổ sung vào hệ thống - Hiệu độ tin cậy hệ thống phải cải thiện Tuy nhiên, vấn đề quan trọng phải cài đặt /thực quản lý thay đổi hệ thống phần mềm tồn tại/ vấn đề hệ thống Và phải thấy tầm quan trọng việc tiến hóa phần mềm: 1.2 Tầm quan trọng tiến hóa - Các tổ chức thường đầu tư lượng vốn lớn vào hệ thống phần mềm họ Cho nên họ có quyền đòi hỏi phải sở hữu hệ thống hoàn hảo - Để bảo trì giá trị sở hữu tổ chức, họ phải thay đổi cải tiến hệ thống - Ngân sách phần mềm cơng ty lớn thường dùng cho việc cải tiến hệ thống tồn phát triển hệ thống Người ta thường sử dụng mơ hình xoắn ốc để cải tiến hệ thống phần mềm 1.3 Mơ hình xoắn ốc phát triển tiến hóa giai đoạn - Initial: giai đoạn khởi đầu Sự phát triển - Khi phần mềm đâng vận hành có yêu cầu duodcj đề xuất - Yêu cầu tiến hóa phần mềm cho hệ thống tạm thời Evolution Các giai đoạn vòng đời hệ thống phần mềm, nơi sử dụng vào hoạt động thay đổi yêu cầu đề xuất thực hệ thống Phục vụ (servicing) Ở giai đoạn này, phần mềm hữu ích phải thực thay đổi để đảm bảo phần mềm thực được: sửa lỗi, đáp ứng thay đổi môi trường vận hành phần mềm không bổ sung thêm chức Kết thúc Phần mềm sử dụng không thực thêm thay đổi 1.4 Quy trình tiến hóa phần mềm Q trình tiến hóa phần mềm phụ thuộc vào: - Kiểu phần mềm bảo trì - Quy trình phát triển sử dụng - Phụ thuộc vào kỹ năng, kinh nghiệm người tham gia * Tác nhân thay đổi tiến hóa hệ thống - Đề xuất thay đổi phần mềm - Liên kết thành phần ảnh hưởng tới thay đổi, ước tính chi phí cho thay đổi -Xác nhận thay đổi, cập nhật, tiến hóa phần mềm liên tục thời gian tồn hệ thống Quá trình phát triển phần mềm Thay đổi thực Lặp lại trình phát triển, nơi sửa đổi cho hệ thống thiết kế, thực thử nghiệm Sự khác biệt quan trọng giai đoạn đầu việc thực thay đổi liên quan đến hiểu biết chương trình, đặc biệt nhà phát triển hệ thống ban đầu không chịu trách nhiệm thực thay đổi Trong giai đoạn hiểu biết chương trình, bạn phải hiểu cách thức chương trình cấu trúc, cách thức cung cấp chức thay đổi đề xuất ảnh hưởng đến chương trình Yêu cầu thay đổi - Cần hiểu chương trình đặc biệt người thiết kế ban đầu không hiểu được: ảnh hưởng đề xuất thay đổi, cấu trúc, phương thức hoạt động chương trình * Nhóm thay đổi khẩn cấp Thay đổi khẩn cấp phải thực mà khơng qua tất giai đoạn quy trình xây dựng phần mềm : - Nếu lỗi hệ thống nghiêm trọng cần phải sửa chữa phép hoạt động bình thường để tiếp tục; - Nếu thay đổi mơi trường hệ thống (ví dụ nâng cấp hệ điều hành) gây ảnh hưởng ngồi dự đốn - Nếu có thay đổi nghiệp vụ, yêu cầu phản ứng nhanh (ví dụ việc phát hành sản phẩm cạnh tranh) Quy trình thay đổi khẩn cấp Change request – Analyze source code- Modifity source code – Deliver modifilier system mối liên hệ Các phương pháp Linh hoạt tiến hóa Các phương pháp Linh hoạt dựa phát triển tăng dần , chuyển đổi từ phát triển sang tiến hóa liền mạch, liên tục Tiến hóa đơn giản tiếp tục trình phát triển dựa phát hành thường xuyên hệ thống Kiểm thử hồi quy tự động đặc biệt có giá trị có thay đổi hệ thống Những thay đổi thể kịch người dùng thêm vào Vấn đề bàn giao/ chuyển giao - Trường hợp nhóm phát triển sử dụng cách tiếp cận linh hoạt đội ngũ tiến hóa khơng quen thuộc với phương pháp linh hoạt thích cách tiếp cận theo kế hoạch - Nhóm tiến hóa mong đợi tài liệu hướng dẫn chi tiết để hỗ trợ tiến hóa điều khơng tạo quy trình nhanh Trường hợp cách tiếp cận dựa kế hoạch sử dụng để phát triển nhóm tiến hóa thích sử dụng phương pháp nhanh nhẹn Nhóm nghiên cứu tiến hóa xây dựng kiểm thử tự động mã hệ thống khơng có tái cấu trúc đơn giản dự kiến phát triển linh hoạt Động lực tiến hóa phần mềm việc nghiên cứu quY trình thay đổi hệ thống - Sau nhiều nghiên cứu thực nghiệm lớn, Lehman Belady đề xuất có số 'luật' mà áp dụng cho tất hệ thống tiến hóa - Được áp dụng cho hệ thống lớn phát triển tổ chức lớn Không rõ ràng điều áp dụng cho loại khác hệ thống phần mềm Các yêu cầu hệ thống thay đổi Trong hệ thống phát triển Mơi trường thay đổi Vì Hệ thống khơng đáp ứng u cầu nó! – cần phải thay đổi để đáp ứng Các hệ thống kết hợp chặt chẽ với môi trường chúng Khi hệ thống cài đặt Môi trường làm thay đổi mơi trường Do thay đổi yêu cầu hệ thống Hệ thống phải thay đổi họ Sẽ hữu ích mơi trường 2.2 Luật Lehman Pháp luật Mô tả Liên tục thay đổi Một chương trình sử dụng môi trường thực tế cần phải thay đổi, trở nên hữu ích mơi trường không giá trị sử dụng ngày suy giảm Sự gia tăng tính Khi chương trình giai đoạn tiến hóa thay đổi, cấu phức tạp trúc có xu hướng trở nên phức tạp Cần có thêm nguồn lực bổ sung dành cho việc bảo vệ đơn giản hóa cấu trúc chương trình Tiến triển chương Tiến trình chương trình quy trình tự điều chỉnh Các trình lớn thuộc tính hệ thống kích thước, thời gian phát hành, số lỗi gần không đổi cho phiên hệ thống Ổn định tổ chức Trong suốt trình tồn chương trình, tốc độ phát triển xấp xỉ không phụ thuộc vào nguồn lực dành cho việc phát triển hệ thống / cần đáp ứng nhanh, rút ngắn thời gian phát triển Luật Lehman Pháp luật Mô tả Bảo tồn quen Trong suốt thời gian tồn hệ thống, thay đổi tăng dần thuộc phiên gần không đổi./ thường chọn số lượng chức khơng có q nhiều thay đổi Tiếp tục phát triển Các chức cung cấp hệ thống phải liên tục gia tăng để trì hài lòng người dùng Chất lượng giảm Thường xuyên thay đổi nhằm cải thiện chất lượng sản phẩm phản ánh thay đổi môi trường hoạt động chúng Hệ thống phản hồi Các quy trình tiến hóa nên kết hợp nhiều hệ thống phản hồi đa tác từ, phản hổi lần lặp, giúp đạt cải thiện đáng kể sản phẩm 2.3 Khả áp dụng luật Lehman - Luật Lehman 's dường áp dụng chung cho hệ thống lớn, phù hợp, tùy chỉnh phát triển tổ chức lớn Xác nhận vào đầu năm 2000 dự án Lehman - Được xem xét có phù hợp hay khơng? + Các sản phẩm phần mềm gói gém + Các hệ thống tích hợp số lượng đáng kể thành phần thương mại COTS; + Các tổ chức nhỏ; + Hệ thống có kích thước trung bình * Những điểm Phát triển phần mềm tiến hóa coi q trình tích hợp, lặp lặp lại biểu diễn sử dụng mơ hình xoắn ốc Đối với hệ thống tùy chỉnh, chi phí bảo trì phần mềm thường vượt q chi phí phát triển phần mềm Quy trình phát triển phần mềm thúc đẩy yêu cầu thay đổi bao gồm phân tích ảnh hưởng thay đổi, đưa kế hoạch thay đổi thực thay đổi Luật Lehman 's, chẳng hạn quan điểm cho thay đổi liên tục, mô tả số hiểu biết sâu sắc bắt nguồn từ nghiên cứu lâu dài q trình tiến hóa hệ thống Bài giảng - Tiến hóa Phần mềm Phần Sửa đổi chương trình sau đưa vào sử dụng - Bảo trì phần mềm pha cuối quy trình hệ thống phần mềm - Các hoạt động cần thực hiện: + Quản lý hoạt động bảo trì - Hiểu kỹ yêu cầu bảo trì - Phân loại yêu cầu: sửa đổi hay nâng cấp - Thiết kế thay đổi yêu cầu - Kế hoạch thay đổi từ thiết kế cũ - Đánh giá ảnh hưởng thay đổi - Triển khai thay đổi - Thực kiểm thử cho thành phần thay đổi - Tiến hành kiểm thử tăng dần, thực kiểm thử hệ thống với khả - Cập nhật tài liệu cấu hình, yêu cầu, thiết kế kiểm thử + Chuẩn hóa hoạt động bảo trì (IEEE 840-1992) - Xác định vấn đề - Phân tích - Thiết kế - Triển khai - Kiểm thử hệ thống - Kiểm thử chấp nhận - Chuyển giao phần mềm Thuật ngữ chủ yếu sử dụng để thay đổi phần mềm tuỳ chỉnh Các sản phẩm phần mềm nói chung phát triển để tạo phiên - huớng đối tượng người dùng cụ thể, liên quan đến phiên tiến hóa, tạo phần mềm Bảo trì phần mềm thường không liên quan đến thay đổi lớn đến kiến trúc hệ thống Thay đổi thực cách sửa đổi thành phần có bổ sung thêm thành phần vào hệ thống Các kiểu Bảo trì phần mềm - Bảo trì sửa chữa khiếm khuyết ( lỗi) phần mềm Thay đổi hệ thống để sửa chữa thiếu sót cách đáp ứng yêu cầu - Bảo trì để phần mềm thích ứng với mơi trường vận hành khác: môi trường thay đổi dẫn tới phải thay đổi phần mềm cho phù hợp - Thay đổi hệ thống để hoạt động mơi trường khác (máy tính, hệ điều hành, v.v ) từ triển khai ban đầu - Bảo trì để bổ sung chỉnh sửa chức hệ thống: chỉnh sua để đáp ứng yêu cầu Các loại bảo trì Hình 9.8 Phân bố nỗ lực bảo trì - Thường lớn chi phí phát triển (2 * 100 * tùy thuộc vào ứng dụng) - Chi phí Bị ảnh hưởng yếu tố kỹ thuật phi kỹ thuật Khi bảo trì có xu hướng phá vỡ cấu trúc ban đầu, gia tăng theo thời gian, làm cho việc bảo trì thêm khó khăn, phức tạp - Phần mềm có khả sử dụng bền vững có chi phí hỗ trợ cao (Ví dụ ngơn ngữ cũ, trình biên dịch cũ…) Chi phí bảo trì Hình Chi phí phát triển bảo trì * Các yếu tố ảnh hưởng đến chi phí bảo trì + Tính ổn định đội ngũ phát triển - Chi phí bảo trì giảm nhân viên tham gia với họ khoảng thời gian - Trách nhiệm tham gia hợp đồng Các nhà phát triển hệ thống khơng có trách nhiệm hợp đồng để tham gia bảo trì nên khơng có động lực để thiết kế cho thay đổi tương lai - Kỹ thành viên đội ngũ thiếu kinh nghiệm kiến thức hạn chế lĩnh vực ứng dụng - Tuổi thọ cấu trúc chương trình Khi chương trình sử dụng lâu cấu trúc thường bị suy thối chúng trở nên khó hiểu khó thay đổi Dự đốn bảo trì Dự đốn bảo trì quan tâm đến việc đánh giá thành phần hệ thống gây vấn đề có chi phí bảo trì cao - Thay đổi chấp nhận phụ thuộc vào khả bảo trì phận bị ảnh hưởng thay đổi - Thực thay đổi làm thối hóa hệ thống giảm tính bảo trì hệ thống đó; - Chi phí bảo trì phụ thuộc vào số lần thay đổi chi phí thay đổi tùy thuộc vào khả bảo trì phần mềm Thay đổi dự đoán - Dự đoán số lượng thay đổi cần thiết hiểu biết mối quan hệ hệ thống mơi trường Từ thay đổi xác định thay đổi khác có liên quan - Các hệ thống có mối quan hệ thay đổi đòi hỏi phải thay đổi môi trường thay đổi - Các yếu tố ảnh hưởng đến mối quan hệ + Số lượng phức tạp giao diện hệ thống; + Số lượng yêu cầu hệ thống vốn hóa dễ bị thay đổi; + Số lượng quy trình nghiệp vụ mà hệ thống sử dụng Tham số đo phức tạp - Các dự đoán khả bảo trì thực cách đánh giá tính phức tạp thành phần hệ thống - Các nghiên cứu hầu hết nỗ lực bảo trì dành cho số lượng tương đối nhỏ thành phần hệ thống Những thành phần phức tạp đòi hỏi khả bảo trì nhiều - Độ phức tạp phụ thuộc vào: + Tính phức tạp cấu trúc điều khiển; + Tính phức tạp cấu trúc liệu; + Đối tượng, phương pháp (thủ tục) kích thước mơ-đun Tham số đo quy trình - sử dụng để đánh giá khả bảo trì + Số lượng yêu cầu bảo trì sửa chữa; + Thời gian trung bình cần thiết cho phân tích ảnh hưởng thay đổi tác động đến thành phần khác; + Thời gian trung bình cần có để thực u cầu thay đổi; + Số lượng yêu cầu thay đổi bật Nếu tất yếu tố gia tăng, điều cho thấy khả bảo trì bị suy giảm Tái xây dựng hệ thống Cấu trúc lại viết lại phần tất hệ thống kế thừa mà không thay đổi chức hệ thống Áp dụng số tất hệ thống lớn cần bảo trì thường xuyên Kỹ thuật tái xây dựng bao gồm việc thêm công việc để hệ thống dễ bảo trì Hệ thống tái cấu trúc xây dựng lại Ưu điểm việc tái cấu trúc, tái xây dựng hệ thống - Giảm thiểu rủi ro: phát triển phần mềm thường có nguy rủi ro cao vấn đề biên chế đặc điểm kỹ thuật - Giảm thiểu chi phí: thường đáng kể so với phát triển hệ thống Hình 9.12 Phương pháp tái cấu trúc Các hoạt động quy trình tái cấu trúc - Dịch mã nguồn (Source code translation): chuyển đổi chương trình sang ngơn ngữ - Kỹ thuật xây dựng đảo ngược: sinh biểu đồ lớp…, tài liệu thiết kế nhằm phân tích, hiểu chương trình dễ dàng - Cải thiện cấu trúc chương trình : tăng khả hiểu - Mơ đun hóa chương trình - Tái cấu trúc liệu: Dọn dẹp tái cấu liệu hệ thống - Cấu trúc liệu (Data reengineering) Yếu tố chi phí ảnh hưởng đến tái cấu trúc hệ thống - Chất lượng phần mềm cần điều chỉnh lại - Công cụ hỗ trợ sẵn sàng cho việc tái xây dựng - Quy mô việc chuyển đổi liệu yêu cầu - Sự sẵn sàng đội ngũ chuyên gia cho việc tái xây dựng Đây vấn đề với hệ thống cũ dựa cơng nghệ khơng sử dụng rộng rãi Bảo trì tính phòng tránh thơng qua hoạt động tái cấu trúc Tái cấu trúc lại trình cải tiến chương trình làm chậm lại thối hóa thực thay đổi Tái cấu trúc hoạt động 'bảo trì' có tính phòng tránh làm giảm thiểu vấn đề thay đổi tương lai Tái cấu trúc bao gồm việc sửa đổi chương trình để cải thiện cấu trúc, giảm độ phức tạp làm cho chương trình dễ hiểu Khi tái cấu trúc lại chương trình, không nên thêm chức mà nên tập trung vào việc cải thiện chương trình Mối quan hệ Tái cấu trúc lại tái xây dựng Tái xây dựng thực sau hệ thống trì khoảng thời gian chi phí bảo trì tăng Khi sử dụng cơng cụ tự động để xử lý tái thiết kế hệ thống kế thừa để tạo hệ thống trì tốt Tái cấu trúc trình liên tục q trình phát triển q trình tiến hóa nhằm tránh thối hóa cấu trúc chương trình, điều làm gia tăng chi phí khó khăn việc bảo trì hệ thống * Phần chương trình xấu Mã chương trình trùng lặp - Đoạn chương trình lặp lại nơi khác chương trình Điều loại bỏ thực phương thức hàm thay Phương thức dài - Nếu phương thức dài, cần thay phương thức ngắn Câu lệnh switch – case: việc chuyển đổi thực thi Trong ngôn ngữ hướng đối tượng, thường sử dụng tính đa hình để đạt yêu cầu mong muốn: Sự trùng lặp liệu - Các mục liệu xuất nhiều nơi chương trình Chúng thường thay việc tạo đối tượng chứa tất liệu Tính khái qt hóa q mức - Điều xảy nhà phát triển định khái qt hóa chương trình để sử dụng tương lai Điều thường loại bỏ chưa cần thiết Quản lý hệ thống kế thừa( di sản) - Các tổ chức phụ thuộc vào hệ thống di sản phải chọn chiến lược để phát triển hệ thống -+ Loại bỏ hoàn toàn hệ thống, điều chỉnh quy trình nghiệp vụ khơng quan trọng hệ thống ( tiến hóa quy trình làm việc) + Tiếp tục bảo trì hệ thống; + Tiếp tục Chuyển đổi hệ thống cách cải tiến kỹ thuật để nâng cao khả bảo trì; + Thay hệ thống hệ thống - Chiến lược lựa chọn phải phụ thuộc vào chất lượng hệ thống giá trị nghiệp vụ Hình 9.13 Một ví dụ đánh giá hệ thống kế thừa * Các nhóm hệ thống - Chất lượng thấp, giá trị nghiệp vụ thấp: loại bỏ hệ thống - Chất lượng thấp, giá trị nghiệp vụ cao: Đây đóng góp quan trọng tốn để bảo trì Nên tái xây dựng lại thay có hệ thống phù hợp - Chất lượng cao, giá trị nghiệp vụ thấp: chọn chiến lược thay phần mềm thương mại thị trường; có chọn chiến lược thay thế, loại bỏ bảo trì - Chất lượng cao, giá trị kinh doanh cao: chọn chiến lược Tiếp tục hoạt động cách sử dụng bảo trì hệ thống thông thường Đánh giá giá trị nghiệp vụ - Khi Đánh giá cần tính đến quan điểm khác nhau: + Từ quan điểm Người dùng cuối hệ thống; + Từ quan điểm Khách hàng; + Quản lý chuỗi dây chuyền; + Quản lý CNTT; + Quản lý có tham niên - Để có quan điểm thực thơng qua Phỏng vấn thu thập kết Tiêu chí đánh giá giá trị nghiệp vụ - Đánh giá Dựa Việc sử dụng hệ thống: Nếu hệ thống sử dụng sử dụng số người, có giá trị kinh doanh thấp - Các quy trình nghiệp vụ hỗ trợ hệ thống: Một hệ thống có giá trị nghiệp vụ thấp buộc phải sử dụng quy trình nghiệp vụ khơng hiệu - Đánh giá dựa Tính tin cậy hệ thống: hệ thống không đáng tin cậy vấn đề trực tiếp ảnh hưởng đến khách hàng hệ thống có giá trị nghiệp vụ thấp - Dựa đầu hệ thống: doanh nghiệp phụ thuộc vào đầu hệ thống hệ thống có giá trị nghiệp vụ cao Đánh giá chất lượng hệ thống - Đánh giá dựa quy trình nghiệp vụ: xem hỗ trợ cho mục tiêu nghiệp vụ tổ chức tốt nào? - Đánh giá môi trường: đánh giá độ hiệu mơi trường chi phí bảo trì hệ thống - Đánh giá ứng dụng: xem xét chất lượng phần mềm ứng dụng Đánh giá quy trình nghiệp vụ - Sử dụng phương pháp tiếp cận định hướng theo quan điểm tìm kiếm câu trả lời từ bên liên quan đến hệ thống: + Có mơ hình quy trình định nghĩa tuân thủ hay không? + Các phận khác tổ chức có sử dụng quy trình khác cho chức không? + Quy trình điều chỉnh, thích nghi nào? + Mối quan hệ với quy trình nghiệp vụ khác quan hệ có cần thiết hay khơng? + Quy trình nghiệp vụ có hỗ trợ hiệu phần mềm ứng dụng di sản hay không? - Ví dụ: Một hệ thống đặt tour du lịch có giá trị nghiệp vụ thấp sử dụng rộng rãi việc đặt hàng dựa web Các yếu tố sử dụng đánh giá môi trường Tham số Câu hỏi Tính ổn định nguồn - Bộ phận cung ứng tồn hay khơng? cung ứng - Bộ phận cung ứng có ổn định tài có khả tiếp tục tồn tại? - Nếu phận cung ứng khơng hoạt động có bảo trì hệ thống? Tỷ lệ cố -Phần cứng có phải tỉ lệ cố báo cáo cao hay không? - Liệu phần mềm hỗ trợ gặp cố có khiến khởi động lại hệ thống hay không? Tuổi thọ - Tuổi thọ phần cứng, phần mềm gì? - Các phần cứng phần mềm hỗ trợ cũ hoạt động nhanh chóng lỗi thời Nếu chuyển sang hệ thống tảng đạt lợi ích kinh tế, lợi ích nghiệp vụ cao Hiệu hệ thống - Hiệu hệ thống có đáp ứng đầy đủ khơng? - Vấn đề hiệu có ảnh hưởng đáng kể đến người dùng hệ thống hay chưa? Các yếu tố sử dụng đánh giá môi trường Tham số Câu hỏi Yêu cầu hỗ trợ – Các hỗ trợ cần có yêu cầu phần cứng phần mềm gì? Nếu chi phí hỗ trợ cao, xem xét việc thay hệ thống Chi phí bảo trì - Chi phí bảo trì phần cứng chi phí quyền cho phần mềm hỗ trợ gì? - Phần cứng cũ có chi phí bảo trì cao hệ thống đại Phần mềm hỗ trợ có chi phí quyền theo năm cao Khả tương - Có vấn đề giao tiếp hệ thống với hệ tác thống khác khơng? - Trình biên dịch sử dụng với phiên hệ điều hành hay không? - Các mơ phần cứng có cần hay không? Các yếu tố sử dụng đánh giá ứng dụng Tham số Câu hỏi – Tính - Để hiểu mã nguồn hệ thống khó khăn hiểu nào? - Các cấu trúc điều khiển sử dụng phức tạp nào? - Các biến có tên có ý nghĩa phản ánh chức chúng hay không? Tài liệu - Tài liệu sẵn có hệ thống gì? ( tài liệu hướng dẫn, thiết kế, kiểm thử…) - Tài liệu có đầy đủ, qn hay khơng? Dữ liệu - Có mơ hình liệu rõ ràng cho hệ thống hay khơng? - Các liệu có trùng lặp hay không? - Dữ liệu hệ thống sử dụng có thống hay khơng? Hiệu - Hiệu ứng dụng có đầy đủ, đáp ứng khơng? - Hiệu có ảnh hưởng đáng kể đến người dùng hệ thống? Các yếu tố sử dụng đánh giá ứng dụng Tham số Câu hỏi Ngơn ngữ lập trình - Trình biên dịch đại có sẵn cho ngơn ngữ lập trình sử dụng để phát triển hệ thống hay không? - Ngôn ngữ lập trình sử dụng để phát triển hệ thống hay khơng? Quản lý cấu hình - Tất phiên tất phần hệ thống quản lý hệ thống quản lý cấu hình? - Có mơ tả rõ ràng phiên thành phần sử dụng hệ thống hay không? Kiểm thử liệu - Liệu liệu kiểm thử cho hệ thống có tồn tại? - Có hay khơng ghi kiểm thử hồi quy thực tính hệ thống? Kỹ đội - Đội ngũ có có kỹ để bảo trì ứng dụng hay khơng? ngũ - Có kinh nghiệm với bảo trì hệ thống hay khơng? Đo lường hệ thống - Có thể thu thập liệu định lượng để đánh giá chất lượng hệ thống ứng dụng + Số yêu cầu thay đổi hệ thống; + Số lượng giao diện người dùng khác hệ thống sử dụng; + Khối lượng liệu sử dụng hệ thống Những điểm Có loại bảo trì phần mềm, cụ thể sửa lỗi, sửa đổi phần mềm để làm việc môi trường mới, thay đổi môi trường phần mềm Tái xây dựng liên quan đến tái cấu trúc xây dựng lại tài liệu phần mềm để làm cho dễ hiểu Tái cấu trúc lại, thay đổi chương trình để bảo vệ chức năng, hình thức bảo trì có tính phòng tránh, có thay đổi dễ dàng bảo trì Giá trị kinh nghiệp vụ hệ thống kế thừa chất lượng ứng dụng cần đánh giá để giúp đưa chiến lược xem xét hệ thống cần thay thế, thay đổi hay tiếp tục bảo trì  ... -Phần cứng có phải tỉ lệ cố báo cáo cao hay không? - Liệu phần mềm hỗ trợ gặp cố có khiến khởi động lại hệ thống hay không? Tuổi thọ - Tuổi thọ phần cứng, phần mềm gì? - Các phần cứng phần mềm. .. trình tiến hóa hệ thống Bài giảng - Tiến hóa Phần mềm Phần Sửa đổi chương trình sau đưa vào sử dụng - Bảo trì phần mềm pha cuối quy trình hệ thống phần mềm - Các hoạt động cần thực hiện: + Quản... tạo phần mềm Bảo trì phần mềm thường khơng liên quan đến thay đổi lớn đến kiến trúc hệ thống Thay đổi thực cách sửa đổi thành phần có bổ sung thêm thành phần vào hệ thống Các kiểu Bảo trì phần mềm