| 这个作业属于哪个课程 | 2020春|S班(福州大学) |
|---|---|
| 这个作业要求在哪里 | 个人作业——软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 总结软件工程实践课程 |
| 作业正文 | 个人作业——软件工程实践总结&个人技术博客 |
| 其他参考文献 | 《构建之法》 |
一、回望
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强软件工程专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
个人觉得以软件工程实践的初衷来说是达到了，在此次实践中最大的收获就是，较为真实的了解到了一个项目完整的 开发流程是什么样的、项目成员是如何分工的。因为之前一直没有项目开发的经验，最多都是单人或者小组直接完成一个老师交付的作业。但从选题到后续各项进程都小组自主的还是第一次。
存在的不足：比较遗憾的是，一开始选择的是web前端的方向，在学习前端知识的过程中，由于小组选题为ios软件的开发，未能使用上，同时在后续实习基地的选择上，也没能选上前端，反而选到了产品，因此后续又在学习产品相关的知识，并应用在了实践和现在的实习学习过程中。
（2）你在第一次作业的个人简历中描述了这门课程结束后，你预期你将增长的能力、技术、技能，并绘制了学习路线图。对比当前你的所学所得，你达到了当时的预期值吗？
在上面的不足中也提到了，所学所得未能达到预期。前端开发的学习在经历了html+css的复习，js的深入，jquery的学习，bootstrip的学习之后，vue仅学习到了结构化开发之前，就因为其他方向学习需求并且由于暂时用不到web前端技术而搁置了。现在由于实习需要，要按照公司导师的安排进行产品经理方面的学习和产出任务，暂时前端没有学习的时间。
（3）哪一次作业让你印象最深刻？为什么？
如果不说团队项目的话，可能印象最深刻的还是疫情记录读取报告内容并记录的那次。因为当时正处疫情最严重的时刻，在网上又接触了很多相关的内容心情很沉重，而且由于期末和寒假长时间未能编写代码，当时的作业做的很艰辛，代码虽然不多，几百行。但由于各项bug来来回回改了好多次，花费了非常多的精力，电脑还老是死机，交代码前两天还是有问题，当时挺绝望的。
（4）在课程问卷中，我们统计了你在课程上花费的精力和提升；现在请你再次将这些数据罗列出来，作为个人的记录。包括以下内容：
| 作业 | 花费时间 |
|---|---|
| 准备篇 | 3h |
| 热身篇——疫情统计 | 50h |
| 结对第一次—某次疫情统计可视化（原型设计） | 10h |
| 团队作业第一次——种子队伍选拔和团队展示 | 3h |
| 结对第二次作业——某次疫情统计可视化的实现 | 20h |
| 团队作业第二次—团队Github实战训练 | 5h |
| 团队作业第三次—项目需求分析 | 5h |
| 团队作业第四次—项目系统设计与数据库设计 | 4h |
| 个人作业——软件评测 | 6h |
| 团队作业第五次——站立式会议+alpha冲刺 | 28h |
| 团队作业第六次——beta冲刺+事后诸葛亮 | 18h |
| 个人作业——软件工程实践总结&个人技术博客 | 6h |
学习和使用的新软件：github desktop（版本控制） Axure rp9和墨刀(原型设计) eclipse及tomcat(java项目)
学习和使用的新工具：在前端学习过程中学会的谷歌浏览器审查页面
学习和掌握的新语言：后端ssh框架和ssm框架
工程功能里的提升：依照课程比较真实的了解到一个项目工程开发的各个阶段
团队合作上的提升：明白了团队协作中共同以及有一个主心骨一样的角色有多么的重要
二、团队总结
你是组员还是组长？你觉得你自己在哪些地方做得好？你觉得自己还有什么可以改进的地方，具体可以怎么改进？
一开始团队分工的时候，我负责的是产品经理，然后小组成员就选产品作为小组组长，但是在团队第一次合作开发口罩预约平台的时候，由于个人的项目开发经验不足，没有很好的划分任务和分配任务，导致一天的冲刺几乎就3个人在做。后面反思了个人的能力，让更有开发经验的成员担任。确实是项目经验不足，分配不够合理，在后续的实践中也算是获得了一定的进步。我觉得自己做的好的地方，作为产品，从拉动团队进行需求讨论到完全的独自进行设计高保真原型的设计，算是把握了项目的灵魂。后续又一定程度参与了后端与测试的工作，也算是为小组尽力了。
你觉得你的组长（组员们）在哪些地方做得好？你觉得ta（ta们）还有什么可以进一步提升的地方，有什么具体的建议吗？
随机分组的很不好的一点就是小组成员们可能会出现在各种方面上的不搭，组员们都不太主动的样子，负责内容多的成员没有主动将任务分出去，任务少的成员又不主动去揽任务。但归根到底可能还是组长在分配上的问题，由于是随机分组，不算很熟悉，又不好意思强硬的要求，因此会出现许许多多的问题。而且网络实践确实是个比较差的方式，作业过程中每个人做了啥基本都无法知晓。而面对面的小组实践更有效率。
《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
萌芽阶段：由于是随机组队，团队成员互相不认识，个人的职责也都不是很清楚，在口罩预约平台的冲刺时明显的体现了。
磨合阶段：在第一次冲刺的时候，不管是在分工还是在后续的贡献度分配上，都出现了一定的矛盾，最后似乎也没有调解的很好。
规范阶段：在第二次冲刺的后期，许多暂时没有任务的同学也主动的开始写文档和参与测试工作，勉强算是做到了一个团队的样子。
但个人感觉还是没有到创造阶段，最后的成果对于一个从需求分析到原型设计的产品来说，是不够合格的，没有达到能够推广出去使用的程度。
从开发的角度，你在团队中担任了什么角色？你是否完成了该角色的任务？现在你觉得你适合该角色吗？
除去产品方面的职责，我在口罩预约平台的时候，算是web前端，完成了后台页面的开发，觉得还是很好的完成了任务。在正式的实践中，第一次参与后端的开发但结果不是很好，贡献度也不足，因为后端的知识掌握的不是很牢靠，我觉得没有很适合这个角色。第二次冲刺主要还是担任测试，对后端接口等进行测试，也算是完成了任务，但觉得并不是很适合。而综合整个实践下来，从产品的角度来说，需求分析和原型设计几乎已经定好了整个项目的开发的骨头，但在后续没能开发出血肉，在项目管理方面也经验不足而有所欠缺，勉强算是达到了新手产品的程度，但希望后续在实习过程中能够进步到足够成长为一个优秀的产品经理。
三、人月神话
1、使用git等版本控制软件(从第二次冲刺开始)
前端提交:
后端提交:
是有针对功能模块进行定期的发布，项目的进展也是有着一定的规划。
项目拥有着从软件需求规格说明书、系统设计说明书、接口说明等文档，也可在git上找到源代码。
2、比较明显的是刚组队完的口罩预约平台的那次冲刺，大家还没有小组的概念，需求大概的讨论完了之后，就各自认领了活然后就埋头苦干了，我当时是写的前端的后台页面和一些后端的接口。结果时间到了一半的时候才发现有比较重要的部分居然没有人负责，有在干活的人几乎都在做自己的事，而没有分配到的人却在等着写文档。最后几个小时几乎是就靠着2、3个人才完成了项目。那天一整天都坐在电脑前爆肝，分析完需求写前端、然后写后端、然后写代码。
四、建议
对于下一届同学，或者大一的同学，想说：
大一先把基础打好，c和c++真的很重要。学有余力的时候就可以多简单体验几门语言，多接触一些领域，尽早的确定自己的方向，并提前努力。最重要的是：多参加比赛和项目，最好能在西二工作室待下去，多一些项目经验，真的会很有好处。这方面的努力是会有结果的。
对于自己今后的建言
既然实习基地大胆的选择了产品经理方向，希望能多努力一点，多学一点，不要在各个方向之间摇摆不定了。大三下真的是个艰难的学期，前端、java、产品摇摆不定，虽然学了很多东西，但都没有能学透。
对于助教工作的建议
我觉得助教可以深入到小组群里去，不只是作为授课老师的助手发布任务什么的，但这样负担比较大。当然也建议作为优秀的学长学姐能够直播一两次，与同学们聊天答疑解惑，大三下真的是一个让人摇摆不定的学期。
对于软工实践课程，你有哪些建议？对于软工实践课程的上课形式和内容，你有什么具体的意见和建议？在哪儿需要强化或者剔除？
课程虽然是模拟项目开发的进程，但个人而言，综合在几周高强度完成比较好，战线拉的过长，到了后期，特别是第二次冲刺，能够感受到大家基本都很疲乏，也没有项目初期的干劲了。
五、个人技术总结
个人技术总结随笔（junit）
六、论文笔记
阅读的是《Code quality analysis in open source software development》
1、什么是开源项目（Open Source Software）
一 个开发人员或一组开发人员编写软件 的第一个版本，并在网上免费提供，邀请其他开发人员参与并贡献代码片段。 正在开发的产品的演变通常由其创建者协调。 协调员的职责包括配置管理、发布调度、决定接受哪些代码贡献以及其他管理活动，使得整个过程看起来像一个传统的过程。
开源项目开发过程也可以说是一个协调的过程，是一项需要长久维护而不是完成需求后就结束的项目，因此开源代码的可维护性就极为的重要，因此就需要一个标准来衡量和评估其可维护性。
2、源代码测量（Source Code Measurement）
典型的软件度量是代码的大小（以代码行、语句数等衡量）和代码复杂性（通过复杂性数字来衡量）
论文中介绍的方法：
代码行数(LOC)衡量程序代码的物理大小，不包括空白行和注释。
Halstead Volume (V ) ：n1（不同操作符的数量)、n2(不同操作数的数量)、N1(操作符的总数)和N2（操作数的总数）。
程序词汇表(program vocabulary) n=n1+n2,程序长度 N = N1+N2
最终定义了Volume V = N * (LOG2 n).
文中还提到了圈复杂度(Cyclomatic complexity),这是一种代码复杂度的衡量标准，数量上表现为线性无关的路径条数，圈复杂度大说明程序代码可能质量低且难于测试和维护。
最后提到了一个符合度量-可维护性指数MI
MI = 171–5.2ln(avgV) – 0.23avgV(g) –16.2ln(avgLOC)+50sin(√2.4avgPerCM)
高MI意味着可维护性高
3、实验结论
文中的实验有样例有一组对照
Pr A最初是作为OSS产品生产的，但后续进行了商业开发，产生了一个CSSPr A的版本，最后虽然No. of releases measured相同，但OSSPr A大代码总尺寸要小，更好维护。
实验结论：
1、使用MI方式，CSS和OSS代码质量至少相等，有时OSS甚至更好，原因可能是开源项目有High motivation的特点
2、开源项目需要更为仔细的个别分析（模块分析？）。很小比例的软件负责最大多数的 问题，因此有理由相信20%的组件可能会产生80%的可维护性问题
3、OSS项目似乎同样受到CSS项目开发过程中的问题：随着时间的推移，可维护性会逐渐恶化。恰当的重新设计的行为（ appropriate reengineering actions），也许也是必要的。预防性维护也是开源项目开发者需要的讨论的。