CMMI课堂笔记整理
课堂笔记整理（15.4.25-4.26）
字体颜色说明：
红色：标题
紫色：是我觉得的重点强调的地方
黑色：一般叙述
课程名称：
CMMI（Capability Maturity Model Integration，能力成熟度模型集成）
任课教师：
荣国平老师
新浪微博、博客：“@只言片语说软件”
推荐书目：《人月神话》，《人件》（老师上课的时候经常引用其中的话）
上课风格（个人观点）：经常会有一些比较开放的思考性问题，个人觉得其实也没有绝对的正确答案，主要是体验一种思考的过程并获取一些启发，有些观点也不是很赞同。还会穿插一些其它学科的知识，让我感到自身知识是多么的匮乏…
相关背景：
上世纪80年代初，美国国防部等政府机构在将一些项目外包时，发现选择承包的公司是一件很复杂的事情，所以就希望弄一个评价标准。于是就委托位于匹兹堡的卡内基梅隆大学（CMU，学校的相关专业很厉害），其成立了软件工程学院（SEI）来进行研究。领头的是Watt Humphrey（从IBM辞职而来，具有很丰富的专业经验），其聚集了不少专家进行研究探讨。总结了大概一百多条标准，开始的时候是做了一个调查问卷，后来逐渐转变为CMM（能力成熟度模型）。而CMMI算是对于CMM的继承。需要注意的是，CMMI的构建Humphrey 并没有在其中，据老师说因为他意识到即便有这么个玩意儿也不能从根本上解决遇到的问题，所以其将研究精力转向了其它方面。具体相关的如果大家感兴趣的可以去搜索些深入阅读材料。
课堂构架：
老师上课的思路感觉还是蛮清晰的，我大概说下一个大框架。
1.一个模型
2.两种表现形式
3.三种应用领域
4.四种类型
5.五个级别
一个模型：就是指能力成熟度模型，老师说他觉得这是软件工程领域很少见的做的相当完美的一项研究。（还记得背景中提到的Humphrey 拉了一帮人一起探讨列条目么？这列出来的一百多条内容里，在日后的这么些年里被实践证明仅有十几条是他们并未想到的。）其本质是刻画一个软件公司从不成熟到成熟的路线图。（而不是一般人所认为的CMMI就是一堆材料）
在这里老师提出了几个问题来帮助认知
我就直接写结论了…
1 CMMI是一个不需要裁减的模型，其本身是完整的。
2敏捷开发和CMMI并非是对立面关系。敏捷指的是一种开发方法，而CMMI是一种模型。
两种表现形式：即连续式和阶段式
连续式是反应一个软件公司的能力水平，阶段式则是反应其成熟度水平。
这里老师也做了一些具体的说明，所谓连续式可以理解为做的好与不好，而阶段式则可以理解为做了还是没做。
其中阶段式所反应的成熟度水平拥有5个级别的划分，而可以把连续式看作是第六个级别。这里老师表达了自己的观点，他觉得这些东西
不能太过于绝对化，比如Google公司，它是没有CMMI级别的，但谁都知道这是一家好公司。而一个只做2级的公司有时候要好于3级的，可以理解为是它的性价比比较低，说明是脚踏实地做事的。（这里没有必要太过钻牛角尖，主要是想传达一个思想，CMMI说到底也只是一个相对的评判标准，不可以说的太绝对。就好像评价一个人，不是用好和坏这么简单就可以定义的。）
还有一点老师想阐述的是这种评估是过程改进的起点，而不是终点。不是说公司评到了5级就好像任务完成，什么都不去追求了。这种评估只是一种辅助手段，最终目的不在于此。
三种应用领域：
开发（CMMI for Development,CMMI-DEV）
服务（CMMI for Service,CMMI-SVC）
采购(CMMI for Acquisition,CMMI-ACQ)
这三个领域共享16个核心过程域，同时每个领域自己特有的一些过程域。
在这里老师还谈了谈所谓管理，如何才算管理呢？首先就必须要有一个目标，如果没有目标，就不会出现偏差。因为没有和实际的一个参照物。而管理就是对这个目标的跟进和对目标的补救。
对于过程域，或者说很多的联系，是一种相关性的，而不是因果关系。就是说这些的联系不是上下级或者太过于紧密的关系。
四种类型：
对于这些过程域要进行分类
分为项目管理、过程管理、工程类、支持类
单个过程域属于唯一的一个类型，比如不会出现一个过程域既是项目管理的又是过程管理的。
这里有个题外内容：老师推荐看一看Google编码规范和代码评审的相关博文。这个和考试的关系肯定是没什么的，老师也强调了一点，就是希望通过上课学到一些东西，哪怕是听说几个新鲜的名词，反正是应该有所收获的，而不是以对付考试为目的。
五个级别：
这个好像就是CMMI评审的那5个级别了，即阶段式所反应的成熟度水平。
需要注意的是老师说这里的5个级别和CMM中的是有所区别的，在以后自己阅读一些相关材料的时候要注意这一点，以免晕掉…
第一个级别：原始级（所有的公司都默认是这个级别）Initial
特点：个人英雄主义，一般团队里有个Superstar，他会左右项目的进展甚至是成功还是失败。开发过程通常随意且混乱。
第二个级别：已管理Managed
特点：这时候项目已经拥有了跟踪，确保整个过程按照方针得到计划与执行。
第三个级别：已定义Defined
特点：核心是共享，过程得到了清晰的说明与理解，并以标准、规程工具与方法的形式进行描述。
第四个级别：已量化的管理Quantitatively Managed
特点：就是量化…老师在这里谈的挺多，主要是因为现实和理想之间存在差距，导致矛盾的存在。说白一些，就是这个量化到底是不是好呢？很难说也很难做到一种完美的量化方法。
第五个级别：优化中Optimizing
特点：从英文表述可以看出，上面几个都是ed形式，而这个是ing，即为无止境的。
这里老师说了一个观点，就是所有的4级、5级的公司基本都是做的数据，再直白点就是造假。因为真实的数据无法体现一种变化关系，但要评级必须…咳咳，就是这样，大家应该都懂的…但是这并非是一味的好或者坏，要辩证看待。比如量化这个东西，它不能完全没有也不能太死板，就是没有一个完美的标准，看个人意识了。基本老师就这么个意思，所以还需要继续研究和探索，大家也不能妄自菲薄，
认为前途很黑暗。
这里老师还阐述了一下软件工程与传统行业的差异表现在哪里，最核心的就是传统行业生产每件东西都是一样的，是重复性的。而软件不一样，每一件都是新的。所以说软件开发是个很困难很复杂的事情，所以我们都很不容易~~
这就是一个大概的体系架构，希望大家可以比较清晰些，不会太晕菜，具体的东西再看看那些PDF。老师说有几个比较重要的东西，一个是过程域的结构，具体就是CMMI Slides这个PDF文档中的Process Area Components这张图，大家仔细看看。另一个是老师在黑板上画的一张表格。
接下来老师就是具体讲述表格中的每个过程域了，目前讲了的有PP、PMC、SAM（这个没有讲，老师说如果有时间再讲）、CM、MA、PPQA、RD、TS、PI
我个人觉得没有必要太过于扣那些细节，除非要去实践的时候，不然开始就这么干的话没有一些毅力基本会晕菜…老师在介绍这些具体过程域的时候也是以一种探讨的方式，而不是单纯的讲述概念。
比如PP这个过程域，就是项目计划，这里谈到了估算问题，老
师其实没有过多说什么具体的估算方法，毕竟时间也不允许。但老师表达了一个想法，估算的具体方法不是最重要的，而是在于让所有的团队里的人相信这个具体的方案是可行的。
又比如PMC这个过程域，就是项目监控。项目监控是必须的，也是有价值的，但出现偏差时，不能鲁莽地去补救，因为导致偏差的原因有很多，要具体去分析。
课上老师还介绍很多，但都比较琐碎。
比如老师说了一个词语：技术负债，他希望我们能够自己去搜索一下这个概念并且有所收获。
比如谈到配置管理的时候，老师说一般有3部分，工作库（基本的东西都可以包含其中）、配置库（稳定版本）这里的东西是不允许随意变更的，但不是不可以变更，需要有一套流程。还有就是产品库。说实话，这里我不是很懂…如果有人能阐述清楚的话，就适当修改一下哈~老师还说代码进入配置库的的节点时在单元测试结束。
比如老师还谈到了语言的问题，bug和defect翻译成中文都是缺陷，但其实在英文中这两个是有区别的，bug是可预知结果的，而defect则是不可预知的错误。
比如老师还说软件工程往往是一种权衡，而不是一种科学。
比如老师还谈论了测试这个职位，他的观点是测试是编码规范的执行者，但产品质量的保障其实并不等于测试的职责。测试在整个循
环改进中是个重要角色，但他不是万能的。
比如老师还说客户需求和产品需求是两个不同的概念，客户需求是用户所需要的使用价值，是用户面临的问题。而产品需求则是根据客户需求所产生的解决方案，乍一看有点晕，仔细想想区别还是蛮明显的哈。老师还说和用户最好只讨论具体问题而不涉及系统，因为当你给用户建立了系统的概念以后，也许需求就需要全部改，也就是大侠重新来过……
比如老师还说有时候太多名词并不是一件好事情，因为软件开发本身已足够复杂，再弄一堆复杂的东西会让人疯掉的…
比如老师还说一个缺陷在开发过程中存在的时间越长，解决的代价越大，且增长不是线性的，有可能是指数级的。
还有很多很多，就不赘述了。
而我个人的感受是老师在课堂上阐述的最多的是一种辩证的观念，就以CMMI为例，它本身就个完美的模型，而每一个过程域所阐述的则是最佳方案（理想方案），但实际操作起来确实是很难达到的。比如老师说评审消除缺陷的平均代价是最低的，大家也知道，但是却很少有人能严格地执行评审制度。我们更多的是寻找一种平衡，一种自己和团队认可的东西。
最后总结一下：软件开发很复杂，大家活的很不容易，多看些书接受点新思想多一点思考不一定立马有用但一定是有益的，矛盾是没法消除的，而考试却是不会很难的，就这样。
PS：我是坐在后排的，而且限于各方面条件和自身水平，这只能提供一个参考，要有什么地方有问题，欢迎大家提出来一起交流，也可以直接在这个上面完善和修改~~
李博洋
cmmi软件生产过程标准
何谓CMM? CMM是由美国卡内基-梅隆大学的软件工程研究所(SEI)推出的评估软件能力与成熟度的一套模型。它侧重于软件过程开发的管理及软件工程能力的改进与评估，是目前国际上最流行、比较实用的一种软件生产过程标准，成为当今企业从事规模软件生产不可缺少的一项内容。CMM模型共分为五个级别：初始级、可重复级、定义级、管理级和优化级。 软件工程：什么是CMMI? CMMI全称是Capability Maturity Model Integration, 即软件能力成熟度模型集成模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。CMMI是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进 CMMI分为五个等级，二十五个过程区域（PA）（如图所示）。 1．初始级软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。 2．已管理级建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。 3．已定义级已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 4．量化管理级分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。5．优化管理级过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。 每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性： 每个等级都有几个过程区域组成，这几个过程域共同形成一种软件过程能力。每个过程域，都有一些特殊目标和通用目标，通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施，就能实现该过程域的目标。 CMMI的原则、目标和方法 一、CMMI的原则： 1．强调高层管理者的支持。过程改进往往也是由高层管理者认识和提出的，大力度的、一致的支持是过程改进的关键。 2．仔细确定改进目标，首先应该对给定时间内的所能完成的改进目标进行正确的估计和定义并制定计划。选择能够达到的目标和能够看到对组织的效益。 3．选择最佳实践，应该基于组织现有的软件活动和过程财富，参考其他标准模型，取其精华去其糟粕，得到新的实践活动模型。 4．过程改进要与组织的商务目标一致，与发展战略紧密结合。 二、CMMI目标:
软件系统测试报告模板
技术资料 [项目名称] 系统测试报告 1测试内容及方法 1.1测试内容 本次测试严格按照《软件系统测试计划》进行，包括单元测试、集成测试、系统测试、用户接受度测试等内容。 1.2测试方法 正确性测试策略、健壮性测试策略、接口测试策略、错误处理测试策略、安全性测试策略、界面测试策略 1.3测试工作环境 1.3.1硬件环境 服务端 数据服务器： 处理器：Inter(R) Xeon(R) CPU E5410 @2.33GHz×2 操作系统：Windows Server 2003 Enterprise Edition SP2 内存空间：8G 硬盘空间：500G×2，RAID0 应用服务器： 处理器：Inter(R) Xeon(R) CPU E5410 @2.33GHz×2 操作系统：Windows Server 2003 Enterprise Edition SP2 内存空间：8G 硬盘空间：500G×2，RAID0 客户端 处理器：Inter(R) Core?2 Quad CPU Q6600 @2.4GHz
操作系统：Windows Server 2003 R2 Enterprise Edition SP2 内存空间：2G 硬盘空间：200G 1.3.2软件环境 操作系统：Windows Server 2003 R2 Enterprise Edition SP2 客户端浏览器：Internet Explorer 6.0/7.0 GIS软件：ArcGIS Server 9.3 WEB服务：IIS6.0 2缺陷及处理约定 2.1缺陷及其处理 2.1.1缺陷严重级别分类 严重程度修改紧急 程度 评定准则实例 高必须立即 修改 系统崩溃、不稳定、 重要功能未实现 1、造成系统崩溃、死机并且不能通过其它方法实现功能； 2、系统不稳定，常规操作造成程序非法退出、死循环、通讯中断或异 常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能。 3、用户需求中的重要功能未实现，包括：业务流程、主要功能、安全 认证等。 中必须修改系统运行基本正 常，次要功能未实 现 1、操作界面错误（包括数据窗口内列名定义、含义不一致）。 2、数据状态变化时，页面未及时刷新。 3、添加数据后，页面中的内容显示不正确或不完整。 4、修改信息后，数据保存失败。 5、删除信息时，系统未给出提示信息。 6、查询信息出错或未按照查询条件显示相应信息。 7、由于未对非法字符、非法操作做限制，导致系统报错等，如：文本 框输入长度未做限制；查询时，开始时间、结束时间未做约束等。 8、兼容性差导致系统运行不正常，如：使用不同浏览器导致系统部分 功能异常；使用不同版本的操作系统导致系统部分功能异常。 低可延期修 改 界面友好性、易用 性、交互性等不够 良好 1、界面风格不统一。 2、界面上存在文字错误。 3、辅助说明、提示信息等描述不清楚。 4、需要长时间处理的任务，没有及时反馈给用户任务的处理状态。 5、建议类问题。
cmmi软件开发流程
软件开发流程软件项目生命周期模型
需求分析 需求分析流程图 过程描述 1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、 供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方 案。 关于自行开发和采购复用的分析， 如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接 受范围内，可考虑采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 工作量、工期、日程、人数 成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预 算的管理等同于计划工作量的管理。） 质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。
软件系统测试报告(简易版)
XXXX软件项目系统测试报告
1．引言部分 1．1项目背景 本测试报告的具体编写目的，指出预期的读者范围。(3-4句) 本测试报告为（系统名称）系统测试报告；本报告目的在于总结测试阶段的测试及测试结果分析，描述系统是否达到需求的目的。 本报告预期参考人员包括测试人员、测试部门经理、项目管理人员、SQA人员和其他质量控制人员。 1．2参考资料 《XXXX需求说明书》 2．测试基本信息 2．1测试范围 2．2测试案例设计思路 根据上述测试范围测试点进行测试用例的设计。 3．测试结果及缺陷分析 3．1测试执行情况与记录 3．1．1测试组织 第 2 页共4 页
3．1．2测试时间 3．1．3冒烟情况 3．1．4测试用例统计 3．2缺陷的统计与分析 缺陷汇总： 列出本次实际发现缺陷数、解决的缺陷数、残留的缺陷数、未解决的缺陷数。 缺陷分析： 对测试中发现的缺陷按缺陷类型、严重程度进行分类统计： 对测试中发现的缺陷就其功能分布、测试阶段进行统计，分析软件缺陷倾向及其主要原因： 残留缺陷与未解决问题 对残留缺陷对系统功能的影响情况进行分析：对未解决问题对项目的影响(如有，列表说明) 4．测试结论与建议 4．1风险分析及建议 无 第 3 页共4 页
4．2测试结论 本项目根据业务需求及开发人员的反馈意见，覆盖了所有的测试需求及案例，均已在ST环境测试完成，有效案例一共xx个，执行率xx%,，成功率xx%，缺陷关闭率为xx%，目前缺陷均已修复并回归关闭； 综上所述，xx需求达到ST项目测试出口标准，本项目ST测试(通过/不通过)，可以进行验收测试 5．交付文档 《xxx需求_系统测试计划》 《xx需求_测试案例》 《xx需求_ST测试报告》 第 4 页共4 页
决策案例分析
政府强行让农民种葡萄到底对不对? 案情简介: 201１年清明前后,正是我国东北农民春耕备耕的时节,可是在辽宁省Ｈ市J县,很多农民却被告知不得在自家田里翻地、播种,当地政府甚至出动大型机械,在农民的田里犁出来一道道深沟，强行要求农民大种葡萄。 清明时节是翻地的黄金时间，４月中旬就要开始播种。由于缺水，J县农民主要种植耐旱的玉米。可是在Ｊ县汤神庙镇,大片大片的耕地并没有翻成种玉米的条条垄沟,而是被翻成了一道道深沟。在汤神庙镇马营子村，村民陈老汉非常痛心地回忆:20１1年3月2号，自己被镇政府的工作人员抬出自家的耕地，眼瞅着玉米地被开出一条条深沟。 一名村民拿着一张镇政府发给他个人的告示,上面的措辞相当强硬:“经请示县政府，镇政府决定，凡是各村规划区内,任何农户决不允许干扰，阻碍，更不得种地，必须栽植酒葡萄,否则造成一切损失,由本户和参与者自负，并根据相关法律追究责任。” 告示上还写道:“县委县政府决定五年内把J县打造成辽宁干红葡萄酒生产第一县,今年我县岭上八个乡镇规划3万亩。” 其背景是，在201０年底，Ｊ县与河北某企业正式签约，计划投资1０亿元，在J县工业园建设一个干红葡萄酒生产项目。为了让项目顺利实施,当地政府部门在去年就启动了３.5万亩酒葡萄产业基地的建设工程,一共涉及J县的1１个乡镇，其中就包括前面提到的汤神庙镇。根据规划,汤神庙镇、王宝营子乡等7个乡镇，每个乡镇栽种葡萄面积不少于5000亩。 村民们说，镇里为了种葡萄把地翻成这样,已经破坏了土壤里原有的水分，即使现在把土填上种玉米,也别想有好收成了。眼瞅着过清明开始种地，这好墒
情都挑开晾着,都成土坷垃,这不是坑人吗?现在又不下雨，更糟了。打多少井啊，都是干井。 引进大型企业振兴地方经济本来是好事，将企业开在原料产地，企业能降低成本，农民的葡萄又有了销路,看上去是双赢的买卖,可为什么老百姓却不买账呢？ 原来，J县长期干旱，并不适合耗水量大的葡萄生产。玉米不但是当地村民的口粮，收割剩下的秸秆还是东北农村家庭必不可少的燃料,一旦葡萄种植失败了，口粮和过冬的燃料又在哪里? 村民们说:别说浇地,吃水都不够，不旱吃水就够了,要是旱了，吃水都不够，还能浇地？ 自然因素还不是最主要的，汤神庙镇的村民算了一笔经济账，按照当地村民的话说，跟耐旱的玉米相比，葡萄太娇贵了，必须有人伺候，这和种在地里差不多就等着收成的玉米相比区别实在太大。而要专心伺候葡萄，很多人就没有办法外出打工，这等于让一家人失去了一份稳定的收入。而在之前政府部门提出的规划中,曾经规定对栽植户实施三年补助,每亩是500元,可村民算下来却发现,种葡萄头两年根本没收益,相比种玉米，一亩50０元的补贴根本不够用,规划中企业称将先行支付生产资料，村民认为这更不是免费的午餐：村民甲：我有4亩地,要是种玉米的话,玉米的价格是1元05分，我一亩地能产两千斤玉米,一亩地就是收入两千元。如果种葡萄,最起码第一年、第二年不结果，第三年结果也是微量的,到第四年大部分结果以后，我还要开始补偿杆子等4、5千块钱投资，也就是在这四五年之内，我一点收入都没有了。 村民乙:谁也不想种，可是没招啊,你说好地给祸害成这样了，谁都来气,社员都不愿意种，一个是水不行，一个这里气候也不适应。
系统测试报告(详细模板)
xxxxxxxxxxxxxxx 系统测试报告 xxxxxxxxxxx公司 20xx年xx月
版本修订记录
目录 1引言 (1) 1.1编写目的 (1) 1.2项目背景 (1) 1.3术语解释 (1) 1.4参考资料 (1) 2测试概要 (2) 2.1系统简介 (2) 2.2测试计划描述 (2) 2.3测试环境 (2) 3测试结果及分析 (4) 3.1测试执行情况 (4) 3.2功能测试报告 (4) 3.2.1xxxx模块测试报告单 (4) 3.2.2xxxxx模块测试报告单 (5) 3.2.3xxxxxxxx模块测试报告单 (5) 3.2.4xxxxxxx模块测试报告单 (5) 3.2.5xxxxx模块测试报告单 (5) 3.3系统性能测试报告 (6) 3.4不间断运行测试报告 (6) 3.5易用性测试报告 (7) 3.6安全性测试报告 (8) 3.7可靠性测试报告 (8) 3.8可维护性测试报告 (10) 4测试结论与建议 (11) 4.1测试人员对需求的理解 (11) 4.2测试准备和测试执行过程 (11) 4.3测试结果分析 (11) 4.4建议 (11)
1引言 1.1编写目的 本测试报告为xxxxxx软件项目的系统测试报告，目的在于对系统开发和实施后的的结果进行测试以及测试结果分析，发现系统中存在的问题，描述系统是否符合项目需求说明书中规定的功能和性能要求。 预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层领导。 1.2项目背景 项目名称：xxxxxxx系统 开发方： xxxxxxxxxx公司 1.3术语解释 系统测试：按照需求规格说明对系统整体功能进行的测试。 功能测试：测试软件各个功能模块是否正确，逻辑是否正确。 系统测试分析：对测试的结果进行分析，形成报告，便于交流和保存。 1.4参考资料 1)GB/T 8566—2001 《信息技术软件生存期过程》(原计算机软件开发规范) 2)GB/T 8567—1988 《计算机软件产品开发文件编制指南》 3)GB/T 11457—1995 《软件工程术语》 4)GB/T 12504—1990 《计算机软件质量保证计划规范》 5)GB/T 12505—1990 《计算机软件配置管理计划规范》
决策分析案例分析报告
某公司某设备操作成本问题 建模与决策分析 一、问题综述 某公司某单位有一台大型设备，供公司生产和科研之用。在工作的时间里，必须有一名操作员负责操作和维护，以及提供一些编程服务。公司网络信息中心的陈主任负责管理这一设备的运作。 现在是公司每年新招录员工刚报到的时间，陈主任面临如何分配新操作员工的问题。由于所有的操作员都是新招录进入公司的，每天都需要进行必要的入职培训和岗位认知，因此，他们每天只能在工作有限的时间内开展工作。 目前有6个操作员（4个本科生、2个研究生）。因为他们的电脑经验以及编程能力不一样，所以，他们的工资也不同。下表给出了他们各自的工资（单位: 元）以及每天可以开展工作的时间。
每个操作员必须保证一周最少工作时间，以保持对设备操作的熟练程度。这一规定硬性的，本科生（A、B、C、D）每周8小时，研究生（E、F）每周7小时。 计算机周一到周五每天从上午8点开到下午10点，任何时候都必须有一位操作员在职。在周末，计算机将由其他人管理。 因为设备的运行费用紧张，陈主任不得不考虑合理地分配每个操作员每天的工作时间，以使设备的操作成本最小。 二、问题定义 1、决策变量 a1、b1、c1、d1、e1、f1=A、B、C、D、E、F每周一工作的时间 a2、b2、c2、d2、e2、f2=A、B、C、D、E、F每周二工作的时间 a3、b3、c3、d3、e3、f3=A、B、C、D、E、F每周三工作的时间 a4、b4、c4、d4、e4、f4=A、B、C、D、E、F每周四工作的时间 a5、b5、c5、d5、e5、f5=A、B、C、D、E、F每周五工作的时间 2、目标：成本最小 成本= （a1+a2+a3+a4+a5）×10.00+（b1+b2+b3+b4+b5）×10.10+ （c1+c2+c3+c4+c5）× 9.90+（d1+d2+d3+d4+d5）× 9.80+ （e1+e2+e3+e4+e5）×10.80+（f1+f2+f3+f4+f5）×11.30 3、资源使用情况及限制条件 （a1+a2+a3+a4+a5）总量为18 （b1+b2+b3+b4+b5）总量为12
cmmi软件开发流程
c m m i软件开发流程 Prepare d on 24 November 2020
软件开发流程软件项目生命周期模型
需求分析 需求分析流程图 过程描述 1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 ?对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。 ?关于自行开发和采购复用的分析， ?如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用； ?本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购； ?否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 ?工作量、工期、日程、人数 ?成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预算的管理等同于计划工作量的 管理。） ?质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。
(完整版)第三方软件测试报告[模板]
第三方软件测试报告（暂定） 1.引言 1.1.编写目的 本文档作为该系统测试的测试标准，内容关系到本次系统测试可能涉及到的测试内容和测试技术解决方案。 1.2.系统概述 略 2.测试描述 2.1.测试范围与内容 我方（北京圆规创新公司）对XX公司“XX”项目进行测试，保证使用方的功能正确，保证系统核心模块的稳定和安全，为项目的验收提供参考。以此，本计划列出了在此次功能测试过程中所要进行的内容和实施的方案及测试资源的安排，作为测试活动的依据和参考。 本次测试的对象为XX公司“XX”项目，测试范围为：略。 本次测试的主要内容有功能测试（含容错测试）、易用性测试。 2.2.测试依据 本次测试所依据的文档包含开发方提供的《需求规格说明书》、《操作手册》、《用户手册》，《维护手册》，《设计文档》等相关开发文档。
并依据IT行业项目的通用标准，包括功能测试标准、缺陷标准、易用性标准。 对于项目的易用性标准，原则上由测试方提出易用性问题修改的建议，由开发方对测试方提交的问题进行确认。 3.测试解决方案 我公司针对用户方提出的测试要求，根据以往项目的实际经验，撰写测试技术解决方案。该解决方案包含了本次系统测试可能涉及到的测试类型，并分别介绍不同测试类型的内容和相关标准。 3.1.系统功能测试 实施系统功能测试，完成对被测系统的功能确认。 采用黑盒测试方法，根据需求规格说明书和用户手册，将功能点转换为功能测试需求，根据测试需求编写测试用例，保证所有功能点必须被测试用例覆盖。 测试用例的编写采用基于场景的测试用例编写原则，便于以使用者的角度进行测试。用例设计上兼顾正常业务逻辑和异常业务逻辑。测试数据的选取可采用GUI测试，等价类划分、边界值分析、错误推测、比较测试等测试方法中的一种或者几种数据的组合，一般以等价类划分和边界值法为主。 3.1.1.系统功能项测试 对《软件需求规格说明书》中的所有功能项进行测试（列表）； 3.1.2.系统业务流程测试 对《软件需求规格说明书》中的典型业务流程进行测试（列表）； 3.1.3.系统功能测试标准 ?可测试的功能点100％作为测试需求（如未作为测试需求，必须在测试计划中标注原因并通知用户方负责人）；
投资决策原理与案例分析报告
实验（实训）报告 课程名称Excel在财会中的高级应用所属课程名称网络会计模块 实验(实训)日期2011.6 班级09会计4班 学号0920430112 姓名沈丹蕾 指导教师钟晓鸣 浙江财经学院东方学院教务部制
投资决策的原理及案例分析 摘要：投资决策是指投资者为了实现其预期的投资目标，运用—定的科学理论、方法和手段，通过一定的程序对投资的必要性、投资目标、投资规模、投资方向、投资结构、投资成本与收益等经济活动中重大问题所进行的分析、判断和方案选择。 关键字：投资；折现方法；净现值； 一、投资决策的意义 1.资本投资一般要占用企业大量资金。 2.资本投资通常将对企业未来的现金流量产生重大影响，尤其是那些要在企业承受好几年现金流出之后才可能产生现金流入的投资。 3.很多投资的回收在投资发生时是不能确知的，因此，投资决策存在着风险和不确定性。 4.一旦做出某个投资决策，一般不可能收回该决策，至少这么做代价很大。 5.投资决策对企业实现自身目标的能力产生直接影响。 综上所述，投资决策决定着企业的未来，正确的投资决策能够使企业降低风险、取得收益，糟糕的投资决策能置企业于死地，所以，我们理应经过深思熟虑并在正确原理的指导下做出正确的投资决策。 二、投资决策指标
1.净现值函数（NPV） 语法：NPV（rate,value1,valve2,…） 功能：在已知未来连续期间的现金流量（value1,valve2,…）及贴现率（rate）的条件下，返回某项投资的净现值。 NPV>0表示项目实施后，除保证可实现预定的收益率外，尚可获得更高的收益。 NPV<0表示项目实施后，未能达到预定的收益率水平，而不能确定项目已亏损。 NPV=0表示项目实施后的投资收益率正好达到预期，而不是投资项目盈亏平衡。 2.内含报酬率函数（IRR） 语法：IRR（values,guess） 功能：返回连续期间的现金流量（values）的内涵报酬率。 Values必须是含有数值的数组或参考地址。它必须含有一个正数和一个负数，否则内含报酬率可能是无限解。IRR函数根据values参数中数字的顺序来解释现金流量的顺序，所以在输入现金流量及现金流出时，必须按照正确的顺序排序。Values参数中的正文、逻辑值或空白单元，都被忽略不计。 Guess为你猜想的接近IRR结果的数值。IRR函数从guess猜测数开始，反复计算直到误差值小于0.00001%，如果反复在计算20次后，依然无法求得结果，IRR函数则会返回错误值#NUM!。在大部分处理中，并不需要提供guess 值。如果省略掉guess，IRR函数将假设它是10%。但是，如果IRR函数返回错误值#NUM!，则应使用不同的guess值再试一次。
系统测试报告模板(绝对实用)
XXX项目软件测试报告 编制： 审核： 批准：
目录 1概述..................................................... 错误!未定义书签。2测试概要................................................. 错误!未定义书签。 进度回顾.......................................... 错误!未定义书签。 测试环境.......................................... 错误!未定义书签。 软硬件环境.................................. 错误!未定义书签。 网络拓扑.................................... 错误!未定义书签。3测试结论................................................. 错误!未定义书签。 测试记录.......................................... 错误!未定义书签。 缺陷修改记录...................................... 错误!未定义书签。 功能性............................................ 错误!未定义书签。 易用性............................................ 错误!未定义书签。 可靠性............................................ 错误!未定义书签。 兼容性............................................ 错误!未定义书签。 安全性............................................ 错误!未定义书签。4缺陷分析................................................. 错误!未定义书签。 缺陷收敛趋势...................................... 错误!未定义书签。 缺陷统计分析...................................... 错误!未定义书签。5遗留问题分析............................................. 错误!未定义书签。 遗留问题统计...................................... 错误!未定义书签。
管理学决策案例分析报告
案例分析 案例一：蔬菜管理 彼得·莫斯是一名生产和经营蔬菜的企业家。他现在已有50000平方米的蔬菜温室大棚和一座毗邻的办公大楼，并且聘请了一批农业专家顾问。 莫斯经营蔬菜业务是从一个偶然事件开始的。有一天，他在一家杂货店看到一种硬花球花椰菜与花椰菜的杂交品种，他突发奇想，决定自己建立温室培育杂交蔬菜。 莫斯用从他祖父那里继承下来的一部分钱，雇用了一班专门搞蔬菜杂交品种的农艺专家，这个专家小组负责开发类似于他在杂货店中看到的那些杂交品种蔬菜，并不断向莫斯提出新建议。如建议他开发菠生菜（菠菜与生菜杂交品种），橡子萝卜瓜、橡子南瓜以及萝卜的杂交品种。特别是一种拧橡辣椒，是一种略带甜味和拧橡味的辣椒，他们的开发很受顾客欢迎。 同时，莫斯也用水栽法生产传统的蔬菜，销路很好。生意发展得如此之快，以致他前一个时期，很少有更多的时间考虑公司的长远规划与发展。最近，他觉得需要对一些问题着手进行决策，包括职工的职责范围，生活质量，市场与定价策略，公司的形象等等。 莫斯热衷于使他的员工感到自身工作的价值。他希望通过让每个员工“参与管理”了解公司的现状，调动职工的积极性。他相信：这是维持员工兴趣和激励他们的最好办法。 他决定在本年度12月1号九时召开一次由每一个农艺学家参加的会议，其议程是： 1.周末，我们需要有一个农艺师在蔬菜种植现场值班，能够随叫随到，并为他们配备一台步话机，目的是一旦蔬菜突然脱水或者枯萎。可以找到这些专家处理紧急情况，要做的决策是：应该由谁来值班，他的责任是什么？ 2.我们公司的颜色是绿色的，要做的决策是新地毯、墙纸以及工作服等应该采取什么样绿色色调？ 3.公司有一些独特的产品，还没有竞争对手，而另外一些产品，在市场上竞争十分激烈。要做的决策是对不同的蔬菜产品应当如何定价，彼得·莫斯要求大家务必准时到会，积极参与发表意见，并期望得到最有效的决策结果。 问题： 1.一个决策的有效性应取决于 A.决策的质量高低 B.是否符合决策的程序 C.决策的质量与参与决策的人数 D.以上提法均不全面。 2.按照利克特的行为模式，彼得·莫斯工作作风与管理方式属于 A.协商式 B.群体参与式 C.开明——权威式 D.民主式 3.12月1日所召开的会议是必要的吗？
cmmi软件开发流程
c m m i软件开发流程 公司内部编号：（GOOD-TMMT-MMUT-UUPTY-UUYY-DTTI-
软件开发流程软件项目生命周期模型
需求分析需求分析流程图
过程描述
1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。 2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事 先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠 性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨 论表决的方法选择并确定最终的技术方案。 关于自行开发和采购复用的分析， 如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、 测试用例等)，一般应进行复用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本 在项目可接受范围内，可考虑采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。
最新软件测试报告模板分析
(OA号：OA号/无)XXX产品名称XX版本（提测日期：YYYY.MM.dd） 第XX轮 功能/性能/稳定性/兼容性测试报告
修订历史记录 A - 增加 M - 修订 D - 删除
1.概述 (4) 1.1 测试目的 (4) 1.2 测试背景 (4) 1.3 测试资源投入 (4) 1.4 测试功能 (5) 1.5 术语和缩略词 (5) 1.6 测试范围............................................................................................ 错误!未定义书签。 2.测试环境 (6) 2.1 测试软件环境 (6) 2.2 测试硬件资源 (7) 2.3 测试组网图 (6) 3.测试用例执行情况 (7) 4.测试结果分析（大项目） (8) 4.1 Bug趋势图 (8) 4.2 Bug严重程度 (9) 4.3 Bug模块分布 (9) 4.4 Bug来源............................................................................................ 错误!未定义书签。 5.测试结果与建议 (10) 5.1 测试结果 (10) 5.2 建议 (11) 5.3 测试差异分析 (11) 6.测试缺陷分析 (11) 7.未实现需求列表 (11) 8.测试风险 (12) 9.缺陷列表 (12)
1.概述 1.1 测试目的 本报告编写目的，指出预期读者范围。 1.2 测试背景 对项目目标和目的进行简要说明，必要时包括该项目历史做一些简介。 1.3 测试资源投入 //针对本轮测试的一个分析 //测试项：功能测试、性能测试、稳定性测试等
数据模型和决策课程案例分析报告
数据模型与决策课程案例一生产战略 一、问题提出 好身体公司（BFI）在长岛自由港工厂生产健身练习器械。最近他们设计了两种针对家庭锻炼所广泛使用的举重机。两种机器都是用了BFI专利技术，这种技术提供给使用者除了机器本身运动功能之外的一些其他额外的运动功能。直到现在，这种功能也只有在很昂贵的、应用于理疗的举重机上才可以获得。 在最近的交易展销会上，举重机的现场演示引起了交易者浓厚的兴趣，实际上，BFI 现在收到的订单数量已经超过了这个时期BFI的生产能力。管理部门决定开始这两种器械的生产。这两种器械分别被BFI 公司命名为BodyPlus100和BodyPlus200，由不同的原材料生产而成。 BodyPlus100由一个框架、一个压力装置、一个提升一下拉装置组成。生产一个框架需要4小时机器制造和焊接时间，2小时喷涂和完工时间；每个压力装置需要2小时机器制造和焊接时间，1小时喷涂和完工时间，每个提升一下拉装置需要2小时机器制造和焊接时间，2小时喷涂和完工时间。另外，每个BodyPlus100还需要2小时用来组装、测试和包装。每个框架的原材料成本是450美元，每个压力装置的成本是300美元，每个提升一下拉装置是250美元。包装成本大约是每单位50美元。 BodyPlus200包括一个框架、一个压力装置、一个提升一下拉装置和一个腿部拉伸装置。生产一个框架需要5小时机器制造和焊接时间，4小时喷涂和完工时间；生产一个压力装置需要3小时机器制造和焊接时间，2小时喷涂和完工时间；生产每个提升一下拉装置需要2小时机器制造和焊接时间，2小时喷涂和完工时间，另外，每个BodyPlus200还需要2小时用来组装、测试和包装。每个框架的原材料成本是650美元，每个压力装置的成本是400美元，每个提升一下拉装置是250美元，每个腿部拉伸装置的成本是200美元。包装成本大约是每单位75美元。 在下一个生产周期，管理部门估计有600小时机器和焊接时间，450小时喷涂和完工时间，140小时组装、测试和包装时间是可用的。现在的每小时劳动力成本是机器制造和焊接时间20美元，喷涂和完工时间15美元，组装、测试和包装12美元。虽然对于BFI 来说由于新机器的独特功能可能还会获得一些价格的灵活性，但BodyPlus100的市场建议价格是2400美元，BodyPlus200是3500美元。授权的BFI销售商可以以市场价格的70%来购买产品。 BFI的总裁相信BodyPlus200 的独特功能可以帮助BFI 成为高端锻炼器械的领导者。所以，他认为BodyPlus200的数量至少会占到整个生产数量的25%。 管理报告 分析BFI的生产问题，为公司的总裁准备一份报告，告诉他们你的发现和建议。报告包括以下几个方面（不仅于此）： （1）BodyPlus100和BodyPlus200的建议生产数量是多少？ （2）BodyPlus200的数量占生产数量至少25%的要求会怎样影响利润？ （3）为了增加利润应扩展哪方面的努力？ 把你的线性规划模型和图形解作为你报告的附录部分。 二、问题分析与模型建立 根据案例对好身体公司（BFI）两种器械产品BodyPlus100和BodyPlus200的描述，
系统安全测试报告模版V
国信嘉宁数据技术有限公司 XXX系统 安全测试报告 创建人：xxx 创建时间：xxxx年xx月xx日 确认时间： 当前版本：V1.0
文档变更记录 *修订类型分为：A－ADDED，M－MODIFIED，D－DELETED。
目录 1.简介 (4) 1.1.编写目的 (4) 1.2.项目背景 (4) 1.3.系统简介 (4) 1.4.术语定义和缩写词 (4) 1.5.参考资料 (4) 2.测试概要 (5) 2.1.测试范围 (5) 2.2.测试方法和测试工具 (5) 2.3.测试环境与配置 (8) 3.测试组织 (8) 3.1.测试人员 (8) 3.2.测试时间细分及投入人力 (8) 4.测试结果及缺陷分析 (9) 4.1.测试执行情况统计分析 (9) 4.2.遗留缺陷列表 (9) 5.测试结论 (9) 6.测试建议 (10)
1.简介 1.1.编写目的 描述编写本测试报告需要说明的内容。 如：本报告为XX项目的安全测试报告，目的在考察系统安全性、测试结论以及测试建议。 1.2.项目背景 对项目背景进行简要说明，可从需求文档或测试方案中获取。 1.3.系统简介 对所测试项目进行简要的介绍，如果有设计说明书可以参考设计说明书，最好添加上架构图和拓扑图。 1.4.术语定义和缩写词 列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。 如： 漏洞扫描： SQL注入： 1.5.参考资料 请列出编写测试报告时所参考的资料、文档。 需求、设计、测试案例、手册以及其他项目文档都是范围内可参考的资料。 测试使用的国家标准、行业指标、公司规范和质量手册等等。
管理决策案例分析解析讲课讲稿
管理决策案例分析 经营决策案例分析 在棋界有句话：“一着不慎，满盘皆输；一着占先，全盘皆活”。它喻示一个道理，无论做什么事情，成功与失败取决于决策的正确与否。科学的经营决策能使企业充满活力，兴旺发达，而错误的经营决策会使企业陷入被动，濒临险境。纵观世界各国，经营决策失败的有之，当然，也不乏成功的案例。从以下的案例中我们会得到许多有益的启示。 案例一：1985年，由马来西亚国营重工业公司和日本三菱汽车公司合资2.8亿美元生产的新款汽车“沙格型”隆重推出市场。马来西亚政府视之为马来西亚工业的“光荣产品”，产品在推出后，销售量很快跌至低潮。经济学家们经过研究，认为“沙格型”汽车的一切配件都从日本运来，由于日元升值，使它的生产成本急涨，再加上马来西亚本身的经济不景气，所以汽车的销售量很少。此外，最重要的因素是政府在决定引进这种车型时，主要考虑到满足国内的需要。因此，技术上未达到先进国家的标准，无法出口。由于在目标市场决策中出现失误，“沙格型”汽车为马来西亚工业带来的好梦，只是昙花一现而已。 此例说明，科学经营决策的前提是确定决策目标。它作为评价和监测整个决策行动的准则，不断地影响、调整和控制着决策活动的过程，一旦目标错了，就会导致决策失败。 案例二：1962年，英法航空公司开始合作研制“协和”式超音速民航客机，其特点是快速、豪华、舒适。经过十多年的研制，耗资上亿英磅，终于在 1975年研制成功。十几年时间的流逝，情况发生了很大变化。能源危机、生态危机威胁着西方世界，乘客和许多航空公司都因此而改变了对在航客机的要求。乘客的要求是票价不要太贵，航空公司的要求是节省能源，多载乘客，噪音小。但“协和”式飞机却不能满足消费者的这些要求。首先是噪音大，飞行时会产生极大的声响，有时甚至会震碎建筑物上的玻璃。再就是由于燃料价格增长快，运行费用也相应大大提高。这些情况表明，消费者对这种飞机需求量不会很大。因此，不应大批量投入生产。但是，由于公司没有决策运行控制计划，也没有重新进行评审，而且，飞机是由两国合作研制的，雇佣了大量人员参加这项工作，如果中途下马，就要大量解雇人员。上述情况使得飞机的研制生产决策不易中断，后来两国对是否要继续协作研制生产这种飞机发生了争论，但由于缺乏决策运行控制机制，只能勉强将决策继续实施下去。结果，飞机生产出来后卖不出去，原来的宠儿变成了弃儿。 此例说明，企业决策运行控制与企业的命运息息相关。一项决策在确定后，能否最后取得成功，除了决策本身性质的优劣外，还要依靠对决策运行的控制与调整，包括在决策执行过程中的控制，以及在决策确定过程中各阶段的控制。 案例三：美国国际商用机器公司为了从规模上占领市场，大胆决策购买股权。1982年用2.5亿美元从美国英特尔公司手中买下了12%的股权，从而足以对付国内外电脑界的挑战；另一次是1983年，又以2.28亿美元收购了美国一家专门生产电讯设备的企业
CMMI体系简介及软件工作流程
CMMI体系简介及软件工作流程 质量管理部 2009年03 月 华丽娜主题 第一部分:CMMI基础知识 CMMI是什么 CMMI发展和厉史 CMMI模型组件概述 第二部分:公司质量体系文件综述 公司软件过程概述 公司过程文件概述 公司体系文件导读 CMMI是什么？ ◆Capability Maturity Model Integration(能力成熟度模型综合) 它综合了以下几方面: System engineering Software engineering Integrated Product and Process Development Supplier Sourcing ◆该模型提供一套可供公众使用的准则；这些准则描述那些成功地 实施了过程改进的组织的特性。
◆该模型用“软件能力成熟度”来衡量这种软件综合能力 CMMI是什么？ ?美国卡内塞一梅隆大学软件工程研究所(SEI)研制。 ?CMMI的前身是SW-CMM和SE-CMM ?CMMI有专门认证评估方法一SCAMPI 发展简史 草案于1997年制定(未广泛应用)。 到2000年，CMM演化成为 Software Engineering)于2002年1月正式推出。 CMMI的诞生（1） 版，经历了十多年，在这期间，IT产业有了长足的发展，相应的工 业标准或规范必然要不断地改进。 不再局限于纯粹软件的范崎。虽然人们了解和应用CMMI需要一定的 时间，但走CMMI将取代CMM这走必然的趋势。 CMMI的诞生（2） ◆CMMI为工业界和政府部门提供了一个集成的产品集，其主要目的 是消除不同模型之间的不一致和重复，降低基于模型改善的成本。 CMMI将以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。 CMMI模型组件概述 CMMI分级（阶段）模型 CMMI阶段式模型的结构