时间：2022-07-16 10:29:05
绪论：在寻找写作灵感吗？爱发表网为您精选了1篇浅谈计算机软件项目管理，愿这些内容能够启迪您的思维，激发您的创作热情，欢迎您的阅读与分享！
论文摘要:本文认真分析了目前国内软件项目管理中出现的问题,以提高软件质量、降低成本、加强软件项目的可控性为目标,在深入研究和探讨CMM的基础上结合软件过程.给出了一种加强软件项目管理的实践模式。该实践模式定义了CMM中的6个关键过程域和3个工作组.并从项目的开发时间和质量方面做效率分析,强调了软件过程对软件项目管理的重要性。
论文关键词:软件项目;软件过程;CMM;KPA
1.引言
项目管理(PM,projectmanagement)是指利用现有的知识、方法和技术手段,有效地计划、调度、控制和跟踪项目的开始、执行、直止终止的过程,是项目顺利实现的有效手段。软件项目管理则是在项目管理的基础上,结合软件产品的实际,利用工程的概念和方法来开发与维护软件,对成本、风险、时间、质量、过程、配置等进行分析、管理、控制,最终目的是为了让软件项目的整个生命周期都在管理者的控制范围内,以预定成本按期、按质完成软件的开发并交付用户使用。目前,软件产品已广泛应用于各个领域,但是很多软件项目的成功率并不高.虽然有些公司根据软件工程理论建立了一些软件开发管理规范.但并没有从根本上提高软件项目管理问题,这就导致软件产品质量不稳定甚至是项目的失败,同时也损害了用户的利益。本文结合我国软件项目管理的特点并经实践应用.以提高软件质量、降低成本、加强软件项目的可控性为目标,通过对CMM的研究和改进,给出了一个基于CMM加强软件项目管理的实践模式,在这个模式中对目前CMM中的KPA做适当的裁减,定义了6个关键过程域和3个工作组。
2.软件项目管理中目前存在的问题
影响软件项目成功率的因素主要是软件质量问题,而在整个软件项目的实施过程中需求不明确、跟踪和监督不力、缺乏客观的软件评审和软件配置以及风险管理意识不足等都阻碍着软件质量的提高。
2.1需求不明确
需求管理是软件项目管理中非常关键的一个步骤.需求分析的完整与否可以降低软件质量、延长项目周期、加大成本。由于用户对计算机系统认识的不足,对于系统的需求往往比较模糊,遗漏甚至是错误的问题经常出现(包括管理流程、业务流程、数据或报表的分析处理等),但这些问题往往没有暴露给开发人员,而是随着项目的进展才逐渐明确。对于开发人员来说,需求的变更意味着软件产品的部分内容必须重新开发,而对于整个软件项目管理而言,势必要重新分配资源、调整计划、估算成本等等,导致软件产品质量下降。
2.2跟踪和监督不力
跟踪和监督主要针对过程而言,也是项目管理中最容易被忽视的环节。软件项目过程由多个任务构成,大部分任务都有前置任务和后置任务,这就要求项目管理者要严格跟踪和监督每一个任务。任务的完成主要从时间进度和质量两方面来衡量,还要充分考虑因客户方引起的一些客观因素(更改需求分析等)。项目管理者虽然制定了具体的项目进度内容,但如果缺乏有效的跟踪和监督机制,对于每一个阶段所要完成的任务疏于评价,就会影响下阶段软件产品的质量,有时甚至是软件产品的重新开发,最终影响整个软件项目。
2.3缺乏客观的软件评审
客观的软件评审是软件产品质量的直接保障,软件评审一直贯穿于整个软件项目的过程中,对软件产品的评审应有客户使用人员和软件业中的同行来进行。客户使用人员对软件产品做阶段性的评审可以及时发现软件产品功能方面的不足,同行评审可以从软件业的规范及标准去发现问题.软件评审可以降低软件开发的成本提高软件产品的质量。大多情况下项目管理者没有做任何阶段性的评审,通常只是在软件产品开发基本完成之后来组织评审,果发现了很多问题,但要修改已经非常困难.要花费很长的时间甚至从头再来。
2.4软件配置混乱
软件配置是指软件产品在各个阶段各种版本的文档、程序及数据的集合,贯穿于整个软件项目的始终。随着软件产品开发的进行,由于各种客观原因,其中的预算、设计方案、进度等内容都有可能需要大大小小的更改(这些改动可能是合理的),整个改变的过程对软件项目的参与人员来说必须是可视的,以便提高软件的可靠性和质量,而这一切都应该有正确的软件配置来控制如果失去正确的软件配置管理,那么针对软件产品发生的任何更改或者是维护都会给软件项目带来混乱甚至是失败。
2.5风险管理意识不足
风险管理是软件项目中防止失败的一种重要手段,软件项目不同的阶段存在着不同的风险,并且风险会随着项目的进展而变化,目前国内的软件企业大都不注意软件项目的风险管理。除了社会环境风险、商业风险等这些客观风险之外.可控的软件项目风险主要指技术风险。技术风险主要是指与软件项目本身相关的的技术因素变化带来的风险,如果在一定的条件下达不到技术条件能够实现的目标,不但延缓项目的进度而且会增加项目的成本.继而使整个项目受到影响。
3.通过过程管理加强软件项目管理的实践模式
利用cMM fCapabilityMaturityModeforSoftware)的核心思想把软件项目管理看作一个软件过程,并根据这一原则对整个软件项目的开发和管理进行过程监控,监督发现过程中影响项目的关键问题并予以解决。软件过程是指软件开发人员开发和维护软件及相关产品的一套行为、方法、实践及变换过程,包括软件开发过程和软件管理过程。CMM把软件开发机构按照不同开发水平划分为5个级别。每个等级被分解为几个KPA(关键过程域),KPA是指在某个成熟度等级应重点关注的区域,也是达到此成熟度等级必须解决的关键点。①初始级,无过程意义。软件过程是无序的、随机的、缺乏总计划,无预见性,大多数活动是应付危机,经常超期超支,成功取决于个人。②可重复级,具备基本的项目管理。KPA分别是:需求管理、软件项目计划、软件跟踪与监督、软件子合同管理、软件质量保证、软件配置管理;③已定义级,已定义软件过程。已将软件管理和软件工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。KPA分别是:组织过程焦点、组织过程定义、培训大纲、集成软件管理、软件产品工程、组间协调、同行评审;④可管理级,过程可度量。已收集了软件过程和产品质量的详细度量方法,软件过程和产品均可被定量地理解和控制。KPA分别是:定量过程管理、软件质量管理;⑤优化级,过程控制。通过过程的量化反馈以及新技术、新方法促使过程不断改进。KPA分别是:缺陷预防、技术更新预防、过程更改管理。
CMM只是一个过程改进的框架.并没有给出具体实施的办法。在该模式中对目前CMM中的KPA做适当裁 减.定义了6个关键过程域:软件项目计划(SPP)、需求管理(RM)、软件项目跟踪和监督(SPTO)、软件质量保证(SQA)、软件配置(SCM)、同行评审(PR),设置了三个工作组:软件项目过程组(SPPG)、软件工程组(SEG)、软件质量保证组(SQAG)。通过工作组对关键过程域的操作来加强软件项目的管理。
3.1定义KPA
3.1.1软件项目计划(SPP)
软件项目计划是为要实施的软件项目编制软件过程活动的安排,包括进度控制、成本控制、质量控制、风险控制等,也是实施CMM2的核心此阶段在安排过程活动的同时开展项目设计的前期工作,设计和界定在整个项目中各阶段所需的开发、质量、跟踪、评审、风险、成本等工作。项目计划是指导项目过程的具体措施,要在有软件项目实施经验的人员领导下投人大量的时间和人力资源来完成。制定项目计划应注意7个问题。①在科学论证的基础上制定过程,充分调动人员积极性合理地确定项目组的参加人员;②对软件项目各程中的任务进行分解,明确项目的里程碑和检查点;③正确估计软件项目中的软件资源、硬件资源、人力资源及其它费用;④正确估计各方面因素带来的风险并制定应对措施;⑤制定项目实施过程中的跟踪和监督措施;⑥确定软件的评审和测试方法;⑦详细的文档资料。
3.1.2需求管理(RM)
需求分析主要包括面向用户的用户需求和面向开发人员的系统需求.是整个软件工程的第一步.也是非常关键的一个环节。需求分析主要针对用户的业务流程、系统功能、性能、数据分析进行严格的定义.是设计一个软件应用系统的起点与基本依据,通过它来评判软件产品是否能够解决用户问题,也是项目成功与否的标准。就目前国内现状来讲,一般签定软件项目合同的用户是主管信息技术的负责人,它所关心的可能是整个系统的目标需求,用户方中层管理人员关心的是业务流程需求.终端操作人员则注重软件本身的易操作性和功能特性,因此.面向用户的需求一定要和用户多方人员多沟通、交流.最终通过双方有关部门人员的论证以文档资料的形式确定下来。任何一个需求分析因客观原因可能存在着需求更改的现象,对于这种情况一定要注意需求更改的可控性.要建立需求的基准版本和更改版本控制文档资料.使受需求变化影响的产品与需求变更一致。但要注意在更改需求的同时要衡量需求的稳定性,如果一个需求的变更比较频繁,意味着本项目并没有真正了解用户想要解决的实际问题。可以说需求分析的完整性和变更可控性直接影响到软件过程的改进,它可以降低软件质量、加大软件开发的成本、甚至是导致项目的失败。软件工程组(SEG)中要明确定义一个需求管理员。
3.1.3软件项目跟踪和监督(SPTO)
软件项目的跟踪和监督始终贯穿于整个软件项目的过程中,是项目得以控制的前提和条件、是软件质量的根本保障,其目的是增加软件过程中进度、成本、工作量、质量、风险等内容的可视性,也是实施CMM2的核心。除去市场、法律等不可控制因素外,根据项目计划对项目进展的有关情况及影响项目实施的相关因素进行及时、客观、准确的信息采集,将采集到的需求、成本、进度、风险等内容形成文档并建立一个项目跟踪信息平台。项目负责人定期召集软件过程人员、开发人员、质量保证人员、用户方有关人员召开开放式的例会,例会的主要内容是检查项目进展、数据的分析、认识的偏差、资源的搭配、相关的风险等问题并讨论确切的解决办法,通过跟踪和监督使项目始终处于可视化的受控状态。
3.1.4软件质量保证(SQA)
软件质量保证是与软件产品满足规定的和隐含的需要能力有关的特征或特性的组合。对用户来讲主要体现在软件产品的有效性、一致性、完整性、可靠性和可操作性等方面,对于软件产品本身来讲体现在软件产品的可移植性、易维护性、健壮性、可重用性等方面。具体实践中.软件质量保证应在软件项目计划、需求分析、跟踪和监督、软件配置和软件评审的相互配合下完成.软件质量保证要做到以事先预防和跟踪为主,事后纠偏为辅。
3.1.5软件配置(SCM)
软件配置是针对软件产品的跟踪和控制活动.贯穿于整个软件项目的过程中.目的是建立和维护在整个生命周期内软件产品的完整性和一致性,使整个软件产品的演进过程处于可控的状态,继而提高软件的可靠性和质量。在实践应用中主要做到五个子项的配置①配置项的标识。标识做到唯一性。便于跟踪和管理。②版本管理。对整个软件过程中的文件和目录提供有效的跟踪手段。③变更控制。保持并传递修改信息。④配置审计。确定整个项目生产周期中产品在技术和管理上的完整性。⑤系统整合。把系统的不同部分集成后完成一组特定的功能。
3.1.6同行评审(PR)
同行评审是根据预定的规范和标准对软件产品进行评审。评审的结果是衡量软件产品质量的依据。在整个软件过程中对详细设计和软件综合测试作为两个关键评审点来进行评审,评审的过程中注意要结合本软件项目的具体要求和标准。
3.2组的定义
在具体的实践应用中设置了三个组,在降低了人员成本的同时提高了软件过程改进能力和软件质量。
软件项目过程组(SPPG)组织具体的项目实施活动,管理并协调整个软件项目的过程,主要完成SPP和SPTO。
软件工程组(SEG)负责软件工程的需求分析、概要设计、详细设计、编码、测试、维护工作。
软件质量保证组(SQAG)主要完成SPTO、SCM、PR、SQA等工作。
4.实践模式效率评估
4.1开发时间
软件开发由需求分析、概要设计、详细设计、编码、软件测试、项目维护和软件集成几部分内容组成,在需求分析和设计阶段采用CMM框架实施过程管理所花费的时间要多于没有实施过程管理花费的时间。首先对项目做大量分析,论证项目的可行性。然后在和用户做良好沟通、反复论证的基础上做需求分析,形成文档资料。这种模式下花费在需求分析和设计上的时间大约占项目总开发时间的40%,但这两个阶段完成了数据流程、算法描述、详细的规格说明等内容,为代码编写、软件测试、软件维护等后续内容的工作节省了时间,软件项目的开发周期大大缩短。经过评估,采用该实践模式实施软件过程管理的软件项目开发周期比没有实施软件过程管理的软件项目开发周期缩短20%。
4.2开发质量
采用CMM标准通过软件过程管理加强软件项目管理的实践模式使软件质量明显提高、需求分析周密、代码错误率明显降低、软件产品完整性好、功能齐全、维护量下降,软件项目最终得以顺利实现。
5.结语
本文给出的通过软件过程管理加强软件项目管理的实践模式优点非常明显.软件过程改进目标明确,可以有效地提升软件产品质量、节省开发时间、降低成本。同时该模式更能体现团队精神,摆脱了软件开发中的个人主义,从整体出发,在强调过程对整体重要性的同时,进一步降低了软件过程中的各种风险,使软件项目始终处在可视化的优良受控状态中
论文关键词:需求分析 用户方干系人 项目经理 需求分析员
论文摘要:计算机软件项目管理中的需求分析是提高软件质量的基础也是决定一个软件项目成败的关键。本文介绍了在需求分析研究中探索出的一些有效措施。
众观国内计算机软件业的发展,除远不如欧美等西方发达国家外,与人均GDP不及我国的印度相比也相距甚远,软件业的劣势正严重制约着我国IT业的发展。我国软件业的劣势表现在自主开发的成熟软件不多,而开发的大量软件工程项目(如ERP等)存在缺陷或完全开发失败。目前,国家正在加大对软件工程的研究和对软件工程人才的培养。根据资料显示,属于需求分析造成软件设计的错误和缺陷约占软件失败的6400,而属于程序代码的错误仅占软件失败的360a,数据表明需求分析是提高软件质量的基础也是决定一个软件项目成败的关键。通过对软件项目管理知识的系统学习并结合近年来自己参与部分软件项目实施的经验,介绍在需求分析研究中探索出的一些有效措施。
1尽快熟悉项目用户方干系人全貌
项目用户方干系人,指所有可能受到项目结果重大影响的人,即项目的风险承担者,他可能是项目的受益者,也可能是项目的受害者。因此,应当从项目的启动开始,需求分析员及其项目成员就要分清项目用户方干系人包含哪些人和组织,通过沟通协调对他们施加影响,驱动他们对项目的支持,调查并明确他们的需求和愿望,减小其对项目的阻力,以确保项目获得成功。
有些项目在做需求调查时,由于受进度要求等客观因素影响,需求分析员与建设单位的技术部门交流较多,向业务管理部门和实际使用者调查不够深入,造成软件试用后不得不再对需求做较大调整,“从头再来”的部分比例很高,大大超过进度要求时间。因此,熟悉项目用户方干系人全貌是进行需求调查的第一步,也是需求调查的基础。在定制开发项目的项目用户方干系人中,最重要的是建设单位中的人事组织、业务关系。最好是能够用组织结构图画出相关单位的组织结构;还应当在相关单位组织结构图基础上画出全体项目用户方干系人结构图,以便更好更全面地进行需求调研分析;用责任矩阵确定各部分的调研对象;建立调研对象通讯录以保证调研及分析期间及时的沟通。
2采取正确的需求获取方法
软件开发项目的目的就是要实现项目用户方的需求,项目用户方的需求包含明确的和隐含的,也可以分为NEED, WANT, WISH等不同的层次。如果对项目所有用户方干系人没有进行足够的沟通和影响,使其尽可能地参与项目,则会出现客户方相关责任人不明确或对范围和需求责任心不强,提出的需求具有随意性,项目前期对需求的确认不够积极,或者是多个用户代表各说各话、昨是今非,项目后期需求变化随意等现象,这就会造成项目范围的蔓延,进度的拖延,成本的扩大,甚至项目的完全失败。
各种用户对系统具有不同的要求,如一个没有经验的用户关心系统是否简单易用,对于高级用户则关心产品的易用性和高效性。因而需要对用户进行分类,每一个用户类将有自己的一系列功能和非功能要求。在项目中,要尽早为产品确定并描述不同的用户类,这样就能从每一个重要的用户类代表中获取不同的需求。
项目需求具有双面性(用户与开发商)和多面性(项目中各干系人),因此,项目经理和系统集成者应了解用户干系人需求,用户干系人也应了解技术方面的需求,两者缺一不可。正确的需求获取需要了解需求的来源、用户的分类、用户的代表性、用户需求谁说了算数等因素。开发人员和项目经理要有足够的耐心聆听用户的讲述,要足够详细地了解每一个细节。项目管理者要善于将需求分类、归类,善于将需求文档化,并有所查询标记。
3可视化需求调研,引导各种客户挖掘他们的需求
有的客户因为自己缺乏计算机知识,无法提出完整准确、隐含的或潜在的需求。若这些需求不能满足将导致用户的不满。因此需求调研分析人员应善于想用户所想,不但要确定明确的需求,还要善于用启发的方式与用户探讨隐含的或潜在的需求,并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。这就要求需求调研分析员要尽快完整地熟悉相关业务,从而能够站在用户的立场看待软件需求,想用户所想,做好业务与计算机之间的桥梁。利用可视化需求调研的方法可以很好地启发用户深人挖掘潜在的需求。可视化需求调研就是使用图表等工具来启发引导用户清楚地叙述需求,并且使需求更加全面完善。
对于高层领导,可以提供系统总体框架图;对于业务管理人员,可以用业务流程图来描述新旧系统的业务流程;对于客户中的技术人员,可以用数据流图、实体关系图或UMI中的各种图形对系统进行各种角度的描述;而对于业务管理人员、客户中的技术人员、以及各层次各流程中的用户,画出用户界面图来进行需求挖掘,是个比较有效的沟通方式。
这里特别说明一下用户界面的重要性。用户界面的设计按理来说是软件设计的责任,当然客户自己对界面有特别提出要求的除外。但是,如果把它提前到需求调研时与客户进行讨论,则可以大大改善需求调研的效果。因为这时客户对于将来的系统还没有一个形象上的概念,或者有一个模糊的预想的概念需要表述、验证、明晰化、完善化,以笔者的经验,画出用户界面草图与客户进行讨论,可以大大激发他们提供更为准确全面的需求。原来收集资料,描述业务,说明系统模型到了山穷水尽的时候,这种方法可以达到柳暗花明又一村的效果。
4详细描述各项业务,以便让所有客户确认
尽可能全面详细地调查并且描述原有系统和用户希望将来系统具有的各项业务的流程,并将这些业务流程文档化后与客户进行讨论,对描述错误或不准确不精确的进行修改,最终让客户进行确认。从近年来开发的软件看,对业务处理过程了解的完整性和准确性非常重要。虽然对数据来说都是SIDUT(查增删改传),但具体业务都是分为若干步骤,每个步骤都有其业务名称,同一步骤可能对多个数据集进行不同操作,需要调查了解清楚才能设计出适合用户业务特点和习惯的软件,使开发出来的软件更受欢迎。当然在进行软件概要设计时,要尽量排除业务流程的制约,即把流程中的各项业务节点工作作为独立的对象,充分考虑他们与其他各种业务对象的接口,在流程之间通过业务对象的相互调用实现其业务流程,这样,在业务流程发生有限的变化时,就能够比较方便地修改系统程序而实现新的需求。
对于各项业务的调查可以通过对以下资料的收集整理分析来完成,这些资料来自各种各样的项目用户方干系人:遵循的标准、组织发放的工作手册、作业流程、有关业务的上级通知、有关业务的办事指南、办理业务时需要填写的登记表、各种相关的统计报表及通过其他途径收集的类似系统的介绍、技术资料等等。 5对项目用户方干系人的愿望进行平衡
不同的项目用户方干系人其愿望和追求的目标往往相差甚远,因 此对项目用户方干系人的愿望进行平衡可能是非常重要而又相当困难的事情。例如:我曾在参与的某医院计算机管理系统项目中,遇到医院管理层希望能够采集尽可能多的信息项以便对数据进行多种多样的统计分析,同时为了对信息进行有效控制而增加一些审批流程;而门诊、药房等对外办公的基层窗口则因为客流速度的压力希望减少信息项的输人量;甚至有些不良的基层部门由于害怕建立透明度高的信息系统会影响他们的利益而消极地应付,即所谓反需求;而客户的客户(就诊的病人)则希望相关机构能够简化工作流程,加快办事速度,增加诊断情况和就诊费用的透明度;甚至项目组本身因为技术、资源、进度等原因,需要对一些功能进行优先级排序和取舍。虽然不是所有人的需求都是可以满足的,特别是消极的反需求是不能接受的,但他们的需求都是应当考虑全面并进行平衡的。
如果不同的用户方干系人有不一致的需求,那么必须决策出满足哪一类用户方干系人的需求更为重要。了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关系如何,将有助于决定哪一个用户类所占份额更大。如果系统分析人员提出的需求与开发者所想要开发的系统发生冲突时,通常由于系统分析人员作为客户的人,市场需求具有更重的分量,但是,系统分析人员不能一味地迁就客户需求。
不同的用户方干系人可能都要求产品按照他们各自的喜好来设计。运用项目的业务目标来决定哪些是你最关心的客户,非核心客户的需求可以安排在下一个版本中开发。当开发者想像的产品与客户需求冲突时,通常应该由客户作出决策,然而,不要陷人“客户总是对的”的陷阱中去,现实中,客户并不总是对的。
6强调实现项目需求的层次递进性
了解该系统或者该项目用户所能够提供的最小的工程费用。当预计经费不能支持时,应当考虑将项目分期实施。在系统上、技术上对用户进行引导性建议,使用户了解集成商所要进行的工作,了解集成商是为了帮助用户实现他的需要、达到用户的目的,而不仅仅是为了赚钱,用户更了解集成商,也更了解自己的系统,有利于以后的项目合作、工程实施和系统维护。
分析用户曾用系统模式、数据结构和库模式,看是否保持、共用、转换,这涉及保护用户投资的问题。根据现在工作业务流情况确定现有的工作模式,还应兼顾将来可能会发生的变化、扩展、新规定,及与同国际接轨可能的带来的变化。考查工程实施环境是否有保证,尤其是网络工程,必须在需求调查时充分了解用户领域的实施环境,当不具有实施环境时,要求进行配套设计和环境改造。
7编写需求文挡和进行需求评审与其他项目小组成员协作完善系统需求
文档资料是集成商重要的财富,贯穿于系统集成和项目开发的整个过程,其中包括法律文档、技术文档、资料文挡。文挡要求完整性、一致性、可修改性、可跟踪性。
以原来的需求为基础的工作完成后,要修补需求错误需要大量的工作,研究表明:比起在需求开发阶段由客户发现的一个错误,然后更正这一错误需要多花到倍的时间。因此,需要进行需求评审。需求审查结束的标准为:已经明确阐述了审查员提出的所有问题、已经正确修改了文档、修订过的文档已经进行了语法检查、所有TBD问题都已经解决、文档归档。
需求文档完成之后,并不是把它扔给后面的设计人员就了事了。作为项目组其他成员,对需求的有效性也起到某种程度的验证作用。虽然软件项目的生命周期按照各种开发模型有不同阶段的划分,但每个阶段的结束不是简单地把阶段工作成果塞给下一阶段的成员就可以了。特别是高科技的软件开发项目,上一阶段的工作成果往往要通过多次的沟通才能更为清晰地被下一阶段成员接受,其有效性、合理性也要被下一阶段的工作所检验,通过检验有时也有必要对上一阶段的工作结果进行相应的调整,需求分析也是如此。因此,无论是同一阶段不同人员之间,或是不同阶段人员之间都应根据需要相互协作,相互配合,共同完成软件开发任务。
论文关键词:云技术 多媒体技术 改革现有的教学模式 教学资源的整合 激活学生的学习兴趣
论文摘要:在云技术架构下,建立强大的多媒体教学资濠库。这样可以集中整合各方优秀的教学资源,建最好的和最丰富的教学课库,让各奏学生均可找到适合自己,而且自己感性趣的课程和课件。建立了多媒体教学资涎库后,既可以垴小东西部教育差距,又能保障教育资泺的均衡发展。
大部分教师(尤其大学教师)的工作应该相应的从向学生灌输知识,转向引导学生学习知识,找到激活学生学习智门的钥匙。
放在云架构内的这些教学资源,随着不断的更新、增加,必将成为一笔极大的资源财富,不仅可以供在校学生学习使用,也可以提供给全社会需要再学习、需要更新知识的人士使用,为全社会形成一种不断学习的氛围,提供一个强大的资源保障。
一旦形成全社会不断学习的风气,社会就会和谐,文明程度的程度就会不断提高,人们的创新意识和能力就有了源动力,人们就会从更多的追求物质财富转而进入追求精神财富。
前文我们探讨了利用“云技术+多媒体技术改革现有的教学模式”,话题意犹未尽,还想进一步探讨一些教学模式改革的细节。当然我们暂且讨论的教学对象为大学以上的学生,或部分高中生,因为绝大部分高中生的教学活动还是基本围绕着高考指挥棒在转。
在云技术架构下,建立强大的多媒体教学资源库。这样可以集中整合各方优秀的教师资源、教学设备资源,建最好的和最丰富的教学课程库,让各类学生均可找到适合自己,而且自己感性趣的课程、课件和学习参考资料。
制作这些课程资源可以分工,高层次教师撰写课程内容,配套各类教师,可以有的整合内容、有的应用多媒体素材加工制作课件、有的制作各类课程教程、而有的则准备相关参考资料以及考试题库系统等教学资源。
这时的教学资源就不是属于某个学校、某个团体、某个局部组织,而是属于国家或全人类的资源,为全人类所共享。
这样,可能有人会担心是否教师或相应的人员都要下岗了呢?否!
大部分教师(尤其大学教师)的工作只是从向学生灌输知识,转向引导学生学习知识。大部分长期从事教学工作的教师深有体会,好学生不完全是教出来的,而且通过老师启发性的引导,激活了他们的兴趣,或打开了他们的智门,使他们自己要学习,只有激活了学习者的源动力,才能使他们朝着一个一个目标不断攀登。
那么,教师教学要包括哪些内容呢?我认为教师的教学工作应该围绕中如何能激活学习者的兴趣和以如何能打开他们的智门为衡量指标。方法可以各不相同,因为人是个性化的,当然方法也应该因人而异,当然可以对个性相近的学生采用类似的方法,但还是需要有微调。
具体做法可以不断摸索。教师可以组织学生开展各种开发、创新活动,可以组织各种竞赛活动,可以组织学生参与各种专题讨论活动,让每个学生均有机会表达自己的想法和观点,很多思想的火花是在交流中产生的,是在实践过程中绽放的,所以要多提供一些机会让学生经历各种活动的锻炼,活动的过程是最能锻炼人能力的,如果省略了过程,结果也是不丰实的。
我们提倡多开展各种创新活动来锻炼学生的能力,而现在学生这方面的锻炼机会太少,应该增加相应的比例。那么是否就不考试了呢?当然不行!期间,我们的学校大多不考试,结果中学毕业生连简单的一元一次方程都不会,这样社会如何发展?考试还是衡量学生学习掌握程度的标尺,当然考试形式可以的笔试,也可以是操作过程,更可以写论述文章、论文之类形式;考试时间可以是期中、期末考试,可以是融入平时的多次抽查中,也可以罗列各类课程统考时间安排表,学生学习到一定程度,可以报名参加考试,来检验自己知识的掌握程度,形式可以通过实践不断总结,不断改进。总之,有助于学生更有效掌握知识、能打开学生智门的方法就是好方法。
学生通过考试,当然需要有一系列学分累积机制,最好将理论课程和实践课程按不同学分比例分别统计,保证不同学科对理论和实际操作的要求不同。
这样的机制,对教师的要求不是低了,而是更高。要求教师积极思考,寻找能与学生更好沟通,激活学生心智的钥匙,这是没有一个统一模式可循的,教师也必须不断摸索、创新。
有了这种师生一对一、一对多、多对多的关系机制,学生与教师之间的距离不是远了,而是更近了,社会也会更和谐。因为从教师的角度来说,必须了解学生,走近学生,才能找出适合他们学习自嘶方法,才能激活他们的学习兴趣;从学生的角度来说,有问题、有心结就可以及时与他们所喜欢的教师沟通、请教,尽快排除障碍,琢磨出适合自己学习的好方法。要使学生学习效果好,教师与学生是一个整体,只有双方的努力、协调,才能找到最佳的教学方法。
如果学生太多,老师顾及不了怎么办?老师可以到学校与学生面对面的谈话,也可以出现在各种活动场合,如:各类研讨会老师可以当组织者,让学生大家来准备内容、畅通各自的观点,但教师更多的时间可以利用现有的网络环境、3G环境,老师可以规定时间在网上,利用视频、语音交流与学生好似面对面的交谈,也可以利用手机、短信等的形式及时进行一些师生对话。不远的将来电脑、手机、电视三网合一,利用任何IT工具都可以及时沟通,现代科学技术的发展已经具备了技术上的条件,问题是我们需要寻找到一系列行之有效的方法来强化师生间的沟通。
放在云架构内的这些教学资源,随着不断的更新、增加,必将成为一笔极大的资源财富,不仅可以供在校学生学 习使用,也可以提供给全社会需要再学习、需要更新知识的人士使用,为全社会形成一种不断学习的氛围,提供一个强大的资源保障。
一旦形成全社会不断学习的风气,社会就会和谐,文明程度的程度就会不断提高,人们的创新意识和能力就有了源动力,人们就会从更多的追求物质财富逐步进入追求精神财富,那么社会的发展也就更稳健。
随着社会的进步,我们应该摸索和寻找一种更理性和有利于学生身心健康的教学体制,让学习者获得获取知识的乐趣,让教师真正成为学生的良师益友。
人类发展方向是朝着地球村的方向发展。我们开始可以建立教学资源的私有云,局部范围的试点,逐步扩大范围,最终使我们的教学资源转而成为全社会的财富。
我们国家的教育资源本来就不够,建立了多媒体教学资源库后,既可以缩小东西部教育差距,又能保障教育资源的均衡发展,我们何乐而不为呢?
一、引言
随着信息技术的飞速发展，软件产品的规模也越来越庞大，个人单打独斗的作坊式开发方式已经越来越不适应发展的需要。各软件企业都在积极将软件项目管理引入开发活动中，对开发实行有效的管理。我公司是西安一家中型软件企业，在公司中已经实行了项目管理制度，软件项目管理是整个项目管理中的一个重要组成部分。
从概念上讲，软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展（即减小开发风险）。
软件开发不同于其他产品的制造，软件的整个过程都是设计过程（没有制造过程）；另外，软件开发不需要使用大量的物质资源，而主要是人力资源；并且，软件开发的产品只是程序代码和技术文件，并没有其他的物质结果。基于上述特点，软件项目管理与其他项目管理相比，有很大的独特性。
二、软件项目管理的组织模式
软件项目可以是一个单独的开发项目，也可以与产品项目组成一个完整的软件产品项目。如果是订单开发，则成立软件项目组即可；如果是产品开发，需成立软件项目组和产品项目（负责市场调研和销售），组成软件产品项目组。
公司实行项目管理时，首先要成立项目管理委员会，项目管理委员会下设项目管理小组、项目评审小组和软件产品项目组。
1、项目管理委员会
项目管理委员会是公司项目管理的最高决策机构，一般由公司总经理、副总经理组成。主要职责如下：
（1）依照项目管理相关制度，管理项目；
（2）监督项目管理相关制度的执行；
（3）对项目立项、项目撤消进行决策；
（4）任命项目管理小组组长、项目评审委员会主任、项目组组长.
2、项目管理小组
项目管理小组对项目管理委员会负责，一般由公司管理人员组成。主要职责如下：
（1）草拟项目管理的各项制度；
（2）组织项目阶段评审；
（3）保存项目过程中的相关文件和数据；
（4）为优化项目管理提出建议。
3、项目评审小组
项目评审小组对项目管理委员会负责，可下设开发评审小组和产品评审小组，一般由公司技术专家和市场专家组成。主要职责如下：
（1）对项目可行性报告进行评审；
（2）对市场计划和阶段报告进行评审；
（3）对开发计划和阶段报告进行评审；
（4）项目结束时，对项目总结报告进行评审。
4、软件产品项目组
软件产品项目组对项目管理委员会负责，可下设软件项目组和产品项目组。软件项目组和产品项目组分别设开发经理和产品经理。成员一般由公司技术人员和市场人员构成。主要职责是：根据项目管理委员会的安排具体负责项目的软件开发和市场调研及销售工作。
三、软件项目管理的内容
从软件工程的角度讲，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。不论是作坊式开发，还是团队协作开发，这六个阶段都是不可缺少的。
根据公司实际情况，公司在进行软件项目管理时，重点将软件配置管理、软件质量管理、软件风险管理及开发人员管理四方面内容导入软件开发的整个阶段。
在八十年代初，著名软件工程专家B.W.Boehm总结出了软件开发时需遵循的七条基本原则，同样，我们在进行软件项目管理时，也应该遵循这七条原则。它们是：
（1）用分阶段的生命周期计划严格管理；
（2）坚持进行阶段评审；
（3）实行严格的产品控制；
（4）采用现代程序设计技术；
（5）结果应能够清楚地审查；
（6）开发小组地人员应该少而精；
（7）承认不断改进软件工程实践地必要性。
四、编写《软件项目计划书》
项目组成立的第一件事是编写《软件项目计划书》，在计划书中描述开发日程安排、资源需求、项目管理等各项情况的大体内容。计划书主要向公司各相关人员发放，使他们大体了解该软件项目的情况。对于计划书的每个内容，都应有相应具体实施手册，这些手册是供项目组相关成员使用的。
《软件项目计划书》一般应该包括下述内容：
1.引言
1.1计划的目的
1.2项目的范围和目标
1.2.1范围描述
1.2.2主要功能
1.2.3性能
1.2.4管理和技术约束
2.项目估算
2.1使用的历史数据
2.2使用的评估技术
2.3工作量、成本、时间估算
3.风险管理战略
3.1风险识别
3.2有关风险的讨论
3.3风险管理计划
3.3.1风险计划
3.3.2风险监视
3.3.3风险
管理
4.日程
4.1项目工作分解结构
4.2时限图(甘特图)
4.3资源表
5.项目资源
5.1人员
5.2硬件和软件
5.3特别资源
6.人员组织
6.1组织结构
6.2管理报告
7.跟踪和控制机制
7.1质量保证和控制
7.2变化管理和控制
8.附录五、软件配置管理
是否进行配置管理与软件的规模有关，软件的规模越大，配置管理就显得越重要。软件配置管理简称SCM（SoftwareConfiguratioManagement的缩写），是在团队开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。
1、目前软件开发中面临的问题
。在有限的时间、资金内，要满足不断增长的软件产品质量要求；
。开发的环境日益复杂，代码共享日益困难，需跨越的平台增多；
。程序的规模越来越大；
。软件的重用性需要提高；
。软件的维护越来越困难。
2、软件配置管理应提供的功能
在ISO9000.3中，对配置管理系统的功能作了如下描述：
。唯一地标识每个软件项的版本；
。标识共同构成一完整产品的特定版本的每一软件项的版本；
。控制由两个或多个独立工作的人员同时对一给定软件项的更新；
。控制由两个或多个独立工作的人员同时对一给定软件项的更新；
。按要求在一个或多个位置对复杂产品的更新进行协调；
。标识并跟踪所有的措施和更改；这些措施和更改是在从开始直到放行期间，由于更改请求或问题引起的。
3、版本管理
软件配置管理分为版本管理、问题跟踪和建立管理三个部分，其中版本管理是基础。版本管理应完成以下主要任务：
。建立项目；
。重构任何修订版的某一项或某一文件；
。利用加锁技术防止覆盖；
。当增加一个修订版时要求输入变更描述；
。提供比较任意两个修订版的使用工具；
。采用增量存储方式；
。提供对修订版历史和锁定状态的报告功能；
。提供归并功能；
。允许在任何时候重构任何版本；
。权限的设置；
。晋升模型的建立；
。提供各种报告。
4、配置管理软件PVC6.0
PVCS6.0是一套非常优秀的配置管理软件，它能够实现配置管理中的各项要求，并且能和多种流行开发平台集成，为配置管理提供了很大的方便。
六、软件质量管理
随着软件开发的规模越来越大，软件的质量问题显得越来越突出。软件质量的控制不单单是一个软件测试问题，在软件开发的所有阶段都应该引入质量管理。我公司除加强了国家标准"信息技术软件生存期过程"（GB/T8566--1995）的规范管理外，还积极为通过ISO9000.3做准备。
1、软件质量保证计划
在进行软件开发前，需要有一个《软件质量保证计划》。目前较常用的是AI/IEEETOL
730--1984，983--1986标准，包括以下内容：
1.计划目的
2.参考文献
3.管理
3.1.组织
3.2.任务
3.3.责任
4.文档
4.1.目的
4.2.要求的软件工程文档
4.3.其他文档
5.标准和约定
5.1.目的
5.2.约定
6.评审和审计
6.1.目的
6.2.评审要求
6.2.1.软件需求的评审
6.2.2.设计评审
6.2.3.软件验证和确认评审
6.2.4.功能评审
6.2.5.物理评审
6.2.6.内部过程评审
6.2.7.管理评审
7.测试
8.问题报告和改正活动
9.工具、技术和方法
10.媒体控制
11.供应者控制
12.记录、收集、维护和保密
13.培训
14.风险管理
2、质量管理的基本原则
。控制所有过程的质量；
。过程控制的出发点是预防不合格；
。质量管理的中心任务是建立并实施文件化的质量体系；
。持续的质量改进；
。有效的质量体系应满足顾客和组织内部双方的需要和利益；
。定期评价质量体系；
。搞好质量管理关键在于领导。
3、软件质量因素
正确性：系统满足规格说明和用户目标的程度，即，在预定环境下能正确地完成预期功能的程度。
健壮性：在硬件发生故障、输入的数据无效或操作错误等意外环
境下，系统能做出适当响应的程度。
效率：为了完成预定的功能，系统需要的计算资源的多少。
完整性（安全性）：对未经授权的人使用软件或数据的企图，系统能过控制（禁止）的程度。
可用性：系统在完成预定应该完成的功能时另人满意的程度。
风险：按预定的成本和进度把系统开发出来，并且为用户所满意的概率。
可理解性：理解和使用该系统的容易程度。
可维修性：诊断和改正在运行现场发现的错误所需要的工作量的大小。
灵活性（适应性）：修改或改进正在运行的系统需要的工作量的多少。
可测试性：软件容易测试的程度。
可移植性：把程序从一种硬件配置和（或）软件系统环境转移到另一种配置和环境时，需要的工作量多少。有一种定量度量的方法是：用原来程序设计和调试的成本除移植时需用的费用。
可再用性：再其他应用中该程序可以被再次使用的程度（或范围）。
互运行性：把该系统和另一个系统结合起来需要的工作量的多少。
4、软件评审
软件评审并不是在软件开发完毕后进行评审，而是在软件开发的各个阶段都要进行评审。因为在软件开发的各个阶段都可能产生错误，如果这些错误不及时发现并纠正，会不断地扩大，最后可能导致开
发的失败。下面这组数据可以清楚的看出前期的错误对后期的影响。
软件评审是相当重要的工作，也是目前国内开发最不重视的工作。
（1）评审目标
。发现任何形式表现的软件功能、逻辑或实现方面的错误；
。通过评审验证软件的需求；
。保证软件按预先定义的标准表示；
。已获得的软件是以统一的方式开发的；
。使项目更容易管理。
（2）评审过程
A、召开评审会议：一般应有3至5人参加，会前每个参加者做好准备，评审会每次一般不超过2小时。
B、会议结束使必须做出以下决策之一：接受该产品，不需做修改；由于错误严重，拒绝接受；暂时接受该产品。
C、评审报告与记录；所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，另外必须完成评审简要报告。
（3）评审准则
。评审产品，而不是评审设计者（不能使设计者有任何压力）；
。会场要有良好的气氛；
。建立议事日程并维持它（会议不能脱离主题）；
。限制争论与反驳（评审会不是为了解决问题，而是为了发现问题；
。指明问题范围，而不是解决提到的问题；
。展示记录（最好有黑板，将问题随时写在黑板上）；
。限制会议人数和坚持会前准备工作；
。对每个被评审的产品要尽力评审清单（帮助评审人员思考）；
。对每个正式技术评审分配资源和时间进度表；
。对全部评审人员进行必要的培训；
。
及早地对自己地评审做评审（对评审准则的评审）。5、ISO9000.3软件质量认证体系
ISO9000.3是ISO9000质量体系认证中关于计算机软件质量管理和质量保证标准部分。它从管理职责、质量体系、合同评审、设计控制、文件和资料控制、采购、顾客提供产品的控制、产品标识和可追溯性、过程控制、检验和试验、检验/测量和试验设备的控制、检验和试验状态、不合格品的控制、纠正和预防措施、搬运/贮存/包装/防护和交付、质量记录的控制、内部质量审核、培训、服务、统计系统等二个方面对软件质量进行了要求。
6、测试
软件测试是软件开发的一个重要环节，同时也是软件质量保证的一个重要环节。所谓测试就是用已知的输入在已知环境中动态地执行系统（或系统的部件）。测试一般包括单元测试、模块测试、集成测试和系统测试。如果测试结果与预期结果不一致，则很可能是发现了系统中的错误，测试过程中将产生下述基本文档：
（1）测试计划：确定测试范围、方法、和需要的资源等。
（2）测试过程：详细描述和每个测试方案有关的测试步骤和数据（包括测试数据及预期的结果）。
（3）测试结果：把每次测试运行的结果归入文档，如果运行出错，则应产生问题报告，并且必须经过调试解决所发现的问题。测试结果：把每次测试运行的结果归入文档，如果运行出错，则应产生问题报告，并且必须经过调试解决所发现的问题。
七、软件风险管理
软件项目管理存在着风险，如果我们提前重视风险，并且有所防范，就可以最大限度减少风险的发生。进行风险管理是有效的手段。
1、风险的分类
根据风险内容，我们可以将风险分为项目风险（成本提高，时间延长等）、技术风险（技术不成熟等）、商业风险（销售问题等）、战略风险（公司的经营战略发生了变化）、管理风险（公司管理人员是否成熟等）、预算风险（预算是否准确等）等。
另外，我们还可以将风险分为已知风险（如员工离职等）、可预报风险（从以往经验得出可能有风险的）和不可预知风险。
2、风险的识别
风险识别的有效方法是建立风险项目检查表。主要涉及以下几方面检查：
。产品规模风险检查
。业务影响风险检查
。与客户相关的风险检查
。过程风险检查
。技术风险检查
。开发环境风险检查
。与人员的模式和经验有关的风险检查
3、风险评估
风险评估主要从下面七个方面进行：
。发生的可能性
。发生的结果（影响）
。建立一个尺度表示风险可能性（如，极罕见、罕见、普通、可能、极可能）
。描述风险带来的后果
。估计对产品和项目的影响
。确定风险评估的正确性
。根据影响排定有限队列
另外，要对每个风险的表现、范围、时间做出尽量准确的判断。
4、风险的评价
对风险的评价主要依据三个因素：风险描述、风险概率和风险影响。从成本、进度及性能三个方面对风险进行评价。确定项目的中止点，在中止点出再一次进行风险评价。
5、风险的驾驭和监控
风险的驾驭与监控主要要靠管理者的经验来实施。如，某开发人员的离职概率是0.7，离职后会对项目造成一定的影响，则该风险驾驭和监控的策略如下：
。与在职人员协商，确定流动原因。
。在项目开始前，把环节这些流动原因的工作列入风险驾驭计划。
。项目开始时，作好人是会流动的准备，采取一些措施确保人员一旦离开时，项目仍能继续。
。制定文档标准，并建立一种机制，保证文档及时产生。
。对所有工作进行细微详审，使更多人能够按计划进度完成自己的工作。
。对每个关键性技术人员培养后备人员。
在考虑风险成本之后，决定是否采用上述策略。
八、人员管理
1、对项目经理的要求
。能够使小组每个成员都能发挥能力
。有一定的组织能力
。能够使小组美味成员有成就感
。有提出解决问题方案的能力
。对问题的理解有一定的深度
。要能让成员知道软件质量的重要性
2、人员的通讯方式
（1）正式非个人方式，如正式会议等；
（2）正式个人之间交流，如成员之间的正式讨论等（一般不形成决议）；
（3）非正式个人之间交流，如个人之间的自由交流等；
（4）电子通讯，如E-MAIL（电子邮件）、（电子公告板系统）等；
（5）成员网络，如成员与小组之外或公司之外有经验的相关人员进行交流；
在实践中发现，（5）的通讯效率最高，其次是（1）。“文秘站”版权所有
人力资源管理中的风险管理
在进行人力资源管理时，我们往往重视招聘、培训、考评、薪资等各个具体内容的操作，而忽视了其中的风险管理问题。其实，每个企业在人事管理中都可能遇到风险，如招聘失败、新政策引起员工不满、技术骨干突然离职等等，这些事件会影响公司的正常运转，甚至会对公司造成致命的打击。如何防范这些风险的发生，是我们应该研究的问题。特别是高新技术企业，由于对人的依赖更大，所以更需要重视人力资源管理中的风险管理。
一 项目管理过程
一个软件项目的管理过程包括以下几个方面的内容:
1 启动一个软件项目
软件人员和用户是在系统工程阶段确定项目的目标和范围。目标标明了软件项目的目的但不涉及如何去达到这些目的。范围标明了软件要实现的基本功能,并尽量以定量的方式界定这些功能。
2 度量
进行度量工作,是为了帮助软件人员了解产品开发的技术过程和产品。度量的作用是为了有效地定量地进行管理。度量的目的是为了把握软件工程过程的实际情况和它所产生的产品质量。
3 估算
在软件项目管理过程中一个关键的活动是制定项目计划。在做计划时,必须就需要的人力、项目持续时间、成本作出估算。现在有许多用于软件开发的估算技术,基本的步骤是:事先建立软件的工作范围;以软件度量为基础作出估算;把项目分解成科单独进行估算的小块。管理人员可使用各种估算技术 。
4 风险分析
每当开始一个新的软件项目时,总是存在着某些不确定性。如是否能准确地理解用户的要求?项目的功能能否实现?是否存在目前还未发现的技术难题?等等。风险分析对于软件项目管理是决定性的。
5 进度安排
每一个软件项目都要求制定一个进度安排,但不是所有的进度都得一样安排。软件项目的进度安排与任何一个工程项目的进度安排没有实质上的不同。首先识别一组项目任务,再建立任务之间的相互关联,然后估算各个任务的工作量,分配人力和其他资源,制定进度时序。
6 追踪和控制
一旦建立了开发进度安排,就可以开始着手追踪和控制活动。由项目管理人员负责追踪在进度中标明的每一个任务。如果任务实际完成日期滞后于进度安排,则管理人员可以使用一种自动的项目进度安排工具来确定在项目中间里程碑上进度误期所造成的影响。
二 软件项目的组织与计划
1 软件项目管理的特点
软件产品与其他任何产业的产品不同,它是无形的,完全没有物理属性,但它确实是把思想、概念、算法、流程、组织、效率、优化等融合在一起了。因此对软件项目进行管理,涉及到系统工程学、统计学、心理学、社会学以及法律等方面的问题。需要用到多方面的综合知识,仅靠技术或科研项目的效率很难得到较好的解决。此外,管理技术的基础是实践,为取得管理技术的成果必须反复实践。很显然,管理能够带来效率,能够赢得时间。在技术迅速发展的今天,必须认真对待技术管理问题。总之,软件项目的组织涉及到软件项目研制中的计划制定、进度估计、资源使用、人员配备、组织机构和管理方法等软件管理的许多问题。
2 制定计划
软件开发项目的计划涉及到实施项目的各个环节,带有全局的性质。计划的合理性和准确性往往关系着项目的成败。计划应力求完备,要考虑到一些未知因素和不确定因素,考虑到可能的修改。计划应力求准确,尽可能提高所依据数据的可靠程度。
三 软件过程成熟度
多年来软件开发项目存在着不能如期完成,软件质量不能令客户满意或软件开发的开销超出预算等,这些都是软件开发机构遇到的难题。这一现象促使人们进一步考察软件过程,从而发现,关键问题在于软件过程的管理不尽人意。在无规则和混乱的管理条件下,先进的技术和工具并不能发挥应有的作用。改进软件过程的管理是解决上述难题的突破口。
对于不同的软件开发机构,在组织人员完成软件项目中所依据的管理策略有很大差别,因而软件项目所遵循的软件过程也有很大差别。在此,可用软件机构的成熟度加以区别。
成熟的软件机构具有的特点是:建立了机构级的软件开发和维护过程;软件过程必要时可做改进;软件产品的质量和客户对软件产品的满意程度是由负责质量保证的经理负责监控;项目进度和预算是根据以往项目取得的实践经验确定因而比较符合实际情况。
四 小结
为使软件项目开发获得成功,必须对软件开发项目的工作范围、可能遇到的风险、需要的资源、要实现的任务、经历的过程、花费的成本以及进度安排等做到了如指掌,而软件项目管理可以提供这些信息。
购物车(0)
