Giải pháp thăm quan


HỖ TRỢ
Đăng ký
Đăng nhập
Bắt đầu dùng thử miễn phí

Cách đo lường chất lượng yêu cầu

Các yêu cầu phải có chất lượng nếu dự án thành công. Bằng cách đặt ra các tiêu chuẩn và điều kiện, các nhóm có thể đánh giá tiến độ của họ trong việc đạt được các mục tiêu đó. Các số liệu được sử dụng sẽ khác nhau tùy thuộc vào công việc đang được thực hiện; tuy nhiên, một số chỉ số chung cho các yêu cầu theo dõi bao gồm:

  • Phạm vi kiểm tra – Có bao nhiêu chức năng của mỗi hệ thống đã được thử nghiệm?
  • Đánh giá độ chính xác – Có mức độ chính xác cao trong các thông số kỹ thuật không?
  • Tính đầy đủ của chức năng – Tất cả các lĩnh vực chức năng có được chỉ định đầy đủ chi tiết không?
  • Tiêu chí chấp nhận rõ ràng – Tiêu chí chấp nhận của người dùng có thể dễ dàng được xác định từ tài liệu không?
  • Yêu cầu thay đổi – Có bao nhiêu yêu cầu thay đổi đã được đệ trình kể từ khi thông số kỹ thuật được viết?

Bằng cách thường xuyên đo lường các yếu tố định tính này, bạn sẽ có thể xác định nhóm của mình cần tập trung nỗ lực vào đâu và cải thiện chất lượng dự án của bạn.

Cách đo lường chất lượng yêu cầu

Mục lục

Tại sao việc đánh giá chất lượng của các yêu cầu lại quan trọng?

  • Trước tiên, chúng ta phải xác định xem chúng ta có gặp vấn đề về yêu cầu hay không và mức độ nghiêm trọng của vấn đề đó để tính toán chính xác lượng nỗ lực cần thiết để biến những nguồn lực không đủ của chúng ta thành những nguồn lực thỏa đáng.
  • Với tư cách là người giám sát, chúng tôi cố gắng đảm bảo rằng nhóm của chúng tôi đang làm việc hiệu quả trong khi xây dựng đặc tả yêu cầu hoặc tiến hành phân tích yêu cầu. Họ có đạt được mục tiêu của mình không?
  • Sau khi xem xét các tình huống khác nhau, chúng tôi đã thiết lập một tiêu chuẩn cho các thông số kỹ thuật yêu cầu của chúng tôi về giá trị của một chỉ số chất lượng tiêu chí. Chúng tôi đặt bốn giá trị để phản ánh từng tình huống tương ứng:
    • Soạn thảo một cuốn tiểu thuyết gốc trong một môi trường khó khăn không phải là điều dễ dàng.
    • Tạo ra một câu chuyện sáng tạo mà không có bất kỳ áp lực hay giới hạn nào.
    • phát triển trần tục
    • Mua lại các mặt hàng không phát triển
  • Để đảm bảo chất lượng cao nhất cho các dự án của mình, chúng tôi thiết lập một điểm chuẩn cho các mục Đánh giá Yêu cầu Hệ thống và Đánh giá Yêu cầu Phần mềm.

Khi nói đến các chỉ số kỹ thuật, chỉ số chất lượng yêu cầu là một trong những công cụ mạnh mẽ nhất hiện có. Xét cho cùng, về mặt lịch sử, việc phát triển một thứ gì đó khác với dự định ban đầu là một vấn đề phổ biến đối với các kỹ sư. Mặc dù việc sử dụng một tiêu chuẩn khách quan không phải lúc nào cũng đảm bảo kết quả hoàn hảo, nhưng nó có thể giảm thiểu đáng kể các rủi ro và sai sót tiềm ẩn trong sản phẩm cuối cùng.

Kích cỡ sản phẩm

Hiểu số lượng yêu cầu trong một dự án là điều cần thiết. Điều này có thể được thực hiện thông qua các trường hợp sử dụng, yêu cầu chức năng, câu chuyện của người dùng, mô tả tính năng, bảng phản hồi sự kiện hoặc mô hình phân tích. Tuy nhiên, lựa chọn của nhóm bạn để đại diện cho các yêu cầu này hoàn toàn không ảnh hưởng đến chức năng chính của chúng – thực hiện các hành vi hệ thống dựa trên các điều kiện cụ thể và nhu cầu chức năng.

Bắt đầu quá trình đánh giá yêu cầu của bạn bằng cách đếm các yêu cầu chức năng riêng lẻ được phân bổ cho một lần phát hành hoặc phát triển sản phẩm. Nếu các cá nhân khác nhau không thể nhận được kết quả tương tự khi họ đếm, điều cần thiết là phải tính đến các loại hiểu lầm và mơ hồ khác có thể phát sinh trong tương lai. Bạn cần biết số lượng yêu cầu tạo nên một bản phát hành để theo dõi chính xác tiến trình của nhóm bạn. Nếu không có kiến ​​thức này, bạn sẽ không có cách nào để đánh giá khi nào bạn hoàn thành dự án! Theo dõi lượng công việc còn lại trong hồ sơ tồn đọng của bạn để đảm bảo rằng mọi người đều hiểu những gì cần phải xảy ra trước khi hoàn thành.

Để đảm bảo rằng các yêu cầu chức năng của bạn là thước đo chính xác về quy mô hệ thống, điều cần thiết đối với các nhà phân tích là tạo ra chúng ở mức độ chi tiết nhất quán. Một cách tuyệt vời để làm điều này là chia nhỏ các yêu cầu cấp cao thành các thành phần con nhỏ hơn để có thể kiểm tra riêng lẻ. Nói cách khác, người kiểm tra nên thiết kế các bài kiểm tra đơn giản để xác định xem từng yêu cầu có được thực hiện chính xác hay không. Điều này đảm bảo tất cả các tác vụ yêu cầu cùng một lượng nỗ lực triển khai và thử nghiệm bất kể mức độ phức tạp của chúng. Để đảm bảo rằng các nhà phát triển và người kiểm tra có thể thực hiện và kiểm tra đúng từng yêu cầu, điều quan trọng là phải theo dõi xem có bao nhiêu yêu cầu con. Các phương pháp định cỡ thay thế khác bao gồm điểm trường hợp sử dụng và điểm câu chuyện, tất cả đều đo lường nỗ lực ước tính cần thiết cho một đoạn chức năng được xác định cụ thể.

Mặc dù các yêu cầu chức năng là cần thiết nhưng cũng không thể bỏ qua các yêu cầu phi chức năng. Những yêu cầu cụ thể này đòi hỏi phải tăng cường nỗ lực để thiết kế và thực hiện một cách hiệu quả. Một số chức năng phụ thuộc vào các nhu cầu phi chức năng được liệt kê như mối quan tâm về bảo mật, cần được thể hiện trong kích thước ước tính cho các tính năng chức năng. Tuy nhiên, tất cả các mong muốn phi chức năng sẽ không xuất hiện ở đây—đảm bảo xem xét ảnh hưởng của chúng đối với ước tính của bạn là rất quan trọng! Hãy xem xét các tình huống sau:

  • Cung cấp nhiều lộ trình để sử dụng một tính năng nhất định giúp nâng cao trải nghiệm người dùng; tuy nhiên, một công việc như vậy đòi hỏi nhiều thời gian và năng lượng hơn từ các nhà phát triển hơn là nếu chỉ có một phương thức truy cập.
  • Ngay cả khi bạn không triển khai các tính năng sản phẩm mới, các ràng buộc về thiết kế và triển khai bắt buộc như giao diện bên ngoài để phù hợp với môi trường vận hành hiện tại có thể làm tăng đáng kể khối lượng công việc giao diện cần thiết.
  • Để đảm bảo hiệu suất tối đa, có thể cần phải thực hiện công việc thiết kế cơ sở dữ liệu và thuật toán tỉ mỉ để đảm bảo phản hồi nhanh chóng.
  • Để đáp ứng các yêu cầu nghiêm ngặt về tính khả dụng và độ tin cậy, cần phải xây dựng các cơ chế chuyển đổi dự phòng và khôi phục dữ liệu có thể tốn nhiều thời gian. Ngoài ra, kiến ​​trúc hệ thống bạn chọn cũng có thể bị ảnh hưởng bởi những yêu cầu này.

Bằng cách theo dõi mức tăng yêu cầu theo thời gian, bất kể chỉ số kích thước được sử dụng là gì, bạn sẽ thu được thông tin chi tiết hữu ích. Khách hàng của tôi nhận thấy rằng các dự án của họ thường tăng khoảng XNUMX% trước khi giao hàng. Ngoài ra, hầu hết các dự án của họ đều chạy lâu hơn ít nhất XNUMX% so với dự kiến! Không có sự trùng hợp nào ở đây—rõ ràng là có mối liên hệ giữa hai xu hướng này.

Yêu cầu chất lượng

Hãy dành chút thời gian để đo lường chất lượng các yêu cầu của bạn bằng cách thực hiện kiểm tra chúng. Ghi lại bất kỳ lỗi nào bạn tìm thấy và chia chúng thành các loại khác nhau, chẳng hạn như thiếu yêu cầu, yêu cầu không chính xác, không cần thiết, mơ hồ, v.v. Sau đó, phân tích các loại lỗi này cùng với nguyên nhân gốc rễ của chúng để các yêu cầu trong tương lai được thực hiện chính xác từ đầu đến cuối. Sử dụng dữ liệu này như một cơ hội để cải tiến nhằm nâng cao hiệu quả của quy trình yêu cầu của bạn! Chẳng hạn, nếu bạn xác định rằng các yêu cầu còn thiếu thường là một vấn đề lặp đi lặp lại, thì cần phải thay đổi các phương pháp khơi gợi của bạn. Có thể các nhà phân tích kinh doanh của bạn không hỏi đủ hoặc các truy vấn chính xác, hoặc có thể bạn phải thu hút thêm các đại diện người dùng phù hợp hơn trong quá trình phát triển nhu cầu.

Nếu nhóm cảm thấy bị ép thời gian khi kiểm tra tất cả các tài liệu yêu cầu của họ, thì một tùy chọn hiệu quả hơn là kiểm tra một vài trang và sau đó tính mật độ lỗi trung bình—số lượng lỗi trên mỗi trang thông số kỹ thuật. Giả sử rằng mẫu này phản ánh chính xác toàn bộ tài liệu (điều này có thể khá là giả định), nhân nó với các trang chưa được kiểm tra có thể cho chúng tôi ước tính có bao nhiêu lỗi ẩn có thể còn sót lại trong thông số kỹ thuật của chúng tôi. Người kiểm tra thiếu kinh nghiệm có thể không phát hiện được tất cả các lỗi, vì vậy hãy sử dụng số lượng lỗi ước tính chưa được phát hiện làm ước tính tối thiểu. Bằng cách sử dụng lấy mẫu kiểm tra, bạn có thể đánh giá chất lượng của tài liệu và quyết định xem có khả thi về mặt tài chính để kiểm tra phần còn lại của đặc tả yêu cầu hay không – điều này chắc chắn là có!

Ngoài ra, ghi lại các lỗi yêu cầu được phát hiện sau khi đường cơ sở được thiết lập. Những vấn đề này sẽ không được chú ý trong quá trình kiểm soát chất lượng trong khi phát triển các yêu cầu. Tính toán tỷ lệ thành công của nhóm bạn trong việc tìm ra những lỗi này ở giai đoạn đầu này – sẽ tiết kiệm chi phí hơn nhiều so với việc cố gắng sửa chúng khi thiết kế và viết mã đã hoàn tất!

Dữ liệu kiểm tra có thể cung cấp cho bạn hai chỉ số có giá trị cao: hiệu suất và hiệu quả. Tính hiệu quả định lượng số lượng lỗi trung bình được phát hiện trong mỗi giờ lao động, trong khi Hiệu quả cho biết tỷ lệ tất cả các lỗi hiện có được xác định thông qua kiểm tra – một thước đo cho thấy mức độ thành công của các đợt kiểm tra của bạn (hoặc các hoạt động đảm bảo chất lượng khác). Tính hiệu quả cho phép bạn ước tính chi phí phát hiện lỗi thông qua kiểm tra. Bạn có thể cân nhắc chi phí này với số tiền chi cho việc xử lý lỗi trong các yêu cầu được tìm thấy sau này trong quá trình phát triển hoặc sau khi chuyển giao, cho phép bạn xác định xem việc cải thiện chất lượng yêu cầu của mình có đáng giá về mặt tài chính hay không.

Yêu cầu Tình trạng

Để luôn dẫn đầu dự án, hãy theo dõi từng yêu cầu trong suốt vòng đời của nó. Bạn thậm chí có thể chỉ định một giá trị thuộc tính để lưu trữ thông tin đó để tăng độ bảo mật và độ chính xác. Kiểu theo dõi trạng thái này sẽ giúp giảm tình trạng tiến thoái lưỡng nan phổ biến với các dự án phần mềm – tuyên bố sai sự thật rằng “đã hoàn thành XNUMX%”. Mọi yêu cầu phải có một trong các trạng thái này trong bất kỳ khung thời gian nhất định nào:

  • Được ủng hộ (ai đó ủng hộ mạnh mẽ nó)
  • Quá trình phê duyệt đã thành công và việc phân bổ đã được đặt trên cơ sở.
  • Sau khi cẩn thận tạo, viết kịch bản và kiểm tra mã, chúng tôi đã triển khai nó.
  • Khi yêu cầu đã trải qua và vượt qua các thử nghiệm của nó, yêu cầu đó đã được xác minh để tích hợp thành công vào sản phẩm.
  • Yêu cầu này sẽ được đáp ứng vào một ngày sau đó.
  • Bạn quyết định Xóa nó và không thực hiện nó.
  • Bị loại bỏ (khái niệm chưa bao giờ được bật đèn xanh)

Bên cạnh các tùy chọn trạng thái nói trên, các trạng thái khác có thể được xem xét. Một số có thể chọn trạng thái “Đã xem xét” để xác thực các yêu cầu của họ trước khi thêm chúng vào cấu hình cơ sở. Ngoài ra, các tổ chức có thể sử dụng "Delivered to Customer" như một phương tiện để xác minh rằng họ đã đưa ra yêu cầu nguyên vẹn và chính xác.

Nếu bạn hỏi về tiến độ của một nhà phát triển, anh ta có thể trả lời rằng có 87 yêu cầu cho dự án cụ thể này. 61 đã được xác nhận và 9 đã sẵn sàng nhưng vẫn đang chờ xác minh trong khi 17 vẫn chưa được hoàn thiện. Tuy nhiên, điều quan trọng cần lưu ý là không phải tất cả các yêu cầu này đều phù hợp về quy mô hoặc ảnh hưởng đến sự hài lòng của khách hàng; họ cũng có thể yêu cầu số lượng nỗ lực khác nhau. Với tư cách là người quản lý dự án, tôi chắc chắn rằng chúng tôi đã hiểu chính xác về quy mô hệ thống con và mức độ hoàn thành của nó. Điều này hiệu quả hơn nhiều so với việc chỉ nói đơn giản “Tôi đã hoàn thành được XNUMX%”. Với một bức tranh toàn cảnh về tiến độ, tôi có thể tự tin nói rằng “trông thật tuyệt!”

Thay đổi yêu cầu

Để đạt được quản lý yêu cầu thành công, tổ chức của bạn phải chú ý đến từng yêu cầu bổ sung, xóa và sửa đổi. Điều này sẽ cho phép bạn theo dõi trạng thái cũng như ý nghĩa của tất cả các yêu cầu thay đổi. Bạn cũng có thể sử dụng dữ liệu này để trả lời một số câu hỏi điều tra như:

  • Có bao nhiêu yêu cầu thay đổi đã được thực hiện trong khung thời gian được chỉ định?
  • Có bao nhiêu yêu cầu đã được trả lời và bao nhiêu yêu cầu vẫn chưa được giải quyết?
  • Tỷ lệ chấp thuận cho các yêu cầu là bao nhiêu và bao nhiêu phần trăm bị từ chối?
  • Nhóm đã tiêu tốn năng lượng đến mức nào để thực hiện từng sửa đổi được phép?
  • Khoảng thời gian điển hình mà các yêu cầu vẫn mở là bao lâu?
  • Trung bình, có bao nhiêu mục (ví dụ: yêu cầu hoặc tạo phẩm) bị ảnh hưởng bởi mỗi yêu cầu thay đổi được gửi?

Đảm bảo rằng bạn theo dõi bất kỳ thay đổi nào được thực hiện trong quá trình phát triển sau khi đặt đường cơ sở cho mỗi bản phát hành. Hãy nhớ rằng, một yêu cầu thay đổi có thể ảnh hưởng đến nhiều loại yêu cầu khác nhau (hướng đến người dùng, chức năng và phi chức năng). Để đánh giá có bao nhiêu thay đổi đã trải qua trong một khoảng thời gian cụ thể, hãy chia số lần sửa đổi cho tổng số lượng yêu cầu trước khoảng thời gian này (như khi xác định đường cơ sở của bạn).

Chúng tôi không muốn loại bỏ hoàn toàn tính không ổn định của các yêu cầu. Rốt cuộc, thường có lý do chính đáng để thay đổi chúng. Tuy nhiên, đồng thời, chúng tôi phải đảm bảo rằng dự án của chúng tôi có thể xử lý các thay đổi và vẫn đáp ứng các nghĩa vụ của nó. Tiến gần hơn đến việc hoàn thành sẽ phát sinh thêm chi phí khi các thay đổi được thực hiện thường xuyên; điều này khiến bạn khó xác định khi nào bạn sẽ phát hành sản phẩm của mình ra thế giới! Khi quá trình phát triển tiến triển, hầu hết các dự án sẽ trở nên linh hoạt hơn trước những thay đổi; nói cách khác, tốc độ chấp nhận thay đổi sẽ giảm dần cho đến khi về XNUMX khi quá trình phát hành kết thúc. Cách tiếp cận lặp đi lặp lại mang lại cho các nhóm nhiều cơ hội để kết hợp các cải tiến trong các lần lặp lại sau trong khi vẫn đi đúng tiến độ của mỗi chu kỳ.

Nếu nhóm của bạn tràn ngập các yêu cầu thay đổi, rất có thể quá trình khơi gợi không toàn diện hoặc các ý tưởng tiếp tục nảy sinh khi dự án tiến triển. Do đó, điều cần thiết là phải theo dõi xem những thay đổi này đến từ đâu từ hoạt động tiếp thị, người dùng, nhân viên bán hàng, nhóm quản lý, v.v. Việc theo dõi thông tin này sẽ giúp bạn xác định ai và điều gì cần chú ý để giảm thiểu các yêu cầu bị bỏ qua và ngăn chặn thông tin sai lệch trong quá trình thực hiện.

Khi các yêu cầu thay đổi vẫn chưa được giải quyết trong một khoảng thời gian dài, đó là dấu hiệu rõ ràng rằng quy trình quản lý thay đổi của bạn cần được chú ý. Cá nhân tôi đã chứng kiến ​​một tổ chức có các yêu cầu nâng cao đã tồn tại nhiều năm và vẫn đang chờ xử lý. Để người quản lý dự án ưu tiên năng lượng của họ cho các hạng mục quan trọng nhất trong hồ sơ tồn đọng, nhóm này nên chỉ định các yêu cầu mở cụ thể thành các bản phát hành bảo trì theo kế hoạch và chuyển đổi các thay đổi bị trì hoãn dài hạn khác thành những thay đổi bị từ chối. Bằng cách này, họ có thể dễ dàng giải quyết những gì cần thiết và cấp bách hơn trước khi giải quyết những vấn đề ít cấp bách hơn.

Thời gian và nỗ lực

Để đảm bảo hiệu suất tối ưu, chúng tôi thực sự khuyên bạn nên ghi lại lượng thời gian mà nhóm của bạn dành cho các nhiệm vụ kỹ thuật yêu cầu. Điều này bao gồm xây dựng các yêu cầu chất lượng và quản lý thay đổi, theo dõi tiến trình, tạo dữ liệu truy xuất nguồn gốc và các hoạt động khác liên quan đến quy trình này.

Mọi người thường hỏi tôi nên dành bao nhiêu thời gian và năng lượng cho các nhu cầu cần thiết của một dự án. Câu trả lời này phụ thuộc rất nhiều vào quy mô, đội ngũ, tổ chức xây dựng nó và mục đích của nó. Theo dõi những nỗ lực của bạn đã đầu tư vào các nhiệm vụ quan trọng cho các dự án như thế này có thể giúp bạn lập kế hoạch tốt hơn cho những dự án trong tương lai với các ước tính chính xác.

Nếu nhóm của bạn trước đó đã hoàn thành một dự án và phân bổ 10% thời gian cho các yêu cầu, thì sau khi phản ánh, bạn có thể nhận thấy rằng chất lượng của những yêu cầu đó có thể được cải thiện nhiều. Nếu phải đối mặt với một dự án tương tự khác, sẽ là khôn ngoan nếu Người quản lý dự án đảm bảo nỗ lực nhiều hơn để tạo ra các thông số kỹ thuật kỹ lưỡng – hơn mười phần trăm tổng số tài nguyên có sẵn là đủ!

Khi bạn thu thập và phân tích dữ liệu, hãy so sánh nỗ lực phát triển dự án với thước đo quy mô sản phẩm. Các yêu cầu được ghi lại của bạn sẽ đưa ra ý tưởng về kích thước tổng thể của nó. Nói chính xác hơn, bạn có thể tương quan nỗ lực để đếm các thông số kỹ thuật riêng lẻ có thể kiểm tra, điểm trường hợp sử dụng hoặc điểm chức năng – bất cứ điều gì tỷ lệ thuận với phép đo sản phẩm của bạn. Tham khảo Hình 1 trong bối cảnh này sẽ mang lại một thước đo để đánh giá khả năng của nhóm phát triển của bạn, điều này giúp dự đoán nội dung phát hành cũng như phạm vi chúng một cách chính xác hơn nữa! Bằng cách thu thập dữ liệu liên quan đến kích thước cho sản phẩm của bạn và ghi nhận nỗ lực triển khai liên quan, bạn có thể lập các ước tính chính xác để chuẩn bị cho các dự án tương tự trong tương lai.

Nỗi sợ hãi có thể đọng lại trong tâm trí nhiều người; sợ rằng việc phát triển một chương trình đo lường phần mềm sẽ lấy đi thời gian quý báu dành cho các nhiệm vụ thiết yếu. Ngược lại, việc triển khai một hệ thống số liệu hiệu quả và có mục tiêu không đòi hỏi quá nhiều nỗ lực và năng lượng. Tất cả những gì bạn cần làm là xây dựng cơ sở hạ tầng cơ bản để thu thập và phân tích dữ liệu, cũng như khuyến khích các thành viên trong nhóm của bạn ghi lại một số chi tiết liên quan về hoạt động công việc của họ. Khi bạn tạo ra một nền văn hóa dựa trên các số liệu trong công ty của mình, thật tuyệt vời khi người ta có thể học được những gì thông qua phương pháp này!

Kết luận

Gợi ý và phân tích yêu cầu là các thành phần thiết yếu của phát triển phần mềm. Không có chúng, một dự án có thể thất bại do các thông số kỹ thuật bị thiếu hoặc không chính xác, dẫn đến việc phải làm lại tốn kém và có khả năng dẫn đến kết quả không đạt yêu cầu. Do đó, điều quan trọng là phải đảm bảo rằng bạn có sẵn một quy trình hiệu quả để thu thập các yêu cầu và xác minh tính chính xác trong suốt thời gian của dự án. Với sự quản lý thích hợp, các nhóm có thể đạt được thành công bằng cách tạo ra các yêu cầu chi tiết mô tả chính xác tất cả các chức năng mong muốn, đảm bảo rằng không có gì bị bỏ sót. Bằng cách thường xuyên đánh giá các quy trình và số liệu hiện có trên mỗi liên doanh, các nhóm sẽ có thể hiểu rõ hơn những gì hoạt động tốt nhất cho họ khi tìm kiếm phản hồi của người dùng trong các chu kỳ phát triển. Điều này sẽ giúp giữ cho các dự án đi đúng hướng và đóng góp vào kết quả chất lượng cao hơn.

Đừng quên chia sẻ bài viết này!

Áo sơ mi