1、本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件特征（软件特征（1）最根本的：软件是一种逻辑元素而不是物理元素软件是开发出的，而不是用传统的方法制造出来的软件不会被用坏时间失败概率一般产品的浴盆曲线本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件特征（软件特征（2）时间失败概率软件失败概率实际曲线软件失败概率理想曲线本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件特征（软件特征（3）工业界已经走向了标准化装配时代，然而绝大多数软
2、件还是定制出来的。科学计算函数库（60年代）重用数据结构重用组件本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。成本结构发生了巨大的变化成本结构发生了巨大的变化一次性的制造成本介质成本的可忽略性逻辑产品不可回逆的投入维护成本的增加服务是质量要素中的重点本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件危机软件危机“软件危机” 是1958年在NATO会议上作为一个正式的议题被提出来 软件项目不成功的例子比比即是：1999 年 10 月，耗资 1.25 亿美元的 NASA 的火星气象卫星失踪（
3、公英制转换）本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件危机软件危机一些数据：大约70的软件开发项目超出了估算的时间，大型项目平均超出计划交付时间20到50，90以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高美国政府审计局：只有不到2的合同定购软件在发布时具有可用性98以上的项目都失败了本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件危机软件危机一种看法“两难境地（Crunch Mode）”：处于两难境地的项目面临无法达到最初目标的威胁（费用、进度表、功能性
4、等），而项目团队努力想跨越困境。 “我们正处于两难境地，在半夜之前是不会回家”“死亡行军（Death March）”：用来描述其进度表几乎不可能完成的项目。 “这是一个死亡行军项目，我希望自己不要参与进去”本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件危机软件危机更准确的说法：慢性痛苦（chronic affliction) Suggested by Prof. Daniel Tiechrow, University of Michigan尽管忍受痛苦，但是软件依然在我们这个世界起着越来越重要的作用，但是如果能够医治痛苦，那么软件业将发
5、展得更加健康。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件危机的主要特征软件危机的主要特征软件开发周期大大超过规定日期;软件开发成本严重超标;软件质量难于保证本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件成功的标准软件成功的标准s用户在用s用户可很容易做完要做的事失败的根本原因：开发人员写出的东西达不到用户要求(人的问题.技术问题)本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。规模复杂性生产率软件技术面临的问题软件技术面临的
6、问题本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。Exchange2000Windows20002000项目经理项目经理25人人约约250人人开发人员开发人员140人人约约1700人人测试人员测试人员350人人约约3200人人例例:Windows95有有1000万行代码万行代码 Windows2000有有5000万行代码，万行代码， 3000多个工程师，几百个小团队。多个工程师，几百个小团队。Exchange2000和和 Windows2000开发人员结构开发人员结构本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之
7、处，请联系本人或网站删除。“软件工程案例分析”课程与其它软件专业课的区别(1) 立足于系统的整体。(2) 系统分析、系统设计、 测试及维护的方法实践。(3) 构筑一个软件系统，实践 软件开发全过程。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。用户分析员程序员系统分析员的地位本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。“一个好的工业，应有一套良好的标准来配套”软件工业化生产过程应具备的特点明确的工作步骤详细具体的规范化文档明确的质量评价标准本文档所提供的信息仅供参考之用，不能作为科学依
8、据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件产品的标准化软件开发过程的标准化本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件工程技术的两个明显特点 强调规范化 强调文档化本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。新世纪软件产业的趋势新世纪软件产业的趋势网络化趋势：计算机与通信的融合趋势 万维网智能网络服务化趋势：“打包式”软件 “服务式”软件全球化趋势本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。中国软件产业发展主
9、要问题中国软件产业发展主要问题产业规模小、集中度低产业竞争力弱，缺乏核心技术市场秩序较为混乱，盗版严重本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。制约软件产业发展的因素制约软件产业发展的因素软件开发规范与标准知识产权环境知识结构公司体制本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。项目与项目管理项目与项目管理项目是什么没有例行的任务需要计划特定的目标需要满足或者特定的产品需要生成项目有一个预定义的时间范围工作不仅仅是为自己，也是为他人工作中有些特性工作分为若干阶段项目完成需要资源项目是
10、大型的或者复杂的项目管理是什么 项目管理是在项目活动中应用知识，技能，工具和技术来满足项目需求的过程，它通过初始化，计划，执行，控制和结束等活动来完成。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件项目与软件项目与软件项目管理软件项目管理软件项目的特征 不可见 复杂性（以每一单位货币来看） 灵活性：软件去适应人或组织而不是相反一致性一致性软件项目管理 为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，
11、请联系本人或网站删除。软件项目的活动软件项目的活动需求分析描述设计编码校验安装维护支持本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件项目分类软件项目分类按软件类别信息系统：与组织接口嵌入式系统：接口是机器操作系统是一个信息系统还是嵌入式系统？ 有些项目是为了生成某一产品，而某些项目的进行是为了达到某些目标。许多软件项目分为两个阶段，第一阶段是目标驱动，第二阶段再生成真正的软件产品。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。从系统的角度看软件项目从系统的角度看软件项目一个项目关注于
12、生成一个系统和/或将一个旧系统转换为一个新系统系统，子系统和环境开放和封闭系统项目失败的一个原因是技术人员不能够开放系统和立即接受外界的变化。部分优化例如：可能很高效，但是难于修改社会技术系统软件项目属于此类本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件项目中的人员软件项目中的人员项目影响者(stakeholders)项目小组内部：项目小组外部，但是在同一组织内：项目小组和组织外部：如客户不同的项目影响者有不同的目标，因而项目领导者需要能够协调这些目标。Boehm和Ross提出软件项目管理的“W理论”，该理论关注于所有各方都能从项目种获
13、益因而对项目的成功都有兴趣。（W代表Everyone a Winner）本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件开发面临的挑战软件开发面临的挑战处理最终日期（deadlines）(85%)处理资源约束（83）与任务小组有效的沟通（80）从小组成员处得到承诺（74）建立可测量的milestone（90）处理变化（60）得到团队公认的项目计划（57）从管理层得到承诺（45）处理冲突（42）管理销售商和子项目承包商（38）本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。项目经理面临的挑
14、战项目经理面临的挑战估计和计划缺少质量标准和度量缺少组织决策的指南缺少使进度可视化的技术角色定义不正确的成功准则缺少标准本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。项目成员面临的挑战项目成员面临的挑战工作的不正确的描述IT的管理失误缺少应用领域的知识缺少及时的文档前续任务没有及时完成包括设备没及时提供用户与技术员之间缺乏交流缺少质量控制软件环境的改变Deadline压力本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件项目常见错误软件项目常见错误选自快速软件开发产品相关的错误需求镀金：
15、项目具有比实际需求多得多的性能功能蔓延：项目平均会有25%的需求变更（Jones 1994）开发人员的镀金：开发人员着迷于新技术又推又拉的交易：经理在批准项目进度顺延时又加入了新的功能研究导向的开发本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件项目常见错误（续）软件项目常见错误（续）过程中的错误缺乏计划过于乐观的计划在压力下放弃计划缺乏足够的风险管理承包人导致的失败在模糊的项目前期浪费时间前期活动不合要求过程中的错误 设计低劣 缺少质量保证措施 缺少管理控制 太早和过于频繁的集成 项目估算时遗漏必要的任务 追赶计划 鲁莽编码本文档所提供
16、的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件项目常见错误（续）软件项目常见错误（续）技术相关的错误银弹综合症: 过于相信以前没有采用过的技术的宣传过高估计了新技术或方法带来的节省量项目中间切换工具缺少自动的源代码控制手段本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。 软件项目常见错误（续）软件项目常见错误（续）人员相关的错误 挫伤积极性 人员素质低 对有问题的员工失控 英雄主义 项目后期加入人员：“火上加油” 办公环境差 开发人员与客户之间发生摩擦 不现实的预期本文档所提供的信息仅供参考之用，
17、不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件项目常见错误（续）软件项目常见错误（续） 缺乏有效的高层对项目的支持 缺乏各种角色的齐心协力 缺乏用户介入 政治高于物质 充满想像：“项目组没人真正相信他们能够按给定的计划进度完成项目，但他们认为如果每个人能够努力工作，并且不出现问题，他们可能会很幸运地按时完成任务。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件项目常见的错误软件项目常见的错误试分析以下故事中的项目所存在的错误： 一天，一位年青人被选来“写”一个用在自动化制造设备上的程序。选择他的理由很简单：他是技
18、术小组中唯一参加过编程培训的人。他懂得汇编语言和Fortran语言，但是他不知道软件工程，更不知道软件计划和跟踪方面的知识。软件开发过程模型选择软件开发过程模型选择本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。主要内容主要内容项目实施的方法选择问题识别项目中的高风险软件开发过程模型的选择 可选择的模型 软件开发项目过程的选择软件开发方法本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。项目实施的方法选择项目实施的方法选择技术选择 技术选择将影响： 开发人员的训练需要 人员招聘 开发环境硬件和
19、软件 系统维护安排方法选择 方法选择将影响： 开发人员组合 实施的进度安排 开发策略选择本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。项目实施的方法选择项目实施的方法选择p步骤： 分析目标驱动还是产品驱动 分析项目其他特征 面向数据还是面向控制 通用还是专用 是否需要专用工具支持的专门技术 是否有特殊的安全性要求 对软硬件有何要求本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。识别项目中的高风险识别项目中的高风险产品不确定性：系统需求理解的准确性。用户在开始时有可能对系统应该什么样都无法确
20、定。在某些环境中，精确而有效的需求描述可能迅速变得过时。过程不确定性：在项目开始时需要选择方法或过程模型，或者一种新的工具，任何对原先采用的开发方法的变化都将引入不确定性资源不确定性：项目进行中资源的数量可能发生变化本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件开发过程模型的选择软件开发过程模型的选择开发一个软件需要选择开发策略（包括过程，方法和工具）以及通用阶段，这些策略和阶段被称为过程模型“过程”：相关联的活动过程模型的选择基于项目和应用的特性，使用的工具和方法，所需要的控制方法和交付物。本文档所提供的信息仅供参考之用，不能作为科学
21、依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件生存周期 (Software Life Cycle) 软件产品或软件系统从设计、投入使用到被淘汰的全过程软件生存期的阶段划分可行性研究与计划需求分析总体设计详细设计实现集成测试确认测试使用和维护软件生存周期软件生存周期计算机软件开发规范上游下游本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。新的国际标准定义的软件生存过程（1995 ISO/IEC 12207）软件生存期过程支持过程组织过程主要过程获取过程供应过程开发过程运行过程维护过程文档编制过程配置管理过程质量保证过程验证过程确认
22、过程联合评审过程审核过程问题解决过程管理过程基础设施过程改进过程培训过程本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。只考虑编写程序 涉及整个软件生存周期扩展到软件工作的范围本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件开发全部过程、活动和任务的结构框架。直观表达软件开发全过程明确规定要完成的主要活动、任务和开发策略也称为：软件过程模型软件生存周期模型软件工程范型软件开发模型软件开发模型本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除
23、。问题求解的一般过程问题求解的一般过程问题求解的一般过程实际问题并不能简单划为四个阶段，各个阶段会在问题的不同层次上同时并存软件开发实际上是一个“混沌”（chaos）过程问题定义方案集成技术开发现状本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。A.编码修正模型编码修正模型Code and Fix Code like Hell(鲁莽编码)从一个大致的想法开始工作，然后经过非正规的设计、编码、调试和测试方法，最后完成工作可能有可能没有的规范发布（可能）本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站
24、删除。编码修正模型编码修正模型好处： 成本可能很低 只需要很少的专业知识，任何写过程序的人都可以 对于一些非常小的、开发完后就会很快丢弃的软件可以采用对于规模稍大的项目，采用这种模型是很危险的本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。B.瀑布模型（瀑布模型（Waterfall Model)所有过程模型的祖宗项目从开始到结束按照一定的顺序执行瀑布模型是文档驱动的，各个阶段不连续也不交叉本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。B.瀑布模型 (Waterfall Model)可行性研
25、究与计划需求分析设计编码运行维护测试定义阶段开发阶段维护阶段适应场合？适应场合？优缺点？优缺点？本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。瀑布模型的适用场合瀑布模型的适用场合有一个稳定产品定义稳定产品定义和很容易被理解的技术解决容易被理解的技术解决方案方案时，纯瀑布模型特别合适对一个定义得很好的版本进行维护维护或将一个产品移植平台移植平台，瀑布模型也特别合适。纯瀑布模型能够降低管理费用降低管理费用，因为你可以预先完成所有计划。对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适，因为可以用顺序方法处理问题用顺序方法处理问题。在质量需求
26、高质量需求高于成本需求和进度需求的时候，它尤为出色。当开发队伍的技术力量比较弱技术力量比较弱或者缺乏经验时，瀑布模型更为适合。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。瀑布模型缺点瀑布模型缺点纯瀑布模型在项目开始时，在设计工作完成前和代码写出来前，很难充分描述需求。瀑布模型最主要问题是缺乏灵活性缺乏灵活性。必须在项目开始前说明全部需求。但这恰恰是非常困难的。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。按照传统瀑布模型开发软件的特点阶段间具有顺序性和依赖性。推迟实现的观点。每个阶段必
27、须完成规定的文档;每个阶段结束前完成文档审查,及早改正错误。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。C.瀑布模型变种：瀑布模型变种：V型模型型模型该方法是对瀑布模型的修正，强调了验证活动可行性研究用户需求系统设计程序设计编 码程序测试系统测试用户接受评价修正修正修正修正本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。D. 瀑布模型变种：生鱼片模型瀑布模型变种：生鱼片模型把阶段重叠起来的瀑布模型起源于日本硬件开发模型（富士通施乐）软件概念需求分析架构设计详细设计编码和调试系统测试本文档
28、所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。生鱼片模型的特点和缺点生鱼片模型的特点和缺点传统的瀑布模型强调阶段之间最小重叠重叠，而生鱼片模型强调大幅度重叠，即在需求分析完成之前就可以进行架构设计和部分详细设计纯瀑布模型强调在任意两个阶段交接时，文档从一个团队交给另一个完全隔离的团队，但是如果一个团队完成各个阶段任务时，可以没有那么多文档文档。问题：缺点是什么？生鱼片模型因为阶段重叠，因而里程碑不明确里程碑不明确，很难有效地进行过程跟踪和控制。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。E.
29、 瀑布模型变种：具有子项目的瀑布瀑布模型变种：具有子项目的瀑布模型模型纯瀑布模型的问题：必须完成全部架构设计后才能进行详细设计，但是，整个系统中有些部分可能有些特殊性，可以有自己的步骤，即将这些部分划分为子项目。问题：该模型有何问题？这种方法的主要风险是相关性相关性无法预料。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。F. 瀑布模型变种：能够降低风险的瀑布瀑布模型变种：能够降低风险的瀑布模型模型纯瀑布模型：要求在开始架构设计前，必须将用户的所有需求都搞清楚，但是实际中是很困难的。可降低风险的瀑布模型是在顶端，即需求分析和架构设计阶段引入螺
30、旋以便降低风险。螺旋中，先开发一个用户界面原型，采用系统情节串联图版（system storyboarding）引导用户提出需求，记录用户与系统的交互操作方式，或者采用其它需求获取方法。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。G.快速原型模型（Rapid Prototype Model）建造/修改 原型用户测试运行原型 听取用 户意见原型范型本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。原型模型原型模型需求分析原型开发最终系统设计原型评价最终系统实现用户反馈本文档所提供的信息仅供参
31、考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。分析定义系统需求生成原型系统设计程序设计编码测试运 行和维护原型化含原型化的软件生存期采用原型模型的软件生存周期本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。原型法的分类原型法的分类原型是项目系统中的一个方面或者多个方面的工作模型。 抛弃型原型：用于试验某些概念，试验完系统将无用处 进化型原型：原型系统不断被开发和被修正，最终它变为一个真正的系统。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。原型法的优点原型法的
32、优点从实践中学习(Learning by doing)改善的沟通改善的用户参与使部分已知的需求清晰化展示描述的一致性和完整性可能可以减少文档减少了维护成本特征约束（利用工具构造原型可以将某些特性落到实处，而非在纸上写的那样容易失误）试验是否能产生期待的结果本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。原型法的缺点原型法的缺点用户有时误解了原型的角色，例如他们可能误解原形应该和真实系统一样可靠缺少项目标准，进化原型法有点像编码修正缺少控制，由于用户可能不断提出新要求，因而原型迭代的周期很难控制额外的花费：研究结果表明构造一个原型可能需要10%
33、额外花费运行效率可能会受影响原型法要求开发者与用户密切接触，有时这是不可能的。例如外包软件。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。从另外的角度看待原型从另外的角度看待原型从中学到什么？学生经常会做一些软件作业，这些作业被称为原型，问题：这些原型和软件系统原型是否相同？但是作为一个原型必须：描述他们希望从中学到的东西，规划原型评价的方法，报告从原型中真正学到的内容。在不同的阶段，原型具有不同的作用。原型起作用的程度实物模型（Mock-ups）仿真交互部分模型：水平，垂直（某些特性构造详细原型）本文档所提供的信息仅供参考之用，不能作为科
34、学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。H.演化模型增量模型(Incremental Model)螺旋模型(Sprial Model)本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。H.1 增量模型(递增模型)先完成一个系统子集的开发，再按同样的开发步骤增加功能 (系统子集),如此递增下去直至满足全部系统需求。系统的总体设计在初始子集设计阶段就应作出设想。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。分析 设计 编码测试 分析 设计 编码测试 分析 设计 编码测试 分析
35、设计 编码测试 增量1增量2增量3增量n 增量1交付客户 增量2交付客户 增量3交付客户 增量n交付客户日历时间.H.1 增量模型本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。风险分析工程实施用户通信用户评估产品维护项目产品增强项目新产品开发项目概念开发项目计划建造及发布H.2 螺旋模型本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。螺旋模型的优缺点优势：随着迭代的增加（成本的增加），风险程度随之降低缺陷：比较复杂，需要责任心，专注和管理方面的知识。本文档所提供的信息仅供参考之用，不能作为
36、科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。H.3 WIN-WIN螺旋模型在螺旋模型中，通过与客户的通信获取客户的需求，实际上，客户的需求与最终确定的需求是不一致的，客户与开发者之间需要进行协商，最终达到双赢的局面。Boehm提出的WIN-WIN螺旋模型中，客户与开发者之间需要识别系统或子系统的关键stakeholders确定涉及者的“win conditions”对这些条件进行协商获得互赢条件本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。WIN-WIN螺旋模型螺旋模型WIN-WIN螺旋模型还引入了三个过程的里程碑，被称为定
37、位点（Anchor points）生命周期目标（life cycle objectives）:定义每个主要活动的目标生命周期体系结构（life cycle architecture）:定义系统和软件的体系结构目标初步操作能力（initial operational capability）:定义软件安装，发布目标。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。I. 并行开发模型并行开发模型（concurrent development model）又被称为并行工程（concurrent engineering）（By Davis and Si
38、taram）软件开发中的所有活动可能同时并存同时并存，但是都处于不同状态中并行开发模型定义了活动从一个状态转化为另一个状态的事件本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。并行开发模型并行开发模型NoneAwaiting changesUnder revisionUnder reviewBaselinedDoneUnder developmentAnalysis activity本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。并行开发模型并行开发模型并行过程模型经常被用于开发C/S系统。
39、该系统的活动可以被分为系统维和部件维。系统维:包含设计，装配和使用三个活动部件维:包含设计和实现两个活动并发性表现在两个方面： 系统和部件的活动同时发生 各个部件可以并行设计和开发本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。“基于版本发布”的特点V1.01.0功功能能时间时间V2.02.0V1.11.1本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。Trade-off Decision (折中决定) 可可 靠靠 性性 发布日期发布日期 功功 能能 最优最优 约束范围约束范围可接受可接受正
40、确的正确的Trade-off 决定决定本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。J. 面向对象模型喷泉模型(Fountain Model)可重用部件组装模型 (构件集成模型 Component Integration Model)本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。分析分析设计设计实现实现测试测试集成集成演化演化J.1 喷泉模型本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。喷泉模型特点 主要用于支持面向对象开发过程体现了
41、软件创建所固有的迭代和无间隙的特征本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。J.2 可重用部件组装模型(构件集成模型)使用重用技术的软件工程模型构件(components)：可重用的软件成份可复用性（Reusability）集成化软件开发环境（ISEE）本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。用户通信计划产品开发及发布用户评估风险分析标志候选构件查找构件若存在则提取构件若不存在则构造构件进行下一次迭代将新构件存入库中可重用部件组装模型本文档所提供的信息仅供参考之用，不能作为科学
42、依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。基于构件的软件工程(CBSE)过程模型 构 件 开 发分析 设计 编程 测试领域分析系统测试构件提交领域专家经验现有系统资料领域构件需求构件/构架库领域构架领域构件系统开发系统专用构件应用系统构件生产线领域构架领域构件问题域用户需求系统生产线 系 统 组 装 分析 设计 编程构架细化专 用 构 件 开 发分析 设计 编程 测试本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。 软件生产线应用构件提取车间构件生产车间标准规范 与 质量保证1基础构件，2功能构件 3接口构件，4用户界面构件 应
43、用构件库 构件库组装车间领域 1领域 2应用系统 . .1 12 23 34 4本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。 转换模型(Transformational Model) 净室模型(Cleanroom Model)K.形式化方法模型本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。K.1 转换模型形式化规格说明与需求比较后修正形式化开发记录变换n变换2变换1测试系统需求目标系统本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。形
44、式化规格语言及其变换技术基于模型的规格说明及其变换技术基于代数结构及其变换技术基于时序逻辑的规格说明和验证技术基于可视形式化技术本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。K.2 净室模型(形式化的增量开发模型)基于思想： 力求在分析和设计阶段就消除错误，确保正确，然后在无缺陷或“洁净”的状态下实现软件的制作。三个关键技术 置于统计过程控制之下的增量开发 基于函数的规范、设计、验证 统计测试和软件认证本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。 净室模型盒结构盒结构规约规约需求需求收
45、集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计划测试计划统计性统计性使用测使用测试试验证验证增量 #1盒结构盒结构规约规约需求需求收集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计划测试计划统计性统计性使用测使用测试试验证验证增量 #2盒结构盒结构规约规约需求需求收集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计划测试计划统计性统计性使用测使用测试试验证验证增量 #1. . . . . . . . . . . . .本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。L. 阶段交付阶段
46、交付阶段交付持续地在确定的阶段向用户展示软件。和渐进原型不同，在阶段交付的时候，你明确地知道下一步要完成什么工作。阶段交付的特点是不会在项目结束的时候一下交付全部软件，而是在项目整个开发过程中持续不断地交付阶段性成果。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。阶段交付阶段交付软件概念需求分析构架设计阶段1：详细设计，编码，调试，阶段2：详细设计，编码，调试，本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。阶段交付的优缺点阶段交付的优缺点优点：项目结束交付全部成果前，分阶段将有用的功能交
47、付给用户。缺点：如果管理层面和技术层面上缺乏仔细规划，工作就无法进行。使用阶段交付的注意点： 必须确定每一阶段的交付是对用户有用的 必须确保考虑了不同产品组成部分的技术依赖关系本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。M. 面向进度的设计面向进度的设计类似于阶段交付，但是面向进度的设计生命周期模型在开始的时候不必知道究竟能达到何目标，但是要确保最后的期限期限。该模型的关键是要按优先级别划分系统特按优先级别划分系统特性并规划开发阶段性并规划开发阶段，保证前面的阶段具有高优先级的特性，低特性具有低优先级别。是否采用这种方法决定于你是否对系统
48、目标具有足够的信心，如果有信心，则没必要采用这种方法。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。N.渐进交付渐进交付渐进交付是一种跨越了渐进原型和阶段交付两种模型的过程模型。基本过程：开发一个产品的版本，展示给用户，根据反馈改善产品。如果计划满足用户的绝大部分需求，渐进交付与渐进原型差不多，如果计划满足少量的需求，渐进交付就和阶段交付差不多。渐进原型，强调的是系统看得见的样子，再回来堵漏洞，渐进交付中，最初的重点是系统核心和底层系统功能。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。
49、渐进交付渐进交付软件概念需求分析构架和内核设计开发一个版本并入用户反馈交付该版本开发一个版本交付最终版本本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。确定渐进交付目标的一种方法确定渐进交付目标的一种方法价值成本比本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。软件开发方法 软件开发过程遵循的方法和步骤 几种典型的开发方法： 模块化方法（modular method） 结构化方法 面向数据结构方法 面向对象方法本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联
50、系本人或网站删除。软件开发需要项目管理软件开发需要项目管理软件开发是个系统工程需要资源的协调软件开发过程的选择与项目的协调紧密相关项目管理、工具、技术、流程项目管理、工具、技术、流程与组织与组织本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。主要内容主要内容回顾 软件项目实施的方法选择 软件开发过程模型的选择 软件开发方法项目管理 项目管理基本概念 实施项目管理的工具与技术 项目管理的流程 项目管理的流程特征（产品项目软件项目） 项目管理组织结构 软件项目管理的流程本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，
