- Văn bản
- Lịch sử
Chapter3The Software Process Learni
Chapter3
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 Unifi ed Process.
• List the artifacts tested in the test workfl ow.
• Describe the four phases of the Unifi ed Process.
• Explain the difference between the workfl ows and the phases of the Unifi ed
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
specifi cations 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.
sch76183_ch03_074-106.indd 74 04/06/10 6:35 PM
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 fi ve workfl ows of Figure 2.4 : requirements, analysis (specifi cation), design, implementation, and testing. In this chapter, these workfl ows are
described, together with potential challenges that may arise during each workfl ow.
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
fi rst 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 Unifi ed 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.
sch76183_ch03_074-106.indd 75 04/06/10 6:35 PM
76 Part A Software Engineering Concepts
3.1 The Unifi ed Process
As stated at the beginning of this chapter, methodology is one component of a software
process. The primary object-oriented methodology today is theUnifi ed 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 Unifi ed Methodology already had been used as the name
of the fi rst version of theUnified Modeling Language (UML). The three precursors of
the Unified 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
Unifi ed 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 Unifi ed 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 fi ts 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 Unifi ed 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.2Iteration and Incrementation within
the Object-Oriented Paradigm
The object-oriented paradigm uses modeling throughout. Amodel is 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 edModeling 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 workfl ow consists of a number of steps, and to carry out that workfl ow, the steps of the workfl ow
are repeatedly performed until the members of the development team are satisfi ed 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 fi nally
satisfi ed that the UML diagrams are correct. The implication is that software engineers, no
sch76183_ch03_074-106.indd 76 10/06/10 2:11 PM
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.
This changed in October 1994, when Rumbaugh joined Booch at Rational. The two
methodologists immediately began to work together to develop a methodology that would
combine OMT and Booch’s method. When a preliminary version of their work was published, it was pointed out that they had not developed a methodology but merely a notation
for representing an object-orie
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 Unifi ed Process.
• List the artifacts tested in the test workfl ow.
• Describe the four phases of the Unifi ed Process.
• Explain the difference between the workfl ows and the phases of the Unifi ed
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
specifi cations 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.
sch76183_ch03_074-106.indd 74 04/06/10 6:35 PM
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 fi ve workfl ows of Figure 2.4 : requirements, analysis (specifi cation), design, implementation, and testing. In this chapter, these workfl ows are
described, together with potential challenges that may arise during each workfl ow.
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
fi rst 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 Unifi ed 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.
sch76183_ch03_074-106.indd 75 04/06/10 6:35 PM
76 Part A Software Engineering Concepts
3.1 The Unifi ed Process
As stated at the beginning of this chapter, methodology is one component of a software
process. The primary object-oriented methodology today is theUnifi ed 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 Unifi ed Methodology already had been used as the name
of the fi rst version of theUnified Modeling Language (UML). The three precursors of
the Unified 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
Unifi ed 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 Unifi ed 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 fi ts 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 Unifi ed 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.2Iteration and Incrementation within
the Object-Oriented Paradigm
The object-oriented paradigm uses modeling throughout. Amodel is 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 edModeling 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 workfl ow consists of a number of steps, and to carry out that workfl ow, the steps of the workfl ow
are repeatedly performed until the members of the development team are satisfi ed 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 fi nally
satisfi ed that the UML diagrams are correct. The implication is that software engineers, no
sch76183_ch03_074-106.indd 76 10/06/10 2:11 PM
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.
This changed in October 1994, when Rumbaugh joined Booch at Rational. The two
methodologists immediately began to work together to develop a methodology that would
combine OMT and Booch’s method. When a preliminary version of their work was published, it was pointed out that they had not developed a methodology but merely a notation
for representing an object-orie
0/5000
Chapter3The 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 Unifi ed Process. • List the artifacts tested in the test workfl ow. • Describe the four phases of the Unifi ed Process. • Explain the difference between the workfl ows and the phases of the Unifi edProcess. • 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 individualsbuilding the software. Different organizations have different software processes. For example, consider theissue 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 upspecifi cations and check them methodically. Then they perform design activities painstakingly, check and recheck their designs before coding commences, and give extensivedescriptions of each code artifact to the programmers. Test cases are preplanned, the resultof each test run is logged, and the test data are meticulously fi led away. Once the producthas 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 bemade only with written authorization, and the modifi cation is not integrated into the productuntil the documentation has been updated and the changes to the documentation approved.sch76183_ch03_074-106.indd 74 04/06/10 6:35 PMChapter 3 The Software Process 75 Intensity of testing is another measure by which organizations can be compared. Someorganizations devote up to half their software budgets to testing software, whereas othersfeel that only the user can thoroughly test a product. Consequently, some companies devoteminimal time and effort to testing the product but spend a considerable amount of timefi 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 changingneeds; 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 newerhardware every 3 to 5 years; this, too, constitutes postdelivery maintenance. In contrast, yet other organizations essentially are concerned with research, leavingdevelopment—let alone maintenance—to others. This applies particularly to universitycomputer 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 regardingthe wide variation in the ways different organizations develop software.) However, regardless of the exact procedure, the software development process isstructured around the fi ve workfl ows of Figure 2.4 : requirements, analysis (specifi cation), design, implementation, and testing. In this chapter, these workfl ows aredescribed, together with potential challenges that may arise during each workfl ow.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 thefi rst part of this chapter, only the challenges are highlighted, but the reader is guidedto the relevant sections or chapters for solutions. Accordingly, this part of the chapternot only is an overview of the software process, but a guide to much of the rest of thebook. The chapter concludes with national and international initiatives to improve thesoftware process. We now examine the Unifi ed Process. Just in Case You Wanted to Know Box 3.1Why does the software process vary so drastically from organization to organization? Amajor 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.
sch76183_ch03_074-106.indd 75 04/06/10 6:35 PM
76 Part A Software Engineering Concepts
3.1 The Unifi ed Process
As stated at the beginning of this chapter, methodology is one component of a software
process. The primary object-oriented methodology today is theUnifi ed 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 Unifi ed Methodology already had been used as the name
of the fi rst version of theUnified Modeling Language (UML). The three precursors of
the Unified 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
Unifi ed 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 Unifi ed 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 fi ts 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 Unifi ed 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.2Iteration and Incrementation within
the Object-Oriented Paradigm
The object-oriented paradigm uses modeling throughout. Amodel is 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 edModeling 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 workfl ow consists of a number of steps, and to carry out that workfl ow, the steps of the workfl ow
are repeatedly performed until the members of the development team are satisfi ed 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 fi nally
satisfi ed that the UML diagrams are correct. The implication is that software engineers, no
sch76183_ch03_074-106.indd 76 10/06/10 2:11 PM
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.
This changed in October 1994, when Rumbaugh joined Booch at Rational. The two
methodologists immediately began to work together to develop a methodology that would
combine OMT and Booch’s method. When a preliminary version of their work was published, it was pointed out that they had not developed a methodology but merely a notation
for representing an object-orie
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.
sch76183_ch03_074-106.indd 75 04/06/10 6:35 PM
76 Part A Software Engineering Concepts
3.1 The Unifi ed Process
As stated at the beginning of this chapter, methodology is one component of a software
process. The primary object-oriented methodology today is theUnifi ed 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 Unifi ed Methodology already had been used as the name
of the fi rst version of theUnified Modeling Language (UML). The three precursors of
the Unified 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
Unifi ed 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 Unifi ed 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 fi ts 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 Unifi ed 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.2Iteration and Incrementation within
the Object-Oriented Paradigm
The object-oriented paradigm uses modeling throughout. Amodel is 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 edModeling 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 workfl ow consists of a number of steps, and to carry out that workfl ow, the steps of the workfl ow
are repeatedly performed until the members of the development team are satisfi ed 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 fi nally
satisfi ed that the UML diagrams are correct. The implication is that software engineers, no
sch76183_ch03_074-106.indd 76 10/06/10 2:11 PM
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.
This changed in October 1994, when Rumbaugh joined Booch at Rational. The two
methodologists immediately began to work together to develop a methodology that would
combine OMT and Booch’s method. When a preliminary version of their work was published, it was pointed out that they had not developed a methodology but merely a notation
for representing an object-orie
đang được dịch, vui lòng đợi..
Chapter3
Quá trình Phần mềm
học tập Mục tiêu
Sau khi nghiên cứu chương này, bạn sẽ có thể
• Giải thích lý do tại sao hai chiều mô hình vòng đời rất quan trọng.
• Mô tả các fi ve OWS workfl cốt lõi của quá trình ed Unifi.
• Danh sách các hiện vật được thử nghiệm trong các kiểm tra workfl ow.
• Mô tả bốn giai đoạn của quá trình ed Unifi.
• Giải thích sự khác biệt giữa các OWS workfl và các giai đoạn của ed Unifi
Process.
• Đánh giá cao tầm quan trọng của quá trình cải tiến phần mềm.
• Mô tả các mô hình trưởng thành năng lực (CMM) .
74
Các quá 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
(Mục 1.11) với phần mềm cơ bản mô hình của nó trong chu kỳ (Chương 2) và kỹ thuật,
các công cụ chúng tôi sử dụng (mục 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ó khác nhau quy trình phần mềm. 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, là tài liệu hướng dẫn chuyên sâu. Họ punctiliously lập
cation specifi 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 bắt đầu mã hóa, và cung cấp cho rộng
các mô tả của mỗi mã vật để các lập trình viên. Trường hợp thử nghiệm được preplanned, kết quả
của mỗi lần chạy thử nghiệm được đăng nhập, và các dữ liệu thử nghiệm là fi tỉ mỉ dẫn đi. Một 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, bất kỳ đề nghị thay đổi phải được đề nghị bằng văn bản, với lý do chi tiết cho việc thực hiện các thay đổi. Các thay đổi được đề xuất có thể được
thực hiện chỉ với sự cho phép bằng văn bản, và các cation modifi 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 các tài liệu đã được phê duyệt.
sch76183_ch03_074-106.indd 74 04/06/10 18:35
Chương 3 Phần mềm Process 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 đến 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ể thử nghiệm một 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 các sản phẩm nhưng chi tiêu một số tiền đá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 được tăng cường để đáp ứng sự thay đổi
nhu cầu; 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. Hầu như tất cả các tổ chức di chuyển các phần mềm của họ để mới hơn
phần cứng mỗi 3-5 năm; này, quá, tạo thành bảo trì postdelivery.
Ngược lại, chưa tổ chức khác về cơ bản có liên quan với nghiên cứu, để
phát triển, hãy để một mình bảo trì cho người khác. Điều này đặc biệt áp dụng cho các trường đại học
ngành khoa học máy tính, nơi sinh viên đại học 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. Việc khai thác thương mại của khái niệm xác nhận 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 về Box 3.1
. 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, bất kể các thủ tục chính xác, quá trình phát triển phần mềm được
xây dựng xung quanh các fi ve OWS workfl của Hình 2.4: yêu cầu, phân tích (cation specifi), thiết kế, thực hiện và kiểm tra. Trong chương này, các OWS workfl đượ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 workfl ow.
Solutions với 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 được dành để mô tả kỹ thuật phù hợp. Trong
phần đầu tiên của chương fi này, chỉ có những thách thức đang nổi bật, nhưng người đọc được hướng dẫn
đến các bộ phận liên quan hoặ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 này kết thúc với những sáng kiến quốc gia và quốc tế để cải thiện các
quy trình phần mềm.
Bây giờ chúng ta xem xét quá trình ed Unifi.
Chỉ trong trường hợp bạn muốn biết Box 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? Một
nguyên nhân chính là thiếu các kỹ năng kỹ thuật phần mềm. Tất cả các chuyên phần mềm quá nhiều
chỉ đơn giản là không kịp cập nhật. Họ tiếp tục phát triển phần mềm Ye Olde Fashioned
Way, bởi vì họ biết không có cách nào khác.
Một lý do khác 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à các nhà quản lý xuất sắc nhưng biết quý chút về phát triển phần mềm, bảo trì. Họ thiếu kiến thức về kỹ thuật có thể dẫn đến các dự án trượt rất tệ đằng sau
lịch trình mà không có điểm trong việc 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.
Tuy nhiên, 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ý. 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, thậm chí nếu
nó không được kiểm tra đầy đủ. Trong bối cảnh như 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 với thời gian để kiểm tra các sản phẩm kỹ lưỡng và do đó cung cấp
nó muộn.
sch76183_ch03_074-106.indd 75 04/06/10 18:35
76 Part A Engineering Software Các khái niệm
3.1 Quá trình ed Unifi
Như đã nêu ở phần đầu của chương này, phương pháp luận 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 hôm nay là Process ed theUnifi. Như
đã giải thích trong Chỉ trong trường hợp bạn muốn biết Box 3.2, Unifi ed "Process" thực sự là
một phương pháp, nhưng tên Unifi ed Phương pháp đã được sử dụng như là tên
của phiên bản đầu tiên của fi theUnified Modeling Language (UML). Ba tiền thân của
các Unified Process (OMT, phương pháp Booch, và Objectory) không còn được hỗ trợ, và
các phương pháp hướng đối tượng khác đã có rất ít hoặc không có sau. Kết quả là, các
Process ed Unifi thường là sự lựa chọn chính ngay 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, các Process ed Unifi là một
phương pháp hướng đối tượng xuất sắc trong hầu hết mọi thứ.
Quá trình ed Unifi 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. Trong thực tế, không có như vậy đơn "một kích thước ts fi tất cả" phương pháp
có thể tồn tại vì sự đa dạng của các 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.
Ngoài ra, một phương pháp đổ xô một gói COTS ra thị trường trước đối thủ cạnh tranh của nó là
khác nhau từ một trong những sử dụng để xây dựng một bảo mật cao quỹ điện tử chuyển mạng. 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. Như sẽ thấy trong Phần B,
một số tính năng của Process ed Unifi là không áp dụng cho nhỏ và thậm chí quy mô vừa
mềm. Tuy nhiên, phần lớn các Process ed Unifi đượ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ỡ.
Sự 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 ed Unifi, nhưng các khía cạnh
của quá trình ed Unifi 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 những vấn đề cần được giải quyết khi các sản phẩm phần mềm lớn hơn được xây dựng được
đánh giá cao kỹ lưỡng.
3.2Iteration và incrementation trong
các Object-Oriented Paradigm
Mô hình hướng đối tượng sử dụng mô hình trong suốt. Amodel là 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 edModeling Language. Đó là, UML là công cụ mà chúng tôi sử dụng để đại diện (mô hình) các sản phẩm phần mềm tiêu.
Một lý do chính để sử dụng một đại diện đồ họa như UML tốt nhất là thể hiện bằng 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
giới thiệu đã đượ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. Mỗi ow workfl bao gồm một số bước, và để thực hiện điều đó workfl ow, các bước của ow workfl
đượ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 là ed satisfi 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. Đó là,
ngay cả những chuyên gia phần mềm có kinh nghiệm nhất lặp và lặp lại cho đến khi họ fi nally
satisfi ed rằng các sơ đồ UML là chính xác. Hàm ý là kỹ sư phần mềm, không
sch76183_ch03_074-106.indd 76 10/06/10 14:11
Chỉ trong trường hợp bạn muốn biết Box 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à
đối tượng mô hình 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 Jim Rumbaugh và nhóm của ông tại Trung tâm Nghiên cứu và Phát triển General Electric ở Schenectady, New York, trong khi Grady Booch
phát triển phương pháp của mình tại Rational, Inc., tại 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 nhau giữa
phương pháp OMT và Booch em rất nhỏ. Tuy nhiên, 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.
Điều này đã thay đổi trong tháng 10 năm 1994, khi gia nhập Rumbaugh Booch tại Rational. Hai
methodologists ngay lập tức bắt đầu làm việc cùng nhau để phát triển một phương pháp mà sẽ
kết hợp phương pháp OMT và Booch của. Khi một phiên bản sơ bộ của công việc của họ được công bố, nó đã chỉ ra rằng họ đã không phát triển một phương pháp mà chỉ là một ký hiệu
để biểu diễn một đối tượng orie
Quá trình Phần mềm
học tập Mục tiêu
Sau khi nghiên cứu chương này, bạn sẽ có thể
• Giải thích lý do tại sao hai chiều mô hình vòng đời rất quan trọng.
• Mô tả các fi ve OWS workfl cốt lõi của quá trình ed Unifi.
• Danh sách các hiện vật được thử nghiệm trong các kiểm tra workfl ow.
• Mô tả bốn giai đoạn của quá trình ed Unifi.
• Giải thích sự khác biệt giữa các OWS workfl và các giai đoạn của ed Unifi
Process.
• Đánh giá cao tầm quan trọng của quá trình cải tiến phần mềm.
• Mô tả các mô hình trưởng thành năng lực (CMM) .
74
Các quá 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
(Mục 1.11) với phần mềm cơ bản mô hình của nó trong chu kỳ (Chương 2) và kỹ thuật,
các công cụ chúng tôi sử dụng (mục 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ó khác nhau quy trình phần mềm. 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, là tài liệu hướng dẫn chuyên sâu. Họ punctiliously lập
cation specifi 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 bắt đầu mã hóa, và cung cấp cho rộng
các mô tả của mỗi mã vật để các lập trình viên. Trường hợp thử nghiệm được preplanned, kết quả
của mỗi lần chạy thử nghiệm được đăng nhập, và các dữ liệu thử nghiệm là fi tỉ mỉ dẫn đi. Một 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, bất kỳ đề nghị thay đổi phải được đề nghị bằng văn bản, với lý do chi tiết cho việc thực hiện các thay đổi. Các thay đổi được đề xuất có thể được
thực hiện chỉ với sự cho phép bằng văn bản, và các cation modifi 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 các tài liệu đã được phê duyệt.
sch76183_ch03_074-106.indd 74 04/06/10 18:35
Chương 3 Phần mềm Process 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 đến 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ể thử nghiệm một 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 các sản phẩm nhưng chi tiêu một số tiền đá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 được tăng cường để đáp ứng sự thay đổi
nhu cầu; 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. Hầu như tất cả các tổ chức di chuyển các phần mềm của họ để mới hơn
phần cứng mỗi 3-5 năm; này, quá, tạo thành bảo trì postdelivery.
Ngược lại, chưa tổ chức khác về cơ bản có liên quan với nghiên cứu, để
phát triển, hãy để một mình bảo trì cho người khác. Điều này đặc biệt áp dụng cho các trường đại học
ngành khoa học máy tính, nơi sinh viên đại học 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. Việc khai thác thương mại của khái niệm xác nhận 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 về Box 3.1
. 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, bất kể các thủ tục chính xác, quá trình phát triển phần mềm được
xây dựng xung quanh các fi ve OWS workfl của Hình 2.4: yêu cầu, phân tích (cation specifi), thiết kế, thực hiện và kiểm tra. Trong chương này, các OWS workfl đượ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 workfl ow.
Solutions với 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 được dành để mô tả kỹ thuật phù hợp. Trong
phần đầu tiên của chương fi này, chỉ có những thách thức đang nổi bật, nhưng người đọc được hướng dẫn
đến các bộ phận liên quan hoặ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 này kết thúc với những sáng kiến quốc gia và quốc tế để cải thiện các
quy trình phần mềm.
Bây giờ chúng ta xem xét quá trình ed Unifi.
Chỉ trong trường hợp bạn muốn biết Box 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? Một
nguyên nhân chính là thiếu các kỹ năng kỹ thuật phần mềm. Tất cả các chuyên phần mềm quá nhiều
chỉ đơn giản là không kịp cập nhật. Họ tiếp tục phát triển phần mềm Ye Olde Fashioned
Way, bởi vì họ biết không có cách nào khác.
Một lý do khác 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à các nhà quản lý xuất sắc nhưng biết quý chút về phát triển phần mềm, bảo trì. Họ thiếu kiến thức về kỹ thuật có thể dẫn đến các dự án trượt rất tệ đằng sau
lịch trình mà không có điểm trong việc 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.
Tuy nhiên, 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ý. 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, thậm chí nếu
nó không được kiểm tra đầy đủ. Trong bối cảnh như 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 với thời gian để kiểm tra các sản phẩm kỹ lưỡng và do đó cung cấp
nó muộn.
sch76183_ch03_074-106.indd 75 04/06/10 18:35
76 Part A Engineering Software Các khái niệm
3.1 Quá trình ed Unifi
Như đã nêu ở phần đầu của chương này, phương pháp luận 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 hôm nay là Process ed theUnifi. Như
đã giải thích trong Chỉ trong trường hợp bạn muốn biết Box 3.2, Unifi ed "Process" thực sự là
một phương pháp, nhưng tên Unifi ed Phương pháp đã được sử dụng như là tên
của phiên bản đầu tiên của fi theUnified Modeling Language (UML). Ba tiền thân của
các Unified Process (OMT, phương pháp Booch, và Objectory) không còn được hỗ trợ, và
các phương pháp hướng đối tượng khác đã có rất ít hoặc không có sau. Kết quả là, các
Process ed Unifi thường là sự lựa chọn chính ngay 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, các Process ed Unifi là một
phương pháp hướng đối tượng xuất sắc trong hầu hết mọi thứ.
Quá trình ed Unifi 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. Trong thực tế, không có như vậy đơn "một kích thước ts fi tất cả" phương pháp
có thể tồn tại vì sự đa dạng của các 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.
Ngoài ra, một phương pháp đổ xô một gói COTS ra thị trường trước đối thủ cạnh tranh của nó là
khác nhau từ một trong những sử dụng để xây dựng một bảo mật cao quỹ điện tử chuyển mạng. 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. Như sẽ thấy trong Phần B,
một số tính năng của Process ed Unifi là không áp dụng cho nhỏ và thậm chí quy mô vừa
mềm. Tuy nhiên, phần lớn các Process ed Unifi đượ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ỡ.
Sự 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 ed Unifi, nhưng các khía cạnh
của quá trình ed Unifi 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 những vấn đề cần được giải quyết khi các sản phẩm phần mềm lớn hơn được xây dựng được
đánh giá cao kỹ lưỡng.
3.2Iteration và incrementation trong
các Object-Oriented Paradigm
Mô hình hướng đối tượng sử dụng mô hình trong suốt. Amodel là 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 edModeling Language. Đó là, UML là công cụ mà chúng tôi sử dụng để đại diện (mô hình) các sản phẩm phần mềm tiêu.
Một lý do chính để sử dụng một đại diện đồ họa như UML tốt nhất là thể hiện bằng 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
giới thiệu đã đượ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. Mỗi ow workfl bao gồm một số bước, và để thực hiện điều đó workfl ow, các bước của ow workfl
đượ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 là ed satisfi 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. Đó là,
ngay cả những chuyên gia phần mềm có kinh nghiệm nhất lặp và lặp lại cho đến khi họ fi nally
satisfi ed rằng các sơ đồ UML là chính xác. Hàm ý là kỹ sư phần mềm, không
sch76183_ch03_074-106.indd 76 10/06/10 14:11
Chỉ trong trường hợp bạn muốn biết Box 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à
đối tượng mô hình 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 Jim Rumbaugh và nhóm của ông tại Trung tâm Nghiên cứu và Phát triển General Electric ở Schenectady, New York, trong khi Grady Booch
phát triển phương pháp của mình tại Rational, Inc., tại 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 nhau giữa
phương pháp OMT và Booch em rất nhỏ. Tuy nhiên, 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.
Điều này đã thay đổi trong tháng 10 năm 1994, khi gia nhập Rumbaugh Booch tại Rational. Hai
methodologists ngay lập tức bắt đầu làm việc cùng nhau để phát triển một phương pháp mà sẽ
kết hợp phương pháp OMT và Booch của. Khi một phiên bản sơ bộ của công việc của họ được công bố, nó đã chỉ ra rằng họ đã không phát triển một phương pháp mà chỉ là một ký hiệu
để biểu diễn một đối tượng orie
đang được dịch, vui lòng đợi..
Các ngôn ngữ khác
Hỗ trợ công cụ dịch thuật: Albania, Amharic, Anh, Armenia, Azerbaijan, Ba Lan, Ba Tư, Bantu, Basque, Belarus, Bengal, Bosnia, Bulgaria, Bồ Đào Nha, Catalan, Cebuano, Chichewa, Corsi, Creole (Haiti), Croatia, Do Thái, Estonia, Filipino, Frisia, Gael Scotland, Galicia, George, Gujarat, Hausa, Hawaii, Hindi, Hmong, Hungary, Hy Lạp, Hà Lan, Hà Lan (Nam Phi), Hàn, Iceland, Igbo, Ireland, Java, Kannada, Kazakh, Khmer, Kinyarwanda, Klingon, Kurd, Kyrgyz, Latinh, Latvia, Litva, Luxembourg, Lào, Macedonia, Malagasy, Malayalam, Malta, Maori, Marathi, Myanmar, Mã Lai, Mông Cổ, Na Uy, Nepal, Nga, Nhật, Odia (Oriya), Pashto, Pháp, Phát hiện ngôn ngữ, Phần Lan, Punjab, Quốc tế ngữ, Rumani, Samoa, Serbia, Sesotho, Shona, Sindhi, Sinhala, Slovak, Slovenia, Somali, Sunda, Swahili, Séc, Tajik, Tamil, Tatar, Telugu, Thái, Thổ Nhĩ Kỳ, Thụy Điển, Tiếng Indonesia, Tiếng Ý, Trung, Trung (Phồn thể), Turkmen, Tây Ban Nha, Ukraina, Urdu, Uyghur, Uzbek, Việt, Xứ Wales, Yiddish, Yoruba, Zulu, Đan Mạch, Đức, Ả Rập, dịch ngôn ngữ.
- I Giới thiệuBắt đầu từ ước muốn mang đến
- power demand is increasing very rapidly
- I Giới thiệuBắt đầu từ ước muốn mang đến
- are robust when firms are restricted to
- gambler placed the money on the palm of
- The viewing technology that allows docto
- I Giới thiệuBắt đầu từ ước muốn mang đến
- such reserves are limited
- Markets are generally efficient if compa
- 시작해야
- 주말을
- edge
- 5 thí sinh xuất sắc
- Technology has begun to solve some pollu
- thôi, không sao đâu
- uy tính an toàn
- cFor the Tobit regressions based on the
- she placed the money on the palm of her
- Mon bonheur ce est qu'il
- patina
- 하는데
- uy tính và an toàn
- xuất sắc
- uy tính và an toàn
