Khả năng đa ngôn ngữ

Dễ sử dụng

Tính khả dụng

Bảo mật

Chương trình

Chương trình và dữ liệu

Tài liệu và dữ liệu

Chương trình, dữ liệu và tài liệu liên quan

Lập trình

Trừu tượng hóa

Kiểm tra

Bảo trì

Quality software, affordable cost, and unlimited time

Quality software, completed within allowable time and cost

Quality and efficient software in terms of cost

Quality software in the shortest time

CAME tools

CASE tools

CARE tools

CAQE tools

Quản lý dự án

Xây dựng cơ sở dữ liệu

Phân tích yêu cầu

Đào tạo nhân viên

Phần mềm quyết định năng suất của tổ chức và tạo nên sự khác biệt.

Phần mềm thay thế hoàn toàn con người trong quá trình làm việc.

Phần mềm làm giảm chi phí vận hành của các tổ chức.

Phần mềm giúp bảo vệ môi trường và giảm khí thải carbon.

Chi phí phát triển cao

Nhân lực chất lượng cao khan hiếm

Yêu cầu thường xuyên thay đổi

Khó kiểm soát quy trình và chất lượng

Tính dễ sửa đổi

Tính dễ kiểm tra

Tính dễ sử dụng

Tính dễ sửa lỗi

Tạo ra tài liệu hướng dẫn sử dụng mã nguồn và tổ chức lại mã nguồn

Tăng cường kiểm thử phần mềm

Thuê thêm nhân viên có kinh nghiệm

Viết lại toàn bộ mã nguồn

Giảm bớt tính năng để giảm khối lượng mã

Đảm bảo mã nguồn được tổ chức tốt và có tài liệu hóa đầy đủ

Tăng cường kiểm thử phần mềm

Thuê thêm nhân viên có kinh nghiệm

Kỹ phần mềm liên quan mật thiết tới Khoa học máy tính

Kỹ nghệ phần mềm là một phần của kỹ nghệ hệ thống

Kỹ nghệ phần mềm và khoa học máy tính không liên quan đến nhau

Khoa học máy tính là một phần của Kỹ nghệ phần mềm

Kỹ sư phần mềm không nên sử dụng các kỹ năng, kỹ thuật để sử dụng máy tính của người khác vào mục đích cá nhân

Kỹ sư phần mềm nên phụ thuộc vào đồng nghiệp

Kỹ sư phần mềm không nên chấp nhận những công việc ngoài khả năng của mình

Kỹ sư phần mềm nên duy trì sự độc lập và liêm chính trong những đánh giá chuyên môn

Thành phần khái niệm, thành phần logic và thành phần vật lý

Thành phần giao diện, thành phần logic và thành phần dữ liệu

Thành phần thuật toán, thành phần cấu trúc và thành phần dữ liệu

Thành phần giao tiếp, thành phần xử lý và thành phần lưu trữ

Quản lý việc lưu trữ và truy xuất dữ liệu từ các cơ sở dữ liệu

Điều khiển hoạt động của phần cứng máy tính như CPU và RAM

Bảo vệ phần mềm khỏi các cuộc tấn công từ bên ngoài

Tiếp nhận các yêu cầu từ người sử dụng và trình bày các kết quả

Phần mềm thời gian thực (Real time software)

Phần mềm nhúng (Embedded software)

Phần mềm thương mại (Business software)

Phần mềm hệ thống (System software)

Công cụ

Tài chính

Con người

Quy trình

Phần mềm có bản quyền

Bộ nhớ

CPU

Các thiết bị đầu vào/đầu ra

Because software is complex and requirements change, along with hardware advancements.

Because software is always stable and does not need to change.

Because hardware does not need to adapt to changes in software.

Because hardware does not affect software development.

Khả năng tích hợp với các dịch vụ thanh toán

Tương thích với nhiều nền tảng

Giao diện thân thiện với người dùng

Khả năng xử lý nhanh

Phương pháp

Quy trình

Công cụ

Lịch sử phát triển

Thác nước

Xoắn ốc

Thiết kế ứng dụng nhanh RAD

Làm bản mẫu

Các công cụ CAME

Các công cụ CASE

Các công cụ CAQE

Các công cụ CARE

thành phần giao diện, thành phần logic và thành phần dữ liệu

thành phần khai niệm, thành phần logic và thành phần vật lý

thành phần thuật toán, thành phần cấu trúc và thành phần dữ liệu

thành phần giao tiếp, thành phần xử lý và thành phần lưu trữ

Là tập chương trình thực thi được trên máy tính hoặc các thiết bị chuyên dụng khác, nhằm hỗ trợ thực hiện các thao tác nghiệp vụ

Là một chương trình thực thi được trên máy tính hoặc thiết bị chuyên dụng khác

Là hệ thống gồm chương trình và thiết bị phần cứng cho phép người dùng giải trí

Là tập các chương trình, dữ liệu và tài liệu liên quan như hướng dẫn sử dụng, thiết kế, đặc tả yêu cầu...

Lưu giữ việc lưu trữ và truy xuất dữ liệu từ các cơ sở dữ liệu

Điều khiển hoạt động của các phần cứng máy tính như CPU và RAM

Bảo vệ phần mềm khỏi các truy cập bất hợp lệ bên ngoài

Tiếp nhận thông tin từ người sử dụng và trình bày các kết quả

Tính bảo mật

Tính thích nghi

Tính khả dụng

Tính thẩm mỹ của giao diện người dùng

Do thời gian bảo trì dài và phần mềm phức tạp

Do các yêu cầu không được xác định rõ ràng ban đầu

Do yêu cầu thay đổi liên tục và thời gian bảo trì dài hơn so với thời gian phát triển

Do sự phức tạp của phần mềm và yêu cầu thay đổi liên tục

Phần mềm quyết định năng suất của tổ chức và tạo nên sự khác biệt.

Phần mềm giúp bảo vệ môi trường và giảm khí thải carbon.

Phần mềm thay thế hoàn toàn con người trong quá trình làm việc.

Phần mềm làm giảm chi phí vận hành của các tổ chức.

Nhân lực chất lượng cao khan hiếm

Chi phí phát triển cao

Khó kiểm soát quy trình và chất lượng

Yêu cầu thường xuyên thay đổi

Phát triển phần mềm

Đặc tả phần mềm

Thẩm định phần mềm

Sử dụng phần mềm

Vì phần cứng không ảnh hưởng đến sự phát triển của phần mềm.

Vì tính phức tạp của phần mềm và yêu cầu sử dụng không ngừng thay đổi, cùng với sự tiến bộ nhanh của hạ tầng phần cứng.

Vì phần mềm không cần thích nghi với những thay đổi trong hạ tầng phần cứng.

Vì phần mềm luôn ổn định và không cần phải thay đổi.

Khách hàng có thể phản hồi sau mỗi lần tăng trưởng.

Dễ kiểm thử và debug và được dùng khi cần đưa sản phẩm ra thị trường sớm.

Được dùng khi cần đưa sản phẩm ra thị trường sớm.

Dễ kiểm thử và debug

Mô hình xoắn ốc giảm thiểu sự cần thiết của tài liệu hóa.

Mô hình xoắn ốc không cần lập kế hoạch chi tiết trước khi bắt đầu phát triển.

Mô hình xoắn ốc yêu cầu tất cả các yêu cầu phải được xác định ngay từ đầu.

Mô hình xoắn ốc cho phép điều chỉnh yêu cầu và quản lý rủi ro qua mỗi vòng xoắn lặp lại.

Mô hình tăng trưởng yêu cầu lập kế hoạch chi tiết cho tất cả các phần trước khi phát triển bắt đầu.

Mô hình tăng trưởng yêu cầu người dùng cung cấp tất cả các yêu cầu trước khi phát triển.

Mô hình tăng trưởng có thể khiến người dùng khó hình dung ra sản phẩm cuối cùng do phát triển qua các phần nhỏ.

Mô hình tăng trưởng không cho phép kiểm thử sản phẩm trước khi tất cả các phần hoàn thành.

Mô hình thác nước không cho phép khách hàng thay đổi yêu cầu sau khi quá trình phát triển bắt đầu.

Mô hình thác nước yêu cầu khách hàng tham gia liên tục trong suốt quá trình phát triển.

Mô hình thác nước yêu cầu sự tham gia của khách hàng ngay từ đầu nhưng không trong suốt quá trình phát triển.

Mô hình thác nước cho phép khách hàng thay đổi yêu cầu trong suốt quá trình phát triển.

Mô hình tiến hóa không cần sự tham gia của khách hàng trong suốt quá trình phát triển.

Mô hình tiến hóa yêu cầu hoàn thành tất cả các yêu cầu trước khi phát triển bắt đầu.

Mô hình tiến hóa không cho phép điều chỉnh yêu cầu sau khi phát triển bắt đầu.

Mô hình tiến hóa cho phép yêu cầu thay đổi liên tục trong suốt quá trình phát triển, không chỉ dựa trên các nguyên mẫu ban đầu.

Mô hình xoắn ốc kết hợp đánh giá rủi ro trong mỗi chu kỳ lặp, giúp quản lý rủi ro tốt hơn so với mô hình thác nước.

Mô hình xoắn ốc yêu cầu tất cả các yêu cầu phải được xác định ngay từ đầu như mô hình thác nước.

Mô hình xoắn ốc không cần đánh giá rủi ro trong quá trình phát triển.

Mô hình xoắn ốc loại bỏ việc kiểm thử phần mềm để giảm rủi ro.

Tạo một user story mới cho tính năng này và đưa vào backlog để xem xét cho các sprint sau.

Bỏ qua yêu cầu của khách hàng vì không nằm trong backlog ban đầu.

Thêm tính năng mới vào sprint hiện tại.

Hoàn thành sprint hiện tại rồi mới xem xét tính năng mới.

Phát triển các hệ thống sử dụng cùng một giao thức truyền thông.

Sử dụng dịch vụ trung gian hoặc một lớp tích hợp cho phép các hệ thống giao tiếp mà không cần thay đổi các hệ thống hiện có.

Tạm dừng tích hợp cho đến khi tìm được giải pháp phù hợp.

Tích hợp dữ liệu từ CRM sang ERP thông qua các kịch bản chuyển dữ liệu hàng ngày.

Mô hình nguyên mẫu

Mô hình gia tăng

Mô hình RAD

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

Mô hình V

Mô hình xoắn ốc

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

Mô hình RAD

Kỹ thuật phần mềm dựa trên thành phần (CBSE)

Chuyển tất cả các hệ thống sang một ngôn ngữ và môi trường duy nhất

Kiến trúc hướng dịch vụ (SOA)

Phát triển phần mềm từ đầu mà không tái sử dụng các thành phần

Có thể thêm các tính năng bổ sung

Không phù hợp cho các dự án nhỏ

Phân tích rủi ro tốn nhiều thời gian

Khó kiểm soát tài liệu

Rapid Application Development

Random Access Data

Remote Access Device

Real-time Analysis Dashboard

Phát triển ứng dụng nhanh

Phát triển ứng dụng tương đối

Không từ nào

Tài liệu phát triển ứng dụng nhanh

Mô hình RAD và mô hình làm bản mẫu.

Mô hình RAD và mô hình thác nước.

Mô hình thác nước và xoắn ốc.

Mô hình RAD và xoắn ốc.

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

Mô hình làm bản mẫu.

Mô hình phát triển nhanh RAD.

Cả hai mô hình RAD và làm bản mẫu.

Làm mô hình bản mẫu

Thiết kế nhanh

Lập trình

Kỹ nghệ

Mô hình chữ V không cần đến sự tham gia của khách hàng trong giai đoạn kiểm thử.

Mô hình chữ V cho phép linh hoạt quay lại các giai đoạn trước khi có thay đổi yêu cầu.

Mô hình chữ V không yêu cầu lập kế hoạch trước.

Mô hình chữ V kết hợp kiểm thử trong từng giai đoạn phát triển, giúp đảm bảo chất lượng sản phẩm.

Mô hình làm bản mẫu giúp giảm thời gian phát triển phần mềm so với mô hình thác nước.

Mô hình làm bản mẫu không yêu cầu sự tham gia của khách hàng trong suốt quá trình phát triển.

Mô hình làm bản mẫu cho phép người dùng điều chỉnh yêu cầu dựa trên nguyên mẫu trước khi sản phẩm hoàn chỉnh được phát triển.

Mô hình làm bản mẫu không yêu cầu tài liệu hoá chi tiết như mô hình thác nước.

Mô hình RAD không yêu cầu kiểm thử phần mềm trước khi phát hành.

Mô hình RAD không yêu cầu sự tham gia của khách hàng trong suốt quá trình phát triển.

Mô hình RAD cho phép hoàn thiện sản phẩm nhanh chóng bằng cách chia nhỏ các yêu cầu.

Mô hình tăng trưởng giúp phát triển hệ thống theo từng phần nhỏ, cho phép kiểm thử sớm và điều chỉnh dựa trên phản hồi từ mỗi phần.

Mô hình tăng trưởng yêu cầu tất cả các yêu cầu phải được xác định trước khi phát triển bắt đầu.

Mô hình tăng trưởng phát triển toàn bộ hệ thống ngay từ đầu mà không cần qua các giai đoạn lặp lại.

Mô hình tăng trưởng không yêu cầu tài liệu hóa như mô hình thác nước.

Giảm thiểu thời gian phát triển và đưa ra sản phẩm nhanh hơn.

Giảm thiểu sự tham gia của khách hàng trong quá trình phát triển.

Loại bỏ sự cần thiết của tài liệu hóa chi tiết.

Tạo ra các nguyên mẫu giúp người dùng dễ dàng điều chỉnh yêu cầu trong quá trình phát triển.

Mô hình RAD

Mô hình xoắn ốc

Mô hình chữ V

Mô hình làm bản mẫu

Mô hình RAD

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

Mô hình xoắn ốc

Mô hình tăng trưởng

Hoàn thành tất cả các tính năng nhỏ trước, sau đó chuyển sang tính năng lớn và phức tạp hơn.

Ưu tiên các tính năng theo thứ tự xuất hiện trong backlog mà không cần thay đổi.

Làm việc chặt chẽ với Product Owner để liên tục đánh giá và sắp xếp lại backlog dựa trên giá trị kinh doanh và phản hồi của khách hàng.

Thực hiện phân tích chi tiết và xác định các tính năng để phát triển nhất để hoàn thành trước.

Tìm kiếm một thành phần đã được phát triển sẵn, có thể tái sử dụng và tích hợp vào hệ thống để tiết kiệm thời gian và chi phí.

Viết lại toàn bộ chức năng mới từ đầu để tích hợp vào hệ thống.

Thay thế toàn bộ các thành phần cũ bằng các thành phần mới để đảm bảo hệ thống đồng nhất.

Biên dịch lại hệ thống và kiểm tra lại tất cả các thành phần hiện tại trước khi phát triển chức năng mới.

Component-based Software Engineering (CBSE)

Phát triển một hệ thống hoàn toàn mới mà không dùng thành phần hoặc dịch vụ tái chế

Chọn mô hình phát triển Waterfall

Service-Oriented Architecture (SOA)

a. Quá trình phát triển đơn giản nên phù hợp với những dự án có ít thay đổi.

b. Các giai đoạn được định nghĩa rõ ràng, dễ phân công và giám sát công việc.

c. Sửa lỗi dễ dàng và tốn ít chi phí.

d. Giảm thiểu các lỗi mắc phải trong giai đoạn thiết kế.

Mô hình hóa

Triển khai

Giao tiếp

Lập kế hoạch

Mô hình thác nước và xoắn ốc.

Mô hình làm bản mẫu và RAD.

Mô hình thác nước và RAD.

Mô hình làm bản mẫu và xoắn ốc.

Đúng thời hạn, chất lượng cao, không quan tâm đến chi phí.

Càng nhanh và tốn ít chi phí càng tốt.

Có chất lượng, có thời gian và chi phí hợp lý.

Có chất lượng và nhanh nhất có thể.

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

Mô hình phát triển nhanh RAD

Mô hình xoắn ốc

Mô hình làm bản mẫu

Mô hình tăng trưởng yêu cầu lập kế hoạch chi tiết cho tất cả các phần trước khi phát triển bắt đầu.

Mô hình tăng trưởng không cho phép kiểm thử sản phẩm trước khi tất cả các phần hoàn thành.

Mô hình tăng trưởng có thể khiến người dùng khó hình dung ra sản phẩm cuối cùng do phát triển qua các phần nhỏ.

Mô hình tăng trưởng yêu cầu người dùng cung cấp tất cả các yêu cầu trước khi phát triển.

Mô hình xoắn ốc cho phép điều chỉnh yêu cầu và quản lý rủi ro qua mỗi vòng xoắn lặp lại.

Mô hình xoắn ốc không cần lập kế hoạch chi tiết trước khi bắt đầu phát triển.

Mô hình xoắn ốc yêu cầu tất cả các yêu cầu trước khi phát triển từng vòng lặp.

Mô hình xoắn ốc kiểm thử sản phẩm sau khi tất cả các phần hoàn thành.

Mô hình thác nước không cho phép khách hàng thay đổi yêu cầu sau khi quá trình phát triển bắt đầu.

Mô hình thác nước cho phép khách hàng điều chỉnh yêu cầu thông qua các nguyên mẫu nhanh chóng.

Mô hình thác nước yêu cầu khách hàng tham gia liên tục trong suốt quá trình phát triển.

Mô hình thác nước không yêu cầu sự tham gia của khách hàng trong quá trình kiểm thử.

Mô hình sử dụng lại

Mô hình hướng thành phần

Mô hình mã nguồn mở

Mô hình Agile

Tạm dừng tiến trình, tổ chức một cuộc họp ngay lập tức với khách hàng để làm rõ yêu cầu và điều chỉnh kế hoạch.

Ghi nhận các yêu cầu mới và tích hợp vào Sprint tiếp theo mà không cần sự thông báo với khách hàng.

Mô hình làm bản mẫu

Mô hình tiến hóa

Mô hình RAD

Mô hình tăng trưởng

Nhóm phát triển tự quyết định các ưu tiên sản phẩm và tiếp tục Sprint mà không cần Product Owner.

Sprint vẫn tiếp tục nhưng các yêu cầu có thể không chính xác hoặc không đáp ứng được nhu cầu khách hàng.

Sprint sẽ bị tạm dừng cho đến khi Product Owner tham gia trở lại.

Nhóm Scrum Master sẽ thay thế vai trò Product Owner và quản lý backlog.

Thành phần có thể được thay thế trực tiếp thông qua giao thức HTTP.

Thành phần được thay thế mà không cần dừng hệ thống.

Thành phần được tích hợp mà không cần kiểm tra tính tương thích với các thành phần khác.

Thành phần phải được biên dịch lại và tích hợp lại vào hệ thống.

Cả ba điều trên.

Không tính sử dụng lại của các thành phần.

Thành viên trong nhóm cần có kỹ năng và trình độ cao.

Không có phản hồi từ khách hàng.

System Development Life Cycle.

Software Design Life Cycle.

System Design Life Cycle.

Software Development Life Cycle.

Mô hình tăng trưởng.

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

Mô hình RAD.

Mô hình xoắn ốc.

Tạm dừng hệ thống và biên dịch lại toàn bộ mã nguồn để tích hợp thành phần mới.

Liên hệ với nhà cung cấp thành phần lỗi và chờ phiên bản cập nhật trước khi tiếp tục.

Thay thế thành phần lỗi bằng một thành phần tương thích mới mà không cần tạm dừng hệ thống, nhờ khả năng thay thế động của CBSE.

Viết lại thành phần lỗi từ đầu và chạy lại toàn bộ hệ thống để kiểm tra tính tương thích.

Phát triển lại dịch vụ gặp sự cố ngay lập tức và tích hợp lại vào hệ thống sau khi hoàn thành.

Tìm kiếm các giải pháp thủ công để thay thế chức năng của dịch vụ gặp sự cố đến khi mạng hoạt động trở lại.

Cấu hình hệ thống để sử dụng các dịch vụ thay thế khác, đảm bảo tính sẵn sàng và khả năng tiếp tục của các phần còn lại của hệ thống.

Tạm dừng toàn bộ hệ thống cho đến khi dịch vụ quan trọng được khôi phục hoàn toàn.

Mô hình làm bản mẫu

Mô hình tăng trưởng

Mô hình RAD

Mô hình tiến hóa

Mô hình thác nước và xoắn ốc.

Mô hình RAD và mô hình làm bản mẫu.

Mô hình RAD và xoắn ốc.

Mô hình RAD và mô hình thác nước.

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

Mô hình tăng trưởng

Mô hình xoắn ốc

Mô hình RAD