3.8 Postdelivery Maintenance Postde

3.8 Postdelivery Maintenance
Postdelivery maintenance is not an activity grudgingly carried out after the product has been
delivered and installed on the client’s computer. On the contrary, it is an integral part of the
software process that must be planned for from the beginning. As explained in Section 3.5,
the design, as far as is feasible, should take future enhancements into account. Coding must be
performed with future maintenance kept in mind. After all, as pointed out in Section 1.3, more
money is spent on postdelivery maintenance than on all other software activities combined.
It therefore is a vital aspect of software production. Postdelivery maintenance must never be
treated as an afterthought. Instead, the entire software development effort must be carried out in
such a way as to minimize the impact of the inevitable future postdelivery maintenance.
A common problem with postdelivery maintenance is documentation or, rather, lack of it.
In the course of developing software against a time deadline, the original analysis and design
artifacts frequently are not updated and, consequently, are almost useless to the maintenance
team. Other documentation such as the database manual or the operating manual may never
be written, because management decided that delivering the product to the client on time was
more important than developing the documentation in parallel with the software. In many
instances, the source code is the only documentation available to the maintainer. The high rate
of personnel turnover in the software industry exacerbates the maintenance situation, in that
none of the original developers may be working for the organization at the time when maintenance is performed. Postdelivery maintenance frequently is the most challenging aspect of
software production for these reasons and the additional reasons given in Chapter 16 .
Turning now to testing, there are two aspects to testing changes made to a product when
postdelivery maintenance is performed. The fi rst is checking that the required changes have
been implemented correctly. The second aspect is ensuring that, in the course of making
the required changes to the product, no other inadvertent changes were made. Therefore,
once the programmer has determined that the desired changes have been implemented, the
product must be tested against previous test cases to make certain that the functionality
of the rest of the product has not been compromised. This procedure is calledregression testing . To assist in regression testing, it is necessary that all previous test cases be
retained, together with the results of running those test cases. Testing during postdelivery
maintenance is discussed in greater detail in Chapter 16 .
A major aspect of postdelivery maintenance is a record of all the changes made, together
with the reason for each change. When software is changed, it has to be regression tested.
Therefore, the regression test cases are a central form of documentation.
sch76183_ch03_074-106.indd 87 04/06/10 6:35 PM
88 Part A Software Engineering Concepts
3.9 Retirement
The fi nal stage in the software life cycle isretirement . After many years of service, a stage
is reached when further postdelivery maintenance no longer is cost effective.
• Sometimes the proposed changes are so drastic that the design as a whole would have
to be changed. In such a case, it is less expensive to redesign and recode the entire
product.
• So many changes may have been made to the original design that interdependencies
inadvertently have been built into the product, and even a small change to one minor
component might have a drastic effect on the functionality of the product as a whole.
• The documentation may not have been adequately maintained, thereby increasing the
risk of a regression fault to the extent that it would be safer to recode than maintain.
• The hardware (and operating system) on which the product runs is to be replaced; it may
be more economical to reimplement from scratch than to modify.
In each of these instances the current version is replaced by a new version, and the software process continues.
True retirement, on the other hand, is a somewhat rare event that occurs when a product
has outgrown its usefulness. The client organization no longer requires the functionality
provided by the product, and it fi nally is removed from the computer.
3.10 The Phases of the Unifi ed Process
Figure 3.1 differs from Figure 2.4 in that the labels of the increments have been changed.
Instead of Increment A, Increment B, and so on, the four increments are now labeled
Inception phase, Elaboration phase, Construction phase, and Transition phase. In
other words, the phases of the Unifi ed Process correspond to increments.
FIGURE 3.1
The core
workfl ows and
the phases of
the Unifi ed
Process.
Requirements
workflow
Analysis
workflow
Design
workflow
Implementation
workflow
Test
workflow
Time
Person-hours
Inception
phase
Elaboration
phase
Construction
phase
Transition
phase
sch76183_ch03_074-106.indd 88 04/06/10 6:35 PM
Chapter 3 The Software Process 89
Although in theory the development of a software product could be performed in any
number of increments, development in practice often seems to consist of four increments.
The increments or phases are described in Sections 3.10.1 through 3.10.4, together with the
deliverables of each phase, that is, the artifacts that should be completed by the end of that
phase.
Every step performed in the Unifi ed Process falls into one of fi ve core workfl ows and
also into one of four phases, the inception phase, elaboration phase, construction phase,
and transition phase. The various steps of these four phases are already described in Sections 3.3 through 3.7. For example, building a business case is part of the requirements
workfl ow (Section 3.3). It is also part of the inception phase. Nevertheless, each step has to
be considered twice, as will be explained.
Consider the requirements workfl ow. To determine the client’s needs, one of the steps
is, as just stated, to build a business case. In other words, within the framework of the
requirements workfl ow, building a business case is presented within atechnical context. In
Section 3.10.1, a description is presented of building a business case within the framework
of the inception phase, the phase in which management decides whether or not to develop
the proposed software product. That is, building a business case shortly is presented within
aneconomic context (Section 1.2).
At the same time, there is no point in presenting each step twice, both times at the same
level of detail. Accordingly, the inception phase is described in depth to highlight the difference between the technical context of the workfl ows and the economic context of the
phases, but the other three phases are simply outlined.
3.10.1 The Inception Phase
The aim of theinception phase (first increment) is to determine whether it is worthwhile
to develop the target software product. In other words, the primary aim of this phase is to
determine whether the proposed software product is economically viable.
Two steps of the requirements workfl ow are to understand the domain and build a
business model. Clearly, there is no way the developers can give any kind of opinion
regarding a possible future software product unless they fi rst understand the domain in
which they are considering developing the target software product. It does not matter if
the domain is a television network, a machine tool company, or a hospital specializing in
liver disease—if the developers do not fully understand the domain, little reliance can be
placed on what they subsequently build. Hence, the fi rst step is to obtain domain knowledge. Once the developers have a full comprehension of the domain, the second step is
to build a business model, that is, a description of the client’s business processes. In
other words, the fi rst need is to understand the domain itself, and the second need is to
understand precisely how the client organization operates in that domain.
Now the scope of the target project has to be delimited. For example, consider a proposed software product for a new highly secure ATM network for a nationwide chain
of banks. The size of the business model of the banking chain as a whole is likely to be
huge. To determine what the target software product should incorporate, the developers
have to focus on only a subset of the business model, namely, the subset covered by the
proposed software product. Therefore, delimiting the scope of the proposed project is the
third step.
sch76183_ch03_074-106.indd 89 04/06/10 6:35 PM
90 Part A Software Engineering Concepts
Now the developers can begin to make the initial business case. The questions that
need to be answered before proceeding with the project include [Jacobson, Booch, and
Rumbaugh, 1999]:
• Is the proposed software product cost effective? That is, will the benefits to be gained
as a consequence of developing the software product outweigh the costs involved? How
long will it take to obtain a return on the investment needed to develop the proposed
software product? Alternatively, what will be the cost to the client if he or she decides
not to develop the proposed software product? If the software product is to be sold in the
marketplace, have the necessary marketing studies been performed?
• Can the proposed software product be delivered in time? That is, if the software product
is delivered late to the market, will the organization still make a profi t or will a competitive software product obtain the lion’s share of the market? Alternatively, if the software
product is to be developed to support the client organization’s own activities (presumably including mission-critical activities), what is the impact if the proposed software
product is delivered late?
• What risks are involved in developing the software product, and how can thes

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

3.8 postdelivery bảo trì Postdelivery bảo trì không phải là một hoạt động miễn cưỡng thực hiện sau khi sản phẩm đãchuyển giao 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 của cácquy trình phần mềm phải được lên kế hoạch cho từ đầu. Như được diễn tả trong phần 3.5,thiết kế, như xa như là khả thi, nên đưa các cải tiến trong tương lai vào tài khoản. Mã hóa phảithực hiện với tương lai bảo trì giữ trong tâm trí. Sau khi tất cả, như chỉ ra ở phần 1.3, hơntiền được chi postdelivery bảo trì hơn trên tất cả các hoạt động phần mềm kết hợp.Do đó nó là một khía cạnh quan trọng của sản xuất phần mềm. Postdelivery bảo trì không bao giờ phảiđược coi là một suy nghĩ lại. Thay vào đó, các nỗ lực phát triển toàn bộ phần mềm phải được thực hiện tạimột cách để giảm thiểu tác động của việc duy trì postdelivery trong tương lai không thể tránh khỏi. Một vấn đề phổ biến với postdelivery bảo trì là tài liệu hoặc thay vào đó, thiếu của nó.Trong quá trình phát triển phần mềm chống lại một thời hạn thời gian, ban đầu phân tích và thiết kếhiện vật thường không được Cập Nhật và, do đó, gần như vô dụng cho việc duy trìđội. Tài liệu khác chẳng hạn như cơ sở dữ liệu hướng dẫn sử dụng hoặc hướng dẫn sử dụng hoạt động có thể không bao giờđược viết, vì quản lý đã quyết định rằng cung cấp sản phẩm cho khách hàng về thời gian làquan trọng hơn phát triển tài liệu hướng dẫn song song với phần mềm. Trong nhiềutrường hợp, mã nguồn là các tài liệu duy nhất có sẵn để duy trì. Mức caonhân viên của doanh thu trong ngành công nghiệp phần mềm trầm trọng thêm tình hình bảo trì, trong đókhông ai trong số các nhà phát triển ban đầu có thể làm việc cho tổ chức vào thời điểm khi bảo trì được thực hiện. Postdelivery bảo trì thường xuyên là một khía cạnh thách thức nhất củaphần mềm sản phẩm dùng cho những lý do và lý do bổ sung được đưa ra trong chương 16. Biến hiện nay để thử nghiệm, có hai khía cạnh để thử nghiệm các thay đổi được thực hiện cho một sản phẩm khipostdelivery bảo dưỡng được thực hiện. Fi rst kiểm tra rằng những thay đổi cần thiết cóđược thực hiện một cách chính xác. Các khía cạnh thứ hai đảm bảo rằng, trong quá trình làmnhững thay đổi cần thiết để các sản phẩm, không có thay đổi vô ý khác đã được thực hiện. Do đó,một khi các lập trình viên đã xác định rằng những thay đổi mong muốn đã được thực hiện, cácsản phẩm phải được kiểm tra đối với trường hợp thử nghiệm trước đó để làm cho chắc chắn rằng các chức năngphần còn lại của sản phẩm đã không bị xâm nhập. Thủ tục này là calledregression thử nghiệm. Để hỗ trợ trong việc hồi qui kiểm tra, nó là cần thiết rằng tất cả các trường hợp thử nghiệm trước đógiữ lại, cùng với các kết quả của chạy những trường hợp thử nghiệm. Kiểm tra trong postdeliverybảo trì được thảo luận chi tiết hơn trong chương 16. Một khía cạnh lớn của postdelivery bảo trì là một kỷ lục của tất cả các thay đổi được thực hiện, với nhauvới những lý do cho mỗi thay đổi. Khi phần mềm được thay đổi, nó đã là hồi qui kiểm tra.Vì vậy, trường hợp kiểm tra hồi quy là một hình thức Trung tâm của tài liệu hướng dẫn.sch76183_ch03_074-106.indd 87 04/06/10 6:35 PM88 phần một khái niệm công nghệ phần mềm3.9 nghỉ hưu Các giai đoạn nal fi trong isretirement vòng đời của phần mềm. Sau nhiều năm phục vụ, một giai đoạnđạt đến khi xa hơn bảo trì postdelivery không còn là hiệu quả chi phí.• Đôi khi những thay đổi được đề xuất là rất mạnh mẽ rằng thiết kế như một toàn thể sẽ cóphải được thay đổi. Trong trường hợp này, nó là ít tốn kém để thiết kế lại và recode toàn bộsản phẩm.• Thay đổi rất nhiều có thể đã được thực hiện với bản gốc thiết kế đó lẫnvô tình đã được xây dựng vào sản phẩm, và thậm chí là một thay đổi nhỏ cho một tiểuthành phần có thể có một tác động mạnh mẽ các chức năng của các sản phẩm như một toàn thể.• Các tài liệu có thể không có được đầy đủ được duy trì, do đó làm tăng cácnguy cơ của một hồi quy lỗi đến mức mà nó sẽ an toàn hơn để recode hơn duy trì.• Phần cứng (và điều hành hệ thống) trên đó sản phẩm chạy là phải được thay thế; nó có thểlà kinh tế hơn để reimplement từ đầu hơn để sửa đổi. Trong mỗi trường hợp các phiên bản hiện tại được thay thế bởi một phiên bản mới, và tiếp tục quá trình phần mềm. Thật sự nghỉ hưu, mặt khác, là một sự kiện hơi hiếm xảy ra khi một sản phẩmđã outgrown tính hữu dụng của nó. Tổ chức khách hàng không còn yêu cầu các chức năngcung cấp bởi các sản phẩm, và nó fi nally được lấy ra khỏi máy tính. 3.10 các giai đoạn của quá trình Unifi ed Con số 3.1 khác với con số 2.4 trong đó các nhãn các gia số đã được thay đổi.Thay vì tăng A, tăng B, và như vậy, từng bước 4 bây giờ có nhãnGiai đoạn khởi động, giai đoạn xây dựng, xây dựng giai đoạn và giai đoạn chuyển tiếp. Ởnói cách khác, các giai đoạn của quá trình Unifi ed tương ứng với từng bước.CON SỐ 3.1Cốt lõiworkfl ows vàCác giai đoạn củaUnifi edQuá trình.Yêu cầuquy trình làm việcPhân tíchquy trình làm việcThiết kếquy trình làm việcThực hiệnquy trình làm việcThử nghiệmquy trình làm việcThời gianPerson-hoursKhởi đầugiai đoạnXây dựnggiai đoạnXây dựnggiai đoạnChuyển tiếpgiai đoạnsch76183_ch03_074-106.indd 88 04/06/10 6:35 PM3 chương trình phần mềm 89 Mặc dù trong lý thuyết sự phát triển của một sản phẩm phần mềm có thể được thực hiện trong bất kỳsố lượng gia số, phát triển trong thực tế thường có vẻ bao gồm bốn bước tăng.Từng bước hoặc giai đoạn được mô tả trong phần 3.10.1 thông qua 3.10.4, cùng với cácphân phôi mỗi giai đoạn có nghĩa là, những đồ tạo tác mà nên được hoàn thành vào cuối màgiai đoạn. Từng bước thực hiện trong quá trình Unifi ed rơi vào một trong fi ve lõi workfl ows vàcũng vào một trong bốn giai đoạn, giai đoạn khởi động, xây dựng giai đoạn, 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 đã được mô tả trong phần 3.3 thông qua 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 yêu cầuworkfl ow (phần 3.3). Nó cũng là một phần của giai đoạn khởi động. Tuy nhiên, mỗi bước đãđược xem xét hai lần, như sẽ được giải thích. Hãy xem xét yêu cầu workfl ow. Để xác định nhu cầu của khách hàng, một trong những bướclà, như chỉ nói, để xây dựng một trường hợp kinh doanh. Nói cách khác, trong khuôn khổ của cácyêu cầu workfl ow, xây dựng một trường hợp kinh doanh được trình bày trong bối cảnh atechnical. ỞPhần 3.10.1, mô tả một trình bày của xây dựng một trường hợp kinh doanh trong khuôn khổtrong giai đoạn khởi động, giai đoạn trong đó quản lý quyết định có hay không để phát triểnsản phẩm phần mềm được đề xuất. Có nghĩa là, xây dựng một trường hợp kinh doanh một thời gian ngắn được trình bày trong vònganeconomic các bối cảnh (phần 1,2). Cùng lúc đó, có là không có điểm trong trình bày mỗi bước hai lần, cả hai lần đồngmức độ chi tiết. Theo đó, giai đoạn khởi động được mô tả trong chiều sâu để làm nổi bật sự khác biệt giữa bối cảnh kỹ thuật của workfl ows và bối cảnh kinh tế của cácgiai đoạn, nhưng ba giai đoạn khác chỉ đơn giản là được trình bày. 3.10.1 giai đoạn khởi động Mục đích của giai đoạn theinception (đầu tiên tăng) là để xác định xem nó là đáng giáđể phát triển sản phẩm phần mềm của mục tiêu. Nói cách khác, mục đích chính của giai đoạn này là đểxác định sản phẩm phần mềm được đề xuất là kinh tế khả thi. Hai bước yêu cầu workfl ow là để hiểu các tên miền và xây dựng mộtMô hình kinh doanh. Rõ ràng, có là không có cách nào mà các nhà phát triển có thể cung cấp cho bất kỳ loại ý kiếnliên quan đến một sản phẩm phần mềm trong tương lai có thể trừ khi họ fi rst hiểu miền trongmà họ đang xem xét việc phát triển sản phẩm phần mềm của mục tiêu. Nó không quan trọng nếutên miền là một mạng lưới truyền hình, một công ty máy công cụ, hoặc một bệnh viện chuyênbệnh gan — nếu các nhà phát triển không hoàn toàn hiểu các tên miền, ít sự phụ thuộc có thểĐặt trên những gì họ sau đó xây dựng. Vì vậy, fi rst bước là để có được kiến thức tên miền. Một khi các nhà phát triển có một hiểu đầy đủ về các tên miền, bước thứ hai làđể xây dựng một mô hình kinh doanh, có nghĩa là, một mô tả về quy trình kinh doanh của khách hàng. Ởnói cách khác, fi rst cần là để hiểu tên miền riêng của mình, và yêu cầu thứ hai là đểhiểu chính xác làm thế nào khách hàng tổ chức hoạt động trong miền đó. Bây giờ, phạm vi của dự án mục tiêu đã được phân cách. 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 lưới ATM bảo mật cao mới cho một chuỗi toàn quốccủa ngân hàng. Kích thước của mô hình kinh doanh của chuỗi ngân hàng như một toàn thể là có khả năngrất lớn. Để xác định những gì các mục tiêu sản phẩm phần mềm nên kết hợp, các nhà phát triểnphải tập trung vào chỉ là một tập hợp con của mô hình kinh doanh, cụ thể là, tập hợp con bao phủ bởi cácsản phẩm phần mềm được đề xuất. Vì vậy, gác phạm vi của dự án đề xuất là cácBước thứ ba.sch76183_ch03_074-106.indd 89 04/06/10 6:35 PM90 phần một khái niệm công nghệ phần mềm Bây giờ các nhà phát triển có thể bắt đầu để làm cho trường hợp kinh doanh ban đầu. Những câu hỏi màcần phải được trả lời trước khi tiếp tục với các dự án bao gồm [Jacobson, Booch, vàRumbaugh, 1999]:• Là sản phẩm được đề nghị phần mềm chi phí hiệu quả? Có nghĩa là, sẽ lợi ích để đượcdo hậu quả của phát triển sản phẩm phần mềm lớn hơn chi phí liên quan? Làm thế nàonó sẽ mất lâu để có được một lợi tức đầu tư cần thiết để phát triển các đề xuấtsản phẩm phần mềm? Ngoài ra, những gì sẽ là chi phí cho khách hàng nếu họ quyết địnhkhông để phát triển các sản phẩm phần mềm được đề xuất? Nếu sản phẩm phần mềm được bán tại cácthị trường, có các nghiên cứu tiếp thị cần thiết thực hiện?• Có thể sản phẩm phần mềm được đề xuất được chuyển giao trong thời gian? Có nghĩa là, nếu các sản phẩm phần mềmđược gửi muộn vào thị trường, sẽ tổ chức vẫn làm cho một t profi hoặc sẽ có được một sản phẩm cạnh tranh phần mềm chia sẻ của sư tử của thị trường? Ngoài ra, nếu phần mềmsản phẩm là được phát triển để hỗ trợ các hoạt động của tổ chức khách hàng (bao gồm cả có lẽ là nhiệm vụ quan trọng hoạt động), những gì là những tác động nếu phần mềm được đề xuấtsản phẩm được phân phối muộn?• Những gì rủi ro có liên quan trong việc phát triển các sản phẩm phần mềm, và làm thế nào có thể thes

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

3.8 Postdelivery Bảo trì
Postdelivery bảo trì không phải là một hoạt động một cách miễn cưỡng thực hiện sau khi sản phẩm đã được
chuyển giao 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
quá trình phần mềm mà phải được quy hoạch ngay từ đầu. Như đã giải thích trong phần 3.5,
thiết kế, như xa như là khả thi, nên cải tiến trong tương lai vào tài khoản. Mã hóa phải được
thực hiện với bảo trì trong tương lai giữ trong tâm trí. Sau khi tất cả, như chỉ ra trong phần 1.3, nhiều
tiền được chi cho bảo trì postdelivery hơn trên 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ì Postdelivery không bao giờ được
coi là một suy nghĩ. Thay vào đó, các nỗ lực phát triển phần mềm toàn bộ phải được thực hiện trong
một cách như vậy là để giảm thiểu tác động của việc duy trì postdelivery không thể tránh khỏi trong tương lai.
Một vấn đề thường gặp với bảo trì postdelivery là tài liệu hướng dẫn hoặc, đúng hơn, thiếu nó.
Trong quá trình phát triển phần mềm chống một thời hạn thời gian, phân tích và thiết kế ban đầu
hiện vật thường không được cập nhật, và kết quả là gần như vô dụng để duy trì
đội bóng. Tài liệu khác như hướng dẫn cơ sở dữ liệu hoặc hướng dẫn vận hành có thể không bao giờ
được viết, vì quản lý quyết định rằng việc cung cấp các sản phẩm cho khách hàng về thời gian là
quan trọng hơn việc phát triển các tài liệu song song với phần mềm. Trong nhiều
trường hợp, các mã nguồn là tài liệu chỉ có sẵn cho nhà duy trì. Tỷ lệ cao
của kim ngạch nhân viên 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 dưỡng, trong đó
không ai trong số các nhà phát triển ban đầu có thể làm việc cho các tổ chức tại thời điểm bảo trì được thực hiện. Postdelivery bảo trì thường xuyên là các khía cạnh thách thức nhất của
sản xuất phần mềm cho những lý do này và các lý do khác được đưa ra trong Chương 16.
Biến ngay bây giờ để thử nghiệm, có hai khía cạnh để thay đổi thử nghiệm được thực hiện cho một sản phẩm khi
bảo trì postdelivery được thực hiện. Việc đầu tiên là kiểm tra fi rằng những thay đổi cần thiết đã
được thực hiện một cách chính xác. Khía cạnh thứ hai là đảm bảo rằng, trong quá trình thực hiện
những thay đổi cần thiết cho các sản phẩm, không có thay đổi vô ý khác đã được thực hiện. Vì vậy,
một khi các lập trình viên đã xác định rằng các thay đổi mong muốn đã được thực hiện, các
sản phẩm phải được thử nghiệm với trường hợp kiểm tra trước để chắc chắn rằng các chức năng
của phần còn lại của sản phẩm không bị tổn thương. Thủ tục này là thử nghiệm calledregression. Để hỗ trợ cho việc kiểm tra hồi quy, nó là cần thiết rằng tất cả các trường hợp kiểm tra trước đó được
giữ lại, cùng với kết quả khi chạy những trường hợp thử nghiệm. Kiểm định trong thời postdelivery
bảo trì được thảo luận chi tiết hơn trong Chương 16.
Một khía cạnh quan trọng của bảo trì postdelivery là một kỷ lục của tất cả các thay đổi được thực hiện, cùng
với lý do cho mỗi thay đổi. Khi phần mềm được thay đổi, nó phải được kiểm tra hồi quy.
Vì vậy, các trường hợp thử nghiệm hồi quy là một hình thức trung tâm của tài liệu.
Sch76183_ch03_074-106.indd 87 04/06/10 06:35
88 Part A Engineering Software Các khái niệm
3.9 Hưu Trí
Các fi giai đoạn nal trong chu kỳ isretirement đời phần mềm. Sau nhiều năm làm việc, một giai đoạn
đạt được khi bảo trì postdelivery thêm không còn là chi phí hiệu quả.
• Đôi khi những thay đổi được đề xuất là quá quyết liệt rằng thiết kế như một toàn thể sẽ phải
được thay đổi. Trong trường hợp này, nó ít tốn kém để thiết kế lại và mã hóa lại toàn bộ
sản phẩm.
• Vì vậy, nhiều thay đổi có thể được thực hiện để thiết kế ban đầu mà phụ thuộc lẫn nhau
vô tình đã được xây dựng thành các sản phẩm, và thậm chí là một thay đổi nhỏ cho một nhỏ
thành phần có thể có một hiệu ứng mạnh mẽ về các chức năng của các sản phẩm như một toàn thể.
• Các tài liệu có thể đã không được duy trì đầy đủ, do đó làm tăng
nguy cơ của một lỗi hồi quy đến mức mà nó sẽ được an toàn hơn để recode hơn duy trì.
• Các phần cứng (và điều hành hệ thống) mà trên đó các sản phẩm chạy là phải được thay thế; nó có thể
là kinh tế hơn để reimplement từ đầu hơn để sửa đổi.
Trong mỗi trường hợp này các phiên bản hiện tại được thay thế bằng một phiên bản mới, và các quá trình phần mềm vẫn tiếp tục.
Đúng nghỉ hưu, mặt khác, là một sự kiện rất hiếm xảy ra khi một sản phẩm
đã phát triển nhanh hơn hữu dụng của nó. Các tổ chức khách hàng không còn đòi hỏi các chức năng
được cung cấp bởi các sản phẩm, và nó fi nally được lấy ra từ máy tính.
3.10 Các giai đoạn của Unifi ed Process
Hình 3.1 khác với hình 2.4 trong đó các nhãn của các gia đã được thay đổi.
Thay vì Tăng A, Tăng B, và như vậy, các gia số bốn đang có nhãn
giai đoạn khởi động, Xây dựng giai đoạn, 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 quá trình Unifi ed tương ứng với số gia.
HÌNH 3.1
Các lõi
OWS workfl và
các giai đoạn của
các Unifi 88 04/06/10 06:35 Chương 3 Quá trình Phần mềm 89 Mặc dù trong lý thuyết phát triển của một sản phẩm phần mềm có thể được thực hiện trong bất kỳ số lượng gia tăng, phát triển trong thực tế thường dường như bao gồm bốn increments. Các gia hoặc pha là được mô tả trong mục 3.10.1 3.10.4 qua, cùng với sự phân phôi của từng giai đoạn, có nghĩa là, những đồ tạo tác nên được hoàn tất vào cuối năm đó giai đoạn. Mỗi bước thực hiện trong quá trình ed Unifi rơi vào một trong fi ve lõi OWS workfl và cũng vào một trong bốn giai đoạn, giai đoạn khởi động, giai đoạn xây dựng, giai đoạn thi công, và giai đoạn chuyển tiếp. Các bước khác nhau của bốn giai đoạn đã được mô tả trong Mục 3.3 thông qua 3,7. Ví dụ, việc xây dựng một trường hợp kinh doanh là một phần của các yêu cầu workfl ow (Phần 3.3). Nó cũng là một phần của giai đoạn khởi động. Tuy nhiên, mỗi bước phải được coi là hai lần, như sẽ được giải thích. Hãy xem xét các yêu cầu workfl ow. Để xác định nhu cầu của khách hàng, một trong những bước được, như chỉ nói, để xây dựng một trường hợp kinh doanh. Nói cách khác, trong khuôn khổ của các yêu cầu workfl ow, xây dựng một trường hợp kinh doanh được trình bày trong bối cảnh atechnical. Trong Phần 3.10.1, một mô tả được trình bày việc xây dựng một trường hợp kinh doanh trong khuôn khổ của giai đoạn khởi động, giai đoạn, trong đó quản lý quyết định có hay không để phát triển các sản phẩm phần mềm được đề nghị. Đó là, việc xây dựng một trường hợp kinh doanh trong thời gian ngắn được trình bày trong bối cảnh aneconomic (mục 1.2). Đồng thời, không có điểm trong việc trình bày từng bước hai lần, cả hai lần ở cùng một mức độ chi tiết. Theo đó, giai đoạn khởi động được mô tả trong chiều sâu để làm nổi bật sự khác biệt giữa các bối cảnh kỹ thuật của OWS workfl và bối cảnh kinh tế của các giai đoạn, nhưng ba giai đoạn khác chỉ đơn giản được vạch ra. 3.10.1 Các giai đoạn khởi động Mục đích của giai đoạn theinception ( tăng đầu tiên) là để xác định xem nó là đáng giá để phát triển các sản phẩm phần mềm mục tiêu. Nói cách khác, mục đích chính của giai đoạn này là để xác định xem các sản phẩm phần mềm được đề xuất là khả thi về mặt kinh tế. Hai bước trong những yêu cầu workfl OW là để hiểu các tên miền và xây dựng một mô hình kinh doanh. Rõ ràng, không có cách nào các nhà phát triển có thể cung cấp cho bất kỳ loại ý kiến về một sản phẩm phần mềm trong tương lai có thể, trừ khi họ fi đầu tiên hiểu được các miền trong mà họ đang xem xét việc phát triển các sản phẩm phần mềm mục tiêu. Nó không quan trọng nếu các tên miền là một mạng lưới truyền hình, một công ty máy công cụ, hoặc một bệnh viện chuyên về gan bệnh nếu các nhà phát triển không hoàn toàn hiểu tên miền, ít phụ thuộc có thể được đặt trên những gì sau đó họ xây dựng. Do đó, bước đầu tiên là để fi có được kiến thức miền. Một khi các nhà phát triển có một hiểu biết đầy đủ của tên miền, bước thứ hai là xây dựng một mô hình kinh doanh, đó là một mô tả về quá trình kinh doanh của khách hàng. Trong Nói cách khác, sự cần thiết phải gốc đầu tiên để hiểu được miền riêng của mình, và sự cần thiết thứ hai là để hiểu chính xác như thế nào các tổ chức khách hàng hoạt động trong lĩnh vực đó. Bây giờ phạm vi của dự án mục tiêu đã đượ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 lưới ATM an toàn cao mới cho một chuỗi toàn quốc của các ngân hàng. Kích thước của các mô hình kinh doanh của chuỗi ngân hàng nói chung có khả năng là rất lớn. Để xác định những sản phẩm phần mềm tiêu nên kết hợp, các nhà phát triển phải tập trung vào chỉ một tập hợp con của các mô hình kinh doanh, cụ thể là, các tập con được bao phủ bởi các sản phẩm phần mềm được đề nghị. Vì vậy, việc phân định phạm vi của dự án là bước thứ ba. Sch76183_ch03_074-106.indd 89 04/06/10 06:35 90 Part A Engineering Software khái niệm Bây giờ các nhà phát triển có thể bắt đầu thực hiện các trường hợp kinh doanh ban đầu. Các 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]: • Là phần mềm chi phí sản phẩm được đề xuất có hiệu quả? Đó là, sẽ lợi ích để đạt được như là một hệ quả của việc phát triển các sản phẩm phần mềm lớn hơn chi phí tham gia? Làm thế nào lâu để có được một lợi nhuận trên đầu tư cần thiết để phát triển các đề xuất sản phẩm phần mềm? Ngoài ra, những gì sẽ là chi phí cho khách hàng nếu họ quyết định không để phát triển các sản phẩm phần mềm được đề xuất? Nếu các sản phẩm phần mềm được bán ở các thị trường, đã nghiên cứu tiếp thị cần thiết được thực hiện? • các sản phẩm phần mềm được đề xuất có thể được giao trong thời gian? Đó là, nếu các sản phẩm phần mềm được phân phối muộn để thị trường, sẽ tổ chức thực hiện vẫn còn t profi hoặc một sản phẩm phần mềm cạnh tranh sẽ có được tỷ trọng của thị trường? Ngoài ra, nếu các phần mềm sản phẩm là được phát triển để hỗ trợ các hoạt động của các tổ chức của khách hàng (có lẽ bao gồm các hoạt động nhiệm vụ quan trọng), tác động nếu phần mềm đề xuất là những sản phẩm được giao muộn? • Những rủi ro có liên quan trong việc phát triển các sản phẩm phần mềm, và làm thế nào có thể thes