项目总结之pos销售系统前台

来源:互联网 发布:如何访问网络打印机 编辑:程序博客网 时间:2024/05/16 06:12

项目总结之pos销售系统前台

       pos销售系统到这时已经就快告一段落了。看到这个“快”字,就知道现在还没有完成呢。确实是这样的,后续工作依然在进行,后台部分依然在加工美化。

不过这不耽误我总结,因为在这次合作开发的项目中我负责的部分已经完成了。我负责的就是前台的数据采集,其实就是前台销售人员使用的部分。

先来回忆一下整个项目的流程:

【背景】

记得项目刚要开始做的时候我们当时应该进入复习状态了,因为当时刚好是作品展示晚会结束。

当时据说这个项目要的也比较紧。于是乎,我们就分了两组来开发,主要是我们人多,为了让更多的人受到锻炼,因此分为两组,这样每个人的工作量就可以大些(其实这是好事儿哦)

【开始】

首先由坤哥为我们讲解需求,然后又把数据库设计好了给我们。不过这个设计在后面也是被我们一改再改。

       需求理解完毕之后,数据库设计也有了,于是我们开始分工合作。我们组一共分了四个人(本来是五个,有一个走了)。我分配的任务是前台销售部分,这一部分是采用C/S方式,因为采用的是触摸屏的pos机,必须要求软件的反应速度要快。

       这一块是这个系统中需要多加注意的部分,因为这一部分直接涉及到用户的体验。对于一个餐饮销售店来说,销售效率始终是个重要的问题。并且对于一个全触屏的操作来说,屏幕上显示的每个按钮都是必须要精雕细琢的。

       等分配完毕我们就开始干活了,斌斌负责先把DAL层搞定,正阳搞定BLL层,胖子呢负责基于B/S的后台管理部分。

       其实这个时候我们组已经有些问题了,那就是需求理解的不透彻。因为仅仅是在qq讨论组中进行的交流,虽然易于保存交流文档。但是缺点是交流的不够充分,这充分说明人的这张嘴还是很有用滴。

       这一直干下来路上也没有遇到什么大的问题,不过最常见的问题就是数据库设计不完善,不是添加一个字段就是减少一个字段。有时候原先删除的内容后来又要添加上去。这说明什么问题呢?数据库设计不够彻底。

       这里就要说到一个重点,不过只是个人感觉:对于整个项目来说可以一边开发一边完善需求。但是数据库的设计不应该这么一直变动吧,这样的话实体类和DAL层不也要改变吗?但是如果数据库设计的很透彻了,也就是意味着已经把需求都涵盖全了。那么需求也就ok了。不存在一边开发一边还要完善需求了。所以这里有疑问。

 

       【完成】

       就在这样的一步一步的改进中慢慢的也算是把前台搞定了。自己还是很高兴的。因为毕竟在设计时可是绞尽脑汁呀。这里不得不说一下了。呵呵

       首先这个机器是触屏的,因此需要考虑每个按钮的大小,不能太小,你不能要求人家销售根筷子来捅按钮吧,因此要考虑手指头的大小。但是按钮也不能太大,按照整个屏幕的大小来说,屏幕上要尽可能的显示更多的信息,尽可能的将重要的信息显示在第一界面上(也就是登录之后显示的页面)。因此要考虑空间分配的问题。怎么才能合理的设计按钮大小,设计点菜列表的大小,如果进行布局,成了必须要考虑的问题。

在米老师的“百般挑剔”下,界面也是一改再改,不过越改越良了。最后也就形成了自己觉得相当满意的一个界面。(当然了,问题依然多多)

       【挑出来设计模式】

       因为这次时间确实紧张,在设计的时候没有考虑参入什么设计模式,不过在做点菜以及取消点菜的时候依然发现了一个设计模式,那就是命令行模式,其实是因为这个功能和《大话设计模式》中的那个点菜的类似,因此联想一下,就来了。

       分析一下,其实就是把已点菜的列表当成是大话代码中的那个list来用。由源码化为控件。道理一样。

       【总结】

       说这个项目有难度吧,我也没有遇到,因为主要的难度应该就是关于驱动的一些操作,这些已经由王鹏和坤哥解决了。剩下的关于系统的软件部分就是没有难度了。

       不过这里有一点要提的就是这是又一次软件工程的实践,也就是我们对于软件工程的理解有深刻了一点。

       需求分析要彻底,合作开发要交流的彻底,并且每一个开发人员在开发时无比保证自己负责的模块能够完全满足了需求即不存在最后需求有但是代码却没有实现的部分。

       一句话,重要的还是做好分析。但是怎么做?又是一个问题。怎么才能清晰地理解整个需求,并且将理解的需求清晰地传递给合作开发者,也是一个问题。

       因此接下来要做的是不断地冲击着关于需求分析和数据库设计的问题,直至最后在拿到一个项目之后可以很清晰的知道从哪开始分析,分析完之后是什么样的,如何将分析的结果清晰地呈现给开发人员。

 

原创粉丝点击