我的成长(二)---产品的需求分析与设计

来源:互联网 发布:微店与淘宝店的区别 编辑:程序博客网 时间:2024/06/06 08:50

我的成长(二)---产品的需求分析与设计

 

         背景

         在本系列博客第一篇中笔者已经介绍了目前正在做一个互联网的项目,客户方面这个项目的负责人是前车网互联的技术总监,现北京易维宝的武井刚(目前的职位不清楚)。所以在项目进行编码实现前,更像武老师指导笔者及笔者的Team学习的一个过程。

 

         开发流程

         之前的开发基本上都是基于传统行业,客户主要集中在政府机构、事业单位、学校。开发流程理论上是基于传统的软件工程中介绍的需求分析-à设计-à编码实现-à测试-à交付。

理论上在整个过程中一直会存在文档的编写和更新。

         但实际过程中并非如此。需求分析阶段,客户可能仅仅只有一个想法,然后根据这个想法笔者这方初步的整理一下需求,时间短,项目组的开发人员也没有一起去梳理就直接开始设计了。设计阶段,也仅仅是草草的进行了数据库设计,然后就直接分模块开始漫长的开发了。漫长的开发完成之后,草草的测试,补写开发文档,就直接交付客户了。

         我想稍微有一点项目开发经验的人就能发现,这种开发方式本身是存在很多问题的。下面笔者一一道来。

 

         一、需求分析

         必须承认的事很多时候笔者事知道需求分析的重要性的,当笔者准备和客户谈需求的时候一般的政府机构、事业单位的相关负责人愿意抽时间交流的不多。从笔者的上一个项目中笔者深有体会,当该单位一把手说完想法之后,留给笔者的就一句话5天之后“给我把首页弄出来,我要去省里汇报工作”。这是时候往往草率的分析一下就直接开发了。

这种分析导致的后果就是开发过程中Team成员间经常会出现争论,没有明确的需求麻烦的可能就是Team leader了。而且由于前期对需求理解的偏差也可能导致项目延期、重做。


         二、设计

         在之前的项目中其实是没有设计的。接口设计、流程设计、实体设计、数据库设计最近才区分得特别的清楚。

         之前开发过程中实体设计完成就等于数据库设计完成了,流程设计、接口设计也是没有的。然后导致的结果就是:没有业务流程的梳理,没有用业务流程中的一系列场景去验证数据库表结构是否合理导致在开发过程中数据库表结构经常变动,很多时候觉得变动多了就开始凑合了。

         最严重的问题是前期没有业务流程的设计,最终导致的是某个模块具体的流程只有该模块的开发人员才清楚。这个时候Team Leader就无法掌控整个项目了,甚至无法准备的向上级汇报工作情况。

 

         三、其他

         系统架构图,

         关于系统架构图是以前的项目中很少没有涉及到的,以前没有根据业务去梳理、去抽象然后得到基础模块、公共模块、低级的服务模块、高级的服务模块。然后找出不同模块间的依赖关系,进行接口的设计,进行开发任务的安排。

         由于没有进行该工作出现了这个几种情况:

任务划分混乱,按照功能将任务划分完成之后就同步开发了,所以经常出现的是需要调基础服务的接口了,但是没有开发,影响了整个系统的开发进程。

接口管理混乱,由于前期一是没有整理接口,二是每个人同时开发都有自己的任务。导致的就是接口的需求方迟迟调不通自己的接口、接口的开发方,今天来一个接口,明天来一个接口自己还有开发任务,最终整个团队乌烟瘴气,情绪低落,开发效率低下。

        

         总结

         目前笔者这个项目正处于设计阶段,最近几天可能就是武老师给笔者提的各种设计标准和流程将设计工作完成9月1号正式进入实现阶段,由于笔者文笔的限制和知识的限制所以文章中难免存在各种瑕疵,但笔者还是希望读者能够从文章中得到对自己有帮助的东西。

         同时附上武老师推荐的两本书《软件方法》《方法论》,笔者愿通读者共同学习,成长。



2 0
原创粉丝点击