课程总结

软件工程：4.课程总结

0.作业要求

请各位同学围绕课程理论学习和课程项目实践，总结自己的学习心得体会，并对照第一篇博客所写的期望，整理自己的收获。作为本课程的最后一个博客作业，希望大家认真对待，写出自己的真实想法和感受。

1. 回顾期望与笃信：

1.1 主要的期望 完成情况

1. 【较好完成】结合项目理解并实际运用软件工程的思维方式和建模方法

2. 【较好完成】能够从更抽象的层次去理解一个系统，掌握快速理解系统的能力

3. 【初步入门】能够对架构系统有初步的理解

4. 【较好完成】实践团队分工和合作

5. 【初步入门】未在第一次博客提及的，对设计的思想和方法，也有了从0到1的体会，虽然还有很多不足，但个人感觉确实一只脚已经迈进了门槛

1.2 关键因素 完成情况

1. 【实际大约平均40分钟】精力投入：确保每天两个小时的时间

2. 【较好完成】积极的正反馈：将问题及时抛出，有问题及时提问解决，将大任务细分为多个小任务，按部就班激励自己

3. 【圆满完成】先修课程：重新复习软件工程内容，包括UML和可行性分析等

4. 【圆满完成】心态调整：受挫时不自闭，与老师、mentor、队友沟通

5. 【较好完成】时间管理：预先计划，提前完成

1.3 学习计划：项目-家庭订单工厂 完成情况

1. 【没有落下一节课，但课上还是容易走神，导致课下工作量加大】个人：

　　1. 保证听课质量

　　2. 前期进行家庭订单工厂的社会调研

2. 【超预期完成，主要是队友给力】团队协同：

　　1. 任务分配：前端+建模

　　2. 做好自己，积极建设团队氛围

2. 心路历程：

2.1.课程理论学习及课程项目实践 完成情况概览：

• 课程理论学习
  全程没有落课，认真完成博客及上课小练习，基本掌握课程主体内容，对UML的各种图的适用场景和主要用途基本明确，对需求、设计分析的方法上较为熟悉，在抽象和元建模上有大致概念，但仍需进一步学习。

• 课程项目实践:

基于家庭工厂的订单协作系统：典型的生活日用品制造业往往由一组家庭式工厂协同配合，共同生产和组装，完成最终订单。系统有几个关键功能：【完成】下单(接单)、【完成】订单分解、【完成】订单分配、【完成】订单进度追踪、【完成】订单完成风险评估、【完成】订单完成效果分析等。要求实现基于网页或手机端的系统。

可以看到，最终核心功能都完成了，达到了项目的基本要求。但是最终在展示上确实由于时间关关系，没有仔细分析如何以更好的方式展示我们的核心功能，使得最终展示效果差强人意，在后续的工作中，我们由于各自还有投稿等任务，并没有真的提前放假，所以还是将精力投入到总结和整理报告文档上，没有进一步去迭代，但是心里还是一直想着能够完善一下的。

最初我选择这个题目的初心：选择一个相对简单的项目，能够利用课上所学，从分析到实现，能全过程走完，对真实开发场景下的全流程有基本认识就算成功。最后看来，不仅达到了我的初心，而且在过程中我还有很多额外的收获，包括对具体的需求、设计分析的流程和工具的掌握，对设计的理解、对团队合作的理解和实践。

2.2 领域分析：

当我们选定后题目后，先针对系统是什么进行了讨论。这里主要借助老师提供的模版，让我们有较为明确的思考和讨论方向。

第一次讨论时，我们大致对我们的系统是什么有了基础的认识，但没有记录并同一术语，这为后来的讨论以及分工协作的合成埋下了隐患，增加了我们讨论的成本，过程中的记录是尤为关键的，对关键的讨论结果要有记录，回顾起来，在每次会议前，应该明确会议的议程，需要的关键产出和讨论结果，并且轮流担任记录的方式，这样可能会使合作更加高效。

最初对系统的理解，包括在头几次讨论时，还局限在我们作为一个提供软件解决方案的公司，根据客户需求为他们定制这样一个系统，所有讨论也完全是从需求和功能出发，而忽视了系统的核心价值。

这和真实场景可能类似，一家公司想做这个系统，找我们来做，已经有了一些构想和关键功能的要求，从服务商的角度出发，很容易陷入【完成用户提出的需求即可，而不在乎是否帮用户实现了价值】，这在一开始顺着客户的思路走可能较为简单，易于开展工作，但实际我们发现，用户提出的需求可能并不能很好的满足其核心价值，因此这样的需求易于变动，因此在领域分析时，应当充分思考对于这个领域，我所设计的系统的核心价值在哪里。

除此之外，在实际生产中，为了确保我自己的利益，我是否需要充分为客户着想，还是满足其要求即可，也是软件开发的挑战。这也涉及到我们对系统的定价，在上周的课程中，也进行了讨论。

理想情况下，我们应当充分从客户角度出发，分析出系统的核心价值，为客户最大化利益，从而实现我系统的价值，赚取最大的利润，但这未必能在真实生产中的复杂博弈下开展。

2.3 需求分析：

在认识到我们系统的价值后，核心的用例就是需求拆解和体现，我们首先通过用例图明确了核心用例，对于关键用例，我们采用集体讨论而非分工，从用例和核心业务流程出发，通过状态图梳理并用例规约梳理出业务主流程，此时术语的不规范，让我们沟通多次出现问题，导致理解的偏差，使得有些部分反复讨论在最终明确。

在类图的设计上，可谓绞尽脑汁，一方面是经验不足，另一方面一些用例的具体细节在未讨论清楚之前，类图是不知道怎么设计的。我们在这一部分投入了相当多的时间，大家齐心协力，才最终统一并得到了一个符合直觉和逻辑的设计。

这里我发现核心的困难在于随着细节的进入，使所有人同步变得异常困难，这需要严格的术语规范，并且合理的会议管理，否则一旦走神，很可能会使后续工作出现偏差。

另外，相对于我们这个小项目尚且如此，对于庞大的系统，每个人需要从哪个粒度清晰理解系统也是关键，让所有人对设计的全部内容充分理解并形成统一是不现实的，在后续课程及老师的提示后，我们开始转变，认识到接口是关于职责的划分结果，组员之间通过明确的借口划分职责，对接功能和任务，使得组内合作解耦，并具有更高的灵活度。在这一部分的理解上，我也对技术架构有了初步的理解和认识。

2.4 设计分析：

后面进入设计阶段，我们有了一些经验后，采用了前后端分离scram的开发模式，明确了分工，我负责一部分前端工作，统一了技术栈，然后开始设计接口。这个阶段又是全新的挑战。设计分析三步走：抽象、分解、协议

抽象和分解的关键在于粒度的把握，可以从数据流或是从控制出发，把握抽象和分解。

最后协议的部分，用不变式和OCL来细化约束，执行协议。

我们在设计部分主要抓住这两个工具来进行设计，在已有的类图基础上，抓主要流程，继续细化分析、迭代，但是在借接口的实际上还是经验不足，设计不周全，导致前后端工作量不平衡，项目推进速度缓慢等问题。

3. 心得体会

一学期下来，收获很多，确实很不容易，坚持听课、听懂再实践需要很强的意志力。
最大的幸运就是遇到12345的队友们，据我观察，我们组可能是唯一一个每次课都能全员到场并听课的组吧，也是团队合作氛围和分工最平均最能发挥每个人的价值的团队吧。
感谢佳慧一以贯之的努力，投入大量的时间细致思考，给我们这些直男提供更多的思路，让我们重新重视一些关键部分更细致的思考，纠正了很多马虎大意的错误，更不必说在后端和数据库上的持续努力和付出。
感谢思然全程carry，在最重要的类图上主动担当，认真仔细、负责到底的工作态度是我学习的榜样，让我明白如何做一个靠谱的队友，在开发上也帮了我很多的忙，特别nice，一直非常耐心地帮助水平拉胯的我。
感谢王康担当起队长的角色，在我们停滞不前时，仍不断给我们打气，鼓励我们一直向前，在划分任务和具体分工上挺身而出，让我们能够顺利的推进下去，尤其在项目管理的工具和方法上，有很多个人的思考，使我们的团队合作更加高效。
感谢袁琦在建模过程中的全程同步，和思然配合完成了很多重要的类图迭代和关键设计，充分发挥自己的优势，担任了最重要的核心业务评估和进度追踪等算法的设计工作，并且主动担任演讲者，让我们的设计完整准确的介绍给老师同学，每次都非常严谨并且有条理，可以说是100%地展现了我们的设计。

我自己的话，说起来有些惭愧，感觉自己本应该付出更多，本可以收获更多的，客观上是实验室事情比较多，然后选课也比较顶的原因吧，但主要还是对自己的要求不够高吧。闲的时候多干一点，忙的时候就不太负责任了，有些任务就比较拖延，但大家也一直宽容我，愿意给我时间，真的很感谢大家Orz。

最后就是非常感谢吴老师，每次2:30小时丰富的内容，理论和例子结合让课程完全不脱离实际，并且辅以练习让我们能够参与进来而不是浮在表面，看似不关痛痒的小作业，对我们在开展项目初期摸不着头脑的时候，实际有很大帮助。
感谢吴老师和孙老师每次评审给出清晰的反馈和细致的建议，让我们能够走在正确的道路上，不断完善自己的设计，并且鼓励我们从最开始对整体的把握有很大偏差，到最后较为深入的理解了项目的核心价值以及如何实现这些核心价值。

今天回顾高软一学期以来的各种艰辛，纵使课程学习上其实还有很多要复习和总结的内容，项目也还有很多有待完善的部分，但不论如何，我都不后悔当初的决定，不管当时有多少人劝退我，笑我头铁选了这门课，自讨苦吃地熬了那些个日夜，我觉得我付出了坚持了我收获了，这就够了。