Re: [討論] 外包的軟體合約通常有具體的需求規範嗎?

: 標題: Re: [討論] 外包的軟體合約通常有具體的需求規範嗎? : 其實寫程式本來就很繁雜 : 無法做到模組化跟標準化 : 需求跟規格變來變去也很正常 : 過度追求流程問題只是一種精神潔癖 : : 設計的時候當然是可以有一套開發的方法 : 但是實做的時候...免不了就是要一直修改啊 : 尤其台灣的軟體工程師...來來去去的... : 我只能說code亂寫的人實在太多... : 往往程式到後來就是...亂到連改都快改不動的程度... : : 我個人覺得寫軟體就是一種服務業 : 產品出去了就要要不斷的maintain : 頂多就只能像DHL一樣做到工作的分配跟管理有一套流程 : 但是貨還是人親自送到客戶手中的... : : 忘記模組化跟流程這件事吧 : 當一個PROGRAMMER就跟一個7-11的店員一樣 : 你得把他當服務業來經營... : 而不是工廠一開就不斷量產的電子業... : ========================================================= 如眾多網友所提, 軟體需求的變動不能免. 程式的需求與規格會變動, 開發的方法就要能考慮到變動的彈 性. 賣出去了, 因 bug 要修改或替換模組, 因新的需要必須再更 動等等都成為必要的 maintain . 不管是出貨前還是出貨後, 都會 碰上修改的要求, 為了便於修改, 就必須強調設計的模組化, 清析 的流程, 甚至為了讓別人能接手 出貨後的maintain , 那還得講求 程式的可讀性. 不盡力做模組化, 代價是後面的維護難以為繼. 如果是做機關軟體包案的, 可能會認為與其修修補補不如推倒 重新打造, 包新案比同意後續維護賺的錢更多, 所以只求能結案領 款, 但相反的, 買的那一方可能就得盡力挑毛病要求盡力改好, 以 免用不了多久, 因賣方不肯也無法修改或維護, 就得廢掉再新買, 那買賣雙方就很難迅速結案付款了. 最後, 當然在保固期間就會變 成 7-11 的店員一樣地被隨叫隨到, 可能還會是拿不回完整最後尾 款的下場. 今天的情況是要問: 做過的包案為何不能大部份再利用, 當成 另一個類似包案的既有基礎, 這樣做跟修改是差不多的, 但因為在 設計時就要求模組化, 所以容易拆併, 又因注重文件與可讀性, 所 以可以讓其他少數人就能在既有基礎上做出類似的包案, 也因可修 改與可維護性提高了, 就能針對需求做較容易的變動與維護就不再 怕被扣尾款了. 這個模組化與可維護性才是軟體工程想提升的能力. ======================= 軟體合約有沒有具體的規範需求 ? 1.都不給買方修改或維護的彈性, 就怕得罪買方, 搶不到標. 2.若說甚麼都可以改, 那也牛皮太大, 變得像空口白話, 不負責 任, 如果買方需索無度, 那豈不更嚴重, 鬧成血本無歸 ? 3.配合買方做出買方滿意的軟體系統, 那麼有些修改是免不了的, 即使像隨機賣, 錄在 CD 的套裝軟體, 也都是有足夠的彈性讓用 戶選用不同的硬體也能自動找對模組匹配. 這是提供買方用戶自 行維護的服務法. 軟體合約顯然會引導供應源與客戶的行為模式, 影響軟體品質的提 升方向與成長. 對這個標題的疑問, 應該可以大致判定, 外包的軟體合約目前在台 灣還是欠缺具體的需求規範, 所以政府機關的軟體的委外雖然大案 子有資策會協助的需求規劃與規格, 也有大包小包分包下去, 但最 底層寫程式去實現的人, 似乎仍然反應是規格不清, 大量修改的機 率還是很高, PG 的怨氣都推給 PM 了. 在大學的電算中心裡, 有關 e 化的項目還是受制於當年軟協 建議政府機關軟體一律委外的限制, 不給編制人員名額用於開發軟 體. 但事實上在同一個機關裡, 替行政單位開發軟體就跟人力派遣 快沒兩樣, 去一個陷一個. 都不派, 行政單位還是想方設法用一些 號稱資訊人員的臨時人力在使用, 但最後這些人也都流失於行政工 作, 為了怕流入行政單位, 這些人都是臨時約聘僱, 都等著國家考 試被正式任用. 唯一的好處是這些變相進用的人不會排斥電腦, 但 也造成好像資訊人員永遠不夠的缺乏現象. 另一個缺點是這些臨時 資訊人員(?)拉低了待遇, 也造成需求龐大的假象. e化的問題, 基本上是透過電腦想達成業務自動化, 但大量進用 臨時約聘僱, 反而跟節約人力的自動化相違背, 所以人員就變成臨 時性質, 這種人力擴充在公務預算單位經常發生, 就因為新工作任 務不會加之於老公務員, 新工作要新人, 不想加新人就會企圖想要 引進電腦 e 化代替白領人力, 但在無法草擬規範需求下, 就很難委 外, 只能用類似派遣變相進用能做(或操作)資訊系統的人力, 冀望 電腦化後再利用約聘合法解除人力, 但這種想法的後果就導致不論 是委外或自雇約聘人員開發的系統, 在 "人性上" 無法完成. 因為 驗收系統的約聘人員很難做此 "自殺性" 的同意. 比之於大型建築 物的建置與使用過程, 很難想像為何資訊系統的建置行不通. 這裡 忽略的是大型建物都是成熟的概念, 外觀再怎麼變化, 其堪用期很 長, 投資金額巨大但值得, 建造時有大量的自動機械幫忙而且工人 是高薪的. 可是, 新增業務性的資訊系統就像新產品 RD 開發案, 壽命周期是很短的, 經常是開發出來一套, 無法推廣, 沒人續用就 掛了. 私立大學沒有國家性超然的人事會計與財產人員, 學校不受這 些公務員管制, 所以能整併所有行政人員與資訊人員為一體, 沒有 需要大量約聘或工讀生代公務員處理的問題, 在規劃新系統時能做 合理性的整體考量, 提供的自動化工具與人力是適當搭配的, 不太 可能是禁令如牛毛, 到處為求生存鑽漏洞, 上下交征利. 這種規劃與建置新應用資訊系統的壓力, 在大學就全都集中到 電算中心. 有規模的私校電算/資訊中心都是龐大的, 但公立學校 則是仍受制於當年軟協的委外建議, 在人力是不足的. 公立大學的 電算中心沒有軟體開發與軟體工程能力, 當然是造成資訊科系師生 在軟體工程認知的不足. 校內的電算中心替行政單位開發軟體系統, 其淒慘的情況可能 比之於 SI 業者做政府包案還不如, 所有的反覆修改, 無法結案, 派一個賠一個黏一個, 全都發生了. 而且人力有限, 直到賠光還是 罵聲怨聲不斷, 比起業者形容刁鑽的買方, 惡質的環境還更慘. 就因學校的行政單位要求電算中心做的軟體開發案, 幾乎是沒 有需求規範的. -- ◆ From: 140.115.1.146
※ 批踢踢實業坊(ptt.cc)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1194145907.A.58B.html

推 ritchieHsu:如果把企業e化講的這麼太簡單 會被我研究所老師 釘到暴 11/04 13:29

→ ritchieHsu:我當初論文題目就有個e化的字眼 畢業口試超血腥的 11/04 13:30

推 ritchieHsu:他是頂頂有名的e化大師 abcde計劃的委員 11/04 13:35

→ ritchieHsu:說我隨便到外面幫企業弄個鳥系統 就算是e化 頭剁給我 11/04 13:36

→ ritchieHsu:也沒辦法 學校就是喜歡搞一堆很厲害的理論之類的 11/04 13:37

→ ggg12345:私人企業,政府機關,私立大學,國立大學四者差距很大,e化沒 11/04 14:07

→ ggg12345:說簡單耶,涉及一群人的事那會簡單?反而是企業明白簡單多. 11/04 14:09

推 PRAM:我覺得教授可以轉職當立委了 11/04 17:27

推 ggg12345:企業好歹有個合約只怕拖延結案,學校根本就沒完沒了,永遠 11/04 18:05

推 ggg12345:被嫌被罵(會少年終獎金),兩者的難度各有不同,不如想像易 11/04 18:09

推 chihyi1980:最後那一段也要有足夠的業界經驗才有資格講的.. 11/04 20:11