软件工程实践总结-化整为零，化零为整

221900339_张昀学生 2022-06-26 22:25:05

这个作业属于哪个课程	班级的链接
这个作业要求在哪里	作业要求的链接
这个作业的目标	课程回顾与总结、个人技术总结
其他参考文献	构建之法

第一部分-课程回顾与总结
1.1 老题新做
【Q】:顾客真的知道他们想要什么吗？
【Q】:在校学生如何为成为一个PM做准备
【Q】:作为”卑微“的乙方，开发团队该如何面对变化无常的需求？
【Q】:从小部分人出发而瞄准的用户群体真的能够带来较大的商业价值吗？
【Q】:非典型用户是否不是软件的服务对象？
1.2 五个阶段中的收获的知识与能力
需求分析阶段
设计阶段
实现阶段
测试阶段
发布阶段
1.3 三类项目中的收获与心得
个人项目
结对项目
团队项目
1.4 七大课程目标的掌握程度
1.5 拜拜，软工实践
第二部分-个人技术总结
2.1 技术学习进展与开发角色
2.2 技术总结

第一部分-课程回顾与总结

1.1 老题新做

这里是原来提问的博客链接

【Q】:顾客真的知道他们想要什么吗？

【A】:顾客作为软件的使用者，更多的是从结果和表面的形式出发对需求进行定义，通常是直接表达最表层的需求，所以未必明晰。作为利益的相关者，顾客向软件团队表达出来的需求更多基于交易结果等角度，单纯表达了顾客对于软件的主观态度和个体定性，缺乏结合行为和定量的分野。顾客追求良好的结果，也会希望拥有比较丰富的功能，但容易角度受限在表层。

~这个问题在团队实践过程中也遇到了，在实践过程中我们的角色同时是甲方和乙方。从提需求角度思考时，有一个很局限的角度是希望自己的产品越丰富越好，但是在最后实现过程中因为考虑到实用性砍掉了很多花里胡哨的功能。
新问题：如何很好的弥合顾客对于结果的高期待和软件开发的局限？
【Q】:在校学生如何为成为一个PM做准备

【A】:PM作为偏向经验导向的岗位，对于项目的经验要求较高。通过查看PM的相关JD可以发现，这个岗位对于应聘者的逻辑思维以及沟通能力语言表达的素质要求较高；此外，原型图和PRD文档的输出是一个PM的基本素质。作为在校大学生，可以更多参与到项目实践中去，积攒产品运营经验；熟练掌握原型图、流程图的制作；阅读相关书籍，提高思维逻辑表达能力。此外，像选择编程语言一样尽早明确自己感兴趣的PM细分领域对相关领域进行学习也很重要（以及，认真参与到软工实践当中！！）

~在这次实践中也积极承担PM的相关工作，锻炼相关的沟通能力和输出能力。
新问题：在校学生如何接触了解到各类不同的pm细分领域？
【Q】:作为”卑微“的乙方，开发团队该如何面对变化无常的需求？

【A】:首先需要审核“变化无常的需求”的可靠性和可行性，也就是这个需求是真的和初始需求存在差距，还是只存在表达上的区别；保证需求变化合理的前提下，其次考虑可行性，也就是需求变化会带来多少新增的工作量和代价。当然，最好的方式还是在一开始多花时间做好沟通，例如，可以通过前期的访问团队深入面谈了解顾客初期阶段的需求，弥合两方对于部分定义的理解差距。或者可以通过快速原型法，以直观的形式将初期的成果快速呈现给甲方以便后续迭代，且快速原型的形式减少了其中不断修改的迭代成本、时间成本。

~在本次实践过程中，作为PM其实在很多时候也很想提出新的要求和需求，但是通过审慎的思考感觉其实很多时候跟预想其实没有差距，也便作罢。
新问题：对于不得不加、不得不改的新需求，如何以最少的返工成本进行修改？

【Q】:从小部分人出发而瞄准的用户群体真的能够带来较大的商业价值吗？

【A】:显然不是只有面向绝大多数用户群体的软件才能称得上具有商业价值。许多小众领域的软件之所以能够取得商业价值，获得相关人群的关注和使用，并且达到后期的商业价值转换，正是因为其对于目标人群和其特性的定位准确，对其特定需求和了解细致，才能够有针对性、创造性的开发软件。我想对于商业价值而言，更重要的是对于小部分人目标人群的定位，并结合开发前期对于商业模式的确认。

~我们在实践过程中的目标群体定位就是针对大学校园的电动车驾驶员和校园交通管理工作人员，并且从目标群体出发进行需求分析和商业角度分析，可以看出校园电动车在总体的电动车市场中占比不大，但是仍然有一定的占比，存在相应的需求和商业发展潜力。
新问题：如何较为准确科学的进行用户群体的量级估计？
【Q】:非典型用户是否不是软件的服务对象？

【A】:非典型用户具有“网络白痴”、“学习欲望极弱”、“抗拒网络产品”等特点，所以不论我们如何迭代产品，对这一类用户使用与否、使用习惯都不太能产生过多的影响，那么此时可以将此类用户归类于非典型用户，很显然的，如果为了不断迎合取悦这一类的用户不断修改功能等，必要性不大，ROI极低。另一种情况是，极小概率事件。如残障人士对软件的使用不便，但是此类人群比例较小，且不论修改之后是否能真正解决问题，软件的重新规划成本有多高，单论利益结果，解决小概率事件对于软件盈利杯水车薪。这种情况下，与其迭代软件解决小概率事件，不如面向小众群体研究新方向。总之，对于软件的非典型用户而言，ROI是很重要的考虑因素。还有一部分非典型用户的需求与软件功能存在一小部分交集，但从比例而言，满足好目标人群用户的需求是我们最大的任务，如果因为存在交集就不断扩张产品的服务内容，软件最后会成为一个庞杂的四不像。

~非典型用户显然不会满足于软件功能，就例如在实践过程中，我们不会集中于汽车驾驶员的校园交通需求，而是主要关注校园电动车驾驶员的停车需求。
新问题：软件产品要如何避免庞杂不清的功能设计？

1.2 五个阶段中的收获的知识与能力

需求分析阶段

在实践中结对项目中和团队项目中需求分析都是由我负责，我认为在需求分析过程中，结果导向是很重要的思维。通过两次的需求分析任务，不论是前期对于用户画像的绘制，还是在过程中模拟用户角度进行需求分析绘制原型图，都一定程度上加强了我提出需求、审核需求、展示需求的能力，提升了我需求分析的能力。

设计阶段

个人/结对/团队项目中其实都少不了概要和详细设计。由于个人项目和结对项目的设计较为简单，所以并未输出文档，主要针对接口、全局数据、数据库进行了简单设计。而在团队项目中，严谨的设计在产品的开发周期中显得尤为重要，需要一开始就明确产品效果以及使用的算法所需要的环境支持，做好系统环境的准备；此外，数据库结构的设计经过全体开发人员开会对接后进行设计，会更合理，可以避免不必要的返工。

实现阶段

编码实现阶段是收获最大的部分，“learning by doing” 的见效最快。个人项目阶段对于完整的软件开发流程与标准有了较为全面的认识；结对项目中学习了vue框架和elementUI组件的使用，同时对于前后端的合作有了进一步了解，对git的使用也更熟悉；在团队项目中，进一步熟悉vue框架和elementUI组件的使用，对于合作过程中的代码规范有了新的理解。

测试阶段

测试也是一项大工程，需要从多个维度出发进行测试。在软件测试作业中，我们使用了黑盒测试，也就是作为用户对软件进行分析设计，不仅可以从页面、路径出发进行测试分析，还需要从性能和数据极限值进行分析设计。在个人项目中接触了白盒测试，单元测试，两类的测试让我对如何保证软件质量有了新的理解

发布阶段

软件的发布并不意味着结束，也不意味着产品已成功上线，发布后紧接着需要面对用户的各类意见以及解决测试中并未发现的BUG，同时也需要对产品进行第一次分析与迭代，针对第一批用户提出的问题进行分析，进行后续的开发会议。

1.3 三类项目中的收获与心得

个人项目

个人项目的综合程度和实践实用度相较于之前的课设都有一定的提升。不论是git的使用还是对于接口的设计都更科学。一开始其实还是对个人项目感觉有点畏惧不知道怎么下手，对于作业要求感到很陌生，不知道如何进行单元测试、设计数据并提升性能，但慢慢按照顺序一个个学习然后下手也慢慢解决了一个个问题，也算通过学习获得了正向反馈捏。

结对项目

结对项目是一次和队友合作开发的经历。相对于自己开发，结对合作需要一定的沟通合作以确保前后端对接顺利。在结对项目中进一步熟悉AXure原型设计工具的使用，技术上也接触到了vue框架和elementUI组件。由于在结对项目期间对于vue框架理解不到位，还熬了一个大夜缝缝补补，好在最后页面的还原度还算比较高，功能也完整实现了，feeling sooooo goood。

团队项目

在团队项目中我主要负责了pm和web端开发的部分工作。在需求分析阶段，跟之前两次项目不同的地方在于一个是沟通量大大提升，需求细节需要让开发成员都能够统一理解，弥合一些词语的理解差距，需求展示形式有功能架构图、文档和原型设计图；另一个不同的地方在于项目具有更加具体的适用人群，适用范围更具体，需要更详细的进行市场分析和用户分析等。在开发阶段，由于功能和UI上相较于结对作业都更为复杂，对于vue框架的使用也更复杂了一些，进一步熟悉掌握了Vue框架和elementUI的使用。在团队项目中，我经历了一套较为完整的软件开发流程，对于软件团体的开发有了初次较为成熟的理解；沟通量也相较于前两次作业有提高，包括和前端同学交流原型实现和参数，对接口等等，最终项目也算圆满完成，蛮有成就感的！

1.4 七大课程目标的掌握程度

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

评价：通过理论课和实践课学习，对于软件开发工程师的职业道德有了比较深刻的理解，在众多负面案例中提取分析并进行自我审视；对于当前市面上的软件风向和开发理念接触学习，并应用到三次软件开发项目当中。
目标2： 掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。

评价：对于需求分析有较为深刻的理解，对于客户的各类表达可以进行统一概括分析，并进行表达展示；熟悉使用NABCD模型进行需求分析，熟悉掌握Axure和墨刀等原型工具的使用。在结对项目和团队项目中负责了产品的需求分析工作，对于需求分析的多维度有一定理解。
目标3： 掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。

评价：通过结对项目和团队项目的合作开发，对于软件的开发体系过程以及在开发前期的概要设计和模型设计有一定理解，在团队项目中参与到软件的概要以及详细设计文档书的书写中。
目标4： 能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。

评价：对于团队所使用的软件技术有一定了解，熟悉使用的组件以及技术的优点以及限制所在。以前端为例，结对项目和团队项目选取了目前较为成熟，对于各类组件包容度较高的vue框架；技术测评上，对于白盒测试中的单元测试和集成测试系统测试有一定的了解，熟练掌握黑盒测试。

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

评价：在团队项目中参与各类文档书的书写，了解文档标准的规范表达和各阶段文档的具体内容，了解各阶段文档目的。
目标6： 具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。

评价：协同队长进行团队合作，具有团队合作意识。作为pm能够合理输出需求展示需求，沟通效果与参数；作为web端开发人员同后端接洽对接，完成开发任务。

目标7： 能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。

评价：了解包括人员构成与职责、风险管理在内的软件项目管理中的设计要素，通过实践与理论学习对于软件规模和工作量的估计有了新的了解。掌握PSP表格的使用。

目标	评分
理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。	92
掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。	92
掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。	85
能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。	89
遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。	89
具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。	92
能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。	86

1.5 拜拜，软工实践

在软工开始之前对于软工实践其实是比较敬畏且畏惧的状态，常常听学长姐抱怨软工秃头于无形，很担心自己的开发经验不足，会在结对和团队开发中感到吃力且拖后腿。但是learning by doing，其实很多时候真正拖后腿的是摆在一项新技术前的陌生与敬畏，靠近并接触实践之后，才能“祛魅”，才能掌握并应用。

感谢自己认真完成了每一项软工作业，获得了一件小白衫；感谢结队队友的帮助，感谢团队项目的伙伴靠谱又有趣，让我能够应用自己的技术完满地完成结对和团队项目。

标题叫“化整为零，化零为整”。把一项“庞大”的任务拆解后，“祛魅”后，一项项地学习并应用，这叫化整为零；在一次次软工实践作业的学习和应用后，完满地结束了团队项目和软工实践，我想这叫化零为整。一年前看似庞大的山在回首间也变得开阔了。

最后感谢傅老师和各位助教在软工实践期间的指导与帮助~~

第二部分-个人技术总结

2.1 技术学习进展与开发角色

寒假给自己定制的学习路线主要以前端和PM技能为主。前端学习上，综合考量了使用广泛度、技术成熟度、框架发展前景等，选择学习的框架由react转为vue，并达到了熟悉掌握可以应用于项目的程度。pm学习上，坚持阅读网站内容。总体上完成了预期的学习目标。在主要担任了web端开发人员的角色，负责了部分web端界面渲染和交互。