一.文档准备

验收之前，项目组要准备好以下几类文档：

1.开发总结文档
2.需求文档：包括需求规格说明书，需求变更文档等
3.设计文档：包括概要设计，详细设计，数据库设计等
4.测试文档：包括测试方案，内部测试报告，第三方测试报告等
5.实施文档：包括实施，部署方案，用户手册，维护手册等
6.过程文档：包括项目周报，会议纪要等

以上文档可以参考国家标准或行业标准进行准备，需要说明的是，1-5项可以在后期补，第6项在后期补就比较麻烦，因此在项目开发过程中要注意整理这类文档。另外，还要仔细阅读合同及相关采购文件，看其中是否还提到需要其它文档。

这些文档可以装订在一起，为了给客户及专家一个很好的印象，有以下几个装订技巧：

1.如果文档总页数太少，就单面打印，反之可以双面打印，总之要给人一种很厚，很充实的感觉。
2.设计一个漂亮的，彩色封面，彩打出来。
3.做一个总目录，列明这份材料包括以上哪些部分。例如：第1/7部分 项目开发报告 第2/7部分 项目需求规格说明书
4.每个部分之间用硬皮纸或突出的标签分开，如果用突出标签，在标签上注明那部分的标题
5.最好在书脊上印上标题
6.开会前问客户要装订多少份

项目验收会前，还要提前发给客户以下几份材料:

1.我方参加验收会的名单，便于客户宣读
2.验收意见
3.会议议程

另外，在验收会上，还需要带上项目过程中签署的文档备查，例如合同原件，盖单的用户需求规格说明书原件等等。

二.ppt准备

验收时的ppt一般包括以下几个部分：

1.项目背景和简介
2.合同执行情况汇报
3.开发过程：记录项目开发过程中的一些重要事件
4.系统功能
5.建设或应用成果
6.系统演示(在ppt上列明要演示哪些内容，然后一个一个对照演示)

在做系统演示时，注意要以业务流程为演示重点，用流程将功能点串起来。

三.系统准备

开会时需要对系统进行演示，因此开会前要保证系统的稳定和速度。注意事项如下：

1.尽量安装多一套系统在笔记本上，以防不测。
2.根据网络情况看是否需要带无线上网卡等设备。
2.设计好几个演示流程，一般不可能演示系统的全部功能，因此通过这几个典型流程可以全面反映系统的功能。准备这几个流程时要准备好脚本和数据，务必保证演示过程中数据完整，出现的界面没有硬伤，例如出错，图片丢失等等。
3.演示完这几个流程后，再挑一些系统的亮点进行演示。注意这个顺序，不要一上来就演示基础信息管理，客户更关心的是这个系统的核心业务。
4.把这几个流程和亮点写在ppt上，让大家可以看到你正在演示什么内容。

四.演示前准备

1.开会前一天把ppt准备好，自己试讲至少两遍，也可以邀请同事试听并给意见。
2.把系统准备好，重要功能复查几次，确保不出错
3.开会时提前一个小时到开会地点，布置会场及准备演示环境。
4.看情况是否需要带数码相机，移动硬盘，交换机，网线等物品。
5.指定同事做会议记录。

按以上要求准备验收会议，验收成功就离你不远了。验收成功后，高兴之余，不要忘了做以下几件事：

1.带回用户验收意见
2.将打印版和电子版的验收文档拿回公司归档
3.写会议纪要，把后续要继续跟进事项记录好，如果有图片，也一起发上吧

项目管理过程组包括：

² 启动过程组：定义并批准项目或阶段

n 制定项目章程

n 制度项目范围说明书（初步）

² 规划过程组：定义和细化目标，规划最佳行动方案，以实现项目或阶段所承担的目标和范围。

n 制定项目管理计划

n 范围计划编制

n 范围定义

n 创建工作分解结构（WBS）

n 活动定义

n 活动排序

n 活动资源估算

n 活动历时估算

n 制定进度计划

n 成本估算

n 成本预算

n 质量计划编制

n 人力资源计划编制

n 组建项目团队

n 沟通计划编制

n 风险管理计划编制

n 风险识别

n 定量风险分析

n 制定风险应对计划

n 计划采购

n 编制合同

² 执行过程组：整合人员和其他资源，在项目的生命期或某个阶段执行项目管理计划。

n 指导和管理项目执行

n 执行质量保证

n 项目团队建设

n 信息发布

n 获取供方相应

n 选择供方

² 监控过程组：要求定期测量和监控进展，识别与项目管理计划的偏差，以便在必要时采取纠正措施，确保项目或阶段目标达成。

n 监督和控制项目工作

n 整体变更控制

n 范围验证

n 范围控制

n 进度控制

n 成本控制

n 执行质量控制

n 管理项目团队

n 绩效报告

n 管理项目关系人

n 风险监督和控制

n 合同管理

² 收尾过程组：正式接受产品、服务或工作成果，有序的结束项目或阶段。

n 项目收尾

n 合同收尾

同项目管理各过程有关的基本概念之一是“计划—执行—检查—行动”循环。

项目过程组和项目管理知识领域映射关系：

二、项目生命期和组织

本章重点：项目生命期、项目关系人和组织的影响

信息系统项目的生命期模型

1、 瀑布模型：

一般将软件开发可以分为：可行性分析（计划）、需求分析、软件设计（概要、详细设计）、编码（含单元测试）、测试、运行维护等一个阶段。（阴影部分可看成定义阶段、开发阶段和维护阶段）

特点：

² 从上一项开发活动接受该项活动的工作对象作为输入

² 利用这一输入，实施该项活动应完成的工作内容

² 给出该项活动的工作成果，做为输出传给下一项开发活动

² 对该项活动的实施工作成果进行评审。若其工作成果得到确认，则继续下一项活动；否则返回前一项，甚至更前。

2、 迭代模型：

初始阶段：系统地阐述项目的范围，选择可行的系统架构，计划和准备业务案例

细化阶段：细化构想，细化过程和基础设施，细化构架并选择构件

构造阶段：资源管理、控制和过程最优化，完成构件的开发并依评价标准进行测试，依构想的验收标准评估产品的发布。

移交阶段：同步并使并发的构造增量集成到一致的实施基线中，与实施有关的工程活动（商业包装和生产、人员培训等），根据完整的构想和需求的验收标准评估实施基线。

3、 螺旋模型：

是一个演化过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺旋模型中软件开发是一系列的增量发布。

4个象限分别标志每个周期所划分的四个阶段：制定计划、风险分析、实施工程和客户评估。螺旋模型强调了风险分析。

项目干系人（Project Stakeholder）：也称利害相关者，是积极参与项目、或其利益因项目的实施或完成而受到积极或消极影响的个人和组织，他们还会对项目的目标和结果施加影响。

每个项目都包括如下的项目关键干系人：

² 项目经理（Project Manager）

² 顾客、客户（Customer/User）

² 执行组织（Performing Organization）

² 项目团队成员（Project Team Members）

² 项目管理团队（Project Management Team）

² 出资人（Sponsor）

² 有影响力的人（Influencers）

² 项目管理办公室（PMO）

组织的结构：

项目：提供某项独特的产品、服务或成果所进行的临时的一次性努力。是用有限的资源、有限的时间为特定客户完成特定目标的一次性工作。

项目的特点：临时性、独特性和渐进性。

信息系统项目的特点：

² 目标不明确

² 需求变化频繁

² 智力密集型

² 设计队伍庞大

² 设计人员高度专业化

² 涉及的承包商多

² 各级承包商分布在各地，互相联系复杂

² 系统集成项目中需研制开发大量的软硬件系统

² 项目生命期通常较短

² 通常要采用大量的新技术

² 使用与维护的要求非常复杂

项目管理的知识领域：

² 项目管理知识体系

² 应用领域知识、标准和规定

² 项目环境知识

² 通用的管理知识和技能

² 软技能（处理人际关系技能）

国际项目管理协会（IMPA）的项目管理专业人员资质认证分为4级：

         A级（Level A）：认证的高级项目经理（Certificated Projects Director CPD），有能力指导一个公司（或一个分支机构），包括有诸多项目的负责规划，有能力管理该组织的所有项目，或者管理一项国际合作的复杂项目。

         B级：认证的项目经理（Certificated Projects Manager CPM），可以管理一般复杂的项目。

         C级：认证的项目管理专家（Certificated Projects Management Professional，PMP）能够管理一般的非复杂项目。

         D级：认证的项目管理专业人员（Certificated Projects Management Practitioner，PMF）具有项目管理的基本知识，并可以将他们应用于某些领域。

项目管理的知识体系（Project Management Body of Knowledge，PMBOK），把项目管理划分为9个知识领域：    范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、采购管理、风险管理和整体管理。

对项目经理的一般要求：

² 广博的知识

² 丰富的经营

² 良好的协调能力

² 良好的职业道德

² 良好的沟通与表达能力

² 良好的领导能力

怎样做个好的项目经理：

² 真正理解项目经理的角色

² 重视项目团队的管理，奖罚分明

² 计划、计划、再计划

² 真正理解“一把手工程”

² 切记注重用户参与

英文缩写：

PMO（项目管理办公室）

WBS（Work Breakdown Structure 工作分解结构）

CPM（Critical Path Method，关键路径法）

PERT（Program Evaluation And Review Technique，计划评审技术）

EV（Earned Value 挣值）

IPMA （International Public Management Association 国际项目管理协会）

ICB（IMPA Competence Baseline 国际项目管理资质标准）

IPMP（International Project Management Professional 国际项目管理专业资质认证）

先用root登录MYSQL服务器，执行

mysql>set password for dp_user@"localhost"=old_password('yourPassword');

　　原因是因为你使用的mysql服务器版本中使用了新的密码验证机制，这需要客户端的版本要在4.0以上，原来的密码函数被改为old_password();，这样使用password()生成的密码在旧的版本上的客户端就不好使了，而PHP中的MYSQL客户端都是3.23的(当然，mysqli的扩展除外)，问题就在这了。

　　近几天刚刚交付验收了一个政府的软件项目，在这个项目的开发过程中遇到了不少困难，包括技术上的障碍和一些实际的人为上的问题。一个项目之所以能成功，能让客户满意，领导放心的原因可能大多都差不多，大多都是老生长谈的那几条。但是一个项目失败的原因却各有各的不同。下面再根据自己的体会写一些项目总结，一为了总结不足，积累经验，二为了以后项目中避免犯同样的错误。

　　一.要和客户有足够有效的沟通

　　和客户的沟通要贯穿整个项目开发的始终，从立项调研，需求获取到最后的验收测试，后期维护。

　　1.要尽量多的主动跟客户沟通

　　客户一般工作都很忙，所以要通过多种方式和客户保持沟通，电子邮件，电话，座谈，调查，会议等。最初的需求尽量保证有几次所有与项目相关的部门和人员都能参加的讨论会，把他们的各自的工作都描述一下，尽量不要遗漏，都罗列出来，因为这是原始需求。这往往不容易做到，因为政府部门很难抽出时间把各部门人员集中在一起来做这些事情的，但是我们必须得这样要求他们，要求他们把这个看成一项工作来抓，因为前期工作做不充分，后面的开发会不会很成功。在对某个功能或者需求不能确定的情况下，最好能整理成列表文档发给客户，让客户以电子版的形式重新描述一下发过来，尽量不要经常打电话骚扰客户，要集中把要了解东西发给客户，以便他们集中精力来处理你问的问题。

　　2.要尽量保证有效的沟通

　　每次沟通要有一定的目的性，把沟通交流的结果用文档的形式保存下来；需求制订出来要得到客户的确认，在经过几次反复之后会得到一个相对比较稳定的需求，虽然客户的需求不可能一直不变，这也是很多人搞项目头疼的地方，但是我认为客户的需求实际上是很少改变的，改变的是你对客户需求的理解。对客户的每一个要求都要重视，尤其是客户后来提到的一些改动建议，要让他们以书面的形式发过来，必要的时候要求负责人盖章签字，我们不能为了下面的下面的一个小办事员随便打个电话就对程序做出大的改动。再改动比较大的情况下，我们可以要求客户对合同的变更追加费用，前提是把需求做为合同的附件加进去，防治最后验收的时候造成争执。

　　3.和客户沟通要找准对象

　　一般企业或者政府都有专门负责信息的人员，而且最好要求客户那边找一个人专门负责这个项目。这样找对方了解需求的时候就不会出现不知道找谁的情况，客户那边有专人负责会带来很多好处，这个项目就是因为客户那边负责这个项目的人员经常更换而为我们项目的开发造成了很多的不变。

　　二.提高开发效率和保证项目质量

　　政府的项目一般都是开始的时候不着急，你催他们准备资料他们也不着急，但是一旦他们把资料准备全了，都交给你了就着急了，要求对方在很短的时间内保证质量的把项目交付。所以如何提高开发效率和保证项目质量是确保项目成功的关键。

　　1.保证良好充分的测试

　　当然软件测试的范畴很大，但是为了赶进度我们往往不能不保证进行所有的软件测试。软件的测试也是遍布整个项目开发周期的，我了解了一下TDD，TDD的思想很好，很适合开发中小型的项目，实施起来也很方便，但是不能纯粹的用敏捷开发的理论，必要的文档还是需要的。我认为代码模块的单元测试，开发最后阶段的集成测试和部署后的整体功能测试和用户验收测试是必不可少的。项目进度再紧张也要进行单元测试，只要保证单元测试能通过，以后代码可以慢慢重构。集成测试保证项目各个模块能良好的协作共同完成复杂的任务，这点不能保证的话，展示给客户的最终功能就不能保证。而功能测试和用户验收测试是纯粹的黑盒测试，自己内部人员先对照原始客户的需求进行功能测试，列出BUG列表，经过几次反复修改后给客户一个可以进行验收测试的系统。

　　2.保证相对必要的文档以及保证文档的可用性

　　每个模块的文档要独立起来，要实现的目标，测试的结果，模块所用的数据库的结构，存储过程，设计思路，调用的接口等这些是必须的。我也不建议面面俱到的文档，但必要的需求文档，模块文档，测试文档是必须的，我们的项目小的不足以让我们去学习庞大的RUP什么的。

　　3.迭代开发

　　刚开始可以根据客户的需求弄出一个蓝图来，交给客户看，以便让客户能尽量早的知道最终的开发出来的系统是什么样子的，这个蓝图要尽量直观，一般在需求整理完毕后一周就能出来，这也是指导以后开发工作的东西，要完整的包含所有的域模型，便于开发人员对问题域的理解。然后把优先级最高的一系列功能完整后出一个DEMO版给客户，要让客户尽量早的发现正在制作的项目和用户想要的结果的之间的偏离和差距，告诉你后以便你尽早的调整，别等你的正式版出来后用户发现这个功能你做的不对，你就傻了，那时候要改动的地方就太多了。然后再弄完善一下给用户个beta版，这时候就已经接近最终版本了，可能还有一些小BUG。最后把小BUG完善修复一下给客户正式版1.0让客户验收。至于二期项目以后再说，先把一期项目的余款结了再说，对吧。

　　4.制订开发规范

　　开发规范订的太死会限制程序员，每个开发人员都会有一些习惯，但是为了协作，制订一个相对通用的规范是有必要的。包括文档的规范，数据库设计规范，编码规范以及各种命名规则。尽量用一些业界通用的规范，网上都有，我CSDN的博客上也整理了一些，MSDN的类库开发人员指南里面也有一些。尽管某些规范很有争议，我感觉你也得选择其中一种来做为你的项目开发规范。

　　5.建立开发基础

　　保证机器和软件的可用，尽量大的内存，尽量快的处理器，操作系统，开发工具都要到位，该想到的就得想到，还要给开发人员一个相对安静舒适的环境，最好能很方便的喝到冰箱里的可乐，而且能在累的时候有绿色的植物看。再一个就是建立一个开发基础结构，这个也颇有争议，几乎每个公司都有自己的系统类库，开发框架以及配套的代码生成工具，这都很好，在开始可以对员工做适当的培训，让他们都能体验自底向上设计的好处，都能用的上这个架构，你可以在架构中要求开发人员以指定的方式实现某些通用的任务，比如说日志记录和错误处理等，而不是让他们使用自己习惯的方式去处理问题，因为.NET的灵活性让实现一个任务有很多中方案和手段。

    小节：虽然这个帖子没有讨论具体技术，而且都是一些空话套话，并且这些空话套话可能别人也都说的不带说了，但我感觉还是有必要自己总结一下的。

http://onlytiancai.cnblogs.com/archive/2005/11/03/218335.html