EOS应用开发过程参考手册
? 形成一致的需求调研工作思路和需求规格编写方法 ? 形成需求调研的问题清单和与用户进行需求沟通的基础文档 通过该项工作，将使得接下来的需求调研工作有的放矢、事半功倍。 进行需求调研 需求调研人员 必须 需求调研人员在用户确认后进入到调研现场，由项目经理负责组织与用户的需求调研工作。一般配合需求调研工作的用户还有其他的业务工作，需求沟通的时间安排往往比较紧凑，沟通通常以会议的方式进行。每次沟通之前要确定一个主题（不可能一次会议能把所有的需求都讨论完），会议过程要做好记录，会议结束时要进行简单的总结，尤其将一些结论性意见进行归纳并得到用户的口头确认，同时确定某些遗留工作和后续的工作安排。会议结束后按照统一的格式整理会议纪要，发送给与会相关人员，以及得到用户方负责人的确认（最好能够签字认可）。 需求调研的内容包括功能范围、功能的业务规则和实现要求、业务处理流程、交互数据内容的数据类型、与其他系统的接口、接口方式、接口数据项和格式要求，以及系统实现上的技术要求等等…… 编写需求规格 需求调研人员 必须 在进行完一次需求调研的沟通会议后，应该及时进行消化，并以文档的形式沉淀到需求规格说明书中，同时将需求沟通中未涉及或未明确的问题再次整理到问题清单中，通过电话、邮件、或会议方式让用户进行澄清。 编写需求规格的过程实际上就是需求分析的过程，需要针对用户的原始需求进行一定的业务抽象和需求点归类，以便切分和分解形成不同层次的需求点。需求规格包括了应用系统的功能需求、非功能性的需求，以及需求调研形成的数据字典和公共词汇。功能需求一般要描述出系统用户的操作和系统的响应，以及业务规则、业务流程。 以上两个工作在需求调研的过程中是迭代进行的，直到项目组认为需求基本明确，或者主要需求明确，能够进行后续的工作。 进行需求评审 需求调研人员、用户 必须 需求调研组认为应用的需求范围和需求内容基本确定，而且需求规格基本形成后，项目经理应该组织用户对需求进行评审，评审可选择会议评审或者需求走查。 需求评审后对于有误的内容要进行更正或者重新调研的工作，对于目前无法确定的问题要形成遗留问题列示在附件中，并确定大致的处理时间计划。 最终审核通过的需求规格说明书需要获得用户的签字认可（可提供一份需求认可书进行签字）。 建立项目管理方案 项目经理 可选 建立操作性强的项目管理方案是保障项目有序进行的重要工具，也是协调项目相关组织、人员关系的重要依据。也有助于新进入项目的成员尽快进入工作角色。项目管理方案包括但不仅限于以下内容： ? 项目的组织结构和分工界面：有助于明确相关组织、角色、人员的工作职责 ? 项目的内外部协调机制：例如例会机制，沟通机制、工作周报等 ? 项目的争议机制：当项目组与用户方发生争议（例如需求不明确导致的争议、实http://www.primeton.com/
第16页共44页
EOS应用开发过程参考手册
现方式争议等）时的解决机制 ? 需求变更的流程 ? 项目风险方案：列出项目实施可能存在的风险以及规避措施等 ? 项目团队人员名单及联系方式 制定项目实施和管理的模板 项目经理，开发经理 必须 项目文档是项目团队沟通的载体，而良好的模板方便项目成员的编写，也有助于阅读人员的理解。项目模板包括项目实施的过程文档模板和项目管理的模板，包括但不仅限于以下内容： 项目实施过程模板： 《项目需求规格说明书》 《项目系统设计说明书》 《系统测试方案和测试案例》 《系统测试报告》 《应用系统用户使用手册》 《应用系统维护手册》 项目管理模板 《项目工作周报》 《会议纪要》 《项目评审报告》 《项目验收报告》 不一定所有模板都要在本阶段完全确定，也可以考虑本阶段暂时确定当前迫切需要的模板。
4.1.4. 输出内容
? ? ? ? ?
《需求调研的会议纪要》 《项目需求规格说明书》 《项目实施总体计划》 《项目管理方案》 《需求变更控制表》
4.1.5. 阶段控制点
由于该阶段是项目的启动阶段，项目团队刚刚建立尚不完整，对于客户而言，非常关注项目的进度计划，对于项目组所在公司而言，在关注项目进度的同时，也关心项目的需求范围。对于项目经理而言，本阶段的主要控制点在于：
? 需求范围的控制：因为在与用户进行需求调研的基础一般是项目的合同文本，往往
合同对项目的功能范围只是做了粗略的描述，这些内容需要通过调研工作进行细化和明确，功能细化的程度往往对工作量的影响很大，在调研中需要掌握需求的主次，避免对非重要功能的需求过度复杂化（要知道一个功能做到不同程度，付出的工作
http://www.primeton.com/
第17页共44页
EOS应用开发过程参考手册
量的差异是很大的），同时思考某个功能点的需求可能带来的工作量和付出这种工作量对项目整体而言是否值得（这就是让系统架构师和开发经理参与需求调研的重要意义）。要明白，在用户理解付出代价的情况下合理有效的需求控制一定会得到用户的支持。
? 项目资源的协调：在本阶段，将会确定项目实施的总体计划，保证计划能得以正常
执行的前提是有效的资源保障。资源的稀缺性是项目的重要特征，项目经理要和公司充分沟通资源的安排和投入时间，以保证项目按照计划正常实施。
4.1.6. 退出条件
? 《项目需求规格说明书》获得用户签字认可。
? 项目组所明确的用户需求基本完备，能够进入到设计阶段。
4.1.7. 参考模板
? ? ? ? ? ?
《项目需求规格说明书》 《需求调研会议纪要》 《项目工作周报》 《项目管理方案》 《需求变更方案》 《需求变更控制表》
4.2. 设计阶段 4.2.1. 概述
设计阶段是应用项目实施的重要阶段，它是将用户需求转发为应用系统技术实现的重要环节。设计的过程，是将用户需求涉及的功能、数据、流程等业务的信息，运用业务和技术的眼光进行抽象，映射成技术实现内容的过程，一方面，经过抽象后系统横向切分为不同的应用系统功能，从而保证这些功能即能够覆盖用户的业务功能需求，又能体现业务模型的可扩展能力和低耦合度，另一方面，经过抽象后的系统从纵向切分为不同的层次，有利于实现时的分工合作，同时降低技术层次的耦合性，利于技术层面的扩展。下图表现了一个系统经过设计后用户和实现人员的不同视角
http://www.primeton.com/ 第18页共44页
EOS应用开发过程参考手册
这样我们就很容易理解，当我们选择J2EE实现用户的应用系统时，对于设计工作，一方面要从技术层面设计一个应用架构来实现应用软件的层次封装，在开源领域，目前有很多种应用架构的成果，但往往只是解决了应用框架中一部分的问题，需要组合或者自行设计完整的应用框架结构，例如，可能选择Hibernate+Struts+Spring经过整合后的框架作为应用的框架，或者采用项目组自行封装的应用框架实现。另一方面要针对用户的需求进行业务的建模和抽象，形成系统对应与数据库的数据对象模型和java的对象模型。在采用EOS实现J2EE应用时，由于EOS已经提供了一套完整的应用软件框架，使得在设计阶段无需考虑应用架构的问题，同时也不用考虑业务模型与java对象抽象的工作。这也是EOS应用开发与传统J2EE应用开发在设计阶段工作方面最大的差别。 对于EOS应用的设计内容，主要的重心在于业务模型的抽象（可理解为业务架构）、构件包的划分以及功能点的细分，这样让设计人员能够从考虑技术架构和OO模型的稳定、优雅和是否符合力学原理的泥沼中解脱出来，将主要的精力花费在考虑业务模型的抽象和扩展能力上（也有助于设计人员从技术思维转向业务思维，或许我这种说法对于热衷于技术研究的设计师会不以为然，但如果设计师跟用户沟通时如果屡屡提及对象、设计模式等词眼未必能让用户对于系统的设计思路有多清晰的理解）。 所以，对于EOS应用的设计，应多多考虑的具体工作包括：数据库的设计、用户的界面表现和整体风格、功能的切分、功能（页面）的流转方式、应用处理的流程或规则、系统权限的控制、与外部系统的接口等等，分解成本阶段的工作步骤如下图所示：
http://www.primeton.com/ 第19页共44页
EOS应用开发过程参考手册
设计阶段项目实施工作项目管理工作制定项目阶段计划系统总体设计技术课题攻关制定项目开发规范页面框架设计数据库设计（业务建模）制定和实施项目配置管理方案系统功能分解功能设计任务分配页面原型设计评审不通过开发环境准备应用功能设计组织设计评审 在上图中，描述了设计阶段的各项工作以及工作之间的大致关系，在设计阶段，首先需要进行系统的总体设计，形成系统的总体结构和总体要求，通过此工作，可以从系统全局的高度分解出系统设计的各项具体工作内容，例如，存在哪些技术点的风险需要进行技术课题的攻关或预研，项目规范内容的总体要求，数据库设计前的业务对象模型（概念模型），应用的页面框架和美工设计要求等，通过总体设计工作，可以形成几条并行工作线，其中，制定项目开发规范将与数据库设计、页面框架设计、原型设计、功能设计等各个工作相互影响，一方面，项目开发规范的内容形成对这些工作的约束，另一方面，这些工作进行的过程中，某些约定或者要求会补充到项目开发规范中。有关各个步骤的具体内容和要求将在工作任务章节进行详细描述。 在本阶段中，以总体设计、数据库设计、页面框架设计、原型设计、功能设计为主线，其他工作内容作为对主线的辅助，保证设计的质量、或者对设计进行验证等等。需要说明的是，尽管列出了上述的很多工作项，在实际操作中，并不是每个工作项有人专职去做，而是根据项目组人员的具体情况，一人可能同时承担多项工作，并行处理。
http://www.primeton.com/
第20页共44页