项目大约开始于年月日,由于之前的补货预测不能满足目前的业务需求,存在预测数据不准确的问题,因此采购表需要IT协助完善相关脚本。
通过前期的需求调研,了解了需要调整的格式、公式、逻辑等,经过一个多月的深入研究,比较细致的讨论了脚本的关键技术,在弄清楚需求和修改的方法之后,就是具体的实施了。
对于这个项目我的心得是这样的:
1、需求调研
需求是否必要?必要的话,现有的条件是否可以满足?新开发的话,效率和成本如何?
必须了解最终客户的真正需求,有时客户会直接提出解决方案,但还是需要了解其真正目的,目的不同,方案自然不同。
2、需求文档
对前一步的需求分析写成文档,明确指出了客户需求,并让客户进行签字确认(每一个细节最好都有确认,如计算逻辑、函数的使用等),同时,对于其他相关人员而言,也便于理解需求,方便程序员维护脚本。
文档可以包含以下几项:项目概述,目标,应用范围,名词定义,详细需求,用户用例,显示结果等。
3、蓝图设计
画出逻辑关系图,列出关键步骤、制定执行计划。这一步也非常的关键,如果考虑不够周全,后期就需要翻工!
如果是多个人合作完成项目,要将工作分工落实到每个人头,以及安排出相应的时间表,时间安排要合理,同时要有弹性,可能会有临时紧急重要需求,可能突然有重大变更,当然这时计划也需要再安排。
4、项目实施
a.对相关原始脚本进行逐行分析,了解每句的含义(如果是新项目,就需要自己写代码)
b.进行相应的修改
c.在数据库中搭建运行环境(调度相应的表到备库,把表结构设计写下来)
d.创建外部数据表(如工作日表)
e.考虑后期影响因素,维护工作,可扩展性(时间范围按系统时间自动截取,年初可能会有问题)
5、检验结果
自己检查结果,是从技术角度检查;客户检查结果,从业务角度检查,因为在需求上可能仍存在误解。
6、部署实施
在真库上创建存储过程、视图、物化视图等。如果是多地系统,需要再从第三步开始。
但是之前的旧版还需要保留一段时间,在这期间两个版本同时运行,当新版没有问题了,再停用旧版。
7、调整维护
在运行过一段时间后,用户可能感觉某些方面没有达到期望,需要修改,这时的需求应该是比较明确的,修改相对容易。将后期需要做的维护工作,注意事项等写入相关文档。
在写脚本的时候,良好的编写习惯也很重要,既可提高编写效率,保证脚本的正确性,同时易于扩展和后期维护。在操作的过程中,要时刻注意按照需求说明进行,不要一味的盯着具体的语句或者以前的逻辑,而偏离了目标。总的来说,项目的实施和具体代码的编写都要有一定的规范和流程。要有全局的观念,不要只专注于几个细节,考虑周全,项目完成后还应该注意哪些方面,后续工作还有哪些。
对于一个项目,计划是很重要的,如果在调研了需求之后,认为项目是必须要执行的,那么就要制定计划了,从需求调研开始,就要拍计划。当然这些也不是线性的,应该是螺旋上升的,后期可能还会做一些修改,但是大的框架应该保持不变了。