基于团队开发模式的项目管理研究Word格式.docx
- 文档编号:18478912
- 上传时间:2022-12-17
- 格式:DOCX
- 页数:50
- 大小:332.58KB
基于团队开发模式的项目管理研究Word格式.docx
《基于团队开发模式的项目管理研究Word格式.docx》由会员分享,可在线阅读,更多相关《基于团队开发模式的项目管理研究Word格式.docx(50页珍藏版)》请在冰豆网上搜索。
第一章前言
1.1软件项目开发中的困难
软件项目做不好的原因,发现70%的项目是因为管理不善引起的,而并不是因为技术实力不够,进而得出一个结论,即管理是影响软件研发项目全局的因素,而技术只影响局部。
美国工业界和政府部门开始认识到,在软件开发过程中,最关键的问题在于软件开发组织不能很好的定义和管理其软件过程,从而使一些好的开发方法和技术都起不到期望的作用。
在无纪律的、混乱的软件开发状态中,开发组织不可能从软件工程的研究成果,即较好的软件方法和工具中获益。
在很多组织中,软件项目开发进度经常严重滞后、经费预算往往超支乃至翻翻,在这种情况下,软件开发组织一般都不能提供使开发项目避免这些问题的基础设施和资金。
中国软件企业面对的软件开发问题更是明显。
软件企业规模小,软件项目超进度、超预算,软件质量低是中国存在的普遍问题。
美国和印度的软件产业已步入以过程为中心和工业化的生产,而我国仍处于以结构化为主的生产方式。
如何改善软件质量,成功地管理软件项目是我们的难题。
软件项目失败的原因有:
定义不明确;
缺乏一个好的软件研发过程;
没有一个统一领导的产品研发小组;
子合同管理不严格;
没有经常注意改善软件过程;
对软件构架很不重视;
软件界面定义不完善且缺乏合适的控制;
软件升级暴露了硬件的缺点;
关心创新而不关心费用和风险;
标准太少而且不够完善等等。
软件开发越来越复杂,软件功能也越来越丰富。
而几乎所有成熟的商业软件,都是靠一个开发团队齐心协力的血汗结晶。
在一个项目的全部开发过程中,并不是完全由固定的开发人员完成相应的任务。
同时,项目开发的各个阶段也是由不同的开发人员来参与。
那么,我们如何在项目的开发、维护和升级过程中如何能够更好的利用在开发过程中产生的结果呢。
这就是项目管理中软件文档的问题。
软件包括源代码,发布版本,和相关资料,这些资产通过一定的操作,都可以转化成为固化资产。
如果研发人员的文档与代码是一致的,那么交接工作会顺畅得多;
如果前期的设计文档足够详细和清晰地表达了上层设计的思路,那么下一级设计或者实现不会因为人员变更而受到较大影响;
如果随机资料与发布版本一一对应,并且完备地描述其细节,那么设计人员的离开并不会增加太多维护工作的难度。
而这些却都是我们在软件项目开发过程中所面临的问题。
那怎么解决这个问题?
“没有规矩,无以成方圆”,制定研发规范,将无形的脑力劳动显式化。
研发规范,主要是为了细化研发过程,便于流程度量、改进和控制。
研发规范的一个重要的目的:
规范化不同人员的表达方式,减少不必要的信息沟通,提高交流的效率。
如何制定研发规范?
各个公司根据各自的经验,和参考国内国际相关标准,都会有自己的一整套系统规范。
如软件项目,从项目立项阶段提交项目立项报告,可行性报告;
到系统设计方案,详细设计报告,测试规程,以及各种评审报告等等。
其模板也多种多样。
规定了这样的一套研发规范,是不是研发过程真的就规范起来,事实并非如此顺利。
这是因为研发规范不仅仅包括这些各种各样的“文档模板”,更重要的是操作规范。
例如,不同研发阶段需要什么样的资源、应该完成什么样的操作、产生什么样的文档才算结束?
这些操作又有什么样的要求?
这就是流程规范。
所以完善的研发规范应该由一系列的流程组成,每个流程包括一些相关操作,和输入输出。
1.2用面向对象技术解决困难
对象是在程序中用来完成特定任务的基本构件,如维护一张列表(List)或画一条线。
对象设计和开发技术具有一些特性,这些特性可以帮助我们克服软件项目中的困难。
动态和静态需求描述:
它为我们提供了一些方法,使我们不仅可以获知程序应该具备的功能,而且知道如何去实现。
动态和静态设计描述:
它不仅提供了定义如何组织代码的方法,还提供了定义各对象间交互的方法。
封装(Encapsulation):
对于系统其他部分,对象的内部工作过程是屏蔽的,允许对象状态、功能及操作的分离。
继承(Inheritance):
该特性允许有多种类型的对象,对象可以重用,你只需关心新的功能。
聚合(Aggregation):
从一个小的简单的对象生成一个大的功能复杂的对象,用来处理复杂的事务。
包(Packages):
将多个对象封装成一个较大的构件,隐藏其内部工作细节,将其抽象化,以便以不同的细节级别来管理复杂程序。
利用这些特性的优点能提高团队的积极能动性和产品质量。
简单地说,面向对象的软件工程之所以能够实现软件开发的“更快、更省、更好”,主要有以下三个原因。
●对象提供了灵活性和可控性,这对处理需求的变化是必须的。
动态和静态需求描述给开发者和客户提供了一个清楚的、可以理解的系统描述;
封装和动态、静态设计描述能帮助你在开发过程中正确地估计和减少需求变化带来的影响;
继承使得对功能的扩展变得非常高效。
●对象的使用使得团队协作更加便利。
封装的使用使得个人和团队能并行使用这些构件,并确保构件的内部工作不会影响其他开发人员的工作,而且对象设计图表在最大程度上方便了团队成员之间的相互沟通。
●对象能帮助管理复杂的项目。
一个设计良好的对象,其功能和使用很容易理解;
由于对象封装了其功能,不用关心其实现细节,因而他们之间的交互也很容易理解,从而使程序代码容易读懂。
由于只需关注对象之间的交互,因而开发者才有可能设计出一个更简单、更一流的方案。
对于系统复杂性问题的解决方法是将一个大系统分割成一组模块,每个模块有叫嚣的状态空间,其状态转移容易理解,并且经试验是正确的,即前面所说的封装与模块化技术。
在面向对象技术中,模块就是对象和子系统。
如果你的设计是基于类的模块化设计,那么状态转移很容易跟踪,并且代码的复杂度也得到控制。
如果团队开发的代码设计良好,其排错率是很高的。
当发现错误时,引起错误的原因是很容易找到,并且不会因为修改它而引起另一个错误。
总而言之,高质量的代码是软件项目的目标。
而且,复杂的代码很难测试。
标准模块化代码使得模块能被单独测试,这样一来,代码路径的数量得到控制,并且确保测试覆盖了这些路径。
相反,如果代码过于复杂,不可能作到充分地测试代码。
复杂性引起的另一个问题是团队很难合作。
如果代码不是标准模块化的,程序员之间会经常互相影响。
由于程序某部分的变化会影响其他人,不断和相关负责人员商量,因而程序员往往在互相协调上花时间比编写代码的时间还要多,同时也降低了他们的积极性和士气。
提高团队的积极能动性需要降低复杂度。
运用抽象、层次、封装、标准模块化等概念,项目经理可以更好地控制住系统的复杂度。
1.3统一建模语言作为管理工具
标准建模语言UML是90年代中的一个产物,它不仅同意了Booch、Raumbaugh和Jacobson的表示方法,而且对其作了进一步的发展,并最终同意为大众所接受的标准建模语言。
至1996年底,UML已稳占面向对象技术市场的85%,成为可视化建模语言事实上的工业标准。
由于UML是一种标准的建模语言,因此在进行软件开发时有必要采用这种标准的建模语言来进行建模、分析和设计。
采用UML及其支持工具作为面向对象方法开发的环境,可以有效、方便开发出符合用户需求的软件产品,并且有利于用户之间交流在开发各阶段产生的产品。
解决好基于UML及其支持环境下面向对象方法的项目管理,可以更有效地重用软件产品,提高软件的生产率和质量,以及减少软件项目的成本和时间。
UML是由一组相一致的图组成的,这些图可以用来沟通和描述一个软件系统的需求、设计和编码。
可以用它在不同的抽象级别上提供系统设计和需求视图,它的输出产品所提供的通用视图是进行协作设计的基础。
本文中并不关注UML是什么,而是描述了UML及其工具在项目开发过程中完成的任务,这些任务是研究和设计活动的组成部分,用于基于对象的软件开发。
UML主要的作用是定义系统需求和设计并将其文档化。
这点非常重要,你可以期望UML在分析和设计阶段发挥重要作用。
但由于需求与测试计划紧密相关,而且代码直接反映了设计,所以在整个开发过程中持续使用UML是很重要的。
如果只在初期使用UML并且不把项目的UML输出产品与构造和测试活动结合起来,将失去对设计的控制。
如果那样,所做的一切只不过是画一些漂亮的图而已。
1.4应用MicrosoftVisualSourceSafe组织软件开发项目
代码是宝贵的资源。
为了保护它,很多开发者应用一些版本控制系统以保护文件避免未授权的修改和意外的错误。
这些系统有很多种,从有关程序注释的更改和存储旧版本的君子协定到自动跟踪修改和历史记录的复杂的软件系统都有。
大多数来源控制系统对于单独的源文件是有效的。
但是,它们几乎全部不能在文件间建立关系。
这在MicrosoftWindows的环境中将引起问题,因为在该环境中,一个应用程序可以包含多个可执行文件和由许多不同的源文件建立的动态连接库,它们有可能在很多其它应用程序中重复使用。
当今,管理源文件间的关系和保护源文件的内容本身同样重要。
MicrosoftVisualSourceSafe版本控制软件通过将项目管理的任务和源代码的控制结合起来,解决了这个问题。
以注重在管理源文件的同时管理项目,VisualSourceSafe提供了对该问题的优秀的解决方案,是用标准的、面向文件的来源控制系统不易实现的。
MicrosoftVisualSourceSafe将文件存储在网络的中心数据库中,而不是在一个普通的DOS目录中。
在系统级,该数据库表现为一个“黑盒”。
但是,当以VisualSourceSafe为视图时,可以看到该数据库中包含了你的组织到项目分层结构中的所有源文件和历史记录。
当你检索一个文件时,VisualSourceSafe将在数据库中标记该文件为签出,然后允许你在你的机器上对该文件进行修改。
当你将该文件放回时,VisualSourceSafe更新它的数据库并重新修改你的机器对文件的访问权限为只读。
然而,这和面向文件的来源控制有什么不同呢?
对于每一个改变,VisualSourceSafe数据库记录并追踪那些对于面向文件的系统不可用的项目信息。
每当文件被加入,修改,共享,移动,或从项目中删除,VisualSourceSafe将同时更新文件和项目的历史记录。
你可以应用项目历史记录来简化这些工作:
1、在连编前浏览指定项目及其全部子项目中所有文件的状态。
缩小那些由于在某一日期连编可能引起错误的指定文件的改变信息。
2、重新生成所有应用程序的前一版本。
3、维护被许多不同应用程序共享的源文件。
4、确定哪一个项目将由于改变被多个不同应用程序共享的文件而受到影响。
5、管理通用应用程序的特定客户版本。
对于软件开发人员来说,试图通过面向文件的系统来完成这些工作,将是令人难以忍受的琐碎且无益的。
正如下述的方案所阐述的那样,VisualSourceSafe面向项目的版本控制通过直接进行这些工作,将开发过程流水线化了。
第二章软件项目管理概述
2.1项目管理的内容
关于项目管理的内容DonaldJ.Reifer在《SoftwareManagement(5thEdition)》中给出了项目管理的3P原则的精神主要体现为规范软件开发过程、标准化软件产品和管理软件开发人员。
RogerS.则提出了另一个3P原则,指出项目管理集中在三个P的管理上:
People、Problem和Process。
而UML的三个主要创始人Jacobson、Booch和Rumbaugh提出的项目管理的4P原则不但包括Reifer的3个P,而且还加上另外的第四个P(Project)和工具(Tools).
无论3P原则还是4P原则,他们对项目管理内容的定义基本上是一样,都是对软开发过程中所涉及到的主要要素(开发人员、开发过程和产品)的管理。
虽然Rifer的“Product”和Roger的“Problem”在字面上不一样,但内容上是一致的,“Problem”强调的主要是要求解的问题空间,而“Product”强调的是对问题的求解结果。
3P原则中的任何一条原则与其它的原则是关联的,并且与你用于指导和控制软件项目中的方法、工具和技术是相关的。
只强调3P原则中任何一方面都不足以使项目成功,必须同时强调三者。
同时,在3P原则中做出一种平衡是必要的,我们有必要做出某些折中,以使得三者能够达到一个平衡点。
生产一个大规模的软件系统是一项高智慧劳动密集的活动,在工作开始之前必须已经做好以下的准备工作:
●确定已有足够的并得到相关培训的开发人员,把这些开发人员组织成若干的开发小组,开发人员必须学会合作、沟通、协作以获得预期的结果;
●开发过程和管理过程已经定义并已经就位;
●获得一个相应的软件开发环境和相关的工具以支持选择的开发方法;
●用户需求必须已经按照用户所期待的要求描述好;
●开发计划已经开发,定义好相关的任务和里程碑,并与客户谈判好预算和开发周期;
●一系列的控制措施、度量准则、复查标准、报告和风险管理过程已经就位。
开发工作开始后必须按照预定的计划监视和控制项目的开发进度。
因此,由这P的管理可以引出一系列的管理活动。
2.2项目管理的原则
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对成本、人员、进度、质量、风险等进行分析和管理的活动。
实际上,软件项目管理的意义不仅仅如此,进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力,企业的软件开发能力越高,表明这个企业的软件生产越趋向于成熟,企业越能够稳定发展(即减小开发风险)。
在进行软件开发和项目管理时,应该遵循以下七条软件工程原则。
它们是:
(1)用分阶段的生命周期计划严格管理
这条基本原理意味着,应该把软件生命周期划分成若干个阶段,并相应地制定出切实可行的计划,然后严格按照计划对软件的开发与维护工作进行管理。
不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作,绝不能受客户或上级人员的影响而擅自背离预定计划。
(2)坚持进行阶段评审
软件的质量保证工作不能等到编码阶段结束之后再进行。
在每个阶段都进行严格的评审,以便尽早发现在软件开发过程中所犯的错误,是一条必须遵循的重要原则。
(3)实行严格的产品控制
在软件开发过程中不应随意改变需求,因为改变一项需求往往需要付出较高的代价,但是,在软件开发过程中改变需求又是难免的,当改变需求时,为了保持软件各个配置成分的一致性,必须实行严格的产品控制,其中主要是实行基准配置管理。
(4)采用现代程序设计技术
实践表明,采用先进的技术既可提高软件开发的效率,又可提高软件维护的效率。
(5)结果应能清楚地审查
为了提高软件开发过程的可见性,更好地进行管理,应该根据软件开发项目的总目标及完成期限,规定开发组织的责任和产品标准,从而使得所得到的结果能够清楚地审查。
(6)开发小组的人员应该少而精
这条基本原理的含义是,软件开发小组的组成人员的素质应该好,而人数则不宜过多。
组成少而精的开发小组是软件工程的一条基本原理。
(7)承认不断改进软件工程实践的必要性
遵循上述六条基本原理,就能够按照当代软件工程基本原理实现软件的工程化生产,但是,仅有上述六条原理并不能保证软件开发与维护的过程能赶上时代前进的步伐,能跟上技术的不断进步。
这就需要把承认不断改进软件工程实践的必要性作为软件工程的第七条基本原理。
按照这条原理,不仅要积极主动地采纳新的软件技术,而且要注意不断总结经验。
根据上面的七条原则,在有效地管理项目开发这一过程中所执行的一系列任务主要有三个阶段:
⏹项目计划:
这一阶段的主要任务是
1.执行项目启动和管理任务
2.制定一个包含进度的项目计划
3.使项目团队适应项目管理计划
⏹项目执行:
4.根据项目计划执行项目
5.跟踪项目状态
6.执行里程碑评审,如果需要重新指定计划
⏹项目收尾:
这一阶段的主要目标对项目进行系统的总结从经验中进行学习,以便能够改进过程。
2.3本文要讨论的内容
要想成为一个优秀的项目管理员,不但要求具有比较全面的管理知识和管理能力,而且还要求具有较丰富的计算机知识。
同时,实践经验也是不可缺少的。
项目管理的涉及面较广,鉴于在时间上和能力上的所限,本文不可能探讨软件项目管理每一方面的内容,而是根据UML和统一开发过程的特点,从团队协作、项目风险管理、项目计划管理、项目执行管理、项目收尾管理这几个方面进行探讨如何在项目开发过程中通过以规范的软件开发文档来对项目进行管理。
第三章团队协作
3.1团队授权和角色分配
为了提高团队成员自主参与管理的意识,提高团队的创新力和活力,使团队领导从繁杂的日常事务中脱身出来,保证他有充足的时间进行项目的计划和管理、团队的管理和远景规划。
合理的授权是关键,它要求团队领导抓大放小,区分重要与一般,分清大事与小事,以集中主要精力抓重点、抓大事。
对于授予成员的任务,不干涉其具体的做法,但要对完成的任务质量进行把关。
角色分配是一项复杂的任务。
项目经理的目标是建立一个稳定的、自力更生的团队,有助于项目的顺利进行和团队成员才能的发挥。
因此,在确定团队结构时,必须考虑团队成员的个人需求和项目需求。
在角色分配时应考虑到团队成员的技能、工作背景和经验。
并且对团队成员做必要的培训,这在之后的项目开发过程的顺利进行有着重要的作用。
一般而言,项目组成员配置的规划和职责界定中,通常我们需要几种角色:
技术组长:
负责技术难题攻关,组间沟通协调。
系统分析人员:
负责将用户需求转换成项目内的功能需求和非功能需求,编制项目需求规格说明书,针对每个迭代集成版本与用户交流获取
需求的细化。
设计人员:
负责对需求规格说明书,进行系统设计。
开发人员:
实现设计,完成用户功能。
集成人员:
负责整套系统的编译集成,督促小组系统功能提交,及时发现各模块
集成问题,起到各小组之间的沟通的纽带。
测试人员:
对于集成人员集成的版本进行测试,尽可能的发现程序缺陷,以及未满足需求的设计。
文档整理人员:
负责对小组内产生文档的整合,统一。
系统环境人员:
负责系统编译环境、运行环境规划。
编制系统环境说明书。
维护人员:
系统验收后,维护人员,建议维护人员早期进入项目参与项目测试以便顺利承担起项目维护职责。
在BPDM项目中由于实际的条件约束,我们并没有在这次的迭代开发中配置所有的人员。
表2.1为BPDM项目的角色分配情况。
表2.1BPDM项目角色分配
角色
人数
责任
系统分析员
2人
根据用户需求,确定项目范围编写需求文档
设计人员
3人
根据需求文档实现项目的设计,为项目提供实现的解决方案
开发人员
8人
数据层2人
根据设计阶段完成的类实现文档进行项目的构造
逻辑层3人
界面层3人
测试人员
11人
进行单元测试,集成测试
3.2团队管理
具有共同的工作规范和框架
高效软件开发团队具有规范性及共同框架的工作,对于项目管理具有规范的项目开发计划,对于分析设计具有规范和统一框架的文档及审评标准,对于代码具有程序规范条例,对于测试有规范且可推理的测试计划及测试报告等等。
并且所有成员都明白自己的职责,知道必须完成什么计划?
由谁来完成?
什么时候开始?
什么时候结束?
按什么顺序?
等,总之一个高效的开发团队无论是工作内容还是工作流程都具有不同程度的规范性和标准风格的框架。
具有明确且有挑战性的共同目标
一个具有明确的而且有挑战性目标的团队比目标不明确或不具有很大的挑战性目标的团队效率高得多,通常技术人员往往会因为完成了某个明确的任务,而且这个任务的完成具有挑战性的意义而感到自豪,反过来团队成员为了获取这种自豪的感觉而更加积极的工作从而带来团队开发的高效率,如作为系统设计人员很清楚的知道在什么时候要做到什么,什么时候开始做,什么时候必须完成,为了完成工作必须面临哪些挑战,怎么解决这些困难等为设计出一个高质量的软件项目提供了重要保证,而模模糊糊的去设计一个系统或模模糊糊的就去编写代码是非常危险的,而且会为此付出高昂代价,因此高效的软件开发团队具有挑战性的共同目标。
3.3团队沟通
要管理好团队,必须了解如何有效地进行沟通。
这个道理看起来很容易理解,但很多项目失败都是因为没有建立一个适当的沟通模型。
项目经理必须建立一套便于精确沟通的机智,并坚持使用它。
标准对象建模语言的使用就是这套沟通机制的一部分。
统一建模语言(UML)增逐渐成为一种工业标准。
UML不仅提供了一组能清晰定义系统及其行为的静态、动态图,而且规定了一种记录和共享需求的精确方式。
它能提供一个便于和客户及项目成员间进行沟通的文档。
在项目过程中,一个小组(如分析组、设计组、实施组等)完成其任务后,再把项目交给下一组。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 基于 团队 开发 模式 项目 管理 研究