Đang tải... (xem toàn văn)
• 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á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 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à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 Ngoà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: 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á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 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ơ đồ đượ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 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ủ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 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á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 yê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 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â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 hoàn toà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ư luôn luôn có là deadline Ví dụ, khách hàng có thể quy định rằng sản phẩm hoà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ả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 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àng yê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ể yê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 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ề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 yê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, 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ô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 yê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 soát quá 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 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ả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 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à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 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í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 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â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ồ để hoà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 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ú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 toàn cảnh”, tức là thiết kế kiến trúc, chưa nó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ì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 Ngoà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 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ả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 toà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 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 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ươ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 đó, 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ả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 xuyên 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 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ý 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 toà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 toà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 toà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 yê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 khuôn khổ của quy trình làm việc yê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 yê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 toàn quốc Quy mô của mô hình kinh doanh của toà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? Ngoà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 yê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ể yêu cầu toà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 toà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ự đoá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 yêu cầu (Chương 11), thực hiện hầu như toà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 đã hoàn thành • Mô hình kinh doanh đã hoàn thiện • Các hiện vật yêu cầu đã hoàn thành • Các hiện vật phân tích đã hoà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 đã hoà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 đã hoà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 đã hoà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 quá 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 yêu cầu sẽ được hoà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 hoà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ể quá 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 khuôn 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 quán 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