Khác biệt giữa bản sửa đổi của “Mô hình xoắn ốc”

Bách khoa toàn thư mở Wikipedia
Nội dung được xóa Nội dung được thêm vào
Không có tóm lược sửa đổi
Nội dung và chú thích nguồn
Dòng 2: Dòng 2:
{{cần biên tập}}
{{cần biên tập}}
{{thiếu nguồn gốc}}
{{thiếu nguồn gốc}}
'''Mô hình xoắn ốc''' ([[tiếng Anh]]: ''spiral model'') là [[Quy trình phát triển phần mềm|quy trình phát triển]] định hướng rủi ro cho các dự án phần mềm. Dựa trên các mô hình rủi ro riêng biệt của mỗi dự án đưa ra, mô hình xoắn ốc chỉ dẫn mỗi nhóm 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, [[ hình thác nước]], hay mô hình xây dựng tiên tiến.
'''Mô hình xoắn ốc''' ([[tiếng Anh]]: ''[[En:Spiral model|spiral model]]'') là qui trình phát triển<ref>[[Quy trình phát triển phần mềm]]</ref> đị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<ref>[[ hình thác nước]]</ref>, hay mô hình xây dựng tiên tiến.


== Lịch sử hình thành ==
== Lịch sử hình thành ==
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 đề "[http://dl.acm.org/citation.cfm?doid=12944.12948 A Spiral Model of Software Development and Enhance]". 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 sơ đồ được tái bản trong nhiều ấn phẩm tiếp theo thảo luận về mô hình xoắn ốc. Boehm đã đề xuất một mô hình xoắn ốc của sự phát triển cung cấp một cách tiếp cận “rủi ro theo định hướng” để 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, và tạo mẫu thêm vào một trong những giai đoạn bình thường của chu kỳ vòng đời phần mềm (phân tích yêu cầu, thiết kế, thực thi kiểm tra)
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<ref>{{Chú thích web|url = http://dl.acm.org/citation.cfm?doid=12944.12948|title = A spiral model of software development and enhancement|first = Boehm B|date = August 1986|publisher = ACM SIGSOFT Software Engineering Notes|page = 14-24}}</ref>". 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 hình thác đổ<ref>[[Mô hình thác đổ]]</ref>, được bắt đầu từ những cái khái quát nhất rồi đi dần đến chi tiết.


Trong các ấn phẩm sau này, Boehm mô tả mô hình xoắn ốc này như một "quy trình kiểu máy phát điện", lựa chọn 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 quá trình 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.
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 quan niệm sai lầm nguy hiểm nhất là:
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;
* 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;
* 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ị.
* Mọi hoạt động trong sơ đồ phải được thực hiện, và theo thứ tự hiển thị.
Trong khi những quan niệm sai lầm có thể phù hợp với các mô hình rủi ro của một vài dự án nhưng chúng thực sự không phù hợp với hầu hết các dự án. Để phân biệt chúng tốt hơn từ "nguy hiểm nhìn như mô hình xoắn ốc", 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.
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 số đặc điểm chung bất biến ==
== Một vài đặc điểm chung bất biến ==


=== Hoạt động của mỗi chu kỳ ===
=== Hoạt động của mỗi chu kỳ ===
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:
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:
# Hãy xem xét đến các điều kiện tiên quyết của các bên liên quan.
# 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.
# Xác định và đánh giá những phương án khác nhau để thỏa mãn điều kiện tiên quyết.
# Xác định và đánh giá những phương án khác nhau để thỏa mãn điều kiện đó.
# 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.
# 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.
# 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.
# 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.
Dòng 33: Dòng 33:
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.
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.


=== Qui trình hoạt động ===
=== Sử dụng điểm cố định các giai đoạn quan trọng ===
Qui 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:
Mô tả ban đầu của Boehm của mô hình xoắn ốc không có bất kỳ quá trình sự kiện quan trọng nào. Trong cải tiến sau này, ông giới thiệu ba cột mốc điểm cố định để thực hiện như các chỉ số đánh giá tiến độ và các điểm cam kết. Những cột mốc điểm có thể được đặc trưng bởi những câu hỏi quan trọng.
# Mục tiêu vòng đời (''Life Cycle Object''). Có một định nghĩa nào đầy đủ cho một cách tiếp cận kỹ thuật và quản lý để đáp ứng điều kiện mọi người đều thắng? Nếu các bên liên quan đồng ý rằng câu trả lời là "Có", thì dự án đã vượt mốc LCO này. Nếu không, dự án có thể bị loại bỏ, hoặc các bên liên quan có thể cam kết một chu kỳ khác để cố gắng để có được sự đồng tình câu trả lời là “Có”.
# Kiến trúc vòng đời (''Life Cycle Architecture''). Có một định nghĩa đầy đủ về cách tiếp cận được ưa chuộng để thỏa mãn điều kiện tất cả mọi người đều thắng, các rủi ro bị loại bỏ hoặc giảm nhẹ đáng kể không? Nếu các bên liên quan đồng ý rằng câu trả lời là "Có", thì dự án đã vượt mốc LCA này. Nếu không, dự án có thể bị loại bỏ, hoặc các bên liên quan có thể cam kết một chu kỳ khác để cố gắng đạt được câu trả lời là “Có”
# Khả năng hoạt động ban đầu (''Initial Operational Capability''). Việc ra mắt một hệ thống đã chuẩn bị đầy đủ các phần mềm, trang web, người sử dụng, vận hành, bảo trì và bảo đảm điều kiện mọi người đều thắng? Nếu các bên liên quan đồng ý rằng câu trả lời là "Có", thì dự án đã được dọn sạch mốc IOC. Nếu không, dự án có thể bị bỏ rơi, hoặc các bên liên quan có thể cam kết một chu kỳ khác để cố gắng có được câu trả lời là  "Có.
LCO đánh dấu ranh giới giữa giai đoạn khởi đầu và lập kế hoạch. LCA đánh dấu ranh giới giữa giai đoạn lập kế hoạch và xây dựng, và IOC đánh dấu ranh giới giữa giai đoạn xây dựng và giai đoạn chuyển tiếp.


==== Lập kế hoạch: ====
=== Tập trung vào hệ thống và chu kỳ sống ===
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:
Đặc điểm này nhấn mạnh tầm quan trọng của các hệ thống tổng thể và những yếu tố ảnh hưởng đến toàn bộ vòng đời của mô hình. Nó không bao gồm những "nguy hiểm nhìn như mô hình xoắc ốc" mà tập trung chủ yếu vào sự phát triển ban đầu của mã phần mềm. Những quá trình này có thể là kết quả sau khi đã đưa ra các phương pháp để định hướng đối tượng hoặc thiết kế và phân tích cấu trúc phần mềm.
# Làm thế nào để bắt đầu một xoắn ốc?
# Khi nào thích hợp chấm dứt dự án?
# Tại sao xoắn ốc kết thúc quá đột ngột?
# Đ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: ====
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<ref>{{Chú thích web|url = http://dl.acm.org/citation.cfm?doid=12944.12948|title = A spiral model of software development and enhancement|page = 12-14}}</ref>”

==== Phát triển và triển khai: ====
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: ====
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 qui trình được lặp lại tương tự


== Tham khảo ==
== Tham khảo ==
{{tham khảo}}
* {{Chú thích web|url = http://dl.acm.org/citation.cfm?doid=12944.12948|title = A spiral model of software development and enhancement|date = August 1986|language = tiếng Anh}}
* {{Chú thích web|url = http://dl.acm.org/citation.cfm?doid=12944.12948|title = A spiral model of software development and enhancement|date = August 1986|language = tiếng Anh}}
* {{Chú thích web|url = https://en.wikipedia.org/wiki/Spiral_model|title = Spiral model|language = tiếng Anh}}
* {{Chú thích web|url = https://en.wikipedia.org/wiki/Spiral_model|title = Spiral model|language = tiếng Anh}}

Phiên bản lúc 06:10, ngày 3 tháng 10 năm 2015

Mô hình xoắn ốc (tiếng Anh: ') là qui trình phát triển[1] đị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[2], hay mô hình xây dựng tiên tiến.

Lịch sử hình thành

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[3]". 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 đổ[4], đượ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

Hoạt động của mỗi chu kỳ

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

Đố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.

Qui trình hoạt động

Qui 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:

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:

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[5]

Phát triển và triển khai:

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:

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 qui trình được lặp lại tương tự

Tham khảo

  • “A spiral model of software development and enhancement” (bằng tiếng Anh). tháng 8 năm 1986.
  • “Spiral model” (bằng tiếng Anh).
  • Carter, Jim A (2001). “https://www.scribd.com/doc/282853840/Chapter1”. Developing e-Commerce Systems (bằng tiếng Anh). tr. 20 - 21. Liên kết ngoài trong |chương= (trợ giúp)
  1. ^ Quy trình phát triển phần mềm
  2. ^ Mô hình thác nước
  3. ^ “A spiral model of software development and enhancement”. ACM SIGSOFT Software Engineering Notes. tháng 8 năm 1986. tr. 14-24. |first= thiếu |last= (trợ giúp)
  4. ^ Mô hình thác đổ
  5. ^ “A spiral model of software development and enhancement”. tr. 12-14.