201771030115-牛莉梅 实验四 软件项目案例分析

项目	内容
课程班级博客链接	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE
这个作业要求链接	https://www.cnblogs.com/nwnu-daizh/p/12616341.html
我的课程学习目标	1、熟练博客操作 2、掌握软件项目个人开发流程 3、掌握Github的操作方法
这个作业在哪些方面帮助我实现学习目标	1、锻炼了我的动手能力 2、让我在找寻别人错误的同时发现自己的错误
结对方学号-姓名	<201771030120-王嫄>
结对方本次博客作业链接	https://www.cnblogs.com/Jenna-wang/p/12631798.html

一、任务1：这里我选取的是李婷华&王颖奇组

https://www.cnblogs.com/litinghua/p/12534838.html#4541150
https://www.cnblogs.com/1556889081wyq/p/12546166.html

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

1、案例作业博客链接：李婷华博客链接

2、案例作业项目仓库链接: 李婷华组仓库链接

3、符合（1）要求的博客评论

4、符合（2）要求的系统运行截图、软件功能总结；附加分要求：若测试发现案例代码存在bug，截图为证.

案例博文在软件设计说明那一块写的非常详细，包括数据库的表结构，软件功能以及主要的类代表的含义及功能等，这极大的方便了读者去使用软件，其中，案例博文的注释等内容也十分详细，使得代码容易理解。

软件功能总结：

• 软件功能：

  • 师生可登录系统进行疫情信息的填报；
  • 二级防疫部门人员可进行疫情信息的填报；
  • 二级防疫部门负责人可对本部门人员的信息进行增删改查，可根据姓名进行模糊查询，根据学号、填报日期、感染情况进行准确查询，可查看感染情况的统计数据（用柱状图来表示），这里的感染情况查询是查看具体的某一天。
  • 学校防控办人员可以进行增删改查等功能，可以按照学号、时间、感染情况等进行准确查询，按照姓名进行模糊查询，可查看感染情况和填报情况的统计数据，可以查看学生和教职工统计信息的汇总。

• 软件功能图:
  

系统运行截图：

学生登陆系统

• 登陆：
  

• 填写信息：
  

二级防疫部门人员系统

• 登陆：
  

• 填写信息：
  

二级防疫部门负责人系统

• 登陆：
  

bug1：二级部门负责人的增加别的学院的，也显示加入成功，此处应该对学院一栏做一个限制。

• 增加：例如：输入数统院，也显示插入成功。
  

bug2：这里的删除操作只能进行一次，如果想继续删除，则无法实现，需要重新运行程序。

• 删除：例如：删除刘鹏的信息，虽然显示删除成功，但数据还在。
  

• 删除后：
  

• 修改：修改前后对比图如下
  

• 学号准确查询：
  

• 姓名模糊查询：
  

• 时间准确查询：
  

• 感染情况查询：
  

• 感染情况统计图：
  bug3:这里必须输入日期才可以查询到正确地结果，但是并未有明显的提示，如果使用者按照其他条件查询统计图，就不会有正确的显示
  

• 错误的显示：
  

校防控办负责人系统

• 登陆：
  

• 增加：
  

• 删除：
  

• 删除后：可以看到刘鹏的信息还在上面，即使更新也没有作用，这也就是前面说的bug2。
  

• 修改：
  

• 修改后：
  

• 学号准确查询：
  

• 姓名模糊查询：
  

• 时间准确查询：
  

• 感染情况查询：
  

• 感染情况统计图：
  

bug4：这里只实现了全校在某一天的感染情况数据统计，而作业要求的校级防控办负责人查看各个学院某一天的感染和未感染人数这个功能并未实现，比如在这里如果输入计工院，2020-04-01，感染人数应该为0个，而统计图显示感染人数有一个，显然是不正确的。

• 查询某人某天情况：
  

• 填报情况统计图：这里以计工院，2020-04-01日为例，设置总人数为10人
  

bug5:导出excel，虽然有相应的弹出框，但并未看见有数据导出到excel，即使修改路径也并未看到有数据导出此处还有待与原作者进一步探讨

• 查看文件源代码位置，发现案例文件路径有误
  

• 修改案例excel文件路径，还是未看到有数据导出
  

• 学生统计信息汇总：
  

• 教职工统计信息汇总：
  

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

• 总结本组实验三博客作业：我们小组总的来说在博文结构上没有太大问题，主要就是界面不够美观，界面背景颜色搭配不太好看，相比于案例博文，实现的功能也没有很全面。

• 代码运行存在的bug：测试代码过程中发现我们的项目在导出excel的时候还是有点小问题，有时候也存在excel不能导出的情况，暂时未找到原因，截图如下：

错误情况：找不到文件

正确情况：可以找到文件

• 未实现的功能：并未完全实现闹钟提醒功能

二、任务2

与实验三结对伙伴协作学习：阅读《现代软件工程—构建之法》第5-6章内容，理解并掌握软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则；
博客作业中针对任务2的评分要点：提供两人讨论任务2学习内容的微信或QQ截图，要求截图美观。

1、软件项目团队的特点

• (1) 团队有一致的集体目标，团队要一起完成这目标。一个团队的成员不一定要同时工作，例如接力赛跑。
• (2) 团队成员有各自的分工，互相依赖合作，共同完成任务。
• (3) 团队具有融洽的交流环境
• (4) 团队具有共同的工作规范和框架
• (5) 团队采用合理的开发过程

2、软件团队的模式

软件团队有各种形式，适用于不同的人员和需求。基于直觉形成的团队模式未必是最合适的。例如小朋友们刚开始踢足球的时候，大家都一窝蜂地去抢球，球在哪里，一堆人就跟到哪里,这样的模式可以叫一窝蜂模式 ( Chaos Team)。随着团队的成熟和环境的变化，团队模式逐渐演变成了一下几种:

• (1) 主治医师模式 ( Chief Programmer Team, Surgical Team )

  • 就像在手术台上那样,有一个主刀医师,其他人(麻醉,护士,器械)各司其职,为主刀医师服务。这样的软件团队中，有首席程序员( Chief Programmer),他1她负责处理主要模块的设计和编码，其他成员从各种角度支持他1她的工作(后备程序员、系统管理员、工具开发、编程语言专家、业务专家)。

• (2) 明星模式( Super -star Model )

  • 主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他人的总和，2004年到2012年的“翔之队”就是一个例子。明星也是人，也会受伤，犯错误，如何让团队的利益最大化，而不是明星的利益最大化?如何让团队的价值在明星陨落之后仍然能够保持?是这个模式要解决的问题。

• (3) 社区模式( Community Model )

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

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

  • 这样的团队在每个项目(剧目)中,不同的人会挑选不同的角色。在下一个剧目中，这些人也许会换个完全不同的角色类型。各人在团队中听从中央指挥(导演)的指导和安排。在学生实践项目或培训项目中，这样的事情经常发生。

• (5) 秘密团队 ( Skunk Work Team )

  • 一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。一个团队的成员如果有很大的自由度，又有独特的使命，这对于大家来说，是很大的驱动力。这样的团队往往能发挥超高的效率完成看似不可能的任务。

• (6) 特工团队( SWAT )

  • 就像电影电视中的特工组“加里森敢死队”等一样，软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。例如2000年之前，很多公司都需要专业人士去解决Y2K问题s。这些团队成员必须了解传统语言和老式系统，才能胜任这样的任务。现在还有一些专门做网站安全性服务的团队，也属于这一类型。

• (7) 交响乐团模式 ( Orchestra )

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

• (8) 爵士乐模式( Jazz Band )

  • 不靠谱。他们演奏时都没有谱子。
  • 没有现场指挥，平时有编曲者协调和指导乐队，
  • 也有模式
  • 人数较少。

• (9) 功能团队模式 ( Feature Team )

  • 很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成沟通&协作一个功能。在这个功能完成之后，这些人又重新组织，和别的角色一起去完成下- -个功能。他们之间没有管理和被管理的关系。大型软件公司里的不少团队都是采用这种模式。这些功能小组也称为Feature Crew.

• (10) 官僚模式( Bureaucratic Model)

  • 还有一个团队模式可以叫作官僚模式。这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导,同时还混进了组织上的领导和被领导关系。

3、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点

• 瀑布模型由温斯顿.罗伊斯首先提出，其优点是容易管理，缺点是开发过程逆转代价大、脱离实际、现代客户难以明确需求，该模型对需求大依赖、效果后期才可现、反馈少、测试集中在后期、需求不明确时难以进行。适用范围为：需求明确的项目、低风险项目、面向过程。
• 瀑布模型的各种变形有：生鱼片模型、大瀑布带着小瀑布模型,如下所示：

• 渐进交付流程：由史蒂夫.迈克康尔在1996年提出，主要形式如下：

• 敏捷流程：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。其特点是：
  • 快速迭代
  • 让测试人员和开发者参与需求讨论。
  • 可以工作的软件胜过面面俱到的文档
  • 客户合作胜过合同谈判
  • 响应变化胜过遵循计划

4、理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则

Team Software Process (TSP )的原则主要有以下7个:

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

截图：

三、任务3：

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

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

1、团队项目作业发布账号链接: 点这里

2、团队项目仓库github链接:点这里(可以在各个分支下面查看)

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

• 我们小组选择的是2019春季计算机学院软件工程 (北京航空航天大学)水哥小组，选择原因是它主要开发的是小程序，而小程序最大的优势就是用微信扫描就可以查看和使用，比一般的系统好用。
• 这一款小程序对我们大学生很有用，很多大学生都想参加比赛，但是找不到合适的队友，想找实习工作，但是也是无处下手，浪费了很多宝贵的时间，而此款小程序，提供分类浏览和关键搜索功能，支持上传图片，随时可以修该简历，可以说使用十分方便，尤其是对大学生来说很有价值。
• 最后一点原因就是，我们想体验一下我们和其他学校学生之间的差距有多大。

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

• Beta阶段分工如下：
  

• Gamma阶段分工和贡献如下：
  

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

通过阅读项目系列博客文档，发现利用用户反馈进行改正是提升品质的最快最好方法；在长时间固定每位成员的职责后，能一定程度促进成员自觉，甚至提前完成任务；

将设计与实现工作分离是提升效率及工作完成质量的重要步骤；功能越多、越方便接入用户的平台，往往审查条件越严格，留出足够的缓冲时间以防万一非常重要。

• 针对TSP原则的第二点：“团队的各个成员对团队的目标、角色、产品都有统一的理解”，该团队做的很好，而且召开多次会议，明确产品需求，由这篇博客可以看出来；

• 针对TSP原则的第四点：“尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定”，该团队进行了很多数据测试，比如软件的抗压能力，各种手机运行的不同状况，由这篇博客可以看出来；

• 针对TSP原则的第六点：“增强团队的自我管理能力”，该团队也做的很好，他们明确分工，各司其职，这极大的提高了团队效率。

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

主要结构如下：具体代码部分，在相应的分支front_end,back_end里面，从下面截图可以看出，对数据库部分有相关的规范，具体代码部分似乎没有相应的代码规范。

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

具体环境部署如下：

• 安装python3和pip3：
  apt update
  apt install python3
  apt install python3-pip
  

• 安装Django：用pip3 install django命令安装

• 下载代码
  

使用体验：由于是小程序，使用起来很方便，微信扫码就可以登陆并使用，界面也良好，在小程序底下有菜单栏，方便导航，而且有搜索功能，但是也有很多的问题，比如有时候会连接不到服务器，导致小程序的部分功能无法使用，

• 主页
  

• 竞赛组队：
  

BUG列举：

bug1：在个人中心没有消息提醒功能，假如用户收到邀请，可能无法及时查看

bug2：该小程序的使用还不是方便，如果服务器没有打开，在手机上就不能正常使用，例如要修改个人资料，点击确定修改，没有反应

• 修改前：
  

• 修改后：点击确定按钮，没有反应
  

8、评价该团队项目是否值得继续开发，并陈述理由？

该团队项目值得继续开发，原因有：

• (1)首先，该团队项目立意很好，贴合大学生的实际需要，如果开发好，将造福一批大学生。

• (2)其次，采用的技术也是很先进的python编程，python语言近几年比较火爆。

• (3)相比于传统的APP，小程序更讨喜一些，它不用占用很大的内存空间，而且使用方便。

• (4)此外，大学生是一个庞大的群体，如果投入使用，一定会有一个很好的下载量。

• (5)该项目可以进一步延申为网站等等。

四、任务4

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

任务	预计花费时间(h)	实际花费时间(h)
总计	35.2	42.2
任务1	16	18
任务2	4	4
任务3	15	20
任务4	0.2	0.2

2、请谈谈完成本次作业的感受和体会。

做完本次作业，体会良多，首先，在运行别人的代码的时候，很容易出现问题，起初，以为是别人的问题，后面和合作伙伴讨论发现，是自己的问题，比如别人数据库用的是Sql server，而我们用的是Mysql，于是自己新建了数据库，运行时候要修改有关数据库连接的部分，才能正常运行程序，之后，如何任务三也是困难重重，首先是环境的搭建，要下载虚拟机，下载linux系统，下载python运行环境等等，虽然过程艰辛，但是也学到了很多。感觉各个大学高手如云啊，大家都很优秀，我们还是得继续努力。