软件开发模式的研讨

    软件开发有其内在规律和模式，发现规律，总结模式，能给软件开发的过程带来便利和提高开发效率。


1.人员配备
1. 项目经理
2. 售前人员
3. 需求设计人员（刻画交互界面）
4. 技术经理（搭建基础架构，确定框架，选用组件，确定各个模块，主要类之间的交互方式，基础表结构，搭建开发环境和测试环境）
5. 领域专家（协助需求人员确定需求，业务表结构，和技术经理确认主要类，主要模块之间的通讯方式）
6. 小组长（核心开发人员，辅助某模块，并分解任务，自己承担一部分主要开发）
7. 组员（一般开发人员，得到组长分配的任务，并完成）
8. 测试人员（根据技术经理的测试指标，在指定的测试服务器进行测试）

2.基础组件储备
对于企业应用来说，储备如下通用组件可能是需要的：




还需要：规则引擎（分为数值计算规则＋海量数据处理规则），站内全文检索（lucence,compass，solr），单点登录（cas），消息总线机制等


3.软件开发模式选择
瀑布模式
常规项目：需求－》概要－》详细设计和编码－》单元测试－》打包，集成，回归测试－》性能测试－》上线试运行－》移交（割接）－》维护阶段


螺旋迭代开发
对于研发类型的项目：



4.开发过程管理

1. 项目经理掌控所有的过程开发文档，敦促相关组员进行编写，并和质监部交互（按照cmm3的标准）
2. 技术经理捏拿开发过程的管理，根据cmm2的部分关键域：
1) 需求管理（和售前以及需求设计人员协作）
2) 软件项目计划（自己）
3) 软件项目跟踪及监督（自己）
4) 软件质量保证（和测试部协作）
5) 软件配置管理（和质监部协作）
6) 软件子合同管理（忽略）

3、组长对分配给自己的需求进行分解成任务，分配给组员，组员编写代码后，建议写个简单的测试java（junit为好）作为源代码的一部分提交，后期接受的开发人员可以通过测试java很快理解该模块的入口和基本功能。


5.过程管理中的工具配备

技术经理捏拿开发过程的管理，根据cmm2的部分关键域：
1. 需求管理（requisitepro，powerdesigner,excel，jira）
 售前主管的售前文档和需求人员设计的界面，需要入版本库管理，关于需求矩阵图可以采取excel的方式，也可以采取requisitepro或者是powerdesigner的需求管理工具。
 分解到个人的时候可以采取jira的需求类型，分解到个人，并能跟踪到该需求的生命周期的状态。

2. 软件项目计划（project，jira）
 有项目经理，技术经理拿出整体开发计划安排，形成project文件。
 由技术经理或者是领域专家分解任务，形成内部版本（内部迭代版本，或者里程碑版本，以及内部模块划分），并在jira中设定完毕，在哪个时间点，实现了多少需求，分配了多少问题，发现多少个bug都一目了然，并且能进行问题（需求，任务，缺陷）的重新分配

3. 软件项目跟踪及监督（jira，fisheye，svn）
 在jira中把任务分配下去，并设定时间，组长和技术经理就能看到该任务的执行情况，以及当前的进展；
 代码提交后，在测试过程中如果发现了bug，在jira中登记为bug，并把bug指派给技术经理，技术经理分解到组长，由组长分配到个人，并可以通过bug的数量能初步统计每个人的缺陷数。
 技术经理和组长能通过fisheye来统计每个程序的代码共享量（做的快的同时分配的task会多一些，能者多劳）


4. 软件质量保证（jira，junit，loadrunner，jprofile）
 程序员的（单元）测试代码随和代码一起提交（单元测试）
 组长，技术经理在此基础上设计junitsuit，作回归测试，发现问题，登记bug（集成测试，反复）
 在测试机器上搭建loadrunner，2种测试方式：持久测试和并发测试
 持久测试是检查否有无法回收的内存块，没有释放的连接
 并发测试是检查并发压力的支撑能力。
 Jprofile检查哪些api最占据时间和空间，用来额外优化


5. 软件配置管理（svn，clearcase+clearquest）
通过svn来实现。Clearcase+clearquest能实现所谓了ucm方式，不过成本太贵，代价太高，一般来说用jira即可，各个jira之间的问题（任务，需求，缺陷）可以作关联，也算是统一变更管理的简单实现。


6.工作流平台项目中的软件过程管理

1. 需求
本项目因为是内部研发项目，并没有大量的需求文档，需求是从领域专家这里获取，少部分的界面是从EI的需求人员设计好发过来，需求直接在技术经理/架构师这里就分解到了各个组长和成员。
目前除了基本的需求文档，界面设计入库，在jira上登记需求，其他需求管理较弱，也没有采取需求矩阵跟踪等工具。

2. 软件建模
软件建模分为2种：数据库建模和软件架构建模，2者都使用powerdesigner来设计；分别是用pdm和oom的模块。切图如下：
 数据库建模：
数据库建模统一控制，并生成sql语句和数据库表的说明文档，定时发布在svn上




数据库建模切图



 软件架构建模：
因为本项目的特殊，engine部分自身结合紧密，垂直分隔不容易，所以采取的是分层分隔法。由领域专家把engine的基本类图搭建出来，刻画彼此各个类之间的交互关系，采取面向接口的方式，生成了初始版本的eclipse工程后，由成员各自设计分配的api，这样领域专家设计的思想得到了继承，知识得到了共享，而且各成员做出来的东西，能按照领域专家预期的目标能集成起来。
要求领域专家对UML以及OO建模有深刻的理解，并能传授给大家；以及核心组件能独立设计（所谓领域专家必须对该领域有深刻了解并有较强的实现能力）







架构切图1：engine总体框架（不包括FSM







架构切图2：engine对外接口暴露





架构切图3：engine核心模型的定义




3. 软件过程
根据项目带有研发特性的特征，采取了螺旋式开发方法，主体开发阶段划分为3个迭代周期，每个迭代完成特定的工作，按照先基础后高级，先容易后困难的模式开发的次序。

4. 开发模式选择

传统企业应用开发模式：大部分是围绕数据库的一种大规模数据运算，涉及到界面显示、交互，数据的增删改查，以及保证数据的一致性。大致分为表现层，逻辑层，数据库层，吻合pojo+service+dao+dao，整个项目体系可以理解为一种面向过程的思想。一般企业构架的图示如下：



传统企业应用开发模式


考虑到我们实现的代码就是为企业应用服务的，所以在本项目中我们依然是继承了这个开发模式，并有所扩展，具体来说在service多设计了几个层次。层次扩展如下：

TestClientAPI是最外的代码，从左至右，依次靠近engine的最核心。从客户端engine9个模块接口以及实现类内部辅助类 DAO JDBC。这里只画到了内部辅助类，整体的层次说明在下面表格中说明。







5. 配置管理
配置管理采用公司提供的服务，利用svn，不过可以考虑利用jira的功能，并和某一段代码，需求作关联，这样就能实现一个简单的统一变更管理。在本项目中只是单纯的用得到了svn功能

6. 测试管理
我是要求engine的组员要写测试api（不限定是junit方式），因为最后代码收拢后，统一在我这里过一遍junitsuit。我定义了2个junitSuit，一个是api的集合，一个是业务逻辑案例的集合。
Api集合简单的测试api的功能，后面的逻辑案例是模拟一个流程在跑动，起止阶段和中间过程中作状态检查。代码更新后先跑一次junit，这样有无修改冲突等一目了然。
在迭代1采取的是粗放是测试管理，因为此时大家集中精力实现功能，在迭代2阶段，部分功能已经实现，发现的bug纳入jira的缺陷管理，并作统一分配。
在迭代1结束后作了一次压力测试，发现了一些问题，作了调整和优化，并用jprofile分析了源代码，已经发现了在某种业务情况下的业务api瓶颈，考虑在后期再优化。


7. 管理工具的应用
主要是对jira+svn+fisheye+confluence的应用。
jira：作为需求，任务，缺陷的管理，界面如下：

典型的jira有4种问题类型：缺陷,需求,任务,改进









项目经理，技术经理，组长的登录界面，添加了一个组员的任务查询列表，方便工作的检查











问题的生命周期
一个问题有几种状态，常见的为打开－》处理中－》解决－》关闭问题。
Jira其实内置了osworkflow作为他的工作流引擎，一个问题就是一个流程实例，当问题关闭的时候，也就是这个流程实例结束了。







该工作流能支持大部分的通用业务流程，比如缺陷，需求，任务均可。

企业版本的jira支持自定义流程，可以划分为需求，现场支持，软件开发等详细的流程。





Fisheye：代码查看器，需要和svn结合起来


Fishsye 查看1，工作流代码（目前已经迁往ei svn，故有个直线下降的箭头）




查询单个成员的代码贡献






图表显示