做軟體中的管理的思考大綱草稿

如何做軟體項目

這裡以企業應用管理型軟體項目為基礎考慮展開。

做軟體項目的一般流程及包含步驟

一般包括需求調研，可行性分析，需求分析，設計，編碼，測試，釋出，教育訓練，維護，改進更新等。

最開始從項目意向提出算起。

       項目負責人初步排定項目整體計劃。

也有可能在其它步驟之後，比如需求調研之後再排定或修正項目整體計劃。其它一些意外情況也有可能導緻項目計劃的調整。

       初步組建團隊。

需求調研。

與有關使用者開會溝通，了解使用者需求，以及讓使用者教育訓練講解業務知識，形成一定的前期準備文檔。

需求分析。

計劃的排定，期限的給出，跟蹤追查進度。

不一定很準确，但是可以在做計劃過程中初步明确待做事項，能夠初步控管進度。

需要采集需求分析相關任務實際執行的資料，比如實際執行時間，以及細化任務事項，比如做什麼地方時花費了多少時間，細節一些當然好，不過需要權衡。這些東西都是經驗資料，可以事後加以分析，然後可供以後類似事情的計劃制定作參考。

如果發現遺漏的任務事項需要及時補充并調整計劃。

業務流程梳理，可行性分析。

業務支援考慮，初步設計考慮，技術調研，對大體方案、架構、主要技術的選用确定。

業務步驟細化，業務所需資料分析整理（其實是初步進行了業務資料庫設計），資料流圖的整理，使業務資料的流向及如何使用比較清楚。

産出需求規格說明書，包括前面提到部分，以及對業務要點的支援規格或形式說明，一些名額的制定。

注意不光有業務需求，還有系統管理需求等。

必要時提供原型（這需要一定的開發技能），或者操作步驟大緻說明文檔。

在寫需求書時要注意考慮，如何讓使用者很好的了解需求規格說明書。是采用規定式的語言，還是給出比較詳細的操作界面或操作步驟，或是提供原型示範？另外，注意評審需求規格書的人分幾類，有直接使用者，使用者的上級上司，自己的上級上司等，不同的人關注點不太一樣。

需求分析中也需考慮到一些設計層面的東西，比如要規定說說明操作方式操作界面上的具體要求，則應該與目前（掌握到的）技術所能支援的程度基本一緻，不然會給設計實作造成很大困擾，導緻需求與設計實作嚴重脫節。要麼就是不要對具體操作要求作出規定，隻是規定要能做到什麼，具體怎麼做留給詳細設計。如果要提供原型，倒是一定程度上能解決這個問題。

還有，需求分析中有無必要比較深入的到設計及實作層面去考慮問題，比如一些功能點能否支援實作？需求規格書一旦以合同的形式通過，到後面如果一些需求發現支援不了，如何能避免違約損失而糾正需求？（當然，合同條款如何制定也是很有技術含量的事情，但這裡限于經驗沒法展開讨論。）這似乎要求一開始在作需求的時候就要想好大體設計實作，以免承諾無法實作的需求。如果是客戶需求提得不夠正确，也許還能說服客戶。

讓使用者确認需求。

       可以考慮先把需求規格說明書通過郵件發給使用者看。然後約定時間開會讨論評審。

       如果使用者能夠在會前及時給出回報，可以再修改補充。這樣開會的效率更高。

       開會評審需求規格說明書，或者通過原型等在會上向使用者示範。

       一般一次開會難以形成最終需求書版本。這時還有一些修改，以及單獨找相關使用者讨論。

       修改後的需求規格說明書再通過郵件等發送給使用者，如果使用者能夠确認下來即定稿。或者再開會讨論評審。反複進行，一般一兩次即到最終定稿。

       其它可并行的事情。比如讓組員了解需求或參與一定的需求分析。以及調研一些技術難點，或者做一些專業技術上的教育訓練或學習。或者一些設計的并行啟動。

設計。

計劃的排定，期限的給出，跟蹤追查進度。

不一定很準确，但是可以在做計劃過程中初步明确待做事項，能夠初步控管進度。

需要采集設計相關任務實際執行的資料，比如實際執行時間，以及細化任務事項，比如做什麼地方時花費了多少時間。事後加以分析，得到經驗供以後參考。

研究需求規格說明書，了解業務以及準備支援業務到什麼程度。（如果做需求與做設計不是同一個人，就有必要）

對于業務支援的大體方案，業務架構，軟體架構，軟體實作所需主要技術的選用确定。

重點難點的設計思路，一些算法的給出。

對象關系圖或類圖設計的重要性如何？

資料庫設計，分業務和系統管理等方面。（參見下面的通用功能或目标）（重點是業務資料方面，系統管理方面可以抽其它時間并行處理）

同時審視需求文檔，看看有無考慮漏掉或錯誤的需要回報。

詳細設計。

一些業務功能在具體操作及界面上如何支援，以及給出實作思路的僞碼邏輯描述。rational rose中的序列圖的表現能力還是差了些。

       給出這些業務功能的僞碼邏輯意味着一件事情，編碼者或開發者的水準有限，不能根據較高層次的成果很好的開展工作。

僞碼邏輯描述要細到什麼程度，以及要不要所有的功能都給出實作思路僞碼，這需要根據編碼者的水準而定，另外也需要權衡。

基礎資料設計準備。

老的業務資料的轉換考慮。

設計成果評審。

其它可并行的事情。比如讓組員熟悉需求文檔，了解業務，準備技術。有技術能力強的人還可以做做代碼架構搭建。以及進行一些通用功能的開發。或者一定程度參與設計工作，比如可以做自己所可能負責子產品的僞碼邏輯。

編碼相關的設計

       計劃制定？一般實作資料的采集還是有必要的。

       要注意考慮可重用性的問題，包括源代碼層次的以及dll層次的。

       代碼架構的搭建。

劃分縱向層次關系，（以利于減少備援，提高複用性），比如從粗的來說就有基礎通用公共層，資料通路層，業務邏輯層，界面層等。對功能業務還要劃分子產品，（以利于團隊并行開發）。

資料通路的技術的選用确定及架構或使用方式設計，公共類及方法的提取，寫點實用例子給定使用方式的模式。

搭建界面架構以利于後面的團隊并行開發。

如果是CS程式，一些公共參數的擷取方式或傳遞方式的考慮，各個界面部分如何聯系考慮。BS程式在界面上的各個部分聯系得稍微少一點，簡單一點。

一些像自動菜單生成的功能可能需要預先開發。

其它一些需要考慮之處，參見下面的通用功能或目标。

如果能夠有一個比較成熟的代碼架構，直接套用，是最好的一種方式。

       一些成熟的（在其它項目中經過實際使用檢驗過的）公共函數及資料結構等基礎類庫搬過來，從源代碼級到二進制級的利用。

給出代碼規範。

       對代碼架構給出說明文檔，說明各個子產品負責的功能範圍，說明一些技術怎麼利用實作，必要時給出例子。說明公共類及函數及常量的放置規則。

組員在此時的并行任務考慮，可以做些什麼事情？可以閱讀設計文檔，以及閱讀代碼架構說明文檔及源代碼，學習必要的開發技術或測試技術，教育訓練等價類的劃分思路，以及針對可能分給他（她）的功能進行從界面安排組織到實作思路的考慮。（這時也需要初步排定開發任務）。

編碼開發。

計劃的排定，期限的給出。

              列出開發相關功能清單，估計工作量，安排任務到人，注意考慮難度和任務本身的邏輯先後的問題，規定好任務實作的先後順序。任務安排細節清單回顧調整，注意關聯順序，以便流暢開發，也為測試考慮。

另外，進度如何保證，是每個任務都去追查呢，還是一批任務給一個期限，後一種似乎更可取。

還有，任務的工作量包括哪些方面的内容的問題，是隻包括開發時間和自己測試時間，還是說改bug的時間也考慮在内？另外，注意改bug的時間必然是有分段，不連續的，這樣完成任務以什麼為辨別，是否應該考慮得很細，比如初次開發完成所用時間，最後測試通過所用時間，裡程碑如何劃分？……

團隊開發。

       注意團隊開發前的準備工作，參見前面的設計中的一些工作。以及可能要給出一點典型功能的比較完整實作的例子，如果擔心編碼者水準的話，本來一般來說給出代碼片段例子再輔以說明文檔是夠用的。

跟蹤追查進度，檢查資料的采集。組員的每日進度彙報，詳細到任務段，需采集的資料的填寫。這需要任務管理工具作支援。

每日編譯，源代碼版本及時管理。

及時進行代碼檢查，同時對功能大概進行檢查。一般每人開發的第一二個功能檢查，後面的功能抽查，重難點功能檢查。

個人自己測試的測試用例思路檢查或抽查。

送出功能集合給測試方，等傳回bug配置設定修改，并行進行開發。

       修改bug的一些資料的采集的填寫及檢查或抽查。

臨時情況導緻的任務調整或追加。

測試。

       （限于經驗沒有詳細展開。）

       計劃的排定。（需要一定程度依賴于開發計劃）

       測試用例編寫。

       測試基礎資料的準備。

       自動測試工具如何使用？

       開發組分批送出功能測試而具體進行測試。

       開發組改bug及送出其它新功能進行測試。

       測試任務的執行記錄的資料采集，以及進度跟蹤控制。

       測試計劃的調整。

       內建測試。

       性能測試。

       其他測試，比如相容性，安裝，更新腳本測試。

使用者教育訓練。

       使用說明書的編寫。

       教育訓練計劃的安排。

              安排專人準備示範系統。

釋出。

       （計劃在前面排定或調整。）

       準備安裝程式，或寫釋出時的詳細操作手冊。

       寫使用說明書。作教育訓練計劃及安排。

       釋出最初系統或釋出更新系統。

       使用者教育訓練。

       使用者試用或正式使用。

維護，更新檔版及更新版的項目啟動。

       使用者回報bug，或提出修改意見，或新的需求。

       再排計劃。

       改bug。

       針對新需求，從需求分析、設計、開發、測試，一步步下來。最後釋出更新版本。

其它

       版本庫的管理，檔案的擱放位置規定。

              代碼及文檔的版本控管

       經驗知識的整理及管理

       計劃安排，進度控管

業務軟體的一些通用功能或目标

組織架構等基礎資料的設計，組織架構變遷的考慮及支援程度。

功能權限設計、資料權限設計、權限使用。

根據權限自動生成菜單。

一些系統性業務資料的清單或樹形的通用維護。

身份驗證，加密技術，安全性考慮。

版權控制，使用者數控制。代碼的安全控制（如反反編譯）。軟體版權方面的法律。

自動更新。

以及注意新版代碼與新版資料結構的配套設計或安排。

還要注意資料内容中包含資料結構的，如何在前期設計能夠向下相容，進而在新版代碼中能夠向上相容。要特别注意序列化類對象導緻固化版本的後果。比如一個舊的類對象被序列化為資料存儲起來，而又反序列化為新版的類對象的後果會是如何。

安裝部署。

列印支援，報表工具。

       導出資料，如果界面上清單控件不支援“複制——粘貼”的話。

簡單消息，郵件通知。

       簡單消息指純粹通知，可能加上很有限的跳轉。

各種分辨率的設計支援。

異常、提示、日志

對于錯誤及異常的提示消息的友好及有效性。

達到自包含幫助的層次。能夠指導使用者正确完成操作，或讓使用者知道該找别的使用者完成先決條件的操作，盡量減少使用者對技術支援人員的依賴。

異常處理機制的設計，對一般錯誤的通用簡單處理。錯誤消息提示可能要制定一點标準規範。

支援運作時查錯。

盡量使運作時出錯易分析追蹤。因為一般來說，這樣的bug一般難于重制或發現，而且也不太可能在正式的伺服器上進行調試。這時隻能依賴詳細的運作時日志記錄了。

這裡的日志記錄是程式級的（而不是使用者操作級的，下面會提到）。

程式級日志記錄的标準規範，當出錯時哪些資訊要寫入日志，除了Exception中的消息及堆棧，引發Exception的調用處的重要變量的值的情況如何記錄。（特定地方的日志記錄細緻程度。）

其它錯誤相關：

       容錯問題，

不要為一點錯誤資料影響其它，比如一個錯誤導緻系統的正常業務流程都走不下去了，或者允許修改，改正錯誤後正常進行。

其他提示相關：

       使用者提示的友好性，

              比如遇到耗時操作，能夠提示使用者耐心等待，而不至于讓使用者感覺系統崩潰。

其他日志相關：

       使用者操作級的日志的記錄詳細程度的設計或規定。什麼使用者，什麼時間，什麼子產品、功能、操作，操作了哪些資料行，對于各資料行中的哪些資料列進行了操作。      

支援調試性

       至少在Visual Studio .Net 2005中的C#開發中，如果沒有異常處理，則出錯時IDE會自動定位到出錯語句，而如果給包含出錯語句的某段代碼在任何外面層級加了try—catch語句，則出錯時IDE會自動定位到catch語句處，反而不友善調試，這個需要研究如何既有異常處理，又能充分利用IDE的調試功能。

支援測試性。

       友善開發人員自己測試，友善測試人員手動測試及自動測試。

比如一些樹狀資料是折疊的，要檢查資料内容的正确性需要全部展開，而業務要求又是折疊的，即開發者測試者的需求跟使用者的需求稍有差别時，進而可以考慮用參數配置等解決這個問題。

       這有待有更多經驗後再讨論。

系統資料的一緻性的保持的設計考慮。在各種可能出錯的場合。

性能支援問題，分頁技術，資料庫通路技術及方式的綜合考慮。

內建性考慮。內建其它系統或被其它系統內建，或為其它系統提供接口。

多資料庫支援。

國際化考慮，多語言支援，多貨币支援，時區支援。

脫機處理及資料導入，分布式設計考慮及資料整合。

熱更新程式版本。

多作業系統支援，可移植性。

使用者的自定義習慣的儲存。如查詢條件，每頁大小，界面布局，等等。

可配置性，（哪些東西需要配置需要具體問題具體分析）。

代碼相關

       架構設計相關

              可擴充性。功能需求增加的友善性，不至于改個地方傷筋動骨。

              可重用性，從源代碼層次到可執行代碼層次。

       重用也導緻精簡。

       代碼的精簡性（盡量減少備援，把重複代碼都合理劃分，提出具有或多或少公共性的函數）。

       代碼的短小性（不要一個函數包含太長的代碼，一些代碼塊可以根據功能意義提成一個函數，也可備以後重用）（或者就在詳細設計時進行劃分？）

       代碼的可讀性，自包含文檔度（從函數，參數，變量等的取名，到一定的注釋）。

       可維護性，   

易使用性。

       比如輸入時進行校驗，或者提供選擇資料方式使使用者能輸入正确的資料。業務規則的友好提示，達到通過提示資訊就能引導使用者能夠正确輸入資料。

       粘貼複制的支援。

       友善使用者輸入有相關性的資料。以及批量輸入及修改資料。

支援工具

版本管理工具

進度安排及跟蹤工具

bug管理工具

寫文檔工具

做需求的支援工具

做設計的支援工具

              實體——對象模組化工具

開發工具

       內建開發環境

測試工具

       自動測試工具

       性能測試工具

對人的技能及素質的要求

分情況考慮，按角色分：需求分析師，設計師，代碼架構師，開發組長，開發組員，測試組長，測試組員。待以後補充。

一些定性定量名額

不一定隻指軟體系統，一般指軟硬體結合的系統。待豐富完善。

内在品質方面

       正确性。

              設計邏輯的正确性，程式實作上的正确性。

              可靠性。……

              業務周密性。

                     一些細緻的功能會不會在設計時被漏掉，到具體用的時候才發現沒有，導緻沒法用或用起來很麻煩。

                     界面操作上的改錯能力。比如輸入錯誤的資料，能夠通過系統提供的操作進行改正，而不是改正不了。

              資料完整性的可靠性。比如斷電或并發性操作導緻資料完整性被或多或少破壞。

       性能方面

              一定硬體配置條件下的并發使用者數，操作的吞吐量，響應時間。

              資料量上限支援，預計可使用壽命。

              性能擴充支援。最大并發使用者數，操作的吞吐量。

              穩定性。比如可以一直運作不必重新開機。

       安全性。

              操作方面的權限設計周密，沒有漏洞。

              程式實作的内在安全，能夠防止黑客侵入系統或直接侵入資料或竊取密碼。

              程式布署管理上的安全。比如一些帶有密碼的配置資訊是加密的，不會被機器管理者所輕易取到。

              操作上的可追查性，如果出了事故能夠根據操作記錄追查到責任人。

功能方面：

       可配置性。

              能夠通過參數，配置界面，腳本等豐富系統功能，或者具有強大的二次開發支援。可以适應業務在相當大範圍内的發展變更。比如自定義各種報表，自定義業務流程，等等。           業務發展的支援壽命。

              通過配置能夠支援一個最大業務範圍，在目前業務發展到這個範圍之外預計需要時間的量。

       脫機處理支援

       分布式支援。

       并發性控制問題。比如兩個人同時操作一份資料會出現什麼情況。可不可能兩個人同時操作一份資料。

       各種顯示裝置的支援能力。比如不同分辨率。

使用者使用方面

       使用者友好度。界面及提示自包含幫助，讓使用者能夠不經專門教育訓練即能使用系統。

       界面操作的友善程度，比如支援鍵盤滑鼠及其他輸入裝置，支援拷貝粘貼，批量操作，……。

       界面美觀程度。

       相關資料的輸入的操作的簡便。

維護更新方面

       可擴充性，易擴充性。

              在哪些方面擴充，世界範圍内使用，多語言，多貨币，多資料庫。增加功能，增加要求，……。

       可維護性，易維護性。

              文檔的完備及詳細，接口豐富，支援二次開發。或者子產品代碼組織劃分得好，可讀性強，支援源代碼級修改更新。

       可內建性，

              能夠內建其他系統資料或支援被其他系統內建，也是一種擴充了。

       可複用性，通用性，子產品性

       可移植性，

其它

       耗費時間量，耗費工作量，耗費成本，

       程式規模，按代碼行或功能點來算。機關規模程式耗費量

       程式價值，機關耗費産出價值

如何控管以及統計資料

如何計劃安排任務及控管

Project軟體中的計劃時間與實際完成時間不分的原理？

可能需要兩份project檔，一份制定計劃，一份記錄完成，然後拿計劃安排與完成情況來對比。

另外project檔中能夠記錄的東西不太方面，需要專門有系統或excel檔來記錄任務完成的詳細資訊。

如何盡可能高效的監管控管

重點難點的特别關注，找準重點難點。設計實作思路的掌控。

進度跟蹤，發現耗時不正常的地方及時了解情況，了解原因，給出對策。

專人對某些方面進行專門檢查。比如設立專門的品質小組。

分級檢查。比如組長檢查老兵，老兵檢查新人。抽查。

及時的代碼回顧。

每日編譯。

每次檢查的文檔記錄。經驗總結。

如何評價項目成果及做事的人的績效

如何評價項目

       參見前面的名額部分。

項目代價的統計

       需要統計出所有參與者在這個項目中總共投入的工作量以及等待的時間量。進而得到項目的兩個代價，一個是實際耗費總代價，一個是實際耗費有效代價。

如何評價人：

       可以根據其完成任務的情況來衡量。包括量及品質等。

       每個參與者，做了多少任務，完成了多少标準工作量，實際付出了多少工作量，公司實際付出了多少成本，個人做事的品質如何，對于個人的其他名額的評價。

       任務有一個标準工作量，考慮用經驗方法給出或者别的方法給出。如果統計得足夠詳細，可以得出一個開發者徹底完成一個任務的工作量，一般包括開發時間量和改bug時間量。還可以得出這個任務總共耗費工作量，即開發者實際耗費工作量加上測試者耗費工作量。測試者要得出測試這個任務的單次全面測試工作量以及由于出現bug的追加測試工作量。

       另外，對于任務的完成在開發方還有一個内行品質的評價，具體名額參數待定。可以想到的有代碼的規範性，可讀性，代碼的自注釋程度，代碼的精簡程度，代碼的複用程度，代碼的備援程度，功能函數的提取程度，正确性，等等。

              另外，這些代碼的名額總體上與個人的開發效率有聯系。而品質及正确性則與改bug的工作量有聯系。

              再有，可以考慮抓某種bug率來督促個人提高開發品質。比如标準工作量與改bug工作量的權重計算後的值之比。

       得到這些資料後，可以用開發者對其負責的那些任務的實際完成工作量總和與标準工作量總和的絕對值以及比例來對其績效作出一定量化的衡量。

       另外，還可以把開發者導緻的追加的測試工作量考慮進來以量化其績效。還可以把開發者完成任務的品質得分考慮進來影響績效計算。      

不過，标準工作量的公平給定是個很難的問題。畢竟，不同任務有不同難度，水準低于某難度要求的開發者耗費再多時間也難以完成任務。這需要另外一套評價估量體系。

還有一種考慮角度，是把工作量不用時間來量度，而用金錢來量度，如何評價一個任務的貨币價值，也是很難的。

需要采集哪些資料

每個人處理單個任務的時間量，實際處理可能分幾段。還要分類型。是初次開發還是由于改bug。一個任務改了幾個bug，每個bug改了幾次。

任務的标準量的給出。

任務完成品質的分數的給出。名額待定。

其他

對于面向對象的批駁：

       現實中，最容易想到的是資料集合，資料流圖等東西，而如何劃分資料集合，使思路清晰，減少備援資料，應該因地制宜，使用最合适的方法，而一味套用面向對象的思路則是生搬硬套。

另外，如何抓住要點用最好的方式向别人（比如使用者）解釋說明清楚一些東西，所使用的方式也是因地制宜的，用rational rose中的那一套也是生搬硬套。