|
帮领导发到这里的，嘿嘿！！ 一、闭着眼睛走出第一步 俺负责评审的三个项目称为A、B、C，评审的目的是尽早发现开发过程中存在的风险，并及时消灭这些风险。 过去都是自己评审自己，评审别人的东东心里没数，不知道三个项目组的开发习惯，也不知道正确的管理办法，无奈之下我要三个项目经理先提交一份项目开发计划。我觉得无论如何，一个错误的决定比不作任何决定要更有好处吧。 尽管开始的方式很简单，我知道，具体工作展开后三个项目会各有各的表演方法，问题也会逐渐地发现。
二、每个人的心思都不一样 尽管提供了一份开发计划的国家标准，提交上来的三份材料存在着让我感到出乎意料之外的差异，作为管理人员，一定不要认为别人会自动按照你的思路思考问题。 ------------------------------------------------------------------
评审日记
------------------------------------------------------------------ 今天评审开发计划，教训如下： 1、项目必须开始于项目验收大纲。验收大纲在开始阶段只包含粗略的内容，随着项目的进展逐步细化。 2、本质上，验收标准就是需求、需求也就是验收标准。项目组成员必须树立验收意识——一切工作都是为了验收。 3、任何项目启动之前必须与用户签订验收大纲，然后才有可能编制项目开发计划。 4、项目验收大纲应该以系统功能为准，必要时辅以具体单据和报表的规格说明。这些内容应该尽可能早地具体化。 5、项目开发计划唯一的目的是保障项目按时验收。主要由两个维度构成： a)验收大纲； b)开发进度； 6、任何含混不清的项目开发计划都会导致项目最终失控，如果对开发计划存在不理解的地方，应该断然否决该计划。 7、如果开发人员不能遵循一个可控的开发模式，应该断然撤下这类开发人员。
三、首战失利总结 1.项目经理需要提交的第一份文档应该是项目验收大纲。因为缺乏经验，项目经理新手普遍缺乏验收意识。 2.在项目启动阶段，不可能提供全面详尽的验收标准。因此，我决定首先要求提交一份纲领性的验收标准。项目整个开发过程按照RUP方法，分成初始、细化、构造、提交四个阶段，每个阶段按照增量方式逐渐细化验收大纲。 3.确定了验收大纲之后，加上合理的进度计划就构成的开发计划。 4.我不打算把项目管理搞成文海战术，所有文档都以简要的表格或者示意图的形式提交审核。 5.推荐UML工具。 验收大纲的编制任务已经下达，不知又会出什么漏洞。 四、再战失利——首次编写验收大纲彻底失败 按理说已经有了明确的需求，编写验收大纲不会太困难。实际上问题仍然不少，又让俺碰了一次钉子。主要问题如下： 1.把验收大纲编写成了系统功能清单 按理说验收大纲就是功能清单，逐项功能验收就行了。如果这样做的话，系统开发的风险就太高了。原因是： （1）完备性：如何保障没有遗漏重要的内容？ （2）相容性：如何保障没有相互冲突的内容？ （3）独立性：如何保障没有相互重叠的内容？ 用户可以给一份自己没有把握的验收大纲签字，但他不会给一个不满意的系统付款。即使用户在目前暂时同意了验收大纲的内容，最后仍然可能不同意验收，我们不能掩耳盗铃。 我告诉你A系统有328个功能，你相信吗？从某种意义上来讲，不能保障合理性的功能清单是一堆垃圾。
的确，我们可以等到以后再发现问题，但代价太高。 降低系统的风险，重要的是让用户理解验收大纲的合理性，同时也让项目开发组能够更深入地剖析系统。 2.没有考虑验收场景 编写验收大纲不考虑实际的验收过程，完全站在开发人员的角度编写，到验收的时候就会欲哭无泪，你会发现验收过程和你预想的完全不同。许多你很得意地地方可能根本没人在意。经常有人说，“早知道是这样验收，咳，我当初就会采用xxx那样的设计方案。” 3.文档缺乏规范 文档编写太不规范，同一个概念竟然有n多不同的称呼。 4.不要在验收大纲中加入设计过程的内容。例如，数据库结构、底层接口标准等。这些内容的合理性客户没有验收依据。 5.有些项目的需求已经非常明确，这时验收大纲必须尽可能详细，最大力度地保障开发过程的可控性。 认真评审别人的文档让俺学了不少东西，许多习以为常做法其实并不平常，一个团队必须有严格的训练、磨合才能步调一致。我打算尽快做一次培训。 2005-2-26 18:18:38
下午组织学习需求规格说明编制的国家标准。
1无歧异
1.1术语的唯一性
1.2同一术语的多种解释需要说明各种解释的环境
2完整性
2.1包括全部有意义的需求：功能、性能、约束、属性、外部接口
2.2对所有输入数据的响应予以定义，要对合法的和非法的输入值的响应做出规定
2.3符合SRS要求。个别章节不适用，要保留章节号
2.4关于“待定”一词的规定
2.4.1必须描述待定内容
2.4.2删除待定内容
2.4.3拒绝承诺待定内容
3可验证性
4一致性：内容无矛盾
5可修改性
5.1内容组织
5.2没有冗余
6可追踪性
6.1向后追踪：追踪历史
6.2向前追踪：追踪派生文档 2005-3-1 17:47:05
五、编写验收大纲的总结 1.感觉好像是在评审俺自己 自己做过的软件也不少了，真的想让别人按照自己的习惯工作难得很哦。要把自己的要求写成有条理的规则，功夫又不到，实在是忧闷。 看起来俺已经走出了从理论到实践的第一小步，现在面临从实践在升华到理论的第二小步。也许只有一步一步这样顺循环下去才能进步。看起来好像是俺在评审别人，其实也是拿别人的工作作镜子照照俺自己。 2.编写验收大纲要以业务模型为骨架 俺觉得编写验收大纲一定要先把企业的业务模型搞清楚了才行，不然的话所谓的“用例”都是无皮之毛。如果验收大纲仅仅是不负责任地罗列用户需求是很危险的。 上面与外行兄聊天的时候我举了个真实的例子，有一次又同时拿他写的需求规格说明让俺看。那个系统包括总公司、分公司、代理商、最终客户四类对象，那份材料描述了5个资金流的处理方法。我画了一个示意图对那位老兄讲，你瞧这里一共有4*3=12类资金流，是不是剩下的7种情况系统都不需要处理呢？结果表明，用户把一些次要的需求给遗漏了。 俺并不是说不能遗漏任何内容，关键是在一开始就能发现的需求为什么非要等到最后才发现呢？ 3.ERP系统结构分析特点俺之见 所以，俺觉得做企业管理软件要抓住的要点是：计划类数据（如生产计划、订单、各类申请单）驱动业务类数据（如入库单、收款单、发货单等），业务类数据驱动物流和资金流。因此，首先要搞清楚的就是物流和资金流具体什么样的。 因此，分析应该从资金流和物流开始，到处业务数据（或者说业务单据）模型，有业务数据模型到处计划类数据模型。 其次，根据统计报表分析主要业务对象的属性。换句话讲，根据统计指标确定基本对象的数据结构。这是一项重要工作，但非关键性的，不会影响系统的总体结构。 4.发明“用例”这个概念的人还是值得表扬的 验收大纲的描述，感觉还是以业务用例为线索编写比较好。不过俺暂时同意提供一个用例清单作为验收大纲的做法，对于编写详细用例，感觉暂时没有必要。因为下一步的系统设计就能看出系统分析人员对用例的理解。俺的主张是推荐书面文档，但尽量减少，大伙能互相理解就行了。 2005-3-1 18:06:16
六、一个折中的管理办法 三个项目组的目前现状是，对于程序设计没得说，但对于开始程序设计之前的那些工作处在稀里糊涂的启蒙阶段。我选择了一个折中的方案，简化程序设计前需要做的工作，但严格控制的编码过程。凡是在编码阶段发现的问题，绝不纵容。 同时把需求、分析、设计、编码、测试换了一个做法： 需求 = 验收大纲
分析 = 数据库结构（用SQL Server表达思想）
设计 = 部署模型、包结构和类结构等(用C#表达设计方案并用Visio做反向工程画出示意图)
编码 = 编码
测试 = 测试 以后逐渐增加前三个阶段的训练，让大伙逐渐学会如何真正地撇开编程语言思考问题。 2005-3-1 18:51:09
七、项目A的验收大纲 把成果罗列出来，希望大伙给出具体的参谋意见。这里项目A验收大纲，以经过客户签字确认。 A项目验收大纲
（版本1.00） 致客户： 我们编写整理了这份项目验收大纲，以保障目前的开发工作能够有效地满足验收要求。 在正式验收之前，我们计划推出５个版本的验收大纲，随着项目的进展逐步展开细化验收大纲内容。大纲的第５版将作为最后的验收标准。 原则上，后续版本的验收大纲只能细化展开老版本的验收条款，不允许在新版本中增加新的验收条款。因此，请相关验收部门和人员仔细阅读本文件，并能达成签字确认。 为保障项目顺利实施，特任命
一、项目经理 xxx，负责项目的开发实施工作。
二、项目监理 xxx，负责监督本项目开发实施过程的规范性和项目的质量保证。
在项目开发实施过程中的异议请及时通知项目监理人，以便及时做出处理。 1业务用例
1.1销售部门
1.1.1销售人员
1.1.1.1订单
1.1.2销售经理
1.1.2.1订单
1.1.3发货人员
1.1.3.1发货通知单
1.1.3.2退货通知单
1.1.3.3移库通知单
1.1.3.4移库返回通知单
1.1.3.5自带底盘改装合同
1.2技术部门
1.2.1订单审核员
1.2.1.1订单
1.2.2BOM编制员
1.2.2.1编码
1.2.2.2BOM
部门管理
BOM资料管理
工艺路线管理
工装工具管理
供料方式管理
生产线管理
1.3财务部门
1.3.1订单审核员
1.3.1.1订单
1.3.2发货审核员
1.3.2.1发货通知单
1.3.2.2退货通知单
1.3.2.3移库通知单
1.3.2.4移库返回通知单
1.4生产管理部
1.4.1生产调度员
1.4.1.1生产计划
编制
签发，并生成上线计划、采购计划、自制物料清单
撤销
打印
1.4.1.2自制物料清单
1.4.1.3采购计划
1.5采购部
1.5.1采购员
1.5.1.1采购计划
1.5.1.2比价采购
1.5.2采购计划管理员
1.5.2.1经营计划
1.5.2.2生成安全库存
1.5.2.3维护产品目录
1.5.2.4维护常备物料目录
1.5.2.5生成采购计划
1.6车间
1.6.1生产管理员
1.6.1.1上线计划
1.6.1.2领料单
1.6.1.3供料计划
1.6.1.4作业计划
1.6.2工序交接单管理员
1.6.2.1工序交接单
1.6.2.2废品单
1.7仓库
1.7.1仓管员
1.7.1.1出库单
1.7.1.2入库单
1.7.1.3移库单
1.7.1.4产品组合单
1.7.1.5产品分解单
1.7.1.6退库单
1.8信息中心
1.8.1基础编码设置
1.8.2角色管理
1.8.3用户管理
1.8.4文件管理
1.9技术服务部门
1.9.1技服管理人员
1.9.1.1产品档案
1.9.1.2技术服务鉴定单
2统计报表及查询
2.1库存日报表
2.2供应商物料明细账
2.3库存物资明细余额对照表
2.4直送工位明细表
2.5库存材料余额对照表
2.6按单据汇总金额（此功能应在相应的单据中加上）
2.7按领料单位汇总金额
2.8查询出（入）库明细
2.9未结账出（入）库单
2.10月份个人销售完成情况统计表
2.11月份销售明细
2.12销售分布情况汇总表
2.13销售日报表
2.14销售收入计算表
2.15查询订单明细
2.16查询某段时间内的订单明细（汇总）
2.17订单执行情况汇总（明细）
2.18成品库某段时间内的出入库明细
2.19某段时间内的分车型出库汇总
2.20移库通知单执行情况查询
2.21查询指定产品的出入明细
2.22成品库查询未提车订单
2.23分类查询产品库存情况
2.24当前生产线库存情况查询
2.25装配情况（或库存）表
2.26工序状态监控
2.27车间领料明细查询
2.28二厂产品发货情况表
2.29底盘流向表
2.30在制品统计表
2.31底盘或牵引车分类情况
2.32物料清单查询
2.33库存资金超过一定金额的物资
2.34积压物资清单
2.35供应商与供货物料档案
2.36查询供货比例
2.37查询低于最低限量、高于最高限量的物料
2.38供应商供货情况一览表（加一栏：库存数）
2.39生产日报表
2.40查询各车间下线、入库车辆
2.41超过交货期的入库车辆明细（汇总）
2.42查询需签字订单
2.43未完成订单
2.44查询订单_未提车
2.45锁具数量大于0的出库单
2.46查询_新产品
2.47查询零部件数量及责任单位
2.48查询车辆档案
2.49一分厂车桥赔偿统计表
2.50二分厂赔偿统计表
2.51分类统计表
2.52赔偿主要零部件数量及责任单位
2.53外部质量索赔单
3接口
3.1与PDM的接口 2005-3-2 17:35:26
八、评审项目A验收大纲 列举一个片断，说明评审思路： 1.1销售部门
1.1.1销售人员
1.1.1.1订单
1.1.2销售经理
1.1.2.1订单
1.1.3发货人员
1.1.3.1发货通知单
1.1.3.2退货通知单
1.1.3.3移库通知单
1.1.3.4移库返回通知单
1.1.3.5自带底盘改装合同 这个清单是否完整地描述了用户需求呢？尽管客户已经签字确认，但这并不能保证其正确性。我们从头分析一下： 1.物流节点 这部分业务涉及到三类物流节点：企业、代理商、用户。 2.枚举物流 (1)移库：企业-〉代理商
(2)移库返回：代理商-〉企业
(3)发货：企业-〉用户
(4)退货：用户-〉企业
(5)代理商发货：代理商-〉用户
(6)退货给代理商：用户-〉代理商 根据需求调研，代理商库存的产权属于企业，但代理商自己的用户信息对企业是保密的，(5)中的业务过程可认为企业把产品卖给了代理商。(6)中的情况可以忽略。 因此，销售过程应该有5个主要的业务过程。这五个主要的业务过程涉及到的业务单据： (1)移库：订单，移库通知单
(2)移库返回：移库返回通知单
(3)销售：订单，发货通知单
(4)退货：退货通知单
(5)代理商发货：订单，发货通知单 统计一下，共有如下几种单据：
(1)订单
(2)移库通知单
(3)移库返回通知单
(4)发货通知单
(5)退货通知单 对照一下，发现验收大纲关于业务单据的描述是正确的。 3.业务单据的状态和用例清单 根据需求调研，每种单据都是要有一定的审批过程的。例如订单要经过销售人员、销售部门经理、财务审核、技术审核才能生效。可以断定订单的基本状态有：
(1)编制
(2)签发
(3)销售审核
(4)财务审核
(5)技术审核
(6)中止
(7)包退期
(8)保修期
(9)完成 至少有上述7种状态。状态之间的转移可以导出基本业务用例：
1-1:编制订单
1-2:签发订单
2-3:销售部门经理审核
3-6:中止订单
3-4:财务审核
4-3:撤销财务审核
4-5:技术审核
5-4:撤销技术审核
5-7:完成全部产品的发货
7-8:进入保修期
8-9:订单生命周期结束 全部的状态转移可能有9*8=72个，我们考虑其中的11个。如果本系统不考虑保修期问题，可以只考虑前9个用例即可。
2005-3-3 12:03:35
九、验收大纲总结 验收大纲终于结题。总结一下心得： 1.毕竟这是一份纲领性文件，不必求全责备。 2.应该划出系统的主要工作流程、系统物流、资金流等能反映企业管理宏观状况的示意图，作为大纲的编制依据。 3.这份文件的最后应该落实到系统用例。 4.验收大纲的编写应该是建设性的，不要拘泥于客户的需求。项目C的验收大纲受到质疑后，我们走访了客户。结果表明，客户因缺乏信息化经验，错误地提出了需求。听了我们的评审意见后，人家还感动得要命。 5.可有可无的内容不要写到验收大纲，这会增加验收难度。例如：一些基础编码类的内容等用户不关心的内容一概删除，没有必要参与验收。（这不是偷工减料，只是建议不要让客户对这些内容验收。） 我会把正式版本的验收大纲发布到“企业信息化”栏目，感兴趣的弟兄可以去查阅。 下一个目标是项目开发计划的评审。 2005-3-4 16:56:59
九、勾画系统骨架：确定初始阶段的内容 俺确定了一个原则来决定哪些业务用例可以出现在初始阶段：最小化原则：次要用例必须去掉。例如：签订订单是主要用例，而中止订单就是次要用例。 对于A项目而言，其业务用例繁多，按把关键用例画成一幅示意图： ┏━━━━━━━━━━━━━━━━━━━━━━┓┏━━━━━━━━━━━┓
┃ 订单 ┃┃ 中长期经营计划 ┃
┗━━━━━━━━━━━━━━━━━━━━━━┛┗━━━━━━━━━━━┛
│ ↓ ↓
│ ┏━━━━━━━━━━━━━━┓┏━━━━━━━━━━━┓
│ ┃ 主生产计划 ┃┃ 安全库存量 ┃
│ ┗━━━━━━━━━━━━━━┛┗━━━━━━━━━━━┛
│ ↓ ↓
│ ┏━━━━━━━━━━━━━━┓┏━━━━━━━━━━━┓
│ ┃ 生产需求计划 ┃┃ 安全库存量计划 ┃
│ ┗━━━━━━━━━━━━━━┛┗━━━━━━━━━━━┛
│ ↓ ↓
│ ┏ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ┓
│ 净需求计划
│ ┗ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ┛
│ ↓ ↓
│ ┏━━━━━━━━━━━━━━┓┏━━━━━━━━━━━┓
│ ┃ 上线计划 ┃┃ 采购计划 ┃
│ ┗━━━━━━━━━━━━━━┛┗━━━━━━━━━━━┛
↓ ↓ ↓ ↓
┏━━━━━━┓┏━━━━━━┓┏━━━━━━┓ ┏━━━━━━┓
┃发货通知单 ┃┃工序工料计划┃┃工序作业计划┃ ┃采购作业计划┃
┗━━━━━━┛┗━━━━━━┛┗━━━━━━┛ ┗━━━━━━┛
↓ ↓ ↓
┏ ━ ━ ━ ━ ━ ━ ━┓ ┏ ━ ━ ━ ━ ━ ┓
出库通知 入库通知
┗ ━ ━ ━ ━ ━ ━ ━┛ ┗ ━ ━ ━ ━ ━ ┛
↓ ↓
┏━━━━━━━━━━━━━━┓ ┏━━━━━━━━━━━┓
┃ 出库单 ┃ ┃ 入库单 ┃
┗━━━━━━━━━━━━━━┛ ┗━━━━━━━━━━━┛ 注意，上面的虚线框表示系统内部数据。 可以看出其中的关键业务用例并不多。初始阶段确定的用例请参看“企业信息化”栏目提供的文档：  http://community.csdn.net/Expert/topic/3818/3818026.xml?temp=.7012445
#050304004 002-A项目开发计划(V1.0)
对于B项目，俺只考虑了几个关键业务用例： 总公司发货给办事处
办事处把货卖掉
办事处收到货款
办事处把货款还给总公司
办事处报销费用 具备如上用例的系统可以正确演示系统功能，开发工作量和风险都比较小。参见： http://community.csdn.net/Expert/topic/3823/3823183.xml?temp=.3089868
#B050304002 002-Ｂ项目开发计划
2005-3-7 18:19:19
十、从用例导出分析模型 从用例导出分析模的关键部分是确认系统对象，以及确定系统对象之间的关系。 分析模型文档我们采用数据库结构图表示。这样做的好处是：(1)关系型数据库结构能够很好地表达实体关系；(2)开发人员熟悉数据库结构的设计；(3)数据库结构本身是形式化定义的（符合SQL规范），不会产生歧义。俺觉得在开发团队未能有效培训的情况下，采用数据库模型代替分析模型是非常有效地。现阶段采用UML或其他不熟悉的任何标准，都是低效率的。 评审发现的主要问题： 1.数据库技术问题： (1)许多人不喜欢在表之间建立必要的外键关联，这次评审要求凡是有必要的，必须到位。 (2)所有的表必须有主键（或者唯一性索引），不然的话这样的表无法更新或者删除记录。 (3)发现不少表之间的关系搞颠倒，例如多对一关系给设计成了一对多关系。错误很明显，但设计人自己却发现不了。 (4)还有人喜欢用汉语拼音缩写做表名和字段名，俺晕，责令改成英语单词或者汉语拼音全称或者直接用汉字。 (5)许多人对允许为空的字段不以为然，这贻害无穷，会给你带来无数BUG。除非绝对必要（例如某些外键字段有时必须允许为空），字段不允许为空。 (6)数据类型不合理，例如把“重量”类型设成字符串。 以上发现的问题主要是对关系型数据库原理缺乏理解，其实看看关系型数据库设计范式就可以避免许多愚蠢的问题。 2.系统分析问题： (1)对抽象类的概念的错误理解:有人以为如果有一种单据可以替代出库单、入库单、借款单、付款单等等，这各类就是抽象类。于是就出现一个名为“单据”的表，包含了上述单据所有字段的集合。因此，本来应该有十几个标的数据库，一下子都“抽象”成了一个表。 这是对抽象的误解。抽象类包含的属性是所有子类属性的交集，而不是并集。因此，抽象的最大特征是属性和方法都它的任何子类都少。 例如，在项目B中，我们确定的单据系统的表，结构示意图如下： ┏━━━━━━━━━━━━━┓ ┏━━━━━━┓
┃ 单据类型 ┃←┃审批流程定义┃
┗━━━━━━━━━━━━━┛ ┗━━━━━━┛
↑
┏━━━━━━━━━━━━━┓ ┏━━━━━━┓
┃ 单据 ┃←┃ 审批记录 ┃
┗━━━━━━━━━━━━━┛ ┗━━━━━━┛
↑ ↑
┏━━━━━┓ ┏━━━━┓
┃业务申请单┃ ┃原始凭证┃
┗━━━━━┛ ┗━━━━┛
↑┏━━━━┓ ↑┏━━━┓
├┃要款申请┃ ├┃出库单┃
│┗━━━━┛ │┗━━━┛
│┏━━━━┓ │┏━━━┓
├┃要货申请┃ ├┃入库单┃
│┗━━━━┛ │┗━━━┛
│┏━━━━┓ │┏━━━┓
└┃ 其它 ┃ └┃ 其它┃
┗━━━━┛ ┗━━━┛ 其中“单据”、“业务申请单”、“原始凭证”这三个表构成了抽象类型，这种设计可以让具体的业务单据共享一大部分关键算法。 (2)使用的开发技术不均衡 在项目A的分析模型中，引入了Petri模型处理系统状态。对于一个定制开发的系统来讲，代价太高，采用更简单的模型取代。 在项目B的分析模型中，有些数据（如部门等）被设计成可动态定制的多层次树形结构的形式，同理简化这一部分的设计。 (3)过分崇拜客户需求调研的原始资料，不敢大胆提出自己的新的见解 有些业务过程现在客户自己也是很模糊，原因是人工能力有限。既然用计算机来管理，许多人工作不到的事情现在应该能做到了。因此，系统设计人员必须跳出手工作业的框框，大胆改进企业业务过程。 (4)懒惰思想，希望有些事情推后一些 有些需求明显没有充分调研，系统分析人员视而不见，希望到最后在处理自己不了解的问题。这会带来灾难性后果。 因此，分析期间，必须通过建立内容完整的分析模型和业务模型，发现需求调研的缺失。 2005-3-8 19:48:48 十一、用例和系统设计的关系 评审项目A设计方案，感觉设计方案相当复杂。直觉告诉俺，这个方案实行起来问题更复杂。因此，必须认真剖析一下原因。 平心而论，A项目称得上一个大型项目。如果一个开发组能顺利拿下这个项目，我想这也算他们软件生涯中一件值得炫耀的事情。但是，确保这个项目开发成功的唯一出路在于，时刻都能感觉到自己在牢牢把握它的方向。 A系统的设计方案陷入一种误区，我想许多缺乏经验的项目组都会这么干——认为用户对界面的操作就是用例。如果这样理解的话，用例系统就太庞大、太复杂了——因为每次点击鼠标都有可能导致一个用例。 应该换隔角度来理解系统设计：用例描述一项完整的业务，例如产生一个合格的订单，这包括订单的起草、各种审核、最后确认无疑后转发到其他部门。 那么用户界面在系统中扮演什么角色呢？答案是，界面负责把用户的一些列操作转化成一个业务用例，然后调用系统的“业务内核”实现用例。参见下面示意图： ┏━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ 用户界面 ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━┛
↓ ↓
┏━━━━━━━━━━━━━┓┏━━━━━━━━━┓
┃业务内核：专门处理业务用例┃┃用户界面支持子系统┃
┗━━━━━━━━━━━━━┛┗━━━━━━━━━┛
↓ ↓
┏━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ 数据库系统 ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━┛ 我们最后讨论了一下，计划通过一个大致和下面差不多的一组类实现系统内核的功能。这组类结构简单，容易把握。顺利实现如下算法，按觉得基本上能有６０％的把握确保系统开发实施成功。至于界面设计，都是些和大局关系不大的东西，可以给程序员较大的自由度去发挥。 namespace ERP
{
public class Sale
{
public static void PublishOrder();
public static void PublishShipNote();
} public class Plan
{
public static void PublishMainPlan();
public static void PublishMainRequire(); public static void PublishSafePlan();
public static void PublishSafeRequire(); public static void CreateNetRequire();
} public class Job
{
public static void PublishLinePlan();
public static void PublishLineJob();
public static void PublishPurchasePlan();
public static void PublishPurchaseJob();
} public class Mater
{
public static void PublishMaterFlow();
}
} 注意，上面的一组类和业务用例几乎一对一的关系。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 结论： 用户界面的职责：把用户操作解释成业务用例
业务内核的职责：负责完成业务用例 即：用户界面 ==> 业务用例 ==> 业务内核 系统的成败以业务内核的实现，只要业务内核的核心算法顺利完成，不愁系统顺利完成。目前为止，我们相信已经找到一种简单划的业务内核设计方案，朝着正确的目标走了一小步。
2005-03-18 12:14:00 2005-3-18 项目评审
A项目：要求实现核心业务逻辑算法。
1 因为要求比较明确，设计没有发现特别的问题，只是有错误的算法需要重新调试。
2 需要调试完毕后，继续验证源代码。
B项目：要求实现７个基本用例，目前首先评审界面操作设计
界面设计有如下问题：
1 物料定义：产品的分类应该放入到左面的资源结构数中去，不应该在右面的数据区开辟一块补丁存放分类树。影响美观，也不符合简单性的要求。
2 对单据明细的操作太复杂：
2.1 现在的操作是先点击增加产品，然后在单据上方出现一个新的明细编辑区，录入明细，在点击编辑区的增加按钮，编辑区关闭，新产品添加到明细。
2.2 建议单击增加产品后，会自动添加空白的单据明细，然后编辑该明细。
3 操作按钮和数据区混合排列，不容易操作。建议把单据的数据区独立出来，让用户能看到和真实单据类似的界面，相关操作按钮集中排放（例如工具条的形式）。
4 控件的显示样式被改头换面，操作人员不知如何下手。例如：
4.1 超级链接和普通文字没有区别。
4.2 文本编辑框变成了带下划线的标签样式。
4.3 解决方案：责令所有的控件都采用默认的形式，不允许别出心裁搞新的样式。
5 控件被不合适地运用
5.1 用编辑框表示不可更改的文本内容，界面又没有明显的禁止编辑的特征。甚至操作员可以修改其内容，但又无法将修改存入数据库。
5.2 用下拉框表示静态文本，仅仅是因为编程比较简单。
5.3 有一个下拉框竟然有两个下拉按钮，操作人员点击两次才能拉出内容。原因也仅仅是为了编程方便。
6 采用推模式创建新单据
6.1 计划管理人员在审批完要货申请单据后，点击“执行”按钮，自动生成了一份入库单。这会让仓库保管员感觉很不舒服的。
6.2 正确方法是：仓库保管员在实际入库式创建空白入库单，然后通过导入操作，把要货申请单数据可选择地导入空白入库单，最后根据实际入库物料和数量编辑入库单。
7 不能有效地利用数据库约束数据的正确性
7.1 当删除一个部门编码时，系统提示“不正确地删除会造成很严重的后果，你确定要删除吗？”
7.2 上面的做法让用户无所适从，操作人员不可能知道会有什么严重后果。
7.3 正确方法是：引用部门编码的数据表建立外键（禁止级联更新和级联删除），如果被删除的编码被引用，数据库会拒绝；如果被删除的数据从未被引用过，删除就可以完成。
8 认为公司提出的评审意见过分严格，主张让用户评审，只要用户没意见，公司不必故意过意不去。答复如下：
8.1 在开发阶段，用户会为所有看不懂的东东签字确认，他们只知道最后不满意就不付款。让用户评审只能使得项目风险延期暴露，不会出促成项目顺利验收。专业人员可以通过图纸看出大楼的缺陷，用户则需要住进去后才能发现问题。靠专业人员还是靠用户评审，哪个更合理是明摆着的事情。
8.2 被动听客户提意见会让你更被动，客户一旦发现你的设计常常不符合他的要求，它就越喜欢找你的小毛病，而且仅仅抓住不放。如果用户发现你能把一切都与腺体他考虑好，你就会越来越主动，即使有小毛病客户也会谅解。因此，绝不允许养成等客户发现问题的坏习惯。
8.3 公司必须提供较高的设计标准，才有可能让每个工程都成为样板工程，公司才能呈良性发展。否则，做的项目越多，声誉就会越差，最后自掘坟墓。 体会
项目过程控制需要进一步严格化，有可能失控的地方必然失控。
|
项目型组织
项目管理
工程项目
科技项目
资格认证
职业休闲
