dinhsinhanh
15-10-09, 05:08 PM
Bài viết này trình bày những mô hình phát triển phần mềm cơ bản.
Một dự án phát triển phần mềm thường trải qua các hoạt động sau đây:
- Phân tích yêu cầu.
- Thiết kế và lập trình.
- Test.
- Bảo trì.
Mỗi mô hình phát triển phần mềm đưa ra một cách tổ chức sắp xếp khác nhau của các hoạt động này.
1. Mô hình thác nước (waterfall)
Đây là mô hình phát triển phần mềm cổ điển nhất. Mô hình này đề nghị các hoạt động được tiến hành như các giai đoạn tách biệt, giai đoạn sau sẽ không bắt đầu chừng nào giai đoạn trước chưa hoàn thành. Sản phẩm đầu ra của giai đoạn trước trở thành đầu vào của giai đoạn sau.http://farm4.static.flickr.com/3235/2974435882_02faa55749_o.jpg
Những mũi tên ngược từ dưới lên trên cho thấy những sai lầm ở giai đoạn trước có thể được phát hiện ở giai đoạn sau và đòi hỏi việc quay ngược lên để làm lại giai đoạn trước. Tuy nhiên ,hoạt động quay lui này chỉ nên được coi là các ngoại lệ mà thôi.
Mô hình thác nước có ưu điểm là dễ quản lí. Đây chính là mô hình ưa thích của các nhà quản lí dự án. Thời gian hoàn thành dự án thường được dự báo với độ chính xác hơn so với các mô hình khác. Các tài liệu đầu ra của từng giai đoạn cũng được xây dựng đầy đủ và hệ thống hơn. Tuy nhiên mô hình này có một số nhược điểm lớn là:
- Mô hình đòi hòi một bản yêu cầu (requirement) đầy đủ và chính xác từ phía khách hàng. Yêu cầu này hiếm khi đạt được bởi khách hàng ít khi xác định được chính xác họ muốn gì ở ngay giai đoạn đầu của dự án, sở thích của họ cũng thay đổi khá thường xuyên. Việc làm lại các giai đoạn ban đầu để đáp ứng sự thay đổi của khách hàng thường mất rất nhiều công sức và phá vỡ cấu trúc của phần mềm.
- Khách hàng cần phải kiên nhẫn. Họ chỉ được tham gia vào dự án ở giai đoạn phân tích yêu cầu và test mà thôi. Ngoài ra, sản phẩm sẽ chỉ được bàn giao khi tất cả các công việc liên quan đã được hoàn thành.
Mô hình thác nước chỉ nên được sử dụng khi đội dự án đã có kinh nghiệm, yêu cầu từ khách hàng được xác định rõ ngay từ đầu và ít có khả năng thay đổi. Hiện nay, mô hình thác nước vẫn được sử dụng rộng rãi do tính gần gũi với các mô hình phát triển trong các ngành kĩ thuật khác.
2. Mô hình tiến hóa (Evolutionary)
Mô hình tiến hóa được đưa ra nhằm giải quyết những khó khăn gây ra do yêu cầu của khách hàng không rõ ràng hoặc hay thay đổi. Ý tưởng của mô hình này là phát triển phẩn mềm qua nhiều phiên bản, mỗi phiên bản được đưa ra lấy ý kiến khách hàng, được sửa chữa, làm mịn cho đến khi đạt được phiên bản hoàn chỉnh.
http://farm4.static.flickr.com/3137/2973583173_9659fbf42f_o.jpg
Mô hình tiến hóa: Các phiên bản 1, 2, 3 có thể rất khác nhau!
Hai kiểu mô hình tiến hóa cơ bản là:
- Khám phá và phát triển (exploratory development): Đội dự án sẽ làm việc cùng khách hàng để khám phá các yêu cầu của họ. Dự án sẽ bắt đầu trước tiên với những yêu cầu đã rõ ràng. Các đặc tính khác sẽ được thêm vào dần dần dựa trên đề nghị của khách hàng.
- Làm bản mẫu để “vứt đi” (throwaway prototyping): Mô hình này được áp dụng cho giai đoạn phân tích yêu cầu. Theo đó, đội dự án sẽ làm các bản mẫu (prototype) để lấy ý kiến khách hàng nhằm kiểm chứng và làm rõ các yêu cầu chưa rõ ràng. Khi đã có một bản yêu cầu hoàn chỉnh, giai đoạn phát triển tiếp theo có thể sử dụng mô hình thác nước.
Mô hình tiến hóa cho phép khách hàng tham gia sâu hơn vào quá trình phát triển, nhờ đó sản phẩm cuối cùng thường phản ánh chính xác mong muốn của khách hàng. Tuy nhiên, mô hình này cũng có các nhược điểm là:
- Khó khăn trong việc thiết kế: Việc phát triển qua nhiều phiên bản có thể phá vỡ kiến trúc tổng thể của phần mềm.
- Khó khăn trong việc quản lí: Các nhà quản lí thích nhìn thấy sản phẩm làm ra trong từng gian đoạn để tiện cho việc quản lí tiến độ. Ngoài ra, các tài liệu mô tả cho từng phiên bản thường không được lập đầy đủ.
- Khó khăn do khách hàng gây ra: Khách hàng có thể nhầm tưởng rằng một bản mẫu có thể tốt gần như sản phẩm thật. Trong thực tế từ bản mẫu đến sản phẩm cuối cùng là một khảng cách xa. Ngoài ra khách hàng có xu hướng đưa thêm vào những yêu cầu không cần thiết.
- Khó khăn về địa lý: Mô hình tiến hóa đòi hỏi đội dự án phải ngồi gần khách hàng. Các dự án outsourcing khó có thể đáp ứng yêu cầu này.
Theo Ian Sommerville (http://www.cs.st-andrews.ac.uk/%7Eifs/) trong cuốn “Software Engineering (http://www.cs.st-andrews.ac.uk/%7Eifs/Books/SE8/index.html)“, mô hình tiến hóa là mô hình phù hợp nhất cho các dự án vừa và nhỏ (dưới 500 000 dòng code). Các dự án lớn và phức tạp nên sử dựng một mô hình kết hợp giữa mô hình thác nước và tiến hóa. Trong đó, các bản mẫu được dùng để làm rõ các yêu cầu của khách hàng. Các yêu cầu đã rõ ràng được tiếp tục phát triển theo mô hình thác nước. Các yêu cầu chưa rõ ràng có thể sử dụng mô hình khám phá và phát triển.
3. Mô hình tăng trưởng (Incremental)
Mô hình tăng trưởng kết hợp những ưu điểm của mô hình thác nước và mô hình tiến hóa. Ý tưởng của mô hình này là phân chia phần mềm thành những phần tăng trưởng (được gọi là các increments) và phát triển, bàn giao chúng lần lượt cho khách hàng theo mức độ quan trọng. Phần tăng trưởng nào đến lượt được phát triển thì những yêu cầu tương ứng sẽ được phân tích. Chỉ những thay đổi từ phía khách hàng cho những phần chưa được phát triển mới được chấp nhận.
http://farm4.static.flickr.com/3179/2973583211_51539da456_o.jpg
Theo Ian Sommerville, mỗi phần tăng trưởng không nên quá 20 000 dòng code và phải mang lại những lợi ích nhất định cho khách hàng. Còn theo Mike Cotterell và Bob Hughes trong “Software Project Management (http://www.amazon.co.uk/Software-Management-Tutorial-computing-information/dp/1850321906/ref=sr_1_3/275-4622645-9975354?ie=UTF8&s=books&qid=1225023453&sr=1-3)”, mỗi phần tăng trưởng nên chiếm từ 1% đến 5% của toàn dự án và không nên kéo dài quá một tháng.
Mô hình tăng trưởng có những ưu điểm sau đây:
- Rút ngắn thời gian chờ đợi của khách hàng. Khách hàng không phải đợi đến khi toàn bộ hệ thống hoàn thành mới được hưởng lợi. Những thành phần quan trọng nhất được bàn giao sớm và mang lại lợi ích sớm hơn cho khách hàng.
- Tăng chất lượng phần mềm. Thành phần quan trọng nhất của hệ thống được phát triển và đi vào hoạt động sớm nhất, bởi vậy nó được test nhiều nhất. Ngoài ra, những ý kiến của khách hàng cũng như kinh nghiệm phát triển các thành phần trước sẽ được áp dụng ngay lập tức cho các thành phần sau.
- Giảm bớt những yêu cầu không cần thiết từ khách hàng. Khi một tính năng chưa có mặt trong hệ thống, họ sẽ nghĩ rằng nó sẽ được tích hợp vào ở những lần bàn giao tiếp theo!
- Tăng năng suất lao động. Nhiều lập trình viên làm việc tốt hơn trong các dự án nhỏ mà họ sớm nhìn thấy thành quả lao động của mình.
Tuy nhiên, mô hình tăng trưởng cũng có nhược điểm là không phải dự án nào cũng có thể được phân chia thành các phần tăng trưởng nhỏ có thể được phát triển và bàn giao tuần tự. Nếu làm không tốt giai đoạn lập kế hoạch và phân tách hệ thống, xung đột giữa các thành phần có thể nảy sinh.
Các biến thể của mô hình tăng trưởng là Agile Development và Extreme Programming.
Ngoài các mô hình phát triển phần mềm cơ bản nói trên còn có các mô hình biến thể như mô hình chữ V (V-model), mô hình xoáy ốc (spiral) hay mô hình tái sử dụng CBSE (component-based software engineering).
Tài liệu tham khảo:
“Software Engineering” của Ian Sommerville
“Software Engineering: A practitioner’s Approach” của Pressman
“Software Project Management” của Cotterell và Hughes
Sưu tầm từ Internet !
Một dự án phát triển phần mềm thường trải qua các hoạt động sau đây:
- Phân tích yêu cầu.
- Thiết kế và lập trình.
- Test.
- Bảo trì.
Mỗi mô hình phát triển phần mềm đưa ra một cách tổ chức sắp xếp khác nhau của các hoạt động này.
1. Mô hình thác nước (waterfall)
Đây là mô hình phát triển phần mềm cổ điển nhất. Mô hình này đề nghị các hoạt động được tiến hành như các giai đoạn tách biệt, giai đoạn sau sẽ không bắt đầu chừng nào giai đoạn trước chưa hoàn thành. Sản phẩm đầu ra của giai đoạn trước trở thành đầu vào của giai đoạn sau.http://farm4.static.flickr.com/3235/2974435882_02faa55749_o.jpg
Những mũi tên ngược từ dưới lên trên cho thấy những sai lầm ở giai đoạn trước có thể được phát hiện ở giai đoạn sau và đòi hỏi việc quay ngược lên để làm lại giai đoạn trước. Tuy nhiên ,hoạt động quay lui này chỉ nên được coi là các ngoại lệ mà thôi.
Mô hình thác nước có ưu điểm là dễ quản lí. Đây chính là mô hình ưa thích của các nhà quản lí dự án. Thời gian hoàn thành dự án thường được dự báo với độ chính xác hơn so với các mô hình khác. Các tài liệu đầu ra của từng giai đoạn cũng được xây dựng đầy đủ và hệ thống hơn. Tuy nhiên mô hình này có một số nhược điểm lớn là:
- Mô hình đòi hòi một bản yêu cầu (requirement) đầy đủ và chính xác từ phía khách hàng. Yêu cầu này hiếm khi đạt được bởi khách hàng ít khi xác định được chính xác họ muốn gì ở ngay giai đoạn đầu của dự án, sở thích của họ cũng thay đổi khá thường xuyên. Việc làm lại các giai đoạn ban đầu để đáp ứng sự thay đổi của khách hàng thường mất rất nhiều công sức và phá vỡ cấu trúc của phần mềm.
- Khách hàng cần phải kiên nhẫn. Họ chỉ được tham gia vào dự án ở giai đoạn phân tích yêu cầu và test mà thôi. Ngoài ra, sản phẩm sẽ chỉ được bàn giao khi tất cả các công việc liên quan đã được hoàn thành.
Mô hình thác nước chỉ nên được sử dụng khi đội dự án đã có kinh nghiệm, yêu cầu từ khách hàng được xác định rõ ngay từ đầu và ít có khả năng thay đổi. Hiện nay, mô hình thác nước vẫn được sử dụng rộng rãi do tính gần gũi với các mô hình phát triển trong các ngành kĩ thuật khác.
2. Mô hình tiến hóa (Evolutionary)
Mô hình tiến hóa được đưa ra nhằm giải quyết những khó khăn gây ra do yêu cầu của khách hàng không rõ ràng hoặc hay thay đổi. Ý tưởng của mô hình này là phát triển phẩn mềm qua nhiều phiên bản, mỗi phiên bản được đưa ra lấy ý kiến khách hàng, được sửa chữa, làm mịn cho đến khi đạt được phiên bản hoàn chỉnh.
http://farm4.static.flickr.com/3137/2973583173_9659fbf42f_o.jpg
Mô hình tiến hóa: Các phiên bản 1, 2, 3 có thể rất khác nhau!
Hai kiểu mô hình tiến hóa cơ bản là:
- Khám phá và phát triển (exploratory development): Đội dự án sẽ làm việc cùng khách hàng để khám phá các yêu cầu của họ. Dự án sẽ bắt đầu trước tiên với những yêu cầu đã rõ ràng. Các đặc tính khác sẽ được thêm vào dần dần dựa trên đề nghị của khách hàng.
- Làm bản mẫu để “vứt đi” (throwaway prototyping): Mô hình này được áp dụng cho giai đoạn phân tích yêu cầu. Theo đó, đội dự án sẽ làm các bản mẫu (prototype) để lấy ý kiến khách hàng nhằm kiểm chứng và làm rõ các yêu cầu chưa rõ ràng. Khi đã có một bản yêu cầu hoàn chỉnh, giai đoạn phát triển tiếp theo có thể sử dụng mô hình thác nước.
Mô hình tiến hóa cho phép khách hàng tham gia sâu hơn vào quá trình phát triển, nhờ đó sản phẩm cuối cùng thường phản ánh chính xác mong muốn của khách hàng. Tuy nhiên, mô hình này cũng có các nhược điểm là:
- Khó khăn trong việc thiết kế: Việc phát triển qua nhiều phiên bản có thể phá vỡ kiến trúc tổng thể của phần mềm.
- Khó khăn trong việc quản lí: Các nhà quản lí thích nhìn thấy sản phẩm làm ra trong từng gian đoạn để tiện cho việc quản lí tiến độ. Ngoài ra, các tài liệu mô tả cho từng phiên bản thường không được lập đầy đủ.
- Khó khăn do khách hàng gây ra: Khách hàng có thể nhầm tưởng rằng một bản mẫu có thể tốt gần như sản phẩm thật. Trong thực tế từ bản mẫu đến sản phẩm cuối cùng là một khảng cách xa. Ngoài ra khách hàng có xu hướng đưa thêm vào những yêu cầu không cần thiết.
- Khó khăn về địa lý: Mô hình tiến hóa đòi hỏi đội dự án phải ngồi gần khách hàng. Các dự án outsourcing khó có thể đáp ứng yêu cầu này.
Theo Ian Sommerville (http://www.cs.st-andrews.ac.uk/%7Eifs/) trong cuốn “Software Engineering (http://www.cs.st-andrews.ac.uk/%7Eifs/Books/SE8/index.html)“, mô hình tiến hóa là mô hình phù hợp nhất cho các dự án vừa và nhỏ (dưới 500 000 dòng code). Các dự án lớn và phức tạp nên sử dựng một mô hình kết hợp giữa mô hình thác nước và tiến hóa. Trong đó, các bản mẫu được dùng để làm rõ các yêu cầu của khách hàng. Các yêu cầu đã rõ ràng được tiếp tục phát triển theo mô hình thác nước. Các yêu cầu chưa rõ ràng có thể sử dụng mô hình khám phá và phát triển.
3. Mô hình tăng trưởng (Incremental)
Mô hình tăng trưởng kết hợp những ưu điểm của mô hình thác nước và mô hình tiến hóa. Ý tưởng của mô hình này là phân chia phần mềm thành những phần tăng trưởng (được gọi là các increments) và phát triển, bàn giao chúng lần lượt cho khách hàng theo mức độ quan trọng. Phần tăng trưởng nào đến lượt được phát triển thì những yêu cầu tương ứng sẽ được phân tích. Chỉ những thay đổi từ phía khách hàng cho những phần chưa được phát triển mới được chấp nhận.
http://farm4.static.flickr.com/3179/2973583211_51539da456_o.jpg
Theo Ian Sommerville, mỗi phần tăng trưởng không nên quá 20 000 dòng code và phải mang lại những lợi ích nhất định cho khách hàng. Còn theo Mike Cotterell và Bob Hughes trong “Software Project Management (http://www.amazon.co.uk/Software-Management-Tutorial-computing-information/dp/1850321906/ref=sr_1_3/275-4622645-9975354?ie=UTF8&s=books&qid=1225023453&sr=1-3)”, mỗi phần tăng trưởng nên chiếm từ 1% đến 5% của toàn dự án và không nên kéo dài quá một tháng.
Mô hình tăng trưởng có những ưu điểm sau đây:
- Rút ngắn thời gian chờ đợi của khách hàng. Khách hàng không phải đợi đến khi toàn bộ hệ thống hoàn thành mới được hưởng lợi. Những thành phần quan trọng nhất được bàn giao sớm và mang lại lợi ích sớm hơn cho khách hàng.
- Tăng chất lượng phần mềm. Thành phần quan trọng nhất của hệ thống được phát triển và đi vào hoạt động sớm nhất, bởi vậy nó được test nhiều nhất. Ngoài ra, những ý kiến của khách hàng cũng như kinh nghiệm phát triển các thành phần trước sẽ được áp dụng ngay lập tức cho các thành phần sau.
- Giảm bớt những yêu cầu không cần thiết từ khách hàng. Khi một tính năng chưa có mặt trong hệ thống, họ sẽ nghĩ rằng nó sẽ được tích hợp vào ở những lần bàn giao tiếp theo!
- Tăng năng suất lao động. Nhiều lập trình viên làm việc tốt hơn trong các dự án nhỏ mà họ sớm nhìn thấy thành quả lao động của mình.
Tuy nhiên, mô hình tăng trưởng cũng có nhược điểm là không phải dự án nào cũng có thể được phân chia thành các phần tăng trưởng nhỏ có thể được phát triển và bàn giao tuần tự. Nếu làm không tốt giai đoạn lập kế hoạch và phân tách hệ thống, xung đột giữa các thành phần có thể nảy sinh.
Các biến thể của mô hình tăng trưởng là Agile Development và Extreme Programming.
Ngoài các mô hình phát triển phần mềm cơ bản nói trên còn có các mô hình biến thể như mô hình chữ V (V-model), mô hình xoáy ốc (spiral) hay mô hình tái sử dụng CBSE (component-based software engineering).
Tài liệu tham khảo:
“Software Engineering” của Ian Sommerville
“Software Engineering: A practitioner’s Approach” của Pressman
“Software Project Management” của Cotterell và Hughes
Sưu tầm từ Internet !