跳到正文Project Governance Portfolio Guidelines S1 2026 · Jimmy Huang's Blog
三、评估方式
Studio Mentor 会在每个 Iteration 中对这些内容进行评估。
你们会收到相关反馈,这部分内容也会计入每个 Iteration 的成绩。
为了清晰展示项目的发展过程,团队需要提供相应的开发产物,例如:
软件包、编程语言和框架等信息,只有在能够为项目提供价值时才应加入。
四、项目治理档案中的典型文件夹和产物
课程提供的团队文件夹结构只是一个建议,团队可以根据自身项目情况进行调整。
1. Team Information Folder
团队信息文件夹
2. Team Meeting Folder
团队会议文件夹
Iteration Planning Meeting Agenda
Iteration Planning Meeting 的议程文档。
在 Analysis and Design 阶段,团队应讨论:
最终用户的目标
最终用户的需求
产品可能提供的机会
项目涉及的技术
其他会议记录
3. Design and Analysis Artifacts Folder
设计与分析产物文件夹
3.1 AI 使用文档
使用了哪些 Prompt
AI 生成了什么结果
团队如何修改这些结果
更多要求请参阅后文的 Design Artefacts Folder 部分。
3.2 Persona Profile
可以从 Iteration 2 开始使用多个 Persona。
3.3 Design Thinking Artifacts
3.4 其他强制性设计与分析产物
Conceptual ERD Diagram
概念实体关系图
Conceptual Architecture Diagram
概念架构图
User Story Mapping
用户故事地图
Identified Use Cases
已识别的使用案例
Customer Journey Mapping
用户旅程图
Ethics Canvas
伦理画布
Lo-fi Prototypes / High-level Prototypes
低保真原型或高层级原型
Site Map
网站地图
其他能够说明团队如何从数据和信息收集,逐步形成对用户需求理解的设计文档
4. Usability Testing Video Folder
可用性测试视频文件夹
该文件夹应体现团队对可用性测试的基本理解,并包含以下内容。
测试视频数量
测试结果报告
预期结果
需要进行的修复
负责修复的团队成员
相应测试用例
团队应确保测试用例能够充分覆盖项目不同阶段所完成的测试。
5. Iteration Build Folder
迭代构建文件夹
Development Approach
开发方法
First-cut Data Models
初步数据模型
Software Packages
软件包
Programming Languages
编程语言
Frameworks
开发框架
6. Testing Folder
测试文件夹
7. System Architecture Folder
系统架构文件夹
该文件夹可从潜在 Sponsor 的角度说明拟议系统。
Sponsor 可能没有 IT 背景,因此建议尽量使用图表进行说明。
潜在数据来源
这些数据可能如何被使用
可能使用的 API
8. Risks Folder
风险文件夹
较为准确地记录大多数项目风险。
为已识别的风险制定总体有效的缓解策略。
9. Retrospective Folder
回顾会议文件夹
Miro:7 Retrospective Templates
10. Data Governance Folder
数据治理文件夹
该文件夹应包括一份 Data Management Plan Report。
更多要求请参阅后文的 Data Management Plan Report Guidelines。
课程期望这些团队在数据治理部分完成比其他团队更多的内容。
11. Security Aspects Folder
安全相关文件夹
Security Plan
与项目相关的具体安全问题
产品中已经实施的所有安全措施
更多要求请参阅后文的 Security Plan Guidelines。
Vulnerability Assessment Report
仅适用于 Master of Cybersecurity 学生。
每一个 Iteration 都需要提交 Vulnerability Assessment Report。
12. Handover Documents Folder
项目交接文件夹
请参考 Handover Package Guidelines。
Product Document
Support Document
Maintenance Document
这些文档会在 Week 11 进行评分,但 Studio 会在整个学期持续检查和审阅这些文档。
五、数据管理计划报告指南
Data Management Plan Report Guidelines
Data Management Plan 是一份动态文档。
它需要在 Iteration Analysis and Design 阶段提交。
教学团队提供的所有反馈,都必须在提交 Iteration Build 时完成落实。
1. 数据管理计划的目的
它是一份动态文档,会在每次 Iteration Review 中被检查。
文档应上传到 PGP 中的 Data Governance Folder。
2. 数据来源和更新频率
数据来源的详细信息
数据的使用方式
数据源自身的更新频率
数据进入团队系统的更新频率
需要明确说明这些数据在当前 Iteration中如何使用。
数据如何进入应用程序
数据如何被更新
更新过程由谁或什么系统执行
3. 数据建模和分析
4. 数据管理计划必须包括的内容
4.1 数据处理流程
Wrangling
数据整理
Cleansing
数据清洗
Transposing
数据转换
Storing
数据存储
Archiving
数据归档
4.2 开放数据源
文档应包括所有 Open Data Sources 的详细信息,并说明这些数据如何被更新到系统中。
4.3 Ethical、Legal 和 Privacy Issues
Ethical Issues
Legal Issues
Privacy Issues
这些部分需要说明与 Artificial Intelligence 伦理有关的问题。
展示对伦理问题的基本理解。
较好地处理相关伦理问题。
考虑数据管理问题。
考虑潜在的算法偏见。
说明开放数据涉及的伦理、法律和隐私问题。
4.4 批判性思考和分析
对所采用数据建模技术的深入批判性思考与分析。
对数据分析技术应用方式的批判性思考与分析。
4.5 过程截图和数据库关系图
4.6 对问题领域的理解
对 Problem Domain 的良好理解。
基于开放数据集定义清晰且有意义的用户需求。
4.7 对需求的理解
为什么需要这些需求
这些需求如何支持产品
未来可能出现的需求
潜在挑战
六、开放数据源表格示例
Example – Data Sources / Open Datasets
Creative Commons Attribution 3.0 的要求包括:
必须给予适当署名
必须提供许可证链接
如果对数据进行了修改,必须说明修改内容
七、设计产物文件夹中的 AI 文档
Design Artefacts Folder
AI Design Document 的目的是记录每个 Iteration 中使用 AI 工具的 Prompt。
记录 Copilot 的使用情况
展示团队对 AI 潜力的理解
展示团队对 AI 局限性的理解
帮助课程团队更全面地评估项目的发展过程
1. 什么时候需要 AI Design Report
如果团队使用 Copilot 完成或改进了以下内容,则每一个部分都需要单独提交一份 AI Design Report:
Problem Statement
User Stories
Acceptance Criteria
AI Design Report 是一份动态文档。
它需要放入 PGP 的 Design Folder 中。
2. AI Design Document 需要记录的领域
Problem Statement
优化项目的核心问题陈述
改进问题陈述的表达
提高问题陈述的清晰度
User Story Development
生成 User Stories
优化 User Stories
确定 User Stories 的优先级
Acceptance Criteria Definition
制定 Acceptance Criteria
优化 Acceptance Criteria
改进项目交付成果的验收条件
3. AI Design Document 的结构
每一份 AI Design Document 应按照以下结构编写。
3.1 Prompt Text
Prompt 的准确文本
提供给 AI 的背景信息
使用的参数或限制条件
AI 生成的结果
3.2 使用另一个 Prompt 进行比较和改进
比较不同 Prompt 的输出结果
改进第一次生成的结果
3.3 Results and Evaluation
Prompt 进行了哪些修改
为什么要修改 Prompt
修改后结果有什么变化
Prompt 如何逐步得到改进
团队如何使用自己的语言重新修改 AI 的结果
4. AI Design 文档建议
Be Specific and Clear
Prompt 和相关背景信息应尽量具体、清晰,以避免歧义。
Use Natural Language
Prompt 可以使用自然、对话式的语言编写,使其更容易:
八、安全计划报告指南
Security Plan Report Guidelines
它需要在 Iteration Analysis and Design 阶段提交。
分析与系统和应用程序相关的安全风险
制定安全措施
制定安全政策
确保应用程序能够安全运行
安全计划必须重点考虑与你们自己的应用程序直接相关的安全问题。
九、系统安全意识
System Security Awareness
安全风险表格示例
密码如何管理?
密码如何修改?
密码多久更换一次?
认证信息的更新流程是什么?
十、伦理、法律、安全和隐私问题
Ethical, Legal, Security and Privacy Issues
产品将如何保护用户信息
产品将如何遵守隐私规则
产品将如何防范黑客攻击
产品将如何应对其他安全威胁
十一、风险分析
Risk Analysis
如果系统遭到攻击,团队应进行 Root Cause Analysis。
Root Cause Analysis 需要记录在:
该部分仅对 Master of Cybersecurity 学生有额外要求。
十二、漏洞评估
Vulnerability Assessment
仅适用于 Master of Cybersecurity 学生
每个 Iteration 在提交 Iteration Build 时,每位 Master of Cybersecurity 学生都必须向 PGP 提交以下内容。
1. Penetration Tests and Findings
对自己的系统进行渗透测试。
执行一次或多次攻击测试。
使用相关截图和文字说明记录测试结果。
警告
严禁进行 Brute Force Attacks,即暴力破解攻击。
2. Result Evaluation、Impact Assessment and Reinforcement
分析渗透测试结果。
描述发现的漏洞。
对已识别漏洞进行影响评估。
列出建议的缓解策略。
实施相应的缓解措施。
3. 没有发现漏洞时的要求
如果测试过程中没有发现或成功利用任何漏洞,仍然需要根据观察结果提供主动安全建议。
如果系统包含一个表单,但没有使用 reCAPTCHA,可以建议加入 reCAPTCHA,以:
十三、安全测试报告结构
所有安全测试工作需要以正式报告的格式进行整理和记录。
Security Drill Structure
1. Pen Test Findings
渗透测试攻击截图
攻击过程描述
测试结果
发现的安全问题
发现的漏洞
2. Impact Assessment
Confidentiality
机密性
Integrity
完整性
Availability
可用性
3. Recommendations
修复已识别漏洞的建议
防止未来漏洞或威胁的最佳实践
每一项建议的优先级
漏洞的潜在影响
修复措施的实施难度
修复措施的实施成本
问题的紧急程度
十四、提交方式
Mentor 在此项目中相当于 Studio Manager。
Project Governance Folder → Security Sub Folder