Á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

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

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

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

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

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à

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ó

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ó

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:

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

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

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

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 mô hình này do vậy phải có tính

mở và tính mềm dẻo để thích nghi với việc mở rộng dần Ta có thể nhận thấy rằng, trong mô hình tăng dần không có sự khác biệt giữa sự phát triển phần mềm và bảo trì

cập nhật (nâng cao) Nếu vận dụng không hợp lý, mô hình này có thể suy thoái thành

mô hình xây dựng và hiệu chỉnh Sự điều khiển toàn bộ quy trình phát triển phần mềm

có thể bị mất và sản phẩm nhận được thay vì có tính mở lại là nỗi kinh hoàng cho những người bảo trì Để tránh được điều này, người phát triển ngay từ đầu phải có cách nhìn toàn cục về sản phẩm, phải đưa ra thiết kế tổng thể của sản phẩm và sự phân chia các thành phần để phát triển sau này cũng phải trên cơ sở thiết kế toàn cục đó Như sơ

đồ (trong hình 5) đã chỉ ra, các pha yêu cầu, đặc tả và thiết kế kiến trúc phải được thực hiện trước khi các thành phần nhỏ hơn được bắt đầu xây dựng Nếu không có những nhà chuyên môn trình độ cao thì sản phẩm phát triển theo mô hình này có thể trở thành sản phẩm kém chất lượng

I.5 Mô hình tăng dần đồng thời (Concurrent incremental model)

Mô hình tăng dần đồng thời còn có tên gọi khác là "lập trình cực điểm" (extreme programming – viết tắt là XP) Tuy nhiên chúng ta sẽ gọi là mô hình tăng dần đồng thời cho dễ hình dung Có thể tóm tắt mô hình này như sau:

Trước hết người ta tìm hiểu nhu cầu khách hàng rồi phân chia thành nhóm các đặc trưng tương ứng với từng phần của phần mềm cần xây dựng Sau đó nhóm đặc tả tiến hành xây dựng đặc tả của phần thứ nhất, sau khi hoàn thành thì trao kết quả cho nhóm thiết kế thực hiện thiết kế, nhóm lại chuyển qua đặc tả thành phần thứ hai, cứ như vậy các thành phần được xây dựng song song, và mỗi nhóm sử dụng các thông tin nhận được từ các thành phần trước đó

Cách tiếp cận này thực sự đã gây ra rủi ro là các thành phần có 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

Sơ đồ mô hình này như sau:

Hình 6 Mô hình tăng dần đồng thời (concurrent incremental model (XP))

Đây là mô hình còn có nhiều tranh cãi Thực chất là mô hình tăng dần, nhưng các phần được thực hiện đồng thời Mô hình này có tính rủi ro cao hơn mô hình tăng dần thông thường Bước đầu tiên nhóm phát triển phần mềm dựa vào ý kiến khách hàng để xác định các đặc trưng khác nhau của phần mềm Với mỗi đặc trưng như vậy

họ thông báo cho khách hàng là phải xây dựng trong bao lâu và giá cả bao nhiêu Tiếp theo khách hàng lựa chọn những đặc trưng cho các phần cần xây dựng dựa trên phân tích giá cả và lợi nhuận (cost-benifit analysis), tức là phân tích dựa trên thời gian và giá

cả nêu ra bởi nhóm phát triển và lợi nhuận dự tính của công ty họ Mỗi phần được lựa chọn lại được chia thành từng phần nhỏ hơn, được gọi là các nhiệm vụ Mỗi lập trình viên trước hết nêu ra các trường hợp để thử cho từng nhiệm vụ sau đó cùng làm việc với cộng sự của họ trước một màn hình (kiểu lập trình này được gọi là pair programming) Lập trình viên hoàn thành nhiệm vụ được giao và chạy các trường hợp thử để bảo đảm phần chương trình họ viết đã chạy tốt Phần chương trình này sau đó được tích hợp vào phiên bản hiện thời của phần mềm cần xây dựng Trường hợp lý tưởng là cả phần lập trình và tích hợp cho một nhiệm vụ chỉ kéo dài trong vài giờ Thường thì các cặp lập trình viên thực hiện các nhiệm vụ song song, như thế sự tích hợp sẽ được tiến hành một cách liên tiếp Các trường hợp dùng để thử các nhiệm vụ

được giữ lại cho các phép kiểm thử tích hợp sau này Một số đặc trưng của lập trình cực điểm (XP) có phần nào hơi khác thường:

• Máy tính của các nhóm lập trình cực điểm được đặt giữa phòng lớn, trong các phòng nhỏ có vách ngăn

• Đại diện của khách hàng luôn luôn làm việc cùng nhóm XP

• Không ai làm việc quá giờ trong hai tuần liên tục

• Không có phân công đặc biệt Tất cả các thành viên của nhóm XP đều có thể tham gia phân tích, thiết kế, lập trình và kiểm thử

• Như sơ đồ đã chỉ ra, không có thiết kế tổng thể trước khi các phần được xây dựng Thay vào đó, thiết kế sẽ được hiệu chỉnh khi sản phẩm được xây dựng Thủ tục này được gọi là tái phân tích nhân tố (refactoring) Khi một trường hợp thử không chạy tốt thì các lệnh sẽ được viết lại cho đến khi nhóm lập trình thấy rằng thiết kế là đơn giản, rõ ràng và mọi trường hợp thử đều chạy tốt

Mô hình này thực sự có lợi khi yêu cầu của khách hàng không rõ ràng và hay thay đổi Tuy nhiên mô hình này còn chưa được sử dụng rộng rãi

I.6 Mô hình đồng bộ và ổn định (Synchronize and stabilize model)

Mô hình đồng bộ và ổn định được xây dựng bởi David Yoffie (Đại học Harvard) và Michael Cusumano (làm việc ở MIT) Pha xác định yêu cầu được thực hiện bằng cách phỏng vấn rất nhiều khách hàng dự kiến và các đặc trưng của nhu cầu khách hàng được liệt kê theo thứ tự ưu tiên Sau đó tài liệu đặc tả được soạn thảo Tiếp theo, công việc được chia làm ba hoặc bốn phần Phần thứ nhất chứa các đặc trưng quan trọng nhất, phần thứ hai chứa các đặc trưng quan trọng thứ nhì Mỗi thành phần

sẽ được xây dựng bởi một số nhóm nhỏ làm việc song song Cuối mỗi ngày các nhóm đồng bộ hóa (synchronize), tức là họ hợp lại những phần họ đã làm riêng biệt thành một thành phần thống nhất, kiểm tra, sửa lỗi và kiểm thử Sự ổn định hóa (stabilize) được thực hiện ở giai đoạn cuối của mỗi phần Trong giai đoạn này những lỗi còn sót lại được phát hiện, được sửa chữa và thành phần được đóng gói, tức là không thực hiện thay đổi nào đối với các đặc tả

Các bước đồng bộ hóa được lặp lại bảo đảm rằng các thành phần khác nhau có thể được kết hợp và cùng làm việc tốt Một điểm lợi của cách làm này là những người phát triển có thể sớm nhìn thấy sự hoạt động của phần mềm 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ó

Hình 7 Mô hình xoắn ốc (Spiral model)

Mô hình xoắn ốc (do Boehm đề xuất năm 1988) là kết hợp các khía cạnh của các mô hình trên đây Cụ thể hơn, mô hình xoắn ốc là sự kết hợp tính lặp của mô hình bản mẫu và tính hệ thống của mô hình thác đổ Về bản chất, mô hình xoắn ốc mô tả sự phát triển của phần mềm qua các giai đoạn tiến hoá, mỗi giai đoạn được coi như một

mô hình thác đổ Ban đầu người ta chưa định nghĩa hệ thống một cách chi tiết, mà chỉ chú ý đến những đặc trưng nổi bật nhất Sau đó phần đặc trưng này được xây dựng và đưa cho khách hàng xem xét, có ý kiến (cũng không hẳn là sử dụng cho công việc như trong mô hình tăng dần) Cùng những thông tin phản hồi từ khách hàng, người phát triển trở lại thực hiện các đặc trưng với mức độ chi tiết hơn Bản chất mô hình xoắn ốc như tên gọi của nó, là bắt đầu từ những cái khái quát nhất rồi đi dần đến chi tiết Trong quá trình đó có lập kế hoạch cho từng giai đoạn làm chi tiết hóa sản phẩm và phân tích rủi ro

Quá trình xây dựng phần mềm thường chứa đựng những rủi ro Ví dụ người chủ chốt có thể xin nghỉ việc trước khi phần mềm được hoàn thành Công ty chế tạo phần cứng mà phần mềm sẽ cài đặt bị phá sản Sau khi chi phí hàng trăm nghìn đô la cho sự phát triển phần mềm bỗng có một bước thay đổi đột phá trong công nghệ làm cho phần mềm trở nên vô dụng, phải thiết kế lại hoàn toàn Công ty có thể nghiên cứu và phát