如何建立软件产品的愿景

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