㈠ java软件开发项目验收有什么需要注意的
依据我们开发java软件项目的经验，下面为大家介绍下验收时的注意事项，当系统经过一段试运行，具备验收的各项条件之后，我们就需要着手验收阶段的准备工作了。
我们需要把到目前为止完成的工作进行一个总结，列出我们已经完成
的各项目工作成果、各类文档，对合同以及各类约定的技术文档中的相关内容进行自查，要彻底了解系统目前完成的情况如何，是否已经完成了与客户方达成的各项书面约定以及口头约定。
在项目实施过程中注重里程碑的确定，制定阶段性目标如果要做好一个项目，完成项目的验收条件，主要还是以业务是否可用作为衡量的。
写好备忘录和问题跟踪记录
㈡ 常见软件故障的判断与解决方法。
§1.1 进行电脑维修应遵循的基本原则：
一、 进行维修判断须从最简单的事情做起
简单的事情，一方面指观察，另一方面是指简捷的环境。
简单的事情就是观察，它包括：
1、 电脑周围的环境情况——位置、电源、连接、其它设备、温度与湿度等；
2、 电脑所表现的现象、显示的内容，及它们与正常情况下的异同；
3、 电脑内部的环境情况——灰尘、连接、器件的颜色、部件的形状、指示灯的状态等；
4、 电脑的软硬件配置——安装了何种硬件，资源的使用情况；使用的是使种操作系统，其上又安装了何种应用软件；硬件的设置驱动程序版本等。
简捷的环境包括：
1、 后续将提到的最小系统；
2、 在判断的环境中，仅包括基本的运行部件/软件，和被怀疑有故障的部件/软件；
3、 在一个干净的系统中，添加用户的应用（硬件、软件）来进行分析判断
从简单的事情做起，有利于精力的集中，有利于进行故障的判断与定位。一定要注意，必须通过认真的观察后，才可进行判断与维修。
二、 根据观察到的现象，要“先想后做”
先想后做，包括以下几个方面：
首先是，先想好怎样做、从何处入手，再实际动手。也可以说是先分析判断，再进行维修。
其次是，对于所观察到的现象，尽可能地先查阅相关的资料，看有无相应的技术要求、使用特点等，然后根据查阅到的资料，结合下面要谈到的内容，再着手维修。
最后是，在分析判断的过程中，要根据自身已有的知识、经验来进行判断，对于自己不太了解或根本不了解的，一定要先向有经验的同事或你的技术支持工程师咨询，寻求帮助。
三、 在大多数的电脑维修判断中，必须“先软后硬：
即从整个维修判断的过程看，总是先判断是否为软件故障，先检查软件问题，当可判软件环境是正常时，如果故障不能消失，再从硬件方面着手检查。
四、 在维修过程中要分清主次，即“抓主要矛盾“
在复现故障现象时，有时可能会看到一台故障机不止有一个故障现象，而是有两个或两个以上的故障现象（如：启动过程中无显，但机器也在启动，同时启动完后，有死机的现象等），为时，应该先判断、维修主要的故障现象，当修复后，再维修次要故障现象，有时可能次要故障现象已不需要维修了。
§1.2 电脑维修的基本方法
一、观察法
观察，是维修判断过程中第一要法，它贯穿于整个维修过程中。观察不仅要认真，而且要全面。要观察的内容包括：
1、 周围的环境；
2、 硬件环境。包括接插头、座和槽等；
3、 软件环境；
4、 用户操作的习惯、过程
二、最小系统法
最小系统是指，从维修判断的角度能使电脑开机或运行的最基本的硬件和软件环境。最小系统有两种形式：
硬件最小系统：由电源、主板和CPU组成。在这个系统中，没有任何信号线的连接，只有电源到主板的电源连接。在判断过程中是通过声音来判断这一核心组成部分是否可正常工作；
软件最小系统：由电源、主板、CPU、内存、显示卡/显示器、键盘和硬盘组成。这个最小系统主要用来判断系统是否可完成正常的启动与运行。
对于软件最小环境，就“软件”有以下几点要说明：
1、 硬盘中的软件环境，保留着原先的软件环境，只是在分析判断时，根据需要进行隔离如卸载、屏蔽等）。保留原有的软件环境，主要是用来分析判断应用软件方面的问题
2、 硬盘中的软件环境，只有一个基本的操作系统环境（可能是卸载掉所有应用，或是重新安装一个干净的操作系统），然后根据分析判断的需要，加载需要的应用。需要使用一个干净的操作系统环境，是要判断系统问题、软件冲突或软、硬件间的冲突问题。
3、 在软件最小系统下，可根据需要添加或更改适当的硬件。如：在判断启动故障时，由于硬盘不能启动，想检查一下能否从其它驱动器启动。这时，可在软件最小系统下加入一个软驱或干脆用软驱替换硬盘，来检查。又如：在判断音视频方面的故障时，应需要在软件最小系统中加入声卡；在判断网络问题时，就应在软件最小系统中加入网卡等。
最小系统法，主要是要先判断在最基本的软、硬件环境中，系统是否可正常工作。如果不能正常工作，即可判定最基本的软、硬件部件有故障，从而起到故障隔离的作用。
最小系统法与逐步添加法结合，能较快速地定位发生在其它板软件的故障，提高维修效率。
三、逐步添加/去除法
逐步添加法，以最小系统为基础，每次只向系统添加一个部件/设备或软件，来检查故障现象是否消失或发生变化，以此来判断并定位故障部位。
逐步去除法，正好与逐步添加法的操作相反。
逐步添加/去除法一般要与替换法配合，才能较为准确地定位故障部位。
四、隔离法
是将可能防碍故障判断的硬件或软件屏蔽起来的一种判断方法。它也可用来将怀疑相互冲突的硬件、软件隔离开以判断故障是否发生变化的一种方法。
上提到的软硬件屏蔽，对于软件来说，即是停止其运行，或者是卸载；对于硬件来说，是在设备管理器中，禁用、卸载其驱动，或干脆将硬件从系统中去除。
五、替换法
替换法是用好的部件去代替可能有故障的部件，以判断故障现象是否消失的一种维修方法。好的部件可以是同型号的，也可能是不同型号的。替换的顺序一般为：
1、 根据故障的现象或第二部分中的故障类别，来考虑需要进行替换的部件或设备；
2、 按先简单后复杂的顺序进行替换。如：先内存、CPU，后主板，又如要判断打印故障时，可先考虑打印驱动是否有问题，再考虑打印电缆是否有故障，最后考虑打印机或并口是否有故障等；
3、 最先考查与怀疑有故障的部件相连接的连接线、信号线等，之后是替换怀疑有故障的部件，再后是替换供电部件，最后是与之相关的其它部件。
4、 从部件的故障率高低来考虑最先替换的部件。故障率高的部件先进行替换。
六、比较法
比较法与替换法类似，即用好的部件与怀疑有故障的部件进行外观、配置、运行现象等方面的比较，也可在两台电脑间进行比较，以判断故障电脑在环境设置，硬件配置方面的不同，从而找出故障部位。
七、升降温法
在上门服务过程中，升降温法由于工具的限制，其使用与维修间是不同的。在上门服务中的升温法，可在用户同意的情况下，设法降低电脑的通风能力，靠电脑自身的发热来升温；降温的方法有：1）一般选择环境温度较低的时段，如一清早或较晚的时间；2）使电脑停机12~24小时以上等方法实现；3）用电风扇对着故障机吹，以加快降温速度。
八、敲打法
敲打法一般用在怀疑电脑中的某部件有接触不良的故障时，通过振动、适当的扭曲，甚或用橡胶锤敲打部件或设备的特定部件来使故障复现，从而判断故障部件的一种维修方法。
九、对电脑产品进行清洁的建议
有些电脑故障，往往是由于机器内灰尘较多引起的，这就要求我们在维修过程中，注意观察故障机内、外部是否有较多的灰尘，如果是，应该先进行除尘，再进行后续的判断维修。在进行除尘操作中，以下几个方面要特别注意：
1、 注意风道的清洁
2、 注意风扇的清洁
风扇的清洁过程中，最好在清除其灰尘后，能在风扇轴处，点一点儿钟表油，加强润滑。
3、 注意接插头、座、槽、板卡金手指部分的清洁
金手指的清洁，可以用橡皮擦拭金手指部分，或用酒精棉擦拭也可以。
插头、座、槽的金属引脚上的氧化现象的去除： 一是用酒精擦拭，一是用金属片（如小一字改锥）在金属引脚上轻轻刮擦。
4、 注意大规模集成电路、元器件等引脚处的清洁
清洁时，应用小毛刷或吸尘器等除掉灰尘，同时要观察引脚有无虚焊和潮湿的现象，元器件是否有变形、变色或漏液现象。
5、 注意使用的清洁工具
清洁用的工具，首先是防静电的。如清洁用的小毛刷，应使用天然材料制成的毛刷，禁用塑料毛刷。其次是如使用金属工具进行清洁时，必须切断电源，且对金属工具进行泄放静电的处理。
用于清洁的工具包括：小毛刷、皮老虎、吸尘器、抹布、酒精（不可用来擦拭机箱、显示器等的塑料外壳）。
6、 对于比较潮湿的情况，应想办法使其干燥后再使用。可用的工具如电风扇、电吹风等，也可让其自然风干。
十、软件调试的几个方法和建议
1、 操作系统方面。
主要的调整内容是操作系统的启动文件、系统配置参数、组件文件、病毒等。
修复操作系统启动文件。
1) 对于Windows 9x系统，可用SYS命令来修复（要保证MSDOS.SYS的大小在1KB以上），但要求，在修复之前应保证分区参数是正确的。这可使用诸如DiskMap之类的软件实现；
2) 对于Windows 2000/XP系统，有两种方法——修复启动文件，使用fixboot命令；修复主引导记录，使用fixmbr命令。
调整操作系统配置文件。
A. 对于Windows 9x系统，可用的工具很多，如：Msconfig命令、系统文件检查器、注册表备份和恢复命令（scanreg.exe，它要求在DOS环境下运行。另外如果要用scanreg.exe恢复注册表，最好使用所列出的恢复菜单中的第二个备份文件）等；
B. 对于Windows 2000系统，可用的工具与Windows 9x相比比较少，但某些调试命令可用Win98中的一些命令（如win98下的Msconfig命令，就可用在windows 2000下）；
C. 对于Windows XP系统，可用的工具主要是Msconfig命令；
D. 调整电源管理和有关的服务，可以使用的命令是，要“运行”文本框中输入gpedit.msc来进行；
E. 所有操作系统的调试，都可通过控制面板、设备管理器、计算机管理器（Windows 9x系统无）来进行系统的调试。
组件文件（包括.DLL、.VXD等）的修复
A. 通过添加删除程序来重新安装；
B. 通过从.CAB文件中提取安装；
C. 可用系统文件检查器（sfc.exe命令）来修复有错误的文件；
D. 从好的机器上拷贝覆盖。
检查系统中的病毒。
建议使用命令行方式下的病毒查杀软件，并能直接访问诸如NTFS分区。
2、 设备驱动安装与配置方面。
主要调整设备驱动程序是否与设备匹配、版本是否合适、相应的设备在驱动程序的作用下能否正常响应。
A. 最好先由操作系统自动识别（特别要求的除外，如一些有特别要求的显示卡驱动、声卡驱动、非即插即用设备的驱动等），而后考虑强行安装。这样有利于判断设备的好坏；
B. 如果有操作系统自带的驱动，则先使用，仍不能正常或不能满足应用需要，则使用设备自带的驱动；
C. 更换设备，应先卸载驱动再更换。卸载驱动，可从设备管理器中卸载；再从安全模式下卸载；进而在INF目录中删除；最后通过注册表卸载；
D. 更新驱动时，如直接升级有问题，须先卸载再更新。
3、 磁盘状况方面。
检查磁盘上的分区是否能访问、介质是否有损坏、保存在其上的文件是否完整等。
可用的调整工具：
A. DiskMap，方便地找回正确的分区；
B. Fdisk及Fdisk /MDR，检查分区是否正确及使主引导记录恢复到原始状态；
C. 当硬盘容量大于64GB时，如果要重新分区或查看分区，要求使用随机附带的磁盘分区软盘中的Fdisk命令。这个命令可用windows Me下的Fdisk命令来代替；
D. Format、Scandisk、厂商提供的磁盘检测程序，检查磁盘介质是否有坏道；
E. 文件不完整时，要求对不完整的文件先进行改名，再用在“操作系统方面”中所述的方法重建。
4、 应用软件方面。
如应用软件是否与操作系统或其它应用有兼容性的问题、使用与配置是否与说明手册中所述的相符、应用软件的相关程序、数据等是否完整等；
5、 BIOS设置方面。
1) 在必要时应先恢复到最优状态。建议：在维修时先把BIOS恢复到最优状态（一般是出厂时的状态），然后根据应用的需要，逐步设置到合适值。
2) BIOS刷新不一定要刷新到最新版，有时应考虑降低版本。
6、 重建系统。
在硬件配置正确，并得到用户许可时，可通过重建系统的方法来判断操作系统之类软件故障，在用户不同意的情况下，建议使用自带的硬盘，来进行重建系统的操作。在这种情况下，最好重建系统后，逐步复原到用户原硬盘的状态，以便判断故障点。
1 本站域名：http://www.cn12.com
本站论坛：http://www.jxlb.com/cgi-bin/leoboard.cgi
㈢ 如何做好软件项目的验收
项目验收是公司乃至每个项目成员都想要的结果，一旦验收对公司来说就是，可以收验收阶段的款了，不需要再投入那么多人力到项目当中，项目终于可以告 一段落，大家都可以轻松一下了。项目验收是一系列细致工作完成到位的结果，而不是某一点的成功或某个人能力就可以促成的事情。一个项目的验收，一般是由一 系列验收准备工作组成的。如果我们在最终验收前，已经将很多阶段的工作细化并得到认可执行，那么项目验收也就是水到渠成的事情了。首先我们要明确进入验收的前提。很多人都认为只要我们完成了合同中规定的内容，完成了需求规格说明中规定的工作，并且按合同试运行了几个月，应该就可以验收了。就可以拿着合同或技术协议与客户谈论验收的相关事宜了。但 实际上客户往往不同意在此时验收。他们的判断往往不是招标书、合同、技术协议、需求规格说明书等文档。其实这些文档无论做得如何细致，对用户而言并没太大 的参考价值。客户关心的是他们的业务是否真地在系统中运作，并且运行良好，并以此作为检验项目验收的标准。当然有的项目也可以通过商务运作，在业务实现不 太好的情况下验收。1、在项目实施过程中注重里程碑的确定，制定阶段性目标如果要做好一个项目，完成项目的验收条件，主要还是以业务是否可用作为衡量的。不是一定得实现所有用户的需求（这里指的是口头上的需求，如果落实到文字上的还是要实现的），也不是只有将一些所谓的技术难点解决用户就会同意验收，而是我们可以完成一定的阶段应用业务目标。我们从进行需求调研的时候就要主动控制项目的边界，将一个一个业务流根据客户方的实际情况合理组织实施顺序，形成我们项目实施计划中的里程碑点，明确达到里程碑点的条件，并得到双方一致正式认可。没有双方高度达成一致的里程碑认可，也就是没有项目目标约定，没有目标约定的项目实施计划一定会经常变更内容、变更初始设定目标，导致计划不可控制，更谈不上验收。很多人希望通过详细的系统需求规格说明书来定义项目要实现的内容和业务目标，这是很有必要的，但需求规格说明书得到认可并非是通过用户审核就可以的结果，应该想办法让用户一起参与到需求规格说明书的制定过程中来，变成用户自己推导出来的业务实施目标，未来才不容易变形。2、积极主动地与客户进行沟通 项目中一定要有沟通策略，和高管如何汇报工作进展，取得支持？和中层如何就业务目标不断确认，逐步清晰？和基层如何就项目应用操作模式达成一致，持续改进？都需要通过沟通反馈完成。沟 通的作用对于高管是让他们清楚我们一直按照项目目标前进，每个阶段工作进展是否顺利，影响项目正常运做原因是什么，需要哪些资源帮助。和高管沟通比较多的 话，第一个好处是高管经常听汇报就知道项目进展程度，可以安排反馈检查，看是否具备我们所说的进展，这样一旦认可了各个阶段目标后，最终要求高管签字确认 也就顺理成章了。给高管汇报技巧就是简洁明了，真实客观，有理有据分析问题，提出对策建议请其决策即可。中层往往是项目主要的推动力量和实际执行者，也往往是对具体业务需求最主要的要求者，他们对企业实际运做过程最清楚，提出要求最具体，而且项目验收与否没有中层的同意往往也是不太容易做到的。往往通过前期业务调研只能对企业项目目标有一个大的，宏观的认识，但如何细化并最终落实并非是一步到位的过程。因此在整个项目过程中，双方项目组要不断沟通，特别是企业中层沟通，才能逐步认识越来越深刻，最终达成一致。和基层的沟通主要体现对最终用户的关怀，定期主动和最终用户沟通，消除一些怨气，让用户能坚持用下去，这个时候我们往往发现很多用户真的是非常好相处，尽管软件还有很多值得改进的地方，但他们一旦认可我们团队，反而会尽心尽力帮助我们推动项目的进行。目前我们公司一般要求每个项目经理在项目进行中都要填写详尽的项目月报，反映项目的进度，与计划的偏差，完成的项目内容，投入人力，目前项目存在的问题，以及预计项目下月的进度等等。将进度月报交部门负责人、项目管理中心、总经办审阅。类似地也要制定针对客户的月报甚至是周报，将相关的信息反应到客户方的负责人，及相关高层。可以先发邮件，然后还要电话落实收到并口头简要汇报，特别是高管层，千万不要以为发了就等于别人会去看，一定要口头跟进汇报一次，保证客户各方面负责人对项目进展做到心中有数。在 项目的过程中，我们也需要注意平时做人的积累，比如要做到讲诚信，讲原则。主要是三条：1）做不到的事情千万别随意承诺；2）承诺的事情一定要努力做 到；3）每次做到的事情都进步一点点。按这三条做事，即使在系统的使用过程中总会有这样或那样的一些不方便，用户也会慢慢接受稍微长一点的响应周期，也会 用更多积极性眼光看现在的问题，也相信问题一定有人响应，也一定可以得到解决。进而使我们和客户之间形成一种较为和谐的关系。3、写好备忘录和问题跟踪记录 在一个漫长项目周期中，很多工作做了也就做了，认可了也就认可了，时间一长也就忘记了很多承诺和约定，到了验收的时候就可能重新翻出来，这种事情很多人可能都经历过，明明说可以先不做的内容最终验收的时候又成了必要条件。每次备忘录要口头交流认可后才打印签字确定阶段性工作成果。下次工作则根据前次备忘录的双方约定继续进行，保障项目在每次工作基础上不断前进，并用备忘录约束双方的行为。同 时我们建议在收集项目出现的各种问题时，采用问题跟踪记录表的形式，这样可以一目了然地显示出我们曾经收集到的各种问题，目前的解决情况，以及还有什么问 题没有解决，准备什么时候解决。这样客户和我们都会对目前的情况非常了解，通过不断地解决出现的问题，来收敛可能出现的问题，当存在的问题越来越少时，也 就表示我们的系统已经在接近验收的标准了。4、验收阶段的准备工作及注意事项 当 系统经过一段试运行，具备验收的各项条件之后，我们就需要着手验收阶段的准备工作了。首先我们需要把到目前为止完成的工作进行一个总结，列出我们已经完成 的各项目工作成果、各类文档，对合同以及各类约定的技术文档中的相关内容进行自查，要彻底了解系统目前完成的情况如何，是否已经完成了与客户方达成的各项 书面约定以及口头约定，没有完成的，如果是书面约定，准备采取什么策略去进一步完成或者采取一定的回避措施，使客户在验收的时候不再提出这些未实现的需 求。做一个详细的验收计划是非常必 要的，可以用来作为验收阶段的工作指导。这就需要与客户进行详细的沟通，再次明确验收前需要完成的工作，尽量避免客户方在此阶段提出过多的更改需求，这是 极为重要的。验收计划中不光要有需要继续完成的工作，还需要有一个相对固定的工期，使双方都继续朝着这个方向去努力，防止无限制的拖延。我们很多的项目碰到的一些常见 问题就是软件开发完之后，很多客户也不使用，如果我们去催促他们的时候，就经常推脱工作太忙，还有其它的事要做等等，或者也就是应付一下随便提一两个小问 题。而等我们提出要验收的时候，他们又总是觉得这也不满意那也不满意，总之是怕承担相应的责任，不愿意验收。针对这种情况我想主要还是想办 法让客户尽量把系统使用起来，只有在使用中才能发现问题，我们也才能解决问题，使系统能更好地运行。如果是基层的人员不愿意使用，我们可以走上层路线，使 客户的高层了解项目正常运行的重要性，也使他们意识到项目验收的重要性，意识到无限制地拖延下去会对政府机会的权威、形象和公司的收益造成不好的影响，利 用他们的主观积极性克制拖沓的工作作风。如果项目经理在这方面没有太多的办法的时候，可以让市场人员动用一些商业运作的手段，或者提请公司高层出面与客户 方的高层尽早沟通，明确系统运行的各项工作。还有一种情况就是客户无穷尽地提出一些需求，一些主要领导对系统指指点点，随便一句话，就要进行需求变更，项目的范围不断扩大，导致项目试运行一直无法结束。甚至一些客户追求系统的完美，提出了很多高难度的需求，导致我们需要投入较多的精力去解决。这 种情况，我觉得是一些政府主管领导对电子政务认识上存在一定的误区，认为这么一个系统就应该能够解决所有的问题。其实信息系统只是政府管理工作的一种辅助 性手段，信息化不是一步到位工程，而是一种长期的、不断改善的系统工程。我们应该想法让他们结合实际情况，提出他们真正需要解决的问题，而不是依靠他们的 长官意志，提出一些不切合实际的、易变的需求。要实现这一点，就需要项目经理安排人员定期到政府机关进行信息化普及培训以及项目管理知识培训。同时在合适 的情况下，建议在该项目验收后启动新的项目来完成一些新的需求。项目验收对任何一个项目管理者 都是一个极大的挑战，即使已经采取本文提到的几种手段，也不能保证我们的项目能够顺利验收，但作为项目的承建方，我们所能做到的就是尽量做好我们所能控制 的事情，另外一些很难由我们控制的事情则需要借用一些其它的力量去完成，比如请市场部运用一些商业手段来促成项目的验收等等。本文中提出的这些建议，是希 望能够起到抛砖引玉的效果，希望各位同仁可以提出更多更好的方法来促进我们的项目如期验收。
㈣ 软件项目客户迟迟不肯验收怎么办
在项目验收的时候，对于项目中可能存在的一些问题，不要让客户想等系统没有一点问题或保证以后没有问题的情况下才验收。如果客户这样想开发团队就麻烦了，微软那么牛，做的操作系统还天天打补丁。开发团队要让客户明白，所谓验收，就是依照合同需求和能够满足企业的需求，结果和预期结果一致就应该算通过了，而且还容许有一些小错误留在验收后改正。 一般来说，现场长时间验收检查不太可行。因此，在验收前准备阶段，项目负责人应主动、积极的与客户密切沟通，及时、准确地收集和理解验收条件。特别是客户对即将验收项目的真实、初步意见和评价，最好是在验收前就沟通好和形成书面正式的《项目评价报告》。如还留有一些可能影响或暂时不影响项目整体验收通过的细节、小问题、变更或异议、分歧等，应与客户协商解决处理好，做到事先沟通、达成共识。强调已经基本上完成项目内容，满足合同要求。 如何顺利地让客户进入验收状态？ 如何才能顺利地让客户进行验收是一直困挠开发团队的一个难题，为了避免项目验收遥遥无期的局面，建议加强以下几方面工作。 （1）及时解决问题，端正处理BUG的态度 既然发现软件存在问题，就应该尽力去解决，这是开发团队的责任。客户不肯验收，主要是害怕承担责任，毕竟还有问题没有解决嘛。如果换做我，我也不会给你验收的。因此，要想让客户方验收，首先要做好合同的明确规定和服务承诺。并以此为依据，让客户放心，让客户方验收。在开发过程中给客户感觉是不是用心的做事是很重要的，否则的话后期验收就会有点困难了。 在项目过程中，需要注意平时承诺的积累，比如要做到讲诚信、讲原则。主要是三条：做不到的事情千万别随意承诺、承诺的事情一定要努力做到、每次做到的事情都要进步一点点。按这三条做事，即使在与与客户沟通中有这样或那样的不愉快和矛盾，客户也会慢慢接受，也会用更多积极性眼光看存在的BUG问题。当然，项目中如果有关键瑕疵，也是客户忌讳的，开发团队一定要理解这些瑕疵并解决好。 （2）平衡和识别项目干系人需求 在项目验收阶段前，要尽量识别和关注所有项目干系人的需求和态度，并时刻给客户灌输只要完成那几项工作就代表项目可以验收了。当客户不肯验收时，要与客户展开深入的交流，明确客户为什么不愿意验收。有时客户的问题只是借口，所以要根据客户的表现判断出这个背后的问题所在。当找到问题后，协调相关的资源来解决。有时和客户直接把问题摊开沟通，或许是比较好的解决方法。 总之，开发团队应要对项目利害关系者进行关注，和关注他们关注的内容，或者他们担忧的内容。作为开发团队要做到尽量做好所能控制的事情，另外一些很难由开发团队控制的事情则需要借用一些其它的力量去完成。比如关注项目利害关系者的一些秘密需求是否得到了满足，或请高层领导运用一些商业手段来促成项目的验收等。 （3）重视阶段性成果验收，提高客户感知度 其实，软件开发项目验收远非是仅仅对系统的测试和检验这样简单，它是开发团队和客户在开发过程中双方合作博弈的结果。因此，在项目开发过程之中，与客户的沟通和绩效汇报是非常重要的。客户之所以迟迟不验收项目，简单的说是因为客户对开发团队做的项目不满意。 一般来说，满意=感知-期望。因此，客户不满意是因为客户的感知度非常低，而期望很高。换句话说，是由于开发团队对项目需求没有定义好，或者没有分析好，或在定义需求的时候没有考虑到客户的感知和期望，导致现在的项目验收困难。所以，一方面量化和降低客户的期望值，另一方面尽量提高客户的感知度是非常重要的。方法可以是对于每一个阶段性的成果，尽量让客户可以参与并且验收，目的是为了尽可能来提高客户的感知度。 （4）清晰处理好客户反馈问题的跟踪状态 在一个项目开发周期中，每次客户的反馈问题都需要认真做好跟踪记录。下次工作要根据前次备忘录的双方约定或客户的反馈问题继续进行，保障项目在双沟通的基础上不断前进，并用备忘录约束双方的行为。 建议在收集项目出现的各种问题时，采用问题跟踪记录表的形式，这样可以一目了然地显示出曾经收集到的各种问题、目前的解决情况、以及还有什么问题没有解决，或准备什么时候解决。这样客户和开发团队就都会对目前的情况非常了解，通过不断地解决出现的问题，来收敛可能出现的问题。当存在的问题越来越少时，也就表示项目开发已经在接近验收的标准了，也可使客户在需要验收的时候不能再找各种各样的借口来拖延验收。
㈤ 软件开发客户验收，如果出现出现客户恶意不验收，如何解决
一般来说，当软件开发项目到了具备验收的各项条件之后，开发团队就会着手准备验收阶段的工作。但如果这时发生客户不愿意验收的话，这是一个让开发团队很头痛和很普遍的问题。原因是多方面的，如果出现出现客户恶意不验收，没有特别办法的时候，也只能伤感情了。
其实，疫情期间，客户因资金原因会找各种借口推迟验收，这也是很常见的。有时，客户迟迟不肯验收或故意推迟验收，有可能客户是以推迟验收而推迟结算和要支付的款项。对于有这种想法的客户是最让开发团队为难的了。动用法律吧，担心破坏了长久建立的关系；不动用法律吧，还真有这么不客气的客户。
㈥ 怎样做好软件项目验收工作
项目验收是公司乃至每个项目成员都想要的结果，一旦验收对公司来说就是，可以收验收阶段的款了，不需要再投入那么多人力到项目当中，项目终于可以告一段落，大家都可以轻松一下了。项目验收是一系列细致工作完成到位的结果，而不是某一点的成功或某个人能力就可以促成的事情。一个项目的验收，一般是由一系列验收准备工作组成的。如果我们在最终验收前，已经将很多阶段的工作细化并得到认可执行，那么项目验收也就是水到渠成的事情了。 首先我们要明确进入验收的前提。很多人都认为只要我们完成了合同中规定的内容，完成了需求规格说明中规定的工作，并且按合同试运行了几个月，应该就可以验收了。就可以拿着合同或技术协议与客户谈论验收的相关事宜了。 但实际上客户往往不同意在此时验收。他们的判断往往不是招标书、合同、技术协议、需求规格说明书等文档。其实这些文档无论做得如何细致，对用户而言并没太大的参考价值。客户关心的是他们的业务是否真地在系统中运作，并且运行良好，并以此作为检验项目验收的标准。当然有的项目也可以通过商务运作，在业务实现不太好的情况下验收。 1、在项目实施过程中注重里程碑的确定，制定阶段性目标 如果要做好一个项目，完成项目的验收条件，主要还是以业务是否可用作为衡量的。不是一定得实现所有用户的需求(这里指的是口头上的需求，如果落实到文字上的还是要实现的)，也不是只有将一些所谓的技术难点解决用户就会同意验收，而是我们可以完成一定的阶段应用业务目标。 我们从进行需求调研的时候就要主动控制项目的边界，将一个一个业务流根据客户方的实际情况合理组织实施顺序，形成我们项目实施计划中的里程碑点，明确达到里程碑点的条件，并得到双方一致正式认可。 没有双方高度达成一致的里程碑认可，也就是没有项目目标约定，没有目标约定的项目实施计划一定会经常变更内容、变更初始设定目标，导致计划不可控制，更谈不上验收。 很多人希望通过详细的系统需求规格说明书来定义项目要实现的内容和业务目标，这是很有必要的，但需求规格说明书得到认可并非是通过用户审核就可以的结果，应该想办法让用户一起参与到需求规格说明书的制定过程中来，变成用户自己推导出来的业务实施目标，未来才不容易变形。项目经理博客 2、积极主动地与客户进行沟通 项目中一定要有沟通策略，和高管如何汇报工作进展，取得支持?和中层如何就业务目标不断确认，逐步清晰?和基层如何就项目应用操作模式达成一致，持续改进?都需要通过沟通反馈完成。沟通的作用对于高管是让他们清楚我们一直按照项目目标前进，每个阶段工作进展是否顺利，影响项目正常运做原因是什么，需要哪些资源帮助。和高管沟通比较多的话，第一个好处是高管经常听汇报就知道项目进展程度，可以安排反馈检查，看是否具备我们所说的进展，这样一旦认可了各个阶段目标后，最终要求高管签字确认也就顺理成章了。 给高管汇报技巧就是简洁明了，真实客观，有理有据分析问题，提出对策建议请其决策即可。 中层往往是项目主要的推动力量和实际执行者，也往往是对具体业务需求最主要的要求者，他们对企业实际运做过程最清楚，提出要求最具体，而且项目验收与否没有中层的同意往往也是不太容易做到的。项目管理培训 往往通过前期业务调研只能对企业项目目标有一个大的，宏观的认识，但如何细化并最终落实并非是一步到位的过程。因此在整个项目过程中，双方项目组要不断沟通，特别是企业中层沟通，才能逐步认识越来越深刻，最终达成一致。 和基层的沟通主要体现对最终用户的关怀，定期主动和最终用户沟通，消除一些怨气，让用户能坚持用下去，这个时候我们往往发现很多用户真的是非常好相处，尽管软件还有很多值得改进的地方，但他们一旦认可我们团队，反而会尽心尽力帮助我们推动项目的进行。目前我们公司一般要求每个项目经理在项目进行中都要填写详尽的项目月报，反映项目的进度，与计划的偏差，完成的项目内容，投入人力，目前项目存在的问题，以及预计项目下月的进度等等。将进度月报交部门负责人、项目管理中心、总经办审阅。项目经理圈子 类似地也要制定针对客户的月报甚至是周报，将相关的信息反应到客户方的负责人，及相关高层。
㈦ 软件项目验收的具体流程
1、流程内容 本流程描述项目验收的全过程。即招投标管理 、软件 采购 和签订信息系统合同的过程。
2、流程的起止点 项目验收流程自开发商申请验收，计算机信息中心主任决定验收方案始，至财务资产处支付结算止。
3、术语解释：二、流程涉及部门及职责 业务主管部门及职责：计算机信息中心：决定验收方案、提供专家组名单、编写科技项目（课题、专题）验收申请表，进行系统测试、汇总验收资料 提交验收报告，申请项目付款2、业务参与部门及职责：系统验收评审组：编写验收报告 技术中心：组成项目验收组，审批验收报告 财务资产处：支付结算