软件项目管理方法（共12篇）
软件项目管理方法 篇1
随着社会的进步以及经济的发展, 软件的规模不断加大, 其复杂度也在不断提高, 导致软件的开发与过程管理困难重重, 软件项目出现成本超支、进度拖延以及质量较低等情况。就目前而言, 中小软件企业在软件过程管理中, 其存在一系列的问题, 如难以控制任务完成进度, 难以控制需求, 软件质量难以控制, 软件版本混乱等, 导致软件质量和交付受到严重影响, 降低了软件的满意度。为了有效改变这种现状, 中小软件企业对软件过程改进、管理以及规范等方面采取了辅助手段, 如CMM/CMMI认证、质量管理体系的建立等, 从而促进中小软件企业的可持续发展。
1 中小软件企业软件过程管理概述
1.1 中小软件企业特点分析
在我国软件产业中, 中小软件企业占据着较大的比例, 其主要特点是熟悉行业需求, 能够对优势业务领域加以有效把握, 执行力高, 管理快捷清晰, 组织结构简洁, 响应速度快等。但是中小软件企业也存在一定的劣势, 其具有较高的维护成本, 总收入中软件销售收入占据的比例低, 经验到制度的转化程度不高, 依赖性强, 制度约束力不高, 人员流动性高以及人力资源不足等。
1.2 软件过程概念
软件过程主要指的是软件开发人员在对软件以及相关的产品进行开发与维护时, 其形成的方法、实践、行为以及变化过程。一般在对软件过程进行管理时, 必须要确保软件产品的质量, 加强其开发与维护过程的质量, 将方法, 工具以及人员进行有机结合, 从而确保软件产品的质量, 提高管理的水平。
2 中下软件企业软件过程管理的改进方法
2.1 加强质量保证与配置管理
一个软件项目的配置项包括该项目的所有相关资料, 如安装程序、工具、代码以及文档等, 配置管理良好是保证软件一致性的重要前提。因此对配置管理进行合理计划, 并对配置管理软件进行恰当选择, 统一管理软件版本, 制定基线配置项变更控制流程, 能够确保软件开发与管理过程的合理性, 提高软件过程管理以及软件产品的质量。在改进软件过程时, 中小软件企业可以从以下几个方面进行考虑:一是在对软件进行测试时, 侧重于控制和检查软件产品的质量, 并且在保证质量的同时, 严格检查和控制软件过程。二是质量保证由专人进行, 从项目计划以及阶段成果等方面进行检测, 对质量问题进行跟踪和记录, 从而有效提高软件产品的质量, 确保产品质量的维护性以及延续性。
2.2 选择重点, 优先突破
在对软件过程进行改进时, 必须要对其重点领域进行选择, 循序渐进。由于软件过程改进是对现有的软件开发与管理过程进行改善, 这对于企业管理人员以及开发人员而言, 具有较大的难度。因此在软件过程改进过程中, 企业可以有针对性地选择改进重点, 逐渐突破, 从而确保软件改进过程的合理性以及科学性。此外, 从软件开发过程而言, 软件企业不同, 使得软件项目开发的过程也不尽相同, 在软件开发过程中, 其编码、设计以及需求等阶段受企业开发人员的综合能力、知识经验以及企业自身的技术水平的影响, 因此必须要对软件过程的相关部分进行重点选择, 有效突破。
2.3 加强自评估
中小软件企业为了保证软件过程的完整性以及规范性, 往往会对软件过程进行盲目改进, 无法对自身软件过程的阶段和水平进行全面清晰的分析, 导致实施的效果低下。因此, 中小软件企业在对自身的软件过程进行改进时, 必须要加强自评估, 有效采用某磐软件度量方法, 利用定量和定性相结合的方式, 提高软件过程状态的评价。此外, 中小软件企业可以在组织内部对岗位的人员进行不同选择, 确保全体人员能够参与到软件的评估过程中, 从而保证软件过程的合理性和准确性。
2.4 重视个体软件过程改进
开发人员作为软件企业中的主体, 其工作计划的恰当性、缺陷率、时间利用率和编码质量的高低等都会影响组织软件过程和软件质量。因此为了提高开发人员的工作效率, 确保软件过程的管理质量, 必须要重视个体软件过程的改进工作。一般个体软件过程具有完整的规程、表格以及方法, 其能够对软件开发人员的工作方式进行改进、管理和控制, 对开发人员计划、管理和度量自身的工作具有指导作用。个体软件过程改进能够对时间利用的情况进行记录, 从而有效掌握时间利用率以及工作的效率;同时能够利用管理缺陷, 有效控制软件缺陷, 并提高相关人员的工作能力。
2.5 合理利用辅助工具
一般而言, 软件过程管理及其改进在很大程度上属于管理的过程, 需要遵守一定的规则, 充分合理利辅助工具, 能够有效提高软件过程管理的水平和质量。就目前而言, 软件企业常用的软件类别包括缺陷管理工具、软件测试工具、配置管理工具以及项目管理工具等, 这些工具具有完善和强大的功能。因此企业能够从自身的实际情况出发, 对这些软件工具进行合理选择与利用, 从而提高软件过程管理的水平, 增强企业的综合竞争实力, 实现企业的可持续发展。
3 结束语
一般来说, 软件过程改进是一个循序渐进的过程, 中小软件企业必须要不断积累和丰富自身的经验, 对软件过程管理进行持续改进。同时, 中小软件企业在对软件过程进行管理和改进时, 必须要加强质量保证与配置管理, 选择重点, 优先突破, 加强自评估, 重视个体软件过程改进, 合理利用辅助工具, 从而提高软件过程管理的水平, 实现自身的可持续发展。
参考文献
[1]楚书来, 于文新.小规模软件企业软件过程管理与改进策略研究[J].黑龙江科技信息, 2012, 02:199-200.
[2]田丽从, 李铁牛, 彭宏.中小型企业软件过程改进方法研究[J].计算机应用与软件, 2011, 04:208-211.
[3]李楠.我国中小软件企业实施CMM改进软件过程的研究[J].中国城市经济, 2011, 26:129-130.
[4]马小龙.一种中小型软件企业软件过程改进框架研究[J].电脑与电信, 2010, 10:38-39.
软件项目管理方法 篇2
对企业需求的描述可以从2个方面来进行描述，一个方面是对客户现行系统的描述，一个方面是对系统未来的设想。总的而言，无论是从那个方面来描述，构成企业信息系统主要包括5个基本要素：企业的组织结构、流程、数据、商务规则与功能（性能）。其中从用户的角度主要关注流程，是以流程为核心的，通过流程将其他几个要素贯穿起来，需求分析人员也应该从这个角度来和用户沟通；从开发者的角度主要关注企业的数据、商务规则与功能，以便于系统的实现；从实施者的角度主要关注企业的组织结构与功能，以便于系统的发布与实施。
1）企业的组织模型
即企业的组织结构关系，包括部门设置、岗位设置、岗位职责等。树型组织结构图是描述企业的组织模型的一种常用方法，它可用来搞清各部门之间的领导关系,每个部门内部的人员配备情况, 职责分工等情况,它是划分系统范围,进行系统网络规划的基础。在组织结构图中应将用户的组织结构逐层详细描述，每个部门的职责也应进行简单的描述。组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围具有很好的帮助。取得用户的组织结构图，是需求获取步骤中的基础工作之一。
用户环境中的企业岗位或角色，和组织机构一样，也是分析人员理解企业业务的基础，也是分析人员提取对象的基础。
对用户角色的识别常常遗漏的是计算机系统的系统管理人员，角色识别不全，对以后的功能识别会造成盲区。
2）企业的流程模型
即企业的业务流程，包含哪些流程、流程之间的关系、每个流程中包括哪些活动、每个活动涉及到的岗位。企业的作业流程首先要有一个总的业务流程图，将企业中各种业务之间的关系描述出来，然后对每种业务进行详细的描述，使业务流程与部门职责结合起来。详细业务流程图可以采用直式业务流程图形式。对企业而言需要定义关于业务流程图的描述标准，大家采用相同的图例来描述，便于管理。
业务流程图的优点 :
■ 绘图的过程,实际上是作业流程条理化的过程
■表达形象直观,易于和用户交流,易于项目组内部交流调研的结果,需要得到用户的认同,这就需要和用户交流调研的结果,交流的文档要通俗、易懂, 不能采用专业术语。
■可以作为培训实施人员与技术服务人员的文档
业务流程图的缺点 :
■对高层管理人员的实际需求调查的不清楚.这一方面是由于用户没有接触过计算机, 对采用计算机后的管理会是什么样子?计算机能够完成当前手工操作的哪些内容?能够作哪些现在手工无法完成的工作等等没有清楚的概念,因此用户无法将这些问题反应出来.另一方面说明分析人员没有经验,对原始材料挖掘不深,不能从用户提供的材料中提炼处来用户的真正需求,不能找到当前管理中的问题。
■对各种业务之间的总体关系没有表达出来.采用直式业务流程图可以将企业的每一种业务的处理流程清楚地表达出来, 但是各业务之间的联系却没有表示出来,单看一种业务的流程图很清楚,但是却不能综合在一起,没有整体的概念,作为需求分析的文档,在这方面表达的不够完整。
■在不利用工具的情况下,画法烦琐。图形可以将流程描述的很清楚，但是还要附加以一些文字说明，如关于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述出的内容，需要用文字进行详细描述。
3）企业的数据模型
即企业中的信息载体有哪些？以及对这些信息载体的详细刻画，包括企业的各种单据、帐本、报表的描述。在需求报告中，应该将单据的描述格式化，需要描述的内容包括：
单据的用途，即单据用在什么地方？
单据的格式：需要明确的画出来，并有实际的有数据的样例，能够具体直观地说明问题； 单据中的数据项的具体描述：长度、类型、计算生成方法、约束条件等；
单据的数据项是由哪些不同类型的角色来填写地，包括用计算机可以填那些数据项。单据中哪些数据是必填的，哪些是可以不用填的。
单据流量：平均每天产生多少条记录，高峰期的数量；
单据的分类：可以从多个角度上进行分类，如：按业务类型来分类（采购/销售/生产），按生成的方式来分类（手工录入型/自动生成型），按格式变化的频繁程度来分类（易变型/稳定型），按表现形式来分类（列表型/卡片型）等等。
单据之间的关系：引用关系等等。
同样对于需要的报表与帐本也可以参照上面的条目进行详细的刻画。
4）企业的商务规则模型
即企业中的商务规则有哪些?这些规则用在哪些地方? 商务规则可以从影响的范围划分为2类：一类是局部的规则，如不允许出现负库存，一类是整体的规则，如对所有的物料管理到批次。商务规则一般是隐藏在功能模型或者流程模型中，不需要单独描述，但是有些复杂的商务规则是需要单独抽取出来描述，如企业的各种单据记帐的商务逻辑，5）企业的功能模型
功能需求是用户的最主要的需求，对用户功能需求的描述可以采用文字描述也可以采用语言加图形的描述方式，只要能够将用户的需求描述地完整、准确、易于理解即可。对功能需求比较复杂的系统（如超过10个功能项），可以先描述一个概要，对简单的系统可以直接进行详细描述。对于用户的功能需求要进行分类，分类的方法应便于用户理解，如按照用户的部门设置情况，进行描述每个部门的需求，这样也便于组织用户进行评审。以下是分类方法的举例：
按部门分类：如采购科、销售科、计划科、生产车间、财务科、统计科、总经理等； 按功能类型分类：如单据录入、单据审核、单据查询、记帐、帐本查询、统计报表、系统维护等。
对功能需求的分类在不同的层次可以采用不同的方法。
对每一项功能应有一个功能编号，以便于与功能规格说明书中的章节进行对应。对每一项功能的描述，应指明用户的输入(input)、处理方法（process）、系统的输出(output)及对此项功能的其他要求。功能需求还应注明使用此功能的岗位。对系统管理员要求的特殊功能可以在此注明，非特殊要求可以在需求分析规格说明书中详细论述。如用户权限可分级，要有操作日志等。
功能需求与性能需求是密不可分的，笼统的性能需求没有任何意思，必须具体到某项功能需求上来，这是分析人员在分析系统时容易忽略的一项。
对上述的5个基本元素可以将他们描述为一个五元组〈组织，流程，功能，数据，业务逻辑〉，对于用户来讲，他们习惯于从组织维来看待系统，即某个部门有哪些岗位，每个岗位参与了哪些流程的哪些活动（功能），在某个功能上操作了哪些数据，对这些数据进行了哪些逻辑处理；对于开发人员习惯于从功能维来看待系统，即某个功能操作了哪些数据，对这些数据进行了哪些逻辑处理，这个功能属于哪个流程，可以由哪些岗位来使用；对于设计人员可能习惯于从数据维来看待系统：即系统中有哪些数据，在这些数据上可以做哪些处理，这些处理用OO的思想来看即是对数据对象的操作。
对以上的5个基本元素进行描述实际上就是系统建模的过程，为确保模型的可操作性，除了上面的5个基本要素外，还需要重点描述的内容有：
（1）新系统对应用模式带来的变化包括对企业的组织结构、作业流程、单据帐本报表等的格式、商务规则等的改变。
（2）新系统的界面模型
用开发工具将用户操作界面快速画出来，使用户心中有数。若时间允许，可将界面原型与数据库表、字段连接起来，真正做出系统雏形，即快速原型法。阅读需求文档的4类读者
需求报告的最终目的是给人来阅读的，所以一定要考虑需求报告的读者群，有4类角色可能阅读企业管理系统的需求文档：
客户与用户业务高层；
用户的中层管理人员与具体人员；
用户IT主管与开发人员，包括设计人员、编码人员、同行的专家；
项目管理人员：包括项目经理、质量保证人员、测试人员、需求管理员、配置管理员、计划人员等等；
不同的读者对文档的阅读需求是不同的，他们关注的信息是不同的。我见过了很多次需求评审的失败（如果做好需求评审我会另外再撰文描述），总结下来我认为和需求描述没有区分读者群是很有关系的。针对上述的4种分类，我们具体的来分析一下每类读者的特点：
（1）客户与用户业务高层
他们关心的企业是系统的目标性需求，关心的是系统总体的功能框架，关心的是系统解决了哪些管理问题，对具体的需求是不关心的，所以给他们阅读的文档应该是从总体上来描述，要高度抽象。由于他们的工作很忙，很难有比较长的时间来读这些材料，所以要简短明了，能够用1页纸说明问题的就要不要用2页纸，而且一般都要给高层进行需求汇报，需要配上语言说明，因此采用PowerPiont片子也就成了一种常用的方法，讲解需求与讨论一般应掌握不要超过1小时。需求人员常犯的毛病是过多地关注了企业的细节性需求，而忽略系统的目标性需求，所以在安排需求获取的步骤上、需求报告的编写上往往没有抓住企业高层最关心的问题、没有抓住根本性的问题，在给企业的高层汇报时当然很难通过评审。
（2）用户的中层管理人员与具体人员
企业的中层管理人员关注的是企业的局部需求，他们要求对自己的负责的局部系统能够有总体的了解，能够和其他的子系统衔接的很好，业务流程很流畅，覆盖了自己需要的所有业务流程，能够通过系统起到控制作用就行了。具体的操作人员更关心自己的的哪些活动是否在系统中都能处理，软件是否可以很容易地操作，他们关注的焦点更具体，要求更直观。所以对这类的读者可以通过比较详细的文档来描述需求了，当然应该以他们习惯的思维方式来描述，不能从开发人员的角度来描述。我看到过很多几百页的需求文档给用户去阅读、去评审，结果要么用户不置可否，要么直接讲看不懂，为什么呢？一是开发人员在文档中分子系统、分模块、分功能点一层深入下去描述，不符合用户的思维习惯，他们希望能够从业务流程、业务活动的角度来考虑问题，而不是功能；二是太多了，用户也没有时间静下心来去消化、吸收如此多的文档，需求毕竟不是小说，能够那么吸引读者。
（3）用户IT主管与开发人员
包括设计人员、编码人员、同行的专家大多数分析人员可能最擅长的就是些写这类的文档了，往往也是那这类的文档给所有的读者看，其问题我们上边都说了，这里我们就不赘述了。需要注意的是在描述需求时候传统的做法是以功能为主线，来展开描述，实际上如果是以数据为主线来描述需求也是一种很好的办法，在我们上面谈到的五元组中，从数据的角度来分析系统可以更容易实现向OOA、OOD的切换。
（4）项目管理人员：
包括项目经理、质量保证人员、测试人员、需求管理员、配置管理员、计划人员等等把拿给开发人员看的需求文档给管理人员看，这也是分析人员常犯的毛病。管理人员实际上最关心的是需求列表。在此基础上项目经理、质量保证人员可以据此来进入项目策划过程，测试人员可据此进入测试策划过程，需求管理员、配置管理员可以识别配置项制定相关的活动计划。没有这张表管理人员就很难高效地开展他们的管理活动，也就谈不到最基本的需求复用了。在上述的表中，需求的优先级是很重要的一列，对项目经理进行项目管理的平衡决策是很重要的，实际上需求的优先级可能比需求本身更重要。需求描述的表示技巧
上面我们谈到了，需求文档是人与人之间交互的文档，是不同类型的人之间交互的文档，因此需求文档的可读性是一个很重要的方面，为了提高文档的可读性可以借鉴下面的一些做法： 在文档的描述中，适当运用链接，增强文档的可读性；
多用穷举的方式，以便于发现遗漏的需求；
通过适当的换行来提高可读性 ；
采用黑体、斜体、下划线、颜色等多种方式来突出重要内容；
定义标准的术语，以减少二义性，减少文档的页数；
软件项目管理方法 篇3
〔中图分类号〕 G721
〔文献标识码〕 C
〔文章编号〕 1004—0463（2007）07（B）—0039—02
随着计算机在信息管理领域中的普及和推广，计算机财务管理系统已走进了各行各业。然而每个行业、每个单位所具有的不同管理特点以及财务制度的改革所引起的企业财务管理的相应变化，使计算机软件开发人员越来越感到软件维护以及功能模块的二次开发其工作量之大，任务之重叫人难以承受。笔者就如何提高财务管理系统软件可维护性的方法谈一些自己的看法。
一、加强系统用数据库的定义
1.“账簿”名字由系统自动产生
各单位对于正常发生的经济业务，往往通过会计凭证的填制和审核，可以反映和监督这些经济业务的发生和完成情况。但是，一个单位在一定时期的会计凭证很多，每张凭证只能反映一项经济业务，因而会计凭证对经济业务的反映只能是分散的，零星的，不能全面地、联系地、系统地反映一个企业在一定时期内发生的全部经济业务。为了便于了解一个单位在一定时期内的全部经济活动，就必须设置会计账簿。把会计凭证所提供的大量而分散的核算资料加以归类整理，登记到账簿中去，以取得经营管理上所需要的各种核算资料，这种用来全面、连续、系统的记录会计业务，具有专门格式而又相互联系在一起的账页，称为会计账簿。设置和登记账簿是会计核算的一种专门方法。财务管理软件自动产生“账簿”的程序包括两部分内容：建立“账簿”和修改已建立“账簿”的结构。“账簿”名字由字母开头并加会计科目表中一级科目编号组成。文件名开头字母多寡由用户通过屏幕输入。在产生“账簿”之前，应先建立一个“账簿”结构文件，然后根据用户输入的字母及会计科目表，利用文件建立命令或文件拷贝命令自动产生全部一级科目的“账簿”，接着用户根据需要对已建立的文件结构进行修改。虽然建立的数据文件较多(一般企业所使用的一级科目在四十个以上)，但在程序执行中不需要作索引，省去了建立索引的开销，这相对提高了系统的运行速度。由于“账簿”文件名是规范的，与一级科目编号是一一对应的，自然在使用“账簿”的程序中不会直接使用会计科目所对应的文件名。
2．增加会计科目类别字段
建立会计科目是财务管理及会计电算化初始化工作中的重要内容，它主要包括设立科目编号，输入科目名称，定义账户类别等内容。为了消除程序中出现直接的科目编号，在记账凭证输入时，为了满足用户要求，凡是往来科目要求作金额核对处理的，在程序中往往会要用具体的科目编号作为比较对象，根据判断结果决定程序的执行路线。如果往来科目编号改变必须要对程序作相应修改。为了把程序和数据相对独立开来，在定义会计科目表的数据库时增加了科目类别标志字段，用标志字段代替程序中的具体科目编号。这样做到了把业务变化引起的程序修改转到了数据维护上。
会计报表的编制也是财务管理系统中不可缺少的部分。会计报表是根据账簿记录和其他日常核算资料，以一定的指标体系，总括地反映会计主体一定时期内的财务状况、经营成果和理财过程的报告文件。它是会计核算程序的最后环节。编制会计报表是会计核算的一种专门方法。一个单位的经济活动的内容、成果及其财务状况是通过一定的经济指标来揭示的。会计核算的目的，就是要通过对经济业务进行记录、加工、整理、综合、汇总等环节，将会计主体的资产、负债和所有者权益的变动，利润的形成与分配，以及资金的取得和运用等各方面的会计信息，以一定的指标体系，全面、系统、概括地反映出来，以便人们了解其一定时期经济活动的内容、成果和财务状况。在会计核算过程中，会计账簿所提供的会计资料仍然是分散在各类账户中的，不能集中而概括地反映出企业、单位经济活动的全貌。因此，就必须对账簿中的会计资料作进一步的加工、整理、综合，并结合其他日常会计核算资料，按照一定的指标体系，以报告文件的形式集中地反映出来，从而全面、系统、概括地提供会计主体一定时期内经济活动的内容、经营成果和财务状况的信息。在编制会计报表处理中，报表项目的变化会直接引起程序的修改且工作量也较大。这也许正是目前市场上销售的财务管理软件中编制会计报表功能模块分为对用户开放和半开放的原因吧。这里所指的“开放”是指向用户提供源程序，用户在系统运行时遇到报表变化时可由用户完成程序维护。它虽然给用户程序修改的方便，但是销售者不会向用户提供系统设计文档，只能靠用户在阅读源程序、弄清其设计思想、方法之后才可以动手修改，这无疑给用户带来了很大困难，同时也给系统的运行带来了影响。为了做到使用户只修改数据而不修改程序，在编制会计报表的功能模块设计中，可以把报表内容作为系统数据文件，建立了一个报表格式定义数据库，把程序与报表的具体内容分离开来。
二、加强系统初始化功能
会计软件的初始化是指从手工会计系统(或旧的计算机会计软件)转换成电算化会计软件过程中所做的有关初始性工作。这些工作完成后，才可以用会计软件进行日常的会计处理。财务管理软件的初始性是指正式录入记账凭证前应该做的各种前期工作，它包括使用财务处理软件前的手工准备阶段，科目代码的设置，初始余额的装入，运行环境的初始设定等。初始化工作完成后，就可进入正常的计算机日常账务处理阶段，即录入凭证、记账、出账阶段。由于初始化工作是因为使用电算化会计软件引起的，而初始化阶段计算机还不能代替手工做会计核算工作，所以，初始化阶段会增加会计人员的工作量。但初始化工作是非常重要的，初始化工作的好坏，直接影响到以后工作能否顺利进行。
为了避免由于管理制度和方法的变化引起功能模块的二次开发，我们必须加强系统的初始化功能，尽可能地给用户提供自定义窗口。
1.工资结构定义
用户可根据本单位工资结构定义工资项目(包括工资项目名称、类型长度等参数的指定)。因为无论何种工资结构总是包含收入(实发)部分、支出(扣除)部分，从收入部分减去支出部分便是职工的应发部分。系统用表格形式分为收入、支出部分，并按顺序由用户输入信息，这样系统同时也完成了工资的计算公式的定义。
2．工资输出文件项目的指定
一个单位至少有离退休职工和在职职工两种不同的输出报表，用户可以通过自定义窗口，从已定义的工资项目中指定输出报表包含的项目，用户还可根据需要指定所需要的其他报表。如，储蓄发放表、水电费发放表等等。
3．工资分配方式的定义
任何一个单位的工资内容会按月按用途分配到相应的会计科目中去。由于各单位的分配方式略有不同，且分配到核算科目所包括的工资项目也会随工资结构变化而变化。所以在初始化中给用户提供了定义工资分配方式的功能。工资分配的去向大致涉及到以下几个科目(贷方科目)：
(1)基本生产(在建立了厂内银行核算的单位把应分配到该科目的总金额转到厂内银行进行核算)；
(2)辅助生产；
(3)企业管理费；
(4)利润的营业外支出；
(5)專业基金的职工福利、奖励基金；
(6)销售。
软件配置管理简化实施方法 篇4
随着科技的不断发展, 软件项目的复杂性与集成度越来越高, 项目的成败在很大程度上取决于对其开发过程的控制, 包括对质量、源代码、进度、资金、人员等的控制, 有效的过程必须有科学的管理方法, “软件配置管理”是通过技术或行政手段, 对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。实践证明, 软件配置管理是一套规范、高效的软件开发管理方法, 同时也是提高软件质量的重要手段。
1.1 实施软件配置管理, 是提高效率和质量的必要手段
软件研发中出现的每一个问题, 必须及时定位、修改、更新和记录, 配置管理过程中的记录、报告和版本控制, 通过问题跟踪和追溯, 能加快问题的定位和修复, 并最大限度减少缺陷和错误的发生以及再次发生;同时, 在软件编码过程中, 使用配置管理工具, 能够较好的避免因并行开发、多重维护带来的版本混乱、重复编码等问题, 清晰的配置管理过程, 在节约人力的同时, 提高了产品质量。
1.2 实施软件配置管理, 有利于单位建立知识库
软件代码是软件开发人员脑力劳动的结晶, 也是软件开发单位的宝贵财富, 长期开发过程中形成的各种代码对象就像一个个零件坯一样, 是快速生成系统的组成部分。实施配置管理, 能够对各人的有用对象进行管理, 把其使用范围扩大到单位级, 进行规范化并加以说明和普及, 建立单位级的代码对象库;在配置管理中, 形成完整的开发日志及问题集合, 以文字方式伴随开发的整个过程, 不依某个人的转移而消失, 有利于单位积累业务经验, 无论对版本整改或版本升级, 都具有重要的指导作用。
1.3 实施软件配置管理, 能够降低成本, 节约费用
通过软件配置管理, 可以对不同阶段软件代码版本进行管理和跟踪, 建立代码知识库, 提高代码的重用率, 同时最大限度地共享代码, 便于进行新版本或类似功能的开发, 减少再开发的成本, 提高开发效率, 缩短开发周期;通过配置管理, 建立开发管理计划和规范, 共享最新文件和代码, 当项目成员跨地域分布时, 能够实现协同有序, 互不干扰而又不失去控的异地工作, 从而节约大量的旅差费用。
1.4 实施软件配置管理, 是规范管理的要求
通过建立科学的配置管理流程, 将大量的文档和代码等知识财富统一标识, 按阶段进行规范化管理, 避免随意保存在项目经理和软件工程师各自的机器里, 因硬盘故障或人员离职造成数字财富因缺乏必要的配置管理而白白流失。能够应对人员离职、版本混乱、加快问题的定位和修复;通过配置管理规范软件研发各阶段的文档, 进行有效的质量记录和文档管理, 保证每个使用者都能得到正确的版本, 在提高项目研发效率的同时, 也为企业积累了组织级财富, 便于今后的项目共享;软件项目的研制过程是随项目的规模以指数上升, 只有在项目研制之初, 制定项目开发和管理计划, 并在研制过程中, 依照计划实施, 才能避免项目研制过程中的盲目性;代码回溯是软件编制过程中经常发生的, 使用工具进行规范化的配置管理, 每天记录当天代码修改情况, 规范文档和代码每天的版本, 使工作或代码回溯成为轻松便捷的事。
2 简化实施软件配置管理的策略
软件配置的主要工作包括:建立配置管理机构和配置库 (即软件开发库、受控库、产品库, 又称软件三库) 、制定配置管理计划、基线控制、出入库控制、更改控制、配置状态记实、配置审核。本文重点介绍综合性科研单位的软件配置管理工作的简化实施。
2.1 建立配置管理机构和配置库
在项目设计开发期间, 应建立相应的配置管理组织 ( 配置管理委员会或配置管理小组) , 专门负责配置管理工作。项目组应指定专人 (配置管理员) 处理配置管理事务。
配置库也称为软件“三库”, 是软件配置管理机构的组成部分, 包括:开发库、受控库、产品库。开发库存放各开发阶段产生的尚未通过评审的程序、文档等电子版本或纸制资料, 一般由项目组建立并维护;受控库存放已通过测试或评审且作为阶段性产品的软件配置项集合, 包括程序和文档, 一般由研制管理部门 (或质量管理部门) 建立和维护, 受控使用;产品库存放已定型 (鉴定) 且供交付、生产、检验验收的软件配置项集合, 包括源代码、可执行程序、数据和文档的电子版或纸制资料, 一般由组织的技术档案管理部门建立和管理。
三库可以借助专门的配置管理软件建立, 也可以以电子或物理形式建立。例如:受控库可以是一系列电子文件夹, 产品库可以是一组文件柜。如表1 所示。
2.2 制定配置管理计划
配置管理计划的目的在于对所开发的软件规定各种必要的配置管理条款, 从而保障产品质量。内容包括:说明配置管理角色和职责、计划纳入配置管理的配置项、计划的基线时间和内容、配置库的建立方式和授权、配置状态记录和统计计划、更改和版本控制, 并确定项目标识、文档标识、程序和产品标识、版本标识等。
对基线的管理是配置管理的重点内容。基线是软件文档或软件代码的一个稳定版本。是被正式确认并作为今后研制生产、使用保障活动的基准。已形成基线的关键文档, 虽然可以修改, 但必须以一个特殊的、正式的过程进行评估, 确认每一处修改。软件开发项目的配置管理基线包括:功能基线、分配基线、设计基线、开发基线和产品基线。在实际应用中, 根据项目的规模和实际研发情况, 可以只划分功能基线、分配基线和产品基线。基线对应的标志性文档如表2, 每一种基线以通过一定级别的评审后建立。
2.3 配置控制
开发库出入库较频繁, 主要由项目组控制。通常配置控制主要是对受控库和产品库的控制。为了简化实施, 只能涉及基线的配置项目进行控制。
2.3.1 基线控制
在确立基线的标志性评审通过后, 及时将基线文件入库, 此后, 若有对基线文件的使用和修改, 应及时记录并向有关人员发布最新版本。
2.3.2 出入库控制
一般在基线建立后、变更前后和重要事件前后, 要记录配置项出入库。配置项出入受控库或产品库应当填写《出库单》和《入库单》。
2.3.3 更改控制
被更改的源代码和相关文档必须正式取自配置管理的受控库或产品库, 更改后重新入库并填写《配置变更报告单》, 版本的变更, 也应进行记录。
2.3.4 配置状态记实
记录并报告受控软件配置管理项的现行状态和历史。在实施配置变更处理的过程中, 配置项的状态分为:变更中、有效、无效。配置管理者应在一个重要阶段结束时, 及时汇总《配置状态记录单》。
2.3.5 配置审核
在项目研发完成一个阶段或在产品交付前, 应进行功能配置审核和物理配置审核, 功能配置审核以确定和保证配置项的完整性;物理配置审计以检查程序与文档的—致性、文档与文档的—致性、交付的产品与任务书要求的—致性以及与标准规范的—致性。完成审核后, 应填写《配置审核单》。
2.3.6 配置总结
根据配置管理情况, 一般在项目完成时, 编写配置管理报告, 也可以在研制总结中进行配置管理总结, 内容包括:配置管理情况综述、用户组划分及权限分配、配置项记录、基线记录、入库记录、出库记录、变更记录、审核记录、备份记录等。
3 结束语
专业软件开发单位的软件配置管理工作, 一般应达到软件研制能力成熟度模型 (CMM) 3 级或以上标准, 故一般采用专业的配置管理软件实现;对于实施质量管理体系的综合性科研单位的配置管理, 一般达到软件研制能力成熟度模型二级标准即可, 重点记录基线形成和变更、大阶段的配置管理状态和审核, 以及相应的出入库, 可以采用一些版本管理软件辅助实施, 同时制定一系列规则, 以人工辅助部门级配置管理工作。
注:文中提到的配置表单和文档表单, 可参考相关标准中的格式。
摘要：软件配置管理是通过技术或行政手段, 对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。配置管理的主要工作一般包括:建立配置管理机构和软件三库、制定配置管理计划、基线控制、出入库控制、更改控制、配置状态记实、配置审核。根据项目的具体情况, 配置管理的实际工作内容不同。
关键词：软件配置管理,配置管理,软件三库,配置管理简化实施
参考文献
[1]陈焱, 李勇, 韩铁军.配置管理在软件系统开发中的作用[J].自动化指挥与计算机, 2012 (04) .
[2]冯济舟.软件配置管理典型问题的研究与思考[J].航天标准化, 2013 (03) .
[3]刘旭奕.基于GJB5235的软件配置管理方法初探[J].标准介绍, 2011 (02) .
[4]高贤志, 戴恒毅.导航装备软件配置管理方法研究与实践[J].装备质量管理, 2012 (08) .
软件项目管理方法 篇5
1.天易成网管监控电脑需要开放TCP：8900端口，其他防火墙类似如下设置：
微软防火墙设置：控制面板-Windows防火墙-高级设置-入站规则-右键-新建规则-选’端口’-选’TCP’-本地特定端口填’8900，其余选默认值，最后起一个名称，完成。
2.在被管理电脑安装天易成内网管理插件：
在天易成官网下载插件后到被管理电脑安装；
3.新建一个内网管理策略：启用内网监控功能。如下图：
4.开始管理，选中要内网管理的电脑-右键-设置策略-选择刚才新建的内网管理策略； 稍等10几秒，安装内网管理的电脑就会显示联机，即可使用企业版功能。
5.插件卸载
浅论软件开发方法 篇6
关键词：软件开发；方法；现状；趋势
一、软件开发方法的现状
1.结构化软件开发方法
（1）面向数据流的结构化软件开发方法
1978年，Yourdon E和Constantine LL提出了结构化软件开发方法，1979年Tom De Marco对此方法作了进一步的完善。该方法用数据流图来表达，根据软件内部数据传递和变换关系，自顶向下逐层分解，描绘出满足功能要求的软件模型，设计阶段依据模块独立性准则、软件结构准则，将数据流图转换为软件的体系结构，用软件结构图来建立系统的物理模型，实现系统的概要设计。此方法适应范围广、开发步骤明确，结构化分析、结构化设计、结构化编程相辅相成，一次完成。
（2）面向数据结构的结构化软件开发方法
1975年Jackson MA提出了Jackson方法——JSP方法。该方法首先描述问题的输入、输出数据结构，分析其对应性，然后推出相应的程序结构从而给出问题的软件过程描述。ISP方法是以数据结构为驱动的，适应于小规模的项目。当输人、输出数据结构无对应关系时，难于应用该方法。基于JSP方法的局限性，又发展了JSD方法，它是JPS方法的扩充。SJD方法是一个完整的系统开发方法，该方法首先建立现实世界的模型，再确定系统的功能需求，对需求的描述特别强调了操作之间的时序性，它以事件作为驱动，是一种基于进程的开发方法，应用于时序特点较强的系统，包括数据处理系统和一些实时控制系统。
Warmer方法是Warmer JD在1974年提出的。Warmer软件开发方法与Jackson方法相比的差别如下：第一，使用的图形工具不同；第二，使用的伪码不同；第三，在构造程序框架时，Warmer方法仅考虑输人数据结构，而Jackson方法不仅考虑输人数据结构，而且还考虑输出数据结构，这点差别也是最主要的差别。
2.面向对象软件开发方法
面向对象软件开发方法包括面向对象分析方法、面向对象设计方法和面向对象实现方法，其核心是面向对象程序设计方法。面向对象程序设计语言的创新发展推动面向对象程序设计方法逐渐形成和完善，从而推动面向对象软件开发方法形成并发展。
在面向对象程序设计方法中，数据和施加在数据上的操作被封装在一起，形成类和对象的概念，用对象分解取代了传统方法的功能分解，所有对象被划分成各种对象类，按照子类与父类的关系组成对象类的层次结构，子类自动继承父类的所有特性，对象彼此间仅通过传递消息实现联系。这一思维观念创新使得问题空间与解空间的结构基本一致；使得从问题空间到解空间的过渡非常自然；使得软件重复使用的粒度增大，有利于大型软件的开发；使得模块的信息隐藏和独立性增强，有利于提高软件的可维护性；为开发者提供了随着对某个被开发系统的认识逐步深入和具体化的过程，与人们通常采用的认识客观世界、解决复杂问题的渐进式思维方式相一致。
二、软件开发方法的发展趋势
在软件工程发展的过程中，繁琐复杂的开发过程、文档维护难度的加大以及软件开发过程中的反馈问题等逐渐的暴露出来，并且人们对软件提出了智能化的需求，而面对这些问题和需求的出现与改变，软件方法的研究与更新也引起了很大的重视与关注，许多新的方法出现并体现出了很大的发展潜力。
1.敏捷软件开发方法
敏捷软件开发方法包括 ASD、FDD、DSDM、XP 等，敏捷软件开发作为一种以人为核心、循序渐进、迭代的开发方法，它把软件项目的整体构建划分为许多个子项目，而这些子项目本身在测试后也验证具有可运行以及集成的特征。敏捷软件开发方法强调了人的作用以及对变化情况的使用，同时强调反馈有效性和简单化，同时重视生产效率的提高，在软件开发过程中，小项目可以分别完成并可以独立运行，软件可以始终处于能够进行使用的状态。它的12条实践原则能够在一定程度上体现出它自身的特性——（1）获得客户的满意最为优先，需要持续的、尽早的交付有使用价值的软件；（2）在软件开发过程中的后期也可以改变对软件的需求；（3）交付可使用的软件要具有经常性，交付的时间需要控制在最短的时间范围之内；（4）开发人员以及业务人员在项目开发中需要始终共同工作；（5）需要为被激励的个人提供必要的支持与环境，并信任他们能够完成软件开发工作；（6）在团队工作中，面对面交谈是左右效率的信息传递方法；（7）首要的进度标准是可以工作的软件；（8）可持续的提高开发速度；（9）强调优秀设计与技能在提高敏捷能力方面的作用；（10）最好的需求、构架与设计来源于自组织的工作团队；（11）在一定时间内，工作人员要针对如何提高工作有效性进行反省并对工作行为做出调整。
2.面向 Agent 的软件开发方法
在互联网不断发展的背景下，规模大以及复杂性高成为了软件开发中最明显的趋势，人们对计算机软件的需求要开始重视其智能化，但是原来的软件开发方法并不能胜任开发具有智能特性软件的工作。Agent 的概念来源于资源分布式人工智能领域，自主性、驻留性以及灵活性是其最重要的三个特征——自主性是指 Agent 能够以外部环境以及内部状态为根据来对自身的状态进行决定，在此过程中并不需要外部进行控制和干涉；驻留性是指 Agent 能够感知到外部环境产生的变化；灵活性是指 Agent 能够与其他的 Agent 进行比较复杂的协同交互行为。凭借 Agent 自身的优势，它在以后的发展中可以应用于交通管理、医疗护理、游戏娱乐、电力电讯甚至国防军事等众多领域。虽然 Agent 仍旧处于探索阶段并且并不成熟，但是已经得到了广泛的重视与关注，并且也会成为软件工程在软件开发方法方面的重要趋势之一。
参考文献：
[1]李光亚.软件工程若干技术发展新趋势[J].微型电脑应用，2010，（11）.
浅谈软件项目加快实施方法 篇7
在软件项目实施过程中执行加快实施方法必须熟悉企业管理知识, 知晓行业关键流程和最佳实践, 以顾问为主导, 规划整个项目工作, 以客户为主体, 完成知识转移和系统建设, 确保流程和数据的正确性, 保证项目实施质量。用友软件加速实施方法最终目标是将行业的成熟管理流程以及经验直接导入企业, 实现软件项目的快速上线, 从而缩短实施周期, 减少投入成本, 推动企业由粗放管理和手工管理向精细化、信息化、流程化管理转型, 实现与客户双赢的结果[1]。
1 软件项目实施中存在的问题
1) 软件项目实施方存在的问题主要有工程师或顾问缺乏行业的专业知识, 没有实施的项目经验;实施方企业没有相应的实施案例库和流程库, 要现场做相关的文档或模板, 耗费大量的时间, 拖延了项目的进度;对客户培训模式不当, 没有互动和案例的引入, 没有严格考核制度, 导致最后培训效果差等。
2) 客户方存在的问题主要是没有标准化的业务流程框架, 存在无标准、不规范的问题;企业管理者认为软件能解决企业的一切问题;领导层对企业要实现的目标不明确、对项目的支持力度不够;客户培训学习不到位, 导致软件操作不熟悉;对企业现有业务流程进行重组影响到了各部门原有的权利和利益关系, 从而导致部分人员出现排斥、抗拒心理;没有建立完备的内部支持体系和管理团队等。
2 软件项目实施四个阶段
加速实施方法由四个阶段组成:项目规划阶段、系统建设阶段、切换准备阶段和切换运行阶段[2]。
2.1 项目规划阶段
1) 项目规划阶段是软件项目实施工作展开前的准备环节, 实施方一方面指派好项目经理并组建项目实施团队, 跟售前交接项目的资料并了解实施项目具体情况以及项目背景等。另一方面协助客户方组建项目实施团队, 对高层进行访谈, 了解企业的现状以及面临的关键问题;召开启动大会以明确实施目标和制度;准备系统环境完成软件安装并对客户进行培训。
2) 本阶段主要交付物清单有:《实施方项目组实施组织架构、责任与任务》、《销售与实施内部交接记录单》、《项目实施主计划书》、《产品安装确认报告》等。
2.2 系统建设阶段
系统建设阶段是软件项目实施中至关重要的阶段[3]。本阶段实施关键内容如下:
1) 关键用户与最终用户的培训。培训软件产品 (如ERP) 相关的基本原理、软件产品功能培训等, 培训顾问或工程师必须要保证用户能理解产品的相关知识。通过培训, 培养出既懂企业实务又懂信息化逻辑的用户。
2) 基础资料规划与信息化流程设计。制定适合本企业的基础资料规划方案, 根据行业需求及管理特点, 设计最佳企业业务流程。
3) 系统权限分配与岗位操作手册。根据前期对公司的各部门、各岗位、各人员工作职责和企业的关键业务调研, 为各部门、各岗位的操作人员分配系统的权限, 然后形成岗位操作手册, 为各岗位提供详细的岗位操作说明。
4) 本阶段主要交付物清单有:《标准产品培训课件》、《业务解决方案》、《模拟演练总结》等。
2.3 切换准备
切换准备是决定软件项目实施是否成功的关键阶段。本阶段实施关键内容如下:
1) 系统运行制度与客户内部支持体系的建立。制定的系统运行制度落实到责任人并进行严格的考核。另一方面需要建立一支既熟悉业务又精通软件和计算机知识的内部支持团队, 这样以后系统日常业务的操作和系统的技术支持就有了保障。
2) 系统环境与静态数据的准备。准备系统环境, 安装软件并完成基础资料、各系统参数、权限等的设置。为了安全需要做好企业数据的备份计划。同时制定好静态数据导入方案和系统切换方案, 确保系统的顺利切换。
3) 本阶段主要交付物清单:《最终用户培训总结报告》、《静态数据导入计划》、《系统切换方案》等。
2.4 切换运行
切换运行阶段是软件项目实施的收尾阶段。本阶段实施关键内容如下:
1) 数据导入。实施方和客户方要制定一份详细的数据导入计划, 客户项目经理一定要关注每个工作明细, 同时要指派到负责人员。在工作初期要对数据进行抽检, 发现问题及时处理。在数据导入后需要对数据进行检查并记录检查结果, 以方便后续问题的追踪。
2) 系统切换运行。在系统切换前需要组织指导小组到各工作岗位上进行现场指导系统操作, 上线初期由客户方的内部人员每天进行检查和讨论, 及时发现问题, 同时需要对每天存在的问题详细记录跟踪。
3) 内部服务交接。系统正常运行后, 运维服务工程师需要提前进入项目运行支持阶段, 最好项目前期阶段就让运维支持工程师参与到实施项目组中来, 这样方便让运维支持工程师更深入地了解项目情况。
4) 本阶段主要交付物清单有:《系统切换检查报告》、《系统切换报告》、《问题处理跟踪单》、《项目总结报告》、《实施与维护内部交接记录单》等。
3 结语
软件项目实施是一项系统工程, 软件项目的快速实施方法对标准实施场景的选择与剪裁, 定义出全新的标准实施线路, 基于用友软件强大的项目案例库和流程库, 快速搭建企业管理平台、规范业务流程, 在工具模板的支撑下, 规范软件实施项目内容与标准和各实施阶段技术指导方案, 加快了系统上线周期, 提高了客户满意度, 从而为企业创造了管理价值。
参考文献
[1]童继龙.ERP项目实施手记[M].北京:清华大学出版社, 2010.
[2]闪四清.ERP原理与实施[M].北京:清华大学出版社, 2012.
OSSP软件项目实施方法介绍 篇8
1 OSSP架构介绍
OSSP架构如图1所示,具有的特点如下。
OSSP涵盖了项目开发中需求分析、系统分析与设计、开发与测试、产品试运行与部署和后续维护与支持等所有流程。
OSSP制定了开发小组在不同阶段必须实施的规程,包括业务(Business)、组织架构(Organization)、实施(Operations)和技术(Technology),不同阶段有不同的着重点。
OSSP集成了一系列的实施管理方案,包括项目管理、需求变更管理、配置管理、质量管理、变革管理和系统设计管理。
2 项目实施方法
在该架构中,软件开发的主要过程以下几个:
2.1 需求分析
需求分析作为OSSP的第一个阶段,它的主要目标是与客户和其他相关人员在系统的工作内容方面达成并保持一致,使系统开发人员能够更清楚地了解系统需求,从而定义系统边界,对系统范围进行限定,为后续阶段的实施计划提供基础,同时也为估算开发系统所需成本和时间提供基础。通常会定义出系统的用户界面原型,通过用户界面原型帮助用户确认系统中的业务流程及相关操作和数据需求。
2.2 系统分析与设计
这一阶段主要是在需求分析阶段的基础上,使用规范的信息系统分析方法和工具,对未来的系统的主要功能需求进行详细的分析,提炼出必要的功能模块,规定模块间的层次关系及接口特征,并开始进行系统的架构设计和相应的软硬件选型,在此基础上,开始进行相关的数据结构设计,细化模块的主要流程,并且开始制定测试计划以及准备测试用例。
2.3 系统开发———开发和测试
本阶段的主要目标就是根据前面确定的系统详细功能需求及设计,结合已有系统的功能,进行具体的软件配置、系统编码及二次开发,在开发过程中,对照系统设计中的层次结构定义代码结构,以构件(源文件、二进制文件、可执行文件以及其他文件等)的方式实现类和对象,并且将开发人员开发完成的组件集成在一起。
2.4 系统开发—系统测试
本阶段的主要工作目标是制定企业系统解决方案所需的测试目标,测试类型、测试策略等;为系统各个功能模块的单元测试、集成测试、系统测试和客户接收测试准备测试用例和测试数据;以及进行信息系统具体业务功能的测试。
2.5 系统试运行及部署
当系统开发结束并且经过集成测试和系统测试后,将进入系统试运行及部署阶段,本阶段的目标是通过项目试运行,确保最终用户可以正常使用本系统,并保证系统满足用户最初提出的需求。
2.6 项目验收及后续支持
在经过了前面的几个阶段,整个系统开始试运行之后,就进入了整个项目的验收和评估阶段了,项目验收需要切实总结在整个项目过程中出现的各种问题和相关经验,为以后项目的改进和提高奠定良好的基础。
2.6.1 项目验收
针对项目验收而言包括阶段性的项目验收和总验收两部分,其中阶段验收是总验收的基础。在每个阶段工作完成后,由相关责任方共同参加,相关责任人在验收报告上签字。验收内容包括项目进度、项目目标完成情况、评价和项目文档。
2.6.2 项目后续支持
针对企业的项目,为客户提供优质、高效的后续服务,提供完善的技术支持,保证系统的正常运行。制定合理的后续支持计划,包括针对企业确定特殊的技术支持策略、安排合适的人力和物力进行定期跟踪等,密切关注管理系统的运行状况,提供完善的支持。
3 质量保证体系
在整个项目实施过程中既要保证进度又要充分保证项目质量,除了具备成熟的方法论、有效的项目管理和充分的技术力量保证等因素以外,制定一套完善的质量保证体系显然是必不可少的。
首先内部应常设独立于其它部门的质量管理小组,负责每个项目的质量监控。
每个项目由专人负责质量监督,分别在项目的前、中、后三个阶段对项目进行质量检验,以确保项目质量:
1)项目前期
质量管理领导小组成员对项目建议书进行检查,包括项目的工作方法、项目的团队、项目工作计划和项目提交的交付物。
2)项目进行中
对项目进程进行监督,确保项目内容和日程不偏离计划、成本与项目进度符合计划、项目范围按计划、人员合理配置、项目进程报告按时提交和确保客户保持必要的支持和参与度;对客户与团队之间的有效沟通进行跟踪评估;了解客户满意度,确保项目的整体质量和表现。
3)项目结束时
将全部项目交付品交给知识管理协调员,由后者输入公司的知识管理库;对项目进行审查,确保其合规完整的完成,如果未能完成,则该项目的收入不能确认为该项目经理当年的绩效考核结果中。
同时质量保证活动将贯穿于整个软件开发生命周期之中,并且细化到各个具体阶段,详见如图2所示。
同时软件管理配置活动也贯穿于整个软件开发生命周期中各个具体阶段,详见图3所示。
4 结束语
软件生存期模型是软件企业进行软件开发的一种框架,它说明了软件的活动和进行软件开发的过程。这个框架模型应包括所有的开发活动以及软件产品。生存期模型的选择对于项目的成功开展非常重要。在实际的应用中,应根据特定环境来选择适合本企业的开发模型。
参考文献
[1]刘伟群,李雄.新型软件开发模型比较[J].现代计算机,2005,5.
[2]张友生,李雄.软件开发模型研究综述[J].计算机工程与应用,2006,3.
软件项目管理方法 篇9
1信息系统软件开发项目管理概述
随着信息时代的飞速发展, 信息技术的应用开发已日趋重要, 成为了企业能否发展的重要因素之一。各大行业纷纷引用了信息化项目管理的先进理念, 凭借ERP、CRM、电子商务等信息系统及信息应用, 提升了企业自身的实力, 增强了企业在市场中的核心竞争力和影响力。与此同时, 软件开发项目中“黑洞”也应运而生:项目无法按期完成、项目合作方的工作难以协调、用户需求经常变动、工作质量难以保证, 给企业带来为了愈来愈多的损失。这种情况说明了项目开发及管理过程中, 存在着许多的问题, 需要更多的重视和研究。
信息系统开发项目管理作为一种科学的管理手段, 是为了使项目能够按照预定的成本、进度、质量顺利完成, 而对成本、人员、进度、质量、风险等进行分析和管理的一系列活动[3]。因此, 对于以“项目”为基本运作单位的各软件开发企业, 都在积极地将标准化的项目管理引入开发活动中, 对软件开发实行有效的管理。因此, 决定一个开发项目实施成功与否, 一个强有力的项目管理无疑起着举足轻重的作用, 项目管理已经是公认的软件开发企业的核心竞争力之一。软件开发项目管理不同于其他, 他涉及到企业的管理变革和流程再造, 是一个相当复杂的过程, 任何一个环节上的小小失误, 都极有可能使整开发项目功亏一篑[4]。信息技术发展快、渗透广等特点, 使得IT项目与一般工程项目存在着明显的差别, 这种差异性造就了软件开发项目时面临的诸多难题[5]。
2面向信息系统软件开发项目的管理方法
面向信息系统的软件开发项目管理方法从软件项目计划管理、软件项目的进度管理、软件开发的成本管理、沟通管理、综合变更控制管理、软件开发项目风险管理等六个方面阐述了具体的管理方法。
2.1软件开发项目计划的管理
在坚持科学、合理、全面、周详的原则基础上, 对部分具体的计划条款进行细化。为了使所有的计划内容都是正确的、明确的、易理解的和可执行的, 不出现未经确认、含糊不清、容易误解、难以执行的项目计划描述, 在制定计划之前以及制定过程中, 与用户方面、公司上层、其他设备供应商、项目团队各技术和管理小组进行充分的沟通与协商。明确确定软件的有关内容, 如软件交付的成果、技术方法工具、组织结构、各工作包、资源要求、预算分配、进度计划等。
对于综合性的项目, 由于项目复杂程度高、涉及面较广、实施周期长, 所以其中的变更是在所难免的。在项目实施过程中, 项目计划制定以后并非一劳永逸, 它与项目实施过程相互渗透, 有一个动态的、灵活的修订过程。
2.2软件开发项目的进度管理
通过面向对象技术同传统技术相结合的方法估算项目工作量及技术难度。识别关键任务, 特别注意系统构架是整个系统的基础。随时了解项目进度, 必要时调整进度表。
2.3软件开发项目的成本管理
成本管理的目的是通过执行项目成本管理过程和使用一些基本项目管理工具和技术来改进项目成本绩效。项目组整体上把按进度和预算交付项目作为最大的挑战, 因此需要对项目进度和成本的控制和管理部分非常重视。项目过程中可借助项目管理软件Microsoft Project 2003来辅助进度和成本的计划和管理。
计划阶段要做好工作量估算, 可利用成熟通用的计算公式, 并结合自身实际情况进行估算。实施阶段要进行成本跟踪和控制。
2.4软件开发项目的沟通管理
要提高大家对沟通作用的认识。要对项目组外部的沟通, 需从实际出发, 采用多种沟通的方式。要对项目组内部沟通, 进行适当的控制, 避免形式主义, 在保证效果的前提下节省时间, 提高工作效率。
2.5软件项目的综合变更控制管理
综合变更控制是指在项目生命周期内对项目变更进行识别、评价和管理的工作, 这也是项目经理及其项目团队的一项重要工作。针对项目本身的复杂程度高低、涉及面宽广、实施周期长短等问题, 适时的变更是在所难免的。当有变更要求提出的时候, 项目经理召集项目团队相关人员, 进行协商讨论和工作安排。主要内容可如下:对变更因素及其影响进行分析, 并采取对策, 确保变更对项目有利;确定变更是否发生;对变更加以管理。
2.6软件开发项目的风险管理
软件开发项目风险管理贯穿于项目的整个过程, 成功的风险管理会大大增加项目开发成功的概率。具体可从制定可行风险管理计划;有效认别风险;风险对目标影响程度;针对风险采取相应的措施;有效地对风险进行跟踪与控制五个方面来对开发项目进行有效的风险管理。
3该项目管理方法在协同监督平台开发项目中的应用
协同监督平台是一个对风险信息的搜集、分析、评估和预警的流程化管理平台。以风险评估报告的方式对国网丽水供电公司 (包括下属各市县公司) 可能产生的风险进行搜集, 按照监察审计部门的风险管理流程对已搜集的风险进行分析, 并将分析结果以及拟办防护措施及时下发到各个防控部门, 起到及时风险防控和预警的重要目的。同时, 还将对各个防控部门采取的防控措施进行评估, 及时了解各个防控部门防控情况, 进一步及时有效的防控风险。登录界面如图1所示。
在协同监督平台的开发过程中, 充分应用了信息系统开发项目的管理方法。协同监督平台开发项目的管理以计划管理为起点, 全过程与开发成本管理、风险管理、进度管理、综合变更控制管理相互贯穿, 最终促成协同监督平台的顺利开发完成。如图2所示。
4结论
随着信息技术的发展和应用范围的不断扩大, 信息系统软件开发项目管理越来越具有普遍性必要性。面向信息系统软件开发项目的管理方法从项目计划管理、进度管理、沟通管理、成本管理、项目综合变更控制以及风险管理等6个方面介绍了如何对软件开发项目的全过程进行管理。通过在协同监督系统的开发项目中的成功实施, 说明该方法能够充分地管理信息系统软件开发项目的实施。
参考文献
[1]程婷婷, 陈伟亚.IT项目管理中制约因素的分析和研究[J].甘肃农业, 2006 (2) .
[2]林建平.企业信息化建设的项目管理[J].中国民用航空, 2006 (2) .
[3]刘普.企业引入项目管理应把握的主要问题[J].铁路工程造价管理, 2005 (6) .
[4]蒋国瑞, 等.IT项目管理 (第2版) [M].北京:电子工业出版社2011, 5.
中小型软件项目进度管理方法研究 篇10
一、基于工作量的软件项目进度估计?
基于工作量的中小型软件项目进度估计, 是在软件工作分解结构分解得足够细的情况下, 先对软件项目的规模进行估计, 根据规模估计出工作量, 再根据工作量估计项目的进度。对于规模和工作量的估计已经有了很多的探讨, 下面研究在工作量已知的情况下, 如何基于工作量估计中小型软件项目的进度。
一般情况, 中小型软件项目的进度估算主要分两种情况, 一种是先确定资源, 由项目根据给项目配备的人员情况以及项目的任务情况, 确定一个最后的结束时间;另一种是先确定最终结束日期后估算, 根据估算情况配备人员和资源, 用工作量除以时间得出人员要求。下面将这两种情况结合在一起进行进度估计方法的研究, 具体步骤如下:
步骤1:根据合同或市场期望的时间确定项目的总体时间要求, 即项目的完成日期A;在大多数情况下, 项目的最终完成日期或交付日期是由市场、顾客或根据组织的要求提前确定的。
步骤2:根据工作量估计值和项目组人员情况估计项目开发所需天数, 计算方法为:每阶段的工作日= (本阶段工作量估计值/本阶段参与人员) *修正值, 修正值由项目经理根据本项目具体情况确定, 修正值范围为0.8~1.5 (修正值也要考虑到有些任务不能同时由很多人来一起干的情况, 如需求分析阶段) 。并由此估计项目的预计完成日期B, 估计时应注意以下换算关系:
1人年=12人月1工作年=12工作月
1人月=22人天1工作月=22工作日
1人天=8人时1工作日=8小时。
在进行这一步骤时, 最好能通过收集历史数据, 并进行分析统计来确定组织每人月的平均有效工作时间, 在分析过程中应考虑到组织的休假制度等各种情况。
步骤3:比较A、B, 若B>A, 项目经理应采取以下措施:a) 调整项目人员安排;或b) 与公司高管协调资源安排, 直至最终估计结果。
步骤4:根据所选择的生命周期模型和项目各阶段工作量的分配百分比, 确定项目的里程碑, 规定在里程碑处须完成的产品或达到的目标。
步骤5:根据产品的功能WBS, 分析各阶段任务的关键依赖关系, 识别出影响项目进度的关键活动。确定哪些模块可以并行独立开发, 哪些模块必须串行开发, 定义出各功能模块的开发顺序, 列出模块的开发顺序表, 尤其要标明模块之间的依赖关系。
步骤6:确定项目进度:根据合同或市场期望的时间要求、项目生命周期、各阶段工作量百分比、活动WBS及所识别的关键路径和依赖关系, 确定项目的各项任务和时间, 同时记录进度估计的假设, 并最终形成项目的进度甘特图。
步骤7:协调计划和资源情况 (SEI, 2008) :进度计划制定出来后, 项目经理组织协调并确认资源的可用性问题, 如果估计的资源和可接受的资源之间有差异, 则协调解决;如解决不了, 则对计划进行修改, 使资源和计划取得一致, 如可通过降低技术性能要求、寻找方式提高生产率、外购等方式来进行调整。具体包括下步骤:
协调人力资源:与估计中所需用到的人。力资源的相关人员及其负责人进行沟通, 明确所有项目成员的到位日期和可投入工作量的百分比;计算除去各项必要的时间耗费外可用的工作量资源;将各项可用的人力资源与估计的情况进行比较, 如有任何差异, 则必须协调解决, 如不能解决, 则必须与组织高级管理者或与客户进行协商, 以使工作量与进度及需求相匹配。
协调其他资源:针对组织内共用的各项。软硬件资源进行沟通, 检查所需资源的使用日期和时间段是否有问题;针对需要其它相关方提供的资源, 与提供方协商确定;检查所需资源使用的具体日期和时间段是否有问题, 如有问题则协调解决。
步骤8:召集项目组成员、高级管理者、客户及其他共利人员对各项估计情况进行评审, 以获得对各项估计的承诺, 计划经评审、批准通过后开始实施。
二、中小型软件项目进度层级及细化
对于进度安排一般分两级进行, 首先确定整体进度和主要里程碑, 然后确定详细进度。刚开始因为项目所掌握的信息比较有限, 所以会先制定一个概要的整体的进度计划, 但在项目进行过程中, 每个阶段开始的时候, 都应该对该阶段的计划进行细化, 形成一个详细的阶段进度计划, 阶段计划一般要求任务粒度细化到一周。在每周开始的时候, 还要求制定详细的周计划。在做阶段计划的时候, 除细化进度外, 还应细化工作量, 细化到两周左右;并用工作量代表费用, 用挣值法来进行成本和进度监控。
另外估计的时机也具有可变性, 例如:根据项目的实际情况, 可以在需求分析完成后再估计项目整体进度, 而在需求分析完成前只做需求分析阶段的进度计划。
下面以某公司正在开发的一个“YNY项目”为例进行介绍。在这个项目中有“X1模块”这样一个模块, 在项目刚开始的时候对这个模块的设计阶段只制定了一个概要的计划时间点, 如表1所示;而等设计阶段开始时, 便对这个模块制定了一个详细的阶段计划, 如表2所示。在制定计划的时候, 对于最后的结束日期一般会设定为一个时间点, 但必要时也可以将其设定为一个区间。
在进度计划制定出来之后, 在每个大的里程碑结束的时候, 还必须根据计划的执行情况, 重新进行进度计划的估计, 不断的重复, 直到项目结束, 所以也有人说, 当项目结束了, 最终的进度计划也就出来了。
三、中小型软件项目进度监控
(一) 中小型软件项目偏差的处理
谈到项目的进度监控及管理, 同样需要思考这样一个问题, 提前完工 (进度提前) 的项目就是好项目吗?答案是不一定, 项目进度晚了固然不好, 但提前完工, 也有可能会有问题, 可能有几个原因:一是制定计划时估计不准确。本来应该5月份完工的项目, 估计成10月份完工, 结果项目是7月份完工, 虽然比计划有所提前, 但仍然不是一个好项目。二是质量没达到要求或费用超支。三是即使质量达到了要求, 费用也没超支, 如果一个项目的一部分提前完工了, 也有可能提前过早地占用了资源, 而导致项目的总体成本提高, 比如说一笔资金, 本来准备6月份投入, 结果2月份用了, 就有可能会提前占用资金。四是当然也有可能是因技术改进, 导致生产率提高而提前完工, 这时就应总结经验, 改进组织的过程。
因此对于进度偏差情况, 要根据具体情况区别对待。那么什么是偏差呢?所谓偏差就是实际进度与计划进度的差异, 通常情况偏差分为两种, 一种是刚才所提到的进度提前的情况, 称之为有利偏差;还有一种是进度滞后的情况, 又称之为不利偏差。不管是有利偏差还是不利偏差, 当偏差发生后, 应该采取如下几个处理步骤。
原因分析:进度的提前是因为管理效率高, 还是因为采取了不正当手段, 或标准定的不合理造成的?
系统分析:有没有因为偏差而对其他目标产生影响, 如:有没有因为进度提前, 而影响到项目的质量和费用等。
采取对策:如进度的提前是正当的, 则应该对项目人员进行激励;如不正当, 则进行处理。进行总结评估。对偏差的产生原因, 及经验教训进行总结, 并将总结结果纳入到组织的体系流程中, 以改进提高组织的项目管理水平。
偏差处理是一个经常性的活动, 通过这些活动就是要使项目始终处在一个状态, 就是“受控状态”即一切尽在掌握之中, 避免“失控状态”的出现。
在项目完成后, 根据最终实际进度与最初计划进度之间的偏差, 判断估计是否准确及项目完成计划的能力。若偏差较大, 应采取措施对项目所采用的估计方法进行改进, 为以后项目的估计提供帮助。
(二) 帕金森定律在监控中的应用
帕金森有一条定律:“工作会延展到填满所有的时间”。因此, 在分配任务的时候, 必须要有期限, 没有期限就永远完成不了。定下期限, 可以给项目人员施加压力, 尽快把工作完成, 定期限是在实践中最有效的方法之一。同时, 也必须注意到在安排工作的时候, 人具有很大的伸缩性。人们具有以一定速度工作以便在给定时间内完成工作的能力 (人力的伸缩性) , 如假定一个项目的工作量估计是200人月, 项目按时完成, 花费200人月, 这个估计是好的, 但不一定是最好的。我们没有理由相信他们不能在180人月里完成, 因为工作被“扩展”了。人们有“扩展工作以填充充裕的时间”的心里。如果估计为200人月, 有可能得220人月才能完成, 但100人月是肯定完成不了的。所以说一个项目即使正好按计划完成, 也得分析一下, 看人员利用率如何?有时候往往容易出现这样的情况, 时间估计过多, 比如说2个月能完成的项目, 估计了3个月, 结果正好按时完成了;也有可能是3个半月的项目, 你估计了3个月, 也正好3个月完成了, 这几种不同的情况, 人员的疲劳程度是不一样的, 所以组织在进行项目监督与控制的时候, 必须考虑到项目人员的这种疲劳程度及“利用率” (Pankaj, 2003) 。这同时也要求组织在进行项目策划的时候进行合理的估计, 虽然合理的范围不是很大, 但也会给估计模型以充分的余地;估计总能实现不是因为其非常正确, 而是因为其合理。
(三) 进度压缩
在进度执行过程中, 经常会因客户的需要, 不得不进行项目进度的压缩, 那么应该如何来压缩项目的进度呢, 压缩过程中应该注意一些什么原则呢?在进行进度压缩的时候, 一般有两种方法:应急法和平行作业法 (韩用明, 2003) , 应急法是权衡成本和进度间的得失关系, 以决定如何用最小的增量成本达到最大量的时间压缩, 常导致成本增加, 平行作业法是平行的做活动, 如在设计完成前就进行编码, 常导致返工和增加风险。但需要注意的是, 当进度被压缩到“正常”范围之外, 工作量就会急速增加, 费用也会迅速上涨。软件项目存在一个可能的最短进度, 这个最短进度是不能突破的。Charles Symons提出的进度压缩费用方法:进度压缩因子=期望进度/估算进度, 压缩进度的工作量=估算工作量/进度压缩因子。例如:项目的初始估算进度是12个月, 初始估算工作量是78人月, 如果期望压缩到10月, 则进度压缩因子=10/12=0.83, 压缩后的工作量=78/0.83=94 (人月) 。也就是说进度缩短17%, 增加21%的工作量。很多的研究表明:进度压缩因子不应该小于0.75, 即进度压缩不应该超过25% (韩万江, 2005) 。
四、结语
总之, 本文所研究的方法是一种比较系统的专门针对中小型软件项目进度管理的体系模型, 能够有效的解决中小型软件项目进度管理所面临的困境, 并首次将人文因素 (人员的疲劳程度) 与软件项目的监控进行了结合探讨。该方法体系具有通用性, 适用于绝大多数中小型软件企业。而对于大型复杂的软件项目, 则必须结合关键路径法一起使用, 仅用本文所研究的方法体系难以实现有效的策划和监控。下一步的研究重点是在大的体系模型确定的基础上, 对项目的偏差设定, 进度压缩因子的具体模型等因素的具体设定进行进一步的建模和研究。
摘要：为提高项目成功率, 研究了一种系统的软件项目进度管理方法.该方法结合实际项目的案例, 考虑到中小型软件项目的特点, 通过获得项目的工作量及各阶段工作量分布, 进行分解得到项目的进度;在进度分解过程中, 充分考虑到项目资源的可靠性和可用性问题;同时, 也对进度计划的细化和监控进行了研究.
关键词：中小型软件项目,进度估计,监控
参考文献
[1]张俊光.软件项目管理的若干关键问题研究[D].北京邮电大学, 2007, 7.
[2] (印) Pankaj Jalote.软件项目管理实践[M].清华大学出版社, 2003.
现代信息系统软件工程设计方法 篇11
【关键词】信息系统；软件工程；设计；方法
计算机软件工程是一类求解的工程。软件工程的应用原理主要是以计算机科学和数学科学以及管理科学为主。同时又借助于传统的软件工程设计的基本原则和基本方法，创建新的软件，实现提高软件质量的目的。软件工程是知道计算机软件设计、开发以及维护的工程学科。在现代社会中各个行业几乎都有计算机软件系统的应用。这在一定程度上促进了社会的发展，提高了人们的工作效率，同时也提高了人们的生活品质。现代信息系统软件工程主要是研究工程化方法的构建、有效的维护和设计实用的、高质量的软件的一门学科，本文主要介绍信息系统软件工程的一般设计方法。
一、需求分析
软件需求分析是软件开发阶段的前期主要工作，通过需求分析希望能够准确的找到软件开发设计的目标，也就是清晰的找到为了满足用户的需求该款软件具体可以做什么。软件需求分析主要包括两个方面，即需求获取和需求规约。为了更好的进行前期的需求分析，要求系统工程的开发人员能够深入的理解各种业务需要解决的问题空间；要求系统工作人员能够用准确的语言刻画出用户的需求，不能想当然的理解用于需求，尽量减少由于人与人之间的通信造成的信息误差；要求能够及时的采取措施适应不断变化的需求，当然造成需求变化的因素很多，作为工作人员，应该做到随机应变。
1.需求获取
现代信息系统软软件工程设计的第一步就是需求获取，软件设计成功的前提就是获取正确的需求描述。用户的需求通常包括功能性的需求和非功能性的需求。功能性的需求中说明了软件工程系统能够为用户做什么，非功能性的需求说明了系统在工作时的属性和特性，比如说系统的效率和可靠性等等。具体而言需求获取主要包括的内容有：物理设备的位置和分布情况；系统用户的技能和熟练程度；数据的格式、发送的频率等数据内容；开发需要的人力资源和计算机的资源以及进度安排；系统的质量，比如说对系统的可靠性的要求等等。这里值得强调的是，搜集需求资料的方式有多种，最主要的是通过调查问卷、访谈和采访等方式。最主要的与用于深入的沟通，才能更好的挖掘用户的需求。
2.需求规约
通常在需求获取的阶段，直接获得了用户的需求。这时候的用户需求是用自然语言表达出来的，要通过需求规约将自然语言准确的表达为一系列的符号、描述等，这些符号和描述是所有的计算机软件分析人员可以共同理解的，并且其理解的意义是完全相同的。通过符号来表现各种对象之间的关系，使得最终的需求报告变得简洁、明确、统一、易懂。
二、数据管理设计
数据管理是计算机对数据进行收集、存储和处理的过程。通过数据管理设计可以将确定下数据管理系统中存储数据的基本结构。这样就能够保证数据的独立性和可靠性、安全性。同时能够减少数a据冗余，提高数据资源的共享程度和管理效率。目前主要的数据管理方法主要有普通文件管理、关系型数据库管理系统、面向对象的数据库管理系统这三种。
现代信息系统需要管理的数据类型往往是多种多样的，包括空间的数据、时间的数据等等。现代信息系统软件工程的数据管理一般是面向数据应用的数据管理对象。面向数据应用的数据管理所管理的数据对象，主要是那些描述构成应用系统构件属性的元数据，这些应用系统构件包括流程、文件、档案、数据元（项）、代码、算法（规则、脚本）、模型、指标、物理表、ETL过程、运行状态记录等。
三、界面设计
在完成数据管理设计之后最重要的就是界面的设计。因为界面设计是用户与机器交互的窗口，其中用于户向系统做出命令，系统也会给用于提交信息，所有的这些活动都是在界面上完成的。良好的接受首先能够使让用于容易掌握操作，其次是能够满足大部分用户的审美需求。也就是让用于在使用的过程中不会因为不接受或不容易上手，产生不良情绪，影响软件的使用。良好的用户界面设计原则主要包括一下几个方面。
1.因人而宜的原则
在需求获取的阶段，要详细的了解该软件面向的群体。根据使用群体的不同，设计不同的界面。首先要弄清楚不同群体的不同需求。我们可以按照技能来分类，也可以按照职业开分类，还可以按照组织层次来分类。通过分类，最终的目的是做到因人而宜，确定其相应的最佳人机交互操作界面设计。对人员进行适当的分类之后，将这些信息描述下来，同时也包括用户的任务脚本，这些信息将对于人机交互设计发挥大大的指导作用。
2.实用与美观相结合的原则
界面设计的过于花哨，往往会使得用户有摸不着头脑的感觉，也就是不知道如何下手，不理解界面中各个对象的具体含义。过于简单的界面往往又显得特别单调和枯燥，不能满足用于的审美需求。随意界面设计的最基本的原则就是使用和美观相结合的原则。另外不要出现模糊不清的提示，操作反应的时间尽量不要超过十秒钟，系统不要发生额外的附带操作结果，以免给用户带来不必要的疑虑和麻烦。
3.交互过程详细原则
很明显，太多的操作项目往往用户不易掌握和操作。所以要设计详细的交互就要做到操作步骤要少；如果有较长时间的操作，要给用于一定的提示；尽量的减轻记忆的负担，尽量不要要求用户把一个窗口的信息写入另一个窗口；增强软件的趣味性；及时的了解用户的反应，以便于修改界面。
四、确认活动
确认活动应当贯穿于整个软件工程设计的始终。目前软件的测试技术主要有白盒和黑盒两种。软件测试的主要目的是发现软件中的错误，及时的修改。其中，为了检验软件的功能和性能是否与用户需求一致而开展的测试成为确认测试，而系统测试主要是测试软件同硬件、其它支持软件、数据等结合在一起，判断软件在运行的现实条件下，与用户的需求匹配的程度。
五、结语
本文从宏观的角度介绍了现代信息系统软件工程的设计方法，其中各个版块中涉及的细节还有待进一步的磋商。需要注意的是软件工程设计最重要的是实用，开发者可以根据具体的情况和具体的用户需求选择不同的方法。
参考文献：
[1] 朱剑.软件工程系统的发展及其应用[J].商业现代化，2010（2）：16.
[2] 梁镇.软件工程质量标准与管理浅析[J].
作者简介：
孙涛（1979-）江苏徐州人，学士，广东省珠海市公安边防支队司令部机要科。研究方向：计算机通信，通信保密等。
基于看板管理方法的敏捷软件开发 篇12
软件开发项目管理从最早的传统项目管理软件工程期到近年的迭代模型时期,最后到目前的敏捷软件开发时期。敏捷软件开发的成功五项因素分别如下。
(1)建立自组织团队。传统的管理方式具有命令和控制的特点,经理制定目标和计划,团队负责完成,发挥不出员工的创造力,影响了企业的效率。软件开发的敏捷开发要求员工自我管理,个人控制时间和目标,员工能参与流程和项目决策。
(2)用户故事在需求管理中的应用。软件开发企业最大的敌人不是用户,而是变化。瀑布模型难以适应目前软件市场需要,因此软件开发工作要取得用户的参与,顺应市场的变化。
(3)用户故事的度量,它能为产品投资收益提供估计结果,辅助产品决策。对故事点大小讨论时,能鼓励团队成员重复讨论,充分理解需求。故事点度量方式一致,提高统计团队工作效率。
(4)持续集成。它能提高项目构建自动化程度,将人力成本更多投放到开发任务。项目更有可见性,构建结果更加丰富,一目了然。团队对开发产品更有信息。
(5)掌握迭代,为员工提供稳定的生活节奏,保持一致的周期循环流程,沟通过程中控制时间。
(6)坚持反馈和改进,了解自身情况,改善团队效率。
精益生产的目标为提高质量和消除消费。看板原则要求生产降低库存量、降低生产周期、生产基于交叉培训和单元并对过程进行持续改善。如同超市进货一样,当货架上货物少于设定值,供货商会及时将其填满。将看板管理与敏捷软件开发结合起来,能够达到效率和质量的有效结合,软件产品周期频繁,能达到按天发布级别。
2 RCOM项目看板方法流程设计
增量迭代开发开发流程存在着三点问题。
(1)每个迭代的用户故事较多,产品经理和开发工程师认为很多功能没有价值,而项目经理认为需要跟踪的项目较多。
(2)对于为期四周的迭代观念不统一,部门不同,期望值不同,测试人员认为时间不充分,产品经理认为需要等待太长时间。
(3)部门之间缺乏协作,缺乏透明的项目进展和进度,太多时间花费在流程上。敏捷软件开发有三个典型流程,分别XP、Scrum及看板,经过比较,看板原则可以解决迭代用户故事较多的情况,对于规模小及优先级别高的用户故事能够迅速完成,并满足产品经理对产品的预期。
2.1基于看板管理的敏捷软件开发流程方案设计
看板一般应用于汽车生产等工业领域中,在敏捷软件开发中看板管理只是理论上行得
通,但是在实际上还缺乏经验。而且其受到产品特点、客户差异及企业文化的影响。其流程主要为,
(1)定义并可视化流程。
(2)限制WIP数量,流程可视化于物理板能够让项目透明,让团队对目前的任务充分明确。限制WIP数量则能让团队在思考时排除干扰,提高个体效率,项目工作不以来时间计划,而是取决团队能力。
(3)拉动式生产,每个团队成员只需要对自己环节加以关注,等待任务-完成工作-到下一环节等待区。这种方式推动了产品开发前进步伐。
2.2看板流程准备和实施
(1)是动员和人员培训,先获取领导层的理解和信任,再向所有员工培训敏捷开发和看板方法,最后,每个部门进行讨论。
(2)制定需求管理环节,产品经理提出产品需求,创建用户故事,技术团队估算用户故事工作量。通过需求分析,工程师能够获取信息,完成研发工作,产品经理全程辅助开发和测试,解答相关问题。
(3)开发流程改造,主要变化在对程序代码的管理方式进行改变,主要有主干和分支两种。
(4)测试流程改造,主要表现为两个方面,一方面提高系统自动化测试率来加快回归测试的进度,另一方面增加测试环境满足功能测试需求。
(5)项目管理流程的建立。
2.3看板流程的实施
当所有准备工作完成之后,看板方法第36增量迭代之后,可以正式实施。产品经理将用户故事进行排列再制成任务卡,贴在用户故事一列,完成需求分析会议。开发组建立功能分支进行开发,测试组应用功能测试环境对用户故事进行测试,直到产品发布。团队成员每天早上聚集看板附近,明确自己的任务,下班前,项目经理将每天的任务卡状态变化汇总。敏捷流程要求强调团队自组织和员工自我管理,但是不可忽视项目经理的作用,项目经理能够组织人员,梳理工作节奏,保证沟通流畅,促进项目进展。
3看板方法效果分析
在对用户故事完成效率统计,并对超时任务进行反思和改进之后,回顾看板流程管理经验,总结建立自组织团队时,应该考虑建立流程、理顺沟通方式、改善管理风格、制定度量标准四个方面问题。从看板流程团队角色视角分析,就项目经理来说,虽然团队沟通节奏加快,但是需要针对需求变更的灵活、用户故事的调整,适应变化和跟踪进度。就企业运营角度来看,看板流程比增量迭代开发,能实现商业价值,流程改造增加来了沟通,工作更透明、工程师时间自由,优势大于劣势,是一个成功的尝试。
摘要：随着互联网技术以及信息技术的发展,我国的软件市场逐渐庞大,企业为了在软件市场中取得一席之地,必须要促进软件生产的效率、降低软件缺陷和生产成本。本文立足于敏捷软件开发和精益开发方法,研究了看板方法在敏捷软件开发中的作用,得出看板方法敏捷实践可以培养团队、兼顾流程效率及团队成员的自我管理的需要,希望具有借鉴意义。
关键词：看板管理方法,敏捷软件,软件开发,精益生产
参考文献
[1]匡松,周启海,陈森玲等.敏捷软件开发的认识偏误与推广瓶颈浅析[J].计算机科学,2007,34(12):294-295,303.
[2]徐照兴,杨水华.敏捷软件开发过程中重构技术的研究[J].煤炭技术,2012,31(11):223-225.
[3]芮雄健,王忠民.基于敏捷软件开发方法的基金管理信息系统开发[J].计算机应用,2004,24(11):162-165.
[4]夏显鄂,梁洪峻.敏捷软件开发与计划驱动开发的概述比较[J].计算机工程与设计,2007,28(16):4035-4037,4062.