软工个人总结

目录

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

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

开篇博客的课程目标和期待（包含当时内心想法但是没写出来的）：

  • 多敲一些代码。
  • 多学一点东西
  • 交一些朋友

已达到期待和目标

  • 学会了很多东西，包括一个软件完整的开发流程，里面的数据流动方式，以及前后端的交接等软件工程方面的内容。
  • 交到了一群很不错的朋友，这或许才是最大的收获吧，大家一起熬夜，一起辛苦，一起收获，很感谢队友。

未达到期待和目标

  • 自己学到了很多应用方面的知识，但是，说实话，技术并没有提升多少，更多的是ctrl c+ctrl v后再参考编写，实际上并不算是自己写的软件吧。

意想不到的收获

  • 交到了很不错的朋友，一开始以为只是一门课，后来发现不仅仅是一门课，在最艰难的日子——熬夜过程中的友谊是很珍贵的。
  • 革命友谊万岁。

总结这门课程的实践总结和给你带来的提升。

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

  • 进度条貌似不太对，因为没有怎么及时更新，总的算了一下，大概5000行左右。

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

作业 花费时间（分钟）
自我介绍 10
第一次作业 500
个人项目 1400
结对项目1 1560
团队风采展 200
结对作业2 1500
团队选题报告 1300
团队课堂UML设计 600
团队需求分析报告 1300
Alpha版本冲刺 4000
团队现场编程 1300
团队项目测评（福大助手） 150
最终版本展示 240

哪一次作业让你印象最深刻？为什么？

  • 第一次个人作业。当时自己测试好好的，然后自己也研究了好久，但是发现最后其实方向错了，导致只拿了很低的分数。

累计花了多少个小时在软工实践上？平均每周花多少个小时？同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答

  • 累计花234小时，一开始说平均每周十个小时左右，显然超标了，主要还是自己菜。
  • 电子竞技，菜是原罪。

学习和使用的新软件；

  • 现场编程重新学习了Eclipce For JavaEE的使用
  • 开发使用了Android Studio工具
  • UML设计使用了StarUML工具和ProcessOn
  • 结对作业使用了C++

学习和使用的新工具；

  • 现场编程重新学习了Eclipce For JavaEE的使用
  • 开发使用了Android Studio工具
  • UML设计使用了StarUML工具和ProcessOn
  • 个人项目中Visual Studio中的性能分析、代码覆盖率也学习使用了部分新工具的功能

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

  • 更加熟悉的使用java语言开发
  • 在web平台上完成我们的现场编程项目，对web端有更深的认识
  • Android平台开发有一个新的认识

学习和掌握的新方法；

  • 在个人项目中知道了单元测试的意义和方法
  • 在个人项目中学习了代码覆盖率的概念
  • 在个人项目中对代码进行性能分析对开发中优化代码有一个比较新的认识
  • 现场编程中知道了web前端使用模板的魅力
  • 在团队开发中学习了Android开发知识
  • 在团队开发中掌握了Android中如何debug

其他方面的提升。

  • 在人际关系学到了一定的东西。

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

经验总结：任务不要拖拉、及时解决、及时询问、及时检查

实例：
最开始在前端分配任务是写界面的时候，自己傻乎乎的把任务分配得不清不楚，同时没有定下检查的规范，所以在最后大家完成的质量很差。事实证明，没有人为因素干扰的系统总是趋于熵增的。要注意认为控制。

分析：
首先要分配得有针对性，不能随意分配，导致任务不清晰，不重点，不均衡。其次要定下验收标准，这样才能让任务完成得更有针对性。

对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，对于同期的TA们，对于后来的学弟学妹：

你有什么想建议、告知和期许想要告诉他们呢？

建议：

  • 可以选，也可以不选。看个人需求，这个课很累，而且只有两学分，收益不高。
  • 但我还想说，再给我从来一次的机会，我还是会选的，因为作为一名计算机的学生，没有开发软件的经历是很丢人的。
  • 所以，综上，如果你有开发软件的经历，不建议你选，如果你想增加开发软件的经历，可以选，认真学就行。

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

  • 我觉得没有必要，我不太清楚换队员的意义何在，这并不需要模拟职场，我们还是组成一个团队一起为一个个任务努力。
  • 同时，我觉得软工收获最大的是友谊，那是一起熬过夜的友谊，很珍贵，而并不是什么模拟换队员，没有意义。

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

  • 6-7人一组，人太多会花费很多沟通成本。但相应任务应该减小。

个人/结对/团队作业应该控制在怎样的规模？

  • 规模的话，个人和结对的觉得都挺适合的，但团队作业应该是按平均每组人数来定。
  • 建议是团队作业的时候纯粹一点，这样能更专心一点。

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

  • 最想感谢的是绪佩同学，作为一个pm，能做到最好了，从开始阶段的为了制定好的验收标准，而去看分配给每个队员的任务的相关材料。
  • 答辩时的认真准备ppt时写好演讲稿。
  • 作为pm还承担很多的前端编写任务。很优秀。

对绪佩同学说的话：

  • 我想问，你的queen是谁？

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

《构建之法》团队发展阶段

  • 萌芽阶段：就像小苗破图而出，柔弱但充满希望。团队成员刚刚接触到团队的宗旨，同时很有可能刚刚互相认识。团队的目标没有真正达成一致，而成员则非常依赖于团队领导的指导。
  • 磨合阶段：就像一个人的青少年时期，充满了对个人、同伴和团队的疑惑和冲突。团队无论大小都要客服困难，交付结果，大家不得不认真的面对问题，开展讨论了。这些冲突不一定都是技术问题也许是关于角色、职责、相互关系。甚至是各自性格、文化的冲突。不少人都想成为某个领域的“拥有者”（在软件项目中，谁负责哪个方面，每个方面要怎么做，等等）。同时也有一些人会以不同的方式进行挑战。
  • 规范阶段：从磨合阶段毕业进入到规范阶段的团队成员们就角色、职责定义和流程都取得了比较一致的意见。这一时期团队具有以下特点。
    1. 团队的工作流程和工作的方式得到大家的认可。成员之间互相更加了解，欣赏各自能力和经验，工作中相互支持。
    2. 领导主要扮演促成者和鼓励者的角色，有能力的成员也分担了一定的领导职责，并自然的获得大家的尊重。
    3. 随着项目的开展，一些成文的或不成文的规则逐步建立起来了。
    4. 作为一个整体，团队要做什么、不做什么，都更加明确。团队的信心更足，和其他团队打交道更有底气。
  • 创造阶段：经历以上三阶段后团队可以创造一些有意义的东西，并不是所哟偶团队都能到达这一阶段。拥有以下特点：
    1. 团队知道为何而战，并将注意力几种到如何创造、实现目标上。
    2. 高度自治，不再需要领导的时时教诲与介入。不同意见仍会出现，但成员都以一种积极的心态和方式解决。互相支持，互相依赖，并保持各自的灵活性。
  • 萌芽阶段： 这个阶段显然是经历过的，在最初始定下项目选题的时候我们便是在萌芽阶段，大家对于我们的产品的目标完成的主要功能主要是通过我描述和讨论好多次之后才陆续确定下来的。应该算是在alpha冲刺开发前团队一直处于这一阶段向下一阶段迈进。
  • 磨合阶段： 这个阶段的对个人和团队中的疑惑感觉我们团队倒比较少出现，因为团队一直以来的答辩得分和成绩都在前列，所以主要是出现成员之间的角色、职责、相互关系、各自性格、文化冲突。团队其实在Alpha完成后Beta阶段也出现了这种苗头，因为配合不够到位、存在一些误会等等一些原因，但是最终还是算比较正常的解决和度过了这种现情况。（我感觉团队不管在任何阶段都在不断的磨合配合的更好，所以不代表我们在后面阶段就不再需要磨合）

团队自信

团队现场编程

UML现场设计

团队展示

项目评测

需求分析报告

项目选题报告

  • 规范阶段：
    • 团队已经有一些成文规则（开会做会议纪要、每隔2-3天进行反馈...）和不成文规则（开会地点：34#3 or 青卜 or 35#3）
    • 在Beta版本和最终版本阶段我便是主要扮演一个促成者和鼓励者的角色，把任务分配下去看结果的流程，apk经过13次迭代，其中有一些是我要求迭代修复bug，还有一些是队员主动更新迭代，修复bug并发布打包新的apk
    • 团队的信息更足，和其他团队打交道更有底气这是一定的！从团队每次作业团队总分、答辩分数、文档分数都高居榜首便能知晓。

团队还没有达到创造阶段，但是我们的记忆罐头就是我们创造出来的有意义的东西！！！

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

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

  1. 我们的产品在开发前做过一次市场调研问卷调查（样本容量：线上93+线下110=203份），并完成了我们的记忆罐头商业企划书。其中包括用户对我们产品功能的反馈饼状图，我们产品功能十分符合用户需求。

需求展示

  1. 在完成产品后我们邀请了86位用户进行内测试用我们的记忆罐头,并且收集了用户反馈问卷。

体验指数展示

期待指数展示

通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件

我们团队在软件工程实践课程的机会之下，通过团队合作完成了产品记忆罐头！分别在Alpha版本阶段完成产品的初始版本，Beta版本完善产品进行一定的bug修复，最终版本已经迭代13次完成产品的1.1.3版本，产品下载链接。

并且通过数据展现软件是可以维护和继续发展的。

现软件的可维护性和是否可继续发展通过上面的用户反馈问卷截图便能看出。

体验指数展示

期待指数展示

用户需求期待指数超过4分的比例在70%以上，证明我们的产品是可维护和可持续发展的。并且产品具有十分可观的盈利方式和前景，对不同手机（三星、华为、Oppo）应用市场的在线付费壁纸做了一个简单的调研：

三星付费壁纸

华为付费壁纸

Oppo付费壁纸

盈利点

可以看出，我们的核心创新点锁屏壁纸展示如果能够达到美观、友好的前提下，还能展示出用户的备忘内容，那么便完全可以借助于付费壁纸已经广为人知的免推广的天然优势！！！在每种壁纸单价较为廉价的模式下，提高用户购买欲，相信可以很快的抢占付费壁纸的一块市场，这样也为后续的开发提供了条件和盈利希望。当然，这一切都需要在能够解决生成美观壁纸展示备忘的这一难点的前提下。也正所谓难点即卖点！

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

总结的话，问题有点多耗时间呀...我要复习了，后面再补吧！！！

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

参考论文文献：

[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.

[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605

[3] Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87

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

Welcome to 404 Note Found. You can see nothing here.

posted @ 2019-01-07 11:15  waaaafool  阅读(258)  评论(0)    收藏  举报