回想开学初对于软件工程这门课的期望,总结本课程对你带来的提升:

学习和使用的新软件及工具

1.AppLoader:APPLoader 是 APICloud Suite 自带的一个工具,用于把我们写好的程序上载到手机,进行测试;
2.Mockplus:Mockplus 是一款简洁快速的原型图设计工具。适合软件团队、个人在软件开发的设计阶段使用;

3. APICloud Suite 2::由APICloud 提供的移动应用集成开发环境;

4.PowerDesigner:PowerDesigner是Sybase公司的CASE工具集,使用它可以方便地对管理信息系统进行分析设计,它几乎包括了数据库模型设计的全过程。

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

1.学习和掌握的新语言:html5, js,C#;
2.学习和掌握的新平台:APICloud平台。

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

本次软件工程实践中我完成了后台数据库连接、软件登录功能、查询功能、跳转功能代码的编写,完成代码约1500行;

学习和掌握的新方法

1.后台与云端数据库的连接;
2.学习了很多在APICloud环境开发中所要应用的函数;
3.使用APPloader 真机同步测试,更具体的了解到程序错误在哪里;
4.学会使用.PowerDesigner完成数据库设计;
5.学会许多HTML语言,完成一些界面设计。

总结与展望

记录自己在软件工程课程上的经验总结

完成一个项目,需要学习许多之前不会或者没有学好的知识,而且在学习过程中会有很不懂得地方要一一通过实践来掌握,使用新的平台也需要学习教程,这就需要我们认真仔细的学习,才能在后面的实践中比较顺利。同时,也需要很大的耐心,我们缺少这样的磨练,比如在登录界面连接数据库时让我困惑了很久,三天都在改这一部分代码,很多次都想放弃,还是就平复完心情接着苦逼的找bug,大家也都是这样,但是坚持了几天之后终于成功了,我觉得非常开心。总之,坚持虽然不一定会成功,但是不坚持一定不会成功。

对于下一届的学弟学妹你有什么建议和告知呢?

选题要谨慎,在选题之前一定要考虑清楚,和同组的小伙伴要商量好,以免产生冲突,在合作时也要团结互助,对于自己负责的部分要认真,意见不合时要心平气和的讨论。

分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》团队合作的阶段,你们团队经历过么?最后到达了哪一阶段?

开始意见各不相同,从萌芽阶段进入磨合阶段,之后和平相处,进入规范阶段。

个人总结的补充

问题

一、第四章

4.5中提到结对编程,在4.5.2中也将此和越野赛车和驾驶飞机来类比,但是我认为,比如驾驶飞机,驾驶和副驾驶有许多工作是需要同时工作合作完成,在副驾驶代替驾驶来执行时驾驶可以分散注意力;可当程序员结对编程时,共用使用一个电脑、一个鼠标、一个键盘,会是分工完成项目,不可能是同时来写代码,当一个人执行任务另一个若是分散注意力不是会出现许多错误?两人一起,其中一人若是被检查出错误而打断会不会反而打断了他的进度从而让整个进度更慢,出现1+1<2的状况?还有在什么时候比较适合结对编程呢?
之后在团队复审时提到人多有伤面子的问题,如果是结对编程突然被他人指出错误导致意见不和,毕竟是在他人面前,不是任存在这个问题?

二、第五章

5.2中各种软件团队的模式,其中爵士乐模式和功能团队模式,成员间都不存在管理与被管理的关系,,每个人之间也都有不同的功能,相当于都是一个小团队共同完成一个任务,各自发挥自己的本事,那么这两种模式有什么具体的区别?

三、第六章

敏捷流程,什么时候适合选择敏捷,敏捷流程的适应范围能多举几个例子么?

四、第七章

7.2.3中提到充分授权和信任,当授权给别人时,就相当于这一部分任务需要完全依赖他人,这样若是在之后发现任务中有许多的错误,有需要再反复去修改甚至重新完成岂不是浪费了大量时间?这样不是很危险吗?再就是提到可以有工具的支持,但是及时发现了错误或者有人进度太慢要如何帮助?不可能让有其他任务的伙伴来为此耽误自己的工作。

五、第十一章

11..4.2中有开发人员的标准工作流程,但是当完成一项工程时,若是在程序员自己专心工作时发现bug又回过头分析甚至解决,不断进入设计、自测、测试复审等环节不会耽误自己的进度么?若是不这样又可能出现11.5.5的小强地狱的状况,那么究竟怎样才能又不耽误自己的进度又让自己项目中出现的bug很少呢?

学习过后我的回答

一、第四章

首先需要二人磨合,在有不同意见能心平气和的讨论,同时分工明确,但是在伙伴需要帮助时又要即使顶上,在合作时都必须认真仔细,有责任感,及时找到错误,及时讨论解决。

二、第五章

爵士乐模式:平时有编曲者指挥和协调乐队;不靠谱
功能团队模式:有明确的目标,平时也都是平等的,没有指挥或者队长。

三、第六章

范围:软件需求经常变化或者需求变化比较大; 项目团队与用户之间进行沟通比较容易; 项目的开发风险比较高; 规模比较小,一般项目组成员在50 人之内; 项目团队的成员能力比较强,而且具有责任感; 项目的可测试性比较好。

四、第七章

首先还是需要信任自己的团队成员,同时借助工具的支持,及时了解伙伴们的工作进程,从而才能及时的帮助成员,让工作顺利按时完成,组长需要做的是支持和帮助,不是迫使完成任务。

五、第十一章

首先需要个人的用心,其次是发现bug后,分析小强,看难度解决所需时间决定是否立即修复,进度与效率要并重。既要进度又要避免小强地狱。