Software Requirements. First Edition – MS Press. Chương 3: Good Practices cho công nghệ yêu cầu – Kỳ 1

Tác giả: Karl E. Wiegers

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

Lời người dịch
Con người hiện đại thực hiện công việc của mình theo cách sau: hình thành lý thuyết trước và sau đó dùng lý thuyết này để hướng dẫn cho hành động. Tuy nhiên, mọi lý thuyết khi thực hiện các tính toán – hiểu theo nghĩa rộng, không phải chỉ là tính toán toán học – đều chỉ xét đến những tham số cơ bản, cốt lõi mà tạm bỏ qua những tham số chi tiết hoặc tham số đặc thù. Nguyên nhân chủ yếu vì nếu tính đến những tham số đó thì sự tính toán sẽ quá phức tạp, không thể kham nổi. Vì vậy, khi áp dụng lý thuyết, những người làm thực hành mới điều chỉnh dần lý thuyết cùng với sự tham gia của các tham số chi tiết và đặc thù của môi trường thực tế. Kết quả đạt được sau những điều chỉnh lý thuyết trên hàng trăm, hàng nghìn ứng dụng thực tế là những gì được gọi là “best practices”các hướng dẫn thực hành tốt nhất. Tuy nhiên, trong nhiều trường hợp, vì nhiều lý do, người ta chỉ gọi những hướng dẫn thực hành đó là “good practices”, như gần đây báo chí Việt Nam hay nói tới các hướng dẫn thực hành nhà thuốc tốt (GPP – Good Pharmacy Practices), hay các hướng dẫn thực hành nông nghiệp tốt (GAP – Good Agriculture Practices).

Trong Chương 3 này, tác giả sẽ trình bày các hướng dẫn thực hành tốt cho công nghệ yêu cầu  đã được đúc rút từ rất nhiều dự án IT thực tế, bao gồm 40 practices được chia thành 7 nhóm: trang bị tri thức, quản lý yêu cầu, quản lý dự án, suy luận yêu cầu, phân tích yêu cầu, đặc tả yêu cầu, kiểm tra yêu cầu.

Tiếp theo tác giả trình bày một thứ tự ưu tiên và mức độ khó khăn khi áp dụng mỗi practice để thực thi công nghệ yêu cầu. Từ đó trong Chương 4, tác giả sẽ trình bày cách thức thiết lập một lộ trình cải tiến quy trình yêu cầu dựa trên 40 practices này.

Sau đó, mỗi practice được mô tả ngắn gọn và chỉ ra chương nào trong cuốn sách sẽ thảo luận chi tiết về nó để người đọc bám sát ý tưởng cần thực hiện.

Một số lưu ý về thuật ngữ tác giả dùng:

  • Thuật ngữ “giáo dục” (educate), ví dụ “Giáo dục cho đại diện người dùng và các nhà quản lý về yêu cầu”. Tác giả muốn nhấn mạnh mục đích của giáo dục là tạo ra nhận thức về tầm quan trọng của một vấn đề, tất cả mọi người phải hiểu lý do vì sao phải triển khai vấn đề đó, việc thực thi vấn đề không được đặt ra.
  • Thuật ngữ “đào tạo” (train), ví dụ “Đào tạo các nhà phân tích yêu cầu”. Tác giả muốn nhấn mạnh mục đích của đào tạo là hướng dẫn thực thi một vấn đề.
  • Thuật ngữ “truyền thông” (communication) được tác giả dùng để chỉ sự trao đổi nhằm tạo ra sự thông hiểu lẫn nhau giữa những người liên quan trong cùng một dự án (stakeholders) – khách hàng, người phân tích, người phát triển, chủ đầu tư dự án,…

Nhiều thuật ngữ thông dụng trong công nghệ phần mềm, người dịch vẫn để nguyên tiếng Anh. Chương này sẽ được đưa thành 2 kỳ.

Mười năm trước đây, tôi rất hâm mộ các phương pháp luận phát triển phần mềm – tập hợp các mô hình và kỹ thuật nhằm giúp tôi giải quyết các thách thức của những dự án phần mềm. Ngày nay, tôi quan tâm hơn đến việc xác định và ứng dụng cái được gọi là “best practices”. Thuật ngữ “best practices”, mặc dù còn gây nhiều tranh cãi, nhưng nó có ý nghĩa là: anh nhận được một lời khuyên gọi là “best” và dựa trên đó anh đạt được kết quả tốt hơn cho công việc của mình. Cách tiếp cận này là sự tổng kết thành công và thất bại của các chuyên gia về rất nhiều dự án ở rất nhiều tổ chức khác nhau (Brown 1996). Từ đó họ rút ra được các yếu tố chung, tổng quát mang lại thành công cho nhiều dự án khác nhau, các yếu tố đó gọi là “best practices”. Tuy nhiên, đầu đề của chương này là “Good practices cho công nghệ yêu cầu” chứ không phải “best practices”. Chương này sẽ trình bày hơn 40 practices trong 7 nhóm khác nhau.

Table 3-1

Table 3-1-Cont

Không phải tất cả các mục trên đều được tán thành là các best practices trong công nghiệp phần mềm (industry best practices). Tôi không cho rằng tất cả các mục đó đều được đánh giá một cách hệ thống vì mục đích này. Tuy nhiên, tôi và nhiều đồng nghiệp khác đã thấy các kỹ thuật này đạt hiệu quả (Sommerville and Sawyer 1997). Mỗi practice sẽ được mô tả ngắn gọn và chỉ ra chương nói về nó trong cuốn sách này hoặc các nguồn tham khảo khác.

Bảng 3-2 nhóm các practices đó theo một thứ tự ưu tiên tương đối khi thi công dự án và độ khó tương đối khi ứng dụng các practices đó. Khi tất cả các practices đó phát huy tác dụng thì bạn có thể gặt hái kết quả – xác suất sự thành công của dự án sẽ lớn hơn.

Table 3-2

Đừng cố gắng ứng dụng tất cả các kỹ thuật trên vào dự án sắp tới của bạn. Thay vì vậy, hãy suy nghĩ về các good practices đã mô tả ở đây như là các mục mới để thêm vào requirements tool kit của bạn. Bạn có thể bắt đầu bằng cách ứng dụng ngay một số practices, ví dụ các practices về quản trị thay đổi mà không cần quan tâm gì đến việc dự án của bạn tiến hành đến đâu.

Chương 4 giới thiệu các cách tiếp cận bạn có thể sử dụng để đánh giá các practices bạn đang dùng trong dự án hiện tại liên quan đến công nghệ yêu cầu và sáng tạo ra một lộ trình (road map) để thực hiện cải tiến quy trình yêu cầu được lựa chọn ra từ các practices ở đây (Chương 3) và ở Chương 4.

I. TRI THỨC (KNOWLEDGE)

Chỉ một số ít nhà phát triển phần mềm được đào tạo một cách chính thức các kỹ năng và kỹ thuật cần thiết cho công nghệ yêu cầu. Tuy vậy, trên thực tế một số nhà phát triển vẫn phải đóng vai trò phân tích viên yêu cầu khi phải làm việc với khách hàng để thu thập, phân tích và tài liệu hoá yêu cầu. Một số khoá đào tạo có thể giúp các nhà phát triển bổ sung các kỹ năng còn thiếu này, giúp họ làm tốt vai trò phân tích viên yêu cầu.

Do quy trình yêu cầu là một quy trình chủ chốt đối với sự thành công của dự án, nên tất cả những người liên quan đến dự án (stakeholders) cần phải có một hiểu biết cơ bản về sự hợp lý, tầm quan trọng, các practices của công nghệ yêu cầu. Tổ chức một khoá đào tạo ngắn trong 1 hoặc 2 ngày cho những người liên quan (nhà phát triển, người làm marketing, khách hàng,  kiểm thử viên, các nhân viên quản lý) về quy trình yêu cầu khái quát có thể là một hoạt động xây dựng nhóm hiệu quả. Tất cả những người tham gia sẽ có một hiểu biết tốt hơn về những thách thức mà các đồng nghiệp của họ phải đối mặt, họ sẽ biết cách phối hợp tốt hơn với các đồng nghiệp vì sự thành công của dự án. Tương tự, các nhà phát triển sẽ có được các khái niệm và thuật ngữ của miền ứng dụng.

Đào tạo các nhà phân tích yêu cầu (Train requirements analysts)

Tất cả các nhà phát triển sẽ được đào tạo các kiến thức cơ bản trong công nghệ yêu cầu, nhưng những người trong số họ chịu trách nhiệm chính về nắm bắt, tài liệu hoá, phân tích các yêu cầu người dùng cần được đào tạo kỹ hơn về các hoạt động này. Các nhà phân tích yêu cầu có kỹ năng được tập hợp lại, họ cần có kỹ năng giao tiếp tốt, hiểu biết miền ứng dụng và có thể lựa chọn các công cụ xử lý yêu cầu (tool kit) trợ giúp cho công việc của mình.

Giáo dục đại diện người dùng và các nhà quản lý về yêu cầu phần mềm (Educate user representatives and managers about software requirements)

Đại diện người dùng sẽ tham gia vào các hoạt động triển phần mềm, họ sẽ được giáo dục 1 ngày về công nghệ yêu cầu cùng các nhà quản lý bên phát triển và bên khách hàng. Họ sẽ hiểu được tầm quan trọng của yêu cầu, các hoạt động và các bán thành phẩm cần chuyển giao cho nhóm yêu cầu, các rủi ro xảy ra nếu sao nhãng quy trình yêu cầu.

Đào tạo các nhà phát triển về các khái niệm của miền ứng dụng (Train developers in application domain concepts)

Để giúp các nhà phát triển có được hiểu biết về miền ứng dụng, hãy thu xếp cho họ các khoá học ngắn về các hoạt động nghiệp vụ của khách hàng, về các thuật ngữ, các mục tiêu của sản phẩm cần được sản xuất. Việc này sẽ làm giảm sự hỗn độn, giảm sự rối loạn truyền thông (miscommunication) giữa các bên liên quan và giảm các công việc phải làm lại sau này. Bạn cũng có thể giải thích thêm với các nhà phát triển về các biệt ngữ và các khái niệm nghiệp vụ quan trọng trong diễn biến của dự án sau này. Người trợ giúp sản phẩm (product champion) sẽ đóng vai trò này.

Tạo ra một bảng thuật ngữ của dự án (Create a project glossary)

Để giảm bớt các vấn đề truyền thông, hãy viết một bảng thuật ngữ định nghĩa tất cả các khái niệm chuyên môn trong miền ứng dụng của dự án. Trong đó gồm cả các thuật ngữ có nhiều cách sử dụng, cũng như các nghĩa cụ thể và thông dụng của nó.

II. SUY LUẬN YÊU CẦU (REQUIREMENTS ELICITATION)

(Mục này nói về các nguồn có thể phát sinh yêu cầu – ND)

Chương 1 đã thảo luận về 3 mức yêu cầu: yêu cầu kinh doanh, yêu cầu người dùng, yêu cầu chức năng (business, user, functional). Chúng xuất hiện từ các nguồn khác nhau, trong những thời điểm khác nhau của dự án, nhằm đáp ứng các mục đích khác nhau vì vậy cần được tài liệu hoá theo những cách khác nhau. Yêu cầu kinh doanh (business requirements) (hoặc còn gọi là tài liệu về tầm nhìn và phạm vi của sản phẩm) phải bao hàm bất cứ yêu cầu người dùng nào (hoặc use – cases nào), và tất cả các yêu cầu chức năng phải được lần vết tới yêu cầu người dùng. Bạn cũng cần phải luận ra các yêu cầu phi chức năng, ví dụ các thuộc tính chất lượng, từ những nguồn thích hợp. Bạn có thể tìm thông tin bổ sung về các chủ đề này trong các chương sau:

  • Chương 4 – Định nghĩa một thủ tục phát triển yêu cầu (Define a requirements development procedure)
  • Chương 6 – Viết tài liệu tầm nhìn và phạm vi dự án (Write a project vision and scope document)
  • Chương 7 – Xác định các lớp người dùng và các đặc tính của họ, lựa chọn người hỗ trợ sản phẩm cho mỗi lớp người dùng (Identify user classes and their characteristics; select product champions for each user class)
  • Chương 8 – Đề nghị đại diện người dùng xác định các use cases (Have user representatives identify use cases)
  • Chương 11 – Xác định các thuộc tính chất lượng và các yêu cầu phi chức năng khác (Determine quality attributes and other nonfunctional requirements)

Định nghĩa một thủ tục phát triển yêu cầu (Define a requirements development procedure)

Định nghĩa và tài liệu hoá các bước mà tổ chức của bạn dùng để thu thập, phân tích, đặc tả (specify) và kiểm tra yêu cầu. Hướng dẫn thực hiện theo các bước sẽ khiến nhà phân tích thực hiện công việc một cách nhất quán, khiến hoạt động thu thập yêu cầu và lập lịch biểu dễ dàng hơn.

Viết tài liệu tầm nhìn và phạm vi dự án (Write a project vision and scope document)

Tài liệu tầm nhìn và phạm vi dự án phải chứa các mục tiêu kinh doanh (business objectives) ở tầm cao của doanh nghiệp đối với sản phẩm. Tất cả các use cases và các yêu cầu chức năng cần phải sóng đôi với tài liệu này. Báo cáo tầm nhìn (vision statement) cấp cho tất cả những người tham gia dự án một hiểu biết chung về các mục tiêu của dự án. Định nghĩa phạm vi của dự án quyết định tính năng hoặc yêu cầu nào được đưa vào dự án.

Xác định các lớp người dùng và các đặc tính của họ (Identify user classes and their characteristics)

Để tránh bỏ qua nhu cầu của bất kỳ nhóm người dùng nào (user community), hãy xác định các nhóm khách hàng khác nhau đối với sản phẩm của bạn. Họ có thể khác nhau về tần suất sử dụng, các tính năng sử dụng, các mức ưu tiên. Hãy mô tả các khía cạnh công việc của họ hoặc các đặc tính cá nhân có thể ảnh hưởng đến thiết kế của sản phẩm.

Lựa chọn người hỗ trợ sản phẩm cho mỗi lớp người dùng (Select product champions for each user class)

Xác định ít nhất một người có thể giới thiệu chính xác các nhu cầu của mỗi lớp người dùng, người được hiểu như là người phát ngôn của lớp người dùng đó, người thay mặt lớp người dùng đó ra các quyết định liên quan đến yêu cầu. Việc này rất dễ khi phát triển các hệ thống thông tin nội bộ (internal information systems), nơi mà người dùng là những người bạn có thể quan hệ thân thiết. Nếu bạn phát triển các hệ thống thông tin thương mại, hãy xây dựng quan hệ tốt đẹp với các khách hàng chính hoặc các bên kiểm thử beta (beta test sites) để xác định những người hỗ trợ sản phẩm thích hợp. Người hỗ trợ sản phẩm phải liên tục tham gia dự án và ra quyết định ngay khi cần thiết.

Thành lập các nhóm tập trung của người dùng tiêu biểu (Establish focus groups of typical users)

Gặp gỡ các nhóm nhỏ đại diện cho người dùng đã sử dụng các phiên bản trước đây của sản phẩm hoặc đã sử dụng các sản phẩm tương tự, tập hợp các yêu cầu chức năng và phi chức năng của họ về sản phẩm hiện thời. Hãy tập trung làm việc với các nhóm có giá trị đối với sự phát triển thương mại của sản phẩm. Khác với người hỗ trợ sản phẩm, các thành viên của nhóm tập trung thường không phải là chủ thể ra quyết định.

Đề nghị đại diện người dùng xác định các use cases (Have user representatives identify use cases)

Tập hợp các mô tả của đại diện người dùng về các tác vụ (tasks) họ cần hoàn thành bằng phần mềm – các use cases. Hãy thảo luận về các tương tác và đối thoại giữa người dùng và hệ thống nhằm giúp người dùng hoàn thành mỗi tác vụ (task) của họ. Thông qua một mẫu tiêu chuẩn (standard template) để tài liệu hoá các use cases và trích xuất các yêu cầu chức năng từ use cases.

Tổ chức các phiên Phát triển ứng dụng chung (Hold Joint Application Development sessions)

Một phiên JAD là một hội thảo mở rộng, được tổ chức để trao đổi về sự cộng tác giữa nhà phân tích và các đại diện khách hàng để sản sinh ra các bản thảo tài liệu yêu cầu.

Phân tích workflow của người dùng (Analyze user workflow)

Quan sát người dùng thực hiện các tác vụ (tasks) của họ. Tạo ra các sơ đồ đơn giản (DFD…) phác thảo khi nào (when) thì người dùng có dữ liệu gì (what data) và họ xử lý dữ liệu như thế nào (how). Tài liệu hoá luồng quy trình nghiệp vụ (business process flow) sẽ giúp bạn xác định các use cases và các yêu cầu chức năng cho sản phẩm. Thậm chí bạn có thể xác định khách hàng có thật sự cần một hệ thống phần mềm mới để đáp ứng các mục tiêu nghiệp vụ của họ (business objectives) hay không (McGraw and Harbison 1997).

Xác định các thuộc tính chất lượng và các yêu cầu phi chức năng khác (Determine quality attributes and other nonfunctional requirements)

Xác định các thuộc tính chất lượng (yêu cầu phi chức năng) sẽ giúp sản phẩm của bạn đáp ứng, thậm chí đáp ứng quá mức các kỳ vọng của khách hàng. Các đặc tính đó gồm: hiệu suất, độ tin cậy, khả năng dễ sử dụng và nhiều thứ khác nữa (performance, reliability, usability, …). Tầm quan trọng tương đối của các thuộc tính chất lượng được xác định bởi người dùng.

Kiểm tra các báo cáo vấn đề của hệ thống hiện tại để tìm kiếm các ý tưởng yêu cầu (Examine problem reports of current systems for requirement ideas)

Các báo cáo vấn đề và đề xuất mở rộng từ khách hàng là nguồn cung cấp phong phú các ý tưởng về tính năng và cải tiến (features and improvements) sẽ được đưa vào một phiên bản nào đó của hệ thống mới. Người hỗ trợ hệ thống hiện tại cũng có thể cung cấp các gợi ý có giá trị đối với quy trình thu thập yêu cầu.

Sử dụng lại yêu cầu trong dự án (Reuse requirements across projects)

Nếu khách hàng đề xuất tính năng tương tự với tính năng đã có trong hệ thống cũ thì hãy cân nhắc liệu có thể sử dụng lại components đã có liên quan đến tính năng đó hay không.

(Còn tiếp)

15/10/2009

Advertisements

2 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

2 responses to “Software Requirements. First Edition – MS Press. Chương 3: Good Practices cho công nghệ yêu cầu – Kỳ 1

  1. ban_mai

    hi anh.cam on anh nhieu!

  2. thaodv

    Cảm ơn bác Thịnh nhiều nhé. Bài dịch của bác rất hay.

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