标题：没头没尾--项目开发笔记：对应开发方式的变化
关键词：分布式开发 C# 项目分工 UML IDEF
11月22号：有点激动，有点沮丧
多谢各位朋友的意见！其实没有写这个项目笔记之前，有很多的问题我都没意识到。写的过程中从前从后可以体会出有很多的过程我们的团队是在糊涂的过程中就走过来了。过程中少的很多部分都是根据以前开发的经验来填充，以及团队中个别牛人的能力来填充。朋友们如果有什么意思与好的建议，欢迎讨论。
其实现在已经可以发现我所说的开发过程有一些问题。不过我想既然是笔记。那还是主要记录事实的好，所以过程的对错也就可能对现在也没有什么太大的帮助。大家就当成是经验与教训吧。不过还是欢迎讨论，为解决问题找到好的想法。
接着上次昨天的说。项目在试图采用UML或IDEF没有结果之后，加上我们花了大多的时候去讨论框架本身（这件事回头再说，讨论的过程非常的麻烦，并且得到的成果比较有限，我们也从框架的讨论中得到了一些总结）。也围绕着需求的文档反反复复的讨论过很多的次。正准备按照以前的开发过程来进一步的进行下一步的开发时，一个契机出现了。
哈，说这是个契机实在有点可笑。事实上是领导们提交给客户的计划中有一项条款是有一个非常短的时间内要交一个详细设计。这个事情项目组是在离提交给客户详细设计的前二周才突然知道的。这下子麻烦了，我还没搞定设计应该采用是什么形式，写什么呀。急急忙忙的找到了我们的需求，从侧面了解到详细设计这个东东客户也不是很在意，只是合同的条款上有这一条，要不什么前期款之类的东东没办法拿回来之类的。然后我根据我以前开发ASP时候的经验，我与需求人员可不可以用一个可以连接起来的应用程序的纯粹页面作为详细设计来配合需求人员与客户讲解需求。讨价还价的结果还不错。最后是同意采用这种方式来进行处理。
由于前期工作的情况，以及我们框架本身的特点，加上这个“契机”，我定义出了以下的开发过程度采用以下的开发模式：
1. 完成数据库设计，完成界面显示
l 主要工作
完成界面的工作以配合需求人员去客户处进行系统讲解。根据需求完成对象的设计与数据库的设计。
l 对应完成框架中的部分
1) 界面中模板文件的生成
2) 界面中重载控件的生成
3) 界面的主要程序的调度界面的生成
4) 数据库表的生成，部分数据库存储过程的生成。以及对应的dataaccess.base层与commondata层的数据文件生成
l 效果
需求人员可以使用我们制作出的界面与用户进行沟通，并进一步的明确用户的需要。并可以提前去实现与客户的交流。数据库的设计与准备文件将会根据数据库的表准备出dataaccess.base与commondata两层。（部分的准备存储过程，这个也是我们特殊的开发过程制约的。）
2. 完成界面逻辑
l 主要工作
提供工具生成数据库表从dataaccess.template直至webservice层的方法，将所有已经提供出的数据库表提供出SelectAll();AddItem();UpdateItem();DeleteItem()等等方法。以及已经定义出的存储过程的方法从Webservice上的调用。并将界面端所有控件对应的动作都做出响应。只实现最为简单的增加，修改与删除。
l 对应完成框架中的部分
i. 使用自己做的工具完成dataaccess.template,dataaccess,businessrules,businessfacade,webservice的代码架子。其中dataaccess.template,dataaccess,businessrules按照数据库的表结构来进行组织；而businessfacade,webservice按照已经定上一个步骤中的客户端的业务结构来进行组织。
ii. 实现界面的逻辑。对应所有界面上的运作都需要完成从Web Service取得数据以及回传的数据（定义好接口）的实现。以及界面的简单信息校验。
iii. 生成的文件的基础上根据界面的响应来进行修改，对应加入businessrules,businessfacade,webservice的方法。
iv. 新加方法时对应加入dataaccess的新方法。
l 效果
一个从界面上来说可以跑的程序。但并非从业务上可以跑的程序。只是完成了界面上所有对数据的简单操作（增删改）。
3. 完成业务逻辑
l 主要工作
最后大部分工作是真正的业务核心。通过以上两个步骤，我们已经实现了将除去业务的部分完成。这部分的工作就是具体去判断业务过程中除了去实现最基础的新增，修改，删除之后还需要实现的其它业务。比如删除一个商品的时候要去判断是不是这条商品已经被使用过等这些的业务流程。
l 操作框架中的部分
1) businessrules，针对特殊业务加入方法以及调用。
2) 对应上一层的方法加入dataaccess以及存储过程的调用。
l 效果
最终完成。
其中涉及到非常多的来这三个阶段中的人员的分工安排。以及每一个过程的实现都将会同时将我们的需求，测试，以及客户反馈带入新的阶段。
目前项目的工作在第二步的过程中。我想下几篇将会讨论定义这个开发模式时的思考以及具体实现过程中的问题。也会讨论我们在其中自己开发的一些小工具的思路。
明后天要去上课了。北京这么冷，早上八点就要上课，痛苦！
（这里有一些事情要补允说明一下：需求人员在我们这个团队中的角色非常的复杂。他们要做先期的需求调研。要做用户UI的审批，要做测试，要做售后技术支持。特殊的身份使我们的需求人员对于业务的了解非常的熟悉，与客户之间的关系很紧密。但是也有点过份的插手到开发过程之中。所以我这里的需求人员与朋友们做项目中的需求人员可能会有不同。）
