Đề thi môn Công nghệ phần mềm - Mô hình quy trình phát triển phần mềm

4

6

5

3

Việc kiểm chứng (xác minh) được thực hiện sau mỗi giai đoạn trong mô hình thác nước

Trong mô hình thác nước, việc tài liệu hoá có thể giảm chi phí bảo trì

Trong mô hình thác nước, vòng lặp lấy phản hồi giúp sửa lỗi ngay lập tức (hoặc tùy biến theo ngữ cảnh câu hỏi)

Mô hình thác nước thích ứng tốt với những thay đổi trong quá trình phát triển phần mềm

Trong mô hình thác nước, những thay đổi có thể gây ra sai sót đáng kể khi dự án tiến triển

Mô hình thác nước phù hợp với những dự án phần mềm mà yêu cầu còn mơ hồ, không được xác định rõ ràng ở giai đoạn đầu của dự án

Một cách tiếp cận kỹ thuật chặt chẽ được thực hiện trong mô hình thác nước

Mô hình thác nước còn được gọi là mô hình phát triển tuần tự tuyến tính

Phiên bản ban đầu của một hệ thống phần cứng

Phiên bản ban đầu của một hệ thống phần mềm

Tài liệu phân tích thiết kế

Tài liệu đặc tả yêu cầu

Lập trình nhanh

Thiết kế nhanh

Phát triển bản mẫu

Tinh chỉnh bản mẫu

Tốc độ tạo mẫu

Cấu trúc bên trong của mẫu

Khả năng của mẫu

Tốc độ tinh chỉnh mẫu

Chất lượng thiết kế không được cải thiện

Các bản mẫu được tạo ra không thể tái sử dụng

Không có khả năng phát hiện lỗi sớm

Một mô hình quy trình phát triển phần mềm chậm, cần nhiều sự tham gia của khách hàng

Phát triển lặp có thể sử dụng cho mô hình làm bản mẫu

Phát triển lặp không thể sử dụng cho mô hình làm bản mẫu

Sử dụng mô hình làm bản mẫu khi các yêu cầu còn mơ hồ

Sử dụng mô hình làm bản mẫu khi các yêu cầu không được xác định rõ ràng

Rational Unit Process

Rapid Unified Process

Rational Unified Process

Relative Unified Process

Mô hình xoắn ốc có khả năng kiểm soát rủi ro trong từng lần lặp

Mô hình xoắn ốc là một mô hình tiến hoá

Mô hình xoắn ốc không giải quyết rủi ro trong từng lần lặp

Mô hình xoắn ốc cần sự tham gia và tương tác từ phía khách hàng

Mô hình xoắn ốc sử dụng bản mẫu như một cơ chế để giảm thiểu rủi ro và cho phép phát triển bản mẫu ở bất kỳ giai đoạn nào

Mô hình xoắn ốc không yêu cầu chuyên môn, kỹ thuật xác định và giải quyết rủi ro

Một cách tiếp cận có hệ thống theo từng bước được thực hiện trong mô hình thác nước

Berry Boehm (hoặc C vì trùng tên)

Bev Boehm

Berry Boehm

Berrem Boehm

RUP (Rational Unified Process) là một mô hình có khả năng thích ứng với những thay đổi trong quá trình phát triển

RUP (Rational Unified Process) là một mô hình không có khả năng thích ứng với thay đổi trong quá trình phát triển

RUP (Rational Unified Process) là một mô hình hiện đại có các khía cạnh của mô hình xoắn ốc

RUP (Rational Unified Process) là một mô hình hiện đại có các khía cạnh của mô hình tăng trưởng

Inception, Elaboration, Construction, Transition

Inception, Construction, Elaboration, Transition

Inception, Construction, Transition, Elaboration

Inception, Elaboration, Transition, Construction

Inception

Construction

Transition

Elaboration

Inception

Construction

Elaboration

Transition

Relative Application Development

Rapid Application Development

Rapid Application Design

Rapid Approach Development

Khi sử dụng mô hình tăng trưởng, cấu trúc hệ thống bị suy thoái khi các tăng trưởng mới được thêm vào

Trong mô hình tăng trưởng, các yêu cầu không cần độ ưu tiên

Hạn chế của mô hình RAD (Rapid Application Development) là hiệu suất không cao (hoặc tùy biến theo ngữ cảnh)

Không mất nhiều thời gian để có được phản hồi (feedback) trong mô hình lặp

Mô hình chữ V

Mô hình thác nước

Mô hình RAD

Agile

Mô hình chữ V không phải mô hình tăng trưởng

Mô hình tiến hoá không thẩm định các phiên bản được tạo ra

Scrum và XP (Extreme Programming) là các phương pháp Agile

Mô hình RAD là sự ráp nối tốc độ cao của mô hình tuần tự tuyến tính

XP (Extreme Programming) không có sự giao tiếp giữa các thành viên trong nhóm phát triển

Trong XP (Extreme Programming), sự lặp lại thường xuyên làm giảm chất lượng sản phẩm phần mềm

XP (Extreme Programming) không khuyến khích sự sáng tạo, tự chủ của các thành viên trong nhóm phát triển

Trong XP (Extreme Programming), sự lặp lại thường xuyên làm tăng chất lượng sản phẩm phần mềm

Khi sử dụng mô hình RAD, ta chỉ quản lý cấu hình trong giai đoạn User Design

Khi sử dụng mô hình RAD, ta không cần quản lý cấu hình

Khi sử dụng mô hình RAD, ta chỉ quản lý cấu hình trong giai đoạn Requirements Planning

Quản lý cấu hình nghiêm ngặt là cần thiết khi sử dụng mô hình RAD

Inception

Elaboration

Construction

Transition