[I.1] 个人作业：阅读和提问

[I.1] 个人作业：阅读和提问

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	个人作业：阅读和提问
我在这个课程的目标是	了解软件工程开发流程，熟悉团队开发过程，能够与团队完成一个软件项目，积累沟通协作的能力
这个作业在哪个具体方面帮助我实现目标	通过快速阅读，初步了解到软件工程的思想和方法论，锻炼独立思考和提问能力

问题一:在实际团队协作中，时间花费是如何计算的？Cocomo模型还准确吗？

另一个原则倒是非常精确，发展于1980年代的Cocomo模型，认为某种项目的时间花费（人月）遵守这样的公式：
Person * Month = 2.4 * KLoC ^ 1.05

在教材的第一章中提到了一个计算项目的时间花费的某种计算模型：Cocomo模型。其中Preson * Month 表示项目的时间花费（人月），KLoC 表示项目的代码行数（Kilo Lines of Code）。在数学上看，指数1.05非常接近1，意味着工作量与代码量近似于线性关系。我的疑问是：这个 1980 年代的 Cocomo 模型得出的指数为什么只有 1.05，这几乎意味着每增加一行代码，所需人月几乎是等比例增加，这似乎与软件工程中“沟通成本随人数平方增长”（Brooks 法则）的直觉相矛盾。请问这个模型是否低估了大规模软件项目的协作开销？还是说随着软件工程的进步，这个模型已经不再适用了。

Brooks 法则（通常称为布鲁克斯定律）是由弗雷德·布鲁克斯（Fred Brooks）在其经典著作《人月神话》（The Mythical Man-Month，1975年）中提出的一个著名论断。
它的核心内容是：
“向一个已经延误的软件项目添加人力，只会让它更延误。”

问题二：在实践中，有哪些有效的方法或模板可以将模糊的非功能需求转化为可测试、可验证的具体指标？

非功能需求：这也叫“服务质量需求”（Quality of Service Requirements），指的是软件系统在功能需求之外的其他需求，例如性能、可靠性、安全性等。

在教材的第八章中提到了“非功能需求”的概念在我们实际进行软件开发中，总会遇到各种非功能需求：如“系统响应速度要快”、“界面要美观易用”。这些描述缺乏可量化的衡量标准，导致在后续测试和验收阶段无法客观判断是否达成。所以我思考，总应该用一些具体的指标来衡量这些非功能需求是否被满足。

经过查阅资料，有以下的模型标准：
ISO/IEC 25010 质量模型： 这个国际标准为软件产品质量定义了一个全面的模型，包括功能性、可靠性、易用性、效率、维护性、可移植性等八大特性，每个特性下又有更细的子特性。它为量化非功能需求提供了一个理论框架。

ATAM（架构权衡分析方法）： 由卡内基梅隆大学软件工程研究所开发的一种方法，专门用于在架构设计阶段评估非功能需求（他们称之为“质量属性”），并识别不同属性之间的权衡点。

具体的量化案例：
性能： 不应是“响应要快”，而是“在 100 个并发用户下，95% 的登录请求应在 2 秒内完成”。
易用性： 不应是“界面要友好”，而是“新员工经过 2 小时培训后，应能在 5 分钟内完成一笔标准订单录入，错误率低于 1%”。

问题三：Program Manager VS. Project Manager,哪一个更适合小组软件开发？

Project Manager	Program Manager
是团队的行政领导，带领大家在项目中工作	和大家平等工作，推动团队完成软件的功能
通常是团队和外界打交道的唯一代表	一个团队可以有多个PM
对项目的功能有最后的决定权	和其他团队成员一起形成决议
管事也管人	管事不管人
不一定做具体工作	一定做具体工作

在书中的第九章中，提到了两种不同PM的角色：Project Manager和Program Manager。两个PM都致力于帮助团队推动软件功能的开发，并且与客户进行交流。但作为小组团队开发，Program Manager应该更适合？因为在小组中，如果采用Project Manger,由于不一定要完成特定的任务，就会出现敷衍完成任务的情况，同时也不好进行打分？小组中，可以平等的进行开发工作，共同推进项目，并且当不同方面的PM。这样还可以给对方的工作打分，比较公平？

问题四：在小组进行软件工程开发时，如何准确定义“用户”画像？

理论和知识点
考虑用户体验的各种角度，设计的层次，步骤和目标，认知阻力(Cognitive Friction),用户体验的衡量标准，情感设计，跨设备的用户体验。

第十章通常会介绍人物角色（Persona）的构建方法，强调基于真实数据而非想象。第十二章则会深入探讨如何围绕用户需求进行设计，并介绍认知阻力、情感设计等概念，这些都需要一个具体的“用户”作为靶心。

在小组进行软件工程开发时，我们明白需要定义“用户”画像来指导设计和开发。但实践中常常遇到这样的困境：小组成员对“用户”的理解停留在模糊的直觉层面（比如“应该是年轻人”、“应该喜欢简洁”），导致画出来的用户画像要么是“刻板印象的堆砌”（如“张小龙，男，35岁，产品经理，喜欢简洁高效”），要么是“理想化的自我投射”（把自己当成用户）。对于一个资源有限的学生项目小组，有哪些具体、可操作的方法或步骤，可以帮助我们科学地定义出真实、有洞察力的用户画像？并且，这个画像在后续的设计和用户体验评估中，应该如何被有效使用，而不是画完就“束之高阁”？

问题五：小组开发的末期，如何进行有效的测试？

Black Box Test, White Box Test, Code Coverage Test, Unit Test...

在小组开发的末期，我们需要进行有效的测试来确保软件的质量。不同的测试方法有不同的侧重点，我们可以根据项目的需求和资源情况，选择合适的测试方法。但在此时，小组开发进入末期，距离最终演示可能只剩下一周左右的时间，主要任务应该是测试。但我们面临一个典型的困境：教材中介绍了黑盒测试、白盒测试、单元测试、代码覆盖率分析等多种方法，理论上我们应该全面执行以确保质量。但在时间极度紧迫的情况下（大家还要准备其他科目的期末考试），我们不可能全部做完。我的问题是：面对有限的时间和人力，我们应该如何对这些测试方法进行优先级排序？或者说，是否存在一个“最小可行测试组合”，能够在有限时间内最大程度地发现影响用户体验的严重缺陷，同时规避“学期末时间不够，干脆随便点点就提交”的风险？