The Software Process Learning Objec

The Software Process
Learning Objectives
After studying this chapter, you should be able to
• Explain why two-dimensional life-cycle models are important.
• Describe the fi ve core workfl ows of the Unified Process.
• List the artifacts tested in the test workflow.
• Describe the four phases of the Unified Process.
• Explain the difference between the workfl ows and the phases of the Unified
Process.
• Appreciate the importance of software process improvement.
• Describe the capability maturity model (CMM).
74
The software process is the way we produce software. It incorporates the methodology
(Section 1.11) with its underlying software life-cycle model ( Chapter 2 ) and techniques,
the tools we use (Sections 5.6 through 5.12), and most important of all, the individuals
building the software.
Different organizations have different software processes. For example, consider the
issue of documentation. Some organizations consider the software they produce to be selfdocumenting; that is, the product can be understood simply by reading the source code.
Other organizations, however, are documentation intensive. They punctiliously draw up
specifications and check them methodically. Then they perform design activities painstakingly, check and recheck their designs before coding commences, and give extensive
descriptions of each code artifact to the programmers. Test cases are preplanned, the result
of each test run is logged, and the test data are meticulously fi led away. Once the product
has been delivered and installed on the client’s computer, any suggested change must be proposed in writing, with detailed reasons for making the change. The proposed change can be
made only with written authorization, and the modifi cation is not integrated into the product
until the documentation has been updated and the changes to the documentation approved.
Chapter 3 The Software Process 75
Intensity of testing is another measure by which organizations can be compared. Some
organizations devote up to half their software budgets to testing software, whereas others
feel that only the user can thoroughly test a product. Consequently, some companies devote
minimal time and effort to testing the product but spend a considerable amount of time
fi xing problems reported by users.
Postdelivery maintenance is a major preoccupation of many software organizations.
Software that is 10, 15, or even 20 years old is continually enhanced to meet changing
needs; in addition, residual faults continue to appear, even after the software has been successfully maintained for many years. Almost all organizations move their software to newer
hardware every 3 to 5 years; this, too, constitutes postdelivery maintenance.
In contrast, yet other organizations essentially are concerned with research, leaving
development—let alone maintenance—to others. This applies particularly to university
computer science departments, where graduate students build software to prove that a particular design or technique is feasible. The commercial exploitation of the validated concept is left to other organizations. (See Just in Case You Wanted to Know Box 3.1 regarding
the wide variation in the ways different organizations develop software.)
However, regardless of the exact procedure, the software development process is
structured around the five workflows of Figure 2.4 : requirements, analysis (specification), design, implementation, and testing. In this chapter, these workflows are
described, together with potential challenges that may arise during each workflow.
Solutions to the challenges associated with the production of software usually are nontrivial, and the rest of this book is devoted to describing suitable techniques. In the
first part of this chapter, only the challenges are highlighted, but the reader is guided
to the relevant sections or chapters for solutions. Accordingly, this part of the chapter
not only is an overview of the software process, but a guide to much of the rest of the
book. The chapter concludes with national and international initiatives to improve the
software process.
We now examine the Unified Process.
Just in Case You Wanted to Know Box 3.1
Why does the software process vary so drastically from organization to organization? A
major reason is lack of software engineering skills. All too many software professionals
simply do not keep up to date. They continue to develop software Ye Olde Fashioned
Way, because they know no other way.
Another reason for differences in the software process is that many software managers
are excellent managers but know precious little about software development or maintenance. Their lack of technical knowledge can result in the project slipping so badly behind
schedule that there is no point in continuing. This frequently is the reason why many
software projects are never completed.
Yet another reason for differences among processes is management outlook. For
example, one organization may decide that it is better to deliver a product on time, even if
it is not adequately tested. Given the identical circumstances, a different organization might
conclude that the risk of delivering that product without comprehensive testing would be
far greater than taking the time to test the product thoroughly and consequently delivering
it late.
76Part A Software Engineering Concepts
3.1 The Unified Process
As stated at the beginning of this chapter, methodology is one component of a software
process. The primary object-oriented methodology today is the Unified Process. As
explained in Just in Case You Wanted to Know Box 3.2, the Unifi ed “Process” is actually
a methodology, but the name Unified Methodology already had been used as the name
of the fi rst version of the Unifi ed Modeling Language(UML). The three precursors of
the Unifi ed Process (OMT, Booch’s method, and Objectory) are no longer supported, and
the other object-oriented methodologies have had little or no following. As a result, the
Unified Process is usually the primary choice today for object-oriented software production. Fortunately, as will be demonstrated in Part B of this book, the Unifi ed Process is an
excellent object-oriented methodology in almost every way.
The Unified Process is not a specifi c series of steps that, if followed, will result in the
construction of a software product. In fact, no such single “one size fits all” methodology
could exist because of the wide variety of types of software products. For example, there
are many different application domains, such as insurance, aerospace, and manufacturing.
Also, a methodology for rushing a COTS package to market ahead of its competitors is
different from one used to construct a high-security electronic funds transfer network. In
addition, the skills of software professionals can vary widely.
Instead, the Unifi ed Process should be viewed as an adaptable methodology. That is, it
is modifi ed for the specifi c software product to be developed. As will be seen in Part B,
some features of the Unifi ed Process are inapplicable to small- and even medium-scale
software. However, much of the Unifi ed Process is used for software products of all sizes.
The emphasis in this book is on this common subset of the Unified Process, but aspects
of the Unifi ed Process applicable to only large-scale software also are discussed, to ensure
that the issues that need to be addressed when larger software products are constructed are
thoroughly appreciated.
3.2 Iteration and Incrementation within
the Object-Oriented Paradigm
The object-oriented paradigm uses modeling throughout. A modelis a set of UML diagrams that represent one or more aspects of the software product to be developed. (UML
diagrams are introduced in Chapter 7 .) Recall that UML stands for Unifi ed Modeling Language. That is, UML is the tool that we use to represent (model) the target software product.
A major reason for using a graphical representation like UML is best expressed by the old
proverb, a picture is worth a thousand words. UML diagrams enable software professionals
to communicate with one another more quickly and more accurately than if only verbal
descriptions were used.
The object-oriented paradigm is an iterative-and-incremental methodology. Each workflow consists of a number of steps, and to carry out that workfl ow, the steps of the workflow
are repeatedly performed until the members of the development team are satisfied that
they have an accurate UML model of the software product they want to develop. That is,
even the most experienced software professionals iterate and reiterate until they are finally
satisfied that the UML diagrams are correct. The implication is that software engineers, no
Just in Case You Wanted to Know Box 3.2
Until recently, the most popular object-oriented software development methodologies were
object modeling technique (OMT) [Rumbaugh et al., 1991] and Grady Booch’s method
[Booch, 1994]. OMT was developed by Jim Rumbaugh and his team at the General Electric Research and Development Center in Schenectady, New York, whereas Grady Booch
developed his method at Rational, Inc., in Santa Clara, California. All object-oriented software development methodologies essentially are equivalent, so the differences between
OMT and Booch’s method are small. Nevertheless, there always was a friendly rivalry
between the supporters of the two camps.

Kết quả (Việt) 1:

các mục tiêu quá trình phần mềm

học tập sau khi nghiên cứu chương này, bạn sẽ có thể
• giải thích tại sao mô hình vòng đời hai chiều rất quan trọng.
• mô tả các fi đã ows workfl cốt lõi của quá trình thống nhất.
• liệt kê các hiện vật được thử nghiệm trong các công việc thử nghiệm.
• mô tả bốn giai đoạn của quá trình thống nhất.
• giải thích sự khác biệt giữa ows workfl và các giai đoạn của quá trình thống nhất
.
• đánh giá cao tầm quan trọng của quá trình cải tiến phần mềm.
• mô tả mô hình trưởng thành năng lực (CMM).

74 qui trình phần mềm là cách chúng tôi sản xuất phần mềm. nó kết hợp các phương pháp
(phần 1.11) với phần mềm cơ bản mô hình vòng đời của nó (chương 2) và kỹ thuật,
các công cụ chúng tôi sử dụng (phần 5.6 thông qua 5,12), và quan trọng nhất của tất cả, các cá nhân
xây dựng phần mềm.
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 các vấn đề của tài liệu
. một số tổ chức xem xét các phần mềm mà họ sản xuất được selfdocumenting; đó là, sản phẩm có thể được hiểu đơn giản bằng cách đọc mã nguồn.
Các tổ chức khác,Tuy nhiên, các tài liệu chuyên sâu. họ punctiliously lập
tiết kỹ thuật và kiểm tra xem chúng có phương pháp. sau đó họ thực hiện các hoạt động thiết kế cẩn thận, kiểm tra và kiểm tra lại thiết kế của họ trước khi mã hóa bắt đầu, và cung cấp cho giới thiệu rộng rãi
của mỗi hiện vật mã để các lập trình viên. trường hợp kiểm tra được kế hoạch trước, kết quả của mỗi
chạy thử đăng nhập,và các dữ liệu thử nghiệm là fi tỉ mỉ dẫn đi. khi sản phẩm
đã được chuyển giao và được cài đặt trên máy tính của khách hàng, bất kỳ đề nghị thay đổi phải được đề nghị bằng văn bản, với lý do chi tiết để thực hiện sự thay đổi. đề nghị thay đổi có thể được thực hiện chỉ với
ủy quyền bằng văn bản, và cation modifi 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à thay đổi các tài liệu đã được phê duyệt.
3 chương trình phần mềm 75
cường độ của thử nghiệm là một biện pháp mà các tổ chức có thể được so sánh. một số tổ chức
dành một nửa ngân sách phần mềm của họ để kiểm thử phần mềm, trong khi những người khác
cảm thấy rằng chỉ có người dùng hoàn toàn có thể kiểm tra sản phẩm. do đó, một số công ty dành
thời gian tối thiểu và công sức để thử nghiệm sản phẩm nhưng chi tiêu một số lượng đáng kể thời gian
vấn đề fi xing báo cáo của người dùng.
Postdelivery bảo trì là một mối bận tâm lớn của nhiều tổ chức phần mềm.
Phần mềm đó là 10, 15, hoặc thậm chí 20 tuổi liên tục tăng cường để đáp ứng nhu cầu thay đổi
, ngoài ra, lỗi còn lại tiếp tục xuất hiện,ngay cả sau khi các phần mềm đã được duy trì thành công trong nhiều năm. gần như tất cả các tổ chức di chuyển phần mềm của họ mới
phần cứng mỗi 3 đến 5 năm, điều này cũng tạo thành bảo trì postdelivery.
Ngược lại, nhưng về cơ bản các tổ chức khác có liên quan với nghiên cứu, để lại
phát triển-hãy để một mình bảo trì cho người khác. này áp dụng đặc biệt là các trường đại học
ngành khoa học máy tính, nơi sinh viên tốt nghiệp xây dựng phần mềm để chứng minh rằng một thiết kế hoặc kỹ thuật đặc biệt là khả thi. khai thác thương mại của khái niệm xác nhận là trái với các tổ chức khác. (Xem chỉ trong trường hợp bạn muốn biết hộp 3.1 về
các sự khác biệt lớn trong cách tổ chức khác nhau phát triển phần mềm.)
Tuy nhiên, không phụ thuộc vào thủ tục chính xác,quá trình phát triển phần mềm được
cấu trúc xung quanh các quy trình công việc của năm con số 2.4: yêu cầu, phân tích (đặc điểm kỹ thuật), thiết kế, thực hiện và thử nghiệm. trong chương này, các quy trình công việc được mô tả
, cùng với những thách thức tiềm năng 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 các phần mềm thường là không tầm thường,và phần còn lại của cuốn sách này là dành cho việc mô tả kỹ thuật phù hợp. trong
Phần đầu của chương này, chỉ có những thách thức được đánh dấu, nhưng người đọc được hướng dẫn
vào các phần có liên quan hoặc các chương cho các giải pháp. theo đó, phần này của chương
không chỉ là một cái nhìn tổng quan của quá trình phần mềm, nhưng một hướng dẫn để nhiều phần còn lại của cuốn sách
.chương kết thúc với sáng kiến ​​quốc gia và quốc tế để nâng cao
trình phần mềm.
Bây giờ chúng tôi kiểm tra quá trình thống nhất.
Chỉ trong trường hợp bạn muốn biết hộp 3.1
tại sao quá trình phần mềm khác nhau rất quyết liệt từ các tổ chức để tổ chức? a
lý do chính là thiếu các kỹ năng công nghệ phần mềm. tất cả các chuyên gia phần mềm quá nhiều
đơn giản là không giữ cho đến ngày.họ tiếp tục phát triển phần mềm Ye Olde thời
cách, bởi vì họ biết không có cách nào khác.
Một lý do cho sự khác biệt trong quá trình phần mềm là nhiều nhà quản lý phần mềm
là người quản lý xuất sắc nhưng biết quý chút về phát triển phần mềm hoặc bảo trì. họ thiếu kiến ​​thức kỹ thuật có thể dẫn đến các dự án trượt rất tệ sau
lịch trình mà không có điểm trong việc tiếp tục. này thường là lý do tại sao nhiều dự án phần mềm
không bao giờ hoàn thành.
Có một lý do cho sự khác biệt giữa các quá trình là triển vọng quản lý. cho
Ví dụ, một tổ chức có thể quyết định rằng nó là tốt hơn để cung cấp một sản phẩm trên thời gian, ngay cả khi nó không
được kiểm tra đầy đủ. cho các trường hợp giống hệt nhau, một tổ chức khác nhau có thể
kết luận rằng nguy cơ của việc cung cấp sản phẩm đó mà không cần kiểm tra toàn diện sẽ là lớn hơn nhiều so
dành thời gian để kiểm tra sản phẩm kỹ lưỡng và do đó cung cấp
nó muộn.
76part một khái niệm công nghệ phần mềm
3,1 quá trình thống nhất
như đã nêu ở phần đầu của chương này, phương pháp là một trong những thành phần của một phần mềm
quá trình.các đối tượng theo định hướng phương pháp chính hiện nay là quá trình thống nhất.
như được giải thích trong chỉ trong trường hợp bạn muốn biết hộp 3.2, Unifi ed "quá trình" thực sự là một phương pháp
, nhưng tên phương pháp thống nhất đã được đã được sử dụng như tên gọi của phiên bản
fi tiên của mô hình ngôn ngữ Unifi ed (UML). ba tiền thân của
quá trình Unifi ed (OMT, phương pháp Booch của,và objectory) không còn được hỗ trợ, và
các phương pháp hướng đối tượng khác đã có ít hoặc không có sau. kết quả là, các quá trình thống nhất
thường là sự lựa chọn chính ngày hôm nay để sản xuất phần mềm hướng đối tượng. may mắn thay, như sẽ được chứng minh trong phần b của cuốn sách này, quá trình Unifi ed là một phương pháp
hướng đối tượng xuất sắc trong hầu hết mọi cách.
quá trình thống nhất không phải là một loạt c specifi các bước, nếu theo sau, sẽ dẫn đến việc
xây dựng một sản phẩm phần mềm. trên thực tế, không có như vậy đơn "một kích thước phù hợp với tất cả các" phương pháp
có thể tồn tại vì nhiều loại sản phẩm phần mềm. ví dụ, có rất 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.
Cũng,một phương pháp đổ xô một gói giường ra thị trường trước đối thủ cạnh tranh của nó là
khác nhau từ sử dụng để xây dựng một mạng lưới chuyển tiền điện tử bảo mật cao. trong
Ngoài ra, các kỹ năng của các chuyên gia phần mềm có thể rất khác nhau.
Thay vào đó, quá trình ed Unifi nên được xem như là một phương pháp thích nghi. nghĩa là, nó là
ed modifi cho các sản phẩm phần mềm c ​​specifi được phát triển.chúng ta sẽ thấy trong phần b,
một số tính năng của quá trình Unifi ed là áp dụng cho những phần mềm nhỏ và thậm chí quy mô vừa
. Tuy nhiên, phần lớn quá trình Unifi ed được sử dụng cho các sản phẩm phần mềm của tất cả các kích cỡ.
Nhấn mạnh trong cuốn sách này là tập hợp con trên này phổ biến của quá trình thống nhất, nhưng các khía cạnh của quá trình
Unifi ed 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 vấn đề cần được giải quyết khi sản phẩm phần mềm lớn được xây dựng là
đánh giá kỹ lưỡng.
3,2 lặp đi lặp lại và incrementation trong
mô hình hướng đối tượng
mô hình hướng đối tượng sử dụng mô hình trong suốt. một modelis một tập hợp các sơ đồ 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 được phát triển. (Uml
sơ đồ được giới thiệu trong chương 7.) Nhớ lại rằng UML là viết tắt của Unifi ed mô hình ngôn ngữ. có nghĩa là, uml là công cụ mà chúng ta sử dụng để đại diện cho (mô hình) sản phẩm phần mềm mục tiêu.
Một lý do chính cho việc sử dụng một đại diện đồ họa như uml được thể hiện tốt nhất bằng cách cũ
câu tục ngữ, một bức tranh trị giá một ngàn chữ. sơ đồ UML cho phép các chuyên gia phần mềm
để giao tiếp với nhau một cách nhanh chóng hơn và chính xác hơn nếu chỉ bằng lời nói
thiệu đã được sử dụng.
Mô hình hướng đối tượng là một phương pháp lặp đi lặp lại-và-gia tăng. mỗi công việc bao gồm một số bước, và để thực hiện mà workfl ow, các bước của quy trình làm việc được lặp đi lặp lại
thực hiện 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 sản phẩm phần mềm mà họ muốn phát triển. có nghĩa là, ngay cả những chuyên gia
phần mềm giàu kinh nghiệm nhất lặp và lặp lại cho đến khi cuối cùng
hài lòng rằng các sơ đồ UML là chính xác. ngụ ý là kỹ sư phần mềm, không
chỉ trong trường hợp bạn muốn biết hộp 3.2
cho đến gần đây,các phương pháp phát triển phần mềm hướng đối tượng phổ biến nhất là mô hình đối tượng
kỹ thuật (OMT) [Rumbaugh et al., 1991] và phương pháp Grady Booch của
[Booch, 1994]. OMT được phát triển bởi Rumbaugh jim và nhóm của ông tại trung tâm nghiên cứu và phát triển điện chung trong schenectady, new york, trong khi Grady Booch
phát triển phương pháp của mình tại hợp lý, inc., trong Santa Clara, California.tất cả các phương pháp phát triển phần mềm hướng đối tượng cơ bản là tương đương, vì vậy sự khác biệt giữa
OMT và phương pháp Booch của nhỏ. tuy nhiên, có luôn luôn là một sự cạnh tranh thân thiện
giữa những người ủng hộ của hai phe.

Kết quả (Việt) 2:

Trình phần mềm
mục tiêu học tập
sau khi nghiên cứu chương này, bạn sẽ có thể
• giải thích tại sao đời hai chiều mô hình rất quan trọng.
• Mô tả fi ve lõi workfl ows của quá trình thống nhất.
• Danh sách các hiện vật được thử nghiệm trong công việc thử nghiệm.
• Mô tả bốn giai đoạn của quá trình thống nhất.
• Giải thích sự khác biệt giữa workfl ows và các giai đoạn của sự thống nhất
quá trình.
• Đánh giá cao tầm quan trọng của phần mềm quá trình cải tiến.
• Mô tả các mô hình trưởng thành khả năng (CMM).
74
Trình phần mềm là cách chúng tôi sản xuất phần mềm. Nó kết hợp phương pháp với các mô hình vòng đời cơ bản phần mềm (chương 2) và kỹ thuật,
(Section 1.11)
Các công cụ chúng tôi sử dụng (phần 5.6 thông qua 5.12), và quan trọng nhất của tất cả, các cá nhân
xây dựng phần mềm.
Khác nhau các tổ chức có quá trình phần mềm khác nhau. Ví dụ, hãy xem xét các
các vấn đề của tài liệu hướng dẫn. Một số tổ chức xem xét phần mềm họ sản xuất là selfdocumenting; có nghĩa là, các sản phẩm có thể được hiểu chỉ đơn giản bằng cách đọc mã nguồn.
Các tổ chức, Tuy nhiên, những tài liệu chuyên sâu. Họ punctiliously xây dựng
thông số kỹ thuật và phương pháp kiểm tra xem chúng. Sau đó họ thực hiện thiết kế hoạt động sửa chữa, kiểm tra và kiểm tra lại thiết kế của họ trước khi mã hóa bắt đầu, và cung cấp cho phong phú
mô tả của mỗi mã artifact để các lập trình viên. Trường hợp thử nghiệm được preplanned, kết quả
của mỗi bài kiểm tra chạy được ghi nhật ký, và dữ liệu thử nghiệm tỉ mỉ fi dẫn đi. Một sản phẩm
đã được chuyển giao và cài đặt trên máy tính của khách hàng, bất kỳ đề nghị thay đổi phải được đề nghị bằng văn bản, với các lý do chi tiết cho việc thực hiện thay đổi. Sự thay đổi được đề xuất có thể
thực hiện chỉ với văn ủy quyền, và cation bổ không được tích hợp vào các sản phẩm
cho đến khi các tài liệu đã được Cập Nhật và thay đổi tài liệu được phê duyệt.
Chương 3 phần mềm quá trình 75
cường độ của thử nghiệm là một biện pháp mà tổ chức có thể được so sánh. Một số
tổ chức dành lên đến một nửa ngân sách phần mềm của họ để thử nghiệm phần mềm, trong khi những người khác
cảm thấy rằng chỉ có người sử dụng triệt để có thể kiểm tra một sản phẩm. Do đó, một số công ty dành
tối thiểu thời gian và nỗ lực để thử nghiệm các sản phẩm nhưng chi tiêu một số lượng đáng kể thời gian
fi xing vấn đề báo cáo của người dùng.
Postdelivery bảo trì là một sự lo lắng chính của nhiều phần mềm tổ chức.
Phần mềm đó là 10, 15, hoặc thậm chí 20 năm cũ đã được liên tục nâng cấp để đáp ứng thay đổi
nhu cầu; Ngoài ra, còn lại lỗi tiếp tục xuất hiện, ngay cả sau khi các phần mềm đã được duy trì thành công trong nhiều năm. Hầu hết các tổ chức di chuyển phần mềm của họ để mới hơn
phần cứng mỗi 3-5 năm; Điều này, quá, tạo thành postdelivery bảo trì.
Ngược lại, được tổ chức khác về cơ bản có liên quan với nghiên cứu, để lại
phát triển — Hãy để một mình bảo dưỡng-để những người khác. Điều này áp dụng đặc biệt để đại học
máy tính khoa học sở, nơi sinh viên tốt nghiệp xây dựng phần mềm để chứng minh rằng một thiết kế đặc biệt hoặc kỹ thuật là khả thi. Khai thác thương mại xác nhận khái niệm còn lại cho các tổ chức khác. (Xem chỉ trong trường hợp bạn muốn biết hộp 3.1 liên quan đến
các biến thể rộng trong các tổ chức khác nhau cách phát triển phần mềm.)
Tuy nhiên, bất kể các thủ tục chính xác, quá trình phát triển phần mềm là
cấu trúc xung quanh thành phố năm quy trình công việc của con số 2.4: yêu cầu, phân tích (kỹ thuật), thiết kế, thực hiện, và thử nghiệm. Trong chương này, các quy trình công việc
miêu tả, cùng với tiềm năng thách thức mà có thể phát sinh trong mỗi công việc.
Giải pháp để thách thức liên quan đến sản xuất phần mềm thường được nontrivial, và phần còn lại của cuốn sách này dành cho mô tả kỹ thuật thích hợp. Trong các
đầu tiên một phần của chương này, chỉ những thách thức được đánh dấu, nhưng người đọc được định hướng
phần có liên quan hoặc chương cho giải pháp. Vì vậy, đây là một phần của chương
không chỉ là một tổng quan của quá trình phần mềm, nhưng một hướng dẫn để hầu hết phần còn lại của các
cuốn sách. Chương kết luận với các sáng kiến quốc gia và quốc tế để cải thiện các
quá trình phần mềm.
Chúng tôi bây giờ kiểm tra quá trình thống nhất.
Chỉ trong trường hợp bạn muốn biết hộp 5.0
tại sao trình phần mềm nào khác nhau các tổ vì vậy đáng kể từ tổ chức để chức? A
lý do chính là thiếu các kỹ năng công nghệ phần mềm. Tất cả các chuyên gia phần mềm quá nhiều
chỉ đơn giản là không Cập Nhật. Họ tiếp tục phát triển phần mềm Ye Olde thời
cách, bởi vì họ biết không có cách nào khác.
Một lý do cho sự khác biệt trong quá trình phần mềm là nhiều phần mềm quản lý
quản lý tuyệt vời nhưng biết quý giá ít về phát triển phần mềm hoặc bảo trì. Của họ thiếu kiến thức kỹ thuật có thể dẫn đến dự án trượt vì vậy nặng phía sau
lịch trình là không có điểm trong tiếp tục. Điều này thường là lý do tại sao nhiều
dự án phần mềm không bao giờ được hoàn thành.
Được nêu ra một lý do cho sự khác biệt giữa quá trình là quản lý outlook. Cho
ví dụ, một tổ chức có thể quyết định rằng nó là tốt hơn để cung cấp một sản phẩm về thời gian, ngay cả khi
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 nhau có thể
kết luận rằng nguy cơ của việc cung cấp sản phẩm đó mà không cần thử nghiệm toàn diện sẽ là
đến nay lớn hơn dành thời gian để kiểm tra các sản phẩm kỹ lưỡng và do đó cung cấp
nó trễ.
76Part A công nghệ phần mềm khái niệm
5.0 trong tiến trình thống nhất
như đã nêu ở đầu của chương này, phương pháp là một phần của một phần mềm
quá trình. Phương pháp hướng đối tượng chính vào ngày hôm qua là quá trình hợp nhất. Như
giải thích tại chỉ cần trong trường hợp bạn muốn biết hộp 3.2, Unifi ed "Quá trình" là thực sự
một phương pháp, nhưng tên thống nhất phương pháp đã có được sử dụng như tên
của phiên bản rst fi Unifi ed mô hình Language(UML). Tiền chất ba của
trình Unifi ed (OMT, phương pháp của Booch, và Objectory) không còn được hỗ trợ, và
các phương pháp theo định hướng đối tượng khác đã có ít hoặc không có sau. Kết quả là, các
quá trình hợp nhất thường là sự lựa chọn chính vào ngày hôm nay cho sản xuất phần mềm hướng đối tượng. May mắn thay, như sẽ được chứng minh trong phần B của cuốn sách này, trình Unifi ed là một
phương pháp tuyệt vời hướng đối tượng trong gần như mọi cách.
Quá trình thống nhất không phải là một loạt c thuật bước mà, nếu sau đó sẽ dẫn đến các
xây dựng của một sản phẩm phần mềm. Trong thực tế, không có phương pháp phù hợp duy nhất "một kích thước với tất cả" như vậy
có thể tồn tại vì sự đa dạng trong các 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à sản xuất.
Ngoài ra, một phương pháp để đổ xô một gói cũi trẻ em để thị trường phía trước của đối thủ cạnh tranh là
mạng chuyển khoản điện tử khác nhau từ một trong những sử dụng để xây dựng một bảo mật cao. Ở
bổ sung, các kỹ năng của các chuyên gia phần mềm có thể thay đổi rộng rãi.
Thay thế, trình Unifi ed nên được xem như là một phương pháp thích nghi. Có nghĩa là, nó
là bổ ed cho sản phẩm phần mềm c thuật được phát triển. Như sẽ được nhìn thấy trong phần B,
một số tính năng của trình Unifi ed là không thể dùng được để nhỏ - và thậm chí còn quy mô trung bình
phần mềm. Tuy nhiên, phần lớn trình Unifi ed được sử dụng cho sản phẩm phần mềm thuộc mọi quy mô.
Sự nhấn mạnh trong cuốn sách này là ngày này tập hợp con chung của quá trình thống nhất, nhưng các khía cạnh
của quá trình Unifi ed áp dụng đối với chỉ phần mềm quy mô lớn cũng được thảo luận, để đảm bảo
những vấn đề cần được giải quyết khi lớn hơn các sản phẩm phần mềm được xây dựng được
triệt để đánh giá cao nhất.
3.2 Lặp đi lặp lại và Incrementation trong
mô hình Object-Oriented
mô hình hướng đối tượng sử dụng mô hình trong suốt. Một modelis một tập hợp các UML sơ đồ đại diện cho một hoặc nhiều khía cạnh của sản phẩm phần mềm được phát triển. (UML
sơ đồ được giới thiệu trong chương 7.) Thu hồi UML là viết tắt của Unifi ed mô hình ngôn ngữ. Có nghĩa là, UML là công cụ mà chúng tôi sử dụng để đại diện cho (mô hình) sản phẩm phần mềm của mục tiêu.
Một lý do chính cho việc sử dụng một đại diện đồ họa như UML tốt nhất được thể hiện bởi cũ
câu tục ngữ, một bức tranh là giá trị một ngàn chữ. UML sơ đồ sử các chuyên gia phần mềm
để giao tiếp với nhau hơn một cách nhanh chóng và chính xác hơn hơn nếu chỉ nói
mô tả đã được sử dụng.
Các mô hình hướng đối tượng là một phương pháp lặp đi lặp lại-và-gia tăng. Quy trình làm việc mỗi bao gồm một số các bước, và thực hiện ra rằng workfl ow, các bước công việc
liên tục được thực hiện cho đến khi các thành viên của nhóm phát triển được hài lòng mà
họ có một mô hình UML chính xác của sản phẩm phần mềm mà họ muốn phát triển. Có nghĩa là,
thậm chí có phần mềm chuyên gia giàu kinh nghiệm nhất lặp và nhắc lại cho đến khi cuối cùng
hài lòng rằng UML sơ đồ là chính xác. Ngụ ý ở đây là phần mềm đó kỹ sư, no
chỉ trong trường hợp bạn muốn biết hộp 5.1
cho đến gần đây, phương pháp phổ biến nhất phát triển phần mềm hướng đối tượng
đối tượng mô hình hóa kỹ thuật (OMT) [Rumbaugh và ctv., 1991] và phương pháp Grady Booch
[Booch, 1994]. OMT được phát triển bởi Jim Rumbaugh và nhóm của ông tại Trung tâm phát triển ở Schenectady, New York, và nghiên cứu điện nói chung trong khi Grady Booch
phát triển phương pháp của ông tại hữu tỉ, Inc, hạt Santa Clara, California. Tất cả các phương pháp phát triển phần mềm hướng đối tượng chủ yếu là tương đương, do đó sự khác biệt giữa
OMT và Booch của phương pháp là nhỏ. Tuy nhiên, có luôn luôn là một thù địch
giữa những người ủng hộ của hai phe.