软件项目管理
 
第1章 软件项目管理概述
1、项目的基本概念（注意与日常运作的区分）和特征；
2、软件项目及特征；
3、项目管理的基本概念；
4、项目管理知识体系（以2017年发布的PMBOK6的十个知识领域为准）；
5、适用于软件项目管理的知识体系。
  
​第2章 项目确立 &第3章 生存期模型【项目初始】
1、理解项目启动的基本过程（项目评估、项目立项、招投标、发布项目章程）；
2、项目章程的主要内容和作用；
3、理解各生存期模型的优缺点及适用场景。
  
第4章 软件项目需求管理
1、软件需求的概念及层次；
2、需求工程的组成。
需求获取和包含的主要活动。
需求分析的主要内容和处理不明确需求
如何做好需求变更管理
  
第6章 软件项目成本计划（含第5章 任务分解）
1、软件项目成本管理的总体过程；
2、软件项目成本的组成；
3、WBS的作用、特点及分解方法；
4、软件项目规模估算的基本方法（LoC、FP、UCP）；
5、软件项目成本估算的各基本方法（专家判定、类比、自顶向下、自底向上、算法模型）及特点；
6、理解软件项目成本预算；
7、软件项目成本控制（监控），掌握赢得值分析法各种量的计算。
任务分解及作用
项目管理度量指标
  
第7章 软件项目进度计划（重点！！）
1、软件项目进度管理的总体过程；
2、活动之间的逻辑关系（FS、SS、FF、SF）及依赖关系（强制、选择、内部、外部）；
3、活动排序的网络图（ADM和PDM的区分、特点）；
4、项目历时估计的方法（重点在CPM和PERT）；
5、时间压缩法中的赶工（掌握时间压缩与成本增加呈线性的情况）
6、甘特图和里程碑图的基本特点。
7.何谓正推法？简述其计算任务历时的基本步骤及计算公式
  
第8章 软件项目质量计划
1、软件质量的基本概念和内涵；
2、软件质量模型；
3、软件质量保证(QA)常见活动、质量控制(QC)常见活动，两者区别。
  
第9章 软件项目配置计划
1、理解软件项目配置管理基本活动；
2、配置管理的基本概念（配置、配置项、基线、版本、SCCB）和目的。
  
第10章 软件项目团队计划
1、理解项目各类型组织结构（职能型、项目型、矩阵型）的优缺点及适用性；
2、软件项目团队所需的角色、职责；
3、项目沟通计划的主要内容；
4、项目干系人分析的“四步法”。
  
第11章 软件项目风险管理
1、风险的概念；
2、软件风险的来源；
3、软件项目风险管理的总体过程；
4、风险识别的基本方法；
5、风险评估（分析）的基本方法（定性和定量）；
6、风险应对策略。​
  
关于项目管理考试的大题分析
赢得值必考
决策树必考
PDM图必考
填空题
 

 
第1章 软件项目管理概述
 
1、项目的基本概念（注意与日常运作的区分）和特征；
 
项目的定义和特征：
 （1）美国项目管理权威机构－－项目管理协会（Project Management Institute,PMI)认为,项目是为完成某一独特的产品或服务所做的一次性努力.
 （2）德国DIN（德国工业标准）69901认为,项目是指在总体上符合下列条件的唯一性任务：
 ①具有预定的目标；
 ②具有时间、财务、人力和其他限制条件；
 ③具有专门的组织.
 （3）《项目管理质量指南(ISO10006)》定义项目为：“具有独特的过程,有开始和结束日期,由一系列相互协调和受控的活动组成.过程的实施是为了达到规定的目标,包括满足时间、费用和资源等约束条件”.
 （4）中国项目管理知识体系纲要（2002版）中对项目的定义为：项目是创造独特产品、服务或其他成果的一次性工作任务.
 （5）联合国工业发展组织《工业项目评估手册》对项目的定义是：“一个项目是对一项投资的一个提案,用来创建、扩建或发展某些工厂企业,以便在一定周期内增加货物的生产或社会的服务.”
 （6）世界银行认为：“所谓项目,一般系指同一性质的投资,或同一部门内一系列有关或相同的投资,或不同部门内的一系列投资”.
 （7）一般地说,所谓项目就是指在一定约束条件下（主要是限定资源、限定时间、限定质量）,具有特定目标的一次性任务.
 共同特征：
 （1）一次性
 （2）独特性
 （3）目标的明确性
 （4）活动的整体性
 （5）组织的临时性和开放性
 （6）开发与实施的渐进性
 常见的习题都是选出符合项目定义的事物,如：创建一个具有特定功能的软件是项目，但是日常打扫卫生就不属于项目
 项目的特征：
 1.有明确的目标
 2.项目之间的活动具有相关性
 3.限定的周期
 4.有独特性
 5.资源成本的约束性
 6.项目的不确定性
 项目与日常运作有什么不同：
 1.项目是一次性的，日常运作是重复进行的
 2.项目是以目标为导向的，日常运作是通过效率和有效性体现的
 3.项目是通过项目经理及其团队工作完成的，而日常运作是职能式的线性管理
 4.项目存在大量的变更管理，而日常运作则基本保持连贯性
 
2、软件项目及特征；
 
软件产品与其他任何产业的产品不同，它是无形的，完全没有物理属性。对于这样看不见，摸不着的产品，难以理解，难于架驭。但它确实是把思想、概念、算法、流程、组织、效率、优化等融合在一起了。因此，要开发这样的产品，在许多情况下，用户一开始给不出明确的想法，提不出确切的要求。他说不清究竟他需要的是什么。在开发的过程中，程序与其相关的文档常常需要修改。在修改的过程中又可能产生新的问题，并且这些问题很可能在过了相当长的时间以后才会发现。文档编制的工作量在整个项目研制过程中占有很大的比重。但从实践中看出，人们对它不感兴趣、认为是不得不做的苦差事，不愿认真地去做。因而直接影响了软件的质量。软件开发工作技术性很强，要求参加工作的人员具有一定的技术水平和实际工作的经验。但事实上，人员的流动对工作的影响很大。离去的人员不但带走了重要的信息，还带走了工作经验。
 软件项目的特殊性：
 1.为逻辑实体而非物理实体，具有抽象性
 2.没有明显的制造过程，也不存在重复生产
 3.软件项目的开发受到计算机硬件的制约
 4.不可能完全摆脱手工开发模式
 5.软件本身是相当复杂的，涉及因素众多，需求多变
 6.软件项目投入大、成本高
 
3、项目管理的基本概念；
 
项目管理是管理学的一个分支学科 ，对项目管理的定义是：指在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望的过程。项目管理是对一些成功地达成一系列目标相关的活动（譬如任务）的整体监测和管控。这包括策划、进度计划和维护组成项目的活动的进展。
 
4、项目管理知识体系（以2017年发布的PMBOK6的十个知识领域为准）；
 
1.项目整合管理（以前版本称为项目综合管理，或项目集成管理），包括6个子过程：制订项目章程；制定项目管理计划；指导与管理项目执行；监控项目工作；实施整体变更控制；结束项目或阶段。
 2．项目范围管理，包括6个子过程：规划范围管理；收集需求；定义范围；创建WBS；确认范围；控制范围。
 3．项目进度管理，包括7个子过程：规划进度管理；定义活动；排列活动顺序；估算活动资源；估算活动持续时间；制定进度计划；控制进度。
 4．项目成本管理，包括4个子过程：规划成本管理；估算成本；制定预算；控制成本。
 5．项目质量管理，包括3个子过程：规划质量管理；实施质量保证；控制质量。
 6．项目人力资源管理，包括4个子过程：规划人力资源管理；组建项目团队；建设项目团队；管理项目团队。
 7．项目沟通管理，包括3个子过程：规划沟通管理；管理沟通；控制沟通。
 8．项目风险管理，包括6个子过程：规划风险管理；识别风险；实施定性风险分析；实施定量风险分析；规划风险应对；控制风险。
 9．项目采购管理，包括4个子过程：规划采购管理；实施采购；控制采购；结束采购。
 10．干系人管理，包括4个过程：识别干系人；规划干系人管理；管理关系人参与；控制干系人参与。
 
5、适用于软件项目管理的知识体系。
 
软件项目管理特征：
 1.软件是纯知识产品，其开发进度和质量很难估计和度量，生产率也难以预测和保证。
 2.项目周期长，复杂度高，变数多
 3.软件项目提供的是一种服务，需要满足一群人的期待，即需要满足一群想法和利益各不相同的人的需求
 
​第2章 项目确立 &第3章 生存期模型【项目初始】
 
1、理解项目启动的基本过程（项目评估、项目立项、招投标、发布项目章程）；
 
1.项目评估：就是在直接投资活动中，在对投资项目进行可行性研究的基础上，从企业整体的角度对拟投资建设项目的计划、设计、实施方案进行全面的技术经济论证和评价，从而确定投资项目未来发展的前景。
 2.项目立项：指成立项目，执行实施。特别是大中型创业项目或行政收费项目，要列入政府、社会、经济发展计划中。
 3.招投标：招投标一般指招标投标。招标投标是基本建设领域促进竞争的全面经济责任制形式。一般由若干施工单位参与工程投标，招标单位 (建设单位) 择优入选，谁的工期短、造价低、质量高、信誉好，就把工程任务包给谁，由承建单位与发包单位签订合同。
 4.发布项目章程：项目章程是证明项目存在的正式书面说明和证明文件。
 
2、项目章程的主要内容和作用；
 
项目章程：项目章程是指项目执行组织最高层批准的一份以书面签署的确认项目存在的文件，包括对项目的确认、对项目经理的授权和项目目标的概述。严格的说，项目章程包括开始一个项目或项目阶段的正式授权。
 项目章程是一个正式的文档，它正式的认可一个项目的有效性，并指出项目的目标和管理方向。它授权项目经理来完成项目，从而保证项目经理可以组织资源用于项目活动。项目章程由项目发起人、出资人或者高层管理人员签字。
 
3、理解各生存期模型的优缺点及适用场景。
 
1.瀑布模型：分析、设计、编码、测试和维护严格按照步骤进行，适合于项目开始前有明确需求和明确解决方案的项目，如公司的财务系统、库存管理系统、短期项目等。
 2.V模型：是瀑布模型的变种，强调测试的重要性，将开发活动与测试活动紧密的联系在一起。适合于对系统的性能、安全有严格要求的项目。
 3.增量模型：由瀑布模型演变而来，假设需求可分阶段，分成一系列增量产品分别开发。适合于项目开始明确了需求的大部分，但对市场和用户把握不是很准，对于有庞大和复杂功能的系统也可考虑增量开发。
 4.螺旋式模型：该模型在四个象限上分别表达了计划制定、风险分析、项目实施、客户评估四个方面的活动，通过一系列瀑布模型的不断循环来逐步规避风险，适合于不确定因素较多，风险较大的项目。
 5.渐进式阶段模型：综合了增量模型和螺旋式模型的一个实用模型，渐进式前进，阶段式提交。适合各种规模的项目，尤其是大中型项目，以及希望随时可查看的未来项目
 
第4章 软件项目需求管理
 
1、软件需求的概念及层次；
 
软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。
 业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
 用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。
 功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示。
 
2、需求工程的组成。
 
1.需求获取阶段
 需求获取首先需要的是技术的支持，其次，在需求获取工作中主要涉及了 3 个至关重要的因素：应搜集什么信息；从什么来源中搜集信息；用什么机制或技术搜集信息。再次，需求获取的开始，代表着软件项目正式开始实施，正所谓万事开头难。综合上述 3 个点使得需求获取成为软件开发中最困难、最关键、最易出错也是最需要交流的方面。在工作开展中，主要是就业务流程、组织架构、软硬件环境和现有系统等相关内容进行沟通，挖掘系统最终用户的真正需求，把握需求的方向。在需求获取调研会中首先对需求获取方法作了验证。现行的需求获取方法一般有基于调查的需求获取方法、基于用例的需求获取方法、原型法等几种方法。各种需求获取方法各有利弊。
 2.需求分析阶段
 需求分析与需求获取是密切相关的，需求获取是需求分析的基础，需求分析是需求获取的直接表现，两者相互促进，相互制约。需求分析与需求获取的不同主要在于需求分析是在已经了解承建方的实际的客观的较全面的业务及相关信息基础上，结合软、硬件实现方案，并做出初步的系统原型给承建方做演示。承建方则通过原型演示来体验业务流程的合理化、准确性、易用性。同时，用户还要通过原型演示及时地发现并提出其中存在的问题和改进意见和方法。
 3.文档编写阶段
 需求开发的最终成果是，在对所要开发的产品达成共识后，所编写的具体的文档。需求文档是在需求获取和需求分析两个阶段任务结束时生成的，所以文档要包含所有需求。在此阶段先要从软件工程和文档管理的角度出发依据相关的标准审核需求文档内容，确定需求文档内容是否完整。对需求文档中存留问题进行修改的工作。
 4.需求确认阶段
 需求确认主要是针对《需求规格说明书》的评审，保证需求符合优秀需求成熟的特征，并且符合好的需求规格说明的特征。在需求确认阶段需要保证以下几点：
 　　（1）软件需求规格说明正确描述了预期的满足各方涉众需求的系统能力和特征。
 　　（2）从系统需求、业务规则或其他来源中正确的推导出软件需求。
 　　（3）需求是完整的、高质量的。
 　　（4）需求的表示在所有地方都是一致的。
 　　（5）需求为继续进行产品设计和构造提供充分的基础。
 5.需求跟踪阶段
 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，确保产品依据需求文档进行开发，建立与维护“需求——设计——编程——测试”之间的一致性，确保所有工作成果符合用户需求。需求跟踪是一项需要进行大量手工劳动的任务，在系统开发和维护的过程中一定要随时对跟踪联系链信息进行更新。需求跟踪能力的好坏会直接影响产品质量，降低维护成本，容易实现复用，同时，需求跟踪还需要建设方的大力支持。
 6.需求复用阶段
 在软件项目实施过程中，许多不同项目间存在着许多相似的需求，尤其是类型相同的项目在不同的用户群众的实施中，需求的相似性就更加明显、更加普遍了。有了需求复用，建设方就能快速的形成一个需求的原型，这样，后期的需求工作只需要在此原型的基础上进行修改、扩充和完善即可，大大提高了需求分析的工作进度。所以，对于需求的复用就需要加以重视。对于需求复用，首要责任就是要提取可复用的需求，对需求复用的理解和扩充。其次就是要保证需求复用不存在冲突。
 7.变更控制阶段
 需求变更在软件项目开发中是不可避免的。无休止的需求变更只会造成各种资源无休止的浪费，但是其中也不乏有许多是必要的、合理的需求变更。对于需求变更，首先是要尽量及早的发现，以避免更大的损失。其次，是要采取相应的、合理的变更管理制度和流程，这样同样可以降低需求变更带来的风险。
 8.版本控制阶段
 版本控制是管理需求规格说明和其他项目文档必不可少的一个方面，也是需求变更文档化管理的最有效办法。可以详细记录发生需求变更的需求文档版本的版本，发生变更的原因，变更发生的控制记录，并对变更后的需求文档进行唯一版本号的标识。使得每个成员都能及时访问最新版本的需求文档。
 实施版本控制的基础是需求基线，所谓需求基线就是项目组成员一经承诺将在某一特定产品版本中实现的功能性和非功能性需求的集合。需求基线的确定可以保证项目的涉众各方可以对发布的产品中希望具有的功能和属性有一个一致的理解。
 
需求获取和包含的主要活动。
 
1.需求获取指通过与用户交流、对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求
 2.需求获取的主要活动：1.了解客户方的所有用户类型及潜在的类型。2.对用户进行访谈和调研，包括会议讨论邮件提问、自行搜索等各种形式。3.对收集到的用户需求作进一步分析整理4.将调研得到的用户需求以适当形式呈交给用户和开发方相关人员。
 
需求分析的主要内容和处理不明确需求
 
需求分析的主要内容有：1.以图形表示的方法描述系统的整体结构，包括边界和接口等。2.通过原型、页面流或其他方式向用户提供可视化界面，以便用户对需求做出自己的评价。3.以模型描述系统的功能项、数据实体、外部实体以及是实体间的关系、状态转换等
 处理不明确需求：1.让用户参与开发，以便及时对不明确需求做出修正。2.开发用户界面原型，以便用户更好的确认需求。3.召开需求讨论会议，汇总和确认需求。4.强化需求分析和评审，让用户参与需求评审并签字认可。
 
如何做好需求变更管理
 
1.建立需求基线
 2.确定需求变更控制过程
 3.成立变更控制委员会SCCB
 4.进行需求变更影响分析
 5.跟踪所有受需求变更影响的工作产品
 6.建立需求基准版本和需求控制版本文档
 7.维护需求变更的历史记录
 8.跟踪每项需求的状态
 9.衡量需求的稳定性
 
第6章 软件项目成本计划（含第5章 任务分解）
 
1、软件项目成本管理的总体过程；
 
1 资源计划过程–决定完成项目各项活动需要哪些资源(人、设备、材料)以及每种资源的需要量。
 2 成本估计过程–估计完成项目各活动所需每种资源成本的近似值。
 3 成本预算过程–把估计总成本分配到各具体工作。
 4 成本控制过程–控制项目预算的改变。
 
2、软件项目成本的组成；
 
软件成本度量需要先估算软件的规模，即所需工作量的估算，然后根据工作量，通过一定的公式估算出成本。首先我们理解软件生命周期包括策划阶段、需求阶段、设计阶段、构建阶段、测试阶段、部署阶段。软件规模估算所估算的正是后四个阶段的工作量。
 
软件成本的构成可分为直接成本和间接成本，具体可分为直接人力成本，间接人力成本，间接非人力成本，直接非人力成本。
 
1.直接人力成本，包括开发方项目组成员的工资、奖金、福利等人力资源费用
 
2.直接非人力成本，包括办公费、差旅费、培训费、业务费、采购费及其他费用
 
3.间接人力成本，指开发方服务于研发管理整理需求的非项目组人员的人力资源费用分摊
 
4.间接非人力成本，指开发方不为研发某个特定项目而产生，但服务于真题研发活动的非人力成本分摊
 
3、WBS的作用、特点及分解方法；
 
即利用WBS方法，先把项目任务进行合理的细分，分到可以确认的程度，如某种材料，某种设备，某一活动单元等。然后估算每个WBS要素的费用。采用这一方法的前提条件或先决步骤是：
 ①对项目需求作出一个完整的限定。
 ②制定完成任务所必需的逻辑步骤。
 ③编制WBS表。
 项目需求的完整限定应包括工作报告书、规格书以及总进度表。工作报告书是指实施项目所需的各项工作的叙述性说明，它应确认必须达到的目标。如果有资金等限制，该信息也应包括在内。规格书是对工时、设备以及材料标价的根据。它应该能使项目人员和用户了解工时、设备以及材料估价的依据。总进度表应明确项目实施的主要阶段和分界点，其中应包括长期定货、原型试验、设计评审会议以及其他任何关键的决策点。如果可能，用来指导成本估算的总进度表应含有项目开始和结束的日历时间。
 一旦项目需求被勾划出来，就应制定完成任务所必需的逻辑步骤。在现代大型复杂项目中，通常是用箭头图来表明项目任务的逻辑程序，并以此作为下一步绘制CPM或PERT图以及WBS表的根据。
 编制WBS表的最简单方法是依据箭头图。把箭头图上的每一项活动当作一项工作任务，在此基础上再描绘分工作任务。
 进度表和WBS表完成之后，就可以进行成本估算了。在大型项目中，成本估算的结果最后应以下述的报告形式表述出来：
 ①对每个WBS要素的详细费用估算。还应有一个各项分工作、分任务的费用汇总表，以及项目和整个计划的累积报表。
 ②每个部门的计划工时曲线。如果部门工时曲线含有“峰”和“谷”，应考虑对进度表作若干改变，以得到工时的均衡性。
 ③逐月的工时费用总结。以便项目费用必须削减时，项目负责人能够利用此表和工时曲线作权衡性研究。
 ④逐年费用分配表。此表以WBS要素来划分，表明每年（或每季度）所需费用。此表实质上是每项活动的项目现金流量的总结。
 ⑤原料及支出预测，它表明供货商的供货时间、支付方式、承担义务以及支付原料的现金流量等。
 采用这种方法估算成本需要进行大量的计算，工作量较大，所以只计算本身也需要花费一定的时间和费用。但这种方法的准确度较高，用这种方法作出的这些报表不仅仅是成本估算的表述，还可以用来作为项目控制的依据。最高管理层则可以用这些报表来选择和批准项目，评定项目的优先性。 以上介绍了三种成本估算的方法。除此之外，在实践中还可将几种方法结合起来使用。例如，对项目的主要部分进行详细估算，其他部分则按过去的经验或用因素估算法进行估算。
 
4、软件项目规模估算的基本方法（LoC、FP、UCP）；
 
1.LoC：面向规模的软件度量通过规范化质量和生产率测量的方法得到，这种测量是基于所生产软件的规模(Size)确定的。为了与其他项目中的同类度量相比较，选择代码行作为规范化，这样，就可以为每个项目产生一组简单的、面向规模的度量标准：
 ●每千行代码(KLOC)的错误数。
 ●每千行代码行(KLOC)的缺陷数。
 ●每千行代码行(KLOC)的成本。
 ●每千行代码行(KLOC)的文档页数。
 ●每人月错误数。
 ●每页文档的成本。
 面向规模的软件度量，通常并不被认为是软件开发过程中最优的方法，因为有很多因素直接影响代码的行数。
 减小估算误差的方法（PERT估计）：请多位专家分别估计程序的最小规模a，最可能规模m，最大规模b，然后计算出这三种规模的平均值 ，最后计算出程序规模的平均值：
 
 
2.FP：采用功能点估算法可得出最终的功能点数（FP），然后将FP转换为Loc（Java语言采用平均值70，即一个功能点对应代码行数量为70），一代码行的研发成本为15元。据此估算出软件研发成本。
 项目管理成本=研发成本12%,
 质量保证成本=研发成本8%，
 配置管理成本=研发成本6%，
 项目直接成本=研发成本+项目管理成本+质量保证成本+配置管理成本;
 项目间接成本（包含办公场所租赁费用、水电、保安、福利、培训、软硬件设备等分摊到该项目的费用）=项目直接成本20%；
 项目总成本=项目直接成本+项目间接成本=项目直接成本*（1+20%）。
 3.UCP：如果采用用例点估算法可得出最终的用例点数（UCP）。软件生产率PE采用20人时/用例点，研发人员的平均成本为400元/天，据此估算出软件研发成本。
 项目管理成本=研发成本12%,
 质量保证成本=研发成本8%，
 配置管理成本=研发成本6%，
 项目直接成本=研发成本+项目管理成本+质量保证成本+配置管理成本;
 项目间接成本（包含办公场所租赁费用、水电、保安、福利、培训、软硬件设备等分摊到该项目的费用）=项目直接成本20%；
 项目总成本=项目直接成本+项目间接成本=项目直接成本*（1+20%）；
 
5、软件项目成本估算的各基本方法（专家判定、类比、自顶向下、自底向上、算法模型）及特点；
 
1.专家判定：基于历史信息，专家判断可以对项目环境及以往类似项目的信息提供有价值的见解。专家判断还可以对是否需要联合使用多种方法，以及如何协调方法之间的差异提出建议。（出题基本就是，A专家B专家C专家各自报价多少，求一个平均数）也称为Delphi法，聘请一个或多个领域专家和软件开发技术人员，由他们分别对项目成本进行估计，并最后达成一致而获得最终的成本。
 2.类比：成本类比估算，指利用过去类似项目的实际成本作为当前项目成本估算的基础。当对项目的详细情况了解甚少时（如在项目的初期阶段），往往采用这种方法估算项目的成本。类比估算是一种专家判断。类比估算的成本通常低于其他方法，而且萁精确度通常也较差。此种方法在以下情况中最为可靠：与以往项目的实质相似，而不只是在表面上相似，并且进行估算的个人或集体具有所需的专业知识。
 常考：已知一个功能点，还有1200个功能点，则是类比估算法
 3.自顶向下与自底向上：1.自顶向下估算法是从项目的整体出发，进行类推，即估算人员根据以往完成类似项目所消耗的总成本或工作量，来推算将要开发的信息系统的总成本或工作量。然后，按比例将它分配到各个开发任务单元中，是一种自上而下的估算形式，通常在项目的初期或信息不足时进行。例如，在合同期和市场招标时等。不是非常精确的时候或在高层对任务的总的评估的时候采用这种方法。该方法的特点是简单易行和花费少，但具有一定的局限性，准确性差，可能导致项目出现困难。2.自底向上估算法也叫工料清单法，这种成本估算方法是利用项目工作分解结构图，先由基层管理人员计算出每个工作单元的生存成本，再将各个工作单元的生产成本自下而上逐级累加，汇报给项目的高层管理者，最后由高层管理者汇总得出项目的总成本。采用这种方法进行成本估算，基层管理者是项目资源的直接使用者，因此由他们进行项目成本估算，得到的结果应该十分详细，而且比其它方式也更为准确。但是这种方法实际操作起来非常耗时，成本估算工作本事也要大量的经费支持。
 4.模型算法：。根据项目特征，用数学模型来预测项目的成本。一般采用历史成本信息(这些信息与项目成本的一些软件度量标准相关)来建立估算模型，并通过这个模型预测工作量和成本。
 
6、理解软件项目成本预算；
 
项目成本估算，是对完成项目工作所需要的费用进行估计和计划，是项目计划中的一个重要组成部分。要实行成本控制，必须先估算费用。费用估算过程实际上是确定完成项目全部工作活动所需要的资源的一个费用估计值，这是一个近似值，既可以用货币单位表示，也可用工时、人月、人天等其他单位表示。在进行费用估算时，也包括各种备选方案的费用估算。
 项目成本估算方法就是运用一系列科学的手段去对项目有关工程技术、经济、社会等方面的条件和情况进行调查、研究、分析，从而推算出项目所需成本的手段。
 
7、软件项目成本控制（监控），掌握赢得值分析法各种量的计算。
 
成本管理是软件项目管理的主要内容之一，分析了目前软件开发成本管理过程中存在的问题，提出了将进度和成本联系起来考虑，使工作量和实际成本匹配的方法。结合现有的估算方法，设计成本管理系统并将其应用于软件项目管理平台中，旨在改善软件开发中成本超支的现象，为企业提高效益。
 
赢得值法用三个基本值来表示项目的实施状态，并以此预测项目可能的完工时间和完工时的可能费用，三个基本值是：累计计划成本额：某一时点应当完成的工作所需投入资金或花费成本的累计值。它等于计划工程量与预算单价的乘积之和。该值是衡量工程进度和工程费用的一个标尺或基准。
 赢得值：某一时点已经完成的工作所需投入资金的累计值。它等于已完工程量与预算单价的乘积之和。它反映了满足质量标准的工程实际进度和工作绩效，体现了投资额到工程成果的转化。
 实际成本额：某一时点已完成的实际工作所花费的成本总金额。它等于已完工程量与实际支付单价的乘积之和。
 通过三个基本值的对比，可以对工程的实际进展情况作出明确的测定和衡量，有利于对工程进行监控，也可以清楚地反映出工程管理和工程技术水平的高低。使用赢得值法进行成本、进度综合控制，必须定期监控以上三个参数。具体步骤如下：
 （1）项目预算和计划首先要制订详细的项目预算，把预算分解到每个分项工程，尽量分解到详细的实物工作量层次，为每个分项工程建立总预算成本TBC（Totalbud-getedcost）。项目预算的的第二步是将每一TBC分配到各分项工程的整个工期中去。每期的成本计划依据各分项工程的各分项工作量进度计划来确定。当每一分项工程所需完成的工程量分配到工期的每个时段，就能确定何时需用多少预算。这一数字通过截止到某期的过去每期预算成本累加得出，即累计计划预算成本CBC（cumulativebudgetedcost）或BCWS.其中，Rb代表预算单价；Qs代表计划工程量；i代表某一预算项；n代表预算项数；t代表时段；j代表当前时段。CBC反映了到某期为止按计划进度完成的工程预算值。它将作为项目成本、进度绩效的基准。
 （2）收集实际成本项目执行过程中，会通过合同委托每一工作包的工作给相关承包商。合同工程量及价格清单形成承付款项。承包商在完成相应工作包的实物工程量以后，会按合同进行进度支付。在项目每期对已发生成本进行汇总，即累计已完工程量与实际单价之积，就形成了累计实际成本CAC（cumulativeactualcost）或ACWP.
 （3）计算赢得值（earned value）
 如前所述，仅监控以上两个参数并不能准确地估计项目的状况，有时甚至会导致错误的结论和决策。赢得值是整个项目期间必须确定的重要参数。对项目每期已完工程量与预算单价之积进行累计，即可确定累计赢得值CEV（cumulative earned value，）或BCWP.
 （4）成本/进度绩效利用以上几个指标即可以比较分析项目的成本/进度绩效和状况，CEV与CAC实际是在同样进度（相同工作量）下的价值比较，它反映了项目成本控制的状况和效率，因此，衡量成本绩效的指标或称成本绩效指数CPI（costperformanceindex，）可由如下公式确定；
 CPI=CEV/CAC另一衡量成本绩效的指标是成本差异CV（costvariance），它是累计赢得值与累计实际成本，即CV=CEV-CAC与CPI一样，这一指标表明赢得值与实际成本的差异，CV是以货币来表示的。
 同样，CBC与CEV是在同样价格体系（预算价）下的工程量的比较，它用货币量综合反映了项目进度的总体状况，因此，可按上述方法同样去衡量进度绩效。
 以上分析可对整个项目进行，也可针对某一独立的工作包进行。
 （5）成本/进度控制有效成本/进度控制的关键是经常地、及时地分析成本/进度绩效，及早地发觉成本/进度差异，以便在情况变坏之前能够采取纠偏措施。
 成本、进度综合控制包括如下内容，分析成本、进度绩效以确定需要采取纠正措施的工作包，决定采取何种纠偏措施。
 修订项目计划，包括工期和成本估计，综合筹划控制措施。
 要做好成本、进度综合控制，应十分关注CPI或CV的走势，当CPI小于1或逐渐变小、CV为负且绝对值越大时，就应该及时制定纠偏措施并加以实施。应集中注意力在那些有负成本差异的工作包或分项工程上，根据CPI或CV值确定采取纠正措施的优先权，也就是说，CPI最小或CV负值最大的工作包或分项工程应该给予最高优先权。总体进度控制可使用相同原理和方法。
 （此题考的还挺多）
 
任务分解及作用
 
任务分解就是将一个项目分解为更多的工作细目或者子项目，使项目变的更小、更易管理、更易操作。他是一个化繁为简，分而治之的过程
 作用：
 1.提供了项目范围基线，是范围变更的重要输入
 2.为评估和分配任务提供具体的工作包
 3.进行估算和编制项目进度的基础
 4.对整个项目成功的集成和控制起到非常重要的作用
 
项目管理度量指标
 
BCWS:计划完成工作的预算成本 BCWS=计划工作量*预算单价
 
BCWP（挣得值）：已完成工作量的预算成本 BCWP=已完成工作量*预算单价
 
ACWP：已完成工作量的实际费用 ACWP=实际完成工作量*实际单价
 
CV:费用偏差。表示完成相同任务的任务实际费用和预算费用的差额。CV=BCWP-ACWP
 
SV:进度偏差，BCWP与BCWS之间的差异SV=BCWP-BCWS
 
CPI:是指挣得值与实际费用之比。CPI=BCWP/ACWP
 
SPI:进度执行标准：是指项目挣得值与计划值之比，SPI=BCWP/BCWS
 
第7章 软件项目进度计划（重点！！）
 
1、软件项目进度管理的总体过程；
 
项目进度管理是指在项目实施过程中，对各阶段的进展程度和项目最终完成的期限所进行的管理，是在规定的时间内，拟定出合理且经济的进度计划（包括多级管理的子计划）。
 在执行该计划的过程中，经常要检查实际进度是否按计划要求进行，若出现偏差，便要及时找出原因，采取必要的补救措施或调整、修改原计划，直至项目完成。其目的是保证项目能在满足其时间约束条件的前提下实现其总体目标。
 项目进度管理一般包含项目进度计划的制定和项目进度计划的控制两部分。
 主要任务
 1.活动定义
 2.活动排序
 3.活动历时估计
 4.人物资源估计
 5.制定进度计划
 6.进度控制项目跟踪
 
2、活动之间的逻辑关系（FS、SS、FF、SF）及依赖关系（强制、选择、内部、外部）；
 
FS关系：完成—开始关系，即：前一工作完成后，后续工作才能开始。
 SS关系：开始—开始关系，即：前一工作开始后，后续工作才能开始。
 FF关系：完成—完成关系，即：前一工作完成后，后续工作才能完成。
 SF关系：开始—完成关系，即：前一工作开始后，后续工作才能完成。
 依赖关系亦称“逻辑关系”。在项目管理中，指表示两个活动(前导活动和后续活动）中一个活动的变更将会影响到另一个活动的关系。通常活动之间的依赖关系包括强制依赖关系（所做工作中固有的依赖关系）、可自由处理的依赖关系（由项目队伍确定的依赖关系）和外部依赖关系（项目活动与非项目活动之间的依赖关系）三种形式
 
3、活动排序的网络图（ADM和PDM的区分、特点）；
 
首先是网络图：
 用图形直观地显示项目各项活动之间的逻辑关系和排序。
 网络图是活动排序的结果，它可以展示各项目活动之间的关系。
 通过网络图可识别关键活动，并确定某一活动进度的变化对后续工程和总工期的影响。
 在网络图中一个活动用一个方框、节点或者其他方式表示
 每一个活动被各种关系线相连接着
 网络图开始于一个任务、工作、活动、里程碑
 网络图结束于一个任务、工作、活动、里程碑
 有些活动具有前置任务或者后置任务
 1.ADM箭线图法
 在ADM网络图中,箭线表示活动(任务)
 代号表示前一任务的结束,同时也表示后一任务的开始.
 两个代号唯一确定一个任务，因此称为双代号网络图
 双代号网络计划一般仅使用结束到开始的关系表示方法，因此为了表示所有工作之间的逻辑关系往往需要引入虚活动加以表示
 在我国这种方法应用较多，软件较多
 
 
2.PDM
 构成PDM网络图的基本特点是节点(Box)
 节点(Box)表示活动（任务）
 用箭线表示各活动(任务)之间的逻辑关系
 可以方便的表示活动之间的各种逻辑关系
 
 
 
4、项目历时估计的方法（重点在CPM和PERT）；
 
1.CPM关键路径法：
 确定项目网络图
 每个活动有单一的历时估算
 关键路径是网络图中持续时间最长的路径
 关键路径可以确定项目完成时间
 组成关键路径的任务称为关键任务，任何关键任务的延迟都会导致项目工期的延期，所以关键任务的缓冲期都是0
 
 
2.PERT工程评价技术：利用PDM任务网络图和加权历时估算公式计算项目总历时
 3.定额估算法：根据项目规模、投入资源即单位生产率计算项目历时，公式为T=Q/(R*S)
 4.经验导出模型：使用根据大量历史项目统计得出的模型公式计算，如COCOMO模型等
 5.基于承诺的进度估计发：从需求出发，由开发人员承诺项目进度
 6.Jones的一阶估算准则：根据项目功能点数及开发商评级，使用公式粗略估计项目历时
 7.其他：专家估计法、类推估计法、模拟估计法等。
 
5、时间压缩法中的赶工（掌握时间压缩与成本增加呈线性的情况）
 
赶工：拿资源换时间
 赶工在项目管理中的定义：对成本和进度进行权衡，确定在尽量少增加费用的前提下最大限度地缩短项目所需要的时间。赶工进度并非总能产生可行的方案，反而常常增加成本。
 赶工原则是“采用优先考虑赶工费用率最低的工作”。压缩工期势必要采取相应施工措施和技术措施，则造成施工成本增加；通俗的说就是“用金钱换时间”。
 
6、甘特图和里程碑图的基本特点。
 
甘特图（Gantt chart）又称为横道图、条状图(Bar chart)。其通过条状图来显示项目、进度和其他时间相关的系统进展的内在关系随着时间进展的情况。
 
 
里程碑图是一个目标计划，它表明为了达到特定的里程碑，去完成一系列活动。
 
 菱形小方快
 
7.何谓正推法？简述其计算任务历时的基本步骤及计算公式
 
1.正推法是按照时间顺序计算任务网络图上各活动的最早开始时间和最早完成时间的有效方法
 2.计算步骤：
 a.首先建立项目的开始时间，项目的开始时间是网络图中第一个活动的最早开始时间
 b.从左到右从上到下进行计算，遍历所有路径
 c.当一个任务有多个前置任务时，其最早开始时间应取前置任务其中最大的最早完成时间
 3.计算公式：
 a.EF=ES+Duration（任务历时）
 b.ES(2)=EF(1)+Lag(1为前置任务2为后置任务，Lag为滞后时间）
 
第8章 软件项目质量计划
 
1、软件质量的基本概念和内涵；
 
概括地说，软件质量就是“软件与明确地和zhi隐含地定义的需求相一致的程度”。具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。上述定义强调了以下三点：
 (1)软件需求是度量软件质量的基础，与需求就一致就是质量不高。
 (2)指定的标准定义了一组指导软件开发的准则，如果没有遵守这些准则，几乎肯定会导致质量不高。
 (3)通常，有一组没有显式描述的隐含需求（如期望软件是容易维护的）。如果软件满足明确描述的需求，但却不满足隐含的需求，那么软件的质量仍然是值得怀疑的。
 影响软件质量的主要因素，这些因素是从管理角度对软件质量的度量。可划分为三组，分别反应用户在使用软件产品时的三种观点。正确性、健壮性、效率、完整性、可用性、风险（产品运行）；可理解性、可维修性、灵活性、可测试性（产品修改）；可移植性、可再用性、互运行性（产品转移）。
 
2、软件质量模型；
 

 软件的 6 个质量特征:
 功能性(Functionality)：当软件在指定条件下使用时，软件产品提供满足明确和隐含需要的功能的能力；
 可靠性(Reliability)：在指定条件下使用时，软件产品维持规定的性能级别的能力；
 易用性(Usability)：在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力；
 效率(Efficiency)：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力；
 可维护性(Maintainability)：软件产品可被修改的能力。修改可能包括纠正、改进或软件对环境、需求和功能规约变化的适应程度；
 可移植性(Portability)：软件产品从一种环境迁移到另一种环境的能力。
 
3、软件质量保证(QA)常见活动、质量控制(QC)常见活动，两者区别。
 
1.软件质量保证(QA)其目的是向管理者提供适当的对软件项目正在进行的过程和正在构造的产品的可视性,
 包括审计软件产品(中间产品和最终产品)和开发过程以验证它们符合通用的过程和标准，
 向管理者、顾客或其他方提供信任，
 确保项目质量与计划保持一致。
 这个任务本身并不能提高产品的质量
 一般由专门的质量保证人员实施
 2.质量控制(Quality Control,QC)是确定项目结果(中间结果和最终结果)与质量标准是否相符，并及时纠正产品缺陷的过程。
 
 比较：
 质量保证重在保证过程被正确执行，属于管理职能，针对项目实施过程的管理手段；
 质量控制重在检验产品的质量，属于检查职能，针对项目产品的技术手段；
 质量控制是针对具体产品的质量管理，在具体环节上提高产品质量，促进具体产品的质量改善；
 质量保证确保项目以一套成熟高效的做事方法开展和实施，在总体上提高信心。依靠在QA制约下的开发过程，能够前瞻性地从制度上保障开发出好产品。因此，具有良好QA管理的企业，容易获得客户更多的信任。企业性能产生突破。
 
第9章 软件项目配置计划
 
1、理解软件项目配置管理基本活动；
 
软件配置管理是识别、定义系统中的配置项，在软件生命周期中控制它们的变更，记录并报告配置项和变更请求的状态，并验证它们的完整性和正确性的一个过程。
 配置管理是否有成效取决于三个要素：人、规范、工具
 主要包括
 1.软件配置管理组织
 2.配置项的标识、跟踪
 3.建立配置管理环境
 4.配置项版本控制
 5. 基线变更管理
 6. 配置审核
 7. 配置状态统计和报告
 8.配置管理计划
 
2、配置管理的基本概念（配置、配置项、基线、版本、SCCB）和目的。
 
配置的概念最早应用于制造系统，其目的是有效标识复杂系统的各个组成部分。
 如今软件的复杂性日益增大，如仍把软件当作单一的整体，就无法解决所面临的问题，因此，软件产品同样需要类似材料清单的概念，配置的概念由此引入软件领域。
 1.配置：在软件开发过程中生成各种制品的总和叫做这个项目的软件配置（程序、文档、数据）。
 2.配置项：
 
项目需定义其受控于软件配置管理的款项。
 为了配置管理的目的而作为一个单位来看待的软件要素的集合。
 具体有：
 a.程序(源代码、可执行程序)
 b.文档
 c.属于软件产品组成部分的工作成果，如需求文档、设计文档、测试用例、测试报告、用户手册、维护文档等；
 d.在管理过程中产生的文档，例如各种项目计划、状态报告，这些文档虽然不是产品的组成部分，但也值得保存。
 e.数据（内部或外部）
 f.有时也会把特定版本开发工具（如编译器、开发工具、CASE工具）等列入配置管理项
 g.每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等
 
3.基线：已经通过了正式评审的配置项，它可以作为进一步开发的基础，并且只有通过正式的变更控制过程才能修改。在软件工程环境中，基线通常标志着软件开发过程中的里程碑，这些里程碑的标志是一项或多项经过正式的技术评审并一致认同的软件制品的提交。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”；为内部开发用的基线则称为一个“Build”。
 4.版本：是一个基线或一个软件配置项的特例。
 5.SCCB：软件配置控制委员会
 6.目的：
 记录软件产品的演化过程
 确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置
 最终保证软件产品的完整性、一致性、追朔性、可控性
 软件配置管理主要功能
 版本控制：采取相应的流程和工具，对软件开发过程中产生的各种文件的版本进行管理。（核心内容）
 变更管理：为防止开发人员对软件的随意变更而进行的管理上的审核过程，包括变更请求、变更评估、批准/拒绝、变更实现。
 其他：配置审计、配置状态统计等。
 
第10章 软件项目团队计划
 
1、理解项目各类型组织结构（职能型、项目型、矩阵型）的优缺点及适用性；
 
职能型：
 优点：1.可以充分发挥职能部门的资源集中优势。2.部门的专家可以同时为部门内的不同项目使用。3.便于相互交流，相互支援。4.可以随时增派人员。5.可以将项目和本部门的职能工作融为一体
 缺点：1.项目和部门利益发生冲突，职能部门更重视本部门的目标，会忽略项目目标2.资源平衡会出现问题。3.权力分割不利于各个职能部门的交流和团结协作4.行政隶属关系使得项目经理没有充分的权力
 
项目型：
 优点：1.项目经理对项目可以负全责。2.项目目标单一，以项目为中心，有利于项目顺利进行。3.避免了多重领导.4.组织结构简单，交流简单，效率高
 缺点：1.资源不能共享2.各个独立的项目处于相对封闭的状态，不利于公司政策的贯彻3.对项目组织的成员缺少一种事业上的连续性和安全感4.项目组织间处于分割状态，缺少信息交流。
 
矩阵型
 优点：1.专职的项目经理负责整个项目，以项目为中心2.公司的多个项目可以共享各个职能部门的资源3.即利于项目目标的实现，有利于公司目标方针的贯彻4.项目成员的顾虑减少了
 缺点：1.容易引起职能经理和项目经理权利的冲突2.资源共享也能引起项目之间的冲突3.项目成员有多头领导
 
2、软件项目团队所需的角色、职责；
 
 
3、项目沟通计划的主要内容；
 
项目沟通计划是对于项目全过程的沟通工作，沟通方法、沟通渠道等各个方面的计划与安排。就大多数项目而言，沟通计划的内容是作为项目初期阶段工作的一个部分。同时，项目沟通计划还需要根据计划实施的结果进行定期检查，必要时还需要加以修订。所以项目沟通计划管理工作是贯穿于项目全过程的一项工作，项目沟通计划是和项目组织计划紧密联系在一起的，因为项目的沟通直接受项目组织结构的影响。
 
4、项目干系人分析的“四步法”。
 
干系人（stakeholder）是能影响项目决策、活动或者结果的个人、群体或者组织，以及会受到或者自认为会受到项目决策、活动或者结果影响的个人、群体或者组织。
 项目干系人分析四步法：
 无遗漏地识别项目干系人
 按重要性对干系人进行分析
 按支持度对干系人进行分析
 项目干系人分析坐标格
 
第11章 软件项目风险管理
 
1、风险的概念；
 
风险是项目的一个固有的不确定的事件或者条件，一旦发生，就会对一个或多个项目目标（如范围、进度、成本和质量）造成积极或消极的影响。也就说风险的发生可能给项目带来问题，也可能给项目带来机会。对于这两种性质不同的风险，在传统的风险管理中都属于其研究对象。
 
2、软件风险的来源；
 
软件风险是有关软件项目、软件开发过程和软件产品损失的可能性。
 分类
 从预测的角度将风险分为3类：
 已知风险（known known）：是通过仔细评估项目计划、开发项目的经济和技术环境以及其他可靠的信息来源之后可以发现的那些风险。例如，不现实的交付时间；没有需求或软件范围文档；恶劣的开发环境等。
 可预测的风险（known unknown）：是指能够从过去项目的经验中推测出来的风险。例如，人员变动；与客户之间无法沟通等。
 不可预测的风险（unknown unknown）：是指可能，但很难事先识别出来的风险
 
根据风险内容（范围），风险可分为
 技术风险:是指由于与项目研制相关的技术因素的变化而给项目建设带来的风险，包括潜在的设计、实现、接口、验证和维护、规格说明的二义性、技术的不确定性、“老”技术与“新”技术等方面的问题。
 费用风险:是指由于项目任务要求不明确，或受技术和进度等因素的影响而可能给项目费用带来超支的可能性。
 进度风险:是指由于种种不确定性因素的存在而导致项目完工期拖延的风险。该风险主要取决于技术因素、计划合理性、资源充分性、项目人员经验等几个方面。
 管理风险:是指由于项目建设的管理职能与管理对象（如管理组织、领导素质、管理计划）等因素的状况及其可能的变化，给项目建设带来的风险。
 社会环境风险:是指由于国际、国内的政治、经济技术的波动（如政策变化等），或者由于自然界产生的灾害（如地震、洪水等）而可能给项目带来的风险。
 商业风险:是指开发了一个没有人真正需要的产品或系统（市场风险）；或开发的产品不符合公司的整体商业策略（策略风险）；或构成了一个销售部不知道如何去出售的产品（销售风险）等。
 其它：人员风险、客户风险、产品风险、过程风险等
 
3、软件项目风险管理的总体过程；
 
风险管理是指在项目进行过程中不断对风险进行识别、评估、制定策略、监控风险的过程。
 通过风险识别、风险分析和风险评价去认识项目的风险，并以此为基础合理地使用各种风险应对措施、管理方法、技术和手段对项目的风险进行有效的控制，妥善处理风险事件造成的不利后果，以最小的成本保证项目总体目标的实现。
 
4、风险识别的基本方法；
 
 
5、风险评估（分析）的基本方法（定性和定量）；
 
风险评估又称风险预测，就是对识别出的风险做进一步分析，对风险发生的概率进行估计和评价，对风险后果的严重程度进行估计和评价，对风险影响范围进行估计和评价，以及对于风险发生时间进行估计和评价。
 风险评估可采用定性风险评估和定量风险评估来进行。
 定性风险评估主要是针对风险概率及后果进行定性的评估。
 例如采用历史资料法、概率分布法、风险后果估计法等。历史资料法主要是应用历史数据进行评估的方法，通过同类历史项目的风险发生情况，进行本项目的估算。
 风险评估的方法——定量风险评估
 定量风险评估是一种广泛使用的管理决策支持技术。一般，在定性风险分析之后就可以进行定量风险分析。
 定量风险分析过程的目标是量化分析每一个风险的概率及其对项目目标造成的后果，也分析项目总体风险的程度。定量风险评估可以包括以下方法：
 访谈
 因果关系分析
 决策树分析
 模拟法
 
6、风险应对策略。​
 
主要应对策略—回避风险
 回避风险是对所有可能发生的风险尽可能的规避，采取主动放弃或者拒绝使用导致风险的方案。例如放弃采用新技术。
 注意事项
 对风险有足够的认识，而且风险发生概率极高，影响极严重
 当其他风险策略不理想的时候，可以考虑
 可能产生另外的风险，如不采用新的开发技术，导致开发的产品技术落后
 不是所有的情况都适用的
 主要应对策略—转移风险
 转移风险是为了避免承担风险损失，有意识将损失或与损失有关的财务后果转嫁出去的方法：例如出售、分包、开脱责任合同(通过免责合同等手段说明不对后果负责)、保险。
 注意事项
 通过分包来转移风险实际上是将一种风险置换成了另一种风险，如分包商交付延误的风险、成本上升的风险
 软件保险（软件如使用过程中出了问题，保险公司来赔偿损失）已经存在
 主要应对策略—损失控制
 损失控制是指在风险事件发生前消除风险可能发生的根源并减少风险事件的概率,在风险事件发生后减少损失的程度。
 损失控制的基点是消除风险因素和减少风险损失。
 损失控制根据目的不同,分为：损失预防和损失抑制
 损失预防是指损失发生前为了消除或减少可能引起风险的各种因素而采取的各种具体措施。制订预防性计划包括针对一个确认的风险事件的预防方法以及风险发生后的应对步骤。
 损失抑制（风险缓解）是指风险发生时或风险发生后为了减少损失幅度所采取的各项措施。
 主要应对策略—自留风险
 自留风险又称承担（接受）风险，由项目组织自己承担风险事件所致损失的措施。类型：
 主动自留风险
 被动自留风险
 
关于项目管理考试的大题分析
 
赢得值必考
 
赢得值（Earned Value）分析法是一种能全面衡量项目成本、进度的整体方法，以资金已经转化为项目成果的量来衡量，是一种完整和有效的项目监控指标和方法。
 赢得值分析法用BCWS、BCWP、ACWP三个基本值来表示项目状态，项目管理者能够清楚的辨别项目的进度和成本是否存在偏差。并以此预测项目可能的完工时间和完工时的可能费用。
 累计计划成本额(BCWS)或称累计计划投资额（CBC）
 某一时点应当完成的工作所需投入资金或花费成本的累计值。
 等于计划工作量与预算单价的乘积之和。
 是衡量项目进度和成本费用的一个标尺或基准。
 完成投资额（BCWP)或称累计赢得值(CEV)
 某一时点已经完成的工作所需投入资金的累计值。
 等于已完成工作量与预算单价的乘积之和。
 是反映了满足质量标准的工作实际进度和工作绩效，体现了投资额到项目成果的转化。
 实际成本额（ACWP)或称累计实际成本（CAC）
 某一时点已经完成的工作所实际花费成本的总金额。
 等于已完成工作量与实际支付单价的乘积之和。
 两个公式
 
 
 
决策树必考
 
比较简单
 
PDM图必考
 
知识点：
 若随机变量X服从一个数学期望为μ、方差为σ2的正态分布，记为N(μ，σ2)。其概率密度函数为正态分布的期望值μ决定了其位置，其标准差σ决定了分布的幅度。当μ = 0,σ = 1时的正态分布是标准正态分布。
 2、正态曲线下，横轴区间（μ-σ,μ+σ）内的面积为68.268949%。
 P{|X-μ|<σ}=2Φ（1）-1=0.6826
 横轴区间（μ-2σ,μ+2σ）内的面积为95.449974%。
 P{|X-μ|<2σ}=2Φ（2）-1=0.9544
 横轴区间（μ-3σ,μ+3σ）内的面积为99.730020%。
 P{|X-μ|<3σ}=2Φ（3）-1=0.9974
 对于PERT法
 图像题：
 正推过程：按照时间顺序计算最早开始时间和最早完成时间的过程
 首先建立项目的开始时间(网络图中首个活动ES:项目的开始时间)
 从左到右，从上到下进行任务编排,求出每一个活动的ES与EF(EF=ES+活动估计工期）
 当一个后置活动有多个前置活动时，选择其中最大的最早完成时间作为后置活动的最早开始时间.
 ES(S)=Max{EF(Pi)}，Pi : 活动S的所有直接前置活动
 
 
历时估计基本方法-CPM
 逆推过程：按照逆时间顺序计算最晚开始时间和最晚结束时间的方法
 首先建立项目的结束时间(网络图中最后一个活动的最晚结束时间)
 从右到左，从上到下进行计算,求出每一个活动的LF和LS（LS=LF-活动的估计工期)
 当一个前置活动有多个后置活动时，选择其中最小的最晚开始时间作为前置活动的最晚完成时间.
 LF§=Min{LS(Si)}，Si : 活动P的所有直接后置活动
 
 
填空题
 
1.实现项目目标的制约因素有项目范围、成本、进度计划和客户满意度
 
2.一个组织的管理工作包括战略管理、运作管理和项目管理。
 
3.项目管理的五要素是技术、方法、团队建设、问题、过程
 
4.项目管理的战术关注点是进度、成本、范围和质量
 
5.项目管理的核心是进度管理和成本管理
 
6.项目管理过程大致分为项目开始、项目计划、项目执行控制和项目结束四个阶段
 
7.项目管理的5个标准化过程组是启动过程组、计划过程组、控制过程组、执行过程组和收尾过程组
 
8.项目管理的战略关注点是人员、问题和过程
 
9.项目按来源可分为合同项目和内部项目两大类
 
10.甲方初始过程包括招标书定义、一方选择、合同签署三个阶段
 
11.招标的方式有公开招标、有限招标、多方洽谈、直接谈判等多种
 
12.项目经理的主要责任包括开发计划、组织实施、项目控制
 
13.乙方初始过程包括招标书定义、乙方选择、合同签署三个阶段
 
14.需求主要指用户对软件的功能和性能的要求
 
15.软件需求包括业务需求、用户需求和功能需求
 
16.任务分解的标准主要有生存期、功能组成、其他方法等几种
 
17.任务分解的方法主要有参照、类比、自顶向下、自底向上等几种
 
18.进度管理常用的图标有甘特图、网络图、里程碑图、资源图
 
19.编址进度计划需要从成本估计、时间估计和进度编制三维考虑
 
20.进度编制的基本方法主要有关键路径法、时间压缩法、资源调整尝试法、关键链路法
 
21.时间压缩法可分为应急法和平行作业法
 
22.成本管理包括成本预测、分析、决策和控制
 
23.项目规模（工作量统计）的计量方式包括规模估算和成本估算两大类，计量单位常为货币
 
24.成本估算需要考虑直接成本和间接成本两大块。最常用的估算方式是代码行、功能点、类比估算法、参照估算、专家估算法
 
25.软件质量是软件满足明确说明或隐含的需求的程度，可通过合同、标准、图纸三个方面共11项特性加以描述
 
26.主观质量模型（ICEDT）包括直观性、一致性、效率、耐久性和体贴五个方面
 
27.软件质量管理由质量管理计划、质量保证和质量控制三个过程
 
28.审计是一种常见的对过程或者或者产品的一次独立评估活动，他包括项目执行过程评审和项目产品审计两方面
 
29.软件项目常用的质量控制活动包括静态分析、动态测试、缺陷跟踪三个方面
 
30.影响软件项目进度、质量和成本的因素是人、技术和过程
 
31.组织结构的主要类型有职能型、项目型和矩阵型三种
 
32.风险规划的主要策略有回避风险、转移风险、损失风险和自留风险
 
33.项目评审按时间通常分为定期评审、阶段评审和事件评审等
 
34.甲方合同管理主要包括验收和违约处理两个过程

 
 
谁能告诉我这科的理论在哪可以实用呀？搞不懂，只能收藏一下包不挂科
 
 
知识点总结
 
第一章：
 
软件工程定义：
 
1968年10月，Fritz Bauer 首次提出了“软件工程”的概念，并将“软件工程”定义为：为了经济地获得能够在实际机器上有效运行的可靠软件，而建立并使用的一系列工程化原则。
 
1993年IEEE对软件工程的定义：软件工程是将系统化的、规范化的、可度量的途径应用于软件的开发、运行和维护的过程，即将工程化应用于软件的方法的研究。
 
软件工程原则：
 
抽象与自顶向下，逐层细化  信息隐蔽和数据封装 模块化 局部化 确定性 一致性和标准化 完备性和可验证性
 
瀑布模型：
 
开发活动的特征：（1）以上一项活动方产生的工作对象为输入(2)利用这一输入,实施本项活动应完成的内容(3)给出该项活动的工作结果,作为输出传给下一项活动(4)对实施该项活动的工作结果进行评审,若其工作得到确认,则继续进行下一项活动,否则返回前项,甚至更前项的活动进行返工
 
瀑布模型的优点:
 
(1)可强迫开发人员采用规范化的方法
 
(2)严格地规定了每个阶段必须提交的文档
 
瀑布模型的缺点
 
(1)由于瀑布模型几乎完全依赖于书面的规格说明,很可能导致最终开发出的软件产品不能真正满足用户的需要。如果需求规格说明与用户需求之间有差异,就会发生这种情况(2)瀑布模型只适用于项目开始时需求已确定的情况。总地来说,瀑布模型是一种应付需求变化能力较弱的开发模型,因此,很多在该模型基础上开发出来的软件产品不能够真正满足用户需求
 
第二章：
 
可行性研究的过程：
 
复查系统规模和目标
复查系统定义，改正含糊或不确切的叙述，清晰地描述对目标系统的一切限制和约束
 
研究目前正在使用的系统
现有的系统是信息的重要来源。若一个软件是对旧系统的改造，那开发新系统时，要充分了解老系统存在的问题，需要增加的功能，新系统实际上是老系统的部分功能加上一些新增功能形成的系统
 
导出新系统的高层逻辑模型
重新定义问题
新系统的逻辑模型实质上表达了分析员对系统必须做什么的看法，得到新系统的高层逻辑模型之后，可能会发现前面问题定义的范畴过大，分析员还要和用户一起再复查问题定义，对问题进行重新定义和修正。
 
导出和评价供选择的解法
分析员应该从系统逻辑模型出发，研究问题的几个组成部分，细化各功能点，导出若干个较高层次的物理解法供比较和选择
 
推荐行动方针
草拟开发计划
任务分解 进度规划 财务预算 风险分析及对策
 
书写文档提交复查
第三章：
 
一.软件需求的定义：
 
以清晰、简单、一致且无二义性的方式，描述用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对软件系统的约束。
 
二.需求分析的任务：
 
业务需求：是客户对于软件系统的高层次目标要求，定义了项目的远景和范围
用户需求：从用户角度描述软件系统的功能需求与非功能需求，通常只涉及系统的外部行为。
功能需求：功能需求描述软件系统应该提供的功能或务,通常涉及用户或其他外部系统与目标系统之间的交互,不考虑目标系统内部的实现细节
非功能需求：非功能需求即性能需求，反映了客户对软件系统质量和性能的额外要求
约束条件： 约束条件是软件系统设计和实现时必须满足的限制条件
业务规则： 业务规则是对某些功能的可执行性成内部执行速制的一些限定条件
外部接口需求:    外部接口需求是描述目标系统与外部环境之间的交互接口
数据定义:当用户描达一个数据项或一个复杂的业务数据结构的格式或缺省值时,正在进行数据定义
第四章：
 
启发规则：
 
启发规则是软件结构设计优化准则，软件概要设计的任务就是软件结构的设计，为了提高设计的质量，必须根据软件设计原理设计软件，利用启发规则优化软件结构。
 
1.改进软件结构提高模块独立性2.模块规模适中3.适当控制深度、宽度、扇出、扇入
 
4.模块的作用域应该在控制域之内5.力争降低模块接口的复杂程度
 
6.设计单入口单出口的模块7.模块功能可预测
 
第五章：
 
详细设计的过程
 
软作详细设计是软件工程的重要阶段,在详细设计过程中,细化了高层的体系结构设计，将软件结构中的主要部件划分为能独立编码、编译和测试的软件单元,并进行软件单元的设计,同时确定了软件单元和单元之间的外部接口。
 
一.详细设计的基本任务：
 
算法设计:用某种图形、表格、语言等工具将每个模块处理过程的详细算法描述出来
数据结构设计:对于需求分析,概要设计确定的概念性的数据类型进行确切的定义
物理设计： 对数据库进行物理设计,即确定数据库的物理结构
其他设计
a.代码设计：为了提高数据的输入、分类、存储及检索等操作的效率,对数据库中的某些数据项的值要进行代码设计b.输入/输出格式设计c.人机对话设计
 
编写详细设计说明书  6 . 评审：对处理过程的算法和数据库的物理结构要进行评审
二.详细设计方法：
 
自顶向下，逐步求精  2.具有单入、单出的控制结构 3. 五种控制结构：顺序结构，选择，先判断型循环结构，后断型循环结构，多选择分支结构
第七章：
 
一．测试用例设计：
 
白盒测试是对软件的过程细节做细致的检查。这一方法把测试对象看作 个打开的盒子，允许测试人员利用程序内部的逻辑结构及有关信息设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态,确定实际的状态是否与期望的状态一致。
 
覆盖标准：
 
语句覆盖
含义：就是选择足够多的测试用例，运行被测程序，使得程序中每条语句至少执行一次。
 
判定覆盖
含义：又称为分支覆盖，在设计测试用例，针对程序中具有分支结构的部分，为了测试所有的可能结果，需要将每个分支都至少执行一次，查看相应的语句执行情况和结果
 
(1)a=2,b=0,x=4,覆盖RACBDE
 
(2)a=3,b=1,x=1覆盖 RABE
 
条件覆盖
条件覆盖是指设计测试用例时,除了保证每条语句执行一次,还要使判定表达式的每个条件的各种可能取值都至少执行一次,为了实现条件覆盖,保证各种可能的条件都取值,即保证
 
第一个判断有以下取值:a>1,a<=1,b=0,b≠0
 
第二个判断有以下取值:a=2,a≠2,x>1,x<=1
 
选择两组测试用例:
 
(1)a=2,b=2,x=2(满足a>1,b≠0,a=2,x>1的条件),执行路径为 RABDE
 
(2)a=1,b=0,x=0(满足a<=1,b=0,a≠2,x<=1的条件),执行路径为RABE
 
判定/条件覆盖
单独使用判定覆盖和条件覆盖测试结果都不够全面, 若将两种覆盖结合，就会相互补充,判定/条件覆盖就是设计足够多的测试用例，使得每个判定表达式中的每个条件都取到各种可能的值,并且使每个判断语句的所有判断结果至少出现一次。
 
(1)a=2,b=0,x=2(满足a>1,b=0,a=2,x>1的条件)，执行路径RACBDE
 
(2)a=1,b=1,x=1(满足a<=1,b≠0,a≠2,x<=1的条件)，执行路径RABE
 
条件组合覆盖
条件组合覆盖就是设计足够多的测试用例,使得每个判定表达式中条件取值的各种组合都至少出现一次。根据每个判定表达式情况,列出如下条件组合
 
(1)a>1,b=0,A表达式为真;(2)a>1,b≠0,A表达式为假;(3)a<=1,b=0,A表达式为假
 
(4)a<=1,b≠0,A表达式为假;(5)a=2,x>1,B表达式为真(6)a=2,x<=1,B表达式为真;
 
(7)a≠2,x>1,B表达式为真;(8)a≠2,x<=1,B表达式为假。
 
选择以下四组测试用例
 
选择条件a=2,b=0,x=2,(1)、(5)组合,执行路径 RACBDE
 
选择条件a=2,b=1,x=1,(2)、(6)组合,执行路径 RABDE
 
选择条件a=1,b=0,x=2,(3)、(7)组合,执行路径 RABDE
 
选择条件a=1,b=1,x=1,(4)、(8)组合,执行路径 RABE
 
路径覆盖
就是选取足够多的用例，保证程序的所有路径都至少执行一次，如果存在环形结构，也要保证此环的所有路径都至少执行一次。
 
(1)a=1,b=1,x=1(满足a<=1,b≠0,a≠2,x<=1的条件),执行路径为RABE
 
(2)a=2,b=0,x=2(满足a>1,b=0,a=2,x>1的条件),执行路径为 RACBDE
 
(3)a=2,b=1,x=2(满足a>1,b≠0,a=2,x>1的条件),执行路径为 RABDE;
 
(4)a=3,b=0,x=1(满足a>1,b=0,a≠2,x<=1的条件),执行路径为 RACBE
 
二．测试的步骤：
 
单元测试
a.单元测试的主要任务
 
单元测试针对每个模块,主要解决五个方面的问题：(1)模块接口(2)局部数据结构（3）路径测试 (4)过界条件 (5)出错处理
 
b.单元测试的执行过程
 
集成测试
a.非增式集成测试方法 b. 增式集成测试方法
 
确认测试
确认测试的标准  配置审查的内容  Alpha Beta 测试  
 
系统测试
方法：恢复测试方法   安全测试方法  强度  性能
 
第八章：
 
一．软件维护的概念
 
软件维护是指在软件运行或维护阶段对软件产品所进行的修改,这些修改可能是改
 
正软件中的错误,也可能是增加新的功能以适应新的需求,但是一般不包括软件系统结
 
构上的重大改变。根据软件维护的不同原因,软件维护可以分成四种类型
 
(1)改正性维护
 
在软件交付使用后,由于开发时测试得不彻底或不完全,在运行阶段会暴露一些开
 
发时未能测试出来的错误,为了识别和纠正软件错误,改正软件性能上的缺陷,避免实
 
施中的错误使用,应当进行的诊断和改正错误的过程,这就是改正性维护
 
(2)适应性维护
 
随着计算机技术的飞速发展和更新换代,软件系统所需的外部环境或数据环境可能
 
会更新和升级,如操作系统或数据库系统的更换等。为了使软件系统适应这种变化,需
 
要对软件进行相应的修改,这种维护活动称为适应性维护
 
(3)完善性维护
 
在软件的使用过程中,用户往往会对软件提出新的功能与性能要求,为了满足这些
 
要求,需要修改或再开发软件,以扩充软件功能、增强软件性能、改进加工效率、提高软件
 
的可维护性,这种情况下进行的维护活动叫作完善性维护,完善性维护不一定是救火
 
式的紧急维修,而可以是有计划的一种再开发活动
 
4)预防性地护
 
这类维护是为了提高软件的可维护性,可靠性等,为以后进一步改进软件打下良好
 
的基础的维护活动,具体来讲,就是采用先进的软件工程方法对需要维护的软件或软件中的某一部分重新设计、编码和测试的活动。
 
二．软件维护的特点
 
1.软件维护受开发过程影响大
 
2.软件维护困难多
 
3.软件维护成本高
 
三．软件维护的步骤
 
软件维护工作包括建立维护组织、报告与评估维护申请、实施维护流程等步骤。
 
在影响分析和版本规划的过程中,不同的维护类型需要采用不同的维护策略
 
（1）改正性维护:首先应该评价软件错误的严重程度,对于十分严重的错误,维护
 
员应该立即实施维护对于一般性的错误,维护人员可以将有关的维护工作与其他开发
 
任务一起进行现划。在有些情况下,有的错误非常严重,以致不得不临时放弃正常的维
 
护控制工作程序,既不对修改可能带来的副作用作出评价,也不对文档作相应的更新,而
 
是立即进行代码的修改。这是一种救火式的改正性维护,只有在非常紧急的情况下才使
 
用,这种维护在全部维护中只占很小的比例。应当说明的是,救火式不是取消,只是推迟
 
了维护所需要的控制和评价。一旦危机取消,这些控制和评价活动必须进行,以确保当
 
前的修改不会增加更为重要的问题
 
(2)适应性维护:首先确定软件维护的优先顺序,再与其他开发任务一起进行规划
 
(3)定善性维护,根据商业的需求和软件的发展，有些完善性维护可能不会被接受。对于被接受的维护中请,应该确定其优先次序井现划其开发工作
 
第九章
 
质量保证
 
产品的生命，不论生产何种产品，质量都是极端重要的。软件产品开发周期长，耗费巨大的人力和物力，更必须特别注意保证质量。
 
软件质量：概括地说，软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说，软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。
 
软件质量因素的定义：
 
正确性：系统满足规格说明和用户目标的程度,即,在预定环境下能正确地完成预期功能的程度
 
建壮性：在硬件发生故障、输人的数据无效或操作错误等意外环境下,系统能做出适当响应的程度
 
完整性(安全性)：对未经授权的人使用软件或数据的企图,系统能够控制(禁止)的程度
 
效率：为了完成预定的功能,系统需要的计算资源的多少
 
可用性：系统在完成预定应该完成的功能时令人满意的程度
 
风险：按预定的成本和进度把系统开发出来,并且为用户所满意的概率
 
可理解性：理解和使用该系统的容易程度
 
可维修性：诊断和改正在运行现场发现的错误所需要的工作量的大小
 
灵活性(适应性)：修改或改进正在运行的系统需要的工作量的多少
 
可测试性：软件容易测试的程度
 
可移植性：把程序从一种硬件配置和(或)软件系统环境转移到另一种配置和环境时,需要的工作量多少,有一种定量度量的方法是:用原来程序设计和调试的成本除移植时需用的费用
 
可再用性：在其他应用中该程序可以被再次使用的程度(或范围)
 
互运行性：把该系统和另一个系统结合起来需要的工作量的多少
 
软件质量保证的措施主要有：基于非执行的测试（也称为复审或评审），基于执行的测试（即以前讲过的软件测试）和程序正确性证明。
 
复审主要用来保证在编码之前各阶段产生的文档的质量；基于执行的测试需要在程序编写出来之后进行，它是保证软件质量的最后一道防线；程序正确性证明使用数学方法严格验证程序是否与对它的说明完全一致
 
技术复审的必要性：
 
正式技术复审的显著优点是，能够较早发现软件错误，从而可防止错误被传播到软件过程的后续阶段。
 
正式技术复审是软件质量保证措施的一种，包括走查和审查等具体方法。走查的步骤比审查少，而且没有审查正规。
 
走查主要有下述两种方式。 
 
（1） 参与者驱动法。参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须回答每个质疑，要么承认确实有错误，要么对质疑做出解释。
 
（2） 文档驱动法。文档编写者向走查组成员仔细解释文档。走查组成员在此过程中不时针对事先准备好的问题或解释过程中发现的问题提出质疑。这种方法可能比第一种方法更有效，往往能检测出更多错误。经验表明，使用文档驱动法时许多错误是由文档讲解者自己发现的。
 
审查步骤： 
 
（1） 综述。由负责编写文档的一名成员向审查组综述该文档。在综述会结束时把文档分发给每位与会者。
 
（2） 准备。评审员仔细阅读文档。最好列出在审查中发现的错误的类型，并按发生频率把错误类型分级，以辅助审查工作。这些列表有助于评审员们把注意力集中到最常发生错误的区域。
 
（3） 审查。评审组仔细走查整个文档。和走查一样，这一步的目的也是发现文档中的错误，而不是改正它们。通常每次审查会不超过90分钟。审查组组长应该在一天之内写出一份关于审查的报告。
 
（4） 返工。文档的作者负责解决在审查报告中列出的所有错误及问题。
 
（5） 跟踪。组长必须确保所提出的每个问题都得到了圆满的解决（要么修正了文档，要么澄清了被误认为是错误的条目）。必须仔细检查对文档所做的每个修正，以确保没有引入新的错误。如果在审查过程中返工量超过5%，则应该由审查组再对文档全面地审查一遍。
 
程序正确性证明：
 
测试可以暴露程序中的错误，因此是保证软件可靠性的重要手段；但是，测试只能证明程序中有错误，并不能证明程序中没有错误。因此，对于保证软件可靠性来说，测试是一种不完善的技术，人们自然希望研究出完善的正确性证明技术。
 
 
 
 
 
软件工程一测
 
 
 
软件工程三要素：______________、_________________、_________________
获取愿景的三部曲：
愿景_______（是/否）功能。
愿景必须指出__________
迭代与增量的定义
UML静态图包括（4个）
UML动态图包括（5个）
为什么使用UML语言
______________是软件成功的基础。
 
 
 
 
答案：
 
工具（系统）、方法（技能）、开发过程（框架）
第一步：找到软件项目的“老大”；第二步：得到“老大”对项目的期望（愿景）；第三步：描述出愿景的度量指标。
否
度量指标
迭代是反复求精，增量是逐块建造
类图、对象图、组件图、部署图
时序图、协作图、状态图、活动图、用例图
主要用于交流，有利于清晰，有利于精确
需求
 
 
 
 
软件工程二测
 
 
 
在项目失败的因素中，与      相关的比例最高。
      是解决需求噩梦的手段。
简要分析项目开发过程中，公司老板、中层经理、一线员工的需求分别有什么特点。
ICONIX过程从把需求文档变成可运作的代码过程只需四步，需要使用哪四张UML图？
若某公司设有公司老总、市场总监与财务总监，实现强化客户管理功能、提升财务效率功能、优化公司资源功能的三种软件，“老大”分别是谁？
 
 
答案：
 
1.需求
 
2.需求工程
 
3.公司老板：企业战略、开源节流（定于愿景）
 
  中层经理：简化管理、优化流程（业务建模）
 
  一线员工：工作简单（用例分析）
 
4.用例图、序列图、类图、健壮性图
 
5.强化客户管理：市场总监
 
  提升财务效率：财务总监
 
  优化公司资源：公司老总
 
 
 
 
 
 
 
软件过程三测
 
 
 
业务建模序列图阶段要注意什么？
业务序列图中，alt表示（           ），loop表示（              ），opt表示（         ）；
Alt和opt在使用的时候有什么区别？
业务序列图中，消息的名字表示什么？
业务序列图中，消息的方向表示什么？
把（        ）看作特殊的业务实体。
业务建模结果复核目的有两点，分别是什么？
 
 
 
 
 
 
 
 
答案：
 
本阶段不要考虑要实现什么系统
分支，循环，可选分支
Alt表示分支，是需要条件的；opt表示可选分支，没有条件，有选择性。
代表责任和目的
责任委托，不是数据流动
时间
一是完善业务建模成果，寻找是否有遗漏或错误的地方进行修正，如果问题明显，就需要迭代回去继续做业务建模工作；
二是关键干系人在信息和意见上达成一致，并共同签字确认，作为下一阶段启动的标志。
 
 
 
 
 
 
 
 
 
 
 
 
 
软件工程四测
 
 
 
业务建模要求我们把视角从_______，以达到清晰准确地“诊断”，对症“开方”
答案：软件系统转向客户组织，站在客户角度看问题
 
2、业务建模三步骤：
 
1、___________2、____________3、____________
 
答案：
 
明确我们为谁服务（选定愿景要改进的组织）。
要改进的组织是什么现状（业务用例图、现状业务序列图）。
我们如何改进（改进业务序列图）。
3、了解组织现状：
 
   （1）从外部看：组织是____的集合，用业务用例图来建模
 
   （2）从内部看：组织是____的集合
 
答案：价值、系统
 
4、业务用例图帮助我们从______了解组织的______。
 
答案：高层次 、业务构成
 
5、业务执行者是在业务组织之外，与其交互，享受其价值的_______
 
答案：人或组织
 
6、业务用例是业务组织为业务执行者提供的______.
 
答案：价值
 
7、业务序列图帮助我们从______了解组织的______。
 
答案：细节上、 业务流程
 
8、业务序列图详细描述________、_______、________之间如何交互，以完成某个业务用例的实现流程
 
答案：业务执行者、业务工人、业务实体
 
9、举个简单的例子并识别其中的业务对象：业务执行者、业务工人、业务实体
 
答案：自由发挥
 
10、我们如何改进（改进业务序列图）
 
答案：了解业务组织现状的目的——发现流程中的改进点：
 
信息自动流转
封装复杂业务逻辑
职责转移
访问和操作业务对象
其他……
 
 
 
软件过程五测
 
域建模_____不等于_____（等于或不等于）数据模型
___用例分析________前做域建模
需求分析的主流分析方法有___原型法____、______用例法_______
绘制系统用例图的步骤
1. 确定系统边界
 
2. 识别系统执行者
 
3. 识别系统用例
 
4. 确定用例间的关系
 
怎样区别主执行者和辅执行者
  主执行者：
 
1.用例发起者；
 
2.用例为其实现有价值的目标；
 
辅执行者：
 
1.用例支持者；
 
2.用例的完成需要与其交互，得到其支持
 
如何找到执行者
  谁使用该系统？
 
• 谁改变系统的数据？
 
• 谁从系统获取信息？
 
• 谁负责维护、管理并保持系统正常运行？
 
• 系统需要应付哪些硬件设备？
 
• 系统需要和那些外部系统交互？
 
• 谁对系统运行产生的结果感兴趣？
 
• 有没有自动发生的事件？
 
系统用例是执行者通过系统____达到某个目标______
用例的关系____泛化____、_____包含_______、______扩展__________
先发现执行者还是先发现用例？为什么？
   执行者比用例明显。
 
• 执行者的个数远比用例的个数少。
 
• 找到一个执行者，就可以找到一堆用例。
 
• 执行者是系统外部人物的代表，所以当然是要先找到执行者，才能够从执行者的角度去寻找用例。
 
用例命名的三个条件是什么？
 用例名称必须是动宾短语。
 
• 采用域建模中的名词术语。
 
• 慎用弱动词弱名词——会掩盖真正的业务
 
用例_____不等于______功能，用例____不等于______步骤
 
 
软件过程六测
 
每个用例必须对应有___愿景目标______
用例描述的基本组成__干系人利益_____________、_____基本路径____________、________扩展路径_______、_______业务规则_______________
_________用例_______是干系人利益的平衡点。
基本路径的书写要求。
  以主动语态、“名词-动词-名词”格式来书写。
 
  主语只能是执行者或系统。
 
基本路径与扩展路径是否要分开。
  要
 
 

1.软件的本质
 
1.1 软件是什么：
 
软件是能够完成预定功能和性能，并对相应数据进行加工的程序和描述程序操作的文档
 
 
1.2 软件的特点
 
软件是设计开发的，而不是传统意义上生产制造的
软件不会“磨损”
虽然整个工业向着基于构建的构造模式发展，然而大多数软件仍然是根据实际顾客的需求制定的
 
 
1.3 软件的失效曲线
 
 
1.4 硬件的失效曲线
 
 
1.5 软件的演化和遗留软件
 
软件需要适应性调整，从而可以满足新的计算环境或者技术的需求
软件必须升级以实现新的商业需求
软件必须被扩展使之具有与更多系统和数据库的互操作能力
软件架构必须进行改建以适应不断演化的计算环境
 
 
1.6 软件应用领域
 
系统软件
应用软件
人工智能软件
web应用软件
嵌入式软件
产品线软件
工程/科学软件
移动应用软件
 
 
1.7 Web App 的特点
 
数据驱动
内容敏感性
持续演化
及时性
安全性
美观性
 
 
1.8 移动 App 的特性
 
移动平台上专门设计的软件
用户接口，用户接口利用移动平台所提供的独特交互机制
移动平台中的持续储存能力
基于Web资源的互操作性提供与app相关的大量信息的访问，并且具有本地处理能力
移动app可以直接访问本地的硬件，并提供本地存储和处理能力
移动web应用系统和移动app之间的界限越来越模糊
移动web应用系统允许移动设备通过针对移动平台的优点和弱点专门设计浏览器获取基于web内容的访问
 
 
1.9 云计算
 
 
云计算提供分布式数据处理和存储功能，他能使得任何用户在任何地点都能使用计算设备来共享广泛的计算资源
计算设备位于云的外部，可以访问云内部的各种
云计算的实现需要开发包含前端和后端服务的体系结构
前端包括客户（用户）设备和应用软件（例如浏览器）用于访问后端
后端包括服务器和相关的计算资源、数据存储系统（如数据库）、服务器驻留应用程序和管理服务器
可以对云体系结构进行分段，提供不同级别的访问
 
 
1.10 软件产品线
 
软件产品线是一系列软件密集型系统，可以共享一组公共的可管理的特性，这些特性可以满足特定市场或任务的特定需求
软件产品线都使用相同的底层应用软件和数据体系结构来开发，并使用可在整个产品线中复用的软件构件来实现。
软件设计线可以共享一组资源，包括需求、体系结构，设计模式，可重用构建、测试用例以及其他软件工程工作产品。
软件产品线在对这些产品进行工程设计时，利用了产品线中所有产品的公共性。
 
 
1.11 软件危机的表现
 
软件开发的工作量估计困难，开发进度难以控制，质量难以保证
软件开发效率低
软件质量无法得到保证
软件开发成本过高
软件维护困难，用户满意度不高
 
 
1.12 软件危机的原因
 
（一）软件本身的需求和特征
 
软件规模大，复杂性高，性能不断增强
软件是逻辑产品，完全认识其本质和特点极其苦难
 
 
（二）工程管理技术缺乏
 
缺乏有效的、系统的开发、维护大型软件项目的技术手段和管理方法
 
 
（三）沟通和理解
 
用户对软件需求的描述和软件开发人员对软件需求的了解往往存在差异，用户经常要求修改需求，开发人员很难适应
 
（四）人员和技术
 
软件开发的技术人员和管理人员缺乏软件工程化的素质和要求，对工程化开发认识不足
 
 
2.软件工程
 
2.1 工程
 
工程是科学技术再某一领域的应用，通过这一领域应用，使自然界的物质和能源的特性能够通过各种结构，机器，产品，系统和过程，以时间最短和精而少的人力做出高效，可靠且对人类有用的东西。
 
 
2.2 系统工程
 
是一个跨多学科领域的工程，通常专注于如何设计和管理复杂的工程专案。
 
 
2.3 系统工程学
 
通过人和计算机的配合，能充分发挥人的理解、分析、推理、评价、创造等能力的优势，又能利用计算机高速运行和追踪能力。以此来实验和剖析系统，从而获得丰富的信息，为选择最优或次优的系统方案提供有力的工具。
系统工程学模型能容纳大量的变量；他是一种结构模型，通过他可以充分认识系统结构，并以此来把握系统的行为，而不只是依赖数据来研究系统行为。
系统工程学是结构方法，功能方法和历史方法的统一。它有一套完善的解决复杂系统问题的工具和技巧。
 
 
2.4 软件工程历史
 
1968年北大西洋公约（NATO）召开的计算机科学会议
 
软件工程 = 软件的工程
 
 
2.5 软件开发需面对的几个事实
 
确定软件方案之前，需要共同努力来理解问题
设计已成关键活动
软件应该具有高质量
软件需具备可维护性
 
 
2.6 软件工程目标和原则
 
目标 ：在给定成本、进度的前提条件下，开发出满足用户需求的高质量的软件产品 （高质量的含义： 有效性、可靠性、可适应性、可追踪性、移植性、可互操作性、可修改性）的软件产品。
原则：在软件开发中为了达到软件开发目标而必须遵守的原则包括：抽象、模块化、信息隐藏、局部化、一致性、可验性证
 
 
2.7 软件工程的定义
 
为了经济的获得可靠，在实际机器上高效运行的软件，而建立和使用的有使用价值的工程原则。
IEEE93：将系统的、规范的、可度量的方法应用于软件的开发、运行和维护的过程。
 
 
2.8 软件工程三要素
 
软件工程采用层次化（分解）的方法，每个层次都包括 过程 方法 工具三个要素
 
 
过程贯穿软件开发的各个环节
 
过程和方法：管理者在软件工程过程中通过适当的方法对软件开发的质量、进度、成本进行评估管理和控制；
 
方法和工具：开发人员采用相应的方法和工具生成软件工程产品（模型、文档、数据、报告、表格等）
 
 
2.9 软件工程过程
 
 
 
2.10 过程的适应性调整相关问题
 
活动、动作和任务的总体流程，以及相互依赖关系
在每一个框架活动中，动作和任务细化的程度
工作产品的定义和要求的程度
质量保证活动的应用方式
项目跟踪和控制活动应用的方式
过程描述的详细程度和严谨程度
客户和利益相关者对项目参与的程度
软件团队所赋予的自主权
队伍组织和角色的明确程度
 
 
2.11 软件工程实践
 
实践的精髓
 
理解问题（沟通和分析）
计划解决方案（建模和软件设计）
实施计划（代码生成）
检查结果的正确性（测试和质量保证）
 
 
理解问题
 
 
谁将从问题的解决中获益？
 
也就是说，谁将是利益相关者？
 
 
有哪些是未知的？
 
哪些数据、功能和特征是解决问题所必须的？
 
 
问题可以划分吗？
 
是否可以描述为更小，更容易理解的问题？
 
 
问题可以图形化描述吗？
 
可以建立分析模型吗？
 
 
 
计划解决方案
 
 
以前见过类似的问题吗？
 
潜在的解决方案中，是否可以识别一些模式？是否已经有软件实现了所需要的数据，功能和特征。
 
 
类似问题是否解决过？
 
如果是，解决方案所包含的元素是否可以复用？
 
 
可以定义子问题吗？
 
如果可以，子问题是否已有解决方案
 
 
能用一种可以很快实现的方案来描述解决方案吗？
 
能构建出设计模型吗？
 
 
 
实施计划
 
 
解决方案和计划一致吗？
 
源代码是否可以追溯到设计模型？
 
 
解决方案的每个组成部分是否可以证明正确？
 
设计和代码是否经过评审？或者采用更好的方式，算法是否经过正确性证明？
 
 
 
检查结果
 
 
能够测试解决方案的每个部分?
 
是否实现了合适的测试策略？
 
 
解决方案是否产生了与所需数据、功能和特征一致的结果？
 
是否按照项目利益相关者的需求进行了确认？
 
 
 
2.11 软件实践通用原则——HOOKER 的概括性原则
 
存在价值
KISS(保持简洁)
保持愿景
关注使用者
面向未来
计划复用
认真思考
 
 
2.12每个软件工程项目都来自业务需求
 
对现有应用程序缺陷的修正
改变遗留系统以适应新的业务环境
扩展现有应用程序功能和特性
或者开发某种新的产品，服务或系统
 
 
3. 软件过程结构和过程改进
 
3.1 通用软件过程模型
 

 
 
 
 任务集定义了为了达到一个软件工程动作的目标所需要完成的工作
 
要完成的任务列表
待生产的产品列表
待使用的质量保证技术列表（保证点、里程碑）
 
 
3.1 过程模式
 
（一） 过程模式（process pattern)
 
 
描述了软件工程工作中遇到的过程相关问题
 
 
明确了问题环境
 
 
给出了针对该问题的一种或多种可证明的解决方案
 
 
通俗地讲，过程模式提供了一个模板
 
一种在软件过程背景下，统一描述解决问题的方法。包括模式名称和驱动力。
 
 
 
（二） 过程模式类型
 
步骤模式（Stage patterns） 定义了与过程的活动框架相关的问题。
任务模式（Task patterns） 定义了与软件工程动作或是工作任务相关，关系软件工程实践成败的问题。
阶段模式（Phase patterns）定义了过程中发生的框架活动序列，即使这些活动流本质上是迭代的。
 
 
（三）过程模式模板
 
1. 启动条件
  	1. 组织或者团队的已有活动
  	2. 过程进入的状态
  	3. 已有的工程信息或者项目信息
2. 问题：要解决的具体问题
3. 解决方案：如何成功实现
	1. 初始状态如何改变
	2. 工程信息或者项目信息如何改变
4. 结果：
	1. 必须完成的相关活动任务
	2. 过程结束状态
	3. 产生的工程信息或者项目信息
 
 
(四)过程评估与改进
 
用于过程改进的CMMI评估方法—— 
  
启动
诊断
建立
执行
学习
 
用于组织内部改进的CMM评估方法，采用了SEI的CMM作为评估的依据，提供了一种诊断方法，用以分析软件开发机构相对成熟度。
SPICE——定义了软件过程评估的一些要求。该标准的目的是帮助软件开发组织建立客观的评价体系，以评估定义的软件体系的有效性
软件ISO 9001:2000——这是一个通用标准，任何开发组织或个人如果希望提高所提供的产品系统或服务的整体质量，都可采用这个标准。因此该标准可以直接应用于软件组织和公司。
 
 
3.2 CMM 能力成熟度模型：
 
L1：初始级
 
L2：可重复级
 
L3：已定义级
 
L4：已管理级
 
L5：优化级
 
 
关键过程域
 
描述软件过程的属性，通过完成一组相互关联的活动，实现一组对建立过程至关重要的目标
 
关键过程域是SEI标识的，帮助确定软件开发组织的软件过程能力，评估软件成熟度的基本单元
关键过程域用具有固定结构和语句的框架标识 
  
关键过程域的目标是指导和评估组织或组织的项目有效实践关键过程域的指南，是关键过程域应当完成的任务和进行关键实践的概括描述。
 
 
3.3 CMMI 能力成熟度模型：
 
CMM的成功导致许多领域也建立了相应的评估模型，但是导致了模型框架和术语等方面的矛盾和不一致
 
 
产生过程和主要参考模型
 
1998年正式启动，来自业界和政府部门和SEI/CMU 三个方面的170余人的支持，经过两年的工作发表了v1.0
 
主要参考模型：
 
软件学科的 SW-CMM
 
集成化开发和过程开发领域的IPD CMM V0.98
 
CMMI的集成原则
 
 
阶段表示法
 
 
连续式表示法
 
软件学科的两种表示法均采用统一的24个域，它们在逻辑上是等价的
 
 
 
 
 
4 过程模型
 
4.1惯用过程模型
 
惯用过程模型力求达到软件开发的结构和秩序
 
这将产生一些问题
 
 
4.2 软件生存周期
 
传统上分为三个时期，7个阶段
 
软件定义 
  
问题定义
可行性分析
需求分析
 
软件开发 
  
系统设计
编码
测试
 
软件运行 
  
维护
 
 
 
4.3 传统瀑布模型
 
软件开发过程与软件生命周期是一致的
相邻二阶段之间存在因果关系
需要对阶段性产品进行评审
 
 
（一）优点
 
软件生命周期模型，使得软件开发可以在分析、设计、编码、测试、和维护的框架下进行
软件开发过程具有系统性，可控性，克服了软件开发的随意性。
 
 
（二）缺点
 
项目开始阶段用户很难精确的提出产品需求，由于技术进步，用户对系统深入的理解，修改需求十分普遍。
项目开发晚期才能得到程序的运行版本，这时修改软件需求和修正开发中的错误的代价很大。
采用线性模型组织项目开发经常发生开发小组人员“堵塞状态”。特别是项目开始和结束阶段。
 
 
4.4 软件开发的V模型
 
 
 
4.5 软件开发的新瀑布模型
 
增加了项目策划
将设计和编码测试分开
进一步细化各个阶段
软件生命周期由原来的三时期七阶段==》五时期十七阶段
仍然保持原来的特点
 
 
4.6增量过程模型
 
增量：
 
小而可用的软件
 
 
特点
 
在前面的增量的基础上开发后面的增量
每个增量的开发可以用瀑布或者快速原型模型
迭代的思路
 
 
 
4.7 演化模型： 原型模型
 
原型模型支持软件需求开发，帮助用户和开发人员理解需求，是软件需求工程的关键
如果开发的原型是可运行的，它的若干高质量的程序片段和开发工具可用于工作程序的开发
原型的开发和评审是系统分析元和客户/用户共同参与的迭代过程，每个迭代循环都是线性过程
第一个原型通常会不太好用，太大或太慢
利益相关者无法意识到原型的临时性，不愿意抛弃，总是希望小修改后使用，软件开发管理层大多数情况下会妥协。
软件工程师为了快，会使用折中手段，采用自己熟悉的语言，系统乃至低效的算法。
 
 
 
4.8 螺旋模型
 
Bohem在1988年提出
 
螺旋模型=瀑布模型（系统化）+原型（迭代）
 
螺旋模型适用于计算机软件整个生命周期
 
 
 
 
 
4.9 螺旋模型的使用
 
软件工程项目从螺旋中心开始启动，沿顺时针方向前进
 
第一圈：产生产品规格说明
第二圈：产生一个用于开发的原型
第三圈：产生软件产品的初始版本
第四圈：产生软件产品比较完善的新版本
 
 
4.10 螺旋模型的有优点
 
符合人们认识现实世界和软件开发的客观规律
支持软件整个生命周期
保持瀑布模型的系统性，阶段性
利用原型评估和降低开发风险
开发者和用户共同参与软件开发，尽早发现软件中的错误
不断推出和完善版本软件，有助于需求变化，获取用户需求，加强对需求的理解
 
 
4.11 演化模型：并行模型
 
表示一个软件工程活动的状态
 
所有活动并发存在，但是处于不同的状态
 
可以用于所有类型的软件开发
 
 
 
 
4.12 其他专用过程模型
 
基于构建的并发模型——能够使软件复用
形式化方法模型——注重需求的数学规格说明
面向方法的软件开发模型——为定义、说明、构建和设计方面提供过程和方法
统一过程模型——一种“用例驱动，以构架为中心的迭代和增量”软件过程和统一建模语言（UML）紧密结合
 
 
 
 
 
4.13 UP工作产物
 
 
起始阶段：
 
  
版本文档
初始项目表
初始商业用例
初始风险评估
项目计划、阶段和迭代
商业模型
一个或多个原型
 
 
细化阶段：
 
  
用力模型
补充需求（包含非功能性的分析模型和软件架构描述）
可执行的框架原型
初步设计模型
修正的风险清单
项目计划（包括迭代计划，适应性工作流，里程碑和技术性工作产物）
初步使用手册
 
 
构建阶段
 
  
设计模型
软件构件
集成软件增量
测试计划和步骤
测试用例
支持文档
用户手册
安装手册
当前版本描述
 
 
转换阶段
 
  
交付软件增量
Beta测试报告
用户反馈报告
 
 
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YFKaE1p9-1637057983927)(C:\Users\asus\AppData\Roaming\Typora\typora-user-images\image-20211109124756741.png)]
 
 
 
4.14 RUP 软件生命周期
 
四个阶段 阶段的结束标志着重要的里程碑
 
先启 - 定义整个项目的范围
精化 - 制定项目计划、描述功能、建立体系架构框架
构建 - 构造软件产品
产品化 - 将软件产品移交到最终用户手中
 
 
4.15 迭代和阶段
 
迭代 是一个基于确定计划和评估标准并产生一个可执行发布版本（内部的或外部的）的独特活动序列。
 
初启阶段
精化阶段
构建阶段
移交阶段
 
 
4. 16 软件过程的定义
 
软件过程定义由 谁 在 什么时候 做 什么事情， 并且 如何 去达到一定的目标
 
 
4.17 统一过程的模型
 
用例模型：用例与用户之间关系（交互时）
 
分析模型：系统的行为初步分配给一组对象
 
设计模型：系统静态结构定义为子系统，类，接口，并定义由子系统、类和接口之间的协作所实现的用例
 
实现模型：构建（表现为源代码）和类到构件的映射
 
实施模型：计算机的物理节点和构件到这些节点的映射
 
测试模型：用于验证的测试用例
 
 
4.18个人软件过程 PSP
 
策划
高层设计
高层设计评审
开发
后验
 
5 敏捷开发
 
5.1 敏捷开发宣言
 
 
5.2 什么是敏捷
 
对变更的良好响应：有效且灵活的响应变化
个人和他们之间的交流：利益相关者（经历，客户，最终用户）之间的有效沟通
客户合作：将客户作为开发团队的一部分，不再分你我
组织高度自主的项目团队（敏捷团队）：承认计划的局限性，项目计划灵活调整，过程设计是的团队与任务相适应，任务流水线化，提前指定计划，保留最重要的工作产品且力求整洁，增量交付。
最重要的是：快速交付给用户可运行软件增量
 
敏捷是一种理念，是一种以人为本的哲学思想
 
 
5.3变更成本以及敏捷过程
 
工程变更的成本 每过一阶段变回变为上一阶段的x倍
 
一个良好设计的敏捷过程可以拉平成本曲线
 
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cIj0RXGj-1637057983932)(C:\Users\asus\AppData\Roaming\Typora\typora-user-images\image-20211109201119948.png)]
 
 
5.4敏捷过程
 
三个假设（不可预测性）：1）需求变更预测，以及客户优先级的变更预测的困难
 
​ 2）在构建验证之前很难估计应该设计到什么程度；
 
​ 3）从在制定计划的角度看，分析，设计，构建和测试不像 我们想象的那样难以预测
 
因此，我们应当遵守如下过程：
 
由用户所需的应用场景驱动
认识到计划时间很短
使用增量式开发策略
交付多个软件增量版本
能做出适应性变更
 
 
5.5 敏捷原则
 
我们最优先要做的是通过尽早，持续交付有价值的软件来使客户满意
即使在开发的后期，也欢迎需求变更，敏捷过程利用便捷客户来创造竞争优势
经常交付可运行软件，交付的间隔可以是从几个星期到几个月，交付的时间间隔越短越好
在整个项目开发期间，业务人员必须天天一起工作
围绕有积极性的个人构建项目，给他们提供所需要的环境和支持，并且信任他们可以完成任务
在团队内部，最富有效果和效率的信息传递方法是面对面交流，
可运行软件是进度的首要度量标准
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应能长期保持稳定的开发速度
不断地关注优秀的技能和好的设计会增强敏捷能力
简单——使不必要做的工作最大化的艺术——是必要的
最好的构架、需求和设计出自于自组织团队
每隔一段时间，团队反省如何才能更有效的工作，并相应调整自己的行为
 
 
5.6 人的因素
 
基本能力
共同目标
精诚合作
决策能力
模糊问题解决能力
相互信任和尊重
自组织
 
 
5.7 极限编程（XP）
 
是使用最广泛的编程
 
 
 
XP策划
 
 
XP设计
 
 
XP编程
 
 
XP测试
 
 
 
 
5.8 行业极限编程
 
IXP的管理具有更大的包容性，扩大了用户角色，升级了技术实践
 
准备评估
项目社区
项目特许
测试驱动管理
回顾
持续学习
 
 
5.9 Scrum基本特征
 
包括了一系列实践和预定义角色的过程骨架
 
基本特征：
 
 
开发活动由工作单元完成
 
 
测试和文档编制工作贯穿始终
 
 
发生于一个过程模式中的工作任务称为一个冲刺，其来源于待定项中定义的需求
 
 
例会时间很短，有时候甚至站立开会
 
 
在规定时间内将演示软件交付给用户
 
 
 
 
5.10 Scrum 四大支柱
 
迭代开发
增量交付
自组织团队
高优先级的需求驱动
 
 
5.11 敏捷方法之极限编程和Scrum的区别
 
迭代长度不同
在迭代中是否允许修改
在迭代中，User story 是否严格按照优先级别来实现
软件的实施过程中 ，是否采用严格的工程方法，保证进度或者质量
 
 
5.12 动态系统开发方法(DSDM)
 
DSDM认为任何事都不能一次性圆满完成，应当以20%的时间完成80%的有用功能，以适应商业目的为准。
 
在很多方面类似于极限编程
 
九条基本原则：
 
 
用户持续参与
 
 
必须授予DSDM团队制定决策的权力
 
 
注重产品的经常交付
 
 
满足业务用途是接受交付品的主要依据
 
 
迭代和增量式开发对于得到正确的业务解决方案是必不可少的
 
 
开发过程中所有的变化可逆
 
 
在高层次上制定需求的基线
 
 
测试自始至终贯穿于开发周期之中
 
 
所有项目涉众的通力合作是必不可少的
 
 
 
 
5.13 敏捷建模
 
提出一系列的敏捷建模原则
 
有目的的建模
 
使用多个模型
 
轻装上阵
 
内容重于表述形式
 
理解模型及工具
 
适应本地需要
 
 
5.14 敏捷统一过程（AUP）
 
每个AUP迭代执行以下活动
 
建模
实现
测试
部署
配置以及项目管理
环境管理
 
 
6 软件工程人员
 
6.1 软件工程师的特质：
 
个人责任感
对团队成员和利息相关者的需求有敏锐的意识
对有缺陷的设计，用诚实且有建设性的方式指出错误
抗压能力
高度的公平感
注重细节
务实
 
 
6.2 软件工程的行为模式
 
 
 
6.3 跨界团队角色
 
外联员 -代表团队和外部顾客谈判
侦查员 -突破团队界限收集组织信息
守护员 -保护团队产品
安检员 -把控利益相关者和他人向团队传送的信息
协调员 -注重横跨团队和组织内部的交流
 
 
6.4 高效团队的特征
 
目标意识
参与意识
培养信任感
鼓励进步意识
团队技能的多样化
 
 
6.5 避免团队毒性
 
混乱的工作环境会造成团队成员的精力浪费，失去对工作目标的关注
由个人，商业或者技术原因造成的高度挫折会导致 团队成员的分裂
“支离破碎或协调不当”的软件过程模型或是定义错误的，选择不当的软件过程模型会成为工作中的阻碍。
对软件团队中角色的模糊定义会造成团队缺乏责任感，遇到问题互相指责。
“持续且重复性的失败”会打击士气，使得团队成员缺乏自信。
 
 
6.6 影响团队结构的因素
 
需解决问题的难度
基于代码行或者功能点的结果程序的规模
团队成员合作的时间
问题可规模化的程度
所建系统的质量和可靠性
交付日期要求的严格程度
项目所需的社会化
 
 
6.7 组织模式
 
封闭模式：遵循传统的权力层级模式
随机模式：团队松散，依靠团队个人自发性
开放模式：尝试组成一种团队，既具有封闭模式的可控性，又具有随机模式的创新性
同步模式：有赖于问题的自然区分，不需要很多交流就可以将成员组织起来共同解决问题。
 
 
6.8 敏捷团队
 
强调个人（团队成员）通过团队合作可以加倍的能力。这是团队成功的关键因素
 
人员胜过过程，政策胜过人员
 
敏捷团队都是自组织的，并且具有多种团队结构
 
自适应结构
运用constantine提出的随机，开放和同步模式。
重要的自主性
 
计划被保持到最低程度，仅仅接受商业要求和组织标准的限制
 
 
6.9 极限编程团队的价值
 
交流
简单
反馈
勇气
尊重
 
 
6.10 社交媒体的影响
 
博客- 用来与团队成员和客户分享技术信息
 
微博（如twitter） 允许对关注他们的人员发布实时信息
 
Targeted on-line 论坛 - 允许参与者发布问题或者观点，并且得到答复。
 
社交网络：在以分享技术信息为目的的软件开发人员之间建立起联系。
 
网址收藏夹：允许开发人员追踪和共享网络资源
 
 
6.11 软件工程中云的应用
 
优势：
 
提供获取各种软件工程工作产品的方法
消除对于设备依赖的限制，并且在各处都能运行
提供新的分配方法和软件测试
对于所有团队成员来说，都能获得其中某个成员开发出的软件工程信息
 
缺点：
 
分散的云服务在软件团队的控制范围之外，因此存在可靠性和安全性风险，
随着云提供的服务越来越多，其在协同性上的风险也越来越高。
云服务强调的可用性和性能，常常会与安全性，保密性和可靠性相互冲突。
 
 
6.12 协作工具
 
命名空间 使项目团队可以用加强安全性和保密性的方法存储工作产品
进度表 可以协调项目事件
模板 可以使团队成员在创造工作产品时保持一致的外观和结构
度量支撑可以量化每个成员的贡献
交流分析会跟踪整个团队的交流，并分离出模式，应用于需要解决的问题或难题
工件收集 显示出工作产品的依赖性
 
 
6.13 团队决策的复杂原因
 
问题的复杂性
与决策相关的不确定性和风险
工作相关的决策会对另外的项目目标产生意外的影响
对问题的不同看法导致不同的结论
对于GSD团队，协调，合作和沟通方面的挑战对决策具有深远的影响。
 
 
6.14 影响软件开发全球化（GSD）的因素
 
 
 
6.9 极限编程团队的价值
 
交流
简单
反馈
勇气
尊重
 
 
6.10 社交媒体的影响
 
博客- 用来与团队成员和客户分享技术信息
 
微博（如twitter） 允许对关注他们的人员发布实时信息
 
Targeted on-line 论坛 - 允许参与者发布问题或者观点，并且得到答复。
 
社交网络：在以分享技术信息为目的的软件开发人员之间建立起联系。
 
网址收藏夹：允许开发人员追踪和共享网络资源
 
 
6.11 软件工程中云的应用
 
优势：
 
提供获取各种软件工程工作产品的方法
消除对于设备依赖的限制，并且在各处都能运行
提供新的分配方法和软件测试
对于所有团队成员来说，都能获得其中某个成员开发出的软件工程信息
 
缺点：
 
分散的云服务在软件团队的控制范围之外，因此存在可靠性和安全性风险，
随着云提供的服务越来越多，其在协同性上的风险也越来越高。
云服务强调的可用性和性能，常常会与安全性，保密性和可靠性相互冲突。
 
 
6.12 协作工具
 
命名空间 使项目团队可以用加强安全性和保密性的方法存储工作产品
进度表 可以协调项目事件
模板 可以使团队成员在创造工作产品时保持一致的外观和结构
度量支撑可以量化每个成员的贡献
交流分析会跟踪整个团队的交流，并分离出模式，应用于需要解决的问题或难题
工件收集 显示出工作产品的依赖性
 
 
6.13 团队决策的复杂原因
 
问题的复杂性
与决策相关的不确定性和风险
工作相关的决策会对另外的项目目标产生意外的影响
对问题的不同看法导致不同的结论
对于GSD团队，协调，合作和沟通方面的挑战对决策具有深远的影响。
 

 
 
关注、星标公众号，直达精彩内容
 

 
参考：网络资料
 
整理:李肖遥
 
嵌入式大体分为以下四个方向：


 
一、嵌入式硬件开发：熟悉电路等知识，非常熟悉各种常用元器件，掌握模拟电路和数字电路设计的开发能力。熟练掌握嵌入式硬件知识，熟悉硬件开发模式和设计模式，熟悉ARM32位处理器嵌入式硬件平台开发、并具备产品开发经验。精通常用的硬件设计工具：Protel/PADS(PowerPCB)/Cadence/OrCad。一般需要有4~8层高速PCB设计经验。
 
二、嵌入式驱动开发：熟练掌握Linux操作系统、系统结构、计算机组成原理、数据结构相关知识。熟悉嵌入式ARM开发，至少掌握Linux字符驱动程序开发。具有单片机、ARM嵌入式处理器的移植开发能力，理解硬件原理图，能独立完成相关硬件驱动调试，具有扎实的硬件知识，能够根据芯片手册编写软件驱动程序。
 
三、嵌入式系统开发：掌握Linux系统配置，精通处理器体系结构、编程环境、指令集、寻址方式、调试、汇编和混合编程等方面的内容;掌握Linux文件系统制作，熟悉各种文件系统格式(YAFFS2、JAFFS2、RAMDISK等);熟悉嵌入式Linux启动流程，熟悉Linux配置文件的修改;掌握内核裁减、内核移植、交叉编译、内核调试、启动程序Bootloader编写、根文件系统制作和集成部署Linux系统等整个流程;、熟悉搭建Linux软件开发环境(库文件的交叉编译及环境配置等);
 
四、嵌入式软件开发：精通Linux操作系统的概念和安装方法、Linux下的基本命令、管理配置和编辑器，包括VI编辑器，GCC编译器，GDB调试器和 Make 项目管理工具等知识;精通C语言的高级编程知识，包括函数与程序结构、指针、数组、常用算法、库函数的使用等知识、数据结构的基础内容，包括链表、队列等;掌握面向对象编程的基本思想，以及C++语言的基础内容;精通嵌入式Linux下的程序设计，精通嵌入式Linux开发环境，包括系统编程、文件I/O、多进程和多线程、网络编程、GUI图形界面编程、数据库;熟悉常用的图形库的编程，如QT、GTK、miniGUI、fltk、nano-x等。
 
公司的日常活动还是看公司的规模，大一点的一般只是让你负责一个模块，这样你就要精通一点。若是公司比较小的话估计要你什么都做一点。还要了解点硬件的东西。
 
那么看了这么多，嵌入式和纯软最大的区别在于：
 

纯软学习的是一门语言，例如C,C++,java,甚至Python，语言说到底只是一门工具，就像学会英语法语日语一样。
 

但嵌入式学习的是软件+硬件，通俗的讲，它学的是做系统做产品，讲究的是除了具体的语言工具，更多的是如何将一个产品分解为具体可实施的软件和硬件，以及更小的单元。
 
不少人问，将来就业到底是选驱动还是选应用？只能说凭兴趣，并且驱动和应用并不是截然分开的。
 
▍PART  01
 
我们说的驱动，其实并不局限于硬件的操作，还有操作系统的原理、进程的休眠唤醒调度等概念。想写出一个好的应用，想比较好的解决应用碰到的问题，这些知识大家应该都懂。
 
▍PART  02
 
做应用的发展路径个人认为就是业务纯熟。比如在通信行业、IPTV行业、手机行业，行业需求很了解。
 
▍PART  03
 
做驱动，其实不能称为“做驱动”，而是可以称为“做底层系统”，做好了这是通杀各行业。比如一个人工作几年，做过手机、IPTV、会议电视，但是这些产品对他毫无差别，因为他只做底层。当应用出现问题，解决不了时，他就可以从内核角度给他们出主意，提供工具。做底层的发展方向，应该是技术专家。
 
▍PART  04
 
其实，做底层还是做应用，之间并没有一个界线，有底层经验，再去做应用，会感觉很踏实。有了业务经验，再了解一下底层，很快就可以组成一个团队。
 
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧  END  ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧
扫描下方微信，加作者微信进技术交流群，请先自我介绍喔。

推荐阅读：嵌入式编程专辑Linux 学习专辑C/C++编程专辑
Qt进阶学习专辑关注微信公众号『技术让梦想更伟大』，后台回复“m”查看更多内容。
长按前往图中包含的公众号关注