BÁO CÁO MÔN QUẢN LÝ DỰ ÁN PHẦN MỀM Các mô hình phát triển phần mềm điều kiện đầu vào, vai trò tham gia, sản phẩm đầu ra của các phases (các activities).

21 7 0
BÁO CÁO MÔN QUẢN LÝ DỰ ÁN PHẦN MỀM  Các mô hình phát triển phần mềm điều kiện đầu vào, vai trò tham gia, sản phẩm đầu ra của các phases (các activities).

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC ĐÔNG Á ……***.… BÁO CÁO: MÔN QUẢN LÝ DỰ ÁN PHẦN MỀM GVHD : ThS Hoàng Nhạc Trung Lớp : S19A1B Nhóm :2 SVTH : Võ Văn Huy (Leader) Nguyễn Chí Thắng Hồng Cơng Quyết Nguyễn Hồng Rơn Lê Văn Linh Ngô Công Lý Ngô Tấn Phúc Đà Nẵng, ngày 10/01/2022 Mục Lục Chương I Đề tài tìm hiểu: Chương II Phân công nhiệm vụ: Chương III Nội dung tìm hiểu nhóm: Câu 1: Các mơ hình phát triển phần mềm: điều kiện đầu vào, vai trò tham gia, sản phẩm đầu phases (các activities) Định nghĩa mơ hình phát triển phần mềm: Các mơ hình phát triển phần mềm: 2.1 Mơ hình thác nước (Waterfall model): 2.2 Mơ hình xoắn ốc: 2.3 Mơ hình Agile 2.4 Mơ hình tiếp cận lặp 2.5 Mơ hình tăng trưởng 2.6 Mơ hình chữ V( V model) 2.7 Mơ hình Scrum 2.8 Mơ hình RAD Câu 2: So sánh Waterfall Agile Sự khác biệt mơ hình Agile Waterfall: Kết luận: 4 5 11 12 13 15 18 19 19 20 Chương I Đề tài tìm hiểu: Câu 1:Các mơ hình phát triển phần mềm: điều kiện đầu vào, vai trò tham gia, sản phẩm đầu phases (các activities) Câu 2: So sánh Waterfall Agile Chương II Phân công nhiệm vụ: STT Họ Tên Nhiệm Vụ Trạng Thái % đóng góp 01 Nguyễn Chí Thắng Định nghĩa mơ hình phát triển phần mềm, Mơ hình Scrum In Progress 14,3% 02 Lê Văn Linh Mơ hình chữ V In Progress 14,3% 03 Nguyễn Hồng Rơn Mơ hình xoắn ốc, RAD model (Rapid Application Development) In Progress 14,3% 04 Võ Văn Huy Mơ hình thác nước (Waterfall model), So sánh Waterfall Agile In Progress 14,3% 05 Ngơ Tấn Phúc Mơ hình Agile, Kết Luận Ưu Nhược điểm Waterfall Agile In Progress 14,3% 06 Hồng Cơng Quyết 07 Ngơ Cơng Lý Mơ hình tăng trưởng (Incremental model) Mơ hình tiếp cận lặp (Iterative model) In Progress 14,3% In Progress 14,3% Chương III Nội dung tìm hiểu nhóm: Câu 1: Các mơ hình phát triển phần mềm: điều kiện đầu vào, vai trò tham gia, sản phẩm đầu phases (các activities) Định nghĩa mơ hình phát triển phần mềm: Mơ hình phát triển phần mềm hay quy trình phát triển phần mềm xác định pha/ giai đoạn xây dựng phần mềm Có nhiều loại mơ hình phát triển phần mềm khác ví dụ như: ● ● ● ● ● ● ● ● Mơ hình thác nước ( Waterfall model) Mơ hình xoắn ốc ( Spiral model) Mơ hình agile Mơ hình tiếp cận lặp ( Iterative model) Mơ hình tăng trưởng ( Incremental model) Mơ hình chữ V ( V model) Mơ hình Scrum RAD model ( Rapid Application Development) Các mơ hình phát triển phần mềm: 2.1 Mơ hình thác nước (Waterfall model): Hình 1: mơ hình thác nước a Mơ tả: - Đây coi mơ hình phát triển phần mềm sử dụng - Mơ hình áp dụng giai đoạn phát triển phần mềm - Đầu giai đoạn trước đầu vào giai đoạn sau Giai đoạn sau thực giai đoạn trước kết thúc Đặc biệt không quay lại giai đoạn trước để xử lý yêu cầu muốn thay đổi b Phân tích mơ hình: - Requirement gathering: Thu thập phân tích yêu cầu ghi lại vào tài liệu đặc tả yêu cầu giai đoạn - System Analysis: Phân tích thiết kế hệ thống phần mềm, xác định kiến trúc hệ thống tổng thể phần mềm - Coding: Hệ thống phát triển theo unit tích hợp giai đoạn Mỗi Unit phát triển kiểm thử dev gọi Unit Test - Testing: Cài đặt kiểm thử phần mềm Cơng việc giai đoạn kiểm tra sửa tất lỗi tìm cho phần mềm hoạt động xác theo tài liệu đặc tả yêu cầu - Implementation: Triển khai hệ thống môi trường khách hàng đưa thị trường - Operations and Maintenance: Bảo trì hệ thống có thay đổi từ phía khách hàng, người sử dụng c Ứng dụng: - Mơ hình thường áp dụng cho dự án phần mềm sau: ● Các dự án nhỏ , ngắn hạn ● Các dự án có thay đổi u cầu khơng có u cầu khơng rõ ràng d Ưu điểm: - Dễ sử dụng, dễ tiếp cận, dễ quản lý - Sản phẩm phát triển theo giai đoạn xác định rõ ràng - Xác nhận giai đoạn, đảm bảo phát sớm lỗi e Nhược điểm: - Ít linh hoạt, phạm vi điều chỉnh hạn chế - Rất khó để đo lường phát triển giai đoạn - Mơ hình khơng thích hợp với dự án dài, diễn ra, hay dự án phức tạp, có nhiều thay đổi yêu cầu vòng đời phát triển - Khó quay lại giai đoạn kết thúc 2.2 Mơ hình xoắn ốc: Hình 2: mơ hình xoắn ốc a Mơ tả - Là mơ hình kết hợp tính mơ hình prototyping mơ hình thác nước - Mơ hình xoắn ốc ưa chuộng cho dự án lớn, đắt tiền phức tạp - Mơ hình sử dụng giai đoạn tương tự mơ hình thác nước, thứ tự, plan, đánh giá rủi ro, … b Phân tích mơ hình - Các pha quy trình phát triển xoắn ốc bao gồm: - Objective identification- Thiết lập mục tiêu: xác định mục tiêu, đối tượng cho pha dự án - Alternate evaluation- Đánh giá giảm thiểu rủi ro: đánh giá rủi ro thực hành động để giảm thiểu rủi ro - Product development- Phát triển sản phẩm: Lựa chọn mô hình phù hợp để phát triển hệ thống - Next phase planning- Lập kế hoạch: đánh giá dự án lập kế hoạch cho pha c Ứng dụng - Mơ hình thường sử dụng cho ứng dụng lớn hệ thống xây dựng theo giai đoạn nhỏ theo phân đoạn d Ưu điểm - Tốt cho hệ phần mềm quy mơ lớn - Dễ kiểm sốt mạo hiểm mức tiến hóa - Đánh giá thực tế quy trình làm việc, vấn đề quan trọng phát sớm e Nhược điểm - Manager cần có kỹ tốt để quản lý dự án, đánh giá rủi ro kịp thời - Chi phí cao nhiều thời gian để hoàn thành dự án - Phức tạp khơng thích hợp với dự án nhỏ rủi ro - Yêu cầu thay đổi thường xuyên dẫn đến lặp vô hạn - Chưa dùng rộng rãi 2.3 Mơ hình Agile Hình 3: mơ hình Agile - Agile phương pháp phát triển phần mềm linh hoạt để đưa sản phẩm đến tay người dùng nhanh tốt xem cải tiến so với mơ hình cũ mơ hình “Thác nước (waterfall)” hay “CMMI” Phương thức phát triển phần mềm Agile tập hợp phương thức phát triển lặp tăng dần yêu cầu giải pháp phát triển thông qua liên kết cộng tác nhóm tự quản liên chức a Mô tả - Dựa mơ hình iterative and incremental - Các u cầu giải pháp phát triển dựa kết hợp function - Trong Agile, tác vụ chia thành khung thời gian nhỏ để cung cấp tính cụ thể cho phát hành cuối b Ứng dụng - Có thể sử dụng với loại hình dự án nào, cần tham gia tính tương tác khách hàng - Sử dụng khách hàng yêu cầu chức sẵn sàng khoảng thời gian ngắn c Ưu điểm - Tăng cường tình thần làm việc nhóm trao đổi cơng việc hiệu - Các chức xây dựng nhanh chóng rõ ràng, dế quản lý - Dễ dàng bổ sung, thay đổi yêu cầu - Quy tắc tối thiểu, tài liệu dễ hiểu, dễ sử dụng d Nhược điểm - Mơ hình Agile sử dụng rộng rãi giới không đồng nghĩa với phù hợp với tất dự án phần mềm - Khơng thích hợp để xử lý phụ thuộc phức tạp - Có nhiều rủi ro tính bền vững, khả bảo trì khả mở rộng - Cần team có kinh nghiệm - Phụ thuộc nhiều vào tương tác rõ ràng khách hàng - Chuyển giao công nghệ cho thành viên nhóm khó khăn thiếu tài liệu 2.4 Mơ hình tiếp cận lặp Hình 4: mơ hình tiếp cận lặp a Mơ tả - Một mơ hình lặp lặp lại từ start làm đầy đủ spec Quá trình sau lặp lại, tạo phiên phần mềm vào cuối lần lặp mơ hình - Thay phát triển phần mềm từ spec đặc tả bắt đầu thực thi mơ hình review để đến yêu cầu cuối b Ứng dụng - Yêu cầu phải xác định; nhiên, số chức yêu cầu cải tiến phát triển theo thời gian - Một công nghệ sử dụng học tập nhóm phát triển làm việc dự án - Phù hợp cho dự án lớn nhiệm vụ quan trọng c Ưu điểm - Xây dựng hoàn thiện bước sản phẩm theo bước - Thời gian làm tài liệu so với thời gian thiết kế - Một số chức làm việc phát triển nhanh chóng sớm vịng đời - Ít tốn thay đổi phạm vi, yêu cầu - Dễ quản lý rủi ro - Trong suốt vòng đời, phần mềm sản xuất sớm để tạo điều kiện cho khách hàng đánh giá phản hồi d Nhược điểm - Yêu cầu tài nguyên nhiều - Các vấn đề thiết kế kiến trúc hệ thống phát sinh lúc - Yêu cầu quản lý phức tạp - Tiến độ dự án phụ thuộc nhiều vào giai đoạn phân tích rủi ro 2.5 Mơ hình tăng trưởng Hình 5: mơ hình tăng trưởng a Mơ tả - Spec chia thành nhiều phần - Chu kỳ chia thành module nhỏ, dễ quản lý - Mỗi module qua yêu cầu thiết kế, thực hiện, … vòng đời phát triển thông thường b Ứng dụng - Áp dụng cho dự án có u cầu mơ tả, định nghĩa hiểu cách rõ ràng - Khách hàng có nhu cầu sản phẩm sớm c Ưu điểm - Phát triển nhanh chóng - Mơ hình linh hoạt hơn, tốn thay đổi phạm vi yêu cầu - Dễ dàng việc kiểm tra sửa lỗi d Nhược điểm - Cần lập plan thiết kế tốt - Tổng chi phí cao so với mơ hình thác nước `2.6 Mơ hình chữ V( V model) Hình 6: mơ hình chữ V a Mơ tả - Mơ hình chữ V phần mở rộng mơ hình thác nước dựa kết hợp giai đoạn thử nghiệm cho giai đoạn phát triển tương ứng Đây mơ hình có tính kỷ luật cao giai đoạn bắt đầu sau hoàn thành giai đoạn trước - Với V model cơng việc test tham gia từ đầu b Ứng dụng - Yêu cầu xác định rõ ràng - Xác định sản phẩm ổn định - Công nghệ không thay đổi hiểu rõ nhóm dự án - Khơng có u cầu khơng rõ ràng không xác định - Dự án ngắn c Ưu điểm - Đây mơ hình có tính kỷ luật cao giai đoạn hoàn thành lúc - Hoạt động tốt cho dự án nhỏ, yêu cầu hiểu rõ - Đơn giản dễ hiểu dễ sử dụng, dễ quản lý d Nhược điểm - Khó quản lý kiểm sốt rủi ro, rủi ro cao - Khơng phải mơ hình tốt cho dự án phức tạp hướng đối tượng - Mơ hình cho dự án dài diễn - Không thích hợp cho dự án có nguy thay đổi u cầu trung bình đến cao 2.7 Mơ hình Scrum Hình 7: mơ hình Scrum a Mơ tả - Chia yêu cầu làm theo giai đoạn Mỗi giai đoạn(sprint) làm số lượng yêu cầu định - Mỗi sprint thường kéo dài từ tuần đến tuần ( ko dài tháng) - Đầu sprint lên kế hoạch làm yêu cầu Sau đó, thực code test Cuối sprint sản phẩm hoàn thiện code lẫn test demo chạy - Hoàn thành sprint 1, tiếp tục làm sprint 2, sprint hoàn thành hết yêu cầu - Trong sprint có họp hàng ngày – daily meeting từ 15 – 20 phút Mỗi thành viên báo cáo: Hôm qua làm gì? Hơm tơi làm gì? Có gặp khó khăn khơng? - Scrum mơ hình hướng khách hàng (Customer oriented) b Các nhân tố tạo nên quy trình Scrum - Có thành tố quan trọng cấu thành nên SCRUM: + Tổ chức (Organization) Tổ chức nhóm dự án Roles: Vai trị Product Owner: Người sở hữu sản phẩm ScrumMaster: Người điều phối Development Team: Nhóm phát triển + Tài liệu (Artifacts): kết đầu Product Backlog: Danh sách chức cần phát triển sản phẩm Sprint Backlog: Danh sách chức cần phát triển cho giai đoạn Estimation:Kết ước lượng team + Quy trình(Process): Quy định cách thức vận hành SCRUM Sprint Planning meeting: Hoạch định cho giai đoạn Review: Tổng kết cho giai đoạn Daily Scrum Meeting: Review hàng ngày c Tổ chức dự án - Product Owner + Product Owner người sở hữu sản phẩm, người định sản phẩm có chức người định Product Backlog + Thông thường Role khách hàng người đại diện cho khách hàng đảm nhận - ScrumMaster + Scrum Master người đảm bảo quy trình Scrum thực thuận lợi - Development Team + Một nhóm từ 4-7 kỹ sư phần mềm chịu trách nhiệm phát triển sản phẩm + Nhóm dự án phải làm việc với Product Owner để định làm Sprint (giai đoạn )này kết + Thảo luận để đưa giải pháp, ước lượng thời gian thực công việc, họp đánh giá kết công việc - Product Backlog + Product Backlog danh sách chức cần phát triển sản phẩm + Danh sách Product Owner định + Thường xuyên cập nhật để đáp ứng nhu cầu thay đổi khách hàng dự án d Ưu điểm - Một người thực nhiều việc ví dụ dev test - Phát lỗi sớm - Có khả áp dụng cho dự án mà yêu cầu khách hàng không rõ ràng từ đầu e Nhược điểm - Trình độ nhóm cần có kỹ định - Phải có hiểu biết mơ hình agile - Khó khăn việc xác định ngân sách thời gian - Luôn nghe ý kiến phản hồi từ khách hàng thay đổi theo, nên thời gian kéo dài - Vai trò PO quan trọng, PO người định hướng sản phẩm Nếu PO làm không tốt ảnh hưởng đến kết chung 2.8 Mơ hình RAD Hình 8: mơ hình RAD a Mơ tả - Mơ hình RAD phương pháp phát triển phần mềm sử dụng quy hoạch tối thiểu có lợi cho việc tạo mẫu nhanh - Các mô-đun chức phát triển song song nguyên mẫu tích hợp để tạo sản phẩm hoàn chỉnh để phân phối sản phẩm nhanh - Đảm bảo nguyên mẫu phát triển tái sử dụng b Ứng dụng - Mơ hình RAD áp dụng thành cơng cho dự án: - Module hóa rõ ràng Nếu dự án chia thành môđun, RAD khơng thành cơng - RAD nên sử dụng có nhu cầu để tạo hệ thống có yêu cầu khách hàng thay đổi khoảng thời gian nhỏ 2-3 tháng - Nên sử dụng có sẵn designer cho model chi phí cao c Ưu điểm - Giảm thời gian phát triển - Tăng khả tái sử dụng thành phần - Đưa đánh giá ban đầu nhanh chóng - Khuyến khích khách hàng đưa phản hồi d Nhược điểm - Trình độ nhóm cần có kỹ định - Chỉ hệ thống có module sử dụng mơ hình Câu 2: So sánh Waterfall Agile Sự khác biệt mơ hình Agile Waterfall: Agile Waterfall Nó tách vịng đời phát triển dự án thành chạy nước rút Quá trình phát triển phần mềm chia thành giai đoạn riêng biệt Nó theo cách tiếp cận gia tăng Phương pháp thác nước trình thiết kế Phương pháp nhanh biết đến với tính linh hoạt Thác phương pháp phát triển phần mềm có cấu trúc nên hầu hết thời gian cứng nhắc Agile coi sưu tập nhiều dự án khác Phát triển phần mềm hoàn thành dự án Agile phương pháp linh hoạt cho phép thay đổi thực yêu cầu phát triển dự án kế hoạch ban đầu hồn thành Khơng có phạm vi thay đổi u cầu phát triển dự án bắt đầu Phương pháp nhanh , theo cách Tất giai đoạn phát triển dự án tiếp cận phát triển lặp lại quy thiết kế, phát triển, thử nghiệm, hoạch, phát triển, tạo mẫu giai vv hoàn thành lần mô đoạn phát triển phần mềm khác có hình Thác thể xuất nhiều lần Kế hoạch kiểm tra xem xét sau lần chạy nước rút Kế hoạch kiểm tra thảo luận giai đoạn thử nghiệm Phát triển nhanh trình Phương pháp lý tưởng cho yêu cầu dự kiến dự án có yêu cầu định thay thay đổi phát triển đổi không mong đợi Trong phương pháp Agile, thử nghiệm thực đồng thời với phát triển phần mềm Trong phương pháp này, giai đoạn "Thử nghiệm" xuất sau giai đoạn "Xây dựng" Agile giới thiệu tư sản phẩm, nơi Mơ hình cho thấy tư dự sản phẩm phần mềm đáp ứng nhu cầu án đặt trọng tâm hồn tồn khách hàng cuối thay đổi vào việc hồn thành dự án theo nhu cầu khách hàng Agat methodology hoạt động đặc biệt tốt với Time & Materials tài trợ khơng cố định Nó làm tăng căng thẳng kịch giá cố định Giảm rủi ro hợp đồng giá cố định công ty cách nhận thỏa thuận rủi ro vào đầu q trình Thích nhóm nhỏ chun dụng với mức độ phối hợp đồng hóa cao Phối hợp / đồng hóa nhóm hạn chế Chủ sở hữu sản phẩm với nhóm chuẩn bị yêu cầu ngày dự án Phân tích kinh doanh chuẩn bị yêu cầu trước bắt đầu dự án Đội kiểm tra tham gia vào yêu cầu thay đổi mà vấn đề Thật khó để thử nghiệm bắt đầu thay đổi yêu cầu Mô tả chi tiết dự án thay đổi lúc q trình SDLC Mơ tả chi tiết cần thực phương pháp tiếp cận phát triển phần mềm thác nước Các thành viên Nhóm Agile hốn đổi cho nhau, đó, chúng hoạt động nhanh Cũng không cần thiết cho nhà quản lý dự án dự án quản lý tồn nhóm Trong phương pháp thác nước, quy trình ln đơn giản vậy, người quản lý dự án đóng vai trị thiết yếu giai đoạn SDLC Kết luận: - Agile Waterfall phương pháp phát triển phần mềm khác tốt theo cách tương ứng - Tuy nhiên, có số khác biệt lớn đánh dấu bên dưới: + Mơ hình thác nước lý tưởng cho dự án xác định yêu cầu khơng có thay đổi q trình phát triển Mặt khác, Agile phù hợp nhất, nơi có nhiều hội thay đổi yêu cầu thường xuyên + Thác nước dễ quản lý, cứng nhắc + Agile linh hoạt thay đổi giai đoạn + Trong trình Agile, u cầu thay đổi thường xun Tuy nhiên, mơ hình thác nước, định nghĩa lần nhà phân tích kinh doanh + Trong mơ tả Agile dự án, chi tiết thay đổi lúc q trình SDLC mà khơng thể thực phương thức Waterfall Nguồn: https://viblo.asia Hết (Cảm ơn Thầy xem hết báo cáo Nhóm) ... 1: Các mơ hình phát triển phần mềm: điều kiện đầu vào, vai trò tham gia, sản phẩm đầu phases (các activities) Định nghĩa mơ hình phát triển phần mềm: Các mơ hình phát triển phần mềm: 2.1 Mơ hình. .. phần mềm: điều kiện đầu vào, vai trò tham gia, sản phẩm đầu phases (các activities) Định nghĩa mơ hình phát triển phần mềm: Mơ hình phát triển phần mềm hay quy trình phát triển phần mềm xác định... 19 20 Chương I Đề tài tìm hiểu: Câu 1 :Các mơ hình phát triển phần mềm: điều kiện đầu vào, vai trò tham gia, sản phẩm đầu phases (các activities) Câu 2: So sánh Waterfall Agile Chương II Phân công

Ngày đăng: 22/06/2022, 22:28

Hình ảnh liên quan

Câu 1:Các mô hình phát triển phần mềm: điều kiện đầu vào, vai trò tham gia, sản phẩm đầu ra của các phases (các activities). - BÁO CÁO MÔN QUẢN LÝ DỰ ÁN PHẦN MỀM  Các mô hình phát triển phần mềm điều kiện đầu vào, vai trò tham gia, sản phẩm đầu ra của các phases (các activities).

u.

1:Các mô hình phát triển phần mềm: điều kiện đầu vào, vai trò tham gia, sản phẩm đầu ra của các phases (các activities) Xem tại trang 3 của tài liệu.
2. Các mô hình phát triển phần mềm: - BÁO CÁO MÔN QUẢN LÝ DỰ ÁN PHẦN MỀM  Các mô hình phát triển phần mềm điều kiện đầu vào, vai trò tham gia, sản phẩm đầu ra của các phases (các activities).

2..

Các mô hình phát triển phần mềm: Xem tại trang 5 của tài liệu.
2.3. Mô hình Agile - BÁO CÁO MÔN QUẢN LÝ DỰ ÁN PHẦN MỀM  Các mô hình phát triển phần mềm điều kiện đầu vào, vai trò tham gia, sản phẩm đầu ra của các phases (các activities).

2.3..

Mô hình Agile Xem tại trang 9 của tài liệu.
2.4. Mô hình tiếp cận lặp - BÁO CÁO MÔN QUẢN LÝ DỰ ÁN PHẦN MỀM  Các mô hình phát triển phần mềm điều kiện đầu vào, vai trò tham gia, sản phẩm đầu ra của các phases (các activities).

2.4..

Mô hình tiếp cận lặp Xem tại trang 11 của tài liệu.
2.5. Mô hình tăng trưởng - BÁO CÁO MÔN QUẢN LÝ DỰ ÁN PHẦN MỀM  Các mô hình phát triển phần mềm điều kiện đầu vào, vai trò tham gia, sản phẩm đầu ra của các phases (các activities).

2.5..

Mô hình tăng trưởng Xem tại trang 12 của tài liệu.
- Mô hình này linh hoạt hơn, ít tốn kém hơn khi thay đổi phạm vi và yêu cầu. - BÁO CÁO MÔN QUẢN LÝ DỰ ÁN PHẦN MỀM  Các mô hình phát triển phần mềm điều kiện đầu vào, vai trò tham gia, sản phẩm đầu ra của các phases (các activities).

h.

ình này linh hoạt hơn, ít tốn kém hơn khi thay đổi phạm vi và yêu cầu Xem tại trang 13 của tài liệu.
- Đây là một mô hình có tính kỷ luật cao và các giai đoạn được hoàn thành cùng một lúc. - BÁO CÁO MÔN QUẢN LÝ DỰ ÁN PHẦN MỀM  Các mô hình phát triển phần mềm điều kiện đầu vào, vai trò tham gia, sản phẩm đầu ra của các phases (các activities).

y.

là một mô hình có tính kỷ luật cao và các giai đoạn được hoàn thành cùng một lúc Xem tại trang 14 của tài liệu.
2.8. Mô hình RAD - BÁO CÁO MÔN QUẢN LÝ DỰ ÁN PHẦN MỀM  Các mô hình phát triển phần mềm điều kiện đầu vào, vai trò tham gia, sản phẩm đầu ra của các phases (các activities).

2.8..

Mô hình RAD Xem tại trang 18 của tài liệu.

Tài liệu cùng người dùng

Tài liệu liên quan