Tổng Hợp Kiến Thức SWE201c Ôn Thi PE & TE

Tổng hợp kiến thức SWE201c giúp ôn thi PE & TE hiệu quả

Tổng hợp kiến thức SWE201c giúp bạn tự tin ôn thi PE và ôn thi TE hiệu quả. Tài liệu chi tiết, mẹo thi thực tế và bài tập SWE201c được biên soạn kỹ lưỡng, hỗ trợ bạn nắm vững kiến thức và chinh phục kỳ thi. Khám phá ngay cùng TruongDevs để có hướng dẫn ôn thi chuẩn xác để đạt kết quả cao!

Các phương pháp phát triển phần mềm

Phương pháp phát triển phần mềm (SDLC - Software Development Life Cycle) được chia thành hai nhóm chính: 6 mô hình SDLC cơ bản và 3 mô hình Agile.

Tổng quan

• 6 Mô hình SDLC cơ bản: Waterfall, V-Model, Incremental & Iterative, Spiral, RUP, Prototype
• 3 Mô hình Agile: Scrum, Kanban, Extreme Programming (XP)

A. 6 Mô hình SDLC cơ bản

1. Mô hình thác nước (Waterfall)

Định nghĩa: Mô hình thác nước là phương pháp phát triển tuần tự, trong đó quá trình phát triển được xem như dòng chảy liên tục qua các giai đoạn: Phân tích yêu cầu → Thiết kế → Triển khai → Kiểm thử → Bảo trì.

Mô hình thác nước (Waterfall)

Các giai đoạn chính

• 1. Phân tích: Thu thập và làm rõ yêu cầu, phân tích tính khả thi, lập kế hoạch dự án.
• 2. Thiết kế: Thiết kế kiến trúc hệ thống, thiết kế chi tiết các module, thiết kế giao diện.
• 3. Triển khai: Lập trình các module, kiểm thử đơn vị, tích hợp các module.
• 4. Kiểm thử: Kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử chấp nhận.
• 5. Bảo trì: Triển khai hệ thống, bảo trì và nâng cấp, hỗ trợ người dùng.

Đặc điểm nổi bật

• Quy trình tuần tự chặt chẽ
• Yêu cầu phải rõ ràng từ đầu
• Tài liệu đầy đủ cho mỗi giai đoạn
• Không có sự chồng chéo giữa các giai đoạn

Khi nào nên sử dụng

• Yêu cầu dự án rõ ràng và ổn định
• Công nghệ sử dụng đã được kiểm chứng
• Nguồn lực và thời gian đầy đủ
• Cần tài liệu chi tiết

Ưu điểm

• Dễ quản lý và kiểm soát
• Tài liệu đầy đủ và chi tiết
• Phù hợp với dự án nhỏ và trung bình

Nhược điểm

• Khó thay đổi yêu cầu
• Rủi ro cao nếu yêu cầu không chính xác
• Thời gian phát triển dài

2. Mô hình chữ V (V-Model)

Định nghĩa: V-Model là phiên bản mở rộng của mô hình thác nước, trong đó các hoạt động kiểm thử được thực hiện song song với từng giai đoạn phát triển.

Mô hình chữ V (V-Model)

Các giai đoạn

• Verification Phases (Bên trái): Phân tích yêu cầu, thiết kế hệ thống, thiết kế kiến trúc, thiết kế module.
• Validation Phases (Bên phải): Unit Testing, Integration Testing, System Testing, Acceptance Testing.

Khi nào sử dụng

• Yêu cầu rõ ràng và cố định
• Có sẵn nguồn lực kỹ thuật
• Dự án nhỏ hoặc trung bình

3. Mô hình Tăng dần & Lặp lại (Incremental & Iterative)

Định nghĩa: Mô hình phát triển tăng dần và lặp lại đặc trưng bởi chu kỳ lặp đi lặp lại của việc phát hành cập nhật và tích hợp các tính năng mới.

Mô hình Tăng dần & Lặp lại (Incremental & Iterative)

Các giai đoạn chính

• Khởi tạo: Xác định phạm vi, yêu cầu, rủi ro tiềm ẩn.
• Chi tiết: Thiết lập kiến trúc để giảm thiểu rủi ro.
• Xây dựng: Phát triển từng thành phần với code sẵn sàng.
• Chuyển giao: Đưa hệ thống vào môi trường hoạt động.

Khi nào nên sử dụng

• Cần cung cấp chức năng thiết yếu nhanh chóng
• Có công nghệ mới cải thiện quá trình thực hiện
• Team chưa quen với lĩnh vực cụ thể
• Tổ chức có mục tiêu cải tiến đáng kể

4. Mô hình Xoắn ốc (Spiral)

Định nghĩa: Mô hình Xoắn ốc tổ chức các hoạt động theo mô hình xoắn ốc, thực hiện qua phân tích rủi ro.

Mô hình Xoắn ốc (Spiral)

Các giai đoạn chính

• Lập kế hoạch: Xác định mục tiêu, phương án tiếp cận, giao tiếp với khách hàng.
• Phân tích rủi ro: Xác định, đánh giá rủi ro, phát triển prototype, lập chiến lược giảm thiểu.
• Kỹ thuật: Coding, testing, triển khai, lựa chọn mô hình dựa trên rủi ro.
• Đánh giá: Khách hàng đánh giá, lập kế hoạch cho chu kỳ tiếp theo.

Khi nào nên sử dụng

• Cần phát hành phần mềm thường xuyên
• Prototype đóng vai trò quan trọng
• Quản lý rủi ro và chi phí là ưu tiên
• Dự án rủi ro cao hoặc phức tạp

5. Mô hình RUP (Rational Unified Process)

Định nghĩa: RUP là phương pháp hướng đối tượng, hỗ trợ tạo sản phẩm cuối cùng và quản lý dự án.

Mô hình RUP (Rational Unified Process)

Các giai đoạn chính

• Khởi tạo: Hình dung và khởi động dự án.
• Chi tiết hóa: Thiết kế use cases và kiến trúc.
• Xây dựng: Từ thiết kế đến sản phẩm cuối cùng.
• Chuyển giao: Đảm bảo sự hài lòng của khách hàng.

Khi nào nên sử dụng

• Yêu cầu thay đổi liên tục
• Có thông tin và dữ liệu chính xác
• Cần tích hợp ở nhiều giai đoạn

6. Mô hình Prototype

Định nghĩa: Mô hình Prototype tạo phiên bản thử nghiệm để kiểm tra và đánh giá trước khi phát triển sản phẩm cuối cùng.

Mô hình Prototype

Các giai đoạn chính

• Xác định yêu cầu: Thu thập yêu cầu cơ bản.
• Thiết kế nhanh: Tạo thiết kế sơ bộ cho prototype.
• Xây dựng prototype: Phát triển phiên bản thử nghiệm.
• Đánh giá: Thu thập và phân tích phản hồi.
• Tinh chỉnh: Cải thiện prototype dựa trên phản hồi.
• Phát triển sản phẩm: Xây dựng sản phẩm cuối cùng.

Khi nào nên sử dụng

• Yêu cầu không rõ ràng
• Cần đánh giá tính khả thi
• Cần thu thập phản hồi sớm
• Muốn giảm thiểu rủi ro

B. 3 Mô hình Agile

7. Scrum (Quan trọng - Cần học)

Định nghĩa: Scrum là framework Agile phổ biến, tập trung vào quản lý dự án qua các sprint ngắn và họp thường xuyên.

Scrum (Quan trọng - Cần học)

Các yếu tố chính

• Vai trò: Product Owner, Scrum Master, Development Team (5-9 người).
• Sự kiện: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
• Artifacts: Product Backlog, Sprint Backlog, Increment.

Khi nào nên sử dụng

• Dự án có yêu cầu thay đổi thường xuyên
• Team nhỏ và tự quản lý
• Khách hàng sẵn sàng tham gia thường xuyên
• Cần release sản phẩm nhanh

8. Kanban

Định nghĩa: Kanban là phương pháp quản lý công việc trực quan, tối ưu hóa luồng công việc qua bảng Kanban.

Mô hình Kanban

Nguyên tắc cơ bản

• Trực quan hóa công việc
• Giới hạn WIP (Work In Progress)
• Quản lý luồng
• Chính sách rõ ràng
• Phản hồi liên tục
• Cải tiến liên tục

Khi nào nên sử dụng

• Cần quản lý công việc liên tục
• Muốn giảm thời gian chu kỳ
• Cần cải thiện hiệu suất

9. Extreme Programming (XP)

Định nghĩa: XP tập trung vào cải thiện chất lượng và đáp ứng yêu cầu thay đổi qua 12 nguyên tắc thực hành.

Mô hình Extreme Programming (XP)

12 Nguyên tắc thực hành

• Planning Game
• Simple Design
• Test-Driven Development (TDD)
• Code Standard
• Refactoring
• Pair Programming
• Collective Code Ownership
• Continuous Integration
• Small Release
• System Metaphor
• Onsite Customer
• Sustainable Pace

Khi nào nên sử dụng

• Dự án nhỏ, yêu cầu thay đổi thường xuyên
• Team kỹ năng cao, làm việc theo cặp
• Khách hàng tham gia trực tiếp

Tiêu chí lựa chọn phương pháp

Nắm vững Waterfall và Scrum là đủ cho các dự án cơ bản. Các tiêu chí dưới đây giúp lựa chọn phương pháp phù hợp.

Đặc điểm dự án

Tiêu chí	Waterfall	V-Model	Incremental	Spiral	RUP	Prototype	Scrum	Kanban	XP
Quy mô dự án	Nhỏ-Trung bình	Trung bình	Mọi quy mô	Lớn	Lớn	Nhỏ-Trung bình	Nhỏ-Trung bình	Mọi quy mô	Nhỏ
Độ phức tạp	Thấp-Trung bình	Cao	Mọi mức độ	Cao	Cao	Thấp-Trung bình	Mọi mức độ	Mọi mức độ	Cao
Thời gian	Dài hạn	Dài hạn	Trung hạn	Dài hạn	Dài hạn	Ngắn hạn	Ngắn-Trung hạn	Linh hoạt	Ngắn hạn

Đặc điểm đội ngũ

Tiêu chí	Waterfall	V-Model	Incremental	Spiral	RUP	Prototype	Scrum	Kanban	XP
Kinh nghiệm	Trung bình	Cao	Trung bình	Cao	Cao	Thấp-Trung bình	Cao	Trung bình	Rất cao
Kỹ năng giao tiếp	Trung bình	Cao	Cao	Cao	Cao	Cao	Rất cao	Cao	Rất cao
Quy mô đội	Linh hoạt	Lớn	Trung bình	Lớn	Lớn	Nhỏ	5-9 người	Linh hoạt	Nhỏ

Sự tham gia của khách hàng

Tiêu chí	Waterfall	V-Model	Incremental	Spiral	RUP	Prototype	Scrum	Kanban	XP
Mức độ tham gia	Thấp	Trung bình	Cao	Cao	Trung bình	Rất cao	Cao	Trung bình	Rất cao
Tần suất feedback	Thấp	Trung bình	Cao	Cao	Trung bình	Rất cao	Cao	Liên tục	Rất cao
Yêu cầu thay đổi	Ít	Ít	Nhiều	Trung bình	Trung bình	Nhiều	Nhiều	Linh hoạt	Rất nhiều

Kiểm thử phần mềm (Software Testing - Môn SWT301)

Giới thiệu về kiểm thử

Kiểm thử là gì? Kiểm thử phần mềm là quá trình đánh giá và xác minh xem ứng dụng có đáp ứng yêu cầu kỹ thuật và nghiệp vụ hay không.

Tại sao cần kiểm thử?

• Đảm bảo chất lượng: Phát hiện và sửa lỗi trước khi sử dụng.
• Giảm chi phí: Chi phí sửa lỗi tăng theo thời gian phát hiện.
• Tăng độ tin cậy: Đảm bảo phần mềm hoạt động đúng mong đợi.
• Nâng cao trải nghiệm: Đảm bảo người dùng có trải nghiệm tốt.

7 Nguyên tắc cơ bản của Kiểm thử phần mềm

1. Không thể kiểm thử toàn diện: Không thể kiểm tra tất cả trường hợp, tập trung vào trường hợp quan trọng.
2. Tập trung lỗi: Lỗi thường tập trung ở một số module nhất định.
3. Nghịch lý thuốc trừ sâu: Lặp lại test case cũ không phát hiện lỗi mới.
4. Kiểm thử chỉ phát hiện lỗi: Không thể chứng minh phần mềm không có lỗi.
5. Ảo tưởng không có lỗi: Không tìm thấy lỗi không có nghĩa phần mềm sẵn sàng.
6. Kiểm thử sớm: Bắt đầu kiểm thử sớm trong chu trình phát triển.
7. Kiểm thử phụ thuộc ngữ cảnh: Cách thức kiểm thử phụ thuộc vào bối cảnh ứng dụng.

Kiểm thử chức năng (Functional Testing)

Loại kiểm thử	Mô tả	Khi nào thực hiện	Ai thực hiện
Unit Testing	Kiểm thử từng đơn vị code riêng lẻ (hàm, class).	Trong quá trình viết code	Lập trình viên
Integration Testing	Kiểm thử tương tác giữa các module.	Sau khi hoàn thành các module	Tester/Developer
System Testing	Kiểm thử toàn bộ hệ thống, tất cả tính năng.	Sau khi tích hợp hoàn chỉnh	QA Team
Acceptance Testing	Kiểm thử chấp nhận từ người dùng.	Trước khi bàn giao	End Users/Client
Regression Testing	Kiểm thử lại sau thay đổi, đảm bảo tính năng cũ hoạt động tốt.	Sau mỗi lần cập nhật	QA Team

Kiểm thử phi chức năng (Non-functional Testing)

Loại kiểm thử	Mô tả	Mục đích
Performance Testing	Kiểm tra hiệu năng hệ thống.	Đánh giá tốc độ, khả năng mở rộng.
Security Testing	Kiểm tra tính bảo mật.	Phát hiện lỗ hổng, bảo vệ dữ liệu.
Usability Testing	Kiểm tra tính dễ sử dụng.	Đánh giá giao diện, trải nghiệm người dùng.
Compatibility Testing	Kiểm tra tính tương thích.	Kiểm tra trên nhiều trình duyệt, thiết bị.
Load Testing	Kiểm tra khả năng chịu tải.	Đánh giá hiệu suất dưới tải bình thường.
Stress Testing	Kiểm tra khả năng chịu áp lực.	Đánh giá khả năng phục hồi, điểm gãy.

Quy trình kiểm thử

1. Lập kế hoạch kiểm thử: Xác định phạm vi, mục tiêu, chiến lược.
2. Thiết kế test case: Xây dựng kịch bản kiểm thử.
3. Chuẩn bị môi trường: Cài đặt môi trường test.
4. Thực thi kiểm thử: Chạy các test case.
5. Báo cáo lỗi: Ghi nhận và theo dõi lỗi.
6. Kiểm thử lại: Verify lỗi sau khi sửa.
7. Báo cáo kết quả: Tổng hợp và đánh giá kết quả.

Yêu cầu chức năng và phi chức năng

Tổng quan về yêu cầu phần mềm

Yêu cầu phần mềm là những điều kiện hoặc khả năng hệ thống phải đáp ứng, chia thành:

• Yêu cầu chức năng (FR): Mô tả những gì hệ thống phải làm.
• Yêu cầu phi chức năng (NFR): Mô tả hệ thống phải làm như thế nào.

Yêu cầu chức năng (Functional Requirements)

Phân loại Mô tả Ví dụ cụ thể Quản lý người dùng Chức năng liên quan đến tài khoản, phân quyền. Đăng ký/đăng nhập, quản lý profile, phân quyền. Xử lý nghiệp vụ Quy trình xử lý chính của hệ thống. Tạo đơn hàng, xử lý thanh toán, quản lý kho. Quản lý dữ liệu Thao tác với dữ liệu. Thêm/sửa/xóa, tìm kiếm, đồng bộ hóa dữ liệu. Tương tác người dùng Giao diện và tương tác. Form nhập liệu, menu điều hướng, thông báo. Báo cáo & Thống kê Tổng hợp và phân tích. Báo cáo doanh thu, thống kê người dùng, biểu đồ.

Yêu cầu phi chức năng (Non-Functional Requirements)

Loại yêu cầu	Mô tả	Tiêu chí đánh giá	Ví dụ cụ thể
Hiệu năng	Khả năng đáp ứng về tốc độ, tài nguyên.	Thời gian phản hồi, throughput, sử dụng tài nguyên.	Load trang < 3 giây, xử lý 1000 request/giây.
Bảo mật	Khả năng bảo vệ thông tin.	Xác thực, mã hóa, kiểm soát truy cập.	Xác thực 2 lớp, mã hóa SSL/TLS.
Độ tin cậy	Khả năng hoạt động ổn định.	Uptime, MTBF, disaster recovery.	Uptime 99.9%, backup hàng ngày.
Khả năng sử dụng	Mức độ dễ sử dụng.	Dễ học, dễ nhớ, satisfaction rate.	Hướng dẫn sử dụng, UI/UX thân thiện.
Khả năng mở rộng	Khả năng tăng trưởng, nâng cấp.	Horizontal/vertical scaling, load balancing.	Microservices, auto-scaling.
Khả năng bảo trì	Dễ dàng bảo trì, nâng cấp.	Code quality, documentation, modularity.	Clean code, API documentation.

Lưu ý khi xác định yêu cầu

• SMART: Cụ thể, đo lường được, khả thi, phù hợp, có thời hạn.
• Độ ưu tiên: Must have, Should have, Could have, Won't have.
• Tính khả thi: Đảm bảo thực hiện được với nguồn lực hiện có.
• Tính nhất quán: Các yêu cầu không mâu thuẫn với nhau.

Đề mẫu

Đề thi mẫu SWE201c

Đáp án tham khảo

Câu 1: Lựa chọn mô hình phát triển phần mềm

Tôi đồng ý với đề xuất sử dụng Unified Process (UP) cho dự án này vì các lý do sau:

Yêu cầu

• Yêu cầu rõ ràng: Dự án có yêu cầu chi tiết và rõ ràng, phù hợp với trọng tâm của UP về việc xác định yêu cầu từ đầu. Với hệ thống an toàn như Cruise Control System (CCS), sự rõ ràng này rất quan trọng để đảm bảo chức năng và an toàn.
• Quản lý rủi ro: UP nhấn mạnh việc quản lý rủi ro sớm, điều cần thiết cho hệ thống an toàn như CCS, nơi lỗi có thể gây hậu quả nghiêm trọng.
• Hướng use case: Cách tiếp cận use case của UP mô hình hóa hiệu quả tương tác giữa tài xế và hệ thống, đảm bảo hệ thống đáp ứng nhu cầu người dùng.

Đội ngũ phát triển

• Chuyên môn đội ngũ: Đội ngũ có kỹ năng kỹ thuật mạnh và chuyên môn hóa trong công việc phát triển.
• Phát triển theo giai đoạn: Cấu trúc bốn giai đoạn của UP—Inception, Elaboration, Construction, Transition—phù hợp với thời gian dự án. Cách tiếp cận này cho phép tiến độ tăng dần, đáp ứng thời hạn 7 tháng cho phiên bản đầu tiên và 12 tháng cho bản phát hành cuối.
• Hướng kiến trúc: Dự án yêu cầu kiến trúc hệ thống vững chắc cho phần mềm điều khiển hành trình.

Kết luận: Unified Process là mô hình phù hợp nhất với yêu cầu rõ ràng, quản lý rủi ro và cấu trúc đội ngũ.

Câu 2: Các loại kiểm thử

• Unit Testing
  • Vai trò: Lập trình viên
  • Mục đích: Đảm bảo các thành phần mã nhỏ (hàm, phương thức) hoạt động đúng như kỳ vọng.
• Integration Testing
  • Vai trò: Lập trình viên
  • Mục đích: Đảm bảo các thành phần khác nhau của hệ thống hoạt động tốt khi tích hợp.
• System Testing
  • Vai trò: QA Testers
  • Mục đích: Kiểm tra toàn bộ hệ thống để đảm bảo hoạt động đúng.
• Acceptance Testing
  • Vai trò: QA Testers và người dùng cuối
  • Mục đích: Kiểm tra xem hệ thống có đáp ứng yêu cầu khách hàng và sẵn sàng sử dụng hay không.
• Regression Testing
  • Vai trò: QA Testers
  • Mục đích: Đảm bảo các thay đổi mới không làm hỏng các chức năng đã hoạt động trước đó.
• Performance Testing
  • Vai trò: Performance Testers
  • Mục đích: Đảm bảo hệ thống hoạt động tốt dưới các điều kiện tải.

Câu 3: Yêu cầu chức năng và phi chức năng

Yêu cầu chức năng

• Hệ thống cho phép tài xế thiết lập tốc độ trong phạm vi an toàn (ví dụ: 30-120 km/h).
• Hệ thống tự động điều chỉnh tốc độ để giữ khoảng cách an toàn với xe phía trước.
• Tài xế có thể hủy điều khiển hành trình bất kỳ lúc nào bằng pedal phanh hoặc nút chuyên dụng.
• Hệ thống hiển thị trạng thái hiện tại cho tài xế (ví dụ: Cruise Control Active).
• Hệ thống tự động tắt khi đáp ứng các điều kiện nhất định (ví dụ: nhấn phanh, hệ thống lỗi).

Yêu cầu phi chức năng

Hiệu năng

• Hệ thống phải phản hồi nhanh với thay đổi về tốc độ và khoảng cách, không có độ trễ.
• Hệ thống hoạt động tốt dưới các tốc độ lái, tải và dữ liệu cảm biến khác nhau.
• Hệ thống sử dụng tài nguyên hiệu quả (ví dụ: bộ xử lý, bộ nhớ), ưu tiên các quy trình an toàn.

Tính dễ sử dụng

• Hệ thống hỗ trợ nhiều ngôn ngữ và có giao diện dễ sử dụng.
• Hệ thống thân thiện với người dùng, cho phép tài xế vận hành với ít phân tâm nhất.

Câu 4: User Stories

User Story 1:
As a driver, I want to be able to set the speed of my car within a safe range, so that I can keep a steady speed while driving.

User Story 2:
As a driver, I want the system to automatically adjust the car's speed to maintain a safe distance from the vehicle ahead, so that I can drive safely without manual intervention.

User Story 3:
As a driver, I want the option to cancel cruise control at any time using the brake pedal or a dedicated button, so that I can take control of the car whenever needed.

User Story 4:
As a driver, I want the system to provide visual feedback so that I can always know the system's status while driving.

User Story 5:
As a driver, I want the system to disengage automatically if certain conditions are met, so that I feel safe in emergency situations.

Câu 5: Các mô hình phát triển phần mềm

Mô hình dự đoán (Predictive Models)

• Waterfall Model: Phương pháp từng bước, mỗi giai đoạn (lập kế hoạch, thiết kế, phát triển,...) phải hoàn thành trước khi chuyển sang giai đoạn tiếp theo. Phù hợp khi yêu cầu rõ ràng và ít thay đổi.
• V-Model: Tương tự Waterfall, nhưng tập trung vào kiểm thử. Kiểm thử được thực hiện ở mỗi giai đoạn phát triển, giúp phát hiện vấn đề ngay lập tức.

Mô hình thích ứng (Adaptive Models)

• Agile Model: Phương pháp linh hoạt, cho phép thay đổi trong quá trình phát triển dựa trên phản hồi. Đội ngũ làm việc theo chu kỳ ngắn (iterations) để bàn giao từng phần dự án.
• Scrum: Một cách áp dụng Agile cụ thể. Đội ngũ làm việc theo sprint (2-4 tuần) để hoàn thành các nhiệm vụ nhỏ, khách hàng đưa phản hồi sau mỗi sprint.
• Lean Software Development: Tập trung vào việc mang lại giá trị cho khách hàng bằng cách loại bỏ lãng phí và cải tiến liên tục. Nhằm làm việc nhanh và hiệu quả hơn.

Câu 6: Phân tích và phân chia User Stories

Hoạt động và Nhiệm vụ người dùng

• Thiết lập tốc độ
  • Thiết lập phạm vi tốc độ
  • Điều chỉnh tốc độ
• Duy trì khoảng cách an toàn
  • Phát hiện xe phía trước
  • Điều chỉnh khoảng cách
• Hủy điều khiển hành trình
  • Hủy thủ công
  • Hủy tự động

Release 1

1.1.1 User Story: As a driver, I want to set a speed between 30-120 km/h so that I can maintain a safe and steady speed.
1.2.1 User Story: As a driver, I want to adjust the speed by 1-5 km/h using controls on the steering wheel so that I can make small changes without distraction.
2.1.1 User Story: As a driver, I want the system to detect vehicles ahead and automatically adjust my speed to maintain a safe distance, so that I can drive safely without manually controlling the speed.
2.2.1 User Story: As a driver, I want to set a preferred following distance so that the system can automatically adjust speed to maintain it.
3.1.1 User Story: As a driver, I want to be able to cancel cruise control at any time using the brake pedal or a dedicated button so that I can take full control of the car immediately.

Release 2

1.1.2 User Story: As a driver, I want the system to show my current set speed so that I can monitor it easily.
1.2.2 User Story: As a driver, I want the system to maintain the new speed after I make adjustments.
2.1.2 User Story: As a driver, I want to be alerted when the system detects a vehicle in front.
3.2.1 User Story: As a driver, I want the cruise control to disengage automatically if a malfunction is detected or the brake pedal is pressed, ensuring my safety in critical situations.

Release 3

2.2.2 User Story: As a driver, I want to be able to adjust the following distance at any time using the interface.
3.1.2 User Story: As a driver, I want to receive a visual notification when cruise control is canceled manually.
3.2.2 User Story: As a driver, I want to be notified if cruise control is disengaged due to a malfunction or system issue.

Hướng dẫn làm bài thi PE SWE201c

Phân tích đề thi PE SWE201c

1. Cấu trúc đề thi điển hình

• Phần mô tả dự án: Background công ty, mô tả hệ thống, yêu cầu chính, ràng buộc.
• Các câu hỏi:
  • 1. Lựa chọn quy trình phát triển (2đ)
  • 2. Chiến lược kiểm thử (1đ)
  • 3. Phân loại yêu cầu (2đ)
  • 4. Viết user stories (1.5đ)
  • 5. Đo lường chất lượng (1đ)
  • 6. Tạo story map (2.5đ)

2. Kỹ thuật đọc hiểu đề

• Bước 1: Đọc tổng quan: Xác định loại dự án, độ phức tạp, thời gian, nguồn lực.
• Bước 2: Đánh dấu từ khóa: Thời gian, yêu cầu, team.
• Bước 3: Phân tích ràng buộc: Technical, business, resource constraints.

Câu 1: Lựa chọn mô hình phát triển (2đ)

Quy trình ra quyết định

• Phân tích yêu cầu: Mức độ rõ ràng, khả năng thay đổi, độ phức tạp.
• Đánh giá team: Kinh nghiệm, kỹ năng giao tiếp, cấu trúc team.
• Xem xét ràng buộc: Thời gian, ngân sách, nguồn lực.

Template trả lời

Recommendation to use Agile (Scrum):
a) Requirements:
  - Flexibility: Requirements may change during development
  - Adaptability: Adjust based on user feedback
b) Development Team:
  - Team Structure: 4-6 experienced developers
  - Collaboration: Good communication within team
Conclusion: Scrum is best due to team structure and changing requirements.

Câu 2: Testing Levels & Responsibilities (1đ)

1. Unit Testing
   Tester: Developers
   Focus: Testing individual components
2. Integration Testing
   Tester: Developers / Integration Team
   Focus: Component interactions
3. System Testing
   Tester: QA Team
   Focus: End-to-end system functionality
4. User Acceptance Testing (UAT)
   Tester: End Users
   Focus: Real-world usage scenarios
5. Regression Testing
   Tester: QA Team
   Focus: Impact of changes on existing features

Câu 3: Functional & Non-functional Requirements (2đ)

Cách nhận diện

• FR: [Danh từ] + [Động từ hành động]
• NFR: System needs/should + [Tính chất/Chất lượng]

Template trả lời

Functional Requirements:
• User Registration: The system shall allow users to create accounts.
• Order Processing: The system shall enable order placement.
Non-Functional Requirements:
• Performance: Respond within 3 seconds.
• Security: Encrypt user passwords.

Câu 4: User Stories (1.5đ)

User Story 1:
As a new user
I want to register an account
So that I can access system features

Câu 5: Quality Metrics (1đ)

1. LCOM (Cohesion)
   Description: Measures method cohesion in a class
   Good Value: < 0.5
2. CBO (Coupling)
   Description: Counts class dependencies
   Good Value: < 14
3. Cyclomatic Complexity
   Description: Measures code complexity
   Good Value: < 10

Câu 6: Story Mapping (2.5đ)

Cấu trúc Story Map

Cấu trúc Story Map

• Trục ngang (Activities): Các hoạt động chính theo thứ tự thời gian.
• Trục dọc (Tasks & Stories): User tasks và stories theo độ ưu tiên.

Ví dụ Story Map

A. Activities and User tasks
1. Create Train Schedule
   1.1 Input Schedule Information
   1.2 Set Route Details
B. Releases
Release 1
1.1.1 As a scheduler, I want to input train times

Hướng dẫn làm bài thi FE SWE201c

Từ vựng quan trọng

• Cohesion: Tính gắn kết
• Loose coupling: Liên kết lỏng lẻo
• Agile mindset: Tư duy nhanh nhẹn
• Refactoring: Cải tiến thiết kế

Tổng hợp lý thuyết

• Agile: Phương pháp quản lý linh hoạt, ưu tiên working software.
• Scrum Events: Sprint Planning, Daily Scrum, Sprint Review, Retrospective.
• CIA Triad: Confidentiality, Integrity, Availability.

Thuật ngữ thêm

• Utilize: Sử dụng
• An aspect of: Khía cạnh của
• Proper testing: Kiểm tra đúng cách
• Oracle: Tiêu chuẩn kiểm tra
• Comprehensive: Toàn diện
• Embrace change: Nắm bắt thay đổi
• Temporal cohesion: Liên kết về mặt thời gian
• Prototyping: Tạo mẫu
• Latent error: Lỗi tiềm ẩn
• Arise: Phát sinh
• Explicitly: Rõ ràng

Lý thuyết bổ sung

Các loại lỗi

• Fault/Bug: Lỗi trong mã nguồn.
• Latent Error: Lỗi tồn tại nhưng chưa được kích hoạt.
• Effective Error: Lỗi đã được kích hoạt và gây ra vấn đề.
• Failure: Hành vi sai lệch có thể quan sát được.

Agile Manifesto

• Cá nhân và tương tác > quy trình và công cụ
• Phần mềm hoạt động > tài liệu toàn diện
• Hợp tác với khách hàng > đàm phán hợp đồng
• Phản hồi với thay đổi > tuân theo kế hoạch

Phương pháp tạo mẫu

• Throwaway: Tạo mẫu nhanh để khám phá yêu cầu, sau đó bỏ đi.
• Exploratory: Xây dựng mẫu để thử nghiệm công nghệ mới.

Kết luận

Việc nắm vững kiến thức SWE201c là chìa khóa để bạn tự tin ôn thi PE và ôn thi TE thành công. Với tài liệu SWE201c chi tiết, mẹo thi thực tiễn và bài tập SWE201c được chọn lọc, bạn sẽ sẵn sàng chinh phục kỳ thi. Hãy bắt đầu ôn tập ngay hôm nay để đạt kết quả cao nhất!