Một sinh viên hỏi: Tại sao nhiều dự án phần mềm thế bao giờ cũng trễ hay thất bại? Nếu kĩ nghệ yêu cầu là quan trọng thì tại sao nó KHÔNG được dạy trong trường? Tại sao nó thậm chí KHÔNG được dạy trong môn quản lí dự án?

Đáp: Lí do then chốt mà phần lớn dự án phần mềm bị chậm là vì thay đổi trong yêu cầu phần mềm và ước lượng dự án sai. Lí do khách hàng giữ thay đổi yêu cầu vì việc thu thập kém các yêu cầu trước khi bắt đầu dự án. Nhiều người quản lí dự án phần mềm cũng không coi tính hợp thức của yêu cầu của khách hàng là một phần việc làm của họ và chấp nhận các yêu cầu mà không phân tích thêm. Lí do khác có thể gây ra vấn đề lịch biểu là người phát triển muốn “hoàn thiện” bất kì cái gì họ làm. Nhiều người thêm các mã phụ không phải là một phần của yêu cầu gốc để làm cho nó “tốt hơn” mà không xét với tác động lên dự án. Nhiều người viết mã và viết lại mã của họ nhiều lần cho tới khi họ cảm thấy thoả mãn với nó. Những điều này tiêu tốn nhiều thời gian và nỗ lực và làm cho dự án bị trễ.

Kĩ nghệ yêu cầu chủ yếu được dạy trong trường có chương trình Kĩ nghệ phần mềm. Bởi vì đào tạo quản lí dự án thường bắt đầu với đặc tả yêu cầu phần mềm (SRS) đã được làm tài liệu cho nên thu được yêu cầu KHÔNG thuộc phạm vi của chúng. Đào tạo khoa học tính toán giả định rằng khách hàng sẽ viết yêu cầu cho nên người phát triển phần mềm sẽ bắt đầu công việc của họ với các yêu cầu phần mềm đã có tại chỗ. Lúc bắt đầu của dự án, có danh sách các yêu cầu với ngân sách tương ứng (chi phí), con người (tài nguyên), và lịch biểu (thời gian). Do đó bất kì thay đổi nào về yêu cầu mà không thay đổi về chi phí, tài nguyên và thời gian đều sẽ ảnh hưởng tới dự án. Không may, nếu các yêu cầu KHÔNG được xác định tốt, khách hàng sẽ phải thêm hay thay đổi yêu cầu sau khi dự án bắt đầu nhưng họ thường KHÔNG cho phép thay đổi trong chi phí, thời gian hay tài nguyên. Nhiều người quản lí dự án phần mềm không biết cách thương lượng trong thay đổi yêu cầu và chấp nhận nó mà không nghĩ về rủi ro cho dự án.

Người quản lí dự án giỏi có thể tránh được thay đổi yêu cầu bởi:

  • Đưa khách hàng và người dùng tham gia sớm vào trong dự án.
  • Phân tích kĩ lưỡng các yêu cầu trong lúc bắt đầu dự án để chắc chắn chúng đầy đủ, được làm tài liệu tốt và đáp ứng nhu cầu của khách hàng.
  • Thiết lập tổ cho Ban kiểm soát thay đổi (CCB) để đánh giá rủi ro của việc thực hiện thay đổi trước khi chấp nhận chúng.
  • Đưa mọi khác hàng tham gia vào mọi pha của dự án (đặc biệt trong pha lập kế hoạch).
  • Đưa ra tăng dần phần mềm. Dừng các yêu cầu thêm hay trì hoãn thực hiện chúng cho tới lần đưa ra tiếp.
  • Dùng cách tiếp cận Agile (nếu dự án nhỏ) như SCRUM. Danh mục sản phẩm (phạm vi) là động và sẽ thay đổi trong toàn bộ vòng đời phát triển phần mềm chừng nào khách hàng còn cảm thấy rằng những thay đổi đó là quan trọng và chấp nhận trách nhiệm về chúng bằng việc cho phép thêm thời gian.

—-English version—-

Avoiding software project failure

A student asked: Why so many software project are always late or failed? If requirements engineering is important then why it is NOT taught in school? Why it is NOT even taught in project management course?

Answer: The key reasons that most software projects are late because of changes in software requirements and wrong project estimates. The reason customers keep changing requirements because of poorly gathering of requirements before the starting of the project. Many software project managers also do not consider customer’s requirements validation is part of their job and accept the requirements without further analysis. Another reason which can cause project’s schedule problems is developers want to “perfect” whatever they do. Many add additional codes that are not part of original requirements in order to make it “better” without consider the impact on the project. Many write code and re-write their code several times until they feel comfortable with it. These consume a lot of time and efforts and make the project late.

Requirements Engineering is mostly taught in schools that have the Software Engineering program. Because Project management training often starts with a documented software requirements specification (SRS) so obtaining requirements is NOT in their scope. Traditional Computer Science training assumes that customer will write the requirements so software developers would begin their works with a software requirements already in place. At the beginning of a project, there is a list of requirements with corresponding budget (Cost), people (Resource), and schedule (Time). Therefore any change in requirements without change in cost, resources, and time will affect the project. Unfortunately, if requirements is NOT well defined, customers will have to add or change requirements after the project starts but they often do NOT allow changes in cost, time or resources. Many software project managers do not know how to negotiate changes in requirements and accept it without thinking about risks to the project.

A good software project manager can avoid requirements change by:

  • Involve the customers and users early in the project.
  • Thoroughly analyze requirements during the beginning of the project to make sure they are complete, well documented and meet customer’s needs.
  • Establish a Change Control Board (CCB) team to evaluate the risk of implementing changes before accepting them.
  • Involve all customers throughout the project phases (especially during the planning phase).
  • Incrementally release the software. Stop additional requirements or postpone implementing them until the next release.
  • Use Agile approach (If the project is small) such as SCRUM. The product catalogue (scope) is dynamic and will changes throughout the software development life cycle as long as the customer feels that those changes are important and accepts the responsibility for them by allowing more time.