| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
| 这个作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/12521474.html |
| 我的课程学习目标 | 学习他人的项目，弥补自己的不足 |
| 这个作业在哪些方面帮助我实现学习目标 | 在比较中发现不足 |
| 结对方学号-姓名 | 201771030104-道彤阳 |
| 结对方本次博客作业链接 | https://www.cnblogs.com/D-TY/p/12666524.html |
任务一
- 案例博客作业链接 https://www.cnblogs.com/hackerZT-7/p/12544280.html
- 案例博客作业仓库链接 https://github.com/YHwzt/Query-system-web
1.对案例博文作业进行阅读并进行评论
2.克隆案例项目源码到本地机器，阅读项目代码规范文档并运行代码，总结代码运行中存在的问题。
（1）克隆到本地
（2）阅读项目代码规范文档并运行代码
-
代码规范
-
注册
-
登陆
-
添加
-
统计图
3.软件功能总结
（1）实现用户注册。
（2）用户注册时分级。
（3）可实现不同角色分别登陆。
（4）学生/教职工可填报疫情信息。
（5）二级部门管理人员可以实现查看疫情信息。
（6）疫情信息支持多属性可视化查看。
（7）可实现人员添加功能。
（8）可导出疫情信息。
（9）可实现填报提醒。
4.该组的系统基本上涵盖到各个方面，实现了老师所要求的功能，是个比较完善的系统，我们组基本上没有可以提到的附加要求。我们组在刚开始将文件导入时，因为环境没配好，出了一些问题，其他的部分基本上都没出问题。
任务二
软件项目团队的特点
- 团队有一致的集体目标，团队要一起完成这目标。
- 团队成员有各自的分工，互相依赖合作，共同完成任务。
软件团队的模式
- 主治医生模式
- 明星模式
- 社区模式
- 业余剧团模式
- 秘密团队
- 特工团队
- 交响乐团模式
- 爵士乐模式
- 功能团队模式
- 官僚模式
瀑布模型及其变形
-
瀑布模型：是一个软件开发架构，于1970年被温斯顿·罗伊斯（Winston Royce）提出。其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。
-
变形模型有：
生鱼片模型
大瀑布带着小瀑布
渐进交付流程
渐进交付流程主要采取的方法是MVP（着重强调更早获得用户反馈）和MBP（最强最美产品，将用户的需求了然于心）。
敏捷流程
- 敏捷团队的要求：自我管理，自我组织，多功能型
- 敏捷流程遵循以下开发原则：
（1）. 尽早并持续地交付有价值的软件以满足顾客需求；
（2）. 敏捷流程欢迎需求的变化， 并利用这种变化来提高用户的竞争优势；
（3）. 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短；
（4）. 业务人员和开发人员在项目开发过程中应该每天共同工作；
（5）. 以有进取心的人为项目核心，充分支持信任他们；
（6）. 无论团队内外，面对面的交流始终是最有效的沟通方式；
（7）. 可用的软件是衡量项目进展的主要指标；
（8）. 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去；
（9）. 只有不断关注技术和设计，才能越来越敏捷；
（10）. 保持简明————尽可能简化工作量的技艺————极为重要；
（11）. 只有能自我管理的团队才能创造优秀的架构、需求和设计；
（12）. 时时总结如何提高团队效率，并付诸行动。
- 敏捷流程的方法论 ：
（1）. 找出完成产品需要做的事情——Product Backlog；
（2）. 决定当前的冲刺（Sprint）需要解决的事情——Sprint Backlog；
（3）. 冲刺。期间团队通过每日例会（Scrum Meeting）进行面对面交流，所有人向同伴报告进度。Scrum Master根据项目情况，用简明的图表展现整个项目的进度（燃尽图Burn Down Chart、看板图Kanban）；
（4）. 得到软件的一个增量版本，发布给用户。然后在此基础上又进一步计划增量的新功能和改进；
TSP原则
- 使用妥善定义的流程，流程中的每一步都可以重复，可以衡量结结果的；
- 团队的各个成员对团队的目标，角色，产品都有统一的理解；
- 尽量使用成熟的技术和做法；
- 尽量多的收集数据（也包括对团队不利的数据），并用数据来帮助团队做出理性的决定；
- 指定切合实际的计划和承诺，团队计划要负责集体执行的角色来制定（而不是从上级来的）；
- 增加团队的自我管理能力；
- 专注于提高质量，争取在软件生命周期的早期发现问题，最有效提高质量的办法是做全面而细致的设计工作；
团队交流截图
任务三
任务三我们选择了北京航空航天大学PureMan团队的项目，他们组的团队项目是设计完成一个手机端的软件，可以登录博客园，查看班级信息，发表评论等。
1.团队项目作业发布账号链接 https://www.cnblogs.com/PureMan6/p/10739662.html#4
2.团队项目仓库github链接 https://github.com/swearitagain/EduCnblogs2.0
3.陈述你选择该团队项目进行分析的理由
（1）该团队的项目贴合于实际生活，有效的解决了手机端处理业务的问题。
（2）可以学习人家的设计过程，了解差距，弥补不足。
4.结合项目系列博客文档，总结项目团队成员的分工合作情况
| 开发人员 | 学习任务 | 承担开发任务 |
|---|---|---|
| 胡俊崧 | 学习react native的组件 | 修改班级一级界面的UI结构和交互逻辑 |
| 蒋锋 | 学习react native的组件 | 熟悉博客园公告相关API，实现发布公告的功能 |
| 吴昊 | 学习react native的组件 | 组织策划会议，催促项目进度 |
| 陈治齐 | 学习react native的组件 | 完成了班级选择页面 |
| 吴枫 | 学习react native的组件 | 测试发布作业，发布公告功能 |
| 邵旭哲 | 组织策划会议，催促项目进度 | 撰写每日例会报告 |
5.结合项目系列博客文档，评价项目的软件项目过程特点（TSP）
（1）按照博客来看，他们的博客很好的反映了开发过程，内容详实，设计合理。
（2）他们很好的划分了项目的阶段，设计，学习，编码，整个过程合理得当。
6.观察该团队项目github仓库的源代码文件结构，是否包含代码规范文档？
这是他们在github上提交的代码，有源文档结构，包含代码规范文档。
7.下载团队项目代码，尝试部署项目运行环境并使用软件，描述最简单直观的使用体验，找出至少两个比较严重的功能性bug，在博客中展示截图
- 下载并尝试
8.评价该团队项目是否值得继续开发，并陈述理由？
该项目值得继续开发，UI方面可以继续优化，争取将可视化部分做的更好。
总结
1.本次任务不同于以往的任务，这次主要是让我们学习优秀的项目，通过学习别人的项目可以有效地提高自己能力，了解自己的不足。
2.要吸取别人优秀的经验，及时完善自己。
3.要和同伴做好任务分工，这样整体的效率会有很大的提升。