RUP:初始阶段

以下大部分知识来自于《UML和模式应用》第三版。


初始阶段定义

 

初始阶段考虑的问题:

1,项目设想和业务案例是什么?

2,是否可行?

3,购买还是开发?

4,粗略估计一下开发成本:10W人民币还是百万人民币,还是上千万。

5,项目应该继续下去还是停止。

 

 

初始阶段的目标不是什么:

1,不是定义所有需求,或者产生可信赖的预算或项目计划。

2,大部分需求分析在细化阶段进行,并伴以产品品质的早期编程和测试。

 

 

初始阶段定义:

预见项目的范围、设想和业务案例。

 

解决主要的问题:

渉众是否就项目设想基本达成一致,项目是否值得继续进行认真研究。

 

 

举例说明:调查一个科研市场和教学行业市场信息。

1,收集这个行业的相关信息(软件,政策、规定、解决方案,获取真实需求)

2,分析这个行业内容

3,相关结论结论。

 

注意内容如下:

 

需要从三个方面收集资料:现有的相关领域的软件;现有的相关领域的政策、规定、解决方案;现有的相关领域真实需求。

需要从四个方面分析资料:从公司角度(我们具不具备这种能力);从市场角度(有谁在做?);从客户角度(我们是否会掏钱买);从用户角度(我们是否觉得这个系统有价值)。

需要从两个方面给出结论报告:从经济角度(这里面有钱)和从技术角度(技术可达,我们具备这种技术能力:理论,解决方案,人员,环境)。

 

 

可以使用的工具SWOT相关工具,根据企业情况进行分析。

 

初始阶段持续时间

 

初始阶段可能仅仅是第一次需求研讨会,并为第一次迭代制定计划的一部分。

有案例的情况下,初始状态更短。

 

 

初始阶段创建的制品

 

在初始阶段完成部分制品,在后续迭代中对其进行精化。

 

制品

注释

设想和业务用例

描述高层的目标和约束,业务案例,并提供执行摘要

用例模型

描述功能需求。在初始阶段,确定大部分用例的名称,详细分析10%的用例

补充性规格说明

描述其他需求,主要是非功能性需求

词汇表/术语表

关键领域术语和数据字典

风险列表和风险管理计划

 

概念验证(验证技术思路)

 

第一个迭代计划

 

阶段计划和软件开发计划(粗略的估计)

 

开发案例

特定项目,对UP步骤和制品进行定制

 

初始阶段关注基本范围的理解以及10%的需求。

 

何时知道自己并不了解初始阶段

 

  • 当认为大部分项目的初始阶段会持续几周或者更长时。
  • 在初始阶段试图定义大部分的需求时。
  • 期望初始阶段的预算和计划是可靠的。
  • 定义架构(应该在细化阶段以迭代方式来定义架构)
  • 认为正确的工作顺序应该是:1)定义需求; 2)设计架构; 3)实现。
  • 没有业务案例或设想制品。
  • 详细描写所有用例。
  • 没有详细编写任何用例。与之相反。应该详细编写10%20%的用例以便获得对问题范围的真实认识。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值