PHẦN MỀM TIẾN HÓA Các chủ đề : - quá trình tiến hóa o Thay đổi quy trình cho các hệ thống phần mềm - Động lực phát triển chương trình o Sự hiểu biết về tiến hóa phần mềm - bảo trì phần m
Trang 1PHẦN MỀM TIẾN HÓA
Các chủ đề :
- quá trình tiến hóa
o Thay đổi quy trình cho các hệ thống phần mềm
- Động lực phát triển chương trình
o Sự hiểu biết về tiến hóa phần mềm
- bảo trì phần mềm
o Làm thay đổi hệ thống phần mềm hoạt động
- Quản lý hệ thống di sản
o Quyết định về thay đổi phần mềm
Tóm tắt:
- Phát triển phần mềm và tiến hóa có thể được nhóm lại là một, quá trình lặp đi lặp lại có thể biểu diễn sử dụng một 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 quá chi phí phát triển phần mềm
- Quá trình tiến hóa phần mềm được điều khiển bởi các yêu cầu thay đổi và bao gồm phân tích tác động thay đổi, phát hành lập kế hoạch và thực hiện thay đổi
- Định luật Lehman, có quan điểm cho rằng sự thay đổi là liên tục, mô tả một số những hiểu biết bắt nguồn từ nghiên cứu lâu dài của quá trình phát triển hệ thống
- Có 3 loại bảo trì phần mềm, cụ thể là: lỗi sửa chữa, thay đổi phần mềm để làm việc trong một môi trường mới, thực hiện các yêu cầu mới hoặc thay đổi
- Phần mềm tái kỹ thuật liên quan đến tái cơ cấu và tái lập tài liệu phần mềm để làm cho nó
dễ dàng hơn để hiểu và thay đổi
- Tái cấu trúc, làm cho chương trình thay đổi vẫn bảo đảm chức năng, là một hình thức bảo trì
- Giá trị kinh doanh của một hệ thống di sản và chất lượng các ứng dụng cần được đánh giá
để giúp quyết định nếu một hệ thống nên được thay thế, chuyển đổi, duy trì
Mục lục:
Thay đổi phần mềm………3
Tầm quan trọng của sự phát triển……… 3
Một mô hình xoắn ốc phát triển và tiến hóa……….3
Sự tiến hóa và bảo trì……….4
Quá trình tiến hóa……….5
Thay đổi nhận dạng và tiến hóa quy trình……… 5
Quá trình tiến hóa phần mềm……….5
Thay đổi thực hiện………6
Yêu cầu thay đổi khẩn cấp……… 6
Trang 2Quá trình sửa chữa khẩn cấp……… 6
Vấn đề bàn giao……… 7
Động lực phát triển chương trình……… 7
Thay đổi là không thể tránh khỏi………7
Định luật Lehman………7
Áp dụng định luật Lehman……….8
Bảo trì phần mềm……… 8
Loại bảo trì………9
Hình 9.8 Bảo trì phân phối nỗ lực………9
Chi phí bảo trì……… 9
Hình 9.9 và Phát triển chi phí bảo trì………10
Các yếu tố chi phí bảo trì………10
Dự đoán bảo trì………10
Thay đổi dự đoán………11
Số liệu phức tạp………11
Số liệu quá trình………11
Ví dụ về bảo trì Yêu cầu & TÁC ĐỘNG ALANYSIS………12
Tác động của MR # 162………12
Hệ thống lại kỹ thuật………12
Ưu điểm của tái cấu trúc………12
Quá trình tái cấu trúc………13
Hoạt động quá trình tái cấu trúc………13
Hình 9.12 Tái cấu trúc phương pháp tiếp cận………13
Yếu tố chi phí tái cấu trúc………14
Bảo trì bằng tái cấu trúc………14
Sắp xếp và tái cấu trúc………14
' Bad smells ' trong mã chương trình………14
Quản lý hệ thống di sản………15
Hình 9.13 Một ví dụ về một di sản đánh giá hệ thống……… 15
Loại hệ thống di sản………16
Đánh giá giá trị kinh doanh………16
Trang 3Các vấn đề trong đánh giá giá trị kinh doanh………16
Đánh giá chất lượng hệ thống………17
Đánh giá quá trình kinh doanh………17
Yếu tố được sử dụng trong đánh giá môi trường………17
Đo lường hệ thống………19
Một bảo trì điển hình dòng chảy………19
Bảo trì & Patching……… 19
Patches bảo trì………20
Thay đổi phần mềm
- Thay đổi phần mềm là không thể tránh khỏi
o Khi có yêu cầu mới xuất hiện khi phần mềm được sử dụng;
o Những thay đổi môi trường kinh doanh ;
o 1 số lỗi phát sinh cần được sửa chữa ;
o Máy tính và thiết bị mới được thêm vào hệ thống;
o Hiệu suất hoặc độ tin cậy của hệ thống có thể được cải thiện
- Một vấn đề quan trọng đối với tất cả các tổ chức đang thực hiện và quản lý thay đổi hệ thống phần mềm hiện có của họ
Tầm quan trọng của sự phát triển
- Các tổ chức có đầu tư rất lớn trong hệ thống phần mềm của họ - đó là những tài sản kinh doanh quan trọng
- Để duy trì giá trị của những tài sản cho doanh nghiệp, phần mềm phải được thay đổi và cập nhật
- Phần lớn các ngân sách phần mềm trong các công ty lớn là dành cho thay đổi và phát triển phần mềm hiện có hơn hơn phát triển phần mềm mới
Một mô hình xoắn ốc phát triển và tiến hóa
Trang 4Sự tiến hóa và bảo trì
- Sự tiến hóa
o Giai đoạn trong vòng đời một hệ thống phần mềm ở trong hoạt động sử dụng và được phát triểu theoyêu cầu mới được đề xuất và thực hiện trong hệ thống
- Bảo trì
o Ở giai đoạn này, phần mềm vẫn còn hữu ích nhưng những thay đổi chỉ thực hiện được những yêu cầu để giữ cho nó sửa lỗi, tức là hoạt động và thay đổi để phản ánh những thay đổi trong môi trường của phần mềm Không có những chức năng mới được thêm vào
- Giai đoại ra
Trang 5o Phần mềm này có thể vẫn được sử dụng nhưng nó không được thực hiện thay đổi nào
Quá trình tiến hóa
Quá trình tiến hóa phần mềm phụ thuộc vào:
- Các loại phần mềm được duy trì ;
- Quá trình phát triển sử dụng;
- Các kỹ năng và kinh nghiệm của những người liên quan
Đề xuất thay đổi định hướng cho sự phát triển hệ thống
- Nên được liên kết với các thành phần bị ảnh hưởng bởi sự thay đổi, do đó các chi phí và tác động của sự thay đổi phải được ước tính
Thay đổi nhận dạng và phát triển tiếp tục trong suốt tuổi thọ của hệ thống
Thay đổi nhận dạng và tiến hóa quy trình
Quá trình tiến hóa phần mềm
Trang 6Thay đổi thực hiện
- Lặp đi lặp lại của quá trình phát triển, nơi các phiên bản vào hệ thống được thiết kế, thực hiện và thử nghiệm
- Một sự khác biệt quan trọng là giai đoạn đầu tiên của sự thay đổi thực hiện có thể liên quan đến sự hiểu biết chương trình, đặc biệt là nếu các nhà phát triển hệ thống ban đầu không chịu trách nhiệm về việc thực hiện thay đổi
- Trong giai đoạn hiểu biết chương trình, bạn phải hiểu làm thế nào chương trình có cấu trúc, làm thế nào nó cung cấp chức năng và làm thế nào thay đổi được đề xuất có thể ảnh hưởng đến chương trình
Yêu cầu thay đổi khẩn cấp
- Thay đổi khẩn cấp có thể được thực hiện mà không đi qua tất cả các giai đoạn của công nghệ phần mềm quá trình
o Nếu một lỗi hệ thống nghiêm trọng đã được sửa chữa để cho phép bình thường hoạt động để tiếp tục;
o Nếu thay đổi môi trường của hệ thống (ví dụ như một bản nâng cấp hệ điều hành )
có hiệu ứng bất ngờ ;
o Nếu có sự thay đổi kinh doanh đòi hỏi phải có một phản ứng rất nhanh (ví dụ việc phát hành một sản phẩm cạnh tranh)
Quá trình sửa chữa khẩn cấp
Trang 7Vấn đề bàn giao
- Trường hợp đội ngũphát triển đã sử dụng một cách tiếp cận nhanhnhưng nhóm nghiên cứu quá trình tiến hóa lại không quen với phương pháp nhanh nhẹn và thích một cách tiếp cận
dựa trên kế hoạch
o Nhóm nghiên cứu tiến hóa có thể mong đợi tài liệu chi tiết để hỗ trợ phát triển và
điều này không được thiết kế trong quá trình nhanh nhẹn
- Nơi một cách tiếp cận dựa trên kế hoạch đã được sử dụng phát triển nhưng nhóm nghiên cứu quá trình tiến hóa thích sử dụng phương phápnhanh
o Nhóm nghiên cứu tiến hóa có thể phải bắt đầu từ đầu phát triển kiểm tra tự động và
mã trong hệ thống có thể không có được tái cấu trúc và đơn giản như dự kiến trong phát triển nhanh
Động lực phát triển chương trình
-Program evolution dynamics(Động lực phát triển chương trình): là nghiên cứu về các
quá trình thay đổi hệ thống
- Sau khi một số nghiên cứu thực nghiệm lớn, Lehman và Belady đề xuất rằng có một số ' định luật ' được áp dụng cho tất cả các hệ thống như chúng đã tiến hóa
- Có quan sát hợp lý c áp dụng cho các hệ thống lớn được phát triển bởi những tổ chức lớn
Nó không rõ ràng nếu đây là áp dụng cho các loại phần mềm hệ thống
Thay đổi là không thể tránh khỏi
- Yêu cầu hệ thống có khả năng thay đổi trong khi hệ thống đang được phát triển bởi vì môi
trường đang thay đổi Do đó, một hệ thống cung cấp sẽ không đáp ứng yêu cầu của mình!
- Hệ thống này được kết hợp chặt chẽ với môi trường của họ Khi một hệ thống được cài đặt trong một môi trường nó thay đổi môi trường và Do đó, thay đổi các yêu cầu hệ thống
- Hệ thống phải được thay đổi nếu nó vẫn còn hữu ích trong một môi trường
Định luật Lehman
Định luật Mô tả
tiếp tụ Một chương trình được sử dụng trong một môi trường thực tếnhất thiết
Trang 8phải thay đổi, nếu không dần dần sẽ trở nên ít hữu ích trong môi trường
đó
Tăng phức tạp Khi tiến hoá, độ phức tạp của phần mềm luôn tăng, nếu không bỏ công sức để làm giảm nó xuống
chương trình
tiến hóa lớn
Phát triển chương trình là một quá trình tự điều tiết Hệ thống các thuộc tính như kích thước, thời gian giữa các phiên bản, và
số lượng lỗi được báo cáo là khoảng bất biến cho mỗi hệ thống phát hành
tổ chức ổn định Độổn đị nh là chỉ số quan trọng trong hệ thống điều khiển Để đảm bảo
độ tiến hoá ổn đị nh, nhân sự cần ổn đị nh qua thời gian
bảo tồn quen thuộc Qua cácphiên bản mới, thay đổi gia tăng trong mỗi bản phát hành là
khoảng không đổi
tiếp tục tăng
trưởng
Các chức năng được cung cấp bởi hệ thống phải liên tục tăng để duy trì sự hài lòng cho người sử dụng
chất lượng giảm
sút
Chất lượng của hệ thống sẽ giảm trừ khi họ sửa đổi để phản ánh những thay đổi trong hoạt động môi trường của họ
hệ thống thông tin
phản hồi
Quá trình tiến hóa kết hợp nhiều nguyên nhân, hệ thống thông tin phản hồi
đa vòng và bạn phải xem nó là hệ thống điều khiển để cải thiện hệ thống
Áp dụng định luật Lehman
- Định luật Lehman dường như áp dụng cho các hệ thống lớn, hệ thống phù hợp được phát triển bởi các tổ chức lớn
o Xác nhận vào đầu năm 2000 bởi công việc của Lehman vào ngày lễ
dự án
- Nó không phải là rõ ràng làm thế nào họ nên được sửa đổi cho
o Thu nhỏ sản phẩm phần mềm ;
o Hệ thống kết hợp một số lượng đáng kể của COTS thành phần ;
o Các tổ chức nhỏ ;
o Hệ thống Kích thước trung bình
Bảo trì phần mềm
- Sửa đổi một chương trình sau khi nó đã được đưa vào sử dụng
- Thuật ngữ này được sử dụng chủ yếu cho việc thay đổi phần mềm tùy chỉnh
Sản phẩm phần mềm chung chung được cho là phát triển để tạo ra phiên bản mới
- Bảo dưỡng không thường liên quan đến những thay đổi lớn về kiến trúc của hệ thống
- Thay đổi được thực hiện bằng cách thay đổi thành phần hiện tại và thêm các thành phần mới vào hệ thống
Loại bảo trì
Trang 9- Bảo trì sửa chữa lỗi phần mềm
o Thay đổi một hệ thống để sửa chữa thiếu sót trong cách đáp ứng yêu cầu của khách hàng
- Bảo trì để phần mềm thích nghi với môi trường của nhiều hệ điều hành
o Thay đổi một hệ thống để nó hoạt động trong một môi trường khác nhau (máy tính,
hệ điều hành, vv) từ thực hiện ban đầu của nó
- Bảo trì để thêm vào hoặc thay đổi chức năng của hệ thống
o Sửa đổi hệ thống để đáp ứng yêu cầu mới
Hình 9.8 Bảo trì phân phối nỗ lực
Chi phí bảo trì
- Thường lớn hơn chi phí phát triển (2 * đến 100 * tùy thuộc vào ứng dụng)
- Bị ảnh hưởng bởi cả hai yếu tố kỹ thuật và phi kỹ thuật
Trang 10- Tăng lên khi phần mềm được duy trì
Bảo trì cấu trúc phần mềm bị sửa đổi như vậy làm cho bảo trì thêm khó khăn hơn
- Phần mềm quá cũ có thể có chi phí hỗ trợ cao (ví dụ ngôn ngữ lập trình cũ, trình biên dịch , vv.)
Hình 9.9 và Phát triển chi phí bảo trì
Các yếu tố chi phí bảo trì
- nhóm ổn định
o Chi phí bảo trì được giảm nếu các nhân viên cùng tham gia với họ trong một thời
gian
- trách nhiệm theo hợp đồng
o Các nhà phát triển của một hệ thống có thể không có hợp đồng trách nhiệm bảo trì, không có động cơ để thiết kế cho sự thay đổi trong tương lai
- kỹ năng nhân viên
o Nhân viên bảo trì thường thiếu kinh nghiệm và có giới hạn kiến thức tên miền
- Tuổi tác và cấu trúc chương trình
o Như các chương trình có tuổi, cấu trúc của chúng là suy thoái và nó trở thành khó hiểu và khó thay đổi
Dự đoán bảo trì
- Dự báo bảo trì là quan tâm đến đánh giá phần nào của hệ thống có thể gây ra vấn đề và có chi phí bảo dưỡng cao
o Thay đổi chấp nhận phụ thuộc vào khả năng bảo trì của thành phần bị ảnh hưởng bởi sự thay đổi ;
o Thực hiện thay đổi làm giảm hệ thống và làm giảm quá trình bảo trì ;
o Chi phí bảo dưỡng phụ thuộc vào số lượng các thay đổi và chi phí thay đổi phụ thuộc vào bảo trì
Trang 11Thay đổi dự đoán
- Dự đoán số yêu cầuthay đổi và sự hiểu biết về mối quan hệ giữa hệ thống và môi trường của nó
- Hệ thống chặt chẽ cùng yêu cầu thay đổi bất cứ khi nào môi trường thay đổi
- Yếu tố ảnh hưởng mối quan hệ này là
o Số lượng và phức tạp của giao diện hệ thống ;
o Số yêu cầu hệ thống vốn đã không ổn định ;
o Các quy trình kinh doanh mà hệ thống được sử dụng
Số liệu phức tạp
- Dự đoán của bảo trì có thể được thực hiện bằng cách đánh giá sự phức tạp của các thành phần hệ thống
- Các nghiên cứu đã chỉ ra rằng nỗ lực bảo trì nhất là trên một số lượng tương đối nhỏ của các thành phần hệ thống
- Phức tạp phụ thuộc vào
o Phức tạp của cấu trúc điều khiển ;
o Phức tạp của cấu trúc dữ liệu ;
o Đối tượng, phương pháp (thủ tục) và kích thước mô-đun
Số liệu quá trình
- Số liệu quá trình có thể được sử dụng để đánh giá khả năng bảo trì
o Số lượng yêu cầu để bảo trì khắc phục;
o Thời gian trung bình cần thiết để phân tích tác động ;
o Thời gian trung bình thực hiện để thực hiện một yêu cầu thay đổi ;
o Số lượng yêu cầu thay đổi nổi bật
- Nếu bất kỳ hoặc tất cả càng tăng, điều này sẽ chỉ ra khả năng bảo trì giảm
Trang 12Ví dụ về bảo trì Yêu cầu &TÁC ĐỘNG ALANYSIS
- Yêu cầu bảo trì 78 ( bảo trì khắc phục yêu cầu )
o Các tính toán đó xảy ra sau khi người chơi thay đổi giá trị của chất lượng, và đề nghị giữ tổng số bất biến, nhưng họ không thực hiện
Ví dụ, nếu những phẩm chất là sức mạnh = 10, sự kiên nhẫn = 0,8 và độ bền = 0,8 (tổng = 11,6 ) , và người chơi điều chỉnh sức mạnh để 11 , sau đó kết quả là sức mạnh = 11, sự kiên nhẫn = 0 và sức chịu đựng = 0 , tổng không là 11,6
- Yêu cầu bảo dưỡng 162 ( Bảo trì bảo trì hoàn hảo )
o Sửa đổi gặp để trò chơi bắt đầu với khu vực và kết nối trong một phong cách phối hợp Khi người chơi đạt cấp độ 2 trạng thái, tất cả các khu vực và các kết nối được hiển thị trong một phong cáchnâng cao phối hợp , mà là đặc biệt đến cấp 2 , vv.Ban
đồ họa sẽ cung cấp các hình ảnh
Tác động của MR # 162
Hệ thống lại kỹ thuật
- Tái cơ cấu hoặc một phần viết lại hoặc tất cả của một hệ thống di sản mà không thay đổi
của nó chức năng
- Áp dụng một số nơi nhưng không phải tất cả các hệ thống phụ của một hệ thống lớn hơn yêu cầu thường xuyên bảo trì
- Tái kỹ thuật bao gồm việc thêm nỗ lực để làm họ dễ dàng hơn để duy trì Hệ thống có thể được tái cấu trúc và tái tài liệu
Ưu điểm của tái cấu trúc
- giảm nguy cơ
o Có nguy cơ cao phát triển phần mềm mới Có thể có vấn đề phát triển, các đặc điểmvấn đề nhân sự và vấn đề kỹ thuật
Trang 13- chi phí giảm
o Chi phí tái cơ cấu thường là ít hơn so với chi phí đáng kể phát triển phần mềm mới
Quá trình tái cấu trúc
Hoạt động quá trình tái cấu trúc
- Dịch mã nguồn
o Chuyển đổi mã sang một ngôn ngữ mới
- kỹ thuật đảo ngược
o Phân tích chương trình để hiểu nó ;
- Cải thiện cấu trúc chương trình
o Tái cơ cấu tự động cho dễ hiểu ;
- chương trình modularisation
o Sắp xếp lại cấu trúc chương trình ;
- tái cấu trúc dữ liệu
o Làm sạch và tái cơ cấu dữ liệu hệ thống
Hình 9.12 Tái cấu trúc phương pháp tiếp cận
Trang 14Yếu tố chi phí tái cấu trúc
- Chất lượng của phần mềm được thiết kế lại
- Công cụ hỗ trợ dành cho tái cấu trúc
- Mức độ chuyển đổi dữ liệu đó là cần thiết
- Sự sẵn có của đội ngũ nhân viên chuyên gia cho tái cấu trúc
o Điều này có thể là một vấn đề với hệ thống cũ dựa trên công nghệ không còn sử dụng rộng rãi
Bảo trì bằng tái cấu trúc
- Tái cấu trúc là quá trình làm cho các cải tiến cho một chương trình để làm chậm sự suy thoái thông qua sự thay đổi
- Bạn có thể nghĩ sắp xếp như ' bảo trì ' làm giảm các vấn đề của sự thay đổi trong tương lai
- Tái cấu trúc liên quan đến việc sửa đổi một chương trình để cải thiện nó cấu trúc, giảm độ phức tạp của nó hoặc làm cho nó dễ hiểu hơn
- Khi bạn cấu trúc lại chương trình, bạn không nên thêm chức năng mà là tập trung vào cải thiệnchương trình
Sắp xếp và tái cấu trúc
Tái kỹ thuật diễn ra sau khi một hệ thống đã được duy trì trong một thời gian và chi phí bảo dưỡng ngày càng tăng.Bạn sử dụng công cụ tự động để xử lý và kĩ sư đã dùng trong hệ thống cũ để tạo ra một hệ thống mới được bảo trì tốt hơn
- Tái cấu trúc là một quá trình liên tục cải thiện trong suốt quá trình phát triển và tiến hóa Nónhằm tránh những cấu trúc và mã phân hủy làm tăng chi phí và khó khăn trong việc duy trì một hệ thống
' Bad smells ' trong mã chương trình
- đang lặp lại