Posted on 2026-04-04 Word count in article: 5k Reading time ≈ 18 mins.

INFO5990 Week 6 Tutorial Summary

Overview

Week 6 的 tutorial 重点围绕两个核心内容： 1. 可信信息（credible information） 在 IT 项目中的作用 2. 项目估算（estimation） 方法的选择与应用

Tutorial 通过概念检查（Concept Check）和一个 healthcare 案例（MediCare Solutions EHR 项目）来练习 DIKW 层次模型、信息验证方法，并要求学生对项目的规模、工作量、资源、时间和成本进行估算。

Objectives

本次 tutorial 的目标是帮助学生： - 理解可信信息在 IT 项目中的重要性，并将 DIKW 层次模型应用于真实场景 - 了解统计学在 IT 研究中的重要性，实践研究方法以识别可靠来源 - 通过 MediCare Solutions EHR 案例，应用五步估算流程 - 评估不同情境下适合的估算方法

Learning Outcomes

完成本次 tutorial 后，学生应能够： - LO2 — 理解与软件测试、数据安全、数据质量和质量保证相关的 IT 行业问题，并学习使用 IT 项目管理方法解决这些问题 - LO4 — 了解 IT 在不同行业中的应用，并评估信息技术对全球化世界中个人和组织的影响 - LO6 — 应用研究方法、模型和工具分析 IT 专业实践，识别和批判变化中的信息，并判断结果的潜在有效性

Part A — Concept Check

Q1: Why is information considered the "fuel" of IT projects?

信息是 IT 项目每个阶段决策的指导。没有准确的信息，项目经理无法定义范围、分配资源或评估风险。

举例： 了解系统需求、用户期望和技术限制，才能高效地执行项目。信息在 IT 项目中的角色类似于燃料——驱动从规划到实施的所有活动。

以社交媒体数据为例：

层次	社交媒体示例
Data（数据）	社交媒体平台上的原始用户活动日志
Information（信息）	经处理的数据，显示每日活跃用户数和每次会话时长
Knowledge（知识）	通过分析趋势，识别出用户使用高峰时段和参与模式
Wisdom（智慧）	利用洞察做出战略决策，如优化 App 推送通知时间或服务器负载均衡，以改善用户体验

DIKW 层次模型说明了数据如何逐步转化为有价值的决策依据。

Q3: Why are statistics important when conducting IT research?

统计学能够对大量数据进行总结和解释，识别模式、趋势和异常。

描述性统计（均值、中位数、方差）帮助理解系统性能或用户行为
推断性统计能够进行预测和假设检验，例如评估新功能是否提高了用户参与度

举例： 在系统负载测试中，统计数据能显示响应时间的分布和瓶颈；在客户调查中，统计数据能量化用户满意度和需求优先级。

Part B — Case Study: MediCare Solutions EHR Project

MediCare Solutions 是一家中型医疗公司，计划开发一套 Electronic Health Record (EHR) 电子健康档案系统，系统需包含： - 患者档案存储（结构化 + 非结构化数据） - 预约挂号管理 - 账单系统集成 - 患者端移动应用

项目经理需要估算项目规模（size）、工作量（effort）、资源（resources）、持续时间（duration）和成本（cost），同时必须确保用于决策的信息是可信的，并采用合适的研究和估算方法。

Q1: Apply the DIKW model to the healthcare data in this project.

DIKW 层次模型代表 Data（数据）、Information（信息）、Knowledge（知识）、Wisdom（智慧），它说明了原始数据如何转化为有用的决策支持。

Data（数据）

数据是尚未经过处理或解释的原始事实。在本案例中，数据包括： - 原始患者病历记录（未整理的笔记、检查结果、病史） - 预约日志（日期、时间、医生、患者姓名等——没有任何汇总） - 账单条目（金额、支付状态代码等——尚未分组或分析）

数据本身只是事件的记录，尚不足以支持决策。

Information（信息）

信息是经过整理、处理和呈现的数据。在本案例中，信息包括： - 每周各部门患者就诊次数报告 - 预约未到率按月统计 - 各类别欠款账单汇总 - 各预约类型的平均等待时间

到这个层次，团队已经能够了解组织的运营状况，例如哪些部门患者量最大，或哪些账单项延迟最多。

Knowledge（知识）

知识是经过分析后，从信息中发现的模式、原因和关系。在本案例中，知识包括： - 发现预约高峰时段是工作日上午 9 点至 11 点 - 识别出某些医疗程序的延误反复出现，与设备调度有关 - 发现欠款延迟最常出现在无保险患者中 - 观察到节假日前预约取消率上升

到这个层次，组织不仅知道"发生了什么"，还理解"为什么会发生"。

Wisdom（智慧）

智慧是将知识应用于做出更好的战略性决策。在本案例中，智慧包括： - 根据就诊高峰重新设计预约排班系统，均衡分配患者量 - 提前调配人员或设备到经常出现瓶颈的部门 - 针对欠款问题实施有针对性的跟进流程，减少应收账款 - 根据就诊频率和手术结果的规律，改善患者护理路径

到这个层次，数据不再是孤立的数字，而是被主动用来创造更好的患者体验和组织效益。

总结表

层次	在本案例中的对应内容
Data	原始患者病历、预约日志、账单记录
Information	就诊周报、账单汇总表、等待时间统计
Knowledge	高峰预约规律、常见延误原因、账单错误趋势
Wisdom	优化排班、合理人员配置、改善患者护理

DIKW 模型说明：数据本身不等于价值，必须经过整理、理解、分析，才能成为真正有用的决策依据。

Q2: Identify 2 primary research and 2 secondary research sources relevant here.

初级研究来源（Primary Research Sources）

1. 对医院工作人员和临床医生的访谈/问卷 通过对 MediCare Solutions 的医生、护士和行政人员进行访谈或问卷调查，直接获取关于当前患者档案管理方式、预约痛点和账单工作流程的第一手见解。这是初级研究，因为数据是为特定目的直接从来源处收集的。主要优势是能够捕捉到任何文档都无法替代的真实情境经验。局限性在于访谈耗时较长，样本量可能有限。

2. 对患者交互和预约处理流程的观察 直接观察患者在预约、登记、就诊和结算过程中的实际流程，以了解现有系统的使用情况和痛点。这是初级研究，因为数据是通过直接观察一手收集的。优势是能够发现访谈中可能遗漏的隐性问题。局限性在于观察范围有限，且可能存在霍桑效应（被观察者改变行为）。

次级研究来源（Secondary Research Sources）

1. EHR 实施行业报告（如 HIMSS 报告、政府卫生 IT 报告等） 已发布的报告、白皮书和市场研究，涵盖电子健康档案的采用率、实施标准、成本、失败率和最佳实践。这是次级研究，因为数据是由他人为更广泛的目的而收集的。优势是提供来自大样本的结构化、可信基准数据。局限性在于发现结果可能无法完全匹配 MediCare Solutions 的具体情境。

2. 关于医疗 IT 实施的学术文献和案例研究 经同行评审的期刊文章和会议论文，研究医疗 IT 项目规划、估算方法论及实际实施案例。这是次级研究，因为它基于现有研究而非新的数据收集。优势是发现结果经同行评审，总体可靠。局限性在于学术研究可能使用专业术语，不一定能直接转化为实际项目行动。

总结表

类型	来源	为什么相关
初级研究	对医院工作人员和临床医生的访谈/问卷	直接获取当前工作流程和痛点的第一手信息
初级研究	对患者交互和预约流程的观察	直接发现现有系统的使用问题
次级研究	行业 EHR 报告（如 HIMSS、政府卫生 IT 出版物）	提供采用率、成本和实施挑战的基准数据
次级研究	医疗 IT 实施的学术文献和案例研究	提供循证方法论和案例研究结果

Q3: Why is credible and referenced information especially critical for healthcare IT projects?

可信且有据可查的信息在医疗 IT 项目中尤其关键，原因有三：

1. 法规合规要求（Regulatory Compliance） 医疗 IT 系统必须遵守严格的法规，如 HIPAA（美国）、GDPR（欧洲）以及当地的医疗数据保护法律。系统设计和实施中使用的信息如果不可靠，可能导致合规失败，进而面临法律处罚和声誉损害。

2. 患者安全风险（Patient Safety） 医疗系统中的错误可能直接影响患者安全。如果项目决策基于不准确或未经验证的信息——例如错误的数据格式假设或不完整的工作流程理解——可能导致系统在关键场景下出错。使用经过验证的、有参考来源的信息可以降低这种风险。

3. 系统设计与决策的可靠性（Reliable Decision-Making） 项目经理在进行需求分析、系统设计、测试规划和成本估算时，都依赖于信息的质量。可信的信息来源（如行业标准、经同行评审的研究、直接的用户调研）能为这些决策提供可靠的输入，确保系统满足实际需求而非建立在假设之上。

Q4: Using the 5 steps of estimation, make a rough plan for the MediCare Solutions EHR project.

估算五步法为项目规划提供了一个结构化、渐进的方法。

第一步 — 分解项目（Decompose the Project）

将项目拆分为更小、可管理的组成部分。

MediCare Solutions EHR 项目可分解为四大功能模块： 1. 患者档案存储系统 — 结构和非结构化数据的存储、检索与安全 2. 预约挂号管理系统 — 预约、取消、提醒和日程管理 3. 账单系统集成 — 支付处理、开票和保险理赔 4. 患者端移动应用 — 患者访问病历、预约挂号和查看账单的界面

此外还有贯穿各模块的横向工作： - 数据从现有系统迁移 - 安全与隐私合规设置 - 系统集成测试 - 用户验收测试（UAT） - 培训与文档编写

将项目分解为这些模块，能让估算更易于管理，并降低遗漏重要范围的风险。

第二步 — 估算规模（Estimate Size）

使用适当的规模估算技术来衡量项目的整体规模。

对于本项目，功能点估算（Function Point Estimation） 是最适用的规模衡量技术：

模块	估算功能点数（示意）
患者档案存储	35–45 FP
预约挂号管理	25–35 FP
账单系统集成	30–40 FP
患者端移动应用	20–30 FP
估算总规模	约 110–150 FP

注：以上为 tutorial 示意数据。正式功能点统计需要项目经理和关键相关方共同参与。

第三步 — 估算工作量（Estimate Effort）

将规模估算转化为工作量估算（人月或人工日）。

使用医疗 IT 环境的大致生产率（考虑复杂性、测试和合规要求，每功能点约 6–8 人工日）：

总估算工作量 = 110–150 FP × 6–8 人日/FP
≈ 660–1,200 人日
≈ 30–55 人月（按每月 22 工作日计）

第四步 — 估算工期（Estimate Duration）

根据工作量估算和可用资源，计算项目需要的时间。

假设团队规模约 6 人：

总工作量：30–55 人月
团队规模：6 人
估算工期 ≈ 30–55 ÷ 6 ≈ 约 5–9 个月

关键调整：某些任务（如测试、合规审查和 UAT）将与开发并行推进，从而缩短总日历时间。

第五步 — 估算成本（Estimate Cost）

将成本费率应用于工作量估算，得出项目总成本。

基于 tutorial sheet 给出的费率： - 开发人员费率：$8,000/人/月 - 测试人员费率：$6,000/人/月

假设团队构成为 4 名开发人员和 2 名测试人员，工期 7 个月： - 开发人员成本：4 × $8,000 × 7 = $224,000 - 测试人员成本：2 × $6,000 × 7 = $84,000 - 项目管理成本（约直接成本的 15%）：约 $46,000 - 基础设施、许可和应急储备（约 15–20%）：约 $50,000–$70,000

指示性项目总成本：约 AUD 40 万至 50 万

五步法总结表

步骤	说明	MediCare Solutions EHR 示例
第一步：分解项目	拆分为模块	4 个功能模块 + 横向工作
第二步：估算规模	衡量整体大小	约 110–150 功能点
第三步：估算工作量	转化为人工月	约 30–55 人月
第四步：估算工期	计算日历时间	约 5–9 个月
第五步：估算成本	应用费率得出总成本	约 AUD 40 万–50 万

实践中的重要说明

估算应不断修订 — 随着更多信息浮出水面（如数据迁移评估或合规审查结果），每个步骤都应重新审视和调整
应包括风险和应急储备 — 医疗 IT 项目风险较高，通常需要在最终成本估算上增加 15–25% 的应急缓冲
相关方对齐至关重要 — 估算应与关键相关方（包括管理层和临床代表）共同审查，确保在承诺前有共同的预期

Q5: Which estimation approach seems best for this case, and why?

最适合 MediCare Solutions EHR 项目的估算方法是 功能点估算法（Function Point Estimation）与专家判断（Expert Judgement）的结合。

功能点估算法为什么适合

项目需求已明确界定：患者档案存储、预约管理、账单集成、移动应用，每一项都可以作为独立的功能模块来处理
功能点方法根据系统应交付的功能来衡量规模，而非低级别的代码行数，提供了一个结构化、可重复的估算基础
允许项目经理通过计数输入、输出、查询、内部逻辑文件和外部接口文件来估算系统整体规模
便于与类似项目进行对比，支持后续估算的持续优化

专家判断为什么必要

医疗 IT 项目涉及诸多难以用公式衡量的复杂性：患者数据隐私要求、现有医院系统集成、监管合规需求、高可靠性和低错误容忍度
有类似医疗项目经验的项目经理或高级工程师，能够根据实践经验对功能点估算进行调整，反映这些现实因素
专家判断也有助于识别风险，如监管审批延迟或数据迁移困难，这些在纯功能点计算中不会出现

与其他方法的比较

类比估算法（Analogy）：将当前项目与类似过往项目进行对比。如果参考项目与当前项目差异较大，误差会很明显。在医疗领域尤其如此，因为没有两家医疗机构拥有完全相同的系统、法规和集成需求
经验模型（Empirical models，如 COCOMO 或 SEER-SEM）：使用历史项目数据和统计关系来估算成本和工期。这些模型在组织拥有充分、可靠的历史数据时最准确；在 tutorial 案例场景中通常不具备这样的数据基础

工期估算

预计工期：约 6 至 9 个月

EHR 系统包含四大主要功能模块，每个模块的复杂度从中到高不等
医疗系统需要全面的测试、数据迁移规划、隐私和安全控制、合规审查
假设一个 5–8 人的全职团队（包括开发人员、测试人员、项目经理和业务分析师），6–9 个月是一个合理的高层初始估算
估算应通过功能点分析结合专家意见进一步细化

成本估算

预计成本：约 AUD 48 万至 78 万

开发人员费率：每人每月 $8,000
测试人员费率：每人每月 $6,000
团队规模约 5–8 人，工期 6–9 个月

简单计算示例： - 6 名开发人员 × $8,000/月 × 7 个月 = $336,000 - 3 名测试人员 × $6,000/月 × 7 个月 = $126,000 - 额外成本（项目管理、合规审查、基础设施）：约 $100,000 至 $150,000 - 指示性总成本：约 $560,000 至 $780,000

注意：以上仅为高层指示性估算。详细成本估算需要完整的功能点分解、人员配置计划和风险调整应急储备。

医疗 IT 项目估算的关键要点

复杂性高于一般企业项目 — 医疗系统必须处理敏感个人数据、遵守隐私法规、与现有临床系统集成，并满足高可靠性标准
测试工作量显著 — 医疗 IT 系统的故障可能直接影响患者安全，因此测试（包括 UAT、安全测试和合规验证）需要比一般企业应用投入更多时间和资源
估算应采用多种方法结合 — 功能点估算提供结构化基础，专家判断补充现实调整，两者结合才能得到更切合实际的估算
估算必须持续更新 — 随着项目推进，对现有系统、数据质量和监管要求了解加深，应重新审视并更新估算，同时向相关方沟通

Key Takeaways

可信信息很重要 — 项目决策应基于有效和可信的信息，而非猜测
数据必须经过解读才能变得有用 — DIKW 模型说明了组织如何从原始记录走向有意义的行动
估算方法应与项目复杂性相匹配 — 不同项目需要不同的估算方法，复杂系统通常需要多种方法结合使用
医疗 IT 项目有额外的挑战 — 安全性、隐私、测试、合规和集成都会增加估算难度
规划质量影响项目成功 — 更好的信息和更准确的估算能带来更好的项目决策和成果

Conclusion

Week 6 tutorial 说明，成功的 IT 项目规划取决于两件事：信息的质量和估算的质量。在 MediCare Solutions 案例中，原始医疗数据只有在通过 DIKW 层次模型转化为信息、知识和智慧后，才能真正支持决策。同时，实际的项目规划需要选择能够反映项目真实复杂性的估算方法。对于本案例，功能点估算与专家判断相结合是最合适的方法，因为它平衡了结构化衡量与实践经验。此外，规划中所用信息的质量应同时得到初级研究（如人员访谈和患者问卷）和次级研究（如行业报告和学术文献）的支持，以确保决策基于可信且相关的证据。总体而言，有效的项目管理不仅在于技术交付，更在于做出有依据、有证据支撑的决策。