本阶段确定所设立的项目是否可行，具体要做如下工作：对需求有一个大概的了解，确定系统中的大多数角色和用况，但此时的用况是简要的。对给出的系统体系结构的概貌，细化到主要子系统即可。识别影响项目可行性的风险。考虑时间、经费、技术、项目规模和效益等因素。关注业务情况，制订出开发计划。识别出剩余的大多数用况。对当前迭代的每个用况进行细化，分析用况的处理流程、状态细节以及可能发生的状态改变。细化流程时，可以使用程序框图和合作图，还可以使用活动图、类图分析用况。考虑项目的目标是否偏离了用户的需求。为解决需求风险要充分了解用户需求以及各需求的优先度，还应尽量列出所有的用况，至少列出重要的用况，并要建立领域的概念模型。考察所选的技术方案是否可行。建立原型是解决技术风险的一种有效方法。考虑实施项目的人员素质能否胜任项目的要求。考虑政策性的因素对项目的影响。
　
　　● 进行高层分析和设计，并作出结构性决策。所产生的基线体系结构包括用况列表、领域概念模型和技术平台等。以后的阶段对细化阶段建立的体系结构不能进行过大的变动。
　
　　● 为构造阶段制订计划。细化阶段完成，意味着已经完成了如下的任务：用况完全细化并被用户接受；完成概念验证；完成类图；开发人员能给出项目估算（可分为精确、人月和无法估算）；基于用况考虑了所有风险（可分为高风险、可能的风险和不可能的风险），并制订了相应的对策和计划；对用况标出优先级（可分为必须先实现、短期内实现和长期实现）。识别出剩余的用况。每一次迭代开发都针对用况进行分析、设计、编码（如类声明、属性声明、范围声明、函数原型声明和继承的声明等）、测试和集成过程，所得到产品满足项目需求的一个子集。
　
　　由于细化阶段的软件设计已经完成，这样各项目组可以并发开发。在代码完成后，要保证其符合标准和设计规则，并要进行质量检查。对于新出现的变化，要通过逆向工具把代码转换为模型，对模型进行修改，再重新产生代码，以保证软件与模型同步。此阶段要建立类图、交互图和配置图；如一个类具有复杂的生命周期，可绘制状态图；如算法特别复杂，可绘制活动图。这一阶段完成最后的软件产品和最后的验收测试，并完成用户文档编制以及用户培训等工作。可以说，UML对系统模型的表达能力超出了以往任何一种面向对象的分析和设计方法。随之出现的问题是，它的复杂性也超出了以往任何一种方法。
　
　　由于UML的复杂性，对它的掌握和使用确实不是一件轻松的事。建议对UML掌握和使用本着由简至难的原则，即熟练掌握基本的概念与表示法后，再学习使用UML的更深入部分。UML的三位创始人所著述的《The Unified Modeling language》也是这样组织内容的。关于UML的作者所推荐的过程指导，请阅读他们著述的《The Unified Software Development Process》。此外北京大学也推出了一套青鸟面向对象软件开发规范，其中包括有一套很完整的过程指导。
　

上一页  [1] [2] [3] [4] 

【责编:Lili】