目录

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

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

开篇博客的课程目标和期待(包含当时内心想法但是没写出来的):
开篇博客链接

  1. 熬夜我应该能挺过去;
  2. 能够学习到软件工程的流程,做出自己的产品;
  3. 学习新技术和使用新工具;
  4. 和团队成员变成朋友;

已达到期待和目标

  1. 熬夜我应该能挺过去 =
    熬夜是真的,整个课程实践过程中,大概有三四次见到福大凌晨夜景,现在回忆起来还是十分痛苦的,虽然在身心上承受很大考验,但是还是挺过来了。年轻吃点苦也挺合适。
  2. 能够学习到软件工程的流程,做出自己的产品 = 团队作业完成了我们的产品记忆罐头,目前可以提供用户正常的使用,手机上还安装着呢,虽然效果没有期望的那么好,但是也基本符合开始的期望。学习实践了软件的需求、开发、测试、推广等等的知识。
  3. 学到更多学习新技术和使用新工具 = 我们的项目是基于Android移动开发的,我几乎都是一张白纸,甚至之前都没有怎么使用过java,面对分配下来的任务,智能去图书馆借书,请教同学,或者自己百度,期间真的学会了特别多。
  4. 和团队成员变成朋友 = 团队组队的时候,也是大家自己不知道怎么的就凑在了一起,经过后来的接触—一次次的团队协作,交流经验,互相提建议;发现大家的很多优点,也都很容易相处,认识了大家优秀的一面。

未达到期待和目标

基本上达到开始的期待和目标。

意想不到的收获

  1. 认识了团队里面很多优秀的小伙伴。
  2. 重新复习了一下去年学的局域网知识(ftp搭建之类);
  3. 其实很多阶段,都让人收获挺大的,答辩课上不少提问和回答挺指的学习的,还有柯老板的道理集今后可能会挺受用的。

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

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

根据自己不完全正确的统计,参照自己的学习进度条,大概完成了4000+行代码。感觉有点多,可能是期间自己写了太多垃圾代码;对于java一开始不是很熟练,写一个小功能都要很久。

软工实践的各次作业分别花了多少时间?(做一个列表)

作业 花费时间(分钟) 博客链接
第一次作业-开篇准备 60 博客链接
个人项目 1236 博客链接
结对项目1 1523 博客链接
团队风采展 120 博客链接
结对作业2 1539 博客链接
团队选题报告 800 博客链接
团队课堂UML设计 920 博客链接
团队需求分析报告 1203 博客链接
Alpha版本冲刺 7890 博客链接1博客链接2博客链接3博客链接4博客链接5博客链接6博客链接7博客链接8博客链接9博客链接10博客链接11
团队现场编程 935 博客链接
团队项目测评(福大助手) 400 博客链接
Beta版本冲刺 2340 博客链接1博客链接2博客链接3博客链接4博客链接5博客链接6博客链接7总结
最终版本展示 240 博客链接

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

要说最让我印象深刻的其实是结对作业一,这次作业是原型作业,和舍友一起做的作业,刚刚开始对于软工实践还抱着一股热情的时候,觉得要认真做好,从界面布局,配色,布局的人性化等等,还参考了国内外的优秀网页,最后设计的原型,最后看来还是蛮漂亮的,还被助教翻牌了,挺开心的。

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

累计花了—-19206分钟=320小时=14天)

贴出开篇博客回答:打算平均每周十个小时左右用在这门课程上。
现在看来,很明显不止,主要还是在自己不懂的技术上面卡住太久时间了。

学习和使用的新软件;

  • 重新学习:Eclipce For JavaEE的使用
  • 开发使用了:Android Studio工具
  • UML设计使用了:StarUML工具和ProcessOn
  • 结对作业使用了:Axure(用得很艰难)
  • 数据库文件可视化软件:SQLite Expert
  • 写服务器代码的时候用的:IntelliJ IDEA
  • 当然还有我们的产品:记忆罐头!

学习和使用的新工具;

  • 现场编程重新学习了Eclipce For JavaEE的使用
  • 开发使用了Android Studio工具
  • UML设计使用了StarUML工具和ProcessOn
  • 数据库文件可视化软件:SQLite Expert
  • 轻量级服务器(阿里云)
  • FTP服务器搭建(忘记叫什么了)
  • 后裔采集器(爬虫)
  • vs里面的代码覆盖率和单元测试工具
  • winscp (查看连接服务器的)

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

  • 学习使用java语言开发
  • web平台上完成项目的云端功能,对web端有更深的认识
  • Android平台开发有一个新的认识

学习和掌握的新方法;

  • 在个人项目中知道了单元测试的意义和方法
  • 在个人项目中学习了代码覆盖率的概念
  • 在个人项目中对代码进行性能分析对开发中优化代码有一个比较新的认识
  • 结对作业学习了原型的设计技巧和爬虫技术
  • 在团队开发中学习了Android开发知识
  • 学习了Javaweb的开发
  • 服务器的搭建
  • Git代码管理

其他方面的提升。

  • 在项目存在压力的情况下,能够评估项目,合理安排时间,通过各种途径学习和开发;也锻炼了团队开发的能力;

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

经验总结: 经过这次实践,我觉得团队协作非常重要,要是一个人很大的压力很难独立完成的项目,有团队的话,就有着交流和相互鼓励,我觉得会轻松很多。而且学习能力非常重要,开发中遇到的问题很多会是我们用已有的知识解决不了的东西,只能在进入下一个阶段前赶紧学习,做好知识储备,要不让会拖慢团队进度。

实例分析:
这次的实践课程,自己起初是一张白纸,只有不断学习,才能做好,从安装Android开发环境,从http协议开始web开发等等,每次在安排任务之后都会对照自己的燃尽图和项目计划,考虑自己要学什么。

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

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

建议:

  • 第一个就是软件工程很有意义啊!!
  • 第二个就是不要怕接触自己没有碰过的技术知识,现在阶段,拓展自己的知识面,会学到更多有趣的东西
  • 第三个就是注意身体。注意身体。注意身体。

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

暂时的换人,可以体验一下,队员之间可以相互取取经,但是永久性的交换队员,我觉得是风险很大的,有的队员可能是团队的核心成员,换到其他项目团队,舒展不开手脚,原团队也会失去主心骨;而且,团队本来就是志同道合的人们一起组建的,不是吗?抱着好玩心态,三天体验卡,还行,永久性的不赞成。

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

看项目情况吧
5-12个人比较实际,一般要八九个吧,文档+美工+前端组+后端组+PM

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

现在的分配就很不错了,特别是团队作业的分阶段反馈,做的很好,让大家能够目标明确的分配时间。

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

最感谢的是郑西坤,在我学习web编程焦头烂额的时候,提供给我很多建议和指导,对我的问题也是不厌其烦的指导,
对西坤同学说的话:
谢谢!(鞠躬)

分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段,你的团队都经历过么,最后到达了“创造”阶段了么?(参考《构建执法》第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 检查一下,自己如果去企业面试,这些常见的问题是否都能回答,并在此总结。

emmmm,我可以说这些问题打开了我新世界的大门吗?很多问题没有听过,更不要说回答了。其实一直觉得自己的学习很奇怪,没有什么目标可言,所以碰到这些系统的问题,就会感觉没见过,概念模糊。。。

总结:现在的能力去就业,在第一轮就被刷掉(很明显),很多知识需要实践和积累,自己都没有听过,看来自己在专业学习上很懈怠,也不得其法,这么多问题给了我很多思路。

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

参考论文文献:

[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

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

2019年,1月18日。

2019年的第一个福大凌晨夜景。

image

版权声明:本文为dalegac原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/dalegac/p/10247409.html