细化迭代1_搭建框架

系统核心架构

项目设想

系统展望：

在餐饮界内中，过去拼价格、拼菜品、比档次、比服务等竞争手段已不稀奇。在现今网络经济时代，许多餐饮企业逐渐依靠灵敏的电子信息工具，不断提高市场应变能力。餐饮企业需要使用pos管理系统来适应当今高节奏的生活方式，为管理一体化提供技术手段，这是今后餐饮管理软件信息化的一个重要标志。也可以为顾客，服务人员，管理者，收费人员等提供方便，如：预订、接待、点菜、菜品上传、厨房分单打印、条码划菜、收银、经理查询等方面；提高为顾客服务质量、缓解餐厅拥挤的状况、提高厨房部的供餐服务质量、也提高了服务人员的效率和质量。

主要应用如下：

1)顾客点餐，系统根据食物的价格和数量提供订单并生成单据供结算费用；

2)厨房根据顾客的订单，准备所需食物。

3)服务人员根据顾客的订单，适时提供相应食物。

4)顾户和收银员确认订单无误，结账并打印小票。

5）常客可升级为会员，给予优惠折扣和高质服务等。

6）经理可以随时查看业务，作出好的管理决策。

本套系统适应所有酒吧、茶餐厅、夜总会、咖啡厅、会所、娱乐城、火锅店、酒楼、酒店 、宾馆、中餐、西餐、快餐、排档等各种餐饮业用户。

系统特性：

1）餐馆内部信息化： 点菜员只要输入菜品编码或拼音字头简码，就能在手持POS机里迅速调出菜品数据，系统自动识别后在厨房打印机分单打印出来，厨师根据菜单很快就能了解到顾客的需要。

2）及时反映需求： 餐馆的老板可以通过电子化系统查询营业收入统计、员工业绩统计、人均消费额、翻台率等；此外，还可以用图形或者表格的形式进行各种数据分析，例如财务状况分析、营销决策分析、营业收入分析等

3）数字化精确管理：如一个炒菜需要用多少料、装成多大一盘、用多少时间做出来、成本和利润是多少，全是模糊的概念。然而当这些都数字化之后，一切就变得比较明晰了。

4）形象得到提升：顾客来到高端大气上档次的酒楼，会觉得管理，服务，待遇等都不一样，会提升酒楼的知名度等，吸引更多的客源。

更加有如下功能：
（1）管理桌账功能
（3）自动分类打折功能
（4）服务员功能
（5）转账功能

（6）分账功能

（7）厨房打印机
8）票据打印机

（9）结账受理各种银行卡、会员卡，现金支付
(10)为商户开通网上订餐功能

开发计划

A. 团队成员：

项目经理（杨剑达）：
计划、组织、领导、控制整个项目，也负责监督整个项目的实施，把握整个项目的进度，对项目实施过程中出现的问题进行处理。
分析员（黄培鑫）：代表整个项目组，同时也可以代表客户方的意见，项目组内所有与客户需求相关的事情必需得到他的认可。对项目做出正确的需求分析，同时也是是项目组中的首席执行官，涉及项目的所有方面，推动项目进度。
架构师（凌鸿）： 软件架构师负责理解和管理非功能性系统需求，比如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等。审查客户和市场人员所提出的需求，确认开发团队所提出的设计；组织开发团队成员和开发过程的定义；协助分析师。
测试员（巴怀桔）：1.独立编写测试计划；独立编写测试用例；协调测试团队内部的工作以及与开发团队之间的工作；.完成“执行测试”的工作；.掌握较深层次的测试方法、测试技术和较复杂的业务流程；负责测试过程工具的研究、推广与维护，负责测试数据库维护工作。

B. 项目进度：

过程

时间

目标

工作内容

工作成果

初始

阶段

1-2周

分组定题

布置任务，确定分组；

确定题目，制定计划。

提交MIS课程设计任务书

提交分组计划确定计划，架构师设定架构。

细化迭代1

3-4周

搭建框架

确定核心架构

实现基础数据增删改查

程序员完成代码阶段，实现功能测试员文档以及成品递交编写文档1.1, 1.2, 3.2

C. 风险控制：

存在风险：

1，不胜任的项目经理，担任项目经理职位的人不具备领导和管理项目的背景、技能、经验和个人品质。

2.项目需求在不断的发生变化，项目的雏形不符合，导致小组分工出现不能很好对接的现象。

3.项目中没有良好的沟通，这些问题的产生是由于信息的不对称、准确性，或者时间性的缺乏，以及粗略的数据收集和记录，或者未能将信息分配给那些需要信息的人。

控制措施：

（a）项目经理要面对矛盾，反省自己。勇于提出深层的、探索性的问题，为了项目的最大利益而进行有效的辩论。
（b）整个小组要不断地改变程序，是的软件可以适应需求的变化，增加系统的糅合性。
（c）项目经理要及时注意到项目的人力、行为方面。他建立一个项目团队，帮助团队成员理解项目目标，要不断激励项目团队成员朝着目标一起工作。

软件架构设计

A. 软件分层。
省
B. 命名规范。
本规范的条目分为两个级别:
规则 - R
建议 - S
S-最好为名词
R-命名类和接口时，需要将所有单词的首字母大写。
R-接口的命名不采用首字母为 I 或加上 IF 后缀的命名方式 。例 如 ：IBookDao 、 BookDaoIF 等 。
R-抽象类必须使用 Abstract 作为类名的前缀，而接口建议使用 Interface 作为 接口名后缀。
R-异常类应该使用 Exception 做为 名称 后缀。
R-如果是运行一次就抛弃的类，以 ing 结尾，比如Rendering
R-类名尽量短，但是最好不要缩写，如果缩写，必须为特别常用的类，比如 org.nutz.dao.Cnd
因为调用者书写你的类名太长，他(她)的IDE会自动替他(她)换行，他会觉得有点不爽
R-不要和 Java 的标准库中的类名冲突，比如 Class, Object, String 等
如果冲突，就表示你极其藐视 Java 标准库中的那个的设计
调用者需要花更多的时间和代码来明确他使用的是你的类, 而不是标准库中的那个
S-以下情况可以允许写奇怪类名 – 名称简短，让人一眼不知道什么意思，用了以后一眼就能知道什么意思
类特别常用
类非常特殊，难以归类
私有类或内部类
不推荐其他人调用的 公有、保护、默认类
起个奇怪的名字，就是不想让你关心这个类的代码
R-缺省接口实现应该使用 Default 名称 前缀 。例 如 ： DefaultEntityMaker。
也可以采用 Impl 作为后缀，表示这个实现为此接口的最优实现或者唯一实现

C.架构相关设计模式。
DAO模式和MVC模式