软件工程实践总结（我的）

痛并快乐着——软件工程实践总结（我的）

1、请回望暑假时的第一次做业，你对于软件工程课程的想象

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

一学期走来，感受仍是学了不少东西的。从刚开始听到打代码就头疼，到如今可以独立地完成一些有挑战性的我的做业，成就感仍是满满的。虽然到如今我仍是但愿未来可以少写代码，但经过一学年的学习，我也知道，能少打代码意味着已经有了必定的代码基础。并且从事这一行业，不可能不打代码。所以，软工实践以来的苦逼和痛，或许会在未来成为意想不到的助力。

学到如今也有不少不足，好比当时但愿能作出一个很耐看的界面，后面也只是草草了事。理想和现实的差距，每每体如今能力的不足和人的惰性身上，也但愿之后可以精益求精，对任何事情都能交出完美的答卷。还有很不足的地方，就是到如今都没能习惯使用github，以及代码规范。

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

一、统计一下，你在这门软件工程实践中，完成了多少行的代码；

做业序号	代码量	备注
1	300	我的做业-词频统计
2	200	第二次结对做业
3	1500	Alpha冲刺阶段
4	100	团队做业-项目测评
5	300	团队现场编程-抽奖系统
6	1000	Beta冲刺
总计	3400

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

做业名称	耗时(h)	作了啥
软工实践第一次做业	2	学了makedown格式，看看博客，写写博客
我的做业-词频统计	20.5	学习单元测试等新知识，复习c++，问同窗，
第三次做业-结对做业（原型设计）	8	学习并使用Axure RP 8
第四次做业 - 团队展现	1	交博客，增长我的部分
第五次做业 - 结对做业2	16	用python爬数据，实现一些附加功能
第六次做业 - 团队答辩	0.5	交博客，增长我的部分
项目UML设计	5	学习ProcessOn、UML设计，绘制用例图
需求分析报告	10	用墨刀设计原型
Alpha 冲刺	80	原型的从新设计，前端界面的设计，AR技术的研究，拍摄数据集，标数据集，作PPT，研究特效，详见各次冲刺学习进度条，写博客
团队现场编程实战（抽奖系统）	7	python学习和熟悉，聊天记录的分析和挖掘
项目测评（团队）	6	上台答辩，作ppt，采访和测试部分工做
Beta 冲刺	10	对前端界面进行优化，标数据集，拍数据集，参与PPT的制做
我的总结	4	写博客
总计	190

三、哪一次做业让你印象最深入？为何？

应该是第一次我的做业吧。那是我第一次接触到这么庞大的代码量，以及要学这么多的的新东西，单元测试，github的使用等等。这些都让我感受头疼和不适应。并且不一样于结队做业，我要一我的完成整个做业，其中不乏我很是不擅长的部分。虽然最后得分不高，可是我从中也收获了不少宝贵的经验，算是痛并快乐着吧。

四、累计花了多少个小时在软工实践上？平均每周花多少个小时？

• 若是算上站立会议时间和课程答辩时间的话，大概在210小时吧
• 软工从开学第一周到十七周基本结束，共17周，平均210/17=12.3个小时

五、学习和使用的新软件；

• visual studio 2017 ：开发c++控制台程序，第一次我的做业使用
• Android studio 3.0.0 ：andoid开发基本工具，用来作界面
• Axure RP 8：原型设计
• Sublime Text 3：使用python爬网站数据
• PowerPoint：作ppt
• Typora：群里老哥推荐，用来makedown的工具

六、学习和使用的新工具；

• github：学了，可是并无习惯运用

七、学习和掌握的新语言、新平台；

• java：从0开始，还好能够向身边同窗学习
• python：爬爬数据，画画图，须要什么功能学什么
• github：download代码，用来学习
• Process On：一个在线画流程图/uml图等的平台，在需求分析阶段尤为好用

八、学习和掌握的新方法；

• 用例图：基于场景来考虑分析问题，更有助于咱们了解需求
• 思惟导图：用思惟发散的理论，基本覆盖了要作的全部任务集，用图来表示清楚美观

九、其余方面的提高。

• 除了技术硬能力方面，和同窗的团队合做也提升了个人团队协做能力和交际能力；
• 每次在deadline前肝博客提升了个人熬夜能力；
• 答辩和博客提升了个人沟通能力和瞎编能力；
• 碰到不会的部分提升了个人学习能力和抗打击能力......
• 学习这门课真是好处多多，学弟学妹们必定要选柯老师（划重点！）

2、写下属于本身的人月神话——我的或结对或团队项目实践中的经验总结+实例/例证结合的分析

• 第一次我的做业的时候，只有痛苦，没有快乐。那种直到deadline，却始终交不出东西的感受，是很难受的。如今想来，失败的缘由除了代码经验过少以外，对软工不够重视（其实很重视了，可是没想到还不够重视）是更主要的缘由。没有付出足够的努力和时间，天然不能保证获得满意的结果。
• 结对做业的完成仍是比较流畅的。由于我c打的很差，因此主体功能仍是由队友完成的。我负责用爬虫爬数据，也学到了一些有用的技能。比较惋惜的是最后程序彷佛有点小bug，得分点并无所有得满，仍是有点惋惜的。
• 团队做业过程当中真的学到了不少，算是把软件工程理论课所学到的东西几乎都能付诸实践。不止是技术上的，还有答辩能力和团队协做能力。所以，假如你经得起软工实践的挑战的话，仍是能从中受益颇多的。

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

（1）对下一届学弟学妹们（和开学初的我）的建议和告知：**

我但愿他们能学会合理分配本身的时间。软工实践的确是一门能够学到不少东西的课，可是同时也意味着占据了不少课余时间，若是不能妥善处理，那么极可能一事无成。我也但愿他们可以作到咱们这届作不到的东西，可以作出真正能面向市场的软件。

（2）特别地，特别地，下一届要不要中途换队员（强制的、完全的从一队换到另外一队）？ 假设依旧是一个90+人数的大班

我认为能够有中途换队员的操做，可是不必强制。由于有的人可能并不能适应这种被迫换队的操做，虽然在社会中可能会出现这样的状况，也的确有锻炼的效果。但假若由于这种缘由而完成不了软工实践（下学期他们仍是必修）的话，这就是一件很尴尬的事情了。

（3）身在一个格外大的班级，竞争强劲，你认为一个组的人数应当在多少比较合适？

8-10人吧，我以为按这学期的人数划分就很合理了。真的想完成一个比较完善的软件，4-5人是远远不够的。

（4）我的/结对/团队做业应该控制在怎样的规模？

软工真是个神奇的存在。在作做业的过程渴望做业少点，但到了如今又以为这些做业量是合理的，也的确可以锻炼人。但仍是但愿可以尽可能给学生足够的自主性，不要过度影响大学的其它精彩的组成部分。

（5）这学期下来，你最感谢的人是谁？有什么话想要对TA说呢？

喜源同窗，个人结队队友和团队队友。到了计算机以来，不少实践基本都是和他组队，并且说实话，他带我飞的次数会比我带他要多不少。最想对他说一句由衷的谢谢。还有说过请他吃饭的事情必定会兑现诺言的。

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

• 萌芽：团队的起源源于队友暑假打的一个比赛，既然比赛有一个成功的算法雏形，咱们固然愿意参与其中。知道这个团队的组成仍是很开心的，由于不少都是之前据说的学霸，天然而然地就觉得能够在里面舒舒服服地被带飞。惋惜在软工实践中，这是不可能的，想要获得好成绩，就要付出努力。
• 磨合：刚开始的团队磨合仍是会有一些小问题的。开始的几回会议简单肯定了接下来的方向，在一次决定分工的群投票中，因为选择的太晚。最后迫于无奈被分入的开发组。但想到你们基本都是0基础，都得从头开始学，也没什么怨言。后来的合做基本流畅，固然也出现过由于贡献度分配的问题而产生争执的状况。我以为这是很合理的，并非一件坏事，理越辩越明，这会让咱们团队合做更加紧密。
• 规范：这大概是咱们团队目前的现况吧。分工明确，责任和协做人清晰可查。组长的统筹也很合理，而且具备执行力。固然，在代码上的规范仍是远远不够的。
• 创造：如今团队尚未到创造的阶段。每一个人作的基本都是本身的工做，不多有我的可以在各个模块都有必定贡献，并提出创造性的想法。整个团队虽然有创造力，可是远远称不上一个创造阶段的团队，咱们也没有能力去执行咱们的创造性想法。

5、怎样证实你学会了软件工程？

1）研发出符合用户需求的软件

咱们团队开发的产品是面向大学生使用的，如今暂未投入市场，但通过咱们小组内部使用和前期投放的问卷调查，这一产品仍是比较受市场欢迎的。

2）经过一系列工具，流程，团队合做，可以在预计的时间内发布 “足够好” 的软件

咱们队用燃尽图等手段，定时查看每一个队员的“生产进度”。采用原型设计模型，拥有良好的团队协做，足够保证能在预计的时间内发布“足够好”的软件。

3）而且经过数据展示软件是能够维护和继续发展的。

咱们团队有足够详细的文档说明和源码，易于维护和继续发展。
补充一下图片：

4）对着这个检查表：http://xinz.cnblogs.com/p/3852177.html 检查一下，本身若是去企业面试，这些常见的问题是否都能回答，并在此总结。

大部分都不能回答，看来个人专业水平离一个程序员的标准仍是远远不够啊。

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

论文名：Open source software development should strive for even greater code maintainability

引用：（百度翻译后的）

随着年龄的增加，预计OSS项目会有相似的行为是颇有道理的：OSS方法将以与CSS相同的方式产生遗留系统。所以，OSS系统也须要适当的从新设计操做。换句话说，预防性维护多是OSS支持者必须考虑的第三种维护类型。须要更多的实证分析来巩固这项研究的发现。咱们将继续监控这些项目的质量，并将咱们的分析扩展到其余OSS项目，这些项目预先发送了有趣的特性，并容许与CSS开发进行比较。可是，从OSS系统用户感知质量的角度来整合OSS质量的结构视图是很是重要的。

虽然简单地浏览了一遍，可是并无很透彻地理解文章的意思。本文着力于oss与传统css的比较，屡次提到了可维护性的概念。软件工程中也反复提到可维护性的概念。从可维护性的角度来看，不止是能更容易地发现bug，更是为从此扩充功能打好基础。这不只须要严格的代码规范和注释，也须要有效的配置管理，这方面咱们团队作的仍是比较粗糙的。同时我也发现，如今百度翻译作的真的不错，翻译出来的效果基本和原意差的不是不少。固然，对一个程序员来讲，学会看英文论文也是必须的，这个还须要增强学习。

7、个性发挥，包括图文、照片和创意等

团队的第一次合影，但愿咱们团队能保持初心，始终如一。

不知道说些啥，那就新年快乐（指望考试高分）吧>_<