软件工程——个人总结

个人总结

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

1.学习和使用的新软件

Mockplus原型设计软件

Dreamweaver软件

2.学习和使用的新工具

php编译工具

My sql 数据库管理系统

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

学习的新语言:
HTML、PHP

掌握的新平台:
微信公众平台、 新浪云

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

在本次软件工程的实践中,我完成了800行左右的代码

5.学习和掌握的新方法

在这次软件工程的时间中我掌握了原型界面的设计,使用PHP的后台数据库链接,使用PHP和HTML制作动态网页,软件开发方法及其测试方法。

总结与展望

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

通过这学期的软件工程实践,让我感触颇多。通过实践,我掌握了新的编程语言,新的平台,同时也发现了新浪云是一个很强大的平台。通过团队成员自己之间的相互配合,相互帮助,相互学习,最终我们的项目顺利地完成了,同时团队成员之间的友谊更加深厚了。

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

学弟学妹们,我们这个项目还有许多需要改进的地方,希望你们能够进一步完善我们的这个项目。同时希望你们有更好的创意和想法来改进这个项目。

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

对于我们团队而言,我们经历了萌芽阶段,磨合阶段,规范阶段,创造阶段。最后我们团队到达了创造阶段。
在这次软件工程的实践过程中,团队成员之间难免产生分歧,但是我们通过讨论和商量,及时的统一了意见,最后我们的项目得以顺利完成。

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

keep learning, keep going !

个人总结的补充

请大家回顾我们软件工程第一次作业,通过本学期的学习,对第一次作业中的5个问题重新回答。

1.书中说到,绝大部分软件都是由多人合作完成的,大家的工作相互之间存在依赖关系。软件的很多错误都来源于程序员对模块功能的误解,疏忽或不了解模块的变化。为了让自己负责的模块功能定义尽量明确,模块内部的改变不会影响其他模块,而且同时也为了模块的质量能得到稳定的,量化的保证,单元测试是一个很有效的解决方案。但是,除了这个解决方案之外,还存在更优的解决方案吗?(第二章 单元测试)

答:为了使模块的质量得到稳定的,量化的保证,单元测试是最有效,也最为实际的解决方案。

2.在单元测试的基础上,就能够建立关于这一模块的回归测试。在软件项目中,如果一个模块或功能以前是正常工作的,但是在一个新的构建中出了问题,那么这个模块就出现了一个“退步”,从正常工作的状态退化到不正常工作的状态。假如,在3.1.5版本中,模块A的编号为125的测试用例是通过了的,但是在新的版本3.1.6上,这个测试用例却失败了,这就是一个“倒退”。工程师们应该在新版本上运行所有已通过的测试用例,以验证有没有“退化”情况发生,这个过程就是一个回归测试。那么,在回归测试时,它的核心是什么?(第二章 回归测试)

答:回归测试的核心是在测试的某个阶段(单元测试,集成测试,系统测试)快完成时,把这个阶段的所有测试用例再跑一遍。如果再发现需要修改的BUG,则在这次回归测试完成后,且BUG修复后再进行回归测试。

3.设计逻辑与思路的审查是代码复审中最核心,最有价值的部分。代码风格与重大缺陷的审查,虽然重要但简单而机械,可以通过软件自动检查,而设计逻辑与思路的审查,却是复杂而有深度的审查,需要有一定理论深度和编码经验的人才能完成,而且对新手尤为重要。新手是任何项目组不可避免的问题,但遗憾的是,许多项目经理的办法是,只将一些简单而少量的工作交给人数不多的那些新手来完成。这样的结果是,新手始终是新手,他们没有经过足够的锻炼,老手累死累活,无法指望新手给予分担工作。对于这个问题,解决的有效方法是什么?(第四章 代码复审)

答:对于这个问题,解决的有效方法是老手可以进一步加强对新手的指导与培训,在有必要的时候,项目经理可以将一些重要的审查适当的交给新手完成,这样既可以让新手掌握更多的东西,同时也能培养他们的自信心。

4.在第五章的在团队模式中,还有一种模式叫作官僚模式,这种模式脱胎于大机构的组织构架,几个人报告给一个小头目,几个小头目报告给中头目,依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导,同时还混进了领导和被领导的关系。跨组织的合作就会变得比较困难,如何解决这个困难来更好的进行跨组织的合作?(第五章 官僚模式)

答:对于这种问题,要加强各个领导层之间的交流,同时,也要加强团队成员与团队领导的进一步交流。

5.需求分析是软件开发的基础和前提,也是最终目标软件验收的标准,它可以避免或者尽早的剔除早期的错误。虽然在可行性研究阶段,我们也进行了用户需求的分析,但是只是粗略的进行了分析,很多的细节部分都被忽略了。通常我们在进行软件开发的过程中,往往由于需求分析的不足,而最终导致项目的失败。据统计,超过60%的失败项目都是由于项目需求分析不明确或错误造成的,那么怎么尽可能的减小需求分析时的不明确和错误?(第八章 需求分析)

答:对于这种问题,我们在进行需求分析的时候,要考虑周全,尽可能的考虑到所涉及的各个方面,同时,要更加的注重细节方面的问题。

原文地址:https://www.cnblogs.com/Fraster/p/7077126.html