软件工程案例分析

《软件工程案例分析》由会员分享，可在线阅读，更多相关《软件工程案例分析（450页珍藏版）》请在金锄头文库上搜索。

1、软件工程案例分析软件工程案例分析陈天洲浙江大学计算机学院软件特征（软件特征（1）最根本的：软件是一种逻辑元素而不是物理元素软件是开发出的，而不是用传统的方法制造出来的软件不会被用坏时间失败概率一般产品的浴盆曲线软件特征（软件特征（2）时间失败概率软件失败概率实际曲线软件失败概率理想曲线软件特征（软件特征（3）工业界已经走向了标准化装配时代，然而绝大多数软件还是定制出来的。科学计算函数库（60年代）重用数据结构重用组件成本结构发生了巨大的变化成本结构发生了巨大的变化一次性的制造成本介质成本的可忽略性逻辑产品不可回逆的投入维护成本的增加服务是质量要素中的重点软件危机软件危机“软件危机” 是1958

2、年在NATO会议上作为一个正式的议题被提出来 软件项目不成功的例子比比即是：1999 年 10 月，耗资 1.25 亿美元的 NASA 的火星气象卫星失踪（公英制转换）软件危机软件危机一些数据：大约70的软件开发项目超出了估算的时间，大型项目平均超出计划交付时间20到50，90以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高美国政府审计局：只有不到2的合同定购软件在发布时具有可用性98以上的项目都失败了软件危机软件危机一种看法“两难境地（Crunch Mode）”：处于两难境地的项目面临无法达到最初目标的威胁（费用、进度表、功能性等），而项目团队努力想跨越困境。“我们正处于

3、两难境地，在半夜之前是不会回家”“死亡行军（Death March）”：用来描述其进度表几乎不可能完成的项目。“这是一个死亡行军项目，我希望自己不要参与进去”软件危机软件危机更准确的说法：慢性痛苦（chronicaffliction)SuggestedbyProf.DanielTiechrow,UniversityofMichigan尽管忍受痛苦，但是软件依然在我们这个世界起着越来越重要的作用，但是如果能够医治痛苦，那么软件业将发展得更加健康。软件危机的主要特征软件危机的主要特征软件开发周期大大超过规定日期;软件开发成本严重超标;软件质量难于保证软件成功的标准软件成功的标准s用户在用s用户可很

4、容易做完要做的事失败的根本原因：开发人员写出的东西达不到用户要求(人的问题.技术问题)规模复杂性生产率软件技术面临的问题软件技术面临的问题Exchange2000Windows20002000项目经理项目经理25人人约约250人人开发人员开发人员140人人约约1700人人测试人员测试人员350人人约约3200人人例例:Windows95有有1000万行代码万行代码 Windows2000有有5000万行代码，万行代码， 3000多个工程师，几百个小团队。多个工程师，几百个小团队。Exchange2000和和 Windows2000开发人员结构开发人员结构“软件工程案例分析”课程与其它软件专业课

5、的区别(1) 立足于系统的整体。(2) 系统分析、系统设计、 测试及维护的方法实践。(3) 构筑一个软件系统，实践 软件开发全过程。用户分析员程序员系统分析员的地位“一个好的工业，应有一套良好的标准来配套”软件工业化生产过程应具备的特点明确的工作步骤详细具体的规范化文档明确的质量评价标准软件产品的标准化软件产品的标准化软件开发过程的标准化软件开发过程的标准化软件工程技术的两个明显特点 强调规范化 强调文档化新世纪软件产业的趋势新世纪软件产业的趋势网络化趋势：计算机与通信的融合趋势 万维网智能网络服务化趋势：“打包式”软件 “服务式”软件全球化趋势中国软件产业发展主要问题中国软件产业发展主要问题

6、产业规模小、集中度低产业竞争力弱，缺乏核心技术市场秩序较为混乱，盗版严重制约软件产业发展的因素制约软件产业发展的因素软件开发规范与标准知识产权环境知识结构公司体制项目与项目管理项目与项目管理项目是什么没有例行的任务需要计划特定的目标需要满足或者特定的产品需要生成项目有一个预定义的时间范围工作不仅仅是为自己，也是为他人工作中有些特性工作分为若干阶段项目完成需要资源项目是大型的或者复杂的项目管理是什么项目管理是在项目活动中应用知识，技能，工具和技术来满足项目需求的过程，它通过初始化，计划，执行，控制和结束等活动来完成。软件项目与软件项目与软件项目管理软件项目管理软件项目的特征不可见复杂性（以每一单

7、位货币来看）灵活性：软件去适应人或组织而不是相反一致性一致性软件项目管理为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。软件项目的活动软件项目的活动需求分析描述设计编码校验安装维护支持软件项目分类软件项目分类按软件类别信息系统：与组织接口嵌入式系统：接口是机器操作系统是一个信息系统还是嵌入式系统？ 有些项目是为了生成某一产品，而某些项目的进行是为了达到某些目标。许多软件项目分为两个阶段，第一阶段是目标驱动，第二阶段再生成真正的软件产品。从从系统的角度看软件项目系统的角度看软件项目一个项目关注于生成一个系统和/或将一个旧系统转换为一个

8、新系统系统，子系统和环境开放和封闭系统项目失败的一个原因是技术人员不能够开放系统和立即接受外界的变化。部分优化例如：可能很高效，但是难于修改社会技术系统软件项目属于此类软件项目中的人员软件项目中的人员项目影响者(stakeholders)项目小组内部：项目小组外部，但是在同一组织内：项目小组和组织外部：如客户不同的项目影响者有不同的目标，因而项目领导者需要能够协调这些目标。Boehm和Ross提出软件项目管理的“W理论”，该理论关注于所有各方都能从项目种获益因而对项目的成功都有兴趣。（W代表Everyone a Winner）软件开发面临的挑战软件开发面临的挑战处理最终日期（deadlines

9、）(85%)处理资源约束（83）与任务小组有效的沟通（80）从小组成员处得到承诺（74）建立可测量的milestone（90）处理变化（60）得到团队公认的项目计划（57）从管理层得到承诺（45）处理冲突（42）管理销售商和子项目承包商（38）项目经理面临的挑战项目经理面临的挑战估计和计划缺少质量标准和度量缺少组织决策的指南缺少使进度可视化的技术角色定义不正确的成功准则缺少标准项目成员面临的挑战项目成员面临的挑战工作的不正确的描述IT的管理失误缺少应用领域的知识缺少及时的文档前续任务没有及时完成包括设备没及时提供用户与技术员之间缺乏交流缺少质量控制软件环境的改变Deadline压力软件项目常见

10、错误软件项目常见错误选自快速软件开发产品相关的错误需求镀金：项目具有比实际需求多得多的性能功能蔓延：项目平均会有25%的需求变更（Jones 1994）开发人员的镀金：开发人员着迷于新技术又推又拉的交易：经理在批准项目进度顺延时又加入了新的功能研究导向的开发软件项目常见错误（续）软件项目常见错误（续）过程中的错误缺乏计划过于乐观的计划在压力下放弃计划缺乏足够的风险管理承包人导致的失败在模糊的项目前期浪费时间前期活动不合要求过程中的错误设计低劣缺少质量保证措施缺少管理控制太早和过于频繁的集成项目估算时遗漏必要的任务追赶计划鲁莽编码软件项目常见错误（续）软件项目常见错误（续）技术相关的错误银弹综合

11、症: 过于相信以前没有采用过的技术的宣传过高估计了新技术或方法带来的节省量项目中间切换工具缺少自动的源代码控制手段 软件项目常见错误（续）软件项目常见错误（续）人员相关的错误挫伤积极性人员素质低对有问题的员工失控英雄主义项目后期加入人员：“火上加油”办公环境差开发人员与客户之间发生摩擦不现实的预期软件项目常见错误（续）软件项目常见错误（续）缺乏有效的高层对项目的支持缺乏各种角色的齐心协力缺乏用户介入政治高于物质充满想像：“项目组没人真正相信他们能够按给定的计划进度完成项目，但他们认为如果每个人能够努力工作，并且不出现问题，他们可能会很幸运地按时完成任务。软件项目常见的错误软件项目常见的错误试分

12、析以下故事中的项目所存在的错误：一天，一位年青人被选来“写”一个用在自动化制造设备上的程序。选择他的理由很简单：他是技术小组中唯一参加过编程培训的人。他懂得汇编语言和Fortran语言，但是他不知道软件工程，更不知道软件计划和跟踪方面的知识。软件开发过程模型选择软件开发过程模型选择主要内容主要内容项目实施的方法选择问题识别项目中的高风险软件开发过程模型的选择可选择的模型软件开发项目过程的选择软件开发方法项目实施的方法选择项目实施的方法选择技术选择技术选择将影响：开发人员的训练需要人员招聘开发环境硬件和软件系统维护安排方法选择方法选择将影响：开发人员组合实施的进度安排开发策略选择项目实施的方法选

13、择项目实施的方法选择p步骤：分析目标驱动还是产品驱动分析项目其他特征面向数据还是面向控制通用还是专用是否需要专用工具支持的专门技术是否有特殊的安全性要求对软硬件有何要求识别项目中的高风险识别项目中的高风险产品不确定性：系统需求理解的准确性。用户在开始时有可能对系统应该什么样都无法确定。在某些环境中，精确而有效的需求描述可能迅速变得过时。过程不确定性：在项目开始时需要选择方法或过程模型，或者一种新的工具，任何对原先采用的开发方法的变化都将引入不确定性资源不确定性：项目进行中资源的数量可能发生变化软件开发过程模型的选择软件开发过程模型的选择开发一个软件需要选择开发策略（包括过程，方法和工具）以及通

14、用阶段，这些策略和阶段被称为过程模型“过程”：相关联的活动过程模型的选择基于项目和应用的特性，使用的工具和方法，所需要的控制方法和交付物。软件生存周期(SoftwareLifeCycle)软件产品或软件系统从设计、投入使用到被淘汰的全过程软件生存期的阶段划分可行性研究与计划需求分析总体设计详细设计实现集成测试确认测试使用和维护软件生存周期软件生存周期计算机软件开发规范上游下游新的国际标准定义的软件生存过程（1995 ISO/IEC 12207）软件生存期过程支持过程组织过程主要过程获取过程供应过程开发过程运行过程维护过程文档编制过程配置管理过程质量保证过程验证过程确认过程联合评审过程审核过程问

15、题解决过程管理过程基础设施过程改进过程培训过程只考虑编写程序 涉及整个软件生存周期扩展到软件工作的范围软件开发全部过程、活动和任务的结构框架。直观表达软件开发全过程明确规定要完成的主要活动、任务和开发策略也称为：软件过程模型软件生存周期模型软件工程范型软件开发模型软件开发模型问题求解的一般过程问题求解的一般过程问题求解的一般过程实际问题并不能简单划为四个阶段，各个阶段会在问题的不同层次上同时并存软件开发实际上是一个“混沌”（chaos）过程问题定义方案集成技术开发现状A.编码修正模型编码修正模型CodeandFixCodelikeHell(鲁莽编码)从一个大致的想法开始工作，然后经过非正规的设

16、计、编码、调试和测试方法，最后完成工作可能有可能没有的规范发布（可能）编码修正模型编码修正模型好处：成本可能很低只需要很少的专业知识，任何写过程序的人都可以对于一些非常小的、开发完后就会很快丢弃的软件可以采用对于规模稍大的项目，采用这种模型是很危险的B.瀑布模型（瀑布模型（Waterfall Model)所有过程模型的祖宗项目从开始到结束按照一定的顺序执行瀑布模型是文档驱动的，各个阶段不连续也不交叉B.瀑布模型 (Waterfall Model)可行性研究与计划需求分析设计编码运行维护测试定义阶段开发阶段维护阶段适应场合？适应场合？优缺点？优缺点？瀑布模型的适用场合瀑布模型的适用场合有一个稳定

17、产品定义稳定产品定义和很容易被理解的技术解决容易被理解的技术解决方案方案时，纯瀑布模型特别合适对一个定义得很好的版本进行维护维护或将一个产品移植平台移植平台，瀑布模型也特别合适。纯瀑布模型能够降低管理费用降低管理费用，因为你可以预先完成所有计划。对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适，因为可以用顺序方法处理问题用顺序方法处理问题。在质量需求高质量需求高于成本需求和进度需求的时候，它尤为出色。当开发队伍的技术力量比较弱技术力量比较弱或者缺乏经验时，瀑布模型更为适合。瀑布模型缺点瀑布模型缺点纯瀑布模型在项目开始时，在设计工作完成前和代码写出来前，很难充分描述需求。瀑布模型最主要问题

18、是缺乏灵活性缺乏灵活性。必须在项目开始前说明全部需求。但这恰恰是非常困难的。按照传统瀑布模型开发软件的特点阶段间具有顺序性和依赖性。推迟实现的观点。每个阶段必须完成规定的文档;每个阶段结束前完成文档审查,及早改正错误。C.瀑布模型变种：瀑布模型变种：V型模型型模型该方法是对瀑布模型的修正，强调了验证活动可行性研究用户需求系统设计程序设计编码程序测试系统测试用户接受评价修正修正修正修正D. 瀑布模型变种：生鱼片模型瀑布模型变种：生鱼片模型把阶段重叠起来的瀑布模型起源于日本硬件开发模型（富士通施乐）软件概念需求分析架构设计详细设计编码和调试系统测试生鱼片模型的特点和缺点生鱼片模型的特点和缺点传统的

19、瀑布模型强调阶段之间最小重叠重叠，而生鱼片模型强调大幅度重叠，即在需求分析完成之前就可以进行架构设计和部分详细设计纯瀑布模型强调在任意两个阶段交接时，文档从一个团队交给另一个完全隔离的团队，但是如果一个团队完成各个阶段任务时，可以没有那么多文档文档。问题：缺点是什么？生鱼片模型因为阶段重叠，因而里程碑不明确里程碑不明确，很难有效地进行过程跟踪和控制。E. 瀑布模型变种：具有子项目的瀑布瀑布模型变种：具有子项目的瀑布模型模型纯瀑布模型的问题：必须完成全部架构设计后才能进行详细设计，但是，整个系统中有些部分可能有些特殊性，可以有自己的步骤，即将这些部分划分为子项目。问题：该模型有何问题？这种方法的

20、主要风险是相关性相关性无法预料。F. 瀑布模型变种：能够降低风险的瀑布瀑布模型变种：能够降低风险的瀑布模型模型纯瀑布模型：要求在开始架构设计前，必须将用户的所有需求都搞清楚，但是实际中是很困难的。可降低风险的瀑布模型是在顶端，即需求分析和架构设计阶段引入螺旋以便降低风险。螺旋中，先开发一个用户界面原型，采用系统情节串联图版（system storyboarding）引导用户提出需求，记录用户与系统的交互操作方式，或者采用其它需求获取方法。G.快速原型模型（Rapid Prototype Model）建造/修改 原型用户测试运行原型 听取用 户意见原型范型原型范型原型模型原型模型需求分析原型开发

21、最终系统设计原型评价最终系统实现用户反馈分析定义系统需求生成原型系统设计程序设计编码测试运 行和维护原型化含原型化的软件生存期采用原型模型的软件生存周期原型法的分类原型法的分类原型是项目系统中的一个方面或者多个方面的工作模型。抛弃型原型：用于试验某些概念，试验完系统将无用处进化型原型：原型系统不断被开发和被修正，最终它变为一个真正的系统。原型法的优点原型法的优点从实践中学习(Learning by doing)改善的沟通改善的用户参与使部分已知的需求清晰化展示描述的一致性和完整性可能可以减少文档减少了维护成本特征约束（利用工具构造原型可以将某些特性落到实处，而非在纸上写的那样容易失误）试验是否

22、能产生期待的结果原型法的缺点原型法的缺点用户有时误解了原型的角色，例如他们可能误解原形应该和真实系统一样可靠缺少项目标准，进化原型法有点像编码修正缺少控制，由于用户可能不断提出新要求，因而原型迭代的周期很难控制额外的花费：研究结果表明构造一个原型可能需要10%额外花费运行效率可能会受影响原型法要求开发者与用户密切接触，有时这是不可能的。例如外包软件。从另外的角度看待原型从另外的角度看待原型从中学到什么？学生经常会做一些软件作业，这些作业被称为原型，问题：这些原型和软件系统原型是否相同？但是作为一个原型必须：描述他们希望从中学到的东西，规划原型评价的方法，报告从原型中真正学到的内容。在不同的阶段

23、，原型具有不同的作用。原型起作用的程度实物模型（Mock-ups）仿真交互部分模型：水平，垂直（某些特性构造详细原型）H.演化模型增量模型(IncrementalModel)螺旋模型(SprialModel)H.1 增量模型(递增模型)先完成一个系统子集的开发，再按同样的开发步骤增加功能 (系统子集),如此递增下去直至满足全部系统需求。系统的总体设计在初始子集设计阶段就应作出设想。分析 设计 编码测试 分析 设计 编码测试 分析 设计 编码测试 分析 设计 编码测试 增量增量11增量增量22增量增量33增量增量nn 增量增量11交付交付客户客户 增量增量22交付交付客户客户 增量增量33交付交

24、付客户客户 增量增量nn交付交付客户客户日历时间日历时间.H.1 增量模型风险分析工程实施用户通信用户评估产品维护项目产品维护项目产品增强项目产品增强项目新产品开发项目新产品开发项目概念开发项目概念开发项目计划计划建造及发布建造及发布H.2 螺旋模型螺旋模型的优缺点优势：随着迭代的增加（成本的增加），风险程度随之降低缺陷：比较复杂，需要责任心，专注和管理方面的知识。H.3 WIN-WIN螺旋模型在螺旋模型中，通过与客户的通信获取客户的需求，实际上，客户的需求与最终确定的需求是不一致的，客户与开发者之间需要进行协商，最终达到双赢的局面。Boehm提出的WIN-WIN螺旋模型中，客户与开发者之间需

25、要识别系统或子系统的关键stakeholders确定涉及者的“win conditions”对这些条件进行协商获得互赢条件WIN-WIN螺旋模型螺旋模型WIN-WIN螺旋模型还引入了三个过程的里程碑，被称为定位点（Anchor points）生命周期目标（life cycle objectives）:定义每个主要活动的目标生命周期体系结构（life cycle architecture）:定义系统和软件的体系结构目标初步操作能力（initial operational capability）:定义软件安装，发布目标。I. 并行开发模型并行开发模型（concurrent development

26、model）又被称为并行工程（concurrent engineering）（By Davis and Sitaram）软件开发中的所有活动可能同时并存同时并存，但是都处于不同状态中并行开发模型定义了活动从一个状态转化为另一个状态的事件并行开发模型并行开发模型NoneAwaitingchangesUnderrevisionUnderreviewBaselinedDoneUnderdevelopmentAnalysisactivity并行开发模型并行开发模型并行过程模型经常被用于开发C/S系统。该系统的活动可以被分为系统维和部件维。系统维:包含设计，装配和使用三个活动部件维:包含设计和实现两个活

27、动并发性表现在两个方面：系统和部件的活动同时发生各个部件可以并行设计和开发“基于版本发布”的特点V1.01.0功功能能时间时间时间时间V2.02.0V1.11.1Trade-off Decision (折中决定) 可可 靠靠 性性 发布日期发布日期 功功 能能 最优最优 约束范围约束范围可接受可接受正确的正确的正确的正确的Trade-offTrade-off 决定决定决定决定J. 面向对象模型喷泉模型(FountainModel)可重用部件组装模型(构件集成模型ComponentIntegrationModel)分析分析分析分析设计设计设计设计实现实现实现实现测试测试测试测试集成集成集成集成演

28、化演化演化演化J.1 喷泉模型喷泉模型特点 主要用于支持面向对象开发过程体现了软件创建所固有的迭代和无间隙的特征J.2 可重用部件组装模型(构件集成模型)使用重用技术的软件工程模型构件(components)：可重用的软件成份可复用性（Reusability）集成化软件开发环境（ISEE）用户通信计划产品开发及发布用户评估风险分析标志候选构件查找构件若存在则提取构件若不存在则构造构件进行下一次迭代将新构件存入库中可重用部件组装模型基于构件的软件工程(CBSE)过程模型 构 件 开 发分析 设计 编程 测试领域分析系统测试构件提交领域专家经验现有系统资料领域构件需求构件/构架库领域构架领域构件系

29、统开发系统专用构件应用系统构件生产线领域构架领域构件问题域用户需求系统生产线 系 统 组 装 分析 设计 编程构架细化专 用 构 件 开 发分析 设计 编程 测试 软件生产线应用构件提取车间构件生产车间标准规范 与 质量保证1基础构件，2功能构件 3接口构件，4用户界面构件 应用构件库 构件库组装车间领域 1领域 2应用系统 .1 12 23 34 4 转换模型(TransformationalModel) 净室模型(CleanroomModel)K.形式化方法模型K.1 转换模型形式化规格说明与需求比较后修正形式化开发记录变换n变换2变换1测试系统需求系统需求目标系统目标系统形式化规格语言及

30、其变换技术基于模型的规格说明及其变换技术基于代数结构及其变换技术基于时序逻辑的规格说明和验证技术基于可视形式化技术K.2 净室模型(形式化的增量开发模型)基于思想：力求在分析和设计阶段就消除错误，确保正确，然后在无缺陷或“洁净”的状态下实现软件的制作。三个关键技术置于统计过程控制之下的增量开发基于函数的规范、设计、验证统计测试和软件认证 净室模型盒结构盒结构规约规约需求需求收集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计划测试计划统计性统计性使用测使用测试试验证验证增量 #1盒结构盒结构规约规约需求需求收集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计

31、划测试计划统计性统计性使用测使用测试试验证验证增量 #2盒结构盒结构规约规约需求需求收集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计划测试计划统计性统计性使用测使用测试试验证验证增量 #1. . . . . . . . . . . . . . . . . . . . . . . . .L. 阶段交付阶段交付阶段交付持续地在确定的阶段向用户展示软件。和渐进原型不同，在阶段交付的时候，你明确地知道下一步要完成什么工作。阶段交付的特点是不会在项目结束的时候一下交付全部软件，而是在项目整个开发过程中持续不断地交付阶段性成果。阶段交付阶段交付软件概念需求分析构架设计阶段1：详细设计

32、，编码，调试，阶段2：详细设计，编码，调试，阶段交付的优缺点阶段交付的优缺点优点：项目结束交付全部成果前，分阶段将有用的功能交付给用户。缺点：如果管理层面和技术层面上缺乏仔细规划，工作就无法进行。使用阶段交付的注意点：必须确定每一阶段的交付是对用户有用的必须确保考虑了不同产品组成部分的技术依赖关系M. 面向进度的设计面向进度的设计类似于阶段交付，但是面向进度的设计生命周期模型在开始的时候不必知道究竟能达到何目标，但是要确保最后的期限期限。该模型的关键是要按优先级别划分系统特按优先级别划分系统特性并规划开发阶段性并规划开发阶段，保证前面的阶段具有高优先级的特性，低特性具有低优先级别。是否采用这种

33、方法决定于你是否对系统目标具有足够的信心，如果有信心，则没必要采用这种方法。N.渐进交付渐进交付渐进交付是一种跨越了渐进原型和阶段交付两种模型的过程模型。基本过程：开发一个产品的版本，展示给用户，根据反馈改善产品。如果计划满足用户的绝大部分需求，渐进交付与渐进原型差不多，如果计划满足少量的需求，渐进交付就和阶段交付差不多。渐进原型，强调的是系统看得见的样子，再回来堵漏洞，渐进交付中，最初的重点是系统核心和底层系统功能。渐进交付渐进交付软件概念需求分析构架和内核设计开发一个版本并入用户反馈交付该版本开发一个版本交付最终版本确定渐进交付目标的一种方法确定渐进交付目标的一种方法价值成本比软件开发方法

34、 软件开发过程遵循的方法和步骤 几种典型的开发方法： 模块化方法（modularmethod） 结构化方法 面向数据结构方法 面向对象方法软件开发需要项目管理软件开发需要项目管理软件开发是个系统工程需要资源的协调软件开发过程的选择与项目的协调紧密相关项目管理、工具、技术、流程项目管理、工具、技术、流程与组织与组织主要内容主要内容回顾软件项目实施的方法选择软件开发过程模型的选择软件开发方法项目管理项目管理基本概念实施项目管理的工具与技术项目管理的流程项目管理的流程特征（产品项目软件项目）项目管理组织结构软件项目管理的流程建立不现实的最终期限建立不现实的最终期限不断变更的客户需求不断变更的客户需求

35、对努力的低估对努力的低估可预见和不可预见的风险可预见和不可预见的风险技术的困难性技术的困难性项目成员的沟通不畅通项目成员的沟通不畅通项目管理不利项目管理不利为什么项目会失败为什么项目会失败?People项目成功的最重要因素Product建立的软件Process框架活动集合和得到工作的软件工程任务Project实现产品所需要的所有工作The 4 Ps软件梯队软件梯队被解决问题的难易程度代码和功能点形成的结果程序的规模梯队的生存周期问题被模块化的程度被建立系统所需要的质量和可靠性发布日期的严格性项目的社会化程度（沟通程度）选择软件项目梯队结构所要考虑的因素选择软件项目梯队结构所要考虑的因素 .建立

36、范围陈述性描述，约束问题表达分解建立功能性分割问题定义问题定义发现项目的关键发现项目的关键系统为什么被开发?做什么?什么时候?谁对某一功能负责?他们组织定位在哪里?从技术和管理上工作怎样被做?多少资源需要(e.g.,人,软件,工具,数据库)?Barry Boehm形式的风险分析经验成本和进度估算基于度量的项目管理价值跟踪（Earnedvaluetracking）质量目标下的跟踪人要意识到项目管理关键实践关键实践什么是项目什么是项目项目是什么没有例行的任务需要计划特定的目标需要满足或者特定的产品需要生成项目有一个预定义的时间范围工作不仅仅是为自己，也是为他人工作中有些特性工作分为若干阶段项目完成

37、需要资源项目是大型的或者复杂的什么是项目管理什么是项目管理项目管理是在项目活动中应用知识，技能，工具和技术来满足项目需求的过程，它通过初始化，计划，执行，控制和结束等活动来完成。 项目生命周期项目生命周期项目生命周期定义一个项目的开始与结束。项目生命周期定义的阶段顺序通常包括某些技术转移或“握手”(hand off)，如从需求到设计，从构造到运行，但是在风险允许下，也可以下一阶段提前进行，这种重叠的阶段被称为快速跟踪(fast tracking)。项目生命周期通常定义：各个阶段需要完成的技术工作；每个阶段需要涉及的人。项目生命周期项目生命周期绝大多数项目生命周期有一些共同的特点，如成本和人员消

38、耗的变化曲线。项目生命周期与产品生命周期是不同的。项目中的人员项目中的人员项目影响者(stakeholders)项目小组内部：项目小组外部，但是在同一组织内：项目小组和组织外部：如客户不同的项目影响者有不同的目标，因而项目领导者需要能够协调这些目标。Boehm和Ross提出软件项目管理的“W理论”，该理论关注于所有各方都能从项目种获益因而对项目的成功都有兴趣。（W代表Everyone a Winner）软件项目管理定义软件项目管理定义软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。软件项目包含的活动软件项目包含的活动需

39、求分析描述设计编码校验安装维护支持应用项目管理方法开展软件开发应用项目管理方法开展软件开发项目的可行性分析需求开发与需求管理软件项目工作量估算软件项目计划与资源分配软件项目监控风险管理软件质量管理与软件开发规范软件项目中的人员管理软件配置管理项目可行性分析与评估项目可行性分析与评估内容安排内容安排可行性分析的内容项目范围管理技术评估经济评估风险评估可行性报告项目建议书需求建议书可行性分析可行性分析目的“说明该软件开发项目的实现在技术上、经济上和社会条件上的可行说明该软件开发项目的实现在技术上、经济上和社会条件上的可行性；评述为合理地达到开发目标可能选择的各种方案性；评述为合理地达到开发目标可能

40、选择的各种方案”。GPS监控系统的投资失误做什么？近期目标？人员配备，怎样整合需求调研问题开发费用问题风险规避顶新国际集团：在投资新产品时1400万：全国28个城镇居民消费习惯调查700 万：委托28个城镇社会科学院进行全国七大区域总体经济投资环境的分析 任务任务了解客户要求及现实环境，从技术、经济和社会因素研究并论证软件项目可了解客户要求及现实环境，从技术、经济和社会因素研究并论证软件项目可行性，编写可行性报告，制定初步项目开发计划行性，编写可行性报告，制定初步项目开发计划“什么都不做”永远是一个可考虑的方案可行性分析的内容可行性分析的内容项目范围策略评估技术评估经济评估风险评估项目范围管理

41、内容项目范围管理内容保证项目包括并且仅仅包括需要包括的内容。它由以下步骤组成：初始化：对项目或阶段授权范围计划：开发一个作为将来项目决策基础的书面的范围声明范围定义：将项目交付物细分为更小的，更易管理的元件范围校验：形式化项目范围的接受条件范围变更控制：控制项目范围的变更范围的含义范围的含义“范围”包含产品范围和项目范围产品范围：产品或服务的特点和功能项目范围：为了生产具有特定特点和功能的产品所需要的工作软件范围软件范围软件项目计划的第一项任务就是确定软件的工作范围，即软件的用途及对软件的要求。因此，应从管理角度和技术角度出发，确定明确的可理解的软件项目范围。软件范围的叙述软件范围的叙述明确给

42、出定量的数据（例如，同时使用该软件的用户数目，发送表格的长短，最大允许响应时间等）指明约束条件和/或限制（例如，产品成本限制了存储的容量）叙述某些质量因素（例如，给出的算法是否容易理解、是否使用Ada语言等）软件范围的估计软件范围的估计软件范围包括功能、性能、限制、接口和可靠性。功能：软件功能评价，并进行适当细化功能分解，满足未来成本和进度估算要求性能包括处理和响应时间的需求。约束条件：外部硬件、可用存储或其他现有系统对软件限制。功能、性能和约束必须在一起进行评价。当性能限制不同时，为实现同样的功能，开发工作量可能相差一个数量级。如果功能保持相同而性能可变，则开发软件所需的工作量和成本将有显著

43、的差异。价值驱动的电子商务分析方法价值驱动的电子商务分析方法业务流程模型业务概念模型策略规划级结构级实施级电子商务技术层业务策略的概念结构概念建模协商建模价值驱动流程建模资源价值配置伙伴网络价值链构架信息策略发布渠道客户信任客户关系企业能力价值建议目标客户产品与服务创新Revenue Model价值结构收入模型收益/损失资产、财务电子商务概念模型电子商务概念模型初始化初始化初始化(Initiation) 正式授权一个新项目或者决定一个已有项目继续进行下一阶段项目是由于下面一些原因产生的：市场需要（新性能汽车）业务需要（培训中心新课程设计）客户需要（客户定制产品）技术进步（如计算机技术进步）法规

44、需要（污染处理）社会需要（政府水处理系统）初始化初始化输入：产品描述策略计划：企业的战略计划项目选择准则（经济回报，市场回报，公共形象）历史信息：以前项目的结果和性能工具和技术项目选择方法专家判断输出：项目章程（授权项目的正式文档，包括业务需求，产品描述）项目经理指派约束假设范围计划范围计划范围计划是将生成产品的项目工作（项目范围）逐步细化的过程。输入：产品描述项目章程约束假设工具和技术产品分析利益成本分析(Benefit/Cost Analysis)备选方案（brainstorming or lateral thinking)专家判断范围计划范围计划输出范围声明（Scope Statemen

45、t)，包括项目理由：Project Justification(Business need)项目产品:概述项目交付物：project deliverables项目目标: 判断项目是否成功的定量准则支持细节（包括假设和约束）范围管理计划范围定义范围定义范围定义涉及到将主要的项目交付物细分以：提高成本，周期和资源估计的准确性定义性能度量和控制的基线便于清晰定义责任分配范围定义正确与否将影响项目的节奏，进度，生产率和项目人员的士气。范围定义范围定义输入范围声明约束假设其它计划输出历史信息工具和技术WBS(Work breakdown structure)模板分解技术策略评估中的模块管理策略评估中的模

46、块管理模块管理（Programm management)“模块是一组协调管理的项目，通过将项目组成模块，将获得比单个管理项目更大的效益。”D. C. Ferns有效的模块管理需要有一个模块目标，项目必须根据模块目标来选择在大的组织中，将可能有模块管理的机构，例如模块主管或者模块经理即使没有专门的组织来管理模块，项目的选择也需要根据组织的整个业务目标来评价策略评估的内容策略评估的内容目标：提出的系统对组织目标具有怎样的贡献？例如它是否能够增加市场份额？IS计划：提出的系统如何与IS计划相适应？它将替换或者与那些系统接口？它与将来开发的系统有何交互关系？组织结构：新系统对目前的部门和组织结构有何影

47、响？例如一个新的订单处理系统是否与目前的销售与库存控制的功能相重叠？MIS:系统将在组织的何层次上提供何种信息？它将以何种方式对现存管理信息系统进行补充何提高？人员：系统将以何种方式影响人力水平何现存雇员的技术？它对组织整个人员开发策略有何影响？情形：系统将使客户对组织的态度有何变化？是否采用一个自动化的系统将与提供友好的服务相冲突？策略评估中的业务管理策略评估中的业务管理业务管理选定的项目将成为业务的一部分，项目将对资源产生竞争竞争中对业务的调整是必要的技术评估技术评估技术的成熟程度实验室技术经过中试的技术已经工业化应用的技术市场需求显在潜在：转化为显在的条件竞争态势：与竞争技术相比，所采用

48、技术的优势及缺陷技术转换成本支撑体系与条件：原料、销售网络、用户体系、政策技术发展趋势及所采用技术的发展前景技术方案选择技术方案选择要考虑的制约条件需求制约：现存的需求结构及需求结构可能的变化资源制约：资金、人力资源、自然资源、其它要素环境制约：经济技术环境、社会文化环境、自然环境选择原则经济性原则：以最小的投入取得最好的效果发展原则：发展的前景及适应发展的能力兼容性原则：与原有经济、技术、环境、社会的兼容性相关效果原则：相关的经济、技术、环境、社会效果选择视角技术先进性技术适用性经济分析经济分析开发所需要的成本和系统运行所需要的成本与得到的效益的比较识别出项目进行中所需要的所有成本和效益并对

49、其进行聚集将成本和效益用单元来表达成本分为开发成本安装成本运行成本经济分析经济分析效益直接效益可见的间接效益不可见的效益经济分析经济分析净收益（Net Profit):项目的净收益是在项目生命周期内总的收入与总的成本的差。没有考虑时间因素回收期限（Payback Period）：将初始投资收回的期限忽略了整个项目的盈利空间经济分析经济分析投资回报(Return on investment):也被称为回报率(accounting rate of return)(ARR)ROI=（平均年收益/总投资）100例如项目1：ROI=10,000/100,000*100=10%缺点：没有考虑时间因素该回报

50、率易与银行利率混淆经济分析经济分析净现率(Net Present Value)考虑了时间因素对将来的收益打一个折扣“拿在手里的钱才是真正的钱”如果假定年折扣率为10，那么明年的100元等于现在手中的91元，后年的100元等于现在的83元目前值t年的值/(1+r)t系统开发和每年运行费用举例1.系统开发费用（一次）人员：.2名系统分析员(450小时/名,45美元/小时) $40,500.5名系统开发人员(275小时/名,36美元/小时) $49,500.1名数据通讯专家(60小时/名,42美元/小时) $2,400.1名数据库管理员(30小时/名,42美元/小时) $1,260.2名技术写作者(

51、120小时/名,25美元/小时) $6,000.1名秘书(160小时/名,15美元/小时) $2,400.2名在转换期间数据输入人员 $49,500 (40小时/名,12美元/小时)系统开发和每年运行费用举例培训：l三天的开发人员内部培训课程 $7,000l30个用户，三天的内部培训课程 $10,000物资：l复印 $500l磁盘、纸张等消耗品 $650系统开发和每年运行费用举例购买硬件、软件：l20台工作站Windows软件 $1,000l20台工作站内存升级 $8,000l网络软件 $17,500l20台工作站办公软件产品 $20,000系统开发总费用 $161,670系统开发和每年运行费

52、用举例2.2.年运行费用（每年）年运行费用（每年）人员：人员：l维护程序员/分析员(250小时/年,42美元/小时) $10,500l网络管理员(300小时/年,50美元/小时) $15,000购买硬件、软件升级：l硬件 $5,000l软件 $6,000物资和杂项 $3,500每年总运行费用 $40,000可行性研究的步骤 (1)复查确认系统目标、规模 (2)研究正使用系统工作流程 (3)导出新系统高层逻辑模型 (4)重新定义问题 (5)导出和评价供选择的方案 (6)推荐可行的方案 (7)草拟开发计划 (8)编写可行性研究报告，送审可行性分析可行性分析可行性分析报告的格式可行性研究报告的编写提

53、示GB 8567-88 计算机软件产品开发文件编制指南 1 引言 1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料可行性研究报告的编写提示2 可行性研究的前提 2.1 要求 2.2 目标 2.3 条件、假定和限制 2.4 进行可行性研究的方法 2.5 评价尺度可行性研究报告的编写提示可行性研究报告的编写提示3 对现有系统的分析 3.1 数据流程和处理流程 3.2 工作负荷 3.3 费用开支 3.4 人员 3.5 设备 3.6 局限性可行性研究报告的编写提示4 所建议的系统 4.1 对所建议系统的说明 4.2 数据流程和处理流程 4.3 改进之处 4.4 影响 4.5 局限性 4.

54、6 技术条件方面的可行性可行性研究报告的编写提示5 可选择的其它系统方案 5.1 可选择的其它系统1 5.2 可选择的其它系统2 .可行性研究报告的编写提示可行性研究报告的编写提示6 投资及收益分析 6.1 支出 6.2 收益 6.3 收益/投资比 6.4 投资回收周期 6.5 敏感性分析可行性研究报告的编写提示7 社会条件方面的可行性 7.1 法律方面的可行性 7.2 使用方面的可行性项目建议书项目建议书起源：组织内部认识到需要利用信息技术改进目前的业务运行改进目前的信息系统开发新的产品目的：使管理层能够作出项目决策准备招标书准备招标书目的：从客户的角度全面地、详细的论述，为了达成确定的需求

55、应需要作何准备一份招标书应当是全面的，能提供足够详细的信息，以使承约商或项目团队能针对顾客的需要相应地准备一份最优的招标书招标书招标书招标书中需要提供工作表述招标书中必须包括客户要求，此要求中规定了规格和特征招标书应当说明客户期望承约商或项目团队提供什么样的交付物招标书中应当列举客户供应条款招标书中可以表述出客户对需要的确认招标书中可以提到客户想要用的合同类型招标书招标书表述出客户想用的付款方式表述出项目完成所需的进度计划提供有关承约商申请书的格式和内容安排支持客户希望潜在承约商提交申请书的最后期限可能包括评价标准可能会指出客户所拥有的可用于此项目的资金量。案例分析案例分析宁波市第五次全国人口

56、普查办公室的宁波市人口地理信息系统地理空间分析、人口统计与分析一体化宁波人口普查、日常管理、统计与分析的数字化、可视化人口信息存储、管理与分析，建立规范化的空间地理信息与人口信息统一管理、分析、统计、发布、录入、更新与维护对空间数据和人口数据的快速采集、建库、维护、查询、管理、显示、输出、统计分析、共享与发布功能案例分析案例分析性能要求满足宁波全部市县人口的数据存储不同县区都可以调用数据，操作数据保证调查高峰操作响应的人机交互保证数据统计的响应时间案例分析案例分析限制要求Windows平台客户端服务器选用Intel服务器存储RAID，保证存储安全与DOMINO办公系统可以实现接口，可以抽取数据

57、报表需求开发与需求管理需求开发与需求管理主要内容主要内容从一个故事看软件开发的实际问题需求管理的困难性管理需求的目的软件需求特性需求工程如何获取需求需求规格说明需求管理工具软件开发面临的实际问题软件开发面临的实际问题软件开发面临的实际问题软件开发面临的实际问题软件开发面临的实际问题软件开发面临的实际问题为什么？为什么？需求？什么是需求什么是需求需求为用户解决问题或达到目标所需的条件或权能系统或系统部件要满足合同、标准、规范和其它正式规定文档所需具有的条件或权能一种反映上述条件或权能的文档说明举例举例系统必须提供基于PPPoE协议的用户接入模式产品应当提供机架式安装，并提供两个千兆以太网端口系统

58、使用的用户是信息中心和网络管理员系统在运行时必须提供自动数据备份功能简要的解释简要的解释需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整文档，该文档详细地说明了产品“必须或应当”做什么。 如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。需求管理的困难性需求管理的困难性需求不总是显而易见的，而且它可来自各个方面。 需求并不总是能容易用文字明白无误地表达。 存在不同种类的需求，其详细程度各不相同。 如果不加以控制，需求的数量将难以管理。 需求之间相互关联，而且需求也和软件工程流程中的其他可交付工件有关。 需求有唯一的特征或特征值。例如，它们的重要性和容

59、易满足的程度都各不相同。 需求涉及众多相关方面，这意味着需求要由功能交叉的各组人员管理。 需求会变更。为什么要管理需求为什么要管理需求？避免失败就是一个很充分的理由。提高项目的成功率需求管理带来其他好处Standish Group 的 CHAOS 报告进一步证实了与成功项目关系最大的因素是良好的需求管理。什么是软件需求什么是软件需求从软件开发过程看软件需求开发从软件发展周期看软件开发过程从软件发展周期看软件开发过程时期年代阶段涉及注重主要使用语言标准模型初期50-60程序设计点编程技巧ALGOLFORTRANCOBOLBASIC中期70-80软件开发线结构化模块化PASCALGB8566软件开

60、发规范瀑布原型现代90-软件过程面过程能力C,C+JAVAVB、VCISO/IEC12207软件生存期过程ISO9000螺旋CMM计算机系统人员硬件软件数据传输机构执行机构（剧作家、导演）（舞台剧本演员道具）软件开发全过程软件开发全过程活动任务系统需求分析系统结构设计软件需求分析建立软件需求评价软件需求联合评审软件结构设计软件详细设计软件编码和测试软件集成软件鉴定测试系统集成系统鉴定测试软件安装软件验收支持软件开发过程软件开发过程定义（IEEE-STD-610）用户为解决某个问题、或为实现某一目标，要求软件必须满足的条件或能力。软件需求的三个层次业务需求用户需求功能需求和非功能需求软件需求的层

61、次性软件需求的层次性软件系统需求(1)系统需求分配软件工程组硬件系统需求(2)其它成分系统需求(n)软件需求客户最终用户系统工程组系统需求分配系统需求分配业务需求业务说明使用实例用户需求功能需求约束条件非功能需求软件需求规格说明软件需求的层次软件需求的层次需求的层次性需求的层次性业务需求项目视图与范围文档用户需求质量属性系统需求功能需求约束条件其它非功能需求Use Case文档软件需求规格说明非功能需求过程需求：交付需求，实现需求，遵循的标准性能需求：速度，容量，可靠性外部需求：互操作性，伦理性， 机密性，安全性，使用要求非功能非功能软件需求软件需求系统需求ACCS应能使汽车保持在预期车速的2

62、KMH范围内行驶分配给硬件的需求硬件应能使车速在规定的精确度1.5KMH范围内分配给软件的需求软件应能在车速超出预期车速0.5KMH时给硬件加/减速命令软件需求软件应能：读入当前车速值计算当前车速与预期车速之差若差值0.5KMH给出加/减速命令汽车限速系统ACCS的需求分配分配需求的实例分配需求的实例产生不合格需求的原因产生不合格需求的原因产生不合格的需求说明的原因无足够的用户参与，原因感到与用户合作不如编写代码有意思因为开发人员觉得已经明白用户的需求了用户需求的不断增加模棱两可的需求不必要的特性过于精简的规格说明忽略了用户分类不准确的计划优秀需求具有的特性优秀需求具有的特性正确性无二义性必要

63、性完整性，完备性可行性，可实现性可验证性划分优先级制定目标的原则制定目标的原则SMARTSpecial,Measure,Agree,Realistic,Time特指,可量测,一致认同感,现实的,实在的,时间需求工程需求工程什么是需求工程把所有与需求直接相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。 需求工程的结构图1需求工程需求开发需求管理获取需求分析需求定义需求验证需求需求变更控制需求跟踪需求状态跟踪需求文档版本控制需求开发需求管理需求工程需求工程的构成需求工程的构成需求开发过程需求开发过程需求开发：通过调查与分析，获取用户需求并定义产品需求。

64、 需求调查：通过各种途径获取用户需求信息（原始材料），产生用户需求说明书。 需求分析：对各种需求信息进行分析，消除错误，刻画细节。常见分析方法“问答分析法”和“建模分析法”两类。 需求定义：根据需求调查和需求分析结果，进一步定义准确无误的产品需求，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计工作。 需求管理过程需求管理过程需求管理：在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。 需求确认：开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 需求跟踪：通过比较需求文档与后续工作

65、成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。 需求变更控制：依据“变更申请审批更改重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。用户/系统市场管理者初始需求变更的需求获取,分析,定义,验证需求控制需求变更需求规格说明项目环境需求开发需求管理（1）获取需求确定目标用户、服务对象明确用户代表用户培训了解实际业务和业务需求（2）分析需求分清功能需求、性能需求、使用需求必要性可行性需求开发需求开发（3）定义需求编写软件需求规格说明（SRS）作用要求：完整、正确、可行、无歧意、可验证形式：图、表、文字（4）验证需求联合评审需求开发需求开发需求获

66、取需求获取需求的来源与有潜力用户探讨目前或竞争产品的描述文档系统需求规格说明当前系统问题报告和增强要求市场调查和用户问卷调查观察正在工作的用户用户任务内容分析3.2.2 需求获取的内容 1.1.用户需求分类用户需求分类 (1)(1)功能性需求功能性需求: : 定义了系统做什么（描述系统必须支持定义了系统做什么（描述系统必须支持 的功能和过程）的功能和过程） (2)(2)非功能性需求（技术需求）非功能性需求（技术需求）: : 定义了系统工作时的特性定义了系统工作时的特性 （描述操作环境和性能目标）（描述操作环境和性能目标）2. 两类需求包括的内容(1) (1) 功能功能(2) (2) 性能性能(

67、3) (3) 环境环境(4) (4) 界面界面(5) (5) 用户或人的因素用户或人的因素(6) (6) 文档文档 (7) (7) 数据数据(8) (8) 资源资源(9) (9) 安全保密安全保密(10)(10)软件成本消耗与开发进度软件成本消耗与开发进度(11)(11)质量保证质量保证(1) 功能需求 系统做什么？系统做什么？ 系统何时做什么？系统何时做什么？ 系统何时及如何修改系统何时及如何修改 或升级？或升级？(2) 性能需求 软件开发的技术性指标软件开发的技术性指标例如：例如： 存储容量限制存储容量限制 执行速度、相应时间执行速度、相应时间 吞吐量吞吐量(3) 环境需求 硬件设备：硬件

68、设备：机型、外设、接口、机型、外设、接口、 地点、分布、温度、地点、分布、温度、 湿度、磁场干扰等湿度、磁场干扰等软件：软件： 操作系统操作系统 网络网络 数据库数据库(4) 界面需求 有来自其它系统的输入吗？有来自其它系统的输入吗？ 到自其它系统的输出吗？到自其它系统的输出吗？ 对数据格式有规定吗？对数据格式有规定吗？ 对数据存储介质有规定吗？对数据存储介质有规定吗？(5) 用户或人的因素 用户类型？用户类型？ 各种用户熟练程度？各种用户熟练程度？ 需受何种训练？需受何种训练？ 用户理解、使用系统的难度？用户理解、使用系统的难度？ 用户错误操作系统的可能性？用户错误操作系统的可能性？(6)

69、文档需求 需哪些文档？需哪些文档？ 文档针对哪些读者文档针对哪些读者？(7) 数据需求 输入、输出数据的格式？接收、发送数据的频率？数据的准确性和精度？数据流量？数据需保持的时间？(8) 资源需求 软件运行时所需的数据、软件。内存空间等资源。 软件开发、维护所需的人力、支撑软件、开发设备等。(9) 安全保密要求 需对访问系统或系统信息加以控制吗？如何隔离用户之间的数据？用户程序如何与其它程序和操作系统隔离？系统备份要求？(10) 软件成本消耗与开发进度需求开发有规定的时间表吗？软硬件投资有无限制？(11) 质量保证 系统的可靠性要求？ 系统必须监测和隔离错误吗？ 规定系统平均出错时间？ 出错后

70、，重启系统允许的时间？ 系统变化如何反映到设计中？ 维护是否包括对系统的改进？ 系统的可移植性？需求开发实例需求开发实例对用户有效管理，防止不合法占用网络资源造成收入流失协助运营公司或部门管理网络和用户向用户提供有效接入服务，满足用户多元化需求政府部门（信产部、公安部等）对运营商及其管理的要求以城市为基本管理单位，分层分级管理，全程全网管理和运营以汇聚点为单位逐步部署（切换）用户使用方便（“首次认证”方案）宽带接入系统目标构架需求分配构架需求分配系统需求宽带接入（交换式以太网构造）身份认证，计费策略，网络安全，访问监测，接入服务，用户管理分配给硬件的需求交换机，PPPoE接入，访问控制设备，认

71、证与安全服务器，网络构架，流量控制分配给软件的需求端口隔离,用户信息（ID-Addr-Mac-IP）,身份认证（ID-Passwd）,访问信息（IP-Sock-Time-Len），流量，接入软件需求软件应能：通过目录服务进行用户管理，实现PPPoE接入与管理，具有安全包过滤，提供DHCP分配，营帐，实时策略宽带接入控制系统宽带接入控制系统适合于宽带网络环境（交换式以太网构造）用于用户接入网络的访问控制，包括：用户身份认证网络接入服务（DHCP、DNS、ARP）不合法用户和访问监测与控制网络安全体系支撑多样化计费策略支持（按时、预付费）用户基本信息管理（ID、Pswd、MAC）硬件技术需求分析硬

72、件技术需求分析交换机交换机交换机交换机AC用户用户用户用户用户用户用户管理机制用户管理机制用户端口隔离用户基本信息（ID-Addr-Mac-IP）用户身份认证（ID-Password）用户访问信息（IP-Sock-Time-Len）IDIPAddrMacTimeSock体系构架体系构架总部区域城市社区收费管理用户信息用户接入服务系统社区网络管理系统用户信息用户信息客户服务收费管理计费管理开户交费投诉上网欠费补交销户计费管理计费管理客户服务网络管理网络管理网络管理收费管理平台支撑平台支撑总部区域和城市汇聚和社区客客户户管管理理系系统统计计费费管管理理系系统统流流量量监监测测系系统统网网络络管管理

73、理系系统统接入控制接入控制系统系统ERP系统的协作关系系统的协作关系计费管理系统计费管理系统客户管理系统客户管理系统接入控制系统接入控制系统网络管理系统网络管理系统流量监测系统流量监测系统账单账单收费收费计时计时用户用户流量流量监测监测开关开关主要功能主要功能用户认证及其管理（首次认证）接入服务（DHCP、MAC-IP捆绑，ID-Sock）不合法用户和访问操作的监测与控制多样化计费操作和管理按时间计费（以后扩展按流量、带宽计费）预付费或记账式计费支持全网漫游与客服管理系统、公安安全监测系统接口部署结构部署结构城市中心汇聚点汇聚点社区接入网社区接入网社区接入网社区接入网社区接入网社区接入网社区接

74、入网社区接入网社区接入网社区接入网社区接入网社区接入网社区接入网社区接入网社区接入网社区接入网环境与要求环境与要求基于Web的构架认证WindowsClientUnixServer响应时间用户分类需求开发中的关键用户分类需求开发中的关键用户及其分类各种用户对系统具用不同要求，没有经验用户是否简单易用高级用户产品易用性和高效需要对用户分类，每一用户类有自己一系列功能和非功能要求在项目中，要尽早为产品确定并描述不同的用户类，这样就能从每一个重要的用户类代表中获取不同需求。用户用户“用户”（user）是泛称“客户”（customer）、“最终用户”（the end user）和“间接用户”（关系人）

75、。掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。客户是掏钱买软件的人，所以他是“上帝”“先有鸡还是先有蛋”哲学如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。“现代营销学之父”菲利普科特勒客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。与客户打交道的主要目的是：一是获取需求，二是签合同。用户用户(续续)即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。项目规模大，开发方与最终用户来往多。从最终用户获取详细需求，请最终用户试验软件，对最终用户进行培训等。重

76、视“间接用户”，千万别“大意失荆州”间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大影响。财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则 “非法经营”。寻找用户代表寻找用户代表寻找用户代表每一个用户类必须有一名和几名用户代表参与软件开发项目周期对于直接面向客户的项目，用户代表相对容易找到，对于商品化软件,用户代表（产品代表）比较难找到。产品代表必须是真正用户，而不是用户代理人，如主办者，产品客户，市场人员必须给产品代表足够尊重，否则将挫伤他们积极性产品代表者产品代表

77、者如何寻求产品代表者？与大公司建立联系通过产品打折或者免费使用方式来吸引产品代表者要注意技术泄漏问题真正聘请具有丰富经验的合适产品代表者“谁说了算谁说了算”“谁说了算？”问题同一用户类：个别用户需求不一致，由产品代表者作出决策。（实质是授权给产品代表者，由其解决用户类需求冲突）不同用户类：不同用户类意见不一致，决策哪一类用户需求更重要。了解产品类信息和业务目标，决定哪一用户类所占份额最大“谁说了谁说了算算”不同公司客户：要求产品按照自己的喜好设计。运用项目业务目标决定最有价值客户。非核心客户的需求可以安排在下一个版本开发。客户经理与真正用户需求相冲突。用户需求必须与业务需求一致，说服客户经理服

78、从产品代表者的用户需求和功能性规格说明。开发者构想产品与客户需求冲突，由客户作出决策，但不要陷入“客户总是对的”的陷阱中去，现实中，客户并不总是对的。某某出版社系统调查表出版社系统调查表编号提出问题1您在您在哪个部门工作？哪个部门工作？2出版业务流程是什么？出版业务流程是什么？3您您每日都处理那些文件、数据、报表？每日都处理那些文件、数据、报表？4工作中手工处理特别麻烦的事情是什么？工作中手工处理特别麻烦的事情是什么？5工作中手工处理什么问题解决不了？影响效工作中手工处理什么问题解决不了？影响效率的问题有哪些？率的问题有哪些？6您认为提高工作效率，节省工作时间，减轻您认为提高工作效率，节省工作

79、时间，减轻工作强度可采取哪些办法？工作强度可采取哪些办法？某某出版社系统调查表出版社系统调查表编号提出问题7您的部门需要成本核算和统计的内容有哪些您的部门需要成本核算和统计的内容有哪些？8您的部门采用计算机管理工作情况如何？您的部门采用计算机管理工作情况如何？9如何改进业务流程使之更合理？如何改进业务流程使之更合理？10哪些问题是目前传统手工方法根本无法解决哪些问题是目前传统手工方法根本无法解决的？的？11出版社计算机管理信息系统需要解决什么问题？“谁说了谁说了算算”市场部门提出需求与开发者构想系统发生冲突，由市场人员作为客户代理人，市场需求具有更重的分量，防止市场人员一味地迁就客户需求。没有

80、简单的正确答案需求获取的常用方法建立分析小组建立分析小组 领域专家：领域专家： 主角主角 系统分析员：导演系统分析员：导演客户访谈客户访谈问题分析与确认问题分析与确认 聆听客户的需求：访谈聆听客户的需求：访谈要点：事先需调查涉众或用户以及公司的背景。访谈前对问题进行复审。在访谈期间要参照一定的格式，以确保提出正确的问题。在访谈结束时总结两、三个最为重要的问题。重复您听到的内容，以确认您的理解是否正确。聆听客户的需求：访谈聆听客户的需求：访谈寻求客户客户是谁？ 用户是谁？ 他们的需要是否不同？ 他们具有什么背景、能力和环境？业务流程 问题是什么？想要解决该问题的原因是什么？ 是否存在其他想要解决

81、该问题的原因？ 成功解决方案的价值是什么？ 现在您如何解决问题？时间和价值之间如何折衷？在其他什么地方可以找到此问题的解决方案？ 举例（宽带运营平台）网络中心、信息中心、各级运营商网络管理员、操作员、上网用户不同，费用、安全、方便竞争环境、能力运营最少运营费用获得最大客户扩大竞争优势系统分割分期实施还是技术解决方案论证聆听客户的需求：访谈聆听客户的需求：访谈产品特点该产品解决什么问题？该产品会引起什么业务问题？对于用户来说，存在着什么危险？产品将处于什么环境？您对可用性有什么期望？您对可靠性有什么期望？需要何种性能/精度？举例高效运营计费模式，营帐模式，接入模式，管理变革，利润分配模式服务质量

82、的风险，会失去客户在线全流程服务7*24高可靠性很重要可以实时记录流量，计算费用，控制访问，灵活出帐，最小单位到3秒聆听客户的需求：访谈聆听客户的需求：访谈通用问题我是否提问了太多问题？ 我的问题是否与主题相关？您是回答这些问题的合适人选吗？ 您的答案是必需的吗？稍后我可以提出更多问题吗？您愿意参加需求复审吗？还有其他应该向您提出的问题吗？聆听客户的需求：访谈聆听客户的需求：访谈注意：不要让对方说明他们不经常说明的事情。 不要提出假设用户可以说明复杂活动的问题。一般来说，人们能做许多自己无法说明的事情。 经验主义的根据 - 缺少相关性。 提出可以自由回答的问题。 回避以“为什么”开头的问题，因

83、为这类问题会让对方采取防范的态度。 进行访谈对话时，要记住： 不要期望获得简单的答案。 不要只求得到对方的回答而匆忙草率地进行访谈。 倾听，倾听，再倾听！聆听客户的需求：研讨班聆听客户的需求：研讨班研讨班研讨班开始前协调员需要邀请应该参加研讨班的涉众，从而确定参加研讨班的小组。应该向参加者提供“热身”材料，供他们在到会之前阅读。协调员负责研讨班的后勤工作，比如发出邀请、申请带有会议所需设备的适当会议室，以及分发研讨班议程等。聆听客户的需求：研讨班聆听客户的需求：研讨班召开会议协调员主持会议，包括：给每个人发言机会。确保会议不脱离正题。收集关于适用的需求属性的意见记录调查结果。总结会议并得出结论

84、。 整理结果需求研讨班结束后，协调员与系统分析员需要花些时间对调查结果进行综合，并将信息精简为可介绍形式。聆听客户的需求：调查终止聆听客户的需求：调查终止如何知道你已经完成了需求获取？用户不能想出更多需求用户提出新的需求，但可以从其它需求的相关功能需求重获得这些新需求用户开始重复原先讨论过的问题用户提出对将来产品的要求，而不是现在讨论的特定产品编写需求文档编写需求文档需求文档要求完整性一致性可修改性可跟踪性软件需求规格说明软件需求规格说明软件需求规格说明的作用客户和营销部门依赖它了解他们所能提供的产品项目经理根据包含在软件需求规格说明中描述的产品来制定规划并预测进度安排、工作量和资源软件开发小

85、组依赖它来理解他们将要开发的产品测试小组利用它来制定测试计划，测试案例软件维护人员和支持人员依据它了解系统的功能产品发布组根据它编写客户文档，包括用户手册和帮助培训人员根据它编写培训教材什么是好的需求规格说明书什么是好的需求规格说明书正确正确地反映用户真实意图。开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。双方确认需求规格说明书。清楚采用反问方式来判断需求文档是否清楚文档结构、段落是否乱七八糟？上下文是否不连贯？ 文档语句是否含糊其词、罗里罗嗦？ 看了半天是否还不明白需求究竟是什么？ 无二义性 每个需求只有唯一含义。措词准确，切勿模棱两可。 什么是好的需求规格说明书什么是好的需求

86、规格说明书一致 各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。 必要 各项需求对用户而言应当都是必要的。“雪中送炭”，不能 “画蛇添足”“锦上添花”是好事，但不会多付钱。集中精力先完成必要需求，条件允许再“锦上添花”“锦上添花”需求设置为较低优先级。 完备 没有遗漏必要需求。不能关注特色，忽视必需功能。 什么是好的需求规格说明书什么是好的需求规格说明书可实现各项需求对开发方开发方而言应当都是可实现的（Attainable）。“可实现”：技术上可行，满足时间、费用、质量约束。营销人员对用户提出的需求“来者不拒”。但是产品需求规格说明书相当于商业合同。对于合同项目，如开发方不能确信某

87、些需求是否可实现，则应事先与用户协商，达成一致处理意见。可验证 各项需求对用户方用户方而言应当都是可验证的（Verifiable）。摩天大楼的一项需求是“抗十二级台风”.如何验证？ 什么是好的需求规格说明书什么是好的需求规格说明书确定优先级 原因是：项目存在“进度、费用、人力资源”限制。“取舍”法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。 阐述“做什么”而不是“怎么做” 重点是阐述“做什么”，而不是“怎么做”。“怎么做”是系统设计和实现阶段的事情。 开发人员身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。关键是不要将“怎么做”写到需求规格说明书里面

88、，记录在其它文档里就行了。 软件需求规格说明软件需求规格说明文档可读性对节、小节和单个需求的号码编排必须一致在右边部分留下文本注释区允许不加限制地使用空格正确使用各种可视化强调标志创建目录表和索引表有助于读者寻找所需信息对所有图和表制定号码和标识号软件需求规格说明软件需求规格说明需求的标识序列号，如UR-2,SRS13层次化编码，如3.2.4层次化文本标签，“当用户请求打印超过10个副本时，系统必须让用户进行确认判断。” print.copies.confirm不完整的需求进行特殊的标识TBD(to be determined)，在继续进行构造需求集合之前，必须处理完所有TBD用户界面与软件需

89、求说明用户界面是解决方案，而不是需求，但是可以更清楚的定义需求。可以画一些草图软件需求规格说明软件需求规格说明a引言a.1目的a.2文档约定a.3预期的读者和阅读建议a.4产品的范围a.5参考文献b.综合描述b.1产品的前景b.2产品的功能软件需求规格说明软件需求规格说明b.3用户类和特征b.4运行环境b.5设计和实现上的限制b.6假设和依赖C.外部接口需求c.1用户界面c.2硬件接口c.3软件接口c.4通信接口软件需求规格说明软件需求规格说明D.系统特性d.1说明和优先级d.2激励、响应序列d.3功能需求其它非功能需求e.1性能需求e.2安全设施需求e.3软件安全性需求e.4软件质量属性e.

90、5业务规则e.6用户文档其它需求附录A:词汇表附录B:分析模型附录C:待确定问题的类标软件需求规格说明的注意事项软件需求规格说明的注意事项需求说明语句保持语句和段落的简短采用主动语态的表达方式编写具有正确的语法和标点的完整句子使用的术语应该和词汇表中定义的一致需求陈述应该具有一致的式样“系统必须”，或者“用户必须”紧跟一个行为动作和可观察的结果“仓库管理子系统必须现实一张在所请求的仓库中有存货的药品名单。”软件需求规格说明的注意事项软件需求规格说明的注意事项减少不确定性，避免采用模糊、主观术语“用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受和健壮。”避免使用比较性词汇“

91、提高，最大化，最小化和最佳化。”定量说明所需提高的程度或说清一些参数可接受的最大值和最小值。“系统处理能力，其处理发票扫描与识别的速度为V1.0的150”需求表达需求表达“产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不得小于60秒”后台任务管理器应该在用户界面的指定区域显示状态消息在后台任务进程启动之后，消息必须每隔60（+_10）秒更新一次，并且保持连续的可见性。如果正在正常处理后台任务进程，那么后台任务管理器必须显示后台任务进程已完成的百分比当完成后台任务时，后台任务管理器必须显示一个“已完成”的消息。如果后台任务中止执行，那么后台任务管理器必须显示一个出错信息。需求表达需求表

92、达“产品必须在显示和隐藏非打印字符之间进行瞬间切换”“用户在编辑文档时，通过激活特定的触发机制，可以在显示和隐藏所有HTML标记之间进行切换。”需求表达需求表达“分析程序应该能生成HTML标记出错的报告，这样就可以使HTML的初学者使用它来迅速排错”在HTML分析程序完全分析完一个文件后，该分析程序必须生成一个出错报告，这个报告中包含了在分析文件中所发生错误的HTML所在的行号以及文本内容，还包含了对每个错误的描述。如果分析过程中未发生任何错误，就不必生成任何错误报告需求优先级需求优先级关键（或首要）。需求与系统的主要任务、基本功能及待开发的功能有关。如果关键需求缺失，系统将无法完成主要任务。

93、重要（或其次）。需求与系统功能的支持有关，（统计数据编译、报告生成、监督和功能测试等），如果缺失，系统仍然可以（在一段时间内）完成基本任务，但服务质量有所下降。辅助（不错）。需求着重“舒适性”功能，与系统主要任务无关，但有助于系统使用或市场定位。难于完全避免初始需求变更的需求对问题的初始理解对问题的新理解时间需求变更需求变更需求变更原因分析1)单纯的用户因素2)市场形势变化3)系统因素4)工作环境和要求变化5)需求开发的缺陷 需求分析、定义和评审不充分与用户沟通不畅需求变更需求变更需求变更对软件开发的影响使变更前开发工作和成果失效返工成为被迫采取的对策工作量及资源投入的增加使开发成本提高项目完

94、成时间后延需求变更需求变更与用户充分沟通与用户共同明确确定的需求的意义项目开发工作项目开发组织用户* 产品后续开发工作的基础* 产品维护工作的重要参考*对用户的承诺， 关系到项目开发工作的投入、交付期和产品质量* 关系到能否如期获得所需的产品* 作为合同的附件，关系到双方的权益* 是产品验收的依据向用户说明需求不确切或频繁变更对开发工作的冲击使用户理解过多变更最终对用户不利降低降低需求变更风险的策略需求变更风险的策略与用户共同确定需求，作为合同附件， 签字生效合同中含有对需求变更的条款采用原型方法开发，或螺旋模型开发项目计划中适当留有余地（时间进度、人力投入、费用等）严格实施变更控制（1）提出

95、变更请求（2）审理变更请求，进行变更影响评估。评估内容：变更所需人力投入变更对原计划安排的影响估计变更引起的成本增加（3）批准变更请求（4）取得用户的认可（5）修订项目计划（6）实施变更（7）验证变更变更控制的步骤变更控制的步骤批准提出变更请求变更影响评估评审评估报告审批用户认可修订项目计划实施变更验证变更结束拒绝修正需求变更控制流程需求变更控制流程1需求变更请求（1）内容申请号变更说明变更类别影响分析变更请求状态变更请求日期需求变更控制实施需求变更控制实施（2）需求变更请求实例项目名：XYZ变更申请号11日期：23Feb1998变更说明IS-41分析器对CDMA的支持影响分析对CDMA的配置

96、模块和分析器无影响TDMA码可复用，受影响的模块是：CGAAPP模块，需对IS-41单独进行规范性分析，CDMAPP01模块（a）TRIS41R01按TRCDMARS41R01复制（b）使用纯虚拟对TRCDMAR01建立（c）ActualCallModeManager并重新定义SILVER06GUIAPP+模块：在资源表中加入IS-41工作量5人日计划时间无需重大变动状态将并入新的CDMA软件2需求变更累积影响的跟踪（1）需求变更累积影响跟踪的意义和作法累积影响变更累积表（2）需求变更累积表实例（表四）需求变更控制实施需求变更控制实施需求变更累积表需求变更号需求变更时间变更说明工作量状态118

97、/2规定使用情况统计322/2结束2演示期用户阻塞2未结束3演示期用户强迫退出2未结束418/2用户信息归档527/2结束5演示期关闭窗口1未结束6演示期保存扩展数并在需要时恢复10未结束7演示期能够在特定节点启动2未结束8演示期删除时列出所有节点1未结束918/2注释（建立删除批准修改等）10未结束1023/2PENETCONFIG支持netconfig格式10未结束1123/2IS-41分析器IS-41分析器对CDMA的支持51/3结束总计513需求控制流（1）需求状态及其演变软件需求在后继阶段开发工作中将逐步展开，加以实现。在不同的开发阶段软件需求以不同的形式进行着状态的演变。例如：需求

98、阶段从获取的需求到定义的需求建议阶段制定出项目计划以后演化为承诺的需求设计阶段设计工作完成并在验收后成为设计的需求编码阶段完成编码和单元测试后成为实现的需求测试阶段完成确认测试后成为完成的需求需求变更控制实施需求变更控制实施需求评审需求评审错误需求基础上的工作的修补是巨大的浪费。研究表明：比起在需求开发阶段由客户发现的一个错误，然后更正这一错误需要多花68到110倍的时间。需求评审需求评审进入审查的标准？文档已经符合标准化文档已经经过了语法检查作者已经审查了文档在版面上的错误已经得到了审查员所需的先前或参考文档所有未解决的问题都被标记为TBD包括了文档中使用过的术语词汇表需求评审需求评审如何判

99、断审查结束？已经明确阐述了审查员提出的所有问题已经正确修改了文档修订过的文档已经进行了语法检查所有TBD问题都已经解决文档归档开发阶段需求状态需求建议设计编码测试获取定义承诺设计实现完成状态的演变生存期各阶段需求生存期各阶段需求如何进行需求分析如何进行需求分析为了得到用户，企业不得不鼓吹：用户就是上帝，用户永远是正确的。 谁都知道这不是真的。事实上，很多时候用户说不清楚需求、会说错需求或者提出一些无法实现的需求。需求分析：在需求开发过程中，对所获取需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确反映用户真实意图。需求分析方法：“问答分析法”(实用型，用户需求调查阶段)“建模分析法”（

100、学术型，产品需求定义阶段） 如何进行需求分析如何进行需求分析问答分析方法 刨根究底地问，如果问题都被解答了，那么需求也就分析清楚了。一个人可以“自问自答”分析需求，几个人分析需求则称为“研讨”。 问答分析最重要的问题是：“是什么”和“为什么”。每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。 如何进行需求分析如何进行需求分析问答分析方法其它常见的问题有：需求存在二义性吗？需求文档的上下文有矛盾吗？需求

101、完备吗？需求是必要的吗？需求可实现吗？需求可验证吗？需求的优先级确定了吗？如何进行需求分析如何进行需求分析建模分析法 采用图形一目了然，“一图低千言” 。 在需求开发过程中，某类信息，图形表示比文本表示更加有效。要图形与文本结合描述需求。需求建模：用图形符号来表示、刻画需求。建模分析方法“结构化分析法”和“面向对象分析法”。 恰当地使用图形符号在建模时使用花样过多的图形符号或文字意味着模型表示复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。 世上不存在一个包罗万象的图它能完整地描述需求。需求建模不可能取代文字描述。在在需需求求文文档档中中，文文字字描描述述是是第第一一重重要要的的，建建模

102、模主主要是起分析、解释作用。要是起分析、解释作用。建议将模型存放在需求文档的附录中，便于正文引用。 如何进行需求分析如何进行需求分析作出决策 需求的冲突在所难免。需求有争议怎么办？先听官儿大的或者威望高的，“少数服从大多数”。产品有多类客户，要求不同。需求决策商业利益为导向。出钱最多先满足。开发者的产品与客户需求冲突，尊重客户观点。纠正明显不合理客户需求。产品复杂，请开发人员快速构造软件原型，看着软件原型再分析需求。 如何定义产品需求如何定义产品需求规程 第一步：细化并分析用户需求第一步：细化并分析用户需求 需求分析员对用户需求说明书进行细化复杂用户需求进行建模分析，帮助理解需求。Rose进行

103、需求建模分析，文档可作需求规格说明书附件。建模分析的技术难度比较高，需求分析员应根据自身水平取舍。 第二步：撰写产品需求规格说明书第二步：撰写产品需求规格说明书 按照指定文档模板撰写产品需求规格说明书。有时包括软件需求规格说明书和硬件需求规格说明书。第三步：进行需求确认第三步：进行需求确认PM邀请同行专家和用户（包括客户和最终用户）一起评审产品需求规格说明书，尽正确无误反映用户真实意愿。 需求评审后，开发方和客户方的责任人对产品需求规格说明书作书面承诺。 软件需求规格说明书的参考模板需求管理需求管理需求管理变更控制建议变更分析影响作出决策交流合并测量需求的稳定性版本控制确定需求文档版本确定单个

104、需求文档版本需求跟踪定义对其它需求的连接链定义对其它系统元素的连接需求状态跟踪定义需求状态跟踪需求每一个状态需求管理工具需求管理工具Caliber-RMhttp:/DOORShttp:/QSSrequireit:http:/RequisitePro:http:/RTMWorkshop:http:/VitalLink:http:/配置管理与配置管理与UCM变更变更在您的脑海里第一个蹦出的词是什么？随时随地，每时每刻别再变了，真够头疼的，不干了。议程议程什么是CM?SCM的定义?SCM的好处SCM的原理SCM工具SCM的趋势UCMClearCase配置管理配置管理configuration man

105、agement用于管理复杂系统的技术分解复杂系统为更小的子系统(处理器,硬盘,键盘,监视器,鼠标, ).通过接口互相联接.每一子系统可以分解为更小的子系统.每一子系统有变量或者继承.BOM 被用于识别确切的组件构成.议程议程什么是CM?SCM的定义?SCM的好处SCM的原理SCM工具SCM的趋势UCMClearCaseSCM的定义的定义 (IEEE)软件配置管理软件配置管理 “配置管理是辨识，定义系统中的条目，在生命周期内控制这些条目的变化，记录与报告条目和变更请求的状态，校验条目的完整性和正确性。”FromANSI/IEEEStd729-1983“ANSI/IEEEstandardGloss

106、aryofSoftwareEngineeringTerminology”,Copyright1983byIEEESCM定义定义 (SEI)“SCM包括辨识在一定时间，给定点的软件配置（如，选择的软件产品和其描述）。在整个生命周期内，系统化的控制配置变化，维护软件配置的集成性和可跟踪性。工作产品置于软件配置管理中，包含发送到客户的产品（如，软件需求文档和代码），用于创建这些软件产品的被辨识的条目等（编译器等）”TheSEISoftwareCapabilityMaturityModel(version1.1)SCM定义定义 (Practical)软件配置管理是一个软件工程规律，由工具和用于管理软件

107、变化的流程组成.流程被用于控制与文档化软件生命周期内的所有变化.这是软件项目的开始，其持续直到软件不可用(在软件发货时并为结束).更多的实践性SCM定义,参见:( & Change MgmntProjectMamntEnvironment跌代开跌代开跌代开跌代开发发发发SCM & 跌代开发跌代开发SCM & Change Control SystemSCM & Change Control System建模工具建模工具需求工具需求工具测试测试工具工具开开发发工具工具议程议程什么是CM?SCM的定义?SCM的好处SCM的原理SCM工具SCM的趋势UCMClearCaseIDENTIFICATIO

108、NIDENTIFICATIONCONTROLCONTROLSTATUSSTATUS ACCOUNTING ACCOUNTINGAUDITAUDITCM的主要功能的主要功能SCM的原理的原理版本控制VersionControl辨识Identification工作空间管理WorkspaceManagement构建与发布管理Build&ReleaseManagement状态记录StatusAccounting审核与评判AuditandReview变更控制ChangeControl5 5SCM -版本控制版本控制版本控制版本化控制所有文件类型(sourcecode,binaries,documenta

109、tion,etc.).分支化(支持并行开发和项目变化).可视化归并(融合并行开发成果).无约束目录分层结构(组织项目文件).4 43 30 01 12 23 32 21 10 0Foo.c1 10 02 2SCM 识别识别标识系统需要反映产品的结构，通过识别组件的结构和种类使其有一致、可理解的形式，通过：给每一组件一个名字版本标识ProjectXCompYFoo.cMainFixbug11 5 54 43 30 01 12 23 32 21 10 01 10 02 2Foo.cSCM 工作空间管理工作空间管理每一梯队成员有一工作空间，防止相互妨碍.当需要变更文档，将从库中复制到梯队成员的工作空

110、间.任何变化只是影响文档，不会影响的库.变更的文档在得到同意后被复制回库中.SCM 构建与发布管理构建与发布管理控制产品发布.控制整个生命周期的变化.应用基线保证软件一致性.基线是一个正式拷贝,所有变化都会反映在其上.执行构建,构建参数的记录,审核结果记录.分段化(把原始对象置于版本控制中)SCM 构建和发布管理构建和发布管理FreezeFreezeBaseline 1FreezeFreezeRelease 1.0Release 1.0.1Release 1.0.2Baseline 2Release 2.0Rel 1.0 FixingFix TeamMajor DevelopmentMAJ T

111、eamMinor DevelopmentMIN TeamBugfix + MinorIntegrationMajor + Minor + BugFixIntegrationBaseline 1 + MajorIntegrationFix minor bugInternal ReleaseSCM 状态记录状态记录记录与报告组件与变更请求状态.收集产品中组件的统计信息.产生对管理目标的修改报告.SCM 审核与评价审核与评价确认产品的完整性确保组件在产品的整个产品生命周期内工作在适当状态，维护组件的一致性确保产品处于定义的组件集合范围变更控制的概念变更控制的概念变变更更请请求来源于求来源于产产品生命

112、周期的不品生命周期的不同方面同方面Change Control Process 新需求新需求新特征新特征Fix Bug核准核准认认可可客客户户与最与最终终用用户户的的输输入入市市场场行行销销开开发发者者输输入入测试测试者者输输入入Require-mentsTestsVisionCode拒拒绝绝 变更控制流程变更控制流程Require-mentsEnhance-mentsTroubleTicketsClassifyClose RequestValidate ChangeProcess ChangeTechnical AssessmentBusiness AssessmentYesNoApprov

113、al关联原理关联原理 所有原理是帮助提供SCM的正常运作.没有辨识，就没有状态记录.没有变更控制，不能审核和评判辨识增强变更控制议程议程什么是CM?SCM的定义?SCM的好处SCM的原理SCM工具SCM的趋势UCMClearCaseSCM 工具工具工具分类工具评价工具发展的趋势Process-OrientedDeveloper-OrientedSCM 工具的分类工具的分类版本控制版本控制通过delta技术或者非变更控制支持实现源代码的版本控制(CVS,SourceSafe,).Version Control面向开面向开发发者的者的 版本控制分布式，并行开发中等变更控制支持 (ClearCase

114、, ADC/Pro).面向流程面向流程 变更控制面向开发者定制流程模型（包括集成方法，推进变更控制系统） (ClearCase+ClearQuest, Continnus, ).版本控制版本控制面向开发者面向开发者面向流程面向流程SCM 工具评价工具评价工具分类与安装、部署的难度有关依靠需要的流程级别(ISO9000-3,SEIsCMM)组织的大小和任务需要考虑实际的要素包括版本控制，依属跟踪，变更控制状态报告，构建管理，流程管理工作空间管理,知识库管理，审核控制(Dart,1996)更多信息，请参阅SusanDart论文NotAllToolsareCreatedEqual(http:/ 52

115、7Add promotioncalculationBug 849New webdesign团队人员工作在活动上( 变更请求)基线中实施了哪些活动?n工件被集成建立基线活动的结果体现在对工件的变更上(代码, 模型等)？SCM 趋势趋势提供比基于文件的checkin/checkout好的模型Rational软件作为建议的统一变更管理(UCM)，成为新的SCM系统UCM基于两个关键概念:组件管理基于活动的SCMArtifactsArtifactsActivitiesActivitiesActivityActivityActivityActivityActivityActivity基于组件的结构基于组

116、件的结构配置控制管理复杂性维护集成性可重用性基础组件重用构架重用项目管理基础计划-Planning安置-Staffing提交-DeliverySystem-System-softwaresoftwareMiddlewareMiddlewareBusiness-Business-specificspecificApplication-Application-specificspecific议程议程什么是CM?SCM的定义?SCM的好处SCM的原理SCM工具SCM的趋势UCMClearCase第三代配置管理解决方案第三代配置管理解决方案:UCM标识工件，并将工件存入安全的版本库中控制并记录对工件的

117、变更保持稳定、一致的工作空间支持工件构件的并行开发及早集成、经常集成保证软件Build可重现记录并追踪变更请求以活动为中心的组织和集成-建立活动变更集将工件组织成版本化的构件在项目里程碑处创建基线最佳实践原则：统一变更管理最佳实践原则：统一变更管理变更后的系统统一变更管理流程面向特定客户技术规格BUG报告功能新功能追加需求新平台支持需求基于基于SCM的活动的活动变变更集更集Add Web InterfaceAdd Web Interfacea.htmla.htmlV5V5c.xmlc.xmlV3V3b.jpgb.jpgV8V8下一代 SCM项项目目经经理角色理角色管理活管理活管理活管理活动动动

118、动 w wTo do listsTo do listsw wAllocate to teamAllocate to teamSCM 工具支持工具支持管理工件管理工件管理工件管理工件 w wVersioning: code, Versioning: code, models, XML, HTMLmodels, XML, HTMLw wParallel developmentParallel development开开发发活活动动RequestRequestPriorityPriorityOwnerOwnerAdd Web InterfaceAdd Web Interface 1 1TerryTe

119、rryBug 527Bug 527 2 2SandySandyAdd local event handler 2Add local event handler 2KimKimUCM -Unified Change ManagementOutoftheBox抽象层次的提升活动( Activity)变更集流( Stream)活动的集合构件（Components）呈现软件结构基线（Baselines）构件的一个版本项目（Project）包含了构件和流基于变更管理的最佳实践经验无数的CM体验成千上万的用户易适用优化整个团队Rational ClearQuestRational ClearCase管理活

120、动To Do ListsWorkflow管理工件Versioning: code, models, XML, HTMLParallel developmentUCMProcessUCM ：抽象层次的提升抽象层次的提升活动( Activity)变更集流( Stream)控制隔离与集成的平衡构件（Components）呈现软件结构基线（Baselines）构件的一个版本项目（Project）包括了流和构件简化变更管理，团队整体受益！项目经理开发人员集成人员测试人员分析设计以活动为中心的组织和集成以活动为中心的组织和集成统一活动与工件Rational ClearQuestRational Clear

121、Case管理活动To Do ListsWorkflow管理工件Versioning: code, models, XML, HTMLParallel development变更集Special Promoa.Html V5c.Xml V3b.Jpg V8ClearQuest: Organized ActivitiesRequestPriorityOwnerSpecial Promo1TerryBug 5272SandyAdd GUI button2Kim引入活动带来的受益引入活动带来的受益永远避免修改的丢失易于再现New GUIBug 849Bug 527Build 3Build 2Build

122、 1以“活动”递交基于活动的集成和测试开发人员测试人员集成人员UCM ：抽象层次的提升抽象层次的提升 统一变更管理统一变更管理 活动( Activity)变更集流( Stream)控制隔离与集成的平衡构件（Components）呈现软件结构基线（Baselines）构件的一个版本项目（Project）包括了流和构件简化变更管理，团队整体受益！项目经理开发人员集成人员测试人员分析设计UCM: 参加项目与选择合适的工作参加项目与选择合适的工作区区参加项目选择活动，实施任务12To Do List1. Bug 671 修正2. 特別菜单3. Bug 829 修正以活动递交变更(递交变更集)3UCM

123、：抽象层次的提升抽象层次的提升活动( Activity)变更集流( Stream)控制隔离与集成的平衡构件（Components）呈现软件结构基线（Baselines）构件的一个版本项目（Project）包括了流和构件简化变更管理，团队整体受益！项目经理开发人员集成人员测试人员分析设计UCM：将工件组织成版本化的构件：将工件组织成版本化的构件“构件”的引入：有利于将逻辑设计与物理实现相对应构件可以在不同项目之间重用SystemUserSrvcsAdminProjectSystemBL5User Srvcs BL2AdminBL3集成人员UCM ：抽象层次的提升抽象层次的提升活动( Activi

124、ty)变更集流( Stream)控制隔离与集成的平衡构件（Components）呈现软件结构基线（Baselines）构件的一个版本项目（Project）包括了流和构件简化变更管理，团队整体受益！项目经理开发人员集成人员测试人员分析设计fileAfileBfileCfileDFileEfileFfileGfileHUCM：在项目里程碑处创建：在项目里程碑处创建基线基线123123123123123123123123构件与基线构件基线AlphaBL1 BetaBL3构件Alpha构件构件BetaBL1BL2BL3BL1BL2UCM: 基线定级基线定级基线的升级Rejected(不合格)项目经理集

125、成人员UCM：基线与复合基线：基线与复合基线SystemcomponentSystem_BaselinePA_BaselineBL1BL2PB_BaselineBL9BL6产品X项目A项目BProjA_componentProjB_componentGUIAdminLibsCoreUCM ：抽象层次的提升抽象层次的提升活动( Activity)变更集流( Stream)控制隔离与集成的平衡构件（Components）呈现软件结构基线（Baselines）构件的一个版本项目（Project）包括了流和构件简化变更管理，团队整体受益！项目经理开发人员集成人员测试人员分析设计UCM ：用构件组织项目

126、结构：用构件组织项目结构定义项目结构项目之间构件共享和复用构件名称哪个基线? 只读? 还是可修改?项目经理UCM：用用“流流”组织项目层次组织项目层次DeveloperJoin a projectMake ChangeDeliver ChangeUpdate Work SpaceSCM工作流实例工作流实例Define implementation modelArchitectProject Mgr.Allocate component to ProjectCreate ProjectEstablish CM PolicyAssign an Schedule workMonitor Projec

127、t StatusCM ManagerSet up CM EnvironmentIntegratorCreate Integration Work SpaceCreate BaseLinesBuild ComponentPromote BaseLines角色角色 & 活动活动Architect深入理解系统构架负责系统构架如何实现Define implementation modelArchitect角色角色 & 活动活动(Cont)CMManager创建与维护SCM基础构架CM计划知识库管理CM ManagerSet up CM Environment角色角色 & 活动活动(Cont)Proje

128、ct Manager建立与维护项目工作空间和基线.根据CM计划，指派与调度工作活动，定义开发策略CCB成员Project Mgr.Allocate component to ProjectCreate ProjectEstablish CM PolicyAssign an Schedule workMonitor Project Status角色角色 & 活动活动(Cont)Developer在指派活动的私有空间工作工作产品测试, 包括私有和集成环境.提交工作产品到项目集成域.基线变更，更新工作空间DeveloperJoin a projectMake ChangeDeliver Change

129、Update Work Space角色角色 & 活动活动(Cont)Integrator接受开发者工作，执行集成构建.集成测试 (组件与系统级).提升基线，并通告所有梯队成员.IntegratorCreate Integration Work SpaceCreate BaseLinesBuild ComponentPromote BaseLinesSCM工作流解释工作流解释软件文件与目录，基于系统架构被组织为版本化的组件.系统结构系统结构PurchasedDevelopedFreeUser GUISecurityGSM ServicesWeb ServicesCDMA ServicesNwk

130、DriverDBMS driverIP ServicesPSTN ServicesAdmin GUINwk InterfaceDBMS Interface项目目录项目目录User GUIAdm GUISec.GSMCDMAIPWebPSTNDBMS SysNwk SysDBMS DrvNwk DrvSCM工作流解释工作流解释(Cont)项目经理创建项目，指派项目梯队于每一组件展开工作.BL-1 (INIT)2 21 14 43 3File1.c组件基线组件基线2 21 13 34 4File2.c2 21 13 3File3.c2 21 13 34 4File4.cComponent项目基线项

131、目基线Comp 1Comp 2Comp 3Project Recommended Baseline工作指派给每一个开发者工作指派给每一个开发者Dev. As Workspace Dev. Cs Workspace Dev. Bs Workspace Dev. Ds Workspace SCM工作流解释工作流解释(Cont)开发者基于指派的活动（任务、缺陷、变更请求），对组件、文件、目录进行修改.新文件和目录版本在开发中被收集，包括其关联的活动.开发者工作空间开发者工作空间SCM 工作流解释工作流解释(Cont)一旦完成，活动和其相关的变化集被发布与集成到项目集成域.新组件基线被创建，测试和提升

132、.开发者提交工作开发者提交工作Integration AreaDev s A WorkspaceDev s B WorkspaceDev s D WorkspaceDev s C Workspace组件基线提升组件基线提升InitialReviewedProductionBL-1BL-3BL-2TestedSCM工作流解释工作流解释(Cont)组件基线被装配成系统新项目建议基线被创建开发者用新的建议基线同步其工作空间新项目基线新项目基线Comp 1Comp 2Comp 3New Project Recommended Baseline开发者开发者 Re-base工作空间工作空间Project

133、Recommended BaselineDev s A WorkspaceDev s B WorkspaceDev s D WorkspaceDev s C WorkspaceSCM 工作流解释工作流解释 (Cont)根据项目计划，系统被测试，发布AlphaBetaFinalUCM统一变更管理统一变更管理 ClearQuestClearCase议程议程什么是CM?SCM的定义?SCM的好处SCM的原理SCM工具SCM的趋势UCMClearCase什么是什么是 ClearCase?ClearCase 是是所有类型的文件和目录的版本管理工具-记录所有活动-报告历史-精确化每一次发布在Unix和Wi

134、ndows环境都可以运行两种用户接口-命令行:cleartool-图形交互:xclearcase基本概念基本概念VOB-VersionedObjectBase（版本对象库）-整个数据库由一些VOB构成CONFIGSPEC-配置规格(file)定义在你的view中看到的每一个VOB元素（element）的版本VIEW-是用于访问VOB的一个工作区-每一个独立开发者或者紧密的合作组都有自己的视图基本概念基本概念 (cont.)元素（ELEMENT）-被存储在VOB中的文件或者目录META-DATA类型:-labels-attributes-hyperlinks-triggers能被联接到要素的特定

135、版本，或者一个分支，或者完整的要素基本概念基本概念 (cont.)element*CHECKEDOUTelement*/main/LATESTvob1vob2element*CHECKEDOUTelement*/main/LATESTelement*CHECKEDOUTelement*./phase2/LATESTelement*REL1-mkbranchphase2element*/main/LATESTelement*CHECKEDOUTelement*/main/LATESTCONFIGSPECsVIEWsvob3KallesviewAnnasviewTestgroupsviewPete

136、rsviewelementsVOBs缺省配置规格（缺省配置规格（Default Config Spec）element*CHECKEDOUTelement*/main/LATEST-每行一条规则-规则从顶向下处理-如第一条规则元素匹配版本没有找到，系统找第二条规则element*CHECKEDOUTelement*/main/LATEST在正常视图窗口中的文件在正常视图窗口中的文件x.ccy.ccz.ccw.ccCHECKEDOUT版本树窗口中的文件版本树窗口中的文件x.ccz.ccy.ccw.cc/main/main/main/mainCHECKEDOUT012301235401234012

137、34匹配缺省配置规格的版本匹配缺省配置规格的版本01234x.cc5z.ccy.ccw.cc/main/main/main/main40123012340123Labellingx.ccz.ccy.ccw.cc/main/main/main/mainREL1REL1REL1REL140123012340123540123Config Spec for Label REL1的的例子例子element*REL1element*/main/LATESTelement*CHECKEDOUTelement*/main/LATEST用用REL1配置规则匹配的版本配置规则匹配的版本/main/main/ma

138、in/mainREL1REL1REL1REL1x.ccz.ccy.ccw.cc40123012354012340123Branching0rel1_corr1x.ccz.ccy.ccw.cc/main/main/main/mainREL1REL1REL1REL14012301234012354012301rel1_corrBranch Config Spec例子例子element*CHECKEDOUTelement*/main/rel1_corr/LATESTelement*REL1-mkbranchrel1_correlement*/main/LATESTelement*CHECKEDOUT

139、element*/main/LATEST用用Branch Config Spec匹配的版匹配的版本本x.ccz.ccy.ccw.cc0rel1_corr1x.ccz.ccy.ccw.cc/main/main/main/mainREL1REL1REL1REL14012301234012354012301rel1_corr要素的基本活动要素的基本活动Checkout-创建新的可编辑版本-同时只能有一个人编辑这个文件Checkin-被命令创建的版本被存储到VOB，对于其他的视图也是可视的-元素便更为写保护模式Uncheckout-取消checkout操作其他工具其他工具Clearmake-Clear

140、CasevariantoftheUnixmakeutilityMultiSite-用户不同位置得并行开发的相同VOB Thats ClearCase!Letstryhowitworksinpractice结论结论SCM不只是版本控制.重要的是，SCM帮助提升整个软件开发周期的质量.执行SCM需要付出经历，时间，资源，承诺和合作.软件开发应用手工流程控制的复杂化，需要选择合适的工具.SCM工具有许多级别/风格,基于你的需求和未来增长选择合适的工具，错误的选择会带来严重的后果.高度集成的现代工具将更容易部署.先驾驭项目，在选择工具CMM基础基础软件项目的现状软件项目的现状美国有大约多少软件项目在进

141、行？其中多少会在未完成前就超出预算或时间表有多少项目会因失败而取消？更多的项目被中途搁浅，不了了之软件危机：原因并非技术层面约30万4050目标目标理解CMM基本概念运用CMM关键流程，提高软件管理水平内容安排内容安排CMM概貌CMM2级中软件项目管理六大要素方法与经验软件危机的后果软件危机的后果临时性流程时间，质量，成本重蹈覆辙压力之下一切走样项目很难控制，进度时间表难以做到切实可行成功往往依赖于：英雄主义，加班加点，救火精神什么是什么是CMM：能力成熟度模型能力成熟度模型 1986年，SEI，第一版最初为美国国防部开发初衷是为了评估子承包商是一个逐级层进式模型公认的软件流程改进模型基于SP

142、C（统计过程模型）方法基于软件行业大量实践经验的总结什么是什么是CMM（Cont.）是一个软件领域最权威的国际标准是一套软件行业多年来所积累的经验总结是一部帮助软件组织提高管理能力的方法指南是一种衡量软件组织的成熟度的评估准则是一种准则，不是一种实现方法CMM的发展过程SEI与与Mitre公司承担项目公司承担项目过程成熟度框架过程成熟度框架成熟度提问单成熟度提问单CMMV1.0CMMV1.1CMMV2.019861987199119931997CMM成熟度级别成熟度级别不断改进的过程不断改进的过程可预测的过程可预测的过程标准的一致的过程标准的一致的过程有纪律的过程有纪律的过程已管理级已管理级(

143、4)(4)已定义级已定义级(3)(3)可重复级可重复级(2)(2)初始级初始级(1)(1)优化级优化级(5)能力增长不可预测不可预测, ,难控制难控制Project Project ManagementManagementIntegrated Integrated Engineering Engineering ProcessProcessProduct and Product and Process Process QualityQualityManaging Managing ProcessProcess组织级流程项目级流程已定量管理优化，不断优化级从无到有量化181224CMM过程过程t

144、oforecasttoimproveActivityResultstoproduceStandardsinputtoinputtoPreparationEvaluationinputtotoimproveCMM结构结构containorganizedbycontainMaturityLevelsKeyProcessAreasCommonFeaturesKeyPracticesProcessCapabilityGoalsImplementationorInstitutionalizationInfrastructureorActivitiesindicateachieveaddressdescr

145、ibeCMM目标目标总结KPA的关键实践增强成熟级别的流程能力指导组织与评估梯队选择可以替换的方法来实施关键流程域每一个关键流程图（KEYPROCESSMAPS）达到一个或多个目标CMM 级别级别经反馈得以改进的过程结结 果果生产率和质量风险已管理级保持优化的组织，但仍为人员密集的过程技术变更、问题分析、问题预防过程度量、过程分析、量化质量计划培训、测试、技术常规和评审、过程关注、标准和过程项目管理、项目策划、配置管理、软件质量保证（量化的）已度量的过程（量化的）已定义且制度化的过程（直觉的）过程依赖于个人个别的、混乱的过程优化级已定义级可重复级初始级四五三二一主要需解决的问题主要需解决的问题

146、特特 征征等等 级级CMM 级别级别等级特性关键过程领域5最优化的ContinuousprocesscapabilityimprovementProcessChangeMgt.TechnologyChangeMgt.DefectPrevention4被管理的Quantitativemeasurementofprocess&qualitativemanagementofproductSoftwareQualityMgt.QuantitativeProcessMgt.3被定义的SoftwareprocessesdefinedandinstitutionalizedPeerReviewsInterg

147、roupCoordinationSoftwareProductEngineeringIntegratedSoftwareMgt.TrainingProgramOrganizationProcessDefinitionOrganizationProcessFocus2可重复的Managementcontrolsinplace;stableplanningandproductbaselines;stilldependentonindividualsfornewproductsSoftwareConfigurationMgt.SoftwareQualityAssuranceSoftwareSubco

148、ntractMgt.SoftwareProjectTracking&OversightSoftwareProjectPlanningRequirementsMgt.1初始的HeroesCMM 过程分类过程分类级别分类管理组织的工程5最优化的TechnologyChangeMgt.ProcessChangeMgt.DefectPrevention4被管理的QuantitativeProcessMgtSoftwareQualityMgt.3被定义的IntegratedSoftwareMgt.IntergroupCoordinationTrainingProgramOrganizationProce

149、ssDefinitionOrganizationProcessFocusPeerReviewsSoftwareProductEngineering2可重复的SoftwareConfigurationMgt.SoftwareQualityAssuranceSoftwareSubcontractMgt.SoftwareProjectTracking&OversightSoftwareProjectPlanningRequirementsMgt.1初始的AdHocProcesses管理可视性管理可视性 过程能力过程能力12345TargetTargetTargetTargetTargetTime,C

150、ost,Probablility阶段性对流程的过程进行定量管理- 除1级外，每个成熟度等级均有若干个关键过程域。- KPA表明，这一级的组织应该从这些方面去改进软件过程。过程变更管理PCM技术变更管理TCM缺陷预防DP软件产品工程SPE集成软件管理ISM培训大纲TP组织过程定义OPD组织过程关注OPF软件配置管理SCM软件质量保证SQA软件子合同管理SSM软件项目追踪SPT软件项目策划SPP需求管理RM同行评审PR组间协调IC软件质量管理SQM定量过程管理QPM优化已管理5级级4级3级2已定义可重复初始规范化过程标准化过程可预测过程持续改进过程个别过程关键过程域关键过程域SEI统计结果统计结果

151、范围中值数据个数用于软件过程改进的开销$490-2004$13755每年软件劳动生产率的增长 9%-67%35%4每年缩减的软件产品上市时间15%-23%-2每年减少的软件错误比率10%-94%39%5成本回报率4.0-8.8:1 5.0:15为什么为什么CMM如此热门？如此热门？在美国它是选择软件供应商的强制标准对大型的，开发任务紧迫的公司来说，这是一个优秀的软件管理标准软件公司可以使用这个非常详细的准则来评估和改进软件开发流程完全使用CMM的话，有助于软件公司达到更好的性能和软件质量实施实施CMM过程中存在的问题？过程中存在的问题？实施CMM时，没有权威的标准。CMM的需求比较庞大，实施起

152、来需要较长的时间，同时费用较高。许多公司在6个月后或只是在实施较低级别的CMM后就放弃了。对于小公司和追求高效的公司过分地墨守陈规没有国际的认证机构，CMM审核是非常耗时的，频繁的和昂贵的。引入引入CMM的效果的效果摘自某通过了摘自某通过了3级评估的软件企业级评估的软件企业产品质量得到了提高千行代码的错误率减少了百分之30返工次数由过去的平均4次减少为一次（每项目）交货期缩短了预算得到了控制高级经理获得了对项目进展情况更好的了解管理的工作量加大了第一级初始级第一级初始级Justdoit;Overcommitmentischaricteristic;Succussdependsonheros,o

153、verandfire-fightingActivityResultsToproduce第二级可重复级第二级可重复级Planningbasedonexperience;Realisticcommitment;Processcandifferacrossprojects;Trackingofcost，scheduleandfunctionality；ActivityResultsToproducePlanningEvaluationInputtoToimproveThinkbeforeyouact,Andthinkafteryouact,justtomakesureyoudiditright.第三

154、级已定义级第三级已定义级Useyourlessonslearned;Standardsprocessisdocumentedandused;Agroupfororganizationprocessimprovement;UsetailoredversionofstandardprocessActivityResultsToproducePlanningEvaluationInputtoToimproveStandardsInputtoInputto第四级（定量）管理级第四级（定量）管理级Predicttheresultsyouneedandexpectedandthencreateopport

155、unitiestogetthoseresultsActivityResultsToproducePlanningEvaluationInputtoToimproveStandardsToforecastInputtoInputto第五级（不断）优化级第五级（不断）优化级Createlessonslearned,Anduselessonslearnedtocreatemorelessonslearned，Andusemorelessonslearnedtocreateevenmorelessonslearned,Anduseevenmorelessonslearnedtocreatemoreet

156、c.ActivityResultsToproducePlanningEvaluationInputtoToimproveStandardsToforecastInputtoInputtoToimproveCMM2RMPPPTSMCMQA活动约定能力衡量验证KPA目标公共特征关键实践内容安排内容安排CMM概貌CMM2级中软件项目管理的六大要素第一级别第一级别 机构普遍缺乏的方面机构普遍缺乏的方面很少制定项目规划没有至下而上的成本预算没有资源规划不切实际的承约较弱的项目管理甚至没有随机的目标和需求较差的计划表没有日复一日的跟踪没有同等的技术复审质量保证，配置管理没有连编或发布过程没有缺陷处理过程没

157、有原始资料控制管理突出的个人运作整个项目不是以团队的方式运行每个项目中重复开发许多过程经常破于进度安排尔放弃最佳实践当某些突出的个人离去时，项目很可能也中止了第一级别第一级别 机构示例机构示例世界上极大多数公司以第一级别进行运作由开发人员担任项目经理所有的一切都存在于开发人员的头脑之中或者是在他/她的机器里没有测试人员的职位，也没有同事测试人员如何摆脱第一级别？如何摆脱第一级别？微软的经验：以团队的方式工作，而不只是一组个人的凑合在团队成员里采用同等的模式进行角色训练和责任训练选择有力的领导并使之融入团队在从构想、计划、开发到稳定程序的整个开发生命周期中共用一个过程如何摆脱第一级别？如何摆脱第

158、一级别？微软的经验：形成一个所有成员共识的观点在写代码前先制定规格书增量计划的方式用以修正实行风险主导的计划实行版本发布逐渐增加功能和组件培养零缺陷的意识需求管理需求管理RequirementsManagement应对软件需求加以控制，以建立软件工程和管理活动的基线软件计划、软件产品和活动均与需求保持一致软件项目策划软件项目策划SoftwareProjectPlanning将对项目的估计写成文件，以供项目策划和跟踪使用项目的活动和承诺都应制定计划并形成文件项目相关的小组和人员都要对项目有关的承诺取得一致意见软件项目跟踪软件项目跟踪和监督和监督SoftwareProjectTrackingand

159、Oversight将计划实际取得的成果和计划实施情况与计划对照跟踪在计划执行中所得到的实际结果和执行情况与软件计划有较大偏离时，要采取纠正措施加以控制项目相关的小组和人员对承诺的变更取得一致意见关键过程域关键过程域目目 标标2级关键过程域的目标级关键过程域的目标软件子合同管理软件子合同管理SoftwareSubcontractManagement子合同双方对承诺取得一致意见主合同方对照承诺跟踪子合同方的实际取得的成果子合同双方保持通畅的通信对照承诺，主合同方跟踪子合同的实际工作情况软件质量保证软件质量保证SoftwareQualityAssurance要对软件质量保证活动制定计划软件产品和活动

160、对适用标准、规程和需求的遵循情况均应作客观的验证将软件质量保证活动和结果通知相关的组和人员未能在项目中解决的不符合要求的问题由高层管理人员处理软件配置管理软件配置管理SoftwareConfigurationManagement要对软件配置管理活动制定计划要对选定的软件工作产品给予标识、控制，并可利用对已标识的软件工作产品的变更应加以控制对相关的小组和个人通报软件基线的状态和内容关键过程域关键过程域目目 标标CMM L2CMM L2对软件开发的影响对软件开发的影响软件项目计划软件项目计划软件项目跟踪与监控软件项目跟踪与监控软件子合同管理软件子合同管理软件配置管理软件配置管理软件质量保证软件质量

161、保证需求管理需求管理返工返工出乎意料出乎意料中止承诺中止承诺对供应者失去控制对供应者失去控制不能支持产品维护不能支持产品维护不了解过程进行得如何不了解过程进行得如何对项目失去控制对项目失去控制不能交付产品不能交付产品CMM-2，The Repeatable LevelRMSPPSPTOSSMSCMSQAProductDevelopmentConfigurationLibararyHistorytSQ需求管理：要求需求管理：要求书面的完整的可行的一致的明确的可测的必要的（优先权）CR/TR/PR举例举例产品应在不少于60秒的正常周期提供状态信息。HTML分析器可以产生HTML标记错误报告，帮助H

162、TML入门者快速解决错误。HTML分析器可以产生一个错误报告，报告包含在分析文件中出错的HTML文本、行号，错误号等.需求管理：活动需求管理：活动在投入项目之前先评审被分配的需求被分配的需求是后续计划，产品，活动的基础对需求的改变要进行评审，并把这种改变也纳入到项目中 CMM关键实践关键实践 -RM微软的经验：观点描述(由产品经理，产品规划者或程序经理制定)功能规格书(由程序经理制定)测试规划(由测试领导者或测试人员制定)功能规格书及测试计划应做增量调整软件项目估算软件项目估算知识管理，知识库：项目描述，经验，教训，客户、行业项目估算的常见方法最大，最小，最可能值加权平均方法工具经验人知识库估

163、算方案软件项目计划：活动软件项目计划：活动软件工程组有成员参与项目计划组软件项目计划要与整体项目计划并行展开计划中的特殊约定要被高层经理评审要使用一定的软件生命周期模型软件项目计划的活动从一定的规程中得到，并且这种活动要文档化计划阶段使用里程碑来管理项目，提供项目的过程状态可视化根据文档化的规程来即软件项目的估算（包括对时间进度，成本，资源，瓶颈等的估算）计划中要界定和评估风险计划本身的数据和版本得到管理微软的经验微软的经验1.产品规划人员确定商业时机。2.产品规划人员、产品单元经理(PUM)和组产品经理(GPM)协同工作以提出更高层次的商业规划3.指定一个PM准备项目规划的草案，包括观点描述

164、、高层特性，推荐计划、里程标以及资源估算。4.PM主持PM、开发经理和测试经理之间的头脑风暴会议以讨论该草案。定下某些特性并将已定义为待解决问题(openissue)的行动项目分配给相关人员。5.在一次或多次头脑风暴会议以后，所有的待解决问题应当以解决了。PM们此时该制定一页(高层次的)规格书，包括定义了优先级的特性集，资源估算，计划评估和风险评估。6.高层管理人员将总结这些规格书并决定特性集以及里程标考察方法。项目追踪与监控项目追踪与监控（Project Tracking）Ifyoudonotknowwhereyouare,amapisuseless.项目追踪与监控项目追踪与监控:目标目标C

165、urrentprocessandresultsareperiodicallycomparedtotheplanning.当前实际过程和结果要同计划作定期的比较Ifprocessandresultsarediffersignificantlyfromtheplanning,correctiveactionsareidentifiedandcontrolled.若实际情况同计划有严重偏差，采用相应的受控行动Allamendmentsinplanningandagreementsaretalkedthroughandagreeduponbyallgroupsandpersonsinvolved（wi

166、thinaswellasoutsidetheorganization）所有对计划的修改要同所有相关人员沟通并取得共识项目追踪与监控项目追踪与监控:活动活动用文档化软件开发计划来追踪软件活动，沟通软件项目状态项目开发计划的修改依据文档化的规程对计划中涉及组织外部的约定（及约定改变）有高层经理的评审和批准软件约定的改变在经批准后同软件工程组、其他相关软件组有明确的沟通软件工程组进行正式的评审，以追踪项目的技术进展，计划，性能以及开发计划执行中遇到的问题要追踪和采取必要行动的有：开发规模，开发成本，关键（计算）资源，软件进度，软件工程技术活动，风险（包括技术，成本，资源和进度风险）项目追踪过程所评测

167、的数据（以及相应的计划修改数据）要被记录表明项目进展的正式评审在选定的里程碑点和选定阶段的起点终点进行微软的经验微软的经验PM主持每周的团队会议，在团队成员中交流项目的情况。PM撰写每周项目情况报告，并递交给上级经理、相关的外部组以及团队成员。PM主持每日的同测试组组长及开发组组长之间的缺陷(BUG)研讨会议，用以监督缺陷活动并控制这个过程。WarTeam应当有经常性的会议用以讨论热点问题。她可以作出对项目有较大影响的决定。软件子承包管理软件子承包管理（Subcontract management）Treattheworkofothers,asyouwouldyourown.软件子承包管理：目

168、标软件子承包管理：目标Theprimecontractorsselectsqualifiedsoftwaresubcontractors.挑选合格的软件承包商Theprimecontractorandsoftwaresubcontractoragreetotheircommitmentstoeachother.双方认同相互间约定Theprimecontractorandsoftwaresubcontractormaintainongoingcommunications双方保持不断沟通Theprimecontractortracksthesoftwaresubcontractorsactualr

169、esultsandperformanceagainstitscommitments.对承包商的实际结果和表现要根据约定进行追踪软件子承包管理：内容软件子承包管理：内容挑战标准能力匹配，标书应答，历史记录软件工程管理能力，人力资源可得性软件管理者的专业知识与行业经验地理位置，其他软硬件资源合同内容工作陈述，条款条件，甲乙方依赖关系待开发产品需求，最终交付的产品，产品修订条件验收规程，承包商评价规程标准甲乙方关系上下关系VS.伙伴关系过程VS.结果子承包管理子承包管理:活动活动对被外包的工作依据文档化规程进行定义和规划依据对各投标单位的能力评估来选择软件子承包商（乙方），并且该评估依据文档化的规程

170、来进行双方达成的合同协议是对乙方进行管理的基础乙方的文档化软件开发计划需经甲方评估和批准依据已经批准的文档化软件开发计划进行对乙方活动的追踪和状态沟通对乙方工作要求或双方合同条款（条件，约定）的更改依据文档化规程来进行子承包管理子承包管理:活动（续）活动（续）甲方会同乙方管理层对乙方进行定期评审对乙方进行定期的技术评审和人员交换对乙方项目进展的正式评审应在选定的里程碑点依据文档化规程来进行甲方的软件质量保证（QA）小组依据文档化规程监督乙方QA活动甲方的软件配置管理（CM）小组依据文档化规程监督乙方CM活动甲方依据文档化规程对乙方进行的接收测试是乙方最终交付的软件产品的一部分对乙方的表现进行定

171、期的评估，评估结果与乙方共同审核微软的经验样例微软的经验样例很少外包产品开发工作；只有少量的内部工具是外包的。许多局部工作包括培训课程设计、翻译、测试是外包的。产品经理监控外部的供应商，并经常通过电子邮件、经常性会议和访问方式进行联系。某些供应商被要求在微软公司内部工作，这样在项目的后期能有更好的控制。软件配置管理软件配置管理（Configuration Management）变更管理与版本控制软件配置管理：目标软件配置管理：目标Softwareconfigurationmanagementactivitiesareplanned.软件配置管理活动有计划Selectedsoftwarework

172、productsareidentified,controlledandavailable.选定的软件工作产品被标记，受控制，可访问Changestoidentifiedsoftwareworkproductsarecontrolled.对被标记的软件工作产品的更改受到控制Affectedgroupsandindividualsareinformedofthestatusandcontentofsoftwarebaselines.软件基线的状态和内容要告诉所有的相关人员软件配置管理软件配置管理:内容内容版本控制和变更控制完整性，可跟踪性Identify（全部对外的部分对外的）过程文档，需求文档，

173、设计文档代码，测试用例支撑工具（编译器）软件配置管理：活动软件配置管理：活动对每一个软件项目都要依据文档化规程准备一份SCM计划经批准的文档化SCM计划是进行SCM活动的基础建立一个配置管理库来储存软件基线要被纳入配置管理的软件工作产品需被标记对所有配置项/配置单元的更改请求和问题报告需依据文档化规程启动，记录，评审，批准，追踪基线更改依据文档化规程进行控制软件基线库中的产品创建和版本发布依据文档化规程来控制配置项/配置单元的状态依据文档化的规程来记录开发一套标准的报表来记载SCM活动和软件基线的内容，并确保相关成员能访问到这些报表依据文档化规程进行软件基线的审计微软的经验微软的经验所有微软的

174、项目都是用SLM或者SourceDepot来作为源代码控制和管理的系统。只有少数产品组使用VisualSourceSafe。所有的源代码改变都被记录下来并都是能够被修订的。任何的check-in都将产生通知电子邮件发送给团队里的所有成员。连编者或者连编团队将负责每天对源代码的连编和管理。每天开发者必须与源代码树进行同步，因此每个人都能同时参与大项目。软件质量保证（软件质量保证（SQA）Trustisgood，controllingisbetter.软件质量保证：目标软件质量保证：目标SQA活动有计划客观的验证软件产品和活动是否同已适用的标准，规程，需求相一致SQA活动和结果要通知到相关成员软件

175、项目内部解决不了的质量争议提交高层经理解决软件质量保证：计划软件质量保证：计划QAPlanQA职权，资源需求具体项目的QA活动参与计划规程的时间安排和经费待查的工作产品和工作活动问题的建档与跟踪问题的反馈的方法，频度软件质量保证：活动软件质量保证：活动依据文档化规程，为软件项目准备一份SQA计划SQA小组的活动与SQA计划相一致SQA小组参与软件计划，标准，规程的准备和评审SQA小组评审软件工程活动，以验证其一致性SQA小组定期向软件工程组通报其SQA活动的结果软件活动与软件工作产品中出现的非一致性现象依据文档化规程进行记录和处理SQA小组对其活动和发现定期评审，并可会同客户的SQA人员来进行

176、微软经验微软经验测试规划和测试样例应该是详细地符合功能规格书的。测试规划由测试人员制定，但由PMs和Devs复审。精确并迅速地控制缺陷。所有的这些行为将被记录在中央数据库中。完成完全测试，完全回馈测试和其它测试方法。为每个开发人员指派同事测试人员。每天进行压力测试软件项目成功软件项目成功6要素要素CMM-2 KPA目标目标RequirementMngr.接收,更改要评审后续一切要跟紧ProjectPlanning软件估计文档化活动约定有计划所涉成员接受它ProjectTracking对照结果比计划采取措施纠偏差更新计划问大家SubcontractMngr.合格才能被选中相互约定要认同自始至终常沟通按约监控和跟踪ConfigurationMngr.配管活动有计划配管产品有选拔配管变更要严格基线信息传大家QualityAssuranceQA活动有计划产品活动被检查检查结果要反馈解决不了上传达小结小结CMM1CMM-2实践与经验总结与经验容易被忽略的几个问题前车之鉴前车之鉴 容易被忽视的几个问题容易被忽视的几个问题问题尽早在上游解决关键功能宜早出现阶段性完成，控制风险用户参与有效估计控制变化，接受必要的变化把文档计入工作量估算