项目管理tool_lessons

Lessons Learned from Tool Adoption1

Karl E. Wiegers

Process Impact

https://www.wendangku.net/doc/9a19049803.html,

Software engineers talk a lot about using tools to help them perform development, project management, and quality tasks. They evaluate quite a few tools and buy a fair number, but they seem to use few tools in their daily work. Selecting and installing a software tool is the easy part. It is much harder to make effective tool usage an integral part of your group’s software engineering practices.

Tool adoption initiatives often stumble because people don’t fully appreciate the technical, managerial, and cultural factors that influence success. Here are eight lessons I’ve learned from groups attempting to use a variety of software development tools. Some of the lessons apply to any kind of tool adoption; others are most pertinent to computer-aided software engineering (CASE) tools for systems analysis and design. Keep these lessons in mind to increase the chance that your next tool investment will yield the desired payback.

General Lessons for Tool Adoption

Most tools that are available to the contemporary software developer or project manager belong to one of these categories:

?Project management tools: These help your team estimate, plan, and track schedules, resources, effort, and costs.

?Analysis and design tools: These help you document, analyze, and manage requirements or create design models.

?Coding tools: These include code generators and reformatters and code analysis and reverse engineering tools.

?Quality improvement tools: These include test planning and execution tools, and static and run-time code analyzers.

?Configuration management tools: These let you track changes and defects, control access to files, and build your product from its components.

Most tools save time and reduce errors by automating a part of your development or management process. Tools that let you iterate on designs or accurately repeat tests can lead to higher quality and projects that are more successful. Defect-tracking tools ensure that problem reports do not get lost, and source control tools prevent one programmer’s changes from obliterating another’s. However, the first lesson to keep in mind is:

1 This paper was originally published in Software Development, October 1999. It is reprinted (with modifications) with permission from Software Development magazine.

A tool is not a process.

For example, development groups sometimes believe that because they are using a tool to track defect reports, they have a defect-tracking process. In reality, a tool merely supports a process. The process defines the steps that you must perform to carry out some activity correctly. Team members must share a common understanding the steps and the roles and responsibilities of the process participants.

I once implemented a new change control system in a web development group. First, I wrote a change control process, which the team members reviewed and accepted. We then beta-tested the new process using paper forms for a few weeks while I selected a commercial issue-tracking tool. Feedback from the beta helped us improve the process, and then I configured the tool to support the new process.

Introducing tools into a group can be disruptive. New ways of working demand new ways of thinking, and most people aren’t eager to be forced out of their comfort zones. To succeed, the team members must agree on some conventions for using new methods and tools. This transformation requires both culture and technical changes. This brings me to lesson two: Expect the group to pass through a sequence of forming, storming,

norming, and performing when it adopts new tools.

Forming, storming, norming, and performing describe the stages through which a new team progresses. These terms also characterize a software group trying to apply new approaches. During forming, the team selects a tool. During storming, team members debate how to use the tool, whether or not it is a good investment, and how to interpret the rules embodied in the tool or in its underlying methods. If you stop at storming, your team will not evolve to an improved future state that includes the tool. Storming is part of the learning curve, the cost of investing in new approaches that promise to yield long-term benefits.

Guide your team through the storming stage, relying on the team members’professionalism and willingness to compromise. It should then enter a norming stage, where the team agrees on how to apply the tool. Some individuals won’t always get their way but everyone must be a bit flexible to support the common good of improved team performance. The ultimate goal is performing, at which point the team achieves better results with the new tool than without it.

Any time someone is asked to change the way he or she works, you can expect to hear the question, “What’s in it for me?” This is a normal human reaction; no one wants to go through an idle change exercise just because someone else had a cool idea. Sometimes, though, the change doesn’t offer an immediate, obvious benefit for everyone. The lesson here is:

Ask “What’s in it for us?” not “What’s in it for me?”

Anyone attempting to introduce new software development methods or tools should be able to articulate the overall expected benefits to the project team, the organization, and the customers. For example, developers might not see the need to use code analyzer tools. After all, it might take them longer to complete their work if they have to run the code through a tool and fix any bugs it finds. However, explaining that it costs several times more to fix defects when the system testers find them than to use the tools during coding is a compelling argument. Quality practices that take one individual more time than his or her current work methods usually have a high return on investment downstream. This benefit might not be obvious to those who feel someone is making their jobs harder.

Tools are sometimes hyped as silver bullets for increasing productivity. Some tools do provide a substantial productivity benefit, as with automated testing tools that can run regression tests far faster and more accurately than a human tester can. However, the benefits from most tools come from improving the quality of the delivered product. Productivity gains come over the long term, as tools help you prevent defects and find existing bugs early and efficiently. Improved initial quality reduces late-stage, defect-repair costs. Any action that reduces rework frees up developer time to create new products, rather than rehabilitating flawed ones. Keep lesson four in mind as you explore increased software development automation:

Tools affect quality directly, productivity indirectly.

I have heard development managers balk at acquiring development tools because they are expensive. “I can’t afford a copy of Tool X for every team member at $2,000 per license,” they protest. However, remember lesson five:

Weigh the price of the tool against the costs of not using it.

A good example here comes from requirements management tools. Licensing a powerful requirements management tool for a team of 10 software and quality engineers might cost $15,000. However, you don’t have to go very far wrong on the project’s requirements to waste $15,000 implementing unnecessary functionality or re-implementing poorly understood and ill-communicated requirements. You cannot predict exactly how many errors such tools can help you avoid. Nonetheless, your tool acquisition decisions should consider the potential costs of not using a tool, in addition to the size of the check you’ll have to write for it.

Lessons from CASE Tool Adoption

I worked with several small software development groups that used a number of CASE tools over several years (see Creating a Software Engineering Culture, Dorset House, 1996). CASE tools let you draw models of requirements and designs according to a variety of standard modeling notations and languages. Commonly used models include data flow, entity-relationship, state-transition, class, sequence, and interaction diagrams. When they first came onto the scene in the 1980s, vendors claimed fabulous benefits from CASE tools. But some of the groups I have seen use CASE tools were simply documenting completed systems. This is useful, but it doesn’t help you improve the software you build, only to understand software you’ve already built. Lesson six is:

Use CASE tools to design, not just to document.

Use the tool’s built-in methodology rules to validate diagrams and detect errors that are difficult for people to find. Your team should use the tools to iterate on design models before they start cutting code, because developers will never conceive the best design on their first attempt. Iterating on requirements and designs, rather than on code, is one way to improve quality and reduce product cycle times.

Our team had some energetic meetings in which we haggled over exactly what rules we should follow for various design models. Resolving these issues was critical to successfully implementing CASE in our group. We finally agreed on some conventions we could all live with. Lesson seven from our experience is:

Align the team on the spirit of the method and the tool, not on “The

Rules.”

Even if the developers do a great job on design, programs rarely match their designs exactly. You need to decide how to reconcile inconsistencies between design models and delivered software. If you want the CASE models to provide long-term benefits to the project, heed lesson eight:

Keep the information in the tool alive.

Ideally, you will update the models to match the reality of the system as it was built, and you’ll keep the models current as you modify the system. This approach demands considerable effort and discipline. If the system evolves while the models remain static, inconsistencies between code and designs can cause confusion, wasted time, and errors during maintenance. If you decide not to update the design models, either discard them once they have served their purpose, or clearly identify them as representing the initial design, not the current software implementation.

Some CASE tools permit round-trip engineering—generating code from a design and regenerating design models automatically from source code. This approach guarantees the correctness of the as-built design documentation. You can repeat the model generation any time code changes are made to create a new set of accurate models.

Fitting Tools into Your Culture

A cultural transformation takes place as a team moves from manual methods to the discipline of using structured processes and tools. Facilitate this change by:

?Articulating why you selected the tools

?Acquiring management commitment

?Selecting appropriate tools for your organization’s culture and objectives

?Training your team

?Setting realistic expectations of the new technology’s future benefits.

Some developers will balk at using new tools, maintaining that they can do better work with their current approach. For example, programmers who use interactive debuggers to perform unit testing (an inefficient process) may resist using test coverage tools. Some skeptics can be swayed when they see their teammates getting better results with the new tools, while others will never accept that there’s a better way. Be alert for recalcitrant team members who sabotage the improvement effort by “proving” that the tools are worthless. Look for allies among the developer ranks, early adopters who are willing to adjust their current approaches to try new tools. Merge the tools into the way your team works, rather than reshaping the culture to fit the tool vendor’s software development paradigm.

Educate your managers about the value of investing in tools, so they understand the tools aren’t just toys to amuse those technology-drunk software geeks. Obtain their commitment to spend the money you need to license the tools, train the team, and accept the short-term productivity hit from the learning curve. Ask management to set realistic and sensible expectations about how the team will incorporate tools into routine project activities.

The best chance for successful tool adoption comes if the tool capabilities will attack some source of pain your team is experiencing. For example, if developers spend countless hours on

tedious searches for memory leaks or pointer problems, they might be willing to try run-time analyzers such as Rational’s Purify or Compuware NuMega’s BoundsChecker. Begin by identifying the areas where improvements are needed, then go to https://www.wendangku.net/doc/9a19049803.html, and search for tools that might fill the bill.

Incorporating tools into a software organization requires more than dropping a user manual on every engineer’s desk. Support the new tools with training in the underlying approaches, such as testing concepts or project estimation principles. Don’t rely on tools to teach your developers the fundamental methods, any more than you can learn arithmetic by using a calculator. The individuals who I’ve seen use tools most effectively had a solid understanding of the methods and principles implemented in their tools.

As you pursue the effective use of new software development and management tools, respect the learning curve, which will likely make your first attempts to use new tools actually take longer than your previous methods did. Share your successes and failures with the team, so everyone can learn from the experiences of others. Work toward a long-term objective of providing each of your developers with a robust, integrated automation suite that will increase their productivity and the quality of the software they deliver.

完整版项目管理案例经典分析珍藏版

案例1背景： 某钢厂改造其烧结车间，由于工期紧，刚确定施工单位的第二天，施工单位还未来得及任命项目经理和组建项目经理部，业主就要求施工单位提供项目管理规划，施工单位在不情愿的情况下提供了一份针对该项目的施工组织设计，其内容深度满足管理规划要求，但业主不接受，一定还要求施工单位提供项目管理规划。 问题： ①项目经理未任命和项目经理部还未建立，就正式发表了施工组织设计，其程序是否正确？ ②业主一定要求施工单位提供项目管理规划，其要求是否一定正确？ ③项目管理规划是指导项目管理工作的纲领性文件。请简述施工项目管理规划的规划目标及内涵。 ④试说明施工项目管理规划的控制原则。 答：①程序不正确，公司还未任命项目经理，项目经理部还未建立，施工组织设计无人审核和批准，不能发表。 ②施工组织设计可以代替施工项目管理规划，但施工组织设计的内容深度应能满足施工项目管理规划的要求；冶金建设工程中，实际上一直使用施工组织设计代替项目管理规划；施工单位可以向业主说明提供的施工组织设计的内容深度已达到项目管理规划的深度要求，不必再编制项目管理规划。 ③施工项目管理规划的规划目标及内涵有： ａ.规划目标包括项目的管理目标、质量目标、工期目标、成本目标、安全目标、文明施工及环境保护目标、条件分析及其他内容等； ｂ.内涵包括施工部署、技术组织措施、施工进度计划、施工准备工作计划和资源供应计划和其他文件等。 ④项目管理规划的控制原则为：实现最优化控制；动态控制；主动控制；全过程控制；全要素控制；建立大控制系统的观念；要对规划的实施明确项目经理部各岗位职责、对执行进行检查分析和改进，进一步进行总结。 案例2背景： 华北某厂１２６０ｍ３级高炉扩容改造工程。根据招标文件要求，为了实现快速、高效、优质、低耗地完成扩容改建任务，该扩容改造，应采用高炉整体平移新技术。高炉分两段安装：第一段为移送；第二段为悬吊，高炉本体工程拟定在拼装平台上基本完成，尽量缩短停炉后施工工期，保证业主要求的工期。高炉本体平移作业采用滚动摩擦方式液压缸推送。要求“新、旧高炉中心线重合，标高与原设计标高相符，误差控制在５～８ｍ”。高炉本体移送重量约４５００ｔ。推移高度约为３６ｍ，推移距离约４２ｍ。高炉本体在液压缸推动下，分步向炉基平移。 问题： ①结合本案例谈谈项目目标的制定。

软件项目管理习题.doc

软件项目管理习题 第一章绪论 1.列举你在执行IT相关任务时曾碰到的问题。试把这些问题按频率和影响大小分别排序。对每一个问题，考虑是否可以通过某种方法降低发生的可能性。 2.软件工程的三个冃标是什么，以什么衡量是否达到冃标？ 3.软件工程活动包括哪些？那些活动需要有最终用户的参与？每个过程需要有怎样的文档产出？ 4.设计包括哪两个阶段，具体任务，干系人有什么区别？ 5.软件工程的原则有哪些？ 6.你能说出哪些软件工程模型，他们各自有什么有缺点,适用于怎样的系统？ 7.有人说“线性模型已经过时了，有着诸多缺点，不需要再了解它。”你怎么看待这种说法？线性模型和其他模型的关系是怎样的？ 8.在下列哪一个阶段项日发起人对项目的范围、质量、时间和成本有最大的影响力，为什么？ 9.项1=1的定义是什么，有什么特点，请给出三个是项日的例子，并给出三个不是项日的例子。 10.软件项目与一般的项目的区別在什么地方 11.判断以下活动中哪些是项目，哪些不是项目，并请说明理由。（1）升级某政府部门的办公自动化系统（2）打字员打印文件（3）报考软件学院软件工程硕士研究生（4）购买家用轿车（5）每天骑千上班 12.项忖生命周期包括哪些阶段？哪个阶段具冇最大的不确定性？各个阶段的活动主要冇哪 些？ 13.项目管理的六要素有哪些？相互之间是什么关系。TQC又指什么？ 14.怎样衡量项目是否成功？ 15.项目管理分哪几大知识体系，它们Z间什么关系？ 16.在选择职员时，应该考虑哪些因索？ 17.管理者是否应该和小组中更多的普通员T交朋友，并和他们打成一片？ 18.如果项1=1快结束时，忽然有一个很重要的，但非常耗时的变更，你作为项目经历应该怎么做 19.为什么说时间和人员不能交换？试说明其原因。 20.你能列出那些人际关系的矛盾？试阐述可能的解决方法。 第二章需求管理 1.软件需求的定义是什么，分别从用户角度，开发者角度，相关文档角度给以阐述 2.描述软件需求要做的五项主要事悄指什么。 3.软件需求过程与那些过程相关，是怎样的关系？

软件项目管理与案例分析 期末复习题

《软件项目管理与案例分析》复习题 一选择题 1. 核心计划过程有明确的依赖关系，在大多数项目中要以同样的顺序必须完成。下列哪一项符合核心计划过程的正确顺序：. A. 范围规划--范围定义--活动排序--活动工期估计 B. 范围定义--范围规划--活动定义--活动排序--活动工期估计 C. 范围规划--范围定义--活动排序--活动定义--活动工期估计 D. 活动工期估计--范围规划--范围定义--活动定义--活动排序 参考答案：A 2. PERT和CPM的主要区别在于PERT： A．在计算进度时使用分布的均值（预期值） B．使用最可能估算计算浮动时间 C．侧重计算浮动时间来确定那些活动的进度没有灵活性 D．在图中包括了回路或条件分支活动 参考答案：A 3.由于你的项目的范围发生变更，因此成本基线也发生变更。你的下一步将是： A.估计范围变更的程度 B.更新预算 C.记录获得的经验 D.执行得到批准的范围变更 参考答案：D

4. 以下哪项不属于合同管理的部分？ A．评估风险 B．确认已经送出建议书 C．确认已经进行了合同变更 D．回答潜在卖方的问题 参考答案：D 5. 你负责对项目进行成本估计工作。因为要求成本估计尽可能精确，所以你决定做出保守的估计。你的第一步工作是： A、确定一种计算机工具帮助进行估计成本 B、利用以前的项目成本估计 C、确定并估计项目的每项工作的成本 D、咨询各方面的专家，并在他们的建议的基础上进行成本估计 参考答案：C 6. 项目整体管理是指？ A.复杂系统的软件集成管理 B.将系统开发过程的管理和项目管理结合起来 C.将系统的主机平台.网络平台.应用软件开发和系统环境建设作为一个整体来进行项目管 理 D.包括在项目生命周期中协调所有其它项目管理知识领域所涉及的过程 参考答案：B 7. 涉及多领域工作的复杂项目最好由下列哪种组织形式管理： A.项目型 B.职能型

大项目管理要素

大项目管理要素 只要流程界定清晰， 项目经理就能保证项目的发展方向与最终目标相契合。 广义而言， 要掌控各种类型项目的发展，首先要关注十个关键的流程。 、生命周期与方法论 项目的生命周期与方法论，是项目的纪律，为项目开展划出了清晰的界限，以保 证项目进程。生命周期主要是协调相关项目，而方法论为项目进程提供了持续稳定的方式 方法。 生命周期通常由项目的阶段组成（包括：开始、规划、执行 / 控制、完成），或 由工作的重复周期构成。项目生命周期的细节一般都会随具体业务、项目、客户 改变。因此即使在同一个项目中， 周期也会有多种可能的变化。 对工作细致度、 文件管理、 项目交付、项目沟通的要求体现在生命周期标准和考核的方方面 面。大项目的阶段一般 更多更长，而小项目的阶段少，考核点也少。 与生命周期类似，项目方法也因项目而易，细节关注程度高。产品开发项目的方 法经常涉及使用何种工具或系统， 以及如何使用。 信息技术项目的方法包括版本控制标准、 技术文档管理、系统开发的各个方面。 项目方法往往不是由项目团队自行确定，而由公司为所有项目设定。采用与否， 其实项目团队没有太多选择。公司管理层设定的方法本身代表权威，也是你作为 导获得项目控制权的一个途径。考虑项目方法某方面的作用时，始终要把握其对项目人员 管理的效率，即在可能出现问题的地方争取正面效应。 、项目定义 清晰的项目描述决定了你的项目控制能力，因为接下来所有工作都在描述范畴之 内。不管你如何并为何要进行描述，你要对你的项目进行书面定义，让项目各方和项目组 随时参考。 项目定义的形式和名称各式各样，包括：项目章程、提案、项目数据表、工作报 告书、项目细则。这些名称的共同点在于，项目主管方和其他相关各方面从上而下地传达 了他们对项目的期待。清晰的项目定义还包括以下方面： 要求而 项目领

项目要素

对于一个项目的评估、分析，需要参考很多要素，从资本投入方面来讲，可以用六个要素来衡量。对于投资者来说，在投资前都应该搞清楚这六个要素在投资中的作用，否者最好不要去投入。 一般来说，在投资前，投资者在资本投入方面，可以通过以下六个要素来衡量。 1、项目初期成本 在项目正式运作之前，需要投入多少钱，这个钱可能成为将来正式运作之后很大的包袱。一些企业由于建厂期间走的弯路太多，建起一个远远超出预算的厂，会推迟项目评估时预计的盈亏平衡时间。 2、每一阶段发生的费用 一般按年算，第一年要花多少，第二年要花多少………当然，最好是清楚每个月的大致情况。而且最好能分出哪些是固定不变的，比如房租;哪些是随着其他因素，比如产量的变化而变化;还有哪些是自己能控制的，比如自己的工资可以少拿一些;哪些是无法控制的，比如国家规定的税费。 3、投资的生命期 多少年之后，这个项目就差不多等于玩完了，再运作下去也不会有赚钱的可能。这也可以结合产品的生命周期，但不少项目不到产品的生命周期结束就结束了。 4、现金产生的时间和数量 什么时候开始能有白花花的银子流进来，也就是要预计什么时候开始有销售了，或者有广告收入，或者有人给顾问费了。 5、对原企业的影响 这个项目有没有可能为其他项目增加利润，比如购入其他项目的产品做原料，或者制造麻烦，比如自己跟自己竞争。 6、需要的营运资金

1、项目实施范围 客户买了哪些模块，实施这些模块将给客户带来什么价值，这是项目的点睛之处。 我常跟客户说ERP是一套管理工具，是一个数据统计和分析的工具。通过它给企业带来价值的创新，而这些价值体现在职能分工、还是业务流程、我们一定要界定清楚。只有界定了、清楚了我们的实施目标，才能为后续项目顺利验收作好铺垫。 所以项目的实施范围条款，在我们的《实施工作任务书》上，一定要做的非常细致，而且一定要项目对方负责人签字确认。 2、项目计划管理 项目计划管理，是保障项目按质按量交付的一个过程，这是项目成功的核心关键。 确定项目范围之后，接下来就是计划管理；想必是顾问的都知道，对于企业而言，时间上的配合实在是不敢恭维。不管是项目到后来是好是坏，甚至有些企业从项目一开始就有并不打算真正把它做好的念头。但不管怎样，对于顾问而言，项目或许没做好，客户也闭着眼睛签字验收了，但凭心而论，就是过不了心里不痛快那道坑。所以，在这种意识里，我们在项目过程中，除了是保障项目的责任不让我们去承担，更重要的是通过有效的计划管理，带动和促进客户的工作积极性。 作为顾问，我们如果没有计划，就没有压力和工作轻重区分；虽然计划跟不上变化，但计划一定要强化执行，尤其是对于我们顾问方，一定要坚持与客户方确认，并每周将《项目周报告及计划》通报相关领导！ 3、项目沟通问题 项目沟通问题，不是跟客户关系做得好不好，而是项目过程有没有做好文档控制的问题。 沟通问题或许是困扰每个顾问的难点，尤其是与对方高层的沟通。在这里，我只想说一句，所有项目相关的事宜均需以书面表达，关键文档还是要作现场确认，切勿以为你跟对方关系不错，就可以不把它当一回事；当项目真正出问题了，那个时候你跟对方的关系是极其脆弱的！ 所以我的观点是：作为顾问，日常《实施日志》的繁琐确认，总比撕开脆弱的关系要强千倍万倍。 4、流程重组意志 ERP项目管理，换句话其实是流程重组过程的管理，该坚持的还是要坚持！

项目管理能力提升四要素

项目管理能力提升四要素 认识项目管理 美国项目管理协会主席保罗说：“在当今社会，一切都是项目，一切也将成为项目。”项目，是在一段时间内为完成某一独特的产品或提供独特的服务所进行的一次性努力的过程。只要有目标和过程，就可以成为一个项目。譬如：设计开发某一产品功能、房屋装修改造、结婚的婚礼筹备等都能称为项目。 项目管理，就是在项目活动中运用知识、技能、工具和技术，以便达到项目要求，其目的是满足和超越项目干系人对项目的需求和期望。项目管理从本质上来说，就是面向目标的，所有的方法、行动都是为了达成目标而服务的。 互联网公司的项目实践 早期或初创的互联网公司，产品经理和技术开发几乎承担着多种角色的工作。产品经理除了产品方案设计以外，还做交互设计、产品测试以及项目执行的整体协调推进工作。技术开发人员除了做程序编码实现以外，还做系统测试以及测试完成后的上线部署。 实际上，从标准规范的人员角色分工来讲，交互设计是交互设计师的工作范畴；系统测试属于测试工程师的工作范畴；上线部署属于运维工程师的工作范畴；项目执行的整体协调推进，也属于项目管理的工作范畴。当那些早期或初创的互联网公司的业务规模越来越大、项目越来越多时，一个人兼任多种角色，就会感到力不从心，必将影响项目进度和节奏。 以中国互联网行业里知名的A公司为例，A公司的W事业部在最早期的组织架构中，会有独立的产品、UE、UI、页面制作、前端、后端、测试等部门，当时没有专职的项目管理人员。项目管理工作多数是由产品和技术部门的负责人来承担。这一阶段尚未形成系统的项目管理流程，因此相关项目工作没有统一的依据，管理较为粗放。项目负责人的界定也不清晰，有时候项目出了问题也难免发生互相推诿扯皮的情况。后来项目执行中问题不断暴露，又得不到快速有效的解决。对项目管理的需求，就变得日益强烈，业务线的领导意识到需要从全局高度统一对项目做管理。主要体现在：需要确保项目资源合理利用、明确项目成员的角色分工、制订合理的项目计划并推进执行。看似非常简单的要求，却是A公司W事业部在项目管理方面的起航。 W事业部为了增强其项目管理能力，成立了项目管理部（PMO），直接向业务线的负责人（高级总监级别）汇报工作。当时在产品、设计和技术类部门，形成了如下形式的人员角色划分（运营和市场类部门，不做介绍），如图1所示。

项目管理软件project操作手册

项目管理软件p r o j e c t 操作手册 SANY标准化小组 #QS8QHH-HHGX8Q8-GNHHJ8-HHMHGN#

项目管理软件PROJECT 2010操作实例 Project工具一般用来管理一个项目，制定项目的执行计划。项目的三要素到底是时间,成本和范围。如何使用Project，必须明确如下几项： A，做什么事 B，这些事的时间有什么要求 C，要做的事之间有什么关系 D，做这些事的人员有谁 E，人员有特别的时间要求 下面举一个具体例子，了解一下项目管理软件的操作过程。 项目名称：电石炉主体安装工程 项目的开始日期：2016年2月1日 项目的结束日期：2016年6月11日 日程排定方法：从项目的开始之日起 项目日历：标准日历 工作时间：每周工作7天，每天8小时 项目目标：确保设备按期投产。 可衡量结果：达到业主产量要求。 一、任务清单列表：

大纲级别任务名称工期（工作日） 1（摘要）电石炉主体安装进度计划90 安装下料槽4 安装底部装置3 安装铜母线9 安装黄铜管3 安装电极壳3 安装电极柱2 安装下料仓2 安装下料管4 安装环形加料机10 安装炉顶加料皮带10 。。。。。。。。。。。 电气安装57 安装低压配电室电气柜4 安装中控室电气柜、控制台5 安装3－4层电气柜3 安装电缆槽30 。。。。。。。。。。 液压安装29 调试27 2配合投料 3投产保驾 4设备验收 5结束 二、资源可使用情况： 资源名称最大单位标准工资率每次使用成本成本累算方式 钳工4￥工时按比例 电工4￥工时按比例 管工6￥工时按比例 电焊工12￥工时按比例 起重工2￥工作日按比例 力工42￥工作日按比例 电动葫芦 卷扬机3￥ 自卸车1￥ 三、任务之间的相关性： 放线→设备机、电、液安装→调试→投产保驾→竣工验收→结束 四、具体操作步骤

IT 项目管理经典案例

1、拯救项目团队 徐家龙最近被公司任命为项目经理，负责一个重要但不紧急的项目实施。公司项目管理部为其配备了七位项目成员，这些项目成员来自不同部门，大家都不太熟悉。徐家龙召集大家开启动会议时，说了很多谦虚的话，也请大家一起为做好项目出主意。一起来承担责任，会议开得比较沉闷。 项目开始以后，项目成员一有问题就去找项目经理，请徐经理给出意见，徐经理为了树立自己的权威、表现自己的能力，总是身体力行；其实，有些问题项目成员之间就可以互相帮助，但是他们怕自己的弱点被别人发现，作为以后攻击的借口，所以他们一有问题就找项目经理，其实徐经理的做法也不全对，成员发现了也不吭声，因为他们认为我是按你说得作的，有问题你经理负责。 团队成员之间一团和气，“找徐经理去！我们听你的；成为了该项目团队的口头禅，但是随着时间的推移，这个貌似祥和团结的团队，在进度上很快就出了问题。该项目由重要但不紧急的项目变成了重要还紧急的项目！ 项目管理部意识到问题的严重性，派高级项目经理张一峰指导该项目的实施。 1.1问题 问题出在哪儿？ 张一峰怎么做？

2、C公司的变更管理 C 公司是一家主要为交通部门从事系统集成业务的公司。 2007 年 3 月底该公司承接了 L 市数字指挥系统的建设工作，公司任命王莽为项目经理。合同金额 300 万交付日期为 7 月 1 日。 王莽组建完团队后，召开了内部的项目启动会议，宣布 4 月 1 日正式开工；大家干劲很高；王莽带领项目团队绘制了项目的生命期模板，分解得到了项目的 WBS ，在此基础上得到了项目计划，然后团队严格按照项目计划执行。a 很遗憾的是：很快项目团队就发现所需的采购设备的项目资金，被公司挪作它用不能及时供给资金。另外这时交付给客户X 模块，虽然用户签收了，但是客户认为项目团队没有领会好他们最急需的需求，希望他们在 4 月底前尽快完成 Y 模块的工作。而项目团队的计划是在 5 月底完成 Y 模块，王莽认为这是客户的变更，需要填写客户变更申请书，客户不承认这是变更，于是引起争执也未填写变更申请书。b 项目团队努力按照计划继续执行，但发现计划越来越难执行；交通部门的意见越来越多，王莽底下的成员看见项目经理已经与客户闹矛盾了，为了缓和关系底下的几个成员；开始不情愿地接受客户的意见，认为能随手改的就改了。公司认为这样作是对的，有助于提高客户满意度，这样到 5 月初时项目计划已经形同虚设。c 随着项目的进行，王莽和项目成员变成了救火队，用交通部们的话说是很好指哪打哪；但是王莽和项目成员发现：自己已经疲于奔命，客户的需求追加了不少，随意的变动也很多。甚至交通部门有的用户上旬说这么改，中旬说那么改，到了下旬说还是上旬作的对，改回去吧！王莽认为这样做下去，自己累死不算，利润率肯定为负数，结局是不讨好的。于是王莽和几个骨干在 5 月底，宁愿不要当月薪水，先后辞职离开了公司。 2.1问题 怎么回事？王莽、管理者各有哪些错误？分步骤的应对措施是什么？ A、启动阶段 B、矛盾初起(争执未起) C、计划形同虚设。

项目管理的四要素

项目管理的四要素 项目管理有四个要素:工作范围、时间、质量、成本。 对一个项目来说当然最理想的情况就是“多、快、好、省”。“多”指工作范围大，“快”指时间短、“好”指质量高，“省”指成本低。但是，这4者之间是相互关联的，提高一个指标的同时会降低另一个指标，所以实际上这种理想的情况很难达到。项目管理的目的 在谈项目管理要素之前，首先明确一下什么是项目管理。按PMI的定义：“Project management is the applications of knowledge,skills,tools, techniques to project activities in order to meet or exceed stakeholder needs and expectations from the project. ”。按字面意思理解，项目管理就是“在项目活动中运用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目的要求”，这指出了项目管理涉及的范 畴和要达到的目标。 对于以“项目”为基本运作单位的IT服务公司来说，主要目标是让每个项目都能使

“客户满意、公司获利”。虽然单方面提高项目管理水平还不能达到此目标，但项目管理无疑起着举足轻重的作用。因此，项目管理已经是公认的IT服务公司核心竞争力之一。 项目的成功要素 成功的项目不仅取决于项目本身从开始到结束的执行过程，还取决于开始前和结束后的努力。成功的项目应该取决于三个阶段的努力： 1)项目开始前必须 “了解什么是客户的成功”，只有客户成功了项目才能成功； 2) 项目执行中能够“担负客户成功的责任”，按要求完成承诺的工作； 3) 项目结束后能“帮助客户实现价值”，只有客户说项目成功了才是真正的成功。

工程项目管理经典案例分析

背景： 某钢厂改造其烧结车间，由于工期紧，刚确定施工单位的第二天，施工单位还未来得及任命项目经理和组建项目经理部，业主就要求施工单位提供项目管理规划，施工单位在不情愿的情况下提供了一份针对该项目的施工组织设计，其内容深度满足管理规划要求，但业主不接受，一定还要求施工单位提供项目管理规划。 问题： ①项目经理未任命和项目经理部还未建立，就正式发表了施工组织设计，其程序是否正确？ ②业主一定要求施工单位提供项目管理规划，其要求是否一定正确？ ③项目管理规划是指导项目管理工作的纲领性文件。请简述施工项目管理规划的规划目标及内涵。 ④试说明施工项目管理规划的控制原则。 答：①程序不正确，公司还未任命项目经理，项目经理部还未建立，施工组织设计无人审核和批准，不能发表。 ②施工组织设计可以代替施工项目管理规划，但施工组织设计的内容深度应能满足施工项目管理规划的要求；冶金建设工程中，实际上一直使用施工组织设计代替项目管理规划；施工单位可以向业主说明提供的施工组织设计的内容深度已达到项目管理规划的深度要求，不必再编制项目管理规划。 ③施工项目管理规划的规划目标及内涵有： ａ.规划目标包括项目的管理目标、质量目标、工期目标、成本目标、安全目标、文明施工及环境保护目标、条件分析及其他内容等； ｂ.内涵包括施工部署、技术组织措施、施工进度计划、施工准备工作计划和资源供应计划和其他文件等。 ④项目管理规划的控制原则为：实现最优化控制；动态控制；主动控制；全过程控制；全要素控制；建立大控制系统的观念；要对规划的实施明确项目经理部各岗位职责、对执行进行检查分析和改进，进一步进行总结。 2、背景： 华北某厂１２６０ｍ３级高炉扩容改造工程。根据招标文件要求，为了实现快速、高效、优质、低耗地完成扩容改建任务，该扩容改造，应采用高炉整体平移新技术。高炉分两段安装：第一段为移送；第二段为悬吊，高炉本体工程拟定在拼装平台上基本完成，尽量缩短停炉后施工工期，保证业主要求的工期。高炉本体平移作业采用滚动摩擦方式液压缸推送。要求“新、旧高炉中心线重合，标高与原设计标高相符，误差控制在５～８ｍ”。高炉本体移送重量约４５００ｔ。推移高度约为３６ｍ，推移距离约４２ｍ。高炉本体在液压缸推动下，分步向炉基平移。

项目管理核心三要素

项目管理三要素：时间、质量、成本工期紧，活儿只能凑合了；超支，赶紧砍内容，别弄那么多；资源有限，人手奇缺，往后拖吧。 这就是我们身边项目运作时常发生的状况。 所有的项目经理都会做预算，都会设置检查点，都知道又要无休止的协调。但真正执行起来，千变万化的现实让他们经常无所适从。 时间、质量、成本难平衡！ 在纸上画一个等边三角形。在各个边上标上时间、质量、成本。我们会看到，任何一方的移动必定带动其他的变形。这个三角形中间又是什么呢？是范围管理，也就是项目范围。这个三角也就是我们常说的“项目管理三角形”。时间、成本、质量就是项目管理的三要素。有一种比喻更能说明三要素之间的关系。 小高为了取悦新认识的女朋友，精心设计了欧洲8日游，旅游花光了他多年的积蓄，旅游结束后，他再也没有财力去继续下一步的发展了。用项目管理的话说，这就是不计成本的恶果。 过了一段时间后，他又攒了一些钱，这次他不和新女朋友旅游了，他请这个姑娘看了场电影—《第一滴血》。看完后，女朋友觉得小高有暴力倾向，又分手了。这一次，小高败在不讲质量。 第三次，小高知道女孩子一般喜欢看歌舞剧，他准备请第三个女朋友去看半年后才上演的《天鹅湖》，战线一直拉着，女朋友爱上了别人——时间拖得太久了。 这个比喻形象地说明了项目管理中的难题：如何平衡三要素之间的关系？ 一般来说，管理者都希望项目完成的时间要快，完成的成本要低，完成后的质量要好。可是这三个要素是彼此互斥的。能够完美做到以上三个要素的项目，少之又少。上世纪60年代初，肯尼迪总统下令要十年内把人送上月球，并安全带回来。这个庞大的计划，要快，必须赶在前苏联之前完成；要好，绝不能出现任何差错；并且在预算上有限制。 结果，在各方为这个项目大开绿灯之后，美国果真抢先把人类送上月球，并平安带了回来。当然，我们平常的项目不可能集所有人力、物力、财力等所有资源，并且得到至高无上的尚方宝剑。 因此，在一般的项目上，这三个要素，彼此之间是鱼与熊掌的关系。要兼顾的难度，会按照几何级数上升。这样一个三角难题，我们怎么去解呢？可以试着从两方面着手。 第一，先弄清楚什么是“好”，什么是“快”，什么是“便宜”。 什么是好项目？一般来说，项目的结果使企业的收入增加、支出减少、服务加强，就是好项目。 那么，什么是“快”？在项目管理上，时间是绝对的。项目经理最容易犯的错误，就是在完工日期的预测上，为了讨好上司而尽量乐观。同时，他们总用历史数据或别人的经验影响自己的预测，也使得项目工期的变化比较大。 要达到预期完工的要求，项目经理要把一个规模大、时间长的项目，分成不同的阶段完成。在每个阶段，又要根据每阶段不同的重点分别来做完工预测。工程分得越细，预测的准确性就越高。这道理很普通，但需要很周详的计划和分析。

项目管理复习资料

1、项目是一个组织为实现自己既定的目标，在一定的时间、人员和资源约束条件下，所开 展的一种具有一定独特性的一次性工作。目的性独特性一次性制约性其他特性 2、项目生命期阶段的划分：启动阶段，计划阶段，执行阶段：实施和控制阶段，收尾阶段 3、项目中的重大事件，通常是指一个主要可交付成果的完成。它是项目进程中的一些重要 标记，是在规划阶段应该重点考虑的关键点。里程碑既不占用时间也不消耗资源。项目干系人:也可称为利益关系人，或利益相关者，是指积极参与项目、其利益受到该项目影响的个人或组织。 4、理解项目管理的含义、特征、基本要素及工作过程 （1）对象：项目管理的对象是项目，一般企业管理的对象是作业； （2）目标：项目管理的目标是确保项目能够成功。企业管理的目标是使每个作业都能高效率地展开，以求企业达到一定的经济效益； （3）内容：项目管理的内容包括项目的范围管理、项目的组织管理、项目的质量管理、项目的费用管理和项目的时间管理等内容，而且每一项管理都含有风险。一般企业管理其内容也许更丰富，涉及面更广，但它的风险性相对比较小； (4）过程：项目管理非常强调其过程性。一般企业管理强调的是创造一个稳定的环境，使各项作业能以最高的效率进行，侧重于作业点的效率 （5）责任：项目管理强调对整个项目负责，一般企业管理中强调分工，强调各部门按作业规范做好自己的本职工作，所以责任在其规定的作业范围内 （6）手段：项目管理中所能采取的手段，一般不同于普通的企业管理方法。 六要素：质量、进度、成本、范围、组织和客户满意度 5、各种项目组织结构的优缺点（特点）职能型组织机构具有明确的等级划分，每一个雇员都有一个明确的上级。员工高度地依各人专长进行组合。职能组织的行为机制偏重行政命令，容易产生官僚主义行为，不易发挥人的主观能动性，难以对其环境问题作出及时的反应。项目型组织结构的特点：优点：注重客户，目标明确，便于统一指挥。有利于项目控制。有利于全面型人才的成长。缺点：机构重复及资源闲置，成本较高。项目间缺乏知识信息交流，不利于企业专业技术水平的提高。不稳定性。矩阵优点：有利于资源共享。成员无后顾之忧。注重客户。缺点：责任不明确。双层汇报关系，需要平衡权利。多个项目资源难以平衡 6、了解项目生命期阶段与项目管理过程的关系：项目生命期一般包括四个阶段没有重复，是一次性结束的，是从项目的实现过程的角度考虑的。项目管理的五个过程（启动、计划、执行、控制、收尾）并不是独立的一次性过程，它贯穿于项目生命期的每一个阶段。 7、认识项目管理知识体系PMBOK：项目整体管理（PIM）项目范围管理（PSM）项目人力资源管理（ PHRM ）项目进度管理（PTM ）项目成本管理（PCM ）项目质量管理（ PQM ）项目采购管理（ PPM ）项目沟通与冲突管理（ PCM ）项目风险管理（ PRM ） 1、项目整合管理，是应用系统论思想、理念和技术方法保证项目的进度、费用、资源、质量等要素之间相互协调所需要的过程；项目成组管理：主要是管理具有相似性质的项目，把这些项目放在一起，形成一个项目组，进行统一管理，以产生规模效益，提高项目管理效率。项目在工作方法、所需人员等方面具有相似性，注重提高项目的效率。项目组合管理：则是从企业整体利益出发，动态地选择不具类似性质的项目，对企业所拥有的或可以获得的生产要素和资源进行选择、匹配、优化组合，从而有效地、优化地分配企业资源，分散企业风险，以达到企业效益最大化，提高企业核心竞争能力的目的。 3、项目组合与企业战略之间的关系：首先要保证所组合的项目有利于实现企业经营战略 其次在项目组合中合理分配资源可以使企业的一些战略目标的组合价值最大化。 项目组合可以培养和提升企业的核心竞争力，应用组织学习手段，将不同项目的技术知识整合起来，形成关键知识或产生新的知识，可以培养、拓展和强化企业的核心竞争力。 4、了解三种项目管理的成熟度模型CMM ，OPM3， K-PMMM 1、项目基准计划：项目的基准计划（baseline）是项目在最初启动时订出的计划，也即初始拟定的计划。项目基线：项目基线是特指项目的规范、应用标准、进度指标、成本指标，以及人员和其他资源使用指标等。 2、项目计划的分类？按照项目计划制定的过程划分：概念性计划（确定项目的战略导向和重点）详细计划（确定详细的工作分解图）滚动计划（在已有计划基础上制定的计划） 3、项目计划的编制程序（1）定义项目的交付物（2）确定任务，进行工作分解（3）建立逻辑关系图（4）为任务分配时间（5）确定责任部门和人的可支配时间（6）为任务分配资源（7）确定支持性任务（8）计划汇总审批与下达

常用项目管理工具

常用项目管理工具 ---来源：不详。 随着IT行业的进展，IT行业内的项目拓展和投资比比皆是。为了提高项目治理水平，赢得市场竞争，专门是在加入WTO后在国内、国际市场上拥有与国际接轨的项目治理人才，越来越多的业界人士正通过不同的方式参加项目治理培训并力争获得世界上最权威的职业项目经理（PMP）资格认证。同时，大部分的IT行业项目治理人士正尝试使用项目治理软件对自己的项目进行辅助治理，为了方便大伙儿的使用，现对项目治理作一简要介绍。 目前市场上项目治理软件种类较多，具有代表性的为微软项目治理软件2000，但大多以美国项目治理协会（PMI）的项目治理理论为基础，在使用过程中要注意以下内容： 一、项目治理软件特点 1．预算及成本操纵 大部分项目治理软件系统都能够用来获得项目中各项活动、资源的有关情形。人员的工资能够按小时、加班或一次性来运算，也能够具体明确到期支付日；关于原材料，能够确定一次性或连续成本；对各种材料，能够设立相应的会计和预算代码。另外，还能够利用用户自定义公式来运行成本函数。大部分软件程序都应用这一信息来关心运算项目成本，在项目过程中跟踪费用。项目过程中，随时能够就单个资源、团队资源或整个项目的实际成本与预算成本进行对比分析，在打算和汇报工作中都要用到这一信息。大多数软件程序能够随时显示并打印出每项任务、每种资源（人员、机器等）或整个项目的费用情形。 2．日程表 日程表程序要紧用来对项目中各个单项资源或一组资源确定工作时刻。能够用这些日程表运算出项目的进度打算。大部分系统软件都对差不多工作时刻设置一个默认值，比如星期一到星期五，早上8点到下午5点，中间有一小时的午餐时刻。关于各个单项资源或一组资源，能够修改此日程表。例如：修改上、下班时刻，按非工作时刻输入公司假期，输入各种换班（白天、夜晚），包括节假日以及数量单位（小时、天、周）。汇报工作进程时要用到这些日程表，它通常能够依照每个单项资源按天、周或月打印出来，或者将整个项目的日程打印成一份全面的，可能有墙壁大的项目日程表。 3．电子邮件 一些项目治理软件程序的共同特点是能够通过电子邮件发送项目信息。这一功能使得用户不必通过打印机或屏幕显示，直截了当从电子邮件中获得信息。通过电子邮件，项目团队成员能够了解重大变化，比如最新的项目打算或进度打算，能够把握当前的项目工作情形，也能够发出各种业务表格。 4．图形 关于有大量活动事项的项目工程，人工制出一份甘特图或网络图，或人工进行修改制图是一件极其乏味而又容易出错的工作。当前项目治理软件的一个最突出的特点是能在最新数据资料的基础上简便、迅速地制作各种图表，包括甘特图及网络图。有了基准打算后，任何修改就能够轻易地输入到系统中，图表自动会反映出这些改变。项目治理软件能够将甘特图中的任务连接起来，显示出工作流程。专门是用户能够仅用一个命令就在甘特图和网络图之间来回转换显示。另外，图形和表格通常有以下功能供用户使用：. 进行任务和关系的交互式操作处理。例如，通过图表连接任务，改变优先关系或通过扩展活动连续显示功能来改变活动连续时刻。 . 定制格式，例如图形大小、标题、颜色、字型以及文件布局。 . 显示任务或成本的基准对比表。 . 突出关键路径，显示出任何活动的延缓。 . 放大或缩小显示图像。

80-软件项目管理习题

软件项目管理习题 第一章绪论（13题） ★2．软件工程的三个目标是什么，以什么衡量是否达到目标？ 可用性；正确性；经济性。以用户需求及项目计划来衡量是否达到目标 ★3．软件工程活动包括哪些？那些活动需要有最终用户的参与？每个过程需要有怎样的文档产出？ 问题定义：关于问题性质、工程目标和规模的书面报告； 可行性研究：可行性分析报告； 需求分析：需求分析说明书； 设计：概要设计说明书，详细设计说明书 实现：无 确认：测试计划，测试报告 支持：操作手册，用户手册。 其中需要有最终用户参与的有：问题定义，可行性研究，需求分析，确认，支持。 ★5．软件工程的原则有哪些？ （1）选取适宜的开发模型。（2）采用合适的设计方法。（3）提供高质量的工程支持。（4）重视开发过程的管理。 ★6．你能说出哪些软件工程模型，他们各自有什么有缺点,适用于怎样的系统？ 一、瀑布模型：（1）实际的项目很少按照该模型给出的顺序进行；（2）用户常常难以清楚地给出所有需求，而线性顺序模型却要求如此；（3）用户必须要有耐心；（4）开发者常常被不必要地耽搁；（5）项目相关人员之间的敌对关系。适用于开发团队熟悉的系统。二、原型化模型：（1）原型作为“第一个系统”，是我们应该抛弃的；（2）趋于用户的压力，用户会要求将原型改成最终的工作产品；（3）趋于开发进度压力及设计结构的压力，无法更改应用模块。适用于：用户定义了软件的一组一般性目标，但不能标识出详细的输入、处理及输出需求以及开发者不能确定有效的算法或技术适应性的系统。 快速应用(RAD) 过程模型: 1、只能用于信息系统。 2、对于较大的项目需要足够的人力资源去建造足够的R AD组。 3、开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当都会导致RAD项目失败。 4、这种模型对模块化要求比较高，如果有哪一功能不能被模块化，那么建造R AD所需要的构件就会有问题。 5、技术风险很高的情况下不适合这种模型。 螺旋模型: 、需要相当的风险分析评估的专门技术，且成功依赖于这种技术。 2、很明显一个大的没有被发现的风险问题，将会导致问题的发生，可能导致演化的方法失去控制。 3、这种模型相对比较新，应用不广泛，其功效需要进一步的验证。 优点： 1、对于大型系统及软件的开发，这种模型是一个很好的方法。开发者和客户能够较好地对待和理解每一个演化级别上的风险。 增量过程模型：缺点：

项目管理案例经典分析(珍藏版)

某钢厂改造其烧结车间，由于工期紧，刚确定施工单位的第二天，施工单位还未来得及任命项目经理和组建项目经理部，业主就要求施工单位提供项目管理规划，施工单位在不情愿的情况下提供了一份针对该项目的施工组织设计，其内容深度满足管理规划要求，但业主不接受，一定还要求施工单位提供项目管理规划。 问题： ①项目经理未任命和项目经理部还未建立，就正式发表了施工组织设计，其程序是否正确？ ②业主一定要求施工单位提供项目管理规划，其要求是否一定正确？ ③项目管理规划是指导项目管理工作的纲领性文件。请简述施工项目管理规划的规划目标及内涵。 ④试说明施工项目管理规划的控制原则。 答：①程序不正确，公司还未任命项目经理，项目经理部还未建立，施工组织设计无人审核和批准，不能发表。 ②施工组织设计可以代替施工项目管理规划，但施工组织设计的内容深度应能满足施工项目管理规划的要求；冶金建设工程中，实际上一直使用施工组织设计代替项目管理规划；施工单位可以向业主说明提供的施工组织设计的内容深度已达到项目管理规划的深度要求，不必再编制项目管理规划。 ③施工项目管理规划的规划目标及内涵有： ａ.规划目标包括项目的管理目标、质量目标、工期目标、成本目标、安全目标、文明施工及环境保护目标、条件分析及其他内容等； ｂ.内涵包括施工部署、技术组织措施、施工进度计划、施工准备工作计划和资源供应计划和其他文件等。 ④项目管理规划的控制原则为：实现最优化控制；动态控制；主动控制；全过程控制；全要素控制；建立大控制系统的观念；要对规划的实施明确项目经理部各岗位职责、对执行进行检查分析和改进，进一步进行总结。

华北某厂１２６０ｍ３级高炉扩容改造工程。根据招标文件要求，为了实现快速、高效、优质、低耗地完成扩容改建任务，该扩容改造，应采用高炉整体平移新技术。高炉分两段安装：第一段为移送；第二段为悬吊，高炉本体工程拟定在拼装平台上基本完成，尽量缩短停炉后施工工期，保证业主要求的工期。高炉本体平移作业采用滚动摩擦方式液压缸推送。要求“新、旧高炉中心线重合，标高与原设计标高相符，误差控制在５～８ｍ”。高炉本体移送重量约４５００ｔ。推移高度约为３６ｍ，推移距离约４２ｍ。高炉本体在液压缸推动下，分步向炉基平移。 问题： ①结合本案例谈谈项目目标的制定。 ②结合本案例谈谈项目管理的总体安排。 答：①项目的目标包括质量、安全、进度、成本等目标，施工组织设计、项目质量计划由项目经理部编制，并按规定程序报批和实施。如质量目标：工程质量一次验收合格率１００％，单位工程优良率８５％以上，质量达到冶金建设工程优良标准。无重大质量事故，质量管理体系持续有效运行。竭尽全力做好工程服务和投产顺产保驾工作，确保用户满意。 安全目标：工亡事故为零；重伤事故为零；重大机械设备事故为零；重大交通事故为零。 现场目标：在争创优质工程的同时，强化现场文明施工的管理，树立公司良好的形象，建设文明、规范的施工现场。 ②项目管理实施项目经理责任制，项目经理对项目实施全方位的管理，负责项目施工全过程的质量、工期、安全、文明施工、确保履行合同，负责组织编制施工组织设计、项目质量计划、相应的项目管理文件。项目经理是工程项目质量、安全的第一责任人。 结合本案例项目管理的总体安排：强化项目管理，全面响应业主技术要求，严格科学管理、精心组织施工，优质、安全、高速建设高炉扩容改造工程。针对本工程的特点，结合类似工程的经验，我们对本工程的总体思路是：项目管理，科学组织；突出重点，齐头并进；有序安排，提高效率；阶段实施，步步为营；

测试管理工具禅道使用

禅道使用流程 概述 禅道项目管理：基于LGPL协议，开源免费的项目管理软件，集产品管理，项目管理，测试管理一体，以及事物管理，组织管理的功能。（PHP+MYSQL开发，基于PHP开发框架）我们目前主要使用禅道来进行整个测试过程管理，其中分为以下角色 1 Admin: 组织试图: 添加用户，编辑用户信息；设置用户权限； 产品视图: 新增产品（即我们实施的项目或者系统），编辑信息；上传计划书和需求书，生成需求和计划(可以作为文档库)；将产品进行模块分类 项目视图中，配置需求模块任务给对应开发人员，更新模块任务完成进度，管理项目团队人员权限。 2．QA测试人员： 在QA试图在该产品下，编写测试用例，进行用例管理；测试阶段：创建测试任务，分配用例，进行脚本执行，更新状态，提交缺陷；通过缺陷管理对BUG进行管控，分配给涉及的开发，可以查看BUG状态跟踪；回归测试后，更新BUG状态，,完成后更改状态查看BUG记录图表。 3．经理：可以浏览QA视图的用例和BUG，产品视图中的需求和计划； 准备阶段：浏览QA视图，测试用例，评审用例，更改测试用例状态，备注说明有异

议用例。项目视图中，分配需求模块对应开发人员，以及涉及项目人员管理。 测试阶段：查看用例执行，及涉及产生的BUG，分配BUG。完成后，可以查看BUG记录图表。 4 开发：权限基本类似经理角色，对应查看模块下的缺陷，修复后更改BUG状态，测试结束后，可以查看BUG图表记录。 下面就对各个角色以及相应职责和操作流进行介绍（中有些基本信息的字段可以根据实际情况修改）： 一管理员角色 1组织管理 在组织视图下，我们主要使用用户列表和权限分组，来配置账号。如果需要更全面记录用户信息，可以使用部门维护和公司管理。 1.1公司管理 编辑公司信息。

项目管理软件论文

项目管理软件论文 项目管理软件在实战中的应用 学号： 考核号： 姓名： 教师： 作者：杨磊 吉林工程师范技术学院吉林省长春市 摘要： 项目管理软件的实质就是软件项目计划的编制和软件项目计划的跟踪控制，这里计划是项目成功实施的指南和跟踪控制依据，而跟踪控制又保证项目计划的成功执行。本文以实力具体分析在软件开发过程中如何进行软件项目管理。 关键词：软件项目管理 前言 随着信息技术的飞速发展，软件产品的规模也越来越庞大，个人单打独斗的作坊式开发方式已经越来越不适应发展的需要。各软件企业都在积极将软件项目管理引入开发活动中，对开发实行有效的管理。 从概念上讲，软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展（即减小开发风险）。 在软件项目中有两条非常重要的线索，一条是软件项目开发过程，另外一条是软件项目管理过程。通常，人们容易注意软件项目开发过程，而忽略软件项目管理过程的线索。事实上，后者很重要，有时其重要性甚至超过项目开发过程。项目管理可以让一个项目获得高额的盈利也可以让一个项目损失惨重，而编码的影响力则相对小一些、。现实中由于出色的项目管理，将已经亏损很严重的项目又重新扭亏为盈的例子并不少见。 项目管理在生活中的例子很多。例如进行一次商品采购，你会在一张纸上记录所有需要购买的东西（即采购清单），这个采购清单帮助你不要遗漏采购项，你可以采用“完成一个采购项，在采购清单上打一个勾”的方法协助你完成采购。与此类似，软件项目管理也是如何管理好软件项目的内容、花费的时间（进度）以及花费的代价（规模成本）。为此需要制定一个好的项目计划，然后控制好这个计划。编制软件项目计划、跟踪控制软件项目计划这就是软件项目管理的实质。其中，计划是项目成功实施的指南和跟踪控制的依据，而跟踪控制是项目计划成功执行的保证。 一、确定软件项目开发的策略 项目经理的首要任务是编制项目计划。项目计划有三大核心目标：确定项目范围、项目预算、项目进度，即明确项目做什么、花多少钱、需要多长时间。为了制定一个合理有效的计划，项目经理需要从项目需求开始确定项目范围，然后将项目的需求进行分解，以便于估算、安排资源和合理的进度等。这样就形成了三个核心计划：范围计划、成本计划和进度计划。此外，作为完整的项目计划，质量计划、风险计划、沟通计划等同样也必不可少。没有质量管理的项目是失败的项目，没有风险管理的项目会时时处于风险之中，没有沟通的项目是很难完成的。项目规划从合同阶段就开始了，其实任何一个合同的主要内容也是确定项目的范围、时间和成本。 软件项目最终的的结果是根据用户的需求提交一个用户满意的产品，这是一个从无