軟件開發(fā)流程圖符號含義（軟件編寫流程圖）
今天給各位分享軟件開發(fā)流程圖符號含義的知識，其中也會對軟件編寫流程圖進(jìn)行解釋，如果能碰巧解決你現(xiàn)在面臨的問題，別忘了關(guān)注本站，現(xiàn)在開始吧！
本文目錄一覽：
求軟件測試大神解釋下這張流程圖什么意思
首先從流程圖上看，該圖是問題跟蹤流程圖。
1.新提交的：一般由測試人員提交問題，主要是描述問題現(xiàn)象，然后提交給對應(yīng)開發(fā)；
2.已解決的：開發(fā)人員收到問題后，開始對問題進(jìn)行分析，判斷該問題是否為軟件缺陷，如果是，則需要修改程序，如果不是，則需要將問題退回給測試人員；
3.已驗(yàn)證的：開發(fā)人員確認(rèn)問題為軟件缺陷后，修改問題，將“已解決的”的問題通過版本更新的形式或其他提交到測試人員，此時(shí)問題成為待驗(yàn)證問題，“已驗(yàn)證的”由測試人員操作，確定開發(fā)修改正確后，問題將關(guān)閉。
4.已關(guān)閉的：從上面的描述，一種是開發(fā)人員認(rèn)為問題不屬于軟件缺陷，因此將問題退回給測試人員，一種測試人員驗(yàn)證問題通過后，問題可以關(guān)閉了。
5.未解決的：如果前面開發(fā)認(rèn)為不是軟件缺陷的問題，測試認(rèn)為是軟件缺陷，此時(shí)則不會將問題關(guān)閉，則是重新提交，成為未解決的，另外一種是驗(yàn)證的時(shí)候仍存在問題，驗(yàn)證不通過，也會成為未解決。需要開發(fā)重新修改軟件，成為“已解決的”。
從上圖來看，該流程圖明顯不夠完善，很難看得問題在各個(gè)階段的狀態(tài)，建議以問題狀態(tài)作為跟蹤依據(jù)更好。
UML建模（二）--流程圖
本文會包含幾塊內(nèi)容：
流程圖= 流程+圖。
流程：Flow, 是指特定主體為了滿足特定需求而進(jìn)行的有特定邏輯關(guān)系的一系列操作過程，流程是自然而然就存在的。但是它可以不規(guī)范，可以不固定，可以充滿問題。所以就會造成看似沒有流程。
圖：Chart 或者 Diagram , 是將基本固化有一定規(guī)律的流程進(jìn)行顯性化和書面化，從而有利于傳播與沉淀、流程重組參考。
從定義可以看出，只要有事情和任務(wù)，流程就會有，但是并不是所有的流程都適合用流程圖的方式去表現(xiàn)，適合用流程圖去表現(xiàn)的流程是一定程度固定的有規(guī)律可循的，流程中的關(guān)鍵環(huán)節(jié)不會朝令夕改的。
● 參與者 ：誰在這個(gè)流程中？可以是系統(tǒng)，可以是個(gè)打印機(jī)，更多的指什么角色——一般是有某種工種的人。比如客服同時(shí)有小A和小B兩人，但是若他們的工作性質(zhì)完全一樣，那么在流程圖里只需要寫一個(gè)客服角色就可以了。
● 活動 ：做了什么事，比如點(diǎn)餐，結(jié)帳等活動。
● 次序 ：這些事情發(fā)生的前后順序如何，哪個(gè)任務(wù)是其他任務(wù)的前置條件？比如客人不結(jié)帳，就不會產(chǎn)生送他優(yōu)惠卡的活動。
● 輸入 ：每項(xiàng)活動開始取決于什么樣的輸入物或數(shù)據(jù)，比如做飯的師傅開始做菜時(shí)，需要拿到具體的點(diǎn)菜單。
● 輸出 ：每項(xiàng)活動結(jié)束后，會輸入什么樣的文檔或數(shù)據(jù)傳遞給下一方，比如師傅做好菜后，如何讓負(fù)責(zé)傳菜的人知道菜已經(jīng)做好？
● 標(biāo)準(zhǔn)化 ：采用一套標(biāo)準(zhǔn)化的符號用以傳遞你的流程圖，從而使受眾更快明白。
常見的流程圖有業(yè)務(wù)流程圖（Transaction Flow）, 頁面流程圖（Page Flow）。
在工作中，作為UED，你可能會發(fā)現(xiàn)PD經(jīng)常談的是業(yè)務(wù)流程，而作為交互設(shè)計(jì)師，我們更多產(chǎn)出的是頁面流程圖。頁面流程圖和業(yè)務(wù)流程圖到底有什么關(guān)系呢？ 先有誰，其次再有誰呢？
先講個(gè)故事：假設(shè)你的夢想是開個(gè)中高檔的全國連鎖餐館，那么首先你想到的應(yīng)該不是如何去選址，而是將為何要開連鎖餐館這件事情，以及你的定位，核心競爭力想清楚。是快餐，還是點(diǎn)餐，是連鎖還是加盟？定位于社區(qū)還是繁華商圈？是川菜還是江浙海鮮？是面向中老年還是年輕人？是家庭主題還是動漫主題？競爭對手是誰？需要什么樣的投資？可能的風(fēng)險(xiǎn)是什么？這些都想清楚了，問題都有答案了，所謂戰(zhàn)略層要清晰了吧。然后假設(shè)你現(xiàn)在分析來分析去，與主要投資方?jīng)Q定了一個(gè)方向：面向年輕人的時(shí)尚動漫茶餐廳，連鎖，但是先在杭州開始第一家，選址定位于年輕人約會，掃街的地域，比如風(fēng)景區(qū)，著名商圈，電影院旁…………等等等等，那么接下來呢？
接下來就是想辦法讓這些實(shí)現(xiàn)吧？那么需要做什么事情呢？選址？拉投資？搞裝修？選餐飲菜單？雇傭員工？每一步怎么去做，時(shí)間點(diǎn)是什么？等等的任務(wù)拆解以及計(jì)劃，就需要到戰(zhàn)術(shù)層了。
這些事情的執(zhí)行，總是需要請人的吧？先是核心團(tuán)隊(duì)分工去部署各項(xiàng)建設(shè)任務(wù)，當(dāng)餐廳開設(shè)起來后，就需要組織穩(wěn)定的運(yùn)營團(tuán)隊(duì)，如服務(wù)、衛(wèi)生、廚房、采購、人事等等，廚房里面還得分工，白案，熱菜，冷菜等等吧？每個(gè)部門需要設(shè)置管理層以及匯報(bào)關(guān)系吧？所以你的組織結(jié)構(gòu)就誕生了。
那具體每種角色是如何順暢合作完成日常穩(wěn)定的以及突發(fā)的各項(xiàng)任務(wù)呢？比如，當(dāng)顧客上門時(shí)，誰去引導(dǎo)客人入座，誰去點(diǎn)菜，怎么將點(diǎn)菜的訊息迅速傳遞到廚房，并分發(fā)到酒水間、冷菜間、熱菜間？并保證客人盡快能夠吃到所點(diǎn)的菜？你必須要考慮各種人員的協(xié)作流程，優(yōu)化效率，所以業(yè)務(wù)流程就出現(xiàn)了。
人肉運(yùn)營了一段時(shí)間，沒有借助任何點(diǎn)餐系統(tǒng)，你發(fā)現(xiàn)也還可以?？腿它c(diǎn)菜時(shí)，服務(wù)員手抄寫下客人的要求，因?yàn)橛袕?fù)印紙，所以服務(wù)員能夠?qū)⒏北舅腿霃N房，同時(shí)寫下餐桌號碼。廚房規(guī)模較小，負(fù)責(zé)分配任務(wù)的員工看下菜單，分別往冷菜處的黑板上寫下需要他們處理的，以及跑到熱菜區(qū)的黑板上寫下待處理的菜品，以及去酒水間報(bào)下品名即可?？墒请S著經(jīng)營的擴(kuò)大，以上的人肉方式出現(xiàn)了很多問題，首先，手抄效率太低，顧客頻繁換菜，響應(yīng)來不及，手抄出錯(cuò)，導(dǎo)致經(jīng)常報(bào)錯(cuò)菜。廚房很混亂，不得不多招了幾個(gè)人專門跑堂。而一旦顧客要加菜，撤菜就更麻煩了，需要找出他們當(dāng)時(shí)點(diǎn)的菜，再進(jìn)行人工的批注和修改，同時(shí)要修改廚房后端的各個(gè)黑板……
所以你們想要開發(fā)一套智能系統(tǒng)，取代很多人肉工作，你們請了系統(tǒng)開發(fā)團(tuán)隊(duì)，他們經(jīng)過評估，判斷從點(diǎn)菜開始，一直到傳菜都可以用系統(tǒng)解決。手持終端，能夠快速傳遞顧客點(diǎn)菜需求到打印機(jī)，打印系統(tǒng)能夠根據(jù)顧客點(diǎn)菜的類型進(jìn)行自動的分單打印，所以熱菜間看到自己的熱菜菜單，冷菜間看到自己的冷菜菜單，而酒水間看到酒店菜單。當(dāng)他們準(zhǔn)備完畢后，送出，傳菜員可以根據(jù)菜名與打印出來的單據(jù)進(jìn)行傳菜并根據(jù)顧客的點(diǎn)菜小票進(jìn)行核對。這套系統(tǒng)同時(shí)必須配備結(jié)算系統(tǒng)，將最終確認(rèn)掉的菜單及消費(fèi)價(jià)格傳遞到結(jié)算前臺，收銀員能夠快速進(jìn)行操作。
這套系統(tǒng)最終是需要展現(xiàn)出來的，那么手持終端的界面如何設(shè)計(jì)？服務(wù)員能夠用更少的點(diǎn)擊完成一個(gè)菜的點(diǎn)餐嗎？結(jié)算中心的界面如何設(shè)計(jì)？
通過以上的故事，是不是更明白從戰(zhàn)略、戰(zhàn)術(shù)、業(yè)務(wù)流程圖到頁面流程圖的關(guān)系了？總結(jié)下：
●先是有一個(gè)業(yè)務(wù)需求和業(yè)務(wù)目標(biāo)，也即我們的愿景是什么？（戰(zhàn)略）
●然后就誕生了我們需要分解出什么樣的任務(wù)，如何執(zhí)行戰(zhàn)術(shù)？（戰(zhàn)術(shù)）
●然后就誕生了需要架構(gòu)什么部門，崗位去分工協(xié)作？（組織架構(gòu)）
●然后就誕生了不同的部門在協(xié)作完成某件任務(wù)時(shí)的業(yè)務(wù)流程？（業(yè)務(wù)流程）
●業(yè)務(wù)流程基本穩(wěn)定后，往往會考慮優(yōu)化效率，所以會誕生出系統(tǒng)來支持流程，減少人肉環(huán)節(jié)，促進(jìn)數(shù)據(jù)采集（系統(tǒng)愿景）
●為了設(shè)計(jì)這個(gè)系統(tǒng)，PD需要思考什么功能能夠取代某個(gè)環(huán)節(jié)的人肉工作（功能需求，系統(tǒng)流程）
●不管是怎么樣的功能最終都會以界面的方式呈現(xiàn)，設(shè)計(jì)師們會關(guān)注用戶在系統(tǒng)里的任務(wù)流，行為路徑，讓用戶完成任務(wù)更加高效愉悅。（頁面流程）
當(dāng)然，除了業(yè)務(wù)流程，系統(tǒng)流程，頁面流程，還有數(shù)據(jù)流程被人關(guān)注。
我們平時(shí)工作中，還會經(jīng)常聽人談到泳道圖啊，任務(wù)流程圖啊等等概念，究竟是神馬關(guān)系呢？
在工作中，我們經(jīng)常能夠看到兩種業(yè)務(wù)流程圖，從表現(xiàn)形式來看，一種很好區(qū)分，俗稱為“泳道圖”的它，在樣子上也確實(shí)像個(gè)泳道，可以有橫向的泳道，也會有縱向的泳道。泳道圖在某些文檔里會被稱為“以活動為單位的流程圖”，浮在泳道中的都是一個(gè)個(gè)活動。
泳道圖有幾個(gè)關(guān)鍵點(diǎn)：兩大維度，活動流轉(zhuǎn)，流程要素。
另外一種類型是以部門和崗位為單位的流程圖，下圖中的圓形就代表一個(gè)個(gè)部門或崗位。矩形代表活動。這種流程圖關(guān)注事情如何完成的邏輯，但是在體現(xiàn)各個(gè)部門的責(zé)任上比較弱。如果是某個(gè)崗位的人來看，很難像泳道圖那樣一眼就能看到自己部門的職責(zé)和任務(wù)。所以現(xiàn)在用得比較少。
流程圖可以提供一種簡單扼要的“縮略俯瞰圖”，幫助觀眾快速了解業(yè)務(wù)如何運(yùn)轉(zhuǎn)。它包含了幾個(gè)關(guān)鍵詞： 誰，什么時(shí)候，在什么條件下，做了什么事情，輸入什么，輸出什么，輸出給誰……
與系統(tǒng)流程不同，業(yè)務(wù)流程更關(guān)注于業(yè)務(wù)本身如何運(yùn)作，講的是業(yè)務(wù)故事，包含的是業(yè)務(wù)規(guī)則。而系統(tǒng)流程則是滿足業(yè)務(wù)流程，實(shí)現(xiàn)部分流程或全部流程的信息化和系統(tǒng)化。
所以業(yè)務(wù)流程是所有環(huán)節(jié)的前置條件——軟件需求分析，信息系統(tǒng)建設(shè)也會先進(jìn)行業(yè)務(wù)流程的梳理。
下面表現(xiàn)了業(yè)務(wù)流程圖是如何在三個(gè)主要場景中發(fā)揮作用的：
1、培訓(xùn)
在此場景中：流程圖能夠提供一種快速了解業(yè)務(wù)如何運(yùn)作的視圖，通過業(yè)務(wù)流程圖，新員工能夠快速明白業(yè)務(wù)的最終目標(biāo)是什么，中有哪些角色在參與以及他們的職責(zé)，以及彼此之間的聯(lián)接。
除了培訓(xùn)新員工，在員工輪崗、調(diào)職場景中，員工也需要業(yè)務(wù)流程圖參考，明白新的工作內(nèi)容如何開展，以及自己所處的位置，自己的上游是誰，下游是誰，自己需要交付的工作內(nèi)容是什么。
2、流程優(yōu)化與重組
業(yè)務(wù)流程重組（Business Process Reengineering）的存在可以明確反駁：存在即合理。事實(shí)上，存在的業(yè)務(wù)流程并未是合理的，有可能是參與的多個(gè)角色習(xí)慣了某種做法，有可能是變革尚未影響到末端的操作，也有可能缺乏對于運(yùn)行中的業(yè)務(wù)流程問題的洞察以及強(qiáng)有力的變革推動——因?yàn)橐苿訕I(yè)務(wù)流程變革，不是某個(gè)部門的事情，而是需要流程中各個(gè)部門的通力配合。
更多時(shí)候，業(yè)務(wù)流程優(yōu)化是自上而下的，但是老板們未必對實(shí)際運(yùn)作的業(yè)務(wù)流程那么心知肚明，業(yè)務(wù)流程圖能夠很好去表現(xiàn)這個(gè)“運(yùn)作模型”。通過看業(yè)務(wù)流程圖，找關(guān)鍵節(jié)點(diǎn)的人訪問，能夠直接切入：為什么要這么做，為什么不這么做？從而探索出更深層次的問題，而不是問：你們現(xiàn)在怎么做？
通過調(diào)研，分析業(yè)務(wù)流程圖，引入更多角色，能夠分析出目前業(yè)務(wù)流程的問題：缺失，重復(fù)，風(fēng)險(xiǎn)，效率等等。從而制定相應(yīng)的優(yōu)化方案。
3、信息化的基礎(chǔ)
正如上文所述的餐館夢想的案例，信息系統(tǒng)的一項(xiàng)任務(wù)就是解放員工的手腳，取代一些重復(fù)的人力勞動工作。系統(tǒng)上了之后，不是說業(yè)務(wù)流程不需要而是經(jīng)過了一些調(diào)整，其中某個(gè)參與者變成了系統(tǒng)，或手持設(shè)備，或打印機(jī)而已。
那么在做系統(tǒng)的功能設(shè)計(jì)和系統(tǒng)流程設(shè)計(jì)時(shí)，是不是必須先要了解目前業(yè)務(wù)是如何運(yùn)作的呢？從而更好分析分析，更好說明系統(tǒng)在什么環(huán)節(jié)取代了什么類型的人肉工作？
所以我們看到的PRD往往也會先以業(yè)務(wù)流程圖開始說明，而敘述一個(gè)系統(tǒng)建設(shè)的好處時(shí)，也可以用以前的業(yè)務(wù)流程與系統(tǒng)上了之后的業(yè)務(wù)流程進(jìn)行對比。根據(jù)分析，將愿景中的新的業(yè)務(wù)流程圖背后需要系統(tǒng)的功能點(diǎn)撰寫清楚。
首先繪制業(yè)務(wù)流程圖本身有沒有流程？一定是有的。在軟件工程學(xué)里聽說一句話叫：萬物皆對象。那么在流程學(xué)里，萬事皆流程。吃飯難道沒流程嗎？就吃飯的動作而言，就有流程：拿筷子——夾菜——入口——咀嚼——吞咽。
那么，繪制業(yè)務(wù)流程圖有沒有可遵循的流程呢？我建議可以從下面4步著手。
1、調(diào)研
如何快速了解業(yè)務(wù)運(yùn)作真相？有沒有調(diào)研的技巧放送？
2、梳理與呈現(xiàn)
能否快速將調(diào)研得到的文字和問題，快速轉(zhuǎn)化為業(yè)務(wù)流程圖？
業(yè)務(wù)流程圖的標(biāo)準(zhǔn)圖示是什么？
怎么評價(jià)一個(gè)業(yè)務(wù)流程圖的好與壞？
3、評審與確認(rèn)——能否真正讓業(yè)務(wù)流程圖反映現(xiàn)實(shí)中的業(yè)務(wù)？
4、歸檔維護(hù)——流程不斷變更，業(yè)務(wù)流程圖如何快速響應(yīng)？
在繪制業(yè)務(wù)流程圖前，思考如何精美、如何交互以及使用什么工具，都不應(yīng)該是重點(diǎn)。
真正重點(diǎn)的是將業(yè)務(wù)流程圖的關(guān)鍵要素給搜集一番。請?jiān)噲D回答清楚以下幾個(gè)問題，否則不要開始繪制流程圖：
除了在本部分開始的那幾個(gè)問題要顧及到， 其實(shí)調(diào)研過程解決的仍然是who，what，why，how，以及where的問題：誰，在什么情況下，做了什么事情，這個(gè)事情需要什么前置條件，又輸出了什么，這個(gè)事情在哪里完成的？ 搞明白這幾個(gè)問題，我們的調(diào)研就可以圓滿完成了。
流程圖的表現(xiàn)，要回答這幾個(gè)問題：
1、Who——誰？部門，角色，崗位
2、What——什么事情？
3、Where——在哪里做的？在我梳理的業(yè)務(wù)流程圖上，where更多表示是文檔還是各種系統(tǒng)，用來表示信息化的程度。比如當(dāng)我們梳理中發(fā)現(xiàn)，有一項(xiàng)登記，是用excel而不是業(yè)務(wù)系統(tǒng)來進(jìn)行的，那么在這里的where就可以表示為：excel文檔。
4、Document——那產(chǎn)生的這份文檔叫什么名字？也寫出來，代表有文件的傳遞，而以后要進(jìn)行信息化的話，此份人肉文檔也是需要被消除而被系統(tǒng)取代的。（相反，如果這項(xiàng)工作是在某個(gè)系統(tǒng)里操作的，where就可以寫成“人事系統(tǒng)”，文檔可以繼續(xù)存在，即該系統(tǒng)中的表單名稱：“員工登記表單”）
5、Condition——條件。在這種條件下，下一個(gè)活動還能夠繼續(xù)，即用邏輯鏈接線的方式來表示一項(xiàng)活動的輸入和輸出，指向某個(gè)活動的箭頭就表示此活動的前置輸入條件。
6、Dicision——決策。有些活動會產(chǎn)生一個(gè)條件判斷，根據(jù)不同的判斷結(jié)果從而走不同的分支流程。比如輸入員工信息的時(shí)候，可以根據(jù)員工之前是否就職過，選擇不同的流程，對于已經(jīng)就職過的，選用之前的工號而不用生成新的工號。
舉個(gè)案例（如果不太恰當(dāng)，請意會）。假設(shè)你受命要調(diào)研兩家餐飲店的業(yè)務(wù)流程，目的是給他們提供性價(jià)比最高的點(diǎn)餐系統(tǒng)。
在調(diào)研中：
你首先可以要求精通業(yè)務(wù)流程的人給你系統(tǒng)講解一遍。
調(diào)研具體操作的人，來驗(yàn)證他給你講解的是否全面和偏差。
實(shí)地觀察和記錄（花點(diǎn)時(shí)間走遍業(yè)務(wù)流程）
三種方式相互結(jié)合使用。第一種方法可以讓你首先建立一個(gè)系統(tǒng)觀，了解大體枝干，但是很難切入到可能會出現(xiàn)問題的細(xì)節(jié)。第二種方法太依賴于問題的質(zhì)量以及問問題的場景。有很多結(jié)論的不正確其實(shí)是因?yàn)閱栧e(cuò)了人或者問問題的方法不對。那么就需要借助第三種，在觀察中再進(jìn)行驗(yàn)證。
在這些問題中，就涉及到了“分單”，“切菜”，“擇菜”，”烹飪”，“傳菜”，“上菜”幾個(gè)活動，也涉及到了“服務(wù)員”，“廚師”，“助理”，“刀工”，“傳菜員”幾個(gè)角色。幾個(gè)活動的次序也比較清楚了。
下面的問題，可能廚師就不了解了，要問點(diǎn)菜員了。
你的調(diào)研和觀察使你擁有了“烹飪”所需的原材料。
接下來的任務(wù)是不是很簡單，對，就像填空題一樣簡單。將活動/事件按照一定的規(guī)則填到由部門和時(shí)間兩條維度決定的框框里。
這個(gè)階段是paper work，你需要將調(diào)研階段收集到的原材料用更直觀明了的方式呈現(xiàn)出來。從而能夠更好進(jìn)行評審和確認(rèn)。也為以后的流程評審和優(yōu)化做準(zhǔn)備。
不可能將所有的活動都放到一張圖里呈現(xiàn)。
“業(yè)務(wù)流程是有層次性的，這種層次體現(xiàn)在由上至下、由整體到部分、由宏觀到微觀、由抽象到具體的邏輯關(guān)系。這樣一個(gè)層次關(guān)系符合人們的思維習(xí)慣，有利于企業(yè)業(yè)務(wù)模型的建立 企業(yè)部門之間的層次關(guān)系表。一般來說，我們可以先建立主要業(yè)務(wù)流程的總體運(yùn)行過程（其中包括了整個(gè)企業(yè)的大的戰(zhàn)略），然后對其中的每項(xiàng)活動進(jìn)行細(xì)化，落實(shí)到各個(gè)部門的業(yè)務(wù)過程，建立相對獨(dú)立的子業(yè)務(wù)流程以及為其服務(wù)的輔助業(yè)務(wù)流程?！?/p>
——引自《百度百科》 業(yè)務(wù)流程詞條
對于很多新人來講， 業(yè)務(wù)最難的在于劃分業(yè)務(wù)流程圖的層次上。
首先，明確你要梳理的業(yè)務(wù)流程的范圍 ——用大的粗略的關(guān)鍵節(jié)點(diǎn)，講清楚這個(gè)業(yè)務(wù)流程范圍中的故事，就是頂層業(yè)務(wù)流程圖。你的頂層業(yè)務(wù)流程圖是業(yè)務(wù)全局故事的簡單表達(dá)，但是請注意這里的業(yè)務(wù)全局不見得是公司整體的業(yè)務(wù)全局，而是你界定好的業(yè)務(wù)范圍。比如，下圖是餐廳的日常運(yùn)作流程圖，若你界定的業(yè)務(wù)范圍是面向顧客的點(diǎn)餐和結(jié)帳流程，那么這就是頂層業(yè)務(wù)流程圖。但是若你界定的是整個(gè)餐廳的運(yùn)作業(yè)務(wù)流程，那這顯然還是一個(gè)子集——并沒有包含餐廳的采購、供應(yīng)商管理、一級庫存管理等工作。
其次，先從頂層的業(yè)務(wù)流程分解開始，由粗至細(xì)。 頂層業(yè)務(wù)流程圖的梳理原則：
1、界定范圍內(nèi)的業(yè)務(wù)全局故事。
2、包含該范圍內(nèi)的關(guān)鍵節(jié)點(diǎn)。并且，當(dāng)被質(zhì)疑說某某環(huán)節(jié)怎么不存在時(shí)，自己要清楚它在下一層分解中應(yīng)該被包含在那個(gè)關(guān)鍵節(jié)點(diǎn)中。比如，贈送10周年優(yōu)惠券，應(yīng)該會在結(jié)帳節(jié)點(diǎn)分解中出現(xiàn)。而打印分單，會在點(diǎn)菜節(jié)點(diǎn)中分解。而準(zhǔn)備兒童座椅應(yīng)該是接待入座環(huán)節(jié)。
3、頂層流程圖分解出來的關(guān)鍵節(jié)點(diǎn)未必都會細(xì)化分解下去，生成二級以及三級的流程圖。這要看該節(jié)點(diǎn)涉及到的“活動”以及“角色”是否復(fù)雜。
再看一個(gè)案例，對傳統(tǒng)生產(chǎn)型企業(yè)的進(jìn)銷存主業(yè)務(wù)流程進(jìn)行分解。橙色的代表被分解點(diǎn)，已經(jīng)可以分解為四層。當(dāng)我們分解到第四層，發(fā)現(xiàn)再往下去涉及到的活動和角色都已經(jīng)很少時(shí)，就不必再分解了，而是可以將第四層的關(guān)鍵節(jié)點(diǎn)直接作為第三層業(yè)務(wù)流程的“活動”，而不是子流程圖。
當(dāng)然，這是依賴于你梳理業(yè)務(wù)流程的目標(biāo)。如果你偏偏是要對“打樣”環(huán)節(jié)進(jìn)行剖析優(yōu)化，則還可以繼續(xù)分解下去。
這一步的工作會幫你建立出清晰的流程目錄結(jié)構(gòu)，如下圖所示是摘選于剛完成的一個(gè)流程梳理的項(xiàng)目中的目錄結(jié)構(gòu)部分。可以看到全圖即是頂層關(guān)鍵節(jié)點(diǎn)，作為老大，可能只要看這一層就夠了。下面則會對頂層做更多細(xì)化拆解。
“H3.樣品認(rèn)證”在頂層業(yè)務(wù)流程圖中，僅僅是一個(gè)“活動”，而在自己細(xì)化的這一個(gè)層次中，則會包含詳細(xì)的子活動一級參與者。
我常用的就是前兩行的“活動”，“判斷”，“邏輯關(guān)系線”，“起始與終止”，以及第二行的“子流程”，和“文件/表單”。如果你不是符號控，我建議這幾個(gè)就足夠了。
其中，“子流程”此圖示就是可以幫助你將流程分解得到的子流程能夠串聯(lián)起來，比如，當(dāng)在”A流程”中涉及到進(jìn)一步需要分解的”A1.1流程”時(shí)，就可以在”A流程”中用子流程符號代表“A1.1”。然后你的讀者就會明白要想進(jìn)一步了解”A1.1″應(yīng)該參考另外一個(gè)流程圖。
流程圖的常用結(jié)構(gòu)：
給大家看一些案例：
基本上包含大多數(shù)圖示的流程圖：
只用到少數(shù)幾個(gè)圖示畫的簡單流程圖（臺灣人的文檔中稱為程序圖——不過這里的程序不是指計(jì)算機(jī)程序，而是process，僅僅是體現(xiàn)任務(wù)之間的處理流程，所以使用極簡單的符號也不為怪了）：
以上兩個(gè)流程圖案例，從符號的復(fù)雜程度上來講，一個(gè)是完整流程圖，一個(gè)是基本流程圖，但是從表現(xiàn)形式來講，都屬于“泳道圖”——Swimlane。這也是我們最常用的一種表現(xiàn)形式了。泳道圖能夠很好體現(xiàn)部門或者角色在流程中的職責(zé)以及上下游的協(xié)作關(guān)系。且流程圖本身的標(biāo)準(zhǔn)容易掌握，達(dá)成共識也就更加容易。
驗(yàn)證你是否做到了以上的DO，以及規(guī)避了Donnot的做法是什么？
很好辦，及時(shí)與各位進(jìn)行評審。將各個(gè)涉眾都叫到一起，給他們看你梳理出來的成果。
這會發(fā)現(xiàn)一些有意思的事情，除了評審你的流程圖是否符合現(xiàn)實(shí)外，也會評審目前的業(yè)務(wù)流程是否符合理想。不同的部門和崗位的代表會在這個(gè)評審中，確認(rèn)當(dāng)前，也會相互提出意見，甚至吵起來，這不失于做流程優(yōu)化的一個(gè)很好的契機(jī)。暫且不表了。
軟件工程各種圖的區(qū)別
1.完成患者監(jiān)護(hù)系統(tǒng)功能級的數(shù)據(jù)流圖、實(shí)體聯(lián)系圖、軟件結(jié)構(gòu)圖。2.網(wǎng)上書店系統(tǒng),其外部用戶主要有游客、會員和管理員。其中,游客進(jìn)行注冊后,可以成為系統(tǒng)的會員,會員享有訂購圖書及訂單和書籍等信息查詢的功能,管理員可對系統(tǒng)的各種信息進(jìn)行管理和維護(hù)。根據(jù)上述描述,請畫出網(wǎng)上書店系統(tǒng)的:①基本系統(tǒng)模型(第0層);②功能級的數(shù)據(jù)流圖(第1層);③底層的訂購圖書數(shù)據(jù)流圖。1.把如下統(tǒng)計(jì)空格程序的Jackson圖改畫為等價(jià)的程序流程圖和盒圖。2、用Jackson圖描述下述的一列火車的構(gòu)成:一列火車最多有兩個(gè)火車頭。只有一個(gè)火車頭時(shí)則位于列車最前面
軟件開發(fā)中的各種流程圖有多種表示方法和形式，其中在
流程圖（Flow Chart）：使用圖形表示算法的思路是一種極好的方法，因?yàn)榍а匀f語不如一張圖。以特定的 圖形符號 加上說明，表示算法的圖，稱為流程圖或框圖。流程圖是流經(jīng)一個(gè)系統(tǒng)的信息流、觀點(diǎn)流或部件流的圖形代表。在企業(yè)中，流程圖主要用來說明某一過程。這種過程既可以是生產(chǎn)線上的工藝流程，也可以是完成一項(xiàng)任務(wù)必需的管理過程。例如，一張流程圖能夠成為解釋某個(gè)零件的制造工序，甚至組織決策制定程序的方式之一。這些過程的各個(gè)階段均用圖形塊表示，不同圖形塊之間以箭頭相連，代表它們在系統(tǒng)內(nèi)的流動方向。下一步何去何從，要取決于上一步的結(jié)果，典型做法是用“是”或“否”的邏輯分支加以判斷。流程圖是揭示和掌握封閉系統(tǒng)運(yùn)動狀況的有效方式。作為診斷工具，它能夠輔助決策制定，讓管理者清楚地知道，問題可能出在什么地方，從而確定出可供選擇的行動方案。流程圖有時(shí)也稱作輸入-輸出圖。該圖直觀地描述一個(gè)工作過程的具體步驟。流程圖對準(zhǔn)確了解事情是如何進(jìn)行的，以及決定應(yīng)如何改進(jìn)過程極有幫助。這一方法可以用于整個(gè)企業(yè)，以便直觀地跟蹤和圖解企業(yè)的運(yùn)作方式。流程圖使用一些標(biāo)準(zhǔn)符號代表某些類型的動作，如決策用菱形框表示，具體活動用方框表示。但比這些符號規(guī)定更重要的，是必須清楚地描述工作過程的順序。流程圖也可用于設(shè)計(jì)改進(jìn)工作過程，具體做法是先畫出事情應(yīng)該怎么做，再將其與實(shí)際情況進(jìn)行比較。
初識流程圖
一、什么是流程圖
二、產(chǎn)品經(jīng)理為什么畫流程圖
三、流程圖有哪些分類
1、業(yè)務(wù)流程圖（Transaction Flow Diagram, TFD）
抽象地描述事物進(jìn)行的次序和順序，不涉及具體操作與執(zhí)行細(xì)節(jié)。在互聯(lián)網(wǎng)軟件行業(yè)通人員都懂的共同常指脫離產(chǎn)品設(shè)計(jì)的用戶行為流程。業(yè)務(wù)流程圖是一種系統(tǒng)分析人員都懂的語言, 用來描述系統(tǒng)組織結(jié)構(gòu)、業(yè)務(wù)流程。
2、頁面流程圖（Page Flow Diagram）
指電子產(chǎn)品具體所呈現(xiàn)的頁面跳轉(zhuǎn)流程圖。其承載了業(yè)務(wù)流程圖所包含的業(yè)務(wù)流轉(zhuǎn)信息。
相較于一開始的極簡流程圖，現(xiàn)在的流程圖已經(jīng)漸漸變得復(fù)雜了一些。我們將抽象的業(yè)務(wù)，映射在了具象的頁面上，用軟件的頁面承載起了業(yè)務(wù)需求。
3、功能流程圖（Function Flow Diagram）
指單頁面內(nèi)或多頁面之間的功能操作流程，其包含在頁面流程中。
任何功能都是被包含在頁面內(nèi)的，但一個(gè)頁面內(nèi)往往不止一個(gè)功能，所以單單頁面流程圖可能無法完整表達(dá)所有流程，而這時(shí)就需要用功能流程圖來更加具體表達(dá)每個(gè)頁面內(nèi)所包含的功能。
4、數(shù)據(jù)流程圖（Data Flow Diagram）
特指軟件產(chǎn)品中，描述數(shù)據(jù)在不同節(jié)點(diǎn)被處理的過程所畫的圖表。主要表達(dá)計(jì)算機(jī)程序?qū)τ跇I(yè)務(wù)的實(shí)現(xiàn)原理。用戶在功能流程圖中的每一個(gè)操作，對應(yīng)都會反映在數(shù)據(jù)流程圖中。同時(shí)，數(shù)據(jù)流程圖也可以叫程序流程圖（Program Flow Diagram）。
它是一種能全面地描述信息系統(tǒng)邏輯模型的主要工具。它可以利用少數(shù)幾種符號綜合的反映出信息在系統(tǒng)中的流動、處理和存儲的情況。數(shù)據(jù)流程圖具有抽象性和概括性。
可能業(yè)務(wù)流程圖、頁面流程圖和功能流程圖大家都耳熟能詳，但數(shù)據(jù)流程圖恐怕了解的就比較少了。其實(shí)，每個(gè)流程圖中都有一個(gè)核心伴隨著不同操作在整個(gè)系統(tǒng)中不斷流轉(zhuǎn)。比如業(yè)務(wù)流程圖大多以人為核心，每個(gè)節(jié)點(diǎn)都是在傳遞人的不同行為。而頁面流程圖和功能流程圖也類似，都是以人的操作行為為核心，在不同頁面和功能間進(jìn)行流轉(zhuǎn)。但數(shù)據(jù)流程圖不同，它是以數(shù)據(jù)為核心，展示整個(gè)系統(tǒng)中，數(shù)據(jù)是如何被處理的。
其更偏技術(shù)思維，更多的是展現(xiàn)后臺程序的實(shí)現(xiàn)原理。所以，常常是開發(fā)人員繪制此圖，而產(chǎn)品經(jīng)理涉及較少。但隨著產(chǎn)品經(jīng)理地不斷成長，向上提高到戰(zhàn)略層，而向下則會深入到實(shí)現(xiàn)層。理解程序的開發(fā)原理和背后的數(shù)據(jù)流轉(zhuǎn)，無疑會讓產(chǎn)品經(jīng)理對產(chǎn)品設(shè)計(jì)有更加深刻的理解。
四、流程圖的顆粒度
關(guān)于軟件開發(fā)流程圖符號含義和軟件編寫流程圖的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。
