| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
| 作业要求 | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
| 学习目标 | (1)学习团队软件项目流程（TSP）、团队成员协作要求; (2)在软件项目测试的过程中，学会两人合作; (3)掌握敏捷流程原则及相关概念。 |
| 作业在哪些方面帮助我实现学习目标 | （1）学会了结对进行代码测试的重要性; （2）掌握了敏捷流程原则及相关概念; （3）明白了团队软件项目的大致流程 |
| 结对方学号-姓名 | 201771030111-刘维 |
| 结对方本次博客作业链接 | https://www.cnblogs.com/Summer-Sy/p/12671681.html |
任务1：实验三优秀案例推荐：王之泰&韩腊梅组
在实验三得分100分以上作业中，任选一份作为案例，对案例项目成果进行评价，具体要求如下：
（1）对案例博文作业进行阅读并进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系，并将以上评论内容发布到案例作业的博客评论区。
（2）克隆案例项目源码到本地机器，阅读项目代码规范文档并运行代码，总结代码运行中存在的问题，体会案例博文是否有助于项目代码理解。
（3）总结本组实验三博客作业及代码设计存在问题与不足，列举代码中存在的bug，未实现的功能等等。
（1）案例博客链接：所选案例为张芹组案例;
（2）案例作业仓库链接：所选案例GitHub仓库链接;
（3）符合（1）要求的博客评论：
（4）符合（2）要求的系统运行截图、软件功能总结：
①登录部分：（此系统可根据不同身份进行选择并登录系统，老师和学生所登录的打卡系统会受到时间的限制）
错过打卡时间提醒信息：（若超过当日早上十点，则不能再进行打卡）
②疫情上报部分：（学生和老师进入的疫情上报子系统）
填报定时提醒:
③二级管理员部分：（若二级部门登录成功，则会根据数据库中的信息判断该管理员的所在学院，此处以物理学院为例）
简单查询功能：
高级查询功能：
关键疫情信息统计功能：
④学校疫情防控办：（能够查询所有疫情信息且高级查询功能并能对查询信息做导出工作）
高级查询功能：
导出Excel功能：
关键信息统计：
学院填报比例：
软件功能总结：
本项目可以对老师/学生的打卡信息进行采集；二级部门可对所属人员信息进行查看，并支持高级查询，同时还有防疫关键信息的柱状图显示功能；学校防控办指定负责人登录系统，浏览所有人员信息，并且利用高级查询可进行数据组合筛选。在数据可视化的设计上，一方面以扇形图的方式展示各学院已填报和未填报学生统计情况，另一方面以柱状图的形式显示关键疫情数据统计情况，同时也可以根据搜索结果导出查询数据到EXCEL文件；本项目还实现了可以实现定时填报提醒，我们将时间设为每天早上9:55提醒，如果超过十点将无法进行信息填报。
bug：
①类名与程序不对应：（这一部分应该是上传在GitHub中的程序没有及时更新造成的）
②二级管理员不能将某地学生的查询信息图表显示：
③学院填报情况统计表刚填写完数据，却显示未填写人数为100%：
④系统的查询功能不能用于查询时间，以时间做查询的时候会出现报错情况：
这一块我们的系统也存在问题，虽然可以实现时间查询，但是当输入的时间无填报信息的时候系统也会出现报错情况，我们可以共同讨论一下，共同学习；
⑤Excel的导出部分导出的位置固定，不能更改，可能会导致文件的覆盖，此外，若有些同学没有D盘，文件该往哪里导可能也会产生问题；
这一部分内容我们已经实现了，可以将Excel表格导入指定目录，我觉得我们可以多交流沟通、互相学习，不断提升自己的能力；
（5）符合（3）要求的总结，代码运行存在的问题截图为证
总的来说，项目还是非常成功，看得出来花费了很多努力，有很多需要我们借鉴学习的地方，像是博文的逻辑以及还有代码规范说明部分都是十分详细的，代码也较为易读，类的命名直观，类与类之间的关系明确，不仅能够实现老师要求的基本功能，还能够实现附加功能，对自己高标准高要求，这是值得我们大家学习的。以此对比自己的项目，发现需要改进的地方还有很多，还是应该离开自己的“舒适圈”，多向优秀的同学学习，不过我也发现了几点小问题和一点不成熟的建议：
①定时提醒功能部分未能实现
②在二级部门管理部分，这里选择的是关于疫情是否确诊的信息，统计图上却是是否填报的信息
③系统的截止时间没有设置，超过上午十点，依然可以打卡：
④填报系统里面如果没有填写姓名等信息，也可以进行上报：
⑤Excel表格的导出结果不够美观，列宽不为适应列宽：
任务2：与实验三结对伙伴协作学习：阅读《现代软件工程—构建之法》第5-6章内容，理解并掌握软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则；
1.软件项目团队的特点:
(1)团队有一致的集体目标， 团队要一起完成这目标。一个团队的成员不一定要同时工作，例如接力赛跑。更重要的就是一个团队当中最重要的就是团结,不能说是谁想离开就离开，这个样子是不行的，因为这会再一定程度上影响一个团队;
(2)团队成员有各自的分工，互相依赖合作,共同完成任务。只有这样一个团队才可以在真正意义上说是一个团队，每个人将自己的任务完成好就是对团队最大的贡献。
2.软件团队的模式：
（1）主治医师模式：
就像在手术台上一样有一个人主刀，其他人各司其职，共同协助主刀医生。
（2）明星模式：
将主治医师模式运用到机制就是明星模式，不同的是这里的明星的光芒大于其他所有人的总和；但是明星也会犯错，这种模式需要讨论的便是如何让团队的价值在明星陨落之后仍然能够保持。
（3）社区模式:
这就是说按照大家的兴趣爱好安排相对应的工作，但这并不是随意，这也是在一个团队当中有人能够审查的;
（4）业余剧团模式:
在一个项目中可以挑选自己喜欢的色，但也许是不同类型的，这是需要领导者能够调配的，所以大家也在尝试不同的角色;
（5）秘密团队:
软件项目在秘密状态下进行，这样的模式最好的就是内部人员有极大的自由，较高的热情，没有外界的干扰，如果一个团队成员有很大的自由度又有独特的使命，这是一个很大的驱动力;
（6）特工团队:
这个团队模式中就需要程序员能够熟练掌握一些传统语言和老式传统，才能胜任这样一个任务;
（7）交响乐团模式:
这样的就是成员多,各种开发人员聚集在一起然后才可以发会出最大的能力;
（8）爵士乐模式:
一个团队成员可以发会自己的想象与能力，研发出自己的铲平,最后首席程序员做一个总结，敲定一个方案，这也给程序员一定程度上给了空间;
（9）功能团队模式:
在这样一个团队中，具备不同能力的程序员平等协作完成一个功能，实现团队利益的最大化;
（10）官僚模式:
这种模式在一个团队中是最容易出现问题的，因为在项目中的成果与问题都会有主机上报的情况，而且每一级的都会为自己的员工谋取自己的利益,所以这样而来就会给大家造成一种只为自己利益照相的情况，从而忽略成绩的评估，导致很多无谓的算机、纠结、甚至会有人贬低自己的团队价值。
3.理解瀑布模型及其变形：
瀑布模型是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此,如果有信息未被覆盖或者发现了问题，那么最好“返回"。上一个阶段并进行适当的修改，项目开发进程从一个阶段流动”到下一个阶段，这也是瀑布模型名称的由来。其核心就是将功能的实现与设计分开，便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。
(1)瀑布模型的变形：
生鱼片模型：
这个模型解决了各个步骤之间分离的特点，但是无法判断上一阶段究竟什么时候结束的问题；
(2)改进的瀑布模型：
(3)瀑布模型的局限性如下：
①各步骤之间是分离的，但是软件生产过程中各个步骤不能这样严格分离出来；
②回溯修改很困难甚至不可能，但是软件生产的过程需要时间回溯；
③最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用。
(4)瀑布模型主要适用于以下情况：
①如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证；
②产品模块之间的接口，输入和输出能很好地用形式化的方法定义和验证；
③使用的技术非常成熟，团队成员都很熟悉这些技术。
④负责各个部分的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流。
瀑布模型的变形主要有生鱼片模型、大瀑布带着小瀑布、子瀑布模型等，但每个模型均有其缺陷。
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，主要负责所有博客撰写；
蒋锋，陈治齐，胡俊崧：开发人员；
吴枫：测试人员；
吴昊：开发（任务没有其他开发人员那么多），负责开会。
在项目前期有6名人员，其中2人担任PM，3人负责开发，2人负责测试（其中有一个人同时负责PM和负责测试）。
在项目开发后期，新入组了两名成员，其中一名替代了原来的测试人员，一名参与到开发任务中。
总结：该团队能够灵活运用项目团队的分工合作技巧，各司其职，PM握整个项目的进度、发布完成调查问卷、完成项目的各种规格说明书、所有博客的撰写、整理例会报告、组织开会，了解后期的项目版本的发布渠道并进行发布而且还会参与到相关知识的学习之中，同时参与开发任务，相互合作;
开会时，每位成员需要如实汇报自己的工作进度，这其实是非常难得的；
这些也使得团队的整体效率以及项目的完成质量整体较高；
5.结合项目系列博客文档，评价项目的软件项目过程特点（TSP）：
该项目的软件项目过程特点：
- 使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的。
- 团队的各个成员对团队的目标、角色、产品都有统一的理解。
- 尽量使用成熟的技术和做法。
- 尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
- 制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。
- 增加团队的自我管理能力。
- 专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。
可以发现，该项目确实是非常优秀的项目，很值得我们去学习。
6.观察该团队项目github仓库的源代码文件结构，是否包含代码规范文档
该项目源代码完全符合代码规范，且包含代码规范文档；
7.下载团队项目代码，尝试部署项目运行环境并使用软件，描述最简单直观的使用体验，找出至少两个比较严重的功能性bug，在博客中展示截图：
（1）代码运行效果：
①登录界面：
②我发表过的博客：
③班级信息部分：
④个人信息部分：
⑤黑暗模式：
⑥存在IOS版，但功能有所欠缺：
（2）用户体验：
- 直观感受就是方便，平时使用博客园，每次需要打开电脑，虽然网页版功能齐全，但毕竟不太方便；
- 基础功能都可以实现，可以查看班级作业、公告等功能，而且可以对个人博客实现查看浏览量、评论等操作；
- 项目的界面也比较友好、很便捷，使用起来也很方便；
- 能有安卓版和iOS版两个版本，用户体验良好。
（3）运行过程中的问题：
①用该项目浏览博客中的表格会出现乱码情况：
②有的时候会出现“网络请求失败”的情况：
③博文的评论中，出现乱码，没有修饰html：
④登录界面存在“未授权”页面跳转：
8.评价该团队项目是否值得继续开发，并陈述理由
我认为该团队项目十分值得继续发展，原因如下：
（1）该项目可以解决我们必须使用电脑处理博客园界面的不方便；
（2）可以扩展博客园的用户，吸引更多的无电脑人士进行办公、学习；
任务4：完成《实验四 软件项目案例分析》博文作业：
| 项目 | 计划时间 | 实际用时 |
|---|---|---|
| 任务一 | 60min | 80min |
| 任务二 | 200min | 180min |
| 任务三 | 200min | 300min |
| 任务四 | 60min | 90min |
总结：请谈谈完成本次作业的感受和体会
本次实验让我充分认识到自己的不足，编程不够仔细，代码不够规范，做到任务三，找到北航的学长学姐写的项目，给我带来了巨大的震撼，比起跟我们差不多大的北航学长，我们之间的差距还是非常巨大的，但是我想，差距也不是一天两天产生的，在我们初入大学的时候，编程能力也是差不多的，所以，今后，我们更应该更加努力，通过不断努力，向更优秀的自己努力。