IT003-111-T19_Nhóm 10_Case study 7.4 DANH SÁCH THÀNH VIÊN NHÓM ST T Mã SV Họ và tên Nhiệm vụ Ký tên 1 030125090540 Nguyễn Thị Hoàng Ngân - Tìm tài liệu, dịch bài, bài phân tích, trả lời câu hỏi 2 030125090515 Nguyễn Thảo Nguyên - Tìm tài liệu, dịch bài, làm powerpoint, kịch bản thuyết trình 3 030125090992 Phạm Thị Minh Tâm - Tìm tài liệu, thuyết trình, trả lời câu hỏi 4 030125090812 Nguyễn Lâm Ngọc Thảo - Tìm tài liệu, bài phân tích, giải pháp, kết luận, tổng hợp bài word, chỉnh sửa word 5 030125090758 Cấn Thị Minh Thúy - Tìm tài liệu, dịch bài, bài phân tích, trả lời câu hỏi 6 030125090909 Thái Lai Thị Minh Trang - Tìm tài liệu, lời mở đầu, tóm tắt case study, chỉnh sửa word 1 IT003-111-T19_Nhóm 10_Case study 7.4 MỤC LỤC LỜI MỞ ĐẦU 3 BÀI DỊCH CASE STUDY 4 TÓM TẮT TÌNH HUỐNG 7 BÀI PHÂN TÍCH 8 1. Mô hình thác nước (Waterfall model) 8 1.1. Đặc điểm 8 1.1.1. Khái niệm 8 1.1.2. Các giai đoạn của mô hình thác nước 8 1.2. Ưu điểm, nhược điểm của mô hình thác nước 11 1.2.1. Ưu điểm 11 1.2.2. Nhược điểm 11 2. Phương pháp phát triển linh hoạt Agile 13 2.1. Đặc điểm 13 2.2. Ưu điểm, nhược điểm của phương pháp Agile 14 2.2.1. Ưu điểm 14 2.2.2. Nhược điểm 15 3. Giải pháp 17 4. Kết luận 19 TÀI LIỆU THAM KHẢO 20 LỜI MỞ ĐẦU Ngày nay, với sự phát triển mạnh mẽ của nền kinh tế và mức độ cạnh tranh giữa các doanh nghiệp ngày càng khốc liệt, việc ứng dụng công nghệ thông tin vào các hoạt động kinh tế, sản xuất kinh doanh, bán hàng, xúc tiến thương mại, quản trị doanh nghiệp… là rất quan trọng tuy nhiên chỉ 2 IT003-111-T19_Nhóm 10_Case study 7.4 dừng lại ở những hệ thống thông tin hỗ trợ cho cấp tác nghiệp là chưa đủ. Hệ thống thông tin trong kinh doanh càng lúc càng đi sâu và phát triển mạnh mẽ hơn, hỗ trợ cho cả việc ra quyết định, điều hành doanh nghiệp, đây là nhân tố góp phần vào sự thành công của doanh nghiệp. Song, vấn đề khó khăn là làm thế nào để nhà quản trị chọn lựa được giải pháp tốt nhất phù hợp với mô dình doanh nghiệp để xây dựng hiệu quả hệ thống thông tin kinh doanh. Trong đó, công cụ ứng dụng của công nghệ thông tin được sử dụng rộng rãi và phổ biến đó là các mô hình phát triển phần mềm. Và phương pháp cổ điển mô hình thác nước (Waterfall Method) ra đời vào năm 1970, là một mô hình nổi tiếng và vẫn được áp dụng trong quy trình phát triển phần mềm tại một số các công ty ra đời hiện nay. Mô hình này hỗ trợ cho việc thiết kế, sản xuất phần mềm theo yêu cầu của khách hàng. Tuy nhiên, trong sự phát triển nhanh chóng của công nghệ cùng với những thay đổi thường xuyên của môi trường xung quanh như kinh tế tài chính, thông tin,… Mô hình thác nước ngày càng bộc lộ những thiếu sót của mình từ đó dẫn đến sự xuất hiện những phương pháp phát triển phần mềm mới, linh hoạt hơn, nhanh chóng hơn và tiết kiệm hơn. Và phương pháp phát triển linh hoạt (Agile Development Methods) là một phần của xu hướng tất yếu được tạo ra dựa trên tiêu chí nhanh nhẹn và linh hoạt Vậy đâu là sự lựa chọn tốt nhất giữ mô hình thác nước và phương pháp Agile. Liệu phương pháp Agile có thật sự tốt để thay thế cho mô hình truyền thống thác nước. Đây chính là đề tài mà nhóm muốn nhắc đến, bài làm của nhóm vẫn còn nhiều sai sót, rất chân thành đón nhận sự góp ý của thầy và các bạn. Xin chân thành cảm ơn! 3 IT003-111-T19_Nhóm 10_Case study 7.4 BÀI DỊCH CASE STUDY BÀI TẬP TÌNH HUỐNG 7.4 SỬ DỤNG PHƯƠNG PHÁP THÁC NƯỚC- WATERFALL, PHÁT TRIỂN LINH HOẠT- AGILE TẠI CÔNG TY TÀI CHÍNH MELLON Sự chuyển hướng của Công ty tài chính Mellon sang phương pháp phát triển phần mềm linh hoạt - Agile là một phần của một xu hướng mới. "Mỗi ngân hàng đầu tư và quỹ phòng ngừa rủi ro mà tôi đã nói đều đang nhắm đến phương pháp Agile" ông Chapman của hãng SunGard nói. Phương pháp phát triển linh hoạt- một thuật ngữ tương đối mới được dựa trên sự phát triển lặp- có nghĩa là phát triển phần mềm trong những phân khúc nhỏ, dễ quản lý, có thể được sửa đổi vì nhu cầu thay đổi, nhưng vẫn sử dụng cơ chế phân phối một cách nghiêm ngặt. Trong lịch sử, sự tiếp cận phát triển phần mềm sử dụng khắp phố Wall là phương pháp Waterfall-"thác nước", nó đòi hỏi phải có sự phân tích nghiêm ngặt, kéo dài và cung cấp các tài liệu cần thiết về nhu cầu. Ví dụ như đối với một dự án 1 năm, người ta dành ra từ 3 đến 6 tháng để phân tích những nhu cầu cần thiết. "Những nhà kinh doanh được trông đợi xác định ra 100% các nhu cầu của họ- cái đặt lên hàng đầu, thậm chí cả trước khi dự án khởi động" Chapman nói. "Mọi người thường mắc vào tình trạng tê liệt phân tích – đó là họ mất hàng tháng để cố gắng xác định ra những gì họ muốn." Ba đến sáu tháng còn lại có thể được dành để thiết kế phần mềm, theo đó, chương trình thực cuối cùng được viết ra. "Chuyện chắc chắn xảy ra là những nhu cầu sẽ thay đổi, việc tích hợp chúng lại- các nhu cầu, trở nên rất khó khăn và những mối nguy hiểm trong quá trình phát triển phần mềm sẽ xảy ra vào giai đoạn cuối của nỗ lực phát triển phần mềm. Phương pháp thác nước có kết quả hoạt động không được tốt trong việc phân phối." Phát triển phần mềm linh hoạt- Agile được thiết kế để cung cấp phần mềm một cách nhanh chóng hơn nhưng vẫn duy trì chất lượng cao. Trong phương pháp Agile, cứ mỗi hai đến bốn tuần, các nhà kinh doanh sẽ nhận được một số lượng nhỏ các mã để xem xét và nhận lấy cơ hội thay đổi nhu cầu ban đầu. “ Hãy tưởng tưởng một quỹ phòng ngừa rủi ro nơi mà hệ thống thương mại các sản phẩm tín dụng phát sinh theo truyền thống sẽ mất một năm để được xây dựng bằng cách sử dụng phương pháp Waterfall, ngược lại với những nhà kinh doanh viết những tài liệu đó trong 6 tháng 4 IT003-111-T19_Nhóm 10_Case study 7.4 bằng phương pháp Agile, sẽ mất 2 tuần để các hệ thống được phân phối, và nó cũng sẽ ổn nếu bạn thay đổi suy nghĩ của mình.” Chapman nói. "Đối với các quỹ phòng ngừa rủi ro cá biệt, phương pháp tiếp cận Agile là một sự thích hợp cực kỳ tốt bởi vì các nhà quản lý danh mục đầu tư muốn mọi việc được hoàn thành một cách nhanh chóng." Nhưng mỗi dự án chỉ thích hợp với phương pháp lặp ngắn, Chapman thừa nhận. “ Ở phố Wall điều đó thì không dễ dàng bởi vì có rất nhiều các hệ thống khác mà bạn cần phải tích hợp lại ", ông nói. "Nhưng tôi nghĩ rằng có một số phần của phương pháp Agile bạn vẫn có thể sử dụng để cải thiện các dự án." Sự phát triển Agile có 3 cấp độ: nhà phát triển, dự án, doanh nghiệp. “Không ai trong phố Wall sử dụng Agile khi đã đạt mức độ doanh nghiệp”, Chapman nói. “Nhiều vấn đề đào tạo cần phải thay đổi trong phạm vi các ngân hàng- nó sẽ mất một khoảng thời gian nào đó. Nhưng tôi nghĩ mỗi dự án sẽ đạt được một vài lợi ích nhất định từ việc cố gắng phân chia dự án thành những phân khúc nhỏ, dễ quản lý để có thể được phân phối một cách nhanh nhạy và có tính lặp cao hơn.” Chapman dám chắc rằng phương pháp Agile thậm chí còn cải thiện được chất lượng phần mềm, bởi vì họ chú trọng việc thử nghiệm. Các phương pháp Agile khuyến khích các nhà phát triển tự làm thử nghiệm riêng của họ, thường là các mã hóa và phát triển quy trình thử nghiệm tự động cho những chương trình mà họ cung cấp. Chapman còn thêm vào rằng: “ Phương pháp phát triển linh hoạt- Agile và CMMI dễ dàng tương thích lẫn nhau- bạn có thể sử dụng CMM và CMMI cải thiện phương pháp agile”. Mặt khác , ông quả quyết rằng, cố gắng sử dụng CMM và CMMI để kiểm soát trong phương pháp thác nước- Waterfall sẽ chỉ đem lại gánh nặng cho các dự án bằng thói quan liêu và thủ tục hành chính. Nguồn:www.wallstreetandtech.com/advancedtrading/showArticle.jhtml? articleID=199601961&cid=RSSfeed_TechWebaccessed via www.computing.co.uk Câu hỏi: 1) Lời nhận xét “ Khi yêu cầu thay đổi, việc tích hợp trở nên khó khăn và những mối nguy hiểm trong quá trình phát triển phần mềm sẽ xảy ra vào giai đoạn cuối của nỗ lực phát triển phần mềm ” muốn đề xuất điều gì về việc tiếp cận bằng phương pháp thác nước truyền thống đến phát triển phần mềm đối với khâu thiết kế hệ thống ? 2) Bạn có nghĩ rằng, có bất kì rủi ro nào sẽ xảy ra trong việc cố gắng tạo ra sự cắt giảm nhỏ xung quanh phương pháp truyền thống để thiết kế hệ thống hay không ? 5 IT003-111-T19_Nhóm 10_Case study 7.4 TÓM TẮT TÌNH HUỐNG Ở công ty tài chính Mellon, việc chuyển đổi sang phương pháp phát triển phần mềm linh hoạt (Agile Development Methods) là một xu thế tất yếu. Nó dựa trên sự phát triển lặp: phát triển phần mềm ở những phần nhỏ, dễ quản lý, có thể chỉnh sửa khi có yêu cầu thay đổi thông qua một cơ chế tương đối nghiêm ngặt. Trước đây, mô hình được sử dụng phổ biến ở phố Wall là phương pháp mô hình thác nước (Waterfall Method). Ở phương pháp này, nhu cầu của khách hàng đòi hỏi phải được phân tích một cách chặt chẽ, phức tạp trong một thời gian dài vì thế mọi người bị mắc kẹt trong một tiến trình phân tích và phải mất hàng tháng để xác định là họ muốn gì. Ví dụ đối với dự án kéo dài một năm, quy trình phân tích đã chiếm từ ba đến sáu tháng và ba đến sáu tháng tiếp theo dành cho việc thiết kế phần mềm, rồi mới bắtt đầu viết chương trình. Theo Chapman: “Sự thay đổi các yêu cầu là không thể tránh khỏi, khi đó việc thống nhất khó mà đạt được, và những rủi ro phát sinh vào cuối tiến trình của phần mềm”. Phương pháp phát triển phần mềm linh hoạt được thiết kế nhằm cung cấp phần mềm theo nhu cầu của khách hàng một cách nhanh chóng hơn mà vẫn đảm bảo dược chất lượng cao. Trong phương pháp này, cứ mỗi hai đến bốn tuần, các nhà thiết kế nhận được một đoạn mã nhỏ để xem trước, sau đó sẽ đưa ra yêu cầu thay đổi nếu cần thiết. Tuy nhiên Chapman cũng thừa nhận rằng không phải bất cứ dự án nào cũng tương thích với phương pháp lặp, nhưng vẫn có những khía cạnh của phương pháp lập trình linh hoạt có thể áp dụng để cải thiện dự án. 6 IT003-111-T19_Nhóm 10_Case study 7.4 BÀI PHÂN TÍCH 1. Mô hình thác nước (Waterfall model) 1.1. Đặc điểm: 1.1.1. Khái niệm : Mô hình thác nước còn được gọi là mô hình tuần tự tuyến tính, quy định trình tự các giai đoạn cần phải thực hiện khi xây dựng một hệ thống thông tin. Mô hình thác nước có thể được minh họa như trong hình 1. Các giai đoạn được tiến hành tuần tự và mỗi giai đoạn bắt đầu sau khi giai đoạn trước kết thúc. Mỗi giai đoạn đều có liên kết quay ngược lại giai đoạn trước đó để sửa chữa những sai sót trong giai đoạn trước đó. Hình 1. – Mô hình thác nước 1.1.2. Các giai đoạn của mô hình thác nước: • Khởi tạo: Giai đoạn khởi tạo là giai đoạn đầu tiên trong một dự án phát triển hệ thống thông tin. Mục đích là để ược lượng tính khả thi của dự án và đưa ra các bước chuẩn bị để đảm bảo các dự án thành 7 IT003-111-T19_Nhóm 10_Case study 7.4 công. Giai đoạn khởi tạo bao gồm cả các tác nhân kích thích (từ môi trường bên ngoài và bên trong) mà từ đó phát sinh nhu cầu về hệ thống thông tin kinh doanh • Đánh giá khả thi Đánh giá khả thi là công việc cần phải thực hiện khi bắt đầu một dự án để đảm bảo rằng dự án này là một kế hoạch kinh doanh có thể thực hiện được. Bản báo cáo khả thi phân tích yêu cầu và ảnh hưởng của hệ thống mới đồng thời xem xét các giải pháp triển khai thích hợp. • Phân tích hệ thống: Quá trình phân tích nhằm nắm bắt yêu cầu nghiệp vụ của hệ thống trong thực tế bằng cách phỏng vấn, quan sát trực tiếp người dùng cuối tại nơi làm việc hay xem xét các tài liệu có sẵn trong hệ thống. Có 3 nhiệm vụ chính trong giai đoạn này: - Đầu tiên, cần phải xác định rõ hệ thống hiện tại vận hành như thế nào. - Thứ hai, đưa ra mô hình về hệ thống hiện tại để đảm bảo sự thỏa thuận giữa các chuyên gia phần mềm và người dùng cuối. - Cuối cùng, một bản đặc tả các yêu cầu về hệ thống mới được đưa ra. Nếu trong quá trình xác định yêu cầu, việc thực hiện một yêu cầu nào đó được phát hiện là không khả thi thì phải quay lại bước đánh giá khả thi và thực hiện phân tích bổ sung cho các giải pháp. • Thiết kế hệ thống: Quá trình thiết kế hệ thống nhằm xác định hệ thống mới sẽ làm việc như thế nào, bao gồm giao diện người dùng, các module (một đơn vị có chức năng riêng trong hệ thống máy tính hay tin học) chương trình, tính bảo mật, thiết kế cơ sở dữ liệu. Nhiệm vụ của giai đoạn này là chuyển đổi những đặc tả yêu cầu thành các bản thiết kế khác nhau để từ đó có thể chọn ra bản thiết kế tốt nhất. Nếu trong quá trình thiết kế, có một yêu cầu nào đó không rõ ràng hay không thể thể hiện thành một bản thiết kế thì sẽ phải quay trở lại giai đoạn phân tích và xác định chi tiết hơn nữa yêu cầu về hệ thống mới. • Xây dựng hệ thống: Đây là giai đoạn xây dựng phần mềm được thực hiện bởi các lập trình viên bao gồm: lập trình, xây dựng cơ sở dữ liệu, kiểm thử, lập tài liệu hướng dẫn, tập huấn sử dụng,… 8 IT003-111-T19_Nhóm 10_Case study 7.4 Quá trình này bao gồm 3 bước nhỏ hơn: + Xây dựng cơ sở dữ liệu + Lập trình + Kiểm lỗi Kết quả quá trình xây dựng hệ thống là một hệ thống thông tin đã được kiểm lỗi và sẵn sàng cho việc chuyển đổi dữ liệu hay đưa vào sử dụng thực tế. Nếu ở bước kiểm lỗi phát hiện rằng hệ thống không đáp ứng những yêu cầu ban đầu được xác định ở bước phân tích thì sẽ phải quay lại bước thiết kế hệ thống để xác định xem có lỗi nào trong quá trình chuyển đổi yêu cầu hay không. Nếu giai đoạn thiết kế diễn giải chính xác nhưng hệ thống không đáp ứng nhu cầu của người dùng thì sẽ phải quay lại bước phân tích để xác định yêu cầu của hệ thống một cách chính xác hơn. • Triển khai hệ thống và chuyển đổi: Quá trình này bao gồm việc cài đặt phần cứng và mạng cho hệ thống mới, kiểm thử bởi người tiêu dùng và tập huấn sử dụng. Đồng thời bao gồm việc chuẩn bị và tiến hành thay đổi, nâng cấp hệ thống cũ thành hệ thống mới. Tại bước này, sẽ phát hiện được là hệ thống thống thông tin mới có hoạt động tốt và thực sự đáp ứng những yêu cầu của người dùng hay không? Nếu phát sinh lỗi thì đòi hỏi quay trở lại các giai đoạn trước đó, tùy vào tính chất và mức độ nghiêm trọng của lỗi. • Xem lại và bảo trì: Một khi hệ thống thông tin được vận hành trong thực tế, nó sẽ gặp phải những yêu cầu thay đổi theo thời gian. Sau một khoảng thời gian hoạt động, hệ thống cần phải được thay đổi và thích nghi với sự thay đổi của yêu cầu kinh doanh. - Giai đoạn bảo trì bao gồm 2 loại: sửa chữa các tính năng, sửa lỗi cho phù hợp với đặc tả ban đầu và thêm các tính năng mới. - Giai đoạn xem lại: xem xét mức độ thành công của dự án và rút ra các bài học trong tương lai. Giai đoạn này thường được tiến hành 6 tháng sau khi chạy thực tế hệ thống. 1.2. Ưu điểm, nhược điểm của mô hình thác nước: 1.2.1.Ưu điểm: Đây là mô hình phát triển sớm nhất nên nó có ý nghĩa lý thuyết cao, nó là một mô hình tốt để giới thiệu về quá trình phát triển hệ thống thông tin. 9 IT003-111-T19_Nhóm 10_Case study 7.4 Thuận lợi của mô hình thác nước là có thể dễ dàng phân chia quá trình phát triển hệ thống thành những giai đoạn hoàn toàn độc lập, đơn giản và rõ ràng với một thời hạn nhất định để dễ dàng quản lý. Mỗi khâu của chu trình phát triển được triển khai trong một khuôn khổ nghiêm ngặt. Mô hình thác nước hạn chế tối thiểu các cố gắng dành cho những hoạt động không cho ra kết quả (mỗi giai đoạn phải có kế hoạch cụ thể và kết quả của giai đoạn trước sẽ tiếp nối cho sự bắt đầu của giai đoạn tiếp theo) nên buộc phải hoàn thành từng giai đoạn. Cho nên dễ dàng quản lý đầu vào và đầu ra của từng giai đoạn. Phạm vi của mô hình có thể áp dụng cho các dự án nhỏ (vì tính đơn giản của nó) và dự án cực kỳ lớn (do tính rõ ràng cẩn thận của nó). Thích hợp với các dự án mà yêu cầu hệ thống rõ ràng và ít thay đổi. 1.1.2. Nhược điểm: Trong mô hình thác nước truyền thống của lĩnh vực phát triển phần mềm, khâu phân tích nhu cầu là khâu quan trọng nhất. Như bảng 2 đã chỉ ra, theo dữ liệu từ nhiều tổ chức khác nhau đã chỉ ra rằng trong những dự án lớn, một lỗi được phát hiện trong khâu phân tích yêu cầu trong giai đoạn thiết kế thì chỉ tốn gấp 3 lần so với chi phí để sửa lại nó nếu được phát hiện trong giai đoạn phân tích. Tương tự nếu bị phát hiện trong giai đoạn xây dựng thì tốn gấp 5 đến 10 lần chi phí; trong giai đoạn triển khai hệ thống thì gấp 10 lần; trong giai đoạn bảo trì đánh giá thì sẽ tốn gấp 10 đến 100 lần chi phí. Dự án càng lớn thì chi phí sửa chữa sẽ càng tăng. Việc xác định các yêu cầu một cách chính xác là chìa khóa thành công của một dự án, có lẽ còn quan trọng hơn cả công nghệ thiết kế nữa. Do đó mô hình chỉ thích hợp khi các yêu cầu phần mềm được rõ ràng và không bị thay đổi (hoặc chỉ giới hạn ở khâu thiết kế). Trong khi đó có rất ít hệ thống có yêu cầu rõ ràng và ổn định.Những cuộc nghiên cứu tại IBM và các công ty khác đã tìm ra rằng trung bình một dự án sẽ trải qua 25% thay đổi trong yêu cầu trong suốt quá trình phát triển hệ thống. [4, pp. 44 - 45] 10 [...]... về nó nhất Khi khách hàng tiếp xúc với hệ thống họ mới hiểu rõ hơn về những cái mà họ cần và điều này sẽ tạo ra sự một sự thay đổi lớn về yêu cầu Tuy nhiên, mô hình thác nước được xem là quá cứng nhắc và thiếu thực tế Quá trình phát triển hệ thống được chia thành các phần độc lập tạo nên nhiều khó khăn khi có thay đổi về yêu cầu từ khách hàng.Với mô hình thác nước, việc theo kịp các thay đổi là không... kiểm thử trong và ngoài nước 3 Giải pháp Theo những phân tích trên thì cả hai phương pháp phát triển phần mềm là mô hình thác nước truyền thống và phương pháp phát triển linh hoạt Agile đều có những ưu và nhược điểm nhất định Vấn đề quan trọng không phải là bạn so sánh những nhược điểm hay ưu điểm của hai mô hình để lựa chọn giữa hai phương pháp mà bạn phải xác định được mô hình nào cùng với những... ổn định Trong các tình huống mà các nhà thiết kế của một chương trình phần mềm có thể dự đoán chính xác những sai sót có thể phát sinh thì mô hình thác nước là sự lựa chọn thích hợp Mặc dù vẫn có các sai sót nhưng mô hình thác nước có được sự dễ dàng trong việc quản lý và các chi phí phát triển có thể được xác định trước Còn phương Agile được áp dụng trong mọi lĩnh vực của phát triển phần mềm Nó phụ... xộn và dư thừa Trong nhiều trường hợp, mô hình thác nước có thể đem lại nhiều lợi ích vì nó cung cấp các khâu phân chia công việc và mốc thời gian rõ ràng Áp dụng phương pháp Agile vào các đội khác biệt về địa lí có thể xem như một thử thách khó khăn vì phương pháp Agile đòi hỏi phải có sự giao tiếp thường xuyên giữa có thành viên để cùng thảo luận, chia sẻ thông tin cho việc hoàn thành dự án Các nguồn... của bạn, có thể mô hình đó vẫn có những nhược điểm ảnh hưởng đến dự án của bạn nhưng đó vẫn là lựa chọn tốt nhất vì nó đã phát huy tối đa ưu điểm của mình cho dự án của bạn, giúp bạn giảm thiểu những ảnh hưởng không tốt mà mô hình đó mang lại 15 IT003-111-T19_Nhóm 10_Case study 7.4 Dưới đây là một số câu hỏi bạn cần có câu trả lời trước khi quyết định sử dụng phương pháp mô hình thác nước hay Agile... nhân, nhóm và các tổ chức phải đủ linh hoạt để thay đổi cách tiếp cận của họ cho phù hợp với điều kiện thay đổi của môi trường bên trong và bên ngoài TÀI LIỆU THAM KHẢO I Sách tham khảo, bài luận, báo cáo 1 ThS Nguyễn Ngọc Đức, ThS Nguyễn Huỳnh Anh Vũ (2011), Hệ thống thông tin quản trị, Nxb lao động – xã hội 2 Pekka Abrahamsson (2002), Agile software development methods – Review and analysis, 3 4... nữa có thể sẽ gây ra một vài sự trì hoãn cho dự án Trong nhiều trường hợp, phương pháp thác nước có thể là cách tiếp cận tốt nhất, nơi mà mỗi mốc công việc có thể hoàn thành trước khi tiến trình chuyển sang khâu kế tiếp và bạn được đảm bảo rằng những nguồn lực tới hạn đã sẵn sàng để sử dụng [7] 4 Kết luận Mô hình thác nước thích hợp cho sự phát triển của các chương trình đã được ổn định Trong các tình... thể giúp bạn xác định các nhu cầu và quản lí sự thay đổi Điều này có nghĩa là bạn có thể kiếm được những nhu cầu bền vững cho phép bạn sử dụng mô hình thác nước Nói cách khác, nếu người sử dụng cuối cùng bị phân tán, bạn có thể có được phạm vi rộng hơn những nhu cầu, nhưng bạn không thể định nghĩa nó cho đến khi những người sử dụng cuối cùng này sử dụng qua hệ thống và bắt đầu đề nghị cần có những... lực của cả đội ngũ lập trình hơn là dựa vào một vài chuyên gia lập trình Vấn đề quan trọng ở đây không là việc cố gắng so sánh sự khác biệt cơ bản giữa hai mô hình thác nước và Agile Những gì cần làm là thiết kế một mô hình lý tưởng, phù hợp với môi trường 17 IT003-111-T19_Nhóm 10_Case study 7.4 công ty, với dự án Điều quan trọng là có được sự nhanh nhẹn chứ không chỉ làm Agile Nói cách khác, việc lựa... mới sau khi dự án khởi động Nói cách khác, nếu bạn tiến hành một dự án phát triển truyền thống với những quy định nghiêm ngặt, các yêu cầu đã được đặt ra trước khi đến với các giai đoạn sau để đảm bảo hoàn thành hệ thống, phương pháp thác nước có thể được xem là một lựa chọn tốt Ai là người sử dụng cuối cùng của hệ thống? Hãy dành một ít thời gian của bạn để biết về những người sử dụng cuối cùng và các . PHÂN TÍCH 8 1. Mô hình thác nước (Waterfall model) 8 1.1. Đặc điểm 8 1.1.1. Khái niệm 8 1.1.2. Các giai đoạn của mô hình thác nước 8 1.2. Ưu điểm, nhược điểm của mô hình thác nước 11 1.2.1. Ưu. trước đó. Hình 1. – Mô hình thác nước 1.1.2. Các giai đoạn của mô hình thác nước: • Khởi tạo: Giai đoạn khởi tạo là giai đoạn đầu tiên trong một dự án phát triển hệ thống thông tin. Mục đích. án. 6 IT003-111-T19_Nhóm 10_Case study 7.4 BÀI PHÂN TÍCH 1. Mô hình thác nước (Waterfall model) 1.1. Đặc điểm: 1.1.1. Khái niệm : Mô hình thác nước còn được gọi là mô hình tuần tự tuyến tính, quy định trình tự