软件开发项目的进度安排方式有哪些?
软件开发项目的进度安排可以有两种考虑方式。
第一种,系统最终交付使用的日期已经确定,软件开发机构必须在合同规定的时间内安排;第二种,只确定了大致的年限,最后交付使用的日期由软件开发机构根据具体情况确定。
后一种考虑能够对软件开发任务进行细致的分析;能够最好地利用资源,合理地分配工作量,但实际工作中常常遇到第一种情况,问题是软件管理人员如何在规定的期限内分配人力和安排进度。
进度安排的好坏往往影响整个项目的按期完成和用户的使用,如不能按期完成,用户就会不满,而且需向用户赔偿损失。
如作为商品,将会失去市场竞争力。
进度安排的精确性有时比成本估算更重要。
在商品生产的社会中,某种商品的损失往往还可以通过其他商品或分期偿还来承担。
而进度拖延的损失是无法弥补的。
下面就软件开发项目进度安排中的几个问题进行讨论。
1.软件工作的特殊性 制定软件进度与其他工程没有很大的区别,因此使用一般的通用技术和工具即可。
但重点要强调的是软件产品是逻辑产品,这与其他工程不同。
因此当几个人共同完成某项任务时,人与人之间就有一个思想交流问题,称之为通信关系。
通信是要付出代价的,不只是要花时间,同时由于通信中的疏忽常常会使错误增加。
如一个组有4个软件工程师,两两之间进行通信联系,通信路径有6条;对6个软件工程师,则通信路径增加至14条。
因此所付的代价就必然会增加,所以工作组的人员不宜太多,一般3—5人为好,目前国外一般采用主程序员组的制度。
另一点要强调的是软件工作切忌中间临时加人,必须在安排进度时就考虑周到。
2.各阶段工作量的分配 估算出总的工作量以后,就需要一个可以进行各阶段工作量分配的模型。
某一阶段工作量所占的百分比必须根据经验数据确定。
这里要再一次强调,在开发过程中保存的记录将增加经验数据库存,而且将改善今后估算的准确性。
R.S.Pessman提出一种称作40-20-40的工作量分配规则,即前期工作(计划、需求分析、概要设计和详细设计阶段)和后期工作(测试阶段)各占40%,编码阶段占20%。
应该强调要重视前期和后期工作。
前期工作容易被忽视,主要原因是:管理人员认为不开始编码工作就算没有进行,他们不了解前期工作的重要性;技术人员往往也急于编码,认为写出代码任务就算完成了。
后期工作也容易被忽视,认为编码出来就完事了,对测试工作要占这么大的工作量没有思想准备。
所以要制定好进度计划,就要研究软件工作的规律,前期基础工作没做好,将会给后期工作带来很大困难,往往使工程进度一拖再拖,难以坚持,有的不得不中途夭折。
3.制定开发进度 需要涉及的下一个未知量是开发进度。
进度安排是软件计划工作中一项最困难的任务,计划人员要把可用资源与项目工作量协调好;要考虑各项任务之间的相互依赖关系,并且尽可能地平行进行;预见可能出现问题和项目的“细脖子”,并提出处理意见;以及规定进度,评审和应交付的文档。
假设用作变量的开发时间TD按线性变化,而且已经得到了总的开发工作量估算值ED,要求在规定的时间TD内完成,在项目中最好有参加工作的人员平均值M,即M=EDTD,这将是一个非常有用的数据。
遗憾的是在上述算式中,项目的工作量和开发时间不能作为独立的变量。
Books定律描述了这种现象的最极端情况:为误期的软件项目增加人员将会使其进度更慢。
来源:www.examda.com (四) 软件开发组织 有多少个软件开发机构,几乎也就有多少人员的组织机构。
不管这些组织机构是好或坏,一般是不可能轻易改变的。
尽管组织机构的改变不属于软件计划人员的职责范围内的事。
不过,在一个新的软件项目中直接涉及人员的组织问题却是可以,也应该在软件计划阶段加以认真考虑的。
影响软件开发进度的原因有哪些
文主要谈谈影响软件开发项目进度的因素、项目进度控制的目的、常用项目进度控制措施,软件开发项目进度控制中对项目经理而言需要注意的问题和一些工作经验、工作方法。
关键词:项目管理、进度、控制 一、影响软件开发项目进度的因素 要有效地进行进度控制,必须对影响进度的因素进行分析,事先或及时采取必要的措施,尽量缩小计划进度与实际进度的偏差,实现对项目的主动控制。
软件开发项目中影响进度的因素很多,如人为因素、技术因素、资金因素、环境因素等等。
在软件开项目的实施中,人的因素是最重要的因素,技术的因素归根到底也是人的因素。
软件开发项目进度控制常见问题主要是体现在对一些因素的考虑上。
常见的问题有以下几种情况: 1、80-20原则与过于乐观的进度控制 80-20原则在软件开发项目进度控制方面体现在:80%的项目工作可以在20%的时间内完成,而剩余的20%的项目工作需要80%的时间。
这个80%的项目工作不一定是在项目的前期,而可能是分布在项目的各个阶段,但是剩余的20%左右的项目工作大部分是在后期。
所以软件开发在进入编码阶段后会给人一种“进展快速”的感觉,使得项目经理、项目团队成员、用户以及高层领导产生了过于乐观的估计。
有些领导看到软件交付给用户了,就一块石头落地“总算交差了”,同时又可能撤出一些被认为不必要的人力资源。
但很多情况下这是为了对付用户不合理的交付期限要求而采用的不得已的措施。
这样的结果是拖延了后期的工作,同时如果软件还不成熟的话,会给用户造成不好的影响。
2、范围、质量因素对进度的影响 软件开发项目比其他任何建设项目都会有更经常的变更,大概是因为软件程序是一种“看不见”又“很容易修改”的东东吧,用户是想改就改,造成需求的蔓延,项目经理有时还不知如何拒绝,加上要说“我能”的心理因素,一般都会答应修改。
这样集少成多,逐渐影响了项目进度。
如果某项工作在进度上表面上达到目标了,但经检验其质量没有达到要求,则必然要通过返工等手段,增加人力资源的投入,增加时间的投入,实际上是拖延了进度。
不管是从横向或纵向来看,部分任务的质量会影响总体项目的进度,前面的一些任务质量中会影响到后面的一些任务质量。
3、资源、预算变更对进度的影响 资源,最主要的还是人力资源,有时某方面的人员不够到位,或者在多个项目的情况下某方面的人员中途被抽到其他项目、或身兼多个项目、或在别的项目不能自拔无法投入本项目。
还有一个很重要的资源,就是信息资源,如某些国家标准、行业标准,用户可能提供不了,而是需要去收集或购买,如果不能按时得到,就会影响需求分析、设计或编码的工作。
其他资源,如开发设备或软件没有到货,也会对进度造成影响。
预算其实就是一种资源,它的变更会影响某些资源的变更,从而对进度造成影响。
4、低估了软件开发项目实现的条件 低估软件开发项目实现的条件表现在低估技术难度、低估协调复杂度、低估环境因素这样几个方面。
首先是低估技术难度。
软件开发项目团队成员,有时甚至是企业的高级项目主管也经常低估项目技术上的困难。
低估技术难度实际上也就是高估人的能力,认为或希望项目会按照已经制定的乐观项目计划顺利地实施,而实际则不然。
软件开发项目的高技术特点本身说明其实施中会有很多技术的难度,除了需要高水平的技术人员来实施外,还要考虑为解决某些性能问题而进行科研攻关和项目实验; 其次,低估了协调复杂度,也低估了多个项目团队参加项目时工作协调上的困难。
软件开发项目团队成员比较强调个人的智慧、强调个性,这给项目工作协调带来更多的复杂度。
当一个大项目由很多子项目组成时,不仅会增加相互之间充分沟通交流的困难,更会增加项目协调和进度控制上的困难。
另外,企业高级项目主管和项目经理也经常低估环境因素,这些环境因素包括用户环境、行业环境、组织环境、社会环境、经济环境。
低估这些条件,既有主观的原因,也会有客观的原因。
对项目环境的了解程度不够,造成没有做好充分的准备。
5、项目状态信息收集的情况 由于项目经理的经验或素质原因,对项目状态信息收集的的掌握不足,及时性准确性完整性比较差。
另外其它一些原因也会造成这种现象。
某些项目团队成员报喜不报忧,不希望别人知道自己工作的不好的情况,例如软件程序的编制,可能会先编制一些表面的东西,现有界面,看起来好像完成任务了,实际上只是一个“原型系统”或演示系统。
给领导造成比较乐观的感觉。
如果项目经理或者管理团队没有及时地检查发现这种情况,将对项目的进度造成严重的影响。
当然,如果出现这种需要时时刻刻都互相提防的氛围,管理人员就应该从管理的角度,从制度的角度检讨一下,进行改进,让大家实事求是地进行沟通。
温伯格说:“无论你多么聪明,离开了信息,对项目进行成功的控制就是无源之水、无本之木。
” 6、执行计划的严格程度 没有把计划作为项目过程行动的基础,而是把计划放在一边,比较随意去做。
例如对于项目团队内部沟通或外部沟通,在计划中要说明清楚...
国内游戏软件发展趋势与分析
浅论软件工程 软件工程 (Software Engineering,简称为SE)是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。
它涉及到程序设计语言,数据库,软件开发工具,系统平台,标准,设计模式等方面。
在现代社会中,软件应用于多个方面。
典型的软件比如有电子邮件,嵌入式系统,人机界面,办公套件,操作系统,编译器,数据库,游戏等。
同时,各个行业几乎都有计算机软件的应用,比如工业,农业,银行,航空,政府部门等。
这些应用促进了经济和社会的发展,使得人们的工作更加高效,同时提高了生活质量。
软件工程师是对应用软件创造软件的人们的统称,软件工程师按照所处的领域不同可以分为系统分析员,软件设计师,系统架构师,程序员,测试员等等。
人们也常常用程序员来泛指各种软件工程师。
软件工程的主要课程: 外语、高等数学、线性代数、高等代数、电子技术基础、离散数学、计算机引论(C语言)、数据结构、C 程序设计、汇编语言程序设计、算法设计与分析、计算机组成原理与体系结构、数据库系统、计算机网络、软件工程、软件测试技术、软件需求与项目管理、软件设计实例分析、CMM/ISO9000等。
软件工程(SoftWare Engineering)的框架可概括为:目标、过程和原则。
(1)软件工程目标:生产具有正确性、可用性以及开销合宜的产品。
正确性指软件产品达到预期功能的程度。
可用性指软件基本结构、实现及文档为用户可用的程度。
开销合宜是指软件开发、运行的整个开销满足用户要求的程度。
这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题,它们形成了对过程、过程模型及工程方法选取的约束。
(2)软件工程过程:生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。
软件工程过程主要包括开发过程、运作过程、维护过程。
它们覆盖了需求、设计、实现、确认以及维护等活动。
需求活动包括问题分析和需求分析。
问题分析获取需求定义,又称软件需求规约。
需求分析生成功能规约。
设计活动一般包括概要设计和详细设计。
概要设计建立整个软件系统结构,包括子系统、模块以及相关层次的说明、每一模块的接口定义。
详细设计产生程序员可用的模块说明,包括每一模块中数据结构说明及加工描述。
实现活动把设计结果转换为可执行的程序代码。
确认活动贯穿于整个开发过程,实现完成后的确认,保证最终产品满足用户的要求。
维护活动包括使用过程中的扩充、修改与完善。
伴随以上过程,还有管理过程、支持过程、培训过程等。
(3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。
[编辑本段]软件工程的定义 软件工程一直以来都缺乏一个统一的定义,很多学者、组织机构都分别给出了自己的定义: (1)。
Barry Boehm:运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。
(2)。
IEEE在软件工程术语汇编中的定义:软件工程是:1.将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护,即将工程化应用于软件;2.在1中所述方法的研究 (3)。
Fritz Bauer在NATO会议上给出的定义:建立并使用完善的工程化原则,以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。
目前比较认可的一种定义认为:软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件,以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。
(4)。
《计算机科学技术百科全书》中的定义:软件工程是应用计算机科学、数学及管理科学等原理,开发软件的工程。
软件工程借鉴传统工程的原则、方法,以提高质量、降低成本。
其中,计算机科学、数学用于构建模型与算法,工程科学用于制定规范、设计范型(paradigm)、评估成本及确定权衡,管理科学用于计划、资源、质量、成本等管理。
[编辑本段]软件工程学的内容 软件工程学的主要内容是软件开发技术和软件工程管理. 软件开发技术包含软件工程方法学、软件工具和软件开发环境;软件工程管理学包含软件工程经济学和软件管理学。
[编辑本段]软件工程基本原理 著名软件工程专家B.Boehm综合有关专家和学者的意见并总结了多年来开发软件的经验,于1983年在一篇论文中提出了软件工程的七条基本原理。
Boehm (1)用分阶段的生存周期计划进行严格的管理。
(2)坚持进行阶段评审。
(3)实行严格的产品控制。
(4)采用现代程序设计技术。
(5)软件工程结果应能清楚地审查。
(6)开发小组的人员应该少而精。
(7)承认不断改进软件工程实践的必要性。
B.Boehm指出,遵循前六条基本原理,能够实现软件的工程化生产;按照第七条原理,不仅要积极主动地采纳新的软件技术,而且要注意不断总结经验。
软件工程(SoftWare Engineering)的框架可概括为:目标、过程和原则。
(1)软件工程目标:生产具有正确性、可用性以及开销合宜的产品。
正确性指软件产品达到预期功能的程度。
可用性指软件基本结构、实现及文档为...
为什么需求分析是软件发展的第一步
我想提问者可能想问的是:需求分析是软件开发的第一步。
。
。
估计是英文单词 development 翻译的问题。
。
从软件工程和需求工程的角度来讲,需求分析并不是第一步,而且也不可能是第一步,为什么这么说呢?做任何事之前需要先知道做什么,这个对软件开发来讲就是需要先知道客户需求!那么获取客户需求就是必需的,然后通过对客户需求进行“翻译”并且进行 规格化编写后 成为开发人员(如设计人员和代码编写人员)以及测试人员能够理解的软件需求规格说明书来用。
那问题来了,怎么获取客户需求呢?从大的角度来讲两个方面:1 做好需求获取准备,包括客户初步需求的研究(合同)、用户模型(哪些人会使用开发的产品)的搭建、调研人员和被访谈人员的选定和协调、类似产品的了解 2 调研客户的策略和制定规范化的问卷, 这些步骤都非常关键!!!为什么这么说呢? 因为对于软件应用开发来讲,目前最大的问题是需求质量低下问题!需求质量低下体现在不断的需求变更上。
然后对齐分析发现:其中引起需求变更最大的三个来源就是:需求不完整、需求描述不清晰 和需求丢失,分析这三个来源背后的主要原因有:准备工作不足、不会调研进行需求、不会分析需求、不会描述客户需求和不会规格化软件需求,从而导致需求变更的非常频繁,结果就是项目组靠不断的加班来赶进度和降低成本。
所以从这个角度来讲,需求准备工作或者需求开发是软件开发的第一步。
希望能对你有帮助。
在软件开发中,需求分析阶段产生的主要文档是什么?
这个时期产生的主要文档是《XX软件需求规格说明书》。
需求规格说明书一般包含以下内容,但具体内容需要根据实际情况来书写,以下仅供参考:1.引言1.1编写目的【阐明编写需求说明书的目的,指明读者对象.】为明确软件需求、安排项目规划与进度、组织软件开发与测试,撰写本文档.本文档供项目经理、设计人员、开发人员参考.1.2项目背景a.项目的委托单位、开发单位和主管部门b.该软件系统与其他1.3定义【列出文当中所用到的专门术语的定义和缩写词的原文.】1.4参考资料a.项目经核准的计划任务书、合同或上级机关的批文b.项目开发计划c.文档所引用的资料、标准和规范.列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源2.任务概述2.1目标2.2运行环境操作系统:Microsoft Windows 2000 Advanced Server支持环境:IIS 5.0数 据 库:Microsoft SQL Server 20002.3条件与限制3.数据描述3.1静态数据3.2动态数据【包括输入数据和输出数据.】3.3数据库介绍【给出使用数据库的名称和类型.】3.4数据词典3.5数据采集4.功能需求4.1功能划分4.2功能描述5.性能需求5.1数据精确度5.2时间特性【如响应时间、更新处理时间、数据转换与传输时间、运行时间等.】5.3适应性【在操作方式、运行环境、与其它软件的接口以及开发计划等发生变化时,应具有的适应能力.】6.运行需求6.1用户界面【如屏幕格式、报表格式、菜单格式、输入输出时间等.】6.2硬件接口6.3软件接口6.4故障处理7.其它需求【如可使用性、安全保密、可维护性、可移植性等.】
软件开发项目进度怎么写。
要写具体时间吗。
1、任务分配、人力资源分配、时间分配要与工程进度相协调在小型软件开发项目中,一个程序员能够完成从需求分析、设计、编码,到测试的全部工作。
随着软件项目规模的扩大,人们无法容忍一个人花十年时间去完成一个需要十几个人年才能完成的软件项目。
大型软件的开发方式必然是程序员们的集体劳动。
由于软件开发是一项复杂的智力劳动,在软件开发过程中加入新的程序员往往会对项目产生不良影响。
因为新手要从了解这个系统和以前的工作做起,当前正在从事这项工作的“专家”不得不停下手中的工作,抽出时间对他们进行培训。
于是,在一段时间内,工作进度便拖后了。
软件开发人数的增加将导致信息交流路径和复杂性的增加,项目进行中盲目增加人员可能造成事倍功半的效果。
适用于大型项目的Rayleigh-Norden曲线[4]表明,完成软件项目的成本与时间的关系不是线性的,使用较少的人员,在可能的情况下,相对延长一些工作时间可以取得较大的经济效益。
然而值得指出的是,程序员小组的正常技术交流能改进软件质量,提高软件的可维护性,减少软件错误,降低软件测试和正确性维护的开销。
任务、人力、时间三者之间存在最佳组合,必须引起项目负责人的足够重视。
2、任务分解与并行化软件工程项目既然需要软件开发人员集体的劳动,就需要采取一定的组织形式,将软件开发人员组织起来。
软件人员的组织与分工是与软件项目的任务分解分不开的。
为了缩短工程进度,充分发挥软件开发人员的潜力,软件项目的任务分解应尽力挖掘并行成分,以便软件施工时采用并行处理方式。
3、工作量分布 用前几节介绍的软件估算技术可以估算出软件开发各个阶段所需要的工作量,通常用人月或人年表示。
软件在需求分析和设计阶段占用的工作量达到总工作量的40%~50%,说明软件开发前期的活动多么重要。
当然这也包括分阶段开发原型的开销。
大家熟悉的编码工作只占全部工作量的10%~20%,而软件测试和调试的工作量占到总工作量的30%~40%。
这对于保证软件产品质量是十分必要的,实时嵌入式系统软件的测试和调试工作量所占的比例还要大些。
4、工程进度安排 软件项目的工作安排与其他工程项目的进度安排十分相似,通常的项目进度安排方法和工具稍加改造就可以用于软件项目的进度安排。
目前,程序评估与审查技术(PERT)和关键路径方法(CPM)是两种比较常用的项目进度安排方法。
两种方法都生成描述项目进展状态的任务网络图。
网络图中按一定的次序列出所有的子任务和任务进展的里程碑,它表示各子任务之间的依赖关系。
网络图也是作业分解结构(WBS)的发展。
20世纪70年代,作业分解结构就已广泛应用于航天、航空、航海、雷达、通信、火控系统等领域的基于计算机项目的分解,并用以命名各项子任务,这些子任务不仅可以用网络图的形式表示,还可以用树型或层次结构图表示。
PERT和CPM方法为软件规划人员提供了定量描述工具,包括:①关键路径。
完成关键路径上所有任务时间的总和,就是项目开发所需要的最短时间。
②用统计模型估算开发每个子任务需要的工作量和时间。
③计算各子任务的最早启动时间和最迟启动时间,即确定启动子任务的时间窗口边界。
某个子任务的最早启动时间被定义为该子任务的所有前导任务完成的最早时间。
反之,某个子任务的最迟启动时间被定义为在保证项目按时完成的前提下,最迟启动该子任务的时间。
与最早启动时间和最迟启动时间对应的概念是最早结束时间和最迟结束时间。
它们分别是最早启动时间和最迟启动时间与完成该子任务所需要时间的和:在任务进度安排过程中,应先寻求关键路径并在关键路径上安排一定的机动时间和节假日,以便应付意想不到的困难和问题。
采用这些工具可以大大减轻软件项目管理人员在制定软件项目进度表方面的工作量,并可提高工作质量。
在软件开发中项目进度失控会受到哪些因素的影响呢?
(1)缺少进度指路明灯 当我们在路上行走的时候,会在沿途观看路标,当到达某一个路标时,我们便知道还有多少路或多少时间才能够到达终点。
这些路标是我们在旅程中的里程碑,让我们可以清楚地知道目前所在地离开目的地有多远,也让我们能估算何时才能够到达目的地。
对于在路上行走的我们,可以通过路边的里程碑这一个简单工具来获知自己的进度信息。
当进行软件开发的时候,我们也需要建立开发项目的里程碑,使我们知道项目的进度。
里程碑是项目管理不可忽视的一部分,通常意味一个时间点上可交付成果的完成,好的里程碑管理就像一张地图指示我们走向项目目标的进度。
(2)项目进度估算准确性差 软件项目开发进度控制面临的最大挑战就是项目进度估算的准确性差。
据统计,在对软件项目进度与成本估算时,大多数项目实际完成时间超过估算进度的25%到100%。
根据我的经验要想对项目进度进行有效的估算,必须抓好以下两个方面:一是项目计划的可行性和可操作性,这是进度估算的基础。
二是要对项目进度进行合理的度量,这样才能够获得项目的真实进展情况,并对项目估算做出相应调整。
(3)前松后紧,项目进度缺乏有效监管和控制 一般人在工作时都有前松后紧的习惯,而里程碑强制规定在某段时间做什么,从而合理分配工作,细化管理粒度。
对复杂的软件开发项目而言,每一阶段的进度都需要逐步逼近目标,里程碑产出的中间“交付物”就是每一步逼近的结果,也是控制的对象。
如果没有里程碑,中间想知道“现在进度做的怎么样了”是很困难的。
(4)没有尽早发现和降低项目风险 在软件开发中错误发现得越晚,对于开发造成的损失越大。
里程碑式开发模式可根据每个阶段产出结果分期确认成果,避免血本无归。
通过早期里程碑评审一般可以提前发现需求和设计中的问题,降低后期修改和返工的可能性。
例如,在需求分析阶段发生的错误,那么最多就是把需求分析写一遍,损失的是一个人的劳动;而到了测试阶段发现了需求错误,再回去重新做需求分析,那么损失可能是致命的。