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

Chương 3 đã mô tả nhiều hướng dẫn thực hành tốt (good practices) của công nghệ yêu cầu, bạn có thể ứng dụng các practices đó vào việc cải tiến quy trình yêu cầu của mình. Tuy nhiên, nếu các nỗ lực cải tiến quy trình được bắt đầu sai thì những người bị ảnh hưởng từ quy trình này sẽ kháng cự lại và có thể chương trình cải tiến sẽ thất bại.

Cải tiến quy trình phần mềm có 2 mục tiêu chính:

  • Sửa chữa các vấn đề mà bạn đã gặp trong các dự án trước và hiện tại.
  • Tiên liệu và ngăn ngừa các vấn đề mà bạn có thể sẽ gặp trong các dự án tương lai.

Nếu cách thức làm việc hiện nay của bạn dường như là tốt thì bạn không thấy có nhu cầu thay đổi cách làm yêu cầu của mình. Tuy nhiên, thậm chí các công ty phần mềm thành công cũng sẽ phải đối mặt với các khó khăn to lớn khi thực hiện các dự án lớn hơn, khi làm việc với một cộng đồng khách hàng khác, khi lịch biểu được siết chặt hơn, hoặc khi làm việc trong một miền ứng dụng mới. Vì vậy, bạn cũng nên biết những cách tiếp cận làm yêu cầu mới có giá trị đối với công việc của bạn.

Chương này mô tả yêu cầu liên quan ra sao với các quy trình chính của dự án và những người có liên quan khác (stakeholders). Một số khái niệm cơ bản về cải tiến quy trình phần mềm và một cách cải tiến quy trình cũng sẽ được đề xuất với các bạn. Tôi sẽ liệt kê một số “tài sản quy trình” yêu cầu (requirement “process assets”) quan trọng mà tổ chức của bạn nên sử dụng. Chương này kết thúc bằng mô tả một lộ trình về cải tiến quy trình yêu cầu có sử dụng các practices trên.

I. YÊU CẦU LIÊN QUAN NHƯ THẾ NÀO ĐẾN CÁC QUY TRÌNH KHÁC CỦA DỰ ÁN (HOW REQUIREMENTS RELATE TO OTHER PROJECT PROCESSES)

Yêu cầu nằm ở trái tim của các dự án phần mềm thành công, nó trợ giúp nhiều hoạt động quản lý và kỹ thuật. Các thay đổi mà bạn thực hiện trong cách tiếp cận các hoạt động phát triển và quản lý yêu cầu sẽ ảnh hưởng tới các quy trình khác và ngược lại. Hình 4-1 minh họa một số liên quan giữa quy trình yêu cầu và các quy trình khác của một dự án phần mềm;

Fig 4.1
HÌNH 4-1. Quan hệ của quy trình yêu cầu với các quy trình khác trong một dự án phần mềm

Sự liên quan giữa quy trình yêu cầu và các quy trình khác được mô tả ngắn gọn dưới đây.

Quy trình Lập kế hoạch dự án (Project planning process)

Yêu cầu phải là cơ sở của các quy trình lập kế hoạch dự án. Các ước lượng tài nguyên và lịch biểu cần dựa trên sự hiểu biết về cái gì sẽ được xây dựng và chuyển giao cho khách hàng. Thông thường, lập kế hoạch dự án nghĩa là tính toán sao cho tất cả các tính năng mong muốn sẽ được thực hiện trong một giới hạn ngân sách và thời gian nhất định. Các quy trình lập kế hoạch có thể dẫn tới việc thu hẹp phạm vi dự án hoặc lựa chọn một cách tiếp cận từng bước một – phát hành dần từng phiên bản của sản phẩm, mỗi phiên bản chỉ bao gồm một số tính năng.

Quy trình Giám sát và kiểm soát dự án (Project tracking and control Process)

Giám sát (monitor) trạng thái của mỗi yêu cầu được coi là một phần của việc giám sát dự án (project tracking) sao cho các nhà quản lý dự án có thể biết liệu công việc có được tiến hành như mong muốn hay không. Nếu không, cấp quản lý có thể đề nghị thu hẹp phạm vi thông qua các quy trình kiểm soát thay đổi.

Quy trình Kiểm soát thay đổi (Change control Process)

Sau khi yêu cầu đã được tài liệu hóa và vạch ranh giới (baselined), tất cả các thay đổi tiếp theo của yêu cầu cần được thực hiện thông qua quy trình kiểm soát thay đổi đã định nghĩa. Quy trình kiểm soát thay đổi đảm bảo rằng:

  • Ảnh hưởng của một đề xuất thay đổi (proposed change) đã được hiểu đầy đủ.
  • Tất cả những ai bị ảnh hưởng bởi thay đổi thì đều đã nhận thức được điều đó.
  • Những người có thẩm quyền ra quyết định để chấp nhận thay đổi.
  • Tài nguyên được điều chỉnh tương ứng.
  • Các tài liệu yêu cầu được cất giữ.

Quy trình Kiểm thử hệ thống (System testing process)

Các yêu cầu người dùng (user requirements) và các yêu cầu chức năng (functional requirements) là đầu vào chính để kiểm thử hệ thống. Nếu hành vi được mong đợi của phần mềm trong các điều kiện khác nhau không được đặc tả thì người kiểm thử rất khó biết hành vi nào của hệ thống là đúng, hành vi nào là sai. Ngược lại, kiểm thử hệ thống là một phương tiện để xác nhận rằng tất cả các chức năng đã được lập kế hoạch thì đều được thực hiện và các công việc (tasks) mà người dùng mong muốn đã hoạt động một cách đúng đắn.

Quy trình Làm tài liệu người dùng (User documentation process)

Trước đây tôi đã làm việc trong một công ty với vai trò technical writer – người viết tài liệu hướng dẫn cho các sản phẩm thương mại. Tôi hỏi một trong số các writers rằng tại sao chúng ta phải làm việc nhiều như vậy. “Chúng ta ở vào điểm cuối của dây chuyền”, cô đáp. “Chúng ta là những người phải tài liệu hóa các thay đổi cuối cùng trong giao diện người dùng hiển thị các tính năng bị xoá bỏ hay thêm vào trong phút cuối”. Các yêu cầu là đầu vào chính của quy trình làm tài liệu, vì vậy chất lượng của yêu cầu sẽ quyết định chất lượng của tài liệu.

Quy trình Thi công hệ thống (Construction process)

Phần mềm có thể chạy (executable software) chứ không phải các tài liệu yêu cầu là sản phẩm phải chuyển giao cho khách hàng của một dự án phần mềm. Các yêu cầu là cơ sở để thiết kế và thi công phần mềm. Yêu cầu chức năng (functional requirements) dẫn tới các thiết kế components, chúng phục vụ như là các đặc tả cho các mã sẽ được viết. Thực hiện soát xét thiết kế để đảm bảo bản thiết kế đã chứa tất cả các yêu cầu. Kiểm thử đơn vị (unit testing) mã nguồn có thể xác định liệu nó có đáp ứng đặc tả thiết kế và yêu cầu tương ứng hay không.

II. ẢNH HƯỞNG CỦA YÊU CẦU PHẦN MỀM TỚI NHỮNG NGƯỜI CÓ LIÊN QUAN KHÁC CỦA DỰ ÁN (IMPACT OF SOFTWARE REQUIREMENTS ON OTHER STAKEHOLDERS)

Khi nhóm phát triển phần mềm thay đổi quy trình yêu cầu của họ thì sự thay đổi này sẽ ảnh hưởng tới những người có liên quan của dự án. Hình 4-2 thể hiện ảnh hưởng của yêu cầu phần mềm tới những người có liên quan.

Fig 4.2
HÌNH 4-2. Quan hệ giữa nhóm phát triển phần mềm và các bên có liên quan

Đó là:

  • Nhóm marketing (Marketing or Product Management): đặc tả yêu cầu kinh doanh hoặc yêu cầu của thị trường cho nhóm phát triển; đề xuất các thay đổi đối với nhóm phát triển.
  • Nhóm hỗ trợ kỹ thuật (Technical Support): hỗ trợ người dùng của khách hàng, cung cấp đầu vào cho nhóm phát triển từ việc phân tích các báo cáo lỗi của khách hàng, đề nghị các thay đổi nâng cấp phần mềm.
  • Người phụ trách dùng (Users): mô tả các yêu cầu người dùng và thuộc tính chất lượng của các yêu cầu đó, soát xét các yêu cầu.
  • Nhóm kỹ thuật phần cứng (Hardware Engineering): đặc tả các giao diện phần cứng mà phần mềm phải làm việc cùng.
  • Nhóm kỹ thuật hệ thống (Systems Engineering): phân bổ các yêu cầu hệ thống cho phần mềm, đề xuất thay đổi.
  • Nhóm mua sắm (Procuers): đặc tả các nhu cầu kinh doanh, chức năng và hiệu suất; đề xuất thay đổi.
  • Nhóm pháp lý (Legal Department): xử lý các vấn đề pháp luật liên quan đến license của các tools và components.
  • Cấp quản lý (Management): đềa ra các ràng buộc của dự án, ràng buộc về tài nguyên và cam kết khác cho nhóm phát triển.

III. CƠ BẢN VỀ CẢI TIẾN QUY TRÌNH PHẦN MỀM (FUNDAMENTALS OF SOFTWARE PROCESS IMPROVEMENT)

Bạn đọc cuốn sách này vì mong muốn làm tốt hơn công nghệ yêu cầu, hãy ghi nhớ 4 nguyên lý sau khi thực hiện cải tiến quy trình phần mềm (Wiegers 1996a):

  1. 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 (Process improvement should be evolutionary, continuous, and cyclical). Đừng nghĩ sẽ cải tiến tất các các quy trình của bạn trong một lúc, hãy chấp nhận rằng bạn không thể làm được tất cả mọi thứ đúng ngay từ đầu, ngay khi bạn bắt đầu thực hiện sự thay đổi. Thay vì cố đạt tới sự hoàn hảo, hãy cải tiến từng chút một và thực hiện nó cẩn thận. Bạn có thể điều chỉnh cách tiếp cận khi bạn đã có được kinh nghiệm với các cải tiến trước đó.
  2. Con người và các tổ chức chỉ thay đổi khi họ bị thúc ép phải thay đổi (People and organizations change only when they have an intence to do so). Sức thúc ép mạnh nhất chính là sự đau khổ khi làm việc theo cách cũ. Tôi không có ý nói đến các đau khổ, chẳng hạn, như các lịch biểu bị siết chặt do nhu cầu của khách hàng, tôi muốn nói đến các đau khổ mà bạn đã trải qua từ các dự án trước. Những đau khổ là động lực khiến một người quản lý nói: “Cuốn sách này nói chúng ta phải làm một số thứ, vậy nên bắt  tay vào làm đi!”. Một số thống kê từ các dự án trước có thể định hướng cho việc thay đổi quy trình yêu cầu:
    • Dự án bị lỗi hẹn (missed deadlines) do các yêu cầu quá phức tạp so với sự hình dung.
    • Nhà phát triển phải làm việc vất vả nhiều giờ do các yêu cầu không được hiểu rõ hoặc các yêu cầu nhập nhằng nhưng lại được đề xuất vào phút cuối quá trình phát triển sản phẩm.
    • Các nỗ lực kiểm thử hệ thống quá ít tác dụng do các kiểm thử viên không hiểu hệ thống làm gì.
    • Chức năng đúng đã được thực hiện nhưng người dùng không hài lòng vì sự kém cỏi của nó như tính tiện dụng thấp chẳng hạn.
    • Tổ chức phát triển đã có kinh nghiệm về các sản phẩm với chi phí bảo trì cao do khách hàng đề xuất nhiều yêu cầu nâng cấp trong giai đoạn suy luận yêu cầu.
    • Tổ chức phát triển đã nhiều lần đối mặt với sự từ chối của khách hàng khi bàn giao sản phẩm.
  3. Các thay đổi quy trình cần phải được hướng đích (Process changes should be goal oriented). Trước khi bắt đầu hành trình thay đổi quy trình, hãy đảm bảo chắc chắn ràng bạn đã biết những gì bạn phải đối đầu. Bạn có muốn giảm bớt lượng công việc phải làm lại do các vấn đề liên quan đến yêu cầu? Bạn có muốn kiểm soát tốt hơn cách tích hợp các thay đổi yêu cầu vào dự án? Bạn có muốn chắc chắn rằng không có yêu cầu nào bị bỏ qua khi thi công? Một lộ trình vạch ra con đường bạn phải đi sẽ nâng cơ may thành công cho bạn khi cải tiến quy trình.
  4. Xử lý các hoạt động cải tiến quy trình của bạn như là các tiểu dự án (Treat improvement activities as miniprojects).  Nhiều sáng kiến cải tiến quy trình đã đổ vỡ vì được lập kế hoạch thực hiện một cách sơ sài, vì các cam kết nguồn lực dành cho chúng chả bao giờ thành hiện thực. Để tránh các vấn đề đó, hãy xử lý các hoạt động cải tiến quy trình như các dự án. Hãy ghép các nguồn lực và công việc (tasks) cải tiến quy trình vào kế hoạch tổng thể của dự án. Hãy lập kế hoạch, giám sát, đo lường và tổng kết báo cáo về công việc đó như một dự án bình thường. Hãy viết một kế hoạch hành động cho mỗi hoạt động cải tiến quy trình. Hãy giám sát thời gian và chi phí mà những người tham gia cải tiến quy trình đã sử dụng nhằm nắm bắt được tốc độ cải tiến.

IV. CHU TRÌNH CẢI TIẾN QUY TRÌNH (THE PROCESS IMPROVEMENT CYCLE)

Hình 4-3 minh hoạ một chu trình cải tiến quy trình mà tôi thấy là rất hiệu quả. Chu trình này nói về tầm quan trọng  của việc biết nơi bạn đang đứng trước khi di chuyển sang một vị trí khác, nói về sự cần thiết của việc lập kế hoạch cho các hoạt động cải tiến và học hỏi từ chính kinh nghiệm của bạn như là một phần của sự cải tiến liên tục.

Fig 4.3
Assess Current Practices = Đánh giá các practices hiện tại

Plan Improvement Actions = Lập kế hoạch cho các hoạt động cải tiến

Create, Pilot and Implement New Processes = Thiết lập, thử nghiệm, cải tiến các quy trình mới

Evaluate Results = Đánh giá kết quả

HÌNH 4.3. Chu trình cải tiến quy trình phần mềm

1. ĐÁNH GIÁ CÁC PRACTICES HIỆN TẠI (ASSESS CURRENT PRACTICES)

Bước đầu tiên trong bất cứ hoạt động cải tiến quy trình nào cũng là đánh giá các practices hiện tại đang được sử dụng trong tổ chức để xác định thế mạnh và hạn chế của nó. Một bản đánh giá không tự nó gợi nên bất cứ cải tiến nào, nó chỉ cung cấp thông tin giúp chọn được những cách làm đúng để có những thay đổi mà bạn muốn.

Bạn có thể đánh giá các quy trình hiện tại theo nhiều cách. Nếu bạn cố gắng thực hiện bất cứ bước nào trong hộp Các bước tiếp theo ở cuối các chương trước thì bạn đã bắt đầu một đánh giá không chính thức về các requirements practices và các kết quả của chúng. Các bảng hỏi tự đánh giá có cấu trúc mang lại cho bạn một cách tiếp cận hệ thống hơn, bạn có thể thấy được các vấn đề bên trong của các quy trình hiện tại mà không cần phải mất quá nhiều công sức.

Cách tiếp cận chi tiết và khách quan hơn là mời các chuyên gia tư vấn bên ngoài đánh giá các software practices của bạn. Các đánh giá tốt nên dựa trên một khung đánh giá quy trình như CMMI chẳng hạn. Các đánh giá viên sẽ kiểm tra và đánh giá tất cả các quy trình quản lý và phát triển của bạn và không chỉ khuôn trong các hoạt động liên quan đến yêu cầu. Hãy chọn một cách đánh giá đáp ứng được các yêu cầu kinh doanh (business requirements) của bạn, không cần thiết nó có phù hợp CMMI hoặc một mô hình cụ thể nào khác.

Phần Phụ lục chứa một bảng hỏi để bạn tự đánh giá các requirements practices của mình. Sử dụng bảng hỏi này để có cái nhìn toàn cảnh về các practices trong công nghệ yêu cầu (requirements engineering practices) của bạn, bạn sẽ biết quy trình yêu cầu (requirements processes) nào cần cải tiến nhất trong tổ chức của bạn. Hãy tập trung sức lực của bạn để cải tiến những practices nào đang và sẽ gây ra cho các dự án của bạn những khó khăn và những rủi ro cao nhất. Mỗi câu hỏi trong bảng tự đánh giá tham chiếu tới một chương trong cuốn sách này. Motorola đã phát triển một bảng hỏi tương tự là “Software Requirements Quality Model” (Smith 1998).

Kết quả đạt được sau một đánh giá chính thức là các số liệu (findings) – báo cáo điểm mạnh và điểm yếu của các quy trình đang sử dụng – và các khuyến nghị (recommendations) để nhận diện các cơ hội cải tiến. Các đánh giá không chính thức, như bảng hỏi tự đánh giá, cung cấp cho bạn những hiểu biết sâu bên trong để lựa chọn những gì cần cải tiến. Bạn sẽ tìm thấy nhiều khuyến nghị tổng quan (general recommendations) trong cuốn sách này về các câu hỏi tự đánh giá. Hãy phân tích mỗi hành động cải tiến để chắc chắn về chi phí – hiệu quả của nó.

2. LẬP KẾ HOẠCH CHO CÁC HOẠT ĐỘNG CẢI TIẾN (PLAN IMPROVEMENT ACTIONS)

Nhằm tuân theo triết lý của hoạt động cải tiến quy trình là coi các hoạt động cải tiến như là các dự án, hãy viết một kế hoạch hành động sau khi bạn đã có các đánh giá. Hãy cân nhắc liệu có nên viết một kế hoạch chiến lược (strategic plan) tổng thể mô tả các sáng kiến cải tiến quy trình của doanh nghiệp của bạn hay không, cũng như các kế hoạch hành động mang tính chiến thuật (tactical action plans) xử lý các cải tiến cụ thể. Mỗi kế hoạch chiến thuật cần chỉ ra mục đích của các hoạt động cải tiến, những người tham gia, một số hành động cụ thể cần hoàn thành để thực thi kế hoạch. Hình 4-4 mô tả một template kế hoạch hành động cải tiến quy trình mà tôi đã sử dụng nhiều lần.

Kế hoạch hành động cải tiến quy trình

Dự án: <Tên dự án>

Ngày: <Ngày dự án được viết>

Mục đích (Goals): <Mô tả mục đích cần đạt được của kế hoạch này. Hãy viết các mục đích định hướng đạt được các kết quả kinh doanh (business results), chứ không phải trong khuôn khổ của sự thay đổi quy trình>
Đo lường thành công (Measures of Success):

<Hãy mô tả bạn sẽ xác định như thế nào các hiệu quả mong muốn đối với dự án khi các thay đổi quy trình được thực hiện>

Phạm vi ảnh hưởng đến tổ chức (Scope of Organizational Impact):

<Mô tả tầm ảnh hưởng đối với tổ chức của các thay đổi quy trình được mô tả trong kế hoạch này>

Những người tham gia (Staffing and Participans):

<Xác định các cá nhân sẽ thực hiện kế hoạch này, vai trò của họ, cam kết thời gian tham gia của họ>

Quy trình giám sát và báo cáo (Tracking and Reporting Process):

<Hãy mô tả cách giám sát tiến độ cải tiến và tình trạng, kết quả đạt được, các vấn đề sẽ được báo cáo>

Các phụ thuộc, rủi ro và ràng buộc (Dependencies, risks, and constrains):

<Xác định bất cứ yếu tố bên ngoài nào cần thiết đối với sự thành công của dự án, hoặc ảnh hưởng xấu đến sự thành công của dự án khi thực hiện kế hoạch này>

Ngày hoàn thành ước tính của dự án (Estimated completion date for all activites):

<Khi nào thì bạn sẽ thực hiện xong tất cả các công việc này?>

CÁC CÔNG VIỆC CẦN THỰC HIỆN (ACTION ITEMS)

<Viết 3 đến 10 công việc cho mỗi kế hoạch hành động>

Stt

(Action item)

Người thực hiện

(Responsible individual)

Ngày hoàn thành

(Due date)

Mục đích

(Purpose)

Mô tả các hoạt động

(Description of Activites)

Các kết quả đạt được

(Deliverables)

Nguồn lực cần thiết

(Resource needed)

<Cá nhân chịu trách nhiệm> <Tất cả các hoạt động sẽ được thực hiện để hoàn thành mục công việc này> <Các thủ tục, templates, các tài sản quy trình  khác sẽ được tạo ra> <Bất cứ nguồn lực cần thiết nào gồm vật liệu, công cụ, tài liệu, hoặc con người>
HÌNH 4-4. Template kế hoạch hành động cải tiến quy trình phần mềm

3. THIẾT LẬP, THỬ NGHIỆM, CẢI TIẾN CÁC QUY TRÌNH MỚI (CREATE, PILOT, AND IMPLEMENT NEW PROCESSES)

Bạn đã đánh giá các requirements practices của bạn và đã chuẩn bị một kế hoạch để cải tiến quy trình. Bây giờ là phần khó khăn: thực hiện quy trình. Nhiều sáng kiến cải tiến quy trình đã rơi vào trình trạng khó khăn khi đưa kế hoạch hành động vào thực tiễn.

Thực hiện một kế hoạch hành động nghĩa là xây dựng các quy trình mới hoặc làm cho quy trình cũ tốt hơn. Tuy nhiên, bạn không nên hy vọng sẽ nhận được quy trình mới hoàn hảo ngay từ đầu. Nhiều cách tiếp cận dường như là một ý tưởng tốt nhưng lại kém hiện thực hoặc không hiệu quả khi thực hiện. Vì vậy, hãy lập một kế hoạch thử nghiệm (process “pilot”) cho các thủ tục mới hoặc các templates mà bạn tạo ra. Sử dụng kiến thức, kinh nghiệm mà bạn thu thập được trong quá trình thử nghiệm để điều chỉnh các quy trình mới. Ghi nhớ các lời khuyên sau khi bạn thử nghiệm các quy trình mới:

  • Lựa chọn những người tham gia thử nghiệm các quy trình mới và sau đó đưa ra đánh giá phản hồi. Họ nên là những người có tính hoài nghi cao nhưng lại không phản đối cải tiến quy trình.
  • Lượng hoá các tiêu chuẩn mà bạn sử dụng để đánh giá cuộc thử nghiệm, hãy tạo ra các kết quả dễ dàng diễn giải.
  • Xác định những người có liên quan đến dự án cần được thông tin về việc thử nghiệm.
  • Cân nhắc việc thử nghiệm các quy trình mới trên các dự án khác nhau để tăng mức độ thử thách của quy trình.
  • Như là một phần của việc đánh giá, hãy hỏi những người tham gia thử nghiệm xem họ cảm thấy thế nào nếu phải quay lại cách làm việc cũ.

4. ĐÁNH GIÁ KẾT QUẢ (EVALUATE RESULTS)

Bước cuối cùng là đánh giá các hoạt động và kết quả đạt được, việc này giúp bạn điều chỉnh các hoạt động cải tiến quy trình tiếp theo. Bạn cũng cần xem xét các quy trình mới đã được những người liên quan biết rõ để thực hiện hay chưa.

Hãy chú ý Hình 4-5 khi bạn ứng dụng các quy trình mới, sự sụt giảm năng suất làm việc sẽ diễn ra ngay sau khi ứng dụng. Nhưng sau một thời gian năng suất làm việc sẽ tăng nên và cao hơn năng suất trước khi bạn ứng dụng quy trình mới.

Fig 4.5
HÌNH 4.5. Đường cong học hỏi cải tiến quy trình

(Còn kỳ 2 của chương 4)

15/11/2009

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

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

  1. Phạm Hữu Thọ

    Cam on anh ve bai viet
    Anh co the dich tiep nhanh nhanh khong?
    Anh shar link cho moi nguoi down ban tieng anh duoc khong?

  2. sata2009blog

    Chào bạn Thọ, tôi đang dùng bản cứng tiếng Anh, xuất bản lần thứ nhất. Bạn có thể search, dùng đúng tên sách và tên tác giả, tìm bản mềm xuất bản lần thứ hai để xem trực tiếp.

  3. Dear Author satablog2.wordpress.com !
    Matchless topic, it is interesting to me))))

  4. sata2009blog

    Thank you very much!

Gửi phản hồ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 Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s