第一个是业务流程，核心业务、附属业务的流程各是什么样的；
业务流程是我们在需求分析过程中就已经开始确认的，但这里要尽一步具体化。拿起手里的铅笔，把项目中的所有业务列举出来，再把每个业务的流层图画出来。反复检查这些流程图，检查业务的每一个环节，并跟客户沟通确认。当所有的流程图可以无误的表述各个业务时，我们的设计就已经成功了一半。
画流程图的过程，就是在脑海中模拟使用要开发的软件的过程，不过这时的软件还在虚无缥缈之中。在我们的脑海中虚拟出一个大工厂，但里面什么也没有，尝试着走入这座工厂去完成自己的任务——也就是客户提出的需求。为了实现需要的功能这里可能要建一个车间，然后思考车间应该有多大、应该建成什么样子的？为了完成要实现的功能这里应该放置一台机器，这台机器应该如何安放、用来制造什么物质？就这样的自由组合拼接，直到这个工厂可以实现我们提出的所有的功能、完成我们所有的业务流程。然后继续在脑海中模拟使用这个工厂，一遍又一遍的走我们的业务流程，直到确认每个环节都不再出现问题，都可以应付现实的需求。在这个过程中，业务流程中不合理部分会被修改或剔除，我们的流程会更趋于，同时我们要开发的软件也已经开始成型
在需求分析之后应该有初步的流程草图、模糊的项目模型和相对明确的需求确认书，而在项目设计之后，必须有客户确认的前端效果图、完整的数据库表结构、数据库文档及详细具体的项目开发文档。这个项目开发文档，可以是一份，也可以拆分成多份。里面有开发背景、需求分析、业务流程、技术难点、架构、程序编写方式、人员安排、时间规划等等的详细介绍。当这些文档出来之后，我们的设计也就已经明确下来
第二个是前端，包括效果图、页面、脚本、样式
在梳理这些业务流程的时候，或者说在建工厂的时候，脑海中应该已经开始考虑界面部分如何实现了，还是用手里的铅笔，把界面的草图画出来。每个业务的每个环节，在前端如何展现？以什么样的方式最有特点、最绚丽出众、最易于人机交互？只是，项目经理也只能给出一个大致的草图，具体的设计实现还是由美工人员来完成
外观界面是项目给人的第一印象，站在客户的角度来讲很重要。就像一座房子，你用的钢筋混泥土的质量再好，入住的人是看不到的，可如果装修的很奢华，那给人的第一印象就是这房子很高大上。程序员一般容易轻视界面的重要性，觉得这不过是一幅皮囊，只要架构足够稳定，界面再怎么绚丽，也不过是是增删改查几种动作的操作方式不同而以。这样想也无可厚非，说明项目开发团队中每个人的关注点不同，但项目经理应该有全局关念，要清楚的知道每个部分的轻重。在不同的需求、不同的客户、不同的领导、不同的时间、不同的外部状况下，各部分的轻重缓急并非是一成不变的
第三个是数据库，把业务流层转换成表结构、表与表间的关系；
数据库的设计跟界面草图的设计几乎同步，业务流程分析完毕、界面草图绘制完成，实现这些业务用到哪些表就很明确了。还是用手中的笔，把要用到的表列出来，把每张表的关键字段列出来，把表与表间的关系标注出来。从其功能上来讲，数据库就像工厂的仓库，但对软件设计者而言，数据库更像是一栋楼房的地基，直接决定着整个项目的稳定性。
有人说数据库难以设计，其实难的并不是数据库的设计，而是业务流程的梳理。再复杂的业务，只要理得清，表现在数据库中，无外乎是表与表间的三种关系：one-to-one、one-to-many以及many-to-many。更进一步的，many-to-many实际上就是两个one-to-many。对于核心业务部分尚不能明确表与表关系的，能一对多就不要一对一，能多对多就不要一对多。这样开发的复杂度会增加，却消除了后面可能的修改扩展的隐患。 “刻削之道，鼻莫如大，目莫如小。鼻大可小，小不可大也；目小可大，大不可小也。举事亦然。为其后可复者也，则事寡败矣。”说的就是这个道理。对于非核心业务也不能明确关系的，可根据实际情况，综合考量开发实现的烦琐程度及未来的可变性再做决定
第四个是开发用什么样的架构，前端、程序、数据库之间以什么方式对接；
当业务流程、前端界面、数据库的草图出来，就开始考虑项目的整体架构、前端脚本和后台程序的局部架构。前端和程序之间通过何种方式互调？程序和数据库之间以什么方式对接？前端脚本的代码如何编写？后台程序如何设计可以把代码重复率降到最低、把程序的稳定性、可调整性抬到最高？
类似于表现在数据库的三种关系，再复杂的业务，表现在具体的前端、程序中，无外乎是四种动作，对数据库操作的四种动作：增（Add）、删（Delete）、改（Update）、查（Select）。更进一步的，四种动作其实就两种：读和写。查为读，增、删、改为写，读写动作的操作频繁度比例大约为十比一
第五个是程序，既包括前端脚本的程序也包括后台的程序，程序的架构是什么样的，工厂模式、三层、还是其它；
界面、页面、样式、脚本、程序、权限、数据库、整体架构、局部架构，自己想要的到底是什么样子的？发挥好高级语言封装、继承、多态的特性，使架构和程序更加的安全、易用、稳定、高扩展、高内聚、低耦合且功能更强大。在开发过程中，应该把自己遇到的暂时不好解决的问题及一闪而过的项目灵感等进行记录，然后在后面的修改扩展中或者是下一个项目的开发中，吸收优秀的处理经验、竭力避免已经出现过的问题。只有通过这样的反复积累，自己在开发细节上的处理才会日趋完善
第六个是技术关键点，比如有的要用到读卡机等外接硬件、比如要放在触摸屏上、比如要有视频功能、比如要读取影像文件，这些特定的技术点如何攻破。
项目设计就是给出这个项目的实施方案。在设计的过程中，有可能会发现一些业务之外的技术难点，这些技术难点大都是之前未曾遇到过的或者是遇到过未曾完美解决的。比如前面提到的视频、影像及外接硬件等，这些技术难点如果攻不破，项目肯定也没办法完成。对于这些技术难点，应该额外分配人手专门对其研究、评估，这个也马虎不得。对于特定的项目，个人比较偏向于用开源软件解决这些特定的技术点，比如处理网页视频通信的有WebRTC、OpenMeetings，处理影像的有dcm4chee等等。不过这样做的问题也不少，如果开源产品不成熟，研究配置起来是非常耗时的，而且后期的更改维护几乎是不可能的，因为更改开源产品的源代码代价很大，相较之下反不如自己研究开发呢。对于公司通用的项目，遇到相应的技术难点，肯定是要专门分配人手研究的，比如有些公司本身就是做PACS的，那影像读取部分自然要掌握核心代码
第七个是人员安排和时间结点，具体到哪个人来做哪项工作，每项工作的时间节点是什么
业务流程的草图出来后，多次检查有无遗漏环节，并和目标对象循环沟通确认。然后把根据业务流程图绘制的前端界面草图交给UI设计师，并把想法告知，由其用PhotoShop将草图具体化成效果图，这个阶段，仍然和目标对象保持沟通。效果图出来后，找目标对象确认，并再次确认需求分析、业务流程有无遗漏、有无错误。经过客户、UI设计师、项目经理之间的反复沟通、反复确认、反复修改之后，出来一份最终的效果图。然后项目经理根据效果图之后更加完整的需求把数据库草图具体化下来，用PowerDesigner设计出相应的CDM图、PDM图，并用此工具整理出完整的数据库文档。这样前端界面和数据库的设计就算完成了。后面就是考虑程序和架构的具体实现方式了
最后应该考虑的是人员安排及开发周期问题，具体到团队中的谁、要做什么工做、时间节点是什么，可以借用Project工具，为开发任务分配资源、跟踪进度、管理预算和分析工作量。控制大型项目的第一个步骤是制定进度表，进度表由里程碑和日期组成。里程碑必须是具体的、特定的和可度量的事件，能进行清晰地定义
过去的项目开发对时间的控制非常糟糕，大部分项目最终完成所用的时间都是自己初期预估的三倍，这到也成了自己的一条经验。客户、公司给出的时间和自己的预估相差很大，所以自己的早期预估只能是非常保守的预估，后面就是长期的和公司、客户拖延时间。还真应了那句编程名言：最初的90%的代码用去了最初90%的开发时间，余下的10%的代码用掉另外90%的开发时间。项目经理心里面应该有非常明确的人员安排计划、时间节点跟踪计划，并将其落实到文档中。开发进度应该严格依照进度表推进，并根据明确的时间节点（里程碑）进行定期的考核、演示
