软件研发计划时间.doc

软件研发计划时间 1.1.目的编写项目开发计划，主要是为了项目能按照计划执行，并做为项目执行的监控标准，降低项目风险，提高项目管理质量，顺利的完成此项目。 1.2.项目简介1.2.1.项目名称1.2.2.产品标识1.3.范围1.4.缩略语与首字母缩写篇二如何估算软件项目开发时间用科学的方法估算项目实施所需时间引言前两天一个朋友给我打电话，问我如何估计项目开发时间。 对此我很诧异，问他以前他们是怎么估计的，他说以前基本都是大家开个会，大约都说说自己意见，最后负责人一拍脑袋，给出一个时间。 不过这次遇到一个非常认真的客户，要求不但要估计出项目开发时间，还要明确说明具体的依据和估算方法，这下我这朋友有点犯难，才询问我。 后来我翻阅了一些数理统计和项目估算方面的资料，告诉了他利用一元线性回归分析估计软件项目开发时间的方法。 想到这种估算需要在一些开发团队很常见，所以在这里成文。 问题的定义及数学模型这里我们仅考虑比较简单的一元回归问题，即通过单一的Proxy预测项目开发时间。 这里先说一下什么叫Proxy。 Proxy叫做代理变量，简单来说就是估计项目开发时间的数理依据。 说白了，就是我们预测开发时间，总要有个根据，例如需求中用例个数、概要设计中的实体个数、数据库中的表的数量等等。 设Proxy为x，项目开发时间为y，那么可以得到y=f(x)，学过初等数学的都可以看懂，就是说开发时间是Proxy的一个函数，如果我们既知道了新项目的x，又知道函数f，那么y就出来了。 可惜天下哪有这么好的事，我们现在既不知道f，又不知道x，别说x的值了，甚至我们都不知道该用哪个Proxy做x。 不过也不必悲观，经过上面分析，我们至少明确了我们奋斗的方向 1、找出候选的Proxy。 2、选择最合适的Proxy作为x。 3、得到x的值。 4、确定函数f。 5、得出y。 下面我们一步一步解决各个问题。 找出候选的Proxy虽然一个项目的特征量很多，不过可不是随便一个特征量都可以当做Proxy的。 要成为Proxy，至少要满足如下四个条件。 1）Proxy的值应该和工作量紧密相关。 这个不用多解释了吧，就是说Proxy的值和y的值要有相关性。 关于“相关性”的概念这里先定性说一下，定量分析后续会讲到。 2）Proxy应该是能明确得出值的，没有二义性。 这是说Proxy应该对应一个明确数值，是一就是一，是二就是二，不能取“不错”、“挺多”这种值。 3）Proxy应该在项目开始阶段可以得出或能较精确估计出。 这个开始阶段最晚不能晚于概要设计，因为估算都是一开始进行，所以Proxy一定要在起始阶段就能得出，否则项目结束了谁还搞估算，实际值都出来了。 4）Proxy对于不同的实施方案是敏感的。 就是说当开发方法、开发过程等因素变化时，Proxy应该具有一定的敏感性。 经过上述分析，我想选用什么作为Proxy大家心里都有点谱了。 一般来说，在估算时常被作为Proxy的有需求分析中用例数量、需求分析中功能模块数量、概要设计中实体数量和数据库设计中表的数量。 当然，各位也可以根据上述要求选择自己的Proxy。 在本文中，我们暂且选择用例数量、实体数量和表数量三个Proxy作为候选。 选择最合适的Proxy作为x这里所谓的“最合适”，在数学上的意义就是和开发时间y的相关性最强。 那么什么是相关性呢，从直观意义上，两个变量的相关性是指两个变量关联的紧密程度，数学上可以用相关系数表示。 相关系数计算公式如下至于这个公式为什么能反映出两个变量的相关性，可以去参考高等数理统计相关资料，本文不再赘述，只是顺便说一下，r的范围在-11之间，绝对值越大代表相关性越强，如果为正值则表示两个变量正相关，否则为负相关。 知道了这个，我们这一步骤的目的就是找出候选Proxy中与y相关系数最大的作为x。 不过，这数据从哪里来呢？这就要从以前做过的项目中提取了。 查阅朋友所在团队最近做过的5个项目的数据资料（这里当然历史项目越多越好，不过笔者这个朋友的团队只有5个项目的记录），得到如下数据项目工期（y）42426790331160（人时）用例数量（x1）372061812实体数量（x2）15941114数据表数量（x3）251871618下面就是计算各个相关系数了，计算相关系数是一项机械且乏味的活动，一般都会交由相应的工具去完成。 不过您要是感兴趣，也可以自己代入上述公式手算。 下图是我用Excel计算的结果图1一般来说，|r|大于0.7就有很好的相关性了，而从计算结果可以看出，用例数量x1和工期y的相关系数达到0.93，最为优秀，而数据表数量x3也达到0.83，唯有实体数量x2的相关系数仅为0.65，质量较差。 因为|r(x2,y)|0.7，所以这里首先排除掉。 到了这里似乎我们可以顺利成章选择x1作为最终Proxy，但是还有一点要考虑，就是显著性。 所谓显著性就是在偶然情况下得到此结果的概率，如果显著性不足，说明这个结果不可靠。 显著性t值的计算公式如下因为n=5，这里自由度为3，然后查询t分布表，得到95%预测区间为3.182。 因为一般显著性0.05则认为显著性较好，所以如果t的值大于3.182，我们则可以接受。 不过如果使用工具的话，一般可以用t检测直接得出显著性，这里我用Excel得到r(x1,y)的显著性为0.006，r(x3,y)的显著性为0.007（如图2所示），都远小于0.05，显著性均非常好。 所以根据择优录取原则，我们选择x1需求文档中用例数量作为预测Proxy。 图2得到x的值在上文中，我们通过相关性和显著性分析，最终决定使用需求文档中的用例数量作为x。 下面就是要确定x的值，这个不必多说，直接从需求文档中得到相应的数量即可。 确定相关函数f知道了x的值，下面就是要确定相关函数了。 这一步是最艰难也是最有技术性的，因为相关函数不但和数理因素相关，还与开发团队、团队中的人以及管理方法有关。 如果人员变动很大或管理方法做了很大的调整，历史数据可能就不具备参考价值了。 不过如果团队的开发水平和管理方法没有重大变动，这个函数还是相对稳定的。 在函数选型上，一般会选择线性函数，当然我个人对此是十分怀疑的，但是这里为了简单起见，我们姑且照例使用线性函数作为预测模型。 这样可以建立一元线性回归模型如下这个函数并不是简单的线性函数，而是包含了一个随机变量，这是一个服从正态分布的随机变量。 上述模型的直观意义可以如下描述a代表与x即用例数量无关的起始时间，b代表每一个用例所耗费的平均时间，而代表开发中的不确定性。 在不同的团队中或不同的管理方法下，a,b和都是不一样的，但是当团队和管理方法相对稳定，可以认为a,b和是可通过历史数据估计的。 而因为的期望为0，所以只要给出a和b的合理估计，就可以得到y的一个无偏估计。 下面我们估计a和b的值。 估计方法有很多，如曲线拟合法或最小二乘法。 这里我们采用最小二乘法进行估计。 最小二乘法估计的基本原理如下求极值可以使用微积分中的求极值方法，首先令Q(a,b)对a和b分别求偏导，并令偏导为零，得如下方程组经过一系列计算和推导，最终可得到:将以前的历史数据代入上述方程，就可以得到a和b的最小二乘估计。 同样，这种机械而乏味的计算一般交由工具去完成。 我用Excel得到a和b的估计分别为56.251和10.653。 Excel分析结果如图3所示图3根据估计结果，我们可以得出相关函数为y=56.251+10.653。 我们还可以证明，这个篇三软件项目沟通计划项目沟通计划项目沟通计划（Project CommunicationPlan）什么是项目沟通计划项目沟通计划是对于项目全过程的沟通工作，沟通方法、沟通渠道等各个方面的计划与安排。 就大多数项目而言，沟通计划的内容是作为项目初期阶段工作的一个部分。 同时，项目沟通计划还需要根据计划实施的结果进行定期检查，必要时还需要加以修订。 所以项目沟通计划管理工作是贯穿于项目全过程的一项工作，项目沟通计划是和项目组织计划紧密联系在一起的，因为项目的沟通直接受项目组织结构的影响。 项目沟通计划的内容项目沟通计划包括四个方面的具体工作，如下图所示 1、编制项目沟通计划前的准备工作1）收集信息项目沟通内容方面的信息；项目沟通所需沟通手段的信息；项目沟通的时间和频率方面的信息；项目信息与最终用户方面的信息。 2）所获信息的加工处理对收集到的沟通计划方面的信息进行加工和处理也是编制项目沟通计划的重要一环，而且只有经过加工处理过的信息，才能作为编制项目沟通计划的有效信息使用。 2、项目沟通需求的确定项目沟通需求的确定是在信息收集的基础上，对项目组织的信息需求做出的全面决策，其内容包括项目组织管理方面的信息需求；项目内部管理方面的信息需求；项目技术方面的信息需求；项目实施方面的信息需求；项目与公众关系的信息需求。 3、沟通方式与方法的确定在项目沟通中，不同信息的沟通需要采取不同的沟通方式和方法，因此在编制项目沟通计划过程中还必须明确各种信息需求的沟通方式和方法。 影响项目选择沟通方式方法的因素主要有以下几个方面沟通需求的紧迫程度；沟通方式方法的有效性；项目相关人员的能力和习惯；项目本身的规模。 4、项目沟通计划的编制项目沟通计划的编制是要根据收集的信息，先确定出项目沟通要实现的目标，然后是根据项目沟通目标和确定项目沟通需求去分解得到项目沟通的任务，进一步根据项目沟通的时间要求去安排这些项目沟通任务，并确定出保障项目沟通计划实施的资源和预算。 项目沟通计划书的内容除了前面给出的目标、任务、时间要求、具体责任、预算与资源保障以外，一般还应该包括下列特殊内容信息的收集和归档格式要求；信息发布格式与权限的要求；对所发布信息的描述；更新和修订项目沟通管理计划的方法；约束条件与假设前提。 项目沟通计划主要包括以下儿个方而的内容。 (1)描述信息收集和文件归档的结构，这一结构用于收集和保存不同类型的信息。 举例来说，一个项目组的成员出席了一个会议并带回一些有价值的信息和资料，它将如何归档和保存在哪里?如果一个供应商送来了一本新产品样本，它将如何归档和保存在哪里?如果同一供应商儿个月后又送来了一本新产品样本，如何处理这本新样本与旧样本?如果在项目中不同的成员负责访谈不同的部门，他们的访谈结果和发现会影响到其他成员下一步的研究，那么这些访谈信息应如何处理和在成员之间共享?对于这样的信息资料如果缺乏及时清晰的和保存，就会造成信息的缺失和部门间或成员间信息的不一致，所以，有必要制定和遵循一个制度，将与项目有关的重要信息资料和文件进行建档管理。 (2)项目干系人联系方式。 应该有一个专用于项目所有相关人员联系方式的小册子，包括项目组成员、项目组上级领导、行政部人员、技术支持人员、出差订房、订票等系统中相关的人员，座机号码、手机号码、职能等等，应一一列上，做到简洁明了，最好能有特殊人员的一些具体的标注，能够做到在一打开小册子的同时就能将所有的相关人员的资料了然于胸，正所谓知己知彼，这样一来，很多在平时大费周章的事，就能在养成的良好的习惯中，轻松应对。 (3)传送重要项目信息的格式。 项目组的成员在准备书而的和口头的状态报告时，是否存在可以遵循的格式?是否所有的缩写词和定义都有一个列表?在不同的项目文件中它们需不需要被重复列出?建立一个项目本身统一的文件模板，是正规管理的一部分，所以必须统一各种文件模板，并提供报告编写指南。 (4)用于创建信息的日程表。 是否已经分配资源去创建、聚集和发送关键项目信息?项目干系人是否知道什么时候期望提交不同的信息?什么时候他们需要参加重要的会议?时间安排是否考虑到了关键项目文件的审评和批准?保证时间以建立关键项目信息和确保其质量是很重要的。 (5)获得信息的访问方法。 谁能看到一个草拟的文件?每个人都能访问所有的项目文件吗?哪些信息在线保存以及哪些只保存在硬拷贝中或以其他形式保存?每个人都能检查硬拷贝中的文件吗? (6)工作汇报方式。 明确表达项目组成员对项目经理或项目经理对上级和相关人员的工作汇报方式，明确什么时间，什么形式。 比如项目组成员对项目经理通过E-mail发送周报;项目经理对直接客户和上级按月通过E-mail发送