Tuần trước, một sinh viên gửi cho tôi một email: “Em là sinh viên năm thứ nhất về Khoa học máy tính. Em bị lẫn lộn về vòng đời phát triển phần mềm. Có bao nhiêu vòng đời vậy? Làm sao em chọn được vòng đời này so với vòng đời khác? Xin thầy lời khuyên.”

Đáp: Có vài vòng đời phát triển phần mềm. Phổ biến nhất và dễ hiểu nhất là vòng đời Thác đổ. Theo ý kiến tôi, mọi thứ khác là cải tiến của vòng đời này qua thời gian. Là sinh viên, bạn phải hiểu mọi pha của vòng đời này. Một khi bạn biết rõ chúng, bạn có thể học về các vòng đời khác. Sau đây là mô tả ngắn gọn:

Vòng đời thác đổ là qui trình phát triển phần mềm tuần tự nơi mọi hoạt động phát triển đều phải tuân theo những pha nào đó như yêu cầu, thiết kế, viết mã, kiểm thử và bảo trì. Bạn phải hoàn thành một pha trước khi chuyển sang pha tiếp, cũng như nước chảy từ trên đỉnh xuống đáy trong một thác nước. Với vòng đời này, khách hàng phải đợi cho tới khi mọi pha được hoàn thành, cho tới khi phần mềm được kiểm thử đầy đủ trước khi họ có thể dùng sản phẩm. Vấn đề với cách tiếp cận này là nếu có thay đổi về sau trong vòng đời, có thể rất khó sửa vì bất kì việc làm lại nào cũng sẽ có chứa rủi ro và khả năng trễ lịch biểu. Thác nước có tác dụng tốt nếu yêu cầu là rõ ràng, được xác định tốt và với thay đổi tối thiểu.

Vì thay đổi xảy ra trong dự án phần mềm, một cách tiếp cận tới giải quyết vấn đề này là phát triển vài lần đưa ra hay lặp. Từng lần lặp đều bao quát toàn bộ vòng đời thác đổ và bất kì thay đổi nào xảy ra sau sẽ được để trễ cho lần lặp tiếp. Điều này làm cho sản phẩm phần mềm đưa ra nhanh hơn, lấy được phản hồi của người dùng nhanh hơn và cho tổ dự án khả năng phản ứng với vấn đề là khiếm khuyết sớm hơn. Cho dù việc đưa ra tăng lên này là cải tiến tốt cho vòng đời thác đổ truyền thống nhưng vẫn có một số khó khăn trong việc thiết kế lại và làm lại và sửa phần mềm điều tăng thêm chi phí cho dự án.

Để giảm chi phí và rủi ro do số thay đổi với dự án, cải tiến tiếp cho vòng đời thác đổ là cân nhắc toàn thể việc phát triển như một số bước tăng nhỏ với lập kế hoạch, yêu cầu, phân tích và làm bản mẫu liên tục để cải tiến yêu cầu. Trong cách tiếp cận này, kĩ thuật làm bản mẫu được áp dụng để lấy phản hồi của người dùng trước khi thiết kế, kiểm thử và đánh giá. Phát triển phần mềm được xây dựng tăng dần, từng lần lặp được xây dựng trên lần lặp trước cho tới khi mọi yêu cầu đều được biết. Vì vòng này giống như xoáy ốc, cho nên cách tiếp cận này thường được nói tới là phương pháp “xoáy ốc”.

Tất cả các cách tiếp cận trên (thác đổ, lặp, và xoáy ốc) có tác dụng tốt trong dự án cỡ vừa và lớn. Tuy nhiên với dự án nhỏ, những cách tiếp cận này vẫn mất thời gian và có thể không đáp ứng điều khách hàng cần để có cái gì đó nhanh chóng. Đó là lí do tại sao cách tiếp cận Agile được tạo ra. Cách tiếp cận này vẫn dựa trên phát triển tương tác và tăng dần nhưng các yêu cầu và giải pháp tiến hoá qua cộng tác giữa khách hàng và người phát triển được gọi là các tổ tự tổ chức chéo chức năng. Agile bao gồm vài phương pháp như Scrum; Lập trình cực đoan – Extreme Programming (XP); Crystal; Phương pháp luận phát triển hệ thống động – Dynamic System Development Methodology (DSDM); Phát triển phần mềm thích ứng – Adaptive Software Development; Phát triển phần mềm gầy – Lean software development; và Phát triển được dẫn lái theo tính năng – Feature-driven development. Trong số này, Scrum có lẽ là phổ biến nhất trong công nghiệp phần mềm. Vì tôi đã viết nhiều bài về Agile trong blog của tôi, bạn có thể xem lại chúng.

—-English version—-

Software development life cycles

Last week, a student sent me an email: “I am a first year student in Computer Science. I am confused about the software development life cycles. How many of them are there? How do I chose one over the other? Please advise.”

Answer: There are several software development life cycles. The most popular and easiest to understand is the Waterfall life cycle. In my opinion, everything else is an improvement of this life cycle over time. As student, you must understand all phases of this life cycle. Once you know them well, you can learn about the other life cycles. Following is a short description:

The waterfall lifecycle is a sequential software development process where all development activities must follow a certain phases such as requirements, design, code, test and maintenance. You must complete a phase before move to the next, just like water flowing from top to bottom in a waterfall. For this lifecycle, customers must wait until all phases are completed, until the software is fully tested before they can use the product. The problem with this approach is if there are changes late in the lifecycle, it could be very difficult to fix as any rework would incur risks and possible schedule delay. The waterfall works well if the requirements are clear, well defined and with minimum change.

Since changes do happen in software projects, one approach to solve this problem is to develop several releases or iterations. Each iteration covers the entire waterfall lifecycle and any change happens late will be delayed to the next iteration. This gets the software product out quicker, gets user feedback faster and gives the project team the ability to react to issues and defects earlier. Even this incremental release approach is a good improvement to the traditional waterfall life cycle but there still are some difficulties in re-designing, reworking and fixing the software which add costs to the project.

To reduce costs and risks due to the number of changes to the projects, the next improvement to the waterfall life cycle is consider the entire development as several small incremental steps with continuous planning, requirements, analysis and prototyping to improve the requirements. In this approach, prototyping technique is applied to get user feedbacks before design, testing and evaluation. The software development is being built incrementally, each iteration is built on top of the previous one until all requirements are known. Since the cycle resembled a spiral, thus this was often referred to as the “spiral” method.

All above approaches (Waterfall, Iterative, and spiral) work well in large and medium size project. However for small project, these approaches still take time and may not meet what customer need to have something quick. That is why the Agile approach is created. This approach is still based on iterative and incremental development but requirements and solutions evolve through the collaboration between customers and developers called self organizing cross functional teams. Agile consists of several methods such as Scrum; Extreme Programming (XP); Crystal; Dynamic Systems Development Methodology (DSDM); Adaptive software development; Lean software development; and Feature-driven development. Among them, Scrum is probably the most popular in the software industry. Since I have written several articles about Agile in my blog already, you can review them.