项目管理案例：软件开发项目需求分析与功能实现

软件项目管理案例：A公司是一家美资软件公司在华办事机构，其主要的目标是开拓中国市场、服务中国客户，做一些本地化和客户化的工作。它的主要软件产品是由总部在硅谷的软件开发基地完成，然后由世界各地的分公司或办事机构进行客户化定制、二次开发和系统维护。这些工作除了日常销售和系统核心维护之外，都是外包给本地的软件公司来做。东方公司是A公司在中国的合作伙伴，主要负责软件的本地化和测试工作。

Bob先生是A公司中国地区的负责人，Henry则是刚刚加入A公司的负责此外包项目的项目经理。东方公司是由William负责开发和管理工作，William本身是技术人员，并没有项目管理的经验。
当Henry接手这项工作后，发现东方公司的项目开发成本非常高，每人每天130美金，但客户的满意度较差，并且每次开发进度都要拖后，交付使用的版本也不尽如人意。而且，东方公司和A公司硅谷开发总部缺乏必要的沟通 只能把问题反馈给Henry，由Henry再反馈给总部。但由于Henry本身并不熟悉这个软件的开发工作，也造成了很多不必要的麻烦。

为此，Bob希望Henry和William用项目管理的方法对该项目进行管理和改进。随后，Henry和William召开了一系列的会议 提出了新的做法。
首先，他们制定了详细的项目计划和进度计划;其次，成立了单独的测试小组，将软件的开发和测试分开;并且，在硅谷和东方公司之间建立了一个新的沟通渠道，一些软件问题可以与总部直接沟通;同时，还采用了里程碑管理。

六个月后，软件交付使用。但是客户对这个版本还是不满意，认为还有很多问题。为什么运用了项目管理的方法，这个项目还是没有得到改善?
Henry和William又进行了反复探讨，发现主要有三个方面问题：1、软件本地化产生的问题并不多，但A公司提供的底层软件本身存在一些问题;2、软件的界面也存在一些问题，这是由于测试的项目不够详细引起的;3、开发的周期还是太短，没有时间完成一些项目的调试，所以新版本还是有许多的问题。

此时，Henry向Bob提出是否采用公开招标的方式，选择新的、实力更强的合作伙伴。但Bob认为，与东方公司合作时间已经很长了，如果选择新的伙伴又需要较长的适应期，而且成本可能会更高。于是，Henry向东方公司提出一些新的管理建议。首先，他们采用大量的历史数据进行分析，制定出更详细的进度计划;其次，要求东方公司提供详细的开发文档和测试文档 做的工作没有任何文档，给其他工作带来了很多困难);第三，重新审核开发周期，对里程碑进行细化。
又过了六个月，新的版本完成了。这一次，客户对它的评价比前两个版本高得多，基本上达到项目运行的要求。但客户还是对项目进度提出了疑问，认为实时推出换代产品不需要那么长的时间。
较常见的做法。在软件外包工程中，保证质量的进度是很难控制的。对于项目经理来说需要一整套复杂的能力，比如制定计划、确定优先顺序、干系人的沟通、评价等，每一种能力都与项目的最终结果有直接或者间接的关系。

然而，国内的项目经理大多没有接受过正规训练，缺乏项目管理方面的专业知识的技巧，往往只是凭借以前的少量经验盲目去做，容易出现各种问题。尤其是在管理外包项目时，缺乏足够的经验和技巧，往往造成进度不断推迟，而质量无法保证的情况。
在这个案例中，我们可以看到现在IT业内许多外包项目的影子。
在该案例中，东方公司没有专门的项目经理，是由技术人员William兼做管理。这是国内软件公司经常会出现的问题。最初，出现进度落后的问题时，A公司的Henry与东方公司的William讨论后决定采用项目管理中计划管理等手段，其中包括里程碑管理。这是控制进度的较常见做法。
里程碑管理的引入。

一般来说，在项目开始时，项目组成员都会对项目制定一个详细的计划。通常情况下，在明确的工作说明书(SOW)和WBS的基础上制定具体的进度计划时，需要采用一些具体的技术。像这种软件外包项目，最成熟的技术是里程碑管理。
里程碑一般是项目中完成阶段性工作的标志。不同类型的项目，里程碑也不同。比如，在开发项目中，可以将需求的最终确认、产品移交等关键任务作为项目的里程碑。本案例中，Henry在接手项目后采用里程碑进行管理是很恰当的。
不过，要注意的是，每到一个里程碑处，应及时对前段工作进行小结，并对后续工作进行计划调整。对于一些管理效果明显的领域，可以不必投入较多精力。而对于下一步管理过程中可能会出现问题的领域，应给予较多的关注。当然，在软件项目里，进度的变化是较常见的事情。
在本案例中，采用里程碑管理后仍没有达到客户的要求，进度依然拖后。在这里，就需要考虑另一个因素-质量与进度的关系。

通常，项目管理的前提是保证在预算内、满足质量的前提下，按进度完成项目。因此，可以看到，保证质量是前提。那么，如何在满足质量的前提下管理进度呢?单纯从项目管理理论知识中并没有一种有效的方式。具体步骤为：
首先，尽量利用历史数据。在本案例中，Henry应该调查之前的项目情况，将会发现可以类比的情况，事先就可以知道需要管理质量和进度的关系。
其次，由于此项目是软件外包项目，Henry不能完全掌握项目的资源 调度情况，因此缺乏对质量的控制。这也是大多数外包工程中最令人难以掌握的地方。在这里，可以采用对进度管理计划添加质量参数的方法，也就是通过参数调整进度和质量的关系。

这一做法的前提是要有一定的历史数据。比如，从历史数据中得知，完成子项目的时间是5天，测试后有15个问题;完成同样子项目的时间是7天，测试后有10个问题;完成同样子项目的时间是8天，测试后有5个问题，……以此类推。

随着数据的不断增多的，采用两维坐标图，就会得到一些离散的点(不考虑资源的差异)，并形成一条曲线。考虑项目允许的质量范围，对照图中的数据，找出相应的参数。根据得到的参数，确定一个合适的进度计划.

软件项目管理案例：一个软件项目的主要内容和实现的主要功能。

一个项目团队管理。您的项目团队使用源代码管理工具了吗？
应该被使用。 VSS，CVS，PVCS，ClearCase中，CCC /丰收，萤火虫即可。我的选择是VSS。
2。您使用的项目团队缺陷管理系统了吗？
应该被使用。的ClearQuest太复杂，我的建议是Bugzilla的。
3。你还在用Word来编写测试组的测试呢？
不写使用Word（测试用例）测试用例。应该是一个专门的系统，可以测试管理器，你也可以开发自己的小一个ASP.NET网站。其主要目的是追踪和浏览。
4。你的团队还没有建立一个门户网站？
有一个门户网站把联系方式，基线时间表，新闻和更多。推荐的SharePoint Portal Server 2003来实现15分钟就搞定了。可以买不起SPS 2003 WSS（在Windows SharePoint服务）。
5。您的项目团队，你可以买它的最佳工具？
应该尝试一起工作的好工具。例如，编写C＃应该用VS.NET而不是记事本。用记事本写程序大多只是表演。但也要考虑到经费，所以说是“最好的，你可以买到。”
6，你在一个安静的环境中工作的程序员？
需要一个安静的环境。这一点是非常重要的，而且要保证每个人的空间大于一定大小。
7。你的员工每个人都有手机吧？
需要一个电话的人。和语音信箱最好的手机。当然，对电话系统开销这么一套带留言不小。但每个人都至少有一个手机，人们往往不站起来喊：“某某某的电话。” “人的因素”，这将强烈谴责这种做法。
8。每个人都知道谁应该是出了问题？
应该知道。任何Feature至少都应该有一个Owner，当然，业主可以继续派遣到其他人。
9。你有没有曾经有人说，“我想......”什么？
要消灭“我以为”。永远不要假设任何事情。
10。在所有这些项目中的团队和你坐在一起？
需求。我反对虚拟团队，在美国也反对开发，测试这种开发方式在中国。能坐在一起就最好坐在一起，好处非常非常多。
11。你的日程安排是否反映最新开发进展情况？
应该反思。但是，如果基线的方法来管理进度：维持一个稳定的计划，然后保持近期的变化。基线也可用于参数的其它方法。基线是变更管理的重要手段里面。
12。你的工作量是留下了每个人自己估算？
应该让每个人自己估算。下来的工作量，以前的估计，而不是从上往下分派。除非有其他原因，比如政治任务工期固定。
13。你们开发人员从项目一开始会加班吗？
这样做。不要一开始就搞疲劳战。从项目加班一开始，只是项目进度不合理。当然，有些软件外包必须天天加班，那属于剥削的范畴。
14。你的项目计划缓冲时间将被添加到它的每个小任务后面？
没有。缓冲时间添加的每个小任务后面，很容易轻易食用。缓冲时间增加一个里程碑全部或检查点前方。
15。值得花一些时间，从95％至100％，以达到良好
值得，非常值得。尤其是当，当后者成为该项目用尽，要坚持。这将带来一个质的区别。
16。登记新缺陷，是否写清了重现步骤？
要。这属于Dev和测试之间的通信手段。面对面沟通需要，填补重现步骤需要。
17。写新代码前将已知缺陷解决？
要。每个人的缺陷不能超过10或15，否则旧的错误必须以继续写新代码来解决。
18。你必须优先考虑的缺陷事先约定呢？
必须有定义。严重程度分1，2，具有较好的一致性：蓝色和数据记不清西弗1，功能错误数西弗2，在界面西弗3指望然而，这项协议可以适当根据产品质量状况进行调整。
19。你不同意的三个会议的缺陷有吗？
必须具备的。有一个明确的决策过程。这类似于CCB（变更控制委员会）的概念。
20。所有的缺陷都关闭了谁注册了它的最后一个人？
问题应该由遥控器关闭。开发不能私自关闭的Bug。
21。程序员不喜欢你老的代码？
厌恶是正常的。解决的办法是组织代码评审，单独留的时间。 XP是一个方法。
22。你的项目组团队士气的活动，为什么呢？每月
过一次，吃饭，唱歌，郊游，玩，卡丁车等等，一定是。不要把钱。
23。你有自己的队徽是什么？
有自己的标志。至少应该有自己的代号。
24。印有你的员工，公司标志的T恤，为什么呢？
有。能增强归属感。当然，T恤都好看，棉最好用80做的，不要穿几次破烂。
25。总经理至少每月参加次项目组会议
想要的。让高层团队成员感到关注这个项目。
26。开发是给每一个你打开它的一个分支？
反对。分支和合并管理的工作量太大，而且容易出错。
27。有人长期入住的代码？
没有。对于大多数项目来说，最多两三天应该入住。
28。在入住注释代码来填充呢？
至少写一两句话，比如“解决问题225”。如果上坡拉，这也算做的“配置审计”的一部分。
29。已为入住天天没有设定最后期限？
要清除入住截止时间。否则生成中断。
30，你可以一下子所有的源代码被编译成安装文件吗？
希望。这是一个每日编译（每日构建）的基础。并且必须能够进行自动的。
31。您编译项目团队每天做呢？
一定做到。有三样东西一个软件项目/产品开发必备：？1 bug管理; 2源代码控制; 3每日构建....
32。你的公司已经积累了项目风险列表？
要。风险清单。否则，下一次的项目开始，只有拍脑袋风险分析。
33。
设计越简单越好越简单越好。当设计多字，未来可能会带来无穷的后患。应该从一开始就勇敢的砍。所谓的范围管理。
34。最大限度地利用现有的产品，技术，代码
的没有什么自己的编码。的BizTalk和Sharepoint就是最好的例子，并以此为基础这两项，可以提高很多起点。或者你可以尝试之类的许多现有的控制。或尝试使用XML，而不是试图解析一个文本文件;尽量用RegExp的，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。
35，你会定期停下来夯实代码？
要。最好一个月左右一次。去年年初，Windows组的谣言停止了一个月来增强安全性的Stevb命令。顺便说一句，“夯”这个字念“挂起”，第一声。
36。你的项目团队每个人都写了每日报告呢？
写。五分钟就足够写10句话，这帮人告诉自己，我今天所做的一切。一个为了沟通，二鞭策自己（如果空闲的一天，不好意思自己会写）。
37，你的项目经理会发出周报吗？
要。同时进行通信。包括目前进度，可能的风险，质量状况，进度等各项工作。
38。你的项目团队是否符合一个星期至少一次呢？
要。必须得到满足。程序员讨厌开会，但会议时间在一起，每星期至少应该有四个小时。包括小组会议，规范审查会议，错误会审会议。我们不闷头写代码。
39。满足你的项目团队讨论什么已被记录？
将发行前的会议要求和议程，将负责进行和记录人，后有人负责发会议纪要，这是有效的交汇点。此外，每个会议应形成协定和行动项目。
40。其他部门知道你的团队是做什么的？
要送些快讯给整个大组织。显示您的团队的价值。否则，当你坐在电梯里面，其他部门谁问：“你在做什么，”你回答“ABC项目”的时候别人全然不知，那种感觉不太好。
41。通过电子邮件
电邮利益进行所有正式沟通是如此抵赖。同时也避免矫枉过正，最好的方法是使用电话和当面说，和电子邮件确认。
42。建立多个邮件组
如果AD +交换内，始建分发列表的项目团队。比如，我会建ABC项目核心团队，农行项目开发团队，农行项目所有测试人员，农行项目扩展团队，等等。电子邮件发起这样一个方便，允许接收邮件的人接受，不应该被骚扰接收。
43。每个人都知道在哪里可以找到的所有文件？
每个人都应该知道。这就是所谓的知识管理（知识管理）。最方便的是在一个集中的文件共享文件，一个更好的方法是使用SharePoint。
44。你决定做出改变的时候，要告诉你的原因是什么？
来告诉你为什么。授权团队成员的手段，以提供足够的信息，这是无国界医生开口的几个原则之一之一。事实上，告诉我为什么是人，告诉我为什么为了有了解。中国人喜欢从事的工作限制，限制信息，人们似乎能够看到该文件的副本是有该人的身份。错了。权威，权力，没那么不能够访问的信息/数据，因而不能在资源的控制权。
45。保持灵活，并期望改变
如此。需求必须成为，并且已经编写的代码会被要求。心理上不抗拒变化做好准备，但预计变化。
46。你有一个全职的软件测试人员？
有一个完整的测试。如果人手不够，可以点对点的测试，交换测试。不要测试你自己的。
47。测试你有一个总体规划，指定做什么和怎么做呢？
这是一个测试计划。或做性能测试？还是做可用性测试？你什么时候开始测试性能？什么是标准的测试？通过什么手段，自动的还是手动？这些问题需要一个测试计划来回答。
48，你是先写测试案例，然后测试它？
应该的。设计应重新规划，重新测试了第一个测试用例。当然，它是柔性的。有时候我做第一遍测试的同时补测试用例。作为第一个测试用例重新开发，我不喜欢，因为不习惯，太麻烦，所推荐的其他人试试也无妨。
49。你是否会创建一个测试案例为各种输入组合？
不要搞边界条件组合。当心组合爆炸。有许多工具，可以自动生成各种边界条件的测试案例组合 - 但要想清楚，你有那么多时间来运行测试用例。
50。程序员，你可以看到测试呢？
要。让我们看看开发测试案例吧。我们一起拿出一个目的：提高质量。
51。你是否只是抓一些人来做易用性测试？
这样做。看到自己写的程序界面，怎么看都是顺眼。这就是所谓的审美疲劳 - 臭找了半天也没有臭，不方便永久要去适应它。
52。你正确地期望自动测试？
不要期望太多。在我看来，除了性能测试，或暂时忘记了第一个“自动测试”吧，忘掉它的WinRunner和LoadRunner的。对于国内的软件测试的现状，它只能“矫枉必须过正”了。
53。你的性能测试已完成，这样做之前，所有功能都开发了？
不能。性能测试不能被分类成一个所谓的“系统测试”阶段。早期测试早期矫正，圣母升天早早。
54。你有没有注意到农药在测试的效果呢？
抗虫，错误了。发现一些新的问题是正常的。在这个时候，最好大家交换试验区，或使用其他工具和用于看技巧，你会发现一些新的bug。
55。有人在你的团队可以说该产品是当前形势的整体质量？
有。当老板问怎么这个产品的质量目前，测试引线/经理应该负责回答。
56。你有一个单元测试呢？
所需的单元测试。然而，单元测试是不，不，不，我没有单元测试的项目，也做成功了 - 可能是侥幸，也许我们都精通的关系。同样，软件工程的实践是非常，非常的作品非常灵活的一套方法，某些方法会更好在某些情况下比其他方法，反之亦然。
57。程序员，你都扔在墙上完成的代码就可以了？
禁忌。写在未来的一个程序，即使我不做单元测试，应该启动和运行自己的。虽然有了专门的测试人员，开发谁不不能做一个小测试。微软测试版本文件说，该计划很烂，然后进行测试，踢回右边。
您输入了所有的功能，以检查它58。计划？
没有。虽然输入检查点做编写安全的代码，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入，并保存一些努力。由于同样的原因，并非所有的功能被写入，得到评价。写作的主要部分是足够的。
59。产品有一个统一的机制，错误处理和错误的接口？
有。最好是有一个统一的错误信息，那么所有为每个错误编号的错误消息。以这种方式，用户可以根据自己的号码在用户手册误差里面去看看错误和可能的原因，例如，SQL Server错误的具体描述。同样，ASP.NET必须有一个统一的异常处理。您可以参考相关的
应用程序块。
60。统一的代码，你必须写规范呢？
有。许多守则公约，搞上了一个分布式的每一个人。当然，如果有这样的工具来检查代码的FxCop更好。
61。你们每个人都明白这个项目什么样的商业意义？
要。这是视觉的意义。这样做不仅可以作为一个工作项目。有时你想认为自己是在中国的先驱变成某一个行业的信息，或不时地告诉团队成员，如何纳税人的钱数以百万计，每年为这个项目可以节省国家的某些部门，所以激励它。平凡的事情也是可以有个崇高的目标。
62。产品的界面和操作实践的各个部分与它保持一致？
这一点。让用户感觉仿佛整个程序写成一个人。
63。有宣传的很酷的功能亮点呢？
要。这是为了增强团队凝聚力和信心。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。因此，对于客户，会感到该产品是可接受但从质量的点。或者，很酷的功能或亮点可以作为衡量质量问题亡羊补牢。
64。可以缩短启动时间
如此。软件启动时间（启动时间）是客户的第一印象是好的或坏的表现。 。
65，不要过于注重外部第一眼印象而忽视内在质量
程序员容易犯这个错误：太看重性能，稳定性，存储效率，但忽视了外在的经验。和高级管理人员，客户相反。考虑到这两个方面，协调这些工作是PM。
66。你就根据详细的产品功能规范发展呢？
这一点。设计应以开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。在设计的细节时，不要钻，不钻到数据库，代码等具体实现里面，这些都是后面的事情，一步步来不能着急。
67。开发和测试功能设计它开始之前，每个人都仔细审阅？
做。功能规格审查的目的是统一思想。此外，在审查的共识形成后，未来没有人能说，“你看，当我反对这样的设计，现在就忍受”
68。每个人都一直以为整个图像为什么？
这一点。虽然该项目只是大家在一片树叶的制造里面，但每个人都应该知道，树本身在制造业，其中叶是怎么样子。我反对软件蓝领，太多的反对作为软件制造商流水线，生产车间。参见第61条。
69。师开发工作是纯粹的垂直或水平为什么？
不是简单地根据功能模块分，或者单纯根据表现层，中间层，数据库层的点上。我推荐它：首先，根据功能模块分，然后每个“层”都有一个Owner来检查所有的设计和代码，以确保一致性。
70。程序员写程序设计说明文档呢？
要。但我听说微软的程序员1999年以前也不写，所以不写来写也不是绝对的，偷懒有时候也是可以的。参见第56条。
71。当你让他写一个程序来招人面试是什么？
希望。我喜欢的人做一个字符串，主题类别的列表。这个主题有许多自行车，判断，指针，递归等，既不偏向过于考算法，也不偏向过于考特定的API。
72。你有没有技术交流讲座？
希望。每两个星期一次搞内部或座谈技术讲座吧。允许成员之间共享的技术思路，这个钱去培训费用之外。
73。程序员可以专注于一件事情么？
让程序员专注一件事。举例来说，有两个项目和10个人一个部门，一种方法是让10个人同时参加两个项目，每个项目每个人都花50％的时间;另一种方法是亲自去项目5个A，5个人，项目B，每个人都100％在某些项目。我会选择后者。很多人都明白这个道理，但花了大量的实践的领导下，作为一种资源，可任意分割。
74。程序员会夸大需要完成一个任务了你的时间？
是的，这是常见的，尤其是在项目的后期会做夸大需要换一换，以次来抵制变革的时间。解决的办法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，以及颗粒大小的估计时间变小。
75，尽量不要使用虚拟头
最好不要使用虚拟头。虚拟元首意味着资源是不安全的，共享的资源会减少资源的效率，容易增加出错的机会，做一个头脑没有太多的时间来审查规范，审查设计谁。一个专门的人，强于2只有50％的投人的时间和精力。我所遭受的损失：7部分时间在测试仪，干燥的Bug发现还活着，还不如加起来两名全职的。请参阅第73 73是程序员，75是资源管理器。

软件项目管理案例3：软件开发项目需求分析怎么写？

代理商和旅游景点管理系统项目开发背景 消费劵管理系统是一个面向广大客户来源以及一个和代理商的业务流程的一个项目，由于该系统涉及的客户面和业务较广，系统的各项功能与各项管理消费劵息息相关，因此做好项目系统需求分析显得至关重要。根据实际情况采用各种技术手段对消费劵的管理，争取代理商、景点和客户之间得到最大限度的需求。编写的目的 为了让开发人员能够很快的了解该项目，了解该项目的需求，知道该项目的具体实现的功能，通过文档信息知道了该项目所涉及到的数据库表和每个表有哪些字段。项目系统需求分析 代理商：

1、 代理商以5折优惠从景点出购买消费劵（消费劵有面值不等的，目前未知）。
2、 代理商预付一定的预付款（如5万元）从景点处购入2倍的消费劵（就是10万元）。
3、 代理商卖出给客户均以7折卖出
4、 代理商预付款余额不得低于一定的金额（未知。如：预付款余额不低于2000等）。
5、 代理商在预付款余额低于一定的金额后，需要及时补充（如：几个工作日内景点收到补充的预付款）。
景点：1、 景点对客户使用的消费劵进行消费劵验证（如：消费劵卡号验证，是否已过期等）。2、 景点对客户所使用的消费劵不得以任何方式返还（如：消费劵1000，用去900，那么也不得返还100元金额）。
客户：1、客户使用消费劵必须在消费劵能使用的范围2、客户在使用消费劵必须在消费劵的有效期内使用，预期作废。3、客户使用消费劵消费时，若消费金额＞实际消费金额，应付实际消费金额—消费劵金额。
共同补充：1、 预付款余额=预付款当前余额—客户实际消费金额（备注：若客户使用1000元的消费劵消费了800，那么客户实际消费金额=800）功能分析描述 根据登陆人员的权限不同，页面不同所执行不同的操作登陆功能 1、 经理登陆管理2、 员工登陆操作登陆功能

描述 ：
1、 代理商经理登陆，经理有权限完善资料，建立工作组，员工信息的录入。添加景点以及景点的相关信息（如：景点的名称，景点的地点，景点经理的联系方式）。管理财政，查看每个景点消费劵的售出量和使用量，对账单，对账表，根据实际情况，打印各个景点的消费劵和消费劵的面值，打印消费劵的数目、该消费劵的折扣，信息都录入数据。根据消费劵的售出情况计算所得的利润。查看预付款余额，不足的及时补充。
2、 代理商员工登陆，登陆出售消费劵界面，激活消费劵的金额，记录每个景点的出售的消费劵的面额（激活的），各个景点的消费劵的出售数量。
3、 景点经理登陆，经理完善资料，建立工作组，员工信息的录入，添加代理商以及代理商的信息（如：代理商的名称，代理商的地点，代理商经理的联系方式）。查看每个代理商在我们景点销售情况及使用情况。查看每个代理商的预付款余额是否已不足（不足提示该代理商），对账单，对账表。
4、 景点员工登陆，登陆收费系统，验证客户所使用的消费劵是否已激活，该客户使用的消费劵是哪个代理商出售的，该消费劵的金额是多少，哪一天消费的，都记录下来。

项目涉及数据的分析代理商和景点数据分析
1、代理商和景点的角色分析：经理，员工，涉及到的就是用户名（username），先不用管它是经理还是员工，后面有该用户的权限的，我分析的数据：代理商用户表（AgentUser）主键AIDNumber用户名AUserNameVarchar（10）用户密码AUserPasswordVarchar（20）用户权限（角色表外键）AUserRightsNumber↓角色表主键RIDNumber角色RoleVarchar（12）
2、景点信息表：景点信息表主键SIDNumber景点名称ScenicSpotNameVarchar（30）景点地址ScenicSpotAddressVarchar（100）景点联系电话ScenicSpotNOVarchar（15）景点折扣ScenicSpotDisCountNumber消费劵数据分析 消费劵信息表主键CCIDVarcher（20）消费劵面值CCMoneyNumber消费劵属于哪个景点（景点信息表外键）SIDVarchar（20）消费劵折扣SDiscountNumer详细账单表 账单表主键ZidVarcher（20）金额MoneyNumber属于哪个景点（景点信息表外键）SIDNumer对账单，

对账表分析
1、 按一定的是时间（比如一个月）会生成一个具体的账单以便于在管理人员的查看和管理，代理商对每个景点的销售消费劵的情况和景点对每个代理商销售的情况都记录保存。
2、 按一个月算每个月双方要对账单。

打印消费劵分析
1、 不能打印任何面值两个相同的卡号，用一个软件以一个数字开头进行递增。
2、 打印每个景点的消费劵，根据该景点在我们代理商的销售情况，按实际情况进行打印（面值，张数）最后补充一个，客户是不是可以上网查询自己的消费劵真假面值，目前在考虑 。