本次由于是我第一次实习，所以负责的工作都是一些比较简单易懂的工作。我收到的第一个任务就是帮策划做应用分类，这样就可以对完成项目需要的时间进行估算，本次采用生产率计算方法估算工作量，其中生产率系数取自公司度量库的历史数据。在估算模块的规模及难度系数的基础上，通过公式--工作量=规模/生产率，并乘以难度系数得到各模块的估计工作量，汇总各模块的工作量，即得到总工作量。
下图是一个典型的功能分类表，籍由数据库中的相关数据便可计算每一个功能需要的工时。
而本次实践面对的第二个任务，也是主要任务，则是对一个巡检小程序进行测试，通过完整复刻一遍使用者的操作流程，找出程序在使用层面出现的问题，包括但不限于见面功能设置、功能使用效果、后台操作是否便捷等等。
后台主界面
关于后台系统，其操作内容比小程序复杂的多，这是本人第一次操作后台系统，看着琳琅满目的分类栏，其实第一反应是有点晕，要是没有薛前辈给我的使用手册，我肯定不会操作，也不愿意操作。
等到我稍微对后台系统有些眉目的时候，小程序前台那边并没有给我相应的反馈，这是令我比较头疼的情况，然后与薛前辈沟通并仔细观看手册之后，我发现后台数据库并不会实时更新，而是在设置好工作内容后在每日零点才会自动创建新的任务，相应的，前台小程序才会有反馈。
等到我自以为完整的走过了一遍审查流程之后，薛前辈告诉我没做完，因为我有一个重要的选项并没有设置，导致流程不完整——巡检没有“反馈问题”，而是反馈“没有问题”，这样就不能开启“整改”流程，而因为后台数据库只能每日零点刷新的机制，当日工作只能作废，明日重新开始。
后来我与薛前辈和镇同事一同对系统进行了测试，并向镇同事汇报了一些小问题，这些小问题被及时的更正了。但关于后台数据库内容刷新的诟病还在，薛前辈同数据库设计师在项目上总是争论不休，而这次针对数据库的争论又开始了。
在实习之前，我是知道策划师和程序员经常因为项目功能问题吵起来：策划师一开始给出的命令较为笼统，导致程序员在没有指导的情况下只能自由发挥，而当该功能被做出来的时候，甲方提出了新的要求，策划师要跟着修改方案，这时候程序员就不干了，因为一开始他策划师叫他自由发挥，前后言论不一致，而且改内容又要耗一笔巨大的时间成本。
总之，目前数据库的问题在我实习结束之前应该不会修改，而项目截止时间已所剩无几，本次实习在8月6日结束，我测试的小程序应该会在之后就交付客户了。