??xml version="1.0" encoding="utf-8" standalone="yes"?>
一.文档准备
验收之前Q项目组要准备好以下几类文档Q?/span>
1.开发ȝ文档
2.需求文档:包括需求规D明书Q需求变更文档等
3.设计文档Q包括概要设计,详细设计Q数据库设计{?br />
4.试文档Q包括测试方案,内部试报告Q第三方试报告{?br />
5.实施文档Q包括实施,部vҎQ用h册,l护手册{?br />
6.q程文档Q包括项目周报,会议U要{?/span>
以上文档可以参考国家标准或行业标准q行准备Q需要说明的是,1-5可以在后期补,W?在后期补就比较ȝQ因此在目开发过E中要注意整理这cL档。另外,q要仔细阅读合同及相关采购文Ӟ看其中是否还提到需要其它文档?/span>
q些文档可以装订在一PZl客户及专家一个很好的印象Q有以下几个装订技巧:
1.如果文档总页数太,单面打华ͼ反之可以双面打印QM要给ZU很厚,很充实的感觉?br />
2.设计一个漂亮的Q彩色封面,彩打出来?br />
3.做一个ȝ录,列明q䆾材料包括以上哪些部分。例如:W?/7部分 目开发报?W?/7部分 目需求规D明书
4.每个部分之间用硬皮纸或突出的标签分开Q如果用H出标签Q在标签上注明那部分的标?br />
5.最好在书脊上印上标?br />
6.开会前问客戯装订多少?/span>
目验收会前Q还要提前发l客户以下几份材?
1.我方参加验收会的名单Q便于客户宣?br />
2.验收意见
3.会议议程
另外Q在验收会上Q还需要带上项目过E中{v的文档备查,例如合同原gQ盖单的用户需求规D明书原g{等?/span>
?ppt准备
验收时的ppt一般包括以下几个部分:
1.目背景和简?br />
2.合同执行情况汇报
3.开发过E:记录目开发过E中的一些重要事?br />
4.pȝ功能
5.或应用成?br />
6.pȝ演示(在ppt上列明要演示哪些内容Q然后一个一个对照演C?
在做pȝ演示Ӟ注意要以业务程为演C重点,用流E将功能点串h?/span>
?pȝ准备
开会时需要对pȝq行演示Q因此开会前要保证系l的E_和速度。注意事如下:
1.量安装多一套系l在W记本上Q以防不?br />
2.Ҏ|络情况看是否需要带无线上网卡等讑֤?br />
2.设计好几个演C流E,一般不可能演示pȝ的全部功能,因此通过q几个典型流E可以全面反映系l的功能。准备这几个程时要准备好脚本和数据Q务必保证演CE中数据完整Q出现的界面没有伤Q例如出错,囄丢失{等?br />
3.演示完这几个程后,再挑一些系l的亮点q行演示。注意这个顺序,不要一上来演C基信息理Q客h兛_的是q个pȝ的核心业务?br />
4.把这几个程和亮点写在ppt上,让大家可以看C正在演示什么内宏V?/span>
?演示前准?/strong>
1.开会前一天把ppt准备好,自己试讲臛_两遍Q也可以邀请同事试听ƈl意见?br />
2.把系l准备好Q重要功能复查几ơ,保不出?br />
3.开会时提前一个小时到开会地点,布置会场及准备演C环境?br />
4.看情冉|否需要带数码相机Q移动硬盘,交换机,|线{物品?br />
5.指定同事做会议记录?/span>
按以上要求准备验收会议,验收成功q你不q了。验收成功后Q高兴之余,不要忘了做以下几件事Q?/span>
1.带回用户验收意见
2.打印版和电子版的验收文档拿回公司归?br />
3.写会议纪要,把后l要l箋跟进事项记录好,如果有图片,也一起发上吧
目理q程l包括:
² 启动q程l:定义q批准项目或阶段
n 制定目章程
n 制度目范围说明书(初步Q?/span>
² 规划q程l:定义和细化目标,规划最佌动方案,以实现项目或阶段所承担的目标和范围?/span>
n 制定目理计划
n 范围计划~制
n 范围定义
n 创徏工作分解l构Q?/span>WBSQ?/span>
n zd定义
n zd排序
n zd资源估算
n zd历时估算
n 制定q度计划
n 成本估算
n 成本预算
n 质量计划~制
n 人力资源计划~制
n l徏目团队
n 沟通计划编?/span>
n 风险理计划~制
n 风险识别
n 定量风险分析
n 制定风险应对计划
n 计划采购
n ~制合同
² 执行q程l:整合人员和其他资源,在项目的生命期或某个阶段执行目理计划?/span>
n 指导和管理项目执?/span>
n 执行质量保证
n 目团队
n 信息发布
n 获取供方相应
n 选择供方
² 监控q程l:要求定期量和监控进展,识别与项目管理计划的偏差Q以便在必要旉取纠正措施,保目或阶D늛标达成?/span>
n 监督和控刉目工?/span>
n 整体变更控制
n 范围验证
n 范围控制
n q度控制
n 成本控制
n 执行质量控制
n 理目团队
n l效报告
n 理目关系?/span>
n 风险监督和控?/span>
n 合同理
² 收尾q程l:正式接受产品、服务或工作成果Q有序的l束目或阶Dc?/span>
n 目收尾
n 合同收尾
同项目管理各q程有关的基本概念之一?#8220;计划—执行—检查—行?#8221;循环?/span>
目q程l和目理知识领域映射关系Q?/span>
目理q程l?/span> 知识领域 |
启动理q程l?/span> |
计划q程l?/span> |
执行q程l?/span> |
监督和控制过E组 |
收尾q程l?/span> |
目整体理 |
制定目章程 制度目范围说明书(初步Q?/span> |
目理规划 |
指导理目执行 |
监控和控刉目工?/span> 整体变更控制 |
目收尾 |
目范围理 |
范围规划 范围定义 建立WBS |
范围验证 范围控制 |
|||
目旉理 |
zd定义 zd排序 zd资源估算 zd历时估算 制定q度计划 |
q度控制 |
|||
目成本理 |
成本估算 成本预算 |
成本控制 |
|||
目质量理 |
质量规划 |
执行质量保证 |
执行质量控制 |
||
目人力资源理 |
人力资源计划~制 团队l徏 |
团队 |
团队理 |
||
目沟通管?/span> |
沟通计划编?/span> |
信息发布 |
l效报告 q系人管?/span> |
||
目风险理 |
风险理计划~制 风险识别 定性风险分?/span> 定量风险风险 风险响应规划 |
风险监控 |
|||
目采购理 |
采购规划 计划{ |
h卖方回应 买房选择 |
合同理 |
合同执行 |
二?span style="font-family: 宋体">目生命期和l织
本章重点Q项目生命期、项目关pMh和组l的影响
信息pȝ目的生命期模型
1?nbsp;瀑布模型Q?/span>
一般将软g开发可以分为:可行性分析(计划Q、需求分?/span>?span style="background: #d9d9d9">软g设计Q概要、详l设计)、编码(含单元测试)、测?/span>?span style="background: #d9d9d9">q行l护{一个阶Dc(阴媄部分可看成定义阶Dc开发阶D和l护阶段Q?/span>
特点Q?/span>
² 从上一开发活动接受该Ҏ动的工作对象作ؓ输入
² 利用q一输入Q实施该Ҏ动应完成的工作内?/span>
² l出该项zd的工作成果,做ؓ输出传给下一开发活?/span>
² 对该Ҏ动的实施工作成果q行评审。若其工作成果得到确认,则l下一Ҏ动;否则q回前一,甚至更前?/span>
2?nbsp;q代模型Q?/span>
初始阶段Q?/span>pȝ地阐q项目的范围Q选择可行的系l架构,计划和准备业务案?/span>
l化阶段Q?/span>l化构想Q细化过E和基础设施Q细化构架ƈ选择构g
构造阶D:资源理、控制和q程最优化Q完成构件的开发ƈ依评h准进行测试,依构想的验收标准评估产品的发布?/span>
UM阶段Q?/span>同步qq发的构造增量集成到一致的实施基线中,与实施有关的工程zdQ商业包装和生、h员培训等Q,Ҏ完整的构惛_需求的验收标准评估实施基线?br />
3?nbsp;螺旋模型Q?/span>
是一个演化过E模型,原型实现的q代特征与线性顺序(瀑布Q模型中控制的和pȝ化的斚wl合h。得Y件的增量版本的快速开发成为可能。在螺旋模型中Y件开发是一pd的增量发布?br />
4个象限分别标志每个周期所划分的四个阶D:制定计划、风险分析、实施工E和客户评估。螺旋模型强调了风险分析?/span>
目q系人(Project StakeholderQ:也称利害相关者,是积极参与项目、或其利益因目的实施或完成而受到积极或消极影响的个人和l织Q他们还会对目的目标和l果施加影响?/span>
每个目都包括如下的目关键q系人:
² 目l理Q?/span>Project ManagerQ?/span>
² ֮、客PCustomer/UserQ?/span>
² 执行l织Q?/span>Performing OrganizationQ?/span>
² 目团队成员Q?/span>Project Team MembersQ?/span>
² 目理团队Q?/span>Project Management TeamQ?/span>
² 人(SponsorQ?/span>
² 有媄响力的hQ?/span>InfluencersQ?/span>
² 目理办公室(PMOQ?/span>
l织的结构:
l织cd 目特点 |
职能型组l?/span> |
矩阵型组l?/span> |
目型组l?/span> |
||
q阵型l织 |
q矩阵型组l?/span> |
强矩阵型l织 |
|||
目l理的权?/span> |
很小和没?/span> |
有限 |
?/span>~中等 |
中等~?/span> |
?/span>~全权 |
l织中全职参与项目工作的职员比例 |
没有 |
0%~25% |
15%~60% |
50%~95% |
85%~100% |
目l理的职?/span> |
部分旉 |
部分旉 |
全时 |
全时 |
全时 |
目l理的一般头?/span> |
目协调?/span>/目ȝ |
目协调?/span>/目ȝ |
目l理/目ȝ |
目l理/计划l理 |
目l理/计划l理 |
目理行政人员 |
部分旉 |
部分旉 |
部分旉 |
全时 |
全时 |
目Q提供某独特的产品、服务或成果所q行的时的一ơ性努力。是用有限的资源、有限的旉为特定客户完成特定目标的一ơ性工作?/span>
目的特点:临时性、独Ҏ和渐进性?/span>
信息pȝ目的特点:
² 目标不明?/span>
² 需求变化频J?/span>
² 智力密集?/span>
² 设计队伍庞大
² 设计人员高度专业?/span>
² 涉及的承包商?/span>
² 各承包商分布在各地Q互相联pd?/span>
² pȝ集成目中需研制开发大量的软硬件系l?/span>
² 目生命期通常较短
² 通常要采用大量的新技?/span>
² 使用与维护的要求非常复杂
目理的知识领域:
² 目理知识体系
² 应用领域知识、标准和规定
² 目环境知识
² 通用的管理知识和技?/span>
² 软技能(处理人际关系技能)
国际目理协会Q?/span>IMPAQ的目理专业人员资质认证分ؓ4U:
AU(Level AQ:认证的高U项目经理(Certificated Projects Director CPDQ,有能力指g个公司(或一个分支机构)Q包括有诸多目的负责规划,有能力管理该l织的所有项目,或者管理一国际合作的复杂目?/span>
BU:认证的项目经理(Certificated Projects Manager CPMQ,可以理一般复杂的目?/span>
CU:认证的项目管理专ӞCertificated Projects Management ProfessionalQ?/span>PMPQ能够管理一般的非复杂项目?/span>
DU:认证的项目管理专业h员(Certificated Projects Management PractitionerQ?/span>PMFQ具有项目管理的基本知识Qƈ可以他们应用于某些领域?/span>
目理的知识体p(Project Management Body of KnowledgeQ?/span>PMBOKQ,把项目管理划分ؓ9个知识领域: 范围理、时间管理、成本管理、质量管理、h力资源管理、沟通管理、采购管理、风险管理和整体理?/span>
寚w目经理的一般要求:
² q博的知?/span>
² 丰富的经?/span>
² 良好的协调能?/span>
² 良好的职业道?/span>
² 良好的沟通与表达能力
² 良好的领D?/span>
怎样做个好的目l理Q?/span>
² 真正理解目l理的角?/span>
² 重视目团队的管理,奖罚分明
² 计划、计划、再计划
² 真正理解“一把手工程”
² 切记注重用户参与
英文~写Q?/span>
PMOQ项目管理办公室Q?/span>
WBSQ?/span>Work Breakdown Structure 工作分解l构Q?/span>
CPMQ?/span>Critical Path MethodQ关键\径法Q?/span>
PERTQ?/span>Program Evaluation And Review TechniqueQ计划评审技术)
EVQ?/span>Earned Value 挣|
IPMA Q?/span>International Public Management Association 国际目理协会Q?/span>
ICBQ?/span>IMPA Competence Baseline 国际目理资质标准Q?/span>
IPMPQ?/span>International Project Management Professional 国际目理专业资质认证Q?/span>
先用rootdMYSQL服务器,执行
mysql>set password for dp_user@"localhost"=old_password('yourPassword');
原因是因Z使用的mysql服务器版本中使用了新的密码验证机Ӟq需要客L的版本要?.0以上Q原来的密码函数被改为old_password();Q这样用password()生成的密码在旧的版本上的客户端就不好使了Q而PHP中的MYSQL客户端都?.23?当然Qmysqli的扩展除?Q问题就在这了?/p>
q几天刚刚交付验收了一个政府的软g目Q在q个目的开发过E中遇到了不困难,包括技术上的障和一些实际的Zؓ上的问题。一个项目之所以能成功Q能让客h意,领导攑ֿ的原因可能大多都差不多,大多都是老生长谈的那几条。但是一个项目失败的原因却各有各的不同。下面再Ҏ自己的体会写一些项目ȝQ一Zȝ不Q积累经验,二ؓ了以后项目中避免犯同L错误?o:p>
一.要和客户有够有效的沟?o:p>
和客L沟通要贯穿整个目开发的始终Q从立项调研Q需求获取到最后的验收试Q后期维护?o:p>
1.要尽量多的主动跟客户沟?/SPAN>
客户一般工作都很忙Q所以要通过多种方式和客户保持沟通,电子邮gQ电话,座谈Q调查,会议{。最初的需求尽量保证有几次所有与目相关的部门和人员都能参加的讨ZQ把他们的各自的工作都描qC下,量不要遗漏Q都|列出来Q因是原始需求。这往往不容易做刎ͼ因ؓ政府部门很难抽出旉把各部门人员集中在一h做这些事情的Q但是我们必dq样要求他们Q要求他们把q个看成一工作来抓,因ؓ前期工作做不充分Q后面的开发会不会很成功。在Ҏ个功能或者需求不能确定的情况下,最好能整理成列表文档发l客P让客户以电子版的形式重新描述一下发q来Q尽量不要经常打电话骚扰客户Q要集中把要了解东西发给客户Q以便他们集中精力来处理你问的问题?o:p>
2.要尽量保证有效的沟?/B>
每次沟通要有一定的目的性,把沟通交的l果用文档的形式保存下来Q需求制订出来要得到客户的确认,在经q几ơ反复之后会得到一个相Ҏ较稳定的需求,虽然客户的需求不可能一直不变,q也是很多h搞项目头疼的地方Q但是我认ؓ客户的需求实际上是很改变的Q改变的是你对客户需求的理解。对客户的每一个要求都要重视,其是客户后来提到的一些改动徏议,要让他们以书面的形式发过来,必要的时候要求负责h盖章{֭Q我们不能ؓ了下面的下面的一个小办事员随便打个电话就对程序做出大的改动。再改动比较大的情况下,我们可以要求客户对合同的变更q加费用Q前提是把需求做为合同的附g加进去,防治最后验收的时候造成争执?o:p>
3.和客h通要扑և对象
一般企业或者政府都有专门负责信息的人员Q而且最好要求客户那Ҏ一个h专门负责q个目。这hҎ了解需求的时候就不会出现不知道找谁的情况Q客户那Ҏ专h负责会带来很多好处,q个目是因ؓ客户那边负责q个目的h员经常更换而ؓ我们目的开发造成了很多的不变?o:p>
?提高开发效率和保证目质量
政府的项目一般都是开始的时候不着急,你催他们准备资料他们也不着急,但是一旦他们把资料准备全了Q都交给你了q急了Q要求对方在很短的时间内保证质量的把目交付。所以如何提高开发效率和保证目质量是确保项目成功的关键?o:p>
1.保证良好充分的测?o:p>
当然软g试的范畴很大,但是Z赶进度我们往往不能不保证进行所有的软g试。Y件的试也是遍布整个目开发周期的Q我了解了一下TDDQTDD的思想很好Q很适合开发中型的项目,实施h也很方便Q但是不能纯_的用敏捷开发的理论Q必要的文档q是需要的。我认ؓ代码模块的单元测试,开发最后阶D늚集成试和部|后的整体功能测试和用户验收试是必不可的。项目进度再紧张也要q行单元试Q只要保证单元测试能通过Q以后代码可以慢慢重构。集成测试保证项目各个模块能良好的协作共同完成复杂的dQ这点不能保证的话,展示l客L最l功能就不能保证。而功能测试和用户验收试是纯_的黑盒试Q自己内部h员先对照原始客户的需求进行功能测试,列出BUG列表Q经q几ơ反复修改后l客户一个可以进行验收测试的pȝ?o:p>
2.保证相对必要的文档以及保证文档的可用?/B>
每个模块的文档要独立hQ要实现的目标,试的结果,模块所用的数据库的l构Q存储过E,设计思\Q调用的接口{这些是必须的。我也不面面俱到的文档,但必要的需求文档,模块文档Q测试文档是必须的,我们的项目小的不以让我们去学习庞大的RUP什么的?o:p>
3.q代开?/B>
刚开始可以根据客L需求弄Z个蓝图来Q交l客LQ以便让客户能尽量早的知道最l的开发出来的pȝ是什么样子的Q这个蓝图要量直观Q一般在需求整理完毕后一周就能出来,q也是指g后开发工作的东西Q要完整的包含所有的域模型,便于开发h员对问题域的理解。然后把优先U最高的一pd功能完整后出一个DEMO版给客户Q要让客户尽量早的发现正在制作的目和用h要的l果的之间的偏离和差距,告诉你后以便你尽早的调整Q别{你的正式版出来后用户发现这个功能你做的不对Q你傻了,那时候要改动的地方就太多了。然后再弄完善一下给用户个beta版,q时候就已经接近最l版本了Q可能还有一些小BUG。最后把BUG完善修复一下给客户正式?.0让客户验收。至于二期项目以后再_先把一期项目的余款l了再说Q对吧?o:p>
4.制订开发规?o:p>
开发规范订的太M限制E序员,每个开发h员都会有一些习惯,但是Z协作Q制订一个相寚w用的规范是有必要的。包括文档的规范Q数据库设计规范Q编码规范以及各U命名规则。尽量用一些业界通用的规范,|上都有Q我CSDN的博客上也整理了一些,MSDN的类库开发h员指南里面也有一些。尽某些规范很有争议,我感觉你也得选择其中一U来做ؓ你的目开发规范?o:p>
5.建立开发基
保证机器和Y件的可用Q尽量大的内存,量快的处理器,操作pȝQ开发工具都要到位,该想到的得惛_Q还要给开发h员一个相对安静舒适的环境Q最好能很方便的喝到冰箱里的可乐Q而且能在累的时候有l色的植物看。再一个就是徏立一个开发基l构Q这个也颇有争议Q几乎每个公叔R有自qpȝcdQ开发框架以及配套的代码生成工具Q这都很好,在开始可以对员工做适当的培训,让他们都能体验自底向上设计的好处Q都能用的上q个架构Q你可以在架构中要求开发h员以指定的方式实现某些通用的Q务,比如说日志记录和错误处理{,而不是让他们使用自己习惯的方式去处理问题Q因?NET的灵zL让实现一个Q务有很多中方案和手段?o:p>
节Q虽然这个帖子没有讨论具体技术,而且都是一些空话套话,q且q些I套话可能别h也都说的不带说了Q但我感觉还是有必要自己ȝ一下的?BR>
http://onlytiancai.cnblogs.com/archive/2005/11/03/218335.html