Phân tích Urd Là Gì – Urd Là File Gì Phần Mềm & Cách Mở File là conpect trong bài viết hiện tại của chúng tôi. Tham khảo content để biết chi tiết nhé.
Hế lôôô anh em, bài này mình sẽ đi tiếp quy trình làm dự án phần mềm và công việc của BA trong đó.
Bạn đang xem: Urd là gì
Ở phần trước mình đã note lại giai đoạn đầu tiên là Analysis, gồm 6 bước nhỏ: Project Definition >> Elicitation >> Analysis >> Documentation >> Verification >> Management.
Hi vọng anh em sẽ không cảm thấy khó hiểu khi đọc đến đây.
Sau bước Analysis này chúng ta đã có tài liệu mô tả yêu cầu, tức là đã biết được khách hàng cần gì. Giờ BA và team dự án sẽ đi vào giai đoạn thiết kế hệ thống sao cho đáp ứng những yêu cầu này nhé anh em ????
2. Design
Ở bước này, tùy level, trách nhiệm, và loại dự án, mà BA sẽ tham gia vào ít hoặc nhiều.
Thực tế xảy ra là: hiếm khi BA ghi nhận các được yêu cầu một cách chi tiết ngay ở bước analysis. Nếu có thì chỉ ở mức độ high level. Còn tiểu tiết như từng User Story thì rất khó.
Do đó thường thì ở giai đoạn này (và có thể là các giai đoạn sau), BA sẽ phải trao đổi thêm với khách hàng để làm rõ các yêu cầu (những anh em nào đã kinh nghiệm, có khả năng clarify rõ ràng mọi thứ ngay từ đầu thì những giai đoạn sau này sẽ đỡ hơn rất nhiều).
Chưa kể nếu dự án triển khai theo Agile thì yêu cầu thay đổi liên tục, đòi hỏi anh em phải quản lý các requirement bài bản và làm việc với khách hàng nhiều về các yêu cầu thay đổi này.
Đó là phía mình, còn về phía khách hàng, nhiều khi họ còn chưa chắc về những yêu cầu họ đưa ra. Mà business thay đổi thì là chuyện một sớm một chiều.
Nên đây là chuyện hết sức bình thường: Requirement sẽ luôn thay đổi không ít thì nhiều xuyên suốt dự án. Đó là lý do vì sao mình vẽ đường //Requirement// màu xanh lá trên cùng chạy xuyên suốt dự án đó anh em ????
Ở bước design, anh em sẽ can thiệp sâu một ít về kỹ thuật, bao gồm những thứ như:
Thiết kế DatabaseVẽ Data FlowVẽ MockupThiết kế UX/UIThiết kế Business Process FlowThiết kế bộ phân quyền hệ thốngVẽ Solution Architect…
Nghe tùm lum tùm la nhưng những điểm trên không phải một mình BA thầu hết (may quá), mà phải có sự can thiệp/ support của các anh em khác, có thể là Dev, Technical Architect, hoặc PM…
Và những thứ này sẽ linh động theo tùy loại dự án. Như những dự án triển khai thì sẽ không cần thiết kế UX/UI hay vẽ mockup.
Tuy nhiên mình thấy trong các thứ trên, hầu như BA sẽ thầu hết 70%.
Solution Architect thì TA sẽ làm. Database thì BA làm cũng được, nhưng cần có sự review từ toàn team vì nó sẽ ảnh hưởng đến những thứ trong tương lai. Còn về UX/UI thì có anh em designer làm chứ BA mình không có chuyên môn để làm phần này (và thường thì cũng chẳng có BA nào đi design UX/UI cả – trừ khi thiếu resources dữ lắm thôi).
Sau cùng cả team sẽ gom các kết quả lại để ra được thành phẩm cuối cùng là: Tài liệu thiết kế.
Để cho sang thì anh em hay gọi là SDD (Software Design Document) hoặc FDD (Functional Design Document).
…
Ô kê, vậy là qua 2 giai đoạn (Analysis và Design), chúng ta đã có được 2 tài liệu quan trọng:
Tài liệu mô tả yêu cầu (SRS/FRD)Tài liệu thiết kế (SDD/FDD)
Có hàng nóng trong tay, anh em developer sẽ bắt đầu HIỆN THỰC HÓA sản phẩm bằng cách viết những dòng code đầu tiên.
Xem thêm: Skrill Là Gì – Tổng Quan Skrill Moneybookers
3. Develop
Giai đoạn này anh em BA sẽ hỗ trợ Development Team trong quá trình build sản phẩm.
Ví dụ có Use Case nào chưa rõ, anh em sẽ giải thích để dev họ hiểu hơn về mục đích của Use Case. Hoặc nếu anh em làm giai đoạn Analysis và Design không kỹ, thì giai đoạn Development sẽ lòi ra những lỗi logic giữa các yêu cầu với nhau.
Ví dụ yêu cầu này conflict yêu cầu kia. Thì lúc này anh em BA phải làm việc lại với khách hàng để làm rõ vấn đề, rồi update lại cho Development Team để anh em làm tiếp.
Sau khi Development Team build xong một hoặc nhiều tính năng nào đó, chúng ta sẽ phải test các tính năng này.
4. Test
Giai đoạn test gồm 2 giai đoạn nhỏ: Internal Testing và External Testing.
4.1. Internal Testing
Internal Testing tức là nội bộ team dự án tự kiểm tra với nhau xem thử các tính năng đã được build đúng chưa, trước khi release cho khách hàng.
Đây có thể là nhiệm vụ của BA, hoặc không.
Các Software Development Team luôn có vai trò QC. QC sẽ là người chịu trách nhiệm test các tính năng vừa mới build này. Đảm bảo Dev làm đúng theo như tài liệu yêu cầu/ thiết kế, và đảm bảo team deliver đúng như những gì đã cam kết với khách hàng.
QC sẽ viết các Test Case để kiểm tra từng tính năng một.
Còn đối với các dự án triển khai, Software Implementation Team thường sẽ không có QC. BA trong team sẽ chịu trách nhiệm cho các phần test này luôn.
Vì so với những dự án build mới từ đầu, độ chính xác của các tính năng chuẩn trong các dự án triển khai sẽ cao hơn rất nhiều.
Vì triển khai là triển khai những gì đã có sẵn. Những tính năng này đều do các hãng lớn build sẵn, nên hầu như việc sai sót là không có.
Xem thêm: Doanh Nghiệp Tiếng Anh Là Gì, Từ Vựng Tiếng Anh Cơ Bản Về Công Ty
BA trong các dự án triển khai chỉ cần test lại các tính năng “khác lạ so với chuẩn”. Tức là những tính năng customized mà khách hàng yêu cầu. Chứ không cần test lại toàn bộ các tính năng từ nhỏ tới lớn mà dev build như login, authorization, CRUD, import/export…
Ngoài Test Case ra, anh em BA cần phải chuẩn bị một thứ nguy hiểm hơn, đó là: Requirement Traceability Matrix (RTM).
Chuyên mục: Hỏi Đáp