软件工程案例分析课件

《软件工程案例分析课件》由会员分享，可在线阅读，更多相关《软件工程案例分析课件（451页珍藏版）》请在装配图网上搜索。

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

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

3、前是不会回家”“死亡行军（Death March）”：用来描述其进度表几乎不可能完成的项目。“这是一个死亡行军项目，我希望自己不要参与进去”软件危机软件危机更准确的说法：慢性痛苦（chronic affliction)Suggested by Prof.Daniel Tiechrow,University of Michigan尽管忍受痛苦，但是软件依然在我们这个世界起着越来越重要的作用，但是如果能够医治痛苦，那么软件业将发展得更加健康。软件危机的主要特征软件危机的主要特征软件开发周期大大超过规定日期;软件开发成本严重超标;软件质量难于保证软件成功的标准软件成功的标准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）(85%)处理资源约束（83）与任务小组有效的

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

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

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

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

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

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

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

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.演化模型增量模型(Incremental Model)螺旋模型(Sprial Model)H.1 增量模型(递增模型)先完成一个系统子集的开发，再按同样的开发步骤增加功能(系统子集),如此递增下去直至满足全部系统需求。系统的总体设计在初始子集设计阶段就应作出设想。分析 设计 编码测试 分析 设计 编码测试 分析 设计 编码测试 分析 设计 编码测试 增量1增量2增量3增量n 增量1交付客户 增量2交付客户 增量3交付客户 增量n交付客户日历时间.H.1 增量模型风险分析工

24、程实施用户通信用户评估产品维护项目产品增强项目新产品开发项目概念开发项目计划建造及发布H.2 螺旋模型螺旋模型的优缺点优势：随着迭代的增加（成本的增加），风险程度随之降低缺陷：比较复杂，需要责任心，专注和管理方面的知识。H.3 WIN-WIN螺旋模型在螺旋模型中，通过与客户的通信获取客户的需求，实际上，客户的需求与最终确定的需求是不一致的，客户与开发者之间需要进行协商，最终达到双赢的局面。Boehm提出的WIN-WIN螺旋模型中，客户与开发者之间需要识别系统或子系统的关键stakeholders确定涉及者的“win conditions”对这些条件进行协商获得互赢条件WIN-WIN螺旋模型螺旋

25、模型WIN-WIN螺旋模型还引入了三个过程的里程碑，被称为定位点（Anchor points）生命周期目标（life cycle objectives）:定义每个主要活动的目标生命周期体系结构（life cycle architecture）:定义系统和软件的体系结构目标初步操作能力（initial operational capability）:定义软件安装，发布目标。I.并行开发模型并行开发模型（concurrent development model）又被称为并行工程（concurrent engineering）（By Davis and Sitaram）软件开发中的所有活动可能同时并

26、存同时并存，但是都处于不同状态中并行开发模型定义了活动从一个状态转化为另一个状态的事件并行开发模型并行开发模型NoneAwaiting changesUnder revisionUnder reviewBaselinedDoneUnder developmentAnalysis activity并行开发模型并行开发模型并行过程模型经常被用于开发C/S系统。该系统的活动可以被分为系统维和部件维。系统维:包含设计，装配和使用三个活动部件维:包含设计和实现两个活动并发性表现在两个方面：系统和部件的活动同时发生 各个部件可以并行设计和开发“基于版本发布”的特点V1.01.0功功能能时间时间V2.02.

27、0V1.11.1Trade-off Decision(折中决定)可可 靠靠 性性 发布日期发布日期 功功 能能 最优最优 约束范围约束范围可接受可接受正确的正确的Trade-off 决定决定J.面向对象模型喷泉模型(Fountain Model)可重用部件组装模型(构件集成模型 Component Integration Model)分析分析设计设计实现实现测试测试集成集成演化演化J.1 喷泉模型喷泉模型特点 主要用于支持面向对象开发过程体现了软件创建所固有的迭代和无间隙的特征J.2 可重用部件组装模型(构件集成模型)使用重用技术的软件工程模型构件(components)：可重用的软件成份可复

28、用性（Reusability）集成化软件开发环境（ISEE）用户通信计划产品开发及发布用户评估风险分析标志候选构件查找构件若存在则提取构件若不存在则构造构件进行下一次迭代将新构件存入库中可重用部件组装模型基于构件的软件工程(CBSE)过程模型 构 件 开 发分析 设计 编程 测试领域分析系统测试构件提交领域专家经验现有系统资料领域构件需求构件/构架库领域构架领域构件系统开发系统专用构件应用系统构件生产线领域构架领域构件问题域用户需求系统生产线 系 统 组 装 分析 设计 编程构架细化专 用 构 件 开 发分析 设计 编程 测试 软件生产线应用构件提取车间构件生产车间标准规范 与 质量保证1基础

29、构件，2功能构件 3接口构件，4用户界面构件 应用构件库 构件库组装车间领域 1领域 2应用系统.1 12 23 34 4 转换模型(Transformational Model)净室模型(Cleanroom Model)K.形式化方法模型K.1 转换模型形式化规格说明与需求比较后修正形式化开发记录变换n变换2变换1测试系统需求目标系统形式化规格语言及其变换技术基于模型的规格说明及其变换技术基于代数结构及其变换技术基于时序逻辑的规格说明和验证技术基于可视形式化技术K.2 净室模型(形式化的增量开发模型)基于思想：力求在分析和设计阶段就消除错误，确保正确，然后在无缺陷或“洁净”的状态下实现软件的

30、制作。三个关键技术 置于统计过程控制之下的增量开发 基于函数的规范、设计、验证 统计测试和软件认证 净室模型盒结构盒结构规约规约需求需求收集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计划测试计划统计性统计性使用测使用测试试验证验证增量#1盒结构盒结构规约规约需求需求收集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计划测试计划统计性统计性使用测使用测试试验证验证增量#2盒结构盒结构规约规约需求需求收集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计划测试计划统计性统计性使用测使用测试试验证验证增量#1.L.阶段交付阶段交付阶段交付持续地

31、在确定的阶段向用户展示软件。和渐进原型不同，在阶段交付的时候，你明确地知道下一步要完成什么工作。阶段交付的特点是不会在项目结束的时候一下交付全部软件，而是在项目整个开发过程中持续不断地交付阶段性成果。阶段交付阶段交付软件概念需求分析构架设计阶段1：详细设计，编码，调试，阶段2：详细设计，编码，调试，阶段交付的优缺点阶段交付的优缺点优点：项目结束交付全部成果前，分阶段将有用的功能交付给用户。缺点：如果管理层面和技术层面上缺乏仔细规划，工作就无法进行。使用阶段交付的注意点：必须确定每一阶段的交付是对用户有用的 必须确保考虑了不同产品组成部分的技术依赖关系M.面向进度的设计面向进度的设计类似于阶段交

32、付，但是面向进度的设计生命周期模型在开始的时候不必知道究竟能达到何目标，但是要确保最后的期限期限。该模型的关键是要按优先级别划分系统特按优先级别划分系统特性并规划开发阶段性并规划开发阶段，保证前面的阶段具有高优先级的特性，低特性具有低优先级别。是否采用这种方法决定于你是否对系统目标具有足够的信心，如果有信心，则没必要采用这种方法。N.渐进交付渐进交付渐进交付是一种跨越了渐进原型和阶段交付两种模型的过程模型。基本过程：开发一个产品的版本，展示给用户，根据反馈改善产品。如果计划满足用户的绝大部分需求，渐进交付与渐进原型差不多，如果计划满足少量的需求，渐进交付就和阶段交付差不多。渐进原型，强调的是系

33、统看得见的样子，再回来堵漏洞，渐进交付中，最初的重点是系统核心和底层系统功能。渐进交付渐进交付软件概念需求分析构架和内核设计开发一个版本并入用户反馈交付该版本开发一个版本交付最终版本确定渐进交付目标的一种方法确定渐进交付目标的一种方法价值成本比软件开发方法 软件开发过程遵循的方法和步骤 几种典型的开发方法：模块化方法（modular method）结构化方法 面向数据结构方法 面向对象方法软件开发需要项目管理软件开发需要项目管理软件开发是个系统工程需要资源的协调软件开发过程的选择与项目的协调紧密相关项目管理、工具、技术、流程与组织主要内容主要内容回顾 软件项目实施的方法选择 软件开发过程模型的

34、选择 软件开发方法项目管理 项目管理基本概念 实施项目管理的工具与技术 项目管理的流程 项目管理的流程特征（产品项目软件项目）项目管理组织结构 软件项目管理的流程为什么项目会失败为什么项目会失败?People 项目成功的最重要因素Product 建立的软件Process 框架活动集合和得到工作的软件工程任务Project 实现产品所需要的所有工作The 4 Ps软件梯队软件梯队被解决问题的难易程度代码和功能点形成的结果程序的规模梯队的生存周期问题被模块化的程度被建立系统所需要的质量和可靠性发布日期的严格性项目的社会化程度（沟通程度）选择软件项目梯队结构所要考虑的因素选择软件项目梯队结构所要考虑

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

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

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

38、目包含的活动需求分析描述设计编码校验安装维护支持应用项目管理方法开展软件开发应用项目管理方法开展软件开发项目的可行性分析需求开发与需求管理软件项目工作量估算软件项目计划与资源分配软件项目监控风险管理软件质量管理与软件开发规范软件项目中的人员管理软件配置管理项目可行性分析与评估内容安排内容安排可行性分析的内容项目范围管理技术评估经济评估风险评估可行性报告项目建议书需求建议书可行性分析可行性分析目的GPS监控系统的投资失误 做什么？近期目标？人员配备，怎样整合 需求调研问题 开发费用问题 风险规避顶新国际集团：在投资新产品时 1400万：全国28个城镇居民消费习惯调查 700 万：委托28个城镇社

39、会科学院进行全国七大区域总体经济投资环境的分析“什么都不做”永远是一个可考虑的方案可行性分析的内容可行性分析的内容项目范围策略评估技术评估经济评估风险评估项目范围管理内容项目范围管理内容保证项目包括并且仅仅包括需要包括的内容。它由以下步骤组成：初始化：对项目或阶段授权 范围计划：开发一个作为将来项目决策基础的书面的范围声明 范围定义：将项目交付物细分为更小的，更易管理的元件 范围校验：形式化项目范围的接受条件 范围变更控制：控制项目范围的变更范围的含义范围的含义“范围”包含产品范围和项目范围 产品范围：产品或服务的特点和功能 项目范围：为了生产具有特定特点和功能的产品所需要的工作软件范围软件范

40、围软件项目计划的第一项任务就是确定软件的工作范围，即软件的用途及对软件的要求。因此，应从管理角度和技术角度出发，确定明确的可理解的软件项目范围。软件范围的叙述软件范围的叙述明确给出定量的数据（例如，同时使用该软件的用户数目，发送表格的长短，最大允许响应时间等）指明约束条件和/或限制（例如，产品成本限制了存储的容量）叙述某些质量因素（例如，给出的算法是否容易理解、是否使用Ada语言等）软件范围的估计软件范围的估计软件范围包括功能、性能、限制、接口和可靠性。功能：软件功能评价，并进行适当细化 功能分解，满足未来成本和进度估算要求 性能 包括处理和响应时间的需求。约束条件：外部硬件、可用存储或其他现

41、有系统对软件限制。功能、性能和约束必须在一起进行评价。当性能限制不同时，为实现同样的功能，开发工作量可能相差一个数量级。如果功能保持相同而性能可变，则开发软件所需的工作量和成本将有显著的差异。价值驱动的电子商务分析方法价值驱动的电子商务分析方法业务流程模型业务概念模型策略规划级结构级实施级电子商务技术层 业务策略的概念结构概念建模协商建模价值驱动流程建模资源价值配置伙伴网络价值链构架信息策略发布渠道客户信任客户关系企业能力价值建议目标客户产品与服务创新Revenue Model价值结构收入模型收益/损失资产、财务电子商务概念模型电子商务概念模型初始化初始化初始化(Initiation)正式授权

42、一个新项目或者决定一个已有项目继续进行下一阶段项目是由于下面一些原因产生的：市场需要（新性能汽车）业务需要（培训中心新课程设计）客户需要（客户定制产品）技术进步（如计算机技术进步）法规需要（污染处理）社会需要（政府水处理系统）初始化初始化输入：产品描述 策略计划：企业的战略计划 项目选择准则（经济回报，市场回报，公共形象）历史信息：以前项目的结果和性能工具和技术 项目选择方法 专家判断输出：项目章程（授权项目的正式文档，包括业务需求，产品描述）项目经理指派 约束 假设范围计划范围计划范围计划是将生成产品的项目工作（项目范围）逐步细化的过程。输入：产品描述项目章程约束假设工具和技术产品分析利益成

43、本分析(Benefit/Cost Analysis)备选方案（brainstorming or lateral thinking)专家判断范围计划范围计划输出范围声明（Scope Statement)，包括 项目理由：Project Justification(Business need)项目产品:概述 项目交付物：project deliverables 项目目标:判断项目是否成功的定量准则支持细节（包括假设和约束）范围管理计划范围定义范围定义范围定义涉及到将主要的项目交付物细分以：提高成本，周期和资源估计的准确性 定义性能度量和控制的基线 便于清晰定义责任分配 范围定义正确与否将影响项目的

44、节奏，进度，生产率和项目人员的士气。范围定义范围定义输入范围声明约束假设其它计划输出历史信息工具和技术WBS(Work breakdown structure)模板分解技术策略评估中的模块管理策略评估中的模块管理模块管理（Programm management)“模块是一组协调管理的项目，通过将项目组成模块，将获得比单个管理项目更大的效益。”D.C.Ferns有效的模块管理需要有一个模块目标，项目必须根据模块目标来选择在大的组织中，将可能有模块管理的机构，例如模块主管或者模块经理即使没有专门的组织来管理模块，项目的选择也需要根据组织的整个业务目标来评价策略评估的内容策略评估的内容目标：提出的系

45、统对组织目标具有怎样的贡献？例如它是否能够增加市场份额？IS计划：提出的系统如何与IS计划相适应？它将替换或者与那些系统接口？它与将来开发的系统有何交互关系？组织结构：新系统对目前的部门和组织结构有何影响？例如一个新的订单处理系统是否与目前的销售与库存控制的功能相重叠？MIS:系统将在组织的何层次上提供何种信息？它将以何种方式对现存管理信息系统进行补充何提高？人员：系统将以何种方式影响人力水平何现存雇员的技术？它对组织整个人员开发策略有何影响？情形：系统将使客户对组织的态度有何变化？是否采用一个自动化的系统将与提供友好的服务相冲突？策略评估中的业务管理策略评估中的业务管理业务管理 选定的项目将

46、成为业务的一部分，项目将对资源产生竞争 竞争中对业务的调整是必要的技术评估技术评估技术的成熟程度实验室技术经过中试的技术已经工业化应用的技术市场需求 显在 潜在：转化为显在的条件 竞争态势：与竞争技术相比，所采用技术的优势及缺陷技术转换成本支撑体系与条件：原料、销售网络、用户体系、政策技术发展趋势及所采用技术的发展前景技术方案选择技术方案选择要考虑的制约条件需求制约：现存的需求结构及需求结构可能的变化资源制约：资金、人力资源、自然资源、其它要素环境制约：经济技术环境、社会文化环境、自然环境选择原则经济性原则：以最小的投入取得最好的效果发展原则：发展的前景及适应发展的能力兼容性原则：与原有经济、

47、技术、环境、社会的兼容性相关效果原则：相关的经济、技术、环境、社会效果选择视角技术先进性技术适用性经济分析经济分析开发所需要的成本和系统运行所需要的成本与得到的效益的比较 识别出项目进行中所需要的所有成本和效益并对其进行聚集 将成本和效益用单元来表达成本分为 开发成本 安装成本 运行成本经济分析经济分析效益 直接效益 可见的间接效益 不可见的效益经济分析经济分析净收益（Net Profit):项目的净收益是在项目生命周期内总的收入与总的成本的差。没有考虑时间因素回收期限（Payback Period）：将初始投资收回的期限忽略了整个项目的盈利空间经济分析经济分析投资回报(Return on i

48、nvestment):也被称为回报率(accounting rate of return)(ARR)ROI=（平均年收益/总投资）100例如项目1：ROI=10,000/100,000*100=10%缺点：没有考虑时间因素该回报率易与银行利率混淆经济分析经济分析净现率(Net Present Value)考虑了时间因素对将来的收益打一个折扣“拿在手里的钱才是真正的钱”如果假定年折扣率为10，那么明年的100元等于现在手中的91元，后年的100元等于现在的83元目前值t年的值/(1+r)t1.系统开发费用（一次）人员：.2名系统分析员(450小时/名,45美元/小时)$40,500.5名系统开发

49、人员(275小时/名,36美元/小时)$49,500.1名数据通讯专家(60小时/名,42美元/小时)$2,400.1名数据库管理员(30小时/名,42美元/小时)$1,260.2名技术写作者(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,0

50、00l网络软件$17,500l20台工作站办公软件产品$20,000系统开发总费用$161,670l维护程序员/分析员(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)编写可行性研究报告，送审可行性分析可行性分析可行性分析报告的格式可行性研究报

51、告的编写提示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.6 技术条件方面的可行性可行性研究报告的编写提示5 可选择的其

52、它系统方案 5.1 可选择的其它系统1 5.2 可选择的其它系统2 .6 投资及收益分析 6.1 支出 6.2 收益 6.3 收益/投资比 6.4 投资回收周期 6.5 敏感性分析可行性研究报告的编写提示项目建议书项目建议书起源：组织内部认识到需要利用信息技术 改进目前的业务运行 改进目前的信息系统 开发新的产品目的：使管理层能够作出项目决策准备招标书准备招标书目的：从客户的角度全面地、详细的论述，为了达成确定的需求应需要作何准备一份招标书应当是全面的，能提供足够详细的信息，以使承约商或项目团队能针对顾客的需要相应地准备一份最优的招标书招标书招标书招标书中需要提供工作表述招标书中必须包括客户要

53、求，此要求中规定了规格和特征招标书应当说明客户期望承约商或项目团队提供什么样的交付物招标书中应当列举客户供应条款招标书中可以表述出客户对需要的确认招标书中可以提到客户想要用的合同类型招标书招标书表述出客户想用的付款方式表述出项目完成所需的进度计划提供有关承约商申请书的格式和内容安排支持客户希望潜在承约商提交申请书的最后期限可能包括评价标准可能会指出客户所拥有的可用于此项目的资金量。案例分析案例分析宁波市第五次全国人口普查办公室的宁波市人口地理信息系统 地理空间分析、人口统计与分析一体化 宁波人口普查、日常管理、统计与分析的数字化、可视化 人口信息存储、管理与分析，建立规范化的空间地理信息与人口

54、信息统一管理、分析、统计、发布、录入、更新与维护 对空间数据和人口数据的快速采集、建库、维护、查询、管理、显示、输出、统计分析、共享与发布功能案例分析案例分析性能要求 满足宁波全部市县人口的数据存储 不同县区都可以调用数据，操作数据 保证调查高峰操作响应的人机交互 保证数据统计的响应时间案例分析案例分析限制要求 Windows平台客户端 服务器选用Intel服务器 存储RAID，保证存储安全 与DOMINO办公系统可以实现接口，可以抽取数据报表需求开发与需求管理主要内容主要内容从一个故事看软件开发的实际问题需求管理的困难性管理需求的目的软件需求特性需求工程如何获取需求需求规格说明需求管理工具软

55、件开发面临的实际问题软件开发面临的实际问题软件开发面临的实际问题软件开发面临的实际问题软件开发面临的实际问题软件开发面临的实际问题为什么？为什么？需求？什么是需求什么是需求需求为用户解决问题或达到目标所需的条件或权能系统或系统部件要满足合同、标准、规范和其它正式规定文档所需具有的条件或权能一种反映上述条件或权能的文档说明举例举例系统必须提供基于PPPoE协议的用户接入模式产品应当提供机架式安装，并提供两个千兆以太网端口系统使用的用户是信息中心和网络管理员系统在运行时必须提供自动数据备份功能简要的解释简要的解释需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整文档，该文档详细地说明

56、了产品“必须或应当”做什么。如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。需求管理的困难性需求管理的困难性需求不总是显而易见的，而且它可来自各个方面。需求并不总是能容易用文字明白无误地表达。存在不同种类的需求，其详细程度各不相同。如果不加以控制，需求的数量将难以管理。需求之间相互关联，而且需求也和软件工程流程中的其他可交付工件有关。需求有唯一的特征或特征值。例如，它们的重要性和容易满足的程度都各不相同。需求涉及众多相关方面，这意味着需求要由功能交叉的各组人员管理。需求会变更。为什么要管理需求为什么要管理需求？避免失败就是一个很充分的理由。提高项目的成功率需求管理

57、带来其他好处Standish Group 的 CHAOS 报告进一步证实了与成功项目关系最大的因素是良好的需求管理。什么是软件需求什么是软件需求从软件开发过程看软件需求开发从软件发展周期看软件开发过程从软件发展周期看软件开发过程时期年代阶段涉及注重主要使用语言标准模型初期50-60程序设计点编程技巧ALGOLFORTRANCOBOLBASIC 中期70-80软件开发线结构化模块化PASCALGB8566软件开发规范瀑布原型现代90-软件过程面过程能力C,C+JAVAVB、VCISO/IEC12207软件生存期过程ISO9000螺旋CMM计算机系统 人员硬件软件数据传输机构执行机构（剧作家、导演

58、）（舞台剧本演员道具）软件开发全过程软件开发全过程活动任务 系统需求分析系统结构设计 软件需求分析建立软件需求评价软件需求联合评审软件结构设计软件详细设计软件编码和测试 软件集成 软件鉴定测试系统集成系统鉴定测试软件安装软件验收支持 软件开发过程软件开发过程 定义（IEEE-STD-610）用户为解决某个问题、或为实现某一目标，要求软件必须满足的条件或能力。软件需求的三个层次 业务需求 用户需求 功能需求和非功能需求 软件需求的层次性软件需求的层次性软件系统需求(1)系统需求分配软件工程组硬件系统需求(2)其它成分系统需求(n)软件需求客户最终用户系统工程组系统需求分配系统需求分配业务需求业务

59、说明使用实例用户需求功能需求约束条件非功能需求软 件 需 求 规 格 说 明软件需求的层次软件需求的层次需求的层次性需求的层次性业务需求项目视图与范围文档用户需求质量属性系统需求功能需求约束条件其它非功能需求Use Case文档软件需求规格说明非功能需求 过程需求：交付需求，实现需求，遵循的标准性能需求：速度，容量，可靠性外部需求：互操作性，伦理性，机密性，安全性，使用要求 非功能非功能软件需求软件需求系 统 需 求ACCS应能使汽车保持在预期车速的2KMH范围内行驶分配给硬件的需求硬件应能使车速在规定的精确度1.5KMH范围内分配给软件的需求软件应能在车速超出预期车速0.5KMH时给硬件加/

60、减速命令软 件 需 求软件应能：读入当前车速值计算当前车速与预期车速之差若差值0.5KMH给出加/减速命令汽车限速系统ACCS的需求分配分配需求的实例分配需求的实例产生不合格需求的原因产生不合格需求的原因产生不合格的需求说明的原因 无足够的用户参与，原因 感到与用户合作不如编写代码有意思 因为开发人员觉得已经明白用户的需求了 用户需求的不断增加 模棱两可的需求 不必要的特性 过于精简的规格说明 忽略了用户分类 不准确的计划优秀需求具有的特性优秀需求具有的特性正确性无二义性必要性完整性，完备性可行性，可实现性可验证性划分优先级制定目标的原则制定目标的原则SMART Special,Measure

61、,Agree,Realistic,Time 特指,可量测,一致认同感,现实的,实在的,时间需求工程需求工程什么是需求工程把所有与需求直接相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工程的结构图1需求工程需求开发需求管理 获取需求分析需求定义需求验证需求需求变更控制需求跟踪需求状态跟踪需求文档版本控制需求开发需求管理需求工程需求工程的构成需求工程的构成需求开发过程需求开发过程需求开发：通过调查与分析，获取用户需求并定义产品需求。需求调查：通过各种途径获取用户需求信息（原始材料），产生用户需求说明书。需求分析：对各种需求信息进行分析，消除错误，

62、刻画细节。常见分析方法“问答分析法”和“建模分析法”两类。需求定义：根据需求调查和需求分析结果，进一步定义准确无误的产品需求，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计工作。需求管理过程需求管理过程需求管理：在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求确认：开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。需求跟踪：通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。需求变更控制：依据“变更申请审批更改重新确认”的流

63、程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。用户/系统市场管理者初始需求变更的需求获取,分析,定义,验证需求控制需求变更需求规格说明项目环境需求开发需求管理（1）获取需求确定目标用户、服务对象明确用户代表用户培训了解实际业务和业务需求（2）分析需求分清功能需求、性能需求、使用需求必要性可行性需求开发需求开发（3）定义需求编写软件需求规格说明（SRS）作用要求：完整、正确、可行、无歧意、可验证形式：图、表、文字（4）验证需求联合评审 需求开发需求开发需求获取需求获取需求的来源 与有潜力用户探讨 目前或竞争产品的描述文档 系统需求规格说明 当前系统问题报告和增强要求 市场调查和用户问

64、卷调查 观察正在工作的用户 用户任务内容分析 需求开发实例需求开发实例对用户有效管理，防止不合法占用网络资源造成收入流失协助运营公司或部门管理网络和用户向用户提供有效接入服务，满足用户多元化需求政府部门（信产部、公安部等）对运营商及其管理的要求以城市为基本管理单位，分层分级管理，全程全网管理和运营以汇聚点为单位逐步部署（切换）用户使用方便（“首次认证”方案）宽带接入系统目标构架需求分配构架需求分配系 统 需 求宽带接入（交换式以太网构造）身份认证，计费策略，网络安全，访问监测，接入服务，用户管理分配给硬件的需求交换机，PPPoE接入，访问控制设备，认证与安全服务器，网络构架，流量控制分配给软件

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

66、交换机AC用户用户用户用户用户用户用户管理机制用户管理机制用户端口隔离用户基本信息（ID-Addr-Mac-IP）用户身份认证（ID-Password）用户访问信息（IP-Sock-Time-Len）IDIPAddrMacTimeSock体系构架体系构架总部区域城市社区收费管理用户信息用户接入服务系统社区网络管理系统用户信息用户信息客户服务收费管理计费管理开户交费投诉上网欠费补交销户计费管理计费管理客户服务网络管理网络管理网络管理收费管理平台支撑平台支撑总部区域和城市汇聚和社区客户管理系统客户管理系统计费管理系统计费管理系统流量流量监测监测系统系统网络管理系统网络管理系统接入控制接入控制系统系统ERP系统的协作关系系统的协作关系计费管理系统计费管理系统客户管理系统客户管理系统接入控制系统接入控制系统网络管理系统网络管理系统流量监测系统流量监测系统账单账单收费收费计时计时用户用户流量流量监测监测开关开关主要功能主要功能用户认证及其管理（首次认证）接入服务（DHCP、MAC-IP捆绑，ID-Sock）不合法用户和访问操作的监测与控制多样化计费操作和管理 按时间计费（以后扩展按流量、带宽计费