XP开发方法简介
XP开发方法简介 1
一、XP诞生背景 2
二、什么是XP? 2
三、XP开发过程简述 6
四．XP的规则 7
4．1 计划阶段 8
4.1.1建立用户需求 8
4.1.2 发布计划 9
4.1.3 小型版本发布 10
4.1.4 项目开发进度 10
4.1.5 迭代开发 11
4.1.6 建立迭代开发计划 11
4.1.7 人员流动 11
4.1.8现场办公 12
4.1.9 修改不合适的规则 12
4．2 设计阶段 12
4.2.1简单性 12
4.2.2定义系统框架（system metaphor） 12
4.2.3 CRC卡 12
4.2.4确定关键问题的解决方法（SPIKE） 13
4.2.5 勿太早增加新功能 13
4.2.6 坚决重组 13
4、3编码阶段 13
4.3.1 自始至终强调用户的作用 13
4.3.2 编码 14
4.3.3 编码前建立测试单元 14
4.3.4 成对编码 14
4.3.5 串行集成 14
4.3.6频繁集成 15
4.3.7集体代码所有权（collective code ownership） 15
4.3.8 最后的优化 16
4.3.9不要加班 16
４．４测试阶段（testing） 16
4.4.1 单元测试 16
4.4.2 单元测试框架 17
4.4.3 发现Bug 17
4.4.4 验收测试 17
五、小结：XP的特点 18
一、XP诞生背景
６０年代晚期，７０年代早期，电脑程序员往往应用能够应用的任何方法来开发软件，许多程序员能开发出一些复杂的软件产品，但没有人可以理解，同时，每个程序运行时都会不可避免的出现一些Bug,这就是软件危机。１９６８年，Edsger Dijbstra 给CACM 写了一封信名为Goto Statement Considered Harmful.信中包含了软件工程的核心思想。人们意识到必须有一个更有纪律性的方法来帮助我们开发软件，使得软件的质量及预计花费相一致。８０年代是电脑程序员的黄金时代，其时已建立了一些软件开发的标准和原则，开发出的软件质量比几年前大大提高，看来只要对所有遇到的问题都创建更多的标准、规则，人们就可以及时交付完美的软件产品。因此人们针对所有潜在的问题制定了越来越多的规则。
然而，人们发现很难真正遵循所有这些规则，整个过程太过复杂，难以理解，一些用抽象的概念写成的文档数量太多，难以管理。试图遵循一个好的大型开发方法犹如加州的淘金热，每个人都迎头前进，结果却失望而归。于是人们又开发了一些软件来帮助软件开发，出现了CASE工具，用于帮助我们遵循这些规则。但它们本身太难应用，实际上很少有人能真正遵循一个大型的开发方法，很多程序员又倾向于应用一些轻量级的软件开发方法，它们包含的
标准和规则比较少，易于遵循。
这并不意味着重新回到无规则的年代，学到的教训并未被忘记，人们选择了一些能提高软件开发质量的规则，去掉那些阻碍开发过程的原则，提出一些轻量级、简明有效，易于遵循的
软件开发方法。
XP是新型的软件开发方法之一。１９９０年，Kent希望找到一种更好的发展软件工程的方法。他与Ward一起工作，总结了自己简单高效的开发软件的经验，于１９９６年提出的一
种新的开发/生产方法――XP。
二、什么是XP?
XP 是Extreme Programming 的缩写，从字面上可以译为极端编程。但是，XP 并不仅仅是一种编程方法，也不是中文中常理解的那种不可理喻的“极端”化做法。实际上，XP 是一种审慎的（deliberate）、有纪律（disciplined）的软件生产方法。
我们说软件生产，而不说“顺口”的软件开发，是因为软件开发常常被误解为代码编写。软件生产从手工作坊式进化到工程化，是软件业不小的进步；但人们在软件工程的实践过程中也逐渐传统的软件生产方法太过“笨重”，难于实施，导致的直接结果是生产成本的上升，于是，人们开始寻找有别于“重量级”（heavyweight）生产模式的“轻量级”（lightweight）生产模式。所谓“轻量级”（lightweight）就是只有很少的一些规则（rule）和做法
（practice）。XP 就是在这样的历史背景下在90 年代初出现的。
XP 的鼻祖是Kent Beck 。最初Kent 的希望是找到更好的软件生产方法。在思考和探索的过程中，Kent 逐渐意识到改进软件项目的四个因素。
第一是强调沟通（communication）。
第二是推崇简单（simplicity）。
第三是注重反馈（feedback）。
第四是富有勇气（courage）。
这四个因素后来成为XP 的四大价值观。
有人以为XP 只在非正规的软件项目开发中才存在，而实际上，XP 特别强调客户满意和团队合作，很多商业化的软件公司都采用XP 来开发软件项目。XP强调满足用户的需求，这种开发方法可在任何需要的时候提供给客户可用的软件产品。XP强调遵循用户的需求变化，即使在开发的生命周期晚期，这种需求变化也可以得到满足。在XP 中，开发队伍不仅仅是编程人员，还包括管理人员和客户。但是XP 适合2-10 人的开发队伍。所以大规模的软件
项目XP 不大能够胜任。
经过多年的应用和实践检验，XP 总结出了软件生产的十余条做（practice），涉及软件设
计、测试、编码、发布等各个环节。
下列几点是必须要做的：you must
1. test before code编码之前写出测试
2. program in pairs成对编码
3. integrate frequently频繁集成
4. be rested不要加班
5. communicate with the customer daily每天与用户进行交流
6. follow the customer’s priorities遵循用户的优先级
7. leave the software clean and simple by the end of the day每天清理代码
8. adapt the process and practices to your environment适应开发方式和环境
XP主要在四方面提高了软件开发：
１．强调交流（communication）
XP teams:
Use a common system metaphor.
Work in an open workspace.
Continuously integrate the code.
Have a customer teammate.
Program in pairs.
Collectively own the code.
Frequently plan with
and report status
to the customer.
２．推崇简单（simplicity）
XP teams:
Do the simplest thing that could
possibly work.
Continuously simplify and improve the
design through refactoring.
３．注重反馈（feedback）
Write test cases before production code.
Develop in small releases,
And even smaller iterations.
And even smaller tasks.
And even smaller tests.
４．要有勇气（courage）
XP team members are not afraid to:
Stop when they are tired.
Let every business decision be made by the customer.
Ask customers to reduce the scope of a release.
Ask their peers, or customers, for help.
Design and implement only what is needed for today, trusting that we can add,
tomorrow, what will be
needed tomorrow.
Make changes that improve the function or structure
of code.
Fix the design and retrofit existing code when the design is shown to be inadequate.
Throw code away.
Change the process when it’s not working.
XP 强调四种价值：交流，简易，回馈，勇气。XP开发过程中，程序员与用户及其他程序员之间经常保持交流，要求开发设计尽可能简洁。同时XP要求从第一天就进行测试，以获得反馈信息，尽早提供给用户可用系统，然后听取用户的反馈，进行修改，有了这些基础，XP
程序员就可以自信的面对需求和软件技术的变化。
XP 是与众不同的，它有点象快步的舞蹈。XP 开发过程包括许多的小卡片，独立的看，这些小卡片没有什么意义，但是当它们组合在一起，一幅完整的美丽的图片就可以看见，也就是说，看上去没有意义的每个部分，组合起来却实现了一个有效的开发过程。XP方法有别于传统软件开发，它是软件开发的一种新的重要的发展。它尤其适合中小规模的团队进行一些需求不甚明确或需求变化很大的开发。XP改变了我们开发程序的传统思维方式。下面我们
将介绍它带给我们那些改变。
第二问题：XP 带给我们的变化
通过软件工程设计的简单而优美的软件并不比那些设计复杂而难以维护的软件有价值。
这是真的吗？XP 认为事实并非如此。
一个典型的项目花在人力上的金钱是花在硬件上的时间的20 倍，这意味着一个项目每年要花200 万美元在程序员身上，而仅仅花10 万美元在电脑设备上。很多聪明的程序员说；“我们如此聪明，发现一种方法可以节省20%的硬件开销”，然后他们使得源程序大而且难懂和难以维护，他们会说：“但是我们节省了20%或者2 万美元每年，很大的节省”。反之，如果我们写我们的程序简单而且容易扩展，我们将至少节省10%的人力开销，一笔更大的节省，
这是你客户一定会注意到的一些事情。
另外一个对客户来说很重要的问题就是程序的BUGS 。XP 不只是强调测试，而且要求正确的测试。测试必须是能自动进行的，以便为程序和客户提供一个安全的环境。在编码的所有阶段，我们不断增加测试用例。当找到bug 时，我们就添加新的测试，一个紧密的安全网就这样产生了。同一个BUG 不出现两次，这些一定会引起用户的注意。
你的客户必须注意的另外一件事情：XP 开发者拥抱需求变化。XP 使我们能够接受需求的变
化。
一般情况下，客户只有在系统被开发完成以后能真正去体会它。XP 却不一样，它通过加强客户的反馈来缩短开发的周期，同时获得足够的时间来改变功能和获得用户的认同。在XP
中，你的客户应该明确的知道这一点。
XP 开发过程的大多的革命是在软件开发的方法上，代码质量的重要程度超出人们一般所认为的。仅仅因为我们的客户不能明白我们的源代码并不意味着我们可以不努力去管理代码的
质量。
第三个问题：我们什么时候用XP
XP 方法的产生是因为难以管理的需求变化，从一开始你的客户并不是很完全的知道他们要的系统是怎么样的，你可能面对的系统的功能一个月变化多次。在大多数软件开发环境中不断变化的需求是唯一的不变，这个时候应用XP 就可以取得别的方法不可能取得的成功。XP 方法的建立同时也是为了解决软件开发项目中的风险问题。假如你的客户在特定的时间内，需要一个相当难开发的系统，而且对于你的项目组来说，这个系统是一个新的挑战（从来没有做过），那风险就更大了，如果这个系统对于整个软件行业来说都是新的挑战，那么它的风险就更大了，采用XP 将可以减少风险，增加成功的可能。
XP 方法是为小团体开发建立的，在2-10 个人之间。假如你的团体恰好合适，你就不需要用其他的软件工程方法了，就用XP ，但是要注意你不能将XP 方法应用于大团体的开发项目中。我们应该注意，在需求一惯呈动态变化或者高具有高风险的项目中，你就会发现XP 方法在小团体的开发中的作用要远远高于在大团体的开发。
XP 方法需要一个扩展的开发团体，XP 团体不仅仅包括开发者，经理、客户也是其中的一员，所有的工作一环扣一环，问问题，商讨方法和日程，增加功能测试，这些问题的解决不仅仅
涉及到软件的开发者。
***另一个需要是可测试性，你必须能增加自动的单元测试和功能测试，然而在你进行这个需求的时候，你会发现有许多的问题很难测试，这需要充分发挥你的测试的经验和智慧，而且你有时还要改变你的设计以便它可以更容易的进行测试。记住：那儿有需求，那儿就应该
有测试的方法。
在XP 方法的好处的清单上，最后一条是生产力。在同样的合作环境下，XP 项目都一致的表现出比使用其他方法高的多的生产力。但这从来不是XP 方法学的真正目标。XP 真实追求的目标是：在规定的时间生产出满足客户需要的软件。假如对于你的开发来说，
这是很重要的方面，你就可以选择XP 了。
三、XP开发过程简述
XP流程图如下：
测试情况
user stories
请求新的user stories bug
计划速度
体系结构
测试信号系统？发布计划版本方案最新版本验
收客户审核小
测试版本
不确定的
估计确信的下一个重复
估计
测试信号
用户提出User Story后，可根据这些需求制订发布计划，根据发布计划确定每一次的迭代计划，一次迭代中实现一部分User Story。当有新User Story加入或项目开发速度变化时，需要修改发布计划。一次迭代完成后，对最新版本进行验收测试。如果出现Bug,要从新进行此次迭代测试，否则就可向用户发布此次可用的系统产品，然后进行下一次迭代，实现其
它User Story。
在XP的计划阶段，User Story是关键所在，可以把User Story手写或打印在卡片上，通过手工处理这些卡片，简单高效地确定项目的内容和计划。
在XP系统体系结构设计阶段，通常用Architectural Spike 或原型来建立一个简单设计，此阶段，CRC卡片是一个简便的工具，它有助于所有技术人员理解整体设计，并提出自己的想法。XP的独特之处在于采用了一种叫重组（refactor）的技术，可以创建更好的体系结
构。
编码阶段中，代码质量非常重要，提高代码质量的方法包括成对设计、重组和在编码前建立
测试。
测试是非常重要的阶段，好的单元测试及验收测试是XP项目的检证印记。XP认为应该是让开发人员向用户证明代码可正确运行，而不是用户来证明代码崩溃了。
四．XP的规则
XP有自己的开发标准，同时支持其他标准，两者融合在一起形成一套良好的开发方法。
计划
1 ．填写用户故事卡片
2 ．通过发布计划会议确定开发日程
3 ．频繁的发布小的版本
4 ．计算项目开发“速度”
5 ．一个项目划分成多个开发周期
6 ．通过周期计划开始一个周期
7 ．在开发组间交换成员
8 ．每天开始的时候进行一次“简便会议”
9 ．当xp 出问题的时候“修复”它。
设计
1 ．简单性
2 ．选择一个系统隐喻
3 ．在设计会议时使用CRC 卡
4 ．通过“侦察”来降低风险
5 ．在开始不要设计太多的附加功能
6 ．任何时候只要有可能就要refactoring
编码
1 ．客户应该是小组的一员
2 ．编码必须写到规定的水平
3 ．编码之前先写单元测试
4 ．所有的代码都由两个人完成
5 ．同一时间只有一组（2 个）人集成代码
6 ．代码经常整合
7 ．所有人拥有所有代码
8 ．把优化工作放在最后
T 9 ．不超时工作
测试
1 ．所有的代码都必须有单元测试
2 ．所有的代码在分布之前必须通过所有单元测试
3 ．当一个BUG 发现时，就增加新的测试
4 ．我们经常运行验收测试，并公布分数。
下面我们分别详细介绍上面的规则和经验
4．1 计划阶段
4.1.1建立用户需求
XP中，用户需要建立Use Story。Use Story与用户的目标相一致，但不是完全相同。Use Story 是开发人员分配任务的基础，评估项目进度的依据，和完成测试的起点。
USER STORIES 和USE CASES 有着一样的目的，但其实却是不一样的。在实施计划的会议上，USER STORIES 都是用来帮助估计时间的，它们替代了大量的需求文档，USERSTORIES 通常是由客户撰写并用来描述他们需要的系统的功能，它们类似于情节描述，但是它不仅仅描述用户界面，它们是有一定格式，一般大概三句话，完全由用户用自己的语言写成，用来描述
任务，不包含任何的技术用语。
USER STORIES 也产生可验收测试，一个或者多个验收测试必须增加以检查USERSTORIES 是
否已经被正确的采用。
USER STORIES 最难以理解的一点就是，它怎样来区别于传统的需求分析的。它们之间最大的区别是在于分析需求的详细水平上，USER STORIES 仅仅提供足够于风险分析的情况，它提供的情况用于估计USER STORY 所需要的开发时间，当开发者对USER STORIES的大概情况做出判断后，他就去见客户，面对面的接受一个更详细的需求描述。
开发者估计多长的时间可以完成这个USER STORY ，在XP 的经验中，1- 3 周是理想的USER STORY 开发时间，理想的开发时间是指在没有打断的情况下将USER STORY 代码实现所需要的时间，不是由别人来指派，而是由你自己才确切的知道任何去做。长于三个星期，就意味
着你应该将该USER STORY 细分，如果小于一周，你就需要将USER STORY 合并。根据XP 的经验，在发布计划的时候，一个项目中USR STORYS 的数量最大不应该超过80 个，最小应
该不小于20 个。
USER STORY 和需求文档的另一个区别是集中在使用者的需求上。在USER STORYS 上，你必须尽量的避免接触太多的特定技术（如：数据的流程，算法等）细节，你应该尽量的保持STORIES 集中在描述用户的需要和价值上，要尽量反对去描述特定的界面输入输出。
流程
流程：在XP 中，UserStory 是一个关于系统如何去解决一个问题的情节。每一个User story 用一张卡来书写，代表着一块以某种方式跟客户相关联的功能模块。从整个项目的计划到开发的过程（游戏计划，提交日程安排，反复计划）中所有的卡片都被保留，他们被客户优先提出，被开发者评估，然后被分给软件工程师以便他们安排开发的日程，当有一些功能测试被用户拥有时，这就意味着UserStory 真正的完成了。
最后附图常用的User story 卡的DEMO ：
客户故事与任务卡
日期: _______________ 类型: 新__ 更改__ 加强__功能测试:_______ 故事号 #: ____________优先级用户:____ 开发人员:______
优先级参考:_____风险:________开发人员预计时间:_______________
任务描述:
备注
任务跟踪:
4.1.2 发布计划
发布会议用来创建一个版本发布计划以产生所有的工作计划，然后该发布计划会议为每个流程创建流程计划。技术人员做技术决定，商业人员做商业决定，这一点十分重要。发布计划
有一系列的规则，允许该项目的每一个参与者都做出自己的决定。这些规则定义了一种方法
以讨论出一个人人都可以接受的时间安排表。
发布计划会议的实质是为开发团队预计每个USER STORY 所需要的理想的程序工作周。理想工作周是指在没有任何阻碍（没有依赖，没有额外的工作，只包括测试）的情况下，实施一个USER STORY计划所需要的时间。而客户则将决定什么USER STORY 最重要或者最优先完
成。
USER STORY 打印或者书写在卡片上。开发者和客户一道讨论这些卡片，以创建一组USER STORY 。我们建议尽早交付一套有良好商业意义的可使用、可测试的系统。你可以按照时间或作用域安排USER STORY 。程序评估用于决定在给定时间之内可完成多少个STORY（按时间）或一组STORY 要多长时间才能被完成（按作用域）。当按时间安排时，程序进度增加迭代的数量以决定能够完成多少USER STORY；按作用域安排时，项目进度将预计的完成USER STORY 的全部工作周拆分以决定多少次迭代，直到版本发布准备就绪。详细安排个体迭代只能仅在每一次迭代开始之前，而不要提前。发布计划会议曾被称为计划竞赛，其规则见
PORTLAND PATTERN REPOSITORY 。
当最终版本发布计划创建完成但不能令人满意时，很多人试图仅仅变更对USER STORY的预计。切不可这样做。预计是有效的，而且将被应用于迭代计划会议。现在低估USERSTORY 会在将来引发种种问题。取而代之的是应讨论出一个可接受的发布计划，直到开发者、用户和
管理人员都能够同意。
在发布计划中，项目分为4个方面：开发范围、资源、时间和质量。必须明确制定出这些方
面的具体要求。
开发范围是需要完成的任务；
资源是可用的人员；
时间是各阶段版本发布的日期；
质量是最后提交的系统应该具有的性能。
管理人员只决定其中的三个参数，其余由开发人员决定。注意，降低质量将与其它三个变量产生不可预见的冲突。实际上，真正需要改变的只是三个变量。同时，要让开发人员降低用户对靠一下子雇佣过多人手以求立即完成计划的期望。
4.1.3 小型版本发布
开发小组需要经常向用户提供系统的部分完整版本。每个版本都能作为一个小的版本执行，完善一部分用户需求，并通过了一些测试。通过经常发布小型版本，及时反馈各种意见，使系统的开发不偏离轨道，保证开发进度，早日完善和简化用户的需求。减少各种修改的成本。
4.1.4 项目开发进度
用于衡量项目开发的快慢程度。其方法是统计每次开发实现时完成了多少用户需求或规定的
设计任务。
在每次的版本发布计划会中，当前完成的任务是继续分配任务的基础，通过对剩余任务的估
计可以检验项目开发的最终进度。但用开发人员数目或开发实现中需要的人数决定项目的开发速度不合理。实际上保证项目开发速度和时间的关键在整个用户需求的定义情况。需求定义的准确、明确，能明显减少修改次数，少产生疑问，直接减少开发中的迭代次数，从而减
少时间和经费支出。
当项目的开发时间超过计划的时间时，应该举行版本发布，或重新评估以前制定的发布计划。
由于经常有维护变化，所以修改发布计划是必须的。
4.1.5 迭代开发
迭代开发增加了系统开发的灵活性。一般把整个开发划分为大约 12个迭代过程，每个过程
持续1-3周。
4.1.6 建立迭代开发计划
在迭代开发开始前，应该确定一个明确的开发计划和开发进度。用户要在开发计划中确定每个开发迭代阶段中必须完成的用户需求、测试和版本发布时间。还有修改验收测试失败的需求。然后将这些计划转换成各阶段的设计实现任务，成为开发人员分配的详细设计计划。
每个任务的理想开发时间是1-3天，开发时间的长短由接收任务的开发人员决定。
项目的开发速度可以衡量迭代任务的轻重。所有开发任务的理想开发时间加在一起不能超过以前的开发速度。如果迭代任务太重，用户应该推迟某些需求的实现。如果过轻，可以增加一些任务，尽量完善需求。迭代开发阶段以天衡量开发速度。而非以周，这样可以更精确的
控制开发进度。
在开发延期的情况下，就能显示出单元测试和系统重构的重要性。不应该在完成计划规定任务前完成其他额外的任务，否则有可能拖延项目进度。但也不能随意修改任务和用户需求的
时间评估。系统的进展依赖于固定的评估。
在开发过程中，应注意开发的速度和是否有用户需求的开发被拖延了。出现问题后，应该及时重新评估和磋商。一般可能每经过3-5次迭代开发后，就需要重新评估用户需求和制定新
的版本发布计划。
总体而言，迭代开发增加了系统的灵活性，可控性。
4.1.7 人员流动
为避免产生知识缺陷和编码时有瓶颈，需要对小组成员做及时调整。如果一个小组的工作由某人独立负责，在其离开后将有大量的工作需要重新开始，那末这部分的工作将成为当前整
个开发任务组的瓶颈。
许多公司都重视交叉培训，一般也不让单人负责单独部分的开发。这样一来可以减少许多问题。XP中采用让开发人员在代码库设计中流动和双人开发的策略。使大家相互交叉了解整个系统的需求和设计，提高团队的开发效率，使开发小组的组建灵活，开发人员负担均衡。XP的双人开发策略是一个核心技术，提高工作效率，保证设计实现任务的连续性，但又不
断有创新。（program in pairs）
4.1.8现场办公
XP认为传统的项目会议中，参会人员不愿意发言，而偏向聆听，效果和效率都不好，也浪费资源和时间。因此他鼓励每天召开例会，讨论问题和解决办法。这样一来避免了传统方法论的缺陷，还能集中参加会议的人员，在电脑前直接浏览代码，直接验证解决办法是否可行。
4.1.9 修改不合适的规则
在实际的开发过程中，有些规则是不适用的，应该及时修改。整个团队讨论哪些部分需要修
改，确定后整个团队都要遵循。
4．2 设计阶段
4.2.1简单性
XP的一个重要原则是保持设计的简单性。其优点在于设计和实现时间短。如某部分太复杂，应该逐步将其简单化。在设计时，不要把没有确定的功能实现加进去。
4.2.2定义系统框架（system metaphor）
如何命名对象对理解系统的设计和代码复用很重要。用system metaphor可以让所有成员都
理解系统的定义规则，从而协调工作。
4.2.3 CRC卡
XP使用CRC实现系统设计。CRC卡的最大好处在于能充分体会到面向对象技术的优点。他允许组内所有成员都可以参与设计，参与人员越多，越可能产生好想法。
CRC卡的编写有一定的规则，但无须完全遵从这些规则，可以适当简化。
4.2.4确定关键问题的解决方法（SPIKE）
为技术难题和设计难题找到解决答案。一般是用一个简单的设计来寻求负责问题的解决方案。用户可以只关心目前出现的问题，而不管其他问题。从而降低技术风险，增加用户需求
评估的可信性。
如果一个问题妨碍整个系统的开发时，应该为解决此问题安排专门人员解决。
4.2.5 勿太早增加新功能
XP强调按部就班的完成任务。增加新功能时，有可能使系统更完善，但系统有可能当前并不需要这一功能，功能的增加只能加重开发人员的负担，拖延进度。一般只需要关心当前的
工作内容就可以了。
4.2.6 坚决重组
一般大家都尽量少修改已经可运行的代码，但XP认为这样做是低效率的，通过重组，可以提高代码的效率，和减少系统的开发时间。同时使每个新代码简单，易理解、修改和扩展，
增加了系统的效率。
开发人员一定要勇于修改自己的设计错误。
4、3编码阶段
4.3.1 自始至终强调用户的作用
XP 的要求并不多，其中之一是尽可能发挥用户的作用，用户不仅可以帮助开发小组，而且本身就是开发小组的组成部分，XP项目开发所有阶段都应该有用户的参与，最好是直
接面对面的参与，最好在每个开发小组中有一名或更多的用户参加。
在确定User Story 时，用户在开发人员的帮助下完成User Story的确定，并作出开发时间的评估及确定User Story的实现优先级。用户的参与能使User Story包含绝大部分
系统设计应有的功能。
在发布计划讨论时，开发人员和用户一起协商确定一个将发布的版本应包含哪些User Story以及发布的时间。发布计划中应定义增量发布信息，允许尽早向用户实现一些功能，这样用户可尽早试用此系统，然后给开发人员提供反馈信息。
由于User Story不涉及细节，开发人员必须与用户交流以获得足够的细节来完成设计任务。功能测试中仍然需要用户帮助，用户可帮助创建测试数据，计算或证实测试结果。可能在产品发布前夕会发现系统不能通过所有的功能测试，此时应由用户来检查整个测试过程，决定
产品是否可以发布。
表面上是乎很浪费用户的时间，但事实上，由于不需要详细的需求规格说明书，不会交付一个不合格的系统，用户的时间从一开始就被大大节约。
4.3.2 编码
编码必须格式化，符合一定的编码标准，这样使得整个开发小组读和修改编码比较简单。
4.3.3 编码前建立测试单元
从一开始就建立测试单元是XP的特性之一，XP认为编码前先建立测试User Story会使编
码更快更容易。
建立单元测试有助于开发者真正去考虑什么应该做，通过测试而使需求明确，这样在用可执行代码实现规格说明要求时不会产生歧义。同时，建立单元测试有助于系统设计，有一些系统的单元测试非常难做，因为这些系统往往先编码、然后考虑测试，而且这些功能往往由完全不同的小组完成。如果先建立测试，往往会被这样一种愿望影响，向用户证实一切有价值
的东西，这样的设计往往易于测试。
先建立单元测试可以这样完成：先建立一个测试来定义手头工作的某些方面，然后以最简单的编码通过这次测试，接着建立第二次测试，增加一些代码来通过这次测试，但不能有
第三次，所有的功能必须在两次测试中完成。
编码应该简单明了。其他人员只要浏览测试即可明白如何使用新代码。
4.3.4 成对编码
成对编码指所有产品的代码由两位开发人员在同一台机器上共同完成。成对编码提高了软件质量而不影响交付时间，两个人在同一台计算机上工作与分别在两台机器上工作能为系统增加同样的功能，而且可能质量更高，同时节约了资源。
成对编码的最佳途径是两人并肩坐在计算机旁，一个人在战术上考虑方法的实现，另一个人从战略上考虑方法是否恰当。习惯这种编码方法需要一定时间。
成对编码另一个好处如前文所述，它有利于人员的流动。
4.3.5 串行集成
如果不控制源代码的集成，开发人员测试代码时会认为一切都很好，但由于源代码模块的并
行集成，源代码的结合体还从未经过测试，不经检测会产生很多的集成问题。
如果不存在一个明确的最新版本，问题更严重。这不仅指源代码，单元测试也是如此。如果没有一组完整、正确、一致的单元测试，可能会费力找一些并不存在的BUG，而真的BUG没
有找到。
一种方法是开发人员负责自己开发的类，每个类的开发者保证每个类的代码已正确集成，这会降低错误，但类之间的关联可能任然会有错误。这不能解决整个问题。
另一种方法是设置集成员或集成小组，但一个人不能完成由许多位开发者开发的代码集成。而如果采用集成小组，假如几个星期才集成一次，这又浪费了人力资源，这种情况下，开发人员往往会使用代码库中的错误集成的旧版本。
这些方法都不能根治整个问题，开发人员一面要并行开发，能对所要求的任意部分作修改，另一方面又希望集成不出错，不应限定严格的串行开发，也不应去考虑复杂的集成问题。应该重新考虑这个问题，解决方案很简单，让开发者自己来作严格的串行测试（或称单线程集成），所有源代码有次序地发布到源代码库，一个时刻只有一组开发者在进行集成、测试及修改。单线集成可以保证最新版本的一致性。上述方法并不意味着不可以在自己的工作站上随时对修改进行集成，只是在未轮到前不能向全组发布你的修改。
这种方法需要一定的锁机制，可用令牌方法实现，经常性的集中和发布代码可以缩短持
有令牌的时间，也就减少了等待令牌的时间。
4.3.6频繁集成
只要需要，开发人员应当随时向代码库进行代码的集成和发布，而不应当使变化超过一天，持续集成有利于避免开发的分歧性及零碎性，这往往是开发者不相互交流哪些代码可重用或共享而造成的。开发人员应在最新版本上工作。使用旧版本会出现集成问题。
经常的集成可以不必在交付最后期限到前花费几个星期来做系统集成。
4.3.7集体代码所有权（collective code ownership）
集体代码所有权鼓励每个人对系统所有部分作出贡献。每个开发者可以对代码的任何一行做
修改，增加功能、修补Bug、重组。
这一点很令人难以理解。不能想象整个团队一起来设计体系结构而没有主要设计者。但是任何一个大的系统不可能在一个人头脑中产生，事实上系统体系结构已分散到整个小组中，只能依赖测试来对整个代码库把关，任何代码在分布前必须通过测试。
如果有需要，任何开发人员可对任何类进行修改然后发布到代码库。由于频繁的集成，开发
人员并不会意识到一个类已被修改或扩展。
小组中的任何人都应该有权对代码进行更改来改进它。每个人都拥有全部代码，这意味着每个人都对它负责。这种技术可以让人们对部分代码进行必要的更改而不用经过代码拥有者个人的瓶颈。每个人都负责这一事实消除了无代码所有权所带来的混乱。
“每人拥有所有代码”与“没人拥有代码”的说法并不一样。没人拥有代码时，人们可以随处进行破坏而不必负任何责任。而 XP 说，“如果是您破坏的，应该您来弥补。”我们有一些必须在每次集成之前和之后运行的单元测试。如果您破坏了某些事物，您要负责进行
修补，无论它位于代码的哪一部分。这需要极端规则。可能这是名称中带有“极端”的另一
个原因。
4.3.8 最后的优化
优化应该在最后进行，不能试图猜测系统的瓶颈在哪里，而应该去测试。
4.3.9不要加班
超时工作会使小组成员没有精力，如果项目需要加班来完成，这个项目一定会被延迟。应该在分布计划会议上修改时间计划或内容计划，同时，一个项目不能按时完成时，增加人手也
不是一个好主意。
４．４测试阶段（testing）
在 XP 中有两种测试：单元测试、验收测试。
开发人员在他们编写代码的同时编写单元测试。客户在他们定义了素材后编写验收测试。单元测试及时告诉开发人员系统在某一点上是否“工作”。验收测试告诉团队系统是否执行用
户希望它执行的操作。
4.4.1单元测试
XP的单元测试有一些不同之处，首先，应该建立或下载一个单元测试框架来创建自动的单元测试集；其次，应该测试系统中所有的类；最后，应该在编码前就建立测试。
单元测试的一般步骤：
1. 创建测试类。测试类的类名要与被测试类的类名保持关联。如果被测类的类名是
Doctor，那么测试类的类名应为DoctorTestCase.
2. 创建测试对象，为对象定义方法，并测试这些代码。
3. 写测试用例。
4. 执行测试用例。如果测试通过，跳到6步；如果测试失败，继续下一步。
5. 调整和修改或增加代码，重复4、5步，知道通过测试。
6. 发布模块代码及其测试用例。
单元测试应该同所有测试的代码一起发布到代码库中。未经测试的代码不能发布，遗漏的单
元测试应立即补上。
有人会认为单元测试花如此多的时间很不值得，事实上，自动的单元测试通过发现或防止Bug使建立单元测试的花费得到高得多的补偿。
另一个误解是单元测试可以在项目的最后几个月完成。但如果没有单元测试，整个开发会拖延，最后几个月可能会用于做别的事情，即使用于做单元测试，时间可能会不够，因为发现
所有的问题需要时间。
单元测试使集体代码所有权成为可能，XP要求所有的代码在发布前必须通过所有的单元测试，这样可以确保实现所有功能。单元测试也使重组成为可能。每个小的修改后，单元测试
可验证结构上的修改并未引起功能的变化。
为验收测试及回归测试建立一个单独的通用单元测试集使频繁测试成为可能。这样可以对最
近的修改做快速集成，然后在测试集上运行这个最新版本。如果测试失败，这个个人最新版本就与小组最新版本不兼容。用自动单元测试，可以把一系列修改很快融入最新版本中，在
很短的时间内发布。
经常加入新功能需要修改单元测试来反映功能变化。
单元测试为有效性测试和回归测试提供了安全网，这样可以有效地重构和集成。编码前建立单元测试非常有利，它可通过固定需求来集中开发者的注意焦点。
4.4.2 单元测试框架
人们有一个普遍的概念，单元测试是一种测试工具，事实上它与编辑器、编译器一样是开发工具，应该在开发的过程中用它，而不是等到项目的最后一个月。单元测试框架有助于需求形式化、结构化、明晰化，也有助于写代码、测试代码、集成代码，发布及优化。项目一开
始就要建立测试框架。
KENT BECK曾经为Smalltalk写过一个测试框架，叫Sunit,帮助开发小组进行测试。后来又与别人合作，写了for jave 的测试框架junit。现在，已经有了多种测试框架。如：CppUnit,
PerUnit,VbUnit,Pbunit等等。
除了语言不同外，所有测试框架的原理都是一致的。
建立“TestCase”类的子类用来包含所需测试的各种方法。每个测试用例均以“Test”打头起名。如“TestCreation” 、“TestSelection”、“TestRemove”等。通过收集命名为“Test…”的方法，测试工具会自动形成一套相应的测试框架。许多测试框架都已被建立，
可从https://www.doczj.com/doc/022454061.html,中下载。
如果没有，你也可以自己构造测试框架。
测试框架依次自动执行所有的用例。这些用例被一个叫做standard setup method 的方法初始化（这个方法可以替换），被一个叫做tear down的方法拆卸。这样可以确保所有用例都在一个干净的环境中执行，一个用例的错误不会影响到其他用例的执行。
大多数的测试框架都有一个简单的用户界面，可以通过用户界面来控制用例的执行、显示执
行进度、查看执行结果。
测试框架简单易用。
4.4.3 发现Bug
产品中的Bug需要建立验收测试来防止。通过一个缺陷验收测试（failing acceptance test）开发者可建立单元测试来显示更多源代码的缺陷。修补Bug时，当单元测试１００％通过后，再重新运行缺陷验收测试以证实Bug已被修补。
4.4.4 验收测试
验收测试由User Story中产生。在一次迭代中，迭代计划会议选定的User Story被转换成验收测试。一个User Story可有一个或多个验收测试，以确保功能的实现。
验收测试是一个黑盒测试，用户负责验证验收测试是否正确，并决定哪个失败的验收测试具
有最高优先级。
一个User Story直到通过验收测试或才被考虑完整，这意味着每次迭代后都要建立新的验
收测试。
质量保证是XP的重要部分，一些项目中质量保证由一个特定小组完成，其它则由整个小组
共同完成。XP要求开发紧密地与QA相联系。
验收测试应该是自动的，这样能经常运行。验收测试的评价向整个小组公布，在每次迭代时间期限内完成失败测试的修改是整个小组的责任。
验收测试的名字从功能测试而来，它更好地反映了这样一个目标，这是达到了用户要求，系
统可被接受的保证书。
五、小结：XP的特点
它是一种轻量级的软件开发过程，正适用于小软件开发队伍。
强调为了写出代码，你必须先写一个小的测试程序，这样你就对系统有了一个把握，然后再扩充系统，再进行修改。它提倡相对概念，也就是让一对儿程序员写代码，相互取长补短（在这一点上我们很支持他，两个人干活总比一个人强）。两个人在沟通的时候就有一些新的发现。它的说法和传统的软件工程想法完全不一样，传统的软件工程认为一次设计成功，然后再集中精力编程这样最好。 XP的基本思想是以简单的模型开始，然后再向上加一些东西，然后再让这个东西向设计目标靠拢，直到成功。这样一来，组内所有成员的工作就不分了，所有的人就都得分析，编程，测试，共同开发。上面已经说过了，因为有成对的程序员进行开发，因此交流很多，因此不需要什么纸头上的东西。
XP 规定了一组核心价值和方法，可以让软件开发人员发挥他们的专长：编写代码。XP 消除
了大多数重量型过程的不必要产物。
数据库设计方法及命名规范
- - 2 数据库设计方法、规范与技巧 (5) 一、数据库设计过程 (5) 1. 需求分析阶段 (6) 2. 概念结构设计阶段 (9) 2.1 第零步——初始化工程 (10) 2.2 第一步——定义实体 (10) 2.3 第二步——定义联系 (11) 2.4 第三步——定义码 (11) 2.5 第四步——定义属性 (12) 2.6 第五步——定义其他对象和规则 (12) 3. 逻辑结构设计阶段 (13) 4. 数据库物理设计阶段 (15) 5. 数据库实施阶段 (15) 6. 数据库运行和维护阶段 (16) 7.建模工具的使用 (16) 二、数据库设计技巧 (18) 1. 设计数据库之前（需求分析阶段） (18) 2. 表和字段的设计（数据库逻辑设计） (19) 1) 标准化和规范化 (19) 2) 数据驱动 (20)
- - 3 3) 考虑各种变化 (21) 4) 对地址和电话采用多个字段 (22) 5) 使用角色实体定义属于某类别的列 (22) 6) 选择数字类型和文本类型尽量充足 (23) 7) 增加删除标记字段 (24) 3. 选择键和索引（数据库逻辑设计） (24) 4. 数据完整性设计（数据库逻辑设计） (27) 1) 完整性实现机制： (27) 2) 用约束而非商务规则强制数据完整性 (27) 3) 强制指示完整性 (28) 4) 使用查找控制数据完整性 (28) 5) 采用视图 (28) 5. 其他设计技巧 (29) 1) 避免使用触发器 (29) 2) 使用常用英语（或者其他任何语言）而不 要使用编码 (29) 3) 保存常用信息 (29) 4) 包含版本机制 (30) 5) 编制文档 (30) 6) 测试、测试、反复测试 (31) 7) 检查设计 (31) 三、数据库命名规范 (31) 1. 实体（表）的命名 (31) 2. 属性（列）的命名 (34)
XP系统服务 XP系统服务 2011年04月07日 1,Alerter 服务微软对警报器服务的描述为:通知所选用户和计算 机有关系统管理级警报,就是在系统出现错误的情况下能及时向用户发出通告.对于普通应用人员来讲,禁用它可以阻止像 IE 出现错误,要求发送错误报告之类对话框的出现,因为这些错误报告对于我们来说毫无用处,除非你的计算机用在局域网络上.一般家用计算机根本不需要传送或接收计算机系统管理来的警示(Administrative Alerts). 此功能类似于禁用错误报告.服务的进程名是 Services.exe. 依存:Workstation 建议:停用 2,application layer gateway service 服务为 internet 连接共 享和 internet 连接防火墙提供第三方协议插件的支持. 如果你没启用internet 连接共享或 windows xp 内置防火墙或你不使用因特网联机共享(ICS) 提供多台计算机的因特网存取和因特网联机防火墙 (ICF) 软件, 你可可以禁止这个服务. 依存:Internet Connection Firewall (ICF) / Internet Connection Sharing (ICS) 建议:停用 3,Application management 服务提供软件安装服务,诸如分派,发 行以及删除.从 win2000 开始引入的一种基于 msi 文件格式的全新有效软件管理方案--应用程序管理组件服务,不仅可可以管理软件的安装,删除,还可以使用此服务修改,修复现有应用程序,监视文件复原并通过复原排除基本故障等.SQL 安装时,提示"系统有一个程序的安装副本在运行之中,请重新启动电脑"等提示,一般重启即可,但如果这个服务不开, 重启 N 次也没有用.服务器装了 SQL 的话也禁止吧(负带影响:有时候安装东西的时候会提示服务未启动,有时候又正常) . 依存:无 建议:手动 4,automatic Updates 服务允许下载并安装 Windows 更新. 如果 此服务被禁用, 计算机将不能使用 Windows Update 网站的自动更新功能.需要手动更新的时候,需将此服务开启. 依存:无建议:停用 5,Background Intelligent Transfer Service 服务该服务的中文意思为智能备份和传输服务, 用于在局域网中利用空闲的网络带宽传输数据.
信息系统开发方法的区别与联系 【摘要】：一个信息系统开发的成败与采用的开发方法有直接的关系，已有多种开发方法，而目前常用的几种方法有：结构化方法，原型法，面向对象方法和CASE方法。对一个具体的信息系统而言，不是所有方法都适合该系统的开发，也不是一个系统只能用到一个方法，对这些方法进行分析和比较，可以帮助开发人员找到合适的方法，同时提出几种方法的结合，发挥各自的优点，作为新的开发方法。 【关键词】：信息系统；结构化；方法；原型法 一、信息系统的概念及方法概述 信息系统开发的方法是指在信息系统开发中的指导思想、逻辑、途径以及工具等的组合。它涉及的知识面广，至今没有一种统一完备的开发方法，常见的方法主要有：结构化方法、原型法、面向对象方法和CASE方法。 （一）结构化方法 结构化方法是在70年代末，为解决当时的“软件危机”而产生的一种面向数据流的系统开发方法。它以用户至上为原则，采用自顶向下的整体分析和设计和自底向上的逐步实施。其开发过程（一个生命周期）为： （1）系统规划：初步调查，确定系统目标和总体结构及实施进度，进行可行性研究； （2）系统分析：分析业务流程、数据与数据流程、功能与数据之间的关系，提出分析处理方式和新系统方案； （3）系统设计：进行总体设计、代码设计、数据库设计、输入/输出设计、模块功能设计，给出设计方案； （4）系统实施：进行编程和人员培训及数据准备； （5）系统运行与维护：进行系统的日常运行管理及局部调整，出问题时提出开发新系统的请求。 （二）原型法 原型法是80年代在关系数据库系统（RDBS）、第4代程序生成语言（4GL）和各种系统开发生成环境产生的基础上提出的一种全新的系统开发方法。它凭借系统开发人员对用户要求的理解，在强有力的软件环境支持下，给出一个实实在
XP操作系统安装配置。 提示：Windows XP要求CPU为奔腾Ⅱ300MHz以上，内存为128MB 以上，而且最好有5GB以上的可用磁盘空间。建议安装Windows XP 系统的分区为6GB~10GB。 全新安装也有两种方式：一种是通过Windows XP安装光盘引导系统并自动运行安装程序；一种是通过软盘、硬盘或Windows 98的启动光盘进行启动，然后手工运行在光盘中或硬盘中的Windows XP安装程序。前一种安装方式操作简单，并且可省去一个复制文件的步骤，安装速度也要快得多。 在第一种情况下，你只需要在BIOS中将启动顺序设置为CDROM优先，并用Windows XP安装光盘进行启动，启动后即可开始安装。 在第二种情况下，启动后需要手工运行在硬盘或光盘中的安装程序。在安装之前千万不要忘记运行“smartdrv.exe”磁盘缓冲程序，否则第一个复制文件的步骤就要二个小时以上。Windows XP的安装执行文件一般为“winnt.exe”，在安装光盘或安装文件的i386目录下，你可在DOS提示符下键入类似“E：\soft\winxp\I386\winnt”命令，也可用“cd”命令，转到i386所在的目录，运行“winnt”命令（图1），即可运行Windows XP 的安装程序。这种安装方式会多一个复制文件的步骤，其余和第一种情况是一样的。 首先在电脑启动的时候恩DEL键（有些主板是恩F2或者F10）
这个时候我们就进入BIOS设置，这时候是设置系统的启动顺序。以便光盘启动安装系统。 好了现在准备工作做好了现在就要开始安装系统了。 在这个见面下敲击回车键（注意要快哦，不然就跳过了） 光盘自启动后,如无意外即可见到安装界面,将出现如下图所示。全中文提示，一步步的安装。
信息管理系统常用开发方法分类 在系统开发的早期，由于缺乏系统开发思想，没能形成工程的概念，以至于60年代出现了所谓“软件危机”，也促使了一门新科学——“软件工程”的诞生。管理信息系统工作者对信息系统的开发提出了许多开发方法，其中常用的有结构化法（Structured Development），原型法（Prototyping Development），面向对象法（Object_Oriented Development）三种。1．结构化法 结构化法体现了自顶向下、结构化、生命周期思想的系统开发方法，主要包括： 1) 结构化分析设计技术（structured analysis design technique）； 2) 约当（E. Yourdon）结构化系统开发方法； 3) 企业系统规划法（BSP）； 4) 詹姆斯.马丁(James Martin) 提出的战略数据规划法；IEM 5) 我国专家提出的映射模型设计法（RMDM）和信息系统设计工程综合分析法（IDEA）； 6) 杰克逊提出的JSP（Jackson structured program）和JSD(Jackson system development)； 7) 哈兰.米尔斯(Harlan D. Mills)提出的系统开发的黑箱(black box)理论及其相应的分析设计方法等。 结构化法是基于系统的思想，系统工程的方法，以用户至上为原则，采用结构化、模块化等手段对信息系统进行分析、设计和实施。在实际开发过程中，对应于系统开发的一般过程（见图1），主要应用的结构化设计方法有结构化分析（Structured Analysis），结构化设计（Structured Design），结构化编程（Structured Program）。 结构化分析（SA），是一种面向数据流的分析方法，采用结构化分析解决问题主要通过“分解”和“抽象”两种方式。在这一阶段采用了诸如数据流程图（DFD）、数据字典（DD）、处理逻辑表达（PL）、数据存储规范化（NF）及数据立即存取图（DIAD）等工具或理论。通过SA过程就能得到一个系统的抽象的逻辑模型。 结构化设计（SD）是对SA阶段提出的逻辑模型进行计划性的设计。通过SD工作过程，尽可能提高系统的运行效率、可变性、可控性和工作质量。SD的工作主要包括代码设计、文件/数据库设计、I/O设计、模块功能设计和处理过程设计。SD提供了一整套设计工具、设计原则和设计策略，采用影射思想由DFD图得到SC图。这样就得到了一个可实施的系统的逻辑模型。 结构化程序设计（SP）是采用一些基本的控制结构（IF…ELSE…ENDIF、DO WHILE…ENDDO、DO CASE…CASE…ENDDO等）工具，采用自顶向下地扩展、模块化、逐步求精原则从事程序代码设计，以得到一个现实的物理模型。 2．原型法 原型法基于新一代的系统开发工具和快速开发方法, 主要包括: 1）原型方法及其分支(如瀑布型和快速型方法)； 2）计算机辅助软件工程（CASE方法）； 3）为建立专用的信息系统开发生成工具的环境，用于定义和生成实际系统的方法。 原型法与传统的生命周期法LC相比摈弃了一步步周密细致地调查、分析、整理文档、再进行逻辑设计、物理设计等繁琐过程而快速构造系统的物理原型。但是，并不能说开发人员用原型法就没有一个分析、设计、实施的过程。实际上开发人员在运用原型法时有意识或无意识地对系统进行了一个分析、设计、比较的过程，才能快速构造一个原型系统，这个原型系统蕴含着开发人员分析、设计、比较的思路，只不过开发人员直接用物理模型表达了对系统的理解，而省却了结构化法中的大量的文档资料。 3．面向对象法 面向对象法（OO）是近年来发展起来的一种系统开发方法, 它与原型方法的设计与实现有一
第五章管理信息系统的开发方法 通过本章学习，了解管理信息系统开发的任务和特点；懂得系统开发的原则、系统开发的方式、开发的策略、开发的组织工作与项目管理的内容；掌握结构化系统开发生命周期法和原型法的基本思想、开发过程和各自的优缺点；理解面向对象法和计算机辅助开发方法。 基本内容 一、管理信息系统开发 1.系统开发的任务：系统开发的任务是根据企业管理的战略目标、规模、性质等具体情况，从系统论的观点出发，运用系统工程的方法，按照系统发展的规律，为企业建立起计算机化的信息系统。其中核心是设计出一套适合于现代企业管理要求的应用软件系统。 2.系统开发的特点：复杂性、基于原系统、高于原系统、一把手工程、产品是无形的。 3.系统开发的基本原则：面向用户原则、系统性原则、符合软件工程规范的原则、逐步规范发展的原则。 4.系统开发的主要风险：投入超计划、系统性能比预期差、没获得预期收益，有的甚至导致完全失败。 二、系统开发方法 1.结构化系统开发方法 结构化系统开发方法：用系统工程的思想和工程化的方法，遵照用户至上的原则，从系统的角度分析问题和解决问题，将提出建立一个管理信息系统到系统完全建成的生命周期划分为5个阶段，这5个阶段是：系统规划、系统分析、系统设计、系统实施和系统维护与评价。按照规定的步骤和任务要求，使用图表工具完成规定的文档，采用自顶向下整体分析和设计，自底向上逐步实施的系统开发过程。 优点：建立面向用户的观点、严格区分工作区间、设计方法结构化、文件标准化和文献化。 缺点：开发周期长、繁琐，使用工具落后、不能充分预料可能发生的情况及变化、不直观，用户最后才能看到真实模型。 2.原型法 原型法：是指系统开发人员在初步了解用户的基础上，借助功能强大的辅助系统开发工具，快速开发一个原型，并将其演示给用户，开发人员根据用户的意见和评价对这个原型进行修改，如此反复，逐步完善，直到用户完全满意为止。 原型法的类型：丢弃式原型法、演化式原型法、递增式原型法。 优点：减少开发时间，提高系统开发效率、改进用户与系统开发人员的信息交流方式、用户满意程度高、应变能力强。 缺点：开发工具要求高、对大型系统或复杂性高的系统不适用、管理水平要求高。 3.面向对象法 面向对象法：面向对象方法的技术把对象的属性(数据)和处理(方法)封装在一起，通过子类对父类的继承，使得软件便于维护和扩充，提高了软件的可复用性。 面向对象法的术语：对象、类、消息、继承、封装。 优点：以对象为基础，利用特定的软件工具直接完成对象客体的描述与软件结构之间的转换，解决了传统结构化开发方法中客观世界描述工具与软件结构不一致的问题，缩短了开发周期，解决了从分析和设计到软件模块多次转换的繁杂过程。 缺点：需要有一定的软件基础支持才可以应用，对大型的系统可能会造成系统结构不合
系统开发方法学 系统开发方法学的目标 开发一个计算机信息系统，不管它是联机航空公司订票系统。还是库存控制系统，其过程基本上是相同的。每一过程都由一些基本的活动组成。这些活动是每一个信息服务人员都应掌握的。但是由于各人对该过程的解释不同，所以很多公司采用了标准的系统开发方法。这些方法(与软件一样)可以在市场上买到或者内部设计。 系统开发方法学指出了要进行的活动、这些活动之间的关系和顺序在及关键的评价和判定的阶段标志。提交可行性研究报告和完成功能说明书是典型方法学中的两个重要的阶段标志。 系统开发方法学的好处 1.资料 长期以来，在信息系统的开发和维护中，资料总是一个问题。信息系统开发方法学(以下简称方法学)鼓励项目组成员将资料作为设计的副产品产生出来。因此，在信息系统实现时，资料总是最新的，而且是完整的。在方法学中包含了变换控制机构以保证资料总是最新的版本。不采用方法学的计算中心依靠各人的自觉性来更新他们职责范围内的资料和程序。这种工作方式会导致失败及不必要的人力浪费。当某个人离开，而留下没有资料的系统和程序时，必须花费大量的人时来弄清楚已经做了些什么。 2.项目管理 由于对开发任务(活动)进行了判别和排出了先后顺序，所以可以形成实现一个项目管理系统所必要的输入。如果没有标准的系统开发方法学，在信息服务环境中要实现项目的计划和控制几乎是不可能的。 3.资金上的节省 方法学具有节省相当大的财力和人力的潜力。最大的节省可以说是由于取消了进三步退两步的系统开发方法学而得到的。方法学对于系统开发不可忽略的重要方面提供了方向和保证。例如，一个好的方法学将要求在进行系统设计之前标列出成本、进度、安排、软件、操作以及设备等约束条件。有关的用户和信息服务经理将就这些书面的约束条件签定协议。如果没有这些指导准则，项目组经常是在一个方向推进(进三步)后，结果却发现由于违反了设计要求，有许多工作必须重做(退两步)。 当项目组遵循一个描述清楚的系统开发方法学的指导准则时，开发一个满足用户要求的高质量的系统的概率是非常高的。 有时用户和信息服务管理人员仅仅看到开发成本，但是估计系统的成本时应该包括整个系统的寿命期(包括生产年限)。尽管利用方法学开发一个系统在前期要求较多的人力，但是最终的设计将是高质量的，从而将减少对系统的修改要求。而且由于有完善的资料，这种修改也更容易实现。另一方面，根据个人所好而没有借助于系统开发方法学所设计的系统将不可避免地导致质量低和相当可观的维护成本。一个设计很差的系统的整个设计组被指派去以全部时间维护系统的情况并不少见。
数据库设计方法、规范与技巧 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式（信息世界模型），用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图（VIEW）形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法（Structured Analysis，简称SA方法）从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典（Data Dictionary，简称DD）来描述。 数据字典是各类数据描述的集合，它是关于数据库中数据的描述，即元数据，而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。 数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度， 取值范围，取值含义，与其他数据项的逻辑关系｝ 数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝ 数据流描述＝｛数据流名，说明，数据流来源，数据流去向， 组成:｛数据结构｝，平均流量，高峰期流量｝ 数据存储描述＝｛数据存储名，说明，编号，流入的数据流，流出的数据流， 组成:｛数据结构｝，数据量，存取方式｝ 处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝, 处理:｛简要说明｝｝ 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。 概念模型特点： (1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示: 2.1 第零步——初始化工程
一、准备工作: 1.准备好Windows XP Professional 简体中文版安装光盘 2.用纸张记录安装文件的产品密匙(安装序列号)。 3.没有有主板，显卡驱动光盘的情况下，用驱动程序备份工具(如:驱动精灵2004 预览版)将原Windows XP下的所有驱动程序备份到硬盘上(如∶F:\Drive)。最好能记下主板、网卡、显卡等主要硬件的型号及生产厂家，预先到驱动之家下载驱动程序备用,如不会查看硬件型号，用驱动精灵或硬件精灵都可以帮你查看到准确的硬件信息。 4.如果你想在安装过程中格式化C盘或D盘(建议安装过程中格式化C盘)，请备份C盘或D 盘有用的数据到其他分区。 5.把你的ADSL网络连接用的账号和密码记下来，装完系统要用，不过要是没记，可以打当地客服电话询问。 二、设置用光盘启动系统: (如果你已经知道方法请转到下一步) 计算机启动还在自检(屏幕为黑屏白字，同时在屏幕右上角还显示一个图标)时按住键盘上的“Del”键，即可进入“CMOS Setup Utility”界面，利用光标移动键选择“Advanced BIOS Features”，敲回车键进入该项设置并选择“First Boot Device”项，利用“Page Up”或“Page Down”两个键将它修改为相应项，即如果你用光盘启动则更改为“CDROM”，而若用软盘启动则应修改为“Floppy”；最后按F10键并敲回车键保存设置后退出BIOS设置。然后放入相应启动盘便可从该盘进行启动了。 如下图：
设置为光驱启动后按F10保存后，在光驱中放入系统安装光盘，重启后在出现CD。。。。字样时按回车键可进入系统安装画面，如看不到CD。。。字样，说明还不是光驱启动。请重新到BIOS里设置。
信息系统开发的几个方法 【内容提要】 在信息系统的开发中存在一个误区，认为信息系统的开发过程是一个纯粹的技术过程，没有正确认识到用户和开发人员之间的关系，以及探讨信息系统开发的重要性。实际上，信息系统的开发过程是一个非常复杂的过程，在本文中对信息系统开发周期进行简单介绍，重点讨论了目前常用的三种信息系统的开发方法，尤其是面向对象开发方法，具有较高的使用价值。 【关键词】信息系统原型法结构化法面向对象法 一、概述 随着信息技术的迅速发展和应用范围的不断扩大，信息系统对社会和经济的影响也日益深入。信息系统的开发是一项复杂的系统工程，它不仅涉及计算机技术，还涉及管理业务、组织和行为。一个好的信息系统能大大提高管理效率。信息系统的开发过程是一个用户、管理者、系统分析员、技术人员、程序员等参与者相互影响、相互联系的过程。 二、信息系统的生命周期 任何事物都有产生、发展、成熟、消亡的过程，信息系统也一样有它的生命周期。信息系统在使用过程中随着生存环境的变化，需要不断的维护、修改，直到它不再适应的时候就要由新系统代替老系统，这样的周期循环就被称为信息系统的生命周期。信息系统的生命周期划分为五个阶段：系统规划、系统分析、系统设计、系统实施、系统运行与维护。 其中后四个阶段构成了一个项目开发周期，这个周期是在周而复始的进行着。一个系统开发完成后，随着内外部环境的变化，会不断地积累新的问题，当问题积累到一定程度的时候就需要重新进行系统分析，开始新的系统开发，必要时还要重新进行系统规划。 1、系统规划 系统规划阶段的主要任务是根据企业目标和发展战略，对系统的需求做出分析和预测，研究系统的必要性和可能性，确定信息系统的目标和主要结构，根据需要和可能给出拟建系统的备选方案，并对备选方案进行可行性分析，写出可行性报告。可行性报告审议通过后，将新系统建设方案及设施计划写成系统设计任务书。 2、系统分析 系统分析阶段的主要任务是解决系统“做什么”的问题。根据系统设计任务书，对现行系统进行详细调查，进行分析，确定新系统的基本目标和逻辑功能要求，提出新系统的逻辑模型。其中的分析包括业务流程，分析数据流程，分析功能与数据之间的关系，提出分析处理方式。 系统分析阶段的工作成果体现在系统分析说明书中，它描述了所有管理层和用户的要求。用户通过系统分析说明书可以了解未来系统的功能，判断是不是其所要求的系统。系统分析说明书一旦讨论通过，就是系统设计的依据，也是将来验收系统的依据。这一阶段是系统开发的关键阶段。 3、系统设计 系统设计阶段要回答的问题是系统“怎么做”的问题。这个阶段的主要任务是根据系统分析阶段确定的方案，按照系统的功能要求，结合实际条件，设计实现系统。这个阶段又可分为总体设计和详细设计两个阶段。总体设计的主要任务包括构造信息系统应用软件的总体结构、系统硬件结构、系统配置方案等，详细设计包括人机界面设计、数据库设计等。这个阶段的技术文档是系统设计说明书。 4、系统实施 系统实施阶段是将设计的系统付诸实施的阶段，这一阶段的任务包括计算机等设备的购
文件编号：YS- 保密级别：内部文件- 威海易尚网络科技有限公司 威海易尚网络科技有限公司技术部 2015-8-15
客户名称、项目名称建设方案 一、项目背景简述 二十一世纪，网络与通信技术呈现迅猛的发展势头，在短短几年之内，智能终端使用率几乎覆盖了整个有效社会群体的99%以上，其速度之快，令人咋舌。就在我们惊诧之际，我们还看到了微信、网购,智能生活等各种网络应用，在人们生活的方方面面，它们是以什么样的惊人的几何倍速，正在增长着。 应该说，我们已经见证了网络和通信所带来的前所未有的市场效益，我们感叹它的巨大力量以及发展潜力。但我们是否想过，能否将这些为我所用，使之产生有利于企业的效应？ 即便是在现在，对很多企业来说，这仍旧是一个具有前瞻性的问题。这是一种挑战，一种机遇，是一种资源，更是一种方向！ 我们看到，有实力的企业已经着手去考虑如何有效的依托网络技术，结合当前成熟的应用程序和功能，去抓住这样一组资源和数据了。毫无疑问，在合理的运作下，这必将为他们带来额外的诸多效益。 下边是几组针对操作提醒功能数据： （1）大型的银行，网银操作具有提醒功能； （2）知名的支付机构，资金操作具有短信提醒功能；
（3）知名的网购平台，订单操作具有相应的提醒功能。 二、需求与可行性分析 根据客户名称（修改后请更正颜色）初期提出的需求文档，以及与客户进行的几次沟通，我们认为客户自主开发企业数据库并基于此建立CRM 系统已刻不容缓。 A、需求分析 （1）随着时间的经年更迭，旧系统所拥有的功能，已无法满足当前主流顾客软需求。 （2）限于早期的互联网技术手段，旧系统无法为当前的企业营销提供足够的数据支持和辅助作用。 （3）有数据表明，智能移动终端使用群体约等于年轻一代的消费群体，并与当前优质消费群体存在大部分重合，他们已逐步成为消费者主力军。 B、可行性论证 （1）网络技术、数据库技术，通信与相应的软件技术已经成熟。 （2）于企业内部建立管理系统已经非常普遍。 （3）企业建立DBCENTER并有效利用，长远的看，能达到提升效率、节约成本，提升综合竞争力的目标。 （4）基于互联网开放标准的数据服务已经非常成熟，能与SC程序媲美。 三、关键技术 数据库，触发器，web服务，接口技术；
一步步教你如何提高XP系统的运行速度 很多人的电脑都安装的是XP系统，该系统的运行速度会随着时间的推移会越来越慢，有的朋友可能会想到重装系统，但重装后，那么多的应用软件也要重新安装，这就不得不花费很多时间。如何在不安装系统的前提下提高XP系统的运行速度呢？你尝试按以下九个方面进行操作，你的XP系统一定会重新高速运行。 1、加快开、关机速度 在WindowsXP中关机时，系统会发送消息到运行程序和远程服务器，告诉它们系统要关闭，并等待接到回应后系统才开始关机。加快开机速度，可以先设置自动结束任务。 首先找到HKEY_CURRENT_USERControlPanelDesktop，把AutoEndTasks的键值设置为1；然后在该分支下有个“HungAppTimeout”，把它的值改为“4000(或更少)，默认为50000； 最后再找到HKEY_LOCAL_MACHINESystemCurrentControlSetControl，同样把WaitToKillServiceTimeout设置为“4000”；通过这样设置关机速度明显快了不少。 2、提升启动速度 要加快WindowsXP的启动速度。可以通过修改注册表来达到目的,在注册表编辑器，找到 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSessionManagerMemoryManagementPrefetchParame ters，在右边找到EnablePrefetcher主键，把它的默认值3改为1，这样滚动条滚动的时间就会减少； 3、加快菜单显示速度 为了加快菜单的显示速度，我们可以按照以下方法进行设置：我们可以在 HKEY_CURRENT_USERControlPanelDesktop下找到“MenuShowDelay”主键，把它的值改为“0”就可以达到加快菜单显示速度的效果。 4、宽带网速的提高 专业版的WindowsXP默认保留了20%的带宽，其实这对于我们个人用户来说是没有什么作用的。尤其让它闲着还不如充分地利用起来。 在“开始→运行”中输入gpedit.msc，打开组策略编辑器。找到“计算机配置→管理模板→网络→QoS 数据包调度程序”，选择右边的“限制可保留带宽”，选择“属性”打开限制可保留带宽属性对话框，选择“启用”，并将原来的“20”改为“0”，这样就释放了保留的带宽。（此技术可能无效） 5、优化网上邻居 WindowsXP网上邻居在使用时系统会搜索自己的共享目录和可作为网络共享的打印机以及计划任务中和网络相关的计划任务，然后才显示出来，这样速度显然会慢的很多。这些功能对我们没多大用的话,可以将其删除。在注册表编辑器中找到 HKEY_LOCAL_MACHINEsofewareMicrosoftWindowsCurrentVersionExploreRemoteComputerNameSpace，删除其下的(打印机)和{D6277990-4C6A-11CF8D87-00AA0060F5BF}(计划任务)，重新启动电脑，再次访问网上邻居，你会发现快了很多。 6、自动关闭停止响应程序 有些时候，XP会提示你某某程序停止响应，很烦，通过修改注册表我们可以让其自行关闭，在HKEY_CURRENT_USERControlPanelDesktop中将字符健值是AutoEndTasks的数值数据更改为1，重新注销或启动即可。 7、清除内存中不被使用的DLL文件 在注册表的HKKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersion，在Explorer增加一个项AlwaysUnloadDLL，默认值设为1。（注：如由默认值设定为0则代表停用此功能。） 8、改善系统预读能力 WindowsXP预读设定可提高系统速度，加快开机速度。按照下面的方法进行修改可进一步善用CPU的
信息系统开发方式 一、各类开发方式 （一）自行开发 优点：可以得到适合本单位的满意的系统，通过系统开发培养自己的力量。 缺点：往往开发周期较长。需要强有力的领导，有足够的技术力量，需要进行一定的咨询。 （二）委托开发 优点：比较省事（从用户角度）。 缺点：必须配备精通业务的人员参加，经常检查、协调。开发费用较高，系统维护困难。 （三）购买现成软件包 优点：最省事（从用户角度）。 缺点：要买到完全适合本单位的、满意的系统不太容易。需要有较强的鉴别能力，谈不上系统维护。 （四）联合开发 优点：对于培养自己的技术力量最为有利，系统维护比较方便。 缺点：双方要精诚合作，自己有一定系统分析和设计力量 信息系统开发方法 一、结构化系统开发方法 （一）基本思想 自行开发用系统工程的思想和工程化的方法，按用户至上的原则，结构化、模块化、自顶向下地对系统进行分析与设计。即先将整个开发过程分为若干个相对独立的阶段（分析、设计、实施），在前二个阶段坚持自顶向下地对系统进行结构化划分、设计，在系统实施阶段则应坚持自底向上地逐步实施。 （二）特点: 1.自顶向下整体性的分析与设计和自底向上地逐步实施的系统开发过程 2.用户至上 3.深入调查研究 4.严格区分工作阶段 5.充分预料可能发生的变化 6.开发过程工程化 （四）优缺点: 1.优点: (1)强调系统开发过程的整体性和全局性，强调在整体化的前提下来考虑具体的分析设计问题，即自顶向下的观点。 (2)强调严格地区分开发阶段，强调一步一步地严格地进行系统分析和设计，每一步工作都及时地总结，发现问题及时地反馈和纠正，从而避免了开发过程的混乱状态。2.缺点： （1）起点太低，所用的工具落后，致使系统开发周期过长，会带来许多问题。 （2）要求开发者在调查中就充分掌握用户需求、管理状况以及可能发生的变化，这不太符合人们循序渐进地认识事物的规律性，在实际工作中实施有一定的困难。 二、原型化法
XP系统下Internet信息服务IIS的安装方法 1、控制面板里没有“->添加/删除Windows组件->Internet信息服务（IIS）”组件的添加方法。 (某些GHOST系统精简后没有此项******不是所有的GHOST系统都需要进行这一步) 把IIS列进系统组件并安装。先到网上下载iis5.安装包，解压到D盘的根目录下（最好是根目录，便于后面打命令）把目录名该为iis51 首先在“开始”菜单的“运行”中输入“c:\Windows\inf\sysoc.inf”，在sysoc.inf中找到“[Components]”这一段，在里面加上这段：“iis=iis2.dll,OcEntry,iis2.inf,,7”,之后保存并关闭。 接下来，在运行中输入“CMD”然后回车，打开命令行模式，在命令行下输入下列的两条命令，在每一行命令结束后回车： expand d:\iis51\iis.dl_ c:\Windows\system32\setup\iis2.dll expand d:\iis51\iis.in_ c:\Windows\inf\iis2.inf 添加.删除windows组件时出现无法打开信息文件iis.inf 添加.删除windows组件时出现无法打开安装文件iis.dll （下载相关的文件,这里的压缩包是我安装时搜集的！到上面提到的相应目录中，即可） 注意如果你解压到了F盘就把上面的D改为F就可以了，其他同理。这时候，你打开控制面板－＞添加/删除Windows组件，就会发现，Internet信息服务（IIS）的安装选项已经出现在安装列表里了。 之后就和平常安装IIS一样了，只不过，在安装的过程中会出现找不到文件的情况（这是正常的，因为你的IIS安装目录没在XP默认的目录下）。这时，你点吉浏览，选择你刚刚解压的目录就可以了，这种让你选择安装文件的现象共会出现几次。过一会，IIS就安装完成了，点击“完成”。但做到这一步还不算完，因为是安装包安装的，需要对IIS进行一些设置（不然会出现内部服务器500错误)。 2、解决数据库链接错误的方法 打开开始--所有程序--管理工具--组件服务，在左边选择“控制台根目录”－>"组件服务"->"计算机"->"我的电脑"－>"COM+应用程序", 然后在右边框里点右键"IIS Out-Of-Process Pooled Applications ",选择属性，点“标识”选项卡，选择“系统帐户”，然后确定，重启IIS 即可。 3、无法进入“控制台根目录”－>"组件服务"->"计算机"->"我的电脑"－>"COM+应用程序"的
1 管理信息系统概述 1.1 管理信息系统定义 管理信息系统也是一种系统，是一种信息系统，是组织(企业)系统的一个子系统。管理信息系统掌握同企业有关的各种事件和对象的信息，并将这种信息提供给企业内外的系统用户。为了达到提供有用信息的目的，系统内必须实现某些过程，特别是信息联系过程和变换过程。系统接收各种数据，将它们转变为信息，将数据和信息加以存贮并将信息提供给用户。管理信息系统并不直接参与决策过程，它的任务主要是提供信息作为决策过程中的参考。但是，就象有些日常事务的决定可以由电子计算机做出一样，信息系统也可参与决策。这就使信息系统和决策过程之间失去明确的界限。 管理信息系统具备信息系统的功能。此外，它还具备其特有的计划、控制、预测和辅助决策功能. （1）计划功能。根据现存条件和约束条件，提供各职能部门的计划。如生产计划、财务计划、采购计划等。并按照不同的管理层次提供相应的计划报告。 （2）控制功能。根据各职能部门提供的数据，对计划执行情况进行监督、检查、比较执行与计划的差异、分析差异及产生差异的原因，辅助管理人员及时加以控制。 （3）预测功能。运用现代数学方法、统计方法或模拟方法，根据现有数据预测未来。 （4）辅助决策功能。采用相应的数学模型，从大量数据中推导出有关问题的最优解和满意解，辅助管理人员进行决策。以期合理利用资源，获取较大的经济效益。
简言之，管理信息系统是一个以计算机为工具，具有数据处理、预测、控制和辅助决策功能的信息系统。 1．2管理信息系统一般模式 （1）执行控制子系统(下层) MIS中的执行控制子系统与企业中管理机构的基层管理相对应。该子系统一般包括：生产管理、材料管理、财务管理、销售管理、人事劳资管理、设备管理等子系统。执行控制子系统处理的数据量大，但数据都是规范的，处理过程和规则都是程序化的。该子系统常用的处理有：事务处理、报表处理、查询处理。常用的输出形式有账簿、表格、图形。 执行控制子系统的主要任务是： 理解并执行中层下达的指令。 处理(录入、存贮、计算、分类、汇总等)原始业务数据。 将汇总信息及执行中层指令的结果传至中层。 提供查询功能。 （2）管理控制子系统(中层) 管理控制子系统是为企业中层各管理部门和管理人员提供控制生产经营活动、制定资源分配方案、评价企业效益等项战术级管理所需的信息。该子系统在整个MIS中起着承上启下的作用。其主要任务是： 汇集下层传来的信息并结合环境信息，监督、控制低层的运行。 处理中层信息上传给高层，理解并执行高层下达的指令，必要时把高层指令分解并下达给低层执行。 提供查询功能。 （3）战略决策和计划子系统(高层)
文件编号： YS- 保密级别：内部文件- 威海易尚网络科技有限公司 威海易尚网络科技有限公司技术部 2015-8-15
客户名称、项目名称建设方案 一、项目背景简述 二十一世纪，网络与通信技术呈现迅猛的发展势头，在短短几年之内，智能终端使用率几乎覆盖了整个有效社会群体的99% 以上，其速度之快，令人咋舌。就在我们惊诧之际，我们还看到了微信、网购,智能生活等各种网络应用，在人们生活的方方面面，它们是以什么样的惊人的几何倍速， 正在增长着。 应该说，我们已经见证了网络和通信所带来的前所未有的市场效益， 我们感叹它的巨大力量以及发展潜力。但我们是否想过，能否将这些为我 所用，使之产生有利于企业的效应？ 即便是在现在，对很多企业来说，这仍旧是一个具有前瞻性的问题。 这是一种挑战，一种机遇，是一种资源，更是一种方向！ 我们看到，有实力的企业已经着手去考虑如何有效的依托网络技术， 结合当前成熟的应用程序和功能，去抓住这样一组资源和数据了。毫无疑 问，在合理的运作下，这必将为他们带来额外的诸多效益。 下边是几组针对操作提醒功能数据： （1）大型的银行，网银操作具有提醒功能；
（2）知名的支付机构，资金操作具有短信提醒功能； （3）知名的网购平台，订单操作具有相应的提醒功能。 二、需求与可行性分析 根据客户名称（修改后请更正颜色）初期提出的需求文档，以及与客 户进行的几次沟通，我们认为客户自主开发企业数据库并基于此建立CRM 系统已刻不容缓。 A、需求分析 （1）随着时间的经年更迭，旧系统所拥有的功能，已无法满足当前主流顾客软需求。 （2）限于早期的互联网技术手段，旧系统无法为当前的企业营销提供足够的数据支持和辅助作用。 （3）有数据表明，智能移动终端使用群体约等于年轻一代的消费群体，并与当前优质消费群体存在大部分重合，他们已逐步成为消费者主力军。 B、可行性论证 （1）网络技术、数据库技术，通信与相应的软件技术已经成熟。 （2）于企业内部建立管理系统已经非常普遍。 （3）企业建立 DBCENTER 并有效利用，长远的看，能达到提升效率、节 约成本，提升综合竞争力的目标。 （4）基于互联网开放标准的数据服务已经非常成熟，能与SC 程序媲美。三、关键技术
数据库设计的基本步骤 一、数据库设计的生存期 按照规范设计的方法，考虑到数据库及其应用系统开发的全过程，将数据库设计分为六个阶段。如下图。 ①需求分析 需求收集和分析，得到用数据字典描述的数据需求，用数据流图描述的处理需求。 ②概念结构设计 对需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型（用E-R图表示）。 ③逻辑结构设计 将概念结构转换为某个DBMS所支持的数据模型（例如关系模型），并对其 进行优化。 ④物理结构设计 为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。 ⑤数据库实施
运用DBMS提供的数据语言（例如SQL）及其宿主语言（例如C），根据逻 辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。 ⑥数据库运行和维护 数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。 说明：设计一个完善的数据库应用系统是不可能一蹴而就的，它往往是上述六个阶段的不断反复。 二、数据库设计阶段的内容 设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程。下面针对各阶段的设计内容给出各阶段的设计描述。如下图。 三、数据库设计阶段的模式 数据库结构设计的不同阶段形成数据库的各级模式，如下图。 需求分析阶段：综合各个用户的应用需求；
概念设计阶段：形成独立于机器特点，独立于各个DBMS产品的概念模式，即E-R图； 逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关 系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图，形成数据的外模式； 物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式。