软考案例分析常见问题及答案总结（三）

1、甲公司中标一个城市轨道交通监控系统开发项目，公司领导决定启用新的技术骨干作为项目经理，任命研发部软件开发骨干小王为该项目的项目经理。

小王技术能力强，自己承担了该项目核心模块开发任务，自从项目管理计划发布以后，一直投身于自己的研发任务当中。除了项目阶段验收会之外，没有召开过任何项目例会，只是项目出现问题时才召开项目临时会议。经过项目团队共同努力，该项目进展到系统测试阶段。在系统测试前，发现该项目有一个指示灯显示模块开发进度严重滞后，小王立刻会同该模块负责人小李熬夜加班赶工，完成了该模块；

小王在项目绩效考核时，认为小李的工作态度不认真，给予较差评价并在项目团队内部公布考核结果。小李认为自己连续熬夜加班，任务也完成了，觉得考核结果不公平，两人就此问题发生了严重冲突，小李因此消极怠工，甚至影响到了项目验收。

①小王缺乏项目管理理论和经验，项目管理能力不足

②小王工作重点一直在自己的研发任务中存在问题，项目经理应该以项目管理为主要工作。

③小王没有按计划召开项目例会存在问题，应该按项目管理计划进行例会。

④小王对进度检查，测试前才发现指示灯模块进度严重滞后。

⑤小王在沟通与小李的沟通过程中存在问题，没有及时把自己的想法与小李沟通，没有给小李解释的机会；

⑥小王处理冲突的方法存在问题，导致小李消极怠工。

⑦小王在沟通方面应读先和小李进行非正式的沟通，了解进度延误的原因。如果进度延误的原因是因为小李的工作态度问题导致的，应该明确指出，并要求改正。如果是其它非小李可控原因，应该和小李一起寻求解决办法。而不是直接公布考核结果。

2、项目启动初期，张伟任命项目成员李明担任项目的质量管理员，专职负责质量管理，考虑到李明是团队中最资深的工程师，有丰富的实践经检，张伟给予李明充分授权，让他全权负责项目的质量管理。得到授权后，李明制定了质量管理计划，内容包括每月进行质量抽查、每月进行质量指标分析、每半年进行一次内部审核等工作。

2017年7月份，在向客户进行半年度工作汇报时，客户表示对项目的不满，一是项目进度比预期滞后：二是项目的阶段交付物不能满足合同中的质量要求。

由于质量管理工作由李明全权负责，张伟并不清楚究竟发生了什么问题，因此，他找李明进行了沟通，得到两点反馈：

（1）在每月进行质量检查时，李明总能发现些不符合项。每次都口头通知了当事人，但当事人并没有当回事，同样的错误不断重复出现：

（2）李明认为质量管理工作太得罪人，自己不想继续负责这项工作。接着，张伟与项目组其他成员也进行了沟通，也得到两点反馈：

（1）李明月度检查工作的颗粒度不一致。针对他熟悉的领域，会检查得很仔细；针对不熟悉的领域，则一带而过；

（2）项目组成员普遍认为：在项目重要里程碑节点进行检查即可，没必要每月进行检查。

①没有制定合理的、可操作性的质量管理计划

②缺少质量标准和质量规范

③质量管理人员李明经验、能力不足

④没有建立质量保证体系

⑤质量保证做得不好，比如没有进行评审等

⑥质量控制做得不到位，检查工作颗粒度不一

⑦在质量管理中，没有采用合适的工具、技术和方法

⑧张伟缺少对项目质量管理工作的监督和指导

⑨对团队成员质量意识和质量管理方面的培训不足。

3、公司任命小陈为项目经理，并从各部门抽调了经验丰富的工程师组成了项目团队。小陈依据过去多年从事会议场所多媒体播控系统的经验，自己编写了项目范围说明书，并依此创建了WBS和WBS词典，形成项目范围基准。在项目实施过程中，由于与供应解码设备的厂商发生合同纠纷，项目组不得不断新寻找新的合作厂商，并针对新的解码设备，全新开发接口软件，致使项目工期拖延。客户针对播放控制软件，要求增加断点续传的功能，开发人员认为工作量不大就自行增加了该功能。项目测试时，小陈发现与之前做的项目不同，地铁运行时数据是通过车地无线网络传输，带宽优先，网络丢包现象严重，导致视频节目播放时，经常卡顿，马赛克现象严重，究其原因发现WBS中解决该问题的软件模块没有开发。验收时，客户对项目执行情况不满意，小陈觉得客户吹毛求疵与客户客户发生了争执，导致客户向公司高层投诉。

①没有制定符合项目实际的项目范围管理计划。

②前期需求调研存在问题，需求调研不充分或没有与客户进行需求确认。

③小陈没有意识到车载节目播放软件与会议场所播放软件的区别和功能不同。

④小陈自己编写了项目范围说明书，应该与相关干系人一起完咸。

⑤创建WBS应该由项目团队的成员参与，不应由小陈自己完

⑥没有与客户进行范围确认。

⑦项目团队成员(开发人员)对项目范围变更流程认识不足，培训不够

⑧小陈对需求跟踪存在问题，遗漏了重要的需求

⑨沟通管理存在问题，客户与小陈发生争议，进而客户投诉。

⑩整体管理存在问题，没有制订整体变更流程，也没有执行。

⑪进度管理存在问题，该项目工期拖延。

⑫质量管理存在问题，网络丢包现象严重、卡顿等。

⑬风险管理存在问题，未识别出项目风险，本项目与以往项目不同，是通过无线传输。

⑭采购管理存在问题，发生了合同纠纷，公司寻找新的合作厂商

4、A公司中标某金融机构(甲方)位于北京的数据中心运行维护项目并签署了运维合同。合同明确了运维对象包括服务器、存储及网络等设备，并约定：核心系统备件4小时到场；非核心系统备件24小时到场；80%以上备件需满足上述时效承诺，否则视为违约。

A公司任命小张担任该项目的项目经理。为了确保满足服务承诺，小张在北京建立了备件库，招聘了专职备件管理员及库房管理员。考虑到备件成本较高，无法将服务器、存储和网络设备的所有备件都进行储备，备件管理员选择了一些价格较低的备件列入《备件采购清单》,并经小张批准后交给了采购部。随后，采购部通过网站搜索发现B公司能够提供项目所需全部备件且价格较低，于是确定B公司作为备件供应商并签署了备件采购合同。项目实施三个月后，甲方向公司投诉：一是部分核心系统备件未能按时到场；二是部分备件加电异常，虽然补发了备件，但是影响了系统正常运行针对备件未能按时到场的问题，小张通过现场工程师了解到，一是部分核心系统备件没有储备，二是部分备件在库存信息中显示有库存，但调取时却找不到。为此需要临时从B公司采购，延误了备件到场时间。

针对备件加电异常的问题，小张召集采购部、库房管理员、B公司召开沟通会议库房管理员认为B公司提供的备件质量存在严重问题，但无法提供相应证据。B公司则认为供货没有问题，是库房环境问题导致备件异常，因为B公司人员送备件到库房时曾多次发现库房温度、湿度超标，采购部人员观点与库房管理员一致，原因是采购部通过查询政府采购网等多家网站发现，B公司去年存在多项失信行为记录大家各执一词，会议无法达成共识。

1、规划采购存在的问题：

①事先没有制订好采购管理计划；

②没有明确供方选择标准；

③采购策略不合理不科学

④采购时只考虑低成本，没有综合考虑进度时效、质量等的制约因素

⑤《备件采购清单》(即采购工作说明书)存在缺限，部分核心系统备件并没有列入其中。

2、实施采购中存在的问题：

①《备件采购合同》没有明确备件规格、型号、数量等要求，特别是没有明确验收标准、验收(收货)流程

②没做好备件的配置管理，备件出、入库不规范，

③备件管理员和库员管理员不称职，没有做好验货和收货

④没有做好采购过程中的风险管理和沟通管理

⑤库房环境存在问题

3、控制采购存在的问题：

①没有做好合同管理，及时监督合同绩效

5、2018年7月某信息系统公司中标当地司法部门语音转写项目，任命小陈为项目经理。小陈组建了项目组，制定了项目范围说明书，并获得了客户确认。为了激励成员，小陈向公司申请了项目奖金，项目进行过程中，小陈发现人员紧张，请来在读研究生小张协助软件研发工作，并对其进行了培训。软件开发完成后，小陈找到公司办公室职员小侯帮助进行软件测试。小侯普通话不标准，测试发现语音识别率不高。小李认为原因是程序架构不合理，小胡则认为是算法存在问题，双方争论不休，小陈认为这是正常的工作状态，未做干预。项目组成员间气氛日趋紧张，士气低落。

恰当地方：

①制定项目范围说明书

②并得到了客户的确认

③申请项目奖金用于团队成员激励。

④对团队成员进行了培训。

⑤项目开发完成后进行了范围确认、项目测试。

不恰当地方：

①团队成员冲突没有进行处理。

②没有进行项目团队建设，团队士气低落。

③范围确认标准不清晰。

④没有专职的测试人员

6、王伟认为好的项目团队中绝对不能出现冲突现象，这次冲突与小张的个人素养有直接关系。为了避免冲突对团队产生不良影响，王伟宣布立即终止会议并请小张留下来单独谈话。在沟通中，王伟批评小张缺乏团队合作意识。小张表示他对加班费、项目奖金等不在意，而且他技术经验丰富，很容易找到份收入不错的工作。他不加班的原因是最近家人、朋友等各种圈子应酬太多。王伟表明如果因为小张的原因导致项目工期延误，会影响小张在团队中的个人声誉，同时更会影响整个项目团队在客户和公司内部的声誉，小张虽不情愿，但最终选择了加班。

①王伟认为好的项目团队中绝对不能出现冲突现象，这种认识不妥。(一定程度的冲突是有益的)

②王伟认为这次冲突与小张的个人素养有直接关系也不妥。(冲突应该对事不对人)

③王伟宣布立即终止会议，并请小张留下来单独谈话，王伟批评小张缺乏团队合作意识，这个做法不妥(应公开处理冲突，利用合作的方式来处理冲突，同时冲突是一个团队问题，而不是某个人问题)

④王伟只是采用了强制的方式，小张是不情愿的选择了加班，这种方式效果可能并不长久，或可能导致其他的问题(如小张消极怠工或离职))

7、刘工和李工带领团队根据以往经验完成了需求调研和范围说明书。但由于该项目甲方负责人负责多个项目，时间紧张，导致需求评审会无法召开。张工考虑到双方已经有合作基础，李工和刘工对原系统非常熟悉，为了不影响进度，张工让项目组采用敏捷开发模式，直接进入了设计和编码阶段。

在客户验收测试时，甲方负责人提出APP的UI设计不符合公司风格、不兼容新燃气表的数据接口、数据传输加密算法不符合要求等多项问题，要求必须全部实现这些需求后才能验收。此时张工把公司新产品研发部正在研发的新产品给甲方负责人展示，双方口头约定可以采用新产品部分功能实现未完善的需求。经过增加人员和加班赶工，延期1个月完成。项目上线后用户又发现了若干问题。

①没有制订科学、合理的项目范围管理计划与需求管理计划。

②没有全面、充分地收集客户的需求，并通过正规的需求评审形成各方认可的需求规格说明书。

③闭门造车式地开展需求调研与项目范围说明书的编写工作，没让相关干系人参与进来。

④没有编制WBS和WBS词典，以形成权威的范围基准。

⑤张工身兼多职，在项目上投入的时间太少，没有及时监控项目进展。

⑥缺乏阶段性的评审，从而未能及时发现问题。

⑦没有做好确认范围的工作，导致遗漏了部分工作与成果。

⑧没有建立规范的范围变更控制流程，存在随意变更需求的现象。

⑨没有做好控制范围的工作。

⑩与甲方的沟通工作做得不好。

⑪控制进度的工作做得不好。

⑫口头约定说明文档管理与配置管理工作也没有做好。

8、A公司是提供SaaS平台服务业务的公司，小张作为研发流程优化经理，他抽查了核心产品的配置管理和测试过程，情况如下：项目组共10人，产品经理野人老师兼任项目经理和配置管理员，还要7名开发工程师和2名测试工程师，采用敏捷开发的方法，2周为一个迭代周期，目前刚刚完成一个01版本的上线。

小张要求看一下配置管理库，野人老师回复：”我正忙着，让测试工程师王工给你看吧，我们10个人都有管理员权限”。小张看到配置库分为了开发库和产品库，产品库包括上线的3个大版本的完整代码和文档资料，而且与实际运行版本有偏差。小版本只能在开发库中找到代码，但没有相关文档，而且因为新需求迭代太快，有些很细微的修改，开发人员随手进行了修改，文档和代码存在一些偏差。

小张策划对产品做一次3.01版本的系统测试，以便更好的解决研发流程和系统本身的问题。

①没有制订规范的配置管理计划

②没有安排专职的配置管理员与专职的项目经理

③没有建立起合理的配置管理系统

④配置库不完整，缺失了受控库

⑤配置库的管理权限设置不规范，不能让所有成员均拥有管理权限。

⑥没有进行规范的版本控制

⑦配置变更控制工作做得不好

⑧没有开展有效的配置审计工作

⑨开发库与产品库的内容均不完整，且文档更新很不及时

⑩项目经理严重缺泛配置管理的意识与经验

9、公司没有智慧法院的相关项目经验，选择刚业两年的小王担任项目经理，由于项目时间较紧，小王主要围绕工作分解、人员分工、项目进度和预算，独自制定了项目管理计划，考虑到公司从未有过智能语音识别方面的相关开发经验，小王特意从某高校请来人工智能实验室的李教授，为项目组人员培训智能语音相关理论知识和常用算法，经过培训，对语音识别技术有了初步的了解，但还不具备自我研发能力，因此项目组决定将该功能外包。

项目实施过程中，甲方希望能在软件中增加一简单功能，小王认为增加功能并不复杂，直接让软件开发人员进行了修改，由于项目本身时间周期较短，又受疫情影响，时间更加紧迫，为了不耽误进度，小王要求项目组采取997工作模式，项目中后期，有核心人员提出离职。项目收尾时，小王发现交付的软件存在部分功能与设计文档不一致。

①选择刚毕业两年的小王担任项目经理可能会因为经验不足导致风险识别工作做不到位

②小王独自制定了项目管理计划，可能会导致风险管理计划和风险识别登记册不够全面

③聘请专家不仅仅是做培训，还应邀请他做风险识别工作

④没有对变更风险进行识别

⑤没有对进度风险进行识别

⑥风险识别不够全面，没有对疫情这种未知风险进行识别

⑦没有对人力资源风险进行识别

⑧没有对质量风险进行识别

10、小王担任项目经理，项目交付期为60天。小王研究了总部提出的需求后，认为项目核心在于各子公司数据收集以及数据可视化及分析预测功能。各子公司数据收集可以以总部现有系统中的数据格式模板为基础，为各子公司建立数据上传接口。针对数据的分析预测功能，由于牵涉到人工智能等相关算法。目前项目组还不具备相关方面的知识储备，因此项目组对该模块功能直接外包。小王将数据收集与可视化工作进行了WBS分解，WBS的部分内容如下：

 此外，虽然总部没有提出修改界面，但小王认为旧版的软件界面不够美观，让软件研发团队重新设计并更改了软件界面。

试运行阶段，总部人员试用后，认为已经熟悉旧版的操作模式，对新版界面的布局极其不适应；各子公司数据报送人员，认为数据上报的字段内容与自己公司的业务并不相关，填写困难。总部和各子公司的试用人员大部分认为新系统不是很好用。

①小王独自分解存在问题，分解过程需要所有(主要)干系人参与。

②WBS分解的层次不够，应该分解到4-6层。

③WBS分解的工期不满足8/80原则，工作包粒度过粗。

④分解后的工作单元不能区分开不同的责任者和不同工作内容。

⑤WBS没有包括项目管理工作。

⑥WBS没有包括外包工作数据分析预测功能

⑦没有制定范围管理计划和需求管理计划

⑧没做好需求收集、分析、调研等工作

⑨没有做好需求跟踪工作

⑩项目范围说明书内容不全面或者项目范围定义不充分

⑪WBS及范围基准应让项目团队和所有关键干系人一起来创建，而不是项目经理创建，导致工作遗漏

⑫项目范围基准未经评审和审批

⑬缺少范围确认等环节，项目成果等没有得到用户的正式确认和接受

⑭范围变更没有规范的变更控制流程

⑮项目变更实施前没有及时变更合同

⑯变更结果没有得到客户的确认

⑰存在范围蔓延和镀金情况

11、某公司中标医院的信息管理系统。公司指派小王担任项目经理，并组建相应的项目团队。由于人手有限，小王让负责项目质量工作的小杨同时担当配置管理员。小杨编写并发布了质量管理计划和配置管理计划。

小杨利用配置管理软件对项目进行配置管理，为了项目管理方便，小杨给小王开放所有的配置权限，当有项目组成员提出配置变更需求时，小杨直接决定是否批准变更请求。小杨为项目创建了三个文件夹，分别作为存放开发、受控、产品文件的目录，对经过认定的文档或经过测试的代码等能够形成配置基线的文件，存放到受控库中，并对其编号。项目研发过程中，某软件人员打算对某段代码作一个简单修改，他从配置库检出待修改的代码段，修改完成并经测试没问题后，检入配置库，小杨认为代码改动不大，依然使用之前的版本号，并删除了旧的代码。公司在质量审计过程中，发现项目管理方面的诸多问题。

①项目未建立配置管理系统和制度，配置管理混乱

②未充分识别配置项

③不能由小杨一人编写并发布质量管理计划和配置管理计划步

④小杨给小王开放所有的配置权限存在问题

⑤没有做好变更管理，小杨直接决定是否批准变更请求存在问题。应该走变更控制流程

⑥配置的版本管理不到位，任何的修改都将产生新的版本

⑦未建立配置库，应该建立开发库、受控库、产品库

⑧没有定义配置管理流程

⑨不能因为有了新的版本号，就删除旧的版本，要保留所有版本

⑩没有定期发布配置状态报告

⑪没有建立基线，导致需求、设计、编码无法对应

⑫小杨是兼职管理，应该配备专职的配置管理员

⑬配置管理人员经验不足

⑭对配置管理工具没有进行有效评估

⑮未进行配置工具使用及配置管理的培训

12、A公司承接某市机关事业单位界老保险信息系统，项目覆盖个市、区、县的机关事业单位在编人员的养老保险信息，实现数据集中统一管理。公司成立了项目组，并任命小王担任项目经理。项目组对项目进行调研后，成立了风险管理小组，编写了项目管理计划和风险管理计划，明确项目风险管理流程如下图所示：

 项目组对风险登记册的各风险制定了相应措施，部分措施如下所示：

 此外，在信息安全方面，养老保险数据信息涉及个人隐私，如果不法分子突破安全限制，会造成用户隐私泄露或信息篡改。因此项目组采用PKI技术为系统的安全运行提供了有效的保障。

①记入风险登记册不应该做为一个单独的步骤，应该是识别风险的输出，并在定性、定量和规划应对过程不断被更新

②风险识别是一个贯穿项目始终、反复要进行的过程，这个流图里没有表现出来

③风险定性、定量分析不应放在同一个步骤中，应分开，两者评估内容和细节不同

④监控风险中，不能只是针对发生风险处理。要实施风险应对措施，跟踪已识别的风险、监督残余风险、识别新风险等

13、小陈认为编制沟通管理计划是一件重复性的工作，于是参考过去的项目管理计划，简单进行了修改后放入了项目计划文件夹下作为公共信息供大家查阅，完成后的沟通管理计划表如下：

①每周例会应该采取会议的形式进行沟通。

②每周例会还包括项目潜在风险的评估、项目团队人力资源协调等内容。

③方案评审会议没有通知相关领导与客户等重要干系人

④方案评审应该包括客户、外包、领导等干系人。

⑤项目阶段性总结应该采取会议的形式进行沟通

⑥开发技能培训应该要明确培训时间。

⑦项目交流会应该采用会议形式。

⑧项目启动应召开项目启动会议，而不是项目交流会。

⑨项目结束的时候还应召开项目总结会议。

14、A公司为提升市场竞争力，计划针对制造业数字化转型的需求，新开发一套数字化软件，实现在工业产品生产和制造过程中数据采集，分析和决策功能。公司让产品部前期对市场需求进行调研。产品部对软件预期能产生的经济效益和社会效益，进行了详细的分析，并针对这两部分，编制了《可行性分析报告》。公司高层领导看了报告后，认为该软件未来会为公司带来巨大的收益，当场拍板决定启动项目，要求产品部补充编剧《项目建议书》,并组建项目团队。

小王作为某名校计算机专业刚毕业的研究生，被公司委以重任，担任该项目的项目经理。研发负责人向小王建议为配置管理设置一名专职配置管理员，但小王认为有配置管理工具，对代码进行控制，大家只要对程序代码做好版本控制就可以了，考虑到项目组人员紧张，没必要再安排专人负责配置管理工作。

开发过程中，为避免多人同时修改代码导致冲突，研发人员要先将服务器上的代码下载，待编码完成后，使用文本对比工具将代码中修改的部分进行上传整合。

软件研发完成测试通过后，研发人员将最终版本软件和软件使用说明书提供给产品部，产品部人员发现说明书描述和内容与软件不完全一致，于是将问题反馈给小王，小王经检查发现提交的说明书并不是最新的说明书。

①可行性分析做得不够详细，还要做技术、财务、风险等方面的分析

②没有对《可行性分析报告》进行审批，仅高层领导拍板决定启动项目

③《项目建议书》不应该后期补充编制

④小王作为刚毕业的研究生担任项目经理存在项目配置管理经验不足

⑤没有制定配置管理计划

⑥没有配备专职的配置管理人员

⑦没有建立基线和管理好基线

⑧没有建立配置库，比如开发库、受控库、产品库

⑨没有选用有效的配置管理工具

⑩版本管理没有做好

⑪变更管理没有做好

⑫没有规范的配置管理流程

15、为实现空气质量的精细化治理，某市规划了智慧环保项目。该项目涉及网格化监测、应急管理、执法系统等多个子系统。作为总集成商，A公司非常重视，委派李经理任项目经理，对公司内研发部门与项目相关的各产品线研发人员及十余家供应商进行统筹管理。李经理明确了关键时间节点，识别出项目干系人为客户和供应商后，开始了项目建设工作。

项目开始建设5个月后，公司高层希望了解项目情况，要求李经理进行阶段性汇报。李经理对各方面工作进展进行汇总，发现三个问题：一是原本该到位的服务器、交换机，采购部门迟迟没有采购到位，部分研发完成的功能无法部署到客户现场与客户进行演示确认；二是S公司作为A公司的供应商，承担空气质量监测核心算法工作，一直与客户方直接对接，其进度已经不受李经理掌控，且S公司作为核心算法国内唯一权威团队，可以确保算法工作按期交付，因此其认为不需要向李经理汇报工作进展；三是公司研发部门负责人因其他项目交付紧迫性更高，从该项目抽调走了2名研发人员张工、王工，项目目前研发人员的空缺需要后续补充。

李经理忧心忡忡，向公司汇报完项目进展情况后，公司政策研究院相关领导表示国家在环境执法方面的法律法规本月初已经进行了较大改版，项目相关子系统会有关联；营销副总裁听完项目汇报后表达不满：该项目作为公司的重点项目，希望作为全国性的标杆项目进行展示和推广，但当前各子系统的研发成果基本照搬了公司现有产品，没有任何创新性的体现，不利于公司后期的宣传推广，PMO提醒李经理依据财务部门推送的数据，公司对部分供应商已经根据进度完成了第二节点款项支付，但当前A公司作为总集成商，与客户的第二个合同付款节点还未到，项目的成本支出和收益方面将面临较大的压力。人力资源负责人提醒李经理，项目成员张工和王工的本月绩效评价还未提交，截止日期为2天以后。

资源管理方面存在的问题：

①没有制定资源管理计划

②没有做好获取资源的工作，原本该到位的服务器、交换机，采购部门迟迟没有采购到位，其他项目抽走张工、王工一直没有补充

③人力资源负责人提醒李经理，项目成员张工和王工的本月绩效评价还未提交。说明没做好团队建设和团队管理。

④项目经理资源管理经验不足。

⑤A公司作为总集成商，与客户的第二个合同付款节点还未到，项目的成本支出和收益方面将面临较大的压力。可能或导致资源获取有困难。

沟通管理方面存在的问题：

①没有制定沟通管理计划

②没有主动地向公司高层作阶段性的汇报

③李经理没有做好与S公司的沟通作，不能让S公司直接与客户对接，也不能因为S公司可以确保算法能够按期交付就不进行工作汇报

④营销副总裁听完项目汇报后表达不满

⑤PMO提醒李经理依据财务部门推送的数据，说明没及时进行沟通。

⑥项目经理沟通管理经验不足。

16、数字化城市管理通过信息化手段和移动通信技术手段来处理、分析和管理整个城市的所有部件和事件信息，促进城市人流、物流、信息流、交通流的通畅与协调。

2023年，某县为提升该县的运营效率，利用已有的海量数据，实现数字化城市管理，启动了数学化城市管理项目，项目建设期8年。作为政府重点项目，为扶持当地民营企业，将项目建设工作交给A公司牵头负责。

A公司过去一直做银行信息管理系统，为了完成好项目，他们仔细研究了数字化城市管理的相关文档，参考了其他城市的数字化城市管理建设项目，发现城市管理的建设要牵涉到多个政府部门。调研中还发现，尽管目前县政府已经汇集了来自各部门关于城市运营的海量数据，但没有统一的数据标准，导致出现数据不规范、难以融合、利用率不高等问题。尤其是交通数据，来源于多个系统，各系统建设时间先后不一、标准不同、数据多而散乱、数据多源异构现象明显，导致海量交通数据一直未得到有效利用。因此，为了满足不同系统间的数据整合和共享需求，A公司打算建立统一的数据元标准，指导与规范城市数字化建设。

①数学化城市管理项目，作为政府重点项目，应该通过公开招标方式选择承建方，不应该直接把建设任务交给当地民营企业。

②数学化城市管理项目涉及部门、内容多，A公司过去一直做银行信息管理系统，不具备相应的项目管理经验。

③A公司只研究之前的文档，只参考了其他城市的经验，没有根据当前项目的实际情况进行调研论证，脱离项目实际，容易存在变更风险。

④城市管理的建设要牵涉到多个政府部门，干系人多，沟通可能存在风险

⑤交通数据，没有统一的数据标准，来源于多个系统，数据散乱，不规范，开发存在风险

⑥为了满足不同系统间的数据整合和共享需求，A公司打算建立统一的数据元标准，没有与相关干系人进行确认，存在需求风险

⑦A公司没有进行数据战略制定，缺少数据战略规划、数据战略评估、数据战略需求评估等数据管理系统过程，没有全面系统地规划数据管理，存在整体管理风险。

⑧没有储备数字管理各层级人才对数据进行有效管理，存在数据管理质量风险。

⑨没有进行数据安全方面的考虑，存在安全风险。