Mô hình xoắn ốc

Bách khoa toàn thư mở Wikipedia
Bước tới: menu, tìm kiếm

Mô hình xoắn ốc (tiếng Anh: spiral model) là quy trình phát triển định hướng rủi ro cho các dự án phần mềm. Kết hợp của thế mạnh của các mô hình khác và giải quyết khó khăn của các mô hình trước còn tồn tại. Dựa trên các mô hình rủi ro riêng biệt của mỗi dự án, mô hình xoắn ốc đưa ra cách áp dụng các yếu tố của một hoặc nhiều mô hình xử lý, chẳng hạn như mô hình gia tốc, mô hình thác nước hoặc mô hình tạo mẫu tiến hóa.

Lịch sử hình thành[sửa | sửa mã nguồn]

Mô hình này lần đầu được Barry Boehm đưa ra trong bài báo năm 1968 với tựa đề "A Spiral Model of Software Development and Enhance[1]". Vào năm 1988, Boehm đã xuất bản một bài báo tương tự cho nhóm đối tượng độc giả rộng hơn. Những bài báo giới thiệu về sơ đồ được tái bản trong nhiều ấn phẩm tiếp theo nhằm thảo luận về mô hình xoắn ốc. Boehm đã đề xuất một mô hình xoắn ốc cung cấp một cách tiếp cận "định hướng rủi ro" để phát triển phần mềm. Mỗi cấp độ trong xoắn ốc liên quan đến việc lập kế hoạch, phân tích, phát hiện rủi ro, hoàn thiện hệ thống và tạo mẫu thêm. Về bản chất, nó mô tả sự phát triển của phần mềm qua các giai đoạn tiến hóa, mỗi giai đoạn được coi như một mô hình thác đổ, được bắt đầu từ những cái khái quát nhất rồi đi dần đến chi tiết.

Dựa trên rủi ro của một dự án từ đó đưa ra một mô hình thích hợp cho việc thực hiện dự án. Như vậy, cộng dồn, thác nước, tạo mẫu, và các mô hình quá trình khác là trường hợp đặc biệt của mô hình xoắn ốc nó phù hợp với các mô hình rủi ro của dự án nhất định.

Boehm cũng xác định một số quan niệm sai lầm phát sinh từ sự đơn giản hóa trong mô hình xoắn ốc ban đầu. Ông cho biết những quan niệm sai lầm rất nguy hiểm:

  • Mô hình xoắn ốc đơn giản chỉ là một chuỗi sự phát triển của mô hình thác nước;
  • Tất cả các hoạt động dự án theo mộttrình tự xoắn ốc đơn;
  • Mọi hoạt động trong sơ đồ phải được thực hiện, và theo thứ tự hiển thị.

Những quan điểm trên có thể phù hợp với một số dự án, tuy nhiên, hầu hết chúng không phù hợp với các dự án phát triển phần mềm hiện nay. Boehm liệt kê một số đặc điểm chung bất biến cho các ứng dụng của mô hình xoắn ốc.

Một vài đặc điểm chung bất biến[sửa | sửa mã nguồn]

Hoạt động của mỗi chu kỳ[sửa | sửa mã nguồn]

Trong mỗi chu kỳ của mô hình xoắn ốc bắt buộc phải xảy ra bốn hoạt động cơ bản này:

  1. Hãy xem xét đến các điều kiện quan trọng nhất của các yếu tố liên quan.
  2. Xác định và đánh giá những phương án khác nhau để thỏa mãn điều kiện đó.
  3. Xác định và giải quyết các rủi ro bắt nguồn từ những phương pháp được lựa chọn.
  4. Có sự chấp thuận của tất cả các bên liên quan, cùng với cam kết sẽ theo đuổi đến cùng các chu kỳ tiếp theo.

Xác định mức độ ảnh hưởng của rủi ro[sửa | sửa mã nguồn]

Đối với bất cứ dự án nào (ví dụ như phân tích các nhu cầu, thiết kế, tạo bản mẫu, thử nghiệm), nhóm dự án phải xác định được cần bao nhiêu nguồn lực là đủ. Trong chu kỳ của quy trình xoắn ốc thực tế, những quyết định này được thực hiện bằng cách giảm thiểu tối đa rủi ro tổng thể.

Ví dụ, việc tăng thêm thời gian thử nghiệm một sản phẩm phần mềm sẽ làm giảm đi rủi ro từ việc thị trường từ chối một sản phẩm kém chất lượng. Tuy nhiên, việc tăng thêm thời gian thử nghiệm này lại dẫn đến một rủi ro khác đó là sự gia nhập của các đối thủ cạnh tranh. Từ góc độ mô hình xoắn ốc, các thử nghiệm cần được thực hiện cho đến khi các rủi ro được giảm thiểu đến mức thấp nhất và không phát sinh trong tương lai.

Xem xét các yêu cầu đặc điểm kỹ thuật cũng là một ví dụ, các dự án chính xác nên xác định những tính năng làm giảm thiểu rủi ro thông qua các thông số chính xác (ví dụ, giao diện giữa phần cứng và phần mềm, giao diện giữa nhà thầu chính và nhà thầu phụ).

Phạm vi của rủi ro này bao gồm các quá trình tiến hóa mà bỏ qua rủi ro từ các vấn đề về khả năng mở rộng, cũng như việc tăng cường đầu tư vào một quá trình kiến trúc kỹ thuật phải được thiết kế lại hoặc thay thế để phù hợp với sự phát triển sản phẩm trong tương lai.

Quy trình hoạt động[sửa | sửa mã nguồn]

Quy trình được chia thành nhiều bước lặp lại, mỗi bước bắt đầu bằng việc lập kế hoạch, phân tích rủi ro, tạo bản mẫu, hoàn thiện và phát triển hệ thống, kiểm định lại và trình tự cứ tiếp tục như vậy. Nội dung của 4 hoạt động chính:

Lập kế hoạch:[sửa | sửa mã nguồn]

Xác định mục tiêu, các ràng buộc và những giải pháp khác nhau để đặt được mục tiêu. Ở bước này ta cần trả lời các câu hỏi:

  1. Làm thế nào để bắt đầu một xoắn ốc?
  2. Khi nào thích hợp chấm dứt dự án?
  3. Tại sao xoắn ốc kết thúc quá đột ngột?
  4. Điều gì sẽ xảy ra khi phần mềm được nâng cấp hoặc bảo trì

Phân tích rủi ro:[sửa | sửa mã nguồn]

Phân tích những rủi ro và khả năng giải quyết (thường là xây dựng bản mẫu). Để xác định rủi ro của mỗi giai đoạn trong mỗi xoắn ốc, Boehm sử dụng mẫu "Spiral Model Template[2]"

Phát triển và triển khai:[sửa | sửa mã nguồn]

Dựa trên việc lập kế hoạch và phân tích rủi ro để từ đó phát triển hệ thống đồng thời phải kiểm tra lại. Giai đoạn này ta nên sử dụng mô hình thác nước để phát triển dự án

Lập kế hoạch cho pha tiếp theo:[sửa | sửa mã nguồn]

Chúng ta xem xét tiến độ và đánh giá thông qua các thông số đã đưa ra ở bước lập kế hoạch. Từ đó, tiếp tục triển khai giải quyết các vấn đề còn lại với quy trình được lặp lại tương tự

Ưu và nhược điểm[sửa | sửa mã nguồn]

Ưu điểm[sửa | sửa mã nguồn]

  • Là mô hình hội tụ các tính năng tốt và khắc phục các yếu điểm của nhiều mô hình phát triển khác gặp phải.
  • Giám sát dự án dễ dàng và hiệu quả
  • Rất phù hợp với dự án có nguy cơ cao và giảm thiểu rủi ro, đối phó với những thay đổi trong quá trình thực hiện dự án
  • Dự đoán về thời hạn và chi phí sát với thực tế

Nhược điểm[sửa | sửa mã nguồn]

  • Phân tích rủi ro khá tốn kém, chủ yếu áp dụng cho dự án lớn, có tiềm lực về tài chính
  • Yêu cầu thay đổi thời xuyên dẫn đến lặp vô hạn, phức tạp, cần có đội ngũ chuyên gia về phân tích rủi ro
  • Chưa được áp dụng rộng rãi như mô hình thác nước, nguyên mẫu.

Tham khảo[sửa | sửa mã nguồn]

  1. ^ “A spiral model of software development and enhancement”. ACM SIGSOFT Software Engineering Notes. Tháng 8 năm 1986. tr. 14-24. 
  2. ^ “A spiral model of software development and enhancement”. tr. 12-14.