在软件工程中什么是需求分析?
一。
确定对系统的综合要求1. 功能需求这方面的需求指定系统必须提供的服务。
通过需求分析应该划分出系统必须完成的所有功能。
2. 性能需求性能需求指定系统必须满足的定时约束或容量约束,通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
3. 可靠性和可用性需求可靠性需求定量地指定系统的可靠性。
可用性与可靠性密切相关,它量化了用户可以使用系统的程度。
4. 出错处理需求这类需求说明系统对环境错误应该怎样响应。
例如,如果它接收到从另一个系统发来的违反协议格式的消息,应该做什么?注意,上述这类错误并不是由该应用系统本身造成的。
5. 接口需求接口需求描述应用系统与它的环境通信的格式。
常见的接口需求有:用户接口需求;硬件接口需求;软件接口需求;通信接口需求。
6. 约束设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。
在需求分析阶段提出这类需求,并不是要取代设计(或实现)过程,只是说明用户或环境强加给项目的限制条件。
常见的约束有:精度;工具和语言约束;设计约束;应该使用的标准;应该使用的硬件平台。
7. 逆向需求逆向需求说明软件系统不应该做什么。
理论上有无限多个逆向需求,我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。
8. 将来可能提出的要求应该明确地列出那些虽然不属于当前系统开发范畴,但是据分析将来很可能会提出来的要求。
注意:举例让学生理解:这样做的目的是,在设计过程中对系统将来可能的扩充和修改预做准备,以便一旦确实需要时能比较容易地进行这种扩充和修改。
二 。
分析系统的数据要求任何一个软件系统本质上都是信息处理系统,系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌,对软件设计有深远影响,因此,必须分析系统的数据要求,这是软件需求分析的一个重要任务。
分析系统的数据要求通常采用建立数据模型的方法(举例)。
三。
导出系统的逻辑模型综合上述两项分析的结果可以导出系统的详细的逻辑模型,通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
四。
修正系统开发计划根据在分析过程中获得的对系统的更深入更具体的了解,可以比较准确地估计系统的成本和进度,修正以前制定的开发计划。
软件需求分析阶段 产物有哪些
回答:海底行 神 10月22日 10:37 尽量把客户所持的假设解释清楚,特别是那些发生冲突的部分。
从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。
Gause 和Weinberg(1989)提出使用“上下文无关问题”—这是一个高层次的问题,它可以获取业务问题和可能的解决方案的全部信息。
客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗?”这些回答可以更直接地认识问题,而这是封闭(close-end)问题所不能做到的。
需求获取利用了所有可用的信息来源,这些信息描述了问题域或在软件解决方案中合理的特性。
一个研究表明:比起不成功的项目,一个成功的项目在开发者和客户之间采用了更多的交流方式(Kiel and Carmel 1995)。
与单个客户或潜在的用户组一起座谈,对于业务软件包或信息管理系统(MIS)的应用来说是一种传统的需求来源。
直接聘请用户进行获取需求的过程是为项目获得支持和买入(buy-in)的一种方式。
尽量理解用户用于表述他们需求的思维过程。
充分研究用户执行任务时作出决策的过程,并提取出潜在的逻辑关系。
流程图和决策树是描述这些逻辑决策途径的好方法。
在需求获取的过程中,你可能会发现对项目范围的定义存在误差,不是太大就是太小。
如果范围太大,你将要收集比真正需要更多的需求,以传递足够的业务和客户的值,此时获取过程将会拖延。
如果项目范围太小,那么客户将会提出很重要的但又在当前产品范围之外的需求。
当前的范围太小,以致不能提供一个令人满意的产品。
需求的获取将导致修改项目的范围和任务,但作出这样具有深远影响的改变,一定要小心谨慎。
正如经常所说的,需求主要是关于系统做什么,而解决方案如何实现是属于设计的范围。
这样说虽然很简洁,但似乎过于简单化。
需求的获取应该把重点放在“做什么”上,但在分析和设计之间还是存在一定的距离。
你可以使用假设“怎么做”来分类并改善你对用户需求的理解。
在需求的获取过程中,分析模型、屏幕图形和原型可以使概念表达得更加清楚,然后提供一个寻找错误和遗漏的办法。
把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议,而不应该看成是对设计者选择的一种限制。
需求获取讨论会中如果参与者过多,就会减慢进度。
人数大致控制在5到7人是最好的。
这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。
相反地,从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音,也会造成问题。
这将导致忽视特定用户类的重要的需求,或者其需求不能代表绝大多数用户的需要。
最好的权衡在于选择一些授权为他们的用户类发言的产品代表者,他们也被同组用户类的其它代表所支持。
没有一个简单、清楚的信号暗示你什么时候已完成需求获取。
当客户和开发者与他们的同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时,他们都将对潜在产品产生新的构思。
你不可能全面收集需求,但是下列的提示将会暗示你在需求获取的过程中的返回点。
1. 如果用户不能想出更多的使用实例,也许你就完成了收集需求的工作。
用户总是按其重要性的顺序来确定使用实例的。
2. 如果用户提出新的使用实例,但你可以从其它使用实例的相关功能需求中获得这些新的使用实例,这时也许你就完成了收集需求的工作。
这些新的使用实例可能是你已获取的其它使用实例的可选过程。
3. 如果用户开始重复原先讨论过的问题,此时,也许你就完成了收集需求的工作。
4. 如果所提出的新需求比你已确定的需求的优先级都低时,也许你就完成了收集需求的工作。
5. 如果用户提出对将来产品的要求,而不是现在我们讨论的特定产品,也许你就完成了收集需求的工作。
以上知识大致上讨论需求分析应该如何做,实际上对于需求分析的方法有很多很多,已经形成了一定的理论,当然这种理论比较偏向与方法学,而方法学的应用主要还是要靠个人。
所以,大家在实际应用的时候,不妨结合自己的实际,有选择性的采用一些方法,那你就是成功的。
用例在需求分析中的使用 多年来,分析者总是利用情节或经历来描述用户和软件系统的交互方式,从而获取需求(McGraw and Harbison 1997)。
Ivar Jacobson(1992)把这种看法系统地阐述成用例(用例)的方法进行需求获取和建模。
虽然用例来源于面向对象的开发环境,但是它也能应用在具有许多开发方法的项目中,因为用户并不关心你是怎样开发你的软件。
而最重要的,用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。
注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。
用例的重要功能是用画用例图的功能来鉴别和划分系统功能。
它把系统分成角色(actor)和用例(用例)。
角色(actor)表示系统用户能扮演的角色(role)。
这些用户可能是人,可能是其他的计算机一些硬件或者甚至是其它软件系统,唯一的标准是它们必须要在被划分进用例的系统部分以外。
它们必须能刺激系统部分并接收返回。
用例描述了当角色给...
怎么做需求分析(下)
Ivar Jacobson(1992)把这种看法系统地阐述成用例(用例)的方法进行需求获取和建模。
虽然用例来源于面向对象的开发环境,但是它也能应用在具有许多开发方法的项目中,因为用户并不关心你是怎样开发你的软件。
而最重要的,用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。
注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。
用例的重要功能是用画用例图的功能来鉴别和划分系统功能。
它把系统分成角色(actor)和用例(用例)。
角色(actor)表示系统用户能扮演的角色(role)。
这些用户可能是人,可能是其他的计算机一些硬件或者甚至是其它软件系统,唯一的标准是它们必须要在被划分进用例的系统部分以外。
它们必须能刺激系统部分并接收返回。
用例描述了当角色给系统特定的刺激时系统的活动。
这些活动被文本描述。
它描述了触发用例的刺激的本质,输入和输出到其他活动者,和转换输入到输出的活动。
用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施。
这样说可能会非常复杂,其实一个用例描述了系统和一个角色(actor)的交互顺序。
用例被定义成系统执行的一系列动作,动作执行的结果能被指定角色察觉到。
用例可以: 用例捕获某些用户可见的需求,实现一个具体的用户目标。
用例由角色激活,并提供确切的值给角色。
用例可大可小,但它必须是对一个具体的用户目标实现的完整描述。
在UML中,用例表示为一个椭圆。
角色是指用户在系统中所扮演的角色。
其图形化的表示是一个小人。
在某些组织中很可能有许多角色实例(例如有很多个销售员),但就该系统而言,他们均起着同一种作用,扮演着相同的角色,所以用一个角色表示。
一个用户也可以扮演多种角色。
例如,一个高级营销人员既可以是贸易经理,也可以是普通的营销人员;一个营销人员也可以是售货员。
在处理角色时,应考虑其作用,而不是人或工作名称,这一点是很重要的。
我们使用不带箭头的线段将角色与用例连接到一起,表示两者之间交换信息,称之为通信联系。
角色触发用例,并与用例进行信息交换。
单个角色可与多个用例联系;反过来,一个用例可与多个角色联系。
对同一个用例而言,不同角色有着不同的作用:他们可以从用例中取值,也可以参与到用例中。
需要注意的是角色在用例图中是用类似人的图形来表示,尽管执行的,但角色未必是人。
例如,角色也可以是一个外界系统,该外界系统可能需要从当前系统中获取信息,与当前系统有进行交互。
一个用例可能包括完成某项任务的许多逻辑相关任务和交互顺序。
因此,一个用例是相关的用法说明的集合,并且一个说明(scenario)是用例的实例。
这种关系就像是类和对象的关系。
在用例中,一个说明被视为事件的普通过程(normal course),也叫作主过程,基本过程,普通流,或“满意之路” (happy path)。
在描述普通过程时列出执行者和系统之间相互交互或对话的顺序。
当这种交互结束时,执行者也达到了预期的目的。
在用例中的其它说明可以描述为可选过程(alternative coruse)。
可选过程也可促进成功地完成任务,但它们代表了任务的细节或用于完成任务的途径的变化部分。
在交互序列中,普通过程可以在一些决策点上分解成可选过程,然后再重新汇成一个普通过程。
角色类和角色实例 软件产品最终是给一些用户来使用的,而用户之间的差异是非常大的。
造成差异的原因包括了对计算机的认知程度的不同,使用习惯的不同,在软件目标组织中所处的地位不同,地理位置不同,业务熟练程度不同。
不同的用户都有自己一系列的功能需求和非功能需求。
对电脑熟练程度不同的人可能就会有不同的要求,熟练程度低的用户可能希望有一个友好的界面,熟练程度高的用户可能更希望有快捷键或宏的操作以提高工作效率。
考虑到用户的差异性,将用户分类并研究用户类的行为特征是非常有必要的。
所以在做具体的需求之前,先将用户分局行为和特点进行分类,对于研究、收集用户的需求是非常有帮助的。
可以利用一个简单的表格列出一些原始的分类,然后不断的完善这个表格。
确认你的分类之间没有交集。
并充分描述用户分类的行为,目的,要求等。
在企业分析中,比较常见的分类可能包括,供应商,客户,部门等。
就像C++中的类和对象一样,我们把分析出的用户分类称为“角色类”,把实际的用户称为“角色实例”。
在得到用户分类之后,最重要的就是要选出用户代表,用户代表不仅仅是在需求阶段中参与项目,还必须对项目的全过程负责。
用户代表能够代表用户分类的需求。
抓住用户代表的需求就大致把握住了用户类的需求。
当然,需求分析还是需要在用户中做大规模的调查的,只是要把重点放在用户代表上。
确保和用户直接进行沟通!大家有没有玩过传话的游戏,可能看过。
一群人排成一列,一句话从排头挨个向后传,到最后,那句话已经是面目全非了。
所以,一定要保证项目组能够直接和用户接触。
对于和用户直接沟通这一点,一般的针对特定企业的应用系统当然是不成问题,可是如果是开...
软件需求分析,架构设计和软件售前这两个工作的区别?和发展前途?...
三个职业都很牛逼。
基本都是可以做一辈子的。
需求分析是将需求转化为软件的业务,目前针对比较大的企业,一般公司由软件开发人员担任,逻辑和分析能力要强。
架构师:一般一个公司也就一个,小公司一般没有架构师这个职称。
收入高,技术要求也高。
主要是会不会忽悠。
售前其实就是销售,牛逼一点的比架构师收入好。
如何做需求分析
一、 我们应当如何做需求分析需求分析不是一蹴而就的,它应当贯穿整个开发周期,不断的分析确认的过程。
这就是敏捷开发倡导的需求反馈。
敏捷开发认为,需求分析阶段不可能解决所有的需求问题,因此在设计、开发、测试,直到最终交付客户,这整个过程都应当不停地用开发的成果与客户交流,及时获得反馈。
只有这样才能及时纠正需求理解的偏差,保证项目的成功。
二、我们应当怎样做需求调研1.初识。
我们对客户提出的需求进行深入理解以后,运用我们专业知识,提出比客户的原始需求更加合理、可操作的解决方案,让客户感觉你说的正是他们想要的。
如果能够这样,客户不仅能够欣然接收你提出的方案,而且会感觉你非常专业,你在客户心目中的形象也会无形中提高,使你有更多的机会提出有利于开发的可行方案,降低开发的风险。
这毫无疑问会形成一个良性循环,但要做到这一点并不容易,毫无疑问,在与客户接触初期的表现起到了极其关键的作用。
(1)高层领导关心的是宏观的目标,因此软件研发目标、宏观统计报表、决策支持功能,我们应该怎样做需求分析,应当与高层领导谈。
(2)中层领导关心的是具体的效益,即软件给各个部门信息化管理方面带来的效益,因此,中层领导是各项业务流程、功能模块的需求决策者。
他们关心功能的定义、业务流转的衔接、查询报表的设计,但不太关心一些具体的操作,以及一些具体业务流程的细节。
(3)基层人员是每一项业务流程的操作者,也是软件今后真正的使用者。
他们是真正了解你所要开发的软件的业务需求的领域专家,是你进行需求调研的重点对象。
但是,基层人员往往受到自身视野的局限,可能只清楚自己工作涉及的十分狭小的一个范围,因此我们需要努力寻找那些业务涉及面广,经验丰富,又有一定大局观的真正的专家。
另外 ,他们就是软件今后真正的使用者,让他们参加,会让他们成为今后软件推行的忠实支持者,对其他操作人员的指导者,益处多多。
而他们关心的则是每项操作的细节。
俗话说:万事开头难。
如果你在项目开始的时候总感觉千头万绪不知如何着手,在这里我给大家的三点建议:1)树立良好的职业威信;2)进行详细角色分析,将与会各方代表对号入座;3)从宏观上制订目标与方案。
随后的工作,就是与各方代码建立联系,逐一拜访他们,将需求调研工作一步一步进行下去。
2.拜访。
需求调研不是一蹴而就的事情,是一件持续数月甚至数年的工作(假如项目还有后期维护) 。
在这漫长的时间里,我们需要依靠客户这个群体的帮助,一步一步掌握真实可靠的业务需求 。
不仅如此,技术这东西总有不如意甚至实现不了的地方,我们需要客户的理解与包容,这都需要有良好的客户关系。
尽管如此,我们也不能总是期望客户中的所有人都能与我们合作,很多项目都不可避免地存在阻碍项目开展的人。
3.研讨会。
(1)由于业务人员自身的局限 ,不可能对所有业务领域的细节全面掌握,往往总是有自己熟悉的部分,也有自己不熟悉的部分。
划分业务组,可以让业务人员分别在自己最熟悉的业务范围内参与讨论,可以有效提高业务讨论的质量;(2)集中式的业务研讨形式和分散式的业务研讨形式;(3)有效抑制个性化差异、分模块组织专项研讨会。
4.业务研讨在需求分析过程中,客户存在的最大问题就是提不出正确的需求,这表现为几种形式:(1)由于对软件不了解,客户提不出需求,不知道软件最终会做成什么样子。
这类客户在需求讨论过程中,往往只能描述目前自己手工管理的方式是怎样的,不知道计算机会怎样管理。
(2)能提出一些业务需求,但当软件做出来摆在自己面前时,需求就变了。
这类客户,他们能熟练使用电脑,对信息化管理是清楚的。
他们提出的业务需求从整体上应当是八九不离十的 。
但是,由于没有实物,在软件中的一些具体操作并没有完全想清楚。
(3)能非常详细地提出业务需求,甚至有时候该怎么做的提出来了。
这类客户,参与过很多软件信息化建设,甚至有些还是软件开发的半专业人士。
但是他们提出的业务需求过于具体 ,甚至怎样实现都说出来了,但这些有时候不是最佳设计方案、可能在技术上难于实现,甚至有些就是过于理想化而不可实现。
解决办法:业务领域分析:客户现有的业务流程是什么样的,都有些什么操作?客户在业务中都有些什么事物,什么专用名词,都是怎样定义的,相互之间的关系是什么?客户在每一项操作中的目的是什么,为什么要这样做,他们制作的手工报表都说明了什么问题?(1)我们做需求分析,眼界不能仅仅停留在软件本身,应当更开阔一些,应当扩展到跟这个业务有关的那些领域知识中。
(2)在客户提出的所有原始需求中那些与业务实现有关的需求都是无效的需求,它们仅仅只能作为我们的一个参考。
(3)还有一些是技术难于实现或者根本就无法实现的需求,我们应当耐心地说服和引导客户,并给他提出一个更加合理的方案。
(4)需求分析不是一种简单的你说我记的收集活动,而是在大量业务分析与技术可行性分析基础上的分析活动。
只有建立在这种分析基础上的软件研发,才能保证需求的正确与变更的可控。
5.迭代...
新系统开发前进行什么分析填空题
需求分析奠定了软件工程和项目管理的基础。
我们在建造软件系统这座大厦的时候,如果需求分析的基础不够坚实和牢固,那么往往会导致软件系统问题百出,甚至被马上丢弃。
在建造软件系统的过程中,如果我们经常习惯地沿用一些不规范的方法,其后果便是产生一条鸿沟──开发者开发的与用户所想得到的软件存在着巨大的“期望差异”。
因此“需求”这个名词的定义不仅仅是从用户角度对系统外部行为的描述,以及从开发人员角度对系统内部特性的描述,其关键的一点是“需求”必须文档化。
需求的类型 软件需求包括三个不同的层次──业务需求、用户需求和功能需求。
除此之外,每个系统还有各种非功能需求。
业务需求(BusinessRequirement)表示组织或客户高层次的目标。
业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。
使用前景和范围(vision and scope)文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求(project charter 或 market requirement)文档。
用户需求(UserRequirement)描述的是用户的目标,或用户要求系统必须能完成的任务。
用例、场景描述和事件响应表都是表达用户需求的有效途径。
也就是说用户需求描述了用户能使用系统来做些什么。
功能需求(Functional Requirement)规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。
功能需求有时也被称作行为需求(behavioral requirement),因为习惯上总是用“应该”对其进行描述:“系统应该发送电子邮件来通知用户已接受其预定”。
功能需求描述是开发人员需要实现什么。
非功能需求(Non-functional Requirement) 定义了软件产品为满足用户业务需求而必须具有的除功能需求以外的特性。
包括系统的完整性(联机帮助、 数据管理、用户管理、软件发布管理、在线升级等)、性能、可靠性、可维护性、可扩充性、对技术和业务的适应性等。
需求分析的任务 1 解决的问题 1) 齐全、准确地找出目标系统全部的功能、性能、限制; 2) 找出全部的输入流、输出流; 3) 找出所有的加工; 4) 产生完整的分层的DFD、数据字典、加工的描述; 5) 补充的意见。
2 综合要求 确定对系统的综合要求,系统功能要求,系统性能要求,运行要求,将来可能提出的要求。
3 任务 图1为需求分析任务图,需求分析阶段要完成的具体明确的最终任务就是形成一份经开发方和用户认可或达成共识的软件需求分析文档(需求规格说明书、修改后的项目开发计划、初步的用户手册、确认测试计划、数据要求说明书)。
这个文档能清晰准确地说明系统将要开发什么,能够规定出详细的技术需求,包括所有面向用户、面向机器和其它软件系统的接口。
可以说需求文档在开发过程中一直起指导作用。
为了更好地完成软件开发第一阶段的需求分析任务,提高质量,需求管理是必不可少的。
需求管理的目的是在客户与开发方之间建立对需求的共同理解,维护需求与其他工作成果的一致性,并控制需求的变更,主要体现在跟踪和控制需求变更管理。
需求管理是开发工作有效进行的保证,是一种很高层次的系统行为,涉及整个开发过程和产品本身。
需求分析的方法 需求分析方法由对软件问题的信息域和功能域的系统分析过程及其表示方法组成,大多数的需求分析方法是由信息驱动的。
信息域具有三种属性: 信息流、信息内容和信息结构。
常用的需求分析方法有:面向数据流的结构化分析方法(SA),面向数据结构的Jackson方法(JSD),面向数据结构的结构化数据系统开发方法(DSSD),面向对象的分析方法(OOA)等。
选择那种方法要根据哪些资源在什么时间对开发人员有效,不能盲目套用。
这里着重阐述面向数据流的结构化分析方法(SA)。
面向数据流的结构化分析方法 面向数据流的结构化分析方法(Structured Analysis,简称SA),是面向数据流进行需求分析的方法,是需求分析使用最多的方法之一。
SA也是一种建模活动,该方法使用简单易读符号,根据软件内部数据传递、变换的关系,自顶向下逐层分解,描绘出满足功能要求的软件模型。
适用于数据处理类型软件的需求分析,这一方法除了简单,容易掌握之外,还能和设计阶段的结构化设计(SD)衔接,从而取得良好的设计结果。
自顶向下逐层分解的分析策略 SA方法的基本手段:“分解”和“抽象”。
这是系统开发技术中控制复杂性的两种手段。
它先将系统“抽象”成一个模型,此模型是有输入和输出并有系统名称的盒子,然后打开这个盒子,对它进行逐层分解,直到能被理解,可以实现为止。
因此分析的策略是自顶向下,逐层加细,由抽象到具体的过程。
如图2。
结构化分析方法使用工具 SA方法利用图形等半形式化的描述方式表达需求,简明易懂,用它们形成需求规格说明书中的主要部分。
描述工具是 1) 数据流图:描述系统由哪几部分组成,各部分之间有什么联系等等。
2) 数据字典:定义了数据流图中每一个图形元素。
3) 描述加工逻辑的结构化语...
需求分析的任务
需求分析的任务是通过详细调查现实世界要处理的对象,充分了解原系统工作概况,明确用户的各种需求然后在此基础上确定新系统的功能。
确定对系统的综合要求,虽然功能需求是对软件系统的一项基本需求,但却并不是唯一的需求,通常对软件系统有下述几方面的综合要求。
1.功能需求2.性能需求3.可靠性和可用性需求4.出错处理需求5.接口需求6.约束7.逆向需求8.将来可能提出的要求 任何一个软件本质上都是信息处理系统,系统必须处理的信息和系统应该产生的信息很大程度上决定了系统的面貌,对软件设计有深远的影响,因此,必须分析系统的数据要求,这是软件分析的一个重要任务。
分析系统的数据要求通常采用建立数据模型的方法。
复杂的数据由许多基本的数据元素组成,数据结构表示数据元素之间的逻辑关系。
利用数据字典可以全面地定义数据,但是数据字典的缺点是不够直观。
为了提高可理解性,常常利用图形化工具辅助描述数据结构。
用的图形工具有层次方框图和Warnier图。
根据在分析过程中获得的对系统的更深入的了解,可以比较准确地估计系统的成本和进度,修正以前定制的开发计划。