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

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

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

答：对于课程期待，让我第一次了解关于项目的开发整个过程，学习到了关于代码规范、测试等，通过alpha阶段和beta阶段去完善项目，项目就好比初生的萌芽，逐渐发育成一课树苗，并且不断进行分支，每块逐步壮大起来。除此之外，让我了解通过团队进行开发项目，利是大于弊的。

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

  • 1）统计一下，你在这门课程中，完成了多少行的代码；
    • 400~500行
  • 2）软工的各次作业分别花了多少时间？（做一个列表）
作业 时间
软工网络15个人阅读作业1 2小时
软工网络15个人阅读作业2——提问题 5小时
软工网络15结对编程练习 8小时
软工网络15团队作业1——团队组队&展示 2小时
软工网络15个人作业3——案例分析 3小时
团队作业3——需求分析与设计 5小时
团队作业2——团队计划 2小时
软工网络15Alpha阶段敏捷冲刺 48小时
团队作业6——展示博客 2小时
团队作业5——测试与发布 2小时
团队作业7——alpha阶段之事后诸葛亮分析 2小时
个人作业4——alpha阶段个人总结 2小时
团队作业8——敏捷冲刺（Beta阶段） 36小时
beta阶段验收互评 2小时
个人作业5——软工个人总结 2小时
总计 123小时
  • 3）哪一次作业让你印象最深刻？为什么？
    • 比较深刻的一次是alpha阶段的冲刺博客，我学到新的关于网站搭建、数据库的建立与实际项目联系等等，通过几次例会去发现问题，大家一起探讨解决方案。
  • 4）累计花了多少个小时在软工上？平均每周花多少个小时？
    • 总的123个小时左右，平均每周9个多小时（3~15周）
  • 5）学习和使用的新软件；
    • vs2017，markdown，mysql，eclipse等
  • 6）学习和使用的新工具；
    • Xmind，Mockingbot ，startuml ，process在线作图
  • 7）学习和掌握的新语言、新平台；
    • Github，码云
  • 8）学习和掌握的新方法；
    • 原型设计，uml图的绘制，需求分析的NABCD模型，框架开发
  • 9）其他方面的提升。
    • 主要了解了开发软件的整个流程，学会写文档，使用github管理代码，以及明白代码规范的重要性。

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

  • 1、团队沟通非常重要。因为每个人都有不一样的分工，每个模块之间的协作需要团队成员之间的沟通。
  • 2、分工要明确。我们团队一开始分工不够明确，差不多每个模块每个人都有接触，有时某个模块卡住了，大家也都卡住了，效率非常低。后来我们渐渐地明确了分工，我负责的是后端开发，给前端返回相应的数据库数据。
  • 3、编码前的需求分析，类图，设计文档等一定要认真对待。因为这些将作为后面编码阶段的依据。

三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。对于换人机制，有什么样的建议？

答：对于大一大二的阶段来说，像代码规范这类的习惯，就应该及早养成，这样会利于团队的开发。可以去多接触一些其他语言或者工具，而不单单说这学期课程是java，那么就只学一门。通过实际的项目发现，有时候需要
多种语言和工具才能实现最终效果。当软工开始再学习的话，时间是不多的，学习效果也不那么好。如果之前有学习过，那会更容易上手一个项目。对于换人机制，老师的初衷想让我们体验一下，在未来工作中进行团队开发，如果遇到意外事故、跳槽等，这样会给团队项目造成什么影响，那么该如何处理团队项目？这个换人机制是不错的，但实际中发现，换的人一般都不是团队开发的核心，可以说大半部分是无关紧要的人，比如说，负责写博客来说，到哪个团队都可以写。

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

答：构建之法提到的阶段有：萌芽阶段、磨合阶段、规范阶段、创造阶段。在本团队开发前三个阶段经历的时间比较长，最后一个“创造”阶段往大的说是没有的，我们团队是参考淘宝、京东这些购物网站，实现一些功能。往小的说是有的，因为我们目标是为个体商户去设计的，实现一对多的售卖，相当于个人的超市。

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

1. 研发出符合用户需求的软件

  • 必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
    • 项目没有公开发布，只是在舍友之间测试过。

2. 通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件

  • 有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄

3. 并且通过数据展现软件是可以维护和继续发展的。

  • 而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
posted @ 2018-06-17 09:03  Min21  阅读(260)  评论(1)  编辑  收藏  举报