问答题
电子政务是指政府机构利用信息化手段来实现政府职能。
某市房地产交易网站是市建设委员会实施电子政务的门户，网站包括以下栏目：项目公示、业务办理、信息发布、通知公告、政策法规、房地产经纪、在线答疑等，其中业务办理栏目中又包括申办预售许可、期房网上签约、申请预售登记、权属登记申请、现房网上签约、经纪机构管理、评估行业管理等项目，多数的业务办理项目需要管理部门多级审批。
某市房地产交易网站是市建设委员会实施电子政务的门户，网站包括以下栏目：项目公示、业务办理、信息发布、通知公告、政策法规、房地产经纪、在线答疑等，其中业务办理栏目中又包括申办预售许可、期房网上签约、申请预售登记、权属登记申请、现房网上签约、经纪机构管理、评估行业管理等项目，多数的业务办理项目需要管理部门多级审批。
问答题
一般而言，电子政务业务分为3个领域，电子政务业务模型如图所示(箭头表示信息的流向)。请在下图(1)、(2)、(3)空中填写恰当的内容。
【正确答案】(1)政府办公自动化(或办公自动化系统)
(2)政务信息查询(或政务信息发布系统)
(3)公共政务办公(或政务业务办理系统)
【答案解析】
问答题
电子政务根据其服务的对象不同，基本上可以分为4种模式，即G2G、G2B、G2C、G2E。请根据本题中房地产交易网站的栏目内容，说明该市建设委员会的电子政务系统包括了哪些模式?为什么?
【正确答案】G2B，栏目中有申办预售许可、申请预售登记等，针对房地产开发商企业。
G2C，栏目中有权属登记申请等，主要是针对购房个人。
G2E，因为题目中指出多数业务办理项目需要政府主管部门多级审批，所以系统后台还包括办公自动化系统。
【答案解析】
问答题
本题中的电子政务项目在进行需求分析时，系统分析师需要有效地获取需求，进行需求建模。需求建模包括域建模、用例建模、组件和服务建模、性能建模等。请用300字以内文字分别简要叙述什么是用例建模、组件和服务建模、性能建模。
【正确答案】用例建模描述各种参与者(人和其他系统)和系统之间的主要交互。用例建模可以描述利益相关者(如用户和维护人员)所看到的系统行为。
组件建模确定系统的子系统、模块和组件结构，为予系统、模块分配需求和职责，每个组件元素作为一个自包含的单元，用于开发、部署和执行。服务建模提供了通用的应用程序，并将应用程序定义为一组抽象服务接口。
性能建模是对系统的性能进行度量，为每个组件确定性能指标。包括执行时间、资源使用、开发复杂性、维护复杂性等质量属性。
【答案解析】
问答题
系统分析师必须能够与具有不同背景的利益相关者(如政府各个部门、房地产开发企业、购房者等)进行沟通交流，以提取和细化需求，并向这些利益相关者描述系统的体系结构。请用50字以内文字简要叙述常用的沟通交流技巧。
【正确答案】调查、访谈、演示、组交互(会议)、书面交流(电子邮件)等。
【答案解析】[解析] 电子政务是指政府机构利用信息化手段，实现各类政府职能。其核心是：应用信息技术，提高政府事务处理的信息流效率，改善政府组织和公共管理。
[问题1]
根据政府机构的业务形态来看，通常，电子政务主要包括以下3个应用领域。
①政务信息查询：面向社会公众和企业组织，为其提供政策、法规、条例和流程的查询服务。
②公共政务办公：借助互联网实现政府机构的对外办公，如申请、申报等，提高政府的运作效率，增加透明度。
③政府办公自动化：以信息化手段提高政府机构内部办公的效率，如公文报送、信息通知和信息查询等。
其业务模型如下图表示。
在图中，社会公众和企业主要通过政务信息查询，以及公共政务办公与电子政务平台建立沟通，相关事务处理请求通过办公自动化系统中转给政府工作人员，政府工作人员可以通过办公自动化系统进行政务处理及对政务信息查询系统的更新。通过对这一典型业务模型的分析，可以看出在电子政务系统中主要存在3种信息流。
①政务办公信息流：主要存在于政府机构内部办公的过程中。
②公共事务信息流：主要存在于政府机构对外办公的过程中。
③政务咨询信息流：主要存在于社会公众和企业查询相关信息的过程中。
[问题2]
第2个问题考查电子政务业务的分类，这是大家都知道的内容了：政府对政府、政府对公务员、政府对企业、政府对公众。根据这些含义，对比试题描述中的功能，逐个划分就可以了。
[问题3]
第3个问题考查域建模、用例建模、组件和服务建模、性能建模的概念。
域建模是指为问题域创建相应的模型并且把它划分为若干个内聚组的过程。域模型是一种用于理解问题域的工具。要构造域模型，必须完成下列工作：
①标识并确定参与者(实体)及其操作(活动)的特征。
②标识管理操作(规则)的策略。
③收集有关实现这些操作、来自这些操作或者记录这些操作(构件/数据)的信息。
④将相关的要素划分为子域。
⑤确定结果域(核心的/通用的/外部的)及它们之间交互的特征。
用例模型描述了各种参与者(人和其他系统)和要分析的系统之间的主要交互。用例应该说明系统如何支持域和业务流程模型中的业务流程。用例模型应该将系统放到上下文环境中，显示系统和外部参与者之间的边界，并描述系统和参与者之间的关键交互。用例建模可以描述利益相关者(如用户和维护人员)所看到的系统行为。
用例建模建立反映系统行为的动态模型，用例模型描述了各种参与者和要分析的系统之间的主要交互。
组件模型为子系统、模块和组件的层次结构分配需求和职责。服务模型将应用程序定义为一组位于外部边界(用例)、架构层之间的抽象服务接口，并且提供了通用的应用程序和基础结构(安全、日志记录、配置等)。
性能建模是通过各种各样的方式来度量性能。必须考虑性能建模过程中其他的几个方面：
①构建和部署应用程序的速度如何?
②构建、维护和运行需要多少花费?
③该应用程序能在多大程度上满足其需求?
④对于必须使用该应用程序的人来说，需要为其付出多大的开销?
⑤该应用程序会对其他应用程序和基础结构产生怎样的影响?
关于这些问题(和无数的其他问题，这取决于具体情况)的答案，对一个成功的应用程序来说是至关重要的，并且通常称其为应用程序在架构上的质量。对这些质量进行建模是很困难的，甚至比性能的标准质量更困难。
[问题4]
第4个问题考查获得需求的沟通与交流技巧，这是经常考查的一个内容。
①用户访谈。用户访谈是最基本的一种需求捕获手段，其形式包括结构化和非结构化两种，结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。
②用户调查。用户访谈时最大的难处在于很多关键的人员时间有限，不容易安排过多的时间；而且客户面经常较广，不可能一一访谈。因此，我们就需要借助“用户调查”这一方法，通过精心设计要问的问题，然后下发到相关的人员手里，让他们填写答案。这样就可以有效地克服前面提到的两个问题。
但是与用户访谈相比，用户调查最大的不足就是缺乏灵活性；而且双方未见面，分析人员无法从他们的表情等其他动作来获取一些更隐性的信息；还有就是客户有可能在心理上会不重视一张小小的表格，不认真对待，从而使得反馈的信息不全面。因此较好的做法是将这两种技术结合使用。具体来说，就是先设计问题，制作成为用户调查表，下发填写完后，进行仔细地分组、整理、分析，以获得基础信息，然后再针对这个结果进行小范围的用户访谈，作为补充。
③联合讨论会。这是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键客户代表、分析人员、开发团队代表一起，通过有组织的会议来讨论需求。通常该会议的参与人数为6～18人，召开时间为1～5小时。
其他的方法还有通过原型进行演示，通过书面或电子邮件等手段与用户交流等。
[问题1]
根据政府机构的业务形态来看，通常，电子政务主要包括以下3个应用领域。
①政务信息查询：面向社会公众和企业组织，为其提供政策、法规、条例和流程的查询服务。
②公共政务办公：借助互联网实现政府机构的对外办公，如申请、申报等，提高政府的运作效率，增加透明度。
③政府办公自动化：以信息化手段提高政府机构内部办公的效率，如公文报送、信息通知和信息查询等。
其业务模型如下图表示。
[*]
在图中，社会公众和企业主要通过政务信息查询，以及公共政务办公与电子政务平台建立沟通，相关事务处理请求通过办公自动化系统中转给政府工作人员，政府工作人员可以通过办公自动化系统进行政务处理及对政务信息查询系统的更新。通过对这一典型业务模型的分析，可以看出在电子政务系统中主要存在3种信息流。
①政务办公信息流：主要存在于政府机构内部办公的过程中。
②公共事务信息流：主要存在于政府机构对外办公的过程中。
③政务咨询信息流：主要存在于社会公众和企业查询相关信息的过程中。
[问题2]
第2个问题考查电子政务业务的分类，这是大家都知道的内容了：政府对政府、政府对公务员、政府对企业、政府对公众。根据这些含义，对比试题描述中的功能，逐个划分就可以了。
[问题3]
第3个问题考查域建模、用例建模、组件和服务建模、性能建模的概念。
域建模是指为问题域创建相应的模型并且把它划分为若干个内聚组的过程。域模型是一种用于理解问题域的工具。要构造域模型，必须完成下列工作：
①标识并确定参与者(实体)及其操作(活动)的特征。
②标识管理操作(规则)的策略。
③收集有关实现这些操作、来自这些操作或者记录这些操作(构件/数据)的信息。
④将相关的要素划分为子域。
⑤确定结果域(核心的/通用的/外部的)及它们之间交互的特征。
用例模型描述了各种参与者(人和其他系统)和要分析的系统之间的主要交互。用例应该说明系统如何支持域和业务流程模型中的业务流程。用例模型应该将系统放到上下文环境中，显示系统和外部参与者之间的边界，并描述系统和参与者之间的关键交互。用例建模可以描述利益相关者(如用户和维护人员)所看到的系统行为。
用例建模建立反映系统行为的动态模型，用例模型描述了各种参与者和要分析的系统之间的主要交互。
组件模型为子系统、模块和组件的层次结构分配需求和职责。服务模型将应用程序定义为一组位于外部边界(用例)、架构层之间的抽象服务接口，并且提供了通用的应用程序和基础结构(安全、日志记录、配置等)。
性能建模是通过各种各样的方式来度量性能。必须考虑性能建模过程中其他的几个方面：
①构建和部署应用程序的速度如何?
②构建、维护和运行需要多少花费?
③该应用程序能在多大程度上满足其需求?
④对于必须使用该应用程序的人来说，需要为其付出多大的开销?
⑤该应用程序会对其他应用程序和基础结构产生怎样的影响?
关于这些问题(和无数的其他问题，这取决于具体情况)的答案，对一个成功的应用程序来说是至关重要的，并且通常称其为应用程序在架构上的质量。对这些质量进行建模是很困难的，甚至比性能的标准质量更困难。
[问题4]
第4个问题考查获得需求的沟通与交流技巧，这是经常考查的一个内容。
①用户访谈。用户访谈是最基本的一种需求捕获手段，其形式包括结构化和非结构化两种，结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。
②用户调查。用户访谈时最大的难处在于很多关键的人员时间有限，不容易安排过多的时间；而且客户面经常较广，不可能一一访谈。因此，我们就需要借助“用户调查”这一方法，通过精心设计要问的问题，然后下发到相关的人员手里，让他们填写答案。这样就可以有效地克服前面提到的两个问题。
但是与用户访谈相比，用户调查最大的不足就是缺乏灵活性；而且双方未见面，分析人员无法从他们的表情等其他动作来获取一些更隐性的信息；还有就是客户有可能在心理上会不重视一张小小的表格，不认真对待，从而使得反馈的信息不全面。因此较好的做法是将这两种技术结合使用。具体来说，就是先设计问题，制作成为用户调查表，下发填写完后，进行仔细地分组、整理、分析，以获得基础信息，然后再针对这个结果进行小范围的用户访谈，作为补充。
③联合讨论会。这是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键客户代表、分析人员、开发团队代表一起，通过有组织的会议来讨论需求。通常该会议的参与人数为6～18人，召开时间为1～5小时。
其他的方法还有通过原型进行演示，通过书面或电子邮件等手段与用户交流等。