ÔN TẬP CUỐI KỲ MÔN QUẢN LÝ DỰ ÁN PHẦN MỀM

ÔN TẬP CUỐI KỲ MÔN QUẢN LÝ DỰ ÁN PHẦN MỀM Phần mềm gì? Dự án phần mềm gì? Dự án phần mềm đến t đâu? Li ệt kê vai trò tham gia vào dự án phần mềm? Phân biệt loại k ết qu ả c m ột d ự án ph ần mềm? Liệt kê nguyên nhân thất bại dự án? Liệt kê ràng buộc m ột d ự án? Tại phải quản lý dự án phần mềm?  Phần mềm = Chương trình máy tính (hay mã nguồn) + Dữ liệu + Tài liệu hướng dẫn (mô tả hoạt động cách sử dụng chương trình)  Dự án phần mềm = Yêu cầu, phạm vi + Ngày bắt đầu, ngày kết thúc + Ngân sách + Chi phí + Lịch trình dự án  Là hành động tạm thời, tạo sản phẩm/dịch vụ/kết Dự án phần mềm = “Đau” + “Sợ” + “Hạnh phúc” Có loại dự án phần mềm chính: Dự án phát triển phần mềm mới, nâng cấp phần mềm có sẵn, sửa chữa phần mềm cũ  Dự án phần mềm đến từ: - Yêu cầu khách hàng - Các vấn đề thực tiễn - Các tài liệu, sách - Ý tưởng  Các vai trò tham gia vào dự án phần mềm: - Khách hàng yêu cầu làm sản phẩm phần mềm - Nhóm phát triển phần mềm - Trưởng dự án - Người dùng cuối  Phần biệt loại kết dự án phần mềm: - Thành cơng (Success): Là dự án hồn thành thời hạn, phạm vi ngân sách với đầy đủ chức yêu cầu - Thách thức (Challenged): Là dự án hồn thành, hoạt động vượt phạm vi ngân sách, bị trễ so với thời hạn cam kết v ới số ch ức yêu cầu - Thất bại (Failure): Là dự án bị huỷ bỏ chừng trước hoàn thành dự án không thực  Quản lý dự án phần mềm để giảm thiểu rủi ro tăng hội thành công cho dự án  Những nguyên nhân gây thất bại cho dự án - Con người - Không nắm yêu cầu - Không quản lý rủi ro - Dự án không tuân theo quy trình - Dự án tuân theo quy trình cách cứng nhắc - Hiệu chỉnh nhiều sử dụng thành phần có sẵn  Các ràng buộc dự án phần mềm: - Phạm vi dự án (Scope) - Lịch trình dự án (Schedule) - Chi phí dự án (Cost) - Nguồn tài nguyên nhân lực (Resources) - Rủi ro (Risk) - Chất lượng dự án (Quality) Liệt kê câu hỏi cần trả lời quản lý dự án phần m ềm? Li ệt kê pha chu trình sống phần mềm Liệt kê hoạt động chính, sản phẩm đầu vào đầu pha, vai trò tham gia vào pha, lý cần thực pha?  Các câu hỏi cần trả lời quản lý dự án phần mềm: - Which step should we next? (Tiếp theo nên làm đến bước nào?) - How long will it take? (Làm bao lâu?) - How to perform the step? (Làm để thực bước này?) - Which artifacts will it produce? (Sản phẩm phụ tạo bước này?) - Who is responsible for doing the step? (Ai người thực bước này?)  Các pha chu trình sống phần mềm: Software Project Planning - Hoạt động chính: Lập kế hoạch cho dự án phần mềm để định có thực dự án hay không - Đầu vào: Yêu cầu từ khách hàng/người dùng - Đầu ra: Tài liệu khái niệm, Kế hoạch dự án, Executive Summary, Project Vision, Project Charter,… - Vai trò tham gia: Users, Clients, Project Manager, Business Analyst, Technical Architect Software Requirements - Hoạt động chính: Gợi ý, phân tích, xác nhận quản lý u cầu, mơ hình hố hệ thống… - Đầu vào: Glossary, Business Rules, Domain Models, Executive Summary, Project Vision, Project Charter, Functional Requirement Specification, Supplementary Specification - Đầu ra: Product Backlog, User Stories, Work Breakdown Structure (WBS), Proof of Concept, Prototype - Vai trò tham gia: Business Analyst, Users, Project Manager Software Design - Hoạt động chính: Lập kế hoạch giải vấn đề phần mềm bao gồm thành phần cấp thấp, thuật toán triển khai quan điểm kiến trúc phần mềm - Đầu vào: Product Backlog, User Stories - Đầu ra: Architectural Design Specification, Detailed Design Specification, GUI - Vai trò tham gia: Technical Architect, Designer, Developer Software Construction (Implementation) - Hoạt động chính: Xây dựng phần mềm ngơn ngữ lập trình - Đầu vào: Product backlog, Architectural design specification, Detailed design specification, Release Plan, Development Plan, Integration Plan - Đầu ra: Code File, Unit Tests, Module, Product - Vai trị tham gia: Developer, Technical Architect • Software Inspection - Hoạt động chính: Thanh tra mã nguồn tìm kiếm khuyết liên quan đến cú pháp - Đầu vào: Code File - Đầu ra: Bugs, Convention Issues • • • - Vai trị tham gia: Technical Architect, Developer Software Testing - Hoạt động chính: Kiểm thử hệ thống phần mềm cung cấp cho bên liên quan thông tin chất lượng sản phẩm/dịch vụ liên quan đến bối c ảnh mà phần mềm dự định vận hành - Đầu vào: Test Plan, Test Data, User Guide, Chương trình thực thi c s ản phẩm phần mềm - Đầu ra: Test Result - Vai trò tham gia: QA/QC, Tester Acceptance Testing - Hoạt động chính: Kiểm thử chấp nhận nhằm kiểm tra xem sản phẩm phần mềm làm có đáp ứng yêu cầu người dùng hay không - Đầu vào: Acceptance Test Plan, Test Result - Đầu ra: System Delivery - Vai trò tham gia: Users, Clients, Supporter, Development Team Software Operation & Maintenance - Hoạt động chính: Các phần mềm thường xảy vấn đề cần cải ti ến, bảo trì, khắc phục lỗi phần mềm thời gian dài sau tri ển khai - Vai trò tham gia: Users, Clients, Supporters, Development Team Chu kỳ sống trình phát triển phần mềm (SDLC) gì? Mơ hình chu kỳ s ống c q trình phát triển phần mềm (SDLC model) gì? Phân bi ệt mơ hình miêu t ả (descriptive model) mơ hình quy định (prescriptive model) Liệt kê thành phần mơ hình chu kỳ sống c trình phát tri ển ph ần m ềm Tại lại cần mơ tả mơ hình chu kỳ sống trình phát triển phần m ềm cho d ự án? Vẽ gi ải thích mơ hình chu kỳ sống trình phát triển phần mềm NASA  Chu kỳ sống trình phát triển phần mềm (SDLC) tất giai đoạn (bao gồm q trình lập kế hoạch, thực hố, kiểm thử, tri ển khai) mà m ột sản ph ẩm ph ần mềm phát triển, tiến hố  Mơ hình chu kỳ sống trình phát tri ển phần m ềm (SDLC model) khuôn khổ khái niệm mô tả cách mà dự án phần mềm phát triển - Phân tích kế hoạch yêu cầu Xác định yêu cầu Thiết kế kiến trúc sản phẩm Xây dựng, phát triển sản phẩm Kiểm thử     - Triển khai bảo trì Các thành phần mơ hình chu kỳ sống gồm: - Activity: Tạo thay đổi trạng thái nhìn thấy bên ngồi s ản ph ẩm phần mềm - Artifact/Product: Sản phẩm phụ quy trình trình phát tri ển sản phẩm phần mềm - Agent/Actor: Tác nhân thực quy trình cụ thể - Role: Tập hợp tác nhân/nhóm có trách nhiệm, quy ền kỹ c ần thi ết để thực quy trình Phân biệt mơ hình miêu tả, mơ hình quy định, mơ hình tính tốn - Mơ hình miêu tả (descriptive model): Mơ tả lịch sử cách mà hệ thống phần mềm cụ thể trước phát triển - Mơ hình quy định (prescriptive model): Quy định cách thức mà hệ thống phần mềm nên phát triển - Mơ hình tính tốn (proscriptive model): Quy định cách thức mà hệ thống phần mềm phát triển Cần mơ tả mơ hình chu kỳ sống trình phát tri ển phần m ềm cho d ự án mơ hình chu kỳ sống: - Mơ tả hệ thống phần mềm đến từ đâu - Thiết lập khuôn khổ để xây dựng, thực tăng cường cho hệ thống phần mềm mà tất nhân viên tham gia dự án phải tuân theo - Phác thảo quy tắc để tạo sản phẩm cần thiết giao cho khách hàng - Là sở để xác định kỹ thuật, công cụ, phương pháp phù hợp cho t ừng giai đoạn thực dự án - Là khn khổ để phân tích, ước tính, phân bổ tiêu thụ tài nguyên t ừng giai đoạn thực dự án - Là sở để tổ chức, lập kế hoạch, phân công nhân viên, dự tính ngân sách, l ập lịch biểu quản lý dự án - Là sở cho nghiên cứu xác định rủi ro, chi phí chất lượng dự án Vẽ giải thích mơ hình chu kỳ sống trình phát tri ển phần mềm c NASA - - - - - Phân tích yêu cầu (Requirements Analysis): Trải dài suốt trình làm dự án  Làm nhiều giai đoạn đoạn đầu  Giảm dần từ giai đoạn Thiết kế sơ (Preliminary Design) đến gđ Kiểm thử chấp nhận (Acceptance Test) Thiết kế (Design): Trải dài suốt trình làm dự án  Bắt đầu gđ Phân tích yêu cầu  Làm nhiều gđ Thiết kế sơ (Preliminary Design) Thiết kế chi tiết (Detailed Design)  Giảm dần từ gđ Hiện thực hoá hệ thống (Implementation) đến Kiểm thử chấp nhận (Acceptance Test) Hiện thực hoá dự án (Implementation): Trải dài suốt trình làm dự án  Bắt đầu từ gđ Phân tích yêu cầu  Tăng dần làm nhiều gđ Hiện thực hoá (Implementation)  Giảm dần gđ Kiểm thử hệ thống Kiểm thử chấp nhận Kiểm thử hệ thống (System Test):  Bắt đầu từ gđ Thiết kế chi tiết  Làm nhiều gđ Hiện thực hoá Kiểm thử hệ thống  Giảm dần gđ Kiểm thử chấp nhận Kiểm thử chấp nhận (Acceptance Test)  Bắt đầu gđ Hiện thực hoá  Tăng dần làm nhiều gđ Kiểm thử chấp nhận Vẽ giải thích mơ hình chu kỳ sống việc phát tri ển ph ần m ềm cho m ột d ự án đ ược thực dựa theo mơ hình thác nước WATERFALL Winston Royce 14 tuần Liệt kê vai trị sản phẩm mơ hình Giải thích ưu khuy ết ểm c mơ hình Liên hệ đồ án nhóm • • • • • • • • Requirements: Lấy yêu cầu, lên ý tưởng cho dự án Vai trò: Users, Clients, Project Manager, Business Analyst, Technical Architect Sản phẩm: Kế hoạch dự án, Executive Summary, Project Vision, Project Charter, WBS, Product Backlog, User Stories, Proof of Concept, Prototype,… Design: Phân tích, thiết kế cho hệ thống Vai trò: Technical Architect, Designer, Developer Sản phẩm: Architectural Design Specification, Detailed Design Specification, GUI Implementation/Coding: Hiện thực hố hệ thống ngơn ngữ lập trình Vai trị: Technical Architect, Developer Sản phẩm: Code File, Unit Test, Product Verification/Testing: Kiểm thử hệ thống kiểm thử chấp nhận Vai trò: QA/QC, Tester, Users, Clients, Supporter, Development Team Sản phẩm: Test Result Maintenance: Triển khai, sửa chữa bảo trì Vai trị: Users, Clients, Supporter, Development Team Sản phẩm: Hệ thống phần mềm sửa chữa, bảo trì Ưu điểm: • Dễ sử dụng quản lý • Là mơ hình có kỷ luật giúp giảm thiểu rủi ro • Địi hỏi cao tài liệu • Thích hợp áp dụng cho dự án có u cầu, giải pháp rõ ràng Khuyết điểm: • Khó quản lý có thay đổi xảy • Các bên liên quan phải đợi đến giai đoạn cuối thấy sản phẩm • Khó khăn việc xác định xác yêu cầu khách hàng giai đo ạn đ ầu c dự án Liên hệ đồ án nhóm:  Nhóm khơng chọn mơ hình WATERFALL dự án nhóm làm có u cầu dự án thay đổi để kịp tiến độ giải pháp cụ thể để thực hi ện dự án cần nhóm tìm hiểu kỹ  Nhóm chọn hiệu chỉnh lại mơ hình SCRUM để thực dự án, với (A – Tên thành viên nhóm) Product Owner, (B, C, D) Business Analyst Database Analyst, (E, F, G, H, I, J, K) Development Team  Các sản phẩm mà nhóm khởi tạo 14 tuần: - Executive Summary (Tóm tắt thực thi) - Project Vision (Viễn cảnh dự án) - Product Backlog - Software Process Definition (Định nghĩa quy trình) - Proof of Concept - Tài liệu ước tính ngân sách, chi phí dự án - Release Planning - High-level Architecture - Báo cáo tình trạng dự án - Timesheet - Mã nguồn - Tài liệu hướng dẫn Vẽ giải thích mơ hình chu kỳ sống việc phát tri ển ph ần m ềm cho m ột d ự án đ ược thực dựa theo mơ hình RUP 14 tuần Liệt kê vai trò sản phẩm mơ hình Giải thích ưu khuyết điểm mơ hình Liên hệ đồ án nhóm • • • Inception: Mơ hình hố nghiệp vụ, thu thập u cầu, phân tích thi ết kế  Xác định phạm vi hệ thống làm sở để ước tính chi phí ban đầu Vai trị: Users, Clients, Project Manager, Business Analyst, Technical Architect Sản phẩm: Kế hoạch dự án, Executive Summary, Project Vision, Project Charter, WBS, Product Backlog, User Stories, Proof of Concept, Prototype,… Elaboration: Phân tích, thiết kế cho hệ thống  Giảm thiểu rủi ro trình thực dự án Vai trò: Technical Architect, Designer, Developer Sản phẩm: Architectural Design Specification, Detailed Design Specification, GUI, Data Model, Design Layer, Implementation Resource Documentation,… Construction: Hiện thực hoá hệ thống ngơn ngữ lập trình tiến hành kiểm thử • • • Vai trị: Technical Architect, Developer Sản phẩm: Code File, Unit Test, Product, Test Result Transition: Triển khai hệ thống, đào tạo, hướng dẫn sử dụng cho khách hàng Vai trò: QA/QC, Users, Clients, Supporter, Development Team Sản phẩm: Product Ưu điểm: • Thường xuyên nhận phản hồi từ bên liên quan • Sử dụng tài nguyên dự án cách hiệu • Cải thiện quản lý rủi ro • Cung cấp xác khách hàng muốn • Các vấn đề xảy dự án phát sớm • Hỗ trợ mơ hình phát triển lặp Khuyết điểm: • Các tiến trình dự án phức tạp, nặng nề • Q trình phát triển vượt q tầm kiểm soát (do đánh giá sai v ề chi phí, tài ngun, rủi ro từ đầu) • Cần người có kinh nghiệm thực mơ hình • Liên hệ đồ án nhóm: Tương tự với phần WATERFALL Vẽ giải thích mơ hình chu kỳ sống việc phát tri ển ph ần m ềm cho m ột d ự án đ ược thực dựa theo mơ hình SCRUM 14 tuần Liệt kê vai trị sản phẩm mơ hình Liệt kê ưu khuyết điểm mơ hình Liên hệ đồ án nhóm • • Sprint: Là khoảng thời gian (khoảng từ – tuần) để tạo phần tăng trưởng phần mềm chuyển giao Vai trò: Product Owner, Development Team Sản phẩm: Sản phẩm bao gồm phần chức chuyển giao Sprint Planning Meeting: Họp kế hoạch Sprint để thống chức làm Sprint Vai trị: Product Owner, Scrum Master, Development Team Sản phẩm: Sprint Goal, Sprint Planning, Sprint Backlog • • • • • • Daily Scrum: Họp Scrum hẳng hàng (khoảng 15’) để Development Team đồng hoá hoạt động thành viên lên kế hoạch cho 24h Vai trò: Scrum Master, Development Team Sprint Review: Rà soát lại phần tăng trưởng vừa làm Sprint th ực hi ện biện pháp thích nghi Product Backlog cần Vai trò: Product Owner, Scrum Master, Development Team bên liên quan Sản phẩm: Product Backlog cập nhật, với hạng m ục dự định đ ược triển khai Sprint tới Sprint Retrospective: Development Team tự tra đưa kế hoạch cho cải tiến Sprint Vai trò: Scrum Master, Development Team Sản phẩm: Các cải tiến triển khai Sprint tới Ưu điểm: • Thường xuyên nhận phản hồi từ bên liên quan • Thích nghi tốt có thay đổi xảy • Thích hợp áp dụng dự án có u cầu khơng rõ ràng khơng rõ gi ải pháp • Giảm thiểu rủi ro • Cung cấp xác khách hàng muốn Khuyết điểm: • Các thành viên dự án làm mơ hình SCRUM phải có trình đ ộ chun mơn cao mơ hình WATERFALL RUP Liên hệ đồ án nhóm:  Nhóm chọn hiệu chỉnh lại mơ hình SCRUM để thực dự án, với (A – Tên thành viên nhóm) Product Owner, (B, C, D) Business Analyst Database Analyst, (E, F, G, H, I, J, K) Development Team  Các sản phẩm mà nhóm khởi tạo 14 tuần: - Executive Summary (Tóm tắt thực thi) - Project Vision (Viễn cảnh dự án) - Product Backlog - Software Process Definition (Định nghĩa quy trình) - Proof of Concept - Tài liệu ước tính ngân sách, chi phí dự án - Release Planning - High-level Architecture - Báo cáo tình trạng dự án - Timesheet - Mã nguồn - Tài liệu hướng dẫn Liệt kê câu hỏi cần trả lời tài liệu tóm tắt th ực thi (Executive Summary) , bước cần thực để viết tài liệu tóm tắt thực thi Tại cần tạo tài liệu tóm tắt thực thi? Minh hoạ tài liệu tóm tắt thực thi nhóm  Các câu hỏi cần trả lời Executive Summary • Tại cần làm dự án này? • Các vấn đề cần giải dự án?   • • Trường hợp nghiệp vụ (Business Case) dự án? • Mục đích dự án? • Thị trường mục tiêu? Các bước để viết Executive Summary • Bước 1: Xác định vấn đề dự án • Bước 2: Thể hiểu biết bạn vấn đề • Bước 3: Đưa giải pháp mà theo bạn tối ưu cho vấn đề • Bước 4: Chứng minh nhóm phát triển bạn hồn tồn có kh ả làm dự án • Bước 5: Chứng minh cho khách hàng thấy bạn đối tác thích hợp họ Lý cần tạo Executive Summary • Là tài liệu mà khách hàng đọc • Cung cấp cho khách hàng nhìn tổng quan dự án l ợi ích mà d ự án mang lại • Là tài liệu quan trọng khơi gợi quan tâm ảnh hưởng đến quy ết định đầu tư vào dự án hay từ bỏ dự án khách hàng Liên hệ đồ án nhóm: Executive Summary nhóm gồm thành phần sau: - Thơng tin nhóm thực dự án - Đưa vấn đề cần giải dự án: Một số công ty/doanh nghiệp khơng trọng việc xây dựng riêng cho trang web chăm sóc, hỗ trợ khách hàng Khách hàng c nh ững công ty/doanh nghiệp cần có kênh hỗ trợ q trình sử dụng sản phẩm mà phải liên hệ đâu - Đưa giải pháp tối ưu cho vấn đề: Cần có website làm trung gian cung cấp dịch vụ cho công ty/doanh nghiệp tư vấn, hỗ trợ khách hàng họ Giúp công ty/doanh nghi ệp ti ết kiệm khoảng chi phí cho việc xây dựng website riêng giúp họ yên tâm kinh doanh - Thể nhóm đối tác tiềm công ty/doanh nghi ệp h ọc muốn thực dự án Liệt kê câu hỏi cần trả lời tài liệu viễn cảnh d ự án (Project Vision), bước cần thực để viết tài liệu viễn cảnh dự án Tại cần t ạo tài li ệu vi ễn cảnh dự án?  Các câu hỏi cần trả lời Project Vision • Sản phẩm mà khách hàng cần gì? • Những cần chuyển giao cho khách hàng? • Quy trình để thực dự án? • Mục tiêu dự án gì? • Dự án có tính gì?  Các bước để viết Project Vision • Bước 1: Xác định hội kinh doanh dự án • Bước 2: Xác định vấn đề • Bước 3: Xác định bên liên quan người dùng • Bước 4: Tóm tắt nhu cầu bên liên quan người dùng • Bước 5: Phát triển tổng quan sản phẩm • Bước 6: Xác định tính sản phẩm • Áp dụng công nghệ, sáng tạo   Vẽ tháp Maslow? Làm áp dụng tháp Maslow đ ể tạo đ ộng l ực làm vi ệc cho nhóm?     Xác định thành viên nhóm tầng thứ c tháp Maslow để đưa đề nghị, khuyến khích, phần thưởng tầng cao tầng mà thành viên có nhằm tạo động lực làm việc cho họ   Giải thích phương pháp tạo động làm việc cho thành viên t ph ần th ưởng n ội (Intrinsic Rewards) thay phần thưởng từ bên (Extrinsic Rewards) - Phần thưởng nội (Intrinsic Rewards): Là phần thưởng mặt tinh thần hoàn thành cơng việc (Bản thân bạn cảm thấy vi ệc quan tr ọng, h ữu ích ho ặc thể bạn làm việc để đóng góp cho điều tốt đẹp) - Phần thưởng từ bên (Extrinsic Rewards): Là phần thưởng vật chất mà bạn nhận hồn thành cơng việc - Việc tạo động làm việc cho thành viên phần th ưởng t bên có th ể hữu ích thúc đẩy thành viên làm vi ệc ều không nuôi d ưỡng văn hoá hợp tác, gắn kết lâu dài Động lực làm việc liên quan đến phần th ưởng t bên ngồi thường khơng bền vững  Nếu bạn muốn thành viên sẵn sàng, tích cực tham gia công vi ệc c ả không nhận phần thưởng, bạn cần khai thác giá trị n ội t ại – nh ững giá tr ị mạnh mẽ phần thưởng vật chất như: Những điều thuộc cảm giác, Sự tự hào, Hạnh phúc,…  29 Quản lý cấu hình phần mềm gì? Đối tượng cấu hình ph ần mềm gì? Li ệt kê đ ặc tính đối tượng cấu hình Đối tượng chuẩn (baseline) gì? Đ ối t ượng chuy ển giao gì? Cột mốc gì? Bản phân phối (Release) gì? T ại c ần qu ản lý c ấu hình? Cho ví dụ vấn đề xảy dự án khơng có quản lý cấu hình  Quản lý cấu hình phần mềm (Software Configuration Management – SCM ho ặc CM) khuôn khổ tổ chức, quy luật để quản lý, tổ chức, kiểm soát m ột cách có h ệ         thống thay đổi tài liệu, mã nguồn, hệ thống máy tính th ực th ể khác Vòng đời phát triển phần mềm Đối tượng cấu hình phần mềm đối tượng điện tử đối tượng vật lý Các đặc tính đối tượng cấu hình: - Đối tượng điện tử: Là điện tử, lưu trữ điện tử dễ dàng sản xuất với số lượng không giới hạn - Đối tượng vật lý: Là đối tượng giao, số lượng có hạn, khơng thể lưu trữ máy tính phải lưu trữ nơi vật lý Đối tượng chuẩn (Baseline) phiên thức chấp nhận mục c ấu hình phần mềm Nó định cố định thời điểm cụ thể ti ến hành quy trình SCM Đối tượng chuẩn thay đ ổi thông qua th ủ t ục kiểm sốt thay đổi thức Đối tượng chuyển giao (Deliveries) hệ thống phân cấp mục cấu hình Cột mốc thời điểm cụ thể liên quan đến kết định Bản phân phối (Release) phân phối sản phẩm phần mềm máy tính ban đầu nâng cấp (mã nguồn, tài liệu, liệu cấu hình,…) Tại cần quản lý cấu hình: - Quản lý cấu hình nhằm mục đích kiểm sốt chi phí n ỗ l ực làm vi ệc liên quan đến việc thay đổi hệ thống phần mềm - Giúp tăng suất với sai lầm tối thiểu - Giúp đồng hoá kiểm soát phiên cập nhật Các vấn đề xảy dự án khơng có quản lý cấu hình: - Khơng thích ứng kịp thời dự án có thay đổi yêu cầu, thành viên, luật pháp, … - Khơng thể kiểm sốt xác chi phí nỗ lực làm việc nhóm - Vấn đề đồng hố phần mềm cục bộ, cập nhật thay đ ổi đ ược thực thành viên khác nhóm   Liên hệ đồ án nhóm: Các vật chuẩn phân phối nhóm thực   Sprint  Vật chuẩn  Bản phân phối - Executive Summary - Mã nguồn gồm chức - Project Vision Đăng nhập, Đăng ký  - Software Process Definition - Unit test - Product Backlog - High-level Architecture - Product Backlog (cập nhật) - Mã nguồn gồm chức - Release Plan Đăng nhập, Đăng ký, Giao diện  - Task Board (Danh sách mail, Nội dung mail, - Ngân sách dự tính Trả lời mail, Chat) - Phân tích chi phí – lợi nhuận - Unit test - Báo cáo tính trạng dự án - Mã nguồn gồm chức - Timesheet Đăng nhập, Đăng ký, Xem danh  - Release Plan (cập nhật) sách mail, Xem nội dung mail, - Product Backlog (cập nhật) Trả lời mail, Giao diện Chat - Unit test  - Product Backlog (cập nhật) - Mã nguồn gồm chức - Clip demo - Hướng dẫn sử dụng - Báo cáo tổng kết dự án Đăng nhập, Đăng ký, Xem danh sách mail, Xem nội dung mail, Trả lời mail, Chat socket, Realtime - Unit test  30 Giải thích cách thực hoạt động định danh, xác định cấu trúc th m ục, xác đ ịnh vật chuẩn, thiết lập mơi trường tương tác, thiết lập hệ thống cấu hình, v ận hành h ệ thống cấu hình, kiểm sốt thay đổi vật chuẩn, báo cáo tr ạng thái c v ật chu ẩn, tra chức tra vật lý vật chuẩn, quản lý chuyển giao phiên bản, lưu dự phòng (backup) lưu trữ (archive) liệu  Xác định cấu trúc thư mục - Xác định số lượng file, thư mục - Thống định danh (cách đặt tên, đánh số file, thư mục, phần m rộng,… dự án) - Xác định quan hệ file, thư mục (file nằm thư mục nào)  Xác định vật chuẩn - Chọn tài liệu, sản phẩm làm vật chuẩn - Xác định vật chuẩn thay đổi chấp nhận phê chuẩn  Thiết lập môi trường tương tác - Xác định môi trường tương tác dự án - Mô tả môi trường tương tác - Thiết lập môi trường  Thiết lập vận hành hệ thống cấu hình - Mơ tả công cụ p.mềm thủ tục, quy trình sử dụng - Mơ tả vị trí máy chủ, cấu hình hệ thống - Thiết lập hệ thống - Vận hành hệ thống  Kiểm soát thay đổi vật chuẩn - Nghiên cứu, phân tích thay đổi - Thơng báo với bên có liên quan việc thay đổi vật chuẩn - Phê chuẩn/Không phê chuẩn thay đổi - Thực việc thay đổi - Kiểm tra thay đổi - Xác lập vật chuẩn  Báo cáo trạng thái vật chuẩn - Liệt kê tất vật chuẩn sản phẩm trung gian, file, th m ục có liên quan - Làm bật sản phẩm trung gian, file, tài li ệu đ ược phát tri ển ho ặc vừa bị thay đổi - Liệt kê thay đổi dang dở, vật chuẩn bị ảnh hưởng  Thanh tra chức năng, tra vật lý vật chuẩn - Kiểm tra chức - Kiểm tra thiết kế - Kiểm tra yêu cầu khách hàng - Đảm bảo vật chuẩn, file, thư mục liệt kê đầy đ ủ báo cáo v ật chuẩn  Quản lý chuyển giao phiên - Xác định vật chuẩn môi trường phát triển sản phẩm file, tài li ệu release - Thực báo cáo trạng thái vật chuẩn - Kiểm tra, xác định yêu cầu khách hàng có thực hay không - xác định yêu cầu khách hàng có ki ểm tra sản ph ẩm chuy ển giao hay khơng - Đóng gói file tài liệu release - Xác nhận release từ khách hàng  Sao lưu dự phòng (Backup) lưu trữ liệu (Archive) - Thực lưu toàn liệu dự án, tuân thủ quy trình l ưu tr ữ thiết lập - Lưu trữ huỷ bỏ tài liệu giấy - Dọn liệu thông tin dự án vừa kết thúc sau lưu xong   Liên hệ đồ án nhóm: Nhóm sử dụng số cơng cụ: - Quản lý cấu hình: Github - Quản lý công việc: Trello - Liên lạc thành viên: Facebook Messenger - Quản lý yêu cầu dự án: Github - Quản lý lỗi phần mềm dự án: Trello  31 Rủi ro gì? Tại cần quản lý rủi ro? Li ệt kê ph ương pháp xác đ ịnh r ủi ro c dự án Phân tích rủi ro gì? Liệt kê đặc tính m ột r ủi ro Gi ải thích ph ương pháp xác định độ ưu tiên cho rủi ro  Rủi ro việc xảy tương lai thời ểm làm ảnh hưởng đến dự án  Rủi ro xác suất mát theo đuổi mục tiêu y ếu t ố khơng thể đốn trước  Quản lý rủi ro cách tiếp cận có hệ thống để gi ảm tác hại r ủi ro, làm cho d ự án bị tổn thương sản phẩm mạnh mẽ  Quản lý rủi ro thực để: - Cải thiện quản trị kiểm soát rủi ro dự án - Giảm tổn thất tác động rủi ro mục tiêu - Tuân thủ pháp luật yêu cầu quy định  Các phương pháp xác định rủi ro: - Tổ chức họp đúc kết kinh nghiệm - Động não:  Phân loại rủi ro  Phân tích đường dẫn quan trọng  Phỏng vấn  Phân tích giả định - So sánh dự án khứ  Phân tích rủi ro phép đo khoa học mức độ nguy hi ểm liên quan đ ến b ất kỳ ho ạt động trình thực dự án  Các đặc tính rủi ro: Xác suất (tỷ l ệ %), Thời ểm có th ể x ảy Tác đ ộng (Mức độ ảnh hưởng) rủi ro  Phương pháp xác định độ ưu tiên cho rủi ro:  Độ ưu tiên rủi ro = Xác suất rủi ro * Tác động (Mức độ ảnh hưởng)  Rủi ro có tích xác suất tác động l ớn r ủi ro có đ ộ ưu tiên cao nh ất Rủi ro khơng có khả xảy khơng có tác đ ộng l ớn có đ ộ ưu tiên th ấp   Liên hệ đồ án nhóm: Danh sách rủi ro xếp theo mức độ ưu tiên nhóm tạo cho dự án   ST  Xác suất  Rủi ro T (%)  Dự án làm không đáp ứng yêu cầu   70 khách hàng  Dự án sử dụng nhiều công nghệ mà   65 thành viên chưa dùng qua  Một số thành viên làm thực tế quỹ   60 thời gian dành cho dự án hạn hẹp  Một số thành viên nhiều ngơn   50 ngữ lập trình sử dụng dự án  Trên thị trường có website chăm sóc   50 khách hàng với dịch vụ tương tự  Có chen ngang dự án khác thực   40 dự án  Các thành viên gặp phải vấn đề hư hỏng   40 phần cứng, liệu,…  Nhóm có nhiều ý kiến cho việc lựa chọn ngôn   30 ngữ thực dự án  Lúng túng việc phân công công việc   30 lần đầu làm việc với nhóm lớn  Các thành viên khơng có thời gian tham gia đầy  10  20 đủ cac lần họp nhóm  32 Liệt kê loại phản ứng trước rủi ro Liệt kê phương pháp để giảm r ủi ro đ ối phó với việc thiếu kinh nghiệm cơng nghệ kỹ thuật, đ ối phó v ới yêu c ầu thường thay đổi không rõ ràng, đ ối phó v ới l ịch trình khơng th ực t ế, đ ối phó với tinh thần động làm việc thấp thành viên  Các loại phản ứng trước rủi ro: - Chấp nhận: Thừa nhận rủi ro tồn tại, khơng có hành động gi ải quy ết r ủi ro, có kế hoạch dự phòng - Tránh: loại bỏ điều kiện làm cho rủi ro xảy cách b ỏ d ự án bỏ công việc - Chuyển giao: Thuê người khác làm thay - Giảm thiểu xác suất rủi ro xảy  Các phương pháp để giảm thiểu rủi ro: - Khi đối phó với việc thiếu kinh nghiệm cơng nghệ kỹ thuật:  Lập dự toán với việc dành thời gian học ban đầu  Duy trì khoản tài nguyên bổ sung  ST  T    Xác định chương trình đào tạo dành riêng cho dự án  Tiến hành đào tạo chéo - Khi đối phó với yêu cầu thường thay đổi không rõ ràng:  Sử dụng kinh nghiệm logic để đưa số gi ả định thông báo cho khách hàng  Phát triển nguyên mẫu có yêu cầu khách hàng xem xét  Thuyết phục khách hàng thay đổi yêu c ầu ảnh hưởng đến lịch trình  Xác định quy trình xử lý thay đổi yêu cầu  Đàm phán toán nỗ lực thực tế - Khi đối phó với lịch trình khơng thực tế:  Đàm phán với khách hàng để có lịch trình tốt  Xác định nhiệm vụ song song  Có tài nguyên sẵn sàng sớm  Xác định thành phần tự động hố, thành phần COTS  Thương lượng với khách hàng chuỗi bước thực quan trọng dự án khơng nằm lịch trình  Đàm phán tốn nỗ lực thực tế - Khi đối phó với tinh thần động làm việc thấp thành viên:  Có buổi xây dựng đội nhóm (Team-building)  Luân chuyển công việc thành viên nhóm  Dự trữ tài ngun dự phịng  Duy trì tài liệu phù hợp cơng việc cho thành viên  Tuân thủ nghiêm ngặt quy trình quản lý cấu hình hướng dẫn - Khi đối phó với việc khơng đáp ứng u cầu hiệu suất:  Xác định tiêu chí hiệu suất rõ ràng khách hàng xem xét  Xác định tiêu chuẩn phải tuân theo để đáp ứng tiêu chí hi ệu suất  Chuẩn bị thiết kế để đáp ứng tiêu chí hi ệu suất xem xét thi ết k ế  Mơ nguyên mẫu thực giao dịch quan trọng  Kiểm tra với khối lượng liệu đại diện  Tiến hành kiểm tra căng thẳng (Stress)  Liên hệ đồ án nhóm: Danh sách phản ứng nhóm chuẩn bị cho rủi ro   Rủi ro  Giải pháp  Dự án làm không đáp ứng - Cần chuẩn bị prototype minh hoạ chức yêu cầu khách hàng cho khách hàng - Có dự án mẫu tương tự với yêu cầu khách hàng làm demo  Dự án sử dụng nhiều cơng nghệ mà - Họp nhóm phân cơng cơng việc tìm hiểu thành viên chưa dùng qua cơng nghệ chia sẻ tìm hiểu cho thành viên khác     Một số thành viên làm thực tế - Các thành viên chậm trễ thời gian hoàn quỹ thời gian dành cho dự án hạn hẹp thành công việc cần phản hồi lại với team leader để leader xếp thêm người hỗ trợ  Một số thành viên nhiều - Với thành viên biết trước ngôn ngữ làm trước vài phần ngôn ngữ lập trình sử dụng dự án - Với bạn chưa biết ngôn ngữ cho bạn tuần tìm hiểu lúc làm bạn thành thạo ngôn ngữ hỗ trợ  Trên thị trường có website chăm - Họp nhóm tìm điểm khác biệt sóc khách hàng với dịch vụ tương tự dự án với website có sẵn để đề chiến lược cụ thể     Có chen ngang dự án khác - Có phân chia hợp lý thời gian để thực thực dự án dự án  Các thành viên gặp phải vấn đề hư - Yêu cầu thành viên nhóm thường hỏng phần cứng, liệu,… xuyên update phần làm lên Github dự án để giảm thiểu rủi ro  Nhóm có nhiều ý kiến cho việc lựa chọn ngôn ngữ thực dự án - Tổ chức họp nhóm tiến hành biểu để thống ngôn ngữ sử dụng  Lúng túng việc phân công công việc - Team leader cần tìm hiểu kinh nghiệm từ tài liệu tham khảo anh chị khoá lần đầu làm việc với nhóm lớn trước  - Dựa vào khả kinh nghiệm làm việc thành viên loại công việc để có phân cơng thích hợp  Các thành viên khơng có thời gian tham - Team leader tạo kênh liên lạc Facebook để phổ biến lại nội dung họp gia đầy đủ lần họp nhóm  10 - Đầu học hàng ngày leader trao đổi lại nội dung họp với thành viên vắng mặt họ đến lớp   33 Giải thích phương pháp phân tích để lựa chọn giải pháp nhi ều gi ải pháp đ ối phó với rủi ro phương pháp định K ế ho ạch qu ản lý r ủi ro gì? Liệt kê nội dung kế hoạch quản lý r ủi ro Gi ải thích ho ạt đ ộng cần thực quản lý rủi ro  Cây định (Decision Tree) đại diện theo thời gian trình quy ết đ ịnh Nó sử dụng mạng gồm loại nút: - Các nút định (nút lựa chọn) biểu thị hình vng - Trạng thái nút tự nhiên (nút hội) biểu thị vòng tròn  Phương pháp định: - Vẽ định cách sử dụng hình vng để thể quy ết định vịng trịn để đại diện cho khơng chắn - Đánh giá định để đảm bảo tất kết có đ ều đ ược bao phủ - Tính tốn giá trị làm việc từ phải sang trái (từ nút đến nút gốc) - Tính giá trị nút kết không chắn = Giá tr ị k ết qu ả * Xác su ất chúng - Chọn giải pháp có chí phí thấp   Kế hoạch quản lý rủi ro đưa phương án, kế hoạch để gi ải quy ết t ừng m ục rủi ro (kế hoạch phòng tránh rủi ro, kế hoạch gi ảm r ủi ro,…), bao gồm c ả s ự ph ối h ợp kế hoạch rủi ro thành phần với với kế hoạch dự án tổng thể Các nội dung kế hoạch quản lý rủi ro: - Mục tiêu (Câu hỏi “WHY”) - Các sản phẩm cột mốc (Câu hỏi “WHAT” “WHEN”) - Trách nhiệm cá nhân(Câu hỏi “WHO” WHERE”) - Cách tiếp cận (Câu hỏi “HOW”) - Tài nguyên (Câu hỏi “HOW MUCH”) Các hoạt động cần thực quản lý rủi ro: - Nhận diện rủi ro: Xác định nguồn phát sinh rủi ro - Phân tích phân loại rủi ro: Phân tích lựa chọn rủi ro cần gi ải - Kiểm soát rủi ro: Lựa chọn chiến lược phương pháp đối phó rủi ro - Sử dụng định: Trong trường hợp khó xác định độ ưu tiên rủi ro để kiểm sốt khó đưa định lựa chọn chi ến lược ki ểm soát rủi ro phù hợp - Giám sát điều chỉnh: Đảm bảo chiến lược, phương án đối phó rủi ro lên kế hoạch thực chặt chẽ  Liên hệ đồ án nhóm: Bản kế hoạch quản lý rủi ro nhóm tạo cho dự án - Mục tiêu dự án      - Các chức dự án Đưa danh sách 10 rủi ro nhóm có nguy gặp phải Sắp xếp rủi ro theo độ ưu tiên Họp nhóm thảo luận hành động, phương án để đối phó rủi ro xảy Thống hành động, phương án tối ưu cho dự án  34 Giải thích phương pháp đo lường chất lượng chương trình máy tính (computer program), phương pháp đo lường chất lượng mã nguồn (source code)  Phương pháp đo lường chất lượng chương trình máy tính: - Viết trường hợp thử nghiệm (Testcase) - Viết trường hợp sử dụng (Usecase/Business case) - Lập danh mục (Check list) - Tạo mẫu (Sample) - Hacking  Phương pháp đo lường chất lượng mã nguồn: - Lập danh mục (Check list) - Viết trường hợp thử nghiệm (Testcase) - Viết trường hợp sử dụng (Usecase/Business case) - Tạo mẫu (Sample) - Đánh giá chuyên gia (Expert)  Các tiêu chí đánh giá phải “tiên đề” bên liên quan đ ến d ự án công nhận, tin tưởng  35 Đặc tính chất lượng (Quality Characteristic) gì? Giải thích đ ặc tính ch ất l ượng c phần mềm theo mơ hình McCall Giải thích đặc tính ch ất l ượng c ph ần m ềm theo mơ hình ISO 9126 Giải thích ngun tắc để đo lường đặc tính ch ất l ượng c m ột thực thể  Đặc tính chất lượng (Quality Characteristic) bao gồm: Chính xác, Hi ệu su ất, Kh ả mở rộng, Sửa đổi, Tính khả dụng, Tài liệu, Khiếm khuyết, Kích thước  Các đặc tính chất lượng phần mềm theo mơ hình McCall - Khả thay đổi: Xác định yếu tố chất lượng ảnh hưởng đến khả thay đổi sản phẩm phần mềm, bao gồm:  Khả bảo trì (đơn giản, ngắn gọn, modul), khả tìm sửa lỗi  Tính linh hoạt, khả thực thay đổi theo yêu c ầu c khách hàng  Khả kiểm tra, xác nhận yêu cầu phần mềm - Khả thích ứng với mơi trường mới: Xác định yếu tố chất lượng ảnh hưởng đến khả thích ứng phần mềm với mơi trường mới, bao gồm:  Tính di động, khả di chuyển p/mềm từ m.trường sang m.trường khác  Khả sử dụng lại, dễ dàng sd thành phần p.m ềm hi ện có bối cảnh khác  Khả tương tác, mức độ tương tác mà thành ph ần p.m ềm làm việc - Hoạt động sản phẩm: Xác định yếu tố chất lượng ảnh hưởng đến mức độ đáp ứng đặc điểm kỹ thuật p.mềm  Tính xác, chức phù hợp với đặc điểm kỹ thuật  Độ tin cậy, mức độ thất bại hệ thống  Hiệu quả, sử dụng tài nguyên hệ thống  Tính tồn vẹn, bảo vệ khỏi truy cập trái phép  Tính tiện dụng, dễ sử dụng  Các đặc tính chất lượng phần mềm theo mơ hình ISO 9126 - Chức (Functionality): Các chức cần thiết có sẵn p.mềm hay khơng? Các tiêu chí để đánh giá bao gồm:  Sự phù hợp  Độ xác  Khả tương tác  Bảo vệ - Độ tin cậy (Reliability): Phần mềm đáng tin cậy đến mức nào? Các tiêu chí đánh giá:  Sự trưởng thành  Khả chịu lỗi  Khả phục hồi - Khả sử dụng (Usability): Phần mềm sử dụng? Các tiêu chí đánh giá:  Hiểu  Khả học hỏi  Khả hoạt động  Sự hấp dẫn - Hiệu (Efficiency): Phần mềm hiệu đến mức nào? Các tiêu chí đánh giá:  Hiệu thời gian  Hiệu việc sử dụng tài nguyên - Bảo trì (Maintainability): Làm để dễ dàng sửa đổi phần mềm? tiêu chí đánh giá:  Khả phân tích  Thay đổi  Ổn định  Khả kiểm tra - Tính di động (Portability): Làm để dễ dàng chuyển p.mềm sang m.trường hoạt động khác? Các tiêu chí đánh giá:  Khả thích ứng  Khả cài đặt  Cùng tồn  Khả thay  Nguyên tắc để đo lường đặc tính chất lượng thực thể: Chúng ta phải biến điều mơ hồ chất lượng thành đo lường  36 Chất lượng gì? Giải thích nguyên tắc để quản lý ch ất l ượng c m ột th ực th ể đó? Phân biệt liệu định tính liệu định l ượng (Qualitative vs Quantitative Data), đo lường định tính đo lường định lượng (Qualitative vs Quantitative Measurement)  Chất lượng mức độ tập hợp đặc điểm vốn có, đáp ứng yêu c ầu (nhu c ầu kỳ vọng)  Nguyên tắc để quản lý chất lượng thực thể: - Tập trung vào khách hàng - Lãnh đạo - Có tham gia người - Phương pháp quản lý có hệ thống - Cải tiến liên tục - Quản lý mối quan hệ - Phê bình  Phân biệt liệu định tính (Qualitative Data) li ệu định lượng (Quantitative Data): - Dữ liệu định tính cảm giác, cảm quan - Dữ liệu định lượng số, so sánh với chuẩn  Phân biệt đo lường định tính (Qualitative Measurement) đo l ường đ ịnh l ượng (Quantitative Measurement): - Đo lường định tính:  Dùng từ ngữ để mơ tả, hình dung  Dữ liệu quan sát khơng đo  Đó màu sắc, mùi vị, thị hiếu, ngoại hình, vẻ đẹp,…  Định tính – Chất lượng  Đo lường định tính thu thập thơng tin số - Đo lường định lượng:  Dùng số để mơ tả, hình dung  Dữ liệu đo lường  Đó chiều dài, chiều cao, diện tích, thể tích, nhiệt độ, tốc độ, th ời gian, chi phí, lứa tuổi,…  Định lượng – Số lượng  Đo lường định lượng đo lường liệu số  37 Giải thích độ đo chất lượng phần mềm góc nhìn c khách hàng Gi ải thích độ đo chất lượng quy trình Giải thích đ ộ đo ch ất l ượng c m ột dự án Giải thích độ đo chất lượng nhân  Các độ đo chất lượng phần mềm góc nhìn khách hàng: - Tốc độ thực thi chương trình phải nhanh - Dữ liệu xử lý xác - Giao diện phần mềm đạt yêu cầu - Dễ sử dụng - Chi phí, giá phù hợp  Các độ đo chất lượng quy trình - Có đầu vào - Có kỹ thuật để thực quy trình - Có sản phẩm cụ thể kết thúc quy trình  Các độ đo chất lượng dự án - Sự hài lòng khách hàng - Đúng tiến độ - Đúng ngân sách - Tiết kiệm tài nguyên  Các độ đo chất lượng nhân sự: - Có Cử nhân Khoa học Máy tính/Kỹ thuật Phần mềm tương đương - Có hiểu biết sâu sắc kinh nghiệm thực tế cơng c ụ quy trình chất lượng p.mềm Có kiến thức cơng cụ SW Engineering Hiểu thấu đáo tồn Quy trình phát triển p.mềm Có kinh nghiệm làm việc với khách hàng  38 Quản lý chất lượng gì? Kiểm sốt chất lượng gì? Liệt kê ph ương pháp ki ểm sốt chất lượng Đảm bảo chất lượng gì? Liệt kê ph ương pháp đ ảm b ảo ch ất lượng Liệt kê nội dung tài liệu kế hoạch đảm bảo chất l ượng cho m ột d ự án Tại cần quản lý chất lượng cho dự án?  Quản lý chất lượng (Quality Management – QM) việc đảm bảo phần mềm đáp ứng tiêu chuẩn cần thiết  Kiểm soát chất lượng (Quanlity Control – QC) phần quản lý chất lượng, tập hợp phương pháp tổ chức sử dụng để đạt tham s ố chất l ượng mục tiêu chất lượng liên tục cải thi ện khả c t ổ ch ức đ ể đ ảm b ảo r ằng sản phẩm phần mềm đáp ứng mục tiêu chất lượng  Các phương pháp kiểm soát chất lượng: - Đảm bảo chất lượng - Kiểm tra thất bại - Kiểm soát thống kê - Chất lượng cơng ty - Kiểm sốt chất lượng tồn diện  Đảm bảo chất lượng (Software Quality Assurance – SQA/QA) phần quản lý chất lượng, tập hợp hoạt động để đảm bảo chất lượng quy trình kỹ thuật phần mềm  SQA đảm bảo phần mềm phát triển đáp ứng tuân thủ thông s ố kỹ thuật chất lượng xác định tiêu chuẩn hóa  SQA q trình diễn Vịng đời phát triển phần mềm SDLC  Các phương pháp đảm bảo chất lượng: - Quản lý chất lượng toàn diện: Nếu sản phẩm không tuân thủ tiêu chuẩn chất lượng, chất lượng sản phẩm đảm bảo - Kiểm tra lỗi: Một sản phẩm kiểm tra sản phẩm bị lỗi - Kiểm soát thống kê: Dựa theo mức chất lượng Six Sigma  Nội dung tài liệu kế hoạch đảm bảo chất lượng dự án: - Mục tiêu kế hoạch - Tài liệu tham khảo - Tiêu chuẩn, thực hành, quy ước, số liệu - Đánh giá p.mềm - Kiểm tra - Báo cáo cố hành động khắc phục - Cơng cụ, kỹ thuật phương pháp - Kiểm sốt nhà cung cấp - Thu thập, bảo trì - Đào tạo - Quản lý rủi ro - Bảng giải  Quản lý chất lượng nhằm mục đích: - Cải thiện hài lịng khách hàng - • Giảm chi phí phát triển Giảm chi phí bảo trì Đáp ứng tiêu chuẩn chất lượng (ISO, CMMI)    Liệt kê tài liệu cần làm trình lập kế hoạch cho dự án • Executive Summary (WHY?) • Work breakdown structure (WBS) • Project Vision (WHAT?) • Release Planning • Project Charter (WHO?) • Requirement Specification • Proof of Concept (WHEN?) • Product Backlog • Prototype • Project Schedule (Lịch trình dự án) • •Ba số quan trọng trình thực dự án? Dựa vào đâu đ ể có đ ược số đó? • Manday/Số point (SCRUM): Dựa vào Product Backlog WBS • Chi phí dự án: Dựa vào Project Schedule (Lịch trình dự án) Phân tích chi phí – l ợi nhuận • Thời gian hồn thành dự án: Dựa vào WBS • •Làm để biết dự án làm bao lâu? Chi phí dự kiến cho d ự án bao nhiêu? Tại sao? • Xây dựng Work breakdown structure (WBS) • Ước lượng số ngày cho phần tử công việc WBS • Xác định cơng việc làm trước, cơng việc làm sau (Li ệt kê công vi ệc, cơng việc nối tiếp cơng việc nào…) • Vẽ sơ đồ mạng lưới lịch trình Network Diagram (Đường dài nh ất s đ m ạng lưới lịch trình gọi Đường – Critical Path Method)  Dự án làm ngày • Dự tính ngày bắt đầu ước lượng ngày kết thúc • Vẽ sơ đồ Gantt • Phân cơng cơng việc cho thành viên  Nếu có thành viên làm nhiều việc thực cân tài nguyên  Resource Smoothing: Kéo dài thời gian thực hi ện công vi ệc th ời h ạn cho phép  Resource Leveling: Kéo dài thời gian hoàn thành dự án • •  Nén lịch trình dự án cách: Fast Tracking (Đôn công vi ệc làm song song, gối đầu lên nhau) Crashing (Tăng thêm người, làm thêm gi ờ, thuê ng ười làm thay,…) Tính lương cho nhân viên  Chi phí dự tính = Tổng lương nhân viên tham gia d ự án + Chi phí cho tài nguyên + Chi phí rủi ro + Chi phí phát sinh khác + … • Đối với SCRUM: • Số Sprint dự án = Tổng số Point dự án / Số Point Sprint • Lương nhân viên = Lương/giờ * Số làm • Chi phí dự tính = (Tổng lương nhân viên * Số Sprint) + Chi phí tài nguyên + Chi phí rủi ro + Chi phí khác + … • •Liệt kê tài liệu cần làm để quản lý tiến trình thực dự án • Project Schedule (Lịch trình dự án) • Time Sheet • Product Backlog • Báo cáo tình trạng dự án • Burndown Chart • ... phẩm: Architectural Design Specification, Detailed Design Specification, GUI, Data Model, Design Layer, Implementation Resource Documentation,… Construction: Hiện thực hố hệ thống ngơn ngữ lập... Architectural Design Specification, Detailed Design Specification, GUI - Vai trò tham gia: Technical Architect, Designer, Developer Software Construction (Implementation) - Hoạt động chính: Xây dựng... Project Vision, Project Charter, Functional Requirement Specification, Supplementary Specification - Đầu ra: Product Backlog, User Stories, Work Breakdown Structure (WBS), Proof of Concept, Prototype