201771010103—陈亚茹—实验四 软件项目案例分析

项目	内容
课程班级博客链接	https://www.cnblogs.com/nwnu-daizh/
作业要求链接	https://www.cnblogs.com/nwnu-daizh/p/12616341.html
作业学习目标	（1）学习团队软件项目流程（TSP）、团队成员协作要求。（2）掌握敏捷流程原则及相关概念。
这个作业在哪些方面帮助我实现学习目标	这次作业主要是通过案例分析和学习帮助我来掌握知识技能
结对方学号-姓名	201771010111——李瑞红
结对方本次博客作业链接	https://www.cnblogs.com/LRHLRH123----/p/12677078.html

实验内容和步骤

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

（1）对案例博文作业进行阅读并进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系，并将以上评论内容发布到案例作业的博客评论区。
（2）克隆案例项目源码到本地机器，阅读项目代码规范文档并运行代码，总结代码运行中存在的问题，体会案例博文是否有助于项目代码理解。
（3）总结本组实验三博客作业及代码设计存在问题与不足，列举代码中存在的bug，未实现的功能等等。

将代码下载到本地：

• 由于GitHub网络状况太差连续几天登不上去，下载速度太慢，最后借用了gitee代码云将代码下载到了本地。
  
  

项目代码规范说明：

• 包名使用小写英文字母
• 接口类中的方法和属性不要加任何修饰符号（public也不要加），保持代码的简洁性
• 获取单个对象的方法用get做前缀
• 插入的方法用save（推荐）或insert做前缀
• 删除的方法用remove（推荐）或delete做前缀
• 如果是大括号内为空，则简洁地写成{}即可，不需要换行；如果是非空代码块则：
  • 左大括号前不换行
  • 左大括号后换行
  • 右大括号前换行
  • 右大括号后还有else等代码则不换行；表示终止右大括号后必须换行
• 缩进采用4个空格，禁止使用tab字符
• 一行代码不超过120个字符
• 遇到其他同行可能不易看懂的内容时，在代码上一行使用“//”进行注释
• 声明字符串常量：命名不不可以英文和拼音混合使用
• 一行声明一个变量
• 在对变量命名时，避免过多的描述
• 避免可要可不要的修饰
• 按照如下顺序来说明类中的成员：public、protected、private
• 检查new的返回值
• 释放指针时不用检查NULL
  总结：项目团队所制定的代码规范符合简明易读且无二义性的代码风格，也符合每个函数只做好一件事的原则。

功能测试说明：

实验要求为:

• 可采集全校各类师生员工疫情信息；
• 各二级部门疫情防控工作负责人可查看本部门人员疫情汇总，并提供高级查询功能进行多属性组合查询和可视化统计功能；
• 学校防控办指定负责人登录《西北师范大学疫情防控信息统计》子系统，可浏览所有人员填报汇总数据清单，利用【高级查询】可进行数据组合筛选，系统以图形化方式展示各学院已填报和未填报学生统计情况和关键疫情数据统计情况，可【导出】查询列表的EXCEL文件；
• 人机交互界面要求GUI界面（WEB页面、APP页面都可）；
• 附加分功能：定时填报提醒

经过反复测试，得到系统实际实现的结果为：

• 系统实现了采集全校师生员工疫情信息的功能。
• 二级防疫部门和其他人填报的页面是是权限分开的两个相同页面。
• 防疫部门普通工作人员可以浏览所有填报信息。
• 二级部门负责人可以浏览本部门所有成员填报信息，增删查本部门填报信息并得到感染情况统计图。
• 防控办负责人可以浏览所有成员的填报信息，并实现更全面的增删查和以及学生和教职工分别的信息汇总。
• 实现了定时填报提醒功能。

功能展示：

• 学生登录下(可以进行疫情填报)：
  
• 二级防疫部门成员登录下：
  
• 二级防疫部门负责人登录下：
  • 登录界面
    
  • 展示所有二级防疫部门成员填报信息
    
    -查询某天填报信息
    
• 防控办成员登录下：
  
  
• 感染情况统计（不知道是不是测试之时数据库中数据太少，柱状图的数据对比不是特别明显）：
  
• 填报信息统计：
  

bug说明：

• 二级防疫负责人在进行学号准确查询时可以查询到所有成员的信息，但是在姓名模糊查询和时间准确查询时却只能查询到本部门成员的信息，不知道这算不算是权限管理上面的小小bug。
  
• 系统对用户输入的控制比较低，比如完全不进行输入也可以实现添加，时间统一为1900年1月1号。输入完全相同的信息也不会报错。
  
• 系统对闹钟的用户输入没有控制，不管输入什么，程序都正常运行。
  
  总结：本系统是一个纯java开发的系统，系统实际实现功能权限比较分明，实现功能也很全面。足以见得结对小组的两个人在系统功能设计上面做了详细的分析设计，代码编写过程也基本遵照了团队的代码规范。最后看了结对成员的博文，博文对项目描述很全面，PSP也做的很详尽，有利于读者对系统功能的理解和应用。但是系统对用户的输入控制比较少，而一个系统最不能相信的就是用户输入，错误的用户输入可能会造成比较严重的后果。但是不论如何，短时间内能做到这样，我自己肯定无法企及，还是应当向两位结对成员学习。

案例作业博客链接：https://www.cnblogs.com/litinghua/p/12534838.html

案例作业项目仓库链接：https://github.com/wyq1998/System-second

博客评论：

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

博客作业中针对任务2的评分要点：提供两人讨论任务2学习内容的微信或QQ截图，要求截图美观。

软件项目团队的特点：

• 团队有一致的集体目标，团队要起完成这目标。
• 团队成员有各自的分工，互相依赖合作，共同完成任务。

软件团队的模式：

模式	特点
一窝蜂模式	没有明确分工，存活时间不长。
主治医师模式	首席程序员（后备程序员、系统管理员、工具开发、编程语言专家、业务专家）负责主要模块设计和编码，其他程序员从各种角度提供支持。
明星模式	首席程序员过于突出和个性化、团队处于解体边缘。
社区模式	有很多志愿者参与，每个人参加自己感兴趣的项目，贡献力量。需要严格的代码复审和签人的质量控制。
业余剧团模式	在项目中，不同的人挑选不同的角色，下一个项目中可以换一个角色，各人在团队中听从中央指挥的指导和安排。
秘密团队	项目在秘密状态下进行，团队内部有极大的自由，往往能发挥出超高的效率，完成看似不可能的任务。
特工团队	团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。
交响乐团模式	团队各司其职，完成任务。某软件领域处于稳定增长阶段时，一些大型软件公司会采取这种模式。
爵士乐模式	强调个性化的表达，强有力的互动，对变化的内容给予有创意的回应。
功能团队模式	具备不同能力的同事们平等协作，共同完成一个功能。
官僚模式	成员之间不仅有技术方面的合作和领导，还混进了组织上的领导和被领导关系。如果应用不好，会有编程“老板驱动”开发流程的重大隐患。

瀑布模型：

• 概述：瀑布模型:将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。其过程是将上一项活动的输出作为该项活动的输入，利用这一输入实施该项活动应完成的内容，然后对当前活动的工作结果进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。
• 传统的瀑布模型：
  
  • 瀑布模型的优点：
    • 为项目提供了按阶段划分的检查瀑布模型查点。
    • 当前一阶段完成后，只需要去关注后续阶段。
    • 可在迭代模型中应用瀑布模型。
    • 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
  • 瀑布模型的缺点：
    • 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
    • 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
    • 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
    • 瀑布模型的突出缺点是不适应用户需求的变化。
    • 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
• 传统的瀑布模型过于理想化,早期的错误只有等到开发后期才能发现，进而带来严重的后果。温斯顿先后三次改进了模型：
  • 在设计大型系统时，要做相邻步骤的回溯，解决上一阶段未能解决的问题。
  • 要让产品成功，最好把这个模型走两遍，在此基础上收集反馈，改进各个步骤，并交付一个最终的版本。
  • 用户的及早介入、讨论、复审是重要的。要让顾客正式地、深入地、持续地参与到项目中来。最终版本为：
    
• 瀑布模型在软件工程实践中的局限性:
  • 各个步骤分离，但是在软件生产过程中的各个步骤不能这样严格分离。
  • 回溯修改很困难，但是软件生产中却需要时时回溯。
  • 最终产品直到最后才出现，但是客户以及软件工程师本人都需要尽早知道产品原型并试用。
• 瀑布模型的变形
  • 生鱼片模型：解决了各个步骤之间分离的缺点。
  • 大瀑布带着小瀑布：解决不同子系统之间进度不一，技术要求迥异，需要区别对待的问题。

渐进交付流程：

• 概述：接近近迭代式开发流程，当系统的主要需求和架构明确之后，软件团队进入一个不断演进的循环中。
  

敏捷流程：

• 开发原则：
  • 尽早并持续地交付有价值的软件以满足顾客的需求。
  • 敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势。
  • 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短。
  • 业务人员和开发人员在项日开发过程中应该每天共同工作。
  • 以有进取心的人为项目核心， 充分支持信任他们。
  • 无论团队内外，面对面的交流始终是最有效的沟通方式。
  • 可用的软件是衡量项目进展的主要指标。
  • 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去。
  • 只有不断关注技术和设计，才能越来越敏捷。
  • 保持简明 ———— 尽可能简化工作量的技艺 ———— 极为重要。
  • 只有能自我管理的团队才能创造优秀的架构、需求和设计。
  • 时时总结如何提高团队效率，并付诸行动。
• 步骤：
  • 找出完成产品需要做的事情。
  • 决定当前冲刺需要解决的事情。
  • 冲刺，团队通过每日例会来进行面对面的交流，大家一次报告昨天做了什么，今天要做什么，碰到了哪些问题。
  • 得到一个软件的增量版本，发布给用户，在此基础上又进一步计划增量的新功能和改进。
• 敏捷团队的要求：
  • 自主管理:以前领导布置了任务，我们实现就可以了，现在要自己挑选任务:每次Sprint结束之后，还要总结不足，提出改进，并且自己要实施这些改进。自主管理”不等于“没有管理”。
  • 自我组织:以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。
  • 多功能型:以前规格说明书由PM来写，测试由测试人员来做，现在每个人都全面负责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。

TSP原则：

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

聊天截图：

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

1. 2016级计算机科学与工程学院软件工程 (西北师范大学)
2. 2019秋福大软件工程实践Z班 (福州大学)
3. 2019春季计算机学院软件工程 (北京航空航天大学)

团队项目作业发布账号链接：https://www.cnblogs.com/PureMan6/p/10739662.html#4

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

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

• 选择该团队进行项目分析的原因是自己从来没有参与到任何的软件开发活动当中去，看到作为大学生，他们能把日常我们学习中经常使用到的网站开发成为手机软件，是一个非常好的创意，自己也是抱着学习的心态。而且，手机博客园对于学生来说的确能在一定程度上带来方便。
• 该软件已经可以在大多数的主流手机上可以安装运行，项目团队对主流的50款手机进行兼容性测试的结果是在腾讯的适配标准下，软件第一个版本50款手机的适配通过率达到了94%。随后经过调试，达到了100%。可以说是一个非常成功的学生开发项目了。

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

• 成员分工如下表：
  
• 团队里有3.5位开发人员，1位测试人员，1.5个项目经理。
• 开发人员负责实现客户端的功能，界面。我们主要需要调用博客园提供的API，配合一些组件，来实现功能。最开始的分工是大家各自负责自己的功能，然后在例会上交流遇到的障碍或者取得进度，确定把功能加入哪里，保证大家大家UI的统一，同时也有两位开发定期统一所有的界面和美化。
• 测试人员负责完成客户端的兼容性测试、压力测试，各个功能的集成测试。
• 项目经理负责完成各种文档，组织开会，安排任务推进项目，与相关人员沟通，做调研，推广。

项目的软件项目过程特点（TSP）：

• 项目使用了敏捷开发流程，这种开发流程节奏快，效率高，对成员的专业能力要求较高，团队里面每个人基本上都做了自己比较擅长的方面。
• 项目分了Alpha、Beta、Gamma三个阶段，每个阶段都进行了10次每日例会。对例会结果撰写文档，文档合集：https://www.cnblogs.com/PureMan6/p/10673298.html
• 团队前期进行了花了较长的时间确定项目方向和学习相关知识。一直到Alpha阶段第4次每日例会才正式进入软件编码。
• 整个项目过程中，团队每一天都会重新明确分工，完成相应的任务。
• 在项目进行中，团队成员始终处于边开发边学习的状态，遇到困难是集体查阅相关资料克服，解决问题后撰写技术博客。
• 项目在Alpha、Beta、Gamma三个阶段分别进行了阶段性结果的发布和测试，所以很多问题都是在早期就解决掉了，在每个阶段结束后团队都要进行开发经验的总结。

GitHub上源代码如下图，源代码中缺乏代码规范描述、也没有README文件等对系统必要的说明，个人认为在代码复审过程和代码测试过程中可能会带来一些不方便之处，也不便于他人对系统代码的阅读。

我们测试了北京航空航天大学团队开发的博客园移动端APP：

• 软件下载途径：
  
  软件使用测试：
• 软件打开页面和登录页面(与网页端相同)：
  
• 功能试用：
  • 主界面：
    
  • 状态栏消息提醒功能实现(为这个功能点赞)：
    
  • 浏览博文页面：
    
  • 账号所在班级列表页面展示(每个班级和仓库一样，选择之后整个软件只显示本班级所在的相关信息)：
    
  • 作业提交界面：
    
• 软件bug说明：
  • 软件后台运行一段时间之后会显示身份信息过期，但软件实际上仍然可以正常使用。
    
  • 软件投票功能不稳定(发布投票成功率并不高，且一旦成功发布，则没有办法删除，删除键无效)：
    
  • 软件页面显示存在问题：
    • 仅能显示手机屏幕宽度的内容，缺少一个滑动条(为了对比明显，此功能在暗黑模式下展示,暗黑模式位于设置功能目录下，实现不完整，但是也是一个非常优秀的功能尝试，不影响正常使用，所以不列为bug，毕竟微信也是今年才有这个功能，对比下已经显得很优秀了)。
      
    • 班级列表中一个班级头像不能显示(但是在网页端这两个班级都是有头像的)。
      
  • 提交列表存在问题(如图显示已有69人提交了作业，但提交列表空空如也，无法显示)：
    

项目是否有继续进行开发的必要。

• 在我个人看来，这个项目其实已经算是比较成功了，就算不会继续进行开发和改进，我可能也会继续使用这个软件,毕竟电脑并不是可以随时随地携带的，手机软件会带来很多方便。
• 客观来讲，首先软件目前出现的bug基本上都不会非常严重的使用体验感，即系统在比较重要的功能上面都没有出问题，其次，纵观整个开发过程，这个软件的开发成本还是比较小的，在可以承受的范围之内。
• 使用博客园的计算机行业从业者和学生并不在少数，这个APP可以满足基本的博文浏览和提交功能，因而潜在的市场还是比较大的。在手机上完成博客撰写本来就是不方便和不现实的，所以软件避开这个功能的实现也是合理的，也就是说，目前软件所欠缺的功能其实并不是很多。
• 综上所述，我认为这个项目是值得继续开发的。

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

任务	耗时
任务1	2h
任务2	3h
任务3	5h
任务4	2h

总结：

• 这次实验主要进行了优秀案例的跟踪和学习，通过这次实验，我对开发流程和步骤有了相较清晰的认识。同时也看到了团队在开发项目时所付出的百分百努力，看到了我们之间的差距。例如最后一个案例提交次数达到七百多次，前后推出了三个阶段性测试版本。我也注意到了团队开发过程中对经验积累和不断总结提升的重视。从他们身上有许多值得我去学习和借鉴的东西。