201771030121-王国伟 实验四 软件项目案例分析

项目 内容
课程班级博客链接 https://edu.cnblogs.com/campus/xbsf/nwnu2020SE
本次作业要求链接 https://www.cnblogs.com/nwnu-daizh/p/12616341.html
我的课程学习目标 进行软件项目案例分析，接受这种分析过程
这个作业在哪些方面帮助我实现学习目标 实践中认识到问题，再去解决问题的过程
结对方学号-姓名 201771030129-张琳
结对方本次博客作业链接 https://www.cnblogs.com/zlin-/

一：任务一，在实验三得分100分以上作业中，任选一份作为案例，对案例项目成果进行评价

  1. 对案例博文作业进行阅读并进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系，并将以上评论内容发布到案例作业的博客评论区。

  1. 克隆案例项目源码到本地机器，阅读项目代码规范文档并运行代码，总结代码运行中存在的问题，体会案例博文是否有助于项目代码理解。

  • 克隆

  • 运行

  • 问题

    • 编码规范中没有说明代码编码类型。
    • 数据可视化没有整合到web页面中

  • 体会

    • 案例博文确实对于项目代码理解有一定作用，但由于不清楚编码类型，导致中文全是乱码，影响阅读
  1. 总结本组实验三博客作业及代码设计存在问题与不足，列举代码中存在的bug，未实现的功能等等。
  • bug
    • 由于编码方式不一致，在我的机器上移植运行之后会出现验证码失效的bug
  • 未实现功能
    • 提醒功能

二： 任务二，与实验三结对伙伴协作学习：阅读《现代软件工程—构建之法》第5-6章内容，理解并掌握软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则；

  1. 协作学习，进行线上交流分享总结

    微信图片_20200410215425

  2. 软件项目团队特点

    • 软件项目团队有各种形式，分别适用于不同的人员和需求；
    • 基于直觉形成的团队模式未必是最合适的；
    • 随着团队的成熟和环境的变化，团队模式会相互演化。

  3. 软件项目的模式

    • 主治医师模式：

      就像在手术台上那样,有一个主刀医师,其他人(麻醉,护士,器械)各司其职,为主刀医师服务。

    • 明星模式：

      主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他人的总和。

    • 社区模式 ( Community Model )

      社区由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。这种模式的好处是“众人拾柴火焰高”，但是如果大家都只来烤火，不去拾柴;或者捡到的柴火质量太差，最后火也就熄灭了。“社区” 并不意味着“随意”，-些成功的社区项目(例如开发和维护Linux操作系统的社区)，都有很 严格的代码复审和签人的质量控制。

    • 业余剧团模式 ( Amateur Theater Team )

      这样的团队在每一-个项目 (剧目)中，不同的人会挑选不同的角色。在下一个剧目中，这些人也许会换- -个完全不同的角色类型。各人在团队中听从一个中央指挥( 导演)的指导和安排。在学生实践项目或培训项目中，这样的事情经常发生。在业余玩票、培训的环境中，每个人可以尝试不同角色，大家还可以比较平等地讨论。但是在 竞争性强烈、创造性要求高的团队,不会存在完美的民主气氛，就像职业足球比赛，每个人的责任都不可或缺，但是不会每个人都有同样的控球时间。

    • 秘密团队 ( Skunk Work Team )

      一些软件项 目在秘密状态下进行，别人不知道他们具体在做什么。这种模式的好处是:团队内部有极大的自由，较高的热情，没有外界的干扰(不用每周给别人介绍项目进展，听领导的最新指示，等等)。一个团队的成员如果有很大的自由度，又有独特的使命，这对于大家来说，是很大的驱动力。这样的团队往往能发挥超高的效率完成看似不可能的任务。

    • 特工团队(SWAT)

      就像电影电视中的特工组“加里森敢死队”等- -样， 软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。

    • 交响乐团模式 ( Orchestra )

      交响乐团的演奏有下面的特点。 家伙多，门类齐全。各司其职，各自有专门场地，演奏期间没有聊天，走动等现象。演奏都靠谱，同时看演奏的都是练习过多次的曲目,重在执行。

    • 爵土乐模式( Jazz Band )

      强调个性化的表达,强有力的互动，对变化的内容给予有创意的回应。这样的团队模式和上面的“交响乐团模式”在很多方面都对立，但是两种模式都产生了很受欢迎的音乐作品，因此不能简单地说孰优孰劣。

    • 功能团队模式 ( Feature Team )

      很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。

    • 官僚模式( Bureaucratic Model )

      这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导，同时还混进了组织上的领导和被领导关系。跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。这种结构有一重大隐患， 在做绩效评估的时候，各个小老板、中老板都要为自己手下的弟兄们争名夺利，而有意无意地忽略了全局最优的绩效评估标准，导致很多无谓的算计、纠结、甚至有人会贬低别的团队的贡献。

  4. 瀑布模型及其变形

    • 瀑布模型：瀑布模型描述了单向的，不可逆的生产过程。
    • 变形：温斯顿指出用户的介入，讨论，复审以及模型下文档的重要性。

  5. 渐进交付流程

    接近迭代式开发流程，当系统的主要需求和框架明确后，软件团队进入不断演进的循环；

  6. 敏捷流程

    1. 尽早并持续地 交付有价值的软件以满足顾客需求

    2. 敏捷流程 欢迎需求的变化，并利用这种变化来提高用户的竞争优势

    3. 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短

    4. 业务人员和开发人员在项目开发过程中应该每天共同工作

    5. 以有进取心的人为项目核心，充分支持信任他们

    6. 无论团队内外，面对面的交流始终是最有效的沟通方式

    7. 可用的软件是衡量项目进展的主要指标

    8. 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去

    9. 只有不断关注技术和设计,才能越来越敏捷

    10. 保持简明一尽 可能简化工作量的技艺一极 为重要

    11. 只有能自我管理的团队才能创造优秀的架构、需求和设计

    12. 时时总结如何提高团队效率，并付诸行动

  7. 理解并体会TSP原则

    1. 使用妥善定义的流程，流程中的每一 步都是可以重复、可以衡量结果的。
    2. 团队的各个成员对团队的目标、角色、产品都有统一的理解。
    3. 尽量使用成熟的技术和做法。
    4. 尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
    5. 制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。
    6. 增加团队的自我管理能力。
    7. 专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计:工作(而不是在后期匆忙修复问题)。

三：任务三，在班级博客园，有很多高校的软件工程课程要求同学们完成团队项目，请与实验三结对伙伴协商，在以下三个班级中选择一个高质量的团队项目案例进行协作学习，要求追踪该团队项目发布所有博客作业，下载项目软件代码。

  1. 团队项目作业发布账号链接（1分）；

    https://www.cnblogs.com/snxfd/

  2. 团队项目仓库github链接（1分）；

    https://github.com/snxfd123/designfile

  3. 陈述你选择该团队项目进行分析的理由（5分）；

    1. 团队分工明确，目的统一
    2. 拥有比较完善的git仓库，各种文档都比较齐全
    3. 对自己的项目有比较完善的解释，可以在移植时拿来参考

  4. 结合项目系列博客文档，总结项目团队成员的分工合作情况（4分）；

    成员 分工内容
    姚玉婷 代码编写以及软件测试
    马丽莎 文档撰写
    孙苗坤 前端页面编写
    张 琼 软件测试

  5. 结合项目系列博客文档，评价项目的软件项目过程特点（TSP）（5分）；

    团队成员 分工 所占比例 任务实际完成时间
    姚玉婷 文档的整理与完善，PP制作，系统验收以及博客的专业 30% 6h
    马丽莎 文档的整理与完善，燃尽图的更新 30% 5h
    孙苗坤 文档的整理与完善 30% 4h
    张 琼 文档的整理与完善 25% 4h

    评价：每个阶段每个人的工作量工作任务不同，一个完整的团队必然是各个团队成员之间紧密配合的结果。就像盖楼房，一层没盖好之后的工作进展也就步履维艰了。

  6. 观察该团队项目github仓库的源代码文件结构，是否包含代码规范文档？（5分）；

    经观察，包含代码规范文档

  7. 下载团队项目代码，尝试部署项目运行环境并使用软件，描述最简单直观的使用体验，找出至少两个比较严重的功能性bug，在博客中展示截图（20分）；

    • clone

    • 部署运行

    • 使用体验

      1. 缺少使用说明（没有说明运行环境tomcat版本，jdk版本，mysql版本等）
      2. github中没有上传数据库的sql文件，只有数据库结构说明
      3. 页面设计比较保守，整体看起来设计不太新颖
      4. 数据显示栏目太少，实际情况可能会更多

    • bug

      1. 查看房间信息时数据库提示出现异常错误。

      2. 404错误，可能是由于tomcat版本问题，但由于博客中未注明，所以找不到

  8. 评价该团队项目是否值得继续开发，并陈述理由？（5分）

    不值得

    1. 同类系统太多，开发完成也没有太大效益
    2. 项目没有特色，不容易推广
    3. 基本已经开发完善，没有继续开发的必要

四：记录完成《实验四 软件项目案例分析》各项任务实际花费的时间

任务 花费时间
任务一 6 h
任务二 3 h
任务三 9.5 h
任务四 2.5 h

五：谈谈完成本次作业的感受和体会。（5分）

​ 本次作业，我通过学习课本内容，了解软件项目团队的特点、模式等等，又通过任务一和任务三的实践，实地了解其他团队的协作方式。更加明白团队合作的重要，希望以后在自己的实践中加以运用。





小记

  1. 这次项目给我最大的印象就是不仅要好好写代码，更重要的是要让自己的代码有用，可读，可移植，必要的文档，说明一个都不能少。
【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/wangguow/p/12677001.html