201771030129-张琳 实验二 个人项目— 《西北师范大学学生疫情上报系统》项目报告
| 项目 | 内容 |
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
| 这个作业要求的链接 | https://www.cnblogs.com/nwnudaizh/p/12416880.html |
| 我的课程学习目标 | 掌握个人软件项目开发流程 |
| 这个作业在哪些方面帮助我实现了学习目标 | 整个过程让我熟悉了并且学习了个人软件项目的开发流程 |
| 项目Github的仓库链接地址 | 无 |
任务一：陈述学生疫情每日上报子系统使用体验
1.我使用的是企业微信里的疫情上报系统，刚开始使用的时候服务器崩溃了，应该是因为使用的人太多了。后面再用的时候感觉很好，错开使用的高峰期；
2.它的优点在于在填写了几天之后，因为那些基本信息都不变，所以它就自动生成了，不用再去选择和填写，如果个别情况有变的话只需要重新填写改变的一栏；
3.还有一点是这个系统在提交的时候需要两次确认，可以更好的保证提交的内容没有错误，提高了系统信息的准确性。
任务二：总结详细阅读《构建之法》第1-2章、结合第2章2.3节所述PSP流程，开发一款自己心目中的西北师范大学学生疫情每日填报系统
我选择第一类开发要求：
有一个数据文件，保存了100天 2000 个教职工/学生的所有防疫信息，请设计一个命令行程序， 支持查询某人在某一天的疫情情况， 查询某种数据的周/月的疫情统计情况，并用柱状图显示统计结果。
需求分析：
1.由于疫情影响了各个角落，作为大学生这个群体，我们需要回学校上课，但是在回学校之前需要保证没有感染新冠肺炎，也没有处于隔离期间也包括没有与感染人员接触等，我们的学校需要了解学生的这些信息，教师也需要返校，所以需要开发出一款了解教师和学生疫情情况的系统；
2.学校需要了解每个学生或者教师的疫情情况，系统可以查询某个人一天的疫情情况；
3.可以查询某种数据的周/月的疫情统计情况;
4.了解某个集体的疫情情况，可以查询一个班级/院系近一周或者一段时间里的疫情情况，可以显示整个系统使用者的疫情情况；
5.需要填报的人数比较多，难以管理，所以应该可以查询填报者和未填报者，并对未填报者及时作出提醒。
6.对于查询结果，应该简单直观的反映出疫情情况，
功能设计：
基本功能：1.一个数据文件，保存了100天 2000 个教职工/学生的所有防疫信息；
2.设计命令行程序；
3.可以查询某个人一天之内的疫情情况；
4.可以查询某种数据的周/月的疫情统计情况；
5.查询结果用柱状图显示。
扩展功能：1.可以查询某个集体的疫情情况，比如查询一个班级/院系近一周或者一段时间里的疫情情况；
2.可以显示整个系统使用者的疫情情况；
3.显示填报者和未填报者的基本信息；
4.对于未填报者作出短信或者微信等方式的提醒。
5.可以增添学生教师等疫情情况以及基本信息。
设计实现：
创建两张表，一张是教师表，另一张是学生表。定义学生类和教师类。
1.教师表中包含职工号，教师姓名，联系电话，当前所在省市，是否与武汉籍人员接触，是否处于隔离期间，是否有发热等症状，是否感染新冠病毒，当天是否返校；
2.学生表中包含学号，学生姓名，联系电话，当前所在省市，是否与武汉籍人员接触，是否处于隔离期间，是否有发热等症状，是否感染新冠病毒，当天是否返校。
运行测试：
关键代码：
总结:程序如何实现软件设计的“模块化”原则
在程序设计中，模块化分的原则是模块内高内聚度，模块间低耦合度。在进行程序设计时将一个大的程序按照功能划分成若干个小程序模块，每一个小程序完成一个确定的功能，但是这些模块之间要建立必要的联系，模块之间相互协作完成整个功能的实现。利用函数实现程序的模块化，会提高程序的易读性，采用自顶向下的方式，将问题划分成几个部分，各个部分在进行细化，直到分解为比较好解决的问题为止。
展示psp：
| psp | 任务内容 | 计划完成需要的时间 | 实际完成需要的时间 |
| Planning | 计划 | 30 | 30 |
| Estimate |
估计这个任务需要多少时间 并规划大致工作步骤 |
30 | 20 |
| Development | 开发 | 1500 | |
| Analysis | 需求分析（包括学习新技术） | 400 | 300 |
| Design Spec | 生成设计文档 | 30 | |
| Design Review | 设计复审（和同事审核设计文档） | 30 | |
| Coding Standard | 代码规范（为目前的开发制定合适的规范） | 30 | |
| Design | 具体设计 | 200 | |
| Coding | 具体编码 | 500 | |
| Code Review | 代码复审 | 120 | |
| Test | 测试（自我测试，修改代码，提交修改） | 60 | |
| Reporting | 报告 | 30 | |
| Test Report | 测试报告 | 60 | |
| Size Measurement | 计算工作量 | 60 | |
|
Postmortem&Process Improvement Plan |
事后总结，并提出过程改进计划 | 100 | 20 |
感觉自己对于系统的需求分析方面做得不是很到位，想的不够多，不够全面，在做计划的时候可以很快的完成，但是如果进行代码部分的话感觉自己完成的时间会比估计的时间要长，其中学习新技术方面也会花费的时间比自己预估的时间长。在后面的总结阶段可以节省一些时间，尤其这次没有完成代码部分，所以总结的东西比较少，在事后总结方面花费的时间就更少了一些。
经验分享：
经验就是要勤快，多多练习编代码，提高自己的编码能力，在需求分析方面其实应该分角度思考，比如站在开发者的角度，用户的角度，以及当前背景下等。不要有拖延症，尽早快的完成作业。本次实验主要学习了个人软件项目的开发流程，对个人软件项目开发流程有了一定的了解，对于PSP的重要性有了一些体会，没有PSP的话去做一些东西没有约束，有些盲目。
