以下大部分知识来自于《UML和模式应用》第三版。
初始阶段定义
初始阶段考虑的问题:
1,项目设想和业务案例是什么?
2,是否可行?
3,购买还是开发?
4,粗略估计一下开发成本:10W人民币还是百万人民币,还是上千万。
5,项目应该继续下去还是停止。
初始阶段的目标不是什么:
1,不是定义所有需求,或者产生可信赖的预算或项目计划。
2,大部分需求分析在细化阶段进行,并伴以产品品质的早期编程和测试。
初始阶段定义:
预见项目的范围、设想和业务案例。
解决主要的问题:
渉众是否就项目设想基本达成一致,项目是否值得继续进行认真研究。
举例说明:调查一个科研市场和教学行业市场信息。
1,收集这个行业的相关信息(软件,政策、规定、解决方案,获取真实需求)
2,分析这个行业内容
3,相关结论结论。
注意内容如下:
需要从三个方面收集资料:现有的相关领域的软件;现有的相关领域的政策、规定、解决方案;现有的相关领域真实需求。
需要从四个方面分析资料:从公司角度(我们具不具备这种能力);从市场角度(有谁在做?);从客户角度(我们是否会掏钱买);从用户角度(我们是否觉得这个系统有价值)。
需要从两个方面给出结论报告:从经济角度(这里面有钱)和从技术角度(技术可达,我们具备这种技术能力:理论,解决方案,人员,环境)。
可以使用的工具SWOT相关工具,根据企业情况进行分析。
初始阶段持续时间
初始阶段可能仅仅是第一次需求研讨会,并为第一次迭代制定计划的一部分。
有案例的情况下,初始状态更短。
初始阶段创建的制品
在初始阶段完成部分制品,在后续迭代中对其进行精化。
制品 | 注释 |
设想和业务用例 | 描述高层的目标和约束,业务案例,并提供执行摘要 |
用例模型 | 描述功能需求。在初始阶段,确定大部分用例的名称,详细分析10%的用例 |
补充性规格说明 | 描述其他需求,主要是非功能性需求 |
词汇表/术语表 | 关键领域术语和数据字典 |
风险列表和风险管理计划 |
|
概念验证(验证技术思路) |
|
第一个迭代计划 |
|
阶段计划和软件开发计划(粗略的估计) |
|
开发案例 | 特定项目,对UP步骤和制品进行定制 |
初始阶段关注基本范围的理解以及10%的需求。
何时知道自己并不了解初始阶段
- 当认为大部分项目的初始阶段会持续几周或者更长时。
- 在初始阶段试图定义大部分的需求时。
- 期望初始阶段的预算和计划是可靠的。
- 定义架构(应该在细化阶段以迭代方式来定义架构)
- 认为正确的工作顺序应该是:1)定义需求; 2)设计架构; 3)实现。
- 没有业务案例或设想制品。
- 详细描写所有用例。
- 没有详细编写任何用例。与之相反。应该详细编写10%~20%的用例以便获得对问题范围的真实认识。