The nature of software products is

The nature of software products is such that virtually everything has to be developed
iteratively and incrementally. After all, software engineers are human, and therefore subject
to Miller’s Law (Section 2.5). That is, it is impossible to consider everything at the same time,
so just seven or so chunks (units of information) are handled initially. Then, when the next set
of chunks is considered, more knowledge about the target software product is gained, and the
UML diagrams are modifi ed in the light of this additional information. The process continues
in this way until eventually the software engineers are satisfi ed that all the models for a given
workfl ow are correct. In other words, initially the best possible UML diagrams are drawn in the
light of the knowledge available at the beginning of the workfl ow. Then, as more knowledge
about the real-world system being modeled is gained, the diagrams are made more accurate
(iteration) and extended (incrementation). Accordingly, no matter how experienced and skillful
a software engineer may be, he or she repeatedly iterates and increments until satisfi ed that the
UML diagrams are an accurate representation of the software product to be developed.
Ideally, by the end of this book, the reader would have the software engineering skills
necessary for constructing the large, complex software products for which the Unifi ed Process was developed. Unfortunately, there are three reasons why this is not feasible.
1. Just as it is not possible to become an expert on calculus or a foreign language in one
single course, gaining profi ciency in the Unifi ed Process requires extensive study and,
more important, unending practice in object-oriented software engineering.
2. The Unifi ed Process was created primarily for use in developing large, complex software products. To be able to handle the many intricacies of such software products, the
Unifi ed Process is itself large. It would be hard to cover every aspect of the Unifi ed
Process in a textbook of this size.
3. To teach the Unifi ed Process, it is necessary to present a case study that illustrates the
features of the Unifi ed Process. To illustrate the features that apply to large software
products, such a case study would have to be large. For example, just the specifi cations
typically would take over 1000 pages.
For these three reasons, this book presents most, but not all, of the Unifi ed Process.
The fi vecore workfl ows of the Unified Process (requirements workfl ow, analysis
workfl ow, design workfl ow, implementation workfl ow, and test workfl ow) and their challenges are now discussed.
3.3 The Requirements Workfl ow
Software development is expensive. The development process usually begins when the
client approaches a development organization with regard to a software product that, in
the opinion of the client, is either essential to the profi tability of his or her enterprise or
somehow can be justifi ed economically. The aim of therequirements workfl ow is for
the development organization to determine the client’s needs. The fi rst task of the development team is to acquire a basic understanding of theapplication domain (domain for
short), that is, the specifi c environment in which the target software product is to operate.
The domain could be banking, automobile manufacturing, or nuclear physics.
sch76183_ch03_074-106.indd 78 04/06/10 6:35 PM
Chapter 3 The Software Process 79
At any stage of the process, if the client stops believing that the software will be cost
effective, development will terminate immediately. Throughout this chapter the assumption
is made that the client feels that the cost is justifi ed. Therefore, a vital aspect of software
development is thebusiness case , a document that demonstrates the cost-effectiveness of
the target product. (In fact, the “cost” is not always purely fi nancial. For example, military
software often is built for strategic or tactical reasons. Here, the cost of the software is the
potential damage that could be suffered in the absence of the weapon being developed.)
At an initial meeting between client and developers, the client outlines the product as
he or she conceptualizes it. From the viewpoint of the developers, the client’s description
of the desired product may be vague, unreasonable, contradictory, or simply impossible
to achieve. The task of the developers at this stage is to determine exactly what the client
needs and to fi nd out from the client what constraints exist.
• A major constraint is almost always thedeadline . For example, the client may stipulate
that the finished product must be completed within 14 months. In almost every application
domain, it is now commonplace for a target software product to be mission critical. That
is, the client needs the software product for core activities of his or her organization, and
any delay in delivering the target product is detrimental to the organization.
• A variety of other constraints often are present, such asreliability (for example, the
product must be operational 99 percent of the time, or the mean time between failures
must be at least 4 months). Another common constraint is the size of the executable load
image (for example, it has to run on the client’s personal computer or on the hardware
inside the satellite).
• Thecost is almost invariably an important constraint. However, the client rarely tells
the developers how much money is available to build the product. Instead, a common
practice is that, once the specifi cations have been fi nalized, the client asks the developers
to name their price for completing the project. Clients follow this bidding procedure in
the hope that the amount of the developers’ bid is lower than the amount the client has
budgeted for the project.
The preliminary investigation of the client’s needs sometimes is calledconcept exploration . In subsequent meetings between members of the development team and the client
team, the functionality of the proposed product is successively refi ned and analyzed for
technical feasibility and fi nancial justifi cation.
Up to now, everything seems to be straightforward. Unfortunately, the requirements
workfl ow often is performed inadequately. When the product fi nally is delivered to the
user, perhaps a year or two after the specifi cations have been signed off on by the client, the
client may say to the developers, “I know that this is what I asked for, but it isn’t really what
I wanted.” What the client asked for and, therefore, what the developers thought the client
wanted, was not what the client actuallyneeded . There can be a number of reasons for this
predicament. First, the client may not truly understand what is going on in his or her own
organization. For example, it is no use asking the software developers for a faster operating
system if the cause of the current slow turnaround is a badly designed database. Or, if the
client operates an unprofi table chain of retail stores, the client may ask for a fi nancial management information system that refl ects such items as sales, salaries, accounts payable,
and accounts receivable. Such a product will be of little use if the real reason for the losses
sch76183_ch03_074-106.indd 79 04/06/10 6:35 PM
is shrinkage (theft by employees and shoplifting). If that is the case, then a stock control
system rather than a fi nancial management information system is required.
But the major reason why the client frequently asks for the wrong product is that software is complex. If it is diffi cult for a software professional to visualize a piece of software
and its functionality, the problem is far worse for a client who is barely computer literate.
As will be shown in Chapter 11 , the Unifi ed Process can help in this regard; the many UML
diagrams of the Unifi ed Process assist the client in gaining the necessary detailed understanding of what needs to be developed.
3.4 The Analysis Workfl ow
The aim of theanalysis workfl ow is to analyze and refine the requirements to achieve
the detailed understanding of the requirements essential for developing a software product
correctly and maintaining it easily. At fi rst sight, however, there is no need for an analysis
workfl ow. Instead, an apparently simpler way to proceed would be to develop a software
product by continuing with further iterations of the requirements workfl ow until the necessary understanding of the target software product has been obtained.
The key point is that the output of the requirements workfl ow must be totally comprehended by the client. In other words, the artifacts of the requirements workfl ow must be
expressed in the language of the client, that is, in a natural (human) language such as English,
Armenian, or Zulu. But all natural languages, without exception, are somewhat imprecise and
lend themselves to misunderstanding. For example, consider the following paragraph:
A part record and a plant record are read from the database. If it contains the letter A directly
followed by the letter Q, then calculate the cost of transporting that part to that plant.
At fi rst sight, this requirement seems perfectly clear. But to what doesit (the second
word in the second sentence) refer: the part record, the plant record, or the database?
Ambiguities of this kind cannot arise if the requirements are expressed (say) in a mathematical notation. However, if a mathematical notation is used for the requirements, then
the client is unlikely to understand much of the requirements. As a result, there may well be
miscommunication between client and developers regarding the requirements, and consequently, the software product developed to satisfy those requirements may not be what the
client needs.
The solution is to have two separate workfl ows. The requirements workfl ow is couched

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

Bản chất của sản phẩm phần mềm là như vậy mà hầu như tất cả mọi thứ đã được phát triểnlặp đi lặp lại và từng bước. Sau khi tất cả, kỹ sư phần mềm là con người, và do đó chủ đềMiller của luật (phần 2,5). Có nghĩa là, nó là không thể để xem xét tất cả mọi thứ cùng một lúc,Vì vậy chỉ bảy hoặc hơn khối (đơn vị thông tin) được xử lý ban đầu. Sau đó, khi tiếp theo thiết lậpkhối xem xét, thêm kiến thức về sản phẩm phần mềm mục tiêu đạt được, và cácUML sơ đồ là bổ ed trong ánh sáng của thông tin bổ sung này. Quá trình tiếp tụcbằng cách này cho đến khi cuối cùng phần mềm kỹ sư có satisfi ed mà tất cả các mô hình cho một nhất địnhworkfl ow là chính xác. Nói cách khác, ban đầu tốt nhất có thể UML sơ đồ được rút ra trong cácánh sáng của sự hiểu biết có sẵn ở đầu workfl ow. Sau đó, như thêm kiến thứcvề thế giới thực hệ thống được mô phỏng đã đạt được, các sơ đồ được thực hiện chính xác hơn(lặp đi lặp lại) và mở rộng (incrementation). Vì vậy, không có vấn đề làm thế nào có kinh nghiệm và khéo léomột kỹ sư phần mềm có thể là, thì liên tục iterates và gia số cho đến khi satisfi ed mà cácUML sơ đồ là một đại diện chính xác của sản phẩm phần mềm được phát triển. Lý tưởng nhất, đến cuối cuốn sách này, người đọc sẽ có các kỹ năng công nghệ phần mềmcần thiết để xây dựng các sản phẩm phần mềm lớn, phức tạp mà trình Unifi ed đã được phát triển. Thật không may, có những ba lý do tại sao điều này là không khả thi. 1. cũng giống như nó là không thể trở thành một chuyên gia về giải tích hoặc một ngôn ngữ nước ngoài trong mộtkhóa học duy nhất, đạt profi ciency trong quá trình Unifi ed yêu cầu nghiên cứu sâu rộng và,quan trọng hơn, sự thực hành trong công nghệ phần mềm hướng đối tượng. 2. quá trình Unifi ed được tạo ra chủ yếu để sử dụng trong việc phát triển sản phẩm phần mềm lớn, phức tạp. Để có thể xử lý các intricacies nhiều của các sản phẩm phần mềm, cácQuá trình UniFi ed là chính nó lớn. Nó sẽ là khó khăn để trang trải mọi khía cạnh của Unifi edQuá trình trong một sách giáo khoa của kích thước này. 3. để dạy trình Unifi ed, nó là cần thiết để trình bày một nghiên cứu trường hợp minh hoạ cáctính năng của quá trình Unifi ed. Để minh họa các tính năng mà áp dụng cho phần mềm lớnsản phẩm, một nghiên cứu trường hợp nào phải được lớn. Ví dụ, chỉ là các cation thuậtthông thường sẽ có hơn 1000 trang. Vì những lý do ba, cuốn sách này trình bày đặt, nhưng không phải tất cả, của quá trình Unifi ed. Fi vecore workfl ows của quá trình thống nhất (yêu cầu workfl ow, phân tíchworkfl ow, thiết kế workfl ow, thực hiện workfl ow, và kiểm tra workfl ow) và thách thức của họ bây giờ đã thảo luận. 3.3 Workfl yêu cầu ow Phát triển phần mềm là tốn kém. Quá trình phát triển thường bắt đầu khi cáckhách hàng phương pháp 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 đó, trongý kiến của các khách hàng, là một trong hai điều cần thiết để tability profi của doanh nghiệp của mình hoặcbằng cách nào đó có thể là justifi ed về kinh tế. Mục đích của therequirements workfl ow là chotổ chức phát triển để xác định nhu cầu của khách hàng. Nhiệm vụ rst fi nhóm phát triển là để có được một sự hiểu biết cơ bản của theapplication tên miền (tên miền chongắn), có nghĩa là, thuật c môi trường trong đó sản phẩm phần mềm mục tiêu là để hoạt động.Tên miền có thể là ngân hàng, ô tô, sản xuất, hoặc vật lý hạt nhân.sch76183_ch03_074-106.indd 78 04/06/10 6:35 PM3 chương trình phần mềm 79 Tại bất kỳ giai đoạn của quá trình, nếu khách hàng dừng lại tin rằng các phần mềm sẽ có chi phíhiệu quả, phát triển sẽ chấm dứt ngay lập tức. Trong suốt chương này giả địnhđược thực hiện rằng các khách hàng cảm thấy rằng chi phí là justifi ed. Do đó, là một khía cạnh quan trọng của phần mềmphát triển là trường hợp thebusiness, một tài liệu chứng minh hiệu quả chi phí củasản phẩm mục tiêu. (Trong thực tế, "chi phí" không phải là luôn luôn hoàn toàn fi quầy. Ví dụ, quân sựphần mềm thường được xây dựng cho lý do chiến lược hoặc chiến thuật. Ở đây, chi phí của phần mềm là cácthiệt hại tiềm năng mà có thể được bị trong sự vắng mặt của các loại vũ khí được phát triển.) Tại một cuộc họp Ban đầu giữa khách hàng và nhà phát triển, các khách hàng tóm tắt các sản phẩm nhưhọ conceptualizes nó. Từ quan điểm của các nhà phát triển, mô tả của khách hàngsản phẩm mong muốn có thể mơ hồ, không hợp lý, mâu thuẫn, hoặc chỉ đơ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àngnhu cầu và fi nd ra từ các khách hàng hạn chế những gì tồn tại.• Một hạn chế lớn là hầu như luôn luôn thedeadline. Ví dụ, khách hàng có thể quy địnhrằng sản phẩm hoàn tất phải được hoàn thành trong vòng 14 tháng. Trong hầu hết ứng dụngtên miền, nó bây giờ là phổ biến cho một sản phẩm phần mềm mục tiêu là nhiệm vụ quan trọng. Rằnglà, khách hàng cần sản phẩm phần mềm cho hoạt động cốt lõi của tổ chức của mình, vàbất kỳ sự chậm trễ trong việc cung cấp sản phẩm mục tiêu là bất lợi cho tổ chức.• Một loạt các hạn chế khác thường trình bày, như vậy asreliability (ví dụ, cácsản phẩm phải là hoạt động 99 phần trăm của thời gian, hoặc mean time between thất bạiphải là ít nhất là 4 tháng). Hạn chế phổ biến khác là kích thước của tải thực thihình ảnh (ví dụ, nó đã để chạy trên máy tính cá nhân của khách hàng hoặc trên phần cứngbên trong các vệ tinh).• Thecost gần như không thay đổi là một hạn chế quan trọng. Tuy nhiên, các khách hàng hiếm khi nói vớiCác nhà phát triển bao nhiêu tiền có sẵn để xây dựng các sản phẩm. Thay vào đó, một phổ biếnthực tế là, một khi các cation thuật đã là fi nalized, khách hàng yêu cầu các nhà phát triểnđể đặt tên giá của họ để hoàn thành dự án. Khách hàng thực hiện theo quy trình này đặt giá thầu trongHy vọng rằng số lượng các nhà phát triển giá thầu là thấp hơn số tiền khách hàng đãngân sách cho các dự án. Điều tra sơ bộ của nhu cầu của khách hàng đôi khi là calledconcept thăm dò. 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à khách hàngđội, các chức năng của các sản phẩm được đề nghị là liên tục refi ned và phân tích chokỹ thuật tính khả thi và fi quầy justifi cation. Đến nay, tất cả mọi thứ có vẻ là đơn giản. Thật không may, các yêu cầuworkfl ow thường được thực hiện không đầy đủ. Khi sản phẩm fi nally được gửi đến cácngười dùng, có lẽ một hoặc hai năm sau khi cation thuật đã được ký vào bởi các khách hàng, cáckhách hàng có thể nói cho 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 phải là thực sự 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àngmuốn, không phải là những gì khách hàng actuallyneeded. Có thể có một số lý do cho điều nàytình trạng khó khăn. Trước tiên, khách hàng có thể không thật sự hiểu những gì đang xảy ra tại của mình hoặc mìnhtổ chức. Ví dụ, nó là không có sử dụng yêu cầu các nhà phát triển phần mềm cho một hoạt động nhanh hơnHệ thống nếu nguyên nhân của hiện tại quay vòng chậm là một cơ sở dữ liệu thiết kế xấu. Hoặc, nếu cáckhách hàng hoạt động một bảng unprofi chuỗi cửa hàng bán lẻ, khách hàng có thể yêu cầu một fi quầy thông tin hệ thống quản lý đó ects refl các mặt hàng như bán hàng, tiền lương, tài khoản phải nộp,và tài khoản phải thu. Một sản phẩm sẽ sử dụng ít nếu thực sự lý do cho những thiệt hạisch76183_ch03_074-106.indd 79 04/06/10 6:35 PMlà co rút (hành vi trộm cắp của nhân viên và trộm). Nếu đó là trường hợp, sau đó một kiểm soát chứng khoánHệ thống chứ không phải là một fi quầy quản lý thông tin hệ thống được yêu cầu. Nhưng lý do chính tại sao khách hàng thường xuyên yêu cầu cho các sản phẩm sai là phần mềm phức tạp. Nếu nó là khó tôn giáo cho một phần mềm chuyên nghiệp để hình dung một phần mềmvà chức năng của nó, vấn đề là đến nay tồi tệ hơn cho một khách hàng người là hiếm khi máy tính biết chữ.Như sẽ được hiển thị trong chương 11, trình Unifi ed có thể giúp đỡ về vấn đề này; UML nhiềuSơ đồ của quá trình Unifi ed hỗ trợ khách hàng trong việc đạt được sự hiểu biết chi tiết cần thiết của những gì cần phải được phát triển. 3.4 phân tích Workfl ow Mục đích của theanalysis workfl ow là để phân tích và tinh chỉnh các yêu cầu để đạt đượcsự 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ềmmột cách chính xác và duy trì nó một cách dễ dàng. Nhìn rst fi, Tuy nhiên, có là không cần thiết cho một phân tíchworkfl ow. Thay vào đó, một cách rõ ràng đơn giản để tiến hành sẽ là để phát triển một phần mềmsản phẩm bằng cách tiếp tục với thêm lặp của yêu cầu workfl ow cho đến khi đã thu được sự hiểu biết cần thiết của sản phẩm phần mềm của mục tiêu. Điểm mấu chốt là rằng đầu ra yêu cầu workfl ow phải được hoàn toàn comprehended bởi các khách hàng. Nói cách khác, những đồ tạo tác của yêu cầu workfl ow phảibày tỏ bằng ngôn ngữ của khách hàng, có nghĩa là, trong một ngôn ngữ tự nhiên (con người) chẳng hạn như tiếng Anh,Tiếng Armenia, hoặc Zulu. Nhưng tất cả các ngôn ngữ tự nhiên, không có ngoại lệ, phần nào không chính xác vàcho vay mình để sự hiểu lầm. Ví dụ, hãy xem xét đoạn sau đây: Một hồ sơ phần và một kỷ lục thực vật được đọc từ cơ sở dữ liệu. Nếu nó có chứa chữ cái một trực tiếptheo sau chữ Q, sau đó tính toán chi phí vận chuyển một phần để thực vật đó. Nhìn rst fi, yêu cầu này có vẻ hoàn toàn rõ ràng. Nhưng những gì doesit (lần thứ haitừ trong câu thứ hai) là: phần hồ sơ, Hồ sơ thực vật hoặc cơ sở dữ liệu? Ambiguities của loại này không thể xảy ra nếu các yêu cầu được thể hiện (nói) 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, sau đókhách hàng là dường như không biết nhiều về các yêu cầu. Kết quả là, có cũng có thểmiscommunication giữa khách hàng và nhà phát triển liên quan đến các yêu cầu, và kết quả là, các sản phẩm phần mềm phát triển để đáp ứng những yêu cầu có thể không là những gì cáckhách hàng cần. Giải pháp là phải có hai riêng biệt workfl ows. Workfl yêu cầu ow viễn

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

Bản chất của các sản phẩm phần mềm là như vậy mà hầu như tất cả mọi thứ đã được phát triển
và từng bước lặp đi lặp lại. Sau khi tất cả, kỹ sư phần mềm cũng là con người, và do đó đề
Luật Miller (Phần 2.5). Đó là, nó là không thể xem xét tất cả mọi thứ cùng một lúc,
vì vậy chỉ cần bảy hay nên khối (đơn vị thông tin) được xử lý ban đầu. Sau đó, khi các tập tiếp theo
của khối được coi là, thêm kiến thức về các sản phẩm phần mềm là đã đạt được mục tiêu, và các
sơ đồ UML là ed modifi trong ánh sáng của thông tin bổ sung này. Quá trình này tiếp tục
theo cách này cho đến khi cuối cùng các kỹ sư phần mềm là ed satisfi rằng tất cả các mô hình cho một định
ow workfl là chính xác. Nói cách khác, ban đầu các sơ đồ UML tốt nhất có thể được rút ra trong
ánh sáng của tri thức có sẵn ở đầu của ow workfl. Sau đó, như thêm kiến thức
về các hệ thống thực tế được mô hình đã đạt được, các sơ đồ được thực hiện chính xác hơn
(lặp lại) và mở rộng (incrementation). Theo đó, không có vấn đề như thế nào có kinh nghiệm và tay nghề cao
là một kỹ sư phần mềm có thể được, anh ta hoặc cô liên tục lặp và tăng cho đến khi satisfi ed rằng các
sơ đồ UML là đại diện chính xác của sản phẩm phần mềm được phát triển.
Lý tưởng nhất, vào cuối của cuốn sách này, người đọc sẽ có những kỹ năng kỹ thuật phần mềm
cần thiết cho việc xây dựng, các sản phẩm phần mềm lớn và phức tạp mà các Process ed Unifi đã được phát triển. Thật không may, có ba lý do tại sao điều này là không khả thi.
1. Chỉ vì nó không thể trở thành một chuyên gia về tính toán hay một ngoại ngữ trong một
khóa học duy nhất, đạt profi tính hiệu trong quá trình ed Unifi đòi hỏi nghiên cứu sâu rộng và,
quan trọng hơn, thực hành bất tận trong hướng đối tượng công nghệ phần mềm.
2. Quá trình ed Unifi đã được tạo ra chủ yếu để sử dụng trong việc phát triển lớn, các sản phẩm phần mềm phức tạp. Để có thể xử lý nhiều vấn đề phức tạp của sản phẩm phần mềm như vậy, các
Process ed Unifi là thân lớn. Nó sẽ là khó để trang trải mọi khía cạnh của ed Unifi
trình trong sách giáo khoa của các kích thước này.
3. Để dạy các Process ed Unifi, nó là cần thiết để trình bày một nghiên cứu trường hợp để minh họa các
tính năng của Process ed Unifi. Để minh họa cho các tính năng mà áp dụng cho phần mềm lớn
các sản phẩm, một nghiên cứu trường hợp như vậy sẽ phải lớn. Ví dụ, chỉ cần các cation specifi
thường có thể mất hơn 1000 trang.
Đối với ba lý do, cuốn sách này trình bày nhất, nhưng không phải tất cả, của Process ed Unifi.
Các fi vecore workfl OWS của Unified Process (yêu cầu workfl ow, phân tích
workfl ow, thiết kế workfl ow, thực hiện workfl ow, và thử nghiệm workfl ow) và thách thức của họ đang thảo luận.
3.3 Yêu cầu Workfl ow
phát triển phần mềm là đắt. Quá trình phát triển thường bắt đầu khi các
khách hàng tiếp cận một tổ chức phát triển đối với một sản phẩm phần mềm, với
các ý kiến của khách hàng, hoặc là cần thiết để các tability profi của doanh nghiệp của mình hoặc
bằng cách nào đó có thể được ed justifi kinh tế. Mục đích của therequirements workfl ow là dành cho
các tổ chức phát triển để xác định nhu cầu của khách hàng. Nhiệm vụ đầu tiên kinh của nhóm phát triển là để có được một sự hiểu biết cơ bản của miền theapplication (domain cho
ngắn), có nghĩa là, môi trường c specifi trong đó các sản phẩm phần mềm mục tiêu là để hoạt động.
Các tên miền có thể là ngân hàng, sản xuất ô tô, hoặc vật lý hạt nhân.
sch76183_ch03_074-106.indd 78 04/06/10 06:35
Chương 3 Quá trình phần mềm 79
Ở bất kỳ giai đoạn của quá trình, nếu khách hàng ngừng tin tưởng rằng phần mềm sẽ được chi phí
hiệu quả, 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í là ed justifi. Do đó, một khía cạnh quan trọng của phần mềm
phát triển là trường hợp thebusiness, một tài liệu chứng minh các chi phí-hiệu quả của
các sản phẩm mục tiêu. (Trong thực tế, "chi phí" không phải lúc nào cũng hoàn toàn tài chính fi. Ví dụ, quân sự
phần mềm thường được xây dựng vì những lý do chiến lược hay chiến thuật. Ở đây, chi phí của phần mềm là
khả năng thiệt hại có thể được đau khổ trong sự vắng mặt của các vũ khí đang được phát triển.)
Tại một cuộc họp ban đầu giữa khách hàng và các nhà phát triển, khách hàng vạch ra các sản phẩm như
anh hay cô quan niệm đó. Từ quan điểm của các nhà phát triển, mô tả của khách hàng
về các sản phẩm mong muốn có thể được mơ hồ, bất hợp lý, mâu thuẫn, hoặc chỉ đơ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
với nhu cầu và fi nd ra từ các khách hàng những gì hạn chế tồn tại.
• Một hạn chế lớn là hầu như luôn luôn thedeadline. Ví dụ, khách hàng có thể quy định
rằng các sản phẩm thành phẩm phải được hoàn thành trong vòng 14 tháng. Trong hầu hết các ứng dụng
tên miền, nó bây giờ là phổ biến cho một sản phẩm phần mềm mục tiêu là nhiệm vụ quan trọng. Đó
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 của tổ chức của mình, và
bất kỳ sự chậm trễ trong việc cung cấp các sản phẩm mục tiêu là bất lợi cho tổ chức.
• Một loạt các hạn chế khác thường, có mặt, asreliability đó (ví dụ, các
sản phẩm phải được hoạt động 99 phần trăm thời gian, hoặc thời gian trung bình giữa các sự cố
phải có ít nhất 4 tháng). Một khó khăn thường gặp là kích thước của phụ tải thực thi
hình ảnh (ví dụ, nó có thể chạy trên máy tính cá nhân của khách hàng hoặc trên các phần cứng
bên trong các vệ tinh).
• Thecost là hầu như 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 bao nhiêu tiền có sẵn để xây dựng các sản phẩm. Thay vào đó, một phổ biến
thực tế là, một khi các cation specifi đã được nalized fi, các khách hàng yêu cầu các nhà phát triển
để đặt tên cho giá của họ để hoàn thành dự án. Khách hàng theo thủ tục đấu thầu này trong
hy vọng rằng số lượng thầu của nhà phát triển là thấp hơn so với số tiền khách hàng đã
lập ngân sách cho dự án.
Các điều tra sơ bộ về nhu cầu của khách hàng đôi khi là thăm dò calledconcept. 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à khách hàng
nhóm, các chức năng của các sản phẩm được đề xuất là tiếp Refi ned và phân tích
tính khả thi về kỹ thuật và tài chính cation justifi.
Cho đến nay, tất cả mọi thứ có vẻ là đơn giản. Thật không may, các yêu cầu
workfl OW thường được thực hiện không đầy đủ. Khi nally sản phẩm fi được giao cho
người sử dụng, có thể một hoặc hai sau khi các cation specifi đã được ký tắt vào của khách hàng năm, các
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ó là không thực sự 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 actuallyneeded. Có thể có một số lý do cho việc này
khó khăn. Đầu tiên, khách hàng có thể không thực sự hiểu những gì đang xảy ra ở riêng của mình
tổ chức. Ví dụ, nó không sử dụng yêu cầu các nhà phát triển phần mềm cho một hoạt động nhanh hơn
hệ thống nếu các nguyên nhân của sự thay đổi hoàn toàn chậm hiện nay là một cơ sở dữ liệu thiết kế xấu. Hoặc, nếu các
khách hàng hoạt động một chuỗi bảng unprofi của các cửa hàng bán lẻ, khách hàng có thể yêu cầu cho một hệ thống thông tin quản lý tài chính mà refl phản hạng mục như bán hàng, tiền lương, các khoản phải nộp,
và các khoản phải thu. Một sản phẩm như vậy sẽ không mấy tác dụng nếu các lý do thực sự cho những tổn thất
sch76183_ch03_074-106.indd 79 04/06/10 18:35
là co rút (vi trộm cắp của nhân viên và trộm cắp). Nếu đó là trường hợp, sau đó một điều khiển chứng khoán
hệ thống chứ không phải là một hệ thống thông tin quản lý tài chính là cần thiết.
Nhưng lý do chính tại sao các khách hàng thường xuyên yêu cầu cho các sản phẩm sai là phần mềm đó là phức tạp. Nếu nó là sùng bái diffi cho một phần mềm chuyên nghiệp để hình dung một phần của phần mềm
và chức năng của nó, vấn đề là còn tồi tệ hơn đối với một khách hàng người hầu như không biết chữ máy tính.
Như sẽ được trình bày trong Chương 11, Quá trình ed Unifi có thể giúp đỡ trong vấn đề này ; UML nhiều
sơ đồ của quá trình ed Unifi hỗ trợ khách hàng trong việc đạt được sự hiểu biết chi tiết cần thiết về những gì cần phải được phát triển.
3.4 Phân tích Workfl ow
Mục đích của theanalysis workfl ow là phân tích và tinh chỉnh các yêu cầu để đạt được
sự hiểu biết chi tiết về yêu cầu cần thiết cho việc 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. Tại fi đầu tiên nhìn thấy, tuy nhiên, không có nhu cầu cho một phân tích
ow workfl. Thay vào đó, một cách rõ ràng đơn giản để tham gia thảo luận sẽ được phát triển một phần mềm
sản phẩm bằng cách tiếp tục lặp đi lặp lại với thêm các yêu cầu workfl OW cho đến khi sự hiểu biết cần thiết về các sản phẩm phần mềm mục tiêu đã được thu được.
Điểm mấu chốt là đầu ra của các yêu cầu workfl ow phải được hoàn toàn thấu hiểu khách hàng. Nói cách khác, các hiện vật của các yêu cầu workfl ow phải được
thể hiện bằng ngôn ngữ của khách hàng, đó là, trong một tự nhiên (con người) ngôn ngữ như tiếng Anh,
tiếng Armenia, hoặc 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à
cho vay mình để hiểu lầm. Ví dụ, hãy xem xét các khoản sau đây:
Một kỷ lục một phần và một kỷ lục thực vật được đọc từ các cơ sở dữ liệu. Nếu nó có chứa các chữ A trực
tiếp bằng chữ Q, sau đó tính toán các chi phí vận chuyển một phần cho nhà máy đó.
Tại fi tiên cảnh, yêu cầu này có vẻ hoàn toàn rõ ràng. Nhưng với những gì doesit (thứ hai
từ trong câu thứ hai) tham khảo: kỷ lục một phần, hồ sơ nhà máy, hay các cơ sở dữ liệu
sự mơ hồ của loại hình này không thể xảy ra nếu các yêu cầu được bày tỏ (nói) 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, sau đó
khách hàng có thể không hiểu được nhiều yêu cầu. Kết quả là, cũng có thể là
sự hiểu lầm giữa khách hàng và các nhà phát triển về các yêu cầu, và do đó, các sản phẩm phần mềm được phát triển để đáp ứng những yêu cầu có thể không được những gì các
nhu cầu của khách hàng.
Giải pháp là phải có hai OWS workfl riêng biệt. Các yêu cầu workfl ow được diễn đạt