Chương 3 quy trình phát triển phần mềm

Chương 3: Quy trình phát triển phần mềm

Mục tiêu mơn học

 Giải thích được tại sao mơ hình vịng đời hai chiều lại quan trọng
 Mơ tả năm quy trình làm việc cốt lõi của quy trình hợp nhất
 Liệt kê các vật được thử nghiệm trong quy trình thử nghiệm
 Mơ tả bốn giai đoạn của quy trình hợp nhất
 Mơ tả sự khác nhau giữa quy trình làm việc và các giai đoạn của quy trình hợp nhất
 Đánh giá cao tầm quan trọng của việc cải tiến quy trình làm phần mềm
 Mơ tả mơ hình năng lực trưởng thành

Quy trình phát triển phần mềm là cách mà chúng tơi sản xuất phần mềm. Nó kết hợp phương pháp
luận (Phần 1.11) với mơ hình vịng đời phần mềm cơ bản (Chương 2) cộng với các kỹ thuật, các công cụ
chúng tôi sử dụng (Phần 5.6 đến 5.12) và quan trọng nhất là các cá nhân xây dựng phần mềm. Các tổ
chức khác nhau có các quy trình phần mềm khác nhau. Ví dụ, hãy xem xét vấn đề tài liệu. Một số tổ chức
coi phần mềm mà họ sản xuất là tài liệu tự lập; có nghĩa là, sản phẩm có thể được hiểu một cách đơn
giản bằng cách đọc mã nguồn. Các tổ chức khác, tuy nhiên, tài liệu chuyên sâu. Họ tạo ra một cách
nhanh chóng các trích dẫn cụ thể và kiểm tra chúng một cách có phương pháp. Sau đó, họ thực hiện các
hoạt động thiết kế một cách cẩn thận, kiểm tra và kiểm tra lại thiết kế của họ trước khi bắt đầu mã hóa
và đưa ra mơ tả của mỗi khối mã cho các lập trình viên. Các trường hợp thử nghiệm được lập kế hoạch
trước, kết quả của mỗi lần chạy thử nghiệm được ghi lại và dữ liệu thử nghiệm được trích dẫn một cách
tỉ mỉ. Một khi sản phẩm đã được phân phối và cài đặt trên máy tính của khách hàng, mọi thay đổi được
đề xuất phải được đề xuất bằng văn bản kèm theo lý do chi tiết để thực hiện thay đổi. Thay đổi được đề
xuất có thể chỉ được thực hiện khi có ủy quyền bằng văn bản và việc sửa đổi khơng được tích hợp vào
sản phẩm cho đến khi tài liệu đã được cập nhật và các thay đổi đối với tài liệu được chấp thuận.

Tại sao quy trình phát triển phần mềm lại khác nhau rất nhiều giữa các tổ chức? Một lý do chính là
thiếu kỹ năng trong kỹ thuật phần mềm. Quá nhiều nhiều chuyên gia phần mềm chỉ đơn giản là không
chịu cập nhật. Họ tiếp tục phát triển phần mềm Ye Olde Fashioned Way(phần mềm lỗi thời) , bởi vì họ
khơng còn cách nào khác. Một lý do khác cho sự khác biệt trong quy trình phát triển phần mềm là nhiều

nhà quản lý phần mềm là những nhà quản lý xuất sắc nhưng lại biết rất ít về phát triển hoặc bảo trì phần
mềm. Sự thiếu hiểu biết về kỹ thuật của họ có thể dẫn đến việc dự án bị chậm tiến độ . Điều này thường
xuyên là lý do tại sao nhiều dự án phần mềm không bao giờ được hoàn thành.

Tuy nhiên, một lý do khác cho sự khác biệt giữa các quy trình là triển vọng quản lý. Ví dụ, một tổ chức
có thể quyết định rằng tốt hơn hết là nên cung cấp sản phẩm đúng hạn, ngay cả khi sản phẩm đó khơng
được kiểm tra đầy đủ. Với những trường hợp giống hệt nhau, một tổ chức khác có thể kết luận rằng rủi
ro của việc phân phối sản phẩm đó mà khơng có thử nghiệm toàn diện sẽ lớn hơn nhiều so với việc dành
thời gian để kiểm tra sản phẩm một cách kỹ lưỡng và do đó trễ thời gian hồn thành sản phẩm.

Cường độ thử nghiệm là một thước đo khác để so sánh các tổ chức với nhau. Một số các tổ chức dành
tới một nửa ngân sách để kiểm tra phần mềm, trong khi những tổ chức khác cảm thấy rằng chỉ người

dùng mới có thể kiểm tra kỹ lưỡng một sản phẩm. Do đó, một số cơng ty bỏ ít thời gian và công sức để
thử nghiệm sản phẩm nhưng dành một lượng thời gian đáng kể để sưa chữa sự cố do người dùng báo
cáo. Bảo trì sau giao hàng là mối bận tâm lớn của nhiều tổ chức phần mềm. Phần mềm 10, 15 hoặc
thậm chí 20 năm tuổi liên tục được cải tiến để đáp ứng sự thay đổi nhu cầu. Ngồi ra, các lỗi cịn sót lại
tiếp tục xuất hiện, ngay cả sau khi phần mềm đã được bảo trì thành cơng trong nhiều năm. Hầu hết tất
cả các tổ chức chuyển phần mềm của họ sang phần cứng mới mỗi 3 đến 5 năm, điều này cũng taọ ra
việc bảo trì sau khi đã giao hàng. Ngược lại, các tổ chức khác về cơ bản chỉ quan tâm đến việc nghiên
cứu, dành việc phát triển — chưa nói đến bảo trì — cho những người khác. Điều này đặc biệt áp dụng
cho trường đại học khoa học máy tính, nơi nghiên cứu sinh xây dựng phần mềm để chứng minh rằng
một thiết kế hoặc kỹ thuật cụ thể là khả thi. Việc khai thác thương mại đối với khái niệm đã được xác
nhận sẽ được giao cho các tổ chức khác. Tuy nhiên, bất kể quy trình chính xác là gì, quy trình phát triển
phần mềm là được tạo thành xung quanh quy trình cơng việc của Hình 2.4: u cầu, phân tích (specifi -
cation), thiết kế, thực hiện và thử nghiệm. Trong chương này, các công việc này được mô tả cùng với
những thách thức tiềm ẩn có thể phát sinh trong mỗi quy trình làm việc. Giải pháp cho những thách
thức liên quan đến việc sản xuất phần mềm thường là không nhỏ, và phần cịn lại của cuốn sách này
được dành để mơ tả các kỹ thuật phù hợp. bên trong Phần đầu tiên của chương này, chỉ những thách
thức được đánh dấu, nhưng người đọc được hướng dẫn đến các phần hoặc chương có liên quan để biết

các giải pháp. Theo đó, phần này của chương không chỉ là tổng quan về quy trình phần mềm mà cịn là
hướng dẫn cho phần lớn phần còn lại của sách. Chương này kết thúc với các sáng kiến tầm cỡ quốc gia
và quốc tế nhằm cải thiện quy trình phát triền phần mềm.

Bây giờ chúng ta sẽ xem xét Quy trình hợp nhất.

3.1 Quy trình Hợp nhất

Như đã nêu ở đầu chương này, phương pháp luận là một thành phần của quy trình phát triển phần
mềm. Phương pháp hướng đối tượng chính ngày nay là Quy trình hợp nhất. Nó được giải thích trong
“trường hợp bạn muốn biết Hộp 3.2”, "Quy trình" của Hợp nhất thực sự là một phương pháp, nhưng
tên ” Phương pháp luận hợp nhất “ đã được sử dụng làm tên phiên bản đầu tiên của Ngôn ngữ tạo mơ
hình hợp nhất (UML). Ba tiền thân của Quy trình Hợp nhất (OMT, phương pháp của Booch và Objectory)
khơng cịn được hỗ trợ nữa và các phương pháp hướng đối tượng khác có ít hoặc khơng có nữa. Kết quả
là, Quy trình Hợp nhất thường là lựa chọn chính ngày nay để sản xuất phần mềm hướng đối tượng. May
mắn thay, như sẽ được trình bày trong Phần B của cuốn sách này, Quy trình biên tập Hợp nhất là một
phương pháp luận hướng đối tượng tuyệt vời về hầu hết mọi cách. Quy trình Hợp nhất khơng phải là
một chuỗi các bước cụ thể, nếu được tuân theo, sẽ giúp xây dựng một sản phẩm phần mềm. Trên thực
tế, khơng có phương pháp luận duy nhất “một kích thước phì hợp cho tất cả” như vậy có thể tồn tại sự
đa dạng của nhiều loại sản phẩm phần mềm. Ví dụ, có là nhiều lĩnh vực ứng dụng khác nhau, chẳng hạn
như bảo hiểm, hàng không vũ trụ và sản xuất. Ngoài ra, một phương pháp để đưa một gói COTS ra thị
trường trước các đối thủ cạnh tranh của nó khác với mạng được sử dụng để xây dựng mạng chuyển tiền
điện tử có độ bảo mật cao. Ngoài ra, kỹ năng của các chuyên gia phần mềm có thể rất khác nhau. Thay
vào đó, Quy trình Hợp nhất nên được xem như một phương pháp luận có thể thích ứng. Đó là, nó là
chỉnh sửa cho sản phẩm phần mềm cụ thể được phát triển. Như sẽ thấy trong Phần B, một số tính năng
của Quy trình Unifi ed không thể áp dụng cho phần mềm quy mơ nhỏ và thậm chí vừa. Tuy nhiên, phần

lớn Quy trình Hợp nhất được sử dụng cho các sản phẩm phần mềm thuộc mọi quy mô. Cuốn sách này
nhấn mạnh vào tập hợp con chung này của Quy trình biên tập Hợp nhất, nhưng các khía cạnh của Quy
trình Hợp nhất chỉ áp dụng cho phần mềm quy mô lớn cũng được thảo luận, để đảm bảo rằng các vấn

đề cần được giải quyết khi xây dựng các sản phẩm phần mềm lớn hơn là việc đánh giá kỹ lưỡng.

3.2 Lặp lại và gia tăng trong Mơ hình hướng đối tượng

Mơ hình hướng đối tượng sử dụng mơ hình hóa xun suốt. mơ hình là một tập hợp các biểu đồ UML
đại diện cho một hoặc nhiều khía cạnh của sản phẩm phần mềm sẽ được phát triển. (UML sơ đồ được
giới thiệu trong Chương 7.) Hãy nhớ lại rằng UML là viết tắt của Unifi ed Modeling Language. UML là
công cụ mà chúng tôi sử dụng để đại diện (mơ hình hóa) cho phần mềm được nói tới. Lý do chính cho
việc sử dụng phương pháp biểu diễn bằng đồ họa UML cho kết quả tốt là vì một câu tục ngữ, một bức
tranh có giá trị bằng một ngàn lời nói. Biểu đồ UML cho phép các chuyên gia phần mềm giao tiếp với
nhau nhanh hơn và chính xác hơn là chỉ bằng lời nói. Mơ hình hướng đối tượng là một phương pháp
luận lặp đi lặp lại và tăng dần. Mỗi quy trình cơng việc bao gồm một số bước và để thực hiện quy trình
cơng việc đó, các bước của quy trình cơng việc được thực hiện liên tục cho đến khi các thành viên của
nhóm phát triển hài lịng rằng họ có một mơ hình UML chính xác của phần mềm mà họ muốn phát triển.
Đó là, ngay cả những chuyên gia phần mềm có kinh nghiệm nhất cũng lặp đi lặp lại và nhắc lại cho đến
khi họ hoàn tồn hài lịng với các sơ đồ UML. Hàm ý là các kỹ sư phần mềm, cho dù họ có xuất sắc đến
đâu, hầu như không bao giờ đạt được sản phẩm như ý trong lần đầu tiên. Làm sao có thể? Bản chất của
các sản phẩm phần mềm là hầu như mọi thứ phải được phát triển lặp đi lặp lại và tăng dần. Xét cho
cùng, các kỹ sư phần mềm là con người và do đó khơng thể xem xét tất cả mọi thứ cùng một lúc, vì vậy
ban đầu chỉ có bảy hoặc nhiều phần (đơn vị thơng tin) được xử lý. Sau đó, khi phần mềm được xem xét,
nhiều kiến thức hơn về sản phẩm phần mềm mục tiêu sẽ đạt được và Biểu đồ UML được sửa đổi dựa
trên thông tin bổ sung này. Quá trình tiếp tục theo cách này cho đến khi các kỹ sư phần mềm hài lịng
rằng tất cả các mơ hình của quy trình làm việc đã chính xác. Nói cách khác, ban đầu các sơ đồ UML tốt
nhất có thể được vẽ ra dựa trên lượng kiến thức hiện có. Sau đó, khi có thêm kiến thức về hệ thống
trong thế giới thực đang được lập mơ hình, các sơ đồ được tạo chính xác hơn (lặp lại) và mở rộng (tăng
dần). Theo đó, dù có kinh nghiệm và khéo léo đến đâu thì một kỹ sư phần mềm cần lặp đi lặp lại và tăng
dần cho đến khi hài lịng rằng Biểu đồ UML mơ tả chính xác sản phẩm phần mềm sẽ được phát triển. Lý
tưởng nhất là vào cuối cuốn sách này, người đọc sẽ có các kỹ năng kỹ thuật phần mềm cần thiết để xây
dựng các sản phẩm phần mềm lớn, phức tạp mà Quy trình Hợp nhất được phát triển. Thật khơng may,
có ba lý do tại sao điều này không khả thi.

1. Cũng như không thể trở thành một chuyên gia về giải tích hoặc ngoại ngữ trong một một khóa học
duy nhất,do đó để đạt được hiệu quả trong Quy trình biên tập Hợp nhất thì cần yêu cầu nghiên cứu sâu
rộng và quan trọng hơn là thực hành không ngừng trong kỹ thuật phần mềm hướng đối tượng.

2. Quy trình Hợp nhất được tạo ra chủ yếu để sử dụng trong việc phát triển các sản phẩm phần mềm
lớn, phức tạp. Để có thể xử lý sự phức tạp của các sản phẩm phần mềm như vậy, Bản thân Quy trình của
Hợp nhất đã lớn. Thật khó để bao qt mọi khía cạnh của Quy trình Hợp nhất trong một cuốn sách giáo
khoa với kích thước nhỏ như này.

3. Để giảng dạy Quy trình Hợp nhất, cần phải trình bày một nghiên cứu điển hình minh họa các tính
năng của Quy trình Hợp nhất. Để minh họa các tính năng áp dụng cho phần mềm lớn, một nghiên cứu
điển hình như vậy sẽ phải lớn. Ví dụ, chỉ là các dịng mơ tả cụ thể thường sẽ chiếm hơn 1000 trang.

Vì ba lý do này, cuốn sách này trình bày hầu hết, nhưng khơng phải tất cả, về Quy trình biên tập Hợp
nhất. Quy trình cơng việc cốt lõi của Quy trình Hợp nhất (quy trình cơng việc u cầu, phân tích quy
trình cơng việc, quy trình cơng việc thiết kế, quy trình cơng việc thực hiện và quy trình cơng việc kiểm
tra) và những thách thức của chúng hiện đã được thảo luận.

3.3 Các yêu cầu quy trình làm việc

Phát triển phần mềm rất tốn kém. Quá trình phát triển thường bắt đầu khi khách hàng tiếp cận một tổ
chức phát triển liên quan đến một sản phẩm phần mềm mà theo ý kiến của khách hàng, là thiết yếu đối
với lợi nhuận doanh nghiệp của họ hoặc bằng cách nào đó có thể hợp lý về mặt kinh tế. Mục đích của
quy trình làm việc theo u cầu là để tổ chức phát triển phần mềm xác định nhu cầu của khách hàng.
Nhiệm vụ đầu tiên của nhóm phát triển là có được sự hiểu biết cơ bản về miền ứng dụng (gọi tắt là
miền), tức là môi trường cụ thể mà sản phẩm phần mềm đó được vận hành. Lĩnh vực này có thể là ngân
hàng, sản xuất ơ tô hoặc vật lý hạt nhân. Ở bất kỳ giai đoạn nào của quy trình, nếu khách hàng khơng
đánh giá phần mềm không hiệu quả, sự phát triển sẽ chấm dứt ngay lập tức. Trong suốt chương này, giả
định được đưa ra rằng khách hàng cảm thấy rằng chi phí này là hợp lý. Do đó, một khía cạnh quan trọng

của phát triển phần mềm là trường hợp kinh doanh, một tài liệu chứng minh hiệu quả chi phí của sản
phẩm mục tiêu. (Trên thực tế, "chi phí" khơng phải lúc nào cũng hồn tồn là tài chính. Ví dụ, phần mềm
quân sự thường được xây dựng vì các lý do chiến lược hoặc chiến thuật. Ở đây, chi phí của phần mềm là
thiệt hại tiềm tàng có thể phải chịu trong trường hợp khơng có vũ khí được phát triển.)

Tại cuộc họp ban đầu giữa khách hàng và nhà phát triển, khách hàng sẽ phác thảo sản phẩm khi họ lên
ý tưởng. Theo quan điểm của các nhà phát triển, mô tả của khách hàng về sản phẩm mong muốn có thể
mơ hồ, khơng hợp lý, mâu thuẫn hoặc đơn giản là không thể đạt được. Nhiệm vụ của các nhà phát triển
ở giai đoạn này là xác định chính xác những gì khách hàng muốn và tìm ra từ khách hàng những ràng
buộc nào tồn tại.

• Một hạn chế chính hầu như ln ln có là deadline. Ví dụ, khách hàng có thể quy định rằng sản phẩm
hồn thiện phải được hồn thành trong vịng 14 tháng. Trong hầu hết mọi lĩnh vực ứng dụng hiện nay,
việc sản phẩm phần mềm trở nên quan trọng là một sứ mệnh lớn lao. Có nghĩa là, khách hàng cần sản
phẩm phần mềm cho các hoạt động cốt lõi cho tổ chức của họ và bất kỳ sự chậm trễ nào trong việc cung
cấp sản phẩm phần mềm đều gây bất lợi cho tổ chức.

• Nhiều ràng buộc khác thường xuất hiện, chẳng hạn như độ tin cậy (ví dụ, sản phẩm phải hoạt động
99% thời gian, hoặc thời gian trung bình giữa các lần hỏng hóc phải ít nhất 4 tháng). Một hạn chế phổ
biến khác là kích thước của trình tải thực thi hình ảnh (ví dụ: nó phải chạy trên máy tính cá nhân của
khách hàng hoặc trên phần cứng bên trong vệ tinh).

• Chi phí gần như luôn luôn là một hạn chế quan trọng. Tuy nhiên, khách hàng hiếm khi nói với các nhà
phát triển số tiền có sẵn để xây dựng sản phẩm. Thay vào đó, một thực tế phổ biến là, sau khi các trích

dẫn cụ thể đã được hoàn thiện, khách hàng yêu cầu các nhà phát đặt ra giá cần để hoàn thành dự án.
Khách hàng tuân theo thủ tục đấu thầu này với hy vọng rằng số tiền nhà phát triển bỏ thầu thấp hơn số
tiền khách hàng đã chi ngân sách cho dự án.

Cuộc điều tra sơ bộ về nhu cầu của khách hàng đôi khi được gọi là thăm dò ý tưởng. Trong các cuộc họp

tiếp theo giữa các thành viên của nhóm phát triển và nhóm khách hàng, chức năng của sản phẩm đề
xuất sẽ được cập nhật liên tục và được phân tích tính khả thi về mặt kỹ thuật và luận chứng tài chính.

Đến nay, mọi thứ dường như đã trở nên suôn sẻ. Thật không may, quy trình cơng việc thường được
thực hiện khơng đầy đủ. Khi sản phẩm cuối cùng được giao cho người dùng, có lẽ một hoặc hai năm sau
khi khách hàng ký tên vào các thông số kỹ thuật, khách hàng có thể nói với các nhà phát triển, "Tơi biết
rằng đây là những gì tơi u cầu, nhưng nó khơng thực sự là những gì tơi muốn." Những gì khách hàng
u cầu và do đó, những gì các nhà phát triển nghĩ rằng khách hàng muốn, không phải là những gì khách
hàng thực sự cần. Có thể có một số lý do giải thích cho tình trạng khó khăn này. Đầu tiên, khách hàng có
thể khơng thực sự hiểu những gì đang diễn ra trong tổ chức của họ. Ví dụ, việc yêu cầu các nhà phát
triển phần mềm cung cấp một hệ điều hành nhanh hơn sẽ khơng có ích gì nếu nguyên nhân của việc hệ
điều hành chậm hiện tại là một cơ sở dữ liệu được thiết kế tồi. Hoặc, nếu khách hàng điều hành một
chuỗi cửa hàng bán lẻ chưa có lãi, khách hàng có thể u cầu hệ thống thơng tin quản lý tài chính bao
gồm các khoản như doanh số bán hàng, tiền lương, các khoản phải trả và các khoản phải thu. Một sản
phẩm như vậy sẽ ít được sử dụng nếu lý do thực sự gây ra tổn là do yếu tố khách quan (trộm cắp). Nếu
đúng như vậy, thì kiểm sốt cổ phiếu cần có một hệ thống thơng tin quản lý tài chính hơn là một hệ
thống thơng tin tài chính. Nhưng lý do chính khiến khách hàng thường xuyên yêu cầu sản phẩm không
đúng là phần mềm quá phức tạp. Nếu một chuyên gia phần mềm hình dung ra một phần mềm là điều
khác biệt và chức năng của nó, vấn đề cịn tồi tệ hơn nhiều đối với một khách hàng hầu như khơng biết
về máy tính. Như sẽ được trình bày trong Chương 11, Quy trình Hợp nhất có thể giúp ích về vấn đề này;
nhiều UML sơ đồ của Quy trình Hợp nhất hỗ trợ khách hàng có được sự hiểu biết chi tiết cần thiết về
những gì cần được phát triển.

3.4 Quy trình phân tích

Mục đích của quy trình phân tích là phân tích và tìm lại các yêu cầu để đạt được sự hiểu biết chi tiết về
các yêu cầu cần thiết để phát triển một sản phẩm phần mềm một cách chính xác và duy trì nó một cách
dễ dàng. Tuy nhiên, ngay từ cái nhìn đầu tiên, khơng cần phải có quy trình phân tích. Thay vào đó, một
cách có vẻ đơn giản hơn để tiến hành sẽ là phát triển một sản phẩm phần mềm bằng cách tiếp tục lặp đi
lặp lại quy trình cơng việc u cầu cho đến khi có được sự hiểu biết cần thiết về sản phẩm phần mềm

đấy.

Điểm mấu chốt là đầu ra của quy trình làm việc yêu cầu phải được khách hàng hiểu toàn bộ. Nói cách
khác, các tạo tác của quy trình cơng việc yêu cầu phải được thể hiện bằng ngôn ngữ của khách hàng,
nghĩa là bằng ngôn ngữ tự nhiên (con người) như tiếng Anh, Tiếng Armenia, hoặc tiếng Zulu. Nhưng tất
cả các ngơn ngữ tự nhiên, khơng có ngoại lệ, có phần khơng chính xác và dễ gây hiểu lầm. Ví dụ, hãy xem
xét đoạn văn sau: Bản ghi bộ phận và bản ghi nhà máy được đọc từ cơ sở dữ liệu. Nếu nó chứa ký tự A
ngay sau ký tự Q thì hãy tính chi phí vận chuyển bộ phận đó đến nhà máy đó. Ngay từ cái nhìn đầu tiên,

u cầu này có vẻ hồn tồn rõ ràng. Nhưng nó (từ thứ hai trong câu thứ hai) đề cập đến cái gì: bản ghi
bộ phận, bản ghi thực vật, hay cơ sở dữ liệu?

Những mơ hồ thuộc loại này không thể nảy sinh nếu các yêu cầu được thể hiện (giả sử) trong một ký
hiệu toán học. Tuy nhiên, nếu một ký hiệu toán học được sử dụng cho các u cầu, thì khách hàng khơng
có khả năng hiểu nhiều u cầu. Do đó, có thể có thơng tin sai lệch giữa khách hàng và nhà phát triển về
các yêu cầu, và do đó, sản phẩm phần mềm được phát triển để đáp ứng các yêu cầu đó có thể không
phải là thứ mà khách hàng cần. Giải pháp là có hai quy trình làm việc riêng biệt. Quy trình cơng việc u
cầu được soạn thảo bằng ngơn ngữ của khách hàng; quy trình phân tích, bằng một ngơn ngữ chính xác
hơn để đảm bảo rằng quy trình thiết kế và triển khai được thực hiện một cách chính xác. Ngoài ra, các
chi tiết khác được thêm vào trong quy trình phân tích, các chi tiết khơng liên quan đến sự hiểu biết của
khách hàng về sản phẩm phần mềm mục tiêu nhưng cần thiết cho các chuyên gia phần mềm, những
người sẽ phát triển sản phẩm phần mềm. Ví dụ: trạng thái ban đầu của một statechart (Mục 13.6) chắc
chắn sẽ không liên quan đến khách hàng theo bất kỳ cách nào nhưng phải được đưa vào các trích dẫn cụ
thể nếu các nhà phát triển muốn xây dựng sản phẩm mục tiêu một cách chính xác. Các thông số kỹ thuật
của sản phẩm tạo thành một hợp đồng. Các nhà phát triển phần mềm được coi là đã hoàn thành hợp
đồng khi họ cung cấp một sản phẩm đáp ứng các tiêu chí chấp nhận của các cation cụ thể. Vì lý do này,
các trích dẫn cụ thể khơng được bao gồm các thuật ngữ khơng chính xác như các thuật ngữ phù hợp,
thuận tiện, đủ hoặc đủ hoặc các thuật ngữ tương tự nghe có vẻ chính xác nhưng trên thực tế cũng
khơng chính xác như nhau, chẳng hạn như tối ưu hoặc hoàn thành 98 phần trăm. Trong trường hợp việc
phát triển phần mềm theo hợp đồng có thể dẫn đến một vụ kiện, thì sẽ khơng có cơ hội để các thơng số

kỹ thuật tạo cơ sở cho hành động pháp lý khi khách hàng và nhà phát triển thuộc cùng một tổ chức. Tuy
nhiên, ngay cả trong trường hợp phát triển phần mềm nội bộ, các thông số kỹ thuật luôn phải được viết
như thể chúng sẽ được sử dụng làm bằng chứng trong một cuộc thử nghiệm. Quan trọng hơn, các
cation specifi cần thiết cho cả quá trình kiểm tra và bảo trì. Trừ khi các trích dẫn cụ thể là chính xác,
khơng có cách nào để xác định liệu chúng có chính xác hay khơng, hãy một mình liệu việc triển khai có
thỏa mãn các cation cụ thể hay khơng. Và thật khó để thay đổi các thơng số kỹ thuật trừ khi một số tài
liệu cho biết chính xác các thơng số kỹ thuật hiện tại là gì. Khi Quy trình hợp nhất được sử dụng, khơng
có tài liệu cation cụ thể nào theo nghĩa thông thường của thuật ngữ này. Thay vào đó, một tập hợp các
tạo tác UML được hiển thị cho máy khách, như được mô tả trong Chương 13. Các sơ đồ UML này và các
mô tả của chúng có thể loại bỏ nhiều (nhưng khơng phải là tất cả) các vấn đề của tài liệu cation đặc tả cổ
điển.

Một sai lầm có thể được thực hiện bởi một nhóm phân tích cổ điển là các trích dẫn cụ thể là mơ hồ;
như đã giải thích trước đây, sự mơ hồ là bản chất của các ngơn ngữ tự nhiên. Tính khơng đầy đủ là một
vấn đề khác trong các thông số kỹ thuật; nghĩa là, một số dữ kiện hoặc yêu cầu có liên quan có thể bị bỏ
qua. Ví dụ: tài liệu trích dẫn cụ thể có thể khơng nêu rõ những hành động nào sẽ được thực hiện nếu dữ
liệu đầu vào có lỗi. Hơn nữa, tài liệu trích dẫn cụ thể có thể chứa đựng những mâu thuẫn. Ví dụ, một vị
trí trong tài liệu đặc tả cho một sản phẩm kiểm sốt q trình lên men quy định rằng nếu áp suất vượt
quá 35 psi, thì van M17 phải được đóng ngay lập tức. Tuy nhiên, một nơi khác lại cho rằng, nếu áp lực
vượt quá 35 psi, thì ngay lập tức người vận hành phải được cảnh báo; chỉ khi người vận hành khơng có
biện pháp khắc phục trong vịng 30 giây thì van M17 mới được tự động đóng lại. Việc phát triển phần

mềm không thể tiến hành cho đến khi các vấn đề như vậy trong các thông số kỹ thuật đã được khắc
phục. Như đã chỉ ra trong đoạn trước, nhiều vấn đề trong số này có thể được giảm bớt bằng cách sử
dụng Quy trình hợp nhất. Điều này là do các biểu đồ UML cùng với các mô tả sơ đồ ít có khả năng chứa
sự mơ hồ, khơng đầy đủ và mâu thuẫn. Sau khi khách hàng đã phê duyệt các thông số kỹ thuật, lập kế
hoạch chi tiết và ước tính sẽ bắt đầu. Khơng khách hàng nào cho phép một dự án phần mềm mà không
biết trước thời gian dự án sẽ thực hiện và chi phí bao nhiêu. Theo quan điểm của các nhà phát triển, hai
hạng mục này cũng quan trọng như nhau. Nếu các nhà phát triển đánh giá thấp chi phí của một dự án,
thì khách hàng sẽ trả phí theo thỏa thuận, có thể ít hơn đáng kể so với chi phí thực tế của các nhà phát

triển. Ngược lại, nếu các nhà phát triển ước tính quá cao chi phí của dự án, thì khách hàng có thể từ chối
dự án hoặc giao việc cho các nhà phát triển khác mà họ ước tính là hợp lý hơn. Các vấn đề tương tự nảy
sinh liên quan đến ước tính thời lượng. Nếu các nhà phát triển đánh giá thấp thời gian hồn thành một
dự án, thì tốt nhất, việc giao sản phẩm trễ sẽ khiến khách hàng mất lòng tin. Tệ nhất, các điều khoản
phạt chậm trễ trong hợp đồng được viện dẫn, khiến các nhà phát triển phải chịu thiệt hại về mặt tài
chính. Một lần nữa, nếu các nhà phát triển đánh giá quá cao thời gian để sản phẩm được giao, khách
hàng có thể trao cơng việc cho những nhà phát triển hứa hẹn giao hàng nhanh hơn. Đối với các nhà phát
triển, chỉ ước tính thời lượng và tổng chi phí là khơng đủ. Các nhà phát triển cần chỉ định nhân sự thích
hợp cho các quy trình cơng việc khác nhau của q trình phát triển. Ví dụ: nhóm triển khai khơng thể bắt
đầu cho đến khi các tạo tác thiết kế liên quan đã được nhóm đảm bảo chất lượng phần mềm (SQA) phê
duyệt và nhóm thiết kế khơng cần thiết cho đến khi nhóm phân tích đã hồn thành nhiệm vụ của mình.
Nói cách khác, các nhà phát triển phải lên kế hoạch trước. Kế hoạch quản lý dự án phần mềm (SPMP)
phải được lập phản ánh các quy trình cơng việc riêng biệt của quá trình phát triển và chỉ ra các thành
viên nào của tổ chức phát triển tham gia vào từng nhiệm vụ, cũng như thời hạn để hoàn thành mỗi
nhiệm vụ. Sớm nhất mà một kế hoạch chi tiết như vậy có thể được lập là khi các thơng số kỹ thuật đã
được hồn thiện. Trước thời điểm đó, dự án q vơ định hình để hồn thành quy hoạch. Một số khía
cạnh của dự án chắc chắn phải được lên kế hoạch ngay từ đầu, nhưng cho đến khi các nhà phát triển
biết chính xác những gì sẽ được xây dựng, họ không thể chỉ rõ tất cả các khía cạnh của kế hoạch xây
dựng nó. Do đó, khi các trích dẫn cụ thể đã được khách hàng chấp thuận, thì việc chuẩn bị kế hoạch
quản lý dự án phần mềm sẽ bắt đầu. Các thành phần chính của kế hoạch là các sản phẩm được cung cấp
(khách hàng sẽ nhận được gì), các mốc quan trọng (khi khách hàng nhận được chúng) và ngân sách (chi
phí sẽ là bao nhiêu). Kế hoạch mô tả chi tiết đầy đủ nhất về quy trình phần mềm. Nó bao gồm các khía
cạnh như mơ hình vịng đời sẽ được sử dụng, cơ cấu tổ chức của tổ chức phát triển, trách nhiệm của dự
án, các mục tiêu và ưu tiên của người quản lý, các kỹ thuật và TRƯỜNG HỢP các cơng cụ được sử dụng
và lịch trình chi tiết, ngân sách và phân bổ nguồn lực. Bên dưới toàn bộ kế hoạch là thời gian và ước tính
chi phí; các kỹ thuật để có được những ước tính như vậy được mơ tả trong Phần 9.2. Quy trình phân tích
được mơ tả trong Chương 12 và 13: các kỹ thuật phân tích cổ điển được mơ tả trong Chương 12 và phân
tích hướng đối tượng là chủ đề của Chương 13. Một tạo tác chính của quy trình phân tích là kế hoạch
quản lý dự án phần mềm. Giải thích về cách tạo SPMP được đưa ra trong Phần 9.3 và 9.5. Bây giờ quy
trình thiết kế được kiểm tra.

3.5 Quy trình thiết kế

Các trích dẫn cụ thể của một sản phẩm cho biết sản phẩm đó phải làm gì; thiết kế chỉ ra cách sản phẩm
làm được điều đó. Chính xác hơn, mục đích của quy trình thiết kế là tinh chỉnh các tạo tác của quy trình
phân tích cho đến khi tài liệu ở dạng có thể được triển khai bởi các lập trình viên. Như đã giải thích trong
Phần 1.3, trong giai đoạn thiết kế cổ điển, nhóm thiết kế xác định cấu trúc bên trong của sản phẩm. Các
nhà thiết kế phân tách sản phẩm thành các mô-đun, các đoạn mã độc lập với các giao diện ned tốt cho
phần còn lại của sản phẩm. Giao diện của mỗi mô-đun (nghĩa là, các đối số được truyền cho mô-đun và
các đối số được trả về bởi mô-đun) phải được chỉ định chi tiết. Ví dụ, một mơ-đun có thể đo mực nước
trong lị phản ứng hạt nhân và gây ra âm thanh báo động nếu mức quá thấp. Một mơ-đun trong sản
phẩm điện tử hàng khơng có thể lấy hai hoặc nhiều tập hợp tọa độ của tên lửa đối phương đang lao tới,
tính tốn quỹ đạo của nó và gọi một mơ-đun khác để thơng báo cho phi cơng về hành động né tránh có
thể xảy ra. Khi nhóm đã hồn thành việc phân rã thành các mô-đun (thiết kế kiến trúc), thiết kế chi tiết
sẽ được thực hiện. Đối với mỗi mơ-đun, các thuật tốn được chọn và cấu trúc dữ liệu được chọn. Bây
giờ chuyển sang mơ hình hướng đối tượng, cơ sở của mơ hình đó là lớp, một loại mơ-đun cụ thể. Các
lớp được trích xuất trong quy trình cơng việc phân tích và được thiết kế trong quy trình thiết kế. Do đó,
đối tượng hướng đối tượng của kiến trúc thiết kế được thực hiện như một phần của quy trình phân tích
hướng đối tượng, và phần đối chiếu hướng đối tượng của thiết kế chi tiết là một phần của quy trình
thiết kế hướng đối tượng.

Đội ngũ thiết kế phải ghi chép tỉ mỉ các quyết định thiết kế được đưa ra. Thơng tin này là cần thiết vì hai
lý do.

1. Trong khi sản phẩm đang được thiết kế, đôi khi sẽ đi đến ngõ cụt và đội thiết kế phải quay lại và thiết
kế lại một số phần nhất định. Có một hồ sơ bằng văn bản về lý do tại sao các quyết định cụ thể được
đưa ra sẽ hỗ trợ nhóm khi điều này xảy ra và giúp nhóm trở lại đúng hướng.

2. Lý tưởng nhất, thiết kế của sản phẩm nên có kết thúc mở, có nghĩa là các cải tiến trong tương lai (bảo
trì sau giao hàng) có thể được thực hiện bằng cách thêm các lớp mới hoặc thay thế các lớp hiện có mà

khơng ảnh hưởng đến thiết kế nói chung. Tất nhiên, trong thực tế, lý tưởng này rất khó đạt được. Hạn
chế về thời hạn trong thế giới thực là do các nhà thiết kế phải vật lộn với đồng hồ để hồn thành một
thiết kế phù hợp với các thơng số kỹ thuật ban đầu mà không phải lo lắng về bất kỳ cải tiến nào sau này.
Nếu các cải tiến trong tương lai (sẽ được thêm vào sau sản phẩm được giao cho khách hàng) được bao
gồm trong các trích dẫn cụ thể, sau đó chúng phải được cho phép trong thiết kế, nhưng trường hợp này
là cực kỳ hiếm. Nói chung, các trích dẫn cụ thể, và do đó là thiết kế, chỉ giải quyết các yêu cầu hiện tại.
Ngoài ra, trong khi sản phẩm vẫn đang được thiết kế, khơng có cách nào để xác định tất cả các khả năng
có thể xảy ra trong tương lai cải tiến. Cuối cùng, nếu thiết kế phải tính đến tất cả các trách nhiệm trong
tương lai, thì tốt nhất là nó sẽ khó sử dụng; tệ nhất, nó sẽ phức tạp đến mức khơng thể thực hiện được.
Vì vậy, các nhà thiết kế phải thỏa hiệp, đưa ra một thiết kế có thể mở rộng theo nhiều cách hợp lý mà
khơng cần thiết kế lại tồn bộ. Tuy nhiên, trong một sản phẩm trải qua quá trình cải tiến lớn, sẽ đến lúc
thiết kế đơn giản là không thể xử lý các thay đổi tiếp theo. Khi đạt đến giai đoạn này, sản phẩm phải
được thiết kế lại toàn bộ. Nhiệm vụ của nhóm thiết kế lại dễ dàng hơn đáng kể nếu các thành viên trong
nhóm được cung cấp hồ sơ về lý do của tất cả các quyết định thiết kế ban đầu.

3.6 Quy trình thực hiện

Mục tiêu của quy trình triển khai là triển khai sản phẩm phần mềm mục tiêu bằng (các) ngôn ngữ triển
khai đã chọn. Một sản phẩm phần mềm nhỏ đôi khi được thực hiện bởi nhà thiết kế. Ngược lại, một sản
phẩm phần mềm lớn được phân chia thành các hệ thống con nhỏ hơn, sau đó được thực hiện song song
bởi các nhóm viết mã. Đến lượt mình, các hệ thống con bao gồm các thành phần hoặc mã tạo tác được
thực hiện bởi một lập trình viên riêng lẻ. Thông thường, tài liệu duy nhất được cung cấp cho một lập
trình viên là tạo tác thiết kế có liên quan. Ví dụ, trong trường hợp mơ hình cổ điển, lập trình viên được
cung cấp thiết kế chi tiết của mô-đun mà họ sẽ triển khai. Thiết kế chi tiết thường cung cấp đủ thơng tin
để lập trình viên thực hiện mã tạo tác mà không gặp quá nhiều khó khăn. Nếu có bất kỳ vấn đề nào,
chúng có thể nhanh chóng được giải quyết bằng cách tham khảo ý kiến của nhà thiết kế có trách nhiệm.
Tuy nhiên, khơng có cách nào để từng lập trình viên biết được thiết kế kiến trúc có đúng hay khơng. Chỉ
khi tích hợp các tạo tác mã riêng lẻ bắt đầu thì những thiếu sót của thiết kế mới bắt đầu được đưa ra
ánh sáng. Giả sử rằng một số tạo tác mã đã được triển khai và tích hợp và các bộ phận của sản phẩm
được tích hợp cho đến nay dường như đang hoạt động bình thường. Giả sử xa hơn rằng một lập trình

viên đã triển khai chính xác cấu phần a45, nhưng khi cấu phần phần mềm này được tích hợp với các hiện
vật khác, sản phẩm không thành công. Nguyên nhân của sự thất bại không nằm ở bản thân hiện vật a45,
mà là ở cách tạo tác a45 tương tác với phần còn lại của sản phẩm, như đặc điểm cụ thể trong thiết kế
kiến trúc. Tuy nhiên, trong loại tình huống này, lập trình viên vừa mã hóa tạo tác a45 có xu hướng bị đổ
lỗi cho lỗi. Điều này là không may, bởi vì lập trình viên đã đơn giản làm theo các hướng dẫn do nhà thiết
kế cung cấp và thực hiện tạo tác chính xác như được mơ tả trong thiết kế chi tiết cho hiện vật đó. Các
thành viên của nhóm lập trình hiếm khi được xem “bức tranh tồn cảnh”, tức là thiết kế kiến trúc, chưa
nói đến việc được u cầu bình luận về nó. Mặc dù thực sự khơng cơng bằng khi mong đợi một lập trình
viên cá nhân nhận thức được tác động của một tạo tác cụ thể đối với toàn bộ sản phẩm, nhưng điều này
không may xảy ra trong thực tế quá thường xuyên. Đây là một lý do khác tại sao nó rất quan trọng đối
với việc thiết kế phải đúng ở mọi khía cạnh. Tính đúng đắn của thiết kế (cũng như các hiện vật khác)
được kiểm tra như một phần của quy trình thử nghiệm.

3.7 Quy trình kiểm tra

Như thể hiện trong Hình 2.4, trong Quy trình Unifi ed, việc kiểm tra được thực hiện song song với các
quy trình cơng việc khác, bắt đầu lại từ đầu. Có hai khía cạnh chính để kiểm tra.

1. Mỗi nhà phát triển và nhà bảo trì phải chịu trách nhiệm cá nhân để đảm bảo rằng cơng việc của họ là
chính xác. Do đó, một chuyên gia phần mềm phải kiểm tra và thử nghiệm lại từng hiện vật mà họ phát
triển hoặc duy trì.

2. Sau khi chuyên gia phần mềm tin rằng một cấu phần là chính xác, nó sẽ được chuyển giao cho nhóm
đảm bảo chất lượng phần mềm để kiểm tra độc lập, như được mô tả trong Chương 6.

Bản chất của quy trình kiểm tra thay đổi tùy thuộc vào các hiện vật được kiểm tra. Tuy nhiên, một đặc
điểm quan trọng đối với tất cả các hiện vật là khả năng truy xuất nguồn gốc.

3.7.1 Yêu cầu Tạo tác

Nếu các tạo tác yêu cầu có thể kiểm tra được trong vịng đời của sản phẩm phần mềm, thì một đặc tính
mà chúng phải có là khả năng truy xuất nguồn gốc. Ví dụ, phải có khả năng truy tìm mọi mục trong hiện
vật phân tích trở lại hiện vật yêu cầu và tương tự đối với hiện vật thiết kế và hiện vật thực hiện. Nếu các
yêu cầu đã được trình bày một cách có phương pháp, được đánh số hợp lý, được tham chiếu chéo và
được lập chỉ mục, thì các nhà phát triển sẽ có chút khó khăn khi theo dõi qua các tạo tác tiếp theo và
đảm bảo rằng chúng thực sự phản ánh đúng các yêu cầu của khách hàng. Khi công việc của các thành
viên trong nhóm yêu cầu sau đó được nhóm SQA kiểm tra, việc xác định nguồn gốc cũng sẽ đơn giản hóa
nhiệm vụ của họ.

3.7.2 Đồ tạo tác phân tích

Như đã chỉ ra trong Chương 1, một nguồn lỗi chính trong phần mềm được phân phối là các lỗi trong
thông số kỹ thuật không được phát hiện cho đến khi phần mềm đã được cài đặt trên máy tính của khách
hàng và được tổ chức của khách hàng sử dụng cho mục đích đã định. Do đó, cả nhóm phân tích và nhóm
SQA đều phải kiểm tra các hiện vật phân tích một cách tận tình. Ngồi ra, họ phải đảm bảo rằng các trích
dẫn cụ thể là khả thi, chẳng hạn như một thành phần phần cứng cụ thể đủ nhanh hoặc dung lượng lưu
trữ đĩa trực tuyến hiện tại của khách hàng là đủ để xử lý sản phẩm mới. Một cách tuyệt vời để kiểm tra
các hiện vật phân tích là xem xét. Đại diện của nhóm phân tích và của khách hàng có mặt.

Cuộc họp thường do một thành viên của nhóm SQA chủ trì. Mục đích của việc xem xét là để xác định
xem các hiện vật phân tích có chính xác hay khơng. Người đánh giá đi qua các hiện vật phân tích, kiểm
tra xem có bất kỳ lỗi nào khơng. Hướng dẫn và kiểm tra là hai loại đánh giá và chúng được mô tả trong
Phần 6.2. Bây giờ chúng ta chuyển sang việc kiểm tra lập kế hoạch chi tiết và ước tính diễn ra sau khi
khách hàng đã ký vào các thơng báo cụ thể. Trong khi đó, điều cần thiết là mọi khía cạnh của SPMP phải
được kiểm tra tỉ mỉ bởi nhóm phát triển và sau đó là nhóm SQA, đặc biệt phải chú ý đến thời lượng và
ước tính chi phí của kế hoạch. Một cách để làm điều này là ban giám đốc có được hai (hoặc nhiều) ước
tính độc lập về cả thời gian và chi phí khi bắt đầu lập kế hoạch chi tiết, sau đó điều chỉnh bất kỳ sự khác
biệt đáng kể nào. Đối với tài liệu SPMP, một cách tuyệt vời để kiểm tra nó là xem xét tương tự như xem
xét các hiện vật phân tích. Nếu thời gian và ước tính chi phí đạt yêu cầu, khách hàng sẽ cho phép dự án
tiếp tục.

3.7.3 Đồ tạo tác thiết kế

Như đã đề cập trong Phần 3.7.1, một khía cạnh quan trọng của khả năng kiểm tra là khả năng xác định
nguồn gốc. Trong trường hợp của thiết kế, điều này có nghĩa là mọi phần của thiết kế có thể được liên
kết với một tạo tác phân tích. Một thiết kế được tham chiếu chéo phù hợp cung cấp cho các nhà phát
triển và nhóm SQA một cơng cụ mạnh mẽ để kiểm tra xem thiết kế có đồng ý với các trích dẫn cụ thể
hay khơng và liệu mọi phần của thơng số kỹ thuật có được hồn thiện trong một số phần của thiết kế
hay không. Đánh giá thiết kế tương tự như đánh giá mà các cation specifi trải qua. Tuy nhiên, xét về bản
chất kỹ thuật của hầu hết các thiết kế, khách hàng thường không có mặt. Các thành viên của nhóm thiết
kế và nhóm SQA làm việc thơng qua tồn bộ thiết kế cũng như thông qua từng hiện vật thiết kế riêng
biệt, đảm bảo rằng thiết kế là chính xác. Các loại lỗi cần xem xét bao gồm lỗi logic, lỗi giao diện, thiếu xử
lý ngoại lệ (xử lý các điều kiện lỗi) và quan trọng nhất là sự không phù hợp với các cation cụ thể. Ngoài

ra, nhóm đánh giá ln phải nhận thức được khả năng một số lỗi phân tích khơng được phát hiện trong
quy trình làm việc trước đó. Mơ tả chi tiết về quá trình xem xét được nêu trong Phần 6.2.

3.7.4 Đồ tạo tác triển khai

Mỗi thành phần nên được kiểm tra trong khi nó đang được triển khai (kiểm tra tại bàn); và sau khi nó
đã được triển khai, nó sẽ được chạy trên các trường hợp thử nghiệm. Việc kiểm tra khơng chính thức
này được thực hiện bởi lập trình viên. Sau đó, nhóm đảm bảo chất lượng kiểm tra thành phần một cách
phương pháp; đây được gọi là thử nghiệm đơn vị. Một loạt các kỹ thuật kiểm thử đơn vị được mơ tả
trong Chương 15. Ngồi việc chạy các trường hợp thử nghiệm, xem xét mã là một kỹ thuật mạnh mẽ,
thành công để phát hiện lỗi lập trình. Tại đây, lập trình viên hướng dẫn các thành viên của nhóm đánh
giá thơng qua việc liệt kê thành phần. Nhóm đánh giá phải bao gồm một đại diện của SQA. Quy trình này
tương tự như xem xét các trích dẫn và thiết kế cụ thể được mơ tả trước đây. Như trong tất cả các quy
trình cơng việc khác, hồ sơ về các hoạt động của nhóm SQA được lưu giữ như một phần của quy trình
cơng việc thử nghiệm. Khi một thành phần đã được mã hóa, nó phải được kết hợp với các thành phần
được mã hóa khác để nhóm SQA có thể xác định xem sản phẩm (một phần) nói chung có hoạt động

chính xác hay không. Cách thức mà các thành phần được tích hợp (tất cả cùng một lúc hoặc một lúc) và
thứ tự cụ thể (từ trên xuống dưới hoặc từ dưới lên trên trong sơ đồ kết nối thành phần hoặc hệ thống
phân cấp lớp) có thể có ảnh hưởng quan trọng đến chất lượng của sản phẩm kết quả. Ví dụ: giả sử sản
phẩm được tích hợp từ dưới lên. Một lỗi thiết kế lớn, nếu có, sẽ xuất hiện muộn, đòi hỏi phải thực hiện
lại một cách tốn kém. Ngược lại, nếu các thành phần được tích hợp từ trên xuống, thì các thành phần
cấp dưới thường khơng nhận kiểm tra kỹ lưỡng như trường hợp xảy ra nếu sản phẩm được tích hợp từ
dưới lên. Những vấn đề này và các vấn đề khác được thảo luận chi tiết trong Chương 15. Một lời giải
thích chi tiết được đưa ra ở đó như lý do tại sao mã hóa và tích hợp phải được thực hiện song song.

Mục đích của thử nghiệm tích hợp này là để kiểm tra xem các thành phần có kết hợp chính xác với nhau
để tạo ra một sản phẩm đáp ứng các u cầu cụ thể của nó hay khơng. Trong q trình kiểm tra tích
hợp, phải đặc biệt chú ý đến việc kiểm tra các giao diện thành phần. Điều quan trọng là số lượng, thứ tự
và loại đối số chính thức khớp với số lượng, thứ tự và loại đối số thực tế. Việc kiểm tra kiểu mạnh này
[van Wijngaarden et al., 1975] được trình biên dịch và trình liên kết thực hiện tốt nhất. Tuy nhiên, nhiều
ngôn ngữ không được gõ mạnh. Khi một ngôn ngữ như vậy được sử dụng, các thành viên của nhóm SQA
phải kiểm tra các giao diện. Khi kiểm tra tích hợp đã hoàn thành (nghĩa là khi tất cả các thành phần đã
được mã hóa và tích hợp), nhóm SQA thực hiện kiểm tra sản phẩm. Toàn bộ chức năng của sản phẩm
được kiểm tra dựa trên các thông số kỹ thuật. Đặc biệt, các ràng buộc được liệt kê trong thông số kỹ
thuật phải được thử nghiệm. Ví dụ điển hình là thời gian phản hồi có được đáp ứng hay khơng. Bởi vì
mục đích của kiểm tra sản phẩm là để xác định xem các thông số kỹ thuật đã được triển khai chính xác
hay chưa, nhiều trường hợp kiểm thử có thể được đưa ra sau khi các thơng số kỹ thuật hồn tất.

Khơng chỉ phải kiểm tra tính đúng đắn của sản phẩm mà còn phải kiểm tra độ bền của sản phẩm. Có
nghĩa là, dữ liệu đầu vào có lỗi cố ý được gửi để xác định xem sản phẩm có bị lỗi hay khơng hoặc liệu khả
năng xử lý lỗi của nó có đủ để xử lý dữ liệu xấu hay không. Nếu sản phẩm sẽ được chạy cùng với phần
mềm hiện được cài đặt của khách hàng, thì các thử nghiệm cũng phải được thực hiện để kiểm tra rằng

sản phẩm mới sẽ khơng có tác dụng phụ trên các hoạt động máy tính hiện có của khách hàng. Cuối cùng,
phải kiểm tra xem liệu mã nguồn và tất cả các loại tài liệu khác có đầy đủ và nhất quán nội bộ hay không.

Thử nghiệm sản phẩm được thảo luận trong Phần 15.21. Trên cơ sở kết quả của việc kiểm tra sản phẩm,
một nhà quản lý cấp cao trong tổ chức phát triển sẽ quyết định xem sản phẩm đã sẵn sàng để xuất
xưởng cho khách hàng hay chưa. Bước cuối cùng trong việc kiểm tra các tạo tác triển khai là kiểm tra
chấp nhận. Phần mềm được giao cho khách hàng, người kiểm tra nó trên phần cứng thực tế, sử dụng dữ
liệu thực tế trái ngược với dữ liệu thử nghiệm. Bất kể nhóm phát triển hoặc nhóm SQA có phương pháp
như thế nào, vẫn có sự khác biệt đáng kể giữa các trường hợp thử nghiệm, bản chất của chúng là dữ liệu
nhân tạo và dữ liệu thực tế. Một sản phẩm phần mềm không thể được coi là đáp ứng các tiêu chuẩn cụ
thể của nó cho đến khi sản phẩm đó đã vượt qua kiểm tra chấp nhận. Thông tin chi tiết về thử nghiệm
chấp nhận được nêu trong Phần 15.22.

Trong trường hợp phần mềm COTS (Phần 1.11), ngay sau khi quá trình thử nghiệm sản phẩm hồn tất,
các phiên bản của sản phẩm hoàn chỉnh sẽ được cung cấp cho một số khách hàng có thể có trong tương
lai để thử nghiệm tại chỗ. Phiên bản đầu tiên như vậy được gọi là bản phát hành alpha. Bản phát hành
alpha đã sửa chữa được gọi là bản phát hành beta; nói chung, bản phát hành beta dự định gần với phiên
bản cuối cùng. (Các điều khoản phát hành alpha và phát hành beta thường được áp dụng cho tất cả các
loại sản phẩm phần mềm, không chỉ COTS.) Lỗi trong phần mềm COTS thường dẫn đến việc bán sản
phẩm kém và tổn thất lớn cho cơng ty phát triển. Vì vậy, càng nhiều lỗi càng tốt được đưa ra ánh sáng
càng sớm càng tốt, các nhà phát triển phần mềm COTS thường cung cấp các bản phát hành alpha hoặc
beta cho các công ty được chọn, với kỳ vọng rằng các thử nghiệm tại chỗ sẽ phát hiện ra bất kỳ lỗi tiềm
ẩn nào. Đổi lại, các trang web alpha và beta thường được hứa hẹn là các bản sao miễn phí của phiên bản
phần mềm được phân phối. Rủi ro liên quan đến một công ty tham gia thử nghiệm alpha hoặc beta. Đặc
biệt, các bản phát hành alpha có thể có nhiều lỗi, dẫn đến thất vọng, lãng phí thời gian và có thể làm
hỏng cơ sở dữ liệu. Tuy nhiên, cơng ty đã có bước khởi đầu thuận lợi trong việc sử dụng phần mềm
COTS mới, phần mềm có thể mang lại lợi thế hơn so với các đối thủ cạnh tranh. Đôi khi xảy ra sự cố khi
các tổ chức phần mềm sử dụng thử nghiệm alpha của khách hàng tiềm năng thay vì thử nghiệm sản
phẩm kỹ lưỡng của nhóm SQA. Mặc dù thử nghiệm alpha ở một số trang web khác nhau thường làm
sáng tỏ nhiều loại lỗi, khơng có sự thay thế cho thử nghiệm phương pháp mà nhóm SQA có thể cung
cấp.

3.8 Bảo trì sau giao hàng

Bảo trì sau giao hàng không phải là hoạt động được thực hiện một cách miễn cưỡng sau khi sản phẩm
đã được phân phối và cài đặt trên máy tính của khách hàng. Ngược lại, nó là một phần khơng thể thiếu
của quy trình phần mềm phải được lập kế hoạch ngay từ đầu. Như đã giải thích trong Phần 3.5, thiết kế,
trong chừng mực khả thi, nên tính đến các cải tiến trong tương lai. Mã hóa phải được thực hiện với lưu ý
bảo trì trong tương lai. Xét cho cùng, như đã chỉ ra trong Phần 1.3, chi phí bảo trì sau giao hàng nhiều
hơn so với tất cả các hoạt động phần mềm khác cộng lại. Do đó, nó là một khía cạnh quan trọng của sản
xuất phần mềm. Bảo trì sau giao hàng không bao giờ được được coi như một suy nghĩ sau. Thay vào đó,
tồn bộ nỗ lực phát triển phần mềm phải được thực hiện theo cách để giảm thiểu tác động của việc bảo
trì sau giao hàng không thể tránh khỏi trong tương lai. Một vấn đề phổ biến với bảo trì sau giao hàng là

thiếu tài liệu hoặc đúng hơn là thiếu tài liệu. Trong quá trình phát triển phần mềm theo thời hạn, các
phân tích và tạo tác thiết kế ban đầu thường khơng được cập nhật và do đó, hầu như vơ dụng đối với
việc bảo trì đội. Các tài liệu khác như sổ tay cơ sở dữ liệu hoặc sổ tay vận hành có thể khơng bao giờ
được viết, bởi vì ban giám đốc quyết định rằng việc giao sản phẩm cho khách hàng đúng thời hạn là
quan trọng hơn là phát triển tài liệu song song với phần mềm. Trong nhiều trường hợp, mã nguồn là tài
liệu duy nhất có sẵn cho người bảo trì. Tỷ lệ cao sự luân chuyển nhân sự trong ngành công nghiệp phần
mềm làm trầm trọng thêm tình hình bảo trì, trong đó khơng một nhà phát triển ban đầu nào có thể làm
việc cho tổ chức tại thời điểm bảo trì được thực hiện. Bảo trì sau giao hàng thường xun là khía cạnh
thách thức nhất của sản xuất phần mềm vì những lý do này và những lý do bổ sung được đưa ra trong
Chương 16. Bây giờ chuyển sang thử nghiệm, có hai khía cạnh để thử nghiệm các thay đổi được thực
hiện đối với một sản phẩm khi bảo trì giao hàng sau được thực hiện. Đầu tiên là kiểm tra xem các thay
đổi bắt buộc đã được thực hiện đúng chưa. Khía cạnh thứ hai là đảm bảo rằng, trong quá trình thực hiện
các thay đổi bắt buộc đối với sản phẩm, khơng có bất kỳ thay đổi vơ ý nào khác được thực hiện. Do đó,
một khi lập trình viên đã xác định rằng các thay đổi mong muốn đã được thực hiện, sản phẩm phải được
thử nghiệm dựa trên các trường hợp thử nghiệm trước đó để đảm bảo rằng chức năng phần cịn lại của
sản phẩm khơng bị xâm phạm. Thủ tục này được gọi là kiểm thử hồi quy. Để hỗ trợ kiểm thử hồi quy,
cần phải giữ lại tất cả các trường hợp thử nghiệm trước đó, cùng với kết quả chạy các trường hợp thử
nghiệm đó. Kiểm tra trong q trình bảo trì sau giao hàng được thảo luận chi tiết hơn trong Chương 16.
Một khía cạnh chính của bảo trì sau giao hàng là hồ sơ về tất cả các thay đổi đã thực hiện, cùng với lý do

của mỗi thay đổi. Khi phần mềm được thay đổi, nó phải được kiểm tra hồi quy. Do đó, các trường hợp
kiểm thử hồi quy là một dạng tài liệu trung tâm.

3.9 Nghỉ hưu

Giai đoạn cuối cùng trong vòng đời của phần mềm là nghỉ hưu. Sau nhiều năm phục vụ, sẽ đến giai đoạn
khi việc bảo trì thêm sau giao hàng khơng cịn hiệu quả về chi phí nữa.

• Đơi khi những thay đổi được đề xuất quá lớn đến mức phải thay đổi toàn bộ thiết kế. Trong trường
hợp như vậy, việc thiết kế lại và mã hóa lại tồn bộ sản phẩm sẽ ít tốn kém hơn.

• Nhiều thay đổi có thể đã được thực hiện đối với thiết kế ban đầu mà sự phụ thuộc lẫn nhau đã vơ tình
được tích hợp vào sản phẩm và ngay cả một thay đổi nhỏ đối với một thành phần nhỏ cũng có thể có
ảnh hưởng mạnh mẽ đến chức năng của tồn bộ sản phẩm.

• Tài liệu có thể khơng được duy trì đầy đủ, do đó làm tăng nguy cơ xảy ra lỗi hồi quy đến mức có thể an
tồn hơn khi mã hóa lại hơn là duy trì.

• Phần cứng (và hệ điều hành) mà sản phẩm chạy phải được thay thế; có thể tiết kiệm hơn nếu thực
hiện lại từ đầu hơn là sửa đổi.

Trong mỗi trường hợp này, phiên bản hiện tại được thay thế bằng phiên bản mới và quá trình phần
mềm tiếp tục. Mặt khác, việc nghỉ hưu thực sự là một sự kiện hơi hiếm xảy ra khi một sản phẩm đã phát
triển hơn tính hữu dụng của nó. Tổ chức khách hàng khơng cịn u cầu chức năng được cung cấp bởi
sản phẩm và nó sẽ bị xóa khỏi máy tính.

3.10 Các giai đoạn của Quy trình Hợp nhất

Hình 3.1 khác với Hình 2.4 ở chỗ nhãn của các giá trị gia tăng đã được thay đổi. Thay vì Phần tăng A,
Phần tăng B, v.v., bốn phần gia tăng giờ đây được gắn nhãn Giai đoạn khởi đầu, Giai đoạn xây dựng, Giai

đoạn xây dựng và Giai đoạn chuyển tiếp. Ở trong nói cách khác, các giai đoạn của Quy trình Unifi ed
tương ứng với các bước tăng dần.

HÌNH 3.1 Giai đoạn Giai đoạn Giai đoạn xây Giai đoạn
khởi đầu xây dựng dựng chuyển tiếp
Các quy trình
làm việc cốt Yêu cầu quy trình
lõi và các giai làm việc
đoạn của
Quy trình Phân tích quy
Hợp nhất. trình làm việc

Thiết kế quy trình
làm việc

Quy trình thực
hiện

Kiểm tra quy trình
làm việc

Thời gian

Mặc dù về lý thuyết, việc phát triển một sản phẩm phần mềm có thể được thực hiện với bất kỳ số
lượng gia tăng nào, nhưng sự phát triển trong thực tế dường như bao gồm bốn bước gia tăng. Các phần
gia tăng hoặc các giai đoạn được mô tả trong Phần 3.10.1 đến 3.10.4, cùng với các sản phẩm của mỗi
giai đoạn, tức là các phần tạo tác sẽ được hoàn thành vào cuối giai đoạn đó. Mỗi bước được thực hiện
trong Quy trình Unifi ed đều thuộc một trong các quy trình làm việc cốt lõi và cũng thuộc một trong bốn
giai đoạn, giai đoạn khởi đầu, giai đoạn xây dựng, giai đoạn xây dựng và giai đoạn chuyển tiếp. Các bước
khác nhau của bốn giai đoạn này đã được mô tả trong Phần 3.3 đến 3.7. Ví dụ: xây dựng một trường

hợp kinh doanh là một phần của các về quy trình làm việc (Phần 3.3). Nó cũng là một phần của giai đoạn
khởi đầu. Tuy nhiên, mỗi bước phải được xem xét hai lần, như sẽ được giải thích. Xem xét quy trình làm
việc yêu cầu. Để xác định nhu cầu của khách hàng, một trong các bước, như vừa nêu, là xây dựng một
tình huống kinh doanh. Nói cách khác, trong khn khổ của quy trình làm việc u cầu, việc xây dựng
một tình huống kinh doanh được trình bày trong bối cảnh kỹ thuật. Trong Phần 3.10.1, mô tả được trình
bày về việc xây dựng một tình huống kinh doanh trong khuôn khổ của giai đoạn khởi đầu, giai đoạn mà
ban giám đốc quyết định có phát triển hay khơng sản phẩm phần mềm được đề xuất. Có nghĩa là, việc
xây dựng một trường hợp kinh doanh được trình bày ngắn gọn trong bối cảnh kinh tế (Phần 1.2). Đồng
thời, khơng có ích lợi gì khi trình bày mỗi bước hai lần, cả hai lần ở cùng một mức độ chi tiết. Theo đó,
giai đoạn khởi đầu được mơ tả chuyên sâu để làm nổi bật sự khác biệt giữa bối cảnh kỹ thuật của quy
trình cơng việc và bối cảnh kinh tế của các giai đoạn, nhưng ba giai đoạn khác được phác thảo đơn giản.

3.10.1 Giai đoạn khởi đầu

Mục đích của giai đoạn khởi đầu (bước đầu tiên) là xác định xem liệu việc phát triển sản phẩm phần
mềm mục tiêu có đáng giá hay khơng. Nói cách khác, mục tiêu chính của giai đoạn này là xác định xem
sản phẩm phần mềm được đề xuất có khả thi về mặt kinh tế hay không. Hai bước của quy trình u cầu
là hiểu miền và xây dựng mơ hình kinh doanh. Rõ ràng, khơng có cách nào để các nhà phát triển có thể
đưa ra bất kỳ loại ý kiến nào về một sản phẩm phần mềm có thể có trong tương lai trừ khi họ đầu tiên
hiểu được lĩnh vực mà họ đang xem xét phát triển sản phẩm phần mềm mục tiêu. Không thành vấn đề
nếu miền là mạng truyền hình, cơng ty máy cơng cụ hay bệnh viện chuyên về bệnh gan — nếu các nhà
phát triển khơng hiểu đầy đủ về miền, có thể rất ít tin tưởng dựa trên những gì họ xây dựng sau đó. Do
đó, bước đầu tiên là có được kiến thức miền. Sau khi các nhà phát triển đã hiểu đầy đủ về miền, bước
thứ hai là xây dựng mơ hình kinh doanh, tức là mơ tả các quy trình kinh doanh của khách hàng. Nói cách
khác, nhu cầu đầu tiên là hiểu chính miền và nhu cầu thứ hai là hiểu chính xác cách tổ chức khách hàng
hoạt động trong miền đó. Bây giờ phạm vi của dự án mục tiêu phải được phân định. Ví dụ: hãy xem xét
một sản phẩm phần mềm được đề xuất cho một mạng ATM mới có độ bảo mật cao cho một chuỗi ngân
hàng trên tồn quốc. Quy mơ của mơ hình kinh doanh của tồn bộ chuỗi ngân hàng có thể là rất lớn. Để
xác định sản phẩm phần mềm mục tiêu nên kết hợp những gì, các nhà phát triển chỉ tập trung vào một
tập hợp con của mô hình kinh doanh, cụ thể là, tập hợp con được bao phủ bởi sản phẩm phần mềm

được đề xuất. Do đó, phân định phạm vi của dự án đề xuất là bước thứ ba.

Bây giờ các nhà phát triển có thể bắt đầu thực hiện trường hợp kinh doanh ban đầu. Những câu hỏi
cần được trả lời trước khi tiến hành dự án bao gồm [Jacobson, Booch, và Rumbaugh, 1999]:

• Sản phẩm phần mềm được đề xuất có hiệu quả về chi phí khơng? Nghĩa là, liệu những lợi ích thu được
do phát triển sản phẩm phần mềm có lớn hơn chi phí liên quan khơng? Mất bao lâu để thu được lợi tức
từ khoản đầu tư cần thiết để phát triển sản phẩm phần mềm được đề xuất? Ngồi ra, khách hàng sẽ
phải trả chi phí gì nếu họ quyết định khơng phát triển sản phẩm phần mềm được đề xuất? Nếu sản
phẩm phần mềm được bán trên thị trường, các nghiên cứu tiếp thị cần thiết đã được thực hiện chưa?

• Sản phẩm phần mềm được đề xuất có thể được giao trong thời gian không? Nghĩa là, nếu sản phẩm
phần mềm được đưa ra thị trường muộn, liệu tổ chức có thu được lợi nhuận hay không hay một sản
phẩm phần mềm cạnh tranh sẽ giành được thị phần sư tử trên thị trường? Ngoài ra, nếu sản phẩm phần
mềm được phát triển để hỗ trợ các hoạt động riêng của tổ chức khách hàng (có lẽ bao gồm các hoạt
động quan trọng của sứ mệnh), thì tác động sẽ như thế nào nếu phần mềm được đề xuất

sản phẩm được giao muộn?

• Những rủi ro nào liên quan đến việc phát triển sản phẩm phần mềm, và làm thế nào để giảm thiểu
những rủi ro này? Các thành viên trong nhóm sẽ phát triển sản phẩm phần mềm được đề xuất có kinh
nghiệm cần thiết khơng? Phần cứng mới có cần thiết cho sản phẩm phần mềm này khơng và, nếu vậy, có
rủi ro rằng nó sẽ khơng được giao trong thời gian khơng? Nếu vậy, có cách nào để giảm thiểu rủi ro đó,
có lẽ bằng cách đặt hàng phần cứng dự phịng từ một nhà cung cấp khác? Có cần các cơng cụ phần mềm
(Chương 5) khơng? Hiện tại chúng có sẵn khơng? Chúng có tất cả các chức năng cần thiết khơng? Có khả
năng là một gói COTS (Phần 1.11)

với tất cả (hoặc gần như tất cả) chức năng của sản phẩm phần mềm tùy chỉnh được đề xuất sẽ được đưa
ra thị trường trong khi dự án đang được tiến hành, và điều này có thể được xác định như thế nào?

Vào cuối giai đoạn khởi động, các nhà phát triển cần câu trả lời cho những câu hỏi này để có thể đưa
ra trường hợp kinh doanh ban đầu.

Bước tiếp theo là xác định các rủi ro. Có ba loại rủi ro chính:

1. Rủi ro kỹ thuật. Ví dụ về rủi ro kỹ thuật vừa được liệt kê.

2. Không làm đúng yêu cầu. Rủi ro này có thể được giảm thiểu bằng cách thực hiện đúng quy trình u
cầu.

3. Khơng nhận được đúng kiến trúc. Kiến trúc có thể khơng đủ chắc chắn. (Hãy nhớ lại Phần 2.7 rằng
kiến trúc của một sản phẩm phần mềm bao gồm các thành phần khác nhau và cách chúng kết hợp với
nhau, và đặc tính có thể xử lý các phần mở rộng và thay đổi mà khơng bị phá vỡ chính là tính mạnh mẽ
của nó.) Nói cách khác, trong khi phần mềm sản phẩm đang được phát triển, có nguy cơ là cố gắng thêm
phần tiếp theo vào phần đã được phát triển cho đến nay có thể u cầu tồn bộ kiến trúc được thiết kế
lại từ đầu. Một cách tương tự sẽ là xây dựng một ngôi nhà của các thẻ, chỉ để đánh bại toàn bộ dinh thự
khi một thẻ bổ sung được thêm vào.

Các rủi ro cần được xếp hạng sao cho các rủi ro trọng yếu được giảm thiểu trước tiên.

Như thể hiện trong Hình 3.1, một lượng nhỏ quy trình phân tích được thực hiện trong giai đoạn khởi
động. Tất cả những gì thường làm là trích xuất thơng tin cần thiết cho việc thiết kế kiến trúc. Công việc
thiết kế này cũng được trình bày trong Hình 3.1.

Bây giờ chuyển sang quy trình thực hiện, trong giai đoạn khởi động thường khơng có mã hóa nào được
thực hiện. Tuy nhiên, đơi khi, cần phải xây dựng một nguyên mẫu thử nghiệm 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, như được mô tả trong Mục 2.9.7.

Dịng cơng việc kiểm tra bắt đầu khi bắt đầu giai đoạn khởi động. Mục đích chính ở đây là đảm bảo
rằng các yêu cầu được xác định chính xác. Lập kế hoạch là một phần thiết yếu của mọi giai đoạn. Trong

trường hợp ở giai đoạn khởi động, các nhà phát triển khơng có đủ thông tin vào đầu giai đoạn để lập kế
hoạch cho tồn bộ sự phát triển, do đó, việc lập kế hoạch duy nhất được thực hiện khi bắt đầu dự án là
lập kế hoạch cho chính giai đoạn khởi đầu. Vì lý do tương tự, việc thiếu thơng tin, việc lập kế hoạch duy
nhất có thể được thực hiện một cách có ý nghĩa vào cuối giai đoạn khởi đầu là chỉ lập kế hoạch cho giai
đoạn tiếp theo, giai đoạn xây dựng.

Tài liệu cũng là một phần thiết yếu của mọi giai đoạn. Các sản phẩm của giai đoạn khởi đầu bao gồm
[Jacobson, Booch, và Rumbaugh, 1999]

• Phiên bản ban đầu của mơ hình miền.

• Phiên bản ban đầu của mơ hình kinh doanh.

• Phiên bản ban đầu của các yêu cầu tạo tác.

• Một phiên bản sơ bộ của các hiện vật phân tích.

• Phiên bản sơ bộ của kiến trúc.

• Danh sách rủi ro ban đầu.

• Các trường hợp sử dụng ban đầu (xem Chương 11).

• Kế hoạch cho giai đoạn xây dựng.

• Phiên bản ban đầu của trường hợp nghiệp vụ.

Có được mục cuối cùng, phiên bản ban đầu của trường hợp nghiệp vụ, là mục tiêu tổng thể của giai
đoạn khởi đầu. Phiên bản ban đầu này kết hợp mô tả về phạm vi của phần mềm sản phẩm cũng như chi
tiết tài chính. Nếu sản phẩm phần mềm được đề xuất được đưa ra thị trường, trường hợp kinh doanh

bao gồm dự đốn doanh thu, ước tính thị trường và ước tính chi phí ban đầu.Nếu sản phẩm phần mềm
được sử dụng nội bộ, trường hợp kinh doanh bao gồm phân tích chi phí - lợi ích ban đầu (Phần 5.2).

3.10.2 Giai đoạn chuẩn bị

Mục đích của giai đoạn xây dựng (bước thứ hai) là xác định lại các yêu cầu ban đầu, xác định lại kiến
trúc, theo dõi các rủi ro và xác định lại các ưu tiên của chúng, xác định lại trường hợp kinh doanh và đưa
ra kế hoạch quản lý dự án phần mềm. Lý do cho cái tên giai đoạn xây dựng rõ ràng; các hoạt động chính
của giai đoạn này là sự tái tạo hoặc phát triển của giai đoạn trước.

Hình 3.1 cho thấy rằng các tác vụ này tương ứng với tất cả trừ việc hoàn thành quy trình cơng việc u
cầu (Chương 11), thực hiện hầu như tồn bộ quy trình phân tích (Chương 13), và sau đó bắt đầu thiết kế
kiến trúc (Phần 8.5.4).

Các sản phẩm của giai đoạn xây dựng bao gồm [Jacobson, Booch, và Rumbaugh, 1999]

• Mơ hình miền đã hồn thành.

• Mơ hình kinh doanh đã hồn thiện.

• Các hiện vật u cầu đã hồn thành.

• Các hiện vật phân tích đã hồn thành.

• Phiên bản cập nhật của kiến trúc.

• Một danh sách cập nhật các rủi ro.

• Kế hoạch quản lý dự án phần mềm (cho phần còn lại của dự án).

• Trường hợp kinh doanh đã hồn thành.

3.10.3 Giai đoạn xây dựng

Mục đích của giai đoạn xây dựng (bước tăng thứ ba) là tạo ra phiên bản chất lượng hoạt động đầu tiên
của sản phẩm phần mềm, cái gọi là bản phát hành beta (Phần 3.7.4). Xem xét lại Hình 3.1. Mặc dù fi gure
chỉ là đại diện tượng trưng cho các giai đoạn, rõ ràng là trọng tâm trong giai đoạn này là triển khai và
thử nghiệm sản phẩm phần mềm. Đó là, các thành phần khác nhau được mã hóa và kiểm tra đơn vị. Các
tạo tác mã sau đó được biên dịch và liên kết (tích hợp) để tạo thành các hệ thống con, được kiểm tra
tích hợp. Cuối cùng, các hệ thống con được kết hợp thành hệ thống tổng thể, được sản phẩm thử
nghiệm. Điều này đã được mô tả trong Phần 3.7.4.

Các sản phẩm của giai đoạn xây dựng bao gồm [Jacobson, Booch, và Rumbaugh, 1999]

• Hướng dẫn sử dụng ban đầu và các hướng dẫn khác, nếu thích hợp.

• Tất cả các hiện vật (phiên bản phát hành beta).

• Kiến trúc đã hồn thiện.

• Danh sách rủi ro được cập nhật.

• Kế hoạch quản lý dự án phần mềm (cho phần cịn lại của dự án).

• Nếu cần thiết, trường hợp kinh doanh được cập nhật.

3.10.4 Giai đoạn chuyển tiếp

Mục đích của giai đoạn chuyển đổi (bước tăng thứ tư) là đảm bảo rằng các yêu cầu của khách hàng đã
thực sự được đáp ứng. Giai đoạn này được thúc đẩy bởi phản hồi từ các trang web đã cài đặt phiên bản

beta. (Trong trường hợp một sản phẩm phần mềm tùy chỉnh được phát triển cho một ứng dụng khách
cụ thể, chỉ có một trang web như vậy.) Các lỗi trong sản phẩm phần mềm được sửa chữa. Ngoài ra, tất
cả các hướng dẫn đã được hoàn thành. Trong giai đoạn này, điều quan trọng là cố gắng phát hiện ra bất
kỳ rủi ro nào chưa được xác định trước đó. (Tầm quan trọng của việc phát hiện rủi ro ngay cả trong giai
đoạn chuyển đổi được nêu rõ trong Chỉ trong trường hợp bạn muốn biết ở Hộp 3.3.)

Các sản phẩm của giai đoạn chuyển tiếp bao gồm [Jacobson, Booch và Rumbaugh,

1999]

• Tất cả các hiện vật (phiên bản cuối cùng).

• Các sách hướng dẫn đã hồn thành.

3.11 Mơ hình vịng đời một so với hai chiều

Mơ hình vịng đời cổ điển (như mơ hình thác nước của Phần 2.9.2) là mơ hình một chiều, được biểu
diễn bằng trục đơn trong Hình 3.2 (a). Cơ bản của Quy trình Unifi ed là một mơ hình vịng đời hai chiều,
được thể hiện bằng hai trục trong Hình 3.2 (b).

Bản chất một chiều của mơ hình thác nước được trình bày rõ ràng trong Hình 2.3. Ngược lại, Hình 2.2
cho thấy mơ hình cây tiến hóa của nghiên cứu trường hợp nhỏ Winburg. Mơ hình này là hai chiều và do
đó nên được so sánh với Hình 3.2 (b).
Các biến chứng bổ sung của mơ hình hai chiều có cần thiết không? Câu trả lời đã được đưa ra trong
Chương 2, nhưng đây là một vấn đề quan trọng nên nó được nhắc lại ở đây. Trong q trình phát triển
một sản phẩm phần mềm, trong một thế giới lý tưởng, quy trình cơng việc u cầu sẽ được hồn thành
trước khi tiếp tục quy trình cơng việc phân tích. Tương tự, quy trình phân tích sẽ được hồn thành trước
khi bắt đầu quy trình cơng việc thiết kế, v.v. Tuy nhiên, trên thực tế, tất cả trừ các sản phẩm phần mềm
tầm thường nhất đều quá lớn để xử lý như một đơn vị duy nhất. Thay vào đó, nhiệm vụ phải được chia
thành từng phần (giai đoạn) và trong mỗi phần tăng dần, các nhà phát triển phải lặp lại cho đến khi họ

hoàn thành nhiệm vụ đang được xây dựng. Là con người, chúng ta bị giới hạn bởi Định luật Miller
[Miller, 1956], định luật này nói rằng chúng ta chỉ có thể chủ động xử lý bảy khái niệm cùng một lúc. Do
đó, chúng tơi không thể xử lý tổng thể các sản phẩm phần mềm, mà thay vào đó chúng tơi phải chia các
hệ thống đó thành các hệ thống con.

Ngay cả những hệ thống con đơi khi cũng có thể q lớn — các thành phần có thể là tất cả những gì
chúng ta có thể xử lý cho đến khi chúng ta hiểu đầy đủ hơn về toàn bộ sản phẩm phần mềm.

Quy trình hợp nhất là giải pháp tốt nhất cho đến nay để xử lý một vấn đề lớn như một tập hợp các bài
toán con nhỏ hơn, phần lớn độc lập. Nó cung cấp một khn khổ để gia tăng và lặp lại, cơ chế được sử
dụng để đối phó với sự phức tạp của các sản phẩm phần mềm lớn.

Một thách thức khác mà Quy trình hợp nhất xử lý tốt là những thay đổi khơng thể tránh khỏi. Một khía
cạnh của thách thức này là những thay đổi trong yêu cầu của khách hàng trong khi sản phẩm phần mềm
đang được phát triển, cái gọi là vấn đề mục tiêu di chuyển (Phần 2.4).

Vì tất cả những lý do này, Quy trình Unifi ed hiện là phương pháp luận tốt nhất hiện có. Tuy nhiên,
trong tương lai, Quy trình hợp nhất chắc chắn sẽ bị thay thế bởi một số phương pháp luận mới. Các
chuyên gia phần mềm ngày nay đang nhìn xa hơn Quy trình hợp nhất để đạt được bước đột phá lớn tiếp
theo. Rốt cuộc, trong hầu hết mọi lĩnh vực mà con người nỗ lực, những khám phá của ngày nay thường
vượt trội hơn bất cứ thứ gì được đưa ra trong quá khứ. Quy trình Hợp nhất chắc chắn sẽ được thay thế
bởi các phương pháp luận của tương lai. Bài học quan trọng là, dựa trên kiến thức ngày nay, Quy trình
hợp nhất dường như tốt hơn các giải pháp thay thế khác hiện có.

Phần cịn lại của chương này được dành cho các sáng kiến quốc gia và quốc tế nhằm cải tiến quy trình.

3.12 Cải tiến quy trình phần mềm

Nền kinh tế toàn cầu của chúng ta phụ thuộc rất nhiều vào máy tính và do đó là phần mềm. Vì lý do này,
chính phủ của nhiều quốc gia đang lo ngại về quy trình phần mềm. Ví dụ, vào năm 1987, một lực lượng

đặc nhiệm của Bộ Quốc phòng Hoa Kỳ (DoD) đã báo cáo, “Sau hai thập kỷ với phần lớn những lời hứa
chưa được thực hiện về năng suất và chất lượng đạt được từ việc áp dụng các phương pháp và công
nghệ phần mềm mới, các tổ chức cơng nghiệp và chính phủ đang nhận ra rằng vấn đề cơ bản của họ là
khơng có khả năng quản lý quy trình phần mềm ”[Brooks và cộng sự, 1987].

Để giải quyết vấn đề này và những lo ngại liên quan, DoD đã thành lập Học viện Kỹ thuật Phần mềm
(SEI) và thành lập Viện này tại Đại học Carnegie Mellon ở Pittsburgh trên cơ sở quy trình mua sắm cạnh
tranh. Một thành cơng lớn của SEI là sáng kiến mơ hình phát triển năng lực (CMM). Các nỗ lực cải tiến
quy trình phần mềm liên quan bao gồm các tiêu chuẩn dòng ISO 9000 của Tổ chức Tiêu chuẩn hóa Quốc
tế và ISO / IEC 15504, một sáng kiến cải tiến phần mềm quốc tế với sự tham gia của hơn 40 quốc gia.
Chúng tôi bắt đầu bằng cách mơ tả CMM.

3.13 Các mơ hình trưởng thành về năng lực

Các mơ hình trưởng thành về năng lực của SEI là một nhóm các chiến lược có liên quan để cải thiện quy
trình phần mềm, bất kể mơ hình vịng đời thực tế được sử dụng. (Thuật ngữ trưởng thành là thước đo
mức độ tốt của chính quy trình.) SEI đã phát triển CMM cho phần mềm (SW – CMM), để quản lý nguồn
nhân lực (P – CMM; P là viết tắt của “con người”), cho hệ thống kỹ thuật (SE – CMM), để phát triển sản
phẩm tích hợp (IPD – CMM) và để mua lại phần mềm (SA – CMM). Có một số điểm khơng nhất qn
giữa các mơ hình và mức độ dư thừa khơng thể tránh khỏi. Theo đó, vào năm 1997, nó đã được quyết
định phát triển một khung tích hợp duy nhất cho các mơ hình trưởng thành, tích hợp mơ hình trưởng
thành năng lực (CMMI), kết hợp tất cả các mô hình phát triển năng lực hiện có. Các ngành bổ sung có
thể được thêm vào CMMI trong tương lai [SEI, 2002].

Vì lý do khơng gian, chỉ có một mơ hình phát triển năng lực, SW-CMM, được xem xét ở đây và tổng
quan về P-CMM được đưa ra trong Phần 4.8. SW – CMM lần đầu tiên được đưa ra vào năm 1986 bởi
Watts Humphrey [Humphrey, 1989]. Nhớ lại rằng một quy trình phần mềm bao gồm các hoạt động, kỹ
thuật và công cụ được sử dụng để sản xuất phần mềm. Do đó, nó kết hợp cả khía cạnh kỹ thuật và quản
lý của sản xuất phần mềm. Cơ bản của SW-CMM là niềm tin rằng bản thân việc sử dụng các kỹ thuật
phần mềm mới sẽ không làm tăng năng suất và khả năng lập bảng, bởi vì các vấn đề của chúng ta là do