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

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

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ápluậ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ứccoi 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 đơngiả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áchnhanh 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áchoạ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ạchtrướ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àosả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ôngchị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ềunhà 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ầnmề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ườngxuyê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ànhthời gian để kiểm tra sản phẩm một cách kỹ lưỡng và do đó trễ thời gian hoà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ànhtớ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áocá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ặcthậm chí 20 năm tuổi liên tục được cải tiến để đáp ứng sự thay đổi nhu cầu Ngoài ra, các lỗi còn sót lạitiế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ọ raviệ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êncứ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ụngcho 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ằngmộ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ácnhậ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: yê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áchthứ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áchthứ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ếtcá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

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 Maymắ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ộtphươ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ạnnhư 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 Thayvà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ăngcủ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àynhấ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 Quytrì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 xuyên 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ơ đồ đượcgiớ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 choviệ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ứctranh 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ớinhau 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ápluậ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ìnhcô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ủanhó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 đếnkhi họ hoàn toà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ủacá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 chocù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ậyban đầ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ựatrê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òngrằ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ốtnhấ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ốngtrong 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ăngdầ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ăngdầ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âydự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ọcduy 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âurộ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ềmlớ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ủaHợp nhất đã lớn Thật khó để bao quát mọi khía cạnh của Quy trình Hợp nhất trong một cuốn sách giáokhoa 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ínhnă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ợpnhấ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 yêu cầu, phân tích quytrì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ểmtra) 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 đốivớ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ủaquy trình làm việc theo yê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ânhà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ọngcủ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ảnphẩm mục tiêu (Trên thực tế, "chi phí" không phải lúc nào cũng hoàn toàn là tài chính Ví dụ, phần mềmquâ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àngbuộc nào tồn tại

• Một hạn chế chính hầu như luôn luôn có là deadline Ví dụ, khách hàng có thể quy định rằng sản phẩmhoàn thiện phải được hoà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ảnphẩ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 cungcấ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 động99% 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ủakhá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ọptiế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 đượcthự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 saukhi 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ếtrằng đây là những gì tôi yê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àngyê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áchhà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áttriể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ộtchuỗi cửa hàng bán lẻ chưa có lãi, khách hàng có thể yêu cầu hệ thống thông tin quản lý tài chính baogồ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ảnphẩ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 soá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ềukhá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

Đ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áchkhá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 xemxé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ự Angay 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,

yêu cầu này có vẻ hoàn toà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 yêu cầu, thì khách hàng không

có khả năng hiểu nhiều yê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ôngphả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 yêucầ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áchơ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ácchi 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ủakhá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ữngngườ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ắcchắ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ậtcủ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ũngkhô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ệcphá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 Tuynhiê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ếtnhư 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áccation 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àiliệ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áctạ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ộtvấ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 soát quá trình lên men quy định rằng nếu áp suất vượtquá 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ựcvượ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ắcphụ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ôngbiế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, haihạ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áttriể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ảysinh 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 hoà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ảnphạ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àichí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áchhà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áttriể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íchhợp cho các quy trình công việc khác nhau của quá 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 đã hoà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ànhviê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ỗinhiệ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 hoàn thiện Trước thời điểm đó, dự án quá vô định hình để hoàn thành quy hoạch Một số khíacạ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ểnbiế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âydự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ạchquả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 (chiphí 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íacạ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ínhchi 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ântí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ạchquả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ờ quytrì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ẩmlà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ìnhphâ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 trongPhầ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ácnhà 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 chophầ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ướctrong 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ảnphẩ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 toá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 đã hoà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 toán được chọn và cấu trúc dữ liệu được chọn Bâygiờ 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áclớ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íchhướ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ìnhthiế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ảotrì 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ạnchế 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ồ để hoàn thành mộtthiế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 baogồ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 trongtươ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 toà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úcthiế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 trongnhó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ểnkhai đã 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ảnphẩ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 songbở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 đượcthự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ậptrì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 đượccung 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ìnhviê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ệnvậ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ácthành viên của nhóm lập trình hiếm khi được xem “bức tranh toàn cảnh”, tức là thiết kế kiến trúc, chưanói đến việc được yê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ìnhviê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àykhô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 đốivớ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ácquy 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áttriể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ệnvậ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ácyê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ànhviê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óanhiệ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 trongthô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áchhà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ómSQA đều phải kiểm tra các hiện vật phân tích một cách tận tình Ngoài ra, họ phải đảm bảo rằng các tríchdẫ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ưutrữ đĩ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 tracá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 địnhxem 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ểmtra 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ả trongPhầ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 khikhá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) ướctí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ácbiệ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ư xemxé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ự ántiế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 địnhnguồ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ênkế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áttriể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 hoà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ảnchấ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 toàn bộ thiết kế cũng như thông qua từng hiện vật thiết kế riêngbiệ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á luôn 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 trongquy 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ứcnà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áchphươ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 Ngoà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 đánhgiá 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àytươ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 quytrì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ìnhcô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 độngchí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ốngphâ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ảnphẩ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ệnlạ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ầncấ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ảithí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 yêu cầu cụ thể của nó hay không Trong quá trình kiểm tra tíchhợ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ềungô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 SQAphả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áchay 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 hoà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ầnmề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ấtxưở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 trachấ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ápnhư 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ệunhâ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ệmchấ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 hoà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ươnglai để 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ànhalpha đã 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ênbả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ácloạ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ảnphẩ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ángcà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ặcbeta 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ảnphầ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 Đặcbiệ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àmhỏ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ềmCOTS 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ố khicá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ảnphẩ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àmsá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ể cungcấ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ếucủ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ềuhơ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ảnxuấ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 đó,toà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ảotrì 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ácphâ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ớiviệ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àiliệ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ầnmề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àmviệ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 xuyên là khía cạnhthá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 trongChươ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ựchiệ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ệncá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 đượcthử 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ủasả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 quá 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ý docủ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ợpkiểm thử hồi quy là một dạng tài liệu trung tâ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ể antoà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ựchiệ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ầnmề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áttriển hơn tính hữu dụng của nó Tổ chức khách hàng không còn yêu cầu chức năng được cung cấp bởisản phẩm và nó sẽ bị xóa khỏi máy tính