软件开发项目

软件开发项目（精选12篇）

软件开发项目 篇1

0 引言

软件开发项目进度,是指完成整个软件开发项目所需活动的过程和时间周期。软件开发项目进度管理是为了确保项目按时完成而对其各项活动及阶段进行的管理。软件开发项目进度管理包括4个步骤,其中软件开发项目进度计划编制和进度控制是实际工作重点,但编制项目进度计划前,应先分解项目,明确该项目包含的活动,并对项目活动进行排序[1]。下文中“软件开发项目”简称为“项目”。

1 项目工作分解

一个项目提出后,根据项目目标确定项目的研究范围后,应对项目进行分解,将可交付成果和复杂的项目逐步分解成较小的、便于管理的组成部分,并创建工作分解结构图,为项目进度计划打下基础[2]。

1.1 项目工作分解的作用

项目分解的作用主要体现在两个方面:

(1)便于进行综合性方案设计。工作分解就是在项目目标的指导下,在任务范围中从粗到细、从简到繁,逐步分析,直到可执行的最小独立单元,这样能够较好地保持项目的系统性和完整性,策划者据此可以通盘考虑实现项目目标应完成的工作,能够清晰地分辨任务实现的重点和步骤、完成周期、成本费用,并评估风险,同时,也有利于发现潜在的不明确内容,为项目总体设计提供可靠依据。

(2)便于分配任务和明确责任。项目工作分解把项目划分成多个独立性较强的任务单元,明确区分各任务的目标、范围和界限,对每个工作任务提出具体要求,便于在执行项目时,落实责任者或完成单位。既可以作为委托工作或下达任务的依据,也便于观察、了解和控制整个项目过程。

1.2 项目工作分解结构的依据、原则和方法

项目工作分解结构的主要依据是前期取得的项目主要资料和其它相关项目的借鉴性文件,包括项目需求文件、任务(合同)范围说明、本项目的其它资料、其它项目的相关资料等。

工作分解结构的原则是:在各层次上保持项目内容的完整性,不能遗漏任务必要的组成部分;每个项目单元只能从属于某一个上层单元,不能同时交叉从属于两个上层单元;相同层次的项目单元应有相同的性质,各项目单元应有明确的任务界限,保持各项目单元的独立性;项目分解的原则应事先确定,同一层次上分解出的项目单元,其分解的原则应该是一致的。

工作分解的方法有自上而下和自下而上等方法。自上而下法是先明确项目最终产品,然后确定中间可交付成果,再对主要可交付成果细分,直至每一个工作只包含一个可交付成果;自下而上法是首先明确项目的所有可交付成果,然后将可交付成果进行逻辑分组,接着将每组汇总成一个母元素,成为上一层次的元素,再将高一层次的元素进行分组、汇总,以此类推,最终汇成一个母元素。

1.3 项目工作分解结构一般步骤

工作分解首先应识别项目的主要要素,项目的主要要素就是项目的主要交付物,然后对识别出的主要要素作进一步细化,分解出更详细的有形的、可检验的产品或服务,在此基础上,选择自上而下或自下而上的方法编制工作分解结构图(也可以使用单位标准模板或以前项目的模板),编制完工作分解结构图后,应编制详细的结构图说明,说明的内容包括各要素的界定、说明、估算经费、时间、预安排的责任部门、人员等。

1.4 项目工作分解结构输出

项目工作分解的输出结果包括项目结构图和相关说明。项目分解结构图(WBS)是通过分解技术,将项目任务按照其内在性质和结构逐层细化而形成的示意图。它涵盖为完成项目交付物需进行的所有项目工作,为项目责任分配和任务协调提供依据。项目结构说明包括各层要素的详细描述、工作说明、负责组织、进度日期、成本预算等。

2 项目活动确认及排序

完成项目工作分解后,应对所确定的可交付成果的具体活动进行分析确认和排序,为编制项目计划打基础。

2.1 项目活动确认

依据项目工作分解结构的成果、其它关于项目范围的说明性文件、项目约束条件、项目的假设前提、管理计划和单位的历史信息等[3]确认项目活动。对于一些小项目,可通过大家集体研究讨论,集思广益的方法,形成可行的活动清单并估算所需时间,对于较大、较复杂的项目,则需要由相应领域专家研讨或使用一定的工具和方法来确认项目活动,这些方法包括:进一步使用活动分解技术、采用已有模板法、领域专家判断法等。项目活动确认后,形成的结果包括:涵盖项目所有必要活动的项目活动清单、描述项目过程中基本关键点的项目里程碑图等,此外,还应适时更新项目工作分解结构图和项目总体管理计划。

2.2 项目活动排序

确认了项目活动,要识别各项活动的相互关系,项目活动之间的关系也称为项目活动之间的先后信赖关系,包括人们无法改变的硬逻辑关系和需由各种因素综合确定的软逻辑关系,在项目活动排序时,要根据项目活动清单、项目里程碑和一些约束条件,先识别并安排硬逻辑关系,再安排软逻辑关系,同时要考虑项目假设条件和外部条件的影响。项目排序图的编制方法可以采用节点图法或箭线图法。项目排序的最终结果,是描述项目各项活动相互关系的项目网络图及其活动说明,项目网络图应包括项目的主要活动和情况,并明确各活动之间的逻辑关系或依赖关系,在网络图的说明中,应描述活动排序的基本方法,对于特殊的排序应进行说明。

2.3 项目时间估算

项目时间估算是指根据项目范围、资源及相关信息,对项目已标识的各活动持续时间所进行的估计。大多数项目活动时间的长短,取决于人力、物力、财力及资源的多少,同时还受人的能力、物资质量和设备效率的影响。对项目活动时间进行估算时,即要考虑各活动所消耗的实际工作时间,也要考虑活动的延迟时间。因此,一般由熟悉项目活动或有经验的人员或团队,采用专家判断法、类比估算法或模拟估算法完成。

3 项目进度计划编制

编制项目进度计划,是综合分析项目活动排序、持续时间、资源需求和进度约束,确定每一个项目活动及整个项目起始和完成日期,建立一个相对科学可行的项目进度计划的过程。编制项目进度计划是一个迭代过程,需要运用科学的计划方法,将时间、经费、人员、设备及各种资源作统筹安排,还要与其它相关项目协调一致。

3.1 编制依据

编制项目进度计划的依据包括:项目活动排序后得到的项目网络图、项目活动估算得到的时间值、现有的和能取得的资源、项目时限和重要里程碑、项目约束条件以及其它风险和假设前提。

3.2 编制方法

根据不同项目的具体情况采用不同的方法,本文重点介绍编制项目进度计划的3种方法。

(1)甘特图法。甘特图又称横道图或条形图,它是通过赋予时间以含义的横道图形式,列出项目活动工期及其相应的开始和结束时间,以反映项目进度信息的一种可视化计划方法。甘特图左侧列出项目活动和工期,顶部列出时间,横道长短代表活动持续时间长短。甘特图的优点是简单、明了、直观、易于绘制,缺点是不能系统地将项目各项活动之间的逻辑关系表示出来,也不能进行定量分析和计算,更不能指出影响项目的关键所在。

(2)关键路线法。关键路线法也是通过横道图以日历形式列出项目活动、工期、相应的开始结束时间来进行规划。它与甘特图的不同之处在于,它运用特定的、有顺序的网络逻辑方法来预测总体项目历时,是一种数字分析技术。关键路线法的重要功能是确定项目的关键工作和关键路线,关键路线的确定是将项目网络图中每一条路径上的所有项目活动的历时分别相加,最长的那条路径就是关键路线。

(3)计划评审技术。计划评审技术是指当项目或项目某些活动历时估算存在不确定性时,运用加权平均历时估算法,来估算项目历时的网络分析技术。这种技术适用于不可预知因素较多,或从未做过的新项目或复杂项目。计划评审技术网络图的画法与一般网络图画法相同,不同之处在于对项目活动时间的估计和分析[4]。

3.3 编制结果

编制项目进度计划的主要成果用表格或图表形式呈现,项目各项活动都标明了各种日期参数的项目进度计划文档。此外,还应包括进度管理计划,用以明确项目进度计划发生变化时的处理原则。

4 项目进度控制

项目进度控制是进度管理的重要内容和过程,是前期一系列进度计划工作的延伸,是进度管理中与实施并行的实践性关键阶段。

4.1 进度控制依据

项目进度计划是经过论证和批准的,在技术和资源上具有可行性,所以是项目进度控制的主要依据。通过项目跟踪监测和沟通形成的有关项目进度的绩效报告、根据项目进展情况提出的变更请求、编制进度计划时形成的进度管理计划,也都是进行项目进度控制的依据。

4.2 进度控制主要工作

控制项目进度的主要工作是:依据作为项目进度基准的项目进度计划,通过跟踪监测和沟通,采用一定的工具和方法进行分析比较,确定项目进度是否发生了变化,如果发生了变化,找出变化的原因,对影响变化的因素进行控制或制定项目进度的补充计划,从而确保进度变化朝着有利于项目目标实现的方向发展[5]。控制项目进度还可以借助项目管理软件来实现。

4.3 进度控制结果

进度控制的结果有两种,第一种是项目所有进展均按计划顺利进行的理想情况;第二种是发生一些偏差,并制定一系列纠偏措施,之后更新项目进度计划。两种情况均应记录项目控制的经验或教训[6]。

参考文献

[1]关保昌,沈建明.现代国防项目管理[M].北京:军事科学出版社,2011.

[2]祝振铎,董雄报.信息系统项目工作分解结构(WBS)研究[J].硅谷,2011(15):78-78.

[3]方德坚,张杨华.也谈软件项目进度管理[J].赤峰学院学报:自然科学版,2011(5):15-16.

[4]王芙蓉.软件项目进度计划与风险控制研究[D].大连:大连海事大学,2009.

[5]徐飞汀.软件项目进度计划管理研究[D].北京:北京邮电大学,2010.

[6]崔晓明,马力.软件项目进度控制方法研究[J].计算机工程与设计,2010(12):2754-2757.

软件开发项目 篇2

对公司的整体状况和运营模式进行了解，重点针对合同管理系统的适用领域、场景以及客户群体、一般性需求进行学习。熟悉公司技术团的工作模式、编码规范和研发管理控制流程。 通过对公司产品关注领域和业务流程的学习以及研发规范的了解，梳理了技术学习主线，制定了具体的学习目标和时间计划为技术研发工作奠定了基础。

二、公司***平台的研发

参与了***平台的部分功能研发，主要参与以下功能模块的代码编制、优化和初步的功能验证测试：系统平台对接浪潮系统、系统对接审批事项清单模块,系统管理模块,筹备成立模块、成立登记模块、分支机构管理、组织管理、注销信息管理、变更信息管理等等。在研发中，按照团队规划完成了个人的任务并按照编码规范进行了源码优化。对于部分编码进行分析和重构，对于部分功能模块进行了效率优化和源码简化，提升代码的可读性、可复用性、可移植性。整个研发过程，积极融入团队，提升技术水平的同时进一步加深了对公司产品业务的理解。

三、公司产品***平台的优化

参与产品***平台的优化。使用技术方法通过重构改进了产品的运行效率。从构建模式、实现方法、代码风格上进行了多方面的知识整理、分析和优化。并以此为契机，强化了效率优化的意识，学习了效率优化的方法，同时，增强了研发中兼顾效率的意识。

20xx年度个人取得的.成绩和经验

20xx年是我进入公司的第一年，无论是对于生活阅历还是工作经验以及技术知识都取

得了很大的成效与进步。在公司的几个月里我着实成长了许多，尤其是对专业知识技能的提升、此外还增长了一些对行业的认识以及开发流程。

20xx年度个人工作中存在的问题和不足及改进方法

刚进公司的时候我面临很多问题，在工作中遇到非常多棘手的问题，不断请教前辈们.有了他们的帮助和自己坚持努力，我发现我所遇到棘手问题越来越少，就这样我从一个新人慢慢变成一个可以担当一面的团队成员，我再也不怕遇到问题。在未来的一年里我应该多锻炼自己表达能力和加强对普通话的学习，其次，对于技术方面了解不够全面，不够广泛，好多技术都还处于一个熟悉、认知阶段。在未来的日子里我会给自己拟定一些目标和学习、提升路线，让自己技术以及各方面不断的提高。不让自己只局限于技术方面的提升与提高 在工作中我体会到了坚持就是胜利，程序员必须有较强的适应能力和承受能力,需要不断的进行学习补充新的知识,只有不断的扩充、更新自己的知识才能应变技术的更新与发展。

提出目前公司存在的各方面问题及合理化建议

公司领导比较给力、很会照顾下属，同事之间也比较容易相处，团队互助性也比较强。但是我们公司对于技术上是不是应该增加一点技术储备方面东西。我希望公司能够一个强大知识库，比如某一天某个人解决了一个极难解决或者比较罕见的问题。有必要保存到知识库里，以备后续之人有一个学习认知的空间。

对自己20xx年度整体表现的客观评价

20xx年度是我在学习中不断总结经验、吸取教训、获得成长的年度。

本年度的工作中，我认真制定工作计划，

按时完成工作任务并适时进行总结和分析，关注功能实现、代码规范、效率优化和用户体验。努力开展对本职工作所需专业技术学习，优化知识结构，并不断深化对合同管理业务的理解。团队建设上，我积极融入团队，努力营造良好的团队氛围，和同事关系融洽。

综上所述，对于20xx年的工作整体表现，我对自己的评定是满意的。

20xx年年度工作计划安排

1. 在原有体系不变动情况下，配合团队完成社会组织信息系统后续的开发。

2. 加强自己工作中阐述问题的能力和分析能力以及解决问题的能力。

3. 不断学习新的技术与知识，让自己更能适应新的需求发展变化，给自己制定一个短期目标以计划 。

4. 努力更正自己开发习惯，提升自己开发技巧。

5. 了解技术以外的知识，摆脱自己“机器人”的概念。

个人职业生涯规划

一、短期目标(提升专业技术水平、掌握解决问题的方法)

合理规划自己时间，给自己制定一个工作之余的学习计划，学习目标，在工作不断吸取经验教训加以总结汇总，不断更正自己工作习惯。

二、长期目标(专注改进薄弱环节，掌握提升效率的技巧，深化业务理解)

软件项目开发中的人员外包 篇3

一、软件企业外包业务需求产生的原因

1、外包业务的开展符合发展型软件企业的现实特点。近年来随着电子信息技术和信息產业化的深入发展，我国软件业作为一个新兴的产业也得到了蓬勃的发展。但处于行业发展初期的大环境中，软件企业在成长过程中具有一些鲜明的特点：第一，软件企业规模较小。《2002年中国软件产业发展公报》调查结果显示，我国共有4700家各类软件公司，其中50人以下的企业占67％左右，50-200人的占26％左右，1000人以上的软件企业则非常少。第二，软件企业项目开发的正规化程度低。我国具有CMM体系认证的企业数量极少，且通过CMM认证的最高级别仅为四级，如深圳华为公司，大部分企业还是在采用IS09000系列质量管理程序来保障软件项目的开发。第三，软件企业的产业化程度较低。我国的大多数软件企业还处于“手工作坊”阶段，尚未形成规模化生产，缺少规范的软件过程监控、质量管理、文档管理等手段采控制软件生产的质量。第四，软件开发人员的人力资源分布不均匀。软件行业在我国20几年的发展历程中，积攒了丰富的人力资源。但由于软件人才的培养体制上，大部分采用了直接引进国外的知识系统再加以内化的方式，造成了我国软件行业人才趋同性较强、没有分明的层次、高级研发人员缺乏、一般编程人员过剩的局面。行业发展到一定程度时，必然会出现市场竞争的两极分化。21世纪，随着我国软件业中领头企业的浮出、跨国软件巨头的逼近，将软件市场的竞争推向了白热化的高潮。为数众多的发展型软件企业如何在市场竞争中立足?“外包”的出现，为他们提供了全新的思路，软件人员外包也是在这种背景下应时而生，

2、外包合作能够实现软件企业的双赢。一方面，作为行业领头的软件企业，无论是项目开发技术、管理经验，还是对高级研发人才(系统架构师、系统分析师等)的拥有都占有绝对的优势．但从软件项目开发的角度来看，进行软件开发需配备的人力是一个从高到低的金字塔型，特别的项目底层的开发需要大量的编程人员来编码实现。且根据项目类别不同、开发所处阶段不同，对人员技术的要求差异很大。大型企业完全具有各型人才的人力成本压力是巨大的，并且也不利于企业集中优势发展核心竞争能力。另一方面，处于行业竞争中的中、下游企业，由于缺乏规范的软件开发质量保障体系，且高端研发人才也相对稀缺，进而导致了他们在同大企业竞争时始终处于不利的位置。但中小型企业的规模小、管理费用低、操作灵活，使其对一般研发人员的大力使用成本相对于大企业占有明显优势。因此，根据现实的市场状况，并借鉴国外软件行业的发展经验，提出了“前店后厂”的经营理念，即具有实力的大企业专注经营其品牌、服务、核心技术、管理水平等体现核心竞争优势的业务，利用其强大的市场号召力，做好“店面”以赢得客户的青睐。如IBM、HP、EDS等国际IT服务业巨头，都有自己的外包服务中心，软件编程、客户服务中心、金融分析中心等非核心业务外包。中下游企业由于实力上根本无法与大型企业正面抗衡，所以只有通过发展战略的互补定位，才能找到自己的成长途径。也就是在“前店后厂”模式中，充当后方的“加工厂”角色，通过技术的精细化耕作和人力资本的成本优势取得上游企业项目的代加工权，在分工协作中获取收益。这种模式的运用，使产业链上的各层企业都有相应的发展空间，通过合作达到双赢．

二、软件人员外包的实施和运作模式

软件人员外包，就是指具有专业人才储备的中小型软件企业，利用其人力成本优势，向由项目开发需要而产生人才需求的软件企业，输送人才的外包服务过程．软件项目开发中的员工外包，在实施中基于几个合作约束；第一，发包方和承包方以外包合同的形式，确定双方在合作中对开发人员的需求与供给要求。在项目开发过程中，外包员工在发包方的管理下进行项目开发，产出的项目相关技术成果的产权归发包方所有；项目完成，合作终止后，全部外包员工返回原企业。第二，发包方以协议的金额向承包方支付整体外包人员的使用费用，不与外包员工个体发生薪酬收支关系。第三，外包员工与承包方签订劳动合同，其人事处置权(包括培训、升迁、薪酬福利、绩效评估等)均归承包方所有；发包方只拥有外包员工在项目开发工作中的管理支配权。

软件人员外包的主要有两种形式：一是外包人员的现场开发，即参与项目的外包员工在发包方中进行现场开发．由于这种形式有利于发包方项目管理优势的发挥，并能保证项目开发的安全性，所以被各软件发包方广泛使用。但这种方式最大的缺点，就是外包员工和发包方的融合容易出问题。二是外包人员的第三方开发，即参与项目的外包员工在发包方项目负责人的领导下，在第三方工作地点进行开发工作．这种方式的工作环境相对比较封闭，有利于项目参与者之间的沟通交流，并能保证项目开发的进度．但封闭的小环境由于缺乏文化氛围容易导致开发人员对工作的厌倦，致使工作满意度不高、工作效率下降．

三、软件人员外包业务的优势和存在的问题

进行软件人员外包对于发包方和承包方来讲，都能享受合作分工的收益。发包方方面，首先企业将自己不擅长、非核心的部分外包出去，不仅可以拥有更多的时间和资源将精力集中在自己的核心竞争力上，还可以节约企业经营成本。其次，满足项目开发灵活性的需求，企业可以根据承接项目类型的不同，挑选不同的承包方企业或在承包方中挑选具有相关能力的开发人员。最后，有利于外包方项目开发管理优势的发挥，并对项目开发质量和安全有全面的保障．而作为承包方，一方面企业能在激烈的竞争中获得成长空间、取得收益；另一方面透过外包员工在外包方的工作，可以积攒项目开发的管理经验、学习先进的开发技术，为本企业的长期发展积聚力量．但在人员外包的具体实施中，也不可避免的存在着一些问题：首先，由于外包人员的人力资本产权归属不同，造成了外包员工激励与约束机制的不完善．即使用外包人员的企业，由于不承担绩效评估、调薪、升迁等的人事处置权，因此对外包员工工作的激励与约束能力就很有限；而拥有这些权利的承包方，由于对外包员工的工作过程不直接监管，所以绩效评估措施使用的有效性就难以保障．其次，外包员工在工作中，对发包方的企业文化、管理方式存在磨合问题．发包方在项目开发的管理中，基于项目成本的考虑，会尽量压缩开发周期，进而造成对开发人员人力资本的过度使用；并且重视项目结果产出，忽视对参与员工的人文关怀，从而加速了人力资本的折旧．同时，在发包方中工作的外包员工面临着内、外部员工的差别待遇，企业文化隔离等问题，当他们面临着巨大的工作压力又难以融入该企业时，会导致工作积极性低、与发包方矛盾频频等问题。最后，由于承包方很难了解外包员工参与项目的真实动机，可能会面临自身人才流失的风险；而发包方在外包员工的选取时，也会因为信息的不对称而面临着人员适用性的风险。

综上所述，我们可以看到软件项目的人员外包是一项极其发展潜力的新兴业务，其使用得当会给合作的双方带来巨大的收益。但在实施过程中，由于机制的不完善也会造成这样、那样管理问题，而对这些问题的解决还有待于我们对它的进一步关注和研究。

试论软件开发项目的管理 篇4

一 实施软件开发项目管理的意义

近年来, 我国的软件开发不断的深入和发展, 随着各种软件技术的不断创新和软件产业的日益发展, 人们越来越意识到软件开项目管理的重要性, 软件开发项目的管理越来越受到人们的重视。我们所说的项目管理就是指的在项目活动中运用一系列的知识、技能、工具和技术来满足或超过相关利益者对项目的要求, 软件开发的项目管理也是这个意义, 它就是使得软件开发结合上管理学的知识, 通过软件管理人员的相互合作, 来实现软件开发项目的目标, 实施软件开发项目管理有利于更好的实现软件开发的目标, 更高效率的实现软件开发。

二 目前在软件项目管理中存在的误区

虽然目前有很多的软件企业都已经意识到了软件开发项目的管理的重要性, 但是他们的软件项目管理中却存在着很多的误区和问题, 这些误区和问题主要表现在以下几个方面:

1.项目经理不够专业。项目经理在整个软件开发项目的管理中发挥着重要的作用, 因为无论是项目的实施还是决策都是由项目管理人员来制定的, 项目经理在软件开发项目的管理中的作用尤其重要, 因此, 项目经理必须是由具有相当高的技术和管理能力的人来担任, 而我国目前的现状是对项目经理的要求不高, 项目经理不够专业, 这就是软件开发项目中的一项非常不利的问题。

2.项目计划缺乏纲领性。目前的软件企业的软件开发项目管理项目计划缺乏纲领性, 项目经理对总体计划和阶段计划的作用认识不足, 使得整个项目的计划都缺乏纲领性, 最终容易导致管理计划与管理实践之间相脱离, 很难高效率的实现软件开发项目的目标。

3.缺乏有效的管理意识。有许多企业的项目经理只有高超的技术技能却没有一定的管理意识和管理技能, 他们总是在具体的技术工作上下工夫, 却没有意识到对整体项目的把握, 容易造成任务分配不公平, 资源浪费等问题, 也无法实现软件开发项目的最终的目标。

4.缺乏有效的沟通制度和机制。很多的企业由于缺乏有效的沟通制度和机制, 使得很多的重要的信息没有及时有效的得到传递, 在制定计划、意见反馈、情况通报、技术问题或成果等方面与相关人员的沟通不足, 从而造成了不必要的损失。

5.风险管理意识淡泊。在软件的开发项目中具有风险管理意识是非常重要的, 然而目前就有很多项目经理没有意识到这一点, 他们的大意很可能使得在一次小的危机到来之时就是的他们措手不及。

6.项目干系人的不确定性。有些企业在范围识别阶段, 项目组无法充分了解客户的整体组织结构、有关人员及其关系、工作职责等, 也就会无法得到完整需求和最终经权威用户代表确认的需求, 从而使得项目范围蔓延、进度的拖延和成本的增加。

7.缺乏项目团队的合理分工。软件企业的整个的软件开发项目是需要整个项目团队的共同努力来实现的, 由于缺乏项目团队的合理分工, 就使得分工不明确, 成员之间相互推诿, 责任不清, 职责不明, 影响整个项目的完成进度。

三 解决软件项目管理中存在的误区的有效策略

既然在软件开发项目的管理中存在着误区, 我们就要积极找出解决这些问题的方法, 我们要运用管理学的方法从软件开的角度, 有针对的性的解决问题, 我们主要要做到以下几点:

1.项目经理应该积极的接受系统的项目管理知识培训, 掌握稳定的知识技能和管理技能, 在掌握好自己的专业知识和进行专业实践的基础上, 还要具有一定的管理知识和实践, 具有专业素质和管理素质。

2.要制定合理的项目计划, 并对计划进行不断的完善和改进, 首先项目经理应该注意提高自己的计划意识, 制定合理的项目计划才能是项目管理人员按着项目的计划来执行项目, 这样才更加具有针对性, 才有利与项目管理的高效率的实现。

3.项目经理要提高自己的项目管理意识, 企业要积极的引导和培训项目经理使他们做好项目管理的工作, 有一定的管理能力和管理经验, 使得自己的整体的管理素质有所提高, 从而更好的在整个软件开发项目中起到带头作用。

4.企业要制定有效的沟通制度和沟通机制来提高整个项目管理人员的沟通意识。只有采取多种沟通方式才能提高沟通的有效性。只有沟通顺畅了, 才能够使得信息得到有效的传递, 才能够在最短的时间能征集最广泛的意见, 能够提高效率, 有利于实现软件开发项目的目标。

5.项目管理人员要提高自己的风险意识, 可以通过学习项目管理知识来掌握风险识别、量化、对策研究、反应控制的工具和方法, 掌握项目风险管理所必备的知识。项目管理人员还应该学会对本行业项目中常见的风险及其对策进行总结, 只有这样, 当面对突如其来的风险时, 项目团队才能够从容应对。

6.实现项目干系人的需求和愿望是项目的目的。项目干系人管理应当从项目的启动开始, 项目经理及其项目成员就要分清项目干系人包含哪些人和组织, 并且要影响和驱动他们对项目的支持, 查明他们的需求和愿望, 减小阻力确保成功。

7.对团队成员进行合理的分工, 使其明确各自的职责, 使得项目成员之间相互配合, 共同来完成软件开发项目。

四 结语:

软件开发项目个人承包协议 篇5

甲方：广州xx生态科技有限公司

乙方： 身份证：

甲乙双方就“xxxxxx平台系统”开发项目签订个人包干协议，乙方为甲方在职员工，根据甲方公司项目管理及绩效考核方式，与乙方签订工作协议：

1、甲方评估项目开发时间及开发需求给乙方，乙方根据项目时间节点完成系统开发要求，甲方只考核乙方开发成果；

2、在项目开发阶段，甲方有权提出修改意见并评估乙方的进度时间；

3、个人项目包干期间，甲方不限制乙方办公地点及上班时间，需要与其他同事对接的工作内容必须提前沟通协调好；

4、乙方月薪为人民币：元，现“XXXX平台系统”包干项目所需时间2个月，即2018年7月日至2018年9月日完成系统开发及对接，总薪酬为人民币元，社保、公积金及其他公司福利正常享受，开发期间，甲方每月发放乙方人民币3500元，项目测试合格并交付后，发放余款元；

基于B/S架构的软件项目开发 篇6

关键词：B/S架构；C/S架构；实际应用

中图分类号：TP311.13

1 前言

随着Web的蓬勃发展，网络结构模式也开始改变，B/S架构也就孕育而生。由于传统的C/S网络结构模式存在着种种问题，从而促使了B/S架构的兴起。人们在基于C/S架构的基础之上，提出了一种具有三层模型的结构，也就是对C/S架构的一种改进。随着B/S架构的广泛应用，掌握和了解B/S架构成为软件开发技术人员的必须具备的知识。

1.1 C/S架构

Client/Server（客户机/服务器）架构，是人们所熟悉的一种软件系统体系结构，通过将任务合理分配给客户机端与服务器端，降低了系统的通讯开销，两端硬件环境的优势可以得到充分的利用。在早期的应用软件开发中，大多数软件系统是把C/S架构作为设计标准的第一选择。C/S架构的的交互性强、可靠性高、有良好的数据处理能力，但是其客户维护成本高，工作量大，软件升级比较麻烦。

1.2 B/S架构

Browse/Server（浏览器/服务器）架构，它是在原有的C/S架构上进行了扩展。B/S构架的软件系统特点：浏览器只需安装在客户机上；服务器端则安装数据库（DB，Data Base）、客戶层浏览器和所有的数据；从逻辑上可分为三层，客户层浏览器、WEB服务层和DB服务器层。

客户机层的作用是实现用户界面在客户端浏览器中显示。浏览器显示从Web服务器端传输来的数据，然后用相应的HTML标记和CSS来实现。不仅如此，浏览器还得读取用户录入的数据，然后把校对后的录入信息上传于Web服务器。

Web服务器层是B/S的主要功能实现，其主要负责分析并处理由客户端浏览器传送来的数据，执行其相应的程序并把结果传回于客户端浏览器。Web服务器不只是为客户端服务，它还调用有关的数据访问接口对象来访问DB服务器中相应的数据，所以Web服务器层拥有大量的数据访问对象例如COM、ADO等。

DB服务器是核心，为其他技术提供访问DB的技术，并且可以完成对DB的各种操作，比如修改、删除、查询DB等功能。DB服务器是服务于Web服务器，按其请求从DB中提取或者删除相应数据。

1.3 B/S架构软件和C/S架构软件的区别

B/S架构和C/S架构有很多不同之处：硬件环境、对安全的要求、软件重用，用户接口、处理问题、系统维护、信息流、程序的架构等。C/S的传统客户服务器两层架构具有升级难、灵活性差、维护工作量大等缺点，已经难于满足如今快速发展的信息网络技术的要求。而C/S被B/S所取代最大的原因就在于B/S架构的客户端免维护，节省了成本，适用于大多数的用户群，适应各种情况。

采用B/S架构来设计和开发软件优势在于：（1）无需开发客户端软件，维护和升级简单方便，只要把完善的功能集中于Web服务器，依据不同且多样的功能设置好对应组别的用户权限就行了；（2）跨平台操作也是B/S的优势，任何一台机器只需要安装有IE、360等浏览器软件就可以访问系统；（3）因为B/S架构的开放性和可扩充性，所以B/S架构的限制也很少。

总之，B/S架构在根本上弥补了两层模式的C/S架构的不足，是应用系统体系架构上的一次重大变革。

2 B/S架构软件的实际应用

在现实生活中，我们用到许多基于B/S架构开发的软件，其在通信、管理以及OA等很多行业应用广泛，如网上银行、城市消防联网、学生信息管理系统等。下面以学生信息管理系统的设计为例，来说明一下基于B/S构架的软件开发。

学生信息管理系统是一个基于B/S架构的Web应用系统，用户可以在客户端使用浏览器给指定的Web服务器提出服务的请求，Web服务器通过HTTP协议把所需文件资料传给用户，且在浏览器上显示出来。该系统主要有两种用户：学生与系统管理员，把其分成两个模块：学生模块与管理员模块，独立设计2个模块的功能，再将他们融于总的控制模块中，其功能可因用户的不同而有所不同，学生可以用学号来查询成绩、班级等相关信息。同时，管理员可通过Internet对相关数据进行查询、修改、录入、删除等操作。此外，管理员不仅可以查看学生的相关信息如年级、学籍等，还能够对成绩、档案和课程安排等信息进行简单的管理。

2.1 B/S软件开发工具

B/S软件开发同网站开发一样，需要利用很多前后台开发工具，现在对学生信息管理系统开发工具列举如下：

ASP（Active Server Pages）指动态服务器页面，是微软开发的一个脚本程序来替代CGI，能够和DB与其他程序进行交互。ASP内含于IIS（Internet Information Services 互联网信息服务），可把VB SCRIPT或JAVA SCRIPT语言编写的服务器端脚本嵌入Web页面。在ASP中利用ADO（ActiveX Data Objects）可方便地访问DB，并有效地对DB进行处理。

该系统采用的是MS SQL 2000为DB系统，微软Windows2003服务器版本系统是其操作系统，IIS5.0/6.0是其Web服务器。

2.2 B/S架构的实例设计

经过上述分析，可将学生信息管理系统分成三层结构来实现，如图2所示。

在学生信息管理系统设计中，Web服务器层的程序设计是整个系统开发的主要部分，其是由Windows Server2003和IIS与全部的学生处理程序ASP文件和.htm文件构成。当某个学生在客户端要求查询信息时，由HTTP协议向服务层处的IIS要求下载文件，IE所要求下载的文件会经过ISS判断，如果是ASP文件，ISS就会执行该文件并把执行的结果返回于IE，如果不是，则直接将文件下载给IE。

以上是基于B/S架构软件项目开发设计中的一个实例，由于篇幅限制，我就不详细说明其他部分设计了。

3 结束语

综上所述，B/S架构软件项目开发是互联网发展的形势所趋，从实际应用中，可以看出B/S架构管理软件更为高效、方便、快捷。

参考文献：

[1]苗壮.基于WEB的学生收费管理系统的设计与实现[D].电子科技大学.2010

[2]肖满生.基于ASP技术和B/S构架的Web应用系统设计模型[J].中国高教论丛.2003

作者简介：赵巧玲（1991-），女，四川绵阳人，本科，研究方向：软件工程。

解析企业软件开发项目的需求管理 篇7

随着信息时代的发展, 计算机软件的需求愈来愈复杂, 规模愈来愈大, 而且随着企业的发展和工作过程重组, 需求变更已愈来愈成为必然。在企业软件项目的开发过程中, 需求变更贯穿了软件项目的整个生命周期, 在软件的项目立项、研发及维护各阶段, 用户经验的增加、对软件使用感受的变化以及整个行业的新动态, 都为软件带来不断完善功能、优化性能、提高用户友好性的要求。在软件项目管理过程中, 项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更, 项目计划会一再调整, 软件交付日期一再拖延, 项目研发人员的士气将越来越低落, 将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。

需求管理是软件开发生命周期的初始阶段, 它对最终提交的软件产品的质量起着至关重要的作用。有资料统计, 软件项目40%—60%的问题都源于需求分析。所以, 重视需求、谨慎对待、严密分析, 是每一个开发者应该持有的正确态度。建立软件需求管理过程的目的在于用户和软件项目组之间形成共同的理解, 这种共同理解应体现在用户需求的文档化确认和对用户需求的控制中, 并保证项目的计划、工作产品和活动都与需求一致。

1 需求管理复杂性分析

软件需求是整个软件开发项目的最关键的一个输入, 和传统的生产企业相比较, 软件的需求具有模糊性、不确定性、变化性和主观性的特点, 不同于生产汽车、电脑等硬件的需求, 是有形的、客观的、可描述的、可检测的, 软件需求是企业软件项目最难把握的问题, 其复杂性体现在以下方面:

1.1 需求的描述问题。

缺少正式的、完整的需求文档浪费了大量的人力物力, 但是有了需求文档又出现了新的问题。在用户方进行的需求评审会完全是走形式, 因为用户根本不去听那上百页的需求文档。不同层次的客户 (用户) 关心的问题是不一样的, 想要每个客户都成为需求专家是不现实的。

1.2 需求的完备程度问题。

需求如何做到没有遗漏?如何准确划定系统的范围?这确实是一个两难问题, 稍微大一点的系统要想穷举需求几乎是不可能的, 每次开需求评审会时, 总会冒出新的需求, 以至于系统没有一个准确的范围界定。即使是这样, 系统还是要开发, 系统的范围还要硬性的划定一个, 从而建立一个基线。

1.3 需求开发的工期问题。

在需求上花费了大量的时间, 客户、企业是否能够忍受?为了确保需求的正确性, 完备性, 项目经理往往坚持要在需求阶段花费大量的时间, 但是客户与企业的高层领导却会为项目迟迟看不到实际可运行的软件担心不已, 他们往往会催促项目组尽快往前推进, 而项目组的成员往往也会被系统复杂、善变的需求折腾的筋疲力尽, 希望尽快结束需求分析的相关工作。

1.4 需求的细致程度问题。

需求到底描述到多细, 才算可以结束了?仁者见仁, 智者见智, 并没有定论, 如果时间允许, 要想细总可以细下去的。但是, 需求的周期越长, 可能的变化越多, 对设计的限制越严格, 对需求的共性提取要求越高, 所以只要客户 (用户) 、需求分析人员、设计人员、测试人员认为描述清楚了, 就可以进入设计阶段了。

1.5 需求的变化问题。

在软件开发过程中如果只有一条真理的话, 那一定是:需求的变化是永恒的, 需求不可能是完备的。软件开发的过程实际上是同变化做斗争的过程, 需求的变更不一定是坏事, 也有可能是好事, 是商业机会, 对市场敏感的人可以从需求的变化中发现市场机会。

2 需求变化的原因:

需求变化的原因很多, 比如: (1) 一开始没有识别全, 需要增加需求; (2) 业务发生了变化, 需求必须变化; (3) 需求错误; (4) 需求不清楚。

需求的变化问题是每个开发人员、每个项目经理都遇到的问题, 也是最头痛的问题, 一旦发生了需求变化, 项目组不得不修改设计、重写代码、修改测试用例、调整项目计划等等。需求的变化好像为项目的正常的进展带来不尽的麻烦, 怎么办?只有通过需求管理使需求在受控的状态下发生变化, 而不是随意变化, 需求管理就是要按照标准的流程来控制需求的变化。难题随之而来, 需求中的变化一般不是突发的革命性的变化, 最常见的是项目需求的渐变 (Proje ct Scope Cre e p) 问题, 这种渐变很可能是客户与开发方都没有意识到的, 当达到一定程度时, 双方才蓦然回首, 发现已经物是人非, 换了一番天地。

3 需求管理策略

需求管理需要遵守以下策略:

3.1 需求一定要与投入有必然的联系

需求一定要与投入有必然的联系, 否则如果需求变更的成本由开发方来承担, 则项目需求的变更就成为必然了。人们常说世上没有免费的午餐, 同样也不应该有免费的需求变更。但是, 接受需求变更目前却是软件企业不得不咽下的苦果。所以, 在项目的开始无论是开发方还是出资方都要明确这一条:需求变, 软件开发的投入也要变。

3.2 要充分理解客户提出来的需求

开发者应该理解客户的需求, 如果这点做不到, 后面的工作是没有意义的, 所以, 那种在没有理解需求的情况下, 就仓促开发的做法是不合适的。

3.3 需求的变更要经过出资者的认可

需求的变更引起投入的变化, 所以要通过出资者的认可, 这样才会对需求的变更有成本的概念, 能够慎重地对待需求的变更。

3.4 做好需求文档的版本管理

记录用户需求、系统需求、软件分配需求的文档都要作为基线确定下来, 做好相关文档的管理工作。需求的基线是指是否容许需求变更的分界线, 需求分析人员在充分与客户用户进行沟通的基础上形成第一个版本的需求文档, 这个需求文档在通过需求评审后即可以建立第一个需求基线。此后每次需求变更并经过需求评审后, 都要重新确定新的需求基线, 以免将来用户需求发生变更时, 原来的需求无法查找。为有效进行需求变更控制, 必然要做的工作就是保存好各个版本的需求基线, 维护需求基线文档, 以备不时之需。

3.5 小的需求变更也要经过正规的需求管理流程

小的需求变更也要经过正规的需求管理流程, 否则会积少成多。在实践中, 人们往往不愿意为小的需求变更去执行正规的需求管理过程, 认为降低了开发效率, 浪费了时间。正是由于这种观念才使需求的渐变不可控, 最终导致项目的失败。

3.6 精确的需求与范围定义并不会阻止需求的变更

并非对需求定义的越细, 越能避免需求的渐变, 这是两个层面的问题。太细的需求定义对需求渐变没有任何效果, 因为需求的变化是永恒的, 并非需求写细了就不会变化了。

3.7 注意沟通的技巧

由于需求的变更可能来自投资方、也可能来自用户方和开发方, 作为投资方可能不愿意为需求的变更付出更多的成本, 而开发方有可能主动的变更了需求目的是使软件做的更精致。于是作为需求管理者, 项目经理需要采用各种沟通技巧来使项目的各方各得其所。

4 结束语

需求管理是软件项目中一项十分重要的工作, 据调查显示在众多失败的软件项目中, 由于需求原因导致的约占到45%, 因此有效的需求管理是企业软件开发项目顺利达成目标的重要支撑条件。理解项目开发的目的和用途, 梳理用户需求, 设计系统的各项功能需求, 监控需求变化, 进行需求确认, 对需求风险进行防范, 以一系列的方法和措施实施需求管理工作, 才能推进软件项目良性发展, 达到用户与软件开发企业的双赢。

摘要：需求管理是整个软件工程的管理的基础, 也是项目成功的关键所在。本文论述了企业软件开发项目中需求管理的重要性, 详细描述了软件需求的复杂性, 分析了需求变化的原因, 并针对这些问题提出相应的管理策略。

关键词：需求管理,软件需求,需求变化

参考文献

[1]吴艳艳.软件项目管理中的需求管理[J].信息技术与信息化, 2008 (2) .

[2]唐薇娜.正确应对需求变更[J].软件工程, 2007 (6) .

软件开发过程质量的项目管理 篇8

关键词：问题管理,DevTrack,软件项目过程质量

引言

目前, 计算机软件的规模和复杂度在不断增长, 国内软件企业也纷纷引入软件项目管理的理念。但国内软件企业对于软件项目的认知, 在一定程度上盲目多于理性、理论多于实践。在软件项目开发过程中, 从项目立项到推出完整产品, 需求的控制和软件缺陷的管理都直接影响到软件的进度和质量。软件项目管理为了监督和跟踪项目, 一般都会要求引入需求变更控制流程和缺陷跟踪管理流程。一般大型软件项目都会为这两个流程制定专门的管理规范, 并引入专门的工具, 例如Rational的系列工具。在中小型软件项目中, 通常都会引入缺陷管理工具, 但是对需求控制一般要求不会太严格, 管理流程也相对放松, 通常都是通过文档管理来控制需求变化。而缺陷管理主要用来确保每个被发现的缺陷都能够被有效处理, 使用得比较好的才会有目的地用工具进行缺陷数据的收集和分析。实际使用中, 在跟踪项目计划时, 需求变更工具和缺陷跟踪管理提供的数据也是项目管理人员用来确定项目状态的重要依据。在项目时间有一定跨度、需求变化较大的情况下, 项目计划会需要不断修改, 最后是项目计划跟在实际情况后面修订, 原来制定的项目计划难以细化和落实, 只能停留在纸面上, 失去了计划的意义。而开发项目中隐藏的缺陷也随着需求的变动不断增加。软件产品即使最终推出, 也难以保证其达到预期质量, 更不用提获得足够的客观数据来提升软件项目过程质量。

1 软件项目现状分析

该公司面对的是特殊客户, 整个研制过程按照客户规定, 在研制合同确立以后, 要经过方案论证、初样研制、正样研制阶段, 经过客户试验合格, 最终才能实现设计定型。尽管每一步都有完整的评审过程, 评审也都要邀请外部专家参与, 但由于时间和环境等原因, 往往难以达到客户和公司期望的效果。这样控制质量完全依赖大节点的评审, 让软件缺陷难以提前得到验证和修订, 一直到试验阶段才会比较集中地暴露出来, 这时修正, 工作量比设计前期增大, 而其它成本也大大上升。而对项目管理人员来说, 由于节点时间长, 对项目的动态和实际进展, 主要是通过项目会议来把握项目计划。这样, 除了依靠经验以外, 很难有什么合适的手段, 更难以做到精确掌握。对于项目开发过程中的项目需求和缺陷的控制, 很难进行有效管理。尤其是随着这两年公司业务的快速发展, 公司总部分成本部和新园区办公, 又新增多处外地研发中心, 对项目管理方式的改进有着迫切的需求。经过分析, 同一般商业软件项目相比, 该公司软件项目具有以下一些特点:

(1) 项目数目多, 而大部分项目规模较小, 但是对研制过程必须经过的阶段要求严格, 时间较长, 全部流程完成平均时间在两年以上;

(2) 项目起始阶段, 除了硬件样机性能指标, 客户其他需求一般都不清晰, 公司也缺乏一个有效的需求开发和控制机制。由于开发过程时间长, 中间其它需求变化会比较大, 有时客户需求变化有一些随意性, 并且客户需求基本都要遵从;

(3) 一般应用于嵌入式环境, 调试环境比较差, 对于界面等要求相对较低, 但是和硬件紧密结合;

(4) 在产品定型以前, 一般样机很少, 通常只能满足开发调试和现场试验需要, 难有条件做系统的黑盒测试。

2 软件项目管理改进

基于公司的软件项目现状, 提出一种新的思路。一个软件项目源头就在需求, 整个项目开发过程就是为了有效地实现这些软件需求。在出现实际设计不符合需求时, 就要通过缺陷管理来解决问题, 使设计和需求相符合。而需求变更和新增需求过程, 也是由于需求变化, 导致设计不能和需求相一致, 给软件项目带来新的设计变化要求。如果把项目按照需求分解成一系列问题, 实际的软件设计也就是把这些需求问题细化, 软件编码就是对需求问题做出具体化解答。因此, 如果把需求当作一系列需要解决的问题, 整个项目开发过程就是这样一个问题求解的过程, 项目管理就是合理地调配资源, 来配合实现问题求解。缺陷管理工具针对发现的具体程序缺陷, 都有一套完整的闭环流程, 一般都包含从“缺陷提交”, 到“缺陷分配”, 再到“缺陷解决”, 最后到“回归验证”的过程。工具还会提供强大的统计和报表输出功能, 对历史过程也会有完整的记录保留。缺陷管理工具在流程追踪上的优势是很明显的。而从问题管理的角度来看, 和需求问题相比, 缺陷就是一类范围定义得很清晰的问题。如果能够通过缺陷管理工具实现问题的分解和关联, 一个项目软件设计的进度管理、需求管理、故障—管理等都可以在缺陷管理工具上结合起来控制完成。

3 DevTrack功能简介

为了实现上述基于问题的管理模式在对目前比较流行的商用和开源软件进行多方比较后, 最终选择了TechExcel公司的DevTrack来实施。DevTrack的基本理念就是基于问题驱动, 和我们的上述想法非常吻合。在DevTrack中, 可以把开发过程组织成项目, 项目可以分解成一系列任务, 这些任务又由工作流程有效地组织起来。对于复杂的项目, 可以分解成几个子项目, 然后对子项目执行任务分解。任务是项目管理中最小单位, 可以分成三类:基于新需求的任务;需求修正类型的任务;产品缺陷类型的任务。这样一个软件系统设计要解决的问题, 就和软件项目管理中的一个个任务对应起来, 可以通过DevTrack这样一个工具来实现底层的结合。

软件系统设计需求和DevTrack中软件项目分解任务的对应关系DevTrack可以基于状态或基于事件跃迁触发工作流程的流转。不只是处理任务, 流程中发生的各种事件, 如状态改变、增加附加信息、任务延迟预警、任务延迟等, 都可以设置为触发源。所有事件都有多种灵活的告知机制可选。DevTrack的功能都基于灵活定制来设计, 项目相关的内容都可以由管理员根据需要定制。和软件项目过程密切相关的主要有两项:

(1) 定义项目的成员结构, 对成员组别和相关的权限、技能、成本等信息实行管理, 还可以根据工作任务动态计算工作负荷。

(2) 定制项目的工作流程, 对于复杂的项目, 可以分解成几个子项目, 对每个子项目定义自己的工作流程。此外, DevTrack还提供了和多种配置管理软件的接口, 可以实现无缝连接。出于费用方面的考虑, 试点项目选择了开源的Subversion。利用DevTrack的集成接口, 在Subversion上进行的操作, 和DevTrack的内部动作一样, 可以方便地触发内部流程。

4 项目实践

公司挑选了一个典型项目来作为试点, 项目主要开发人员在新园区, 而测试人员、客户代表以及项目管理人员位于本部, 硬件服务器和网络配置等主要设施也在本部。管理员首先配置了项目工作流程, 对项目设置了任务处理流程、故障处理流程。为与公司管理制度配合, 增加了工作的月计划流程, 月计划流程通过和前述任务处理及故障处理流程关联来实现。在项目执行过程中, 按照如下模式来执行:

(1) 项目管理员设置项目基本内容、项目成员。在本项目中, 项目人员划分成项目经理、测试经理、项目管理员、开发人员和测试人员五种角色组, 每组设置恰当人选, 其中部分人同时属于两个组;并对应不同开发阶段设置了项目状态, 对每种角色, 在不同状态设置了不同的权限。

(2) 在项目起始阶段, 对应系统需求文档, 没有设立子项目, 直接分解出不同的项目任务, 并下达给对应的开发人员组的责任人。

(3) 开发人员通过配置管理工具提交设计文档和设计代码的同时, 测试人员会得到通知, 并可以启动测试流程。

(4) 测试人员如果认为设计有问题, 可以提出故障, 启动一个新任务, 通过故障处理流程和项目经理指配给责任开发人员。

(5) 开发过程中间经过评估, 发现需要新增需求, 项目经理就通过任务处理流程来处理。出现需求变更的情况, 在工具中对原任务做出说明后, 任务提前返回项目经理处, 在变更以后, 重新进行处理。整个过程会通过DevTrack自动记录下来。

(6) 项目运行过程中, 项目管理员随时通过DevTrack报表统计项目状态、任务处理、需求变化等状况, 并产生报告。还可以按照任务和缺陷的数目、变化趋势、处理情况等, 设置各种预警条件, 自动产生各种项目状态提示。

结束语

目前试点项目已经基本完成, 这种模式得到了成功应用, 取得了预期的效果:

(1) 由于需求和任务对应关联增强, 对于需求变化情况和需求变更评估变得更为有效;

(2) 细化了控制节点, 项目管理人员也对项目状态有了更清晰的掌握;

(3) 相比过去的方式, 项目运转的流程更清晰, 获取了更多有效的项目流程信息, 对提升后续的项目软件流程控制有借鉴作用;

(4) 更丰富的报表和项目流程与电子邮件的紧密结合, 提升了项目内部人员之间以及项目内外人员之间的沟通效率。

实际中发现这种方式在项目成员绩效和项目人员工时考核上也有一定作用, 但在资源管理和成本控制等方面, 必须和项目管理计划等结合才能更好地发挥作用。

参考文献

[1][美]凯西·施瓦贝乐.IT项目管理, 王金玉时郴译[M].北京:机械工业出版社, 2002.

[2]AlanM Davis.Using RequirementManagement To Speed Delivery of HigherQualityApp lica-toins[Z].Rational Soft2ware Corporation, 1995.

[3]TechExcel Incorporation.DevTrack6User Guide[Z].Te2chExcel Incorporation, 2005.

软件开发项目管理信息系统研究 篇9

1 软件开发项目管理信息系统的发展现状

1.1 国外软件开发项目管理信息系统的研究现状

在国外,依托计算机应用的项目管理在上个世纪就已经出现,随着网络计划技术的不断发展以及网络分析程序的不断完善,分析软件所具备的应用功能也在不断拓展,软件开发企业为了实现软件开发项目管理信息化,越来越关注和重视开发项目管理信息系统的研究和设计。从功能层次角度来看,项目管理软件的不断发展,逐渐分离出三个功能层次,第一层次是基本功能,主要是模拟基础工作流程,实现资源共享,便于项目管理人员操作,基层功能开发在上个世纪80年代就已经完成 ;第二层次体现为两大特点,在基本功能基础上产生分析功能,并通过建立数学模型生成预测功能,再有就是借助网络应用技术,实现了在局域网上的多项目管理,打破了地域的限制,即实现了使用功能和通讯功能 ;第三层次是项目管理功能,旨在提高管理系统的兼容性,实现在线管理。随着各种技术的不断发展,软件开发的日益深入,软件开发项目管理的重要性逐渐显现出来,其在资源管理、进度控制、质量监督、项目跟踪等方面都发挥着积极的作用。

1.2 国内软件开发项目管理信息系统的应用现状

自上个世纪70年代起,国内开始关注项目管理软件的开发和研究,但一直处于初级水平,直到90年代,国内研发主体开始转变为软件企业,项目管理软件研发的专业化进程开始加快,由原来的自主研发、自己使用的小生产方式过渡到社会化大生产,软件产品的功能才得以拓展,随着集成技术的广泛应用以及运行环境的改变,也实现了资源共享。然而近年来国内软件开发企业过于依赖国外技术,项目管理软件的开发和研究出现了滞缓现象,除了技术因素制约外,市场因素也在一定程度上限制了国内项目管理软件的发展。就软件行业发展状况来看,国内软件产业虽然保持着持续增长的势头,但是软件市场并不乐观,市场繁荣的背后隐藏着巨大的危机,真正拥有自主知识产权的软件产品很少,而且主流软件产品也缺乏市场竞争力。

概括而言,现阶段国内软件开发项目管理存在的问题主要体现为以下几点 :其一,不重视项目管理,在实际工作中,管理人员主要依赖于个人的知识技能,缺乏相关理论的指导,管理工作存在很大的盲目性和随意性 ;其二,项目计划有待完善,管理人员对企业的阶段性计划和总体计划的作用缺乏认识,开发目标并不明确 ;其三,不重视项目沟通,信息的利用率不高,缺乏有效的沟通,项目组织结构混乱,项目管理阻碍重重 ;其四,变更管理有待规范,软件开发项目的质量和进度与需求变更联系密切,由于缺乏有效的软件管理机制,变更管理不规范,使得软件开发项目的质量和进度受到了很大程度的影响 ;其五,不重视风险防范,管理人员不具备分析风险的能力,风险防范意识淡薄,缺少应对风险的策略。总而言之,国内软件开发企业主要将精力放到了技术层面上,并没有建立起完善的软件开发项目管理信息系统,现阶段国内软件开发企业的当务之急就是要将软件开发项目和项目管理信息系统融合起来,加强项目管理,提高市场竞争力。

2 软件开发项目管理信息系统的总体设计方案

2.1 系统功能结构设计

项目管理依托于必要的理论知识以及技术和工具,涉及到九个知识领域和五个实施阶段,九个知识领域主要包括项目综合管理、范围管理、质量管理、进度管理、成本管理、沟通管理、人力资源管理、采购管理和风险管理,将这些领域的工作内容应用到软件项目管理中,可以分为五个实施阶段,通过对整个阶段流程运作的管理来实现项目管理预期,基于项目生命周期理论的五个实施阶段,主要分为项目启动阶段、计划阶段、执行阶段、控制阶段和结束阶段,项目开发过程也可以划分为五个实施阶段,实现流程化管理。

对九个知识领域和五个实施阶段进行需求分析,确定软件开发项目管理信息系统的总体功能结构,可以将系统细化为十一个子系统,即综合管理系统,根据项目计划,确定组织程序,实施统一管理,实现项目目标 ;计划管理系统,主要负责各种项目计划的编制、审批、查询等 ;需求管理系统,主要包括变更控制和需求跟踪两部分内容 ;费用管理系统,主要负责项目费用的规划、估算、预算和控制 ;质量管理系统,主要负责项目质量的规划、保证、控制和持续改进 ;人员管理系统,主要包括项目成员沟通管理和个人信息管理两部分内容 ;配置管理系统,主要提供产品入库、变更和配置报告方面管理的功能 ;进度管理系统,主要负责项目执行过程的跟踪、协调和控制 ;风险管理系统,主要负责风险计划制定、风险分析和风险控制的任务 ;售后服务系统,主要提供技术支持、管理规范、在线服务、客户沟通等功能 ;后台管理系统,主要提供数据导入导出、数据表维护、用户数据管理、操作日志管理等功能。

2.2 基于 B/S 结构的设计思想

随着计算机网络技术的不断发展,基于Web的网络管理模式得到了广泛的应用,任何一种Web浏览器都能够在网络节点上实现快速配置和控制,与传统工具相比优势明显,它具备可维护性、升级能力强、开发周期短、远程访问方便等特点,能够兼容多种开发语言,可以直接对数据库进行访问或直接建构客户端界面。传统基于C/S的网络构建模式虽然在在文件服务器模式性能上已经有了很大的改善,但是还存在着一定的局限性,如开发成本高、开放性和跨平台性差、资源冗余度大、生命周期短、安装和维护升级比较困难等,为了改进基于C/S结构的软件开发项目管理信息系统存在的缺点,B/S结构应用而生,并得到了广泛应用,现已成为C/S结构的代换技术。传统的C/S网络结构模式是二层结构,新发展起来的B/S模式是三层结构,即在表示层和功能层基础上又增加了数据层,不仅简化了客户机的工作,还能够在服务器上完成对数据库和应用程序的直接访问,克服了传统C/S模式的局限性,具备开发成本低、开放性和跨平台性强、生命周期长、安装和维护升级比较容易等优点,已经成为现阶段网络开发的主流技术,基于B/S结构的软件开发项目管理信息系统的应用前景十分广阔。

2.3 系统总体技术设计

软件开发项目管理信息系统的总体设计方案包括开发技术支持、数据库设计、安全性设计和运行环境设计四方面内容 :其一,开发技术支持,管理系统的开发技术应采用目前的主流技术,即B/S网络结构模式主要由浏览器、Web服务器和数据库服务器组成,该系统无需安装客户端软件,只要将服务器连接到网络上,就能够实现操作,克服了传统开发应用程序的限制,为软件开发项目提供了更具模块化的设计方式 ;其二,数据库设计,数据库信息建模以及范式分解直接关系到数据库系统的运行效能,因此在设计中应力求逻辑关系简单,简化数据库表的连接操作程序,从而增强系统的整体运行性能,数据库设计的关键在于保证数据库的完整性,主要包括三类数据库表的设计,即基本信息数据表、系统信息数据表和工作表,要保证其在实体、值域、引用以及用户定义等四个方面的完整性 ;其三,安全性设计,基于B/S结构的软件开发项目管理信息系统,具有开放性特点,为了保证系统的安全性,有必要对用户进行分层分级管理,设置加密、权限访问等功能,增强系统的安全性 ;其五,运行环境设计,选择先进的客户端和软硬件,性能良好的应用程序和数据库服务器,如硬件环境可选用小型机配置,创建良好的系统运行环境。

3 管理信息系统各子系统功能的实现

软件开发项目管理信息系统可以细化为十一个子系统,在此以需求管理子系统为例,需求管理的核心是需求分析,这是整个软件开发过程的基础,根据需求工程设计的领域,可以将需求管理子系统分解为获取、分析、规范、验证、变更五个环节,在此基础上设计相应的功能模块。鉴于数据结构设计是系统实现的基础,需求管理子系统的设计思想就是要将功能模块转化为数据结构,然后在通过计算机语言将这些功能实现,需求管理子系统数据结构设计主要包括基本信息表、项目需求表、需求状态表、分析报告表、变更表等内容。对于需求单据的状态变化,主要通过枚举定义来控制,要想获取需求,首先要填写需求单据,需求单据设计包括编码、名称、状态、内容、审核意见等流程,需求单据设计完成后,在此基础上对填写的数据单据进行需求分析和需求规范,然后执行,然后进入验证阶段,得出分析报告表,进行需求变更管理。

4 结论

快速软件项目开发方法探讨 篇10

1 第一天:需求分析及界面设计

1.1 项目展示。

项目名称:学生个人资料信息管理系统。

开发语言:VB6.0。

数据库:Access2000。

1.2 项目需求分析。

功能分析:本案例要求开发人员通过一个界面完成对学生个人资料的“编号、专业、班级、姓名、班委”几项信息进行管理。使用功能上要求可以对数据进行“录入、修改、删除、查询、打印”, 以及对记录的浏览“上一条、下一条、第一条、最后一条”功能。

数据分析:通过学生个人资料的“编号、专业、班级、姓名、班委”几项信息我们可以看出, 在每一项中包含的都是文本内容, 比如编号可以编辑成具有意义的“20070102003”, 其中“2007”代表入学年份、“01”代表生源类别、“02”代表班级编号、“003”代表学生的顺序号, 虽然“20070102003”看上去是数字, 但是在这种不需要运算的情况不需要把它视为“数字”, 而应该设为“文本”。“班委”一项只有“是”和“否”两种可能, 所以选择其为布尔类型。其它几项设为“文本”是不容置疑的。

界面设计分析:本项目要求对学生个人资料的“编号、专业、班级、姓名、班委”几项信息进行管理, 那么在用户界面中就必须有可以控制这六项的地方。在VB中与用户交互的核心对象就是“控件”, 那么, 控件的选择也就决定了用户使用的灵活性和方便性。

1.3 界面设计。

在窗体中添加五个标签“label”。将其Caption属性依次更改为“编号、专业、班级、姓名、班委”。为每个标签后面添加一个可与数据库交互的控件。“编号”——由于其编制有特殊要求, 故选择文本框“Text”。“专业、班级”——由于可能很多人在一个专业或班级, 选择组合框“ComboBox”。“姓名”——这一数据相同的可能性很小, 选择文本框“Text”。“班委”——这一数据只有“是、否”两个值, 选择用“CheckBox”。

界面要实现数据的“上一条、下一条、第一条、最后一条、录入、修改、删除、查询和打印”的功能要求, 选用命令按钮“Command”。通常情况下, 用户可能按专业、班级条件进行查询的时候较多, 故单独设置查询窗体, 由于“打印”的结果通常是在查询完数据后, 将查询结果打印出来, 故“打印”功能放到查询窗体中。通常窗体操作时要控制自身的卸载, 故为其添加一个“后退”功能按钮。

根据以上分析, 要单独设置查询窗体, 具有根据“专业、班级”条件进行查询的功能, 并可以打印报表进行输出。选择控件时“专业”用组合框“ComboBox”, “班级”用列表框“ListBox”。添加一个“MSFlexGrid”控件。“打印”按钮完成的是将查询结果以表格的形式输出到打印纸上, 利用报表可以很方便地实现输出, 但是打印的灵活设置又是打印时经常遇到的常规要求, 故在这里不对报表进行直接输出而是以“打印预览”的形式输出, 再由用户通过调用系统的打印机而灵活设置打印项, 如纸张大小、横纵向、页边距等, 因此在查询窗体中除了设置“查询”按钮, 还设置“打印预览”按钮。

程序设计分析:此项目根据以上需求分析可知, 共需要两个窗体文件、一个报表文件。这三个对象中有大量的对数据库操作的需求, 故考虑采用ADO对象技术, 增加模块对象, 以方便使用对象。

数据库需求分析:根据项目分析结果, 我们发现虽然有两个窗体和一个报表在与数据库交互数据, 但是, 实际上操作的只有“编号、专业、班级、姓名、班委”几项信息, 而且我们在设计第一个信息管理界面时已将这几项信息安排到了同一个界面中, 故我们只需要设计一个表就可以了。

1.4 数据库设计。

建立Access数据库名称为:grxx.mdb;在此数据库中设计数据表:Grxx_tbl;在表Grxx_tbl中添加“G_ID、G_SPEC、G_CLASS、G_NAME、G_BW”六个字段, 数据类型全部设成“文本”, 同时设置“G_ID”字段为主键。具体设置见表1所示。

1.5 用户界面设计。

(1) 工程文件的建立:在打开VB6应用程序时, 选择工程为“数据工程” (数据工程中自动添加一个Form、一个数据环境、一个数据报表、工具箱中自动添加ADODC、DataGrid和MSFlexGrid表格控件) , 将Form改名为“frm_xx”, 然后添加一个窗体改名为“frm_cx”, 添加一个模块改名为“mymd”, 移出数据环境, 将数据报表改名为“Drpt”, 然后把工程及工程中的所有文件, 和数据库“grxx.mdb”保存在同一个文件夹中。

(2) Frm_xx窗体的设计:具体各控件的属性设置见表2所示。

(3) Frm_cx窗体的设计:查询条件中的专业为Combo1、班级为List1, 表格为MSFlexGrid1, “查询”按钮名称为“Cmdcx”, Index属性为0, “打印预览”按钮名称为“Cmdcx”, Index属性为1。

(4) Drpt报表的设计:数据报表设计要显示所有字段的信息。

a.报表数据源的设置。设置报表的DataSource属性值是报表的必须条件, 在这里不用绑定的形式, 而是用结果集在运行时动态赋值。

b.报表标头和报表注脚的设计。在报表标头部分添加三个RptLabel, 分别设置Caption属性值为“学生个人资料”、“打印日期:”、“第页”;再添加“当前页码”%p和“当前日期”%D两个控件。在报表注脚部分添加一个RptLabel, 设置Caption属性值为“我的报表!”。

c.页标头和页注脚的设计。在页标头部分添加四个RptLabel, 分别设置Caption属性值为“编号”、“姓名”、“专业”、“班级”;再添加RptLine控件, 拉伸成两条横线和五条竖线。在页注脚部分添加一个RptLabel, 设置Caption属性值为“共页”;再添加“总页码”%p控件。

d.细节部分的设计。在细节部分添加四个RptText, 默认情况下显示“非绑定”, 分别对应页标头部分的五个RptLabel位置放置着五个控件, 然后依次设置其DataField属性值分别为“G_ID、G_NAME、G_SPEC、G_CLASS”。

(5) mymd模块的设计:在“工程”主菜单中选择“添加模块”子菜单, 这时添加模块Module1到工程中。将工程名称改为“mymd”。

(6) 工程启动对象的设置:在“工程”菜单的“属性”子菜单中设置启动对象为“Sub main”。

2 第二天:

:代码编写 (略)

3 第三天:

:应用程序发布

3.1 编译可执行文件。

VB的可执行文件的编译是通过“文件”菜单的“生成DataProject.exe”菜单项进行的。在这里名称改为“学生个人资料信息管理系统”, 同时将这个文件保存在与工程文件相同的路径下。

3.2 应用程序打包和发布。

在打包前先建一个文件夹, 名称改为“学生个人资料信息管理系统安装包”。然后将工程文件关闭, 再利用VB自带的打包向导, 进行打包。打包时注意包含文件必须有“学生个人资料信息管理系统.exe”和“grxx.mdb”。

发布时只需双击“Setup.exe”文件就可按照安装向导进行安装。

4 结论

以学生资料个人信息管理系统为例, 从项目需求分析到界面设计和数据库设计, 从代码实现、编译可执行文件到应用程序的打包和安装注意事项, 每个环节均贯穿于项目中, 确保了项目的完整性。可以说通过本项目的实践训练, 编程者就可以在短时间内将零散的知识点完整地牢记在心, 并具有了软件项目的整体开发经验。

参考文献

软件项目的需求变更管理 篇11

需求管理的常见误区

软件项目的范围控制应该是在需求分析阶段就开始的，然而很多项目经理针对需求分析存在不少认识误区。

误区1：开发商和用户仅就软件需求的基本轮廓达成一致即可，具体细节准备日后协商。

从项目管理角度分析，这是非常危险的，许多软件项目失败的最主要原因就是需求分析阶段对问题、流程、细节的描述不够准确，导致后期预算超支或者工期延误。

正确的方法是：在需求分析阶段，双方必须对项目的应用背景、功能需求、性能需求、可靠性需求、可用性需求、操作界面需求、外部接口需求，以及项目评审的方法、标准、过程进行全面、细致地研究讨论，逐一进行明确。

误区2：软件需求是软件必需向用户提供的功能和界面，功能上满足需求就足够了。

从软件需求工程角度分析，这只是认识到了软件系统的功能需求，忽略了软件的非功能需求和设计约束，需求捕获不够全面。软件需求工程理论认为，软件需求包括功能需求、非功能需求和设计约束三方面内容。

正确的方法是：除了要明确软件的功能需求，还需要进一步明确非功能需求（即软件产品所必备的属性和品质，包括可靠性、可用性、安全性、可扩展性、可移植性等）和设计约束（即软件研发必须遵守的特定规约、限制条件、政策标准,如软件必须采用国内自主知识产权的数据库产品）。

误区3：需求调研的对象是用户，用户就是软件产品的最终使用人员。

从项目管理角度分析，该观点缺乏对项目相关人全面、系统的认识，对用户的概念理解不到位。“用户”是一种泛称，它可细分为客户、最终用户和间接用户三种类型。例如，很多企业的一把手并不直接参与软件的采购和操作，但是其对于软件项目实际上起到了关键意义的决定作用，属于最重要的间接用户。

正确的方法是：要充分认识用户的多重性、层次性、复杂性，在进行需求调研时应首先对用户进行分析、分类，根据重要性、优先级、特殊性对各类用户进行排序；其次，是针对不同类别的用户分别制订不同的需求调研计划，全面开展需求调研。需要重点指出的是，对于由多个业务部门共同参与的软件项目，在确认软件需求时一定要得到全部参与部门的共同认可。

误区4：按照“需求、设计、编程、测试”步骤研发出的软件不必考虑需求跟踪问题。

从软件工程角度分析，这是对于需求变更过程缺乏系统的认识的表现，严格线性顺序的开发模型并不能保证各个开发阶段的工作成果与需求保持一致。实际上，由于需求变更的不可预见性和必然性，各个阶段往往以螺旋的方式渐进。

正确的方法是：需求跟踪应该贯穿于整个软件需求管理阶段，需求跟踪的目标是实现《产品需求规格说明书》和软件产品之间的双向可追溯。

做好需求工程

需求分析是软件工程项目最重要、最基础的起始阶段，为后续的规划设计阶段提供参照依据。在软件研发项目过程中一定要树立需求工程的意识，将需求视为一项系统工程。为了能够全面做好需求管理，应根据项目实际情况严格划分项目阶段，清晰界定、定义项目阶段的基线，在每个项目阶段制订、执行阶段性需求管理计划，逐一认真落实。

1．需求工程的结构及目标任务

需求工程是一个包括创建和维护系统需求文档所必需的一切活动的过程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工程结构如图1所示，需求开发与需求管理的流程如图2所示。

需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求开发过程有3个主要活动：需求调查、需求分析、需求定义。需求开发过程可分为两个阶段：用户需求调查阶段和产品需求定义阶段，两个阶段在逻辑上通常是以迭代的形式进行的。需求开发过程产生的主要文档有《用户需求说明书》、《产品需求规格说明书》（对于软件产品而言就是《软件需求规格说明书》）。

需求管理的目的是在用户与开发商之间建立对需求的共同理解，维护需求与软件工作成果的一致性，并控制需求的变更。需求管理过程有三项主要活动：

（1）需求确认:开发商和用户共同对需求文档进行评审，双方就需求达成共识后做出书面承诺，使需求文档具有商业合同效果。

（2）需求跟踪:通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。

（3）需求变更控制:依据“变更申请、审批、实施、重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。

需求管理过程产生的主要文档有《需求评审报告》、《需求跟踪报告》、《需求变更控制报告》等。

2．需求的跟踪

需求跟踪的目的是建立与维护“需求、设计、编程、测试”过程的一致性，确保所有的工作成果符合用户需求。需求跟踪有两种方式：

（1）正向跟踪：检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。

（2）逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。

正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵。

组建变更控制管理机构

项目变更是指项目实施过程中由于环境或者其他因素的变化而对项目部分或者全部功能、性能、架构、技术指标、集成方案、进度、质量等方面做出改变。

1．变更控制管理的任务及目标

信息系统项目实施过程中变更是无法避免的。变更控制管理的任务是：建立规范、严格、可行、高效的变更控制体系机制，组建变更控制管理机构，出台变更管理制度；对用户提交的变更请求进行快速的响应、受理；及时分析、研究、评估变更的可行性、成本、代价、范围；对于确定接受的变更请求制订变更实施计划方案及配套应对措施，实施变更任务，进行变更测试检查，做好变更记录。需求变更控制的最终目标是：通过建立严格规范的变更控制管理流程,拒绝不切合实际的变更，减少变更带来的风险，防止变更范围扩大、蔓延，杜绝随意的变更申请及受理过程等。

2．变更控制管理机构的建立

组建有效的变更控制管理机构和制订配套的变更控制管理制度，是进行变更控制管理的重要基础和前提保障，否则变更控制管理将成为一纸空文。变更控制管理机构（形式上可以是“变更控制管理委员会”、“变更控制管理办公室”、“变更控制管理组”等）是一个特殊组织，对项目负责人直接负责，它不受现存的职能组织结构的束缚,可由来自不同机构、不同部门、不同专业、不同岗位的人员组成，各成员划分权限岗位、明确职责、落实责任、协同工作。一般情况下，变更控制管理机构内部应至少配备以下四种角色的成员：

项目管理人员（类似于“项目经理”）：主要负责制订项目管理制度和项目管理计划，督促、检查、落实、考核项目执行过程，做好项目干系人之间的沟通协调工作。

技术负责人员（类似于“总工程师”）：主要负责项目中信息技术平台的分析、建模、设计、测试、实现。

业务管理人员（类似于“业务经理”）：主要负责收集整理业务需求、编写需求说明书、验证和评审需求、管理和控制需求变更。

通信联络人员：主要负责项目组织内部成员之间的信息发布。

需求变更控制 管理工作程序

需求变更的目的是希望软件产品更加符合用户的需求，但是变更涉及的人员多、范围广、影响大，在进行变更控制管理时必须建立严格、规范的变更控制管理工作程序，这样才能使项目始终按照预定的方向、模式、进度进行。

需求变更控制过程中最难办的事情不是“满足用户提出的变更请求”，而是“在用户认同支持、追加项目投资经费的前提下尽快完成变更任务”。用户往往认为提出变更需求是基本权利，而软件开发商往往认为只有义务解决在《用户需求说明书》、《产品需求规格说明书》中预先定义的各类需求，除此以外都应该拒绝或者在用户追加投资的前提下解决。

现实中信息系统项目的目标是具有一定弹性的，这一点尤其重要，用户和软件开发商之间为了达成共同目标不可能针锋相对，项目管理人员需要利用高超的管理艺术、沟通技巧、人格魅力，在对立博弈的关系之中寻求最佳的平衡点。

另外，有必要强调的是，在项目实施过程中，变更处理越早，难度越小，损失越小；变更处理越迟，难度越大，损失也越大。而且，任何变更都必须经过项目建设全部相关方（建设单位、承建单位和监理单位）多方确认后才能计划实施，严禁任何一方擅自变更。对项目变更的范围要有明确的界定，而且项目建设全部相关方对变更范围的理解上都没有任何异议。

软件开发项目 篇12

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.