Mô hình xoắn ốc (spiral model)

Mô hình xoắn ốc (spiral model)

Nhóm 2 Date:10/9/2015

KHOA CÔNG NGH THÔNG TIN Ệ

Mô hình xoắn ốc do Boehm đề xuất năm 1988

Là sự kết hợp tính lặp của mô hình nguyên mẫu

và tính hệ thống của mô hình thác nước

Về bản chất,mô hình 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ư là một mô hình thác nước

Mô hình xoắn ốc là một trong những ứng viên cho mô hình phát triển phần mềm hiện tại

 Mô hình xoắn ốc là mô hình phát triển phần mềm kết hợp các yếu tố của thiết kế và tạo mẫu trong mỗi giai đoạn với trọng tâm là kiểm soát rủi ro qua các chu kì phát triển.

 Là phương pháp phát triển hệ thống (SDM) được sử dụng trong CNTT.

 Đây là mô hình đầu tiên giải thích tại sao lặp lại vấn đề.

 Mô hình được sử dụng phổ biến cho các dự án lớn,đắt tiền và phức tạp.Đặc biệt là các dự án phần mềm lớn cho chính phủ.

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

 Mô hình sự phát triển của phần mềm thông qua các giai đoạn tiến hóa,mỗi giai đoạn tiến hóa

được coi như là một mô hình thác đỗ

 Bản chất của mô hình xoắn ốc như tên gọi của nó,là bắt đầu từ những gì khái quát nhất để đi đến chi tiết,với mục đích lập kế hoạch làm chi tiết hóa sản phẩm qua từng giai đoạn

 Mô hình xoắn ốc là ý tưởng làm giảm thiểu rủi thông qua việc sử dụng các bản mẫu và các

công cụ khác

 Cung cấp cách thức làm phần mềm bằng cách

đưa ra các phiên bản tăng dần.Sự 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 mà sự tăng ở đây là

sự tiến hóa ,tức là cũng các đặc trưng ấy nhưng được làm mịn hơn,chi tiết hơn

 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

6

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

kì,mỗi chu kì tương ứng với một sản phẩm

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

như sau:

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

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

phẩm của chu kỳ.

 Trước khi bắt đầu mỗi chu kì nào đó, 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ì là xét duyệt và đánh

giá

 Với mỗi vòng lặp xoắn ốc,các phiên bản được

hoàn thiện dần.Tại một vòng xoắn ôc ,phân tích rủi ro phải đi đến một quyết định “tiến hành tiếp hay dừng lại”.Nếu rủi ro quá lớn,thì có thể đình

chỉ dự án hoặc thay đổi yêu cầu đặt ra cho thích hợp

8

PLAN Risk

Analysis

Engineering Customer

evaluation

Thiết kế và tạo lập 1 nguyên mẫu

Thử nghiệm

nguyên mẫu

Chu trình 1

 Người ta vẽ hai đường thẳng vuông góc cắt

nhau chia mặt phẳng thành 4 vùng tương ứng với 4 công việc của một pha phát triển

 Các đường xoắn ốc đi từ phía trong ra ngoài cũng theo chiều kim đồng hồ

 Độ dài đường xoắn ốc sẽ biểu diễn giá tích lũy của phần mềm

 Một vòng của đường xoắn ốc sẽ biễu diễn một pha của quá trình phát triển

 Nếu đi từ trong ra ngoài ở góc phần tư thứ 3 ta được mô hình thác đổ

 Một pha bắt đầu từ góc phần tư phía trên

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

o 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

o 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ử dụng, mua

o Các ràng buộc cho từng giải pháp: Chi phí, kế

hoạch,thời gian

 Kết quả của giai đoạn này là chọn được

giải pháp thích hợp

 Ở góc ph n t th hai là phân tích r i ro 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.

 Nếu rủi ro được giải quyết thì chuyển sang

bước tiếp theo: phát triển phần mềm(góc phần tư thứ 3)

 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

 Bước cuối cùng là lên kế hoạch cho pha phát

triển kế tiếp

 Đường xoắn ốc sẽ được lặp lại chừng nào sản

phẩm chưa được hoàn chỉnh

 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ỏ

 Bốn câu hỏi cơ bản phát sinh trong quá trình

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

 Làm thế nào để xoắn ốc được bắt đầu?

 Khi nào thích hợp để chấm dứt một dự án?

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

 Điều gì xảy ra khi phần mềm được nâng cấp hoặc

bảo trì?

Câu trả lời của những câu hỏi liên quan cho

thấy mô hình xoắn ốc áp dụng tốt cho sự phát triển hoặc nâng cấp phần mềm

 Khởi Tạo Xoắn Ốc:

 Một công việc thực tế có thể giải quyết hiệu quả bằng cách xây dựng phần mềm.Khi đó ta có thể nghĩ đến phát triển bằng mô hình xoắn ốc

 Kết Thúc Xoắn Ốc:

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

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

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

phát triển nhưng với quy mô nhỏ hơn

 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;xây dựng đội ngũ 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ế.

 Đánh giá thật chi tiết và phát triển dần dần,tái sử dụng,

loại bỏ các yêu cầu thật không cần thiết…

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

 Trao đổi thường xuyên với người sử dụng,có tài liệu hướng dẫn 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,…

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

 Phát triển các phần ổn định trước.

 Vấn đề về hiệu quả.

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

 Liên 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.

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

 Xác định chính xác từng rủi ro.

 Lên kế hoạch giải quyết từng rủi ro

 Đánh giá dự án hàng tháng ,so sánh với các

tháng trước để làm nổi bật rủi ro

 Đề xuất các biện pháp hạn chế rủi ro từ các

nhóm và chọn ra cách tối ưu nhất

20

 Hạn chế rủi ro,làm tăng độ tín cậy của dự án.

 Việc phân tích rủi ro sẽ tốn kém nên mô hình chỉ

áp dụng cho các dự án lớn,khi mà chi phí rủi ro

không đáng kể so với tổng chi phí toàn bộ dự án.

 Là lựa chọn phù hợp cho những dự án có hợp

đồng giữa nhà phát triển và khách hàng.

 Mô hình nên áp dụng cho những công ty phần

mềm với đội ngũ chuyên gia phân tích rủi ro có

trình độ cao

 Phù hợp với các hệ thống phát triển nhiều phiên

bản hay có yêu cầu chưa xác định rõ ràng.

 Nhằm thỏa hiệp giữa nhà phát triển và khách

hàng,cả hai cùng thắng(win-win)

 Khách thì có phần mềm thỏa mãn yêu cầu chính.

 Người phát triển thì có kinh phí thỏa đáng,thời gian hợp lí.

 Các hoạt động chính trong xác định hệ thống:

 Xác định cổ đông(Stakeholders).

 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.

24

 Hệ thống chiến đấu FCS quân đội

 Hệ thống chiến đấu sử dụng công nghệ kĩ thuật tiến bộ trong chiến tranh

 FCS bao gồm mạng lưới cảm biến mặt đất không cần giám

soát(UGS),xe trên không người lái(UAV),các phương tiện mặt đất

không người lái.

 Công ty Boeing và công ty cổ phần Khoa Học

Quốc Tế (SAIC) đã làm việc với nhau như các

nhà tích hợp hệ thống,phối hợp hơn 550 nhà

thầu và nhà thầu phụ trong 41 tiểu bang.Một mô hình xoắn ốc đã được lên kế hoạch cho FCS

26

phát triển và nâng cấp.

Tính đến năm 2004,FCS đang trong giai đoạn

phát triển hệ thống và trình diễn(SSD),bao gồm 4 hình xoắn ốc trong 2 năm

Tháng 10/2005,Lầu Năm Góc đề nghị trì hoãn

hệ thống do chi phí chiến tranh Irad,bão Katrina

và sự suy giảm trong ngân sách dự kiến

Dự án bị hủy bỏ sau 6 năm (2003-2009)

27

 Dự án cải tiến năng suất phần mềm TRW:

(The TRW Software Productivity Project)

 Dự án bắt đầu vào năm 1981,Boehm và các

cộng sự trong TRW đã mô tả tổ chức của dự án phần mềm với mục tiêu phát triển một môi

trường để làm tăng năng suất của phần mềm

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

 Dự án với quy mô lớn,phức tạp;mục đích chưa

rõ ràng cụ thể;chi phí đầu tư lớn,thời gian kéo

dài(trên 4 năm)

28

 Từ việc phân tích đặc điểm ,mục tiêu dự

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ế

Sự cam kết giao dịch _ Ngân sách cho giai đoạn kế tiếp

• 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

Sự cam kết giao dịch

_ Phát triển nguyên mẫu (bản mẫu) SDE _ Đưa ra ngay một dự án để sử dụng SDE _ Chuyển giao SDE để hỗ trợ dự án _ Thành lập một nhóm lãnh đạo đại diện.

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

Sự cam kết về tiến độ _ Phát triển theo các kế hoạch

 SPS đã phát triển 300 công cụ và hơn 1300

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 đó

 Trên 25 dự án sử dụng tất cả các phần của hệ

thống,giúp tăng năng suất của họ ít nhất 50%;

thực tế ,phần lớn tăng gấp đôi năng suất

33

 Mô hình xoắn ốc là một trong những lựa chọn

tốt nhất để phát triển các phần mềm

với quy mô lớn,phức tạp và nhiều rủi ro

34

 A Spiral Model of Software Development and

Enhancement (Barry W Boehm, TRW Defense

Systems Group)

 Software Engineering 9th edition (Ian

Sommerville)

35

36