Khác biệt giữa bản sửa đổi của “Thành viên:Haiyen2411/Trang nháp”

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
nKhông có tóm lược sửa đổi
Dòng 43: Dòng 43:
== Tham khảo ==
== Tham khảo ==
{{Tham khảo|tác giả = Bohm|tên = A sprial model}}
{{Tham khảo|tác giả = Bohm|tên = A sprial model}}
*{{Sơ khai}}[[Thể loại|Thể loại: Qui trình phát triển phần mềm]]
*{{Sơ khai}}

Phiên bản lúc 17:42, ngày 8 tháng 10 năm 2015

Mô hình vòng xoắn

Mô hình xoắn ốc (tiếng Anh: spiral model) là quy trình mô hì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 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 của ông với tựa đề "A Spiral Model of Software Development and Enhance".<ref> [http://dl.acm.org/citation.cfm?doid=12944.12948/Boehm B, "A spiral model of software development and enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, August 1986] </ref>

Vào năm 1988 Boehm đã xuất bản một bài báo tương tự cho một đố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  vòng xoắn của sự phát triển mà 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, rủi ro, phân tích, 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)

Bốn hoạt động của mỗi chu kỳ

Quy tắc bất di bất dịch của bốn hoạt động cơ bản này đó là nó bắt buộc phải xảy ra trong mỗi chu kỳ của mô hình xoắn ốc.

  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.

Một  số phạm vi bất biến của “rủi ro xoắn ốc tương tự” bắt nguồn từ việc loại bỏ sự ảnh hưởng của các bên liên quan từ các giai đoạn tuần tự nhất định hoặc trong chu kỳ. Ví dụ, những người duy trì hệ thống hay các quản trị viên có thể sẽ không được tham dự vào sự xác định và phát triển hệ thống. Kết quả là những hệ thống sẽ không thỏa mãn được điều kiện tiên quyết được đặt ra.

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.

Phạm vi của “Rủi ro xoắn ốc tương tự” 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 các quá trình tăng cường đầu tư vào một 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ự gia tăng trong tương lai của sản phẩm.

Xác định mức độ rủi ro một cách chi tiết

Đối với bất kỳ hình thành một dự án (ví dụ: các yêu cầu đặc điểm kỹ thuật, tài liệu thiết kế, kế hoạch kiểm tra) các nhóm dự án phải quyết định bao nhiêu chi tiết là đủ. Trong chu kỳ quy trình xoắn ốc đích thực, những quyết định này được thực hiện bằng cách giảm thiểu rủi ro tổng thể.

Xem xét các yêu cầu đặc điểm kỹ thuật như là một ví dụ, các dự án chính xác nên xác định những tính năng mà rủi ro được giảm đi thông qua 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 chính và nhà thầu phụ). Ngược lại dự án không nên cụ thể những tính năng mà những đặc điểm kỹ thuật chính xác tăng nguy cơ (ví dụ: bố trí màn hình đồ họa)

Mô tả ban đầu của Boehm của mô hình xoắn ốc không bao gồm bất kỳ sự kiện quan trọng quá trình.

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.

Tham khảo