评教阶段总结

评教阶段总结

    评教系统进行了一个月零八天的时间，以一个组长的身份带领着几个人做系统，采用敏捷开发的思路。由于经验尚浅，四月一日给老师看阶段性成果心里还是很没有底的，听老师的意见总会推翻自己以前的很多想法，但在开始之前还是想不到哪里有做的不好。

工作情况

    需求了解阶段

    时间：2014年2月21号-2月28号

    概况：

    前面两天是对评教系统1.0业务的了解。

    2月23号会议讨论，系统接下来的进展，由于对原系统的开发以及业务与数据库的关联的认识并不是很深刻，因此划分模块，每人负责一部分走查原来代码，理清负责部分的业务以及程序实现。

    2月26号会议分模块讲解负责部分的业务、实现过程以及对应数据库的关系。其中发现了个别问题没有弄清，以及每个人需要写出该模块的需求文档，因此在26号到28号主要完成此项任务。另外整理出了需要增加的需求文档，需要每个人思考如何变动数据库进行实现。

   数据库变更以及界面简单优化

    时间： 3月01号-3月05号

    概况：

    3月1号下午会议讨论了数据库的大体设计，没有实质性进展。

    3月2号对内部人员进行分组：李亚光、张世栋、庞凡负责将数据库从基础库中抽离；张江江、赵欢欢、朱火云负责界面的一些简单优化工作。两组分别进行。

    3月4号会议：将评教系统涉及到的表从数据库中抽离，基本已经完成，张世栋对组员进行了讲解数据库的变动情况（删除个别历史表，合并理论、实践涉及表）；

    3月5号，界面方面的改动也进行了一些验收，但也有一些没有实现的。

   系统原有功能实现

    时间：3月6号-3月15号

    概况：对系统原有功能进行实现，截至15号仍有一些功能需要进一步完成

   系统功能扩展及测试  

    时间：3月16号-3月30号

    概况：

    导出Excel功能实现；对系统一部分扩展功能的任务进行划分及实现（班级评估情况统计页面、查询为空提示、考核内容设置页面的优化）。朱火云、李亚光对前一阶段的任务进行实现。

29号、30号对系统进行测试，并解决过程中出现的问题。

    由于自考毕业设计、论文答辩以及计算机等级考试的原因，自己花费功能实现的时间也就不是很多了，两件事情主要集中在下旬，这段时间对项目的把控并不是很牢靠，截至四月三十日，项目进行的效果并不是很显著：由于数据库变更，将系统的原有功能进行实现，扩展的功能只算是刚刚开始。

阶段验收总结

    这次的验收中再次发现了自己的很多问题：

    想法单纯，定位不高

    常常说只空谈思想，不亲自实践是高谈阔论。但脱离了思想，只知埋头苦作，就是丢掉了提高自己的绝佳时机。项目之初，并没有给自己一个很高的定位，以至于后面的规划、计划仅仅建立在一个较低的定位上：实现原有功能，进行部分功能的扩展。

    而更高的定位是怎样的？——思考！勇敢的发现原有系统中不完善之处，进行改正；原则性的问题必须坚持；技术性的问题，必须面对、努力克服。而这次的项目初期丢失了这样思考与定位。

    躲避困难

    原有系统采用复制基础系统数据库数据到本库，再进行数据的应用，这无疑容易造成数据的不一致性。项目之初计划丢弃此功能，直接读取基础系统数据库数据，设计中看到基础系统数据库设计应用了很多第三张关系表，获取我们的信息要查询多张表，建立视图数据量庞大，执行缓慢。

    只能说我们止步在了这里，没有亲自尝试去解决这必须要解决的问题。复制数据导致了我们必须要保证数据的一致性，考虑到对授课关系的这些数据，基础系统目前只实现了添加以及删除的功能。而我们的保证数据一致性也只是仅仅考虑了这两方面，没有亲自去实践尝试解决这个根本性的问题。

    页面焦点

    “全心全意为人民服务”的思想，听着有些大，但做项目却着实需要考虑的，站在用户角度出发不仅仅是说说，这次真的有了切身体会。

     其实第一次见到评教界面的时候，真的会很迷茫，页面功能不明确，标出的信息提示不知道实际意义：

    这个页面中分了两个功能区：移动成绩至历史库、添加本次评分人员；三个功能按钮：移动成绩、添加人、补充人员。应用的人就要猜了：移动成绩会移到哪里去？添加和补充人员有什么区别？我应该先执行那个功能块？在为用户着想上，不得不说我们又犯懒了，没有站在用户角度看问题，而是以程序开发人员熟悉了界面后的功能实现的态度去看待这些。起初看到这个界面，无论是谁，都会产生疑问，我们同样也是，但到了开发中却忽视了这个问题，而没有把它放到首要解决的位置。

    无论程序设计的再好，界面是用户首先看到的，我们不能让用户来进行一次类似开发人员的培训再回去使用系统，那就把界面设计的拥有焦点，让用户一目了然吧，这是首要做的。

   灵活性考虑

   灵活性，开发人员应对变更的法宝。需求变更是每个项目组多多少少都要经历的，怎样应对这些变更，每次都去修改代码，有时甚至重复修改，联动修改，造成的后果可想而知。

   这次的开发，灵活性上考虑的少之又少，我们仅仅实在需求变动的情况下进行的些许改动，而这又与我们前面提到的定位脱不了干系。举个例子，项目中用到了下图所示的设计

   这种诸如“（文字说明）：（下拉框选项）”式的内容，我们完全可以进行抽象，定义函数功能：传入参数设置某特定该组合的“文字说明”更改、下拉框格式等内容。这样我们就可以不用亲自去更改代码而实现了页面的灵活配置。

中结

    这次的“阶段性成果”是对我们设计理念上的一次反省，做项目就应该多思考，多考虑以前设计的不足，前人的东西是值得借鉴的，但也有是需要我们提出改正的。积极主动的思考，提出自己的意见主张，有可能会错，但只有这样做了才能体现出我们的价值、实现项目的意义。