Chương 2

Machine Translated by Google
Chương 2
Vòng đời phần mềm

Người mẫu
Mục tiêu học tập
Sau khi nghiên cứu chương này, bạn sẽ có thể
• Mô tả cách phát triển sản phẩm phần mềm trong thực tế. •
Hiểu mô hình vòng đời cây tiến hóa. • Đánh giá
cao tác động tiêu cực của sự thay đổi đối với sản phẩm phần mềm. •
Sử dụng mô hình vòng đời lặp đi lặp lại và tăng dần. •
Hiểu được tác động của Định luật Miller đối với sản xuất phần mềm.
• Mô tả điểm mạnh của mô hình vòng đời lặp đi lặp lại và tăng dần. • Nhận
thức được tầm quan trọng của việc sớm giảm thiểu
rủi ro. • Mô tả các quy trình linh hoạt, bao gồm cả lập trình
cực đoan. • So sánh và đối chiếu nhiều mô hình vòng đời khác nhau.
Chương 1 mô tả các sản phẩm phần mềm sẽ được phát triển như thế nào trong một thế giới lý
tưởng. Chủ đề của chương này là những gì xảy ra trong thực tế. Như sẽ được giải thích, có sự
khác biệt rất lớn giữa lý thuyết và thực hành.
2.1 Phát triển phần mềm về mặt lý thuyết

Trong một thế giới lý tưởng, một sản phẩm phần mềm được phát triển như mô tả trong Chương 1.
Như được mô tả dưới dạng sơ đồ trong Hình 2.1, hệ thống được phát triển từ đầu; biểu thị tập
rỗng. (Xem Phòng trường hợp bạn muốn biết Hộp 2.1 nếu bạn muốn biết nguồn gốc của thuật ngữ
này từ đầu .) Trước tiên, các Yêu cầu của khách hàng được xác định, sau đó là Phân tích
37
Chỉ trong trường hợp bạn muốn biết Hộp 2.1
Thuật ngữ từ đầu, có nghĩa là “bắt đầu từ con số không”, xuất phát từ thuật ngữ thể thao thế kỷ
19. Trước khi đường (và đường chạy) được trải nhựa, các cuộc đua phải được tổ chức trên bãi đất
trống. Trong nhiều trường hợp, vạch xuất phát chỉ là một vết xước trên cát. Một vận động viên
chạy không có lợi thế hoặc khuyết tật phải xuất phát từ vạch đó, tức là “từ đầu”.
Ngày nay, thuật ngữ cào có một ý nghĩa thể thao khác. Một “người chơi gôn cào” là
người có handicap chơi gôn bằng 0.
HÌNH 2.1
Lý tưởng hóa
phần mềm
phát triển.
Yêu cầu
Phân tích
Thiết kế
Thực hiện
Phát triển
được thực hiện. Khi các tạo phẩm phân tích hoàn tất, Thiết kế sẽ được tạo ra. Tiếp theo là việc Triển
khai sản phẩm phần mềm hoàn chỉnh, sau đó được cài đặt trên máy tính của khách hàng.
Tuy nhiên, việc phát triển phần mềm trong thực tế có sự khác biệt đáng kể vì hai lý do.
Đầu tiên, các chuyên gia phần mềm cũng là con người và do đó có thể mắc sai lầm. Thứ hai, yêu cầu của
khách hàng có thể thay đổi trong quá trình phát triển phần mềm. Trong chương này, cả hai vấn đề này
đều được thảo luận sâu hơn, nhưng trước tiên chúng tôi trình bày một nghiên cứu trường hợp nhỏ, dựa
trên nghiên cứu trường hợp trong [Tomer và Schach, 2000], minh họa các vấn đề liên quan.
C
Nghiên cứu nhỏ
2.2 2.2
Nghiên cứu điển hình nhỏ về Winburg
Để giảm tắc nghẽn giao thông ở trung tâm thành phố Winburg, Indiana, thị trưởng thuyết phục
thành phố thiết lập hệ thống giao thông công cộng. Các làn đường dành riêng cho xe buýt sẽ được
thiết lập và người đi lại sẽ được khuyến khích “đỗ và đi”; nghĩa là, đỗ xe ở các bãi đậu xe ở
ngoại ô rồi bắt xe buýt từ đó đi làm và quay về với chi phí một đô la cho mỗi chuyến đi. Mỗi xe
buýt phải có một máy bán vé chỉ chấp nhận tiền đô la.
Hành khách nhét hóa đơn vào khe khi họ bước vào xe buýt. Các cảm biến bên trong máy tính tiền
sẽ quét hóa đơn và phần mềm trong máy sử dụng tính năng nhận dạng hình ảnh
Chương 2 Mô hình vòng đời phần mềm 39
thuật toán để quyết định xem hành khách có thực sự nhét tờ đô la hợp lệ vào khe hay
không. Điều quan trọng là máy bán vé phải chính xác vì một khi có thông tin cho rằng bất
kỳ mảnh giấy nào cũng có tác dụng, thu nhập từ vé sẽ giảm mạnh xuống mức 0. Ngược lại,
nếu máy thường xuyên từ chối những tờ đô la hợp lệ, hành khách sẽ ngần ngại sử dụng xe
buýt. Ngoài ra, máy tính tiền phải nhanh chóng. Hành khách cũng sẽ miễn cưỡng sử dụng xe
buýt nếu máy dành 15 giây để đưa ra quyết định về tính hợp lệ của tờ đô la - ngay cả một
số lượng hành khách tương đối nhỏ cũng phải mất nhiều phút để lên xe buýt. Do đó, yêu
cầu đối với phần mềm máy tính giá vé bao gồm thời gian phản hồi trung bình dưới 1 giây
và độ chính xác trung bình ít nhất là 98%.
Tập 1 Phiên bản đầu tiên của phần mềm được triển khai.
Các thử nghiệm Tập 2 cho thấy rằng không đạt được giới hạn yêu cầu về thời gian phản hồi
trung bình là 1 giây để quyết định tính hợp lệ của tờ đô la. Trên thực tế, trung bình
phải mất 10 giây để nhận được phản hồi. Quản lý cấp cao phát hiện ra nguyên nhân. Có vẻ
như để đạt được độ chính xác 98% cần thiết, một lập trình viên đã được người quản lý của
cô ấy hướng dẫn sử dụng các con số có độ chính xác kép cho tất cả các phép tính toán
học. Kết quả là mỗi thao tác mất ít nhất gấp đôi thời gian so với các số có độ chính xác
đơn thông thường. Kết quả là chương trình chậm hơn nhiều so với bình thường, dẫn đến thời
gian phản hồi lâu. Các tính toán sau đó cho thấy rằng, bất chấp những gì người quản lý
đã nói với người lập trình, vẫn có thể đạt được độ chính xác 98% như quy định ngay cả
khi sử dụng các số có độ chính xác đơn. Lập trình viên bắt đầu thực hiện những thay đổi
cần thiết trong quá trình triển khai.
Tập 3 Trước khi lập trình viên có thể hoàn thành công việc của mình, các thử nghiệm sâu
hơn của hệ thống cho thấy rằng, ngay cả khi những thay đổi được chỉ định đối với việc
triển khai được thực hiện, hệ thống vẫn sẽ có thời gian phản hồi trung bình trên 4,5
giây, không bằng thời gian quy định 1 thứ hai. Vấn đề là thuật toán nhận dạng hình ảnh phức tạp.
May mắn thay, một thuật toán nhanh hơn vừa được phát hiện nên phần mềm máy tính giá vé
đã được thiết kế lại và triển khai lại bằng thuật toán mới. Điều này dẫn đến thời gian
phản hồi trung bình đạt được thành công.
Tập 4 Hiện tại, dự án đang bị chậm tiến độ đáng kể và vượt quá ngân sách. Thị trưởng,
một doanh nhân thành đạt, có ý tưởng sáng suốt là yêu cầu nhóm phát triển phần mềm cố
gắng tăng độ chính xác của thành phần nhận dạng hóa đơn đô la của hệ thống càng nhiều
càng tốt để bán gói hàng thu được cho các công ty máy bán hàng tự động. . Để đáp ứng
yêu cầu mới này, một thiết kế mới đã được áp dụng nhằm cải thiện độ chính xác trung bình
lên hơn 99,5%. Ban quản lý quyết định cài đặt phiên bản phần mềm đó vào máy tính tiền.
Tại thời điểm này, quá trình phát triển phần mềm đã hoàn tất. Thành phố sau đó có thể
bán hệ thống của mình cho hai công ty máy bán hàng tự động nhỏ, bù đắp khoảng một phần
ba chi phí.
tràn ngập.
Phần kết Vài năm sau, các cảm biến bên trong máy tính tiền trở nên lỗi thời và cần được
thay thế bằng mẫu mới hơn. Ban quản lý đề nghị tận dụng sự thay đổi để nâng cấp phần
cứng cùng một lúc. Các chuyên gia phần mềm chỉ ra rằng việc thay đổi phần cứng có nghĩa
là cần có phần mềm mới. Họ đề nghị triển khai lại phần mềm bằng một ngôn ngữ lập trình
khác. Tại
40 Phần A Khái niệm Kỹ thuật Phần mềm
HÌNH 2.2 Mô hình vòng đời cây tiến hóa cho nghiên cứu điển hình nhỏ ở Winburg. (Hình chữ nhật được vẽ bằng
đường chấm chấm biểu thị việc triển khai chưa được hoàn thành.)
Phát triển
BẢO TRÌ
Yêu cầu1 Yêu cầu4
Phân tích1 Phân tích4
Thiết kế1 Thiết kế3 Thiết kế4
Thực hiện1 Thực hiện2 Thực hiện3 Thực hiện4
Tập 1 Tập 2 Tập 3 Tập 4
Tại thời điểm viết bài, dự án chậm tiến độ 6 tháng và vượt 25% ngân sách.
Tuy nhiên, tất cả những người liên quan đều tự tin rằng hệ thống mới sẽ đáng tin cậy hơn và có
chất lượng cao hơn, bất chấp “những khác biệt nhỏ” trong việc đáp ứng các yêu cầu về thời gian
phản hồi và độ chính xác.
Hình 2.2 mô tả mô hình vòng đời cây tiến hóa của nghiên cứu trường hợp nhỏ.
Các hộp ngoài cùng bên trái thể hiện Tập 1. Như được hiển thị trong hình, hệ thống được phát triển
từ đầu (). Các yêu cầu (Requirements), thiết kế (Design) lần lượt theo sau.
1 ), phân
Tiếp tích
theo,(Phân
như đã
tích
mô1
tả trước đây, các thử

1 ) và
nghiệm
triểnphiên
khai bản
(Implementation
đầu tiên của phần mềm cho thấy
1 không thể đạt được thời
gian phản hồi trung bình là 1 giây và việc triển khai phải được sửa đổi. Triển khai được sửa đổi
xuất hiện trong Hình 2.2 dưới dạng Triển khai. Tuy nhiên, việc gửi triển khai Triển khai được vẽ
bằng một đường chấm. 2 .
2 chưa bao giờ được hoàn thành. Đó là lý do tại sao hình chữ nhật đại diện cho
2
Trong tập 3, thiết kế đã phải thay đổi. Cụ thể, khả năng nhận dạng hình ảnh nhanh hơn) dẫn
thuật toán tion đã được sử dụng. Thiết kế được sửa đổi (Tư 3 đến việc thực hiện được sửa đổi.
vấn thiết kế (Thực hiện Cuối 3 ).
cùng, trong Tập 4, các yêu cầu đã được thay đổi (Yêu cầu 4 ) để ở-
tăng độ chính xác. Điều này dẫn đến các thông số kỹ thuật được sửa đổi (Thiết kế 4 ), được sửa đổi
phân tích (Thiết kế
4 ) và triển khai được sửa đổi (Thực hiện 4 ).
Trong hình 2.2 , các mũi tên liền biểu thị sự phát triển và các mũi tên đứt nét biểu thị sự
bảo trì. Ví dụ: khi thiết kế được thay đổi trong Tập 3, Thiết kế được thay thế Thiết kế Mô hình 3
cây tiến hóa là một 1 như thiết kế của Phân tích 1 .
ví dụ về mô hình vòng đời (hay gọi tắt là mô hình ), tức là chuỗi các bước được thực hiện ,
trong khi sản phẩm phần mềm được phát triển và duy trì. Một mô hình vòng đời khác có thể được sử
dụng cho mô hình mini

HÌNH 2.3 Một
phiên bản
đơn giản hóa
của mô hình
vòng đời thác nước.

Yêu cầu
Phân tích
Thiết kế
Thực hiện
Phát triển
BẢO TRÌ
nghiên cứu trường hợp là mô hình vòng đời thác nước [Royce, 1970]; một phiên bản đơn
giản hóa của mô hình thác nước được mô tả trong Hình 2.3. Mô hình vòng đời cổ điển
này có thể được xem như mô hình tuyến tính của Hình 2.1 với các vòng phản hồi. Sau
đó, nếu tìm thấy lỗi trong quá trình thiết kế do lỗi trong yêu cầu, theo các mũi tên
hướng lên trên nét đứt, thì nhà phát triển phần mềm có thể quay lại từ thiết kế đến
phân tích và từ đó đến các yêu cầu và thực hiện các chỉnh sửa cần thiết ở đó.
Sau đó, họ chuyển sang phân tích, sửa tài liệu đặc tả để phản ánh những sửa đổi đối
với yêu cầu và lần lượt sửa tài liệu thiết kế. Các hoạt động thiết kế giờ đây có thể
tiếp tục ở nơi chúng đã bị tạm dừng khi phát hiện ra lỗi.
Một lần nữa, các mũi tên liền biểu thị sự phát triển; mũi tên nét đứt, bảo trì.
Mô hình thác nước chắc chắn có thể được sử dụng để đại diện cho nghiên cứu điển hình nhỏ ở Winburg,
tuy nhiên, không giống như mô hình cây tiến hóa ở , nhưng nó không thể hiển thị thứ tự các sự kiện.
Hình 2.2, mô hình cây tiến hóa có lợi thế hơn mô hình thác nước. Vào cuối mỗi tập,
chúng ta có một đường cơ sở , tức là ,một tập hợp hoàn chỉnh các tạo phẩm (hãy nhớ
rằng tạo tác là một thành phần cấu thành của một sản phẩm phần mềm). Có bốn đường cơ
sở trong Hình 2.2. họ đang
Cuối Tập 1: Yêu cầu 1 , Phân tích1 , Thiết kế 1, Thực hiện 1
Cuối Tập 2: Yêu cầu 1, Phân tích1, Thiết kế 1, Thực hiện 2
Đường cơ sở đầu tiên là tập hợp các tạo tác ban đầu; đường cơ sở thứ hai phản ánh việc
triển khai đã được sửa đổi (nhưng chưa bao giờ

2 hoàn thành) của Phần 2, cùng với các yêu cầu,
phân tích và thiết kế không thay đổi của Phần 1. Đường cơ sở thứ ba giống như đường cơ sở
đầu tiên nhưng có thay đổi về thiết kế và cách triển khai . Đường cơ sở thứ tư là tập hợp
đầy đủ các tạo phẩm mới được hiển thị trong Hình 2.2. Chúng ta xem lại khái niệm đường cơ
sở trong Chương 5 và 16.
42 Phần A Khái niệm kỹ thuật phần mềm
2.3 Bài học từ nghiên cứu điển hình nhỏ ở Winburg
Nghiên cứu trường hợp nhỏ của Winburg mô tả quá trình phát triển một sản phẩm phần mềm gặp trục trặc vì
một số nguyên nhân không liên quan, chẳng hạn như chiến lược triển khai kém (sử dụng số có độ chính xác
kép không cần thiết) và quyết định sử dụng thuật toán quá chậm.
Cuối cùng, dự án đã thành công. Tuy nhiên, câu hỏi hiển nhiên là: Việc phát triển phần mềm có thực sự
hỗn loạn trong thực tế không? Trên thực tế, nghiên cứu trường hợp nhỏ ít gây tổn thương hơn nhiều so
với nhiều dự án phần mềm, nếu không muốn nói là phần lớn. Trong nghiên cứu điển hình nhỏ ở Winburg, chỉ
có hai phiên bản mới của phần mềm do lỗi (sử dụng số có độ chính xác kép không phù hợp; sử dụng thuật
toán không đáp ứng được yêu cầu về thời gian phản hồi) và chỉ có một phiên bản mới vì về sự thay đổi do
khách hàng thực hiện (nhu cầu tăng độ chính xác).
Tại sao cần có nhiều thay đổi đối với một sản phẩm phần mềm? Đầu tiên, như đã nêu trước đây, các
chuyên gia phần mềm cũng là con người và do đó sẽ mắc sai lầm. Thứ hai, sản phẩm phần mềm là mô hình
của thế giới thực và thế giới thực luôn thay đổi. Vấn đề này sẽ được thảo luận chi tiết hơn ở Phần 2.4.
Nghiên cứu nhỏ C
2.4 Nghiên cứu tình huống nhỏ về máy kéo Teal
Teal Tractors, Inc., bán máy kéo ở hầu hết các vùng của Hoa Kỳ. Công ty đã yêu cầu bộ phận phần
mềm của mình phát triển một sản phẩm mới có thể xử lý tất cả các khía cạnh kinh doanh của mình.
Ví dụ: sản phẩm phải có khả năng xử lý doanh số bán hàng, hàng tồn kho và hoa hồng trả cho nhân
viên bán hàng, cũng như cung cấp tất cả các chức năng kế toán cần thiết. Trong khi sản phẩm phần
mềm này đang được triển khai, Teal Tractors mua một công ty máy kéo của Canada. Ban quản lý của
Teal Tractors quyết định rằng, để tiết kiệm tiền, các hoạt động ở Canada phải được tích hợp vào
các hoạt động ở Hoa Kỳ. Điều đó có nghĩa là phần mềm phải được thay đổi trước khi hoàn thiện:
1. Nó phải được sửa đổi để xử lý các khu vực bán hàng bổ sung.
2. Nó phải được mở rộng để giải quyết những khía cạnh kinh doanh được xử lý khác nhau.
ently ở Canada, chẳng hạn như thuế.
3. Nó phải được mở rộng để xử lý hai loại tiền tệ khác nhau, đô la Mỹ và Canada

USD.
Teal Tractors là một công ty đang phát triển nhanh chóng với triển vọng tuyệt vời trong tương
lai. Việc tiếp quản công ty máy kéo Canada là một diễn biến tích cực, có thể mang lại lợi nhuận
thậm chí còn lớn hơn trong những năm tới. Tuy nhiên, từ quan điểm của bộ phận phần mềm, việc mua
lại công ty Canada có thể là một thảm họa. Trừ khi các yêu cầu, phân tích và thiết kế đã được
thực hiện nhằm mục đích kết hợp các phần mở rộng có thể có trong tương lai, công việc liên quan
đến việc bổ sung các khu vực bán hàng ở Canada có thể tuyệt vời đến mức có thể hiệu quả hơn nếu
loại bỏ mọi thứ đã thực hiện cho đến nay và bắt đầu lại từ đầu. Lý do là việc thay đổi sản phẩm
ở giai đoạn này cũng tương tự như việc cố gắng sửa chữa sản phẩm phần mềm ở giai đoạn cuối của
vòng đời của nó (xem Hình 1.6). Mở rộng phần mềm sang
việc xử lý các khía cạnh cụ thể đối với thị trường Canada cũng như đồng tiền Canada có thể khó
khăn như nhau.
Ngay cả khi phần mềm đã được tính toán kỹ lưỡng và thiết kế ban đầu thực sự có thể mở rộng,
thì thiết kế của sản phẩm được chắp vá lại với nhau không thể gắn kết như lẽ ra nếu nó được
phát triển ngay từ đầu để phục vụ cho cả Hoa Kỳ. Các bang và Canada. Điều này có thể có tác
động nghiêm trọng đến việc bảo trì trong tương lai.
Bộ phận phần mềm của Teal Tractors là nạn nhân của vấn đề mục tiêu di chuyển .
Nghĩa là, trong khi phần mềm đang được phát triển thì các yêu cầu sẽ thay đổi. Không có vấn đề
gì nếu lý do thay đổi là cực kỳ đáng giá. Thực tế là việc tiếp quản công ty Canada có thể gây
bất lợi cho chất lượng của phần mềm đang được phát triển.
Trong một số trường hợp, lý do khiến mục tiêu di chuyển ít lành tính hơn. Đôi khi một nhà quản lý
cấp cao đầy quyền lực trong một tổ chức liên tục thay đổi suy nghĩ của mình về chức năng của một sản
phẩm phần mềm đang được phát triển. Trong các trường hợp khác, có sự thay đổi tính năng , sự bổ Một
sung nhỏ, gần như tầm thường vào các yêu cầu. Nhưng bất kể lý do là gì, những thay đổi thường xuyên,
dù chúng có vẻ nhỏ đến đâu, đều có hại cho sức khỏe của sản phẩm phần mềm. Điều quan trọng là sản
phẩm phần mềm phải được thiết kế như một tập hợp các thành phần độc lập nhất có thể, sao cho sự thay
đổi đối với một phần của phần mềm không gây ra lỗi ở phần mã dường như không liên quan, do đó- gọi là
lỗi hồi quy . Khi nhiều thay đổi được thực hiện, hiệu quả là tạo ra sự phụ thuộc trong mã. Cuối cùng,
có quá nhiều sự phụ thuộc đến nỗi hầu như bất kỳ thay đổi nào cũng gây ra một hoặc nhiều lỗi hồi quy.
Khi đó, điều duy nhất có thể làm là thiết kế lại toàn bộ sản phẩm phần mềm và triển khai lại nó.
Thật không may, không có giải pháp nào được biết đến cho vấn đề mục tiêu chuyển động. Liên quan
đến những thay đổi tích cực về yêu cầu, các công ty đang phát triển sẽ luôn thay đổi và những thay
đổi này phải được phản ánh trong các sản phẩm phần mềm quan trọng của công ty.
Đối với những thay đổi tiêu cực, nếu cá nhân yêu cầu những thay đổi đó có đủ ảnh hưởng thì không thể
làm gì để ngăn cản những thay đổi đó được thực hiện, gây phương hại đến khả năng bảo trì thêm của sản
phẩm phần mềm.
2.5 Lặp lại và tăng dần
Do hậu quả của cả vấn đề mục tiêu di động và nhu cầu sửa chữa những lỗi không thể tránh khỏi trong
quá trình phát triển một sản phẩm phần mềm, vòng đời của các sản phẩm phần mềm thực tế giống với mô
hình cây tiến hóa của Hình 2.2 hoặc mô hình thác nước của Hình 2.3 chứ không phải là chuỗi lý tưởng
hóa của Hình, 2.1. Một hệ quả của thực tế này là việc nói về (chẳng hạn) “ giai đoạn phân tích” chẳng
có ý nghĩa gì nhiều . Thay vào đó, các hoạt động của giai đoạn phân tích được trải đều trong suốt
vòng đời. Tương tự, Hình 2.2 cho thấy bốn phiên bản triển khai khác nhau, một trong số đó (Việc triển
khai chưa bao giờ được hoàn thành do vấn đề về mục tiêu di chuyển. 2)
Xem xét các phiên bản kế tiếp của một tạo phẩm, ví dụ: tài liệu đặc tả hoặc mô-đun mã. Từ quan
điểm này, quá trình cơ bản là lặp đi lặp lại. Nghĩa là, chúng tôi tạo ra phiên bản đầu tiên của hiện
vật, sau đó chúng tôi sửa lại nó và tạo ra phiên bản thứ hai, v.v. Của chúng tôi
mục đích là mỗi phiên bản gần với mục tiêu của chúng tôi hơn so với phiên bản trước đó và cuối
cùng chúng tôi xây dựng một phiên bản đạt yêu cầu. Lặp lại là một khía cạnh nội tại của công
nghệ phần mềm và các mô hình vòng đời lặp đã được sử dụng trong hơn 30 năm [Larman và Basili, 2003].
Ví dụ, mô hình thác nước được đưa ra lần đầu tiên vào năm 1970, có tính lặp lại (nhưng không
tăng dần).
Khía cạnh thứ hai của việc phát triển phần mềm trong thế giới thực là sự hạn chế của Định
luật Miller. Năm
. 1956, George Miller, giáo sư tâm lý học, đã chỉ ra rằng, tại bất kỳ thời điểm
nào, con người chúng ta chỉ có khả năng tập trung vào khoảng bảy khối (đơn vị). thông tin)
[Miller, 1956]. Tuy nhiên, một tạo phẩm phần mềm điển hình có nhiều hơn bảy phần. Ví dụ: một tạo
phẩm mã có thể có nhiều hơn bảy biến và một tài liệu yêu cầu có thể có nhiều hơn bảy biến. Một
cách mà con người chúng ta xử lý sự hạn chế về lượng thông tin mà chúng ta có thể xử lý bất cứ
lúc nào là sử dụng sàng lọc từng bước . Nghĩa là, chúng ta tập trung vào những khía cạnh hiện
tại là quan trọng nhất và hoãn lại những khía cạnh hiện ít quan trọng hơn.
Nói cách khác, mọi khía cạnh cuối cùng đều được xử lý nhưng theo thứ tự quan trọng hiện tại.
Điều này có nghĩa là chúng tôi bắt đầu bằng cách xây dựng một tạo phẩm chỉ giải quyết được một
phần nhỏ những gì chúng tôi đang cố gắng đạt được. Sau đó, chúng tôi xem xét các khía cạnh khác
của vấn đề và thêm các phần mới thu được vào tạo phẩm hiện có. Ví dụ: chúng ta có thể xây dựng
một tài liệu yêu cầu bằng cách xem xét bảy yêu cầu mà chúng ta cho là quan trọng nhất. Sau đó,
chúng ta sẽ xem xét bảy yêu cầu quan trọng nhất tiếp theo, v.v. Đây là một quá trình tăng dần.
Sự gia tăng cũng là một khía cạnh nội tại của công nghệ phần mềm; phát triển phần mềm gia tăng
đã hơn 45 tuổi [Larman và Basili, 2003].
Trong thực tế, phép lặp và phép tăng được sử dụng kết hợp với nhau. Nghĩa là, một tạo phẩm
được xây dựng từng phần một (gia tăng) và mỗi gia tăng trải qua nhiều phiên bản (lặp lại). Những
ý tưởng này được minh họa trong chu trình Hình 2.2 cho nghiên cứu điển ,đại diện cho cuộc sống
hình nhỏ ở Winburg (Phần 2.2 và 2.3). Như thể hiện trong hình đó, không có một “giai đoạn yêu
cầu” nào như vậy. Thay vào đó, các yêu cầu của khách hàng được trích xuất và phân tích hai lần,
tạo ra các yêu cầu ban đầu (Yêu cầu (Yêu cầu thay vì bốn phần riêng biệt 1
) và được sửa đổi
trong đó mã được tạo và sau đó 4 ). Tương tự, không có một “giai đoạn thực hiện” duy nhất nào cả, nhưng
được sửa đổi. Phản ánh các khái niệm cơ bản bên dưới-
Những ý tưởng này được khái quát hóa trong ,
Hình 2.4 trong mô hình vòng đời lặp đi lặp lại và tăng dần [Jacobson, Booch, và Rumbaugh, 1999].
Hình này cho thấy sự phát triển của một sản phẩm phần mềm theo bốn giai đoạn, được gọi là Phần
tăng trưởng A, Phần tăng trưởng B, Phần tăng trưởng C và Phần tăng trưởng D. Trục hoành là thời
gian và trục tung là số giờ công (một giờ-người là số lượng công việc mà một người có thể làm
trong 1 giờ), do đó phần tô đậm dưới mỗi đường cong là tổng nỗ lực cho mức tăng đó.
Điều quan trọng cần đánh giá cao là Hình 2.4 chỉ mô tả một cách khả thi mà một sản phẩm phần
mềm có thể được chia thành các phần tăng dần. Một sản phẩm phần mềm khác có thể được xây dựng
chỉ với 2 bước, trong khi sản phẩm thứ ba có thể yêu cầu 14. Hơn nữa, hình này không nhằm mục
đích thể hiện chính xác cách thức phát triển một sản phẩm phần mềm. Thay vào đó, nó cho thấy sự
nhấn mạnh thay đổi như thế nào từ lần lặp này sang lần lặp khác.
Các giai đoạn tuần tự của Hình 2.1 là các cấu trúc nhân tạo. Thay vào đó, như được phản ánh
,
rõ ràng trong Hình 2.4, chúng ta phải thừa nhận rằng các quy trình công việc (hoạt động) khác
nhau được thực hiện trong toàn bộ vòng đời. Có năm quy trình công việc cốt ,lõi : quy trình yêu
cầu , quy trình phân tích , quy trình thiết kế , quy trình thực hiện và quy trình công việc ,kiểm
tra , và, như đã nêu trong câu trước, tất cả năm quy trình đều được thực hiện trong suốt cuộc đời.
HÌNH 2.4 Việc xây dựng một sản phẩm phần mềm theo bốn giai đoạn.
Tăng A Tăng B Tăng C Tăng D
Yêu cầu
quy trình làm việc
Phân tích
ưi
-iờờ gg
n
Thiết kế
Thực hiện
Bài kiểm tra
Thời gian
chu kỳ của một sản phẩm phần mềm. Tuy nhiên, có những lúc một quy trình công việc chiếm ưu thế hơn
bốn quy trình còn lại.
Ví dụ, khi bắt đầu vòng đời, các nhà phát triển phần mềm rút ra một bộ yêu cầu ban đầu. Nói cách
khác, khi bắt đầu vòng đời lặp lại và tăng dần, quy trình công việc yêu cầu chiếm ưu thế. Các tạo
phẩm yêu cầu này được mở rộng và sửa đổi trong suốt phần còn lại của vòng đời. Trong thời gian đó,
bốn quy trình công việc còn lại (phân tích, thiết kế, triển khai và kiểm tra) chiếm ưu thế. Nói
cách khác, quy trình công việc yêu cầu là quy trình công việc chính ở đầu vòng đời, nhưng tầm quan
trọng tương đối của nó sẽ giảm dần sau đó. Ngược lại, quy trình triển khai và kiểm thử chiếm nhiều
thời gian của các thành viên trong nhóm phát triển phần mềm ở cuối vòng đời hơn so với lúc ban đầu.
Các hoạt động lập kế hoạch và tài liệu được thực hiện trong suốt vòng đời lặp đi lặp lại và
tăng dần. Hơn nữa, kiểm thử là một hoạt động chính trong mỗi lần lặp và đặc biệt là vào cuối mỗi
lần lặp. Ngoài ra, toàn bộ phần mềm đều được kiểm tra kỹ lưỡng sau khi hoàn thành; tại thời điểm
đó, việc kiểm tra và sau đó sửa đổi việc triển khai dựa trên kết quả của các thử nghiệm khác nhau
hầu như là hoạt động duy nhất của nhóm phần mềm. Điều này được phản ánh trong quy trình thử nghiệm
của Hình 2.4.
Hình 2.4 cho thấy bốn mức tăng. Hãy xem xét Phần tăng A, được mô tả bằng cột bên trái. Khi bắt
đầu bước tăng này, các thành viên trong nhóm yêu cầu sẽ xác định các yêu cầu của khách hàng. Khi
hầu hết các yêu cầu đã được xác định, phiên bản đầu tiên của phần phân tích có thể được bắt đầu.
Khi quá trình phân tích đã đạt được tiến bộ đầy đủ, phiên bản đầu tiên của thiết kế có thể được bắt
đầu. Thậm chí một số mã hóa thường được thực hiện trong lần tăng đầu tiên này, có lẽ dưới dạng
nguyên mẫu chứng minh khái niệm để kiểm tra tính khả thi của một phần sản phẩm phần mềm được đề
xuất. Cuối cùng, như đã đề cập trước đó,
HÌNH 2.5 Ba Tăng B

lần lặp
Lặp lại B.1 Lặp lại B.2 Lặp lại B.3
của Phần tăng
của mô hình
Yêu cầu
vòng đời lặp và quy trình làm việc
tăng dần trong

Hình 2.4 . Phân tích
ưigg
n
Thiết kế
-iờờ
Thực hiện
Bài kiểm tra
Thời gian
Đường cơ sở
các hoạt động lập kế hoạch, kiểm tra và ghi tài liệu bắt đầu từ Ngày đầu tiên và tiếp tục từ đó trở
đi cho đến khi sản phẩm phần mềm cuối cùng được giao cho khách hàng.
Tương tự, trọng tâm chính trong Phần tăng trưởng B là vào các yêu cầu và quy trình công việc phân
tích, sau đó là quy trình công việc thiết kế. Sự nhấn mạnh trong phần tăng C
Đầu tiên là quy trình thiết kế, sau đó là quy trình triển khai và quy trình kiểm tra.
Cuối cùng, trong Phần tăng D, quy trình triển khai và quy trình kiểm tra chiếm ưu thế.
,
Như được phản ánh trong Hình 1.4, khoảng một phần năm tổng nỗ lực được dành cho các yêu cầu và
quy trình công việc phân tích (cùng nhau), một phần năm khác cho quy trình công việc thiết kế và
khoảng ba phần năm cho việc triển khai. quy trình làm việc. Tổng kích thước tương đối của các vùng
tô bóng trong Hình 2.4 phản ánh những giá trị này.
Có sự lặp lại trong mỗi lần tăng của Hình 2.4. Điều này được thể hiện trong Hình 2.5 mô tả ba ,
lần lặp trong Phần tăng trưởng B. ( Hình 2.5 là chế độ xem phóng to của cột thứ hai của Hình 2.4 .)
Như được hiển thị trong Hình 2.5, dòng chảy nhưng lại ở các , mỗi lần lặp lại bao gồm tất cả năm công việc-
tỷ lệ khác nhau.
Một lần nữa, cần phải nhấn mạnh rằng Hình 2.5 không nhằm mục đích chỉ ra rằng mỗi lần tăng bao
gồm chính xác ba lần lặp. Số lần lặp thay đổi theo từng mức tăng. Mục đích của Hình 2.5 là để hiển
thị việc lặp lại trong mỗi lần lặp và nhắc lại rằng tất cả năm quy trình công việc (yêu cầu, phân
tích, thiết kế, triển khai và thử nghiệm, cùng với việc lập kế hoạch và tài liệu) đều được thực hiện
trong hầu hết mỗi lần lặp, mặc dù ở các mức độ khác nhau. tỷ lệ mỗi lần.
Như đã giải thích trước đây, Hình 2.4 phản ánh sự gia tăng nội tại trong quá trình phát triển
của mọi sản phẩm phần mềm. Hình 2.5 hiển thị rõ ràng phép lặp làm cơ sở cho việc tăng dần. Cụ thể,
Hình 2.5 mô tả ba bước lặp liên tiếp, trái ngược với một bước tăng lớn. Chi tiết hơn, Lặp lại B.1
bao gồm các yêu cầu,

phân tích, thiết kế, triển khai và kiểm tra các quy trình công việc, được biểu thị bằng hình chữ nhật nét đứt
ngoài cùng bên trái với các góc tròn. Việc lặp lại tiếp tục cho đến khi các thành phần của mỗi quy trình trong
năm quy trình công việc đều đạt yêu cầu.
Tiếp theo, tất cả năm bộ tạo tác được lặp lại trong bước lặp B.2. Lần lặp thứ hai này có
bản chất tương tự như lần đầu tiên. Nghĩa là, các tạo phẩm yêu cầu được cải thiện, từ đó kích
hoạt các cải tiến đối với các tạo phẩm phân tích, v.v., như được phản ánh trong lần lặp thứ hai
, tương tự cho lần lặp thứ ba.
của Hình 2.5 và
Quá trình lặp lại và tăng dần bắt đầu từ đầu Phần tăng trưởng A và tiếp tục cho đến hết Phần
tăng trưởng D. Sau đó, sản phẩm phần mềm hoàn chỉnh sẽ được cài đặt trên máy tính của khách
hàng.
Nghiên cứu nhỏ C

2.6
Xem lại nghiên cứu điển hình nhỏ về Winburg
Hình 2.6 cho thấy mô hình cây tiến hóa của nghiên cứu điển hình nhỏ ở Winburg ( Hình
2.2 ) được xếp chồng lên mô hình lặp và tăng dần (quy trình kiểm tra không được hiển thị
vì mô hình cây tiến hóa giả định thử nghiệm liên tục, được giải thích trong Phần 1.7) .
Hình 2.6 làm sáng tỏ thêm bản chất của việc tăng dần:
• Phần tăng A tương ứng với Tập 1, Phần tăng B tương ứng với Tập 2,
và như thế.
HÌNH 2.6 Mô hình vòng đời cây tiến hóa cho nghiên cứu điển hình nhỏ ở Winburg ( Hình 2.2 ) được xếp chồng
lên mô hình vòng đời lặp đi lặp lại và tăng dần.
Phát triển
BẢO TRÌ
Tăng A Tăng B Tăng C Tăng D
Yêu cầu Yêu cầu1

Yêu cầu4
Phân tích
Phân tích1 Phân tích4
gg
ưi
-iờờ n
Thiết kế
Thiết kế1 Thiết kế3 Thiết kế4
Thực hiện Thực hiện1 Thực hiện2 Thực hiện3 Thực hiện4
Tập 1 Tập 2 Tập 3 Tập 4

Thời gian
• Từ quan điểm của mô hình lặp và tăng dần, hai trong số các phần tăng thêm không bao gồm
tất cả bốn quy trình công việc. Chi tiết hơn, Phần tăng B (Phần 2) chỉ bao gồm quy trình
công việc triển khai và Phần tăng C (Phần 3) chỉ bao gồm quy trình công việc thiết kế và
quy trình công việc triển khai. Mô hình lặp và tăng dần không yêu cầu mọi quy trình công
việc phải được thực hiện trong mỗi lần tăng. • Hơn nữa, trong Hình 2.4, hầu hết quy trình
công việc yêu cầu
được thực hiện ở Phần tăng trưởng A và Phần tăng trưởng B, trong khi ở Hình 2.6, nó được
thực hiện ở Phần tăng trưởng A và Phần tăng trưởng D. Ngoài ra, trong Hình 2.4, hầu hết
phân tích được thực hiện trong Phần tăng trưởng B, trong khi ở Hình 2.6, quy trình phân
tích được thực hiện ở Phần tăng trưởng A và Phần tăng trưởng D. Điều này cho thấy rằng cả
Hình 2.4 và Hình 2.6 đều không thể hiện cách mọi sản phẩm phần mềm được xây dựng. Thay
vào đó, mỗi hình cho thấy cách xây dựng một sản phẩm phần mềm cụ thể, làm nổi bật sự lặp
lại và tăng trưởng cơ bản. • Quy mô nhỏ và sự chấm dứt đột ngột của quy trình triển khai
trong Phần tăng B (Tập 2) của Hình
2.6 cho thấy việc Triển khai chưa được hoàn thành. Phần màu xám phản ánh một phần của quy
trình triển khai chưa được thực hiện. 2
• Ba mũi tên nét đứt của mô hình cây tiến hóa cho thấy mỗi mức tăng sẽ duy trì mức tăng
trước đó. Trong ví dụ này, mức tăng thứ hai và thứ ba là các trường hợp bảo trì khắc
phục. Nghĩa là, mỗi lần tăng sẽ sửa các lỗi ở lần tăng trước. Như đã giải thích trước đó,
Phần tăng B (Tập 2) điều chỉnh quy trình triển khai bằng cách thay thế các biến có độ
chính xác kép bằng các biến có độ chính xác đơn thông thường.
Phần tăng C (Tập 3) điều chỉnh quy trình thiết kế bằng cách sử dụng thuật toán nhận dạng
hình ảnh nhanh hơn, từ đó cho phép đáp ứng yêu cầu về thời gian phản hồi. Sau đó, những
thay đổi tương ứng phải được thực hiện đối với quy trình thực hiện công việc. Cuối cùng,
trong Phần tăng D (Tập 4), các yêu cầu được thay đổi để quy định độ chính xác tổng thể
được cải thiện, một ví dụ về bảo trì hoàn hảo. Sau đó, những thay đổi tương ứng sẽ được
thực hiện đối với quy trình công việc phân tích, quy trình công việc thiết kế và quy
trình công việc triển khai.
2.7 Rủi ro và các khía cạnh khác của việc

lặp lại và tăng dần
Một cách khác để xem xét sự lặp lại và tăng dần là toàn bộ dự án được chia thành các dự án nhỏ hơn
(hoặc các phần tăng dần). Mỗi dự án nhỏ mở rộng các tạo phẩm yêu cầu, phân tích, thiết kế, triển
khai và thử nghiệm. Cuối cùng, tập hợp các tạo phẩm tạo thành sản phẩm phần mềm hoàn chỉnh.
Trên thực tế, mỗi dự án nhỏ không chỉ bao gồm việc mở rộng các tạo phẩm. Điều cần thiết là phải
kiểm tra xem mỗi tạo phẩm có chính xác hay không (quy trình kiểm tra) và thực hiện bất kỳ thay đổi
cần thiết nào đối với các tạo phẩm có liên quan. Quá trình kiểm tra và sửa đổi, sau đó kiểm tra lại
và sửa đổi, v.v., rõ ràng là có bản chất lặp đi lặp lại. Nó tiếp tục cho đến khi các thành viên của
nhóm phát triển hài lòng với tất cả các thành phần của dự án nhỏ (hoặc phần tăng thêm)
hiện tại. Khi điều đó xảy ra, họ tiến tới bước tăng tiếp theo.
So sánh Hình 2.3 (mô hình thác nước) với Hình 2.5 (chế độ xem các lần lặp trong Phần
tăng trưởng B) cho thấy rằng mỗi lần lặp có thể được xem như một mô hình thác nước nhỏ
nhưng hoàn chỉnh. Nghĩa là, trong mỗi lần lặp lại, các thành viên của nhóm phát triển sẽ
trải qua các giai đoạn yêu cầu, phân tích, thiết kế và triển khai cổ điển trên một phần
cụ thể của sản phẩm phần mềm. Từ quan điểm này, mô hình lặp và tăng dần của Hình 2.4 và
2.5 có thể được xem như một chuỗi các mô hình thác nước liên tiếp.
Mô hình lặp và tăng dần có nhiều điểm mạnh:
1. Có nhiều cơ hội để kiểm tra xem sản phẩm phần mềm có đúng không.
Mỗi lần lặp lại đều kết hợp quy trình kiểm thử, vì vậy mỗi lần lặp lại là một cơ hội
khác để kiểm tra tất cả các tạo phẩm đã được phát triển cho đến thời điểm này. Các
lỗi được phát hiện và sửa chữa càng muộn thì chi phí càng cao, như trong Hình 1.6.
Không giống như mô hình thác nước cổ điển, mỗi lần lặp lại của mô hình lặp và tăng
dần mang đến nhiều cơ hội hơn để tìm ra lỗi và sửa chúng, từ đó tiết kiệm tiền.
2. Sự vững chắc của kiến trúc cơ bản có thể được xác định tương đối sớm trong vòng đời.
Kiến trúc của một sản phẩm phần mềm bao gồm các tạo phẩm thành phần khác nhau và cách
chúng khớp với nhau. Một sự tương tự là kiến trúc của một cathe-dral, có thể được mô
tả theo phong cách La Mã, Gothic hoặc Baroque, cùng với những khả năng khác. Tương
tự, kiến trúc của một sản phẩm phần mềm có thể được mô tả là hướng đối tượng ( Chương
7 ), các đường ống và bộ lọc (các thành phần UNIX hoặc Linux) hoặc máy khách-máy chủ
(với một máy chủ trung tâm cung cấp lưu trữ tệp cho mạng máy tính khách). Kiến trúc
của một sản phẩm phần mềm được phát triển bằng mô hình lặp và tăng dần phải có đặc
tính có thể được mở rộng liên tục (và, nếu cần, có thể dễ dàng thay đổi) để kết hợp
với phần tăng dần tiếp theo. Có thể xử lý các phần mở rộng và thay đổi như vậy mà
không bị hỏng được gọi là tính mạnh mẽ Tính mạnh mẽ là một phẩm chất quan trọng trong .
quá trình phát triển một sản phẩm phần mềm; nó rất quan trọng trong quá trình bảo trì
sau giao hàng. Vì vậy, nếu một sản phẩm phần mềm tồn tại qua quá trình bảo trì sau
giao hàng 12, 15 hoặc hơn thông thường thì kiến trúc cơ bản phải mạnh mẽ. Khi sử dụng
mô hình lặp và tăng dần, sẽ sớm thấy rõ liệu kiến trúc đó có mạnh mẽ hay không. Nếu,
trong quá trình kết hợp (chẳng hạn) bước tăng thứ ba, rõ ràng là phần mềm được phát
triển cho đến nay phải được tổ chức lại một cách quyết liệt và triển khai lại các phần
lớn, thì rõ ràng là kiến trúc đó không đủ mạnh mẽ. Khách hàng phải quyết định có nên
từ bỏ dự án hay bắt đầu lại từ đầu. Một khả năng khác là thiết kế lại kiến trúc để
mạnh mẽ hơn, sau đó tái sử dụng càng nhiều tạo phẩm hiện tại càng tốt trước khi tiếp
tục giai đoạn tăng trưởng tiếp theo. Một lý do khác tại sao một kiến trúc mạnh mẽ lại
quan trọng đến vậy là vấn đề mục tiêu chuyển động (Phần 2.4). Gần như chắc chắn rằng
các yêu cầu của khách hàng sẽ thay đổi, do sự phát triển trong tổ chức của khách hàng
hoặc do khách hàng liên tục thay đổi suy nghĩ của mình về những gì phần mềm mục tiêu
phải làm. Kiến trúc càng mạnh mẽ thì phần mềm càng có khả năng thay đổi linh hoạt hơn.
Không thể thiết kế một kiến trúc có thể đương đầu với quá nhiều thay đổi mạnh mẽ. Tuy
nhiên, nếu những thay đổi cần thiết có phạm vi hợp lý thì một kiến trúc mạnh mẽ sẽ có
khả năng kết hợp những thay đổi đó mà không cần phải cơ cấu lại mạnh mẽ.
3. Mô hình lặp lại và gia tăng cho phép chúng tôi sớm giảm thiểu rủi ro. Rủi ro luôn liên quan đến
việc phát triển và bảo trì phần mềm. Ví dụ, trong nghiên cứu điển hình nhỏ ở Winburg, thuật toán
nhận dạng hình ảnh ban đầu không đủ nhanh; luôn có nguy cơ rằng một sản phẩm phần mềm đã hoàn
thiện sẽ không đáp ứng được những hạn chế về thời gian của nó. Việc phát triển dần dần một sản
phẩm phần mềm cho phép chúng tôi giảm thiểu những rủi ro như vậy sớm trong vòng đời.
Ví dụ: giả sử một mạng cục bộ (LAN) mới đang được phát triển và có lo ngại rằng phần cứng mạng
hiện tại không đủ cho sản phẩm phần mềm mới. Sau đó, một hoặc hai lần lặp đầu tiên hướng tới
việc xây dựng các phần của phần mềm có giao diện với phần cứng mạng. Nếu hóa ra, trái ngược với
lo ngại của các nhà phát triển, mạng có đủ khả năng cần thiết thì các nhà phát triển có thể tiến
hành dự án với niềm tin rằng rủi ro này đã được giảm thiểu. Mặt khác, nếu mạng thực sự không
thể đáp ứng được lưu lượng bổ sung mà mạng LAN mới tạo ra thì điều này sẽ được thông báo cho
khách hàng sớm trong vòng đời, khi chỉ một phần nhỏ ngân sách được chi tiêu. Giờ đây, khách hàng
có thể quyết định có nên hủy dự án hay không, mở rộng khả năng của mạng hiện tại, mua mạng mới
và mạnh hơn hoặc thực hiện một số hành động khác.
4. Chúng tôi luôn có phiên bản phần mềm hoạt động được. Giả sử một sản phẩm phần mềm được phát
triển sử dụng mô hình vòng đời cổ điển trong Hình 2.1. Chỉ đến cuối dự án mới có phiên bản hoạt
động của sản phẩm phần mềm. Ngược lại, khi sử dụng mô hình vòng đời lặp và tăng dần, ở cuối mỗi
lần lặp, sẽ có một phiên bản hoạt động của một phần của sản phẩm phần mềm mục tiêu tổng thể.
Khách hàng và những người dùng dự định có thể thử nghiệm phiên bản đó và xác định những thay
đổi nào là cần thiết để đảm bảo rằng việc triển khai hoàn chỉnh trong tương lai đáp ứng được
nhu cầu của họ. Những thay đổi này có thể được thực hiện cho lần tăng tiếp theo, sau đó khách
hàng và người dùng có thể xác định xem có cần thay đổi thêm hay không. Một biến thể của điều
này là cung cấp một phần phiên bản của sản phẩm phần mềm, không chỉ để thử nghiệm mà còn để tạo
thuận lợi cho việc giới thiệu sản phẩm phần mềm mới trong tổ chức khách hàng. Sự thay đổi hầu
như luôn được coi là một mối đe dọa. Thông thường, người dùng lo sợ rằng việc giới thiệu một
sản phẩm phần mềm mới tại nơi làm việc sẽ khiến họ mất việc vào tay máy tính.
Tuy nhiên, việc giới thiệu dần dần một sản phẩm phần mềm có thể mang lại hai lợi ích. Đầu tiên,
nỗi sợ hãi dễ hiểu về việc bị máy tính thay thế đã giảm bớt. Thứ hai, nhìn chung sẽ dễ dàng hơn
để tìm hiểu chức năng của một sản phẩm phần mềm phức tạp nếu chức năng đó được giới thiệu từng
bước trong khoảng thời gian vài tháng chứ không phải toàn bộ.
5. Có bằng chứng thực nghiệm cho thấy vòng đời lặp đi lặp lại và tăng dần có hiệu quả. Biểu đồ tròn
của Hình 1.1 thể hiện kết quả báo cáo của Standish Group về các dự án hoàn thành năm 2006
[Rubenstein, 2007]. Trên thực tế, báo cáo này (còn gọi là Báo cáo CHAOS—
xem Just in Case You Want to Know Box 2.2) được xuất bản 2 năm một lần. Hình 2.7 cho thấy kết
quả từ năm 1994 đến năm 2006. Tỷ lệ sản phẩm thành công tăng đều đặn từ 16% năm 1994 lên 34%
năm 2002, nhưng sau đó giảm xuống còn 29% vào năm 2004. Trong cả hai năm 2002 [Softwaremag.com,
2004] và 2004 [Hayes, 2004] báo cáo, một trong những yếu tố gắn liền với sự thành công của dự án
là việc sử dụng quy trình lặp đi lặp lại. (Các lý do được đưa ra dẫn đến sự sụt giảm tỷ lệ dự
án thành công trong năm 2004 bao gồm: nhiều dự án lớn hơn năm 2002, việc sử dụng mô hình thác
nước, thiếu sự tham gia của người dùng và thiếu sự hỗ trợ từ các nhà điều hành cấp cao [Hayes,
2004].) , tỷ lệ dự án thành công lại tăng lên trong nghiên cứu năm 2006 lên 35%. Chủ tịch của
Standish Group, Jim Johnson, cho rằng sự gia tăng này là do ba yếu tố: quản lý dự án tốt hơn,
cơ sở hạ tầng Web mới nổi và (một lần nữa) sự phát triển lặp đi lặp lại [Rubenstein, 2007].
Chỉ trong trường hợp bạn muốn biết Hộp 2.2
Thuật ngữ CHAOS là một từ viết tắt. Vì một số lý do không rõ, Nhóm Standish giữ bí
mật từ viết tắt. Họ tuyên bố [Standish, 2003]:
Chỉ một số ít người ở The Standish Group, và bất kỳ ai trong số 360 người đã nhận và giữ lại những
chiếc áo phông chúng tôi phát sau khi họ hoàn thành cuộc khảo sát đầu tiên vào năm 1994, biết các chữ
cái CHAOS tượng trưng cho điều gì.
HÌNH 2.7
Kết quả của
Nhóm độc lập 2006 35% 46% 19%

Báo cáo CHAOS
từ năm 1994 đến
2006. 2004 29% 53% 18%
2002 34% 51% 15%
2000 28% 49% 23%
1998 26% 46% 28%
1996 27% 33% 40%
1994 16% 53% 31%
0% 20% 40% 60% 80% 100%
Hoàn thành đúng thời hạn và trong ngân sách
Trễ, vượt ngân sách hoặc thiếu tính năng

Đã hủy trước khi hoàn thành
2.8 Quản lý việc lặp lại và tăng dần

Thoạt nhìn, mô hình lặp và tăng dần của Hình 2.4 và 2.5 trông hoàn toàn hỗn loạn. Thay
vì tiến trình có trật tự từ yêu cầu đến triển khai mô hình thác nước ( Hình 2.3 ), có
vẻ như các nhà phát triển làm bất cứ điều gì họ thích, có thể là viết mã vào buổi sáng,
một hoặc hai giờ thiết kế sau bữa trưa và sau đó là nửa giờ chỉ định trước khi về nhà.
Đó không phải là tình huống. Ngược lại, mô hình lặp và tăng dần cũng được tổ chức
giống như mô hình thác nước, bởi vì như đã chỉ ra trước đó, việc phát triển một sản
phẩm phần mềm bằng mô hình lặp và tăng dần không gì khác hơn là phát triển một loạt
các sản phẩm phần mềm nhỏ hơn. , tất cả đều sử dụng mô hình thác nước.
Chi tiết hơn, như trong Hình 2.3, việc phát triển một sản phẩm phần mềm bằng mô hình thác
nước có nghĩa là thực hiện liên tục các giai đoạn yêu cầu, phân tích, thiết kế và triển khai
(theo thứ tự đó) trên toàn bộ sản phẩm phần mềm. Nếu gặp sự cố, thực hiện theo các vòng phản hồi
trong Hình 2.3 (mũi tên nét đứt); nghĩa là việc lặp lại (bảo trì) được thực hiện. Tuy nhiên, nếu
cùng một sản phẩm phần mềm được phát triển bằng mô hình lặp và tăng dần thì sản phẩm phần mềm
đó được coi là một tập hợp các phần tăng trưởng. Đối với mỗi bước tăng lần lượt, các giai đoạn
yêu cầu, phân tích, thiết kế và triển khai (theo thứ tự đó) được thực hiện lặp đi lặp lại trên
bước tăng đó cho đến khi rõ ràng là không cần lặp lại nữa. Nói cách khác, toàn bộ dự án được
chia thành một loạt các dự án nhỏ về thác nước. Trong mỗi dự án nhỏ, việc lặp lại được thực hiện
khi cần thiết, như trong Hình 2.5. Do đó, lý do mà đoạn trước nói rằng mô hình lặp và tăng dần
được tổ chức giống như mô hình thác nước là vì mô hình lặp và tăng dần là mô hình thác nước,
được áp dụng tuần tự.
2.9 Các mô hình vòng đời khác
Bây giờ chúng ta xem xét một số mô hình vòng đời khác, bao gồm mô hình xoắn ốc và mô hình đồng
bộ hóa và ổn định. Chúng ta bắt đầu với mô hình code-and-fi x khét tiếng.
2.9.1 Mô hình vòng đời mã hóa và sửa lỗi Thật không
may là có quá nhiều sản phẩm được phát triển bằng cách sử dụng cái có thể được gọi là mô hình
vòng đời mã hóa và sửa lỗi . Sản phẩm được triển khai mà không có yêu cầu hoặc thông số kỹ thuật
hoặc bất kỳ nỗ lực thiết kế nào. Thay vào đó, các nhà phát triển chỉ cần ghép mã lại với nhau và
làm lại nó nhiều lần nếu cần để làm hài lòng khách hàng. Cách tiếp cận này được thể hiện trong
Hình 2.8. , trong đó hiển thị rõ ràng sự thiếu vắng các yêu cầu, thông số kỹ thuật và thiết kế.
Mặc dù cách tiếp cận này có thể hoạt động tốt trên các bài tập lập trình ngắn dài 100 hoặc 200
dòng, nhưng mô hình code-and-fi x hoàn toàn không đạt yêu cầu đối với các sản phẩm có kích thước hợp lý.
Hình 1.6 cho thấy chi phí thay đổi một sản phẩm phần mềm là tương đối nhỏ nếu
HÌNH 2.8
Thực hiện các
Mã-và-
phiên bản đầu tiên
mô hình vòng
đời fi x.
Sửa đổi cho đến khi

khách hàng hài lòng
Bưu phẩm đã được giao
BẢO TRÌ
Phát triển
Sự nghỉ hưu
BẢO TRÌ
thay đổi được thực hiện trong các giai đoạn yêu cầu, phân tích hoặc thiết kế nhưng sẽ trở nên lớn đến
mức không thể chấp nhận được nếu các thay đổi được thực hiện sau khi sản phẩm đã được mã hóa hoặc tệ hơn
là nếu nó đã được chuyển giao và cài đặt trên máy tính của khách hàng. Do đó, chi phí của phương pháp mã
hóa và sửa chữa thực sự lớn hơn nhiều so với chi phí của một sản phẩm được xác định chính xác và được
hủy ký hiệu một cách tỉ mỉ. Ngoài ra, việc bảo trì một sản phẩm có thể cực kỳ khó khăn nếu không có tài
liệu đặc tả hoặc thiết kế và khả năng xảy ra lỗi hồi quy sẽ lớn hơn đáng kể. Thay vì cách tiếp cận mã
hóa và sửa lỗi, điều cần thiết là trước khi bắt đầu phát triển sản phẩm, một mô hình vòng đời thích hợp
phải được chọn.
Đáng tiếc là có quá nhiều dự án sử dụng mô hình code-and-fi x. Vấn đề đặc biệt nghiêm trọng ở những
tổ chức chỉ đo lường tiến độ dựa trên dòng mã, vì vậy các thành viên của nhóm phát triển phần mềm bị áp
lực phải tạo ra càng nhiều dòng mã càng tốt, bắt đầu từ Ngày đầu tiên của dự án. Mô hình code-and-fi x là
cách dễ nhất để phát triển phần mềm—và cho đến nay là cách tồi tệ nhất.
Một phiên bản đơn giản hóa của mô hình thác nước đã được trình bày ở Phần 2.2. Bây giờ chúng tôi đang
sider mô hình đó chi tiết hơn.
2.9.2 Mô hình vòng đời thác nước Mô hình

vòng đời thác nước được đưa ra lần đầu tiên bởi Royce [1970]. Hình 2.9 cho thấy các
vòng phản hồi để bảo trì trong khi sản phẩm đang được phát triển, như được phản ánh
trong Hình, 2.3 mô hình thác nước đơn giản hóa. Hình 2.9 cũng cho thấy các vòng phản
hồi để bảo trì sau giao hàng.
Một điểm quan trọng liên quan đến mô hình thác nước là không có giai đoạn nào được hoàn thành cho đến
khi tài liệu cho giai đoạn đó được hoàn thành và các sản phẩm của giai đoạn đó đã được nhóm đảm bảo chất
lượng phần mềm (SQA) phê duyệt. Điều này chuyển thành những ca-tions sửa đổi; nếu các sản phẩm của giai
đoạn trước phải thay đổi do hậu quả của việc tuân theo
HÌNH 2.9
Đã thay đổi
đầy đủ Yêu cầu
yêu cầu
cuộc sống thác nước-
mô hình chu kỳ
Phân tích
Thiết kế
Thực hiện
BẢO TRÌ
Phát triển
Sự nghỉ hưu
BẢO TRÌ
một vòng phản hồi, giai đoạn trước đó chỉ được coi là hoàn thành khi tài liệu về giai đoạn đó đã được
sửa đổi và các sửa đổi đó đã được nhóm SQA kiểm tra. Cố hữu trong mọi giai đoạn của mô hình thác nước
là thử nghiệm. Kiểm thử không phải là một giai đoạn riêng biệt chỉ được thực hiện sau khi sản phẩm đã
được xây dựng, cũng không phải chỉ được thực hiện vào cuối mỗi giai đoạn. Thay vào đó, như đã nêu trong
Phần 1.7, việc kiểm thử nên được tiến hành liên tục trong suốt quá trình phát triển phần mềm. Đặc
biệt, trong quá trình bảo trì, cần phải đảm bảo không chỉ phiên bản sửa đổi của sản phẩm vẫn thực hiện
những gì phiên bản trước đó đã làm—và vẫn thực hiện chính xác (kiểm tra hồi quy)—mà còn đáp ứng mọi
yêu cầu mới. do khách hàng áp đặt.
Mô hình thác nước có nhiều điểm mạnh, bao gồm cách tiếp cận có tính kỷ luật bắt buộc—quy định rằng
tài liệu phải được cung cấp ở mỗi giai đoạn và yêu cầu rằng tất cả sản phẩm của từng giai đoạn (bao
gồm cả tài liệu) phải được SQA kiểm tra tỉ mỉ. Tuy nhiên, thực tế là mô hình thác nước dựa trên tài
liệu cũng có thể là một điểm yếu. Để thấy điều này, hãy xem xét hai tình huống có phần kỳ lạ sau đây.
Đầu tiên, Joe và Jane Johnson quyết định xây một ngôi nhà. Họ tham khảo ý kiến của một kiến trúc sư.
Thay vì cho họ xem các bản phác thảo, sơ đồ và có lẽ cả mô hình tỷ lệ, kiến trúc sư đưa cho họ một tài
liệu đánh máy dài 20 trang mô tả ngôi nhà bằng thuật ngữ kỹ thuật cao. Mặc dù cả Joe và Jane đều không
có kinh nghiệm kiến trúc trước đó và hầu như không hiểu tài liệu nhưng họ vẫn nhiệt tình ký tên và nói:
“Hãy tiếp tục, xây nhà!”
Một tình huống khác như sau: Mark Marberry mua bộ vest của mình bằng cách đặt hàng qua thư. Thay vì
gửi cho anh ấy những bức ảnh về bộ vest của họ và các mẫu vải có sẵn, công ty gửi cho Mark một bản mô
tả bằng văn bản về đường cắt và vải của sản phẩm của họ. Sau đó, Mark đặt mua một bộ đồ chỉ dựa trên
mô tả bằng văn bản.
Hai kịch bản trước rất khó xảy ra. Tuy nhiên, chúng mô tả chính xác cách phần mềm thường được xây
dựng bằng mô hình thác nước. Quá trình bắt đầu với các thông số kỹ thuật. Nhìn chung, các tài liệu đặc
tả dài, chi tiết và khá nhàm chán khi đọc. Khách hàng thường thiếu kinh nghiệm trong việc đọc các đặc
tả phần mềm, và khó khăn này càng tăng thêm bởi thực tế là các tài liệu đặc tả thường được viết theo
phong cách mà khách hàng không quen thuộc. Khó khăn thậm chí còn tệ hơn khi các đặc tả được viết bằng
ngôn ngữ đặc tả hình thức như Z [Spivey, 1992] (Phần 12.9). Tuy nhiên, khách hàng vẫn tiếp tục ký vào
tài liệu đặc tả, cho dù đã hiểu đúng hay chưa. Theo nhiều cách, có rất ít sự khác biệt giữa việc Joe
và Jane Johnson ký hợp đồng xây dựng một ngôi nhà từ một bản mô tả bằng văn bản mà họ chỉ hiểu một phần
và việc khách hàng phê duyệt một sản phẩm phần mềm được mô tả dưới dạng một tài liệu đặc tả mà họ chỉ
hiểu một phần.
Mark Marberry và những bộ quần áo đặt hàng qua thư của anh ấy có vẻ cực kỳ kỳ quái, nhưng đó chính
xác là những gì xảy ra khi mô hình thác nước được sử dụng trong phát triển phần mềm. Lần đầu tiên khách
hàng nhìn thấy một sản phẩm đang hoạt động chỉ là sau khi toàn bộ sản phẩm đã được mã hóa.
Chẳng có gì ngạc nhiên khi các nhà phát triển phần mềm lại sống trong nỗi sợ hãi trước câu nói: “Tôi biết đây là điều
tôi đã yêu cầu nhưng nó không thực sự là điều tôi muốn”.
Điều gì đã xảy ra? Có sự khác biệt đáng kể giữa cách khách hàng hiểu về sản phẩm được mô tả trong
tài liệu mô tả và sản phẩm thực tế. Các thông số kỹ thuật chỉ tồn tại trên giấy tờ; do đó khách hàng
không thể thực sự hiểu được bản thân sản phẩm sẽ như thế nào. Mô hình thác nước, tùy thuộc vào cách nó
thực hiện chủ yếu trên văn bản

các thông số kỹ thuật có thể dẫn đến việc tạo ra các sản phẩm không đáp ứng được nhu cầu thực sự
của khách hàng.
Công bằng mà nói, cần phải chỉ ra rằng, giống như kiến trúc sư có thể giúp khách hàng hiểu cái
gì sẽ được xây dựng bằng cách cung cấp các mô hình tỷ lệ, bản phác thảo và kế hoạch, thì kỹ sư phần
mềm cũng có thể sử dụng các kỹ thuật đồ họa, chẳng hạn như sơ đồ luồng dữ liệu (Phần 12.3) hoặc sơ
đồ UML ( Chương 17 ) để giao tiếp với khách hàng. Vấn đề là những công cụ hỗ trợ bằng đồ họa này
không mô tả được sản phẩm hoàn thiện sẽ hoạt động như thế nào. Ví dụ: có sự khác biệt đáng kể giữa
sơ đồ (mô tả sơ đồ về sản phẩm) và bản thân sản phẩm đang hoạt động. Trong cuốn sách này, hai giải
pháp được đưa ra để giải quyết vấn đề mà tài liệu đặc tả thường không mô tả sản phẩm theo cách giúp
khách hàng xác định xem sản phẩm được đề xuất có đáp ứng được nhu cầu của mình hay không. Giải
pháp hướng đối tượng được mô tả trong Chương 11 và 13. Giải pháp cổ điển là mô hình tạo mẫu nhanh,
được mô tả trong Phần 2.9.3.
2.9.3 Mô hình vòng đời tạo mẫu nhanh Nguyên mẫu nhanh là một mô
hình hoạt động có chức năng tương đương với một tập hợp con của sản phẩm. Ví dụ: nếu sản phẩm mục
tiêu xử lý các tài khoản phải trả, tài khoản phải thu và lưu kho thì nguyên mẫu nhanh có thể bao
gồm một sản phẩm thực hiện xử lý màn hình để thu thập dữ liệu và in báo cáo nhưng không cập nhật
tệp hoặc xử lý lỗi. Một nguyên mẫu nhanh cho sản phẩm mục tiêu nhằm xác định nồng độ enzyme trong
dung dịch có thể thực hiện tính toán và hiển thị câu trả lời nhưng không thực hiện bất kỳ xác nhận
hoặc kiểm tra tính hợp lý nào của dữ liệu đầu vào.
Bước đầu tiên trong mô hình vòng đời tạo mẫu nhanh được mô tả trong Hình 2.10 là xây dựng một
nguyên mẫu nhanh và để khách hàng cũng như những người dùng tương lai tương tác và thử nghiệm với
nguyên mẫu nhanh. Một khi khách hàng hài lòng rằng nguyên mẫu nhanh chóng thực sự thực hiện được hầu hết
HÌNH 2.10
Nhanh Đã thay đổi
Mô hình nguyên mẫu yêu cầu
vòng đời tạo
nguyên mẫu nhanh.
Phân tích
Thiết kế
Thực hiện
BẢO TRÌ
Phát triển
Sự nghỉ hưu
BẢO TRÌ
56 Phần A Các khái niệm về kỹ thuật phần mềm
những gì được yêu cầu, các nhà phát triển có thể soạn thảo tài liệu đặc tả với sự đảm bảo nào đó
rằng sản phẩm đáp ứng được nhu cầu thực sự của khách hàng.
Sau khi tạo ra nguyên mẫu nhanh, quy trình phần mềm tiếp tục như trong Hình 2.10.
Điểm mạnh chính của mô hình tạo mẫu nhanh là sự phát triển của sản phẩm về cơ bản là
tuyến tính, tiến hành từ nguyên mẫu nhanh đến sản phẩm được giao; các vòng phản hồi của mô hình thác
nước ( Hình 2.9 ) ít có khả năng cần thiết hơn trong mô hình tạo mẫu nhanh. Có một số lý do cho việc
này. Đầu tiên, các thành viên của nhóm phát triển sử dụng nguyên mẫu nhanh để xây dựng tài liệu đặc
tả. Bởi vì nguyên mẫu hoạt động nhanh đã được xác nhận thông qua tương tác với khách hàng, nên có lý
khi hy vọng rằng tài liệu đặc tả kết quả sẽ chính xác. Thứ hai, hãy xem xét thiết kế. Mặc dù nguyên
mẫu nhanh chóng đã được lắp ráp một cách vội vã (hoàn toàn chính xác), nhóm thiết kế vẫn có thể hiểu
rõ hơn về nó - tệ nhất là nó sẽ thuộc loại "làm thế nào để không làm điều đó". Một lần nữa, các vòng
phản hồi của mô hình thác nước ít có khả năng cần thiết ở đây.
Việc thực hiện tiếp theo. Trong mô hình thác nước, việc triển khai thiết kế đôi khi dẫn đến phát
hiện ra lỗi thiết kế. Trong mô hình tạo mẫu nhanh, thực tế là phiên bản hoạt động sơ bộ của sản phẩm
phần mềm đã được xây dựng có xu hướng làm giảm nhu cầu sửa chữa thiết kế trong hoặc sau khi triển
khai. Nguyên mẫu đã cung cấp một số hiểu biết sâu sắc cho nhóm thiết kế, mặc dù nó có thể chỉ phản
ánh một phần chức năng của sản phẩm mục tiêu hoàn chỉnh.
Sau khi sản phẩm đã được khách hàng chấp nhận và lắp đặt, quá trình thuê chính sau khi giao hàng
sẽ bắt đầu. Tùy thuộc vào nhiệm vụ bảo trì cụ thể phải được thực hiện, chu trình được thực hiện lại
ở giai đoạn yêu cầu, phân tích, thiết kế hoặc triển khai.
Một khía cạnh thiết yếu của một nguyên mẫu nhanh được thể hiện trong từ “nhanh” . Các nhà phát
triển nên nỗ lực xây dựng nguyên mẫu nhanh nhất có thể để tăng tốc quá trình phát triển phần mềm.
Suy cho cùng, mục đích sử dụng duy nhất của nguyên mẫu nhanh là xác định nhu cầu thực sự của khách
hàng là gì; một khi điều này đã được xác định, việc triển khai nguyên mẫu nhanh chóng sẽ bị loại bỏ
nhưng các bài học kinh nghiệm sẽ được giữ lại và sử dụng trong các giai đoạn phát triển tiếp theo.
Vì lý do này, cấu trúc bên trong của nguyên mẫu nhanh là không phù hợp.
Điều quan trọng là nguyên mẫu phải được xây dựng nhanh chóng và được sửa đổi nhanh chóng để phản ánh
nhu cầu của khách hàng. Vì vậy, tốc độ là điều cốt yếu.
Tạo mẫu nhanh được thảo luận chi tiết hơn trong Chương 11 .
2.9.4 Mô hình vòng đời nguồn mở Hầu như tất cả các dự án
phần mềm nguồn mở thành công đều trải qua hai giai đoạn không chính thức.
Đầu tiên, một cá nhân có ý tưởng về một chương trình, chẳng hạn như hệ điều hành (Linux), trình duyệt
Net (Firefox) hoặc máy chủ Web (Apache). Anh ta hoặc cô ta xây dựng phiên bản đầu tiên, sau đó sẽ
được cung cấp để phân phối miễn phí cho bất kỳ ai muốn có một bản sao; ngày nay, việc này được thực
hiện thông qua Internet, tại các trang như SourceForge.net và FreshMeat.net.
Nếu ai đó tải xuống bản sao của phiên bản đầu tiên và cho rằng chương trình đáp ứng được nhu cầu thì
người đó sẽ bắt đầu sử dụng chương trình đó.
Nếu có đủ sự quan tâm đến chương trình, dự án sẽ chuyển dần sang giai đoạn hai không chính thức.
Người dùng trở thành người đồng phát triển, trong đó một số người dùng báo cáo lỗi và những người
khác đề xuất cách khắc phục những lỗi đó. Một số người dùng đưa ra ý tưởng để mở rộng chương trình,
HÌNH 2.11
Thực hiện các
Mô hình phiên bản đầu tiên
vòng đời nguồn

mở.
Thực hiện khắc phục,

hoàn thiện và thích nghi
bảo trì sau giao hàng
Phát triển
Sự nghỉ hưu
BẢO TRÌ
và những người khác thực hiện những ý tưởng đó. Khi chương trình mở rộng về chức năng, nhưng những người
dùng khác sẽ chuyển chương trình để chương trình có thể chạy trên các tổ hợp hệ điều hành/phần cứng bổ sung.
Một khía cạnh quan trọng là các cá nhân thường làm việc trong một dự án nguồn mở trong thời gian rảnh
rỗi trên cơ sở tự nguyện; họ không được trả tiền để tham gia.
Bây giờ hãy xem xét kỹ hơn ba hoạt động của giai đoạn không chính thức thứ hai:
1. Báo cáo và sửa lỗi là bảo trì khắc phục.
2. Thêm chức năng bổ sung là bảo trì hoàn hảo.
3. Chuyển chương trình sang môi trường mới là bảo trì thích ứng.
Nói cách khác, giai đoạn không chính thức thứ hai của mô hình vòng đời nguồn mở chỉ bao gồm việc
bảo trì sau giao hàng, như trong Hình 2.11. Trên thực tế, thuật ngữ người đồng phát triển
trong đoạn thứ hai của phần này nên là người đồng bảo trì .
Có một số điểm khác biệt chính giữa mô hình vòng đời phần mềm nguồn đóng và nguồn mở:
• Phần mềm nguồn đóng được duy trì và kiểm thử bởi các nhóm nhân viên của tổ chức sở hữu phần mềm.
Người dùng đôi khi gửi báo cáo lỗi. Tuy nhiên, những điều này chỉ giới hạn ở các báo cáo lỗi (báo
cáo về hành vi không chính xác được quan sát); người dùng không có quyền truy cập vào mã nguồn, vì
vậy họ không thể gửi báo cáo lỗi (báo cáo mô tả vị trí mã nguồn không chính xác và cách sửa mã
nguồn đó).
Ngược lại, phần mềm nguồn mở thường được duy trì bởi các tình nguyện viên không được trả lương.
Người dùng được khuyến khích gửi báo cáo lỗi. Mặc dù tất cả người dùng đều có quyền truy cập vào
mã nguồn nhưng chỉ một thiểu số mới có khuynh hướng và thời gian cũng như các kỹ năng cần thiết để
đọc mã nguồn và gửi báo cáo lỗi (“sửa lỗi”); do đó hầu hết các báo cáo lỗi đều là báo cáo lỗi. Nhìn
chung có một nhóm nòng cốt gồm những người bảo trì tận tâm chịu trách nhiệm quản lý dự án nguồn mở.
Một số thành viên của nhóm ngoại vi , tức là những người dùng không phải là thành viên của nhóm cốt
lõi, thỉnh thoảng chọn gửi báo cáo lỗi. Các thành viên của nhóm nòng cốt có trách nhiệm đảm bảo
rằng những khiếm khuyết này được sửa chữa. Chi tiết hơn, khi một báo cáo lỗi được gửi đi, một thành
viên nhóm cốt lõi sẽ kiểm tra xem bản sửa lỗi có thực sự giải quyết được vấn đề hay không và sửa
đổi mã nguồn một cách thích hợp. Khi báo cáo lỗi được gửi, một thành viên của nhóm nòng cốt sẽ tự
mình xác định cách khắc phục hoặc giao nhiệm vụ đó cho một tình nguyện viên khác,
thường là thành viên của nhóm ngoại vi mong muốn được tham gia nhiều hơn vào dự án nguồn mở.
Một lần nữa, quyền cài đặt bản sửa lỗi trong phần mềm bị hạn chế đối với các thành viên của
nhóm cốt lõi. • Các phiên bản
mới của phần mềm nguồn đóng thường được phát hành khoảng một năm một lần. Mỗi phiên bản mới đều
được nhóm đảm bảo chất lượng phần mềm kiểm tra kỹ lưỡng trước khi phát hành; một loạt các
trường hợp thử nghiệm được chạy.
Ngược lại, một châm ngôn của phong trào nguồn mở là “Phát hành sớm. Phát hành thường xuyên”
[Raymond, 2000]. Nghĩa là, nhóm cốt lõi sẽ phát hành phiên bản mới của sản phẩm nguồn mở
ngay khi nó sẵn sàng, có thể là một tháng hoặc thậm chí chỉ một ngày sau khi phiên bản trước
đó được phát hành. Phiên bản mới này được phát hành sau quá trình thử nghiệm tối thiểu; người
ta cho rằng thử nghiệm rộng rãi hơn sẽ được thực hiện bởi các thành viên của nhóm ngoại vi.
Một phiên bản mới có thể được hàng trăm nghìn người dùng cài đặt trong vòng một hoặc hai ngày
sau khi phát hành. Những người dùng này không chạy các trường hợp thử nghiệm như vậy. Tuy
nhiên, trong quá trình sử dụng phiên bản mới trên máy tính của mình, họ gặp phải lỗi và họ
báo cáo qua e-mail. Bằng cách này, các lỗi trong phiên bản mới (cũng như các lỗi sâu hơn ở
các phiên bản trước) sẽ được phát hiện và sửa chữa.
So sánh hình 2.8 , 2.10 , và 2,11 , chúng tôi thấy rằng mô hình vòng đời nguồn mở có
các tính năng chung với cả mô hình mã và sửa lỗi và mô hình tạo nguyên mẫu nhanh. Trong cả ba mô
hình vòng đời, một phiên bản hoạt động ban đầu đều được tạo ra. Trong trường hợp mô hình tạo mẫu
nhanh, phiên bản ban đầu này bị loại bỏ và sản phẩm mục tiêu sau đó được xác định và thiết kế
trước khi được mã hóa. Trong cả mô hình vòng đời code-and-fi x và nguồn mở, phiên bản ban đầu
được làm lại cho đến khi nó trở thành sản phẩm mục tiêu. Theo đó, trong một dự án nguồn mở, nhìn
chung không có thông số kỹ thuật hoặc thiết kế nào cả.
Ghi nhớ tầm quan trọng to lớn của việc có các thông số kỹ thuật và thiết kế, làm thế nào mà
một số dự án nguồn mở lại thành công đến vậy? Trong thế giới nguồn đóng, một số chuyên gia phần
mềm có kỹ năng cao hơn và một số có kỹ năng kém hơn (xem Phần 9.2). Thách thức của việc sản xuất
phần mềm nguồn mở đã thu hút một số chuyên gia phần mềm. Nói cách khác, một dự án nguồn mở có
thể thành công, bất chấp việc thiếu thông số kỹ thuật hoặc thiết kế, nếu kỹ năng của các cá nhân
làm việc trong dự án đó quá xuất sắc đến mức họ có thể hoạt động hiệu quả mà không cần thông số
kỹ thuật hoặc thiết kế.
Mô hình vòng đời nguồn mở bị hạn chế về khả năng ứng dụng. Một mặt, mô hình nguồn mở đã được
sử dụng cực kỳ thành công cho một số dự án phần mềm cơ sở hạ tầng nhất định, chẳng hạn như hệ
điều hành (Linux, OpenBSD, Mach, Darwin), trình duyệt Web (Firefox, Netscape), trình biên dịch
(gcc), Máy chủ web (Apache) hoặc hệ thống quản lý cơ sở dữ liệu (MySQL). Mặt khác, thật khó để
hình dung việc phát triển nguồn mở của một sản phẩm phần mềm chỉ được sử dụng trong một tổ chức
thương mại. Chìa khóa để phát triển phần mềm nguồn mở là các thành viên của cả nhóm cốt lõi và
nhóm ngoại vi đều là người dùng phần mềm đang được phát triển. Do đó, mô hình vòng đời nguồn mở
không thể áp dụng được trừ khi sản phẩm mục tiêu được nhiều người dùng xem là hữu ích đối với họ.
Tại thời điểm viết bài, có khoảng 350.000 dự án nguồn mở tại SourceForge.
net và FreshMeat.net. Khoảng một nửa trong số họ thậm chí chưa bao giờ thu hút được một nhóm làm
việc cho dự án. Trong số những nơi công việc đã bắt đầu, ưu thế áp đảo chưa bao giờ được hoàn
thành và khó có thể tiến xa hơn nữa. Nhưng khi mô hình nguồn mở
đã có hiệu quả, đôi khi nó còn thành công ngoài sức tưởng tượng. Các sản phẩm nguồn mở được liệt
kê trong ngoặc đơn ở đoạn trước được sử dụng rộng rãi; hầu hết chúng được sử dụng thường xuyên
bởi hàng triệu người dùng.
Những giải thích cho sự thành công của mô hình vòng đời nguồn mở được trình bày trong Chương
4 trong bối cảnh các khía cạnh tổ chức nhóm của các dự án phần mềm nguồn mở.
2.9.5 Quy trình Agile Lập trình
cực đoan [Beck, 2000] là một cách tiếp cận mới gây nhiều tranh cãi để phát triển phần mềm dựa
trên mô hình lặp và tăng dần. Bước đầu tiên là nhóm phát triển phần mềm xác định các tính năng
( câu chuyện ) khác nhau mà khách hàng muốn sản phẩm hỗ trợ. Đối với mỗi tính năng như vậy, nhóm
sẽ thông báo cho khách hàng sẽ mất bao lâu để triển khai tính năng đó và chi phí sẽ là bao
nhiêu. Bước đầu tiên này tương ứng với các yêu cầu và quy trình phân tích của mô hình lặp và
tăng dần ( Hình 2.4 ).
Khách hàng chọn các tính năng sẽ được đưa vào mỗi bản dựng kế tiếp bằng cách sử dụng chi phí–
phân tích lợi ích (Phần 5.2), tức là trên cơ sở thời lượng và ước tính chi phí do nhóm phát
triển cung cấp cũng như những lợi ích tiềm năng của tính năng này đối với hoạt động kinh doanh
của họ. Bản dựng được đề xuất được chia thành các phần nhỏ hơn được gọi là nhiệm vụ. Đầu tiên,
một lập. trình viên sẽ đưa ra các trường hợp thử nghiệm cho một nhiệm vụ; đây được gọi là phát
triển dựa trên thử nghiệm (TDD). Hai lập trình viên làm việc cùng nhau trên một máy tính ( lập
trình cặp ) [Williams, Kessler, Cunningham và Jeffries, 2000], thực hiện nhiệm vụ và đảm bảo
rằng tất cả các trường hợp kiểm thử đều hoạt động chính xác. Hai lập trình viên thay phiên nhau
gõ 15 hoặc 20 phút một lần; lập trình viên không gõ cẩn thận sẽ kiểm tra mã trong khi đối tác
của họ nhập nó. Nhiệm vụ sau đó được tích hợp vào phiên bản hiện tại của sản phẩm. Lý tưởng
nhất là việc triển khai và tích hợp một nhiệm vụ sẽ không mất quá vài giờ. Nói chung, một số
cặp sẽ thực hiện các nhiệm vụ song song, do đó việc tích hợp về cơ bản là liên tục. Các thành
viên trong nhóm thay đổi đối tác viết mã hàng ngày, nếu có thể; học hỏi từ các thành viên khác
trong nhóm sẽ nâng cao trình độ kỹ năng của mọi người. Các trường hợp kiểm thử TDD được sử dụng
cho nhiệm vụ này sẽ được giữ lại và sử dụng trong tất cả các thử nghiệm tích hợp tiếp theo.
Một số hạn chế của lập trình cặp đã được quan sát thấy trong thực tế [Drobka, Noftz và
Raghu, 2004]. Ví dụ: lập trình theo cặp yêu cầu khối thời gian lớn không bị gián đoạn và các
chuyên gia phần mềm có thể gặp khó khăn trong việc tìm ra khối thời gian từ 3 đến 4 giờ.
Ngoài ra, lập trình cặp không phải lúc nào cũng hiệu quả với những cá nhân nhút nhát, hống hách
hoặc với hai lập trình viên thiếu kinh nghiệm.
Một số tính năng của lập trình cực đoan (XP) hơi khác so với
cách thức mà phần mềm thường được phát triển:
• Các máy tính của nhóm XP được đặt ở trung tâm của một căn phòng lớn có các dãy bàn nhỏ
ngăn tủ.
• Đại diện khách hàng luôn làm việc với nhóm XP. • Không cá nhân
nào được phép làm thêm giờ trong hai tuần liên tiếp.
• Không có chuyên môn. Thay vào đó, tất cả thành viên của nhóm XP đều làm việc theo yêu cầu,
phân tích, thiết kế, mã hóa và thử nghiệm.
• Không có bước thiết kế tổng thể trước khi xây dựng các công trình khác nhau. Thay vào đó, dấu hiệu hủy
bỏ được sửa đổi trong khi sản phẩm đang được xây dựng. Thủ tục này được gọi là tái cấu trúc .
Bất cứ khi nào một trường hợp kiểm thử không chạy, mã sẽ được tổ chức lại cho đến khi nhóm hài lòng rằng
thiết kế đơn giản, dễ hiểu và chạy tất cả các trường hợp kiểm thử một cách thỏa đáng.
Hai từ viết tắt hiện nay liên quan đến lập trình cực đoan là YAGNI (bạn sẽ không cần nó) và DTSTTCPW
(làm điều đơn giản nhất có thể có tác dụng). Nói cách khác, nguyên tắc lập trình cực đoan là giảm thiểu số
lượng tính năng; không cần thiết phải xây dựng một sản phẩm có thể làm được nhiều hơn những gì khách hàng
thực sự cần.
Lập trình cực đoan là một trong số các mô hình mới được gọi chung là các quy trình linh hoạt . Mười bảy
nhà phát triển phần mềm (sau này được gọi là Liên minh Agile) đã gặp nhau tại một khu nghỉ mát trượt tuyết
ở Utah trong hai ngày vào tháng 2 năm 2001 và đưa ra Tuyên ngôn về Phát triển phần mềm Agile [Beck và cộng
sự, 2001]. Nhiều người tham gia trước đây đã là tác giả của các phương pháp phát triển phần mềm của riêng
họ, bao gồm Extreme Programming [Beck, 2000], Crystal [Cockburn, 2001] và Scrum [Schwaber, 2001]. Do đó,
Liên minh Agile đã không quy định một mô hình vòng đời cụ thể mà đặt ra một nhóm các nguyên tắc cơ bản chung
cho các phương pháp phát triển phần mềm riêng của họ.
Các quy trình linh hoạt có đặc điểm là ít chú trọng hơn vào phân tích và thiết kế so với hầu hết các mô
hình vòng đời hiện đại khác. Việc triển khai bắt đầu sớm hơn nhiều trong vòng đời vì phần mềm hoạt động được
coi là quan trọng hơn tài liệu chi tiết. Khả năng đáp ứng với những thay đổi trong yêu cầu là một mục tiêu
chính khác của các quy trình linh hoạt và tầm quan trọng của việc cộng tác với khách hàng cũng vậy.
Một trong những nguyên tắc trong Tuyên ngôn là cung cấp phần mềm hoạt động được thường xuyên, lý tưởng
nhất là 2 hoặc 3 tuần một lần. Một cách để đạt được điều này là sử dụng hộp thời gian [Jalote, Palit,
Kurien và Peeth-amber, 2004], đã được sử dụng trong nhiều năm như một kỹ thuật quản lý thời gian. Một khoảng
thời gian cụ thể được dành cho một nhiệm vụ và các thành viên trong nhóm sẽ thực hiện công việc tốt nhất có
thể trong thời gian đó. Trong bối cảnh của các quy trình linh hoạt, thường có 3 tuần được dành cho mỗi lần lặp lại.
Một mặt, nó mang lại cho khách hàng niềm tin khi biết rằng phiên bản mới với chức năng bổ sung sẽ xuất hiện
sau mỗi 3 tuần. Mặt khác, các nhà phát triển biết rằng họ sẽ có 3 tuần (nhưng không nhiều hơn) để cung cấp
phiên bản mới mà không có bất kỳ hình thức can thiệp nào của khách hàng; một khi khách hàng đã chọn công
việc cho một lần lặp lại thì nó không thể thay đổi hoặc tăng lên. Tuy nhiên, nếu không thể hoàn thành toàn
bộ nhiệm vụ trong hộp thời gian thì công việc có thể bị giảm bớt (“được mô tả”).
Nói cách khác, các quy trình linh hoạt đòi hỏi thời gian cố định chứ không phải các tính năng cố định.
Một đặc điểm chung khác của quy trình linh hoạt là tổ chức các cuộc họp ngắn vào thời gian cố định mỗi
ngày. Tất cả các thành viên trong nhóm phải tham dự cuộc họp. Yêu cầu tất cả những người tham gia đứng thành
vòng tròn thay vì ngồi quanh bàn sẽ giúp đảm bảo rằng cuộc họp kéo dài không quá 15 phút quy định. Mỗi thành
viên trong nhóm lần lượt trả lời năm câu hỏi:
• Tôi đã làm được gì kể từ cuộc họp hôm qua? • Hôm nay
tôi đang làm gì? • Vấn đề gì đang cản
trở tôi đạt được điều này? • Chúng ta đã quên điều gì? • Tôi đã học
được điều gì muốn chia sẻ với
nhóm?
Mục đích của cuộc họp độc lập là nêu ra vấn đề chứ không phải giải quyết chúng; các giải pháp được tìm
ra tại các cuộc họp tiếp theo, tốt nhất là được tổ chức ngay sau cuộc họp độc lập.
Giống như hộp thời gian, các cuộc họp độc lập là một kỹ thuật quản lý thành công hiện được sử dụng
trong bối cảnh của các quy trình linh hoạt. Cả hai lần lặp lại theo khung thời gian và các cuộc họp độc
lập đều là ví dụ của hai nguyên tắc cơ bản làm nền tảng cho tất cả các phương pháp linh hoạt: giao tiếp
và đáp ứng nhu cầu của khách hàng nhanh nhất có thể.
Các quy trình linh hoạt đã được sử dụng thành công ở một số dự án quy mô nhỏ. Tuy nhiên, các quy
trình linh hoạt vẫn chưa được sử dụng đủ rộng rãi để xác định liệu phương pháp này có thực hiện được
hứa hẹn ban đầu hay không. Hơn nữa, ngay cả khi các quy trình linh hoạt tỏ ra tốt cho các sản phẩm phần
mềm quy mô nhỏ, điều đó không nhất thiết có nghĩa là chúng có thể được sử dụng cho các sản phẩm phần
mềm quy mô vừa hoặc lớn, như sẽ được giải thích sau đây.
Để đánh giá cao lý do tại sao nhiều chuyên gia phần mềm bày tỏ nghi ngờ về các quy trình linh hoạt
trong bối cảnh các sản phẩm phần mềm quy mô trung bình và đặc biệt là quy mô lớn [Reifer, Maurer, và
Erdogmus, 2003], hãy xem xét sự tương tự sau đây của Grady Booch [2000].
Bất cứ ai cũng có thể đóng thành công một vài tấm ván để xây chuồng chó, nhưng sẽ thật liều lĩnh nếu
xây một ngôi nhà ba phòng ngủ mà không có kế hoạch chi tiết. Ngoài ra, để xây một ngôi nhà ba phòng ngủ,
cần có các kỹ năng về hệ thống ống nước, hệ thống dây điện và mái nhà và việc kiểm tra là rất cần thiết.
(Nghĩa là, có khả năng xây dựng các sản phẩm phần mềm quy mô nhỏ không nhất thiết có nghĩa là người ta
có kỹ năng xây dựng các sản phẩm phần mềm quy mô trung bình.) Hơn nữa, thực tế là một tòa nhà chọc trời
có chiều cao bằng 1000 chuồng chó không có nghĩa là người ta có thể xây dựng một tòa nhà chọc trời bằng
cách xếp chồng 1000 chuồng chó lên nhau. Nói cách khác, việc xây dựng các sản phẩm phần mềm quy mô lớn
thậm chí còn đòi hỏi những kỹ năng chuyên môn và phức tạp hơn những kỹ năng cần thiết để tạo ra các sản
phẩm phần mềm quy mô nhỏ.
Yếu tố quyết định chính trong việc quyết định liệu các quy trình linh hoạt có thực sự là một bước
đột phá lớn trong công nghệ phần mềm hay không sẽ là chi phí bảo trì sau phân phối trong tương lai (Phần
1.3.2). Nghĩa là, nếu việc sử dụng các quy trình linh hoạt giúp giảm chi phí bảo trì sau giao hàng, thì
XP và các quy trình linh hoạt khác sẽ được áp dụng rộng rãi. Mặt khác, tái cấu trúc là một thành phần
nội tại của các quy trình linh hoạt. Như đã giải thích trước đây, sản phẩm không được thiết kế tổng
thể; thay vào đó, thiết kế được phát triển tăng dần và mã được tổ chức lại bất cứ khi nào thiết kế hiện
tại không đạt yêu cầu vì bất kỳ lý do gì. Quá trình tái cấu trúc này sau đó sẽ tiếp tục trong quá trình
bảo trì sau phân phối. Nếu thiết kế của một sản phẩm khi nó vượt qua bài kiểm tra chấp nhận là có tính
mở và linh hoạt thì việc bảo trì hoàn hảo sẽ dễ dàng đạt được với chi phí thấp. Tuy nhiên, nếu thiết
kế phải được tái cấu trúc bất cứ khi nào chức năng bổ sung được thêm vào thì chi phí bảo trì sau khi
giao hàng cho sản phẩm đó sẽ cao đến mức không thể chấp nhận được. Do tính mới của phương pháp này, về
cơ bản vẫn chưa có dữ liệu về việc bảo trì phần mềm được phát triển bằng quy trình linh hoạt. Tuy nhiên,
dữ liệu bảo trì sơ bộ chỉ ra rằng việc tái cấu trúc có thể tiêu tốn một tỷ lệ lớn trong tổng chi phí
[Li và Alshayeb, 2002].
Các thử nghiệm đã chỉ ra rằng một số tính năng nhất định của quy trình linh hoạt có thể hoạt động
tốt. Ví dụ, Williams, Kessler, Cunningham và Jeffries [2000] đã chỉ ra rằng lập trình cặp dẫn đến sự
phát triển mã chất lượng cao hơn trong thời gian ngắn hơn, mang lại sự hài lòng công việc cao hơn. Tuy
nhiên, một thử nghiệm rộng rãi để đánh giá lập trình cặp trong bối cảnh bảo trì phần mềm được mô tả
trong Phần 4.6 [Arisholm, Gallis, Dybå, và Sjøberg, 2007] đã đưa ra cùng một kết luận khi phân tích 15
nghiên cứu được công bố so sánh hiệu quả của từng chương trình. và lập trình cặp [Dybå và cộng sự,
2007]: Nó phụ thuộc vào cả chuyên môn của người lập trình và độ phức tạp của sản phẩm phần mềm cũng như
các nhiệm vụ cần giải quyết.
Tuyên ngôn về Phát triển Phần mềm Agile về cơ bản tuyên bố rằng các quy trình linh hoạt vượt trội
hơn các quy trình kỷ luật hơn như Quy trình Thống nhất ( Chương 3 ). Những người hoài nghi trả lời rằng
những người ủng hộ quy trình linh hoạt chỉ hơn tin tặc một chút. Tuy nhiên, có một nền tảng trung gian.
Hai cách tiếp cận này không phải là không tương thích; có thể kết hợp các tính năng đã được chứng minh
của các quy trình linh hoạt trong khuôn khổ các quy trình có kỷ luật. Sự tích hợp của hai cách
tiếp cận này được mô tả trong các cuốn sách như cuốn của Boehm và Turner [2003].
Tóm lại, các quy trình linh hoạt dường như là một cách tiếp cận hữu ích để xây dựng các sản
phẩm phần mềm quy mô nhỏ khi yêu cầu của khách hàng còn mơ hồ. Ngoài ra, một số tính năng của quy
trình linh hoạt có thể được sử dụng hiệu quả trong bối cảnh của các mô hình vòng đời khác.
2.9.6 Đồng bộ hóa và Ổn định Mô hình Vòng đời Microsoft, Inc., là nhà sản
xuất phần mềm COTS lớn nhất thế giới. Phần lớn các gói của nó được xây dựng bằng cách sử dụng một
phiên bản của mô hình lặp và tăng dần được gọi là mô hình vòng đời đồng bộ hóa và ổn định
[Cusumano và Selby, 1997].

Giai đoạn phân tích yêu cầu được thực hiện bằng cách phỏng vấn nhiều khách hàng tiềm năng cho
gói và trích xuất danh sách các tính năng có mức độ ưu tiên cao nhất đối với khách hàng. Một tài
liệu cụ thể bây giờ đã được soạn thảo. Tiếp theo, tác phẩm được chia thành ba hoặc bốn bản dựng.
Bản dựng đầu tiên bao gồm các tính năng quan trọng nhất, bản dựng thứ hai bao gồm các tính năng
quan trọng nhất tiếp theo, v.v. Mỗi bản dựng được thực hiện bởi một số nhóm nhỏ làm việc song song.
Cuối mỗi ngày, tất cả các đội đều đồng bộ ; nghĩa là họ đặt các thành phần đã hoàn thiện một phần
lại với nhau rồi kiểm tra và gỡ lỗi cho sản phẩm thu được. Quá trình ổn định được thực hiện vào
cuối mỗi bản dựng. Mọi lỗi còn lại được phát hiện cho đến nay đều đã được sửa và giờ đây chúng sẽ
đóng băng bản dựng; nghĩa là, sẽ không có thay đổi nào nữa đối với các thông số kỹ thuật.
Bước đồng bộ hóa lặp đi lặp lại đảm bảo rằng các thành phần khác nhau luôn hoạt động cùng
nhau. Một ưu điểm khác của việc thực hiện thường xuyên sản phẩm được xây dựng một phần này là các
nhà phát triển có được cái nhìn sâu sắc sớm về hoạt động của sản phẩm và có thể sửa đổi các yêu
cầu nếu cần thiết trong quá trình xây dựng. Mô hình vòng đời có thể được sử dụng ngay cả khi đặc
tả ban đầu chưa đầy đủ. Mô hình đồng bộ hóa và ổn định được xem xét kỹ hơn trong Phần 4.5, trong
đó các chi tiết về tổ chức nhóm sẽ được thảo luận.
Mô hình xoắn ốc được giữ nguyên vì nó kết hợp các khía cạnh của tất cả các mô hình khác được
mô tả trong Phần 2.9.
2.9.7 Mô hình vòng đời xoắn ốc Như

đã nêu trong Phần 2.5, yếu tố rủi ro luôn liên quan đến việc phát triển phần mềm.
Ví dụ, nhân sự chủ chốt có thể từ chức trước khi sản phẩm được ghi chép đầy đủ.
Nhà sản xuất phần cứng mà sản phẩm phụ thuộc rất nhiều vào đó có thể bị phá sản.
Quá nhiều hoặc quá ít đều có thể được đầu tư vào việc thử nghiệm và đảm bảo chất lượng.
Sau khi chi hàng trăm nghìn USD để phát triển một sản phẩm phần mềm lớn, những đột phá về công
nghệ có thể khiến toàn bộ sản phẩm trở nên vô giá trị. Một tổ chức có thể nghiên cứu và phát
triển một hệ thống quản lý cơ sở dữ liệu, nhưng trước khi sản phẩm có thể được đưa ra thị trường,
một gói có chức năng tương đương, có giá thấp hơn sẽ được công bố bởi đối thủ cạnh tranh. Các
thành phần của sản phẩm có thể không khớp với nhau khi thực hiện tích hợp. Vì những lý do hiển
nhiên, các nhà phát triển phần mềm cố gắng giảm thiểu những rủi ro đó bất cứ khi nào có thể.
Một cách để giảm thiểu một số loại rủi ro nhất định là xây dựng nguyên mẫu. Như được mô tả
trong Phần 2.9.3, một cách tiếp cận để giảm rủi ro rằng sản phẩm được giao không đáp ứng được nhu
cầu thực sự của khách hàng là xây dựng một nguyên mẫu nhanh trong giai đoạn yêu cầu. Trong các
giai đoạn tiếp theo, các loại nguyên mẫu khác có thể phù hợp. Ví dụ, một công ty điện thoại có
thể nghĩ ra một thuật toán mới, có vẻ hiệu quả cao để định tuyến các cuộc gọi qua mạng đường dài.
Nếu sản phẩm được triển khai nhưng không hoạt động như mong đợi thì công ty điện thoại sẽ lãng
phí chi phí phát triển sản phẩm. Ngoài ra, tức giận hoặc
những khách hàng bất tiện có thể đưa doanh nghiệp của họ đi nơi khác. Có thể tránh được kết quả này bằng
cách xây dựng một nguyên mẫu chứng minh khái niệm để chỉ xử lý việc định tuyến các cuộc gọi và thử nghiệm
nó trên một trình mô phỏng. Bằng cách này, hệ thống thực tế không bị xáo trộn; và đối với chi phí triển
khai thuật toán định tuyến, công ty điện thoại có thể xác định liệu có đáng để phát triển toàn bộ bộ điều
khiển mạng kết hợp thuật toán mới hay không.
Nguyên mẫu chứng minh khái niệm không phải là nguyên mẫu nhanh được xây dựng để chắc chắn rằng các yêu
cầu đã được xác định chính xác, như được mô tả trong Phần 2.9.3. Thay vào đó, nó giống một nguyên mẫu kỹ
thuật hơn, tức là một mô hình quy mô được xây dựng để kiểm tra tính khả thi của việc xây dựng. Nếu nhóm
phát triển lo ngại liệu một phần cụ thể của sản phẩm phần mềm được đề xuất có thể được xây dựng hay không
thì một nguyên mẫu chứng minh khái niệm sẽ được xây dựng. Ví dụ, các nhà phát triển có thể lo ngại liệu
một tính toán cụ thể có thể được thực hiện đủ nhanh hay không.
Trong trường hợp đó, họ xây dựng một nguyên mẫu để kiểm tra thời gian thực hiện phép tính đó. Hoặc họ có
thể lo lắng rằng phông chữ họ định sử dụng cho tất cả các màn hình sẽ quá nhỏ để người dùng bình thường có
thể đọc mà không bị mỏi mắt. Trong trường hợp này, họ xây dựng một nguyên mẫu để hiển thị một số màn hình
khác nhau và xác định bằng thử nghiệm xem liệu người dùng có thấy phông chữ nhỏ đến mức khó chịu hay không.
Ý tưởng giảm thiểu rủi ro thông qua việc sử dụng nguyên mẫu và các phương tiện khác là ý tưởng làm nền
tảng cho mô hình vòng đời xoắn ốc [Boehm, 1988]. Một cách đơn giản để xem xét mô hình vòng đời này là mô
hình thác nước với mỗi giai đoạn được phân tích rủi ro trước đó, như trong Hình 2.12. Trước khi bắt đầu
mỗi giai đoạn, cần nỗ lực giảm thiểu (kiểm soát) rủi ro. Nếu không thể giảm thiểu tất cả các rủi ro đáng
kể ở giai đoạn đó thì dự án sẽ bị chấm dứt ngay lập tức.
HÌNH 2.12
Phân tích rủi ro Phân tích rủi ro
Một phiên bản
Nhanh Đã thay đổi
đơn giản hóa của
nguyên mẫu yêu cầu
mô hình vòng đời
xoắn ốc
Phân tích rủi ro
Sự chỉ rõ
Thiết kế
Thực hiện
BẢO TRÌ
Phát triển
Sự nghỉ hưu
BẢO TRÌ
Nguyên mẫu có thể được sử dụng một cách hiệu quả để cung cấp thông tin về các loại rủi ro nhất định.
Ví dụ, các ràng buộc về thời gian thường có thể được kiểm tra bằng cách xây dựng một nguyên mẫu và đo xem
liệu nguyên mẫu đó có thể đạt được hiệu suất cần thiết hay không. Nếu nguyên mẫu là sự thể hiện chức năng
chính xác của các tính năng liên quan của sản phẩm thì các phép đo được thực hiện trên nguyên mẫu sẽ giúp
nhà phát triển ý tưởng hay về việc liệu có thể đạt được các ràng buộc về thời gian hay không.
Các lĩnh vực rủi ro khác ít phù hợp hơn với việc tạo mẫu, ví dụ, rủi ro là nhân viên phần mềm cần thiết
để xây dựng sản phẩm không thể được thuê hoặc nhân sự chủ chốt có thể từ chức trước khi dự án hoàn thành.
Một rủi ro tiềm ẩn khác là một nhóm cụ thể có thể không đủ năng lực để phát triển một sản phẩm quy mô lớn
cụ thể. Một nhà thầu thành công khi xây dựng những ngôi nhà dành cho một gia đình có lẽ sẽ không thể xây
dựng một khu phức hợp văn phòng cao tầng. Tương tự như vậy, có những khác biệt cơ bản giữa phần mềm quy mô
nhỏ và quy mô lớn, và việc tạo nguyên mẫu ít được sử dụng. Rủi ro này không thể được giảm thiểu bằng cách
kiểm tra hiệu suất của nhóm trên một nguyên mẫu nhỏ hơn nhiều, trong đó các vấn đề về tổ chức nhóm cụ thể
đối với phần mềm quy mô lớn không thể phát sinh. Một lĩnh vực rủi ro khác mà việc tạo nguyên mẫu không thể
áp dụng là đánh giá lời hứa giao hàng của nhà cung cấp phần cứng.
Một chiến lược mà nhà phát triển có thể áp dụng là xác định xem các khách hàng trước đây của nhà cung cấp
đã được đối xử tốt như thế nào, nhưng hiệu suất trong quá khứ không phải là một yếu tố dự đoán nhất định về
hiệu suất trong tương lai. Điều khoản phạt trong hợp đồng giao hàng là một cách để cố gắng đảm bảo rằng
phần cứng thiết yếu được giao đúng thời hạn, nhưng điều gì sẽ xảy ra nếu nhà cung cấp từ chối ký một thỏa
thuận có điều khoản như vậy? Ngay cả khi có điều khoản phạt, việc giao hàng trễ có thể xảy ra và cuối cùng
dẫn đến hành động pháp lý có thể kéo dài trong nhiều năm. Trong khi chờ đợi, nhà phát triển phần mềm có
thể đã phá sản vì việc không cung cấp phần cứng đã hứa dẫn đến việc không cung cấp phần mềm đã hứa. Nói tóm
lại, trong khi việc tạo nguyên mẫu giúp giảm thiểu rủi ro ở một số lĩnh vực thì ở những lĩnh vực khác, tốt
nhất đó chỉ là câu trả lời một phần, còn ở những lĩnh vực khác thì đó lại không phải là câu trả lời.
Mô hình xoắn ốc đầy đủ được thể hiện trong Hình 2.13. Kích thước xuyên tâm thể hiện chi phí tích lũy
cho đến nay và kích thước góc thể hiện sự tiến triển theo đường xoắn ốc. Mỗi chu kỳ của đường xoắn ốc tương
ứng với một pha. Một giai đoạn bắt đầu (ở góc phần tư trên cùng bên trái) bằng cách xác định các mục tiêu
của giai đoạn đó, các phương án thay thế để đạt được các mục tiêu đó và các ràng buộc áp đặt lên các
phương án đó. Quá trình này dẫn đến một chiến lược để đạt được những mục tiêu đó. Tiếp theo, chiến lược đó
được phân tích từ góc độ rủi ro. Nỗ lực được thực hiện để giảm thiểu mọi rủi ro tiềm ẩn, trong một số
trường hợp bằng cách xây dựng một nguyên mẫu. Nếu không thể giảm thiểu một số rủi ro nhất định, dự án có
thể bị chấm dứt ngay lập tức; tuy nhiên, trong một số trường hợp, người ta có thể đưa ra quyết định tiếp
tục dự án nhưng ở quy mô nhỏ hơn đáng kể.
Nếu tất cả rủi ro được giảm thiểu thành công thì bước phát triển tiếp theo sẽ được bắt đầu (góc phần tư
phía dưới bên phải). Góc phần tư này của mô hình xoắn ốc tương ứng với mô hình thác nước cổ điển.
Cuối cùng, kết quả của giai đoạn đó được đánh giá và giai đoạn tiếp theo được lên kế hoạch.
Mô hình xoắn ốc đã được sử dụng thành công để phát triển nhiều loại sản phẩm. Trong một nhóm gồm 25 dự
án trong đó mô hình xoắn ốc được sử dụng kết hợp với các phương tiện khác để tăng năng suất, năng suất của
mỗi dự án đã tăng ít nhất 50% so với mức năng suất trước đó và 100% ở hầu hết các dự án [Boehm, 1988 ].
Để có thể quyết định xem có nên sử dụng mô hình xoắn ốc cho một dự án nhất định hay không, điểm mạnh và
điểm yếu của mô hình xoắn ốc hiện đã được đánh giá.
Mô hình xoắn ốc có một số điểm mạnh. Việc nhấn mạnh vào các lựa chọn thay thế và các ràng buộc hỗ trợ
việc sử dụng lại phần mềm hiện có (Phần 8.1) và việc kết hợp các
HÌNH 2.13 Mô hình vòng đời xoắn ốc đầy đủ [Boehm, 1988]. (© 1988 IEEE.)
Tích lũy
trị giá
Tiến triển
bởi vì
bước
Quyết tâm Đánh giá các lựa chọn thay thế,
mục tiêu, xác định, giảm thiểu rủi ro
lựa chọn thay thế,

hạn chế
Rủi ro
Rủi ro Phân tích
Rủi ro Phân tích
Phân tích
Nguyên
mẫu
ủrR
Nguyên mẫu Nguyên mẫu Nguyên mẫu
htP
io
ncâí
hoạt động
h
Sự cam kết 1 2 3
Ôn tập
vách ngăn Kế hoạch yêu cầu Mô phỏng, mô hình, điểm chuẩn
Kế hoạch vòng đời Khái niệm về

hoạt động Phần mềm
Chi tiết
Phần mềm
yêu cầu
thiết kế
sản phẩm
Kế hoạch thiết kế
Xác thực yêu cầu
phát triển Mã số
Đơn vị
Hội nhập Bài kiểm tra
Xác nhận thiết kế

và kiểm tra
và xác minh Hội
kế hoạch
nhập
Lập kế hoạch giai đoạn tiếp theo
Chấp Bài kiểm tra
thuận
Thực hiện Bài kiểm tra
Phát triển, xác minh
sản phẩm cấp độ tiếp theo
chất lượng phần mềm như một mục tiêu cụ thể. Ngoài ra, một vấn đề phổ biến trong phát
triển phần mềm là xác định khi nào sản phẩm của một giai đoạn cụ thể đã được kiểm thử đầy đủ.
Dành quá nhiều thời gian cho việc thử nghiệm là lãng phí tiền bạc và việc giao sản phẩm
có thể bị trì hoãn quá mức. Ngược lại, nếu thực hiện quá ít thử nghiệm thì phần mềm được
phân phối có thể còn sót lại các lỗi, dẫn đến hậu quả khó chịu cho nhà phát triển. Mô
hình xoắn ốc trả lời câu hỏi này về mặt rủi ro có thể xảy ra do không thực hiện đủ thử
nghiệm hoặc thực hiện quá nhiều thử nghiệm. Có lẽ quan trọng nhất, trong cấu trúc của mô
hình xoắn ốc, bảo trì sau giao hàng chỉ đơn giản là một chu kỳ khác của xoắn ốc; về cơ
bản không có sự phân biệt giữa bảo trì và phát triển sau giao hàng. Do đó, vấn đề bảo trì
sau giao hàng đôi khi bị các chuyên gia phần mềm thiếu hiểu biết coi thường không xảy ra,
bởi vì bảo trì sau giao hàng được xử lý giống như quá trình phát triển.
66 Phần A Các khái niệm về kỹ thuật phần mềm
Có những hạn chế về khả năng áp dụng mô hình xoắn ốc. Cụ thể, ở dạng hiện tại, mô hình này chỉ
dành riêng cho việc phát triển nội bộ phần mềm quy mô lớn [Boehm, 1988]. Hãy xem xét một dự án nội bộ,
tức là một dự án trong đó các nhà phát triển và khách hàng là thành viên của cùng một tổ chức. Nếu
phân tích rủi ro dẫn đến kết luận rằng dự án nên bị chấm dứt thì nhân viên phần mềm nội bộ có thể được
phân công lại sang một dự án khác.
Tuy nhiên, một khi hợp đồng đã được ký kết giữa tổ chức phát triển và khách hàng bên ngoài, nỗ lực
chấm dứt hợp đồng đó của một trong hai bên có thể dẫn đến một vụ kiện vi phạm hợp đồng. Do đó, trong
trường hợp phần mềm hợp đồng, mọi phân tích rủi ro phải được cả khách hàng và nhà phát triển thực hiện
trước khi hợp đồng được ký kết chứ không phải như trong mô hình xoắn ốc.
Hạn chế thứ hai đối với mô hình xoắn ốc liên quan đến quy mô của dự án. Cụ thể, mô hình xoắn ốc
chỉ có thể áp dụng cho phần mềm quy mô lớn. Sẽ vô nghĩa khi thực hiện phân tích rủi ro nếu chi phí
thực hiện phân tích rủi ro tương đương với chi phí của toàn bộ dự án hoặc nếu việc thực hiện phân tích
rủi ro sẽ ảnh hưởng đáng kể đến tiềm năng lợi nhuận. Thay vào đó, trước tiên các nhà phát triển nên
quyết định mức độ rủi ro và sau đó thực hiện phân tích rủi ro bao nhiêu, nếu có.
Điểm mạnh chính của mô hình xoắn ốc là nó có tính rủi ro, nhưng đây cũng có thể là điểm yếu.
Trừ khi các nhà phát triển phần mềm có kỹ năng xác định các rủi ro có thể xảy ra và phân tích rủi ro
một cách chính xác, nếu không thì nguy cơ thực sự là nhóm có thể tin rằng tất cả đều ổn vào thời điểm
mà trên thực tế, dự án đang hướng tới thảm họa. Chỉ khi các thành viên của nhóm phát triển là những
nhà phân tích rủi ro có năng lực thì ban quản lý mới quyết định sử dụng mô hình xoắn ốc.
Tuy nhiên, nhìn chung, điểm yếu chính của mô hình xoắn ốc, cũng như mô hình thác nước và mô hình
tạo mẫu nhanh, là nó giả định rằng phần mềm được phát triển theo các giai đoạn riêng biệt. Tuy nhiên,
trên thực tế, việc phát triển phần mềm có tính lặp lại và tăng dần, như được phản ánh trong mô hình
cây tiến hóa (Phần 2.2) hoặc mô hình lặp và tăng dần (Phần 2.5).
2.10 So sánh các mô hình vòng đời

Chín mô hình vòng đời phần mềm khác nhau đã được xem xét với sự chú ý đặc biệt đến một số điểm mạnh và
điểm yếu của chúng. Nên tránh mô hình code-and-fi x (Phần 2.9.1). Mô hình thác nước (Phần 2.9.2) là
một đại lượng đã biết. Điểm mạnh của nó được hiểu rõ, và điểm yếu của nó cũng vậy. Mô hình tạo mẫu
nhanh (Phần 2.9.3) được phát triển nhằm khắc phục điểm yếu cụ thể được nhận thấy trong mô hình thác
nước, cụ thể là sản phẩm được giao có thể không phải là thứ khách hàng thực sự cần. Tuy nhiên, vẫn
chưa có đủ bằng chứng cho thấy cách tiếp cận này vượt trội hơn mô hình thác nước ở các khía cạnh khác.
Mô hình vòng đời nguồn mở đã cực kỳ thành công trong một số ít trường hợp khi được sử dụng để xây
dựng phần mềm cơ sở hạ tầng (Phần 2.9.4). Các quy trình linh hoạt (Phần 2.9.5) là một tập hợp các
phương pháp tiếp cận mới gây tranh cãi mà cho đến nay dường như có hiệu quả nhưng chỉ dành cho phần
mềm quy mô nhỏ.
Mô hình đồng bộ hóa và ổn định (Phần 2.9.6) đã được Microsoft sử dụng rất thành công, nhưng vẫn chưa
có bằng chứng nào về sự thành công tương đương trong các nền văn hóa doanh nghiệp khác.
Một giải pháp thay thế khác là sử dụng mô hình xoắn ốc (Phần 2.9.7), nhưng chỉ khi các nhà phát triển
được đào tạo đầy đủ về phân tích rủi ro và giải quyết rủi ro. Mô hình cây tiến hóa (Phần 2.2) và mô
hình lặp và tăng dần (Phần 2.5) gần nhất với cách sản xuất phần mềm trong thế giới thực. Một so sánh
tổng thể xuất hiện trong Hình 2.14.
Mỗi tổ chức phát triển phần mềm nên quyết định một mô hình vòng đời phù hợp với tổ chức đó, ban
quản lý, nhân viên và quy trình phần mềm của tổ chức đó.
HÌNH 2.14 So
Mô hình vòng đời Điểm mạnh Những điểm yếu
sánh các mô
Mô hình cây tiến hóa (Phần Mô hình chặt chẽ sản xuất phần
hình vòng
đời 2.2) mềm trong thế giới thực
được mô tả Tương đương với mô hình lặp và

tăng dần
trong chương
Mô hình vòng đời lặp lại và tăng dần Mô hình chặt chẽ sản xuất phần
này, bao gồm
(Phần 2.5) mềm trong thế giới thực
cả phần định
Nền tảng của Unifi ed
nghĩa từng mô hình. Quá trình
Mô hình vòng đời code-and-fi x (Phần Tốt cho các chương trình ngắn không Hoàn toàn không đạt yêu cầu đối với
2.9.1) cần bảo trì các chương trình không cần thiết
Mô hình vòng đời thác nước Cách tiếp cận kỷ luật Sản phẩm được giao có thể
(Phần 2.9.2) Điều khiển tài liệu không đáp ứng được nhu cầu của khách hàng
Mô hình vòng đời tạo mẫu nhanh Đảm bảo rằng hàng được giao Chưa được chứng minh vượt qua
(Phần 2.9.3) sản phẩm đáp ứng được nhu cầu của mọi nghi ngờ
khách hàng
Mô hình vòng đời nguồn mở Đã hoạt động rất tốt trong một số ít Khả năng ứng dụng hạn chế
(Phần 2.9.4) trường hợp Thường không hoạt động
Quy trình linh hoạt (Phần 2.9.5) Làm việc tốt khi yêu cầu của khách Dường như chỉ làm việc trên
hàng còn mơ hồ các dự án quy mô nhỏ

Nhu cầu của người dùng trong tương lai được đáp ứng
Mô hình vòng đời đồng bộ hóa và ổn Chưa được sử dụng rộng
định (Phần 2.9.6) Đảm bảo rằng các thành phần có rãi ngoại trừ tại
thể được tích hợp thành công Microsoft
Mô hình vòng đời xoắn ốc Rủi ro dẫn đến Chỉ có thể được sử dụng
(Phần 2.9.7) cho các sản phẩm nội bộ,
quy mô lớn
Các nhà phát triển phải có
năng lực phân tích rủi ro và

giải quyết rủi ro
và nên thay đổi mô hình vòng đời tùy thuộc vào các tính năng của sản phẩm cụ thể hiện
đang được phát triển. Một mô hình như vậy kết hợp các khía cạnh thích hợp của các mô
hình vòng đời khác nhau, tận dụng điểm mạnh và giảm thiểu điểm yếu của chúng.
chương Có sự khác biệt đáng kể giữa cách phát triển phần mềm trên lý thuyết (Phần 2.1) và cách phát triển phần
Ôn tập mềm trong thực tế. Nghiên cứu trường hợp nhỏ Winburg được sử dụng để giới thiệu mô hình cây tiến hóa
(Phần 2.2). Các bài học từ nghiên cứu trường hợp nhỏ này, đặc biệt là những thay đổi về yêu cầu, được
trình bày ở Phần 2.3. Sự thay đổi được thảo luận chi tiết hơn trong Phần 2.4, trong đó bài toán mục tiêu
chuyển động được trình bày bằng cách sử dụng nghiên cứu trường hợp nhỏ về Teal Tractors. Trong Phần 2.5,
tầm quan trọng của việc lặp lại và tăng dần trong công nghệ phần mềm trong thế giới thực được nhấn mạnh
và mô hình lặp lại và tăng dần được trình bày. Nghiên cứu trường hợp nhỏ của Winburg sau đó được xem
xét lại trong Phần 2.6 để minh họa sự tương đương của mô hình cây tiến hóa và mô hình lặp và tăng dần.
Trong Phần 2.7, điểm mạnh của mô hình lặp và tăng dần được trình bày, đặc biệt là nó cho phép chúng ta
giải quyết rủi ro sớm. Việc quản lý mô hình lặp và tăng dần được thảo luận trong Phần 2.8. Một số mô
hình vòng đời khác nhau hiện đã được mô tả, bao gồm mô hình vòng đời mã-và-fi (Phần 2.9.1), mô hình vòng
đời thác nước (Phần 2.9.2), mô hình vòng đời tạo mẫu nhanh (Phần 2.9.3), mô hình vòng đời nguồn mở (Phần
2.9.4), các quy trình linh hoạt (Phần 2.9.5), mô hình vòng đời đồng bộ hóa và ổn định (Phần 2.9.6) và
mô hình xoắn ốc mô hình vòng đời (Phần 2.9.7). Trong Phần 2.10, các mô hình vòng đời này được so sánh và
đưa ra các đề xuất liên quan đến việc lựa chọn mô hình vòng đời cho một dự án cụ thể.
Vì Mô hình thác nước lần đầu tiên được đưa ra vào năm [Royce, 1970]. Một phân tích về mô hình thác nước được đưa ra
Hơn nữa trong chương đầu tiên của [Royce, 1998].
Mô hình đồng bộ hóa và ổn định được phác thảo trong [Cusumano và Selby, 1997] và được mô tả chi tiết
Đọc trong [Cusumano và Selby, 1995]. Mô hình xoắn ốc được giải thích trong [Boehm, 1988], và ứng dụng của nó
vào Hệ thống Năng suất Phần mềm TRW xuất hiện trong [Boehm và cộng sự, 1984].
Lập trình cực đoan được mô tả trong [Beck, 2000]; tái cấu trúc là chủ đề của [Fowler et al., 1999].
Tuyên ngôn về Phát triển phần mềm linh hoạt có thể được tìm thấy tại [Beck và cộng sự, 2001]. Sách đã
được xuất bản về nhiều phương pháp linh hoạt, bao gồm [Cockburn, 2001] và [Schwaber, 2001]. Các phương
pháp linh hoạt được ủng hộ trong [Highsmith và Cockburn, 2001], [Boehm, 2002], [DeMarco và Boehm, 2002],
và [Boehm và Turner, 2003], trong khi trường hợp chống lại các phương pháp linh hoạt được trình bày trong
[Stephens và Rosenberg, 2003]. Tái cấu trúc được khảo sát trong [Mens và Tourwe, 2004]. Việc sử dụng XP
trong bốn dự án quan trọng được mô tả trong [Drobka, Noftz và Raghu, 2004]. Các vấn đề có thể phát sinh
khi giới thiệu các quy trình linh hoạt trong một tổ chức hiện đang sử dụng các phương pháp truyền thống
được thảo luận trong [Nerur, Mahapatra, và Mangalaraj, 2005] và trong [Boehm và Turner, 2005].
Một số bài viết về lập trình cực đoan xuất hiện trên tạp chí IEEE Soft- số tháng 5-tháng 6 năm 2003 ,
đồ bao gồm [Murru, Deias, và Mugheddu, 2003] và [Rasmusson, 2003], cả hai đều mô tả các dự án thành
công được phát triển bằng cách sử dụng lập trình cực đoan. Tạp chí IEEE Computer số tháng 6 năm 2003
chứa một số bài viết về các quy trình linh hoạt. Số tháng 5-tháng 6 năm 2005 của IEEE Software có bốn bài viết
về các quy trình linh hoạt, đặc biệt là [Ceschi, Sillitti, Succi, và De Panfi lis, 2005] và [Karlström và
Runeson, 2005]. Mức độ mà các phương pháp linh hoạt được sử dụng trong ngành công nghiệp phần mềm được phân tích
trong [Hansson, Dittrich, Gustafsson và Zarnak, 2006]. Một cuộc khảo sát về các yếu tố thành công quan trọng
trong các sản phẩm phần mềm linh hoạt được trình bày trong [Chow và Cao, 2008]. Các phương pháp tiếp cận để hỗ
trợ quá trình chuyển đổi sang các phương pháp linh hoạt được đưa ra trong [Qumer và Henderson-Sellers, 2008].
Tái cấu trúc đặt ra vấn đề cho các công cụ quản lý cấu hình phần mềm; một giải pháp được đưa ra trong [Dig,
Manzoor, Johnson, và Nguyen, 2008].
Kiểm thử linh hoạt một sản phẩm phần mềm quy mô lớn được mô tả trong [Talby, Keren, Hazzan và Dubin-
sky, 2006]. Hiệu quả của sự phát triển dựa trên thử nghiệm được thảo luận trong [Erdogmus, Morisio và
Torchiano, 2005]. Số tháng 5-tháng 6 năm 2007 của IEEE Software có nhiều bài viết khác nhau về phát triển
dựa trên thử nghiệm, bao gồm [Martin, 2007].
Phân tích rủi ro được mô tả trong [Ropponen và Lyttinen, 2000], [Longstaff, Chittister, Pethia, và
Haimes, 2000] và [Scott và Vessey, 2002]. Quản lý rủi ro trong phát triển phần mềm ra nước ngoài được
trình bày trong [Sakthivel, 2007] và [Iacovou và Nakatsu, 2008]. Quản lý rủi ro khi phần mềm được phát
triển bằng cách sử dụng các thành phần COTS được mô tả trong [Li et al., 2008].
Một mô hình lặp lại và tăng dần chính được mô tả chi tiết trong [Jacobson, Booch, và Rumbaugh, 1999].
Tuy nhiên, nhiều mô hình lặp lại và gia tăng khác đã được đưa ra trong 30 năm qua, như được kể lại trong
[Larman và Basili, 2003]. Việc sử dụng mô hình gia tăng để xây dựng hệ thống kiểm soát không lưu được
thảo luận trong [Goth, 2000]. Một cách tiếp cận lặp đi lặp lại để tái thiết kế các hệ thống cũ được đưa
ra trong [Bianchi, Caivano, Marengo và Visaggio, 2003]. Một công cụ hỗ trợ phát triển phần mềm tăng dần
trong khi vẫn đảm bảo rằng các tạo phẩm phát triển một cách nhất quán được mô tả trong [Reiss, 2006].
Nhiều mô hình vòng đời khác đã được đưa ra. Ví dụ, Rajlich và Bennett [2000] mô tả mô hình vòng đời
hướng tới bảo trì. Số tháng 7-tháng 8 năm 2000 của IEEE Software có nhiều bài viết về mô hình vòng đời
phần mềm, bao gồm [Williams, Kessler, Cunningham, và Jeffries, 2000] mô tả một thử nghiệm về lập trình
cặp, một thành phần của các phương pháp linh hoạt.
Rajlich [2006] đi xa hơn và gợi ý rằng nhiều chủ đề của chương này đã dẫn chúng ta đến một
mô hình mới cho công nghệ phần mềm.
Kỷ yếu của Hội thảo Quy trình Phần mềm Quốc tế là nguồn thông tin hữu ích về các mô hình vòng đời.
[ISO/IEC 12207, 1995] là tiêu chuẩn được chấp nhận rộng rãi cho các quy trình vòng đời phần mềm.
tăng 44 yêu cầu quy trình làm việc 44

Thuật ngữ chính quy trình linh hoạt 60
quy trình phân tích 44 lặp 44 rủi ro 50
kiến trúc 49 mô hình vòng đời lặp đi lặp độ bền 49
hiện vật 41 lại và tăng dần 44 mô hình vòng đời xoắn ốc 63

đường cơ sở 41 mô hình vòng đời 40 ổn định 62
code-and-fi x mô hình vòng Định luật Miller 44 cuộc họp độc lập 60
đời 52 giảm thiểu rủi ro 63 cải tiến từng bước 44
nhóm nòng cốt 57 mô hình 40 câu chuyện 59
quy trình làm việc cốt lõi 44 bài toán mục tiêu chuyển động 43 đồng bộ hóa 62
quy trình thiết kế 44 phần mềm nguồn mở 56 mô hình vòng đời đồng bộ hóa
mô hình vòng đời cây tiến lập trình cặp 59 và ổn định 62

hóa 40 nhóm ngoại vi 57 nhiệm vụ 59
lập trình cực đoan 59 nguyên mẫu chứng minh khái niệm 63 phát triển dựa trên thử nghiệm 59
báo cáo lỗi 57 nguyên mẫu nhanh 55 kiểm tra quy trình làm việc 44
báo lỗi 57 mô hình vòng đời tạo mẫu nhanh hộp thời gian 60
tính năng leo 43 55 mô hình vòng đời thác nước 41

đóng băng 62 tái cấu trúc 60 quy trình làm việc 44
quy trình triển khai 44 lỗi hồi quy 43
Vấn đề 2.1 Trình bày nghiên cứu trường hợp nhỏ của Winburg ở Phần 2.2 và 2.3 bằng mô hình thác nước. Có pha i đây là
hiệu quả hơn hay ít hơn mô hình cây tiến hóa? Gia i thich câu tra lơi cu a ba n.
2.2 Giả sử rằng người lập trình trong nghiên cứu trường hợp nhỏ ở Winburg đã sử dụng các số có độ chính xác đơn
từ đầu. Vẽ cây tiến hóa kết quả.
2.3 Mối liên hệ giữa Định luật Miller và việc cải tiến từng bước là gì?
2.4 Việc tinh chỉnh từng bước có tương ứng với việc lặp lại hoặc tăng dần không?
2.5 Quy trình công việc, tạo phẩm và đường cơ sở có liên quan như thế nào?
2.6 Mối liên hệ giữa mô hình thác nước và mô hình lặp và tăng dần là gì?
2.7 Giả sử bạn phải xây dựng một tích số để xác định căn bậc ba của 9384,2034 đến bốn chữ số thập phân. Một khi sản
phẩm đã được triển khai và thử nghiệm, nó sẽ bị vứt đi. Bạn sẽ sử dụng mô hình vòng đời nào? Đưa ra lý do cho
câu trả lời của bạn.
2.8 Bạn là nhà tư vấn kỹ thuật phần mềm và được phó chủ tịch mời đến phụ trách tài chính cho một tập đoàn sản xuất
lốp xe và bán chúng thông qua chuỗi cửa hàng bán lẻ lớn. Cô ấy muốn tổ chức của bạn xây dựng một sản phẩm có
thể giám sát hàng tồn kho của công ty, bắt đầu bằng việc mua nguyên liệu thô và theo dõi lốp xe khi chúng được
sản xuất, phân phối đến các cửa hàng riêng lẻ và bán cho khách hàng. Bạn sẽ sử dụng tiêu chí nào khi lựa chọn
mô hình vòng đời cho dự án?
2.9 Liệt kê các rủi ro liên quan đến việc phát triển phần mềm của Bài toán 2.8. Bạn sẽ cố gắng giảm thiểu từng rủi
ro như thế nào?
2.10 Việc phát triển sản phẩm kiểm soát hàng tồn kho cho công ty lốp xe của bạn thành công đến mức tổ chức của bạn
quyết định rằng sản phẩm này phải được triển khai lại dưới dạng trọn gói để bán cho nhiều tổ chức khác nhau
sản xuất và bán sản phẩm thông qua các nhà bán lẻ của chính họ. Do đó, sản phẩm mới phải có tính di động và
dễ dàng thích ứng với phần cứng và/hoặc hệ điều hành mới.
Các tiêu chí mà bạn sử dụng khi lựa chọn mô hình vòng đời cho dự án này khác với các tiêu chí trong câu trả
lời của bạn cho Vấn đề 2.8 như thế nào?
2.11 Mô tả loại sản phẩm sẽ là ứng dụng lý tưởng cho phần mềm nguồn mở
phát triển.
2.12 Bây giờ hãy mô tả loại tình huống trong đó việc phát triển phần mềm nguồn mở là không phù hợp.
2.13 Mô tả loại sản phẩm sẽ là ứng dụng lý tưởng cho quy trình linh hoạt.
2.14 Bây giờ hãy mô tả loại tình huống trong đó quy trình linh hoạt không phù hợp.
2.15 Mô tả loại sản phẩm sẽ là ứng dụng lý tưởng cho mô hình vòng đời xoắn ốc.
2.16 Bây giờ hãy mô tả loại tình huống mà mô hình vòng đời xoắn ốc không phù hợp.
2.17 Mô tả rủi ro cố hữu khi sử dụng mô hình vòng đời thác nước.
2.18 Mô tả rủi ro cố hữu khi sử dụng mô hình vòng đời mã và sửa chữa.
2.19 Mô tả rủi ro cố hữu khi sử dụng mô hình vòng đời nguồn mở.
2.20 Mô tả rủi ro cố hữu khi sử dụng các quy trình linh hoạt.
2.21 Mô tả rủi ro cố hữu khi sử dụng mô hình vòng đời xoắn ốc.
2.22 (Dự án dài hạn) Bạn sẽ sử dụng mô hình vòng đời phần mềm nào cho Chocoholics Anonymous
sản phẩm được mô tả trong Phụ lục A? Đưa ra lý do cho câu trả lời của bạn.
2.23 (Bài đọc về Kỹ thuật phần mềm) Người hướng dẫn của bạn sẽ phân phát bản sao của [Rajlich, 2006]. Bạn có đồng ý
rằng công nghệ phần mềm đã bắt tay vào một mô hình mới không? Gia i thich câu tra lơi cu a ba n.
Tài liệu tham khảo [Arisholm, Gallis, Dybå, và Sjøberg, 2007] E. ARISHOLM, H. GALLIS, T. DYBÅ, VÀ DIK SJØBERG, “Đánh giá lập trình cặp liên
quan đến độ phức tạp của hệ thống và chuyên môn của lập trình viên,”
Giao dịch của IEEE về Kỹ thuật phần mềm 33 (tháng 2 năm 2007), trang 65–86.
[Beck, 2000] K. BECK, Giải thích về lập trình cực đoan: Chấp nhận sự thay đổi, Addison-Wesley
Longman, Reading, MA, 2000.
[Beck và cộng sự, 2001] K. BECK, M. BEEDLE, A. COCKBURN, W. CUNNINGHAM , M. FOWLER, J. GRENNING, J. HIGHSMITH, A.
HUNT, R. JEFFRIES, J. KERN, B. MARICK, RC MARTIN, S. MELLOR, K. SCHWABER, J. SUTHERLAND, D. THOMAS, VÀ A. VAN
BENNEKUM, Tuyên ngôn về Phát triển Phần mềm Linh hoạt , Agilemanifesto.org, 2001.
[Bianchi, Caivano, Marengo, và Visaggio, 2003] A. BIANCHI, D. CAIVANO, V. MARENGO, AND

G. VISAGGIO, “Tái cấu trúc lặp đi lặp lại các hệ thống kế thừa,” Giao dịch của IEEE về Kỹ thuật phần mềm 29
(tháng 3 năm 2003), trang 225–41.
[Boehm, 1988] BW BOEHM, “Mô hình xoắn ốc về phát triển và cải tiến phần mềm,” IEEE
Máy tính 21 (tháng 5 năm 1988), trang 61–72.
[Boehm, 2002] BW BOEHM, “Hãy sẵn sàng cho các phương pháp linh hoạt và cẩn thận,” IEEE Computer 35 (Tháng 1
2002), trang 64–69.
[Boehm và Turner, 2003] B. BOEHM VÀ R. TURNER, Cân bằng sự nhanh nhẹn và kỷ luật: Hướng dẫn cho
Lúng túng , Addison-Wesley Professional, Boston, MA, 2003.
[Boehm và Turner, 2005] B. BOEHM VÀ R. TURNER, “Những thách thức của quản lý đối với việc triển khai các quy trình
linh hoạt trong các tổ chức phát triển truyền thống,” IEEE Software 22 (Tháng 9–
tháng 10 năm 2005), trang 30–39.
[Boehm và cộng sự, 1984] BW BOEHM, MH PENEDO, ED STUCKLE, RD WILLIAMS, AND AB PYSTER, “Môi trường phát triển phần
mềm để cải thiện năng suất,” IEEE Computer 17 (tháng 6 năm 1984), trang 30–44.
[Booch, 2000] G. BOOCH, “Tương lai của Kỹ thuật phần mềm,” bài phát biểu chính, Quốc tế
Hội nghị về Kỹ thuật phần mềm, Limerick, Ireland, tháng 5 năm 2000.
[Ceschi, Sillitti, Succi, và De Panfi lis, 2005] M. CESCHI, A. SILLITTI, G. SUCCI, AND S. DE PANFILIS, “Quản lý dự
án trong các công ty linh hoạt và dựa trên kế hoạch,” IEEE Software 22 (Tháng 5– tháng 6 năm 2005), trang 21–27.
[Chow và Cao, 2008] T. CHOW VÀ D.-B. CAO, “Nghiên cứu khảo sát về các yếu tố thành công quan trọng trong các
dự án phần mềm linh hoạt,” Tạp chí Hệ thống và Phần mềm 81 (tháng 6 năm 2008), trang 961–71.
[Cockburn, 2001] A. COCKBURN, Phát triển phần mềm linh hoạt , Addison-Wesley Professional, Read-
ing, MA, 2001.
[Cusumano và Selby, 1995] MA CUSUMANO VÀ RW SELBY, Bí mật của Microsoft: Công ty phần mềm mạnh nhất thế giới
tạo ra công nghệ, định hình thị trường và quản lý con người như thế nào , The Free Press/Simon và Schuster,
New York, 1995.
[Cusumano và Selby, 1997] MA CUSUMANO VÀ RW SELBY, “Microsoft xây dựng phần mềm như thế nào,”
Thông tin của ACM 40 (tháng 6 năm 1997), trang 53–61.
[DeMarco và Boehm, 2002] T. DEMARCO VÀ B. BOEHM, “Cuộc xung đột về các phương pháp linh hoạt,” IEEE Com-
puter 35 (tháng 6 năm 2002), trang 90–92.
[Dig, Manzoor, Johnson và Nguyen, 2008] D. DIG, K. MANZOOR, RE JOHNSON, VÀ TN NGUYEN, “Hợp nhất phần mềm hiệu
quả trong sự hiện diện của tái cấu trúc hướng đối tượng,” Giao dịch IEEE về Kỹ thuật phần mềm 34 ( Tháng 5–
[Drobka, Noftz, và Raghu, 2004] J. DROBKA, D. NOFTZ, AND R. RAGHU, “Thí điểm XP trên bốn dự án quan trọng”,
IEEE Software 21 (Tháng 11–Tháng 12 năm 2004), trang 70–75.
[Dybå và cộng sự, 2007] T. DYBÅ, E. ARISHOLM, DIK SJØBERG, JE HANNAY, VÀ F. SHULL, “Hai cái đầu có tốt hơn
một không? Về hiệu quả của lập trình cặp,” Phần mềm IEEE 24
(Tháng 11–Tháng 12 năm 2007), trang 12–15.
[Erdogmus, Morisio, và Torchiano, 2005] H. ERDOGMUS, M. MORISIO, VÀ M. TORCHIANO, “Về hiệu quả của phương pháp
tiếp cận thử nghiệm đầu tiên đối với lập trình,” Giao dịch của IEEE về Kỹ thuật phần mềm 31 (Tháng 3 năm
2005), trang 226–37.
[Fowler và cộng sự, 1999] M. FOWLER với K. BECK, J. BRANT, W. OPDYKE, VÀ D. ROBERTS, Tái cấu trúc:
Cải thiện thiết kế mã hiện có , Addison-Wesley, Reading, MA, 1999.
[Goth, 2000] G. GOTH, “Phần mềm kiểm soát không lưu mới có cách tiếp cận tăng dần,” IEEE Software 17 (Tháng 7–
[Hansson, Dittrich, Gustafsson và Zarnak, 2006] C. HANSSON, Y. DITTRICH, B. GUSTAFSSON, AND

S. ZARNAK, “Thực tiễn phát triển phần mềm công nghiệp linh hoạt như thế nào?” Tạp chí Hệ thống và Phần mềm
79 (tháng 9 năm 2006), trang 1217–58.
[Hayes, 2004] F. HAYES, “Hỗn loạn đã trở lại,” Computerworld , www.computerworld.com/
managementtopics/management/project/story/0,10801,97283,00.html, ngày 8 tháng 11 năm 2004.
[Highsmith và Cockburn, 2001] J. HIGHSMITH AND A. COCKBURN, “Phát triển phần mềm linh hoạt: Công việc đổi mới,”
IEEE Computer 34 (tháng 9 năm 2001), trang 120–22.
[Iacovou và Nakatsu, 2008] CL IACOVOU VÀ R. NAKATSU, “Hồ sơ rủi ro của việc thuê ngoài nước ngoài
Dự án Phát triển,” Truyền thông của ACM 51 (tháng 6 năm 2008) trang 89–94.
[ISO/IEC 12207, 1995] “ISO/IEC 12207:1995, Công nghệ thông tin—Quy trình vòng đời phần mềm,” Tổ chức Tiêu
chuẩn hóa Quốc tế, Ủy ban Kỹ thuật Điện Quốc tế, Geneva, 1995.
[Jacobson, Booch, và Rumbaugh, 1999] I. JACOBSON, G. BOOCH, VÀ J. RUMBAUGH, Quy trình phát triển phần mềm của
Unifi ed , Addison-Wesley, Reading,MA, 1999.
[Jalote, Palit, Kurien và Peethamber, 2004] P. JALOTE, A. PALIT, P. KURIEN, AND VT PEETHAMBER, “ Timeboxing: A
Process Model for Iterative Software Development,” Journal of Systems and Software 70 (Tháng 2 năm 2004) ,
trang 117–27.
[Karlström và Runeson, 2005] D. KARLSTRÖM VÀ P. RUNESON, “Kết hợp các phương pháp linh hoạt với quản lý dự án
theo giai đoạn,” IEEE Software 22 (tháng 5–tháng 6 năm 2005), trang 43–49.
[Larman và Basili, 2003] C. LARMAN VÀ VR BASILI, “Phát triển lặp lại và tăng dần: A
Tóm tắt lịch sử,” IEEE Computer 36 (tháng 6 năm 2003), trang 47–56.
[Li và Alshayeb, 2002] W. LI VÀ M. ALSHAYEB, “Nghiên cứu thực nghiệm về nỗ lực XP,” Kỷ yếu của Diễn đàn quốc tế lần
thứ 17 về COCOMO và mô hình hóa chi phí phần mềm , Los Angeles, tháng 10 năm 2002, IEEE.
[Li và cộng sự, 2008] J. LI, OPN SLYNGSTAD, M. TORCHIANO, M. MORISIO, VÀ C. BUNSE, “Khảo sát thực tiễn về quản lý
rủi ro trong phát triển với phần mềm có sẵn Các thành phần,” Giao dịch IEEE về Kỹ thuật phần mềm 34 (tháng 3–
[Longstaff, Chittister, Pethia, và Haimes, 2000] TA LONGSTAFF, C. CHITTISTER, R. PETHIA, AND

YY HAIMES, “Có phải chúng ta đang quên đi những rủi ro của công nghệ thông tin?” Máy tính IEEE 33
(Tháng 12 năm 2000), trang 43–51.
[Martin, 2007] RC MARTIN, “Tính chuyên nghiệp và phát triển dựa trên thử nghiệm,” Phần mềm IEEE 24
(tháng 5–tháng 6 năm 2007), trang 32–36.
[Mens và Tourwe, 2004] T. MENS VÀ T. TOURWE, “Khảo sát về tái cấu trúc phần mềm,” IEEE Trans-
hành động về Kỹ thuật phần mềm 30 (tháng 2 năm 2004), trang 126–39.
[Miller, 1956] GA MILLER, “Con số bảy huyền diệu, cộng hoặc trừ hai: Một số giới hạn về khả năng xử lý thông tin
của chúng ta,” Tạp chí tâm lý học 63 (tháng 3 năm 1956), trang 81–97; được in lại tại: www.well.com/user/smalin/
miller.html.
[Murru, Deias, và Mugheddu, 2003] O. MURRU, R. DEIAS, VÀ G. MUGHEDDU, “Đánh giá XP ở một mức độ
Công ty Internet Châu Âu,” IEEE Software 20 (tháng 5–tháng 6 năm 2003), trang 37–43.
[Nerur, Mahapatra và Mangalaraj, 2005] S. NERUR, R. MAHAPATRA, VÀ G. MANGALARAJ, “Những thách thức khi chuyển sang
các phương pháp linh hoạt,” Truyền thông của ACM 48
(tháng 5 năm 2005), trang 72–78.
[Qumer và Henderson-Sellers, 2008] A. QUMER AND B. HENDERSON-SELLERS, “Khuôn khổ hỗ trợ đánh giá, áp dụng và cải
tiến các phương pháp linh hoạt trong thực tế,” Tạp chí Hệ thống và Phần mềm 81 (tháng 11 năm 2008), trang. 1899–
1919.
[Rajlich, 2006] V. RAJLICH, “Thay đổi mô hình công nghệ phần mềm,” Truyền thông của
ACM 49 (tháng 8 năm 2006), trang 67–70.
[Rajlich và Bennett, 2000] V. RAJLICH VÀ KH BENNETT, “Mô hình theo giai đoạn cho Đời sống Phần mềm
Cycle,” IEEE Computer 33 (tháng 7 năm 2000), trang 66–71.
[Rasmusson, 2003] J. RASMUSSON, “Giới thiệu XP vào các dự án ở Greenfi: Bài học kinh nghiệm,”
IEEE Software 20 (tháng 5–tháng 6 năm 2003), trang 21–29.
[Raymond, 2000] ES RAYMOND, Nhà thờ và chợ: Suy nghĩ về Linux và Nguồn mở của một nhà cách mạng tình cờ , O'Reilly
& Associates, Sebastopol, CA, 2000; cũng có tại www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/.
[Reifer, Maurer, và Erdogmus, 2003] D. REIFER, F. MAURER, VÀ H. ERDOGMUS, “Các phương pháp linh hoạt mở rộng quy
mô,” IEEE Software 20 (Tháng 7–tháng 8 năm 2004), trang 12–14.
[Reiss, 2006] SP REISS, “Bảo trì gia tăng các tạo phẩm phần mềm,” Giao dịch của IEEE trên
Kỹ thuật phần mềm 32 (tháng 9 năm 2006), trang 682–97.
[Ropponen và Lyttinen, 2000] J. ROPPONEN VÀ K. LYTTINEN, “Các thành phần của rủi ro phát triển phần mềm: Làm thế
nào để giải quyết chúng? Khảo sát của người quản lý dự án,” Giao dịch của IEEE về Kỹ thuật phần mềm 26 (tháng 2
năm 2000), trang 96–111.
[Royce, 1970] WW ROYCE, “Quản lý sự phát triển của các hệ thống phần mềm lớn: Khái niệm và kỹ thuật,” 1970 Tài liệu
kỹ thuật WESCON, Triển lãm và Hội nghị điện tử phương Tây Los Angeles, tháng 8 năm 1970, trang A/1-1–A/1- 9; in ,
lại trong: Kỷ yếu của Hội nghị Quốc tế về Kỹ thuật Phần mềm lần thứ 11 , Pittsburgh, tháng 5 năm 1989, IEEE,
trang 328–38.
[Royce, 1998] W. ROYCE, Quản lý dự án phần mềm: Khung thống nhất , Addison-Wesley,
Đọc, MA, 1998.
[Rubenstein, 2007] D. RUBENSTEIN, “Báo cáo của Nhóm tiêu chuẩn: Ngày nay ít sự hỗn loạn trong phát
triển hơn,” www.sdtimes.com/content/article.aspx?ArticleID=30247, ngày 1 tháng 3 năm 2007.
[Sakthivel, 2007] S. SAKTHIVEL, “Quản lý rủi ro trong phát triển hệ thống ngoài khơi,” Truyền thông
của ACM 50 (tháng 4 năm 2007), trang 69–75.
[Schwaber, 2001] K. SCHWABER, Phát triển phần mềm linh hoạt với Scrum , Hội trường Prentice, Thượng
Sông Saddle, NJ, 2001.
[Scott và Vessey, 2002] JE SCOTT AND I. VESSEY, “Quản lý rủi ro trong triển khai hệ thống doanh
nghiệp,” Truyền thông của ACM 45 (tháng 4 năm 2002), trang 74–81.
[Softwaremag.com, 2004] “Standish: Tỷ lệ thành công của dự án được cải thiện trong 10 năm,” www.
softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish, ngày 15 tháng 1 năm 2004.
[Spivey, 1992] JM SPIVEY, Ký hiệu Z: Cẩm nang tham khảo [Standish, , Hội trường Prentice, New York, 1992.
2003] STANDISH GROUP INTERNATIONAL, “Giới thiệu,” www.standishgroup.com/

hỗn loạn/giới thiệu.pdf, 2003.
[Stephens và Rosenberg, 2003] M. STEPHENS VÀ D. ROSENBERG, Tái cấu trúc lập trình cực đoan: Vụ kiện
chống lại XP , Apress, Berkeley, CA, 2003.
[Talby, Keren, Hazzan, và Dubinsky, 2006] D. TALBY, A. KEREN, O. HAZZAN, VÀ Y. DUBINSKY, “Kiểm thử
phần mềm linh hoạt trong một dự án quy mô lớn,” IEEE Software 23 (Tháng 7–Tháng 8 năm 2006) ,
trang 30–37.
[Tomer và Schach, 2000] A. TOMER AND SR SCHACH, “Cây tiến hóa: Mô hình phát triển phần mềm hướng
đến bảo trì,” trong: Kỷ yếu của Hội nghị châu Âu lần thứ tư về bảo trì và tái cấu trúc phần mềm
(CSMR 2000) , Zürich, Thụy Sĩ, Tháng 2/tháng 3 năm 2000, ACM, trang 209–14.
[Williams, Kessler, Cunningham, và Jeffries, 2000] L. WILLIAMS, RR KESSLER, W. CUNNINGHAM, AND R.

JEFFRIES, “Tăng cường trường hợp lập trình cặp,” IEEE Software 17 (Tháng 7 – tháng 8 năm 2000),
trang 19 –25.

Chương 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chương 2

Uploaded by

Copyright:

Available Formats

Machine Translated by Google

Vòng đời phần mềm

Mục tiêu học tập

Sau khi nghiên cứu chương này, bạn sẽ có thể

Hiểu mô hình vòng đời cây tiến hóa. • Đánh giá

Sử dụng mô hình vòng đời lặp đi lặp lại và tăng dần. •

2.1 Phát triển phần mềm về mặt lý thuyết

Chỉ trong trường hợp bạn muốn biết Hộp 2.1

Chương 2 Mô hình vòng đời phần mềm 39

40 Phần A Khái niệm Kỹ thuật Phần mềm

Yêu cầu1 Yêu cầu4

Phân tích1 Phân tích4

Thiết kế1 Thiết kế3 Thiết kế4

Thực hiện1 Thực hiện2 Thực hiện3 Thực hiện4

Tập 1 Tập 2 Tập 3 Tập 4

phản hồi và độ chính xác.

tả trước đây, các thử

bằng một đường chấm. 2 .

dụng cho mô hình mini

Chương 2 Mô hình vòng đời phần mềm 41

HÌNH 2.3 Một

vòng đời thác nước.

Cuối Tập 1: Yêu cầu 1 , Phân tích1 , Thiết kế 1, Thực hiện 1

Cuối Tập 2: Yêu cầu 1, Phân tích1, Thiết kế 1, Thực hiện 2

Cuối Tập 3: Yêu cầu 1, Phân tích1, Thiết kế 3, Thực hiện 3

Cuối Tập 4: Yêu cầu 4, Phân tích4, Thiết kế 4, Thực hiện 4

triển khai đã được sửa đổi (nhưng chưa bao giờ

42 Phần A Khái niệm kỹ thuật phần mềm

2.3 Bài học từ nghiên cứu điển hình nhỏ ở Winburg

khách hàng thực hiện (nhu cầu tăng độ chính xác).

Nghiên cứu nhỏ C

2.4 Nghiên cứu tình huống nhỏ về máy kéo Teal

ently ở Canada, chẳng hạn như thuế.

3. Nó phải được mở rộng để xử lý hai loại tiền tệ khác nhau, đô la Mỹ và Canada

Chương 2 Mô hình vòng đời phần mềm 43

khăn như nhau.

phẩm phần mềm.

2.5 Lặp lại và tăng dần

44 Phần A Khái niệm kỹ thuật phần mềm

Chương 2 Mô hình vòng đời phần mềm 45

Tăng A Tăng B Tăng C Tăng D

Bài kiểm tra

quy trình làm việc

46 Phần A Khái niệm kỹ thuật phần mềm

HÌNH 2.5 Ba Tăng B

tăng dần trong

quy trình làm việc

Bài kiểm tra

quy trình làm việc

bao gồm các yêu cầu,

Chương 2 Mô hình vòng đời phần mềm 47

năm quy trình công việc đều đạt yêu cầu.

Nghiên cứu nhỏ C

Tăng A Tăng B Tăng C Tăng D

Yêu cầu Yêu cầu1

Tập 1 Tập 2 Tập 3 Tập 4

48 Phần A Khái niệm Kỹ thuật Phần mềm

trình triển khai chưa được thực hiện. 2

2.7 Rủi ro và các khía cạnh khác của việc

Chương 2 Mô hình vòng đời phần mềm 49

Mô hình lặp và tăng dần có nhiều điểm mạnh:

50 Phần A Khái niệm Kỹ thuật Phần mềm

Chỉ trong trường hợp bạn muốn biết Hộp 2.2