Giới thiệu Tiến hóa phần mềm là một điều không thể tránh khỏi vì những lí do sau: - Những yêu cầu mới được hình thành khi sử dụng phần mềm - Môi trường nghiệp vụ thay đổi - Các lỗi phần
Trang 1Bài giảng 4 - Tiến hóa Phần mềm
Phần 1
- 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 là một điều không thể tránh khỏi vì những lí do sau:
- Những yêu cầu mới được hình thành khi 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 được sửa chữa
- Máy tính và các thiết bị mới được bổ sung vào hệ thống
- Hiệu năng hoặc độ tin cậy của hệ thống phải được cải thiện
Tuy nhiên, vấn đề quan trọng là phải cài đặt /thực hiện và quản lý các thay đổi đối với hệ thống phần mềm đã tồn tại/ những vấn đề chính trong các hệ thống.
Và chúng ta phải thấy được tầm quan trọng của việc tiến hóa phần mềm:
1.2 Tầm quan trọng của sự tiến hóa
- Các tổ chức thường đầu tư một lượng vốn khá lớn vào các hệ thống phần mềm của họ Cho nên họ có quyền đòi hỏi phải sở hữu một hệ thống hoàn hảo
- Để bảo trì giá trị sở hữu của tổ chức, họ phải thay đổi và cải tiến hệ thống
- Ngân sách phần mềm chính trong các công ty lớn thường dùng cho việc cải tiến các hệ thống đã tồn tại hơn là phát triển một hệ thống mới
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 của sự phát triển và tiến hóa
4 giai đoạn
- Initial: giai đoạn khởi đầu
Sự phát triển
Trang 2- Khi phần mềm đâng được vận hành và có các yêu cầu mới 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 trong vòng đời một hệ thống của phần mềm, nơi nó được sử dụng vào hoạt động và đang thay đổi như yêu cầu mới được đề xuất và thực hiện trong hệ thống
Phục vụ (servicing)
Ở giai đoạn này, phần mềm vẫn còn hữu ích nhưng có thể phải thực hiện những thay đổi để đảm bảo phần mềm có thể thực hiện được: sửa lỗi, đáp ứng thay đổi trong môi trường vận hành phần mềm nhưng không bổ sung thêm các chức năng
Kết thúc
Phần mềm vẫn có thể được sử dụng nhưng không thực hiện thêm bất kỳ thay đổi nào
1.4 Quy trình tiến hóa phần mềm
Quá trình tiến hóa phần mềm phụ thuộc vào:
- Kiểu phần mềm được bảo trì
- Quy trình phát triển được sử dụng
- Phụ thuộc vào kỹ năng, kinh nghiệm của 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 các thành phần ảnh hưởng tới sự thay đổi, ước tính chi phí cho sự thay đổi đó
-Xác nhận thay đổi, cập nhật, tiến hóa phần mềm liên tục trong thời gian tồn tại của hệ thống
Quá trình phát triển phần mềm
Thay đổi thực hiện
Lặp lại quá trình phát triển, nơi các sửa đổi cho hệ thống được thiết kế, thực hiện và thử nghiệm
Sự khác biệt quan trọng là giai đoạn đầu của việc thực hiện thay đổi có thể liên quan đến sự hiểu biết của chương trình, đặc biệt nếu các nhà phát triển hệ thống ban đầu không chịu trách nhiệm thực hiện 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 cấu trúc, cách thức cung cấp chức năng và sự thay đổi được đề xuất có thể ảnh hưởng đến chương trình như thế nào
Yêu cầu thay đổi
Trang 3- Cần hiểu được chương trình đặc biệt người thiết kế ban đầu không hiểu được: ảnh hưởng của những đề xuất thay đổi, cấu trúc, phương thức hoạt động của chương trình
* Nhóm thay đổi khẩn cấp
Thay đổi khẩn cấp có thể phải được thực hiện mà không qua tất cả các giai đoạn của quy trình xây dựng phần mềm :
- Nếu một lỗi hệ thống nghiêm trọng cần phải được sửa chữa để cho phép hoạt động bình thường để tiếp tục;
- 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) gây ra những ảnh hưởng ngoài dự đoán
- Nếu có những thay đổi về nghiệp vụ, yêu cầu phản ứng rất nhanh (ví dụ như việc phát hành một 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 và tiến hóa
Các phương pháp Linh hoạt dựa trên phát triển tăng dần , do đó sự chuyển đổi từ
phát triển sang tiến hóa là một sự liền mạch, liên tục Tiến hóa chỉ đơn giản là sự tiếp tục của quá trình phát triển dựa trên các bản phát hành thường xuyên của hệ thống
Kiểm thử hồi quy tự động đặc biệt có giá trị khi có thay đổi đối với một hệ thống
Những thay đổi có thể được thể hiện bằng các kịch bản người dùng được 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 nhưng đội
ngũ tiến hóa không quen thuộc với các phương pháp linh hoạt và thích cách tiếp cận theo kế hoạch - Nhóm tiến hóa có thể mong đợi các tài liệu hướng dẫn chi tiết
để hỗ trợ sự tiến hóa và điều này không được tạo ra trong các quy trình nhanh
Trường hợp 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 tiến hóa thích sử dụng các phương pháp nhanh nhẹn Nhóm nghiên cứu tiến hóa có thể xây dựng kiểm thử tự động và các 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 sự phát triển linh hoạt
2 Động lực tiến hóa phần mềm
là việc nghiên cứu các quY trình thay đổi hệ thống
- Sau nhiều nghiên cứu thực nghiệm lớn, Lehman và Belady đề xuất rằng có một số 'luật' mà áp dụng cho tất cả các hệ thống được tiến hóa
- Được áp dụng cho các hệ thống lớn được phát triển bởi các tổ chức lớn
Trang 4Không rõ ràng nếu những điều này được áp dụng cho các loại khác của hệ thống phần mềm
Các yêu cầu của hệ thống có thể sẽ thay đổi Trong khi hệ thống đang được phát triển bởi vì Môi trường đang thay đổi Vì vậy một Hệ thống sẽ không đáp ứng các yêu cầu của nó! – cần phải thay đổi để đáp ứng
Các hệ thống được kết hợp chặt chẽ với môi trường của chúng Khi một hệ thống được cài đặt trong một Môi trường làm thay đổi môi trường và Do đó thay đổi yêu cầu hệ thống
Hệ thống phải được thay đổi nếu họ Sẽ vẫn hữu ích trong một môi trường
2.2 Luật của Lehman
Pháp luật Mô tả
Liên tục thay đổi Một chương trình được sử dụng trong môi trường thực tế cần phải
thay đổi, hoặc trở nên ít hữu ích hơn trong môi trường đó nếu không giá trị sử dụng ngày càng suy giảm
Sự gia tăng tính
phức tạp
Khi một chương trình trong giai đoạn tiến hóa được thay đổi, cấu trúc của nó có xu hướng trở nên phức tạp hơn Cần có thêm các nguồn lực bổ sung dành cho việc bảo vệ và đơn giản hóa cấu trúc của chương trình
Tiến triển chương
trình lớn
Tiến trình của chương trình là một quy trình tự điều chỉnh Các thuộc tính của hệ thống như kích thước, thời gian giữa các bản phát hành, và số lỗi gần như là không đổi cho mỗi phiên bản hệ thống
Ổn định tổ chức Trong suốt quá trình tồn tại của chương trình, tốc độ phát triển của
nó xấp xỉ và 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 của Lehman
Pháp luật Mô tả
Bảo tồn sự quen
thuộc
Trong suốt thời gian tồn tại của một hệ thống, sự thay đổi tăng dần trong mỗi phiên bản gần như không đổi./ thường chọn số lượng chức năng không có quá nhiều thay đổi
Tiếp tục phát triển Các chức năng được cung cấp bởi các hệ thống phải liên tục gia
tăng để duy trì sự hài lòng của 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 được
phản ánh những thay đổi trong môi trường hoạt động của chúng
Hệ thống phản hồi Các quy trình tiến hóa hiện nay 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 những cải thiện đáng
kể đối với sản phẩm
2.3 Khả năng áp dụng các luật của Lehman
Trang 5- Luật Lehman 's dường như là áp dụng chung cho các hệ thống lớn, phù hợp, tùy chỉnh được phát triển bởi các tổ chức lớn Xác nhận vào đầu năm 2000 bởi dự án của Lehman
- Được xem xét có phù hợp hay không?
+ Các sản phẩm phần mềm được gói gém
+ Các hệ thống tích hợp một số lượng đáng kể các 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 chính
Phát triển phần mềm và tiến hóa có thể được coi như là một quá trình tích hợp, lặp đi lặp lại có thể được 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
Quy trình phát triển phần mềm được thúc đẩy bởi các yêu cầu thay đổi và bao gồm phân tích ảnh hưởng thay đổi, đưa ra kế hoạch thay đổi và thực hiện thay đổi
Luật Lehman 's, chẳng hạn như quan điểm cho rằng thay đổi là liên tục, mô
tả một số hiểu biết sâu sắc bắt nguồn từ các nghiên cứu lâu dài của quá trình tiến hóa của hệ thống
Trang 6Bài giảng 4 - Tiến hóa Phần mềm
Phần 2
Sửa đổi một chương trình sau khi đã được đưa vào sử dụng.
- Bảo trì phần mềm là pha cuối cùng của 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ế các thay đổi được yêu cầu
- Kế hoạch thay đổi từ thiết kế cũ
- Đánh giá các ảnh hưởng của thay đổi
- Triển khai thay đổi
- Thực hiện kiểm thử cho các thành phần thay đổi
- Tiến hành kiểm thử tăng dần, thực hiện kiểm thử hệ thống với các khả năng mới
- Cập nhật các tài liệu cấu hình, yêu cầu, thiết kế và 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
Trang 7Thuật ngữ này chủ yếu được 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 ra các phiên bản mới - huớng đối tượng người dùng cụ thể, liên quan đến các phiên bản tiến hóa, tạo ra phần mềm mới
Bảo trì phần mềm thường không liên quan đến những thay đổi lớn đến kiến trúc của hệ thống
Thay đổi được thực hiện bằng cách sửa đổi các thành phần hiện có và bổ sung thêm các thành phần mới 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 một hệ thống để sửa chữa thiếu sót trong cách đáp ứng các yêu cầu của nó
- Bảo trì để phần mềm thích ứng với một môi trường vận hành khác: do môi trường thay đổi dẫn tới phải thay đổi phần mềm cho phù hợp
- 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, v.v ) từ khi triển khai ban đầu
- Bảo trì để bổ sung hoặc chỉnh sửa các chức năng của hệ thống: chỉnh sua
để đáp ứng yêu cầu mới
Các loại bảo trì
Trang 8Hình 9.8 Phân bố nỗ lực bảo trì
- Thường lớn hơn chi phí phát triển (2 * 100 * tùy thuộc vào ứng dụng)
- Chi phí Bị ảnh hưởng bởi cả yếu tố kỹ thuật và 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ả năng sử dụng bền vững có thể có chi phí hỗ trợ cao (Ví
dụ như ngôn ngữ cũ, trình biên dịch cũ…)
Chi phí bảo trì
Hình 9 Chi phí phát triển và bảo trì
* Các yếu tố ảnh hưởng đến chi phí bảo trì
+ Tính ổn định của đội ngũ phát triển
- Chi phí bảo trì sẽ giảm nếu nhân viên cùng tham gia với họ trong một khoảng thời gian
- Trách nhiệm trong tham gia hợp đồng
Các nhà phát triển của một hệ thống có thể không có trách nhiệm trong hợp đồng để tham gia bảo trì nên không có động lực để thiết kế cho sự thay đổi trong tương lai
- Kỹ năng của thành viên trong đội ngũ
thiếu kinh nghiệm và kiến thức hạn chế về lĩnh vực ứng dụng
- Tuổi thọ và cấu trúc của chương trình
Khi các chương trình càng sử dụng lâu thì cấu trúc thường bị suy thoái và chúng trở nên khó hiểu và khó thay đổi hơn
Dự đoán bảo trì
Trang 9Dự đoán bảo trì quan tâm đến việc đánh giá những thành phần của hệ thống
có thể gây ra vấn đề và có chi phí bảo trì cao
- Thay đổi được chấp nhận phụ thuộc vào khả năng bảo trì của các bộ phận
bị ảnh hưởng bởi sự thay đổi đó
- Thực hiện thay đổi làm thoái hóa hệ thống và giảm tính bảo trì của hệ thống đó;
- Chi phí bảo trì phụ thuộc vào số lần thay đổi và chi phí thay đổi tùy thuộc vào khả năng bảo trì phần mềm
Thay đổi dự đoán
- Dự đoán số lượng thay đổi cần thiết và sự hiểu biết về mối quan hệ giữa một hệ thống và môi trường của nó Từ 1 thay đổi sẽ xác định được các 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 bất cứ khi nào môi trường thay đổi
- Các yếu tố ảnh hưởng đến mối quan hệ này là
+ Số lượng và sự phức tạp của các giao diện hệ thống;
+ Số lượng các 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 được sử dụng
Tham số đo phức tạp
- Các dự đoán về khả năng bảo trì có thể được thực hiện bằng cách đánh giá tính 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 hầu hết các nỗ lực bảo trì được dành cho một số lượng tương đối nhỏ các thành phần hệ thống Những thành phần phức tạp đòi hỏi khả năng bảo trì nhiều hơn
- Độ phức tạp phụ thuộc vào:
+ Tính phức tạp của cấu trúc điều khiển;
+ Tính phức tạp của cấu trúc dữ liệu;
+ Đối tượng, phương pháp (thủ tục) và kích thước mô-đun
Tham số đo quy trình
- có thể được sử dụng để đánh giá khả năng bảo trì
+ Số lượng yêu cầu bảo trì sửa chữa;
Trang 10+ Thời gian trung bình cần thiết cho phân tích ảnh hưởng bởi sự thay đổi tác động đến các thành phần khác;
+ Thời gian trung bình cần có để thực hiện yêu cầu thay đổi;
+ Số lượng yêu cầu thay đổi nổi bật
Nếu bất kỳ hoặc tất cả những yếu tố trên gia tăng, điều này có thể cho thấy khả năng bảo trì bị suy giảm
Tái xây dựng hệ thống
Cấu trúc lại hoặc viết lại một phần hoặc tất cả các hệ thống kế thừa mà không thay đổi chức năng của hệ thống
Áp dụng khi một số nhưng không phải tất cả ở các 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ác công việc để hệ thống dễ bảo trì hơn
Hệ thống có thể được tái cấu trúc và xây dựng lại
Ưu điểm của việc tái cấu trúc, tái xây dựng hệ thống
- Giảm thiểu rủi ro: khi phát triển phần mềm mới thường có nguy cơ rủi ro cao như vấn đề biên chế và các đặc điểm kỹ thuật
- Giảm thiểu chi phí: thường ít hơn đáng kể so với phát triển hệ thống mới
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ữ mới
- Kỹ thuật xây dựng đảo ngược: sinh ra các biểu đồ lớp…, tài liệu thiết kế nhằm phân tích, hiểu được chương trình dễ dàng hơn
- Cải thiện cấu trúc chương trình : tăng khả năng có thể hiểu được
- Mô đun hóa chương trình
- Tái cấu trúc dữ liệu: Dọn dẹp và tái cơ cấu dữ liệu hệ thống
Trang 11- Cấu trúc dữ 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 của phần mềm cần được đ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ô của việc chuyển đổi dữ liệu được yêu cầu
- Sự sẵn sàng của đội ngũ chuyên gia cho việc tái xây dựng
Đây có thể là vấn đề với các hệ thống cũ dựa trên công nghệ không còn được 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 là quá trình cải tiến một chương trình làm chậm lại sự thoái hóa của nó khi thực hiện thay đổi
Tái cấu trúc là hoạt động 'bảo trì' có tính phòng tránh làm giảm thiểu các vấn đề của sự thay đổi trong tương lai
Tái cấu trúc bao gồm việc sửa đổi một chương trình để cải thiện cấu trúc, giảm độ phức tạp của nó hoặc làm cho chương trình dễ hiểu hơn
Khi tái cấu trúc lại chương trình, không nên thêm các chức năng mà nên tập trung vào việc cải thiện chương trình
Mối quan hệ giữa Tái cấu trúc lại và tái xây dựng
Tái xây dựng được thực hiện sau khi một hệ thống được duy trì trong một khoảng thời gian và chi phí bảo trì càng tăng Khi đó sử dụng các công cụ tự động
để xử lý và tái thiết kế một hệ thống kế thừa để tạo ra một hệ thống mới có thể duy trì được tốt hơn
Tái cấu trúc là một quá trình liên tục trong cả quá trình phát triển và quá trình tiến hóa nhằm tránh thoái hóa cấu trúc chương trình, điều này làm gia tăng chi phí và khó khăn trong 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