WAY TO ENTERPRISE
Lesson 1
Quy trình phát triển phần mềm
Agenda
I. Quy trình phát triển phần mềm
II. Các giai đoạn phát triển phần mềm
III. Vai trò của BA trong phát triển phần mềm
Giới thiệu
I. Quy trình phát triển phần mềm
Quy trình phát triển phần mềm là đưa những yêu cầu của khách hàng thành một ứng dụng/hệ thống phần mềm hoàn chỉnh một cách nhanh nhất, tốt nhất.
Yêu cầu khách
hàng
Ứng dụng/Hệ
thống Quy trình phát triển phần mềm
Mô hình phát triển phần mềm
I. Quy trình phát triển phần mềm
Quy trình phần mềm giúp trả lời những câu hỏi:
- Nhân sự: Ai sẽ làm? Ai làm việc gì?
- Thời gian: Khi nào bắt đầu? Mất bao lâu để hoàn thành?
- Phương thức: Làm thế nào?
- Công cụ: Cần sử dụng những công cụ gì để hoàn thành công việc?
- Chi phí: Chi phí bỏ ra là bao nhiêu và thu về được bao nhiêu?
- Mục tiêu: Mục tiêu hướng đến là gì?
Những yêu cầu khác nhau thì có thể có những quy trình phát triển khác nhau.
II. Các giai đoạn phát triển phần mềm
II.I Phân tích Requirement
Phân tích Requirement:
Là quá trình xác định mong muốn của người dùng đối với ứng dụng, liên quan đến tất cả các nhiệm vụ được thực hiện để xác định nhu cầu của các bên liên quan.
Các công việc chính của phân tích requirements bao gồm:
- Phân tích - Lập tài liệu
- Xác định và quản lý các requirements của phần mềm hoặc hệ thống.
Định nghĩa Requirement:
Là tất cả yêu cầu của khách hàng khi họ nói ra.
II.I Phân tích Requirement
Ví dụ về Requirement:
Một người đến cửa hàng điện thoại và bảo người bán hàng “Tôi muốn mua Iphone 13 mới nhất với giá 13 triệu”
🡺 Hãy phân tích Requirement của khách hàng?
II.II Các loại Requirement
1. Business Requirement: là những yêu cầu rất high-level từ phía khách hàng ( thường là các mục tiêu dài hạn, áp dụng cho toàn tổ chức).
2. Stakeholder Requirement: là những yêu cầu cụ thể của từng Stakeholder. Những yêu cầu này phải thể hiện được cái need-nhu cầu cụ thể của các Stakeholder.
3. Solution Requirement: là những yêu cầu về khả năng và tiêu chuẩn mà giải pháp phải có để đạt đc Business Requirement và Stakeholder Requirement. Gồm 2 loại:
- Functional Requirement (what the system do?): là những thứ mà hệ thống có thể làm
- Non-Functional Requirement (how the system work?): là những thứ không liên quan chức năng nhưng giúp hệ thống chạy tốt và đảm bảo được chất lượng.
4. Transition Requirement: là những yêu cầu của khách hàng liên quan tới việc áp dụng các giải pháp vào tổ chức như thế nào cho hiệu quả
Ví dụ các loại Requirement
1. Business Requirement: Giám đốc một công ty bán hàng đưa ra yêu cầu mong muốn
“tăng 10% tỉ lệ khách hàng quay lại mua hàng”
2. Stakeholder Requirement: là Sales team phải:
+ Biết được thông tin khách hàng => Hệ thống phải quản lý được thông tin khách hàng.
+ Theo dõi được các hoạt động tương tác của khách hàng => Hệ thống phải lưu trữ được các hoạt động tương tác của khách hàng với hệ thống
Ví dụ các loại Requirement
3. Functional Requirement:
+ Xây dựng chức năng Đăng ký thông tin khách hàng => lấy được thông tin khách hàng + Xây dựng chức năng Lưu các hoạt động mua hàng của từng khách hàng => Xây dựng danh sách khách hàng tiềm năng dựa vào những lần mua hàng
+ Xây dựng các chương trình Giảm giá ưu đãi để thu hút khách hàng 4. Non-Functional Requirement:
Hệ thống ko phải chỉ chạy được, mà hệ thống còn phải chạy nhanh, gọn và đẹp, tiện dụng
5. Transition Requirement:
- Ít nhất có 5 buổi đào tạo hệ thống cho Sales team.
- Toàn bộ Scenario phải đáp ứng được toàn bộ nghiệp vụ của công ty và phải được chạy test ít nhất 2 lần trước khi phát hành
II.II Thiết kế (Design)
Thực hiện thiết kế và tổng hợp các tài liệu thiết kế:
- Thiết kế Database - Thiết kế API
- Vẽ Data Flow - Vẽ Mockup - Thiết kế UX/UI
- Thiết kế Business Process Flow - Thiết kế bộ phân quyền hệ thống - Vẽ Solution Architect
……..
Tùy từng quy trình phát triển có thể đưa ra các loại tài liệu khác nhau, và BA có thể ko phải làm tất cả những loại tài liệu này
II.III Lập trình (Coding)
Lập trình viên thực hiện lập trình dựa trên các tài liệu thiết kế.
Đầu ra: Mã nguồn (Source Code)
II.IV Kiểm thử (test)
Công việc của giai đoạn Kiểm thử:
- Test Plan - Testcase - Test report - Test Evidence
II.V Triển khai
Triển khai sản phẩm cho khách hàng.
Đầu ra: Tài liệu hướng dẫn/ training khách hàng.
III Vai trò của BA trong phát triển phần mềm
III Vai trò của BA trong phát triển phần mềm
Các vị trí trong một dự án phần mềm:
Project Manager:
Thiết lập dự án, xác định scope, quản lý tiến độ, resource, chi phí…
Business Analysis:
Phân tích yêu cầu, quản lý yêu cầu…
Techlead:
Xây dựng cấu trúc hệ thống, review code, nghiên cứu công nghệ mới hoặc khó…
Developer:
Coding theo yêu cầu……
Tester (QC):
Viết testcase dựa theo yêu cầu và test……
III.I Vai trò của BA trong phân tích yêu cầu
III.I Vai trò của BA trong phân tích yêu cầu
1. Project Definition
Mục đích của bước này là để BA chúng ta hiểu được project:
- Project này làm gì.
- Khách hàng là ai.
- Lĩnh vực gì.
- Vấn đề của họ ra sao, mục tiêu của họ là gì, scope dự án như thế nào…
Để hiểu được Project chúng ta phải trả lời được các câu hỏi sau:
- Vấn đề khách hàng đang gặp phải là gì? ( Problem to be solved) - Mục tiêu khách hàng muốn là gì? (Business Goal)
- Hiện trạng của khách hàng? (Business Case) - Phạm vi của dự án? (Project scope)
III.I Vai trò của BA trong phân tích yêu cầu
Ví dụ:
Một bác khách hàng đến tìm mình và bảo “ Xây dựng cho tôi hệ thống quản lý phòng học”
Xác định Project Definition:
- Vấn đề khách hàng đang gặp phải là gì? ( Problem to be solved) - Mục tiêu khách hàng muốn là gì? (Business Goal)
- Hiện trạng của khách hàng? (Business Case) - Phạm vi của dự án? (Project scope)
III.I Vai trò của BA trong phân tích yêu cầu
2. Khai thác yêu cầu (Elicitation)
Elicitation là khai thác thông tin từ khách hàng, mọi yêu cầu từ khách hàng thường là không có sẵn mà BA phải biết cách khai thác => để hiểu được mình cần phải làm gì?
Một số phương pháp khai thác yêu cầu:
- Meeting
- Data analysis - Prototyping - Survey
- Document Analysis
….
III.I Vai trò của BA trong phân tích yêu cầu
3. Phân tích (Analysis)
Phân tích đơn giản chỉ là sắp xếp và phân loại các thông tin để BA xác định được:
- Vấn đề thực sự của khách hàng là gì?
- Đâu là những yêu cầu thực tế?
- Đâu là những yêu cầu không thể thực hiện được?
- Những thứ khách hàng thực sự ưu tiên vào thời điểm hiện tại? priority Cách sắp xếp và phân loại thông tin:
- Tổ chức lại yêu cầu - Phân rã yêu cầu
- Đánh độ ưu tiên của yêu cầu - Validate
- Verify
III.I Vai trò của BA trong phân tích yêu cầu
4. Tài liệu (Document)
Bước documentation nghĩa là tài liệu hóa, tức là đem toàn bộ những thứ làm được từ bước trên tổng hợp lại thành tài liệu.
Hai tài liệu phổ biến là SRS hoặc FRD:
SRS: Software Requirement Specification FRD: Functional Requirement Document Để document áp dụng:
- Tận dụng Template có sẵn - Mô hình hóa để Document
III.I Vai trò của BA trong phân tích yêu cầu
5. Verification
Sau khi Document sẽ chuyển cho team verify lại một lần nữa, cụ thể là QC hoặc PM.
Document đã đúng chưa?
Các yêu cầu trong Document đã đầy đủ chưa?
III.I Vai trò của BA trong phân tích yêu cầu
6. Management
Quản lý các Document sau khi hoàn thành.
Nếu có Requirement thay đổi thì phải control việc thay đổi thế nào?
Quản lý Requirement sao cho ko để miss yêu cầu và khi có nhiều thay đổi là một vấn đề không đơn giản.
III.II Vai trò của BA trong thiết kế
III.II Vai trò của BA trong thiết kế
Vai trò BA:
Ở bước design, sẽ can thiệp sâu một chút về kỹ thuật:
- Thiết kế Database - Thiết kế API
- Thiết kế Business Process Flow - Activity Diagram
- State Diagram
…..
Không hẳn là BA sẽ phải làm hết những phần này mà sẽ có sự tham gia của các vị trí khác như Dev, Technical, Architect, hoặc PM……
III.III Vai trò của BA trong develop
III.III Vai trò của BA trong develop
Vai trò BA:
Giai đoạn này BA sẽ hỗ trợ Develop team trong quá trình phát triển sản phẩm.
Ví dụ:
Usecase nào không rõ thì BA sẽ giải thích rõ hơn.
Đến giai đoạn phát triển sẽ phát hiện ra những logic không phù hợp hoặc conflict với nhau thì BA cần phân tích và trao đổi lại với khách hàng.
III.IV Vai trò của BA trong kiểm thử
III.IV Vai trò của BA trong kiểm thử
Vai trò BA:
Trong giai đoạn Kiểm thử thì QC sẽ viết bộ Test case và BA chuẩn bị một tài liệu Requirement Traceability Matrix (RTM)
RTM là một tài liệu mapping Requirement với Testcase.
Mục đích của RTM là để BA check lại xem các Requirement đã được test hay chưa? Và test thành công hay thất bại. RTM sẽ giúp BA control được
Requirement xuyên suốt dự án.
III.V Vai trò của BA trong deploy
III.V Vai trò của BA trong deploy
Vai trò BA:
- Chuẩn bị tài liệu hướng dẫn sử dụng cho khách hàng ( tùy dự án có thể là BA hoặc QC làm công việc này).
- Sau khi chuẩn bị tài liệu Hướng dẫn sử dụng thì sẽ tiến hành Training khách hàng sử dụng hệ thống
III.VI Vai trò của BA trong maintain
III.VI Vai trò của BA trong maintain
Vai trò BA:
- Fix bugs: khi có lỗi phát sinh, khách hàng sẽ gửi lỗi để BA vào phân tích và team fix.
- Log bugs và phân tích bugs: nguyên nhân tại sao, ai là người phát hiện, hiện trạng, thời gian…
- Phân tích để phát triển thêm các tính năng mà khách hàng muốn.
- Nâng cấp version khi có phiên bản update ( thường là sau khi fix bugs)
- Activity sheet: quản lý hoạt động giữa team phát triển và khách hàng, tính toán phát sinh chi phí nếu cần
