(Tiểu luận) bài tập lớnmôn quản lý dự án xây dựng hệ thống quản lý nhà sách tiền phong

TRƯỜNG ĐẠI HỌC KINH TẾ QUỐC DÂN  BÀI TẬP LỚN MÔN QUẢN LÝ DỰ ÁN Học viên thực hiện: Mã học viên: Lớp: Trần Bùi Thu Thủy CH301095 Quản lý Kinh tế Chính sách Hà Nội, tháng 10 năm 2022 XÂY DỰNG HỆ THỐNG QUẢN LÝ NHÀ SÁCH TIỀN PHONG I Giới thiệu dự án 1.1 Thông tin dự án - Tên Dự Án: Xây dựng hệ thống quản lý nhà sách Tiền Phong Khách Hàng: nhà sách Tiền Phong Bên cung cấp sản phẩm: Công ty CP Giải pháp phần mềm Biplus Việt Nam 1.2 Phạm vi dự án Hệ thống thiết kế xây dựng tốt nâng cấp, thay đổi phù hợp với nhiều nhà sách Khu vực ảnh hưởng nhà sách Tiền Phong: quầy tốn, nhóm quản lý xuất nhập, quản lý mạng - Phạm vi liệu: Dữ liệu sách thông tin giao dịch giữ nguyên - Làm thông tin khác Công nghệ thực hiện: Java Application - SQL Server Ước lượng thời gian thực thi dự án : tháng ( 18/10/2021 – 18/03/2022) tương đương với Sprint (Mỗi Sprint dài tuần) 1.3 Sản phầm bàn giao cuối - Phần mềm quản lý sách với đầy đủ chức yêu cầu - Hệ thống sở liệu dự án khách hàng cung cấp Mã nguồn chương trình - Tài liệu phát triển 1.4 Các bên liên quan Vai trò Nhà tài trợ dự án Khách hàng Họ tên Nhà sách Tiền Phong Nhà sách tiền phong Công ty Cổ phần Giải pháp phần mềm BiPlus Việt Bên nhà thầu Nam Đại diện: Bùi Xuân Hiền – Giám đốc 1.5 Tổng quan dự án Hiện công việc quản lý đầu sách nhà sách lớn khơng có hỗ trợ cơng nghệ thơng tin gặp nhiều khó khăn Với số lượng đầu sách lớn, thường xuyên thay đổi cập nhật, bên cạnh số sách bán hàng ngày lớn Dự án triển khai phạm vi nhà sách Tiền Phong, đối tượng tập trung quản lý thông tin đầu sách nhà sách, danh mục đầu sách bán Các chức hệ thống: - Quản lý nhập-xuất sách Quản lý bán sách quầy - Quản lý khách hàng 1.6 Mục tiêu Mục tiêu doanh nghiệp - Hỗ trợ cơng việc tính tốn bán sách nhanh hiệu Quản lý sách nhập xuất nhà sách, tránh gian lận, sai thiếu việc - quản lý số lượng lớn sách Kết nối nhà sách Tiền Phong với thuận tiện Chương trình có giao diện dễ sử dụng, cài đặt với đầy đủ chức quản lý nhà sách cần bổ sung chức nhà sách yêu cầu Mục tiêu công nghệ - Xây dựng trang web để nhận gửi thông tin phản hồi với khách hàng Di chuyển sở hạ tầng cơng nghệ cũ vịng ngày khơng làm ảnh hưởng tới q trình bn bán, quản lý nhà sách - Đẩy nhanh tốc độ xử lý lên 20% 1.7 Yêu cầu nghiệp vụ - Dự án phần mềm phát triển hệ thống quản lý bán sách nhà sách Tiền Phong Người sử dụng phần mềm : Nhân viên quản lý nhà sách nhân viên thu ngân Mục đích dự án thiết kế chương trình quản lý bán sách dễ sử dụng, dễ cài đặt, chương trình có nhiều tính linh hoạt tìm kiếm thông tin sách theo nhiều tùy chọn chuyên nghành, tên sách, tác giả… cập nhật thêm đầu sách mới, tính tổng tiền hóa đơn sách cách nhanh chóng xác 1.8 Thước đo thành cơng dự án - Tiết kiệm chi phí tổng thể >5% Giảm thời gian làm việc >15% - Hệ thống hoạt động tốt với đầy đủ chức tuần chạy thử - Tốc độ xử lý nhanh hệ thống cũ >5% 1.9 Tổng quan nội dung dự án - Kỹ thuật phương pháp phát triển dự án: theo Triết lý Agile Khái niệm Agile (viết tắt Agile Software Development) có nghĩa phương thức phát triển phần mềm linh hoạt, ứng dụng quy trình phát triển phần mềm với mục tiêu đưa sản phẩm đến tay người dùng nhanh tốt Rất nhiều nơi định nghĩa Agile phương pháp Thực chất, Agile giống phương pháp luận, triết lý dựa nguyên tắc phân đoạn vòng lặp (iterative) tăng trưởng (incremental) Quy trình Agile hồn chỉnh Các giai đoạn phát triển sản phẩm chia nhỏ thành phần tăng trưởng cụ thể mà người dùng tương tác Nhờ sản phẩm có phản hồi cần thiết để tránh khỏi vấn đề nghiêm trọng cải tiến tốt Thêm vào đó, quy trình quản lý sản phẩm có tính chất lặp lại cịn giúp cho nhóm chuyển sang phần tăng trưởng khác vấn đề phần tăng trưởng giải - Khung tổ chức công việc: Scrum team Phương pháp quản lý Scrum Framework quy trình quản lý, giúp giải vấn đề phức tạp Phương pháp đảm bảo tính hiệu quả, sáng tạo sản phẩm tạo phải đạt giá trị cao Bản thân Scrum Framework đơn giản, nhằm giúp việc phối hợp hiệu thành viên đội phát triển, thực sản phẩm phức tạp Với phương pháp quản lý Scrum, sản phẩm xây dựng chuỗi quy trình lặp lại (gọi Sprint) Các sprint diễn đặn, sprint hội để học hỏi điều chỉnh nhằm đạt phù hợp kết tốt Khi áp dụng Scrum, có họp (Meetings or Ceremonies) quan trọng tạo nên cấu trúc Sprint sau: Sprint planning: Cuộc họp lên kế hoạch đội dự án, nhằm xác định cần hồn thành Spring tới Daily stand-up: Cũng biết đến “Daily Scrum”, họp nhỏ 15 phút ngày để trao đổi công việc đội phát triển Sprint demo: Một họp chia sẻ, nơi mà thành viên họ làm Sprint Sprint retrospective: Sự đánh giá, nhìn lại điều làm chưa làm Sprint tại, đưa giải pháp hành động cho Sprint tốt hoàn thiện - Tài nguyên sử dụng - Kinh phí đầu tư: 800.000.000 VNĐ bao gồm:  Lương nhân viên tham gia  Tiền thuê sở vật chất  Các chi phí phát sinh  Dữ trữ 10% -  Số thành viên tham gia dự án: người Công cụ thực hiện:  Trọn Microsoft office: lập kế hoạch dự án  Eclipse : Cài đặt chương trình  Visual Paradigm: Phân tích, thiết kế, vẽ biểu đồ chương trình -  SQL Server: Lưu trữ CSDL Kỹ thuật sử dụng dự án  J2EE II  SQL Quản lý nhân dự án 2.1 Lập kế hoạch nhân Dự án xây dựng phần mềm vận hành theo Scrum Scrum - phương pháp phổ biến Agile - framework giúp việc tiếp cận, phát triển công việc/sản phẩm phức tạp cách nhanh nhất, hiệu Theo kinh nghiệm thu trình triển khai dự án với Scrum, Scrum đạt hiệu cao nên tổ chức team có người tối đa người (với nhóm lớn, chia thành nhóm Scrum nhỏ - Scrum of Scrums - giới thiệu viết khác) Scrum bao gồm tập phương pháp thực hành (practices), vai trò (roles), kiện (events), tạo tác (artifacts) quy tắc (rules) thiết kế để làm “kim nam” cho team thực dự án Những vai trò Scrum Team Mỗi Scrum team có ba vai trị tương ứng với trách nhiệm, quyền hạn rõ ràng giúp cho cơng việc tối ưu hóa Ba vai trị Scrum team bao gồm: Development Team, Product Owner Scrum Master Và ba phận kết hợp với có tồn Scrum team Development Team Là thành viên tham gia trực tiếp vào q trình phát triển tính cụ thể phần mềm/sản phẩm Các thành viên Development Team tự tổ chức - nghĩa họ trao quyền để quản lý cơng việc họ Scrum khuyến khích thành viên “đa di năng”, đảm nhiệm nhiều vai trị định miễn cần thiết để hồn thành cơng việc, chẳng hạn phân tích, thiết kế, xây dựng, kiểm thử phần mềm/sản phẩm Yêu cầu vị trí Business Analysis - Nhà phân tích nghiệp vụ kinh doanh Mô tả công việc : - Trực tiếp làm việc với khách hàng để lấy yêu cầu nghiệp vụ cần xây dựng cho hệ thống phần mềm - Trao đổi với giám đốc dự án yêu cầu khách hàng, độ khả thi yêu cầu - Trao đổi yêu cầu nghiệp vụ với nhóm dự án để xây dựng chức tương ứng Document continues below Discover more from: lý dự án Quản QLDA1920 Đại học Kinh tế… 291 documents Go to course ĐỀ CƯƠNG LẬP DỰ 27 ÁN - Trình bày sự… Quản lý dự án 100% (4) Đề cương QLDA - ĐỀ 39 CƯƠNG MÔN QUẢ… Quản lý dự án 83% (6) Sad - giải pháp quản lí rủi ro Quản lý dự án 100% (2) Bài tập cá nhân lập 36 kế hoạch Quản lý dự án 100% (2) đề cương QLDA (English ver cho ai… Quản lý dự án 100% (2) Bai tap Gia tri thoi - gian cua Giám sát trình xây dựng chức để đảm bảo module đượctien xây dựng phù hợp với yêu cầu khách hàng đưa Quản lý 100% (2) Trực tiếp làm việc với khách hàng qua trình xây dựng dựgiao án diện phần mềm, lấy yêu cầu giao diện khách hàng đưa Yêu cầu khả : - Có khả giao tiếp tốt, biết truyền đạt thơng tin Biết lập trình bản, có hiểu biết q trình xây dựng hệ thống thơng tin - Có thẩm mỹ cao, sáng tạo tốt xây dựng giao diện cảm quan Tốt nghiệp đại học chuyên ngành công nghệ thông tin QA - Quality Assurance (Quản lý chất lượng) Mô tả công việc : - Chịu trách nhiệm quản lý dự án Chịu trách nhiệm quản lý nhóm dự án Kiểm tra chất lượng cơng việc hồn thành nhóm dự án - Đưa báo cáo trình phát triển dự án cho giám đốc dự án Đưa gợi ý việc xây dựng phần mềm, định phương pháp phát triển phần mềm áp dụng Yêu cầu khă : - Có khả giao tiếp, truyền đạt thông tin tốt - Nhiều năm kinh nghiệm lập trình, phát triển phần mềm (tối thiểu năm) Có kinh nghiệm việc đảm bảo chất lượng dự án (tối thiểu năm nhóm - QA, năm vị trí quản lý QA) Tốt nghiệp đại học chuyên ngành công nghệ thông tin Người thiết kế giao diện Mô tả công việc : - Trao đổi với nhà phân tích nghiệp vụ kinh doanh Đưa định việc xây dựng giao diện cảm nhận dựa yêu cầu khách hàng tươn ứng - Trao đổi với lập trình viên trình xây dựng giao diện Đảm bảo việc xây dựng chức lập trình viên phù hợp với giao diện cảm quan đưa Yêu cầu khả : - Có khả giao tiếp, truyền đạt thơng tin tốt - Có khả lập trình tốt (2 năm kinh nghiệm) Có kinh nghiệm xây dựng giao diện người dùng Có thẩm mỹ tốt, sáng tạo - Tốt nghiệp đại học, cao đẳng chuyên ngành công nghệ thông tin Người quản trị sở liệu Mô tả công việc : - Trao đổi với nhà phân tích nghiệp vụ kinh doanh - Thiết kế mơ hình sở liệu Lập tình cở sở liệu - Trao đổi với lập trình viên trình xây dựng sở liệu Yêu cầu khả : - Có khả giao tiếp, truyền đạt thơng tin tốt - Có khả lập trình tốt (2 năm kinh nghiệm) Có kinh nghiệm xây dựng sở liệu - Tốt nghiệp đại học, cao đẳng chun ngành cơng nghệ thơng tin Lập trình viên Mơ tả công việc : - Tiếp nhận công việc từ cấp - Lập trình module chức phần mềm Trao đổi với thành viên nhóm q trình xây dựng u cầu khả : - Biết lập trình Có khả tiếp thu tốt - Chăm với cơng việc, có trách nhiệm với cơng việc Tốt nghiệp đại học, cao đăng, trung cấp chuyên ngành công nghệ thông tin Product Owner Giúp nhóm hiểu nhu cầu khách hàng/người dùng, từ nhóm xây dựng sản phẩm/phần mềm có giá trị Product Owner chịu trách nhiệm tối đa hóa giá trị sản phẩm/phần mềm cách quản lý Product Backlog danh sách công việc cần thực Điều bao gồm việc đảm bảo mục product backlog (backlog items) cập nhật liên tục xếp theo mức độ ưu tiên, giúp cho thành viên nhóm hiểu tính năng, yêu cầu liệt kê Product Backlog người dùng cần chúng Đây cơng việc thực quan trọng giúp nhóm xây dựng sản phẩm/phần mềm giá trị Product Owner chịu trách nhiệm đảm bảo khách hàng/người dùng nhóm có hiểu biết chung tầm nhìn dự án, mục tiêu dự án chi tiết công việc thực hiện, để nhóm lập kế hoạch xây dựng hạng mục công việc cách hiệu Mặc dù Product Owner chịu trách nhiệm cuối việc xếp mức độ ưu tiên cập nhật Backlog items, Scrum Master Development Team phải hỗ trợ q trình cách chia sẻ thơng tin ước lượng (thời gian, chi phí, nguồn lực), tính phụ thuộc, mục công việc kỹ thuật, v.v Scrum Master: chịu trách nhiệm giúp nhóm hiểu sử dụng Scrum hiệu Scrum mơ tả đơn giản, lúc dễ dàng để hiểu Đó lý nhóm cần có Scrum Master - người nắm tồn cơng việc từ việc lên kế hoạch, phân công công việc, tổ chức họp giúp Product Owner, Development Team phần cịn lại cơng ty thực Scrum cách xác, hiệu Điều có nghĩa người vai trị dành tồn thời gian để giúp đỡ (hoặc “phục vụ”) cho Product Owner, Development Team người toàn tổ chức, giúp loại bỏ trở ngại trình thực tạo điều kiện thuận lợi cho họ, bao gồm: - Giúp Product Owner tìm cách hiệu để quản lý Backlog - - Truyền đạt tầm nhìn dự án, mục tiêu dự án chi tiết Backlog items cho Development Team, giúp Development Team hiểu hoạt động đặc thù Scrum thực chúng cần Giúp phần lại tổ chức hiểu Scrum phối hợp tốt với nhóm Tạo điều kiện cho việc áp dụng Scrum không dự án mà phạm vi rộng toàn tổ chức 2.2 Xây dựng nhân dự án Vai trò Product Owner Scrum master Trách nhiệm Quản lý toàn hoạt động nhóm dự án Phân cơng cơng việc, tổ chức họp Team thực Scrum cách xác, hiệu Số lượng 1 Nhà phân tích nghiệp Thu thập yêu cầu nghiệp vụ từ vụ kinh doanh khách hàng Kĩ sư đảm bảo chất Đảm bảo chất lượng công việc suốt dự án lượng Người thiết kế giao Xây dựng giao diện cảm quan cho hệ thống diện Người quản trị CSDL Lập trình viên Tổng Thiết kế, xây dựng hệ thống Cơ sở liệu Cài đặt, tích hợp module 2.3 Phát triển đội dự án Scum master người có nhiệm vụ điều phối, tổ chức để chắn thành viên nhóm dự án thực hành Scrum cách xác, hiệu Scrum hoạt động dựa ba giá trị cốt lõi, gọi Ba chân Scrum bao gồm Minh bạch, Thanh tra Thích nghi - Minh bạch (transparency): Trong Scrum, tính minh bạch đề cao giá trị cốt lõi Muốn thành công với Scrum, thơng tin liên quan tới q trình phát triển phải minh bạch thông suốt Các thông tin là: tầm nhìn (vision) sản phẩm, yêu cầu khách hàng, tiến độ công việc, khúc mắc rào cản v.v Từ người vai trị có đủ thơng tin cần thiết để tiến hành định có giá trị để nâng cao hiệu công việc Các công cụ họp Scrum đảm bảo thông tin minh bạch cho bên - - Thanh tra (inspection): Công tác tra liên tục hoạt động Scrum đảm bảo cho việc phát lộ vấn đề giải pháp để thông tin đa dạng hữu ích đến với bên tham gia dự án Truy xét kĩ liên tục chế khởi đầu cho việc thích nghi cải tiến liên tục Scrum Thích nghi (adaptation): Scrum linh hoạt phương pháp phát triển linh hoạt (agile software development) khác Nhờ mang lại tính thích nghi cao Dựa thơng tin minh bạch hóa từ q trình tra làm việc, Scrum phản hồi lại thay đổi cách tích cực, nhờ mang lại thành cơng cho dự án Trong mơ …t nhóm Scrum, có ba bên phép định xử lý cơng việc: PO, Scrum Master nhóm phát triển Mỗi bên bị ràng buô …c trách nhiệm riêng biê t và… họ phải làm việc để đạt cân yêu cầu sản phẩm cuối Nhóm Scrum bắt b …c nhóm liên chức năng, hay nói cách khác nhóm Scrum phải có tất nguồn lực cần thiết để hồn thành công việc Trên bảng Scrum, cột dán nhãn để phản ánh giai đoạn dòng chảy công việc Các task theo thứ tự, làm tất việc sprint vài tuần (khoảng thời gian thông thường cho sprint) chuyển chúng sang trạng thái hoàn thành (cột Done) cuối xử lý hết sprint trạng thái chờ Để thực điều cách dễ dàng, team sử dụng công cụ quản lý dự án như: - Trello: Đây ứng dụng quản lý dự án tiếng sử dụng nhiều Nó có tài khoản miễn phí cao cấp mang đến cho bạn hội tuyệt vời để sử dụng hầu hết chức phổ biến Cấu trúc Trello dựa phương pháp kanban Tất dự án đại diện bảng, có chứa danh sách Mọi danh sách có thẻ lũy tiến mà bạn tạo dạng kéo thả Người dùng có liên quan đến bảng, gán cho thẻ - - Jira: JIRA công cụ phát triển để theo dõi lỗi, theo dõi vấn đề quản lý dự án cho quy trình phát triển phần mềm di động Bảng điều khiển JIRA có nhiều chức & tính hữu ích xử lý vấn đề khác cách dễ dàng Các họp quan trọng việc phát triển đội dự án trình phát triển dự án Các họp bao gồm: - Sprint Planning Meeting (Họp kế hoạch Sprint): Được thực đầu Sprint, Sprint Planning Meetings, người định lựa chọn tính cần thực hiện, phân cơng cơng việc, phân rã tính thành nhiệm vụ (tasks) lên kế hoạch xem công việc thực Sprint Product Owner cập nhật Backlog items nhóm (Development Team + Scrum Master) thảo luận để đảm bảo tất người hiểu mục cơng việc Dựa ước tính, hiệu suất dự kiến hiệu suất khứ, Development team dự đốn khối lượng cơng việc hồn thành Sprint từ xác định mục tiêu Sprint - Sprint goal Sau đó, Development team xác định cách xây dựng chức cho sản phẩm/phần mềm cách họ thực để hoàn thành Sprint goal Sprint Planning Meetings có timeboxed thường - tiếng Cả nhóm tập trung phân rã, lập kế hoạch cơng việc cho tuần đầu Sprint - Daily Scrum and Sprint Execution (Họp ngày) Là họp có timeboxed thường kéo dài khoảng 15 phút, diễn ngày giúp nhóm hướng tới Sprint goal Scrum Master đảm bảo họp diễn hàng ngày theo dõi trở ngại xác định họp Daily Scrum chủ yếu dành cho thành viên Development team để đồng hóa cơng việc báo cáo vấn đề, vướng mắc mà họ gặp phải Phạm vi họp giới hạn nghiêm ngặt, thành viên nhóm trả lời ngắn gọn ba câu hỏi họ làm để đáp ứng Sprint goal: ▶ Tính từ thời điểm kết thúc họp Daily cuối đến bạn làm gì? ▶ Bạn dự định làm hơm nay? ▶ Có cản trở, khó khăn q trình thực bạn khơng - Sprint Review Meeting (Họp sơ kết) Sprint Retrospective Meeting (Họp cải tiến Sprint) Với họp cuối, em trình bày cụ thể phần 2.4 2.4 Điều chỉnh hoạt động dự án: Sẽ có nhiều Sprint dự án, kết thúc Sprint thời gian cho Review Retrspective, để nhân đánh giá lại trình hiệu làm việc - Sprint Review Meeting (Họp sơ kết) Sprint Review meeting tổ chức vào cuối Sprint với tham gia gồm Development team, Product Owner Scrum Master (và bên liên quan khác) Trong họp này, nhóm giới thiệu tính mà họ xây dựng Sprint cho Product Owner Product Owner kiểm tra công việc để xem liệu sản phẩm/phần mềm có thật hoạt động tốt chấp nhận hay khơng Nhóm Product Owner thảo luận phần gia tăng tính mục lại Product Backlog, thực thay đổi cần thiết cho - Backlog Sprint Retrospective Meeting (Họp cải tiến Sprint) Được diễn sau Sprint Review trước Sprint Planning meeting Nội dung họp bàn điều xảy Sprint vừa qua, bao gồm vấn đề người, quy trình sản phẩm Các thành viên nhóm khám phá học kinh nghiệm tốt, điều làm chưa tốt, tìm kiếm hội để cải thiện định thay đổi thực Sprint 3.1 Nhận diện rủi ro Category Description  Yêu cầu khách hàng không đặc tả chức ID 1.1 hệ thống  Quy trình sử dụng sai so với yêu cầu khách hàng Khách hàng Phát triển  Quá nhiều yêu cầu thay đổi khách hàng 1.3  Yêu cầu khách hàng vượt khả dự án phát triển (về chi phí, nhân lực,cơng nghệ) 1.4  Sử dụng mơ hình phát triển phần mềm 2.1  Có thể sử dụng cơng nghệ không phù hợp với dự 2.2 án  Thời gian phát triển dự án lâu so với dự kiến Lợi nhuận 1.2 2.3  Thị trường có đổi đột ngột công nghệ 3.1  Chi phí việc trì ,triển khai hệ thống q cao 3.2  Khả cạnh tranh hệ thống quản lý nhà 3.3 sách có thị trường Ngân sách  Chi phí cho dự án vượt ngân sách 4.1  Xuất chi phí khơng thống kê dự án 4.2 (chi phí giao tiếp, tìm hiểu u cầu ngồi luồng) Nhân lực  Người quản lý khơng có kĩ phù hợp với dự án 5.1 5.2  số programmer khơng có khả làm việc nhóm tốt  Sự số thành viên chủ chốt 5.3  Thiếu thành viên có kĩ tương ứng với 5.4 công nghệ  Xảy bất đồng thành viên dự án Tài nguyên  Thiếu công cụ phát triển lập trình 6.1  Mất mát tài nguyên vật chất 6.2  Sự cố internet, cắt điện luân phiên 6.3  Vấn đề quyền phần mềm 6.4 3.2 Risk Analyze (Phân tích rủi ro) 3.2.1 Likelihood (Khả xảy rủi ro) Bảng mô tả tỉ lệ khả xảy rủi ro dự án : Title Rate Description Rủi ro khả xảy thấp ghi lại không theo dõi Very Low 20 Low 40 Medium 60 Rủi ro xảy rõ ràng dự án High 80 Rủi ro có khả xảy đặc biệt hồn cảnh dự án Very High 100 Rủi ro tỉ lệ xảy cao, trường hợp dự án có rủi ro chắn xảy Rủi ro khả xảy theo dõi suốt dự án 3.2.2 Impact (Mức độ ảnh hưởng rủi ro) Bảng mô tả tỉ lệ tác động rủi ro dự án : Title Rate Very Low 20 Rủi ro khơng có ý nghĩa dự án Description Low 40 Rủi ro có tác động nhỏ dự án ( < 5% chệch hướng dự án ngày kết thúc , chi phí dự án , … ) Medium 60 80 Rủi ro có tác động từ 10% - 25% làm chệch hướng dự án 100 Rủi ro có tác động lớn từ 25% trở lên làm chệch hướng dự án High Very High Rủi ro có tác động từ 5% - 10% làm chệch hướng dự án 3.2.3 Mức ưu tiên rủi ro Bảng mô tả ưu tiên rủi ro bên dự án theo công thức : Priority = (Likelihood + Impact)/2 ID Likelihood Impact Priority Score Rating 1.1 60 100 80 High 1.2 40 100 70 High 1.3 20 80 50 Medium 1.4 40 40 40 Medium 2.1 100 80 90 Very High 2.2 20 40 30 2.3 60 60 60 Low Medium 3.1 80 100 90 Very High 3.2 100 60 80 High 3.3 80 100 90 Very High 4.1 40 80 60 Medium 4.2 20 80 40 Low 5.1 40 100 70 High 5.2 80 80 80 High 5.3 40 100 60 Medium 5.4 60 60 60 Medium 6.1 20 60 40 Low 6.2 20 40 30 Low 6.3 40 40 40 Medium 6.4 20 20 20 Low 3.2.4 Kế hoạch xử lý rủi ro (Xử lý theo mức ưu tiên) Rating ID Very High 2.1 Action Reduced Likelihood Action Reduced Impact Action Resource Cần có người quản lý giám Project sát bảo đảm nhóm làm Manager việc thực hiển theo mơ hình mới.Đảm bảo vấn đề chuyển giao, tích hợp mơ hình Very 3.1 High Very High Ln cập nhật Khi có thay đổi công Project thông tin nghệ , rút ngắn thời Manager, cơng nghệ đưa gian hồn thiện dự án Developer dự đoán chuyển qua công nghệ trước 3.3 Tổ chức hội thảo cho phía Project khách hàng biết Manager tính mà chương trình quản lý nhà sách khác khơng có High 1.1 u cầu phía Thực buổi nói All member khách hàng có chuyện thường xuyên người am với khách hàng hiểu hệ thống để đưa yêu cầu cụ thể High 3.2 Áp dụng kỹ Cắt giảm số server không Quality thuật , yêu cần thiết việc trì Manager cầu vấn để kiểm hệ thống thử sản phẩm kỹ nhằm giảm dung lượng hệ thống High 5.2 Yêu cầu chọn Cần tổ chức training thành viên cho dự phương pháp làm việc án cần nhóm cho thành viên người có khả mới, chưa quen vơi phong làm việc theo cách làm việc nhóm nhóm High 1.2 Nhóm phân tích Nhanh chóng review lại yêu cầu pha yêu cầu nhằm so sánh với kế hoạch phải làm yêu cầu khách hàng xác High 5.1 Chỉ xét tuyển PMer có kỹ phù hợp với dự án, lựa chọn tối ưu PM Medium 2.3 nhiều Hạn chế Thường xuyên kiểm tra , thay đổi nhân thúc đẩy tiến độ làm việc, , địa điểm làm triển khai mốc để làm việc , … việc.Thực việc khen thưởng thúc đẩy làm việc nhân viên Medium 4.1 Gặp gỡ trao đổi Tăng giá thành sản phẩm với đối tác nhằm lên mức độ phù hợp với chi đạt mức phí bỏ kinh phí hợp lý Xác định rõ việc phân chia kinh phí hợp lý, đầu tư mức Medium 5.3 Cần có chế độ đãi Có nhân viên khác dự ngộ hợp lý Trả phịng cho tình xấu lương xứng đáng cho người đóng vai trị quan trọng q trình dự án phát triển Medium 5.4 Tiến hành giải vấn đề mâu thuẫn nhóm để đảm bảo tiến độ dự án thuận lợi Medium 1.3 Tư vấn đầy đủ Thiết kế lần yêu cầu thông tin cho khách hàng thành khách hàng, tránh module riêng biệt trường hợp khách hàng thay đổi yêu cầu Đồng thời có ràng buộc chắn với khách hàng điều khoản thay đổi yêu cầu Medium 6.3 Nếu cố điện ln phiên, phải triển khai làm thêm bù lúc có điện có internet Low 2.2 Nghiên cứu chi phí lợi ích cơng nghệ so với dự án Low 6.4 Mua phần mềm Khi Cty chưa kịp mua bản quyền cần quyền, tạm thời dùng thiết triển khai freeware bẻ khóa dự án thấy cần thiết thời gian tạm thời 3.2.5 Risk Process Mặc dù tạo Risk Plan từ sớm project , rủi ro xuất tiến hành dự án sau Để chắn rủi ro quản lý gây ảnh hưởng đến dự án , cần làm theo bước sau: Hoạt động - Bất kỳ người dự án (gồm coach, team leader, project owner) - phát rủi ro Risk Form sử dụng để lưu trữ rủi ro Với Risk Form, người tìm rủi ro mô tả rủi ro , đánh giá khả xảy ảnh hưởng đến dự án cách hành động làm giảm rủi ro Tất Risk Form chuyển đến Project Owner để xem xét lại - Project Owner xem lại tất rủi ro dự án xác định mức độ ưu tiên tất rủi ro Vai trị - Thành viên nhóm có trách nhiệm - Xác định rủi ro dự án hoàn chỉnh Risk Form - Gửi Risk Form trưởng nhóm - Trưởng nhóm có trách nhiệm Xem xét tất Risk Form để xác định chúng có khả ảnh hưởng đến dự án - hay không Làm việc với thành viên phát lỗi để tiếp cận hành động giảm thiểu nguy từ rủi ro - Chuyển rủi ro có mức độ ưu tiên cao đến người quản lý dự án Người quản lý dự án có trách nhiệm - Xác nhận mức độ ưu tiên Risk Form nhận Tiến hành hành động nhằm trước mắt giải tẩt rủi ro mức low medium - Tiếp cận hành động giải rủi ro mức high very high