信息系统软件工程监理控制点及监理方法.docx
《信息系统软件工程监理控制点及监理方法.docx》由会员分享，可在线阅读，更多相关《信息系统软件工程监理控制点及监理方法.docx（24页珍藏版）》请在冰豆网上搜索。
信息系统软件工程监理控制点及监理方法
信息系统软件工程监理控制点及监理方法
1、监理控制目标
应用系统建设监理工作应力求达到以下主要目标:
（1）对软件开发单位、软件实施单位和系统承建单位的行为进行监控，促使开发行为符合国家法律法规、有关政策和相关技术标准，制止开发行为的随意性和盲目性，促使开发进度、质量按计划（合同）实现，力求开发行为合法、科学、合理又经济。
（2）促进用户与软件开发单位、软件实施单位和系统承建单位的有效沟通，使软件开发单位、软件实施单位和系统承建单位能够全面准确了解用户的实际需求，同时用户能及时了解项目的进展情况。
（3）促使软件开发单位、软件实施单位和承建单位为项目运行的全过程建立一套明确、合理、可行的计划或者规程，并利用与之相应的审核、监理机制和手段对其执行过程进行有效控制。
（4）促使系统的关键技术指标在项目实施过程中处于受控状态，及早预测和发现可能影响施工计划的各种因素，及时纠正可能影响系统功能与性能的缺陷。
2、监理控制要点
2.1准备阶段的监理
2.1.1立项阶段的监理工作
立项阶段最终要做的工作就是编制可行性研究报告，目的是:
说明项目的实现在技术、经济和社会条件方面的可行性;评述为了合理地达到开发目标而可能选择的各种方案;说明并论证所选定的方案。
从以下四个方面的进行可研监理设审核：
（1）经济可行性:
进行成本/效益分析。
从经济角度判断系统开发是否“合算”。
（2）技术可行性:
进行技术风险评价。
从建设基础、问题的复杂性等出发，判断系统开发在时间、费用等限制条件下成功的可能性。
（3）法律可行性:
确定系统开发可能导致的任何侵权、妨碍和责任。
（4）方案的选择:
评价系统或产品开发的几个可能的候选方案。
最后给出结论意见。
2.1.2确定招标方式
了解业主需求，协助业主确定招标方式。
根据有关国际组织协议或国内法规以及信息服务项目招标的特点，在实践中确定信息服务招标方式的基本原则是:
（1）如果可以拟定详细的条件，而且服务的性质允许采用招标方式，可采用公开或邀请招标的方式进行。
（2）如果不能确切拟定或最后拟定条件，或采购的服务相当复杂，可采用征求建议书、邀请建议书、两阶段招标、竞争性谈判、设计竞赛等方式。
（3）与其他形式的服务相比，聘用专家提供咨询、研究、监理等服务更侧重对专家知识、技能、经验方面的考虑，故有独特的方式。
在招标方式确定后，协助业主制定招标文件和评标标准，并对招标过程的组织提出建议。
2.1.3审查承建单位资质
采用公开招标方式时，协助业主对投标单位的资质进行审查，采用邀标或其他招标方式时，协助业主单位对候选承建单位进行资质审查。
协助业主单位对承建单位资质进行审查，
1、承建单位的软件企业认定情况、系统集成资质情况等，
2、考察承建单位在以往的开发过程中是否从事过与本项目相关或相似的开发工作，帮助业主单位选择合格的承建单位，减小项目实施的风险。
2.1.4审查承建单位质量管理体系
软件企业所遵循的质量管理体系主要有两种，一种是软件能力成熟度模型（SW-CMM），一种是ISO质量管理体系。
2.1.5监督招标过程
1、开标过程监理
开标应当在招标文件确定的提交投标文件截止时间的同一时间公开进行;开标地点应当为招标文件中预先确定的地点。
开标时，要检查投标文件的密封情况，经确认无误后，由工作人员当众拆封，宣读投标人名称、投标价格和投标文件的其他主要内容。
开标过程应当记录，并存档备查。
2、评标过程监理，
评标委员会由招标人的代表和有关技术、经济等方面的专家组成，成员人数为五人以上单数，其中技术、经济等方面的专家不得少于成员总数的三分之二。
专家应当从事相关领域工作满八年并具有高级职称或者具有同等专业水平，由招标人从国务院有关部门或者省、自治区、直辖市人民政府有关部门提供的专家名册或者招标代理机构的专家库内的相关专业的专家名单中确定;一般招标项目可以采取随机抽取方式，特殊招标项目可以由招标人直接确定。
确认没有与投标人有利害关系的人进入相关项目的评标委员会。
评标委员会成员的名单在中标结果确定前应当保密。
确认没有任何单位和个人非法干预、影响评标的过程和结果。
评标委员会应当按照招标文件确定的评标标准和方法，对投标文件进行评审和比较;设有标底的，应当参考标底。
评标委员会完成评标后，应当向招标人提出书面评标报告，并推荐合格的中标候选人。
招标人根据评标委员会提出的书面评标报告和推荐的中标候选人确定中标人。
招标人也可以授权评标委员会直接确定中标人。
在确定中标人前，“招标人不得与投标人就投标价格、投标方案等实质性内容进行谈判。
评标委员会成员和参与评标的有关工作人员不得透露对投标文件的评审和比较、中标候选人的推荐情况以及与评标有关的其他情况。
3、决标过程监理
中标通知书对招标人和中标人具有法律效力。
中标通知书发出后，招标人改变中标结果的，或者中标人放弃中标项目的，应当依法承担法律责任。
招标人和中标人应当自中标通知书发出之日起三十日内，按照招标文件和中标人的投标文件订立书面合同。
招标人和中标人不得再行订立背离合同实质性内容的其他
协议。
依法必须进行招标的项目，招标人应当自确定中标人之日起十五日内，向有关行政监督部门提交招标投标情况的书面报告。
中标人应当按照合同约定履行义务，完成中标项目。
中标人不得向他人转让中标项目，也不得将中标项目肢解后分别向他人转让。
中标人按照合同约定或者经招标人同意，可以将中标项目的部分非主体、非关键性工作分包给他人完成。
接受分包的人应当具备相应的资格条件，并不得再次分包。
中标人应当就分包项目向招标人负责，接受分包的人就分包项目承担连带责任。
2.1.6合同签订管理
监理工程师应对工程承建、共同承担风险的合同条款、法律条款分别进行仔细的分析解释。
同时也要对合同条款的更换、延期说明、投资变化等事件进行仔细分析。
合同分析和工程检查等工作要同其联系起来。
合同分析是解释双方合同责任的根据。
监理工程师在业主与承建单位订立合同的过程中要按条款逐条分析，如果发现有对业主产生风险较大的条款，要增加相应的抵御条款。
要详细分析哪些条款与业主有关、与承建单位有关、与工程检查有关、与工期有关等，分门别类分析各自责任和相互联系的关联，做到一清二楚，心中有数。
合同评审过程中的考查以下内容，确定以下内容在合同中进行了明确定义;
（1）定义/使用的术语:
（2）保密约定;，
（3）知识产权约定:
（4）双方义务;
（5）合同价款及付款方式;
（6）各阶段工程成果及交付期限，应选取里程碑式的工程成果交付的期限，并在一定程度上把成果和付款计划联系起来;
（7）验收标准和方式/工程的质量要求，应准确细致地描述工程的整体质量和各部分质量，必要时可以用明确的技术指标进行限定;
（8）用户培训需求;
（9）维护期约定，包括维护期长度、维护响应时间、维护方式和维护法用等;
（10）违约责任;
（11）期限和终止;
（12）不可抗力;
（13）变更，包括资金、需求、期限、合向等变更，对变更的范围进行约定，并明确每一种变更以何种方式何种程序处理;对范围外的变更，可注明另行协商并再补签合同;
（14）其他约定，如适用法律、争议解决和双方的其他协作条件等。
将监理意见以合同评审专题报告形式提交业主。
3、分析设计阶段监理
3.1软件项目计划监理的目标
（1）监督承建单位形成软件规模估计文档，以供计划和跟踪软件项目使用。
（2）监督承建单位制定软件项目的活动和约定，并形成文档。
（3）监督和控制软件项目计划的产品和活动与软件的需求规格说明一致。
3.2软件项目计划监理的主要活动
（1）确保软件承建单位在项目软件过程规范约定的基础上制定软件项目计划。
（2）监督承建单位为实施软件工程和管理软件项目制定合理的软件项目计划，包括进行软件规模估计和软件风险分析，建立软件项目组织，确定软件项目生命周期，进行软件项目策划，确定必要的约定。
（3）监督承建单位依据书面规程制定项目的软件项目计划，确认计划内容是否满足标准、规范及合同要求。
（4）审查承建单位编写的项目计划文档，软件项目计划包括:
软件项目的用途、范围、目标和对象，软件开发计划，软件配置管理，软件质量保证，软件框架设计，问题跟踪与排除方法，软件度量。
（5）审查承建单位标明、建立和保持对软件项目的控制所必需的软件工作产品。
（6）审查承建单位依据书面规程估计软件工作产品规模，估计软件项目的工作量和成本，估计项目的关键计算机资源。
（7）监督承建单位依据书面规程制定项目的软件进度计划，分析承建单位制定项目的软件工程设备和支持工具计划的合理性、可行性，分析软件进度计划的合理性。
（8）管理和控制软件计划数据，审查软件项目计划的活动情况。
（9）确保软件项自计划通过正式的评审，在评审后得到技术修改和批准，给出是否符合要求的结论，确定其能否作为软件开发的前提和依据，作为应用软件系统建设进度控制的依据。
3.3软件质量管理体系监理
1、监督应用软件系统建设承建单位根据项目合同和业主应用软件系统需求，制定项目软件工程和管理活动，结合成为密切相关、定义完整的项目软件过程;
2、评估项目软件过程的技术合理性，包括是否符合标准和规范，是否符合项目合同和业主技术要求;
3、项目软件过程文档化，并得到批准;监督和控制承建单位的项目软件过程的状杰，促使承建单位支持和实施项目软件过程，提高软件项目实施的计划性，减少软件项目实施的风险;
4、监督应用软件系统建设承建单位在软件开发过程中按照项目软件过程的规范实施，跟踪、记录和审查软件管理过程活动。
3.4软件质量保证监理的主要内容
1、确保项目遵循书面的承建单位管理策略来实施软件质量保证，承建单位成立了软件质量保证活动的组织;
2、控制承建单位依据书面规程，为软件项目制定软件质量保证计划，保障软件质量保证计划符合项目软件过程的规范要求;
3、参加承建单位的软件质量保证组按照软件质量保证计划进行活动;
4、参加承建单位的软件质量保证组评审软件工程活动，验证软件工程活动与软件项目计划的一致性;
5、参加承建单位软件质量保证组审核指定的软件产品，依据指定的软件标准、规程和合同需求对可交付的软件产品进行评价，验证软件产品与软件项目计划的一致性;
6、控制承建单位依据书面规程，归档和处理软件活动和软件工作产品中的偏差，管理和控制不一致性问题的文档;
7、软件监理人员和业主的软件质量保证人员定期对软件质量保证组的活动和结果进行评审;
8、跟踪和记录软件质量保证活动的情况，审查软件质量保证活动，并给出软件质量保证监理报告。
3.5软件配置管理监理的主要活动
1、确保应用软件系统建设承建单位的配置管理组织和环境按照软件项目计划的要求成立并配备。
2、控制承建单位依据书面规程，为应用软件系统建设项目制定软件配置管理计划。
3、监督承建单位使用审批通过的、文档化的软件配置管理计划作为实施软件配置管理活动的基础，该计划包括:
要执行的活动、活动的进度安排、指定的职责和所需的资源;监督承建单位标识将置于配置管理下的软件工作产品，工作产品包括与过程相关的计划、标准或规程、软件需求、软件设计、软件代码单元、软件测试规程、为软件测试活动建立的软件系统、软件系统产品和编译程序。
4、控制承建单位依据书面规程，对所有配置项/单元的更改请求和问题报告实施初始准备、记录、评审、批准和跟踪。
5、监督承建单位依据书面规程，控制对基线的更改。
监督承建单位依据书面规程，由软件基线库生成软件产品并对其发布进行控制。
监督承建单位依据书面规程，记录配置项/单元的状态。
6、控制承建单位编制软件配置管理报告，证明软件配置管理活动和软件基线库的内容，并提供给业主。
7、监督承建单位依据书面规程，进行软件基线库审核。
进行软件配置管理活动状态的跟踪和记录。
8、定期审查软件配置管理活动和软件配置管理基线，以验证它们与文档定义的一致性。
9、审核软件配置管理活动及其工作产品，并给出软件配置管理监理报告。
3.6需求说明书评审内容
作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其他需求给予评价。
评审的主要内容是:
1、系统定义的目标是否与用户的要求一致;
2、系统需求分析阶段提供的文档资料是否齐全;
3、文档中的所有描述是否完整、清晰、准确反映用户要求:
4、与所有其他系统成分的重要接口是否都已经描述:
5、被开发项目的数据流与数据结构是否足够、确定;
6、所有图表是否清楚，在不补充说明时能否理解;
7、主要功能是否己包括在规定的软件范围之内，是否都已充分说明;
8、软件的行为和它必须处理的信息、必须完成的功能是否一致;
9、设计的约束条件或限制条件是否符合实际;
10、是否考虑了开发的技术风险;
11、是否考虑过软件需求的其他方案_;
12、是否考虑过将来可能会提出的软件需求;
13、是否详细制定了检验标准，它们能否对系统定义是否成功进行确认;
14、有没有遗漏、重复或不一致的地方;
15、用户是否审查了初步的用户手册或原型;
16、项目开发计划中的估算是否受到了影响。
为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。
评审结束应有评审负责人的结论意见及签字。
除承建单位分析员之外，业主单位人员和监理单位都应当参加评审工作。
需求说明书要经过严格评审，一般，评审的结果都包含了一些修改意见，待修改完成后再经评审通过，才可进入设计阶段。
3.7软件分包合同监理的方法
方法1:
定期审查软件分包合同的管理活动。
实施定期审查的主要目的是适当地、及时地掌握软件分包合同管理的软件过程活动。
在满足业主单位需求的前提下，只要有适当的机制来报告异常情况，审查的时间间隔就尽可能长些。
方法2:
根据实际需要随时跟踪和审查软件分包合同的管理活动。
方法3:
评审和（或）审核软件分包合同的管理活动及其产品，并报告结果。
这些评审和（或）审核至少应验证:
1、选择分承建单位的活动。
2、管理软件分包合同的活动。
3、协调主承建单位和分承建单位配置管理的活动。
4、与分承建单位按计划评审的实施情况。
5、确认分包合同达到关键里程碑或阶段完成时的评审情况。
6、对分承建单位软件产品的验收过程。
3.8概要设计说明书评审
3.8.1评审内容
1、可追溯性:
即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有己确定的软件需求，软件每一成分是否可追溯到某一项需求。
2、接口:
即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。
模块是否满足高内聚和低耦合的要求。
模块作用范围是否在其控制范围之内。
3、风险:
即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。
4、实用性:
即确认该软件设计对于需求的解决方案是否实用。
5、技术清晰度:
即确认该软件设计是否以一种易于翻译成代码的形式表达。
6、可维护性:
从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。
7、质量:
即确认该软件设计是否表现出良好的质量特征。
8、各种选择方案:
看是否考虑过其他方案，比较各种选择方案的标准是什么。
9、限制:
评估对该软件的限制是否现实，是否与需求一致。
10、其他具体问题:
对于文档、可测试性、设计过程等进行评估。
3.8.2衡量设计的技术标准
1、设计出来的结构应是分层结构，从而建立软件成分之间的控制。
2、设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件。
3、设计应当既包含数据抽象，也包含过程抽象。
4、设计应当建立具有独立功能特征的模块。
5、设计应当建立能够降低模块与外部环境之间复杂连接的接口。
6、设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。
软件设计过程根据基本的设计原则，使用系统化的方法和完全的设计评审来建立良好的设计。
3.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
所继承设计的已知风险是否已确定和分析？
3.8.4详细设计说明书评审、测试计划评审
序号
检查项
是/不确定/否/不适用
所有单元或过程的目的是否都已文档化？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明实现该单元的关键算法？
是否已列出该单元的调用？
依从性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且各更高级别文档一致？
正确性
是否处理所有条件（>0,=0,<0,switch/case）?
是否存在处理“casenotfound”的条件？
是否正确地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被详细说明？
事都所有该单元的数据结构都被详细说明？
是否所有修改共享数据（或文件）的程序都考虑到了其他程序对该共享数据（或文件）的存取权限？
是否所有逻辑单元、时间标志和同步标志都被定义和初始化？
接口
接口参数在数量、类型和顺序上是否匹配？
是否所有的输入和输出都被正确定义和检查？
是否传递参数序列都被清晰描述？
是否所有参数和控制标志由已描述的单元传递或返回？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度？
性能
是否该单元的所有约束都被详细说明？
可靠性
初始化是否使用到默认值，默认值是否正确？
3.8.5软件编码规范评审
3.8.5.1源程序文档化
1、符号名的命名
符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等等。
这些名称应能反映它所代表的实际东西，应有一定的实际意义。
例如，表示次数的量用Times，表示总量的量用Total，表示平均值的量用Average，表示和的量用Sum等等。
名称不是越长越好，应当选择精炼的、意义明确的名称。
必要时可使用缩写名称，但这时要注意缩写规则要一致，并且要给每一个名称加注释。
同时，在一个程序中，一个变量只应用于一种用途。
2、程序的注释
夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。
注释绝不是可有可无的。
一些正规的程序文本中一注释行的数量占到整个源程序的1/3－1/2，甚至更多。
注释分为序言性注释和功能性注释。
序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对子理解程序本身具有引导作用。
有些软件开发部门对序言性注释做了明确而严格的规定，要求程序编制者逐项列出。
有关项目包括:
程序标题;有关本模块功能和目的的说明;主要算法;接口说明（包括调用形式、参数描述、子程序清单）;有关数据描述（重要的变量及其用途、约束或限制条件，以及其他有关信息）;模块位置（在哪一个源文件中，或隶属十哪一个软件包）;开发简历（模块设计者、复审者、复审日期、修改日期及有关说明）等。
功能性注释功能性注释嵌在源程序体中，用于描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样。
而不要解释下面怎么做。
要点:
描述一段程序，而不是每一个语句;用缩进和空行，使程序与注释容易区别;注释要正确。
3、标准的书写格式
视觉组织用空格、空行和移行来实现。
恰当地利用空格，可以突出运算的优先性，减少发生编码的错误;自然的程序段之间可用空行隔开;移行也叫做向右缩格，它是指程序中的各行不必都在左端对齐，不必都从第一格起排列，这样做可以使程序分清层次关系。
对于选择语句和循环语句，把其中的程序段语句向右做阶梯式移行，使程序的逻辑结构更加清晰。
3.8.5.2数据说明
在设计阶段己经确定了数据结构的组织及其复杂性。
在编写程序时，则需要注意数据说明的风格。
为了使程序中数据说明更易于理解「和维护，必须注意以下几点。
1、数据说明的次序应当规范化
数据说明次序规范化，使数据属性容易查找，也有利于测试、排错和维护。
原则上，数据说明的次序与语法无关，其次序是任意的。
但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。
2、说明语句中变量安排有序化
当多个变量名在一个说明语句中说明时，应当对这些变量按字母
升级会员 