方案在我们工作与学习过程中起着重要的作用，对于我们进一步开展工作与学习，有着非常积极的意义。那么一份科学的方案是什么样的呢？以下是小编整理的《软件项目技术培训方案》，欢迎阅读，希望大家能够喜欢。
轻量级软件项目管理方案
摘要：给出了轻量级软件项目管理解决方案。从项目计划管理、配置管理、项目建模、需求管理、Bug管理与代码自动化生成6个方面进行了分析，并给出了实用的CASE工具。
关键词：项目管理;配置管理;代码自动化生成;.NET
Solution of Lightweight Software Project Management
ZHAI Jing-xuan
(China University of Mining and Technology, Xuzhou 221116, China)
Key words：project management; configuration management; automatic code generation; .net
“软件危机”是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。“软件危机”于1968年由北大西洋公约组织的计算机科学家第一次提出，并随之誕生了“软件工程”这一学科。软件工程主要目的是研究用工程化方法构建和维护有效的、实用的和高质量的软件，从而避免“软件危机”。
“软件危机”已经提出40多年来，软件工程领域研究成果显著，取得了较大的成就。由于微电子技术的发展和计算机应用的普及，软件成本在计算机成本中所占的比例持续增长，软件项目日趋复杂，软件开发效率的提高也远远落后于信息化普及速度。因此导致“软件危机”问题不仅没有解决，而且愈演愈烈。对于软件工程的研究依然是一个比较热门的领域。软件项目的管理方法研究是软件工程学的研究领域之一，良好的软件项目管理模式对于对提高项目的成功率，减少开发成本和提升软件质量具有促进作用。
软件项目管理主要包括进度管理、成本管理、质量管理、风险管理与配置管理等。要进行有效的过程管理，必须制定科学的管理办法和使用有效的软件项目管理工具。
软件工程发展至今，陆续诞生了CMM(软件能力成熟度模型)、CMMI(能力成熟度模型集成)、RUP(统一软件开发过程)与MSF(微软解决方案框架)等成熟管理模型。这些解决方案对项目管理进行了全面的定义，一定程度上缓解了软件危机问题。诸如，CMMI中定义了详细的项目管理及过程管理模型，适合研发团队进行规范化设计。但对于不具有很高的复杂程度软件研发项目，完全按照CMMI或其它成熟的模型不切合实际，但是又必须以成熟模型为主要参考目标。本文根据实际软件项目管理与研发经验，提出了一种适合于中小型项目的轻量级项目管理解决方案。该方案主要适用于采用Microsoft.NET平台进行开发的项目团队。
1轻量级项目管理过程
轻量级项目管理过程包括计划、需求、设计、编码、测试、发布与维护5个阶段。
计划阶段主要工作为调研用户需求，分析系统目标，分析系统开发的可行性，制定初步的项目计划。
需求阶段主要工作内容为与用户沟通，编写完善的“需求规格说明书”。“需求规格说明书”包括软件的功能需求、性能需求、非功能性需求、环境约束和外部接口等。
设计阶段主要包括概要设计和详细设计两个部分，由架构师针对软件的需求设计出系统总体流程、子系统、数据与对象描述、算法和程序接口等。
编码阶段的主要工作内容为将设计描述为可编译的源程序。
测试阶段的主要工作任何为根据需求规格和设计文档，对软件的功能进行验证。测试与需求阶段同步开始，到项目验收前结束。
发布阶段的主要工作是，对于软件产品进行安装部署，发布以后还需要根据用户要求和产品实际情况进行维护。
轻量级软件项目管理解决方案的目标是针对中小型软件项目运作的实际情况，建立行之有效的管理体系和沟通机制，提供项目开发效率，保障产品质量，确保项目能如期交付。主要管理的内容是开发过程中的各类文档、进度控制管理、BUG跟踪与代码同步协作开发。
2轻量级项目管理实施
笔者所在的团队主要以Microsoft.NET为基础开发平台，数据库采用SqlServer系列，软件项目管理方案主要基于以上经验获得。因此本方案主要适用于使用.NET平台的开发的各类中小型项目，B/S与C/S项目均可。方案主要内容为：
2.1项目计划管理
软件项目管理的目的主要是确定项目的范围、进度和费用。项目计划就是要对项目整个实施过程的目标、任务、进度和责任委派做出具体的规定和部署，它在项目管理中处于中心地位。项目计划主要包括设计工作分解结果。此阶段主要使用的工具为：Microsoft Project等。
2.2配置管理
配置管理过程是对处于不断演化、完善过程中的软件产品的管理过程。其最终目标是实现软件产品的完整性、一致性、可控性，使产品极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。常见的用于支持配置管理的工具有CVS、Subversion、VSS、StarTeam、CC等等。我们选择VSS2005为团队配置管理工具。主要原因是：VSS为轻量级平台，便于部署和迁移;VSS与微软发布的产品Visual Studio.NET2008/2010等兼容性非常好。
配置管理模板包括PP(项目计划)、RD(需求)、TS(设计)、V&V(验证与确认)等环节的各类文档，如需求规格说明书、项目计划、RD_用例报告、TS_概要设计说明书、详细设计说明书、数据库设计说明书、安装维护手册、测试计划、测试方案与单元测试记录等。
2.3项目建模
方案采用的建模工具有Enterprise Architect与PowerDesigner。
Enterprise Architect是以目标为导向的软件系统。它覆盖了系统开发的整个周期，除了开发类模型之外，还包括事务进程分析，使用案例需求，动态模型，组件和布局，系统管理，非功能需求，用户界面设计，测试和维护 等。Enterprise Architect是一个完全的UML分析和设计工具，它能完成从需求收集经步骤分析、模型设计到测试和维护的整个软件开发过程。它基于多用户Windows平台的图形工具可以帮助您设计健全可维护的软件。除此，它还包含特性灵活的高品质文档输出。用户指南可以在线获取。
Sybase PowerDesigner是一个"一站式"的企业级建模及设计解决方案，它能帮助企业快速高效地进行企业应用系统构建及再工程(Re-engineer)。使用该工具可以设计数据流程图、概念数据模型与物理数据模型，包括了数据库建模的全过程。该工具在项目中主要用于数据库建模。支持数据库的正向和反向工程，便于数据字典维护与调整。
2.4需求管理与Bug跟踪
我们采用Mantis作为项目管理和Bug跟踪平台。Mantis是一款基于Web的Php+Mysql的开源BUG管理系统，一款简单实用的系统，具有截图功能和强大的报表功 能。Mantis还具有良好电子邮件支持，可将需求与Bug的各种状态定义按照预定设置发送到项目组相应邮箱。
对于新增需求变更，经历提出需求、确认需求、开发需求、测试需求到发布需求五个阶段，这五个阶段分别由需求工程师、开发工程师、测试工程师与配置管理工程师进行完成。通过Mantis提供的基于Web的协作系统，可以很方便的进行需求变更管理和跟踪。
对于已发布的项目所产生的Bug，通过Mantis也可以进行记录、跟踪。其邮件提醒功能使得Bug状态一旦发生改变，会立即通知到相关责任人进行处理。同时，其强大的统计和报表功能也便于统计各项目的Bug量，统计测试人员报告的数量等关键值。
2.5代码自动化生成
轻量级项目均采用三层结构进行设计。三层结构模式如图2。
图2三层结构框架
三层结构包含:表示层(UI),业务逻辑层(BLL),数据访问层(DAL)，各层特点如下：
数据访问层:主要是对原始数据的操作层。可以操作数据库、文本文档或XML文件等多种数据格式，执行对数据库的增、删、查、改操作。数据访问层还可以通过OR映射进行扩充。
业务逻辑层:是系统的核心层，位于数据层和表示层中间，主要实现业务规则制定与业务流程实现。业务逻辑层直接调用数据层，并接受表示层的调用，起到承上启下的作用。
表示层:表示层是与用户直接交互的一层，主要处理用户的输入操作，提供交互式接口。在项目实现过程中，表示层一般为WebForm或WinForm等形式。
三层结构的划分，体现了“高内聚、低耦合”的设计思想，有效降低层与层之间的依赖，增强各层的复用性，有利于标准化开发。但三层结构也存在着降低性能、级联修改等问题。但轻量级项目一般侧重于业务流程，对于系统性能要求不高，而且计算机芯片的发展使得项目开发效率越来越比性能更重要。因此，轻量级软件项目均采用三层结构设计。
除此之外，还有业务实体层(Model)，这个层主要内容是存放可持久化的实体类;通用工具类库(Common)，主要用于存放通用的管理类库。类库的存在形式一般为Static类和Static方法。由于开发模式基本相似，所以开发过程中的大量相似代码，如：实体类、数据库操作类、UI界面，均可采用工具生成。.NET平台下比较优秀的代码生成工具有李天平的动软.NET代码生成器Codematic和国外成熟的代码生成器CodeSmith。
轻量级项目采用动软.NET代码生成器为主要生成工具。动软. NET代码生成器Codematic是一款为.net程序员设计的自动代码生成器，Codematic生成的代码基于面向对象的思想和三层架构设计，结合了微软Petshop中经典的思想和设计模式，可以通过反射支持多数据库，支持对连接字符串加密等。Codematic在项目中主要针对数据库中的表或视图生成表示层、业务层、数据层及实体等代码。使得开发人员完全从重复的录入过程中解脱。最新版本的Codematic还支持模板语法，开发人员可根据实际项目需要生成相应的表示层或数据层的SQL代码。以下是动软.NET生成器生成的Visual Studio .NET2010解决方案结构。
3结束语
本文根据中小型研发项目实际需要，提出了一种轻量级开发的项目管理解决方案。方案主要针对项目计划管理、配置管理、项目建模、需求管理与Bug跟踪、代码自动化生成5个方面进行了定义和分析，给出了各过程中最佳的解决方案和管理工具。轻量级的项目管理解决方案已经大量应用于团队所承担的各类研发项目中，与方案实施前相比，开发更高效、项目进度可控，能有效的提高软件产品质量。
参考文献：
[1]季丽萍.浅谈.NET三层结构及其应用[J].福建电脑,2009(6).
[2]李立芳,周小平.软件项目管理活动浅析[J].中国科技信息,2010(10).
[3]范振钧.基于ASP.net的三层结构实现方法研究[J].计算机科学,2007(4).
[4]孙继红.基于.NET三层架构的网上商城设计与实现[J].电脑编程技巧与维护,2008(16).
[5]于红波.三层结构各层次的实现技术研究[J].山东纺织科技,2008(1).
[6]刘宇翔.软件项目管理的流程设计分析[J].科技资讯,2010(36).
[7]邹晖.软件项目管理开发与应用[J].中小企业管理与科技:上旬刊,2011(5).
[8]徐朝辉,樊银亭.MVC设计模式在.NET三层结构开发中的研究和实现[J].北京电子科技学院学报,2007(2).
作者：翟靖轩
摘 要： 本文从软件项目管理课程的教学实践出发，对笔者之前提出的敏捷软件项目管理教学方案进行了改进，文中描述了改进过程和改进效果，体现了自我改进、不断创新的教学改革精神。
关键词： 软件项目管理;敏捷;教学方案;教学改革
本文著录格式：王芳，秦映波. 敏捷软件项目管理课程教学方案实践过程改进[J]. 软件，2020，41(10)：184186+197
【
【Key words】： Software project management; Agile; Teaching scheme; Educational reform
0 引言
軟件项目管理课程是软件工程专业本科阶段的必修课，对培养具有实践和管理能力的软件开发人才具有重要的意义[1]。然而很多人觉得大学时候学的软件项目管理相关内容很“虚”，那是因为大学期间的软件项目管理更侧重理论，理解起来枯燥乏味，很难学以致用;学生没有实际项目演练机会，学的东西没有办法马上进行实践;所有的概念都只是文字而已，根本谈不上理解为何需要这样的管理流程、管理方法和工具、技术标准等。
而对于有6年互联网公司研发经验、2年项目管理经验、2年教学经验的笔者而言，大学时期学软件项目管理当然是非常有用的。在真正的软件开发工作中，不管用什么开发语言，不管是前端和后端，可以确定的说，现代软件项目开发都离不开软件项目管理知识的应用。学好了软件项目管理，工作可以按时完成，软件质量有保证，开发的时间和成本都可控。实践中遇到的问题，要从理论和实践两个方面去寻找答案，如果没有上过这些课程，就需要重新学习。可是在日常工作中，遇到了实际问题，留给我们解决问题的时间是不多的，所以未必来得及重新学习。目前处于本科阶段的学生们当然无法知晓这一因果联系。
作为软件项目管理课程的教师，最重要的工作就是打破学生对该课程的不良印象，把理论知识和鲜活的案例结合起来，和学生一起探讨这些知识点背后的历史和现实意义，让学生认识到此课程的价值，调动学生的学习兴趣、提高学生的实践能力。
1 软件项目管理课程教学方案研究与实践
国内重点大学的教学团队走在软件工程系列课程改革的前列。以韩万江副教授为代表的教学团队结合互联网时代的软件工程发展，重新构建课程体系和教学内容。笔者通过北京邮电大学《软件项目管理》精品课程在中国大学MOOC的在线课程，深入学习了重点大学相关课程的课程内容和教学模式。
这些课程的教师们在教授软件工程系列课程的基本概念、基本原理和基本方法的同时，更重视软件工程实践训练。这些课程突破以开发生命周期安排教学单元的形式，从可实践的角度进行案例教学和项目实战;以Web应用开发项目为主线，完成基于敏捷模型的项目开发和管理过程，并构建基于云服务的课程项目实验环境，将过程和工具结合在一起，以实现“做中学”和“基于项目的学习”;通过贯穿始终的项目案例和情景项目展示，让学生切身体会软件项目管理过程从而更好地将软件工程思想和软件项目管理理论与实践相结合[2-5]。
笔者通过对软件项目管理课程相关教学方案的学习[6-8]，结合自身企业软件开发和项目管理经验，针对本学院软件工程专业软件项目管理课程进行了教学改革，对软件项目管理课程的教学内容、教学方式、考核制度等方面进行了详细规划和设计，形成了一套符合当前互联网行业软件产品开发规律的、让学生真实体会软件产品迭代过程的敏捷软件项目管理教学方案[9]。
经过对本学院2016级和2017级软件工程专业学生大三上学期《软件项目管理》课程的教学改革，教学效果得到了各位同学的肯定。同学们经过一个学期的团队项目实践，在做的过程中不断学习，从产品规划到项目部署，逐渐找到适合自己的角色，补充该角色应该具备的知识和技能，为毕业后选择合适的职位积累了宝贵经验。很多学生把这次实践经验写在实习简历中;还有些团队的项目成了社团的工作平台、为师生工作和学习提供便利的小程序、大学生创新创业项目等。
2 软件项目管理课程教学方案改进
在过去的两年中，笔者所在学院的软件项目管理教师团队不断总结经验教训，通过对教学方案实施过程中遇到的问题进行整理和思考，在原有方案的基础上完成了4项改进。
2.1 整合教学资源
我校软件工程专业在软件项目管理课程中使用北京邮电大学的韩万江副教授的《软件项目管理案例教程(第4版)》，该教材在中国大学MOOC上有精品课程《软件项目管理》[2]。受该精品课程的启发，我校也在超星学习通建立了该课程的线上学习资源，方便学生在线学习和交流。学生按照教学计划、结合自身情况随时随地地在线上学习课程理论基础知识，通过题库练习巩固理论基础。在线学习平台还有利于教师和学生以及学生和学生之间的互动交流。图1为我校软件项目管理课程资源和题库。
2.2 优化项目选题
学生在自主选择项目时，往往面临缺乏用户场景的难题。如果学生无法设身处地理解用户需求，就无法保持产品持续迭代的热情。课程提供的可选题目均来自2018年度和2019年度微信小程序开发大赛各赛区决赛入围名单(微信小程序开发大赛为每年上半年，而软件项目管理课程为每年的下半年)，绝大部分项目需求来源于校园生活和学习。可选题目仅供参考，大家可根据自身意愿和生活学习过程中的实际需求进行思考或扩展，最终产品名称可自行决定。但选题必须从解决实际问题出发，来源于生活和学习，服务于生活和学习。
2.3 优化团队组建规则
在学生自愿组队的基础上增加教师干预：一是根据个人意愿将女生分散到不同团队，女生往往对产品设计、团队管理更擅长，避免女生扎堆的团队出现。二是将个别不能成团的学生安排入整体能力较高的团队，以便观摩学习，在良好的氛围中进行自我改进。团队内部要明确各项工作的负责人，确保项目过程的产出有责任人，避免抱大腿、打酱油等不公平现象的出现。
2.4 鼓励过程分享
要鼓励学生分享和互动，鼓励做得好的团队分享自己的创意和成果，不但为其他团队树立了学习的榜样，而且使自己的工作更有价值，能起到相互激励的作用。以17级软件工程专业的4个班级为例，有较多的团队愿意站上讲台来分享团队成果，图2为分享团队及项目列表。教师要鼓励学生将遇到问题的抛出来，分享后马上收集学生的问题，图3为学生对某项目的提问列表(筛选了学生对某项目的提问)。教师将问题整理后反馈给分享的团队，他们在准备后再次进行分享，精准地回答学生提出的问题。这一过程充分體现了“以教师为主导，以学生为主体”的教学理念。在最后阶段的课程总结问卷调查中，有超过半数的同学表示自己受益于分享，或从中学到知识，或由此受到鼓舞，图4为某同学通过问卷调查表单提交的课程总结内容。
3 结语
软件行业日新月异，新的技术和工具层出不穷，软件工程专业相关的课程内容和教学手段也必须要“与时俱进”，符合市场需求。软件项目管理需要与实践结合紧密的特点，对师资提出了更高要求。为了让学生了解到人们广泛使用的软件是如何开发出来的，课程教师需要有丰富的项目经验，有第一手的流程、文档、数据，能让学生真切感受到了开发流程、需求管理、质量控制的作用，体会到概念和理论并不是很有道理的废话，而是对工业界经验的总结。由此引发学生对互联网行业的关注，激起学习兴趣，使学生掌握规范化的软件开发和质量控制过程，培养良好的团队合作能力和实践能力，为日后从事软件开发相关工作打下坚实的基础[10-11]。
参考文献
[1]张永平， 刘燕， 邵星. “案例驱动+项目实践”的软件项目管理课程教学实践[J]. 计算机教育， 2015， 23： 115-119.
[2]韩万江， 姜立新. 软件项目管理案例教程(第4版)[M]. 北京： 机械工业出版社， 2019.
[3]韩万江， 姜立新， 张笑燕， 等. 基于工程化的软件工程教学案例研究[J]. 软件， 2019， 40(3)： 78-87.
[4]韩万江， 张笑燕， 陆天波， 等. 软件工程专业认证的新思路研究[J]. 软件， 2015， 36(3)： 37-40.
[5]韩万江， 张笑燕， 陆天波. 《软件项目管理》课程中理论与实践的交融关系[J]. 软件， 2014， 35(2)： 165-168.
[6]Bob Hughes， Mike Cotterell 著. 廖彬山， 周卫华 译. 软件项目管理(原书第5版)[M]. 北京： 机械工业出版社， 2010.
[7]Andrew Pham， Phuong-Van Pham著. 崔康 译. Scrum实战—敏捷软件项目管理与开发[M]. 北京： 清华大学出版社， 2013.
[8]邹欣. 构建之法—现代软件工程[M]. 北京： 人民邮电出版社， 2015.
[9]王芳， 邓一星， 秦映波. 敏捷软件项目管理课程教学方案研究与实践[J]. 软件， 2018， 39(4)： 77-81.
[10]韩万江， 张笑燕， 陆天波. 基于混合式教学的软件项目管理课程建设[J]. 大学教育， 2015， 10： 161-162.
[11]邓一星. 软件工程专业校企合作形式的探索与实现， 2016， 37(8)： 54-56.
作者：王芳 秦映波
摘要：本文提出了一种新型的软件项目管理的课程实践方案，给出了相应的考核和评价机制，并在最后对课程实践的效果进行了总结分析。
关键词：软件项目管理;实践;培养方案;开源教学
1引言
未来5年，中国软件从业人员将从目前的90万人增加到250万人左右，有望推动我国IT产业的更加快速发展。然而，我国IT行业在迅速发展的同时，也面临着一些挑战。
1.1软件企业现状
随着计算软件规模和复制度的增加，我国的软件企业正在从“手工作坊式”向“软件工厂式”转变。许多中小型软件企业的管理模式十分退后，面临着很大的挑战，它们要么成功转型，要么在竞争中被淘汰。而转型成功的关键是能否形成一个合理的软件项目管理模式。根据文献[0]的论述，我国项目管理发展滞后的一个重要原因就是缺乏合格的项目管理人才。可以预见到，我国软件企业对项目管理人才的需求将会急剧增加。
1.2软件人才现状
在近几年内，尽管中国软件从业人员将会大大增加，但是中国软件人才目前仍然处于两头小、中间大的不合理人才梯队结构[0]，即中端人才过剩，高端和低端人才缺乏。从目前国内的软件高端人才数量现状与软件业较先进的国家相比，未来五年，国内软件业高端人才至少缺口20万人[0]。而且目前国内的软件高端人才中却普遍存在着“重技术轻管理”和“管理缺乏规范性”等问题，执行软件项目管理的能力不强。这更加重了软件企业对项目管理人才的需求。
1.3软件项目管理人才培养的现状
在软件企业对项目管理人才的需求不断升温的情况下，社会上出现了许多软件项目管理的培训机构。虽然这类培训一般都是费用高、时间短，很难达到预期效果，但是因为项目管理人才供不应求，这类培训仍然很有市场。
然而这类“救火式”的培养只能算是临阵磨枪。因为培训时间短，学生除了完成一些案例分析之外，很少有实践的机会，换句话说，学生在培训过程中主要获得了项目管理的理论知识。随着时代的发展，项目管理的理论不能固定不变，况且项目管理课程的历史较短，其底层理论尚未定型。文献[0]详细论证后指出，项目管理底层理论已显得陈旧，需要更加广泛和强大的理论作为支持。可见，在这种情况下，软件项目管理的培训不应只以理论为主，而需要伴以更多的实践内容。
在我国软件企业对项目管理人才的需求不断升温的情况下，软件项目管理人才的培养不能依赖于社会上的培训机构，各高校应增加投入，承担起软件项目管理人才的培养，这样才能在数量和质量上都满足新形势下我国对软件人才的需求。
在各高校中开设“软件项目管理”课程至今已经五年多了，其教学模式一直在不断完善。软件项目管理课程与程序设计、算法分析、数据库设计等其他软件类课程的一个重大区别在于学生的实践机会很少。没有参与到一个软件项目中而去谈软件项目管理的实践，这显然是不现实的。然而，学生在工作之前很难有机会参与软件项目，要体验规范的软件项目管理就更加不可能。所以，为“软件项目管理”课程增置相应的课程实践是非常必要的。
1.4相关研究以及本方案的特点
文献[0]提出了一种较为完整的软件项目管理培养方案，内容包括了教学与实践，但是实践的比重偏低。文献[0]则提出了一种让学生在虚拟的项目中锻炼实践能力的新构想，并对实践效果做了简要分析，但是并没提及项目的来源和去向，以及项目的难度问题。本文延续了笔者在文献[0]中提出的“开源教学”思想，补充了文献[0]中未提及的内容，强调Learning by Doing的模式[0]，提出了一种新的“软件项目管理”课程实践方案，包含了情景演练和项目实践这两大重要内容，可以与文献[0]的培养方案结合，形成一套更加完整的，符合我国新形势要求的“软件项目管理”培养方案。
2实践方案概述
2.1培养目标
作为软件项目管理课程的一部分，本实践方案的目标与整个课程的培养目标保持一致，即培养学生对项目管理和控制能力，而在实际培养过程中，则体现为培养学生的协同开发能力、学习能力、沟通能力、表达能力和领导能力，使其具有开阔视野，合作、创新的精神[0](如图1所示)。事实上，这五方面能力也必须在实践过程中才能得到真正的锻炼。
2.2培养模式
本实践方案强调Learning by Doing的模式。这种模式最早是由美国卡奈基·梅隆大学提出的，目的在于培养工科学生实践能力[0]。“Learning by Doing”的意思就是从在做的过程中学习。学生通过自己动手实践，获得对客观知识的最直接认识，再经过归纳和总结，形成自己的知识，从而完成整个学习过程。这种模式将彻底改变过去“填鸭式”的教学，让学生处于教学的中心地位。
文献[0]提出了将Learning by Doing的模式应用于软件项目管理的教学的一种方式。他们通过软件模拟了现实的软件项目管理的情景，为学生提供了方便易用、仿真度高的实践平台。学生可以通过类似于游戏的方式来体验软件项目管理，能够尝试各种不同的决策以验证自己的想法。事实证明，他们以这种方式成功地将Learning by Doing的模式应用于软件项目管理课程。
3课程实践内容
3.1情景演练
情景演练是设置于课程实践前期的实践内容，由老师或助教虚拟一个项目管理过程中的情景，将学生置身于情景之中，锻炼学生解决实际问题的能力。
●情景的设计
这种虚拟情景并非纯属虚构，而是由任课老师或助教根据实际的软件项目管理案例而设计的。此外，还应向学生提供一个较为清晰的项目背景，以及情景的上下文，争取让学生“身临其境”。情景演练的内容则贯穿软件项目管理的五个过程组和九大知识领域，可以为学生提供软件项目管理中可能遇到的各种实际问题。
●演练的方式
学生以小组为单位进行情景演练，每个组员扮演情景中的一个角色并完成其特殊的工作。必要情况下，需要老师或助教扮演辅助角色。演练的时间视具体情景而定，演练一个项目的收尾也许只要一两天，而演练一次项目计划的时间则至少数倍与前者。演练完成之后，学生将向上台报告演练结果，并听取老师的点评和同学的意见。
在多次情景演练中，学生可以扮演不同的角色，体验项目管理中的不同工作，能够更好的认识自己的长处和不足，确定下一步的学习重点。
情景演练可以让学生“身临其境”地体验到项目管理中所遇到的各种问题，仿真度高于案例分析，是下一步项目实践的必要基础。
3.2项目实践
相对于先前的情景演练，项目实践更加“真刀真枪”。在项目实践中，学生仍然以组为单位进行实践，通过团队协作完成一个软件项目。
●实践的形式
在整个项目实践中，任课老师或助教扮演项目的甲方，而学生团队则为乙方，乙方按照甲方的需求完成一个实践项目。此外，任课老师或助教仍然会在适当的时候给予学生必要的指导。
当一个学生团队接选定一个项目之后，他们自发地选择其中一位成员作为项目经理，然后由项目经理主持完成系统分析员、开发人员、测试人员等职位的任命。任命的过程需要参考学生在情景演练中表现，争取让每个学生才能展现自己的特点。接下来，学生团队就可以在项目的五大过程中发挥他们所学的九大领域的知识，利用他们在案例分析和情景演练中积累的初步经验来解决项目实践中遇到的各种问题。
在实践过程中，学生依然可以更换角色。有的学生可能会在项目的不同阶段扮演不同的角色，承担不同的任务;有的重要角色(如，项目经理)可能会实行“轮岗”机制，让更多学生有机会体验该角色的工作。
项目收尾之后，老师将组织一个报告会，让每个团队介绍自己的工作情况，分享经验与教训，讨论项目管理中问题的解决办法。这个经验交流会使得整个项目实践得以升华，是学生的一次宝贵经历，即便是对于软件企业中的项目经理，这种经验交流也是十分难得的。
●项目的来源与去向
项目的选题是项目实践中比较重要的问题。首先，所选项目必须贴近实战，这就要求不能凭空想象一个没有实际需求的项目，因为这会导致项目的范围难以界定。最好就是任课老师正在负责某个项目，可以将其中的子项目交给学生实践。但是这样做风险较大，项目经理不便由学生来担任，而且项目的时间、规模和难度也不一定适合。
笔者认为比较理想的项目来源是开源社区，上面有大量的开源项目，而且资料齐全，有足够大的选择空间，学生可以很容易地找到时间、规模和难度都适中的项目。
还有另一种情况则是学生本身有了很好的构想，希望开发某种软件，只是有待实现。这时也可以作为一个实践项目。最后如果实现了这种新的软件，何不将其开源，从而将好的构想发扬光大呢?笔者提倡从开源社区获得实践项目，并把项目实践的成果贡献给开源社区。
3.3开源教学
笔者在文献[0]中首次提出了“开源教学”的想法，而在本软件项目管理实践方案中，“开源教学”的思想可以得到较好的体现。
当前IT行业中有许多非常成功的软件都是由开源软件发展过来;有许多软件为了得到更好的发展，也都纷纷加入到开源社区之中，使得开源社区迅速成为一个巨大的免费软件项目宝库。在国外，开源社区的一大主力就是大学生。大批的学生本着学习和交流的目的在开源项目中工作，不仅自身能力得到了很好的锻炼，还可以为后人留下宝贵的软件财富。当前国外的开源社区不但带动了软件产业的发展，同时还培养了大量优秀的软件人才，可谓一举两得。然而国内的开源软件起步较晚，发展较慢，急需大量的高校学生投身开源事业。
本文软件项目管理实践方案的项目实践部分提倡从开源社区中选题的一个重要目的就是引导学生参加开源项目，加快我国开源事业的发展。
在软件项目管理课程实践引入“开源教学”的优势主要有：
(1) 开源社区为学生提供了极大的选题空间。国内外的开源社区中都有大量的软件项目，学生可以很容易地加入到开源项目中去，选择最合适的项目作为实践。
(2) 有齐全的技术资料和强大的技术支持。只要加入到开源项目，学生就可以获得详尽的项目文档，并且可以方便地与其他开发者交流，共同解决问题。
(3) 提供一个展示作品的平台。学生团队完成了自己得意佳作之后，完全可以将其贡献到开源社区，让更多人了解自己的作品，以可以让其他人共同参与完善这个作品。
(4) 壮大国内开源社区，带动软件产业发展，同时培养高素质的软件人才。
在课程实践效果分析中将会给出开源项目实践与一般项目实践的对比。
4课程实践的考核与评价
考核与评价是本软件项目管理实践方案的一个重要环节，它一方面能够起到督促作用，激励学生认真完成课程实践;但更重要的是考核与评价机制可以帮助学生认识自己的学习的效果，发现自己在软件项目管理中的长处与不足，对将来运用软件项目管理的知识或在软件项目管理领域深造都有重要的参考价值。
本课程实践的考核与评价并非在实践结束之后进行，而是贯穿整个软件项目管理的实践过程。从课程实践开始，老师就对学生的表现进行记录、考核和评价，直到学生完成所有的实践内容。整个考核与评价过程主要分为三个部分：情景演练的考核、项目实践过程的考核和项目实践结果的考核。三个部分的比例如图2所示。
1. 情景演练的考核
情景演练中考核学生在特定场景中对各种实际问题的处理能力。由于每个学生可以经历多种情景，对学生的能力的考核比较全面。这个阶段的评价占学生实践总成绩的25%，在下一阶段确定学生在项目实践中职务的时候，这个评价也起到关键作用。
2. 项目实践过程的考核
在项目实践过程中，学生的每一项活动都会被记录，作为考核和评价的依据。如果说情景演练侧重于在多个“点”上考核学生的能力，那么项目实践过程则是在多个活动主线上考核学生。相对于情景演练，这种考核更加全面和有参考价值，占学生实践总成绩的55%。
3. 项目实践结果的考核
在项目实践的最后有一个项目报告会，学生以团队为单位汇报项目实践的结果，并分享经验和教训。学生在报告会中的表现在一定程度上反映其在实践过程中收获，这部分考核占学生实践总成绩的20%。
5课程实践效果分析
我们在计算机专业本科的一个班中实验了这种软件项目管理课程实践方案，将学生分为三组，每组10人。其中A和B两组的实践项目来自开源社区，而C组则选择实验室中的实际项目作为对照。
在选题过程中，因为开源社区中项目资料丰富，A组和B组的学生表现出浓厚的兴趣;而C组只能在实验室范围内选题，可选范围比较小。
另外，C组实践的项目是真实项目的子项目，关系到整个项目的顺利进行，所以C组项目经理的决策需要经老师或助教的批准，受到较多的约束，锻炼机会较少。
而从项目的结果上看，C组的项目完成效果较好，A组和B组项目则是基本达标。课程实践结束后，三组的学生均表示希望在所做的项目中做更进一步的研究，但C组因为实验室项目的保密因素，不能在原基础上进行研究。而A组和B组则可能会将实践的成果重新贡献到开源社区，让更多人参与该项目。
总体来说，参加课程实践的学生都表现出较高的积极性，部分学生能够较恰当地运用软件项目管理课程中的知识。开源教学对于提高学生的积极性起到了重要作用，虽然选择开源项目的组实践结果稍差，但是在实践过程中更加自由，更能够锻炼学生的实践能力。
6结束语
软件项目管理人才的培养关系到我国新形势下的软件产业发展，各高校应该承担起培养高素质软件项目管理人才的责任。而培养关键在于理论和实践的结合，尤其实践能力的培养，高校应重视这个被长期忽视的问题。本文介绍的软件项目管理实践方案坚持Learning by Doing的教学模式，以开源教学为手段，是课程实践模式的一次新的探索。
参考文献
[1] 徐庆艳.我国项目管理滞后的原因及发展途径[J].集团经济研究,2005,(5).
[2] 中国软件中端人才过剩，高端人才缺口20万[EB]. 搜狐教育.http://learning.sohu.com/20070709/n250962964.shtml 2007-07-09
[3] 泽琳,李红,杜卿. 软件产业人才需求与软件人才培养[J]. 计算机教育,2005,(8).
[4] 刘发贵,李育成. 论计算机专业学生软件项目管理能力的培养[J]. 计算机教育,2005,(8).
[5] 实战模拟的“软件项目管理”课程实践与考核[j]. 计算机教育,2007,(3).
[6] MVarcio de O. Barros, Alexandre R. Dantas, Gustavo O. Veronese, and Clⅴaudia M. L.Werner. Model-driven game development-experience and model enhancements in software project management education, Softw. Process Improve. Pract. 2006; 11: 411-421.
[7] Learning by Doing. http://west.cmu.edu
[8] Koskela, L. and Howell, G.. The Underlying Theory of Project Management is Obsolote. Proceedings of the PMI Research Conference, 2002:293-302.
作者简介
刘发贵，华南理工大学计算机学院计算机软件工程系系主任、计算机技术中心副主任。教授，硕士生导师。
地址：广州五山路381号华南理工大学510640
电话：020-87110893
13600066003
E-mail：fgliu@scut.edu.cn
作者：刘发贵 刘文谦
1.
开发框架
开发的系统中所应用的技术都是基于JavaEE，技术成熟稳定又能保持先进性。采用B/S架构使系统能集中部署分布使用，有利于系统升级维护;采用MVC的开发模式并参考SOA体系架构进行功能设计，使得能快速扩展业务功能而不会影响现有系统功能的正常使用，可根据实际业务量进行部分功能扩容，在满足系统运行要求的同时实现成本最小化。系统采用分布式部署，系统功能隔离运行，保障系统整体运行的稳定性。
图1.开发框架与体系结构图
1.1.
web端技术栈
(1)前端采用elementUI/jquery/bootstrap/vue实现，前端和Controller交换数据基于json格式。
1.2
业务端技术栈
(1)
业务端基于springboot、springMVC、JPA、SpringData技术栈构建，对于复杂的系统则采用springCloud构建。
(2)
四层分隔：controller(Facade)/service/dao/entity,其中façade主要用于生成json，实现和前端的数据交换。
(2)命名：按照功能模块划分各层包名，各层一致。
2.
系统安全保障
2.1
访问安全性
权限管理是系统安全的重要方式，必须是合法的用户才可以访问系统(用户认证)，且必须具有该资源的访问权限才可以访问该资源(授权)。
我们系统设计权限模型，标准权限数据模型包括
：用户、角色、权限(包括资源和权限)、用户角色关系、角色权限关系。权限分配：通过UI界面方便给用户分配权限，对上边权限模型进行增、删、改、查操作。
基于角色的权限控制策略根据角色判断是否有操作权限，因为角色的变化
性较高，如果角色修改需要修改控制代码。
而基于资源的权限控制：根据资源权限判断是否有操作权限，因为资源较为固定，如果角色修改或角色中权限修改不需要修改控制代码，使用此方法系统可维护性很强。建议使用。
2.2
数据安全性
可以从三个层面入手：操作系统;应用系统;数据库;比较常用的是应用系统和数据库层面的安全保障措施。
在操作系统层面通过防火墙的设置。如设置成端口8080只有自己的电脑能访问。应用系统层面通过登陆拦截，拦截访问请求的方式。密码不能是明文，必须加密;加密算法必须是不可逆的，不需要知道客户的密码。密码的加密算法{
MD5--不安全，可被破解。需要把MD5的32位字符串再次加密(次数只有你自己知道)，不容易破解;加密多次之后，登录时忘记密码，只能重置密码，它不会告诉你原密码，因为管理员也不知道。
3.
项目计划的编制和管理
本公司项目基于敏捷过程的方式组织，项目计划基于需求和团队反复讨论的过程。在开发系统时都经过了解需求，开需求分析会议，确定开发任务，推进开发进度，测试，试点，交付等开发步骤，其中具体内容有：
1，了解需求：跟客户沟通，充分了解对方的需求，然后对需求进行过滤，最后整体成需求文档
2，需求分析会议：也就是项目启动会议之后要做的事情，对拿来的需求进行讨论，怎么做满足需求。主要对需求进行全面的梳理，让开发，产品，项目都熟悉整个需求。
3，确定开发任务：根据敏捷开发法则，需求变成一个一个功能点之后就是安排开发任务了。根据团队现有的资源合理分配任务，和时间节点
4，
推进开发进度：在开发的实际过程中，注意节奏的把控，注重功能点完成的时间点。
5，
每一个功能点完成之后都会有测试工程师进行单元测试。
6，试点单位进行试用，然后解决问题。
7，交付
4.
项目进度保障体系
4.1制度保障
实行项目经理负责制，建立强有力的开发指挥机构和开发保障体系，投入能保证开发进度如期实现的足够的开发队伍，实行专业化开发。建立从项目经理到各开发人员的开发任务，全面、及时掌握并迅速、准确地处理开发过程中遇到的各种问题。对开发过程中遇到的需求变更进行协调管理，对重大关键问题超前研究，制定措施，及时调整开发的公共类保证开发过程的连续性和高效性。强化开发过程的时间点把控问题，对开发任务实行动态管理。保证在时间点内完成开发任务。实行内部经济承包责任制。使责任和效益挂钩，个人利益和完成工作量挂钩，做到多劳多得，调动开发团队、个人的积极性。编制科学合理的总体开发进度计划，运用专业管理软件，对开发计划进行动态控制;并在总计划的基础上分解明确的月及旬计划，项目经理抓住主要技术难点，严格按计划安排组织开发，重点抓好关键技术的开发。定期检查开发计划的执行情况，及时对开发进度计划进行调整;在开发过程中，根据开发进展和各种因素的变化情况，不断优化开发的方案，保证各开发有条不紊的执行。
4.2开发进度开发工期保证措施
任务分发将利用一流的开发策划、高效的组织、科学的领导和动态的控制，用一流的运作与协调、一流的技术框架与技术、一流的团队素质等来实现一流的管理，从而通过过程控制实现最终产品的精品，满足客户对工期、质量等各方面的要求。
完善的开发计划保证体系是保证项目工期的纲要，掌握开发管理主动权，全面而宏观的控制整个开发的过程，是保证开发进度的关键。通过完善的开发计划保证体系，采用先进的开发计划计算、设计软件，制定出科学合理的开发进度计划。
1.
编制三级网络计划
在开发过程中中我单位将分级编制网络计划来控制整个项目的开发。
(1)一级网路计划
根据项目总工期控制项目各阶段里程碑目标。
(2)二级网路计划
根据各阶段分项业务的工期目标控制分解成分部目标。
(3)三级网路计划
主要技术使用控制周计划和日计划。通过对关键技术开发编制标准业务，建立计划统计数据库，利用项目管理信息系统对工期进行全方位管理。
2.制定派生计划
根据总控工期、阶段工期和分项业务工作量制定出技术保障、商务合同、物资采购、设备定货、人力资源等派生计划，是进度管理的重要组成部分，按照最迟完成或最迟准备的插入时间原则，制定各类派生保障计划，作到各项工作有备而来，有章可循。
工期保证体系框图
技术保证体系
综合保证体系
组织保证体系
技术总监
开发组织设计
技术总监
开发人员
测试人员
试验室
项目经理
制
度
保
证
奖惩制度
岗位责任制
经济责任制
开发团队
单元测试
技术培训
测试用例
开发进度计划保证
月度计划
季度计划
计划
技术工作责任制
技术标准
设计文件
招标文件
技术规范
技术工作标准化
开发团队
实现工期目标
4.3施工进度三阶段控制措施
（一）开发进度“事前控制”
1.积极做好业务需求，业务流程等准备工作，为自己尽早投入开发创造好条件，把准备工作做细做充分，确保按时无障碍开发。
2.编制详细的开发进度计划，包括需求文档，业务分工计划，业务流程等。
3.关键技术或特殊技术编制相应的开发进度计划，制定相应的节点，编制节点控制计划。
4.编制开发节点实施细则，明确搭接和流水的节拍。
（二）开发进度“事中控制”
1.严格审核开发人员的进度计划、季度计划、月计划，并监督各人员按照已制定的开发进度计划进行开发。
2.在本项目开发期间，按开发进度需要，配备充足的开发人员，确保时间点的正常运行。
3.在开发期间，每周结束前，组织召开一次碰头会，协商解决当周开发过程中和第二周开发中将会发生的问题，应解决的问题决不拖延。
4.狠抓开发进度与质量，加强技术培训。只有在确保技术过关、质量的前提下才能求速度、讲进度、抓工期。
5.根据开发的实际情况，及时修改和调整开发进度，并定期向客户通报系统开发进展情况。
（三）施工进度“事后控制”
1.根据开发进度计划，及时组织测试人员通过事先编写的测试用例进行分项测试与系统测试。
2.定期整理有关开发进度的资料，汇总编目，建立相应的档案。
5.
项目质量保障体系
5.1过程中的保证
依据项目的软件特点、合作方的项目实施要求，采取需求分析，系统设计，软件项目计划，软件需求分析，软件模型设计，软件详细设计，单元测试设计，编写单元测试，系统培训，系统测试等一些列的措施在过程中保证项目的质量。
5.2技术方面的保证
公司研发人员均为国内高校分子计算机专业或招聘的高级技术人才，专业基础和工作经验扎实丰富，整个团队具有高级工程师、博士的人才搭配，具备强大的持续研发能力。
5.3软件质量管理责任分配
角色
职责
配置管理员
制定、创建和维护配置库，提供文档规范，并传达到各个部门。
QA(质量保证)
参与项目各个阶段的评审，进行过程评审和产品审计，检查文档和代码的规范执行情况
QC(质量控制)
软件测试是质量控制的主要手段，测试人员进行软件的测试设计和执行工作
5.4工作产品和活动
活动
责任人
工作产品
是否可裁剪
项目立项
项目经理
项目计划
否
配置管理员
配置管理计划
是
QA
质量保证计划
是
测试人员
系统测试计划
否
需求管理活动
项目经理
需求调研报告
是
需求规格说明书
否
用户、项目经理
用户确认书
是
QA
评审报告
是
设计过程、决策分析活动
设计组
概要设计说明书
否
界面设计图
是
详细设计说明书
是
项目经理
决策分析评议表
是
QA
评审报告
是
开发编码、集成过程活动
项目经理
版本发布记录
否
QA
评审报告
是
开发人员
程序代码
否
系统测试活动
测试人员
测试用例、测试报告
否
QA
评审报告
是
项目结项、交付与维护活动
项目经理
培训教材
是
用户手册
是
安装手册
是
项目总结报告
否
项目经理、客户
用户验收报告
是
QA
评审报告
是
项目跟踪与监控活动
项目经理
项目问题跟踪日志
是
QA
不符合项问题跟踪记录表
否
项目跟踪与监控活动检查单
是
风险管理活动
项目经理
风险管理列表
是
QA
风险管理活动检查单
是
配置管理活动
配置管理员
配置状态报告
是
变更请求审批表
是
变更跟踪记录表
是
QA
配置管理活动检查单
是
评审活动
项目成员
评审报告
否
QA
评审活动检查单
是
5.5评审
评审是以一种正式的形式进行，如有正式的、事先定义好的有关职责的各种角色，并遵循组织规定的流程。
对于任何工作产品的审计，都会组建与之对应的专门评审组，包括作者、主持人、记录员以及陪审员若干。评审组的成员可以包括PPQA、项目组成员，但不能有作者的直接领导或者管理者。
评审小组先召开一个预备，作者会针对工作产品向大家做个总体的介绍，例如讲解一下本工作产品的目标是什么，以及其相关的实现
细节、开发标准等。应该允许甚至鼓励评审组成员动手查看工作产品，或者查看开发过程中所用到的检查单。
评审小组的主持人负责确定什么时间开始真正的评审会议，在预备会和正式评审会议之间，评审小组成员对工作产品进行彻底检查，并依据相关标准和准则评审工作产品。
在预定时间，评审小组成员以会议形式聚在一起，依次对产品进行检查，主持人负责对整个会议的进展进行控制，记录员记录下这个过程。
在工作产品中发现的每一个缺陷都会被认真记录下来，并被适当分类。
会议结束后，负责人需要分析相关缺陷，找出产生此缺陷的原因并加以修正。
主持人应确保所有的缺陷都会得到解决和修正。如果过程需要加以变更的话，应将相关问题移交相关的质量保证人员。
阶段
评审内容
评审时机
参加人员
是否可裁剪
计划阶段
项目计划
项目启动会议
项目所有成员
否
配置管理计划
项目所有成员
是
质量保证计划
项目所有成员
是
系统测试计划
项目所有成员
否
需求阶段
需求调研报告
项目评审会议1
需求分析师、项目经理、系统架构师、设计组成员、QA
是
需求规格说明书
需求分析师、项目经理、系统架构师、设计组成员、QA
否
设计阶段
概要设计说明书
项目评审会议2
需求分析师、项目经理、系统架构师、设计组成员、QA
否
UI设计图
UI美工、需求分析师、项目经理、系统架构师、设计组成员、QA
是
详细设计说明书
需求分析师、项目经理、系统架构师、设计组成员、QA
是
决策分析评议表
需求分析师、项目经理、系统架构师、设计组成员、QA
是
编码阶段
代码检查(1)
项目评审会议3
开发组成员、项目经理、需求分析师、系统架构师、QA
否
代码检查(2)
开发组成员、项目经理、需求分析师、系统架构师、QA
否
测试阶段
系统测试用例
项目评审会议4
测试人员、项目经理、开发组成员、需求分析师、系统架构师、QA
否
系统测试报告(1)
测试人员、项目经理、开发组成员、需求分析师、系统架构师、QA
否
系统测试报告(2)
测试人员、项目经理、开发组成员、需求分析师、系统架构师、QA
否
发布阶段
用户手册
项目总结会议
项目所有成员
是
项目总结报告
项目所有成员
否
5.6质量保证(QA)
QA工作审计产品
文档
责任人
项目计划
项目经理
需求规格说明书
项目经理
概要设计说明书
项目经理
源代码
开发组
系统测试用例
测试组
系统测试报告
测试组
用户手册
项目经理
项目总结报告
项目经理
入最佳实践库的产品
项目经理
QA工作中需要审计的活动
活动
评审时机
项目立项
计划阶段
需求管理活动
需求阶段
设计过程活动
设计阶段
决策分析活动
设计阶段
开发编码活动
编码阶段
集成过程活动
编码阶段
系统测试活动
测试阶段
项目结项
发布阶段
交付与维护
发布阶段
项目跟踪与监控活动
每月一次
风险管理活动
每月一次
配置管理活动
每月一次
评审活动
每月一次
QA审计中的不符合项目问题
对QA审计过程中发现的不符合项问题要写入《不符合项跟踪记录表》，以邮件的方式发给问题的相关人员，做好和项目成员、项目经理、部门经理之间的沟通，问题的上报流程：项目组成员沟通解决——项目经理——部门经理——总经理。QA要对不符合项问题进行跟踪与监控，直到问题解决，QA验证并关闭不符合项。
6.
系统测试验收方案
系统测试验收主要包含以下四方面的工作内容，分别是验收测试、系统试运行、系统文档验收以及项目终验。
6.1.
验收测试
验收测试即对信息系统进行全面的测试，依照双方合同约定的系统环境，以确保系统的功能和技术设计满足建设方的功能需求和非功能需求，并能正常运行。验收测试阶段应包括编写验收测试用例，建立验收测试环境，全面执行验收测试，出具验收测试报告以及验收测试报告的签署。
6.2系统试运行
信息系统通过验收测试环节以后，可以开通系统试运行。系统试运行期间主要包括数据迁移、日常维护以及缺陷跟踪和修复等方面的工作内容。为了检验系统的试运行情况，甲方可将部分数据或配置信息加载到信息系统上进行正常操作。在试运行期间，甲乙双方可以进一步确定具体的工作内容并完成相应的交接工作。对于在试运行期间系统发生的问题，根据其性质判断是否是系统缺陷，如果是系统缺陷，应该及时更正系统的功能;如果不是系统自身缺陷，而是额外的信息系统新需求，此时可以遵循项目变更流程进行变更，也可以将其暂时搁置，作为后续升级项目工作内容的一部分。
6.3系统文档验收
系统经过验收测试后，系统的文档逐步、全面地移交给客户。客户按照合同或者项目工作说明书的规定，对所交付的文档加以检查和评价;对不清晰的地方可以提出修改要求，在最终交付系统前，系统的所有文档都需要验收合格并经双方签字认可。
6.4项目终验
在系统经过试运行以后的约定时间，双方启动项目的最终验收工作。最终验收的工作包括双方对验收测试文件的认可和接受、双方对系统试运行期间的工作状况的认可和接受、双方对系统文档的认可和接受、双方对结束项目工作的认可和接受。项目最终验收合格后，由双方的项目组撰写验收报告。
7.
技术服务与支撑
我公司在合同有效期内提供免费维护期和长期的技术服务，向用户用户相关技术人员免费提供原理和技术上的指导和咨询，使用户能正确熟练地使用本协议的软件开发及测试成果。
根据用户使用系统的相关部门人员现状，一旦系统安装调试完毕投入正常运行后，卓安公司在交付本系统的一段时间内，专门指派若干名专业工程师为用户使用部门进行指导培训和维护，直到用户安排的技术人员能完全接管本系统的操作管理为止。
7.1.
现场支持
系统在售后期间，提供7×24小时的技术支持服务。如系统出现故障，将保证30分钟远程响应;影响生产的故障4小时抵达现场，并派出专业工程师在8小时内排出故障;不影响生产的故障8小时内抵达现场，并派出专业工程师在2个工作日内排除故障。如在2个工作日内无法解决，将在2日内向用户方提出详细解决方案及日程安排，交给用户方确认。
7.2.
技术支持
长期电话技术咨询和技术服务和远程在线服务。用户可以随时拨打技术支持热线电话或通过远程协助进行有关技术咨询，专业技术人员会耐心解答用户的问题。免费提供需求预测、系统规划等支持。当用户需要对系统扩容、调整时，将免费协助用户准备预算、规范书、工程有关事项。
7.3.
常规维护
系统在售后期间，会安排工程师定期对系统进行运行检查。如有功能需求分析范围内的问题，及时进行修改;维护期后发现的在需求规格说明书范围内问题，同样及时进行修改。对用户提出的方便操作和易用等可用性方面的要求，尽可能满足用户要求，并保证在接到要求后两周内解决。用户提出性能要求，如属于软件编制因素导致性能较差，技术人员主动调整软件，以提高性能，保证在一个月内解决。
7.4.
变更管理
对系统的应用平台和开发、运行环境以及应用系统的变更和升级的详细资料第一时间提交用户。
8.
培训计划
8.1.1.
培训工作概述
用户软件系统项目建设完工后，为了使各个使用本系统的部门能熟练的操作系统，利用系统提供的功能来处理日常工作，本公司将对使用系统的相关部门员工进行一次全面的培训。
培训过程按系统使用部门划分，分别培训各部门使用的系统功能点及业务流程。另外为了用户管理需要，将重点培训2名系统管理员，培训系统管理相关功能。
8.1.2.
培训规范
由于培训过程涉及到时间、场地、人员等诸多不确定因素，本方案所提及项只作为参考大纲。实际培训安排因由主管部门统一规划，并下文到各系统使用部门。
培训的效果与参与人员的重视程度有很大的关系，客户各部门对参与人员要做好工作，引起重视。主管部门可以考虑是否需要在培训结束并且参与培训人员试用一段时间后，组织一次系统使用测验。
通过系统使用培训，达到以下目标：
Ø
使相关使用部门了解系统运作，熟悉系统功能。
Ø
使系统有效的推广到相关使用部门，让员工积极参与使用系统。
Ø
培训专业系统管理人员，深入了解系统功能，为系统业务功能扩展提供建议。
正本 LOGO GG市xxxxx管理局 XXXXXXXXXX平台建设项目 招标编号：
XXXXXXXX-XXX 技 术 文 件 单位全称(公章)：浙江某某有限公司 地 址：
邮 编：310000 时 间：2013年06月05日 目录 第一部分 评标响应导读 1 第1章 项目名称 2 第2章 技术响应、评审评分应答导读表 3 2.1 技术响应导读表 3 2.2 评审评分应答导读表 4 第二部分 技术解决方案 6 第1章 项目描述 6 1.1 项目概述 7 1.2 建设的必要性 7 1.3 现状与差距 7 1.4 建设内容 7 第2章 我方在本项目上的优势 7 2.1 公司优势 8 2.2 需求把握优势 8 2.3 技术团队优势 8 2.4 服务优势 8 第3章 设计依据与原则 8 3.1 项目建设参考标准及设计依据 8 3.2 设计原则 9 3.2.1 充分考虑性价比 9 3.2.2 实效性和共享性 9 3.2.3 标准化 9 3.2.4 健壮性 9 3.2.5 扩充性 9 3.2.6 易维护性 9 3.2.7 开放性 9 3.2.8 可移植性 10 3.2.9 安全性和可靠性 10 3.3 质量标准与管理规范 10 3.4 本项目的建设原则 10 第4章 系统总体架构设计 10 4.1 总体设计要求 10 4.2 系统功能、框架构成设计 11 4.3 业务数据逻辑结构 11 4.4 系统网络拓扑结构 11 4.5 J2EE研发平台 11 4.6 Web应用服务环境 12 4.7 系统流程设计 13 4.8 搭建部署框架设计 13 第5章 需求功能分析、性能设计 13 5.1 系统功能模块分析 13 5.1.1 使用对象 14 5.1.2 xxxxOA系统 14 5.1.3 A系统 14 5.1.4 B系统 14 5.1.5 C管理系统 14 5.1.6 D管理系统 15 5.1.7 FF系统 15 5.1.8 GG培训系统 15 5.1.9 GG基础数据管理系统 15 5.1.10 社区GG管理 15 5.1.11 企业GG(CX)管理系统 15 5.1.12 AQ统计系统 15 5.1.13 其他需求 15 5.2 需求性能分析设计 15 5.3 需求灵活性分析 16 第6章 稳健性、安全性、可扩展性等 16 6.1 稳健性解决方案 16 6.2 安全性解决方案 17 6.3 可扩展性解决方案 17 6.4 可操作性解决方案 18 6.5 可维护性解决方案 19 6.6 开放性解决方案 19 第7章 扩展性及交互接口 19 7.1 与安监系统、消防安全等系统交互 20 7.2 数据结构的扩展性 20 7.3 需求的可扩展性 20 7.4 功能模块的变更与新增 20 7.5 服务接口的预留工作 20 7.6 其他接口的预留工作 20 7.7 单点登录的预留工作 20 7.8 手持终端设备客户端的预留工作 21 第8章 关键业务环节解决方案 21 8.1 与它系统对接技术方案 21 8.2 需求迭代解决方案 22 8.3 B的业务环节 22 8.4 综合预警统计 22 8.5 执法现场检查记录数据安全 22 第9章 关键技术解决方案 22 9.1 基本技术介绍 22 9.1.1 MVC模式 22 9.1.2 Web服务技术 23 9.1.3 Jquery、ajax技术 23 9.1.4 面向对象及面向组件技术 23 9.2 与外界系统数据交互 23 9.3 兼容性解决方案 23 9.4 高性能页面响应解决方案 23 9.5 高并发解决方案 24 9.6 技术特点及难点 24 9.6.1 工作流管理 24 9.6.2 方便维护 24 9.6.3 友好界面 24 9.6.4 安全机制 24 9.6.5 技术难点 25 第10章 系统安全解决方案 25 10.1 物理安全 25 10.2 网络层安全 25 10.2.1 防火墙策略 26 10.2.2 安全检测系统 26 10.2.3 拒绝服务攻击的防范 26 10.3 系统平台安全 27 10.3.1 用户认证 27 10.3.1.1 USB Key 27 10.3.1.2 统一用户身份认证 27 10.3.2 统一用户身份认证子系统介绍 27 10.3.2.1 用户管理 27 10.3.2.2 组织机构管理 28 10.3.2.3 系统注册 28 10.3.2.4 权限管理 28 10.3.2.5 角色管理 28 10.3.2.6 组管理 28 10.3.2.7 职位、项目权限管理 28 10.3.2.8 选项设置 28 10.3.2.9 界面设计示意图 28 10.3.3 操作系统安全 30 10.3.4 应用软件和数据库系统安全 31 10.3.5 系统安全管理和系统病毒防范 31 10.3.6 访问控制 32 10.3.7 入侵检测 32 10.4 安全管理体制 32 10.4.1 网络管理 32 10.4.2 设备管理 32 10.4.3 数据管理 32 10.4.4 操作管理 33 10.4.5 项目管理 33 10.4.6 奖惩措施 33 第11章 网络系统设计 33 11.1 基本要求 33 11.2 应用设计 34 11.3 网络设计 34 11.4 网络系统安全设计 34 11.5 存储设计 34 第12章 数据结构设计 34 12.1 设计原则 35 12.2 结构规范 36 12.2.1 业务数据的数据结构 36 12.2.2 业务数据的数据字典 38 12.3 数据交换内容 38 12.4 数据接口规范 38 第13章 接口介绍 39 13.1 数据接口设计 39 13.1.1 接口规范 40 13.1.1.1 规范约定 40 13.1.1.2 规范格式说明 40 13.1.1.3 方法命名规范 40 13.1.1.4 Web服务接口相应对象及接口名称 40 13.1.1.5 接口安全设计规范 40 13.1.2 接口实现 41 13.1.3 接口调用 41 13.2 单点登录预留接口设计 41 13.3 与其他安监系统接口设计 41 13.4 与其他机构部门接口设计 42 13.5 与其他应用系统接口设计 42 第14章 软硬件环境设计 42 14.1 硬件环境 42 14.1.1 服务器硬件环境配置 42 14.1.2 硬件设备配置清单 43 14.2 软件环境及开发环境 43 14.2.1 操作系统的选择 44 14.2.2 防病毒 45 14.2.3 文档管理 45 14.2.4 数据库环境 45 14.2.5 开发工具及程序设计语言 45 14.2.6 测试工具 45 14.2.7 版本控制工具 45 14.3 测试环境的软硬件配置 45 14.4 培训环境软硬件配置 47 14.5 部署、验收环境软硬件配置 48 第三部分 组织实施方案 48 第1章 标准规范控制 48 1.1 分析和设计标准 48 1.2 程序设计标准 49 1.2.1 Java代码编制规范 50 1.2.2 数据及接口标准 50 1.2.3 软件界面设计规范 50 1.2.4 数据库设计规范 50 1.3 文档规范 50 1.4 项目管理规范化 51 第2章 项目管理 51 2.1 沟通需求分析 51 2.2 项目沟通的方式 52 2.3 沟通信息的收集和归档 52 2.4 项目收尾时的沟通 52 2.5 项目沟通管理文档 52 第3章 项目范围控制 52 3.1 范围定义 52 3.2 范围变更 54 第4章 实施组织方案及进度计划 54 4.1 实施工期 54 4.2 实施方案细则 55 4.3 实施组织架构及职责分工 56 4.3.1 双方职责分工 56 4.3.2 领导组织机构 56 4.3.3 实施方组织架构 57 4.4 项目进度控制及安排 57 4.4.1 定义 57 4.4.2 进度控制范围 58 4.4.3 各阶段任务执行安排表 58 4.5 实施各阶段进度控制 59 4.5.1 实施阶段进度控制表 59 4.5.2 项目研发进度控制详细安排表 60 第5章 软件项目研发计划 60 5.1 研发计划目标 60 5.2 研发计划内容 61 5.3 研发计划前提 62 5.4 软件研发计划执行 62 5.5 软件研发计划验证和审核 62 5.6 系统研发进度计划 62 第6章 项目测试方案 62 6.1 方案概述 63 6.1.1 确定工程 63 6.1.2 定义测试策略 63 6.1.3 测试需求 63 6.1.4 估计测试工作量 63 6.1.5 确定资源 63 6.1.6 工程调度表 63 6.1.7 单元测试计划 63 6.1.8 系统测试计划 65 6.2 功能测试 65 6.3 数据准确性测试 67 6.4 极限度测试 67 6.4.1 负载测试 67 6.4.2 强度测试 68 6.4.3 容量测试 68 6.5 预留容量要求测试 69 6.6 源代码测试 69 6.7 测试结果和报告 69 6.8 错误限度 70 第7章 项目质量管理 71 7.1 质量保证期 72 7.2 软件质量管理目的 72 7.3 软件质量管理 72 7.4 软件配置管理 73 7.5 记录收集、维护和保存 73 7.6 管理报表 73 第8章 项目沟通管理 73 8.1 沟通需求分析 73 8.2 项目沟通的方式 74 8.3 沟通信息的收集和归档 74 8.4 项目收尾时的沟通 74 8.5 项目沟通管理文档 74 第9章 项目文档管理 74 1、软件类文档 75 Ø 软件需求说明书 75 Ø 详细设计说明书 75 第10章 项目风险变更管理 75 第11章 软件纠正措施 76 11.1 目的 76 11.2 角色与职责 77 11.3 纠正措施流程 77 第四部分 维护、售后服务方案 79 第1章 技术服务、维护计划方案 79 1.1 维护体制 80 1.2 组织架构 80 1.3 本地资源配置 81 1.4 维保能力 81 1.5 报修流程框架 81 1.6 业主方(用户方)维护人员培训 81 1.7 维护回馈 81 第2章 售后服务方案 81 2.1 我公司现有服务方案 81 2.2 售后服务内容 81 2.2.1 验收前售后服务内容 82 2.2.2 验收后售后服务内容 82 2.2.3 免费维护期之后的售后服务内容 82 2.3 售后服务流程 82 2.4 售后服务方式 82 2.5 售后服务机构情况表 84 2.6 售后服务响应 85 2.6.1 售后服务人员配置响应 85 2.6.2 售后服务人员情况表 85 2.6.3 故障等级划分 86 2.6.4 响应时间承诺 86 2.7 售后服务承诺 86 2.8 优惠条件承诺 87 第五部分 项目小组名单 88 第1章 项目小组人员名单 88 第2章 人员简历及证书 90 2.1 副总经理兼项目经理-xxx 90 2.2 需求分析师、系统分析师- 91 2.3 软件安全师- 91 2.4 软件工程师- 92 2.5 软件工程师- 92 2.6 软件工程师- 92 2.7 效果工程师- 93 2.8 性能测试工程师- 93 2.9 软件测试工程师- 94 2.10 UI设计师- 94 2.11 硬件工程师- 95 2.12 商务联络- 95 第六部分 工程量、人工费、开发成本 96 第1章 工程量、人工费(不含保价) 96 第2章 开发成本等费用比清单 98 2.1 开发成本等费用组成比说明表 100 2.2 开发详细设计成本费用组成清单 100 第七部分 培训计划 101 第1章 培训计划方案 101 1.1 培训计划声明 101 1.2 培训目的 103 1.3 培训计划 103 1.3.1 培训阶段划分 103 1.3.2 培训课程 103 1.3.2.1 系统管理员培训 103 1.3.2.2 相关领导培训 103 1.3.2.3 普通用户培训 104 1.3.2.4 软件开发、维护培训 104 1.3.3 培训环境及设施 104 1.3.4 培训对象及人员 104 1.3.5 教员资质 105 1.3.6 受训人要求 105 第2章 培训内容 105 2.1 操作培训 105 2.2 维护培训 105 2.3 软件开发培训 105 2.4 现场培训 106 2.5 其他培训 106 第3章 培训方法 106 第4章 培训材料、效果及时间安排 107 4.1 培训材料 107 4.2 培训效果 108 4.3 培训费用 108 4.4 培训时间安排 109 第八部分 验收方案 109 第1章 验收要求 109 第2章 验收方案 109 2.1 项目验收组织机构 109 2.2 项目验收依据 111 2.3 项目验收时间安排 112 2.4 项目验收流程 112 2.5 项目验收内容 112 第九部分 技术偏离说明表 113 第1章 技术偏离响应表 113 第十部分 其他说明 116 第1章 验收文档附件 116 第2章 问题回馈单附件 120 第3章 设备配置清单 121 第一部分 评标响应导读 第1章 项目名称 本项目名称为《SCCGGZHJGF信息平台建设项目》，本方案文档中简称为“GGZHJGF信息平台”或“AJZHH信息平台”或“信息平台”。
第2章 技术响应、评审评分应答导读表 2.1 技术响应导读表 我方为方便招标方、专家及业主方人员能快速理解我方的投标书结构及内容，特列出响应招标书相关要求的技术部分的导读表。其中我方响应招标书要求的打“√”，未响应的打“×”。
备注：技术偏离相应表见“第九部分 技术偏离响应表”。
技术响应导读表 单位全称(公章)：
浙江某某有限公司 招标编号：XXXXXXXX-XXX 招标文件 对应章节 条款/内容 投标文件 对应章节 我方是否响应 第三部分 项目技术规范和服务要求 第二部分 技术解决方案 √ 第1章 项目概述 第二部分 第1章 1.2项目背景 √ 第2章 总体方案 第二部分 第1章 1.1项目目标 √ 2.1 使用对象 第二部分 第5章 5.1.1使用对象 √ 2.2 建设目标 第二部分 第3章 3.2建设要求的理解 √ …… 其他要求 设备清单 第十部分 其他说明 第3章 设备配置清单 √ 全权代表签名：
日 期：
2013年06月05日 2.2 评审评分应答导读表 我方按照评标办法《商务评审评分表》、《技术评审评分表》以及本项目采用“综合评分法”的条款及法则进行逐条回答，并填写评分导读表及评分偏离表。
评标价格响应表 单位全称(公章)：
浙江某某有限公司 招标编号：XXXXXXXX-XXX 评标价格元素 评分标准 价格权值 我方响应 1.投标报价(A) (1)报价的合理性;
(2)投标报价高于本项目总投资，架构分将作为零分处理 30% 我方完全理解和响应 2.技术和服务方案(B) 主要包含方案的先进性、科学性、完整性和可持续发展性，方案与需求吻合程度，提供的售后服务方案、维护人员和机构服务优劣程度以及承诺和优惠等方面的因素。
62% 我方提供的本项目技术解决方案能满足招标书中所有功能、性能、非性能指标 2.1 投标方案的科学性和完整性 10% 我方提供的本项目技术解决方案能满足招标书中其对投标方案的科学性和完整性 3.投标人基本情况(C) 投标人的综合实力、经验情况，主要包括公司规模、资质、项目组人力、类似项目建设成功案例等方面因素 8% 我方完全理解和响应 3.1 投标人基本情况 4% 我方完全理解和响应 备注：总分=A+B+C。技术偏离情况见后文“技术偏离响应表”。
全权代表签名：
日 期：
2013年06月05日 第二部分 技术解决方案 第1章 项目描述 1.1 项目概述 我方已认真阅读招标文件，理解本项目的基本情况，若我方中标，将全力配合GG市SCCGGJGJ对本项目的建设。我方理解：
……。
1.2 建设的必要性 依据SCC政府对GG监管的要求，以科学发展观为指导，坚持安全发展……低事故的要求。
1.3 现状与差距 我公司理解SCC的现状与差距，主要表现在：
……。
1.4 建设内容 我方完全理解招标书中的要求，我方若中标，将积极配合SCC安监局建设好本项目系统平台，我方明确本项目建设的内容，主要包括：
……实现资源共享。
第2章 我方在本项目上的优势 2.1 公司优势 ……。
2.2 需求把握优势 我司……的方案。
2.3 技术团队优势 ……很强的IT技术服务队伍。
2.4 服务优势 我方拥有……提供本地化的零小时D服务响应。
第3章 设计依据与原则 3.1 项目建设参考标准及设计依据 本项目建设方案编制的主要依据是：
1、《国家信息化领导小组关于我国电子政务建设指导意见》(中办发[2002]17号);
2、《国家GG科技发展规划纲要(2004-2010)》;
……;
3.2 设计原则 本项目涉及到系统必须以实用为原则。采用成熟的并且通过实践考验的先进技术和解决方案。
3.2.1 充分考虑性价比 在实现先进性、成熟性和可靠性前提下……达到最小化。
3.2.2 实效性和共享性 本项目涉及……信息资源共享。
3.2.3 标准化 本项目涉及到的各个系统模块设计、系统性能、代码编写等应符合中国有关软件项目的标准化的要求。
……。
3.2.4 健壮性 本项目涉及到……。
3.2.5 扩充性 本项目涉及到……。
3.2.6 易维护性 本项目涉及到……。
3.2.7 开放性 本项目涉及到……。
3.2.8 可移植性 本项目涉及到……。
3.2.9 安全性和可靠性 本项目涉及到……。
3.3 质量标准与管理规范 我公司严格遵循ISO9001和CMMI 3认证质量管理系列标准对项目产品进行研发及质量管理。详细内容请参阅“……”章节。
3.4 本项目的建设原则 我方能理解并完全响应招标书中对本项目的建设原则，若我方中标，我方将积极配合……。
一、二、三、 第4章 系统总体架构设计 4.1 总体设计要求 我司完全能理解并明白招标书的需求，并郑重承诺完全满足相应要求。
Ø 系统采用mysql、Oracle、sql2008其中一种数据库，并基于J2EE平台开发;
Ø ……。
4.2 系统功能、框架构成设计 应招标书内容所述，本项目的系统主要内容包括为建设……。
图1- 系统业务总体框架图 1)、运行体系 运行体系主要是支撑和保障本项目系统的安全性和可维护性……的容灾处理策略。
2)、安全管理 安全管理主要保障本项目系统及其他相应的应用系统的安全性，……。
3)、…… 4.3 业务数据逻辑结构 图2- 业务数据逻辑结构图 为考虑到本项目系统的后期维护和扩展问题，业务的数据逻辑结构设计也需要充分考虑到其扩展性。其中……。
4.4 系统网络拓扑结构 本项目系统涉及到的用户和机构单位存在上下级关系，从区县到乡镇，到街道的上下数据联动，……。
GGZHJGF信息平台与省市数据中心的网络拓扑：
图2- xxx拓扑图 4.5 J2EE研发平台 J2EE是一种利用Java 2平台来简化企业解决方案的开发、部署……。
J2ee平台技术架构: J2EE的核心技术：
J2EE为搭建具有可伸缩性、灵活性、易维护性的商务系统提供了良好的机制：
1、2、 4.6 Web应用服务环境 目前比较流行的大型J2EE服务器主要是IBM的WebSphere和BEA的WebLogic服务器。……。
基于J2EE平台的web服务器对照表 Web服务器 简介 优缺点 IIS6.0 WebSphere WebLogic Server JBoss应用服务器 Apache 基于上表的几个web服务器的性能、功能比较，我方建议本项目的web服务、应用系统程序服务器采用IIS6.0或Tomcat/Apache服务器。
4.7 系统流程设计 4.8 搭建部署框架设计 我方明确……。
第三层 ：
。
第二层：应用服务层 。
第一层：系统硬件支撑层 第5章 需求功能分析、性能设计 5.1 系统功能模块分析 应招标书要求，我方对本项目的系统功能结构设计主要包括如下图所示内容：
图3-系统功能模块结构图 5.1.1 使用对象 本系统焊管上……。系统用户架构如下图所示：
5.1.2 xxxxOA系统 该子系统主要包括领导组织，责任体系，工作上报，部门通知，请假申请，常用文档下载，数据查询功能模块。
² 领导组织 。
² 工作上报 。
5.1.3 A系统 。
² xx治理 。
² xx提醒 ……。
5.1.4 B系统 ² 现场检查记录 5.1.5 C管理系统 ² 申报管理 5.1.6 D管理系统 ² D值守 。
5.1.7 FF系统 。
5.1.8 GG培训系统 功能。
5.1.9 GG基础数据管理系统 主要包括数据录入、数据查询、数据管理、统计分析模块：
5.1.10 社区GG管理 包括……的功能。
5.1.11 企业GG(CX)管理系统 包括……的功能。
5.1.12 AQ统计系统 。
5.1.13 其他需求 。
5.2 需求性能分析设计 我方已认真阅读招标书，我方完全理解和响应招标书要求，若我方中标，对其性能要求将满足如下：
² 系统基本性能要求 ……。
5.3 需求灵活性分析 其考虑到项目业务需求的变更……。
第6章 稳健性、安全性、可扩展性等 6.1 稳健性解决方案 我方提供的本项目系统具有高可靠性。本项目系统采用相对独立化分级设计，对系统关键设备考虑冗余，对重要数据进行备份。我方选用高可靠性的本项目终端设备……。
为达到规定的可靠性、可维护性和可用性，本项目系统中采用了如下成熟理念：
表格 GGZHJGF信息平台可靠性、可维护性成熟理念 序号 采用的成熟理念 1.使用成熟可靠的软件设计方法，比如模块化、组件化、面向对象的设计方法等，使用成熟稳定的软件开发技术和平台，比如windows、Linux操作系统、SQL/mysql数据库系统、JAVA开发语言等;
2.在软件系统、框架设计、组件的设计、开发、测试、部署和维护过程中，严格遵循ISO-9001质保程序;
3. 4. 5. 6.2 安全性解决方案 我方应招标书要求，在项目研发的需求分析阶段、系统框架设计阶段、项目详细设计阶段中充分考虑项目的安全性，我们将结合以往的成功案例中的安全策略以及本项目的安全需求，提供物理安全、数据安全、网络安全、防火墙策略、应用程序安全等技术方案。
并为满足招标书中队系统安全要求，我方郑重承诺满足：
1)、需拥有完整、合理、统一的服务器、数据库、系统文件、数据等各方面的安全控制，建立完善的安全管理机制。
2)、……。
保证本项目在实际应用中的安全性,详细请见“第二部分，第10章 系统安全解决方案”章节内容。
6.3 可扩展性解决方案 我方提供的本项目系统解决方案具有良好的可扩展性，系统的可扩展性可从系统结构、接口、应用功能、软件、硬件等方面考虑，下面将从以下几方面论述系统可扩展性：新增系统接口的扩展、新增系统功能的扩展、新增系统应用的扩展(如其它web服务、短信服务等)、与其他应用程序的接口。
l 新增系统接口的扩展 详见“第二部分，第12章 接口介绍”章节中的方案说明，我方将提供对系统要求的新增系统接口的支持。
l 新增系统功能的扩展 ……。
详细请参阅“第二部分，第7章 扩展性及交互接口”章节。
6.4 可操作性解决方案 我方主要是从软件功能模块化、按用户权限进行控制管理、友好性、参数配置化方面满足其软件质量的可操作性的。我方采用MVC模式和jquer UI等技术，让整个软件项目系统的可操作性更加完善。
² 功能模块化 ……。
² 按用户权限进行控制管理 在页面中也只能操作属于用户自身权限所具有的按钮和数据。如审核用户只能看到自己相关的审核数据和审核按钮。
² 友好性 我方应用软件是一个完整意义上的多用户系统，登录系统进行业务操作的用户数在本项目系统中没有限制的情况下，没有上限限制，完全满足本项目业务的需要。
采用合理的、简洁大方而又美观的页面布局，让操作界面更加……。
² 参数配置化 基于本项目系统可能存在大量统计报表的情况，我们将采用自定义的配置方式实现……。
6.5 可维护性解决方案 我方采用系统可自定义的方式，用户可以通过参数配置、自定义系统的主题样式、配置数据库连接、接口IP和安全设置提高后期项目的可维护性。……。
6.6 开放性解决方案 我方承诺在供货时提供所有应用软件的源代码、伪代码、详细设计文档、测试文档、操作手册、维护手册、开发说明文档和方案，并提供二次开发工具。我方承诺按招标人所需，及时提供足够的软件二次开发技术支持。
第7章 扩展性及交互接口 我方完全能理解并接受招标书的相关要求，为保证本项目的高可扩展性，并结合本公司以往在监管行业的项目开发经验，针对本项目提出可扩展性解决方案。
……。
7.1 与安监系统、消防安全等系统交互 我……具体内容见下文。
7.2 数据结构的扩展性 我方在……。
² 与其他应用系统的数据融合并扩展 为……;
² 新功能扩展的数据结构调整 为考虑到未来本项目系统的新增功能……数据结构的调整。
7.3 需求的可扩展性 任何一个项目系统都会随着时间的推移，需求难免发生变更或新增，所以做好需求的可扩展性也是必要的。我方应招标书要求，并结合本公司在以往的相关行业领域的成功案例，主要建议做这方面的预留工作：
需求的变更;
新需求的增加;
……接口的预留。
7.4 功能模块的变更与新增 这一方面，主要考虑本项目系统的功能模块的调整与新增，我方将做好……等。
7.5 服务接口的预留工作 我方采用微软提供……的可扩展性和可维护性。
7.6 其他接口的预留工作 ……的扩展。
7.7 单点登录的预留工作 我方能理解招标书中的需求，并结合……跨域的登录信息技术处理。
7.8 手持终端设备客户端的预留工作 应招标书要求，本方案在实施过程中，将充分考虑到手持终端设备客户端的预留工作，主要包括：
……。
第8章 关键业务环节解决方案 8.1 与它系统对接技术方案 应招标书要求，本方案针对GGZHJGF信息平台与其他应用系统对接提供如下方案：
……：
1)、解决数据量大导致对接性能低 与它系统对接过程中……分批对接。
2)、解决对接过程中的复杂性 因各个应用系统的数据结构存在差异性……的复杂性。
3)解决对接过程中的数据稳定性和安全性 同样，采……和安全性。
8.2 需求迭代解决方案 应招标书要求，为满足项目的可扩展性，可实施性，面对未来可能存在着需求变更…… 8.3 B的业务环节 8.4 综合预警统计 。
。
8.5 执法现场检查记录数据安全 为提……。
第9章 关键技术解决方案 9.1 基本技术介绍 9.1.1 MVC模式 MVC是 ……的操作。
。
其优点有：
9.1.2 Web服务技术 Web services是建立可互操作的分布式应用程序的新平台……。
9.1.3 Jquery、ajax技术 本方案在UI层采用jquery技术和ajax技术，是……。
9.1.4 面向对象及面向组件技术 本方案完全应招标书要求，采用面向对象及面向组件技术以保障项目能成功实施：
……的问题。
9.2 与外界系统数据交互 本方案考虑数据通信交互主要涉及到两大方面，第一方面……。
9.3 兼容性解决方案 我方在本项目的兼容性将做好大量的工作，一个是各种浏览器的兼容显示的问题……。
9.4 高性能页面响应解决方案 应招标文件中对性能的需求，并响应本方案的“第二部分，第5章 的需求性能分析设计”内容，我方在本项目性能方面主要满足：
1、系统响应时间要求：
……。
9.5 高并发解决方案 GGZHJGF信息平台的潜在用户群是很庞大的……。
Web服务与数据库分离示意图 9.6 技术特点及难点 本项目在具体实施过程中可能存在着这几项技术特点：
。
9.6.1 工作流管理 由……等。
9.6.2 方便维护 系统设计过程中，采用了自定义及可配置的设计思想，以提高系统的可维护性，主要表现在：
² ……的变更及维护工作。
9.6.3 友好界面 友好的界面将直接带给用户友好的体验效果，并可增强本公司在用户心目中的好映像，主要表现在：
² 简洁实用的操作界面;
² 大气并具有现代审美观的界面设计;
² 用户上手快。
9.6.4 安全机制 除了网络安全机制、物理安全机制、……防止SQL注入式攻击。
9.6.5 技术难点 本系统在具体实施研发过程中，因用户来自四面八方，浏览器多种多样，同一时间并发操作，或者不同时间操作同一业务等事件……。
本方案的设计也将面临这几个技术难点：
² 如何解决统一用户身份认证，和单点登录的问题;
² ……的技术瓶颈问题;
第10章 系统安全解决方案 10.1 物理安全 保证 。
10.2 网络层安全 基于互联网的网络互连互通的特点……。
10.2.1 防火墙策略 防火墙就是……应用程序代理防火墙等。
10.2.2 安全检测系统 入侵检测 。
针对上述内容和应招标书要求，本方案针对几类相关工具进行比较：
表-安全工具软件比对表 工具软件、设备 针对性功能 缺点 360安全卫士 Windows修复工具 主页防篡改工具 卡巴斯基 诺顿 表-防火墙性能比对表 防火墙或设备 基本参数 功能 华盾UTM 深信服科技UTM 10.2.3 拒绝服务攻击的防范 DDoS(分布式拒绝服务)攻击，是指……的攻击方法。
10.3 系统平台安全 10.3.1 用户认证 我方应招标书要求，完全理解用户身份认证相关需求……。
10.3.1.1 USB Key 随着互联网及业务系统应用的逐步深入……鼠标被监控。
10.3.1.2 统一用户身份认证 本方案考虑到角色权限的稳定性、实效性、安全性，以及……及权限管理功能。
10.3.2 统一用户身份认证子系统介绍 统一用户身份认证子系统将……。
图5-统一用户身份认证系统的网络拓扑图 ² 总体设计思路 总体设计思路是将…… 1) 2) 单点登录、多系统间遨游的网络拓扑示意图 ² 其功能结构 图6-功能结构图 10.3.2.1 用户管理 10.3.2.2 组织机构管理 10.3.2.3 系统注册 10.3.2.4 权限管理 权限及为模块+动作 10.3.2.5 角色管理 。
10.3.2.6 组管理 。
10.3.2.7 职位、项目权限管理 其功能如同组管理，且作为待扩展的功能，此节不再阐述。
10.3.2.8 选项设置 都要有日志记录。
10.3.2.9 界面设计示意图 用户授权操作示意界面：
用户添加界面：
机构管理主界面：
系统注册主界面：
权限管理主界面：
角色管理主界面：
组管理主界面：
组授权管理界面：
特此声明：
本方案提供的图片及示意图为阐述本方案的内容及意图，不为最终设计效果图。若我方中标，我方将根据客户的具体要求及相关的共同签署的有效合同为依据，提供具体的设计效果及系统设计的相关文档说明书。
投标人(盖章)：_浙江某某公司_ 法定代表人或授权委托人(签字)：________________ 日期：_2013年06月05日 10.3.3 操作系统安全 操作系统是应用软件和服务运行的公共平台……。
10.3.4 应用软件和数据库系统安全 一、应用软件安全 应用系统的安全设计表现在多个方面：
。
è 数据资源保护 对数据库系统所管理的数据和资源提供安全保护，包括以下几点：
Ø 。
è 数据备份 高可靠系统的引入并不能避免由于病毒或人为误操作所带来的数据的逻辑损坏，要进一步保护数据安全，数据备份系统的引入必不可少。
……。
数据备份的整套解决方案：
è 数据容灾 容灾备份……。
10.3.5 系统安全管理和系统病毒防范 计算机系统设计上的安全不能防止系统实现或配置中存在的漏洞。……。
10.3.6 访问控制 访问控制是网络安全防范和保护的主要策略……。
è 入网访问控制 入网访问控制为网络访问提供了第一层访问控制^。
è 权限控制 。
è 目录级安全控制 。
è 属性安全控制 。
è 服务器安全控制 。
10.3.7 入侵检测 入侵检测(Intrusion Detection)是 Ø 。
10.4 安全管理体制 为加强我方项目管理及IT研发团队管理……在项目管理及奖惩管理方面建立相关规章制度。下面作简要说明：
10.4.1 网络管理 。
10.4.2 设备管理 。
10.4.3 数据管理 。
10.4.4 操作管理 。
10.4.5 项目管理 规定相关人员在实施项目管理的过程中权限、工作规定、工作流程、工作责任等，并建立相应的考核制度。
10.4.6 奖惩措施 为保证。
第11章 网络系统设计 11.1 基本要求 本次项目建设，为了方便与省安监局其他系统的实现数据交互和管理人员的统一维护，本次系统所有涉及软件要求基于J2EE平台开发，并且达到以下要求：
Ø 系统将采用B/S结构;
Ø 系统将采用多层架构的体系结构;
。
11.2 应用设计 应招标书要求，本方案采用多层架构技术，实现项目的可扩展性、可维护性，以及结合其他相关技术保障项目能成功实施……。
1、表现层(UI)：展现给用户的操作界面或者网页，用户在界面上可以完成各种操作，实现人与系统的互动。
2、业务逻辑层(BLL)：也可以将业务逻辑层分业务处理层和对象模型层。业务处理层针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。对象模型层及对对象的属性进行定义描述(比如对小张这个人物对象进行特征、性格、行为等定义描述)。
3、数据访问层(DAL)：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。
采用这种三层架构使开发出的系统稳定健壮、易扩展;
其充分满足建设要求的移植性、安全性、稳定性等。
11.3 网络设计 ……。
11.4 网络系统安全设计 见“第二部分，第10章 系统安全解决方案”章节。
11.5 存储设计 存储设计的可靠性、……。
第12章 数据结构设计 12.1 设计原则 为加强……各级信息系统建设应遵循以下原则：
实用性 以……。
标准性 以……数据共享。
扩展性。
安全性 充分考虑系统的安全防护，具备较强的数据管理机制和控制能力。
12.2 结构规范 ……。
12.2.1 业务数据的数据结构 业务数据的数据库结构设计主要以GG市SCCGGJDS的相关规范标准为基准，主要包括以下部分：
名称 数据库表名称 说明 领导组织表 OA_Leader 领导组织记录表 责任体系表 OA_ZRTX 其他关联表 略…… 略…… 备注：数据表的结构及其他数据表将根据具体需求待定。
12.2.2 业务数据的数据字典 业务数据的数据字典主要包括以下部分，主要与……为基准：
名称 代码 说明 所属行业 ssss 营业执照类别 sssdf 企业类型 本……。
12.3 数据交换内容 应招标书要求，本方案提供的数据交换的内容主要包括：
…… 其具体的内容将根据项目具体实施过程中的实际需求而定，本方案将不再做阐述。
12.4 数据接口规范 数据接口规范请参考下文说明(第13章 接口介绍)。
第13章 接口介绍 13.1 数据接口设计 根据我方先……详细见下文。
13.1.1 接口规范 13.1.1.1 规范约定 ……。
13.1.1.2 规范格式说明 è ……。
返回列表 见基本格式里面的数据部分：
…… 13.1.1.3 方法命名规范 维护接口以Update开始;
……。
13.1.1.4 Web服务接口相应对象及接口名称 对象或类名称 对象或类代码 用户信息 其他对象…… 略…… 13.1.1.5 接口安全设计规范 绝大部分接口统一默认至少有2个参数，接口功能所需参数、票据。参数名为不限、ticket，以下其他接口输入参数中，不再另行描述。
功能描述 用户权限校验 访问地址 所有 输入参数 输出参数 处理流程 1、备注 13.1.2 接口实现 ² 验证系统访问合法性 功能描述 验证业务系统访问合法性 访问接口 输入参数 输出参数 处理流程 1、备注 备注：其他的接口实现与此实例相同。
特此声明：
本方案提供的接口实现方式只供参考，具体实现方式将根据项目实施过程中的实际情况作调整变更。
13.1.3 接口调用 调用原理：
……。
13.2 单点登录预留接口设计 若我方中标，我方将按照本方案在项目实施时做好支持单点登录的预留接口的工作，该工作主要提供：
……。
13.3 与其他安监系统接口设计 若我方中标，我方将根据招标书要求，在项目实施时做好与……具体内容包括：
1)、。
与企业基础数据库对接示意图 13.4 与其他机构部门接口设计 若我方中标……。
与其他机构进行数据交互的示意图 13.5 与其他应用系统接口设计 。
第14章 软硬件环境设计 14.1 硬件环境 14.1.1 服务器硬件环境配置 我司应招标书要求，结合客户现有的经济条件、物理硬件条件，给出以下硬件环境配置要求：
表-服务器硬件环境配置表 序号 项目 参数 主要软件工具 1 Web应用服务器 CPU频率：2.13GHz及以上，双核 内存：512MB 硬盘：10GB 其他参数：不限制 Windows、Linux操作系统;
Tomcat，Apache，IIS管理工具 2 3 4 5 6 7 其硬件设备请参考“硬件设备清单”。
14.1.2 硬件设备配置清单 应招标书要求，我公司应响应其招标书中的硬件设备清单的内容及相关服务事项要求。详情见“第十部分 第3章、设备配置清单”。
14.2 软件环境及开发环境 应招标书要求，我方提供软件环境解决方案主要包括操作系统的选择、防病毒、文档管理、数据库环境、开发工具及程序设计语言、测试工具、版本控制工具。
14.2.1 操作系统的选择 操作系统平台……。
主流操作系统对比表 序号 内容 UNIX Windows Linux 1 可管理性 较好的可管理性 很好的可管理性 可管理性好，且开放源代码，必要时可进行源码级修改 2 可维护性 系统维护难度较大。服务器可靠性高，支持24小时长时间不间断运行 系统维护难度较小，维护软件简单易用。但是服务器整体稳定性稍低 系统维护难度较大，有维护软件工具可选。服务器稳定，支持连续24小时不间断运行 3 4 5 6 7 8 省安监局现有的软硬件状况表 序号 项目 详细说明 1 现有的安监系统 2 数据库 Oracle 10g，或mysql，或sql2008 3 操作系统 Windows、Linux 4 Web应用及web服务服务管理 Tomcat，Apache，IIS 根据上表的比较分析，并结合GG市SCCGGJDS的软硬件环境，各类计算机操作系统选择考虑如下：
14.2.2 防病毒 。
14.2.3 文档管理 开发工程将使用常见通用的Microsoft Word 2003, Microsoft Visio 2003， Microsoft Excel 2003，Microsoft Project 2003，Microsoft PowerPoint 2003，SVN等进行文档管理。
14.2.4 数据库环境 。
表-数据库优缺点对比表 数据库 优点 缺点 14.2.5 开发工具及程序设计语言 代码编写：Eclipse ，版本代号Indigo，平台版本3.7 编写语言：Java(后台)、Javascript(前端) 数据库开发：
14.2.6 测试工具 14.2.7 版本控制工具 。
14.3 测试环境的软硬件配置 我方对本项目在测试过程中的测试环境配置如下：
序号 项目 服务端 客户端 1 操作系统 Windows、Linux 无限制 2 数据库 Oracle 10g/mysql 无 14.4 培训环境软硬件配置 我方对本项目针对业主方(用户方)进行培训的过程中的环境配置如下，培训环境所需软硬件由业主方(用户方)提供：
序号 项目名称 参数 数量 1 GG企业基础数据库 当前版本 1套 2 Oracle数据库或 Mysql数据库 10g版本 1套 3 服务器操作系统 Windows、Linux 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 14.5 部署、验收环境软硬件配置 其配置环境与“培训环境软硬件配置”相同，此节不再阐述。
第三部分 组织实施方案 第1章 标准规范控制 1.1 分析和设计标准 1.2 程序设计标准 ：
1.2.1 Java代码编制规范 。
1.2.2 数据及接口标准 Ø 数据接口采用可扩展标记语言XML格式;
Ø 。
1.2.3 软件界面设计规范 1.界面设计原则 业务处理界面：
。
1.2.4 数据库设计规范 数据表命名规则 函数：FN_XXXX(FN+_+函数名称) 1.3 文档规范 在项目开发过程中，应该按要求编写好十三种文档，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。主要包括《可行性分析报告》、《项目开发计划》、《软件需求说明书(软件规格说明书)》、《详细设计说明书》、《用户操作手册》、《测试计划》、《测试分析报告》、《开发进度月报》、《项目开发总结报告》、《软件维护手册》、《软件问题报告》、《软件修改报告》。
1.4 项目管理规范化 。
第2章 项目管理 在本项目中……等。
2.1 沟通需求分析 经过分析后，我们认为，此次建设工程的沟通基本需求大致在以下几个方面：
Ø 。
2.2 项目沟通的方式 。
在本项目中，我们将主要采用以下的方式进行项目中的沟通：
Ø 项目报告、备忘录 Ø 电子邮件 Ø 项目会议 Ø 电话 Ø 传真等 2.3 沟通信息的收集和归档 我们将采用Word、Excel等软件系统进行信息收集和文件归档的管理。通过软件系统对信息的版本、使用权限进行控制和管理，并记录完整的信息使用记录。
2.4 项目收尾时的沟通 Ø 。
2.5 项目沟通管理文档 为有效和规范地执行项目沟通，我们制定了项目一般沟通事项的范例和模板，包括：
Ø 第3章 项目范围控制 3.1 范围定义 项……本项目实施范围如下：
系统名称 子系统名称 功能模块范围 GGZHJGF信息平台 (政府端) GGOA系统 主要实现领导组织、责任体系、工作上报、部门通知、请假申报、常用文档下载、数据查询的功能模块 企业端应用系统 信息申报 主要包括企业录入、整改录入、事故申报、培训申报、事件报告的功能模块 辅助系统 手持移动终端 统一权限认证管理子模块(说明：可以扩展或演化成独立的子系统) 权限管理 分角色管理、组管理、职位管理、项目管理，以及角色、组、职位授权管理。
系统设置 主要包括安全设置、样式设置、系统日志。
3.2 范围变更 一个项目的实施计划可能制订的非常好，但是想不出现任何改变几乎是不可能的。因此对变更的管理是在项目实施是需要进行重视的。
第4章 实施组织方案及进度计划 4.1 实施工期 我方郑重承诺：
应招标书要求，若我公司中标，我公司理解并执行本项目实施总工期为……。
投标人(盖章)：_浙江某某公司 法定代表人或授权委托人(签字)：________________ 日期：_2013年06月05日_ 4.2 实施方案细则 我方应招标要求，实施细则描述如下：
。
4.3 实施组织架构及职责分工 4.3.1 双方职责分工 Ø 浙江某某有限公司责任分工：
² 。
Ø 浙江省GG市SCCGGJGJ方面责任分工：
² 。
4.3.2 领导组织机构 ² 技术支持小组 ……。
机构名称 任务与职责 联合领导小组 项目研发组 系统分析组 开发小组1-n 项目测试小组 项目实施组 网络工程组 培训组 数据录入组 质量控制小组 审查 验收 质量控制 服务支持组 技术支持 系统维护 实施方组织的详细内容紧接见下文。
4.3.3 实施方组织架构 项目实施方组织由以下几个小组组成：
1) 项目管理组：
² 人员组成：项目经理;
² 职责范围：负责对项目建设过程中的一切技术管理、公司内部资源协调、开发商和采购人关系协调和重大问题的决策，负责项目实施各阶段的各项计划的制订;
监督项目进度。
2) 设计开发组：
² 人员组成：需求分析师、系统架构师、开发工程师、UI设计师(美工);
² 职责范围：系统负责编制此项目开发系统中需涉及到的外部接口细则，落实系统外部接口的实施，协调各系统间的接口，应用软件的研制、开发、调试、手册编写、程序维护等。
3) 质量管理组：
² 人员组成：测试工程师;
² 职责范围：负责系统各项测试环节的测试方案编写及具体测试工作实施，质量管理计划制定和项目质量控制。
4) 项目实施组：
² 人员组成：实施工程师;
² 职责范围：负责硬件设备、系统软件(如数据库等)的现场安装和测试、用户上线操作指导，并提交现场测试报告和用户使用情况报告。
5) 售后运维组：
² 人员组成：系统运维工程师;
² 职责范围：负责有关文档的整理编辑，系统培训组织，系统平台售后运维等。
4.4 项目进度控制及安排 4.4.1 定义 工程项目进度控制是指为保证工程项目实现预期的工期目标，对工程项目寿命周期全过程的各项工作时间进行计划，实施，检查，调整等的一系列工作。
² ……。
² 如何编制项目进度计划 。
4.4.2 进度控制范围 。
4.4.3 各阶段任务执行安排表 用户方及业主方(用户方)需配合我方进行任务执行，我方提供各阶段任务执行安排表，本项目系统实施的各阶段任务执行安排表如下：
表格-各阶段任务执行安排表 项目阶段 工作任务明细 用户工作 提交成果 准备阶段 明确项目规则，规范和工作方法 参与 项目工作规则 明确项目组所有成员职责 参与并决策 项目人员名单 制定项目实施计划、质量保证计划 计划确认 项目实施计划、质量保证计划 需求分析 初步明确项目的需求分析 确认、签字 需求分析、建设计划、目标任务书和测试验收方案 项目实施 落实实施任务 参与、确认 工作计划 系统设计、开发 具体实施 系统测试 提供测试案例,测试工作 测试计划、测试报告 系统验收 双方对系统进行验收 验收确认 系统验收报告 4.5 实施各阶段进度控制 4.5.1 实施阶段进度控制表 我们将认真落实响应招标文件中提出的实施要求，实行三个阶段的执行计划：
第一阶段 合同签订后30天内进行详细的需求调研，进一步优化需求分析、概要设计、详细设计，并细化系统建设计划、目标任务书和测试验收方案，向采购人提供上述文档并需经采购人审查通过。一个月内完成前期调研并提交系统需求说明书和前期系统分析、设计工作。并在30日内完成设备到货，并想采购人提供上述文档，经采购人审查通过 第二阶段 合同签订后2个月内完成项目的系统建设及培训，经初验合格交付使用进入试运行。
第三阶段 投入试运行后正常运行1个月。期满经终验合格后进入3年维护期。
项目研发工期安排见下表: 备注：开发周期为本项目合同签订中的项目研发起止时间为准，本方案初步按招标书中的总工期为3个月，其中研发时间为2个月(共8周)的项目研发测试时间，其中最后一个月(最后4周)为验收和试运行时间段。
由于时间紧凑，研发功能繁多，故本方案采取敏捷开发模式，及按模块需求调研和研发同步进行。
上图中初步预计配置5个研发小组，每个研发小组配置1-2人。
投标人(盖章)：_浙江某某有限公司_ 法定代表人或授权委托人(签字)：________________ 日期：_2013年06月05日_ 4.5.2 项目研发进度控制详细安排表 若我公司中标，我方将在本项目合同签订后6个工作日后给出本项目实施的具体项目进度控制计划表，目前初步计划表如下：
进度控制图1 进度控制图2 进度控制图3 第5章 软件项目研发计划 5.1 研发计划目标 。
5.2 研发计划内容 软件开发计划内容包括：。
5.3 研发计划前提 è 有关项目软件订立一个文档化并得到一致认可的工作说明。
è è 相关人员(包括软件负责人和软件工程师)需要做软件评估和计划方面的培训。
5.4 软件研发计划执行 1)、软件过程组要参与项目提案小组。
è 。
5.5 软件研发计划验证和审核 项目开发计划验证和审核的主要内容有：
è 。
è 软件开发计划的内容。
5.6 系统研发进度计划 我方将CMMI 3的软件开发标准流程管理，建立完整的软件开发组织结构，配备优秀的软件设计和开发人员，并按照项目实施研发进度控制安排表执行(见“第三部分，第4章 4.5.2 项目研发进度控制详细安排表”)。
第6章 项目测试方案 测试计划即定义测试项目，确定测试需求、所需要的资源、总体测试策略、所要达到的标准及时间安排等，生成测试计划文档资料，以便能够正确的度量和控制测试。
6.1 方案概述 6.1.1 确定工程 。
6.1.2 定义测试策略 。
6.1.3 测试需求 。
6.1.4 估计测试工作量 6.1.5 确定资源 。
6.1.6 工程调度表 我方在进行本项目系统研发测试过程中，采用工程调度的办法进行测试工程管理，以确保达到测试的目的。
6.1.7 单元测试计划 单元测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试大多采用白盒测试技术，系统内多个模块可以并行地进行测试。
单元测试计划表 测试阶段 规划内容 具体内容 特殊说明 单元测试 适用对象 各单元模块 进入条件 单元模块编译通过之后，下一个增量开发之前 测试内容 1 模块接口测试;
2 模块局部数据结构测试;
3 模块边界条件测试;
4 模块中所有独立执行通路测试;
5 模块的各条错误处理通路测试。
人员需求 1测试开发人员2测试工程师3测试执行者(该阶段的工作一般由编程组内部人员担任) 测试开发人员：测试工具、桩模块的开发、测试用例脚本的开发 测试工程师：测试过程设计(测试用例的设计、开发) 测试执行者：执行测试过、分析评估测试结果 系统资源 1.操作环境：相对简单、独立的测试环境。除了操作系统，测试机上只安装软件运行和测试必需的软件，以免不相关的软件影响测试实施。
2.单元模块说明书、设计说明 技术方法 主要运用白盒法结合黑盒法测试技术 测试工具 自动化单元测试工具或自行开发的测试工具 市场上比较流行的测试工具有：MI和Rational系列中的单元测试工具，还有一些如：C++ TEST Junit 步 骤 1. 单元测试计划 2. 测试工具分析 3. 确定测试环境 4. 测试需求分析 5. 测试用例设计 6. 测试用例开发 7. 测试实施 8. 测试分析评估 测试项目及方法：
(一)、单元测试方法 (二)、单元测试过程 。
6.1.8 系统测试计划 。
6.2 功能测试 。
我们将编制测试项目来验证所有系统功能是否满足，在本项目系统的测试中，我们将至少进行以下功能的测试：
表格-功能测试内容列表 测试系统：GGZHJGF信息平台(以下简写为PT);
企业端(CMP);
手持终端(MV) 序号 分类 功能名称 相关设备/系统 详细说明 1 GGOA 领导组织 PT 对基本信息维护、查询功能的测试 2 责任体系 PT 同上 3 4 5 6 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 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 6.3 数据准确性测试 。
6.4 极限度测试 ：
6.4.1 负载测试 。
表格-系统负载测试目标表 序号 分类 详细描述 1 测试目标 核实某项功能和操作在不同的工作量条件下也能正常完成。
2 技术 使用为功能周期测试制定的测试。
通过修改数据文件来增加事务数量，或通过修改测试来增加每项事务发生的次数。
3 完成标准 多个事务或多个用户：在可接受的时间范围内成功地完成测试，没有发生任何Bug。
4 需考虑的特殊事项 负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。
负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。
6.4.2 强度测试 。
表格-系统强度测试目标表 序号 分类 详细描述 1 测试目标 核实测试对象能够在以下强度条件下正常运行，不会出现任何错误：
服务器上几乎没有或根本没有可用的内存 连接或模拟了最大实际(实际允许)数量的客户机 多个用户对相同的数据或账户执行相同的事务 最繁重的事务量或最差的事务组合(请参见上面的“性能测试”) 注：强度测试的目标可表述为确定和记录那些使系统无法继续正常运行的的情况或条件。
2 技术 使用为性能评测或负载测试制定的测试。
要对有限的资源进行测试，我们将在一台计算机上运行测试，而且可以考虑减少或限制服务器上的 RAM 等资源。
对于其他强度测试，应该使用多台客户机来运行相同的测试或互补的测试，以产生最繁重的事务量或最差的事务组合。
3 完成标准 计划的测试已全部执行，并且在达到或超出指定的系统限制时没有出现任何软件Bug，或者导致系统出现Bug的条件并不在指定的条件范围之内。
4 需考虑的特殊事项 如果要增加网络工作强度，可能会需要使用网络工具来给网络加载消息或信息包。
应该限制数据库可用空间的增长。
使多个客户机对相同的记录或数据账户同时进行的访问达到同步。
6.4.3 容量测试 容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生Bug的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。
表格-系统容量测试目标表 序号 分类 详细描述 1 测试目标 核实测试对象在以下高容量条件下能否正常运行：
连接或模拟了最大(实际或实际允许)数量的客户机，所有客户机在长时间内执行相同的、且情况(性能)最坏的业务功能。
已达到最大的数据库大小(实际的或按比例缩放的)，而且同时执行了多个查询或报表事务。
2 技术 使用为性能评测或负载测试制定的测试。
应该使用多台客户机来运行相同的测试或互补的测试，以便在长时间内产生最繁重的事务量或最差的事务组合(请参见上面的“强度测试”)。
创建最大的数据库大小(实际的、按比例缩放的、或填充了代表性数据的数据库)，并使用多台客户机在长时间内同时运行查询和报表事务。] 3 完成标准 计划的测试已全部执行，而且在达到或超出指定的系统限制时没有出现任何软件Bug。
4 需考虑的特殊事项 对于上述的高容量条件，哪个时间段是可以接受的时间需要和招标人商量以后确定。
6.5 预留容量要求测试 我们承诺在中标以后，提供一套测试方案，测试系统的预留容量和其它性能指标，该项测试将和系统利用率测试一起进行，并将测试结果提交招标人。
6.6 源代码测试 我方承诺在本项目系统投入使用(商业运营或试运营)后一个星期内提交合同内所有应用软件的源代码，在招标人软件测试室进行编译，并下载或拷贝到指定的设备上进行功能测试，只有通过了此功能测试才能进行其他的软件测试步骤或完成软件验收。
6.7 测试结果和报告 我们承诺在每次测试以后，提供测试报告，并由我方和招标人确认测试结果。测试报告格式如下，将包括以下的表格内容：
表格-测试问题列表 序号 问题编号 功能名 概要描述 版本 发行日 类别 预定对应状况 备注 1 2 3 4 表格-测试结果统计表 总测试项 实际测试项 OK项 POK项 NG项 NT项 无需测试项 数目 百分比 其中：OK表示测试结果全部正确;
POK表示测试结果大部分正确;
NG表示测试结果有较大的错误;
NT表示由于各种原因本次无法测试。
表格-测试问题统计表 问题总数 十分严重问题 中度严重问题 轻度严重问题 其它统计项 数目 百分比 表格-测试问题记录表 序号 问题号 内容 1 问题简述 2 问题描述 3 问题级别 4 问题分析与对策 5 避免措施 6 备注 6.8 错误限度 我方对软件错误按以下分类：
² 十分严重 表现为某重要功能无法实现，且没有替代的解决方法，导致系统性能降低。重新安装软件，或重新运行软件不能视为替代的解决办法。
² 中度严重 表现为某重要功能无法顺利实现，但有可行的替代解决办法。
² 轻度严重 表现为有操作不方便的现象存在，但不影响功能的实现。
我方承诺未解决的软件问题数目(不包括文档问题)不超过合同双方认可的数目。
第7章 项目质量管理 我方将遵循ISO9001认证和CMMI 3认证具有严格而完整的软件质量保证体系，我们将把该体系应用于本项目的软件开发管理中，基于此，我们将提供一套具体的针对本项目的软件质量保证计划，该计划的目的首先是我们用于软件开发管理，其次，用于招标人对软件开发活动的审核。该计划包括设计评审计划、对外购软件的评测、内部审查、客户审查、针对质量的一系列测试活动等。
7.1 质量保证期 我方郑重承诺：
若我方中标，我方将认真履行我方与业主方(用户方)签署的有效合同中提到的本项目系统质量保证期间相关的责任，以及满足相关的技术服务要求和承担相应的责任要求。
投标人(盖章)：_浙江某某有限公司_ 法定代表人或授权委托人(签字)：________________ 日期：_2013年06月05日_ 7.2 软件质量管理目的 。
7.3 软件质量管理 ……的一致性。
7.4 软件配置管理 。
7.5 记录收集、维护和保存 。
7.6 管理报表 软件质量保证过程一系列的报表，例如 第8章 项目沟通管理 在本项目中，……等。
8.1 沟通需求分析 经过分析后，我们认为，此次建设工程的沟通基本需求大致在以下几个方面：
Ø 。
8.2 项目沟通的方式 。
在本项目中，我们将主要采用以下的方式进行项目中的沟通：
Ø 项目报告、备忘录 Ø 电子邮件 Ø 项目会议 Ø 电话 Ø 传真等 8.3 沟通信息的收集和归档 。
8.4 项目收尾时的沟通 Ø 。
8.5 项目沟通管理文档 Ø 第9章 项目文档管理 本次项目我方将至少提供以下标准文档：
1、软件类文档 Ø 软件需求说明书 Ø 概要设计说明书 Ø 详细设计说明书 Ø 数据库设计说明书 Ø 服务扩展系统开发规范 Ø 技术手册(安装、操作、维护、Bug排除等) Ø 测试计划 Ø 工程日志 2、管理类文档 管理类文档遵循ISO9000要求建立，包括：
Ø 工程进度报告 Ø 项目培训记录 Ø 项目会议记录 Ø 系统初验验收书 Ø 系统初验报告 Ø 系统试运行报告 Ø 系统终验验收书 Ø 系统终验报告 Ø 项目开发总结报告 第10章 项目风险变更管理 风险是指对无法达到预定目标的可能性和结果的一种测评。本项目系统工程，是一个极端复杂的系统工程，涉及到软件开发、施工部署、多应用系统间数据交互等多个不同领域，工程中隐藏的风险更是复杂多变。如何识别和控制风险是整个项目管理中的一个重要的组成部分。风险管理即处理风险的行为或实践行为，包括对风险的计划、评估(识别及分析)。提出应对风险的处理方法及对风险的监控(通常是用来发现风险是如何变化的)。我方的风险管理将与关键的项目实施过程紧密相连。
风险管理包含以下几个相互关联的部分：风险计划、评估(识别、分析和排序)、规避和控制。
图-风险管理 第11章 软件纠正措施 11.1 目的 在本项目系统项目实施工程中，。
11.2 角色与职责 对项目实施发现问题和采取纠正措施过程中参与的角色和相应的职责定义如下表：
表格-纠正措施的角色和职责对应表 角色 职责 项目领导 负责审批和监控各子项目组所采取的纠正措施，负责项目中的重大问题组织制定纠正措施。
项目经理 对本项目组内发生的不合格的原因进行调查分析、制定并实施纠正措施。
问题发现者或提出者 收集、记录发生的问题，向项目组反映，并对解决结果和纠正措施发表意见进行回复。
质量保证组 负责对项目组内存在的不合格的原因进行调查分析并制订纠正措施，责成各项目组予以实施;
负责监督、验证所有纠正措施的制定和有效实施，并对各种纠正措施进行协调管理;
负责由纠正措施引起的相应规程的更改、重新发放及记录。
专家组 负责进行决策支持和技术支持，对发现的问题提出有效的解决方案，或者对已有的纠正措施进行评估分析。
11.3 纠正措施流程 当本项目系统项目实施过程中出现了(但不限于)以下情况时，须考虑采取纠正措施：
² 内部评审中发现的个别项目组存在的、在多个阶段中都存在的问题，比如进度滞后、难以沟通等;
² 内部评审中发现的质量保证和质量控制不适应当前实施情况，或是规定不够明确、具体的问题;
² 内部评审中发现的在具体规程执行中普遍存在的问题，比如计划粗略、实施过程不规范等;
² 收集的招标人意见及其处理结果反映出的较为集中的问题;
² 在管理评审中发现的普遍存在的问题。
² 硬件设备或软件系统性能达不到要求 对于纠正上述问题而采取措施的完成期限，一般不应超过一个月。
对于由于组织机构设置或是人力资源紧张而导致的问题，制定的纠正措施的完成期限应适当放宽，可放至一到三个月。
在出现以上问题时(不限于此)，应分析其原因，可从以下方面判断分析：
² 检查质量控制体系是否有疏漏，是否需要制定新的规程或是实施细则，以消除和避免此类问题的发生;
² 在规则已明确的情况下，问题的发生是否是因为该项目组(或多个项目组)资源不足或是时间进度安排不合理造成的;
² 问题的发生是否是因为未能认真执行有关规程造成的;
² 对本项目系统的需求理解是否准确、完备;
² 硬件设备和软件系统的设计是否存在缺陷;
² 项目计划是否恰当、合理;
² 项目管理是否充足、正确;
² 选择和使用的开发环境、开发工具和技术是否恰当;
² 项目组相互交流是否充分，对开发要求是否充分了解;
² 测试工作是否充分;
² 验收和验证活动是否正确。
采取措施进行纠正。由项目领导、项目经理、专家组、质量保证组和出现问题的项目组一起举行会议进行纠正措施的研讨。下表列出项目中可能出现的问题及相应的主要纠正措施：
表格-主要问题及纠正措施 主要问题 主要纠正措施 详见 进度滞后 重新安排进度、进行进度监控 进度计划 质量问题 质量审核、质量控制 质量保证计划 风险出现 风险识别、风险控制 风险管理计划 成本超出 成本预算、成本控制 成本管理计划 冲突 沟通、协商、冲突解决 冲突管理 纠正措施的验证。质量保证组根据纠正措施中规定的完成期限，及时验证措施实施的效果，并填写《纠正措施表》。对原措施无效或效果不明显的，需督促项目组重新采取纠正措施并落实。对于纠正措施无正当理由没有执行的，且未能协商出可接受的修正期限，质量保证组督促责任项目组，若仍无反应，由项目经理部加以追查并上报项目领导组，直到完成为止。在下次审核中，应检查此纠正措施是否仍然有效。如不再生效，则应重新发《纠正措施表》，记录并上报项目经理部和项目领导组。
质量保证组负责长期保存纠正措施的记录，纠正措施的结果做为项目关键阶段评审的信息输入。
第四部分 维护、售后服务方案 第1章 技术服务、维护计划方案 1.1 维护体制 。
1.2 组织架构 我 。
我们拟定的售后服务机构的组织机构图如下：
1.3 本地资源配置 方将对于本项目提供以下的本地资源配备：
。
1.4 维保能力 我方拟在本项目提供足够维保人力和物力，具体措施如下：
² 。
1.5 报修流程框架 1.6 业主方(用户方)维护人员培训 1.7 维护回馈 。
第2章 售后服务方案 2.1 我公司现有服务方案 2.2 售后服务内容 2.2.1 验收前售后服务内容 验收。
2.2.2 验收后售后服务内容 。
2.2.3 免费维护期之后的售后服务内容 负责软件功能的局部修改，界面修改，新功能的培训工作;
免费维护期后的售后服务年费以项目有效合同的售后服务年费为准。
2.3 售后服务流程 对于不满足服务质量的人、部门，公司制定了严格的规章制度，并将服务质量同个人的效绩进行挂钩。
2.4 售后服务方式 我方将提供丰富的售后服务支持方式，已最迅速、最直接、最适合的方式解决您的实际问题。
我方设立了一套较为完备的售后服务和技术支持体系，并确立网上监察项目的技术支持和售后服务体系设置如下：
客户服务 网上受理 技术支持中心 项目组现场支持 热线服务 总部支持 网上受理 服务方式具体说明如下：
l 电话支持 电话支持服务方式一般可用于解决一些简单故障，或解释客户的一些疑问;
在电话支持过程中，我售后服务人员将根据您描述的故障现象或疑问，做出耐心的解答;
电话支持的次数将不受限制，我们随时欢迎客户就各种问题与我售后服务人员进行交流，共同进步;
l 远程拨入 远程拨入方式将大大提高诊断速度与工作效率，现在各种远程拨入技术的发展也使这一手段的安全性和可行性得到保证。在客户允许的前提下，我售后服务人员将通过远程拨入方式，快速而直接地对系统进行诊断与故障排除，并提交详细的操作过程和配置文档;
l 现场服务 当以上两种支持方式仍不能解决您的问题，我售后服务人员将会立即赶赴现场进行紧急故障处理。当确诊为硬件故障时，我们将负责联系厂家进行技术支持。
l 文档、补丁升级 对于由于系统软件或应用程序过时或存在漏洞，而导致的系统隐患或故障，可以采用分发系统补丁或升级文档等方式解决。我们将根据具体情况，采用网络发送或上门安装等方式。
透过我们的服务计划，您可以得到有关设备在许可范围内的任何非随机软件的最新修补程序和维修软件新版本。
l 定期回访 我们认为定期回访这一环节以往并不被重视，但多年的服务经验告诉我们，回访制度具有很重要的作用：
对于潜在的问题，如能及早发现，将大大延长系统的无故障运行时间;
对于细小的问题，往往被忽视，直至发展为较难控制的地步;
对于并无明显故障但运行性能不理想的系统，必须进行配置的优化，或者设备的升级;
基于以上原因，我们将与用户约定访问交流制度，同时为用户送上以下内容：
系统及周边设备的常规检查;
最新产品介绍与业界动态信息;
其他用户的经验教训。
l 培训 技术培训是我方最重要的售后服务方式之一。在实施过程中，将对相关人员进行培训。
以上是我方有关售后服务承诺的一个基本框架，具体实施完全可以根据用户的意愿进行相应的调整，或根据用户的特殊要求，设计一些特殊的服务内容。总而言之，我们会根据客户的实际需求，整合现有的多种服务方式，最终为客户提供一个真正“量体裁衣”的服务计划。我方将坚持以“客户心目中的首选“为目标，为客户提供优良的服务而一直努力。
2.5 售后服务机构情况表 售后服务机构情况表 序号 机构名称 机构性质 注册地址 服务技术人员数量 联系电话 1 浙江某某有限公司 2 3 说明：我方已承诺在浙江省内，公司的售后服务人员直接由本公司委派，并根据需要统一协调技术力量，为本项目提供售后服务。硬件售后服务待项目实施时方能提供。
投标人(盖章)：_浙江某某股份有限公司_ 法定代表人或授权委托人(签字)：________________ 日期：_2013年06月05日_项 2.6 售后服务响应 2.6.1 售后服务人员配置响应 如果本系统在售后发生任何故障，或是您需要技术咨询，可以随时向售后服务人员寻求帮助：对于贵政府这样的重要客户，我方将制定一位客户经理，专职负责项目管理和故障响应，并进行定期的电话跟踪和上门回访，我们将提供该客户经理的手机号码、Email等联系方式，并保证手机24小时开机。
我们的服务人员为您提供尽善尽美的服务，解除您的后顾之忧。
2.6.2 售后服务人员情况表 应招标书要求，我公司拟排维护人员列表：
备注：参与本项目到位则打“√”，否则打“X” 售后服务人员情况表 序号 类别 姓名 性别 年龄 学历 专业 职称 本项目中职责 参与本项目是否到位 1 总协调人 项目经理 √ 2 3 4 投标人(盖章)：_浙江某某有限公司_ 法定代表人或授权委托人(签字)：________________ 日期：_2013年06月05日_ 2.6.3 故障等级划分 若本系统发生问题时，您可以根据实际状况确定故障等级，可以在下列四种等级中进行选择：
一级故障-—系统瘫痪，造成系统无法访问使用(紧急);
二级故障-—现有网络的性能严重下降，对系统的部分业务运作有重要影响(严重);
三级故障-一出现疑似故障或报警，同时大部分业务运作仍可正常工作(一般);
四级故障-—对业务运作几乎无影响，或根本没影响，但需要技术帮助(技术支持);
2.6.4 响应时间承诺 我们将根据以上的故障等级情况，正式为您做出响应时间承诺：
一级故障――我们承诺：“电话立即响应，在1小时内到现场”;
二级故障――我们承诺：“电话立即响应，在2小时内到现场”;
三级故障――我们承诺：“电话立即响应，在3小时内到现场”;
四级故障――我们承诺：“电话立即响应，安排人员远程或现场支持”。
如果故障在一定的时限内未能得以解决，该故障将自动升级到更高的故障层面，获得更高的关注程度和重视程度。
2.7 售后服务承诺 售 后 服 务 承 诺 尊敬的xxxx管理局：
我方售后服务方案内容完全满足标书中的要求，若我方中标，将提供包括但不限于如下的几点质保及售后服务承诺：
……。
投标方应提供相应的培训计划，详细说明培训的方式、地点、人数、时间等实质性内容。
投标人(盖章)：_浙江某某有限公司_ 法定代表人或授权委托人(签字)：________________ 日期：_2013年06月05日_项 2.8 优惠条件承诺 优惠条件承诺 我公司郑重承诺，针对本项目提供以下优惠条件：
1、免费提供安监其它业务信息化建设方案和咨询。
2、……。
投标人(盖章)：_浙江某某有限公司_ 法定代表人或授权委托人(签字)：________________ 日期：_2013年06月05日_项 第五部分 项目小组名单 第1章 项目小组人员名单 项目实施人员安排表 单位全称(公章)：
浙江某某有限公司 招标编号：XXXXXXXX-XXX 序号 姓名 性别 年龄 学历 专业资格 (页码) 在本项目中的职责 项目经历 到位情况 1 第209页 项目经理 承担商务标中多个案例项目开发的研发、管理、培训工作 到位 2 3 4 5 6 7 8 9 10 11 12 13 投标人(盖章)：_浙江某某有限公司_ 法定代表人或授权委托人(签字)：________________ 日期：_2013年06月05日_ 第2章 人员简历及证书 2.1 副总经理兼项目经理-xxx xxx履历 基本信 姓名 性别 年龄 职务 学历 所学专业 拟在项目中的岗位 联系电话 教育背景 期间 大学/培训 近三年工作简历 期间 项目名称 角色 业绩 优秀 优秀 优秀 优秀 优秀 优秀 【在此处贴上证件扫描件】 2.2 需求分析师、系统分析师- xxx履历 2.3 软件安全师- 2.4 软件工程师- 2.5 软件工程师- 2.6 软件工程师- 2.7 效果工程师- 2.8 性能测试工程师- 2.9 软件测试工程师- 2.10 UI设计师- 2.11 硬件工程师- 2.12 商务联络- 投标人(盖章)：_浙江某某有限公司_ 法定代表人或授权委托人(签字)：________________ 日期：_2013年06月05_ 第六部分 工程量、人工费、开发成本 第1章 工程量、人工费(不含保价) 。
本项目的工程量、人工费清单(不含报价)如下表：
表格-项目实施工程量、人工费清单 单位全称(公章)：
浙江某某有限公司 招标编号：XXXXXXXX-XXX 序号 大类 小类 内容描述 工程量(工作日) 工程量小计(工作日) 人工数(人) 1 需求分析 需求调研 与业主方沟通，进行需求调研 20 36 1 2 需求分析 需求分析的主要内容是系统各个功能模块的优化方案细节要求 10 1 3 需求方案设计编制 按需求调研结果，设计需求说明书，由建设双方共同评审前确认需求说明书，依说明书提出建设方案，确定工作内容和工作 量 6 1 4 系统设计 5 6 7 8 程序研发 9 10 11 12 13 14 15 系统测试 16 17 18 19 系统部署 20 21 22 22 小计(累计) 全权代表签名：
日 期：
2013年06月05日 第2章 开发成本等费用比清单 下表按所占各工作量填报相应百分比例，列出了开发概要设计成本。
2.1 开发成本等费用组成比说明表 表格-开发成本等费用组成比说明表 单位全称(公章)：
浙江某某有限公司 招标编号：XXXXXXXX-XXX 费用名称 在整个费用中所占比例(%) 1、前期调研费用 1.1、需求调研、业务沟通 1.2、前期软硬件部署、文档编写及项目研发其他准备事项成本费 2、人工成本应用系统开发成本 2.1、系统总体设计成本费 2.2、系统功能设计成本费 2.3、测试成本费 3、安装调试成本 3.1、 3.2、 4、硬件设备成本费 5、培训费 6、维护费用 6.1、需求叠代变更调研成本费 7、常驻专职工程师成本费 总计 全权代表签名：
日 期：
2013年06月05日 2.2 开发详细设计成本费用组成清单 其中详细设计成本比例如下(按工作日计算，及占总开发天数中百分比)：
表格-开发详细设计成本费用组成说明表 单位全称(公章)：
浙江某某有限公司 招标编号：XXXXXXXX-XXX 子系统名称 功能模块范围 开发成本占百分比(%) GGOA系统 主要实现领导组织、责任体系、工作上报、部门通知、请假申报、常用文档下载、数据查询的功能模块 4% 总计 100% 备注：开发成本占百分比(%)=各模块的开发成本/所有模块总开发成本*100% 全权代表签名：
日 期：
2013年06月05日 第七部分 培训计划 第1章 培训计划方案 1.1 培训计划声明 …… 因我方的原因导致培训不能按期完成，或原有的设计需要改变，业主方(用户方)有权要求我方重新进行培训，所有费用由我方承担。
1.2 培训目的 ……。
1.3 培训计划 ² …… 1.3.1 培训阶段划分 。
1.3.2 培训课程 。
1.3.2.1 系统管理员培训 ：
表格-系统管理员培训安排表 序号 课程 地点 1 系统总体介绍 2 开发工具及软件设计介绍 3 软件安装及配置、网络 4 5 6 7 8 1.3.2.2 相关领导培训 这部分人员经过培训，主要能达到以下目标：
：
表格-各领导培训安排表 序号 课程 地点 1 系统总体介绍 2 统计分析报表查看 3 各功能查询操作 4 相关权限的功能模块的操作 1.3.2.3 普通用户培训 这部分人员经过培训，主要能达到以下目标：
Ø 熟练操作软件的各个业务功能(或涉及业务的相关功能)。
Ø 熟练使用软件提供的各项统计分析工具。
课程安排如下，具体实施时提交详细计划，经业主审批后执行：
表格-普通用户培训安排表 序号 课程 地点 1 系统总体介绍 2 统计分析报表查看 3 各功能查询操作 4 个功能模块的基本操作 备注：该课程通过设置不同用户身份权限进行实例讲解。如安监人员、审批人员、机构领导等不同权限具有不同功能模块的操作，则我方提供按用户权限模块进行实例操作演示。
1.3.2.4 软件开发、维护培训 。
1.3.3 培训环境及设施 ……。
1.3.4 培训对象及人员 在本工程实施过程中，我方分阶段、分批对业主的系统管理人员、安监人员、维护维修人员以及培训人员本项目系统全面、系统、专业的培训。针对系统运行的需要，建议培训如下系统运营人员。
² 系统管理员：GGZHJGF信息平台的管理和维护(包括对软件的修改、开发、升级及测试);
1.3.5 教员资质 我方将指定具有相当理论水平……。
1.3.6 受训人要求 ：
² 系统管理员 è 熟悉GG安监行业知识及相关法律法规;
è 。
² 系统维护人员 è 具有计算机相关专业知识学习背景。
è 有 è 。
其他受训人员无条件要求。
第2章 培训内容 2.1 操作培训 。
2.2 维护培训 。
2.3 软件开发培训 。
2.4 现场培训 现场培训：将使系统管理员和普通用户学会对本项目系统的功能操作及维护。培训包括正常操作程序和怎样处理紧急情况。
2.5 其他培训 其它培训：根据业主方的实际需求，如果有需求，将对于服务器、web应用GGZHJGF信息平台的部署调试、路由器等硬件设备，以及操作系统、数据库、备份软件、网管软件和专用商业软件等的培训，为业主人员提供原厂商公开的免费标准培训课程，每门课程至少应培训2人次。
第3章 培训方法 我方对业主人员的培训。尽可能多地提供实验课时，以提高人员的实际操作水平。为达到培训目的，我方的培训计划针对全系统进行培训，培训的内容包括但不限于以下：
è ;
我方将提供以下几种培训方式：
现场培训：直接到业主方指定的现场及业主方调配的培训环境中进行培训;
网络或远程协助培训：直接使用QQ、视频、远程协助等手段进行远程培训;
电话及视频培训：直接使用电话、视频、多媒体等方式进行远程培训。
第4章 培训材料、效果及时间安排 4.1 培训材料 培训文件在培训实施前14个工作日提交给业主确认批准。
培训文件以Microsoft Office 2003/XP、PPT、Visio等经业主批准的格式提交。
书面教材保证培训人员每人1套，同时以光盘方式提交至少2份电子文档。
我方为每个培训课程提供培训相关的材料及文件。这些材料和文件包括：
表格-培训材料及文件列表 序号 材料及文件 说明 1 系统功能模块操作说明书 2 系统维护手册 系统配置、部署、调试、维护说明 3 系统数据库、网络管理基本操作说明书 包括数据库备份还原操作等，网络部署实例等 4 系统疑难问题解答书 5 系统后台操作说明书 如用户维护、权限维护、自定义设置等说明 6 基础网络知识文档、操作系统高级应用文档、系统集成文档 若有需要 7 硬件配置操作手册 若有需要 4.2 培训效果 为使培训人员不断进步而达到培训计划要求，如果业主方有所需要，我方在业主方的配合下组织所有培训人员都经常接受测验和考试，以确定他们可否称职地完成将被赋予的任务和工作。
我方准备并提交一份测验和考试计划，以及详细材料，包括范围、功能和方法供业主确认。
考核分理论考核及实践考核，该方案需经得业主方的审批方可执行。
4.3 培训费用 应招标书要求，除培训场地配置、业主方受训人员聚集等所需费用由业主方自行承担外的，凡是跟本项目有关的一切培训费用将由我方承担。
我方郑重承诺：以我方与业主方共同签署的合同为依据，将认真履行合同，提供本项目系统的免费培训服务。
4.4 培训时间安排 表格-培训时间安排表 课程名称 提供的资料 持续时间 授课教师 培训对象 培训地点 课程费用 系统维护操作培训 Xx操作说明书 4个工作日 系统维护人员 0.00 系统后台内管理培训 2个工作日 系统管理员 0.00 GGZHJGF信息平台操作培训 3个工作日 0.00 服务器安装配置 《服务器安装配置操作手持》 2个工作日 0.00 备注：具体时间待定。其他说明如下：
ü 培训方式采用集中分批培训，采用现场授课+上机，部分人员采用远程视频教程培训;
ü 培训地点由双方协商，用户指定，内部人员可在会议室统一培训，上机可至我司计算机机房进行上机操作。
投标人(盖章)：_浙江某某有限公司_ 法定代表人或授权委托人(签字)：________________ 日期：_2013年06月05日_ 第八部分 验收方案 第1章 验收要求 第2章 验收方案 2.1 项目验收组织机构 。
2.2 项目验收依据 在此次工程项目中，作为验收依据的主要包括：
l 投标方的《投标技术文件》;
l 双方签订的《项目合同书》;
l 双方签订的《用户需求说明书》、《需求规格说明书》;
l 项目实施中的《项目需求变更报告》;
l 其他项目相关文档及资料。
在这些文档当中，将以双方(用户方、实施方)认可《需求规格说明书》和《项目需求变更报告》这两份文档作为主要的验收依据。
2.3 项目验收时间安排 本项目的验收时间安排为：
在完成系统的安装、配置任务后，并在所有测试运行通过后，申请用户方进行系统的初验，初步预计在项目签订有效合同日起，后推至第16周。
系统正常试运行1个月后，组织对系统进行正式验收，初步预计在签订合同日起后推5个月底，及第20周。
2.4 项目验收流程 。
2.5 项目验收内容 1.验收内容 项目验收的内容主要包括以下方面：
l 项目进度计划执行情况 l 系统功能质量情况 l 系统界面设计情况 l 项目文档提交情况 l 其他 此次项目包括多个方面的工作和任务，每一项任务的完成、每一个文档的提交、每一个设备、软件或应用系统的交付，都有相应的完成标志和测试、评估和验收标准。
2.提交文档 在此次工程总体验收时，我方将提交 Ø 软件的源程序及可执行代码。源程序要求具有良好的编程风格，代码注释和说明必需完整，可执行代码以二进制文件或可安装文件的形式提供;
Ø 数据库的设计以及数据实体模型、相互关系和数据字典的描述;
Ø 网络系统的拓扑结构以及相关设备的配置;
Ø 系统的体系架构及描述;
Ø 网站页面视觉设计内容的素材原稿。
Ø 软件需求说明书 Ø 概要设计说明书 Ø 详细设计说明书 Ø 数据库设计说明书 Ø 服务扩展系统开发规范 Ø 技术手册(安装、操作、维护、故障排除等) Ø 测试计划 Ø 工程日志 Ø 试运行报告 投标人(盖章)：_浙江某某有限公司_ 法定代表人或授权委托人(签字)：________________ 日期：_2013年06月05日_ 第九部分 技术偏离说明表 第1章 技术偏离响应表 技术偏离说明表 单位全称(公章)：
浙江某某有限公司 招标编号：XXXXXXXX-XXX 序号 采购要求 投标响应 偏离情况 说明 1 第二部分 编制和提交采购响应文件须知 二、招标文件 8.1标的物 三、投标文件编制 我方已认真阅读和理解招标书内容 无偏离 我方完全理解和响应其采购总则，我方明确标的物为SCCGGZHJGF信息平台建设项目包括11大子系统，一手持终端应用系统和企业端应用系统，和相关的硬件设备的采购及配置。
我方的投标文件的编制已完全遵照招标书中的投标文件编制要求，并覆盖招标书的相关内容。
2 第三部分项目技术规范和服务要求 完全理解和响应 无偏离 见本技术方案的“第二部分”至“第九部分” 3 第2章.总体方案 2.1.使用对象 2.2建设目标 2.3建设原则 要求具有：
先进性和成熟性;
开放性和标准性;
时效性和共享性;
安全性和可靠性;
可扩展性和易维护性 完全理解和响应。
正偏离 我方采用java技术平台，J2EE技术路线，并结合MVC技术、jquery、web服务技术和组件化模块开发技术实现其先进性、成熟性、时效性和共享性。
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 注：投标人应根据投标设备的性能指标、对照招标文件要求在“偏离情况”栏注明“正偏离”、“负偏离”或“无偏离”。
投标人(盖章)：_浙江某某有限公司_ 法定代表人或授权委托人(签字)：________________ 日期：_2013年06月05日_ 第十部分 其他说明 第1章 验收文档附件 以下附录几个验收文档：
验收申请书 项目名称：
建设单位：
承建单位：
项目开始日期：
项目结束日期：
承建单位盖章：
项目经理签字：
日期：
年 月 日 建设单位意见：
建设单位(签字或盖章) 日期：
用户使用报告书 一、申请验收的业务软件(子系统)名称 业务软件(子系统)名称 承建单位 二、验收说明 1、应用软件能否满足相关政策法规要求，能否满足业务需求、功能需求并经过充分运行(两个月)的验证。
2、应用软件的软件操作方便性、软件性能、软件稳定性能否满足工作需要。
3、培训工作、运行维护工作、数据迁移工作能否满足工作需要。
4、对于在试运行后产生的新需求，作为下一步完善软件系统的需求对待，不影响验收通过。
三、本单位使用的业务软件(子系统)名称 四、验收评审意见 □ 通过 □不通过 五、存在问题及建议(意见为通过或不通过，都可以列出目前存在的问题及建议) 六、负责人签字、盖章 单位名称(盖章)：
单位负责人(签字)：
日期：
业务部门：
部门负责人(签字)：
日期：
专家评审表 项目名称：
建设单位：
承建单位：
开工日期：
竣工日期：
专家意见：
1)是否满足本业务需求 2)功能需求和性能需求 3)文档是否齐全 4)其他意见 专家签名：
第2章 问题回馈单附件 表单一：
表单二：
第3章 设备配置清单 产品设备配置(软件)清单 单位全称(公章)：
浙江某某有限公司 标项：
一 序号 设备名称 品牌 规格 型号 单位及 数量 性能及指标 产地 1 《GGZHJGF信息平台》 xxxx科技 V1.0 1套 具有高并发、可配置化的实用性较强的安监电子政务的GGZHJGF信息平台系统 GG 2 全权代表签名：
日期：
2013年06月05日 硬件设备配置清单 单位全称(公章)：
浙江某某有限公司 招标编号：XXXXXXXX-XXX 序号 名称 参数配置 数量 备注 1 应用CX服务器 DELL R720 2U机架式服务器;
英特尔四核至强处理器E5620;
8GB(4*2GB) DDR3-1333 ECC+REG内存;
600GB(300GB*2) 3.5寸热插拔SAS硬盘(15000RPM) RAIDI1;
Broadcom四端口千兆自适应网卡 1 1、参考品牌：
DELL 英特尔 金士顿 威刚 2、服务器要求提供原厂商正式服务承诺函、原厂商产品授权证明 2 数据库服务器 DELL R720 2U机架式服务器;
英特尔四核至强处理器E5620;
12GB(3*4GB)DDR3-1333 ECC+REG内存;
900GB(300GB*3) 3.5寸热插拔SAS硬盘(15000RPM) RAIDI5;
Broadcom四端口千兆自适应网卡 1 3 备份服务器 DELL R720 2U机架式服务器;
英特尔四核至强处理器E5620;
8GB(3*4GB)DDR3-1333 ECC+REG内存;
900GB(300GB*3) 3.5寸热插拔SAS硬盘(15000RPM) RAIDI5;
Broadcom四端口千兆自适应网卡 1 4 手持设备 纽曼P9平板电脑 Android 2.3/1.2GHZCPU/512MDDR3内存/电容屏8寸/3G WIFI 3 5 系统配套用PC 联想商用/扬天T2900d/双核E6700/2G内存/500G硬盘/20宽屏 6 6 系统运行环境 Windows server 2003 3 Tomcat 3 Mysql 2 防病毒系统 3 备注：实际提供的硬件设备的参数及性能不低于上表中的相关指标。
全权代表签名：
日 期：
2013年06月05日
一、验收目的
为使信息化项目建设按照标准要求进行，确保项目竣工后达到有关要求和标准，并能正常投入运行，必须进行项目验收。
二、验收对象
参与项目建设的施工单位。
三、项目验收的前提条件：
(1) 所有建设项目按照合同要求全部建成，并满足使用要求; (2) 各个分项工程全部验收合格; (3) 已通过软件确认测试评审; (4) 已通过软件系统测试评审; (5) 软件已置于配置管理之下;
(6) 各种技术文档和验收资料完备，符合合同的内容;
(7) 系统建设和数据处理符合信息安全的要求，涉密信息系统需提供主管部门验收的合格证书;
(8) 外购的操作系统、数据库、中间件、应用软件和开发工具符合知识产权相关政策法规的要求;
(9) 各种设备经加电试运行，状态正常; (10) 经过监理方同意;
(11) 经过相关主管部门和项目业主同意; (12) 合同或合同附件规定的其他验收条件;
四、验收方法
项目验收是项目开发建设中有组织的主动性行为，它是对项目建设高度负责的体现，也是项目建设成功的重要保证。切实做好项目建设中的验收工作至关重要，应当采取有效措施，实实在在做好。为保证项目验收质量，针对不同的验收内容，在实施验收操作中，可以采取以下不同的方法：
(一)登记法
对项目中所设计的所有硬件、软件和应用程序一一登记，特别是硬件使用手册、软件使用手册、应用程序各种技术文档等一定要登记造册，不可遗漏，并妥善保管。对项目建设中根据实际进展情况双方同意后修订的合同条款、协调发展建设中的问题进行登记。
(二)对照法
对照检查项目各项建设内容的结果是否与合同条款及工程施工方案一致。
(三)操作法
这是项目建设最主要的验收方法。首先，最项目系统硬件一一实际加电操作，验证是否与硬件提供的技术性能相一致;其次，运行项目软件系统，检验其管理硬件及应用软件的实际能力是否与合同规定的一致;第三，运行应用软件，实际操作，处理业务，检查是否与合同规定的一致，达到了预期的目的。 (四)测试法
对能使用检测仪器进行检测的设备，实施应当一一进行实际测试，检查是否和设备、实施的规格、性能要求相一致。
五、验收步骤
(一) 需求分析
项目监理单位组织人员对项目进行验收需求分析，针对项目验收，监理单位需配备2名有经验的工程师和一名行业专家来组成项目团队，负责具体工作。
(二)编写验收方案(计划书)
项目监理单位在对项目进行深入的需求分析的基础上编写验收方案(计划书)，提交业主单位审定。
(三)成立项目验收小组
实施测试验收工作时，应当成立项目验收小组，具体负责验收事宜。
(四)项目验收的实施
严格按照验收方案对项目应用软件、网络集成效果、系统文档资料等进行全面的测试和验收。
(五)提交验收报告
项目验收完毕，对项目系统设计、建设质量、设备治疗、软件运行情况等做出全面的评价，得出结论性意见，对不合格的项目不予验收，对一流问题提出具体的解决意见。
(六)召开项目验收评审会
召开由验收委员会全体成员参加的项目验收评审会，全面细致的审核项目销售小组所提交的验收报告，给出最终的验收意见，形成验收评审报告提交项目业主存档。
六、验收程序
(一)初验
1、申请：项目竣工后经测试和试运行合格，施工单位根据合同、招标书、计划任务书，检查、总结项目完成情况后向业主提出初验申请。
2、方式：项目业主组织监理和施工单位进行初验。
3、施工单位提供材料：初验申请书、完工报告、项目总结、一级要求的验收评审资料。
(二)终验
1、申请：初验合格后，项目业主根据合同、招标书、任务书，检查、总结项目实施和完成情况后向主管部门提出验收申请。
2、经过审核，材料齐全则由主管部门组织验收。
验收工作有由主管部门和项目业主、监理等单位和专家组组成验收小组进行验收。验收工作分为两个步骤：验收小组和验收评委会评审，由验收小组共同确定验收时间、评审时间及其他安排。
(1) 验收小组验收
验收小组一般由5-8人组成，成员由主管部门和项目业主的管理人员、监理单位专业技术人员共同完成。验收时参照相关验收内容及标准进行，验收后必须提交验收报告。 (2) 验收委员会评审
验收委员会一般由8-15人组成，成员由验收小组及主管部门、项目业主和监理单位的领导、专家等组成。验收委员会评审一般采取会议评议方式进行，听取验收总结报告说明、验收小组验收结果及意见，通过评审提交验收评审报告。
(3) 项目业主提供材料：验收申请、项目建设总结性评价报告(组织与实施协调)、项目 实施报告(技术、项目管理、质量控制)、相关文档资料、验收安排计划、验收小组及委员会名单、验收计划书(由监理单位负责)
3、 验收签字
经过验收、评审形成的验收报告和评审报告，验收委员会成员签字。
七、验收依据
作为项目验收的依据，一般选用项目合同书、国标、行业标准和相关政策法规、国际惯例等。
(一) 项目合同书 签定的项目有关合同
(二) 国家标准
硬件、软件、布线、安全等
(三) 新疆省信息化项目建设管理暂行办法
(四) 其他
具体验收标准和一句由监理单位根据具体项目情况提出，主管部门和项目业主审定。
八、验收内容和标准
根据具体项目实际制定，由项目监理单位负责编写，主管部门和项目业主审定。项目验收标准是判断项目成果是否达到要求的一句，因而应具有科学性和权威性，只有制定科学的标准，才能有效的验收项目结果。验收内容一般包括测试(复核)、资料评审、质量鉴定三部分。
验收的内容包括以下几个部分：
(一) 验收内容一般包括软件验收(按功能要求的可执行软件、开发计划文档、详细设计文档、质量保证计划、设备相应附件、设备运行、网络运行等)
(二) 验收评测工作主要包括：文档分析、方案制定、现场测试、问题单提交、测试报告;
(三) 验收测试内容主要包括：功能度、安全可靠性、易用性、可扩充性、兼容性、效率、资源占用率、用户文档。
(四) 文档验收标准一般包括：文档完备性、内容针对性、内容充分性、内容一致性、文字明确性、图表详实性、易读性、文档价值等。
(五) 软件、硬件验收标准要符合国家和相关标准。 需要评审的资料包括以下几个部分：
(一) 基础资料：招标书、投标书、有关合同、有关批复文件、系统设计说明书、系统功能说明书、系统结构图、项目详细实施方案。
(二) 项目竣工资料：项目开工报告、项目实施报告、项目质量测试报告、项目检查报告、测试报告、材料清单、项目实施质量与安全检查记录、操作使用说明书、售后服务保证文件、培训文档、其他文件。
(三) 软件开发文档：需求说明书、、概要设计说明书、详细设计说明书、数据库设计说明书、测试计划、测试报告、程序维护手册、程序员开发手册、用户操作手册。
(四) 软件开发管理文档：项目计划书、质量控制计划、配置管理计划、用户培训计划、质量总结报告、会议记录和开发进度月报。
九、验收结论
验收结果分为:验收合格、需要复议和验收不合格三种。符合信息化项目建设标准、系统运行安全可靠、任务按期保质完成、经费使用合理的，视为验收合格;由于提供材料不详难以判断，或目标任务完成不足80%而又难以确定其原因等导致验收结论争议较大的，视为需要复议。
1、 项目凡具有下列情况之一的，按验收不合格处理：
(一) 未按项目考核指标或合同要求达到所预定的主要技术指标的;
(二) 所提供材料不齐全或不真实的;
(三) 项目的内容、目标或技术路线等已进行了较大调整，但未曾得到相关单位认可的;
(四) 实施过程中出现重大问题，尚未解决和作出说明，或项目实施过程及结果等存在纠纷尚未解决的;
(五) 没有对系统或设备进行试运行，或者运行不合格;
(六) 项目经费使用情况审计发现问题的;
(七) 违犯法律、法规的其他行为;
2、验收结论确认和处理
由主管单位同相关部门根据验收已经和相关资料得出结论，并进行确认。
3、 项目验收结论的处理
(一) 验收结论为验收合格的，项目业主将全部验收材料同意装订成册并连同相应的电子文档分别报主管部门及相关部门备案。
(二) 验收结论需要复议的，主管部门以书面形式通知建设单位在三个月内补充有关材料或者进行相关说明。
(三) 验收结论为验收不合格的，主管部门以书面形式通知项目业主和设计、施工单位，限期整改，整改后试运行合格的，项目业主重新申请验收。
(四) 未通过验收的信息化项目，不得交付使用。
十、项目交接
项目竣工验收合格后，应班里项目交接手续。项目的移交包括实体移交和项目文件移交部分。 十
一、各项目业主和监理单位要严格参照此方案开展项目验收工作。
1 项目质量管控
1.1目的
本计划的目的在于对所开发的软件规定各种必要的质量保证措施，以保证所交付的软件能够满足项目预定需求，能够满足本项目总体组制定的且经领导小组评审批准的该软件系统需求规格说明书中规定的各项具体需求。
软件开发项目组在开发软件系统所属的各个子系统(其中包括为本项目研发或选用的各种支持软件、组件)时，都应该执行本计划中的有关规定，但可根据各自的情况对本计划作适当的剪裁，以满足特定的质量保证要求，剪裁后的计划必须经项目组相关负责人批准。 1.2管理 1.2.1机构
在本软件系统整个开发期间，必须成立软件质量管理小组负责质量保证工作。 软件质量保证组和项目负责人及各领导组必须检查和督促本计划的实施。系统的软件质量保证人员有权直接向各领导组报告该项目的软件质量状况。系统的软件质量保证人员应该根据对项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划的所有要求。 1.2.2任务
软件质量保证工作涉及软件生存周期各阶段的活动，应该贯彻到日常的软件开发活动中，而且应该特别注意软件质量的早期评审工作。因此，对于所负责系统，要按照本计划的各项规定进行各项评审工作。软件质量保证小组要参加所有的评审与检查活动。评审与检查的目的是为了确保在软件开发工作的各个阶段和各个方面都认真采取各项措施来保证与提高软件的质量。在软件开发过程中，要进行如下几类评审与检查工作：
a. 阶段评审：在软件开发过程中，要定期地或阶段性地对某一开发阶段或某几个开发阶段的阶段产品进行评审。在软件及其所属各子系统的开发过程中，应该进行以下三次评审：第一次评审软件需求、概要设计、验证与确认方法;第二次评审详细设计、功能测试与演示，并对第一次评审结果复核;第三次是功能检查、物理检查和综合检查。
阶段评审工作要组织专门的评审小组，原则上由项目总体小组成员或特邀专家担任评审组长，评审小组成员应该包括项目所有成员、质量保证人员、和上级主管部门的代表，其他参加人员视评审内容而定。
每一次评审工作都应填写评审总结报告(RSR)、评审问题记录(RPL)、评审成员签字表(RMT)与软件问题报告单(SPR)等四张表格。
b. 日常检查：在软件的工程化开发过程中，各子系统应该填写项目进展报表，即软件进展报表表头、软件阶段进度表、软件阶段产品完成情况表、软件开发费用表等四张表格。项目组杨大亮或其他领导通过项目进展季报表发现有关软件质量的问题。
c. 软件验收：必须组织专门的验收小组对软件系统及其所属各个子系统进行验收。验收工作应该满足各业务部门、领导部门及相关使用部门的需求，质量管理小组验收内容应包括文档验收、程序验收、演示、验收测试与测试结果等几项工作。而公司领导层、业务部门验收软件的功能演示成果及使用手册等。 1.2.3职责
在项目的软件质量保证小组中，其各方面人员的职责如下： a. 组长全面负责有关软件质量保证的各项工作;
b. 全组负责有关阶段评审、项目进展报表检查以及软件验收准备等三方面工作中的质量保证工作;
c. 项目的专职配臵管理人员负责有关软件配臵变动、软件媒体、文件控制以及对软件提供商的控制(在系统使用相关正版软件厂商提供的产品时生效)等三方面的质量保证活动;
d.全组负责测试复查和文档的规范化检查工作;
e. 用户体验师反映用户的质量要求，并协助检查各类人员对软件质量保证计划的执行情况; f. 项目的专职质量保证人员协助组长开展各项软件质量保证活动，负责审查所采用的质量保证工具、技术和方法，并负责汇总、维护和保存有关软件质量保证活动的各项记录。 1.3文档 1.3.1基本文档
为了确保软件的实现满足认可的需求规格说明书中规定的各项需求，软件开发项目组至少应该编写以下八个方面内容的文档： a. 软件需求规格说明书(SRS);
b. 软件设计说明书(SDD)，对一些规模较大或复杂性较高的项目，应该把本文 档分成概要设计说明书(PDD)与详细设计说明书(DDD)两个文档; c. 软件测试计划(STP); d. 软件测试报告(STR); e. 用户手册(SUM); f. 源程序清单(SCL); g. 项目实施计划(PIP); h. 项目开发总结(PDS)。 1.3.2其他文档
除了基本文档之外，对于尚在开发中的软件，还应该包括以下四个方面的文档：
a. 软件质量保证计划(SQAP); b. 软件配臵管理计划(SCMP); c. 项目进展报表(PPR); d. 阶段评审报表(PRR)。
注：前面两个文档由项目组制订，属于管理文档，项目组应充分考虑执行计划中规定的条款。后面两类文档属于工作文档，就是本计划的2.2中提到的四张阶段评审表与四张项目进展季报表，项目组按照规定要求认真填写有关内容。 1.3.3文档质量的度量准则
文档是软件的重要组成部分，是软件生存周期各个不同阶段的产品描述。验证和确认就是要检查各阶段文档的合适性。评审文档质量的度量准则有以下六条： a. 完备性：所有承担软件开发任务的项目，都必须按照GB 8567(是国家标准局的指南文档，名称叫《计算机软件产品开发文件编制指南
》)的规定编制相应的文档，以保证在开发阶段结束时其文档是齐全的。 b. 正确性：在软件开发各个阶段所编写的文档的内容，必须真实地反映该阶段的工作且与该阶段的需求相一致。
c. 简明性：在软件开发各个阶段所编写的各种文档的语言表达应该清晰、准确简练，适合各种文档的特定读者。
d. 可追踪性： 在软件开发各个阶段所编写的各种文档应该具有良好的可追踪性。文档的可追踪性包括纵向可追踪性与横向可追踪性两个方面。前者是指在不同文档的相关内容之间相互检索的难易程度;后者是指确定同一文档某一内容在本文档中的涉及范围的难易程度。
e. 自说明性：在软件开发各个阶段所编写的各种文档应该具有较好的自说明性。文档的自说明性是指在软件开发各个阶段中的不同文档能独立表达该软件其相应阶段的阶段产品的能力。
f. 规范性：在软件开发各个阶段所编写的各种文档应该具有良好的规范性。文档的规范性是指文档的封面、大纲、术语的含义以及图示符号等符合有关规范的规定。 1.4评审和检查
对新开发的或正在开发的各个子系统，都要按照GB 8566(计算机软件开发规范)的规定认真进行定期的或阶段性的各项评审工作。就整个软件开发过程而言，至少要进行软件需求评审、概要设计评审、详细设计评审、软件验证和确认评审、功能检查、物理检查、综合检查以及管理评审等八个方面的评审和检查工作。在软件及其所属各个子系统的开发过程中，把前七种评审分成三次进行。在每次评审之后，要对评审结果作出明确的管理决策。下面给出每次评审应该进行的工作。 1.4.1第一次评审
第一次评审会对软件需求、概要设计以及验证与确认方法进行评审。 a. 软件需求评审(SRR)应确保在软件需求规格说明书中规定的各项需求的合理性。
b. 概要设计评审(PDR)应评价软件设计说明书中的软件概要设计的技术合适性。 c. 软件验证和确认评审(SV&VR)应评价软件验证和确认计划中确定的验证和确认方法的合适性与完整性。 1.4.2第二次评审
第二次评审会要对详细设计、功能测试与演示进行评审，并对第一次评审结果进行复核。如果在软件开发过程中发现需要修改第一次评审结果，则应按照《软件配臵管理计划》的规定处理。
a. 详细设计评审(DDR)应确定软件设计说明书中的详细设计在满足软件需求规格说明书中的需求方面的可接受性。
b. 编程格式评审应确保所有编码采用规定的工作语言，能在规定的运行环境中运行，并且符合GB 8566中提倡的编程风格。在满足这些要求之后，方可进行测试工作。
c. 测试工作评审应对所有的程序单元进行静态分析，检查其程序结构(即模块和函数的调用关系和调用序列)和变量使用是否正确。在通过静态分析后，再进行结构测试和功能测试。在结构测试中，所有程序单元结构测试的语句覆盖率Co必须等于100%，分支覆盖率C1必须大于或等于85%。要给出每个单元的输入和输出变量的变化范围。各个子系统只进行功能测试，不单独进行结构测试，因而要登录程序单元之间接口的变量值，力图使满足单元测试的C1和Co准则的那此测试用例在子系统功能测试时得到再现。测试工作评审要检查所进行的测试工作是否满足这些要求。特别在评审功能测试工作时，不仅要运行变量的等价值，而且要运行变量的(合法的和非法的)边界值;不仅要运行开发组给出的测试用例，而且要允许运行其他相关人员、评审人员选定的采样用例。 1.4.3第三次评审
第三次评审会要进行功能检查、物理检查和综合检查。这些评审会应在集成测试阶段结束后进行。
a. 功能检查(FA)应验证所开发的软件已经满足在软件需求规格说明书中规定的所有需求。
b. 物理检查(PA)应对软件进行物理检查，以验证程序和文档已经一致、并已做好了交付的准备。
c. 综合检查(CA)应验证代码和设计文档的一致性、接口规格说明之间的一致性(硬件和软件)、设计实现和功能需求的一致性、功能需求和测试描述的一致性。 1.5软件配臵管理
对工程化软件系统的各项配臵进行及时、合理的管理，是确保软件质量的重要手段，也是确保该软件具有强大生命力的重要措施。有关工程化软件的配臵管理工作，可按软件项目组编写的《软件配臵管理计划》。在软件配臵管理工作中，要特别注意规定对软件问题报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。 1.6工具、技术和方法
在项目所属的各个子系统(其中包括有关的支持软件)的研制与开发过程中，都应该在各自的软件质量保证活动中合理地使用软件质量活动的支持工具、技术和方法。这些工具主要有下列三种：
a.软件测试工具。它支持用java语言编写的模块的静态分析、结构测试与功能测试。主要功能为：协助测试人员判断程序结构与变量使用情况是否有错;给测试人员提供模块语句覆盖率Co和分支覆盖率C1的值，并显示未覆盖语句和未覆盖分支的号码及其分支谓词，给出不同测试用例有效性的表格;同时提出功能测试的有效情况，并协助组织最终交付给用户的有效测试用例的集合。 b. 软件配臵管理工具。它支持用户对源代码清单的更新管理以及对重新编译与连接的代码的自动组织;支持用户在不同文档相关内容之间进行相互检索并确定同一文档某一内容在本文档中的涉及范围;同时还应支持软件配臵管理小组对软件配臵更改进行科学的管理。 c. 文档辅助生成工具与图形编辑工具。它主要协助用户绘制描述程序流程与结构的DFD图与SC图、绘制描述软件功能(输入、输出关系)的曲线以及绘制描述控制系统特性的一些其他图形，同时还可生成若干与软件文档编制大纲相适应的文档模块板。用户利用这个工具的正文与图形编辑功能以及上述辅助功能，可以比较方便地产生清晰悦目的文档，也有利于对文档进行更改，还有助于提高文档的编制质量。 1.7媒体控制
为了保护计算机程序的物理媒体，以免非法存取、意外损坏或自然老化，工程化软件系统的各个子系统(包括支持软件)都必须设立软件配臵管理人员，并按照软件项目小组制订的、且经领导层批准的《软件配臵管理计划》妥善管理和存放各个子系统及其专用支持软件的媒体。 1.8记录收集、维护和保存
在项目及其所属的各个子系统的研制与开发期间，要进行各种软件质量保证活动，准确记录、及时分析并妥善保存有关这些活动的记录，是确保软件质量的重要条件。在软件质量保证小组中，应有专人负责收集、汇总与保存有关软件质量保证活动的记录。
软件开发实训项目方案
——北京中科海教育科技有限公司
一. 实训公司介绍
科海集团是在1983年5月由中国科学院和北京市海淀区政府联合创办，是中关村最早成立的高新技术企业，国内知名的IT企业，与“四通、融通、京海、科海”并称为中关村的“两通两海”。2003年，科海集团投资创办北京金科海科技发展有限公司。2004年，公司被认定为中关村高新企业。
北京中科海教育科技有限公司是以软件开发为主的高科技公司，专注于技术提高用户体验为目标，我们追求软件产品的最优化，致力于为客户打造最实用的软件产品。我们主要致力于全球中小型企业信息化系统的开发工作，包括CRM，ERP，协同系统等。涉及政府，房地产，医药等多个行业。同时为广大客户提供全方位的网络综合信息化服务及多层次电子商务解决方案。协助企业创建完备出色的互联网信息平台，利用现代科技手段把握机遇，并创造更高价值。其下属的全资子机构，北京新科海学校致力于IT职业技能培训业务，牢固树立以就业为导向，以服务为宗旨的办学理念，多年来培养了大量的IT领域高技术专门人才，为区域经济和社会发展做出了巨大贡献。
二. 关于大学生就业实训
2009年，全国应届高校毕业生将达到万人，加上往年未就业的高校毕业生，就业需求极大。而另一方面，受当前经济形势影响，出现了企业用工需求下降、现有岗位非正常流失等新情况、新问题，致使当今大学生就业问题显得尤为突出。与此同时，当今高等教育和社会需求之间并不能很好地衔接，企业需要的是复合型、实用技能型人才，而高校毕业生所受教育普遍存在与其日后从事岗位所需的实践技能脱节的问题，学历层次不等于技能层次。
按照教育服务市场需求、服从产业结构调整的原则，改造现有高校课程设置结构、调整专业培养方向、强化实用技能培训、为学生提供就业项目实训等创新培养模式成为必然。
为推进高等教育、职业培训与社会需求相衔接，北京中科海教育科技有限公司推出IT领域大学生就业实训项目，本课程由IT企业为新入职技术职位员工的内训课程改造而来，主要针对高校计算机及相关专业毕业生，通过专业的项目开发训练，让学员们在完
成项目的过程中巩固在学校里学习到的基础知识。获得实用、领先的就业经验技能;增加求职竞争力，并在其职业生涯第一年拥有明显优势;在职人员可以丰富自己的职业技能，开拓更为广阔的职业道路。
三. 实训项目介绍
Java软件开发实训项目
实训目标：
软件开发实训课程，通过一个完整的软件开发项目，使具有一定编码基础、但没有或只有很少实际工作经验的学员能够了解软件项目开发的整个过程，并最终具备编写项目可行性研究报告、项目开发计划书、软件需求文档、概要设计和详细设计文档、用户手册及项目开发总结报告的能力。
实训项目资料：
-
-
-
-
-
-
-
-
开发环境配置手册项目需求文档项目概要设计文档项目详细设计文档项目数据库设计文档程序代码规范开发流程规范程序代码质量控制规范
项目一: 内容管理系统CMS设计与实现
内容管理系统(Content Management System，CMS)内容管理系统是企业信息化建设和电子政务的新宠，也是一个相对较新的市场，CMS其实是一个很广泛的称呼，从一般的博客程序，新闻发布程序，到综合性的网站管理程序都可以被称为内容管理系统。
在CMS领域，在各个层面都有极多地优点，在政府上网，学校上网，商业门户，信息港，地方门户网，等各种设计到文章发布和用管理的网站建设中。其特点/优势如下：
- 可以针对各种内容进行分类和发布管理。可以针对不同类型的用户发布不
同的内容，可以将各种内容进行分类。
- 可以任意定义内容类型与多媒体支持。
- 用户接口可编辑性强，可以根据客户要求订做用户接口和风格模块。
- 可分布式管理。站点管理和维护人员无须集中在同一个办公室，甚至都不
用在同城，全球任何一个有网络的地方都可以让您实现高效率的管理。
- 可开发性强，可以针对不同的需求进行专门的开发。
容易使用。用户不必具备计算机编程基础、只需根据用户操作手册(或经
过简单演示)就可以轻松地管理并运作整套系统。
系统开发与运行环境：
-服务器：基于Intel构架的企业服务器
-操作系统：Microsoft Windows 200x/XP
-支持环境：Tomcat/WebLogic Server、JDK
-数 据 库：Oracle
-编程语言：Java、Servlet、JSP、Javabeans、HTML
-设计工具： Dreamweaver、Photoshop、Eclipse等
-客户端：IE6.0以上
前提知识/技术：JavaSE、Java Web编程(JSP/Servlet/JavaBean)、数据库应用、JDBC编程。
项目二: 网络实时通讯系统设计与实现
实时通讯系统(Real-time Communication System，RCS)也称“即时通讯工具”，用于实现网络即使通讯——利用有效硬件，如电脑、视频、可视电话、手机等，在这些终端硬件上安装实时通讯程序，如QQ、ICQ、MSN、网易POPO等，只要双方都安装有同样的这种程序，然后利用网络连接在线，就可以类似面对面交流一样，实行语音、文字、视频等的实时交流。
系统开发与运行环境：
-服务器/客户端：主流PC
-操作系统：Microsoft Windows 200x/XP
-支持环境：Sun JDK
-数 据 库：Oracle
-编程语言：Java SE
-设计工具：UltraEdit/Jcreator/Eclipse等
前提知识/技术：JavaSE、Java GUI编程、Java Scoket编程、多线程编程、数据库应用、JDBC编程。
-
四. 实习特色及优势
实训周期：
项目实训时间由院校和我公司双方协商，实训学时：80学时(两周)。
资深专家
行业内资深技术专家亲自指导，他们在技术、项目及职业发展方面的经验与成就，为参加实习的学生提供最直接高效的实习效果。
全真项目
项目也是至关重要的因素，学生实习的项目就是公司真实开发的项目，代表了当前国际国内IT行业最主流的技术方向及应用领域。
赠送资料
凡参加暑期实训的学员均赠送java学习视频教程一套
五. 时间安排
暑期项目实训时间定于2009年7月20日-2009年7月31日，周一至周五全天实训。
7月20日-7月24日 项目实训
7月27日-7月31日 项目实训
7月26日参观北京奥林匹克公园(免费)
除了暑期之外，其他时间，也欢迎各个大学联系我们，组织学生参加我们的免费实训(为期两周，无任何学习费用，食宿自理)。
六. 后勤保障及服务
接待
我们提供从车站到实习公司的一站式接待服务，院校及学生无需为交通、接站、入住基地等事宜操心。
食宿
公司统一安排食宿，安全卫生便捷，以保证所有学生能全身心投入到实习中去。真正感觉北京IT行业的良好氛围。
住宿费一天25元，楼房，24小时热水，有空调。
七. 联系方式
联系人：高老师
北京中科海教育发展有限公司
电话：010- 8260889
2、82617627
项目技术文件：
项目编号：
项目名称：济南广电VOD软件系统采购
项目说明
本次VOD软件项目是 网站VOD系统的换代升级。将采用目前业界通用的视频技术，结合电视、电台的清流源信号实现全网络的视频点击和直播功能。该次采购的内容包括VOD软件(采集平台、转码、媒体管理、点播直播播出平台、互动平台)以及，采集转码功能中需要的集成硬件。本次项目价格包括VOD软件价格和需要集成的硬件价格，及除服务器外所有软件价格和集成设备的价格，涉及的服务器配置需要提供给购买方。
VOD软件系统技术参数要求：
二、资格、资质证明文件
1) 营业执照副本、税务登记证副本、组织机构代码证(复印件加盖公章);
2) 法定代表人授权委托书(附件二);
3)投标供应商必须提供VOD软件系统生产厂家的授权证明书和售后服务承
诺书;
4) 供应商所报货物是进口产品的，必须保证货物的来源合法;若成交，在
货物验收的同时必须提供该货物的海关进口证明、产品合格证书和商检
证明;
5)供应商认为需要提交的其它文件。
商务要求
1、投标商须提供2011年至今同类产品的应用案例(提供合同原件)。
2、项目实施工期：本项目时间紧迫，要求实施周期为合同签订后60天内，
即在60日内系统上线使用，每超过一个自然日将扣除投标方中标金额的1%。
3、本系统质保期为3年。系统验收合格，双方签署VOD软件系统验收书之
日起3年内免费维护与升级软件系统，并每月一次检查服务器和软件系统运行情况。
4、在标书中说明质保期满后的每年维保费用。
5、投标供应商必须提供vod软件系统正常运行所需的服务器、存储等硬件
配置清单及参考价格。
6、服务响应：供应商提供7×24小时电话咨询服务，远程技术支持服务，
重大故障(如：直播、点播服务停止，服务器宕机)12小时内软件维护人员到现场处理。
7、投标方提供完整的培训方案，保证操作人员能熟练地对系统进行使用，
保证技术人员能掌握对系统进行简单的维护和开发，提供技术维护手册，升级、安装手册。
8、技术服务：系统验收合格，中标人需要提供软件产品完整的接口文档，
并根据招标人实际需求完成定制的开发工作。开发完成后需开放系统的数据和应用接口，便于招标人在此基础上进行二次开发。开放标准API接口，数据库接口，相关程序接口。配合第三方软件接口开发.9、付款方式：签订供货合同预付30%，设备安装调试、新旧系统切换完成
后经双方联合验收合格，支付总货款的30%， 双方联合验收合格且系统稳定运行6个月后支付总货款的30%，系统稳定运行12个月后支付其余的10%。
综合评审办法
综合评分包括报价部分、商务部分和技术部分，各部分权值分配如下：
评分细则如下：(打分的最小单位为0.1分)
推荐阅读：
浅谈软件项目管理范文06-11
工程项目管理软件应用06-23
软件系统项目合同书06-30
税控软件项目可行性研究报告06-10
软件技术交流07-01
软件开发技术培训记录06-26
用友软件培训总结报告06-06
项目实习生培训方案06-06
合肥软件测试培训学校06-09
软件产品营销策划方案06-17
