买一款教学管理软件大概需要多少钱?
Rational RequisitePro是一个强大、易用、集成的需求管理产品。
而通过与Rational系列软件产品的广泛集成,大大扩展了RequisitePro及其他产品的功能,再一个日事清也是一款强大易用的软件,给软件工程生命周期内的各个阶段都提供了强大、方便的信息查询、跟踪、管理功能。
从而能够促进更好的团队沟通、帮助管理变更和评估变更的影响,帮助验证所有的规划需求被交付物所满足、降低项目风险。
软件项目需求管理可以采取什么策略呢?
需求管理需要遵守以下策略: 1、需求一定要与投入有必然的联系。
需求一定要与投入有必然的联系,否则如果需求变更的成本由开发方来承担,则项目需求的变更就成为必然了。
人们常说世上没有免费的午餐,同样也不应该有免费的需求变更。
但是,接受需求变更目前却是软件开发商不得不咽下的苦果。
所以,在项目的开始无论是开发方还是出资方都要明确这一条:需求变,软件开发的投入也要变。
2、需求的变更要经过出资者的认可。
需求的变更引起投入的变化,所以要通过出资者的认可,这样才会对需求的变更有成本的概念,能够慎重地对待需求的变更。
笔者曾经经历过一个项目,为了避免项目的风险,我们请了用户代表全程参与了开发过程,结果此用户代表在开发过程提出了大量“小的需求变更,当开发人员按此需求变更修改了软件时,在项目进入现场实施阶段时,却有大量的这些变更需要改回去,问题就是出在我们的项目组成员视该用户代表的需求为圣旨,却忽略了需求是否经过了客户方真正有决策权的人员的认可。
3、小的需求变更也要经过正规的需求管理流程。
小的需求变更也要经过正规的需求管理流程,否则会积少成多。
在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低了开发效率,浪费了时间。
正式由于这种观念才使需求的渐变不可控,最终导致项目的失败。
4、精确的需求与范围定义并不会阻止需求的变更。
并非对需求定义的越细,越能避免需求的渐变,这是2个层面的问题。
太细的需求定义对需求渐变没有任何效果。
因为需求的变化是永恒的,并非由于需求写细了,它就不会变化了。
注意沟通的技巧。
考试大收集 实际情况是用户、开发者都认识了到了上面的几点问题,但是由于需求的变更可能来自客户方、也可能来自开发方,作为客户他们可能不愿意为需求的变更付出更多的投资,开发方有可能是主动的变更了需求,他们的目的可能是使软件做的更精致,于是作为需求管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。
有什么好的需求管理工具
需求是研发团队工作的起点,很多研发团队的开发过程混乱的源头都在于需求管理没有做好。
这里是本人收集整理的几个需求管理系统,希望对大家有点帮助。
Rational RequisiteProRational RequisitePro是一个强大、易用、集成的需求管理产品。
而通过与Rational系列软件产品的广泛集成,大大扩展了RequisitePro及其他产品的功能,给软件工程生命周期内的各个阶段都提供了强大、方便的信息查询、跟踪、管理功能。
从而能够促进更好的团队沟通、帮助管理变更和评估变更的影响,帮助验证所有的规划需求被交付物所满足、降低项目风险。
网址:http://www-01.ibm.com/software/awdtools/reqpro/IBM Rational DOORSIBM Rational DOORS前身是大名鼎鼎的Telelogic DOORS,被IBM收购后更名为IBM Rational DOORS。
DOORS是最老牌的企业需求管理套件,通过使用DOORS/ERS,可以帮助企业更有效地进行沟通并加强协作与验证,从而降低失败的风险。
通过对整个组织实施多种需求管理的方法,可以使项目的管理更加透明。
它可以使企业跨越地域与组织的边界来按国际化的方式运行。
网址:http://www-01.ibm.com/software/awdtools/doors/青铜器RDM青铜器RDM是IPD+CMMI+Scrum一体化研发管理解决方案,针对需求管理,涵盖需求的全生命周期管理,从市场客户需求收集(创意管理)、产品路线图(Roadmap)定义、产品特性需求、产品设计需求与规格、项目开发Build划分(迭代划分)、测试用例库、测试计划、测试执行、缺陷跟踪、全方位的需求跟踪矩阵RTM;同时实现Scrum开发模式,基于项目需求直接生成项目任务,实现基于需求和缺陷的迭代开发模式;全面实现了IPD、CMMI、Scrum业界主流研发管理框架的需求管理要求。
网址:http://www.cnrdm.com/index.php/zh_cn/Product/18.html比较内容Telelogic DoorsIBM Rational RequisitePro青铜器RDM结论项目级别的比较(1)Doors 将所有的与需求相关的数据均存放在服务器上的 doors 数据库(不是商业数据库)中。
(2)一个 DOORS Database 能够同时支持许多个不同的项目开发,从而使得新的项目能够复用和共享过去的文件和信息。
不同项目(文件)之间的追踪关系可以跨项目建立。
(1)ReqPro 将需求的数据存放在数据库中,而把与需求相关的上下文信息存放在 Word 文档中。
(2)一个 Database 只能支持一个项目的开发 , 无法支持对过去文件和信息的复用和共享。
不同项目之间无法建立联系。
(1)RDM所有项目的需求统一保存在一个Database,该数据库可以是Oracle、Sql、Mysql任何商用数据库(2)不同项目之间的需求可以相互关联、共享;同时支持产品标准化需求库,从而支持平台化产品开发模式,可以基于产品标准需求库构建项目,实现具体客户的个性化。
RDM、Doors 占优(1) Doors 中的项目显然是从企业的级别考虑,任何一个用户,只要有权限,就可以访问企业中的任何一个项目的需求数据。
(2)RDM需求集中保存,便于统一维护,跨项目共享也更方便,同时产品通用需求库概念,支持平台化开发模式,兼顾平台化和项目个性化要求。
多人同时访问(1)一个时刻,只能有一个人修改一个 module (类似于 requisitepro 中的一个 word 文档),其他人只读方式打开。
DOORS 有访问方式:独占、共享和只读。
当某人独占打开某个 module 时,其他人只能只读访问。
但 DOORS 提供共享方式,特别是可以允许不同的人同时修改同一文档的不同部分,比如 A 用户负责修改第一章, B 用户负责修改第二章。
这是 tool-setup for sharing 的功能。
(1)一个时刻,只能有一个人修改一个 word 文档。
其他人只读方式打开。
(1)RDM支持需求检入/检出,版本化操作;同时不同版本之间的差异化能自动对比分析(2)RDM的需求可以灵活根据需求类型、需求状态划分权限,支持多人并发对需求进行编辑、维护。
RDM占优,ReqPro、Doors两者相同。
需求创建和编辑在 doors 中创建和编辑(与 word 的使用类似。
)创建方法简单直观。
在 word 文档中创建和编辑,创建方法和理解上略有困难。
在 requistitepro 中创建的需求放在数据库中,不能被文档使用RDM支持在线创建编辑需求 和 基于Excel编辑需求,然后集中导入RDM 两种模式。
在线编辑支持富文本、直接插入图片等个性化手段各有优劣, ReqPro、RDM略占优(1) doors 中创建和使用简单,不需要 word 。
但是,它毕竟没有 word 的编辑功能强大。
(2)RDM支持富文本、直接插入图片方式,能使需求展现的更直观需求修改历程的纪录和管理(1)可以针对 module (类似于 requisitepro 中的一个 word 文档)打基线。
可以比较基线之间的不同点。
基线可以作为创建新的 moduel 的模版。
(2)需求项的修改有历史记录,并且可以回滚到任何一个历史点的内容。
(3)可以和主流的配置管理工具集成使用;(1)需求项的修改有历史记录。
(2)可以和 clearcase 工具集成使用 , 完成基线功能,但是只是形成版本,没有比较功能。
(1)RDM支持需求检入/检出,版本化记录,同时一个页面展现版本间差异(2)RDM本身提供变更管理流程...
软件项目管理的需求如何管理
需求管理包括需求调研,需求开发,需求确认,需求变更管理需求调研是要到市场或者最终用户处进行需求调研的,获取原始的用户需求,形成客户需求说明书。
需求开发是根据原始的用户需求,进行开发整理,形成需求规格说明书;需求确认是项目干系人,包括专家、用户一起进行进行需求评审,确认需求,这时一般会将需求规格说明书转化成需求矩阵(需求表格,进行整个生命周期管理)需求变更管理是需求管理的重要组成部分,需要有变更申请与批准,未被批准的需求变更不允许程序员私自修改。
最近开始忙起来,感觉特别需要一个日程管理软件,有好用推荐的么?...
前言:在软件项目的开发过程中,需求变更贯穿了软件项目的整个生命周期,从软件的项目立项,研发,维护,用户的经验在增加,对使用软件的感受有变化,以及整个行业的新动态,都为软件带来不断完善功能 ,优化性能,提高用户友好性的要求。
在软件项目管理过程中,项目经理经常面对用户的需求变更。
如果不能有效处理这些需求变更,项目计划会一再调整,软件交付日期一再拖延,项目研发人员的士气将越来越低落,将直接导致项目成本增加、质量下降及项目交付日期推后。
这决定了项目组必须拥有需求管理策略。
需求管理复杂性分析 软件需求是整个软件开发项目的最关键的一个输入,和传统的生产企业相比较,软件的需求具有模糊性、不确定性、变化性和主观性的特点,他不像生产汽车、电脑等硬件的需求,是有形的、客观的、可描述的、可检测的,软件需求是软件项目最难把握的问题,他的复杂性体现在以下方面: 1、需求的描述问题。
缺少正式的完整的需求文档浪费了大量的人力物力,但是有了需求文档又出现了新的问题。
在用户方进行的需求评审会完全是走形式,因为用户根本不去听他读那上百页的需求文档。
不同层次的客户(用户)关心的问题是不一样的,想要每个客户都成为需求专家是不现实的。
2、需求的完备程度问题。
需求如何做到没有遗漏?如何准确划定系统的范围?这确实是一个两难问题,稍微大一点的系统要想穷举需求几乎是不可能的,每次开需求评审会时,总会冒出新的需求,以至于系统没有一个准确的范围界定。
即使是这样,系统还是要开发,没办法,系统的范围还要硬性的划定一个,从而建立一个基线。
3、需求开发的工期问题。
在需求上花费了大量的时间,客户、软件公司是否能够忍受?为了确保需求的正确性,完备性,项目经理往往坚持要在需求阶段花费大量的时间,但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已!他们往往会逼迫项目组尽快往前推进,而项目组的成员往往也会为系统复杂的善变的需求折腾的筋疲力尽,他们也希望尽快结束此阶段。
4、需求的细致程度问题。
需求到底描述到多细,才算可以结束了?仁者见仁,智者见智,并没有定论,如果时间允许,要想细总可以细下去的。
但是,需求的周期越长,可能的变化越多,对设计的限制越严格,对需求的共性提取要求越高,所以只要大家(客户、用户、需求分析人员、设计人员、测试人员)认为描述清楚了,就可以进入设计阶段了。
5、需求的变化问题。
在软件开发过程中如果只有一条真理的话,那一定是:需求的变化是永恒的,需求不可能是完备的。
软件开发的过程实际上是同变化做斗争的过程,需求的变更不一定是坏事,也有可能是好事,是商业机会,对市场敏感的人可以从需求的变化中发现市场机会。
需求变化的原因很多,如: 一开始没有识别全,需要增加需求; 业务发生了变化,需求必须变化; 需求错误; 需求不清楚。
需求的变化问题是每个开发人员、每个项目经理都遇到的问题,也是最头痛的问题,一旦发生了需求变化,你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等,需求的变化好比是万恶之源,为项目的正常的进展带来不尽的麻烦,怎么办?管理它!使需求在受控的状态下发生变化,而不是随意变化,需求管理就是要按照标准的流程来控制需求的变化。
难题随之而来,需求中的变化一般不是突发的革命性的变化,最常见的是项目需求的渐变(Project Scope Creep)问题,这种渐变很可能是客户与开发方都没有意识到的,当达到一定层度时,双方才蓦然回首,发现已经物是人非,换了一番天地。
需求管理策略 需求管理需要遵守以下策略: 1、需求一定要与投入有必然的联系。
需求一定要与投入有必然的联系,否则如果需求变更的成本由开发方来承担,则项目需求的变更就成为必然了。
人们常说世上没有免费的午餐,同样也不应该有免费的需求变更。
但是,接受需求变更目前却是软件开发商不得不咽下的苦果。
所以,在项目的开始无论是开发方还是出资方都要明确这一条:需求变,软件开发的投入也要变。
2、需求的变更要经过出资者的认可。
需求的变更引起投入的变化,所以要通过出资者的认可,这样才会对需求的变更有成本的概念,能够慎重地对待需求的变更。
笔者曾经经历过一个项目,为了避免项目的风险,我们请了用户代表全程参与了开发过程,结果此用户代表在开发过程提出了大量“小的需求变更,当开发人员按此需求变更修改了软件时,在项目进入现场实施阶段时,却有大量的这些变更需要改回去,问题就是出在我们的项目组成员视该用户代表的需求为圣旨,却忽略了需求是否经过了客户方真正有决策权的人员的认可。
3、小的需求变更也要经过正规的需求管理流程。
小的需求变更也要经过正规的需求管理流程,否则会积少成多。
在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低了开发效率,浪费了时间。
正式由于这种观念才使需求的渐变不可控,最终导致项目的失败。
4、精确的需求与范围定义并不会阻止需求的...