软件过程复习

软件过程基本理论与技术（40）（CMM，RUP,迭代开发，敏捷开发，XP,Scrum,软件构建，重构技术，配置管理,过程评价）过程的定义IEEE-Std-610定义“过程”是为完成一个特定的目标而进行的一系列操作步骤，如软件开发过程。SEI－CMM 定义过程是用于软件开发及维护的一系列活动、方法及实践! 软件过程的分类和组成软件基本过程：软件获取、供应、开发、运行和维护的过程，包括需求分析、软件设计、编码等过程。软件支持过程：对软件主要过程提供支持的过程，包括文档编制过程、配置管理过程、质量保证过程、验证和确认过程（测试过程）、评审过程等。软件组织过程：对软件主要过程和支持过程的组织保证过程，包括管理过程、基础设施过程、改进过程和培训过程。过程规范就是对输入/输出和活动所构成的过程进行明文规定或约定俗成的标准。软件过程规范是软件开发组织行动的准则与指南，可以依据上述各类过程的特点而建立相应的规范，如软件基本过程规范、软件支持过程规范和软件组织过程规范。为什么需要软件过程即使软件开发团队拥有了最先进的编程技术和工具支持，也不一定能够保证软件项目的成功；而采用什么样的过程将人力、技术、方法、工具等要素有机结合起来逐渐成为关系到项目成败的重要因素，因此也逐渐出现了对“软件过程”的研究。软件是抽象的软件没有生产流水线。软件是不断更改的。软件的质量难以控制软件开发过程是指在完成某个软件项目的过程中，开发目标软件所经历的步骤，是一系列软件活动的集合。软件工程过程有两方面的含义：一是指为了指导和控制软件开发过程，经总结、抽象形成的一组规范的集合；二是指一门专门研究软件开发过程的学科，即“研究过程的工程”。软件工程过程是按照软件工业化的标准定义的在软件开发中必须具有的一系列过程规范；软件工程过程是定义软件中的软件需求、软件设计，软件编码、软件测试、软件部署的实现目标和规范化的管理方法论；软件工程过程是保证软件工业化生产的法典；软件工程过程做的是：定义标准和为了达到标准的路；软件工程过程要改善的是：软件开发的效率和质量；软件工程过程的实现最重要的是：人软件过程的比较CMM也是一个标准，它要求我们应该做到什么，而没有告诉我们应该如何做。XP告诉我们如何做，但是没有明确的指出，做到以后该如何改进；ISO9001是工业标准，但是不是软件业的工业标准；RUP和CMM结合，把RUP的九个工作流和CMM2、3级的KPA结合起来是一种趋势；UML成为交流的工具软件过程理论的基石：软件产品和服务的质量，很大程度上取决于生产和维护该软件或者服务的过程的质量。软件过程改进框架：软件过程改进环境（软件过程改进架构，软件过程改进计划，软件过程改进规划图，软件过程评估办法）I: Initiating 开始 D: Diagnosing 诊断、评价 E: Establishing 建立A: Acting 执行 L: Leveraging 调整PSP着重于软件开发人员的个人能力提升，体现在估算能力、计划能力、计划执行以及质量管理等方面。PSP作用个人级别估算和计划。承诺和拒绝承诺。理解和改进。工业水准的过程和规范。客观决策的数据。PSP是包括了数据记录表格、过程操作指南和规程在内的结构化框架。一个基本的PSP流程包括策划、设计、编码、编译、单元测试以及总结等阶段。在每个阶段，都有相应的过程操作指南，用以指导该阶段的开发活动所有的开发活动都需要记录相应的时间日志与缺陷日志。PSP基本原则软件系统的整体质量由该系统中质量最差的某些组件所决定；软件组件的质量取决于开发这些组件的软件工程师，更加确切的说，是由这些工程师所使用的开发过程所决定；作为合格的软件工程师，应当自己度量、跟踪自己的工作，应当自己管理软件组件的质量；作为合格的软件工程师，应当从自己开发过程的偏差中学习、总结，并将这些经验教训整合到自己的开发实践中，也就是说，应当建立持续地自我改进机制。TSP能够提供了 ①一个已经定义的团队构建过程；②一个团队作业框架； ③一个有效的管理环境。TSP启动过程：商业目标-分配角色-产品开发策略-整体计划-质量目标-分期计划-风险评估-准备管理评审-管理评审-评估启动过程TSP（团队软件过程）：是为开发软件产品的开发团队提供指导，TSP的早期实践侧重于帮助开发团队改善其质量和生产率,以使其更好的满足成本及进度的目标。21:TSP实践：①一个已经定义的团队构建过程②一个团队作业框架。③一个有效的管理环境22:团队软件过程TSP基于以下4条基本原理:①应该遵循一个确定的、可复的过程并迅速获得反馈，这样才能使学习和改革最有成效;②一个群组是否有效，是由明确的目标、有效的_工作环境、有能力的教练和积极的领导这4方面因素的综合作用所确定的，因此应在这4个方面同时努力，而不能偏废其中任何一个方面;③应注意及时总结经验教训，当学员在项目中面临各种各样的实际问题并寻求有效的解决问题方案时，就会更深刻地体会到TSP的威力;④：应注意借鉴前人和他人的经验,在可知利用的工程、科学和教学法经验的基础上来规定过程改进的指令。RUP采用Use case的概念。RUP采用迭代的思想把系统的风险分布在四个阶段，风险越大的迭代越要放在靠前的阶段做;RUP的中心元素有三个1.用于成功开发软件的一组基本原则:这些原则是开发RUP的基础。2.可重用方法内容及流程构件块的框架:方法插件系列定义了方法框架，从该框架您可以创建自己的方法配置及定制的流程。3.底层方法及流程定义语言:统一方法体系结构元模型提供了用于描述方法内容及流程的语言。认识MSF1)它是一种框架结构1一种帮助提供技术决策指南的观点。2一组反复跟踪、监控和管理项目及其进展的参考方法。3一致的重用性保证在灵活的计算环境中有效的利用已有的知识和技能2)一个资源的集合1联机资料2.CD-ROM知识库3.教学课程4完整的参考手册3)它在不断发展RUP与MSF比较1.MSF不错的过程方法,简单，实用，线条清晰。2.RUP整体更具备严谨性，和适应性。3.RUP提供了一套丰富的被在工业中清晰定义和良好理解的术语集合4.MSF依赖于微软特定的文化和人员素质特性，使用MSF实践需要企业文化的改变以及项目团队成员的承诺和投入5.MSF中的一些过程方法可以按照UMA的方式整合企业自己的方法体系中RUP 产品开发时考虑了两组主要用户: 作为项目团队一部分的软件开发执行人员，包括项目干系人/过程工程执行人员，尤其是软件过程工程师和经理。为什么要使用RUP？1.RUP 向软件开发执行人员提供了一种基于标准，但又可以配置的流程环境。该流程环境：允许发布已定制的方法，并可供整个项目团队访问/允许按每个项目的独特需要对方法进行配置/向每个用户提供定制过滤2.RUP本质上是软件工程实践的集合体，这些实践将不断地定期改善以反映行业实践变化。对项目干系人。RUP提供了一个术语词汇表和一个知识百科全书，以帮助您向软件开发团队有效地传达您的需要。对软件开发执行人员。RUP提供一个核心的、通用的流程定义，确保队员可以共享该定义，这样有助于改善团队沟通。RUP在软件开发实践中提供了丰富的指导。对经理或团队负责人。RUP向您提供一个流程，您可以通过该流程与员工进行有效地沟通，以及相应地管理和控制他们的工作。对流程工程师。RUP向您提供很好的体系结构基础和大量的材料，您可以用它们来构造您的流程定义。业务驱动开发的6个原则：提高过程的适应性；平衡有竞争的涉众的优先级；团队协作；体现迭代的力量；提升抽象级别；持续关注质量RUP9个规程需求规程、业务建模规程、配置和变更管理规程、环境规程、项目管理规程、分析与设计规程、实施规程、测试规程、部署规程RUP的6个最佳实践：迭代开发；管理需求；使用基于组件的构架；可视建模；持续的质量验证；控制变更。迭代开发先启阶段：确定项目范围和边界条件；确定用例和主要场景，将会驱动权衡主要的设计；对一些主要场景展示候选架构；估量总时间和费用；找出潜在的风险(不可预测的资源)；为项目准备环境支持；评估标准：项目干系人参与的范围定义与成本和进度估算。捕获一组正确的需求并且对这些需求有共同的理解。成本和进度估算、优先权、风险和开发过程必须是恰当的。已经识别所有的风险并且存在一个可以解决该风险的对策。精化阶段：尽早的定义、确认架构基线；确定架构的风险；确定愿景；为构造阶段创建一个详细的计划；证明架构基线在合理的时间、合理的成本内符合愿景；细化的支持环境评估标准：稳定的产品愿景和需求。稳定的架构。关键的测试和评估；指出并且解决主要的风险元素。构造阶段：为移交阶段完成软件产品。优化资源、避免不必要的报废和返工，最小化开发成本。尽可能快的达到质量标准。尽可能快的实现可用的版本(alpha, beta和其他测试版本) 评估标准：产品是否能够在用户中稳定地发布并且成功的部署？是否所有的项目干系人都准备好把产品移交到用户？实际资源支出是否于计划中的相符？移交阶段：实现用户的自营。实现项目干系人赞同与评估愿景一致来完成基准线的部署。在一个快速和高效益的方式下完成最后的产品基线确定。评估标准：用户是否满意? 实际资源支出是否在计划支出的范围内？什么是迭代：一个有基线计划的不同顺序的活动，或者能够产生一个产品的发布的评价标准（内部或者外部）。迭代是通过了多个阶段。各阶段的交付产品各不相同，这取决于它们所在的生命周期和项目的性质。一个迭代可以看做是有计划、可交付、可评估的的小项目。并且这些项目的评估和修正也适合于剩余的项目。影响迭代持续时间的因素：大小、稳定性和组织成熟度；熟悉迭代过程；项目的大小；技术简单的项目；用来管理代码、发布信息并且执行测试的自动化水平风险管理策略：风险回避—重组项目，以致于它不会受风险的影响。风险转移—重组项目，让别人承担风险。风险接受—承受，这意味着你必须视试着低风险，减小概率或者减轻影响并且找到一个应急计划 (“B计划”). 通过以下方法降低所接受的风险：创造一个风险列表工件。采取一些立竿见影、主动的措施来减小风险发生概率和减轻风险的影响。定义一个意外事件计划客观度量度量用来提供给开发团队：迄今为止进展情况的准确评估。深刻理解不断变化的软件产品的质量。依据成本和进度的估计完成产品。迭代开发中七个核心指标：管理指标：工作和进展（随着时间推移的工作）预算成本和支出（随着时间推移的费用）工作人员和团队动态（随着时间推移的人员变动）质量指标：改变通信量和稳定性（随着时间推移的通信量改变）缺陷和模块化（随着时间推移每个变更导致的缺陷）返工和适应性（随着时间推移每个变更导致的返工）平均故障间隔时间（MTBF）和成熟度（随着时间推移的故障率）RUP与敏捷敏捷方法使软件团队具有快速工作、快速响应变化能力，与RUP相比，敏捷模型在人员、方法、产品等方面的论述远不如RUP全面、详细。RUP是可配置过程，未给出对于特定项目（例如：有限资源和时间约束）的完整配置方案。RUP与XP-共性1基础都是面向对象方法2都采用迭代，增量开发方式3都是基于风险驱动4都重视代码、文档的最小化和设计的简化5采用动态适应变化的演进式迭代周期6强调需求和测试管理7鼓励用户积极参与RUP与XP-差异1.XP以代码为中心，编码和设计活动融为一体，弱化了架构的概念RUP过程通常以架构为中心，细化阶段的主要目的就是构造出一个可运行的架构原型，作为将来添加需求功能的稳固基础。2.XP有一个非常关键的假设就是:开发人员只注重眼前需求，依赖重构来适应需求的变动，这样所带来的风险、开销要小于需求变化使得事先充分设计失效的代价;反之，实施XP就是不明智的3.XP不包含业务建模、部署、过程管理等概念。4.RUP更加强调项目的可控性。5.可以将XP中的最佳实践纳入到RUP之中。6.RUP经过裁减后适合各种规模的项目，XP只适用于小团队。7.XP实践依赖团队成员的强关系而RUP对团队成员的关系紧密程度要求弱一些平衡敏捷和规范：1敏捷与规范，软件开发中看似对立的两个属性，实际上相得益彰。2计划驱动的开发人员必须敏捷，敏捷开发人员必须规范。成功的关键在于找到两者的平衡点。3这个平衡点随项目所处的环境以及所涉及的风险而变化。仅凭一腔热情径直地采用极端方法的开发人员，必须学会如何根据实际情况恰当地平衡敏捷与规范。敏捷宣言：个体和迭代，超越过程和工具；工作的软件，超越完整的文档；客户协作，超越合同谈判；响应变更，超越履行计划敏捷过程：个体和交互胜过过程和工具。可以工作的软件胜过面面俱到的文档。客户合作胜过合同谈判。响应变化胜过遵循计划。XP的四个核心价值：沟通：问题往往是由于开发人员与设计人员、设计人员与客户之间的沟通不畅造成的。简单：应该尽量保持代码的简单，只要它能工作就可以与其实现一个复杂的的系统，不如设计一个能够满足目前需要的、简单的系统，因为你所考虑的情况可能永远都不会发生。反馈：尽快获得用户的反馈，并且越详细越好，使得开发人员能够保证自己的成果符合用户的需要。勇气：这是最重要的核心价值。因为XP强调要”拥抱变化”，因此对于用户的反馈，要勇于对自己的代码进行修改，丢掉坏的代码。极限编程的原则：1．所有的代码都必须有单元测试 2．所有的代码在发布之前必须通过所有单元测试 3．当一个BUG发现时，就增加新的测试 4．经常运行验收测试，并公布分数推荐工具：Junit结对编程就是由两名开发人员在同一台计算机上共同编写解决同一个问题的程序代码，通常一个人编码，另一个人对代码进行审查与测试，以保证代码的正确性与可读性。结对编程是加强开发人员相互沟通与评审的一种方式。Scrum: 是一种迭代式增量软件开发过程，通常用于敏捷软件开发。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队。什么是敏捷软件开发?1.敏捷软件开发是软件项目的一个概念框架.有许多建立在敏捷概念上的方法，如 Scrum 和 Extreme Programming (XP).2.与僵化的、重量级的、官僚式的方法形成对照，比如瀑布模型（指纯粹形式的）3.最大限度地降低短期固定时间的迭代式软件的开发风险.敏捷过程的限制1.敏捷软件开发过程包含过程、原则、工具和最重要的-人2.因此诚信是基础3.没有过程能够对诚信进行有效地约束4.诚信与否是有效实施敏捷过程的最大限制传统项目管理：事先对整个项目进行估计、计划、分析。反对变更; 变更需要重新估计、重新规划。严密的合同来减少风险, 如果改变需求要走 CR 流程.。项目作为一个“黑盒子” ，对客户与供应商的可视性差.。产品化和测试阶段是分离的.。文档和计划驱动的方法.。软件交付时间晚, 意识到风险的时间晚敏捷项目管理:对整个项目做一个粗略的估计,每一次迭代都有详细的计划.鼓励变化, 客户价值驱动开发.信任和赋予权力;合约使变更变得简单，增加价值.客户和开发人员之间是紧密的连续的合作关系。每次迭代都产生可交付的软件。专注于交付软件。第一次迭代就可交付能工作的版本，风险发现的早. 敏捷原则：1. 优先级最高的是，通过早期和持续交付有价值的软件来满足客户。 2. 欢迎变更需求，即使在开发的后期提出。敏捷过程为客户的竞争优势而控制变更。 3. 以两周到两月为周期，频繁地交付可运行的软件，首推较短的时间定量。 4. 在整个项目过程中，每一天开发人员都要和业务人员合作。 5. 由个体推动项目的建设，为个体提供所需的环境，支持和信任。 6. 在开发团队中或开发团队间传递信息的最为有效和高效的方法是面对面的交谈。 7. 衡量进展的重要尺度是可运行的软件。 8. 敏捷过程提介可持续的开发。 9. 发起人，开发者和用户应该步调一致。 10.不断地关注技术上优越的设计会提高敏捷性。 11.简洁是最重要的，简洁就是尽量减少工作量的艺术。 12.最佳的架构，需求和设计来自于自组织的团队。 13.团队要定期反省如何使工作更有效，然后相应地调整行为。敏捷的项目有三个主要阶段 :产品定义 (规划); 运行Sprints 所需要的准备、规划、技术分析。执行Sprints (执行): 在增量时间段内实现需求 (产品需求清单)。结束: 准备最终发布，结束项目Scrum的最佳实践1迭代式软件开发方法2两层项目规划3团队的整体协作能力（Whole Team）4软件持续集成原则。Scrum开发过程三个要素1角色2活动3工件Scrum中的三种角色1.Product Owner- 产品所有者个人：代表所有的干系人2.Scrum Master: 个人：负责指导过程的执行3.Scrum Team – Scrum团队:承诺完成工作，向干系人交付产品价值活动定义的主要活动包括冲刺规划会议（Sprint Plan Meeting）、每日站立会议（Scrum Daily Meeting）、冲刺复审会议（Sprint Review Meeting）和冲刺回顾会议（Sprint Retrospective Meeting）。工件在Scrum中，工件包括产品订单（Product Backlog）、冲刺订单（Sprint Backlog）、燃尽图（Burn Down Chart）、新的功能增量（New Functions Increment）等实体概念。自适应软件开发（Adaptive Software Development）着眼于人员协作和团队自我组织。包含思考、协作和学习三个阶段。敏捷常见误解：敏捷是拯救任何项目的银弹.（敏捷方法只有运用得当才有效果.）敏捷意味着ad-hoc hacking ，不需要任何文档.（敏捷是有严格要求的，也是面向质量的根据沟通的需要产生相应的文档.）敏捷只是开发者的问题（基本的开发方法与传统相比有显著不同, 影响项目的各个方面: 合同, 角色, 定价模型, 项目管理等.）采用敏捷方法的开发组/项目不需要制定计划（敏捷项目需要经常制定计划，但是不需要试图超前制定项目计划，通常这也是不可能的.）敏捷项目的范围可以随时改变.（变更可以等到下一次迭代开始，当前正在进行中的迭代不能变更）只对小项目适用（在中型和大型的项目中一样取得了成功）软件构建技术：软件构建指的是通过编码、验证、单元测试、集成测试和调试的组合，详细地创建可工作的、有意义的软件。软件构建具体包含什么活动，是由采用的生命周期过程所决定的。在经典的生命周期模型中，软件构建过程活动包含了软件编码相关活动、部分详细设计活动和部分软件测试活动。在敏捷模型中，软件构建过程是与其他软件开发过程（计划、需求、设计等）并行或重叠进行的，这时更倾向于将设计、编码和测试活动组合起来称为“构建”活动。软件构建原则：最小的复杂性。要预测变更。为验证而构建。构建方式：手工构建（通过javac编译代码）通过IDE构建（eclipse自动编译）通过自动化构建工具（maven和ant自动构建）要考虑的问题：在软件构建过程中，要充分考虑到软件的质量，提高其可复用性、可维护性，主要考虑的方面有：持续集成。软件重构。软件复用和质量。软件重构技术：软件重构是在不改变代码外在行为的前提下，对代码进行修改以改进程序的内部结构，即软件重构只是将软件的内部结构进行调整，提高其可理解性，降低修改的成本。重构时间：“三次原则”可以作为重构时机的参考，即“事不过三，三则重构”。也就是说，第一次编写全新的代码尽管去做；第二次编写类似的代码虽然令人反感，但还是直接去做；第三次再做类似的事情，这时就应该重构。不需要重构：重构也不是随意的活动，除了存在必须重构的情况，同时也有一些不允许重构的情况，例如：程序原型不能重构；代码不能正常工作时不需要重构；在项目接近尾声时不能重构；重构方法：重新组织函数。在对象之间迁移特征。重新组织数据。简化条件表达式。简化函数调用。处理概括关系。大型重构。软件测试技术软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。Junit测试工具 JUnit是一个开放源代码的Java测试框架，用于编写和运行可重复的测试。他是用于单元测试框架体系xUnit的一个实例（用于java语言）。它包括以下特性：用于测试期望结果的断言（Assertion）。用于共享共同测试数据的测试工具。用于方便的组织和运行测试的测试套件。图形和文本的测试运行器。注意事项： 1.测试方法必须使用注解 org.junit.Test 修饰。2.测试方法必须使用 public void 修饰，而且不能带有任何参数。3.单元测试代码和被测试代码使用一样的包，不同的目录。4.注解 org.junit.Test 中有两个非常有用的参数：expected 和 timeout。5.org.junit.Ignore 用于暂时忽略某个测试方法，因为有时候由于测试环境受限，并不能保证每一个测试方法都能正确运行。先说说软件配置管理的定义及目的，再解释以下软件配置管理的相关术语软件配置管理是一个辅助性的软件生命周期过程，对软件项目进行版本控制、变更管理等活动，能够记录软件任一时刻的状态并支持回溯。软件配置管理的目的，是通过将错误减少到最低来实现生产力的最大程度提高。1. 项目存储库：存放所有项目所有资源的中心数据库。2. 流与组件流：是一个共享的开发区域，对应于某个开发团队。组件是一组相关文件或目录的集合。3. 变更集：变更集包含了对文件或目录个体内容的变更（例如删除、修改、转移等操作）。4. 基线与快照：基线就是组件的“版本”，代表的是某时某处某组件的状态。快照代表整个流的配置基线，可以是包含多个组件基线的组合基线。5. 主线与支线：通往最终产品的开发线。从主线分离出的独立开发线。配置管理的作用1.用于管理不断发展的软件项目或产品2.项目管理的重要辅助机制(减少人为错误/提高开发效率/保护项目资源)3.一种技术和策略相结合的管理手段(明确的过程和标准/高效实用的工具)敏捷开发中的配置管理敏捷开发对配置管理的更高要求:1.更协同的团队配置管理.更高的团队沟通效率。项目以及团队的组织架构、角色都应该与配置管理环节相关联。工具应该将项目、团队信息纳入管理环节。2.更协同的并行开发.并行开发中需要更多的协同能力，跨各个并行开发的信息应该是清晰的，可以灵活被传递的。3.完全基于任务的配置管理.配置管理应该以任务和变更为驱动，版本变化的目的与意义是任务和变更。同时，任务和变更会提高沟通效率、个人工作效率，提高变更响应速度4.开发过程与配置管理的紧密结合.配置管理中的开发过程与工具的紧密结合，过程控制的自动化提高团队协作效率，减少过重的流程要求，提高敏捷化。5.更高效的工作区模式.需要更高效的工作区开发模式，团队/个人的变化通知可以及时了解，主动性的接受与拒绝。过程评价：以一系列的标准对软件过程的质量进行评定而使软件过程不断改进和优化的系列活动。过程评价/过程评估：SEI在 “评价/评估指南”“评估指南”：当用户以过程改进为出发点，对自身机构的软件过程进行评定时：1.评定过程现有的过程能力2.预见其能力，潜在缺陷和改进方向。“评价指南” 仅是客观评定过程能力当时所达到的程度。无论是过程评价还是过程评估，其目的都是：认知过程能力、比较过程能力、改进过程能力。过程评价有多种实现方法，其中过程度量便是一种最有效且最系统化的方法，其他诸如问卷调查、实际走查（walk through）等也是实现过程评价的常用方法过程度量模型就是要研究过程度量所涉及的属性和问题，从而规范过程度量的内容和步骤，实现过程度量的目标。

团队与团队文化建设（10）发挥团队智慧两大挑战：确定整体架构之前很难进行分工。鼓励团队成员在讨论和评审会议中的参与程度。团队设计面向整体开发，因此需要额外考虑如下内容：团队智慧的使用。设计标准。设计复用。设计的可测试性支持。设计的可用性支持等要求团队实现策略：评审的考虑。复用策略。可测试性考虑集成策略选择：大爆炸集成策略。逐一添加集成策略。集簇集成策略。扁平化集成策略。团队项目规划– 工作分解结构– 开发策略与计划– 生命周期模型– 日程/质量/风险计划团队项目跟踪与管理– 挣值管理– 里程碑评审– 纠偏活动管理WBS作用范围基线/提供整体观/不遗漏可交付物/明确各个角色的责任/工作包定义/估算和计划的基础/理解工作，分析风险创建WBS方法1识别和分析可交付成果及相关工作2确定工作分解结构的结构与编排方法3自上而下逐层细化分解4为工作分解结构组成部分制定和分配标志编码5核实工作分解的程度是必要且充分的好的WBS检查标准1最底层要素不能重复，即任何一个工作包应该在WBS中的一个地方且只应该在 WBS中的一个地方出现2所有要素必须清晰完整定义，即相应的数据词典必须完整定义3最底层要素必须有定义清晰的责任人，可以支持成本估算和进度安排4最底层的要素是实现目标的充分必要条件，即项目的工作范围得到完整体现范围管理包括确保项目做且只做成功完成项目所需的全部工作的各过程.WBS为范围管理提供了基准.1收集需求2定义范围3创建WBS 4核实范围5控制范围变更人员角色评审-项目组长• 项目组长的角色评审应当从领导力角度开考察团队的表现。• 重点关注团队激励和团队承诺方面的问题。• 项目会议的组织情况也需要总结。比如，会议效果、讨论技巧等。• 此外，还应当就如何在下一周期做得更好提出改进建议。人员角色评审-计划经理• 计划经理主要关注项目进度，因此，在总结阶段需要就估算、生产效率、里程碑等话题进行总结。人员角色评审-开发经理• 开发经理进行总结的时候，应当从开发内容和开发策略角度出发，总结得失。人员角色评审-质量经理• 质量经理的总结则应该从项目整体质量状况出发，总结质量目标的实现过程，并找出改进机会。人员角色评审-过程经理• 过程经理关注团队遵循过程的程度和过程改进方案。因此，在项目总结阶段，过程经理需要总结的问题为：– 是否所有人都如实记录数据？人员角色评审-支持经理• 支持经理主要关注配置管理状况、问题和风险跟踪机制以及复用策略的支持等话题。因此，在项目总结阶段，支持经理需要总结的问题为：– 项目团队开发环境是否合用？人员角色评审-工程师• 此外，由于大部分角色经理同时充当着软件工程师的角色，因此，还需要就工程师角色的工作状况进行总结。工程师重点关注的就是个人的绩效（生产效率、质量水平等）。因此，需要总结的问题包括：– 个人计划的绩效与实际的绩效有没有差别？自主团队具备如下的特点：– 自行定义项目的目标– 自行决定团队组成形式以及成员的角色– 自行决定项目的开发策略– 自行定义项目的开发过程– 自行制定项目的开发计划– 自行度量、管理和控制项目工作自主团队的外部环境:项目启动阶段获得管理层的支持。在项目进展过程中获得管理层的支持承诺文化的建立与团队激励通常用以激励团队成员的方式有三种：“威逼”、 “利诱”以及鼓励承诺按照马斯洛关于人的需求层次的理论，人的需求大致分成五个不同的层次。– 第一层：生理需求– 第二次：安全感– 第三层：爱和归属感– 第四层：获得尊敬– 第五层：自我实现角色经理团队领导者告知倾听、指导询问、说服激励/挑战、决定促进达成一致、控制教练、监控授权、设定目标挑战团队文化是指团队成员在共同工作中形成的一种价值观、行为模式和社交规范。团队文化建设对软件工程过程至关重要，因为一个良好的团队文化可以促进协作、提高生产力和创造优秀的软件产品。以下是团队文化建设的贡献情况说明：促进团队合作良好的团队文化可以鼓励团队成员之间相互信任和支持。团队成员会更倾向于分享知识，并且能够更好地协作完成任务。这有助于减少项目延迟和错误，促进团队效率和成功。提高工作动力一个积极、充满活力和友好的团队文化可以激励成员参与工作和增强工作动力。成员们会更愿意投入时间并尝试新的想法和方法。打造创新氛围团队文化对于推动创新也非常重要。当团队成员从不同背景和专业领域汇集在一起时，他们能够交流各自的经验和知识，激发出新的想法和创新。建立共同价值观团队文化还有助于建立共同的价值观。这意味着成员将会更容易接受并实施项目目标和价值观，并且能够更好地了解其他成员的需求和期望。提高工作满意度良好的团队文化可以提高成员的工作满意度。这是因为成员与团队共享相似的价值观和目标，同时也能够获得尊重和支持，从而增强他们对工作和团队的投入感和忠诚度。

过程环境与支持管理（15）软件过程环境以过程为中心的组织-软件过程架构-软件过程实施-软件过程评估-软件过程改进软件过程文化过程至上，奉过程为教条，一切围绕着过程，组织、质量和效率都服从于过程，过程的执行严格，过程结果可靠、稳定，认为生产的“东西”是过程的一个节点，只是全局的一部分。但效率较低，缺乏灵活性、创造性。2以过程为焦点，关注过程，强调过程的重要性，但不拘于过程，让过程服从于质量和效率、服从于组织的业务目标……

3过程只能起辅助作用，人决定一切, 过程可能流于形式…项目管理过程是计划、跟踪和协调项目执行及生产所需资源的管理过程。项目管理过程的活动，包括软件基本过程的范围确定、策划、执行和控制、评审和评价等。质量管理过程是对项目产品和服务的质量加以管理，从而获得最大的客户满意度。此过程包括在项目以及组织层次上建立对产品和过程质量管理的关注风险管理过程，在整个项目的生命周期中对风险不断的识别、诊断和分析，回避风险、降低风险或消除风险，并在项目以及组织层次上建立有效的风险管理机制子合同商管理过程，选择合格的子合同商并对其进行管理的过程。软件组织过程业务规划过程是为组织与项目成员提供对愿景的描述以及企业文化的介绍，从而使项目成员能更有效地工作。定义过程是建立一个可重复使用的过程定义库，从而对其它过程等提供指导、约束和支持改进过程是为了满足业务变化的需要，提高过程的效率与有效性，而对软件过程进行持续的评估、度量、控制和改善的过程。人力资源和培训过程，为项目或其它组织过程提供培训合格的人员所需的活动基础设施过程是建立生存周期过程基础结构、为其他过程建立和维护所需基础设施的过程。需求管理需求确认，需求跟踪，变更控制。需求定义指的是解释涉众需求,并根据需求规模整理成对要构建系统的明确的说明。前景文档是用一般的语言定义系统特征的文档软件需求规格说明书是用更专业的术语定义系统特征的文档。项目管理项目管理就是将知识、技能、工具与技术应用于项目活动，以满足项目的要求。成功的项目管理是指在一定的时间和成本范围内，按一定的质量标准完成项目，并得到客户的认可。质量保证（Quality assurance）为使人们确信软件质量满足用户需要所必须的全部有计划有组织的活动。关注于过程改进。质量控制（Quality control）对开发过程中的软件产品的质量特性进行连续的收集和反馈，通过质量管理和配置管理等机制,使软件开发过程向着既定的质量目标发展。关注于项目软件产品。共同点：QC和QA都是为了保证产品的质量，都需要进行验证区别：

QC和QA的主要区别前者是保证产品质量符合规定；后者是建立体系并确保体系按要求运作，以提供内外部的信任。QA独立于QC之外，QA审查项目的质量控制是否按照指定的体系来完成。质量管理八大原则以顾客为中心；领导作用；全员参与；过程方法；系统的管理方法；持续改进；基于事实的决策方法；互利的供方关系质量管理规划质量管理 (启动过程组)实施质量保证 (实施过程组)实施质量控制 (执行过程组) 项目时间管理规划进度管理 (规划过程组)定义活动 (规划过程组)排列活动顺序 (规划过程组)估算活动资源 (规划过程组)估算活动持续时间 (规划过程组)制定进度计划 (规划过程组)控制进度 (监控过程组) 项目成本管理规划成本管理 (规划过程组)估算成本 (规划过程组)制定预算 (规划过程组)控制成本 (监控过程组)

过程监控和度量（15）如何建立软件过程？从现有的成熟的软件生存周期模型中选择/对模型加以改进/自定义过程软件生命周期软件从诞生到消亡的整个生存过程六个主要过程：制定计划、需求分析、设计、程序编码、测试及运行维护软件过程包括:软件生命周期模型软件产品开发相关的过程、活动和任务的框架，这些过程、活动和任务覆盖了软件整个生存周期.传统软件生命周期模型瀑布模型（采用结构化的分析和设计方法将逻辑实现与物理实现分开。它将软件生命周期划分为计划、需求分析、设计、编码、软件测试和运行维护六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。优点：过程有计划分工明确缺点：理想化，不灵活。产品交付延迟，反应慢）渐增模型（渐增模型通常采用“二次开发”的模式（通常以瀑布模型开发两次），优点在于缓解了瀑布模型不灵活，用户无法预判系统正确性的问题；缺点在于，需要严格、小心的控制过程，否则容易退化成“边做边改”模型，而且重复开发势必带来了成本上的增加。）螺旋模型（螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型的阶段相符合。每个螺旋周期可分为 4 个步骤：第一，制定计划，即确定目标，选定实施方案，明确开发限制条件；第二，风险分析，即分析所选方案，识别风险，通过原型消除风险；第三，开发实施，即实施软件开发；第四，用户评估，即评价开发工作，提出修改意见，建立下一个周期的计划。螺旋模型加强了用户与开发人员的交流，兼有瀑布模型与演化模型的优点。尽管螺旋模型能够很大程度上保证产品是成功的，但却不能保证项目是成功的，进度、成本的压力使项目本身不可能无休止的重复。因此，风险分析是螺旋模型的核心活动，每次循环之前，都要评估下一次循环对项目产生的影响，保证项目的进度和成本在可控范围内。）喷泉模型（喷泉模型适合于面向对象的开发方法，它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。喷泉模型支持软件复用，有利于多项开发活动集成，但需要大量开发人员同时开发，不利于项目管理。使用喷泉模型时，文档必须严格管理以确保统一性。喷泉模型适用于使用面向对象开发方法的软件项目。）原型模型（原型模型以迭代式开发为思想，针对需求分析难以完整、准确，或者可实现性难以验证的问题，首先构建一个软件原始模型给用户体验，反馈意见，通过不断更新或者多次重复开发，得到最终软件。优点：易明确需求、易验证方案、用户快速体验与反馈缺点：需要工具和方法支持，以保障进度和成本）现代软件生命周期模型RUP模型/敏捷过程/微软解决方案框架软件过程的实施过程中要对软件过程进行管理，一方面要保证软件项目遵循已建立的过程，进度是可控的，这就需要采取一定的监控技术；另一方面，需要将过程进展情况量化以评估过程实施质量，即进行过程的度量，进而优化和改进软件过程。因此，过程管理是实时、持续的，贯穿项目始终。度量的客观性是指所得到的关于某对象的度量值是该对象的真实描述。度量的主观性是指所得到的关于某对象的度量值是由度量者的主观判断得到的，因此所得到的度量值会随度量者的不同而异。过程度量的意义过程度量能够为软件团队提供用于评估的参考，有助于帮助软件团队实施成功的过程、自我评价软件过程能力、积累经验并对过程进行改进。过程度量的对象度量软件过程通常要关注的主要对象包括：过程自身、过程结果和活动。不同对象所要度量的内容和使用的方法略有不同。对过程自身的度量：要衡量软件过程本身的完成情况，常见的指标有进度、成本、工作量等软件过程的产生结果主要是各种软件工件，即文档、源程序等。主要的度量目标有：规模、结构和质量。规模最常用长度或功能来表示，例如模块中代码行数、文档页数、规格说明中的功能点数目等等。结构主要指软件架构，度量往往针对软件的模块结构、控制流、数据流、控制结构等方面的设计，以此来界定软件的复杂度。质量有很多的评价准则，在软件工程发展过程中逐渐产生了一些成熟的质量模型，比较常见的有McCall模型、Boehm模型和ISO模型。度量活动是软件过程的基本组成部分，对活动的度量即是对成员行为的度量。过程监控原因：在实际软件开发过程中，往往会产生一些偏离过程的活动，例如工作效率过低、资源分配不足、突发事件等等。这些活动如果置之不理，势必会对原定的软件过程造成影响，软件过程监控就是为了确保软件过程能够高质量的运行而实施的一组活动。过程监控是否有效关键在于两方面：一方面是监控点的选择，即选择合理的监控时机；另一方面是监控内容的确定与验证。过程监控原则：按里程碑监控：在软件过程的里程碑监控，可以对进度、结果质量等进行全面检查。周期性监控：按固定的时间跨度进行监控，例如：每周进行一次检查。按进度比例监控：根据项目的特点或者项目规模，规定每完成进度的多少比例时进行一次检查，例如：每完成进度的10%进行一次检查，那么在完成进度的10%、20%、30%……时进行检查。有了软件过程度量技术的支持，可以在多个层面对过程的执行质量进行检查，主要监控的内容有：进度。效率。过程结果。工作状态。进度：一个软件项目往往包含若干里程碑，在里程碑处可以检查项目是否滞后于计划进度。效率：计划效率=计划工作量/计划工时，同理，实际效率=度量工作量/实际工时。项目经理在制定计划时，往往预先估计到达某个里程碑所需的工作量，从而得到计划效率。借助工作量度量技术，可以随时监控实际工作效率。过程结果：即使工作量和进度达到了计划规定，也并不标志着执行了高质量的过程，还要检查过程结果（代码、文档等）的质量。监督过程结果需要借助软件质量度量技术。工作状态：监督团队成员是否在按照计划执行任务，同时考察其工作积极性。隐患：检查资源（人力、成本、软硬件等）分配与占用情况，以防资源过早消耗对后续过程产生影响；如果发生突发活动（例如需求变更），那么要估计对现有过程产生的影响。1：Tsp的信息获取：①：需求获取②：需求汇总③需求验证④需求文档制作（形成一个完整的需求规格说明书）软件需求规范（SRS）：1：引言2：系统定义3：应用环境4：功能规格5：性能需求6：实现约束7：质量描述8：其他要求9：参考材料10：签字认证⑤团队设计（除了设计过程与PSP一致，还要考虑团队智慧的使用、设计标准、设计复用、设计的可测试性支持、设计的可用性支持等要求）⑥团队智慧⑦设计标准⑧复用性支持、可测试性考虑、验证与确认。2：RUP中的软件生命周期的四个阶段及对应里程碑：初始阶段：生命周期目标里程碑。细化阶段：生命周期结构里程碑。构造阶段：初始功能里程碑。交付阶段：产品发布里程碑。

质量运动和过程改进（20）IDEAL模型：它描述了实现软件过程改进所必需的阶段、活动和成功的过程改进工作所需要的资源。IDEAL模型解决了软件组织在各种质量改进环境下的需要。它包括了软件过程改进周期中的五个阶段，IDEAL是代表这五个阶段的单词的首字母。过程改进与质量改进的关系质量改进是社会发展的原动力；过程改进是实现价值提升的基本方法过程成熟度标准软件过程能力；软件过程性能；软件过程成熟度2.1.1 软件过程不成熟的特点软件过程能力低，不能按预定计划开发出客户满意的产品，项目拖延、费用大大超出预算已成惯例。2过程性能的不可预见性，对进度和预算估计、产品质量的目标缺乏历史数据和有效方法的客观基础，开发的进度、成本和产品的质量都难以预测。3过程的不可视性，软件过程缺乏定义、缺乏文档和缺乏跟踪，在整个软件过程中，不清楚每个阶段进出的标准、执行的方法和规则。4过程的不稳定性，实际的、具体的操作过程是在一个项目开始后临时拼凑而成，每个项目都不一样。5过程的被动性、缺乏改进的主动性。2.1.2 软件过程成熟的标准软件过程能力高，具有全组织范围的管理软件开发和维护过程的能力。2软件过程性能可预见性，对进度、预算和质量做出现实的和准确的估计和预测。3软件过程规范化，可遵循的标准、规则和指导性原则。4过程的一致性5过程的丰富性6过程的可视性7过程的稳定性8过程的不断改进质量运动指的是一种旨在提高软件产品质量的方法论和实践活动。它强调通过对软件开发过程进行全面优化来提高软件产品的质量，而不是仅仅依靠测试和修补缺陷来达到这个目标。质量运动的主要目标是确保软件产品具有高度的可靠性、可维护性、可用性、安全性和可扩展性。为此，它通常会采取一系列措施，包括：强调敏捷开发、持续集成和持续交付等最佳实践，以确保软件开发过程的高效性和可追溯性。2引入代码审查、单元测试、集成测试、系统测试和用户验收测试等多个层次的测试机制，以确保软件产品的功能完整性和稳定性。3引入代码质量评估、性能测试、安全测试等专业工具，以确保软件产品的技术质量和安全性。4实行合理的需求管理、变更管理和缺陷管理体系，以确保软件产品的稳定性和可维护性。CMM为了改进过程，需要首先进行过程评估，找出当前过程运行能力的不足，然后提出改进措施。软件生产商通过软件评估，在保证业务目标的前提下，改进软件过程。软件过程改进的核心原则软件过程改进的核心原则有五条，分别是：注重问题，强调知识创新，鼓励参与，领导层的统一，不断地改进。过程改进的关键是发现软件过程中所存在的问题和缺陷，而过程度量正是发现问题和缺陷的必备手段。软件过程改进模型 CMM不仅是评估模型，也是过程改进模型，其中定义了几种方法。两个实施和改进的一般模型：质量改进范例（Quality Improvement Paradigm，QIP）和启动—诊断—建立—行动—学习模型（IDEAL），过程实施的评价结果可以是定性的或定量的。过程改进的两种模式目标驱动模式。目标驱动的过程改进模式是指根据一个预先给定的目标，自顶向下制定过程度量或评价模型，有目的地开展相关改进活动的过程改进模式；缺陷驱动模式缺陷驱动的过程改进模式是指根据过程实施时所产生的关于过程缺陷的反馈信息，进行有针对性改进活动的过程改进模式。RTC的主要功能包括以下方面：开发生命周期中的协作和集成。过程配置和定制。变更管理。计划。软件配置管理。构建自动化。报告。过程的基本概念过程就是人们使用相应的方法、规程、技术、工具等将原始材料（输入）转化成用户需要的产品。过程的3个基本要素是：人、方法与规程、技术与工具。过程与产品存在因果关系。即好的过程才能得到好的产品，而差的过程只会得到差的产品。过程被文档化后才能成为规范。软件过程改进的根本目的是：提高质量、提高生产率并且降低开发成本。为了真正提高软件过程能力，企业至少要做三件最重要的事情：首先制定适合于本企业的软件过程规范。对员工们进行培训，指导他们依据规范来开发产品。购买一些软件工程和项目管理工具，提高员工们的工作效率。文档太多怎么办机构要下功夫制定出结构良好的文档模板，给出充足的提示和示例。这样使用者就可以“依葫芦画瓢”，总比他自己琢磨怎样写要方便得多。提高开发人员的写作能力，这是练内功。一是要学习好的写作方法，二是要不断地练笔（其实写文档就是在练笔）。CMM 初始级：项目的实施不可预测。组织缺乏明文的管理办法，软件工作没有稳定的环境，制定了计划又不执行，反应式驱动工作开展。紧急情况下已定的规程丢在一边，急于编码和测试。个别项目的成功依赖于某个有经验的管理人员；个别管理人员能顶住削减过程的压力，但他们离职则全然不同。规定的过程无法克服由于缺乏有效管理带来的不稳定性。能力：不可预测。可重复级：建立了基本的软件过程，可跟踪成本、进度、功能和质量 -基于以往项目经验，制定了过程实施规范，项目管理过程稳定，软件机构可重复以前成功项目中所进行的软件项目工程实践。–如有分包，其质量也能得到控制。–能力：稳定的策划和跟踪。已定义级–完整的软件过程，实现了标准化和文档化 –针对特定项目，可将标准软件过程进行剪裁。– 固定的过程工作小组– 制定和实施了人员培训大纲，保证人员能够胜任岗位知识和技能要求– 管理活动和过程活动稳定，成本、进度、功能和质量可控，软件产品质量具有可追溯性。– 能力：稳定的管理和技术活动已管理级– 对软件过程（过程模型及过程实例）和生产率和软件产品质量建立了定量的目标，所有重要的过程活动都是可度量的。 – 新应用领域的风险可知可控，可在定量的范围内预测过程和产品的质量趋势，并在偏离时即使予以纠正。– 能力：过程可度量优化级– 不断的过程改进。可得到软件过程有效性的统计数字，并用于对新技术的成本 / 效率分析，优化出最佳实践方法。自知过程的薄弱环节，可预防缺陷的出现。可通过对当前过程的分析，评价对新技术或将出现的变更作出评价。重视探索创新活动，并将成功的创新推广。出现的缺陷得到分析，找出原因，防止再次发生，教训为其它项目吸取。– 能力：过程可优化CMMI的三个模型：CMMI-SVC帮助服务性组织去建立质量服务过程架构使其能够更好的改进服务表现和提高企业的服务收益性。CMMI-ACQ模型帮助组织或企业为他们的客户进行外包、采购、交易或者其他采购产品服务提供了管理架构。CMMI-DEV模型帮助生产服务开发组织整合他们的软件开发和系统工程来改进他们本身的性能和提高过程改进的效率。过程域按类划分：组织级的过程定义、过程焦点、过程性能、创新和部署等（过程管理过程）配置管理。产品与质量保证。度量分析。原因分析与解决方案。决策分析与解决方案（支持过程）项目的监督控制。集成项目管理。项目定量管理。风险管理等（项目管理过程）需求管理与开发。技术解决方案。产品集成。确认。验证（工程过程）软件过程能力企业实施软件过程所能实现预期目标的程度，可用于预测企业的软件过程水平。软件过程行为企业在项目开发中遵循其软件过程所能得到的实际结果。软件过程成熟度软件过程行为可被定义，预测和控制并被持续性提高的程度。主要用来表明不同项目所遵循的软件过程的一致性。软件能力成熟度等级企业的软件开发在由低到高成熟化演进过程中所普遍面临的具有一定成熟度标志特征的平台软件过程静态方面当软件过程仅以某种特定的描述形式存在时，过程质量就表现为静态的一面。此时的过程质量实际上就是软件过程描述本身所具备的属性，它表现为：功能性：该过程描述满足实际需要的程度；易使用性：用户使用该过程描述进行过程实施和运作所需的努力程度，其中包括易理解性和易学习性等子特性；准确性：描述特定类型的软件过程的准确程度，可包含精确性、一致性、完整性、冗余度等子特性；易维护性：用户在改进基于该描述形式的软件过程时所需的努力程度，其中包括易分析性和易修改性等子特性。软件过程动态方面当软件过程在执行运作时，过程质量就表现为动态的一面。此时的过程质量是以软件过程所表现出的过程运作能力来衡量，其中包括过程运作能否达到所预定的目标、是否保证了软件产品的质量等，可以简称为过程能力。过程制度化：过程文化：人们的习惯和行为受到过程思维和过程管理原则的影响。过程基础设施。CMMIC Capability 能力M Maturity 成熟度M Model 模型I Integration 集成CMMI是过程评估的检查单2过程改进的指导书，行业最佳实践3过程审计的依据CMMI的表达式分为两种Staged—阶段式Continuous—连续式

在项目实践中应用了哪些RUP的最佳实践**？用例建模：通过对系统所需功能进行建模，确定系统的需求和范围，并将其转化为可执行的测试用例，以确保系统能够满足用户需求。迭代开发：采用迭代的方式逐步实现系统的功能，每个迭代都需要完成一定的工作量，并且必须被完整测试和验证。构建和发布管理：使用自动化构建和部署工具来管理代码库和版本控制，并确保每个版本的完整性和可部署性。风险管理：识别、分析和管理项目中存在的风险，制定相应的应对策略，以提高项目成功的概率。团队协作：强调团队成员之间的有效沟通和协作，以确保所有人都理解项目目标和进度，并能够共同努力实现这些目标。过程改进：对项目过程进行评估和反思，在项目结束后总结经验教训并制定改进措施，以促进组织的不断发展和提高。在项目实践中对敏捷过程产生的具有感悟**？1需求变化是常态敏捷过程强调快速响应客户需求的变化，因此在项目实践中，我们会经常遇到需求的变化。这需要开发团队具备灵活的思维和快速的响应能力，以确保更好地满足客户需求。2团队协作至关重要敏捷过程注重团队协作和自组织，因此在项目实践中，我们必须建立一个高效的团队，并运用各种工具和方法来促进团队沟通和协作。只有这样，才能确保项目的顺利进行。3持续交付有助于降低风险敏捷过程强调持续交付有价值的软件，这可以帮助我们及早发现问题并及时解决。同时，每次迭代都会生成可运行的软件，这有助于客户更好地理解项目进度和软件功能，降低项目风险。4需要不断改进敏捷过程是一种不断改进的过程，以确保我们能够不断学习和提高。在项目实践中，我们需要定期进行团队回顾和反思，总结经验教训并找出改进的空间，以持续提高项目的质量和效率。在项目实践中采用了什么手段实现过程度量？代码行数统计：通过统计代码行数来衡量开发人员的工作量和项目进展情况。这种方法比较简单，但是容易被工程师轻易地操纵。功能点分析：通过事先定义好的功能点来度量项目完成情况。这种方法需要在项目启动前进行详细的需求分析，并且需要专业的功能点测量工具和技术支持。成本效益分析：使用成本效益分析工具来计算项目的成本效益比，以判断项目的经济效益是否达到预期。质量评估：通过软件质量评估指标来度量项目的质量。这种方法需要在项目执行过程中对代码、文档、测试等方面进行评估，结果更加客观、实际。测试覆盖率：使用自动化测试工具来度量测试覆盖率，以确保软件能够满足预期的功能和性能要求。通过度量发现了哪些问题，进行了哪些改进？项目延迟：如果项目延迟了，可能是因为开发人员无法按时完成任务或者出现了其他问题。通过度量，可以确定哪些部分需要更多的时间和注意力，并采取相应的措施来加快进度。成本超支：过高的成本可能是由于低效率、错误或其他原因引起的。通过度量，可以确定成本超支的根本原因，并采取相应的措施来控制成本。缺陷率过高：缺陷率过高可能会导致项目失败或延迟。通过度量，可以确定缺陷率高的原因，并采取相应的措施来减少缺陷。代码重复率过高：过高的代码重复率可能会导致代码维护困难、效率低下等问题。通过度量，可以确定代码重复率高的原因，并采取相应的措施来减少代码重复。代码质量低：低质量的代码可能会导致许多问题，包括性能问题、安全漏洞等。通过度量，可以确定代码质量低的原因，并采取相应的措施来提高代码质量。开发人员效率低：低效率可能是由于流程不当、缺乏培训或其他原因引起的。通过度量，可以确定效率低的原因，并采取相应的措施来提高效率。基于CMM的过程改进是目标驱动的过程改进模式。基于CMM的过程改进步骤如下：（1）确定本机构目前的CMM成熟度级别，明确下一步需要达到的级别：CMM要求一个机构的成熟度级别应当从第2级开始并逐步升级实施，不允许进行成熟度级别的跨越实施。（2）初始化过程改进：应当将过程改进本身作为一个项目来进行管理和策划。过程改进策划的内容包括：需确定详细步骤和活动及所涉及的里程碑、所涉及的关键人物、资源、进度，并确保所有相关人员得到并确认所策划的内容。3）准备并实施过程评价:由于当前所处的级别已经明确，可以直接利用CMM得到当前软件机构的过程评价结果。例如，假如当前级别已被评价为3级，则可根据第2、3级所标明的能力特点、关键过程域、关键实践来表明本机构当前的过程评价结果（4）分析评价结果和制定改进活动计划:根据所希望达到的CMM级别的关键过程域中对目标、执行约定、执行能力、执行活动、测量和分析、验证执行等关键实践的要求，列出各子目标，对每个子目标，详细计划所需增加的活动、资源、度量方法或工具、验证手段等，并依此制定达到每个子目标的具体计划和实施策略。（5）实施改进活动:依照计划实施改进活动，注意应有必要的监控手段。6）确认改进结果1.组织合格的评估师对所进行的改进活动进行评价，以判定是否达到本机构所希望达到的CMM级别。2.对于那些希望其CMM级别获得SEI认可的软件机构而言，所聘请的评估师必须获得SEI颁发的CMM评估师资质，而对那些仅希望通过CMM评价达到自身改进目标的软件机构而言，可在本机构内部组织进行CMM级别的评价，其方式可模仿SEI要求的评价方式，也可用自身特有的方式进行评价，以判断是否达到了所希望的CMM级别。（7）维持和监督改进的结果:努力将机构维持在新的CMM级别上。应当建立有效的监控机制来保持已达到的级别的持续性。对于CMM5级的机构而言，由于这样的监控机制已经制度化，机构只需保持该制度的正常执行，就能确保改进结果的持续性。但对于其他级别的机构而言，应当指定专门人员监督新级别的维持，并赋予足够的权限。（8）重复1到7通过一个学期的学习，请你谈谈你对软件工程过程这门课的理解，并请提出对这门课的意见与建议。对软件工程过程的理解。通过一个学期的学习，我认为软件工程过程是一种系统化、规范化的方法，用于管理和开发软件项目。它不仅关注于软件产品本身，更关注于软件开发的整个过程。软件工程过程包括需求分析、设计、编码、测试、维护等多个阶段，并采用了各种工具和技术来提高软件开发效率和质量。在这门课上，我学到了许多软件工程过程的基本概念和实践技巧。例如，软件需求工程、软件设计模式、软件测试方法和过程改进等方面的知识，这些都对我的日后从事软件开发工作有很大的帮助。此外，在这个过程中还学习了如何与团队成员合作，如何有效地沟通和交流，如何协调和管理项目进度和风险等重要技能。对这门课的意见与建议1. 实践与理论结合在学习软件工程过程的时候，我们需要更多地将理论知识应用到实际项目中去。希望课程能够通过更多的案例和实践活动，让我们更深入地了解软件工程过程各个阶段的操作和实践经验。2. 更新内容随着时代的变化和技术的不断更新，软件开发过程也在不断地演变和改进。因此，希望课程也能及时更新课程内容，使学生能够获得最新的知识和技能。3. 更多互动在这门课程中，我们需要和其他同学进行合作、交流和讨论。但是，有时候课堂上的讨论并不充分或者略显被动。因此，希望老师能够提供更多互动的机会，让学生更积极地参与讨论和交流。同时，还可以通过在线平台等方式，在课外时间进一步加强交流和合作。我国软件开发存在的问题（1）质量意识淡薄，企业从上到下都缺乏正确的产品质量意识，只注重完成软件产品的功能，忽视产品的质量问题。（2）体制不灵活，不健全，导致质量监督不力。由于体制问题造成软件人才不必要的流动，同样是因为体制问题造成实际上企业的软件资产流失。（3）做产品的概念不浓，大多只为短期的经济利益，做短期的项目。（4）形式化的东西太多，为追求评奖或完成项目，报喜不报忧。（5）软件企业的交流少，思想保守。（6）对新技术研究的跟进、投入少。（7）多数项目盲目采用国外技术，没有从自身问题入手，寻找适合产品开发的技术和过程。工具使用项目管理项目管理是指通过规划、组织、监督和控制资源来达成项目目标的过程。在软件工程过程中，项目管理工具通常包括计划、任务分配、进度跟踪、风险管理等功能。以下是一些常用的项目管理工具：Trello：Trello 是一个简单而直观的看板式项目管理工具，可用于团队协作、任务分配、进度追踪、文档共享等。Asana：Asana 是一个全功能的项目管理工具，可用于任务管理、进度跟踪、文件共享、团队讨论等。JIRA：JIRA 是一款流行的跟踪和管理问题的工具，它可用于敏捷开发、版本控制、缺陷管理等。配置管理配置管理是指对软件开发生命周期内的软件产品进行追踪和控制的过程。配置管理工具可以帮助团队管理各个版本的代码和文档，并确保所有成员都使用相同的版本。以下是一些常用的配置管理工具：Git：Git 是目前最流行的版本控制系统之一，它可以跟踪变更、协作以及管理代码。Subversion：Subversion 是一个中心化的版本控制系统，可用于管理文档和代码等各种类型的数据。变更管理变更管理是指对软件开发过程中的需求变更进行有效跟踪和管理的过程。以下是一些常用的变更管理工具：GitHub：GitHub 是一个基于 Git 的代码托管平台，除了提供版本控制功能外，还提供了问题跟踪、协作、自动构建等功能。Bitbucket：Bitbucket 是另一个基于 Git 的代码托管平台，它与 JIRA 集成，可用于敏捷开发和协作。Scrum和XP最佳实践的应用总结：Scrum产品待办列表（Product Backlog） - 创建一个清晰的、有优先级的任务列表，并与团队共享。保持待办事项简单明了、可测量和可分解。冲刺计划（Sprint Planning） - 与团队一起创建一个可执行的计划，以在下一个迭代中完成一组任务集。冲刺回顾（Sprint Review） - 回顾上一个迭代中已经完成的工作，以及未来如何改进和提高。每日站会（Daily Standup） - 每天同步团队进度，让所有人都知道自己正在做什么，并协调解决可能存在的问题。燃尽图（Burndown Chart） - 通过跟踪项目中的工作量，燃尽图可以显示剩余工作量和进度是否满足预期。XP测试驱动开发（TDD） - 在编写代码之前编写单元测试，以确保代码质量和正确性。这将消除很多代码错误。持续集成（Continuous Integration） - 持续整合代码，防止开发人员在开发过程中出现意外错误造成的问题，并确保代码质量。短期迭代（Short Iterations） - 将开发分解为小的、可重复的任务集，以改进开发流程并降低风险。团队编程（Pair Programming） - 两个开发人员一起编写代码，增强协作和知识共享，并提高代码质量。简单设计（Simple Design） - 设计要尽可能简单，易于理解和修改。避免过度设计和不必要的复杂性。