围绕课程理论学习和课程项目实践，总结自己的学习心得体会，整理自己的收获。
在课程之初，正式开始项目之前，写了这门课的第一篇博客——期望与笃信；对自己进行了简单的剖析并提出了自己的目标以及方案计划；总结起来就是，寻求三个方面能力的提升
- 团队协作
- 技术积累
- 建模
而这三个能力又体现在以下六个方面：
- 对软件工程过程的认识与理解
- 行业自信
- 知识体系重构
- 代码能力
- 文档能力
- 团队合作
接下来我将就本学期项目开发的整个过程，对照以上几点，整理自己的收获与不足，以期在接下来的学习生活中寻求更好的发展；
同样的还是回顾一下这学期的项目：
项目内容：基于订单的家庭工厂协作系统（需求、设计、实现和测试）
典型的生活日用品制造业往往由一组家庭式工厂协同配合，共同生产和组装，完成最终订单。系统有几个关键功能：下单(接单)、订单分解、订单分配、订单进度追踪、订单完成风险评估、订单完成效果分析等。要求实现基于网页或手机端的系统。
对软件工程过程的认识与理解
纵观整个建模和开发过程，从领域分析，需求分析，到设计建模再到编码实现和测试过程；可以发现，我们要做的软件开发目的是为了做出一款提高效率、解决问题的软件；那么这其中每个部分所起的作用是什么呢？
领域分析要回答的问题是:
-
系统的核心价值是什么？
-
系统的范围包括哪些方面？
-
系统涉及的核心数据有哪些？
需求分析，是在发现用户痛点后，通过分析，发现用户实质性需求。然后方便在实际产品中，通过合适的方式来满足用户需求。
换句话说，领域分析是要精准定位核心价值与用户痛点；需求分析是要提炼用户实质性需求，并方便满足。
需求分为用户需求和产品需求。
用户需求是用户从自身角度出发，自以为的需求。用户经常提出的需求，从他们角度而言都是正确的，但更多是从自身情况考虑，对于产品的某个功能有自己的期望，但对产品定位、设计的依据等情况不了解，他们的建议也许并不是该功能的最好实现方式，也就不足以直接作为产品规划的直接依据。
产品需求是提炼分析用户真实需求，并符合产品定位的解决方案。解决方案可以理解为一个产品，一个功能或服务，一个活动，一个机制。
需求分析要回答的问题是:
从用户提出的需求出发，挖掘用户内心真正的目标，并转为为产品需求的过程。
在项目开发过程中，吴老师承担了用户的角色，给我们的项目提出了很多宝贵的意见；虽然吴老师不是真正意义上的用户，但是很多意见却提得十分有价值；我发现这背后的原因是吴老师对相关领域有十分充分的了解，能最大程度上的从实际出发考虑问题，提出问题，并引导我们给出解决方案。这也充分说明了一个精确的领域分析是十分重要的，值得我们好好学习。
总的来说，需求分析就是要把用户要干什么变成产品要干什么。
软件详细设计阶段要干什么?
在需求分析阶段主要确认了待开发系统的核心价值,而在设计阶段就要考虑如何让这些核心价值"落地",落到实处,可以真真切切的体现在软件的设计细节上,是一个将想法落到实处的过程。
确定软件系统的总体布局，各个子模块的功能和模块间的关系，与外部系统的关系，选择的技术路线。有一些研究与论证性的内容; 对概要设计的进一步细化，一般由各部分的担当人员依据概要设计分别完成，然后在集成，是具体的实现细节。是“程序”的蓝图，确定每个模块采用的算法、数据结构、接口的实现、属性、参数。
在上一篇"设计也可以按图索骥"中，我曾经有这样的论述：
设计阶段可以参照的模式规范是什么？
- 以需求分析为指导，以核心价值落地为目标，以不懂业务的程序员可以顺利开发为评判准则
- 以架构图描述技术框架，以用例图描述需求，以类图、组件图、顺序图、状态图描述系统细节和运行时各状态情况，以OCL来约束对一个模型或者系统中的一些值的限制
- 以业务流程分析与风险控制来说明业务与规避风险
总结来说，就是：业务分析+UML+OCL；
在我之前的认知中，设计人员需要懂业务，并将其以正确地体现在设计模型中，以便不懂业务的开发人员在不需要投入时间成本了解业务的情况下也能正确的进行开发，这也是衡量一个设计模型优劣的标准。吴老师提到“要开发出真正有用的产品，团队所有人员都应该理解业务”，“设计人员可以不懂开发，但是开发人员一定要懂业务”；起初我是不太理解的，但是后来我发现其实并不矛盾；设计人员将业务流程体现在设计模型中，开发人员则根据设计模型充分充分了解了业务，从而可以让需求精准落地。设计人员通过设计建模让开发人员懂业务，这是协调统一的。
行业自信与知识体系重构
随着互联网浪潮的翻涌，学习和从事互联网行业的门槛降低，带来的是竞争压力的加剧，如何培养提升自己的核心竞争力，在互联网浪潮中站稳脚跟是亟待解决的问题。同时，很多内容之前也曾了解过，不过现在也印象不深，更像是一团乱麻，面对问题时，也不能有效地理出头绪，没有对过去的知识结构进行重新的整理与归纳。
上述提到的两个问题一直是我对自己不够自信的原因，这次课程让我对软件工程过程有了更深入的认识，也深刻体会了软件工程本身的价值所在，相信软件开发人员在计算机行业中还是比较吃香的。第二个问题则主要体现在以往使用UML工具或者相关框架时，只是停留在使用它完成任务而已；并没有体会它背后的作用与价值，它使用与哪一个环境，它的优势和劣势，这些都是我之前不曾考虑到的；自然对这些工具框架和相关知识印象不深，一团乱麻；其实每个过程所需要使用到的相关技术和工具都是有很大关联的，最重要的作用就是充当前后两个软件工程过程的纽带，前一个过程处理的好坏，极大的影响了后面的过程；处理不好甚至要全局推翻重来。
其次是整理归纳的能力，知识的内化是一个输入，消化吸收再产出的过程，以往我往往忽视了这个产出的过程，知识只进不出，始终不是自己的；虽然这门课结束了，但是不得不说，博客总结是一个值得坚持的好习惯。
代码能力
不管是搭架子还是实现某个具体功能，就我目前来说，还并算熟练的程序员；自认为目前还停留在这样的阶段：
读懂代码，能看懂代码，能根据需求实现功能。但具体原理不是太清楚，不太清楚的意思是：不知道怎么用好，怎么用不好，存在什么隐患，有哪些亮点。写出的每一句代码，未必有理由，修修改改能得到正确的输出结果或实现相应的功能。有一定的可复制的方法或流程，去完成相似的事情；
会在以后的项目开发过程中不断精进提升，尽量写出的每一句代码，都有理由，自问自答可以解释上一级别不确定的问题，并形成一家之言；
文档能力
十分重要的一点，搞清楚文档的作用是什么？
- 文档要说明一个什么问题？
- 文档给谁看？
- 文档的什么类型的？
同时也需要参考一些模板，但是要搞清楚模板每一部分的作用，取其精华，去其糟粕，为我所用；
最后UML建模工具一定要熟练且准确，才能用文档把问题描述清楚，把方案表达清楚。
团队协作
整体来说，我比较认可当前小组的合作模式；是一种去中心化的模式，虽然有名义上的组长，但其实人人都可以是组长，每个人都可以根据项目需要和小组成员时间来组织开会或者是分配任务；这整个过程中，我们虽然没有对每个人的具体角色定位做明确安排（比如说产品经理、设计人员、开发人员这种割裂开的模式），但是每个人都有自己重点负责的内容，同时每个人之间的工作又是相互关联，相互依赖的，这就意味着每个成员都有着十分的参与度，虽然这看起来很浪费时间，但是整体来看，效果还是不错的。
小组合作遵循这样的模式：
- 小组讨论，确定大框架
- 成员分工，细化小细节
- 小组开会，互相评审
- 迭代优化，直到到达目标效果
每周两次组会也是保证进度一致推进的保障。
同时冷静客观的沟通也是团队协作的基石。
最后
感谢吴老师和孙老师的细心指导和教诲，感谢队友们靠谱认真的为项目付出时间和精力❤️。