- 翻譯公司資訊
-
世聯(lián)翻譯公司完成安全系統(tǒng)中文翻譯
發(fā)布時間：2018-02-12 08:46 點擊：
世聯(lián)翻譯公司完成安全系統(tǒng)中文翻譯
- 目的：
- 建議：
-
需要增強輔助工具.
- 定義：能夠提高工作效率（減少錯誤、降低重復(fù)性工作難度和時間）的非產(chǎn)品核心的工具。
- 事例：安裝過程需要配置文件（這可能會因為安裝人員不熟悉技術(shù)或者操作系統(tǒng)而增長了安裝的時間并容易產(chǎn)生錯誤，還有培訓(xùn)新員工的成本也比較高。安裝人員，需要對linux的了解、需要熟悉我們的系統(tǒng)、需要對照篇幅較長的說明）。
- 建議：對于重復(fù)性的復(fù)雜的工作，我們一次性投入資源進行輔助性工具的開發(fā).
-
好處：
- 減少持續(xù)性投入成本。
- 縮短重復(fù)性工作的時間。
- 降低人工出錯的可能。
- 降低對安裝人員技術(shù)和水平的要求。
- 減少培訓(xùn)成本。
- 簡化了復(fù)雜的工作，縮短幫助手冊的篇幅。
-
缺點：
- 增加了非核心功能的投入（分析、開發(fā)、測試、文檔）。
- 需要定期維護工具。（新需求、需求變化等）
-
分析和總結(jié)：
- 從上邊的優(yōu)缺點對比中，我們看出大部分重復(fù)性、操作復(fù)雜的工作，我們都可以用一次性的投入換來較大的收益。我們只要識別出這些工作并進行輔助工具的開發(fā)來解決這些問題。
-
關(guān)于工作模式。
- 環(huán)境：由于現(xiàn)今的商業(yè)化軟件需求趨于復(fù)雜化，定制化，需求膨脹和需求快速變化成為了一個很大的問題。
- 分析：我對于這種現(xiàn)狀提出了一個比較好的實現(xiàn)方式，這并不一定特別的適合我們現(xiàn)有的工作模式，但是我希望其中的一些優(yōu)秀的實踐方法可以作為我們的參考。
- 工作模式流程圖：
-
解釋：上邊圖例中，左側(cè)是瀑布模型的簡單圖例，右邊是基于XP極限編程的一種開發(fā)模式實踐
-
需求分析：
- 首先理解用戶需求，將其梳理成軟件需求列表。
-
需求分類
- 關(guān)鍵需求（高風(fēng)險、復(fù)雜）10%，影響項目成敗，需要盡早處理，減低風(fēng)險，合理評估項目計劃的關(guān)鍵。
- 主要需求20%，項目的主體，不容易發(fā)生改變，完成將增加士氣。
- 高增值需求 40%，低投入高產(chǎn)出（易用性等需求），盡量不在第一迭代處理，完成將增加用戶滿意度。
- 低增值需求20%，高投入低產(chǎn)出（用戶可能不會使用的功能），盡量延遲開發(fā)，時間緊迫的情況下，有時到后期客戶自己就會主動放棄這些需求。
- 錯誤需求：不應(yīng)該做的需求和客戶也沒有描述清楚，或者他自己也沒有想明白的需求。這部分如果是不應(yīng)該做的需求就用延遲開發(fā)的辦法處理，如果是不明確的需求要等到和用戶明確了需求，再重新分類到其他類型中。(當(dāng)然為了避免無必要的爭執(zhí)，我們一般是不會對用戶說這是錯誤的需求的，我們可以告訴他這是低附加值的需求，到項目后期，隨著他們對項目的了解，他們會明白的)。
- 做迭代計劃，大約以1周到1個月甚至幾個月為1迭代（這要視工程的規(guī)模決定）大概3-5個迭代是比較適宜的。
-
需求分析：
中間的迭代我們應(yīng)該根據(jù)需求的優(yōu)先級進行分配，先完成高附加值的需求，而推延低附加值的需求，這點客戶是可以接受的。隨著項目的推進，客戶也越來越明白他們自己想要的是什么，當(dāng)他看到主要功能和高附加值功能都很好的運行時，我們把關(guān)注點集中在低附加值的需求上，這時客戶往往會根據(jù)成本（主要指時間）和產(chǎn)出比，做出比較合理的取舍。
- 接下來我們做項目的初步架構(gòu)，這次架構(gòu)應(yīng)盡可能考慮到可擴展性、易維護性、易測試性、安全等軟件指標，然后在項目迭代過程中，不斷反思和完善架構(gòu)。
-
迭代（開發(fā)組）
- 首先是修改上一次迭代中測試組提出的問題。
- 然后進行關(guān)于本次迭代的細致需求分析。
- 然后進行軟件設(shè)計。
- 當(dāng)設(shè)計遇到不好處理的情況時，重新審視我們的架構(gòu)，并在需求時，重構(gòu)。
- 進行組件層的白盒單元測試（組件好比一臺機器的零件），由于它是業(yè)務(wù)無關(guān)的，所以功能穩(wěn)定，開發(fā)組能夠更好的測試它保證質(zhì)量(代碼和測試代碼的時間投入比例大約是1:1的)，這將覆蓋代碼路徑測試和邊界測試等白盒單元測試相關(guān)的情況。
- 定期進行代碼審查和走查工作，這將保證代碼質(zhì)量在一定得級別以上，并可以提高初級員工的能力。
- 提交本迭代的代碼給測試組。
-
迭代（測試組）
- 測試用例設(shè)計（主要關(guān)注在邏輯組件層），這是業(yè)務(wù)相關(guān)也容易變化的，測試人員要根據(jù)需求的變化不斷的更新。這要覆蓋正常流程異常流程，覆蓋所有業(yè)務(wù)分支。
- 測試上一個迭代的產(chǎn)品。
- 回歸測試。
- 提交測試報告（BUG列表）。
- 提交一個迭代的產(chǎn)品給客戶（給他們信心和信任，并階段性的給他們一個逐步深入了解真實需求的機會）
- 對下個迭代進行初步的分析，并用圖形的方式（只是畫圖而不用代碼）把我們的想法提前可客戶進行交流，盡可能早的取得下一個迭代功能相關(guān)的真實需求。
- 總結(jié)本迭代遇到的問題，并考慮應(yīng)對方法，在下一個迭代進行實踐來驗證他。
- 迭代結(jié)束，定期的慶祝一下給項目的成員信心，并稍微緩解下大家緊繃神經(jīng)，讓大家調(diào)整好狀態(tài)，以應(yīng)對下一個迭代。
- 當(dāng)所有迭代都結(jié)束時，可能還有一些維護工作。其實在迭代過程中已經(jīng)在進行DEBUG等維護工作，如果剩下的需求很多。（這將是一個新的項目，有新的合同和新的收入，我們不應(yīng)該無償?shù)淖鎏囝~外的工作，除非我們認為值得）。
-
關(guān)于軟件設(shè)計方面，在需求變化快速的今天，我們要適當(dāng)?shù)脑黾涌蓴U展性和易維護性的投入。無論什么項目都有相對固定的部分、相對變化的部分，我們在容易變化的部分的設(shè)計投入將會降低我們因為變化產(chǎn)生的成本。下邊我會舉一個設(shè)計的例子用來說明這個問題。
- 需求：軟件工作流
- 場景：流程經(jīng)常變化、會增加新的工作節(jié)點
- 類圖和構(gòu)建圖（只是為了說明問題的簡化設(shè)計）
-
說明：
- 首先把實際的工作流節(jié)點從主流程中抽離出來，采用接口模式以庫的形式動態(tài)加載，能夠解決新增工作流的問題。
- 另外用工具可視化編輯工作流能力降低配置的風(fēng)險（手工錯誤）和減少時間、降低配置難度。
-
一些非功能性的內(nèi)部需求（區(qū)別于用戶需求）：
- 可擴展性，在易發(fā)生變化的部分，利用設(shè)計模式做一些可擴展的設(shè)計，這雖然會增加設(shè)計的難度，增加開發(fā)的時間，但是當(dāng)你發(fā)現(xiàn)一個新的需求或者需求變更，因為我們的設(shè)計只用配置或者很少的很獨立的代碼就可以解決時，你將會覺得這個設(shè)計時超值的。
- 易維護性，在經(jīng)常需要維護的部分增加設(shè)計。比如說：一個日志服務(wù)，能讓我們方便的記錄和查詢想要的日志信息，這個組件就是很有意義的。再舉個例子，有的 XML文件需要經(jīng)常的修改（關(guān)于用戶界面樣式的定制配置文件），我們寫一個工具去可視化的配置，能夠提高這種效率。
- 易測試性，我們需要白盒測試的組件，不光需要容易看懂，而且需要容易測試，這方面的工作，有時會同時達到高內(nèi)聚低耦合的高質(zhì)量設(shè)計的效果。
- 安全性，安全性需求要盡早進行分析，當(dāng)項目已經(jīng)完成時，你再想提高他就難了。比如數(shù)據(jù)傳輸保密性、權(quán)限控制…
-
建議采取的其他實踐：
- 結(jié)對編程測試，兩個人互相寫對方的白盒測試，互相代碼審查。
- 市場人員，架構(gòu)設(shè)計師，主要開發(fā)人員、測試經(jīng)理和客戶定期的交流討論，可以拉近大家的距離并達到集思廣益的效果。
- 定期代碼走查，將提高整體團隊的水平并讓更多人熟悉別人完成的部分。
- 我的建議包括了，在需求變動頻繁年代中，我所遇到或者聽到的問題的解決建議，有些來自cogent，有些來自其他公司，可能這并不能很適當(dāng)?shù)膽?yīng)對我們現(xiàn)在遇到的問題。但很喜歡我們公司主動去了解分析并嘗試解決問題的工作態(tài)度。有什么針對性的問題嗎，或者以后以郵件或者其他形式交流，我希望morpho中國能為整個公司發(fā)揮更大的作用。世聯(lián)翻譯公司完成安全系統(tǒng)中文翻譯
