初始阶段启动项目
初始阶段的全部目的是要启动项目。
初始阶段所作的工作给客户、开发组织以及其他项目相关人员都提供了保证:构架设计师和开发人员能够缓解关键风险,明确地表达候选架构,并生成最初的业务案例。
初始阶段概述
初始阶段的目标是生成具有必要内容的业务案例,以证明启动项目是正确的。为了生成这一案例,首先必须划定目标系统的范围。知道了这个范围,就可以弄清当前项目所包括的内容。了解哪些内容是构架所必须包括的,就可以定义关键风险的寻找范围,并用它来规定业务案例中费用、开发进度以及投资回到等因素的评估范围。
要尽量获取足够多的构架内容,以确信存在能够支持系统范围的构架。这也是“候选构架”索要表达的意图。
设法避免彻底的失败。通过急躁缓解风险、缩减风险发生的范围或者通过增加实际或资源的投入来避免哪些无法缓解的风险。
设法建立最初的业务案例,以便于从经济学角度考察预想的系统,也就是要对费用、开发进度和投资回报及早作出估计。此时要考察下面两个问题:
- 由软件产出的使用或出售所获得的利润是否超过用于开发的费用。
- 是否能及时进入十尝以获取利润?
尽力给项目组提供开发环境-过程和工具。
初始阶段初期
开始制定计划,扩展系统构想,并开始手机评价准则。
初始阶段开始之前
在初始阶段开始之前,你对所要做的事情已有一定的了解。尽管在初始阶段开始之前所作事情的程度各有不同,跨越了一个很宽的范围,但是仍然可以将其分成三种不同的情况
- 开发上市产品的软件开发机构。
- 为同一公司的其他部门开发系统的软件开发机构,即典型的内部开发机构。
- 为客户开发系统的软件开发机构。
制定初始阶段计划
在项目开始时,你可能会陷入进退两难的境地。有经验的开发人员会建议你制定计划,但你又没有制定计划所需要的大量信息。这是,你可以通过问自己“需要做什么”来搞清楚要计划的内容时什么?可以餐区如下步骤开始你的工作:
- 将开发人员在项目开始之前所搜集的信息集中起来。
- 把这些信息组织整理以便于使用。
- 召集一批知道如何使用这些信息的人员。
- 研究提出需要进一步了解的内容。
将工作限定在该阶段需要完成的几个关键目标上。然后,制定一个实验性的计划,以澄清与这些初始目标有关的需求,并在相应的用况中详细描述。制定用来创建一个候选构架的计划,该计划要将构架完善到恰能足以确定该项目是切实可行的,通常这个计划金是构架视图的一个操作。要尽快设法确定究竟需要一次迭代,还是在某些情况下需要两次迭代。
要记住,最初的计划只是实验性的。随着所掌握的信息量增多,要对计划进行修改,以包含新发现的内容。
扩展系统构想
第一步工作是扩展构想陈述,使其可以指导初始阶段的工作。
设立评价准则
当项目经理掌握了足够多的信息来开始为第一次迭代制定详细计划时,他也将制定表明迭代达到预期目标的评价准则。
- 确定系统范围,最系统的最初构想提出了关于系统范围的一些想法,但没有景区地定义系统的范围。其要点包括:
- 是否清楚哪些部分在系统之内?
- 是否是识别了所有的参与者?
- 是否弄清楚了跟参与者的哥哥接口的共性?
- 在系统范围之内的什么部分能作为一个哦概念股系统支持他自身?
- 解决本阶段所需要的需求中的不确定问题,初始阶段开始时的需求可能储在帆帆的构想和大量的文字描述之间。然而,这些初始需求可能比较含糊。评价的要点包括:
- 达到该阶段目标所需的有限数量的用况需求是否以及被识别和详细描述?
- 补充需求中的需求是否已被识别和详细描述?
- 建立候选构架,开发人员至少要开发出一个可用的构架。评价准则包括:
- 是否能够满足用户的需要?
- 构架是否可用?
- 缓解关键风险,关键风险时指哪些会危害项目成功的风险。评价的要点包括:
- 是否已识别出所有的关键风险?
- 已识别的风险是否以及缓解或者是否已制定出缓解的计划?
- 判断初始业务案例的价值,评价的要点时:初始业务案例是否足以说明继续进行该项目的合理性?
原型的初始迭代工作流
初始阶段,进行三组不同的活动。一是制定迭代计划;而是五个核心工作流;三是选择适合于该项目的开发环境。
五个核心工作流引言
初始阶段的大部分工作都在第一个工作流中完成;其中有一些工作在分析和设计工作流中进行;在最后的实现和测试工作流中只有少量的工作。在这个阶段中,所关注的是要证明新的概念,而不是要却博爱这种探索性的原型在任何细节都能正确运行。
把项目融入到开发环境中
开发环境由过程、执行过程以及为项目提供的服务所组成。
找出关键风险
初始阶段的任务是要识别和环境关键风险。关键风险是使项目不能实现的风险。
执行五个和兴工作流--从捕获需求到测试
本节将详细介绍在本阶段所要做的工作。

捕获需求
初始阶段的终点主要放在需求工作流上。这一工作流包括识别和详细描述与本阶段相关的用况。他包括以下几个主题:
- 列出作为系统特征清单候选的需求。
- 理解系统语境
- 以用况的形式捕获有关的功能性需求。
- 捕获有关的非功能性需求。
以用况捕获需求
- 确定参与者和用况
- 区分用况的优先级
- 详细描述一个用况
- 构造用户界面原型
- 构造用况模型
分析
这一阶段的成功是生成初始的分析模型。用该分析模型来精确定义用况和帮助生成候选构架。
- 构架分析,初始阶段的任务是:为了实现该姐u但的目标而挑选出需要仔细考虑的用况或场景-主要是理解和细化这些用况或场景。
- 分析一个用况
- 分析一个类和分析一个包
设计
本阶段设计工作流的主要目的是为包含在初步构架描述中的候选构架勾画出设计模型。
- 构架设计,开发初始的或第一个设计模型轮廓,完成设计模型构架视图的第一步工作。
- 设计一个用况
- 设计一个类和设计一个子系统。
实现
实现工作流的活动范围依赖于项目精力早期所做的决定。
测试
与分析、设计和实现工作流中的活动并行进行的是,测试工程师能力使自己了解目标系统的一般性质,考虑进行什么样的测试,并制定一些临时性的测试计划。然而由于探索性的演示原型主要是用作说明而不是提供进一步使用,所以,在初始阶段期间不进行大量的测试。
构造初始业务案例
在初始阶段后期,当发现项目有了一个候选构架并且能够缓解关键风险时,通过对项目的资源需求、投资金额以及十尝接受程度的综合考虑,就可以将这些构想转变成经理说的条款。业务案例的一方面是业务标书,另一方面是产品的最终使用所产生的经济效益。
对业务标书的勾画
对业务标书的估计公式依赖于最终产品的规模。然而,初始阶段末期的估计规模可能与最终的规模相差很大。
对投资回报的估计
业务估计构成了业务案例的一个方面,而另一方面,并不存在用来计算软件所能带来的收益的简单共识。
评估初始阶段中的迭代
在初始阶段开始时,一般有了足够的可用信息,项目经理便会制定评价准则来评价第一次迭代和整个阶段可否结束。
初始阶段平的最重要的成功使决定继续开发还是取消开发。可以检查这一阶段的介个目标(系统范围、关键风险、候选构架),从而决定继续开发还是取消开发。
制定细化阶段的计划
在初始阶段末期,我们开始考虑细化阶段的费用和进度安排,因而开始制定细化姐u但的计划。
初始阶段的可交付内容
初始姐u但完成以下一些内容:
- 一个特征清单。
- 描述系统语境的业务模型的第一个版本。
- 代表用况模型、分析模型、设计模型的第一个版本的首次剪辑。一些实现模型和测试模型的基本内容;补充需求的第一个版本。
- 包括用况、分析、设计和实现模型的视图轮廓的候选构架描述的第一个草案
- 可能有一个探索性概念证明原型,用来演示新系统的用途。
- 一个初始的风险清单和一个用况优先级清单。
- 开始制定整个项目计划,包括为阶段制定的通用计划。
- 业务案例的第一个曹参,他包括:也无预警和成功准则。