Phát Biểu Bài Toán (Statement of Work - SOW) Trong Quản Lý Dự Án CNTT

Phát biểu bài toán (Statement of Work) là gì? Tìm hiểu cách xây dựng SOW hiệu quả, chi tiết để đảm bảo dự án thành công. Mẫu SOW chuẩn.

• Tác giả: Huỳnh Mậu Quý
• Người hướng dẫn: ThS. Nguyễn Hữu Trung
• Trường học: Trường Đại học Công Nghệ TP.HCM
• Chuyên ngành: Quản lý dự án công nghệ thông tin
• Đề tài: Phát biểu bài toán – Statement Of Work
• Loại tài liệu: Đồ án môn học
• Năm xuất bản: 2020
• Địa điểm: TP.HCM

Mục lục chi tiết

• NHẬN XÉT CỦA GIAO VIÊN HƯỚNG DẪN
• LỜI CẢM ƠN
• MỤC LỤC
• DANH MỤC CÁC BẢNG
• DANH MỤC CÁC HÌNH VẼ
• 1. CHƯƠNG 1: TỔNG QUAN
• 1.1. Giới thiệu đề tài
• 1.2. Tên nhóm thực hiện đề tài
• 1.3. Ý nghĩa tên nhóm
• 1.4. Các thành viên tham gia
• 2. CHƯƠNG 2: QUẢN LÝ PHẠM VI DỰ ÁN
• 2.1. Phát biểu bài toán – Statement Of Work
• 2.2. Thời gian và vật liệu (Time and Materials)
• 2.3. Dự kiến chi phí về nguồn nhân lực
• 2.4. Dự kiến chi phí về bản quyền phần mềm và thiết bị
• 2.5. Dự kiến các chi phí phát sinh
• 2.6. Dự kiến tổng chi phí
• 2.7. Điều khoản thanh toán hợp đồng (Payment Terms)
• 2.8. Quy trình quản lý thay đổi (Change Management Process)
• 2.9. Các chi phí liên quan (Engagement related expenses)
• 2.10. Hợp đồng thỏa thuận dịch vụ (Profressional services agreement)
• 2.11. Chấp nhận và ủy quyền (Acceptance and authoziration)
• 2.12. Tôn chỉ dự án – Project Charter
• 2.13. Mục tiêu dự án (Project Purpose)
• 2.14. Cách tiếp cận và phạm vi (Project Scope)
• 2.15. Bàn giao dự án (Project Deliverables)
• 2.16. Các cột mốc thời gian (Milestones)
• 2.17. Ngân sách dự án (Project Budget)
• 2.18. Ràng buộc và phụ thuộc (Project Constraints and - Dependencies)
• 2.19. Các rủi ro đã nhận biết (Known Risk)
• 2.20. Vai trò và trách nhiệm (Roles and Responsibilies)
• 2.21. Phát biểu phạm vi – Scope Statement
• 2.22. Cấu trúc phân rã công việc – WBS (Work Breakdown Structure)
• 2.23. Các công việc cần chuẩn bị
• 3. CHƯƠNG 3: QUẢN LÝ THỜI GIAN DỰ ÁN
• 3.1. Ước lượng thời gian cho từng công việc
• 3.2. Phân rã nhánh công việc
• 3.3. Đường công việc và đường thiết yếu
• 4. CHƯƠNG 4: QUẢN LÝ CHI PHÍ DỰ ÁN
• 4.1. Ước lượng chi phí cho từng công việc
• 4.2. Tính toán các chỉ số theo mô hình COCOMO cơ bản
• 5. CHƯƠNG 5: QUẢN LÝ CHẤT LƯỢNG DỰ ÁN
• 5.1. Các tiêu chuẩn đánh giá mức độ thành công của dự án
• 5.2. Tiêu chuẩn đánh giá cho cột mốc Milestone
• 5.3. Các vấn đề phát sinh sau khoản thời gian thực hiện đồ án
• 5.4. Phân tích Pareto
• 6. CHƯƠNG 6: QUẢN LÝ NHÂN SỰ DỰ ÁN
• 6.1. Ước lượng số lượng nhân sự
• 6.2. Sơ đồ tổ chức nhân sự
• 6.3. Ma trận kỹ năng của nhân viên
• 6.4. Gán công việc vào sơ đồ WBS
• 6.5. Ma trận công việc, nhật đồ tài nguyên
• 6.6. Bảng thu nhập cho từng nhân sự
• 6.7. Các báo cáo trong MS về nhân sự
• 7. CHƯƠNG 7: QUẢN LÝ TRUYỀN THÔNG DỰ ÁN
• 7.1. Thu thập thông tin
• 7.2. Phân phối thông tin
• 7.3. Giám sát và điều chỉnh
• 7.4. Giải quyết khi có xung đột
• 8. CHƯƠNG 8: QUẢN LÝ RỦI RO DỰ ÁN
• 8.1. Phương pháp dùng để nhận biết rủi ro
• 8.2. Danh sách các rủi ro có thể xảy ra và hướng đối phó
• 8.3. Kế hoạch đối phó rủi ro không thể trước được
• 9. CHƯƠNG 9: QUẢN LÝ MUA SẮM DỰ ÁN
• 9.1. Danh sách mua sắm các thiết bị
• 9.2. Đơn vị cung cấp dịch vụ
• 10. CHƯƠNG 10: QUẢN LÝ TÍCH HỢP DỰ ÁN
• 10.1. Chuẩn bị các công việc cho quá trình triển khai phần mềm
• 10.2. Tài liệu hướng dẫn cài đặt, sử dụng
• 10.3. Huấn luyện người dùng
• 10.4. Chuyển giao sản phẩm
• 10.5. Tổng kết và đánh giá

Tóm tắt

I. SOW là gì Nền tảng thành công cho mọi dự án quản lý

Trong lĩnh vực quản lý dự án, việc thiết lập một nền tảng vững chắc ngay từ đầu là yếu tố quyết định đến sự thành công. Một trong những tài liệu quan trọng nhất để thực hiện điều này chính là Phát biểu bài toán (SOW), hay còn gọi là Statement of Work. Đây là một văn bản pháp lý chi tiết, mô tả toàn bộ công việc, sản phẩm cần bàn giao, mục tiêu, lịch trình, và các điều khoản mà một bên (nhà thầu hoặc nhà cung cấp) sẽ thực hiện cho một bên khác (khách hàng). SOW không chỉ là một bản mô tả công việc, mà còn là một thỏa thuận ràng buộc, thiết lập kỳ vọng rõ ràng cho tất cả các bên liên quan (stakeholders). Theo một nghiên cứu về quản lý dự án, hơn 50% các dự án thất bại xuất phát từ việc xác định yêu cầu và phạm vi không rõ ràng. Một bản tuyên bố công việc (Statement of Work) được soạn thảo kỹ lưỡng sẽ giúp giảm thiểu rủi ro này bằng cách định hình một lộ trình chi tiết. Nó đóng vai trò như một bản đồ, hướng dẫn đội ngũ dự án từ điểm bắt đầu đến khi hoàn thành, đảm bảo mọi người đều hiểu rõ mục tiêu chung và trách nhiệm của mình. SOW là cơ sở để xây dựng các tài liệu quan trọng khác như Cấu trúc phân rã công việc – WBS (Work Breakdown Structure) và kế hoạch quản lý dự án tổng thể.

1.1. Định nghĩa Statement of Work là gì trong dự án

Statement of Work (SOW) là một tài liệu chính thức, mô tả chi tiết các hoạt động, sản phẩm bàn giao và mốc thời gian của một dự án. Nó xác định các yêu cầu cụ thể và các điều khoản của hợp đồng. Về bản chất, SOW trả lời các câu hỏi cốt lõi: Ai, Cái gì, Ở đâu, Khi nào và Như thế nào. Nội dung của SOW thường bao gồm phạm vi công việc, mục tiêu, các nhiệm vụ cần thực hiện, lịch trình chi tiết với các mốc thời gian dự án (milestones) quan trọng, danh sách các sản phẩm bàn giao (deliverables), các tiêu chuẩn hiệu suất và tiêu chí nghiệm thu. Tài liệu này đóng vai trò là kim chỉ nam cho đội ngũ dự án và là cơ sở để đo lường tiến độ và thành công của dự án.

1.2. Vai trò của SOW trong việc quản lý các bên liên quan

SOW là công cụ giao tiếp trung tâm giữa khách hàng và nhà cung cấp dịch vụ. Nó đảm bảo rằng tất cả các bên liên quan đều có chung một sự hiểu biết về các mục tiêu và kết quả mong đợi của dự án. Bằng cách định nghĩa rõ ràng trách nhiệm, kỳ vọng và các sản phẩm bàn giao, SOW giúp quản lý mối quan hệ giữa các bên, tránh những hiểu lầm có thể dẫn đến xung đột. Trong tài liệu nghiên cứu về dự án 'Phần mềm quản lý học sinh', SOW đã xác định rõ vai trò và trách nhiệm của từng thành viên, từ 'Trưởng phòng hành chính' phía khách hàng đến 'Quản lý dự án' và 'Lập trình viên' phía đội ngũ phát triển (Bảng 2.10: Vai trò và trách nhiệm của từng thành viên tham gia dự án), tạo ra sự minh bạch và trách nhiệm giải trình.

1.3. Phân biệt SOW với Project Charter và Hợp đồng dự án

Mặc dù có liên quan, SOW, Project Charter (Tôn chỉ dự án) và Hợp đồng dự án là các tài liệu khác nhau. Project Charter là một tài liệu cấp cao, được tạo ra trong giai đoạn khởi tạo để chính thức phê duyệt sự tồn tại của dự án và trao quyền cho người quản lý dự án. Nó phác thảo mục tiêu và phạm vi ở mức tổng quan. Ngược lại, SOW đi vào chi tiết hơn rất nhiều, mô tả cụ thể 'cách thức' thực hiện công việc. Trong khi đó, Hợp đồng dự án là một thỏa thuận pháp lý bao trùm, và SOW thường là một phụ lục hoặc một phần không thể tách rời của hợp đồng, cung cấp chi tiết kỹ thuật và nghiệp vụ cho các điều khoản pháp lý chung.

II. Rủi ro khi thiếu SOW trong quản lý dự án Tránh Scope Creep

Việc bỏ qua hoặc soạn thảo một bản Phát biểu bài toán (SOW) sơ sài là một trong những sai lầm nghiêm trọng nhất trong quản lý dự án. Hậu quả trực tiếp và phổ biến nhất là hiện tượng 'scope creep', hay còn gọi là sự leo thang phạm vi. Khi không có một ranh giới công việc rõ ràng được xác định trong SOW, các yêu cầu mới rất dễ được thêm vào một cách không kiểm soát trong suốt vòng đời dự án. Điều này dẫn đến việc đội ngũ phải làm nhiều hơn so với kế hoạch ban đầu, gây áp lực lên nguồn lực, kéo dài mốc thời gian dự án và làm tăng chi phí. Một nghiên cứu của Viện Quản lý Dự án (PMI) chỉ ra rằng 52% các dự án đã trải qua hiện tượng scope creep. Ngoài ra, sự thiếu minh bạch từ một SOW yếu kém còn gây ra hiểu lầm giữa khách hàng và đội ngũ phát triển, dẫn đến tranh chấp về sản phẩm bàn giao và các tiêu chí nghiệm thu. Khi kỳ vọng không được quản lý chặt chẽ, sự hài lòng của khách hàng giảm sút, và dự án có nguy cơ thất bại cao dù đội ngũ đã nỗ lực hết mình. Một SOW hiệu quả chính là hàng rào bảo vệ vững chắc nhất chống lại những rủi ro này.

2.1. Hiện tượng Scope Creep và những hệ lụy tài chính

Scope creep là sự gia tăng dần dần, không được kiểm soát của phạm vi dự án. Nó xảy ra khi các yêu cầu bổ sung được đưa vào sau khi dự án đã bắt đầu mà không có sự điều chỉnh tương ứng về thời gian, chi phí và nguồn lực. Nếu không có một nội dung SOW chi tiết làm cơ sở đối chiếu, việc từ chối các yêu cầu ngoài phạm vi trở nên rất khó khăn. Hệ lụy tài chính là không thể tránh khỏi. Mỗi thay đổi nhỏ đều tiêu tốn thời gian và công sức, làm đội chi phí nhân lực và có thể ảnh hưởng đến báo giá dự án ban đầu. Trong tài liệu tham khảo, việc có một 'Quy trình quản lý thay đổi' rõ ràng trong SOW là một cơ chế để kiểm soát scope creep, yêu cầu mọi thay đổi phải được phân tích, đánh giá và phê duyệt chính thức.

2.2. Tranh chấp về sản phẩm bàn giao và tiêu chí nghiệm thu

Khi một SOW không định nghĩa rõ ràng 'thế nào là hoàn thành', tranh chấp là điều khó tránh. Khách hàng có thể có một hình dung khác về sản phẩm bàn giao (deliverables) so với những gì đội ngũ phát triển thực hiện. Ví dụ, một yêu cầu 'xây dựng chức năng báo cáo' có thể được hiểu theo nhiều cách khác nhau. Một SOW tốt sẽ chi tiết hóa các yêu cầu này: báo cáo cần có những chỉ số nào, định dạng ra sao, tần suất xuất báo cáo như thế nào. Tương tự, tiêu chí nghiệm thu phải được lượng hóa và có thể đo lường được. Thiếu những chi tiết này, quá trình nghiệm thu sẽ dựa trên cảm tính, dẫn đến việc phải làm lại nhiều lần và gây bất mãn cho cả hai bên.

III. Hướng dẫn xây dựng các thành phần cốt lõi trong một SOW

Để viết một Phát biểu bài toán (SOW) hiệu quả, việc cấu trúc nội dung một cách logic và đầy đủ là vô cùng quan trọng. Một bản SOW không chỉ là danh sách các công việc, mà phải là một tài liệu toàn diện bao gồm mọi khía cạnh của dự án. Bắt đầu với phần giới thiệu tổng quan, mô tả bối cảnh và mục tiêu kinh doanh mà dự án hướng tới. Tiếp theo, phần quan trọng nhất là quản lý phạm vi dự án, nơi tất cả các công việc cần thực hiện và không cần thực hiện phải được liệt kê rõ ràng. Điều này giúp ngăn chặn những giả định sai lầm. Sau đó, tài liệu cần đi sâu vào các sản phẩm bàn giao cụ thể, định nghĩa chúng một cách chi tiết để không có sự mơ hồ. Mỗi sản phẩm bàn giao nên được liên kết với các mốc thời gian dự án (milestones) tương ứng trong lịch trình tổng thể. Các yêu cầu về kỹ thuật, tiêu chuẩn chất lượng, và các giả định cũng cần được nêu rõ. Cuối cùng, một mẫu SOW chuẩn không thể thiếu phần chi phí, điều khoản thanh toán và quy trình quản lý thay đổi. Đây là những yếu tố đảm bảo sự minh bạch về tài chính và tạo ra một khuôn khổ linh hoạt để xử lý các thay đổi không lường trước một cách có kiểm soát.

3.1. Xác định phạm vi công việc và mục tiêu dự án

Đây là trái tim của SOW. Phần này cần mô tả chi tiết công việc sẽ được thực hiện. Bắt đầu bằng việc nêu bật mục tiêu chính của dự án. Ví dụ, trong tài liệu gốc, mục tiêu là 'Xây dựng phần mềm quản lý học sinh trường THPT, giúp cho việc quản lý học sinh trở nên dễ dàng, nhanh chóng và chính xác.' Sau đó, liệt kê các nhiệm vụ và hoạt động cụ thể cần thiết để đạt được mục tiêu đó. Quan trọng không kém là xác định những gì nằm 'ngoài phạm vi' (out of scope). Việc này giúp quản lý kỳ vọng và ngăn chặn scope creep ngay từ đầu. Một phạm vi công việc rõ ràng là nền tảng cho việc lập kế hoạch và phân bổ nguồn lực hiệu quả.

3.2. Liệt kê sản phẩm bàn giao và mốc thời gian Milestones

Mọi dự án đều tạo ra kết quả cụ thể, và chúng được gọi là sản phẩm bàn giao (deliverables). SOW phải liệt kê tất cả các sản phẩm này, từ báo cáo, tài liệu thiết kế, mã nguồn, đến sản phẩm phần mềm hoàn chỉnh. Mỗi sản phẩm cần có mô tả chi tiết. Ví dụ, 'Tài liệu hướng dẫn sử dụng phần mềm' là một sản phẩm bàn giao được đề cập trong tài liệu gốc. Các mốc thời gian dự án (milestones) là những điểm kiểm soát quan trọng trong lịch trình, thường gắn liền với việc hoàn thành một hoặc nhiều sản phẩm bàn giao. Việc xác định rõ các cột mốc này giúp theo dõi tiến độ và tạo cơ hội để các bên liên quan xem xét và phê duyệt công việc theo từng giai đoạn (Bảng 2.7: Các cột mốc cho dự án).

3.3. Thiết lập tiêu chí nghiệm thu và điều khoản thanh toán

Làm thế nào để biết một công việc đã thực sự hoàn thành và đạt yêu cầu? Đó là vai trò của tiêu chí nghiệm thu. Các tiêu chí này phải cụ thể, có thể đo lường, có thể đạt được, phù hợp và có thời hạn (SMART). Ví dụ, 'Phần mềm phải chạy ổn định, không bị trễ' là một tiêu chí trong tài liệu. Các điều khoản thanh toán phải được liên kết chặt chẽ với việc hoàn thành các mốc thời gian và nghiệm thu sản phẩm bàn giao. Tài liệu gốc đã minh họa rất rõ điều này khi chia việc thanh toán thành 3 giai đoạn, gắn liền với các bước 'ký kết hợp đồng', 'triển khai bản Beta', và 'triển khai bản Open', đảm bảo quyền lợi và thúc đẩy tiến độ cho cả hai bên.

IV. Phân tích mẫu SOW thực tiễn từ dự án quản lý học sinh

Lý thuyết sẽ trở nên dễ hiểu hơn khi được áp dụng vào thực tiễn. Tài liệu nghiên cứu về dự án 'Phần mềm quản lý học sinh trường THPT ABC' cung cấp một ví dụ điển hình về cách một Phát biểu bài toán (SOW) được cấu trúc và triển khai. Phân tích mẫu SOW chuẩn này cho thấy cách các yếu tố lý thuyết được cụ thể hóa thành các điều khoản, con số và kế hoạch hành động rõ ràng. Từ việc xác định khách hàng và quản trị viên, dự tính thời gian 77 ngày, đến việc phân rã chi tiết các loại chi phí, SOW này đã tạo ra một khuôn khổ minh bạch ngay từ đầu. Các bảng biểu như 'Dự kiến chi phí về nguồn nhân lực' (Bảng 2.2) hay 'Dự kiến chi phí về bản quyền phần mềm và thiết bị' (Bảng 2.3) không chỉ là những con số ước tính mà còn là cam kết về nguồn lực và ngân sách. Việc phân tích một ví dụ thực tế như vậy giúp các nhà quản lý dự án học hỏi và áp dụng vào bối cảnh của riêng mình, từ đó nâng cao chất lượng của các tài liệu SOW và góp phần vào sự thành công của dự án.

4.1. Cách xác định phạm vi và yêu cầu dự án cụ thể

Trong ví dụ này, phần phát biểu phạm vi đã xác định rõ các yêu cầu và tính chất của phần mềm. Các chức năng cốt lõi được liệt kê chi tiết, bao gồm: 'Chức năng đăng nhập', 'Chức năng quản lý học sinh', 'Chức năng tính điểm', 'Chức năng xếp loại', và 'Chức năng báo cáo – thống kê'. Bên cạnh đó, các yếu tố phi chức năng như 'Môi trường hoạt động phần mềm: Desktop Application' và 'Thao tác đơn giản, dễ sử dụng' cũng được nêu bật. Việc làm rõ các yêu cầu dự án này giúp đội ngũ phát triển có định hướng chính xác, tránh việc xây dựng các tính năng không cần thiết và tập trung vào việc mang lại giá trị thực sự cho người dùng.

4.2. Minh họa về các sản phẩm bàn giao và cột mốc thời gian

Phần 'Bàn giao dự án (Project Deliverables)' trong tài liệu đã liệt kê các sản phẩm bàn giao một cách rõ ràng và toàn diện. Danh sách này không chỉ bao gồm sản phẩm chính là 'Phần mềm quản lý học sinh', mà còn cả các hạng mục hỗ trợ quan trọng như 'Các thiết bị phục vụ', 'Bản quyền phần mềm', 'Tài liệu hướng dẫn sử dụng', và 'Kênh hỗ trợ khi có sự cố'. Mỗi sản phẩm này đều là một cam kết cụ thể. Tương ứng với đó, 'Các cột mốc thời gian (Milestones)' (Bảng 2.7) đã phân chia dự án thành các giai đoạn nhỏ hơn, dễ quản lý hơn, từ 'Thu thập các yêu cầu' (7 ngày) đến 'Xây dựng các chức năng' (13 ngày) và 'Kế hoạch bảo trì phần mềm' (1 ngày), tạo ra một lộ trình tiến độ rõ ràng.

4.3. Phân tích chi phí dự án và điều khoản thanh toán hợp đồng

Sự minh bạch tài chính là một điểm mạnh của SOW trong ví dụ này. Phần 'Dự kiến tổng chi phí' đã tổng hợp chi phí từ ba nguồn chính: nhân lực, bản quyền & thiết bị, và chi phí phát sinh (Bảng 2.5). Các con số cụ thể giúp các bên liên quan có cái nhìn rõ ràng về ngân sách cần thiết. Đặc biệt, 'Điều khoản thanh toán hợp đồng' được thiết kế thông minh theo 3 giai đoạn (30% - 40% - 30% còn lại), gắn liền với các mốc tiến độ quan trọng. Phương pháp này không chỉ đảm bảo dòng tiền cho đội ngũ phát triển mà còn tạo động lực để họ hoàn thành các giai đoạn đúng hạn, đồng thời giảm rủi ro cho khách hàng vì họ chỉ thanh toán khi đã nhận được kết quả tương ứng.

V. Tối ưu SOW trong quản lý dự án Chìa khóa cho tương lai

Một bản Phát biểu bài toán (SOW) không phải là một tài liệu tĩnh được tạo ra một lần rồi lãng quên. Nó là một văn kiện sống, cần được tham chiếu, cập nhật và quản lý trong suốt vòng đời dự án. Để tối ưu hóa SOW, cần đảm bảo rằng ngôn ngữ sử dụng là rõ ràng, đơn nghĩa và tránh các thuật ngữ mơ hồ. Sự tham gia của tất cả các bên liên quan chính, bao gồm cả đội ngũ kỹ thuật và đại diện khách hàng, trong quá trình soạn thảo là rất quan trọng để đảm bảo tính chính xác và sự đồng thuận. Trong tương lai, với sự phát triển của các phương pháp quản lý dự án linh hoạt (Agile), SOW cũng cần có sự điều chỉnh để phù hợp. Thay vì cố gắng định nghĩa mọi chi tiết từ đầu, một 'Agile SOW' có thể tập trung vào việc xác định các mục tiêu kinh doanh, các kết quả chính (key outcomes) và ngân sách tổng thể, trong khi cho phép phạm vi công việc được điều chỉnh linh hoạt qua các vòng lặp (sprint). Việc kết hợp sự chặt chẽ của SOW truyền thống với tính linh hoạt của Agile sẽ là chìa khóa để quản lý thành công các dự án phức tạp trong môi trường kinh doanh biến động.

5.1. Tầm quan trọng của quy trình quản lý thay đổi Change Management

Không có dự án nào diễn ra chính xác 100% như kế hoạch. Thay đổi là không thể tránh khỏi. Vì vậy, một SOW mạnh phải đi kèm với một 'Quy trình quản lý thay đổi' chặt chẽ. Như trong tài liệu tham khảo, quy trình này bao gồm các bước: 'Yêu cầu thay đổi', 'Tiếp nhận và phân tích ảnh hưởng', và 'Chấp nhận hoặc từ chối'. Việc có một quy trình chính thức đảm bảo rằng mọi thay đổi đối với phạm vi công việc, thời gian hoặc chi phí đều được xem xét cẩn thận, đánh giá tác động và được phê duyệt bởi các bên có thẩm quyền. Điều này giúp kiểm soát scope creep và duy trì sự ổn định cho dự án.

5.2. Hướng tới một SOW linh hoạt trong kỷ nguyên Agile

Các dự án công nghệ hiện đại thường đòi hỏi sự linh hoạt cao. Việc áp dụng một SOW cứng nhắc có thể cản trở sự đổi mới. Do đó, xu hướng hiện nay là xây dựng các SOW linh hoạt hơn. Thay vì mô tả chi tiết 'cách làm', SOW có thể tập trung vào 'kết quả cần đạt'. Ví dụ, SOW có thể định nghĩa một ngân sách cho một khoảng thời gian nhất định (ví dụ: 3 tháng) và một mục tiêu cấp cao. Đội ngũ Agile sẽ có quyền tự chủ để xác định các công việc cụ thể trong từng sprint để đạt được mục tiêu đó. Cách tiếp cận này kết hợp sự bảo vệ của một hợp đồng dự án với khả năng thích ứng cần thiết để tạo ra sản phẩm tốt nhất.

Trích đoạn nội dung tài liệu

Chương 1: TỔNG QUAN 1. Giới thiệu đề tài Trong thời đại phát triển của công nghệ thông tin như hiện nay, việc áp dụng các ứng dụng của công nghệ thông tin vào công việc quản lý các dữ liệu là hết sức cần thiết, giúp bảo đảm an toàn về dữ liệu, truy xuất các thông tin một cách nhanh chóng, … Phần mềm quản lý học sinh trường trung học phổ thông ra đời cũng là điều tất yếu của quá trình phát triển, ứng dụng công nghệ thông tin vào trong giáo dục. Giúp quá trình quản lý học sinh trở nên nhanh chóng và dễ dàng hơn, giúp việc tính toán các điểm số cho học sinh trở nên đơn giản nhưng vẫn đảm bảo được an toàn về dữ liệu, điểm số cho học sinh; cũng như dựa vào các điểm số mà tạo được các báo cáo thống kê một cách chính xác. Tên nhóm thực hiện đề tài Sau thời gian hội ý và thảo luận, các thành viên trong nhóm đã thống nhất lựa chọn tên cho nhóm là “Like a Wolf”.

Ý nghĩa tên nhóm Trong thế giới tự nhiên, hổ luôn được coi là chúa tể sơn lâm, sư tử thì vô cùng mạnh mẽ nhưng “sát thủ rừng xanh” phải kể đến loài sói. Dù không mang trong mình một sức mạnh vô song nhưng sói là những kẻ đi săn gan lì và dẻo dai bậc nhất. Với kẻ yếu thế hơn, loài sói luôn sẵn sàng khô máu để chiến đấu. Nhưng khi gặp đối thủ mạnh hơn, chúng sẽ không dễ dàng mạo hiểm.

Loài sói không hề sĩ hiện, gặp kẻ mạnh chúng nhanh chóng rút lui và tìm cơ hội tấn công chứ không dễ dàng bỏ cuộc. Trong trận chiến, nếu sói bắt buộc phải chiến đấu với kẻ mạnh hơn, chúng sẽ đồng loạt tấn công (loài sói được biết đến là loài có tinh thần đoàn kết và tinh thần bầy đàn cực kỳ cao). Trên tinh thần của bầy sói, nhóm luôn đề cao tinh thần đoàn kết, giúp đỡ lẫn nhau, cùng nhau mà tiến bộ vượt qua mọi khó khăn. Các thành viên tham gia Họ và STT MSSV Lớp Email SĐT tên Huỳnh 1 Mậu 1711060619 17DTHA1 [e-mail] 0379112419 Quý Nguyễn 2 Thị Cẩm 1711060331 17DTHA1 tientien.com 0838532354 Tiên Trần 3 Minh 1711060419 17DTHA1 [e-mail] 0964323746 Duyệt Lê 4 Trung 1711060249 17DTHA1 [e-mail] 0362031569 Phẩm Bảng 1.1: Danh sách các thành viên.

7 Chương 2: QUẢN LÝ PHẠM VI DỰ ÁN 2. Phát biểu bài toán – Statement Of Work Trong thời đại công nghệ 4.0, việc quản lý và lưu trữ thông tin ngày càng được sự quan tâm và chú ý của giới công nghệ. Việc tổ chức dữ liệu, lưu trữ, xử lý dữ liệu, trách mất cắp thông tin ngày càng được đặt lên hàng đầu. Chính vì những điều đó, một phần mềm giúp quản lý học sinh tại các trường THPT đang là điều cần thiết, giúp quá trình quản lý thông tin và xủ lý dữ liệu ngày càng nhanh chóng, đáp ứng được nhu cầu của nhà trường, thông tin được đảm bảo trong quá trình xử lý.

Thay thế cho việc quản lý thông tin học sinh và xử lý điểm số liên quan của từng học sinh bằng cái tài liệu giấy hoặc tài liệu bảng tính. Phần mềm quản lý học sinh THPT là kết quả tất yếu của quá trình phát triển của thời đại công nghệ ngày càng phát triển như hiện giờ. Thời gian và vật liệu (Time and Materials) Khách hàng Nguyễn Văn Tèo (Trưởng phòng hành chính Trường THPT ABC) Quản trị viên Huỳnh Mậu Quý Tên dự án Phần mềm quản lý học sinh Thời gian dự tính 77 ngày Ngày bắt đầu 18 /5/ 2020 Ngày kết thúc 03/08/2020 Bảng 2.1: Thông tin cơ bản về dự án. Dự kiến chi phí về nguồn nhân lực Số Thời gian Chi phí Tổng chi phí Mô tả lượng (Theo ngày) (VNĐ/Ngày) (VNĐ) Trưởng nhóm quán lý dự 1 77 800.000 án Nhân viên phát triển phần 3 77 500.000 mềm Nhân viên Training người dùng và triển khai phần 3 15 300.000 mềm Tổng cộng 192.2: Dự kiến chi phí cho nhân sự.

Dự kiến chi phí về bản quyền phần mềm và thiết bị Số Tổng chi phí Mô tả Chi phí (VNĐ) lượng (VNĐ) Server HP 1 20.000 Bản quyền phần mềm Windows 1 10.000 Server 2019 Bản quyền phần mềm SQL 1 10.000 Server 2019 Bản quyền phần mềm Quản lý 1 5.000 học sinh Tổng cộng 275.3: Dự kiến chi phí cho các thiết bị. Dự kiến các chi phí phát sinh Dự kiến chi phí Số lượng Mô tả Tổng chi phí (VNĐ) (VNĐ/Ngày) (Ngày) 200.000 – Tối đa: Chi phí di chuyển, đi lại 15 1.000 – Tối đa: Chi phí lưu trú, 15 2.000 – Tối đa: Chi phí ăn uống 15 400.4: Dự kiến các chi phí phát sinh. Dự kiến tổng chi phí Mô tả Chi phí (VNĐ) Dự kiến chi phí nhân lực 192.000 Dự kiến chi phí bản quyền và thiết bị 275.000 Dự kiến chi phí phát sinh 60.5: Dự kiến chi phí chung cho toàn dự án. Điều khoản thanh toán hợp đồng (Payment Terms) Thời gian thanh toán gia trị hợp đồng được chia làm 3 gia đoạn: - Giai đoạn 1: Thanh toán ngay sau khi gia đoạn phân tích yêu cầu, nghiệp vụ và ký kết hợp đồng.

Thanh toán trước 30% giá trị hợp đồng (158.000 VNĐ), thời hạn thanh toán trong vòng 6 ngày (từ ngày 25/5/2020 đến ngày 30/5/2020). - Giai đoạn 2: Thanh toán tiếp tục 40% giá trị hợp đồng (211.000 VNĐ) ngay sau khi triển khai bản Beta tới người dùng. Thời gian thanh toán trong vòng 6 ngày, căn cứ vào thời gian thỏa thuận thanh toán giữa các bên. - Giai đoạn 3: Thanh toán tiếp thục 40% giá trị hợp đồng (211.000 VNĐ) còn lại ngay sau khi quá trình chạy thử bản Beta kết thúc và triển khai bên Open và 10 ký kết các hợp đồng bảo trì phần mềm.

Thời gian thanh toán trong vòng 6 ngày, căn cứ vào thời gian thở thuận thanh toán giữa các bên. Giả định (Assumptions) Về phía khách hàng: - Phải đảm bảo cung cấp đầy đủ các thông tin, tài liệu liên quan cũng như hướng dẫn, giáp đáp thắc mắc về nghiệp vụ để phụ vụ công tác thu thập thông tin từ phía đội ngũ phát triển. - Về mặt tài chính, phải đáp ứng được các khoản kê chi tiết đã nên ở trên đảm bảo về mặt thiết bị giúp phục vụ cho quá trình xây dựng, phát triển và vận hành phần mềm. - Trong trường hợp, phía khách hàng không thể đáp ứng được các thông tin, nghiệp vụ cũng như không thể đảm bảo về mặt tài chính trong quá trình xây dựng và phát triển phần mềm, phía khách hàng có thời hạn 30 ngày để bổ sung, đảm bảo các điều kiện xậy dựng và phát triển phần mềm.

Thời hạn sẽ được thống nhất bởi đội ngũ phát triển và phía khách hàng. Về phía đội ngũ phát triển: - Có trách nhiệm tư vấn, phân tích cho phía khách hàng hiểu rõ các mô hình, làm rõ các yêu cầu và chức năng bên phía khách hàng mong muốn có trong phần mềm quản lý học sinh. - Hiểu đúng và hiểu rõ các yêu cầu từ phía khách hàng, nắm chắc nghiệp vụ xử lý và quản lý học sinh. - Đảm bảo xây dựng phần mềm đúng theo yêu cầu của phía khách hàng, bảo đảm an toàn thông tin, trách mất thông tin trong quá trình xử lý.

- Nếu phía đội ngủ phát triển không thể thực hiện xây dựng được phần mềm quản lý thì đội ngũ phát triển phải có trách nhiệm đền bù các thiệt hại và có trách nhiệm tìm công ty, bên thứ ba đảm bảo xây dựng được phần mềm quản lý học sinh cho phía khách hàng. Các chi phí phát sinh, phía đội ngủ phát triển phải chịu trách nhiệm toàn bộ. Quy trình quản lý thay đổi (Change Management Process) Quy trình sau đây sẽ được thực hiện nếu có các thay đổi cần chỉnh sửa trong quà trình xây dựng và phát triển phần mềm: - Yêu cầu thay đổi. 11 - Tiếp nhận yêu cầu và phân tích các ảnh hưởng.

- Chấp nhận hoặc từ chối yêu cầu thay đổi. o Nếu chấp nhận, thực hiện các thay đổi. o Kiểm tra lại các kết quả đã đạt được. Nếu không đáp ứng được như cầu thì có thể sẽ cần lặp lại các bước trên để tiến hành thay đổi.

Nếu đã đáp ứng được yêu cầu thì sẽ cập nhật vào bảng dưới đây. Phiên Ngày cập Chi tiết Họ và tên bản nhật Huỳnh 1.1 Kế hoạch, phân tích, đánh giá về dự án 17/5/2020 Mậu Quý Bổ sung thêm các cột mốc (Milestones), các chi phí liên quan.1 21/5/2020 Cập nhật lại lịch biểu phí, điều khoản thanh toán, Mậu Quý điều chỉnh về thời gian dự án Bổ sung các mốc thời gian hoàn thành cho từng Nguyễn 2.2 công việc, phân rã công việc và vẽ sơ đồ PERT, Thị Cẩm 26/5/2020 xác định đường công việc. Tiên Cập nhật, chỉnh sửa các mốc thời gian hoàn thành cho từng công việc, cập nhật các nhánh phân rã và Huỳnh 2.3 02/06/2020 cập nhật chỉnh sửa sơ đồ PERT, cập nhật đường Mậu Quý công việc. Bổ sung các chi phí theo ngày cho từng công việc trong sơ đồ WBS, tính toán các chỉ số COCOMO Trần 2.4 cơ bản, vẽ sơ đồ GANTT, giả định dự án thực hiện Minh 05/06/2020 đến ngày nào đó để xác định các chỉ số CPI, SPI, Duyệt … Cập nhật các chi phí theo ngày cho từng công việc, Huỳnh 2.5 cập nhật sơ đồ GANTT, cập nhật các chỉ số CPI, 09/06/2020 Mậu Quý SPI, … Bổ sung các chỉ tiêu đánh giá khi hoàn thành dự Lê Trung 2.1 án, các chỉ tiêu cho các chức năng cụ thể, giả định 12/06/2020 Phẩm các vấn đề phát sinh cho dự án Cập nhật, chỉnh sửa các tiêu chí hoàn thành dự án, Huỳnh 2.2 16/06/2020 chỉnh sửa các tiêu chí cho các chức năng cụ thể.

Mậu Quý 12 Bổ sung sơ đồ tổ chức cho dự án, bổ sung sơ đồ Nguyễn 2.3 RAM, bổ sung ma trận kỹ năng cho các nhân viên, Thị Cẩm 19/06/2020 bổ xung gán công việc trên WBS Tiên Cập nhật, chỉnh sửa sơ đồ RAM, chỉnh sửa gán Huỳnh 2.4 công việc trên WBS, bổ sung bảng thu nhập cho 23/06/2020 Mậu Quý từng nhân viên, các báo cáo trong MS. Trần Bổ sung các thông tin liên quan đến thu thập thông 2.5 Minh 27/06/2020 tin, phân phối và giám sát, điều chỉnh thông tin Duyệt Cập nhật các phương pháp thu thập thông tin, bổ Huỳnh 2.6 sung cách giải quyết xung đột giữa các thành viên 28/06/2020 Mậu Quý trong nhóm Bổ sung các phương pháp nhận biết rủi ro, liệt kê Lê Trung 2.7 28/06/2020 các kế hoạch ứng phó Phẩm Cập nhật, bổ sung các phương pháp nhận biết rủi Huỳnh 2.8 30/06/2020 ro và cách đối phó Mậu Quý Trần 2.9 Bổ sung danh sách mua sắm các thiết bị Minh 01/07/2020 Duyệt Cập nhật và chỉnh sửa danh sách mua sắm các Huỳnh 2.