|
本阶段的主要目标如下:
- 明确软件系统的范围和边界条件,括从功能角度的前景分析、产品验收标准和哪些做与哪些不做的相关决定
- 明确区分系统的关键用例(Use-case) 和主要的功能场景
- 展现或者演示至少一种符合主要场景要求的候选软件体系结构
- 对整个项目做最初的项目成本和日程估计(更详细的估计将在随后的细化阶段中做出)
- 估计出潜在的风险(主要指各种不确定因素造成的潜在风险)
- 准备好项目的支持环境
初始阶段的产出是:
- 蓝图文档核心项目需求关键特色主要约束的总体蓝图
- 原始用例模型(完成10%~20%)
- 原始项目术语表(可能部分表达为业务模型)
- 原始商业案例,包括业务的上下文、验收规范(年度映射、市场认可等等),成本预计
- 原始的风险评估
- 一个或多个原型
里程碑:生命周期的目标

初始阶段结束时是第一个重要的里程碑:生命周期目标里程碑。初始阶段的评审标准:
- 风险承担者就范围定义成本日程估计达成共识
- 以客观的主要用例证实对需求的理解
- 成本/日程、优先级、风险和开发过程的可信度
- 被开发体系结构原型的深度和广度
- 实际开支与计划开支的比较
如果无法通过这些里程碑,则项目可能被取消或仔细地重新考虑。
细化阶段

细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。
为了达到该目的,必须对系统具有"英里宽和英寸深"的观察。体系结构的决策必须在理解整个系统的基础上作出:它的范围,主要功能和如性能等非功能性需求。
容易引起争论,细化阶段是四个阶段中最关键的阶段。该阶段结束时,硬"工程"可以认为已结束,项目则经历最后的审判日:决策是否项目提交给构建和交付阶段。对于大多数项目,这也相当于从移动的、轻松的、灵巧的、低风险的运作过渡到高成本、高风险并带有较大惯性的运作过程。而过程必须能容纳变化,细化阶段活动确保了结构、需求和计划是足够稳定的,风险被充分减轻,所以可以为开发结果预先决定成本和日程安排。概念上,其逼真程度一致于机构实行费用固定的构建阶段的必要程度。
在细化阶段,可执行的结构原形在一个或多个迭代过程中建立,依赖于项目的范围、规模、风险和先进程度。工作量必须至少处理初始阶段中识别的关键用例,关键用例典型揭示了项目主要技术的风险。通常我们的目标是一个由产品质量级别构件组成的可进化的原型,但这并不排除开发一个或多个探索性、可抛弃的原型来减少如:设计/需求折衷,构件可行性研究,或者给投资者、顾客即最终用户演示版本等特定的风险。
本阶段的主要目标如下:
- 确保软件结构、需求、计划足够稳定;确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度。
- 针对项目的软件结构上的主要风险已经解决或处理完成。
- 通过完成软件结构上的主要场景建立软件体系结构的基线。
- 建立一个包含高质量组件的可演化的产品原型。
- 说明基线化的软件体系结构可以保障系统需求可以控制在合理的成本和时间范围内。
- 建立好产品的支持环境。
初始阶段的产出是:
- 用例模型(完成至少80%)-- 所有用例均被识别,大多数用例描述被开发
- 补充捕获非功能性要求和非关联于特定用例要求的需求
- 软件体系结构描述_可执行的软件原型
- 经修订过的风险清单和商业案例
- 总体项目的开发计划,包括纹理较粗糙的项目计划,显示迭代过程和对应的审核标准
- 指明被使用过程的更新过的开发用例
- 用户手册的初始版本(可选)
里程碑:生命周期的结构
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] 下一页
 【责编:Lili】 |