Mô hình Độ chín Bền vững của Phần mềm

Software Sustainability Maturity Model

By Ross Gardler, Published: 07 September 2010, Reviewed: 12 March 2012

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

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

Lời người dịch: Để đánh giá độ chín của phần mềm, cả nguồn đóng và nguồn mở, có nhiều phương pháp để thực hiện, như CMMI, SSMM, RRR, SPICE và mỗi cách thức đó có những ưu và nhược điểm của riêng chúng. Bài viết này đề cập tới những phương pháp đó và cách kết hợp của chúng để đánh giá về Độ chín đối với Tính bền vững của phần mềm cho việc Sử dụng lại các phần mềm đó. “Chúng tôi tranh luận rằng bằng việc đánh giá một dự án với lưu ý về 3 yếu tố của tính bền vững - tính mở, khả năng sử dụng lại và khả năng - có khả năng nhấn mạnh các cơ hội cho sự cải tiến trong đổi mới mở, thiết kế sản phẩm và độ chín của qui trình. Điều này tới lượt nó sẽ cho phép các nhà quản lý tìm cách sử dụng lại hoặc phát triển tiếp các kết quả đầu ra của phần mềm, để phân bổ các tài nguyên theo một cách thức phù hợp nhất cho các nhu cầu dự án của họ”. Bài viết có thể là tham khảo rất tốt cho các công ty phần mềm và các nhà quản lý CNTT ở Việt Nam. Một khía cạnh khác là: để đánh giá năng lực các công ty phần mềm không chỉ có duy nhất CMMI.

Khi chọn sử dụng lại phần mềm cho mua sắm hoặc phát triển - bất kể mô hình giấy phép và sự phát triển mà bạn sẽ sử dụng - bạn cần cân nhắc tương lai. Trong khi một sản phẩm phần mềm có thể thỏa mãn các nhu cầu ngày nay, liệu nó có còn thỏa mãn các nhu cầu của ngày mai hay không? Liệu nhà cung cấp có vẫn còn ở xung quanh trong 5 năm nữa hay không? Nhà cung cấp liệu sẽ vẫn quan tâm cho tất cả các khách hàng của mình trong 5 năm nữa hay không? Nhà cung cấp sẽ có trách nhiệm trả lời cho các báo cáo lỗi và các yêu cầu tính năng nữa hay không? Nói cách khác, phần mềm có bền vững hay không?

Khi đánh giá phần mềm nguồn đóng, nhiều trong số này là công việc phỏng đoán. Phần mềm nguồn mở (PMNM), mặt khác, trình bày một số ưu điểm (bản dịch tiếng Việt) so với nguồn đóng, như những lựa chọn cho sự duy trì và phát triển liên tục của các cấu hình phần mềm cục bộ. Điều này có thể giảm thiểu các rủi ro do sự thất bại của nhà cung cấp thể hiện. Nhưng nó cũng là sự đánh giá sản phẩm phức tạp, vì những người mới tới với các phương pháp luận phát triển nguồn mở (bản dịch tiếng Việt) có thể thấy khó khăn để đánh giá phần mềm về tính bền vững của nó.

Tài liệu này phác thảo một đề xuất cho một Mô hình Độ chín Bền vững của Phần mềm – SSMM (Software Sustainability Maturity Model), nó có thể được sử dụng để chính thức đánh giá cả phần mềm nguồn mở và nguồn đóng với sự tôn trọng về tính bền vững của nó. Mô hình đưa ra một phương tiện đánh giá các rủi ro có liên quan tới việc áp dụng một giải pháp được đưa ra. Nó là hữu dụng cho những ai mua sắm các giải pháp phần mềm để triển khai và/hoặc tùy biến, cũng như để sử dụng lại trong các sản phẩm phần mềm mới. Cũng hữu dụng cho các nhà lãnh đạo dự án và các lập trình viên, khi nó cho phép họ xác định các lĩnh vực quan tâm, với sự tôn trọng về tính bền vững, trong các dự án của họ.

Các dạng sử dụng lại

Khái niệm Sử dụng lại phần mềm là quan trọng trong việc đánh gia tính bền vững của phần mềm. Vì thế trước khi chúng ta xem xét các kỹ thuật cho việc đo đếm tính bền vững của phần mềm, hãy xác định một số khái niệm quan trọng khi chúng được sử dụng trong ngữ cảnh này.

Sử dụng lại phần mềm là ứng dụng lại tri thức được gói trong mã phần mềm để giảm nỗ lực phát triển và duy trì một hệ thống phần mềm. Thậm chí khi một ứng dụng phần mềm hoàn chỉnh không thể được sử dụng lại được thì các thành phần riêng rẽ, 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 vẫn còn có thể sử dụng lại được.

Khi sử dụng lại các thành phần riêng rẽ của các hệ thống phần mềm, thường có 2 tiếp cận. Tiếp cận đầu là sử dụng lại một thành phần như nó đang có, mà không cần hiểu các công việc bên trong nó. Đó là, một người đơn giản thực hiện các lời gọi tới thành phần đó và nhận lại các kết quả. Khi sử dụng lại một thành phần theo cách này, một người phải chắc chắn thành phần đó chính xác được yêu cầu, khi mà không có khả năng sửa đổi hành vi của thành phần đó.

Tiếp cận thứ 2 khi sử dụng lại các thành phần phần mềm là thực hiện một số sửa đổi tới thành phần đó trước khi đưa nó vào trong hệ thống. Điều này có thể được thực hiện khi thành phần đó không thực hiện chính xác như được yêu cầu trong môi trường mới. Tuy nhiên, để cho phép dạng sử dụng lại này, thành phân đó phải được thiết kế lại và được viết lại tài liệu, và được cấp phép theo một cách thức mà cho phép sự sửa đổi đó.

Các yếu tố ảnh hưởng tới tính bền vững của phần mềm

Tính bền vững của phần mềm bị ảnh hưởng vì cả các vấn đề kỹ thuật và phi kỹ thuật. Các vấn đề kỹ thuật có xu hướng tập trung vào cách sử dụng lại được mà phần mềm đó là - như, tiềm năng của nó cho sự thích nghi - trong khi các vấn đề phi kỹ thuật bao gồm cách mà một dự án được điều hành (bản dịch tiếng Việt) và được cấp vốn. Thường không có khả năng tách bạch rõ ràng các vấn đề kỹ thuật khỏi các vấn đề phi kỹ thuật.

Để bền vững được qua thời gian, phần mềm cần phải vừa là hữu dụng và vừa có khả năng thích nghi được. Nó cũng cần phải tiến hóa khi các nhu cầu của người sử dụng tiến hóa. Tiềm năng sử dụng lại vì thế là yếu tố chủ chốt trong tính bền vững của phần mềm. Sử dụng lại có thể tiết kiệm được thời gian và tiền bạc, và làm gia tăng độ tin cậy của các sản phẩm kết quả. Tuy nhiên, một ý định để sử dụng lại phần mềm mà là không dễ dàng sử dụng lại được có thể có hiệu ứng ngược. Mục tiêu của Mô hình Độ chín về Tính bền vững của Phần mềm (SSMM) là để cung cấp một biện pháp đánh giá các yếu tố rủi ro trong việc sử dụng lại phần mềm.

Tính bền vững của phần mềm cũng bị ảnh hưởng bởi số lượng các môi trường trong đó phần mềm có khả năng được sử dụng và sử dụng lại. Ví dụ, nếu một công cụ có khả năng áp dụng được cho chỉ một số nhỏ những người sử dụng mà thực hiện những đóng góp tối thiểu cho dự án, thì ít có khả năng là các tài nguyên đầy đủ đó sẽ có sẵn sàng cho sự hỗ trợ và phát triển liên tục của sản phẩm.

Là không thông thường thực tiễn tốt đối với ý định để tạo ra một giải pháp phần mềm mà tìm cách làm thỏa mãn cho quá nhiều nhóm người sử dụng khác hẳn nhau. Điều này là vì khó để giải quyết các nhu cầu của tất cả những người sử dụng tiềm năng mà không phải thực hiện những thỏa hiệp đáng kể. Vì thế trở nên ngày càng phổ biến đối với các nhà cung cấp để chia sẻ các thành phần cốt lõi của một hệ thống phần mềm và sau đó tập trung vào nhóm người sử dụng đặc thù cần ở các mức trừu tượng hóa cao hơn, như các giao diện người sử dụng. Ví dụ, cân nhắc rằng nhiều máy tìm kiếm trên Internet, các mạng xã hội và các dịch vụ micro - blogging tất cả cộng tác trong cùng y hệt các khung công việc quản lý dữ liệu cốt lõi. Trong các trường hợp đó, các tổ chức mà thường xuyên cạnh tranh trong thị trường đó có khả năng cộng tác trong cộng nghệ chồng lấn, trong khi vẫn phát triển những ưu thế cạnh tranh trong thị trường đặc thù của họ. Thường được gọi là đổi mới mở (bản dịch tiếng Việt), tiếp cận này được thảo luận chi tiết hơn trong trình diễn video ở trên.

Có nhiều ví dụ mã phần mềm đang được sử dụng, đặc biệt nếu chúng ta nhìn vào phần mềm nguồn mở để truyền cảm hứng. Các thành phần phần mềm có khả năng sử dụng lại trải từ các thư viện nhỏ, như những 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. Cũng có những ứng dụng hoàn chỉnh mà có thể được mở rộng thông qua các hệ thống cài cắm (plug-in), như Moodle, Drupal hoặc trình duyệt web Mozilla Firefox.

Các kỹ thuật để đo đếm tính bền vững

Một kỹ thuật đánh giá tính bền vững đủ giàu có nên đề cập tới cả các khía cạnh kỹ thuật và phi kỹ thuật của các thành phần và hệ thống phần mềm có ý định cho sự triển khai hoặc sử dụng lại.

Nhiều tiếp cận cho việc đo đếm tính bền vững của phần mềm và các qui trình quản lý của nó. Tuy nhiên, các đo đếm định tính là có vấn đề, khi chúng cho phép ý kiến cá nhân gây ảnh hưởng tới các kết quả. Ví dụ, một người bản hàng tốt hoặc lãnh đạo dự án có thể gây ảnh hưởng đáng kể tới đánh giá định tính của một sản phẩm.

Ngoài các biện pháp định tính ra, có nhiều tiếp caanhj định lượng cho việc đo đếm khả năng sử dụng lại. Chúng sẽ xem xét bản thân mã và/hoặc các dữ liệu công khai có sẵn về mô hình phát triển của dự án. Nhưng những thứ đó đòi hỏi sự truy cập tới mã nguồn và các dữ liệu quản lý (như dữ liệu theo dõi các lổi), vì thế làm cho có khả năng để đánh giá cả phần mềm nguồn mở và nguồn đóng bằng việc sử dụng cùng y hệt phương pháp đó. Một dự án được phát triển mở (bản dịch tiếng Việt) cho phép tất cả các khía cạnh của sự quản lý, điều hành và mã nguồn sẽ được xem xét, trong khi một dự án đóng thường sẽ dựa vào những đảm bảo từ những người chủ sở hữu dự án, hơn là vào đánh giá toàn diện.

Trong phần này chúng tôi xem xét một số kỹ thuật đánh giá hiện hành và giới thiệu một 'sự xếp hạng tính mở' mới, nó được thiết kế để cho phép đánh giá các cơ hội cho sự cộng tác với các bên thứ 3 trong thiết kế, triển khai và duy trì các kết quả đầu ra của dự án. Một sự khác biệt chủ chốt giữa việc xếp hạng tính mở và các kỹ thuật đang tồn tại là việc xếp hạng tính mở xem xét các rào cản tiềm tàng cho các dạng cộng tác cần thiết để đạt được những phần thưởng của đổi mới mở trong phần mềm.

Các kỹ thuật không chính thức

Các kỹ thuật không chính thức (bản dịch tiếng Việt) là nhanh và dễ dàng để áp dụng, nhưng chúng không nhất quán và mở cho sự diễn giải. Chúng tập trung vào thông tin mà dễ dàng truy cập được cho những người đánh giá. Trong một dự án phần mềm nguồn mở, thông tin nhiều hơn nhiều là sẵn sàng so với trogn một dự án nguồn đóng. Điều này cho phép một sự đánh giá hoàn chỉnh hơn đối với dự án. Ví dụ, bổ sung thêm vào các tính năng trực quan đang tồn tại và sử dụng của một dự án nguồn đóng, thì hiện trạng, nhịp độ và đường hướng của sự phát triển liên tục là nhìn thấy rõ ràng trong một dự án nguồn mở.

Vì tính mềm dẻo cà bản chất tự nhiên không có cấu trúc của nó, các kỹ thuật không chính thức có thẻ được tạo ra và được áp dụng cho cả các khía cạnh kỹ thuật và phi kỹ thuật của phát triển và sử dụng lại phần mềm. Một đánh giá không chính thức có thể bao gồm một đánh giá sơ bộ các tính năng theo yêu cầu, một sự rà soát lại lướt nhanh những người sử dụng đang tồn tại và một sự xem xét về quản lý của dự án. Tuy nhiên, chúng không thể được áp dụng một cách đáng tin cậy cho các dự án khác nhau một cách chính xác vì chúng là không chính thức, đó là chúng thiếu các qui trình đánh giá được xác định và lặp đi lặp lại được. Tính hữu dụng của chúng vì thế bị hạn chế cho việc làm hẹp đi một số lượng lớn các ứng viên đối với một tập hợp có khả năng quản lý được hơn các ứng viên mà có thể sau đó được đánh giá một cách chính thức.

Các kỹ thuật chính thức

Có nhiều kỹ thuật chính thức cho việc đo đém tính hiệu quả của các đội và các qui trình phát triển phần mềm. Một số có uy tín tốt, như Mô hình Độ chín theo Khả năng – CMM (Capability Maturity Model). Những mô hình khác, như Xếp hạng Tính sẵn sàng Sử dụng lại – RRR (Reuse Readiness Rating), là ít có uy tín hơn nhưng tuy vậy vẫn được sử dụng trong các tổ chức đáng kể. Thậm chí còn ít có uy tín hơn nữa nhưng vẫn đưa ra được công việc nền tảng hữu dụng cho một Mô hình Độ chí về Tính bền vững của Phần mềm – SSMM (Software Sustainability Maturity Model). Các phần bên dưới phác họa ngắn gọn một số kỹ thuật đánh giá chính thức được sử dụng trong công việc này.

Mô hình Độ chín theo Khả năng (CMM)

CMM đã được giới thiệu vào đầu những năm 1980. Nó đưa ra một tập hợp các mô hình đánh giá được sử dụng lại để xác định khả năng của một tổ chức phân phối một mẩu phần mềm, đúng thời gian và với một mức chất lượng chấp nhận được. Những ví dụ chung nhất là Tích hợp cho Phát triển Mô hình Độ chín theo Khả năng - CMMI-DEV (Capability Maturity Model Integration for Development) và Xác định Khả năng và sự Cải tiến Qui trình Phần mềm - SPICE (Software Process Improvement and Capability dEtermintation, còn được gọi là ISO 15504). Để áp dụng các mô hình đó, một người đòi hỏi sự truy cập tới đội phát triển. Thoạt nhìn, điều này làm cho chúng lý tưởng cho việc áp dụng cả đối với các dự án nguồn mở và nguồn đóng.

Tuy nhiên, CMM không thể áp dụng được trực tiếp cho các cộng đồng dự án nguồn mở, vì nó giả thiết một cấu trúc tổ chức có ràng buộc. Tuy vậy, vì một dự án nguồn mở được quản lý tốt sẽ có các qui trình và cấu trúc được xác định tại chỗ, không có lý do vì sao các khái niệm được thấy trong các mô hình đó không thể áp dụng được để áp dụng chúng cho các dự án nguồn mở.

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

Các Nhóm Làm việc về Sử dụng lại Phần mềm (WG) của các hệ thống dữ liệu khoa học Trái đất của NASA (ESDS) đang phát triển RRR (Reuse Readiness Rating) (bản dịch tiếng Việt) như một mô hình để đo đếm và đánh giá khả năng sử dụng lại của các thành phần và hệ thống phần mềm. RRR được thiết kế để đánh giá bất kỳ thành phần phần mềm nào, bất kể phương pháp luận phát triển của thành phần đó.

Khi sử dụng lại các thành phần phần mềm không có sửa đổi, sự đánh giá sử dụng các mức đó là đủ trong hầu hết các trường hợp. Tuy nhiên, nếu chúng ta định tiến hành các tùy biến cho phần mềm mà chúng ta đang sử dụng lại thì chúng ta cũng cần một đánh giá phương pháp luận phát triển và quản lý dự án. Các mức Sẵn sàng Sử dụng lại không đưa ra một cơ chế cho sự đánh giá như vậy, mà đưa ra một khung công việc cho đánh giá kỹ thuật của các thành phần theo yêu cầu.

Các mô hình đánh gia nguồn mở

Có một số mô hình đánh giá PMNM, bao gồm Mô hình Độ chín Nguồn Mở - OSMM của Capgemini và cái khác có cùng tên của Navica, Xếp hạng Độ sẵn sàng của Doanh nghiệp và Định chất lượng và Lựa chọn PMNM - QSOS (Qualification and Selection of Open Source software). Mỗi trong số các mô hình đó có ý định cung cấp một biện pháp đánh giá các khía cạnh phi kỹ thuật của một dự án PMNM, nhưng gì một số người có thể gọi là 'tính mở' của mô hình phát triển của chúng. Đó là, chúng được sử dụng để giúp chỉ dẫn đánh giá dự án như một sự tổng hợp của cả 2 các đầu ra của nó và đội phát triển của nó (hoặc cộng đồng trong trường hợp của nguồn mở).

Các tiếp cận đó là hữu dụng trong đó chúng nhấn mạnh tới tầm quan trọng của việc xem xét sức khỏe cộng đồng khi lựa chọn các sản phẩm nguồn mở. Tuy nhiên, chúng không thể dễ dàng được áp dụng cho các dự án nguồn đóng nơi mà tính trực quan theo yêu cầu trong đội phát triển dự án thường không được thể hiện. Ví dụ, không có khả năng để đánh giá tính hiệu quả của việc theo dõi các vấn đề và lên kế hoạch phát hành mà không có sự truy cập trình theo dõi các vấn đề của các dự án. Ddieuf này không phải là sự thất bại của các mô hình đánh giá, mà là kết quả của sự thiếu hụt thông tin minh bạch về sự phát triển của hầu hết các sản phẩm nguồn đóng.

Xếp hạng Tính mở

OSS Watch, trong quan hệ đối tác với Pia Waugh, đã phát triển một 'xếp hạng tính mở'. Đây là một loạt các câu hỏi được thiết kế để chỉ dẫn đánh giá của một cấu trúc dự án với sự tôn trọng quản lý sở hữu trí tuệ, áp dụng các tiêu chuẩn, quản lý tri thức, quản lý dự án, và các cơ hội thị trường. Không giống như các mô hình trước đó được thiết kế để đánh giá các dự án nguồn mở, mô hình này có thể được áp dụng cho cả các sản phẩm phần mềm nguồn mở và nguồn đóng.

Xếp hạng Tính mở cho phép một người xác định các điểm mạnh và yếu trong một cấu trúc quản lý dự án với sự tôn trọng cho phép sự cộng tác của bên thứ 3 và sử dụng lại các kết quả đầu ra. Điều này cho phép những người quản lý dự án xác định các lĩnh vực mà có thể không có chủ ý hạn chế các cơ hội cộng tác. Tương tự, việc xếp hạng cho phép các bên thứ 3 hiểu được những rào cản nào đang tồn tại với lưu ý tới việc thực hiện các sửa đổi cục bộ tới các kết quả đầu ra của phần mềm từ các bên thứ 3. Bằng việc sử dụng công cụ này cả 2 bên có thể lên kế hoạch có hiệu quả hơn cho sự phân bổ các tài nguyên của họ phù hợp với các nhu cầu của họ.

Các kỹ thuật được tự động hóa

Một số kỹ thuật đo đếm tự động đối với các mô hình phát triển cộng đồng và chất lượng phần mềm cũng đã được khai thác. Đó là, có thể, một trong những lĩnh vực nặng nhọc nhất của đánh giá phần mềm. Các công cụ được tự động hóa có xu hướng đưa ra một tổng kết mức cao mà làm mờ đi các chi tiết ở bên dưới. Vì lý do này một số người cảm thấy rằng chúng là biện pháp không hiệu quả đối với tính bền vững. Dù thế, có thể là một sai lầm để bỏ qua tất cả các tiếp cận được tự động hóa mà không có việc cân nhắc ở những nơi mà chúng có thể bổ sung thêm giá trị.

Đánh giá cộng đồng một cách tự động

Các kỹ thuật đánh giá cộng đồng có xu hướng đo đếm hoạt động về các trình theo dõi vấn đề, các trình theo dõi lỗi. các danh sách thư và kiểm soát phiên bản. Chúng đưa ra một số chỉ số hoạt động cộng đồng và vì thế, theo những người đề xướng của chúng, một biện pháp về sức khỏa của cộng đồng. Tuy nhiên, việc đo đếm sức khỏe cộng đồng bằng sử dụng các kỹ thuật định lượng, đối với nhiều người, là không hoàn thiện.

Các đo đếm định lượng, như số lượng các thư điện tử được gửi hoặc được đệ trình, không đưa ra được tham chiếu tới giá trị của các hoạt động đó. Ví dụ, một thư điện tử duy nhất mà cản trở một lỗi chính trong thiết kế là quan trọng hơn nhiều với lưu ý cho tính bền vững của phần mềm so với nhiều thư điện tử thảo luận về màu sắc của một núm trong giao diện của người sử dụng. Các kỹ thuật định lượng không có khả năng thực hiện sự khác biệt này. Những hạn chế của đánh giá định lượng các cộng đồng nguồn mở làm cho các kỹ thuật được tự động hóa trở thành một chủ đề thú vị cho các nghiên cứu hàn lâm. Tuy nhiên, hiện tại chúng có giá trị hạn chế khi đo đếm tính bền vững. Tuy nhiên, với sử dụng cẩn thận, chúng có thể hành động như những cho chỉ số của các lĩnh vực đòi hỏi sự xem xét chi tiết hơn hoặc các xu thế chung bên trong cộng đồng.

Đánh giá chất lượng phần mềm tự động

Đánh giá tự động chất lượng phần mềm là chín muồi hơn so với đánh giá tự động các mô hình phát triển cộng đồng và vì thế đưa ra các biện pháp có giá trị hơn. Điển hình, các công cụ sẽ tìm cách đo đếm các yếu tố như độ ổn định, khả năng kiểm thử, và an ninh. Trong nhiều dự án nó được xem xét là thực tiễn tốt để tích hợp một số dạng các công cụ đó trong qui trình phát triển.

Có nhiều ví dụ về các công cụ phân tích mã tự động. Các công cụ đó khi được sử dụng đúng, có thể đưa ra thông tin có giá trị về các khía cạnh đặc thù về chất lượng mã và sự quản lý.

Mô hình Độ chín về tính Bền vững của Phần mềm – SSMM

Để xác định mô hình độ chín cho tính bền vững của phần mềm, chúng tôi đã xây dưng sự truyền cảm hứng từ từ trong các kỹ thuật đánh giá được mô tả ở trên. Trong một số trường hợp (Các mức Sẵn sàng của Khả năng sử dụng lại và Mô hình Độ chín theo Khả năng), chúng tôi đã mở rộng hơn là áp dụng mô hình đó. Chúng tôi mô tả các thuộc tính chính được thấy ở từng mức độ, nhưng không chi tiết hóa các thuộc tính và tính năng theo yêu cầu cho sự tiến bộ từ một mức này sang mức tiếp sau. Trước khi xem xét các thuộc tính chủ chốt đó, hãy xác định từng trong số 9 mức độ trong mô hình đó. Trong việc đặt tên từng mức đó chúng tôi đã lấy cảm hứng từ vòng đời của một cây lê:

hạt giống

Dự án là ít hơn so với một ý tưởng và một bức vẽ trống. Ở giai đoạn này, không ai ngoài (những) người chủ dự án và môi trường ngay lập tức của họ có thể có bất kỹ ảnh hưởng nào lên kết quả đầu ra cuối cùng.

nảy mầm

Dự án đang bắt đầu hình thành, nhưng nó vẫn còn ít hơn là một đề xuất. (Những) người chủ dự án còn chưa bắt đầu truyền đạt các mục tiêu của dự án theo bất kỳ cách thức nào có ý nghĩa.

cây con

Có một sự triển khai giai đoạn sớm giải pháp ở thời điểm này. Tuy nhiên, không có sự tham gia của (những) người chủ dự án có lẽ có khả năng cao là không sống sót được. (Những) người chủ dự án không, nói chung, tìm đầu vào từ bên ngoài khác so với thông qua sự trợ giúp được ký hợp đồng, dù họ làm cho mã nguồn sẵn sàng để sử dụng lại.

vị thành niên

Dự án đang bắt đầu đưa vào cuộc sống của riêng nó, dù vẫn còn hầu hết được (những) người chủ dự án chỉ dẫn. Một số khía cạnh thiết kế dự án bây giờ có thể được ai đó khác với (những) người chủ dự án dẫn dắt, dù (những) người chủ dự án gốc ban đầu vẫn còn là sống còn cho sự phát triển của dự án vì họ là 'những người canh giữ' cho dự án.

đâm hoa

Dự án có khả năng hoạt động một cách độc lập trong một tập các chỉ tiêu được xác định hẹp. Những tác động từ bên ngoài đang bắt đầu có một ảnh hưởng đáng kể vào tương lai của dự án và vì thế một cộng đồng những người ngang hàng đang xây dựng xung quanh dự án.

thụ phấn

Dự án và cộng đồng có liên quan của nó không còn bị (những) người chủ dự án ban đầu kiểm soát nữa. Có khả năng là dự án có thể tiếp tục nếu (những) người chủ dự án rút lui hoàn toàn. Bản thân (những) người chủ dự án nhận thức được điều này và đang đảm bảo rằng các cơ chế là sẵn sàng để cho phép cộng đồng sẽ chỉ dẫn dự án hướng tới tính bền vững đầy đủ.

kết trái

Cộng đồng là tự tổ chức và đang hoàn thành các vai trò quan trọng trong cấu trúc quản lý dự án. Người lãnh đạo dự án vẫn còn là sống còn cho sự sống còn của dự án, nhưng có những ứng viên có khả năng thực hiện được vai trò của họ, một sự quá độ về quản lý được đưa ra.

chín muồi

Dự án đã ngắt tự do khỏi (những) người chủ dự án ban đầu và có thể sống sót được một cách độc lập. Cộng đồng và dự án mà cộng đồng làm việc bây giờ có khả năng ra các quyết định vì lợi ích của tất cả những người ngang hàng, hơn là vì bất kỳ tập con nào các thành viên của cộng đồng.

phân tán

Dự án đang làm thỏa mãn các nhu cầu của một tập hợp đa dạng những người sử dụng và những người đóng góp và có thể hầu như nhất định sống sót với sự ra đi của người lãnh đạo hiện hành của dự án.

Bảng bên dưới phác thảo các tính năng chủ chốt của từng trong các mức đó và ánh xạ chúng tới Mô hình Độ chín theo Khả năng (CMM) và các Mức độ Sẵn sàng Sử dụng lại – RRL (Reuse Readiness Levels). Từng mức SSMM kết hợp các yêu cầu của cả CMM và RRL, bổ sung thêm vào các yêu cầu tiếp được phác họa trong bảng này. Lưu ý rằng các yêu cầu để đạt được một mức là tối thiểu, không phải là tối đa. Ví dụ, mã phần mềm có thể có sẵn theo một giấy phép nguồn mở trước mức 5, nhưng để đạt được mức 5 thì điều này phải là như thế.

Bảng 1. Phác thảo SSMM

Mức SSMM	Tên SSMM	Tóm tắt tính mở	Mức sẵn sàng sử dụng lại (RRL)	Mức của Mô hình Độ chín theo Khả năng (CMM)
0	Hạt giống	Không mã nguồn nào sẵn sàng theo một giấy phép của OSI.	1 - Không có khả năng sử dụng lại; Phần mềm không sử dụng lại được.	0 - Không tương thích
1	Nảy mầm	Hoặc không có mã nguồn sẵn sàng hoặc mã nguồn không thẩm tra được; không có qui trình quản lý IP cho phép những đóng góp của các bên thứ 3.	2 - Khả năng sử dụng lại ban đầu; sử dụng lại phần mềm là không thực tế.	1 - Những người có năng lực và những hào kiệt
2	Cây con	Mã nguồn thẩm tra được là sẵn sàng trong một hệ thống kiểm soát phiên bản công khai (bản dịch tiếng Việt) với quyền sở hữu IP và cấp phép (bản dịch tiếng Việt) theo dõi được.	3 - Khả năng sử dụng lại cơ bản; phần mềm có thể sử dụng lại được từ những người sử dụng có kỹ năng với nỗ lực, chi phí và rủi ro đáng kể.	2 - Quản lý dự án cơ bản
3	Vị thành niên	(Những) người chủ dự án có cơ chế cho việc tham gia với sự quan tâm có hiểu biết của bên thứ 3 trong dự án; dự án có một địa chỉ thư có trách nhiệm trả lời.	4 - Sử dụng lại là có thể; phần mềm có thể được hầu hết người sử dụng với một số nỗ lực, chi phí và rủi ro sử dụng lại được.
4	Đâm hoa	Các bên thứ 3 có khả năng kiểm tra, hiểu và gây ảnh hưởng tới tương lai của dự án; dự án có một trình theo dõi vấn đề công khai, website thông tin và danh sách thư, tất cả chúng được sử dụng để quản lý dự án.	5 – Sử dụng lại là thực tế; phần mềm có thể được hầu hết những người sử dụng với chi phí và rủi ro hợp lý sử dụng lại được.	3 - Tiêu chuẩn hóa qui trình
5	Thụ phấn	Các bên thứ 3 có thiện chí và khả năng nhận trách nhiệm cho những khía cạnh chính của phát triển dự án; trình theo dõi vấn đề và danh sách thư là tích cực và có trả lời cho các yêu cầu của các bên thứ 3; mã nguồn được phát hành theo một giấy phép do OSI phê chuẩn.	6 - Phần mềm sử dụng lại được; phần mềm có thể được hầu hết những người sử dụng sử dụng lại dù còn có thế có một vài chi phí và rủi ro.
6	Kết trái	Phần mềm được quản lý theo một cách thức để đảm bảo rằng những thay đổi của 1 người không phá vỡ sự sử dụng lại của người khác; mã có các kiểm thử đủ theo đơn vị và các qui trình quản lý để đảm bảo rằng các phát hành có chất lượng nhất quán chấp nhận được.	7 - Phần mềm sử dụng lại được cao độ; phần mềm có thể được hầu hết những người sử dụng với chi phí và rủi ro tối thiểu sử dụng lại được.	4 - Quản lý định lượng
7	Chín muồi	Các vai trò trong dự án được xác định rõ ràng và các nhiệm vụ quản lý chính được nhiều hơn một thành viên cộng đồng điều hành; các qui trình giải quyết xung đột và ra quyết định được xác định theo một tài liệu điều hành (bản dịch tiếng Việt) và được tuân thủ.	8 – Khả năng sử dụng lại được thể hiện; phần mềm đã và đang được nhiều người sử dụng sử dụng lại.
8	Phân tán	Dự án có khả năng duy trì xung lượng của riêng nó một cách độc lập với bất kỳ một người tham gia nào trong cộng đồng; một mô hình điều hành được gắn vào và được sửa đổi đáp ứng được những thách thức đang nổi lên; không người tham gia duy nhất nào của dự án có sự kiểm soát đối với dự án và vì thế những người mới tới có khả năng giành được ảnh hưởng.	9 – Khả năng sử dụng lại được chứng minh; phần mềm đang được nhiều tầng lớp người sử dụng bao trùm một dải rộng lớn các hệ thống sử dụng lại.	5 - Cải tiến qui trình liên tục

Kết luận

Đề xuất này cho SSMM thể hiện cách một việc xếp hạng tính mở mới có thể được kết hợp với các mô hình đang tồn tại được sử dụng để đánh giá các khía cạnh khác nhau của các qui trình phát triển phần mềm và các kết quả đầu ra của chúng.

Chúng tôi tranh luận rằng bằng việc đánh giá một dự án với lưu ý về 3 yếu tố của tính bền vững - tính mở, khả năng sử dụng lại và khả năng - có khả năng nhấn mạnh các cơ họi cho sự cải tiến trong đổi mới mở, thiết kế sản phẩm và độ chín của qui trình. Điều này tới lượt nó sẽ cho phép các nhà quản lý tìm cách sử dụng lại hoặc phát triển tiếp các kết quả đầu ra của phần mềm, để phân bổ các tài nguyên theo một cách thức phù hợp nhất cho các nhu cầu dự án của họ.

Nếu bạn muốn áp dụng việc xếp hạng tính mở cho dự án của riêng bạn, xin liên hệ với chúng tôi.

When choosing software for procurement or development reuse - regardless of the licence and development model you will use - you need to consider the future. While a software product may satisfy today’s needs, will it satisfy tomorrow’s needs? Will the supplier still be around in five years’ time? Will the supplier still care for all its customers in five years’ time? Will the supplier be responsive to bug reports and feature requests? In other words, is the software sustainable?

When evaluating closed source software, much of this is guesswork. Open source software, on the other hand, presents a number of advantages over closed source, such as options for the ongoing maintenance and development of local software configurations. This can reduce the risks presented by supplier failure. But it can also complicate product evaluation, since newcomers to open source development methodologies may find it difficult to evaluate the software in terms of its sustainability.

This document outlines a proposal for a new Software Sustainability Maturity Model (SSMM), which can be used to formally evaluate both open and closed source software with respect to its sustainability. The model provides a means of estimating the risks associated with adopting a given solution. It is useful for those procuring software solutions for implementation and/or customisation, as well as for reuse in new software products. It is also useful for project leaders and developers, as it enables them to identify areas of concern, with respect to sustainability, within their projects.

Types of reuse

The concept of Software reuse is important in relation to evaluating software sustainability. So before we examine existing techniques for measuring software sustainability, let’s define some important terms as they are used in this context.

Software reuse is the re-application of knowledge encapsulated in software code in order to reduce the effort of developing and maintaining a new software system. Even when a complete software application cannot be reused individual components, data formats, high-level designs, algorithms or other items may still be reusable.

When reusing individual components of software systems there are generally two approaches. The first is to reuse of a component as-is, without the need to understand its inner workings. That is, one simply makes calls on the component and receives the results. When reusing a component in this way, one has to be sure the component exactly as required, as it is not possible to modify the component’s behaviour.

The second approach when reusing software components is make some modifications to the component before including it in the system. This can be done when the component does not perform precisely as required in the new environment. However, in order to allow for this type of reuse, the component must be well-designed and documented, and licensed in a way that allows for modification.

Factors affecting software sustainability

The sustainability of software is affected by both technical and non-technical issues. Technical issues tend to focus on how reusable the software is - i.e. its potential for adaptation - while non-technical issues include how a project is governed and funded. Often it is not possible to cleanly separate the technical issues from the non-technical issues.

To be sustained over time, software needs to be be both useful and adaptable. It also needs to evolve as the users’ needs evolve. The potential for reuse is therefore a key factor in the sustainability of software. Reuse can save time and money, and increase the reliability of resulting products. However, an attempt to reuse software that is not easily reusable can have the reverse effect. The goal of the Software Sustainability Maturity Model is to provide a means of evaluating the risk factors in reusing software.

Software sustainability is also affected by the number of environments in which the software is likely to be used and reused. For example, if a tool is applicable to only a small number of users who make minimal contributions to the project, it is less likely that sufficient resources will be available for the ongoing support and development of the product 1.

It is not normally good practice to attempt to create a software solution that seeks to satisfy too many disparate groups of users. This is because it is difficult to address the needs of all potential users without having to make significant compromises. It is therefore becoming increasingly common for suppliers to share core components of a software system and then focus on a specific group of user needs at higher levels of abstraction, such as the user interfaces. For example, consider that numerous Internet search engines, social networks and micro-blogging services all collaborate on the same core data management frameworks. In these cases organisations that often compete in the marketplace are able to collaborate on overlapping technology, while still developing competitive advantages in their specific market. Often called open innovation, this approach is discussed in more detail in the video presentation above.

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

Techniques for measuring sustainability

A sufficiently rich sustainability evaluation technique should address both technical and non-technical aspects of software components and systems intended for implementation or reuse.

Many approaches to measuring the sustainability of software rely on a set of qualitative measures that examine the implementation of the software and its management processes. However, qualitative measures are problematic, as they allow personal opinion to influence the results. For example, a good salesperson or project lead can significantly influence the qualitative evaluation of a product.

In addition to the qualitative measures, there are numerous quantitative approaches to measuring reusability. These will examine the code itself and/or publicly available data about the project’s development model. But these require access to the source code and management data (such as bug tracking data), thus making it impossible to evaluate both open and closed source software using the same method. An openly developed project allows all aspects of management, governance and source code to be examined, while a closed project will often rely on assurances from the project owners, rather than an exhaustive evaluation.

In this section we examine a number of existing evaluation techniques and introduce a new ‘openness rating’, which is designed to enable the evaluation of opportunities for collaboration with third parties in the design, implementation and maintenance of a project’s outputs. A key difference between the openness rating and existing techniques is that the openness rating examines potential barriers to the kinds of collaboration necessary to reap the rewards of open innovation in software.

Informal techniques

Informal techniques are quick and easy to apply, but they are inconsistent and open to interpretation. They focus on information that is easily accessible to the evaluators. In an open source software project, far more information is available than in a closed source project. This enables a much more complete evaluation of the project. For example, in addition to existing visible features and uses of a closed source project, the status, pace and direction of ongoing development are clearly visible in an open source project.

Because of their flexibility and unstructured nature, informal techniques can be created and applied to both technical and non-technical aspects of software development and reuse. An informal evaluation may include a preliminary evaluation of required features, a cursory review of existing users and an examination of the project management. However, they cannot reliably be applied to different projects precisely because they are informal, that is they lack defined and repeatable evaluation processes. Their usefulness is therefore limited to narrowing down a large number of candidates to a smaller, more manageable set of candidates that can then be formally evaluated.

Formal techniques

There are many formal techniques for measuring the effectiveness of software development teams and processes. Some are well established, such as the Capability Maturity Model. Others, such as the Reuse Readiness Rating, are less well established but are nevertheless employed in significant organisations. Yet more are even less established but still provide useful background work for a Software Sustainability Maturity Model. The sections below briefly outline some of the formal evaluation techniques used in this work.

Capability Maturity Model

The Capability Maturity Model (CMM) was introduced in the early 1980s. It provides a set of assessment models that are used to determine an organisation’s ability to deliver a given piece of software, on time and with an acceptable level of quality. The most common examples are CMMI-DEV (Capability Maturity Model Integration for Development) and SPICE (Software Process Improvement and Capability dEtermintation, otherwise known as ISO 15504). In order to apply these models, one requires access to the development team. At first sight, this makes them ideal for applying to both open source and closed source projects.

However, the CMM cannot be directly applied to open source project communities, as it assumes a bounded organisational structure. Nevertheless, since a well-run open source project will have defined processes and structures in place, there is no reason why the concepts found in these models cannot be adapted in order to apply them to open source projects.

Reuse readiness rating

The NASA Earth Science Data Systems (ESDS) Software Reuse Working Group (WG) is developing Reuse Readiness Rating as a model for measuring and evaluating the reusability of software components and systems. The Reuse Readiness Rating is designed to allow evaluation of any software component, regardless of the development methodology of that component.

When reusing software components without modification, evaluation using these levels is sufficient in most cases. However, if we intend to make adaptations to the software we are reusing we also need an evaluation of the development methodology and project management. The Reuse Readiness Levels do not provide a mechanism for such an evaluation, but do provide a framework for the technical evaluation of the components in question.

Open source evaluation models

There are a number of models for the evaluation of open source software, including the Open Source Maturity Model by Capgemini and another of the same name by Navica, the Business Readiness Rating and Qualification and Selection of Open Source software (QSOS). Each of these models attempts to provide a means of evaluating the non-technical aspects of an open source software project, what some would call the ‘openness’ of their development model. That is, they are used to help guide the evaluation of the project as a sum of both its outputs and its development team (or community in the case of open source).

These approaches are useful in that they highlight the importance of considering community health when selecting open source products. However, they cannot easily be applied to closed source projects where the required visibility into the project development team is usually not present. For example, it is impossible to evaluate the effectiveness of issue-tracking and release-planning without access to the projects issue tracker. This is not a failing of the evaluation models, but a result of the lack of transparent information about the development of most closed source products.

Openness Rating

OSS Watch, in partnership with Pia Waugh, have developed an ‘openness rating’. This is a series of questions designed to guide evaluation of a projects structure with respect to the management of intellectual property, standards adoption, knowledge management, project management, and market opportunities. Unlike earlier models designed to evaluate open source projects, this model can be applied to both open and closed source software products.

The openness rating allows one to identify strong and weak points in a project’s management structure with respect to enabling third party collaboration and reuse of outputs. This enables project managers to identify areas that may be unintentionally limiting collaboration opportunities. Similarly, the rating allows third parties to understand what barriers exist with respect to making local modifications to a third party’s software outputs. By using this tool both parties can more effectively plan their allocation of resources in line with their needs.

Automated techniques

A number of techniques for the automatic measurement of software quality and community development models have also been explored. This is, perhaps, one of the most contentious areas of software evaluation. Automated tools tend to deliver a high level summary that obscures the details underneath. For this reason some people feel that they are not an effective measure of sustainability. Nevertheless, it would be a mistake to ignore all automated approaches without considering where they might add value.

Automated community evaluation

Community evaluation techniques tend to measure activity on issue trackers, bug trackers, mailing lists and version control. They provide some indication of community activity and therefore, according to their proponents, a measure of community health. However, measuring community health using quantitative techniques is, for many people, flawed.

Quantitative measures, such as the a number of emails sent or commits made, make no reference to the value of those activities. For example, a single email that prevents a major error in design is far more important with respect to sustainability of the software than multiple emails discussing the colour of a button in the user interface. Quantitative techniques are unable to make this distinction.

The limitations of quantitative evaluation of open source communities make automated techniques an interesting topic for academic study. However, at present they are of limited value when measuring sustainability. However, with careful use, they may act as indicators of areas requiring a more detailed examination or of general trends within the community.

Automated software quality evaluation

The automated evaluation of software quality is more mature than that of community development models and therefore provides more valuable measures. Typically, tools will seek to measure such factors as consistency, testability, and security. In many projects it is considered good practice to integrate some of these types of tools within the development process.

There are many examples of automated code analysis tools. These tools when used correctly, can provide valuable information about specific aspects of code quality and management.

Software Sustainability Maturity Model (SSMM)

In order to define a maturity model for software sustainability, we have drawn inspiration from each of the evaluation techniques described above. In some cases (Reusability Readiness Levels and Capability Maturity Model), we have extended rather than adapted the model. We describe the key attributes found at each level, but do not detail the properties and features required to progress from one level to the next. Before examining these key attributes, let’s define each of the nine levels in the model. In naming each of these levels we have taken inspiration from the life cycle of a pear tree:

seed

The project is little more than an idea and a blank canvas. At this stage, nobody but the project owner(s) and their immediate environment can have any direct influence over the final outcome.

germination

The project is starting to take shape, but it is still little more than a proposal. The project owner(s) have not started to communicate the project’s objectives in any meaningful way.

seedling

There is an early-stage implementation of the solution at this point. However, without the commitment of the project owner(s) the project is highly unlikley to survive. Project owner(s) do not, in general, seek external input other than through contracted help, although they do make the source code available for reuse.

juvenile

The project is starting to take on a life of its own, although it is still mostly guided by the project owner(s). Some aspects of project design can now be led by someone other than the initial project owner(s), although the original project owner(s) are still critical to project development since they are the ‘gatekeepers’ to the project.

flowering

The project is able to function independently within a narrowly defined set of criteria. External influences are starting to have a significant effect on the future of the project and thus a community of peers is building around the project.

pollination

The project and its related community are no longer controlled by the original project owner(s). It is possible that the project would continue if the project owner(s) were to withdraw entirely. The project owner(s) themselves recognise this and are ensuring that mechanisms are in place to allow the community to guide the project towards full sustainability.

fruiting

The community is self-organising and fulfilling important roles in the project management structure. The project leader is still vital to the survival of the project, but there are candidates that might be able to fill their role, given a managed transition.

ripening

The project has broken free of the original project owner(s) and can survive independently. The community and the project that the community works with are now able to make decisions for the benefit of all peers, rather than for any subset of community members.

dispersal

The project is satisfying the needs of a diverse set of users and contributors and would almost certainly survive the departure of the current project lead.

The table below outlines the key features of each of these levels and maps them to the relevant Capability Maturity Model and Reuse Readiness Levels. Each SSMM level incorporates the requirements of both the CMM and RRLs, in addition to the further requirements outlined in this table. Note that the requirements to reach a level are the minimum, not the maximum. For example, software code may be available under an open source licence prior to level 5, but in order to reach level 5 this must be the case.

Table 1. Draft Software Sustainability Maturity Model

SSMM Level	SSMM Title	Openness Summary	Reuse Readiness Level	Capability Maturity Model Level
0	Seed	No source code available under an OSI licence.	1 - No reusability; the software is not reusable.	0 - Incomplete
1	Germination	Either no source code available or unverifiable source code; there is no IP management process allowing for third party contributions.	2 - Initial reusability; software reuse is not practical.	1 - Competent people and heroics
2	Seedling	Verifiable source code is available in a public version control system with traceable IP ownership and licensing.	3 - Basic reusability; the software might be reusable by skilled users at substantial effort, cost and risk.	2 - Basic project management
3	Juvenile	Project owner(s) have a mechansim for engaging with and understanding third party interest in the project; the project has a responsive mail address.	4 - Reuse is possible; the software might be reused by most users with some effort, cost and risk.
4	Flowering	Third parties are able to examine, understand and influence the future of the project; the project has a public issue tracker, informational web site and mailing list, all of which are used to manage the project.	5 - Reuse is practical; the software could be reused by most users with reasonable cost and risk.	3 - Process standardisation
5	Pollination	Third parties are willing and able to take responsibility for key apects of project development; the issue tracker and mailing list are active and responsive to third party requests; source code is released under an OSI approved licence.	6 - Software is reusable; the software can be reused by most users although there may be some cost and risk.
6	Fruiting	Software is managed in such a way as to ensure that one person's changes do not break another's reuse; code has sufficient unit tests and release management processes to ensure that releases are of a resonably consistent quality.	7 - Software is highly reusable; the software can be reused by most users with minimum cost and risk.	4 - Quantitative management
7	Ripening	Roles within the project are clearly defined and key management tasks are handled by more than one community member; decision-making and conflict resolution processes are defined in a governance document and followed.	8 - Demonstrated reusability; the software has been reused by multiple users.
8	Dispersal	The project is able to maintain its own momentum independently of any one participant in the community; a governance model is adhered to and modified in response to emerging challenges; no single project participant has control over the project and thus newcomers are able to gain influence.	9 - Proven reusability; the software is being reused by many classes of users over a wide range of systems.	5 - Continuous process improvement

Conclusion

This proposal for a Software Sustainability Maturity Model demonstrates how a new openness rating2 can be combined with existing models used to evaluate various aspects of software development processes and their outputs.

We argue that by evaluating a project in terms of three elements of sustainability - openness, reusability and capability - it is possible to highlight opportunities for improvement in open innovation, product design and process maturity. This in turn will allow project managers seeking to reuse or further develop software outputs, to allocate resources in the most appropriate way for their project’s needs.

If you would like to apply the openness rating to your own project, please contact us.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com