Một người quản lí hỏi tôi: “Cách nào tốt nhất để xây dựng sản phẩm phần mềm chất lượng cao? Làm sao chúng tôi có thể giảm thời gian mất cho việc xây dựng phần mềm?”

Đáp: Theo ý kiến tôi, có được yêu cầu đúng lúc bắt đầu dự án là cách tốt nhất. Điều đó sẽ giúp xây dựng phần mềm chất lượng tốt hơn, giảm nỗ lực trong làm lại và ít thời gian kiểm thử hơn nhiều. Càng nhiều thay đổi cho dự án phần mềm trong các pha thiết kế, viết mã hay kiểm thử sẽ tạo ra khả năng nhiều lỗi hơn trong sản phẩm. Một khi lỗi đi vào trong phần mềm, bạn phải kiểm thử và loại bỏ chúng và điều đó mất thời gian, điều có thể làm trễ dự án. Có yêu cầu có chất lượng sẽ giúp cho việc chuyển gia phần mềm có chất lượng.

Phần lớn những người quản lí, đặc biệt là những người không có kinh nghiệm phát triển phần mềm bao giờ cũng thúc đẩy viết mã vì họ nghĩ viết mã là phát triển phần mềm. Họ không muốn tổ dành thời gian trong yêu cầu hay thiết kế bởi vì họ không thấy “phát triển” gì cả. Việc thiếu tri thức này về vòng đời phát triển phần mềm đã làm nảy sinh trong nhiều dự án việc nhảy qua hai pha đầu tiên này và vội vàng đi vào pha viết mã. Không thu được yêu cầu chính xác sẽ làm nảy sinh chi phí cao hơn, tốn nhiều thời gian hơn, và nhiều lỗi hơn trong phần mềm. Chi phí cho việc sửa lỗi sẽ tăng lên ít nhất mười lần cho từng pha, điều có nghĩa là ở pha viết mã, nó sẽ tốn 100 lần để sửa lỗi hơn là sửa nó trong pha yêu cầu. Cũng dễ tìm và sửa lỗi trong pha yêu cầu hay pha thiết kế hơn là trong viết mã hay kiểm thử. Yêu cầu kém đòi hỏi nhiều việc làm lại và có thể gây cho dự án thất bại. Tính hiệu quả của tổ để chuyển giao phần mềm chất lượng tuỳ thuộc vào các yêu cầu được làm tài liệu tốt đến đâu và đúng đắn thế nào. Đó là lí do tại sao ở cuối pha yêu cầu, chúng ta phải tiến hành kiểm điểm kĩ lưỡng để đảm bảo rằng các yêu cầu là đầy đủ, đúng đắn, bản chất, khả thi và kiểm thử được.

Không may là ngay cả ngày nay, rất ít chương trình đào tạo hội tụ vào kĩ nghệ yêu cầu nhưng vẫn để nhiều nhấn mạnh vào ngôn ngữ lập trình. Bằng việc có đào tạo thích hợp, các kĩ sư yêu cầu hay người phân tích doanh nghiệp có thể làm việc chặt chẽ với người dùng để học về qui trình doanh nghiệp để cho họ có thể hiểu được nhu cầu của người dùng. Bằng việc hiểu nhu cầu của người dùng và cách phần mềm sẽ được dùng, họ có thể có được tài liệu yêu cầu chính xác và đầy đủ cho dự án phần mềm.

—-English version—-

High Quality software

A manager asked me: “What is the best way to build high quality software product? How can we reduce the time it takes to build software?

Answer: In my opinion, getting the correct requirements at the beginning of the project is the best way. It will help build better quality software, reduce the effort in re-works and much less testing time. The more changes to a software project during design, coding or testing phases will result in the possibility of more defects in the software product. Once defects get into the software, you must test and remove them and it takes time which may delay the project. Having quality requirements will help the delivery of quality software.

Most managers, especially people who do not have software development experience always push for coding as they think coding is software development. They do not want the team to spend time in requirements or design phases because they do not see any “development”. This lack of knowledge about software development lifecycle has resulted in many projects skip these first two phases and hurry go to coding phase. The failure to obtain accurate requirements will result in higher cost, more time, and more defects in the software. The costs of fixing defects will increase at least ten times for each phase that means at coding phase, it will cost 100 times to fix a defect than fix it during requirement phase. It is also easier to find and fix defects during the requirements phase or design phase than during coding or testing. A bad requirement requires a lot of rework and could cause project failure. The effectiveness of the team to deliver quality software depends on how good and correct the requirements are documented. That is why at the end of requirement phase, we must conduct a thorough review to ensure that requirements are complete, correct, essential, feasible and testable.

Unfortunately even today, very few training programs are focusing on requirements engineering but still put a lot of emphasis on programming languages. By having appropriate training, requirement engineers or business analysts can work closely with users to learn about the business processes so they can understand users’ needs. By understand users’ needs and how the software will be used, they can get accurate and complete requirements documentation for the software project.