2012年9月5日星期三

從軟件工程看國教科的弊處


倘若你曾經唸過資訊科技或者從事過一些資訊科技的項目合作的話,軟件工程的中開發流程你會或多或少都會知道。

當中包括 需求分析 | 軟體架構 | 軟體設計 | 軟體編程 | 軟體測試 | 軟體部署

這是常見的開發模式,當然也有其他模式,但都是萬變不離其宗。

事實上這次德育及國民教育科的開展,其實都是需要類似這個流程去進行,可惜是做得不足,因此得出的結果事與願違。

一間公司入面很多時開發軟件的原因都是因為客戶用家需求才會開發,但亦會有可能是來自資訊科技部門自行開發,因為有些是更創新而讓服務優化,這情形是有出現。這即是現在是國教科未必是家長或者學校需求,但是教育局想優化學生,所以才推行,這的確是理解,因為教育能夠進步的話,這便是提升學生水平,有如優化系統便可以提升,工作效率一樣。

在軟件開發過程中,需求分析是最深入和最困難,因為很多時人們都以為是最簡易,其實是最易出錯,因為拿requirement analysis是常出現自以為是的情況,拿不到客戶的真實需要。這個情形便是有如現在的國教科的諮詢問題,看其諮詢期短,學界根本難以提供完整的資訊予教局,如何分析和制定便難以掌握。此外學界提供的資訊又是否接納更是同樣的關鍵,而且諮詢完畢又沒有回應,這當然會是錯漏百出。當然亦有可能是根本教局早有自己的一套的預算,諮詢的也只是虛招非實幹。有如開發者自定模組並根本不理會客戶,只會理會自己最大的得著如成功回報等,包括向上司邀功,向西環邀功。

往制定課程(軟體架構)便來得難以捉摸,其綱領由於拿回來的諮詢根本有很大出入時便有如開始走到錯位但仍然要硬著頭皮做下去,並以閉門造車的模式去設計以及編寫有關課程。而最大的需求並不是來自家長和學生及學界想要的,而是主子老闆想要的,根本是兩碼子事,怎會混在一起呢。

到了開展期(軟體測試)便來了今天的大禍,學生、家長、學校(用家)根本對這課程所理解的預期完全是兩回事時,那便大禍臨頭。

但是真實需要準備實行(軟體部署)便難以成行,因為學生、家長甚至學校的反對,要推只會弄得車毀人亡,最後雙輸局面。

如何收拾殘局,常見便是要用家硬啃,因為沒有得轉回,最後用家便面如死灰去使用,只是事倍功半,最終效果是得不償失。大老闆迫你用,不可以抗旨,否則後果自負。

當然亦有較佳的出路,就是從新上路,再做過一次完整性的開發流程,認真地向有關方面的諮詢而非交行課。這樣便會形成雙贏局面,因為用家深知關發者(教局)是真正做事而變得合作,反而可以有更大的成績。

最弊是修修改改,就是現在胡紅玉所做的事,加加減減是最痛苦,兩頭不到岸,學生一面如白老鼠般試驗的偏差教育,另一方面教局亦生怕又出現用家的反彈而畏首畏尾,形成雙輸局面。

現在國教科這事便如這樣,學生苦,教局困局,但現在情勢是要硬推,這隨時會使用家大力反抗,形成對抗,結果換了其中一邊的話,那就不堪設想。

當時的諮詢,你聽了沒有,不是今天又說大家討論這些廢話,人家成年前已經講過,只是你從沒有聽進去。


3 則留言:

  1. 唔同意
    更加多的情況是用家自己也不能給出一個準確的requirement,而需要在軟體測試後在不斷微調以到達要求

    回覆刪除
    回覆
    1. 如果連最基本的準則都沒有定下,那些微調根本就是錯誤。
      即係叫你寫個accounting system,原來最後出左個inventory system,但開發者認為兩項都有類似,包括存在有stock take的功能,所以要水用家繼續使用。但事實上根未是兩個系統,咁點樣可以整合呢?開發者 因為比人投訴,然後一路微調,但係個inventory system存有先天性的缺陷,難以可以移植到新系統上,起初是可以勉強符合到要求,但最後是爆鑊。

      呢個情況,相信見唔少。

      刪除
  2. 武光兄
    同意有你上述所描述這個情況。
    咁這個微調有幾微呢?
    在日常的情況,這些微調是需要在大家有compremise下才會有一個正常的好微調,但很多情況是微調來來去去又原地踏步。個用家然後又嘈,個開發者又鬧用家唔明點用。兩邊都互推的情況,唔係冇見過。

    老實講沒有真正的compremise,得出個結果咪就係硬食。

    回覆刪除

LinkWithin

Related Posts with Thumbnails