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

danh mục và trích dẫn nguồn
(chú thích nguồn)
(danh mục và trích dẫn nguồn)
Mô hình vòng xoắn
 
'''Mô hình xoắn ốc''' ([[tiếng Anh]]: ''spiral model'') là quy trình [[Quy trình phát triển phần mềm|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 [[ hình thác nước|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 đề "[http://dl.acm.org/citation.cfm?doid=12944.12948 A Spiral Model of Software Development and Enhance]" (Mô hình xoắn ốc để phát triển và cải tiến phần mềm). 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ỳ ==
Những bài báo trước đó thì sử dụng thuật ngữ "mô hình quy trình" khi đề cập đến mô hình xoắn ốc cũng như mô hình gia tốc, mô hình thác thác nước, mô hình mẫu, và các phương pháp tiếp cận khác. Tuy nhiên, đặc trưng kết hợp phân tích rủi ro cùng với những tính năng của những mô hình khác được thể hiện:
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.
 
# 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.
'''Bốn hoạt động cơ bản của mỗi chu kỳ:'''
# 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à 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.
 
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.
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.
 
== Xác định mức độ ảnh hưởng của rủi ro ==
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.
Đố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.
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.
 
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.
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.
 
== Xác định mức độ rủi ro một cách chi tiết ==
4.Có sự chấp thuận của tất cả
Đố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ể.
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.
 
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)
Chu kỳ của dự án sẽ bỏ sót
hoặc không tận dụng được những nỗ lực giảm thiểu rủi ro bằng việc chọn lựa từ bỏ
các bên liên quan hoặc là sẽ rất mạo hiểm.
 
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.
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.
 
== Sử dụng điểm cố định các giai đoạn quan trọng ==
'''Xác định mức độ ảnh hưởng của rủi ro'''
Mô tả ban đầu của Boehm của mô hình xoắn ốc không bao gồm bất kỳ giai đoạ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ư chỉ số 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 đầ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 chiến thắng? Nếu các bên liên quan đồng ý rằng câu trả lời là "Có", thì dự án đã rà phá mốc LCO này. 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 sự đồng tình câu trả lời là “Có”.
Đố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 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ể.
 
Kiến trúc vòng đời (Life Cycle Architecture). Có một định nghĩa đầy đủ về phương pháp được ưa chuộng để thỏa mãn điều kiện chiến thắng của tất cả mọi người, các rủi ro bị loại bỏ hoặc giảm nhẹ đáng kể nào không? Nếu các bên liên quan đồng ý rằng câu trả lời là "Có", thì dự án đã rà phá mốc LCA này. 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 đạt được câu trả lời là “Có”
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.
 
Khả năng hoạt động ban đầu. Ở đó có đủ chuẩn bị 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 chiến thắng của mọi người bằng cách tung ra hệ 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ó."
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.
 
== Tham khảo ==
'''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 bao gồm bất kỳ giai đoạ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 mà phục vụ như là chỉ số tiến độ và các điểm cam kết.
Những cột mốc điểm neo 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 đầ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 chiến thắng?
Nếu các bên liên quan đồng ý rằng câu trả lời là "Có", thì dự án đã
rà phá mốc LCO này. 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 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ề
phương pháp được ưa chuộng để thỏa mãn điều kiện chiến thắng của tất cả mọi người,
các rủi ro bị loại bỏ hoặc giảm nhẹ đáng kể nào không? Nếu các bên liên quan đồng
ý rằng câu trả lời là "Có", thì dự án đã rà phá mốc LCA này. 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 đạt được câu trả lời là “Có”
 
Khả năng hoạt động ban đầu. Ở đó có đủ chuẩn bị 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 chiến thắng của mọi người
bằng cách tung ra hệ 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ó."
23

lần sửa đổi