F.W.知識瑣記: 軟體工程

顯示具有 軟體工程 標籤的文章。顯示所有文章

2025年6月22日

商業軟體介面設計有多重要? 花旗銀行錯匯9億美元的教訓

作者: Fred F.M. Wang (FW知識瑣記) 日期: 2025-6-22

2020年8月花旗銀行發生一起嚴重轉帳失誤, 3 人把關，仍錯匯 9 億美元！
"花旗最終將此事件歸咎於「人為失誤」，甲骨文發言人則出面表示，有許多金融機構每天利用 Flexcube 進行上兆美元的交易，言下之意，此次意外並非軟體疏失。但深究此事件，從 Flexcube 的介面設計來看，恐怕也難辭其咎。"

文中Flexcube 匯款作業介面截圖畫面，誰看了都覺得太過簡略，欄位標示文字不清楚，缺乏明確的指示與送出後的檢核機制，才會容易造成錯誤。

UI改善重點 :
1 每個輸入框前要有清晰的說明，使用更人性化的語言及術語。
2 表單送出前以簡潔的文字描述即將發生的事，與再確認詢問。
3 表單送出後增加檢核與防措機制。
資料來源 : https://www.managertoday.com.tw/articles/view/62718?

2025年5月4日

各程式語言程式設計風格與慣例(Coding Styles, Coding Conventions)

作者: Fred F.M. Wang (FW知識瑣記) 日期: 2025-5-4

學習一種程式語言，除了學習基本的語法與可用的程式庫外，參考程式語言官方或大企業/組織釋出的程式設計風格與慣例，建議建立良好的程式設計習慣，以開發出品質佳，可讀性高，好維護與高效率的系統。下面蒐集各程式語言一些不錯的程式設計風格與慣例網址，提供大家參考。

HTML/CSS - Google HTML/CSS Style Guide

https://google.github.io/styleguide/htmlcssguide.html

HTML - HTML Style Guide (jQurty Foundation)

https://contribute.jquery.org/style-guide/html/

CSS - CSS Style Guilde (jQurty Foundation)

https://contribute.jquery.org/style-guide/css/

JavaScript - JavaScript Style Guide(jQurty Foundation)

https://contribute.jquery.org/style-guide/js/

JavaScript - Google JavaScript Style Guide

https://google.github.io/styleguide/jsguide.html

JavaScript 编码规范

http://itmyhome.com/js/index.html

PHP - PER Coding Style 2.0

https://www.php-fig.org/per/coding-style/

PHP - PSR Coding Standards

https://github.com/php-fig/fig-standards/tree/master/accepted

Visual Basic Coding Conventions (Microsoft)

https://learn.microsoft.com/en-us/dotnet/visual-basic/programming-guide/program-structure/coding-conventions

Assembly Language Coding Guidelines

https://projectacrn.github.io/latest/developer-guides/asm_coding_guidelines.html

AutoIT - Best coding practices

https://www.autoitscript.com/wiki/Best_coding_practices

C# - Common C# code conventions (Microsoft)

https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions

C# - 常用的 C# 程式碼慣例(Microsoft)

https://learn.microsoft.com/zh-tw/dotnet/csharp/fundamentals/coding-style/coding-conventions

C# at Google Style Guide(Google)

https://google.github.io/styleguide/csharp-style.html

C Coding Standard (Carnegie Mellon University)

https://users.ece.cmu.edu/~eno/coding/CCodingStandard.html

C Coding Style - GNOME Developer Documentation

https://developer.gnome.org/documentation/guidelines/programming/coding-style.html

C++ - Google C++ Style Guide(Google)

https://google.github.io/styleguide/cppguide.html

Objective-C - Google Objective-C Style Guide(Google)

https://google.github.io/styleguide/objcguide.html

Fortran Style Guide

https://fortran-lang.org/learn/best_practices/style_guide/

Go language- Google Go Style Guide

https://google.github.io/styleguide/go/

Go - Effective Go

https://go.dev/doc/effective_go

Java - Google Java Style Guide

https://google.github.io/styleguide/javaguide.html

Java Code Conventions (1997, Sun Microsystems)

https://www.oracle.com/technetwork/java/codeconventions-150003.pdf

Perl - perlstyle - Perl style guide

https://perldoc.perl.org/perlstyle

Python - PEP 8 – Style Guide for Python Code

https://peps.python.org/pep-0008/

Python - Google Python Style Guide

https://google.github.io/styleguide/pyguide.html

R language - Google’s R Style Guide

https://google.github.io/styleguide/Rguide.html

Ruby Style Guide

https://github.com/rubocop/ruby-style-guide

SAP ABAP - ClearABAP Style Guide

https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md

Scala Style Guide

https://docs.scala-lang.org/style/

Scala - Databricks Scala Style Guide

https://github.com/databricks/scala-style-guide

SQL Style Guide (Mozilla)

https://docs.telemetry.mozilla.org/concepts/sql_style

Swift - Google Swift Style Guide

https://google.github.io/swift/

2022年12月15日

如何寫出可靠的程式?

作者: Fred F.M. Wang (FW知識瑣記) 日期: 2022-12-15

一些程式設計的習慣，決定您程式的品質與可靠度。筆者整理幾個通用可供參考的重點 :

1 一致的程式設計風格 : 提高程式可讀性與可維護性(團隊開發或他人修改)。

2 適當的縮排 : 提高程式可讀性，並可幫助除錯。

3 適當地使用註解 : 註解用來解釋某程式段的功能以及如何運作，有助於程式的可維護性。

4 適當的變數名稱與函式名稱 : 選擇描述性與有意義的名稱，提高程式可讀性，便於理解。

5 避免全域變數 : 全域變數會讓程式發生無法預期的行為，且不易除錯。

6 使用程式語言內建函式 : 使用語言內建函式可讓程式碼更簡潔更有效率。

7 避免重複的程式碼 : 重複的程式碼難以維護，並容易造成錯誤，如果發現需要寫重複的程式碼時，應該將這段程式碼寫成可供叫用的共用函式。

8 運用Design Patterns : Design Patterns是解決一般程式設計問題被證明過的方案，可以讓程式碼更有效率，提高再用性與可維護性。

本部落格提升程式設計能力相關的參考文章 :

2020-1-15 給新手程式設計師 - 養成幾個程式設計的習慣，對您將來有很大的幫助

2019-1-14 如何精進程式設計能力

2017-6-20 程式碼審查有助於提升程式品質嗎? 有關程式審查的十個事實

2012-3-14 技術債務

2011-10-10 甚麼是卓越的軟體工程師

2008-9-25 程式設計師的生產力差多少

2007-11-14 如何維護老舊程式

2005-7-29 程式設計功力提升的方法與Joel on Software網站

2004-12-13 [筆記] 軟體品質指標 : 列出McCall在1977年提出的軟體品質模型(Software Quality Model)，包含用來評估一個軟體系統品質的優劣的11個要點。

2018年12月24日

如何讓公開的程式可以執行，但令人難以閱讀與理解 -- 使用程式碼混淆器(Obfuscator)

作者: Fred F.M. Wang (FW知識瑣記) 日期:2018/12/24 修定 : 2023/6/9

在特定情況，你需要提供程式給其他人，或公開在網站，例如網頁內的javascript code，基於保護個人智慧財產，你不希望別人了解你的程式邏輯與演算法，但是程式又可以必須可以正確執行。

因此，必須使用程式碼混淆（Obfuscation）技術將電腦程式的程式原始碼，轉換成一種功能相同，可正確執行，但是難於閱讀和理解的形式。

使用程式碼混淆（Obfuscation）技術的工具稱為混淆器(Obfuscator)

ㄧ C/C++的程式混淆器 :
1. 下面網址可以下載 C/C++ Obfuscator(程式混淆器)
1.1 http://stunnix.com/prod/cxxo/    , 範例
    1.2 http://www.sourceformat.com/obfuscate-code-cpp.htm
    1.3 http://www.star-force.com/products/starforce-obfuscator/

2. C/C++線上程式混淆器

Online C/C++ Obfuscator

還有一個C程式混淆的國際比賽，裡面有一些人將C程式混淆為有趣的程式碼 The International Obfuscated C Code Contest(ioccc)

二 Javascript 線上程式混淆器

Javascript Obfuscator

三 Python 線上程式混淆器

Oxyry Python Obfuscator

四 PHP 線上程式混淆器

2018年11月27日

各種程式語言的程式設計慣例(Coding Conventions)與設計風格指引(Style Guildes)

作者: Fred F.M. Wang (FW知識瑣記) 日期: 2018/11/27

要讓開發的程式可讀性高，可維護性才會好，有一致的程式設計風格與標準，不只是自己在將來修改程式時比較不會有困難，團隊中也有利於code review與維護工作的交接。下面整理一些常用程式語言的設計慣例與風格。

C語言

GNU Coding Standard - GNU.org
NASA C Style Guide - NASA Goddard Space Flight Center Aug.1994
C Coding Style - GNOME Developer Center

C++語言

Google C++ Style Guide - Google

HTML/CSS

Google HTML/CSS Style Guide - Google
HTML5 Style Guide and Coding Conventions - w3schools.com

Java 語言

Java Code Conventions - Oracle Sep.1997
Google Java Style Guide - Google

Javascript 語言

JavaScript Style Guide and Coding Conventions - w3schools.com
Google JavaScript Style Guide - Google

PHP 語言

PSR-2: Coding Style Guide - PHP-FIG.org

Python 語言

PEP 8 -- Style Guide for Python Code - python.org
Google Python Style Guide - Google

Visual Basic 語言

Visual Basic Coding Conventions - Microsoft

2017年6月20日

程式碼審查有助於提升程式品質嗎? 有關程式審查的十個事實

作者: Fred F.M. Wang (FW知識瑣記) 日期:20170620

英文原文：10 facts about code reviews and quality

摘要翻譯

以下是從 680家公司訪談有關程式品質與程式碼審查的案例，得到下面結果

　　事實一：我們花大量的時間在審查程式碼。事實是，我們每週平均花費 5 個小時來審查程式碼，或者每週 12.5％的時間來查看程式碼。

　　事實二：作為開發人員，每週花費超過一天的時間來審查程式碼與提高程式碼品質並不相關，反而是用更多時間在發佈新功能（而不是修復bug 或償還技術債務）。

　　事實三：45％的開發人員說，「缺少時間」是審查程式碼的真正障礙，34％的開發人員則認為是迫於「發佈新功能的壓力」

　　事實四：72％的開發人員表示他們被阻止花時間審查程式碼。

　　事實五： 66％的開發人員表示需要 1 人批准他們的 pull requests，25％需要 2 人，小於 5％需要超過 2 人。(註 : Pull Requests : 開發人員可以透過Github發出Pull Requests要求請求他人將程式拉下來看，也就是由開發人員主動要求他人幫忙做Code Review的意味。)

　　事實六：53％的人表示有監控程式碼覆蓋率，但 65％表示沒有程式碼覆蓋率的最小門檻值(標準)，來批准 pull requests (註 : 代碼覆蓋（英語：Code coverage）是軟體測試中的一種度量，描述程式中源代碼被測試的比例和程度，所得比例稱為代碼覆蓋率。有多種不同的覆蓋率準則，如函式覆蓋率，敘述覆蓋率，判斷覆蓋率，條件覆蓋率等 )

　　事實七：29％的開發人員表示他們的專案中最大的問題是「工作量」，而工程副總和處長的則認為是「交付速度」。開發人員的第三大問題則是「管理」。

　　事實八：關於誰來審查程式碼，讓團隊中的每個人都參與是最常見的做法。其他方法則是由專案負責人或模組的負責人來參與，或讓資深的開發人員來審查多數的程式碼。

　　事實九：較嚴格的程式碼審查會讓我們用更少的時間修復錯誤，也就有更多的時間來提供新功能。較不嚴格的程式碼審查者會花費 31％的時間修復錯誤，而嚴格的審查者則只花費 24％的時間。關於專注新功能的時間：和上面對應的分別是 43％和 54％。(嚴格的審查者有更多的時間專注於新功能)

　　事實十：開發人員花費 45% 的時間修復錯誤或解決技術債務(以前留下來的問題)，與建立新功能所花費的時間不相上下。

由上面來看，程式碼審查可以提高修復錯誤的效率，但是不見得可以提高程式碼品質。

2012年3月21日

如何建立高效率應用系統開發團隊

下面是筆者以個人經驗，提出建立高效率應用系統開發團隊的重點，如下

第一專業團隊的養成，建立Library(知識庫，程式庫..)
a.尋找適合團隊中各種角色的人才, 並持續進行培訓
b.蒐集相關知識，建立與累積程式庫
c.建立高效率的工作流程並且持續改善工作流程
d.訂定績效考核標準，建立標準TAT

第二專業分工
可將開發區分為兩大團隊 : 一個是專精商業領域知識，善於溝通的需求分析團隊與專精開發技術與架構設計的系統開發團隊。

2.1 業務需求分析團隊的任務
a.蒐集需求,過濾哪些需求適合系統化 : 成員包含熟悉各業務領域(銷售、財務、人事…)等的人員，收集並過濾需求。
b.編寫規格 : 確定需求後, 使用UML等工具編寫規格。
c.專案溝通會議 : 完成系統規格後,與系統開發團隊連繫與溝通, 應做快速而有效的溝通。

2.2系統開發團隊的任務
a.雛形製作團隊共同參與設計會議
b.繪製DFD,ERD等; 建立功能模組
c.細部設計開發與整合
e.單元測試與整合測試
f.品管(QA)
角色再區分 : 使用者介面設計人員,程式設計師, 測試與QA人員
重點 :
a.需訂定各階段標準TAT
b.持續建立公用程式庫,商業功能模組,與樣版(template)
c.持續改善流程 (生產線化)

2012年3月14日

技術債務

作者: Fred Wang (FW知識瑣記) 日期:

最近看到這個名詞，深有所感，從網路整理一些重點，做為備忘。

何謂技術債務 : 由Ward Cunningham首次提出，指開發團隊在設計或架構選擇時從短期效果的角度選擇一個易於實現的方案，但從長遠來看，這種方案會帶來不良的影響，這就是開發團隊所欠的債務。

"重構"一書作者Martin Fowler定義 :　技術債務類似於金融債務，它也會產生利息，這裡的利息其實就是指由於魯莽的設計決策導致需要在未來的開發中付出更多努力的後果。

Martin Fowler認為您可以選擇繼續支付利息，也可以透過重構過去前鲁莽的設計將本金一次付清。雖然一次性付清本金需要代價，却可以降低未來的利息。

"Code Complete"一書作者Steve McConnell將技術債務分成兩類
1.缺乏經驗造成，例如技術能力不足或經驗不足而產生品質不佳的設計。
2.為了短期的利益，選擇快速或方便的方案，對長期而言會造成不良影響。

造成的原因可能是
1.開發人員沒有經驗
2.時程的壓力
3.分工缺乏整體考量
4.過度的複雜的設計，沒有考慮使用情境等
5.短視，無法為長期經營考量設計(缺乏可讀性，可維護性，再用性等)
6.來自客戶或上司的壓力，不合理的需求，造成不合理的設計

這篇文章"用雞講解技術債務形成的過程"用有趣的例子舉出上面第6點原因。

根據CAST分析報告顯示，平均一家公司要解決技術債務的花費是每行程式碼3.61美元。

下面這篇文章提出一些解決方案 :http://www.infoq.com/articles/technical-debt-levison

身為經理人不可坐視這些技術債務不管，否則將造成很大的債務危機。需要對您的系統持續改善，減少過去專案殘留的問題，同時也可藉此提高團隊整體的開發設計能力。

2012年3月7日

Java重構工具(Refactoring Tools)整理

作者: Fred Wang (FW知識瑣記) 日期: 2012/3/7, revised 2012/4/5

網路上許多重構工具版本都相當老舊，也沒有新板產生。早期一些重構工具的網站也已經關閉了。下面是一些現存Java重構工具的整理 :

1. Eclipse提供的20多個重構功能

2.RefactorIT : 自動化重構, 原始碼衡量, 稽核與修正。可以單獨安裝或作為Eclipse與NetBeans開發環境的插件(Plug-in) ，Open Source : http://sourceforge.net/projects/refactorit/

3.JFactory : 提供15種重構能力的工具，可以單獨執行，直接下命令列或作為JBuilder, NetBeans與Elixir IDE的插件。 Open Source : http://jrefactory.sourceforge.net/

4.Transmogrify : Java程式碼分析與重構工具
. Open Source : http://transmogrify.sourceforge.net/

5.DPT(Design Pattern Transformer) : 研究用途的工具，提供prototype工具，以利對Java程式碼重構的設計與了解。 Free : http://dpt.kupin.de/

6.JavaRefactor : 小型的Java程式碼重構工具，為JEdit的插件。(http://plugins.jedit.org/plugins/?JavaRefactor)

2012年2月20日

雛型化設計對新系統開發的重要性

作者: Fred Wang (FW知識瑣記) 日期: 2012/2/20

Why You Need Domain Knowledge : 這篇文章由一把空氣手槍的設計，闡述軟體開發常發的困境，傳統瀑布式的開發方法往往在開發團隊花很多的時間與精力開發測試完成後，到使用者驗收測試，甚至上線使用，才引發使用者對系統大幅修改的需求，甚至根本不合End User的需要，然後，再耗費更大的精力重新設計，並大改系統，這對開發團隊的士氣是很大的打擊。

雛型化設計是開發一個新系統非常好也非常重要的方式，特別是使用者無法將需求描述清楚的情況，或者有可能如參考文章的情境，使用者往往要看到雛形會才能引發更實際的想法與需求。

2012年2月15日

Code Review的方法與工具

作者: Fred Wang (FW知識瑣記) 日期: 2012/2/15

Code Review的目的 : 越早發現問題，解決問題的成本越低

Code Review的層次 :

規範層次 : 避免資安漏洞與造成效能問題等，沒有遵循會造成嚴重的後果
推薦層次 : 避免造成未來可能的問題, 必要性較高的作法，例如異常值的處理等
建議層次 : 較好的寫法與習慣, 經過團隊同意列入參考的撰寫風格

Java Code Review Tools

CheckStyle : 靜態程式碼分析，顯示程式哪些地方違反訂定的程式標準(免費)
PMD : 基於靜態規則設定的Java原始程式分析器能夠指出程式中潛在的問題(免費)
Jalopy : 可以簡易地設定程式標準格式並偵測與修正程式中的錯誤(免費)
Hammurapi : 強大的原始程式檢查工具(免費)
Squale : 一種管理軟體品質的平台(免費)
Teamstudio Analyzer for Java : 以192條預定的規則檢查Java程式，並產生違反規則的報告。此工具也可以根據預設的樣式自動修正程式。(付費軟體)

Lotus Notes Code Review Tools

Teamstudio Script Browser : 協助檢視Lotus Script程式碼與程式碼間的關係(免費)
LotusScript Manager : Lotus Notes developers用來進行程式碼稽核的小工具(免費)

SAP ABAP Code Review Tool

Extended Program Check (SLIN) : 分析找到的錯誤，警示與訊息，指出可能造成執行期錯誤與其他嚴重問題的來源.(內建)
Code Inspector(SCI) : 根據效能, 安全性, 語法與命名規則檢查Repository的物件(內建)
Runtime Analysis : 衡量程式的執行效能(內建)

參考資料

Wikipedia, “List of tools for static code analysis”
Harshad Oak,”Three tools that make Java code review painless and
effective”,TechRepublic
Teamstudio Free Utilities: A Resource for Developers and Administrators
Erik Sodtke,“An Integrated Approach to Troubleshooting Your ABAP Programs”

2012年1月12日

UML各種圖示法的使用時機整理

2005.5.20 Fred Wang

UML有許多的圖示法可以使用, 我將這些圖示法的使用時機整理在一起, 作為專案使用時的參考:

Use Case Diagram
使用時機 : 在規劃階段根據使用者目標, 找出使用案例(User Case), 再畫出互動關係, 用來確認專案範圍及掌控專案。

Class Diagram
使用時機 : 專案的每個階段幾乎都用得到, 在分析階段, 分析從使用者角度看到的物件及其繼承關係, 在設計階段用來明確的定義實作階段要完成的介面(Interface)與類別(Class), 在實作階段則定義出屬性及方法(methods)作為系統文件。

Interaction Diagram – Sequence Diagram or Collaboration Diagram
使用時機 : 進入設計階段, 已經清楚定義Classes, 透過Interaction Diagram可以清楚的看出class間的互動關係

Package Diagram
使用時機 : 在設計階段當Class數量很多時, 可將Classes分類存於不同Package, 使用Package Diagram可以概觀的看出Packages間的關係。

State Diagram
使用時機 : 在設計階段, 單一物件有清楚的生命週期或狀態變化, 需要狀態圖才可將哪些事件造成哪些狀態的改變描述清楚。

Activity Diagram
使用時機 : 在分析階段用來分析一個使用案例(Use Case)內有哪些動作, 這些動作間的關係。(此時尚未定義物件Class, 還未將動作分配給Classes)。也可以提供設計與實作階段的重要參考。

Deployment Diagram
使用時機 : 用於分散式系統, 在架構設計階段用來表達可用元件(如EJB, WebServices)分散於不同的Application Servers的狀況。

最常用的四種Diagrams是Use Case Diagram, Class Diagram, Sequence Diagram 與Activity Diagram。

如何維護老舊程式

編著: Fred Wang 日期: 2007/11/14

超過十年歷史的企業，其應用系統開發人員，有超過60%的時間會花在維護既有的系統，而經常需要維護所謂的老舊程式，所謂老舊程式通常有下列三點現象: (1)目前的人員中，沒有人參與過這些程式的開發，(2)這些程式的開發未採取適當的開發方法，因此設計不佳，缺乏註解且文件說明不明確與完整，或經過維護人員的輪替，多人修改後，原來的文件已經無法參考，(3)結構缺乏模組化的觀念，例如相同的程式複製多處等。通常在維護此類的程式常遭遇到許多的挫折，對軟體工作者而言常視此類工作為低價值的苦差事。

對程式控制流程像義大利通心麵般複雜，一個副程式長達上千行，而註解只有三行，且找不到文件說明，維護人員遇到使用者提出需求，需要修改這種程式時，這種狀況可以有三種處理方式:

1. 硬著頭皮修改，奮戰到底，直到完成為止
2. 運用軟體工程的方法，將需修改的部分重新設計，撰寫程式和測試
3. 完全重新設計，撰寫程式和測試

通常小幅的修改，尚未考慮重新設計的狀況，如上面第1點，軟體工程界的大師Yourdon提出的十點建議 :

1. 平時應研究這些程式碼，儘可能獲取有關的背景資料
2. 嘗試熟悉程式的整體控制，不要一開始就研究程式的細節，最好能自己畫出高層次的流程圖 (Fred : 可以畫出SOD, ERD, IPO Chart等)
3. 評估既有的文件說明，若有幫助的話，可以在原始程式上加上註解
4. 利用編譯器產生的交互參考表和符號表等
5. 修改程式時千萬要小心，盡量保持程式撰寫的風格，更改地方要需註明原因與時間
6. 除非你非常確定，否則不要刪掉任何陳述
7. 原程式中的暫存變數和工作儲存區，不要用，應自行定義新變數，以避免麻煩
8. 紀錄詳細的維護內容和產生的結果 (留下維護紀錄)
9. 不要沒有理由的拋開一個程式，而重新撰寫一個。
10. 要加入錯誤檢查的功能

除了上面的做法外Martin Fowler的”重構-改善既有程式的設計”，提出漸進式且安全的方法以改善程式的品質，這是近年來我看到最實用與最好的軟體工程書，極力推薦每一程式設計人員熟讀與應用。

有些人會認為重新編寫一個會更好，但是如果這個程式攸關安全，如生命，健康，財務，營收，客戶服務等關鍵流程，錯誤時將造成極大的風險，那麼就不是簡單的重寫就可以的。

就與重新設計開發有關的議題，做預防性的維護可以改善整體的設計，此類的維護就使用者角度，對其功能並無變化，乍看之下，似乎很浪費，但是對IT未來龐大維護成本將可大量減少，下面是Roger Pressman提出的幾點考慮 :

1. 維護一行原始程式的成本為當初開發該行程式所需成本的40倍
2. 以現代的設計方法，重新設計軟體架構，可以大量簡化未來的維護工作
3. 若有較佳的範式(prototype)，生產力將提高甚多
4. 使用者對此軟體的使用已經有經驗，因此修正的方向更容易確定

預防性維護可視為軟體的新版本，主要目標在”應用今日的方法與昨日的系統以滿足明日的需求”。

2012年1月4日

ZDNet軟體工廠一文之閱讀心得

作者: Fred Wang 2012/1/4

ZDNet軟體工廠(http://www.zdnet.com.tw/members/1000101720/blog/?v=post&id=10000198)

製造業不管是汽車或電子等，都經過早期手工時期，為了大量製造，開始了生產線標準流程，但是軟體業為何仍落在手工業時期，而少導入生產線製造模式，快速生產組裝，主要在於軟體不需重覆生產與大量製造。

但是，如何思考以工廠製造與經營方式改變軟體開發的現狀是在軟體工程領域不斷被研究與討論的，近年來就是Web Service, SOA等，而軟體工廠更包含標準化與自動化的作業，組裝，測試與品管, 而軟體設計師等同與產品設計，IC設計，設計完成後就進入軟體工廠，元件部份則有專業的元件工廠製造軟體元件提供下游廠商使用。

這是一種理想，而MIS嚴格來說應該是產品的使用者，將產品導入並應用在業務上，就角色與資源運用上都並不適合定位為軟體工廠，但是仍可採用一些標準化的精神與自動化的工具協助改善現狀。

我主修軟體工程，也了解許多MIS在採用軟體工程過程的困難，身為主管應該在不影響工作目標下，推廣與鼓勵以更理想兼具品質與生產力的方法開發系統。

相關文章

1.軟體開發生產線化探討
2.企業應用系統的開發生產模式探討

2011年12月8日

[專案管理] 解救您的專案 - 如何面對不斷變更的需求

作者: Fred Wang 原作日期: 2011/10/2

如何面對不斷變更的需求，要了解為何客戶會不斷變更他的需求，有沒有可能是派來談需求的代表，對業務的需求不夠了解，專業能力不夠，提出的需求代表性不足，提出的不是最終用戶的需要，也許是對系統化過程經驗不足，也可能是尚未成熟的需求(只有想法)，或許是新業務或變動大的業務，尚無法訂定明確的需求。這些問題要先了解，才能真正找到問題的根源。(先確認到底專案所有相關影響人有哪些，他們的期望與需求各是什麼，客戶的代表是否有足夠的授權）

解決不斷變更的需求，需要建立一些管理程序，而這些管理程序也要看雙方合作的經驗與信任的關係，如果合作經驗少，信任度尚未建立，需求分析與變更管理的過程都需要更嚴謹(成本較高)的方式來進行。

1. 需求蒐集與分析

a.專業的了解 : 系統分析師不僅僅只是蒐集客戶的需求了解客戶業務流程，還須對客戶的產業與專業領域有更多的了解，最好也懂得以一些大型系統作為最佳案例，例如SAP ERP各模組功能，在需求討論的過程可以提供客戶一個比較好與正確的引導，以期能讓客戶對需求考慮完整周詳，減少未來的需求變更。當然要求SA具備專業顧問級的能力，可能不太容易，但是這個能力的大小將直接影響專案的進行。一些大型專案(在中大型公司)會引進專業顧問，將業務流程標準化與合理化再進行系統化。

b.需求溝通會議 : 需求的提出與需求變更，透過正式的需求溝通會議進行，任何決議都有紀錄，紀錄都有簽字，且須通知主管，而不是一通電話或eMail私底下就決定，如此會讓客戶(需求提出者)，更審慎地制定需求與嚴格地面對變更。

c.雛型化需求確認 : 由於使用者的需求變化大，也許是業務面變化大，也許是新的業務需求，可以採用雛形化的需求確認方法，透過多次需求訪談，快速雛型建立與確認，將需求談定。如果系統龐大，則應該區分功能模組，逐一確認模組。d.

d.使用高生產力的工具 : 由於雛型開發法可能的成本高於瀑布法，因此，使用可以快速開發雛形且未來容易轉換成實際系統的工具才有較好的生產力。

e.累積經驗 : 最好每次專案可以累積一些雛形，樣板或模組化的功能，不同應用領域累積不同的專業經驗與設計雛形，可以讓這個過程能夠更為快速。當然對於需求不明確的專案，專案經理必須估較長的需求確認時程，與雙方談定需求確認的方法，以避免爭議。(需求合理性是另外一個議題)

2. 系統設計

需求變更是專案過程中常見的現象，因為需求變更造成整個架構變更，全部或多數程式要重寫，都是系統設計開發人員要設法避免的。因此有經驗的設計開發人員會採取彈性的設計與開發手法，預先考慮可能的變更，提供系統較好的彈性，重點列出如下 :

a.彈性的架構 : 將系統設計得更為彈性，讓變更時的影響最小，設計的彈性包括系統架構每一層次都獨立化(如使用者介面與商業邏輯，資料處理區隔, Web設計上Javascript, CSS, HTML區隔，使用MVC架構等)

b.程式模組化 : 系統的開發最理想的是像堆積木般，將既成的模塊加以組合就可以完成整個系統，也就是採用庫存程式庫，再加以組裝。或是先用標準的庫存程式建立半成品(標準次系統)，在上面加以客製化的程式來完成整個成品。

c.參數化設計 : 系統中可能變動的部分予以參數化，可以透過一個設定檔或介面進行變更，這些參數可能是系統參數或由使用者自行變更的業務參數。

這些能力與開發團隊累積的開發與系統架構的經驗與累積的程式庫有關。

3. 變更管理

a.將變更管理列入合約 : 專案一開始就跟客戶談好變更的方式與流程，而且要在合約中註明。另外，上線後提供多久或多少次的變更支援，在合約訂定保固的條文。

b.保留彈性的時間 : 專案時程最好也留下一些彈性的時間可以面對一些小型的變更，而會影響時程的大型變更就須雙方談定否則不能貿然進行。

c.變更過程要有變更記錄 : 專案會議需有會議記錄外，變更也需有變更紀錄以記錄需求變更的原因，變更的單位與負責人，主管，進行變更的影響分析，造成的成本增加，對專案時程的影響等，且必須雙方負責主管同意才能進行變更。

特別是對專案越後期的變更，造成影響越大，如果沒有做好變更管理，釐清責任，將大幅提高專案的風險。

如同軟體品質管理，要做到多嚴謹，訂定怎樣的品質標準與要投入的成本多少有關，需求與變更管理也是一樣，都應該有成本觀念。多數專案的失敗，往往發生不斷延長的時程與不斷增加的成本。

推薦相關閱讀 :

1. 怎樣控制需求變更 , ITEye, 2008/11/5

2. 企業如何應對客戶不斷變化的需求，2011/6/10

3. 需求總是變化，程序總在修改，2011/5/19

2011年11月28日

Information Dashboard的設計程序

作者 : Fred Wang 原作日期 : 2010/06

以下內容根據自己的經驗並參考Business Dashboards – A Visual Catalog for Design and Deployment”一書整理而成。

Dashboard開發專案的角色

Project Manager –負責專案計畫與管理
Data Architect –熟悉Data Warehouse, cubes及資料整合技術
Data Source Expert– 熟悉資料來源及其存取方式，如DB Connections，Data Tables and Fields，Access Rules
Dashboard Expert–熟悉Dashboard設計軟體與Dashboard設計方法
Business Unit Manager/Key Users–了解業務需求與能夠提出希望看到與分析的Dashboard需求
IT infra. Support–提供Server, Network, Database等技術支援

設計程序

1.業務需求分析

1.1 設計衡量指標與KPIs (Information Design)

請參考“Business Dashboards – A Visual Catalog for Design and Deployment”一書,第五章

1.2 選擇展示的方法並與用戶進行互動(建立一個故事板stody board)

a.使用工具如 Pen and Paper, Whiteboard, Powerpoint or Dashboard Prototyping Software

b.可參考templates, samples, best practices

c.運用元件包含 :

Charts, Gauges, Tables…
Warning and Alerts : Traffic lights, arrows, trend…
Interactivity : Drill Down, Annotation, Actions…

1.3 確認需求與使用者簽字

2 使用者介面設計

2.1 參考 best practices, samples and templates : 應了解正確的統計圖表與Dashboard設計表達方式

2.2 外觀佈局(layout)設計

a.顏色選擇 : 避免過多的顏色或依賴顏色表達重點，可以用對比方式突顯重點 (部分人士有色盲與辨色力問題)

b.字型種類與大小 : A.避免混用不同的字型，建議英文用Arial，中文用標楷體 B.避免使用太多不同大小的字型 C.避免使用太大或太小的字型，特別是中老年的使用者避免太小的字型 D.建議標題用12 or 14 pixel粗體字，一般文字用8-12 pixel的字

c.Dashboard大小: 設計大小應適合於使用者螢幕單一可視範圍，避免產生捲軸，當單一可視範圍無法放置所有的設計元件時，有幾種設計方式

使用可以展開與收合的元件
使用層疊的元件，透過按鈕或其他選項切換
使用Tab元件切換
使用多個Dashboards，用選單，按鈕或連結切換檢視Dashboards
使用參數過濾資料，顯示使用者要看的內容，例如使用時間選擇元件選擇某一季來顯示統計圖，而不是顯示4個圖

d.元件放置 : 如果有超過兩個以上的tables, grids , scorecards or charts應如何放置

與key users討論，哪些資訊最重要，通常依重要性由左至右，由上至下排序
根據控制流程由左至右，由上至下排序，例如先看Scorecard，才會看趨勢圖，然後點特定指標值，顯示明細的Charts

2.3 給定Dashboard標題與元件的標籤

2.4 設計核心的Dashboard功能(如filters，drill down, alerts, etc)

a. 定義控制流程
b. 決定展開路徑(Drill Paths)

2.5 展示Dashboard雛型給使用者，得到使用者建議, 修正與核可

3. 資料與系統設計

3.1 資料模型設計

a.決定每一元件的資料來源

b.決定每一個UI Component的資料格式與計算方式

c.決定所需歷史趨勢資料的保留方式(Data Warehouse)

3.2 Data Model轉換, 來源資料與顯示Dashboard所需的資料格式與粗細度可能不同，需經過計算或轉換後才能做為Dashboard的Data Model

3.3 系統設計

a.決定資料的存取方式

b.設計OLAP Cube的結構

c.設計整體架構，包含網頁設計，使用者權限等

4.架構設計 (略)

從專案角度可以分下面幾個步驟

1. 組成專案團隊

2. 建立專案計畫

3. 檢視衡量指標與KPIs

4. 根據風險，機會與成功要素排定Dashboard實作的優先順序

5. 開始外觀佈局(layout)設計

6. 定義軟體,硬體,安全與架構需求

7. 得到關鍵利害關係人的核可簽字

8. 開始建構dashboard與相關系統(包含測試)

9. 訓練使用者

2011年11月26日

彈性應用系統平台十種設計方向(Flexible Application Platform 10 Design Approach)

作者 : Fred Wang 日期 : 2011/11/26

甚麼是一個高彈性的應用系統平台，可能具備下面的彈性需求類型 :

a.使用者操作彈性，b.彈性可調整的外觀，c.支援多前端平台，d.功能可擴展性，e.開發人員分工協同設計，f.程式高度可再用性，g.彈性支援多種後端來源資料儲存與傳送方式，h.可彈性擴充後端支援的硬體

是否有機會做到呢? 下面提供一些設計方向，可以依據所需的彈性需求類型組合參考下面的設計方向來建構。在此僅說明設計方向，至於實現的技術需要獨立專文討論。

一，使用者介面個人化設計 : 如iGoogle，myYahoo等個人化入口網站，提供End User有限度地調整自己個人網頁要看的內容。

二，使用者外觀與資料分離式設計 : 將外觀如theme, styles抽離網頁內容，在Runtime時由展示層(Presentation Layer)動態組合成網頁後呈現到使用者前端(Client)，好處是可以獨立設計與調整外觀Theme，並可切換不同的Theme，這種設計在許多系統都已經實現，特別是WCM系統，IBM Portal, Quickr等。有些平台提供設計師上傳預先設計好的themes或styles檔案的介面，有些提供使用者介面(UI)進行Themes與styles有限度的微調，並可以儲存自訂的Themes與styles。

三，多重網路協議層設計 : 為了支援多種的使用者前端如Web Browser，內嵌式設備，行動設備或自行開發的應用前端(application Client) 如Flex, Adobe AIR等，在展示層增加一個層次用來處理多種的網路協議(protocol)，將這些前端訊息格式轉換成一致的格式傳給後端層次的成式處理，也將後端層次的層次處理或抓取的資料轉成前端訊息格式回應給前端。

四，MVC架構或多層次架構設計 : 將不同類型的處理分層，一個層次的程式接收前一層的資訊加以處理再轉交/呼叫下一個層次的程式或透過委託程式(delegation)分配給後一層次的程式處理。這種設計可以提高功能的可擴充性，而且有利於大型專案的專職分工。

五，程式模組化設計 : 這是程式設計入門學問了，程式設計師必需具備的高內聚力，低耦合性等模組化程式設計素養，不管是前端的Javascript,邏輯處理的Java等都平常都要養成模組化設計的習慣，而團隊則要做好共用模組的管理，如測試，驗證，品檢，文件製作等才能提高再用性的效力；另外，Design Pattern與software framework的運用也是很好的方向。

六，Metadata結構設計 : 在資料庫的資料表(data tables)前增加Metadata層，程式不直接存取實體的資料表，而是存取Metadata層結構的資料，而Metadata與資料表的轉換有專屬程式處理，例如:Metadata與Oracle資料庫間有一組處理程式，而Metadata與MS SQL Servr資料庫間又有另外一組處理程式。此種設計廣泛出現在Data Warehouse，而知名ERP軟體SAP也是採用此種設計。

七，高度參數化設計 : 將系統中任何可能變動的參數甚至一些判斷邏輯從程式抽離，並設計使用者介面(UI)提供管理者進行調整。這些參數又分為系統參數與業務相關參數，可以區分不同權限管理。多數商用系統應該都有這樣的設計，很多是儲存在.ini檔中，而較好的是提供使用者操作介面，例如SAP的Configuration。

八，可客製物件設計 : 這種設計是將商業的元素物件化，例如:訂單是一個物件，訂單項目是另一個物件，每個物件有標準欄位與可自訂欄位，欄位值可以設定預設值公式，欄位檢查，並可以設定物件間的關聯，部份看起來是資料庫管理系統的作業，部分應該是程式中處理的，有些系統如Force.com將這些動作完全提供使用者介面，透過畫面以簡單的操作完成設定。

九，彈性資料表設計 : 這個設計是資料庫內表格設計的一種技巧，例如，物料主檔各類型的物料屬性不同，如果採用聯集，會設計出一個欄位超多的資料表，儲存資料時也將產生許多的空值或預設值，浪費許多的儲存空間。因此衍生彈性資料表設計，就是區分預設欄位資料表與彈性欄位資料表，前者包含key欄與一些共同的必要欄位，這些欄位可以設定索引快速搜尋，後者包含Key欄，屬性名稱欄位，型態欄位與內容欄位。

十，虛擬化與雲端化的基礎架構設計 : 這是近年最夯的IT話題，主要好處就是高擴充彈性的基礎架構(infrastructure)，服務容量將要不足時可以隨時加入硬體伺服器，任何一台伺服器要維修也可以不影響營運下抽離。有兩種不同種類的技術，一種是VMWare,Xen的虛擬技術，一種是Google Hadoop, MapReduce等技術。

作者: Fred Wang(http://fredwang.blogspot.com)，麻煩參考時請註明出處，本網站的連結，否則視為侵權。

2011年11月12日

軟體開發生產線化探討

作者 : Fred F.M. Wang 日期 : 2011/11/12
軟體開發團隊的成功要點包含設計建立程式元件與累積程式元件庫並建立高效率的生產線，因此，要改善軟體開發效率可以將流程生產線化，並區分系統與元件兩類生產線。
1. 系統生產線。
a.根據不同技術平台建立不同的系統生產線，如SAP, VB, Java等。
b.技術平台應單純化, 避免過多的生產線; 架構也應單純化，避免太多類型的設計架構讓開發流程,無法標準化與一致化。
c.應妥善運用庫存元件,樣版與架構，如果沒有適當元件則會建立系統專用元件。
d.檢視系統專用元件是否具備可再用性，經過審核與品檢後納入元件庫管理。
2. 元件生產線
a.根據商業各領域知識,專家經驗,最佳典範與既有系統開發領域相關的功能元件,或樣版。
b.根據現有系統經驗與開發經驗開發公用元件,或樣版。
c.元件取得也可以透過外界取得,購買或外包開發,提高效率。
參考這篇文章 : "ZDNet基於構件技術的企業MIS開發及應用" 加以修改成下面生產線圖

企業應用系統的開發生產模式探討

作者 : Fred F.M. Wang 日期 : 2011/11/12

一般企業IT應用軟體開發模式相較於四種製造模式是屬於接單生產，雖然較容易貼近客戶的需求，但是資源的運用與TAT較差。本文將介紹四種製造模式之優缺點比較。

Build to Order 接單製造 : 完全根據客戶需求規格打造產品
優點:完全符合客戶的需求
缺點:生產單位需要不斷配合客戶進行產品與製程的變更,效率較差,TAT長

Configuration to Order(CTO)接單裝配 : 將零件模組化,接單時再裝配為客戶需要的產品
優點:生產效率較接單製造高,對產品客製化與變更的彈性也較後兩者大
缺點:可能無法完全符合客戶的需求

Build to Assembly 組裝製造 : 先製造半成品,接單後再進行組裝完成成本
優點:生產效率較前兩者高
缺點:可能無法完全符合客戶的需求(半成品需要經過客戶認可)

Build to Stock : 製造標準化產品
優點:可以計畫性生產,生產效率與資源運用最好
缺點:無法完全符合客戶的需求

IT若要縮短應用系統開發時程，又能盡量滿足客戶需求，應朝接單裝配或組裝製造的方向規劃。配合有效的專業分工與產能(內製或外包)控制,成熟的程式元件庫或樣版(半成品)，

2011年11月11日

軟體工程方法論與IT政策

作者 : Fred F.M. Wang 原作日期 : 2004/08/12

企業在進行一項軟體專案除了專案管理方法外還會引用一套軟體工程方法(Methodology)來完成應用軟體的開發或實作。而採用的方法往往會與使用的技術或專案的特性相關，而專案管理方法也可能與採用的實作方法相關。例如: SAP ERP導入會採用SAP的ASAP Methodology, 而J2EE Project業界流行的是RUP或XP, 而RUP及XP各有一套專案管理的方法，也各有適用的狀況，RUP以Process為主體，XP以人為主體，RUP適用於60人以上的專案而XP適合於現有系統的改善或小型的專案。

企業在方法的選擇及使用的技術會根據其管理的角度訂定IT Policy，而不同管理層面的考慮的優先順序將對企業的成本與效益帶來不同程度的影響。

軟體工程方法論的採用及選擇

筆者在二十多年前研究所階段就以軟體工程方法論的研究為主，最早的軟體工程方法論源於工業工程方法，由於軟體技術的演進及軟體應用層面的擴大，傳統的方法論以經無法適用於各種應用的開發，因此衍生出許多現代的方法論。而這些方法論無非是用來解決應用需求轉換為軟體系統的問題，協助軟體專案從需求定義，系統建構，上線等過程提供系統方法來完成專案。採用軟體工程方法論的目的整理如下:

使用者，分析師，與程式設計師等專案人員有共同的語言
一致的程序及交付項目
以系統的方法增加成功的機率
提昇專案品質
提高專案的可預測性，及早發現問題
成功經驗可以經過文件加以傳承
提高專案的效能

如同軟體工程方法論的演進史，不同的方法論是因應不同種類的應用才產生出來的，因此IT Policy應該制定選擇方法論的程序，而非限定單一方法論的使用。

應用系統架構程序

大型與複雜的系統往往無法用單一技術元件完成，特別是近年來J2EE的專案，因Internet而盛行，J2EE Project往往會牽涉多種技術，因此在架構系統的過程更形重要，Architect需在專案範圍，風險，專案時程及資源預算等限制下訂出應用系統的架構，此架構可能包含應開發的元件組合, 選用產品及APIs等，當然IT Policy也是限制之一。由於專案的內外部限制已經很多，因此IT Policy在產品或平台的選擇方面，若過於僵化將使專案的進行更形艱難。

最佳軟體方案(Best of Breed)，單一供應商與自行開發的決策

企業在選擇軟體系統解決方案，會有三種可能的選擇最佳軟體方案(Best of Breed)，單一供應商與自行開發，而這三種方案的決策會受下面的條件的影響:

企業現況及需求，包含企業規模，組織，需求的範圍及條件等
預算與投資
技術或產品的成熟度與市場的趨勢
資訊人員的技術能力

以SCM Solution為例, 此三種方案比較如下表:

(另外, 近年使用Open Source或租用則不列入比較 – 2011/11/11)

由上表可知，若政策上要求企業需求適用性為第一考量，則會以Best of Breed及自行開發為主。

不同企業採用的策略不同，年營業額七億以上的Starbucks以Oracle ERP為主幹，再以Best of Breed的方式選入其他產品作為該企業SCM Solution。而年營業額七千四百萬的Green Mountain Coffee Roasters則採用單一廠商產品的解決方案。但是Wal-Mart仍採用自行開發的方式。

以特有與創新的經營管理模式取得市場優勢的公司，往往無法在市場找到適合於此模式的產品，因此傾向於自行開發，如Wal-Mart，其條件是需擁有專業的資訊科技部門。

由於許多較具規模的企業，其業務型態較為複雜，資訊科技於商業應用領域也較為廣泛，因此單一產品往往無法滿足於各項應用，因此也會傾向於採取Best of Breed的方式，如Starbucks等，來滿足快速成長的商業應用，但是業務型態單純及規模較小的企業容易選擇合適的產品以完成企業的需求此時將傾向於選擇單一套裝軟體以減低IT人力成本及整合成本。

因此IT政策在解決方案策略的訂定，應該優先從企業規模及商業需求為優先考慮，以因應企業快速變化的需求，例如，可以制定選擇解決方案的優先順序或不同狀況及不同條件下該採用何種解決方案。

不同產品的適用領域與架構設計師

不同的產品、API或Solutions各有其適用領域，根據筆者的經驗，一個具備一般WCM功能網站用WCM產品與採用Jakarta Struts framework開發的時程差異為一比九。而Document Management System及Workflow System上Lotus Notes優於SAP，Transaction Process則SAP優於Lotus Notes，而開發平台上Domino Designer的彈性優於SAP ABAP Workbench，但SAP Workbench開發速度較快。若某項需求適合用Lotus Notes完成，卻錯誤的選擇用SAP開發，那麼開發時程可能就需花費如上面九倍或更長的時間。

軟體架構設計師(Software Architect)在此的角色，就相當重要，軟體架構設計師是計劃並監督建構過程的軟體技術設計人員，主要的任務就在規劃與系統架構層次相關的事務，評估可能的風險與成本，並有效運用有限的人力、物力資源達成系統層次的需求，因此除了是資深技術人員，通常也是策略制定、組織協調好手、稱職的顧問與領導者。

一位好的架構設計師通常具有以下專業領域的技術素養：

企業需求
硬體與軟體架構
分析、設計與開發
產品支援
效能、安全性、容量規劃(capacity planning)、網路

架構設計師在專案過程中的角色:

研擬最初的高階架構藍圖(blueprint)並列出影響架構可能因素的清單。
審慎評估付諸實施的專案計劃對系統既有基礎結構(infrastructure) 與架構的衝擊，以及計算可能付出的成本與所帶來的效益而訂定。
制定專案的架構決策與其優先順序的判斷基準、定義問題領域 (Problem Domain)、決定可能解決方案的限制條件、確認有關可能解決作法的假設狀況以及辨識模組重用的可能性。
負責確保需求的達成，以及硬體、軟體、基礎結構、效能、安全性、容量、可用性和系統運作、管理與維護等等屬於系統層次相關技術之間的協調與平衡。
構建架構時期，預先列出這些可能的風險，然後在後續的開發時期配合開發人員予以適當地處理與解決。
領導開發團隊，保持與其它成員的良好互動，確保開發人員是根據架構藍圖來構建系統。

因此企業應重視軟體架構師的人才培育與投資。在政策上也應訂定正確的方法來進行軟體開發專案。

訂閱：文章 (Atom)