Software Requirements. First Edition – MS Press. Chương 4: Cải tiến quy trình yêu cầu của bạn – Kỳ 2

Tác giả: Karl E. Wiegers

Người dịch: Hoàng Xuân Thịnh

V. TÀI SẢN QUY TRÌNH YÊU CẦU (REQUIREMENTS PROCESS ASSETS)

Nếu bạn muốn các dự án được hoàn thành với các kết quả tốt hơn thì bạn cần có các quy trình hiệu quả trên toàn bộ các giai đoạn của công nghệ yêu cầu: suy luận, phân tích, đặc tả, kiểm tra, quản lý. Tập hợp các quy trình thực hiện các công việc trên được gọi là tài sản quy trình. Một quy trình hướng dẫn các hành động mà bạn cần thực hiện để có được các kết quả mà bạn cần chuyển giao; tài sản quy trình giúp các bên liên quan tới dự án thực hiện nhất quán và hiệu quả công việc của họ. Tài sản quy trình gồm các loại tài liệu sau:

Loại tài liệu

Nội dung

Danh sách kiểm tra

(Checklist)

Một danh sách liệt kê các hoạt động, các kết quả chuyển giao (deliverables), hoặc các đầu mục khác (items) được đánh dấu hoặc được kiểm tra (noted or verified). Checklist đảm bảo những ai thực hiện công việc không bỏ qua bất cứ chi tiết quan trọng nào.
Ví dụ (Example) Minh hoạ cho một bán thành phẩm cụ thể. Tích lũy các ví dụ tốt hơn theo thời gian để minh họa tốt hơn cho những dự án sau.
Kế hoạch

(Plan)

Tài liệu khái quát về việc làm thế nào để đạt được một mục đích và những gì cần làm để đạt được mục đích đó.
Chính sách

(Policy)

Một nguyên tắc hướng dẫn thiết lập sự kỳ vọng về các hành vi, hành động, các kết quả chuyển giao. Các quy trình cần phải sóng đôi với các chính sách.
Thủ tục

(Procedures)

Mô tả từng bước một về các công việc (tasks) nối tiếp nhau nhằm hoàn thành một hoạt động (activity). Mô tả các công việc (tasks) được thực hiện và chỉ ra các vai trò (roles) sẽ thực hiện chúng. Tránh kèm các thông tin hướng dẫn (tutorial information) trong một thủ tục.
Mô tả quy trình (Process description) Một định nghĩa được ghi thành văn về một tập hợp các hoạt động cần thực hiện nhằm đạt được mục đích nào đó. Mô tả quy trình có thể bao gồm mục tiêu của quy trình, các mốc chính (key milestones), người tham gia, thời gian thích hợp để thực hiện hoạt động, các bước truyền thông, các kết quả mong muốn, dữ liệu đầu vào và đầu ra của quy trình (Caputo 1998).
Mẫu

(Template)

Một mẫu được sử dụng như một hướng dẫn để sản xuất một bán thành phẩm trọn vẹn (complete work product). Các templates cho các tài liệu chính của dự án nhắc bạn không bỏ qua những gì quan trọng. Một template tốt sẽ cung cấp nhiều cách thức nắm bắt và tổ chức thông tin. Các hướng dẫn trong template giúp người dùng sử dụng hiệu quả template hơn. Hình 4-4 chính là một template.

Hình 4-6 xác định một số tài sản quy trình mà bạn cần có để phát triển và quản lý các yêu cầu hiệu quả hơn.

Tài sản quy trình phát triển yêu cầu

(Requirements Development

Process Assets)

Tài sản quy trình quản lý yêu cầu

(Requirements Management

Process Assets)

  • Template tầm nhìn và phạm vi của dự án (Project vision and Scope Template)
  • Thủ tục phát triển yêu cầu (Requirements Development Procedure)
  • Thủ tục phân bổ yêu cầu (Requirements Allocation Procedure)
  • Template tình huống sử dụng (Use case template)
  • Template đặc tả yêu cầu phần mềm (SRS template)
  • Thủ tục xếp thứ tự ưu tiên các yêu cầu (Requirements Prioritization Procedure)
  • Các checklists thanh tra SRS và Use cases (SRS and Use case Inspection Checklists)
  • Thủ tục kiểm soát thay đổi (Change Control Procedure)
  • Thủ tục ban kiểm soát thay đổi (Change Control Board Procedure)
  • Checklists và template phân tích ảnh hưởng thay đổi yêu cầu (Requirements Change Impact Analysis Checklist and Template)
  • Thủ tục giám sát tình trạng yêu cầu (Requirements Status Tracking Procedure)
  • Template ma trận lần vết yêu cầu (Requirements Traceability Matrix Template)

HÌNH 4-6. Các tài sản quy trình chính cho phát triển và quản lý yêu cầu

Các thủ tục được liệt kê trong Hình 4-6 không cần thiết được viết thành các tài liệu riêng rẽ. Ví dụ, một mô tả về quy trình quản lý yêu cầu tổng thể (overall requirements management process) có thể bao gồm thủ tục kiểm soát thay đổi, thủ tục giám sát tình trạng, và danh sách kiểm tra (checklist) phân tích ảnh hưởng. Ví dụ về một mô tả quy trình quản lý yêu cầu xem Phụ lục J của CMM Implementation Guide (Caputo 1998).

Sau đây là các mô tả ngắn gọn về mỗi tài sản quy trình trong Hình 4-6, cùng các tham chiếu tới các chương sẽ thảo luận chi tiết về chúng. Cần ghi nhớ rằng đối với mỗi dự án đều phải “may đo lại” các thủ tục để đáp ứng các nhu cầu cụ thể của tổ chức.

1. TÀI SẢN QUY TRÌNH PHÁT TRIỂN YÊU CẦU (REQUIREMENTS DEVELOPMENT PROCESS ASSETS)

Template tầm nhìn và phạm vi của dự án (Project vision and Scope Template)

Tài liệu tầm nhìn và phạm vi (vision and scope) định nghĩa nền tảng ý tưởng (conceptual foundation) của dự án và cung cấp một tham chiếu để ra quyết định về các thứ tư ưu tiên của yêu cầu và các thay đổi. Tầm nhìn và phạm vi (vision and scope) là một mô tả ở cấp độ cao và chính xác về các yêu cầu kinh doanh (business requirements) của phần mềm cần làm.  Viết tài liệu này theo một cách nhất quán sẽ đảm bảo tất cả các vấn đề đúng (right issues) đều được cân nhắc khi ra quyết định thực hiện dự án. Chương 6 gợi ý một template cho tài liệu này.

Thủ tục phát triển yêu cầu (Requirements Development Procedure)

Thủ tục này mô tả làm thế nào để định danh các khách hàng và các kỹ thuật suy luận yêu cầu từ họ. Nó cũng mô tả các tài liệu yêu cầu khác nhau và mô hình phân tích thích hợp. Thủ tục có thể chỉ ra loại thông tin kèm theo mỗi yêu cầu, ví dụ mức ưu tiên, độ ổn định dự kiến của yêu cầu, hoặc số phiên bản phần mềm dự định. Thủ tục cũng xác định các bước mà dự án phải thực hiện để phân tích và kiểm tra yêu cầu. Nó cũng bao gồm các bước cần thiết để chấp nhận SRS và thiết lập ranh giới yêu cầu.

Thủ tục phân bổ yêu cầu (Requirements Allocation Procedure)

Phân bổ các yêu cầu sản phẩm ở cấp độ cao (high-level product requirements) thành các hệ thống con cụ thể là việc quan trọng khi phát triển các hệ thống bao gồm cả phần cứng và phần mềm hoặc các sản phẩm phần mềm phức hợp (complex software product) chứa nhiều hệ thống con (Nelsen 1990). Phân bổ được thực hiện sau khi các yêu cầu mức hệ thống đã được xác định và kiến trúc hệ thống đã được định nghĩa. Thủ tục này chứa thông tin về việc làm thế nào để thực hiện sự phân bổ nhằm đảm bảo các chức năng đúng (right functionality) được gán cho đúng thành phần hệ thống (system component) thích hợp. Thủ tục cũng mô tả làm thế nào các yêu cầu đã phân bổ lần vết được về yêu cầu hệ thống gốc và các yêu cầu liên quan trong các hệ thống con khác.

Template tình huống sử dụng (Use case template)

Mẫu use case cung cấp một cách thức tiêu chuẩn để tài liệu hoá mỗi công việc (tasks) mà người dùng mong muốn thực hiện với hệ thống. Một định nghĩa use-case gồm một mô tả ngắn về công việc (task), mô tả về các hành vi có thể lựa chọn (alternative behaviors) hoặc các loại trừ đã biết (known exceptions) cần phải được xử lý,  thông tin kèm theo đặc tả theo công việc (task) người dùng. Use-cases có thể được phác thảo (elaborate) theo các yêu cầu chức năng (functional requirements) riêng biệt trong SRS. Bạn cũng có thể kết hợp các template use-case và SRS thành một tài liệu duy nhất chứa các yêu cầu người dùng (user requirements) và yêu cầu chức năng (functional requirements). Chương 8 đề xuất một khuôn dạng (format) use-case template.

Template đặc tả yêu cầu phần mềm (SRS template)

SRS template (software requirement specification template) cung cấp một cách thức có cấu trúc để tổ chức các yêu cầu chức năng (functional requirements) và yêu cầu phi chức năng. Một tổ chức thông qua một SRS template tiêu chuẩn sẽ nâng cao rất nhiều chất lượng của yêu cầu. Bạn có thể thông qua nhiều templates khác nhau để thích hợp với nhiều loại hình dự án khác nhau, tránh làm kiểu “one size fits all” (một kích thước cho tất cả). Chương 9 mô tả một SRS template.

Thủ tục xếp thứ tự ưu tiên các yêu cầu (Requirements Prioritization Procedure)

Bạn tôi Matt mô tả giai đoạn cuối của một dự án phần mềm điển hình là “giai đoạn cắt xén nhanh” khi chức năng đã được lập kế hoạch bị xoá bỏ vào phút cuối để đáp ứng hạn cuối của lịch biểu. Để cắt giảm phạm vi tại bất cứ giai đoạn nào, chúng ta cũng phải biết tính năng nào, use-cases nào, yêu cầu chức năng (functional requirements) nào có mức ưu tiên thấp nhất. Chương 13 đề xuất một thủ tục được xếp thứ tự ưu tiên để bạn tham khảo cùng nhiều thông tin khác liên quan đến rủi ro kỹ thuật, chi phí tương đối của việc cài đặt mỗi use-case, mỗi tính năng hoặc yêu cầu.

Các checklists thanh tra SRS và use-case (SRS and use -case Inspection Checklists)

Thanh tra chính thức tài liệu yêu cầu là một biện pháp quan trọng để đảm bảo chất lượng. Một inspection checklist định danh được khá nhiều trong số các lỗi thông thường được tìm thấy ở tài liệu yêu cầu. Chương 14 đề xuất các ví dụ về SRS inspection chectlist và use-case inspection checklist.

2. TÀI SẢN QUY TRÌNH QUẢN LÝ YÊU CẦU (REQUIREMENTS MANAGEMENT PROCESS ASSETS)

Thủ tục kiểm soát thay đổi (Change control procedure)

Một quy trình kiểm soát thay đổi có thể làm giảm các hỗn độn trong dự án bởi các thay đổi yêu cầu không kiểm soát được và không biết bao giờ thì ngừng. Thủ tục kiểm soát thay đổi định nghĩa cách một yêu cầu mới hoặc một sửa đổi yêu cầu cũ được đề xuất, được truyền thông, được đánh giá và được quyết định chấp nhận hay không. Kiểm soát thay đổi thường được trợ giúp bởi một công cụ giám sát nhưng một công cụ thì không thay thế cho quy trình được. Chương 17 chỉ ra quy trình kiểm soát thay đổi một cách chi tiết.


Thủ tục ban kiểm soát thay đổi (Change Control Board Procedure)

Ban kiểm soát thay đổi (CCB) là một nhóm bao gồm một số người liên quan đến dự án phần mềm (stakeholders) ra các quyết định liên quan đến thay đổi yêu cầu, liệu các thay đổi đó được chấp thuận hay từ chối. Thủ tục CCB mô tả cơ cấu và hoạt động của nhóm. Các hoạt động chính của CCB là phân tích ảnh hưởng của các thay đổi, ra quyết định về mỗi thay đổi, thông báo đến tất cả những ai liên quan về các thay đổi. Chương 17 định nghĩa về cơ cấu và chức năng của CCB.

Checklists và templates phân tích ảnh hưởng thay đổi yêu cầu (Requirements Change Impact Analysis Checklist and Template)

Ước lượng chi phí và ảnh hưởng của một thay đổi là việc làm quan trọng trước khi chấp nhận hoặc từ chối thay đổi đó. Như được minh hoạ trong Chương 18, một checklist phân tích ảnh hưởng chứa nhiều câu hỏi đòi hỏi bạn suy nghĩ về các công việc (tasks) có thể, các hiệu ứng phụ (side effects), các rủi ro tiềm tàng liên quan tới sự thực hiện một thay đổi yêu cầu cụ thể. Chương 18 cung cấp một template cho vấn đề này.

Thủ tục giám sát tình trạng yêu cầu (Requirements Status Tracking Procedure)

Quản lý yêu cầu bao gồm giám sát và báo cáo tình trạng của mỗi yêu cầu chức năng (functional requirement) và điều kiện mà theo đó trạng thái này có thể thay đổi. Bạn nên sử dụng một cơ sở dữ liệu hoặc một công cụ quản lý yêu cầu để giám sát một số lượng lớn các yêu cầu trong một hệ thống phức tạp. Thủ tục này cũng mô tả các báo cáo mà bạn cần phải có để giám sát bất cứ khi nào có thể. Chương 16 nói rõ về vấn đề này.

Template ma trận lần vết yêu cầu (Requirements Traceability Matrix Template)

Ma trận lần vết yêu cầu liệt kê tất cả các yêu cầu chức năng (functional requirements) từ SRS, cùng các thành phần thiết kế (design components) của mỗi yêu cầu, các tệp nguồn (source files) và thủ tục (procedures) cài đặt các yêu cầu, các tình huống kiểm thử (test cases) kiểm tra tính đúng đắn của việc cài đặt. Ma trận lần vết yêu cầu cũng sẽ xác định người dùng hoặc yêu cầu hệ thống mà từ đó yêu cầu chức năng (functional requirements) được dẫn xuất ra. Chưưng 18 đề xuất một template ma trận lần vết yêu cầu.

VI. LỘ TRÌNH CẢI TIẾN QUY TRÌNH YÊU CẦU (REQUIREMENTS PROCESS IMPROVEMENT ROADMAP)

Cải tiến quy trình yêu cầu không phải là công việc dễ dàng. Những cách tiếp cận không có định hướng đối với vấn đề này sẽ không bao giờ dẫn tới thành công cả. Bạn cần phải xây dựng một lộ trình để thực thi các practices yêu cầu đã cải tiến (improved requirements practices). Lộ trình này cần phải là một phần của kế hoạch cải tiến quy trình.

Do tình trạng của mỗi doanh nghiệp là khác nhau nên tôi không thể đưa ra một lộ trình phù hợp với tất cả (one-size-fits-all). Cách tiếp cận công thức hoá không thể thay thế cho tư duy và cảm nghĩ của chính bạn. Hình 4-7 minh họa một lộ trình cải tiến quy trình của một doanh nghiệp. Các kết quả kinh doanh mong muốn (desired business results) được thể hiện trong các hộp chữ nhật in đậm bên phải. Các hoạt động cải tiến chính được thể hiện trong các hộp khác và trong một số mốc (milestones) trung gian (hình vòng tròn). Thực hiện các hoạt động cải tiến quy trình trong các hộp chữ nhật từ trái qua phải. Sau khi bạn đã tạo ra một lộ trình tương tự, hãy chuyển cho mỗi người chịu trách nhiệm về một mốc, họ sẽ viết một kế hoạch hành động để đạt được mốc đó. Công việc sau đó là đưa kế hoạch vào hành động.

HÌNH 4-7. Lộ trình mẫu về cải tiến quy trình yêu cầu.
Các bước tiếp theo
  • Hoàn thành các Bảng tự đánh giá Requirements Practices hiện tại trong Phụ lục. Xác định 3 cơ hội cải tiến requirements practices cao nhất của bạn căn cứ trên các hạn chế của quy trình hiện tại.
  • Xác định trong số các tài sản quy trình công nghệ yêu cầu ở Hình 4-6, tài sản quy trình nào chưa thực sự hữu ích trong tổ chức nhưng bạn lại nghĩ nó vẫn được sử dụng tốt.
  • Dựa trên 2 bước trên, xây dựng một lộ trình cải tiến quy trình yêu cầu như template ở Hình 4-7. Giao cho mỗi ai đó thực hiện một mốc trên lộ trình. Yêu cầu mỗi người viết kế hoạch hành động để đạt được mốc đó, sử dụng template về kế hoạch hành động trong Hình 4-4. Giám sát tiến độ thực hiện kế hoạch cải tiến.
Advertisements

10 phản hồi

Filed under Quản lý yêu cầu phần mềm, Tủ sách Công nghệ thông tin

10 responses to “Software Requirements. First Edition – MS Press. Chương 4: Cải tiến quy trình yêu cầu của bạn – Kỳ 2

  1. ban_mai

    Anh ơi,có thể giải thích rõ về UML được hok anh,em ko bit gì về nó hết!

  2. sata2009blog

    Xin chào ban_mai, câu hỏi của em có thể được trả lời ngắn thế này. Trên thực tế, trong bất cứ lĩnh vực công việc nào, người ta cũng phải làm việc chung cùng nhau. Mà để làm việc chung thì cần thông hiểu nhau, mà để thông hiểu nhau thì mỗi người đều cần thể hiện suy nghĩ của mình ra ngoài cho người kia thấy. Cái “vật” được dùng để thể hiện suy nghĩ của mình ra ngoài đó được gọi là ngôn ngữ. Ví dụ, người Việt mình có 26 chữ cái và một số quy tắc ngữ pháp là đủ để hình thành ngôn ngữ tự nhiên là tiếng VN dùng trong trao đổi hàng ngày, như mẹ bảo “Con đi chợ đi” thì con phải hiểu là đi chợ chứ không phải đi chơi chẳng hạn. Nhưng ngôn ngữ nhiên lại không đủ để thể hiện các suy nghĩ của con người về âm nhạc, để thể hiện các giai điệu nhạc các nhạc sỹ cần 7 nốt nhạc và các quy tắc sử dụng chúng, chẳng hạn không thể chỉ dùng ngôn ngữ tự nhiên để thể hiện bản nhạc “Chiều biên giới”. Tương tự, các kỹ sư IT cũng có ngôn ngữ của riêng mình để thể hiện các ý tưởng xây dựng phần mềm, một trong số ngôn ngữ đó là UML – Ngôn ngữ mô hình hóa thống nhất. Dùng UML kỹ sư phần mềm có thể thể hiện được tình huống “người môi giới chứng khoán thực hiện một hành động môi giới cho khách hàng” đủ để mã hóa tình huống này vào một phần mềm chứng khoán. UML chỉ là một trong số các ngôn ngữ xây dựng phần mềm thôi, hiện có thể nói nó là ngôn ngữ thể hiện ý tưởng của các kỹ sư phần mềm tốt nhất so với các ngôn ngữ khác. Thân chào em.

  3. bài viết anh rất hay.
    chương 9 chưa viết hả anh?
    khi nào có chương 9 vậy anh?
    em rất quan tâm đến vấn đề này.

  4. sata2009blog

    Các chương sau sẽ lần lượt đăng lên em ạ. Để tải bản in lần 2 (anh đang dùng bản lần 1), em search đúng tên sách và tên tác giả là ra thôi. Cám ơn em.

  5. Hong Pham

    Bây giờ em mới nhập môn với use case requirement, chưa biết học từ đâu cả. Anh có thể hệ thống basic cho em và mọi người được ko? Thank you !!!

  6. sata2009blog

    Cám ơn em đã tin cậy, nói về cái này sẽ mất rất nhiều thời gian, ngay bây giờ thì anh chưa thể viết gì được về UC, sau này chắc sẽ đề cập đến trên satablog2. Chúc vui.

  7. Trong Tung

    Trước đây đọc các sách dịch ở VN về đề tài công nghệ thường rất khó chịu, vì dịch không rõ nghĩa và cũng không làm cho người đọc hiểu được ý chính của tài liệu! Thường chấp nhận mò mẫm đọc tài liệu tiếng anh cho chắc!
    Tuy nhiên tình cờ đọc được chương Một và chương Hai trên phần đăng của anh Thịnh, thấy rất hay!
    Anh Thịnh dịch rất sát nghĩa và có vẻ anh rất am hiểu trong vấn đề requirement! Đọc phần anh dịch mình hiểu được rất nhiều điều mới!
    Mong rằng anh sẽ đi được hết cuốn sách này, từ đó có được một tài liệu chuẩn để giúp cho mọi người hiểu biết nhiều hơn!
    Rất biết ơn về sự đóng góp của anh!

  8. sata2009blog

    Cám ơn bạn Trọng Tùng. Tôi đã dịch xong toàn bộ cuốn sách này, hiện đang duyệt lại bản thảo và sẽ đưa toàn bộ lên satablog2. Chúc bạn khỏe!

  9. Kieuvo

    Thật là 1 tài liệu hay. Tôi đang rất cần nó. Cám ơn anh đã đăng lên cho chúng tôi có tài liệu tìm hiểu rõ hơn.

    Anh có thể cho tôi xin link softcopy về cuốn sách này không a. Bản tiếng Anh cũng được.

    Cám ơn anh nhiều.

  10. tài liệu rất hay, thanks anh.
    Hi vọng anh sẽ tiếp tục dịch nhiều tài liệu nữa cho mọi người tham khảo!

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Đăng xuất / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Đăng xuất / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Đăng xuất / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Đăng xuất / Thay đổi )

Connecting to %s