準則: 流程區別元件
本準則說明會影響專案流程自訂方式的一些因素。
關係
主要說明

概觀

軟體開發流程會受下列因素的影響:

  • 領域因素,例如應用程式領域、要支援的商業流程、使用者群組以及競爭對手提供的項目。
  • 生命週期因素,例如上市時間、預期的軟體生命期限以及規劃的未來版本。
  • 技術因素,例如程式設計語言、開發工具、資料庫、元件基礎架構以及現有的軟體系統。
  • 組織因素。

這些因素的重要程度各不相同。下列幾節說明其中的一些主要因素,這些是最有可能影響開發流程的整體外形,以及您在開發組織中實作流程與工具的方式。

商業環境定義說明在其中開發軟體的環境定義。有多種不同的商業環境定義類型會影響流程的最佳自訂方式。商業環境定義的範例包括:

  • 合約工作,其中的開發人員開發符合給定客戶滿意度的軟體,並且只適用此客戶。
  • 推論或商業型開發作業,其中的開發人員產生及涵蓋將軟體推到市場的成本。
  • 內部專案,其中的客戶和開發人員都隸屬於相同的組織。

其中有許多中介的方案;例如,只有部分軟體開發作業外包,位置分佈是附加因素等等。個別關係人的總數是商業環境定義的良好指標。

商業環境定義會影響形式層次、正式層次以及流程的嚴格性。關係人(購買者、客戶、承包商、監管單位等等)愈多時,專案就愈有可能需要在主要的專案里程碑時,提出正式的證明,例如文件、報告及原型等。

軟體開發工作的規模

由諸如來源程式碼行 (SLOC)、交付來源指示或功能點等特定測量值所定義的軟體開發工作的規模,會以人員數、月數,或成本來表示。

工作規模會影響形式層次、正式層次以及流程的嚴格性。專案規模愈大,開發小組就愈大,並且不論商業環境定義為何,各個小組和管理階層在需求、介面和進度指示方面,必須更正式,可見度也要越高。大型專案的溝通會因為各小組散置各地,而更形困難。

創新程度

創新程度是依此軟體工作相對於開發組織先前的工作,以及開發作業是屬於第二個循環或後續的循環。這包括組織和其流程、資產、現行技術集合的成熟度,以及諸如成立和訓練團隊、取得工具及其他資源等議題。

專案的創新程度對流程具有完全不同的影響方式。一個史無前例的全新專案會嚴重影響動態配置:初始階段和詳述階段會比較長,並且可能會跨越數個反覆作業。並且也會更注重引出及擷取需求、建立使用案例模型、架構以及減輕風險等。 如果專案是先前系統的演化週期,其變更管理更加重要,並且納入舊版程式碼也會形成技術方面的挑戰。

創新不只是和要開發的系統相對而已,它也和開發組織的成熟度相對,因為在引進新技術或工具時,將會影響流程。特別的是在組織中引進 Rational Unified Process (RUP) 時, 必須以審慎考量的步驟分成各個階段。組織在採用新流程時,會呈現出一些僵化現象, 因此採用策略必須考慮從到新舊流程慣例之間平順的轉換。

應用程式類型

應用程式有很多不同的類型,例如,內嵌即時系統、分散式資訊系統、電話系統、電腦輔助軟體工程設計 (CASE) 工具等等。應用程式類型會影響到流程,特別是有關於領域針對開發作業實施的特定限制,例如安全措施、效能、國際化、記憶體限制等。

如果應用程式是任務型的程式,則應用程式類型會影響流程;例如,飛機內的飛航控制系統。一般而言,任務型的系統需要較高的正式層次,以用來追蹤需求及確保產品品質。任務型的應用程式也需要分配更多資源進行測試。

開發類型或是目標領域會帶出如下的流程問題:

  • 支援特定作業的技術與工具:例如,限定狀態機的自動化產生程式碼。
  • 認證程序;例如,醫療設備。
  • 依循標準;例如,適用於會計或財務議題,以及電信設備。

開發類型

開發類型有許多種,例如:

  • 合約工作,針對特定的客戶開發某項產品。在進行合約工作時,會有較多關係人需要管理和協商。這裡通常需要較正式的外部工作成果,因為客戶或代表們會想要監視進度並獲得通知。請確定提供給客戶審查的工作成果極容易瞭解。有時,需要訂定一個里程碑,讓專案可以對專案的其餘部分,提供一個固定價格。在此情況下,您可能就需要新增一個里程碑,或是調整現有的里程碑。在別的情況下,您可能需要使用其他里程碑和階段,調整為客戶使用的生命週期模型。
  • 推論式開發,針對大眾市場開發某項產品。在推論式開發中,位在組織內部的 行銷(產品)管理人員就形同客戶。推論式開發的上市時間,通常要比功能重要許多,並且也比較不需要做正式的審查。
  • 內部開發,所開發的產品會交付給公司內的其他部門。如果您是要交付給沒有使用 RUP 的其他專案時,您可能需要調整為別的生命週期模型。在說明工作成果時,可以接受以較技術的說明方式,因為大部分的工作成果會是由同儕審查。
  • 預先研究,這通常不會開發產品。預先研究專案的目的通常是要瞭解是否有可能建置產品。預先研究專案不會具有和一般專案相同的里程碑。

現行開發流程

通常,並不會取代組織中目前使用的軟體開發流程慣例,因為在大部分的情況下,都會逐步實作新的開發流程,並先專注於較關鍵及重要的部分。現有的某些軟體開發流程可能會繼續存在一段時間,或甚至於永久存在。

問題與主要原因

專案識別和重點化了哪些問題,會影響您在開始實作流程時,所專注的那些流程部分。需要注意的一件重要事情是如果組織內沒有已經存在的工作方式,就不需要找出問題。請參閱概念:在專案中實作流程。您可能是需要找出問題的主要原因。若要消除問題,您需要透過改進流程、引進工具來將流程自動化,以及訓練人員等方式,來處理主要原因。 

常見問題範例

以下是一些常見問題的範例:

  • 無法管理範圍,組織不斷嘗試要做的事情總是比最後實際做到的多。
  • 無法擷取需求,沒有辦法定出需求。
  • 無法管理變更需求。
  • 無法管理需求,需求沒有在最終產品內完成。
  • 無法預估,總是對自己的按時交付能力過度樂觀。
  • 設計缺失,很能符合需求,但卻窮於設計系統。他們有什麼設計問題? 系統很難維護和加強嗎?他們有效能、使用性、容量等等方面的問題嗎?
  • 無法產生品質良好的產品,產品的問題太多,這可能是因為缺少測試,不過這通常是和無法擷取及管理需求,以及設計缺失相關。
  • 軟體效能無法接受。
  • 使用性極低。
  • 開發人員衝突,擁有權和配置管理缺乏控制,因此開發人員做互相衝突的變更,並且流失工作。
  • 太晚發現問題。 
  • 使用案例無法移轉為設計。
主要原因範例

問題通常是錯誤的症狀。因此您需要找出問題的主要原因。以下是一些常見的主要原因範例:  

  • 需求管理不足
  • 溝通語意不明及不明確
  • 架構脆弱
  • 太過於複雜
  • 需求、設計和實作之間有未發現到的不一致存在
  • 測試不足
  • 專案狀態評量過於主觀
  • 由於採直瀉式開發而延誤減少風險
  • 變更延伸未做控制
  • 自動化不足
  • 沒有系統化的方式來建置使用者介面
  • 使用案例無法轉換為設計

組織因素

若要在組織中實作流程,是看諸如組織的應變能力、組織結構、專案的組織與管理文化、可運用的能力與技術、先前的經驗與目前的態度等組織因素。

組織因素也會影響流程的配置方式。例如,如果組織內的人員先前已經有使用軟體開發流程說明的經驗,就比較容易開始使用 RUP。另一方面,如果人員沒有使用軟體開發流程說明的經驗,您很可能會決定要限制流程說明的範圍。您也可能會加入額外的努力,來使流程說明容易瞭解和使用,確定其中包含(或參考)的資訊會提供最大的價值。

如果有某些部分對大部分人員而言都是新的領域,則盡可能開發最優秀的準則會使轉換較容易一點。比方說,如果程式設計語言是大部分人員的新語言,您就要提供很好的「程式設計準則」和「設計準則」,來協助他們學習新語言。

態度

組織內的人員對於改用新技術、新流程或新工具抱持負面態度時,可以說是對成功實作流程和工具的最大威脅。對於流程過度樂觀也會是個問題,因為這會導致人員將注意力過度集中於流程。

為了評定人員對新技術、流程及工具的態度,可以提出如下的問題:

  • 您覺得新技術的好處在哪裡?新的技術是否能解決目前的任何問題? 您覺得新技術有什麼缺點?
  • 您覺得新流程的好處在哪裡?新的流程是否能解決目前的任何問題? 您覺得新流程有什麼缺點?
  • 您覺得新工具的好處在哪裡?新的工具是否能解決目前的任何問題? 您覺得新工具有什麼缺點?

若要評定人員的動力,可以找出對如下問題的回答:

  • 組織內的每個人都清楚為何需要變更嗎?
  • 是否每個人都知道競爭對手在做什麼?並且那會對商業有何影響?
  • 是否每個人都知道業界的技術變更以及其對商業的影響嗎?  

負面的態度可能會包括類似如下的陳述:

  • 「流程不能幫什麼忙,只會礙事而已」。
  • 「流程代表要產生大量文件」。
  • 「流程太過於繁重」。

處理負面態度的一些方式如下:

  • 指出目前的問題,來刺激動機。
  • 說明流程並不會指使你該怎麼做。必須把流程當作是「協助系統」,讓您可以找到指引、定義等等。
  • 說明您只使用流程的一小部分。沒有哪個人可以負責整個流程,並且那也不是真正的目的。將流程比做存放書籍的書架,您只需閱讀需要其資訊的書籍即可。
  • 召開一個成功的試驗專案,顯示新流程和工具的運作方式。在試驗專案中包括一或兩個懷疑論者。 

過度樂觀的症狀包括:

  • 人員完全仰賴該流程,並認為流程會解決他們的所有問題。
  • 流程是銀子彈或有魔力的公式,只要照著做,就保證一定會成功。
  • 專案小組未先評估需要解決的與專案相關問題,就想要花大量時間和人力調整流程。 

處理過度樂觀的一些方式如下:

  • 設定期待值。流程會有幫助,但是不會解決問題。人要去解決問題。
  • 勸阻人員不要花太多時間來調整流程。
  • 使人員集中注意力於開發軟體。

技術及管理的複雜性

不同類型的系統及其專案可以分類為系統的技術複雜性管理複雜性。下圖顯示如何分類不同系統的概念。例如,一般的小型商業試算表應用程式通常技術複雜性比較低,並且容易管理。另一個極端是典型的武器系統專案,這通常是技術複雜性很高,並且管理很複雜。

通常在增加系統大小、專案持續時間或商業環境定義時,也會增加管理的複雜性。增加創新程度,不論是在問題領域或解決方案空間方面,都會提高技術複雜性。在管理和技術複雜性之間也會有互動存在,因為許多大型專案也都會有複雜的技術。這會導致:

  • 提高管理複雜性,因而導致更形式化,包括更正式的審查和里程碑,以及更多工作成果。
  • 提高技術複雜性導致引進特定的技術、角色和工具,因而帶來更多作業。

圖解說明詳見隨附的文字。

系統依技術複雜性和管理複雜性分類