軟體開發流程會受下列因素的影響:
-
領域因素,例如應用程式領域、要支援的商業流程、使用者群組以及競爭對手提供的項目。
-
生命週期因素,例如上市時間、預期的軟體生命期限以及規劃的未來版本。
-
技術因素,例如程式設計語言、開發工具、資料庫、元件基礎架構以及現有的軟體系統。
-
組織因素。
這些因素的重要程度各不相同。下列幾節說明其中的一些主要因素,這些是最有可能影響開發流程的整體外形,以及您在開發組織中實作流程與工具的方式。
商業環境定義說明在其中開發軟體的環境定義。有多種不同的商業環境定義類型會影響流程的最佳自訂方式。商業環境定義的範例包括:
-
合約工作,其中的開發人員開發符合給定客戶滿意度的軟體,並且只適用此客戶。
-
推論或商業型開發作業,其中的開發人員產生及涵蓋將軟體推到市場的成本。
-
內部專案,其中的客戶和開發人員都隸屬於相同的組織。
其中有許多中介的方案;例如,只有部分軟體開發作業外包,位置分佈是附加因素等等。個別關係人的總數是商業環境定義的良好指標。
商業環境定義會影響形式層次、正式層次以及流程的嚴格性。關係人(購買者、客戶、承包商、監管單位等等)愈多時,專案就愈有可能需要在主要的專案里程碑時,提出正式的證明,例如文件、報告及原型等。
由諸如來源程式碼行 (SLOC)、交付來源指示或功能點等特定測量值所定義的軟體開發工作的規模,會以人員數、月數,或成本來表示。
工作規模會影響形式層次、正式層次以及流程的嚴格性。專案規模愈大,開發小組就愈大,並且不論商業環境定義為何,各個小組和管理階層在需求、介面和進度指示方面,必須更正式,可見度也要越高。大型專案的溝通會因為各小組散置各地,而更形困難。
創新程度是依此軟體工作相對於開發組織先前的工作,以及開發作業是屬於第二個循環或後續的循環。這包括組織和其流程、資產、現行技術集合的成熟度,以及諸如成立和訓練團隊、取得工具及其他資源等議題。
專案的創新程度對流程具有完全不同的影響方式。一個史無前例的全新專案會嚴重影響動態配置:初始階段和詳述階段會比較長,並且可能會跨越數個反覆作業。並且也會更注重引出及擷取需求、建立使用案例模型、架構以及減輕風險等。
如果專案是先前系統的演化週期,其變更管理更加重要,並且納入舊版程式碼也會形成技術方面的挑戰。
創新不只是和要開發的系統相對而已,它也和開發組織的成熟度相對,因為在引進新技術或工具時,將會影響流程。特別的是在組織中引進 Rational Unified Process (RUP) 時,
必須以審慎考量的步驟分成各個階段。組織在採用新流程時,會呈現出一些僵化現象, 因此採用策略必須考慮從到新舊流程慣例之間平順的轉換。
應用程式有很多不同的類型,例如,內嵌即時系統、分散式資訊系統、電話系統、電腦輔助軟體工程設計 (CASE) 工具等等。應用程式類型會影響到流程,特別是有關於領域針對開發作業實施的特定限制,例如安全措施、效能、國際化、記憶體限制等。
如果應用程式是任務型的程式,則應用程式類型會影響流程;例如,飛機內的飛航控制系統。一般而言,任務型的系統需要較高的正式層次,以用來追蹤需求及確保產品品質。任務型的應用程式也需要分配更多資源進行測試。
開發類型或是目標領域會帶出如下的流程問題:
-
支援特定作業的技術與工具:例如,限定狀態機的自動化產生程式碼。
-
認證程序;例如,醫療設備。
-
依循標準;例如,適用於會計或財務議題,以及電信設備。
開發類型有許多種,例如:
-
合約工作,針對特定的客戶開發某項產品。在進行合約工作時,會有較多關係人需要管理和協商。這裡通常需要較正式的外部工作成果,因為客戶或代表們會想要監視進度並獲得通知。請確定提供給客戶審查的工作成果極容易瞭解。有時,需要訂定一個里程碑,讓專案可以對專案的其餘部分,提供一個固定價格。在此情況下,您可能就需要新增一個里程碑,或是調整現有的里程碑。在別的情況下,您可能需要使用其他里程碑和階段,調整為客戶使用的生命週期模型。
-
推論式開發,針對大眾市場開發某項產品。在推論式開發中,位在組織內部的 行銷(產品)管理人員就形同客戶。推論式開發的上市時間,通常要比功能重要許多,並且也比較不需要做正式的審查。
-
內部開發,所開發的產品會交付給公司內的其他部門。如果您是要交付給沒有使用 RUP 的其他專案時,您可能需要調整為別的生命週期模型。在說明工作成果時,可以接受以較技術的說明方式,因為大部分的工作成果會是由同儕審查。
-
預先研究,這通常不會開發產品。預先研究專案的目的通常是要瞭解是否有可能建置產品。預先研究專案不會具有和一般專案相同的里程碑。
通常,並不會取代組織中目前使用的軟體開發流程慣例,因為在大部分的情況下,都會逐步實作新的開發流程,並先專注於較關鍵及重要的部分。現有的某些軟體開發流程可能會繼續存在一段時間,或甚至於永久存在。
專案識別和重點化了哪些問題,會影響您在開始實作流程時,所專注的那些流程部分。需要注意的一件重要事情是如果組織內沒有已經存在的工作方式,就不需要找出問題。請參閱概念:在專案中實作流程。您可能是需要找出問題的主要原因。若要消除問題,您需要透過改進流程、引進工具來將流程自動化,以及訓練人員等方式,來處理主要原因。
常見問題範例
以下是一些常見問題的範例:
-
無法管理範圍,組織不斷嘗試要做的事情總是比最後實際做到的多。
-
無法擷取需求,沒有辦法定出需求。
-
無法管理變更需求。
-
無法管理需求,需求沒有在最終產品內完成。
-
無法預估,總是對自己的按時交付能力過度樂觀。
-
設計缺失,很能符合需求,但卻窮於設計系統。他們有什麼設計問題? 系統很難維護和加強嗎?他們有效能、使用性、容量等等方面的問題嗎?
-
無法產生品質良好的產品,產品的問題太多,這可能是因為缺少測試,不過這通常是和無法擷取及管理需求,以及設計缺失相關。
-
軟體效能無法接受。
-
使用性極低。
-
開發人員衝突,擁有權和配置管理缺乏控制,因此開發人員做互相衝突的變更,並且流失工作。
-
太晚發現問題。
-
使用案例無法移轉為設計。
主要原因範例
問題通常是錯誤的症狀。因此您需要找出問題的主要原因。以下是一些常見的主要原因範例:
-
需求管理不足
-
溝通語意不明及不明確
-
架構脆弱
-
太過於複雜
-
需求、設計和實作之間有未發現到的不一致存在
-
測試不足
-
專案狀態評量過於主觀
-
由於採直瀉式開發而延誤減少風險
-
變更延伸未做控制
-
自動化不足
-
沒有系統化的方式來建置使用者介面
-
使用案例無法轉換為設計
若要在組織中實作流程,是看諸如組織的應變能力、組織結構、專案的組織與管理文化、可運用的能力與技術、先前的經驗與目前的態度等組織因素。
組織因素也會影響流程的配置方式。例如,如果組織內的人員先前已經有使用軟體開發流程說明的經驗,就比較容易開始使用
RUP。另一方面,如果人員沒有使用軟體開發流程說明的經驗,您很可能會決定要限制流程說明的範圍。您也可能會加入額外的努力,來使流程說明容易瞭解和使用,確定其中包含(或參考)的資訊會提供最大的價值。
如果有某些部分對大部分人員而言都是新的領域,則盡可能開發最優秀的準則會使轉換較容易一點。比方說,如果程式設計語言是大部分人員的新語言,您就要提供很好的「程式設計準則」和「設計準則」,來協助他們學習新語言。
組織內的人員對於改用新技術、新流程或新工具抱持負面態度時,可以說是對成功實作流程和工具的最大威脅。對於流程過度樂觀也會是個問題,因為這會導致人員將注意力過度集中於流程。
為了評定人員對新技術、流程及工具的態度,可以提出如下的問題:
-
您覺得新技術的好處在哪裡?新的技術是否能解決目前的任何問題? 您覺得新技術有什麼缺點?
-
您覺得新流程的好處在哪裡?新的流程是否能解決目前的任何問題? 您覺得新流程有什麼缺點?
-
您覺得新工具的好處在哪裡?新的工具是否能解決目前的任何問題? 您覺得新工具有什麼缺點?
若要評定人員的動力,可以找出對如下問題的回答:
-
組織內的每個人都清楚為何需要變更嗎?
-
是否每個人都知道競爭對手在做什麼?並且那會對商業有何影響?
-
是否每個人都知道業界的技術變更以及其對商業的影響嗎?
負面的態度可能會包括類似如下的陳述:
-
「流程不能幫什麼忙,只會礙事而已」。
-
「流程代表要產生大量文件」。
-
「流程太過於繁重」。
處理負面態度的一些方式如下:
-
指出目前的問題,來刺激動機。
-
說明流程並不會指使你該怎麼做。必須把流程當作是「協助系統」,讓您可以找到指引、定義等等。
-
說明您只使用流程的一小部分。沒有哪個人可以負責整個流程,並且那也不是真正的目的。將流程比做存放書籍的書架,您只需閱讀需要其資訊的書籍即可。
-
召開一個成功的試驗專案,顯示新流程和工具的運作方式。在試驗專案中包括一或兩個懷疑論者。
過度樂觀的症狀包括:
-
人員完全仰賴該流程,並認為流程會解決他們的所有問題。
-
流程是銀子彈或有魔力的公式,只要照著做,就保證一定會成功。
-
專案小組未先評估需要解決的與專案相關問題,就想要花大量時間和人力調整流程。
處理過度樂觀的一些方式如下:
-
設定期待值。流程會有幫助,但是不會解決問題。人要去解決問題。
-
勸阻人員不要花太多時間來調整流程。
-
使人員集中注意力於開發軟體。
不同類型的系統及其專案可以分類為系統的技術複雜性和管理複雜性。下圖顯示如何分類不同系統的概念。例如,一般的小型商業試算表應用程式通常技術複雜性比較低,並且容易管理。另一個極端是典型的武器系統專案,這通常是技術複雜性很高,並且管理很複雜。
通常在增加系統大小、專案持續時間或商業環境定義時,也會增加管理的複雜性。增加創新程度,不論是在問題領域或解決方案空間方面,都會提高技術複雜性。在管理和技術複雜性之間也會有互動存在,因為許多大型專案也都會有複雜的技術。這會導致:
-
提高管理複雜性,因而導致更形式化,包括更正式的審查和里程碑,以及更多工作成果。
-
提高技術複雜性導致引進特定的技術、角色和工具,因而帶來更多作業。
系統依技術複雜性和管理複雜性分類
|