个人作业——软件工程实践总结作业

最新推荐文章于 2024-09-30 11:32:01 发布

weixin_30606461

最新推荐文章于 2024-09-30 11:32:01 发布

阅读量119

点赞数

文章标签：移动开发数据库 python

原文链接：http://www.cnblogs.com/LuChenggang/p/10969547.html

版权

格式描述

课程：软件工程1916|W（福州大学）
要求：链接
学号：221600127
目标：回顾这学期的软件工程实践课程，总结收获

一、请回望暑假时的第一次作业，你对于软件工程课程的想象

1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？

个人认为在增强计算机专业能力的方面算是达成了目标。由于项目的相关性，我习得了与安卓开发相关的知识，这让我感觉成就感满满。同时与团队成员之间的交流与合作，使我体验到了团队合作编程，这也较符合我的预期。
但是由于是第一次较为大型的项目开发，我们小组的成员也都缺乏相应的经验。因此最后的作品可能会与当初的预期有所落差，这也是必然的。从我个人出发，我认为我们在项目初期的规划存在较大的不足，这些不足在越到项目后期暴露的越严重且较难修复，比如我们组在后期的开会中对前期的许多提议进行了完全的修改、数据库的设计也与初期的预想有着较大的改动。同时在项目分工方面也可能存在着一些不足，这与个人的意向有关。

2）总结这门课程的实践总结和给你带来的提升，包括以下内容：

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

完成了约8k行代码，但可能由于代码质量的关系，导致该数据有点虚高

2.软工实践的各次作业分别花了多少时间？（做一个列表）

作业	所花时间/h	学习和掌握的技能
第一次作业	3	发表博客记录自己的成长，MarkDown语法，反思过去
结对作业第一次	6	NABCD模型，墨刀
结对作业第二次	15	使用Python爬取网页数据，Vs性能测试，C++STL库的使用
团队作业第一次	0.5
团队作业第二次	5	进行选题
团队作业第三次	8	痛点分析
团队作业第四次	10	分析项目需求，撰写《项目规格说明书》
团队作业第五次	12	撰写《系统设计说明书》与《数据库设计说明书》
团队作业第六次	8	GitHub的使用，抽奖算法的随机实现，截屏软件
α冲刺	40	Android基础语法，AndroidStudio的使用
事后诸葛亮	4	回顾
β冲刺	70	Android与服务器交互，服务器端的搭建，第三方框架的使用

3.哪一次作业让你印象最深刻？为什么？

β冲刺，因为在α冲刺阶段更多的是在学习与安卓开发相关的基础知识。但是在β阶段我们将所学的知识真正的应用到了应用上，每做出一个功能点就能在手机上实时看到效果并且可以与组员分享喜悦，这种感觉使人满足并且印象深刻。

4.累计花了多少个小时在软工实践上？平均每周花多少个小时？

累计花了约180个小时在软工实践上，平均每周花12个小时。

二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析

在项目开始的初期，我们对所做的包括项目选题、原型设计、分析等都不太理解。我们不仅不太理解怎么去做这些，同时也不理解为什么要去做这些。因此，可能我们当初在起始阶段所做的工作就有着一定程度的缺陷，而这也在后来的冲刺阶段给我们带来了巨大的痛苦。很多时候我们感觉无从下手，只能一次又一次地集结组员开会，但显然这也于事无补同时效率也并非很高。比如原型的设计，我们后来真正开始实施界面时才发现最初的原型设计存在着诸多的问题，很多不需要的功能都有在原型设计中体现，而真正比较关键的功能在原型中却没有展示，这也导致了我们最后界面的成果可能不尽人意。
而我个人认为最有趣的环节还是每日的晚会环节，大家围在一起讨论项目的进度与问题，讨论今天的个人成就与明天的计划，展示成果等等。我认为这种氛围是很难得的同时也是很有益的。

三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。特别地，特别地，下一届要不要中途换队员？

个人认为软件工程实践这门课程所需要的时间还是过多，因为作为一门学分并不多的课程但实际占用的时间却极多。这个占用时间过多是相较于大三下来说，大三下有着较为繁重的升学或找工作压力，尤其是对于升学的人来说，就我个人而言，我认为软件工程实践是在一定程度上打乱了我的计划。因此，我建议将软件工程实践调整到大二下或者大三上，大家都有一定的基础而又有较多的空闲时间。但是，我认为软件工程实践确实是一次很宝贵的经历，虽然占用的时间较多，但还是值得的，有回报。
对于开学初的我，我会建议他一定要在初期做好准备工作，需求分析、原型设计等初期工作要做的充分。而我们小组当初在选题时放弃了几个过难但比较有想法的选题，或许当初坚持一下说不定会有更大的收获。
至于换队员，我们认为是可行的。就我们小组而言，新组员的到来为我们小组带来了一定的活力。而且我认为老师既然有考虑到项目的相关性的话，那么换组完全是可行的。

四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章人、绩效和职业道德）

萌芽阶段
刚开始选题的时候，我们小组一起聊天聊到了很晚。最后确定选题的时候，我们小组都对未来的项目充满了希望和热情。
磨合阶段
我们小组可能处于长期磨合状态，导致对项目开发的热情有所下降，自信心也有所下降。后期程度可能有一定的改善，逐渐迈向规范阶段。比如一些提议的最终确定及原本有异议的队员的让步。
规范阶段
在后期经过各种讨论确定了我们的目标后，我们的开发进度逐渐加速同时也变得规范起来。最后也算是做出了与预期相符的作品，虽然有一定程度的落差。但也算是进入了规范阶段的门槛了。
创造阶段
未经历过，很想但是受限于实际情况

五、怎样证明你学会了软件工程？

1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量（3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件

个人认为我们小组的选题还是符合用户需求的，只需再美化及添加相应的信誉分制度便可以完善我们的软件，达到拥有一定的用户量和持续使用量的目的。

2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄

通过Github签入代码，确认组员每天的工作任务是否成功完成。每天都有例会进行项目进度的汇报及未来的规划等。

3）并且通过数据展现软件是可以维护和继续发展的。
而不是找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料

代码有留下接口，同时也在GitHub上发布源代码

六（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：

参考论文文献：
[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