I) Development methodology -

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

Phương pháp phát triển phần mềm, hay còn gọi là phương pháp luận phát triển phần
mềm, bao gồm các quy trình, kỹ thuật, và công cụ được sử dụng trong quá trình phát
triển các hệ thống phần mềm. Có nhiều phương pháp phát triển phần mềm khác
nhau, mỗi phương pháp có những đặc điểm, ưu và nhược điểm riêng. Dưới đây là
một số phương pháp phát triển phần mềm phổ biến:

1. Phương pháp nước rơi (Waterfall): Là phương pháp truyền thống nhất, trong
đó quá trình phát triển được chia thành các giai đoạn tuyến tính và tuần tự, bắt đầu
từ việc thu thập yêu cầu và kết thúc bằng việc bảo trì hệ thống. Mỗi giai đoạn phải
được hoàn thành trước khi giai đoạn tiếp theo bắt đầu.

2. Phương pháp phát triển linh hoạt (Agile): Agile tập trung vào việc phát triển
liên tục và đáp ứng nhanh chóng trước sự thay đổi. Phương pháp này nhấn mạnh vào
sự hợp tác giữa các bên liên quan, phát triển lặp đi lặp lại và thường xuyên cập nhật
sản phẩm dựa trên phản hồi từ người dùng.

3. Phương pháp phát triển theo vòng đời xoắn ốc (Spiral): Kết hợp các yếu tố của cả
phương pháp nước rơi và phát triển linh hoạt, xoắn ốc là một mô hình lặp đi lặp lại
trong đó mỗi vòng lặp là một dự án phần mềm nhỏ, cho phép việc đánh giá rủi ro và
phản hồi người dùng sớm và thường xuyên.

4. Phương pháp Phát triển Phần mềm Nhanh (Rapid Application Development
- RAD): RAD tập trung vào việc nhanh chóng tạo ra các phiên bản ban đầu của phần
mềm để thử nghiệm và lấy phản hồi. Điều này thường được thực hiện thông qua việc
sử dụng công cụ phát triển phần mềm tự động hóa và kỹ thuật lập trình linh hoạt.

5. Phương pháp Lean: Lấy cảm hứng từ sản xuất tinh gọn, phương pháp Lean trong
phát triển phần mềm tập trung vào việc giảm thiểu lãng phí và tối đa hóa giá trị sản
phẩm cho khách hàng. Điều này đạt được thông qua việc liên tục đánh giá dự án và
loại bỏ các yếu tố không cần thiết.

6. Phương pháp DevOps: Mặc dù không phải là một phương pháp phát triển phần
mềm theo nghĩa truyền thống, DevOps tập trung vào việc cải thiện sự hợp tác giữa
các nhóm phát triển và vận hành để đạt được việc triển khai phần mềm nhanh chóng
và liên tục.
Mỗi phương pháp phát triển phần mềm có những điểm mạnh và hạn chế riêng, và sự
lựa chọn giữa chúng thường dựa trên mục tiêu cụ thể của dự án, yêu cầu về thời gian,
ngân sách, và khả năng đáp ứng sự thay đổi của dự án.

*) Phương pháp Waterfall

Phương pháp Waterfall, hay Mô hình Nước Rơi, là một trong những phương pháp luận
phát triển phần mềm truyền thống nhất. Nó dựa trên việc hoàn thành các giai đoạn
của dự án một cách tuần tự, nơi mỗi giai đoạn phải được hoàn thành trước khi bước
sang giai đoạn tiếp theo. Các giai đoạn chính thường bao gồm:

1. Phân tích và Thu thập Yêu cầu: Xác định yêu cầu của người dùng và dự án.
2. Thiết kế Hệ thống và Phần mềm: Tạo ra thiết kế tổng thể và chi tiết cho hệ
thống.
3. Triển khai và Lập trình: Thực hiện việc viết mã dựa trên thiết kế đã được xác
định.
4. Kiểm thử: Kiểm tra và tìm kiếm lỗi trong phần mềm.
5. Triển khai: Cài đặt phần mềm tại môi trường hoạt động của người dùng.
6. Bảo trì: Sửa chữa và cập nhật phần mềm sau khi đã được triển khai.

Ưu điểm:

● Dễ hiểu và áp dụng đối với quản lý dự án do cấu trúc tuần tự rõ ràng.

● Tốt cho các dự án với yêu cầu rõ ràng từ đầu và ít có khả năng thay đổi trong
quá trình phát triển.
Nhược điểm:

● Không linh hoạt để đáp ứng sự thay đổi trong yêu cầu.
● Rủi ro và vấn đề có thể không được phát hiện cho đến giai đoạn kiểm thử.
● Có thể dẫn đến sự lãng phí nếu dự án phải điều chỉnh đáng kể.

*) Phương pháp Agile

Phương pháp Agile là một tập hợp các nguyên tắc và phương pháp luận dựa trên việc
phát triển phần mềm thông qua sự hợp tác liên tục và phản hồi từ người dùng. Nó
tập trung vào việc phát triển sản phẩm thông qua các lần lặp ngắn gọi là sprint, mỗi
sprint thường kéo dài từ một đến bốn tuần. Các nguyên tắc chính của Agile bao gồm:

● Ưu tiên khách hàng và sự hài lòng thông qua giao hàng sớm và liên tục.
● Chấp nhận sự thay đổi yêu cầu, ngay cả ở giai đoạn muộn của dự án.
● Giao hàng thường xuyên của phần mềm hoạt động.
● Sự hợp tác chặt chẽ giữa các bên liên quan và nhóm phát triển.
● Hỗ trợ, tin tưởng, và khuyến khích nhóm làm việc tự quản.

Ưu điểm:

● Linh hoạt và thích ứng tốt với sự thay đổi.

● Tạo điều kiện cho sự hợp tác và giao tiếp tốt hơn giữa các bên liên quan.
● Phản hồi nhanh từ người dùng giúp định hình và cải thiện sản phẩm dựa trên
nhu cầu thực tế.

Nhược điểm:

● Yêu cầu sự cam kết và hợp tác cao từ phía khách hàng.
 ● Có thể khó quản lý nếu phạm vi công việc không được xác định rõ ràng từ
đầu.
● Đôi khi có thể dẫn đến việc thiếu tập trung vào việc lập kế hoạch dài hạn do
tập trung vào giao hàng ngắn hạn.

Agile không phải là một phương pháp cụ thể mà là một tập hợp các nguyên tắc có
thể được áp dụng thông qua nhiều phương pháp luận khác nhau như Scrum, Kanban,
Extreme Programming (XP), và nhiều hơn nữa. Sự chọn lựa giữa Waterfall và Agile
phụ thuộc vào đặc thù của dự án và môi trường làm việc.
Phương pháp luận Scrum

Scrum là một trong những khung công tác Agile phổ biến nhất, được thiết kế để tạo

ra môi trường phát triển sản phẩm linh hoạt và phản hồi nhanh. Scrum tập trung vào

việc quản lý và kiểm soát công việc trong một môi trường động.

Các thành phần chính của Scrum:

● Sprint: Các chu kỳ làm việc cố định, thường kéo dài từ 1 đến 4 tuần, trong đó
nhóm đặt mục tiêu hoàn thành một tập hợp công việc cụ thể.
● Scrum Master: Người hỗ trợ nhóm, giúp nhóm áp dụng đúng phương pháp
Scrum, loại bỏ các rào cản và tạo điều kiện cho nhóm làm việc hiệu quả.
● Product Owner: Đại diện cho người dùng cuối và các bên liên quan khác, đảm
bảo rằng dự án đang di chuyển theo đúng hướng và rằng sản phẩm cuối cùng
đáp ứng nhu cầu của họ.
● Backlog Sản phẩm: Danh sách tất cả công việc cần được thực hiện, được ưu
tiên bởi Product Owner.
● Sprint Backlog: Phần của backlog sản phẩm được chọn để làm việc trong
sprint hiện tại, cùng với kế hoạch cho việc phân phối sản phẩm.
● Daily Scrum (Stand-up): Cuộc họp hàng ngày nơi thành viên nhóm cập nhật về
tiến độ và rào cản.
● Sprint Review và Sprint Retrospective: Cuộc họp diễn ra cuối mỗi sprint để
đánh giá công việc đã hoàn thành và lên kế hoạch cải thiện cho sprint tiếp
theo.

Ưu điểm:

● Tăng cường giao tiếp và hợp tác.

● Phản hồi nhanh từ người dùng.
● Linh hoạt trước sự thay đổi.

Nhược điểm:

● Yêu cầu cam kết cao từ tất cả các bên.

 ● Có thể khó áp dụng trong các dự án với yêu cầu cứng nhắc hoặc quy mô lớn.

Phương pháp luận Kanban

Phương pháp luận Kanban, vốn có nguồn gốc từ hệ thống sản xuất tinh gọn của
Toyota ở Nhật Bản, là một hệ thống nhằm tối ưu hóa dòng công việc và quản lý dự
án. Kanban được thiết kế để giúp các tổ chức cải thiện hiệu suất làm việc thông qua
việc giảm thiểu lãng phí và tăng cường khả năng hiển thị của quy trình làm việc. Dưới
đây là những nguyên tắc cơ bản và cách thức hoạt động của phương pháp luận
Kanban:

Nguyên Tắc Cơ Bản

1. Hiển Thị Công Việc: Kanban sử dụng một bảng Kanban (thường là một bảng

vật lý hoặc số) để hiển thị tất cả các công việc hiện tại ở các giai đoạn khác

nhau của quy trình. Mỗi công việc được biểu diễn bằng một thẻ hoặc "card" di

chuyển qua các cột trên bảng, tương ứng với từng giai đoạn của quy trình.

2. Giới Hạn Công Việc Đang Thực Hiện (WIP): Để tránh tình trạng quá tải và cải

thiện tốc độ hoàn thành công việc, Kanban đặt giới hạn cho số lượng công

việc đang thực hiện tại mỗi giai đoạn của quy trình.

3. Quản Lý Dòng Công Việc: Bằng cách theo dõi sự di chuyển của công việc qua

các giai đoạn, Kanban giúp nhận diện các điểm nghẽn và cơ hội để cải thiện

dòng công việc.

4. Cải Tiến Liên Tục: Mục tiêu cuối cùng của Kanban là cải thiện liên tục quy

trình làm việc thông qua việc đánh giá và điều chỉnh dựa trên hiệu suất thực tế

và phản hồi.

Cách Thức Hoạt Động

● Bảng Kanban: Một công cụ trực quan chia làm nhiều cột, mỗi cột tượng trưng

cho một phần của quy trình làm việc (ví dụ: Đang Chờ, Đang Thực Hiện, Hoàn
 Thành). Công việc được chia thành các thẻ và được di chuyển qua bảng theo

tiến độ.

● Thẻ (Card): Mỗi thẻ trên bảng Kanban tượng trưng cho một công việc hoặc

nhiệm vụ cụ thể, bao gồm thông tin chi tiết như mô tả công việc, người phụ

trách, thời hạn, và mọi yếu tố liên quan khác.

● Luồng Công Việc (Workflow): Được xác định rõ ràng thông qua bảng Kanban,

giúp mọi người trong nhóm hiểu rõ công việc nào cần được thực hiện, bởi ai,

và ở giai đoạn nào.

● Cuộc Họp Đánh Giá Dòng Công Việc: Định kỳ, nhóm sẽ tổ chức các cuộc họp

để đánh giá dòng công việc, xác định các điểm nghẽn và thảo luận về cách cải

thiện quy trình.

Ưu Điểm
● Tăng Khả Năng Hiển Thị: Mọi người có thể dễ dàng nhìn thấy tất cả công việc

đang được thực hiện và ở giai đoạn nào.

● Cải Thiện Dòng Công Việc: Giúp nhận diện và giảm thiểu các điểm nghẽn.

● Tối Ưu Hóa Hiệu Suất: Bằng cách giới hạn WIP, Kanban giúp giảm thời gian

hoàn thành công việc và tăng hiệu suất làm việc.

● Cải Tiến Liên Tục: Khuyến khích sự cải thiện không ngừng trong quy trình làm

việc.

Kanban là một công cụ linh hoạt và mạnh mẽ, có thể được áp dụng cho mọi loại

nhóm và dự án, từ phát triển phần mềm đến quản lý nhiệm vụ hàng ngày.

"What type and level/stage of testing would you suggest the team do? Who will do
test in each test level/stage?"
II) Testing Types and Levels:
Types of Testing:

● Unit Testing: Individual components or pieces of code are tested to ensure

each function works properly in isolation.
● Integration Testing: Different modules or services are tested together to
ensure they work properly in conjunction.
● System Testing: The complete system is tested to verify that it meets all
specifications and requirements.
● Acceptance Testing: The system is tested for acceptability to ensure it is
ready for delivery.

Levels of Testing:

● Component Level Testing (CLT): Testing of individual software components.

● Integration Level Testing (ILT): Testing the integration of components to
create interconnected systems.
● System Level Testing (SLT): Testing the system as a whole to ensure it meets
quality standards and system requirements.
● User Acceptance Testing (UAT): Final testing phase where the user tests the
system to verify it meets their needs.

Suggesting Testing Stages for SBMS:

Unit Testing:
● Who Does It: Developers
● When: After small pieces of code are written.
● Focus: Functionality of individual methods and classes.
Integration Testing:
● Who Does It: Developers or a specialized integration test team.
● When: After multiple units of code have been combined.
● Focus: Data flow between modules and combined functionality.
System Testing:
● Who Does It: Quality Assurance (QA) team.
● When: Once the entire software is considered feature-complete.
● Focus: Overall behavior of the system and compliance with
requirements.
User Acceptance Testing (UAT):
● Who Does It: Actual users, stakeholders, or client representatives.
● When: Before the software is released into the production environment.
● Focus: The software’s ability to satisfy user needs and business
objectives.

Q3.
Understanding Functional and Non-Functional
Requirements:

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

1. Mô tả cụ thể hành vi: Yêu cầu chức năng thường được mô tả qua các hành vi
cụ thể của hệ thống, ví dụ như việc nhập dữ liệu, xử lý và sinh kết quả.
2. Dựa trên nghiệp vụ: Chúng liên quan trực tiếp đến các quy trình kinh doanh và
quy trình làm việc mà hệ thống hỗ trợ.
3. Có thể kiểm tra được: Bạn có thể dễ dàng kiểm tra chúng thông qua các ca
kiểm thử, để xác minh hệ thống có thực hiện đúng yêu cầu hay không.

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

1. Liên quan đến chất lượng: Non-functional requirements thường mô tả chất
lượng của hệ thống, bao gồm hiệu suất, độ tin cậy, khả năng mở rộng, bảo
mật, và giao diện người dùng.
2. Áp dụng rộng rãi: Chúng không chỉ áp dụng cho một tính năng cụ thể mà
thường ảnh hưởng đến toàn bộ hệ thống hoặc các mô-đun lớn.
3. Khó kiểm tra hơn: Việc kiểm tra non-functional requirements thường phức tạp
hơn và đôi khi yêu cầu các công cụ và kỹ thuật đặc biệt.

Note:

1. Có các tiêu đề rõ ràng của phần cho các yêu cầu chức năng và phi chức năng.
2. Liệt kê từng yêu cầu theo định dạng ngắn gọn, có dấu đầu dòng.
3. Bắt đầu mỗi yêu cầu chức năng bằng một động từ hành động, chẳng hạn như
"shall allow," "shall enable," "shall provide", v.v., để cho biết hệ thống dự kiến
sẽ làm gì.
4. Mô tả các yêu cầu phi chức năng với các chi tiết cụ thể như số liệu định lượng
hoặc kỳ vọng chính xác có thể đo lường được.

Q5.

Functional Test Cases:

Functional Test Cases: These are specific tests of the functions of the system, which
can be automated or carried out manually. They're designed to input certain
conditions and check for the expected outcomes.

When writing a functional test case, you need to include:

1. Test Case ID: A unique identifier for the test case.

 2. Test Description: A brief description of what is being tested.
3. Pre-conditions: Any pre-existing conditions that must be met before the test
can be executed.
4. Test Steps: Step-by-step instructions on how to perform the test.
5. Test Data: Any data needed to perform the test.
6. Expected Result: The expected outcome of the test if the feature works
correctly.
7. Actual Result: The actual outcome of the test (filled out during test execution).
8. Status: The final status of the test (e.g., Pass, Fail, Blocked) after execution.
9. Remarks: Any additional information or observations about the test

Q6.

User Stories are a way to describe features from the perspective of the end user.
They are a tool used in Agile development to capture a description of a software
feature from an end-user perspective. A user story describes the type of user, what
they want, and why. This helps to create a simplified description of a requirement.

User stories are often written in this format:

● As a [role], I want [feature] so that [reason/benefit].

Here's what each part means:

● [Role] - Who is the user or customer of this feature?

● [Feature] - What is the feature or action they want to perform?
● [Reason/Benefit] - Why do they want this feature? What benefit does it
provide?

Acceptance Criteria:
Criteria 1 (Actionable & Testable condition)
Criteria 2 (Another condition)
...
Criteria N (Final condition)

Viết câu chuyện người dùng hiệu quả:

1. Cụ thể và ngắn gọn: Câu chuyện của người dùng phải đơn giản và xác định rõ
ràng người dùng cần gì và tại sao.
2. Tập trung vào người dùng: Luôn viết câu chuyện từ góc nhìn của người
dùng, nhấn mạnh nhu cầu và lợi ích của người dùng.
3. Tránh dùng thuật ngữ kỹ thuật: Câu chuyện của người dùng phải dễ hiểu đối
với tất cả các bên liên quan, kể cả những thành viên nhóm không chuyên về kỹ
thuật.
4. Bao gồm các tiêu chí chấp nhận: Xác định điều gì phải đúng để câu chuyện
được coi là "hoàn thành". Điều này giúp làm rõ phạm vi của câu chuyện và hỗ
trợ thử nghiệm.
5. Ưu tiên tương tác hơn chức năng: Làm nổi bật những gì người dùng muốn đạt
được thay vì chỉ tập trung vào chức năng hệ thống.
6. Cộng tác và tinh chỉnh: Câu chuyện của người dùng phải được tinh chỉnh và
làm rõ với ý kiến đóng góp của nhóm phát triển, các bên liên quan và người
dùng để đảm bảo chúng phản ánh chính xác nhu cầu của người dùng.