软件项目视图与范围模板.docx
- 文档编号:26623195
- 上传时间:2023-06-20
- 格式:DOCX
- 页数:6
- 大小:72.73KB
软件项目视图与范围模板.docx
《软件项目视图与范围模板.docx》由会员分享,可在线阅读,更多相关《软件项目视图与范围模板.docx(6页珍藏版)》请在冰豆网上搜索。
软件项目视图与范围模板
项目视图与范围
a.业务需求
业务需求说明了提供给客户和产品开发商的新系统的最初利益。
不同的产品,例如信息管理系统,商业软件包,系统捆绑软件将有不同的侧重点。
然而,项目开发的投入是由于人们坚信:
有了新产品,世界将变得更加美好。
本部分描述了你为什么要从事此项项目的开发,以及它将给开发者和购买者带来的利益。
a.1背景
在这一部分,总结新产品的理论基础,并提供关于产品开发的历史背景或形势的一般性描述。
a.2业务机遇
描述现存的市场机遇或正在解决的业务问题。
描述商品竞争的市场和信息系统将运用的环境。
包括对现存产品的一个简要的相对评价和解决方案,并指出所建议的产品为什么具有吸引力和它们所能带来的竞争优势。
认识到目前只能使用该产品才能解决的一些问题,并描述产品是怎样顺应市场趋势和战略目标的。
a.3业务目标
用一个定量和可测量的合理方法总结产品所带来的重要商业利润。
关于给客户带来的价值在本模板a.5的项目视图和范围文档中阐述,这里仅把重点放在给业务的价值上。
这些目标与收入预算或节省开支有关,并影响到投资分析和最终产品的交付日期。
如果这些信息在其它地方已叙述,就请参考有关文档,在此就不再重复了。
a.4客户或市场需求
描述一些典型客户的需求,包括不满足现有市场上的产品或信息系统的需求。
提出客户目前所遇到的问题在新产品中将可能(或不可能)出现的阐述,提供客户怎样使用产品的例子。
确定了产品所能运行的软、硬件平台。
定义了较高层次的关键接口或性能要求,但避免设计或实现细节。
把这些要求写在列表中,可以反过来跟踪调查特殊用户和功能需求。
a.5提供给客户的价值
确定产品给客户带来的价值,并指明产品怎样满足客户的需要。
可以用下列言辞表达产品带给客户的价值:
•提高生产效率,减少返工。
•节省开支。
•业务过程的流水线化。
•先前人工劳动的自动化。
•符合相关标准和规则。
•与目前的应用产品相比较,提高了可用性或减少了失效程度。
a.6业务风险
总结开发(或不开发)该产品有关的主要业务风险,例如市场竞争、时间问题、用户的接受能力、实现的问题或对业务可能带来的消极影响。
预测风险的严重性,指明你所能采取的减轻风险的措施。
b.项目视图的解决方案
文档中的这一部分为系统建立了一个长远的项目视图,它将指明业务目标。
这一项目视图为在软件开发生存期中作出决策提供了相关环境背景。
这部分不应包括详细的功能需求和项目计划信息。
b.1项目视图陈述
编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述。
项目视图陈述将考虑权衡有不同需求客户的看法。
它可能有点理想化,但必须以现有的或所期待的客户市场、企业框架、组织的战略方向和资源局限性为基础。
(这里是曾在前面章节讨论过的“化学制品跟踪系统”的简单项目视图陈述的一个实例。
“化学制品跟踪系统”可使科学家查询到化学制品仓库或供应商将提供的化学制品容器。
系统可随时了解公司中每一个化学制品容器所处的位置,容器中所剩余的药品剂量,任何时候每个容器所处的位置和用法的历史记录。
通过充分利用公司内部的可用化学制品,废弃极少量已使用或过期失效的化学制品,使用标准的化学制品的购买过程等将在化学制品上节省
25%开支。
“化学制品跟踪系统”还能产生符合政府部门规定所要求的全部报表,包括化学制品的使用、存储和废弃等报表。
)
b.2主要特性
包括新产品将提供的主要特性和用户性能的列表。
强调的是区别于以往产品和竞争产品的特性。
可以从用户需求和功能需求中得到这些特性。
b.3假设和依赖环境
在构思项目和编写项目视图和范围文档时,要记录所作出的任何假设。
通常一方所持的假设应与另一方不同。
如果你把它们都记录下来,并加以评论,就能对项目内部隐含的基本假设达成共识。
(比如,“化学制品跟踪系统”的开发者假设:
该系统可以替代现有的仓库存货系统,并能与有关采购部门的应用相连接。
把这些都记录下来以防止将来可能的混淆和冲突。
还有,记录项目所依赖的主要环境,比如:
所使用的特殊的技术、第三方供应商、开发伙伴或其它业务关系。
)
c.范围和局限性
当一个化学家发明了可以把一种化学制品转变为另一种化学制品的新的化学变化时,它所发表的论文中包含了“范围和局限性”部分,这一部分描述了这一化学变化所能作和不能作的一种限定。
类似地,一个软件项目也必须定义它的范围和局限性,并作为业务需求的一部分。
项目范围定义了所提出的解决方案的概念和适用领域,而局限性则指出产品所不包括的某些性能。
澄清范围和局限性这两个概念有助于建立各风险承担者所企盼的目标。
有时客户所要求的性能太奢华或者与产品所制定的范围不一致。
一般客户所提出的需求超出项目的范围时就应当拒绝它,除非这些需求是很有益的。
这时,可适当扩大项目范围来适应这些需求
(在预算、计划、人员方面也要相应进行变化)。
记录这些需求以及拒绝它们的原因,以备日后重新遇到时,有记录可查。
c.1首次发行的范围
总结首次发行的产品所具有的性能。
描述了产品的质量特性,这些特性使产品可以为不同的客户群(customercommunity)提供预期的成果。
如果你的目标集中在开发成果和维持一个可行的项目规划上,应当避免一种倾向,那就是把一些潜在的客户所能想到的每一特性都包括到1.0版本的产品中。
这一倾向所带来的普遍恶果是产生软件规划的动荡性和错误性。
开发者应把重点放在能提供最大价值、花费最合理的开发费用及普及率最高的产品上。
例如,我的同事Scott的上一个项目开发小组决定,用户可以用首发版的软件进行包裹传递业务。
1.0版本并不要求快速、结构紧凑或易于使用,但该软件必须稳定运行;整个开发小
组始终以这一目标为准。
首发版的软件完成了基本的系统目标,而随后的版本则包含了附加的特性、选项和使用帮助。
c.2随后发行的范围
如果你想象一个周期性的产品演变过程,就要指明哪一个主要特性的开发将被延期,并期待随后版本发行的日期。
c.3局限性和专用性
明确定义包括和不包括的特性和功能的界线是处理范围设定和客户期望的一个途径。
列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能。
d.业务环境
这一部分总结了一些项目的业务问题,包括主要的客户分类概述和项目的管理优先级。
d.1客户概貌
客户概述明确了这一产品的不同类型客户的一些本质的特点,以及目标市场部门和在这些部门中的不同客户的特征。
对于每一种客户类型,概述要包括以下信息:
•各种客户类型将从产品中获得的主要益处。
•它们对产品所持的态度。
•感兴趣的关键产品的特性。
•哪一类型客户能成功使用。
•必须适应任何客户的限制。
d.2项目的优先级
一旦明确建立项目的优先级,风险承担者和项目的参与者就能把精力集中在一系列共同的目标上。
达到这一目的的一个途径是考虑软件项目的五个方面:
性能、质量、计划、成本和人员(Wiegers1996a)。
在所给的项目中,其每一方面应与下面三个因素之一相适应。
•一个驱动(driver)—一个最高级别的目标。
•一个约束(constraint)—项目管理者必须操纵一个对象的限制因素。
•一个自由度(degreeoffreedom)—项目管理者能权衡其它方面,进而在约束限制的范围内完成目标的一个因素。
未必所有的因素都能成为驱动,或所有的因素都能成为约束因素。
在项目开始时记录和分析哪一个因素适用于哪一类型,将有助于使每一个人的努力和期望与普遍认可的优先级相一致。
e.产品成功的因素
明确产品的成功是如何定义和测量的,并指明对产品的成功有巨大影响的几个因素。
不仅要包括组织直接控制的范围内的事务,还要包括外部因素。
如果可能,可建立测量的标准,用于评价是否达到业务目标,这些标准的实例有:
市场股票、销售量或收入、客户满意程度的测量、交易处理量和准确度。
F.关联图
本文档部分内容来源于网络,如有内容侵权请告知删除,感谢您的配合!
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 项目 视图 范围 模板