软件实施心得体会.docx
《软件实施心得体会.docx》由会员分享，可在线阅读，更多相关《软件实施心得体会.docx（9页珍藏版）》请在冰豆网上搜索。
软件实施心得体会
软件实施心得体会
软件实施心得体会
【篇一：
实施项目经理的心得】
在项目的不同阶段，项目经理要考虑的事情也不同，要做的事情也不同，下面按照项目不同阶段来谈谈我的体会。
一、项目前期阶段：
项目的前期阶段是一个项目最重要的时期，在这个时候项目经理对项目情况了解越多，后期项目风险就越小。
1．细读项目合同，弄清楚这个是什么项目，项目的目的是什么，项目合同中有那些客户关注的问题。
有哪些是新的功能，这些功能现有系统通过实施变通的方法能解决吗？
如果不能解决是否要进行二次开发？
了解项目实施的范围是如何，这次实施是推行主要业务还是全部业务，是帮企业推行个别部门还是整个公司以及整个集团？
2.从项目合同中了解情况后，还要从其他方面了解这客户关注的问题最终又是那些部门、那些岗位甚至是那些人员提出的，在项目调研阶段主动到这些部门拜访这些人员，真正理解他们的需求，还有了解各个方面对这次项目看法和期望，有助于在实施中碰到阻力的时候，就每件事情分析那些人会支持你，那些人会反对你，从而好联合支持人去对抗反对者，让项目向成功方向发展。
记住，想办法让企业有声望的部门领导成为你坚强的支持。
3.了解客户的基本情况后，再了解自己公司高层领导对该项目的态度。
公司高层是想把项目做大还是想赚钱？
是想做样板工程还是敷衍了事，这个决定了你项目实施策略，这个策略将影响到你项目的整体计划。
4.知己知彼，现在来估算项目资源和分析项目风险。
项目资源之一是时间，按照项目的合同要求是否可以完成项目，如果完不成，是那
（包括产品bom以及历史图纸），及早分配整理任务。
产品数据管理这个系统基本运行需要一定的数据量以及这些数据达到一定程度的准确性，系统才能正常运行，提前进行数据整理工作是你项目成功的保障之一。
项目调研后进行系统建模工作，在建模工作中尽量培训企业人员进行建模，让企业项目组人员快速熟悉你的系统。
这样好处多多：
其一是减少顾问方的工作量；其二是为你的项目培养一个本土的实施人员；其三是为了降低后期维护风险，如果你没有在企业培养一个人员，那么当你的人员一走，电话就响个不停了，甚至有些地方你电话教他去设置，还找了大半天，既浪费了你的“银两”，又浪费了你的时间；其四也是降低项目的风险，如果企业没有人知道怎么去建模，企业的业务发生了变化，那么系统没有更改过来，系统后面还能很好运行起来吗？
呵呵，你的项目不是变成了豆腐渣工程了，最后被企业废了。
在项目过程中，必须时时保持和客户领导以及自己领导的沟通，和客户领导沟通时要注意态度积极点，同时具体点，不要讲很多系统细节的事情。
在和项目小组成员沟通的时候，要先灌输系统管理念。
在每次会议的时候，你都应该认为，
项目成员提出的方案，从他们的角度来看是最合理的，你要充分尊重每一个人和他的意见，夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论，只有他们的面子被照顾了，后面实施的阻力就小了。
如果确实有意见，可以私下沟通，如果还沟通不了，那么找企业项目经理一起去说明项目风险，必须按照你的意见进行执行，因为你们要对项目负责。
在项目过程中有时遇到项目变更，变更通常分为两种：
一种需求变更；另一种是程序优化。
如果需要改并且你的战略是容许这种情况的，那么注意下面几点：
?
将变更情况写成书面的文件，签字并导盖章；
?
弄清楚更改的根本目的是什么，有没有同样能达到相同目的方法，
只是操作上复杂了点，是否可以想办法说服客户。
业务调研以及系统建模完成后，就进入客户培训、项目试运行以及正式运行阶段。
1、给客户做培训前，多准备，其中包括培训通知下发、会议室联系，是否需要投影仪，培训文档准备（ppt），同时按照培训的思路在系统中操作一次，看看系统是否存在程序的问题。
强调一点培训手册一定要站在客户业务人员的角度，根据具体业务讲解如何通过使用本系统的一系列功能来实现。
所以，第一次培训以前，系统是否存在问题、培训文档是否完备都是很关键的因素，第一次培训不好，以后就麻烦很多。
在培训时一定要参加培训人员进行签名，告诉他参加培训后需要进行考试，如果成绩不理想，会影响以后的工作，同时企业会采取相应的处罚措施，在培训时候建议一次培训的人员不要太多，大概在30~40个人一场为宜，太多效果往往不理想，在培训过程中为了提高培训者兴趣，可以在培训快要结束的时候要求培训人员上台来进行一次简单操作，看看效果如何，同时也有利用下一场的改进。
2、项目进行试运行，选定一些功能，这些功能在试运行过程中可以只考虑过程，不要考虑试运行文件的准确性，其目的是为了验证系统功能与实际业务结合的时候，看那些地方还需要修改，发现问题尽快解决，同时也要安排专门的人员进行跟踪，全方位了解运行过程中的问题，解决客户疑难。
提高他们的兴趣。
在试运行阶段根据自己经验以及企业实际情况，考虑如何设置非电子化运行的障碍，最大限度保证企业业务人员使用你的系统。
3、在项目正式运行以前，全面测试系统功能，尽量在设置上少出问题，减少客户投诉，准备项目正式运行文件，要求企业领导签字下发，下发系统正式运行文件的目的是为了整个公司重视，减少在正式运行时候的阻力。
根据系统大小，考虑是否要召开正式运行启动会议。
根据项目试运行得到的经验，与对方的项目经理协商设置减少非电子化运行的障碍。
这个障碍对于不同的企业不同情况，处理方法也不同：
?
企业存在文档服务器：
处理的情况是在运行以前，现转移文件服务器的
文件，在项目正式运行后，关闭文件服务器。
业务流程到新的系统，在正式运行后，该系统只作为历史查询，关闭新增功能。
?
存在信息发布系统：
关闭其他信息发布系统，全部转移到新的系统，关
闭新增功能。
?
存在其他流程系统：
处理情况是转移业务流程，关闭原有新增功能。
?
没有存在其他系统，但是却继续使用纸档：
处理情况是与相关的领导以
及资料发布归档人员联系，所有的资料审批和发布必须以电子档为准，其他不受理。
其他的不一一例举了。
准备工作完成后，进入项目正式运行阶段，全面跟踪项目的刚刚开始的各种业务，及时处理出现的问题，同时每天编写项目运行日报，向领导、项目成员甚至所有客户通告系统运行基本情况，及时表扬表现好的单位或个人。
作为项目经理，要考虑的事情就是：
做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级，最后把款收回或协助把款收回。
所以项目经理要注意：
第一保证项目进度；第二是控制好费用；第三在能力范围内尽量把质量提高；第四是降低客户的期望值，让他们从理想回到现实；最后在每个阶段项
【篇二：
软件配置管理实施体会】
软件配置管理实施体会
陈越，fashi@
随着软件产业的崛起，软件工程技术正吸引着越来越多关注的目光。
作为软件工程的一个重要的领域，软件配置管理（softwareconfigurationmanagement）也日益受到人们的重视。
在这里，笔者并不打算对软件配置管理的细节进行讨论，几乎任何一本关于软件工程的教材中都有专门的章节对此进行介绍，而是想从一个实践者的角度来阐述关于软件配置管理的一些想法。
一．软件配置管理的目的
对于任何一个软件组织（企业）来说，开发出满足用户需求的、高质量的软件产品是其追求的目标。
而要实现这一目标的关键是建立起一个稳定、可控、可重用的软件流程（softwareprocess）。
因为某一软件产品的成败可能维系于关键技术的突破和创新；但对于软件组织而言，要想永葆竞争优势并不断取得成功，那就必须不断地改进它的软件流程。
要进行软件流程改进（softwareprocessimprovement）就需要有明确的、量化的对现状的分析和对未来的预期，这些数据来源于对软件过程的度量，而进行度量的前提和基础就是软件配置管理。
与一般制造业相类似，软件流程就像是一条流水线，在它的各个环节上都会有“零部件”产生，它们就是我们所熟悉的程序、相关文档以及数据。
这些正是软件配置管理的对象——（软件）配置项。
它们不仅是大量人力物力投入的结晶，更是开发经验的积累，是软件组织最宝贵的财富。
软件配置管理贯穿于软件开发活动的始终，覆盖了开发活动的各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及相关的人员报告，从而实现对软件过程的控制。
那么我们对这些配置项进行管理只是为了保存这些信息吗？
众所周知，人员的高流动性和知识和技术的快速更新是软件业的重要特点。
应对这样的特点我们只有努力地把开发人员个人的成功经验转化为团队的以及整个组织的经验。
在这样的一个转化过程中，软件配置管理也起着极其重要的作用。
因为对于一个大型的软件企业来说，它的配置库有如一个巨大的图书馆，随着产品版本的不断演进，越来越多的配置项会充斥其间，以至于没有任何一个人能了解其中的全部内容。
当我们需要在开发组织内部迅速的共享以往的成果时，配置管理就能发挥作用了。
它就像常见的图书编目法那样，帮助图书管理员（配置管理员）迅速的找出所需的资料（配置项），而不必彻底了解其中的确切内容。
这样工作效率大为提高，很多常见的容易引起混乱的问题都能尽量得以避免。
所以，我们在从事软件配置管理工作时应以整个软件流程的改进为目标，为软件项目管理和软件工程的其它领域打好基础，以便于稳步推进整个软件组织的能力成熟度。
二．工具的选择
古语有云：
“工欲善其事，必先利其器。
”软件配置管理是一项十分繁琐的工作，同时又和整个软件的开发活动紧密地联系在一起，所以在实际工作中更需要有得力的工具辅助。
目前常用的配置管理工具主要有mssourcesafe、rationalclearcase等，这些工具各有所长，因而只有根据项目
的预算和开发组织的些实际情况出发来选择，正所谓“好用就好”。
在这里，笔者提出一些个人的看法供大家参考。
首先，配置管理工具应该提供完善的版本管理的功能。
在该工具的所管理的配置库中，所有的配置项都应清晰、完整的得到保存，相应的操作纪录完备，使得开发组织中的任何人员都能迅速的了解任一配置项的演进过程，并快捷的找到所需的资源。
其次，配置管理工具应具备一定的工作空间的管理功能。
正如前文指出的那样，一个软件企业往往有多个项目同时进行着开发，为了最大程度的利用组织的经验、共享成果，我们有必要在一个共同的配置库里提供多视角的观察手段，在逻辑上按照不同的角色分工来组织信息的选取规则和显示方式，从而能根据需要，在开发人员间灵活的进行分工合作。
由于我们把配置管理工作立足于软件过程的改进，那么我们所选用的工具最好能具有一定的过程控制的能力，能利用它按照企业本身的开发流程来灵活的建立相应的电子流，并在此过程中记录用于过程度量的相关数据，整合软件过程管理的各个环节，以便于客观的发现问题，高效的解决问题。
另外，我们选取得工具一定要操作简便，不能给开发人员增加过多的负担，因为过多的形式化的约束往往带来人们的反感，使得大家不约而同的选择规避的措施，其结果只能是事倍功半，甚至和我们的目标南辕北辙。
三．实现的策略
笔者所在的软件组织从事的通信软件的研发，我们把配置管理作为推进软件过程改进的一个很重要的工作领域。
我们明确定义了配置管理相关的角色、工作职责和工作流程，通过一段时间的努力，已经取得了明显的效果。
1．配置库的设置
决定配置库的结构是配置管理活动的重要基础。
一般常用的是两种组织形式：
按配置项类型分类建库和按任务建库。
按配置项的类型分类建库的方式经常为一些咨询服务公司所推荐，它适用于通用的应用软件开发组织。
这样的组织一般产品的继承性较强，工具比较统一，对并行开发有一定的需求。
使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。
但由于这样的库结构并不是面向和各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。
而按任务建立相应的配置库则适用于专业软件的研发组织。
在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格的分类存储，人为增加目录的复杂性。
因此，笔者认为特别是对于研发性的软件组织来说，还是采用这种设置策略比较灵活。
2．分支的划分
在实际的开发活动中系统中，为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，我们基本上为每个配置项从建立开始就划分成3个不同的分支，让它们分别对应3类工作空间。
l私有分支
私有分支对应的是开发人员的私有开发空间。
开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素。
l集成分支
集成分支对应的是开发团队的公共空间。
凡是要为同组人员共享的配置项都从该分支获得。
即各开发人员必须将私有工作空间中的开发成果归并（merge）到该分支后才能进入下一个开发活动。
所有涉及多人协调的开发工作（如集成测试等）都必须工作在这一空间中。
该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限。
该分支的管理工作由系统集成员及相关指定人员负责。
l公共（主干）分支
公共分支对应的是整个软件开发组织的公共空间。
各个开发小组在现阶段的任务完成后，将可以发布的版本归并到该分支上，将来需要查阅相关资料时，以该分支上的版本为准。
该分支对组织内的全体软件人员开放只读权限。
该分支的管理工作由系统集成员负责。
上面定义的3类工作空间（分支）由配置管理员统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。
在变更发生时，应及时做好基线的推进。
3．变更控制
对于大型的软件开发项目，无控制的变更将迅速导致混乱，变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的的机制。
本文所涉及的变更控制的对象主要指配置库中的各基线配置项。
变更管理的一般流程是：
a）由开发人员或系统集成员提出变更需求；
b）由sccb（软件变更控制委员会）审核并决定是否批准；
c）配置管理员根据sccb的决定临时开放相应的权限，并备案；
d）系统集成员执行相应的变更。
在这里，将要涉及的变更控制分为两类：
一类是基线的变更控制，另一类是软件版本的变更控制。
l基线的变更控制
基线的变更是指在一个软件版本的开发周期内对基线配置项的变更，主要包括基线的应用和更新等活动。
基线变更所涉及的操作主要包括基线标签的定义和标签的使用。
基线标签属于严格受控的配置项，它的命名必须严格按照相关的命名规范来进行。
基线在建立时，按照角色职责的分工，须经sccb同意并以正式的将该基线的标识和作用范围通知系统集成员，由后者负责执行；基线一旦
划定，由该基线控制的各配置项的历史版本均处于锁定或严格受控状态，任何对基线位置的变更请求都必须按变更控制流程，提交sccb批准，然后由系统集成员执行。
l软件版本的变更
软件版本的命名规范应事先制定，并按照开发计划予以发布使用。
在软件版本的演进过程中既需要从以前的版本中继承，又需要相对的独立性。
所以在对于一个子版本（例如某特定用户的定制版本）就需要对一系列配置项从统一的开发起始基线所确定的版本上建立新的分支，然后在此分支上开发新的版本。
因此在这样的变更控制流程中，受控的对象还应包括特定的分支类型，以及工作视图的选取规则，同时配置管理员将在这一过程中担负更多的操作职责。
上述几点是笔者在从事软件配置管理过程中的一些心得体会，在此抛砖引玉，供大家参考。
本文来自《pmt评论》总第23期
【篇三：
软件实训个人心得】
《个人模式实训》的个人小结
今天的实训结束了，今天做的是纸牌游戏软件和趣味打字游戏。
今天的东西对我来说有点难度，最后没有能过完全做完。
但是我还是觉得这是一个不错的实训，在这种集体的环境里和同学们一起学习，每天的生活过的也是非常的充实。
此次实践课我的收获很多。
我和同学们这一次真正自己动手制作了一个小软件，虽然还存在很多的问题，而且我做的软件在使用起来还是很不可行的，但是我们从中受到了很多知识，不仅是专业的知识，更让我明白了一个软件从设计到实现的每一个环节真的很不容易，不仅需要扎实的专业知识，更需要一个团队的配合，这才是一个软件成功的关键。
这就告诉我们，一个人的出色不算什么，一个团队的出色才是真正有用的。
刚开始拿到题目我们组员都不知如何下手，经过小组成员一起查找资料，并且开会讨论，我们确定了设计的设计目标以及具体实现方式，包括如何将java的思想运用到实际系统的详细设计之中。
在实验课上，我学会了很多学习的方法。
而这是日后最实用的。
要面对社会的挑战，只有不断的学习、实践，再学习、再实践。
这对于我的将来也有很大的帮助。
以后，不管有多苦，我想我都能变苦为乐，找寻有趣的事情，发现其中珍贵的事情。
就像中国提倡的艰苦奋斗一样，我都可以在实验结束之后变的更加成熟，会面对需要面对的事情，以及学会遇到问题，不急不慌，慢慢解决它。
虽然过程辛苦是不可避免，但收获还是令人感到尤其的欣慰。
在这次的软件设计中不仅检验了我所学习的知识，也培养了我的实践能力，让我知道遇到一个问题，如何去寻找思路，如何去解决问题，最终完成整个事情。
在设计过程中，与同学分工设计，和同学们相互探讨，相互学习，相互监督。
学会了合作，学会了宽容，学会了理解，也学会了做人与处世。
课程设计是我们专业课程知识综合应用的实践训练，是我们迈向社会，从事职业工作前一个必不少的过程。
实验过程中，也十分感谢实验指导老师陈中育老师的指点与教导。
这次软件设计不仅是对这学期所学知识的一种综合检验，而且也是对自己动手能力的一种提高，增强
了自己实践能力。
通过这次课程设计使我明白了自己知识还比较欠缺，只是学习书本知识还是远远不够的，自己不会的东西还有太多，学习需要自己长期的积累，在以后的学习、工作中都应该不断的学习，将课本的理论知识与生活中的实践知识相结合，不断提高自己文化知识和实践能力。
升级会员 