TRƯỜNG ĐAỊ HOCC BÁCH KHOA HÀNÔỊ VIỆN CÔNG NGHÊ T C HÔNG TIN VÀ TRUYỀN THÔNG ̀ ̀ BÔ M C ÔN CÔNG NGHÊ CPHÂN MÊM BÁO CÁO ĐỒ ÁN MÔN HỌC NHẬP MÔN CÔNG NGHỆ PHẦN MỀM Đề tài Tìm hiểu quy trình phát triển phần mềm Giảng viên hướng dẫn: Thầy Huỳnh Quyết Thắng Sinh viên thực : Đặng Việt Hùng Nguyễn Văn Hiệp Lớp Công nghệ phần mềm K51 Đồ án môn học Nhập môn công nghệ phần mềm Lớp CNPM K51 MỤC LỤC Giới thiệu……………………………………………………………………………………………………………………… I Các quy trình phát triển phần mềm chuẩn .5 I.1 Nội dung .5 I.2 Chi tiết tìm hiểu .5 I.2.1 Qui trình gì? I.2.2 SEP, ISO, CMM/CMMI I.2.3 Các mô hình SEP .6 II Tìm hiểu quy trình áp dụng thực tế công ty phần mềm 12 II.1 Nội dung 12 II.2 Chi tiết thực 12 II.2.1 Giới thiệu GoldeSoft .12 II.2.2 Khảo sát quy trình phát triển phần mềm GoldenSoft 12 II.2.3 Quy trình phát triển phần mềm số công ty phần mềm khác 16 III Nhận xét đánh giá………… 17 IV Tài liệu tham khảo………… 18 2|Page Đồ án môn học Nhập môn công nghệ phần mềm Lớp CNPM K51 Giới thiệu Đồ án môn học Nhập môn công nghệ phần mềm Giảng viên hướng dẫn: PGS.TS Huỳnh Quyết Thắng Danh sách nhóm STT Họ tên Đặng Việt Hùng Nguyễn Văn Hiệp Đề tài Tìm hiểu quy trình phát triển phần mềm thực tế ứng dụng công ty phần mềm / công ty tin học làm việc địa bàn Hà nội - Công việc cụ thể  Các quy trình chuẩn: sở lí thuyết, phân loại, tìm hiểu chung  Tìm hiểu thu thập tài liệu tham khảo tiêu biểu liên quan đến nội dung tập lớn  Một số quy trình phát triển phần mềm thông dụng: CMM, Prototyping, RAD, RUP, Chú ý SCRUM : chia nhỏ thành module  Các công cụ hỗ trợ triển khai quy trình  Thực tế ứng dụng công ty (trên địa bàn Hà Nội): khảo sát thực tế, vấn, đánh giá  Bài học kinh nghiệm kết luận 3|Page Đồ án môn học Nhập môn công nghệ phần mềm Lớp CNPM K51 Đề cương nghiên cứu STT Nội dung - Tìm hiểu quy trình chuẩn • • • - Tìm hiểu, thu thập tài liệu tham khảo liên quan đến quy trình phát triển phần mềm - Một số quy trình thông dụng • • • • • Cơ sở lý thuyết Phân loại Tìm hiểu chung CMM Prototyping RAD RUP SCRUM - Các công cụ hỗ trợ triển khai quy trình - Thực tế ứng dụng công ty địa bàn Hà Nội (công ty phần mềm GoldenSoft) • Khảo sát thực tế • Phỏng vấn • Đánh giá - Công ty cổ phần phần mềm Golden Soft • Giám đốc: KS Vũ Hồng Lĩnh • Địa chỉ: Số 5-Bắc Hồng-Khương Trung• - Tổng kết học kinh nghiệm, kết luận - Viết báo cáo 4|Page Thanh Xuân-Hà Điện thoại: 0947 Đồ án môn học Nhập môn công nghệ phần mềm I Các quy trình phát triển phần mềm chuẩn I.1 - Nội dung Tìm hiểu quy trình phát triển phần mềm chuẩn Lớp CNPM K51  Cơ sở lý thuyết  Phân loại  Tìm hiểu chung Một số quy trình thông dụng      CMM Prototyping RAD RUP SCRUM Các công cụ hỗ trợ triển khai quy trình I.2 Chi tiết tìm hiểu Cũng ngành sản xuất khác, qui trình yếu tố quan trọng đem lại s ự thành công cho nhà sản xuất phần mềm, giúp cho thành viên dự án từ người cũ đến người mới, hay công ty x lý đồ ng công việc tương ứng vị trí thông qua cách thức chung công ty, hay cấp độ dự án Có thể nói qui trình phát triển/xây dựng phần mềm (Software Development/Engineering Process - SEP) có tính chất đị nh để tạo sản phẩm chất luợng tốt với chi phí thấp suất cao, điều có ý nghĩa quan trọng đối vớ i công ty sản xuất hay gia công phần mềm củng cố phát triển với công nghiệp phần mềm đầy cạnh tranh I.2.1 Qui trình gì? Qui trình hiểu phương pháp thực sản xuất sản phẩm Tương tự vậy, SEP phương pháp phát triển hay sản xuất sản phẩm phần mềm.Thông thường qui trình bao gồm yếu tố sau:      - Thủ tục (Procedures) Hướng dẫn công việc (Activity Guidelines) Biểu mẫu (Forms/templates) Danh sách kiểm định (Checklists) Công cụ hỗ trợ (Tools) Với nhóm công việc chính:  Đặc tả yêu cầu (Requirements Specification): “đòi hỏi” cho yêu cầu chức phi chức 5|Page Đồ án môn học Nhập môn công nghệ phần mềm Lớp CNPM K51  Phát triển phần mềm (Development): tạo phần mềm thỏa mãn yêu cầu “Đặc tả yêu cầu”  Kiểm thử phần mềm (Validation/Testing): để bảo đảm phần mềm sản xuất đáp ứng “đòi hỏi” “Đặc tả yêu cầu”  Thay đổi phần mềm (Evolution): đáp ứng nhu cầu thay đổi khách hàng - Tùy theo mô hình phát triển phần mềm, nhóm công việc triển khai theo cách khác Để sản xuất sản phẩm phần mềm người ta dùng mô hình khác Tuy nhiên tất mô hình thích hợp cho ứng dụng I.2.2 SEP, ISO, CMM/CMMI Vấn đề đặt làm cải tiến qui trình để cải thiện chất lượng suất? Câu trả lời qui trình khung (Process Framework - PF) PF yêu cầu mà mộ t qui trình phải đáp ứ ng tùy theo mỗ i mức độ PF không qui trình cụ thể mà đưa yêu cầu mỗ i mức độ trưởng thành khác qui trình phải đạt Đây hướng dẫn cho hoạt động cải tiến để nâng mức độ trưởng thành từ thấp lên cao Có nhiều PF, phổ biến ISO CMM (Capability Maturity Model) tổ chức giới công nhận ISO nhắm chung đến nhiều loại tổ chức sản xuất lẫn dịch vụ, CMM dành riêng cho tổ chức phát triển phần mềm Đối với ph ần mềm, ISO ch ỉ mức độ chất lượng yêu cầu tối thiểu mà SEP phải đạt (ISO certified) việc cải tiến qui trình thực thông qua qui trình kiểm định, CMM bao gồm thực tiễn tốt nh ất (best practices) tập hợp rút tỉa từ nhiều tổ chức phát triển phần mềm khác chúng tổ chức thành mức độ trưởng thành khác (Level - Initial, Level - Repeatable, Level - Defined, Level - Managed, Level - Optimizing) Ngày nay, phần m ềm không đứng riêng mà thường m ột phận hệ thống hoàn chỉnh Do đó, CMMI (Capability Maturity Model Integration) đời hướng đến qui trình cho việc xây dựng hệ thống, bao gồm việc tích hợp để xây dựng bảo trì toàn hệ thống I.2.3 Các mô hình SEP Mô hình SEP gọi chu trình hay vòng đời phần mềm (SLC - Software Life Cycle) SLC tập hợp công việc quan hệ chúng với diễn trình phát triển phần mềm Có nhiều mô hình SLC khác nhau, số ứng dụng phổ biến giới: Các mô hình phiên (Single-version models) - • Mô hình Waterfall (Waterfall model) • Mô hình chữ V (V-model) Các mô hình nhiều phiên (Multi-version models) • • • • • Mô Mô Mô Mô Mô hình hình hình hình hình 6|Page mẫu (Prototype) tiến hóa (Evolutionary) lặp tăng dần (Iterative and Incremental) phát triển ứng dụng nhanh (RAD) xoắn (Spiral) Đồ án môn học Nhập môn công nghệ phần mềm a Lớp CNPM K51 Mô hình Waterfall Mô hình bao gồm giai đoạn xử lý nối tiếp mô tả Hình Hình Mô hình Waterfall - Phân tích yêu cầu tài liệu đặc tả (Requirements and Specifications): giai đoạn xác định “đòi hỏi” (“What”) liên quan đến chức phi chức mà hệ thống phần mềm cần có Giai đoạn cần tham gia tích cực khách hàng kết thúc tài liệu gọi “Bản đặc tả yêu cầu ph ần mềm” hay SRS (software requirement specification), bao gồm tập hợp yêu cầu duyệt (reviewed) nghiệm thu (approved) người có trách nhiệm dự án (từ phía khách hàng) SRS tảng cho hoạt động cuối dự án - Phân tích hệ thố ng thiết k ế (System Analysis and Design): giai đoạn định “làm nào” (“How”) để hệ th ống phần mềm đáp ứ ng “đòi hỏi” (“What”) mà khách hàng yêu cầu SRS Đây là cầu nối “đòi hỏi” (“What”) mã (Code) thực để đáp ứng yêu cầu Hiện thực kiểm thử thành phần (Coding and Unit Test): giai đoạn thực “làm nào” (“How”) giai đoạn “Phân tích hệ thống thiết kế” Kiểm thử (Test): giai đoạn tiến hành kiểm thử mã (code) thực, bao gồm kiểm thử tích hợp cho nhóm thành phần kiểm thử toàn hệ thống (system test) Một khâu ki ểm thử cuối thường thự c hi ện nghiệm thu (acceptance test), với tham gia khách hàng vai trò để xác định hệ thống phần mềm có đáp ứng yêu cầu họ hay không - Cài đặt bảo trì (Deployment and Maintenance): giai đoạn cài đặt, cấu hình huấn luyện khách hàng Giai đoạn sửa chữa lỗi phần mềm (nếu có) phát triển thay đổi khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm hệ thống) Thực tế cho thấy đến nh ững giai đoạn sau có khả nhận sai sót nh ững giai đoạn trước phải quay lại để sửa chữa Đây kiểu waterfall dạng lặp (Iterative Waterfall) minh hoạ Hình 7|Page Đồ án môn học Nhập môn công nghệ phần mềm Lớp CNPM K51 Mô hình chữ V Trong mô hình Waterfall, kiểm thử thực giai đoạn riêng biệt Còn với mô hình chữ V, toàn qui trình chia thành hai nhóm giai đoạn tương ứ ng nhau: phát triển ki ểm th Mỗi giai đoạn phát triển kết hợp với giai đoạn kiểm thử tương ứng minh họa Hình b Hình Mô hình chữ V Tinh thần chủ đạo V-model hoạt động kiểm thử phải tiến hành song song (theo khả có thể) từ đầu chu trình với hoạt động phát triển Ví dụ, hoạt động cho việc lập k ế hoạch kiểm thử toàn hệ thống thực song song với hoạt động phân tích thiết kế hệ thống c Mô hình mẫu (Prototype) Hình Mô hình mẫu Mô hình mẫu (prototype) đượ c minh hoạ Hình Trong đó, qui trình bắt đầu việc thu thập yêu cầu với có mặt đại diện phía phát triển lẫn khách hàng nhằm định mục tiêu tổng thể h ệ thố ng phần mềm sau này, đồ ng thời ghi nhận tất yêu cầu biết sơ luợc nhóm yêu cầu cần phải làm rõ Sau đó, thực thiết kế nhanh tập trung chuyển tải khía cạnh thông qua 8|Page Đồ án môn học Nhập môn công nghệ phần mềm Lớp CNPM K51 prototype để khách hàng hình dung, đánh giá giúp hoàn chỉnh yêu c ầu cho toàn h ệ thống ph ần mềm Việc giúp tinh chỉnh yêu cầu, mà đồng thời giúp cho đội ngũ phát triển thông hiểu cần phát triển Ti ếp theo sau giai đoạn làm prototype chu trình theo mô hình waterfall mô hình khác Chú ý, prototype thường làm thật nhanh thờ i gian ngắn nên không xây dựng môi trường công c ụ phát triển giai đoạn xây dựng phần mềm thực sau Prototype không đặt mục tiêu tái sử dụng cho giai đoạn phát triển thực sau d Mô hình tiến hóa (Evolutionary) Mô hình thực dạng dựa mô hình mẫu, nhiên có khác biệt:  Mô hình tiến hóa xây dựng nhiều phiên prototype liên tiếp  Những phiên prototype trước xây dựng với mục tiêu tái sử dụng phiên sau Hình minh họa mô hình tiến hóa, cho thấy số phần hệ thống phần mềm đuợc xây dựng sớm từ giai đoạn thực phân tích yêu cầu thiết kế Mô hình lặp tăng dần (Iterative and Incremental) Mô hình lặp tăng dần có lúc hiểu Tuy nhiên, ta phân biệt nhiều khác biệt Trước tiên, hai mô hình có điểm giống dựa tinh thần mô hình tiến hóa, có thêm đặc điểm nhắm đến việc cung cấp phần h ệ th ống, để khách hàng đưa vào sử dụng môi trường hoạt động sản xuất thực sự, mà không cần chờ toàn hệ thống hoàn thành (trong mô hình mẫu hay tiến hóa, phiên mẫu hay trung gian không nhắm đến đưa vào vận hành thực cho khách hàng, trừ phiên cuối cùng) Để khách hàng sử dụng, phiên ph ải thực qui trình đầy đủ công vi ệc từ phân tích yêu cầu với khả bổ sung hay thay đổi, thiết kế, thực kiểm nghiệm xem qui trình (chu trình) Các chu trình sử dụng mô hình khác (thông thường waterfall) Hình minh họa hai mô hình này, chu trình waterfall nhỏ e 9|Page Đồ án môn học Nhập môn công nghệ phần mềm Lớp CNPM K51 Hình Mục tiêu phiên phát tri ển phần lõi nhóm chức quan trọng Sau phiên đưa vào sử dụng, k ết qu ả đánh giá phản hồi lập kế hoạch cho chu trình phiên để thực hiện:  Những thay đổi cho phiên trước nhằm đáp ứng nhu cầu khách hàng tốt  Có thể thêm chức đặc điểm bổ sung  Sự khác hai mô hình tăng dần lặp hiểu đơn giản sau (so với sản phẩm hoàn thành chu trình trước):  Mô hình tăng dần (Incremental): thêm chức vào sản phẩm (xem minh hoạ Hình 6)  Mô hình lặp (Iterative): thay đổi sản phẩm (xem minh họa Hình 6) Một SEP kết hợp hai mô hình lặp lẫn tăng dần, chẳng hạn RUP (Rational Unified Process) Mô hình phát triển nhanh (RAD) Mô hình phát triển nhanh (RAD - Rapid Application Development) mô hình tăng dần với chu kỳ phát triển cực ngắn Để đạt mục tiêu này, RAD dựa phương pháp phát triển sở thành phần hóa hệ thống vớ i việc tái sử dụng thành phần thích hợp RAD thích hợp cho hệ thống quản lý thông tin f g Mô hình xoắn (Sprial) Mô hình xây dựng Barry Boehm, đặt trọng tâm phân tích rủi ro xem xét kế hoạch để giải chúng, thông qua nhiều chu kỳ nối tiếp lặp liên tiếp dựa chất mô hình lặp Trong mô hình này, việc phân tích giải vấn đề có rủi ro cao tập trung vào thiết kế khía cạnh cụ thể không dựa vào việc xử lý vấn đề cách chung chung Hình minh họ a mô hình với giai đoạn lặp theo chu kỳ xoay vòng, chu kỳ bao gồm giai đoạn sau:  Analysis: Xác định mục tiêu chất lượng cho sản phẩm thực hiện, đồng thời xác định lựa chọn mua, tái sử dụng hay tự thiết kế thực thành phần hệ thống  Evaluation: Phân tích lựa chọn rủi ro xảy Việc thực nhiều hoạt động khác thông qua làm mẫu hay mô  Development: Phát triển kiểm định sản phẩm mức dựa kết định hướng giai đoạn số (phân tích rủi ro)  Planing: Kiểm duyệt tất kết giai đoạn xảy trước lập kế hoạch cho chu kỳ lặp 10 | P a g e Đồ án môn học Nhập môn công nghệ phần mềm Hình 11 | P a g e Lớp CNPM K51 Đồ án môn học Nhập môn công nghệ phần mềm AI Tìm hiểu quy trình áp dụng thực tế công ty phần mềm II.1 - Nội dung Tìm hiểu quy trình áp dụng thực tế công ty phần mềm - Cụ thể khảo sát công ty Golden Soft Lớp CNPM K51 II.2 Chi tiết thực Tiếp tục thực theo đề cương đồ án, nhóm tiến hành khảo sát, tìm hiểu thực tế áp dụng quy trình phát triển phần mềm công ty địa bàn Hà Nội Cụ thể nhóm khảo sát công ty sau:  Trực tiếp khảo sát công ty cổ phần phần mềm vàng GoldenSoft  Tìm hiểu thông tin quy trình công ty o FPT o Tinh vân o Sóc bay o II.2.1 Giới thiệu GoldenSoft - Công ty GoldenSoft công ty hàng đầu lĩnh vực phát triển hệ thống phần mềm hướng dịch vụ Công ty phần trình thực hóa đề án xây dựng phủ điện tử Một số hệ thống GoldenSoft nghiên cứu, triển khai, phát triển; hỗ trợ hiệu cho quan quản lý nhà nước nhiều lĩnh vực, đặc biệt bất động sản  Hệ thống cấp quản lý giấy chứng nhận chuyên gia môi giới định giá bất động sản  Hệ thống cấp quản lý giấy chứng nhận quyền sử dụng đất, quyền sở hữu nhà tài sản khác gắn liền với đất  Hệ thống sàn bất động sản điện tử Việt Nam  Hệ thống website ban đạo trung ương vấn đề nhà bất động sản  - Công ty GoldenSoft có 20 nhân viên, kỹ sư tốt nghiệp khoa CNTT ĐHBKHN II.2.2 Khảo sát quy trình phát triển phần mềm GoldenSoft Hiện GoldenSoft áp dụng quy trình SCRUM, theo mô hình linh hoạt Do đặc thù đội phát triển số lượng nhỏ (có team, team khoảng thành viên), nên việc áp dụng quy trình SCRUM giúp việc phát triển phần mềm trở nên nhanh chóng dễ dàng a Giới thiệu SCRUM - Đó quy trình phát triển phần mềm theo mô hình linh hoạt (agile) Công nghệ Agile cung cấp nhiều phương pháp luận, quy trình thực nghiệm việc phát triển phần mềm trở nên nhanh chóng dễ dàng Scrum theo mô hình Scrum chia dự án thành vòng lặp phát triển gọi sprint Mỗi sprint thường 2- tuần (30 ngày) để hoàn thành Nó phù hợp cho dự án có nhiều thay đổi yêu cầu tốc độ cao 12 | P a g e Đồ án môn học Nhập môn công nghệ phần mềm Lớp CNPM K51 Một sprint hoàn thành số chức năng, mục đích toàn hệ thống Các tác vụ sprint chia thành danh mục, đội làm việc phát triển đánh giá lại cho đạt mục đích ban đầu khoảng thời gian đề Thành phần quan trọng scrum role (vai trò) trao đổi đánh giá Có role là:  Product Owner: người làm công việc bắt đầu cho dự án, tạo yêu cầu trình phát triển dự án Phân tích mục tiêu, giải phóng kế hoạch  Scrum Master: họ phải đảm bảo sprint hoàn thành mục đích, bảo vệ đội làm việc loại bỏ trở ngại  Đội làm việc scrum: thường từ 5-9 người, tùy theo quy mô dự án có nhiều đội, nhiều người tham gia Sẽ lập trình viên (programmer), người thiết kế (designer), kiểm thử viên (tester),… thường thấy dự án phần mềm truyền thống Các đội làm việc tiến hành cài đặt chức mô tả yêu cầu Họ tự quản lý, tổ chức điều chỉnh đội làm việc cho hiệu lớn Tất thành viên có ảnh hưởng đến thành công thất bại toàn hệ thống hệ thống nhỏ Có pha lập kế hoạch kết thúc xác định tiến trình cần thiết gồm liệu đầu vào đầu thật đầy đủ Có số vòng lặp phát triển pha kế hoạch Kế hoạch lập ban đầu tương đối có điều chỉnh So sánh scrum quy trình phần mềm truyền thống Với phương pháp truyền thống, việc lập kế hoạch dự án (xác định việc cần làm thời gian kế thúc) dựa kinh nghiệm môi trường làm trực tiếp Và so với kế hoạch bắt tay vào xây dựng thường có độ trễ định b Scrum quy trình thác nước (waterfall), xoắn ốc (spiral)  Mô hình thác nước chia dự án phần mềm gồm giai đoạn: đặc tả yêu cầu, thiết kế hệ thống, cài đặt (lập trình), kiểm thử bảo trì Quy trình dễ quản lý lại 13 | P a g e Đồ án môn học Nhập môn công nghệ phần mềm Lớp CNPM K51 linh hoạt không hiệu có thay đổi giai đoạn sau ảnh hưởng lớn đến giai đoạn trước  Quy trình xoắn ốc chia dự án thành giai đoạn: lập kế hoạch, phân tích rủi ro, giao tiếp khách hàng, đánh giá lại, sản xuất phân phối Nó chưa sử dụng rộng rãi Các quy trình phần mềm truyền thống thường có nhiều giai đoạn, nhiều thành phần, yếu tố suốt thời gian phát triển sản phẩm Phương pháp scrum tránh điều Đặc điểm Waterfall Spiral Scrum c - Áp dụng scrum GoldeSoft Triển khai SCRUM GoldenSoft trải qua 10 bước sau:  Bước 1: Thu nhập đặc điểm sản phẩm (backlog) đơn đặt hàng Đây bước quan trọng Lập nên đội làm việc, tách thành đội cần thiết thảo luận với nghiệp vụ cần làm Sau bổ nhiệm người vào vị trí Product owner, người có khả trao đổi, bao quát công việc tốt, biết xếp ưu tiên thứ tự nhiệm vụ Sau tự tổ chức lại đội làm việc, đề xuất vị trí Scrum master thảo luận chi tiết yêu cầu, xếp chúng theo thứ tự ưu tiên  Bước 2: Ước lượng đầy yêu cầu sản phẩm đầu Có ước lượng mức độ cao, chia sản phẩm thành số lượng danh mục backlog Tuy nhiên số lượng không xác được, sau chúng bổ sung Tiếp đến ước lượng chi tiết backlog, ước lượng số lượng đội làm việc  Bước 3: Lên kế hoạch phát triển vòng lặp sprint Sử dụng trao đổi kế hoạch phát triển sprint với tất thành viên Xác định khoảng thời gian phát triển sprint (thường 30 ngày), mục tiêu sprint gì, đạt gì, phân tích yêu cầu sprint cách rõ ràng 14 | P a g e Đồ án môn học Nhập môn công nghệ phần mềm Lớp CNPM K51  Bước 4: Lên kế hoạch phát triển nhiệm vụ sprint Tất người xác định ngân sách sprint đó, chia đặc điểm thành tác vụ nhỏ hơn, ước lượng số thời gian làm task (giờ), hoàn tất yêu cầu nhận dạng task quan trọng  Bước 5: Tạo không gian làm việc cộng tác cho tất người Thường sử dụng bảng trắng để vẽ nên vấn đề cần thiết cho tất người đánh giá  Bước 6: Các thành viên bắt tay xây dựng sprint Lập trình, kiểm thử điều chỉnh thời gian để có hiệu tốt Đôi hủy bỏ sprint quay lại với việc lập kế hoạch khác  Bước 7: Mọi người báo cáo kết để tiếp tục làm việc Các báo cáo tập trung vào vấn đề: đạt so với lần trao đổi trước; hoàn thành lần trao đổi tiếp theo; có trở ngại trình làm việc v.v  Bước 8: Tổng hợp kết biểu đồ Đây tranh tổng quát việc làm được, việc chưa làm được, thời gian ước lượng lại điều chỉnh lại  Bước 9: Xem xét để hoàn tất Khi thành viên nói công việc hoàn thành có nghĩa thay đổi bị từ chối, đẩy lại cho vòng lặp sau  Bước 10: Đánh giá, phản ánh lặp lại Có họp đánh giá lại sprint thành viên Sẽ trình bày đạt được, phản hồi khách hàng, xét thời hạn sprint Nhìn lại biểu đồ bước để xác định lại toàn hệ thống tiếp nhận đóng góp, bổ sung để đưa tiếp vào vòng lặp sprint d Các điểm mạnh quy trình SCRUM áp dụng GoldenSoft Điểm mạnh việc linh hoạt, dự án không cố định từ đầu thời gian hoàn thành hay yêu cầu mà xác định phát triển thực tế Phân phối sản phẩm mềm dẻo: nội dung sản phẩm chuyển giao xác định linh hoạt theo môi trường sử dụng thực tế Thời gian biểu linh hoạt: muộn sớm so với kế hoạch ban đầu Chất lượng sản phẩm tốt giảm rủi ro sản xuất, chi phí thấp Khả trao đổi khách hàng nhà phát triển, thành viên đội đặt lên mức cao Tốc độ phát triển nhanh, tiết kiệm thời gian Việc chuẩn bị hành động cho thay đổi trình phát triển tốt hàng ngày có buổi họp đánh giá lại vòng lặp phát triển Các bugs (lỗi) vấn đề phát sớm nhiều so với phương pháp truyền thống khách hàng tham gia đánh giá nhiều đầu sản phẩm nhanh Và sai hướng, hủy sprint để quay lại với kế hoạch 15 | P a g e Đồ án môn học Nhập môn công nghệ phần mềm Lớp CNPM K51 II.2.3 Quy trình phát triển phần mềm số công ty phần mềm khác Theo khảo sát nhóm, công ty phần mềm khác áp dụng quy trình dựa quy trình chuẩn Tuy nhiên tùy đặc thù công ty, số lượng nhân viên, số thành viên team, quy mô dự án; mà có điều chỉnh cho phù hợp Nhận xét chung dự án vừa nhỏ, quy trình phần mềm thường chưa quan tâm mức Sau có phân tích, thành viên bắt tay vào cài đặt Mỗi có lỗi yêu cầu chỉnh sửa, họp bàn team để xử lý 16 | P a g e Đồ án môn học Nhập môn công nghệ phần mềm BI Nhận xét đánh giá - Thông qua việc thực đồ án, nhóm rút học sau Lớp CNPM K51  Nắm tầm quan trọng quy trình phát triển phần mềm  Nắm kiến thức quy trình phát triển phần mềm: sở lý thuyết, quy trình thực tế, công cụ hỗ trợ triển khai quy trình  Học hỏi kinh nghiệm áp dụng quy trình phát triển phần mềm công ty 17 | P a g e Đồ án môn học Nhập môn công nghệ phần mềm IV Lớp CNPM K51 Tài liệu tham khảo Bài giảng Thầy Huỳnh Quyết Thắng, Viện CNTT&TT, ĐHBKHN Roger S Pressman: “Software Engineering: A Practitioner's Approach”, 6th Ed., McGraw Hill, 2004 Ian Sommerville: “Software Engineering”, 7th Ed., Addison-Wesley, 2004 Ghezzi, M Jazayeri, and D Mandrioli, Fundamentals of Software Engineering 2nd Ed., Prentice-Hall, 2002 John Musa: “Software Reliability Engineering”, McGraw-Hill, 1998 Barry W Boehm et al.: “Software Cost Estimation with COCOMO II”, Prentice Hall PTR, 2000 Guide to the Software Engineering Body of Knowledge(SWEBOK) – IEEE 2004 Version wikipedia.org www.pcworld.com.vn - Các viết, tài liệu liên quan mô hình phát triển phần mềm 18 | P a g e