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