SWE201c

Nếu thấy bài viết này hữu ích, hãy để lại 1 ⭐ trên GitHub của mình nhé! Cảm ơn mọi người ❤️

• Nội dung được biên soạn phù hợp với đề thi PE EOS hiện tại
• Link youtube học cho vui: Link YT SWE201c
• Lưu ý: Tài liệu này được chia sẻ miễn phí và không được phép sử dụng cho mục đích thương mại hoặc giảng dạy có thu phí. Các bạn có thể tự do sử dụng cho việc học tập và giảng dạy phi lợi nhuận. Chúc mọi người học tốt!
• Nếu phát hiện sai sót, vui lòng liên hệ tác giả
• Tài liệu này được tham khảo từ : 9 loại phát triển phần mềm được sử dụng hiện nay

Phát video trên YouTube

Mục lục:

• 1. Các phương pháp phát triển phần mềm
• 2. Tiêu chí lựa chọn phương pháp
• 3. Các loại kiểm thử
• 4. Yêu cầu chức năng và phi chức năng
• 5. Hướng dẫn làm bài thi PE SWE201c
• 6. Hướng dẫn làm bài thi FE SWE201c

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

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

Các giai đoạn chính

1. Giai đoạn 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. Giai đoạn 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 người dùng

3. Giai đoạn lập trình (Implementation)

• Lập trình các module
• Kiểm thử đơn vị
• Tích hợp các module

4. Giai đoạn kiểm thử

• Kiểm thử tích hợp
• Kiểm thử hệ thống
• Kiểm thử chấp nhận

5. Giai đoạn triển khai và bảo trì (Deployment & Maintenance)

• Đưa hệ thống lên môi trường thật, chuyển dữ liệu, đào tạo người dù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 được xác định rõ ràng từ đầu
• Tài liệu đầy đủ cho mỗi giai đoạn
• Về nguyên tắc các giai đoạn không chồng chéo: giai đoạn sau chỉ bắt đầu khi giai đoạn trước đã ký nghiệm thu. (Bản thân Royce — người vẽ sơ đồ này năm 1970 — đã nói mô hình thuần tuần tự là "rủi ro và mời gọi thất bại", và đề nghị thêm vòng lặp quay lại giai đoạn trước. Cái được dạy dưới tên Waterfall là phiên bản đã bỏ mất các vòng lặp đó.)

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 dự án đầy đủ
• Cần tài liệu chi tiết cho mỗi giai đoạn

Ư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 tương ứng.

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

Cặp đối xứng — điểm cốt lõi của V-Model

Liệt kê hai cột như trên là chưa đủ, vì cái làm nên chữ V không phải là "có 8 giai đoạn" mà là từng giai đoạn bên trái được ghép với đúng một mức kiểm thử bên phải. Kế hoạch kiểm thử của mỗi mức được viết ngay khi làm giai đoạn tương ứng bên trái, chứ không đợi đến lúc code xong.

Để ý thứ tự ngược nhau: giai đoạn cao nhất bên trái (yêu cầu) ghép với mức kiểm thử cuối cùng bên phải (acceptance), còn giai đoạn thấp nhất bên trái (thiết kế module) ghép với mức kiểm thử đầu tiên (unit). Đó là lý do hình vẽ có dạng chữ V chứ không phải hai cột song song.

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
• Lỗi phát hiện muộn có chi phí rất cao (y tế, hàng không, ngân hàng lõi) — V-Model bắt viết kế hoạch kiểm thử sớm nên bắt lỗi đặc tả sớm hơn Waterfall

Ưu điểm

• Kiểm thử được lập kế hoạch song song với thiết kế, không dồn về cuối
• Mỗi giai đoạn có tiêu chí ra rõ ràng nên dễ theo dõi tiến độ
• Bắt lỗi đặc tả sớm hơn Waterfall vì phải nghĩ "test cái này thế nào" ngay lúc viết đặc tả

Nhược điểm

• Vẫn cứng như Waterfall: yêu cầu đổi giữa dự án thì phải sửa cả hai nhánh của chữ V
• Không có prototype hay bản chạy được nào cho khách xem cho đến giai đoạn muộn
• Cần nhiều tài liệu, tốn công với dự án 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 là phương pháp phát triển phần mềm đặ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à dần dần tích hợp các tính năng mới.

Incremental và Iterative khác nhau thế nào

Hai chữ này hay bị dùng lẫn, nhưng chúng trả lời hai câu hỏi khác nhau, và đề thi thích hỏi đúng chỗ khác nhau đó:

Thực tế các dự án dùng cả hai cùng lúc, và đó chính là lý do mô hình này được gọi bằng cả hai chữ: mỗi vòng vừa thêm tính năng mới (incremental) vừa tinh chỉnh những gì đã làm dựa trên phản hồi (iterative).

Các giai đoạn chính

Khác với Waterfall, mô hình này không có một dãy giai đoạn chạy một lần. Nó có một vòng lặp được chạy lại nhiều lần, mỗi vòng là một mini-project đầy đủ:

• Lập kế hoạch ban đầu (chỉ một lần): xác định tầm nhìn sản phẩm và chia công việc thành danh sách các increment, sắp theo mức độ quan trọng
• Mỗi vòng lặp: phân tích yêu cầu của increment này → thiết kế → lập trình → kiểm thử → tích hợp vào bản đang có → giao cho khách xem
• Đánh giá cuối mỗi vòng: lấy phản hồi, cập nhật lại danh sách increment còn lại — thứ tự ưu tiên có thể đổi
• Lặp lại cho đến khi hết increment hoặc hết ngân sách

Điểm quan trọng: sau vòng lặp đầu tiên đã có một sản phẩm chạy được và giao được, dù còn thiếu tính năng. Đây là khác biệt lớn nhất so với Waterfall và V-Model, nơi không có gì chạy được cho đến gần cuối.

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

• Cần nhanh chóng cung cấp chức năng thiết yếu, phần còn lại giao sau
• Yêu cầu tổng thể đã rõ, nhưng chi tiết còn có thể thay đổi
• Team chưa quen với lĩnh vực, cần học dần qua từng vòng
• Cần phản hồi thật từ người dùng trước khi làm tiếp phần lớn hệ thống

Ưu điểm

• Có sản phẩm chạy được sớm, thấy được tiến độ thật thay vì tin vào tài liệu
• Yêu cầu đổi ở vòng sau không phá vỡ những gì đã làm
• Rủi ro được chia nhỏ theo vòng thay vì dồn hết vào cuối dự án

Nhược điểm

• Cần một kiến trúc tốt từ đầu, nếu không thì đến vòng thứ năm phải viết lại từ gốc
• Tổng chi phí thường cao hơn Waterfall vì tích hợp và kiểm thử bị lặp lại nhiều lần
• Khó ước lượng ngày kết thúc và tổng chi phí ngay từ đầu

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

Định nghĩa

Mô hình Xoắn ốc là cách tiếp cận phát triển phần mềm trong đó các hoạt động được tổ chức theo mô hình xoắn ốc và thực hiện theo thứ tự được xác định thông qua phân tích rủi ro.

Các giai đoạn chính

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

Bốn giai đoạn trên là bốn góc phần tư của hình xoắn ốc, và mỗi vòng xoắn đi qua đủ cả bốn. Vòng càng ra xa tâm thì càng tốn chi phí — trục bán kính trong hình chính là chi phí tích luỹ.

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

Spiral được chọn vì một lý do và chỉ một lý do: rủi ro. Nếu đề thi không có dấu hiệu rủi ro nào thì gần như chắc chắn không phải Spiral.

• Dự án lớn, đắt, rủi ro cao — thất bại thì mất rất nhiều tiền
• Có rủi ro kỹ thuật chưa biết trả lời được không: công nghệ mới chưa ai dùng, yêu cầu hiệu năng cực đoan, tích hợp với hệ thống lạ
• Yêu cầu khó nắm bắt và cần làm prototype qua nhiều vòng mới rõ
• Khách hàng sẵn sàng tham gia đánh giá cuối mỗi vòng
• Cần một điểm dừng có kiểm soát: sau mỗi vòng có thể quyết định "đi tiếp hay huỷ dự án" dựa trên rủi ro còn lại

Ưu điểm

• Rủi ro lớn được phát hiện và xử lý sớm, không nổ ra ở cuối dự án
• Có điểm quyết định huỷ/tiếp sau mỗi vòng, giới hạn được thiệt hại
• Linh hoạt: mỗi vòng có thể chọn mô hình con phù hợp (Waterfall hay prototype)

Nhược điểm

• Phức tạp và đắt để quản lý — cần người thật sự biết phân tích rủi ro
• Số vòng không biết trước nên rất khó ước lượng ngày kết thúc và chi phí
• Quá nặng cho dự án nhỏ hoặc rủi ro thấp

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

Định nghĩa

RUP là phương pháp phát triển phần mềm được trang bị nhiều công cụ hỗ trợ việc tạo ra sản phẩm cuối cùng và các nhiệm vụ liên quan. Đây là phương pháp hướng đối tượng được sử dụng cho cả quản lý dự án và phát triển phần mềm chất lượng cao.

Các giai đoạn chính

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

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

• Dự án lớn, phức tạp, đội ngũ đông hoặc phân tán nhiều nơi — cần vai trò và sản phẩm đầu ra được định nghĩa rõ để phối hợp
• Cần tài liệu và khả năng truy vết đầy đủ (ngành có quy định pháp lý, hợp đồng yêu cầu bàn giao tài liệu)
• Yêu cầu chi tiết còn có thể thay đổi, nhưng kiến trúc phải được chốt sớm và giữ ổn định
• Muốn phát triển lặp mà vẫn giữ được kỷ luật quy trình — RUP thường được coi là cầu nối giữa Waterfall và Agile
• Dự án hướng đối tượng, dùng UML và use case làm trung tâm

Ngược lại, RUP là lựa chọn sai khi dự án nhỏ, team dưới mười người, hoặc khi yêu cầu đổi quá nhanh đến mức làm tài liệu không kịp có giá trị — lúc đó Scrum phù hợp hơn.

Ưu điểm

• Kết hợp được tính lặp của Agile với tài liệu và kỷ luật của Waterfall
• Kiến trúc được chốt sớm ở pha Elaboration nên giảm rủi ro phải viết lại
• Vai trò, quy trình và sản phẩm đầu ra được định nghĩa rõ, dễ mở rộng cho team lớn

Nhược điểm

• Nặng và phức tạp: cần chuyên gia quy trình, khối lượng tài liệu lớn
• Quá tốn kém cho dự án nhỏ
• Dễ bị áp dụng nửa vời — làm đủ tài liệu nhưng không thực sự lặp, thành ra Waterfall đắt tiền

#6. Mô hình Prototype

Định nghĩa

Mô hình Prototype là quá trình tạo ra một phiên bản thử nghiệm của sản phẩm để kiểm tra và đánh giá trước khi phát triển phiên bản cuối cùng. Đây là cách tiếp cận hiệu quả để thu thập phản hồi về yêu cầu, chức năng và khả năng sử dụng.

Các giai đoạn chính

• Xác định yêu cầu: Thu thập các yêu cầu cơ bản cho hệ thống
• 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 từ người dùng
• 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

Hai loại prototype

Đề thi FE hay hỏi phân loại này, và nó cũng quyết định bạn viết code prototype cẩn thận đến đâu:

• Throwaway / Rapid Prototyping — dựng mẫu thật nhanh, chỉ để làm rõ yêu cầu, rồi bỏ đi và xây lại sản phẩm thật từ đầu. Code mẫu cố tình làm sơ sài vì biết trước là sẽ xoá.
• Evolutionary Prototyping — mẫu đầu tiên được tinh chỉnh dần qua từng vòng và trở thành sản phẩm cuối. Vì vậy phải viết tử tế ngay từ mẫu đầu.

Rủi ro kinh điển của loại thứ hai: một prototype được dựng để "chỉ demo cho khách" rồi bị đẩy lên production vì trông đã chạy được — mang theo toàn bộ nợ kỹ thuật của một bản dựng tạm.

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

• Yêu cầu của hệ thống không rõ ràng, khách hàng chưa diễn tả được mình muốn gì
• Hệ thống có nhiều tương tác người dùng — giao diện cần thấy mới góp ý được
• Cần đánh giá tính khả thi của giải pháp
• Cần thu thập phản hồi sớm từ người dùng
• Muốn giảm thiểu rủi ro trong phát triển

Ưu điểm

• Phát hiện sai lệch về yêu cầu rất sớm, khi sửa còn rẻ
• Khách hàng tham gia được ngay vì có thứ nhìn thấy để góp ý
• Giảm rủi ro làm xong cả hệ thống rồi mới biết là làm sai

Nhược điểm

• Khách hàng dễ tưởng prototype là sản phẩm gần xong và đòi bàn giao sớm
• Dễ sa vào vòng lặp vô hạn nếu không chốt được yêu cầu — mỗi lần xem lại khách lại nghĩ ra thứ mới
• Prototype dựng tạm nếu bị đem lên production sẽ để lại nợ kỹ thuật lâu dài

B. 3 Mô hình thuộc nhóm Agile

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

Định nghĩa

Scrum là framework phổ biến nhất trong Agile, tập trung vào việc quản lý dự án thông qua các sprint ngắn và các cuộc họp thường xuyên. Đây là phương pháp được sử dụng rộng rãi trong ngành công nghiệp phần mềm và là kiến thức bắt buộc cho mọi lập trình viên.

Các yếu tố chính

• Vai trò:
  • Product Owner: Đại diện khách hàng, quản lý product backlog, định hướng sản phẩm
  • Scrum Master: Hỗ trợ team, loại bỏ trở ngại, đảm bảo quy trình Scrum được tuân thủ
  • Development Team: Nhóm phát triển sản phẩm (thường 5-9 người)
• Sự kiện:
  • Sprint: bản thân sprint là một sự kiện — nó là cái chứa bốn sự kiện còn lại. Dài 1–4 tuần, và độ dài được giữ cố định giữa các sprint để team ước lượng được.
  • Sprint Planning: chọn các item từ Product Backlog và lập Sprint Backlog. Tối đa 8 giờ cho một sprint dài một tháng.
  • Daily Scrum: Họp ngắn tối đa 15 phút hàng ngày, cập nhật tiến độ và khó khăn
  • Sprint Review: Đánh giá kết quả sprint với stakeholders. Tối đa 4 giờ cho sprint một tháng.
  • Sprint Retrospective: Rút kinh nghiệm và cải thiện quy trình. Tối đa 3 giờ cho sprint một tháng.
• Artifacts:
  • Product Backlog: Danh sách yêu cầu sản phẩm được sắp xếp theo độ ưu tiên
  • Sprint Backlog: Danh sách công việc cụ thể cho sprint hiện tại
  • Increment: Phiên bản sản phẩm có thể chạy được sau mỗi sprint

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

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

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

• Team quá lớn (>9 người) hoặc phân tán địa lý
• Khách hàng không thể tham gia thường xuyên
• Dự án có yêu cầu cố định, ít thay đổi
• Tổ chức có văn hóa command-and-control mạnh
• Dự án đòi hỏi tài liệu chi tiết từ đầu

Lưu ý quan trọng

Scrum là framework phổ biến nhất trong phát triển phần mềm hiện đại và là kiến thức cốt lõi cho mọi lập trình viên. Việc hiểu và thực hành tốt Scrum sẽ giúp bạn:

• Dễ dàng hội nhập vào các dự án phần mềm chuyên nghiệp
• Nâng cao khả năng làm việc nhóm và giao tiếp
• Tăng cơ hội nghề nghiệp trong ngành công nghệ
• Hiểu rõ quy trình phát triển phần mềm hiện đại

#8. Kanban

Định nghĩa

Kanban là phương pháp quản lý công việc trực quan, bắt nguồn từ hệ thống sản xuất của Toyota. Phương pháp này tập trung vào việc cải thiện liên tục và tối ưu hóa luồng công việc thông qua việc trực quan hóa quy trình làm việc trên bảng Kanban.

Nguyên tắc cơ bản

• Trực quan hóa công việc: Sử dụng bảng Kanban với các cột như "To Do", "In Progress", "Done" để theo dõi tiến độ công việc một cách trực quan
• Giới hạn WIP (Work In Progress): Hạn chế số lượng công việc đang thực hiện để tránh quá tải và tăng hiệu suất hoàn thành
• Quản lý luồng: Đảm bảo công việc di chuyển trơn tru giữa các giai đoạn, xác định và giải quyết các điểm nghẽn
• Chính sách rõ ràng: Thiết lập và truyền đạt rõ ràng các quy tắc, tiêu chuẩn và quy trình làm việc
• Phản hồi liên tục: Tổ chức các buổi review định kỳ để đánh giá và cải thiện quy trình
• Cải tiến liên tục: Thường xuyên phân tích metrics và tìm cách tối ưu hóa quy trình

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

• Cần quản lý công việc liên tục và có tính lặp lại
• Muốn giảm thời gian chu kỳ và tăng tốc độ delivery
• Cần cải thiện hiệu suất và chất lượng công việc liên tục
• Công việc có tính chất dịch vụ hoặc hỗ trợ
• Team cần sự linh hoạt trong quản lý công việc
• Muốn giảm thiểu lãng phí và tối ưu hóa nguồn lực

Ưu điểm

• Tăng tính minh bạch và khả năng theo dõi công việc
• Giảm thời gian chờ đợi và tăng hiệu suất
• Cải thiện chất lượng sản phẩm/dịch vụ
• Tăng sự hài lòng của khách hàng
• Giảm stress cho team và tăng sự hợp tác
• Áp lên quy trình đang có mà không cần đổi vai trò hay cấu trúc team — chi phí bắt đầu gần bằng không
• Việc gấp có thể vào bảng bất cứ lúc nào, không phải đợi hết sprint

Nhược điểm

• Không có mốc thời gian nào bắt buộc, nên rất khó trả lời "bao giờ xong?" nếu team không đo và dùng số liệu (lead time, cycle time, throughput)
• Ít nghi thức cũng nghĩa là ít điểm bắt buộc phải cải tiến: nếu không tự tổ chức review thì bảng Kanban chỉ còn là chỗ để việc, không cải thiện gì
• Không phù hợp cho dự án cần một bản phát hành lớn theo hạn cố định
• Giới hạn WIP đặt sai (quá lỏng) thì mất hết tác dụng; đặt đúng cần vài tuần thử và điều chỉnh
• Không quy định vai trò nào, nên với team mới hoặc chưa tự chủ, việc dễ bị bỏ lửng giữa các cột

#9. Extreme Programming (XP)

Định nghĩa

XP là phương pháp phát triển phần mềm tập trung vào việc cải thiện chất lượng và khả năng đáp ứng với yêu cầu thay đổi của khách hàng thông qua 12 nguyên tắc thực hành cốt lõi.

12 Nguyên tắc thực hành cốt lõi

• Planning Game: Lập kế hoạch 2 cấp độ (release và iteration) với 3 bước: khám phá, cam kết và điều hướng
• Simple Design: Bắt đầu với thiết kế đơn giản và để nó phát triển qua các iteration
• Test-Driven Development (TDD): Viết test case trước khi viết code, tự động hóa unit test
• Code Standard: Tuân thủ các tiêu chuẩn code thống nhất trong team
• Refactoring: Cải thiện cấu trúc code thường xuyên mà không thay đổi hành vi
• Pair Programming: Hai lập trình viên dùng chung một máy. Driver gõ code, lo phần chi tiết đang làm; Navigator quan sát, nghĩ trước một bước, chỉ ra lỗi và hướng đi. Hai người đổi vai thường xuyên. (Vai trò là driver — không phải "pilot")
• Collective Code Ownership: Code thuộc về cả team, ai cũng có thể sửa bất kỳ phần nào
• Continuous Integration: Tích hợp code thường xuyên, tự động hóa kiểm thử
• Small Release: Phát hành bản chạy được ra production theo chu kỳ ngắn (vài tuần), mỗi bản thêm một lượng nhỏ chức năng. Bản đầu tiên có thể là MVP, nhưng các bản sau thì không — chúng là các lần bồi thêm lên sản phẩm đã có
• System Metaphor: Sử dụng ngôn ngữ chung dễ hiểu giữa developer và user
• Onsite Customer: Khách hàng làm việc trực tiếp với team, tương tự Product Owner trong Scrum
• Sustainable Pace: Duy trì tốc độ phát triển bền vững, có thời gian buffer để xử lý vấn đề

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

• Dự án nhỏ với yêu cầu thay đổi thường xuyên
• Team có kỹ năng cao và sẵn sàng làm việc theo cặp
• Khách hàng có thể tham gia trực tiếp vào dự án
• Cần đảm bảo chất lượng code cao thông qua TDD
• Muốn giảm thiểu rủi ro kỹ thuật thông qua tích hợp liên tục

Ưu điểm

• Chất lượng code cao nhất trong các phương pháp Agile: TDD cho bộ test tự động, pair programming cho review ngay lúc viết, refactoring liên tục chống nợ kỹ thuật
• Sửa yêu cầu rất rẻ — thiết kế đơn giản cộng bộ test dày đặc nghĩa là đổi code không sợ vỡ chỗ khác
• Kiến thức lan trong team, không có "người duy nhất hiểu module này"

Nhược điểm

• Đòi hỏi kỷ luật rất cao. Bỏ một practice thường làm sập các practice khác — bỏ test thì refactoring và collective ownership thành nguy hiểm
• Pair programming làm chi phí nhân sự trên mỗi dòng code tăng, khó thuyết phục quản lý, và không phải ai cũng làm việc được theo cặp cả ngày
• Cần khách hàng ngồi cùng (onsite customer) — điều kiện rất ít dự án thực tế đáp ứng
• Không có tài liệu thiết kế dày, khó dùng cho hợp đồng cố định phạm vi hoặc ngành bị quản lý chặt (nơi RUP mạnh hơn)
• Khó mở rộng cho team lớn hoặc phân tán: nhiều practice giả định cả team ngồi cùng phòng

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

Bạn chỉ cần nắm vững Waterfall với Scrum thôi là đủ rồi nhé, còn nếu chuyên sâu hơn thì coi ở dưới nhé.

Đặc điểm dự án

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

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

3. 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 một ứng dụng hoặc sản phẩm phần mềm có đáp ứng các yêu cầu kỹ thuật và nghiệp vụ đã đề ra 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 đưa vào sử dụng
• Giảm chi phí: Chi phí sửa lỗi sẽ tăng theo thời gian phát hiện lỗi
• Tăng độ tin cậy: Đảm bảo phần mềm hoạt động đúng như mong đợi
• Nâng cao trải nghiệm: Đảm bảo người dùng có trải nghiệm tốt với sản phẩm

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 (Exhaustive testing is not possible): Không thể kiểm tra tất cả các trường hợp có thể xảy ra, cần tập trung vào các trường hợp quan trọng.
2. Tập trung lỗi (Defect Clustering): Phần lớn các lỗi thường tập trung ở một số module nhất định của phần mềm.
3. Nghịch lý thuốc trừ sâu (Pesticide Paradox): Việc lặp lại cùng một bộ test case sẽ không phát hiện được lỗi mới.
4. Kiểm thử chỉ phát hiện lỗi (Testing shows presence of defects): Kiểm thử có thể chỉ ra sự tồn tại của lỗi nhưng không thể chứng minh phần mềm hoàn toàn không có lỗi.
5. Ảo tưởng không có lỗi (Absence of Error – fallacy): Việc không tìm thấy lỗi không đồng nghĩa với việc phần mềm đã sẵn sàng để phát hành.
6. Kiểm thử sớm (Early Testing): Việc kiểm thử nên được bắt đầu càng sớm càng tốt trong chu trình phát triển phần mềm.
7. Kiểm thử phụ thuộc ngữ cảnh (Testing is context dependent): Cách thức kiểm thử phụ thuộc vào bối cảnh của ứng dụng.

Ba trục để phân loại kiểm thử

Chỗ hay mất điểm nhất của phần này là gộp ba câu hỏi khác nhau vào một danh sách. Trước khi học tên từng loại, hãy nắm ba trục độc lập sau — một phép kiểm thử luôn có vị trí trên cả ba trục cùng lúc.

Ví dụ: một test case "đăng nhập sai mật khẩu 5 lần thì bị khóa tài khoản" là mức System, loại Functional, kỹ thuật Black-box. Cùng chức năng đó, nếu người viết test đọc code để chọn đầu vào phủ hết các nhánh if thì nó thành White-box — mức và loại không đổi.

Black-box, White-box, Grey-box

1. Bốn mức kiểm thử (Test Levels)

Bốn mức dưới đây xếp theo kích thước của thứ đang được kiểm thử, từ một hàm đơn lẻ tới cả hệ thống trong tay người dùng. Đây là trục mức, không phải trục loại — vì vậy Regression không nằm trong bảng này (xem mục 3 bên dưới).

Hai mức tích hợp hay bị hỏi thêm

• Component/Module Testing — nằm giữa Unit và Integration: kiểm thử một component hoàn chỉnh (nhiều class hợp lại) một cách độc lập, thường phải dùng stub (thay thế cho module bị gọi) và driver (thay thế cho module gọi đến).
• Acceptance Testing chia hai: Alpha làm tại nơi phát triển với người dùng nội bộ; Beta làm tại chỗ người dùng thật, ngoài tầm kiểm soát của team. Cả hai đều là validation.

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

Kiểm thử chức năng hỏi "hệ thống có làm đúng việc không". Kiểm thử phi chức năng hỏi "hệ thống làm việc đó tốt đến mức nào" — nhanh, an toàn, dễ dùng, chạy được ở đâu. Một hệ thống pass hết functional test vẫn có thể không dùng được nếu mỗi thao tác mất 30 giây.

3. Kiểm thử liên quan đến thay đổi (Change-related Testing)

Nhóm này không thuộc functional hay non-functional — nó được định nghĩa bởi lý do chạy: có một thay đổi vừa vào code. Bốn tên dưới đây bị lẫn nhau nhiều nhất trong đề thi.

Liên hệ ngược lên 7 nguyên tắc ở đầu mục: bộ regression suite chạy y nguyên mãi mãi chính là ví dụ điển hình của nghịch lý thuốc trừ sâu — nó sẽ ngừng tìm ra lỗi mới. Vì vậy regression suite cần được rà và bổ sung test case định kỳ, không phải viết một lần rồi để đó.

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, và chiến lược
2. Thiết kế test case: Xây dựng các kịch bản kiểm thử
3. Chuẩn bị môi trường: Cài đặt và cấu hình môi trường test
4. Thực thi kiểm thử: Chạy các test case đã thiết kế
5. Báo cáo lỗi: Ghi nhận và theo dõi các lỗi phát hiện
6. Retest và regression: Chạy lại đúng test đã fail để xác nhận lỗi đã hết (retest), rồi chạy lại các test đã pass để chắc bản sửa không phá chỗ khác (regression)
7. Báo cáo kết quả: Tổng hợp và đánh giá kết quả kiểm thử

4. 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 mà hệ thống phải đáp ứng. Được chia thành hai loại chí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

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

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

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

• SMART: Yêu cầu phải Specific (cụ thể), Measurable (đo lường được), Achievable (khả thi), Relevant (phù hợp), Time-bound (có thời hạn)
• Độ ưu tiên: Phân loại yêu cầu theo mức độ quan trọng (Must have, Should have, Could have, Won't have)
• Tính khả thi: Đảm bảo yêu cầu có thể 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

Hướng dẫn làm bài thi PE SWE201c - LƯU Ý MANG TÍNH CHẤT THAM KHẢO

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/tổ chức
  • Mô tả hệ thống cần phát triển
  • Các yêu cầu chính của hệ thống
  • Ràng buộc về thời gian và nguồn lực
• Các câu hỏi gặp trong đề thi
  • 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 (new/maintenance)
• Độ phức tạp của hệ thống
• Thời gian và nguồn lực có sẵn

Bước 2: Đánh dấu từ khóa quan trọng

Đây là bảng đáng học nhất của cả phần PE: đề bao giờ cũng gài tín hiệu trong đoạn mô tả bối cảnh, và câu 1 chấm chủ yếu vào việc bạn có đọc ra được không. Dòng đầu tiên là dòng quan trọng nhất.

Bước 3: Phân tích ràng buộc

• Technical constraints
• Business constraints
• Resource constraints

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

Cách chọn mô hình phát triển

Quy trình ra quyết định

• Bước 1: Phân tích yêu cầu
  • Mức độ rõ ràng của yêu cầu
  • Khả năng thay đổi yêu cầu
  • Độ phức tạp của dự án
• Bước 2: Đánh giá team
  • Kinh nghiệm của team
  • Kỹ năng giao tiếp
  • Cấu trúc team
• Bước 3: Xem xét ràng buộc
  • Thời gian
  • Ngân sách
  • Nguồn lực

Templates trả lời cho từng mô hình

Template cho Agile (Scrum)

Recommendation to use Agile:
I suggest using the Agile method for these reasons:

a) Requirements:
• Flexibility: Requirements not clearly defined, might change during development
• Adaptability: Need to adjust based on user feedback and market trends
• Thoroughness: Many requirements need early validation

b) Development Team:
• Team Structure: 4-6 experienced developers, perfect for Scrum
• Strong Collaboration: Good communication within team
• Role Expertise: Clear roles (PO, Scrum Master, Developers)
• Adaptability: Can quickly adjust to changes
• Time Constraints: Fits well with sprint cycles

Conclusion:
Scrum is best due to team structure, need for iteration, and ability to handle changing requirements.
                            

Template cho Waterfall

Recommendation to use Waterfall:
I recommend the Waterfall method for these reasons:

a) Requirements:
• Clear and Stable: Requirements well-defined from start
• Structured Approach: Step-by-step process needed
• Detailed Planning: Complex requirements need thorough documentation

b) Development Team:
• Team Structure: Works well in structured environment
• Specific Roles: Clear separation of responsibilities
• Documentation Focus: Strong documentation practices
• Predictability: Well-defined timeline and milestones

Conclusion:
Waterfall is best due to clear requirements, structured roles, and need for documentation.
                            

Tiêu chí chấm điểm

Đây là cách chia điểm ước lượng cho câu 2 điểm — dùng để biết nên dồn chữ vào đâu, không phải barem chính thức.

Đọc bảng theo tỷ lệ thì rõ hơn đọc theo số: ba phần tư số điểm nằm ở phần phân tích và lập luận, chỉ một phần tám ở chỗ nêu tên mô hình. Viết "Chọn Waterfall" rồi hết là mất gần hết điểm, dù chọn đúng.

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

Template trả lời mẫu (Nhớ paraphrase lại nhé và học thuộc hoặc học hiểu tùy vào bạn)

Based on the project requirements, the following testing levels are proposed:

1. Unit Testing
   Tester: Developers
   Focus:
   - Testing individual software components
   - Verifying correct functionality of each component
   - Code coverage and basic functionality checks

2. Integration Testing
   Tester: Developers or dedicated integration testing team
   Focus:
   - Component interactions and compatibility
   - Interface testing between modules
   - Data flow verification

3. System Testing
   Tester: Dedicated testing team
   Focus:
   - End-to-end system functionality
   - Requirements verification
   - Complete system behavior testing

4. User Acceptance Testing (UAT)
   Tester: End users
   Focus:
   - Real-world usage scenarios
   - Business requirement validation
   - User workflow verification

In addition to the four levels above, the following test types
will be applied across those levels:

- Regression Testing
  Tester: Testing team, supported by automated test suites
  Purpose: ensure that each change does not break features
  that already worked. Runs after every build, at unit,
  integration and system level.

- Performance Testing (including load and stress testing)
  Tester: Specialised performance engineers
  Purpose: verify response time and throughput at the
  expected user volume (load), and locate the breaking
  point beyond it (stress).
                                            

Từ khóa quan trọng cho mỗi level

Các trường hợp đặc biệt

Regression Testing

• Change Impact Analysis
• Automated Test Suites
• System Stability Checks
• Feature Verification

Performance Testing

• Load Testing
• Stress Testing
• Performance Monitoring
• Peak Load Simulation

Tips quan trọng

1. Phân công testing đúng người
   • Unit testing → Developers
   • Integration → Dev team/Testing team
   • System → Dedicated testers
   • UAT → End users
2. Thứ tự testing
   • Start with Unit Testing
   • Move to Integration
   • Complete System Testing
   • Finish with UAT
3. Focus areas
   • Component functionality
   • Integration points
   • System requirements
   • User acceptance

Tiêu chí chấm điểm

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

Bảng nhận diện chi tiết

Template trả lời chuẩn

                            Functional Requirements:
                            • [Tên chức năng ngắn gọn]: The system shall [động từ] [mô tả chi tiết chức năng].
                            Source: "[trích dẫn từ case study]"

                            Ví dụ:
                            • User Registration: The system shall allow users to create new accounts with email and password.
                            • Order Processing: The system shall enable customers to place and track their orders.
                            • Report Generation: The system shall provide managers with daily sales reports.

                            Non-Functional Requirements:
                            • [Loại NFR]: The system shall [mô tả yêu cầu] [chỉ số cụ thể nếu có].
                            Source: "[trích dẫn từ case study]"

                            Ví dụ:
                            • Performance: The system shall respond to user requests within 3 seconds.
                            • Security: The system shall encrypt all user passwords using SHA-256.
                            • Reliability: The system shall maintain 99.9% uptime during business hours.

Quy tắc format:

• Cách đặt tên FR:
  [Danh từ] + [Hành động]: User Registration, Order Processing, Data Management
  Hoặc
  [Hành động] + [Đối tượng]: Manage Users, Process Orders, Generate Reports
• Cấu trúc câu mô tả:
  "The system shall" + [động từ] + [chi tiết chức năng/yêu cầu]
• Cách đặt tên NFR:
  [Loại NFR]: Performance, Security, Usability, Reliability, etc.
• Format trình bày:
  • Dùng bullet points (•)
  • In đậm tên yêu cầu
  • Dùng dấu hai chấm (:) sau tên
  • Mỗi yêu cầu một dòng riêng

Ví dụ đáp án hoàn chỉnh:

                            Functional Requirements:
                            • Data Entry: The system shall allow users to input customer information into the database.
                            Source: "Users need to input customer details into the system"

                            • Report Generation: The system shall generate monthly sales reports automatically.
                            Source: "System must provide monthly reports for management"

                            • User Management: The system shall enable administrators to create and modify user accounts.
                            Source: "Admin needs to manage system users"

                            Non-Functional Requirements:
                            • Performance: The system shall process all data entry operations within 1 second.
                            Source: "System must be fast and responsive"

                            • Security: The system shall require two-factor authentication for admin access.
                            Source: "System needs strong security measures"

                            • Reliability: The system shall maintain 99.9% uptime during working hours.
                            Source: "System must be highly available"

Tiêu chí chấm điểm

Câu 4: User Stories dựa trên Requirements (1.5đ)

Cấu trúc chuẩn cho mỗi User Story

            As a [role]
            I want to [action/feature từ FR hoặc NFR]
            So that [benefit/value]

            Ví dụ từ FR "System shall allow users to register":
            As a new user
            I want to register an account
            So that I can access the system's features

Template trả lời

            User Story 1: [Từ FR/NFR 1]
            As a [role liên quan đến requirement]
            I want to [chức năng/yêu cầu từ requirement]
            So that [lợi ích mang lại]

            [Tiếp tục với 4 User Story còn lại...]

INVEST — sáu tiêu chí của một user story tốt

Viết đúng khuôn "As a / I want / So that" chỉ đảm bảo hình thức. INVEST là bộ sáu tiêu chí để kiểm tra nội dung. Đề bài không bắt liệt kê INVEST, nhưng người chấm dùng chính sáu tiêu chí này để trừ điểm — và câu 6 (story mapping) thì trừ điểm thẳng vào chữ Small.

Tips làm bài

1. Chọn requirement để viết story
   • Ưu tiên các FR rõ ràng, cụ thể
   • Có thể dùng cả FR và NFR
   • Chọn requirement có tác động lớn đến user
2. Xác định role
   • Role phải phù hợp với requirement
   • Dùng role cụ thể (không dùng "user" chung chung)
   • Có thể dùng: admin, manager, customer, staff...
3. Viết benefit
   • Benefit phải rõ ràng, cụ thể
   • Liên quan trực tiếp đến role
   • Thể hiện được giá trị thực tế

Thang điểm chi tiết (1.5đ) - Tham khảo chứ không hẳn là đúng

Câu 5: Quality Metrics (1.0đ)

Template trả lời chuẩn

To measure code and design quality in this project, I propose these metrics:

1. LCOM (Lack of Cohesion of Methods) - Measuring Cohesion
   • Description: Measures how weakly the methods of a class are related to each other
   • Formula: LCOM = P - Q, where P = number of method pairs sharing
     no attribute, Q = number of method pairs sharing at least one
     attribute. If P - Q is negative, LCOM is taken as 0.
   • Good Value: 0 (lower is better; the value is a count, not a ratio)
   • Application in Project: Use to identify classes that may need to be split into smaller, more focused classes

2. CBO (Coupling Between Objects) - Measuring Coupling
   • Description: Counts number of other classes a class is coupled to
   • Formula: Count unique class dependencies (method calls, attributes, parameters, etc.)
   • Good Value: < 14 classes
   • Application in Project: Monitor dependencies between components to maintain loose coupling

3. Cyclomatic Complexity
   • Description: Measures complexity of code by counting decision points
   • Formula: E - N + 2P (E=edges, N=nodes, P=connected components)
   • Good Value: < 10 per method
   • Application in Project: Identify complex methods needing refactoring

4. Code Coverage
   • Description: Percentage of code executed by tests
   • Formula: (Lines executed / Total lines) * 100
   • Good Value: > 80% coverage
   • Application in Project: Ensure comprehensive test coverage of critical features

5. DIT (Depth of Inheritance Tree)
   • Description: Measures inheritance levels in class hierarchy
   • Formula: Count levels from class to root of inheritance tree
   • Good Value: < 6 levels
   • Application in Project: Keep inheritance hierarchies manageable and avoid deep nesting

Các Metrics phổ biến

Tips làm bài

1. Chọn metrics phù hợp
   • Metrics đo cohesion
   • Metrics đo coupling
   • Chọn thêm metrics đo các khía cạnh khác
2. Mô tả chi tiết
   • Giải thích rõ metric đo gì
   • Nêu công thức/cách tính cụ thể
   • Chỉ ra giá trị tốt là bao nhiêu
3. Liên hệ với dự án
   • Giải thích cách áp dụng vào dự án
   • Nêu lợi ích khi sử dụng metric
   • Đề xuất công cụ đo nếu có

Câu 6: Story Mapping (2.5đ)

Story Mapping là gì?

Story Mapping là một kỹ thuật trực quan để:

• Tổ chức và sắp xếp user stories theo luồng người dùng
• Hiểu được bức tranh tổng thể của sản phẩm
• Lập kế hoạch phát triển và releases

Cấu trúc của Story Map:

• Trục ngang (Activities): Các hoạt động chính của người dùng theo thứ tự thời gian
• Trục dọc (Tasks & Stories):
  • Hàng trên: User tasks chi tiết cho mỗi activity
  • Hàng dưới: User stories được sắp xếp theo độ ưu tiên

Lợi ích của Story Mapping:

• Giúp team hiểu rõ luồng người dùng
• Dễ dàng xác định độ ưu tiên và phân chia releases
• Tạo cái nhìn tổng quan về scope của dự án
• Hỗ trợ giao tiếp giữa các bên liên quan

Cấu trúc trình bày Story Map trên EOS

Story Map được chia làm 2 phần chính:

1. Phần A - Activities and User tasks:
   • Liệt kê các hoạt động chính (Activities)
   • Dưới mỗi Activity là các User tasks cụ thể
   • Đánh số theo cấp: 1, 1.1, 1.2, etc.
2. Phần B - Releases:
   • Chia các User stories theo từng đợt release
   • Mỗi story phải map với task cụ thể
   • Đánh số 3 cấp: 1.1.1, 1.1.2, etc.

Ví dụ Story Map cho "Train Schedule Management"

A. Activities and User tasks
1. Create Train Schedule
   1.1 Input Basic Schedule Information
   1.2 Set Route Details
   1.3 Assign Resources
   1.4 Validate Schedule

2. Update Train Schedule
   2.1 Modify Existing Schedule
   2.2 Handle Schedule Conflicts
   2.3 Notify Affected Parties
   2.4 Update Related Systems

B. Releases
Release 1 (Core Functionality)
1.1.1 As a scheduler, I want to input train departure times
1.1.2 As a scheduler, I want to input train arrival times
1.2.1 As a scheduler, I want to define train stops
2.1.1 As a scheduler, I want to modify schedule times
2.1.2 As a scheduler, I want to update route information

Release 2 (Advanced Features)
1.3.1 As a scheduler, I want to assign train staff
1.4.1 As a scheduler, I want to check schedule conflicts
2.2.1 As a scheduler, I want to resolve timing conflicts
2.3.1 As a scheduler, I want to send update notifications
                    

Tips làm Story Map hiệu quả

1. Cách xác định Activities

• Bắt đầu từ người dùng:
  • Liệt kê các hành động chính của user
  • VD: Đăng ký, Quản lý profile, Đặt hàng...
• Sắp xếp theo trình tự:
  • Từ trái sang phải theo thứ tự thực hiện
  • VD: Đăng ký → Đăng nhập → Xem sản phẩm → Đặt hàng
• Đặt tên Activity:
  • Dùng động từ + danh từ
  • VD: "Manage Account", "Process Order"

2. Cách chia User Tasks

• Phân tích từng Activity:
  • Chia nhỏ thành các task cụ thể
  • VD: Activity "Manage Account":
    - Update Profile
    - Change Password
    - Manage Settings
• Đánh số task:
  • Dùng số thập phân: 1.1, 1.2, 1.3...
  • Theo thứ tự ưu tiên từ trên xuống

3. Cách phân chia Releases

• Release 1 (MVP):
  • Chọn các chức năng cốt lõi nhất
  • Đảm bảo sản phẩm có thể hoạt động cơ bản
  • VD: Đăng ký, đăng nhập cơ bản
• Release 2+:
  • Thêm tính năng nâng cao
  • Cải thiện trải nghiệm người dùng
  • VD: Tích hợp mạng xã hội, features nâng cao

Lỗi thường gặp

• Sai cấu trúc đánh số
  • Activities phải bắt đầu từ 1, 2, 3...
  • Tasks phải có số thập phân (1.1, 1.2...)
  • User stories phải có 3 cấp số (1.1.1, 1.1.2...)
• Thiếu logic trong phân chia
  • Activities không liên quan
  • Tasks không thuộc về activity
  • Stories không map với tasks
• Sai format user stories
  • Thiếu cấu trúc As a/I want/So that
  • Stories không cụ thể
  • Không đáp ứng INVEST — hay gặp nhất ở đây là vi phạm chữ Small: story to bằng cả một epic, không xong trong một sprint

Tiêu chí chấm điểm

Tổng kết và Tips chung

Quản lý thời gian

• Câu 1: 20 phút
• Câu 2: 10 phút
• Câu 3: 15 phút
• Câu 4: 10 phút
• Câu 5: 10 phút
• Câu 6: 20 phút
• Review: 5 phút

Chiến lược làm bài

• Đọc kỹ coi đề là agile hay waterfall
• Học thuộc sẵn template của chính mình
• Làm theo thứ tự câu 1 tới 6. Câu 5 (Quality Metrics) chỉ tốn khoảng 10 phút học thuộc mà được 1.0đ — nên làm, đừng bỏ

Lưu ý quan trọng

• Đọc kỹ yêu cầu từng câu
• Trình bày rõ ràng, có cấu trúc
• Viết tiếng Anh cẩn thận. Bài viết sai ngữ pháp nhiều thì người chấm sẽ trừ điểm, kể cả khi nội dung đúng — nên dùng câu ngắn, đúng, thay vì câu dài mà sai

Đề mẫu:

Đề PE kỳ FA24 dưới đây là đề mình đã làm. Bối cảnh: một Cruise Control System (CCS) cho xe hơi — hệ thống an toàn quan trọng, yêu cầu đã khá rõ, thời hạn 7 tháng cho bản đầu và 12 tháng cho bản cuối, team có kỹ năng kỹ thuật tốt và phân vai rõ. Sáu câu hỏi lần lượt là: chọn mô hình phát triển (2đ), testing levels và ai chịu trách nhiệm (1đ), yêu cầu chức năng và phi chức năng (2đ), viết user story (1.5đ), quality metrics (1đ), story mapping (2.5đ) — tổng 10đ.

Đề mỗi kỳ đổi bối cảnh (đổi hệ thống, đổi thời hạn, đổi đặc điểm team) nhưng giữ nguyên dạng câu hỏi. Vì vậy đừng học thuộc đáp án cho CCS — hãy học cách đọc bối cảnh rồi lắp vào template.

Xem đề thi

Đáp án tham khảo:

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

I agree with the suggestion to use the Unified Process (UP) for this project for the following reasons:

a) Requirements:

• Stable core, evolving detail: The safety rules of a Cruise Control System (CCS) are fixed and known from the start, but the detailed behaviour at the edges — how the system reacts when the driver brakes, when the road is steep, when a sensor fails — is refined as the team learns. UP fits this shape: it locks the architecture early in the Elaboration phase, then develops the details across iterations.
• Risk management: UP is risk-driven. It requires the highest-risk items to be addressed in the earliest iterations. In a safety-critical system, where a failure can injure the driver, this ordering matters more than delivery speed.
• Use case-driven: UP builds the system around use cases, which models the driver–system interaction directly. Each use case also becomes a traceable link from requirement to design to test — necessary evidence for an automotive safety audit.

b) Development Team:

• Team specialisation: The team has specialised technical roles. UP defines explicit roles and work products, so specialised members know exactly what they own.
• Phased development: UP's four phases — Inception, Elaboration, Construction and Transition — map onto the project timeline. Because each phase contains several iterations, the team can deliver a working first version at month 7 and continue to the final release at month 12 without restarting the process.
• Architecture-centric: The CCS needs a solid, verified architecture before feature work begins, because an architectural mistake in a safety-critical system is very expensive to correct later. UP produces an executable architecture baseline at the end of Elaboration, exactly for this reason.

Conclusion: The Unified Process is the most suitable model for this project because it is risk-driven, architecture-centric and use-case-driven, while its iterations still allow the detailed requirements to be refined as the team learns more about the system.

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

1. Unit Testing:
   • Role: Developers
   • Purpose: It makes sure that small pieces of code, like functions or methods, work as expected.
2. Integration Testing:
   • Role: Developers
   • Purpose: It ensures that different parts of the system work well together.
3. System Testing:
   • Role: QA Testers
   • Purpose: It tests the whole system to see if it works properly
4. Acceptance Testing:
   • Role: QA Testers and End Users
   • Purpose: It checks if the system meets the customer's requirements and is ready for use.
5. Regression Testing:
   • Role: QA Testers
   • Purpose: Checks that new changes haven't broken anything that was working before.
6. Performance Testing:
   • Role: Performance testers
   • Purpose: Ensures the system performs under load conditions.

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

Functional Requirements:

• The system should allow the driver to set a speed within a safe range (eg 30 - 120 km/h).
• The system should automatically adjust speed to keep a safe distance from the car ahead.
• The driver should be able to cancel cruise control anytime using the brake pedal or a dedicated button.
• The system should show the driver the current status (eg Cruise Control Active).
• The system should turn off automatically when certain conditions are met (eg brake press, system malfunction).

Performance Requirements:

• The system must respond quickly to changes in speed and distance, with no delay.
• The system should perform well under different driving speeds, loads, and sensor inputs.
• The system should use resources efficiently (eg processor and memory), ensuring that safety-critical processes are prioritized.

Usability Requirements:

• The system should support multiple languages and have an easy-to-use interface.
• The system should be user-friendly, allowing the driver to operate it with minimal distraction.

Câu 4: User Stories

• 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
• 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.
• 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.
• As a driver, I want the system to provide visual feedback so that I can always know the system's status while driving
• 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: Phân loại mô hình — Predictive và Adaptive

Predictive Models (kế hoạch cố định trước):

• Waterfall Model: This is a step-by-step approach where each phase (planning, design, development, etc.) must be completed before moving to the next. It works best when the project's requirements are clear and unlikely to change.
• V-Model: This model follows the same sequence as Waterfall, but every development phase is paired with the test level that verifies it, and the test plans are written during that development phase instead of at the end.

Adaptive Models (kế hoạch điều chỉnh theo phản hồi):

• Scrum: The team works in sprints (fixed periods of 1–4 weeks, usually 2 weeks) to deliver a usable increment, and the customer gives feedback at the end of each sprint through the Sprint Review.
• Extreme Programming (XP): An adaptive model built around engineering practices — test-driven development, pair programming, continuous integration and refactoring — so that changing the code late in the project stays cheap and safe.
• Lean Software Development: This model focuses on delivering value to the customer by eliminating waste and making small, continuous improvements to the process. Kanban is the most common way of applying it.

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

A. Activities and User Tasks

1. Set Speed
   1. Set Speed Range
   2. Adjust Speed
2. Maintain Safe Distance
   1. Detect Vehicle in Front
   2. Adjust Distance
3. Cancel Cruise Control
   1. Manual Cancel
   2. Automatic Cancel

Release 1

• 1.1.1 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 FE SWE201c

Từ vựng quan trọng

Thuật ngữ cơ bản

• Cohesion: mức độ các phần bên trong một module cùng phục vụ một việc. Cao là tốt.
• Decomposability: khả năng chia hệ thống thành các module nhỏ độc lập — phân rã, không phải "phân hủy".
• Loose coupling: các module ít phụ thuộc vào nhau. Tiếng Việt "lỏng lẻo" nghe như khuyết điểm, nhưng đây là điều tốt: sửa module này không phải sửa module kia.
• Confidentiality: chỉ người có quyền mới đọc được dữ liệu (một trong ba trụ C-I-A).
• Integrity: dữ liệu không bị sửa đổi trái phép hoặc sai lệch.
• Cutover strategy: cách chuyển từ hệ thống cũ sang hệ thống mới (chuyển một lần, chạy song song, hay chuyển từng phần).
• Failover: tự động chuyển sang hệ thống dự phòng khi hệ thống chính chết.
• Standby: hệ thống dự phòng đang ở trạng thái chờ, sẵn sàng nhận việc khi failover xảy ra.
• Capacity: lượng tải mà hệ thống phục vụ được (số user, số giao dịch mỗi giây) — không phải "công suất" theo nghĩa điện.
• Truncated: bị cắt bớt phần cuối — thường nói về dữ liệu dài hơn ô chứa nên mất phần dư.

Thuật ngữ nâng cao

• Agile mindset: tư duy Agile — ưu tiên phản hồi sớm và thích ứng với thay đổi. Agile là tên riêng, đừng dịch thành "nhanh nhẹn".
• Specification: bản đặc tả — mô tả hệ thống phải làm gì, không chỉ là thông số kỹ thuật.
• Implement: hiện thực hóa bằng code (giai đoạn viết code), phân biệt với deploy = đưa lên môi trường thật.
• Coincidental (cohesion): mức cohesion thấp nhất — các phần bị nhét chung một module mà không có liên hệ gì, kiểu file Utils.java.
• Iterative: làm nhiều vòng, mỗi vòng làm tốt hơn cái đã có.
• Incremental: làm nhiều vòng, mỗi vòng thêm phần mới vào cái đã có.
• Fidelity: mức giống-thật của prototype. Low-fidelity là bản vẽ tay hoặc wireframe; high-fidelity là bản gần như sản phẩm thật.
• Sprint: khoảng thời gian có độ dài cố định (1–4 tuần) mà Scrum team hoàn thành một increment. Điểm cốt lõi là độ dài không đổi.
• Estimate: ước lượng công sức, thường bằng story point chứ không bằng giờ.
• Refactoring: sửa cấu trúc code cho gọn hơn mà không thay đổi hành vi bên ngoài. Nếu hành vi đổi thì đó không còn là refactoring.

Tổng hợp lý thuyết quan trọng

Agile & Scrum

• Agile: Phương pháp quản lý dự án linh hoạt
• Velocity: Thước đo lượng công việc hoàn thành trong sprint
• Scrum Events: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
• Scrum Artifacts: Product Backlog, Sprint Backlog, Increment

Kiểm thử & Bảo mật

• Black Box Testing: Kiểm tra chức năng không quan tâm cấu trúc bên trong
• White Box Testing: Kiểm tra cấu trúc và luồng xử lý mã nguồn
• CIA Triad: Confidentiality (Bảo mật), Integrity (Toàn vẹn), Availability (Khả dụng)

Nguyên lý SOLID & Design Patterns

• OCP: Open for extension, closed for modification
• DIP: High-level modules shouldn't depend on low-level modules
• Observer Pattern: Quản lý quan hệ phụ thuộc một-nhiều
• Strategy Pattern: Đóng gói thuật toán có thể thay thế

Từ vựng bổ sung

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

Chuỗi nhân quả đầy đủ có bốn mắt, và đề FE hay hỏi đúng mắt đầu tiên — cái thường bị bỏ sót:

• Error (mistake): hành động sai của con người — lập trình viên hiểu sai yêu cầu, hoặc gõ sai. Đây là nguyên nhân, nằm trong đầu người, không nằm trong code.
• Fault / Defect / Bug: kết quả của error nằm lại trong mã nguồn hoặc tài liệu. Tồn tại kể cả khi chương trình không chạy.
• Failure: hành vi sai lệch quan sát được khi chạy — chỉ xảy ra khi luồng thực thi đi qua đúng chỗ có fault, với đúng dữ liệu làm nó bộc lộ.
• Latent và Effective error: hai trạng thái của cùng một fault — latent là fault chưa được kích hoạt lần nào, effective là fault đã bị kích hoạt và gây failure.

Nhớ theo một câu: người gây error → error để lại fault trong code → fault khi bị chạy tới thì gây failure. Hệ quả trực tiếp: một fault có thể tồn tại nhiều năm mà không có failure nào, nên "chưa thấy lỗi" không đồng nghĩa "không có lỗi" — đúng nguyên tắc Absence of Error fallacy ở mục 3.

Agile Manifesto

Bốn giá trị, mỗi giá trị có dạng "A hơn B":

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Prototyping Methods

• Throwaway (Rapid) Prototyping: dựng mẫu thật nhanh chỉ để chốt yêu cầu, rồi bỏ đi và viết lại sản phẩm thật cho tử tế. Mẫu này không cần code sạch vì nó không sống sót.
• Evolutionary Prototyping: mẫu ban đầu được giữ lại và bồi dần thành sản phẩm cuối. Vì vậy phải viết cẩn thận ngay từ bản mock đầu tiên.

← Quay lại danh sách bài viết