201771030111-刘维 实验四 软件项目案例分析

项目	内容
班级博客	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE
作业链接	https://www.cnblogs.com/nwnu-daizh/p/12616341.html
学习目标	了解并掌握软件工程的相关知识及其应用
作业目标	（1）学习团队软件项目流程、团队成员协作要求。（2）掌握敏捷流程原则及相关概念
结对搭档	李松榆-201771030110
结对方本次实验博客链接	https://www.cnblogs.com/Unicorn-snow/p/12670881.html

任务1：实验三优秀案例分析（张芹&李佩杉组）

1.案例作业博客链接：https://www.cnblogs.com/zhangqin1/p/12580394.html

2.案例作业项目仓库链接：https://github.com/lipeishan82/EPS

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

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

 ①登录部分：（此系统可根据不同身份进行选择并登录系统，老师和学生所登录的打卡系统会受到时间的限制）

  

 错过打卡时间提醒信息：（若超过当日早上十点，则不能再进行打卡）

  
  
 ②疫情上报部分：（学生和老师进入的疫情上报子系统）

  
  
  
 填报定时提醒:

  
  
 ③二级管理员部分：（若二级部门登录成功，则会根据数据库中的信息判断该管理员的所在学院，此处以物理学院为例）

  
 简单查询功能：

  
 高级查询功能：

  
 关键疫情信息统计功能：

  
 ④学校疫情防控办：（能够查询所有疫情信息且高级查询功能并能对查询信息做导出工作）

  
 高级查询功能：

  
 导出Excel功能：

  
  
  
  
  
 关键信息统计：

  
 学院填报比例：

  

5.总结本组实验三博客作业及代码设计存在问题与不足，列举代码中存在的bug，未实现的功能等等。

  通过对张芹组优秀案例的学习，我学到了很多关于博客书写和代码设计的技巧。该组实验三博客结构清晰，内容层次性强，从而使读者可以通过阅读博客来迅速掌握该软件的设计思路和使用方法。从代码设计的角度上来看，该组代码设计实现了需要分析中声明的包括打卡提醒的全部内容。并且代码在一定程度上实现了程序的模块化，将实现数据库连接类和数据操作的类以及其他的类各自分开，使得代码逻辑性强，结构层次清晰，提高了可读性和可维护性。代码书写风格也比较规范。

  当然，我也发现了该代码设计中存在的两个问题：

  ①导出excel的保存路径以及excel的保存名无法通过用户手动进行选择，于是当用户想保存两张不同的excel表时就会发生覆盖，这在一定程度上是很不智能的

  

  ② 打卡提醒显示在信息填报页面不甚合理，换言之，如果用户已经开始填报信息，则不存在需要提醒的必要

  

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

1.软件项目团队的特点:

(1)团队有一致的集体目标， 团队要一起完成这目标。一个团队的成员不一定要同时工作，但是一定要为了目标共同努力。

(2)团队成员有各自的分工，互相依赖合作,共同完成任务。每个人不仅要为自己的工作负责，还要彼此协作。

2.软件团队的模式：

（1）主治医师模式：

  就像在手术台上一样有一个人主刀，其他人各司其职，协助主刀医师。

（2）明星模式：

  将主治医师模式运用到机制就是明星模式，但团队模式强调的是团队的作用，而不是个人的独角戏，这种模式显然违背了团队模式的初衷，效率也很低。

（3）社区模式:

  由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。例如Linux操作系统的社区，但像这样的成功案例往往需要严格的代码复审和签入的质量控制。

（4）业余剧团模式:

  团队中各人扮演各人的角色。在开发之余、培训的环境中，每个人都可以尝试不同角色，大家可以比较平等地讨论。

（5）秘密团队:

  软件项目在秘密状态下进行，这样的模式最好的就是内部人员有极大的自由，较高的热情，没有外界的干扰。但不可能成为普遍模式，只会针对个别项目。

（6）特工团队:

  软件团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。这个模式的效率很高，但对成员的知识面要求很广，不会成为普遍模式。

（7）交响乐团模式:

  团队里的人各司其职，想交响乐队一样。大家各司其职，重在执行。

（8）爵士乐模式:

  该模式与交响乐模式存在相当多的对立。一般形式为领导给出一个主题，然后成员们百花齐放，各显本领，快收尾时再总结。而这要求团队里的人员不能太多。

（9）功能团队模式:

  在这样一个团队中，具备不同能力的程序员平等协作完成一个功能。这样的效率高，但每个小组必须与其他小组就编程规范达成一致。

（10）官僚模式:

  脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次向上。有助于技术的交替与互补，容易掺杂一些追名逐利，往往会使团队效率大打折扣。

3.理解瀑布模型及其变形：

 (1)瀑布模型是一个经典的软件生命周期模型，也叫预测型生命周期、完全计划驱动型生命周期。在这个模型里，在项目生命周期的尽早时间，要确定项目范围及交付此范围所需的时间和成本。

  在这个模型里，项目启动时，项目团队专注于定义产品和项目的总体范围，然后制定产品（及相关可交付成果）交付计划，接着通过各阶段来执行计划。应该仔细管理项目范围变更。如果有新增范围，则需要重新计划和正式确认。对于经常变化的项目而言，瀑布模型毫无价值。

 (2)瀑布模型的特点：

  ①从上一项开发活动接受其成果作为本次活动的输入。

  ②利用这一输入，实施本次活动应完成的工作内容。

  ③给出本次活动的工作成果，作为输出传给下一项开发活动。

  ④对本次活动的实施工作成果进行评审。若其工作成果得到确认，则继续进行下一项开发活动；否则返回前一项，甚至更前项的活动。尽量减少多个阶段间的反复。以相对来说较小的费用来开发软件。

 (3)瀑布模型的局限性如下：

  ①各步骤之间是分离的，但是软件生产过程中各个步骤不能这样严格分离出来；

  ②回溯修改很困难甚至不可能，但是软件生产的过程需要时间回溯；

  ③最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用。

 (4)瀑布模型主要适用于以下情况：

  ①如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证；

  ②产品模块之间的接口，输入和输出能很好地用形式化的方法定义和验证；

  ③使用的技术非常成熟，团队成员都很熟悉这些技术。

  ④负责各个部分的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流。

 (5)改进的瀑布模型：

  
 (6)瀑布模型的变形：

  瀑布模型的变形主要有生鱼片模型、大瀑布带着小瀑布、子瀑布模型等，但每个模型均有其缺陷。

  生鱼片模型：

  这个模型解决了各个步骤之间分离的特点，但是无法判断上一阶段究竟什么时候结束的问题；

4.渐进交付流程：

这个流程是史蒂夫●迈克康奈尔在1996年总结的，其实很接近现在大家谈论较多的迭代式开发流程。当系统的主要需求和架构明确之后，软件团队进人了一个不断演进的循环中:
  
5.敏捷流程：

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

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

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

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

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

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

6.TSP原则：

 （1）使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的。

 （2）团队的各个成员对团队的目标、角色、产品都有统一的理解。

 （3）尽量使用成熟的技术和做法。

 （4）尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。

 （5）制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。

 （6）增加团队的自我管理能力。

 （7）专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。

 学习截图：

    

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

1.团队项目作业发布账号链接：https://www.cnblogs.com/PureMan6/

2.团队项目仓库github链接：https://github.com/swearitagain/EduCnblogs2.0

3.陈述你选择该团队项目进行分析的理由：

  ①作为博客园的使用者，我对他们实现手机版博客园的项目抱有很大的兴趣。

  ②以前没尝试过安卓应用的开发，想借此机会学习一下。

  ③想看看我和重点大学的学生差在哪里。

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

• 开发：胡俊崧、蒋锋、陈治齐、张进
• 测试：曾林思、吴昊
• PM：邵旭哲

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

  ①使用了妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的。

  ②团队的各个成员对团队的目标、角色、产品都有统一的理解。

  ③使用了成熟的技术和做法。

  ④尽量多地收集了数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。

  ⑤制定了切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。

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

  该团队项目github仓库包含代码规范文档，且源代码书写风格符合代码规范。

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

 (1)运行效果：
  ①登录界面：
    
  
  ②我发表过的博客：
  
  ③班级信息部分：
      
      
  ④个人信息部分：
  
  ⑤黑暗模式：
  
 (2)运行过程中的bug：
  使用该APP浏览博客时图片与文字尺寸差距过大，文字无法随着网页缩放自动填充，观感不好：
  
8.评价该团队项目是否值得继续开发，并陈述理由？
  我觉得改团队项目值得继续开发。首先，博客园的确实缺少手机版本，该项目的开发使得用户可以在可以在手机上登陆班级博客，可以让同学们的学习更加方便。其次，该项目开发过程中国所涉及到技术具有很强的现实意义，软件开发的实践性可以极大提高开发者的编程能力。作为一名使用者，我也希望这个APP能越做越好。

任务4：完成《实验四 软件项目案例分析》博文作业：

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

项目	计划时间	实际用时
任务一	60min	80min
任务二	200min	180min
任务三	200min	300min
任务四	60min	90min

2.总结
  在任务1的同班优秀案例学习过程中，我从目标同学的博客以及代码中学到了很多实用的技巧和方法。在任务三里，我选择学习了北航大学学长的项目，而他们的实力也给了我巨大的震撼。相比于优秀的北航学长学姐，我的能力看起来是微不足道的。我想，或许天赋有一部分的原因，但是绝大部分的原因应该在于我自身。当然，临近大四，我也会加强编程练习，向着优秀的人学习。