软件项目管理过程分析论文

软件项目管理过程分析论文（精选10篇）

软件项目管理过程分析论文 篇1

随着软件项目规模的扩大,推动了软件工程和软件技术的发展。但当前软件工程和软件技术的研究也日益深入。项目的管理一般需要把握两条线,技术架构和开发规范,本文基于一般多层架构的项目做一个软件项目开发过程的实践分析。

1 技术架构

技术架构可重可轻,它将直接涉及到安装运行环境,从而影响到软硬件成本,同时对项目组成员要求不同,从而影响项目进度,由于主流.Net和J2EE架构中,J2EE灵活性高,以下以J2EE平台进行架构考虑。

如果系统同时在线用户数目不大,操作方式不复杂(不会涉及远程调用,服务器集群,异步消息处理),项目规模不大(数据库结构表数目在100个以下),就一定不要使用EJB,也就是不要把Application Server引入。如情况相反,则往往需要应用系统分层实现策略。分层是实现一个健壮的复杂的现代软件系统的前提,一般的系统都必须考虑数据持续层、业务实现层、请求控制层和显示层。理清这个层次结构有助于设计阶段制定架构的实现,从而保证整个系统的结构清晰。以下是可供参考的策略。

1.1 数据持续层

当前数据库大都是关系型数据库,在面向对象设计语言下,使用O/R Mapping工具好像是很自然,如果架构中使用了Application Server,大家自然的选择是EntityBean,其容器事务管理方面确实很大优势。另外一个比较好的持续层方案是JDO和Hibernate工具,他们都支持通过POJO(Plain Old Java Object)进行O/R Mapping。他们实际上只是一组Java Class的工具类,不需Application Server支持。O/R Mapping技术在项目规模比较大的情况下,可以大大减少一个对象增删改的SQL语句数量,加快开发速度和质量,但对于小型项目却未必需要考虑,完全可以使用一个SQL执行工具完成访问数据库工作,Apache下开源项目Common里有个DbUtils就是一个好选择,所有SQL语句可以写在一个文本配置文件里,便于修改。

1.2 业务实现层

在使用Application Server时,毫无疑问使用Session Bean处理业务,同时为每个Session Bean提供一个Business Delegate是一个不错的设计,为客户端隐藏调用细节。在轻量级情况,就用普通Java Class就可以了,业务层的设计主要在于相似业务的重用,一般做法把一些可重用方法提取到基类,例如得到数据连接,执行查询SQL和没返回的SQL,关闭数据连接,可以为各种类型的数据库操作在基类提供方法,而具体业务子类只要使用这个基类方法即可。

1.3 控制层

控制层负责接受请求,校验访问权限,调用业务对象,保存结果,分发视图,如果在大项目里,建议使用Apache下的Struts框架,当要注意合理使用,有必要进行合适的扩展。但不管是否使用Struts作为控制层框架,基于MVC的实现必须有如图1这样的思路。

Business是业务实现,Action负责提取请求中数据以适应Business的接口,读取结果以合适的结构返回给客户,运用Command模式进行设计,SecurityManager负责访问控制,同时对Action池进行管理,提高性能。而控制器Controller就只要按需要从池里面取适当的Action执行其Run方法,然后Forward到某个视图,一个Jsp页面,View再把结果显示给用户。

1.4 显示层

显示层的任务是显示数据,不关心数据的取得过程,视图关心如何显示,一个布局页面,这个页面Include具体特定视图是一种好的设计。特定视图显示风格需要统一,可以提供封装特定形式的显示代码,如表格,文字环绕风格等,提供如分页等公共功能组件。

以上架构将在后续设计实现阶段不断细化,直至完成一个架构基线。

2 开发过程规范

开发过程规范或模型,例如,瀑布开发模型,快速开发模型,迭代开发模型,甚至是极限编程。项目的开发过程规范的衡量标准有一个有利于,即是否有利于项目进展,任何软件过程制品都要经过这个标准检验。如果不是有利于项目进度,如果不能帮助推动项目进度,一概不做。基于迭代的开发模型是许多现代开发模型的核心,其适应性很强,是值得推荐贯彻的过程思想。由于软件一步到位基本是不可能的,为了应付各种变化,只能步步为营,做多少算多少,知道多少需求就实现多少,同时最快地反馈给最终用户,所以上面提到选择一个灵活的架构和优秀的设计是非常重要的。以下是一个基于迭代开发思想(XP和RUP等快速开发模型都基于这样思想)的实用的软件过程建议。

2.1 项目需求

客户提供部分或者调研部分,可以详细整理,理出条条框框最重要,需求分析过程是针对特别的需求进行分析,对于一些普通的增删操作,不用做大量文档,需求分析结果要求出文档有:Key Abstract或者说叫Domain Model类图,罗列所有可能的对象和关系,由此一般可以映射到数据库设计。面向对象软件开发是以对象驱动的,所以Key Abstract类图是非常重要的。接下来的其他制品,如数据库设计,页面设计,都将依赖于他。在需求分析阶段,页面设计工作应该同步进行,页面设计结果可以作为原型(Mock Up反馈给软件客户。

2.2 项目设计

设计阶段进一步细化我们的核心类图,和数据库设计,给出复杂业务的相关流程图和文字描述。在这个阶段,架构设计必须已经提前完成,架构设计一般是取一个简单但能涉及到系统各个部位技术的业务。一般数据库系统,用户登陆管理是一个好的选择,因为用户登陆涉及数据库操作,会话管理,权限管理,从页面到数据持续都会涉及到。然后详细设计和实现这样一个业务,这个设计和实现就被当成是其他业务设计和实现的样板,是为架构基线。架构基线一般都是第一次迭代时完成的,架构基线里将会产生很多通用类库,很多抽象基础类,以提供其他业务实现使用,所以架构基线历时会比较长,而且必须经过严格测试。可以说当架构基线完成后,其他业务将可以在此基础上大大加快速度。

2.3 项目实现

实现阶段主要规范的是代码风格,文件,类,方法命名约定,同时保证没有脱离给定的架构实现。同时单元测试代码应该随着实现的完成而产生,比如在Main函数里写针对该类的方法测试代码是好的选择。

以上是迭代过程模型的一次迭代过程,一般控制一次在两周左右完成,架构基线迭代周期可以长一些,而且也不要刻意追求每次迭代的过程阶段完整性。

3 质量保证规范

质量保证规范有很多借鉴的标准,如ISO CMM,但在现实中往往只要借鉴一部分就可以了,质量保证的核心内容是配置管理和Review评审。配置管理中首先选择一个合适的版本控制服务器,CVS绝对值的推荐。然后是代码的管理,规划好目录结构是很重要的,这个工作常常被忽略,目录结构树能让人马上找到自己想要的,所有与项目有关的资料都该在这个目录下,这个目录除了源代码外还应该包括:文档,运行测试环境。特别提一下源代码目录的规范,一般是按模块分文件夹,再在子文件里按架构的层次分,比如web、Controller、model、ado、EJB等,文件夹不要用大写。

编写一个编译脚本非常重要,虽然开发工具都带编译调试功能,但编译脚本可以方便实现自动化编译,而且不依赖于开发工具。例如C的Make,java可以用ANT,不需要很多时间学习,却可以大大提高项目配置管理的质量。基于编译脚本就可以要求小组成员每天上班checkout代码,然后运行脚本,每天下班必须Commit修改的代码然后update得到最新代码再编译,项目build工程师可以在一定时间运行脚本,发布一个milestone的版本,同时给CVS打上tag,提交给测试人员。这些就是所谓Nightly Build过程,Milestone Release。Milestone版本可以直接提交给客户,让其提供最直接的反馈,以实现项目在可控可见的范围内进行。甚至可以在合同里跟客户约定milestone,跟客户的费用支付直接挂钩,这样可以大大降低风险,也可以让客户完全有信心,保证项目不会偏离客户需求。这就是持续集成,XP极限编程的精髓所在。

软件质量保证的核心应该就是Review,包括代码Review,文档Review。每个制品(文档或者代码实现)产生后,必须经过第二者或者第三者的评审,评审主要是文档是否表达足够清晰,是否符合小组习惯格式。代码实现主要是看代码实现是否符合技术架构的框架,是否重用了公共方法,代码句法是否是符合规范,注释和可读性是否符合要求。Review保证了技术框架不会因为功能越来越多而变得越来越乱,越来越偏离其既定规范,而且代码评审也常常能够发现一些很隐蔽的Bug。

4 小结

本文总结了一个J2EE项目开发过程,汇集了一个项目中会涉及到的各方面的知识,希望可以为一些新组建的项目组提供参考。项目中遇到的情形往往各有各不同,而采取的应对方法也可以不尽相同,保持项目管理的灵活机动始终是重要的。既要坚持一个稳定的项目开发制度,又不能教条地遵守种种规则。

参考文献

[1]覃征.软件项目管理[M].北京:清华大学出版社,2004.

[2]Jalote P.Software project management in practice.北京:清华大学出版社,2005.

[3]张青.软件项目工程管理[M].成都:电子科技大学出版社,2006.

[4]郭宁,周晓华.软件项目管理[M].清华大学出版社,2007.

[5]张念.软件项目管理[M].北京:中国水利水电出版社,2008.

软件项目管理过程分析论文 篇2

班级：——

学号：——

姓名：——

软件项目管理是为了使软件项目能够按照预定的成本，进度，质量顺利完成，而对人员，产品，过程和项目进行分析和管理的活动。根本目的是为了让软件项目尤其是大型项目的整个软件生命周期（从分析，设计，编码到测试，维护全过程）都能在管理者的控制之下，以预定成本按期，按质完成软件交付用户使用。

——序

当今世界，IT技术对于一个企业的重要性是毋庸置疑的。在很多领域，计算机技术都得到了非常广泛的应用，IT技术已经普遍地服务于社会的各行各业，在很多的领域都形成了推动力。但同时我们也看到一个非常严重的问题，那就是软件危机。为什么会发生“软件危机”。据总结，主要产生的原因是：（1）由于缺乏软件开发的经验和有关软件开发数据的积累，以致经常出现超出经费预算，无法遵循进度计划。（2）软件需求在开发的初期阶段不够明确，或是未能得到确切的表达。开发工作开始后，软件人员和用户又未能及时交换意见，造成矛盾在开发期几种暴露。（3）未能在测试阶段做好充分的检测工作，提交至用户的软件质量差，在运行过程中暴露出大量的问题。归结起来，我们说的软件危机是一种矛盾，就是弱的软件生产力能力与强的业务发展需求之间的矛盾。要能够迎接业务发展所带来的挑战，从事软件生产的组织迫在眉睫要去做的一件事就是软件生产力的改造。在“应用就是业务”的今天，软件生产力的改造是决定企业能否获得并长久保持竞争优势的一个决定性因素，所以，关注并启动软件生产力的提升是一项战略性的决策，是一个系统工程，它将决定企业能否获得并长久保持竞争优势。而项目管理则是提升生产力的一项重要任务。

然而，项目管理在我们的软件生产中的应用是那么的重要。那么我们应该怎么样才能更好的掌握项目管理，我们的项目流程是怎么样的。

首先，项目管理的第一流程是项目的启动。

项目的启动就是确定项目的目标范围，它主要包括开发和被开发双方的合同（或是协议），软件要完成的主要功能以及这些功能的量化范围，项目开发的阶段周期等。尤其是启动信息技术（IT）的项目，我们做软件的必须了解企业组织内部在目前和未来主要业务发展方向，这些主要业务将使用什么技术及相应的使用环境是什么。启动信息技术（IT）的项目的理由很多，但能够使项目成功的最合理的理由一定是为企业现有业务提供更好的运行平台，而不是展示先进的IT技术。在项目启动的过程中，我们还要注意将项目的范围进行明确定义才能进行很好的项目规划。项目目标必须是可实现可度量的。如果这一步管理得不好或是做得不好，直接导致的是项目的最终失败。

其实，第二就是项目的规划

项目的规划其实就与项目的计划意义差不多。它是一项复杂的，自始至终不断迭代的一个过程。而且为项目的运作提供可靠的实施基础。在整个项目中，项目规划是指项目的估算，风险的分析，进度的规划，人员的选择与配置，产品质量的规划等。然而，在项目管理的过程中，计划的编制是整个项目规划中最为复杂的阶段。项目计划工作涉及九个项目管理知识领域。也就是说我们要知道九个项目管理知识领域中哪些是重要的，哪些是必要的和熟悉它们之间的关系。而且在计划编制的过程中，我们还可看到后面各阶段的输出文件。所以说它是指导项目的进程发展。规划建立软件项目的预算，提供一个控制项目成本的尺度，也为将来的评估提供参考，它是项目进度安排的依据。最后，形成的项目计划书将作为跟踪控制的依据。

第三：项目的实施及控制

一旦建立起基准计划就必须按照计划执行，这包括按计划执行项目和控制项目，以使项目在预算内，按进度，使顾客满意的完成。在这个阶段，项目管理过程包括：测量实际的进程，并与计划进程相比较。同时，发现计划的不当之处。为了测量实际的进程，掌握实际上已经开始或结束的是哪些任务，已经花了多少钱，这些都是很重要的。如果实际进程与计划进程的比较显示出现项目落后于计划，超出预算或是没有达到技术要求，就必须立即采取纠正措施，以使项目能恢复正常轨道，或是更正计划的不合理之处。然而，项目的监控，也是为项目能正常回到轨道上的一个重要步骤。俗话说：“没有跟踪就不算完成”，在软件项目中，有太多的工作需要我们去完成，如果有时计划做得不够周密，或是计划赶不上变化。我们怎么办，置之不理？还是去跟踪监控一下，然后及时改正错误。为什么我们用的那么多的软件是要不定时的安装补丁，原因也就是因为这个。在跟踪监控中我们发现问题，然后去修补它，使得软件的性能，功能更好。总得来说。项目的实施及监控最终的目的就是保证项目能够安装预先设定的计划轨道上行驶，使得项目不要偏离预定的发展进程，尽快完成软件项目。

最后就是软件的项目结束

项目管理的最后环节就是软件项目的结束过程。因为项目的特征之一就是它的一次性。有起点也有终点，进入项目结束期的主要工作是适当地做出项目终止的决策，确认项目实施的各项成果，进行项目的交接和清算等，同时对项目进行最后评审，并对项目进行总结。这个也代表着项目将进入后续的维护期。项目最后执行的结果是有两种状态，要不就是成功要不就是失败。然而，一旦我们决定终止一个项目，项目就要有计划，有序的分阶段停止。当然，这个过程可以简单地执行也可以详细认真的执行。在这里项目总结是项目结束中的最后一个环节也是一个我们不能忽视的一个环节。很多项目没有能进行很好的总结，比如说项目总结时项目人员已经不全了，有新的项目要做，没有时间去写等等的理由让项目的总结没做好。所以，这也是软件项目那么多漏洞的原因之一。所以，项目的结束之前的工作我们也要好好认真的完成。

软件开发不同于其他产品的制造，软件的整个过程都是设计过程（没有制造过程）。另外，软件开发不需要使用大量的物质资源，而主要是人力资源；并且，软件开发的产品只是程序代码和技术文件，并没有其他的物质结果。基于上述的特点，软件项目管理与其他项目管理相比，有很大的独特性。所以，软件项目开发管理过程中，不仅要努力实现项目的范围、时间、成本和质量等目标，还必须协调整个项目过程，以满足项目参与者及其他利益相关者的需要和期望；随着软件规模和所涉及的领域不断地扩大，软件项目的管理越来越困难。纵观所有失败的软件项目，基本原因是不能管理其软件过程，在无纪律的、混乱的项目状态下，组织不可能从较好的方法和工具中获益。严谨的软件过程控制与管理不仅可以在每个阶段回顾和纠正项目的偏差，识别软件项目的风险甚至果断中止项目，而且可以将人才流动所带来的不利影响减少到最小。要进行有效的过程控制，必须明确软件项目管理流程。

最后，总结一下项目管理过程。软件项目管理不同于其他的项目管理，它有很多的特殊性。软件是一个特殊的领域，远远没有建筑工程等领域那么规范化、软件目前有很大的发展空间，经验在项目管理中发挥着很重要的作用，理论和标准还在发展中，它体现软件的“软”的特殊。合同启动了一个软件项目，同时贯穿项目的始终；根据合同进行软件的需求分析，获得需求规格；根据需求规格进行任务分解，任何分解的目的是可以很好得规划和管理项目；根据任何分解的结果，给出项目需要的资源，以便于估计活动的历时，最终编制项目计划以及项目的预算等。这样便可以形成项目的三个核心的基准计划：项目范围基准，成本基准，时间基准计划等。

软件项目管理过程分析论文 篇3

关键词 高校管理 教务管理信息系统 发展

中图分类号：TP3 文献标识码：A

1教务管理信息系统的初形和功能

社会在发展，科技在创新，计算机已成为人类进步的关键技能和因素。教务管理软件的发展是随着计算机的发展而发展的，它是从原有单一的程序到可实现多个功能的程序集合，即教务管理子系统的初形。因此，我们可以从计算机的操作系统和相关数据库系统软件的发展来分析教务管理软件的演变过程。

1.1教务管理信息系统的初形

1987年2月，在数据库系统软件应用方面，美国FOX公司推出了多用户关系型数据库管理系统，FOXBASE+系统，由于其性能优越，很快在我国得到广泛的应用和普及。由于我国计算机发展的滞后，在90年代中，教务管理人员提出把实现单一功能的程序集合起来的要求，很快程序开发人员把这些实现单一功能的程序进行分类集结，形成可实现多个功能的程序集合，此时的教务管理软件功能开始增强，处理的数据也增多了，开始形成教务管理子系统的初形。

1.2教务管理信息系统的功能

我国的计算机发展相对比西方慢，在90年代初，才利用数据库管理系统进行编程，应用到教务管理上，当时的教务管理信息系统算不上是系统，只是一些实现单一功能的程序。这些程序有：学生学籍数据录入程序，打印学生名单、打印各类成绩单等。

2教务管理信息系统的形成过程

教育事业正在高速发展，高校和高职院校的数量显著增长，学校办学规模不断扩大，学生人数不断增长，这些变化对原有高校的教务管理信息系统提出了更多的要求和功能。随着计算机技术的不断发展，开发教务管理信息系统所采用的操作平台、开发工具和后台的数据库管理系统有很多。该系统主要是由各子系统组合而成的，已实现多种功能为主，同时达到远程数据传送效果。这个阶段采用DOS操作系统，数据库软件方面有更高版本的FOXPRO。如FOXPRO 2.6 FOR DOS，它是一套关联型数据库管理系统程序，其功能完整，用户界面比较友好，便利阅读的表格来编排数据元素的，使用户轻易地储存、组织、管理及打印平日工作上的各种数据，因此用这套软件开发教务管理系统的学校很多，并且有计算机公司开始参与开发，专业技术开发人员介入到教务管理信息系统的开发中。

操作平台方面有Windows、UNIX、Linux。作为一个处理数据量相对不算大的教务管理信息系统，采用Windows操作系统已基本足够了。计算机网络技术的快速发展，以及为了满足应用软件在网络上的使用，微软公司在2000年推出了构建于客户机/服务体系结构的Windows2000系列操作系统，实现用户应用软件的网上操作，数据共享。前台开发工具方面，采用Power Builder、Delphi、ASP.NET、FrontPage等，而采用Power Builder作为前台开发工具的用户比较多，它是目前较流行的开发工具。后台数据库管理系统应用方面也有很多，如规模较大的采用SQL Server、Oracle、Sybase等大型数据库，规模较小的采用Acces、Foxpro等小型数据库。

3教务管理信息系统的发展趋势

为了落实教育部的《面向21世纪教育振兴行动计划》安排，推动教学资源建设，推广现代化教育技术在教学和教学管理中的应用，促进教育整体质量和办学效益的提高。从教育主管部门，到各高校以及计算机技术开发公司都积极面对，通过多方技术支持参与和开发教务软件，到两方面的发展势头。

3.1教育部门的推动力量

国家教育部信息中心作为全国高校管理软件的推广、培训部门，一直致力于高校教务管理软件系统的开发工作，它所开发的《高等院校教务综合管理系统》，从教务管理的实际流程出发，将所有数据处理集成在一起，实现真正数据共享，彻底解决数据安全性问题，为教务管理人员解决了很多烦琐的工作，减轻工作的负担。

3.2学校的研发力量

随着学校办学规模的不断扩大，管理水平不断提高，原有的管理模式和手工处理方式已很难跟上形势发展的步伐，只有运用信息技术进行科学管理，才会有助于提高教育管理工作效率。因此，很多高校根据自己的实际，充分利用学校的人才资源和技术资源，自行开发适合自己学校管理的教务管理信息系统。为各级学校开发校园网，开发教务管理信息系统以及办公自动化系统，大大提高学校的教育和教学管理的效果。

总之，学校的主要工作重点是教学工作，如何科学高效的落实教学工作，为教学工作做好统筹、规划和服务。计算机的教务管理信息系统是当今学校提高教务管理工作效率的重要手段，只有科学高效的灵活运用教务管理系统，才能使学校更加重视系统内容，也有效的助推了系统的应用和研发，从而加快了学校信息化管理的进程。

参考文献

[1] 吴企渊，梁燕等.计算机操作系统[M].北京：清华大学出版社，2000.

[2] 陶志穗等.计算机应用初级教程[M].广州：广东高等教育出版社 ，2003.

[3] 朱爱民等.Power Builder9.0与系统开发[M].北京：清华大学出版社，2003.

软件项目管理过程分析论文 篇4

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.

软件项目需求分析总结 篇5

软件项目需求分析总结

需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键 总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况： 客户本身说不清楚 文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。需求自身经常变动 随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。分析人员或客户理解有误 毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。由此出现的问题： a)需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。b)需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。c)需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。d)对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。e)项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计（软件的成熟度）方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。f)此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。结论 a)需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。b)需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。c)需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。d)需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生 e)需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。f)需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题 g)帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解 h)最后，需求分析报告一定要双方共同签字确认。

软件项目管理过程分析论文 篇6

随着社会经济的飞速发展, 计算机在企业管理中应用的普及, 技术过程控制与应用环境分离已不再可能, 实现技术过程控制管理, 不仅可以使企业人员以最少的劳动和最短的时间取得足够的、可靠的、准确的信息, 还可以从简单的数据录入、收集、汇总等重要繁琐的事务中解脱出来。更重要的是为生产技术质量控制的实际应用打下了基础。

任何一个机械工业企业要生存、求发展就必须生产出满足需求的产品, 而这些产品的形成必须经过市场调研、开发设计、生产技术准备、采购、生产制造等过程。工艺技术、工艺管理作为纽带, 将它们连接成一个整体。本文主要介绍了通过工艺准备过程管理软件对工艺准备中的过程进行监控和调度, 把投入生产前的各项准备过程信息按规律组织起来, 只有对多种信息进行智能化的管理, 才能为企业后续生产加工提供技术质量保证。

2. 系统组成

工艺准备过程管理软件主要由工艺系统管理、工艺准备过程配置、工艺信息录入、工艺准备过程管理、系统服务等七大功能模块组成 (见图1) 。

其中, 工艺系统管理模块主要是通过定义不同级别的用户角色, 设置相应的权限, 从而有效地根据系统地理位置分布不同、职能部门不同的用户进行管理, 同时, 为确保工艺准备过程信息的安全性, 在这里操作者可以对各级别用户使用权限的密码进行设置;工艺准备过程配置模块主要是对工艺准备过程中的管理人员、执行人员、审查人员制定的;工艺信息录入模块主要记录工艺申请报告、工艺评审报告、项目评审记录等信息, 通过这些信息记录, 可以及时、准确的了解现阶段设计和开发的工艺是否符合设计要求, 从而保证工艺文件的正确性、合理性、可生产性和可检验性;可以根据工艺准备过程管理模块中的八个子过程来检验该工艺准备及完成情况;在系统服务模块下, 工艺员可以利用WORD或EXCEL为使用模板调用数据库中的信息。

3. 关键技术

工艺准备过程管理软件的关键技术在于它是一种基于工作流的开放式快速工艺准备过程管理技术, 因此过程管理、数据管理、组织管理决定着整个系统架构。

(1) 过程管理是整个系统的核心部分。它管理着系统的执行、活动及操作过程, 包括:工艺审查、设计工艺方案、设计工艺规程、设计工装、工艺验证等流程, 其中工艺审查、设计工艺规程、设计工艺下又可分为多个子过程而工艺设计方案、工艺验证、工艺总结则不可以继续分解。

(2) 数据管理从数据功能的角度出发, 根据系统过程中所需的相关数据如:工艺方案、工艺过程卡等设计结果数据和工艺评审数据。从数据格式角度, 工艺准备中的数据包括用数据库形式描述的格式化数据和用文件形式描述的图形文档数据等 (见图2) 。

(3) 组织管理在企业的生产中表现为既要体现专业分工的特点, 又要体现项目管理的特点。专业分工保证了技术工种间的协调, 项目管理则体现了产品研制过程的控制。该工艺准备过程管理软件, 主要按XXX厂的工艺准备实际情况来制订, 组织机构划分为车间级, 车间主管工艺主任、专业工艺师和各工艺室主任、专业工艺设计员和管理员四个基本组织层面。图4是控制工艺准备执行过程的界面, 它显示了正在运行的过程实例, 并可以查看各个过程实例的流程图及进展情况, 还显示了过程中各个活动的状态。

4. 运行环境

(1) 开发环境

本系统在Microsoft Windows XP下进行设计开发及调试, 前端客户程序以Delphi8为软件开发程序, 后台数据库为Oracle。

(2) 运行环境

操作系统:Windows XP、Windows 2000、Windows 2003;

支撑环境:Oracle数据库;

硬件环境:奔腾Ⅱ或以上型号微机, 32M以上内存, 4.3以上硬盘。

5. 结语

本软件是结合兵器集团XXX所快速工艺准备与过程优化技术需求研发的, 通过生产前工艺过程管理模块、数据管理模块、组织结构管理模块的建立, 实现工艺准备过程开放式优化管理, 这种开放式工艺准备过程管理, 是一种贯穿计划、设计、制造和管理全过程的协同工作环境, 是对生产过程中的工艺信息进行协调的统一管理。

软件项目开发过程中的需求分析 篇7

1 软件开发项目需求分析

在软件项目的开发过程中, 尤其是对于大型软件项目的开发, 开展需求分析是非常重要的环节。在软件项目的开发过程中使用需求分析, 即通过文档的形式研究用户关于软件项目系统的使用目的、使用功能、使用可靠性等, 从而使得所开发出来的软件项目更加符合用户的需求。在运用需求分析的过程中, 主要需要做好以下几方面的内容:首先需要识别用户的需求问题;其二需要分析和汇总用户需求;其三需要对用户各种不同的需求建立相应的文档;最后还需要对所建立的文档进行评审。由此可见, 应用需求分析, 需要软件项目的开发人员与软件项目的使用人员共同参与完成。

随着现阶段软件项目开发数量的日益增多以及软件项目开发的复杂程度日益增大, 在整个软件项目的开发过程中, 需求分析起着至关重要的作用。可以说, 没有做好相应的需求分析, 将会给整个软件项目的开发造成极大难度。特别是对于一些大型软件项目的开发, 一旦不能及时掌握用户的需求动态, 将会使所设计的软件项目很难满足实际的使用需求, 从而将会造成较大幅度更改, 进而产生巨大的资金及人力浪费。

2 软件开发项目需求分析存在的问题

2.1 用户参与度不足

由于需求分析的应用主要是对用户实际的使用系统进行使用功能、使用性能以及使用可靠度等方面的分析研究, 一旦用户不参与到需求分析的实际工作中或参与程度不够, 那么将会导致整个需求分析工作无法正常开展。虽然软件项目的开发人员对于系统的开发以及软件项目各方面的特性都非常熟悉, 但是大部分软件用户对软件项目的实际功能、性能等并不是十分了解, 进而导致用户对于系统相关的特性描述不全面, 导致软件项目的开发人员无法真正掌握用户的实际需求。这样势必会导致所开发出来的软件项目不能完全满足用户的实际心理需求, 进而会出现返工现象, 从而给软件开发企业带来巨大的人力和财力损失。

2.2 用户需求的不确定性

在运用需求分析的过程中, 如果用户对自身的使用需求不够确定, 那么将会给整个软件项目的开发工作带来极大难度, 不仅可能大幅度增加软件项目开发的复杂程度, 同时还可能出现软件项目规模不可控等情况。此外, 如果用户的需求不能确定, 那么可能导致软件项目的代码结构出现变化, 这就打破了代码规范中“高内聚、低耦合”的原则, 从而进一步加大了代码维护的难度, 最终导致所开发的软件项目的各方面性能受到影响。因此, 对于用户需求不确定的情况, 需要采取有效的措施来解决。

2.3 需求分析深入度和全面性不足

对于软件项目开发的需求分析需要做到彻底、深入, 并且还需要十分全面。然而在实际运用过程中, 由于对于需求分析的深入度不够, 导致所开发的软件项目可能出现功能划分、功能定义出错等问题。另外, 由于需求分析的不够全面, 可能导致用户所需求的一些功能不能完美展现, 这样有可能导致软件项目在使用过程中出现结构破坏的情况。由此可见, 对于需求分析的运用, 需要双方的共同努力, 从而使得所开发出来的软件项目具有更加完整的功能和特性, 以更好地满足用户的实际需求。

3 相应的解决措施

3.1 加强用户与开发人员的合作

为了保证在软件项目的开发过程中能够更好运用需求分析, 加强用户与软件开发人员之间的合作意义重大, 这是做好软件项目开发需求分析的基础和前提。在实际的需求分析过程中, 由于认知方面的问题, 用户对于软件系统的功能及特性认识肯定会存在一定的偏差, 而设计人员由于具有足够的专业知识, 能够准确掌握相应的性能和特点。加强软件用户与软件项目开发人员之间的合作, 能够使得开发人员帮助用户更加全面深入地了解软件系统, 从而使得软件开发人员能够更加精确和全面地掌握用户的实际需求, 从而有利于整个软件项目开发过程更好进行。

3.2 做好系统各类需求的状态跟踪

由于在运用需求分析时不仅需要分析软件系统的运行环境, 同时还需要考虑软件系统的稳定性、功能性等条件, 因此, 需要在需求分析的过程中加强对软件各类需求的状态跟踪。对于软件系统中数据结构的定义、子模块的功能和定义等进行有效的状态跟踪, 从而保证各模块的实际功能做得更好, 最终确保能够满足用户的整体需求。

3.3 提升需求分析的完整性和一致性

除了需要做好以上两方面的工作之外, 在需求分析的应用过程中, 还需要保证需求分析的完整性。保障用户软件系统实际需求功能及特性的完整性, 以保证软件系统能够更好地被用户使用。同时还需要保证软件系统的整体功能与各模块功能之间的一致性, 这样能够确保整个软件项目系统具有更高的稳定性。

3.4 运用好需求分析的各种开发工具

最后, 需求分析过程中所形成的各种文档, 是软件项目得以更好开发的基本参考, 因此, 还需要运用好各种开发工具加强对这些文档的审核和查阅, 从而帮助软件项目的设计者更好地掌握所开发系统的数据结构定义、所需要进行模块功能设计的图形等需求。运用好这些工具, 一方面有利于用户了解系统定义的准确度, 避免由于技术而引起沟通难题;另一方面有利于后续编码测试工作的顺利展开, 一些需求设计优秀文档甚至能够直接翻译成特定的编程语言。

4 结语

总而言之, 在开发软件项目的过程中, 及时掌握用户的需求, 根据用户对软件的实际需求功能开发软件项目意义重大。因此, 针对于软件开发人员与软件用户之间对于软件的需求存在差异的问题, 需要软件项目开发人员在开发软件项目之前, 充分收集用户的资料, 运用需求分析全面掌握用户对于软件项目的实际需求, 从而以更为专业的态度为用户开发出最佳的软件项目, 以实现软件企业更好发展。

参考文献

[1]张建成, 田青, 李刚.软件工程需求分析方法探讨[J].信息技术与信息化, 2010 (6) :74-77.

[2]樊林赋.面向IT项目的需求分析管理的方法研究及应用[D].上海:上海交通大学, 2012.

软件项目设计过程管理探讨 篇8

1.1 软件设计过程的内涵

软件的设计过程是指软件工程人员为了获得特定功能与性能的软件产品, 而在一系列软件的支持下所进行的软件开发工程活动。简而言之, 软件设计过程就是将需求转变为软件表达的过程。

那么如何将需求转变为了软件表达呢?这里首先要明确的是什么是需求。这里所说的需求, 主要包含功能需求和性能需求, 在一些特定的软件项目开发过程中, 可能还需要进行数据需求的分析。只有明确了软件系统的功能需求、性能需求和数据需求, 才能够有针对性地进行软件项目的开发设计。其次, 还需要明确的是软件设计过程一般分为两步, 第一步是初步设计。所谓初步设计就是将之前所分析的软件系统的性能需求、功能需求和数据需求转换为数据表或者软件框架只有确定了数据表或者将软件框架, 才能够在此基础上进行有针对性的特定功能开发与实现;第二步是详细设计。所谓详细设计, 就是指将之前所建立起来的数据表和软件框架, 逐步求精和细化, 最终实现软件系统所要求的功能或者性能转变为具体的数据结构或者软件算法, 而且其中每一个细化过程中出现的数据结构或者软件算法, 都需要配以合适的软件界面进行显示, 以提供良好的人机交互桌面, 并且要将软件界面和数据结构、软件算法时刻保持统一, 以提高软件项目的整体一致性和系统性。

1.2 软件设计流程

要想做好对软件项目的过程管理, 首先必须明确软件的设计流程。因此, 这里首先对软件项目开发的流程进行简要分析。

软件设计过程一般很难用文字语言表述完整清楚, 目前也没有统一的表达能够说清楚软件开发的过程, 但是结合以往的开发经验, 现在的软件工程师都已经清楚认识到, 目前开发出来的支持数据流图、层次式输入输出结构图等相较于传统的流程图能够更加精确、清晰地反映出软件项目开发的需求和框架细化精确的层次步骤。

概括来说, 软件设计的一般流程可以分为以下几个步骤:

(1) 需求分析。首先需要对软件系统进行需求分析, 正如上文所分析, 需要进行功能需求分析、性能需求分析和数据需求分析。

(2) 子系统分离。在明确系统需求的基础上, 需要对整个软件系统进行子系统的划分, 只有对一个大型软件项目系统进行合理的分割, 甚至是分割成若干软件算法或者数据结构等, 才能简化软件设计系统的复杂性。

(3) 层次优化设计。为分割后的每一个子系统进行层次设计, 并且需要明确不同子系统之间的层次关系, 为各个层次之间的数据流进行导向设计。

(4) 软件框架结构设计。根据系统的层次关系, 确定软件系统的框架结构, 并在此基础上确立数据表的结构, 为整个软件系统的功能实现和数据表达奠定技术基础。

(5) 数据表设计 (包含算法设计) 。结合系统的功能需求, 为数据表达设计合适的算法, 既要实现系统指定的功能, 同时还要满足系统的相关性能要求和质量验收标准。

(6) 界面设计 (包含操作设计) 。为整个软件系统设计合理的人机交互界面, 包括人机操作交互设计及其操作响应的设计, 都包含在此步骤中。通过界面设计完成数据表达和软件算法的外封装, 将封装接口留给用户自行使用或者进行二次开发。

(7) 整体测试。根据所设计的软件框架结构、数据表结构、软件算法以及界面操作功能, 结合系统需要实现的功能需求和性能需求, 对整个软件进行白盒测试与黑盒测试, 确保整体质量达到预期的设计要求。这里需要说明的是, 设计阶段的测试主要是功能性单步调试, 需要待软件整体功能完成后才能够进行各功能的单元测试及系统集成测试。

2 软件项目设计过程的管理建议与措施

2.1 对软件项目的进度、质量和成本进行全过程跟踪管理

软件项目开发最在乎无非是项目的进度、质量和成本, 因此要实现对软件项目的过程管理, 就必须以软件项目的进度、质量和成本作为突破口, 对软件项目的进度、质量和成本实施全过程监控管理, 才能够实现对软件项目的全过程管理。具体来说, 对软件项目的进度、质量和成本实施全过程监控管理, 可以从以下几个方面着手:

2.1.1 合理设置软件项目的里程碑标志

按照软件开发计划的进度安排, 为软件项目的开发进度设置阶段性里程碑标志, 也可以进一步细化为大里程碑和小里程碑。确定了里程碑, 软件开发的每一阶段也就确定下来了, 可以依据每一阶段的软件开发, 为软件项目配备合适的人力资源、软件开发资源以及必要的技术支撑等, 就能够按阶段实现软件的开发设计工作。按照软件开发计划的进度, 细化分配到每个编程人员软件模块完成时间表。由项目负责人监督项目进度, 并与开发小组上报的日报、周报进行核对, 及时更正项目进度偏差。倘若由于某一环节时间发生偏差, 项目负责人也可以对里程碑适当进行调整, 从而保证进度管理的灵活性, 也从另一个方面保证软件项目开发的质量。

2.1.2 进行阶段性单元测试

为了保证软件开发的质量, 需要在开发的过程中进行阶段性测试, 包括功能测试、性能测试、容错测试以及安全测试等等。这里所说的阶段性测试主要是指单元测试。要按照软件设计开发的进度进行相应的单元测试, 因为每一阶段都有不同的测试内容和测试目的, 应该在软件开发设计的相应阶段之前就确定好测试的手段、方法以及相关测试报表。如果测试成功, 则可以顺利进入到下一里程碑阶段;如果测试失败, 则应当详细分析导致失败的原因, 指出功能测试或者性能测试的缺陷, 同时完成测试报表, 以供后向通道的测试。如有必要, 应当对系统发生失败的测试项目逐条语句进行单步调试, 直至完成阶段性测试。

2.1.3 对软件开发费用进行控制

一般而言, 当软件系统的功能需求和性能需求分析完毕后, 只要确定好系统的里程碑标志, 即可确定软件系统开发的相关资源, 严格来说软件系统的开发成本基本也已经明确了, 因此对于软件开发的可预见性成本的控制是不难的, 关键是在开发过程中, 需要对一些不可预见性的成本开支进行严格控制, 如设计更改、人员调整等等, 这些因素都有可能导致软件系统开发的成本大幅上升。因此, 软件系统的成本管理重点是要控制不可预见性的成本费用。

项目经理或者项目负责人正确的决策是减少项目不可预见费用的重要因素, 错误的决策会导致项目部分返工, 甚至于项目方案变动, 造成人力物力的浪费。

2.2 对软件设计过程进行监理, 重在沟通

过去软件系统的开发过程管理存在着一个误区, 就是重管理轻监理。在这样的管理方针下, 很多软件工程师在实际开发设计过程中会感觉束手束脚, 最后不是质量打了折扣, 就是开发周期一拖再拖, 管理效果差强人意。因此, 要加强对软件设计过程的管理, 就必须改变这一传统的管理手段, 对设计过程重在监理, 强调沟通, 发挥效率, 真正为软件设计的过程去服务, 而不是去管理。

沟通主要包括跟用户进行沟通和开发团队内部的沟通。开发团队与用户沟通在需求分析阶段要做到最大可能的到位, 用户方的技术人员和用户方的高层在需求理解上经常会不一致, 在项目开发过程中会提出需求变更或者添加功能需求, 用户方的高层之间也会有不同的意见。因此正确全面地把握用户需求, 才能做出最正确的决策, 拿出最经济有效的方案。

开发团队的沟通管理重在监理, 对软件设计过程的人力、周期、质量、资金等等进行监理, 当发生偏差时就进行自上而下的沟通, 再自下而上进行信息反馈, 这样既不会束缚软件工程师的手脚, 同时对于软件设计本身而言, 其质量、进度和成本在经过有效的沟通和反馈之后, 依然在项目管理轨道上行进。

需要说明的是, 这里强调的沟通并不是指出现问题, 大家坐下来讨论问题出现的原因, 然后提出解决的办法和措施, 这样无疑是耽误了软件设计的周期。这里所强调的沟通, 实际上是指当监理人员发现软件设计开发过程中某一指标或者某些指标发生了偏离, 与项目协调员或者项目专员进行沟通, 由项目专员与软件工程师进行沟通协调, 在进行设计的过程中实现自下而上及自上而下的双向信息流通。

2.3 对软件设计过程中产生的设计文档严格要求, 对开发过程记录严加管理

软件设计过程中产生设计文档、记录, 必须按照软件工程开发规范, 与实际的代码一一对应。一套高水平的规范文档, 可以将在项目中的开发人员由于各种原因离岗带来的项目进度损失、人力资源损失都记录在内, 这样新来的开发人员看着文档就可以接替这个岗位的工作。对软件设计开发过程实行文档管理, 不仅仅是为了防范岗位接替带来的损失, 更重要是依靠完善的文档管理, 能够对软件开发设计过程中的任意一个环节都可以进行回顾、监测;在强调弱化管理、加强监控的软件过程管理模式的同时, 只有依靠文档管理, 才能够最终实现对软件开发设计过程细致入微的管理。

2.4 软件设计模型选取和注意项目积累

开发团队在经过一段时期的开发后, 有了一定项目经验和技术积累。当新的项目需求与以前的项目需求很接近时, 可以采用原型法开发, 列出需求变化的部分和新增的功能、要删掉的功能, 这样可以沿用前项目的开发文档 (当然要根据项目修改) 和开发方案、思路、技术, 进行快速有效的开发。新开发的项目成功后又可以作为以后项目的原型, 这也是软件构件重用的基本思路, 这样能够利用积累下来的软件模型、程序代码和开发经验, 实现高效的组装式的软件开发程式, 大大降低后续软件开发的出错率, 极大地提高后续软件开发的稳定性与可靠性。

2.5对软件设计过程中的部分软件功能模块化以供复用

软件模块复用是软件快速高效开发中经常用到的, 对某特定行业、特定需求, 特别约定俗成的软件功能需求尽量提出来设计成软件模块。将软件开发设计重复使用的一部分称之为软件构件, 这是近几年来逐步盛行的一种高效、低成本的软件开发模式。重复使用某一软件构件, 首先需要明确该软件构件定义中所使用的技术标准和规范, 倘若连技术标准语规范都无法明确, 那么很难保证利用该软件构件开发出来的软件具有全局统一的技术规范, 从而软件的可靠性也无法得到保证。因此, 确定构件使用的技术标准与规范, 对于软件构件的应用也是基础技术保障。

3结束语

软件的开发设计已经逐渐成为第三产业中越来越重要的分支, 同时软件开发设计水平也标志着一个国家的计算机自主知识创新能力和水平。因此, 我国目前也逐步加大了对软件产业的投资, 从目前全国各地普遍兴建软件产业园就可以看出软件产业的强劲发展势头。要想做大做强软件产业, 质量是关键, 管理是根本。因此本文详细探讨了软件项目开发的过程管理, 给出了具体的过程管理建议与措施, 对于进一步提高软件开发设计的过程管理水平具有较好的指导借鉴意义。当然, 更多的软件过程管理措施还有待于广大软件工程师在实际开发设计过程中共同努力才能够最终得以落实, 并实现我国软件产业的快速、健康发展。

参考文献

[1]王长峰.IT项目管理案例与分析[M].北京:机械工业出版社, 2008.

[2]唐毅鸿, 杨朝晖, 刘倩羽.软件性能工程[M].北京:机械工业出版社, 2003.

[3]张文清.软件开发过程项目管理的研究[D].北京:首者经济贸易大学, 2005.

[4]吴吉义.软件研发中的项目质量管理过程研究[J].微型机与应用, 2007 (6) .

软件项目管理过程分析论文 篇9

“精简并行过程” (Simplified Parallel Process, SPP) 是基于CMM以及软件工程和项目管理知识而创作的一种“软件过程改进方法和规范”, 它由众多的过程规范和文档模板组成。SPP主要用于指导国内IT企业持续地改进其软件过程能力。

此处“精简并行”的含义是:

(1) 对CMMI 3级以内各过程域的内容和要求作了“精简”处理。

(2) 在产品生命周期之内, 项目管理过程、项目研发过程和机构支撑过程“并行”开展。

SPP模型把产品生命周期划分为6个阶段, 分别为:产品概念阶段, 记为PH0;产品定义阶段, 记为PH1;产品开发阶段, 记为PH2;产品测试阶段, 记为PH3;用户验收阶段, 记为PH4;产品维护阶段, 记为PH5。

在SPP模型中, 软件项目的过程有3大类:项目管理过程、项目研发过程和机构支持过程。上述3类过程可以细分为19个主要过程域, 分布在PH0到PH5的各个阶段。

项目管理过程包含6个过程域, 分别为:立项管理、结项管理、项目规划、项目监控、风险管理、需求管理。

项目研发过程包含8个过程域, 分别为:需求开发、技术预研、系统设计、实现与测试、系统测试、Beta测试、客户验收、技术评审。

机构支撑过程包含5个过程域, 分别为:配置管理、质量保证、培训管理、外包与采购管、服务与维护。

2 基于SPP的软件过程管理实践

2.1 项目案例

项目名称:云南某糖业集团综合管理信息系统。

项目概况:本项目主要内容为在充分分析用户实际需求基础上, 采用面向构件的设计方法, 基于J2EE系统架构, 开发并实施“云南某糖业集团综合管理信息系统”, 实现该糖业集团从甘蔗原料的种植、运输、生产到成品糖的销售全面的信息化管理。包括以下子系统:财务管理、农务管理、OA系统、生产管理、采购管理、库存管理、供应商管理、销售管理、人力资源管理。

2.2 过程模型定义

SPP模型的3类过程贯穿了产品的整个生命周期, 19个最常见的过程域都合理地安排在产品生命周期中的某些阶段。用户可以根据自己产品的特征, 适当地裁剪或扩充SPP的过程域, 很容易制定出最适合于本产品的过程模型。

我们根据项目系统功能较多, 涉及面较广、项目开发时间较紧等特点, 对SPP进行裁剪, 定义了如表1所示的过程模型。

2.3 软件项目过程管理实施过程

2.3.1 项目计划

(1) 由项目经理组织项目计划讨论会, 在讨论会上各开发负责人对自己所负责的模块所需要的工作量进行评估, 根据工作量和工程需求初步确定总体开发计划和发布时间;

(2) 写完成后发送给项目经理、相关的开发人员和测试人员;

(3) PPQA确认所有相关文档经过了评审并都已经commi到CVS。

2.3.2 需求开发与管理

(1) 由需求分析负责人统一接收糖业集团客户的相关规范和新需求, 需求分析负责人将规范和新需求转发给项目经理、相关的开发人员和测试人员, 同时commit到CVS;

(2) 需求分析负责人、项目经理仔细阅读规范与需求后, 对规范和新需求进行研究, 并就难点和疑点进行讨论, 整理出重点内容, 并将重点内容发给项目经理、相关的开发人员和测试人员, 同时commit到CVS;

(3) 项目经理、测试负责人、需求分析负责人、相关的开发人员与测试人员开会对规范、需求和重点内容进行讨论, 确定需求的具体含义以及最终实现的需求和功能点;

(4) 项目经理根据规范、需求和开会讨论结果编写出《需求规格说明书》与《功能列表》, 测试负责人 (或专门的需求分析负责人) 对文档进行检查并修改完善, 然后commit到CVS;

(5) PPQA (文档管理专员) 确认所有相关文档经过了评审并都已经commit到CVS。

2.3.3 设计与实现阶段

(1) 技术经理构思系统设计, 项目组开发成员一起讨论系统的设计, 对设计形成较为清晰的思路;

(2) 技术经理负责编写概要设计文档, 与开发团队成员与测试负责人一起讨论概要设计;

(3) 概要设计完成后, 技术经理编写详细设计文档、数据库设计文档和编码规范, 各模块负责人负责编写所负责的模块进行详细设计;

(4) 设计文档编写完成后, 发邮件通知项目经理、测试负责人、相关开发人员和测试人员;

(5) 技术经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的概要设计文档、详细设计文档进行审查, 将建议和意见以邮件的形式反馈给模块负责人;

(6) 模块负责人收集邮件中的修改建议并对设计文档进行修改, 同时回复邮件说明详细设计修改情况, 修改后的详细设计commit到CVS;

(7) 对设计存在争议或出现明显不合理的设计, 召开一个小型会议对异议进行讨论, 有效解决设计所出现的分歧;

(8) PPQA对开发最终修改的详细设计计划进行检查, 并确认所有文档都已经commit到CVS。

2.3.4 系统测试阶段

(1) 在项目的设计阶段, 测试负责人根据规范文档、功能列表和概要文档编写总体测试方案与性能测试方案;

(2) 测试方案编写完成后, 发邮件通知技术经理、项目经理、相关开发人员和测试人员;

(3) 技术经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的测试方案进行审查, 技术经理和项目经理对测试方案进行总体性的审查, 而各模块负责人则负责相关模块或功能的测试方案的审查, 将建议和意见以邮件的形式反馈给测试负责人;

(4) 测试负责人收集邮件中的修改建议并对测试方案进行修改, 同时回复邮件说明测试方案修改情况, 修改后的测试方案commit到CVS;

(5) PPQA对最终修改的测试方案进行检查, 并确认所有文档都已经commit到CVS。

2.3.5 系统部署及试运行阶段

(1) 编制计划。与用户方项目实施负责人商议具体测试及试运行时间, 地点, 人员等安排, 项目组编制《测试及试运行计划》。

(2) 签署计划。用户签署《测试及试运行计划》, 进一步确认测试及试运行安排。

(3) 发测试及试运行通知。在测试及试运行开始前2天, 按照签署的《测试及试运行计划》, 将时间, 地点, 人员等信息通知用户实施负责人。

(4) 搭建环境及数据准备。在试运行开始前搭建好软件环境、硬件环境、网络环境、调通线路;检查软件、硬件、网络、线路等各个环节是否有问题;

(5) 组织测试及试运行。用户相关各级领导给予全面配合, 组织相关人员进行测试及试运行。

(6) 测试及试运行总结。测试及试运行完成, 总结试运行中设备、软件的运行情况, 总结试运行中业务流程和操作环节的情况, 以书面总结形式将测试及试运行结果通知相关负责人。

2.3.6 系统培训阶段

系统使用人员计算机应用水平较低, 有部份人员还不会使用电脑, 系统培训阶段工作是整个项目实施工作中比较重要的工作, 此阶段的培训工作中将用户参加产品培训的人员划分为3个层次:决策层、技术层、操作层。

3 结束语

“云南某糖业集团综合管理系统”应用范围包括集团总部、8个分公司和子公司, 具有系统功能较多, 涉及面较广、项目开发时间较紧等特点, 严格、合理的项目过程管理将是项目成功的关键, 我们采用了上述基于SPP的软件项目过程模型, 结合该项目特点进行适当裁剪, 并创建了一套符合实际情况的实施方法, 有效地对软件项目过程进行了管理, 确保项目质量及进度, 成功开发出一套糖业集团综合管理系统。

摘要：对CMM及CMM精简并行过程进行了分析, 结合具体的项目案例, 在基于CMM精简并行过程模型基础上进行裁剪, 建立了符合项目实际情况的过程管理模型, 提出了一套符合项目实际情况的软件过程管理实施方法, 有效地对软件项目过程进行了管理, 保证了项目的质量及进度。

关键词：CMM,SPP,软件过程管理

参考文献

[1]RUZHI.http://www.mypm.net/blog/user1/runzhi/archives/2006/1256.html, 2006.

[2]霍英.面向小型软件企业/小型软件项目的CMM应用研究[J].计算机应用研究, 2007 (2) .

[3]林锐.软件项目管理与精简并行过程[J].计算机系统应用, 2004 (8) .

[4]SELIYA, N1, KHOSHGOFTAAR, T1M1, ZHONG, S1Analyzing soft-ware quality with limited fault-p roneness defect data[C].1Ninth IEEE International Symposium on High-Assurance Systems Engi-neering, 2005.

高校软件项目开发过程管理 篇10

进入21世纪, 随着软件工程学科的发展, 人们对软件开发过程管理的认识越来越深刻。管理是影响软件开发项目全局的因素, 而技术只影响局部, 许多问题不是出在不懂怎么做, 而是没有安排好, 做的次序不对, 或不知道如何做得更好。有效的软件过程管理, 有助提高软件的开发效率和生产质量, 降低生产成本。

目前软件开发深入各个领域, 高校作为国家重要的科研基地, 承担了大量的软件开发任务。高校软件开发组织不同于常规意义上的软件开发组织, 在软件开发过程上有其自身的特点和要求, 企业中已应用成熟的软件开发管理方法并不完全适用。为了适应这种特点, 必须结合高校实际, 对企业中软件开发过程管理方法做出适当的更改和调整。

1、高校软件项目开发的特点

高校软件项目开发多由教师和学生组织成临时团队协作完成, 其主要特点如下:

1.1 创新性强、研究性强, 项目难度大。

高校所涉及的软件项目, 和一般企业不同, 多属于前沿性的研究课题, 探索成分较多, 软件开发过程中, 需要查阅大量文献, 即时关注国内外研究动态, 软件需求经常变化, 修改较多。

1.2 开发团队成员新手多、人员流动大、管理经验欠缺。

教师和学生是高校软件项目开发的主力, 他们虽然有较好理论水平, 但实践经验非常不足, 对软件整个生存周期的管理体会不深, 管理意识薄弱。

1.3

高校软件开发项目和企业相比, 对于开发成本、用户意见、进度等方面的控制不如企业那样严格。

1.4 高校软件项目开发过程中, 经常会忽略测试阶段的工作。

开发人员的兴趣多集中在功能的实现上, 而对软件运行的性能关注不多, 预先测试工作很少, 这就造成事后不得不耗费大量力气去弥补。

2、高校软件项目开发的过程管理改进

基于上述特点, 笔者结合实际, 根据自己的实践工作经验, 对于高校软件项目开发过程的管理, 提出如下改进措施:

2.1 团队管理

团队管理要有纪律性, 分工明确, 责任清晰。可基于项目开展工作, 尽量采用扁平化的组织结构, 角色简洁, 不必要的角色设置及时删除并做优化调整。

2.2 文档管理

高校软件项目开发团队往往是基于某个课题成立的临时组织, 流动性大, 文档管理的不完善非常不利于知识的流动和传播。CMM作为软件过程管理的工业标准, 它的各个关键过程域对于文档的要求都严格细致, 高校软件项目开发过程中, 引入C M M过程规范可以有效保证文档管理的完整规范性, 但CMM管理复杂, 实际应用中, 需适当裁剪, 具体来说, 可以在开发的各个阶段设置几个结束点, 在这几个结束点上, 编写严格的规范的文档书写标准, 在结束点之前, 流水帐一样记录下所做所想, 将有关信息用更自由方式记录保存, 在某个阶段结束之后, 花一定时间来创建和对文档格式化, 只保留关键节点的文档, 从而有效节省文档开发工作量, 提高工作效率。

2.3 计划管理

项目启动之前, 应有大致实施计划。项目实施过程中, 项目负责人要不断对照原有计划进行工作调整。高校软件项目开发需求变更频繁, 同时, 软件开发自身的难度大复杂性大等特点也要求计划制订时不能跨越太长时间段, 要立足当前, 逐步推进, 逐步细化。高校软件项目开发在时间性上的要求要比企业弱一点, 要保证有充足时间完成研究过程, 但这并不是说高校软件项目开发就无时间限制, 在开发过程中, 可每隔两周进行一次小会讨论, 制订未来两周内详细的研究开发计划, 并对未来三个月内的工作做粗略规划, 下次计划的制订要紧密结合上次计划完成情况, 及时调整。

2.4 开发过程管理

在开发工作具体开始之前, 要制定详细的开发工作流程, 高校软件项目开发流程主要包括下面几个阶段:需求分析、系统设计、编码测试、收尾四个阶段。

2.4.1 需求分析阶段管理

和企业不同, 高校软件项目开发的需求除部分来源于客户需求, 更多的, 则来源于一些研究性课题研究的需要。这也导致高校软件项目开发的需求分析管理和企业有很大不同。高校软件项目开发的需求包括问题求解和需求确定两个部分。问题求解部分主要的工作是构思的形成、构思的筛选和概念的形成与评估, 其中, 牵涉大量国内外文献的研究和综述, 在构想确立的过程中要经常开会讨论, 由专家对构想进行初步评估, 全部审核通过后, 需由负责人撰写详细的问题求解报告, 在此过程中搜集整理的资料随同报告分类保存。需求确定阶段则针对问题求解报告, 编写详细的需求计划书, 有条件的情况下, 可采用一些快速开发工具针对需求设计开发原型, 开发原型应包括核心功能和关键难点的实现, 设计尽量的简单, 不求完善, 软件原型的设计可帮助预测需求的合理性, 以最快的速度得到需求反馈。需求分析书在最初设计时并不要求过分细致, 要抓住重点, 力求简单易懂, 在最终文档交付之前, 可进行多次迭代开发以尽可能的减少实际开发中的更改。

2.4.2 系统设计阶段管理

通用的建模工具如U M L可帮助进行系统整体设计。系统的分析报告应包括以下几个要点:系统整体的功能模块框架体系, 系统中的用户权限分析、系统整体运行流程和系统的数据结构构建体系, 此外, 还应包括关键难点的技术实现可行性。良好的系统设计可有效降低编码过程中的返工问题。

2.4.3 编码和测试阶段管理

高校软件项目开发中编码阶段, 最大不足是代码编写不规范, 变量函数的命名各成体系, 没有正式标准, 注释部分描写不清, 这就造成代码可读性差, 严重降低代码重用性。高校软件项目开发的另一大不足是对测试重视不够, 这就很难保证软件产品的质量和性能。结对编码对改善上述不足有很好效果, 由两人结对进行代码开发, 一人负责代码功能的实现, 另一人负责代码的可读性和运行的正确性和完善性。这样可有效提高代码编写速度, 使编写者更有信心, 同时可保证未来代码运行的正确性, 发现问题及时修改, 避免把所有问题积累到最后再做处理。在此阶段, 文档书写可以少一些, 关键部分有记录即可, 但代码要书写规范, 语句尽可能的精简清晰, 可读性可理解性要强。源代码的管理也是该阶段的一个重要工作, 常用的配置管理软件, 如CVS等可有效控制和管理版本的更改变动, 全过程配置管理, 有利于项目内统一的编码、测试, 保持一致性。

2.4.4 收尾阶段管理

在团队解散前, 收尾工作要做好, 整个过程中的文档和最终软件成果指定专人整理归类, 为后续开发和维护打下良好的基础。

2.5 跟踪管理

在软件项目开发过程中, 项目负责人的角色很重要, 要及时跟踪团队资源变更情况, 跟踪项目执行的范围和进展情况, 确定未做的有多少, 已完成的有多少。

2.6 培训管理

高校软件项目开发中, 可依据实际采用内外部培训、自我培训、专家指导等多种形式。培训内容要按具体情况展开, 一般来说, 新人培训应该包括组织内部已经形成的制度和纪律, 软件文档编写约定, 软件开发流程中的各项验收和管理标准, 团队的组织结构角色分工, 除此外, 可结合具体项目制订项目入门的快速指南。通过共同分析项目的目标和管理规范的必要性, 使分配的任务得到新加入的开发人员的认可, 有利于工作积极性的调动。

2.7 支持开发全过程的网络管理平台的构建

在有条件的情况下, 建立基于网络的软件开发全过程的协同工作平台可有效帮助提高软件开发过程的管理, 特别是对高校软件项目开发来说, 可在一定程度上解决开发团队缺少固定时间地点所造成的沟通缺失, 更好的保管归类开发过程的文档, 方便查询, 同时使团队成员对开发过程中的规范性有更深刻的理解。

3、结语

总之, 高校软件项目开发过程管理, 需从自身固有的特性出发, 一方面, 要逐步建立和完善规范化的管理模型, 另一方面, 在实际操作上, 要从现有环境和条件出发, 在项目不同阶段、不同团队和不同模块采用灵活多样的方法, 以期获得最佳的实践效果。

摘要：高校软件项目开发具有创新性强、变更频繁, 开发人员新手多、管理经验欠缺、流动性大等特点。其过程管理, 既要参照软件企业常用管理方式保证规范性, 同时又需结合自身特性赋予更多灵活性, 在开发的各个阶段, 需采取多种方式综合管理, 以平衡各方效益。

关键词：软件开发管理,敏捷管理,软件过程改进

参考文献

[1]张海藩.软件工程导论 (第五版) [M].北京:清华大学出版社, 2008

[2]萨默维尔, 程成, 陈霞.软件工程 (原书第8版) [M].北京:机械工业出版社, 2007

[3]唐俐威.软件开发的敏捷管理方法研究[D].哈尔滨:哈尔滨工业大学, 2006