统一过程精解（英文影印版）
点击看大图基本信息
- 作者： （美）Kendall Scott
- 丛书名： 软件工程实践丛书
- 出版社：清华大学出版社
- ISBN：7302082677
- 上架时间：2004-5-11
- 出版日期：2004 年4月
- 开本：32开
- 页码：185
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 综合
编辑推荐
读者通过本书的阅读，可理解以下重要概念和活动：迭代和增量、业务和域建模、标识参与者和用例、原型化用户接口、健壮性分析、设计和配置模型、状态图和活动图、实现模型。
内容简介回到顶部↑
通过本书的阅读，可理解以下重要概念和活动：
◆迭代和增量
◆业务和域建模
◆标识参与者和用例
◆原型化用户接口
◆健壮性分析
◆设计和配置模型
◆状态图和活动图
◆实现模型
◆迭代和增量
◆业务和域建模
◆标识参与者和用例
◆原型化用户接口
◆健壮性分析
◆设计和配置模型
◆状态图和活动图
◆实现模型
目录回到顶部↑
list of figures
preface
why this book?
organization of this book
acknowledgments
chapter 1: overview
introduction
history
use case driven
architecture-centric
understanding the big picture
organizing the development effort
facilitating the possibilities for reuse
evolving the system
guiding the use cases
iterative and incremental
logical progress toward a robust architecture
dealing with ongoing changes in requirements
greater flexibility to change the plan
continuous integration
preface
why this book?
organization of this book
acknowledgments
chapter 1: overview
introduction
history
use case driven
architecture-centric
understanding the big picture
organizing the development effort
facilitating the possibilities for reuse
evolving the system
guiding the use cases
iterative and incremental
logical progress toward a robust architecture
dealing with ongoing changes in requirements
greater flexibility to change the plan
continuous integration
前言回到顶部↑
Why This Book?
From the moment the Unified Process made its appearance, I heard many people describing it as really big and complicated, at conferences like UML World and in various public forums, such as Rational's Object Technology User Group (OTUG) mailing list. I agreed that in comparison to other wellknown processes, it was rather large, but I didn't think that it was all that complicated, all things considered.
In Chapter 2 of UML Explained, I managed to describe the fundamental conc. epts that underlie the Unified Process in about ten pages. While I was still writing that book, it occurred to me that I could probably describe the most important details of the Unified Process in a book not much bigger than that one (that is, 200 pages rather than my usual 150 or so). So, I set about writing this book partially to debunk the notion that the process contained just too much for the average person to get his or her arms around, and also to establish that the process doesn't specify tasks that people on a project don't do anyway, in one way or another.
The result is a book that I've specifically conceived as a companion piece to UML Explained. Rather than try to teach you about the UML, which the Unified Process makes fairly heavy use of, I've included references to chapters and sections in that book that offer details about the various UML diagrams and techniques that come into play within the process. I've also brought a number of the diagrams over from that book into this one, to help the continuity and flow across both books. As Picasso said, "Good artists borrow; great artists steal."
Here are some other key features of this book:
~ I've made domain modeling and business modeling, which tend to get short shrift in other books about this process, full players, with the associated artifacts and activities part of the Requirements workflow where they belong.
~ I've minimized the amount of project management material.
Walker Royce's Software Project Management: A Unified Framework (Addison-Wesley, 1998) is the definitive work on how to do project management in conjunction with the Unified Process, and I see no need to try to add value to what he's written.
~ Chapters 7 through 9 include the story of how The Internet Bookstore, a sample project, was designed and built. Whereas Chapters 2 through 6 include diagrams from UML Explained relevant to that example, the later chapters explain how the project team broke the system down into chunks in the course of doing iterative and incremental development. Applying Use Case Driven Object Modeling with UML (Rosenberg and Scott, AddisonWesley, 2001) contains other views of the same bookstore project. (My attitude is, stick with what you know!)
My goal was to write a book that would demystify what people like to call A Real Big Process or some variation of that. I hope you think I've succeeded.
Organization of This Book
The body of this book can usefully be divided into four parts.
The first part comprises Chapter 1. This chapter provides an overview of the Unified Process, in the form of a "nutshell" description, some history, exploration of the major themes (use case driven, architecture-centric, and iterative and incremental), and definitions of the major terminology: workflows, phases, iterations and increments, and artifacts, workers, and activities.
The second part comprises Chapters 2 through 6. These chapters provide the details about the five workflows (Requirements, Analysis, Design, Implementation, and Test) that the process defines. Each chapter includes the following:
~ An introduction that offers a brief overview of what's included in the workflow and its primary goals
~ Descriptions of the various artifacts that get produced during the workflow
~ Descriptions of the various roles that people play during the workflow, expressed in terms of "workers"
~ Descriptions of the various activities that workers perform during the workfiow in order to produce the artifacts
Each of the Activities sections has a diagram that shows the nonlinear nature of the given workflow. Solid lines on this diagram show logical sequences in which to perform the activities; in some cases, one activity is basically a prerequisite to another activity, whereas in other cases, the work that the team performs for one activity will cause a cycling back to one or more activities that it previously performed. Dashed lines are for data flow: The contents of the artifact that results when one activity is finished feed into the next activity or a previous activity. The third part comprises Chapters 7 through 9. These chapters provide the details about three of the four phases (Inceptidn, Elaboration, and Construction) that the process defines. Each chapter includes the following:
~ An introduction that offers a brief overview of what the project team does during the phase, including its primary goals and a high-level look at how each of the five workflows "cuts across" the phase. (You might think of the workflows and the phases as forming a matrix, with the workflows running down the left-hand side and the phases across the top.)
From the moment the Unified Process made its appearance, I heard many people describing it as really big and complicated, at conferences like UML World and in various public forums, such as Rational's Object Technology User Group (OTUG) mailing list. I agreed that in comparison to other wellknown processes, it was rather large, but I didn't think that it was all that complicated, all things considered.
In Chapter 2 of UML Explained, I managed to describe the fundamental conc. epts that underlie the Unified Process in about ten pages. While I was still writing that book, it occurred to me that I could probably describe the most important details of the Unified Process in a book not much bigger than that one (that is, 200 pages rather than my usual 150 or so). So, I set about writing this book partially to debunk the notion that the process contained just too much for the average person to get his or her arms around, and also to establish that the process doesn't specify tasks that people on a project don't do anyway, in one way or another.
The result is a book that I've specifically conceived as a companion piece to UML Explained. Rather than try to teach you about the UML, which the Unified Process makes fairly heavy use of, I've included references to chapters and sections in that book that offer details about the various UML diagrams and techniques that come into play within the process. I've also brought a number of the diagrams over from that book into this one, to help the continuity and flow across both books. As Picasso said, "Good artists borrow; great artists steal."
Here are some other key features of this book:
~ I've made domain modeling and business modeling, which tend to get short shrift in other books about this process, full players, with the associated artifacts and activities part of the Requirements workflow where they belong.
~ I've minimized the amount of project management material.
Walker Royce's Software Project Management: A Unified Framework (Addison-Wesley, 1998) is the definitive work on how to do project management in conjunction with the Unified Process, and I see no need to try to add value to what he's written.
~ Chapters 7 through 9 include the story of how The Internet Bookstore, a sample project, was designed and built. Whereas Chapters 2 through 6 include diagrams from UML Explained relevant to that example, the later chapters explain how the project team broke the system down into chunks in the course of doing iterative and incremental development. Applying Use Case Driven Object Modeling with UML (Rosenberg and Scott, AddisonWesley, 2001) contains other views of the same bookstore project. (My attitude is, stick with what you know!)
My goal was to write a book that would demystify what people like to call A Real Big Process or some variation of that. I hope you think I've succeeded.
Organization of This Book
The body of this book can usefully be divided into four parts.
The first part comprises Chapter 1. This chapter provides an overview of the Unified Process, in the form of a "nutshell" description, some history, exploration of the major themes (use case driven, architecture-centric, and iterative and incremental), and definitions of the major terminology: workflows, phases, iterations and increments, and artifacts, workers, and activities.
The second part comprises Chapters 2 through 6. These chapters provide the details about the five workflows (Requirements, Analysis, Design, Implementation, and Test) that the process defines. Each chapter includes the following:
~ An introduction that offers a brief overview of what's included in the workflow and its primary goals
~ Descriptions of the various artifacts that get produced during the workflow
~ Descriptions of the various roles that people play during the workflow, expressed in terms of "workers"
~ Descriptions of the various activities that workers perform during the workfiow in order to produce the artifacts
Each of the Activities sections has a diagram that shows the nonlinear nature of the given workflow. Solid lines on this diagram show logical sequences in which to perform the activities; in some cases, one activity is basically a prerequisite to another activity, whereas in other cases, the work that the team performs for one activity will cause a cycling back to one or more activities that it previously performed. Dashed lines are for data flow: The contents of the artifact that results when one activity is finished feed into the next activity or a previous activity. The third part comprises Chapters 7 through 9. These chapters provide the details about three of the four phases (Inceptidn, Elaboration, and Construction) that the process defines. Each chapter includes the following:
~ An introduction that offers a brief overview of what the project team does during the phase, including its primary goals and a high-level look at how each of the five workflows "cuts across" the phase. (You might think of the workflows and the phases as forming a matrix, with the workflows running down the left-hand side and the phases across the top.)
加载中...
