gipi的學習筆記-經營管理、數據思考、終身學習

你辛苦加班，努力的把產品趕了出來，但當你面對這兩個問題時，你心裡踏實嗎？若你的答案是否定的，那這個產品大概也不會是客戶心中的首選，雖然說軟體工程師不是什麼藝術的工匠，但若做一個產品，你沒有辦法全神貫注的去將這個產品做到最好，做到自己能引以為傲，做到自己都不禁要讚嘆，那這個產品只是一個產出物，而不是你所創造出來的傑作。

[軟體開發]到底是Scrum好，還是CMMI讚？關於開發流程選擇的二三事
其實現在很多公司談開發方法都是混搭，也就是部分的Scrum+部分的CMMI，純的Scrum或者純CMMI不見得合適於每個團隊，所以流程的合適性是必須要被嚴謹看待的，唯有當開發流程導入的好處大於壞處時，這個流程才算是合適的，導入開發流程可以局部局部來，不必要一次到位，但唯一準則就是「合適」，唯一的要求就是「優化」。

[系統開發]我們該專注的是程式Bug數還是規格Bug數？
所以，若要分析系統的穩定性問題，應該從錯誤發生的地方，一路從程式追溯回規格與架構，在專案開發中PG幾乎是最後一個接手人，決定權也不高，但卻必須要承擔大多數系統的品質問題，這是不公義的，其實規格的Bug所帶來的影響並不比程式的Bug來的小，應該被同等重視，別再讓PG成為系統問題的代罪羔羊。

[產品開發]談一體化解決方案
做套裝軟體並不簡單，模組與模組間的切分更是困難，有些模組彼此的相關性極高(或稱功能耦合)，通常買了A模組就會連B模組一起買了，但有些模組彼此間的相關性較低，我買了A模組不見得要買B模組，為了滿足不同的用戶、產業別、國家別的需求，這些模組的功能應該是要可被置換的，但你卻不能因為我不買某個模組而讓我的系統無法使用，如下圖，我想買你們ERP中的訂單、生管及維修模組，但財務跟客服的系統我要沿用我們公司既有的系統，你能做得到嗎？這個問題我相信大多數的廠商都被問過，有些夠靈活的系統在模組設計時就是以子系統的觀念去設計模組與模組間的接口(鬆耦合)，所以可以做到，但有更多的廠商是透過客製化的方式來解決這個問題。

[系統開發]需求雙向追溯矩陣(Traceability Matrix)
在系統開發中，有個詞彙我們常聽到，那就是需求雙向追溯矩陣，這觀念其實非常的重要，但似乎被提到的多，但真的被應用的少，以下我簡單的提一下這個追溯矩陣的概念。

不管是依循瀑布式或者Agile、RUP等等開發生命週期方法論，系統開發一定都免不了要經過需求收集、分析、設計、Coding、測試等等程序，才能比較準確地完成客戶的需求，但如果我們只單單憑我們收集到的客戶需求就開始下去做SA、SD、Coding等工作，直到最後才讓客戶做驗收，我們有多少的把握我們開發出來的結果是符合客戶期望的？這種交付模式在開發上的風險實在太大了。

[軟體開發]系統整合最大的問題不在技術
整合，一直是資訊系統一項很大的重點，現在不管哪家軟體廠商提出的軟體架構，一定不會少掉整合這個issue，SharePoint跟Outlook、Dynamic CRM整合；SAP的ERP要跟BI、Salesforce的CRM整合；目的都在讓提高綜效，簡化流程、提高資訊的效益，然而，一直以來整合都沒有萬靈丹，一直沒有人敢說他擁有一套絕對可以確保整合成功的架構或者產品，這是為什麼？

『系統開發有標準開發流程好不好？重不重要？』

你問這個問題，100個人有99個人會跟你說重要，不過通常他們後面會接著：『可是....』，接著就開始跟你說哪個部分的流程可以跳過，哪個部分可以少做一點，最重要的還是準時把東西交出來，有問題再說吧，我想很多人對 CMMI都有基本認識，CMMI最重要的就是訂定一個Process Model，依循這個Process Model，產出符合預期的內容，接著做量化管理，可預測產出，進行流程最佳化，這大概就是CMMI一層層上來的概要標的了。

[產品開發]能相信的只有測試過的程式
之前去聽Ruddy老師的課程時，老師問了一個問題：『我們相信local端的程式還是雲端的程式？』
這個問題的答案帶點詼諧：『我們只能相信測試過的程式。』

聽到這句話讓我會心一笑，是的，我們能相信的只有有測試過的程式，而且是在『Testing環境』中測試過的這一個 assembly、component，我強調Testing環境的那個assembly、component，為什麼？下面我來說明一下前因後果。

[產品開發]談定位，什麼該做？什麼不做？

[產品開發]產品開發不趕流行

[系統開發]商用軟件的痛-客製化升級

[系統開發生命週期]Use Case Diagram補完

[系統開發生命週期]Use Case Diagram概述

[產品開發]軟體產品開發的五大支柱

[系統開發]Webform or Winform的選擇

[系統分析]談談需求分析(RA)