牙套男IVANTHEGREAT

面積對比是對二色或二色以上的相對的面積比例而言。因此，面積的對比也就是色面積的大小的問題。

各種色彩都可以任意大小的面積描畫出來，但對於二個以上的色，各個色面需要怎樣的面積比，才能顯得更美，或才能得到安定的均衡，這些問題都需要解決。
純色的明度與面積，是決定純色面積的均衡的兩個要素，若要了解明度程度，把純色放在近似等明度的灰色上，再比較其明度，最後以無彩色明度系列，測定純色明度。每個色經實際測定，就可知道各色向的純色，其明度皆相異。

歌德（J,W.Goethe）所定的純色明度數比如下：

黃：橙：紅：紫：青：綠
9：8：6：3：4：6

代表性的三組補色的明度比如下：

黃：紫＝9：3＝3：1＝3/4：1/4
橙：青＝8：4＝2：1＝2/3：1/3
紅：綠＝6：6＝1：1＝1/2：1/2

把這些明度比，置放在調和的面積上時，面積與明度成反比的關係。換句話說，黃與紫的時候，由於黃對紫有三倍強的明度，所以只要有紫面積的1/3，就可保持均衡。

如113～115圖所示，關於補色，可求得如下的面積比調和。

黃Y：青紫BP＝1/4：3/4
橙O：綠青GB＝1/3：2/3
紅R：青綠BG＝1/2：1/2

除此之外，其他所有色彩也能同樣考慮。
這些面積比，都互相保持均衡，因此，每個色彩都顯得肅靜，有安定的調和，但於構圖上，使用面積對比時，只能得到中庸的效果。
以上所述的面積比，只適於互為純色的情形下，若改變明度時，面積比也隨著改變。
假若均衡的面積比以外的要素，如有明暗的強烈對比時，一色作為主色，他色作為配色，因此，對比變化較為明確，則這個構成變為富於變化的，有生氣的東西。

因此，於表現的時候，怎樣的色，使用怎樣的對比，是依主題，美術上的感覺及個人的趣向而不同。
於面積對比時，小面積的色與大面積的色，保持均衡，是由於我們對比刺激感覺均衡所致。
若使用兩個互相強調的對比時，可得到很有活躍感的，有變化的色彩表現。
面積對比的特徵是，對其他對比的效果，可予以強調或柔和。
於明度對比那一章中，已提過比例，實際上，面積的對比，也就是真正的比例對比。
於明暗的構圖，只有一小部份的明色，與大部分的暗色的面積對比時，這個對比擴張於畫面全部，能予以有深度的重要性。

因此，在於構圖（composition）時，能注意到色彩的面積，比色彩的選定還要重要。任何配色，都需要從相互間的色面面積比來檢討。
色的面積，要以色的明度，彩度，形狀，範圍，輪廓來決定，對於此種表現不可以毫無準備或毫無計畫。
對這一點，尤其要留意的是需要決定正確的色彩面積。色彩面積的大小，並非由輪廓線來作明顯的拘束，因為將受到來自色相，彩度，明度及對比效果，所產生的色彩比例所支配之故。

113～115圖，是表示著下列各記的面積

黃Y：青紫BP＝1：3
橙O：綠青GB＝1：2
紅R：青綠BG＝1：1

116、117圖是黃橙色的變化範圍。

青的變化範圍＝10：15＝2：3
紅紫的變化範圍：綠的變化範圍＝10：10＝1：1

118圖的黃與白，青與白的面積比為：
黃：白＝3：1
青：白＝5：2

以這種分割比，作成均衡的構成圖。
119圖是由純色的紅／青／黃與白／黑的5個色面所成，考慮純色與明色的彩度的面積比，在此，以高彩度色所佔的面積最小與高明度的大面積成均衡。
120圖是住宅展覽的廣告，是黃綠YG：紫P＝2：5，非常單純，但充分表現明快感，這個輕快感，來自背景色的黃綠，面積比均衡之故。

Filed under: 色彩原理 | No Comments »

Filed under: 印刷實務 | No Comments »

最新版OmniPlan 1.6.1

相關軟體 OmniWeb│OmniGraffle│OmniOutliner│OmniFocus│
OmniDazzle│OmniDiskSweeper│OmniObjectMeter│OmniDictionary

OmniPlan 提供了 Gantt 圖表、摘要匯總、進度里程碑、排程、時間追蹤及記錄等等工具與專案，讓您更加善用資源與預算，讓專案管理更加輕鬆與方便。

How to get your project done on time and under budget:

· Translate strategy into tactics everyone can understand

• Create summaries of work broken into lists of activities

• Distribute workloads fairly and efficiently

• Manage costs as you go

用戶介面

User-Friendly Interface

OmniPlan簡單的操作頁面，提高了您工作的效率，而不用花時間去研究怎麼樣去操作軟體。人性化的設計，令您的工作更加隨心所欲，並且自動幫您處理複雜的函數。

We designed OmniPlan to help you spend your time on more worthy pursuits than trying to figure out how to use project management software. OmniPlan’s intuitive approach helps you get things done and stays out of your way while doing so. OmniPlan has several customizable views starting from “simple creation” for basic planning options; when you’re ready for more sophisticated functions, OmniPlan can be configured to meet your needs.

支持Leopard

Leopard Support

OmniPlan在強大的Mac OS X技術下，具備OS X 10.5 Leopard的特點。例如Quicklook功能，可以在OmniPlan中直接查看關聯的檔。

OmniPlan is built to use the latest and greatest Mac OS X technologies including OS X 10.5 Leopard features such as Quicklook which you can use to preview your linked files from within OmniPlan.

Live Filtering 任務篩選

通過強大的工作任務篩選功能，將複雜的專案有序的分開。只需要輕輕點一下您的滑鼠，就可以任意選擇你需要的專案，OmniPlan會自動篩選出您需要的那些專案。

Cut your complex project down to size using our powerful live task filter. You can select any number of criteria and OmniPlan will give you a live, filtered view of just those matching items. Need to see all tasks groups from your current selection assigned to a particular resource? Live filter it with a few simple mouse clicks.

Fine Grained Time Scales 精準的時間表

讓OmniPlan為您的項目設置精確的時間表，年，月，日甚至是分。

We let you set the time scale that’s most appropriate for your project, whether that’s  days or months, minutes or years. You can even snap the timescale to fit in your entire project, letting OmniPlan take care of it for you.

Easy Task Management 簡單的任務管理

您可以輕鬆的分配任務資源，通過摘要快速進入任務，追蹤任務等。你可以清楚的瞭解專案進度。

Tasks are the activities needed to complete your project (”survey beta testers”, for example, or “drywall the bedroom”). They are summaries of work broken into individual elements, to which you can then assign resources (”Bill”, or “vinyl flooring”). OmniPlan lets you enter tasks quickly in the outline view, in a familiar hierarchical format that simplifies complex projects with summaries and subheadings. You can track the costs associated with your tasks (resource cost, task cost, and total), view task constraints and dependencies, and create milestones that represent completion points in your project — all within the outline view. You’ll have a clear understanding of your project’s goals and deliverables in no time.

Efficient Resource Allocation 最有效的資源分配

通過OmniPlan在您的專案預算內準確地，有效地分配人員，材料，設備等資源，

With OmniPlan’s resource management, you can identify bottlenecks in your project, track budgets, and distribute workloads fairly and efficiently. Resources are defined as Staff, Material, Equipment, and Groups. OmniPlan allows you to assign a cost to each of your resources by use or by hour, so you can keep precise control over your project budget. You can control your resource availability with a calendar, and make adjustments to reflect efficiencies (for example, assign a 75% efficiency to a staff member who can only devote ¾ of their time to your project). OmniPlan’s resource leveling function automatically redistributes workloads among resources, so you avoid overallocation.

Smart Scheduling清楚的行程安排

一個完美的工作行程安排，可以幫助您瞭解並且控制專案中所有的細節。

A good schedule helps you understand the details of your project and improves your ability to keep everything on track. Your OmniPlan schedule shows you what needs to be done, when it can (or must) be done, and who’s going to do it. Tasks can be scheduled according to a variety of rules – as early as possible, on a specific date, or as resources allow. OmniPlan’s calendar mode gives you options for determining work week schedules for your resources, and editing specific dates as needed. Once you’ve completed and fine-tuned your project plan, OmniPlan lets you set a baseline (a set of original start and finish dates, durations, and work/cost estimates), which acts as a reference point against which you can compare the actual progress of your plan.

Visual Timelines 直觀的時間表

通過Gantt 圖表直觀的顯示出專案開始完成，以及每一個環節的執行時間，令您便捷的管理專案進度。

The Timeline (or Gantt Chart) view of your project displays activities in a calendar. Durations for each task are shown graphically in a time-phased diagram by day, week, month, quarter, or year. The Gantt view shows task start and stop times, dependencies, resources, or resource usage by task, all on a timeline. You can visually edit tasks and create dependencies (where a certain task can’t begin unless another has finished) by dragging and connecting them in the Gantt view. OmniPlan’s graphical display of your project’s information helps you quickly assess status and proactively manage deadlines.

Filed under: 資訊多媒體 | No Comments »

處於日前這個知識經濟爆炸的時代，個人、企業需要處理更新的內容與日劇增，過往繁複的內容處理流程，隨著時間與組織的成長，讓太多過時、錯誤的內容無法及時更新，以難以正確挖掘長久累積的資訊，找出並修正過往資料。 CMS 正是為此問題而衍生，並提供全面的解決平台。包含了完整的內容管理流程，從友善、簡易的內容創作介面，經由散布、刊登到最後的彙集與管理，以及客制 化的網站管理架構，內容刊登的呈現模式，以及使用者的導覽方式等。筆者在此與各位分享一套以PHP開發的開放源碼CMS — Drupal. 

Drupal 

Drupal(droo-puhl)是荷蘭語“druppel”的發音，英語意指微量、簡潔的意思。其原始碼 版權宣告採用GNU GPL。秉持著協同、標準化、開放源碼、高品質、容易使用、模組化彈性設計及低資源需求為設計宗旨。目前的版本有三個分支(4.5.x、4.6.x以及 4.7.x)，相對軟體的支援程度如下表： (表1) 

Drupal也提供了完整的線上手冊，若欲深入研究，可參考官方網站(http://drupal.org/)或台灣中文支援站(http://tw-drupal.info/)。 國內外已有相常多的文章、論文與著作，討論如何評估與分析CMS。諸如以小中型企業為主的《Open Source Content Management Systems for Small and 

Medium-Sized Enterprises》<註一>，或是中大型企業為主的《How to evaluate a content management system》<註二>。從簡單的幾項分析項目到複雜至極的數學矩陣<註三>皆有，端視個人與組織的需求而定。 嚴謹的評比，必需考慮組織架構、目標，或管理人員與技術人員等面向。在本文中，僅以程式開發者的角度，簡化繁雜的分項評比，提供常用的分析項目，並說明Drupal在此項目上見長的特性。 

1.中文支援 

目前仍有許多開放源碼軟體並未針對中文進行額外處理。諸如中文化介面的翻譯、中文字串搜尋的問題等。若需要對此軟體作事後中文修正，則需付出更多的人力成本。 Drupal在其原始碼底層直接以UTF-8設計，以解決多國語言上的問題，也能夠處理繁體中文的搜尋問題。中文化介面的翻譯上，也有熱心的社群<註四>提供中文化的版本。 

2.效能 

執行效能對於營運的正常運作有顯著的影響，如何以最低資源成本，最快的處理速度，發揮至可接受的程度，也是評估上常見的議題。 Drupal使用Apache、PHP與MySQL/PostgreSQL建置而成，在速度與穩定性上，已為許多企業所青睞並採納。在資源成本上，相較於plone官方網站建議至少1GHz處理器與512MB記憶體而言<註五>，在硬體需求上較小。 

3.安全性 

筆者在此探討狹義的安全性，即專注於CMS本身的軟體層面上。網路上充斥著SQL injection與XSS(Cross Site Scripting)等攻擊，對於網站的永續經營、顧客資訊與敏感文件的保護帶來衝擊。這個問題視該開放源碼軟體在開發過程中，對於輸入驗證等安全項目關心的程度。 Drupal對於安全性有較嚴謹的態度，相較於其他開放源碼CMS而言，至今發現的安全漏洞較少，而且其開發者與擁護者眾多，使得臭蟲與安全回報制機上較完備。 

4.維護性 

維護性泛指擴充性、人力資源與平台轉移等，這些都是組織會考慮的項目。組織採用開放源碼軟體時，往往會擔心軟體終止開發、未來功能擴充需求、技術人員難尋或將來平台轉移等問題。 Drupal 擁有相當多的擴充模組、樣版及元件可直接套用。在技術上，採用了Smarty Engine，使得程式與內容分開管理，對自行開發擴充套件上，提供了很大的彈性。在人力資源上，Apache、PHP與 MySQL/PostgreSQL等，在台灣擁有廣大的社群與使用者，開發、維護上的任職或外包上較不成問題，而隨著組織發展需要將內容轉移至其他平台，也有其相對應的程式或模組可用。 

開始安裝Drupal 

在安裝Drupal前，請讀者確定環境已有GNU/Linux或BSD等作業系統，並且已經安裝好Apache、PHP及MySQL等必需之軟體。筆者的建置環境如下： 
(表2) 

目前Drupal繁體中文版僅提供4.6.0以及4.7.0兩個版本。Drupal 4.6.0版本有嚴重的安全漏洞，而4.7.0尚在測試階段。因此，筆者建議若要求穩定性為主，則選擇4.6.6穩定的英文版本；若要求中文化介面為優 先，則可選擇4.7.0繁體測試版，待正式版釋出後再行更新亦可。 

第一步：下載原始碼 

取得Drupal軟體原始檔<註六>後，解開至Apache網頁內容目錄下。GNU/Linux常見的目錄是/var/www/html，FreeBSD則是/usr/local/www/data。 

(指令) tar -zxvf drupal-4.6.6.tar.gz mv drupal-4.6.6/* drupal-4.6.6/.htaccess /usr/local/www/data 

第二步：建立Drupal的資料庫 

建立drupal資料庫於MySQL中。 (指令) mysqladmin -uroot -p create drupal 然後，為設定drupal資料庫的管理權限，先進行MySQL命令列模式。 (指令) mysql -uroot –p 建立drupal資料庫的管理權限，注意指令最後有分號”;”，並請讀者參照修改password的值。最後離開MySQL命令列模式。 (指令) mysql> GRANT ALL PRIVILEGES ON drupal.* TO root@localhost IDENTIFIED mysql> BY ‘password’; mysql> flush privileges; mysql> exit 最後只要匯入Drupal的相關資料表的設定。其中password為MySQL root之密碼，而目錄位址請視作業系統而更改。 (指令) mysql -uroot -ppassword druapl < /usr/local/www/data/database.mysql 

第三步：修改Drupal的設定值 

Drupal 的預設設定值於/usr/local/www/data/sites/default/settings.php，路徑位址請視作業系統而更變。主要變更 $db_url與 $base_url兩個變數。請將 $db_url改為第二步驟設定的密碼與資料庫名稱，將 $base_url改為網站的位址。 {mosimage} 

第四步：建立上傳資料夾 

上傳資料夾是用來置放網站的圖片、媒體或使用者統計數據等。對於Apache執行者而言，必需擁有可讀寫權限。資料夾的目錄位址請視作業系統而更改。 (指令) mkdir /usr/local/www/data/files 在FreeBSD中，預設的Apache執行者是www，而GNU/Linux常見的是nobody。請視Apache的執行者而更改www值。 (指令) chown www /usr/local/www/data/files 最後設定上傳資料夾為可讀寫權限。 (指令) chmod 755 /usr/local/www/data/files 

第五步：更新排程的設定 

很多Druapl的模組(如搜尋模組)必需定期執行排程，以更新網頁最新變化。執行的方式可以由直接瀏覽網站cron.php的方式進行。在此之前，請讀者先確定作業系統中是否有wget指令，在GNU/Linux中wget通常已安裝，但在FreeBSD需額外安裝。 編輯cron table。 (指令) crontab -e 並加入以下設定值。此設定值為每日零點進行更新。 (設定內容) 0 * * * * wget -O - -q http://www.mydomain.com/cron.php 

第六步：設定Druapl網站管理員 

Drupal預設沒有建立任何使用者。因此，第一個建立的使用者，即是網站管理員。首先，瀏覽剛建好的Drupal網站介面，請打開瀏覽器並輸入網站的位址，如http://www.mydomain.com/。 {mosimage} 點選create the first account，會出現如下畫面。 {mosimage} 輸入想要的網站管理員帳號及E-mail，成功登錄後會隨機給定一個密碼，此密碼可事後在管理介面另行修改。 {mosimage} 登入成功後的畫面如下。 {mosimage} 最後，嘗試發表一篇內容，點選create content，會出現如下圖的格式，填入適當的內容，並按下Submit按鈕發佈內容至網站上。 {mosimage} 在首頁上的顯示結果如下。 {mosimage} 基本上，Drupal的安裝已經完成，讀者可以參考Drupal線上手冊或是相關論壇以建立屬於自己的CMS風格。初始的功能非常簡潔，相較於其他華麗的CMS而言，透露出文質彬彬的氣息，然而其功能強大的模組與元件亦可使Drupal得以完成繁雜困難的內容管理。 

成功的應用實例 

Drupal 發展的歷史悠久，已經累積了許多成功的案例，目前國內外愈來愈多網站開始使用Drupal架設。國外諸如Contaire(http: //contaire.com/drupalsite)、CSC-SY(http://www.csc-sy.net/)、Destination Bride(http://www.destinationbride.com/)及CraftyTraveler (http://www.craftytraveler.com/)等。國內諸如政府機關的環境資訊中心(http://e- info.org.tw/)、社群的台灣部落格(http://www.twblog.net/)及滬尾部落群(http: //www.tamsui.org/)等。 若讀者欲了解Drupal原始碼GNU GPL的詳細內容或是與其他授權的差別，您可

以上網查閱中央研究院資訊科學研究所自由軟體鑄造場提供之「自由軟體授權條款之比較表 v2.0」<註七>。對於想進一步討論Drupal中文化的讀者，自由軟體鑄造場的專案開發平台亦有「Drupal繁體中文PO檔」專案 <註八>進駐，您可以在其中找到專案說明、也可以自行回報瑕疵等資訊，並匯集熟悉與有興趣的開發者能透過此平台互相討論交流。一起來一窺氣質 出眾的Drupal吧！(作者目前任職於中央研究院資訊科學研究所自由軟體鑄造場)
<註一>文章刊登於http://www.steptwo.com.au/papers/kmc_opensource/index.html <註二>文章刊登於KM Column - 2002年1月 <註三>《Open Source for the Enterprise》，書籍作者 James M. Kretchmar，Prentice Hall出版社。ISBN：0-13-046210-1 <註四>台灣中文支援站(http://tw-drupal.info/) <註五>What kind of server is recommended for Plone？ http://plone.org/documentation/faq/server-recommendations <註六>Drupal官方版本由此下載http://drupal.org/project/Drupal+project；Drupal 4.6.0繁體中文版由此下載http://drupal.org/project/zh-hant；Drupal 4.7.0繁體中文版po檔由此下載http://tw-drupal.info/node/54。 <註七>自由軟體授權之比較表v2.0 http://www.openfoundry.org/article.pl?sid=04/11/10/078231 <註八>「Drupal繁體中文PO檔」專案網址http://rt.openfoundry.org/Foundry/Project/?Queue= 

Filed under: 資訊多媒體 | No Comments »

ganttproject
http://www.ganttproject.biz/
專案的可用資源、里程碑、任務/子任務，以及任務的起始日期、持續時間、相依性、進度、備註等等功能。 相關資訊： GanttProject 是以 JAVA 撰寫。 支援平台：Windows,Linux, Mac OSX 授權方式：GPL … 

Filed under: 專案企劃 | No Comments »

[軟體工程師何時轉職 ?]

每一個寫程式的人心裡都明白, 這工作不可能做一輩子。不單單是體力及腦力問題, 最重要的是寫程式, 經濟價值實在有限。

我不會否認有很多的程式高手, 但重點不在於你有多優秀, 而是有多少老闆願意付出和你努力成正比的薪資來顧用你。不是沒有這種工作, 而是如同鳳毛麟角, 而且, 這種工作通常你也做不久, 因為壓力太大, 消耗青春太劇烈了。

退一步來說, 你也不值得付出這麼多, 在良好的SA及SD的規劃下, 工程師只要達成一般標準, 就可以解決掉九成以上的軟體開發需求, 除非是機緣巧合, 或是你很有興趣, 否則另外那一成的工作, 你是很難有機會碰上, 或者, 就算碰上, 也沒法子養活你一輩子。

軟體工程師總有一天要轉職的, 這是他們的宿命。

當要轉職時, 他們有幾個選擇, SA, SD, SE, 出去當老闆及換一行等諸多選擇。看起來雖多, 但其實晚景淒涼, 因為寫程式都是關起來寫, 長期自閉的結果, 當他們想轉職時, 很難擁有足夠的人脈來支撐他們換個前途光明的事業。一般人羨慕IT人的高薪, 卻不曉得只是寅支卯糧, 沒有妥善的規劃, 後勢看跌的。

前面的五個選項, 基本上最後兩項只是充場面, 只有少數人才能選那兩個, 大多數軟體工程師還是要在前三者中選一個來發展的。

SA看起來最風光, 未來也是潛力最好的, 但很遺憾的, 軟體工程師裡, 只有少數人適合這個職務。因為這個工作是很需要和別人打交道的, 而好的軟體工程師通常這一點非常不擅長。

因此, 如果你自認為擅於溝通, 三姑六婆都是你的紅顏知己, 邏輯能力不錯, 又對管理有興趣, 那麼SA是你很好的選擇, 程式功力並不是你要考慮的重點。

相對的, 你對使用者介面很有心得, 而且在美感上也獲得了同事的一致讚賞, 程式功力也有那麼一點自信, 討厭和不是搞IT的人打屁聊天, 那不要懷疑, SD是你最佳的歸宿。

最後, 你覺得IT的世界對你充滿了吸引力, 無論是作業系統, 開發工具或是軟體及IT設備都是如此的吸引你, 人與人的接觸對你來說並不是人生的首要需求, 層出不窮的IT科技讓你陶醉其中, 那麼, SE絕對是你的首選。

要如何轉職, 每一個軟體工程師是要誠實面對自己的, 而不是依前途來決定自己要選什麼職務, 如果你依這種方式選, 以我個人在職場生涯的經驗, 這樣的人很難散發出光芒, 也難以有他期望的成就。所以, 現在在寫程式, 正在想要轉職的工程師, 請謹慎而且誠實的面對自己, 做出恰當的選擇。

[結語]

以上是個人提供給對於SA, SD及SE或到困惑的朋友, 做為參考及工作分配的依據。這三者的產生, 其實也是源於目前IT技術的成長過於快速, 所以必需針對軟體工程進行適切的分工, 才能應付好日益複雜的IT環境。

希望本文的分享, 能給些朋友幫助, 有任何相關問題, 歡迎留言討論或來信分享。

引用http://www.wscken.idv.tw/pjblog/article.asp?id=11

Filed under: 資訊多媒體 | No Comments »

就某種角度來看, SE對PM而言, 算是萬金油, 只要做IT專案, 那就一定用得上, 差別只是要選那一個專業的SE而已。系統建置安裝要SE, 使用者環境要SE, 甚至到硬體選擇及佈建, 都要用到SE, 有什麼IT專案跟這個沒有關係呢 ?

當然, 雖然SE是到處都吃得開, 但相對的也是專案裡面最沈默及少有聲音的一群。他們的工作基本上就是建構出一個可以執行系統的環境, 系統要如何展現, SE可以給SA和SD一些建議, 但建議時機通常都是在系統運行出了些非系統可以掌握的問題後。

系統工程師基本條件上, 和SD最為接近, 但有一點不同, 就是不需要有很好的軟體開發經驗, 也就是不太需要會寫程式。但要對作業系統, 服務器系統, 網路運用環境有相當程度的瞭解。

SE通常是三者中最為博學一員, 好的SE雖然不一定要程式寫的呱呱叫, 但卻不能對編程一無所知, 對作業系統及開發工具也要有一定的熟悉度, 甚至部份網管有關的工作也要有所涉獵, 所以算得上是專案裡的萬金油。

在專案裡, SE所要執行的工作如下：

· 規劃及建置系統執行環境
· 安裝及設定使用者端環境
· SERVER安裝及設定
· 提供環境設置竟見給SA及PM
· 最佳化系統可靠度及效度
· 撰寫可靠度及效能測試計劃書
· 對電腦及相關週邊設備有一定熟悉度

而一名SE則有下列基本要求：

1. 至少熟悉一種作業系統, 尤其是讓系統的設定及微調等相關技術
2. 至少熟悉一種網路伺服器作業系統, 對如何設定及最佳化熟悉
3. 曾任軟體工程師職務一年以上或熟悉一種開發工具
4. 對網路環境有一定的認識, 尤其是一些通訊設置
5. 熟悉可靠度及效能的評估方法, 並瞭解與系統環境相關之設定

基本上, 如果擁有了像SD一樣的技術背景及個性, 但在美學上實在令人不敢恭維, 那麼SE算是極佳的選擇了。一般而言, SE的下一個生涯規劃, 會比較偏重於技術性兵種, 像是DBA或是網管, 對於IT產品比較有狂熱或愛好的人, SE是極佳的出路。

[在專案中的運用時機]

基本上SE是萬金油, 只要是IT的案子裡就一定要塞一個SE進去, 因為沒有IT專案不需要使用工程技術的, 差別只在使用何種工程技術而已。在套裝軟體的導入專案裡, SE負責處理軟體使用環境, 解決非系統性問題, 安置及調整資料庫和網路環境, 然後安裝啟動。所有系統運行所需要的條件, 都要由SE來解決和處理, 但這些工作全都不會出現在眾人的面前, 但卻又重要無比, 算得上是幕後的英雄。

會同時運用到SA,SD及SE的專案, 還是以客製化開發為主的。

在開發型專案裡, SA團隊要負責初期的需求調查及整體架構的規劃, 將所有的系統開發工作內容轉化成井井有條的文件, 並且適度的分割及派送, 並確保未來這些被分割的開發結果能夠在未來可以正確運作。

SD則在SA的文件中去尋求系統呈現的一致性, 易用性及保證開發工具可以正確無誤的展現SA的要求結果。所以SD要負責操作界面的外觀設計, 訂定一致的展現規範, 設計系統操作畫面及操作手順, 同時配合SA完成系統開發文件。基本上, 開發文件中, 是包含系統使用手冊初稿的。

SD在設計時, 必需與SA充分配合, 以確保設計的系統符合需求及運作要求。

除了上述的工作內容外, 這三者都要撰寫測試計劃, SA著重在於資料的流動符合原先規劃的順序及結果測試, SD則著重在操作畫面中的防呆測試及操作介面的正確性, 而SE則在系統可靠度上進行規劃。

引用http://www.wscken.idv.tw/pjblog/article.asp?id=11

Filed under: 資訊多媒體 | No Comments »

一般來說, SD在生涯規劃裡, 並不是SA或是PM。當然, 一定要硬來一次也沒有什麼不可以, 但要走這條路, 就要趁早轉職, 因為SD畢竟是較為幕後的工作, 在與客戶的溝通協調上, 並不會有太高的要求, 也較不需要公司管理層面的全局觀。

表面上看起來, SD沒有SA那麼多的工作要求, 但實際上SD是最需要天賦的工作, 不管是畫面的構成, 操作的手順及調整, 甚至於元件的定義及物件的規範, 全都需要一些天賦。很多軟體, 功能很強, 但怎麼看怎麼不順眼, 或者怎麼用就怎麼憋扭, 功能帶來的效益, 全都被這些毛病給遮蓋掉了, 這就是SD的問題。

另外, SD也扮演了系統最佳化的推手。SA所規劃出來的要求及佈置, 都只是邏輯上的構思, 在不同的工具上, 可能有更好的方法可以表現, 也可能會難以展示, 這都需要藉由SD對使用環境及開發工具的瞭解, 來進行調整和規劃。

舉例來說, 同樣是一套財務軟體, 在WINDOWS XP, MAC, X WINDOWS下, 就會有很不一樣的展現模式和技巧。如果再搭配上不同的開發工具, 如C++, JAVA, .NET, PHP, …那差異更多。對SA而言, 這些東西他都不用去考慮, 但SD就不同了, 這些不同的地方, 並不僅僅只是如此而已, 有時還會包括了開發成本及時間問題, SD的重要度, 由此可知。

在一個客製化專案裡, SD的工作內容如下：

· 設計畫面元素規範
· 設計頁面結構及規則
· 設計系統操作畫面, 並編定欄位規範及防呆處理
· 設計權限管理與系統操作機制
· 撰寫使用手冊
· 調整DB之各項定義, 使其符合畫面欄位規範及操作搭配
· 配合SA撰寫系統開發文件, 供程式師CODING之用
· 撰寫UI(使用者介面)測試計劃書

而做為一名稱職的SD, 以下的條件, 是必要的：

1. 至少對一個作業系統極為熟悉, 對於這個作業系統的各個元件特性及API, 有充分的瞭解
2. 熟悉2種以上的開發工具, 而專案所需的工具, 必需是其擅長的之一, 其熟悉度包含了標準安裝裡的各個函數庫, 系統常數, 物件定義, 語法, 主要的輔助工具開發廠商, 及重要的工具使用方法
3. 具一定的美學感
4. 至少能使用一種繪圖工具軟體
5. 曾經擔任職業軟體工程師三年以上

可以這樣說, SA給了系統靈魂和神經系統, SD則是給了系統軀體和外觀, 兩者的結合, 才能產生出正確, 美觀又好用的系統。如果你覺得自己是個不太愛和太多人打交道的IT人, 又對使用者介面有那麼點執著及天賦, 那麼, SD絕對是適合你的好選擇。

引用http://www.wscken.idv.tw/pjblog/article.asp?id=11

Filed under: 資訊多媒體 | No Comments »

做軟體開發專案規劃時, 常會碰到助理問我一個問題, SA,SD和SE的差別在那裡 ?

這個問題我以前也有過, 還頗為困擾, 系統分析和系統設計及系統工程到底有什麼差別 ? SA和SD的工作又有何不同 ? 這兩者的養成教育又有何差異 ?在過去, SA,SD及SE的確很難區分, 甚至這些角色常常會透過軟體工程師來混合發展。

隨著IT領域的發展, SA,SD及SE漸漸的成為了大型專案必需要的專業分工, 這三者間是有相當的差異的, 不管是養成過程, 甚或是未來的發展, 都大相徑庭, 而要成為一名稱職的PM, 是要能區分出這三者的差異, 才能妥善的安排工作的。

[SA,系統分析師]

SA是 System Analysis 的縮寫, 一般稱為系統分析, 主要的工作就是透過一系列的分析工作, 把客戶想要的結果產生方式, 以各種文件表達出來, 讓開發團隊可以根據這些文件實作出這個結果。

這樣的解釋比較文縐縐一點, 用個通俗一點的方式比喻, 就像是要做出一道宮保雞丁時, 就會有食譜一樣, 裡面會介紹需要的材料及做菜的順序, 然後裡面也會強調要以怎樣手法才能產生出某種效果, 以促進色香味。

這樣的過程裡, SA是較為偏重於在工作流程和處理邏輯的, 透過SA, 開發團隊才可以理出整個系統的架構, 一種做事的脈絡, 以及系統和工作間的關連性, 最重要的, 是這些結果都會被SA呈現在文件中, 而非放在少數人的腦袋裡。

SA不僅止是要針對電腦裡的東西去運作及規劃, 還包括了現實世界裡的實體流程及組織。在很多的情況下, 配合新系統的組織及流程, 是要由SA來執行的。總結起來, 在一個開發案裡, SA執行以下的工作：

· 藉由系統需求書, 使用者的現有標準作業流程來建立出符合期望的新作業流程及搭配流程的系統功能及模組規劃
· 依據功能及模組規劃案, 定出初步的資料庫內容及系統與使用者間的權限搭配規範
· 定出各個軟體零件的規範, 如物件, 函數庫, …等等
· 設計新的標準作業流程, 並把系統功能或模組綁入這些流程中
· S.A依據客戶的環境及需求, 尋找合適的SD來搭配

而SA也有以下的特色：
· 對於系統在怎樣的環境及用什麼開發工具, 並不十分在意, 良好的S.A產生出來的文件, 使用不同的開發工具都應該可以完成, 產生相同的結果, 但那一種最合適, 由SD決定
· SA偏重於流程及執行邏輯的表達
· SA著重於軟體邏輯, 對開發工具的學習並不是十分重要, 所以會一種語言即可, 主要是以該語言工具來實踐邏輯觀。
· SA一定要有全局觀, 也就是不能拘泥於一個角度或是一個局部去思考問題, 這一點是尋找優秀SA時最困難的。因為在規劃模組及功能時, 一定要同時考量到所有直接相關及間接相關的程序及邏輯問題, 因此要有全局觀。

相較於SD, SA更側重在邏輯及工作順序搭配的表達, SA並不需要去關切使用什麼作業系統或是什麼開發工具, 如前特色所述, 好的SA文件, 可以用任何一種開發工具來實現。當然, SA不受限於IT技術, 但卻會有專業領域的限制。

很少有SA同時專精於數個領域的, 熟悉汽車業運作規範的SA, 在金融業的開發案裡, 就很難討好, 反之亦然。但SD沒有這種限制, 基本上SD可以和任何行業的專案開發團隊配合運作。

會如此的原因是SA是偏重於流程及管理分析及重新再造工作的。而作業流程, 除了少數領域裡共通性高, 在核心流程上, 是需要長期鑽研的。前面提及的汽車及金融業就是一例。

所以, 一個SA必需具備以下的能力,資歷及專業訓練：

1. 至少熟悉一種程式開發語言
2. 熟悉軟體工程, 對於開發工具的元素及特色熟悉
3. 對管理制度或作業流程設計熟悉
4. 熟悉UML或類似的系統描述工具
5. 邏輯能力良好
6. 良好的溝通能力, 主要作為瞭解需求之用
7. 相關的業界熟悉度

在三者之中, SA是最接近PM的, 所以SA在做生涯規劃時, 不妨以PM做為下一個發展的專業目標。

引用http://www.wscken.idv.tw/pjblog/article.asp?id=11

Filed under: 資訊多媒體 | No Comments »

我常在許多軟體公司與專案經理們討論軟體人員的職掌時，發現到，耶？ 怎麼我所認知的 SA/SD 與他們實際的工作內容大大不同。嗯，所以我想就針對 SA/SD 來給個正名與定位吧。

SA, 系統分析師(System Analyst)，是對設計中(Under Design)的系統來作分析，既然是分析，那麼，應該是需要 “剖開” 系統內容，來對其系統內部的結構組成元素，以分析其脈絡。所以我覺得系統分析師，也可以稱之為 “結構分析師(Structure Analyst)。

系統分析師的工作，是著重在系統的內部，應該是要能找出與描述系統組成結構的靜態(Static)元素，並利用元素，動態組合以滿足系統外部的功能需求。也就是說，靜態面的結構元素，與功能面的行為(Behavior)描述，均是屬於系統分析師的範疇。幾個主要的產出，包括類別(Class)圖、循序(Sequence)圖、資料庫的 E-R(Entity-Relationship)圖，是 SA 所該負責的，而且，上述的產出是偏向於建立領域概念的模型(Domain Conceptual Model)，並非為與平台相依的軟體規格模型(Software Specification Model)，與平台相依的軟體模型，是屬於 SD(System Designer) 的範疇。

而一般軟體公司對 SA 的定位，是在於對客戶端操作者(Operator)與領域專家(Domain Expert)的需求訪談。但是，需求面是屬於系統外部的功能面觀點，我一直不認為這是屬於 SA 的工作，正確地來說，這應該是 “需求分析師(RA, Requirement Analyst)” 的範疇。

有趣的是，我發現到，一般對 SA 的要求，還需要包括對使用者介面(User Interface)的設計，為何會需要 UI 的設計？ 我想應該是與 SA 訪談的對象，都比較偏於層級比較低的終端操作者，而這些操作者，會很重視 UI 的操作，卻很少能正確地說明系統真正要的功能，往往都是以局部操作者的角度來看待系統。

我發現到，一般軟體公司對 SA 的角色定位太過模糊，以致於 SA 根本就搞不清楚他們要做的是到底是屬於系統外面的工作，還是屬於系統內部的工作。如果能正確地將系統外部的需求分析與系統內部的結構分析作區分，需求分析由 RA 負責；結構分析由 SA 負責。如此，才能界定與釐清系統內與外的工作。

至於 SD，系統設計師(System Designer)，焦點仍就於系統內部的結構，與 SA 所不同的是，SA 所建構的是屬於偏向於領域的概念模型；而 SD 則是根據領域模型，再配合實體的平台，如 .NET or J2EE的框架(Framework)，考量其效能、穩定、分散與安全性等，所建構而得的軟體規格模型。SD 的主要產出，仍包括了類別圖、循序圖以及 Database Schema，而這些產出，都會與實體的平台相依。例如，具化的軟體模型是以 J2EE 來實做，而就永續層(Persistent Layer)設計考量，SD 是以 Hibernate Framework 來實做，以橋接領域物件與資料庫的永續儲存。

不過，軟體公司對 SD 的定位，反而僅在於對資料庫 Schema 的設計。其實呢，對於 E-R 與 DB Schema，也並沒有相對切分邏輯(Logical)與實體(Physical)的層次(Layer)。邏輯與實體之分，簡單的說，實體的 DB Schema 會考量到與現實所使用的資料庫系統的特性相關，諸如欄位資料型別的定義、Index and Constraint 的設計等…。

一個基本的結論，系統外部的功能性需求分析，係由 RA 所負責。而系統內部的分析與設計，是交由 SA 與 SD 來負責的，而 SA 與 SD 的界限，可以以是否有與實體的平台相依來界定。我們也可以以兩句話來說明分析與設計的關係：

“Do the right thing (分析)”and “Do the thing right (設計)”。

posted by kenming_wang(矇矇)

Filed under: 資訊多媒體 | No Comments »