软件项目管理教程.docx
《软件项目管理教程.docx》由会员分享，可在线阅读，更多相关《软件项目管理教程.docx（63页珍藏版）》请在冰豆网上搜索。
软件项目管理教程
软件项目管理实用教程
前言
“和谐”是软件项目管理的精髓。
软件项目管理是一门科学也是一门艺术。
我们既要遵循科学的规律去管理软件项目，也要因地制宜，灵活机动，随行就市地做好项目中的每一个子任务，实现每个子目标。
如何做好项目管理？
作者以为，我们需要知晓如何定义项目的目标，制定项目的目标计划；需要知晓项目的开发周期、开发模型与开发步骤，做好软件项目的系统分析与设计；需要知晓如何建立项目质量的标准体系，定期和不定期地进行项目质量的检查与评比；需要知晓如何分析一个项目的工作任务结构，制定出项目的工作计划（时间计划）和成本计划；需要依据项目的工作任务结构（WBS）来预知、规避与处理项目的风险，做好项目的风险计划；需要知晓如何招募项目组成员，有效地分配项目任务，并带领您的项目团队在规定的时间内，以有限的项目资源（人、财、物与时间）去实现一个既定的项目目标。
本书结合我国目前软件项目开发与管理的实际，在上述几个方面都做了简要与实用的阐述,希望您能从中获得收益，在以后的软件项目开发活动中取得成功。
本书的任务与目的：
（1）定义项目范围；
（2）预估项目工作量；
（3）编制项目计划、成本计划、风险计划；
（4）如何做好系统分析；
（5）如何做好软件系统的架构设计；
（6）项目团队建设；
（7）软件质量分析与管理；
（8）项目变更控制与管理；
（9）软件项目的招投标、项目立项、可行性分析、合同签订、项目验收等。
第1章项目管理综述
我们的企业要两条腿走路，一个是科学技术，一个是项目管理。
——华罗庚
1.1什么是项目
项目是为完成某个独特的产品或服务所做的一次性任务。
软件项目的特点：
（1）项目是一项有计划的活动。
若一项工作的开展与完成无需与之对应的工作目标计划、工作任务计划、工作时间计划、工作成果质量计划与资源（人、财、物、时间）使用计划，我们就不能把该工作看做为一个项目，也就是说，项目是一项耗时长，有一定技术难度，相对复杂，且需要消耗一些资源的工作。
（2）项目是一项基于日常工作与科学探索之间的活动。
从一般概念上来讲，日常工作应该是简单的，容易完成的，具有固定的工作流程与工作模式，变化小，挑战性低，工作结果具有明显的确定性；科学探索活动尽管拥有坚实的理论体系，科学的探索途径，但需要多长的时间，其工作结果怎样却不能预先知晓。
软件项目工作居于上述两者之间，既拥有枯燥繁杂的日常工作之特点，也拥有自身的理论体系，具有一定的技术性与挑战性，吸引了一批又一批，一代又一代的仁人志士为之而奋斗。
（3）项目是一项具有确定的工作目标，需要产出固定的项目产品或需要实施与完成项目所规定的若干服务。
比如开发出一套ERP软件系统或完成ERP软件系统中的数据库系统的升级。
（4）项目具有预先确定的时间周期。
比如用一年的时间开发出一套ERP软件系统或用三个月的时间为某个企业实施ERP软件系统。
（5）项目是一群人的工作，需要相互合作，共同完成，不是只由你自己也不是只需要你自己就能完成的工作。
（6）项目需要专家的支持与参与，需要拥有广泛的领域知识与一定的专业技术，不是一般人所能胜任与完成的工作。
该特性强调了项目工作的难度与复杂性。
（7）项目需要分阶段完成。
该特性强调了项目工作的长期性，项目成果的阶段性，同时也指明了项目最终目标实现的途径。
（8）所需的项目资源是有限的，是受限的。
软件项目的分类：
●按规模划分，可分为大型项目、中型项目和小型微型项目等。
●按软件开发模式划分，可分为组织内部项目（软件产品项目）、为用户开发的外部项目（定制项目）和软件外包项目（承接子模块、子系统）。
●按产品交付类型划分，可分为产品型项目、一次型项目。
产品型项目往往来源于多个的一次性项目。
●按软件商业模式划分，可分为软件产品销售、在线服务（SaaS）两种模式，或者分为随需服务模式（on-demand）和内部部署（on-premise/on-Site）模式。
●按软件发布方式划分，可分为新项目、重复与类似项目，也可分为完整版本、次要版本或服务包（servicepack）、修正补丁包（patch）等。
●按项目待开发的产品划分，可分为组织型、嵌入型和半独立型。
●按系统架构划分，可分B/S、C/S多层结构，也可分集中式系统和分布式系统，或者分为面向对象、面向服务、面向组件等类型。
●按技术划分，可分为Web应用、客户端应用、系统平台软件等，也可分为J2EE、.Net等不同平台之上的项目。
1.2什么是项目管理
PMBOK（ProjectManagementBodyofKnowledge，项目管理的知识体系）给出的定义:
项目管理是为了满足项目需求，在项目活动中采用的知识、方法、技术和工具的集合。
PRINCE2（PRojectINControlledEnvironment，受控环境下的项目管理）给出的定义：
项目管理是对项目各个方面的计划、监督和控制，并激励项目的所有参与人员去达到项目的时间、质量、成本、性能等多方面的目标。
作者特别推崇PRINCE2给出的定义。
PRINCE2由英国政府商务部（OGC）所有，于1996年开始推广，它的运用不仅仅局限于在英国，事实上成为了所有类型项目的管理标准，并已迅速发展成为国际标准。
世界各地的许多企业将其作为他们管理项目的首选方法。
PRINCE2描述了如何以一种有逻辑性的、有组织的方法，按照明确的步骤对项目进行管理。
PRINCE2不是一种工具也不是一种技巧，而是结构化的项目管理流程，这也是它为什么容易被调整和升级，为什么适用于所有类型的项目的原因。
一般来说，项目管理包含下列一些活动：
（1）计划---确定项目的目标即确定要做什么，实现目标需要多长的时间（Howlong的问题）和成本（Howmuch的问题），项目的质量标准是什么，质量如何保证，目标的实现过程中可能会出现什么样的风险；
（2）组织---做项目需要有一个合法的机构，需要有一个能战斗的团队，在恰当的机构组织内做好各方面的安排（人、财、物与时间的安排）；
（3）人员---让合适的人做合适的事。
遵循能者多劳，把不合适的人今早地踢出项目团队的原则；
（4）指导---解决困难与冲突。
困难有在实现目标的多种方法与途径中选择一合适方法与途径的困难，有某些实现技术上的困难，有人员短缺、时间紧迫、资金不足等等方面的困难；
（5）监督---确保按计划开展，即确保项目能在规定的时间、规定的成本、规定的质量要求下完成；
（6）控制---及时弥补项目缺陷。
例如：
某团队成员离岗了怎么办？
某人员最近制造的错误非常地多怎么办？
眼看项目的截止时间快到了，但任务还有许多没完成怎么办？
（7）创新---提出问题的新的解决方案，乃至提出新的问题。
创新是一个软件企业的最核心的竞争力；
（8）关系---与客户、用户、软硬件系统供应商、咨询顾问、团队其他人员等项目利益人（Stakeholder）保持联系。
图1.2.1我说你做就是管理
项目管理的四要素是：
项目范围、项目时间、项目成本（资金预算）与项目质量。
它们之间的关系如图1.2.2所示。
图1.2.2项目管理要素间的和谐关系
项目管理的本质是：
如何让项目团队成员依据项目的开发制度与过程，运用必备的软件工具，在确定的项目范围之内，以计划好的时间与成本，制造或完成满足质量要求的产品或服务。
项目管理的本质如图1.2.3所示。
图1.2.3项目管理的本质
项目成功的标志有如下几点：
●在规定的时间内完成已知的项目；
●项目成本控制在预算之内（过底的成本不一定是好事）；
●功能特性（项目质量）达到规格说明书所要求的水平；
●项目通过客户或用户的验收；
●项目实施者收到了全部的项目经费（最重要的标志）；
●项目范围变化是最小的或可控的；
●没有干扰或严重影响整个组织的工作流程。
项目管理成功要素有下列几点：
●制定计划：
预估和确定项目的工作量大小、所需资源和进度、风险应对措施等；
●建立组织：
建立项目组，并有明确的角色定义和任务分工；
●配备资源：
任用各种层次的技术人员和管理人员，以及准备所需的软硬件；
●监控执行：
协调项目各方人员，监控各种风险，督促项目进展，随时检查实施情况，确保项目按计划进行，按时、按质完成任务；
●总结提高：
项目完成后，及时进行总结，吸取教训，分享经验，丰富组织的项目管理数据库或知识库。
项目实施过程中的项目状态与项目成功要素之间的关系如图1.2.4所示。
图1.2.4项目状态与项目成功要素之间的关系
项目管理的基本方法有阶段化管理、量化管理与优化管理等。
阶段化管理：
将项目的生命周期分为若干个阶段，再根据不同阶段所具有的不同特点来进行针对性的管理。
量化管理：
针对影响项目成功的因素制定指标、收集数据、分析数据，从而完成对项目的控制和优化。
优化管理：
分析项目每部分所蕴涵的知识，不断吸取教训、总结经验，将知识和实践更好地融合在一起，从而对项目的计划、实施办法等进行优化，获得项目的最佳效益。
项目角色和职能
角色
职能
项目经理
项目的整体计划、组织和控制。
需求人员
在整个项目中负责获取、阐述以及维护产品需求及书写文档。
设计人员
在整个项目中负责评价、选择、阐述以及维护产品设计以及书写文档。
编码人员
根据设计完成代码编写任务并修正代码中的错误。
测试人员
负责设计和编写测试用例，以及完成最后的测试执行。
质量保证人员
负责对产品的验收、检查和测试的结果进行计划、引导并做出报告。
环境维护人员
负责开发和测试环境的开发和维护。
其他
另外的角色，如文档规范人员、硬件工程师等。
软件项目管理和生命周期的活动比较
项目生命周期
1.3项目管理的知识体系
美国PMI推出的项目管理知识体系PMBOK，目前最新版是PMBOK2004。
包括九个项目管理知识领域，44个基本的项目管理过程。
知识域
启动
计划编制
执行
监控
收尾
项目
综合管理
制定项目章程；制定项目初步范围说明书
制定项目管理计划
指导与管理项目执行
监控项目工作
整体变更控制
项目收尾
项目
范围管理
范围计划
范围定义
制作工作分解结构
范围核实
范围控制
项目
时间管理
活动定义/排序
活动资源估算
活动时间估算
编制进度表
进度控制
项目
成本管理
成本估算/预算
成本控制
项目
质量控制
质量规划
质量保证
质量控制
项目人力
资源管理
人力资源规划
人员招聘
团队建设
项目团队管理
项目
沟通管理
沟通规划
信息分发
绩效报告
相关利益者管理
项目
风险管理
风险管理规划
风险识别
风险定性/定量分析
风险应对规划
风险监控
项目
采购管理
采购/发包规划
询价
供方选择
合同管理
合同收尾
英国政府商务部（OGC））出资研究开发PRINCE，受控环境下的项目管理（PRojectsINControlledEnvironments）。
PRINCE2提供一种精辟的、可调整的过程模型。
这个过程模型包含了8个管理过程和它们各自的子过程，为参与项目的各方提供了一种稳固的工作架构和顺畅的沟通渠道。
这些过程可根据项目的需要做适当的增减。
PRINCE2主要过程的作用可归纳如下：
（1）项目指导（DP）过程。
定义了项目管理委员会的职责，确保项目管理委员会对商业论证最终负责，必要时对项目经理和高级管理层提出建议。
（2）项目准备（SU）过程。
可根据项目的需要来决定其正式程度。
该过程明确一个基本问题：
“我们的项目是否切实可行、值得进行？
”、
（3）项目启动（IP）过程。
是第一个真正的项目过程，它为项目奠定一个坚实的基础，与项目管理委员会在目标、风险和产品质量预期方面取得共识。
（4）阶段控制（CS）过程。
包含项目经理的日常管理活动。
（5）产品交付管理（MP）过程。
涵盖根据产品描述中的质量标准制造和递交实际产品的一切工作。
（6）项目阶段边界管理（SB）过程。
对项目现阶段的现状与价值的评估，有助于决定商业论证是否仍旧可行。
（7）项目收尾（CP）过程。
确保项目的结束，采取必要的后续行动使得项目的后审查等计划工作都能被得到有效地控制。
（8）项目计划（PL）过程。
描述了计划和重新计划项目的可重复的步骤，确保能够按照要求来制定计划。
图：
1.3.1PRINCE2的项目管理模型
IBM公司的全球项目管理方法（World-wideProjectManagementmethod，WWPMM）由4个有机部分组成，即项目管理领域、项目管理工作产品、项目管理工作模式和项目管理系统。
WWPMM由4个有机部分（即项目管理领域、工作产品、工作模式和信息系统）组成，并定义了13个领域及其51个子领域，在此基础上再分解为150个过程。
1.变更管理ChangeManagement
2.沟通管理CommunicationManagement
3.交付管理DeliveryManagement
4.事件管理EventManagement
5.人力资源管理HRM---HumanResourceManagement（对应PMBOK的人力资源管理）
6.项目定义ProjectDefintion
7.质量管理QualityManagement（对应PMBOK的质量管理）
8.资助人协议管理SponsorAgreementManagement
9.风险管理RiskManagement（对应PMBOK的风险管理）
10.跟踪和控制TrackAndControl
11.供应商管理SupplierManagement（对应PMBOK的采购管理）
12.技术环境管理TechnicalEnvironmentManagement
13.工作计划管理WorkPlanManagement
1.4项目管理的几项原则
1.4.1项目管理的透明原则
项目管理和这本书所要阐述的一个最重要的原则就是“透明”原则。
项目经理频繁作出的决定如果是基于项目团队所收集的信息，如果是基于预先广泛地征求项目利益人的意见，那么这个项目往往会成功。
营造一个透明的项目环境意味着项目中各项信息的公开性，意味着项目管理过程中的各种决定有着坚实的理论基础、事实依据与人脉关系。
事实上，没有一个项目是严格按照计划进行的，唯一的解决办法就是让项目利益人都知道困难所在，都提出各自的意见、期望和办法，然后再共同选择一条最好的解决问题的途径。
但是，作为一个项目经理很难在项目的全过程中保持“诚实”。
例如：
你的老板希望你在某年某月某日之前完成某个项目，而你认为这是不可能的，你那时怎么办？
你若不理会老板，我行我素，你将会受到老板的严厉批评；若你跟老板讲道理，而老板又是外行，你老板反过来又会认为你工作不力，能力不行，岂不冤枉哉！
在现实生活中，许多项目经理在面对项目交付截止日期时会自加压力，用加班加点来赶进度。
但也有一些项目经理常常通过缩小项目范围，甚至牺牲项目质量来达到项目进度的要求。
他们明明知道这个项目是程序员通过打补丁来完成的，缺乏通用性，更没有软件架构的支撑，测试不充分，健壮性与可维护性难以保障。
这类问题最好的解决办法就是透明性，最好是在项目一开始的时候就让全体项目利益人都知道困难所在，项目经理不能密而不宣，默默对带，甚至喝着咖啡静静地等待着项目截止期的到来。
1.4.2信任你的团队原则
项目经理对项目负责，这是天经地义的事。
但这并不代表着你需要亲历所有的事，需要比团队中任何其他人更精通业务技术，需要对项目中的所有工作负责！
然而，许多项目经理正是这样的，他们武断地扩大或缩减项目计划（范围、时间、成本与质量），只考虑怎样让现实与计划一致，很少考虑软件系统本身。
管理项目就是组建一个团队，并保障这个团队的生产效力。
做好这点的最好办法是信任与依靠团队每个成员的能力、智慧与经验，放弃项目的微观管理，在某种意义上真正做到“你办事我放心”。
项目经理做决策前要听取大家的意见与建议，这不代表你没有意见与主见。
如果你没有充足的理由否定其他成员的建议，那就不要马上否定。
你最好的做法是：
“聆听”、“信任”、“支持”、“总结”、“吸取”与“提高”。
当然你不能盲目地信任你的团队，你需要评估建议的合理性。
本书除了讲清项目管理的原理与过程外，还重点讲解了如何做系统分析、软件的架构设计等，其目的就是让项目经理能掌握覆盖软件项目开发全过程的知识，以便做好项目的“指导”工作。
1.4.3复查与测试原则
从一般意义上看，复查是一件枯燥无新意的工作，并不是很多人愿意反复查看与研究自己“已经”搞定的事的。
另外，复查也没有一个好的名声，好像是一批人戴着放大镜吹毛求疵地查找另一批人的缺点似的。
因此，在项目管理的实际过程中往往需要某些人在项目的相关文档上签字，以此表示文档内容的正确与否性与签字人有关。
复查的目的不是为了形成一件完美无缺的产品，而是为了防止出现不必要的错误，因为从纸张上发现错误总要比用软件测试容易和便宜得多；同时也是项目利益人（包括开发人员）给项目经理的一个可靠的信息，一个可信的承诺，项目经理以此可作出种种的项目决策。
复查是静态的，测试可视作为动态的。
静态时的人，状态甚好，往往思维缜密，目标、条理与逻辑性都比较强，可找出文档中的许多不当之处，真可用成语“安心定志”与“心静神怡”来形容。
测试是复查的一种动态抽样证明，关键是需要做好测试计划，使得测试既具有典型性、代表性，又具有全面性。
1.4.4平等原则
做软件项目不仅仅是写代码，在软件项目的整个开发周期中会产生各种各样的产品，例如：
文档、进度表、计划、源代码、错误报告等，它们分别是由项目团队中的不同成员制造出来的，我们绝对不能说某个产品比其它产品重要，因为只要某件产品中存在缺陷，就会影响最终软件产品的正确性与质量，这也就意味着项目团队成员之间只有分工的不同，没有重要性的不同。
对许多项目经理来说，当程序员与测试员有意见分歧时，项目经理往往倾向于信任程序员；当系统分析师与程序员有意见分歧时，项目经理又会倾向于信任系统分析师。
这可不是一个好的习惯，会导致一个项目团队进入一个人与人之间不相平等的境地。
客观地对待项目组成员在项目开发中的各类建议是制造一个好软件产品的关键，项目组成员在项目决策中应有平等的发言权与地位。
1.4.5正确地做事原则
众所周知，软件项目的开发需要分若干个阶段来进行，一开始就要正确地做项目，要比以后发现问题，纠正问题要好得多得多。
第2章软件项目开发流程
2.1开发流程简介
2.1.1需求分析
1．相关系统分析员初步了解用户需求，用WORD写出要开发的系统的主要功能模块，每个功能模块有哪些小功能模块。
具体来讲，要做以下一些事：
（1）听取用户的项目介绍；
（2）明白用户的主要需求（用户想干什么，他们的目的是什么）；
（3）收集用户的主要表格（统计与分析表）与表单（往往是今后的软件系统的原始数据的输入界面）；
（4）逐一理解用户的表格与表单（各数据项目的含义）；
（5）把你的理解写成WORD文档；
（6）初步定义相关的用户操作界面；
（7）把上述的WORD文档提交给用户确认；
（8）重复上述过程，直至你和用户均认为理解了用户的需求。
这一步的特点是：
（1）按用户的思路分析问题；
（2）理解用户的需求为唯一目的；
（3）不要加以归纳、总结、抽象与提高。
2．系统分析员深入了解和分析需求，根据自己的经验写出一份详细的需求文档。
文档越详细，界面越多越好。
这一步的特点是：
（1）融入了开发方的经验与建议（包括工作流程的定义、表单格式的定义、报表格式的定义等）；
（2）尽一切可能让用户理解与接受这一版的系统需求分析说明书，需要用户方的项目负责人签字确认。
该版系统分析说明书具有一定的法律效力，可作为软件开发合同的附件。
2.1.2概要设计
概要设计是面向用户的设计，是用户能看得懂的设计。
主要针对下列几个方面进行设计：
（1）软件系统的一层、二层操作界面（点击主界面上的某些菜单显示出二层操作界面。
这部分工作可由美工完成）；
（2）功能菜单的布局设计；
（3）主要功能的输入界面设计（表单格式设计）；
（4）主要报表的输出界面（浏览与打印格式）设计；
（5）软件系统的基本处理流程（数据流程）设计；
（6）用户的组织结构设计；
（7）子系统间的接口设计。
概要设计的要点有下列几条：
（1）简洁性；
（2）可视化性。
最好能进行软件系统的原型演示；
（3）功能全面性。
否则用户会提出异议；
2.1.3详细设计
详细设计是面向程序员的设计，是指导与规范程序员的代码编制行为的设计。
设计工作主要有下列几个方面：
（1）功能模块划分设计，或叫做软件分解结构（PBS）设计；
（2）模块的主要算法（流程图）、接口（入口参数、出口参数，甚至需要指定入出口参数的名称）设计；
（3）页面布局设计（包括页面上所有按钮的功能、点击流程、位置布局等的设计）；
（4）数据结构设计（数据库中所有表文件，及各表文件中各字段的代码、类型与宽度等的设计）。
详细设计的目标是：
可按功能模块下发软件开发任务，使每个任务均能放心地让程序员去实现，使得程序员在编码阶段没有太大的自由度。
详细设计也许会扼杀某些程序员的聪明才智，但我们赞成这样的口号，叫做“步调一致才能得胜利”。
本阶段的里程牌是《软件系统详细设计说明书》。
2.1.4编码
开发者根据《软件系统详细设计说明书》中对数据结构、算法和模块实现等方面的设计要求，开始编写程序，分别实现各模块的功能，从而实现目标系统的功能。
程序员完成各自的功能模块，对各自的模块质量负责，为系统联调作好准备。
2.1.5测试
本步骤的目的是测试程序员已编写好的模块，先进行模块测试，然后逐步进行模块与模块之间的系统联调。
为了做好测试，测试人员需要依据《系统分析说明书》、《软件系统详细设计说明书》来预先编制一本测试计划（非常详细的测试报告，含有测试用例）。
这一步骤的里程碑是：
《测试报告》与可交付给用户测试的软件系统。
用户需要独立地进行“用户接收性测试”，用户在这一过程中完成软件系统中各功能的确认（初次验收）。
2.1.6系统交付
软件测试达到用户的要求后，软件系统开发者应向用户提交开发的安装程序、数据字典、《系统安装手册》、《用户使用指南》、《需求分析报告》、《设计报告》、《测试报告》等双方合同约定的产品。
《系统安装手册》应详细介绍安装软件对运行环境的要求、安装软件的定义和内容、在客户端、服务器端及中间件的具体安装步骤、安装后的系统配置等。
作为项目性开发，系统安装由开发方完成；对于软件产品，系统安装由用户自行完成。
《用户使用指南》应包括软件各项功能的使用流程、操作步骤、相应业务介绍、特殊提示和注意事项等方面的内容，在需要时还应举例说明。
用户使用手册或指南编写的目标是让用户能依据手册学会软件系统的使用。
2.1.7项目验收
用户验收。
目标：
用户或客户方的相关领导在验收书上签字。
验收手段：
一般是开验收会议
2.2项目准备与启动
2.2.1项目建议书
项目建议书（projectproposal），就是项目立项申请报告。
它可以比较简要，也可以比较详尽，而重点是如何向有关
升级会员 