INFO5990-Week5-Lecture-Summary
一、本周整体框架
Week 5 Lecture 分成四大部分：
- Information（信息）
- Referencing（引用）
- Research in IT（IT 中的研究）
- Estimation in IT Projects（IT 项目估算）
老师开篇点出核心逻辑链：
First gather information, then understand it through research, and finally use it to estimate time, cost, and effort.
这条链路贯穿整个 Lecture：信息是基础 → 研究是理解信息的方式 → 估算是把信息转化为项目决策的工具。
二、Information（信息）
2.1 什么是信息？
信息的定义：可以被处理、组织和结构化的数据集合，用于传达知识、想法或指令。
信息在 IT 专业实践中的重要性体现在六个方面： - Decision making（决策） - Communication with stakeholders（与干系人沟通） - Problem solving and troubleshooting（问题解决与故障排除） - Project management（项目管理） - Knowledge sharing and continuous learning（知识共享与持续学习） - Compliance and Ethics（合规与伦理）
2.2 DIKW 金字塔（Data → Information → Knowledge → Wisdom）
这是信息管理的经典层级模型：
| 层级 | 定义 | 对应问题 | IT 角色需求 |
|---|---|---|---|
| Data（数据） | 原始事实、数字或符号，没有上下文 | Nothing | 技术专家（programmers、system admins、analysts）处理原始日志、记录、指标 |
| Information（信息） | 经过处理或组织的、有意义的数据 | What? | 所有 IT 专业人员——用于决策、沟通和汇报。这是专业 IT 实践的最低要求层级 |
| Knowledge（知识） | 将经验、上下文和解释应用于信息 | How? / Why is? | 项目经理、顾问、业务分析师、高级工程师——解释和应用信息 |
| Wisdom（智慧） | 运用知识做出正确判断和决策的能力 | Why do? / What is best? | 领导者、策略师、架构师、高管——做长期、伦理和战略决策 |
金字塔从底部（Data）到顶部（Wisdom），是一个从收集零件 → 连接零件 → 形成整体 → 整合全局的过程。
深入理解
DIKW 金字塔的核心启示：不是所有数据都是信息，不是所有信息都是知识。作为 IT 专业人士，你的价值不在于收集数据（这可以自动化），而在于把数据转化为有意义的信息，进而形成可执行的知识和智慧。例如，一个服务器日志文件（Data）本身没有意义，但当你分析出"上个月服务器宕机 3 次，集中在每周五下午 5 点"（Information），再结合你对系统的理解判断"这是因为每周五的批处理任务导致内存溢出"（Knowledge），最后建议"应该升级内存或重新调度批处理时间"（Wisdom）——这就是从 Data 到 Wisdom 的完整路径。
2.3 为什么可信的信息很重要？
五个原因：
- Accuracy in Decision Making：决策的质量取决于信息的质量。不准确或误导性的信息会导致代价高昂的错误、项目失败或安全风险。
- Trust and Professional Reputation：IT 专业人员与客户、管理层和用户合作，分享可信的、基于证据的信息能建立信任、增强专业声誉。
- Risk Reduction：可信的信息帮助正确识别风险、避免错误选择。
- Compliance and Ethics：医疗、金融、政府等行业要求 IT 专业人员处理经过验证的、准确的信息。使用不可信的信息可能导致法律违规、数据泄露或隐私丧失。
- Efficient Communication：团队和干系人需要一个共同的、可靠的事实来源（common, reliable source of truth）。可信的信息确保所有人对齐，减少冲突和混乱。
可信的信息确保值得信赖的决策、合乎伦理的实践、法律合规和专业问责。没有可信度，信息就失去价值，甚至可能造成伤害。
2.4 信息来源的分类
| 来源类型 | 定义 | 举例 |
|---|---|---|
| Primary Sources（一手来源） | 直接的、原创的、第一手证据 | 研究报告、调查问卷、访谈、公司记录和日志 |
| Secondary Sources（二手来源） | 对一手数据的解读、总结或分析 | 教科书、文档、行业报告、新闻文章 |
| Tertiary Sources（三手来源） | 一手和二手来源的整合集合 | 百科全书、词典、数据库 |
2.5 有用信息 vs 无用信息
| 有用信息的特征 | 无用信息的特征 |
|---|---|
| Accurate（准确） | Inaccurate（不准确） |
| Relevant（相关） | Irrelevant（不相关） |
| Timely（及时） | Outdated（过时） |
| Complete（完整） | Incomplete（不完整） |
| Credible（可信） | Redundant（冗余） |
| Understandable（可理解） | Unverifiable（不可验证） |
| Actionable（可执行） | Ambiguous（模糊） |
好的例子："Server uptime last month was 99.95%." → 准确、相关、可执行（用于评估 SLA 合规性）
差的例子："Some servers might have gone down sometime last year." → 模糊、过时、不完整
2.6 信息效度的层级
效度（Validity）= 信息准确、可靠、正确反映现实的程度。
| 效度层级 | 适用场景 | 举例 |
|---|---|---|
| High Validity（高效度） | 错误会导致严重后果的关键场景（法律、财务、伦理、安全） | 医疗记录、网络安全威胁警报 |
| Moderate Validity（中效度） | 日常 IT 运营，小错误可以容忍但应尽量减少 | 项目进度报告 |
| Low Validity（低效度） | 头脑风暴、趋势分析、创新等探索性/非正式场景，近似准确即可 | 反馈调查 |
2.7 如何有效地找到信息？
五个步骤： 1. Define the need（明确需求）——清楚你要找什么 2. Choose the right sources（选择正确的来源） 3. Use effective search strategies（使用有效的搜索策略）——关键词 + 布尔运算符（AND、OR、NOT） 4. Evaluate credibility（评估可信度）——使用 CRAAP Test 5. Organise and store information（组织和存储信息）——使用引用管理工具（Zotero、Mendeley、EndNote）和结构化笔记（Evernote、Notion、OneNote） 6. Apply and communicate（应用和沟通）——把原始信息转化为有洞察力的报告、仪表盘或建议
2.8 CRAAP Test
CRAAP 是评估信息可信度的框架，包含五个维度：
| 维度 | 含义 | 核心问题 |
|---|---|---|
| C — Currency（时效性） | 信息是否最新？ | 什么时候发布或更新的？ |
| R — Relevance（相关性） | 信息是否与你的问题直接相关？ | 是否在合适的层级（太简单/太高深）？ |
| A — Authority（权威性） | 作者、出版商或机构是谁？ | 是否是公认的专家？ |
| A — Accuracy（准确性） | 信息是否有证据、参考文献或数据支撑？ | 是否经过同行评审或测试？ |
| P — Purpose（目的性） | 信息为什么被创建？ | 是为了告知、教育、销售、说服还是娱乐？是否有偏见或隐藏目的？ |
深入理解
CRAAP Test 在学术写作和专业实践中都非常实用。很多学生（和 IT 从业者）会直接 Google 然后引用第一个搜索结果，但这可能是一篇有商业偏见的博客文章。用 CRAAP 五个维度快速过一遍，就能判断一个来源是否值得引用。特别是在写作业和报告时，引用来自 IEEE、ACM 等学术数据库的同行评审论文，远比引用随机博客更有说服力。
三、Referencing（引用）
3.1 为什么引用很重要？
引用是对你使用过的信息来源进行致谢的方式。在 IT 专业实践和学术中，引用的作用包括： - Acknowledge authorship（承认原作者身份）——避免剽窃 - Support credibility（支持可信度）——表明你的信息有证据支撑 - Allow verification（允许验证）——让他人可以找到原始来源
3.2 常见引用格式
| 格式 | 适用领域 |
|---|---|
| APA | IT 和社会科学领域最常用。本课程作业使用 APA7 格式 |
| Harvard | 跨学科广泛使用 |
| IEEE | 工程、计算机科学、IT 领域的标准格式 |
四、Research in IT（IT 中的研究）
4.1 什么是研究？
研究是系统性地收集、分析和解释信息（数据）的过程，目的是回答问题、解决问题或产生新知识。
研究的关键特征： - Systematic（系统性）：遵循清晰的方法或流程，不是随机搜索 - Objective（客观性）：追求真相或有效结果，避免个人偏见 - Evidence based（基于证据）：依赖数据、实验或可信来源 - Replicable（可复制性）：他人应该能够遵循相同过程并得到类似结果 - Innovative（创新性）：通常旨在发现新洞察或改进现有方法
4.2 研究的类型
| 类型 | 描述 | 举例 |
|---|---|---|
| Pure Research（纯研究） | 扩展理论知识 | 算法研究、AI 模型 |
| Applied Research（应用研究） | 解决实际问题 | 开发 HRMS 系统 |
| Qualitative Research（定性研究） | 关注非数值的洞察 | 用户体验研究 |
| Quantitative Research（定量研究） | 使用可测量的数值数据 | 系统性能基准测试 |
4.3 为什么研究在 IT 中重要？
- Innovation and Advancement（创新与进步）：IT 快速发展（AI、cloud、cybersecurity、IoT、blockchain），研究驱动新技术、方法和工具
- Problem Solving（问题解决）：研究提供系统性的方法来分析和解决技术或商业挑战
- Evidence based Decision Making（基于证据的决策）：确保 IT 策略基于事实、数据和证据，而非假设
- Improving Professional Practice（改进专业实践）：研究识别最佳实践、标准和方法论（如 Agile、ITIL、DevOps）
4.4 Primary Research vs Secondary Research
| 特征 | Primary Research（一手研究） | Secondary Research（二手研究） |
|---|---|---|
| 定义 | 直接从来源收集原始的、第一手的数据 | 使用他人已收集的现有数据或信息 |
| 目的 | 回答特定的研究问题或解决问题 | 收集背景信息、支持分析或比较发现 |
| 来源 | 调查问卷、访谈、观察、实验、系统日志 | 书籍、期刊文章、行业报告、网站、数据库 |
| 优势 | 针对你的具体研究问题定制；最新且特定；对质量有直接控制 | 节省时间和资源；提供更广泛的视角；适用于趋势分析和背景知识 |
| 劣势 | 耗时且昂贵；需要仔细的规划和执行 | 可能不完全相关或最新；依赖原始来源的可信度 |
| 举例 | 进行用户调查测试新的 HRMS 界面 | 查阅 IEEE 论文或 Gartner 报告了解云安全趋势 |
如何选择？ - 需要具体的、当前的、特定上下文的数据 → Primary Research（用户测试、系统日志、调查） - 需要趋势、基准、更广泛的洞察 → Secondary Research（行业报告、期刊论文） - 需要快速了解/背景 → Tertiary Sources（百科全书、综述）
4.5 研究的局限性与偏差
研究不是完美的： - Primary Research 的问题：样本量小可能导致误导性结论；设计不良可能导致有偏差的结果 - Secondary Research 的问题：可能过时或不够针对特定场景；可能存在偏差（赞助报告、选择性数据）
五、Estimation in IT Projects（IT 项目估算）
5.1 什么是估算？
估算是在实际工作开始之前，预测完成项目或任务所需的工作量、时间、成本和资源的过程。
在 IT 中，估算通常应用于：软件开发、系统实施、测试和基础设施搭建。
Estimation: The fine art of guessing（估算：精细的猜测艺术）
5.2 估算对 IT 项目的重要性
| 作用 | 说明 |
|---|---|
| Project Planning & Scheduling | 准确的估算让项目经理能制定时间线、设定里程碑、有效分配资源。没有估算，项目面临延迟和瓶颈的风险 |
| Budgeting & Cost Control | 组织需要预测项目成本以获得审批和资金。估算确保财务资源不会过度或不足分配 |
| Stakeholder Expectations | 帮助为客户、赞助者和团队成员设定现实的截止日期和交付物。通过透明建立信任 |
| Resource Management | 确保人力资源（开发者、测试人员、分析师）和技术资源（服务器、许可证、工具）被有效分配 |
| Risk Management | 尽早识别可能的超支，让团队能够准备应急计划 |
| Performance Measurement | 实际项目绩效可以与估算进行比较，以提高未来预测的准确性 |
5.3 估算的工作原理
每个项目中，估算核心是理解这条关系链：
Effort → Resources → Time → Cost
- Effort（工作量）：完成项目所需的总工作量
- Resources（资源）：可用的人员、技能和工具
- Time（时间）：取决于工作如何在团队中分配
- Cost（成本）：取决于做了多少工作、由谁来做
关键洞察： - 加人可以加快速度，但会增加成本 - 短的截止日期通常需要更多资源 - 更少的资源意味着工作需要更长时间
5.4 项目估算五步法
| 步骤 | 内容 | 工具/方法 |
|---|---|---|
| Step 1: Determine SIZE | 定义项目范围、功能和复杂度 | Function Points、Story Points、Lines of Code (LOC)、功能数量 |
| Step 2: Determine EFFORT | 完成项目所需的总工作量 | 以 person-hours、person-days 或 person-months 为单位。可用 COCOMO 或敏捷估算技术 |
| Step 3: Decide RESOURCES | 人力（开发者、测试人员、设计师）、技术（软件、硬件、工具）和财务资源 | 基于所需技能集和可用性进行分配 |
| Step 4: Calculate DURATION | 在给定资源和工作量的情况下，完成项目所需的日历时间 | Effort ≠ Duration：100 小时的工作，1 个开发者需要 2 周，2 个开发者需要 1 周 |
| Step 5: Calculate COST | Cost = (Effort × Resource rate) + Overheads（基础设施、工具、许可证等） | 用于预算编制和客户谈判 |
深入理解
这五步的关键在于理解它们之间的顺序依赖关系：你必须先知道项目有多大（Size），才能估算需要多少工作（Effort）；知道工作量后，才能决定需要什么资源（Resources）；有了资源配置，才能计算持续时间（Duration）；最后才能算出成本（Cost）。跳过任何一步，后续的估算都会不可靠。
还有一个经常被忽视的点：Effort ≠ Duration。100 person-hours 的工作不等于 100 小时就能完成——它取决于你有多少人和他们的技能水平。这也是"加人一定能加速"这个常见误解的来源——Frederick Brooks 在《人月神话》中就指出，在已经延迟的项目上加人，往往会让项目更延迟（因为沟通开销和新人培训成本）。
5.5 估算方法概览
没有单一的最佳方法，需要根据项目特点选择：
（1）Function Point Analysis (FPA)（功能点分析）
原理：通过分析系统需要做什么（输入、输出、用户操作、数据）来估算项目规模。每个功能被赋予一个复杂度等级（简单、中等、复杂），据此估算工作量。
关注什么：用户输入（表单、数据录入）、输出（报告、屏幕）、系统交互、数据和接口
优点：聚焦用户需求；可在项目早期使用；与编程语言无关
适用条件：需求清晰稳定；适合结构化或大型系统
Hospital Management System 案例：
| 功能 | 类型 | 复杂度 |
|---|---|---|
| Patient registration | Input | Simple |
| Appointment booking | Input | Medium |
| View patient details | Output | Medium |
| Patient database | Data | Complex |
FP 取决于功能数量和其复杂度。
（2）Model-Based Estimation / COCOMO（基于模型的估算）
原理：使用数学模型和历史数据来估算工作量、时间和成本。基于项目规模（通常用代码行数 KLOC 衡量）使用公式计算。
优点：比猜测更有结构性和一致性；减少人为偏见；适合大型或复杂项目
局限：依赖输入数据的质量；如果假设错误则准确度降低
COCOMO Model 案例 — Hospital Management System： - 估计规模 = 40 KLOC（中大型系统） - Step 1：理解项目——多功能（注册、预约、报告、数据库管理）+ 安全性、可靠性、多用户支持 → 复杂系统 - Step 2：估算总工作量 ≈ 110 person-months - Step 3：估算持续时间 ≈ 13 months（多人团队并行工作） - 结论：更大更复杂的系统需要更多工作量、更多时间和通常更高的成本
（3）Expert Judgement（专家判断）
原理：依赖有经验的 IT 专业人员基于过去经验给出估算。
适用场景：早期阶段、需求不确定的项目
举例：高级架构师说"我们去年做了一个类似的 HMS，用了 6 个月 6 个开发者。这个模块更少，大概 4 个月 5 个人就够了。"
特点：虽然主观，但当专家熟悉领域时，往往非常现实。
（4）Estimation by Analogy（类比估算）
原理：将当前项目与类似的历史项目进行比较，根据差异进行调整。
适用条件：有可作为基准的历史项目数据
举例：如果你的公司开发了一个 Clinic Management System（用了 5 个月，$200,000），而新的 HMS 复杂度是其两倍，你可以估算 ~10 个月，~$400,000。
（5）Task-based Estimation / WBS（基于任务的估算 / 工作分解结构）
原理：将项目分解为任务或子任务（Work Breakdown Structure），分别估算每个任务，然后汇总。
适用条件：任务定义清晰时最佳，适合详细的项目规划
Hospital Management System 举例： - UI Design → 100 hours - Backend Development → 400 hours - Testing → 200 hours - Deployment → 50 hours - Total = 750 hours - 然后根据团队规模和小时费率计算持续时间和成本
5.6 估算方法的局限性和偏差
| 方法 | 局限性 | 偏差 |
|---|---|---|
| Expert Judgement | 严重依赖个人经验；对大型复杂项目可能不够 | 主观乐观（低估）或悲观（高估）；可能锚定在不完全匹配的过去项目上 |
| Estimation by Analogy | 需要真正可比的历史项目数据；范围/技术差异可能被忽视 | 过度依赖相似性，忽略新项目的独特方面；可能产生"虚假等价偏差" |
| Function Point Analysis | 耗时；需要早期就有详细的功能规格说明（不一定有） | 依赖评估者对系统复杂度的解读；不同评估者可能给出不同的功能点值 |
| COCOMO | 基于假设和历史数据的校准；对新兴技术不太准确 | "Garbage in, garbage out"——有偏差的或低质量的输入数据导致不准确的结果 |
| WBS / Sum of Parts | 有重复计算工作量或忽视组件间隐藏依赖的风险 | 锚定偏差——估算者可能聚焦于某些部分而忽略集成开销 |
深入理解
每种估算方法都有其最佳适用场景。在实践中，最好的做法是组合使用多种方法，互相验证。例如，先用 Expert Judgement 快速得到一个粗略估算，再用 FPA 或 COCOMO 进行更精确的验证，最后用 WBS 进行详细分解。如果三种方法给出的结果大致一致，那么估算就比较可靠；如果差异很大，就需要重新审视假设。
另外，所有估算方法都有一个共同的根本问题：估算是在信息不完全的情况下做预测。项目越早期，不确定性越大，估算的偏差也越大。这就是为什么敏捷方法论提倡"渐进式估算"——随着项目推进、信息增多，不断修正估算。
5.7 Agile vs Traditional Estimation 对比
| 方面 | Agile Estimation（敏捷估算） | Traditional Estimation（传统估算） |
|---|---|---|
| Approach | 迭代、自适应、基于相对工作量 | 预测性、详细的前期规划（规模、工作量、成本、进度） |
| Method | Planning Poker、Wideband Delphi、Velocity Tracking | COCOMO、Function Point Analysis、WBS |
| Focus | 按功能/用户故事估算工作量/复杂度，不是一次性估算整个项目 | 在执行前估算整个项目 |
| Strengths | 灵活，鼓励团队协作，随项目发展持续重新估算 | 开始时就有明确的预算和时间线承诺。适合需求稳定、定义清晰的项目 |
| Limitations | 难以提供长期的成本/持续时间预测；严重依赖一致的团队速度；合同要求固定预算/时间线时不太适用 | 对需求变更不灵活，前期估算可能随项目推进变得过时；如果假设错误，存在大偏差的风险 |
六、Case Study：MediCare Solutions 的 EHR 系统
6.1 背景
一家中型医疗保健公司 MediCare Solutions 想要开发一个电子健康记录（EHR）系统。系统需包括： - 患者记录存储（结构化 + 非结构化数据） - 预约排程 - 与医院计费系统集成 - 患者安全移动应用
CIO 指派一个项目经理来估算项目的规模、工作量、资源、持续时间和成本。经理还必须确保过程中使用的信息是有效的、可信的、经过充分研究的，并在决定前评估估算方法。
6.2 分析问题
- 用 DIKW 层级解释原始患者数据如何在 MediCare Solutions
中成为决策的"智慧"
- Data：原始的患者记录（姓名、日期、检查结果数字）
- Information：处理后的患者档案（某患者 3 个月内血糖持续偏高）
- Knowledge：结合医学知识理解（该患者可能存在糖尿病风险，需要调整治疗方案）
- Wisdom：做出战略决策（系统应增加自动预警功能，当检测指标异常时主动通知医生）
- 识别至少两个 Primary 和两个 Secondary 研究来源
- Primary：对医生/护士/行政人员进行需求访谈；分析现有系统的日志数据
- Secondary：查阅 IEEE/ACM 关于 EHR 系统的学术论文；参考 Gartner 的医疗 IT 行业报告
- 将项目估算五步法应用于 EHR 系统
- Size：多模块（患者记录、预约、计费集成、移动应用）→ 大型复杂系统
- Effort：基于类似项目和复杂度估算（如 120-150 person-months）
- Resources：前端、后端、数据库、安全、移动开发团队 + 测试 + PM
- Duration：团队并行工作，约 12-18 个月
- Cost：人力成本 + 基础设施 + 许可证 + 合规审计费用
- 推荐哪种估算方法？为什么？
- 建议组合使用：先用 Expert Judgement（如果公司有类似项目经验）进行初步估算，再用 FPA 对各模块进行详细分析（EHR 系统的功能需求相对清晰），最后用 WBS 分解具体任务。如果有可比的历史项目，还可以用 Analogy 做交叉验证。
七、End of Lecture Questions 梳理
为什么可信的信息对 IT 专业人员很重要？ → 确保决策准确、建立信任、降低风险、保证合规、促进高效沟通。
DIKW 层级如何帮助 IT 决策？ → 从原始数据到有意义的信息，再到可应用的知识，最终到做出正确判断的智慧——每一层都增加了价值和理解深度。
信息的关键来源有哪些？CRAAP Test 如何帮助评估？ → 来源分为 Primary、Secondary、Tertiary。CRAAP Test 通过 Currency、Relevance、Authority、Accuracy、Purpose 五个维度评估信息可信度。
区分 Primary 和 Secondary Research，项目可行性研究应选哪个？为什么？ → 两者的定义和区别见上表。可行性研究应两者结合：用 Secondary Research 了解行业趋势和类似系统，用 Primary Research 收集特定的用户需求和技术环境数据。
概述项目估算的 5 个步骤并解释它们如何相互关联 → Size → Effort → Resources → Duration → Cost，每一步的输出都是下一步的输入。
比较六种项目估算方法，哪种最可靠？为什么？ → 没有单一最可靠的方法——每种都有适用场景和局限。最可靠的做法是组合使用多种方法并交叉验证。