软件项目管理课程课件(清华)

教材：软件项目管理覃征等编著《软件项目管理》《软件项目管理》第1章导论1.1软件工程一、软件工程定义软件：是与一个系统，特别是一个计算机系统有关的程序、过程和有关文档的完整集合。工程：是科学和数学的应用，通过这一应用，使得自然界的物质和能源的特性通过各种结构、机器、产品、系统和过程成为对人类有用的东西。软件工程的定义有多种说法:FritzBauer[NAV69]在NATO会议上给出的定义:软件工程是建立和使用一套合理的工程原则，从而经济地获得可靠的和能在实际机器上高效运行的软件。IEEE[IEEE93]给出了一个更加综合的定义：（１）将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。（２）（１）中所述方法的研究。本书给出的定义:软件工程是一类求解软件的工程。它应用计算机科学、数学以及管理科学等原理，借鉴传统工程的原则、方法，创建软件以达到提高软件质量、降低成本、按时按量交付的目的。计算机科学、数学用于构造模型和算法。工程科学用于制定规范、设计模式、评估成本及确定权衡。管理科学用于计划、资源、质量、成本等管理。二．软件工程框架软件工程目标软件工程活动软件工程原则软件工程框架软件工程目标正确性－－软件产品达到预期功能的程度。可用性－－软件基本结构、实现、文档为用户可用的程度。合算性－－具有经济效益，即开发、运行的开销满足用户要求的程度。软件工程活动---生产软件步骤问题定义－－明确要解决的问题可行性分析－－即定义的问题是否有解决的办法需求分析－－为解决问题，目标系统必须具备哪些功能设计－－总体设计，详细设计实现－－编写程序代码确认－－测试支持－－软件维护软件工程原则选取适宜的开发模型采用合适的设计方法提供高质量的工程支持重视开发过程的管理三．软件工程模型所有软件工程的活动都必须进行管理。软件项目管理贯穿于软件工程的演化过程。软件工程的演化过程：三．软件工程模型软件工程模型:组织软件工程活动的方法，称为软件工程模型。软件工程模型是用一定的流程将各个活动连接起来，并可用规范的方式操作全过程，如同工厂的生产线。常见模型有线性、快速原型、螺旋、渐增式等模型。常见的软件工程模型线性模型（也称，瀑布模型，顺序模型）常用的软件工程模型螺旋模型可看成是连接的线性模型常用的软件工程模型渐增式模型（增量模型）常用的软件工程模型渐增式模型首先构建系统的基本轮询回路：1.2项目管理一．项目与项目管理１．项目的概念及特点项目：是指在一定约束条件下具有特定目标的一项一次性任务．共同特点：①一次性，又称为单件性②目标的明确性：成果性目标（功能性要求），约束性目标③作为管理对像的整体性2、项目的生命周期２．项目的生命周期①项目启动阶段进行可行性分析，若接受项目进行需求确认，项目立项②项目计划阶段建立解决问题方案，向客户提交种计划书③项目实施阶段执行解决方案，实现项目的目标④工作结束阶段正式验收项目另一书中对项目周期阶段的划分生命周期阶段工程阶段初始阶段细化阶段生产阶段构造阶段移交阶段各阶段特点工程阶段：使计划、需求和构架同时进化，并解决开发风险，这个阶段以一个可执行构架基线结束，即工程阶段进行设计和综合活动。生产阶段：进行构造、测试和实施活动。各阶段特点借助提高功能的演示使系统能力得以进化。各种活动同时进化，每个阶段都包括一次或多次迭代，一次迭代表示一个活动序列，这些活动有明确的中间事件（里程碑）。各阶段特点主里程碑：使用正式版本的评价标准和发布说明书，一个阶段结束产生一个主里程碑。次里程碑：使用非正式版本，一次迭代结束产生一个次里程碑。各阶段特点为实现整个项目的某个特定状态，每个阶段都要进行足够次数迭代。各阶段的工作产品（制品，文档等），同时进化产生，但每个阶段都有一个主要焦点：初始阶段需求（生命周期目标里程碑）细化阶段设计（生命周期构架里程碑）构造阶段实现（初始的可操作能力里程碑）移交阶段实施（产品发布里程碑）（这里的模型是渐增式（增量式））３．项目管理项目管理定义PMI定义：在项目活动中运用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目的要求。项目管理又可定义为：在一个确定的时间范围内，为了完成一个既定的目标，通过特殊形式的临时性组织运行机制，经有效的计划、组织、领导和控制，充分利用既定有限资源的一种系统管理方法。项目管理特点①综合性②创造性③时间性４．项目管理的要素范围、时间、成本、质量、组织、客户满意度二．项目管理知识体系1.集成管理2.范围管理3.九个知识领域时间管理4.成本管理5.质量管理6.人力资源管理7.沟通管理8.采购管理9.风险管理三．项目管理学科的发展项目管理学科发展的特点全球化发展、多元化发展、专业化发展项目管理学科在双向探索中前进各学科领域的理论、方法应用于项目管理，项目管理的理论、方法应用于各学科领域项目学发展的趋势1.微观项目管理，即单一项目的管理2.PMBOK是当前项目管理学科发展的重要内容3.项目学是知识创新与市场相结合的综合化发展4.项目学是科学、技术和艺术的综合１．３软件项目管理一．软件项目产品的特点1.抽象性2.缺陷检测的困难性3.高度的复杂性4.缺乏统一规则二．软件项目失控的原因软件失控项目(p15-16)是指软件项目在进行时遇到困难，导致大大超出可控制范围的项目。软件项目失控的原因七方面原因：需求不明确、计划不充分和过于乐观的估计、采用新技术、管理方法缺乏或不恰当、性能问题、团队组织不当、人际因素三．软件项目管理的内容软件项目管理的定义(p19)软件项目管理的过程(p19)软件项目管理的内容(p19-20)软件项目管理的定义PMI对项目管理定义：在项目活动中运用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目的要求。软件项目管理的定义：在软件项目活动中运用一系列的知识、技能、工具和技术，以满足软件需求方的整体要求。软件项目管理的过程1.启动软件项目2.制定项目计划3.跟踪及控制项目计划4.评审项目计划5.编写管理文档软件项目管理的内容1.软件项目需求管理2.软件项目估算与进度管理3.软件项目配置管理4.软件项目风险管理5.软件项目质量管理6.软件项目资源管理第２章软件项目需求管理２．１软件需求一.软件需求概念1.定义简单地说，软件需求就是确定系统需要做什么．严格意义上，软件需求是系统或软件必须达到的目标与能力定义软件需求的五项内容1.系统的输入2.系统的输出3.系统的功能4.系统的属性5.系统环境的属性2.软件需求在软件项目的作用软件需求与其他软件过程的关系二软件需求类别1.软件需求的抽象层次软件需求分成四个抽象层次1.原始问题描述2.用户需求3.系统需求4.软件设计描述软件需求的抽象层次1.原始问题描述是对要解决问题的叙述2.用户需求是用自然语言和图表给出的关于系统需要提供的服务及系统的操作约束3.系统需求用详细的术语给出系统要提供的服务及受到的约束，因而系统需求文档也称为功能描述．4.软件设计描述是在系统需求的基础上加入更详细的内容构成的，它作为软件详细设计和实现的基础，是对软件设计活动的概要描述．原始问题描述和用户需求的抽象层次比较高．能帮助我们在较高的抽象层次上进行交流，便于用户和软件开发人员之间的理解和沟通．系统需求和软件设计描述则是具体的，可以根据它们来进行编码实现．通常情况下，经常提到的是用户需求和系统需求．2.用户需求用户需求从用户的角度描述系统的需求，以便没有专业技术背景的用户能看懂．它只描述系统的外部行为，尽量避免涉及系统内部的设计特性，因而用户需求就不可能使用任何实现模型来描述，而只能通过自然语言，图表，图形等来叙述．使用自然语言可能出现如下问题描述困难需求混乱因此写需求文档应遵守一些简单原则：标准的格式使用一致的语言使用特殊文本尽量避免专业术语3.系统需求系统需求是比用户需求更为详细和专业的需求描述，是系统实现的依据．一个完整且一致的系统需求描述，是软件设计的起点．系统需求描述通常采用结构化语言和过程设计语言PDL.系统需求的描述语言名称说明优点缺点结构化语言是对自然语言格式化，依赖于定义标准格式或模板来表达需求描述表现能力强、易于理解、一致性约束、控制结构、图形化显示仍然有一定程度的二义性；细致程度欠缺PDL源于像Java或Ada这样的程序设计语言，包含附加的、更抽象的构造来提高其表达能力可通过软件工具进行语法和语义检查表达系统功能的能力不足、使用的符号只有具有程序设计背景的人才能理解4．系统需求的分类分为三类：功能需求非功能需求领域需求(1)功能需求功能需求描述系统所应提供的功能和服务，包括系统应该提供的服务，对输入如何响应及特定条件下系统行为的描述．系统的功能需求应该具备全面性和一致性．要做到全面和一致几乎是不可能的．原因有二，其一是系统本身固有的复杂性；其二是用户和开发人员站在不同的立场上，导致他们对需求的理解有偏颇，甚至出现矛盾为保证软件项目的成功，无论在哪个阶段，只要发现问题，都必须修正需求文档．(2)非功能需求非功能需求是指那些不直接与系统的具体功能相关的一类需求，但它们与系统的总体特性相关，如可靠性，响应时间，存储空间等．非功能需求定义了对系统提供的服务或功能的约束，包括时间约束，空间约束，开发过程约束及应遵循的标准等按照非功能需求的起源，可将其分为三大类：产品需求，机构需求，外部需求；产品需求对产品的行为进行描述；机构需求描述用户与开发人员所在机构的政策和规定；外部需求范围比较广，包括系统的所有外部因素和开发过程表2.2非功能需求的类别非功能需求产品需求可用性需求效率需求性能需求空间需求可靠性需求可移植性需求机构需求交付需求实现需求标准需求外部需求互操作需求道德需求立法需求隐私需求安全性需求(3)领域需求领域需求的来源不是系统的用户，而是系统应用的领域，反应了该领域的特点．领域需求可能是功能需求，也可能是非功能需，其确定需要领域知识．三．软件需求文档软件需求文档是对软件系统要求的陈述．包括：用户需求系统需求三．软件需求文档1.需求文档的编制与作用编写需求文档时，以下几点是应该注意的：语句和段落尽量简短．表达时采用主动语态．语句要完整，且语法，标点等正确无误．使用的术语要与词汇表中的定义保持一致．陈述时要采用一致的样式．避免模糊的，主观的术语，如性能＂优越＂避免使用比较性的词汇，尽量给出定量的说明，含糊的语句表达将引起需求的不可验证．需求文档的作用使用对象需求文档的作用软件项目客户了解软件项目能够提供的软件产品，检查软件需求是否满足需要项目管理人员根据需求文档制定项目的开发计划和软件过程，初步预测资源的使用软件开发人员理解要开发的产品及具体要开发的内容软件测试人员验证软件系统是否满足了预期的要求软件维护人员使用需求文档帮助理解软件系统内在的逻辑关系软件发布人员在需求文档的基础上编写用户文档，如用户手册软件培训人员在需求文档的基础上编写培训材料２．软件需求规格说明(1)基本含义规格就是一个预期的或已存在的计算机系统的表示，它可以作为开发者和用户之间协议的基础来产生预期的系统．软件需求规格SRS也称为功能规格说明，需求协议或系统规格说明，精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，是对外部行为和系统环境（软件，硬件，通信端口和人）接口的简洁完整的描述性文档．软件项目管理者用SRS来对项目进行计划和管理。除设计和实现上的限制外，SRS一般不包括设计、构建、测试或工程管理的细节。SRS的基本内容包括功能需求和非功能需求。功能需求定义系统需要“做什么”,描述系统输入输出的映射及其关联信息,完整地刻画系统功能,是整个软件需求的核心。非功能需求定义系统的属性,描述和功能无关的目标系统特性,包括系统的性能、有效性、可靠性、安全性、易维护性及可见性等。(2)IEEE标准830-1998见:P27—P28