软件开发交付物应该以什么形式进行
1. 确认项目范围项目中范围包括了两大类:一类产品范围,也就是应该覆盖的业务需求;另一类项目范围,是为了实现项目目标所需要完成的工作。
第二类项目范围,大多是事务性工作。
相对比较好界定,比如开发环境准备,系统安装调试,系统切换等。
因为讨论的目的仅仅是界定需要做哪些事情,对于工作范围中理解的偏差,双方记录了下来,列为待决事项希望后续进行讨论,所以还算顺利。
初步确定的工作范围见表3-3。
W老师建议,产品范围使用统一的功能清单进行确认。
为了规范大家的工作,根据经验将功能的层级进行了统一的约定:第一层是子系统,指相对比较独立、完整的一组业务功能。
例如:存款子系统、贷款子系统等。
表3-3项目范围编号 一级 二级 三级 状态 类别 工作量/人天 责任矩阵乙方 甲方 第三方 备注A 软件系统 1025 A1A2A3 应用系统 确认 必须 750 P S 详细内容见《子系统A需求清单》外部接口 确认 必须 150 P S S 详细内容见《外部接口系统清单》版本升级系统 确认 可选 125 P S 详细内容见《版本自动升级系统规格》B 系统实施 340 B1B2B3 数据移植 确认 必须 65 P S 用户培训 确认 必须 95 P S 系统切换 确认 必须 180 P S SC 硬件系统 60 C1C2 主机环境 确认 必须 15 P P 乙方确认配置,安装调试;甲方采购部署网点环境 确认 必须 45 P P S 乙方确认配置;甲方负责改造D 项目管理 100 D1D2 项目启动 确认 必须 20 P S 系统移交 确认 必须 10 P S S第二层是功能集,指在子系统内按照业务特性归集的一组操作。
比如客户信息管理、利率管理、还款管理等功能集。
第三层是执行单元,是指一次完成的一个独立业务操作,比如新增客户、修改客户信息、查询客户信息等。
这个简单的分类方法对于多个小组并行工作帮助很大,讨论不再像以前没有章法,工作成果也非常一致,效率很高。
这就是经验啊!2. 粗略工作量估算开发的工作量由于需求还没有最终确定,请W老师按照经验估算一下最高、最低、最可能三个值,作为基本的估算数据。
对于项目范围内的事务性工作,按工作所需人数和大约持续的时间估算了工作量。
汇总起来,得到了项目总体工作量。
小M向上级书面汇报粗略估算的项目总体人力要求。
S总、W老师和公司几个专家一起帮助小M对估算结果进行审核,认可了估算的结果。
3. 人力资源配置当前最重要的是确认启动项目的人力需求。
小M比较详细地测算了启动之后需要的人员数量,各级岗位人员的技能要求、工作开始日期、工作结束日期等信息。
S总确认之后,开始向小M的项目中派遣人员。
同时,事业部也开始根据估算数据从公司内协调和寻找资源,为后期工作做准备。
客户方面,G总从各个业务部门调集所需要的资源,并约定下周一参加项目启动会。
4. 客户沟通《项目管理计划》整理出来之后, G总让高层领导在上面签字批准,这下项目组可有了“尚方宝剑”。
小M、W老师在G总的带领下,逐个拜访客户各个方面的相关领导。
拜访内容一是让干系人了解这个项目,了解干系人对项目的要求和期待。
二是提交《项目管理计划》,说明项目与这些部门的关系,并借此机会邀请他们参加下周一的启动会。
按照公司的要求,小M还确定了三名客户主管作为满意度调查对象,获取其联系方式(电子邮件、电话),通知了公司负责调查的部门。
5. 确定开发过程业务小组在W老师的指导下,进展非常有序:W老师与架构师、业务负责人一起,根据项目实际情况对开发过程进行裁剪,制定一个《项目开发过程》文件。
按照项目的开发阶段,明确各阶段交付物,制定交付物的模板。
对于需求分析过程的模板进行了确认和修改,并选择了几个典型功能作为案例,进行实际使用的演练和改进。
经过演练之后,结合客户的特点对需求分析的过程进行了调整,制定了完整的模板、流程;演练的结果做成了“样例”,参加过演练和方法整理的人员成了可以培养和指导他人的“种子”了。
项目管理工具软件有哪些?
交付物质量管理是汽车新产品开发项目管理的重要内容,对项目实施成功与否具有重要意义,运用全球整车开发流程(Global Vehicle Development Process,GVDP)、项目质量及状态审议(Program Quality ReadinessReview,PQRR)等工具管理控制项目各主要节点的交付物,可使项目开发各阶段的交付物质量达到最优状态,从而为项目既定目标的如期实现保驾护航。
急需软件项目管理案例,要案例就行,软件项目的~
A公司是一家美资软件公司在华办事机构,其主要的目标是开拓中国市场、服务中国客户,做一些本地化和客户化的工作。
它的主要软件产品是由总部在硅谷的软件开发基地完成,然后由世界各地的分公司或办事机构进行客户化定制、二次开发和系统维护。
这些工作除了日常销售和系统核心维护之外,都是外包给本地的软件公司来做。
东方公司是A公司在中国的合作伙伴,主要负责软件的本地化和测试工作。
Bob先生是A公司中国地区的负责人,Henry则是刚刚加入A公司的负责此外包项目的项目经理。
东方公司是由William负责开发和管理工作,William本身是技术人员,并没有项目管理的经验。
当Henry接手这项工作后,发现东方公司的项目开发成本非常高,每人每天130美金,但客户的满意度较差,并且每次开发进度都要拖后,交付使用的版本也不尽如人意。
而且,东方公司和A公司硅谷开发总部缺乏必要的沟通 只能把问题反馈给Henry,由Henry再反馈给总部。
但由于Henry本身并不熟悉这个软件的开发工作,也造成了很多不必要的麻烦。
为此,Bob希望Henry和William用项目管理的方法对该项目进行管理和改进。
随后,Henry和William召开了一系列的会议 提出了新的做法。
首先,他们制定了详细的项目计划和进度计划;其次,成立了单独的测试小组,将软件的开发和测试分开;并且,在硅谷和东方公司之间建立了一个新的沟通渠道,一些软件问题可以与总部直接沟通;同时,还采用了里程碑管理。
六个月后,软件交付使用。
但是客户对这个版本还是不满意,认为还有很多问题。
为什么运用了项目管理的方法,这个项目还是没有得到改善? Henry和William又进行了反复探讨,发现主要有三个方面问题:1、软件本地化产生的问题并不多,但A公司提供的底层软件本身存在一些问题;2、软件的界面也存在一些问题,这是由于测试的项目不够详细引起的;3、开发的周期还是太短,没有时间完成一些项目的调试,所以新版本还是有许多的问题。
此时,Henry向Bob提出是否采用公开招标的方式,选择新的、实力更强的合作伙伴。
但Bob认为,与东方公司合作时间已经很长了,如果选择新的伙伴又需要较长的适应期,而且成本可能会更高。
于是,Henry向东方公司提出一些新的管理建议。
首先,他们采用大量的历史数据进行分析,制定出更详细的进度计划;其次,要求东方公司提供详细的开发文档和测试文档 做的工作没有任何文档,给其他工作带来了很多困难);第三,重新审核开发周期,对里程碑进行细化。
又过了六个月,新的版本完成了。
这一次,客户对它的评价比前两个版本高得多,基本上达到项目运行的要求。
但客户还是对项目进度提出了疑问,认为实时推出换代产品不需要那么长的时间。
较常见的做法。
在软件外包工程中,保证质量的进度是很难控制的。
对于项目经理来说需要一整套复杂的能力,比如制定计划、确定优先顺序、干系人的沟通、评价等,每一种能力都与项目的最终结果有直接或者间接的关系。
然而,国内的项目经理大多没有接受过正规训练,缺乏项目管理方面的专业知识的技巧,往往只是凭借以前的少量经验盲目去做,容易出现各种问题。
尤其是在管理外包项目时,缺乏足够的经验和技巧,往往造成进度不断推迟,而质量无法保证的情况。
在这个案例中,我们可以看到现在IT业内许多外包项目的影子。
在该案例中,东方公司没有专门的项目经理,是由技术人员William兼做管理。
这是国内软件公司经常会出现的问题。
最初,出现进度落后的问题时,A公司的Henry与东方公司的William讨论后决定采用项目管理中计划管理等手段,其中包括里程碑管理。
这是控制进度的较常见做法。
里程碑管理的引入 一般来说,在项目开始时,项目组成员都会对项目制定一个详细的计划。
通常情况下,在明确的工作说明书(SOW)和WBS的基础上制定具体的进度计划时,需要采用一些具体的技术。
像这种软件外包项目,最成熟的技术是里程碑管理。
里程碑一般是项目中完成阶段性工作的标志。
不同类型的项目,里程碑也不同。
比如,在开发项目中,可以将需求的最终确认、产品移交等关键任务作为项目的里程碑。
本案例中,Henry在接手项目后采用里程碑进行管理是很恰当的。
不过,要注意的是,每到一个里程碑处,应及时对前段工作进行小结,并对后续工作进行计划调整。
对于一些管理效果明显的领域,可以不必投入较多精力。
而对于下一步管理过程中可能会出现问题的领域,应给予较多的关注。
当然,在软件项目里,进度的变化是较常见的事情。
在本案例中,采用里程碑管理后仍没有达到客户的要求,进度依然拖后。
在这里,就需要考虑另一个因素-质量与进度的关系。
通常,项目管理的前提是保证在预算内、满足质量的前提下,按进度完成项目。
因此,可以看到,保证质量是前提。
那么,如何在满足质量的前提下管理进度呢?单纯从项目管理理论知识中并没有一种有效的方式。
具体步骤为: 首先,尽量利用历史数据。
在本案例中,Henry应该调查之前的项目情况,将会发现可以类比的情况,事先就可以知道需要管理质量和进度的关系。
其次,由...
软件项目周期是什么
软件生命周期又称为软件生存周期或系统开发生命周期,是软件的产生直到报废的生命周期,周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段,这种按时间分程的思想方法是软件工程中的一种思想原则,即按部就班、逐步推进,每个阶段都要有定义、工作、审查、形成文档以供交流或备查,以提高软件的质量。
一,问题定义。
要求系统分析员与用户进行交流,弄清“用户需要计算机解决什么问题”然后提出关于“系统目标与范围的说明”,提交用户审查和确认。
二,可行性研究。
一方面在于把待开发的系统的目标以明确的语言描述出来,另一方面从经济、技术、法律等多方面进行可行性分析。
三,需求分析。
弄清用户对软件系统的全部需求,编写需求规格说明书和初步的用户手册,提交评审。
四,开发阶段。
开发阶段由三个阶段组成:1,设计;2,实现:根据选定的程序设计语言完成源程序的编码;3,测试五,维护:维护包括四个方面1,改正性维护:在软件交付使用后,由于开发测试时的不彻底、不完全、必然会有一部分隐藏的错误被带到运行阶段,这些隐藏的错误在某些特定的使用环境下就会暴露。
2,适应性维护:是为适应环境的变化而修改软件的活动。
3,完善性维护:是根据用户在使用过程中提出的一些建设性意见而进行的维护活动。
4,预防性维护:是为了进一步改善软件系统的可维护性和可靠性,并为以后的改进奠定基础。
接待客户过程中有什么项目交付物?
计划这个东西,到现在为止一直都存在错误的理解,回忆下我以前的计划,计划事情目标不明确,工作事项也不是具体的结果,而是例如阅读、总结、看视频等这样的项目细分。
再回忆下我的个人目标,让家人幸福,保持健康的身体,成为方案解决者。
这样的目标以及计划,所谓的让家人幸福结果就是经常吵架,保持健康的身体就是周末躺在床上睡觉,所谓的方案解决者也只是一句空口号而已。
这样的目标以及计划完全就是错误的,完全没有办法去执行以及监督,没有任何的可以判断的标准,看1个小时的视频也是看,看3个小时那也是看,看了之后又没有效果,谁知道,这种计划简直就是一种逃避计划,逃避自己在社会中所受到的歧视而通过这些计划建立的一些让自己感觉到有一些自尊的毫无用处的计划而已。
如何彻底的改变自己的计划方式,让计划真正的成为帮助自己实现目标的步骤。
计划是为了完成具体的目标,而目标必须要符合SMART原则,具体的、可量化的、可实现的、有时间限制的、目标与目标之间有关联性。
这是最初出发的地方,你必须要明确的知道自己想要的是什么,等这一切确定好后再来做计划,计划的目的是为了完成具体的目标,再分解的过程中可以用WBS来进行分解。
目标必须要有明确的交付物。
目标确定好后,有明确的交付物这大部分人都是知道的,但是在计划的时候,每一个步骤是否有详细的交付物明细这很少人能够做到了。
在做WBS分解的时候,就必须要确定目标分解后的交付物,可以分成那几个阶段来提交交付物,最后就能够达成目标。
千万不要将执行计划弄成看视频、上网搜索等这些空口号,否则在执行的时候就必然会找不到标准,从而也没有办法进行控制。
项目目标的计划过程,就是将目标进行细化分解的过程,在分解的过程中一定要以交付物为重点,每一个步骤要提交的物品是什么,然后如何计划去实现这个交付物。
这样会让你在执行的过程中会显得更加的有目标,而且也非常的方便进行监控。
转载请注明出处51数据库 » 软件项目各阶段交付物