Xếp hạng Tính sẵn sàng Sử dụng lại

Reuse Readiness Rating

By Ross Gardler, Published: 14 July 2009, Reviewed: 09 July 2012

Theo: http://www.oss-watch.ac.uk/resources/reuseReadinessRating

Bài được đưa lên Internet ngày: 09/07/2012

Lời người dịch: Có vài phương pháp đánh giá phần mềm và tính sẵn sàng sử dụng lại phần mềm. Bài viết này đưa ra phương pháp Mức độ Sẵn sàng Sử dụng lại - RRL (Reuse Readiness Levels). “RRL có những ưu điểm hơn các hệ thống đánh giá khác theo đó chúng cho phép sự so sánh các thành phần phần mềm, bất kể phương pháp luận pháp triển nào được áp dụng. Đối với sử dụng lại hộp đen, điều này làm cho RRL áp dụng được rộng rãi. Tuy nhiên, ở những nơi sử dụng lại hộp trắng (đòi hỏi những sửa đổi đối với thành phần đó) sẽ phải được xem xét, thì RRL không đánh giá được tính phù hợp phương pháp luận phát triển của dự án cho sự sử dụng như vậy. Trong các trường hợp đó RRL nên được bổ sung với các công cụ độ chín nguồn mở đang tồn tại”. Xem thêm: Mô hình Độ chín Bền vững của Phần mềm và Sân chơi bình đẳng: phát triển một nền kinh tế pha trộn cho mua sắm phần mềm.

Sử dụng lại phần mềm có thể tiết kiệm thời gian, tiết kiệm tiền và làm gia tăng độ tin cậy của các sản phẩm kết quả. Tuy nhiên, sự cố gắng sửa dụng lại phần mềm mà không dễ sử dụng lại có thể có hiệu ứng ngược. Có một số mô hình để đo đếm độ chính các thành phần phần mềm để sử dụng lại, mà chúng có xu hướng tập trung vào một hệ thống tính điểm hơn là xác định rõ ràng một mô hình độ chín. Vì các mô hình độ chín cho phép các dự án đo đếm hiệu năng của nó và vì thế thiết lập các mục tiêu cải thiện khả năng sử dụng lại, có thể còn có tranh cãi rằng chúng là về giá trị nhiều hơn so với các hệ thống tính điểm. Nhóm Làm việc (WG) Sử dụng lại Phần mềm Hệ thống Dữ liệu Khoa học Trái đất ESDS (Earth Science Data Systems) của NASA đã phát triển các Mức độ Sẵn sàng Sử dụng lại (Reuse Readiness Levels) như một mô hình cho sự đo đếm và đánh giá như vậy. Tài liệu này giới thiệu khái niệm các Mức độ Sẵn sàng Sử dụng lại và khai thác khả năng ứng dụng của chúng cho phần mềm nguồn mở.

Sử dụng lại phần mềm là gì?

Sử dụng lại phần mềm là ứng dụng lại tri thức được gói ghém trong mã phần mềm dể giảm nỗ lực phát triển và duy trì một hệ thống phần mềm mới. Có nhiều thứ cần phải được xem xét cho sử dụng lại, không chỉ bản thân phần mềm. Ví dụ, thậm chí khi phần mềm không thể được sử dụng lại, các định dạng dữ liệu, các thiết kế mức cao, các thuật toán hoặc các khoản khác cũng vẫn có thể được sử dụng lại. Hệ quả là, khi xem xét sử dụng lại phần mềm chúng ta phải xem xét từng khoản quan tâm. Những khoản đó được biết tới như là các chế tác (artifacts), các tài sản và các thành phần.

Một chế tác là bất kỳ khoản nòa được sản xuất ra ở cùng thời điểm trong quá trình của chu kỳ phát triển phần mềm. Một chế tác có thể được sử dụng lại, đó là một chế tác được thừa nhận như là có một giá trị đặc biệt, được biết tới như là một tài sản. Một thành phần là một mẩu phần mềm được phác họa rõ ràng, thực hiện một chức năng hữu dụng bên trong một hệ thống phần mềm.

Các thành phần phần mềm sử dụng lại được – RSC (Reusable Software Components) là các thực thể phần mềm có ý định để sử dụng lại. Về nguyên tắc, nhiều chế tác khác nhau được sản xuất ra trong quá trình vòng đời phát triển phần mềm có thể sử dụng lại được, bao gồm: mã nguồn, đặc tả phân tích và thiết kế, các kế hoạch (quản lý dự án), dữ liệu (kiểm thử), tài liệu, sự tinh thông và kinh nghiệm, các qui trình đảm bảo chất lượng, và bất kỳ thông tin nào được sử dụng để tạo ra phần mềm và tài liệu phần mềm. Tuy nhiên, trong khi tất cả các khoản đó là hữu dụng, thì phần mềm là chế tác mà hầu hết thường sử dụng lại được.

Có nhiều ví dụ về mã phần mềm đang được sử dụng lại, đặc biệt nếu chúng ta nhìn vào các phần mềm nguồn mở vì sự truyền cảm hứng. Các thành phần phần mềm sử dụng lại trải từ các thư viện nhỏ, như các thư viện trong dự án Apache Commons, thông qua các khung công việc cho việc xây dựng các ứng dụng hoàn chỉnh, như Eclipse Rich Client Platform để hoàn tất các ứng dụng có thể được mở rộng thông qua các hệ thống cài cắm, như Mozilla Firefox.

Sử dụng lại các thành phần phần mềm

Có 2 dạng sử dụng lại phần mềm, hộp đen và hộp trắng. Hộp đen có nghĩa là sự triển khai mã đó được ẩn dấu khỏi người sử dụng đầu cuối bằng các giao diện được xác định tốt và được làm thành tài liệu tốt, thường là một giao diện lập trình ứng dụng - API (application programming interface), nó cho phép người tiêu dùng sử dụng thành phần đó mà không càn biết nó đã được triển khai như thế nào. Các thành phần hộp đen có thể đắt giá hơn để sản xuất so với các thành phần hộp trắng, nhưng chúng thường sẽ đưa ra tiết kiệm tổng thể lớn hơn cho người sử dụng đầu cuối trong các trường hợp nơi mà thành phần đó là một sự phù hợp tự nhiên cho các nhu cầu của người sử dụng. Sử dụng lại hộp đen vì thế là phổ biến nhất cho các trường hợp sử dụng chung, như các thư viện cho các hoạt động chung trong một ứng dụng; ví dụ, các thư viện cho việc quản lý ghi lưu ký và báo cáo lỗi có thể thường được sử dụng lại theo cách này. Khi sử dụng lại các thành phần hộp đen cho các ứng dụng web, như các thư viện Javascript, cũng có khả năng sử dụng một thành phần từ một mạng phân phối nội dung - CDN (content delivery network), sinh ra trong việc truy cập nó qua Internet, hơn là việc gói thành phần đó với ứng dụng.

Sử dụng lại hộp trắng là sử dụng lại mà theo đó người sử dụng đòi hỏi sự truy cập tới sự triển khai ben trong của thành phần đó để thực hiện các sửa đổi. Là phổ biến hơn với nhiều người triển khai vì thành phần đó có thể được tùy biến cho phù hợp với các nhu cầu chính xác của hệ thống đích. Tuy nhiên, các lợi ích về hiệu suất của sử dụng lại có thể nhanh chóng thu nhỏ khi nhiều sửa đổi hơn được giới thiệu. Sử dụng lại hộp trắng là phổ biến hơn nơi mà các hệ thống chồng lấn với nhau nhưng có các yêu cầu khác biệt cho lĩnh vực được đưa ra của chúng. Ví dụ, các trình duyệt web thường sẽ được tùy biến cho các trường hợp sử dụng đặc thù.

Phần mềm nguồn mở thường thể hiện tốt nhất cả 2 thế giới đó. Những người có mong muốn sử dụng lại một thành phần như là một hộp đen có thể làm thế bằng việc tải về các phát hành nhị phân của phần mềm, trong khi những người có mong muốn sử dụng lại hộp trắng có thể giành được mã nguồn của dự án để tiến hành các sửa đổi. Không có nhu cầu để quyết định trước liệu hộp đen hay hộp trắng được yêu cầu, vì người ta có thể chuyển sang mô hình hộp trắng nếu những hạn chế trong mô hình hộp đen được xác định. Hơn nữa, một dự án nguồn mở được phát triển bằng việc sử dụng một mô hình phát triển mở (bản dịch tiếng Việt) sẽ giúp các đội dự án đảm bảo rằng những sửa đổi cục bộ không ngăn cản được các bản nâng cấp sang các phiên bản mới của thành phần đó trong tương lai.

Đánh giá cho sử dụng lại

Quy trình tìm kiếm và đánh giá phần mềm để sử dụng lại là tương tự, bất kể chế độ sử dụng lại. Các bước chính trong qui trình đó la:

• Chỉ định đối tượng sẽ được tạo ra
• Tìm kiếm dự án, lĩnh vực và các cơ sở dữ liệu chung cho các ứng viên sử dụng lại
• Đánh giá các ứng viên để xác định các ứng viên nào (nếu có) sẽ được sử dụng
• Sửa đổi, nếu cần, để phù hợp cho các nhu cầu đặc thù
• Tích hợp (các) thành phần sử dụng lại được
• Kiểm tra hệ thống bao gồm cả (các) thành phần mới
• Lấy ý kiến phản hồi tri thức về chi phí sử dụng lại

Có lẽ khó nhất của các bước đó là 'Đánh giá các ứng viên để xác định các ứng viên nào (nếu có) sẽ được sử dụng'. Không loại bỏ được các thành phần không phù hợp ở cơ hội sớm nhất sẽ gây ra nỗ lực tiêu phí trong các giai đoạn sau này. Các Mức độ Sẵn sàng Sử dụng lại – RRL (Reuse Readiness Levels) được thiết kế đặc biệt để hỗ trợ trong đánh giá này, bằng việc xác định rõ một tập hợp các tiêu chí đối với chúng một thành phần có thể được đánh giá để sử dụng lại. Việc áp dụng một tập hợp các tiêu chí một cách nhất quán cho các thành phần sẽ đảm bảo rằng tất cả các khía cạnh được xem xét và tất cả các thành phần được xem xét như nhau.

Sử dụng RRL để chỉ dẫn cho đánh giá cho phép người ta định tỷ lệ cho thành phần trong thang độ chín sử dụng lại. Một thành phần được đánh giá càng cao trong thang tỷ lệ này thì khả năng sử dụng lại càng dễ. Càng thấp trong thang này, thì nỗ lực lớn hơn được yêu cầu để sử dụng lại. Bất kỳ thành phần phần mềm nào cũng có thể được đo đếm theo thang đo này, bất kể quy trình phát triển được áp dụng. Tuy nhiên, vì các thành phần nguồn mở cho phép người sử dụng sửa đổi thành phần đó một cách trực tiếp, sử dụng lại các thành phần mức thấp hơn thường dễ dàng hơn đáng kể cho các thành phần nguồn mở so với các thành phần nguồn đóng.

Các yêu cầu cho một thành phần phần mềm sử dụng lại được

Một thành phần phần mềm sử dụng lại được thường sẽ là khép kín và có những biên giới được xác định rõ với lưu ý tới những gì nó làm và không làm được. Ở các biên giới đó nó sẽ thể hiện một tập hợp được xác định rõ như nhau các điểm giao diện mà sẽ cho phép tích hợp dễ dàng với các thành phần khác. Đối với hầu hết những người sử dụng, giao diện sẽ là đủ để cho phép sử dụng lại; đó là, sự triển khai sẽ được ẩn dấu thông qua vỏ bọc.

Đối với những người sử dụng nào cần sửa đổi bên trong thành phần đó theo một cách thức nào đó, ví dụ để bổ sung thêm một tính năng, hoặc sửa một lỗi không được phát hiện trước đó, thì một đặc tả rõ ràng, không mù mờ tối nghĩa và có thể hiểu được đối với thành phần đó sẽ được yêu cầu. Thành phần đó sau đó sẽ tuân thủ các kiểm thử đặc tả và tái thực hiện được của người sử dụng, sẽ kiểm tra sự tuân thủ này. Điều này cho phép người sử dụng sửa đổi các chi tiết triển khai, giả thiết mã nguồn là sẵn sàng, không sợ phá vỡ các hệ thống đang tồn tại đang sử dụng thành phần đó.

Khi phân phối một thành phần phần mềm sử dụng lại được, cũng quan trọng để cung cấp tài liệu rõ ràng về cách sử dụng lại nó, cùng với các ứng dụng ví dụ và các chỉ dẫn cài đặt và các script. Cuối cùng, là sống còn rằng thành phần đó được cấp phép đúng và các chi tiết đầy đủ được làm sẵn sàng cho người sử dụng đầu cuối.

Các mức độ sẵn sàng sử dụng lại

Các mô hình độ chín không phải là khái niệm mới hoặc duy nhất. Chúng thường được sử dụng trong nhiều lĩnh vực chuyên ngành để đo đếm và quản lý sự tiến bộ cùng với một thước đo độ chín. Ví dụ, Tích hợp Mô hình Độ chín Khả năng (Capability Maturity Model Integration) của Carnegie Mellon đưa ra một số mô hình cho phát triển phần mềm, mua sắm và cung cấp dịch vụ. Mô hình Độ chín Phần mềm Nguồn mở - OSMM (Open Source Maturity Model), Mô hình Độ chín Bền vững Phần mềm – SSMM (Software Sustainability Maturity Model) (bản dịch tiếng Việt) và Định phẩm chất và Lựa chọn Phần mềm Nguồn Mở - QSOSS (Qualification and Selection of Open Source Software) tất cả là những ví dụ các kỹ thuật đánh giá đề cập tới độ chín của các thành phần phần mềm. Tuy nhiên, từng trong số các mô hình đó tập trung vào các thành phần nguồn mở hơn là các thành phần phần mềm nói chung.

RRL được thiết kế để cho phép đánh giá bất kỳ thành phần phần mềm nào, bất kể phương pháp phát triển của thành phần đó. Trong trường hợp sử dụng lại hộp đen, đánh giá sử dụng các mức đó là đủ trong hầu hết các trường hợp. Tuy nhiên, sử dụng lại nguồn mở dạng hộp trắng đòi hỏi sự tham gia với cộng đồng dự án. RRL không đưa ra cơ chế cho một đánh giá như vậy. Vì thế, chúng tôi gợi ý cũng đánh giá bằng việc sử dụng một trong những mô hình khác được nêu ở trên.

Các Mức độ Sẵn sàng Sử dụng lại – RRL (Reuse Readiness Levels) có 9 mức độ sử dụng lại, như được chỉ ra trong bảng bên dưới. Trong khi các mức đó là hữu dụng, thì chúng thường được thấy là được định nghĩa quá rộng. Hệ quả là , một số Mức độ Chủ đề đã được định nghĩa. Chúng đưa ra một phương tiện để đánh giá các khía cạnh đặc thù của sử dụng lại và được thảo luận trong phần sau.

Tóm tắt các Mức độ Sẵn sáng Sử dụng lại

Mức	Tóm tắt	Mô tả
1	Khả năng sử dụng lại hạn chế; phần mềm không được khuyến cáo sử dụng lại.	Ít được cung cấp ngoài các mã nguồn hạn chế hoặc tiền biên dịch, các tệp nhị phân thực thi được. Không có sự hỗ trợ, thông tin liên hệ về các lập trình viên hoặc các quyền sử dụng lại được chỉ định, phần mềm không có khả năng mở rộng và không thỏa đáng hoặc không tài liệu.
2	Khả năng sử dụng lại sơ khai, sử dụng lại phần mềm là không thực tế.	Một số mã nguồn, tài liệu và thông tin liên hệ được cung cấp, nhưng vẫn còn rất hạn chế. Việc kiểm thử ban đầu từng được thực hiện, nhưng các quyền sử dụng lại vẫn còn chưa rõ. Sử dụng lại có thẻ là thách thức và chi phí cao tới mức cấm đoán.
3	Khả năng sử dụng lại cơ bản; phần mềm có thể sử dụng lại được với những người sử dụng có kỹ năng với nỗ lực, chi phí và rủi ro đáng kể.	Phần mềm có một số sự tuân thủ về khả năng module hóa và các tiêu chuẩn, một số hỗ trợ được các lập trình viên cung cấp, và các chỉ dẫn cài đặt chi tiết là sẵn sàng, nhưng các quyền không được chỉ định. Một chuyên gia có thể có khả năng sử dụng lại phần mềm, nhưng người sử dụng thông thường có thể không.
4	Sử dụng lại là có khả năng; phần mềm có thể được hầu hết mọi người sử dụng sử dụng lại với một số nỗ lực, chi phí và rủi ro.	Phần mềm và tài liệu là hoàn chỉnh và hiểu được. Phần mềm từng được trình bày trong một phòng thí nghiệm trong một hoặc nhiều nền tảng, các bản vá không thường xuyên sẵn sàng, và các vấn đề về sở hữu trí tuệ có thẻ cần phải được thương thảo. Sử dụng lại là có thể, nhưng có thể còn khó khăn.
5	Sử dụng lại là thực tế; phần mềm có thể được hầu hết người sử dụng sử dụng lại mà không có chi phí và rủi ro hợp lý nào.	Phần mềm ở mức độ khá về tính khả chuyển, module hóa, mở rộng được và có khả năng thiết lập cấu hình được, có sự tuân thủ các tiêu chuẩn độ trung thực thấp, có sách chỉ dẫn người sử dụng, và đã được kiểm thử trong phòng thí nghiệm. Cộng đồng người sử dụng tồn tại, nhưng có thẻ là cộng đồng nhỏ các chuyên gia. Các lập trình viên có thể có thể liên hệ được để yêu cầu các quyền sử dụng lại hạn chế.
6	Phần mềm có khả năng sử dụng lại được; phần mềm có thể được hầu hết người sử dụng sử dụng lại dù có thể có một số chi phí và rủi ro.	Phần mềm từng được thiết kế cho khả năng mở rộng, theo module và tính khả chuyển, nhưng phần mềm và tài liệu có thể vẫn có khả năng ứng dụng hạn chế. Các sách chỉ dẫn là có sẵn, và phần mềm từng được trình bày trong một ngữ cảnh phù hợp. Các lập trình viên có thể liên hệ được để có được các tuyên bố chính thức về các quyền bị hạn chế hoặc để thương lượng về các quyền bổ sung thêm.
7	Phần mềm sử dụng lại được cao độ; phần mềm có thể được hầu hết người sử dụng sử dụng lại với chi phí và rủi ro tối thiểu.	Phần mềm là khả chuyển và module hóa cao độ, có sự tuân thủ các tiêu chuẩn độ trung thực cao, đưa ra sự cài đặt tự động được xây sẵn, và đã được kiểm thử trong ngữ cảnh phù hợp. Hỗ trợ được các lập trình viên tổ chức, và một chỉ dẫn giao diện là sẵn sàng. Phần mềm và tài liệu là áp dụng được cho hầu hết các hệ thống. Các tuyên bố ngắn gọn là sẵn sàng, mô tả các quyền sử dụng hạn chế và các lập trình viên có thể liên hệ được để thương lượng về các quyền bổ sung thêm.
8	Khả năng sử dụng lại cục bộ được trình bày; phần mềm được nhiều người sử dụng sử dụng lại.	Phần mềm từng được trình bày sẽ mở rộng được, và được định lượng thông qua kiểm thử và trình bày. Chỉ dẫn mở rộng và hỗ trợ được các tổ chức cung cấp là sẵn sàng. Các tuyên bố ngắn goạn là có sẵn, mô tả các quyền sử dụng không bị hạn chế và các lập trình viên có thể liên hệ được để có được các tuyên bố về các quyền chính thức.
9	Khả năng sử dụng lại mở rộng được thể hiện; phần mềm đang được nhiều lớp người sử dụng qua một dải rộng các hệ thống sử dụng lại.	Phần mềm khả chuyển và module hóa đầy đủ, với tất cả sự tuân thủ các tiêu chuẩn và tài liệu thỏa đáng, việc đóng gói được bao bọc, một trình cài đặt GUI, và một cộng đồng hỗ trợ lớn cung cấp các bản vá. Phần mềm từng được kiểm thử và kiểm tra hợp lệ thông qua sử dụng đầu ra ứng dụng thành công. Nhiều tuyên bố mô tả các quyền sử dụng không hạn chế và trích dẫn được khuyến cáo được nhúng vào trong sản phẩm.

Các mức chủ đề

Một thành phần được đánh gía xuyên khắp một số mức chủ đề, mỗi mức đó đưa ra chỉ dẫn về những gì một người có thể mong đợi ở từng mức sử dụng lại. Các mức chủ đề được xác định là:

• Tài liệu
• Khả năng mở rộng
• Các vấn đề về sở hữu trí tuệ
• Khả năng module hóa
• Việc đóng gói
• Tính khả chuyển
• Tuân thủ các tiêu chuẩn
• Hỗ trợ
• Kiểm tra và kiểm thử

Một khi từng chủ đề được đánh giá, có khả năng đi tới được một mức độ sử dụng lại tổng thể cho thành phần phần mềm như là một tổng thể. Ví dụ, chúng ta có thể quyết định rằng mức thấp nhất đạt được xuyên khắp tất cả các chủ đề là mức của thành phần đó như là một tổng thể, hoặc chúng ta có thể bổ sung thêm một trọng số tới một hoặc nhiều mức chủ đề hơn.

Như một ví dụ về các mức chủ đề, một tóm tắt các mức Vấn đề Sở hữu Trí tuệ được đưa ra bên dưới:

Các mức của vấn đề về sở hữu trí tuệ

Mức	Tóm tắt
1	Các lập trình viên từng được nhận diện, nhưng không quyền nào được xác định.
2	Các lập trình viên đang thảo luận các quyền tuân thủ với các chính sách tổ chức của họ.
3	Các thỏa thuận các quyền đã được đề xuất cho các lập trình viên.
4	Các lập trình viên đã thương thảo về các thỏa thuận các quyền.
5	Thỏa thuận về quyền sở hữu, các quyền sử dụng lại hạn chế, và trích đoạn được khuyến cáo
6	Danh sách lập trình viên, trích đoạn được khuyến cáo và các tuyên bố quyền được phác thảo
7	Danh sách lập trình viên và tuyên bố các quyền hạn chế được đưa vào trong mẫu sản phẩm
8	Tuyên bố các quyền sở hữu trí tuệ và trích dẫn được khuyến cáo được đưa vào sản phẩm
9	Các tuyên bố mô tả các quyền không hạn chế, trich dẫn được khuyến cáo và các lập trình viên được nhúng vào trong sản phẩm

Kết luận

Sử dụng lại các thành phần phần mềm có thể cho phép tiết kiệm đáng kể trong sự phát triển các hệ thống mới. Tuy nhiên, đánh giá các thành phần để sử dụng lại có thể là khó khi xem xét các vấn đề phi kỹ thuật. Các Mức độ Sẵn sàng Sử dụng lại – RRL (Reuse Readiness Levels) đưa ra một cách thức có cấu trúc để đánh giá một thành phần để sử dụng lại. Có một cấu trúc như vậy sẽ giúp đảm bảo rằng tất cả các khía cạnh sử dụng lại được xem xét và cho phép người sử dụng thực hiện những lựa chọn có nhiều thông tin hơn, trong khi các lập trình viên có thể thiết lập các mục tiêu ưu tiên cho việc cải thiện khả năng sử dụng lại của thành phần đó. RRL có những ưu điểm hơn các hệ thống đánh giá khác theo đó chúng cho phép sự so sánh các thành phần phần mềm, bất kể phương pháp luận pháp triển nào được áp dụng. Đối với sử dụng lại hộp đen, điều này làm cho RRL áp dụng được rộng rãi. Tuy nhiên, ở những nơi sử dụng lại hộp trắng (đòi hỏi những sửa đổi đối với thành phần đó) sẽ phải được xem xét, thì RRL không đánh giá được tính phù hợp phương pháp luận phát triển của dự án cho sự sử dụng như vậy. Trong các trường hợp đó RRL nên được bổ sung với các công cụ độ chín nguồn mở đang tồn tại. Để có sự khai thác các vấn đề rộng lớn hơn trong mua sắm phần mềm, OSS Watch đã phát hành một chỉ dẫn cho Các yếu tố quyết định để sử dụng lại phần mềm nguồn mở (bản dịch tiếng Việt).

Software reuse can save time, save money, and increase the reliability of resulting products. However, an attempt to reuse software that is not easily reusable can have the reverse effect. There are a number of models for measuring the maturity of software components for reuse, but these tend to focus on a scoring system rather than clearly defining a maturity model. Since maturity models allow projects to measure their performance and thus set targets for improving reusability, it can be argued that they are of more value than scoring systems. The NASA Earth Science Data Systems (ESDS) Software Reuse Working Group (WG) has developed Reuse Readiness Levels as a model for such measurement and evaluation. This document introduces the concept of Reuse Readiness Levels and explores their applicability to open source software.

What is software reuse?

Software reuse is the reapplication of knowledge encapsulated in software code in order to reduce the effort of developing and maintaining a new software system. There are many things that need to be considered for reuse, not just the software itself. For example, even when software cannot be reused, data formats, high-level designs, algorithms or other items may be. Consequently, when considering software reuse we must examine each item of interest. These items are known as artifacts, assets and components.

An artifact is any item produced at some point during the software development life cycle. An artifact that can be reused, that is an artifact that is recognised as having a particular value, is known as an asset. A component is a clearly delineated piece of software that performs a useful function within a software system.

Reusable Software Components (RSCs) are software entities that are intended for reuse. In principle, many different artifacts produced during the software development life cycle can be reused, including: source code, analysis and design specification, plans (project management), data (testing), documentation, expertise and experience, quality assurance processes, and any information used to create software and software documentation. However, while all of these items are useful, software is the artifact that is most often reused.

There are many examples of software code being reused, especially if we look towards open source software for inspiration. Reusable software components range from small libraries, such as those in the Apache Commons project, through frameworks for building complete applications, such as the Eclipse Rich Client Platform to complete applications that can be extended through plugin systems, such as the Mozilla Firefox.

Reusing software components

There are two types of software reuse, black-box and white-box. Black-box means that the code implementation is hidden from the end user by well-defined and documented interfaces, usually an application programming interface (API), which allow the consumer to use the component without needing to know how it has been implemented. Black-box components can be more expensive to produce than white box components, but they will typically deliver greater overall savings for the end user in cases where the component is a natural fit to the user’s needs. Black-box reuse is therefore most common for general use cases, such as libraries for common activities within an application; for example, libraries for managing logging and error reporting can often be reused in this way. When reusing black-box components for web applications, such as Javascript libraries, it is also possible to use a component from a content delivery network (CDN), which results in accessing it over the Internet, rather than bundling the component with the application.

White-box reuse is reuse in which the user requires access to the internal implementation of the component in order to make modifications. It is more popular with many implementers because the component can be tailored to fit the exact needs of the target system. However, the productivity benefits of reuse can rapidly diminish as more modifications are introduced. White-box reuse is more common where systems overlap one another but have distinct requirements for their given domain. For example, web browsers will often be customised for specific use cases.

Open source software often presents the best of both worlds. Those wishing to reuse a component as a black-box can do so by downloading the binary releases of the software, whilst those requiring white-box reuse can obtain the project’s source code in order to make modifications. There is no need to decide in advance whether black-box or white-box is required, since one can move to the white-box model if limitations in the black-box model are identified. Furthermore, an open source project that is developed using an open development model will help project teams ensure that local modifications do not prevent upgrades to new versions of the component in the future.

Evaluating for reuse

The process of finding and evaluating software for reuse is similar, regardless of the mode of reuse. The key steps in the process are:

• Specifying the object to be created
• Searching the project, domain, and general databases for reuse candidates
• Evaluating the candidates to determine which (if any) should be used
• Modifying, if necessary, to fit specific needs
• Integrating the reusable component(s)
• Validating the system including the new component(s)
• Feeding back the knowledge regarding the payoff of reuse

Perhaps the hardest of these steps is ‘Evaluating the candidates to determine which (if any) should be used’. Failure to reject unsuitable components at the earliest opportunity will result in wasted effort in later stages. Reuse Readiness Levels (RRLs) are specifically designed to assist in this evaluation, by clearly defining a set of criteria against which a component can be evaluated for reuse. Applying a consistent set of criteria to components ensures that all aspects are considered and that all components are considered equally.

Using the RRLs to guide evaluation allows one to rate the component on a reuse maturity scale. The higher up this scale a component is rated, the easier reuse is likely to be. The lower down the scale, the more effort is required for reuse. Any software component can be measured against this scale, regardless of the development process adopted. However, since open source components allow the user to modify the component directly, reuse of lower-level components is often significantly easier for open source components than for closed source.

Requirements for a reusable software component

A reusable software component will typically be self-contained and have clearly defined boundaries with respect to what it does and does not do. At these boundaries it will present an equally clearly defined set of interface points that will allow easy integration with other components. For most users, the interface will be sufficient to allow reuse; that is, the implementation will be hidden through encapsulation.

For those users who need to modify the internals of the component in some way, for example to add a feature, or fix a previously undiscovered defect, a clear, unambiguous, and understandable specification for the component will be required. The component will then conform to the specification and user-reproducible tests will validate this conformance. This allows users to modify implementation details, assuming source code is available, without fear of breaking existing systems using the component.

When distributing a reusable software component, it is also important to provide clear documentation on how to reuse it, along with example applications and installation guides and scripts. Finally, it is critical that the component is correctly licensed and full details are made available to the end user.

Reuse readiness levels

Maturity models are not a new or unique concept. They are commonly used in many areas of endeavour to measure and manage progression along a scale of maturity. For example, the Carnegie Mellon Capability Maturity Model Integration provides a number of models for software development, acquisition and service provision. The Open Source Maturity Model, Software Sustainability Maturity Model and Qualification and Selection of Open Source Software are all examples of evaluative techniques that address software component maturity. However, each of these models focuses on open source components rather than software components in general.

The Reuse Readiness Levels are designed to allow evaluation of any software component, regardless of the development methodology of that component. In the case of black-box reuse, evaluation using these levels is sufficient in most cases. However, white-box reuse of open source requires engagement with the project community, for example to make sure local modifications can be fed back to the original project. As such, white-box reuse requires an evaluation of the development methodology and project community. The Reuse Readiness Levels do not provide a mechanism for such an evaluation. Therefore, we suggest also evaluating using one of the other models mentioned above.

The Reuse Readiness Levels consist of nine levels of reuse, which are shown in the table below. While these levels are useful, they are often found to be too broadly defined. Consequently, a number of Topic Levels have been defined. These provide a means for evaluating specific aspects of reuse and are discussed in the next section.

Reuse Readiness Level Summaries

Level	Summary	Description
1	Limited reusability; the software is not recommended for reuse.	Little is provided beyond limited source code or pre-compiled, executable binaries. There is no support, contact information for developers or rights for reuse specified, the software is not extensible, and there is inadequate or no documentation.
2	Initial reusability; software reuse is not practical.	Some source code, documentation, and contact information are provided, but these are still very limited. Initial testing has been done, but reuse rights are still unclear. Reuse would be challenging and cost-prohibitive.
3	Basic reusability; the software might be reusable by skilled users at substantial effort, cost, and risk.	Software has some modularity and standards compliance, some support is provided by developers, and detailed installation instructions are available, but rights are unspecified. An expert may be able to reuse the software, but general users would not.
4	Reuse is possible; the software might be reused by most users with some effort, cost, and risk.	Software and documentation are complete and understandable. Software has been demonstrated in a lab on one or more specific platforms, infrequent patches are available, and intellectual property issues would need to be negotiated. Reuse is possible, but may be difficult.
5	Reuse is practical; the software could be reused by most users with reasonable cost and risk.	Software is moderately portable, modular, extensible, and configurable, has low-fidelity standards compliance, a user manual, and has been tested in a lab. A user community exists, but may be a small community of experts. Developers may be contacted to request limited rights for reuse.
6	Software is reusable; the software can be reused by most users although there may be some cost and risk.	Software has been designed for extensibility, modularity, and portability, but software and documentation may still have limited applicability. Tutorials are available, and the software has been demonstrated in a relevant context. Developers may be contacted to obtain formal statements on restricted rights or to negotiate additional rights.
7	Software is highly reusable; the software can be reused by most users with minimum cost and risk.	Software is highly portable and modular, has high-fidelity standards compliance, provides auto-build installation, and has been tested in a relevant context. Support is developer-organized, and an interface guide is available. Software and documentation are applicable for most systems. Brief statements are available describing limited rights for reuse and developers may be contacted to negotiate additional rights.
8	Demonstrated local reusability; the software has been reused by multiple users.	Software has been shown to be extensible, and has been qualified through test and demonstration. An extension guide and organization-provided support are available. Brief statements are available describing unrestricted rights for reuse and developers may be contacted to obtain formal rights statements.
9	Demonstrated extensive reusability; the software is being reused by many classes of users over a wide range of systems.	Software is fully portable and modular, with all appropriate documentation and standards compliance, encapsulated packaging, a GUI installer, and a large support community that provides patches. Software has been tested and validated through successful use of application output. Multiple statements describing unrestricted rights for reuse and the recommended citation are embedded into the product.

Topic levels

A component is evaluated across a number of topic levels, each of which provides guidance about what one can expect at each reuse level. The topic levels defined are:

• Documentation
• Extensibility
• Intellectual Property Issues
• Modularity
• Packaging
• Portability
• Standards compliance
• Support
• Verification and Testing

Once each topic has been evaluated, it is possible to arrive at an overall reuse level for the software component as a whole. For example, we may decide that the lowest level achieved across all topics is the level of the component as a whole, or we may add a weighting to one or more topic levels.

As an example of the topic levels, a summary of the Intellectual Property Issue levels is provided below:

Levels of Intellectual Property Issues

Level	Summary
1	Developers have been identified, but no rights have been determined.
2	Developers are discussing rights that comply with their organizational policies.
3	Rights agreements have been proposed to developers.
4	Developers have negotiated on rights agreements.
5	Agreement on ownership, limited reuse rights, and recommended citation.
6	Developer list, recommended citation, and rights statements have been drafted.
7	Developer list and limited rights statement included in product prototype.
8	Recommended citation and intellectual property rights statement included in product.
9	Statements describing unrestricted rights, recommended citation, and developers embedded into product.

Conclusion

Software component reuse can enable considerable savings in the development of new systems. However, evaluation of components for reuse can be difficult when considering non-technical issues. Reuse Readiness Levels (RRLs) provide a structured way of evaluating a component for reuse. Having such a structure helps ensure that all aspects of reuse are considered and allows users to make more informed choices, while developers can set priority targets for improving reusability of the component. RRLs have advantages over other evaluation systems in that they allow a comparison of software components, regardless of the development methodology adopted. For black-box reuse, this makes RRLs widely applicable. However, where white-box reuse (requiring modifications to the component) is to be considered, RRLs fail to evaluate the suitability of the project development methodology for such reuse. In these cases RRLs should be supplemented with existing open source maturity tools. For an exploration of the wider issues in software procurement, OSS Watch has produced a guide to the Decision factors for open source software reuse.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com