软件工程-个人总结

软件工程--个人总结
一、回想开学初对于软件工程这门课的期望，总结本课程对你带来的提升：
1.学习和使用的新软件:
Mockplus原型设计软件
Dreamweaver软件
2.学习和使用的新工具
Enterprise Architect UML分析和设计工具
php编译工具
My sql 数据库管理系统
3.学习和掌握的新语言、新平台
语言：HTML、PHP
平台：微信公众平台、 新浪云平台
4.在这次软件工程实践中，完成了相对较少的代码
5.学习和掌握的新方法
原型界面的设计；
使用PHP和MySQL制作动态网页。
软件开发方法及其测试方法；
二、总结与展望
1.记录自己在软件工程上课程上的经验总结
团队大作业后，始终相信在做一个项目之前，团队必须要先定好自己所做的项目方向，要做到熟知自己的项目需求分析，而且在课程的学习方面必须打好基础练习操作，比如熟悉画顺序图,用例图,类图。之后要根据自己的项目进行一系列的典型用户分析，原型设计，到编写代码，实现运行，最后进行软件测试。
其次，就是团队精神，大家相互团结协作，各司其职，才能将最后的团队工程作业更好更高效的完成。
2.对于下一届的学弟学妹的建议和告知。
要选择好自己团队所做的项目，一旦决定，就要坚持不懈的完成才能收获成果。还有就是上课得好好听讲，打好自己的理论基础，才能时间与理论更好的结合。
3.分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》团队合作的阶段，你们团队经历过么？最后到达了哪一阶段？
经历了萌芽阶段，磨合阶段，规范阶段及创造阶段，刚开始大家对各自的角色和职责不清楚，大家都慢慢熟悉适应，相对交流比较少，后期在了解了项目的具体功能后，项目设计会有一点点的分歧，但在后面大家的相互讨论，分享经验，分析后大家意见统一，积极合作，共同完成团队的工作。
4.个性发挥
大家协调合作，才能将工作做到最好，期待学弟学妹能比我们做得更好，创造更多的奇迹。
三. 看完《构建之法》，对你列出不懂的5个问题，进行解答
a.在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文
b.列出一些事例或资料，支持你的提问
c.说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾？
例如：我看了这一段文字 （引用文字），有这个问题 （提出问题）；我查了资料，有这些说法（引用说法）；根据我的实践，我得到这些经验（描述自己的经验）；但是我还是不太懂，我的困惑是（说明困惑）；或者我反对作者的观点（提出作者的观点，自己的观点，以及理由）。
1.代码复审
第四章 4.4书中有句话：“发现逻辑错误程序可以编辑通过，但代码的逻辑错误”，要做到代码复审，但是如果代码能够编译通过，只是有一部分的算法比较繁琐，这一部分的代码优化后，是提升了速度，但是对于之后整个程序的开发和维护增加了更大的难度，这样，我们还要讲究代码复审吗？
答：需要代码复审，当所有代码完整无误，就要测试运行，这时我们就要看这个软件质量的好坏，看软件在功能、时间方面的效果，而且软件工程的质量在长期的过程中的保证，此时只有在开发者进行不断的代码修复，解决所有的出现问题，保证项目软件在后期的开发过程中不会继续出现此类问题，才能表明代码复审成功，不会对后期的开发和维度增加难度，期间还要保证团队人员在重要设置项目软件管理，进行记录，保证时时有人跟踪此项目。

2.第六章scrum方法论
用于敏捷开发软件，是一种迭代式增量软件开发过程，是一种轻量级控制方法，应对变化能力强，适合成长型，变化多团队，已广泛应用于百度，淘宝，它主要有三个部分：由program owner负责完成产品需求列表的创建、评估，并按用户故事列表排好优先级 ；再进行完整的迭代过程，选取用户故事优先级别高的，开发测试，还有就是期间的每日例会，一方面能保证工作朝着正确的方向，另外能让团队的每个人了解每日的进展。
虽然Scrum 方法对于敏捷开发有很大的优势，但是最坏的结果，它使产品质量下降怎么办？要如何处理？
答：要从Scrum 开发的各个角度寻求原因。找到产品负责人，确保产品功能和达到要求得标准，询问流程管理员是否整个流程是顺利实施与进行的，是否清除了开发过程中的障碍，再者对开发团队中的每个人负责的不同方面再次细化分工，根据自己的任务分配是否完成工作，另外看自己团队的会议记录，查看工作状态，已完成的项目是否确保正确完成，从项目流程的各方面找原因，人为原因加强自己团队人员任务分配，若是流程出现问题，不妨耐心再重新Scrum敏捷开发，也帮助大家更了解这个项目。

3.没有看懂本书第十一章第四节中的从Spec到实现的一系列内容。
答：开发者看到初始的代码效果了解实现细节后会着手写设计文档，然后按照设计文档继续写代码，然后与同事一起复审，就这样经过多次编写文档修改代码，复审代码 。之后进行自己创建单元的测试和整个系统的单元测试，得到测试版本，交给相关人员测试，收集数据进行问题解决，直至最后的代码复审完毕，然后按照代码修改意见完善单元测试和文档设计，最后将代码写入到代码库。

4.微软PM
第九章
即项目管理，实现了9个项目管理内容，它主要强调敏捷项目管理，是否可以说，当一个人成为一个好的项目管理者，顺其自然也就是一个好的程序员呢？
答：并不一定。侧重点并不相同，项目管理侧重于管理，所谓管理包含领导、组织、用人、计划、控制等五项主要工作，是运用管理的知识、工具和技术，达成解决项目的问题或达成项目的需求。而程序员侧重于专长技能，一个好的程序员是专长于某一项技能，能将自己的特殊技能展示在软件设计等具体的工作中来的人。
如果说一个人是一个好的项目管理者，那他一定是比别人会经营管理团队，有领导能力，能统筹大局，能够协调团队项目里面发生的情况，使项目进程能顺利走向前的人。这样的人能纵观大局，但也有局限于自己技能的，所以不能一概而论是个好的管理者就一定是个好的程序工作者。

5.如何来衡量每个人在团中的个人绩效？
第17章 绩效管理17.3和17.5
答：书中说可以按照工作量多少，效率高低，比资历，，比完成任务维度，贡献度，靠评比来判断，但我认为对于一个团队来说，这样会造成更恶性循环，不但做不到提升团队能力，还会导致团队解散，更别提团队创造力。
应该说：团队领导者首先应该制定一个团队规范，团队成员间是要进行互相的超越，但是在互相协作，帮助提升团队效率的基础上来说，不能进行私下的你争我抢的抢功劳方式，造成恶性竞争。其次，团队成员之间不能有等级划分，对技术强的做的好的继续鼓励，技能相对弱的，不怎么喜欢团队发言的，多给他们机会发言，参与讨论，让他们对自己有信心。另外可以安排小的项目教育不同能力的人进行实战训练，好的加以用之，有点欠缺考虑的，加以指导，并在后期给它相关的问题解决，提升能力。这样团队在以后的工作能力会更强，并且个人的绩效也会有相对大的提高，每个人也会在以后的团队协作中会更准确找到自己的擅长，有更突出的表现。