软件项目性能要求吗 软件项目性能效率测试
项目管理软件有用吗？
楼上有两位已经把项目管理软件的重要性说的比较清楚了，就我个人理解，简单来说就是让管理者轻松地掌握项目的进度，而具体的负责人员也可以明白自己在特定时间段内该完成的内务。
从上到下都知道自己在干嘛，该干成什么样子，什么时候该完成。
项目管理顾名思义是对项目进行管理，所以任何有项目需要管理的企业都需要这种软件的。
所以也就没有特定性质的什么企业需要，有项目就用项目管理软件罗。
楼上的都没有进行品牌推荐，我还是推荐一下吧，我是最近才开始用这家的，虽然不知名但软件和价格都很实在，物美价廉谁都喜欢吧~所以让大家知道也不是坏事。
全程软件的PM任务项目管理软件。
就是这个了，其他的太贵我们都没考虑，所以只推荐这一个。
希望有帮助到你~
项目管理软件需要具备哪些功能呢？
从定制一个软件项目到最终的实现不仅是个漫长的过程，也是充满变数的过程，全面理解与正确领悟用户需求演变的本质与应对的策略应当是需求分析人员所要具备的素质。
有理由认为面向对象的理念降低了开发过程的难度，但却强化了需求分析在项目过程中的地位与作用。
需求分析人员是否具备、是否能够驾驭面向对象的概念对项目的成功率关系会更加重大。
下面就说明一下需求分析与项目风险的关系。
1.来自用户的风险 投资者总是在摸索的过程中不断调整自己的实现目标，尽管软件开发商使尽浑身解数也跟不上用户需求的变化，最终只能是疲于应付敷衍了事。
投资方的感觉是上当受骗却又无可奈何，开发商则抱怨用户需求漫无边界、任意变更。
这种公说公有理、婆说婆有理的局面在合同条款中难分伯仲，不能说是两败俱伤，起码也是各有苦衷。
造成这种局面固然存在着客户方的原因，但要把责任全部归结给“上帝”似乎也有失公允，因为用户对于计算机应用毕竟是外行。
现实地说问题解决的关键只能是提升自身的设计能力来化解这种项目过程中可能出现的危机，所以需求分析在项目过程中的作用就像航标或是舵手，一旦有所偏颇对项目过程影响重大。
“对象”作为最接近真实事物的载体，把主观思维与客观事物形成映射关系。
通过这种映射把设计构思的模式标准化，把实现的方式规范化，这就是“对象”在软件设计过程中的作用。
所以，需求分析过程中善于发现与发觉可以被归结成“对象”的元素非常必要。
它以体现为承载技术设计的单元载体，也可以被构造成同时承载技术与业务的合成载体。
面向对象的设计理念为软件的开发开辟了一条前所未有的光明之路，但要想在这条路上走好，就要学会全面应用并自由驾驭面向对象的理念。
规避项目过程中的风险，应当是从需求构架的构思过程开始，而不是在设计过程中开始。
2.来自开发过程的风险 如果基于“面向过程”的开发理念，面对项目过程中源源不断的用户需求及频繁的功能变更，会使开发效率、工程质量与服务能力面临着严峻的考验。
进度停滞不前、性能难以把握、可靠程度低、测试工作量大、整体成本失控等一系列的问题很可能发生，最终导致交付周期长、实施难度大、应变能力差、相对寿命周期短的必然性后果。
面向对象的诱惑力就在于它能彻底改变这种困惑被动的局面。
达到设计目标的途径可以有很多种，如果没有得力的指导与约束，问题就会变得复杂起来。
设计者常常会在仁者见仁、智者见智的抉择中困惑不已，而客观评价这些主观构思方面的优劣并没有多大的说服力，这里有技术上的原因，也有思维方式不同、习惯上的差别、视野视角的变化等原因。
这往往是造成项目管理难度大、可控性不强的主要原因之一。
对于专业人士来说崇尚“阳春白雪”的高雅固然没错，但如果对“下里巴人”的技术不屑一顾也未必就是合理的选择。
因为“阳春白雪”会意味着更多成本的支出，如果“下里巴人”能够兑现订单也未必非要“阳春白雪”不可。
技术的意义在于创造价值并兑现市场利益，当企业面对市场的时候，驾驭技术的本质并不在于技术本身，如何用尽量小的代价获取相对好的市场回报才是技术价值的意义所在。
推崇先进的开发理念并不等同于对技术的迷信或盲目崇拜，技术对于企业来说只是一个生产手段，而不是研究的对象。
忽略技术在企业过程中的作用并不妥当，但盲目追求技术上的先进性也同样具有极高的风险性。
制定技术路线、把握技术介入的深刻程度都是决定项目盈利能力的控制要素。
软件企业中不能没有技术，但企业毕竟不是基础技术的机构，这也是技术管理人员经常容易步入的一个误区。
在引入了面向对象的理念之后，通过对象的封装可以在很大程度上形成设计实现的客观约束，从而避免过多的自由发挥空间，使整个团队能够沿着基本相同的设计方式完成设计任务。
关于业务对象的抽象与封装如果是从实现的过程中去总结摸索，将会是一个漫长而重复的实践过程，如果在需求分析阶段就能够造出对象原型，对于有效屏蔽上述种种风险具有非常明显的改进效果，也就是说面向对象绝不仅仅是编程人员需要掌握的理念，需求分析人员对此理念的驾驭能力对项目的影响程度要比程序员多得多。
【软件项目经理岗位要求】软件项目经理的要求
项目经理是项目组织的管理者，负责对项目的计划、组织、领导和控制等工作，因此，一个项目经理必须具备以下几方面的能力 （一）领导能力 项目领导工作包括有效的沟通和有效的激励，要使项目团队成员齐心协力地工作，实现项目目标，必须进行有效的领导。
1.项目经理需要采取民主式的领导方式 对于项目经理而言，采用这种领导方式比主要依靠职权的独裁式或命令式的管理方式更为有效，这是因为项目组织是一个临时性的组织，且由各方面的专家组成，项目本身涉及面广，只有充分调动每位组员的积极性，在遇到问题的时候，与大家共同商量解决问题的方法，授予下属更大的工作自主权，才会实现有效的领导。
2.懂得激励成员的因素，并能设计出一种富于支持和鼓励的工作环境。
项目经理可以通过鼓励全体项目组织成员的积极参与来创造出这样一个环境。
1）.使项目组织成员了解项目结果和利益的蓝图 如某一项目目标是对工厂进行全新设计，那么项目经理就应将这一目标生动地描绘出来，把实现这一项目目的的益处向大家解释清楚。
如消除生产上的瓶颈问题，增加产量，减少库存等。
这样，当大家都清楚通过自己的努力，可以达到的美好结果时，就会更加热情地投入工作。
2）.授权 通过授权，使成员拥有实现自己工作目标的决策权力。
如让成员拥有制定工作计划、决定如何完成任务、控制工作进程以及解决妨碍工作进展问题等方面的权力，这样的授权，能使每个人的工作内容更有挑战性，能够满足组织成员受尊重、实现自己价值等需求的满足。
3）.奖励 奖励是一种动机强化的手段，通过奖励对期望的行为具有激励作用，被认同或得到奖励的行为会重复发生，如项目组成员提前完成了一项重大任务或发明了一种可加快项目进程的工作方法，而受到奖励，这样会鼓励大家在未来的工作中保持和发扬这一良好作风。
奖励的方式很多，如金钱、口头鼓励、表扬、赞赏、奖品等等，应注意奖励的方式，只有能满足成员需求的奖励，才能起到激励作用。
一种最简单有效的激励方式是对项目组中每位成员的工作表现出真诚的兴趣，当成员向你汇报他们的工作时，要全神贯注地听。
然后，向他们提一些有关工作的问题，并用“谢谢”“干的不错”“很好”等语言来表达对他们付出的认同和赏识。
在成员之间创造一种同志式的友谊与忠诚 项目工作应该充满乐趣，项目经理应从工作中获得乐趣，也应鼓励项目团队成员获得同样的乐趣，项目经理应信任每个成员，为大家提供有挑战性的工作。
同时，通过不定期地举行一些聚餐、野餐或庆功会等等方式提供大家交流的机会，建立一种相互信任，充满乐趣又有远大前途的工作环境，创造一种同志式的友谊与忠诚。
3.项目经理要言行一致，身体力行 要为组织成员树立榜样，如果希望成员为赶进度而加班，自己应该首先留下来而不是提前离开。
（二）人员开发能力 有效的项目经理会对项目成员进行训练和培养，使组织成员有机会增加自身价值，使每个人在项目结束时，都拥有比项目开始时更丰富的知识和竞争能力。
1.项目经理应创造一种学习环境，使员工能从他们所从事的工作中，从他们所经历或观察的情景中得到知识。
如尽可能给成员分配全面的任务，使他们丰富知识。
如让一个没用过Excel的人去用Excel处理数据，这就能使他学会使用Excel。
或是让一个阅历不足的成员能跟经验丰富的成员一起工作，使新的成员从经验丰富的人那里学到更多的东西。
2.让他们参加正式的培训课程。
（三）沟通能力 一个项目经理，一定要是一个良好的沟通者，他需要与项目组织成员、承包商、项目业主以及相关的各方面进行沟通，只有通过有效的沟通，才能了解掌握各方面的情况，及时地发现潜在的问题，征求到改进工作的建议，协调各方面的关系。
沟通包括口头沟通和书面沟通。
口头沟通是通过语言来传递信息，在项目早期，面对面的口头沟通对促进项目组织的团队建设，发展良好的工作关系和建立共同目标是特别重要的。
项目经理也应主动拜访项目业主、公司上层管理者、以及项目相关部门，了解他们各自的想法，争取建立良好的关系，也应经常与项目组成员进行口头沟通以增进了解。
另外定期组织会议也是必不可少的，包括： 情况评审会——通报情况，找出问题解决问题会议——针对问题召开有关人员会议技术设计评审会——对提出的设计方案进行评审 书面沟通是通过文字来传递信息。
如，内部备忘录、信件、进度报告、项目总体报告等。
另外，优秀的项目经理会注意倾听项目业主表达的期望和要求，项目组成员的意见和关注所在，听比说获益更多。
（四）处理矛盾冲突的能力 1.项目工作中的矛盾冲突 项目管理中自始至终存在着矛盾冲突，在项目的各层次和全过程中都会产生矛盾冲突，项目经理经常要处理项目运行中产生的各种矛盾冲突，特别是在组织机构重新组合和多个项目都在争取共享有限资源的情况下，矛盾冲突尤为突出，在管理方面主要的矛盾冲突可能来自： 1）.进度方面的矛盾围绕完成项目的时间，各项活动顺序安排等方面存在的不一致。
2）.资源分配方面的矛盾要保证项目完成，项目组织与职能部门之间...
软件项目需求分析为什么困难？
1）客户说不清楚需求； （2）需求自身经常变动； （3）分析人员或客户理解有误。
1、客户说不清楚需求 有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。
例如全国各地的很多政府机构在搞网络建设，这些单位的领导和办公人员大多不清楚计算机网络有什么用，反而要软件系统分析人员替他们设想需求。
这类工程的需求是如此的主观，以致产生很多贪污腐败现象。
有些客户心里非常清楚想要什么，但却说不明白。
读者可能很不以为然。
就举日常生活的事例吧，比如说买鞋子。
考试大收集我们非常了解自已的脚，但没法说清楚脚的大小和形状。
只能拿鞋子去试，试穿时感觉到舒服才会买鞋（居然也有神通广大的售货员，看一眼客户的手，就知道应该穿什么样的鞋）。
如果客户本身就懂软件开发，能把需求说得清清楚楚，这样的需求分析将会非常轻松、愉快。
如果客户全不懂软件，但信任软件开发方，这事也好办。
分析人员可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。
最怕的就是“不懂装懂”或者“半懂充内行”的客户，他们会提出不切实际的需求。
如果这些客户甚至觉得自己是上帝的爸爸，那么沟通和协商都会很困难。
2、需求自身经常变动 唐僧曾说：“妖要是有了仁慈之心，就不再是妖，是人妖。
”（《大话西游之大圣娶亲》） 连妖都会变心，别说人了。
所以喜新厌旧乃人之常情，世界也因此变得多姿多彩。
软件的需求会变化吗？ 答：据历史记载，没有一个软件的需求改动少于三次。
唯一只改动需求两次的客户是个死人。
这个可怜的家伙还是在运送第三次需求的路上被车子撞死的。
让我们先接受“需求会变动”这个事实吧，免得在需求变动时惊慌失措。
明白“需求会变动”这个道理后，在进行需求分析时就要留点神： （1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。
考试大收集以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。
（2）在合同中一定要说清楚“做什么”和“不做什么”。
如果合同含含糊糊，日后扯皮的事情就多。
要防止象韩复渠那样，在别人请他喝酒吃饭时他什么都点头（人家就更加献殷勤），吃完了他就宣布刚才答应的事都不算数，便扬长而去。
3、分析人员或客户理解有误 有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。
它们喝汽油，靠四个轮子滚动前进。
嗓门极大，在夜里双眼能射出强光。
……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。
” 软件系统分析人员不可能都是全才。
客户表达的需求，不同的分析人员可能有不同的理解。
如果分析人员理解错了，可能会导致开发人员白干活，吃力不讨好。
我读中学时候最怕写作文逃题，如果逃题了，不管作文写得多长，总是零分。
所以分析人员写好需求说明书后，要请客户方的各个代表验证。
如果问题很复杂，双方都不太明白，就有必要请开发人员快速构造软件的原型，双方再次论证需求说明书是否正确。
由于客户大多不懂软件，他们可能觉得软件是万能的，会提出一些无法实现的需求。
有时客户还会把软件系统分析人员的建议或答复给想歪了。
有一个软件人员滔滔不绝地向客户讲解在“信息高速公路上做广告”的种种好处，客户听得津津有味。
最后，心动的客户对软件人员说：“好得很，就让我们马上行动起来吧。
请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。
”
要提高软件项目计划的准确性需要掌握哪些内容？
1.加强基础数据的统计与分析 软件项目都是具有独特性的，不能照搬其他项目的经验作为制定本项目计划的依据。
因此，在企业范围内加强对项目基础数据的统计分析以得出规律是十分必要的。
项目管理既是科学又是艺术，由于文化的差异，西方发达国家强调的是管理中的科学性，而我国的绝大多数企业强调的是管理中的艺术性。
由于不重视基础数据的收集和统计，软件项目的计划常常是凭经验或“拍脑袋”而定的，企业并没有足够的统计数据来支持计划的制定。
科学管理尽管是在上个世纪初，对制造业和体力工人提出的，但其中提出的“不能度量就不能控制”的理念依然值得软件企业在管理项目时采纳。
2.以面向学习和改善系统的评价原则促进数据统计 评价方式将决定人们的行为，要想改变人们的习惯，仅靠讲道理是难以见效的，还必须辅之以相应的评价体系。
软件企业在项目管理评价进程的一个误区是将评价的重点放在人的方面，而忽视了很多项目问题在于管理系统本身这个事实。
据统计，人员的敬业精神和能力不够只占项目失败原因的10%左右，在大约90%的原因来自于项目管理系统的架构与流程等方面。
3.谨防里程碑陷阱 众所周知，里程碑是项目计划与控制中的一个极为重要的概念，也正因为如此，人们也易于过于依赖里程碑，反而使项目计划落空。
里程碑陷阱表现在以下几个方面：首先，人们在软件项目的里程碑被设定以后，认为“目标管理是只问结果，不计过程”，从而忽视对过程的监控而导致项目里程碑不能按期达到。
大多数软件企业的从业人员属于知识工作者，他们对授权的要求较强烈，这方面的误区更易发生。
第二，对里程碑控制不严。
因为大部分里程碑毕竟只是一些项目的中间结果，在项目过程中人们易于放松对里程碑变更的控制，易于出现里程碑大多按期完成而项目却难以按期完成的现象。
项目活动彼此是有关联的，一个里程碑的延迟会导致连锁反应，甚至可能导致项目工期的失控。
第三，里程碑的设置仅仅由项目组根据项目本身的特点而定，忽视了与利益相关者的沟通并得到他们的承诺。
建筑工程方面都有自己专用的项目管理软件吗？
前言：在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能 ，优化性能，提高用户友好性的要求。
在软件项目管理过程中，项目经理经常面对用户的需求变更。
如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。
这决定了项目组必须拥有需求管理策略。
需求管理复杂性分析 软件需求是整个软件开发项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，他的复杂性体现在以下方面： 1、需求的描述问题。
缺少正式的完整的需求文档浪费了大量的人力物力，但是有了需求文档又出现了新的问题。
在用户方进行的需求评审会完全是走形式，因为用户根本不去听他读那上百页的需求文档。
不同层次的客户（用户）关心的问题是不一样的，想要每个客户都成为需求专家是不现实的。
2、需求的完备程度问题。
需求如何做到没有遗漏？如何准确划定系统的范围？这确实是一个两难问题，稍微大一点的系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至于系统没有一个准确的范围界定。
即使是这样，系统还是要开发，没办法，系统的范围还要硬性的划定一个，从而建立一个基线。
3、需求开发的工期问题。
在需求上花费了大量的时间，客户、软件公司是否能够忍受？为了确保需求的正确性，完备性，项目经理往往坚持要在需求阶段花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已！他们往往会逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变的需求折腾的筋疲力尽，他们也希望尽快结束此阶段。
4、需求的细致程度问题。
需求到底描述到多细，才算可以结束了？仁者见仁，智者见智，并没有定论，如果时间允许，要想细总可以细下去的。
但是，需求的周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求越高，所以只要大家（客户、用户、需求分析人员、设计人员、测试人员）认为描述清楚了，就可以进入设计阶段了。
5、需求的变化问题。
在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。
软件开发的过程实际上是同变化做斗争的过程，需求的变更不一定是坏事，也有可能是好事，是商业机会，对市场敏感的人可以从需求的变化中发现市场机会。
需求变化的原因很多，如： 一开始没有识别全，需要增加需求； 业务发生了变化，需求必须变化； 需求错误； 需求不清楚。
需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办？管理它！使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。
难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是项目需求的渐变（Poject Scope Ceep）问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定层度时，双方才蓦然回首，发现已经物是人非，换了一番天地。
需求管理策略 需求管理需要遵守以下策略： 1、需求一定要与投入有必然的联系。
需求一定要与投入有必然的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。
人们常说世上没有免费的午餐，同样也不应该有免费的需求变更。
但是，接受需求变更目前却是软件开发商不得不咽下的苦果。
所以，在项目的开始无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。
2、需求的变更要经过出资者的认可。
需求的变更引起投入的变化，所以要通过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。
笔者曾经经历过一个项目，为了避免项目的风险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过程提出了大量“小的需求变更，当开发人员按此需求变更修改了软件时，在项目进入现场实施阶段时，却有大量的这些变更需要改回去，问题就是出在我们的项目组成员视该用户代表的需求为圣旨，却忽略了需求是否经过了客户方真正有决策权的人员的认可。
3、小的需求变更也要经过正规的需求管理流程。
小的需求变更也要经过正规的需求管理流程，否则会积少成多。
在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。
正式由于这种观念才使需求的渐变不可控，最终导致项目的失败。
4、精确的需求与范围定义并不会阻止需求的...
软件项目设计和开发评审要求有哪些呢？
a）设计和开发评审应分级进行。
公司级的项目应进行公司级评审；业务部门级的项目一般进行业务部门级评审； ）设计和开发评审视具体情况可一次进行，也可分段进行； c）评审结论应明确； d）评审资料应及时归档。
6 评审依据 a）合同、技术协议书、需求规格说明书和设计任务书； ）有关标准、规范和质量保证文件。
7 评审内容 评审的内容可根据产品设计的研制周期、技术难度、复杂程度以及使用方的要求有所侧重和适当的增减，但应满足对设计结果进行评审的要求。
主要内容： a）设计方案正确性、先进性、可行性和经济性； ）系统组成、系统要求及接口协调的合理性； c）系统与各子系统间技术接口的协调性； d）采用设计准则、规范和标准的合理性； e）系统可靠性、维修性、安全性要求是否合理； f）关键技术的落实解决情况； g）编制的质量计划是否可行。
-