软件开发制作——流程图
- 格式:doc
- 大小:337.50 KB
- 文档页数:9
流程图开始流程图是一种用来表示流程、步骤或者操作的图表,它通过图形符号和连接线来展示一个过程的各个步骤及其之间的关系。
流程图在各个领域都有着广泛的应用,比如工程、管理、软件开发等。
在本文中,我将详细介绍流程图的制作步骤和注意事项。
首先,制作流程图的第一步是确定流程的目标和范围。
在确定流程图的范围时,需要明确流程的起点和终点,以及流程中涉及到的各个步骤。
这一步非常重要,因为它直接关系到后续流程图的设计和展示效果。
接下来,根据确定的范围,开始绘制流程图的框架。
流程图的框架通常由各种图形符号和连接线组成,比如矩形框代表步骤,菱形框代表判断,箭头线代表流程的方向等。
在绘制框架时,需要考虑到整个流程的逻辑关系,保证各个步骤之间的连接清晰明了。
然后,填充流程图的内容。
在填充内容时,需要将每个步骤或操作用文字描述清楚,确保每个步骤的功能和作用都能清晰表达。
此外,还需要注意步骤之间的逻辑关系,确保整个流程图的逻辑性和连贯性。
在填充内容的过程中,还需要注意一些细节问题。
比如,需要统一使用一种字体和字号,保证整个流程图的视觉效果统一。
同时,还需要注意文字的排版和对齐,确保整个流程图的美观和易读性。
最后,对制作好的流程图进行审查和调整。
在审查过程中,需要检查流程图的逻辑关系是否清晰,文字描述是否准确,图形符号是否规范等。
如果发现问题,及时进行调整和修改,直到流程图达到预期的效果为止。
总之,制作流程图是一个需要细心和耐心的过程,但只要按照上述步骤和注意事项进行操作,就能够制作出清晰、准确的流程图,为工程、管理、软件开发等各个领域的工作提供有力的支持。
希望本文对大家制作流程图有所帮助,谢谢阅读!。
业务流程图第一部分:什么是流程图1. 定义那什么是流程图呢流程图=流程+图,如下图:图2 流程图的定义流程:Flow,是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程,流程是自然而然就存在的;但是它可以不规范,可以不固定,可以充满问题;所以就会造成看似没有流程;前不久,团队每个人对接一个业务团队去调研流程,反馈给我的流程有一些缺失;询问时,负责人反馈给我的答复是:这一块业务他们没有流程;其实严格意义上讲,业务已经开展,不可能没有流程,只是说没有固定的流程或者你调研的对象也讲不清楚;图:Chart 或者Diagram, 是将基本固化有一定规律的流程进行显性化和书面化,从而有利于传播与沉淀、流程重组参考;从定义可以看出,只要有事情和任务,流程就会有,但是并不是所有的流程都适合用流程图的方式去表现,适合用流程图去表现的流程是一定程度固定的有规律可循的,流程中的关键环节不会朝令夕改的;工作中我们还用到或听到很多其他类型的图表,比如交互设计师们经常说的线框图Wireframes,信息架构图或站点地图Site Map,,开发工程师们经常说的用例图Use Case或E-R图;这些不同的图表要表达的内容有何种差异呢简单做个对比,如图:图3 流程图VS其他常用图表如果要串到某一个项目来说,可以理解成:用例图Use Case:表现了一个角色在系统里要完成的活动是什么,比如用户这个角色与ATM取款机的交互过程中,用户需要完成的活动有存钱,取钱,查询等;而存钱这个活动再可以进一步细分为插卡,输入密码,输入金额,ATM吐钞,用户收款,退卡等活动;用例图可以不考虑用户动作的前后次序,而仅仅提取一些关键的动宾短语,映射出系统应该满足的功能点;常用用例图的人是产品经理和开发工程师;流程图则表示用户每一个活动的前后次序,比如用户必须要先插入银行卡,才能够输入密码,且流程图必须直接表现出各种异常判断,比如当密码错误时,出现什么提示,密码输入错误超过多少次时,出现什么提示和动作;常用流程图的人是产品经理,设计师,或者任何需要讲述业务如何运作的人;信息架构图,站点地图Site Map:表现为了做一个这样的系统,功能与内容的展现层次是什么,比如用户一进去后,欢迎页面的导航如何设计,是否直接出现取款,存款,查询,或者还有别的导航常用信息架构图的是设计师;但是常用组织架构图的是HR;线框图Wireframe:将具体每个界面的内容布局和权重表达出来,且标注出一些交互细节的设计,比如当密码错误后,如何提示下一步动作;常用线框图的人是设计师;实体关系图E-R图:则是数据库架构的工作,表示一个业务系统或场景中的实体时间的关系,比如储户与银行卡的关系是归属1对多,通过开卡事件产生关联;一般来讲,用矩形来表示实体,椭圆标识这个实体的属性,比如储户这个实体的属性有:姓,名,号码,住址等;而银行卡的属性有:开户行,开户名称,银行卡号等;那么流程图要体现出他的差异定义,要素是什么总结出了流程图的6大要素,希望大家能够记住,这6个要素可以在以后的文章里不断回顾,你也可以拿来判断你所看到的流程图是否专业;图4 流程图6大要素•参与者:谁在这个流程中可以是系统,可以是个打印机,更多的指什么角色——一般是有某种工种的人;比如客服同时有小A和小B两人,但是若他们的工作性质完全一样,那么在流程图里只需要写一个客服角色就可以了;•活动:做了什么事,比如点餐,结帐等活动;•次序:这些事情发生的前后顺序如何,哪个任务是其他任务的前置条件比如客人不结帐,就不会产生送他优惠卡的活动;•输入:每项活动开始取决于什么样的输入物或数据,比如做饭的师傅开始做菜时,需要拿到具体的点菜单;•输出:每项活动结束后,会输入什么样的文档或数据传递给下一方,比如师傅做好菜后,如何让负责传菜的人知道菜已经做好•标准化:采用一套标准化的符号用以传递你的流程图,从而使受众更快明白;关于流程图的标准化,并不是强制的,事实上,我们见过很多种类的流程图,只要能够传递明白任务和次序其实已经归类于流程图了;如下面的图:但是若在一个公司的环境下,你的流程图的受众又非常多的话,采取标准化的符号会带来很多交流上的好处,总之你懂的;第二部分:流程图的分类常见的流程图有业务流程图Transaction Flow, 页面流程图Page Flow;在工作中,作为UED,你可能会发现PD经常谈的是业务流程,而作为交互设计师,我们更多产出的是页面流程图;页面流程图和业务流程图到底有什么关系呢先有谁,其次再有谁呢先讲个故事:假设你的梦想是开个中高档的全国连锁餐馆,那么首先你想到的应该不是如何去选址,而是将为何要开连锁餐馆这件事情,以及你的定位,核心竞争力想清楚;是快餐,还是点餐,是连锁还是加盟定位于社区还是繁华商圈是川菜还是江浙海鲜是面向中老年还是年轻人是家庭主题还是动漫主题竞争对手是谁需要什么样的投资可能的风险是什么这些都想清楚了,问题都有答案了,所谓战略层要清晰了吧;然后假设你现在分析来分析去,与主要投资方决定了一个方向:面向年轻人的时尚动漫茶餐厅,连锁,但是先在杭州开始第一家,选址定位于年轻人约会,扫街的地域,比如风景区,著名商圈,电影院旁……那么,接下来呢接下来就是想办法让这些实现吧那么需要做什么事情呢选址拉投资搞装修选餐饮菜单雇佣员工每一步怎么去做,时间点是什么等等的任务拆解以及计划,就需要到战术层了;这些事情的执行,总是需要请人的吧先是核心团队分工去部署各项建设任务,当餐厅开设起来后,就需要组织稳定的运营团队,如服务、卫生、厨房、采购、人事等等,厨房里面还得分工,白案,热菜,冷菜等等吧每个部门需要设置管理层以及汇报关系吧所以你的组织结构就诞生了;那具体每种角色是如何顺畅合作完成日常稳定的以及突发的各项任务呢比如,当顾客上门时,谁去引导客人入座,谁去点菜,怎么将点菜的讯息迅速传递到厨房,并分发到酒水间、冷菜间、热菜间并保证客人尽快能够吃到所点的菜你必须要考虑各种人员的协作流程,优化效率,所以业务流程就出现了;人肉运营了一段时间,没有借助任何点餐系统,你发现也还可以;客人点菜时,服务员手抄写下客人的要求,因为有复印纸,所以服务员能够将副本送入厨房,同时写下餐桌号码;厨房规模较小,负责分配任务的员工看下菜单,分别往冷菜处的黑板上写下需要他们处理的,以及跑到热菜区的黑板上写下待处理的菜品,以及去酒水间报下品名即可;可是随着经营的扩大,以上的人肉方式出现了很多问题,首先,手抄效率太低,顾客频繁换菜,响应来不及,手抄出错,导致经常报错菜;厨房很混乱,不得不多招了几个人专门跑堂;而一旦顾客要加菜,撤菜就更麻烦了,需要找出他们当时点的菜,再进行人工的批注和修改,同时要修改厨房后端的各个黑板……所以你们想要开发一套智能系统,取代很多人肉工作,你们请了系统开发团队,他们经过评估,判断从点菜开始,一直到传菜都可以用系统解决;手持终端,能够快速传递顾客点菜需求到打印机,打印系统能够根据顾客点菜的类型进行自动的分单打印,所以热菜间看到自己的热菜菜单,冷菜间看到自己的冷菜菜单,而酒水间看到酒店菜单;当他们准备完毕后,送出,传菜员可以根据菜名与打印出来的单据进行传菜并根据顾客的点菜小票进行核对;这套系统同时必须配备结算系统,将最终确认掉的菜单及消费价格传递到结算前台,收银员能够快速进行操作;这套系统最终是需要展现出来的,那么手持终端的界面如何设计服务员能够用更少的点击完成一个菜的点餐吗结算中心的界面如何设计通过以上的故事,是不是更明白从战略、战术、业务流程图到页面流程图的关系了总结下:•先是有一个业务需求和业务目标,也即我们的愿景是什么战略•然后就诞生了我们需要分解出什么样的任务,如何执行战术战术•然后就诞生了需要架构什么部门,岗位去分工协作组织架构•然后就诞生了不同的部门在协作完成某件任务时的业务流程业务流程•业务流程基本稳定后,往往会考虑优化效率,所以会诞生出系统来支持流程,减少人肉环节,促进数据采集系统愿景•为了设计这个系统,PD需要思考什么功能能够取代某个环节的人肉工作功能需求,系统流程•不管是怎么样的功能最终都会以界面的方式呈现,设计师们会关注用户在系统里的任务流,行为路径,让用户完成任务更加高效愉悦;页面流程当然,除了业务流程,系统流程,页面流程,还有数据流程被人关注;我们平时工作中,还会经常听人谈到泳道图、任务流程图等等概念,究竟是神马关系呢图5 流程图的分类本文着重于上述流程中的“业务流程图”——并会分享如何绘制泳道图——也即是PD们最多使用,技术们最多参考,UED们最多看到的流程图;本来在第四部分会对泳道图的图示以及绘制方法、原则做更详细的说明,但是看目前的篇幅情况,预计会放到下篇,所以先在这里简单说明下吧;在工作中,我们经常能够看到两种业务流程图,从表现形式来看,一种很好区分,俗称为“泳道图”的它,在样子上也确实像个泳道,可以有横向的泳道,也会有纵向的泳道;泳道图在某些文档里会被称为“以活动为单位的流程图”,浮在泳道中的都是一个个活动;另外一种类型是以部门和岗位为单位的流程图,下图中的圆形就代表一个个部门或岗位;矩形代表活动;这种流程图关注事情如何完成的逻辑,但是在体现各个部门的责任上比较弱;如果是某个岗位的人来看,很难像泳道图那样一眼就能看到自己部门的职责和任务;所以现在用得比较少;再回过头来说泳道图,泳道图有几个关键点:两大维度,活动流转,流程要素;我们会在以后详解;第三部分:为什么需要业务流程图流程图可以提供一种简单扼要的“缩略俯瞰图”,帮助观众快速了解业务如何运转;它包含了几个关键词:谁,什么时候,在什么条件下,做了什么事情,输入什么,输出什么,输出给谁……与系统流程不同,业务流程更关注于业务本身如何运作,讲的是业务故事,包含的是业务规则;而系统流程则是满足业务流程,实现部分流程或全部流程的信息化和系统化;所以业务流程是所有环节的前置条件——软件需求分析,信息系统建设也会先进行业务流程的梳理;下面表现了业务流程图是如何在三个主要场景中发挥作用的:1. 员工培训图6 流程图的应用场景之一:培训在此场景中:流程图能够提供一种快速了解业务如何运作的视图,通过业务流程图,新员工能够快速明白业务的最终目标是什么,中有哪些角色在参与以及他们的职责,以及彼此之间的联接;除了培训新员工,在员工轮岗、调职场景中,员工也需要业务流程图参考,明白新的工作内容如何开展,以及自己所处的位置,自己的上游是谁,下游是谁,自己需要交付的工作内容是什么;2. 流程优化与重组图7 流程图的应用场景之二:流程优化业务流程重组Business Process Reengineering的存在可以明确反驳:存在即合理;事实上,存在的业务流程并未是合理的,有可能是参与的多个角色习惯了某种做法,有可能是变革尚未影响到末端的操作,也有可能缺乏对于运行中的业务流程问题的洞察以及强有力的变革推动——因为要推动业务流程变革,不是某个部门的事情,而是需要流程中各个部门的通力配合;更多时候,业务流程优化是自上而下的,但是老板们未必对实际运作的业务流程那么心知肚明,业务流程图能够很好去表现这个“运作模型”;通过看业务流程图,找关键节点的人访问,能够直接切入:为什么要这么做,为什么不这么做从而探索出更深层次的问题,而不是问:你们现在怎么做通过调研,分析业务流程图,引入更多角色,能够分析出目前业务流程的问题:缺失,重复,风险,效率等等;从而制定相应的优化方案;3. 信息化的基础图8 流程图的应用场景之三:信息化基础正如上文所述的餐馆梦想的案例,信息系统的一项任务就是解放员工的手脚,取代一些重复的人力劳动工作;系统上了之后,不是说业务流程不需要而是经过了一些调整,其中某个参与者变成了系统,或手持设备,或打印机而已;那么在做系统的功能设计和系统流程设计时,是不是必须先要了解目前业务是如何运作的呢从而更好分析分析,更好说明系统在什么环节取代了什么类型的人肉工作所以我们看到的PRD往往也会先以业务流程图开始说明,而叙述一个系统建设的好处时,也可以用以前的业务流程与系统上了之后的业务流程进行对比;根据分析,将愿景中的新的业务流程图背后需要系统的功能点撰写清楚;第四部分:如何绘制业务流程图首先绘制业务流程图本身有没有流程一定是有的;在软件工程学里听说一句话叫:万物皆对象;那么在流程学里,万事皆流程;吃饭难道没流程吗就吃饭的动作而言,就有流程:拿筷子——夹菜——入口——咀嚼——吞咽;有不少同学在这一部份很快想会问一个问题:Heidi,请介绍画流程图的工具吧我个人是工具派,从不否认人工欲善其事,必先利其器的道理;好的工具本身就是一名好的老师,除了技能,也能够教会我们一些理论与理念,这些理念也是“器”中很重要的一部分;其次才是具体的工具应用技能;所以我并不建议直接跳转到工具应用;对于初学者而言,笔与纸永远是最好的入门工具,因为你无需和任何一个陌生的软件较劲;那么,绘制业务流程图有没有可遵循的流程呢我建议可以从下面4步着手;1. 调研如何快速了解业务运作真相有没有调研的技巧放送2. 梳理与呈现•能否快速将调研得到的文字和问题,快速转化为业务流程图•业务流程图的标准图示是什么•怎么评价一个业务流程图的好与坏3. 评审与确认——能否真正让业务流程图反映现实中的业务4. 归档维护——流程不断变更,业务流程图如何快速响应。
软件工程开发第一章软件工程基本观念1.1 软件工程的目标与常用模型软件工程的目标是提高软件的质量与生产率,最终实现软件的工业化生产。
对开发人员而言,如果非得在质量与生产率之间分个主次不可,那么应该是质量第一,生产率第二。
软件工程的主要环节如图1所示,软件开发过程一般包括可行性与需求分析、系统设计、程序设计、测试和维护。
图1 软件工程环节常见的软件工程模型有:线性模型,渐增式模型,螺旋模型,快速原型模型,形式化描述模型等等。
虽然线性模型比较简单,太理想化,但是每一个非线性的模型都能转化为一系列简单的线性模式,因此在其他模式中需要灵活运用线性模式。
1.2 软件开发的基本策略1.2.1 复用在一个新系统中,大部分的内容是成熟的,只有小部分内容是创新的。
应该把大部分的时间用在小比例的创新工作上,而把小部分的时间用在大比例的成熟工作中。
我们将具有一定集成度并可以重复使用的软件组成单元称为软构件。
软件复用可以表述为:直接使用已有的软构件,即可组装(或加以合理修改)成新的系统。
这样可以提高生产率和质量。
图2应用软构件产生应用软件1.2.2 分而治之我们可以把复杂的问题分解成N个简单的问题,再逐个寻求解决方法。
但是最终的目的是要保证单个的简单问题可以通过程序实现,组装后能够使原本复杂的问题得到合理解决。
1.2.3 优化——折衷优化是用以优化软件的各个质量因素,但不能面面俱到,应折衷,其目标就是协调各个质量因素,实现整体质量最优。
而不能盲目得拆东墙,补西墙。
第二章软件开发过程各个环节介绍2.1 可行性分析与需求分析2.1.1 可行性分析要求可行性分析是从经济、技术、市场与政策及人员方面分析这个项目做还是不做。
2.1.2 需求分析要求当确定做之后,我们就要与客户交流,进行需求分析,但由于客户表达不清、需求自身经常变动或分析人员理解有误,都会导致需求分析困难。
因此,有必要通过请教行家或者分析同类型产品,来做进一步的分析。
软件开发流程图
软件开发流程图:
在软件开发流程中,项目前期需要获取用户需求并编制初步方案。
同时,需要跟踪需求的基本确定并编制详细预算,配置内部资源并分配开发任务。
在系统实现过程中,需要进行技术调测并控制/调整进度,以确保无需变更。
在集成测试阶段,需要进行测试并提交测试文档。
如果通过测试,则进行部署试用,并获得试用意见。
最后,需要进行系统验收并结项,向总经理汇报。
硬件开发流程图:
在硬件开发流程中,需要进行产品调研并拟定产品需求表。
然后,研发经理组织结构、电子与ID协调定义,进行3D图
形设计与修改,并形成产品外观效果图、产品3D图和产品规
格书。
如果评审通过,则由业务形成立案通知书和产品研发任务书,交总经理审批并输出给研发部进行设计开发工作。
软件开发流程图解析随着信息化时代的发展,软件应用日益普及,软件的研发和开发也变得越来越重要。
软件开发过程中的流程图,是管理软件开发过程和维护软件项目的一个重要工具。
本文将对软件开发流程图进行解析。
什么是软件开发流程图软件开发流程图,是对软件开发过程中各环节关系的图形化表达。
它通过图形与符号来描述分析、设计、编码、测试等软件开发过程中的步骤与流转关系,具有较强的表现力和可视性,从而能够清晰地呈现不同阶段之间的关系,使开发人员有效地掌控整个软件开发过程。
软件开发流程图的组成部分1. 流程图主体软件开发流程图的主体是由不同的节点组成,用来表示不同的处理过程或者操作。
2. 活动每一个节点表示一个具体的活动,也称为流程元素。
活动可以是一系列有序的任务,也可以是一个算法、一个判断语句,或者是一个输入或输出控件等。
3. 控制流控制流表示活动之间的关系,控制流有三种基本类型:顺序结构、选择结构和循环结构。
4. 数据流数据流是指数据在软件开发过程中的传递过程。
数据流从一个活动开始,经过数据传输器,到达另一个活动。
5. 数据存储数据存储是指软件程序中数据的存储,可以是内存或者其他设备。
软件开发流程图的优点1. 易于理解软件开发流程图采用图像的方式来表示软件开发过程中的不同流程和步骤,使得开发人员更容易理解。
2. 易于修正软件开发流程图使得开发人员更容易发现软件开发过程中的问题和漏洞,从而可以快速进行修正,提高开发效率。
3. 易于跟踪软件开发流程图可以帮助开发人员跟踪软件开发过程中的进度和成果,以及发现潜在的问题和风险。
4. 易于沟通软件开发流程图的图形化表现形式易于沟通交流,使得开发团队和管理层更容易理解开发进度和成果。
软件开发流程图的设计方法在设计软件开发流程图时,需要根据实际情况选择不同的图形符号和命名规则,可以采用以下步骤:1. 确定流程图主题和目的需要明确软件开发流程图的主题和目的,以便在设计过程中更好地掌握设计思路和方法。
模型图模型名称测试介入点测试范围优点瀑布模型全部代码编写完后整个软件产品1、测试成本低2、测试范围小3、简单、高效螺旋模型1、一个功能代码完成后,进行单元测试2、一个模块代码完成后,进行集成测试3、产品全部功能完成后,进行系统测试1、单元测试--代码2、集成测试--接口3、系统测试--整个软件产品1、应对变更和风险能力强2、测试介入时间早3、测试较充分4、软件质量有所提高和改善RUP模型(Rationalunified process )Rational统一开发过程每个阶段编码完成后每个阶段业务建模时定义的功能范围+上一阶段完成的所有功能1、将系统进行分解,简化了测试的难度2、每个阶段提交个半成品a、提高客户的信心b、控制变更范围c、可以提早进行变更IPD模型(Integration product development)集成产品开发过程1、硬件研发完成后--硬件测试2、软件研发完成后--软件测试1、硬件2、软件所有部门的数据都进行了充分的数据共享,提高了决策的准确性常见的软件研发基本流程图缺点适用范围1、测试介入晚,发现缺陷较晚,软件质量不可控2、上有成果物未完成时下游的人力资源闲置3、简单、高效1、项目小2、需求明确3、公司规模小1、需要专业的风险识别专家2、成本高与人的生命和财产相关的系统需要专业的软件构架师不适合功能模块联系较紧密的系统管理成本较高大型的软硬件集成厂商。
一个完整的软件开发流程一、开发流程图二、过程产物及要求本表主要列出开发阶段需要输出的过程产物,包括产物名称、成果描述、负责人及备注,即谁、在什么时间、应该提供什么内容、提供内容的基本方向和形式是什么。
三、过程说明(一)项目启动1、产品经理和项目干系人确定项目方向,产品型项目的干系人包括公司领导、产品总监、技术总监等,项目的话则包括客户方领导、主要执行人等。
2、公司领导确认项目组团队组成,包括产品经理、研发项目经理、研发工程师、测试团队等。
3、明确项目管理制度,每个阶段的成果产物需要进行相应的评审,评审有相应的《会议纪要》;从项目启动起,研发项目经理每周提供《项目研发周报》;测试阶段,测试工程师每周提供《项目测试周报》。
4、产品经理进行需求调研,输出《需求调研》文档。
需求调研的方式主要有背景资料调查和访谈。
5、产品经理完成《业务梳理》。
首先,明确每个项目的目标;其次,梳理项目涉及的角色;再来,每个角色要进行的事项;最后,再梳理整个系统分哪些端口,要有哪些业务模块,每个模块再包含哪些功能。
(二)需求阶段1、进入可视化产物的输出阶段,产品经理提供最简单也最接近成品的《产品原型》,线框图形式即可。
在这个过程中还可能产生的包括业务流程图和页面跳转流程图。
业务流程图侧重在不同节点不同角色所进行的操作,页面跳转流程图主要指不同界面间的跳转关系。
项目管理者联盟2、产品经理面向整个团队,进行需求的讲解。
3、研发项目经理根据需求及项目要求,明确《项目里程碑》。
根据项目里程表,完成《产品开发计划》,明确详细阶段的时间点,最后根据开发计划,进行《项目任务分解》,完成项目的分工。
4、研发工程师按照各自的分工,进入概要需求阶段。
《概要需求》旨在让研发工程师初步理解业务,评估技术可行性。
(三)设计阶段1、UI设计师根据产品的原型,输出《界面效果图》,并提供界面的标注,最后根据主要的界面,提供一套《UI设计规范》。
UI设计规范主要是明确常用界面形式尺寸等,方便研发快速开发。
软件开发制作——流程图
项目开发中的各种2010-05-07 20:15:24 阅读700 评论1 字号:大中小订阅
1、各司其职的形状
在我的流程图中,适用于不同目的和功能的形状都有各自确定的规范。
到目前为止,我一共定义了以下一些形状:(1)开始和结束
作为整张流程图的头和尾,必须标清楚到底具体指哪个页面,以免日后出现歧义。
(2)网页
如你所见,网页的形状是一个带有漂亮的淡蓝色过渡效果的长方形,它的边框为深蓝色,中间写明了这个网页的用途,括号中的数字代表这个形状所对应的demo文件的名称(比如这里是2.html),我有时会把流程图输出为网页的形式,并把每个网页形状和它所对应的demo文件链接起来,这样查看起来非常方便。
对OmniGraffle来说这是小菜一碟,如果你被迫用Visio,嗯……
另外,所有从形状出来的线条,都具有和此形状边框一样的颜色。
这样的做法不仅看起来漂亮,在复杂的流程图中还能轻易地标明各形状的关系。
我没有见过类似的做法,所以这是由我首创也说不定,呵。
(3)后台判断
很常见的一个形状。
我在用法上有一点和其他人的不同在于,我几乎总是让…是‟的分支往下流动,让…否‟的分支向右流动。
因为流程图一般都是从上向下、从左到右绘制的,遵循上述规则一方面可以让绘制者不用为选择方向操心,另一方面也方便了读者阅读。
(4)表单错误页
既然有表单,当然会有错误信息。
其实这个信息很重要,用户出错时惶恐不安,就靠着错误提示来解决问题了。
你不在流程图里说什么时候显示错误页、不在demo里提供错误页,有些程序员会直接在网页上写个“错误,请检查”,所以UI 设计师一定要对这个东西重视起来。
但一般来说也没必要把每种错误都在流程图中表示出来,因为含有两个文本框的表单就有三种出错情况了,多了就更不用说了。
所以我都是把错误页变为表单的附属页,比如表单页的编号为2,那么此表单错误页的编号就从2.1开始排下去,每种错误放到一个附属页中,这样程序员在拿到demo时也能搞清楚什么意思。
结合网页和表单的形状,一个表单验证的流程图就是这样的:
(5)后台动作
并非所有后台动作都绘入流程图中(否则流程图就会变成庞然大物了),只有需要特别强调的后台动作(和用户体验直接相关的)才使用此形状。
(6)多重分支
多重分支指的是几种并列的情况,每种情况都有发生的可能,发生哪种取决于分支起始处的判断结果。
(7)对话框
有时候一些操作可以利用对话框来完成,这些对话框由js生成,显示在父界面之上。
(8)注释
这个形状(比如页面)详细的内容,或者需要解释的业务逻辑,甚至用户此处的情况等,我都会放到注释中,这样既降低沟通成本,又可作为备忘。
(9)跳转点
在一个复杂的流程图中,往往出现跳转到另外一个远处结点的情况,此时如果直接用线连过去,未免使得流程图显得凌乱,用一个跳转点就解决问题了。
在点内标明跳转到的形状的编号,画起来容易,看起来也清楚。
此外,也可以利用跳转点来分割篇幅巨大的流程图,Yahoo!就这么用。
(10)子流程
分割篇幅巨大的流程图,更好的办法是用子流程。
要注意的是,如果你在流程图中使用了子流程这一形状,一定记得同时附上子流程图,以消除影响项目质量的不确定性因素。
另外,在子流程图中也可以标明其所属关系。
(11)流程块
可以用流程块将整张流程图分隔为几个部分,并为每个部分单独命名(比如“流程块1”等)。
这样做的目的在于从视觉上使复杂的流程图变得更为清晰,在沟通时也方便。
2、图例和流程图信息
在团队合作中,图例是必须的,否则没人知道你画出来的东西到底是什么。
即使流程图只给自己看,也最好养成标注图例的好习惯。
其实这道理有点类似程序中的注释。
流程图信息也是必备的。
其内容至少应包括作者、时间、流程图名称和版本(如下图)。
这一方面可以让读者(其他同事)在有问题时能够方便地找到作者你,也起到了meta的作用。
3、绘制流程图的工具
Mac下首选OmniGraffle,Windows下除了Visio,似乎没有更好的选择(虽然Visio已经很难用了)。
4、评价流程图的好坏
我觉得一个好的流程图至少应做到以下几点:
1. 密切地迎合了用户的心理状态、如实的反映了用户的操作习惯。
流程图是要指导UI设计的,是UI设计的参
照物,如果流程图本身无法正确描绘出用户的情况的话,UI十有八九会出问题;
2. 覆盖了各种可能的情况和细节。
这非常重要。
任何在先期不确定的因素,都会在项目中成为随时引爆的地雷,
都会直接降低最终上线的UI质量。
此种情况真是屡见不鲜。
但同时这条又很难做到,因为它不仅要求设计
师熟悉用户,也要设计师充分知晓产品的商业逻辑,还要了解系统的运作机制,落下以上任何一个方面,都
会在流程图中留下死角。
这个问题我不知道有没有更好的解决方案,不过与PD和系分反复沟通是个行之有
效的方法;
3. 考虑到系统的设计和承受能力。
系统的运作机制和承受能力必须在绘制流程图过程中考虑进去,以免出现流
程图被开发人员枪毙的情况。
我的习惯是,在绘制流程图时和系统分析师频繁沟通和交流,确保每一个环节
都是可行的;
4. 确保别人看得懂你的流程图。
别人现在看不懂,你自己以后也一样看不懂。
为了降低沟通成本,把流程图画
清楚吧。
5、其它
(1)想办法把流程图绘制得漂亮些。
谁不喜欢漂亮的东西呢?
这是我做过的一些流程图,当然文字全部模糊掉了(放图之前犹豫了好长时间-这样做不知是否有损我的职业道德。
我特意请教了Fenng,他觉得没事。
如果谁觉得有问题请直言不讳地告诉我)。
(2)如果你在公司里不是一锤定音式的人物的话,你就需要对你的文档进行版本管理。
流程图也不例外,什么时间发布的什么版本,都要清楚地标出来,“ 最新”是个用不得的词。