03软件工程课程实践的经验与教训
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
附件:
03软件工程课程实践的经验与教训
Group 2——银行信用卡子系统
肖伟(组长,3032112026):
经过一个短学期的软件工程,我深刻体会到了软件工程技术运用于软件工程开发环节中的重要作用。也树立起我在软件开发或者项目开发中,使用软件工程技术来解决实际问题的决心和毅力。软件工程的学习使我不解决了对现实问题的疑惑,而且教会了如何去面对和解决这些问题。在学习软件工程以前,我写过大大小小很多程序,也做过一些项目开发。但是由于缺乏软机工程的思想,总是在最后关键时刻,陷入危机。以前都是以时间紧迫,搪塞过去,现在我明白了,其实是准备不充分。就像我这个学期做的一个项目一样。内容是完成在虚拟力场的状态下,完成都物体的抓取。我暑假花了一个月时间。完成整个项目90%的功能,但是接下来的一个学期里面,进度甚微。自从接触了软件工程以后,我明白了,我的需求分析和框架设计做的很不够。我没有仔细分析在项目开发工程中碰到的问题,和分离可重用模块。导致了代码冗余严重难以维护。导致后面想做较大的改动都非常困难。
短暂的软件工程的学习和训练,是一个令人难忘的回忆。尤其是我在担任组长的时候碰到了大大小小的问题。比如利用人员特色,合理分配。如何调动人员积极性。如何分工。如何定义需求。如何整体设计和沟通小组,组组合作等等。对于一项单干的我来说都是一个巨大的挑战。从所周知,软件开发是个集体的项目,一个团队的凝聚力直接放映了一个团队的战斗力。虽然在一开使的时候碰到挫折,比如组员不合作,分配给他们的任务无法完成。然而这些因素不能归公于组员,有很大一部分是我这个当组长的错,毕竟个人基础和专长不一样,有时候你认为想当然的事情,别人说不定要干很久。于是我从中明白了,当一个组长干活起劲了,组员也会动手的。终于让我们完成赶在元旦完工的伟大梦想。
软件工程中的遗憾,不能充分调动组员的积极性。不能写出规范的文档等等。然而不可否认,这些都是伟大的尝试。经验的点滴积累。
卓科(3001112085):
通过一学期的软件工程实践活动,我充分了解到了一个软件从需求分析,过程建模,数据建模,再到实际的编码实现以及最后的测试评估等一系列严格的步骤。
在此次工程项目使我充分理解到在项目实践中团队合作的重要性,以及在编程设计中相互间信息交流的必要性,合作者之间通过相互之间交流信息,可以避免犯许多不必要的错误和走不必要的弯路,可见在开发一个大型软件的时候,重要的不仅仅是技术支持,团队的协作能力也起着重要的作用,能充分以每个人自身的特点分配任务,才能以最快的时间和最高的效率完成任务。
在此次软件项目实践中,还改变了我以前的一个错误观点,认为在软件实现中最重要的
是编码实现。实际上在面对小问题的时候也许只用考虑编码实现,但面对实际问题的时候,面对大量的客户定制的需求,一个人的编码实现往往是不太现实的。这时候就需要对问题进行周密的分析和详尽的计划。在拿到一个实际问题的时候,首先第一个要考虑的就是要确定对象以及其相关的行为,也就是为问题划分类,以及类的层次和相互关系。这部分行为都包含在需求分析中,可以说一份好的需求报告就确定了软件的基本构架,而后期的编码实现是在此基础上进行的充实和完善,但不会偏离主体方向,因此一份准确的需求就显得非常的必要,这其中还包括了软件开发的风险估计。然后就是建立过程模型,以及具体的编码实现。然后是软件的评估测试,这也是很有必要的,许多人认为编码结束就以为项目的结束,这在实际项目中往往会带来不必要的损失,客户往往会因为你开发的软件中某项功能的缺失或不符合规格而要求索赔或拒绝付款,这往往会令整个项目前功尽弃,因此一份准确而详尽的测试计划也是非常有必要的。在测试过程中往往是以客户当初提出的需求为标准的,通过某些输入输出来测量软件的质量,以期最大程度的减少Bug。当然完全的避免Bug几乎是不可能的,这就意味着在软件提交后,对软件的维护和技术更新是必不可少的,这也充分体现了软件开发的螺旋性前进的模式。
通过软件工程这门课的学习,这不仅仅是书本上的学习,这更是一门注重实践的课程,只有在实践过程中,才能充分把握书本中学到的知识。
缪存款(3032112024):
参加了这次软工银行系统的开发项目,我受益很多,同时也接受到了不少教训。课本上的东西本来是从实践中提炼总结抽象出来的,如果没有将这些东西用到实际工作中,不能深刻的理解其中的奥秘和原由。软件工程这门课解决了软件开发过程中遇到的问题,而这些问题从目前我们遇到的只能说是一点点,我不能以此对它妄加评论,就我个人来说,至少我改掉了不少个人的陋习。比如以前写文档,都是没头没尾的,都是应付,而现在从客户的角度来考虑问题,不用说文档的内容写的怎么样,至少要有头有尾,封面,目录这些都要齐全和耐看。同时从其他小组人员的情况,可以看出,大都仍按个人意愿来完成各部分的子系统,没有充分协调相互之间的联系,所以造成相互推脱责任。还有就是一个系统有很多接口,这一点我从数据库系统的实验里又得到了软工中的教训。数据库系统试验的时候,组员之间接口一开始固定后,大家就没再深入交流,而实际上不同人对同个接口的理解不同,结果最后传递参数时连类型都搞错了。
软工前期,我帮忙画了些流程图,原先没看书,结果都是自己随便在那想象,花了很多时间然后出来的东西又被人否认,那种感觉真的很难受。我的主要工作是做信用卡系统的测试工作。我原先以为测试是随便弄弄的,找不找的到bug带有很大主观性。但是从书中了解到并不是这样一回事。同时测试包括对代码的白盒测试和对功能部件的黑盒测试。原先我只知道黑盒测试。因为时间有限,我并没有去研究同学的代码,只对功能进行了测试。尽管我懂的不多,但是仍然发现了很多问题,可见学生跟真正的软件开发人员差距还是很大。
李彬孟(3032112027):
作为计算机专业的学生,软件工程的学习自然是必不可少的。一个冬学期下来,一门软工课程也将近结束。时间总是太紧迫了,但还是学到了很多东西。对整个IT的学习生涯中无疑是一次很大的进步。回顾大一大二,也陆陆续续的做了几个小的项目,但每每在每个项