笔记-分析设计阶段监理-22.2 分析设计阶段监理工作内容
这章节实在要背诵，太重要了。
22.2 分析设计阶段监理工作内容
分析设计阶段监理一方面监督和控制承建单位工作过程的规范性，另一方面对承建单位需求分析和设计阶段工作成果进行评审，保障软件需求分析设计过程和产品符合规范和要求。
软件需求分析阶段监理主要任务是：
- 对软件需求分析的相关内容（重点是工程需求、功能需求、性能需求、设计约束等）、需求分析过程、需求分析活动、文档格式进行审查，确认是否满足要求；
- 给出是否符合要求的结论；
- 确定其可否作为软件开发的前提和依据。
目前国内信息系统工程建设的过程中，常出现承建单位忽视系统设计的情况，而业主单位出于进度等方面的要求以及信息技术上的弱势，也放松了对承建单位系统设计的要求，致使工程处于边设计、边编码、边修改的“三边”状态。在这种情况下，工程建设的质量、进度与投资几乎失控，常出现质量问题、进度延迟与投资加大的情况，而编码与设计脱节、设计与需求脱节的情况最终会造成系统后续维护的工作量大为增加，经常出现“补丁摞补丁”，最终导致系统在实质上被废弃的情况。
所以，在设计阶段中监理单位要尽可能与业主单位协调配合工作，听取业主单位从业务角度出发提出的对开发方设计的意见。监理单位主要从文档的规范性、可实施性出发，以国家相关标准为依据，从软件工程学的角度对承建单位提出意见与建议，配合业主单位工作，敦促承建单位做好工程项目的设计工作。在设计阶段，监理单位主要针对需求的覆盖性及可跟踪性、模块划分的合理性、接口的清晰性、技术适用性、技术清晰度、可维护性、约束与需求的一致性、可测试性、对软件设计的质量特性的评估、对软件设计的风险评估、对比情况、文档格式的规范性等方面进行评审。在此过程中，业主单位也需要对设计文档进行检查，主要在功能设计是否全面准确地反映了需求、输入项是否完全与正确并符合需求、输出项是否符合需求、与外界的数据接口是否完全与正确并符合需求、各类编码表是否完全与准确并符合需求、界面设计是否符合需求、维护设计是否符合需求、各类数据表格式和内容是否符合要求、是否存在其他有疑问的设计等方面进行核查。▲▲▲
软件概要设计监理的目的是对软件概要设计有关内容（重点是软件的功能、软件的结构、接口设计、接口关系等）、概要设计过程、概要设计活动、文档格式进行审查，确定承建单位提出的软件总体结构设计是否实现了软件需求规格说明的要求，确认是否满足要求；给出是否符合要求的结论；确定其可否作为软件详细设计的前提和依据。
软件详细设计监理的目的是对软件详细设计有关内容（重点是软件的算法、数据结构、数据类型、异常处理、计算效率等）、详细设计过程、详细设计活动、文档格式进行审查，确定承建单位提出的软件详细设计内容是否实现了软件概要设计的要求，确认是否满足要求；给出是否符合要求的结论；确定其可否作为软件编码的前提和依据。
22.2.1 项目计划监理
22.2.2 软件质量管理体系监理
承建单位软件管理过程是保证应用软件系统建设质量的重要基础，软件管理过程监理关心的内容是应用软件系统建设承建单位的软件管理能力。
应用软件系统建设承建单位软件管理过程监理的目标是确保软件承建单位制定具有规范的、标准的项目软件过程；承建单位依据项目软件过程对项目进行计划和管理。
软件管理过程监理的主要内容包括：
（1）监督应用软件系统建设承建单位根据项目合同和业主应用软件系统需求，制定项目软件工程和管理活动，结合成为密切相关、定义完整的项目软件过程；
（2）评估项目软件过程的技术合理性，包括是否符合标准和规范，是否符合项目合同和业主技术要求；
（3）项目软件过程文档化，并得到批准；监督和控制承建单位的项目软件过程的状杰，促使承建单位支持和实施项目软件过程，提高软件项目实施的计划性，减少软件项目实施的风险；
（4）监督应用软件系统建设承建单位在软件开发过程中按照项目软件过程的规范实施，跟踪、记录和审查软件管理过程活动。
22.2.3 软件质量保证计划
▲▲▲ 软件质量保证计划
22.2.4 软件配置管理监理
▲▲▲ 软件配置管理监理
22.2.5 需求说明书评审
由于信息应用系统建设针对的行业广泛，因此在需求分析阶段可能存在着承建单位对业主单位的业务需求理解不全面、不准确的情况，常发生承建单位认为某一个业务功能的实现非常简单，而实际上业主单位业务标准的要求很复杂的情况。在这种情况下，如果不在监理单位的协调下进行业主单位与承建单位充分的沟通，往往造成承建单位按照自己的理解进行开发的情况出现，如果在测试阶段没有发现此类问题则会给系统造成重大隐患，如果发现问题则会造成工程建设返工与延期。
因此，在此阶段监理单位的工作重点是监督承建单位的分析人员、设计人员和测试人员对需求说明书的审查，并协调业主单位与承建单位需求说明书的评审确认。需求分析阶段工作落实的情况，直接决定了后续开发工作的质量、进度、投资与变更的情况，因此必须在监理过程中给予足够的重视。
1.编制良好的需求说明书八条原则
▲▲▲ 编制良好的需求说明书八条原则
2.需求说明书的框架
需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。
需求说明书的框架见表22.1。
3.需求说明书评审内容
▲▲▲ 需求说明书评审内容
4.需求说明书检查表
需求说明书检查表见表22.2。
5.需求说明书评审报告
在需求说明书评审结束后，监理单位应将评审意见以专题监理报告形式提交业主单位。
22.2.6 软件分包合同监理
1. 软件分包合同监理的目标
通过招投标方式签订合同的项目，承建单位可按照合同约定或者经业主同意，将中标项目的部分非主体、非关键性工作分包给他人完成。分承建单位应当具备相应的资格条件，并不得再次分包。承建单位应当就分包项目向业主负责，分承建单位承担连带责任。
软件分包合同管理包括选择分承建单位，建立同分承建单位的约定，并跟踪、评审分承建单位的执行情况和结果。当进行分包时，制定包括技术和非技术需求（如交付日期）的书面协议，并依此管理分包合同。分承建单位要完成的工作及其计划要成文归档。分承建单位遵循的标准要与主承建单位的标准一致。
由分承建单位完成分包工作的软件计划、跟踪和监督活动。主承建单位确保这些计划、跟踪和监督活动能恰当地完成，并且分承建单位交付的软件产品能满足其验收标准。主承建单位和分承建单位共同管理其产品和过程界面。
承建单位的软件分包管理涉及的活动包括：
- 识别所要采办的产品；
- 选择分承建单位；
- 与分承建单位签订协定并予以管理和维护；
- 监督分承建单位的过程能力；
- 验收分承建单位的产品；
- 对所采办的产品安排支持和维护。
对于那些不交付给业主单位产品（如开发工具）的采办，业主单位和承建单位所面临的风险相对较小，软件分包合同监理的内容可以根据需要选择使用。不过，如果项目建立的环境包含有开发工具，而且这个环境又是将要交付给业主单位的产品的组成部分，那么这部分的监理过程是非常值得重视的。
2. 软件分包合同监理的基本准则
承建单位根据需要制定了软件分包合同，同时该分包合同的格式规范，有专人进行负责、管理和维护，软件分包合同的要求与业主单位的合同要求没有冲突，进度、质量和软件过程标准与承建单位的项目计划一致。
3. 软件分包合同监理的方法
方法1：定期审查软件分包合同的管理活动。实施定期审查的主要目的是适当地、及时地掌握软件分包合同管理的软件过程活动。在满足业主单位需求的前提下，只要有适当的机制来报告异常情况，审查的时间间隔就尽可能长些。
方法2：根据实际需要随时跟踪和审查软件分包合同的管理活动。
方法3：评审和（或）审核软件分包合同的管理活动及其产品，并报告结果。这些评审和（或）审核至少应验证：
（1）选择分承建单位的活动。
（2）管理软件分包合同的活动。
（3）协调主承建单位和分承建单位配置管理的活动。
（4）与分承建单位按计划评审的实施情况。
（5）确认分包合同达到关键里程碑或阶段完成时的评审情况。
（6）对分承建单位软件产品的验收过程。
22.2.7 概要设计说明书评审
1. 设计说明书的框架
设计说明书的框架见表22.3。
软件设计的最终目标是要取得最佳方案。“最佳”是指在所有候选方案中，就节省开发费用、降低资源消耗、缩短开发时间的条件，选择能够赢得较高的生产率、较高的可靠性和可维护性的方案。在整个设计的过程中，各个时期的设计结果需要经过一系列的设计质量的评审，以便及时发现和及时解决在软件设计中出现的问题，防止把问题遗留到开发的后期阶段，造成后患。
2. 设计评审的内容
1）评审内容
（1）可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有己确定的软件需求，软件每一成分是否可追溯到某一项需求。
（2）接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚和低耦合的要求。模块作用范围是否在其控制范围之内。
（3）风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。
（4）实用性：即确认该软件设计对于需求的解决方案是否实用。
（5）技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达。
（6）可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。
（7）质量：即确认该软件设计是否表现出良好的质量特征。
（8）各种选择方案：看是否考虑过其他方案，比较各种选择方案的标准是什么。
（9）限制：评估对该软件的限制是否现实，是否与需求一致。
（10）其他具体问题：对于文档、可测试性、设计过程等进行评估。
在这里需要特别注意：软件系统的一些外部特性的设计，例如软件的功能、一部分性能以及用户的使用特性等，在软件需求分析阶段就已经开始。这些问题的解决，多少带有一些“怎么做”的性质，因此有人称之为软件的外部设计。
2）判断设计好坏的三条特征
McGlanghlin给出在将需求转换为设计时判断设计好坏的三条特征：
（1）设计必须实现分析模型中描述的所有显式需求，必须满足用户希望的所有隐式需求。
（2）设计必须是可读、可理解的，使得将来易于编程、易于测试、易于维护。
（3）设计应从实现角度出发，给出与数据、功能、行为相关的软件全貌。
以上三点就是软件设计过程的目标。为达到这些目标，必须建立衡量设计的技术标准。
3）衡量设计的技术标准
（1）设计出来的结构应是分层结构，从而建立软件成分之间的控制。
（2）设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件。
（3）设计应当既包含数据抽象，也包含过程抽象。
（4）设计应当建立具有独立功能特征的模块。
（5）设计应当建立能够降低模块与外部环境之间复杂连接的接口。
（6）设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。
软件设计过程根据基本的设计原则，使用系统化的方法和完全的设计评审来建立良好的设计。
3. 设计说明书检查表
清晰、完整、依从、一致、可行性、数据使用、功能性、接口、可维护性、性能、可靠性、易测性、可追溯性
设计说明书检查表见表22.4。
22.2.8 详细设计说明书评审
清晰、完整、依从、一致、正确性、数据使用、接口、可维护性、性能、可靠性、易测性、可追溯性
详细设计说明书见表22.5。
22.2.9 测试计划评审
完整、依从、一致、正确、详细级别／程度、易测性／可行性、可追溯性
测试计划检查表见表22.6。
22.2.10 软件编码规范评审
程序实际上是一种供人阅读的文章，也有一个文章的风格问题。应该使程序具有良好的风格，具体表现在:源程序文档化、数据说明的方法、语句结构和输入/输出方法等。
评审的目的是为使程序具有良好的风格，便于阅读。
1. 源程序文档化
1）符号名的命名
符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等等。这些名称应能反映它所代表的实际东西，应有一定的实际意义。例如，表示次数的量用Times，表示总量的量用Total，表示平均值的量用Average，表示和的量用Sum等等。
名称不是越长越好，应当选择精炼的、意义明确的名称。必要时可使用缩写名称，但这时要注意缩写规则要一致，并且要给每一个名称加注释。同时，在一个程序中，一个变量只应用于一种用途。
2）程序的注释
夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。注释绝不是可有可无的。一些正规的程序文本中一注释行的数量占到整个源程序的1/3－1/2，甚至更多。注释分为序言性注释和功能性注释。
序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对子理解程序本身具有引导作用。有些软件开发部门对序言性注释做了明确而严格的规定，要求程序编制者逐项列出。有关项目包括：
- 程序标题；
- 有关本模块功能和目的的说明；
- 主要算法；
- 接口说明（包括调用形式、参数描述、子程序清单）；
- 有关数据描述（重要的变量及其用途、约束或限制条件，以及其他有关信息）；
- 模块位置（在哪一个源文件中，或隶属十哪一个软件包）；
- 开发简历（模块设计者、复审者、复审日期、修改日期及有关说明）等。
功能性注释功能性注释嵌在源程序体中，用于描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样。而不要解释下面怎么做。要点：
- 描述一段程序，而不是每一个语句；
- 用缩进和空行，使程序与注释容易区别；
- 注释要正确。
3）标准的书写格式
视觉组织用空格、空行和移行来实现。恰当地利用空格，可以突出运算的优先性，减少发生编码的错误；自然的程序段之间可用空行隔开；移行也叫做向右缩格，它是指程序中的各行不必都在左端对齐，不必都从第一格起排列，这样做可以使程序分清层次关系。对于选择语句和循环语句，把其中的程序段语句向右做阶梯式移行，使程序的逻辑结构更加清晰。
2. 数据说明
在设计阶段己经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。为了使程序中数据说明更易于理解和维护，必须注意以下几点。
1）数据说明的次序应当规范化
数据说明次序规范化，使数据属性容易查找，也有利于测试、排错和维护。原则上，数据说明的次序与语法无关，其次序是任意的。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。
2）说明语句中变量安排有序化
当多个变量名在一个说明语句中说明时，应当对这些变量按字母的顺序排列。带标号的全程数据也应当按字母的顺序排列。
3）使用注释说明复杂数据结构
如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点。
4）语句结构
在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。
比如：
- 在一行内只写一条语句；
- 程序编写首先应当考虑清晰性；
- 程序要能直截了当地说明程序员的用意；
- 除非对效率有特殊的要求，程序编写要做到清晰第一，效率第二，不要为了追求效率而丧失了清晰性；
- 首先要保证程序正确，然后才要求提高速度，也就是在使程序高速运行时，首先要保证它是正确的；
- 避免使用临时变量而使可读性下降；
- 让编译程序做简单的优化；
- 尽可能使用库函数；
- 避免不必要的转移；
- 尽量采用基本的控制结构来编写程序；
- 避免采用过于复杂的条件测试；
- 尽量减少使用“否定”条件的条件语句；
- 尽可能用通俗易懂的伪码来描述程序的流程，然后再翻译成必须使用的语言；
- 数据结构要有利于程序的简化；
- 程序要模块化，使模块功能尽可能单一化模块间的耦合能够清晰可见；
- 利用信息隐蔽，确保每一个模块的独立性；
- 从数据出发去构造程序；
- 不要修补不好的程序，对不好的程序要重新编写。
3. 输入和输出
输入和输出信息是与用户的使用直接相关的。输入和输出的方式和格式应当尽可能方便用户的使用。一定要避免因设计不当给用户带来的麻烦。因此，在软件需求分析阶段和设计阶段，就应基本确定输入和输出的风格。系统能否被用户接受，有时就取决于输入和输出的风格。输入/输出风格还受到许多其他因素的影响。例如输入/输出设备（如终端的类型、图形设备、数字化转换设备等）、用户的熟练程度，以及通信环境等。不论是批处理的输入/输出方式，还是交互式的输入/输出方式，在设计和程序编码时都应考虑下列原则：
（1）对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性。
（2）检查输入项的各种重要组合的合理性，必要时报告输入状态信息。
（3）使得输入的步骤和操作尽可能简单，并保持简单的输入格式。
（4）输入数据时，应允许使用自由格式输入。
（5）应允许默认值。
（6）输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目。
（7）在交互式输入时，要在屏幕上使用提示符明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息。
（8）当程序设计语言对输入/输出格式有严格要求时，应保持输入格式与输入语句的要求的一致性。
（9）给所有的输出加注解，并设计输出报表格式。
22.2.11 工程设计阶段投资控制
（1）依据招投标文件、承建合同，审核工程计划、设计方案中所说明的工程目标、范围、内容、产品和服务，对可能的投资变化，向业主单位提出监理意见。
（2）对涉及费用的设计变更进行控制，对必要的变更应由三方达成共识，并做工程备忘录。