《IT项目管理课程设计-医院电子病历管理系统要点.pdf》由会员分享，可在线阅读，更多相关《IT项目管理课程设计-医院电子病历管理系统要点.pdf（16页珍藏版）》请在三一文库上搜索。
1、课程设计报告 课程名称IT项目管理课程设计 姓名 院（系） 专业班级 学号 指导教师 医院电子病历管理系统开发项目 目录 一需求分析. 3 1. 背景 3 2. 功能需求 3 3. 建设目标 3 二项目计划. 3 1. 项目范围管理. 3 2. 人员配置计划. 6 3. 项目实施计划. 9 三.风险计划 13 1. 风险识别 , 评估与风险规划. 13 2. 风险分析表 . 14 3. 风险应对措施. 16 一需求分析 1. 背景 信息技术推动者社会的进步， 已经给人们的生活带来革命性的变化。随着现 代科学技术的迅猛发展， 计算机技术已经渗透到各个领域，其强大的功能已经被 人们深刻认识，它已经
2、进入了人类社会的各个领域并发挥着越来越重要的作用， 特别是 Internet 技术的推广和信息高速公路的建立， 使 IT 产业在市场竞争中越发 显示出其独特的优势。 步入信息化时代，有巨大的数据信息等待加工处理和传输， 这使得对数据的进一步掌控和利用显得尤为迫切。目的国内外的医疗部门正 在积极地参加到这场变化中来。 我国多家医院已经建立起医疗信息系统。该系统 正在全国逐步推广。 传统的病历模式也受到了现代信息技术的挑战，记载病历的 新载体电子病历电子病历也应运而生。 2. 功能需求 医院电子病历管理系统主要用于医院的信息管理，总体任务是实现病历信息 关系的系统化、 科学化、规范化和自动化， 其
3、主要任务是用计算机对医院病历的 各种信息进行日常管理，如查询、修改、增加、删除，针对这些要求设计了医院 电子病历管理系统。 推行医院电子病历管理系统的应用是进一步推进医院病历管 理规范化、电子化的重要举措。 3. 建设目标 项目建设目标主要从本项目的建设成果、项目的工期要求以及项目投资目标 三方面来说明。 项目成果：交付使用一个医院电子病历管理系统软件，能实现利用计算机对 医院病历信息进行管理， 满足对医院病历的各种信息进行日常管理，如查询、修 改、增加、删除等功能。 工期要求：本项目从2016 年 6 月 14 日开始立项，要求在2016 年 8 月中旬 投入运行。 项目投资：项目投资要求控
4、制在5 万人民币以内。 二项目计划 1. 项目范围管理 （1）生存期模式 针对本项目的开发特点， 参考企业的生存期模型说明和软件过程体系，决定 采用增量模型，理由如下： 医院电子病历管理系统可以先基于通用功能作出一个最小的使用版本，再逐 步添加其他的功能。 这样一来， 用户可以先试用最小版本的同时，提出更多明确 的需求，这有助于下一阶段的开发，大大减小了开发的风险。 在医院电子病历管理系统中， 要求系统有可扩充性， 若使用增量模型， 可以 保证系统的可扩充性。用户明确了需求的大部分，但是也会存在不详尽的地方， 只有等到一个可用的产品出来，通过用户使用， 然后进行评估， 评估结果作为下 一个增量
5、的开发计划， 下一个增量发布一些新增的功能和特性，直至产生最终完 善的产品。 “系统要求有可扩充性， 可以在现有系统的基础上， 通过前台就可加挂其他 功能模块”也说明用户可能会增加新的需求。 从最基础的做起， 逐步扩充其应用， 所以选择增量模型来开发学生信息管理 系统。 （2）工作任务分解 当解决问题过于复杂时， 可以将问题进行分解， 直到分解后的子问题容易解 决，然后分别解决这些子问题。规划项目时，也应该从任务分解开始，将一个项 目分解为更多的工作细目或子项目，使项目变得更小、更易管理、更易操作。这 样可以提高估算成本、 时间和资源的准确性。 使工作变得更易操作， 责任分工更 加明确。完成项
6、目本身是一个复杂的过程，必须采取分解的手段把主要的可交付 成果分成更容易管理的单元才能一目了然，最终得出项目的分解结构（WBS ） 。 1）任务分解的原则 1.将主体目标逐步细化分解，最底层的日常活动可直接分派到个人去完成； 2.每个任务原则上要求分解到不能再细分为止； 3.日常活动要对应到人、时间和资金投入。 2）任务分解的方法 1.采用树状结构进行分解； 2.以团队为中心，自上而下与自下而上的充分沟通，一对一个别交流与讨论， 分解单项工作。 3）任务分解的标准 1.分解后的活动结构清晰，从树根到树叶，一目了然，尽量避免盘根错节； 2.逻辑上形成一个大的活动，集成了所有的关键因素包含临时的里
7、程碑和监 控点，所有活动全部定义清楚，要细化到人、时间和资金投入。 医院电子病历管理系统开发的工作分解结构如图所示。 2. 人员配置计划 项目团队组建的工作流程如图2.2 所示。 项目组管理采用自上而下的负责方式：项目组成员向项目负责人负责， 项目 负责人向项目领导小组负责。 这种方式清晰地定义了各个运作层面的职责，便于 项目管理、控制，提高项目管理的力度和效率。 项目组织结构如图2.3 所示。 项目组成立 研究项目（总）负责人以及专 业负责人 确定内外部接口人 确定项目组成员 项目组成员报备 项目启动会 项目组成立收尾 图 2.2 项目组建的工作流程 领导小组 项目负责人 软 件 开 发 负
8、 责 人 资 源 管 理 负 责 人 质 量 评 审 负 责 人 图 2.3 组织结构示意图 参与项目各方的责任一般通过责任分配矩阵的形式进行表达，这种表达形式 的优点是直观地将项目责任方的责任和权利完整地表达出来，便于项目各方进行 有效的协调， 对项目的成功实施非常关键。 根据组织结构确定的项目责任分配矩 阵，责任矩阵如表2.1 所示。 表 2.1 责任矩阵 WBS 软件开 发部 资源管 理部 质量评 审部 领 导组 软 件 规 划 项目规划F C P 计划评审C F 需 求 分 析 用户界面设计F C 用户需求评审C F 修改需求、用户界面F C 编写需求规格说明C F 需求验证C C F
9、 项 目 设 计 概要设计F C 数据库 ER图编制、建库F C 设计评审C F 项 目 实 施 用 户 登 陆 管理员登录F C P 病案管理员登录F 医生登录C F 病人登录C F C 病 病案的形成管 理 病案信息 录入 F C 病案编目F 病案信息C F 注：F：负责； C：参与； P：批准。 案 管 理 维护 病案质控F 病案借阅管理病案预约C F 病案借阅F C 医生授权 管理 F 病 案 的 开 发 利 用管理 病案检索C F 治疗方法 优化 F 病案统计C F 系 统 集 成 系统集成测试F C 环境测试F 测试总结C F 提 交 验收测试F 产品提交C F 3. 项目实施计划
10、 （1） 项目进度计划 1）甘特图 项目进度甘特图如图2.4 所示 图 2.4 项目进度甘特图 2. 网络图 项目进度网络图如图2.5 所示。 表 2.2 项目资源表 2. 人力资源计划 项目人力资源计划如表2.3 所示。 表 2.3 项目人力资源计划表 (3) 成本计划 项目成本预算如表2.4 所示。 表 2.4 成本预算表 (4) 质量计划 1质量目标 整体创优良是项目的质量目标。 2. 质量保证计划 质量管理范围如下： （1）软件设计应符合设计规范及用户的要求。 （2）服务及设备采购应符合项目需求，资质和质量符合国家标准和建设单位 的要求。 （3）项目研发应符合公司需求。 （4）软件的集
11、成和交付符合要求。 质量管理方法和手段采用PDCA 循环方法，即每一个工序事先均应制定切实 可行的实施计划， 并认真按照计划和相关技术标准的要求实施，通过定期质量检 查，即使发现问题，及时采取措施纠正，持续改进质量，确保整体质量处于受控 的状态。 管理的结果是整体优良的交付物、完整的质量管理报告。 三.风险计划 项目风险管理是指通过风险识别、风险分析和风险评价去认识项目的风险， 并以此为基础合理地使用各种风险应对措施、管理方法技术和手段， 对项目的风 险实行有效的控制， 妥善的处理风险事件造成的不利后果，以最少的成本保证项 目总体目标实现的管理工作。 1. 风险识别 , 评估与风险规划 （1）
12、 风险识别 风险识别是理解某特定项目有哪些可能令人满意的结果的过程。就是采用系 统化的方法，识别某特定项目已知的和可预测的风险。 （2）风险评估 风险评估（ Risk Assessment） 是指，在风险事件发生之前或之后（但还没有结 束） ，该事件给人们的生活、生命、财产等各个方面造成的影响和损失的可能性 进行量化评估的工作。 即，风险评估就是量化测评某一事件或事物带来的影响或 损失的可能程度。 （3）风险规划 针对风险分析的结果，为提高实现项目目标的机会，降低风险的负面影响而 制定风险应对策略和应对措施的过程，即制定一定的行动和策略来对付、减少、 以至于消灭风险事件。通常采取的措施有 1.
13、 回避风险。 2. 转移风险。 3. 损失控制。 4. 自留风险。 2. 风险分析表 根据风险识别，风险评估，风险规划可以制定了如下风险分析表 排序输入风险事件可能性影响风险值风险应对措施 1 最终用户 抵制该系 统 投 资 方 可 能 会 由 于 某 个 细 节 的 问 题 对 整 个 系 统 产生反感。 80% 70% 40% 1. 尽力满足用户 提出的需求。 2. 界面尽可能的 美观，方便。 3. 需求分析阶段 派出专门的系统 分析员去了解用 户的性格，爱好， 工作习惯。 2 项 目期 间，投资 方举棋不 定 网 上 购 物 系 统众多，投资 方 浏 览 后 可 能 会 经 常 要 求更
14、改需求 60% 70% 40% 1. 软件详细设计 阶段注意增加软 件的可重用性。 提高复用水平。 2. 沟通和协调。 3 客户的需 求规格说 明 需求不明确， 增加需求，导 致需求蔓延， 由 于 本 软 件 是 不 太 了 解 计 算 机 的 用 户使用，变更 需 求 可 能 性 很大。 70% 50% 35% 1. 采取加班的方 法。 2. 修改计划去掉 一些任务。 3. 与客户商量延 长一些时间。 4. 当出现影响重 大的变更需求时 与客户协调，这 个版本的不做改 动，在下一个版 本中进行功能的 提升。 4 合同带来 的限制 进度要求紧， 合 同 金 额 有 限。 30% 50% 15%
15、 可以请一些实习 的学生做辅助工 作 , 一来 成本不 高 , 二来 可以加 快进度。 5 交付期限 紧缩。 需 方 存 在 紧 缩 交 付 期 限 的可能。导致 项目吃紧。 20% 60% 10% 1. 加班。 2. 临 时 雇 佣 员 工。 3. 调整结构。 6 历史项目 信息。 开 发 人 员 的 流动。 15% 60% 9% 1. 注意项目团队 的沟通，及时了 解开发人员的动 态。 2. 控制好项目过 程中的文档。 3. 从其他的项目 组借调人员。 4. 从外部招聘有 过此类开发经验 员。 7 人员缺乏 经验。 由 于 本 项 目 中 的 一 些 员 工 是 刚 刚 招 聘来的，可能
16、会缺乏经验。 15% 30% 10% 1. 采取一帮一， 让有经验的程序 员带着相对经验 少的程序员进行 开发。 2. 开发之前适当 的培训。 8 用户数量 超 出计 由 于 该 网 站 可 能 销 售 商 20% 20% 20% 1. 防患于未然， 数据库上采用数 据池的技术在， 划。品特别，导致 访问激增。 增 加 并 发 访 问 量。 9 技术达不 到预期效 果。 可 能 有 一 些 技 术 达 不 到 预期的效果， 不 能 使 需 方 满意。如访问 速度，一些特 效等等。 10% 10% 10% 1. 找懂得这种技 术的人帮忙。 2. 向老师请教。 表 12 3. 风险应对措施 （1）
17、风险规避 风险规避是改变项目计划来消除特定风险事件的威胁。通常情况下我们可 以采用多种方法来规避风险。例如，对于软件项目开发过程中存在的技术风险， 我们可以采用成熟的技术， 团队成员熟悉的技术或迭代式的开发过程等方法来规 避风险 ; 对于项目管理风险我们可以采用成熟的项目管理方法和策略来规避不成 熟的项目管理带来的风险; 对于进度风险我们可以采用增量式的开发来规避项目 或产品延迟上市的风险。 对于软件项目需求不确定的风险我们可以采用的原型法 来规避风险。 （2）风险转移 风险转移是转移风险的后果给第三方，通过合同的约定， 由保证策略或者供应商 担保。可以采用外包的形式来转移软件开发的风险，例如
18、发包方面对一个完全陌 生领域的项目可以采用外包来完成， 发包方必须有明确的合同约定来保证承包方 对软件的质量，进度以及维护的保证。否则风险转移很难取得成功。 （3）风险减轻 风险减轻是减少不利的风险事件的后果和可能性到一个可以接受的范围。通常在 项目的早期采取风险减轻策略可以收到更好的效果。例如，软件开发过程中人员 流失对于软件项目的影响非常严重，我们可以通过完善工件， 配备后备人员等方 法来减轻人员流失带来的影响。 （4）风险接受 准备应对风险事件， 包括积极的开发应急计划， 或者消极的接受风险的后果。对 于不可预见的风险，例如不可抗力; 或者在风险规避，风险转移或者风险减轻不 可行，或者上述活动执行成本超过接受风险的情况下采用。