本文主要是介绍软件工程过程总结，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

软件工程过程总结

• 一、软件过程基本理论与技术**********
• 二、团队与团队文化建设**********
• 三、过程环境与支持管理**********
• 四、过程监控与度量**********
• 五、质量运动与过程改进**********

一、软件过程基本理论与技术**********

我国的软件开发存在的问题？（1）质量意识淡薄，企业从上到下都缺乏正确的产品质量意识，只注重完成软件产品的功能，忽视产品的质量问题。（2）体制不灵活，不健全，导致质量监督不力。由于体制问题造成软件人才不必要的流动，同样是因为体制问题造成实际上企业的软件资产流失。（3）做产品的概念不浓，大多只为短期的经济利益，做短期的项目。（4）形式化的东西太多，为追求评奖或完成项目，报喜不报忧。（5）软件企业的交流少，思想保守。（6）对新技术研究的跟进、投入少。（7）多数项目盲目采用国外技术，没有从自身问题入手，寻找适合产品开发的技术和过程。
软件过程的有哪些分类？软件过程可概括为三类：基本过程类、 支持过程类和组织过程类。 软件基本过程：软件获取、供应、开发、运行和维护的过程，包括需求分析、软件设计、编码等过程。软件支持过程：对软件主要过程提供支持的过程，包括文档编制过程、配置管理过程、质量保证过程、验证和确认过程（测试过程）、评审过程等。软件组织过程：对软件主要过程和支持过程的组织保证过程，包括管理过程、基础设施过程、改进过程和培训过程。
软件开发过程是指在完成某个软件项目的过程中，开发目标软件所经历的步骤，是一系列软件活动的集合。
如何建立软件过程？从现有的成熟的软件生存周期模型中选择、对模型加以改进、 自定义过程、六个主要过程：制定计划、需求分析、设计、程序编码、测试及运行维护
瀑布模型：计划->需求分析->设计->编码->测试->运行·维护 优点：过程有计划、分工明确；缺点：理想化，不灵活、产品交付延迟，反应慢
渐增模型：软件项目往往要“干两遍”，这样最终软件才能较好的令用户满意。第一次只是“试验开发”，目的是探索可行性、明确需求，所得到的工件称为“原型”。优点：缓解了瀑布模型不灵活，用户无法预判系统正确性的问题；缺点：易退化成“边做边改”模型、增加了成本。
螺旋模型：每个螺旋周期可分为制定计划、风险分析、开发实施、用户评估4 个步骤。优点：加强了用户与开发人员的交流，兼有瀑布模型与演化模型的优点；缺点：风险分析是螺旋模型的核心活动，要重复评估，以确保进度和成本可控
喷泉模型：优点：支持软件复用，有利于多项开发活动集成；缺点：大量开发人员同时开发，不利于项目管理，同时要确保文档一致性
原型模型：原型模型以迭代式开发为思想，针对需求分析难以完整、准确，或者可实现性难以验证的问题，首先构建一个软件原始模型给用户体验，反馈意见，通过不断更新或者多次重复开发，得到最终软件。优点：易明确需求、易验证方案、用户快速体验与反馈：缺点：需要工具和方法支持，以保障进度和成本
V模型：优点：包含了底层测试（单元测试）和高层测试（系统测试）；清楚的标识了开发和测试的各个阶段；自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。缺点：自上而下的顺序导致测试工作在编码后，不能及时的进行修改；实际工作中，需求经常变化，导致V模型步骤反复执行，返工量很大，灵活度较低。
CMM软件能力成熟度模型分为五个等级 ：初始级，软件生产过程的特征是随机的，有时甚至是杂乱的。很少过程被定义，成功依赖于个人的努力。 可重复级，建立基本的项目管理过程，以跟踪费用、进度和功能。设定必要的过程纪律以重复以往在相同应用的项目的成功。已定义级，管理和工程活动的软件过程已文档化、标准化、集成化到一个标准的组织的软件过程。组织内所有的项目使用的软件过程是集体同意、裁剪过的标准开发和维护软件的版本。已管理级，详细的软件过程和产品质量的特征已被收集。软件过程和产品已被定量管理和控制。优化级，能自觉利用各种经验和来自新技术、新思想的先导试验的定量反馈信息，不断改进和优化组织统一的标准软件过程。
CMM、 PSP、 TSP三者之间的关系、CMM是过程改善的第一步，它提供了评价组织的能力、识别优先改善需求和追踪改善进展的管理方式。企业只有开始CMM改善后，才能接受需要规划的事实，认识到质量的重要性，才能注重对员工经常进行培训，合理分配项目人员，并且建立起有效的项目小组。然而，它实现的成功与否与组织内部有关人员的积极参加和创造性活动密不可分。PSP能够指导软件工程师如何保证自己的工作质量，估计和规划自身的工作，度量和追踪个人的表现，管理自身的软件过程和产品质量。经过PSP学习和实践的正规训练，软件工程师们能够在他们参与的项目工作之中充分运用PSP，从而有助于CMM目标的实现。TSP结合了CMM的管理方法和PSP的工程技能，通过告诉软件工程师如何将个体过程结合进小组软件过程，并将后者与组织进而整个管理系统相联系；通过告诉管理层如何支持和授权项目小组，坚持高质量的工作，并且依据数据进行项目的管理，向组织展示如何应用CMM的原则和PSP的技能去生产高质量的产品。
RUP中的软件生命周期的四个阶段及对应里程碑：初始阶段：生命周期目标里程碑。细化阶段：生命周期结构里程碑。构造阶段：初始功能里程碑。交付阶段：产品发布里程碑。
业务驱动开发的6个原则：提高过程的适应性、平衡有竞争的涉众的优先级、团队协作、体现迭代的力量、提升抽象级别、持续关注质量。
RUP的9个规程：需求、业务建模、配置和变更管理、环境、项目管理、分析与设计、实施、测试、部署。
RUP的6个最佳实践：迭代开发、管理需求、使用基于组件的构架、可视建模、持续的质量验证、控制变更。
RUP的三个中心元素。用于成功开发软件的一组基本原则。这些原则是开发RUP的基础。可重用方法内容及流程构件块的框架。方法插件系列定义了方法框架，从该框架您可以创建自己的方法配置及定制的流程。底层方法及流程定义语言。统一方法体系结构元模型提供了用于描述方法内容及流程的语言。
敏捷宣言的四个核心价值是：个体和互动高于流程和工具、工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划。① 人是获得成功的最为重要的因素。一个由平均水平的、具有良好沟通能力的程序员组成的团队，将要比那些虽然拥有一批高水平的程序员，但是成员之间却不能进行交流的团队更有可能获得成功。团队的构建要比环境的构建重要的多。许多团队和管理者就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境。② 没有文档的软件是一种灾难。代码不是交流系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行面熟。然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且使这些文档和代码保持同步，要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。③ 成功的项目需要定期且频繁的客户反馈。不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切地工作在一起，并尽量经常地提供反馈。一个指明了需求、进度以及项目成本的合同存在根本上的缺陷。在大多数情况下，合同中规定的条款远在项目完成之前（有时甚至是远在合同签署之前）就变得没有意义。那些为开发团队和客户的协同工作方式提供指导的合同才是最好的合同。④ 随时应对变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的，并且易于适应商务和技术方面的变化。计划不能考虑得过远。首先，商务环境很可能会变化，这会引起需求的变动。其次，一旦客户看到系统开始运作，他们很可能会改变需求。最后，即使我们知道需求是什么，并且确信他们不会改变，我们仍然不能很好地估算出开发他们需要的时间。所以我们要时刻保持计划的灵活性，这样才不会浪费不必要的人力、物力、财力。
平衡敏捷与规范：如果只有强有力的规范而缺乏敏捷，将导致官僚作风， 进而停滞不前；缺乏规范的敏捷则如同一个新创公司在盈利之前的不负 责任的狂热。敏捷过程与规范过程各有自己的特点和优点，在本质上和在实际项目中，敏捷与规范是可以平衡的.Boehm等详细总结了敏捷与规范两种方法各自的擅长领域，并给出了基于风险分析平衡敏捷与规范的策略，而平衡的策略可以综合两种方法的优点。Boehm给出了影响敏捷与规范方法选择的五个维度（动态性、危险性、规模、人员和文化）。结论：敏捷与规范，软件开发中看似对立的两个属性，实际上相得益彰。计划驱动的开发人员必须敏捷，敏捷开发人员必须规范。成功的关键在于找到两者的平衡点。这个平衡点随项目所处的环境以及所涉及的风险而变化。仅凭一腔热情径直地采用极端方法的开发人员，必须学会如何根据实际情况恰当地平衡敏捷与规范。
极限编程XP是敏捷过程中最负盛名的一个，其名称“极限”二字的含义是指把好的开 发实践运用到极致。XP的四个观点：交流 、简单、回馈、勇气。原则:测试1．所有的代码都必须有单元测试 2．所有的代码在发布之前必须通过所有单元测试 3．当一个BUG发现时，就增加新的测试 4．经常运行验收测试，并公布分数
敏捷项目管理:对整个项目做一个粗略的估计,每一次迭代都有详细的计划.鼓励变化, 客户价值驱动开发.信任和赋予权力;合约使变更变得简单，增加价值.客户和开发人员之间是紧密的连续的合作关系每次迭代都产生可交付的软件专注于交付软件.第一次迭代就可交付能工作的版本，风险发现的早.
为什么采用敏捷? 采用敏捷方法得当的话，可以：更加透明; 随时跟踪项目的状态和进展情况，及早发现问题和风险 .快速交付, 每次迭代都能交付可运行的软件.最高风险和最高优先级的需求，最优先进行开发.改善应对变更能力, 减少大量的重计划.改善项目沟通.更好的客户参与, 避免错误的假设.
软件构建指的是通过编码、验证、单元测试、集成测试和调试的组合，详细地创建可工作的，有意义的软件。软件构建的原则：最小的复杂性、要预测变更、为验证二构建。
软件重构是在不改变代码外在行为的前提下，对代码进行修改以改进程序的内部结构，即软件重构只是将软件的内部结构进行调整，提高其可理解性，降低修改的成本。为什么需要重构？“三次原则”可以作为重构时机的参考，即“ 事不过三，三则重构”。也就是说，第一次编写全新的代码尽管去做；第二次编写类似的代码虽然令人反感，但还是直接去做；第三次再做类似的事情，这时就应该重构。 重构常用方法？1. 重新组织函数 2. 在对象之间迁移特征 3. 重新组织数据 4. 简化条件表达式 5. 简化函数调用 6. 处理概括关系 7. 大型重构
复用已有资产：降低复杂度对生产率有很大影响。在更高的抽象层次工作，降低了复杂度并使交流变得容易。复用已有资产降低复杂度，比如：可复用的组件、以前的系统、已有业务流程、模式、开源软件；两个关于复用的例子在过去十年对软件业产生了巨大影响：对中间件的复用，比如数据库、Web服务器和端口。开源软件提供了许多或大或小的可利用的组件。

二、团队与团队文化建设**********

Scrum开发过程三个要素：1.角色：定义了产品负责人、Scrum主管和团队成员。2.活动：定义的主要活动包括冲刺规划会议、每日站立会议、冲刺复审会议和冲刺回顾会议。3.工件：在Scrum中，工件包括产品订单、冲刺订单、燃尽图、新的功能增量等实体概念。最佳实践：迭代式软件开发方法。两层项目规划。团队的整体协作能力。软件持续集成原则。
重构？
迭代开发的优势？需求可以变化，早期的迭代可以暴露风险，使重用更加容易，能够在每一个迭代开发中发现并更正缺陷，能够更好地利用项目的人员资源，每次迭代都可以集成构建系统各部分。
制定迭代计划时要考虑的因素有哪些?版本迭代计划的内容：根据产品研发和运营的实际情况，产品版本迭代计划主要包括以下的内容：发布新功能；优化或升级现有的产品功能；修复产品缺陷；优化界面表现细节（视觉、交互体验和用户指引） 等。每一次的产品版本迭代计划都有可能是上面的某一项或者是几项组成。需要保持延续性来培养和固定用户的操作习惯：
一次迭代过程：在迭代开始之后，团队成员在一次迭代中完成指定的工作。工作结束之后，迭代评估执行中使用尽可能多的客观测量来确定迭代目标是否实现以及如何实现。假如你决定继续，你必须使变更控制委员会批准你的项目改变，修改你的风险列表，并且可能修改产品目标（需求）或者产品的规格说明书（架构设计）。顾及到需求和项目变更，修改项目规格说明书成为新的目标，并且允许你操纵这个项目。基于已经调整的目标，你可以计划下一次迭代，创建一个新的迭代计划。
迭代评审，在迭代结束后进行，展示迭代的成果 (功能运行).确保成果与预期的一致，收集反馈；为项目提供一个参考点，根据目前的位置计划下一期的旅程；为下次迭代提供输入（改正、修改、新的想法可以由产品所有者添加到产品需求清单.
迭代回顾会议-简单流程:Scrum Master 总结本次迭代; 迭代任务清单, 重要的事情和决策, 预期的/实际进度.每个组员陈述迭代中那些方法进行的较好、哪些需要改进, Scrum Master 进行记录.对重要的问题计划相应的措施：团队自己解决, 或者提交给公司的管理层.
沟通和协作激励团队中个人的最好表现。 当人们感到真正要对最终产品负责的时候，他们被激励去很好的完成工作。鼓励跨职能的合作。 打破经常存在在下面两种情况之间的屏障：
分析师、开发人员和测试人员、运作业务、开发应用和实现应用的团队、确保成员理解项目的任务和远景。软件是由有才能，有动力的人紧密合作而创造的。很多复杂的系统需要大量的不同技能的项目干系人的协作，并且大的项目常常跨越地理和时间的界限，进一步增加了开发过程的复杂度。
团队激励：通常用以激励团队成员的方式有三种：“ 威逼 ” 、“ 利诱 ” 以及鼓励承诺.
激发每个项目成员的工作积极性和工作热情：个人技能提升、表扬和鼓励、乐于接受项目成员意见、关注每个项目成员的职业发展。
加强项目中的团队文化建设：在现在的IT项目管理中，我们强调的团队文化主要有责任感，协作精神，服务意识等方面的内容。责任感是团队文化最基本的要素，只有团队中每个人员都有了这种责任感，能够积极主动工作，才能够谈得上后续的沟通和相互协作，以达到团队所共同确定的目标。在IT项目中我强调的最多的责任感就是项目成员要把自己角色下的工作做好，努力为下游角色输出高质量的工件。协作精神在现在的项目中是很重要的，这也就决定了我们即使完成一个简单的项目任务也需要我们项目中的需求，设计，开发和测试人员来共同协作完成。协作精神之根本在于企业文化所强调的互相尊重，项目内每位成员都应该尊重和认可其它成员所扮演的角色，学习他人的优点。项目成员应该在尊重的前提下充分信任和充分沟通来共同实现团队任务，每个成员都应该认识到团队利益始终高于个人利益，只有团队进步和发展了，个人才能够更好的进步和发展。项目中每个成员都需要树立很好的服务意识，因为我们只有在很好的服务于他人的时候，我们才能够真正体会到我们自身知识和技能的提高，体会到这种工作为他人所带来的便利和工作所带来的成就感。
质量经理的主要工作内容：• 带领团队开发和跟踪质量计划 • 向项目组长警示质量问题 • 软件产品提交配置管理之前，对其进行评审，以消除质量问题 • 项目小组评审的组织者和协调者 • 参与项目总结
过程经理的主要工作内容：• 带领团队定义和记录开发过程并且 支持过程改进。 • 建立和维护团队的开发标准。 • 记录和维护项目的会议记录。 • 参与项目总结。
支持经理的主要工作内容 • 带领团队识别开发过程中所需要的各 类工具和设施。 • 主持配置管理委员会，管理配置管理 系统。 • 维护软件项目的词汇表。 • 维护项目风险和问题跟踪系统。 • 支持软件开发过程中复用策略的应用。 • 参与项目总结。
加强团队文化建设的方法：1)在项目组内部进行关于团队文化建设，沟通等方面的培训，并结合项目实际的例子加强项目成员对团队的理解。2)项目经理应该定期和项目组成员进行单独沟通，了解项目成员对自己工作和个人职业发展的一些真实想法，项目的发展和个人的发展是个有机的整体，两者相互促进，需要让项目成员感受到在做项目过程中个人技能的提高和个人成就感的增加。3)项目组应该定期组织相关的聚会和活动，加强项目成员间相互的沟通和了解，活跃项目气氛，因为可以把这种轻松和活跃的氛围传递到日常紧张的工作任务中，让项目成员更多感受到工作的乐趣。

三、过程环境与支持管理**********

软件配置管理是一个辅助性的软件生命周期过程，对软件项目进行版本控制、变更管理等活动，能够记录软件任一时刻的状态并支持回溯。提炼为三个方面的内容：版本控制；变更控制；过程支持。关键活动包括：配置项、工作空间管理、版本控制、变更控制、状态报告、配置审计等。
软件配置管理过程包括7项基本活动：(1) 制定配置管理计划；(2) 识别和标志配置项；(3) 搭建配置管理环境；(4) 配置项的版本控制；(5) 基线变更管理；(6) 配置审核；(7) 配置状态统计
软件配置管理最佳实践：统一标识配置项并存入安全的配置管理系统；控制和审计配置项的变更；合理组织配置项；在项目的里程碑建立相应的基线；记录和跟踪变更请求；过程驱动的软件配置管理；维护稳定而一致的工作空间；支持并行开发；尽早和持续集成；确保有能力重现软件的构建过程；把握好工具、流程和人员三者之间的关系；善用模式和反模式；
4个比喻：软件资源的保险箱：存储库（Repository）、影集：配置管理系统应该能够重现整个软件系统在某一历史时刻的构造、版本管理、基线、变更；软件项目的时间机器：获得系统的最新配置，获得系统在历史某一时刻的配置，组合出任意时刻、任意状态的系统配置，在新团队中自动修复缺陷；4.很多作者一起写一本书：并发开发。团队合作◆ 对于项目的同一个局部，开发人员可以即同时工作，又互不干扰。◆ 对于系统的多个版本，以核心配置为基础 、并行的开发路径 、合并各方的结果 ◆ 异地合作
项目存储库：存放所有项目所有资源的中心数据库。
基线和快照?基线就是组件的“版本”，代表的是某时某处某组件的状态。一条基线由一个或多个变更集构成。快照代表整个流的配置基线，可以是包含多个组件基线的组合基线。快照的作用：可以通过快照来重建和更新工作空间；可以通过基线替换来更新流内的组件配置；也可以进行快照比较。
流与组件：流是一个共享的开发区域，对应于某个开发团队。组件是一组相关文件或目录的集合。组件在软件配置管理中的作用：组件可以用来组织和管理企业的软件资产、可以服务于若干个软件项目，或者一个软件产品中的若干个模块、每个组件都能够进行独立开发和分开部署，便于软件团队分工协作、组件可以由“基线”标识其变更历史，便于区别和利用。 组件是软件配置管理中支持复用的基石，可以大大提高敏捷团队开发效率。变更集：变更集包含了对文件或目录个体内容的变更（例如删除、修改、转移等操作）。
主线与支线：通往最终产品的开发线。从主线分离出的独立开发线。
项目区域： 一个项目的最顶层的组织，包含了相关的项目团队、资产、流程等诸多内容、不同的项目区域用于开发不同的软件产品、存储库中可以存放多个项目区域，项目区域包含了一个或者多个团队区域
团队区域：项目中的不同开发团队和组织独立拥有的区域，包含了这些团队各自拥有的团队成员、角色划分、工作流程和相应资产。 团队区域确定了项目中团队的组织架构
存储库工作空间与本地工作空间：开发人员需要将组件从存储库中取出来，放到自己的工作空间中才能进行编辑。 工作空间又称为“砂盒”，隔离开发人员之间的干扰，使独立进行开发工作、科学高效的管理开发者的任务、是个人工作成果提交的基础环境，也是个人自由工作的环境
存储库工作空间：存储在服务器上，其中组件需要被下载到本地工作空间才能进行编辑
本地工作空间：团队成员个人工作PC 中的本地目录
存储库和本地工作空间之间的联系与区别：存储库工作空间：驻留在服务器端 、将组件以基线的方式来管理，可以选择性的装入；本地工作空间：驻留在用户工作台，是实际的工作区域，也是存储库和外 部进行数据交换的唯一通道，必须拷贝特定的组件版本进行编辑 存储库工作空间与组件、流之间的映射关系 每个团队成员有自己的存储库工作空间，其默认流向目标 （flow target）就是团队流。 每位团队成员的变更结果提交、合并，最终在流中形成了团队开发结果。
配置管理的作用：用于管理不断发展的软件项目或产品、项目管理的重要辅助机制：减少人为错误、提高开发效率、保护项目资源、一种技术和策略相结合的管理手段、明确的过程和标准、 高效实用的工具
敏捷开发中的配置管理:敏捷开发对配置管理的更高要求:更协同的团队配置管理、更协同的并行开发、完全基于任务的配置管理、开发过程与配置管理的紧密结合、更高效的工作区模式
常用的开源免费的软件配置管理工具：SVN、GIT、CVS
软件配置管理工具的主要功能：版本控制；变更管理；配置审核（配置审计）配置状态统计（查询和报告）；问题跟踪（跟踪缺陷和变更）；访问控制和安全控制
软件配置管理工具选择：功能；是否符合团队特点？性能；费用是；售后服务；易用性

四、过程监控与度量**********

过程度量与监控：软件过程的实施过程中要对软件过程进行管理，一方面要保证软件项目遵循已建立的过程，进度是可控的，这就需要采取一定的监控技术；另一方面，需要将过程进展情况量化以评估过程实施质量，即进行过程的度量，进而优化和改进软件过程。因此，过程管理是实时、持续的，贯穿项目始终。
过程度量的意义：过程度量能够为软件团队提供用于评估的参考，有助于帮助软件团队实施成功的过程、自我评价软件过程能力、积累经验并对过程进行改进。
软件过程监控：在实际软件开发过程中，往往会产生一些偏离过程的活动，例如工作效率过低、资源分配不足、突发事件等等。这些活动如果置之不理，势必会对原定的软件过程造成影响，软件过程监控就是为了确保软件过程能够高质量的运行而实施的一组活动。
如何做好过程监控？过程监控是否有效关键在于两方面：一方面是监控点的选择，即选择合理的监控时机；另一方面是监控内容的确定与验证。采取一定的监控技术；同时需要将过程进展情况量化以评估过程实施质量，进而优化和改进软件过程，从而实现好对过程的监控，选择合理的监控时机（按里程碑监控；周期性监控；按进度比例监控）；对监控内容进行确定与验证。
监控内容能支撑哪些指标？监控内容：进度，效率，过程结果，工作状态，隐患；支撑的指标：进度偏差，工作量偏差，生产率，质量成本，返工成本指数，重构率，活动缺陷发现密度；指标体系：绩效评价指标体系：源代码，bug数，代码覆盖率，设计、开发约束。
监控项目工作过程关注：把项目的实际绩效与项目管理计划进行比较；评估项目绩效，决定是否需要采取纠正或预防措施，并推荐必要的措施识别新风险，分析、跟踪和监测已有风险，确保全面识别风险，报告风险状态，并执行适当的风险应对计划；在整个项目期间，维护一个准确且及时更新的信息库，以反映项目产品及相关文件的情况；为状态报告、进展测量和预测提供信息；做出预测，以更新当前的成本与进度信息；监督已批准变更的实施情况；如果项目是项目集的一部分，还应向项目集管理层报告项目进展和状态监控项目工作属于项目整合管理领域，监控过程组；输入（项目管理计划、进度预测、成本预测、确认的变更、工作绩效信息、事业环境因素、组织过程资产）；工具与技术（专家判断、分析技术、项目管理信息系统、会议）；输出（变更请求、工作绩效报告、项目管理计划更新、项目文件更新）。
监控项目工作是跟踪、审查和报告项目进展，以实现项目管理计划中确定的绩效目标的过程。本过程的主要作用是，让干系人了解项目的当前状态、已采取的步骤，以及对预算、进度和范围的预测。监督是贯穿于整个项目的项目管理活动之一，包括收集、测量和发布绩效信息，分析测量结果和预测趋势，以便推动过程改进。持续的监督使项目管理团队能洞察项目的健康状况，并识别须特别关注的任何方面。控制包括制定纠正或预防措施或重新规划，并跟踪行动计划的实施过程，以确保它们能有效解决问题。

五、质量运动与过程改进**********

软件质量为“与软件产品满足规定的和隐含的需求能力有关的特征或者特性的全体”。
质量改进的基本要素6C “变革管理的六个阶段”：①领悟——理解质量真谛②承诺——制定质量策略的决心③能力——教育与培训④沟通——成功的经验 文档化、制度化⑤改正——预防与提高绩效⑥坚持——强调质量管理成 为一种工作方式
如何提高软件的质量？1.需求分析：首先需要确保清楚你的程序应该做什么。需要考虑需求之间的兼容性，是否可以实现所有要求，是否存在某些硬件限制2.软件设计：首先考虑解决方案，如何实施,需要使用哪些算法,哪部分代码可以重用,可以使用哪些库,不同的组件和类如何相互通信等。3.编码指南：它定义了要使用的编码风格，这样你的代码就会有一个统一的风格 - 可读。4. 定期审查：与其他团队成员一起进行设计和代码审查。5.静态代码分析：使用静态代码分析工具。这些工具可以分析源代码而无需运行它。6.单元测试：单元测试有助于确保在每次更改时没有破坏已经正在运行的功能，并且可以帮助其他程序员了解代码的用途。7.组件和系统测试：对组件或系统进行更高级别的测试。8. 持续集成：使用CI系统（如Jenkins）设置持续集成服务器，让它在每次新更改的情况下每晚运行构建并检查代码。9.错误跟踪：在bug跟踪系统中跟踪已发现的错误（例如：Mantis）。对于每个错误，记录如何重现它们以及它与预期行为的不同之处。10.分析和内存使用：为了能够保持软件的性能，定期测量其运行时间。
过程改进是在软件过程工程中为了更有效地达到优化软件过程的目的，所实施的改善或改变其软件过程的系列活动。过程改进的关键是发现软件过程中所存在的问题和缺陷，而过程度量正是发现问题和缺陷的必备手段。
度量软件过程通常要关注的主要对象包括：过程自身、过程结果和活动。不同对象所要度量的内容和使用的方法略有不同。 1）对过程自身的度量；要衡量软件过程本身的完成情况，常见的指标有进度、成本、工作量等。对于进度，软件项目在计划阶段会定义进度指标，可以在项目实施过程中的各个里程碑与计划指标对比来度量；成本的度量也并不困难，因为这些数据是可量化的，也有计划指标加以参考。 2）对过程结果的度量；软件过程的产生结果主要是各种软件工件，即文档、源程序等。主要的度量目标有：规模、结构和质量。 规模最常用长度或功能来表示，例如模块中代码行数、文档页数、规格说明中的功能点数目等等。 结构主要指软件架构，度量往往针对软件的模块结构、控制流、数据流、控制结构等方面的设计，以此来界定软件的复杂度。 质量有很多的评价准则，在软件工程发展过程中逐渐产生了一些成熟的质量模型，比较常见的有McCall模型、Boehm模型和ISO模型。 3）对活动的度量；活动是软件过程的基本组成部分，对活动的度量即是对成员行为的度量。每位团队成员每天的任务分解为一系列简短的活动，团队内部通过同级评审会议来评价活动的成效，由于很多软件活动在不同的软件项目过程中是可参考甚至可复用的，因此经过长期积累，团队能够形成基于活动的一套度量体系。
过程改进的两种模式：目标驱动模式：目标驱动的过程改进模式是指根据一个预先给定的目标，自顶向下制定过程度量或评价模型，有目的地开展相关改进活动的过程改进模式；缺陷驱动模式：缺陷驱动的过程改进模式是指根据过程实施时所产生的关于过程缺陷的反馈信息，进行有针对性改进活动的过程改进模式。
软件过程改进的6条基本原则：对软件过程的重大变更必须是自上而下的、每个人都必须参与、有效的变更需有现行过程的目标和对它的深入了解、变更要持续进行、软件过程变更如果没有自觉的努力和定期的强化将不会持久、软件过程改进需要有必要的投入。
成熟的软件组织：具有全面而充分的组织和管理软件开发和维护过程的能力；管理员监视软件产品的质量以及生产这些产品的过程；制定了一系列客观基准来判别产品质量，并分析产品和过程中的问题；进度和预算可以按照以前积累的经验来制定，结果可行。预期的成本、进度、功能与性能和质量都能实现，并达到目的；能准确及时地向工作人员通报实际软件过程，并按照计划有规则地(前后一致，不互相矛盾)工作；凡规定的过程都编成文档；软件过程和实际工作方法相吻合。必要时，过程定义会及时更新，通过测试，或者通过成本-效益分析来改进过程。全体人员普遍地、积极地参与改进软件过程的活动。在组织内部的各项目中，每人在软件过程中的职责都十分清晰而明确，每人各守其责，协同工作，有条不紊，甚至能预见和防范问题的发生。
不成熟的软件组织：软件过程一般并不预先计划，而是在项目进行中由实际工作人员及管理员临时计划；有时，即使软件过程已计划好，仍不按计划执行；没有一个客观的基准来判断产品质量，或解决产品和过程中的问题；对软件过程步骤如何影响软件质量，一无所知，产品质量得不到保证。而且，一些提高质量的环节，如检查、测试等经常由于要赶进度而减少或取消。产品在交付前，对客户来说，一切都是不可见的；没有长远目标，管理员通常只关注解决任何当前的危机；由于没有实事求是地估计进度、预算，因此他们经常超支、超时。当最后期限临近，他们往往在功能性和质量上妥协，或以加班加点方式赶进度。
质量运动和过程改进的关系：过程改进为了提高质量，质量运动为了提高过程改进中的质量意识，从而达到质量运动的目的，提高质量。
质量要素有哪些？功能性，可靠性，易使用性，效率，可维修性，可移植性。
如何分析质量问题？PDCA模型，建立过程控制措施，将计划转入实施阶段，评价实施绩效，将实际绩效与质量目标对比，对差异采取措施。
如何改进过程活动？首先进行过程评估，找到当前过程运行能力的不足，然后提出改进措施。CMM模型，对过程中的某些指标定性，定量分析，最后得出结果，提出改进措施对比分析。
提升过程能力？①使用过程管理具②使用合适的过程改进模型③注重问题，强调知识创新，鼓励参与，领导层的统一，不断地改进。
DEAL模型解决了软件组织在各种质量改进环境下的 需要。它包括了软件过程改进周期中的五个阶段， IDEAL是代表这五个阶段的单词的首字母。I: Initiating 开始D: Diagnosing 诊断、评价E: Establishing 建立A: Acting 执行L: Leveraging 调整
PDCA模型其实每月的质量月报、质量分析会议的思想基础和方法依据就是PDCA循环。PDCA循环的含义是将质量改进分为四个阶段，即计划（plan）、执行（do）、检查（check）、调整（Action）。在质量管理活动中，要求把各项工作按照作出计划、计划实施、检查实施效果，然后将成功的纳入标准，不成功的留待下一循环去解决。八个步骤：1.分析现状，找出问题；2.分析影响质量的原因；3.找出措施；4.拟定措施计划；为什么要制定这个措施？达到什么目标？在何处执行？由谁负责完成？什么时间完成？怎样执行？5.执行措施，执行计划；6.检查效果，发现问题；7.总结经验，纳入标准；8.遗留问题转入下期PDCA循环。
戴明（Deming）十四点原则。树立改进产品和服务的坚定目标；采用新的思维方法；停止依赖检验的办法获得质量；不再凭价格标签进货；坚持不懈地提高产品质量和生产率；岗位培训制度化；管理者的作用应突出强调；排除畏难情绪；打破部门和人员之间的障碍；不再给操作人员提空洞的口号；取消对操作人员规定的工作定额和指标；不再采用按年度对人员工件进行评估；创建积极的自我提高计划制度；让每个员工都投入到提高产品质量的活动中去；
过程管理工具在一个完整的软件生命周期过程中，应用于各个环节的工具有很多，例如：需求分析：Power Designer、Clear Quest等；架构设计：Rational Software Architect、Rose等；
语言编程：Visual Studio、Eclipse等；软件测试：Rational Functional Tester、Borland Silk等；配置管理：Clear Case、Visual Source Safe等；项目管理：Microsoft Project、Rational Portfolio Manager等
RTC是基于Jazz平台的团队协作工具，用于集成软件生命周期内的任务。RTC的主要功能包括以下方面： 开发生命周期中的协作和集成、过程配置和定制、变更管理、计划、软件配置管理、构建自动化、报告。质量改进（Quality Improvement）为向本组织及其顾客提供增值效益，在整个组织范围内所采取的提高活动和过程的效果与效率的措施。质量改进是消除系统性的问题，对现有的质量水平在控制的基础上加以提高，使质量达到一个新水平、新高度。

说起质量改进（例子，结合项目）背景：团队特点：1.我所处团队主要承接公司某BG下各分子公司的产品研发，项目众多且运营模式、规模、业务、语言、架构各不一样。2.团队新组建，成员中新人居多，做事风格及流程规范方面未形成一致。痛点：1.领导及业务部门不清楚各项目的质量情况2.项目质量好坏无数据度量、项目间无客观的比较3.质量改进措施效果是否有效无数据支撑4.项目团队之间交流少，缺少相互借鉴学习的机会。方案：第一步：质量月报设计1.月报采用汇总页+各项目详情页的设计风格2.汇总页展示所有项目的质量概述、线上问题、过程数据、各项目指标对比的图表等信息 3.详情页展示单个项目的版本情况、缺陷数据、测试产物、开发建议等信息4.除上述表格统计的数据外，月报中还自动生成了图表，查看和分析起来会更加直观。缺陷趋势：可以通过趋势图清晰的看出各缺陷指标是否收敛，来判断改进措施是否有效。
项目间对比：把各项目的同一指标进行横向对比，能够清晰看出哪个项目质量相对较好或较差。5.小结：通过对需求答疑、版本发布、CodeReview、缺陷、测试产物、线上问题等多维度进行统计分析，得出各项目的质量情况和存在的问题，进而来推动质量改进。由于工作量及技术原因，目前统计的指标较片面，后续会持续的优化改进，加入更多的维度和指标，让项目的质量度量更加科学合理。
第二步：自动化统计：对于上面设计的月报，前期的数据都是采用人工统计，经过几轮实践发现存在较多弊端。如：人力成本高、指标统计方法不一致、数据丢失等。后面我们采用python实现了自动化统计工具，来获取Jira、RDM系统上的缺陷数据，并生成质量月报，不仅节约了人力，也提高了数据的准确性。
第三步：人工分析：拿到自动生成的数据后，仅需人工补充项目里程碑节点、质量概述、风险、测试产物、开发建议等信息。然后对问题版本、线上问题、缺陷数据进行分析，分析未达标指标的原因，提出改进建议。第四步：质量分析会议：每月的质量月报发出后，会组织各项目的开发组长、测试组长召开质量分析会议，议题如下：1.跟踪上月的改进事项，并查看改进效果2.分析本月项目存在的问题，制定改进措施3.做的好的项目分享改进建议及心得总结：团队从17年4月开始做质量月报，至今已有11，统计的项目从最开始的3个发展到现在的近10个；月报内容从单一的表格到现在的图表集合；度量指标从单一维度到现在的全阶段覆盖；统计方式从人工统计到现在的自动化统计；在些感谢所有参与质量月报工作的童鞋，你们的付出都是有价值的，因为我们看到了所有项目质量的提升。

这篇关于软件工程过程总结的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！