軟體工程應用在遊戲團隊開發上

soking

最近在尋找軟體工程的資料，碰巧前陣子公司內部在進行員工教育課程的時候，有發表過
今年上海GDP一篇演講主題，就是在討論一些關於軟體工程開發管理應用在遊戲產業的理論。

把一些個人認為有用的資料整理出來跟大家分享：D

==========================================================

軟體開發的成功與失敗：
有許多軟體開發專案都失敗了，而且不同專案有不同的失敗原因。
還好，從這些專案中我們可以找出相同的症狀並加以歸類。
.. 無法準確了解使用者需要
.. 無法處理需求的改變
.. 模組（Module）間無法配合
.. 軟體很難維護或擴充
.. 太慢發現專案的嚴重瑕疵（Defect）
.. 軟體品質低落
.. 無法接受軟體效能
.. 團隊成員彼此妨礙，不知道誰改了什麼、什麼時候改、改那裡和為什麼改
.. 不可信賴的建構並發表（Build-and-release）流程

如果能克服前述這些原因，不但可以消除症狀，還能有更多優勢，以可重複、
可預期的方式來開發和維護軟體。

這就是最好的軟體實務經驗：它們是商業上被證實可行的軟體開發方式。使用
它們可以解決軟體開發的問題主因稱為”最好的實務經驗”，不是說可以準確
測量它們的價值，而是因為它們已經廣被業界的成功組織採用。
這些最好的實務經驗包括：

1. 以反覆式開發方式（Iterative Development）去開發軟體
2. 管理需求
3. 以元件為基礎（Component-based）的架構
4. 視覺式模型製作軟體（Visually Model Software）
5. 持續驗證軟體品質
6. 控制軟體的改變

[ 本文最後由 發條人形紅舞鞋 於 08-2-4 12:47 PM 編輯 ]

soking

這篇是關於「往覆式開發」的軟體專案文章。
有興趣的朋友可以看看：P

訪客，本文章隱藏的內容需要積分高於 10 才可以瀏覽，你目前積分為 0

[ 本文最後由 soking 於 07-12-24 01:37 PM 編輯 ]

soking

使用RUP於專案的控管

RUP的核心精神
● 使用案例驅動（Use Case Driven）
● 以架構為核心（Architecture Centric）
● 往覆與漸進（Iteration & Incremental）
● 以模組為基礎（Model Based）


有別於瀑布式開發從分析、設計、開發、測試到上線，單一縱向的開發流程，RUP（Rational Unified Process）開發方法論還有第二個面向，橫軸以生命周期的角度，將軟體開發分為初始（Inception）、細化（Elaboration）、建構（Configuration）及交付（Transition）等4個發展階段，因此RUP是二維的開發流程。

剖析縱、橫切面，主要呈現RUP的4個重要的精神：使用案例驅動（Use Case Driven）、以架構為核心（Architecture Centric）、往覆與漸進（Iteration & Incremental）及以模組為基礎（Model Based）。


9個工作流程
縱向的RUP開發流程，羅列軟體專案中應具備的心法（Disciplines），共分為9個工作流程（Workflow），前6項是核心流程，後3項是屬於支持性管理流程：

● 商業建模（Business Modeling）：商業建模通常應用在初次接觸的領域專案，利用商業建模中的各種活動與步驟，熟悉領域知識（Domain Knowledge）。對於熟悉的領域，這是可以省略的工作。

● 需求分析（Requirements）：建立需求模組，繪製使用案例圖（Use Case Diagram），是未來分析、設計、實作與測試的基礎，其重要性不容忽視。

● 分析與設計（Analysis & Design）：根據需求分析所繪製的使用案例圖，導出分析模組與設計模組。分析模組用以描述系統的功能與作用，而設計模組中的類別圖（Class Diagram）已經可以據以產生程式框架。

● 實作（Implementation）：根據前一階段產出的類別圖，填入與商業邏輯程式，成為可執行的功能。

● 測試（Test）：測試工作同樣必須基於使用案例，導出測試案例。RUP採用的自動化測試，錄製測試案例，測試案例可分為基本的正常流程及例外狀況，一旦發現系統有其他的錯誤時，再針對錯誤錄製測試案例。

● 部署（Deployment）：包括軟體的封裝、安裝與驗收。

● 建構與變更管理（Configuration & Change Management）：主要是版本控管與變更管理。

● 專案管理（Project Management）：包括專案的計畫、監控、風險評估及人員的管理。

● 環境配置（Environment）：系統的軟、硬體配置，及手冊與教育訓練的規畫。


以上工作流程，在軟體生命周期的不同階段，占有不同程度的比重，例如初始階段以需求分析為主、細化階段則分析與設計的工作居多，建構階段實作的比重吃重，而交付階段偏重建構與變更管理。

soking

軟體生命周期的四階段

從軟體生命周期的角度，共分為初始、細化、建構及交付等4個階段，每個階段又可畫分多個往覆式（Iteration）開發流程，以漸進的方式，在系統基礎架構上逐步構築出完整的功能。

● 初始階段：藉由訪談探索需求，形成需求模組，畫出使用案例，而後續各階段的設計、開發與測試，都將根基於需求模組的使用案例，認知有誤將導致未來付出很大的修正成本，所以這個階段具有重要的意義。

● 細化階段：RUP強調以架構為核心，根據初始階段的使用案例，找出足以驗證系統架構的核心需求，再視規模切割成適當的往覆周期完成。在每個往覆中完成的核心功能，均包括分析、設計、實作與測試等完整的開發步驟，提交給使用者可以執行的系統，以確認設計無誤。

● 建構階段：漸進是RUP的核心精神，在細化階段確認系統的架構與核心功能後，建構階段即根據基本的架構，大量複製前一階段的設計，逐步累進增加系統功能。

● 交付階段：在前面幾個周期中，經由數次的往覆式流程，已經提交使用者數個可執行的版本，這個階段主要是根據使用者的回饋，進行少量的調整、設定與安裝，因為主要的問題，應該在早期階段已經解決。


==========================================================

4個核心精神
從縱向的開發流程分析，RUP是一連串建構模組的過程，從需求模組導出設計模組、開發模組及測試模組。而所有的設計，均根源於初始階段需求模組的使用案例。由此看出，開發流程的核心精神是「以模組為基礎」及「使用案例驅動」。

而橫向以軟體生命周期的角度來看，RUP為避免瀑布式開發，單向一次性的流程的缺點，在於若驗收時才發現產品不符合期待，將付出慘痛的代價。因此最重要的就是在細化階段，開發核心功能，以驗證系統架構設計的正確性，到了建構階段，便以系統架構作為大量複製的基礎。

而且生命周期的每個階段，都可以切分成多個往覆式流程，每次都設計一點、實作一點、測試一點與交付一點，達到「早期發現，早期修正」的目的，以降低專案的風險，這便是「以架構為核心」、「往覆與漸進」的精神。


===========================================================


精準分工利於管理

RUP的架構非常龐大，縱向的9個工作流程，各自皆有明確應執行的工作項目，每個工作項目又細分各種活動（Activity）與相對的產出（Artifact），再細看每個活動，也都包含詳細的執行步驟。

當每個人只需專注於自身扮演角色所應處理的工作，在轉交給下一個人的時候，也明確定義應輸出/輸入的文件與程式，軟體產業的發展便有可能類似硬體產業，形成軟體工廠加速生產。

雖然「軟體工廠」的想法，現階段看來仍很遙遠，不過精細的分工及明確定義的步驟與產出，確實有助於管理者清楚掌握專案的進度與執行的情況。即使專案延遲或失敗，也會清楚明白是哪一個環節發生問題。


============================================================

[ 本文最後由 soking 於 07-12-24 02:56 PM 編輯 ]

VariableD

在公司实习的时候就觉得很无奈...理想化的开发模式是谁都想要的,但是实际上却是几乎做不到...就算员工素质的因素不考虑在内,这是要以时间+MONEY来支持的T_T
不过版本控制软件是个好东西...

soking

自然這是借鏡於大型的商業軟體工程的相關理論，國內遊戲界恐怕還需要經過不少整合吧

感覺上，有真正的專案管理制度的遊戲公司很少，然而國外有規模的遊戲公司已經行之有年

我跟一些資深企畫討論過XD"
公司某方面來說，不是不想作，但是往往受限於許多因素不能真的狠下心改組
畢竟，這樣的變動可能會面臨一段時間無法有效產出，影響整體作業。

得過且過的心態，就會變成繼續沿用土法煉鋼的模式。
其實在專業資訊這麼進步的年代，無法借鏡這樣的成功模式，挺可惜的

VariableD

我过去在的公司是下狠心在实行软件工程管理的,但是结果并不是很如意.
管理并不是不好,但是游戏很大的一个特点就是,它并不是纯粹的"软件工程"...
我想原因还是时间和金钱的拉锯战,国内这种现状的工作量(每天加班到十点或者十一点,周末不出版本不放人),结果出来的作品,还是三个字"没有爱".=_=
或者说我不满意国内这种现状,所以还是从商业制作退出了.

soking

嗯嗯，商業競爭的確是殘酷的

不過我之所以對這個模式感興趣並加以學習閱讀，是因為老外的遊戲公司採用軟體工程思維運作
已經有了成效出來，證明一樣可行

阿獸PO在這邊的本意，倒並不是在鼓吹改造商業市場上的遊戲公司要改組
而是讓正在業餘遊戲界自製遊戲的同好們，有一個可以參考的製作開發模式

多多吸取專業經驗，我相信是能減輕開發磨合期的陣痛的。

這也是為什麼前陣子在板上，阿獸去詢問幾名有開發驗的諸如烏米、萬古這些有完成經驗的版友
對照聽過的演講記錄以及閱讀軟體工程專案管理的文件，的確是有相當的相似之處的

至於業界的一些苦悶現象，恐怕遠水救不了近火
即使是每一間公司都不太一樣呢

Umi烏米

哎呀被點名了...
其實我倒沒有提供什麼有效的經驗呢qwo

目前也是在做企劃、預定三個月結束案子
嗯好好做計劃  不要看啥做啥的
我的邏輯能力還是得拜NS先生的磨練呀XD

業界是一定有難唸的經、相較起來同人就有愛多了...

VariableD

我是觉得商业模式可能不是那么值得参考...(虽然一些辅助开发软件是很好用,尤其是对企划来说)
毕竟条件太不相同了.
光分工明确这点就几乎做不到.加上制作时间的不固定和成员的流动性.

相反倒是同人组本身的经验很宝贵.
也要有一定发展的组才在考虑这个问题呢...总之大家多分享吧...=v=