UML和模式应用

按有用程度 按页码先后 最新笔记

• 

  3,4,5

  damen (我执)

  P37 在初始阶段我们应该做什么： 预见项目的范围、设想和业务案例（即该应用干什么，有哪些大致部分，大致怎么干） 注意，初始阶段不是需求分析 P38 初始阶段的输出有哪些？ 1， 设想和业务用例 2， 用例模型 3， 数据字典，即建立在项目组中的统一语境 4， 风险列表和风险管理计划（这里需要进一步看看） 5， 澄清设想和验证技术思路 6， 迭代计划、阶段计划、软件开发计划 7， 开发案例 可以看到，这是在项目开... (更多)

  P37

  在初始阶段我们应该做什么：

  预见项目的范围、设想和业务案例（即该应用干什么，有哪些大致部分，大致怎么干）

  注意，初始阶段不是需求分析

  P38

  初始阶段的输出有哪些？

  1， 设想和业务用例

  2， 用例模型

  3， 数据字典，即建立在项目组中的统一语境

  4， 风险列表和风险管理计划（这里需要进一步看看）

  5， 澄清设想和验证技术思路

  6， 迭代计划、阶段计划、软件开发计划

  7， 开发案例

  可以看到，这是在项目开始前进行的准备工作，这些准备工作需要你：

  1， 对业务有一个总体的认识，并划定粗略的业务边界

  2， 在项目组中建立统一的针对该项目的语境，确定术语

  3， 指定计划，包括迭代计划、风险管理计划等等 (收起)

  2011-11-17 00:17:02   回应

  收藏

  推荐
• 

  第二章

  damen (我执)

  P19 阐述了一个迭代步骤的示例，这里要注意： 1， 第一次迭代应选择A，具有重要架构意义。B，具有高业务价值。C，具有高风险的需求。并对其进行详尽的分析。计划的制定应该首先设计、构造和测试选出的满足该3个条件的需求。这样做的目的是建立产品的基线，并及时可以得到反馈。 2， 测试时必须冻结代码 3， 你应当使用UML建模来确定用例和完成设计。UML建模用于沟通和理解，而非文档。 P21 该图表示： 1， 每次迭代都需... (更多)

  P19

  阐述了一个迭代步骤的示例，这里要注意：

  1， 第一次迭代应选择A，具有重要架构意义。B，具有高业务价值。C，具有高风险的需求。并对其进行详尽的分析。计划的制定应该首先设计、构造和测试选出的满足该3个条件的需求。这样做的目的是建立产品的基线，并及时可以得到反馈。

  2， 测试时必须冻结代码

  3， 你应当使用UML建模来确定用例和完成设计。UML建模用于沟通和理解，而非文档。

  P21

  该图表示：

  1， 每次迭代都需要分析一定比例的代码，但是在这个迭代过程中，构造部分（即编码）的完成比例可以较低。这样做的好处是可以随时适应变更

  2， 迭代的时间必须固定

  P24

  注意变更管理和配置管理

  P26

  该图表示：

  1， 在初始的迭代过程中，业务建模、需求、项目管理应是关注的重点。

  2， 随后，设计成为主要关注点。

  3， 接下来就是实现。

  4， 测试应该从实现开始至所有的迭代结束。

  5， 配置和变更管理应该随着项目的进行逐步得到重视。

  UP将其分为4部分：初始----可行性研究和需求的初步了解等

  细化----确定需求

  设计----UML建模

  实现----编码

  P28

  开发案例可理解为：

  在每一个UP过程中，通过实践所产生的输出。这里的实践是指项目小组为完成该项目所采取的行动，如需求分析例会，建模等等。这里的输出是指在每一个UP过程的实践后，都有相应的确定的输出，如领域模型，架构文档等。

  这样做的好处是：每次迭代都有固定的成果，即目标。项目小组需要为在一次迭代中完成该目标而努力。成果可以用于反馈和进行下一轮的迭代。如果没有固定的成果，迭代的边界将变得不可确定。 (收起)

  2011-11-15 23:52:10   回应

  收藏

  推荐

• 

  3,4,5

  damen (我执)

  P37 在初始阶段我们应该做什么： 预见项目的范围、设想和业务案例（即该应用干什么，有哪些大致部分，大致怎么干） 注意，初始阶段不是需求分析 P38 初始阶段的输出有哪些？ 1， 设想和业务用例 2， 用例模型 3， 数据字典，即建立在项目组中的统一语境 4， 风险列表和风险管理计划（这里需要进一步看看） 5， 澄清设想和验证技术思路 6， 迭代计划、阶段计划、软件开发计划 7， 开发案例 可以看到，这是在项目开... (更多)

  P37

  在初始阶段我们应该做什么：

  预见项目的范围、设想和业务案例（即该应用干什么，有哪些大致部分，大致怎么干）

  注意，初始阶段不是需求分析

  P38

  初始阶段的输出有哪些？

  1， 设想和业务用例

  2， 用例模型

  3， 数据字典，即建立在项目组中的统一语境

  4， 风险列表和风险管理计划（这里需要进一步看看）

  5， 澄清设想和验证技术思路

  6， 迭代计划、阶段计划、软件开发计划

  7， 开发案例

  可以看到，这是在项目开始前进行的准备工作，这些准备工作需要你：

  1， 对业务有一个总体的认识，并划定粗略的业务边界

  2， 在项目组中建立统一的针对该项目的语境，确定术语

  3， 指定计划，包括迭代计划、风险管理计划等等 (收起)

  2011-11-17 00:17:02   回应

  收藏

  推荐
• 

  第二章

  damen (我执)

  P19 阐述了一个迭代步骤的示例，这里要注意： 1， 第一次迭代应选择A，具有重要架构意义。B，具有高业务价值。C，具有高风险的需求。并对其进行详尽的分析。计划的制定应该首先设计、构造和测试选出的满足该3个条件的需求。这样做的目的是建立产品的基线，并及时可以得到反馈。 2， 测试时必须冻结代码 3， 你应当使用UML建模来确定用例和完成设计。UML建模用于沟通和理解，而非文档。 P21 该图表示： 1， 每次迭代都需... (更多)

  P19

  阐述了一个迭代步骤的示例，这里要注意：

  1， 第一次迭代应选择A，具有重要架构意义。B，具有高业务价值。C，具有高风险的需求。并对其进行详尽的分析。计划的制定应该首先设计、构造和测试选出的满足该3个条件的需求。这样做的目的是建立产品的基线，并及时可以得到反馈。

  2， 测试时必须冻结代码

  3， 你应当使用UML建模来确定用例和完成设计。UML建模用于沟通和理解，而非文档。

  P21

  该图表示：

  1， 每次迭代都需要分析一定比例的代码，但是在这个迭代过程中，构造部分（即编码）的完成比例可以较低。这样做的好处是可以随时适应变更

  2， 迭代的时间必须固定

  P24

  注意变更管理和配置管理

  P26

  该图表示：

  1， 在初始的迭代过程中，业务建模、需求、项目管理应是关注的重点。

  2， 随后，设计成为主要关注点。

  3， 接下来就是实现。

  4， 测试应该从实现开始至所有的迭代结束。

  5， 配置和变更管理应该随着项目的进行逐步得到重视。

  UP将其分为4部分：初始----可行性研究和需求的初步了解等

  细化----确定需求

  设计----UML建模

  实现----编码

  P28

  开发案例可理解为：

  在每一个UP过程中，通过实践所产生的输出。这里的实践是指项目小组为完成该项目所采取的行动，如需求分析例会，建模等等。这里的输出是指在每一个UP过程的实践后，都有相应的确定的输出，如领域模型，架构文档等。

  这样做的好处是：每次迭代都有固定的成果，即目标。项目小组需要为在一次迭代中完成该目标而努力。成果可以用于反馈和进行下一轮的迭代。如果没有固定的成果，迭代的边界将变得不可确定。 (收起)

  2011-11-15 23:52:10   回应

  收藏

  推荐