狼大大3640766
软件开发项目管理的目录
第一篇 将消费需求转化为产品规格设计第1章 软件与软件开发项目1.1 软件概念、发展和分类1.2 软件的过程、生存期与开发方法1.3 软件开发项目1.4 软件开发项目管理第2章 可行性研究与软件需求分析2.1 项目可行性研究2.2 对软件项目的经济分析2.3 软件需求分析2.4 软件需求分析方法第二篇 软件项目开发过程管理第3章 软件项目业务规划3.1 软件项目规划与估算3.2 软件生产率与代码行成本3.3 软件项目进度与组织3.4 软件环境与配置3.5 软件配置管理第4章 软件设计与程序编码4.1 软件设计概述4.2 软件设计原理与结构4.3 软件编码4.4 面向对象方法第5章 软件开发项目小组管理5.1 软件开发项目小组建设5.2 软件开发项目小组成员管理5.3 软件开发项目小组成员协调第三篇 软件开发项目后期管理第6章 软件质量管理（成熟度模型与应用）6.1 软件项目管理中的成熟度模型6.2 软件质量成熟度管理与应用6.3 集成成熟度模型与个体软件过程第7章 软件测试与软件维护7.1 软件测试管理概述7.2 软件测试过程管理7.3 软件的维护7.4 软件维护的实施7.5 软件反推工程附录I 计算机软件标准与文档附录II 计算机辅助软件开发（CASE）参考文献
软件项目管理要注意什么呢？
如何在所学的项目管理理论和实际项目实践中找到一条连接的纽带；软件项目管理的度如何把握；为什么项目协调中更多的是貌合神离；为什么自己觉得自己所管理的项目老是失败。
这一连串的问题引起了项目管理者的同感，笔者本人也曾经在项目管理中屡遭挫折，目前的项目管理中依然麻烦不断。
但是，作为一名软件项目管理者来说，在实施项目管理的过程中，笔者觉得在项目管理中，我们的大多数人常常在管理思维中留下一些空白，而这些空白正是我们公正、客观地评判和成功执行软件项目管理的必要途径。
空白1： 为效益而实施项目管理 为什么我们要实施项目管理，是为了提高项目的效益。
这里所指的项目的效益是一个综合性的指标，包括低风险、高产出等。
为此我们不难得出我们在实施项目管理应该掌握的度。
即：引入项目管理后所产生的效益减去项目管理的成本后必须大于未引入项目管理时的效益。
由于引入项目管理后所产生的效益与项目管理的复杂度（项目管理的成本）并非线性相关的，因此项目管理的复杂度必然存在一个最优值，这就是我们应该把握的度。
也许上面的说法比较抽象。
一个实际行之可效的判断项目管理的度规则就是：大家认可并且能够准确地理解和实施。
拿美国项目管理专家James P Lewis的话说就是 KISS原则（Keep it simple and stupid），拿物理学家爱因斯坦的话说就是：Keep it simple ut not too simple. 空白2： 考虑所处环境 任何系统都是建立在一个具体的系统环境中的，一般情况下受上一级系统影响最为显著，这是系统论的观点。
项目管理是企业管理的下属层次，因此在很大程度上项目管理的成功与否常常受企业管理的制度制约（比如说设备采购的批复等待会延误工期），这就是为什么常常会出现计划不如变化来的快的原因。
因为我们在制定计划时根本就没有考虑自身和客户双方的企业管理的环境，所以我们的计划在实施过程中会受到企业管理环境因素的影响。
我敢跟你打赌：在没有人事激励机制常常拖欠或故意克扣员工工资但获得CMM5认证的公司开发效率不会比一个没有实施项目管理的开发团队的效率高多少。
因为恶劣的公司人事制度扼杀了开发人员的天才和积极性。
因此，作为一个项目管理者，审视自身的项目所处的企业环境并做出准确的判断是非常有必要的。
缺少良好的项目环境，项目管理者的心血常常白费。
这往往是我们中的一些项目经理在不同的公司里项目管理表现大相径庭的原因。
此外，正是基于企业环境这样一个观点，目前美国PMI，日本ENAA等提出了项目管理成熟度模型（OPM3和P2M），改变了传统PMBOK的缺陷（忽略外部因素和自身的灵活性）。
有兴趣的项目管理者可以参看有关项目管理成熟度和企业管理方面（建议参看职业经理人方面）的资料。
空白3： 合理评判软件项目管理 我们总是把过多的项目失败归罪到项目经理的名头上。
他们的角色常常是替罪羊而不是领导者，他们拥有的更多的是责任而绝非职权。
实际上项目失败并非完全决定于项目管理，比如说信息系统过低的报价。
一个项目按时在预算范围内完成了而另外一个则没有按时完成，这不意味着第一个项目管理得比较好。
因为前者可能是项目时间和成本宽松的项目而后者根本就是不可能完成的项目。
前者项目管理的意义在于获得较高的项目效益而后者的意义在于避免更大的项目损失。
很可惜，充满了浮躁的软件企业没有诸如此类的意识，一些项目在未开始前注定就是失败的，项目经理们一上手便被扣以一责任人的镣铐。
因此，项目管理有无具体效果，需要合理地进行评判，单纯以出效益为上的观点未必有失偏颇。
空白4： 心理学的必要性 没有一个领域像软件项目管理中人的因素更为重要，在软件领域没有实现自动化之前，一切试图取代人的主要作用的机制都是收效甚微的。
人的行为是心智活动的表现。
开发人员的心理活动决定了其在开发的表现。
合适的压力能够勾起开发人员的成功欲望但是过大的压力却直接影响着项目参与者的身心健康。
特别是后者一直以来都未能引起软件开发界的重视。
很多人曾经有过不明不白的辞职经历，在没有学习《管理心理学》之前，笔者对这些人的＂过激＂行为有时想想都觉得奇怪。
作为一个软件项目管理者，不了解和掌握管理心理学，很难针对复杂多变的人的因素采取合理的应对措施，同时自身的心理健康也未必能够得到保证。
为此笔者建议有条件的软件企业，可以通过聘用心理顾问来处理员工的心理问题，以此缓和由于工作压力而导致的员工之间矛盾冲突和项目坍塌。
空白5： 尊重常识，系统性考虑问题 这个观点笔者在《软件项目管理原则谈》已经重申过。
就像不要指望人一秒钟跑二十米一样指望项目中有过多的奇迹出现。
可惜我们中的大多项目管理者在进行项目管理时依然实施＂***＂。
我们的管理者都知道自然规律不可违抗性，但是却很少有人意识到一些社会规律的不可违抗性。
他们总以为唯物的主观能动性能够替代实际，产生奇迹。
加班被认为是解决资源匮乏的唯一途径，通过开发人员＂无上＂的生产力来达成项目的成功。
很少有人会意识到加班造成的疲劳会再次使工作效率降低...
软件项目管理有哪些呢？
软件项目的目标不仅仅是进度目标和成本目标，更重要的就是质量目标，质量直接决定了软件产品能否生存已经后续的升级和维护等工作量。
这里只谈为了提高软件质量可能采取的各种活动，但前提仍然是我们在做项目计划的时候首先要根据需求确定质量目标和制定质量计划。
1.过程 要提高质量需要强调我们对产品质量的保证不是依靠的团队中一两个重要成员，而是我们有相应的过程和方法论来保证质量，保证产品质量的过程是可以持续的。
对于很多项目我们都不建议采用CMMI里面较为重量级的各种过程，但是对于产品质量提升有帮助的各种过程我们仍然需要去将其规范化和流程化。
与此相关的主要有规范类的文件，比如需求编写模板和规范，设计规范和模板，代码编写规范和模板，数据库设计的规范和模板，界面设计规范和模板，测试用例模板。
对于过程管理方面需要定义的主要有任务和工件的输入输出要求，配置管理和源代码管理，软件生命周期模型，缺陷跟踪和管理，问题和风险跟踪管理，变更管理。
2.培训 最重要的质量意识就是预防胜于检查，强调一次要事情做对，强调上游工序为下游提供合格的中间产出物，尽量减少各种缺陷的泄露。
很多时候质量问题并不复杂，更多是团队成员没有质量意识，没有负责任的工作态度。
提升质量最关键有两个方面，首先是我们都有意愿和意识来提升产品质量，其次是我们要有相应的能力和技能来保证产出物的质量。
第一点我们依靠的团队绩效规则的建立，团队建设，质量文化的组建形成，员工态度和责任感的培养等内容。
第二点我们强调的是培训，以师带徒，自我学习，个人知识管理方法，问题管理，学习型组织，读书会等各种方式来提升技能。
3.评审 评审是软件开发过程中保证质量的一个重要活动，项目软件开发往往会跟踪选择的软件生命周期模型分为多个阶段，对于较大点的项目还有严格的岗位角色划分，每个阶段都是不同的成员在进行工作。
因此如果各个阶段的产出物的质量不能够很好保证的话，将导致缺陷泄露和后续大量的返工，这些都是我们不希望看到的坏质量成本投入。
首先评审不是来检查产出物的各种低级错误的，每个人在思考问题上都有局限性和盲点。
评审是涉及到需求，设计，开发，测试等各种角色的成员共同来从不同的角度来发现工件的各种问题。
比如对于需求问题，测试人员在评审的时候重点关注的是该条需求描述和业务规则的可测试性，而设计和开发重点是可实现性。
评审涉及到正式同行评审，多人复审，单人复审，代码走查等各种方式，需要根据项目的实际情况来选择使用。
我们需要重点防止的就是需求和总体设计阶段的缺陷泄露，对于这种泄露往往都会造成大量的返工。
4.测试 测试是保证软件质量的最后一道关口，是一种迫不得已的行为，根据我们的质量意识应该要尽量做到问题不是到测试阶段才发现和暴露出来。
很多问题在测试阶段才发现返工成本都是很大的。
测试有单元测试，集成测试和系统测试，验收测试等各个阶段。
在某一个功能或模块在交付给测试人员进行测试的时候，开发人员应该根据需求和设计进行较为充分的自测。
这样的话系统测试的重点才能够真正去关注全流程的贯通和各种可能的业务场景组合和编辑，而不是关注某一个具体的实现功能点。
项目管理中的软件项目管理是怎样的？
为什么要有专职的项目经理？ 专业化是一个趋势，因为在专业化的条件下，可以有效降低成本，提高利润率。
项目经理的工作内容归根到底只有一项：识别并管理风险。
这项工作的目的是控制项目成本。
由于项目的风险是多方面的，而且风险的表现形式也是多种多样的。
从风险范围上来说，既有公司内部风险，也有和客户交流、合作的风险；从风险的类型上来说，既有管理风险，也有技术风险；从风险产生的阶段来说，包括了从业务分析到上线后维护的项目周期？ 我认为一个项目经理是否优秀，主要是看他/她能在多大程度上提前识别并消除风险，而不是弥补和解决了多少问题（风险未被及时识别或妥善处理，就会转换成问题）。
当然能弥补和解决问题的项目经理也是相当合格的，但还不够优秀。
项目组的范围界限在哪里？ 我认为项目组的范围界限可以有三种划分： 1、包括客户方所有参与该项目的立项、调研、审批、测试和使用人员，包括开发商市场开发、管理审批、商务谈判、后勤保障和具体负责该项目开发的人员； 2、包括客户方项目经理、业务需求提出人和测试人，包括开发商具体负责该项目开发的人员； 3、仅包括开发商具体负责该项目开发的人员。
大部分人在思想上可以接受范围1，而在实务中接受的是范围3.而我个人认为项目经理，特别是开发商方面的项目经理应该采用的是范围。
对项目组范围理解不同，将影响项目经理对工作的处理方式，范围1实际上是很虚的，在项目管理实务操作中没有太大的意义；而范围3实质是把客户方和该项目有密切关系的人与开发商具体负责该项目开发的人对立起来，也就是所谓的甲方、乙方。
在这种对立的前提下处理项目的分歧和矛盾，效果肯定要打折扣。
而按范围2来理解，在项目管理实务中项目经理就必须要让客户方和该项目有密切关系的人也接受这一观点，从而拆除双方之间的＂障碍＂，达到相互信任、相互尊重、共同协商解决问题的良性氛围，以达到降低项目外部风险的目的。
当然，这样就增大了项目经理工作的难度，但对项目的成功则是很重要的。
项目管理软件都有哪些？哪些比较好？
这个没法直接给你介绍，一、不知道你公司的承受价位是多少；二、不知道哪款更适合你。
好与不好这个太主观对你没有什么帮助意义。
有一些心得和你分享一下希望对你有帮助：首先，看软件的容量，考虑系统能否处理你预计进行的项目数量、预计需要的资源数以及预计同时管理的项目数量。
其次，注意文件编制和联机帮助功能，主要考虑用户手册的可读性、概念的逻辑表达、手册和联机帮助的详细程度，举例说明的数量、质量、对高级性能的说明水平。
然后，看看可利用的功能，考虑系统是否具备项目组织所需要的各种功能。
除此以外，还有注意几点，软件与其他系统的兼容能力、安装要求、报表功能、安全性能、经销商的支持、操作简易性。
市面上一般常用的国外的有Oracle 公司的Primavera P6、Artemis 公司Artemis Viewer、NIKU 公司的Open WorkBench、Welcom 公司的OpenPlan；国内的公司有禅道项目管理软件、智邦国际项目管理软件等。
国外的一般比较贵，你参考下
软件项目管理与一般项目管理的区别是什么？
通常意义上来说，软件项目管理是指软件开发过程的管理，来源是项目的立项报告和开发任务书，结果是可部署的软件系统。
软件工程是软件开发遵循的一般性指导，是项目经理和开发人员必须掌握的，一般都作为一门课程教学，ISO9002和CMM是我们经常具体使用的指南。
IT项目管理涉及面就较广了，不但要考虑软件系统，还要涉及网络基础设计、软硬件平台、运行维护管理等。
软件估算的戒律（1）不要追求完美：就像没有人能预测出未来，如果还没有完成，就不要企图完美的结果。
更何况估算的太精确，反而会失去灵活机动的空间。
（2）不要为满足预算而估算：如果这个项目的预算根本不能完成100%的任务，那么就不要让你的团队委曲求全。
正确地反映客观现状，不仅可以争取应得的权利，而且是完成任务的前提。
（3）不要随意削减估算结果：有很多老板喜欢把项目经理递交的估算，不假思索地砍掉一部分。
这是一种不负责任的做法，如果要削减一定要有理由。
（4）客观地估算，不贪多不偷减：就像老板不能随便削减你的估算一样，你也同样不能在估算的时候，贪多或是偷减。
贪多必然导致会浪费，偷减必然导致不足。
这两个结果恐怕都不是一个合格的项目经理的作为。
（5）客观利用过去的经验：对于以往估算的经验，当然是宝贵的财富，但是如果财富用错了地方就会变成垃圾。
在使用经验时，要注意现在和参考经验之间的差异。
不要忘记，随着时间的推移，计算机领域技术的更新，许多观念都在发生着改变。
（6）不要以客户目标作为估算的结果：客户是上帝，软件公司一定要尽力实现客户的需求。
但我们要实现的是合理的目标，况且不能为了完成目标而去堆积数字，这样岂不是因果倒置了。
（7）不要隐匿不确定的成本：软件开发中存在潜在风险，是很正常的事情。
现在风险就会带来潜在的成本，如：突然一位程序员离职，导致工作进度路落后。
我们不可能估算到任何一种可能发生的情况，但有责任把可能出现的一些关键环节列出来。
什么是软件项目管理？
软件项目管理是为使工作项目能够按照预定的需求、成本、进度、质量顺利完成，而对人员、产品、过程和项目进行分析和管理的活动。
我们团队现在使用的是日事清，日事清日报的基础模版是KPTP，四个部分就组成了一份清晰明了的工作记录，这样的记录既能充分体现你当前的工作状态，又能层次分明地向领导传递工作困难与你的工作能力。
软件项目管理是什么
首先，项目的定义是：为实现某一特定目的而做出的一次性的努力。
它包括范围管理，进度管理，时间管理，质量管理，成本管理，风险管理，需求管理，沟通管理，集成管理，配置管理，人力资源管理等。
范围管理是基础，成本管理，时间管理，质量管理是核心。
人力资源管理是支持性计划。
九大管理相互协调，共同协助完成整个项目
软件项目管理的大概流程是什么？
项目管理的对象是工程项目。
它所涉及的范围覆盖了整个工程过程。
为使项目开发获得成功，关键问题是必须对项目的工作范围、可能风险、需要资源（人、硬件/）、要实现的任务、经历的里程碑、花费工作量（成本）、进度安排等做到心中有数。
这种管理在技术工作开始之前就应开始，在从概念到实现的过程中继续进行，当工程过程最后结束时才终止项目管理是为了使项目能够按照预定的成本、进度、质量顺利完成，而对人员（People）、产品（Product）、过程（Process）和项目（Project）进行分析和管理的活动。
项目管理的根本目的是为了让项目尤其是大型项目的整个生命周期（从分析、设计、编码到测试、维护全过程）都能在管理者的控制之下，以预定成本按期，按质的完成交付用户使用。
而研究项目管理为了从已有的成功或失败的案例中总结出能够指导今后开发的通用原则，方法，同时避免前人的失误。
项目管理的提出是在20世纪70年代中期的美国，当时美国国防部专门研究了开发不能按时提交，预算超支和质量达不到用户要求的原因，结果发现70%的项目是因为管理不善引起的，而非技术原因。
于是开发者开始逐渐重视起开发中的各项管理。
到了20世纪90年代中期，研发项目管理不善的问题仍然存在。
据美国工程实施现状的调查，研发的情况仍然很难预测，大约只有10%的项目能够在预定的费用和进度下交付。
1995年，据统计，美国共取消了810亿美元的商业项目，其中31%的项目未做完就被取消，53%的项目进度通常要延长50%的时间，只有9%的项目能够及时交付并且费用也控制在预算之内。
项目管理和其他的项目管理相比有相当的特殊性。
首先，是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。
其次，系统的复杂性也导致了开发过程中各种风险的难以预见和控制。
Windows这样的操作系统有1500万行以上的代码，同时有数千个程序员在进行开发，项目经理都有上百个。
这样庞大的系统如果没有很好的管理，其质量是难以想象的。
项目管理的内容主要包括如下几个方面：人员的组织与管理，度量，项目计划，风险管理，质量保证，过程能力评估，配置管理等。
转载请注明出处51数据库 » 软件项目管理 生存期
