2.0 项目流程 需求分析请求

0：创业的话，就是一个点子，因为现在技术其实都能实现了。

1: 需求文档（项目经理）（如果是接来的项目，项目经理需要评估这个项目的可行性，例如要做健身的，就需要一个手表之类的）
      主题，
      受众，
      类似于什么风格的软件。
      主体的功能，需不需要第三方登陆，需不需要定时提醒，需不需要。。。。

2：需求分析-》

              2.1：UML图（类图），使用的工具是starUML 需要哪些数据，需要那些类，那些方法，不会特别细致，就是大概的。这个是不是应该架构师来做呢？？

              2.2：模型图：最底层数据库，然后网络层，控制层，UI，就像是老张的那个图吧

              2.3：UI/UE（用户体验）（产品部分）----》产出 原形图，整体的界面是什么样子的，返回按钮在哪，点某个按钮在哪个界面

              2.4：接口文档： 前台到后台，需要那些数据，需要提供那些数据

              2.5： 甘特图，就是我的plan的表，注意前置任务，前置任务就是这个任务必须完成不然其他任务不能完成

关于接口文档：可以查看下面的接口

接口的规范可以查看自己的资源里面的内容，也可以查看一下新浪的 接口规范：http://open.weibo.com/wiki/Oauth2/authorize

               http://m2.qiushibaike.com/article/list/video?page=
请求数据：
属性名 类型 默认值 描述
page int 1 请求的页

返回的接口：
eer：0，0代表没有错误，
。。。   。。。 。。。。


3：编码阶段， 标准的来说，产出物是一个测试版本，交给测试team去测试
小公司，编码事件最长，越大的公司，需求分析的较长，需求分析的事件有可能接近编码的时间。
测试版本也不能不稳定，肯定会报错的不要放在上面了，



4：测试阶段 给出bug的，压力测试一般是针对后台的。
测试组会根据需求分析的，去写测试案例，测试用例等等。
游戏的话，会有性能测试，
网络测试，有的时候会找网差的时候做，网络切换的时候，wifi换3G等。
公司小的话，就是一个excel的表格，
公司大的话，就会搭建一个defect的服务器

开始的时候，提交一个测试版本到测试组，测试组会测试一个星期，
后来的时候，可能就是2天一个版本，最后可能就是1天一个版本了。甚至半天一个版本。

理想情况下，是全部close，当然也会有deferred的defect，这个会在下一个版本中fix，
当然了重大的defect一定是要fix的。


-----------------------------------------------
自己的名下有bug的情况下，
open a defect/bug
not a defect/bug？，这个会到项目经理那边，最终决定在产品那边
fix
reopen
fix
close
----------------------------------------------

5：上线，分为两种，新品上线，产品更新，公测，时间比较宽松
如果着急的话，可以是一两个星期，如果不着急，可以是一两个月
产品更新的时候一定要在用户使用量最小的时候进行，半夜，11点之后，这个时候测试组的主要程序员，这个时候发现任何bug，在6点之前上线。

需要降低耦合度，公共类越多，耦合度越高，


网络，就是网络，
界面就是界面，我只要做展示就行了，数据怎么来的是网络的问题。（如果做网络的还没有做完这个，网络的需要先给假数据)，接口
一个人专门去写数据库
一个人专门去写框架
实体类不要再用gsonformat去生成了，因为开发的时候先有实体类（要加注解）

接口文档：

后台如果是c语言的话，需要一个对照表，为了考虑各个类型

接口
字段名，类型，是否为必选项，描述