软件工程基础知识 二

系统开发方法论

系统开发方法主要包括结构化分析于设计方法（SA/SD）、面向数据结构的设计方法和面向对象分析与设计方法。

1、结构化分析与设计方法

该方法采用结构化技术来完成软件开发的个性任务，把软件生命周期的全部过程依此划分为若干阶段，然后顺序地完成每个阶段的任务，与瀑布模型又很好的结合度，是与其最相适应的开发方法。

结构化分析方法学也称为生命周期方法学，它采用结构化分析、设计、编程来完成软件开发的各项任务，具有阶段性、推迟实现、文档管理3大特点。目前虽然面向对象开发方法以及取代了结构化方法成为软件开发的主流，但对于一些功能需求非常明确而且不会轻易改变的软件系统，结构化方法仍然比较有效。

1）结构化分析基础

结构化分析（解决”做什么“的问题）：是一种面向数据流的需求分析方法。其基本思想是：自顶而下，逐层分解，每个最底层的问题都是足够简单、容易解决的，于是复杂的问题也就迎刃而解了。在结构化分析时，常使用的工具包括数据量图和数据字典，整个分析的结果由一套分层的数据流图、一本数据字典、一组小说明（加工的逻辑说明）以及软件需求规格说明书组成。

2）结构化设计基础

结构化设计包括体系结构设计、接口设计、数据设计和过程设计等任务。它是一种面向数据流的设计方法，是以结构化分析阶段所产生的成果为基础，进一步自顶而下、逐步求精和模块化的过程。

• 概要设计：主要是设计软件的结构，确定系统是由那些模块组成，以及每个模块直接的关系，它可以使用结构图（包括模块、调用、数据）来描述程序的结构，同时还可以使用层次图和HIPO（层次图加输入输出图），整个过程主要包括：复查基本系统模型、复查并精华数据流图、确定数据流图的信息类型（包括交换流和事务流）、根据流类型分别实施变换分析或事物分析、根据软件设计原则对得到的软件结构图进一步优化。

• 详细设计：确定应该如何具体地实现所要的系统，得出对目标系统的精确描述。它采用自顶向下、逐步求精的设计方式和单入口的控制结构。经常使用的程序流程图、盒图、PAD图（问题分析图）、PDL（伪代码）

3）模块设计原则

在结构化方法种，模块化是一个很重要的概念，它是将一个带开发的软件分解成若干个小的简单部分——模块，每个模块可以独立地开发、测试。这是一种复杂问题的”分而治之“原则，其目的是使程序的结构清晰，易于测试与修改。

具体来说，模块是指执行某一特定任务的数据结构和程序代码。通常将模块的接口和功能定义为其外部特性，将模块的局部数据和实现该模块的程序代码称为内部特性。而在设计时，最重要的原则就是实现信息隐藏和模块独立。模块通常具有连续性，也就是意味着作用于系统的小变动将导致行为上的小变化，同时规模说明的小变动也将影响到一小部分模块。

• 信息隐蔽：是开发整体程序结构时使用的法则，即将每个程序的成分隐藏封装在一个单一的设计模块中，并且尽可能少地暴露其内部的处理。通常我们可以将难的决策、可能修改的决策、数据结构的内部链接，以及对它所做的操作细节、内部特征码、与计算机硬件有关的细节等隐藏起来。 可以提高软件的可修改性，可测试性和可移植性。

• 模块独立：是指每个模块完成一个相对独立的特定子功能，并且与其他模块直接的联系最简单。保持模块的高度独立性，也是在设计时的一个很重要的原则。通常我们用耦合（模块之间联系紧密的程度）和内聚（模块内部各元素之间联系的紧密程度）两个标准来衡量，目标是高内聚，低耦合。内聚类型通常可以分为七种，如图所示：

模块的耦合类型通常也分为7种：

 

2、面向数据结构的设计

数据的输入、存储都涉及不同的数据结构，面向数据结构设计方法的基本思想是根据数据结构导出程序结构。典型的买那些数据结构的设计方法包括Jackson方法和Warnier方法。

Jackson方法的基本步骤：线建立系统的数据结构，接着一数据结构为基础，对应地建立程序结构，然后列出程序中要用到的各种基本操作，并将操作分配到适当的模块中。

面向数据结构的设计方法并没有明显地使用软件结构的概念，对应模块独立性原则也重视不足，因此并不试用于复杂的软件系统。

3、面向对象分析与设计

这个方法引入了“对象”的概念，将数据和方法封装在一起，提高了模块的聚合降低了耦合的，更大程度上支持软件复用。是目前最流行的和最具有发展前景的软件开发方法。

软件测试

软件测试是保证软件质量的主要手段之一，也是在将软件交付给客户之前所必须完成的步骤。目前，软件的正确性证明尚未得到根本的解决，软件测试仍是发现软件错误和缺陷的主要手段。

大量统计资料证明，目前软件测试所花费用已经超过软件开发费用的30%。

1、软件测试基础

1）软件测试的目的

软件测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件产品（主要指程序）中的错误和缺陷。

为了发现程序中的错误，应竭力设计能暴露错误的测试用例。测试用例是由测试数据和预期结构构成的。一个好的测试用例是极有可能发现至今为止尚未发现的错误和测试用例。一次成功的测试是发现了至今为止尚未发现的错误的测试。

高效的测试是指用少量的测试用例发现呗测试软件尽可能多的错误。

软件测试所追求的目标就是尽可能少的时间和人力发现软件产品中尽可能多的错误。

2）软件测试准则

• 应该尽早地、不断地进行软件测试，把软件测试贯穿于开发过程的始终。

• 所有测试都应该能追溯到用户需求，从用户的角度看，最严重的错误是导致软件不能满足用户需求的那些错误。

• 应该从“小规模”测试开始，并逐步进行“大规模”测试。

• 应该在测试之前就制定出测试计划。

• 根据Pareto原理，80%的错误可能出现在20%的程序模块中，测试成功的关键是如何成功找出这20%的模块。

• 应该由独立的第三方从事测试工作。

• 对非法和非预期的输入数据也要像合法的预期的输入数据一样编程测试用例。

• 检查软件是否做了应该做的事仅是成功的一半，另一半是看软件是否做了不该做的事。

• 在规划测试时不要设想程序中不会查出错误。

• 测试只能证明软件中有错误，不能证明软件中没有错误。

3）软件测试分类

从测试阶段划分，可分为单元测试、集成测试、确认测试、系统测试。

从测试方法划分，可分为白盒测试、黑盒测试。

对于产品，可分为测试与测试。

在实际应用中，一旦纠正了程序中的错误后，还应选择部分或全部原先已测试过的测试用例，对修改后的程序重新测试，这种测试称为回归测试。

2、V模型

V模型是一个著名的、以测试为驱动的开发模型，该模型强调开发过程中测试贯穿始终。如下图所示，单元测试的测试计划在编码阶段完成；集成测试计划在详细设计阶段完成；确认计划在概要设计阶段完成。

3、单元测试

单元测试（Unit Testing），也称模块测试，通常可放在编程阶段，由程序员对自己编写的模块自行测试，检查模块是否实现了详细设计说明书中规定的功能和算法。单元测试主要发现编程和详细设计中的错误，单元测试计划应该在详细设计阶段制定。

单元测试期间着重从以下几个方向对模块进行测试：模块接口、局部数据结构、重要的执行通路、出错处理通路、出错处理通路、边界条件等。

测试一个模块时需要为该模块编写一个驱动模块和若干个桩（Stub）模块。驱动模块用来调用被测模块，它接收测试者提供的测试数据，并把这些数据传送给被测模块，然后从被测模块接收测试结果，并以某种可以看见的方式（例如显示或打印）将测试结果返回给测试者。桩模块用来模拟被测模块所调用的子模块，它接受被测模块的调用，检验调用参数，并以尽可能简单的操作模拟被调用的子程序模块功能，把结果送回被测模块。顶层模块测试时不需要驱动模块，底层模块测试时不需要桩模块。

模块的内聚程度高可以简化单元测试过程。如果每一个模块只完成一种功能，则需要测试的方案数目将明显减少，模块中的错误也更容易预测和发现。

4、集成测试

集成测试（Integration Testing），也称组装测试，它是对由各模块组装而成的程序进行测试，主要目标是发现模块间的接口和通信问题。例如，数据穿过接口可能丢失；一个模块对另一个模块可能由于疏忽而照成有害影响；把子功能组合起来可能不产生预期的主功能；个别看来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有问题等。集成测试主要发现设计阶段产生的错误，集成测试计划应该在概要设计阶段制定。

集成的方式可分为非渐增式集成和渐增式集成。

非渐增式集成是先测试所有的模块，然后全部将所有这些模块集成到一起，并把庞大的程序作为一个整体来测试。这种测试方法的出发点是可以“一步到位”，但测试者面对众多的错误现象，往往难以分清那些是“真正的”错误，哪些是由其他错误引起的“假性错误”，诊断定位和改正错误也十分困难，所以非渐增式集成只适合一些非常小的软件。

渐增式集成是将单元测试和集成测试合并到一起，它根据模块结构图，按某种次序选一个尚未测试的模块，把它同以测试好的模块组合在一起进行测试，每次增加一个模块，直到所有模块集成在程序中。这种测试方法比较容易定位和改正错误，目前在进行集成测试时已普遍采用渐增式集成。

渐增式集成又可分为自顶向下集成和自底向上集成。自顶向下集成测先测试上层模块，再测试下层模块。由于测试下层模块时它的上层模块已测试过，所以不必另外编写驱动模块；自底向上集成先测试下层模块，再测试上传模块，同样由于测试上层模块时它的下层模块已测试过，所以也不必另外编写桩模块。者两种集成方法各有利弊，一种方法的优点恰好对应另一种方法的缺点，实际测试时可以根据软件特点以及进度安排灵活选用最恰当的方法，也可将两种方法混合使用。

5、确认测试

确认测试（Validation Testing）主要依据软件需求说明书检查软件的功能、性能以及其他特征是否与用户的需求一致。确认测试计划应该在需求分析阶段制定。

软件配置复查是确认测试的另一项重要内容。复查的目的是保证软件配置所有成分都已齐全，质量符号要求，文档与程序完全一致，具有完成软件维护所必需的细节。

如果一个软件是作为产品被许多客户使用的，不可能也没有必要由每个客户进行验收测试。绝大多数软件开发商都使用被称为（Alpha）测试和（Beta）测试的过程来发现那些看起来只有最终用户才能发现的错误。

测由用户在开发者的场所进行，并且在开发者的指导下进行测试，开发者负责记录发现的错误和使用中遇到的问题。也就是说，测试是在“受控的”环境中进行的。

测试是在一个或多个用户的现场由该软件的最终用户实施的，开发者通常不在现场，用户负责记录发现的错误和使用中遇到的问题并把这些问题报告给开发者。也就是说测试是在“非受控的”环境中进行的。

经过确认测试之后软件通常可以交付使用了。

6、系统测试

系统测试的对象是完整的、集成的计算机系统，系统测试的目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。系统测试技术依据是用户需求或开发合同，除应满足一半测试的准入条件外，在进行系统测试钱，还应确认被测系统的所有配置项已通过测试，对需要固化运行的软件还应提供固件。

一般来说，系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等，其中，最重要的工作是进行功能性测试与性能测试。功能测试主要采用黑盒测试方法，性能测试主要验证软件系统在承担一定负载的情况下所表现处理的特性是否符号客户的需要，主要指标有响应时间、吞吐量、并发用户数和资源利用率等。

7、回归测试

回归测试的目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。回归测试的对象主要包括以下4个方向。

• 未通过软件单元测试的软件，在变更之后，应对其进行单元测试

• 未通过配置项测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试和配置测试。

• 未通过系统测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试、配置项测试和系统测试。

• 因为其他原因进行变更之后的软件单元，也首先应对变更的软件单元进行测试，然后再进行相关的软件测试。

8、白盒测试

白盒测试，又称结构测试，主要用于单元测试阶段。它的前提把程序看出装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。这种方法安装程序内部逻辑设计测试用例，检测程序中的主要执行通路是否都能按预定要求正确工作。

白盒测试常用的技术是逻辑覆盖，即考查用测试数据运行被测试程序时对程序逻辑的覆盖程度。主要是覆盖标准有6中：语句覆盖，判断覆盖，条件覆盖、判定/条件覆盖、组合条件覆盖和路径覆盖。

1）语句覆盖

语句覆盖是指选择足够多的测试用例，使得运行这些测试用例时，被测试程序的每个语句至少执行一次。

很显然，语句覆盖是一种很弱的覆盖标准。

2）判定覆盖

判定覆盖又称分支覆盖，它的含义是，不仅每个语句至少执行一次，而且每个判断的每种可能的结果（分支）都至少执行一次。

判定覆盖比语句覆盖强，但对程序逻辑覆盖的程序仍然不高。

3）条件覆盖

条件覆盖的含义是，不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。

条件覆盖不一定包含判断覆盖，而判定覆盖也不一定包含条件覆盖。

4）判定/条件覆盖

同时满足判定覆盖和条件覆盖的逻辑覆盖称为判定/条件覆盖。它的含义是，选取足够的测试用例，使得判定表达式中每个条件的所有可能结果至少出现一次，而且每个判定本身的所有可能结果也至少出现一次。

5）条件组合覆盖

条件组合覆盖的含义是，选取足够的测试用例，使得每个判定表达式中条件结果的所有可能组合至少出现一次。

显然，满足条件组合覆盖的测试用例，也一定满足判定。条件覆盖。因此，条件组合覆盖是上述5种覆盖标准种最强的一种。然而，条件组合覆盖还不能保证出现中所有可能的路径都至少经过一次。

6）路径覆盖

路径覆盖的含义是，选取足够的测试用例，使得出现的每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求每条环路至少经过一次）。

路径覆盖实际上考虑了程序中各种判定结果的所有可能组合，因此是一种较强的覆盖标准。但路径覆盖并未考虑判定中的条件结果的组给，并不能代替条件覆盖和条件组合覆盖。

9、McCabe复杂度

McCabe复杂的属于白盒测试技术，其包括环路复杂度（Cyclomatic complexity）、基本复杂的、模块设计复杂度、设计复杂度和集成复杂度等。

McCabe度量标准是将程序的流程图转化为有向图，也就是控制流图，然后以图论的知识和计算方法来衡量软件的质量。程序流程图和对应的控制流程图如下所示：

将程序流程图转换称控制流程图以后，就可以计算其环路复杂度了。

计算有向图G的环路复杂度公司为：  V（G）=m-n+2     （其中V（G）是有向图G中的环路个数，m是G中的又向弧数，n是G中的节点数）

在上图中 有向弧数位15，节点数位12，所以环路复杂度位：15-12+2=5。

10、黑盒测试

黑盒测试，又称功能测试，主要用于集成测试和确认测试阶段。它把软件看作是一个不透明的黑盒子，完全不考虑（或不了解）软件的内部结构和处理算法，它只检查软件功能是否安装软件需求说明书的要求正常使用，软件是否能适当地接收输入数据并产生正确的输出信息，以及在软件运行过程中能否保持外部信息（例如文件和数据库）的完整性等。

常用的黑盒测试技术包括等价类划分、边值分析、错误推出和因果图等。

1）等价类划分

在设计测试用例时，等价类划分是用的最多的一种黑盒测试方法。所谓等价类就是某个输入域的集合，对于一个等价类中的输入值来说，他们揭示程序中错误的作用是等效的，也就是说，如果等价类中的一个对湖人数据能检测出一个错误，那面等价类中的某个错误，那么等价类中的其他输入数据也不能检测出这一错误（除非这个等价类的某个子集同时还属于另一个等价类）。

如果一个等价类内部的数据是符号（软件需求说明）要求的、合理的数据，则称这个等价类位有效等价类。有效等价类主要用例检验软件是否实现了软件需求说明书中规定的功能。

如果一个等价类内部的数据是不符合（软件需求说明）要求的、不合理或非法的数据，则称这个等价类位无效等价类。无效等价类主要用来检验软件的容错性。

黑盒测试中，理由等价类划分方法设计测试用例的步骤如下：

• 根据软件的功能说明，对每一个输入条件确定若干个有效等价类和若干个无效等价类，并为每个有效等价类和无效等价类编号。

• 设计一个测试用例，使其覆盖尽可能多的尚未覆盖的有效等价类。重复这一步，直至所有的有效等价类均被覆盖。

• 设计一个测试用例，使其覆盖尽可能多的尚未覆盖的无效等价类。重复这一步，直至所有的无效等价类均被覆盖。

应特别注意的是，无效等价类用例测试非正常的输入数据，因此每个无效等价类都有可能查出软件中的错误，所有要位每个无效等价类设计一个测用例。

2）边界分析

经验表明，软件在处理边界情况时最容易出错。设计一些测试用例，使软件恰好运行在边界附近，暴露出软件错误的可能性会更大一些。

通常每一个等价类的边界都应着重测试，选取的测试数据应该恰好等于，稍小于或稍大于边界值。

将等价类划分法和边界分析法结合使用，更有可能发现软件中的错误。

3）错误推测

使用等价类划分和边值分析技术，有助于设计出具有代表性的、容易暴露软件错误的测试方案。但是，不同类型不同特征的软件通常又有一些特殊的容易出错的地方，错误推测法注意依靠测试人员的经验和直觉，从各种可能的测试方案选出一些最可能引起程序出错的方案。

4）因果图

因果图是根据输入条件与输出结果之间的因果关系来设计测试用例的，它首先检测输入条件的各种组合情况，并找出输出结果对输入条件的依赖关系，然后为每种输出条件的组给设计测试用例。

软件维护

软件维护就是在软件交付使用之后直至软件被淘汰的整个时期内为了改造错误或满足新的需求而修改软件的活动。

软件维护的代价是很大的，据1994年Sofware Engineering Encyclopedia记载，20世纪80年代末用于软件维护的花费约为整个软件生命周期总花费的75%，而且还在逐年上升。

1、软件维护类型

根据引起软件维护的原因，软件维护通常可以分为以下4中类型：

• 改正性维护：改正性维护是指在使用过程中发现了隐蔽的错误后，为了诊断和改正这些隐蔽错误而修改软件的活动，该类维护一般占总维护工作量的25%。
• 适应性维护 适应性维护是指为了适应变化了的环境而修改软件的活动。该类维护一般占总维护工作量的20%。
• 完善性维护 完善性维护是指为了扩充或完善原有软件的功能或性能而修改的软件活动。该类维护一般占总维护工作量的5%。
• 预防性维护  为了提高软件可维护性和可靠性、为未来的进一步改进打下基础而修改软件的活动。该类维护一般占维护工作量的50%。

2、软件的可维护性

软件的可维护性是指理解、改正、改动、改进软件的难易程度。根据Boehm质量模型，通常影响软件可维护性的因素有可理解性、可测试性和可修改性。

1）可理解性 维护人员理解软件结构、接口、功能和内部过程的难易程度

2）可测试性 测试和诊断软件错误的难易程度。

3）可修改性 修改软件的难易程度

为了提高软件的可维护性，在软件生命周期的各个阶段都必须充分考虑维护问题。先进的软件工程方法是软件可维护的基础保证。

面向对象方法学的对象封闭机制、消息通信机制、继承机制和多态机制从根本上提高了软件的可理解性、可测试性和可修改性。

结构化设计的几条主要原则，如模块化、信息隐蔽、高内聚、低耦合等，对于提高软件的可理解性、可测试性和可修改性也都有重要的作用。

另外，书写详细正确的文档、书写源文件的内部注解、使用良好的编程语音、具有良好的程序设计风格，也有助于提高软件的可理解性。使用先进的测试工具、保持以前的测试过程和测试用例，则有助于提高软件的可测试性。

3、软件维护管理

软件维护管理是指为保证维护质量、提高维护效率、控制维护成本而进行的维护过程管理，它要求对软件的每次“修改”均需经过申请、评估、批准、实施及验证等步骤。

软件维护管理的核心是维护评估和维护验证。维护评估的主要工作包括：判定维护申请的合理性与轻重缓急、确定维护的可行性与时间及费用、制定维护策略与维护计划等。维护验证主要审查修改后的软件是否实现了维护目标以及软件文档是否做了相应修改等。

软件质量保证

软件质量就是软件与显性及隐形需求相一致的程度。具体来说就是，软件质量是软件与明确叙述的功能和性能需求、文档中明确描述的开发标准，以及任何专业开发的软件产品都应具有隐含特征相一致的程度。

影响软件质量的因素主要包括：人、软件需求、开发过程的各个环节、测试的局限性、质量管理的困难性、是否对质量管理予以重视、软件人员的传统习惯、开发规范和支持性的开发工具等方面。

1、软件质量特性标准

为了能够统一描述软件质量特性，如今已形成了许多质量特性标准，其中最常用的有国家通用的ISO/IEC9126软件质量模型和McCall软件质量模型。

IEO/IEC9126模型  该标准已于1996年被采纳为我国的国家标准《GB/T 16120 ——1996软件产品评价、质量特性及其使用指南》，其包括以下6类21个质量特性，如下图所示：

McCall 质量模型 

McCall质量模型体系​​​​

 

McCall质量模型体系表

 

2、软件质量保证基本概念

软件质量保证就是保证软件产品充分满足消费者要求的质量而进行的有计划、有组织的活动。它主要包括质量方针的制定和展开、质量保证方针和质量保证标准的制定、质量保证体系的建立和管理、明确各阶段的质量保证工作、各阶段的质量评审、确保设计质量、重要质量问题的提出与分析、总结实现阶段的质量保证活动、整理面向用户的文档和说明书、产品质量和质量保证系统的鉴定、质量信息的收集分析及使用等。

3、技术评审

正式的技术评审FTR（Formal Technical Review） 是软件工程师组织的软件质量保证活动。它通常会采用系统化、严密的过程、包括制定计划、总体会员、做准备、开会、返工、追踪和因果分析。应培训审查者，依赖于缺陷检查表和其他错误分析技术。注意：此时不是由作者来主持主审，而是由主持人陈述。

• 制定计划：确定谁来参加，一般需要将人事控制在7人之内：确定准备哪些内容。

• 总体会议：确定评审的背景、假设及目标。

• 做准备：评审员预先阅读评审的材料。

• 评审会议：主持人引导，根据预先准备的检查表进行评审。

• 返工：评审会议为了发现问题，问题应在会后进行返工。

• 跟踪：确定错误已经修改，并通知所有的评审人。

评审工作流示意图

 

软件过程改进

软件过程改进/过程改进（Sofware Process Improvement SPI）帮助软件企业对其软件（制作）过程的改变（进）进行计划、（措施）制定及实施。它的实施对象就是软件企业的软件过程，也就是软件产品的生成过程，当然也包括软件维护之类的维护过程，而对于其他的过程并不关注。

ISO9000标准族​​​​​​

能力成熟度模型（CMM）

CMM模型是CMU/SEI（卡内基梅隆大学/软件工程研究所）提出的软件过程城市度模型。它描述和分析了软件过程能力的发展程度，确立 另一个软件成熟度的分级标准，同时将软件过成熟度分为5级，如下图表示：

在CMM内部，每个成熟度等级（除第一级外）规定了不同的关键过程域（KPA），一个软件组织如果希望达到某一个成熟度级别，就必须完全满足关键过程域所规定的要求，即满足关键过程域的目标。而公共特性是对每个KPA的所有关键实施按照他们的属性进行分组。无论哪个KPA，它们的关键实施都统一按5个公共属性进行组织，分别是执行约定、执行能力、实施活动、度量和分析、实施验证。

CMM模型的最新版本是CMMI，其涉及面比CMM更广，覆盖软件工程、系统工程、集成产品开发和系统采购，如下图所示，它将组织的成熟度分成5个级别，但其中规定的KPA与CMM相比有所变化。

CMM过程成熟度模型

 

软件项目管理

软件项目本身是复杂的，如果没有仔细地进行计划，则复杂的项目是不可能成功的。一个计划良好的项目将受到有效的控制，进制明显，而参加该项目的人员都会得到支持以进行其工作。另外，软件项目本身也具有风险性，如果没有有效的风险管理也是不能成功的。

通常软件工程项目的管理比其他工程项目的管理更困难，这是因为：

• 软件产品不可见。开发的进度及产品的质量是否符号要求不明显，比较难进行把握。

• 没有标准的软件过程。尽管几年来“软件过程改进”领域有许多进步，但由于没有团队、人员的个性化因素，目前还不存在一个“放之四海而皆真理”的标准化软件过程

• 大性软件项目常常是一次性项目。由于这些项目都是“前无古人”的，因此缺乏可以借鉴的历史经验。

1、项目管理九大知识领域

在PMBOK中提出了项目管理九大知识领域，此后者九大知识领域为业界普遍认同。九大知识领域中有四大核心领域：范围管理、时间管理、成本管理、质量管理，四大辅助领域：人力资源、沟通管理、风险管理、采购管理以及负责整体协调的整体管理。

• 整体管理：整体管理负责项目的全生命周期管理、全局性管理和综合性管理。全生命周期管理意味着项目整体管理过程负责管理项目的启动阶段知道项目收尾阶段的项目生命周期。全局性管理意味着项目整体管理过程负责管理项目的整体包括项目管理工作、技术工作和商务工作等。综合性管理意味着项目整体管理过程负责光临项目的需求、范围、进度、成本质量、人力资源、沟通、风险和采购等。

• 范围管理：范围管理确定在项目内包括什么工作和不包括什么工作，由此界定的项目范围在项目的全生命周期内可能因种种原因而变化，项目范围管理也要管理范围的这种变化

• 时间管理：时间管理又称进度管理，其职责是保证项目的所有工作都在一个指定的时间内完成。

• 成本管理：成本管理就是要确保在批准的预算内完成项目

• 质量管理：质量管理是指确定质量方针、目标和职责，并通过质量系统中的质量计划、质量控制、质量保证和质量改进来使其实现的所有管理职能的全部活动。

• 人力资源管理：人力资源管理是为项目正常开展，而进行的招聘（选择）项目组人员并进行有效组织、考核绩效支付报酬、进行有效激励、结合组织与个人需要进行有效开发以便实现最优组织绩溪的全过程。

• 沟通管理：沟通管理是指项目组为项目干系人之间进行良好沟通而进行的管理活动。其内容包括沟通计划编制、信息分发、绩效报告及项目干系人管理等。

• 风险管理：所谓风险管理，就是要在风险成为影响项目成功的威胁之前，识别、着手处理并消除风险的源头。

• 采购管理：采购管理是为完成项目工作，从项目团队外部购买或获取所需的产品、服务或成果的过程。

2、网络计划技术

用网络分析的方法编制的计划成为网络计划，它是一种编制大型工程项目进度计划的有效方法。计划借助于网络表示各项工作与所需要的时间以及各项工作的相互关系。通过网络分析研究工程费用与工期的关系，并找出在编制计划以及计划执行过程中的关键路径，这种方法称为关键路径法（Critical Path Method CPM）。另外，还有一种方法，也是应用网络分析方法与网络计划，但它注重于对各项工作安排的评价和审查，这种方法称为计划评审技术（Program Evaluation and Review Technique PERT）。

1）关键路径

在现代管理中，人们常用有向图来描述和分析一项工程的计划和实施过程，一项工程常被分为多个小的子工程，这些子工程被称为活动。在有向图中，若以定点表示活动，弧表示活动之间的先后关系，这样的图简称为AOV（Activity On Vertex）网；若以定点表示事件，弧表示活动，权表示完成该活动所需的事件（称为活动历时或持续时间），这样的图称为AOE（Activity On Edge）网。例如 下图表示一个具有10给活动的某个工程的AOE网。图中有7个顶点，分别表示事件1~7，其1中表示工程开始状态，7表示工程结束状态。

因AOE网中的某些活动可以并行地进行，所以完成工程的最少时间是从开始定点到结束定点的最长路径长度，称从开始顶点到结束定点的最长路径为关键路径（临界路径），关键路径上的活动为关键活动。

为了找出给定的AOE网络的关键活动，从而找出关键路径，应首先定义以下几个重要的量：

1）（j）,（j）：顶点j事件最早最迟发生事件

2）e(i),l(i)：活动i最早、最迟开始时间。

从源点到某定点的最长路径长度，称为时间为的最早发生时间，记作(j)。显然，l(i)=(j)-(所需时间)，其中j为活动的终点。满足条件l(i)=e(i)的活动为关键活动，关键活动所组成的路径称为关键路径。

求顶点的(j)和(j)可按以下两步来做：

由源点开始向汇点地推

其中，是网络中以为终点的入边集合。

由终点（汇点）开始向源点递推

其中，是网络中以为起点的出边集合。

要求一个AOE网的关键路径，一般需要根据以上变量列出一张表格，然后逐个进行检查。例如，求上图AOE网的关键路径的表格如下图所示：

 

由此，关键活动为、、、和其对应的关键路径有两条，分别为V1—>V2—V5—>V7和V1—>V4—>V5—>V7，长度都是10。

3、甘特图

甘特图（Gantt 图）用水平线段表示任务的工作阶段；线段的起点和终点分别对应着任务的开工时间和完成时间；线段长度表示完成任务的计划时间，，下图给出了一个具有5个任务的甘特图。如果5条线段分别代表着完成任务的计划时间，则在横坐标方向附加一条可向右移动的纵线。它可随着项目的进展，指明已完成的任务（纵线扫过的）和有待完成的任务（尚未扫过的）。我们从甘特图上可以很清楚地看出各子任务在时间上的对比关系。

在甘特图中，每一任务完成的标准不是以能否继续下一阶段任务为标准，而是以必须交付应交付的文档于通过评审为标准，因此在甘特图中，文档编制与评审是软件开发进度的里程碑。甘特图的优点是表明了各任务的计划进行度和当前进度，能动态地反应软件开发进展情况。确定是难以反映多个任务之间存在的负责的 逻辑关系。

4、风险管理

风险是指“损失或伤害的可能性”，其包含不确定性、针对未来、会带来损失等特征。

项目风险管理通常包括风险识别、风险估计（风险评估）和风险驾驭（风险控制）3个主要活动。风险识别的主要工作是找到潜在风险并将其文档化，它包括项目风险、技术风险和商业风险3种；风险评价是通过对各种风险发生的可能性和破坏性着两个方面进行评估，并将它们按优先级进行排列；风险驾驭是指利用某种技术，如原型化、软件自动化、软件心理学和可靠性工程学等方法设法避开风险。

当软件工程环境种考虑风险时，主要是基于关系未来、关系变化、关系选择这三个概念提出的。项目风险关系着项目计划的成败，而商业风险关系着软件的生存能力。在 进行软件工程分析时，项目管理人员要进行4种风险评估活动，包括建立表示风险概率的尺度，描述风险引起的后果，估计风险影响的大小，以及确定风险估计的正确性等。

在风险管理时，经常会应用风险曝光度（Risk Exposure）这个概念，它的计算方法是风险出现的概率乘以风险可能造成的损失。假设正在开发的软件项目可能存在一个未被发现的错误，而这个错误出现的概率是0.5%，给公司造成的损失将是1000000元，那么这个错误的风险曝光度就应该为1000000*0.5%=5000元。

软件开发工具

 在整个软件开发过程中，要使用到一些列的工具，工具的使用让开发效率及软件质量得到了极大的提升。

1、需求分析工具

需求分析工具主要包括两种：PowerDesigner和Rational Rose

PowerDesigner是一种系统分析设计CASE工具，同时也可以作为数据库设计工具使用。它是由美国原Power Soft公司推出的发展版本。PowerDesigner是一个集成的系统设计工具集，可以用于创建UML图、数据库的概念模型和物理模型并能针对某一程序开发语言（平台）快速地生成相应的对象和组件。

Rational Rose简介

Rational Rose是运用最为广泛的UML建模CSAE工具之一，它支持除对象图外所有的UML模型图。

2、数据库设计工具

数据库设计工具主要包括两种PowerDesigner和ERwin。

ERwin是美国CA（Computer Associates International Inc）公司的拳头产品之一。它为企业数据需求和关系数据库设计提供了一个定义、管理和实现的平台。ERwin将ER绘图工具与基于Windows的图形用户接口相结合，这样的特点使得用户能够快速地构建企业的数据解决方案。ERwin支持概念模型和物理模型之间的无损转换，并能够根据物理模型生成具体的数据库或是数据库生成脚本，并支持基于XML格式的数据模型输出。此外，ERwin还与CA另一个需求分析实施用的产品BPwin进行无缝集成，用于帮助设计、生成和维护高质量的应用程序，加速基于组件应用程序的开发。

3、项目管理工具

Microsoft Project与Microsoft的其他办公软件一样，是一个功能强大、界面友好、易于使用的工具软件。就目前来说，Microsoft在全球占据了斤2/3的i项目管理软件市场。它可以用来控制简单或复杂的项目，安排和追踪项目中所有的活动以及这些活动所涉及的资源、资金利用情况，使用户对整个项目的进展一目了然，在一定程度上减轻了项目管理工作量，同时对于提高项目的质量起到了促进的作用。

Micosoft Project 是一个综合性的工具，可以进行多种管理，如项目范围管理、项目实际管理、项目成本管理、人力资源管理等。

Visual Source Safe（VSS）用于项目配置管理，它提高了完善的版本和配置管理功能以及安全保护和跟踪检查功能。VSS将所有的项目源文件（包括各种文件类型）以特有的方式存入数据库。用户可以根据需要随时快速地共享文件。文件一旦被添加进VSS，它的每次改动都会被记录下来，用户可以恢复文件的早期版本，项目组的其他成员也可以看到有关文档的最新版本，并对它们进行修改。使用VSS来管理项目可使得项目组成员间的沟通与合作更简易且直观。

CVS(Concurrent Versions System)与VSS一样，也是用于项目配置管理。它是一个免费、开发、灵活、支持分支/合并、并行开发和集成，便于团队协作大规模开发的版本控制工具。可以说，CVS是目前最为流行和首推的版本控制系统，它同时也是一个开源项目。