软件项目开发流程

1、软件生命周期：软件生命周期是软件产品或系统一系列相关活动的全周期。1软件定义：确定软件开发总目标；确定工程的可行性；导出实现策略及系统功能；估计资源和成本，并且制定工程进度表。2软件开发：具体设计和实现在前一个时期定义的软件3软件维护：使软件持久地满足用户的需要。1.问题定义、2.可行性研究、3.需求分析4.总体设计、5.详细设计、6.编码和单元测试、7.综合测试8.软件维护软件定义软件开发可行性分析需求分析总体设计详细设计编 码测 试软件发布软件运行软件维护软件维护问题定义系统设计系统实现1. 问题定义 “要解决的问题是什么?” 确定用户要求解决的性质、工程的目标和规模。2. 可行性研究 “

2、对于上一个阶段所确定的问题有行得通的解决办法吗?” 经济可行性、技术可行性、法律可行性、不同的方案3. 需求分析 “为了解决这个问题，目标系统必须做什么” 确定系统必须具有的功能和性能，系统要求的运行环境，并且预测系统发展的前景。 规格说明书(specification)4. 总体设计（概要设计） “概括地说，应该怎样实现目标系统?” 设计出实现目标系统的几种可能的方案。推荐一个最佳方案。5. 详细设计 “应该怎样具体地实现这个系统呢?” 设计出程序的详细规格说明。6. 编码和单元测试 写出正确的容易理解、容易维护的程序模块 仔细测试编写出的每一个模块。7. 综合测试 集成测试和验收测试，现场

3、测试或平行运行8. 软件维护 使系统持久地满足用户的需要。 改正性维护，适应性维护，完善性维护，预防性维护。IEC12207软件生命周期 ISO/IEC15504软件过程 软件过程软件过程 任务框架，各项任务的工作步骤 运用方法的顺序、文档资料、管理措施，各个阶段的里程碑 生命周期模型或过程模型 典型的过程模型1.瀑布模型(Waterfall model)2.快速原型开发模型(Rapid Prototyping model)3.增量模型(Incremental model)4.螺旋模型(Spiral model)瀑布模型理想的瀑布模型实际的瀑布模型瀑布模型的特点1.阶段间具有顺序性和依赖性2.

4、推迟实现的观点清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现。3.质量保证的观点(文档驱动)每个阶段都必须完成规定的文档每个阶段结束前都要对所完成的文档进行评审瀑布模型的缺点 开发过程一般不能逆转，否则代价太大 规格说明很难理解：“我知道这是按我的要求做的，但不是我想要的样子。” 软件的实际情况必须到项目开发的后期客户才能看到。（文档驱动的两面性）用户测试运行原型建造/修改 原型 听取用 户意见 原型模型的特点 快速原型的本质是“快速” 快速原型可以取代规格说明阶段，但不是设计阶段，容易适应需求的变化 有利于开发与培训的同步 原型模型的应用范围 对所开发的领域比较熟悉而且有快速的原型开

5、发工具 项目招投标时，可以以原型模型作为软件的开发模型 进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型是非常适合的 比较 瀑布模型试图一次就获得正确的产品 快速原型频繁变化，然后废弃 增量模型的优点 每个阶段交付一个可用的产品 减少一个全新产品给客户带来的心理上的影响 分阶段地交付产品不需要大的资金支出 需求经常变化，增量模型的灵活性使其具有更加优越的适用性 增量模型的困难 需要一个开放的结构，方便构件的加入 增量模型本身就是一个矛盾的名词风险更大的增量模型1988年，Barry Boehm正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模

6、型所忽视的风险分析 简化版本：瀑布模型+风险分析 每个阶段之前- 确定目标，可供选择的办法及其限制条件- 风险分析 每个阶段之后- 评估- 计划下一阶段 螺旋模型的优点 容易确定什么时候已经对某一阶段的产品充分测试完毕 维护和开发之间没有什么本质上的差别 螺旋模型的缺点 仅适合于大型软件 风险驱动既是优点也是缺点 对于100或200行长的短程序可以做得很好 问题 没有规格说明书 没有设计 不能令人满意生命周期模型生命周期模型优点优点缺点缺点建造-修补模型适用于不需要任何维护的小程序不适于重要的程序瀑布模型文档驱动的有序方法交付产品可能不符合客户的要求快速原型模型确保交付的产品符合客户的要求还没

7、有证明无懈可击增量模型增大投资的早期回报要求开放的结构，可能退化为建造-修补模型螺旋模型结合上述所有模型的特性只能用于大型的内部软件产品，开发者必须精通风险分析和风险排除这个项目是做还是不做呢？l 一旦软件范围已经被标识出来，们自然会问：“我们能够开放软件以满足改范围吗？项目是可行的吗？”在软件危机时期人们通常会跳过这个阶段，往往陷入从开始就注定失败的项目泥潭中。l 可行性分析的目的是为了用最小的代价在尽可能短的时间内确定问题是否能够解决。l 必须记住：。 最根本的任务是对以后的行动方针提出建议 如果问题没有可行的解，应该建议停止这项开发工程，以避免时间、资源、人力和金钱的浪费 如果问题值得解

8、，应该推荐一个较好的解决方案，并且为工程制定一个初步的计划可行性研究的任务 经济可行性 操作可行性 这个系统的经济效益能超过它的开发成本吗？使用现有的技术能实现这个系统吗？技术可行性 系统的操作方式在这个组织内行得通吗？ 包括总体方案和可行性论证两个方面内容： 引言 系统建设的背景、必要性和意义 拟建系统的候选方案 可行性论证 方案的比较 结论可行性分析报告要尽量取得有关管理人员的一致认识举例举例 1 2 3 4 5 年年604020 0成本成本- -效益效益( (万元万元) )该系统节省经费该系统节省经费该系统成本该系统成本盈亏平衡点盈亏平衡点投资回收期投资回收期 - -成本及效益分析图成本

9、及效益分析图复查系统规模和目标复查系统规模和目标研究目前正在使用的系统研究目前正在使用的系统导出新系统的逻辑模型导出新系统的逻辑模型评价可能解法，推荐行动方案，评价可能解法，推荐行动方案，草拟开发计划草拟开发计划书写可行性报告等文挡，提交审查书写可行性报告等文挡，提交审查符合要求吗？符合要求吗？ny 需求工程提供了一个比较完善的流程和方法来需求工程提供了一个比较完善的流程和方法来解决如何定义一个待开发的软件系统解决如何定义一个待开发的软件系统 需求工程过程可以被描述为需求工程过程可以被描述为6 6个部分：个部分： 需求获取、需求分需求获取、需求分析、需求传递、需求建模、需求确认和需求管理析、需

10、求传递、需求建模、需求确认和需求管理 开发出符合客户要求的系统需求，包括符合客户要求的界面 提供有效的解决方案以便确定软件系统中的主要元素 将定义的需求分配给系统中的每个元素，了解软件需求受系统的制约、对操作环境的影响 制定合适的软件版本发布策略，以确定系统或软件需求实现的优先级 确定软件需求，并根据客户需求变化进行必要的更新（1）用户解决问题或达到目标所需的条件或性能（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档条件或性能（3）一种反映上面（1）或（2）所描述的条件或性能的文档说明。 业务需求业务需求反映组织机构或客户对系统、产品的概括性要求，包括所要达到的业务目标，由项目视图

11、与范围文档说明 用户需求用户需求描述用户使用系统而要完成的各种任务，由用例（use case）文档或方案脚本说明 功能需求功能需求定义开发人员必须实现的软件功能，它源于用户需求，是软件需求说明书中重要的组成部分 需求层次之间的关系需求层次之间的关系不同层次成果不同层次成果简单性描述简单性描述 需求获取需求获取：通过各种途径获取用户的需求信息， 经过“定义问题分析问题根本原因分析涉众定义系统边界确定约束条件” 需求分析需求分析：对获取的需求信息去伪存真、归纳处理，进行各种分析，试图掌握用户的真正意图和要求 需求获取需求获取需求分析需求分析需求定义需求定义需求确认需求确认 需求定义需求定义：根据需

12、求调查和需求分析的结果，解释涉众需求，并整理成规范的、清晰的产品需求规格说明书 需求确认需求确认是指开发方和客户方共同对需求说明书进行评审，双方对需求达成共识后作出承诺，并符合优秀需求陈述的特征，包括完整、正确、可行、必要、具有优先级、无二义性和可验证 需求获取需求获取需求分析需求分析需求定义需求定义需求确认需求确认 需求管理是需求管理是针对不断变化的客户需求加以收集、处理和跟踪，并建立软件需求的基准线，以作为项目中软件开发活动过程和产品度量和变更管理的基础。 需求管理可需求管理可以分为需求评审、需求跟踪和需求变更控制 需求变更控制是需求管理中最主要的工作系统架构设计系统架构设计详细设计详细设

13、计 可靠性可靠性 性能和安全性性能和安全性 可扩展性可扩展性 可定制性或可移植性可定制性或可移植性 可维护性可维护性 可重用性可重用性高可靠性高可靠性高可维护性高可维护性高可理解性高可理解性高效率高效率 软件设计的目标 设计软件系统结构，如系统层次结构的划分、分布式结构的布局。 确定设计元素，为设计元素分配特定功能。 确定设计元素之间的关系，完成相应的通讯、同步与数据存取的协议和接口的设计。 分析系统的规模和负载等，使系统满足性能、安全性等要求。 对不同的设计方案进行比较和分析，选择最优的解决方案。 编写设计文档。 设计文档评审 软件体系结构是一个抽象的系统规范，包含一定形式软件体系结构是一个

14、抽象的系统规范，包含一定形式的结构化元素，对程序系统各构件的可见特性、的结构化元素，对程序系统各构件的可见特性、结构及其相互之间关系的描述结构及其相互之间关系的描述 详细设计就是考虑在技术上如何实现已设计好的体系结构、如何实现已定义的软件功能 主要任务是为每个模块确定所采用的算法、程序流程和数据结构，确定每个模块的接口细节 构造软件系统的逻辑体系结构，包括系统层次依赖关系 将逻辑体系结构中指定的组件映射到物理环境，从而生成一个高级部署体系结构 创建一个实现规范 创建一系列详细说明实现软件部署方案的计划 软件设计评审，主要是技术评审，也包括文档审查。 软件设计的审查涉及软件体系结构和详细设计结果

15、，其审查对象是产品规格设计说明、系统架构和技术设计文档、测试计划和测试用例。 其目的是保证软件设计和需求分析保持一致，使设计更好地符合用户需求和业务需求，确保软件系统能满足系统功能性和非功能性的需求 单元测试单元测试:是验证那些可单独被测试的软件部分其隔离的功能特性 单元测试的对象是构成软件产品或系统的最小的独立单元 驱动程序驱动程序（driver），对底层或子层模块进行（单元或集成）测试时所编制的调用被测模块的程序，用以模拟被测模块的上级模块 桩程序桩程序（stub），对顶层或上层模块进行测试时，所编制的替代下层模块的程序，用以模拟被测模块工作过程中所调用的模块。 集成测试是将已分别通过测试

16、的单元按设计要求组合起来再进行的测试，以检查这些单元之间的接口是否存在问题 持续集成 每项功能符合实际要求 功能逻辑清楚，符合使用者习惯 菜单、按钮等各项操作是否正常、灵活 系统的界面清晰、美观 系统的各种状态按照业务流程而变化，并保持稳定 能接受正确的数据输入，对异常数据的输入可以进行提示、容错处理等 数据的输出结果准确，格式清晰，可以保存和读取 软件升级后，能继续支持旧版本的数据 与外部应用系统的接口有效负载测试负载测试（Load test）/压力测试(stress test)容量测试容量测试（Capacity test ）性能测试性能测试（Performance test）安全性测试安全

17、性测试（Security test ）容错测试容错测试（Recovery test） 兼容性测试兼容性测试（Compatibility test）可靠性测试可靠性测试（Reliability test） 验收测试是是技术测试的最后一个阶段，也称为交付测试。 验收测试一般会根据产品规格说明书严格地检查产品，逐字逐句地对照说明书以检查事先定义的软件产品的各项具体要求，确保所开发的软件产品符合用户期望和需求 2.5.1 系统部署系统部署 2.5.2 软件运行和技术支持软件运行和技术支持 2.5.3 维护过程维护过程 开发试验性系统 对试验性系统进行全面认证 测试通过，开始规划原型系统 根据培训规划培

18、训部署的管理员和用户 完成原型系统的网络构建、软硬件的安装和配置 数据备份或做好可以恢复（Roll-back）的准备 将数据从现有应用程序迁移到当前解决方案 进行相关的设置、定制和数据初始化处理 针对所有基本功能进行原型验证 完成所有的部署 确定和管理由于引人并发操作软件而带来的操作上的风险 按要求的步骤和在要求的操作环境中运行软件 提供操作上的技术支持，以便解决操作过程个出现的问题 确保软件（或主机系统）有足够的能力满足用户的需求 基于实施情况，确定客户所需要的支持服务 通过提供适当的服务来满足客户的需求 针对客户对产品本身及其相应的支持服务的满意程度进行持续的评估 确定组织、操作以及接口对现行系统的影响 对软件进行设计更新、代码修改或系统参数调整、硬件升级等，并进行测试验证 一旦系统或系统组件发生了变更，应及时更新有关的文档 移植系统与软件，以满足系统运行环境的要求 尽量减少软件与系统对用户使用的影响 为及时满足用户的需求和系统性能、稳定性等要求，保持系统操作完整性的前提下对系统进行变更、移植与升级，包括硬件、软件、操作手册、网络等方面的维护 计划计划 计划就是预测未来，将不确定性转化为确定性计划就是预测未来，将不确定性转化为确定性 计划就是