计算机系列之软件工程基础知识

22、软件工程基础知识（占8-10分）

1、信息系统生命周期

◆软件工程基本原理:用分阶段的生命周期计划严格管理、坚持进行阶段评审、实现严格的产品控制采用现代程序设计技术、结果应能清楚的审查、开
发小组的人员应少而精、承认不断改进软件工程实践的必要性。
◆软件工程的基本要素: 方法、工具、过程
◆软件生存周期:可行性分析与项目开发计划、需求分析、概要设计(选择系统解决方案，规划子系统)、详细设计(设计子系统内部具体实现)、编码、测试、维护。

需要掌握每个阶段是干什么的以及它的输出，会考：

◆1.系统规划阶段:任务是对组织的环境、目标及现行系统的状况进行初步调查、初步需求调研、初步设计任务、可行性分析，根据组织目标和发展战略确定信息系统的发展战略，对建设新系统的需求做出分析和预测，同时考虑建设新系统所受的各种约束，研究建设新系统的必要性和可能性。根据需要与可能，给出制建系统的备选方案。

输出:可行性研究报告、系统设计任务书。

◆2.系统分析阶段，又叫逻辑设计阶段:任务是根据系统设计任务书所确定的范围，对现行系统进行详细调查，描述现行系统的业务流程，指出现行系统的局限性和不足之处，确定新系统的基本目标和逻辑功能要求，即提出新系统的逻辑模型。系统分析阶段又称为逻辑设计阶段。这个阶段是整个系统建设的关键阶段，也是信息系统建设与一般工程项目的重要区别所在。

输出:系统说明书、需求说明书。

◆**3.系统设计阶段，又叫物理设计阶段:系统分析阶段的任务是回答系统“做什么”的问题，而系统设计阶段要回答的问题是"怎么做”。**该阶段的任务是根据系统说明书中规定的功能要求，具体设计实现逻辑模型的技术方案，也就是设计新系统的物理模型。这个阶段又称为物理设计阶段，可分为总体设计(概要设计)和详细设计两个子阶段。

输出:系统设计说明书(概要设计、详细设计说明书)。

◆**4.系统实施阶段:是将设计的系统付诸实施的阶段。**这一阶段的任务包括计算机等设备的购置、安装和调试程序的编写和调试、人员培训、数据文件转换、系统调试与转换等。这个阶段的特点是几个互相联系、互相制约的任务同时展开，必须精心安排、合理组织。系统实施是按实施计划分阶段完成的，每个阶段应写出实施进展报告。系统测试之后写出系统测试分析报告。

输出:实施进展报告、系统测试分析报告。

◆**5.系统运行和维护阶段:**系统投入运行后，需要经常进行维护和评价，记录系统运行的情况，根据一定的规则对系统进行必要的修改，评价系统的工作质量和经济效益。

2、能力成熟度模型

能力成熟度模型：CMM

能力成熟度模型集成 CMMI

(2)连续式模型：关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级。

3、软件过程模型

1、瀑布模型：适用于 需求要明确

瀑布模型(SDLC):瀑布模型是一个经典的软件生命周期模型，一般将软件开发分为:可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码(含单元测试)、测试、运行维护等几个阶段。

瀑布模型特点
(1)从上一项开发活动接受该项活动的工作对象作为输入
(2)利用这一输入，实施该项活动应完成的工作内容
(3)给出该项活动的工作成果，作为输出传给下一项开发活动。
(4)对该项活动的实施工作成果进行评审。若其工作成果得到确认，则继续进行下一项开发活动;否则返回前一项，甚至更前项的活动。尽量减少多个阶段间的反复。以相对来说较小的费用来开发软件。

2、螺旋模型：适用于 大型、强调风险，需求不明确，快速原型，不断迭代

◆螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序(瀑布)模型中控制的和系统化的方面结合起来。在螺旋模型中，软件开发是一系列的增量发布。
◆开发过程具有**周期性重复的螺旋线状。**四个象限分别标志每个周期所划分的四阶段:制订计划、风险分析、实施工程和客户评估。螺旋模型强调了风险分析，特别适用于庞大而复杂的、高风险的系统。

螺旋：有不对的可以返回去修改。

3、V 模型：适用于 重视每个阶段的测试，需求明确、需求变更不频繁

◆V模型从整体上看起来，就是一个V字型的结构，由左右两边组成。左边的下画线分别代表了需求分析、概要设计、详细设计、编码。右边的上画线代表了单元测试、集成测试、系统测试与验收测试。V模型的特点如下:
(1)单元测试的主要目的是针对编码过程中可能存在的各种错误;
(2)集成测试的主要目的是针对详细设计中可能存在的问题，
(3)系统测试主要针对概要设计，检查系统作为一个整体是否有效地得到运行;
(4)验收测试通常由业务专家或者用户进行，以确认产品能真正符合用户业务上的需要。
(5)V模型用于需求明确和需求变更不频繁的情形

需求分析对应验收测试：验需

概要设计对应系统测试：系概

详细设计对应集成测试：集详

编码和实现对应单元测试：单编

4、原型化模型：适用于需求不明确

◆原型化模型**第一步就是创建一个快速原型（比如用 PS、PPT、蓝湖、Figma 画一个界面来确认是否满足），**能够满足项目干系人与未来的用户可以与原型进行交互，再通过与相关干系人进行充分的讨论和分析，最终弄清楚当前系统的需求，进行了充分的了解之后，在原型的基础上开发出用户满
意的产品。
◆原型法认为在很难一下子全面准确地提出用户需求的情况下，原型应当具备
的特点如下。
(1)实际可行
(2)具有最终系统的基本特征
(3)构造方便、快速，造价低。原型法的特点在于原型法对用户的需求是动态
响应、逐步纳入的。

5、增量模型：优先核心，分期增量（一期、二期等）

◆增量模型:首先开发核心模块功能，而后与用户确认，之后再开发次核心模
块的功能，即每次开发一部分功能，并与用户需求确认，最终完成项目开发，优先级最高的服务最先交付。
◆特点:但由于并不是从系统整体角度规划各个模块，因此不利于模块划分。
难点在于如何将客户需求划分为多个增量。 与原型不同的是增量型的每一次增量版本都可作为独立可操作的作品，而原型的构造一般是为了演示。

6、喷泉模型：面向对象

◆喷泉模型:是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。使开发过程具有迭代性和无间隙性。

7、基于构件的开发模型CBSD：构件复用、快速（比如可拖拽的低代码平台等、可拖拽的图形等）

◆基于构件的开发模型CBSD:利用预先包装的构件来构造应用系统。构件可以
是组织内部开发的构件，也可以是商品化成品软件构件。
特点是增强了复用性，在系统开发过程中，会构建一个构件库，供其他系统复用，因此可以提高可靠性，节省时间和成本。

8、形式化方法模型：数学

◆形式化方法模型:建立在严格数学基础上的一种软件开发方法，主要活动是
生成计算机软件形式化的数学规格说明。

4、信息系统开发方法

1、结构化方法（生命周期法）：适用于需求明确，中小型项目，适合数据处理领域的项目

结构是指系统内各个组成要素之间的相互联系、相互作用的框架。

结构化方法也称为生命周期法，是一种传统的信息系统开发方法，由**结构化分析(Structured Analysis,SA)（系统分析阶段）、结构化设计(Structured Design,SD)（系统设计阶段）和结构化程序设计(Structured Programming，SP)（系统实施阶段）**三部分有机组合而成，其精髓是自顶向下、逐步求精和模块化设计。

结构化方法的主要特点：

(1)开发目标清晰化。结构化方法的系统开发遵循“用户第一”的原则。
(2)开发工作阶段化。每个阶段工作完成后，要根据阶段工作目标和要求进
行审查，这使各阶段工作有条不紊地进行，便于项目管理与控制。
(3)开发文档规范化。结构化方法每个阶段工作完成后，要按照要求完成相
应的文档，以保证各个工作阶段的衔接与系统维护工作的遍历。
(4)设计方法结构化。在系统分析与设计时，从整体和全局考虑，因
自顶向下地分解;在系统实现时，根据设计的要求，先编写各个具体的功能模块，然后自底向上逐步实现整个系统。

结构化：就要求所有需求都确定好、只能自顶向下（不能回去）。要模块化的设计、阶段化的开发等。

这种生命周期法在早期的软件开发中是可行的，因为早期的软件开发需求简单且明确等。

◆结构化方法的不足和局限
(1)开发周期长:按顺序经历各个阶段，直到实施阶段结束后，用户才能使
用系统。
(2)难以适应需求变化：不适用于需求不明确或经常变更的项目。
(3)**很少考虑数据结构:**结构化方法是一种面向过程，面向数据流的开发方
法，很少考虑数据结构。

◆结构化方法常用工具
结构化方法一般利用图形表达用户需求，常用工具有数据流图、数据字典、结构化语言、判定表以及判定树等。

2、面向对象：适合于大规模、特别复杂的项目

任何现实世界的事物都可以看作一个对象，类是对象的集合体。比如公共交通这个类将汽车、自行车这样的对象集合在公共交通类当中。

面向对象(Object-Oriented，OO)方法认为，客观世界是由各种对象组成的，任何事物都是对象，每一个对象都有自己的运动规律和内部状态，都属于某个对象类，是该对象类的一个元素。复杂的对象可由相对简单的各种对象以某种方式而构成，不同对象的组合及相互作用就构成了系统。

面向对象方法的特点：

(1)使用OO方法构造的系统具有更好的复用性，其关键在于建立一个全面、
合理、统一的模型(用例模型和分析模型)
(2)OO方法也划分阶段，但其中的系统分析、系统设计和系统实现三个阶段
之间已经没有“缝隙”。也就是说，这三个阶段的界限变得不明确，某项工作
既可以在前一个阶段完成，也可以在后一个阶段完成;前一个阶段工作做得不
够细，在后一个阶段可以补充。
(3)面向对象方法可以普遍适用于各类信息系统的开发。

面向对象方法的不足之处

必须依靠一定的面向对象技术支持，在大型项目的开发上具有一定的局限性
不能涉足系统分析以前的开发环节。

当前，一些大型信息系统的开发，通常是将结构化方法和OO方法结合起来。

首先，使用结构化方法进行自顶向下的整体划分;

然后，自底向上地采用OO方法进行开发。

因此，结构化方法和O0方法仍是两种在系统开发领域中相互依存的、不可替代的方法。

3、原型法：适用于需求不明确、分析层面难度大、技术层面难度不大

原型化方法也称为快速原型法，或者简称为原型法。它是一种根据用户初步需求，利用系统开发工具，快速地建立一个系统模型展示给用户，在此基础上与用户交流，最终实现用户需求的信息系统快速开发的方法。

按是否实现功能分类:分为水平原型(行为原型，功能的导航)、垂直原型(结构化原型，实现了部分功能)
按最终结果分类:分为抛弃式原型、演化式原型。

◆原型法的特点
原型法可以使系统开发的周期缩短、成本和风险降低、速度加快，获得较高的综合开发效益。

原型法是以用户为中心来开发系统的，用户参与的程度大大提高，开发的系统符合用户的需求，因而增加了用户的满意度，提高了系统开发的成功率。

由于用户参与了系统开发的全过程，对系统的功能和结构容易理解和接受，有利于系统的移交，有利于系统的运行与维护。

◆原型法的不足之处
开发的环境要求高。管理水平要求高。

◆由以上的分析可以看出，原型法的优点主要在于能更有效地确认用户需求。从直观上来看，原型法适用于那些需求不明确的系统开发。
事实上，对于分析层面难度大、技术层面难度不大的系统，适合于原型法开发。

◆从严格意义上来说，目前的原型法不是一种独立的系统开发方法，而只是一种开发思想，它只支持在系统开发早期阶段快速生成系统的原型，没有规定在原型构建过程中必须使用哪种方法。因此，它不是完整意义上的方法论体系。这就注定了原型法必须与其他信息系统开发方法结合使用。

4、敏捷开发

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，相对于传统软件开发方法的“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

敏捷软件开发宣言:
1.个体和交互胜过过程和工具
2.可以工作的软件胜过面面俱到的文档
3.客户合作胜过合同谈判
4.响应变化胜过遵循计划

1、结对编程

◆结对编程:一个程序员开发，另一个程序在一旁观察审查代码，能够有效的提高代码质量，在开发同时对代码进行初步审查，共同对代码负责。

2、自适应开发：适应性、提供根本基础

◆自适应开发:强调开发方法的适应性(Adaptive)。不像其他方法那样有很多
具体的实践做法，它更侧重为软件的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。

3、水晶方法：不同项目不同策略

◆水晶方法:每一个不同的项目都需要一套不同的策略、约定和方法论。

4、特征驱动开发：模型驱动，中小型软件、需求经常变动

◆特性驱动开发:是一套针对中小型软件开发项目的开发模式。是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目。

5、SCRUM：迭代增量、30天一次冲刺，小型发布

◆并列争球法SCRUM:是一种迭代的增量化过程，把每段时间(30天)一次的
迭代称为一个“冲刺”，并按需求的优先级别来实现产品，多个自组织和自治
的小组并行地递增实现产品。

6、极限编程：测试先行，沟通、简明、反馈、勇气

◆极限编程XP:核心是**沟通、简明、反馈和勇气。因为知道计划永远赶不上变
化，XP无需开发人员在软件开始初期做出很多的文档。XP提倡测试先行，**为了将以后出现bug的几率降到最低。

7、统一过程（RUP）

◆统一过程(RUP)
提供了在开发组织中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品。
◆3个显著特点:用例驱动、以架构为中心、迭代和增量。
◆4个流程:初始阶段、细化阶段、构建阶段和交付阶段。 每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经达到。
◆适用:一个通用过程框架，可以用于种类广泛的软件系统、不同的应用领域
不同的组织类型、不同性能水平和不同的项目规模。

用例驱动：比如做一个图书馆管理系统，学生去借书。借书就是一个用例，即以实际的使用场景的例子来驱动。

5、软件产品线

◆软件产品线是一个产品集合，这些产品**共享一个公共的、可管理的特征集，这个特征集能满足特定领域的特定需求。**软件产品线是一个十分适合专业的开发组织的软件开发方法，能有效地提高软件生产率和质量，缩短开发时间，降低总开发成本。

核心资源:包括所有产品所共用的软件架构，通用的构件、文档等。
产品集合:产品线中的各种产品。

产品线的建立方式：

6、逆向工程

软件复用是将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。

**逆向工程:软件的逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。**逆向工程的四个级别:

**实现级:**包括程序的抽象语法树、符号表、过程的设计表示。
**结构级:**包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构。
**功能级:**包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型。
**领域级:**包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息。例如E-R模型。

其中，领域级抽象级别最高，完备性最低；实现级抽象级别最低，完备性最高。

◆与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。
(1)重构是指在同一抽象级别上转换系统描述形式。，即用其他代码、方式再实现一遍。
(2)设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。
(3)再工程是指**在逆向工程所获得信息的基础上，修改或重构已有的系统，产生系统的一个新版本。**再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。它不仅能从已存在的程序中重新获得设计信息，而且还能使用这些信息来重构现有系统，以改进它的综合质量。在利用再工程重构现有系统的同时，一般会增加新的需求，包括增加新的功能和改善系统的性能。

(4)正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。

软件系统工具通常可以按软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。

软件开发工具:需求分析工具、设计工具、编码与排错工具。

软件维护工具:版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。

软件管理和软件支持工具:项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。

7、软件开发周期

1、软件需求

软件需求:是指用户对系统在功能、行为、性能、设计约束等方面的期望。
是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

分为需求开发和需求管理两大过程，如下所示:

软件需求分为三大类（重要）：

◆业务需求:反映企业或客户对系统高层次的目标要求，**通常来自项目投资人
客户、市场营销部门或产品策划部门。**通过业务需求可以确定项目视图和范围。（不懂开发的人，提出的业务需求，比如提出要手机上可以使用等）

◆用户需求:描述的是用户的具体目标，或用户要求系统必须能完成的任务。
即描述了**用户能使用系统来做什么。**通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。

◆系统需求:从系统的角度来说明软件的需求，包括功能需求、非功能需求和
设计约束等。

1)功能需求:也称为行为需求，规定了**开发人员必须在系统中实现的软件功能，**用户利用这些功能来完成任务，满足业务需要。

2)非功能需求:指系统必须具备的属性或品质，又可以细分为软件质量属性
(如可维护性、可靠性、效率等)和其他非功能需求。

3)设计约束:也称为限制条件或补充规约，通常是对系统的一些约束说明，例
如必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。

质量功能部署（QFD）是一种将用户要求转换成软件需求的技术。QFD将软件需求分为三类：

（1）常规需求：用户认为系统应该做到的功能或性能，实现越多用户越满意。

（2）期望需求：用户想当然认为系统应该具备的功能或性能，但很难正确描述出来或没有写在需求说明书里、合同里的自己想要得到的这些功能或性能需求，比如它可能是常规性、常识性的东西，比如系统里要有复制粘贴功能等。比如它也可能是很高级、很难描述，但想要有的东西。如果期望需求没有得到实现，会让用户感到不满意。

（3）意外需求。意外需求也称之为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不识实现也不影响其购买的决策。

答案：

1、B、用户需求（非常具体、细节，第一句和第三句是对应的。）

2、C、功能需求

3、A、业务需求（相对抽象，只说了能纠正，但没说怎么做）

2、需求获取

需求获取：是一个确定和理解不同的项目干系人的需求和约束的过程。

常见的需求获取法：

用户访谈：良好的灵活性及较宽广的范围，但获取需求时信息量大、记录困难等。

问卷调查：

采样：基于数理统计原理。

情节串联板：通过一系列图片讲故事。

联合需求计划：通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。

需求记录技术：任务卡片、场景说明、用户故事等。

3、需求分析：建立了系统的逻辑模型

◆需求分析:一个好的需求应该具有无二义性、完整性、一致性、可测试性
确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。

需求分析的任务

(1)绘制系统上下文范围关系图：即数据流图
(2)创建用户界面原型
(3)分析需求的可行性
(4)确定需求的优先级
(5)为需求建立模型
(6)创建数据字典
(7)使用QFD(质量功能部署)

1、结构化的需求分析

结构化特点：自顶向下，逐步分解，面向数据。

三大模型：功能模型（数据流图）、行为模型（状态转换图）、数据模型（E-R图）以及数据字典。

2、数据流图

◆数据流图描述数据在系统中如何被传送或变换，以及如何对数据流进行变换的功能或子功能，用于对功能建模，数据流图相关概念如图:

◆数据流图是可以分层的，从顶层(即上下文无关数据流)到0层、1层等，顶
层数据流图只含有一个加工处理表示整个管理信息系统，描述了系统的输入和输出，以及和外部实体的数据交互。数据流图示例如下:

4、需求定义：定义软件需求规格说明书

◆需求定义(软件需求规格说明书SRS):是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之
成为**整个开发工作的基础。**SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。

◆需求定义方法
(1)严格定义也称为预先定义，需求的严格定义建立在以下的基本假设之上:
所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采用图形(或文字)可以充分体现最终系统。

(2)原型方法，迭代的循环型开发方式，需要注意的问题:并非所有的需求都能在系统开发前被准确地说明。项目干系人之间通常都存在交流上的困难，原型提供了克该服困难的一个手段。特点:需要实际的、可供用户参与的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定就应遵从严格的方法。

5、需求验证

◆需求验证:也称为需求确认，目的是与用户一起确认需求无误，对需求规格
说明书SAS进行评审和测试，包括两个步骤:
需求评审:正式评审和非正式评审。
需求测试:设计概念测试用例。

◆需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线，不可以再随意更新，如果需要更改必须走需求变更流程。

6、需求管理

◆定义需求基线:通过了评审的需求说明书就是需求基线，下次如果需要变更
需求，就需要按照流程来一步步进行。需求的流程及状态如下图所示:

需求变更和风险：
主要关心需求变更过程中的需求风险管理，带有风险的做法有:无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算。

变更产生的原因:外部环境的变化、需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化。

变更控制委员会CCB:也称为配置控制委员会，其任务是对建议的配置项变更做出评价、审批，以及监督已经批准变更的实施。

需求跟踪：

双向跟踪，两个层次，如下图所示：

◆正向跟踪表示用户原始需求是否都实现了，反向跟踪表示软件实现的是否都是用户要求的，不多不少，可以用原始需求和用例表格(需求跟踪矩阵)来表示：

◆若原始需求和用例有对应，则在对应栏打对号，若某行都没有对号，表明原始需求未实现，正向跟踪发现问题;若某列都没有对号，表明有多余功能用例，软件实现了多余功能，反向跟踪发现问题。

A: 包含6个关键过程域

B：属于需求属性

C: 顺序不对，应该是先问题分析和变更描述，然后变更分析和成本计算，然后是变更实现。（可以少步骤，但步骤顺序不能改变，否则就是错误的）

D：正确

答案为：D。

2、系统设计：实现物理模型，该怎么做。

1、处理流程设计（了解即可）

◆业务流程建模：

标杆瞄准:以行业领先的标杆企业为目标，结合本企业情况分析建模

IDEF(一系列建模、分析和仿真方法的统称)

DEMO(组织动态本质建模法)

Petri网

业务流程建模语言:BPEL、BPML、BPMN、XPDL。

基于服务的BPM:基于Web服务的思想对业务流程进行建模。

比如：

先浏览店铺，然后立即购买，然后提交订单，然后支付，然后等待发货，然后确认收货，然后评价。

这一些列就是一个线上购物的业务流程，这个业务流程是由小的活动或流程构成的。

对以上业务流程的分析、建模、设计的过程，就是业务流程建模。

2、流程表示工具(考点)

程序流程图(Program Flow Diagram，PFD)用一些图框表示各种操作，它独立于任何一种程序设计语言，比较直观、清晰，易于学习掌握。任何复杂的程序流程图都应该由顺序、选择和循环结构组合或嵌套而成。

IPO图也是流程描述工具，用来描述构成软件系统的每个模块的输入、输出和数据加工。

N-S图,又叫盒图容易表示嵌套和层次关系，并具有强烈的结构化特征。但是当问题很复杂时，N-S图可能很大，因此不适合于复杂程序的设计。

问题分析图(PAD)是一种支持结构化程序设计的图形工具。PAD具有清晰的逻
辑结构、标准化的图形等优点，更重要的是，它引导设计人员使用结构化程序
设计方法，从而提高程序的质量。

◆业务流程重组BPR
BPR是对企业的业务流程进行根本性的再思考和彻底性的再设计，从而获得可以
用诸如成本、质量、服务和速度等方面的业绩来衡量的显著性的成就。BPR设计
原则、系统规划和步骤如下图所示:

◆业务流程管理BPM
BPM是一种以规范化的构造端到端的卓越业务流程为中心，以持续的提高组织
业务绩效为目的的系统化方法。
BPM与BPR管理思想最根本的不同就在于流程管理并不要求对所有的流程进行再造。构造卓越的业务流程并不是流程再造，而是根据现有流程的具体情况，对流程进行规范化的设计。

流程管理包含三个层面:规范流程、优化流程和再造流程

IPO：流程

N-S：盒图、嵌套和层次，不适合复杂

PAD:结构化程序设计

所以 答案为 B：任何复杂的程序流程图都应该由顺序、选择、循环结构构成

BPR 是对业务流程的根本性改造；BPR 过程以流程为中心。

所以答案为：A、A

BPR 以流程为中心，以人为本，以客户为导向。

3、系统设计

◆系统设计主要目的:为系统制定蓝图，在各种技术和实施方法中权衡利弊精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方法。
◆系统设计方法: 结构化设计方法，面向对象设计方法。
◆系统设计的主要内容: 概要设计、详细设计
◆概要设计基本任务:又称为**系统总体结构设计，**是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。
◆详细设计的基本任务:模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计(代码、输入/输出格式、用户界面)、编写详细设计说明书、评审。

概要设计：整个系统划分的模块及模块间的关系。

详细设计：模块内的详细算法、数据结构、数据库的物理设计、详细设计说明书等。

系统设计基本原理：
抽象化;
自顶而下，逐步求精;
信息隐蔽;
模块独立(高内聚，低耦合)。

系统设计原则：
保持模块的大小适中;
尽可能减少调用的深度;
多扇入，少扇出;
单入口，单出口;
模块的作用域应该在模块之内;
功能应该是可预测的。

原则是：多扇入，少扇出。

扇出就是调用别人的数量；扇入就是别人调用你，扇入高，表示别人调用你调用的越多，表示你的价值越大，表示你的复用诚笃越高。

所以答案是 D。

扇出过大，就不应该再分解了，而是应该合并。过小是合理的，是我们追求的。

4、人机界面设计

人机界面设计的三大黄金原则：

1、置于用户控制之下：

• 以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
• 提供灵活的交互
• 允许用户交互可以被中断和撇消
• 当技能级别增加时可以使交互流水化并允许定制交互
• 使用户隔离内部技术细节
• 设计应允许用户和出现在屏幕上的对象直接交互

2、减少用户的记忆负担：

• 保持界面的一致性
• 减少对短期记忆的要求
• 建立有意义的缺省
• 定义直觉性的捷径
• 界面的视觉布局应该基于真实世界的隐喻
• 以不断进展的方式揭示信息

3、保持界面的一致性：

• 允许用户将当前任务放入有意义的语境
• 在应用系列内保持一致性
• 如过去的交互模型已建立起了用户期望，除非有迫不得已的理由，否则不要改变它

3、系统实施

1、测试

1、测试原则和方法

◆系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未
发现的错误的测试。

测试原则:
◆应尽早并不断的进行测试;
◆测试工作应该避免由原开发软件的人或小组承担;
◆在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期的
输出结果;
◆既包含有效、合理的测试用例，也包含不合理、失效的用例;
◆检验程序是否做了该做的事，且是否做了不该做的事;
◆严格按照测试计划进行;
◆妥善保存测试计划和测试用例;
◆测试用例可以重复使用或追加测试。

◆软件测试方法可分为静态测试和动态测试。
静态测试:指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测，包括对文档的静态测试和对代码的静态测试对文档的静态测试主要以检查单的形式进行，而对代码的静态测试，包括桌前检查、代码审查、代码走查的方式。使用这种方法能够有效地发现30%-70%的逻辑设计和编码错误。

代码审查和代码走查的本质都是对代码逻辑的检查。

代码审查：由技术人员、技术专家一起拉个会进行对你的代码的审查。

代码走查：让程序员基于测试用例 模拟计算机执行你的代码，比如 a = 0;经过 a = a + 10；则 if a = 10 就会走 是的分支，否则就走不是的分支等。程序员根据这个实例进行走查，看看实际上会走到哪里去。

◆动态测试:指在计算机上实际运行程序进行软件测试，一般采用白盒测试和
黑盒测试方法。
黑盒测试法:功能性测试，不了解软件代码结构，根据功能设计用例，测试软
件功能。
白盒测试法:结构性测试，明确代码流程，根据代码逻辑设计用例，进行用例
覆盖。

2、测试阶段

(1)单元测试:也称为模块测试，测试的对象是可独立编译或汇编的程序模块、
软件构件或OO软件中的类(统称为模块)，测试依据是软件详细设计说明书。

(2)集成测试:目的是检查模块之间，以及模块和已集成的软件之间的接口关
系，并验证已集成的软件是否符合设计要求。测试依据是软件概要设计文档。

(3)确认测试:主要用于**验证软件的功能、性能和其他特性是否与用户需求一致。**根据用户的参与程度，通常包括以下类型:

内部确认测试:主要由软件开发组织内部按照SRS进行测试。

Alpha测试:用户在开发环境下进行测试。

Beta测试 :用户在实际使用环境下进行测试，通过该测试后，产品才能交付用户。

验收测试:**针对SRS，在交付前以用户为主进行的测试。**其测试对象为完整的、
集成的计算机系统。验收测试的目的是，在真实的用户工作环境下，检验软件系
统是否满足开发技术合同或SRS。验收测试的结论是用户确定是否接收该软件的
主要依据。除应满足一般测试的准入条件外，在进行验收测试之前，应确认被测
软件系统已通过系统测试。

单元测试就是针对单个的模块进行测试，依据是软件详细设计说明书。

集成测试就是针对模块间进行测试，依据是软件概要设计文档。

确认测试就是针对整个系统的功能、性能等，依据是需求文档。

(4)系统测试：测试对象是完整的、集成的计算机系统；测试的目的是在真实系统工作环境下，验证完成的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。测试依据是用户需求或开发合同。主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试安装与反安装测试等，其中，最重要的工作是进行功能测试与性能测试。功能测试主要采用黑盒测试方法;性能测试主要指标有响应时间、吞吐量、并发用户数和资源利用率等。
(5)配置项测试:测试对象是软件配置项，测试目的是检验软件配置项与SRS的一致性。测试的依据是SRS。在此之间，应确认被测软件配置项已通过单元测试和集成测试。
(6)回归测试:测试目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。

测试的顺序为：单元测试->集成测试->系统测试->确认测试。

测试策略

◆自底向上:从最底层模块开始测试，需要编写驱动程序，而后开始逐一合并模块，最终完成整个系统的测试。优点是较早的验证了底层模块。
◆自顶向下:先测试整个系统，需要编写桩程序，而后逐步向下直至最后测试最底层模块。优点是较早的验证了系统的主要控制和判断点。（比如对接了第三方系统，不同的子系统需要进行联调，先对接第三方系统的接口，先调通，然后再测试自己系统内部的功能模块。）
◆三明治:既有自底向上也有自顶向下的测试方法，二者都包括。兼有二者的优点，缺点是测试工作量大。

3、测试用例的设计

◆黑盒测试用例:将程序看做一个黑盒子，只知道输入输出，不知道内部代码由此设计出测试用例，分为下面几类:

​ ◆等价类划分:把所有的数据按照某种特性进行归类，而后在每类的数据里选取一个即可。等价类测试用例的设计原则:设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类,，重复这一步，直到所有的有效等价类都被覆盖为止;设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
​ ◆边界值划分:将每类的边界值作为测试用例，边界值一般为范围的两端值以及在此范围之外的与此范围间隔最小的两个值，如年龄范围为0-150，边界值头0,150，-1,151四个。
​ ◆错误推测:没有固定的方法，凭经验而言，来推测有可能产生问题的地方作为测试用例进行测试。
​ ◆因果图:由一个结果来反推原因的方法，具体结果具体分析，没有固定方法

等价类：比如 >90 的为 优；80-90的为良；60-80的为及格；<60 为 不及格。这就是四个等价类。测试时，只需要设计一个类中的一个数值是否通过测试、可以得到正确结果就可以了。比如 >90的，找个95去验证测试。而不是把>90的数字都去验证、测试下。

有效等价类：正确的等价类（输入）。比如上面的分数中，0-100的数值都可以看做是有效等价类。所以有效等价类要尽可能多的覆盖：比如设计一个输入为95的、82的、63的、40的输入，从而可以覆盖到四个等价类（>90、80-90、60-80、<60的）

无效等价类：错误的等价类（输入）。比如上面的分数中，输入-1、101等。仅覆盖一个尚未被覆盖的：比如一个研究生的录取条件为：本科来自211且考研分数大于300，假如这里输入了一个测试：（二本，267），首先二本不满足来自211,267不满足大于300，所以这个测试的输入既不满足学校的要求、也不满足分数的要求，一个都不满足，这就是一个错误的测试用例、错误的输入。因为它覆盖了两个无效等价类，这个时候就不知道他到底是本科学校的问题还是因为分数的问题。而正确的无效等价类应该只覆盖一个：比如 （二本，350），这样就能知道他是因为学校的原因没有通过的，可以找到不通过的唯一原因。

盒测试用例:知道程序的代码逻辑，按照程序的代码语句，来设计覆盖代码分#支的测试用例，覆盖级别从低至高分为下面几种:

(1)语句覆盖SC:逻辑代码中的所有语句都要被执行一遍，覆盖层级最低，因为执行了所有的语句，不代表执行了所有的条件判断。

只要每个语句都执行过一次即可。

(2)判定覆盖DC:逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次。

通过若干个测试，使得最终只要每个判断语句的真、假都执行过一次即可

（3）条件覆盖CC：针对每一个判断条件内的每一个独立条件都要执行一遍真和假。

通过若干个测试，使得最终要每个判断语句中的每个判断条件的真和假都覆盖了。

比如 a 的 (y > 1) && (z == 0) 这个判断语句包含了两个判断条件：(y > 1) 和 (z == 0)。

第一个用例：X = 1，Y = 2，Z = 0,

满足了 y > 1 （真）、z == 0（真）

第二个用例：X = 2，Y = 1，Z = 1,

满足了 y > 1 (假)，z == 0 (假)

同理 也满足了 b 的每个判断条件。

使得上面判断语句中的每个判断条件都执行过 真 和 假。

（4）条件判断组合覆盖CDC：同时满足判定覆盖和条件覆盖。

判定覆盖：真假分支都执行过

条件覆盖：每个条件的真假都执行过

上述 条件判定组合覆盖的测试用例中：

sacbed 使得 条件 a、条件b的 真 都走过了

sabd 使得 条件 a、条件 b 的假 都走过了

这样条件 a 的真和假、b 的真和假都走过了，就满足了判定覆盖。

而 X = 4 和 X = 1 使得 b 中的条件 x > 1 （4 > 1 为真、1 > 1 为假）的真、假都走走过了

同理… 因此满足了条件覆盖。

同时满足了判定覆盖、条件覆盖，所以也就是满足了条件判定组合覆盖。

（5）路径覆盖：逻辑代码中的所有可行路径都覆盖了，覆盖层级最高。

所有可行路径。路径覆盖法往往能比语句覆盖法发现更多的错误。

语句：只要所有语句都走一遍即可

判定：只要判断语句的真、假都走一遍即可

条件：只要判断语句中的每个判断条件的真、假都走一遍即可

路径：所有路径

解题：

首先①(x=0,y=3)，满足了 x = 0 && y > 2，使得x = 0、y > 2 都为真；

​ 第一个判断语句就直接走真，不走向右侧第二个条件语句了。

其次②(x=1,y=2)，满足了 x = 0 && y > 2，使得 x = 0 为 假，y > 2 为假

​ 同时 x < 1 || y = 1 中，使得 x < 1 为 假，y = 1 也为假

所以这里就不满足条件覆盖以及判定覆盖了。

① 走的路径为：第一个判断语句、语句A

②走的路径为：第一个判断语句、第二个判断语句、语句B

所以这里的所有语句都走了一遍，但并不是所有路径都走了。

所以35的答案为 A

③(x=-1,y=2) 走的路径为：第一个判断语句、第二个判断语句、结束

因此 ①②③走完了所有路径，因此满足路径覆盖。

所以36答案为 D。

4、调试

◆测试是发现错误，调试是找出错误的代码和原因。
◆调试需要确定错误的准确位置;确定问题的原因并设法改正;改正后要进行回归测试。
◆调试的方法有: 蛮力法、回溯法(从出错的地方开始，向回找)、原因排除法(找出所有可能的原因，逐一进行排除，具体包括演绎法、归纳法、二分法)

5、软件度量

◆ 软件的两种属性:外部属性指面向管理者和用户的属性，可直接测量，一般为性能指标。内部属性指软件产品本身的的属性，如可靠性等，只能间接测量。
◆McCabe度量法:又称为环路复杂度，假设有向图中有向边数为m，节点数为n，则此有向图的环路复杂度为m-n+2。 边数 - 顶点数 + 2
注意m和n代表的含义不能混淆，可以用一个最简单的环路来做特殊值记忆此公式，另外，针对一个程序流程图，每一个分支边(连线)就是一条有向边，每一条语句(语句框)就是一个顶点。

4、运行和维护

1、系统转换

◆遗留系统是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统，它通常具有以下特点:

(1)系统虽然完成企业中许多重要的业务管理工作，但仍然不能完全满足要求。一般实现业务处理电子化及部分企业管理功能，很少涉及经营决策。
(2)系统在性能上已经落后，采用的技术已经过时。例如多采用主机/终端形式或小型机系统，软件使用汇编语言或第三代程序设计语言的早期版本开发，使用文件系统而不是数据库。
(3)通常是大型的软件系统，已经融入企业的业务运作和决策管理机制之中，维护工作十分困难。
(4)没有使用现代信息系统建设方法进行管理和开发，现(4)在基本上已经没有文档，很难理解。

◆系统转换是指新系统开发完毕，投入运行，取代现有系统的过程，需要考虑多方面的问题，以实现与老系统的交接，有以下三种转换计划:

◆直接转换:现有系统被新系统直接取代了，风险很大，适用于新系统不复杂或者现有系统已经不能使用的情况。优点是节省成本。

◆并行转换:新系统和老系统并行工作一段时间，新系统经过试运行后再取代若新系统在试运行过程中有问题，也不影响现有系统的运行，风险极小，在试运行过程中还可以比较新老系统的性能，适用于大型系统。缺点是耗费人力和时间资源，难以控制两个系统间的数据转换。

◆分段转换:分期分批逐步转换，是直接和并行转换的集合，将大型系统分为多个子系统，依次试运行每个子系统，成熟一个子系统，就转换一个子系统。同样适用于大型项目，只是更耗时，而且现有系统和新系统间混合使用，需要协调好接口等问题。
◆数据转换与迁移:将数据从旧数据库迁移到新数据库中。有三种方法:系统切换前通过工具迁移、系统切换前采用手工录入、系统切换后通过新系统生成。

2、系统维护

◆系统的可维护性可以定义为**维护人员理解、改正、改动和改进这个软件的难易程度，**其评价指标如下:
(1)**易分析性。**软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。

(2)**易改变性。**软件产品使指定的修改可以被实现的能力，实现包括编码、设计和文档的更改。

(3)**稳定性。**软件产品避免由于软件修改而造成意外结果的能力。

(4)**易测试性。**软件产品使已修改软件能被确认的能力。

(5)**维护性的依从性。**软件产品遵循与维护性相关的标准或约定的能力。

◆系统维护包括硬件维护、软件维护和数据维护，其中软件维护类型如下：

**正确性维护:**发现了bug而进行的修改。

**适应性维护：**由于外部环境发生了改变，被动进行的对软件的修改和升级。

**完善性维护:**基于用户主动对软件提出更多的需求，修改软件，增加更多的功能，使其比之前的软件功能、性能更高，更加完善。

**预防性维护:**对未来可能发生的bug进行预防性的修改。

3、系统评价

系统评价分类：立项评价、中期评价、结项评价。

8、项目管理

1、范围管理

范围管理确定在项目内包括什么工作和不包括什么工作。

需求是：你要什么；

范围是：需求的边界；

◆产品范围和项目范围

产品范围是指产品或者服务所应该包含的功能。产品范围是否完成，要根据产品是否满足了产品描述来判断。产品范围是项目范围的基础，产品范围的定义是产品要求的描述。

项目范围是指为了能够交付产品，项目所必须做的工作。项目范围的定义是产生项目管理计划的基础。判断项目范围是否完成，要以范围基准来衡量。项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典。

产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受到影响的是项目的范围。

◆WBS 将项目整体或者主要的可交付成果分解成容易管理、方便控制的若干个子项目或者工作包，子项目需要继续分解为工作包，持续这个过程，**直到整个项目部分解为可管理的工作包，这些工作包的总和是项目的所有工作范围。**最普通的WBS 如下表所示:

2、进度管理（会考）

◆进度管理就是采用科学的方法，确定进度目标，编制进度计划和资源供应计划，进行进度控制，在与质量、成本目标协调的基础上，实现工期目标。

◆具体来说，包括以下过程：

(1)活动定义:确定完成项目各项可交付成果而需要开展的具体活动。

(2)活动排序:识别和记录各项活动之间的先后关系和逻辑关系。

(3)活动资源估算:估算完成各项活动所需要的资源类型和效益。

(4)活动历时估算:"估算完成各项活动所需要的具体时间。

(5)进度计划编制:分析活动顺序、活动持续时间、资源要求和进度制约因素，制订项目进度计划。

(6)进度控制:根据进度计划开展项目活动，如果发现偏差，则分析原因或进行调整。

活动资源估算的方法主要有：专家判断法、替换方案的确定、公开的估算数据、估算软件（依靠软件的强大功能，可以定义资源可用性、费率等）、自下而上的估算（把复杂的活动分解为更小的工作）。

软件规模估算模型：（会考）

◆COCOMO模型:常见的软件规模估算方法。常用的代码行分析方法作为其中一种度量估计单位，以代码行数估算出每个程序员工作量，累加得软件成本。
模型按其详细程度可以分为三级:

(1)基本COCOMO模型是一个静态单变量模型，它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量。

(2)中间COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件人员、项目等方面的影响因素调整工作量的估算。

(3)详细COCOMO模型包括中间COCOMO模型的所有特性，将软件系统模型分为系统、子系统和模块3个层次，更进一步考虑了软件工程中每一步骤(如分析、设计)的影响。

基本COCOMO模型：只考虑代码行

中间COCOMO模型：考虑代码行之外，还考虑软硬件、人员等

详细COCOMO模型：考虑代码行之外，还考虑软硬件、人员等，以及软件工程的每一步：系统分析、系统设计等。

◆COCOMOⅡ模型:COCOMO的升级，也是以软件规模作为成本的主要因素考虑多个成本驱动因子。该方法包括三个阶段性模型，即应用组装模型、早期设计阶段模型和体系结构阶段模型。包含三种不同规模估算选择**:对象点、功能点和代码行。**

应用组装模型：需求分析阶段，以 对象点 为估算

早期设计阶段模型：设计阶段，以 功能点 为估算

体系结构阶段模型：开发阶段，以 代码行 为估算

◆进度安排的常用图形描述方法有Gantt 图(甘特图)和项目计划评审技术(Program Evaluation& Review Technique,PERT)图。

甘特图：反应了任务的并行关系

PERT 图： 反应了任务的依赖关系

◆工具与技术–关键路径法（重点，每年必考）

关键路径:是项目的**最短工期，但却是从开始到结束时间最长的路径。**进度网络图中可能有多条关键路径，因为活动会变化，因此关键路径也在不断变化中。

关键活动:关键路径上的活动，最早开始时间=最晚开始时间。

通常，每个节点的活动会有如下几个时间:
(1)**最早开始时间(ES)，**某项活动能够开始的最早时间。

(2)**最早结束时间(EF)，**某项活动能够完成的最早时间。EF=ES+工期最早。

(3)**最迟结束时间(EF)，**为了使项目按时完成，某项活动必须完成的最迟时间。
(4)**最迟开始时间(LS)。**为了使项目按时完成，某项活动必须开始的最迟时(4)间。LS=LF-工期。

这几个时间通常作为每个节点的组成部分，如图所示:

顺推:最早开始ES=所有前置活动最早完成EF的最大值;最早完成EF=最早开始ES+持续时间。

逆推:最晚完成LF=所有后续活动最晚开始LS的最小值;最晚开始LS=最晚完成LF-持续事件。

总浮动时间=最迟开始LS-最早开始ES 或 最迟完成LF-最早完成EF 或 关键路径-非关键路径时长

关键路径就是最长的那个路径。

历时总时长就是关键路径，关键路径就是最长的那一条。

上图最长的就是 a->d->f->j->k 共计 3 + 4 + 3 + 5 + 1 = 16 是最长的，所以答案是 C。

第二题，此时 d-i 为 8，a-c为6，f-h为2，则此时最长的为：a->d->i->k，还是16.

根据上表，可以画出如下图：

所以关键路径（耗时最长）的为：17天，即：A->D->F->G：2+6+6+3 = 17

如果要有活动 c，则 涉及c 的路径（这里只有一个，也就是 A->C->E->G）的总时长不大于17，即：2 + x + 4 + 3 <=17 => 所以 x = 8，x 本来工期为 5，所以浮动时间为 8 - 5 = 3 天。

所以答案分别为：D、D

​

3、成本管理

项目成本管理包括 成本估算、成本预算、成本控制三个过程。

估算：是估计多少钱，比如100万。

预算：拿到了100万，怎么分配、怎么花。

控制：节约。

◆成本的类型（考点）
(1)可变成本:随着生产量、工作量或时间而变的成本为可变成本。可变成本又称变动成本。（比如材料，生产一个手机要一个屏幕的材料，2个手机就要2个屏幕的材料。）

(2)固定成本:不随生产量、工作量或时间的变化而变化的非重复成本为固定成本。（比如厂房）

(3)直接成本:直接可以归属于项目工作的成本为直接成本。如项目团队差旅费、工资、项目使用的物料及设备使用费等。（项目团队的人独有的成本：差旅费、员工个人的工资、设备使用费）

(4)间接成本:来自一般管理费用科目或几个项目共同担负的项目成本所分摊给本项目的费用，就形成了项目的间接成本，如税金、额外福利和保卫费用等。（需要分摊的：税金、额外福利、管理层的工资）

(5)机会成本:是利用一定的时间或资源生产一种商品时，而失去的利用这些资源生产其他最佳替代品的机会就是机会成本,泛指一切在做出选择后其中一个最大的损失。（比如农民只有一块地，可以用来养猪或养鸡或养羊，养猪可以赚10万，养鸡可以赚8万，养羊可以赚12万，农民选择了养猪，而放弃了养鸡或养羊，这里损失的最大利益是12万（8万的鸡、12万的羊中最大的就是12万），所以这里机会成本就是12万，养猪的获得成本就是10万，一般来说都要获得成本大于机会成本，所以最合适的是这里选择养羊获得12万，机会成本损失10万（养猪和养鸡中最大的为10万））

(6)沉没成本:是指由于过去的决策已经发生了的，而不能由现在或将来的任何决策改变的成本。沉没成本是一种历史成本，对现有决策而言是不可控成本，会很大程度上影响人们的行为方式与决策，在投资决策时应排除沉没成本的干扰。（沉没成本是要排除的成本，比如电影票已经买了、钱已经花了，如果电影确实非常烂，不是去选择不管烂不烂都去把这个电影看了（因为钱已经花了），而是花了钱之后明确知道电影很烂，就直接放弃去看。）

学习曲线:重复生成产品时，**产品的单位成本会随着产量的扩大呈现规律性递减。**估算成本时，也要考虑此因素。（比如刚开始学习、做这个工作要10天，后续再做类似的工作就只需要3天了，随着不断地熟悉，单位成本就降低了）

4、软件配置管理

◆以下内容都可以作为配置项进行管理:外部交付的软件产品和数据、指定的内部软件工作产品和数据、指定的用于创建或支持软件产品的支持工具、供方/供应商提供的软件和客户提供的设备/软件。
◆典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例,运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。
◆每个配置项的主要属性有:名称、标识符、文件状态、版本、作者、日期等
◆配置项可以分为基线配置项和非基线配置项两类，例如，基线配置项可能包括所有的设计文档和源程序等;非基线配置项可能包括项目的各类计划和报告等。
◆所有配置项的操作权限应由CMO(配置管理员)严格管理，基本原则是:基线配置项向开发人员开放读取的权限;非基线配置项向PM、CCB及相关人员开放。

◆配置项的状态可分为**“草稿”“正式”和“修改”三种。配置项刚建立时其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。**如图所示：

◆配置项版本号：0 开头就是草稿，X.Y 为正式状态，X.YZ 为修改状态。
(1)处于**“草稿"状态的配置项的版本号格式为0.YZ**,YZ的数字范围为01~99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。

(2)处于**“正式"状态的配置项的版本号格式为X.Y**，X为主版本号，取值范围为1一9。Y为次版本号，取值范围为0~9。配置项第一次成为“正式”文件时，版本号为1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0,1.1…。当附件的变动积累到一定程度时，配置项的值可适量增加，Y值增加一定程度时,X值将适量增加。当配置项升级幅度比较大时，才允许直接增大x值。

(3)处于**“修改"状态的配置项的版本号格式为X.YZ**。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0,增加X.Y值。参见上述规则(2)。

◆配置项版本管理:在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

◆基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线(Release)，内部开发使用的基线一般称为构造基线(Build)

◆一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。

◆产品的一个测试版本(可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等)是基线的一个例子。

◆建立基线还可以有如下好处:
(1)基线为开发工作提供了一个定点和快照。
(2)新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目(在主要分支上)所进行的变更进行隔离。

(3)当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法

(4)可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。

◆配置库存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具。主要作用:

(1)记录与配置相关的所有信息，其中存放受控的软件配置项是很重要的内容

(2)利用库中的信息评价变更的后果，这对变更控制有着重要的意义。

(3)从库中可提取各种配置管理过程的管理信息

◆使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。

不属于产品组成部分工作成果的配置项：工作计划，而需求文档（需求阶段）、设计文档（设计阶段）、源代码（实施阶段）的产出物是产品组成部分工作成果的配置项。

5、质量管理

◆质量是**软件产品特性的综合，表示软件产品满足明确(基本需求)或隐含(期望需求)要求的能力。**质量管理是指确定质量方针、目标和职责，并通过质量体系中的质量计划、质量控制、质量保证和质量改进来使其实现的所有管理职能的全部活动;
◆主要包括以下过程:

(1)质量规划:识别项目及其产品的质量要求和标准，并书面描述项目将如何达到这些要求和标准的过程。

(2)质量保证:一般是每隔一定时间(例如，每个阶段末)进行的，主要通过系统的质量审计((软件评审)和过程分析来保证项目的质量。

(3)质量控制:实时监控项目的具体结果，以判断它们是否符合相关质量标准，制订有效方案，以消除产生质量问题的原因。

质量模型、质量特性：（常考）

功能性：一组功能及其指定的性质有关的一组属性，包括安全性、准确性、适合性等

可靠性：在规定的一段时间和条件下，软件维持其性能水平有关的一组软件特性，包括容错性、易恢复、成熟等

可用性：于使用的难易程度及规定或隐含用户对使用方式所做的评价有关的软件属性，包括易理解、易操作等

效率（性能）：与在规定条件下，软件的性能水平和所用资源之间的关系有关的一组软件属性，包括几秒内打开、吞吐量等

可维护性：与进行指定的修改所需的努力有关的一组软件属性，包括易分析、稳定、可修改、可测试。

可移植性：与软件可从某一环境转移到另一环境的能力有关的一组软件属性。包括适应性、易安装、一致性、可替换等。

质量审计（软件评审）、过程分析是软件质量保证的主要活动。

6、风险管理

◆风险管理计划编制:如何安排与实施项目的风险管理，制定下列各步的计划

◆风险识别:识别出项目中已知和可预测的风险，确定风险的来源、产生的条件、描述风险的特征以及哪些项目可以产生风险，形成一个风险列表。

◆风险定性分析:对已经识别的风险进行排序，确定风险可能性与影响、确定风险优先级、确定风险类型。

◆风险定量分析:进一步了解风险发生的可能性具体由多大，后果具体由多严重。包括灵敏度分析、期望货币价值分析、决策树分析、蒙特卡罗模拟。

◆风险应对计划编制:对每一个识别出来的风险来分别制定应对措施，这些措施组成的文档称为风险应对计划。包括消极风险(避免策略、转移策略、减轻策略);积极风险(开拓、分享、强大)。

◆风险监控:监控风险计划的执行，检测残余风险，识别新的风险，保证风险福计划的执,得导并读价这些计划对减少风险的有效性

完全避开或消除风险，或者只享受权益而不承担风险是不可能的。

在信息系统项目中，从宏观上来看，风险分为项目风险、技术风险和商业风险。

**项目风险包括：潜在的预算、进度、个人、资源、用户、需求方面的问题以及它们对项目的影响，会威胁到项目计划。**即可能拖延项目进度、增加项目成本。

**技术风险包括：潜在的设计、实现、接口、测试和维护方面的问题，技术上的不确定性等，威胁到待开发系统的质量和预定的交付时间。**即系统能不能做出来以及做出来质量如何。

商业风险威胁到待开发系统的生存能力。即系统能不能卖出去。

◆组织结构模式:项目型(项目经理绝对领导)、职能型(部门领导为主)、矩阵型(二者结合，既有项目经理也有部门领导，但权利分割不同)。
◆程序设计小组的组织方式:
(1)主程序员制小组(主程序员全权负责，后援工程师必要时能替代主程序员，适合大规模项目)

(2)民主制小组(也即无主程序员小组，成员之间地位平等，任何决策都是全员参与投票，适合于项目规模小，开发人员少，采用新技术和确定性较小的项目)

(3)层次式小组(两个层次，一名组长领导若干个高级程序员，每个高级程序员领导若干个程序员)。