项目设计初探

傷城~ 2022-05-20 09:21 261阅读 0赞

**写在前面：**刚刚经历了一个项目从无到有的全过程，并且有幸成为项目主导人员（有导师监管），在离开了项目组以后想对项目设计过程中的一点认识整理在这里。虽然说教式的话语让人没有耐性看下去，但只有真正经历过的同学才会深有感触吧。

一个项目要想真正做起来，离不开前期的设计工作。前期主要的历程：背景调研、需求分析与设计、概要分析与设计、系统原型设计、数据库设计与说明、详细设计与说明。后期主要包括用户操作手册的编写。接下来，本文将分为项目前期、项目中期与项目后期3部分进行阐述。

**项目前期**

1、背景调研

如果确定了开发计划，那么项目设计人员的担子就落下来了。如果项目设计人员对项目背景认识深刻，或者就是这个行业的人，那还好说。但若是一点也不熟悉，之前对这个领域没做过任何研究，那就需要下功夫去了解行业背景，大多数使用场景、涉及到的业务逻辑、产品成型后的主要功能，甚至是商业模式都需要进行一定程度的了解。按导师的话说，做了一个项目，就应该是这个领域的专家，做的项目多了，你就是一个对社会各行各业都有深刻认识的人才。但这对一个初出茅庐的学生来说，还是有一定的难度，但也不是无法可解。可以通过网上查阅资料、关注领域公众号、紧跟该领域重大新闻、实地走访等等的方式收集一些资料，这些资料阅读得多了，自然了解就更深入了。

2、需求分析与设计

背景了解得差不多了，接下来就该收集需求了。需求分析是项目推动的第一步，如果这一步走不好，项目就无法继续向前推进。

我觉得需求这东西不仅仅只是老板给你的，说“我要这个功能，我要那个功能”。诚然，这是很明显的“需求”了，但这些需求合不合理，是不是这么一回事，这都有待商榷。一定要把每一个需求拿到具体的应用场景中去分析，否则会出现很多不合逻辑的地方，即使应用到具体的场景中去了，也要反复推敲。这些分析、梳理的过程就是需求的另一个来源。在分析这些需求的过程中，需要充分挖掘“显式需求”背后的“隐式需求”，往往这些“隐式需求”才是系统中承上启下的关键节点。

需求分析和架构设计必须要有自己的分析、自己的判断，用专业知识来解决用户的问题。如果用户怎么说就怎么做，不加思考分析，达不到用专业知识解决用户问题的目标，因为用户描述的需求是零散的，没有逻辑的，是宽泛的，只有经过专业知识分析提炼过的需求才是真正可实现的合理需求。

通过与项目组成员的充分讨论、修改，最后成文《\*\*\*\*\*项目需求说明书》。

3、概要分析与设计

需求梳理完毕后，将这些需求进行归类、整理、模块化。模块化后的东西就是整个系统的框架了。

概要设计一方面要完成的是从需求到功能的转化，并对功能进行细化、分类。概要设计另一方面更关注的是方向性的问题，策略的选择，所以概要设计中要写清楚技术选型是什么，要采用何种易于扩展的架构设计。

通过与项目组成员的充分讨论、修改，最后成文《\*\*\*\*\*项目概要设计说明书》。

4、系统原型设计

概要设计中的系统框架出来了之后，就可以做一个系统原型了。系统原型可以更好地帮助项目组不管是设计人员还是最后的编码实施人员更加深刻地理解与疏通业务逻辑，在这个过程中可能还会发现一些不合理的模块设计或归类，应该做及时的调整。

原型系统的制作有专业的快速原型设计工具Axure，也可以用Visio等画图工具将整个系统页面画出来的，根据需要选用即可。

通过与项目组成员的充分讨论、修改，最后成文《\*\*\*\*\*项目原型设计说明书》。

5、数据库设计与说明

不得不说，数据库设计是项目前期的重大挑战之一，尤其是对首次设计项目数据库的同学来说。数据库设计难就难在要考虑的东西不仅多，而且杂，主要体现在以下2个方面：

①数据库设计对功能的满足

*  数据库应该有哪些表？
 *  每张表中应该有哪些字段？
 *  每个字段应该采用何种类型最恰当？
 *  每张表的字段存在冗余吗？在什么时候又需要必要的冗余来支持功能呢？
 *  表与表之间的联系是什么？
 *  这些表能满足所有的功能吗？
 *  ……

②数据库设计对性能的影响

*  表中字段什么类型最不影响性能？
 *  字符型字段要不要固定长度？
 *  数据库字段要不要采用限制长度的策略？
 *  哪些表中应该建立索引？
 *  建立什么类型的索引最能提升访问效率？
 *  建立了索引会不会对数据插入的影响太大？
 *  事务怎么做？事务隔离级别怎么做？
 *  ……

通过与项目组成员的充分讨论、修改，最后成文《\*\*\*\*\*项目数据库设计说明书》。

6、详细设计与说明

详细设计也是项目中的一大挑战。其实，详细设计最理想的出现时机就是在项目前期，也就是说，此时，项目还未真正实施，一行代码都没有，这个时候详细设计就已经做好了，规定了每个模块的每个功能前端页面展示了哪些数据（数据是如何展示的已经在上一阶段的原型设计中完成了）、调用了后端的哪些方法，传递了哪些参数，用到了数据库的哪几张表中的哪几个字段，各个功能的内在逻辑是怎样的。这样的详细设计文档一出来，后面的项目实施人员闭着眼睛就能把整个系统做出来。我不知道大公司的项目是不是这样在执行的，但我知道这对从来没有做过项目设计和编码实施的同学来说，确实是一大难事。因为我所经历的项目组导师就是这样要求我的，但彼时能力不够，也没有过这样的经历，根本无法领会到这一层，这样的详细设计也就无从谈起了。就这样，我们项目组在没有《\*\*\*\*\*项目详细设计说明书》的情况下就开始了项目编码阶段。

等我们编完代码，进入到项目收尾阶段，我才将《\*\*\*\*\*项目详细设计说明书》补起来了。

**项目中期**

项目进行到中期，其实就是编码阶段了。《\*\*\*\*\*项目详细设计说明书》这个文档可以作为编码的最高纲领。项目组成员之间的沟通都是基于这个文档进行的，可以节省很多沟通成本，大大提高编码效率。之前在项目组的时候并没有这个文档，就只能靠口头交流或是暂时性的文档支持，不得不说，这样的方式还是带来了很大的麻烦，也一定程度上影响了项目的实施。但经过整个开发流程后，每个人都有自己的认识、理解与收获，这也算是成长的一种方式吧。

**项目后期**

1、项目测试

项目编码完成之后，开发人员要组织进行自测。这时候的测试就不是开发过程中的模块化测试了，而是整个项目拉通了进行测试。看各模块功能是否开发完毕，已经开发完毕的功能是否可用，是否满足前期需求文档、概要设计文档的要求……

本来测试又是另一个领域的问题，我没有学过正统的测试，因此只能做到这些皮毛。在更加规范的开发中，测试其实是关键且重要的一环，是要贯穿整个开发始末的。不仅包括对项目的功能测试，还有对项目负载等性能测试。这部分后来用Apache组织开发的基于Java的压力测试工具JMeter进行了测试。但也只是对性能进行了测试，还没有感受过真正的测试。希望有机会可以加入到大项目中去感受一波。

开发人员要对测试中发现的问题进行集中解决。解决完之后要再进行测试，一方面查看bug是否改正，另一方面避免影响到其他正常功能。

2、用户操作手册

系统经过几轮测试，稳定之后，就可以编写《\*\*\*\*\*项目用户操作手册》了，交付使用。