1. Trang chủ
  2. » Công Nghệ Thông Tin

Mô hình xoắn ốc

36 1,1K 2

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 36
Dung lượng 1,62 MB

Nội dung

Mô hình xoắn ốc

Trang 1

ĐẠI HỌC BÁCH KHOA-ĐẠI HỌC ĐÀ NẴNG

KHOA CÔNG NGHỆ THÔNG TIN

MÔ HÌNH XOẮN ỐC

Nhóm 5

Trang 2

của phần mềm qua các giai đoạn tiến

hoá, mỗi giai đoạn được coi như một mô hình thác nước

Trang 3

CÁC KHÁI NIỆM

Mô hình xoắn ốc là mô hình phát triển phần mềm

với trọng tâm là kiểm soát rủi ro qua các chu kỳ

phát triển.

Nó có hai đặc trưng chính

 Dùng cách tiếp cận chu kỳ để phát triển dần mức độ

khái niệm và thực thi của hệ thống trong lúc hạn chế tối

đa sự rủi ro

 Tập hợp các mốc thời gian để đảm bảo cam kết của

các bên liên quan để đi đến một giải pháp giúp hệ

thống khả thi và thỏa mãn các yêu cầu

Rủi ro là các tình huống hoặc sự kiện làm cho dự

án không đáp ứng được mục đích đặt ra.

Trang 4

ĐẶC ĐIỂM MÔ HÌNH

Bản chất mô hình xoắn ốc như tên gọi của nó, là

bắt đầu từ những cái khái quát nhất rồi đi dần

đến chi tiết

Trong quá trình đó có lập kế hoạch cho từng giai

đoạn làm chi tiết hóa sản phẩm và phân tích rủi ro.

Nhấn mạnh việc đánh giá rủi ro

Phần mềm được xây dựng theo nhiều chu kỳ.

Người ta trì hoãn việc xây dựng chi tiết các yếu

tố phần mềm có rủi ro thấp và tránh đổ vỡ không cần thiết trong thiết kế cho đến khi các yếu tố rủi

ro cao trở nên ổn định.

Trang 5

ĐẶC ĐIỂM MÔ HÌNH

của một giai đoạn phát triển phần mềm

 Xác định mục tiêu, các giải pháp khác nhau

để đạt được mục tiêu, các ràng buộc

 Phân tích rủi ro và khả năng giải quyết

(thường là xây dựng bản mẫu)

 Phát triển và kiểm thử sản phẩm của chu kỳ.

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

người ta thường xác định các rủi ro và

cách giải quyết có thể, kết thúc mỗi chu kì

Trang 6

ĐẶC ĐIỂM MÔ HÌNH

phần mềm bằng cách đưa ra các phiên

bản tăng dần:

 Đây không phải là bổ sung thêm các thành

phần mới như mô hình tăng dần

 Đây là sự tiến hóa: cũng các đặc trưng ấy

nhưng được làm mịn hơn, chi tiết hơn, cũng như nêu ra được các rủi ro mới cần giải quyết

 Phiên bản sau cùng chính là phần mềm hoàn

chỉnh có thể chuyển giao cho khách hàng sử dụng

Trang 7

MÔ HÌNH XOẮN ỐC

Trang 8

ngoài cũng theo chiều kim đồng hồ

tích lũy của phần mềm

một pha của quá trình phát triển

Trang 9

GIẢI THÍCH MÔ HÌNH

bên trái (góc 1):

 Xác định các mục tiêu của pha: hiệu suất, tính

năng, khả năng thích nghi với sự thay đổi

 Các giải pháp khác nhau để đạt được các

mục tiêu này: thiết kế A, thiết kế B, tái sử

Trang 10

GIẢI THÍCH MÔ HÌNH

cho giải pháp đã lựa chọn

 Xác định các rủi ro của giải pháp đã chọn.

 Hình thành chiến lược giải quyết rủi ro: tạo

bản mẫu, mô phỏng, kiểm định chuẩn, kiểm tra tài liệu tham khảo, phân tích mô hình hoặc

tổ hợp chúng lại cùng với các kĩ thuật giải

quyết rủi ro khác

 Biện pháp thường được sử dụng là bản mẫu.

Trang 11

GIẢI THÍCH MÔ HÌNH

sang bước tiếp theo: phát triển phần mềm

 Thiết kế sản phẩm từ tổng thể đến chi tiết

 Viết mã cho sản phẩm

 Kiểm thử sản phẩm của từng giai đoạn

phát triển kế tiếp

Trang 12

KHỞI TẠO VÀ KẾT THÚC XOẮN ỐC

trình xem xét cách trình bày của mô hình xoắn ốc:

 Xoắn ốc bắt đầu như thế nào?

 Làm thế nào để có được xoắn ốc thích hợp

để chấm dứt sớm dự án?

 Tại sao xoắn ốc kết thúc quá đột ngột?

 Điều gì xảy ra lúc nâng cấp hoặc bảo trì

phần mềm?

Trang 13

KHỞI TẠO VÀ KẾT THÚC XOẮN ỐC

 Xoắn ốc bắt đầu bằng giả thiết rằng một công

việc thực tế có thể được giải quyết hiệu quả bởi một phần mềm.

 Nếu rủi ro lớn và không có biện pháp khắc

phục thì dự án phải dừng lại.

 Trong một số trường hợp, dự án vẫn được

tiếp tục nhưng với quy mô nhỏ hơn

Trang 14

CÁC RỦI RO CƠ BẢN VÀ HƯỚNG GIẢI QUYẾT

 Thất bại về nhân sự

 Tuyển dụng nhân sự cao cấp, đào tạo lẫn nhau,xây dựng nhóm,

có đầy đủ nhân sự với các chức năng khác nhau.

 Thời gian biểu và ngân sách không thực tế

 Thiết lập kế hoạch và đánh giá chi phí thật chi tiết; phát triển dần dần; tái sử dụng; theo sát yêu cầu,

 Phát triển các chức năng không phù hợp

 Phân tích kĩ tổ chức, nhiệm vụ của phần mềm; xây dựng các khái niệm; thường xuyên trao đổi với người sử dụng và có tài liệu

hướng dẫn sử dụng sớm

 Phát triển giao diện người dùng không thích hợp

 Cần phân tích các công việc, xây dựng các hình mẫu trước; đặc điểm người sử dụng (chức năng, phong cách, khối lượng công việc)

 Sự mạ vàng (thêm vào các yêu cầu không cần thiết)

 Theo sát yêu cầu, tạo bản mẫu; phân tích chi phí có ích; thiết kế chi phí

Trang 15

CÁC RỦI RO CƠ BẢN VÀ HƯỚNG GIẢI QUYẾT

Tiếp tục thay đổi yêu cầu

 Giới hạn việc thay đổi lớn; che giấu thông tin; phát triển dần dần

Thiếu các thành phần tiện nghi ngoài

 Cần phải kiểm định, đo lường, kiểm tra tài liệu tham

khảo,phân tích khả năng tương thích.

Thiếu yêu cầu đặt ra

 Phát triển các phần ổn định trước; kiểm tra tài liệu

tham khảo; chi phí trong hợp đồng,

Vấn đề về hiệu suất

 Cần phải mô phỏng, đo lường, thử nghiệm

Đòi hỏi vượt quá sự đáp ứng của công nghệ

hiện hành

Trang 16

KẾ HOẠCH QUẢN LÝ RỦI RO

ro, lên kế hoạch và kết quả hàng tháng

Trang 17

ƯU ĐIỂM

phần thiết yếu trong quy trình xoắn ốc để

tăng độ tin cậy của dự án

Trang 18

ƯU ĐIỂM

Nó được xem như là một mô hình tổng hợp của

các mô hình khác Không chỉ áp dụng cho phần mềm mà còn phải cho cả phần cứng

Một rủi ro nào đó không được giải quyết thì

chấm dứt dự án

Các vòng tròn được lặp để đáp ứng được thay

đổi của người dùng

Kiểm soát rủi ro ở từng giai đoạn phát triển

Đánh giá chi phí chính xác hơn các phương

pháp khác

Trang 19

thác nước hay là bản mẫu

Trang 20

PHẠM VI ÁP DỤNG

 Trước hết, phân tích rủi ro sẽ tốn kém, do đó mô hình chỉ

có thể áp dụng cho các dự án lớn, khi mà chi phí phân tích rủi ro là không đáng kể so với tổng chi phí toàn bộ dự án

 Với các dự án kí hợp đồng thì nhà phát triển và khách

hàng phải phân tích rủi ro trước khi hợp đồng được kí, và

mô hình xoắn ốc là một lựa chọn phù hợp để thực hiện

điều này

 Mô hình này chỉ nên áp dụng nếu công ty phần mềm có

một đội ngũ chuyên gia phân tích rủi ro trình độ cao.

 Có thể rủi ro vẫn còn nhưng nhà phát triển lại chủ quan cho rằng

đã hết và có thể mắc sai lầm

 Ngoài ra, phát triển game là một lĩnh vực mà ở đó mô hình xoắn ốc được sử dụng và rất cần thiết bởi vì kích thước và mục tiêu của những dự án lớn liên tục thay đổi.

Trang 21

MÔ HÌNH XOẮN ỐC WINWIN

tiếp của nhà phát triển và khách hàng là vô cùng cần thiết

khách hàng những gì họ cần và khách hàng cung cấp đầy đủ chi tiết để tiến hành

triển và khách hàng bước vào quá trình đàm phán

Trang 22

MÔ HÌNH XOẮN ỐC WINWIN

hai bên cùng thắng (thỏa mãn):

 Khách hàng có phần mềm thỏa mãn yêu cầu

 Nhà phát triển có kinh phí thỏa đáng và thời gian

hợp lý.

thống:

 Xác định các cổ đông chủ yếu

 Xác định điều kiện thắng của cổ đông

 Thỏa hiệp điều kiện thắng của các bên liên quan

 bộ điều kiện cùng thắng cho tất cả các bên để

Trang 23

MÔ HÌNH XOẮN ỐC WINWIN

Trang 24

MÔ HÌNH XOẮN ỐC WINWIN

Cùng với đàm phán sớm, mô hình xác định 3 mốc

quy trình để hoàn thành chu kì xoắn ốc và các

mốc quyết định

 Mục tiêu chu kì sống (life cycle objectives):

• xác định một tập các mục tiêu cho mỗi hoạt động chính của công nghệ phần mềm

 Kiến trúc chu kỳ sống ( life cycle architecture)

• Thiết lập các mục tiêu phải được đáp ứng khi các kiến trúc hệ thống và phần mềm được xác định

 Khả năng vận hành ban đầu (Initial operational

capability)

• trình bày một tập các mục tiêu liên quan đến sự chuẩn bị phần mềm để cài đặt/phân phối, chuẩn bị trước khi cài đặt và hỗ trợ theo yêu cầu của tất cả các bên sử dụng hoặc cung cấp phần

Trang 25

ỨNG DỤNG THỰC TẾ

(the TRW Software Productivity Project)

các cộng sự trong TRW đã mô tả tổ chức của một dự án phần mềm mà mục tiêu là phát triển một môi trường để làm tăng

năng suất phần mềm gấp 2 lần trong 5

năm và gấp 4 lần trong 10 năm

Trang 26

ỨNG DỤNG THỰC TẾ (TRW-SPS)

nghệ phần mềm tích hợp với nhiều công

cụ phục vụ quá trình phát triển phần mềm

 Dự án có quy mô lớn, phức tạp

 Mục đích chưa rõ ràng, cụ thể

 Số tiền đầu tư lớn

 Thời gian thực hiện dài (trên 4 năm)

 Tồn tại nhiều rủi ro trong quá trình thực hiện

Trang 27

Vậy mô hình xoắn ốc đã được áp dụng

như thế nào trong dự án này?

Trang 28

CHU KÌ 0 - NGHIÊN CỨU KHẢ THI

Mục tiêu _ Năng suất phần mềm tăng đáng kể

Các ràng buộc _ Chi phí hợp lý_ Phù hợp với văn hóa phần mềm của TRW

• Sự giao ước với chính phủ, kĩ thuật cao, hướng tới con người, bảo mật

Các rủi ro _ Sự cải tiến không có tác dụng cao_ Sự cải thiện này xung đột với các ràng buộc

Giải pháp giải quyết rủi ro

_ Những cái nhìn tổng quát xung quanh _ Phân tích chi phí của mô hình

_ Phân tích các ngoại lệ của dự án _ Tìm kiếm tài liệu

Kết quả giải quyết rủi ro

_ Một vài giải pháp thay thế không khả thi

• Hệ thống chia sẻ thời gian riêng rẽ: tính bảo mật?

_ Kết hợp các giải pháp có thể tạo ra lợi nhuận đáng kể:

• Tăng gấp hai lần trong 5 năm _ Cần nghiên cứu sâu hơn nữa để xác định kết hợp tốt nhất

Lập kế hoạch cho pha tiếp

theo

_ Cần lực lượng đặc biệt 6 người trong 6 tháng _ Khảo sát và phân tích rộng hơn

• Bên trong, bên ngoài, kinh tế.

_ Phát triển khái niệm của quá trình sản xuất, nhân tố kinh tế

Trang 29

CHU KÌ 1 - HÌNH THÀNH KHÁI NIỆM CÔNG

• Hợp đồng chính phủ, công nghệ cao, hướng con người, bảo mật.

_ Sự ưu đãi dành cho các sản phẩm TRW

Giải pháp giải quyết rủi ro _ Nghiên cứu và kiểm tra bên ngoài rộng rãi_ Kiểm định tiêu chuẩn mạng LAN TRW

_ Lập ra dự án định giá cho các máy trạm

Kết quả giải quyết rủi ro _ Khái niệm công việc: Các văn phòng riêng, LAN TRW, đầu cuối cá nhân, VAX_ Bắt đầu với các dumb terminal chính; làm thí nghiệm với các máy trạm thông minh.

_ Trì hoãn chưa quan tâm đến hệ điều hành, lựa chọn công cụ.

Kế hoạch cho pha tiếp theo

_ Phân chia nỗ lực vào môi trường phát triển phần mềm (SDE), thiết bị, quản lý _ Phát triển lát cắt thứ nhất, nguyên mẫu SDE

• Từ thiết kế đến chi phí: 15 người 1 đội trong vòng 1 năm _ Kế hoạch sử dụng bên ngoài

_ Phát triển nguyên mẫu (bản mẫu) SDE

Trang 30

CHU KÌ 2 - CÁC ĐẶC TẢ YÊU CẦU MỨC

ĐỈNH

Mục tiêu

_ Hệ thống thân thiện với người sử dụng.

_ Phân mềm được tích hợp sẵn, các công cụ tự động hóa văn phòng _ Hỗ trợ tất cả nhân viên của dự án

_ Hỗ trợ tất cả các pha của chu kì sống.

Các ràng buộc _ Chuyển giao SDE cho khách hàng => có tính khả chuyển_ Ổn định, dịch vụ đáng tin cậy

Các thay thế _ Hệ điều hành: VMS/AT&T Unix/Berkeley Unix/ISC _ Máy chủ (Host-target)/ tập hợp đầy đủ các công cụ portable

_ Các máy trạm: Zenith/LSI-11/…

Các rủi ro

_ Không phù hợp với nhu cầu, mức ưu tiên của người sử dụng dự án.

_ Hệ thống không thân thiện với người dùng

• Hội chứng 12 ngôn ngữ, chỉ dành cho các chuyên gia _ Hiệu suất thực thi của Unix, hỗ trợ tính tương thích với máy trạm/máy tính lớn

Giải pháp giải quyết rủi

ro

_ Khảo sát người dùng dự án.

_ Khảo sát các tổ chức sử dụng UNIX _ Nghiên cứu máy trạm.

Kết quả giải quyết rủi

ro

_ Đặc tả yêu cầu mức độ cao _ Host-target sử dụng Unix host _ Máy trạm nền tảng UNIX _ Xây dựng sự thân thiện người dùng cho UNIX _ Tập trung vào các công cụ để hỗ trợ sớm các pha.

Kế hoạch cho pha tiếp

theo

Toàn bộ kế hoạch phát triển

• Về các công cụ: SREM, RTT, PDL, các công cụ giúp đỡ tự động hóa.

• Về người dùng cuối: cung cấp các công cụ

• Mạng LAN: trang thiết bị, phương tiện

Trang 31

CÁC VÒNG KẾ TIẾP

Đặc tả thiết kế sơ bộ với RTT:

 RTT thiết lập sự lần vết giữa các trường hợp đặc tả yêu cầu phần mềm, thiết kế các thành phần, mã hóa các thành phần và kiểm thử Nó hỗ trợ nhiều truy vấn liên quan, phân tích và báo cáo khả năng của các thế

hệ Đặc tả thiết kế sơ bộ với RTT ( và hầu hết các

công cụ khác của hệ thống sản xuất phần mềm hiệu quả) nhìn sẽ khác các đặc tả thiết kế sơ bộ thông

thường, nó có xu hướng trình bày các mức xây dựng thống nhất của tất cả các thành phần của thiết kế

Còn mức độ chi tiết của đặc tả RTT là hướng đến

kiểm soát rủi ro.

Trang 32

CÁC VÒNG KẾ TIẾP

mục đơn vị (UDF):

 Công cụ UDF tập hợp vào một thư mục điện tử tất cả

các thứ liên quan đến sự phát triển của đơn vị phần mềm được lập trình riêng rẽ (thường từ 500 đến

1000 chỉ lệnh): đơn vị yêu cầu, thiết kế, mã hóa, các trường hợp kiểm thử, kết quả kiểm thử và tài liệu

hướng dẫn Nó cũng bao gồm một khuôn mẫu quản

lý để theo vết thời gian biểu của lập trình viên và thực

tế hoàn thành của các vấn đề.

Trang 33

KẾT QUẢ DỰ ÁN

1,300,000 lệnh; 93% các lệnh được sử

dụng lại từ các dự án đã được TRW phát triển trước đó, hoặc các gói phần mềm

Trang 34

KẾT QUẢ DỰ ÁN

đó là các dự án với hệ thống đích không phải là Unix sẽ không chấp nhận hệ thống chủ dựa vào Unix Kết quả là hệ thống đã không được sử dụng phổ biến vào các dự

án TRW như mong đợi

Trang 35

quản lý tại mọi giai đoạn của dự án, và nếu được áp dụng đúng thì có thể làm giảm rủi ro trước khi những rủi ro này trở thành vấn

đề thực sự.

 Tóm lại, tài liệu kiểm soát rủi ro, các đặc tả chủ yếu, kế hoạch,

đánh giá kết quả sản phẩm thường xuyên của nhà phát triển và

Trang 36

TÀI LIỆU THAM KHẢO

and Enhancement (Barry W Boehm, TRW

Defense Systems Group)

Sommerville)

Ngày đăng: 20/02/2016, 23:28

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w