软件项目开发流程.ppt_第1页
软件项目开发流程.ppt_第2页
软件项目开发流程.ppt_第3页
软件项目开发流程.ppt_第4页
软件项目开发流程.ppt_第5页
已阅读5页,还剩66页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件开发流程SoftwareDevelopmentProcess jzwsc 软件生命周期 软件生命周期是软件产品或系统一系列相关活动的全周期 软件定义 确定软件开发总目标 确定工程的可行性 导出实现策略及系统功能 估计资源和成本 并且制定工程进度表 软件开发 具体设计和实现在前一个时期定义的软件 软件维护 使软件持久地满足用户的需要 1 问题定义 2 可行性研究 3 需求分析 4 总体设计 5 详细设计 6 编码和单元测试 7 综合测试 8 软件维护 软件产品或系统一系列相关活动的全周期 软件定义 软件开发 可行性分析 需求分析 总体设计 详细设计 编码 测试 软件发布 软件运行 软件维护 软件维护 问题定义 系统设计 系统实现 1 问题定义 要解决的问题是什么 确定用户要求解决的性质 工程的目标和规模 2 可行性研究 对于上一个阶段所确定的问题有行得通的解决办法吗 经济可行性 技术可行性 法律可行性 不同的方案3 需求分析 为了解决这个问题 目标系统必须做什么 确定系统必须具有的功能和性能 系统要求的运行环境 并且预测系统发展的前景 规格说明书 specification 4 总体设计 概要设计 概括地说 应该怎样实现目标系统 设计出实现目标系统的几种可能的方案 推荐一个最佳方案 5 详细设计 应该怎样具体地实现这个系统呢 设计出程序的详细规格说明 6 编码和单元测试写出正确的容易理解 容易维护的程序模块仔细测试编写出的每一个模块 7 综合测试集成测试和验收测试 现场测试或平行运行8 软件维护使系统持久地满足用户的需要 改正性维护 适应性维护 完善性维护 预防性维护 IEC12207软件生命周期 ISO IEC15504软件过程 软件过程 任务框架 各项任务的工作步骤运用方法的顺序 文档资料 管理措施 各个阶段的里程碑生命周期模型或过程模型典型的过程模型瀑布模型 Waterfallmodel 快速原型开发模型 RapidPrototypingmodel 增量模型 Incrementalmodel 螺旋模型 Spiralmodel 瀑布模型 理想的瀑布模型 实际的瀑布模型 软件过程 瀑布模型 续1 瀑布模型的特点阶段间具有顺序性和依赖性推迟实现的观点清楚地区分逻辑设计与物理设计 尽可能推迟程序的物理实现 质量保证的观点 文档驱动 每个阶段都必须完成规定的文档每个阶段结束前都要对所完成的文档进行评审 软件过程 瀑布模型 续2 瀑布模型的缺点开发过程一般不能逆转 否则代价太大规格说明很难理解 我知道这是按我的要求做的 但不是我想要的样子 软件的实际情况必须到项目开发的后期客户才能看到 文档驱动的两面性 快速原型模型 用户测试运行原型 建造 修改原型 听取用户意见 软件过程 快速原型模型 原型模型的特点快速原型的本质是 快速 快速原型可以取代规格说明阶段 但不是设计阶段 容易适应需求的变化有利于开发与培训的同步原型模型的应用范围对所开发的领域比较熟悉而且有快速的原型开发工具项目招投标时 可以以原型模型作为软件的开发模型进行产品移植或升级时 或对已有产品原型进行客户化工作时 原型模型是非常适合的 软件过程 快速原型模型 比较瀑布模型 试图一次就获得正确的产品快速原型 频繁变化 然后废弃 软件过程 增量模型 续1 增量模型的优点每个阶段交付一个可用的产品减少一个全新产品给客户带来的心理上的影响分阶段地交付产品不需要大的资金支出需求经常变化 增量模型的灵活性使其具有更加优越的适用性增量模型的困难需要一个开放的结构 方便构件的加入增量模型本身就是一个矛盾的名词 软件过程 增量模型 风险更大的增量模型 软件过程 螺旋模型 1988年 BarryBoehm正式发表了软件系统开发的 螺旋模型 它将瀑布模型和快速原型模型结合起来 强调了其他模型所忽视的风险分析简化版本 瀑布模型 风险分析每个阶段之前确定目标 可供选择的办法及其限制条件风险分析每个阶段之后评估计划下一阶段 简化的螺旋模型 完整的螺旋模型 软件过程 螺旋模型 续2 螺旋模型的优点容易确定什么时候已经对某一阶段的产品充分测试完毕维护和开发之间没有什么本质上的差别螺旋模型的缺点仅适合于大型软件风险驱动既是优点也是缺点 软件过程 建造 修补模型 对于100或200行长的短程序可以做得很好问题没有规格说明书没有设计不能令人满意 各种生命周期模型的比较 不知山林 险阻 沮泽之形者 不能行军 这个项目是做还是不做呢 可行性研究 一旦软件范围已经被标识出来 们自然会问 我们能够开放软件以满足改范围吗 项目是可行的吗 在软件危机时期人们通常会跳过这个阶段 往往陷入从开始就注定失败的项目泥潭中 可行性分析的目的是为了用最小的代价在尽可能短的时间内确定问题是否能够解决 必须记住 可行性分析不是要求解问题本身 而是要确定问题是否有解 可行性研究的任务 最根本的任务是对以后的行动方针提出建议如果问题没有可行的解 应该建议停止这项开发工程 以避免时间 资源 人力和金钱的浪费如果问题值得解 应该推荐一个较好的解决方案 并且为工程制定一个初步的计划 可行性研究的内容 1 技术可行性 2 经济可行性 3 操作可行性 4 社会可行性 法律可行性 5 抉择 可行性研究的任务 经济可行性 操作可行性 这个系统的经济效益能超过它的开发成本吗 使用现有的技术能实现这个系统吗 技术可行性 系统的操作方式在这个组织内行得通吗 技术可行性 度量一个特定技术信息系统解决方案的实用性及技术资源的可用性考虑的问题 1 开发风险分析 2 资源分析 3 相关技术的发展 现有技术能否实现新系统 技术难点 建议采用技术的先进性 可行性研究报告 包括总体方案和可行性论证两个方面内容 引言系统建设的背景 必要性和意义拟建系统的候选方案可行性论证方案的比较结论可行性分析报告要尽量取得有关管理人员的一致认识 经济可行性 度量系统解决方案的性能价格比 考虑的问题 成本 效益分析 开发 运行的成本 效益 有形成本 效益无形成本 效益价值和成本的关系质量与价值 成本的关系价值 成本的均衡 举例 该系统节省经费 该系统成本 盈亏平衡点 投资回收期 成本及效益分析图 操作可行性 用户使用可能性时间进度可行性组织和文化上的可行性 复查系统规模和目标 研究目前正在使用的系统 导出新系统的逻辑模型 评价可能解法 推荐行动方案 草拟开发计划 书写可行性报告等文挡 提交审查 符合要求吗 n y 什么是需求工程 需求工程提供了一个比较完善的流程和方法来解决如何定义一个待开发的软件系统 需求工程的内容 需求工程过程可以被描述为6个部分 需求获取 需求分析 需求传递 需求建模 需求确认和需求管理 需求工程的目标 开发出符合客户要求的系统需求 包括符合客户要求的界面提供有效的解决方案以便确定软件系统中的主要元素将定义的需求分配给系统中的每个元素 了解软件需求受系统的制约 对操作环境的影响制定合适的软件版本发布策略 以确定系统或软件需求实现的优先级确定软件需求 并根据客户需求变化进行必要的更新 什么是软件需求 1 用户解决问题或达到目标所需的条件或性能 2 系统或系统部件要满足合同 标准 规范或其它正式规定文档条件或性能 3 一种反映上面 1 或 2 所描述的条件或性能的文档说明 软件需求的层次 1 业务需求反映组织机构或客户对系统 产品的概括性要求 包括所要达到的业务目标 由项目视图与范围文档说明用户需求描述用户使用系统而要完成的各种任务 由用例 usecase 文档或方案脚本说明功能需求定义开发人员必须实现的软件功能 它源于用户需求 是软件需求说明书中重要的组成部分 软件需求的层次 2 需求层次之间的关系 不同层次成果 简单性描述 需求开发 1 需求获取 通过各种途径获取用户的需求信息 经过 定义问题 分析问题根本原因 分析涉众 定义系统边界 确定约束条件 需求分析 对获取的需求信息去伪存真 归纳处理 进行各种分析 试图掌握用户的真正意图和要求 需求获取 需求分析 需求定义 需求确认 需求开发 2 需求定义 根据需求调查和需求分析的结果 解释涉众需求 并整理成规范的 清晰的产品需求规格说明书需求确认是指开发方和客户方共同对 需求说明书 进行评审 双方对需求达成共识后作出承诺 并符合优秀需求陈述的特征 包括完整 正确 可行 必要 具有优先级 无二义性和可验证 需求获取 需求分析 需求定义 需求确认 需求管理 需求管理是针对不断变化的客户需求加以收集 处理和跟踪 并建立软件需求的基准线 以作为项目中软件开发活动过程和产品度量和变更管理的基础 需求管理可以分为需求评审 需求跟踪和需求变更控制需求变更控制是需求管理中最主要的工作 软件设计 系统架构设计 详细设计 软件设计的目标 可靠性性能和安全性可扩展性可定制性或可移植性可维护性可重用性 体系结构设计任务 设计软件系统结构 如系统层次结构的划分 分布式结构的布局 确定设计元素 为设计元素分配特定功能 确定设计元素之间的关系 完成相应的通讯 同步与数据存取的协议和接口的设计 分析系统的规模和负载等 使系统满足性能 安全性等要求 对不同的设计方案进行比较和分析 选择最优的解决方案 编写设计文档 设计文档评审 体系结构设计视角 软件体系结构是一个抽象的系统规范 包含一定形式的结构化元素 对程序 系统各构件的可见特性 结构及其相互之间关系的描述 详细设计 详细设计就是考虑在技术上如何实现已设计好的体系结构 如何实现已定义的软件功能主要任务是为每个模块确定所采用的算法 程序流程和数据结构 确定每个模块的接口细节 部署设计 构造软件系统的逻辑体系结构 包括系统层次依赖关系将逻辑体系结构中指定的组件映射到物理环境 从而生成一个高级部署体系结构创建一个实现规范创建一系列详细说明实现软件部署方案的计划 设计评审 软件设计评审 主要是技术评审 也包括文档审查 软件设计的审查涉及软件体系结构和详细设计结果 其审查对象是产品规格设计说明 系统架构和技术设计文档 测试计划和测试用例 其目的是保证软件设计和需求分析保持一致 使设计更好地符合用户需求和业务需求 确保软件系统能满足系统功能性和非功能性的需求 实施的丰富内容 编程 单元测试 单元测试 是验证那些可单独被测试的软件部分其隔离的功能特性单元测试的对象是构成软件产品或系统的最小的独立单元 驱动程序和桩程序 驱动程序 driver 对底层或子层模块进行 单元或集成 测试时所编制的调用被测模块的程序 用以模拟被测模块的上级模块桩程序 stub 对顶层或上层模块进行测试时 所编制的替代下层模块的程序 用以模拟被测模块工作过程中所调用的模块 集成测试 集成测试是将已分别通过测试的单元按设计要求组合起来再进行的测试 以检查这些单元之间的接口是否存在问题持续集成 自顶向下法 Top downIntegration 自底向上法 Bottom upIntegration 功能测试 每项功能符合实际要求功能逻辑清楚 符合使用者习惯菜单 按钮等各项操作是否正常 灵活系统的界面清晰 美观系统的各种状态按照业务流程而变化 并保持稳定能接受正确的数据输入 对异常数据的输入可以进行提示 容错处理等数据的输出结果准确 格式清晰 可以保存和读取软件升级后 能继续支持旧版本的数据与外部应用系统的接口有效 系统测试 负载测试 Loadtest 压力测试 stresstest 容量测试 Capacitytest 性能测试 Performancetest 安全性测试 Securitytest 容错测试 Recoverytest 兼容性测试 Compatibilitytest 可靠性测试 Reliabilitytest 验收测试 验收测试是是技术测试的最后一个阶段 也称为交付测试 验收测试一般会根据产品规格说明书严格地检查产品 逐字逐句地对照说明书以检查事先定义的软件产品的各项具体要求 确保所开发的软件产品符合用户期望和需求 2 5部署 运行和维护 2 5 1系统部署2 5 2软件运行和技术支持2 5 3维护过程 系统部署 开发试验性系统对试验性系统进行全面认证测试通过 开始规划原型系统根据培训规划培训部署的管理员和用户完成原型系统的网络构建 软硬件的安装和配置数据备份或做好可以恢复 Roll back 的准备将数据从现有应用程序迁移到当前解决方案进行相关的设置 定制和数据初始化处理针对所有基本功能进行原型验证完成所有的部署 软件运行 确定和管理由于引人并发操作软件而带来的操作上的风险按要求的步骤和在要求的操作环境中运行软件提供操作上的技术支持 以便解决操作过程个出现的问题确保软件 或主机系统 有足够的能力满足用户的需求 技术支持 基于实施情况 确定客户所需要的支持服务通过提供适当的服务来满足客户的需求针对客户对产品本身及其相应的支持服务的满意程度进行持续的评估 维护过程 确定组织 操作以及接口对现行系统的影响对软件进行设计更新 代码修改或系统参数调整 硬件升级等 并进行测试验证一旦系统或系统组件发生了变更 应及时更新有关的文档移植系统与软件 以满足

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论