TÓM TẮT LUẬN VĂN Mục tiêu chính của luận văn là tìm ra đáp án cho câu hỏi các phương thức đo lường phần mềm có thể được kết hợp trong quá trình phát triển phần mềm theo phương thức Agile
CƠ SỞ LÝ THUYẾT
Lợi ích của đo lường phần mềm
Sự đo lường được giới thiệu bởi các tổ chức công nghệ thông tin để hiểu rõ hơn, đánh giá, kiểm soát và dự đoán việc ra quyết định và quy trình phần mềm Có nhiều công dụng thiết thực của thang đo phần mềm Bốn trong số chúng gồm:
Dự toán dự án và theo dõi tiến độ:
Hiện tại, có rất nhiều công việc dự toán, với thành công hạn chế Ngày nay, ngành công nghiệp phần mềm nhận biết rằng có rất nhiều khía cạnh của phát triển phần mềm ảnh hưởng đến sự dự toán Nhấn mạnh về cải tiến quy trình cho chúng ta một số điểm cần quan tâm ở đây, các ước lượng không chính xác là kết quả của thời gian chu trình phát triển dài và sự biến đổi của quy trình Điều đó không bất thường đối với các dự án yêu cầu phải thay đổi sau khi ra đời Các nhà quản lý phải có trách nhiệm đặt hệ thống thích hợp đúng nơi để đo lường tiến độ dự án Họ cần phải sử dụng dữ liệu từ các dự án trước đó để ước lượng dự án và hiệu quả xử lý một cách tiến độ quá trình và yêu cầu thay đổi Đánh giá hoạt động của sản phẩm:
Phân tích code là vùng lớn nhất của nghiên cứu số liệu phần mềm Mọi sự phát triển phần mềm kết quả cuối cùng có bước tiến của code Code được thể hiện bằng một ngôn ngữ chuẩn trong lập trình có thể được xử lý tự động Mỗi ngôn ngữ cũng được xác định, và code là hình thức hoàn toàn của các kết quả mong muốn Điều này làm cho các sản phẩm cuối cùng - code - một phương tiện thuận lợi để áp dụng số liệu phần mềm
Quá trình cải thiện thông qua phân tích chất lượng phần mềm:
Chất lượng phần mềm là một trong những hứa hẹn và mở rộng nhất trong quá trình phát triển phần mềm ngày nay Phân tích defect, theo dõi và loại bỏ cung cấp một tiềm năng lớn cho các công ty phải cắt giảm chi phí phát triển và chi phí bảo trì của họ Chất lượng phần mềm bao gồm một loạt các thuộc tính: tính toàn vẹn, tính
18 tương hợp, linh hoạt, bảo trì, tính di động, tính mở rộng, tái sử dụng, khả năng đàn hồi và khả năng sử dụng Những thuộc tính này nên được lưu ý khi thiết kế và thực hiện các quy trình phát triển phần mềm Sau đó, thành tích đạt được có thể được xác nhận sử dụng số liệu phân tích lỗi và kiểm tra đảm bảo chất lượng
Xác nhận kinh nghiệm của các mẫu tốt nhất trong phát triển phần mềm
Công nghệ phần mềm là một lĩnh vực thay đổi nhanh chóng Điều đó rất quan trọng cho các công ty để tiếp tục sử dụng số liệu đo lường để kiểm tra các yêu cầu đôi khi không thực tế được thực hiện cho các phương pháp phát triển phần mềm mới và các công cụ trong công nghệ phần mềm.
Tổng quan ISO 9126
Mô hình chất lượng ISO-9126 [10] trên thực tế được mô tả là một phương pháp phân loại và chia nhỏ những thuộc tính chất lượng, nhằm tạo nên những đại lượng đo đếm được dùng để kiểm định chất lượng của sản phẩm phần mềm Ở mô hình chất lượng trong và chất lượng ngoài của sản phẩm trong ISO/IEC 9126
Tại mỗi đặc tính chất lượng, đặc tính chất lượng con của phần mềm đều được định nghĩa Với mỗi đặc tính và các đặc tính con, khả năng của phần mềm được xác định bằng tập các thuộc tính trong có thể đo đạc được Các đặc tính và các đặc tính con cũng có thể đo lường trong phạm vi khả năng của hệ thống chứa phần mềm
Tính chức năng: Khả năng của phần mềm cung cấp các chức năng đáp ứng được nhu cầu sử dụng khi phần mềm làm việc trong điều kiện cụ thể
Sự phù hợp: là khả năng của một phần mềm có thể cung cấp một tập các chức năng thích hợp cho công việc cụ thể phục vụ mục đích của người sử dụng
Độ chính xác: là khả năng của phần mềm có thể cung cấp các kết quả hay hiệu quả đúng đắn hoặc chấp nhận được với độ chính xác cần thiết
Khả năng tương tác: với một hoặc một vài hệ thống cụ thể của phần mềm
Tính an toàn: khả năng bảo vệ thông tin và dữ liệu của sản phẩm phần mềm,sao cho những người, hệ thống không được phép thì không thể truy cập, đọc hay chỉnh sửa chúng
Tính tuân thủ chức năng: các phần mềm theo các chuẩn, quy ước, quy định
Tính tin cậy: Là khả năng của phần mềm có thể hoạt động ổn định trong những điều kiện cụ thể
Tính chính xác: khả năng tránh các kết quả sai
Khả năng chịu lỗi: khả năng của phần mềm hoạt động ổn định tại một mức độ cả trong trường hợp có lỗi xảy ra ở phần mềm hoặc có những vi phạm trong giao diện
Khả năng phục hồi: khả năng của phần mềm có thể tái thiết lại hoạt động tại một mức xác định và khôi phục lại những dữ liệu có liên quan trực tiếp đến lỗi
Tính tuân thủ tin cậy: phần mềm thoả mãn các chuẩn, quy ước, quy định
Tính khả dụng: Là khả năng của phần mềm có thể hiểu được, học được, sử dụng được và hấp dẫn người sử dụng trong từng trường hợp sử dụng cụ thể
Có thể hiểu được: người sử dụng có thể hiểu được xem phần mềm có hợp với họ không và và sử dụng chúng thế nào cho những công việc cụ thể
Có thể học được: người sử dụng có thể học các ứng dụng của phần mềm
Có thể sử dụng được: khả năng của phần mềm cho phép người sử dụng sử dụng và điều khiển nó
Tính hấp dẫn: khả năng hấp dẫn người sử dụng của phần mềm
Tính tuân thủ khả dụng: phần mềm thoả mãn các chuẩn, quy ước, quy định
Tính hiệu quả: Khả năng của phần mềm có thể hoạt động một cách hợp lý, tương ứng với lượng tài nguyên nó sử dụng, trong điều kiện cụ thể
Đáp ứng thời gian: khả năng của phần mềm có thể đưa ra trả lời, thời gian xử lý và một tốc độ thông lượng hợp lý khi thực hiện công việc của mình, dưới điều kiện làm việc xác định
Tận dụng tài nguyên: khả năng của phần mềm có thể sử dụng một số lượng, một loại tài nguyên hợp lý để thực hiện công việc trong những điều kiện cụ thể
Tính tuân thủ hiệu quả: thoả mãn các chuẩn, quy ước, quy định
Khả năng bảo hành, bảo trì: Khả năng của phần mềm có thể chỉnh sửa Việc chỉnh sửa bao gồm: sửa lại cho đúng, cải tiến và làm phần mềm thích nghi được với những thay đổi của môi trường, của yêu cầu và của chức năng xác định
Có thể phân tích được: phần mềm có thể được chẩn đoán để tìm những thiếu sót hay những nguyên nhân gây lỗi hoặc để xác định những phần cần sửa
Có thể thay đổi được: phần mềm có thể chấp nhận một số thay đổi cụ thể trong quá trình triển khai
Tính bền vững: khả năng tránh những tác động không mong muốn khi chỉnh sửa phần mềm
Có thể kiểm tra được: khả năng cho phép phần mềm chỉnh sửa có thể được đánh giá
Tổng quan Agile và Scrum
Agile là một nhóm các phương pháp và phương pháp luận phát triển phần mềm dựa trên các nguyên tắc phát triển phân đoạn lặp và tăng trưởng, theo đó nhu cầu và giải pháp tiến hóa thông qua sự hợp tác giữa các nhóm tự quản và liên chức năng Agile thường sử dụng cách lập kế hoạch thích ứng, việc phát triển và chuyển giao theo hướng tiến hóa; sử dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển
Nhờ tính linh hoạt, đa dạng và hiệu quả cao, các phương pháp Agile ngày càng trở thành sự lựa chọn hàng đầu của các khách hàng, nhà phát triển, các công ty phát triển phần mềm Theo khảo sát của hãng nghiên cứu thị trường Forrester, mức độ phổ biến của Agile hiện đang ở mức cao nhất, và gấp nhiều lần so với các phương pháp truyền thống như thác nước hay CMMI
Hình 2.1 Mức độ phổ biến của các phương pháp phát triển phần mềm
Khi nào sử dụng Agile:
Trong bài báo “Embrace Agile” đăng trên HBR[23], đồng tác giả Scrum, ông Jeff Sutherland cùng với giáo sư Takeuchi ở Đại học Harvard và Darrell K Rigby đã cung cấp một số lời khuyên hữu ích Các tác giả cho rằng Agile phù hợp khi:
- Nhu cầu khách hàng và yêu cầu về giải pháp thay đổi thường xuyên
- Cần cộng tác chặt chẽ với khách hàng và có thể cung cấp các phản hồi nhanh, khách hàng nắm rõ hơn về những gì họ mong muốn
- Vấn đề rất phức tạp, giải pháp không rõ từ đầu và phạm vi cũng không được xác định rõ
- Đặc tả sản phẩm có thể thay đổi, và những sáng tạo đột phá luôn được ưu tiên
- Việc phát triển tăng trưởng mang lại giá trị, và khách hàng có thể sử dụng ngay những giá trị này
- Công việc có thể bẻ nhỏ thành từng phần và có thể được thực thi trong những phân đoạn lặp ngắn
- Những thay đổi ở phút chót có thể quản lí được
23 - Những sai sót có thể mang lại những bài học chứ không mang đến những thảm họa
Agile có thể không phù hợp trong những điều kiện ngược lại:
- Điều kiện thị trường ổn định và có thể tiên lượng - Yêu cầu rất rõ ràng và luôn ổn định
- Khách hàng không thể cộng tác thường xuyên
- Công việc tương tự những gì đã làm trước đó, và giải pháp là rất rõ ràng Đặc tả chi tiết có thể làm ra với sự dự đoán rõ ràng và chính xác Vấn đề có thể giải quyết tuần tự qua từng bộ phận chức năng mà không gặp trở ngại nào
- Khách hàng không thể bắt đầu kiểm thử các phần sản phẩm cho tới khi sản phẩm hoàn chỉnh
- Thay đổi phút chót rất tốn kém, hoặc không thể - Sai sót trong thực thi có thể dẫn đến thảm họa không thể cứu vãn được
Trong bài báo “A Leader’s Framework for Decision Making”[24] trên HBR số Tháng 11 năm 2007, các tác giả Snowden và Boone trình bày một mô hình phân loại thế giới trong các vùng với các đặc điểm tương đối khác nhau với độ phức tạp tăng dần: Hiển nhiên (Obvious), Rắm rối (Complicated), Phức hợp (Complex) và Hỗn độn (Chaotic)
24 Tình huống Đặc điểm nhận dạng Vai trò người ra quyết định Hiển nhiên Các khuôn mẫu và sự kiện lặp đi lặp lại
Nhìn rõ mối quan hệ nhân- quả
Có một câu trả lời đúng đắn Mọi người biết rõ những cái đã biết
Quản lí theo thực tế
Phán đoán trước, phân loại sau, rồi phản hồi
Sử dụng quy trình đúng đắn Ủy quyền
Sử dụng kinh nghiệm tốt (best practice) Truyền đạt rõ ràng, trực tiếp Giao tiếp hai chiều có thể không cần thiết
Rắm rối Cần chuyên gia phân tích
Có thể nhận biết quan hệ nhân-quả nhưng không hiển nhiên đối với mọi người Có nhiều hơn một câu trả lời Mọi người biết là có những thứ chưa biết đến
Quản lí theo thực tế
Phán đoán trước, phân tích sau, rồi phản hồi
Thiết lập đội chuyên gia Lắng nghe các lời khuyên có phần khác biệt
Phức hợp Thay đổi liên tục và không thể tiên lượng Không có câu trả lời đúng đắn
Mọi người không biết những điều chưa biết
Rất nhiều ý tưởng đối nghịch nhau
Cần những tiếp cận sáng tạo Lãnh đạo dựa-trên-khuôn- mẫu (pattern-based leadership)
Thử nghiệm trước, phán đoán sau, rồi phản hồi
Tạo môi trường thử nghiệm cho phép các khuôn mẫu xuất hiện
Tăng mức độ tương tác và giao tiếp hai chiều
Dùng các phương pháp để tạo lập thật nhiều ý tưởng: thảo luận mở; tạo lập biên; khuyến khích các nhân tố thu hút; khuyến khích sự bất đồng quan điểm và sự đa dạng; quản lí các điều kiện ban đầu và giám sát để hình thành các khuôn mẫu
Hỗn độn Nhiễu loạn cao độ
Không rõ quan hệ nhân- quả, thậm chí không có điểm nào để tìm kiếm manh mối Không thể biết được điều gì Phải ra nhiều quyết định cấp tập mà không có thời gian để suy nghĩ
Lãnh đạo dựa-trên-khuôn- mẫu (pattern-based leadership)
Hành động trước, phán đoán sau, rồi phản hồi
Quan sát xem cái nào hiệu quả thay vì tìm kiếm câu hỏi đúng đắn
Hành động tắp lự để vãn hồi trật tự (mệnh lệnh và kiểm soát)
Truyền đạt rõ ràng, trực tiếp
Bảng 2.1 Nhận biết và ra quyết định phù hợp với độ phức tạp, theo Snowden và Boone
Như chúng ta thấy, Agile phù hợp hơn ở vùng Phức hợp, nơi có thể vận dụng cách thức thí nghiệm - phán đoán - phản hồi để ra quyết định, trao quyền tự quản cho nhóm, thiết lập các điều kiện ban đầu và luôn tìm kiếm các khuôn mẫu thích ứng có tính tối ưu nổi lên trong quá trình nhóm làm việc tự tổ chức Ở một mức độ nhất định, Agile có thể phù hợp ở vùng Rắm rối, nhưng nói chung, vùng Phức hợp là vùng dễ thấy tính tương thích nhiều nhất
Dựa trên Cynefin, chúng ta có cái nhìn rõ ràng hơn trong trường hợp nào thì Agile sẽ hiệu quả Tuy vậy, Cynefin vẫn chỉ là một công cụ mang tính kĩ thuật Và những lời khuyên ở bên trên cũng mang tính kĩ thuật Nó động đến câu hỏi “phải làm sao” khi ra quyết định Agile hay không Agile Nhưng việc ra các quyết định trong thực tế lại đòi hỏi chúng ta phải hỏi “tại sao”, “để làm gì” nhiều hơn Agile để làm gì?
Tức là hỏi cái mục đích của việc sử dụng Agile Xa hơn nữa, là hỏi cái triết lí kinh doanh của nhà lãnh đạo là gì Đặc trưng của Agile:
Có rất nhiều phương pháp Agile với các hướng tiếp cận rất khác nhau Bên cạnh các cách thức tổ chức công việc, thiết lập quy trình, các phương pháp Agile còn nghiên cứu và đưa vào sử dụng các công cụ và kĩ thuật đặc thù như công cụ tích hợp liên tục, kiểm thử đơn vị, mẫu thiết kế, tái cấu trúc, phát triển hướng kiểm thử (TDD), phát triển hướng hành vi (BDD), hay lập trình theo cặp v.v… để đảm bảo và gia tăng tính linh hoạt Tuy vậy các phương pháp này chia sẻ nhiều đặc trưng giống nhau như cộng tác nhóm chặt chẽ, tổ chức các nhóm tự quản, liên chức năng, tính đáp ứng cao trong suốt vòng đời của dự án
Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại Các phân đoạn (được gọi là Iteration hoặc Sprint) này thường có khung thời gian ngắn (từ một đến bốn tuần) Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử (với các mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm Các phương pháp Agile
26 thường phân rã mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và không thực hiện việc lập kế hoạch dài hạn Có phương pháp như Scrum thậm chí sử dụng phương pháp lập kế hoạch “just-in-time” trong quá trình phát triển Khi đó, thậm chí công việc lập kế hoạch, làm mịn kế hoạch được thực hiện liên tục trong suốt quá trình làm việc
Hình 2.3 Các phân đoạn lặp đi lặp lại trong Agile
Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng Các phần nhỏ này thường là đầy đủ, có khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử dụng ngay Theo thời gian, phân đoạn này tiếp nối phân đoạn kia, các phần chạy được này sẽ được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn Khác với mô hình phát triển Thác nước – vốn chỉ cho phép nhìn thấy toàn bộ các chức năng tại thời điểm kết thúc dự án, sản phẩm trong các dự án Agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt được trạng thái đủ để phát hành
PHƯƠNG THỨC XÂY DỰNG MÔ HÌNH ĐO LƯỜNG PHẦN MỀM
Điều kiện tiên quyết của thang đo phần mềm
Sự lựa chọn và kết hợp của số liệu là việc làm rất quan trọng trong việc hỗ trợ việc ra quyết định Có một số điều cần xem xét khi thiết lập một mô hình đo lường phần mềm Tham khảo bài viết của nhóm tác giả Eric Bouwers, Joost Visser và Arie van
Deursen về những cạm bẫy trong sử dụng các thang đo phần mềm [7] để chỉ ra những điều kiện cần có cho thang đo phần mềm Đầu tiên, tình trạng bong bóng thang đo (Metric in a Bubble) xảy ra khi chúng ta nhìn vào số liệu trong sự cô lập
Các số liệu trong cần phải được đặt trong một bối cảnh để lấy được thông tin hữu ích từ các dữ liệu thu thập được Bối cảnh đó có thể đạt được bằng cách liên hệ giá trị số liệu gần đây nhất của một sản phẩm phần mềm để các giá trị lịch sử của số liệu và phần mềm tương tự Sau đó chúng ta có thể xem các sản phẩm phần mềm được cải thiện hoặc giảm sút số liệu Trên cơ sở này sau đó bạn có thể xác định lý do có khả năng cho xu hướng này
Một cạm bẫy phổ biến khác theo Bouwers là cạm bẫy có tên “Treating the Metric”
Trong tình huống này, sự thay đổi trong hệ thống chỉ để nâng cao giá trị của một chỉ số, thay vì cố gắng để đạt được một mục tiêu cụ thể “Giá trị của các số liệu đã trở thành một mục tiêu trong chính nó, thay vì một phương tiện để đạt được một mục tiêu lớn hơn”[7] Để ngăn chặn sự thay đổi bất lợi như trong hành vi, điều quan trọng là những người tham gia xây dựng mô hình đo lường phần mềm phải hiểu các số liệu phần mềm liên quan đến các mục tiêu đo lường như thế nào Bằng cách này, người thực hiện có thể thấy sự liên quan của đo lường và họ có thể sử dụng kết quả
37 của phép đo phần mềm để điều chỉnh hành vi của mình vì lợi ích của tổ chức Hơn nữa, không chỉ là mối quan hệ giữa các số liệu và các mục tiêu đo lường nên được rõ ràng mà bản chất của mục tiêu cần được cung cấp trong việc lựa chọn số liệu
Ngược lại với quá ít số liệu là sự tắc nghẽn Nếu bao gồm quá nhiều số liệu trong mô hình đo lường của, chúng sẽ không thể đánh giá sự tiến bộ hướng tới mục tiêu đo lường chung Sự cải thiện của một số số liệu luôn luôn gây ra sự suy giảm trong một số số liệu Người thực hiện đo lường bắt đầu từ chối các số liệu và các mục tiêu của nó hoàn toàn vì anh ta không thể nhìn thấy làm thế nào để cải thiện chúng Điều này được gọi là “Metrics Galore” [7]
Tất cả các số liệu cho mô hình đo lường nên được lựa chọn theo tiêu chí dễ dàng trong việc thu thập và mức độ có hiệu lực Số liệu phải được thu thập tự động càng nhiều càng tốt Các tương tác thủ công là cần thiết để thu thập các thang đo cản trở thực hiện đo lường Ngoài ra, sự tham gia của các tương tác thủ công trong đo lường đe dọa tính hợp lệ của dữ liệu Tính hợp lệ của dữ liệu đo lường là quan trọng bởi vì dữ liệu sai hoặc không chính xác có thể dẫn đến cách hiểu sai và cuối cùng là quyết định sai lầm Do đó, sự không chắc chắn của một phép đo phải được xem xét khi giải thích kết quả của nó Các phép đo với một sự không chắc chắn rất cao phải được bỏ qua vì không có thông tin có giá trị có thể được bắt nguồn từ chúng Đối với mục đích hỗ trợ các cải tiến quy trình và các sản phẩm phát triển phần mềm, các số liệu nên cho phép phân tích gốc nguyên nhân [8] Nói cách khác, bằng cách nhìn vào các thang đo, chúng là một phần của quá trình hay sản phẩm gây ra một vấn đề liên quan đến việc đạt được các mục tiêu đo lường.
Phương pháp tiếp cận để xác định một mô hình đo lường phần mềm
Phương pháp Goal Question Metric (GQM) được xác định bởi Basili [10] được sử dụng trong nghiên cứu này để xác định mô hình đo lường và được xem như là một khuôn khổ giải thích cho việc đánh giá hiệu suất Ưu điểm của việc sử dụng phương pháp tiếp cận GQM là tách mối quan tâm tổ chức (mục tiêu) thành những quan tâm quá trình cụ thể (câu hỏi) Nó cung cấp một cơ sở cho việc quyết định những dữ liệu cần được thu thập và gợi ý rằng dữ liệu thu thập phải được phân tích theo những
38 cách khác nhau, tùy thuộc vào câu hỏi nhằm mục đích trả lời GQM được phát triển chủ yếu để đáp ứng nhu cầu của các phương pháp tiếp cận mục tiêu theo định hướng đã nêu sẽ rất hữu ích trong việc đo lường quá trình và sản phẩm trong dòng công nghệ phần mềm Thực hiện theo phương thức GQM bao gồm nhiều hoạt động:
- Xác định các mục tiêu: Dựa trên mô tả bối cảnh, mục tiêu cải thiện hoạt động tổ chức và các xếp hạng về tầm quan trọng của mục tiêu chiến lược của tổ chức
- Tạo các kế hoạch đo lường: Mỗi mục tiêu được xác định là một sự khởi đầu cho việc tạo ra kế hoạch GQM Mỗi mục tiêu sẽ liên kết với tập hợp các thang đo cần theo dõi để đạt được mục tiêu
- Thu thập và xác nhận dữ liệu: Mục tiêu chính của hoạt động này là thu thập dữ liệu sản phẩm phù hợp với mô hình GQM đã tạo và kế hoạch đo lường của nó
- Phân tích các dữ liệu: Thu thập số liệu được phân tích, để kiểm tra mức độ đạt được các mục tiêu khác nhau được lựa chọn ban đầu
- Đóng gói kinh nghiệm: Những kinh nghiệm đó có được là trong khi tiến hành các hoạt động đo lường được đóng gói Kinh nghiệm này có thể được tái sử dụng trong các dự án trong tương lai
Bên cạnh đó GQM cũng không tránh khỏi các nhược điểm:
- GQM trở nên khó khăn để áp dụng khi các tác động của phương pháp là không rõ ràng
- Một bất lợi bằng cách sử dụng phương pháp này là lựa chọn số liệu và các thuộc tính chất lượng là chủ yếu là chủ quan và một mặt có thể là để chọn dễ dàng hơn để đo lường
- Hướng dẫn chi tiết cho thành lập các chương trình GQM trong môi trường công nghiệp vẫn còn hạn chế
- GQM đã bị chỉ trích vì thiếu cấu trúc và hướng dẫn
Hình 3.1 Goal Question Metric Approach ( GQM)
Basili cho rằng “ một tổ chức muốn đo lường một cách có mục đích thì đầu tiên phải xác định mục tiêu cho bản thân và các dự án của mình, sau đó nó phải theo dõi những mục tiêu để các dữ liệu được dự định để xác định những mục tiêu hoạt động, và cung cấp một khuôn khổ cho việc giải thích các dữ liệu liên quan đến các mục tiêu đã nêu” [17] Cách tiếp cận GQM, được minh họa trong hình 3.1, xuất phát đo lường phần mềm từ mục tiêu hiệu suất cụ thể Những mục tiêu hiệu suất này cũng được gọi là mục tiêu đo lường Đối với mỗi mục tiêu đo lường, một hoặc nhiều câu hỏi được đặt ra đặc trưng cho cách mục tiêu có thể đạt được Để đánh giá những thành tựu hướng tới mục tiêu xác định, chúng ta cần phải trả lời những câu hỏi này Với mục đích này, đề tài chọn các số liệu cung cấp những thông tin cần thiết để trả lời các câu hỏi Nói cách khác, các số liệu định lượng là một yếu tố ảnh hưởng đến thành tích hiệu suất hướng tới mục tiêu đo lường.
Kết nối giữa mục tiêu kinh doanh với mục tiêu đo lường
Trong một môi trường Agile, rất nhiều quyết định được giao cho các nhóm phát triển tự tổ chức Đội phát triển cần thông tin đo lường phần mềm như một hỗ trợ để
40 hoạt động Ở cấp độ tổ chức các nhóm phát triển đang phải đối mặt với quy hoạch, đánh giá tiến độ và phản hồi của sự tương tác
Do đó, để có thể xác định mục tiêu và đo lường các chỉ số cho các cấp độ hoạt động, chúng ta cần phải phân tích cách phát triển phần mềm góp phần vào việc tạo ra giá trị kinh doanh
Giá trị doanh nghiệp là một thuật ngữ không chính thức Giá trị của một doanh nghiệp không chỉ xác định bằng tài sản hữu hình mà còn bởi tài sản vô hình
Highsmith cho rằng “những tài sản vô hình rất quan trọng cho sự thành công lâu dài của công ty, tài sản vô hình rất quan trọng cho sự thành công lâu dài, và khả năng tận dụng các cơ hội là một khả năng vô hình quan trọng đối với hầu hết các công ty”[12] Khả năng cơ hội được kết nối với sự nhanh nhẹn từ một điểm nhìn của phát triển phần mềm Sự nhanh nhẹn được xác định bởi Highsmith như khả năng tạo và ứng phó với thay đổi để phát triển trong một môi trường kinh doanh đầy biến động
Do đó, sự nhanh nhẹn là chìa khóa để thành công trong kinh doanh Mô hình chất lượng phần mềm tập trung vào thành phần vô hình của giá trị kinh doanh
Chappell nhận thấy chất lượng phần mềm như là một đóng góp vô hình quan trọng đối với các giá trị kinh doanh: “Mỗi tổ chức xây dựng phần mềm tùy chỉnh cho cùng một lý do: để tạo ra giá trị kinh doanh Một phần quan trọng của giá trị đó bắt nguồn từ chất lượng của phần mềm”[5] Hậu quả của chất lượng phần mềm thấp theo thời gian là làm tắc nghẽn hoạt động của doanh nghiệp Theo Chappell chất lượng phần mềm thấp sẽ dẫn đến việc thất thoát tài chính từ kinh doanh, thất thoát tài chính từ bồi thường khách hàng, thất thoát tài chính từ các khách hàng, thất thoát tài chính của quỹ từ các vụ kiện và vốn chủ sở hữu thương hiệu cuối cùng thấp hơn [5]
Do đó, để đảm bảo rằng việc phát triển phần mềm thêm vào việc tạo ra giá trị kinh doanh, cần phải đánh giá và nâng cao chất lượng phần mềm Đối với mục đích này, cần phải phá vỡ các khía cạnh chất lượng phần mềm thành các thành phần đo lường được Chappell cụ thể hóa một số nhân tố ảnh hưởng đến các khía cạnh chất lượng phần mềm như sau (xem Bảng 3.1)
Bảng 3.1 Các yếu tố ảnh hưởng đến chất lượng phần mềm (Chappell)
Chất lượng chức năng thỏa thuận với các yếu tố đặc biệt quan trọng cho các bên liên quan với một cách nhìn khách quan về sự phát triển phần mềm Các bên liên quan với một cách nhìn khách quan đánh giá giá trị của một sản phẩm phần mềm cùng các thuộc tính chất lượng chức năng Ví dụ, một người sử dụng phân tích nếu một sản phẩm phần mềm cung cấp các chức năng mà họ cần Nếu chức năng không tuân thủ các yêu cầu của người sử dụng, giá trị của các phần mềm bị giảm bớt Do đó, chất lượng chức năng ảnh hưởng đến việc thông qua hoặc từ chối bởi người sử dụng
42 Chất lượng quy trình đề cập đến tình trạng của quá trình phát triển Kế hoạch phù hợp với kế hoạch phát hành và ngân sách là chất lượng của quá trình phát triển phần mềm
Chất lượng cấu trúc là một quan điểm nội bộ về chất lượng của một sản phẩm phần mềm Có liên quan để việc kiểm thử hoặc bảo trì bên trong của mã nguồn các sản phẩm phần mềm Mặc dù chất lượng cấu trúc là một điểm bên trong, nó vẫn được nhìn nhận ở bên ngoài Cấu trúc không tốt có thể gây ra nhiều lỗi hơn trong các sản phẩm phần mềm hoặc thời gian phát triển dài hơn thời gian chờ đợi cho các cải tiến vì khó để thực hiện thay đổi trong mã nguồn của một sản phẩm phần mềm Do đó, chất lượng cấu trúc có ảnh hưởng lớn đến chức năng và quy trình chất lượng
Highsmith đề cập đến yếu tố tương tự ở Tam giác Agile mình mà đóng góp với giá trị kinh doanh và xác định sự thành công của phát triển phần mềm [11]
Các tam giác nhanh nhẹn trong hình 3.2 có 3 chiều là kích thước giá trị, chất lượng và hạn chế Các mục tiêu của phát triển phần mềm linh hoạt được định nghĩa theo ba chiều kích này Highsmith cho rằng mục tiêu của phát triển phần mềm là “giá trị sản phẩm mang tới sự hài lòng cho khách hàng, xây dựng chất lượng mà quá trình phát triển nhanh chóng, tạo ra một nền tảng khả thi cho các cải tiến trong tương lai, và cung cấp trong phạm vi hạn chế (trong đó có phạm vi, tiến độ và chi phí) "[11] các tam giác Agile đặc biệt nhấn mạnh tầm quan trọng của việc tạo ra các giá trị trong các hình thức của sản phẩm phần mềm được phát hành
Hình 3.2 Tam giác Agile (Highsmith 2010)
Theo lý luận của Highsmith và Chappell, có thể kết luận rằng phầm mềm với chất lượng cao tập trung mạnh vào việc tạo ra các giá trị trong hình thức làm việc của phần mềm là rất quan trọng để đảm bảo phát triển phần mềm là góp phần tạo ra giá trị kinh doanh Nói cách khác, chất lượng phần mềm là tạo khả năng chủ chốt để khả năng tạo và ứng phó với thay đổi để phát triển
MÔ HÌNH CHẤT LƯỢNG PHẦN MỀM TRONG MÔI TRƯỜNG AGILE
Xác định mô hình
Cách tiếp cận GQM, được mô tả trong Phần 3.2, được áp dụng để xác định mô hình đánh giá chất lượng phần mềm Trong Bảng 4.1 là mục tiêu chính của phát triển phần mềm theo phương thức Agile được thể hiện bằng cách sử dụng GQM để định nghĩa mẫu [17]
Phân tích Phát triển phần mềm
Với mục đích Đánh giá và cải thiện hiệu suất
Về khía cạnh Chất lượng phần mềm
Từ tầm nhìn của Giám đốc, Chủ sản phẩm, Scrum Master và nhóm phát triển
Ngữ cảnh Phương thức Agile trong môi trường Scrum
Bảng 4.1 Mục tiêu chính của phát triển phần mềm
Các phân tích trong phần trước đã được đặc trưng trong ba khía cạnh đó góp phần vào chất lượng phần mềm Hình 4.1 mô tả lược đồ GQM với cải thiện chất lượng phần mềm là mục tiêu chính và phân chia thành các mục tiêu con là cải thiện chất lượng chức năng, cải thiện chất lượng kết cấu và cải thiện chất lượng quy trình cũng như các câu hỏi và số đo được phân chia từ các mục tiêu con
Hình 4.1 Ứng dụng của phương thức GQM để định nghĩa mô hình đo lường chất lượng phần mềm
Những bên liên quan khác nhau trong các bộ phận sản xuất theo quy trình Agile sẽ mang lại những quan tâm khác nhau trên đặc điểm của chất lượng phần mềm Ví dụ, một nhóm phát triển quan tâm nhất về chất lượng cấu trúc, trong khi chủ sở hữu quan tâm nhất về chất lượng chức năng Điều quan trọng cần lưu ý là một dự án phát triển phần mềm thường có thêm các bên liên quan bên ngoài, chẳng hạn như khách hàng hoặc người sử dụng, mà không được thể hiện trong các quan điểm của các mô hình Các bên liên quan được tách ra vì họ không sử dụng mô hình này, mặc dù điều quan trọng là phải kết hợp quan điểm của họ trong việc đưa ra quyết định
Các đặc điểm của chất lượng phần mềm phụ thuộc lẫn nhau Trong tình huống nhất định một quyết định để cải thiện về một đặc điểm có thể dẫn đến sự suy giảm tạm thời trong đặc điểm khác Ví dụ, quyết định tái cấu trúc mã nguồn để nâng cao chất lượng kết cấu của một sản phẩm phần mềm dẫn đến giảm số lượng các tính năng trong giai đoạn này Trong môi trường phát triển Agile, đội ngũ phát triển cần phải
46 làm cho những quyết định thương mại nằm trong sự cộng tác với chủ sở hữu sản phẩm Mô hình chất lượng phần mềm cho phép đánh giá tình trạng của chất lượng phần mềm để từ đó phán đoán tầm ảnh hưởng của quyết định
Các đặc tính chất lượng chức năng và chất lượng cấu trúc được xác định bởi Chappell cũng có thể được tìm thấy trong tiêu chuẩn ISO/IEC 25010, thể hiện trong hình 4.2 Chất lượng chức năng và chất lượng kết cấu của Chappell ánh xạ với chức năng phù hợp và bảo trì tương ứng Sự phù hợp chức năng được định nghĩa là
“mức độ mà một sản phẩm hoặc hệ thống cung cấp các chức năng thỏa mãn các quy định và ngụ ý nhu cầu khi sử dụng trong điều kiện cụ thể” [9] và bảo trì được định nghĩa là “mức độ hiệu quả và hiệu quả với một sản phẩm hoặc hệ thống có thể được thay đổi như các nhà bảo trì mong đợi”[9]
Hình 4.2: Mô hình chất lượng sản phẩm (ISO/IEC 25010)
Nguồn iso25000.com Điều quan trọng cần lưu ý là các đặc điểm khác trong mô hình chất lượng sản phẩm theo tiêu chuẩn ISO 2510, hiệu suất hiệu quả và khả năng sử dụng có giá trị Nhưng những đặc điểm được chọn là quan trọng nhất để đánh giá khi phát triển phần mềm là “tạo ra giá trị hài lòng cho khách hàng, xây dựng chất lượng tăng tốc quy trình phát triển, tạo ra một nền tảng khả thi cho các cải tiến trong tương lai, và cung cấp trong phạm vi hạn chế (trong đó có phạm vi, thời hạn, và chi phí )”[11] Một thực tế quan trọng là những đặc điểm được lựa chọn có thể được đánh giá trong một môi trường phát triển Agile Hầu hết các dữ liệu cho việc đánh giá đã tồn tại trong các công cụ phần mềm Các công cụ khác cần thiết cho việc phân tích khả năng bảo trì một sản phẩm phần mềm có thể được tích hợp trong quá trình xây dựng của một sản
47 phẩm phần mềm Nếu yêu cầu đặc biệt tồn tại trong một dự án cần thêm các yêu cầu đặc biệt như hiệu năng, mô hình có thể được mở rộng để chứa các yêu cầu này
Cách tiếp cận GQM đề xuất để lấy được các số liệu của một phép đo từ mục tiêu của chương trình đo lường Mục đích chính là để đánh giá chất lượng phần mềm
Các đặc tính chất lượng phần mềm, chất lượng chức năng, chất lượng kết cấu và chất lượng quy trình là cơ sở cho các mô hình đo lường
Chất lượng chức năng của một phần mềm giao dịch với chất lượng cảm nhận bên ngoài của một phần mềm Chất lượng chức năng càng cao cấp thì giá trị mà người dùng nhận được càng lớn từ việc sử dụng một sản phẩm phần mềm Các giá trị mà khách hàng nhận được từ các sản phẩm phần mềm xác định nếu một cá nhân hay công ty quyết định sử dụng một sản phẩm hoặc dịch vụ nhất định và ký hợp đồng
Vì vậy, cần thiết để thúc đẩy một mức độ cao về chất lượng chức năng để đảm bảo việc bán các sản phẩm và dịch vụ
Chất lượng kết cấu, cũng được gọi là chất lượng kỹ thuật, của một phần mềm có liên quan đến cấu trúc mã nguồn của phần mềm Do đó, nó là một cái nhìn nội bộ về chất lượng của phần mềm Đặc biệt, các nhà phát triển phần mềm quan tâm về phần này của chất lượng phần mềm, vì chúng bị ảnh hưởng bởi các vấn đề về chất lượng thấp trong khía cạnh này [6]
Chất lượng quy trình xem xét các khía cạnh liên quan đến quá trình giao hàng Để đánh giá quá trình giao việc tuân thủ thời gian giao hàng và ngân sách được phân tích Chappell nhấn mạnh rằng không cần cung cấp đầy đủ các tính năng trong thời gian và ngân sách tại một thời điểm, nhưng cần phải luôn cung cấp những tính năng về thời gian và ngân sách Chất lượng quy trình cao hơn là khi cung cấp các tính năng trong thời gian và ngân sách.
Các câu hỏi được xây dựng dựa trên tiếp cận mô hình GQM
48 Câu hỏi liên quan đến chất lượng chức năng Để đánh giá các mục tiêu chất lượng chức năng, luận văn sử dụng các yếu tố về chất lượng chức năng đã được xác định bởi Chappell Chương trước đã trình bày về ảnh hưởng tắc nghẽn của Metrics Galore Tình trạng này xảy ra khi một số lượng lớn các số liệu lấn át các bên liên quan của một mô hình đo lường Những yếu tố liên quan đến phụ đặc điểm của sự phù hợp chức năng trong ISO 25010, hiển thị trong danh sách sau đây:
Chức năng đầy đủ: “Mức độ mà tập các chức năng bao gồm tất cả các nhiệm vụ cụ thể và mục tiêu người dùng” [9]
Chức năng đúng đắn: “Mức độ mà một sản phẩm hoặc hệ thống cung cấp kết quả chính xác với mức độ cần thiết của độ chính xác” [9]
Việc đánh giá nếu yêu cầu được đáp ứng là kết nối với đầy đủ chức năng Các yếu tố xem các sản phẩm phần mềm có vài khiếm khuyết là ràng buộc về tính chính xác chức năng Như đã đề cập trước đó, các mô hình có thể được mở rộng với các câu hỏi và các số liệu liên quan đến yếu tố chất lượng chức năng khác như hiệu suất đủ tốt, dễ học và dễ sử dụng Hai yếu tố này cuối cùng cũng là một phần của tiêu chuẩn ISO 25010 Chúng tạo hiệu quả đặc điểm hiệu suất rời rạc và tính khả dụng Các câu hỏi xuất phát từ mục tiêu chất lượng chức năng như sau:
Q1.1 Bao nhiêu yêu cầu người dùng đã được hoàn thành trong Sprint?
Bối cảnh: Yêu cầu người dùng càng nhiều thì chức năng càng phải đầy đủ
Lợi ích mà người dùng nhận được từ việc sử dụng các phần mềm, tăng cùng với mức độ đầy đủ chức năng của phần mềm Các tỷ lệ phân phối các yêu cầu sử dụng được coi là năng suất của quá trình phát triển phần mềm
Thang đo: Tỷ lệ yêu cầu được hoàn thành - Requirement Released Rate
Giải thích: Số lượng yêu cầu người dùng được thực hiện và phân phối càng cao, yêu cầu chất lượng chức năng càng cao
Q1.2 Có bao nhiêu bug được loại trừ trong một sprint?
Bối cảnh: Một bug (hay defect) là một lỗi xảy ra trong quá trình thực hiện chức năng của một phần mềm Tất cả các lỗi trong một phần mềm làm giảm tính chính xác chức năng của phần mềm đó Các lợi ích mà người dùng nhận được từ việc sử dụng các phần mềm liên quan chặt chẽ đến sự đúng đắn chức năng của phần mềm [5] Do đó, điều quan trọng là nỗ lực đóng góp để loại bỏ bug ra khỏi phần mềm
Thang đo: Defect Removal Rate
Giải thích: Càng nhiều lỗi được sửa chữa càng nâng cao chất lượng chức năng
Q1.3 Kiểm soát lỗi phát sinh được sửa chữa trước khi giao hàng như thế nào?
Bối cảnh: Phát triển phần mềm được thực hiện bởi nhân viên tri thức và không máy móc Mặc dù các nhà phát triển không có ý để phát sinh lỗi trong sản phẩm của mình nhưng chắc chắn đó là điều không thể tránh khỏi Như đã đề cập trước đó, các chức năng đúng đắn và lợi ích mà người dùng nhận được từ một phần mềm là có liên quan đến số lượng các lỗi trong phần mềm
Vì vậy, điều quan trọng là trong quá trình hoạt động đảm bảo chất lượng là xác định và sửa chữa các lỗi trước khi phần mềm được phân phối
Thang đo: Defect Removal Effeciency
Giải thích: Số lượng lỗi được phát hiện và sửa chữa trước khi giao phần mềm càng cao, các cải tiến về chất lượng chức năng càng cao
Q1.4 Có bao nhiêu bug bị thoát ra sau mỗi sprint?
Bối cảnh: Cần hạn chế tối đa các lỗi bị thoát ra sau mỗi sprint, đặc biệt là các lỗi nghiêm trọng ảnh hưởng đến chức năng chính của sản phẩm
Thang đo: Tỷ lệ lỗi bị thoát ra - Escaped Defect Rate
Giải thích: Càng ít lỗi bị thoát ra, chất lượng chức năng càng cao
Câu hỏi liên quan đến chất lượng kết cấu:
50 Theo Chappell, chất lượng kết cấu liên quan đến cấu trúc bên trong của một phần mềm Để đánh giá chất lượng cấu trúc, chúng tôi phân tích khả năng bảo trì của mã nguồn của phần mềm Trong ISO 25010 khả năng duy trì được định nghĩa là "mức độ ảnh hưởng và ảnh hưởng của một sản phẩm hay hệ thống cần được thay đổi bởi dự định của người bảo trì" Khả năng bảo trì phần mềm ảnh hướng về các đặc điểm khác của chất lượng phần mềm ISO 25010 đưa ra danh sách một số đặc điểm góp phần bảo trì phần mềm Các đặc điểm chất lượng phần mềm khác gây ảnh hưởng lớn nhất bao gồm:
Khả năng phân tích - Analysability: “Mức độ ảnh hưởng và sự ảnh hưởng có thể đánh giá tác động đối với một sản phẩm hoặc hệ thống của một sự thay đổi có ý định cho một hoặc nhiều phần của sản phẩm, hoặc chẩn đoán một sản phẩm bằng thiếu sót hoặc nguyên nhân của thất bại , hoặc xác định bộ phận để sửa đổi”[9]
Khả năng biến đổi - Moditability: “Mức độ mà một sản phẩm hoặc hệ thống có thể vận hành một cách hiệu quả và tùy chỉnh hiệu quả mà không phát sinh defect hay làm suy giảm chất lượng sản phẩm hiện có” [9]
Khả năng kiểm thử - Testability: “mức độ hiệu quả và tính hiệu quả tiêu chí kiểm thử có thể được thiết lập cho một hệ thống, sản phẩm hoặc thành phần và kiểm tra có thể được thực hiện để xác định những tiêu chí đã được đáp ứng chưa” [9]
Chất lượng phần mềm sẽ tập trung vào analysability, modifiability và testability nhằm đánh giá khả năng bảo trì của phần mềm Các khía cạnh khác của bảo trì phần mềm bị loại ra để ngăn chặn tình huống bất lợi của Metrics Galore Nhưng đặc điểm bảo trì bổ sung có thể được thêm vào mô hình về sau nếu thích hợp
Các câu hỏi xuất phát từ mục tiêu chất lượng kết cấu như sau:
Q2 Cách bảo trì của sản phẩm phần mềm ra sao?
Bối cảnh: Nghiên cứu đã chỉ ra rằng khía cạnh bảo trì của chất lượng cấu trúc có một mối tương quan tích cực với thời gian giải quyết vấn đề [4] Phát hiện này liên quan đến việc thực hiện các tính năng mới, cũng như các lỗi hiện có Nói cách khác, khả năng bảo trì của một phần mềm càng cao, các vấn đề tồn đọng có thể được giải quyết nhanh hơn Từ thực tế này, có thể
51 thấy rằng chất lượng cấu trúc có ảnh hưởng lớn về chức năng và quy trình chất lượng
Thang đo: bảo trì phần mềm SIG
Giải thích: khả năng bảo trì của một phần mềm càng cao, chất lượng cấu trúc của phần mềm càng cao
Câu hỏi liên quan đến chất lượng quy trình
Thông thường, không có các kế hoạch về ngân sách cho tính năng cá nhân trên cấp độ sprint Tuy nhiên, các số liệu được xác định để truy xuất cuộc họp về ngày giao hàng, có thể được sử dụng để đánh giá hiệu quả của phát triển phần mềm liên quan đến các nỗ lực phát triển rộng Bằng cách cải thiện hiệu quả, nhiều tính năng có thể được thực hiện với cùng một nỗ lực của tất cả lập trình viên Một quá trình phát triển lặp lại đáng tin cậy cung cấp phần mềm có chất lượng sẽ phần nào được cung cấp bởi sự kết hợp và xây dựng các số liệu Đối với sự đảm bảo rằng quá trình phát triển luôn cung cấp những cải tiến phần mềm với chất lượng tốt, vai trò các thông tin thu được từ các mô hình được sử dụng để ra quyết định Nếu chú trọng vào việc tăng số lượng các tính năng được giao, có thể sẽ bỏ qua chất lượng cấu trúc của phần mềm Mặc dù có thể quan sát tỷ lệ cải thiện của các tính năng mới trong ngắn hạn nhưng khả năng để thích nghi với thay đổi môi trường trong dàihạn sẽ mất đi Khả năng bảo trì của một phần mềm có tương quan với các nỗ lực phát triển cần thiết để thay đổi một phần mềm [4] Do đó, điều quan trọng là phải nhận thức được những đánh đổi thực hiện theo các khía cạnh chất lượng phần mềm
Các câu hỏi xuất phát từ mục tiêu chất lượng quy trình như sau
Q3.1 Năng suất của quá trình phát triển phần mềm là gì?
Bối cảnh: Công suất được định nghĩa là “Tỷ lệ tối đa của đầu ra của một quá trình, được đo bằng đơn vị sản lượng trên một đơn vị thời gian” [22] Năng lực của một quá trình phát triển phần mềm liên quan đến tỷ lệ mà yêu cầu người dùng được thực hiện
Giải thích: Công suất của quy trình phát triển phần mềm càng cao, chất lượng quy trình càng cao
Q3.2 Thời gian tăng cường phát triển sản phẩm ra sao?
Xây dựng thang đo
Các thang đo đã được lựa chọn là các chỉ số về chất lượng phần mềm được định nghĩa và được mô tả trong phần sau
Tỷ lệ yêu cầu được hoàn thành - Requirement Released Rate
Requirement Released Rate là thang đo hiệu của quá trình từ đơn vị đầu vào đến đầu ra Đầu vào của quá trình là đơn vị xuyên suốt các quá trình trong một khoảng thời gian nhất định Trong phát triển phần mềm, yêu cầu người dùng được sử dụng làm đầu vào cho quá trình phát triển Một yêu cầu người dùng (ý tưởng) đi qua các giai đọan khác nhau của quá trình phát triển phần mềm, như mô tả trong hình 3.2
Các đầu ra của quá trình phát triển là việc chuyển đổi một yêu cầu người dùng thành hình thành mã nguồn Việc thực hiện một yêu cầu người sử dụng tạo thành một tính năng phần mềm Công thức tính năng suất xác định bởi John Kammelar như sau:
Requirement Released Rate: Tỷ lệ yêu cầu được hoàn thành
∑user stories released in sprint: Tổng yêu cầu người dùng hoàn thành trong sprint
∑user stories required in sprint: Tổng yêu cầu người dùng được yêu cầu hoàn thành trong sprint
Tỷ lệ loại bỏ lỗi: Defect Removal Rate
Những nhà phát triển phần mềm luôn cố gắng làm giảm số lượng lỗi trong phát triển nhưng họ không không thể hoàn toàn loại bỏ lỗi trong các sản phẩm phần mềm Lỗi xuất hiện trong một phần mềm làm giảm giá trị thu được từ việc sử dụng nó Do đó, điều quan trọng là loại bỏ càng nhiều lỗi càng tốt
Thang đo Defect Removal Rate được dùng để phân tích lượng lỗi phần mềm đã được gỡ bỏ thành công trong mỗi sprint Chỉ có lỗi đã được tìm thấy trước sprint được tính Dữ liệu tính toán được lấy từ hệ thống ghi nhận lỗi ITS Lỗi được đánh dấu trong hệ thống ITS với các vấn đề loại lỗi và lỗi được sửa tại sprint nào
Trên cơ sở các lỗi tìm thấy trước sprint, công thức cho tỷ lệ loại bỏ lỗi dựa theo tác giả Stephen H Kan [19] là:
Defect Removal Rate: Tỷ lệ loại bỏ lỗi
∑ Bugs found before sprint: Tổng số lỗi tìm thấy trước sprint
∑Working days in sprint to resolve bugs: Số ngày làm việc trong sprint để khắc phục lỗi
Escape Defect Rate: Tỷ lệ lỗi bị thoát ra
54 Trong quá trình phát triển, sự xuất hiện của các defect là điều không thể tránh khỏi
Tuy nhiên cần hạn chế tối đa việc bỏ sót lỗi trong quá trình phát triển đặc biệt là các lỗi nguy hiểm ảnh hưởng trực tiếp tới chức năng sản phẩm Tỷ lệ lỗi thoát ra được tính bằng công thức
Escape Defect Rate: Tỷ lệ lỗi bị thoát ra
∑Bugs found on stagging/production: Tổng số lỗi tìm thấy trên staging hay production
∑Bugs found: Tổng số lỗi tìm thấy
Hiệu suất loại bỏ lỗi - Defect Removal Effeciency
Hiệu suất loại bỏ lỗi - Defect Removal Effeciency (DRE) được đề xuất bởi Jones để đánh giá hiệu quả của các hoạt động đảm bảo chất lượng trong quá trình phát triển phần mềm Các số liệu DRE tính toán tỷ lệ phần trăm của các lỗi đã được tìm thấy và sửa chữa trong phát triển trước khi phần mềm được phân phối Jones cho rằng
“mức độ loại bỏ lỗi hiệu quả có ảnh hưởng lớn đến sự hài lòng của khách hàng”, mức độ cao của sự hài lòng của khách hàng tương quan mạnh với mức độ cao về hiệu quả lỗi được loại bỏ DRE được định nghĩa như sau:
Development defects là số lỗi được tìm thấy và sửa trong giai đoạn phát triển trước khi phần mềm được phân phối cho khách hàng và Total defect là là tổng số lượng của các lỗi phát sinh trong giai đoạn phát triển và số lượng các lỗi được tìm thấy bởi người dùng hoặc khách hàng sau khi phần mềm đã được chuyển giao
Giá trị Defect Removal Effeciency trong bài viết dựa trên công thức DRE của Jones So sánh với DRE, giá trị cần phân biệt trong bài là những lỗi được tìm thấy
55 trong quá trình phát triển từ những lỗi được tìm thấy sau khi giao sản phẩm Công thức tính được đề xuất như sau:
𝐷𝑅𝐸 =∑Bugs found and fixed in sprint
DRE: Hiệu suất loại bỏ lỗi
∑ Bugs found and fixed in sprint: Lỗi phát hiện và sửa chữa trong sprint
∑ Bugs at the moment: Tổng số lỗi tính tới thời điểm hiện tại
Hệ số thời gian phát triển - Enhancement Time Ratio
Sửa lỗi phần mềm là một hình thức bảo trì Như đã đề cập trong mô tả của các tỷ lệ loại bỏ lỗi, điều được mong đợi là giảm thiểu số lượng lỗi đến mức thấp nhất Hiển nhiên, khi tập trung vào việc sửa lỗi thì thời gian dành cho hoàn thành duy trì nâng cao sản phẩm Bijlsma đã đề xuất Enhancement Time Ratio để theo dõi sự cân bằng giữa bảo trì khắc phục và duy trì:
Với RE là số cải tiến trong một khoảng thời gian nhất định, và RD là số lỗi được giải quyết trong cùng khoảng thời gian [5] Dữ liệu tính toán có thể dễ dàng được lấy ra từ ITS trong sprint, đã làm cho chỉ số trước đó
Bijlsma khẳng định trong nghiên cứu của ông cho giả thuyết rằng "Các nhà phát triển hệ thống phần mềm với khả năng bảo trì cao hơn sẽ thực hiện nhiều cải tiến hơn so với các nhà phát triển có hệ thống bảo trì thấp hơn" [5]
Enhancement Time Ratio là một phần mở rộng của công thức gốc ở trên Trong tỷ lệ này chỉ có tóm tắt nhu cầu người dùng, công việc và lỗi phát sinh được đề cập
Các điều chỉnh cho phép chúng ta phân tích làm thế nào mở rông thời gian của lập trình viên trong suốt sprint Enhancement Time Ratio được tính như sau:
Enhancement Time Ratio: Hệ số thời gian phát triển Logged time on user stories in sprint: Thời gian thực hiện chức năng mới
Logged time on user stories, bugs and tasks: Tổng thời gian làm việc bao gồm cả thực hiện chức năng mới và thời gian sửa lỗi
Heitlager đã phát triển mô hình chất lượng SIG để đánh giá khả năng bảo trì của một sản phẩm phần mềm [8] Mô hình này sử dụng các định nghĩa của bảo trì trong các tiêu chuẩn ISO/IEC 9126 để gán một giá trị bảo trì đến sản phẩm phần mềm
Tổng quan về ứng dụng
Tác giả thực hiện ứng dụng theo yêu cầu trực tiếp của dự án X đang tham gia Dự án X là một dự án phát triển website thương mại điện tử theo phương thức Agile
Dự án được phân chia thành nhiều nhóm nhỏ thực hiện nhiều yêu cầu người dùng khác nhau trong cùng một khoảng thời gian (mỗi nhóm sẽ có thứ tự sprint khác nhau vụ thuộc vào tính năng mà nhóm chịu trách nhiệm) Các tính năng mới sẽ được build và test trên các test server khác nhau và chúng sẽ được định kì merge lại với nhau để hoàn thiện tính năng đưa lên production (sản phẩm cuối cùng của quy trình dành cho người sử dụng) Yêu cầu của dự án là giảm thiểu tối đa số lượng lỗi phát sinh trên production, chính vì vậy cần có báo cáo định kì để theo dõi thông số trên nhằm đảm bảo chất lượng sản phẩm
Hình thức: Báo cáo dưới dang bảng thống kê và biểu đồ được thực hiện bằng file excel với 3 sheet chính:
Defect Data : Nguồn của báo cáo thống kê được xuất ra từ ITS là thông tin của tất cả lỗi phát sinh được nhóm phát triển phát hiện và ghi chú lại
Queries: Là các điều kiện lọc để phân nguồn dữ liệu vào đúng nơi cần thống kê
60 Trends: Là báo cáo hiển thị bao gồm bảng thống kê và các biểu đồ trực quan dành cho nhà quản lý để theo dõi chất lượng dự án.
Các nội dung báo cáo chính
- Escaped defects: Tổng số lượng bug thống kê trên test server, staging và production; số lượng bug không bị phát hiện trong quá trình thực hiện bị thoát lên staging, số lượng bug ở staging thoát lên production
Hình 5.1 Defect Escape Report Định nghĩa về cấp độ ảnh hưởng của bug trong dự án chia làm 5 cấp theo thứ tự từ cao xuống thấp là Critical, High, Medium, Low, Cosmetic trong đó các bug Critical
61 và High luôn được kiểm soát chặc chẽ, vì vậy trong nội dung báo cáo này có thêm bảng thống kê lọc riêng các bug có dán nhãn Critical và High
Hình 5.2 High/Critical Defect Escape Report
- Bug by components/modules: Như đã trình bày trong phần giới thiệu, mỗi nhóm nhỏ khác nhau sẽ chịu trách nhiệm một nhóm tính năng khác nhau Việc thống kê phân loại bug theo tính năng là cần thiết để cải thiện và nâng cao hiệu quả làm việc trong mỗi nhóm phát triển
Hình 5.3 Escape Production by Durable Team
C/H Defects Escape PRODUCTION by Durable Team
ALL SERVERITY Defects Escape PRODUCTION by
Misc Shoppers Owners Ad Products Dealers Content
Hình 5.4 Escape Staging by Durable Team
- Defect Ratio: Là tỷ lệ tìm thấy lỗi của các nhóm khác nhau trong cùng sản phẩm hay môi trường Báo cáo hiện đang thống kê tỷ lệ giữa hai nhóm onshore (team US)
C/H Defects Escape to STAGING by Durable Team
Misc Shoppers Owners Ad Products Dealers Content
ALL SERVERITY Defects Escape to STAGING by
MiscShoppersOwnersAd ProductsDealers
64 và offshore ( team Việt Nam) nhằm xác định mức độ hiệu quả trong việc kiểm thử phần mềm giữa hai nhóm trên
- DDE (Defect Detection Efficiency): Số bug có hoặc không có hiệu lực đã được báo lên Theo dõi chỉ số DDE nhằm mục đích giảm thiểu tối đa số lượng bug không có hiệu lực để nâng cao hiệu suất kiểm thử phần mềm
KẾT QUẢ ĐẠT ĐƯỢC VÀ HƯỚNG PHÁT TRIỂN
Kết quả đạt được
Trình bày được phương pháp thích hợp dùng để định nghĩa mô hình đo lường sản phẩm phần mềm Phương thức được chọn là GQM Với sự lựa chọn này, bài viết cung cấp hướng dẫn liên quan đến sự kết hợp của các thang đo có ích cho việc đảm bảo thực hiện thành công một hệ thống đo lường Định nghĩa một mô hình cơ bản để đo lường chất lượng quy trình phát triển phần mềm theo phương thức Agile dựa trên phương thức GQM đã được nghiên cứu Sự linh hoạt thêm hoặc loại bỏ các đặc tính và thang đo đảm bảo mô hình có thể được điều chỉnh với các nhu cầu cụ thể của một môi trường phát triển phần mềm Tất cả các yếu tố nêu trên góp phần tăng khả năng thành công của ứng dụng mô hình chất lượng phần mềm
- Ứng dụng xây dụng được sản phẩm cụ thể, đã và đang ứng dụng trong dự án hiện tại.
Hướng phát triển
Trong ngắn hạn: Ứng dụng toàn diện mô hình vào dự án thực tiễn để đánh giá tổng quan sâu sắc hơn về mô hình đã xây dựng
Về lâu dài: Phân tích thiết kế hệ thống đánh giá tự động dựa trên mô hình đã nghiên cứu
DANH MỤC CÁC TÀI LIỆU THAM KHẢO
[1] Capers Jones, “Measuring Defect Potentials and Defect Removal Efficiency”, 2008
[2] Christopher W.H.Davis, “Agile Metrics in Action”, Manning Publications Co
[3] D Hartmann, R Dymond, “Appropriate Agile Measurement: Using Metrics and Diagnostics to Deliver Business Value”, in Proc of AGILE 2006 Conference (AGILE’06), Minneapolis, Minnesota, 2006, pp 126–134
[4] Dennis Bijlsma, MiguelAlexandre Ferreira, Bart Luijten, and Joost Visser
Faster issue resolution with higher technical quality of software.Software Quality Journal, 2012
[5] David Chappell The business value of software quality http://www davidchappell.com/writing/white_papers.php
[6] David Chappell The three aspects of software quality: Functional, structural, and process http://www.davidchappell.com/writing/white_papers.php
[7] Eric Bouwers, Joost Visser, and Arie van Deursen Getting what you measure
[8] Ilja Heitlager, Tobias Kuipers, and Joost Visser A Practical Model for Measuring Maintainability In International Conference on the Quality of Information and Communications Technology, pages 30-39, 2007
[9] ISO ISO/IEC 25010: Systems and software engineering systems and software quality requirements and evaluation (square) system and software quality models, March 2011
[10] ISO International Standard ISO/IEC 9126
[11] Jim Highsmith Beyond scope, schedule, and cost:The agile triangle http://jimhighsmith.com/beyond-scope-schedule-and-cost-the-agile-triangle/, November 2010
67 [12] Jim Highsmith Determining business value http://jimhighsmith.com/determining-business-value/, January 2013
[13] K Schwaber, Agile Project Management with Scrum Redmond, USA:
[14] L Williams, “Agile software development methodologies and practices”, Advances in Computers, vol 80, pp 1–44, 2010
[15] Norman E Fenton and Martin Neil Software metrics: roadmap In Proceedings of the Conference on The Future of Software Engineering, 2000
[16] Q Ktata, G Levesque, “Designing and Implementing a Measurement Program for Scrum Teams: What do agile developers really need and want?”, in Proc of C3S2E-10, Montreal, Canada, 2010, pp 101–107
[17] R Van Solingen and E Berghout The Goal/Question/Metric Method: A Practical Guide for Quality Improvement of Software Development McGraw-Hill, 1999
[18] The Agile Research Network, Peggy Gregory and Katie Taylor (University of Central Lancashire, UK), Helen Sharp, Leonor Barroca and Dina Salah (The Open University, UK), “From Performance to Value: Measuring in Agile”, 2015
[19] V Mahnic, N Zabkar, “Measuring Progress of Scrum-based Sofware Projects”, 2012
[20] Victor R Basili, Gianluigi Caldiera, and H Dieter Rombach The goal question metric approach In Encyclopedia of Software Engineering Wiley, 1994
[21] V.R Basili, M Lindvall, M Regardie, C Seaman, J Heidrich, J Munch, D
Rombach, and A Trendowicz Linking software development and business strategy through measurement, April2010
[22] W Bruce Chew Basic operations self-instructional workbook http://hbswk.hbs.edu/archive/1460.html, April 2000
[23] https://hbr.org/2016/05/embracing-agile [24] https://hbr.org/2007/11/a-leaders-framework-for-decision-making
