如何建立软件开发项目里程碑
展开全部 建立项目里程碑 当我们在路上行走的时候,会在沿途观看路标,当到达某一个心目中的路标时,我们便知道还有多少路或多少时间才能够到达终点。
这些路标是我们在旅程中的里程碑,让我们可以清楚地知道目前所在,离开目的地有多远,让我们能估算何时才能够到达目的地。
让我们利用硬件供应商或渠道商的供应里程碑来作一个简单的说明,硬件装钳完成后或收到厂家运到的产品时便是一个里程,把商品送到客户办公室让客户签收后便是另一个里程,安装测试后让客户验收便成为最后一个里程。
完成这三个里程后便知道项目已经完结。
软件开发的里程碑 软件开发服务的企业,往往在签订协议时收取一笔定金,然后需要支付数月所需的开发组员薪资,而且软件开发服务商往往未能在指定时间内完成开发的项目,各种原因导致项目延误,那么便需要企业应用本身的流动资金来应付。
如何才算是一个里程碑呢?简单的说是到达一个阶段可以让客户看到部分结果的地方。
就以软件开发为例(如左图),要开发一套软件,我们需要经过一定的流程或阶段。
分别为信息搜集、需求分析、系统设计、系统开发、系统测试。
但只有四个阶段产生交付物,分别在信息搜集阶段后将产生一份《需求说明书》、在需求分析后产生一份《功能说明书》、在系统设计阶段后产生《系统逻辑说明》及《 DFD ( Data Flow Diagram )图》、和在系统测试阶段后产生《测试报告》。
每一份交付物的完结说明我们已经完成了一个阶段的工作,在客户确认这一份工作成果后我们才进入下一个阶段的工作。
每一份交付物将是整个系统开发过程中的『里程碑』。
所以里程碑的建立必需连带交付物,而这交付物必需让客户确认。
当客户确认我们的交付物后,也是客户确认我们已经在系统开发的过程中到达某一个指定的阶段,完成某一部分的工作。
确认里程碑的交付物 当我最初执行项目管理的时候,往往把交付物送交客户确认后,两三各星期下来都没有回应,不断跟进也没有多大的进展,相信很多从业人员往往会说『客户需要太长的时间来进行确认,将影响项目的进度』。
又或者会说『客户不会确认过程中的任何交付物,因为。
。
。
。
(很多理由和原因)。
。
。
』!这便是一个项目经理的经验问题,而不是客户会不会、或者愿意不愿意确认的问题。
当我们进行项目启动集会的时候,项目经理便应该跟项目赞助人很明确地说明确认项目过程中所产生的交付物的重要性,同时更应该清楚地说明交付物在没有确认前将不能够开展下一阶段的工作,在没有得到客户确认一个阶段的交付物时,继续开展下一阶段的工作对项目会带来莫大的风险,因为任何的工作都可能被客户推翻,可能变成废物,或需要不断进行修改。
这不但浪费组员的时间及士气,更严重地延误项目的进度,延误项目的最终交付,导致项目的超时、超支。
明确的沟通 在启动集会中我们更应该透明化。
应该很详细地让项目赞助人及其他参与集会的项目涉及人清楚地理解项目的整个流程和进度时间计划。
让他们对项目的运作有初步的认识和了解,好能跟项目小组互相配合。
同时更需要采用各种不同的软技巧(参阅项目管理技巧新探)来让客户依时确认交付物,让我们能够进入下一阶段。
当客户确认我们所提交的交付物后,便是客户同意我们已经完成了某一个阶段的工作,如果我们在合约谈判的时候把服务收费时间按项目交付物来让客户支付,那么我们不但能够有助企业的资金流动,更不用为收费的事情因项目的延误跟客户发生争执。
故此在项目建立的初步阶段,我们便应该建立有关项目的里程碑和工作架构分解。
让我们能更有效的管理项目的进度。
软件项目计划的计划制定
展开全部项目计划详细说明了所需软件工作及如何实现。
它定义了每一个主要任务,并估算其所需时间和资源,同时为管理层的评估和控制提供了一个框架。
项目计划也提供了一种很有效的学习途径。
如果能合理建档,它便是一个与实际运行效能比较的基准。
这种比较可以使计划者看到他们的估算误差,从而提高其估算精确度。
我们着重强调对项目规模和资源的估算,是因为低质量的项目资源估算将不可避免地造成资源短缺,进度延迟和预算超支。
又由于项目资源估算是从软件规模估算中直接衍生出来的,所以低质量的规模估算是造成许多软件项目问题的根本原因。
项目计划应在项目开始初期制定出,并随着工程的进展不断地加以精化。
起初,由于软件需求通常是模糊而又不完整的,我们的工作重点应在于明确该项目需要哪些领域的知识,并且如何获取这些知识。
如果不遵循这一指导原则,程序员们通常会积极地投入到那部分已知的工作中去,而把未知部分留滞到以后。
这种工作方式通常会产生很多问题,因为未知部分具有最高的风险系数。
软件项目计划的逻辑如下所述 :由于软件需求在初始阶段是模糊而又不完整的,质量计划只能建立在对客户需求的大致而不确切的理解之上。
因此,项目计划应该从找出含糊不确切与准确恰当的软件需求间的映射关系入手。
接着建立一种概念设计。
项目初始架构的建立要十分谨慎,因为它通常标定了产品模块的分割线,同时描述了这些模块所实现的功能及所有模块间的关系。
这就为项目计划和项目实施提供了组织框架,因此一个低质量的概念设计是不能满足要求的。
在每一次后续的需求精化时,也应同时精化资源映射,项目规模估算和工程进度。
软件项目计划-制订软件项目计划的方法与策略制订软件项目计划的目的在于建立并维护软件项目各项活动的计划,软件项目计划其实就是一个用来协调软件项目中其它所有计划,指导项目组对项目进行执行和监控的文件。
一个好的软件项目计划可为项目的成功实施打下坚实的基础。
软件项目有其特殊性,不确定因素多,工作量估计困难,项目初期难于制定一个科学、合理的项目计划。
我曾主持和参与过大大小小的软件项目十余项,下面我将把我制订软件项目计划的经验分享给大家。
1.注重项目计划的层次性软件项目计划的层次及其关系如下图所示。
高级计划,是项目的早期计划。
高级计划应当是粗粒度的,主要是进行项目的阶段划分,确定重大的里程碑,所需相关的资源,包括人力资源、设备资源、资金资源,即所谓的人、财、物三个要素。
大的阶段交替之前,应做好下一阶段的详细计划,我们称之为二级计划。
详细计划要确定各项任务的负责人,开始时间,结束时间,任务之间的依赖关系,设备资源,小的事件点(即里程碑)。
如果项目规模相对较大,可以有多级的计划,比如说,一个项目组可能分为几个开发组,二级计划是各开发组制订的适合的自己小组的计划。
如果开发组还分了小组,可以有小组的三级计划。
开发人员的个人计划是低级计划,由开发人员根据自己的任务自行制定,要把任务细化到人·日。
一般的,软件项目计划至多有四级就够了,过多的等级将会引发效率的瓶颈。
大的项目不见得要有庞大的组织和人员数量来支撑,合理的划分小组,减少组织的层次,有利于项目计划的制订和实施。
较小的软件项目由于工期不长,人员较少,有二级计划(高级计划与低级计划)也是可行的。
2.重视与客户的沟通与客户的沟通是很重要的。
不必害怕客户知道我们的开发计划,特别是项目进度情况,应当和客户共享这些信息。
首先,客户会提出一些对项目时间、进度、效果上的要求,这个指标往往经不起推敲,有的还带有较强的政策性。
如:在我主持的一个某单位人nnerlink>MIS系统的开发中就发现,客户方对时间上的约束是有成形的文件的,是他们单位领导们开会的决定。
客户给出的从项目启动到验收的时间只有三个月,但是,经过我们认真的需求调研,做出项目进度的粗计划和部分的二级计划后,发现三个月的时间是难于实现的。
我们把做出的调研文档和项目计划摆出来和和客户讨论,最终使项目的开发时间延长为六个月。
站在为了科学地分析和解决问题的立场上来看,项目组和客户的目的是一致的,所以对于合理的项目进度客户是会理解与支持的。
其次,我们有义务要让客户知道项目的计划。
这样才能让客户和用户主动、积极参与项目,达到项目的最终目标。
项目计划取得双方签字认可是一种好的习惯。
客户可能不愿意签正式的文件,那么在文档的封面上签上双方负责人的姓名、联系方式也行,虽然是非正式的,但留下了项目工作的痕迹。
有必要想办法让客户清楚签字意味着什么。
这就意味说双方有了一个约定,既让用户感觉心里踏实,也让自己的项目组有了责任感,有一种督促和促进的作用。
3.该详细的详细,该简略的就简略软件项目计划就如同软件项目本身一样有它特殊性,一个三五个人花两三个月就可以完工的小项目,可能项目计划就四五页纸,包括一个WBS(工作分解结构)和一个Gantee图(甘特图)。
一个需要五六十个人甚至上百人,要花上半年或更...
软件项目进度管理怎样计划项目发挥真正的作用,而不成为挂在墙上的...
1、任务分配、人力资源分配、时间分配要与工程进度相协调在小型软件开发项目中,一个程序员能够完成从需求分析、设计、编码,到测试的全部工作。
随着软件项目规模的扩大,人们无法容忍一个人花十年时间去完成一个需要十几个人年才能完成的软件项目。
大型软件的开发方式必然是程序员们的集体劳动。
由于软件开发是一项复杂的智力劳动,在软件开发过程中加入新的程序员往往会对项目产生不良影响。
因为新手要从了解这个系统和以前的工作做起,当前正在从事这项工作的“专家”不得不停下手中的工作,抽出时间对他们进行培训。
于是,在一段时间内,工作进度便拖后了。
软件开发人数的增加将导致信息交流路径和复杂性的增加,项目进行中盲目增加人员可能造成事倍功半的效果。
适用于大型项目的Rayleigh-Norden曲线[4]表明,完成软件项目的成本与时间的关系不是线性的,使用较少的人员,在可能的情况下,相对延长一些工作时间可以取得较大的经济效益。
然而值得指出的是,程序员小组的正常技术交流能改进软件质量,提高软件的可维护性,减少软件错误,降低软件测试和正确性维护的开销。
任务、人力、时间三者之间存在最佳组合,必须引起项目负责人的足够重视。
2、任务分解与并行化软件工程项目既然需要软件开发人员集体的劳动,就需要采取一定的组织形式,将软件开发人员组织起来。
软件人员的组织与分工是与软件项目的任务分解分不开的。
为了缩短工程进度,充分发挥软件开发人员的潜力,软件项目的任务分解应尽力挖掘并行成分,以便软件施工时采用并行处理方式。
3、工作量分布 用前几节介绍的软件估算技术可以估算出软件开发各个阶段所需要的工作量,通常用人月或人年表示。
软件在需求分析和设计阶段占用的工作量达到总工作量的40%~50%,说明软件开发前期的活动多么重要。
当然这也包括分阶段开发原型的开销。
大家熟悉的编码工作只占全部工作量的10%~20%,而软件测试和调试的工作量占到总工作量的30%~40%。
这对于保证软件产品质量是十分必要的,实时嵌入式系统软件的测试和调试工作量所占的比例还要大些。
4、工程进度安排 软件项目的工作安排与其他工程项目的进度安排十分相似,通常的项目进度安排方法和工具稍加改造就可以用于软件项目的进度安排。
目前,程序评估与审查技术(PERT)和关键路径方法(CPM)是两种比较常用的项目进度安排方法。
两种方法都生成描述项目进展状态的任务网络图。
网络图中按一定的次序列出所有的子任务和任务进展的里程碑,它表示各子任务之间的依赖关系。
网络图也是作业分解结构(WBS)的发展。
20世纪70年代,作业分解结构就已广泛应用于航天、航空、航海、雷达、通信、火控系统等领域的基于计算机项目的分解,并用以命名各项子任务,这些子任务不仅可以用网络图的形式表示,还可以用树型或层次结构图表示。
PERT和CPM方法为软件规划人员提供了定量描述工具,包括:①关键路径。
完成关键路径上所有任务时间的总和,就是项目开发所需要的最短时间。
②用统计模型估算开发每个子任务需要的工作量和时间。
③计算各子任务的最早启动时间和最迟启动时间,即确定启动子任务的时间窗口边界。
某个子任务的最早启动时间被定义为该子任务的所有前导任务完成的最早时间。
反之,某个子任务的最迟启动时间被定义为在保证项目按时完成的前提下,最迟启动该子任务的时间。
与最早启动时间和最迟启动时间对应的概念是最早结束时间和最迟结束时间。
它们分别是最早启动时间和最迟启动时间与完成该子任务所需要时间的和:在任务进度安排过程中,应先寻求关键路径并在关键路径上安排一定的机动时间和节假日,以便应付意想不到的困难和问题。
采用这些工具可以大大减轻软件项目管理人员在制定软件项目进度表方面的工作量,并可提高工作质量。
华为项目管理模式?
第一章:项目与项目管理1、什么是项目?◆项目定义 ◆项目管理定义 ◆项目管理的特点 ◆项目管理常见问题分析2、什么是项目管理?◆项目管理的9大内容 ◆项目管理的5大过程 ◆参考模板:《项目管理手册》第二章:项目启动阶段工具与模板1、立项申请 ◆制定项目章程 ◆制定项目初步范围说明书 ◆任命项目经理——给项目经理授权 ◆项目启动会议2、组建项目团队 ◆项目组织结构:职能式组织结构、项目式组织结构、矩阵式组织结构、强矩阵组织结构、弱矩阵组织结构、混合矩阵组织结构 ◆项目经理的职责:项目经理的能力要求、项目经理的主要工作职责 ◆项目组成员的职责3、策划和制作任务书 ◆项目描述 ◆项目里程碑 ◆项目评价标准 ◆项目干系人4、项目启动会 ◆项目目标 ◆项目管理方式 ◆项目工作方式 ◆华为项目启动工具与模板运用:◆项目组成员(模板) ◆项目任务书(模板) ◆产品开发任务书(模板) ◆案例分析与练习:第三章:项目计划阶段工具与模板1、工作分解结构(WBS) ◆项目工作分解 ◆WBS分解的误区 ◆WBS分解的几种不同方法2、项目责任矩阵3、活动排序4、项目资源、工期、成本核算5、项目进度计划 ◆甘特图 ◆关键路径法6、项目风险管理计划 ◆风险管理的重要性 ◆识别项目风险:头脑风暴法、检查表法、专家判断法、SWOT分析法 ◆项目风险评估 ◆项目风险应对 ◆项目风险管理计划 ◆风险影响周期 ◆案例研讨:制定项目管理计划7、项目沟通管理计划 ◆沟通管理的重要性 ◆项目沟通的要求:项目沟通矩阵图、项目经理沟通矩阵图、项目组通讯方式 ◆沟通中的过滤与障碍 ◆产生沟通障碍的原因 ◆项目启动会议 ◆沟通管理计划 ◆有效沟通的方式 ◆项目经理在沟通中的作用 ◆项目团队成员之间的沟通 ◆案例研讨:制定项目沟通计划 ◆华为项目管理模板参考 ◆WBS(模板) ◆进度计划表(模板) ◆风险管理表(模板) ◆沟通计划表(模板) ◆PERT图的绘制(模板) ◆战争地图 第四章:项目实施与监控阶段工具与模板1、项目沟通管理2、项目监控方法与工具 ◆应用进度计划表 ◆召集会议 ◆观察与检查 ◆项目跟踪计划 ◆定期反馈与报告3、项目变更管理 ◆案例研讨:制定项目的进度图 ◆华为项目监控模板与项目管理制度:◆项目会议纪要(模板) ◆项目状态报告(模板) ◆项目变更管理表(模板) ◆项目管理制度 ◆鱼骨图 ◆对策表 ◆PDCA循环 第五章:项目收尾阶段工具与模板1、评估与验收2、项目总结 ◆项目总结会议 ◆项目总结表(模板)3、文件归档 ◆工具:项目总结相关表格 ◆项目总结表(模板) 第六章:研发项目的考核与激励1、项目团队的绩效管理2、项目经理及组员的PBC3、项目的考核要素4、研发团队的激励 ◆案例研讨:如何考核和激励研讨人员 ◆工具与模板:◆项目团队PKI(模板) ◆研发个人PBC(模板) 第七章:项目成功的关键要素1、业界项目成功的关键因素2、业界项目失败的关键因素3、成功项目管理各阶段重要关键点 ◆案例研讨:项目成功的关键点有哪些?第八章:项目管理软件Project2007实战演练 要求每人配备笔记本电脑,并预装Project2007软件 第九章:总结和答疑 具体模板和工具为表格,可发邮件至activechan@163.com索取
软件项目进度表包含什么内容
一是参考其它项目.另一个现在的可参考项目是安装 Microsoft Office Project 2003, 内有好几个相关模板.供参:项目启动 6 工作日 组建工作组 6 工作日 定义工作组角色 2 工作日 确定所需技能 2 工作日 确定资源 2 工作日 将角色赋予资源 2 工作日 工作组成立 0 工作日 构想 44 工作日 定义初步的商业需求(持续性工作) 29 工作日 风险管理 1 工作日 定义项目结构 9 工作日 定义跟踪项目的步骤 5 工作日 定义解决问题的步骤 4 工作日 定义跟踪问题的步骤 3 工作日 定义控制变更的步骤 4 工作日 定义责任和期望 2 工作日 项目结构确定完毕 0 工作日 研究和收集设想 25 工作日 进行初步的用户访问 2 工作日 定义使用场合 10 工作日 制定初步的用户描述 5 工作日 制定初步的构想说明 1 工作日 确立设计目标 8 工作日 制定初步的解决方案概念 5 工作日 制定初步的项目范围 19 工作日 定义关键的成功因素 2 工作日 定义衡量成功的标准 1 工作日 定义主要的可交付结果(初步) 3 工作日 起草构想/范围 3 工作日 审阅构想/范围 2 工作日 更新构想/范围 3 工作日 缓冲时间 4 工作日 进行里程碑检查 1 工作日 构想得到批准 0 工作日 规划 59 工作日 更新风险评估 1 工作日 进行用户访问 10 工作日 创建功能描述 31 工作日 制定功能描述: 第 0 批 5 工作日 制定功能描述: 第 1 批 5 工作日 制定功能描述: 第 2 批 5 工作日 制定功能描述: 第 n 批 5 工作日 功能描述基准 0 工作日 开发计划 28.25 工作日 创建开发计划 28 工作日 进行概念性设计 10 工作日 进行逻辑设计 15 工作日 进行物理设计 19 工作日 制定开发日程 5 工作日 测试计划 35 工作日 制定测试计划 30 工作日 制定测试日程 5 工作日 用户培训计划 36 工作日 制定用户培训计划 30 工作日 制定用户培训日程 6 工作日 后勤计划 48 工作日 制定后勤计划 43 工作日 进行基础设施分析 15 工作日 制定安全计划 2 工作日 制定部署计划 27 工作日 定购组件 15 工作日 后勤计划完成 0 工作日 创建后勤日程 7 工作日 产品管理计划 18 工作日 制定产品管理计划 14 工作日 制定产品管理日程 5 工作日 程序管理计划 41 工作日 创建程序管理计划 21 工作日 创建程序管理日程 20 工作日 建立项目计划基准 0 工作日 合并项目计划 11 工作日 审阅合并计划 4 工作日 创建合并日程 2 工作日 缓冲时间 4 工作日 确定交货日期 0 工作日 构想/范围冻结 0 工作日 进行里程碑检查 1 工作日 项目计划得到批准 0 工作日 开发 81 工作日 更新风险评估 1 工作日 提供开发所需的设备/检验概念是否达到 0 工作日 建立开发环境/实验室 5 工作日 内部发布 #1 24 工作日 开发目标组件 9 工作日 测试单个组件 5 工作日 测试组装为整体的应用程序 6 工作日 开发增强性能的材料 4 工作日 测试和审查材料 3 工作日 制定分发步骤 9 工作日 创建分发产品 2 工作日 分发给合适的对象 1 工作日 缓冲时间 8 工作日 内部发布 #1 结束 0 工作日 审阅来自内部发布的结果 2 工作日 进行发布后的审阅 1 工作日 内部发布 #n 24 工作日 开发目标组件 10 工作日 测试单个组件 4 工作日 测试组装为整体的应用程序 5 工作日 开发增强性能的材料 4 工作日 测试和审查材料 3 工作日 制定分发步骤 3 工作日 创建分发产品 4 工作日 缓冲时间 6 工作日 分发给合适的对象 1 工作日 内部发布 #n 结束 1 工作日 审阅来自内部发布的结果 2 工作日 功能说明冻结 1 工作日 最后的特性开发 10 工作日 最后的后勤开发 9 工作日 最后的性能支持开发 5 工作日 特性开发结束 0 工作日 更新计划和日程 13 工作日 更新开发计划 4 工作日 更新测试计划 3 工作日 更新后勤计划 13 工作日 更新程序管理计划 3 工作日 更新产品管理计划 3 工作日 更新用户培训计划 6 工作日 缓冲时间 3 工作日 进行里程碑检查 2 工作日 项目范围规划完成 1 工作日 稳定 73 工作日 更新风险评估 1 工作日 发布测试版 1 32 工作日 制定测试版计划 3 工作日 征寻和选择用户 2 工作日 准备测试版产品包 8 工作日 开始测试 0 工作日 提供测试支持 8 工作日 收集用户反馈 7 工作日 结束测试支持 0 工作日 修补缺陷 10 工作日 结束测试 0 工作日 发布测试版 n 1 工作日 修补缺陷 10 工作日 收集错误 1 工作日 改正高优先级的错误 10 工作日 发布无错误版 0 工作日 进行最后的错误分类 5 工作日 发布版候选 1 7 工作日 进行工作组评估 2 工作日 客户/用户评估 2 工作日 支持评估 3 工作日 发布版候选 n 6 工作日 黄金发布版 0 工作日 发布 1 工作日 项目后检查 2 工作日 软件开发:------------------------- 项目范围规划 3.5 工作日 确定项目范围 4 工时 获得项目所需资金 1 工作日 定义预备资源 1 工作日 获得核心资源 1 工作日 项目范围规划完成 0 工作日 分析/软件需求 14 工作日 行为需求分析 5 工作日 起草初步的软件规范 3 工作日 制定初步预算 2 工作日 工作组共同审阅软件规范/预算 4 工时 根据反馈修改软件规范 1 工作日 确定交付期限 1 工作日 获得开展后续工作的批准(概念、期限和预算) 4 工时 获得所需资源 1 工作日 分析工作完成 0 工作日 设计 14.5 工作日 审阅初步的软件规范 2 工作日 制定功能规范 5 工作日 根据功能规范开发原型 4 工作日 审阅功能规范 2 工作日 根据反馈修改功能规范 1 工作日 获得开展...
施工网络计划图采用什么软件编制
1.EXCEL施工进度计划自动生成表格:编写较方便,适用于比较简单的工程项目。
2.PKPM网络计划、项目管理软件: 1)可完成网络进度计划、资源需求计划的编制及进度、成本的动态跟踪、对比分析 2)可读取概预算数据,自动生成带有工程量和资源分配的施工工序,自动计算关键线路提供了多种优化、流水作业方案及里程碑及前锋线功能 3)自动实现横道图、单代号图、双代号图转换等功能。
4)编码过滤 5)实现计划、合同、实际时间的比较分析; 6)可以导入P3数据及Ms Project数据 3.Primavera Project Planner(P3) 在国内外为数众多的大型项目管理软件当中,美国Primavera公司开发的Primavera Project Planner (P3)普及程度和占有率是最高的。
国内的大型和特大型建设工程项目几乎都采用了P3。
目前国内广泛使用的P3进度计划管理软件主要是指:项目级的P3。
P3是用于项目进度计划、动态控制、资源管理和费用控制的综合进度计划管理软件,也是目前国内大型项目中应用最多的进度计划管理软件。
(1)软件的特点。
1)拥有较为完善的管理复杂、大型建设工程项目的手段。
2)拥有完善的编码体系,包括WBS(工作分解结构)编码、作业代码编码、作业分类码编码、资源编码和费用科目编码等。
3)这些编码以及这些编码所带来的分析、管理手段给项目管理人员的管理以充分的回旋余地,项目管理人员可以从多个角度对工程进行有效管理。
(2)软件的功能。
1)同时管理多个工程,通过各种视图、表格和其他分析、展示工具,帮助项目管理人员有效控制大型、复杂项目。
2)可以通过开放数据库互联(Open Data Base Connectivity简写ODBC)与其他系统结合进行相关数据的采集、数据存储和风险分析。
3)P3提供了上百种标准的报告,同时还内置报告生成器,可以生成各种自定义的图形和表格报告。
但其在大型工程层次划分上的不足和相对薄弱的工程(特别是对于大型建设工程项目)汇总功能将其应用限制在了一个比较小的范围内。
4)某些代码长度上的限制妨碍了该软件与项目其他系统的直接对接,后台的Btrieve数据库的性能也明显影响剜软件的响应速度和与项目信息管理系统集成的便利性,给用户的使用带来了一些不方便。
这些问题在其后期的P3e中得到了一定程度的解决。
4.Microsoft Office Project Microsoft Project是Microsoft公司开发的项目管理系统,它是应用最普遍的项目管理软件之一,Project4.0、Project98、Project已经在我国获得了广泛的应用。
借助Project和其他辅助工具,可以满足一般要求不是很高的项目管理的需求;但如果项目比较复杂,或对项目管理的要求很高,那么该软件可能很难让人满意,这主要是该软件在处理复杂项目的管理方面还存在一些不足的地方。
例如,资源层次划分上的不足,费用管理方面的功能太弱等。
但就其市场定位和低廉的价格来说,Project是一款不错的项目管理软件。
(1)软件的特点。
1)充足的任务节点处理数量。
可以处理的任务节点数量多少是一个工程项目管理软件能否胜任大型复杂工程项目管理的最基本的条件。
该系统可以处理的任务节点数已经超过100万个,可以处理的资源数也已经超过100万个,实际上只取决于计算机系统的资源情况。
2)强大的群体项目处理能力。
一个大型项目要划分成若干个子项目,以及子子项目。
为了实现分级管理,通常按工作分解结构进行分解或是从顶上向下分解,先粗后细进行设计;或是从底向上,先制定各子项目计划,再逐级向上集成,最后形成整个大系统。
无论采用哪种方式,都要求工程项目管理软件具有同时处理多个项目的能力。
3)Project 同时处理群体项目的数量已经达到1000多个。
这样高的技术指标已经能够满足大型复杂工程项目管理的需求。
如何把子项目组成主项目,这也是能否有效地管理大型项目的要素之一。
Project提供了比较完善的解决方案。
4)突出的易学易用性,完备的帮助文档。
Project是迄今为止易用性最好的项目管理软件之一,其操作界面和操作风格与大多数人平时使用的Microsoftoff波软件中的Word、Excel完全一致。
对中国用户来说,该软件有很大吸引力的一个重要原因是在所有引进的国外项目管理软件当中,只有该软件实现了“从内到外”的“完全”汉化,包括帮助文档的整体汉化。
5)强大的扩展能力,与其他相关产品的融合能力。
作为Microsoft Office的一员,Project也内置了VisualB asic for.application(VBA),VBA是Microsoft开发的交互式应用程序宏语言,用户可以剩用vBA作为工具进行二次开发,一方面可以帮助用户实现日常工作的自动化;另一方面还可以开发该软件所没有提供的功能。
此外,用户可以依靠Microsoft Project 与Office家族其他软件的紧密联系,将项目数据输出到wofd中生成项目报告,输出到Excel中生成电子表格文件或图形,输出到Power Point中生成项目演示文件,还可以将Microsoft Project 的项目文件直接存储为Aeeem数据库文件,实现与项目管理信息系统的直接对接。
(2)软件的功能。
1)进度计划管理。
Project为项目的进度计划管理提供了完备的工具,用户可以根据自己的习惯和项目的具体要求采用“自上而...
IT项目质量管理的计划工具
在项目进度被延滞或质量保证小组认为某阶段开发质量有问题时,提请项目经理、项目负责人等必要的相关人员举行质量会议。
解决当前存在的和潜在的问题。
质量保证是建立在文档的复审基础之上,因而文档版本的控制,特别是软件配置管理,直接影响软件质量保证的影响力和力度。
质量保证小组的检测范围包括:系统分析人员是否正确的反映了用户的需求;软件执行体是否正确的实现了分析人员的设计思想;测试人员是否进行了较为彻底的和全面的测试;配置管理员是否对文档的规范化进行的比较彻底,版本控制是否有效。
3.2 质量管理实施有了良好的资源配备,又如何在项目全生命周期内实施质量保证,让我们从以下几个方面来看质量保证的实施过程:3.2.1 项目进度的质量保证项目进度是项目进行是否顺利的最直观表现。
显然在项目开始之前,项目开发计划是必须的。
如果项目开发计划的制定的是完全合理的,那项目进度也就真正表达了项目与最终的交付使用之间的距离,然而要制定完全合理的项目开发计划几乎不太可能。
可见要保证项目进度,首先要保证项目开发计划尽可能合理。
项目计划的合理程度与项目计划制定者从事类似规模和类似业务的项目的经验有直接关系,通过经验往往能够预见潜在的阻碍,这样要求项目计划制定者需要集众人之力来完善计划。
当项目计划制定初期,由质量保证小组组织召开的项目计划评审会,邀请公司技术专家、用户以及项目组小组成员一起讨论项目计划的可行性,会议通常采用头脑风暴法,各抒己见,会后由指定的记录员形成质量记录,发送给相关人员,对其计划中不合理的地方进行修改完善,并由质量保证人员对其结果跟踪,以确保项目计划完整性、可行性,完善后的计划交由配置管理人员进行版本控制。
然而在计划实施过程中,计划不是“固定化”。
常有人道,“计划赶不上变化”,但“要跟上变化”。
项目计划以里程碑为界限,将整个开发周期划分为若干阶段。
根据里程碑的完成情况,适当的调整每一个较小的阶段的任务量和完成的任务时间,这种方式非常有利于整个项目计划的动态调整。
也利于项目质量保证的实施。
实际运作中,当质保小组发现计划实施的差异后,报告项目经理,由项目经理组织负责对计划进行周期性维护,对于已经变动的计划由质保小组协助配置管理小组完成版本控制。
项目开发各阶段的质量保证a、需求分析需求分析是开发人员对系统需要做什么和如何做的定义过程。
从系统分析的经验来看,这个过程往往是个循序渐进的过程,一次性对系统形成完整的认识是困难的。
只有不断地和客户领域专家进行交流确认,方能逐步明了用户的需求。
从系统开发的过程得知,系统分析时犯下的错误,会在接下来的阶段被成倍的放大,越是在开发的后期,纠正分析时犯下的错误所花费的代价越是昂贵,也越发影响系统的工期和系统的质量。
解决系统分析错误的方法。
TAJ Technologies公司通常采用邀请用户参与进行需求评定,然后对其用户的意见由质保成员跟踪检测是否纳入需求规格说明书,同时与用户签字确认形成需求基线,交由配置管理员放入配置管理库。
虽然尽早的邀请用户参与,仍然避免不了项目进行中用户的需求变更请求。
对于开发过程存在的需求变动,我们要求用户填写变更申请单发送给项目配置管理员,在通过配置配置员转交质保小组,负责组织专家小组和项目组成员一起讨论实施变更的可行性及实施后所带来的影响,小的变更则直接记录入变更记录原因分析项和风险项栏,大的变更则需要形成正式的变更报告,无论那种变更都需要对相应的文档实施同步变更(包括需求规格说明书、详细设计文、安装手册、操作手册等)。
但是对于无法实现或是变更会带来巨大的影响而将导致进度的延期,这时,我们将变更报告提交给用户或邀请用户进行协调会议,讨论变更取舍问题或是项目进度变更问题。
作者:麦秸杆儿2006-5-29 16:51 回复此发言6 软件项目质量管理经验谈决定变更之后,由项目经理组织实施变更,测试人员检测变更结果,而质保小组成员监督变更实施过程并协助配置管理员对变更后的成果物进行版本控制。
变更实施完后,上线前还需要指定人员协助用户一同测试并由用户签字后同意方可上线。
b、系统设计优良的体系结构应当具备可扩展性和可配置性,而好的体系结构则需要好的设计方法,自然设计选型成为了系统设计首要的工作,究竟是采用哪种设计方法好呢?对于设计选型不能一概而论,需要针对项目的结构、项目的特征和用户的需求来分析,同样也要考虑到参与项目小组成员的素质,如果其中大部分都没有从事过面向对象的设计且项目进对紧迫,这样没有多余的时间来培训小组成员来掌握面向对象的设计方法,尽管众所周知面向对象设计方法的优势,我们还是不如采用面向过程的方式(除用户指定开发设计方式外)可以减少项目承担的技术风险。
TAJ Technologies公司有过一个项目,用户指定需要采用面向对象分析、设计和开发,且开发周期短,在无赖的情况下,项目小组只能选用面向对象的软件开发过程,由于项目小组很少从事过面向对象的开发,经验缺乏...
项目时间管理的简介
“按时、保质地完成项目”大概是每一位项目经理最希望做到的。
但工期托延的情况却时常发生。
因而合理地安排项目时间是项目管理中一项关键内容,它的目的是保证按时完成项目、合理分配资源、发挥最佳工作效率。
它的主要工作包括定义项目活动、任务、活动排序、每项活动的合理工期估算、制定项目完整的进度计划、资源共享分配、监控项目进度等内容。
时间管理工作开始以前应该先完成项目管理工作中的范围管理部分。
如果只图节省时间,把这些前期工作省略,后面的工作必然会走弯路,反而会耽误时间。
项目一开始首先要有明确项目目标、可交付产品的范围定义文档和项目的工作分解结构(WBS)。
由于一些是明显的、项目所必须的工作,而另一些则具有一定的隐蔽性,所以要以经验为基础,列出完整的完成项目所必需的工作,同时要有专家审定过程,以此为基础才能制定出可行的项目时间计划,进行合理的时间管理。
在产品描述、活动清单的基础上,要找出项目活动之间的依赖关系和特殊领域的依赖关系、工作顺序。
在这里,既要考虑团队内部希望的特殊顺序和优先逻辑关系,也要考虑内部与外部、外部与外部的各种依赖关系以及为完成项目所要做的一些相关工作,例如在最终的硬件环境中进行软件测试等工作。
设立项目里程碑是排序工作中很重要的一部分。
里程碑是项目中关键的事件及关键的目标时间,是项目成功的重要因素。
里程碑事件是确保完成项目需求的活动序列中不可或缺的一部分。
比如在开发项目中可以将需求的最终确认、产品移交等关键任务作为项目的里程碑。
在进行项目活动关系的定义时一般采用优先图示法、箭线图示法、条件图示法、网络模板这4种方法,最终形成一套项目网络图。
其中比较常用的方法是优先图示法,也称为单代号网络图法。
项目工期估算是根据项目范围、资源状况计划列出项目活动所需要的工期。
估算的工期应该现实、有效并能保证质量。
所以在估算工期时要充分考虑活动清单、合理的资源需求、人员的能力因素以及环境因素对项目工期的影响。
在对每项活动的工期估算中应充分考虑风险因素对工期的影响。
项目工期估算完成后,可以得到量化的工期估算数据,将其文档化,同时完善并更新活动清单。
一般说来,工期估算可采取以下几种方式:1)专家评审形式。
由有经验、有能力的人员进行分析和评估。
2)模拟估算。
使用以前类似的活动作为未来活动工期的估算基础,计算评估工期。
3)定量型的基础工期。
当产品可以用定量标准计算工期时,则采用计量单位为基础数据整体估算。
4)保留时间。
工期估算中预留一定比例作为冗余时间以应付项目风险。
随着项目进展,冗余时间可以逐步减少。
项目的进度计划意味着明确定义项目活动的开始和结束日期,这是一个反复确认的过程。
进度表的确定应根据项目网络图、估算的活动工期、资源需求、资源共享情况、项目执行的工作日历、进度限制、最早和最晚时间、风险管理计划、活动特征等统一考虑。
进度限制即根据活动排序考虑如何定义活动之间的进度关系。
一般有两种形式:一种是加强日期形式,以活动之间前后关系限制活动的进度,如一项活动不早于某活动的开始或不晚于某活动的结束;另一种是关键事件或主要里程碑形式,以定义为里程碑的事件作为要求的时间进度的决定性因素,制定相应时间计划。
在制定项目进度表时,先以数学分析的方法计算每个活动最早开始和结束时间与最迟开始和结束日期得出时间进度网络图,再通过资源因素、活动时间和可冗余因素调整活动时间,最终形成最佳活动进度表。
关键路径法(CPM)是时间管理中很实用的一种方法,其工作原理是:为每个最小任务单位计算工期、定义最早开始和结束日期、最迟开始和结束日期、按照活动的关系形成顺序的网络逻辑图,找出必须的最长的路径,即为关键路径。
时间压缩是指针对关键路径进行优化,结合成本因素、资源因素、工作时间因素、活动的可行进度因素对整个计划进行调整,直到关键路径所用的时间不能再压缩为止,得到最佳时间进度计划。
目前项目管理软件正被广泛地应用于项目管理工作中,尤其是它清晰的表达方式,在项目时间管理上更显得方便、灵活、高效。
在管理软件中输入活动列表、估算的活动工期、活动之间的逻辑关系、参与活动的人力资源、成本,项目管理软件可以自动进行数学计算、平衡资源分配、成本计算,并可迅速地解决进度交叉问题,也可以打印显示出进度表。
项目管理软件除了具备项目进度制定功能外还具有较强的项目执行记录、跟踪项目计划、实际完成情况记录的能力,并能及时给出实际和潜在的影响分析。
在现代管理学奠基人彼得·德鲁克的《卓有成效的管理者》一书中提到,管理者有效性的基础是:记录时间;管理时间;统一安排时间。
因此,为了提高项目进展时间,第一步就是记录项目时间耗用的实际情况。
Linkwedo 可以清晰记录时间,帮助员工和管理者准确把握时间的分配情况,体现出也许连员工自己都忽略的工作过程和时间付出。
通过具体的事件记录和数字统计对时间花费进行分析比较,不仅可以使项目管理者一目...