软件项目流程

软件开发从业者福利！软件项目流程思维导图。软件开发流程一般过程，包括对软件先进行需求分析，设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编码和调试、程序联调和测试以及编写、提交程序等一系列操作以满足客户的需求并且解决客户的问题。喜欢请点赞收藏！关注我，能持续获取优质导图哦。

项目流程

运行维护

项目测试

黑盒测试、白盒测试、单元测试是开发人员分在不同的开发阶段要做的事情 黑盒测试、集成测试、系统测试是测试人员在测试周期内级层做的工作 验收测试一般是在用户方做的工作

测试方式

黑盒测试

不考虑程序内部结构和逻辑结构，主要是用来测试系统的功能是否满足需求规格说明书。 一般会有一个输入值，一个输出值，和期望值做比较。黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试

白盒测试

主要应用在单元测试阶段，是对代码级的测试，针对程序内部逻辑构，测试手段有：语句覆盖、判定覆盖、条件覆盖、路径覆盖、条件组合覆盖。白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致

中小型的WEB项目，就自己的经验，在开发成型之后的测试、使用过程中主要会出现四类BUG

第一类是比较明显的错误。比如出现错别字，样式问题导致的页面显示混乱或对通用浏览器不兼容，表单字段合理性验证问题导致程序异常，页面之间的跳转出错，操作过程抛出程序异常（Exception）

项目被公司组织人员测试之后，正式部署到客户要求的服务器中。正式部署之后应该先试运行一段时间，没有大的问题，才能被正式使用。试运行阶段及正式运行初期，客户很可能会反馈不少新问题，有些是明显的错误。不过，如果前期测试严密的话，这时更多反馈的应该是修改意见，比如增删改些字段，变换下操作方式，等等类似于公司测试人员的“似是而非”的问题。对于这些“似是而非”的修改要求，项目经理应根据实际情况和客户之间商讨决定。每次更改之后、发布新版本之前，应该把更改过的相关业务从头到尾再测一遍，这的确比较耗时，尤其是客户频繁更改的情况。为了减少频繁的更改发布，应该想办法让客户尽可能的一次提出所有的更改要求——当然这不容易，不要今天提一点，明天想到了再提一点，频繁的更改发布会另出现新问题的概率大大增加

正式部署之后的修改再发布就是版本更新了，发布时应该先检验新版本中配置文件的变化，有没有增加、修改或删除的内容，如果没有则不发布配置文件，如果有则和当前运行版本中的配置文件进行校对、整合。如果当前版本有要下载的程序包，注意要发布项目的程序包的版本和当前运行项目的程序包的版本的异同。还有，上传的文件应该存放在独立于项目之外的虚拟目录中，即能防止发布时不小心被覆盖或修改，又方便后期的文件备份。发布项目时要注意的问题应该整理成文档，发布操作严格依照文档说明进行，可有效避免发布导致的不必要问题

第二类是不容易发现的错误。比如多用户同时操作导致的并发问题，程序编写规则有误导致的数据准确性问题，业务处理过程中出现明显过失问题，如给予某个角色不应有的权限

第三类是在稍具规模的项目中常会出现的错误。比如由脚本、样式、程序导致的网络延迟，脚本、程序执行效率导致的响应速度过慢，数据量过大导致的数据库查询速度过慢，等等，大都是和性能相关的问题

第四类是新版本发布导致的问题。比如配置文件被不小心覆盖、替换或内容被手动更改，WEB项目中的附属安装程序包在发布新版本时不小心被不同版本替换，根据用户要求对功能进行修改之后出现新的BUG

测试范围

单元测试

是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试

集成测试

是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其它软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各个组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。也可以理解为在软件设计单元、功能模块组装、集成为系统时，对应用系统的各个部件（软件单元、功能模块接口、链接等）进行的联合测试，以决定它们能否在一起共同工作，部件可以是代码块、独立的应用、网络上的客户端或服务器端程序


系统测试

是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其它软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各个组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。也可以理解为在软件设计单元、功能模块组装、集成为系统时，对应用系统的各个部件（软件单元、功能模块接口、链接等）进行的联合测试，以决定它们能否在一起共同工作，部件可以是代码块、独立的应用、网络上的客户端或服务器端程序

验收测试

项目开发

项目设计者更应当在平时扎扎实实的提高自己各方面的基本功，以尽可能的完善前期设计。而为了应付非理想情况下的前期设计，项目开发者要注意的问题也有很多，就过去的经验，项目开发过程中要关注的主要有下面几项

第一个要注意的问题是页面、样式、脚本、程序的编写细节

我们在完成设计后动手开发，第一件要做的事情是将UI设计师出的效果图转换成HTML页面，也就是美工常说的切页。那页面是什么格式的，HTML、ASPX、JSP还是PHP？美工和负责前端脚本的开发人员、负责后台程序的程序员之间应该先达成一种共识，其实在项目设计阶段，这里应该是先规划好的：页面、脚本、后台程序间通过什么样的方式交互？虽然前台脚本和后台程序完全是两码事，在细节上差异巨大，但编写脚本和编写程序要追求的目标是相似的——脚本和程序的架构设计都应该尽可能的低重复、高扩展、易用易调取、安全，甚至是样式和页面的设计也应该追求类似的目标，比如页面、样式、脚本、程序都要求低重复性。如何保证高内聚、低耦合定律？如何在程序中抓捕所有的异常、不让任何一个异常被暴露？等等这些问题，在设计架构时就应该考虑到。自己过去的笔记中有关于架构的问题列表，应该做些整理，力求不再让这些问题出现在开发环节。不敢对样式和脚本的技术细节枉谈，但具体到后台程序的编写，思路可以参考《重构，改善既有代码设计》这本书，里面有很多代码重构的技巧、实例值得学习借鉴。在开发环节，前端和后台程序的编写是可以并行的。有些环节必须单步顺序执行，比如只有效果图出来后才能出切页，但大部分环节是可并行的。在不同的开发阶段团队人员的工作量也是不一样的，熟悉之后，可以更轻松的对团队中的人力资源进行调配

第二个要注意的问题是代码生成器等工具的使用

要创造软件生产流水线，主要依赖的工具就是代码生成器。学会使用CodeSmith之后，代码编写的效率有了很大的提高。CodeSmith就像是软件工程中的机器人，其存在的目的就是为了消灭重复工作、消除体力劳动，让人专心于创造工作。像数据库设计工具PowerDesigner、代码审查工具StyleCop、程序帮助文档生成工具SandCastle等等都是类似的目的，学会使用这些工具，可以让自己的工作事半功倍。不过“有机械者必有机事，有机事者必有机心”，想要熟练的应用这些工具也是要费时间和心思的，而且工具并非万能的。比如CodeSmith，过去一直试图用其生成尽可能多的代码，但却总有些部分需要手动去改，这样整个项目的编码就会分成三部分：一部分是纯手工编写的，比如工具类库；一部分是混合的，既有生成的也手动更改的；一部分是纯工具生成的，比如数据库访问层。常用的工具类到是可以统一做下整理到工具类库，也不麻烦，但需要手工改动的其它部分还是要耗人力的。希望可以将这部分需要手工改动代码降到最低，让绝大部分代码可以由工具自动生成、自动修改。尽管便捷工具的问题有很多，但整体来讲，还是有不少好工具值得人花些时间去学习使用

第三个要注意的问题是开发进度跟踪

在项目设计阶段，应该有比较明确的进度表才对，即便没有很明确的文档、没有用Project，项目经理心里也应该对时间有数，在某个时间点某个功能必须完成、在某个时间点必须出来可演示的版本、在某个时间点必须可以上线试运行、在某个时间点所有的项目开发工作必须完成。还是那句话，抛开时间来讲工作毫无意义。为了跟踪项目开发进度，确保项目的每个阶段性目标可以按时完成，定期的团队会议是不可或缺的。通过会议间的沟通协调，找出时间延后或提前的原因，以部署下一阶段的开发任务。当每个阶段性目标都可以准时完成时，整个项目的开发定然也能按时完成

第四个要注意的问题是人与人间的沟通、协作

中小型的项目，一个人可以勉强应付的，我决不会希望去安排两个人。一个人面临再多的问题也都是项目的问题，多一个人性质就完全变了，沟通协调、意见统一、互相游说争辩，耗费的无用的时间可是要倍增的。但是，你总不可能所有的项目都独自开发，更多的情况下，还是要跟人合作的——人或多或少。良好沟通协作的前提是团队中所有的成员必须在出现不同意见时保持心平气和，团队人员和客户之间互相角逐，团队人员之间互相角逐，团队人员和团队领导者之间互相角逐，团队领导者和公司各部门、和公司领导之间也在互相角逐，费心费口舌！为了保证沟通渠道的畅通，定期的会议是必须的，团队也应该定期向领导作汇报，并时刻和用户保持沟通，时刻了解用户的想法、纠正可能的错误。一直到现在，都不敢说用户的需求已经全部确定了下来

第五个要注意的问题是开发过程中的沼泽地

在开发过程中（设计阶段也有）经常会碰到突然毫无头绪的情况，有早期的设计也不管用，就是不知道如何走下去了。还有可能突然发现，后期一些功能的实现把整个程序结构全给打乱了，虽然跌跌撞撞完成了要实现的功能，却觉得程序超脱了自己掌控。再有就是开发遇到致命问题，如陷入泥沼一样，项目到了进退不得的地步。灵感丧失的状况经常出现，对着屏幕大脑却一片空白，这时通常会躲到空空的楼道阁间中来会踱步，才会理出些思绪。还有，自己开发的每个项目几乎都有相应的笔记，不停的写不停的分析，这些笔记一方面用于计划、安排、总结自己当前的工作，一方面帮助自己清理思路找到工作灵感。还是比较偏向于在灵感缺失时到外面去走走换个思路的办法，再就是平时应该多读些技术类的书、多关注网上的实际案例、多参与高难度项目的开发，让自己拥有源源不断的源头活水，如此，思维将永不枯竭。遇到程序结构被打乱的情况也无需担心，只要不影响大局，后面可以专门抽出时间来对相应的代码进行重构、整修。开发过程中沼泽地的出现大都还是因为早期设计考虑的不完整，如果早期对架构设计的足够灵活，增删功能都应比较自如才是，项目是不太可能出现致命问题的。应该在设计之时考虑到相应的回改机制，如果在开发过程中出现了一些不可测的问题，数据库、架构、程序能否方便灵活的做出相应调整

第六个要注意的问题是程序文档的整理

规模较大的、比较正规的项目，程序文档不可或缺。程序文档在中小型项目中的作用并不大，因为团队间的协作开发完全可以通过直接查看源程序及程序注释来降低互相对接时出现的麻烦。Java中有javadoc命令，用于生成自己API文档的，.NET平台下有工具SandCastle。用工具生成就很简单了，所以不论具体作用有多少，最好出一份程序文档，哪怕仅仅是为了做做表面工作、提供给项目验收者查看。这里着重要说的是接口文档，如果按自己设想的架构，前端和后台程序间通过ajax调用WebServcie接口进行交互，那这个接口文档是必须的。而且，打算在新架构中将这些交互接口做成通用的，不仅提供给自己的项目前端使用，还可以将其开放给外部平台，如此，接口文档更是不可或缺。最好有个测试用的接口平台，比如在XX医院时见到的那种，可以方便的在平台上对接口进行测试，这对外部接口调用者来说是非常方便的。只是不知道，他们用的什么技术做成的那个平台

项目设计阶段，要考虑的主要有七个问题

第一个是业务流程，核心业务、附属业务的流程各是什么样的；

业务流程是我们在需求分析过程中就已经开始确认的，但这里要尽一步具体化。拿起手里的铅笔，把项目中的所有业务列举出来，再把每个业务的流层图画出来。反复检查这些流程图，检查业务的每一个环节，并跟客户沟通确认。当所有的流程图可以无误的表述各个业务时，我们的设计就已经成功了一半。 画流程图的过程，就是在脑海中模拟使用要开发的软件的过程，不过这时的软件还在虚无缥缈之中。在我们的脑海中虚拟出一个大工厂，但里面什么也没有，尝试着走入这座工厂去完成自己的任务——也就是客户提出的需求。为了实现需要的功能这里可能要建一个车间，然后思考车间应该有多大、应该建成什么样子的？为了完成要实现的功能这里应该放置一台机器，这台机器应该如何安放、用来制造什么物质？就这样的自由组合拼接，直到这个工厂可以实现我们提出的所有的功能、完成我们所有的业务流程。然后继续在脑海中模拟使用这个工厂，一遍又一遍的走我们的业务流程，直到确认每个环节都不再出现问题，都可以应付现实的需求。在这个过程中，业务流程中不合理部分会被修改或剔除，我们的流程会更趋于，同时我们要开发的软件也已经开始成型

在需求分析之后应该有初步的流程草图、模糊的项目模型和相对明确的需求确认书，而在项目设计之后，必须有客户确认的前端效果图、完整的数据库表结构、数据库文档及详细具体的项目开发文档。这个项目开发文档，可以是一份，也可以拆分成多份。里面有开发背景、需求分析、业务流程、技术难点、架构、程序编写方式、人员安排、时间规划等等的详细介绍。当这些文档出来之后，我们的设计也就已经明确下来

第二个是前端，包括效果图、页面、脚本、样式

在梳理这些业务流程的时候，或者说在建工厂的时候，脑海中应该已经开始考虑界面部分如何实现了，还是用手里的铅笔，把界面的草图画出来。每个业务的每个环节，在前端如何展现？以什么样的方式最有特点、最绚丽出众、最易于人机交互？只是，项目经理也只能给出一个大致的草图，具体的设计实现还是由美工人员来完成 外观界面是项目给人的第一印象，站在客户的角度来讲很重要。就像一座房子，你用的钢筋混泥土的质量再好，入住的人是看不到的，可如果装修的很奢华，那给人的第一印象就是这房子很高大上。程序员一般容易轻视界面的重要性，觉得这不过是一幅皮囊，只要架构足够稳定，界面再怎么绚丽，也不过是是增删改查几种动作的操作方式不同而以。这样想也无可厚非，说明项目开发团队中每个人的关注点不同，但项目经理应该有全局关念，要清楚的知道每个部分的轻重。在不同的需求、不同的客户、不同的领导、不同的时间、不同的外部状况下，各部分的轻重缓急并非是一成不变的


第三个是数据库，把业务流层转换成表结构、表与表间的关系；

数据库的设计跟界面草图的设计几乎同步，业务流程分析完毕、界面草图绘制完成，实现这些业务用到哪些表就很明确了。还是用手中的笔，把要用到的表列出来，把每张表的关键字段列出来，把表与表间的关系标注出来。从其功能上来讲，数据库就像工厂的仓库，但对软件设计者而言，数据库更像是一栋楼房的地基，直接决定着整个项目的稳定性。 有人说数据库难以设计，其实难的并不是数据库的设计，而是业务流程的梳理。再复杂的业务，只要理得清，表现在数据库中，无外乎是表与表间的三种关系：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%的开发时间。项目经理心里面应该有非常明确的人员安排计划、时间节点跟踪计划，并将其落实到文档中。开发进度应该严格依照进度表推进，并根据明确的时间节点（里程碑）进行定期的考核、演示

项目设计

经过需求分析之后，我们手里已经有了一份比较明确的需求确认书，同时项目经理的脑海中也有了一个模糊的模型。项目设计环节，就是要以这份需求确认书为基本依据，和客户继续保持沟通，将脑海中的项目模型具体化下来，落实成效果图、CDM、PDM及开发文档等电子资料

需求分析

对需求进行分析的过程，就是将早期进行需求了解时搜集到的资料、脑海中的零散碎片进行整理的过程，最终以文档的形式将需求具体化下来。

怎样（How）？

实现这样的需求应该怎样做？有没有技术难点、可否实现？业务流程应该是怎样的？数据库如何设计？总的架构如何设计？框架如何设计？前端如何设计？能安排给谁来做各模块？目前的需求有哪些模糊的部分需要再次确认？

早期的需求分析，我们至少要得出下面四个问题的的初步答案

初步整理后的需求确认书。

在对了解需求时的资料进行梳理后，整理出一份前期的需求确认书。至少要把核心需求列清晰，以文档的形式具体化下来，并和客户保持非正式沟通、确认。这样的沟通确认应该是多次的、循环的，以对这个确认书进行多次的完善，逐步的将其具体化。

在整个的需求分析过程中，在早期的需求确认书出来之后，我们和目标对象的沟通应该是持续的。在最后应该和目标对象进行一次正式详细的沟通，把早期的需求确认书、早期分析之后零散的碎片进一步整理，然后再出一份正式的需求确认文档，交由用户签字确认。这份文档，就是目前可得到的最详细的需求确认文档。

在这个需求分析、对需求反复确认的过程中，脑海中其实已经开始进行项目的初步的设计才对。流程、架构、界面、数据库、程序、前端、业务、权限等等片段，已经开始出现在脑海中了。需要哪些人来做哪些模块、各模块大致要花多少时间、哪些功能哪些环节可能会出现问题、项目开发之中开发之外的阻力可能会有哪些？这些自己心里面都应该有数了，只是，仍然没有具体化下来，而这个具体化的过程，就是项目设计的过程


可行性研究

对这个初步的需求确认书进行可行性研究，用户的要求是否可以实现。如果不可以，为什么？难点在哪里？如果可以，难度系数如何？从个人来讲、从单位来讲付出收益间是正值还是负值？在你看来，结合你当前的时间安排，这个到底值不值得抽出时间来开发。

业务流程

自己了解到的用户需求，实现这些需求的业务流程是怎样的。核心业务有哪些？核心业务的流程是什么？附属业务有哪些？附属业务的流程是什么？比如要给犬只办卡、比如要进行会诊、比如要交费、比如要统计、比如要管理网站展示信息、比如要进行权限管理，等等，大致的流程是怎样的？这些要和用户确认清楚。更详细的流程，会在设计阶段具体化下来，这里必须得出初步的流程。


开发成本

如果说这个项目可以开发，值得开发，业务流程也理得差不多了，那需要多少人、具体到是谁？需要多少时间、最少要多少时间、最长要多少时间？你个人以及公司能否持续投入这样的时间和人力来做这项工作？

多少（How much）？

这个项目的繁杂度如何？做的话时间成本、人力成本是多少？项目的收益是多少、对单位对自己对现在对将来有什么益处？对单位来讲有没有市场？对个人来讲能不能锻炼自己巩固提升自己的位置、还是仅仅徒增麻烦？

了解需求

做什么（What）？

这是什么？要实现什么功能？必须要实现的功能有哪些？不确定是否要实现的功能有哪些？核心的功能有哪些？是WEB应用系统还是桌面应用程序？是注重处理业务实现还是注重信息展示还是两者兼有？对于数据库有没有特别的要求？有没有什么规范、有的话是什么？

谁（who）？

项目的需求来自于谁（哪里）？项目的使用者是谁？项目的沟通协调人是谁？项目的检验者是谁？项目的主负责人是谁？

何地（where）？

开发完成的项目最终要部署在什么地方？环境是内网还是外网？什么操作系统什么数据库什么环境可变动否？确定的还是不确定的？

何时（when）？

目标对象要求多长时间完成工作？自己初步估计需要多长时间可以开发完成？目标对象的可承受时间下限是什么？

为什么（why）？

Why应该是贯穿在前四个W中的，每得到一个W的答案，都应该多问一句，这样做的目的是什么？为什么要这样做？不这样做不行吗？用另外一种做法行不行？Why提供了一个更好更深入了解需求的机会。

人员组成

美工

熟悉UI的设计并具备将效果图转换成前端页面的能力，也就是得同时精通PhotoShop、HTML、CSS、jQuery等前端知识

一个负责UI设计，做出完整的效果图，这个人的设计功底应该比较强

负责将效果图转换成页面，并完成样式、脚本等的编写，这个人对前端样式脚本的掌握应该比较熟练

程序员

熟练掌握代码的编写重构

根据业务将软件划分成不同的功能模块，按照功能模块进行工作量上的划分，交给不同的程序员完成

据程序架构进行工作量上的划分，实体由谁来负责、接口由谁来负责、应用层由谁来负责、业务逻辑层由谁来负责、数据访问层由谁来负责，等

项目经理

备需求分析的能力、数据库设计维护的能力、架构设计的能力、程序编写的能力、前端样式脚本编写的能力，最重要的是对业务流程有精准的把握

部门经理

具备领导能力

模块划分

前端

程序

数据库