个人作业——软件工程实践总结

作业要求


所属课程	软件工程1916-W(福州大学)
作业要求	个人作业——软件工程实践总结作业
所在团队	基于云的胜利冲锋队
学号	221600416
作业目标	软件工程实践总结

一、请回望开学初的第一次作业，你对于软件工程课程的想象

1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？

开篇博客中我写道:"我的期待是在软件工程实践中可以提高我的编程能力，巩固过去两年多来学习的编程知识，并学习新的知识来迎接在课程中不断遇到的新的挑战，并且在团队合作中磨砺自己的沟通与交流的能力，最好可以认识一些兴趣相投或者能力互补的伙伴"，我觉得在编程能力，团队沟通方面得到锻炼。但是由于开发的语言框架以前已经学过，所以在学习新知识方面没有达到期望。

2）总结这门课程的实践总结和给你带来的提升，包括以下内容：

1.统计一下，你在这门软件工程实践中，完成了多少行的代码？
结对编程和团队编程总计大约5k+行。

2.软工实践的各次作业分别花了多少时间？（做一个列表）

作业名称	时间/h
第一次作业——准备篇	2
结对第一次—原型设计（文献摘要热词统计）	4
结对第二次—文献摘要热词统计及进阶需求	10
团队作业第一次—团队展示	2
团队作业第二次—项目选题报告	3
团队第三次-项目原型设计	2
团队作业第四次-项目需求分析	20
团队作业第五次—项目系统设计与数据库设计	12
团队作业第六次—团队Github实战训练	3
项目Alpha冲刺（团队）	50
事后诸葛亮（团队）	2
项目Beta冲刺（团队）	60
Beta阶段团队项目互评	8
个人作业——软件工程实践总结作业	2
总计	180

3.哪一次作业让你印象最深刻？为什么？
结对作业第二次—文献摘要热词统计及进阶需求；原因：如果不考虑工作量等因素的话，个人觉得是这么多作业中难度最大的，一定程度锻炼了我的编程能力。

4.累计花了多少个小时在软工实践上？平均每周花多少个小时？
大约花费180个小时，每周花费约14小时。

5.学习和使用的新软件；
原型设计：墨刀
用例图、类图等：亿图图示

6.学习和使用的新工具；
墨刀、亿图图示

7.学习和掌握的新语言、新平台；
无

8.学习和掌握的新方法；
用github进行团队协作编程

9.其他方面的提升。
编写文档的能力，复杂系统分析的能力，时间管理的能力

二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析

在后台开发的过程中，以为自己返回给前端的数据格式可以轻易被解析，或者部分字段非必需，但是前端真正接入的时候却经常出现问题，需要双方进一步沟通解决问题。

三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。特别地，特别地，下一届要不要中途换队员？

对开学初的我：认真掌握软件工程理论知识，只有熟悉了基础的理论知识，才能更好地指导实践课程。
换队员建议：中途换队员这件事，就我来看，有利有弊。
利是有机会学习更多知识，在别的团队中认识更多的同学，也有助于提高应变和适应能力，对于选择毕业后选择就业的同学会有一定程度上的能力提升。
弊是被选中的队员要花费大量时间去适应这个过程，包括学习新知识，了解新项目，对于大三下选择考研的同学来说弊端尤为明显。
综上，我的建议是，换队员时可以有选择性地挑选，提前了解同学们未来的计划，最好在那些毕业后准备工作的群体中进行选择。

四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章人、绩效和职业道德）

答：《构建之法》中提到团队的发展有下列四个阶段:
1.萌芽阶段;
2.磨合阶段;
3.规范阶段;
4.创造阶段;
萌芽阶段：我们团队在老师办公室讨论需求，初步确定了项目需求。
磨合阶段：由于项目需求复杂，我们经历了一段时间的讨论和分析，初步确立了项目计划和分工，并合作编写了前期的项目文档。
规范阶段：在两次冲刺过程中，我们严格按照项目计划实施，每个时段基本都完成了各自的任务，项目进展较为顺利。
至于创造阶段我们团队可能没有达到，因为是严格按照老师的需求进行系统开发，没有加入过多自己的元素。

五、怎样证明你学会了软件工程？

1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量（3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
我们的用户面向软件工程实践课程老师和全体选择这门课程的学生。

2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布；而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄*
github提交记录和部分项目计划

3）并且通过数据展现软件是可以维护和继续发展的。
而不是找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
项目源码在团队github中

六*（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：

我简要地阅读了第一篇 Code quality analysis in open source software development。
论文中提出了一个试点案例研究的结果来证明开源式软件与传统的封闭模型相比，可以生成更好的软件。案例研究的目的如下（a）了解结构质量的含义;（b）弄清楚开源式发展所提供的代码的结构质量分析的好处。通过这篇论文，我了解到自己对于开源这个概念了解的匮乏。以前虽然经常阅读别人在github上的开源代码，但是几乎没有把自己的代码分享出去与大家交流，我意识到这样可能会使我陷入一个困境，难以意识到自己目前存在的缺陷，因为自己以为良好的规范在别人眼中可能存在问题，当然别人的意见也不一定百分百正确，但是开源可以收集更多群体的意见，有更大的几率发现自己的不足。