Vòng đời phát triển phần mềm
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.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
