某地区数智化科技城建设项目科技大信息施工总结报告

免责声明，本资源仅供用户学习和技术研究探讨使用，如果由于以上原因造成的版权纠纷，概不负责！希望人人都能拥有学习研究知识的机会。某地区数智化科技城建设项目科技大信息施工总结报告项目完成情况2.1目标完成情况项目目标：本项目将建设统一访问首页，统一访问首页独立于各类应用之上，为多业务系统的统一界面入口，避免用户打开多个浏览器窗口访问不同业务系统依次登录，彼此之间通过切换浏览器窗口来完成业务操作。统一访问首页通过整合不同应用系统的业务展现界面，可以将割裂的业务操作进行合理编排并推送辅助信息到展现界面帮助操作人员完成业务操作和决策，可以增强用户的操作体验。作为统一对内的信息服务窗口，以浏览器的方式向用户展现各类应用信息为信息提供者和信息使用者提供信息发布全方位管理以及信息资源展示，具体包括信息资源、API服务、信息开放、信息治理、信息可视化等栏目；实际完成情况：已按照项目计划，完成阶段性验收要求的全部建设内容，10月1日已进入阶段性验收部分的上线试运行阶段。2.2任务完成情况当前项目已经按照初期计划顺利完成建设阶段，已经做好上线试运行前的全部准备工作。项目所涉及的建设内容当前均按招标文件、投标文件、合同、有关技术文件及适用的标准要求建设完成，各种技术文档和阶段性验收资料完备，以上均符合建设合同的内容；项目中功能和性能满足设计要求。项目实施总结3.1项目工作量说明序号建设内容工作量变化类型变化说明1人口库调研增加客户单位现有信息化建设缺乏，对信息化认识不足。增加了调研工作量。2宏观经济库调研增加客户单位现有信息化建设缺乏，对信息化认识不足。增加了调研工作量。3城建筑库调研增加客户单位现有信息化建设缺乏，对信息化认识不足。增加了调研工作量。4法人库调研增加客户单位现有信息化建设缺乏，对信息化认识不足。增加了调研工作量。5空间地理库调研增加客户单位现有信息化建设缺乏，对信息化认识不足。增加了调研工作量。6信用信息库调研增加客户单位现有信息化建设缺乏，对信息化认识不足。增加了调研工作量。7需求整理与分析增加由于客户对大信息建设认识不足，导致需求分析整理过程难度加大，工作量加大。8需求调研报告无无10需求规格说明书无无10概要设计无无11详细设计无无12信息库设计无无13基础支撑台开发无无14信息管理子系统开发无无15统一首页子系统开发无无16信息交换管理台开发无无17信息智能分析系统开发无无18城运行一张图开发无无110系统功能测试无无20系统集成测试无无21系统性能测试无无22信息库部署无无23中间件部署无无24单点登录部署无无25地理信息套件部署无无26基础支撑台部署无无27信息管理子系统部署无无28统一首页子系统部署无无210信息交换管理台部署无无30信息智能分析系统部署无无31城运行一张图部署无无32运维培训无无33用户培训无无34上线试运行未开展未开展3.2项目进度说明序号里程碑变更类型计划完成时间实际完成时间变化说明1完成需求调研延期6月27日6月30日客户单位现有信息化建设缺乏，对大信息认识不足，导致调研时间延长2完成系统设计无7月13日7月13日无3完成系统开发无8月30日8月30日无4完成系统测试无10月12日10月12日无5完成部署实施无10月22日10月22日无6完成用户培训提前10月30日10月22日为了用户更好的适用台，培训提前展开7上线试运行结束无12月31日3.3项目风险及解决3.4客户满意情况说明自项目开始建设以来，项目组耐心帮助解决客户日常工作中碰到的实际问题，多次获得客户的肯定与表扬。客户满意度较高。3.5实施情况总结3.5.1签定合同阶段一个项目的开发成败或者说项目开发带来效益的大小，在很大程度上是受项目合同签定的影响的。往往，很多一部分与客户签定的项目合同都是很模糊的，也很难签定的比较清楚，这样以来就会导致在项目的开发后期，工作两会越来越大，影响项目的竣工周期；而且，项目的开发费用一般是不会变的。这样以来，我们就大大的降低了我们的开发效益。虽然需求范围很难签定的明确，但是我们在签定合同时，要尽量的去把合同功能边界和添加新功能的要求签定。3.5.2开发团队在项目确立后，要尽快的建立起项目开发团队。项目团队成员的团结合作、相互沟通是非常重要的，团队成员之间要相互学习彼此的优点和技术，使团队的能力不断的提高。这样，在项目的开发过程中，团队才不会被难题困住不动。另外，团队中要有一个项目负责人，这个人无论是在与客户的沟通上，还是在技术上都要是很出众的人，此项目负责人要能很好的沟通客户与开发成员之间，以此来更好的理解客户的功能需求。人的记忆力总是有限的，所以就要求开发团队成员要尽量的书写一些开发文档，这些文档往往是我们在项目开发后期要用到的可寻资料。项目团队士气是项目成功的一个因素,我们需要不断的来培养我们的团队气势，使我们的团队不断的壮大。3.5.3需求的调研在项目确立后，就到了需求调研分析阶段。项目组对客户的整体组织结构、有关人员的关系、职责等如果没有一个很好、足够的了解掌握，这样项目组就无法很好的完整的整理到客户的需求、或者说客户真实的功能需求，如此以来我们就为自己埋下了地雷,影响项目的开发周期，这就要求我们要与客户搞好无论是工作上的还是生活上的朋友关系,要深入的去了解客户需求。3.5.3.2我们要尽量的让客户也参与到项目的开发团队中来，也就是说我们要使客户把自己也纳入到项目的开发团队中来，如此一来，我们掌握客户需求的真实性、可靠性就会大大的提高,也就不会为项目的后期功能开发埋下陷阱3.5.3.3在需求调研过程中，如果缺乏足够用户参与，这样的需求调研也是失败的。很多程序员不愿参与到客户的需求调研中去，为什么呢？很简单，与客户沟通不如与代码沟通容易有意思。尽管这样，我们还是必须用足够多的时间去和客户进行沟通，了解他们真实的需求。很多用户也是如此，他们自己也不愿意参与到项目的需求调研中来。虽然现状如此，我们还是要努力的使客户参与到需求的调研中来。3.5.3.4模糊需求，也就是模棱两可是需求规格说明中最为可怕的问题。一是指诸多客户对需求说明产生了不同的理解；一是指单个读者能用不止一个方式来解释某个需求说明。针对对这种情况，就要求我们的调研人员要能够从多个角度来分析客户的不同需求，整理出最终的需求与客户确认，定出最终真实可靠的需求，我们绝不能凭借我们自己的单面理解来定立客户的最终需求。3.5.3.5在一个项目的开发中，文档的书写是极为中要的一项工作。因为，某些文档就是我们在开发后期与客户沟通的可寻依据、也是我们程序员在编码过程中要用到的重要文档。我们绝对不能认为，凭借我们的大脑来记录所有的开发需求；即使，你说你是天才，你要用你那颗爱因斯坦的大脑来记录所有的开发需求，那也是不可能的，人的精力总是有限的。这就要求我们在需求调研中做好需求文档的记录和整理。3.5.3.6需求调研工具选择，客户一般对图形还是比较感兴趣的，所以我们在调研过程中，我要尽量的采用图形化界面来和客户沟通需求。把客户的意思转换为用例图、时序图、协作图、状态图、类图等，使表达的意思更加直观。这样客户会更快的进行问题的实质。3.5.4做好开发计划在项目确立后，我们就需要做好项目开发计划，需求调研用时，开发用时，测试用时，实施用时，维护用时。在我们做好了计划后，我们要随时的跟踪计划任务的完成进度，从而使我们的项目进度掌控在我们的开发周期范围之内，今日计划、行动，明日成功。3.5.5很好的沟通在其他行业中，人与人的之间的沟通只很重要的。项目开发也不例外，很好的沟通能够加快项目的进度，这就要求我们每一个开发人员要学会和善于沟通于客户和同事之间。在一个项目的开发过程中，我们与客户的沟通是一个不断交流和沟通的过程。在开发到一定的阶段，我们就需要和客户沟通已有功能，尽量的去避免一些隐藏的问题，及时的发现问题，解决问题，从而按时或者提前完成项目的开发。同时，与客户及各感谢也要保持良好的沟通，保证项目顺利实施。3.6.6做好工作总结在项目进行的过程中，我们要不断去整理自己的工作情况和做好总结，这样以来，无论是在自己的技术水还是的知识体系，都会为今后的工作带来更大的价值。3.6.7风险管理在项目计划、实施过程中，遇到风险问题要提前分析并找到有效的处理解决办法。防止风险演变成问题。经验与教训5.1项目成功的经验5.1.1定义项目成功的标准在项目的开始，要保证风险承担者对于他们如何判断项目是否成功有统一的认识。经常，满足一个预定义的进度安排是唯一明显的成功因素，但是肯定还有其他的因素存在，比如：增加场占有率，获得指定的销售量或销售额，取得特定用户满意程度，淘汰一个高维护需求的遗留系统，取得一个特定的事务处理量并保证正确性。项目计划目标定义，包括进度，成本和质量。5.1.2识别项目的驱动、约束和自由程度每个项目都需要衡它的功能性，人员，预算，进度和质量同标。我们把以上五个项目方面中的每一个方面，要么定义成一个约束，你必须在这个约束中进行操作，要么定义成与项目成功对应的驱动，或者定义成通向成功的自由程度，你可以在一个规定的范围内调整。5.1.3定义信息标准在项目早期，要决定用什么标准来确定信息是否准备好发布了。你可以把发布标准基于：还存在有多少个高优先级的缺陷、度量或其他方面表明项目已经达到了它的目的。不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，并且与你的客户指的“质量”一致。5.1.4沟通承诺尽管有承诺不可能事件的压力，从不作一个你知道你不能保证的承诺。和客户和管理人员沟通哪些可以实际取得时，要有好的信誉。你的任何以前项目的信息会帮助你作说服的论据，虽然这对于不讲道理的人来说没有任何可真正的防御作用。5.1.5写一个计划有些人认为，花时间写计划还不如花时间写代码，但是，困难的部分不是写计划，困难的部分是作这个计划——思考，沟通，权衡，交流，提问并且倾听。用来分析解决问题需要花费的时间，会减少项目以后会带来的意外。5.1.6把任务分解成英寸大小的小圆石英寸大小的小圆石是缩小了的里程碑。把大任务分解成多个小任务，帮助更加精确的估计它们，暴露出在其他情况下你可能没有想到的工作活动，并且保证更加精确、细密的状态跟踪。5.1.7为通用的大任务开发计划工作表如果经常承担某种特定的通用任务，如实现一个新的对象类，需要为这些任务开发一个活动检查列表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步骤。这些检查列表和工作表将帮助成员确定和评估与他／她必须处理的大任务的每个实例相关的工作量。5.1.8计划中．在质且控制活动后应多次修改工作几乎所有的质量控制活动．如测试和技术评审．都会发现缺陷或其他提高的可能。项目进度或工作细分结构，应该把每次质量控制活动后的修改，作为一个单独的任务包括进去。5.1.10为过程改进安排时间从项目进度中留出一些时间，因为软件项目活动应该包括做能够帮助你下一个项日更加成功的过程改进。不要把项目成员可以利用的时间100％的投入到项目任务中。5.1.10管理项目的风险在项目计划时花一些时间集体讨论可能的风险因素，评估它们的潜在危害，并且决定如何减轻或预防它们。5.1.11根据工作计划而不是日历来作估计估计与任务相关联的工作计划（以人时为单位）的数量，然后把工作计划转换为日历时间的估计。每天有多少有效的小时花费在项目任务上，可能碰到的任何打断或突发调整请求，会议，和所有其他会让时间消失的地方。5.1.12不要为人员安排超过他们80%的时间跟踪组员每周实际花费在项目指定工作的均小时数会发现，我们被要求做的许多活动相关的任务，显著地降低了工作效率。5.1.13将培训时间放到计划中确定组员每年在培训上花费多少时间，并把它从组员工作在指定项目任务上的可用时间中减去。虽然可能在均值中早已经减去了休假时间、生病时间和其他的时间，对于培训时间也要同样的处理。5.1.14记录估算和如何达到估算的当准备估算作的工作时，把它们记录下来，并且记录是如何完成每个任务的。理解创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将帮助估算过程。5.1.15记录估算并且使用估算工具有很多商业工具可以帮助你估算整个项目。根据它们真实项目经验的巨大信息库，这些工具可以给出一个可能的进度和人员分配安排选择。它们同样能够帮助避免进人“不可能区域”。5.1.16遵守学习曲线如果项目第一次尝试新的过程，工具或技术，那么必须认可付出短期内生产力降低的代价。不要期望在新软件工程方法的第一次尝试中就获得显著的效益，在进度安排中考虑不可避免的学习曲线。5.1.17考虑意外缓冲事情不会像作项目计划的一样准确的进行，所以预算和进度安排应该在主要阶段后面包括一些意外的缓冲，以适应无法预料的事件。5.1.18记录实际增况与估算情况5.1.110只有当