Category Archives: Quản lý yêu cầu phần mềm

Software Requirements. First Edition – MS Press. Chương 5 – Yêu cầu phần mềm và quản lý rủi ro

Tác giả: Karl E. Wiegers

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

Dave, quản lý dự án của Chemical Tracking System tại Contoso Pharmaceuticals, đang có cuộc gặp với trưởng nhóm lập trình Helen và trưởng nhóm kiểm thử Ramesh. Tất cả đều đang vui mừng về dự án mới và họ nhớ lại một số vấn đề đã gặp trong dự án trước đây gọi là Pharm-Simulator.

“Hãy nhớ lại xem chúng ta đã không phát hiện ra người dùng ghét cái giao diện của Simulator như thế nào cho đến tận lần kiểm thử beta?” Helen hỏi. “Chúng ta đã mất 5 tuần để xây dựng lại hệ thống và kiểm thử lại. Tôi không hề muốn lặp lại việc đó một lần nữa.”

“Chả vui vẻ tí nào cả”, Dave nói. “Điều khó chịu nữa là người dùng nói họ muốn rất nhiều tính năng nhưng thực tế thì chả ai sử dụng sau này cả. Vậy hãy trao đổi với họ ít nhất 3 lần trước khi biết chúng ta có nên viết một tính năng nào đó, nếu không hãy bỏ nó đi ngay. Vớ vẩn thật!”

“Chúng ta đã xông vào Simulator quá sớm và không có đủ thời gian để viết các yêu cầu chi tiết,” Ramesh nhớ lại. “Một nửa thời gian của mấy ông kiểm thử là đi hỏi mấy ông lập trình xem chương trình có những tính năng nào để mà kiểm thử. Đến khi kiểm thử lại thấy là các chức năng mà mấy ông lập trình đã viết lại hoàn toàn  không phải là cái mà người dùng mong muốn.”

“Tôi thật sự bực bội khi bà quản lý bộ phận đề nghị xây dựng Pharm-Simulator đã ký trên bản yêu cầu mà chẳng hề đọc qua xem nó thế nào”, Dave thêm vào. “Cho đến khi chúng ta nhận được cả dòng thác các đề xuất và thay đổi yêu cầu từ những người thuộc bộ phận ấy. Chả có gì ngạc nhiên khi dự án chậm đến 4 tháng và chi phí thì hầu như tăng gấp đôi so với ngân sách. Nếu điều đó xảy ra lần nữa, chắc tôi điên mất!”

Ramesh đề nghị. “Hay là chúng ta lập một danh sách các vấn đề mà ta đã gặp trong Simulator từ đó ta dễ tránh được các vấn đề tương tự có thể có trong dự án Chemical Tracking System. Tôi đã đọc một bài báo về quản lý rủi ro phần mềm, họ khuyên chúng ta nên chỉ ra các rủi ro và phác thảo kế hoạch phòng ngừa chúng.”

“Tôi không biết về cái đó,” Dave nói. “Chúng ta đã học được rất nhiều từ Simulator và chúng ta đều không muốn các vấn đề tương tự như vậy từ dự án này nữa. Dự án này không lớn đến mức cần phải quản lý rủi ro. Nếu chúng ta viết ra những gì có thể gây rắc rối cho Chemical Tracking System thì điều đó có vẻ như là tôi không biết làm thế nào để thực hiện dự án một cách thành công. Tôi không muốn bất cứ những suy nghĩ trái chiều nào đối với dự án này. Chúng ta cần phải lập kế hoạch cho dự án thành công!”

Tiếp tục đọc

Advertisements

%(count) bình luận

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

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:

Tiếp tục đọc

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

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ỳ 1

Tác giả: Karl E. Wiegers

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

Lời người dịch
Trong chương này, căn cứ trên các hướng dẫn thực hành (practices) của chương 3, tác giả đề xuất với bạn một lộ trình cải tiến quy trình yêu cầu cho các dự án công nghệ thông tin của chính bạn.

Để thúc đẩy quyết tâm cải tiến của bạn, tác giả nêu ra hai lý do sau:

  • Quy trình yêu cầu là trái tim của một dự án thành công.
  • Quy trình yêu cầu ảnh hưởng đến nhiều nhóm người khác nhau liên quan đến dự án.

Với vai trò là trung tâm của dự án, tác giả kê ra các quy trình xoay quanh quy trình yêu cầu:

  • Quy trình lập kế hoạch dự án.
  • Quy trình giám sát và kiểm soát dự án.
  • Quy trình kiểm soát thay đổi.
  • Quy trình kiểm thử hệ thống.
  • Quy trình làm tài liệu cho người dùng hệ thống.
  • Quy trình thi công hệ thống.

Và sự ảnh hưởng của quy trình yêu cầu đối với những nhóm người liên quan (stakeholdes) tới dự án:

  • Nhóm marketing.
  • Nhóm hỗ trợ kỹ thuật.
  • Nhóm phụ trách người dùng.
  • Nhóm kỹ thuật phần cứng.

Sau khi đã nhấn mạnh lý do cải tiến quy trình yêu cầu, để tăng khả năng thành công, tác giả trình bày 4 nguyên lý – tức 4 cơ sở cho hành động cải tiến như sau:

  • Cải tiến quy trình cần được thực hiện theo kiểu tiến hoá, liên tục và có chu trình.
  • Con người và các tổ chức chỉ thay đổi khi họ bị thúc ép phải thay đổi.
  • Các thay đổi quy trình cần có mục đích rõ ràng.
  • Coi các hoạt động cải tiến như là các tiểu dự án.

Tiếp theo, tác giả đề xuất  một chu trình cải tiến mà bạn có thể dùng cho các dự án của  mình, đặc biệt có những bảng hỏi và template rất cụ thể.

Quy trình yêu cầu, trên thực tế là một tập hợp nhiều quy trình con khác nhau, tác giả gọi chúng là các tài sản quy trình – nói theo ngôn ngữ của doanh nghiệp, tất cả những gì được dùng để sản xuất ra sản phẩm thì gọi là tài sản của doanh nghiệp. Cải tiến quy trình chính là làm mới hoặc cải tiến các tài sản này. Có hai loại tài sản quy trình yêu cầu: các quy trình phát triển yêu cầu và các quy trình quản lý yêu cầu.

Cuối cùng tác giả trình bày một lộ trình cải tiến yêu cầu và cho rằng không có công thức cải tiến chung cho tất cả, bạn phải cụ thể hóa lộ trình cải tiến cho chính mình.

Chương này sẽ được chia thành 2 kỳ.

Tiếp tục đọc

4 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

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

Tác giả: Karl E. Wiegers

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

III. PHÂN TÍCH YÊU CẦU (REQUIREMENTS ANALYSIS)

Phân tích yêu cầu bao gồm việc làm mịn, phân tích ý tưởng và lời lẽ, nghiên cứu kỹ lưỡng các yêu cầu đã thu thập được để đảm bảo chắc chắn tất cả stakeholders (những người có liên quan) hiểu điều họ muốn nói, để tìm kiếm các lỗi, các thiếu sót và thiếu hụt khác. Công việc phân tích yêu cầu cũng đánh giá liệu các yêu cầu và SRS  (tài liệu đặc tả yêu cầu phần mềm) có đáp ứng đầy đủ các đặc tính về yêu cầu tuyệt vời được viết ở Chương 1 hay không. Mục đích của bạn là phát triển các yêu cầu chất lượng và chi tiết đủ để có thể xây dựng các ước lượng đầu vào cho dự án chuẩn bị tiến hành và để thực hiện việc thiết kế, xây dựng, kiểm thử sản phẩm.

Tiếp tục đọc

%(count) bình luận

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

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ỳ.

Tiếp tục đọc

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

Software Requirements. First Edition – MS Press. Chương 2: Yêu cầu từ góc nhìn của khách hàng

Tác giả: Karl E. Wiegers

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

Lời người dịch
Mở đầu chương bằng một tình huống trao đổi điển hình giữa khách hàng và nhà phát triển phần mềm, tác giả chỉ ra sự nhầm lẫn của khách hàng về các mức yêu cầu: yêu cầu kinh doanh (business requirements), yêu cầu người dùng (user requirements), yêu cầu chức năng và phi chức năng (functional and non-functional requirements) của sản phẩm phần mềm cần được xây dựng.

Từ các mức khác nhau của yêu cầu, tác giả dẫn ra các lớp khách hàng khác nhau: khách hàng là người trả tiền mua phần mềmkhách hàng là người lách cách gõ phím sử dụng phần mềm hàng ngày. Mỗi khách hàng lại đặt ra các mức yêu cầu khác nhau. Tác giả nhận định rằng phần mềm chất lượng cao là do có được yêu cầu tuyệt hảo (excellent requirements) ngay từ đầu, mà yêu cầu tuyệt hảo là kết quả của sự cộng tác tốt giữa hai nhân vật: khách hàngnhà phát triển.

Mọi sự cộng tác giữa các bên đều giống như một cuộc chơi, nghĩa là đều phải có các quy tắc ràng buộc, kiểm soát cuộc chơi. Tác giả đã đề xuất các quy tắc ràng buộc cuộc chơi và theo đúng phong cách của người Mỹ – mọi thứ đều phải có luật phân xử, ông gọi vui các quy tắc đó là Dự luật, chúng cần phải được khách hàng và nhà phát triển cùng thông qua thành Luật trước khi bắt đầu dự án xây dựng phần mềm. Đó là Dự luật yêu cầu về quyền của khách hàng phần mềmDự luật yêu cầu về trách nhiệm của khách hàng phần mềm.

Cuối cùng tác giả chỉ ra khi nào thì cần kết thúc quá trình phát triển yêu cầu để bắt tay vào các công việc tiếp theo. Kết quả của quá trình phát triển yêu cầu là bản đặc tả yêu cầu phần mềm SRS.

Tiếp tục đọc

6 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

Software Requirements. First Edition – MS Press. Chương 1: Cơ bản về yêu cầu phần mềm

Tác giả: Karl E. Wiegers

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

Lời người dịch
Chương này mở đầu bằng một tình huống mà bất cứ ai làm các dự án phần mềm cũng có thể đã gặp, tác giả dẫn dắt ra những hệ lụy khi phát triển phần mềm mà không có được đầy đủ, chính xác yêu cầu đầu vào. Tác giả đặt vấn đề như vậy nghĩa là sẽ chỉ cho độc giả một lối ra – lối ra đó là quy trình yêu cầu hay còn được gọi là công nghệ yêu cầu, tức là một dãy các bước cần thực hiện để làm ra cái được gọi là “yêu cầu phần mềm”.

Trước hết là một định nghĩa về khái niệm “yêu cầu” của IEEE – trong đó yêu cầu được nhìn từ cả hai phía: khách hàng và người phát triển hệ thống. Tác giả nhấn mạnh rằng yêu cầu thật sự chỉ nằm trong tâm trí khách hàng, những lời thể hiện yêu cầu, đặc tả yêu cầu chỉ là sự thể hiện ra bên ngoài của yêu cầu mà thôi, vì vậy sự thể hiện này có thể đúng, gần đúng hoặc sai so với những gì khách hàng thật sự mong muốn. Tiếp theo tác giả diễn giải 3 mức từ trừu tượng đến cụ thể hơn của yêu cầu: từ yêu cầu kinh doanh dẫn tới yêu cầu người dùng, từ yêu cầu người dùng dẫn tới yêu cầu chức năng và phi chức năng. Tiếp nữa tác giả trình bày các đặc tính của yêu cầu tuyệt vời (excellent requirements) thông qua lời thể hiện yêu cầu (requirement statement) – là yêu cầu trực tiếp từ khách hàng và người dùng được thể hiện bằng ngôn ngữ viết tự nhiên, đặc tả yêu cầu (requirement specification) – là lời thể hiện yêu cầu được viết lại bằng một ngôn ngữ đã được chuẩn hóa theo cách nào đó, theo khuôn mẫu nào đó.

Cuối chương, tác giả phân biệt sự khác nhau giữa 2 giai đoạn trong quy trình yêu cầu là phát triển yêu cầu (trình bày trong phần II cuốn sách) và quản lý yêu cầu (trình bày trong phần III cuốn sách). Sự phân biệt này rất quan trọng trong thực tế hoạt động của các dự án phần mềm.

Tiếp tục đọc

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