政府的權力皆來自於人民的期待。其功能像艘承載人民福祉的大船,航行著,執政者則成了當今時下的臨時船舵,替我們划槳。可是真正帶領國家航向偉大航道,取得大秘寶的則是---我們這些身為航海士的人民們!

每個人都知道,台灣是一個我們需要維護的家,但,對於“如何維護”這件事情,大家的需求可能就不太一致了。對一個政府來說,要聽見這麼多人的聲音是件不容易的事情,在這樣的狀況下,地方機構的服務落實就變得十分的重要。而問卷調查在現代社會是種十分重要的方法,不僅簡單好上手,同時在正確度上也不亞於其他方式。

其中,問卷設計最為關鍵。一份問卷設計的好壞,將決定了獲得的訊息是否可靠。所以這次信諾科技所扮演的角色為-協助《民政局》,當紙本問卷在電子系統化的過程中,是如何維持回收的的正確性,同時卻也更進一步的讓這些科員,在電子化後能無痛的轉移原有的辦公習慣。

 

民政局105年度滿意度調查系統

臺北市政府民政局,簡稱民政局,1945年成立,是臺北市政府所屬的一級機關。自設立之初原本共有6課,下轄有地政處和兵役處等機關,但隨著時間的演變和需求的改變,許多行政機關如上述都升格成為一級機關。統計自2009年,民政局共有5科5室,分別是:區政監督科、自治行政科、宗教禮俗科、戶籍行政科和人口政策科;5室則是內部的人事室(1945年)、主任室(1945年)、秘書室(1993年)、政風室(1993年)及資訊室(1998年)。資料來源:維基百科

 

在過去一段很長的時間裡,大家似乎常常有著一種“需求分析”是整個軟體工程中,最為簡單的一個步驟。但,你知道嗎?當我們在建置一個新的系統時,確立目的、範圍、定義及功能等等,一切細項後所做的分析則是相當關鍵且為不可或缺的!

那為什麼這麼重要阿?不是就只是個分析過程而已嗎?

那讓我舉例來說好了:倘若在對客戶進行需求訪談時,如我們未能正確地認識顧客需求的話,那麼最後的系統,會在一堆誤解中產出。它會在一種沒有滿足客戶需求的狀態下呈現,這樣的狀況下,避免不了的一定就是“修改”這個浩大的工程。大幅的更動,可能會使系統的原始架構受到挑戰,而接踵而來的可能是---砍掉重練!聽到「重練」著這關鍵字,聽了我們慌,客戶更慌...。因為在交付的期限上將無法“順利”的完成,再來,因時程縮短,將會大大提高品質出包的風險!無形中不僅浪費時間也傷了一些和氣,實在得不償失啊~

所以現在請大家再一次和我一起踏上的專案航行吧~看著信諾是如何將客戶的需求,從零到一的去實體化每一項產品!

系統需求與開發

在這次的專案中,為了有效落實、優化民政局所屬機關、北市各區戶所的服務風氣,並確實掌握民眾對相關服務的觀感,及局內辦公人員對工作環境、業務管理...等等事務的改善意見,我們將這次建置系統的核心需求著重在:提升民眾洽公滿意度與為民服務品質。而要造就出一個系統與架設一個網站的起始點不同,網站著重於視覺規劃;但系統則是注重統計及演算,所以在系統開發的過程中,每一個步驟的分析都會影響著後續的設計,因此耗時且費工!

 

STEP 1. 系統分析及雛型系統製作

首先,得研讀一連串相關的作業及現有系統功能來做為開發的前導,了解後,便會開始蒐集相關資料來進行作業分析,分析完,就能更具體的得知系統改良抑或重建的可行性,這些都是在為需求訪談做準備而已!而訪談後的彙整,會依著承辦單位相關的標準及訪談結果,彙整出整個系統之架構、資料流程圖,以及螢幕畫面報表格式,最後再以“系統分析規格書”的方式產生文件,並完成雛型展示。

 

系統分析及雛型系統製作流程圖

系統分析及雛型系統製作流程圖示

 

STEP 2. 系統設計

再來,拿著前一步驟的系統分析結果來進行系統設計。在這裡,我們會先定出實體資料庫的架構及人機介面,並產出“系統設計規格書”、“測試計畫書”給客戶確認。確認完畢後,再針對客戶確認後之雛型系統功能特性,來規劃出整體系統架構,並完成資料庫設計及資料結構設計。

 

系統設計流程圖

系統設計流程圖示

 

STEP 3. 程式設計

系統樣式得到確定後,就表示系統已一定程度的框架了,此時我們就依據上一步驟所產出的“系統設計報告書”,來開列我們的程式規格,接著就可以上工寫程式了~而同時間也把現有的各系統資料,轉到專案所使用的個別資料庫,產生一份”單元測試報告書”來進行單元測試。

 

程式設計流程圖

程式設計流程圖示

 

STEP 4. 系統測試與建置

依據上步驟所得的“測試計畫書”的內容,回測程式、系統功能及其反應時間,來做最後一步的驗證。確認所做的每個分析及設計,是否都有達成需求,並生成最終的文件:”系統測試報告書”。最後最後,進行完系統整體測試,便能開始系統的建置作業。

 

系統測試與建置流程圖

系統測試與建置流程圖示

 

瞭解更多...