[toc]
软件设计师笔记05_软件工程基础
下面的内容参考自《软件设计师教程(第5版)》 这本书的第5章 软件工程基础知识。
软件工程概述
软件工程指的是应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，目的是提高软件生产率、提高软件质量、降低软件成本。
软件工程的基本要素：方法、工具、过程。
计算机软件
计算机软件指的是计算机系统中的程序及其文档。程序是计算任务的处理对象和处理规则的描述。任何以计算机为处理工具的任务都是计算任务。
按照软件的应用领域，将计算机软件分为以下十类，包括：
- ①系统软件；
- ②应用软件；
- ③工程/科学软件；
- ④嵌入式软件；
- ⑤产品线软件；
- ⑥Web 应用软件；
- ⑦人工智能软件；
- ⑧开放计算；
- ⑨网络资源；
- ⑩开源软件
软件工程基本原理
软件工程的七条基本原理
- ① 分阶段的生命周期计划严格管理；
- ② 坚持进行阶段评审；
- ③ 实现严格的产品控制；
- ④ 采用现代的程序设计技术；
- ⑤ 结果应能清楚地审查；
- ⑥ 开发小组的人员应少而精；
- ⑦ 承认不断改进软件工程实践的必要性
软件生存周期
一个软件产品或软件系统要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生存周期。
软件生存周期包括以下七个方面：
- 可行性分析与项目开发计划。这个阶段主要确定软件的开发目标及其可行性。参与该阶段的人员有用户、项目负责人、系统分析师。产生的文档有可行性分析报告、项目开发计划。
- 需求分析。该阶段的任务不是具体的解决问题，而是要确定软件系统要做什么，确定软件系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。参与该阶段的人员有用户、项目负责人、系统分析师。产生的文档主要是软件需求说明书。
- 概要设计。该阶段开发人员把确定的各项功能需求转换成需要的体系结构。概要设计就是设计软件的结构，明确软件由哪些模块组成，这些模块层次结构是怎样的，调用关系是怎样的，每个模块的功能是什么。参与该阶段的人员有系统分析师、软件设计师。产生的文档主要是概要设计说明书。
- 详细设计。该阶段的主要任务是对每个模块的功能进一步详细、具体的描述。参与该阶段的人员有软件设计师、程序员。产生的文档主要是详细设计文档。
- 编码。把每个模块的控制结构转换成计算机可接受的程序代码，即写成某种特定程序设计语言表示的源程序清单。
- 测试。测试是保证软件质量的重要手段。参加测试的人员通常是另一部门（或单位）的软件设计师或系统分析师。产生的文档主要是软件测试计划、测试用例、测试报告。
- 维护。软件维护是软件生存周期中时间最长的阶段。软件已交付且正式投入使用后，便进入维护阶段。对软件进行修改的原因包括：①运行中发现隐含的错误而需要修改；②为了适应变化的（或变化后的）工作环境而修改；③需要对软件功能进行扩充、增强而进行的修改；④为将来软件维护活动做预先准备。
软件过程
在开发产品或构建系统时，遵循一系列可预测的步骤(即路线图)是非常重要的，它有助于及时交付高质量的产品。这个软件开发中所遵循的路线图称为“软件过程”。
软件过程有三层含义：
- 个体含义：指某产品、系统在生存周期中的某一类活动的集合，如开发过程、管理过程等。
- 整体含义：指软件产品、系统在所有上述含义下的软件过程的总体。
- 工程含义：指解决软件过程的工程。
能力成熟度模型（CMM）
能力成熟度模型（CMM） 是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步提高。
通过该能力成熟度模型可以较容易地确定软件过程的成熟度并识别其软件过程执行中的薄弱环节，确定对软件质量和过程改进最为关键的几个问题，从而形成对其过程的改进策略。
能力成熟度模型（CMM）将软件过程的改进分为五个成熟度级别。
能力成熟度模型集成（CMMI）
CMMI 是若干过程模型的综合和改进，是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。
CMMI 提供了两种表示方法：阶段式模型和连续式模型。
- 阶段式模型。结构类似于 CMM，它关注组织的成熟度。
- 连续式模型。关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级（简称 CL）。
CMMI 中包括六个过程域能力等级。
- CL0（未完成的）：过程域未执行或未得到CL1中定义的所有目标。
- CL1（已执行的）：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。
- CL2（已管理的）：其共性目标是集中于已管理的过程的制度化。所有工作任务和工作产品都被监控、控制、和评审。
- CL3（已定义级的）：其共性目标集中于已定义的过程的制度化。过程是按照组织的裁剪指南从组织的标准过程中裁剪得到的，还必须收集过程资产和过程的度量，并用于将来对过程的改进。
- CL4（定量管理的）：其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的质量目标作为管理准则。
- CL5（优化的）：使用量化（统计学）手段改变和优化过程域，以满足客户的改变和持续改进计划中的过程域的功效。
软件过程模型
软件过程模型习惯上称为软件开发模型，它是软件开发全部过程、活动和任务的结构框架。
典型的软件过程有瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件的开发模型和形式化方法模型等。
瀑布模型
瀑布模型的开发流程如同瀑布一般，一步一步的走下去，直到最后完成项目开发。
瀑布模型包括需求分析、设计、编码、测试、运行与维护共5个阶段。
如图所示 
- 瀑布模型的优点：容易理解、成本低、强调开发的阶段性早期计划及需求调查和产品测试
- 瀑布模型的缺点：只适用于需求明确或者二次开发(需求稳定)，当需求不明确时，最终开发的项目容易产生错误，有很大的缺陷。
V 模型
V模型是瀑布模型的一个变体。如图所示。
V 模型的特点是增加了很多轮测试，并且这些测试贯穿于软件开发的各个阶段，不像其他模型都是软件开发完成后测试，很大程度上保证了项目的准确性。
增量模型
增量模型：首先开发核心模块功能，而后与客户确认。之后再开发次核心模块的功能，即每次开发一部分功能，并与客户需求确认。最终完成项目开发，优先级最高的服务最先交付
增量模型也具有瀑布模型所有的优点。
增量模型的优点：可交付的第一个增量版本所需要的成本和时间很少，所承担的风险不大。由于很快发布了第一个版本，因此可减少客户需求的变更。
增量模型的缺点：若客户需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发或重新发布；管理发生的成本、进度和配置的复杂性可能会超出组织的能力。
演化模型
在开发过程中，软件开发人员需要一种专门应对不断演变的软件产品的过程模型。而演化模型是迭代的过程模型，特别适用于对软件需求缺乏准确认识的情况。
典型的演化模型有原型模型和螺旋模型等。
原型模型
原型模型：即快速原型开发，原型模型针对的就是需求不明确的情况，首先快速构造一个功能模板，演示给客户看，并按用户要求及时修改，中间再通过不断的演示与客户沟通，最终设计出项目，就不会出现与客户要求不符合的情况，采用的是迭代的思想。
原型模型如图所示。 
螺旋模型
螺旋模型是将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。
因此螺旋模型是针对需求不明确的项目，与原型模型类似，但是增加了风险分析，这也是其最大的特点。
螺旋模型强调风险分析，使用户、开发人员对演化层出现的风险有所了解，从而作出反映。因此，螺旋模型适合用于庞大、复杂、高风险的系统。
螺旋模型如图所示。 
螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，每个螺旋周期分为如下4个工作步骤。
- 制订计划：确定软件目标，选定实施方案，明确项目开发的限制条件。
- 风险分析：对所选方案进行分析，识别风险，消除风险。
- 实施工程：实施软件开发，验证阶段性产品。
- 用户评估：评价开发工作，提出修正建议，建立下一个周期的开发计划。
喷泉模型
喷泉模型：是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。使开发过程具有迭代性和无间隙性。
喷泉模型如图所示。 
- 优点：喷泉模型的各个阶段没有明显的界线，开发人员可以同步进行。其优点是可以提高软件项目的开发效率，节省开发时间。
- 缺点：这种模型要求严格管理文档，使得审核的难度加大。
基于构件的开发模型CBSD
基于构件的开发模型CBSD：利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品软件构件。
- 特点是增强了复用性，在系统开发过程中，会构建一个构件库，供其他系统复用,因此可以提高可靠性,节省时间和成本。
基于构件的开发模型如图所示 
形式化方法模型
形式化方法是建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机软件形式化的数学规格说明。
统一过程（UP）模型
统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，由UML方法和工具支持。
统一过程（UP）模型定义了四个技术阶段及其产品
- （1）起始阶段：专注于项目初创活动。
- （2）精化阶段：在理解了最初领域范围之后，需要进行需求分析和架构演进。
- （3）构建阶段：关注系统的构建，产生实现模型。
- （4）移交阶段：关注软件提交方面的工作，产生软件增量。
敏捷方法
敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。通过在软件开发过程中加入灵活性，敏捷方法使用户能够在开发周期的后期增加或改变需求。
敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念(敏捷宣言)。
极限编程(XP)
极限编程(XP)是一种轻量级(敏捷)、高效、低风险、柔性、可预测的、科学的软件开发方式。
它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。
- 4大价值观:沟通、简单性、反馈和勇气。
- 5个原则:快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
- 12 个最佳实践。
- 计划游戏(快速制定计划、随着细节的不断变化而完善)、
- 小型发布(系统的设计要能够尽可能早地交付)、
- 简单设计(只处理当前的需求，使设计保持简单)、
- 测试先行(先写测试代码，然后再编写程序)、
- 重构(重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求)、
- 结队编程、集体代码所有制、持续集成(可以按日甚至按小时为客户提供可运行的版本)、
- 每周工作40个小时、现场客户和编码标准。
水晶法
水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论，认为人对软件质量有重要的影响，因此随着项目质量和开发人员素质的提高，项目和过程的质量也随之提高。
通过更好地交流和经常性的交付，软件生产力得到提高。
并列争求法(Scrum)
并列争求法使用迭代的方法，其中，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
多个小组并行地递增实现产品。协调是通过简短的日常情况会议来进行，就像橄榄球中的“并列争球”。
自适应软件开发(ASD)
ASD有6个基本的原则。
- 有一个使命作为指导;
- 特征被视为客户价值的关键点;
- 过程中的等待是很重要的，因此“重做”与“做”同样关键;
- 变化不被视为改正，而是被视为对软件开发实际情况的调整;
- 确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求;
- 风险也包含其中。
敏捷统一过程(AUP)
敏捷统一过程(AUP)采用“在大型上连续”以及在“在小型上迭代”的原理来构建软件系统。
采用经典的UP阶段性活动(初始、精化、构建和转换)，提供了一系列活动，能够使团队为软件项目构想出一个全面的过程流。
每个AUP迭代执行以下活动:
- 建模。建立对商业和问题域的模型表述，这些模型“足够好”即可，以便团队继续前进。
- 实现。将模型翻译成源代码。
- 测试。团队设计和执行一系列的测试来发现错误以保证源代码满足需求。
- 部署。对软件增量的交付以及获取最终用户的反馈。
- 配置及项目管理。着眼于变更管理、风险管理以及对团队的任一制品的控制。项目管理追踪和控制开发团队的工作进展并协调团队活动。
- 环境管理。协调标准、工具以及适用于开发团队的支持技术等过程基础设施。
各个软件过程模型总结
瀑布模型：需求明确，如同瀑布一般，按阶段一步一步完成。
V模型：瀑布模型的变体。在瀑布模型的各个阶段上添加多轮测试。很大程度上保证了软件的准确性。强调测试贯穿项目始终，而不是集中在测试阶段。是一种测试的开发模型。
增量模型：瀑布模型的变体。先开发核心功能，后开发附加功能。一个增量一个增量的开发。特点是可以很快发布了第一个版本。
演化模型：针对的就是需求不明确的情况。
- 原型模型：采用快速迭代的思想。只适合小型软件系统的开发。
- 螺旋模型：在原型模型的基础上加上了风险分析。适合用于庞大、复杂、高风险的系统。
喷泉模型：适合于面向对象的开发方法,可复用。使开发过程具有迭代性和无间隙性。
需求分析
软件需求
软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。
通常这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等。
而需求分析也称为软件需求分析等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。
软件需求分析包括内容的如下
- （1）功能需求：考虑系统要做什么、什么时候做、如何修改或升级。
- （2）性能需求：考虑软件开发的技术性指标，如存储容量限制、执行速度、响应时间、吞吐量等。
- （3）用户或人的因素：考虑用户的类型。
- （4）环境需求：考虑软件应用的环境。
- （5）界面需求：考虑来自其他系统的输入或到其他系统的输出等。
- （6）文档需求：考虑需要哪些文档、文档针对哪些读者。
- （7）数据需求：考虑输入、输出格式，接收、发送数据的频率，数据的精准度、数据流量、数据保持时间。
- （8）资源使用需求：考虑软件运行时所需要的资源。
- （9）安全保密需求：考虑是否需要对访问系统或系统信息加以控制。
- （10）可靠性需求：考虑系统的可靠性需求、系统是否必须检测和隔离错误、出错后重启系统所允许的时间等。
- （11）软件成本消耗或开发进度需求：考虑开发是否有规定的时间表
- （12）其他非功能性需求：如采用某种开发模式、确定质量控制标准、里程碑和评审、验收标准等。
系统设计
在需求分析阶段，我们已经搞清楚了软件“做什么”的问题，并把这些需求通过规格说明书描述了出来。
然后进入系统设计阶段，系统设计的主要目的就是为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方案。
概要设计
第一步：设计软件系统总体结构
软件系统总体结构的设计是概要设计关键的一步，其基本任务是采用某种设计方法，将一个复杂的系统按功能划分成模块;确定每个模块的功能;确定模块之间的调用关系;确定模块之间的接口，即模块之间传递的信息;评价模块结构的质量。
第二步：数据结构及数据库设计
进行数据结构的设计。
进行数据库的设计。数据库的设计是指数据存储文件的设计，主要进行以下几方面设计。
- ①概念设计。在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用E-R模型来表述数据模型。E-R模型既是设计数据库的基础，也是设计数据结构的基础。
- ②逻辑设计。E-R模型是独立于数据库管理系统(DBMS)的，要结合具体的DBMS 特征来建立数据库的逻辑结构。
- ③物理设计。对于不同的DBMS，物理环境不同，提供的存储结构与存取方法各不相同。物理设计就是设计数据模式的一些物理细节，如数据项存储要求、存取方法和索引的建立等。
编写概要设计文档 文档主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。
评审 对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等都一一进行评审。
详细设计
- (1)对每个模块进行详细的算法设计，用某种图形、表格和语言等工具将每个模块处理过程的详细算法描述出来。
- (2)对模块内的数据结构进行设计。
- (3)对数据库进行物理设计，即确定数据库的物理结构。
- (4)其他设计。根据软件系统的类型，还可能要进行以下设计。
- ①代码设计。为了提高数据的输入、分类、存储和检索等操作，节约内存空间，对数据库中某些数据项的值要进行代码设计。
- ②输入/输出格式设计。
- ③用户界面设计。
- (5)编写详细设计说明书。
- (6)评审。对处理过程的算法和数据库的物理结构都要评审。
系统设计的结果是一系列的系统设计文件，这些文件是物理实现一个信息系统(包括硬件设备和编制软件程序)的重要基础。
系统测试
软件项目系统测试是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方。
系统测试可以发现系统分析和设计中的错误。
系统测试与调试
信息系统测试包括软件测试、硬件测试、网络测试。测试的目的是以最少的人力和时间发现潜在的各种错误和缺陷。
测试应遵循的基本原则
- ①应尽早并不断地进行测试；
- ②测试工作应避免原先开发软件的人员或小组参与；
- ③设计测试方案时要确定输入数据，还要根据系统功能确定预期的输出结果；
- ④设计测试用例时要设计合理、有效的输入条件，还要包含不合理、失效的输入条件。人们在测试时通常忽略了对异常、不合理、意想不到的情况进行测试，这可能就是隐患；
- ⑤在测试时要检查程序是否做了该做、不该做的事，多余的工作会影响程序的效率；
- ⑥严格按照测试计划进行测试；
- ⑦妥善保存测试计划、测试用例；
- ⑧要精心设计测试用例。
测试的过程包括
- ①制定测试计划；
- ②编制测试大纲；
- ③根据测试大纲设计和生产测试用例；
- ④事实测试；
- ⑤生成测试报告
传统软件的测试策略
软件测试策略将软件测试用例的设计方法集成到一系列经过周密计划的步骤中，从而使软件构造成功地完成。
有效的软件测试实际上分为4步进行，即单元测试、集成测试、确认测试和系统测试。
单元测试
单元测试也称模块测试，在模块编写完成且编译无误后进行，侧重于模块中的内部处理逻辑和数据结构。
单元测试环境如图所示。 
集成测试
集成测试就是把模块组合起来进行测试。即使所有的模块都通过了测试，在集成之后，仍然可能出现问题。
另外，单个模块的误差可以接受，但模块组合后，可能会出现误差累积，最后累积到不能接受的程度。
集成测试通常有以下两种方法：
- （1）非增量集成：分别测试各个模块，再将这些模块组合起来进行整理测试。
- （2）增量集成：以小增量的方式逐步进行构造和测试。
常用的增量集成策略包括：自顶向下集成测试、自底向上集成测试、回归测试、冒烟测试等
确认测试
确认测试始于集成测试的结束，那时已测试完单个构件，软件已经组装成完整的软件包，而且接口错误已被发现和改正。
确认过程的一个重要成分是配置评审，主要检查软件、文档、数据是否齐全、分类有序。
系统测试
系统测试是将已经确认的软件、硬件、外设、网络等其他因素结合在一起，进行各种集成测试和确认测试，主要包括恢复测试、安全性测试、压力测试、性能测试、部署测试。
测试方法
软件测试的测试方法分为静态测试和动态测试。
- 静态测试：是指被测程序不在机器上运行，采用人工检测和计算机辅助静态分析的手段对程序进行测试，包括人工检测、计算机辅助静态分析。
- 人工检测：是指通过人工阅读、分析程序代码、设计测试用例等方式，发现程序中的错误和缺陷。
- 计算机辅助静态分析：是指利用计算机程序对程序代码进行分析，发现程序中的错误和缺陷。
- 动态测试：是指通过运行程序发现错误，一般采用黑盒测试和白盒测试。
- 黑盒测试：也称功能测试，在不考虑软件内部结构和特性的情况下，测试软件的外部特性。
- 白盒测试：也称结构测试，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要。
调试
调试发生在测试之后，其任务是根据测试时所发现的错误找出原因和具体的位置，进行改正。
调试工作主要由程序开发人员进行，谁开发的程序就由谁来进行调试。
目前常用的调试方法有以下五种：
- （1）试探法：调试人员分析错误的症状，猜测问题所在的位置，一步步试探和分析问题所在。该方法效率低，适用于结构比较简单的程序。
- （2）回溯法：调试人员从发现错误症状的位置开始，人工沿着程序的控制流程往回追踪代码，直到找出问题根源为止。该方法适用于小型程序。
- （3）对分查找法：该方法主要用来缩小错误范围，直到把故障范围缩小到比较容易诊断为止。
- （4）归纳法：从测试所暴露的问题出发，收集所有正确、不正确的数据，并分析它们之间的关系，提出假想的错误原因，用这些数据证明或反驳，从而查出错误所在。
- （5）演绎法：根据测试结果，列出可能的错误原因，分析已有的数据，排除不可能和彼此矛盾的原因。若有多个错误同时存在，就要重新分析，提出新的假设，直到发现错误为止。
系统维护
系统维护主要包括硬件维护、软件维护和数据维护。
硬件维护
硬件维护应由专职的硬件维护人员来负责，主要有两种类型的维护活动。
一种是定期的设备保养性维护，保养周期可以是一周或一个月不等，维护的主要内容是进行例行的设备检查与保养，易耗品的更换与安装等;
另一种是突发性的故障维护，即当设备出现突发性故障时，由专职的维修人员或请厂方的技术人员来排除故障，这种维修活动所花的时间不能过长，以免影响系统的正常运行。
软件维护
软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部修改。
软件维护的内容一般有以下几个方面。
- (1)正确性维护。正确性维护是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。
- (2)适应性维护。适应性维护是指使应用软件适应信息技术变化和管理需求变化而进行的修改。
- (3)完善性维护。这是为扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。这些功能对完善系统功能是非常必要的。
- (4)预防性维护。为了改进应用软件的可靠性和可维护性，为了适应未来的软/硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。
除此之外还有数据维护。
数据维护
数据维护工作主要是由数据库管理员来负责，主要负责数据库的安全性和完整性以及进行并发性控制。数据库管理员还要负责维护数据库中的数据，当数据库中的数据类型、长度等发生变化时，或者需要添加某个数据项、数据库时，要负责修改相关的数据库、数据字典，并通知有关人员。
另外，数据库管理员还要负责定期出版数据字典文件及一些其他数据管理文件，以保留系统运行和修改的轨迹。当系统出现硬件故障并得到排除后,要负责数据库的恢复工作。
数据维护中还有一项很重要的内容，那就是代码维护。不过代码维护发生的频率相对较小。
代码维护
代码的维护应由代码管理小组进行。变更代码应经过详细讨论，确定之后要用书面形式贯彻。代码维护的困难往往不在于代码本身的变更，而在于新代码的贯彻。为此，除了成立专门的代码管理小组外，各业务部门要指定专人进行代码管理，通过他们贯彻使用新代码。这样做的目的是要明确管理职责，有助于防止和更正错误。
软件项目管理
软件项目管理是指软件生存周期中软件管理者所进行的一系列活动，其目的是在一定的时间和预设范围内有效地利用人力、资源、技术和工具，使软件系统或软件产品按原定计划和质量要求如期完成。
软件项目管理涉及的范围
有效的软件项目管理集中在以下四点：人员（person）、产品（product）、过程（procedure）项目（project）。
软件项目估算
软件项目估算涉及人、技术、环境等多种因素，因此很难在项目完成前准确地估算出开发软件所需的成本、持续时间和工作量。
成本估算方法
常用的成本估算方法如下
- 1、自顶向下估算：又称类比估算法，确定一个总金额，再向下分摊到每一个功能点
- 2、自底向上估算：从底层功能点开始估算成本，向上累加
- 3、差别估算法：与以前项目比较，找出不同点重新估算，相同点则直接估算
- 4、专家估算：聘请专家以其经验对项目整体费用进行估算
COCOMO估算模型
COCOMO估算模型是常见的软件规模估算方法。常用的代码行分析方法作为其中一种度量估计单位，以代码行数估算出每个程序员工作量，累加得软件成本
COCOMO估算模型按其详细程度可以分为三级：
- 基本COCOMO模型：是一个静态单变量模型，它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量
- 中间COCOMO模型：在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算
- 详细COCOMO模型：包括中间COCOMO模型的所有特性，但更进一步考虑了软件工程中每一步骤（如分析、设计）的影响
进度管理
软件项目进度管理的目的是确保软件项目在规定的时间内按期完成。
一个软件项目通常可以分成多个子项目和任务，这些任务之间存在一定的关系。有些任务可并行开发，有些任务必须在另一些任务完成后才能进行。
因此，进度管理的任务是确定项目任务的顺序和依赖关系，为每个任务分配资源和时间，确保项目在规定时间内完成。
进度管理的基本原则
进度管理的基本原则如下
- （1）划分：项目必须要被划分成若干个可以管理的活动和任务。
- （2）相互依赖性：划分后的各个活动之间的依赖关系必须是明确的，如有的任务必须按顺序完成，有的任务可以并发进行，有的任务只能在其他活动完成后才能开展，有的任务则可以独立进行。
- （3）时间分配：必须为每个任务规定开始和结束时间。
- （4）工作量确认：每个项目都有预定的人员参与，项目管理者在任何时间节点中所分配的人员数量不能超过项目团队的总人数。
- （5）确定责任：为每个任务指定特定的团队成员进行负责。
- （6）明确输出结果：每个任务都要有一个明确的输出结果，如一个可交付的工作产品。
- （7）确定里程碑：每个任务或任务组都应该与一个项目里程碑相关联，当一个或多个工作产品经过质量评审并得到认可时，标志着一个里程碑的完成.
进度安排
为了监控项目的进度计划和实际的进展情况，也为了表示各项任务之间进度的相互依赖关系，需要采用图示的方法。
进度安排的常用图形描述方法有Gantt图(甘特图)和项目计划评审技术(PERT)图。
甘特图（Gantt Chart）
Gantt图：又称为横道图，横轴表示时间，纵轴表示活动，以时间顺序表示活动，能反应活动间的并行关系，但无法反应活动之间的依赖关系。
Gantt图能清晰地描述每个任务从何时开始，到何时结束，任务的进展情况以及各个任务之间的并行性。但是它不能清晰地反映出各任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分。
PERT图
PERT图：类似于前趋图，是有向图，反应活动之间的依赖关系，有向边上标注活动运行的时间，但无法反应活动之间的并行关系
PERT图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的关系，即哪些任务完成后才能开始另外一些任务，以及如期完成整个工程的关键路径。
图中的松弛时间则反映了完成某些任务时可以推迟其开始时间或延长其所需完成的时间。但是，PERT图不能反映任务之间的并行关系。
软件质量
软件质量是指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体。
软件质量管理是指对软件开发过程进行独立的检查活动，由质量保证、质量规划和质量控制3个主要活动构成。
软件质量特性
目前已经有多种软件质量模型来描述软件质量特性，例如ISO/IEC9126软件质量模型和McCall软件质量模型。
ISO/IEC9126 软件质量模型
在 ISO/IEC9126软件质量模型 中，软件质量模型由三个层次组成，第一层为质量特性，第二层为质量子特性，第三层为度量指标。
如图所示 
ISO/IEC 9126模型中，基本特性为6个：功能性、可靠性、易使用性、效率、可维护性和可移植性。
- 功能性：适合性、准确性、互操作性、安全保密性。
- 可靠性：成熟性、容错性、易恢复性。
- 易用性：易理解性、易学性、易操作性。
- 效率：时间特性、资源利用性。
- 维护性：易分析性、稳定性、易测试性、易改变性。
- 可移植性：适应性、易安装性、一致性、易替换性。
McCall软件质量模型
McCall 软件质量模型给出了一个三层模型框架，第一层为质量特性，第二层为评价准则，第三层为度量指标。
软件质量保证
软件质量保证是指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是生产高质量的软件。
在软件质量方面强调三个要点：
- ①软件必须满足用户规定的需求；
- ②软件应遵循规定标准所定义的一系列开发准则；
- ③软件还应满足某些隐含的需求。
软件质量保证包括七个主要活动相关的各种任务：
- ①应用技术方法；
- ②进行正式的技术评审；
- ③测试软件；
- ④标准的实施；
- ⑤控制变更；
- ⑥度量；
- ⑦记录、保存和报告。
软件度量
软件度量用于对产品及开发产品的过程进行度量。
软件度量分类
软件度量有两种分类方法。
- 第一种分类是将软件度量分为面向规模的度量、面向功能的度量和面向人的度量;
- 第二种分类是将软件度量分为生产率度量、质量度量和技术度量。
软件工具和软件开发环境
软件工具
用来辅助软件开发、运行、维护、管理和支持等过程中的活动的软件称为软件工具。
软件开发工具
对应于软件开发过程的各种活动，软件开发工具通常有需求分析工具、设计工具、编码与排错工具、测试工具等。
- (1)需求分析工具。用于辅助软件需求分析活动的软件称为需求分析工具，它辅助系统分析员从需求定义出发，生成完整的、清晰的、一致的功能规范。功
- (2)设计工具。用于辅助软件设计活动的软件称为设计工具，它辅助设计人员从软件功能规范出发，得到相应的设计规范。
- (3)编码与排错工具。辅助程序员进行编码活动的工具有编码工具和排错工具。
- (4)测试工具。用于辅助软件测试活动的软件称为测试工具。
软件维护工具
辅助软件维护过程中活动的软件称为软件维护工具，它辅助维护人员对软件代码及其文档进行各种维护活动。
软件维护工具主要有版本控制工具、文档分析工具、开发信息库工具、逆向工程工具和再工程工具。
- (1)版本控制工具。在软件开发和维护过程中，版本控制工具用来存储、更新、恢复和管理一个软件的多个版本。
- (2)文档分析工具。文档分析工具用来对软件开发过程中形成的文档进行分析，给出软件维护活动所需的维护信息。
- (3)开发信息库工具。开发信息库工具用来维护软件项目的开发信息，包括对象、模块等。
- (4)逆向工程工具。逆向工程工具辅助软件人员将某种形式表示的软件(源程序)转换成更高抽象形式表示的软件。这种工具力求恢复源程序的设计信息，使软件变得更容易理解。逆向工程工具分为静态的和动态的两种。
- (5)再工程工具。再工程工具用来支持重构一个功能和性能更为完善的软件系统。目前的再工程工具主要集中在代码重构、程序结构重构和数据结构重构等方面。
软件开发环境
软件开发环境指支持软件产品开发的软件系统。