如何建立软件产品的愿景

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,2010-8-20,#,RUP,大讲堂（第三讲）,-,如何建立软件产品的愿景,肖勇,1,2,议程,为什么需要愿景,业务愿景,系统愿景,导出愿景的技巧,小节,2,为什么需要建立项目愿景,-,基本认识,愿景：向往的前景，愿景是为整,个软件开发的组织服务，对于软,件项目，愿景通常也是由关键性,客户或公司的重要管理者提出。,软件项目的愿景来源于不止一人,不正确的愿景是大多数项目失败,的根本原因,愿景的重要性：“如果仅允许一,份文档、模型或工件来支撑项,目，我会选择愿景文档。”,Philippe Kruchten,3,业务,愿景,系统,远景,愿景,3,4,为什么需要建立项目愿景,-,一件事可以有不同视角,4,5,为什么需要建立愿景,-,重要性,有一个清晰的愿景是开发一个满足涉众真,正需求的产品的关键。,愿景给更详细的技术需求提供了一个高层,的、有时候是合同式的基础。,5,6,为什么需要建立愿景,-,如何陈述,对的陈述应该能回答以下问题,:,关键术语是什么？（词汇表）,我们尝试解决的问题是什么？（问题陈述）,我们的商业理由是什么？,涉众是谁？用户是谁？他们各自的需求是什么？,产品的特性是什么？,功能性需求是什么？,非功能性需求是什么？,设计约束是什么？,6,7,业务愿景,-,概念,业务愿景是对于组织应实现什么目标的理解。,了解业务愿景的主要目标是如何规划业务愿景并,不断改进它,帮助达成目标的高级业务需求,现有业务流程的问题（如客户难点、高成本、计,划问题等等）,7,8,业务愿景,-,内容,业务愿景捕获项目的高级目标。它传达了有关项目的,基本信息，包括开发系统的业务目的以及具体要开发,什么，同时它还是验证未来所有决策的标尺。,从商业的角度提供必要的信息，以确定该项目是否值,得投资。对于商业软件产品，业务愿景应包含一组关,于项目的假设，以及在这些假设成立的情况下投资收,益率（,ROI,）的数量级。,8,9,业务愿景,-,检查项,_,概述很好地描述了目标组织吗,有可能按照建议对目标组织作出变更和改进吗？,可评估新的目标吗,新的目标现实并且有可能实现吗,处理了风险吗,在项目的框架设置内可作出建议的变更和改进吗,业务愿景明确地指出了希望作出变更的域吗,业务愿景明确地描述了有必要作出变更的原因吗,9,10,系统愿景,-,概念,获得需要解决的问题的共识。,确定系统的项目干系人。,定义系统的边界。,描述系统的主要特性,10,11,系统愿景,-,主要内容,确定目标系统的市场背景,列明系统将要解决的重大问题,系统的概括定义,以特性（,Feature,）的方式定义目标系统的高层需求,特性表达了目标系统为了实现用户利益而必须具备的能力,（,Capability,）,特性是一种对外的服务，通常要求用户提供一系列输入以得到响应,的结果,市场背景,软件特性,11,12,系统愿景,-,主要内容（续）,明确地定义目标系统,勾画目标系统的上下文环境与边界,列明目标系统的主要（能力）特性及其提供给客户的利益,明示目标系统当前所做的假定和其依赖的条件，它们将可能是未来,引起需求变更的重要因素,软件上下文环境,利益相关者,标识目标系统的最终用户与其他涉众，以确定需求收集的来源,分析用户与涉众的基本特点，以帮助获取与辨别系统的需求,列明用户与涉众针对目标系统的各类需要（,needs,），它们决定了,最终系统需求,12,13,系统愿景,-,主要内容（续）,设计约束限定了目标系统设计乃至实现方案的选择范围,接口需求,质量范围概略描绘了目标系统的重要质量需求,适用标准、硬件需求及环境需求等,其他,13,14,系统愿景,-,建立的步骤,获得需要解决的问题的共识,确定项目干系人,定义系统边界,确定要施加在系统上的约束,形成问题陈述,定义系统特性,评估结果,14,15,系统愿景,-,建立步骤,1,：获得需要解决的问题的共识,要获得问题的定义的共识,查找根本原因（或者叫“问题后面的问题”）。真正,的问题往往隐藏在表面问题的后面,不要接受问题的第一次陈述。继续问“为什么？”了,解问题的本质,15,16,系统愿景,-,建立步骤,2,：确定项目干系人,系统的用户是谁？,谁负责出资购买系统？,还有谁受系统生成的输出的影响？,当系统交付和部署时谁将评价系统？,系统有没有其他内部或外部用户的需求需要满足？,维护新系统的人是谁？,还有其他人吗？,好，还有其他人吗？,16,17,系统愿景,-,建立步骤,3,：定义系统边界,系统边界定义解决方案以及围绕解决方案的真,实世界之间的边界。,在许多情况下，系统的边界是很明显的。,边界不明显的情况我们需要通过反复讨论确定,下来。,17,18,系统愿景,-,建立步骤,4,：确定要施加在系统上的约束,政治：有没有内部或外部政治问题影响可能的解决方案？部门之间呢？,经济：适用的财务或预算约束有哪些？销售的货物成本或产品定价方面有,没有要考虑的问题？有没有什么许可问题？,环境：有没有环境或规章制度方面的约束？法律方面的呢？我们是否受其,他标准的约束？,技术：我们在技术的选择上受约束吗？我们只能受限于在现有的平台或技,术条件下工作吗？我们在新技术的使用上受到阻碍吗？,可行性：规定了时间进度吗？我们受限于现有的资源吗？我们可以使用外,面的劳动力吗？我们可以扩展资源吗？临时资源？ 永久资源？,系统：解决方案要建立在我们现有的系统上吗？我们必须维护与现有解决,方案的兼容性吗？必须支持哪些操作系统和环境？,18,19,系统愿景,-,建立步骤,5,：形成问题陈述,与所有小组成员一起研究框架图，并为识别的每个问题填写以下,模板：,问题,影响,。,其影响是,。,一个成功的解决方案将,。,系统愿景,-,建立步骤,6,：定义系统特性,基于问题陈述中列出的好处，制定您希望系统拥有的特性,的列表。简单地描述这些特性，并将属性赋予它们，以帮,助定义它们在项目中的一般状态和优先级。,19,20,系统愿景,-,建立步骤,7,：评估结果,您已经完全找出“问题背后的问题”是什么了吗,问题的陈述表达得正确吗,项目干系人列表完整而正确吗,每个人都同意系统边界的定义吗,如果系统边界是用参与者表示的，那么所有的参与者都得到定义并进行,了正确描述吗,您已经充分研究了要施加到系统上的约束吗,您已经涵盖了各种类型的约束（比如政治、经济和环境方面）吗,已经确定并定义了系统的所有关键特性吗,这些特性会解决识别出的问题吗,这些特性与确定的约束一致吗,20,21,导出愿景的技巧,-,角色扮演,给项目小组的每个成员分配一个对系统有影响的角色。角色可以是,用户、系统本身、其他系统，有时是系统维护的实体。然后，小组,走查如何使用系统。在此过程中，将讨论谁负责什么事情，对每个,角色的职责进行记录。让系统分析员扮演用户或客户的角色有助于,真正地了解问题领域。,作为角色扮演的框架，您可以对如何使用系统按照脚本执行走查。,如果您已经概括了一些用例，可以将它们用作脚本的基础。还可以,在业务级别执行走查，将业务用例用作脚本的基础。,经常与角色扮演一起使用的另一个技巧是类职责协作,(CRC),卡。,21,22,导出愿景的技巧,-,鱼骨图的使用,22,23,导出愿景的技巧,-,排列图,23,愿景,24,愿景在哪里？,愿景什么样？,导出愿景的技巧,-,愿景引导（一）,24,25,我 要,？,我为愿景,做些什么,导出愿景的技巧,-,愿景引导（二）,理想状态,应 有 状 态,现 实 状 态,25,26,过去,现在,未来？,导出愿景的技巧,-,愿景引导（三）,未来在过去的延长线上吗？,未来,26,27,我的工作难以,找到失误！,销售部,工作能找,到失误,吗？,软件部,导出愿景的技巧,-,愿景引导（四）,我的,27,28,导出愿景的技巧,-,集体讨论,集体讨论是一次简短的集体会议，在会议上每个人都可以提出他们,认为对项目很重要的任何意见。,集体讨论的意思是，让参与者在很短的一段时间内（比如，,15,分,钟）各抒己见，说出他们认为对项目很重要的任何意见。之后，协,调人领导大家对结果进行整理并确定优先顺序。集体讨论的规则如,下：,一开始，明确说明集体讨论会议的目标。,尽可能提出更多的提议。,发挥您的想象力。,收集信息时，不允许出现批评或争论。,一旦信息收集完毕，对提议进行整理。,28,29,导出愿景的技巧,-,集体讨论（续）,组织者让每个参与者都能进行表决。,让每个参与者对每个提议依据类别区分优先顺序（例,如，关键、重要、不错），这些类别具有已指定的权重,（如，,3,、,2,、,1,）。每个提议的优先值的和将说明它相,对于其他提议的重要程度。,如果一些提议需要进一步发展，可以留待以后的会议讨,论。,参与者传阅剩余的自粘性便笺，并以一种有意义的方式,进行整理。,29,30,导出愿景的技巧,-,演示图板,简单地说，演示图板表示使用工具向用户（参与者）说明,（并且有时用动画演示）系统将如何适合于组织，并表明,系统的行为是什么。辅导员向小组展示原始故事板，小组,提供意见。然后，就会在研讨会期间“实时”发展故事板。,因此，需要图形化绘图工具，以使您很容易地更改故事板。,为了避免注意力分散，使用简单的工具（框架图、白板,),常,是很明智的。,有两组截然不同的工具可用于演示图板：被动工具和主动,工具。被动表示显示非动画的图片，而主动工具内置了更,复杂的功能。,30,31,EX,：软件公司内部信息系统建设的愿景,“我们的内部工具有两个目标：使用软件来处理日常工作，为我们,的知识工作者避免浪费的时间；同时把人解放出来做更艰难的工作,以及处理意外事件”,通过提供流程、应用程序和系统带动新一波的用户生产力,集中关注支持公司业务模式的流程和系统,在安全和优化的,IT,架构上运行,产品的首位和最佳客户,31,32,小结,愿景不是理想和目标,愿景的三个特征：,1.,愿景是发生于自己内心的最真切的刻骨铭心的愿望（刻在大脑,的潜意识层）；,2.,愿景是高于现实的（现实生活中不存在的）；,3.,愿景在头脑中是一幅生动而清楚的图像,用户的愿景有三类：一类是合理的,一类是不合理，还有一类是合,理的但目前技术条件无法达成的目标,32,33,小结,形成共同的行动纲领,目标要以业务为导向，可度量，合理，可行,太大的愿景会造成资源浪费，太小愿景造成士气低落,清楚的（,specific,）,可衡量的,measurable),达得到的（,attainable),合理的,(reasonable),具体的,(tangible),33,34,UML,简介,-,主要历史,其它的方法,OOSE,Booch,方法,OMT,34,35,UML,简介,-,主要作用,UML,是一套标准的建模语言，是一整套建模的符号,UML,是一套我们需要遵循规则,UML,是开发高品质产品保证,UML,是软件产品成功部署的保证,UML,使整个软件开发过程可视化,UML,描述整个软件开发过程中，包括分析，设计，实现,UML,让软件建构在特定的语言工具之上,UML,能生成各个阶段工件文档化,35,36,元素,结构性元素（,Structural things,）,动作性元素,（,Behavioral things,），分组元素,Grouping things,Annotational things,关系,（依赖）,Dependency,（关联）,Association,（一般化）,Generalization,（实现）,Realization,图,Class diagram,Object diagram,Component diagram,Deployment diagram,Use case diagram,Interaction diagram,Sequence diagram,Collaboration diagram,Statechart diagram,Activity diagram,UML,简介,-,基本符号,36,UML,简介,-,基本符号,(,元素,),结构化元素,（类）,Class,（接口）,Interface,（用例）,use case,（组件）,component,（节点）,node,动作性元素,(,交互,) interation,(,状态,) state,(,状态机,) state machine,37,分组元素,(,包,)package,37,38,UML,简介,-,基本符号,(,关系,),38,39,动态,多种视角,精确的语法和语义,Activity,Diagrams,静态,Sequence,Diagrams,Communication,Diagrams,State Machine,Diagrams,Deployment,Diagrams,Object,Diagrams,Component,Diagrams,Class,Diagrams,Use-Case,Diagrams,Models,UML,简介,-,基本符号,(,关系,),39,40,40,