高级软件工程实践总结
一、请回望第一次作业,你对于高级软件工程课程的想象
1)对比开篇博客你对课程目标和期待,“希望通过实践锻炼,增强计算机专业的能力和就业竞争力”,对比目前的所学所练所得,在哪些方面达到了你的期待和目标,哪些方面还存在哪些不足,为什么?
本次我们小组的项目主要用到的技术是,前端用到bootstrap框架和anjularjs,HTML,css,后台用Sqringmvc框架,java语言进行开发的。在本科阶段大都是自己一个人做项目,缺乏团队的意识。在本次的项目开发中,收获最大的是项目管理上的锻炼,增强了团队的意识,学会了如何与团队其他成员进行更有效的沟通,提高开发效率。其次,虽然经过本次的项目实践,代码能力相比之前有很大的提升,但是还是远远不够,在实际开发过程中也因为能力的不足使得项目不能按原计划完成,希望在日后继续努力,提升自己的代码能力,为团队做出更大的贡献。
2)总结这门课程的实践总结和给你带来的提升,包括以下内容:
- 统计一下,你在这门高级软件工程实践中,完成了多少行的代码
按模块统计,在这次高级软件工程实践中,完成的大约14000行代码。
- 高级软工实践的各次作业分别花了多少时间?(做一个列表)
作业 | 花费时间 | 作业 | 花费时间 |
高级软件工程第一次作业 | 2h | 项目Alpha冲刺Day11 | 0.8h |
高级软件工程第二次作业 | 7h | 项目Alpha冲刺Day12 | 0.7h |
第一次结对作业 | 8h | 设计模式第三次作业 | 7h |
高级软件工程第一次作业 | 1.5h | 测试随笔 | 2h |
第二次结对作业 | 24h | 总结随笔 | 1.5h |
团队选题报告 | 3h | 集合随笔 | 0.4h |
设计模式第一次作业 | 4h | 城市安全风险管理项目Postmortem结果 | 1h |
团队项目-需求分析 | 3h | 项目Beta预备 | 1h |
设计模式第二次作业 | 8h | Beta冲刺第一天 | 0.5h |
项目Alpha冲刺Day1 | 0.8h | Beta冲刺第二天 | 0.5h |
项目Alpha冲刺Day2 | 0.7h | Beta冲刺第三天 | 0.5h |
项目Alpha冲刺Day3 | 0.8h | Beta冲刺第四天 | 0.5h |
项目Alpha冲刺Day4 | 0.6h | Beta冲刺第五天 | 0.5h |
项目Alpha冲刺Day5 | 0.5h | Beta冲刺第六天 | 0.5h |
项目Alpha冲刺Day6 | 0.7h | Beta冲刺第七天 | 0.5h |
项目Alpha冲刺Day7 | 0.8h | Beta冲刺总结 | 1.5h |
项目Alpha冲刺Day8 | 0.8h | 用户调查报告 | 3h |
项目Alpha冲刺Day9 | 0.7h | Beta冲刺集合 | 0.5h |
项目Alpha冲刺Day10 | 0.7h |
哪一次作业让你印象最深刻?为什么?
作业中包含个人作业和团队作业。团队作业让我比较印象深刻。其中最让我印象深刻的是团队作业中的最终项目总结。在做项目总结的作业时,脑子里浮现的是这几个月来与团队成员一起奋斗的画面,为能完成本次项目感到兴奋与自豪。
累计花了多少个小时在高级软工实践上?平均每周花多少个小时?
累计花在高级软件工程的软工实践上大约240小时。Alpha和Beta阶段大约花费3周时间。故平均每周花费80小时。
学习和使用的新软件;
开发软件IntelliJ IDEA、ProcessON(画图、Git(版本控制)、RP(原型设计)、svn(版本管理工具)
学习和使用的新工具;
Github(一个代码托管平台)、安科网
学习和掌握的新语言、新平台;
anjularjs,sqring mvc框架、bootstrap前端框架
其他方面的提升。
项目管理方面的提升,有效的沟通。
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
定义:
三个以上的个人实践根据某种规则密切联系成为一个统一的整体,我们称这样的总体为团队实践。
性质:
团队实践应具有以下性质:
- 团队中的个人都要遵守统一的团队规则
- 在形式上,个人之间是独立的,可以并发执行
- 在内容上,个人实践是紧密联系,缺一不可的
- 个人实践之间应该两两互不矛盾。这个包含两个层面:个人的代码不会影响其他人的结果,同时自己的代码不会受其他人的代码影响。
鉴于以上性质,加上自己的实践,总结出以下经验:
本次项目的开发过程中,每当遇到问题时的迷茫,以及解决难题时的快意,都让我们印象深刻。在项目的收尾阶段,将对我们遇到的问题进行一些总结,分享我们的项目经验与教训。
需求分析阶段。只有充分了解了用户的需求才能开发功能完整、性能良好的产品。所以前期的市场调研,各个功能模块的详细描述显得非常重要。
数据库的设计。一个项目的开发必然离不开数据的交互。在本次的项目过程中,因为底层封装的东西,设置数据库字段不能出现大写字母,调用一些底层的方法无法实现,折腾了很长时间才解决。所以数据库的设计显得格外的重要。
测试。测试环节也是项目开发过程中的一个重要环节。这次我们团队测试分为两个阶段:第一个阶段为组内成员之间进行交叉测试、第二阶段让学长学姐充当用户进行第二轮测试。这样测试的作用避免存在局限性,开发人员测试自己模块时,往往会下意识的不去输入一些非法数据。
分工与合作。由于团队成员之间存在能力上的不同,故任务的分配显得非常重要。分配得当,会带来很多好处,大大提高开发效率。
沟通。在实际生活中大家都在强调够沟通的重要性。经过本次项目的实践,深有体会。在分派任务时,没有和谐的沟通,就很可能把做正确的事和正确的做事混为一谈。准确地说,正确地做事必须要以做正确的事为前题,如果没有做正确的事,正确地做事就没有意义。
整体性能与用户需求。一个产品的开发最终是要提供给用户使用。故在开发过程中应该站在用户的角度思考问题。在本次项目的测试阶段就发现这个问题,开发人员往往被很多习惯限制了自己的思维,没有想到用户是不懂程序的,没有对一些非法的输入进行处理,导致最后程序的崩溃,数据的丢失等等。
三、对下一届实践的建议,或者对于开学初的你,对于大一的你,对于开学初的我,你有什么想建议和告知的呢?
理论必须与实践相结合才有意义。《构建执法》中强调learning By Codeing。根据个人的经验,作为一门实践课程,如果只是在课上学习一点理论知识,而不把理论运用在实践上,过不了多久就忘得一干二净,只有在实践中才会发现自己的不足,慢慢完善自己。对下一届学弟学妹的意见是,趁年轻多学点东西,这门课完全可以满足你在动手能力上的需求,加入软工实践,会收获很多你意想不到的东西。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段,你的团队都经历过么,最后到达了“创造”阶段了么?(参考《构建执法》第17章 人、绩效和职业道德)
√ 萌芽阶段√ 磨合阶段√ 规范阶段√ 创造阶段。
我们团队经历着这四个阶段。从大家一脸蒙蔽,个人角色和职责都不清楚,不知道自己该做什么,该往哪里去的萌芽阶段到大家对同伴和团队的疑惑和冲突,在组长的带领下,大家相互信任,解决冲突,能够有效的沟通,逐渐进入规范阶段。进入规范阶段,我们就角色,职责定义,人员分工,和开发流程都能取得比较一致的意见,作为一个整体,团队要做什么,不做什么,都相比前面两个阶段更加明确。团队的信心更足。经历了萌芽阶段、磨合阶段、规范阶段,现在团队终于可以创造一些有意义的东西。
五、怎样证明你学会了软件工程?
1)研发出符合用户需求的软件
必须公开发布,有实际的用户,一定的用户量和持续使用量 (3 天后能保持10 - 100个用户);而不是: 做没有用户使用的软件
2)通过一系列工具,流程,团队合作,能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护,有定时的进度发布 ; 而不是: 通过临时熬夜,胡乱拼凑,大牛一人代劳,延迟交付等方式糊弄
3)并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码,代码无文档,代码不能编译,没有task/bug 等项目的发展资料
请在随笔中用数据证明上述内容或侧重选择之一。
在博客中可以看到我们项目经过选题、需求分析、原型设计、代码实现、用户测试、最终成果。选题报告:http://www.cnblogs.com/zlxbky/p/7774087.html。
需求分析:http://www.cnblogs.com/zlxbky/p/7834324.html。
原型设计、代码实现、用户测试:http://www.cnblogs.com/zlxbky/p/7986891.html
http://www.cnblogs.com/zlxbky/p/8124241.html。
六*(选做)、阅读软件工程中关于代码质量的的经典论文,从下列文献中选择一篇或若干篇,结合自己的实际做一个阅读笔记(例如,自己写的代码质量如何,是不是一个大泥球,如何衡量自己代码的质量)?从以下参考论文中选择一篇或若干篇:
参考论文文献:
[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.
[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605
[3] Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87