软件工程----个人总结

1.学习和使用的新软件和新工具
Mockplus:原型设计,做项目的界面
PHPstrome:用于此次团队项目代码的完成
数据库:存储数据
微舞幻灯:用于制作动态PPT
kk录像机:用于录像以及视频的剪辑
AppServ:AppServ所包含的软件有:Apache、Apache Monitor、PHP、MySQL、PHP-Nuke和phpMyAdmin。我们用到的有Apache,phpMyAdmin
2.学习和掌握的新语言、新平台
PHP:只了解了它的一点点相关的用法,还没有完全掌握。
Notepad:可以在Notepad里面编写有关PHP的代码,其他语言也可以编写。
菜鸟教程:可以直接在浏览器搜索,里面有不少语言的教程,讲得比较详细,而且简单易懂。
3.统计一下,你在这软件工程实践中,完成了多少行的代码
大约有5000行。
4.学习和掌握的新方法
1)使用菜鸟教程来学习各种语言,简单易懂。
2)使用微舞幻灯来制作动态PPT。
3)使用Mockplus来制作原型界面。
4)使用PHP来制作动态网页,可以内嵌HTML使用。
总结与展望
1.记录自己在软件工程课程上的经验总结
在这门课上,觉得不管是个人项目,结对项目,还是团队项目,都需要有一定的知识储备以及一颗勇于探索新知识的热忱的心,还要善于思考,虽然在整个团队项目当中,自己有很多不懂得部分,但是在不断地查阅资料和小组成员的帮助之下,最终完成了自己被分配的部分,有时候小组成员之间会有摩擦,但是要平静,要好好交流,这样才有利于整个项目的完成。
2.对于下一届的学弟学妹你有什么建议和告知呢?
团队分工要明确合理,小组成员之间要好好交流,有什么不会的要积极查找资料,态度很重要,不能不会就不管了,要抱着求知的心态去学习。
3.分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》团队合作的阶段,你们团队经历过么?最后到达了哪一阶段?
我们团队经历过萌芽阶段、磨合阶段,刚开始都在兴致勃勃的讨论着有关项目的各个部分,充满了希望,觉得会做出一个特别特别棒的网站,但是到后来,发现有冲突了,因为每个人负责的部分不相同,有的组员会根据他自己的想法来改变其他人的代码,导致后期没有办法运行,最终,我们团队达到了规范阶段,团队的领导得到广泛的尊重,其他的成员也分担了一定的领导职责。随着项目的发展和成员们的互动,一些成文或不成文的规则逐步建立起来了。通过聆听、讨论,成员互相之间更加了解,认识到并欣赏各自的能力和经验。成员之间的讨论更加友好,大家意识到并尊重各人的个性。
4.个性发挥,包括图文、照片和创意等
软件工程----个人总结_第1张图片
1.个人项目或团队项目最重要的是什么?该如何去做好最重要的这一点?书36页表格
从表格当中可以很明显的看出:最重要的是需求分析,大四学生与工作三年的软件工程师相比,花费时间最主要的差别在于需求分析与测试。只有分析明白了写的代码的需求是什么,才能更容易的去写(就比如该做什么都不清楚,那如何去做这件事情呢),需求分析不光要站在用户的角度设身处地的为用户着想,将“如何实现”转化为“实现什么”,引导用户提出合理的需求,然后分析所提出需求的重要性并进行总结,然后将整理得到的需求分析以合适的方式递给用户,然后在软件开发的过程当中不断的完善需求。
通过查阅资料,我还知道了需求分析除了书第八章所提到的需求分析的方法外,还有: 1.系统功能需求:(软件)系统必须具备的功能、性能、属性。包括系统性能(功能速度、响应时间、恢复时间等等)、可靠性、易用性、安全性、移植、部署等方面的内容需求。2.设计约束的需求:影响系统实现的各种设计约束,包括开发语言、数据完整性方针、资源的限制、运行的环境的要求等等。
还要注意的一点是要想得到好的需求,还要有一定的所研究领域的专业知识,深刻理解业务,熟悉用户的工作流程,从用户的切身利益点出发。

2.敏捷流程的需求是经常变化的(书118页表格),但是在书本105页又说:敏捷流程的第一步骤就是:找出完成产品需要做的事情。既然需求是经常变化的,那从哪个角度出发来写代码呢?
通过查阅资料,我知道了:敏捷需求分析认为,需求应建立在以用例为中心的需求文档体系,采取协作式而非合同式的沟通方式之上。具体可分为五个关键点:
用例; 协作; 迭代,即需求不是一次最终确定,而是先完成主要框架,再通过迭代逐步精化; 整个过程中以分析为支撑,做需求同时也在做分析,分析模型的输出结果应跟需求分开; 把用例分解到用户故事,在整个软件生命周期过程中来驱动开发和测试。
所以说表格中所说的需求应该是细化了的需求,而敏捷流程步骤所说的需求是指一个大的整体的框架,还有不同的一点是需求分析以文档为中心,并不是传统的沟通方式。
迭代是敏捷需求分析与细化过程中最显著的方式。迭代的特征包含如前文所述的两部分:全生命过程、小粒度的以业务价值为基础的划分。迭代是要产生最终产品的反复,也就是说你的一次一次的反复必须都能产生最终的产品,而不是中间的半成品。这也反映了需求划分的原则,以及每一次小的迭代,其结果都是可确认的。因此,迭代过程中重要的一种方法是分解,以及关注于当前价值实现的部分。如果一个需求暂时不能被理解并且与当前的商业目标的关系并不那么直接,那么它应该被分解和延后,而不是草草地做一个似是而非的大方案而囊括之。

3.软件团队模式以及开发流程当中,提到了一些似乎不怎么好的模式,比如对于软工课上的学生的“主治医师模式”、(一个学生干活,其他学生打酱油)既然这个模式不太好,为什么还要使用呢?我觉得应该把89页那句话去了,这样有助于学生自己思考去选择哪种模式,而不是对这种模式抱有投机取巧的念想。(书本第五章),现在才发现,这只是作者介绍的其中一种模式而已,并不是提倡我们这样子去学习,而是为了让我们更好地理解。

4.怎样才能提升自己的创新意识?第16章
我觉得要想培养一个人的创新意识,最重要的还是要有好奇心、要不耻下问、要大胆质疑、还要从多角度看待一个问题,要有渴求获得新知识的那份心。
我认为好奇心是提升创新意识当中最重要的,只有对自己身边的一系列问题及现象提出自己的看法,才能够激发自己的好奇欲,才能够进步。提出问题是取得知识的先导,只有提出问题,才能解决问题,从而认识才能前进,千万不能怕问题简单,怕被人耻笑,一定要不耻下问,自己觉得有问题的就大胆提出,有疑问才能促使我们去思考,去探索,去创新,只有弄懂了最简单的,才能获得进步。横看成林侧成峰,只有从多角度去看待问题,才能够激发我们的思维,才会激励我们创新。
对于我们来说,要想提升自己的创新意识,就要大胆地闯,大胆地试,实践出真知,这样我们才能够尽快的成长起来。

5.这是一件大事还是一件小事?书本第五章95页
回答:这是一件很大的事,车设计好了,然后又提出要加倒车灯,那么就必须重新设计尾部。。。。。。所有的一切都得重新开始。所以说瀑布模型有很多的局限性,如果有新的需求了,就很难甚至不可能回溯了,就相当于全部的一切都白干了,最终产品要在最后才能出现。对于需求不确定的项目可以采用原型模式,由于需求的变化,这些对象经常面临着剧烈的变化,但是他们却拥有比较稳定一致的接口。可以很好的解决需求不确定的问题。所以在需求分析的时候,要注意到这一点,要便于修改,而不能不适应变化。

你可能感兴趣的:(软件工程----个人总结)