2009-05-25 63 views

Trả lời

8

Công cụ quản lý yêu cầu thay đổi dành cho người dùng yêu cầu thay đổi trong phần mềm.

Khi quá trình phát triển phần mềm bắt đầu, có thỏa thuận giữa nhóm phát triển và người dùng (hoặc bộ phận của họ) về những gì phần mềm sẽ làm. Điều này được gọi là yêu cầu. Khi tất cả mọi người đồng ý về các yêu cầu, tốt nhất là bằng văn bản, bắt đầu phát triển.

Nếu người dùng phát hiện ra rằng họ cần thay đổi các yêu cầu tại bất kỳ thời điểm nào trong quá trình phát triển, họ thực hiện yêu cầu thay đổi. Những yêu cầu đó được đăng nhập vào công cụ quản lý yêu cầu thay đổi. Nhóm phát triển xem xét yêu cầu và thương lượng với người dùng về thay đổi - sẽ mất thêm bao nhiêu thời gian hoặc tiền - cho đến khi họ đạt được thỏa thuận.

Một khi phần mềm đã được triển khai, có thể có thay đổi bổ sung xác định bởi người sử dụng. Họ ghi lại các yêu cầu của họ trong công cụ quản lý yêu cầu thay đổi. Định kỳ, nhóm phát triển xem xét các yêu cầu thay đổi mới và thỏa thuận với người dùng về yêu cầu nào trong số những yêu cầu đó sẽ được đưa vào bản phát hành tiếp theo của phần mềm.

Sử dụng sự thay đổi theo yêu cầu công cụ quản lý giúp đỡ để quản lý "phạm vi creep". Nó giúp cả hai bên đánh giá công việc bổ sung cần thiết trên phần mềm và giữ toàn bộ quá trình được tổ chức.

Nếu được thực hiện đúng, sẽ có bản ghi các thay đổi được yêu cầu, các thay đổi đã thực hiện và các thay đổi hiện đang được xử lý. Cải tiến phần mềm sẽ được ưu tiên.

+1

Thực hiện tốt. :) "Nếu người dùng khám phá ra rằng họ cần phải thay đổi các yêu cầu" ... nên là "Khi người dùng ..." – Russell

2

Nó tương tự hoặc giống với công cụ theo dõi lỗi. Những điều có thể xảy ra bao gồm:

  • Có người trông theo yêu cầu (các "ai đó" có thể là một người quản lý sản phẩm, quản lý dự án, và/hoặc nhóm phát triển lãnh đạo) và quyết định liệu có nên xem xét nó thêm

  • Nếu yêu cầu không bị từ chối ngay lập tức thì yêu cầu đó được chuyển cho ai đó (có thể là kiến ​​trúc sư hoặc trưởng nhóm phát triển), người sẽ đánh giá tính khả thi của nó và nói nỗ lực/lịch/nguồn lực cần thiết để thực hiện nó là

  • Nếu lợi ích mong đợi vượt quá chi phí dự kiến, vv thì nó sẽ là appr được thêm vào lịch phát triển và cuối cùng được chỉ định cho nhà phát triển có sẵn

  • Vì nó trải qua các giai đoạn khác nhau này và được nhiều người xem xét, mọi người sẽ thêm ý kiến ​​của họ và/hoặc chi tiết bổ sung và tài liệu: ví dụ vào thời điểm cuối cùng người tiếp cận QA đã kiểm tra việc triển khai thực hiện thay đổi được yêu cầu, nhân viên QA sẽ không chỉ thấy yêu cầu ban đầu mà còn nhận xét từ người quản lý dự án, kiến ​​trúc sư, nhà phát triển, v.v.

0

Đó là cơ bản một cơ sở dữ liệu giúp giữ tất cả các mục 'todo' của bạn khỏi rơi khỏi bàn.

Và cũng như một lợi ích rìa, cung cấp phương tiện đánh giá mức độ phát triển của nhóm phát triển của bạn.

0

bạn có thể sử dụng một công cụ quản lý vấn đề (bug tracker) như một công cụ thay đổi yêu cầu

hoặc bạn có thể đi lo-fi và sử dụng một giao thức để thay thế (tức là chỉ cần một thủ tục được viết ra trong tài liệu word)

những gì tôi sử dụng với khách hàng của tôi là sự kết hợp của SLA (Service Level Agreement) và thay đổi theo yêu cầu giao thức: 'Maintenance Blocks' - Managing Change Requests

--LM

1

một ví dụ tuyệt vời của một công cụ thay đổi quản lý yêu cầu là ứng dụng Tổng đài http://www.switchboardsite.com. Kiểm tra nó ra để có được một cảm giác về cách quản lý yêu cầu thay đổi hoạt động.

Các vấn đề liên quan