项目变更

　　作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。 它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上所具有的选择限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能，多角度描述产品对用户和开发人员都极为重要。 　　需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的。 　　开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将会最终给系统带来极大损害的部分，而且以后再对它进行修改也极为困难。 　　不重视需求过程的项目队伍将自食其果。需求工程中的缺陷将给项目成功带来极大风险，这里的“成功”是指推出的产品能以合理的价格、及时地完成并在功能、质量上完全满足用户的期望。下面将讨论一些需求风险。第 5章将介绍怎样应用软件风险管理从而防止与需求有关的风险的出现和不适当的需求过程所引起的一些风险。 　　（1

对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” (Leffingwell 1997) 。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟 ( 期望差异 ) —开发者开发的与用户所想得到的软件存在着巨大期望差异。 在软件工程中，所有的风险承担者 (stakeholder)( 这个词很有意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众的，也有的翻译成参与者的，但是我想他的主要意思就是和这个项目有密切相关利益的人 ) 都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员 ( 负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人 ) 、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用有效的需求分析过程。软件需求的定义 IEEE 软件工程标准词汇表 (1997 年 )

项目又延期了，老板恨恨的批评了整个项目组，投入了那么多，产出在哪里？查原因，发现是由于项目的需求不断变更导致，这恐怕是很多项目经理、程序员都经历过的事。 我这里就谈谈项目延期的一个重要因素：需求问题 这张图大家再熟悉不过了，我再炒一下冷饭，列一下主要可能的情况 客户提出的需求 项目组 客户期望的结果 是否满意 需求A 系统A 系统A 是 需求A 系统B 系统A 否 需求A 系统A 系统B 否 客户为何提不了真正的需求？ 1、业务部门 ：业务人员基本是站在自身的角度看问题，从自身负责的业务出发，没有从本部门或更高层次来分析问题，导致需求的着眼点比较低。在此基础上形成的最终需求也就是把各部门的需求进行汇总，简单处理罢了。而且，业务部门对技术知识的匮乏，也导致其提出需求时是没有考虑技术上方面的。 2、技术人员 ：客户方面的技术人员由于业务知识有限，无法挖掘更深层次的需求，只能是基于已有需求，或者轻度发掘部分需求，无法从根本上解决需求的问题。 按照以上提出的需求，可想而知，项目的结局如何。也有部分项目，在需求分析阶段，生成了完整的需求规格说明书，并且用户签字画押，最终的结果是如果不能真正解决客户业务的问题，即使系统投产了，也必将引来用户的各种抱怨，势必对公司形象、后续项目产生各种不利影响。 我们在整天抱怨需求不断变化的同时，能否换个角度来看待需求的变化，假设需求就是变化的，事实情况也是如此

本文已同步至 GitHub / Gitee /公众号，感兴趣的同学帮忙点波关注~ 第一章 引论 1、“项目管理知识体系”：应该包含所有行业、应用领域项目管理的具体知识、技能、方法和实践。 2、我们发的这本巨厚的书叫“项目管理知识体系指南”简称“PMBOK 指南”，PMBOK 指南的目的： 收录项目管理知识体系中被“普遍公认”的“良好做法”的那一部分。 形成的一个项目管理标准和框架，提供一套项目管理专业的通用词汇；适用于所有领域、行业的项目管理。 标准实践中可以加以选择和裁剪； PMBOK 指南只讨论单个项目的管理 PMBOK 指南只讨论项目管理的共性 它是一套项目管理的指南，并不是具体的方法论。 1. 什么是项目？ 项目是：为创造独特的产品、服务或成果而进行的临时性工作。 pmbok 告诉我们项目有三大特性： 临时性 、 独特性 、 渐进明细 。 1）项目的过程是临时的，但临时并不意味着时间短。比如：修建体育场鸟巢是个项目，这个项目用了好几年时间，这个时间很长。过程是临时的，指的是项目有明确的起点和终点，起点是立项的时候。终点是： 目标达成（正常收尾） 不能达到目标项目终止（有可能是没钱了） 项目需求不复存在 客户或发起人希望终止等等 2）结果的独特性：项目创造的可交付成果是独特的，所以导致项目的不确定性和风险。项目创造出来的结果，PMBOK 里叫做可交付成果。可交付成果

Mercurial简介 Mercurial 是一款非常优秀的分布式版本控制系统(DCVS)，具有高效率、跨平台、可扩展、使用简便且开源等优点，是目前最为流行的版本控制工具之一。Mercurial英文意为水银，所以常被缩写为Hg。在使用Mercurial之前，我曾经使用过VSS(已停止更新)和 SVN ，也尝试过微软的 TFS ，它们都不是分布式版本控制系统，换句话说，就是当源码服务器故障或网络不通时，你将无法提交你所做的本地修改。这也是之前的版本控制工具与Mercurial最大的不同，目前与Mercurial类似的工具还有 Git ，但由于对Windows系统的支持做得不是很人性化，我个人不太喜欢。 最开始接触Mercurial时，由于长期使用SVN的缘故，已经习惯了依赖中央源码服务器，也曾感觉Mercurial的操作很别扭，不是很方便。但当我在项目中使用了一段时间以后，就喜欢上这个它了。下面放出Mercurial相关的一些信息： Mercurial官网： http://mercurial.selenic.com/ Mercurial客户端(TortoiseHg)： http://tortoisehg.bitbucket.org/ 支持Visual Studio中使用Mercurial的插件VisualHg： http://visualhg.codeplex.com/

软件需求分析与管理的十个问题 1.需求工作涉及到哪些内容 首先需求包括了产品需求，用户需求，软件需求。产品需求关注的是产品的标准化和通用化，会对收集到的用户需求进行分类和优化，结合业界标准系统模型进行抽象并通用化。用户需求反映的是用户面临的问题域，根据问题域用户期望的能够达到的解决效果；而对于软件需求则是用软件工程的语言结构化和文档化的对用户需求和产品需求的描述。 需求工作涉及到需求开发和需求管理。需求开发涉及到需求调研，需求收集，需求分析，需求开发等工作，其中的重点有业务流程，数据字典，业务规则，界面原型。对于基于面向对象的开发方法则涉及到业务用例，系统用例(涉众，基本流，扩展流，业务规则，界面，操作)等诸多内容。需求管理工作涉及到需求的状态管理，变更管理，需求的跟踪，需求的验证和确认等重要内容。 在我们需求分析和开发中，最容易忽视的主要有两点，一个就是缺乏需求分析和开发的过程，把用户需求直接作为了软件需求，没有需求建模和抽象的过程。另外一点就是对于性能，安全，易用性，可维护性和扩展性等非功能性需求没有考虑，导致开发出来的系统是一个不好用的半成品。CMMI把需求管理放到2级，需求开发放到3级，实际上真正的提高需求人员的需求分析和开发能力才是解决需求问题之道。需求分析开发做不好，需求变更或追踪管的再好也没有用处，在这点上一定不能本末倒置。 2.做好需求分析需要具备哪些知识

项目管理知识体系指南 （PMBOK）读书笔记 项目管理知识体系指南 1.引论 1.1 指南概论和目的 1.2 基本要素 1.2.1 项目 项目 是 为创造独特的产品、服务或成果而进行的临时性工作 。 独特的产品、服务或成果 临时性工作 项目驱动变更 项目驱动组织进行变更：“当前状态” => “将来状态” （期望的结果） 项目创造的商业价值 有形OR无形效益 项目启动背景 符合法规、法律或社会要求 满足相关方的要求或需求 执行、变更业务或 技术战略 创造、改进或 修复产品 、过程或服务 1.2.2 项目管理的重要性 1.2.3 项目、项目集、项目组合以及运营管理之间的关系 1.2.4 指南的组成部分 项目和开发生命周期 预测型、迭代型、增量型、适应型、混合型生命周期 项目阶段 阶段关口 （里程碑） 项目管理过程 项目管理过程组 启动、规划、执行、监控、收尾 项目管理知识领域 项目整合管理 包括为识别、定义、组合、统一和协调各项目管理过程组的各个过程和活动而开展的过程与活动 项目范围管理 包括确保项目做且只做所需的全部工作以成功完成项目的各个过程 项目进度管理 包括为管理项目按时完成所需的各个过程 项目成本管理 包括为使项目在批准的预算内完成而对成本进行规划、估算、预算、融资、筹资、管理和控制的各个过程 项目质量管理 包括把组织的质量政策应用于规划、管理、控制项目和产品质量要求

项目管理五大过程组： 1、启动过程组：获得授权，定义一个新项目或现有项目的一个新阶段，正式开始该项目或阶段的一组过程。 2、规划过程组：明确项目范围，优化目标，为实现目标而制定行动方案的一组过程。 3、执行过程组：完成项目管理计划中确定的工作以实现项目目标的一组过程。 4、监控过程组：跟踪、审查和调整项目进展与绩效，识别必要的计划变更并启动相应变更的一组过程。 5、收尾过程组：为完结所有过程组的所有活动以正式结束项目或阶段而实施的一组过程。 一、启动过程组 1、制定项目章程 制定项目章程是制定一份正式批准项目或阶段的文件，并记录能反映干系人的需要和期望的初步要求的过程。在多阶段项目中，这一过程可用来确认或优化在以前的制定项目章程过程中所做的相关决策。 2、识别干系人 识别干系人是识别所有受项目影响的人或组织，并记录其利益、参与情况和影响项目成功的过程。 二、规划过程组 3、制定项目管理计划 制定项目管理计划是对定义、编制、整合和协调所有子计划所必需的行动进行记录的过程。项目管理计划是关于如何对项目进行规划、执行、监控和收尾的主要信息来源。 4、收集需求 收集需求是为实现项目目标而定义并记录干系人的需求的过程。 5、定义范围 定义范围是制定项目和产品的详细描述的过程。 6、创建工作分解结构（WBS） 创建工作分解结构是把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程

项目整体管理就是为满足各方需求而进行协调以达到预期目的的过程。它是一项综合性、全局性的工作，主要内容是在相互冲突的目标或可选择的目标中权衡得失。虽然所有的项目管理过程在某种程度上都可看成是一个整体，但在整合管理中所描述的这些过程是最基本的管理知识。整合管理主要包括：项目计划开发、项目计划实施、项目综合变更控制这三个过程。这些过程彼此相互影响，同时与其它领域中的过程也互相影响。 　　 项目计划开发 　　在整合管理中，项目计划开发就是利用其它各领域的项目规划过程的输出，创建一个内容充实、结构紧凑的文件来指导项目的实施和控制。因此，项目计划开发过程所需要的主要的依据是其它项目规划过程的成果。在这里，项目规划过程主要包括：范围计划、范围界定、活动定义、进度安排、资源规划、成本预算、质量规划、管理规划、沟通规划等一系列规划过程。在这些过程中，最基本的文件是：工作分析结构和辅助说明。 　　在项目计划开发中还需要考虑组织的管理政策。所有项目相关组织可能都有正式或非正式的政策。这些政策是项目实施的规范和标准，必须被项目团队进行遵守和执行，因此在计划时必须考虑到它们的影响。例如：人事管理政策中的雇佣和解雇标准等。 　　同时，项目计划开发也需要参考项目的历史资料。项目的历史资料是进行项目规划的基础，它为项目规划提供了参考依据。 　　最后，在项目计划开发中还需要考虑项目的制约因素和假定条件

　随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。 　　网站项目管理（WPM）的含义为WebbasedProjectManagement，即以Web应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。 　　在本文中，笔者将网站项目管理（WPM）与软件工程的统一过程管理（RUP）进行参照比较，并结合实际工作经验，力求将网站工程管理（WPM）的角色、分工、流程进行完整的阐述，使网站项目管理逐渐走向规范化。 按照笔者的经验，网站项目管理可以分为以下七个阶段进行控制： 1.需求分析及变更管理 2.项目模型及业务流程分析 3.系统分析及软件建模 4.界面设计、交互设计及程序开发 5.系统测试和文档编写 6.客户培训、技术支持和售后服务 　　需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的