Mô hình xoắn ốc

Chia sẻ: nhuthuybkdn

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.

Bạn đang xem 10 trang mẫu tài liệu này, vui lòng download file gốc để xem toàn bộ.

Nội dung Text: Mô hình xoắn ốc

ĐẠ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:
 Khuất Thanh Tùng
 Phan Nguyễn Như Thủy
 Lê Thị Cẩm Hằng
 Nguyễn Trí Công
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 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.
4
ĐẶC ĐIỂM MÔ HÌNH

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
ĐẶC ĐIỂM MÔ HÌNH

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
7
V&V: Validation and verification
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
GIẢI THÍCH MÔ HÌNH

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
GIẢI THÍCH MÔ HÌNH

Ở 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
GIẢI THÍCH MÔ HÌNH

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ầ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
15
KẾ HOẠCH QUẢN LÝ RỦI RO

Xác định các rủi ro của dự án
Trì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ớm
Nhận được phản hồi sớm từ người sử dụng
Phâ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Ô HÌNH XOẮN ỐC WINWIN


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
MÔ HÌNH XOẮN ỐC WINWIN




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

Mục tiêu _ Năng suất phần mềm tăng đáng kể
_ Chi phí hợp lý
Các ràng buộc _ 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

_ 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ác thay thế
_ 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

_ Sự cải tiến không có tác dụng cao
Các rủi ro
_ Sự cải thiện này xung đột với các ràng buộc
_ Những cái nhìn tổng quát xung quanh
_ Phân tích chi phí của mô hình
Giải pháp giải quyết rủi ro
_ Phân tích các ngoại lệ của dự án
_ Tìm kiếm tài liệu
_ 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 quả giải quyết rủi ro _ 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
_ Cần lực lượng đặc biệt 6 người trong 6 tháng
Lập kế hoạch cho pha tiếp _ Khảo sát và phân tích rộng hơn
•Bên trong, bên ngoài, kinh t ế.
theo
_ 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
28
CHU KÌ 1 - HÌNH THÀNH KHÁI NIỆM CÔNG
VIỆC

Mục tiêu _ Gấp đôi năng suất phần mềm trong 5 năm
_ Đầu tư 10,000$ cho một người
_ Phù hợp với văn hóa phần mềm của TRW
Các ràng buộc
•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
_ Văn phòng: riêng/theo modun
_ Truyền thông: LAN/star/bộ tập trung/…
Các thay thế _ 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ó thể bỏ lỡ các tùy chọn mang tính đột phá
Các rủi ro _ Giá thành/chất lượng mạng LAN TRW
_ Chi phí máy trạm
_ Nghiên cứu và kiểm tra bên ngoài rộng rãi
Giải pháp giải quyết rủi ro _ 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

_ 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
Kết quả giải quyết rủi ro _ 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ụ.

_ 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
Kế hoạch cho pha tiếp theo
•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
_ Đưa ra ngay một dự án để sử dụng SDE
Sự cam kết giao dịch
_ Chuyển giao SDE để hỗ trợ dự án
_ Thành lập một nhóm lãnh đạo đại diện.

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

_ 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
Mục tiêu
_ 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.
_ Chuyển giao SDE cho khách hàng => có tính khả chuyển
Các ràng buộc
_ Ổn định, dịch vụ đáng tin cậy
_ Hệ điều hành: VMS/AT&T Unix/Berkeley Unix/ISC
Các thay thế _ 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/…
_ 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
Các rủi ro
•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
_ Khảo sát người dùng dự án.
Giải pháp giải quyết
_ Khảo sát các tổ chức sử dụng UNIX
rủi ro
_ Nghiên cứu máy trạm.
_ Đặc tả yêu cầu mức độ cao
_ Host-target sử dụng Unix host
Kết quả giải quyết rủi
_ Máy trạm nền tảng UNIX
ro
_ 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.
Toàn bộ kế hoạch phát triển
Kế hoạch cho pha tiếp
•Về các công cụ: SREM, RTT, PDL, các công cụ giúp đỡ t ự động hóa.
theo
•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
30
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.

31
CÁC VÒNG KẾ TIẾP

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 đề.



32
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
Đề thi vào lớp 10 môn Toán |  Đáp án đề thi tốt nghiệp |  Đề thi Đại học |  Đề thi thử đại học môn Hóa |  Mẫu đơn xin việc |  Bài tiểu luận mẫu |  Ôn thi cao học 2014 |  Nghiên cứu khoa học |  Lập kế hoạch kinh doanh |  Bảng cân đối kế toán |  Đề thi chứng chỉ Tin học |  Tư tưởng Hồ Chí Minh |  Đề thi chứng chỉ Tiếng anh
Theo dõi chúng tôi
Đồng bộ tài khoản