【说明】<br />某监理单位承担了某市政府机关的办公应用系统建设工程的监理工作。经过..

2010年上半年下午试卷案例

第 3 题

知识点	承建单位监理单位建设单位设计阶段需求分析招标分析设计阶段评审业务需求政府

【说明】
某监理单位承担了某市政府机关的办公应用系统建设工程的监理工作。经过公开招标，建设单位选择A公司作为工程的承建单位，目前项目己经进入分析设计阶段。A公司完成了系统的需求分析工作。按照合同约定，建设单位组织专家组对需求规格说明书进行评审，专家组形成以下主要评审意见：
(1) 需求规格说明书未能完全覆盖用户的业务需求；
(2) 需求规格书明书存在多处前后描述不一致的情况；
(3) 需求规格说明书中部分功能定义不明确，不能满足设计工作需要；
(4) 承建单位须对需求规格说明书进行补充完善后，再次提交评审。

问题：3.1 一般情况下，需求评审专家组的人员组成包括、、、。
供选择的答案：
①建设单位代表 ②承建单位代表 ③监理单位代表
④用户单位代表 ⑤第三方测试机构代表⑥行业专家
⑦信息化领域专家

问题：3.2 针对本次需求评审的结果，监理应重点开展哪五项工作？

问题：3.3 分析设计阶段项目建设成果主要包括。
供选择的答案：
①立项建议书 ②概要设计规格说明③软件质量保证计划
④项目开发工作计划⑤可行性分析报告 ⑥详细设计规格说明
⑦测试计划 ⑧测试报告 ⑨软件配置管理计划

知识点讲解

· 承建单位

· 监理单位

· 建设单位

· 设计阶段

· 需求分析

· 招标

· 分析设计阶段

· 评审

· 业务需求

· 政府

承建单位

负责具体实施的承建方应该有自己的项目管理，监理方代表项目建设方对承建方提出的工程计划进行监督和协调，对一些关键点进行控制。这些关键点主要属于进度、资金及质量的范畴，但不能涉及管理细节。工程项目管理主要以承建方为主，并强调在项目中组织并制定相关计划。

在一个大型信息系统工程项目的建设中，承建方可能有多个，比如硬件提供商、软件开发商和系统集成商等。而在市场竞争日益激烈的今天，专业化能促进生产效率和提高生产质量，故而承建方常常分解成一定的层次结构，如总承包商和分包商等，从而使一部分人或企业专注于项目管理的科学化。

从市场的角度看，总承包商既是买方又是卖方；从工程合同的角度来讲，他既要对建设方负全部法律责任，又要根据分包合同对分包商进行管理并履行义务，所有的主合同都会限定总承包商可以分包的最大范围。总承包商只能将某些具体的工程施工分包给分包商，但不能分包合同的责任和义务。总承包商不能期望通过分包逃避自己在合同中的法律和经济责任。

作为分包商，一般情况下不与建设方直接发生合同关系。分包商只接受总承包商的统筹安排和调度，它只对总承包商承担分包合同内规定的责任并履行规定的义务。

如果总承包商违反分包合同，则应该赔偿分包商的经济损失；分包商违反分包合同并造成建设方对总承包商的罚款或制裁，则分包商应该赔偿总承包商的损失。分包商是从总承包商处按分包合同索回其应得部分的，如果总承包商无力偿还债务，则分包商也同样蒙受损失，因此分包商的利益通常与总承包商的利益密切相关。

监理单位

项目监理方服务于信息系统建设合同的建设方与承建方。接受建设方委托后，监理方作为工程承包合同的监督者，所执行的原则是使工程承包合同成为“平等条约”；作为工程承包合同管理和工程款支付的签认者，所执行的原则是等价交换。因此监理方是为双方的利益服务的，而不仅仅为委托方服务。

根据工程监理的深入程度不同，信息系统工程监理可分为如下三种。

（1）咨询式监理。只解答用户方就企业信息化过程中提出的问题，其性质类似于业务咨询或方案咨询。这种方式费用最少，监理方的责任最轻，适合于对信息化有较好把握，并且技术力量较强的用户方采用。

（2）里程碑式监理。将信息系统的建设划分为若干个阶段，在每一个阶段结束都设置一个里程碑，在里程碑到来时通知监理方进行审查或测试。一般来讲，这种方式比咨询式监理的费用要多，监理方也要承担一定的责任。不过，里程碑的确定需要承建方的参与，或者说监理合同的确立需要开发方的参与，否则就会因对里程碑的界定不同而引起纠纷。

（3）全程式监理。一种复杂的监理方式，不但要求对系统建设过程中的里程碑进行审查，还应该派相应人员全程跟踪并收集系统开发过程中的信息，不断评估承建方的开发质量和效果。这种方式费用最高，监理方的责任也最大，适合于那些对信息系统的开发不太了解且技术力量偏弱的用户采用。

监理单位的主要作用如下。

（1）信息系统工程监理可以帮助建设单位更合理地保证工程的质量、进度和投资，并合理且客观地处理好它们之间的关系。监理由独立的第三方依据相关技术标准来对工程建设进行监督，这样对信息系统工程的建设质量更能起到保驾护航的作用。在项目建设全过程中，监理单位要依据国家有关法律和相关技术标准，遵循守法、公平、公正、独立的原则，对信息系统建设的过程进行监督和控制。即在确保质量、安全和有效性的前提下，合理安排进度和投资。监理单位要帮助建设单位对工程有关方面控制进行再控制，对承建单位项目控制过程进行监督管理。

（2）在信息系统工程建设中，建设单位和承建单位有许多问题存在争议，双方都希望由第三方在工程的立项、设计、实施、验收及维护等各个阶段的效果都给予公正、恰当且权威的评价，这就需要监理单位来协调和保障这些工作的顺利进行。

（3）由于建设单位在信息技术等相关领域普遍存在缺乏人才和经验不足的问题，实践证明建设单位自行管理对于提高项目投资的效益和建设水平是无益的。通过第三方的专业服务，帮助建设单位对项目实施控制，并对建设单位和承建单位都做出约束，是监理作用一个重要体现。

建设单位

建设方是建设项目的主要投资者，有时也是项目的最终使用者，是在工程建设阶段的全权代表，建设项目的经济效益，如投资额度、工程质量、投入使用时间和使用寿命直接关系着建设方的切身利益。虽然承建方、监理方与建设方是平等的市场主体，但由于建设方是投资方，掌握着项目的最终资源——决定了其他方为从属地位，所以说建设方对工程项目管理起着主导性作用。建设方加强和改善对项目的管理是从根本上实现项目按质如期完成的最有效的途径之一。

作为项目管理集体中的主要负责人，建设方的作用是阐明本项目的目标并确认各项工作的轻重缓急，组织协调参与各方为此目标而通力合作，在管理决策过程中做出决策。但在某些具体的项目管理事务中，建设方并不总是处于主要负责人的地位，还要作为裁判、支持者、服务员及督促员的角色。

设计阶段

设计阶段监理进行质量控制的要点如下。

（1）了解建设单位的建设需求和对信息系统安全性的要求，协助建设单位制定项目质量目标规划和安全目标规划。

（2）对各种设计文件提出设计质量标准。

（3）进行设计过程跟踪，及时发现质量问题，并及时与承建单位协调解决。审查阶段性成果，并提出监理意见。审查承建单位提交的总体设计方案，审查承建单位对关键部位的测试方案。

（4）协助承建单位建立质量保障体系。

（5）协助承建单位完善现场质量管理制度。

（6）组织设计文件及设计方案交底会，制定质量要求标准。

需求分析

软件需求分析监理的主要任务和目的是对软件需求分析的相关内容（重点是工程需求、功能需求、性能需求和设计约束等）、需求分析过程、需求分析活动及文档格式进行审查，确认是否满足要求，并确定其可否作为软件开发的前提和依据。

（1）参与用户需求调研，尤其是关键业务及有甲乙双方决策人物参与的大型交流会等。

（2）组织有关单位参加《需求规格说明书》技术联合评审会议，并根据国家相关标准、软件工程理论、用户需求及工程建设合同等进行审查并提出监理意见。

（3）根据项目管理的理论，审核承建单位递交的《项目开发计划》。审核的重点是项目参与人员的技术工作背景是否适应本项目、工作分配及进度计划是否合理，以及软件开发风险因素分析、风险防范措施是否到位等。

（4）审核承建单位提交的软件开发的质量保证及配置管理计划等软件生存周期支持过程的文档。

（5）审核承建单位针对本工程投入的软硬件资源是否满足工程需要并及时到位。

（6）审核承建单位在开发过程中使用的软件工具的合法性。

（7）主持监理例会，做好监理日记，定期将项目进展情况及发现的问题汇总，并以项目月报的形式向项目建设单位做书面汇报。

（8）做好项目往来文档的整理及存档工作。

在需求分析阶段，监理工作的重点是对软件需求规格说明书和项目开发计划的审核。

招标

下列工程建设项目包括项目的勘察、设计、施工、监理，以及与工程建设有关的重要设备、材料等的采购，因此必须进行招标。

（1）大型基础设施、公用事业等关系社会公共利益、公众安全的项目。

（2）全部或部分使用国有资金投资或者国家融资的项目。

（3）使用国际组织或者外国政府贷款、援助资金的项目。

任何单位和个人不得将依法必须进行招标的项目化整为零或者以其他任何方式规避招标。招标投标活动应当遵循公开、公平、公正和诚实信用的原则。必须进行招标的项目，其招标投标活动不受地区或者部门的限制。任何单位和个人不得违法限制或者排斥本地区、本系统以外的法人或其他组织参加投标，不得以任何方式非法干涉招标投标活动。

招标分为公开招标和邀请招标。公开招标是指招标人以招标公告的方式邀请不特定的法人或者其他组织投标。邀请招标是指招标人以投标邀请书的方式邀请特定的法人或者其他组织投标。国务院发展计划部门确定的国家重点项目和省、自治区、直辖市人民政府确定的地方重点项目不适宜公开招标的，经国务院发展计划部门或者省、自治区、直辖市人民政府批准，可以进行邀请招标。

招标代理机构

招标人有权自行选择招标代理机构，委托其办理招标事宜。任何单位和个人不得以任何方式为招标人指定招标代理机构。招标人具有编制招标文件和组织评标能力的，可以自行办理招标事宜。任何单位和个人不得强制其委托招标代理机构办理招标事宜。依法必须进行招标的项目，招标人自行办理招标事宜的，应当向有关行政监督部门备案。

招标代理机构是依法设立、从事招标代理业务并提供相关服务的社会中介组织。招标代理机构应当具备下列条件。

（1）有从事招标代理业务的营业场所和相应资金。

（2）有能够编制招标文件和组织评标的相应专业力量。

（3）有符合规定条件，可以作为评标委员会成员人选的技术、经济等方面的专家库。

从事工程建设项目招标代理业务的招标代理机构，其资格由国务院或者省、自治区、直辖市人民政府的建设行政主管部门认定。具体办法由国务院建设行政主管部门会同国务院有关部门制定。从事其他招标代理业务的招标代理机构，其资格认定的主管部门由国务院规定。

招标代理机构与行政机关和其他国家机关不得存在隶属关系或者其他利益关系。招标代理机构应当在招标人委托的范围内办理招标事宜。

招标公告

招标人采用公开招标方式的，应当发布招标公告。依法必须进行招标的项目的招标公告，应当通过国家指定的报刊、信息网络或者其他媒介发布。招标公告应当载明招标人的名称和地址、招标项目的性质、数量、实施地点和时间，以及获取招标文件的办法等事项。

招标人采用邀请招标方式的，应当向3个以上具备承担招标项目的能力、资信良好的特定法人或者其他组织发出投标邀请书。投标邀请书应当载明的事项与招标公告相同。

招标人可以根据招标项目本身的要求，在招标公告或者投标邀请书中要求潜在投标人提供有关资质证明文件和业绩情况，并对潜在投标人进行资格审查。国家对投标人的资格条件有规定的，依照其规定。招标人不得以不合理的条件限制或者排斥潜在投标人，不得对潜在投标人给予歧视待遇。

招标文件

招标人应当根据招标项目的特点和需要编制招标文件。招标文件应当包括招标项目的技术要求、对投标人资格审查的标准、投标报价要求和评标标准等所有实质性要求和条件，以及拟签订合同的主要条款。

国家对招标项目的技术、标准有规定的，招标人应当按照其规定在招标文件中提出相应要求。招标项目需要划分标段、确定工期的，招标人应当合理划分标段、确定工期，并在招标文件中载明。招标文件不得要求或者标明特定的生产供应以及含有倾向或者排斥潜在投标人的其他内容。

招标人根据招标项目的具体情况，可以组织潜在投标人踏勘项目现场。招标人不得向他人透露已获取招标文件的潜在投标人的名称、数量，以及可能影响公平竞争的有关招标投标的其他情况。招标人设有标底的，标底必须保密。

招标人对已发出的招标文件进行必要的澄清或者修改的，应当在招标文件要求提交投标文件截止时间至少15日前，以书面形式通知所有招标文件收受人。该澄清或者修改的内容为招标文件的组成部分。

招标人应当确定投标人编制投标文件所需要的合理时间。但是，依法必须进行招标的项目，自招标文件开始发出之日起至投标人提交投标文件截止之日止，最短不得少于20日。

分析设计阶段

分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、概要设计说明书评测、详细设计说明书评测以及软件编码规范评测等。下述章节将详细论述。

需求说明书评测

由于软件应用系统针对的行业广泛，因此在需求分析阶段可能存在着承建单位对业主单位的业务需求理解不全面、不准确的情况，常发生承建单位认为某一个业务功能的实现非常简单，而实际上业主单位业务标准的要求却很复杂的情况。在这种情况下，如果不通过评测进行相关的质量控制，往往造成承建单位按照自己的理解进行开发。如果不进行评测，或者评测之后没有充分发现问题，则给系统造成重大隐患，或者造成返工与延期。

因此，在此阶段评测的工作重点是与承建单位的分析人员、设计人员一起对需求说明书进行审查，并协调业主单位完成需求说明书的评审确认。

什么样的需求说明书是良好的，需求说明书编写应该遵照怎样的框架，针对需求说明书的评测有哪些主要内容等，这些在下述章节将详细论述。

. 编制良好的需求说明书8条原则。

1979年由Balzer和Goldman提出了作出良好规格说明的8条原则。

原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”。

原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。

原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其他系统元素交互的方式。

原则4：规格说明必须包括系统运行的环境。

原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。

原则6：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。

原则7：规格说明必须容许不完备性并允许扩充。

原则8：规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规格说明应被松散地构造（即耦合），以便能够很容易地加入和删去一些段落。

尽管Balzer和Goldman提出的这8条原则主要用于基于形式化规格说明语言之上的需求定义的完备性，但这些原则对于其他各种形式的规格说明都适用。当然要结合实际来应用上述的原则。

. 需求说明书的框架。

需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。如下表中列出了需求说明书的框架。

需求说明书的框架

. 需求说明书评测内容。

需求说明书评测作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性，以及其他需求给予评测。评测的主要内容是：

①系统定义的目标是否与用户的要求一致；

②系统需求分析阶段提供的文档资料是否齐全；

③文档中的所有描述是否完整、清晰，准确地反映用户要求；

④与所有其他系统成份的重要接口是否都已经描述；

⑤被开发项目的数据流与数据结构是否足够、确定；

⑥所有图表是否清楚，在不补充说明时能否理解；

⑦主要功能是否已包括在规定的软件范围之内，是否都已充分说明；

⑧软件的行为和它必须处理的信息、必须完成的功能是否一致；

⑨设计的约束条件或限制条件是否符合实际；

⑩是否考虑了开发的技术风险；

?是否考虑过软件需求的其他方案；

?是否考虑过将来可能会提出的软件需求；

?是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；

?有没有遗漏、重复或不一致的地方；

?用户是否审查了初步的用户手册或原型；

?项目开发计划中的估算是否受到了影响。

为保证软件需求定义的质量，评测应由专门指定的人员负责，并按规程严格进行。评审结束，应有评审负责人的结论意见及签字。除承建单位分析员之外，业主单位人员和测试单位都应当参加评测工作。需求说明书要经过严格评测，一般，评测的结果都包括了一些修改意见，待修改完成后再经评测，才可进入设计阶段。根据上述讨论的评测内容，可以制定需求说明书评测规范，如下表所示。

填表说明：Y—是，TBD—不确定，N—否，NA—不适用。

需求说明书评测规范

在需求说明书评测结束后，测试单位应将评测意见以专题报告的形式提交业主单位。

概要设计说明书评测

. 设计说明书的框架。如下表所示为软件设计规格说明的大纲。

软件设计规格说明大纲

软件设计的最终目标是要取得最佳方案。“最佳”是指在所有候选方案中，就节省开发费用，降低资源消耗，缩短开发时间的条件，选择能够赢得较高的生产率、较高的可靠性和可维护性的方案。在整个设计的过程中，各个时期的设计结果需要经过一系列设计质量的评测，以便及时发现和解决在软件设计中出现的问题，防止把问题遗留到开发的后期阶段，造成后患。

. 概要设计说明书评测的内容。

①可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有已确定的软件需求，软件每一成份是否可追溯到某一项需求。

②接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚和低耦合的要求。模块作用范围是否在其控制范围之内。

③风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。

④实用性：即确认该软件设计对于需求的解决方案是否实用。

⑤技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达。

⑥可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。

⑦质量：即确认该软件设计是否表现出良好的质量特征。

⑧各种选择方案：看是否考虑过其他方案，比较各种选择方案的标准是什么。

⑨限制：评估对该软件的限制是否现实，是否与需求一致。

⑩其他具体问题：对于文档、可测试性、设计过程等进行评估。

在这里需要特别注意：软件系统的一些外部特性的设计，例如软件的功能、一部分性能以及用户的使用特性等，在软件需求分析阶段就已经开始。这些问题的解决，多少带有一些“怎么做”的性质，因此有人称之为软件的外部设计。

为评测设计是否达到目标，必须建立衡量设计的技术标准。如下：

①设计出来的结构应是分层结构，从而建立软件成分之间的控制。

②设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件。

③设计应当既包含数据抽象，也包含过程抽象。

④设计应当建立具有独立功能特征的模块。

⑤设计应当建立能够降低模块与外部环境之间复杂连接的接口。

⑥设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。

根据上述讨论的评测内容以及评测标准，可以建立概要设计说明书评测规范，如下表所示。

填表说明：Y—是，TBD—不确定，N—否，NA—不适用。

概要设计说明书评测规范

详细设计说明书评测

详细设计说明书的评测标准和评测内容与概要设计说明书基本相同，这里不再赘述。如下表所示为详细设计说明书评测规范。

填表说明：Y—是，TBD—不确定，N—否，NA—不适用。

详细设计说明书评测规范

软件编码规范评测

程序实际上也是一种供人阅读的文章，有一个文章的风格问题。程序良好的风格表现在源程序文档化、数据说明的方法、语句结构和输入/输出方法这四个方面，软件编码规范评测也是围绕这四个方面展开。下面分别论述评测内容以及相应的评测标准。

. 源程序文档化。

①符号名的命名。符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。这些名字应能反映它所代表的实际东西，应有一定实际意义。例如，表示次数的量用Times，表示总量的用Total，表示平均值的用Average，表示和的量用Sum等。

名字不是越长越好，应当选择精炼的、意义明确的名字。必要时可使用缩写名字，但这时要注意缩写规则要一致，并且要给每一个名字加注释。同时，在一个程序中，一个变量只应用于一种用途。

②程序的注释。夹在程序中的注释是程序员日后与程序读者之间通信的重要手段。注释绝不是可有可无的。一些正规的程序文本中，注释行的数量占到整个源程序的1/3~1/2，甚至更多。注释分为序言性注释和功能性注释。

序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。有些软件开发部门对序言性注释做了明确而严格的规定，要求程序编制者逐项列出。有关项目包括：程序标题；有关本模块功能和目的的说明；主要算法；接口说明：包括调用形式，参数描述，子程序清单；有关数据描述：重要的变量及其用途，约束或限制条件，以及其他有关信息；模块位置：在哪一个源文件中，或隶属于哪一个软件包；开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。

功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样。而不要解释下面怎么做。要点：描述一段程序，而不是每一个语句；用缩进和空行，使程序与注释容易区别；注释要正确。

③标准的书写格式。视觉组织用空格、空行和移行来实现。恰当地利用空格，可以突出运算的优先性，减少编码的错误；自然的程序段之间可用空行隔开；移行也叫做向右缩格。它是指程序中的各行不必都在左端对齐，都从第一格起排列，这样做使程序完全分不清层次关系。对于选择语句和循环语句，把其中的程序段语句向右作阶梯式移行。使程序的逻辑结构更加清晰。

. 数据说明。

在设计阶段已经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。为了使程序中数据说明更易于理解和维护，必须注意以下几点。

①数据说明的次序应当规范化。数据说明次序规范化，使数据属性容易查找，也有利于测试，排错和维护。原则上，数据说明的次序与语法无关，其次序是任意的。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。

②说明语句中变量安排有序化。当多个变量名在一个说明语句中说明时，应当对这些变量按字母的顺序排列。带标号的全程数据也应当按字母的顺序排列。

③使用注释说明复杂数据结构。如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点。

. 语句结构。

在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。

比如：在一行内只写一条语句；程序编写首先应当考虑清晰性；程序要能直截了当地说明程序员的用意；除非对效率有特殊的要求，程序编写要做到清晰第一，效率第二，不要为了追求效率而丧失了清晰性；首先要保证程序正确，然后才要求提高速度，反过来说，在使程序高速运行时，首先要保证它是正确的；避免使用临时变量而使可读性下降；对编译程序做简单的优化；尽可能使用库函数；避免不必要的转移；尽量采用基本的控制结构来编写程序；避免采用过于复杂的条件测试；尽量减少使用“否定”条件的条件语句；尽可能用通俗易懂的伪码来描述程序的流程，然后再翻译成必须使用的语言；数据结构要有利于程序的简化；程序要模块化，使模块功能尽可能单一化，模块间的耦合能够清晰可见；利用信息隐蔽，确保每一个模块的独立性；从数据出发去构造程序；不要修补不好的程序，要重新编写。

. 输入和输出

输入和输出信息是与用户的使用直接相关的。输入和输出的方式和格式应当尽可能方便用户的使用。一定要避免因设计不当给用户带来的麻烦。因此，在软件需求分析阶段和设计阶段，就应基本确定输入和输出的风格。系统能否被用户接受，有时就取决于输入和输出的风格。输入/输出风格还受到许多其他因素的影响。如输入/输出设备（终端的类型，图形设备，数字化转换设备等）、用户的熟练程度以及通信环境等。不论是批处理的输入/输出方式，还是交互式的输入/输出方式，在设计和程序编码时都应考虑下列原则。

①对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性；

②检查输入项的各种重要组合的合理性，必要时报告输入状态信息；

③使输入的步骤和操作尽可能简单，并保持简单的输入格式；

④输入数据时，应允许使用自由格式输入；

⑤应允许缺省值；

⑥输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；

⑦在交互式输入时，要在屏幕上使用提示符，明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息；

⑧当程序设计语言对输入/输出格式有严格要求时，应保持输入格式与输入语句要求的一致性；

⑨给所有的输出加注解，并设计输出报表格式。

评审

对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等都一一进行评审。

业务需求

网络系统是为一个集体提供服务的，对于该集体内的不同用户，需要收集特定的业务信息，包括以下内容。

（1）确定结构组织。业务需求的第一步就是获取组织结构图，了解集体中的岗位设置及岗位职责。

（2）确定关键时间点。对于大型项目，必须制订严格的项目实施计划，确定各个阶段关键的时间点。

（3）确定网络投资规模。在整个网络的设计和实施中，费用是一个主要考虑的因素。

（4）确定业务活动。主要通过对业务的分析，形成各类业务的网络需求，主要包括最大用户数、并发用户数、峰值带宽和正常带宽等。

（5）预测增长率。通过对网络发展趋势的分析，明确网络的伸缩性需求。

（6）确定网络的可靠性和可用性。网络设计人员在进行需求分析的过程中，首先应获取行业的网络可靠性和可用性标准，并根据标准与用户进行交流，确定特殊的要求。

（7）确定Web站点和Internet连接。

（8）确定网络的安全性。

（9）确定远程接入方式。

政府

政府信息系统以电子政务为主要形式，是指政府机构在其管理和服务职能中运用现代网络技术打破传统行政机关的时间、空间和部门分隔的制约，使各级政府的各项监管更加严密，服务更加便捷，涉及政府机关、各团体、企业和社会公众，主要包括机关办公政务网、办公政务资源网、公众信息网和办公政务信息资源数据库几个部分。

（1）安全级别高。政务信息数据中，有些关乎国家、政府部门、地方政策和利益，比个人或商务信息更为敏感；有些属于大规模的基础设施，比如档案、城建数据；有些具有服务特性，比如医保、社保、公积金、房屋交易等信息；加之电子政务行使政府职能的特点易导致政府信息系统受到各种攻击，包括黑客组织、犯罪集团和信息战时期的信息对抗等国家行为的攻击，因此，其安全问题尤其是数据安全应被重点关注。

（2）业务的不间断运维需求高。政府信息系统面向社会提供外部服务，如出入境审批系统、身份证申领系统等，都必须在故障出现后以最短的时间恢复业务运行，否则导致业务受理停止，大量人员等待，大量紧急任务无法处理，影响政府办事效率和形象。

（3）例行运维亟须加强。我国政府部分信息系统存在管理松散，制度不严明，执行乏力现象，包括内部信息外泄，个人下载或运行游戏、炒股、聊天、视频软件，甚至非法修改IP地址，卸载杀毒软件，不仅严重违反纪律，更易影响到关键应用的性能质量，因此，日常运维管理亟须加强。

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5