信息系统软件工程分析设计阶段监理控制点及监理方法文档格式.docx
《信息系统软件工程分析设计阶段监理控制点及监理方法文档格式.docx》由会员分享，可在线阅读，更多相关《信息系统软件工程分析设计阶段监理控制点及监理方法文档格式.docx（13页珍藏版）》请在冰豆网上搜索。
8、跟踪和记录软件质量保证活动的情况，审查软件质量保证活动，并给出软件质量保证监理报告。
1.5软件配置管理监理的主要活动
1、确保应用软件系统建设承建单位的配置管理组织和环境按照软件项目计划的要求成立并配备。
2、控制承建单位依据书面规程，为应用软件系统建设项目制定软件配置管理计划。
3、监督承建单位使用审批通过的、文档化的软件配置管理计划作为实施软件配置管理活动的基础，该计划包括:
要执行的活动、活动的进度安排、指定的职责和所需的资源;
监督承建单位标识将置于配置管理下的软件工作产品，工作产品包括与过程相关的计划、标准或规程、软件需求、软件设计、软件代码单元、软件测试规程、为软件测试活动建立的软件系统、软件系统产品和编译程序。
4、控制承建单位依据书面规程，对所有配置项/单元的更改请求和问题报告实施初始准备、记录、评审、批准和跟踪。
5、监督承建单位依据书面规程，控制对基线的更改。
监督承建单位依据书面规程，由软件基线库生成软件产品并对其发布进行控制。
监督承建单位依据书面规程，记录配置项/单元的状态。
6、控制承建单位编制软件配置管理报告，证明软件配置管理活动和软件基线库的内容，并提供给业主。
7、监督承建单位依据书面规程，进行软件基线库审核。
进行软件配置管理活动状态的跟踪和记录。
8、定期审查软件配置管理活动和软件配置管理基线，以验证它们与文档定义的一致性。
9、审核软件配置管理活动及其工作产品，并给出软件配置管理监理报告。
1.6需求说明书评审内容
作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其他需求给予评价。
评审的主要内容是:
1、系统定义的目标是否与用户的要求一致;
2、系统需求分析阶段提供的文档资料是否齐全;
3、文档中的所有描述是否完整、清晰、准确反映用户要求:
4、与所有其他系统成分的重要接口是否都已经描述:
5、被开发项目的数据流与数据结构是否足够、确定;
6、所有图表是否清楚，在不补充说明时能否理解;
7、主要功能是否己包括在规定的软件范围之内，是否都已充分说明;
8、软件的行为和它必须处理的信息、必须完成的功能是否一致;
9、设计的约束条件或限制条件是否符合实际;
10、是否考虑了开发的技术风险;
11、是否考虑过软件需求的其他方案_;
12、是否考虑过将来可能会提出的软件需求;
13、是否详细制定了检验标准，它们能否对系统定义是否成功进行确认;
14、有没有遗漏、重复或不一致的地方;
15、用户是否审查了初步的用户手册或原型;
16、项目开发计划中的估算是否受到了影响。
为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。
评审结束应有评审负责人的结论意见及签字。
除承建单位分析员之外，业主单位人员和监理单位都应当参加评审工作。
需求说明书要经过严格评审，一般，评审的结果都包含了一些修改意见，待修改完成后再经评审通过，才可进入设计阶段。
1.7软件分包合同监理的方法
方法1:
定期审查软件分包合同的管理活动。
实施定期审查的主要目的是适当地、及时地掌握软件分包合同管理的软件过程活动。
在满足业主单位需求的前提下，只要有适当的机制来报告异常情况，审查的时间间隔就尽可能长些。
方法2:
根据实际需要随时跟踪和审查软件分包合同的管理活动。
方法3:
评审和（或）审核软件分包合同的管理活动及其产品，并报告结果。
这些评审和（或）审核至少应验证:
1、选择分承建单位的活动。
2、管理软件分包合同的活动。
3、协调主承建单位和分承建单位配置管理的活动。
4、与分承建单位按计划评审的实施情况。
5、确认分包合同达到关键里程碑或阶段完成时的评审情况。
6、对分承建单位软件产品的验收过程。
1.8概要设计说明书评审
1.8.1评审内容
1、可追溯性:
即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有己确定的软件需求，软件每一成分是否可追溯到某一项需求。
2、接口:
即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。
模块是否满足高内聚和低耦合的要求。
模块作用范围是否在其控制范围之内。
3、风险:
即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。
4、实用性:
即确认该软件设计对于需求的解决方案是否实用。
5、技术清晰度:
即确认该软件设计是否以一种易于翻译成代码的形式表达。
6、可维护性:
从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。
7、质量:
即确认该软件设计是否表现出良好的质量特征。
8、各种选择方案:
看是否考虑过其他方案，比较各种选择方案的标准是什么。
9、限制:
评估对该软件的限制是否现实，是否与需求一致。
10、其他具体问题:
对于文档、可测试性、设计过程等进行评估。
1.8.2衡量设计的技术标准
1、设计出来的结构应是分层结构，从而建立软件成分之间的控制。
2、设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件。
3、设计应当既包含数据抽象，也包含过程抽象。
4、设计应当建立具有独立功能特征的模块。
5、设计应当建立能够降低模块与外部环境之间复杂连接的接口。
6、设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。
软件设计过程根据基本的设计原则，使用系统化的方法和完全的设计评审来建立良好的设计。
1.8.3设计说明书检查表
序号
检查项
是/不确定/否/不适用
清晰性
1
是否所设计的架构，包括数据流、控制流和接口被清楚地表达了？
2
是否所有的假设、约束、策略及依赖都被记录在本文档了？
3
是否定义了总体设计目标？
完整性
4
是否所有以前的TBD（待确定条目）都已经解决了？
5
是否设计已经可以支持本文档中遗留的TBD有可能带来的变更？
6
是否所有的TBD的影响都已经被评估了？
7
是否仍存在可能不可行的设计部分？
8
是否已记录设计时的权衡考虑？
该文件是否包括了权衡选择的标准和不选择其他方案的原因？
依从性
9
是否遵守了项目的文档编写标准？
一致性
10
数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致？
11
该设计是否反映了实际操作环境（硬件、软件、支持软件）？
可行性
12
从进度、预算和技术角度上看该设计是否可行？
13
是否存在错误的、缺少的或不完整的逻辑？
数据使用
14
所有符合数据元素、参数以及对象的概念是否都已文档化？
15
是否还有任何需要的但还没有定义的数据结构，反之亦然？
16
是否已描述最低级别数据元素？
是否已详细说明取值范围？
功能性
17
是否对每一下级模块进行了概要算法说明？
18
所选择的设计和算法能否满足所有的需求？
接口
19
操作界面的设计是否有为用户考虑（入词汇、使用信息和进入的简易）
20
是否已描述界面的功能特性？
21
界面将有利于解决问题吗？
22
是否所有界面都互相一致，与其他模块一致，以及和更高级别文档中的需求一致？
23
是否所有的界面都提供了所需求的信息？
24
是否已说明内部各界面之间的关系？
25
界面的数量和复杂程度是否已减少到最小？
可维护性
26
该设计是否是模块化的？
27
这些模块是否具有高内聚度和低耦合度？
28
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明？
性能
29
主要性能参数是否已被详细说明（如实时、速度要求、磁盘输入/输出接口等）
可靠性
30
该设计能够提供错误监测和恢复？
31
是否矣考虑非正常情况？
32
是否所有错误情况都被完整和准确的说明？
33
该设计是否满足该系统进行集成时所遵守的约定？
易测性
34
是否能够对该系统进行测试、演示、分析、或检查来说明它是满足需求的？
35
该套系统是否能用增量型的方法来测试和集成？
可追溯型
36
是否各部分的设计都能追溯到需求说明书的需求？
37
是否所有的设计决策都能追溯到原来确定的权衡因素？
38
所继承设计的已知风险是否已确定和分析？
1.8.4详细设计说明书评审、测试计划评审
所有单元或过程的目的是否都已文档化？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明实现该单元的关键算法？
是否已列出该单元的调用？
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且各更高级别文档一致？
正确性
是否处理所有条件（>
0,=0,<
0,switch/case）?
是否存在处理“casenotfound”的条件？
是否正确地规定了分支（逻辑没有颠倒）？
是否所有声明的数据都被详细说明？
事都所有该单元的数据结构都被详细说明？
是否所有修改共享数据（或文件）的程序都考虑到了其他程序对该共享数据（或文件）的存取权限？
是否所有逻辑单元、时间标志和同步标志都被定义和初始化？
接口参数在数量、类型和顺序上是否匹配？
是否所有的输入和输出都被正确定义和检查？
是否传递参数序列都被清晰描述？
是否所有参数和控制标志由已描述的单元传递或返回？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
单元是否具有高内聚度和低耦合度？
是否该单元的所有约束都被详细说明？
初始化是否使用到默认值，默认值是否正确？
1.8.5软件编码规范评审
1.8.5.1源程序文档化
1、符号名的命名
符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等等。
这些名称应能反映它所代表的实际东西，应有一定的实际意义。
例如，表示次数的量用Times，表示总量的量用Total，表示平均值的量用Average，表示和的量用Sum等等。
名称不是越长越好，应当选择精炼的、意义明确的名称。
必要时可使用缩写名称，但这时要注意缩写规则要一致，并且要给每一个名称加注释。
同时，在一个程序中，一个变量只应用于一种用途。
2、程序的注释
夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。
注释绝不是可有可无的。
一些正规的程序文本中一注释行的数量占到整个源程序的1/3－1/2，甚至更多。
注释分为序言性注释和功能性注释。
序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对子理解程序本身具有引导作用。
有些软件开发部门对序言性注释做了明确而严格的规定，要求程序编制者逐项列出。
有关项目包括:
程序标题;
有关本模块功能和目的的说明;
主要算法;
接口说明（包括调用形式、参数描述、子程序清单）;
有关数据描述（重要的变量及其用途、约束或限制条件，以及其他有关信息）;
模块位置（在哪一个源文件中，或隶属十哪一个软件包）;
开发简历（模块设计者、复审者、复审日期、修改日期及有关说明）等。
功能性注释功能性注释嵌在源程序体中，用于描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样。
而不要解释下面怎么做。
要点:
描述一段程序，而不是每一个语句;
用缩进和空行，使程序与注释容易区别;
注释要正确。
3、标准的书写格式
视觉组织用空格、空行和移行来实现。
恰当地利用空格，可以突出运算的优先性，减少发生编码的错误;
自然的程序段之间可用空行隔开;
移行也叫做向右缩格，它是指程序中的各行不必都在左端对齐，不必都从第一格起排列，这样做可以使程序分清层次关系。
对于选择语句和循环语句，把其中的程序段语句向右做阶梯式移行，使程序的逻辑结构更加清晰。
1.8.5.2数据说明
在设计阶段己经确定了数据结构的组织及其复杂性。
在编写程序时，则需要注意数据说明的风格。
为了使程序中数据说明更易于理解「和维护，必须注意以下几点。
1、数据说明的次序应当规范化
数据说明次序规范化，使数据属性容易查找，也有利于测试、排错和维护。
原则上，数据说明的次序与语法无关，其次序是任意的。
但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。
2、说明语句中变量安排有序化
当多个变量名在一个说明语句中说明时，应当对这些变量按字母的顺序排列。
带标号的全程数据也应当按字母的顺序排列。
3、使用注释说明复杂数据结构
如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点。
4、语句结构
在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。
语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。
1.8.5.3输入和输出
1、对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性。
2、检查输入项的各种重要组合的合理性，必要时报告输入状态信息。
3、使得输入的步骤和操作尽可能简单，并保持简单的输入格式。
4、输入数据时，_应允许使用自由格式输入。
5、应允许默认值。
6、输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目。
7、在交互式输入时，要在屏幕上使用提示符明确提示交互输入的请求，指明可使用选择项的种类和取值范围。
同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息。
8、当程序设计语言对输入/输出格式有严格要求时，应保持输入格式与输入语句的
要求的一致性。
9、给所有的输出加注解，并设计输出报表格式。
升级会员 