Tiểu luận hệ thống thông tin quản trị Mô hình thác nước Waterfall model

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

DANH SÁCH THÀNH VIÊN NHÓM

ST

1

03012509054

0

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

03012509051

5

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 03012509099

2

Phạm Thị Minh Tâm - Tìm tài liệu, thuyết trình,

trả lời câu hỏi

4

03012509081

2

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 03012509075

8

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

03012509090

9

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

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ỉ 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!

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

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 ?

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

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 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,…

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.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

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]