IT软件项目的生命周期(ppt 46页).ppt

Page1 第3章IT软件项目的生命周期 3 1IT软件项目生命周期的划分3 2IT软件项目生命周期中各阶段任务3 3IT软件项目生命周期中的重要概念3 4IT软件项目管理里程碑 Page2 3 1IT软件项目生命周期的划分 1 软件项目生命周期的概念任何软件的开发都要经历一个 生命周期 从软件的调研开始到淘汰的全过程 从项目批准到交付的过程 一般将项目分为以下4个阶段 识别需求 提出解决方案 执行项目 结束项目 Page3 1 软件项目生命周期的概念 对于典型的IT软件项目 项目的生命周期可以从不同的角度认识 从项目承担方看 项目是从接到合同正式开始的 到完成规定工作结束 从客户的角度看 项目是从确认有需求开始 到使用项目的成果实现商务目标结束 无论从哪个角度分析 软件项目的生命周期都包括识别 设计 实施和评估4个阶段 典型软件项目开发的生命周期如图3 1所示 Page4 2 典型软件项目开发的生命周期 图3 1典型软件项目开发的生命周期 Page5 3 瀑布模型 瀑布模型是美国WinstonRoyce向IEEEWESCON Royce Winston1970 提交的一篇名为 管理大规模软件系统的开发 ManagingtheDevelopmentofLargeSoftwareSystems 的论文中首次提出的 这种方法是从一个阶段成瀑布流入下一个阶段 所以这个模型就称为 瀑布模型 Page6 软件开发瀑布模型及不同阶段之间的交互 图3 2软件开发瀑布模型及不同阶段之间的交互 Page7 1 纯瀑布模型 软件概念 用户提出对软件的开发与初步需求 详细设计 编码和调试 选择合适的计算机语言 完成详细设计中的各个模块的编码并调试 初步设计 将用户需求分解成硬件与软件需求 并建立系统的整体结构模型 需求分析 开发者与用户交流 确定系统的目标 服务与约束 将初步设计的整体 结构继续分解为可实施编码的小模块 并完成流程图 系统测试 测试系统的各部分是否满足需求 Page8 2 改进的纯瀑布模型 生鱼片模型 主要缺点 因为阶段重叠 里程碑非常不明确 很难精确地进行过程跟踪 并行地执行活动可能导致无效的沟通 错误的想法以及低下的效率 生鱼片模型 是将模型中的连续的各阶段相互有较大幅度的重叠 例如 在需求分析完成之前可以进行初步设计和详细设计 主要优点 在项目比较小且定义得很好时 可以有效地减少文档的产生 是比较有效的模型 Page9 2 改进的纯瀑布模型 具有子系统的瀑布模型 初步设计中将系统分成几个逻辑上相对独立的子系统 每一个子系统都 采用相对独立的方法进行设计 形成了具有子系统的瀑布模型 图中 初步设计阶段将系统分成3个相对 独立的子系统 各子系统分别独立进行详细设计 编码和调试及子系统设计 最后统一进行系统测试 Page10 Boehm给出的一些成本数据 从表中我们能看出什么特点 Page11 4 原型模型 原型 Prototype 法是在20世纪80年代初 在总结和归纳结构化分析与设计方法开发软件项目的基础上 改进结构化系统分析与设计的过于繁琐 开发周期长 见效慢等缺点 借助第4代程序开发语言而产生的一种项目开发方法 这种方法是借助先进的软件开发工具根据用户提出的软件需求定义 快速建立一个软件系统的 原型 向用户展示待开发软件的全部或部分功能 在征求用户对原型软件的意见后 反复进行修改 完善 提高和确认 最终实现项目的目标 Page12 1 渐进原型模型图 渐进原型模型是从软件开发系统概念开始 根据软件需求定义 快速建立一个软件系统 原型 的生命周期模型 Page13 2 渐进原型模型的基本过程 原型建立通常是软件从最显著的方面开始 向用户展示待开发系统的全部或者部分功能 通常是完成的部分 然后根据用户对原型的反馈信息 反复进行修改 完善 提高和确认 直到开发者和用户都认为原型已经 足够好 最终实现项目目标 完成结尾工作 交付作为最终产品的原型 Page14 3 渐进原型模型的特点 直观 形象 更多地遵循了人们认识事物的规律 因而更容易被人们接受 采用模拟的手段 缩短了用户和系统分析 设计人员之间的距离 在整个系统开发过程中反馈是及时的 标准是统一的 可及时地暴露问题 确保系统实现的正确性 充分利用了新一代的软件工具 使得系统开发和运行的效率都大大提高 Page15 4 原型法的应用的软件支撑环境 要有一个方便灵活的关系数据系统 要有一套完整的程序生成软件 要有一个与数据库对应的 灵活方便的数据字典 有一个可以快速抽象或者能够容易提炼的原型 Page16 5 螺旋模型 螺旋模型示意图 Page17 1 螺旋模型说明 1988年Boehm提出 基于风险 的螺旋模型螺旋模型主要由4个部分组成 需求定义 风险分析 实现和评审螺旋模型是这4个部分组成的迭代模型 软件开发的过程每迭代一次 螺旋线就增加一周 系统产生一个新的版本 而软件开发的时间和成本又有新的投入 螺旋模型中的显著特点是在每个固定阶段对项目的风险进行评估 Page18 2 螺旋模型的迭代 每次迭代都包括以下六个步骤 1 确定下一阶段的目标 方案的约束条件 2 风险分析 评估及解决 3 为该系统构造合适的原型 4 评价方案 5 开发 验证软件产品 6 制定下一阶段计划 交付给下一步骤 开始新的迭代过程 Page19 例1质量螺旋模型 1 Page20 例1质量螺旋模型 2 Page21 例2软件产品螺旋模型 1 Page22 例2软件产品螺旋模型 2 Page23 6 编码修正模型 使用编码修正模型 一般是从一个大致的想法开始工作 可能有一个正式的规范 也可能没有 然后结合使用一些无论如何都称不上规范的设计 编码 调试和测试方法 来完成产品开发 编码修正模型有两点好处 不需要什么成本 不需要在除了纯粹编码工作以外的项目规划 文档编制 质量保证 标准实施或任何其他活动中花费时间 它只需要极少的专业知识 Page24 7 为项目选择最快速的生命周期 1 为项目选择最有效的生命周期模型 通常可以思考以下问题 1 在项目开始的时候 开发者和用户对需求的理解是否充分 在项目进行过程中 对需求的理解有可能出现改变吗 2 开发者对系统的整体框架的理解是否充分 是否有可能在项目进展过程中对系统框架进行重大改变 3 可靠性需求有多大 4 需要在项目中为未来的版本提前进行多少计划和设计 Page25 7 为项目选择最快速的生命周期 2 5 项目要承受多大的风险 6 是否被迫预先确定进度 7 需要具备在进展过程中进行变更的能力吗 8 需要在项目整个进展过程中提供给用户可视的进展情况吗 9 需要在项目整个进展过程中提供给管理者可视的进展情况吗 10 需要多少经验和技巧来成功地使用这种生命周期模型 Page26 3 2IT软件项目生命周期中各阶段任务 根据前面对IT软件项目各个主要模型生命周期的分析 可以将一般的软件项目开发过程详细划分为以下6个主要阶段 如图3 6所示 项目开发准备阶段调查研究阶段项目分析阶段项目设计阶段项目实施阶段维护与评价阶段 Page27 图3 6软件项目的开发阶段 Page28 1 项目开发准备阶段 当现行软件系统不满足业务需要时 公司领导层提出开发新软件系统的要求 公司管理咨询人员 或者负责信息化工作的人员 首先进行初步调查 确定是否进行立项 制定出新软件系统的开发计划 本阶段不属于项目的分析与设计 但确实是一个不可或缺的重要阶段 它往往对项目开发的成败起着至关重要的作用 如果项目开发采取外包的方式 本阶段还包括招标的过程 Page29 2 调查研究阶段 本阶段需要采取各种各样的方式进行调查研究 搞清目前系统的界限 组织分工 业务流程 资源状况及薄弱环节 需要绘制现行项目的有关图表 在掌握充分资料的基础上 与用户或公司协商讨论 提出初步的系统目标和项目计划 针对用户的情况和要达到的目标进行新系统开发的可行性研究 并提交可行性研究报告 Page30 3 项目分析阶段 本阶段是新系统的逻辑设计阶段 管理人员和系统分析人员使用一系列的图表工具构造出独立于任何物理设计的系统逻辑模型 并与文字说明 图表 流程 规范等共同组成系统的逻辑说明书 本阶段需要对现行系统中不能适应新项目要求的部分进行处理 必要时对企业的资产和业务流程及管理方式进行优化和重组 本阶段是新系统设计方案的优化过程 本阶段是各个阶段中的关键阶段 Page31 4 项目设计阶段 本阶段是新系统的物理设计阶段 根据新系统的逻辑模型进行物理模型的设计 具体地选择一个物理的计算机信息处理系统 要求具体地进行计算机过程和人工过程的各种详细设计 进行程序模块和处理过程 处理逻辑 的设计等 选择合理的硬件 软件 进行代码 输入界面 输出界面 文件 数据存储处理等 系统物理设计的关键是模块化 Page32 5 项目实施阶段 本阶段是新系统调试运行阶段 对操作人员进行培训 编制系统设计文档 使用手册和有关说明书 程序员对程序进行集成和调试 进行各种文件和数据库的建立 需要大量人力投入到数据收集 整理和录入工作中 本阶段的工作是十分艰巨的 本阶段投入的人力 物力 财力最多 花费时间最长 工作量最大 Page33 6 维护与评价阶段 本阶段是新系统调试后到投入运行之间的修改 完善 验证的阶段 本阶段完成的工作主要有 系统的处理逻辑 程序 文件 数据等的修改 评价系统的优劣 主要是指系统的工作质量和经济效益 如 输出信息的准确性 系统的可靠性和运行质量 系统的开发费用 使用维护费用 经济效益 工作效率的提高和服务质量的改善等 Page34 3 3IT软件项目生命周期中的重要概念 检查点 是指在规定的时间间隔内对项目进行的检查与复审工作 它是通过比较实际进展与计划进度之间的差异 并根据这个差异来进行调整的 里程碑 完成阶段性工作的标志 不同类型的项目里程碑不同 里程碑往往是一些重要活动的完工 或重要文档的交付 或阶段评审的通过 基线 指一个 或一组 配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态 基线是一些重要的里程碑 但相关交付产品要通过正式评审并作为后续工作的基准和出发点 Page35 3 4IT软件项目管理里程碑 在IT软件项目的整个生命周期 通常有3种类型的检查点 主里程碑 小里程碑 状态评估里程碑是开发人员和其他项目管理人员必须经常达成和满足的目标 通常是以各阶段所完成的文档来体现 每个里程碑都是 二分性 的 完成 和 没完成 两种状态 对于IT软件项目来说 如果不能设置好的里程碑 并监控执行 项目就可能会失控 并使成本预算和进度都难以管理 Page36 1 主里程碑 主里程碑是最重要的里程碑 它通常是指项目生命周期中的一些重要转折点 为项目提供战略目标 主里程碑可以看作是一个连续的过程 在这个过程中包括对不同因素的重新定义 主里程碑的设置是为了确保对需求的理解 对项目生命周期的计划 对产品的形式 功能和质量等因素保持连贯性和可控制性 在IT软件项目的整个生命周期中 一般存在4个主里程碑 如下表所示 Page37 IT软件项目的主里程碑 Page38 项目干系人所关注的问题重点 对一般的IT软件项目而言 项目主要干系人有 客户 关心项目的可行性 对需求的理解 时间及成本的预算 风险的评估以及产品的质量特征等 使用者 关心系统使用权的连贯性及产品的质量特征等系统设计师 主要关心需求的变化 系统的完整性及连贯性 平衡并分析时间 风险 质量 成本之间的关系开发人员 关心是否有足够详细的需求说明和使用情况的描述 以及选择组件的结构 开发环境等 维护人员 关心新系统与现行系统的协同工作能力 良好的维护性能等 Page39 2 小里程碑 小里程碑的形式和内容比较灵活 可以根据项目或组织的情况而变 主要为实现项目的目标提供战术方法 小里程碑需要通过项目的内容及周期长度来确定 设置小里程碑的主要目的是为了合理分配工作 细化管理的 粒度 Page40 1 使用小里程碑应遵循的原则 在项目早期建立小里程碑 让开发者建立自己的小里程碑 保持小里程碑的小型化特征 保持里程碑的二分性 制定一系列完整的里程碑 在短期计划 而不是长期计划 中应用小里程碑 Page41 2 小里程碑与任务列表的异同 相同 都是在一定 粒度 下跟踪工作的完成情况 不同 主要在于各自的侧重点不同 如 里程碑认为任务只有两种状态 完成和没完成任务列表没有这种限制里程碑定义的任务能在规定的时间内完成任务列表可以任意长度当脱离原来轨迹时 里程碑要求调整任务列表没有这种规定应用里程碑比通常应用的任务列表更严格 Page42 3 定期状态评估 状态评估的主要目的是根据反映项目进展情况的动态信息对项目进行评估 比较实际进展与计划进度之间的差异 并根据差异情况进行相应的调整 定期状态评估是一种有效的管理活动 按照规定的时间间隔 如月或季 进行相应的评估 定