spiralmodel

ĐẠI HỌC BÁCH KHOA-ĐẠI HỌC ĐÀ NẴNGKHOA CÔNG NGHỆ THÔNG TIN

MÔ HÌNH XOẮN ỐCNhóm 5: Khuất Thanh Tùng Phan Nguyễn Như Thủy Lê Thị Cẩm Hằng Nguyễn Trí Công

2

GIỚI THIỆU

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 hoá, mỗi giai đoạn được coi như một mô hình thác nước.

2

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.

3

ĐẶ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 roPhầ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.

4


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

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á

5


Mô hình xoắn ố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: Đâ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.

6

MÔ HÌNH XOẮN ỐC

S/W: software

V&V: Validation and verification7

GIẢI THÍCH MÔ HÌNH

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.

8


Một pha bắt đầu từ góc phần tư phía trên 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ử dụng, mua...

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.

9


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

10


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

11

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

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:

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?

12

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

Khởi tạo 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.

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

13

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í14

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ầnThiế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

15

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

Xác định các rủi ro của dự ánTrình bày kế hoạch giải quyết mỗi rủi ro.Thường xuyên cập nhật danh sách các rủi

ro, lên kế hoạch và kết quả hàng thángĐánh giá dự án hàng tháng để làm nổi bật

tình trạng rủi ro, so sánh với tình trạng của tháng trước

Khởi xướng các hành động khắc phục thích hợp.

16

ƯU ĐIỂM

Hạn chế rủi ro sớmNhận được phản hồi sớm từ người sử dụngPhân tích rủi ro dự án được đẩy lên làm một

phần thiết yếu trong quy trình xoắn ốc để tăng độ tin cậy của dự án

Xây dựng dự án có sự kết hợp các mô hình khác vào phát triển (thác nước, mô hình mẫu,…)

Cho phép thay đổi tùy theo yêu cầu cho mỗi vòng xoắn ốc

17

Ư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

18

NHƯỢC ĐIỂM

Phức tạp và không thích hợp với các dự án nhỏ và ít rủi ro

Yêu cầu thay đổi thường xuyên dẫn đến lặp vô hạn và thất bại

Đòi hỏi năng lực quản lý, năng lực phân tích rủi ro cao

Chưa được dùng rộng rãi như mô hình thác nước hay là bản mẫu

19

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.

20

MÔ HÌNH XOẮN ỐC WINWIN

Trong công nghệ phần mềm, hoạt động giao tiếp của nhà phát triển và khách hàng là vô cùng cần thiết.

Trong bối cảnh lý tưởng, nhà phát triển hỏi 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.

Thực tế điều này ít khi xảy ra Nhà phát triển và khách hàng bước vào quá trình đàm phán Khách hàng phải cân nhắc giữa chức năng, hiệu

suất với chi phí và thời gian.21


Một cuộc đàm phán tốt phải dẫn đến kết quả 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ý.Các hoạt động chính trong xác định hệ 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 để đi tới định nghĩa hệ thống phần mềm

22


23


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 mềm.

24

ỨNG DỤNG THỰC TẾ

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

25

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

Mục tiêu: tạo ra một môi trường công 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

Đặc điểm dự án: 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

26

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

Từ việc phân tích đặc điểm mục tiêu dự án, Boehm và các đồng sự đã quyết định sử dụng mô hình xoắn ốc trong suốt quá trình phát triển dự án này.

Vậy mô hình xoắn ốc đã được áp dụng như thế nào trong dự án này?

27

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

28

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 TRWSự giao ước với chính phủ, kĩ thuật cao, hướng tới con người, bảo mật

Các thay thế

_ Quản lý: Sự tổ chức dự án, chính sách, lập kế hoạch, điều hành_ Nhân sự: bố trí cán bộ nhân viên, các ưu đãi, đào tạo_ Công nghệ: Các công cụ, máy trạm, các phương pháp, tái sử dụng_ Cơ sở hạ tầng: trụ sở văn phòng, phương tiện liên lạc

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ả thiHệ 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ơnBê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

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

29

Mục tiêu _ Gấp đôi năng suất phần mềm trong 5 năm

Các ràng buộc

_ Đầu tư 10,000$ cho một người_ Phù hợp với văn hóa phần mềm của TRWHợ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

Các thay thế

_ Văn phòng: riêng/theo modun_ Truyền thông: LAN/star/bộ tập trung/…_ Thiết bị đầu cuối: Riêng tư/dùng chung; smart/dumb _ Công cụ: SREM/PSL-PSA/…; PDL/SADT/… _ CPU: IBM/DEC/CDC/…

Các rủi ro_ Có thể bỏ lỡ các tùy chọn mang tính đột phá_ Giá thành/chất lượng mạng LAN TRW_ Chi phí máy trạm

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 SDETừ 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.

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

30

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ùngHộ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ểnVề 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

CÁC VÒNG KẾ TIẾP

31

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

CÁC VÒNG KẾ TIẾP

32

Thiết kế chi tiết với công cụ phát triển thư 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 đề.

KẾT QUẢ DỰ ÁN

SPS đã phát triển 300 công cụ và hơ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 bên ngoài.

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

KẾT QUẢ DỰ ÁN

Tuy nhiên có một rủi ro bị đánh giá thấp đó 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.

34

NHẬN XÉT

Mô hình xoắn ốc là cách tiếp cận thực tế cho việc phát triển các phần mềm quy mô lớn. phần mềm được tiến hóa theo đường xoắn ốc, từ tổng quan cho

đến chi tiết. người phát triển và khách hàng hiểu rõ hơn và có phản ứng thích

hợp với rủi ro tại từng mức tiến hóa. Bản mẫu còn giúp cho khách hàng nhìn rõ từng bước phát triển của

phần mềm và có ý kiến góp ý kịp thời cho người phát triển đi đúng hướng

Mô hình này dùng bản mẫu như một cơ chế làm giảm rủi ro. Mô hình đòi hỏi xem xét trực tiếp các rủi ro kỹ thuật cũng như

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à khách hàng là đặc trưng chính của mô hình.

35

TÀI LIỆU THAM KHẢO

A Spiral Model of Software Development and Enhancement (Barry W. Boehm, TRW Defense Systems Group)

Software Engineering 9th edition (Ian Sommerville)

36

spiralmodel

Technology