医院医疗设备采购项目 HIS系统及硬件采购（三）
来源：广州软件开发 编辑：广州软件开发公司 日期：2018-08-22
5. 基础设施集成方案
5.1 概述
按照以往建设的模式，数据中心里的各系统不仅在逻辑上，而且在物理上也都处于独立分散的状态，每个业务系统都有自己独立的接入表现层、应用逻辑层和数据处理层。从规划的全局角度看，如果沿用这种思路和架构，它的局限性和消极方面都将逐渐体现出来，主要表现为：设备总体档次比较低，会购买大量中低端型号；设备利用率差，各系统间的资源无法根据应用情况灵活调整；设备绝对数量大，系统管理的负担太大；设备选型时风险高，比较容易出现所购设备或大或小的问题。
为了避免这些弊端，必须考虑新的IT硬件构架模式。事实证明，当信息系统发展到一定阶段后，IT系统的整合和优化是必然的方向。我们在设计系统平台架构时大量使用整合的概念和技术，综合考虑医疗信息系统的业务规划要求，强调系统结构的简洁性和灵活性。数据中心建设的主要目标可以概括为: 建设一种能在今后相当长的一段时间内，承担全院信息共享利用，同时提供服务的开放数据平台，为用户提供清晰、先进、可以灵活部署、具有易于扩展、易于管理特点的基础IT硬件平台。
5.2 产品选型清单
5.3 服务器及存储设备
根据对应用需求的分析，方案必须能保证系统具有可靠、故障恢复快捷以及长时间连续运行的能力，保证在各种条件下都能良好运行。同时应考虑项目建设的动态扩展能力，须提供硬件设备随业务增长的扩容方案。
5.3.1 选型原则
企业级计算性能
企业信息系统的工作内容大多是数据密集型操作，数据来源相当广泛，种类繁多，数据库和各类应用都面临着数据采集、数据集中、数据查询等数据密集型操作，同时还面临着OAP（联机分析处理）和建立决策支持数据仓库的需要，因此，服务器系统强劲的CPU数据处理能力和扩展能力就十分重要。
高度的可靠性和可用性
数据库和各类应用每天都面临着大量数据的收集和处理，服务器系统的冗余容错能力提供了高可靠性和可用性，再辅之高可用性方案设计，才可充分保证企业ERP信息系统工作的不间断进行。像服务器的冗余电源、内存镜像等设计都可以考虑。
极佳的稳定性
作为企业信息系统的支撑平台，需要保证服务器系统能持续、高效、稳定的运行，以减少对服务器系统的管理和维护的时间和工作量，以及计划外停机时间。稳定性依赖于软硬件的兼容性和各自的稳定性设计。
对数据的高保护性
不言而喻，对于数据就是生命的企业信息系统来讲，数据在服务器系统中进行计算、存储和网络传输时，其完整性、有效性是必须保证的。对于有机密要求的数据，还要保证数据的机密性。
良好的管理性
在企业信息系统中各种网络设备、计算机设备、安全设备种类繁多，这对整个系统的管理和控制提出了很大挑战。就服务器系统而言，专业服务器系统管理软件对服务器系统的集中和可视化管理，将使网络计算环境管理变得简单易行。
5.3.2 服务器
|
品牌型号 |
联想ThinkServer RQ940 D4820v2 16/300A2NRPOD |
数量 |
1台 |
|
类型 |
指标项目 |
指标 |
|
基本参数 |
产品类别 |
机架式 |
|
产品结构 |
4U |
|
处理器 |
CPU类型 |
Inte 至强E7-4800 v2 |
|
CPU型号 |
Xeon E7-4820 v2 |
|
CPU频率 |
2GHz |
|
智能加速主频 |
2.5GHz |
|
标配CPU数量 |
2颗 |
|
最大CPU数量 |
4颗 |
|
制程工艺 |
22nm |
|
三级缓存 |
16MB |
|
总线规格 |
QPI 7.2GT/s |
|
CPU核心 |
八核 |
|
CPU线程数 |
16线程 |
|
主板 |
扩展槽 |
I/O扩展槽双CPU：
1×PCIE 3.0 x16槽
3×PCIE 3.0 x8插槽
I/O扩展槽四CPU：
2×PCIE 3.0 x16槽
8×PCIE 3.0 x8插槽 |
|
内存 |
内存类型 |
DDR3 |
|
内存容量 |
16GB |
|
内存描述 |
2*8GB V-RDIMM DDR3 1600内存 |
|
最大内存容量 |
3TB |
|
存储 |
硬盘接口类型 |
SAS |
|
标配硬盘容量 |
300GB |
|
硬盘描述 |
标配2块300GB SAS热插拔2.5寸硬盘(1000转)，最大可拓展到14.4TB存储空间 |
|
热插拔盘位 |
支持热插拔 |
|
磁盘控制器 |
R700 |
|
RAID模式 |
RAID 0，1，5，6，10，50，60 |
|
光驱 |
DVD RW 光驱 |
|
网络 |
网络控制器 |
1个X540双口万兆Mezz卡 |
|
接口类型 |
标准接口 |
1×RJ45网口
7×USB 2.0接口（3个前置，2个内置，2个后置）
2×VGA接口
1×串口 |
|
管理及其它 |
系统支持 |
Windows Server 2012（包括Hyper-V）
Windows Server 2012 R2（包括Hyper-V）
Windows Server 2008 R2 SP1（包括Hyper-V）
Orace Soaris 11
SES 11.3
RedHat 6.4/6.5
RedHat KVM 5.8/5.9
VMware ESXi 5.1/5.5
Citrix XenServer 6.0 FP1 |
|
电源性能 |
电源类型 |
标配1+1 80PUS冗余白金电源 |
|
电源功率 |
1600W |
|
外观特征 |
产品尺寸 |
704×173.8×424mm |
|
适用环境 |
工作温度 |
10℃-35℃ |
|
工作湿度 |
10%-80% |
|
储存温度 |
40℃-60℃ |
|
|
|
|
|
|
|
5.3.3 存储设备
|
品牌型号 |
联想SureSAS112F(双控FC) |
数量 |
1台 |
|
类型 |
指标项目 |
指标 |
|
主要性能 |
平均传输率 |
3200MB/s |
|
硬盘转速 |
600GB、450GB、300GB 15krpm，2TB、1TB 7200rpm |
|
硬盘描述 |
2TB * 3 |
|
高速缓存 |
控制器缓存：4GB |
|
系统支持 |
Windows 2003/2008
RedHat 4/5
SuSE 9/10
Sun Soaris 9/10(SPARC) ，Sun Soaris 10(x86) |
|
外接主机通道 |
4个8Gb/s FC 接口 |
|
RAID支持 |
冗余双活双控，支持RAID0、1、3、5、6、10、50、60 |
|
内置硬盘接口 |
SAS，SATA |
|
处理器 |
每控制器1颗1.2GHz RISC存储专用处理器，整合XOR引擎 |
|
风扇 |
双冗余、热插拔 |
|
其它参数 |
UN数量：256
最大硬盘数量：96个
磁盘扩展：个6Gb Externa Mini SAS
产品重量：30.8Kg |
|
一般性能 |
产品电源 |
双冗余、热插拔，AC 100-240V，50/60Hz，436W |
|
长度 |
602mm |
|
宽度 |
447mm |
|
高度 |
89mm |
|
工作温度 |
5-40℃ |
|
工作湿度 |
10%-90%(非凝结环境) |
|
|
|
|
|
|
|
5.4 工作站终端设备
|
序号 |
名称 |
型号 |
参数 |
|
1 |
PC终端 |
联想启天 B4550 |
产品类型 ：商用台式机
操作系统 ：Windows 7 专业版
主板芯片组 ：Inte G61
CPU 系列 ：英特尔 赛扬双核
CPU 型号 ：Inte 赛扬双核 G1820
CPU 频率 ：2.7GHz
总线 ：DMI 5 GT/s
三级缓存 ：2MB
核心代号 ：Haswe
核心/线程数 ：双核心/双线程
制程工艺 ：22nm
内存容量 ：2GB
内存类型 ：DDR3 1333MHz
硬盘容量 ：500GB
光驱类型 ：DVD刻录机
显卡类型 ：集成显卡
显卡芯片 ：Inte GMA HD 4000
显存容量 ：共享内存容量
DirectX ：DirectX 11
音频系统 ：集成
显示器尺寸 ：19.5英寸
显示器描述 ：ED宽屏
有线网卡 ：1000Mbps以太网卡 |
6. 项目实施方案
6.1 定制开发
软件研发生命周期是指软件开发全部过程、活动和任务的结构框架。软件研发包括需求、设计、编码和测试等阶段，也包括运行维护阶段。本项目的软件研发过程中使用的各种生命周期模型，主要有以下几种：瀑布/改进瀑布模型、螺旋模型、增量迭代模型、原型法、快速和敏捷开发等。在本项目中建议采取增量迭代模型、原型法、快速和敏捷开发这三种主要方法作为定制开发的主要模型工具。
6.1.1 选择适合的生命周期模型
对于一个特定的软件研发项目，选择生命周期模型的原则是：
模型应符合项目本身的特点（规模和复杂性）；
模型应满足整体开发进度要求；
模型应有利于项目风险的控制；
模型要与项目组人员的知识技能匹配；
模型要有利于开发过程的管理与控制。
建议从以下角度考虑模型的选择：
在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型；
在用户无信息系统使用经验，需求分析人员技能不足情况下一定要借助原型；
在不确定性因素很多，很多因素事前无法确定或估计的情况下尽量采用增量迭代和螺旋模型；
在需求不稳定情况下尽量采用增量迭代模型；
对于多个完全独立功能开发可以在需求阶段就按照功能并行，但每个功能内都应该遵循瀑布模型；
对于全新系统的开发必须在总体设计完成后再开始增量或并行；
对于编码人员经验较少情况下，建议不要采用敏捷或迭代等生命周期模型；
增量迭代和原型可以综合使用，但每一次增量或迭代都必须有明确的交付和出口准则。
6.1.2 增量迭代模型
增量迭代是RUP统一过程常采用的软件开发生命周期模型。增量和迭代有区别但两者又经常一起使用。所以这里要先解释下增量和迭代的概念。假设现在要开发A、B、C、D四个大的业务功能，每个功能都需要开发两周的时间。则对于增量方法而言可以将四个功能分为两次增量来完成，第一个增量完成A、B功能，第二次增量完成C、D功能；而对于迭代开发来将则是分两次迭代来开发，第一次迭代完成A、B、C、D四个基本业务功能但不含复杂的业务逻辑，而第二个迭代再逐渐细化补充完整相关的业务逻辑。在第一个月过去后，采用增量开发的时候A、B全部开发完成而C、D还一点都没有动;而采用迭代开发的时候A、B、C、D四个的基础功能都已经完成。
RUP强调的每次迭代都包含了需求，设计和开发，测试等各个过程，而且每次迭代完成后都是一个可以交付的原型。迭代不是并行，在每次迭代过程中仍然要遵循需求à设计à开发的瀑布过程。迭代周期的长度跟项目的周期和规模有很大的关系。小型项目可以一周一次迭代，而对于大型项目则可以2~4周一次迭代。如果项目没有一个很好的架构师，很难规划出每次迭代的内容和要达到的目标，验证相关的交付和产出。因此迭代模型虽然能够很好的满足用户需求的变化，但确是一个很难真正用好的模型。
就对风险的消除上，增量和迭代模型都能够很好的控制前期的风险并解决。但迭代模型在这方面更有优势。迭代模型可以更多的从总体方面去系统性地思考问题，从最早就可以给出相对完善的框架或原型，后期的每次迭代都是针对上次迭代的逐步精化。
比较标准的增量模型往往要求在《系统需求规格说明书》全部出来后，再进行后续的设计开发。同时每个增量也可以是独立发布的小版本。由于系统的总体设计往往对一个系统的架构和可扩展性有重大的影响，因此我们推荐的增量最好是在架构设计完成后再开始进行增量，这样可以更好的保证系统的健壮性和可扩展性。
|
阶段 |
子阶段 |
主要工作 |
应完成的文档 |
检查重点 |
|
总体需求确定 |
|
总体需求分析 |
软件需求规格说明书 |
软件需求规格说明书的评审 |
|
总体架构设计 |
|
系统架构设计 |
系统架构设计 |
系统架构设计评审 |
|
迭代1 |
需求 |
确定当前迭代的交付成果和周期 |
当前迭代功能说明
当前迭代进度计划 |
交付成果可验证
周期可行性 |
|
设计 |
当前迭代的详细设计 |
当前迭代详细设计 |
详细设计评审 |
|
开发 |
当期迭代的程序开发 |
当前迭代代码 |
代码检查 |
|
测试 |
当期迭代的程序测试 |
当前迭代测试用例
当前迭代测试评价报告 |
测试设计和测试用例评审
迭代目标检查 |
|
交付 |
当期迭代的程序交付 |
当前迭代交付说明 |
交付反馈意见收集 |
迭代2
…… |
结合上一次迭代的反馈意见，根据总体需求和架构，确定后面迭代的交付成果和周期 |
变更控制情况 |
|
注：根据每一次迭代可以参考瀑布模型的阶段检查重点进行检查。 |
6.1.3 原型法
原型法一般都不是单独采用的一种生命周期模型，往往会结合瀑布和增量迭代等方法一起使用。对于螺旋模型就可以理解为瀑布+迭代+原型+风险的一种生命周期模型。对于迭代开发来讲，每一个迭代周期的产出都可以看作是下个阶段要精化的原型。而对于瀑布模型开发来讲，我们在需求阶段也可以进行界面和操作建模，形成DEMO后和用户做进一步的需求沟通和确认。
当用户没有信息系统的使用经验，系统分析员也没有过多的需求分析和挖掘经验的时候，需求分析和调研过程则更需要是一个启发式的过程。而原型则是这种很好的启发式方法，可以快速的挖掘用户需求并达成需求理解上的一致。否则即使双方都签字认可的需求往往仍然不是用户真正想要的东西。
原型可以分为抛弃型的和不抛弃型的。如果原型仅仅是需求阶段和用户沟通画的DEMO，则这种原型一般都建议抛弃掉。而对于迭代开发来将，每次迭代的产出都是可以独立运行和包含基础功能的系统，是后续细化的基础，这类原型一般都不建议抛弃，后期的设计开发也要基于该原型逐渐的进行完善。
6.1.4 快速和敏捷开发
我们一般将快速和敏捷开发作为方法论，而很少将其作为一种软件开发生命周期模型。敏捷的目的是减少繁重和不必要的输出，从而提高效率，而不是分析设计都还没有做就去做开发。因此对于瀑布，增量迭代或原型我们可以借鉴敏捷方法论中的一些好的实践，这些实践都是对传统的生命周期模型很好的补充。
6.1.5 瀑布/改进瀑布模型
瀑布模型将软件生命周期的各项活动规定为按固定顺序联接的若干阶段工作，形如瀑布流水，最终得到软件系统。如下图所示：
瀑布模型是最基本的和最有效的一种可供选择的软件开发生命周期模型。瀑布模型要求软件开发严格按照需求à分析à设计à编码à测试的阶段进行，每一个阶段都可以定义明确的工作成果和验证准则。瀑布模型在每一个阶段完成后都可以组织相关的评审和验证，只有在评审通过后才能够进入到下一个阶段。
由于需要对每一个阶段进行验证，瀑布模型要求每一个阶段都有明确的工作成果产出，对于严格的瀑布模型每一个阶段都不应该重叠，而应该是在评审通过，相关的工作成果都已经基线后才能够进入到下一个阶段。
瀑布模型的优点是可以保证整个软件系统较高的质量，保证缺陷能够提前被发现和解决。采用瀑布模型可以保证系统在整体上的充分把握，使系统具备良好的扩展性和可维护性。但对于前期需求不明确，而又很难短时间明确清楚的项目则很难很好的利用瀑布模型。另外对于中小型的项目，需求设计和开发人员往往在项目开始后就会全部投入到项目中，而不是分阶段投入，因此采用瀑布模型会导致项目人力资源过多的闲置的情况，这也是必须要考虑的问题。
项目经理往往会以进度约束而不选择瀑布模型，导致这种情况的一个关键因素是需求阶段人力不足。因此在需求阶段人力能够得到充分保证的情况下，瀑布模型和迭代模型在开发周期上并不会存在太大的差别。反而是很多项目对于迭代或敏捷模型用不好，为了赶进度在前期需求不明确，没有经过一个总体的架构设计情况下就开始编码，后期出现大量的返工而严重影响进度。
架构设计是软件开发中一个重要的关注点。在架构设计完成后系统会被分为相关的子系统和功能模块。每个功能模块间的接口都可以定义清楚。在这种情况下，当某个模块的详细设计完成后就没有必要等到其它模块的详细设计都要完全作完才开始编码，因此在架构设计完成后可以将系统分为多个模块并行开发，每个模块仍然遵循先设计和编码测试的瀑布模型思路。这是瀑布模型的一种最重要的改进思路，也可以说这是一种增量开发的模型。
当一个新系统的开发存在多个完全不相关的独立需求时，也可以选择将整个开发过程按独立的需求来分为多个小瀑布进行操作。这种方式的最大问题就是没有一个完全总体的设计，架构设计人员无法在洞悉了所有需求后从系统的可扩展性，复用等方面总体规划。
在项目管理中有一种压缩进度的方法叫赶工，因此改进瀑布模型就可以适当重叠各个阶段过程，达到资源的有效利用。比如可以提前开始下一个阶段的工作而不一定等到相关的文档完全出来。
表1瀑布/改进瀑布模型的阶段划分与检查重点
|
阶段 |
主要工作 |
应完成的文档 |
检查重点 |
|
需求分析 |
1.调研用户需求及用户环境
2.确定系统运行环境
3.建立系统逻辑模型
4.确定系统功能及性能要求
5.编写需求规格说明、系统使用说明书概要、测试计划
6.确认项目开发计划书 |
1.需求规格说明书
2.项目开发计划书
3.系统使用说明书系统使用说明书概要
4.测试计划 |
1.过程和成果的规范性
2.对已完成的成果进行评审 |
|
概要设计 |
1.建立系统总体结构，
划分功能模块
2.定义各功能模块接口
3.数据库设计
4.制定集成测试计划 |
1.概要设计书
2.数据库设计书
3．接口设计书
4.集成测试计划 |
1.过程和成果的规范性
2.对已完成的成果进行评审 |
|
详细设计 |
1.设计各模块具体实现算法
2.确定模块间详细接口
3.制定模块测试方案 |
1.详细设计书
2.模块测试计划 |
1.设计时采用的技术与工具
2.过程和成果的规范性
3.对已完成的成果进行评审 |
|
实现 |
1.编写程序源代码
2.进行模块测试和调试
3.编写系统使用说明书 |
1.程序调试报告
2.系统使用说明书 |
1.实现过程中采用的技术与工具
2.过程和成果的规范性
3.对实现过程及已完成的成果进行评审 |
|
集成测试 |
1.执行集成测试计划
2.编写集成测试报告 |
1.系统源程序清单
2.集成测试报告 |
1.测试时采用的技术和工具
2.过程和成果的规范性
3.对测试工作及已完成的成果进行评审 |
|
系统测试 |
1.测试整个软件系统
2.试用系统使用说明书
3.编写开发总结报告 |
1.确认测试报告
2.系统使用说明书
3.开发工作总结 |
6.2 实施团队
.
|
公司名称 |
AABBCC有限公司 |
|
项目组技术人员构成 |
|
姓名 |
职务 |
学历 |
从业年限 |
备注 |
|
胡玉波 |
项目经理 |
本科 |
10年以上 |
|
|
姚计军 |
技术经理 |
本科 |
10年以上 |
|
|
杜雷明 |
实施工程师 |
本科 |
10年以上 |
|
|
|
|
|
|
|
|
6.3 项目实施计划
公司将根据医院信息化建设项目的目标，提交项目实施计划，每个实施任务须符合总体项目计划和项目时间表。
6.3.1 项目实施的准备
项目的资源准备。
定义项目范围和队伍。
在项目实施前，和院方确定项目的细节。
6.3.2 实施进度安排
6.3.2.1 总体日程安排
根据本信息化项目建设目标，按照总体规划、分步实施的原则，公司建议划分3个工程实施阶段来完成市级卫生信息平台信息化建设项目的全面建设。
阶段一，需求分析及阶段：主要工作是通过建立流程优化及需求分析审核小组已确认需求；
阶段二，设计开发阶段：主要工作是根据需求分析结果对现有系统需改造开发的部分进行详细设计和代码编制，包括单元测试和功能测试；
阶段三，部署实施阶段：主要工作是按计划进行系统分阶段部署，并采取按流程测试和压力测试等方法确保系统稳定性，最终通过UAT测试完成实际部署准备，确认实际部署计划。
分阶段计划：前提条件为建设好基础网络与硬件环境。
项目要求：各模块完成最终客户化修改工作，客户化修改备忘录详实，分类、汇总数据保证准确。
6.3.2.2 总体进度安排
总体进度安排表如下：
|
工作任务 |
开始日期 |
结束日期 |
说明 |
|
项目启动 |
2014-10-08 |
2014-10-10 |
|
|
需求调研 |
2014-10-11 |
2014-10-17 |
|
|
基础设施采购 |
2014-10-08 |
2014-10-17 |
|
|
设备安装调试及验收 |
2014-10-20 |
2014-10-25 |
|
|
数据初始化 |
2014-10-20 |
2014-10-31 |
|
|
软件培训 |
2014-10-27 |
2014-11-07 |
集中培训后保留培训环境至系统上线，用户可继续组织日常的练习，以便进一步熟悉应用系统。 |
|
一阶段客户化开发 |
2014-11-03 |
2014-11-14 |
|
|
系统联调测试 |
2014-11-17 |
2014-11-21 |
|
|
模拟演练 |
2014-11-24 |
2014-11-28 |
|
|
二阶段客户化开发 |
2014-12-01 |
2014-12-12 |
|
|
系统初验 |
2014-12-15 |
2014-12-19 |
|
|
开业试运行 |
2014-12-22 |
2015-01-21 |
具体时间节点配合开院时间予以确定 |
|
系统终验 |
2015-01-22 |
2015-01-31 |
|
（注：实际进度根据项目启动时间节点顺延）
计划开标后开始各项工作。
我公司将保证以下关键节点
n 基础设施建设工程在2014年10月底交付验收；
n 2014年12月本项目所有系统上线试运行。
总体进度安排是一个动态的文档，公司将根据项目进展随时进行更新。
由于系统需要有与其他外部机构接口，可能由于来自其他方面约束，公司将根据需要调整其总体进度。
月进度表
月进度要显示上个月完成的进度和工作量，时间范围应以周为单位，并征求业主方和监理方（若有）的同意。进度跟踪和报告应用完成工作量的百分比来表示。
月进度表应与项目进度报告一起递交给业主方和监理方（若有）。
递交文件的审查
业主方和监理方（若有）将审查提供的进度安排和文件，在接到文件后的3个工作日内签署认可或提出评论意见。公司将在接到业主方和监理方（若有）的意见后3个工作日内回复业主方和监理方（若有）的意见。
如果需要进行进度修正，或经项目管理委员会同意，公司将根据项目状态对进度安排进行修改。
6.3.2.3 进度报告方式
公司定期举行项目进展报告会，内容包括（但不限于）如下：
每周向业主方项目负责人报告一次。
每月与公司中层负责人会面一次，并与主要用户会面交流一次。
与业主方的管理层就项目的重大步骤举行定期会商。
项目的进度的更新报告包括下列内容：
未完成的任务
在进度报告周期内未完成的任务
在未完成情况下，补救的措施及双方同意的更新的进度表
重要的成果和达到重要目标
项目人事变动
新旧成员交替
特殊事件
技术性的
系统和应用的
管理的改变
其他项目的主要风险
6.3.2.4 进度报告格式
公司将会按月给业主方一份进度报告，下面是建议的报告格式：
完成的工作 - 在报告月内完成的工作概述。
在进行中的工作 - 在报告月内概述在进行中还没被完成的工作。
将交付的成果 - 提供在报告月期间将要完成的交付成果。
已付出工作量 - 报告为运行支持和变更需求所消耗的工作量。
服务水平 - 按不同问题等级来统计所消耗工作量。
6.3.3 进度偏差控制
项目实施过程中出现进度偏差是在所难免的，实施进度控制就是要求能对偏差能进行有效的控制，提出相应的解决方案，使之有利于项目的进展。在多年的软件开发过程中，公司总结了一系列简单有效的偏差解决方法，详细见下表：
进度偏差解决方法表
|
方法 |
适用条件 |
缺点 |
|
增加资源 |
有可调用的资源，加入资源对项目进展有明显作用。 |
增加成本，加大沟通和任务安排上的难度，有时难以见效。 |
|
加班赶工 |
具有加班的条件。 |
增加成本，可能会降低资源的工作效率，引发副作用。 |
|
加速跟进 |
关键路径上的后继活动，受延期活动的影响不很大时。 |
可能会造成项目返工。 |
|
协调解决问题 |
由于协调原因或配合方的工作不力造成了任务延期。 |
只会对以后的工作起到作用，无法解决现有的延期问题，需要和其他方法结合来使用。 |
|
提高资源工作能力，改进资源工作方法 |
延期的原因是由于资源工作能力不足或工作方法不佳引起的。 |
可能效果不是立即见效。 |
|
调整进度计划，压缩后继的关键路径工作的工期 |
任务延期较严重，难以通过压缩该任务来追赶项目进度时。 |
对后继工作的控制和实施工作要求较高。 |
|
优化项目进度计划缩小项目范围、降低任务的要求 |
原先制定的项目进度计划不合理。
项目进度要求比范围和质量要求更高，缩小项目范围、
降低项目质量不会产生对项目后果较严重的影响。 |
对项目的整体工作可能会产生影响。
对项目的质量产生不良的影响。 |
在项目开发过程中，如果出现了进度偏差，按照“具体问题具体分析”的原则，针对这些偏差进行分析和研究，发现其中的问题，针对问题寻找最佳解决方案。然后根据偏差的处理决定，执行解决方案，调整项目进度计划。如果必要的话，通知项目领导小组。当进度偏差比较大时，需要考虑缩小检查周期，以便更好地监视并纠正措施的效果，以保障项目按期完成。
6.4 培训
我公司将在系统试运行前对招标人相关人员进行培训，使招标人全面掌握该系统的结构、功能、使用方法和系统日常维护。
招标人可以对投标人提出的培训方案进行选择和调整。
培训时间将至少在各系统上线前一周进行。
培训人数由甲方确定。
培训内容请参看下面两节。
培训方式包括：现场培训、远程培训等等。
培训课程名称包括：应用系统培训、常用计算机技能培训等。
我方将为招标人技术管理人员提供相关设备（服务器、存储系统、相关软件）的安装、使用、维护培训。
培训讲师：李向，我公司高级讲师，拥有３年培训经验。
n 我公司承诺根据《培训计划》的相关要求选派有相应专业的实际工作和教学经验的教师和相应的辅导人员来完成对所有硬件产品、随机系统、软件产品、系统集成等在内的全部免费培训，我公司编写并提供教材。
n 对于每次培训的具体内容、深度和时间安排，我公司事前提出具体培训方案，我公司不限制医院此类培训参加人数。
n 除培训计划外，在系统运行和质量保证期间若医院有培训要求，我公司应根据实际情况而协助医院完成相关培训。
n 培训的时间、内容、人员、班次等项内容在具体执行过程中医院可以进行调整，医院的培训调整需提前 3 日通报我公司，以方便我公司安排。
6.4.1 培训目的
通过对医院系统管理人员和操作人员进行全面的技术类和操作类培训，确保用户维护管理和操作人员达到能独立操作、独立进行管理、运营、故障处理、日常维护测试等工作，使供货商提供的相关设备与系统能够正常、安全的运行。
为此，我们将提供全程的人员培训计划，包括从项目启动阶段到项目结束整个过程的培训内容。具体的培训形式将采取：
（1）通过与用户联合进行软件本地化实施，进行用户现场的培训，以掌握软件开发的技巧和初步熟悉有关数据库、应用服务器软件的管理技巧；
（2）安排用户有关系统管理员到专门的数据库及应用服务器软件培训单位进行脱产培训，以深入掌握数据库等系统软件的管理技术。具体的内容将在后面详细说明。
6.4.2 培训策略
（1）培训内容先进性与实用性相结合；
（2）聘请专业的培训教师为学员授课；
（3）培训教材采用原厂商提供的中文教材，授课语言为中文；
（4）非现场培训做好接待工作，协调好相关的一切事宜；
（5）对学员从严要求，确保培训质量；
（6）建立培训反馈体系，由学员考评培训教师，确保培训质量。
6.4.3 培训内容
公司将采取现场培训和集中培训两种方式，组织下列培训：
|
序号 |
培训人群 |
培训内容 |
|
1 |
系统软件管理员培训 |
中标后尽快安排系统软件管理员的培训，主要为第三方厂商的认证培训，包括数据库管理、应用中间件管理等 |
|
2 |
软件的系统开发培训 |
有关人员在参加有关基础培训后，跟随软件开发进行进一步培训 |
|
3 |
软件的应用管理维护培训 |
软件的应用管理维护培训的时间计划原则为：尽可能安排在整个系统集成工作结束后，应用软件安装调试、试运行时进行。这样做的好处在于，学员在项目实施的过程中通过我们所做的现场培训，可以初步掌握系统的安装、管理和维护的知识和技能，可以更容易理解和领会具有更多理论基础要求和专业培训内容。 |
|
4 |
应用软件的使用培训 |
在有关应用软件开发基本完成时进行 |
6.4.4 培训方式
6.4.4.1 现场培训
1）项目启动初期系统技术、软件技术概念培训。
培训目的：在项目启动初期对用户方项目参与人员进行系统、软件等方面技术的初步介绍和交流，为进一步的深入技术培训打下基础。
培训内容：面向对象设计和开发技术：包括面向对象的分析与设计、编程与测试。
2）应用软件的管理维护培训
培训目的：对医院的有关的技术人员软件维护的培训，使受培训的人员能够独立掌握系统的应用管理维护技术，使之能适用网络系统正常运行的需求。
培训内容：系统的应用管理维护技术、网络管理技术等。
3）应用软件的系统开发用户培训
培训目的：对医院的有关的技术人员软件开发和维护的培训，使培训人员能独立完成软件的相应的修改和维护的工作。
培训内容：日常运行于维护，报表模板管理、门户内容管理、页面定制管理等。
4）应用软件的适用培训：
培训目的：在应用系统基本上线以后，对系统的实际操作人员进行详细的操作培训，德系统正式运行后顺利进行工作，以保证能做到对整个系统有清晰的理解和应变能力。
培训内容：
² 业务优化后的流程
² 管理优化后的流程
² 软件运行及维护
² 软件运行和维护中应注意的问题
² 实际操作练习
² 用户应用操作人员的培训
² 业务所需的相关计算机软硬件知识
² 应用软件系统技术原理
5）应用软件培训计划
应用软件的培训只要是根据《用户操作手册》进行流程及操作培训，这是系统安全运行的基础，也是项目实施的关键所在。医院目前已经使用了部分系统，各部门人员都能比较熟悉计算机了，这是一件好事情，但是其操作习惯在短时间内不容易改变的，这会对新的系统有所抵触的情绪，要想解决好这一问题有几点：
首先得明确的是新的系统将是配合医院新的管理实施的工具，业务流程及数据的正确性将是思想转变的基础。
其次是要系统本身操作简单；
细化培训工作；
强化考核
我公司将对医院进行系统的培训工作，包括项目实施工期中的所有系统，严格按照所列时间进行培训工作的开展，具体到每个子系统的培训工作将在今后的实施工作中提交，包括业务流程培训、用户操作手册等。
2.4.4.2 集中培训
为了保证用户能够顺利掌握我们所开发的软件，并能在将来针对业务需求的变化进行自我维护和二次开发调整，我们将采用与用户进行实际的数据库软件、应用服务器软件操作和配置管理，使系统管理人员能更直接和深入地理解和掌握所需要的系统管理技巧，为将来进行专职脱产培训打下坚实的基础。
具体内容如下：
1）对于系统管理员的用户现场培训
主要着重于系统的总体结构、各种设备、系统安装、应用软件开发技术等方面，使得系统管理员应能够在系统正式运行后接手所有的工作，以保证能做到对整个系统有清晰的理解和应变能力。
系统管理员培训目的在于：
² 全面掌握整个系统的设计思想、施工过程以及全部功能；
² 对于系统数据的及时、有序的整理维护；
² 保证系统正常的运行及正确的维护；
² 能够针对业务需求的变化进行二期软件开发。
2）对系统管理员其他培训
² 第三方培训：公司可以与专业培训机构联系，医院可以将部分重要系统管理人员送培训机构进行学习。
² 服务器操作系统培训课程：主要学习有效使用windowsNT/2000的基本技能，学习如何浏览和查找文件系统，操作文本文件，创建和修改文件权限，访问系统文件和目录等，还将学习如何管理客户机。
² 数据库系统操作和管理：主要通过现场的讲解和实际操作使系统管理员初步掌握SQ Sever的体系结构、硬件设置、逻辑数据库结构和物理数据库布局，SQ Sever进程的管理、多数据库的监控、回滚段的管理、数据库的调整、数据库的安全和审计，数据库的优化、备份和恢复过程，还有SQ Sever系统管理员的职责，SQ Sever的管理事项等。还将讲述数据库的安装过程及数据库常碰到的问题及解决办法。
² 开发工具培训教程：主要学习开发的基本技能及其他课程培训。
6.5 售后服务
为了更好地为医院提供专业的技术支持与软硬件服务，明确公司为贵院提供的服务内容与规范，本文特将公司客户服务与支持进行详细的分类。在这里，我们按照两种方式进行分类。
按服务内容进行分类，服务可分为信息化管理咨询服务、软件技术服务、网络硬件技术服务、人员培训服务、配套软件供应服务等。
按服务阶段进行分类，服务可分为售前服务、售中服务、售后服务等。
服务宗旨：一切以客户为中心
服务准则：真诚、快捷、有效、周到
服务目标：完美的服务质量；完整的服务架构；完善的服务体系；
服务标准：ISO9001国际服务质量体系标准，ITI，ISO20000
图 ITI方法论示意图
6.5.1 服务方式及内容
本项目应用系统从项目终验收之日起，我公司提供硬件设备免费维护三年，软件产品免费升级及维护三年，所开发系统免费维护二年。
保修期间的维护服务不收取任何额外费用，保修期后的服务双方另行协商，我公司可在投标文件中提出建议。
系统维护与支持的具体内容如下：
电话支持
我公司应对应用系统的运行、维护提供7x24的实时技术支持。
我公司应提供热线电话或Emai、传真等方式随时回答用户各种技术问题并在24小时内提出解决方案。
故障响应
7x24小时的实时故障响应。我公司必须在出现系统软件及应用软件等系统故障的2小时内给予响应，8小时内恢复运行。
远程技术支持
当系统出现故障，经用户许可后，我公司可以远程登录用户系统，进行故障分析、问题定位并提供解决方案。对系统进行的任何配置、数据改动及其它可能对系统和业务造成不良影响的操作，必需经用户确认后方可进行。
定期跟踪
项目验收完毕后，我公司需要定期电话、现场跟踪系统使用情况，听取意见和建议，及时分析系统存在的问题，并随时给予解决。必要时，我公司应派遣技术人员去现场解决存在的问题。
系统软件升级
我公司需要及时向用户通报系统软件升级情况，若用户需要对系统软件升级，我公司应提供升级版本和相应的支持服务。
现场服务
当系统运行环境出现严重故障，或因更换服务器等原因需要重新搭建系统，我公司应及时提供切实可行的建议，通过远程支持不能及时解决问题时，派技术支持人员在4小时内赶赴现场，协助用户完成故障排除、升级或迁移操作，对系统进行完整性检查并跟踪运行。
6.5.2 按内容进行服务
信息化管理咨询服务
信息化管理咨询是医疗信息化建设的前端和高端工作，它决定了医院优化后的管理模式、信息化建设的具体内容和范围，对于医院希望通过信息化建设来全面提升其医疗服务水平和经营管理水平有着十分重要的导航作用。
软件技术服务
软件技术服务主要是针对于为医院提供的数字化医院信息系统软件进行的，主要包括软件系统专业实施；软件系统常规运行维护；软件客户化；软件系统升级；专用接口定制等。
软件系统常规运行维护工作主要是在售中和售后进行的。一般情况下，公司向客户承诺在软件工程合同签订后一年内享受免费软件服务支持（具体情况见合同书关于售后期部分）。一年后按照人次或按照项目进行收费，也就是有偿的售后服务。内容主要指对已实施运行模块的错误修改调整和故障排除。服务方式分为现场支持服务，远程诊断维护、电话及传真咨询服务，电子邮件服务，互联网技术远程支持。公司将定期为客户进行软件系统的检修与调整。《公司与医院的软件服务合同书》中将阐述相关的内容。
由于医院规模、管理模式、周围环境、病人来源、建设历史等的差异，每个医院都有各自的特点与特色。在实施全数字化医院软件系统的过程中，公司公司已经根据客户的实际情况对软件模块做了针对性的调整。软件客户化不是指对现有模块的细微变化，指的是公司公司根据客户的实际情况为其定制模块的行为。这里所指的客户化要求也包括客户根据其使用公司公司提供的医院信息系统的具体情况提出功能扩充要求和由于客户要求与数字化医院信息系统的设计原则相背的情况下对现有模块进行地较大修改，即二次开发。客户化的工作量根据实际情况而定。
医院的业务单位是分布在住院部和门诊部的临床科室及医疗辅助科室，他们承担着医院大部分工作，并与其他职能科室如总务、设备、行政管理部门等发生着千丝万缕的联系。全数字化医院信息系统作为医院信息化建设的核心业务体系必然要与其他软件相结合。当客户要求得到有关医院信息系统和某应用软件的接口服务时，公司公司将为客户提供相应的技术支持，制作专用接口软件，如医保软件接口，财务软件接口；临床分系统软件；文献检索、查询软件；图书管理软件接口；办公自动化软件接口等。数据库良好的开放性和拓展性使得公司公司提供的全数字化医院软件可以与多种其他相关的软件系统实现无缝连接，实现数据流通、信息共享。
网络硬件技术服务
l 网络硬件技术服务主要是指公司公司为客户提供的计算机硬件方面的支持与服务，主要内容包括网络硬件专业方案设计及实施；网络硬件常规运行维护；网络硬件工程升级；网络硬件工程客户化；网络安全工程建设；网络硬件系统防雷技术；数据备份、恢复、存储与转换等技术。
经过详细地实地勘测，公司公司的网络集成工程师可以根据客户的实际情况向客户提供完整高效的网络硬件专业方案设计。公司公司专业工程师队伍的现场服务能够帮助客户建设稳定、有序的硬件环境。通过制定并实施切实可行的设计方案，节约了客户的物质资源，减轻了实施的工程量，提高了硬件工程的安全性、完整性、兼容性，并保留一定的可扩充性。良好的网络环境既把外部环境的有害干扰置于门外，又保证为软件系统顺利运行创造必要的硬件条件，还保留了对外进行信息流通道渠道。工程的主要内容包括UPS系统建设，交换机的设置；服务器及其配置的数据库、操作系统安装调试；导医系统的安装调试；局域网与广域网的接口及相关的Internet技术.
硬件设备供应商通过大量的技术投入不断实现硬件功能的快速提高，医院的硬件系统运行一段时间后，为了更好地满足医院大量数据处理、信息传递的要求，除了对软件进行相应的升级工作外，网络硬件也要更新换代。公司公司熟知客户的实际情况和业内硬件供应商的技术状况，专门为客户提供硬件系统升级的客户化方案，帮助客户优化资源，达到既节俭，又高效的目的。
可持续的人员培训服务
软件和硬件的实施工作与人员的培训是整个全数字化医院信息系统工程建设不可分裂的部分。优秀的培训服务可以使客户早日掌握医院信息系统的各种工作流程、维护手段、应急方法等，减少不必要的操作错误，简化工作步骤，缩短应用周期。主要的服务项目有计算机基础知识教程；全数字化医院信息系统管理员培训；全数字化医院信息系统操作员培训；系统培训；网络管理员培训；数据库管理员培训；专项技术培训如导医系统安装与调试等。 通过系统的、由浅入深的讲解，实地的操作训练，受训的人员均能达到预期的效果。
配套软件供应服务
全数字化医院信息系统的核心业务范围主要涉及临床科室及其相关的医技科室。业务科室又与其他职能科室发生着方方面面的联系。
公司公司已建立了自己的网站，在网上提供医卫行业的最新消息、政府政策法规、医疗科技的发展状况、医卫信息化建设的进程等信息。在档客户可以在网上直接享受会员服务，非在档客户（也就是潜在客户）也可获得免费信息支持。网站的内容会定期更新，服务范围会不断扩大。主要的服务有：网络医院、远程医疗、网上医学信息检索、网络生物数据库服务等。
6.5.3 按阶段进行服务
售前服务
售前服务主要是指公司的售前工程师根据客户提供的资料和实际勘测情况，根据医院的投资规划和远期发展情况，考虑用户最佳的性能/价格比为设计原则，定制符合医院发展特点的软硬件解决方案，供医院决策者优化对比选择。
合同签订前公司公司公司员工与医院客户接触的时期内都属于售前服务的有效期间。
包括有：医院咨询、产品和服务介绍、系统演示、方案设计等。
售中服务
软硬件工程合同签订后，公司公司的实施工程师和网络技术工程师为客户进行现场的工程建设。（包括：（此指软件）工程实施的组织建设、需求调研、模拟环境的搭建、初始化数据的准备、操作员培训、系统调试、试运行、正式运行、验收安排、软件客户化等。）。软件工程的售中服务期限指合同签订后至合同中规定的工程实施完毕并验收合格后。硬件工程按照合同规定的时限进行服务。
售后服务
售后服务的期间分为两段：软件工程实施完毕并验收合格后一年内，公司公司免费为客户进行软件运行的日常维护工作；软件工程实施完毕并验收合格后一年后，进入有偿的客户服务阶段。
服务内容包括：
１、系统故障排除
非人为因素、硬件因素、自然因素造成的系统故障排除。
2、软件的常规运行维护
模块的安装、调试、测试、维护。
报表的制作、修改、维护。
合乎公司产品发展方向的客户化需求的修改。
3、版本升级服务
合同范围内模块的版本升级服务以及技术培训。
相关阅读
广州软件开发公司业务咨询卢先生 手机18998818351 售后服务热线：020-22076940