作业格式
- 课程名称：软件工程1916|W（福州大学）
- 作业要求：个人作业——软件工程实践总结作业
- 个人学号：221600308
- 作业目标：软工实践总结
作业正文
一、请回望暑假时的第一次作业，你对于软件工程课程的想象
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
"期待是希望在学习这门课的过程中，能够了解到软件项目开发的具体步骤，学习到如何使用测试 工具、维护软件等等，同时希望能够和同学们一起有一个让人满意的成果。"
- 以上是我在中对这门课的期待。回想当时其实对软工实践这门课有不少的抵触，因为大三下学期要准备的东西的确很多，而软工实践需要挤压准备其他东西的时间。
- 在软工实践的过程中，已经基本的达到了我期待的目标。我了解到了如何规范地开展一个项目，如何撰写规范的需求说明书、数据库说明书等等。也学习了如何写测试用例、使用loadround等测试工具来进行测试。
- 另外，我的代码能力也得到了提升，特别是在web前端方面，写了不少的css，也学习使用了vue框架。
- 最开心的是和男朋友一起拿到了小黄衫⁄(⁄ ⁄•⁄ω⁄•⁄ ⁄)⁄
- 不足的话是因为当初自己没有信心带一个团队，于是没有选择做自己一贯做的移动端的项目，导致这段时间对移动端的编码没有积累，也没有进行flutter的学习，只是搭了个环境。
"针对你的选择，你给自己的大三设定的规划安排是什么？"
学期初把手上的项目写完，尽量在大学生服外比赛中拿到好成绩。同时努力提高自己的绩点，在大三暑假之前考出雅思6.5以上的成绩，为申请学校做准备。争取能够找到一个暑期实习，这样就积攒到两个计算机相关的实习，为以后找工作增加实践经验。
- 虽然软工实践占用了很多时间，但大体上还是按照规划来的，我在服外比赛中拿到了国三，最近也有时间好好复习。虽然雅思这边稍微有不足，但是拿到了蚂蚁金服旗下的一个实习。也证明，好好安排时间，一切是可能的。
2）总结这门课程的实践总结和给你带来的提升：
1. 统计一下，你在这门软件工程实践中，完成了多少行的代码；
其实我的代码量并不是很多，我的任务量主要在文档、UI和测试用例上。
语言 代码行 HTML 420 CSS 110 swift 970
2. 软工实践的各次作业分别花了多少时间？
3. 哪一次作业让你印象最深刻？为什么？
- 这次的作业令我印象深刻，这是我第一次做原型，也是我难得的与同学进行合作的一次。之前虽然有组队参加比赛，但是主要还是各做各的，最后整合，没有共同负责同一个部分的。刚开始我们有不少分歧，但根据老师提示阅读《构建之法》之后，我们进行沟通解决了矛盾。
- 也让我发现其实我对UI设计有很大的兴趣，在完成作业之后，我还跑去实验室找设计组的组员要设计的书看，看完了一本《配色设计原理》。
4. 累计花了多少个小时在软工实践上？平均每周花多少个小时？
- 根据问题2给出的表格， 加上到现场答辩以及其他交流的时间，大概有近160个小时了，不算一下，自己也没发现居然有这么多的时间。平均下来，几乎每周都有12个小时左右。
5. 学习和使用的新软件&新工具；
- 因为软件和工具不好区分，这两个问题和在一起总结。
- 原型设计：墨刀、Photoshop
- 用例图、类图等：ProcessOn、StarUML
- 测试：LoadRound
- 代码管理：GitHub、GitLab
- Markdown: StackEdit、HackMD
6. 学习和掌握的新语言、新平台
- 前端vue框架、 深入学习了html
7. 学习和掌握的新方法；
- 单元测试
- VS的调试
8. 其他方面的提升。
- 多任务并行的管理能力
- 抗压能力
- 团队写作的能力
- 文字处理能力
- 自学能力和查资料能力
二、写下属于自己的人月神话
在团队项目实践中，队员们的实力不能没有差距但是也不能相差过大。因为如果全是很强的人，如老师所说，可能谁也不服谁，并不能作出1+1大于2的作品，但如果全是基础薄弱的人，所有人还得从头学起，不断乱撞，效率低下。一个团队需要较强的人进行指导，告诉其他人应该这么做做什么，这样可以节省时间。我们团队就是这样，我们的队长和将航对我们需要学的知识很清楚，直接告诉我们去学某某的某某部分，也不需要从头看起，节省了不少时间，也让我们一直有信心去做这个项目。但是差距不能过大，不然会造成沟通上的问题，也会心有余力不足。例如我们的队友没有web的基础，那如果叫他学vue的话必然要从头，花费时间太长，学其他的，也因为之前的基础不好，所以会将大多数时间放在学习上，而不是做项目上。
三、对下一届实践的建议等等。
下一届实践的建议：在组队时要对个人能力做一个调查，避免弱*弱=放弃的情况发生。但每个组的组员间能力差距不宜过大，不然有能力者拼命干，没能力者好好躺。另外我们实践是必修，这个模式是好的，老师和助教一直在把控我们实践的进度，让我们不需要在比如最后一个月之内狂赶。但个人建议，软工实践放在大二下或大三上会比在大三下比较合适。大三下大家都要忙着考研、就业、升学，如果不能很好地安排时间，那必有一个会所损失。如果把软工实践时间提前，其一，大家会从软工实践中发现自己的某些不足，在之后的学期中还有很多时间学习这方面知识，提高自己；其二，在大三下找工作之前就已经有了基本的项目经验；其三，不会给考研地同学增加太多压力，可以有更多的时间进行复习。
对开学初的自己：好好把握时间，治疗好拖延症和脱发。
对大一的自己：认真学习才是最重要的，找准方向深入研究，比什么社团学生工作都有用。
对后来人的期许：对于学弟学妹，相信他们能更好地完成更优秀的项目。
对于中途换队员：鼓励换。但建议可以让组与组之间投票决定要交换的组，交换的组员的负责方向尽量一致。
四、分析一下自己所处的团队。四个阶段。
- 萌芽阶段
最开始组队的时候，大家有很多想法都想要实现，一起讨论要做什么、用什么技术实现、实现哪些功能。 - 磨合阶段
之前主要是选题报告和文档的时候，大家用协同文档写各自的部分，最后发博客，没有出现什么问题。但之后alpha阶段就是我们团队的主要磨合阶段，那时候虽然对代码规范有了说明，但不少习惯还是不大好改，而且GitLab的使用也不熟悉，导致需要磨合。 - 规范阶段
在alpha之后到beta阶段，大家的分工更明确了，各种工具也更加得心应手，经过alpha阶段的敲打各项规范性也都有了相当大的进步。 - 创造阶段
创造阶段我们目前还有一点距离。
五、怎样证明你学会了软件工程？
1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
在我们beta结束之后的用户使用调查报告中可以看出，我们的网站满足大部分用户的需求。
2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
我们通过GitLab进行代码管理和协作，每个人都有分支，只有在分支中的代码ok，才会进行合并。此次的项目进度也一直在计划之内。
3）并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
虽然我们的代码没有公开，但是是有源代码的，而且每一个接口都有一个专门的markdown文档说明。
六*（选做）、阅读软件工程中关于代码质量的的经典论文，做一个阅读笔记？
In addition, there was a deliberate difference in quality emphasis in the two programming efforts: one was done by a “hotshot” programmer who was encouraged to maximize code efficiency, and one by a careful programmer who was encouraged to emphasize simplicity. The main results of the study were:
• Ten times as many errors were detected in the “efficient” program (over an identical series of 1000 test runs).
• The measures of program quality were significantly higher on the “simple” program; thus, they were good indicators of relative operational reliability, at least in this context.
————————Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]
- 通过阅读论文可以知道，不同的quality emphasis会产生不一样的结果。虽然你的程序看起来是“高效”的，但实际上更加容易检测出错误；虽然你的程序尽量“简单”，但他的可靠性可以达到良好。
Concurrently, other authors were recognizing the significance of characterizing and dealing explicitly with software quality attributes. Wulf [5] identified and provided concise definitions of seven important and reasonably non-overlapping attributes: maintainability/modifiability, robustness, clarity, performance, cost, portability, and human factors. Abernathy, et al. [6] defined a number of characteristics of operating systems and analyzed some of the trade-offs between them. Weinberg [7] performed experiments in which several groups of programmers were given the same assignment but different success criteria (development speed, number of statements, amount of core used, output clarity, and program clarity). For each characteristic, the highest performance was achieved by the group given that characteristic as its success criterion.
————————Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]
- 我们在日常的开发中不能有过多的偏颇，代码质量是依靠可测试性，简单性，可读性和可描述性等方面衡量的，不能追求高效而忽略了代码质量，从而也容易导致更多的bug出现。就自己的代码来说，我目前做到了可读性和可测试性（对代码进行规范和注释），但在简单性和可测试性上可能还需要加强。
七、个性发挥
- 软工实践开始到结束的这段时间，我的状态如下：
扫一扫
5795
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
