Giải pháp thăm quan


HỖ TRỢ
Đăng ký
Đăng nhập
Bắt đầu dùng thử miễn phí
6 Mẹo để triển khai thành công công cụ Quản lý Yêu cầu của bạn
Danh sách blog

6 Mẹo để triển khai thành công công cụ Quản lý Yêu cầu của bạn

Blog | đọc 8 phút
Do admin viết

Mục lục

6 Mẹo để triển khai thành công công cụ Quản lý Yêu cầu của bạn

Tại sao bạn cần một công cụ Quản lý Yêu cầu:

Không có gì bí mật mà poor yêu cầu dẫn đến sản phẩm kém chất lượng và những dự án này thường chứa đầy phạm vi. Những thách thức với cách tiếp cận dựa trên tài liệu đối với các yêu cầu là rất nhiều, bao gồm cả thực tế là rất khó để cập nhật chúng trong sự thay đổi không ngừng của phát triển phần mềm. Ngay cả khi bạn đã thực hiện một công việc xuất sắc trong việc thu thập và ghi lại các yêu cầu của người dùng, thì nhiệm vụ quản lý các yêu cầu chỉ mới bắt đầu.

Dưới đây là một số lý do chính để sử dụng công cụ Quản lý yêu cầu tự động theo Karl Wiegers (bài viết trên www.processimpact.com về Quản lý yêu cầu tự động).

  • Quản lý các phiên bản và thay đổi. Hầu hết các hệ thống được phát hành theo kiểu lặp đi lặp lại (hoặc Agile) ngày nay. Điều này có nghĩa là các yêu cầu sẽ có các phiên bản được liên kết với bản phát hành. Có thể theo dõi các thay đổi và xác định tác động của các thay đổi là kiểm soát thay đổi và phạm vi thay đổi.
  • Lưu trữ thông tin bổ sung về yêu cầu trong các thuộc tính yêu cầu. Còn rất nhiều điều chúng ta cần biết về một yêu cầu khác ngoài tuyên bố của yêu cầu. Ví dụ: trạng thái của các yêu cầu, mức độ ưu tiên, ai đã yêu cầu nó, trạng thái kiểm tra. Ở đây chỉ có một vài đề nghị.
  • Liên kết các yêu cầu với các phần tử hệ thống khác. Để đảm bảo tất cả các yêu cầu là một phần của sản phẩm, tất cả các yêu cầu đều được kiểm tra, đánh giá các thay đổi, v.v., chúng ta cần có khả năng liên kết các yêu cầu với các phần tử hệ thống khác.
  • Theo dõi trạng thái. Hãy nghĩ đến việc có thể tạo danh sách tất cả các yêu cầu không được chấp thuận, tất cả các yêu cầu không được liên kết với các yêu cầu cấp thấp hơn và tất cả các yêu cầu không được kiểm tra. Đây là những loại thông tin giúp chúng tôi thực sự biết được tình trạng của dự án.
  • Xem các tập hợp con yêu cầu. Hãy nghĩ đến việc có thể xem tất cả các yêu cầu ưu tiên cao mà không có phương pháp kiểm tra được chỉ định. Hoặc một văn phòng an ninh chỉ muốn xem xét các yêu cầu liên quan đến bảo mật. Việc có thể lọc các yêu cầu để chỉ bao gồm thông tin mà người dùng muốn xem giúp giảm thời gian cần thiết để xem xét các yêu cầu này.
  • Kiểm soát quyền truy cập. Bạn sẽ muốn đảm bảo rằng các nhà phân tích kinh doanh chỉ có thể sửa đổi các yêu cầu của người dùng; nhà phân tích hệ thống chỉ có thể sửa đổi các yêu cầu hệ thống, v.v. Sau khi được chấp thuận, quyền truy cập vào các yêu cầu phải được giới hạn để không thể thực hiện thêm thay đổi nào nếu không được xem xét.
  • Giao tiếp với các bên liên quan. Thông báo về các thay đổi là điều cần thiết để đảm bảo các bên liên quan nhận thức được tất cả các thay đổi tiềm ẩn. Hầu hết các công cụ quản lý yêu cầu có thể hỗ trợ tự động cung cấp loại thông báo này.

Đối với những người trong chúng ta, những người đã sử dụng các công cụ quản lý yêu cầu, rất khó để tưởng tượng việc quay lại thực hiện công việc đó trên giấy. Và tôi tin rằng có rất ít người trong chúng ta chọn quay lại phương pháp đó. Cá nhân tôi sẽ sử dụng bất kỳ công cụ quản lý yêu cầu nào theo cách tiếp cận dựa trên tài liệu. Tuy nhiên, điều đáng ngạc nhiên đối với tôi là nhiều tổ chức thuộc mọi quy mô tiếp tục dựa vào các công cụ dựa trên tài liệu để quản lý các yêu cầu của họ. Sử dụng công cụ Quản lý Yêu cầu là bước đầu tiên cần thiết để kiểm soát các yêu cầu.

Trước khi mua một công cụ Quản lý Yêu cầu:

Không có gì bí mật mà chuyên nghiệp các giải pháp kỹ thuật yêu cầu giúp nâng cao hiệu quả khi làm việc với các yêu cầu. Họ cũng giúp giảm thiểu số lượng sai lầm điều này thường dẫn đến những hiệu chỉnh tốn kém khi được tìm thấy trong các giai đoạn sau của vòng đời phát triển. 

Do đó, nhiều công ty đang tìm kiếm các giải pháp kỹ thuật yêu cầu như vậy, nhưng thật không may, quy tắc tương tự đối với hầu hết các loại công cụ phần mềm khác cũng áp dụng cho các giải pháp kỹ thuật yêu cầu: một kẻ ngốc với một công cụ vẫn là một kẻ ngốc…

Tốt nhất trong lớp các giải pháp kỹ thuật yêu cầu như nền tảng ALM Yêu cầu Truy cập rất linh hoạt có thể để hỗ trợ hầu hết mọi loại quy trình kỹ thuật yêu cầu. Tất nhiên, chúng tôi - với tư cách là nhà cung cấp công cụ - rất vui khi bán cho bạn một số phần mềm nhưng chúng tôi tin rằng chỉ điều này sẽ không giúp được gì cho bạn. Thay thế we muốn giúp bạn thành công trong việc sử dụng sản phẩm của chúng tôi.

Vì vậy, trước khi mua một giải pháp kỹ thuật yêu cầu hãy đảm bảo rằng bạn có một quy trình kỹ thuật yêu cầu phù hợp được xác định với những hoạt động nhất định được giao cho những vai trò nhất định. Tất nhiên, chúng tôi cũng có thể chia sẻ kinh nghiệm của chúng tôi với bạn trong lĩnh vực này. Nếu bạn biết các đặc điểm chi tiết của quy trình của bạn nó dễ dàng hơn nhiều cho bạn để tìm một giải pháp thích hợp phù hợp với nhu cầu của qua một vài thao tác đơn giản về quá trình.

6 mẹo để triển khai thành công công cụ Quản lý yêu cầu trên một hệ thống phức tạp

Nhiều năm trước, tôi đã dành vài năm làm việc trên một hệ thống điều khiển vũ khí rất phức tạp. Như bạn có thể tưởng tượng, các yêu cầu rất lớn, phức tạp và thường xuyên thay đổi. Chúng tôi đã dành rất nhiều thời gian chỉ để cố gắng quản lý những thay đổi khó chịu tiếp tục được gửi, cả từ khách hàng và nhà phát triển.  Trong những ngày đầu tiên, chúng tôi không có bất kỳ công cụ quản lý yêu cầu nào để giúp sử dụng đánh giá những thay đổi này. Chúng tôi đã sử dụng Interleaf và Excel (Tôi có thể nghe thấy tiếng rên rỉ đau đớn bây giờ). Mọi thứ đều là thủ công, bao gồm cả việc truy xuất nguồn gốc phức tạp của chúng tôi. Chúng tôi có một vài người không làm gì ngoài việc duy trì ma trận truy xuất nguồn gốc và đánh giá tác động của những thay đổi. Tại thời điểm này, chúng tôi chỉ có khả năng truy xuất nguồn gốc từ Khái niệm hoạt động đến Yêu cầu hệ thống đến Yêu cầu hệ thống con. Tôi nói là “duy nhất” nhưng vào thời điểm đó chỉ cần có được mức độ truy xuất nguồn gốc này là một thành tựu lớn. 

Khi chúng tôi có đủ thay đổi, chúng tôi đã ban hành tài liệu yêu cầu hệ thống mới và tài liệu yêu cầu hệ thống con mới. Những nhà thầu kém cỏi đó đã phải trải qua các yêu cầu hệ thống con khổng lồ và xác định thủ công những gì có thay đổi. Tôi không thể tưởng tượng được thời gian mà các nhà thầu bỏ ra chỉ để cố gắng tìm ra những thay đổi mà họ cần quan tâm.

Chính giữa dự án nâng cấp này, khách hàng đã nói đủ và giao nhiệm vụ cho nhóm của tôi đánh giá và lựa chọn một công cụ quản lý yêu cầu. Công cụ chúng tôi chọn không quan trọng đối với cuộc thảo luận cụ thể này, nhưng những gì chúng tôi học được từ việc lựa chọn và triển khai công cụ này là quan trọng.  Đây là một số bài học kinh nghiệm.

(1)  Không có một công cụ nào có thể làm hài lòng tất cả mọi người. Chúng tôi có những người dùng yêu thích lựa chọn của chúng tôi và những người đã chiến đấu với chúng tôi trên từng bước đường. Nếu không có khách hàng hỗ trợ và thực thi thay đổi thì sẽ không thể thực hiện được trên một chương trình lớn như chương trình này. Một người dùng phàn nàn về kích thước cột của ma trận truy xuất nguồn gốc do công cụ tạo ra, hoàn toàn phớt lờ thực tế rằng nó đã tiết kiệm cho anh ta nhiều ngày làm việc thủ công.

(2)  Truy xuất nguồn gốc thủ công của chúng tôi không được sạch sẽ. Khi chúng tôi nhập tất cả thông tin của mình vào công cụ và liên kết với nó, chúng tôi nhận thấy có nhiều lỗ hổng trong việc truy xuất nguồn gốc. Điều đáng lo ngại hơn là chúng tôi có những liên kết thực sự không có ý nghĩa gì. lập ma trận truy xuất nguồn gốc của chúng tôi.

(3) Chỉ cần theo dõi các yêu cầu đã là tuyệt vời, nhưng bây giờ chúng tôi có thể sử dụng nỗ lực tương tự để liên kết các yêu cầu với các kế hoạch kiểm tra và tiến xa hơn đến việc liên kết các yêu cầu của hệ thống con với các tài liệu thiết kế mà chúng tôi có thể xem xét. Điều này không xảy ra trong một sớm một chiều, nhưng nó đã xảy ra. Cuối cùng, chúng tôi có thể theo dõi các yêu cầu hệ thống đến một yêu cầu hệ thống con đối với tài liệu thiết kế đến một mô-đun mã. Chúng tôi thậm chí còn sử dụng một công cụ để xác định độ phức tạp của các mô-đun mã và sử dụng công cụ này để giúp xác định mức độ khó khăn của một thay đổi khi thực hiện và kiểm tra.

(4)  Các chỉ số từ công cụ yêu cầu là chìa khóa để hiểu tính hoàn chỉnh của các hoạt động thử nghiệm. Chúng tôi thường nghĩ rằng chúng tôi đã hoàn thành 50% việc kiểm tra. Rốt cuộc, 50% bài kiểm tra đã được hoàn thành. Tuy nhiên, những gì chúng tôi nhận thấy là trước tiên chúng tôi thường thử nghiệm những phần đơn giản nhất và dễ hiểu nhất của hệ thống. Vì vậy, ngay cả khi nghĩ rằng chúng tôi đã hoàn thành 50%, mọi thứ còn lại rủi ro rất cao. Chúng tôi đã học cách ưu tiên thử nghiệm của mình bằng cách xem xét mức độ ưu tiên của các yêu cầu và độ phức tạp của phần mềm, thông tin mà chúng tôi không thể xác định thông qua truy xuất nguồn gốc thủ công.

(5)  - Rất dễ bị choáng ngợp.  Bắt đầu đơn giản. Chúng tôi đã phải dừng lại những ý tưởng đầy tham vọng của mình và bắt đầu với một mô hình truy xuất nguồn gốc đơn giản. Khi chúng tôi học hỏi và có thêm kinh nghiệm với công cụ này, chúng tôi đã bổ sung thêm thông tin vào mô hình của mình. Chúng tôi đã liên tục đánh giá quy trình của mình để tìm ra những gì chúng tôi có thể làm để cải thiện quy trình của mình.

(6) - Đừng bỏ qua đào tạo và cố vấn. Chúng tôi đã đào tạo tất cả mọi người trong dự án và tạo ra các chuyên gia giúp người dùng vượt qua những trở ngại ban đầu. Chúng tôi đã cử các chuyên gia của mình đến các nhà thầu của chúng tôi trong nhiều tuần tại một thời điểm để giúp họ bắt đầu sử dụng công cụ này. Chúng tôi thậm chí còn có nhóm người dùng nội bộ của riêng mình. Hãy chuẩn bị cho loại nỗ lực này.

Thật là một trải nghiệm học hỏi tuyệt vời đối với tôi. Nếu bạn quan tâm đến việc bắt tay vào thay đổi như thế này để cải thiện quy trình yêu cầu của mình, liên hệ với Visure Solutions. Chúng tôi sẽ rất vui khi được thảo luận về quy trình của bạn với bạn.


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

Áo sơ mi