软工课程总结

一、软工初印象

  • 期待、目标和不足

    • 期待：坦诚的说，一开始没有很多期望，想着组队水一水，过了就行了，在组队后却成了队长，就期望着能和大家一起做东西出来，能让每个人得到不错的分数，以及有好的收获。
    • 不足：没有负责项目的代码部分，是很可惜的一点，但也是自己的选择，会利用寒假的时间去弥补这样的遗憾。
    • 目标：希望能在寒假完善好小二结账的商家端，也通过这个过程，弥补下在软工实践中缺失的部分。

  • 提升总结

    • 代码行数

      • 软工实践的代码大量集中在团队项目中，而我本身在团队项目中不主要负责代码部分，所以个人主要代码分布在个人项目和结对项目的代码，以及部分团队项目中的代码，一共只有只有1140行左右

    • 作业时间列表

      作业名称 耗时(h) 任务
      软工实践第一次作业 2 跟随问题引导，反思自己，做出预期
      个人作业-词频统计 15 复习c++，学习github使用
      第三次作业-结对作业（原型设计） 2 接触墨刀，尝试原型设计
      第四次作业 - 团队展示 5 设计团队头像，确定项目，开会讨论并拍照
      第五次作业 - 结对作业2 10 负责文本处理部分的代码
      第六次作业 - 团队答辩 10 开会确定团队的分配和管理，书写博客，ppt制作演讲
      项目UML设计 3 开了临时会议，紧急分配任务，并去别组制作UML图
      需求分析报告 10 项目logo设计，思维导图制作，博客整理
      团队现场编程实战（抽奖系统） 8 进度协调，需求分析，博客、文案撰写，演示视频制作
      Alpha 冲刺 50 机动+任务分配+答辩准备+美工设计+答辩准备+博客整理+拍摄演示视频
      Alpha 事后诸葛亮 1 博客整理，alpha反思，beta 计划
      项目测评（团队） 6 任务分配，ppt制作，演讲，博客整理
      BETA 版冲刺前准备（团队） 1 组织会议，反思总结，分配任务，博客撰写
      Beta 冲刺 30 机动+任务分配+答辩准备+美工设计+答辩准备+博客整理+拍摄演示视频
      本次作业 3 反思总结，博客撰写
      总计 221

    • 印象最深刻的作业

      • 现场编程实战作业
      • 我们在头一天的熬夜开会做了准备，提前配置好了了编程环境，在第二天拿到题目后，从一开始的懵逼，到冷静下来后的分析、分配和构建，到紧张编程到最后没有做出东西，再到任务的重新分配，以及之后一个下午+一个晚上的团队编程，最后终于成功做出东西并提交github。经历了一个软件完整的构建过程，有deadline的刺激、有团队的协作，有失败、有反思、有调整，最终也有了一个好的结果。是很棒、很难忘的经历！

    • 累计时长

      • 累计大约花了221个小时，按15周次来算，平均每周14个小时

  • 学习和使用的新软件

    • typora可以编辑markdown
    • 有道云笔记可以做笔记
    • 墨刀可以做原型设计
    • powerpoint的功能非常丰富且强大
    • 格式工厂对文件格式转换的处理很棒

  • 学习和掌握的新语言、新平台

    • 小程序开发平台
    • 学习了部分小程序的开发语言

  • 学习和掌握的新方法

    • markdown语法排版简洁明了
    • 创客贴和千图网都是很棒的素材网站
    • 阿里巴巴矢量图库有很多矢量素材，可以做ppt

  • 其他方面的提升

    • 做了三次ppt答辩，演讲方面得到了锻炼，提升空间很大
    • 做了四次ppt，收集了很多素材，也多了些设计思路
    • 博客整理，让我做笔记的整理更简洁、明了
    • 有道云笔记很好用，多端同步，很方便

二、人月神话

  • 个人作业

    个人作业难度是经过老师和助教讨论过控制在合理范围内的，对这个难度我觉得是，班上绝大部分同学自身通过花费时间学习，就可以完成地不错，但结果并不是绝大部分同学都能完成地很好，包括我自己也一样，排除个人能力的差异以外，更多的还是态度差异，有的人“想着怎么去完成作业”，有的人“想着怎么完成好作业”，类似于这样的态度差异，也决定了最终结果上的差异。

  • 团队作业

    在团队作业中当了小组长，所以对团队领导者的角色有了新的认识，作为一个好的团队领导者应该有两个基本的品质：一个是团队中必要且领先的个人能力，另一个是足够的个人魅力。

    作为我自己来说，在整个过程中，因为没有参与代码编写部分，在后期会感觉到与团队脱节，而作为队长又会大概率承担一些与项目无关的以外的事情，花费了很多时间，但却对自己的所需要的能力的成长帮助不大。所以我自己以后不会像这次软工一样，在没有相关能力和好的考虑情况下，草率地担任一个团队的领导者，那样对自己和对团队都不能够很好地担负责任，可能作为一个组员在团队中工作，提高自己的核心业务能力，同时向好的领导者学习管理经验，会是一个更好的选择。

三、前车之鉴

  • 建议、告知和期许

    • 期许：希望他们对自己想做的东西，能有更创新有趣的想法，也希望他们能收获自己想要的东西。
    • 建议：建议每个人都要参与代码的编程，不要留下和我一样的遗憾。
    • 告知：少熬夜！少熬夜！少熬夜！

  • 跳槽建议

    交换队员，更建议采取自愿，强制换队本意是好的，但这种骚操作很难把控利弊，容易翻车，造成不好的结果。

  • 人数

    人数在6-7人比较合适，任务量、沟通交流、团队协作都比较有利。

  • 作业规模

    • 个人作业：难度上，希望能让多数同学通过查询和学习能独立完成；任务量上，希望平均能在10h左右完成比较好。
    • 结对作业：难度上，还是要能让大多数人通过努力做出来，任务量上平坦下来，平均每个人在7-8h左右比较好。
    • 团队作业：团队项目因为是各组自定、老师审核，所以觉得提醒同学们，按自己的实际情况去自己选择项目的难度即可，作业量的话希望能简化一些内容，比如：每天的冲刺博客这种，虽然是课程要求，但做到最后反而成了负担，没有了促进作用。

  • 感谢的人

    感谢刘浩同学，从结对作业到团队作业都给了我很多的帮助，也向他学习了很多东西，具体不想谈，放在心里就好。

四、团队分析

回想起来，我们小组一路走过来还是很不容易。最初组建时候，人员配置缺少大佬和有开发经验的同学，队内其实有一种不够自信的因素在其中；到第一次答辩的项目选题答辩的时候，尽管答辩成绩还不错，但答辩结束后却又两位同学选择跳槽，成为全班唯二的跳槽同学。整个小组就显得有些出师不利、摇摇欲坠的感觉；然后，随着时间的推移，和不断的调整和努力，团队在一次又一次答辩中取得了不错的成绩，整个团队信心也越来越足，技术上也越来越成熟，不断遇到新的问题，不断解决新的问题；最后完成了完整的项目，也取得了不错的成绩，大家都收获很多，非常感谢这段经历！

五、软件工程

怎么证明你学会了软件工程？哈哈，对我而言这是个伪命题，当然是无法证明的。用一个学期的时间在课程要求的引导下，经历了一个完整的软件工程，用期末的三天时间粗读了软工的理论，所以不敢说自己学会了软件工程，只能是对整个软件工程的过程有所体悟，也在整个过程中有了新的收获。

对于项目的发布其实是比较可惜的一点，因为我们项目是基于微信平台的小程序，又涉及到支付的功能，所以本身具有很大的资质限制性，尽管我们已经尽最大努力去达成小程序的发布，但最终还是因为一个无法搞定的资质证书，宣告发布失败。但尽管如此，我们对项目自身的需求和可用性来讲都很有信心，作为一个软件也实现了完整的功能和交互。

六、阅读笔记

参考文献：

[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.

这篇论文主要介绍了关于开源软件的开发。开源项目的代码需要是”严格模块化，自包含，自我解释“，由于其它程序员可以自由读取、修改，加快了系统的演化速度，而审核代码质量的关键在于带啊吗是否有注释，编码是否贵伐以及代码的可扩展性和移植性。

七、个性发挥

  • 个人很喜欢自己为项目设计的宣传海报，所以最后的最后附在这里
posted @ 2019-01-09 11:45  小_H  阅读(263)  评论(1)  编辑  收藏  举报