项目范围管理和敏过程的研究

项目范围管理和敏过程的研究

0项目配置管理不完善许多项目通常在开始时都详细确定项目的范围、时间和成本。一般用户往往对进度的关注度大于对范围的关注度,一个项目半年或一年都看不到具体的产品出来用户肯定是无法接受的,所以一般的软件项目按版本增量迭代进行,在增量迭代中若不断地补充需求,项目就越变越庞大以致超过其计划及预算范围。这使得问题更难解决。产品开发中不断延续的变更会使其整体结构日渐紊乱,补丁代码也使得整个程序难以理解和维护。插入补丁代码使模块违背高内聚、低耦合的设计原则,特别是如果项目配置管理工作不完善的话,回收变更和删除特性会带来问题。造成这样的结果主要原因是由于没有控制和管理好项目的范围。1敏到机械开发的价值观敏捷过程(AgileProcess,AP)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷过程中是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态,它主要由两方面构成:(1)由敏捷软件开发价值观和敏捷原则构成的敏捷软件开发的一个高层需求,这个高层需求构成了一个有效的软件方法的准则;(2)用于软件开发的实践指导的以敏捷软件过程为基础的敏捷方法。敏捷软件开发的价值观和原则:1)敏捷软件开发的价值观。它由四部分构成:个体和交互胜过过程和工具;可以工作的软件胜过面面俱到的文档;客户合作胜过合同谈判;响应变化胜过遵循计划。敏捷软件开发的这个价值观强调了敏捷软件开发中应该集中精力的方面,但不完全排除另一方面,这是理解敏捷软件开发价值观的关键之处。2)敏捷软件开发的原则。敏捷软件开发的原则由敏捷软件开发的价值观引伸而来,是敏捷实践区别于重型过程的特征所在。具体内容如下:优先考虑的是通过尽早地和不断地提交有价值的软件使客户满意;即使到了开发的后期,也欢迎改变需求;敏捷过程利用变化来为客户创造竞争优势;经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好;围绕被激励起来的个体来构建项目;给他们提供所需的环境和支持,并且信任他们能够完成工作;在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈;工作的软件是首要的进度度量标准;敏捷过程提倡可持续的开发速度;责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度;不断地关注优秀的技能和好的设计会增强敏捷能力;简单是最根本的;最好的构架、需求和设计出自组织团队;每隔一定时间,团队会在如何才能更有效地工作方面进行反省,对自己的行为进行调整。敏捷可以看作是对变化和不确定全面反应,有效、灵活、轻型的方法。敏捷过程强调在预测的基础上的变化。设计和构建的计划中包括了对于需求、设计变更的管理,并通过有效的沟通把风险降低。敏捷过程是在保证软件开发成功的前提下,尽量减少开发过程中的活动和制品的方法。敏捷过程基本符合CMM目标和关键过程域(KPA),满足了CMM第2级和第3级大部分KPA的要求,但基本没有涉及CMM第4级和第5级,敏捷过程结合了具体的开发技术和技能,可操作性好。敏捷过程坚持经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。这种方式可以全方位满足项目范围的变化尤其是客户可能不断变化的需求。客户、开发人员可以进行有意义的、频繁的交互,持续不断地引入反馈。2产品职责的规定项目管理最重要也是最难做的一件工作就是确定项目范围。项目范围(scope)包括产品范围和工作范围,产品范围是一个产品或服务应该包含哪些特征或功能以及这些特征或功能应该是怎样的,工作范围是为了交付所指特征和功能的产品所必须做工作,简单地说就项目做什么,如何做,才能交付该产品。产品范围是对产品要求的度量,工作范围在一定程度上是产生项目计划的基础,项目的产品范围和工作范围应该高度一致,以保证项目产品最终能交付满足特定要求的产品。项目范围管理(projectscopemanagement)是指对项目包括什么与不包括什么的定义与控制的过程,这个过程用于确保项目团队和利益相关者对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。范围、时间、成本是制约一个项目的“三约束条件”,三个条件互相影响,互相制约,而且往往因为范围影响了时间和成本。管理这三项约束,就要在一个项目的范围、时间和成本三者之间进行权衡。由于项目的不确定性和资源使用的竞争性,很少有项目能够最终完全按照最初预定的范围、时间和成本目标完成。随着时间的推进,项目发起人、项目团队成员或其他利益相关者对项目会产生不同的看法,引起项目范围发生变化,从图1不难看出,它会引起时间和成本随之发生变化。项目经理和项目小组必须意识到范围变更本身并没有什么不对,事实上很多时侯这会让系统更健壮、更实用。如果变更失控,后果也非常严重,甚至导致整个项目失败。根据数据统计,最可能引起信息系统集成项目失败的前三个因素分别是:缺乏用户参与、不完整的要求和说明、易变的要求和说明,这几个因素都直接或间接与范围变更管理有关。3解决方案的设计项目在设计时要充分考虑不确定因素,才能适应变化。特别是数据结构要以项目灵活性为主,其次才是考虑项目性能的提高。为适应需求的变化,必须采取不同的设计态度。敏捷建模方法的核心原则是简单、递增的变化、拥抱变化、它对如何应对需求的变化很有好处。采用敏捷建模从事开发工作时,最简单的解决方案就是最好的解决方案,尽可能地保持模型的简单。对无法在项目一开始就固化的需求进行演进型的设计。开始不必要对这个系统进行过分的建模,只要基于现有的需求进行建模,随着项目的进行,项目环境和需求发生变化时,再来完善和重构这个系统。递增的变化是指不用在模型中包容所有的细节,只要开发一个小的模型或是概要模型,打下一个基础,然后慢慢地改进模型。敏捷过程项目范围管理模型由调整界定产品范围、调整界定工作范围、设计持续集成、交付产品、通过验证所交付的产品,完善需求,调整产品范围进入下一次迭代,经过多次迭代直到交付符合真正需求的产品。其核心是迭代式开发,寻求快速的反馈,用户经历过一次或几次的迭代之后,对软件开发和业务需求如何实现已经有了形象的认识,用户提出的需求基本上可以代表他们的真实需求。这时,就可以将需求进行冻结。后面如果还有修改,将是细节的调整,不会对软件的架构产生重大的影响。(1)项目范围:项目单位申请第一次根据用户最基本、最关键、最直接的需求界定产品范围,确定小团队,编写简单项目范围说明书,确定申请产品范围变更及更新变更的程序。进入第二次循环后,根据已完善的需求,按照变更程序调整产品范围。(2)申请工作的文明化第一次根据基本产品范围,编写范围管理计划,制定工作分解结构WBS,确定范围基准,确定申请工作范围变更及更新变更的程序,小团队分工。进入第二次循环后,根据调整后的产品范围,按照变更程序调整工作范围,保证工作范围与产品范围保持高度一致。(3)设计团队合作组织协调项目经理创造良好工作环境,鼓励团队成员创新,关注优秀技能和好的设计,定期组织召开有开发团队与真实用户参加的例会,加强团队成员及团队成员与用户之间的互动和沟通,软件项目采用隔日集成。记录简单文档。(4)项目实施过程将集成的产品交付用户,真实用户根据项目范围说明书对已完成的项目范围进行验证核实,分析比较,理解完善需求,进入下一轮迭代,如果已经满足真实用户要求则冻结产品范围,完善文档资料,交付最终产品。4系统需求的制订某软件公司受湖南×××学院的委托开发财务预算管理系统,湖南×××学院财务处作为直接用户提出了简单的需求,包括编制预算,财务报帐,实时查询预算余额等,软件公司项目经理详细地了解报帐业务流程后,绘制出用户界面原型向用户演示和说明方案,使用户理解技术实现的思路。(1)财务预算管理系统项目单位项目干系人包括:开发小团队、财务处用户,其中开发小团队由5人组成,财务处用户由处长1人、副处长1人、普通员工9人组成,其中副处长为项目发起人,提出需求,承担与开发团队沟通及项目测试等工作。项目经理了解用户的基本需求后,多次召开有财务处副处长和小团队成员参加的例会,初步确定财务预算管理系统产品范围:预算编制、预算管理、预算执行、数据管理、查询、系统管理等,编写项目范围说明书,确定项目变更程序,需得到项目经理和财务处副处长共同认可。根据系统业务需求可以确定出用例类图,如图3所示。(2)设计及测试团队根据产品范围,项目团队编写范围管理计划,按项目模块制定工作分解结构WBS,建立项目责任矩阵。在工作范围发生变化时,项目经理与团队成员共同协商确定工作范围变更,调整工作分解结构及责任矩阵。确定系统采用VB.NET+SQLServer2000实现,小团队分工:项目经理1人(兼系统分析),负责与客户沟通、业务建模、需求分析和系统分析工作;设计工程师2人负责系统设计、代码编写等工作;测试工程师1人,负责单元测试、集成测试、系统测试等工作;文档人员1人,负责编写项目范围说明书、用户手册、帮助文档等工作。项目开发时间初步确定45天。(3)该项目是连续的项目实施总结项目例会是为了加强对于项目进度的有效监控,对重要问题及时做出决策,对项目的成果和问题及时通报。每隔一天上午小团队和财务处副处长召开例行会,讨论项目实施情况,解决各种问题。通过项目例会制度,用户与开发团队之间加强了沟通和交流,用户不断对项目范围及已经取得的成果进行确认,避免了在项目实施后期范围变更的巨大风险。对软件项目的影响软件开发文档(项目章程、项目范围说明书、项目范围管理计划等)对软件项目来说是一个很大的工作量。按照敏捷方法的原则,在需求冻结之前,不过分地把精力投入到文档的制作上,而是将有关的信息记录和保留下来,在需求基本冻结之后,再创建和对文档进行格式化。能为企业需求,满足情绪财务副处长提出的各种要求均需要认真听取、分析以后给出答复,满足其合理需求。团队成员彼此平等,遇到问题共享商量,营造良好开发环境,鼓励创新,关注优秀技能和好的设计,经常开展各种活动以提升开发效率。其他财务状况首先进行数据库概念设计,绘出ER图,接着进行数据库结构设计,将ER图转换成关系表,共25张。建立主键外键约束,如:depart-yearly-budget-detail(部门年度经费预算明细表),其字段有部门编号(外键来自depart),明细项目编号(外键来自budget-detail),测算依据,经费限额,核定金额;depart-input-data(部门经费录入表),其字段有序号,部门编号(外键来自depart),明细项目编号(外键来自budget-detail),金额,报帐人,日期,报帐摘要。为了查询方便、操作灵活设计了28个视图。如专项经费报帐:操作系统的步骤:添加部门,添加总项目,编制预算,财务报帐,只有编制了预算的项目才能报帐,考虑到在财务预算执行过程中,由于各种新情况的出现,比如部门调整,工作增减,预算有可能需要调整,因此在编制预算中可以调整预算。在报帐时报帐摘要不能为空,但可以自动套用。原则上不能修改报帐,因特殊情况需要修改时,在报帐列表中双击某一行可进行修改。报帐表格里增加一个摘要字段,自动记录报帐人及报帐时间,作为日后备查。作为财务系统,安全、准确、完整无疑是非常重要的,本系统主要从以下几个方面进行安全设计:1)由系统管理员分级授权,拥有不同权限的人员只能访问经过许可的资源,用户表进行加密处理,以防止计算机专业人员从数据库客户端直接登录,然后使用SQL语句处理数据。所有对数据的修改都将自动记录时间及用户名,以便日后审核。2)对用户表密码采用DES加密,防止非法入侵。3)系统自动定期进行数据备份,防止因系统崩溃引起的数据丢失。财务部门局域网与Internet物理隔离。(4)实现产业经费和专项经费报帐,增加企业经营规模和设计中心交付第一次集成系统后,财务处组织了测试,结果发现登录无法实现,主要原因是财务处多个系统,这些系统的数据库主要采用的都是SQLServer,在这种情况下,当本系统登录时必须选择需要的服务器。采用以下代码来实现:以上代码只有在SQLServer2000的SP2以上版本中才能正确使用,最好安装SQLServer2005。系统隔日集成,将集成的产品交财务处副处长进行测试,在不断的测试过程中,用户提出实现产业经费和专项经费报帐,与EXCEL数据之间共享、汇总报表、打印等需求,小团队与用户共同讨论,调整产品范围,增加与EXCEL数据导入导出,打印规范报表,实现产业经费和专项经费报帐功能。报请学院相关领导同意,增加开发经费1万元,交付日期往后推迟15天,其范围、时间和成本的变更在合同附加项中注明。小团队调整工作范围。5变更控制的必要性一个项目的范围计划做得再好,也不可能不出现任何改变。因此,变更是必然的,正确地对待范围变更,这样才能适应不断变化的环境的需要。首先