quản trị dự án công nghệ tài chính Đề tài quy trình phát triển phần mềm (sdlc)

Do đó, nhà phát triển cần tuân thủ các chuẩn mực lập trình coding standards, áp dụng các kỹ thuật lập trình tốt best practices va str dụng các công cụ hỗ trợ tools để giám thiểu lỗi và t

TRƯỜNG ĐẠI HỌC NGÂN HÀNG TP HÒ CHÍ MINH

LỜI CẢM ƠN

Lời đầu tiên, chúng em xin gửi lời cảm ơn chân thành đến Giảng viên bộ môn Quản trị dự án công nghệ tài chính là thầy Đặng Trí Dũng đã hướng dẫn, truyền đạt những kiến thức quý báu cho chúng em Trong thời gian tham gia vừa qua, chúng em đã có thêm cho mình

nhiều kiến thức bê ích, tỉnh thần học tập hiệu quả, nghiêm túc

Bộ môn Quan tri dự án công nghệ tài chính là môn học vô cùng bỏ ích và có tính thực tế cao Đám bảo cung cấp đủ kiến thức, gắn liền với nhu cầu thực tiễn của sinh viên

Tuy nhiên, do vốn kiến thức còn nhiều hạn chế và khả năng tiếp thu thực tế còn nhiều bỡ

ngỡ Mặc dù chúng em đã có gắng hết sức nhưng chắc chắn bài tiêu luận nhóm này của chúng em khó có thê tránh khỏi những thiếu sót và nhiều chỗ còn chưa chính xác, kính mong thầy xem xét và góp ý đề bài tiểu luận của chúng em được hoàn thiện hơn a

Sau cùng, em xin kính chúc thầy thật đồi dào sức khỏe, niềm tin để tiếp tục thực hiện

sứ mệnh cao đẹp của mình là truyền đạt kiến thức cho thế hệ mai sau

Nhóm chúng em xin chân thành cảm ơn Thầy rất nhiều ạ!

1.3.1 Giai đoạn Lập kế hoạch và Phân tích yêu cầu (Analysis): ‹-:-:s55¿ 3

1.3.3 Giai đoạn Phát triển (Developimen†): ¿+ c2 cv SE Erkxexeerrkrrersee 5 c8 ‹{ 0i 0 in 6 A,O 5

1.3.6 Bảo trì (Malnf€nATC©): các ch KH 18 kh 6 Chương 2 Tổng quan về mô hình SDLC

2.1 Các mô hình cơ bản trong SDÚC c ch ng ki kh Ett 7 2.1.1 Mô hình WaterFall

2.1.2 Mô hình BigBang ern rr HH TH KH KH tk HT 9

2.1.3 MO NINN s5 0n nh -“caă ỏ.ố.Ắ.Ắồ 11

2.2 M6 hinh duroc str dung pho bién mhat .c.ccccscccccccsesessececsesesesecscecseseacecsssesececasseseeeees 13 2.2.1 MO NINN AGC «0.0 eee ce cecceee cece eeceneeeeeecaeceaeeecaeeeeeeceaeseneeecaeeseneesceeesenresieeesseeeas 13

2.2.2 Khung làm việc ŠcTu1m cc xxx th BE 15

2.2.3 So sánh sự khác nhau giữa Agile và ŠCTU Sky 16

2.3 So sánh các mô hình SH HH KHE KHE HT ĐH 17 Chương 3 Phần mềm thực tế ứng dụng mô hình SDLC

3.1 Phần mềm FINHAYY 6 25.5: St t2 xxx HH HH 1e 20

3.1.1 Khái niệm Finhay

3.1.2 Các giai đoạn phát triển phần mềm của Finhay ¿55+ se Scsxexscexees 20

3.1.3 Ưu điểm và nhược điểm của việc phat trién phan mềm Finhay .- 22

DANH MỤC HÌNH ÁNH

Hình 2 1: Quy trình của mô hình Waterfall nn nh ki kh 7 Hình 2 2: Quy trình của mô hình BigBang - nhe kết 9 Hình 2 3: Quy trình của mô hình SpITaÌL -ccccc nh nh kg hen 11 Hình 2 4: Quy trình tổng quan cia mG hinh Agile ccccsesccsssecsssseseeeceessecsesessseecsessessessresiesaesans 13 Hình 2 5: Quy trình được lặp đi lặp lại (iteratIOIì) ch khen rhh 14 Hình 2 6: Quy trình chỉ tiết của Šcrum tt tt tt v Sinh TH TH TT TH TH TH TH Hy rưện 15

Chương I Giới thiệu sơ lược về Quy trình phát triển phần mềm (SDLC)

1.1 Khái niệm

Quy trình phát triển phần mềm còn được gọi là vòng đời phát triển phần mềm (SDLC — Software Development Lif Cyele) là chuỗi các bước để xây đựng phần mềm chất lượng cao và đáp ứng yêu cầu của người dùng

SDLC bao gồm một kế hoạch chỉ tiết giái thích cách lập kế hoạch, xây dựng và báo trì phan mềm cụ thế Mỗi giai đoạn của Vòng đời SDLC đều có quy trình và sản phẩm phân phối riêng để chuyến sang giai đoạn tiếp theo với sự tham gia của đội ngũ phát triển phần mềm Quy trình được chia thành 6 bước:

1.2 Quy trình

e_ Giai đoạn 1: Lập kế hoạch và phân tích yêu cầu (Analysis)

Đây là giai đoạn đầu tiên và quan trọng nhất trong quy trình phát triển phần mềm Ở giai đoạn này, nhà phát triển sẽ tiền hành nghiên cứu vẻ nhu cầu, mong muốn, vấn đề của khách hàng

và người dùng Nhà phát triển sẽ xác định được mục tiêu, phạm vị, ngân sách, thời gian và các

ràng buộc của đự án Nhà phát triển cũng sẽ xây dựng được các tài liệu yêu cầu (requirement documents) để làm cơ sở cho các giai đoạn tiếp theo

e_ Giai đoạn 2: Thiết kế (Design)

Oo giai doan nay, nha phat triển sẽ dựa vào các tài liệu yêu cầu để thiết kế ra kiến trúc, giao

diện và các thành phân của phần mềm Thiết kế phần mềm sẽ giúp nhà phát triển hiểu được cách thức hoạt động, tính năng và chức năng của sản phẩm Thiết kế phần mềm cũng sẽ giúp nhà phát triển ước lượng được nguồn lực, công cụ và công nghệ cần thiết cho việc coding Kết qua cua giai

đoạn này là một tài liệu thiết kế phần mềm (SDD) hoặc một tài liệu đặc tả thiết kế (SDD)

e_ Giai đoạn 3: Phát triển (Development)

Quá trình xây dựng phần mềm được bắt đầu Ở bước này, các nhà phát triển phần mềm bắt

đầu lập trình (viết code) và triển khai các thông số thiết kế đã được xác định ở bước trước đó Cụ

thé, nhà phát triển giao điện người đùng (f#ont-end đevelopers) xây đựng giao diện cho phần mềm, trong khi nhà phát triển back-end developer sẽ sử đụng các ngôn ngữ lập trình va cac framework

dé lập trình trên máy chủ phối hợp với các quán trị cơ sở dữ liệu để xử lý dữ liệu

Sau khi hoàn tất việc lập trình, các nhà phát triển triển khai sản phẩm trong môi trường phát triển (môi trường test, không chứa người dùng thật và dữ liệu thật) Lập trình viên sẽ tiến hành kiêm thử (testing) và có sự điều chỉnh cần thiết, phù hợp để đám báo tuân thủ các yêu cầu đã

đặt ra

Đây cũng là giai đoạn đài nhất của quy trình Vòng đời phát triển phần mềm Giai đoạn này thường đòi hỏi thời gian và nguồn lực lớn nhất trong tất cá các giai đoạn của chu trình phát triển phần mềm Coding cũng là giai đoạn có thé gap nhiều lỗi và sai sót nhất Do đó, nhà phát triển cần tuân thủ các chuẩn mực lập trình (coding standards), áp dụng các kỹ thuật lập trình tốt (best practices) va str dụng các công cụ hỗ trợ (tools) để giám thiểu lỗi và tăng hiệu quá

e_ Giai đoạn 4: Kiếm thử (Testing)

Không phải sản phâm phần mềm nào sau khi lập trình xong cũng có thể hoạt động mượt

mà và đáp ứng đầy đủ yêu cầu của khách hàng Do đó, sau khi hoàn tất phan lập trình phần mềm,

sản phẩm sẽ tiếp tục chuyển cho các tester chuyên phụ trách kiếm thử phần mềm để tiến hành kiêm

tra

'Testers sẽ tạo các kịch bản kiểm thử và tiến hành test toàn diện Mục đích của việc kiểm

thử phần mềm là xác minh và đảm bảo chất lượng của sản phẩm đúng như yêu câu đề ra Nếu các chức năng chưa đạt yêu cầu thì cần yêu cầu Developers chỉnh sửa cho đến khi sản phâm đáp ứng yêu cầu đã được thống nhất với khách hàng

Sau khi kiểm thử, tester sé cap nhật các lỗi vào công cụ quản lý và thông báo các bug (lỗi) cho developers Trong giai doan nay, Testers lam viéc chat ché voi Developers dé khac phục các lỗi hoặc bắt kỳ vấn đề nào phát hiện được Tùy vào mô hình phát triển phần mềm được lựa chọn

mà hoạt động của developer và tester có thé tiến hành lần lượt hoặc diễn ra song song Quá trình

kiểm thử chức năng, kiểm tra lại, báo bug lỗi, báo cáo sẽ thực hiện đi thực hiện lại cho đến khi các chức năng lập trình đã thực hiện đúng theo tài liệu đặc tả hay yêu cầu của khách hàng e© Giai đoạn 5: Triển khai (Deployment)

Sau khi hoàn tất kiếm thử, phần mềm không còn lỗi, các nhà phát triển sẽ triển khai sản pham trén Production environment (méi trường chứa ứng dụng thật, chạy với người dùng thật, dir liệu thật) và cung cấp sản phâm hoàn thiện cho khách hàng Lúc này khách hàng đã bắt đầu sử dụng phần mềm ở mức chất lượng cao nhất

Một khi sản phẩm sau khi được kiếm thử và sẵn sàng triển khai, sản phẩm được phát hành chính thức trên thị trường thích hợp Sau khi phần mềm được đưa vào vận hành chính thức, bước tiếp theo chúng ta cần phải bảo trì sản phẩm Lúc này, công ty sẽ tạo ra một nhóm bảo trì dé quan

lý các vấn để mà khách hàng gặp phải khi sử dụng sản phẩm Khi muốn báo trì một sản phẩm, chúng ta cần làm:

- _ Sửa lỗi - lễi được báo cáo đo một số tình huống chưa được kiểm tra

- _ Upgrade — Nâng cấp ứng dụng lên các phiên bản mới hơn của Phần mềm

- _ Cải tiến — Thêm một số tính năng mới vào phần mềm hiện có

—> Trong giai đoạn này, giao tiếp và hỗ trợ khách hàng rất quan trọng để giữ cho phần mềm luôn hoạt động tốt và đáp ứng nhu cầu người dùng

—> Tóm lại, trên đây là các giai đoạn chu trình phát triển phần mềm gồm 6 bước chính Tuy nhiên, quy trình này có thê thay đổi tùy thuộc vào các mô hình và phương pháp phát triển cụ thê được sử

dụng

1.3 Rủi ro

Quy trình phát triển phần mềm thường bao gồm nhiều bước, từ thu thập yêu cầu đền triển khai và báo trì Mỗi bước trong quy trình đều tiềm ấn những rủi ro riêng có thể ảnh hưởng đến chat lượng, tiến độ và chỉ phí của dự án Dưới đây là một số rủi ro phố biến thường gặp trong từng bước của quy trình phát triển phần mềm:

1.3.1 Giai đoạn Lập kế hoạch và Phân tích yêu cầu (Analysis):

e_ Rủi ro về yêu câu:

- _ Yêu cầu không rõ ràng, không đầy đủ hoặc thay đổi thường xuyên: dẫn đến việc thiết kế, phát triển và thử nghiệm sai sót, lãng phí thời gian và chỉ phí

- _ Thiếu sự tham gia của người dùng: dẫn đến sản phâm không đáp ứng nhu cầu thực tế của người dùng, gây khó khăn trong việc sử dụng và ảnh hưởng đến sự hài lòng của khách hàng

®© Rủi ro về phạm vi dự án:

Xác định phạm vi dự án không chính xác hoặc không đây đủ: dẫn đến việc phát triển phần mềm vượt quá ngân sách, thời gian hoặc không đáp ứng đầy đủ yêu cầu

Thay đôi phạm vi dự án không được kiểm soát: dẫn đến việc lãng phí thời gian và chỉ phí, ảnh hưởng đến chất lượng phần mềm

—> Quy trình lên kế hoạch và phân tích yêu câu trong phát triển phần mềm thường có thế mang đến nhiều rủi ro chủ yếu vì những lý do sau đây:

Hiểu sai yêu câu của khách hàng: Việc phân tích yêu cầu không chính xác hoặc không đầy

đủ có thê dẫn đến hiểu lầm về những gì khách hàng thực sự mong đợi từ sản phâm phan mềm Điều này có thê dẫn đến việc phát triển sản phẩm không đáp ứng được yêu cầu thực

tế hoặc không đáp ứng được nhu cầu người dùng

Thiếu sự tương tác với khách hàng: Kế hoạch và phân tích yêu cầu thường diễn ra ở giai đoạn ban đầu của dự án khi mối tương tác với khách hàng thường còn ít Việc không có sự phản hỏi đầy đủ từ phía khách hàng có thê dẫn đến việc không hiểu rõ nhu cầu thực sự của

họ và làm mắt đi các cơ hội sửa đổi sớm

Thay đổi yêu cầu: Yêu cầu thay đổi thường xảy ra trong suốt quá trình phát triển phần mềm Nếu không có quy trình quán lý thay đổi yêu cầu hiệu quả, những thay đổi này có thế dẫn đến sự mắt cân bằng về phạm vi, ngân sách và thời gian

Khả năng ước lượng không chính xác: Kế hoạch dựa trên các ước tính ban đầu về phạm vị,

ngân sách và thời gian Việc ước tính không chính xác có thể dẫn đến các vấn đề về quản

ly dy an va lam mat di sy tin tưởng từ phía khách hàng và bên nội bộ

1.3.2 Giai đoạn Thiết kế (Design):

Rủi ro về thiết kế:

Thiết kế sai sót, thiểu hiệu quả hoặc không phù hợp với yêu câu: dẫn đến việc phát triển

phần mềm gặp nhiều khó khăn, tốn kém chỉ phí sửa lỗi và thay đổi thiết kế

Thiếu tài liệu thiết kế đầy đủ: gây khó khăn cho việc giao tiếp, phối hợp giữa các bên liên

quan, ảnh hưởng đến tiến độ và chất lượng dự án

Rủi ro về kien trúc phần mềm:

- _ Kiến trúc phần mềm không phù hợp hoặc không hiệu quả: dẫn đến việc phần mềm khó có thế mở rộng, bao trì và nâng cấp, ánh hưởng đến hiệu suất và khá năng đáp ứng nhu cầu trong tương lai

- Lỗi trong kiến trúc phần mềm: dẫn đến việc phần mềm không hoạt động chính xác hoặc

gặp nhiều lỗi trong quá trình sử đụng

1.3.3 Giai đoạn Phát triển (Development):

e Rairo vé lap trinh:

- Lỗi lập trình, sai sót trong mã nguồn: dẫn đến phần mềm không hoạt động đúng chức năng, gây ra lỗi và sự có trong quá trình sử dụng

- _ Chất lượng mã nguồn kém: dẫn đến việc phần mềm khó bảo trì, nâng cáp và để bị lỗi e©_ Rủi ro về quản lý mã nguồn:

- _ Thiếu kiểm soát phiên bán mã nguồn: dẫn đến việc khó theo đối thay đối, truy tìm lỗi và gây ra mâu thuẫn giữa các phiên bản

- _ Thiếu các quy trình quán lý mã nguồn hiệu quá: dẫn đến việc lãng phí thời gian, chỉ phi và

giám hiệu quả phát triên

1.3.4 Kiếm thử (Testing):

e Kiếm thử không đầy đủ: Dẫn đến việc phát hành phần mềm có lỗi ra thị trường

® Quy trình kiếm thử không hiệu quả: Dẫn đến việc lãng phí thời gian và tài nguyên

© Thiếu sự tham gia của người dùng: Dẫn đến việc phát triển phần mềm không đáp ứng được nhu cầu của người đùng

1.3.5 Trién khai (Deployment):

e Vấn đề triển khai: Dẫn đến việc phần mềm không hoạt động chính xác trong môi trường sản xuất

e_ Mất dữ liệu: Dẫn đến việc mắt mát dữ liệu quan trọng

®© Thiếu hỗ trợ người dùng: Dẫn đến việc người dùng gặp khó khăn trong việc sử dụng phần mềm

Lỗi mới: Dẫn đến việc phần mềm không hoạt động chính xác

Thay đối yêu cầu: Dẫn đến việc cần phải sửa đổi phần mềm để đáp ứng nhu cầu mới của người dùng

Thiếu tài liệu bảo trì: Dẫn đến việc khó khăn trong việc sửa lỗi và nâng cấp phần mềm

Đề giảm thiểu rủi ro trong quy trình phát triển phần mềm, cần có các biện pháp sau:

Áp dụng các phương pháp tốt nhất cho từng bước trong quy trình phát triển phần mềm

Sử dụng các công cụ và kỹ thuật phù hợp

Dao tạo nhân viên về các rủi ro tiểm ấn và cách giảm thiểu rủi ro

Giao tiếp hiệu quá giữa các thành viên trong nhóm và các bên liên quan

Theo dõi và đánh giá rủi ro thường xuyên

—> Bằng cách thực hiện các biện pháp này, có thê giảm thiểu rủi ro trong quy trình phát triển phần

mềm và tăng khả năng thành công của dự án Ngoài ra, việc lựa chọn mô hình phát triển phần mềm

phù hợp cũng có thể giúp giảm thiêu rủi ro Hiểu rõ rủi ro trong từng bước của quy trình phát triển phan mém là rất quan trọng đề có thể đưa ra các biện pháp giảm thiếu rủi ro phu hop va dam bao

dự án thành công

2.1 Các mô hình co ban trong SDLC

Hau hét tat cá các đự án hoặc phần mềm lớn nào đó đều sử đụng đến vòng đời phát triển phần mềm - hay còn được gọi tắt là SDLC SDLC sẽ cung cấp cho các nhà phát triển những mô hình cụ

thể để họ có thể áp dụng mô hình đó vào các dự án nhỏ của mình một cách chi tiết hơn để đảm bảo

quá trình chuyến đổi suôn sẻ từ đầu đến cuối dự án

Việc lựa chọn mô hình SDLC phù hợp còn phụ thuộc vào bối cảnh của dự án và yêu cầu kinh

doanh Vì thế mà từ trước đến nay đã có rất nhiều mô hình SDLC được phát triển để phù hợp hơn với những phần mềm và dự án Sau đây là một số mô hình được nhà phát triển ứng dụng vào các

dự án của mình

2.1.1 Mô hình WaterFall

®- Định nghĩa: mô hình WaterFall (thác nước) là một mô hình tuyến tính, tuần tự đổi với SDLC, có nghĩa là các bước trong các giai đoạn sau sẽ không thê bắt đầu cho đến khi giai

đoạn trước được hoàn thành, giống như một cái thác nước và đặc biệt là những điểm cuối

này không thể xem lại khi hoàn thành Đây được coi là phương pháp phát triển phần mềm

đầu tiên và thường áp dụng rộng rãi cho các dự án cấp cao; dự án phức tạp, nhiều mặt

© Cac giai doan:

Waterfall model

Hình 2 1: Quy trình của mô hình Waterfall

7

(1) Yêu cầu: xác định và ghi lai tat cả các yêu cầu của hệ thống hoặc phần mềm cần phát triển

(2) Phân tích: phân tích chỉ tiết các yêu cầu đã xác định dé hiểu rõ các khía cạnh kỹ thuật

(5) Kiểm thứ: xác định xem phần mềm có hoạt động đúng theo yêu câu và thiết kế không

(6) Vận hành/triên khai: triễn khai hệ thông phần mềm vào môi trường thực tế và bắt đầu `

Rõ ràng vẻ thời gian và ngân sách: do các giai đoạn phát triển và kiêm thử được xác định

rõ ràng từ đầu, mô hình Waterfall giúp dé dang ude tinh va quan ly thời gian cũng như

ngân sách của dự án

Tai liéu day di: mô hình này yêu cầu tài liệu chỉ tiết ở mỗi giai đoạn, giúp đám bảo rằng

tất cả các yêu cầu và thiết kế đều được ghi chép lại rõ ràng Điều này rất hữu ích cho việc bao trì và chuyến giao dự án sau này

Nhược điểm:

Thiếu linh hoạt: mô hình Waterfall không đễ dàng thích ứng với các thay đổi trong yêu cầu

dự án Khi một giai đoạn đã hoàn thành, rất khó để quay lại và thực hiện các thay đổi mà

không ảnh hưởng đến các giai đoạn sau

- _ Không phù hợp với các dự án phức tạp và không chắc chấn: đôi với các dự án mà yêu cầu không rõ ràng hoặc có khá năng thay đổi, mô hình Waterfall không phái là lựa chọn tốt nhất Điều này là đo mô hình này yêu cầu xác định yêu cầu và thiết kế chỉ tiết ngay từ đầu

- _ Khó khăn trong việc thay đổi yêu cầu: nêu có sự thay đôi trong yêu cầu dự án, việc quay lại và thay đôi thiết kế hoặc mã nguồn đã hoàn thành có thê rất tốn kém và phức tạp

- — Ír tương tác với khách hàng: mô hình Waterfall thường có ít sự tham gia của khách hàng sau giai đoạn thu thập yêu cầu ban đầu Điều này có thể dẫn đến việc sản phâm cuối cùng không đáp ứng đúng mong đợi của khách hàng

- - Không phù hợp với dự án đài hạn: đối với các dự án kéo đài, mô hình Waterfall có thể không đáp ứng được các yêu cầu thay đổi theo thời gian và công nghệ mới

- Núi ro cao: với mô hình WaterfalL, rủi ro tập trung vào cuối dự án, khi phát hiện ra lỗi hoặc

vấn đề trong giai đoạn kiểm thử Điều này có thể làm tăng nguy cơ dự án không hoàn thành đúng hạn hoặc vượt quá ngân sách

—> Tóm lại, một mô hình có quá nhiều nhược điểm như này sẽ khiến nó ít phù hợp hơn với các dự

án phan mềm hiện đại, đặc biệt là những dự án yêu cầu sự linh hoạt và khả năng thích ứng cao

2.1.2 Mô hình BigBang

®_ Định nghĩa: Mô hình BigBang là một mô hình SDLC đơn giản, phù hợp cho các dự án nhỏ để học tập hoặc một dự án phụ không cần thiết lập nhiều kế hoạch Nó quá đơn giản nhưng lại đòi hỏi nhiều tiền, mã hóa phức tạp và mắt nhiều thời gian nên nó chứa đựng nhiều rủi ro vì các dự án lớn có nhiều phức tạp và yêu cầu của các bên liên quan thay đổi

(1) Đấu vào: thời gian, tài nguyên, và nỗ lực được đưa vào quá trình phát triên phần mềm

mà không có kế hoạch chỉ tiết

(2) Mô hình Big Bang: các nhà phát triển thường tiễn hành viết mã, kiểm thử, và tích hợp ` trực tiếp mà không có kế hoạch rõ ràng

Thich hop cho các dự án nhỏ và thứ nghiệm: mô hình này phù hợp cho các dự án nhỏ, nơi

mà yêu cầu không rõ ràng hoặc không quan trọng, cũng như cho các dự án thử nghiệm hoặc nguyên mẫu

Thời gian phát triển ngắn: vì không cần nhiều tài liệu và không có giai đoạn cụ thể, thời

gian phát triển có thể ngắn hơn so với các mô hình khác

Nhược điểm:

Rui ro cao: với mô hình Big Bang, có rất Ít hoặc không có kế hoạch và tài liệu chỉ tiết

Điều này có thê dẫn đến rủi ro cao, vì sản phâm cuối cùng có thế không đáp ứng được yêu cầu của khách hàng

Khó kiểm soát va quan lý: thiêu câu trúc và quy trình rõ ràng khiến việc quản lý và kiếm

soát dự án trở nên khó khăn, đặc biệt đối với các dự án lớn hoặc phúc tạp

Khó khăn trong việc kiểm thứ và bảo trì: vì không có giai đoạn kiêm thử rõ ràng, lỗi có thể

không được phát hiện sớm Điều này làm cho việc kiểm thử và báo trì sán phẩm trở nên

khó khăn hơn

ràng từ đầu có thê dẫn đến khó khăn trong việc đáp ứng các yêu cầu thay đổi một cách có

tổ chức

—> Tóm lại, mặc dù mô hình Big Bang có thể hữu ích trong một số trường hợp cụ thể (phát triển một dự án cho mục đích học tập; khi có yêu cầu cần thực hiện ngay lập tức, .), nhưng do nhiều rủi ro và hạn chế, nó không phái là lựa chọn tốt nhất cho hẳu hết các dự án phần mềm, đặc biệt là những dự án lớn và phức tạp

2.1.3 Mô hình Spiral

®- Định nghĩa: mô hình xoắn ốc là một mô hình quan trọng của SDLC, nó là sự kết hợp giữa

mô hình Waterfall và mô hình Agile, được cung cấp đề hỗ trợ xử lý các sự cố xảy ra hay nói cách khác khá năng xử lý rủi ro trong mô hình xoắn ốc được ưu tiên hàng dau

© Cac giai doan:

= mi

Plan Risk Analysis

Requirements Risk Reduction

Hình 2 3: „y trình của mô hình Spiral

(1) Lập kế hoạch, xác định mục tiếu: các yêu cầu được thu thập từ khách hàng và các mục tiêu sẽ được xác định, xây dựng và phân tích khi bắt đầu mỗi giai đoạn Sau đó, các giải pháp thay thé kha thi cho giai đoạn này sẽ được đề xuất ở góc phần tư này (Plan)

11

(2) Xác định và giải quyết rủi ro: trong góc phần thứ tư (Risk Analysis), tất cá các giải pháp đều được đánh giá để chọn giái pháp tốt nhất có thể Sau đó, những rủi ro liên quan đến giải pháp được xác định rõ ràng và không may có thế được giải quyết bằng chiến lược tốt nhất có thê Ở góc cuối cùng của phần tư vấn này, mẫu được xây dựng

đê đưa ra giải pháp tốt nhất có thê

(3) ` Phát triển phiên bản tiếp theo của sản phẩm: Trong góc phần tư thứ ba (Engineering), các tính năng đã được xác định là phát triển và xác minh thông tin qua thử nghiệm Vào góc cuối cùng của phần thứ tư, phiên bản tiếp theo của phần mềm sẽ có san (4) Xem xét và lập kế hoạch cho giai đoạn tiếp theo: Trong phan thứ tư (Evaluate), khách hàng đánh giá phiên bản phần mềm đã được phát triển cho đến nay Cuối cùng, thiết lập kế hoạch cho giai đoạn tiếp theo được bắt dau

Phát hiện sớm vấn đề: với việc thực hiện các nguyên mẫu và kiêm thử trong mỗi vòng xoắn ốc, các vấn đề có thê được phát hiện sớm và giái quyết kịp thời

Tương tác thường xuyên với khách hàng: khách hàng có thê tham gia vào quá trình phát triển trong mỗi vòng xoắn ốc, đảm báo rằng sản phẩm cuối cùng đáp ứng đúng mong đợi

và yêu cầu của họ

Phù hợp với các dự án lớn và phức tạp: mô hình Sprral đặc biệt phù hợp cho các dự án lớn,

nơi mà việc quản lý rủi ro và sự linh hoạt là rat quan trọng

Nhược điểm:

Chi phí cao: việc lặp đi lặp lại các vòng xoắn ốc có thé lam tang chi phi phát triển, đặc biệt

khi cần nhiều nguyên mẫu và các hoạt động kiểm thử chỉ tiết

- _ Phúc tạp trong quản Ïýÿ: mô hình Spiral yêu cầu quản lý chỉ tiết và liên tục theo đối tiến độ, đánh giá rủi ro và lập kế hoạch Điều này có thê làm tăng độ phức tạp trong quán lý đự án

- _ Không phù hợp cho các dự én nhỏ: đôi với các dự án nhỏ hoặc có yêu cầu rõ ràng ngay từ đầu, mô hình Spiral có thể không phải là lựa chọn tốt nhất do chi phí và sự phức tạp không can thiết

- Yêu cầu chuyên môn cao: đễ thực hiện mô hình Spiral hiệu quả, nhóm phát triển cần có kỹ năng và kinh nghiệm trong việc đánh giá rủi ro và quản lý dự án

- Kho khan trong việc xác định thời gian và ngân sách cu thé: do tính linh hoạt và lặp lại của mô hình, việc dự đoán thời gian và ngân sách cụ thể cho toàn bộ dự án có thể trở nên

kho khan

2.2 Mô hình được sử dụng phố biến nhất

2.2.1 Mô hình Agile

® Định nghĩa: mô hình Agile được đề xuất để khắc phục những rủi ro của mô hình Waterfall,

nó là một phương pháp phát triển phần mềm linh hoạt và là một tập hợp các nguyên tắc, giá trị bao gồm nhiều khung làm việc (ữamework) khác nhau như Scrum, Kanban, XP (Extreme Programming), và nhiều khung khác Nó không chỉ đơn giản là hoàn thành xong sản phẩm từ vòng xoáy đầu tiền mà nó sẽ là một chuỗi các chu kì được lặp đi lặp lại đến khi dự án hoàn thành hoặc là đáp ứng được hết tất ca các nhu câu của khách hàng cũng như

là các bên liên quan

® Cúc quy trình:

Hình 2 4: Quy trình tổng quan của mô hình Agile

(2) Thiết kế: thiết kế kiến trúc và các thành phân chỉ tiết của hệ thống

(3) Phát triển: lập trình theo các yêu cầu đã được xác định

(4) Kiểm thứ: sử dụng các loại kiêm thử (kiểm thử đơn vị, tích hợp, hệ thống, chấp nhận)

để đảm bảo phần mềm hoạt động đúng theo yêu câu và thiết kế

(5) Triển khai: đào tạo và cài đặt người dùng, sau đó triển khai vào hệ thống

(6) Đánh giá: tô chức cuộc họp đề đánh giá quá trình và nhận phán hồi từ khách hàng và

các bên liên quan, sau đó điều chỉnh theo yêu cầu

(7) Bàn giao: tổ chức cuộc hợp bàn giao và xác định các cải tiến cần thiết