第一節 發現項目機會

§客戶的需求和問題就是選擇項目的依據，是項目投資機會。 §通常投資者是從以下幾個方面發現項目投資機會：

1.市場需求。進行市場分析，客觀地分析市場現狀（市場容量的大小，供求情況），預測未來市場的發展趨勢（高速成長，平穩發展，還是逐漸衰退），了解主要競爭對手的產品、市場份額和發展戰略。

2.國家政策和產業導向。國家、行業和地方的科技發展和經濟社會發展的長期規劃與階段性規劃，這些規劃一般由國務院、各部委、地方政府和主管廳局發布。國內企業應重視這些政策規劃。

3.客戶發布的項目招標。及時得到行業中客戶單位的招標信息，進行可行性分析并投標。

第二節 可行性分析

§識別出的項目機會只能作為候選項目，還必須對其進行可行性分析，才能確定能否將其作為一個項目來實施。 §技術可行性分析的目的是確定能否利用現有的或可能擁有的技術能力來實現項目目標。

2.1 技術可行性分析

§1.項目總體技術方案分析。分析項目所采用的技術方案是否合理，包括項目所依據的技術原理，主要技術、方法和過程，項目擬采用的質量標準等。 §2.軟件組織水平與能力分析。 l研發能力：技術水平，研發成果； l生產和市場營銷能力； l資金管理能力：資金回收和支付，銀行貸款； l其它能力：已獲得的各種認證和資質。 §3.項目技術來源分析。l自主研發：擁有完全的自主知識產權和決策權；l合作開發：要明確技術成果的所有權和使用權；l使用其它組織或個人的技術（包括開源軟件）。如果使用了專利，要進行專利分析。§4.項目負責人及技術骨干的資質分析。項目負責人和技術骨干的學歷、專業、職稱、行業資質、項目研發經歷、近期主要研發成果、獲得的主要獎勵等。§例如，系統集成商必須具有一定的人員資質，如系統集成商三級要求：§企業從事軟件開發、系統集成等業務的工程技術人員不少于100人，且本科學歷人員所占比例不少于80%。§企業總經理或負責系統集成工作的副總經理具有4年以上從事信息技術領域企業管理工作經歷；企業具有已獲得信息技術相關專業高級職稱，且從事計算機信息系統集成工作不少于4年的技術負責人。

2.2 使用開源軟件

§開源軟件經過三十多年的發展，已經異常豐富。§使用開源軟件的好處：?(1)節省成本，提高開發效率。?(2)開放和自由。開源軟件通常符合開放標準，使用戶不會被個別商業公司的專有標準束縛。例如，OpenOffice符合開放標準OpenDocument Format，使用戶對自己的文檔有完全意義上的所有權。微軟被迫公開了OOXML格式并力推其成為開放標準。?(3) 靈活可定制。擁有源代碼，可以進行定制、修改和擴展。?(4) 公開透明。適用于涉及國家或商業安全的領域。?(5) 良好的學習平臺。通過閱讀源代碼、文檔、社區網站上的討論等，可以理解開源軟件的架構、設計，觀察技術決定的決策過程等，對于開發人員技術水平的提高有很大促進作用。

2.2.1 尋找合適的開源軟件

§除使用通用搜索引擎外，還可以使用一些專業性網站提供的目錄和搜索服務。例如：§www.osalt.com，一家專門針對現有的商業軟件來推薦相應的開源軟件的網站。§開源項目托管網站，如SourceForge,Google Project Hosting，提供了分類瀏覽和搜索功能。§一些網站（如國內的www.open-open.com）對流行的開源軟件進行了匯總和索引。

2.2.2 開源軟件與自由軟件

§1985年，Richard Stallman成立自由軟件基金會（FreeSoftware Foundation, FSF），該組織對自由軟件做了如下定義：§自由軟件賦予使用者四種自由:?使用該軟件的自由；?研究和改寫該軟件來符合使用者自身的需求的自由；?復制和散布該軟件的自由；?改寫并發布改寫后軟件的自由。§1989年，FSF發布了通用公共許可證（General Public License ，GPL），對自由軟件的使用和分享方式進行了規范的定義，保證了自由軟件的永續自由，即所謂“Copyleft”。促進了開源運動。§GPL具有“傳染性”，即一個軟件一旦使用了遵守GPL的自由軟件的代碼，那么這個軟件也必須遵守GPL。因此許多商業公司出于保護自身知識產權的目的，不敢使用和參與開發自由軟件。§Stallman認為保護軟件的專有權是“不道德的”。§開源軟件在自由軟件的開放、共享與商業組織利益之間尋求一種平衡。一些開源軟件許可證允許商業組織在使用開源軟件的過程中，不泄露其技術機密。使開源軟件有了更大的發展。§1998年，開源軟件促進會（OpenSource Initiative，OSI）成立，成為促進開源軟件運動的權威組織。該組織對開源軟件有明確定義，并負責對開源軟件許可證進行認證。§一種提法：自由和開源軟件（Freeand Open Source Software，FOSS）。

2.2.3 使用開源軟件的質量風險

§絕大多數開源軟件許可證都有免責條款。意味著如果軟件出現質量問題，沒有人為用戶負責。 §要把住質量關：使用優秀的、成熟度高的開源軟件。 §除常規的評價方式（如測試）外，還可利用開源項目特有的一些信息來評價其成熟度，例如項目領導者、開發者社區的規模和活躍程度、用戶的規模、是否有安全補丁機制、文檔是否豐富等。 §有一些開源軟件成熟度評價模型（如OpenBRR）采用定量的方法（數學模型）進行評價。

2.2.4 使用開源軟件的服務風險

§開源軟件不提供技術支持和服務承諾。 §可利用開源項目社區解決一些技術問題，但很有限。 §可購買軟件支持服務（也稱為“訂閱”）。例如Linux操作系統有Redhat公司提供發行版并出售訂閱服務，MySQL數據庫有Oracle公司出售訂閱服務。 §一些公司（如OpenLogic）提供了廣泛的開源軟件服務,包括管理咨詢、法律保障、技術支持、培訓等。

2.2.5 使用開源軟件的法律風險

§如果用戶只是自己使用開源軟件（無論是只運行開源軟件的二進制形式還是修改源代碼后供自己使用），則在一般情況下不會有風險。 §如果用戶要傳播開源軟件，例如把開源軟件（無論是原封不動的還是修改過的）包含在自己的產品中進行再發布，則可能有一定的風險。 §這些風險來自三個方面：軟件著作權、軟件專利、許可證。

開源軟件的著作權

§除了很少一部分屬于公共領域（publicdomain）的開源軟件不受著作權保護外，絕大部分開源軟件都是有著作權的。 §開源軟件的著作權所有者一般通過軟件許可證把權利授權給用戶，同時也要求用戶遵守特定的約束。 §開源軟件的開發者眾多且分散，因此其著作權來源復雜，容易產生侵權現象。

開源軟件的專利

§開源軟件可能包含有軟件專利。 §專利持有者通常通過許可證把專利使用權授予用戶，但有些許可證并沒有對專利授權做出明示。 §由于開源軟件代碼來源復雜，可能帶有未經授權的專利。

防止侵犯著作權和專利的方法

§通過各種渠道調查清楚開源軟件是否涉及著作權和專利方面的問題和糾紛。 §利用第三方資源來規避風險，例如“開放發明網絡”公司可以向受到有關Linux的專利訴訟的公司提供援助，Redhat公司可以為購買了支持服務的用戶提供開源擔保，代替用戶處理侵犯著作權和專利的法律問題。

開源軟件許可證

§開源軟件許可證把各種權利賦予用戶，同時對開源軟件的傳播進行了不同程度的約束。 §OSI認證的開源許可證有幾十種，同時推薦了9種最常用的，分別是：GNU通用公共許可證，簡稱GPL；GNU寬通用公共許可證，簡稱LGPL；Mozilla公共許可證，簡稱MPL；通用開發和發布許可證，簡稱CDDL；Eclipse公共許可證，簡稱EPL；3條BSD許可證；2條BSD許可證；MIT許可證；Apache許可證。 §要詳細解讀所使用的開源軟件的許可證，遵守其約束。 §GPL是目前應用最為廣泛的許可證，據統計，有60%以上的開源軟件采用了它。 §如果作品A使用了GPL許可證，只要作品B包含了作品A的全部或一部分或者其派生作品，那么作品B就是基于作品A的作品。作品B如果要發行，也必須使用GPL許可證。 §使得一個開源軟件作品及其派生作品在傳播過程中永遠保持其自由和開放。GPL對最終用戶非常友好，但專有軟件廠商或對代碼有保密要求的用戶不適合使用GPL許可的開源軟件。 §LGPL的大部分條款與GPL相同，差別在于它允許專有軟件以動態鏈接的方式使用LGPL許可的軟件。 §動態鏈接是指在運行時調用其接口或功能，共享數據結構，而不把它包含進來作為一部分發布。 §LGPL旨在鼓勵一些具有高度可重用性的代碼（例如函數庫）被更多的人使用和改進。 §MPL是Mozilla基金會推出的，它對軟件的再發布做了以下規定： §對于采用MPL的開源軟件源代碼所做的修改，必須繼續以MPL發行。 §對于采用MPL的開源軟件的可執行形式，可采用其他許可證發行（包括專有軟件）。 §可以將采用MPL的開源軟件的源代碼與其它代碼結合在一起形成一個廣義作品，并將該廣義作品以其它許可證發行（包括專有軟件）。 §CDDL是Sun公司在MPL的基礎上開發的，在一些條款上做了改進，與MPL沒有本質上的不同。 §EPL是由Eclipse基金會推出的，在軟件再發布上的規定與MPL類似。 §2條BSD許可證對軟件再發布只做了以下2條規定： ?再發布源代碼時必須保留原著作權聲明和本許可證的條款。 ?再發布二進制形式時必須在文檔或其它附帶資料中包含原著作權聲明和本許可證的條款。 §3條BSD許可證比2條BSD許可證多了以下一條規定： ?在未得到書面許可的情況下不能使用著作權所有者的名稱來簽署或推廣派生于本軟件的產品。 §MIT許可證又名X11許可證或X許可證，由麻省理工學院推出，它對于軟件再發布只有一條規定： ?原著作權聲明和本許可證條款必須出現在本軟件的所有拷貝或實質性部分中。 §Apache許可證由Apache軟件基金會推出，與BSD許可證很類似，但其條款更為嚴謹，特別是對授權的描述更加清楚完整，是一個很成熟的商業友好的許可證。

思考題(使用開源軟件的典型案例)

§案例一：張三下載了開源軟件A的可執行形式并將它安裝在自己的電腦中使用，并且下載學習其源代碼。 §案例二：甲公司開發的某軟件產品需要動態鏈接開源函數庫B但并不包含B。該軟件使用非開源的商業許可證以二進制形式發行。 §案例三：乙公司在其專有產品中包含了一個未作任何修改的開源函數庫C，該產品調用C的公開的API完成特定的操作。該產品使用非開源的商業許可證以二進制形式發行。 §案例四：丙公司將開源軟件D的一段代碼復制到其專有軟件產品的一個源代碼文件中并做了一些修改。該軟件使用非開源的商業許可證以二進制形式發行。 §案例五：丁公司將開源軟件E的代碼稍作改進后使用非開源的商業許可證以二進制形式發行。

第三節 合同項目立項過程

§合同是客戶（甲方）和供應商（乙方）之間具有法律效力的“契約”，明確規定了雙方的責任和權利。 §甲方要提供準確和完整的需求，通過招標選擇合格的乙方。 §乙方要了解清楚甲方的需求并判斷是否有能力滿足這些要求，通過投標來爭取項目。 §雙方簽署合同。

3.1 招標書定義

招標文件的內容

§投標須知：主要包括投標文件的組成，投標時間和地點，評標、中標、簽署合同的過程和標準等。 §項目需求說明：描述項目的功能和技術方面的需求。 §項目招標文件模版

3.2 招標

§招標者要向供應商發出正式的投標邀請，并向他們發送（或發售）招標文件。 §為了使所有投標方對招標文件中的內容有清楚的、統一的理解，招標者可以組織統一答疑。?

招標的方式

§公開招標。將招標信息在社會上公開發布。優點：可以最大程度地吸引更多的供應商來投標，有利于招標者獲得最優的服務或最低價格的產品；缺點：在投標者很多的情況下很耗時，且成本較高。 §受限制的招標。只向一些經過篩選合格的供應商發出投標邀請。針對性較強。 §直接談判。直接與某一個供應商談判，只適用于某些特殊情況。

3.3 投標

§項目分析 §可行性分析 §編寫和遞交投標書

3.3.1 項目分析

3.3.2 可行性分析

3.3.3 投標書

§投標書應按照招標文件的要求來編制，對招標文件提出的要求和條件做出實質性響應。對于軟件項目來說，投標書的主要內容一般可以分為兩大部分：商務標部分和技術標部分。 §項目投標書模版

3.4 評標

§評標就是根據招標文件中規定的條件對投標者進行評估，從中選擇能夠提供最優服務和最合理價格的供應商。 §評標由招標者組建的評標委員會負責，根據我國的招投標法，評標委員會由招標者的代表和有關技術、經濟等方面的專家組成，成員人數為5人以上單數，其中技術、經濟等方面的專家人數不得少于成員總數的三分之二。

評標

§公正性：評標活動應當獨立進行，保證公平、公正地對待所有投標者。 §保密性：凡屬于對投標書的審查、澄清、評價和比較的有關資料以及中標候選人的推薦情況等均要嚴格保密。 §過程：對投標書進行詳細審查，與投標者代表進行會談，已有軟件成果的演示和測試，參觀開發現場等。 §結果：通常是對投標者的各個方面進行量化打分，按照分值將投標者排序。

3.5 簽署合同

§經過評標確定中標者后，招標者應向中標者發出中標通知書，并同時將中標結果通知所有未中標的投標人。 §雙方就合同條款進行協商，達成共識后簽字蓋章，合同生效。

合同的類型

§按照計價方式，合同可以分為兩種類型： §固定價格合同：由合同雙方商定一個確定的項目總價格，該價格是固定不變的，除非合同條款產生了變化。這種合同對甲方來說是低風險的，對乙方來說則有一定風險。適用于那種可以準確定義需求并且有較少風險的項目。 §成本加酬金合同：就是甲方向乙方支付項目的實際成本，再加上商定的管理費和利潤。對甲方來說是有風險的，對乙方來說則是低風險的。適用于那種需求不確定性高和有風險的項目。

合同的一般內容

§雙方的權利與義務； §供應的商品與服務； §技術成果的歸屬； §項目的質量要求； §項目的各種期限； §保密約定； §驗收標準和方法； §價格和付款方式； §違約處理方法； §解決爭議的方法

……

項目合同模版

第4節 通用產品項目立項過程

§微軟公司的新產品項目立項階段的步驟： §1、? 新產品項目的提議 §2、? 市場分析預測 §3、? 技術可行性分析 §4、? 確定產品研發實施步驟 §5、? 高層論證和審批

通用產品項目立項的一般過程

4.1?產品構思

§立項建議小組要在宏觀上搞清楚“開發什么”、“怎樣開發”、“怎樣賺錢”等重要問題。 §產品構思的主要內容： ?待開發產品的主要功能； ?待開發產品的技術方案； ?Make-or-Buy分析； ?開發計劃； ?市場營銷計劃。

Make-or-Buy分析

§確定產品中的哪些部分應當自行研發、采購或外包開發。 §做Make-or-Buy決定的依據包括： ?成本（包括初始成本和后續維護成本）； ?風險； ?工作效率； ?知識產權； ?……

4.2 立項調查

§立項調查的目的是為產品構思和可行性分析提供充分的、有價值的信息。 §立項調查的主要內容有： ?用戶和市場調查； ?政策調查； ?競爭對手和同類產品調查。

立項調查的方式

§常見的立項調查的方式有： ?從Internet上搜索相關資料； ?從出版物中提取信息； ?與用戶交談； ?向用戶群體發調查問卷； ?與同行、專家交談，聽取他們的意見。 §立項調察要堅持客觀性。 §對調查得到的信息進行整理，最好形成一份《調查報告》。

4.3 申請立項

§立項建議小組根據產品構思、立項調查和可行性分析結果完成《立項建議書》，提交給有決策權的機構領導。 §立項建議書模版

4.4 立項評審

§機構領導組織立項評審委員會，并確定一位主席。立項評審委員會一般由機構領導、各級經理、市場人員、技術專家、財務人員等組成。 §主席應當具有比較豐富的評審經驗，負責主持評審會議，并負責撰寫《立項評審報告》。

立項評審的一般步驟

§第一步：評審準備 §（1）評審委員會主席確定評審會議的時間、地點、設備和參加會議的人員名單（包括評審委員會成員、立項建議小組、記錄員、旁聽者等），并通知所有人員。 §（2）主席將《立項建議書》及相關材料發給所有評委，各評委必須在舉行評審會議之前閱讀完畢，并及時與立項建議小組交流。 §第二步：舉行評審會議。 §（1）主席宣布本次評審會議的議程、重點、原則、時間限制等。 §（2）立項建議小組陳述《立項建議書》的主要內容。 §（3）答辯。評審委員會提出疑問，立項建議小組解答。雙方應對有爭議的內容達成一致意見。記錄員記錄答辯過程的重要內容，包括問題、結論、建議等。 §第三步：評估。 §（1）立項建議小組退席。 §（2）每個評審委員會成員認真評估該項目，給出同意或不同意立項的結論和意見建議。 §第四步：評審會議決議 §評審委員會根據少數服從多數的原則，給出評審結論。 §主席撰寫《立項評審報告》并遞交給機構領導。 §第五步：機構領導終審 §此時機構領導具有一票否決權，可在《立項評審報告》中簽署最終審批結論和意見。 §《立項評審報告》模版

第5節 項目授權和啟動

任命項目經理

§項目經理是項目團隊的核心和靈魂，全面負責項目的管理，他的管理能力、經驗水平、知識結構、個人魅力都對項目的成敗起著關鍵的作用。 §一般地，項目的首要建議人被任命為項目經理，但如果他確實不適合這個職位，也可以物色其他人選，但應給項目建議人一定的獎勵。

項目籌備

§項目經理要選擇人員，組成項目團隊。 §項目經理要善于和機構領導、財務和人力資源部門協商，盡可能給項目爭取必要的資金和資源。 §機構的資金和資源是有限的，可能難以完全按照《立項建議書》的要求給項目分配充足的資金和資源。

第6節 項目計劃

§項目計劃（Project Planning）也稱項目規劃，其目的是為項目的開發和管理工作制定合理的行動綱領，使所有人員按照該計劃有條不紊地開展工作。 §誰在什么時候進行項目計劃？

?當項目經理完成了項目籌備，必要的資金和資源已經到位，那么項目經理和核心成員即可組成一個項目計劃小組，開始進行項目計劃。

項目計劃的步驟

6.1 項目估計

§做項目計劃之前，應該對軟件規模、項目工作量進行估計。如果這些要素估計得比較準確的話，那么后續制定的項目計劃就比較合理。對于一些外包項目而言，項目估計得到的數據是雙方討價還價的依據。 §項目估計幾乎不可能成為一門精確的科學。但依據某種方法（規則）進行估計顯然比隨意進行項目計劃好得多。 §有關項目估計方法將在第5章“成本管理”中講述。

6.2?制定項目計劃

§項目計劃分為兩類：一是全局的計劃書（OverallPlan），通常就稱為《項目計劃》；二是一些下屬計劃書（SubordinatePlan），例如配置管理計劃、質量管理計劃、階段開發計劃和測試計劃等。 §下屬計劃書是對《項目計劃》的補充，其內容不可與《項目計劃》沖突。通常《項目計劃》由項目經理負責制定，由機構領導審批。而下屬計劃書一般由項目成員制定，由項目經理審批即可。

項目計劃的主要內容

§項目目標與范圍； §過程模型與技術方法； §人力資源計劃； §軟硬件資源計劃； §財務計劃； §進度計劃； §下屬計劃。 §《項目計劃》模版

6.3項目計劃審批

§項目經理把《項目計劃》遞交給機構領導。 §機構領導認真閱讀該《項目計劃》，如果沒有異議，就簽字批準，使其成為正式文件；如果有不同意之處，就和項目經理溝通，并請項目經理及時修改。 §如果是合同項目，要請甲方代表共同審批項目計劃。

6.4項目計劃變更控制

§《項目計劃》不是一成不變的。 §一般的，若下列情況發生，應當變更《項目計劃》： ?進度偏差超過了容許的誤差，如20%； ?費用偏差超過了容許的誤差，如20%； ?項目過程模型發生了顯著的變化； ?用戶需求發生了重大的變化； ?發生了不可抗拒的變化，如公司裁員、機構調整、產品發展戰略調整等。 §項目計劃的變更應遵循嚴格的變更控制流程（第7章）。

第7節 選擇合適的項目方法

§選擇項目方法有時也稱為“項目分析”或“技術策劃”。 §7.1分析項目特征 §7.2選擇過程模型 §7.3制定技術計劃

7.1 分析項目特征

§（1）系統的需求是否明確和固定？

?有一些軟件產品的需求是比較明確的，而且隨著時間的推移不會產生太大的變化；而另外一些軟件產品的需求會頻繁地變更，且隱含著很多的不確定性。

§（2）系統的規模和復雜性如何？

??系統要解決的問題的規模和復雜性對項目方法的選擇有很大影響。

§（3）項目團隊的經驗和技能如何？

? 項目團隊是否有開發類似系統的經驗？是否有可供復用的軟件資產？是否具有開發系統所需的技能？

§（4）軟件產品是什么類型？

??不同類型的軟件產品要用不同的方法學和技術來實現，對軟硬件平臺的要求也有很大差別。例如實時控制系統可能要使用時態邏輯、Petri網這樣的技術，嵌入式控制系統要求軟件對存儲器的使用要嚴格控制，管理信息系統通常是面向數據的，需要使用數據庫和合適的開發平臺。

§（5）系統是不是安全性關鍵的？

??如果系統的故障會造成巨大的經濟損失，甚至會危及人的生命，那么系統的安全性和可靠性要求就很高，測試工作必須做得非常充分，在開發過程中可能還需使用諸如Z和VDM之類的形式化方法，并考慮使用n版本技術。

7.2 選擇過程模型

過程模型特征總結

§線性模型是計劃驅動的，強調嚴格按照計劃執行，要求在項目之初就明確需求和解決方案。 §迭代型/適應型/極限型模型是價值驅動的，強調不斷為用戶提供實際價值以及過程的適應性和敏捷性，允許隨著項目的進展逐漸明晰需求和解決方案。

7.3制訂技術計劃

§技術計劃一般包含如下內容。 ?待開發系統的特征； ?選擇的過程模型； ?開發方法； ?需要的軟件工具； ?系統運行的硬件/軟件環境； ?需要的培訓。

第8節 軟件外包

§軟件外包就是企業為了專注核心競爭力業務和降低軟件項目成本，將軟件項目中的全部或部分工作發包給提供外包服務的企業完成。 §利用軟件外包可以合理地配置資源，最大限度地從社會分工合作、資源共享中獲益。 §在軟件項目的立項階段，項目負責人通常要進行Make-or-Buy分析，確定待開發產品的哪些部分應當“采購”、“外包開發”或者“自主研發”。如果需要外包開發，就要執行相應的外包管理流程。

軟件外包管理過程

案例分析

§“軟件缺陷管理和度量系統”項目

??? 1. 甲方項目招標需求說明書

??? 2. 乙方項目建議書

本章內容小結

§理解在發現項目機會時，需求信息的幾個來源。 §了解技術可行性分析的幾個方面。了解怎樣合法地使用開源軟件。 §理解合同項目的立項過程。 §理解通用產品項目的立項過程。 §掌握項目啟動過程。 §了解項目計劃的主要內容。 §理解怎樣選擇項目的過程模型和技術方法。 §了解軟件外包

主要參考文獻

§1.蔡俊杰. 開源軟件之道.電子工業出版社，2010.4

??? 本書第5章介紹了怎樣正確使用開源軟件，包括法律因素（許可證、著作權、專利等），特別是對常用開源許可證的對比介紹比較到位。

§2.林銳. 軟件工程與項目管理解析.電子工業出版社，2003.10

??? 本書特色是所講的軟件工程和項目管理知識是從實際企業而來，比較實用。第2章和第3章講述了項目的立項和規劃。

總結

以上是生活随笔為你收集整理的第二章 软件项目立项与规划的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。