| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE/ |
| 作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
| 我的课程学习目标 | 再次进行结对，学习团队软件项目流程，团队成员协作，掌握敏捷流程原则及相关概念。 |
| 这个作业在哪些方面帮助我实现课程目标 | (1）学习软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型；（2）体验结对学习交流的好处；(3）了解团队协作的好处。 |
| 结对方姓名-学号 | 张燕 - 201771010142 |
| 结对方本次博客作业链接 | https://www.cnblogs.com/zyan---/p/12658240.html |
1、实验目的与要求
（1）学习团队软件项目流程（TSP）、团队成员协作要求。
（2）掌握敏捷流程原则及相关概念。
2、实验内容和步骤
任务一：
1.案例作业博客链接;
2.案例作业项目仓库链接；
3.符合（1）要求的博客评论；
4.符合（2）要求的系统运行截图、软件功能总结；
注册界面：
登录成功界面：
疫情填报界面：
高级查询：
可视化数据分析图：
信息增删：
导出
整体来说，功能界面是比较完整的，有登录注册界面，疫情上报界面，各个阶级负责人管理界面等，大致功能有高级查询功能、可视化统计功能，信息的增删改查功能、数据出为ECXCEL文件功能和邮件提醒等功能，可以提醒人们按时打卡，界面也设计的比较美观，完成度很高，很值得我们去学习。
5.符合（3）要求的总结，代码运行存在的问题截图为证。
1、起初在导入代码时候，由于和作者环境不一致，配置了很久的环境，花费了很长时间。
2、在配置好环境后又出现以下等错误:
3、在阅读代码过程中，发现有些地方还是没有严格按照其所述编码规范走，如：
括号的格式:
4、在代码中有很多不必要的代码，可以适量删除，方便阅读：
任务二:与实验三结对伙伴协作学习：阅读《现代软件工程—构建之法》第5-6章内容，理解并掌握软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则；
软件项目团队的特点
（1）团队有一致的集体目标，团队成员要一起完成目标，一个团队的成员不一定要一起工作。
（2）团队成员有各自的分工，互相依赖合作，共同完成任务。
软件团队的模式：
1.主治医生模式（一人主刀，其他人各司其职，服务主刀）；
2.明星模式（主治医师模式运用到极点）；
3.社区模式（由志愿者参与，每个人参与自己感兴趣的项目，众人拾柴火焰高）；
4.业余剧团模式（各人在中央指挥的指导和安排下执行各种不同的任务）；
5.秘密团队（在秘密状态下进行项目，有极大的自由度，不受外界干扰）；
6.特工团队（有一些有特殊技能的专业人士组成解决棘手紧迫的问题）；
7.交响乐团模式（成熟，专业，专注与某一方面的团队）；
8.爵士乐模式（随意，互动强力，创意的团队）；
9.功能团队模式（具备不同能力的人员平等协作完成一个功能，完成之后又重新组织，和别的角色完成下一个功能）；
10.官僚模式（层层领导）；
瀑布模型：
1.定义：瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
2.核心思想：按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
3.优点：1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。
4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
4.缺点：1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
TSP原则：
- 使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的。
- 团队的各个成员对团队的目标、角色、产品都有统一的理解。
- 尽量使用成熟的技术和做法。
- 尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
- 制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。
- 增加团队的自我管理能力。
- 专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。
任务三：
我们选的是2019春季计算机学院软件工程 (北京航空航天大学);
1.团队项目作业发布账号链接
2.团队项目仓库链接；
3.陈述你选择该团队项目进行分析的理由;
首先看到了他们的项目选题——博客园手机APP续写，就很感兴趣，因为平时都直接在网页上用博客园来写随笔和作业，所以想深入了解一下，看开发成手机APP会是怎么的效果，是不是登陆使用都方便了些，是否和网页上的功能一致，带着这些猜想，所以选择了该团队项目来分析。
4.结合项目系列博客文档，总结项目团队成员的分工合作情况;
首先从这篇阶段项目展示可以得知这个叫PureMan6的团队总共有7个人,有点意思，七个人分工各不相同，有两个PM和PM测试人员，有四个开发员，有一个软件测试人员，而四个开发人员在项目不同阶段分工也大不相同，具体看Scrum Meeting，大致如下图所示
5.结合项目系列博客文档，评价项目的软件项目过程特点;
1、关于此项目的过程，该团队约摸写了50几篇开发过程博客文档，我在阅读过程中，了解到PureMan6团队主要采用了功能团队模式模式和业余剧团模式相结合的特殊模式，如此特殊模式的特点就是这样的团队在一个项目中，不同的人会挑选不同的角色，各人在团队中都听从一个中央指挥的指导和安排，在“中央指挥”的组织下，每个人都可以尝试不同的角色，各司其职，各自有专门场地，项目期间都比较靠谱，团队内部交流也比较频繁，经常进行例会交流，互相可以了解进度和未解决的问题，简而言之，就是具备不同能力的同事们平等协作，共同去完成这个项目。
2、关于项目流程，都是RUP统一流程，从瀑布模型开始的各种模型都有一个公共点：重计划，重实现设计，重文档表达。RUP把软件开发的各个阶段整合在一个同统一的框架里面，要完成一个复杂的软件项目，团队的各种成员要在不同阶段做不同的事情，遵循分析——设计——实现（制造）——销售——维护这个流程，首先该团队通过开例会讨论确定项目名称，以及团员大致分工，再做具体需求分析，然后每个人依照各自分工来对相应的模块进行设计开发，再此过程中，不断通过线上线下交流来保证代码规范，互相可以联系，后进行综合，发布项目并进行测试，收集数据。
6.观察该团队项目github仓库的源代码文件结构，是否包含代码规范文档？
该团队在博客文章内有具体写代码规范说明。在GitHub上未显示有代码规范文档
7.下载团队项目代码，尝试部署项目运行环境并使用软件，描述最简单直观的使用体验，找出至少两个比较严重的功能性bug，在博客中展示截图;
APP初始页面：
APP登录界面：
我的博客界面：
我的班级－作业界面：
我的班级－博文界面：
我的班级－新增投票界面：
我的班级－新增设置界面：接受信息权限和黑暗模式
关于“我”界面：
整个APP从打开就给人很舒服的感觉，所有的都是白色背景，黑色字体，看上去非常简洁，大方，界面模块总共分为三个大块，位于底部，使用起来非常方便，在三个大模块中又分为小的模块，和PC版的博客园相差无几，值得一说的是他们设计了黑暗模式，让人可以在黑夜中更好的接受屏幕，不会太刺眼，非常贴心的设计，很喜欢他们的设计和界面。
.依旧存在的问题：
1、首先很多模式在黑暗状态下不能使用
2、提示列表无法显示
3、文档设置的格式没有同步渲染
8.评价该团队项目是否值得继续开发，并陈述理由？;
我认为很值得继续开发，现在这个软件已经可以被下载使用,大多数功能都是可以使用的，现在这些功能对我们来说，也非常受用了。携带手机就可以查看作业，公告，博文等，非常的便捷，不同于网页登陆的局限性，而且界面也非常之简洁美观，再后续加上书写博客的功能，以及将以上出现的BUG修复完善后，这个就与网页版的博客园无异了，而且有很多优越之处，所以说这个项目应该继续开发，等所有完善后，就可以直接下载博客园APP了。非常的看好这个项目。
3、PSP
| PSP | 内容 | 计划时间 | 实际完成时间 |
|---|---|---|---|
| Planning | 计划 | 15 | 15 |
| Estimate | 估计这个任务需要多少时间，并规划大致工作步骤 | 15 | 10 |
| Analysis | 分析对方代码 | 30 | 60 |
| Design Spec | 生成设计文档 | 10 | 15 |
| Coding Standard | 验证测试 | 40 | 35 |
| Design | 具体设计 | 60 | 80 |
| Code Review | 审查代码bug | 30 | 40 |
| Test | 测试（自我测试，修改代码，提交修改） | 25 | 40 |
| Reporting | 博客书写 | 10 | 15 |
| Postmortem & Process Improvement Plan | 事后总结工作 | 20 | 25 |
4、总结
这次又和我的结对伙伴进行了结对交流共同学习，首先我觉得这是个非常好的学习方式，有些注意不到的知识点，也许再讨论过程中可以得到充分理解。其次，在学习别人项目过程中，也可以获取很多知识，比如人家的博文界面书写的好看，你就可以模仿人家的界面进行排版，然后慢慢深化，就有了自己整齐美观的排版规律，再比如人家的项目做的比你出色，你就可以通过github来下载人家代码，进而进行分析学习，没准编程能力就会有很大提升，我们在看了北京航空大学的同学们开发的博客手机APP，感触很深，一是因为人家的项目无论界面功能，都远远超过我们，是我们不容易做到的程度，二是因为人家们认真的学习精神，详细的博客文章就可以说明人家们的努力，每个人都是非常认真负责的在未团队项目贡献力量，这是我们应该学习之处，往后，我们也要跟更加努力，才能更上一层楼。
posted on
