IT项目管理练习1.docx

1.什么是项目管理：是项目的管理者，在有限的资源约束下，运用系统的观点、方法和理论，对项目涉及的全部工作进行有效地管理。即从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。 注：为了协调、整合项目管理知识领域和组织内部的信息，有必要制定一个完善的项目管理计划。项目管理计划用来协调所有项目计划文件和帮助引导项目的执行与控制。这样的话，在其他知识领域制定的计划会被认为是整个项目管理计划的附属部分。项目管理计划包括以下内容：1、项目计划假设和有关选择的决定；2、在利益相关者之间的快捷沟通；3、确定关键管理评审的内容、程度和时机；4、确定测量进展和控制项目的基准。项目管理计划应该是动态的、灵活的并随着环境或项目的改变而改变。这些计划在领导团队和评估项目现状的过程中能给予项目经理以帮助。为了制定和整合一个完整的项目管理计划，项目经理一定要把握项目集成管理的艺术，因为它将用到每个项目管理知识领域的知识。在项目团队和其他利益相关者一起制定一个项目管理计划，能帮助项目经理引导项目的执行，以及更好地把握整个项目。2.项目管理的作用：1、能更好的控制财务、人力和物力起源；2、改进与客户的关系；3、缩短开发时间；4、降低了成本，提高了生产力；5、更高的质量和可靠性；6、更高的边际利润；7、出色的内部协调；8、对达成战略目标的积极影响；9、更高的员工士气。3.三维约束：每个项目都会以不同的方式受到范围、时间和成本目标的约束。在项目管理中，这些限制有时被称为三维约束（triple constraint）。为了使项目成功完成，项目经理必须考虑范围、时间和成本，并平衡这3个经常冲突的目标。为此，必须考虑一下几个方面。1、范围：作为项目的一部分，需要完成哪些工作？顾客或者项目发起人希望从项目中得到什么样的独特产品、服务或成果？如何确认范围？2、时间：需要多长时间完成项目？项目进度如何安排？团队如何跟踪实际进程？谁有权批准进度的变更？3、成本：完成项目都需要话费什么？项目预算有多少？如何跟踪控制成本？谁能授权改变预算？每个项目在建立时，以上三个点都有着各自的目标。如IT合作项目可能会有一个最初的范围：形成一份40-50页篇幅的报告，并对30个潜在的信息技术项目进行1小时的回报。项目经理会进一步定义项目范围，包括对每个潜在项目的描述；一份其他公司已经实施的类似项目的调查；粗略的成本和时间估计、风险评估、潜在回报率的大小，等等。这些目标或许意味着要达到的目的，但并不是真正意义上的目标。三维约束之间的平衡例如：为满足范围和时间目标，可能会增加项目预算。相反，为了满足时间和成本目标，不得不缩减项目范围。有经验的项目经理明白，必须首先判断三维约束中哪个方面是最重要的。假如时间最重要，必须经常改变最初的范围或成本目标以满足日程安排。假如范围目标是最重要的，那就需要对时间和成本目标进行调整。四维约束？质量因素尽管三维约束描述了项目的基本影响因素：范围、时间和成本，以及它们之间的相互关联，但其他因素同样可以发挥巨大作用。质量通常也是项目的一个关键因素，它和顾客满意或者项目发起人满意一样重要。事实上，有些人称项目管理应具有四维约束，即范围、时间、成本和质量，并将质量设置为前三者的核心。有时会出现这样的情况，在达到了范围、时间和成本目标的同时，却没有满足质量要求或令顾客满意，那应该如何避免出现这种情况呢？答案是，优秀的项目管理不应该仅仅只满足项目的三维约束。4.软件生命周期、 引言有很多种不同的生命周期模型用于软件的开发。软件开发的生命周期是以对软件的需求定义为起点，以对软件的正式验收作为终点。它并不是独立存在的，而是一个完整产品生命周期实实在在的一部分。在产品生命周期之中，软件的开发会不断改正其自身的错误并且时常针对软件的需求而进行调整。软件产品最简单的形式只不过是一个程序软件，但实际上确没有那么简单，由于软件产品是由开发出的不同软件部分所构成的一个完整的系统，这将会使产品变的非常复杂。有许多不同的软件开发生命周期模型，但是它们都有一个共同的特点，那就是在生命周期中的某一时刻，软件都会被测试。这篇文章概述了一些常用的软件生命周期模型，并重点强调了在各个模型中的测试工作。、 顺序生命周期模型软件开发生命周期模型以需求定义为开端，以对需求的正式验收作为终结。传统意义上，被用于软件开发生命周期的模型应该是顺序的并且开发过程的各个阶段都经过完善的定义。通常用型生命周期模型和瀑布生命周期模型来表示这种顺序的开发过程。而事实上，这两种生命周期模型有许多不同的形态，将不同的阶段引入生命周期模型，并在不同阶段之间设立边界。以下介绍的生命周期模型的各个阶段是经过许多最有经验的开发者经过反复实践而得来的。图、型生命周期模型图、瀑布生命周期模型 需求分析阶段这个阶段主要是收集并分析用户的需求，并且根据软件需求建立完整而明确的需求说明书。 概要设计阶段在这个阶段，针对用户需求的软件结构将会被设计，并确定软件内部各个部件的相关联系。 详细设计阶段软件各个部件的执行功能将被详细说明。 遍码与单元测试阶段在本阶段，将对软件的各个部件进行编码，并且进行单元测试以确定各个部分确实执行了详细设计阶段所制定的目标。 软件集成阶段这个阶段被测试过的各个部件被逐渐集成起来测试直到构成了一个完整的软件。 系统集成阶段这个阶段将软件程序集成起来，构成产品并进行测试。 验收测试阶段这个阶段将进行测试以验证软件确实完整的执行了用户的需求。、 渐进开发生命周期模型顺序模型（型和瀑布生命周期模型）只是代表着一种理想化的软件开发模型。但实际上出于种种原因，例如需求的多变性和为应付过长的开发时间而开发零时系统的需要，还有其它的生命周期模型将会被采用。现在，让我们以渐进开发的迭代生命周期为例，来看一下其它的生命周期模型。软件开发所具有的一个问题就是用户急需软件产品，但是开发者却要花费很长的时间去完整地进行开发。那么取一个折中的解决方法就是节省一些时间，但在功能上打一点折扣开发出一个功能有所缩减的试用版给用户，作为完整版发布前的一个跳板。也可以将这个跳板作为软件减少软件开发风险的一种方式。在软件开发中，通常将这种方法称为渐进开发或是执行阶段。与之相对应的生命周期模型被称为渐进开发生命周期模型。在渐进开发的生命周期之中，每一个独立的阶段都将遵从型和瀑布型生命周期模型。图、渐进开发生命周期每一个软件的发布都会经过验收测试以证明软件的各个部分所构成的整体确实实现了需求。但是每个阶段的测试和集成将会耗费大量的时间和精力。由于过多的开发周期会增加成本，耗费时间，所以应该经过认真估算，尽早地规划好到底应该使用多少个周期来进行软件的开发。在早期开发出来的产品没有任何的实用价值，只是作为下一步开发的一个原型。这些原型仅仅是用来满足、核对用户关键需求所走的一个捷径。可是如果其中缩减了文档的书写和对软件的测试，那么就有必要将这些将这个原型抛弃并从下一个阶段开始重新设计。因为一个缺乏质量的原形不可能给下一步的开发打下一个好基础。、 迭代生命周期模型迭代生命周期模型并不是一开始就完全适应需求，而是先根据说明先开发软件的部分些可执行部件。而是先开发一些具有部分功能的部件，这些部件要求能够通过审查以确定更进一步的需求。不断重复这个过程，为此模型的每一个周期遍写出更新版本的软件。一个迭代周期模型由下图的四个连续部分组成不断重复组成。图、迭代生命周期模型敏捷软件开发敏捷的推动需自上而下和自下而上同时进行,才有可能成功,敏捷实施失败案例多于成功案例 敏捷强调沟通,各种会议和非正式沟通等手段,如需求宣读会议,头脑风暴,冲刺回顾会议,评审会议等 敏捷实施需要勇气,强调尊重客观事实 敏捷强调团队荣辱,团队成功,团队失败 敏捷重视质量,项目管理中四个因素:范围,成本,质量,和交付日期,其中质量不可调控,其优先级大约为质量交付日期成本范围,重要性递减 敏捷重视个人,敏捷认为个人的情绪波动,天气好坏,交通拥堵等客观因素都会影响开发效率和开发质量 敏捷不适合大型合同类项目,如房地产行业无法通过敏捷实施,但比较适合多变的软件开发 敏捷与PMP都是软件开发方法论,各有千秋,没有具体的上下文则无法简单对比孰优孰劣 敏捷中很重要的一个概念是反馈,反馈带动重构,反馈的方式通过SPRINT回顾会议发生 敏捷中可测试,可演示,可评估,可变化 敏捷强调直指目标,强迫人们关注当下,干扰因素过多则将干扰因素任务分解,按正常工作进行 敏捷方法符合认知论,符合当下的力量 敏捷使企业与员工达到和谐和双赢敏捷开发的12条准则:准则1：Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。 准则2：Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage. 欢迎对需求提出变更即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。 准则3：Deliver working software frequently, from a couple of weeks to a couple of mouths, with a preference for the shorter timescale. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。 准则4：Business people and developers must work together daily throughout the project. 项目过程中，业务人员与开发人员必须在一起工作。 准则5：Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。 准则6：The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。 准则7：Working software is the primary measure of progress. 可用的软件是衡量进度的主要指标。 准则8：Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。 准则9：Continuous attention to technical excellence and good design enhances agility. 对技术的精益求精以及对设计的不断完善将提升敏捷性。 准则10：Simplicity-the art of maximizing the amount of work not done-is essential. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。 准则11：Th