Mô hình vòng đời phát triển phần mềm

Chương Mô hình vòng đời phát triển phần mềm  Nếu bạn đâu, chọn đ ường đ ược  Nếu bạn bạn đâu, kể đồ không th ể giúp đ ỡ bạn - Watts Humphrey Mỗi chương trình có vòng đời phát triển Không quan trọng nó: lớn hay nhỏ, có người làm việc dự án - tất phần mềm qua bước: Khái niệm Thu thập yêu cầu / thăm dò / mô hình Thiết kế Viết Code gỡ rối (Coding and debugging) Thử nghiệm Triển khai cài đặt Bảo trì / Cải tiến phần mềm Nghỉ hưu Chương trình người nén số bước, kết hợp hai nhiều bước thành , tất chương trình phải qua đủ tất bước Một kiểu mô hình! Nhưng tất mô hình: Code and Fix  Code & Fix Mô hình phát triển phần mềm Đó hầu hết làm phát triển dự án nhỏ mình, cho đối tác  Các mô hình code fix , thường sử dụng thay cho quản lý dự án thực tế Trong mô hình yêu cầu thức, tài liệu cần thiết, không đảm bảo chất lượng thử nghiệm thức, phát hành cách bừa bãi Thậm chí ước tính nhân lực, thời gian hay lịch trình  Code fix cần khoảng thời gian tối thiểu để hiểu vấn đề sau bắt đầu viết code Biên dịch code chạy thử Nếu không hoạt động, fix vấn đề mà bạn nhìn thấy thử lại lần Tiếp tục chu kỳ chương trình bạn muốn, lỗi gây chết chương trình bán Một kiểu mô hình! Nhưng tất mô hình: Code and Fix đây cách tuyệt vời để làm nguyên mẫu nhanh chóng chương trình nhỏ Nó hữu ích để định kiến trúc thể phiên nhanh chóng thiết kế giao diện người dùng Sử dụng để hiểu vấn đề lớn 2.1 Quá trình code and fix không mô hình Mô hình thác nước  Mô hình truyền thống mô hình PTPM có định hướng kế hoạch mô hình thác nước Nó tạo vào năm 1970 Winston Royce, có đầy đủ giai đoạn chu kỳ vòng đời tiêu chuẩn : Thu thập yêu cầu , phân tích, thiết kế kiến trúc, thiết kế chi tiết, mã hóa, gỡ lỗi, kiểm tra hệ thống, phát hành bảo trì Nó đòi hỏi phải có tài liệu chi tiết giai đoạn, với đánh giá, lưu trữ tài liệu, sign-off giai đoạn quy trình, quản lý cấu hình, quản lý chặt chẽ toàn dự án  Mô hình định hướng kế hoạch Mô hình thác nước 2.2 Quá trình mô hình thác nước Mô hình thác nước  Có hai vấn đề liên quan tới mô hình thác nước làm cản trở chấp nhận làm cho khó để thực Đầu tiên, thường yêu cầu bạn hoàn thành giai đoạn N trước bạn tiếp tục vào giai đoạn N + điều có nghĩa bạn phải nắm tất yêu cầu bạn trước bạn bắt đầu thiết kế kiến trúc, kết thúc việc code and fix bạn trước bạn bắt đầu bất kiểm thử, vvv, Về lý thuyết, điều tốt Bạn có đầy đủ yêu cầu, bạn hiểu xác khách hàng muốn, bạn sau tự tin chuyển sang thiết kế hệ thống Mô hình thác nước  Vấn đề 1: Ta có dự án mà tất yêu cầu nắm từ bắt đầu Không có dự án mà trình phát triển thay đổi Vì vậy, kết thúc giai đoạn trước bắt đầu giai đoạn khác có vấn đề  Vấn đề 2: Mô hình điều khoản cho việc lưu Nó dựa tâm lý dây chuyền lắp ráp cho phát triển phần mềm Sơ đồ cho thấy cách để quay trở lại làm lại thiết kế bạn bạn tìm thấy vấn đề trình thực Điều tương tự vấn đề Trong thực tế điều không thực tiễn Thế giới không làm việc theo cách Bạn tất thứ cần thiết trước xảy Mô hình thác nước  Như biết, mô hình thác nước lý thuyết tuyệt vời Nó phân lập giai đoạn khác chu kỳ sống buộc bạn phải suy nghĩ bạn thực cần phải biết trước bạn di chuyển tiếp Nó cách tốt để bắt đầu nghĩ dự án lớn; mang lại cho nhà quản lý an tâm cho phép họ nghĩ họ biết xảy (thực họ vấn đề khác) Nó mô hình tốt cho đội thiếu kinh nghiệm làm việc, dự án dẫn họ qua chu kỳ sống  Nhưng mô hình thác nước mô hình thực tiễn tốt, chuyển thành mô hình khác Sơ kết Sprint - Sprint Review  Được tổ chức Sprint kết thúc để 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 n ếu cần Trong họp này, Nhóm Scrum bên hữu quan trao đổi với v ề nh ững v ừa hoàn thành Sprint v ừa r ồi Trên c s thay đổi Product Backlog suốt Sprint, ng ười tham dự h ọp s ẽ h ợp tác đ ể th ảo luận v ề nh ững công vi ệc s ắp triển khai Cuộc họp chủ yếu nhằm mục đích cung cấp phản h ồi h ữu ích khuy ến khích s ự c ộng tác gi ữa bên  Cuộc họp đóng khung bốn cho Sprint có đ ộ dài tháng ( 2h cho Sprint hai tu ần )  Buổi Sơ kết Sprint có số đặc điểm sau:   Product Owner nhận biết phần “Hoàn thành” phần chưa “Hoàn thành”;  Nhóm Phát triển thảo luận điều thu ận lợi, khó khăn mà nhóm tr ải qua, cách th ức gi ải quy ết v ấn đ ề đó;  Nhóm Phát triển trình diễn phần việc “Hoàn thành” tr ả l ời câu h ỏi c c t ọa v ề gói tăng tr ưởng;  Product Owner trao đổi Product Backlog D ựa tiến độ thời, Product Owner đ ưa d ự đoán ngày hoàn thành d ự án; ,  Toàn nhóm thảo luận làm, nhờ bu ổi Sơ kết Sprint cung cấp giá tr ị đ ầu vào cho bu ổi H ọp K ế ho ạch Sprint ti ếp theo Kết họp Sơ kết Sprint Product Backlog đ ược cập nh ật, với h ạng mục dự định s ẽ đ ược tri ển khai Sprint tới Product Backlog điều chỉnh toàn di ện đ ể thích ứng v ới c h ội m ới Cải tiến Sprint - Sprint Retrospective  Buổi họp hội để Nhóm Scrum tự tra đưa k ế hoạch cho c ải ti ến Sprint ti ếp theo  Được tổ chức sau Sơ kết Sprint trước Họp Kế hoạch Sprint diễn Cuộc h ọp đ ược đóng khung ph ạm vi ba cho Sprint tháng (1.5h cho sprint tu ần)  Mục đích họp Cải tiến Sprint để:  Thanh tra lại tất yếu tố Sprint vừa diễn ra, từ người, m ối quan h ệ, quy trình, công cụ;  Nhận biết xếp đặt lại hạng mục chủ chốt thực tốt, cải tiến dự định; và,  Tạo kế hoạch để triển khai cải tiến cách thức làm việc Nhóm Scrum  Scrum Master động viên Nhóm Scrum để cải tiến, phạm vi khung làm vi ệc Scrum, quy trình phát tri ển bi ện pháp th ực hành đ ể nâng cao hiệu thú vị cho Sprint Trong cu ộc h ọp Cải ti ến Sprint, Nhóm Scrum s ẽ l ập k ế ho ạch đ ể gia tăng ch ất l ượng s ản phẩm việc định nghĩa lại Định nghĩa “Hoàn thành” cần thiết  Kết thúc họp Cải tiến Sprint, Nhóm Scrum phải nhận biết cải tiến triển khai Sprint tới Vi ệc tri ển khai c ải tiến thích nghi thân Nhóm Scrum M ặc dù c ải ti ến có th ể đ ược tri ển khai t ại b ất kì th ời ểm đó, cu ộc họp Cải tiến Sprint cung cấp phiên làm việc thức đ ể tập trung vào vi ệc tra thích nghi Đồ nghề Scrum – Artifact  Các đồ nghề Scrum biểu đạt công việc giá trị b ằng nhi ều cách h ữu ích đ ể cung c ấp tính minh b ạch c hội cho việc tra thích nghi  Các đồ nghề Scrum thiết kế để tối đa hóa tính minh b ạch thông su ốt c thông tin c ần thi ết đ ể đ ảm b ảo Nhóm Scrum thành công việc chuyển giao gói tăng tr ưởng đ ạt tiêu chu ẩn “Hoàn thành” Product Backlog – Sản phẩm tồn đọng  Là danh sách thứ tự tất cần thi ết sản phẩm Nó nguồn yêu c ầu nh ất th ể hi ện thay đ ổi sản phẩm Product Owner người chịu trách nhiệm Product Backlog, nội dung nó, hi ện di ện, th ứ t ự h ạng m ục  Product Backlog không hoàn ch ỉnh Phiên b ản sớm nh ất c Product Backlog ch ỉ cho th yêu c ầu đ ược tìm hi ểu rõ ràng từ lúc Product Backlog tiến hóa với v ới sản phẩm môi tr ường mà đ ược s d ụng Product Backlog động, thay đổi thường xuyên để nhận bi ết nh ững mà sản phẩm cần ph ải có đ ể có tính c ạnh tranh h ữu ích Chừng sản phẩm đó, Product Backlog diện Product Backlog li ệt kê t ất c ả tính (feature), ch ức năng, yêu cầu, cải thiện, vá lỗi cần thiết để làm nên sản ph ẩm tương lai Các hạng m ục Product Backlog đ ược mô t ả v ới thuộc tính như: mô tả, thứ tự, ước lượng  Product Backlog thường xếp theo giá trị, đ ộ r ủi ro, đ ộ ưu tiên, s ự c ần thi ết Các h ạng m ục đ ứng đ ầu danh sách s ẽ trực tiếp điều khiển hoạt động phát triển Càng thứ tự cao hơn, hạng mục đ ược quan tâm nhi ều h ơn, đ ược tập trung nỗ lực nhiều giá trị chúng Các h ạng mục có th ứ tự cao h ơn rõ ràng chi ti ết h ơn Ước l ượng s ẽ xác hạng mục rõ ràng chi tiết h ơn Hạng mục Product Backlog s ắp tham gia vào Sprint t ới ph ải đ ược phân tách cho hạng mục hoàn thành khung th ời gian c Sprint  Khi sản phẩm đưa vào sử dụng mang lại giá tr ị, thị tr ường cung cấp phản h ồi, Product Backlog s ẽ tr thành m ột danh sách lớn toàn diện Nhu cầu không ng ừng thay đ ổi, th ế m ột Product Backlog m ột th ực th ể s ống đ ộng S ự thay đổi yêu cầu nghiệp vụ, điều ki ện th ị tr ường, hay công ngh ệ có th ể d ẫn đ ến thay đ ổi Product Backlog  Việc “làm mịn” (grooming) Product Backlog hoạt đ ộng thêm vào chi tiết, ước lượng, trình t ự c h ạng m ục Product Backlog Đây trình liên tục, theo Product Owner Nhóm Phát tri ển th ảo lu ận v ề chi ti ết c t ừng h ạng m ục Trong suốt trình làm mịn này, hạng mục liên tục đ ược xem xét rà soát cẩn th ận Tuy nhiên, chúng có th ể đ ược c ập nh ật thời điểm Product Owner  Việc làm mịn hoạt động bán thời gian Product Owner Nhóm Phát triển Thông th ường, Nhóm Phát tri ển s ẽ có hi ểu biết để tự thực việc làm mịn Thời điểm cách thức th ực việc làm m ịn s ẽ đ ịnh b ởi Nhóm Scrum Quá trình làm mịn thường không tiêu tốn nhiều h ơn 10% lượng th ời gian c Nhóm Phát tri ển  Nhóm Phát triển chịu trách nhiệm việc ước lượng Product Owner gây ảnh h ưởng lên Nhóm băng cách giúp h ọ hi ểu l ựa chọn tình khó, người trực ti ếp làm việc đ ưa s ố ước lượng cuối Kiểm soát tiến độ hướng đến Mục tiêu  Tại thời điểm nào, tổng khối lượng công việc lại để đạt mục tiêu ph ải đ ược nhóm tổng k ết Prododuct Owner theo dõi lượng công việc lại lần buổi họp Sơ kết Sprint Product Owner so sánh giá tr ị v ới l ượng th ời gian l ại tính từ Sprint trước để đánh giá tiến độ hướng đến th ời điểm dự tính hoàn thành mục tiêu c d ự án  Thông tin minh bạch trước tất bên h ữu quan  Rất nhiều phương pháp sử dụng để biểu thị tiến độ công việc, bi ểu đồ burndown, bi ểu đ burnup hay phương pháp dự báo khác Các biện pháp chứng minh h ữu ích Tuy nhiên, nh ững th ứ không thay th ế đ ược tầm quan trọng tính thực nghiệm trình phát triển Trong môi tr ường ph ức tạp, ta không th ể bi ết đ ược nh ững ều xảy Chỉ dựa điều xảy để đưa định cho tương lai Sprint Backlog  Sprint Backlog tập hợp hạng mục Product Backlog đ ược lựa ch ọn đ ể phát triển Sprint, kèm theo m ột k ế ho ạch đ ể chuyển giao phần tăng trưởng sản phẩm hi ện th ực hóa Mục tiêu Sprint Sprint Backlog m ột b ản d ự báo c Nhóm Phát triển chức có phần tăng tr ưởng chuy ển giao  Sprint Backlog xác định công việc mà Nhóm Phát triển ph ải làm đ ể bi ến h ạng m ục Product Backlog thành ph ần tăng trưởng đạt tiêu chuẩn “Hoàn thành” Sprint Backlog cho th tất c ả nh ững vi ệc Nhóm Phát tri ển c ần ph ải làm đ ể ti ến t ới M ục tiêu Sprint  Sprint Backlog kế hoạch với chi tiết vừa đ ủ đ ể nh ững thay đ ổi v ề ti ến đ ộ công vi ệc có th ể nhìn th đ ược cu ộc họp Scrum Hằng ngày Nhóm Phát triển chỉnh sửa Sprint Backlog suốt Sprint, Sprint Backlog s ẽ đ ược c ập nh ật su ốt thời gian Sự cập nhật xảy Nhóm Phát triển làm việc theo k ế ho ạch h ọ, hi ểu rõ h ơn v ề công vi ệc c ần thiết để đạt Mục tiêu Sprint  Mỗi có thêm việc mới, Nhóm Phát triển đưa vào Sprint Backlog Khi công vi ệc b đ ầu hay k ết thúc, giá tr ị ước l ượng v ề th ời gian lại để hoàn tất công việc cập nhật Khi có ph ần k ế ho ạch không c ần thiết, chúng s ẽ b ị b ỏ Ch ỉ có Nhóm Phát triển thay đổi Sprint Backlog Sprint Sprint Backlog m ột b ức tranh th ời gian th ực v ề công vi ệc mà Nhóm Phát triển lên kế hoạch để hoàn thành Sprint, c b ản thu ộc v ề Nhóm Phát tri ển Kiểm soát tiến độ Sprint  Tại thời điểm Sprint, tổng lượng thời gian lại đ ể hoàn thành công vi ệc có th ể tính toán đ ược Nhóm Phát tri ển theo dõi số thường xuyên, vào họp Scrum Hằng ngày Dựa vào vi ệc theo dõi này, h ọ có th ể d ự báo tiến độ đạt đến Mục tiêu Sprint Theo đó, họ quản lý đ ược ti ến đ ộ công vi ệc  Scrum không quan tâm đến lượng thời gian b ỏ h ạng m ục Sprint Backlog Scrum ch ỉ quan tâm đ ến l ượng th ời gian l ại thời điểm hoàn thành công việc Gói tăng trưởng - Increment  Gói tăng trưởng tập hợp tất hạng mục Product Backlog đ ược hoàn thành su ốt Sprint hi ện t ại nh ững Sprint trước Cuối Sprint, gói tăng trưởng ph ải th ỏa mãn ều ki ện “Hoàn thành”, có nghĩa ph ải tr ạng thái sử dụng thỏa mãn định nghĩa Nhóm Scrum “Hoàn thành”  Gói tăng trưởng phải trạng thái dùng để Product Owner quy ết đ ịnh phát hành Định nghĩa “Hoàn thành”  Khi hạng mục Product Backlog Gói tăng tr ưởng cho “Hoàn thành”, ng ười ph ải hi ểu rõ “Hoàn thành” nghĩa Mặc dù việc xác đ ịnh rõ định nghĩa hoàn toàn ph ụ thu ộc vào t ừng Nhóm Scrum, nh ưng m ọi thành viên phải chia sẻ chung cách hiểu việc hoàn thành công vi ệc, đ ể đ ảm b ảo tính minh b ạch thông su ốt “Đ ịnh nghĩa Hoàn thành” dùng để đánh giá công vi ệc th ực hoàn thành m ỗi gói tăng tr ưởng c s ản ph ẩm  Định nghĩa giống dẫn cho Nhóm Phát triển nắm số lượng hạng mục Product Backlog có th ể đ ược lựa ch ọn cho Sprint Mục đích Sprint để chuyển giao Gói tăng trưởng ch ức có ti ềm chuy ển giao đ ược tuân thủ “Định nghĩa Hoàn thành: Nhóm Scrum  Mỗi Sprint, Nhóm Phát triển chuyển giao Gói tăng tr ưởng Ph ần tăng trưởng ph ải kh ả dụng, đ ể Product Owner có th ể l ựa chọn phát hành Mỗi gói tăng tr ưởng đ ược cộng d ồn vào gói tăng tr ưởng tr ước đ ược ki ểm th toàn để đảm bảo chúng làm việc tốt với  Khi Nhóm Scrum ngày trưởng thành “Định nghĩa Hoàn thành” đ ược m r ộng v ới ch ỉ tiêu kh khe h ơn đ ể đ ạt ch ất lượng cao Scrum, mate Những ý tưởng phương pháp Scrum đội bóng nhỏ thống theo mục tiêu chạy nước rút cho phát triển để di chuyển chúng tới mục tiêu Scrum sử dụng đội ngũ không 10 nhà phát triển Cũng giống phương pháp linh hoạt khác, scrum nhấn mạnh hiệu đội ngũ nhỏ sở hữu tập thể Scrum đặc trưng chạy nước rút, lặp lặp lại từ đến bốn tuần Chạy nước rút timeboxed có khoảng thời gian cố định đầu nước rút làm việc theo nhóm hoàn thành thời gian chạy nước rút Scrum, mate Yêu cầu Scrum gói gọn hai phần tồn đọng Việc tồn đọng sản phẩm vấn đề ưu tiên tất yêu cầu dự án; tạo đội scrum nhà sở hữu sản phẩm Một việc chạy nước rút bắt đầu, có nhóm phát triển thêm mục vào phần tồn đọng chạy nước rút, không tổ chức bên thêm mục vào phần tồn đọng chạy nước rút, để tồn đọng sản phẩm Scrum, mate Dự án Scrum có họp hàng ngày, nơi toàn nhóm thảo luận tiến độ chạy nước rút Bất sơ suất lịch trình vấn đề việc thực rõ ràng sau giải nhóm lúc Tại họp Scrum, thành viên nhóm trả lời ba câu hỏi sau đây: Bạn hoàn thành nhiệm vụ kể từ họp Scrum cuối cùng? Có vấn đề xảy trình bạn hoàn thành nhiệm vụ hay không? Bạn có dự định làm nhiệm vụ khoảng từ đến họp Scrum tiếp theo? Scrum, mate Trước lần chạy nước rút bắt đầu, Scrum có giai đoạn lập kế hoạch ban đầu tạo danh sách yêu cầu ban đầu Nhiệm vụ lần chạy nước rút không nên dài nỗ lực ngày Sau lần chạy nước rút, họp kế hoạch khác tổ chức nơi người chủ Scrum nhóm ưu tiên sản phẩm tồn đọng tạo backlog cho lần chạy nước rút Sau lên kế hoạch cho lần nước rút cuối cùng, nước rút cuối thực để kết thúc dự án Lần chạy nước rút thực chức mới, mà để chuẩn bị chuyển giao cho phát hành sản phẩm Kết luận Như thấy từ phương pháp mô tả chương này, lặp lặp lại chìa khóa, cho dù bạn sử dụng trình định hướng tiến triển hay phát triển linh hoạt Cách tốt để xây dựng đoạn phức tạp phần mềm làm bước Tìm hiểu designing, writing, testing, and delivering bước bạn để viết phần mềm hoàn hảo [...]... theo đ ể phát tri ển ph ần m ềm  Ta thường nhầm lẫn “Qui trình PTPM” với thuật ngữ vòng đời ph ần mềm  Vòng đời phần mềm có xu hướng rất trừu tượng, mô tả các giai đo ạn chung c ủa các d ự án phát tri ển ph ần m ềm Vòng đời phần mềm còn nhiều hơn phát triển hệ thống hay sản phẩm; nó nói t ới con đ ường t ừ cái nôi t ới n ấm m ồ mà các yêu cầu được thu thập và phân tích, và phần mềm được phát triển, ... kiểm th ử, triển kh ải, b ảo trì, và cu ối cùng cho nghỉ việc  Mô hình vòng đời tương tự, có tên là V -mô hình (Forsberg et al., 1996) T ổ ch ức t ạm th ời chung c ủa nh ững pha t ổng quát này thường định nghĩa loại vòng đời phần mềm mà một tổ chức dùng  Được tổ chức theo cách này, vòng đời có thể là thác đ ổ, và theo cách khác nó có th ể là l ặp hay xoáy ốc Mô hình xoắn ốc của Boehm Mô hình chữ V... mô hình m ới cho phát triển phần mềm Trái ngược với các mô hình kế ho ạch đ ịnh h ướng ph ức tạp nêu trên và đ ược tán thành b ởi các tổ chức như Viện Công nghệ phần mềm (SEI) tại Đại học Carnegie Mellon, mô hình quy trình m ới này khá đ ơn giản Nó đòi hỏi ít tài liệu h ướng dẫn và ít quá trình đi ều khi ển h ơn Nó nh ắm m ục tiêu vào các d ự án ph ần mềm nhỏ và vừa và các đội nhỏ hơn của các nhà phát. .. vào các d ự án ph ần mềm nhỏ và vừa và các đội nhỏ hơn của các nhà phát triển Nó đ ược d ự đ ịnh đ ể cho phép các nhà phát tri ển nhanh chóng điều chỉnh để thay đ ổi các yêu cầu và nhu c ầu c ủa khách hàng, và nó đ ược đ ề xu ất đ ể phát hành phần mềm hoàn thành nhanh h ơn nhiều so với các mô hình k ế ho ạch đ ịnh h ướng Đó là mô hình ptpm linh hoat -nhanh nhẹn " AGILE  Phương pháp Agile là tuyệt hảo... Mục tiêu của việc xây dựng một mô hình dự án là để phân chia d ự án thành các m ảnh thành ph ần , m ỗi trong số đó có cùng một đặc điểm là : mỗi ho ạt động phải được xác đ ịnh b ởi có b ước tiến v ới tiêu chu ẩn hoàn thi ện m ục tiêu Phân phôi trình diễn đ ược th ực hi ện hoặc không đ ược th ực hi ện " Các mô hình phát triển gia tăng Cách truyền thống để thực hiện các mô hình gia tăng đ ược g ọi là... các công ngh ệ đ ược hi ểu rõ  Các vòng đời lặp hay xoáy ốc thường được dùng trong hoàn cảnh doanh nghiệp n ơi các yêu c ầu là bi ến đ ộng, công ngh ệ không đ ược hiểu rõ, hay cả hai  Theo lí thuyết, việc lặp giúp nhận diện và kiểm soát r ủi ro do các yêu cầu bi ến đ ộng hay công ngh ệ thách th ức s ớm h ơn là cách ti ếp cận thác đổ Các vòng đời phát triển phần mềm lặp dường nh ư là được ưa chuộng... sư phần mềm chứ KHÔNG ĐƠN THUẦN là người lập trình Chúng ta sẽ xem xét hai phương pháp linh hoạt: 1.Lập trình eXtreme 2.Scrum Lập trình eXtreme (XP)  Lập trình eXtreme đã tạo ra khoảng năm 1995 bởi Kent Beck và Ward Cunningham XP là một cách “nhẹ nhàng, hiệu quả, ít rủi ro, linh hoạt, có thể dự đoán, khoa học, và thú vị để phát triển phần mềm. “  Là phương pháp linh hoạt dành cho các nhóm phát triển. .. trả này ở mức thấp do vậy sẽ thúc đẩy môi trường sản xuất phần mềm Tổng quan XP XP dựa trên bốn ý tưởng cơ bản sau đây: • Sự tham gia tích cực của khách hàng • Thử nghiệm đơn vị liên tục (còn được gọi là thử nghiệm điều khiển phát triển [TDD]) • Lập trình Cặp • Chu kỳ lặp ngắn và phát hành thường xuyên Động lực của XP  Rủi ro là vấn đề cơ bản nhất trong phần mềm Nó có th ể biểu hi ện b ằng nhi ều... c ải ti ến s ử d ụng thông tin ph ản h ồi c ủa khách hàng và kết quả của hội nhập và kiểm tra hệ th ống Đây là m ột mô hình lý tưởng cho m ột môi tr ường thay đổi hoặc yêu cầu không rõ ràng, ho ặc m ột miền ứng d ụng ch ưa đ ược hi ểu rõ Đây là mô hình phát tri ển thành các quá trình phát tri ển linh ho ạt hi ện đ ại Tạo mẫu tiến hóa công nhận rằng nó rất khó để lên kế hoạch các d ự án đ ầy đ ủ t... phát sinh nhiều chi phí  XP sử dụng các nhóm làm việc kết hợp gồm những người lập trình, khách hàng và các nhà quản trị để phát triển phần mềm có chất lượng cao trong thời gian nhanh chóng Một chương trình chạy được là thước đo đầu tiên của tiến trình theo XP XP có thể phát triển và tồn tại được là do sự hiểu biết ngày một tiến bộ về các vấn đề đang giải quyết và cũng là vì các công cụ sẵn có cho ... Fix  Code & Fix Mô hình phát triển phần mềm Đó hầu hết làm phát triển dự án nhỏ mình, cho đối tác  Các mô hình code fix , thường sử dụng thay cho quản lý dự án thực tế Trong mô hình yêu cầu thức,... fix không mô hình Mô hình thác nước  Mô hình truyền thống mô hình PTPM có định hướng kế hoạch mô hình thác nước Nó tạo vào năm 1970 Winston Royce, có đầy đủ giai đoạn chu kỳ vòng đời tiêu chuẩn... ột mô hình m ới cho phát triển phần mềm Trái ngược với mô hình kế ho ạch đ ịnh h ướng ph ức tạp nêu đ ược tán thành b ởi tổ chức Viện Công nghệ phần mềm (SEI) Đại học Carnegie Mellon, mô hình