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
n →‎Tham khảo: AlphamaEditor, Executed time: 00:00:09.4995434
Thêm nội dung và bỏ thể loại bài sơ khai
Dòng 36: Dòng 36:
# 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ó.
# 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.
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.

=== Tập trung vào hệ thống và chu kỳ sống ===
Đặ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.


== Tham khảo ==
== Tham khảo ==
Dòng 41: Dòng 44:
* {{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}}
* {{Chú thích sách|họ = Carter|tên = Jim A|tựa đề = [[Developing e-Commerce Systems]]|năm = 2001|tháng = 7|trang = 20 - 21|chương = https://www.scribd.com/doc/282853840/Chapter1|ngôn ngữ = tiếng Anh}}{{Sơ khai}}
* {{Chú thích sách|họ = Carter|tên = Jim A|tựa đề = [[Developing e-Commerce Systems]]|năm = 2001|tháng = 7|trang = 20 - 21|chương = https://www.scribd.com/doc/282853840/Chapter1|ngôn ngữ = tiếng Anh}}

Phiên bản lúc 10:16, ngày 30 tháng 9 năm 2015

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. 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, mô hình thác nước, 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". 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 và kiểm tra)

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.

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

  • 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ị.

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.

Một số đặ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 tiên quyết của các bên 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 tiên quyết.
  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.

Sử dụng điểm cố định các giai đoạn quan trọng

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.

  1. 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ó”.
  2. 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ó”
  3. 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.

Tập trung vào hệ thống và chu kỳ sống

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

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)