MÔ HÌNH XOẮN ỐC: LỊCH SỬ, ĐẶC ĐIỂM, GIAI ĐOẠN, VÍ DỤ - CÔNG NGHỆ - 2026

Các mô hình xoắn ốc là một nguyên mẫu của quá trình phát triển ứng dụng. Nó dựa trên giả thuyết rằng phát triển phần mềm là một chu trình lặp đi lặp lại cho đến khi đạt được các mục tiêu đã thiết lập. Nó có khả năng xử lý số lượng lớn rủi ro có thể xảy ra khi phát triển bất kỳ phần mềm nào.

Nó là một trong những mô hình quan trọng nhất để hỗ trợ quản lý rủi ro. Như tên gọi của nó, mô hình này được thể hiện dưới dạng hình xoắn ốc, nơi các giai đoạn khác nhau của mô hình được phân bố theo các chu kỳ khác nhau. Số chu kỳ trong mô hình không cố định và có thể thay đổi tùy theo từng dự án.

Phân tích, đánh giá, lập kế hoạch và phát triển. Nguồn xoắn ốc phát triển phần mềm: Beao commons.wikimedia.org

Lịch sử

Sự sáng tạo

Mô hình xoắn ốc được xác định bởi nhà toán học và giáo sư kỹ thuật phần mềm người Mỹ Barry Boehm. Sau khi trình bày khái niệm của mình vào năm 1986 về sự phát triển của các ứng dụng phức tạp, ông đã công bố mô hình của mình vào năm 1988 trong một khuôn khổ toàn diện hơn trong bài báo "Mô hình xoắn ốc về phát triển và cải tiến phần mềm".

Một phần của ấn phẩm năm 1988 này đã mô tả bằng hình ảnh mô hình xoắn ốc, cho thấy một cách toàn diện quá trình phát triển phần mềm trông như thế nào theo kiểu xoắn ốc và được hỗ trợ bởi các chu trình.

Boehm được biết đến với nhiều đóng góp trong lĩnh vực kỹ thuật phần mềm, chẳng hạn như mô hình chi phí xây dựng (COCOMO), mô hình xoắn ốc của quy trình phần mềm, phương pháp G-Theory (win-win) để xác định và quản lý yêu cầu. của phần mềm.

Thay thế cho mô hình thác nước

Trong ấn phẩm của mình, Boehm đã mô tả mô hình xoắn ốc như một giải pháp thay thế khả dĩ cho mô hình thác nước đã được thiết lập trước đó, cũng là cơ sở cho việc thực hành của ông.

Mô hình xoắn ốc không phải là mô hình đầu tiên thảo luận về sự phát triển theo chu kỳ, nhưng nó là mô hình đầu tiên giải thích tại sao sự lặp lại quan trọng. Theo kế hoạch ban đầu, nó đã được nhắm mục tiêu vào các dự án lớn, phức tạp có thời gian lặp lại thường từ 6 tháng đến 2 năm.

Mô hình này không cho rằng các nhiệm vụ phát triển phần mềm được thiết kế tuyến tính, không giống như mô hình thác nước, mà coi chúng là các nhiệm vụ lặp đi lặp lại.

Mô hình tuần hoàn này ảnh hưởng đến Kiến trúc Kỹ thuật Phần mềm Dựa trên Mô hình (MBASE) và lập trình cực đoan.

Đặc điểm của mô hình xoắn ốc

Kiểm soát rủi ro

Điều khác biệt đáng kể của mô hình này với các mô hình quy trình phần mềm khác là nó nhận ra rủi ro một cách rõ ràng. Do đó, nó làm giảm đáng kể sự thất bại của các dự án phần mềm lớn bằng cách liên tục đánh giá rủi ro và xác minh sản phẩm đang phát triển mỗi lần.

Mô hình máy tính này chứa các thành phần từ hầu hết các mô hình khác của vòng đời phần mềm, chẳng hạn như mô hình thác nước, mô hình tạo mẫu, mô hình lặp lại, mô hình tiến hóa, v.v.

Do đó, nó có khả năng xử lý hầu hết mọi loại rủi ro mà các mô hình khác thường không xử lý được. Tuy nhiên, do có nhiều thành phần nên mô hình này phức tạp hơn nhiều so với các mô hình phát triển phần mềm khác.

Mô tả của xoắn ốc

Mỗi vòng xoắn đại diện cho một chu trình hoàn chỉnh, qua đó bốn góc phần tư luôn đi qua, đại diện cho bốn giai đoạn của mô hình.

Khi kích thước của vòng xoắn tăng lên, thì tiến trình đạt được cũng vậy. Do đó, các giai đoạn không được thực hiện chỉ một lần mà nhiều lần, theo kiểu xoắn ốc.

Mặc dù sự lặp lại theo chu kỳ này làm cho dự án chậm tiếp cận các mục tiêu đã thiết lập, rủi ro mà quá trình phát triển thất bại được giảm thiểu một cách mạnh mẽ.

Chung

Bốn giai đoạn chỉ thực hiện các mục tiêu cơ bản của một chu kỳ, nhưng chúng không phải được thể hiện trong mỗi chu kỳ.

Thứ tự của mỗi chu kỳ cũng không được xác định chặt chẽ. Do đó, mô hình có thể được kết hợp bất cứ lúc nào với các mô hình khác.

Linh hoạt

Nó khá linh hoạt, vì nó thực hiện các quá trình xác định mục tiêu, phân tích rủi ro, phát triển và lập kế hoạch riêng cho từng giai đoạn của dự án.

Metamodel

Nó được coi là một siêu mô hình vì nó bao gồm các mô hình khác. Ví dụ, nếu hình xoắn ốc là một chu kỳ đơn, nó sẽ đại diện cho mô hình thác nước, vì nó kết hợp cách tiếp cận dần dần của mô hình cổ điển này.

Anh ta cũng sử dụng phương pháp tiếp cận mô hình tạo mẫu, vì vào đầu mỗi chu kỳ, anh ta tập hợp một mẫu thử nghiệm để quản lý rủi ro.

Hơn nữa, nó tương thích với mô hình tiến hóa, vì các lần lặp lại của vòng xoắn có thể được coi là các cấp độ tiến hóa, qua đó hệ thống cuối cùng được xây dựng.

Các giai đoạn

Xác định mục tiêu, lựa chọn thay thế và ràng buộc

Yêu cầu hệ thống được xác định càng chi tiết càng tốt, bao gồm hiệu suất, giao diện phần cứng / phần mềm, các chỉ số chính về thành công, v.v. và những mục tiêu nào nên gắn với chu kỳ phát triển hiện tại được xem xét.

Ngoài ra, các lựa chọn thay thế khác nhau cho việc triển khai nó cũng được kiểm tra, chẳng hạn như build vs. mua, sử dụng lại các thành phần hiện có hoặc thuê ngoài, v.v.

Tương tự như vậy, các hạn chế như chi phí, lịch trình và giao diện, tiêu thụ thời gian, v.v. được xác định.

Đánh giá rủi ro

Tất cả các lựa chọn thay thế được đề xuất đều được đánh giá. Các mục tiêu và ràng buộc đóng vai trò xác định các tham chiếu để chọn giải pháp tốt nhất.

Ngoài ra, các rủi ro có thể cản trở sự thành công của dự án cũng được xác định, chẳng hạn như thiếu kinh nghiệm, công nghệ mới, lịch trình chặt chẽ, thiếu quy trình, v.v., thực hiện các chiến lược có lợi nhất với rủi ro thấp nhất.

Cuối cùng, các phương pháp như tạo mẫu, mô phỏng, mô hình phân tích và khảo sát người dùng được sử dụng.

Phát triển và thử nghiệm

Tất cả các phát triển cần thiết được thực hiện, sử dụng công nghệ và giải pháp đã chọn. Với mỗi lần lặp lại, một phiên bản ứng dụng tốt hơn được tạo ra.

Mã thực tế được viết và kiểm tra nhiều lần cho đến khi đạt được kết quả mong muốn, sau đó sẽ làm cơ sở cho các bước phát triển sau này.

Lập kế hoạch cho chu kỳ tiếp theo

Sau khi hoàn thành một chu kỳ, bắt đầu lập kế hoạch cho chu kỳ tiếp theo. Việc lập kế hoạch này có thể được tiếp tục với dự án một cách bình thường nếu mục tiêu của chu trình đã đạt được, xem xét định nghĩa của mục tiêu tiếp theo.

Nó cũng có thể là để tìm các giải pháp khác, nếu giai đoạn phát triển trước đó bị lỗi. Chiến lược hiện tại có thể được thay thế bằng một trong những lựa chọn thay thế đã xác định trước đó hoặc một chiến lược mới. Với điều này, một nỗ lực mới để đạt được mục tiêu đã cho sẽ được bắt đầu.

Thí dụ

Quân đội Hoa Kỳ đã áp dụng mô hình xoắn ốc để phát triển và nâng cấp chương trình hiện đại hóa Hệ thống Chiến đấu Tương lai (SCF).

Chính thức ra mắt vào năm 2003, SCF được hình dung để trang bị cho quân đội các phương tiện kết nối trong thời gian thực với một mạng lưới chiến trường cực kỳ nhanh chóng và linh hoạt.

Dự án được chia thành bốn vòng xoáy phát triển, mỗi vòng khoảng hai năm. Spiral 1 được lên kế hoạch bắt đầu vào năm 2008 và cung cấp các nguyên mẫu để sử dụng và đánh giá.

Sau khi hoàn thành vòng xoắn 1, vòng xoắn 2 được lên kế hoạch bắt đầu vào năm 2010. Việc phát triển sản phẩm cuối cùng dự kiến ​​sẽ được giao vào năm 2015.

Vào tháng 8 năm 2005, Boeing thông báo hoàn thành cột mốc quan trọng đầu tiên của dự án, đó là đại tu chức năng của các hệ thống. Boeing và Tập đoàn Quốc tế Ứng dụng Khoa học là đồng lãnh đạo của dự án.

Tuy nhiên, vào tháng 10 năm 2005, Lầu Năm Góc đã khuyến nghị trì hoãn dự án do ảnh hưởng lớn đến chi phí từ cuộc chiến Iraq và viện trợ từ cơn bão Katrina.

Dự án đã bị hủy bỏ vào năm 2009 sau khi cắt giảm ngân sách mà không thể chứng minh được lợi ích của mô hình xoắn ốc trong nhiệm vụ này

Lợi thế

Cấu trúc tuần hoàn

Do kiểu cấu trúc này, các vấn đề giữa thiết kế và yêu cầu kỹ thuật của phần mềm được loại bỏ ngầm, nhờ vào việc kiểm tra định kỳ.

Quản lý rủi ro

Các rủi ro được phân tích ở từng giai đoạn của sản phẩm trước khi tiếp tục. Điều này giúp khắc phục hoặc giảm thiểu rủi ro tiềm ẩn.

Tất cả nhân viên đều được hưởng lợi từ tầm quan trọng to lớn của phân tích rủi ro trong mô hình này, có thể thể hiện lợi thế lớn nhất của họ so với các mô hình quy trình khác.

Đánh giá rủi ro thường xuyên có giá trị khi sử dụng các môi trường kỹ thuật mới, thường liên quan đến khả năng rủi ro cụ thể do không có các giá trị thực nghiệm.

Sự tham gia và phản hồi của khách hàng

Khách hàng được tham gia vào từng giai đoạn của dự án, cho đến khi dự án hoàn thành. Do đó, các phản hồi khác nhau có thể được thu thập để cải thiện phiên bản tiếp theo của dự án.

Ngoài ra, phản hồi có thể được thu thập bất cứ lúc nào do tiến trình hình xoắn ốc. Do đó, khách hàng và người dùng có thể được tích hợp ngay từ đầu trong quá trình phát triển.

Lý tưởng cho các dự án lớn

Nó đặc biệt phổ biến và nổi bật đối với các dự án lớn và phức tạp, nơi mà việc kiểm soát ngân sách là ưu tiên của khách hàng và nhà phát triển. Bạn có quyền kiểm soát tối đa chi phí, tài nguyên và chất lượng của dự án phần mềm.

Nhược điểm

Đắt

Nó có thể khá tốn kém, vì nó đòi hỏi trình độ chuyên môn cao để phân tích rủi ro. Ngoài ra, các dự án mất rất nhiều thời gian để phát triển, điều này có thể làm tăng chi phí.

Khá phức tạp

Cần phải có sự quản lý trước rất tích cực và phức tạp của dự án, trong đó mỗi chu trình được kiểm soát và ghi chép lại một cách liên tục và cẩn thận.

Nó tương đối phức tạp hơn các mô hình khác, bởi vì có nhiều chu kỳ, mỗi chu kỳ trải qua các giai đoạn khác nhau, do đó làm tăng nỗ lực của quá trình tài liệu hóa.

Kiến thức về phân tích và quản lý rủi ro thường không có sẵn là điều cần thiết.

Quản lý thời gian

Rất khó quản lý thời gian vì số chu kỳ không xác định. Ngoài ra, quá trình phát triển có thể bị trì hoãn bất cứ lúc nào nếu các quyết định quan trọng phải được thực hiện trong một chu kỳ hoặc bằng các hành động bổ sung khi lập kế hoạch cho chu kỳ tiếp theo.

Nhiều bước

Thực hiện nhiều bước trong quá trình phát triển phần mềm không phải lúc nào cũng thuận lợi bởi vì, mặc dù tính linh hoạt của thử nghiệm, các phần chưa hoàn thành của chương trình có thể đến được hệ thống hoàn thiện.

Do đó, luôn có nguy cơ rằng bất kỳ lỗi khái niệm hoặc sự không nhất quán nào sẽ ảnh hưởng đến sản phẩm cuối cùng.

Người giới thiệu

1. Victor Font Jr (2019). Mô hình xoắn ốc. Hướng dẫn cơ bản về SDLC. Lấy từ: ulatesdlc.com.
2. Ionos (2019). Mô hình xoắn ốc: mô hình quy trình phát triển phần mềm hướng rủi ro. Lấy từ: ionos.com.
3. Techuz (2018). Mô hình xoắn ốc là gì? Giải thích đơn giản về vòng đời phát triển phần mềm xoắn ốc (SDLC). Lấy từ: techuz.com.
4. Thử nghiệm một lần (2020). Mô hình xoắn ốc. Lấy từ: onestoptesting.com.
5. Geeks cho Geeks (2020). Kỹ thuật phần mềm - Mô hình xoắn ốc. Lấy từ: geeksforgeeks.org.
6. Chandu (2019). Mô hình xoắn ốc trong Kỹ thuật phần mềm. Lấy từ: medium.com.