ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN CHƯƠNG TRÌNH ĐÀO TẠO THẠC SĨ CÔNG NGHỆ THÔNG TIN QUA MẠNG o0o BÁO CÁO THU HOẠCH MÔN HỌC PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC TRONG TIN HỌC Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM Giảng viên hướng dẫn: GS.TSKH Hoàng Văn Kiếm Học viên thực hiện: Trần Bá Dược Mã số học viên: CH1201098 TP. HCM, năm 2013 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM Mục lục Lời nói đầu 2 Lời nói đầu 2 PHẦN I 3 GIỚI THIỆU MỘT SỐ MÔ HÌNH TRONG XÂY DỰNG PHẦN MỀM 3 I.1. MÔ HÌNH XÂY DỰNG VÀ HIỆU CHỈNH (BUILD AND FIX MODEL) 3 I.2. MÔ HÌNH THÁC ĐỔ (WATERFALL MODEL) 4 I.3. MÔ HÌNH BẢN MẪU (RAPID PROTOTYPING MODEL) 6 I.4. MÔ HÌNH TĂNG DẦN (INCREMENTAL MODEL) 8 I.5. MÔ HÌNH TĂNG DẦN ĐỒNG THỜI (CONCURRENT INCREMENTAL MODEL) 10 I.6. MÔ HÌNH ĐỒNG BỘ VÀ ỔN ĐỊNH (SYNCHRONIZE AND STABILIZE MODEL) 12 I.7. MÔ HÌNH XOẮN ỐC (SPIRAL MODEL) 12 I.8. MÔ HÌNH HƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL) 16 PHẦN II 18 PHƯƠNG PHÁP SCRUM TRONG XÂY DỰNG PHẦN MỀM 18 1. Khái niệm về SCRUM : 18 2. Quy trình thực hiện SCRUM : 19 PHẦN III 26 ÁP DỤNG NHỮNG NGUYÊN LÝ SÁNG TẠO TRONG SCRUM 26 Nguyên tắc phân nhỏ: 26 Nguyên tắc linh động: 26 Nguyên tắc thực hiện sơ bộ: 26 Nguyên tắc tác động theo chu kỳ: 27 Nguyên tắc quan hệ phản hồi: 27 Nguyên tắc vạn năng: 27 . Nguyên tắc tách khỏi: 27 PHẦN IV 28 TÀI LIỆU THAM KHẢO 28 GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 1 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM Lời nói đầu Khoa học kỹ thuật giữ một vai trò đặc biệt quan trọng trong cuộc sống hiện nay của mỗi chúng ta. Nhờ khoa học kỹ thuật mà con người tạo ra nhiều của cải vật chất, sản phẩm,…phục vụ cho cuộc sống của mình ngày càng tốt hơn; giúp con người khám phá nhiều quy luật vận động của thế giới xung quanh mình, từng bước điều khiển được sự vận động của tự nhiên. Chính vì thế, việc nghiên cứu, tìm tòi, sáng tạo ra những giá trị mới đã trở thành một việc làm cấp thiết của mỗi người chúng ta, nhằm góp một phần tri thức của mình cho tri thức chung của nhân loại, góp phần cải tạo thế giới. Trải qua một thời gian học tập và nghiên cứu môn Phương pháp Nghiên cứu khoa học và tư duy sáng tạo, với sự hướng dẫn tận tình của Thầy GS.TSKH Hoàng Văn Kiếm, tôi đã hiểu sâu hơn về phương pháp nghiên cứu, tìm tòi, phát hiện vấn đề mới trong lĩnh vực khoa học máy tính. Tôi tin rằng, với những kiến thức mà Thầy đã truyền đạt, sẽ giúp ích rất nhiều cho việc học tập và nghiên cứu của tôi sau này. Tôi chân thành cảm ơn Thầy GS.TSKH Hoàng Văn Kiếm. Kính chúc Thầy và gia đình luôn dồi dào sức khỏe. Học viên GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 2 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM PHẦN I GIỚI THIỆU MỘT SỐ MÔ HÌNH TRONG XÂY DỰNG PHẦN MỀM I.1. Mô hình xây dựng và hiệu chỉnh (Build and fix model) Có khá nhiều phần mềm (software) đã được xây dựng dựa trên mô hình xây dựng và hiệu chỉnh. Trong mô hình này không có các pha phân tích thiết kế. Phần mềm được xây dựng như sau: người phát triển sau khi trao đổi với khách hàng sẽ viết phiên bản (version) đầu tiên. Tiếp theo, phần mềm được chạy thử với sự quan sát của khách hàng và liên tục được hiệu chỉnh cho đến khi khách hàng vừa ý (tức là đáp ứng được yêu cầu của khách hàng). Sau khi được khách hàng chấp nhận, phần mềm được đưa vào sử dụng và bảo trì. Mô hình này có thể biểu diễn trong sơ đồ sau: Hình 1. Mô hình xây dựng và hiệu chỉnh Cách thức này được nhiều người sử dụng để làm phần mềm, nhất là các phần mềm nhỏ. Nếu nói chính xác hơn thì mô hình trên đây không có tài liệu phân tích, thiết kế. Vì thực ra khi viết chương trình thì người phát triển cũng phải hình dung ra các chức năng của phần mềm, những module phải có, những thuật toán sử dụng Nghĩa là GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 3 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM phần nào đó họ cũng có phân tích thiết kế, nhưng họ không biên soạn lại thành tài liệu mà thôi. Nếu phần mềm do một người viết và dễ dàng trao đổi với khách hàng thì có lẽ mô hình xây dựng và hiệu chỉnh là cách nhanh nhất để đi tới sản phẩm. Sau khi viết phiên bản đầu tiên, người phát triển đã hiểu khá rõ yêu cầu của khách hàng, họ cũng hiểu rõ các dòng lệnh vừa viết. Vì vậy khi khách hàng nêu yêu cầu hiệu chỉnh phần mềm thì họ biết ngay cần phải hiệu chỉnh phần nào của chương trình. Công việc thường được thực hiện khá nhanh chóng và phần mềm sớm được hoàn thành và đưa vào sử dụng. Về hình thức, cách làm phần mềm theo kiểu xây dựng và hiệu chỉnh cũng giống như làm bản mẫu. Tuy nhiên có một sự khác biệt, là khi làm bản mẫu ta bỏ qua các yếu tố quan trọng khác mà chỉ tập trung mô tả các yêu cầu của khách hàng; còn trong mô hình xây dựng và hiệu chỉnh thì ta chú ý tới cả các đặc trưng này khi xây dựng phần mềm. Nhược điểm của mô hình thể hiện rõ trong giai đoạn bảo trì. Công việc bảo trì thường là sửa lỗi và cập nhật. Nếu phần mềm vừa mới được đưa vào sử dụng và tác giả vẫn còn chịu trách nhiệm công việc này thì không có vấn đề gì lắm. Tuy nhiên nếu phần mềm đã được sử dụng sau một thời gian dài, khiến cho chính người viết chương trình cũng quên đi ý nghĩa các dòng lệnh; hoặc việc bảo trì lại do một người khác thực hiện thì sẽ rất khó khăn. Nếu bạn thử đọc chương trình nguồn của một tác giả khác mà không có tài liệu giải thích kèm theo thì bạn sẽ thấy rất khó hiểu. Đôi khi bạn tìm hiểu vấn đề rồi viết mới chương trình có lẽ còn đơn giản hơn là sửa lại chương trình của người khác. Mô hình xây dựng và hiệu chỉnh chỉ thích nghi cho phần mềm nhỏ, một người viết và ít khả năng phải sửa đổi trong quá trình sử dụng. Ngày nay các phần mềm thường lớn, do nhiều người viết do đó cách thức này trở nên không thích hợp. Khi có nhu cầu làm phần mềm, ta cần lựa chọn mô hình vòng đời thích hợp (đôi khi ta nói đơn giản là mô hình). Mô hình này phải được cả nhóm làm phần mềm nhất trí, sau đó công việc phát triển phần mềm mới thực sự được bắt đầu. I.2. Mô hình thác đổ (Waterfall model) Vào năm 1970, mô hình thác đổ được đưa ra lần đầu tiên bởi W.W. Royce. Trong mô hình này, quá trình phát triển phần mềm được coi như một dòng chảy trải qua các pha yêu cầu, phân tích, thiết kế, cài đặt, tích hợp và bảo trì. Thực ra, Royce có mô tả tính lặp của từng pha, nghĩa là nếu trong một pha người ta phát hiện ra điều gì đó sai sót hoặc không phù hợp thì sẽ quay lại hiệu chỉnh ở pha trước. GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 4 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM Hình 2. Mô hình thác đổ (waterfall model) Mô hình thác đổ là mô hình cũ nhất và được sử dụng rộng rãi nhất trong công nghệ phần mềm. Tuy nhiên cũng có nhiều ý kiến chỉ trích và cho rằng mô hình này có một số nhược điểm như sau: • Các dự án trong thực tế hiếm khi tuân theo dòng chảy tuần tự mà mô hình đề nghị. Mặc dầu mô hình cho phép lặp, nhưng điều đó chỉ làm gián tiếp. Kết quả là những thay đổi có thể gây ra lẫn lộn khi nhóm phát triển làm việc. • Khách hàng thường khó phát biểu mọi yêu cầu một cách tường minh ngay từ đầu. Mô hình tuần tự tuyến tính đòi hỏi điều này và thường khó thích hợp với sự không chắc chắn tự nhiên tồn tại vào lúc đầu của nhiều dự án. Khách hàng phải kiên nhẫn chờ đợi, vì bản làm việc được của chương trình chỉ có được vào cuối của thời gian dự án. Một sai lầm ngớ ngẩn, nếu đến lúc có chương trình làm việc mới phát hiện ra, có thể là một thảm họa. • Có thể xảy ra các trạng thái tắc nghẽn trong quá trình thực hiện dự án phần mềm, nghĩa là có một số thành viên của nhóm phát triển phải chờ đợi sự chuyển giao từ nhóm khác hoàn thành công việc ở pha trước. Trong thực tế, thời gian chờ đợi có GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 5 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM thể vượt quá thời gian sản xuất. Trạng thái nghẽn có xu hướng xẩy ra vào thời gian đầu và cuối của quy trình phần mềm. Tuy nhiên, mô hình vòng đời cổ điển có một vị trí quan trọng vì nó đưa ra một hình mẫu về các bước mà một phần mềm cần phải trải qua là: phân tích hệ thống, thiết kế, cài đặt, tích hợp và bảo trì. Nhiều mô hình sau này là cải tiến mô hình này, nhưng vẫn giữ lại những điểm cốt lõi. I.3. Mô hình bản mẫu (Rapid prototyping model) Mô hình bản mẫu thực chất cũng là mô hình thác đổ, nhưng phần xác định yêu cầu được thay bằng bản mẫu. Mô hình này có thể biểu diễn bởi sơ đồ sau: GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 6 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM Hình 3. Mô hình bản mẫu (rapid prototyping model) Cũng như mô hình thác đổ, các pha từ bản mẫu đến thiết kế đều có kiểm tra (verify), các pha cài đặt và tích hợp có kiểm thử (test). Thông thường khách hàng đã xác định được một tập các mục tiêu tổng quát cho phần mềm, nhưng còn chưa nhận diện được đầu vào, đầu ra, những cái cần xử lý. Trong các trường hợp khác người phát triển có thể không chắc về tính hiệu quả của thuật toán, việc thích nghi hệ điều hành hay dạng màn hình giao diện cần có. Trong trường hợp này và nhiều trường hợp khác, cách làm bản mẫu có thể đưa ra cách tiếp cận tốt nhất. Để làm bản mẫu, đầu tiên người ta thu thập yêu cầu khách hàng. Người phát triển và khách hàng cùng ngồi lại với nhau để xác định các mục tiêu tổng thể cho phần mềm, xác định xem yêu cầu nào đã rõ ràng, yêu cầu nào còn phải xác định thêm. Tiếp theo là việc "thiết kế nhanh". Thiết kế nhanh chỉ tập trung vào việc biểu diễn các khía cạnh của phần mềm thấy được đối với người dùng, ví dụ như là màn hình nhập dữ liệu, các chức năng tìm kiếm, truy xuất thông tin, các báo cáo. Người phát triển có thể kết hợp để thử nghiệm một thuật toán. Tuy nhiên mục đích chính là thể hiện được các yêu cầu của khách hàng trong phần mềm mà chưa để ý đến tính tối ưu, tốc độ, sự hợp lý Thiết kế nhanh dẫn tới việc xây dựng một bản mẫu. Bản mẫu được giới thiệu với khách hàng và có thể để họ dùng thử và đánh giá, góp ý kiến. Trên cơ sở ý kiến khách hàng người phát triển làm mịn dần bản mẫu cho đến khi khách hàng thấy vừa ý (chủ yếu là cái vào, cái ra, giao diện ). Căn cứ vào bản mẫu người phát triển cũng hiểu rõ hơn yêu cầu khách hàng, những yêu cầu về cấu hình, về các thuật toán, cấu trúc dữ liệu, ngôn ngữ lập trình phù hợp So sánh mô hình thác đổ và mô hình bản mẫu: Trong mô hình thác đổ, mục đích của pha xác định yêu cầu là làm sao nắm bắt được những yêu cầu của khách hàng. Tuy nhiên việc này thường gặp khó khăn do khách hàng đôi khi không diễn đạt được chính xác yêu cầu của mình và có thể người phát triển đôi khi hiểu sai ý của khách hàng. Việc sử dụng bản mẫu trong pha xác định yêu cầu sẽ khắc phục được phần nào tình trạng này. Khách hàng dễ kiểm tra lại các yêu cầu của mình qua việc chạy thử các chức năng của phần mềm bản mẫu. Thực chất thì mô hình bản mẫu cũng là mô hình thác đổ nhưng kỹ thuật khảo sát được sử dụng là bản mẫu. Việc sử dụng bản mẫu còn có điểm lợi là giúp các nhà phát triển có cơ hội áp GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 7 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM dụng thử và đánh giá những công nghệ và kỹ thuật mới và có thể giảm thiểu những rủi ro khi sử dụng những công nghệ mới này. I.4. Mô hình tăng dần (Incremental model) Phần mềm được xây dựng từng bước, cũng như xây một ngôi nhà vậy. Nếu như khi xây dựng ngôi nhà có lúc người ta phải phá đi xây lại một bức tường không vừa ý thì khi làm phần mềm chúng ta cũng có thể sửa đổi thậm chí bỏ đi những module chương trình không phù hợp, một phần mềm ra đời, được đưa vào sử dụng. Trong quá trình sử dụng ngoài việc phát hiện và sửa chữa sai sót, người ta thấy cần nâng cấp chất lượng bằng cách cải tiến một vài thuật toán, thêm một số chức năng Ví dụ như khi làm phần mềm soạn thảo văn bản chẳng hạn. Phiên bản đầu có thể chưa có chức năng kiểm tra chính tả, chưa có chức năng chèn hình ảnh Người ta nâng cấp phiên bản này bằng cách bổ sung các chức năng này. Sau khi hoàn thành công việc này người ta lại thấy nên thêm chức năng vẽ đồ thị, thêm khả năng tính toán trong bảng. Mỗi lần nâng cấp như vậy người ta lại dựa trên nền tảng phần mềm đã có và xem xét sửa đổi lại tài liệu các pha. Từ nhận xét rằng phần mềm có thể được xây dựng từng bước đã đưa đến việc ra đời một mô hình mới là mô hình tăng dần. Trong mô hình tăng dần, người ta xem phần mềm bao gồm nhiều thành phần (components) tương đối độc lập nhau. Với hệ điều hành chẳng hạn, đó là thành phần scheduler, thành phần file management system, Mỗi thành phần như vậy được coi như một phần mềm nhỏ, được thiết kế, lập trình, kiểm thử và đưa cho khách hàng sử dụng theo mô hình thác đổ rồi kết hợp dần thành phần mềm hoàn chỉnh thỏa mãn tất cả các yêu cầu của khách hàng. Ban đầu người ta chưa chú ý đến toàn bộ các yêu cầu của phần mềm mà chỉ chú ý đến những nét đặc trưng nhất và xây dựng phiên bản đầu tiên của phần mềm bao gồm các đặc trưng này rồi đưa cho khách hàng sử dụng. Chương trình được hiệu chỉnh theo ý kiến phản hồi của khách hàng. Tiếp theo người ta lại xây dựng phần mềm thứ hai thỏa mãn các đặc trưng quan trọng thứ hai và lại đưa cho khách hàng sử dụng và có ý kiến. Phần mềm thứ hai này sau khi hiệu chỉnh lại được tích hợp vào phần mềm đầu tiên thành một phần mềm lớn hơn. Phần mềm tích hợp này lại được kiểm thử để bảo đảm việc ghép nối thành công và chương trình chạy tốt. Cứ như vậy, thay vì xây dựng phần mềm hoàn chỉnh, người ta xây dựng các phần mềm con rồi tích hợp dần cho tới khi đạt được sản phẩm mong muốn. Sơ đồ sau mô tả mô hình tăng dần. GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 8 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM Hình 5. Mô hình tăng dần (incremental model) Nhận xét mô hình tăng dần: Với mô hình thác đổ hoặc bản mẫu, sản phẩm được chuyển giao cho khách hàng chính là phiên bản hoàn chỉnh thỏa mãn tất cả các yêu cầu của khách hàng và có thể sử dụng ngay. Thời gian hoàn thành phần mềm được quy định trong hợp đồng và có thể sớm hoặc muộn hơn. Với mô hình tăng dần thì phần mềm được chia ra nhiều phần (thường là từ 5 đến 25 phần). Phần đầu tiên chứa đựng những đặc trưng quan trọng nhất được nhanh chóng xây dựng và chuyển giao cho khách hàng sử dụng. Thời gian hoàn thành phần đầu tiên này thường rất ngắn so với thời gian xây dựng toàn bộ phần mềm hoàn chỉnh. Như vậy khách hàng được sử dụng sản phẩm trong thời gian ngắn nhất và họ có thể được hưởng lợi từ việc sử dụng phần mềm. Khi mỗi phần sau được hoàn thành và được tích hợp thì họ được sử dụng ngay. Như vậy họ được làm quen từng bước với sản phẩm và sẽ ít bỡ ngỡ khi sản phẩm chứa đựng những công nghệ mới. Nhờ theo sát từng bước phát triển của phần mềm mà khách hàng có thể có những ý kiến xác đáng, giúp cho nhà phát triển đi đúng hướng và sản phẩm cuối cùng sẽ thỏa GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 9 [...]... Pha sử dụng và bảo trì GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 17 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM PHẦN II PHƯƠNG PHÁP SCRUM TRONG XÂY DỰNG PHẦN MỀM II.1 Khái niệm về SCRUM SCRUM là quy trình đã được định rõ của phương pháp Agile giúp theo dõi và điều khiển các hoạt động phát triển phần mềm Nó bao gồm những mảng hoạt động thiết lập, theo. .. Đánh giá (lại) SCRUM, quy trình này lặp lại lần nữa Việc lặp đi lặp lại này sẽ tiếp diễn cho đến khi đủ các tính năng sản phẩm được hoàn tất hoặc sản phẩm được xuất xưởng GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 25 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM PHẦN III ÁP DỤNG NHỮNG NGUYÊN LÝ SÁNG TẠO TRONG SCRUM III.1 Nguyên tắc phân nhỏ SCRUM phân chia... này chỉ nên áp dụng nếu công ty phần mềm có một đội ngũ chuyên gia phân tích rủi ro trình độ cao I.8 Mô hình hướng đối tượng (Object-Oriented model) GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 16 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM Hình 8 Mô hình hướng đối tượng Trong phương pháp hướng đối tượng, tính lặp giữa các pha và giữa các phần trong một... Việc sử dụng những cơ chế kiểm soát này cũng là yếu tố then chốt trong quy trình phát triển phần mềm GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 18 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM SCRUM Các thông số kiểm soát luôn được đo lường, theo dõi, và phối hợp với nhau Hai thông số chính là (danh sách) những việc chưa hoàn tất và rủi ro Danh sách những. .. (Product backlog) và Danh sách các việc chưa làm trong Đợt chạy nước rút ( Sprint backlog) theo tính chất của từng việc GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 27 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM PHẦN IV TÀI LIỆU THAM KHẢO [1] Hoàng Văn Kiếm, Bài giảng Phương pháp Nghiên cứu khoa học và tư duy sáng tạo, Trường Đại học Công nghệ Thông tin – Đại... Trần Bá Dược 15 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM • Trước hết, phân tích rủi ro sẽ tốn kém, do đó mô hình chỉ có thể áp dụng cho các dự án lớn, khi mà chi phí phân tích rủi ro là không đáng kể so với tổng chi phí toàn bộ dự án • Phân tích rủi ro được thực hiện trong suốt quá trình phát triển phần mềm Tuy nhiên nếu là phần mềm ký hợp đồng mà bị dừng... được trong đợt chạy nước rút (Sprint) trước mắt dựa trên thực tế nhóm dự án lớn hay nhỏ, độ dài ngắn của thời gian thực hiện, và năng suất của nhóm GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 26 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM III.4 Nguyên tắc tác động theo chu kỳ Khi thực hiện dự án theo quy trình SCRUM, SCRUM phân chia dự án thành những. .. và có thể hiệu chỉnh các yêu cầu, có thể là ngay trong quá trình các thành phần được xây dựng Mô hình này có thể áp dụng ngay cả trong trường hợp các đặc tả ban đầu không hoàn thiện I.7 Mô hình xoắn ốc (Spiral model) GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 12 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM Hình 7 Mô hình xoắn ốc (Spiral model) Mô hình...Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM mãn được các yêu cầu đặt ra, thậm chí qua việc sử dụng một số phần đầu, khách hàng nhận thấy rằng không nên phát triển tiếp vì sẽ không mang lại lợi ích kinh tế Khó khăn trong việc sử dụng mô hình tăng dần chính là sự tích hợp phần mới phát triển với phần chương trình đã có Thiết kế của... thể không tương thích với nhau Với mô hình tăng dần, khả năng rủi ro phần nào được giảm thiểu vì thiết kế kiến trúc được thực hiện trước khi phần mềm được chia nhỏ thành từng phần và được xây dựng GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 10 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM Sơ đồ mô hình này như sau: Hình 6 Mô hình tăng dần đồng thời (concurrent . Bá Dược 2 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM PHẦN I GIỚI THIỆU MỘT SỐ MÔ HÌNH TRONG XÂY DỰNG PHẦN MỀM I.1. Mô hình xây dựng và hiệu chỉnh. sử dụng và bảo trì. GVHD: GS.TSKH Hoàng Văn Kiếm, HVTH: Trần Bá Dược 17 Đề tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM PHẦN II PHƯƠNG PHÁP SCRUM TRONG XÂY. tài: Áp dụng những nguyên lý sáng tạo trong xây dựng phần mềm theo phương pháp SCRUM Hình 8. Mô hình hướng đối tượng Trong phương pháp hướng đối tượng, tính lặp giữa các pha và giữa các phần trong