软件工程实践总结——实践出真知

222200207朱骏祥 2024-12-14 21:56:33

这个作业属于哪个课程	软件工程24年秋季
这个作业要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	完成软件工程实践总结&个人技术总结，并完成相应博客
其他参考文献	《构建之法》、CSDN

一、课程回顾与总结
1.1 以前问题思考的博客
1.2 问题再解答
1.2.1 问题1：在一个被认定为“足够好”的软件发布后，得到的用户反馈中，哪些是有用的？什么时候才能将这个软件优化到相对稳定的版本？
1.2.2 问题2：认为软件系统十分复杂是不是因为软件工程还没有充分发展？
1.2.3 问题3：软件开发是年轻人的饭碗，吃的是青春饭？那年纪大的程序员经验丰富但是快速学习能力拼不过年轻程序员的时候该怎么办呢？
1.2.4 问题4：软件的行为和用户的期望值不一样，就一定是 Bug 吗？
1.2.5 问题5：为什么一般不推荐在单元测试中使用随机数增加测试的真实性？
1.3 新问题
1.3.1 任务分配与进度管理
二、 5个阶段中收获的最大的知识或能力
2.1 需求阶段
2.2 设计阶段
2.3 实现阶段
2.4 测试阶段
2.5 发布阶段
三、关于个人项目/结对编程/团队项目理解或心得
3.1 个人项目
3.2 结对编程
3.3 团队项目
四、自我评分对课程目标的掌握度
4.1 目标1：理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。
4.2 目标2：掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。
4.3 目标3：掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。
4.4 目标4：能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。
4.5 目标5：遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。
4.6 目标6：具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。
4.7 目标7：能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。
五、个人技术总结

一、课程回顾与总结

1.1 以前问题思考的博客

软件工程实践暑期作业

1.2 问题再解答

1.2.1 问题1：在一个被认定为“足够好”的软件发布后，得到的用户反馈中，哪些是有用的？什么时候才能将这个软件优化到相对稳定的版本？

回答：在一个被认定为“足够好”的软件发布后，用户反馈中以下几种类型是有用的：

功能反馈：用户对软件功能的评价，包括哪些功能有用、哪些功能不足或缺失。
性能反馈：关于软件性能的反馈，如响应时间、处理速度、资源消耗等。
可用性反馈：用户对软件易用性的评价，包括界面设计、导航流程、帮助文档等。
兼容性反馈：用户在不同设备、操作系统或浏览器上使用软件时遇到的兼容性问题。
错误报告：用户报告的软件错误或崩溃情况，这些信息对于修复bug至关重要。
安全反馈：关于软件安全性的反馈，如潜在的安全漏洞或隐私问题。
改进建议：用户提出的改进意见或新功能建议。
情感反馈：用户对软件的整体满意度和情感反应，这可以提供关于用户忠诚度和品牌声誉的洞察。

至于何时才能将软件优化到相对稳定的版本，这通常取决于以下几个因素：

反馈的频率和严重性：如果用户反馈中包含大量严重的错误或问题，可能需要多次迭代才能达到稳定。
开发资源：开发团队的规模和资源会影响优化的速度和质量。
技术复杂性：软件的技术复杂性也会影响优化过程，复杂系统可能需要更长的时间来稳定。
市场反馈：市场对软件的接受程度和竞争状况也会影响优化策略。
项目管理：有效的项目管理和迭代计划可以帮助团队更高效地优化软件。

通常，软件开发是一个持续的迭代过程，优化和更新是常态。软件可能永远不会完全“稳定”，但可以通过持续的改进和用户反馈来达到一个相对稳定和满意的版本。

1.2.2 问题2：认为软件系统十分复杂是不是因为软件工程还没有充分发展？

认为软件系统十分复杂并不是因为软件工程还没有充分发展。软件系统的复杂性是由多种因素造成的，这些因素包括但不限于：

需求变更：随着时间的推移，产品需求会不断变化，这些变化可能需要对现有系统进行修改或添加新功能，从而增加了软件系统的复杂性。
技术选型：选择不合适的技术栈或架构模式可能会导致系统的过度复杂化。
规模扩大：随着业务的发展，软件系统可能需要处理更多种类的数据和用户，这会导致系统规模的扩大。
不完善的设计：缺乏清晰的系统设计和架构规划可能导致系统出现混乱和复杂性。
依赖性问题和代码模糊性问题：这些问题是复杂性的主要原因，经常相互交织，导致软件系统变得难以理解、维护和修改。
软件管理工程的特殊性：软件是知识产品，进度和质量都难以度量，生产效率也难以保证。软件系统复杂程度也是超乎想象的。

软件工程的发展已经取得了显著的进步，包括软件过程管理、组件化软件工程等方法和技术的应用。然而，由于软件固有的复杂性、易变性和不可见性，软件开发周期长、代价高和质量低的问题依然存在。因此，软件系统的复杂性并不是因为软件工程没有充分发展，而是由于多种复杂因素的综合作用。

1.2.3 问题3：软件开发是年轻人的饭碗，吃的是青春饭？那年纪大的程序员经验丰富但是快速学习能力拼不过年轻程序员的时候该怎么办呢？

软件开发确实需要持续学习和适应新技术，但这并不意味着年纪大的程序员就没有竞争力。相反，经验丰富和知识深厚的程序员在许多方面仍然具有显著优势。以下是一些应对策略：

持续学习：不断学习新技术和工具是保持竞争力的关键。年纪大的程序员可以通过在线课程、技术书籍、研讨会等方式来更新自己的知识库。
利用经验：经验丰富意味着拥有解决复杂问题的能力和丰富的项目管理经验。这些是年轻程序员难以比拟的。
团队合作：在团队中发挥领导和指导作用，利用自己的经验指导年轻程序员，同时从他们那里学习新技术。
专业领域：选择一个特定的技术领域进行深入研究，成为该领域的专家。这样可以在该领域内保持竞争力。
软技能：除了技术能力，沟通、项目管理、团队协作等软技能也很重要。年纪大的程序员通常在这些方面更有优势。
适应变化：保持开放的心态，适应行业变化，愿意尝试新的工作方式和工具。
健康生活：保持良好的身体和精神状态，以便能够应对高强度的工作和持续的学习。
职业规划：制定长期的职业规划，考虑从技术岗位转向管理或咨询岗位，这些岗位通常更看重经验和综合能力。
网络建设：建立和维护专业网络，这有助于获取行业信息和职业机会。
心态调整：认识到年龄不是限制，而是经验和智慧的积累。保持积极的心态，相信自己的价值。

总之，年纪大的程序员可以通过多种方式来应对快速变化的技术环境，保持自己的竞争力和市场价值。

1.2.4 问题4：软件的行为和用户的期望值不一样，就一定是 Bug 吗？

软件的行为与用户的期望不一致，并不一定就是 Bug。Bug 通常指的是软件中由于编程错误、设计缺陷或其他原因导致的不符合预期功能或行为的问题。然而，用户期望与软件行为不一致的情况可能由多种原因造成，以下是一些可能的情况：

Bug：如果软件的行为违反了设计规范或功能需求，那么这确实是一个 Bug。
用户误解：用户可能对软件的功能或操作方式有误解，导致他们对软件的期望不正确。
需求不明确：在软件开发过程中，如果需求没有被充分理解和明确传达，可能导致软件行为与用户的期望不符。
用户期望变化：随着时间的推移，用户的需求和期望可能会发生变化，而软件可能还没有更新以适应这些变化。
文档不清晰：如果软件的文档或用户指南不清晰，用户可能会对软件的行为有错误的预期。
环境因素：软件的行为可能受到运行环境的影响，例如操作系统版本、硬件配置等，这可能导致行为与预期不符。
配置问题：软件的行为可能受到配置设置的影响，错误的配置可能导致不符合预期的行为。
兼容性问题：软件可能与某些系统或第三方应用不兼容，导致行为异常。

在确定是否为 Bug 之前，需要进行详细的分析和测试，以确认问题的根源。如果是由于软件本身的缺陷导致的不符合预期的行为，那么这确实是一个 Bug，需要进行修复。如果是由于其他原因，如用户误解或需求不明确，可能需要通过用户教育、需求澄清或文档更新来解决。

1.2.5 问题5：为什么一般不推荐在单元测试中使用随机数增加测试的真实性？

一般不推荐在单元测试中使用随机数增加测试的真实性，主要原因包括：

可重复性：单元测试应确保每次运行时结果一致。随机数会导致输入不固定，从而使测试结果不可预测，难以判断代码是否正确。
可预测性：测试应该是确定性的，即给定相同输入时，输出相同。随机数破坏了这一原则，增加了调试难度。
覆盖性：随机数可能无法覆盖所有边界条件和特殊情况，而这些是单元测试重点关注的内容。
可维护性：依赖随机数的测试用例在代码或测试条件变更时，可能需要调整随机数生成逻辑，增加了维护成本。

尽管随机数在某些特定测试场景（如模糊测试）中有其用途，但这些场景通常不属于传统的单元测试范畴。因此，单元测试更倾向于使用固定、已知的输入，以确保测试的可重复性和可靠性，从而更有效地验证代码的正确性。

1.3 新问题

原来的问题基本上都解决了，不过出现了以下的新问题：

1.3.1 任务分配与进度管理

项目进度可能因意外事件而受阻，同时需要在不过度施压的情况下激励团队成员按时完成任务。

二、 5个阶段中收获的最大的知识或能力

2.1 需求阶段

在需求分析阶段，我掌握了与用户有效沟通的关键技巧，学会了如何收集和整合他们的反馈。我深刻认识到理解用户的真实需求和期望对于项目成功至关重要。此外，我还学习了如何撰写需求文档，确保文档内容清晰、具体且可追溯，为后续的设计和开发工作奠定坚实基础。

2.2 设计阶段

我学会了如何将用户需求转化为初步的项目设计，并在团队协作中不断完善方案。根据用户的反馈和团队的讨论，我们明确了游戏的目标和风格，并结合各组成员的意见，最终确定了游戏的核心设计方向。

风格设计

在初期的讨论中，我们希望游戏能够体现出校园生活的真实与趣味。经过查阅大量类似题材的游戏案例，并参考目标用户群体的喜好，团队决定采用3D 半开放世界的形式，力求重现福州大学的校园风貌。这种风格不仅能满足高沉浸感的需求，也能增强新生和校友的代入感。

游戏视角设计

团队对游戏视角展开了激烈讨论，权衡了多种可能性，如完全开放的第一人称视角或传统的固定俯视视角。最终我们选择了一种自由探索的第一人称视角，既能够让玩家欣赏到校园全景，也能在执行任务时感受到环境的互动性。这一选择在后期还需根据玩家反馈进一步优化。

系统功能设计

任务系统设计

任务系统是游戏的核心之一。我学习了任务状态管理和任务的动态展示设计，为此我们设计了主线任务与支线任务的分类。初期方案希望任务种类丰富、流程复杂，但团队商议后决定保持简洁，突出校园主题任务，降低开发难度。

团队协作与决策

在设计过程中，我深刻体会到团队协作的重要性。从风格选择到系统功能规划，我通过与队友反复讨论、调整方案，将个人想法融入到团队的集体决策中。这不仅锻炼了我的沟通能力，也让我认识到需求分析与用户体验设计的关键性

2.3 实现阶段

在实现阶段，作为组长兼策划，我承担了多重角色和责任。我们的小组共有9名成员，虽然团队中存在一些成员参与度不高的情况，但这并没有影响到我们的整体进度。

作为组长，我不仅要负责项目的整体策划和协调，还要亲自参与到场景搭建，脚本编写等具体工作中。我根据每个成员的长处将他们分成小组，并在开发过程中密切关注各个小组的进度。我充当了沟通的桥梁，确保信息在各个小组之间顺畅传递。

在开发过程中，我遇到了各种问题，但通过与团队成员的积极交流和协调，我们逐渐克服了这些困难，使队员们能够更专注于创作，相互之间的沟通也变得更加频繁，团队之间的默契得到了显著提升。

尽管面临挑战，我始终坚持我的职责，确保项目的顺利进行。通过这次经历，我学会了如何在压力下保持冷静，如何有效地管理团队，并从中获得了宝贵的经验。这个实现阶段对我来说是一个成长的过程，它不仅提升了我的个人能力，也加深了我对团队管理和项目实施的理解。

2.4 测试阶段

在测试阶段，我经历了从游戏开发新手到熟练掌握测试流程和工具的转变。起初，我对游戏测试知之甚少，但通过积极的学习和实践，我逐渐掌握了这一领域。

我首先在网络上搜集了大量的游戏测试资源，阅读了许多有帮助的帖子和文章，这些资料为我提供了理论基础。同时，我也利用AI的帮助，获取了关于游戏测试工具和流程的详细指导。通过结合网络资源和AI的建议，我逐步了解了游戏测试的各个方面，包括功能测试、性能测试、用户体验测试等。

通过这个阶段的学习和实践，我不仅掌握了游戏测试的基本技能，还学会了如何系统地分析和解决问题。我意识到测试不仅仅是发现bug，更是确保游戏质量的重要环节。这个过程不仅提升了我的专业技能，也让我对游戏开发的整个流程有了更深刻的理解。

2.5 发布阶段

发布阶段我使用Unity自带的打包功能进行打包

三、关于个人项目/结对编程/团队项目理解或心得

3.1 个人项目

这个学期的两个独立项目让我获得了丰富的经验和深刻的感悟。

第一个项目的目标是收集有关巴黎奥运会的数据。这不仅是本学期软件工程实践的首次正式项目，也为整个学期的实践活动奠定了基调。项目的节奏迅速，我不断地经历着一个循环：识别问题、吸收新知识、尝试实施、解决问题或调整策略。除了表面上掌握的新技能，比如解析JSON数据、软件打包、通过命令行执行程序、进行单元测试等，我更显著地提升了自己解决问题的能力，并且更加清晰地认识到自己的短板。

第二个项目是对四个不同的人工智能平台进行评估。这次实践让我深刻体会到AI的潜力，它能极大地简化许多基础任务。然而，我也意识到AI并非无懈可击，我们不能盲目依赖它的输出，必须对其结果进行细致的审查。在未来的学习中，我将学会利用AI作为学习新知识的辅助工具，同时保持批判性思维和独立分析的能力。

3.2 结对编程

协作编程是敏捷软件开发领域的一种工作模式，它要求两名开发者携手合作，共同完成一项编程任务，共享一台电脑。这种编程方式中，两名开发者分别承担“编码者”和“审核者”的角色：编码者（Coder）：编码者是负责敲代码的成员，他们将项目需求转化为具体的代码实现。他们需要思考代码逻辑、编写代码、调试程序以及进行测试等；审核者（Reviewer）：审核者的任务是监督编码者的工作，他们提供反馈、进行代码审查、识别潜在的错误或问题，并提出改进的建议。

在我们小组的实际项目中，我们通过紧密合作成功地完成了任务。我认为这种协作编程的经历为我们后续的团队项目奠定了坚实的基础，教会了我们如何与团队成员有效沟通、如何协同工作以及如何合理分配任务。在协作编程的过程中，我们的团队实现了许多单独作业难以达到的优势，比如：知识的交流与技能的传授、及早发现并修复错误、设计思路的多元化以及提升代码的可读性和可维护性等。当然，协作过程中也难免会有意见不合的时候，当团队成员的想法出现分歧时，我们必须找到解决之道，以确保项目目标的统一和实现。

3.3 团队项目

在《相约福大》游戏项目中，我同时担任了项目经理和后端开发的角色。这是我第一次以全局视角参与到一个复杂的大型游戏开发项目中。从需求分析到原型设计，从开发测试到项目部署，每个环节我都或多或少参与其中，并且站在负责人的立场上对各种问题进行权衡与决策。这次经历让我对项目管理与团队合作有了更加深刻的理解和实践体会。

1.站立式会议与高效沟通

我们在开发过程中采用了每日站立式会议的形式，快速汇报进度与解决问题。这种高效的沟通方式让我能及时掌握项目各模块的开发状态，并为需要协作的任务提供支持。站立会议成为团队交流的重要纽带，减少了误解和工作延误，极大地提高了开发效率。

2.明确分工与责任落实

根据队员的长处与特长，我将团队划分为不同的小组，明确各自的分工和职责。同时，我时刻关注队员的心态和状态，及时调整任务分配，帮助他们解决遇到的困难。这不仅提升了团队的凝聚力，还让每个成员能够更专注于自己的核心任务。

四、自我评分对课程目标的掌握度

4.1 目标1：理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。

评分：99
在本次实践中，我严格遵守了职业道德规范和实践要求，尽可能地保障项目质量，消除潜在风险。当下大家对于独立游戏的喜爱逐年上涨，人们对于独立游戏有很大的需求。我在积极了解人们的需求之后再努力设计满足用户的软件，并在开发中尽力实现。同时项目中未有不符合时代风气、与人文相反的元素。

4.2 目标2：掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。

评分：96

我能够熟练地运用Axure XP9来进行原型开发，以充分、准确地理解客户的需求.

4.3 目标3：掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。

评分：96

在我们的团队项目中，软件设计阶段是一个关键环节，我们精心打造了系统的架构设计、数据模型设计以及组件级别的设计，并将这些设计详细记录在文档中。随后，我们组织了团队内部的评审会议，对这些设计模型进行了深入的讨论和反复的打磨，以确保我们的设计方案能够精准地满足项目需求。

4.4 目标4：能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。

评分：93

在软件开发的过程中，我不仅掌握了从组件层面到整个软件系统的综合技术评测能力，还培养了对设计模型进行深入评判的专业素养。这种能力使我能够全面分析和评估不同设计方案的优劣，从而做出明智的选择，优选出最符合项目目标的方案。
我学会了如何从技术可行性、性能指标、用户体验、可维护性等多个维度对设计方案进行综合评估。这不仅包括对现有设计方案的分析，还涉及到对潜在风险的识别和预防措施的制定。我能够识别设计中的瓶颈和不足之处，并提出切实可行的改进建议。

4.5 目标5：遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。

评分：94

在本学期的项目实践中，我积累了丰富的经验，特别是在编写需求规格说明书、系统设计说明书以及系统测试报告等方面。在着手撰写这些文档之前，我总是投入时间深入研究相关的文档编写标准，确保自己对软件开发流程中各个阶段的文档要求有透彻的理解。我努力掌握每种文档的结构框架、内容要点以及遵循的标准化写作规范。
在文档撰写过程中，我特别注重使用精确而规范的语言，关注每一个细节，以确保文档的准确性和专业性。通过不断的学习和实践，我逐渐精通了文档编写的技巧和方法，这不仅提升了我的文档撰写能力，也增强了我对软件开发文档重要性的认识。