INFO5990-Week6-Tutorial-Summary
INFO5990 Week 6 Tutorial Answer Sheet Summary
Overview
Week 6 的 tutorial 聚焦于两个核心主题：可信信息（credible information）在 IT 项目中的作用和项目估算（estimation）方法的选择与应用。与 Week 5 侧重于沟通、团队合作和利益相关者管理等"人"的维度不同，Week 6 转向了"信息和方法"的维度——IT 项目的决策质量取决于信息的质量，而项目规划的可行性取决于估算方法的合理性。
Tutorial 通过两个递进的部分构建完整的知识框架：Part A 通过 Concept Check 建立核心概念基础——理解信息为什么是 IT 项目的"燃料"、如何通过 DIKW 层次模型将原始数据转化为有价值的决策依据、以及统计学在 IT 研究中的重要性；Part B 通过 MediCare Solutions EHR 案例将这些概念应用到实际场景中——对医疗数据应用 DIKW 模型、识别研究来源、分析可信信息的关键性、运用五步估算法进行项目规划、以及选择最合适的估算方法。
这两个部分的逻辑是：Part A 建立"信息-知识-决策"的概念基础，Part B 将这些概念应用到一个具有现实复杂性的医疗 IT 项目中。这种从概念→应用的结构，培养了 IT 专业人士在实际项目中做出有依据、有证据支撑的决策的能力。
Learning Outcomes
完成本次 tutorial 后，学生应能够： - LO2 — 理解与软件测试、数据安全、数据质量和质量保证相关的 IT 行业问题，学习使用 IT 项目管理方法解决这些问题。本周通过讨论可信信息如何影响系统设计和测试质量、以及不准确的信息如何危及数据安全和患者安全来培养这一能力。 - LO4 — 理解 IT 在不同行业中的应用，评估信息技术对全球化世界中个人和组织的影响。本周通过 MediCare Solutions 医疗 IT 案例，分析 EHR 系统在医疗行业中的应用，理解信息质量和项目估算如何影响医疗 IT 项目的成败。 - LO6 — 应用研究方法、模型和工具分析 IT 专业实践，识别和批判变化中的信息，判断结果的潜在有效性。本周通过 DIKW 模型的应用、初级/次级研究来源的识别、以及项目估算方法的评估来培养这一能力。
Part A — Concept Check（概念检查）
Q1: Why is information considered the "fuel" of IT projects?（为什么信息被视为 IT 项目的"燃料"？）
核心答案： 信息在 IT 项目的每个阶段指导决策——从规划到实施。没有准确的信息，项目经理无法定义范围（scope）、分配资源（allocate resources）或评估风险（assess risks）。
深入理解： "燃料"这个比喻精准地描述了信息在 IT 项目中的角色——就像汽车没有燃料就无法行驶一样，IT 项目没有信息就无法推进。信息驱动了项目生命周期中的所有关键活动：
在规划阶段，信息帮助定义项目的范围和目标——需要了解系统需求（system requirements）、用户期望（user expectations）和技术约束（technology constraints），才能制定切实可行的项目计划。如果在规划阶段使用的信息不准确或不完整，可能导致范围定义错误，进而在项目后期引发 scope creep 或需求返工。
在执行阶段，信息帮助团队做出日常决策——哪些任务应该优先完成？当前进度是否符合预期？哪些风险正在变为现实？项目经理通过持续收集和分析信息来监控项目健康状况并及时调整。
在交付阶段，信息帮助验证项目成果——系统是否满足最初定义的需求？用户是否满意？系统性能是否达标？
示例： 了解系统需求、用户期望和技术限制，使项目能够高效执行。例如，如果项目团队不了解目标用户的设备分布（60% 使用手机、30% 使用平板、10% 使用桌面电脑），可能会在 UI 设计上做出错误决策。
Q2: Explain the DIKW hierarchy using an IT-related example（用 IT 相关案例解释 DIKW 层次模型）
核心答案： 以社交媒体数据为例：
| 层次 | 社交媒体示例 | 说明 |
|---|---|---|
| Data（数据） | 社交媒体平台上的原始用户活动日志 | 未经处理的原始事实记录，本身不携带含义 |
| Information（信息） | 经处理的数据，显示每日活跃用户数（DAU）和每次会话时长 | 数据经过整理和聚合后形成有意义的指标 |
| Knowledge（知识） | 通过分析趋势，识别出用户使用高峰时段和参与模式 | 从信息中发现模式、关系和因果 |
| Wisdom（智慧） | 利用洞察做出战略决策，如优化 App 推送通知时间或服务器负载均衡，以改善用户体验 | 将知识应用于做出更好的战略性决策 |
深入理解： DIKW 层次模型（Data → Information → Knowledge → Wisdom）是信息管理的经典框架，描述了原始数据如何逐步转化为有价值的决策依据。每一层都建立在前一层的基础上，但"含义密度"和"决策价值"显著递增。
Data（数据） 是最底层——原始的、未经处理的事实和数字。数据本身没有含义，需要上下文才能被理解。例如，"1,234,567" 这个数字本身没有意义——它可能是用户数量、交易金额或访问次数。
Information（信息） 是数据经过处理、整理和上下文化后的结果。当我们说"平台的每日活跃用户数为 123 万，平均会话时长为 8.5 分钟"时，数据已经被赋予了含义和结构。信息回答"what"（发生了什么）。
Knowledge（知识） 是从信息中提取出的模式、趋势和因果关系。例如，发现"用户活跃高峰在工作日的午休时间和晚间，周末活跃度比工作日高 40%"——这超越了数据描述，进入理解"why"和"how"的层面。
Wisdom（智慧） 是最高层——将知识应用于做出更好的决策。例如，基于用户活跃模式，决定在午休时间推送重要通知、在周末增加服务器容量、在低活跃时段进行系统维护。
Q3: Why are statistics important when conducting IT research?（为什么统计学在 IT 研究中很重要？）
核心答案： 统计学能够对大量数据进行总结和解释，识别模式、趋势和异常。描述性统计（均值、中位数、方差）帮助理解系统性能或用户行为；推断性统计能够进行预测和假设检验，例如评估新功能是否提高了用户参与度。
深入理解： 统计学是将主观感觉转化为客观证据的工具。
描述性统计（Descriptive Statistics） 帮助我们理解"现在发生了什么"： - 均值（Mean）：如系统平均响应时间 200ms——了解整体性能水平 - 中位数（Median）：如客户满意度中位数 4.2/5——不受极端值影响，比均值更稳健 - 方差和标准差：如响应时间标准差 50ms——反映系统性能的稳定性
推断性统计（Inferential Statistics） 帮助我们做出预测和决策： - 假设检验：新 UI 上线后转化率是否显著提升？通过 A/B 测试和统计检验判断 - 回归分析：影响网站加载速度的因素有哪些？识别关键变量及其影响程度
实践场景： 在系统负载测试中，统计数据能显示响应时间的分布和瓶颈（如 95th percentile）；在客户调查中，统计数据能量化用户满意度和需求优先级。
Part B — Case Study: MediCare Solutions EHR Project（案例分析）
案例背景
MediCare Solutions 是一家中型医疗公司，计划开发一套 Electronic Health Record（EHR）电子健康档案系统，系统需包含： - 患者档案存储（Patient Records Storage）— 结构化 + 非结构化数据 - 预约挂号管理（Appointment Scheduling） - 账单系统集成（Billing System Integration） - 患者端移动应用（Mobile App for Patients）
项目经理需要估算规模、工作量、资源、工期和成本，同时确保信息可信并采用合适的研究和估算方法。
Q1: Apply the DIKW model to the healthcare data in this project
Data（数据）
原始患者病历记录、预约日志、账单条目。
深入理解： 数据是未经处理的原始事实：未整理的病史笔记和检查结果、包含日期/时间/医生/患者字段的预约记录、金额和支付状态代码等账单明细。数据本身只是事件记录，不足以支持决策。
Information（信息）
经处理的报告，显示每个部门的患者就诊次数或付款状态。
深入理解： 数据经过整理后形成有意义的指标：每周各部门就诊次数报告、预约未到率月度统计、各类别欠款账单汇总、各预约类型的平均等待时间。到这个层次，团队能了解运营状况。
Knowledge（知识）
模式如预约高峰时段、最常见的医疗程序或账单延迟规律。
深入理解： 从信息中发现规律和因果：预约高峰在工作日上午 9-11 点；某些程序延误与设备调度有关；欠款最常出现在无保险患者中；节假日前取消率上升。组织不仅知道"发生了什么"，还理解"为什么"。
Wisdom（智慧）
利用洞察优化排班、资源配置和改善患者护理。
深入理解： 将知识转化为行动：根据高峰规律重新排班；提前调配资源到瓶颈部门；针对欠款群体实施跟进流程；基于就诊规律改善护理路径。数据被主动用于创造价值。
总结表
| 层次 | 在本案例中的对应内容 |
|---|---|
| Data | 原始患者病历、预约日志、账单记录 |
| Information | 就诊周报、账单汇总表、等待时间统计 |
| Knowledge | 高峰预约规律、常见延误原因、账单错误趋势 |
| Wisdom | 优化排班、合理人员配置、改善患者护理 |
Q2: Identify 2 primary research and 2 secondary research sources
初级研究来源（Primary Research Sources）
1. 对医院工作人员和临床医生的问卷调查/访谈
通过对医生、护士和行政人员进行访谈或问卷调查，直接获取关于当前工作流程和痛点的第一手见解。这是初级研究，因为数据是为特定目的直接从来源处收集的。优势是能捕捉到文档无法替代的真实情境经验。局限性在于耗时且样本量可能有限。
2. 对患者交互和预约处理流程的观察
直接观察患者在预约、登记、就诊和结算过程中的实际流程。优势是能发现访谈中遗漏的隐性问题（如前台人员已习惯的低效操作）。局限性在于可能存在霍桑效应（Hawthorne Effect）。
次级研究来源（Secondary Research Sources）
1. EHR 实施行业报告（如 HIMSS 报告）
已发布的报告和白皮书，涵盖 EHR 采用率、实施标准、成本基准和最佳实践。优势是提供来自大样本的基准数据。局限性在于可能无法完全匹配 MediCare Solutions 的具体情境。
2. 医疗 IT 实施的学术文献和案例研究
经同行评审的期刊文章，研究医疗 IT 项目规划和实施。优势是经过学术检验，发现较可靠。局限性在于发表周期长，部分发现可能已过时。
| 类型 | 来源 | 为什么相关 |
|---|---|---|
| 初级研究 | 对医院工作人员的访谈/问卷 | 直接获取工作流程和痛点的第一手信息 |
| 初级研究 | 对患者交互流程的观察 | 直接发现现有系统的使用问题 |
| 次级研究 | 行业 EHR 报告（如 HIMSS） | 提供采用率、成本的基准数据 |
| 次级研究 | 学术文献和案例研究 | 提供循证方法论和案例分析 |
Q3: Why is credible and referenced information especially critical for healthcare IT projects?
核心答案： 确保法规合规；降低危及患者安全或数据安全的错误风险；为系统设计、测试和决策提供可靠输入。
深入理解：
1. 法规合规要求（Regulatory Compliance） — 医疗 IT 系统必须遵守 HIPAA、GDPR 以及当地医疗数据保护法律。如果系统设计基于不可靠信息（如过时的法规版本或错误理解的数据跨境传输限制），可能导致合规失败，面临巨额罚款和声誉损害。
2. 患者安全风险（Patient Safety） — 医疗系统中的错误可能直接影响患者健康甚至生命。不准确的信息可能导致：用药剂量单位转换错误、急诊场景下遗漏过敏警告、基于不可靠基准的容量规划导致高峰期宕机。
3. 系统设计与决策的可靠性（Reliable Decision-Making） — 项目经理在需求分析、系统设计、测试规划和成本估算中都依赖信息质量。可信来源（如行业标准 HL7/FHIR、经同行评审的研究、直接用户调研）确保决策基于事实而非假设。
Q4: Using the 5 steps of estimation, make a rough plan
第一步 — 估算项目规模（Estimate Size）
项目分解为四大功能模块 + 横向工作（数据迁移、安全合规、集成测试、UAT、培训）：
| 模块 | 估算功能点数 |
|---|---|
| 患者档案存储 | 35–45 FP |
| 预约挂号管理 | 25–35 FP |
| 账单系统集成 | 30–40 FP |
| 患者端移动应用 | 20–30 FP |
| 估算总规模 | 约 110–150 FP |
第二步 — 估算工作量（Estimate Effort）
医疗 IT 环境生产率约 6–8 人工日/FP： - 总工作量 = 110–150 FP × 6–8 人日/FP ≈ 660–1,200 人日 ≈ 约 30–55 人月
第三步 — 估算资源（Estimate Resources）
- 开发人员：4 名 | 测试人员：2 名 | 项目经理：1 名 | 业务分析师：1 名
第四步 — 估算工期（Estimate Duration）
- 总工作量 30–55 人月 ÷ 核心团队 6 人 ≈ 约 5–9 个月
第五步 — 估算成本（Estimate Cost）
假设工期 7 个月（中间值），开发 $8,000/人/月，测试 $6,000/人/月： - 开发：4 × $8,000 × 7 = $224,000 - 测试：2 × $6,000 × 7 = $84,000 - PM + BA（约 15%）：$46,000 - 基础设施/应急（15–20%）：$50,000–$70,000 - 指示性总成本：约 AUD $400,000–$500,000
| 步骤 | MediCare Solutions EHR 示例 |
|---|---|
| 估算规模 | 4 模块，约 110–150 FP |
| 估算工作量 | 约 30–55 人月 |
| 估算资源 | 4 开发 + 2 测试 + PM + BA |
| 估算工期 | 约 5–9 个月 |
| 估算成本 | 约 AUD $400K–$500K |
Q5: Which estimation approach seems best for this case, and why?
结论：功能点估算法（Function Point Estimation）与专家判断（Expert Judgement）的结合。
功能点估算适合的原因： 项目需求已明确界定（四个独立模块），功能点方法根据系统功能衡量规模（而非代码行数），提供结构化、可重复的估算基础，便于与类似项目对比。
专家判断必要的原因： 医疗 IT 的特殊复杂性（隐私要求、系统集成、合规需求、零错误容忍）难以用纯公式衡量。有经验的专家能调整估算以反映现实因素，并识别纯计算中不会出现的风险。
与其他方法的比较： - 类比估算（Analogy）：医疗 IT 项目差异大，没有两家机构有完全相同的环境，参考项目差异显著时误差大 - 经验模型（COCOMO/SEER-SEM）：需要充分的历史数据，MediCare Solutions 可能不具备此基础
功能点提供结构化基础，专家判断补充现实调整——既有方法论严谨性，又有对现实的灵活适应。
关键概念总结
本周核心链条
信息质量 → 决策质量 → 项目质量。 DIKW 说明如何从数据提取决策依据；研究方法说明如何获取可信信息；统计学说明如何得出可靠结论；五步估算法说明如何将信息转化为项目计划。每个环节都建立在信息可信度之上。
与前几周的连接
- Week 2 的信息素养是本周"可信信息"的方法论基础
- Week 3 的 IT 投资价值证明与项目估算直接相关
- Week 4 的方法论选择受估算准确性的直接影响
- Week 5 的沟通原则（7Cs）应用于向利益相关者呈现估算结果
关键术语表
| 术语 | 英文 | 含义 |
|---|---|---|
| DIKW 层次模型 | DIKW Hierarchy | 数据→信息→知识→智慧的转化框架 |
| 可信信息 | Credible Information | 可靠的、有来源可追溯的信息 |
| 初级研究 | Primary Research | 为特定目的直接从来源收集的原始数据 |
| 次级研究 | Secondary Research | 利用他人已收集和发布的现有数据 |
| 描述性统计 | Descriptive Statistics | 总结和描述数据特征的统计方法 |
| 推断性统计 | Inferential Statistics | 基于样本数据进行推断和预测的统计方法 |
| 功能点估算 | Function Point Estimation | 基于系统功能来衡量软件规模的方法 |
| 专家判断 | Expert Judgement | 基于经验和专业知识进行估算调整 |
| 电子健康档案 | Electronic Health Record (EHR) | 患者健康信息的数字化记录系统 |
| 霍桑效应 | Hawthorne Effect | 被观察者因知道被观察而改变行为的现象 |
参考
- INFO5990 Week 6 Tutorial Sheet & Answer Sheet
- INFO5990 Week 6 Lecture: Information and Estimation for IT Projects
- DIKW Hierarchy (Ackoff, 1989)
- HIMSS — Healthcare Information and Management Systems Society
- Function Point Analysis (IFPUG Standards)