前言

　　近年來(lái)，隨著(zhù)人民生活水平的不斷提高和住宅多樣化的不斷發(fā)展，物業(yè)管理已成為一門(mén)科學(xué)。其內涵已經(jīng)超出了傳統房產(chǎn)管理的范疇，發(fā)展成為集多種手段對物業(yè)進(jìn)行綜合管理，并對相關(guān)物業(yè)資料進(jìn)行保管、歸類(lèi)、匯總、整理分析等。在此前提下，我國各地涌現出了一些運用現代計算機、控制與通信技術(shù)的智能化住宅小區。但是許多智能化住宅小區都存在搭好了硬件平臺，卻沒(méi)有優(yōu)秀的軟件在上面運行的情況，或者說(shuō)缺少現代化的管理手段�？茖W(xué)高效管理是現代化的真正內涵，簡(jiǎn)單的硬件拼湊對于現代化小區的實(shí)際應用是缺少實(shí)際意義的。為此，只有利用計算機進(jìn)行物業(yè)管理，利用優(yōu)秀的物業(yè)管理軟件實(shí)現對物業(yè)信息的標準化和規范化，為物業(yè)管理工作提供準確及時(shí)的信息，有助于物業(yè)管理部門(mén)進(jìn)行管理并做出相關(guān)決策，同時(shí)，也使物業(yè)管理公司及時(shí)準確地了解運營(yíng)狀況，做出經(jīng)營(yíng)決策，這樣，才能使物業(yè)管理走向現代化。

　　現在物業(yè)管理中軟件的應用大致有三個(gè)層次（或稱(chēng)三種階段），第一層次為單項數據處理，模仿手工管理方式，多用于簡(jiǎn)單的事物性工作，這是目前國內大多數物業(yè)管理公司計算機應用水平。第二層次是數據綜合處理，此時(shí)計算機應用呈現網(wǎng)絡(luò )化和實(shí)時(shí)處理特點(diǎn)，已經(jīng)具備部分提高物業(yè)管理效率的特點(diǎn)。第三層次則是管理信息系統，此時(shí)信息論、控制論、軟件工程等優(yōu)化理論在軟件程序中得以運用，計算機網(wǎng)絡(luò )和數據庫的建立，使計算機由管理某個(gè)單一系統發(fā)展成全面的管理信息系統。系統集成能力的高低和決策分析功能，成為衡量此階段物業(yè)管理軟件水平的依據。筆者在物業(yè)管理軟件的開(kāi)發(fā)使用與維護中對所發(fā)現或存在的問(wèn)題，進(jìn)行了分析，提出了一些改進(jìn)的措施，希望能夠引起物業(yè)管理系統軟件開(kāi)發(fā)的同行們對這些問(wèn)題的思考。

　　1、需求分析直接關(guān)系到軟件的質(zhì)量和生命周期

　　1.1領(lǐng)導的重視程度和參加需求分析人員的因素

　　首先，軟件項目開(kāi)發(fā)是一把手工程，這一點(diǎn)企業(yè)領(lǐng)導一定要明確，一般情況下企業(yè)一把手對軟件開(kāi)發(fā)的重視程度越高，軟件成功的可能性就越大，但實(shí)際上大多數企業(yè)的領(lǐng)導卻對軟件開(kāi)發(fā)工作并不關(guān)心和重視，往往只是安排下去后就不再過(guò)問(wèn)，有的領(lǐng)導甚至認為只要把計算機買(mǎi)來(lái)了電腦里就什么都有了，想要什么只要一敲鍵盤(pán)就會(huì )有了。企業(yè)領(lǐng)導不光要重視軟件的開(kāi)發(fā)工作，還應對使用計算機進(jìn)行企業(yè)管理有相當的認識，不能只是憑一時(shí)心血來(lái)潮或要搞一些政績(jì)工程就要搞軟件開(kāi)發(fā)。其次，參加需求分析的業(yè)務(wù)人員（指所有設計、運行、維護、管理計算機信息系統的技術(shù)人員）的素質(zhì)與工作狀況直接影響信息系統的建立與實(shí)施，這一點(diǎn)不可忽視。在組建時(shí)必須綜合考慮每個(gè)工作人員的特長(cháng)及優(yōu)勢協(xié)調，對業(yè)務(wù)了解的深刻程度，參加的人員中還應包括部分軟件的最終使用者，這些人應盡量選擇有應用管理系統經(jīng)驗的人。如果能有參加過(guò)軟件開(kāi)發(fā)經(jīng)驗的人員就更好了，往往這些人能提出一些好的建議，會(huì )使開(kāi)發(fā)過(guò)程少走很多彎路。

　　1.2明確開(kāi)發(fā)的目的

　　需求分析的任務(wù)是確定系統必須完成那些工作，要對目標系統提出完善、準確、清晰、具體的要求。需求分析是軟件定義時(shí)期的最后一個(gè)階段，這時(shí)必須準確回答“系統必須做什么”這個(gè)問(wèn)題，需求分析的結果是系統開(kāi)發(fā)的基礎，關(guān)系到整個(gè)軟件工程的成敗和軟件的質(zhì)量。另外，對現階段業(yè)務(wù)的需求要貼近實(shí)際，對未來(lái)的業(yè)務(wù)需求也應該具有前瞻性。

　　在需求分析的過(guò)程中要盡量多地組織開(kāi)發(fā)小組，與實(shí)際要使用系統的業(yè)務(wù)人員討論和溝通，要從用戶(hù)處收集需求的合理性，這樣，才能真正明白要達到業(yè)務(wù)目標所需的功能和用戶(hù)要求，只是憑空猜想用戶(hù)的要求結果是不會(huì )令人滿(mǎn)意的。如何能獲得需求呢，通過(guò)有效的用戶(hù)—— 開(kāi)發(fā)者的合作才能成功。需求獲取是一個(gè)需要高度合作的活動(dòng)，必須透過(guò)客戶(hù)所提出的表面需求理解他們的真正需求。詢(xún)問(wèn)一個(gè)可擴充的問(wèn)題有助于更好地理解用戶(hù)目前的業(yè)務(wù)過(guò)程，并且知道新系統如何幫助或改進(jìn)他們的工作。

　　調查用戶(hù)任務(wù)可能遇到的變更，或者用戶(hù)需要使用系統其他可能的方式。想象自己在學(xué)習用戶(hù)的工作，需要完成什么任務(wù)？有什么問(wèn)題？從這一角度來(lái)指導需求的開(kāi)發(fā)和利用。還有探討例外的情況，比如，什么會(huì )妨礙用戶(hù)順利完成任務(wù)？用戶(hù)對系統錯誤情況的反映，是如何想的？搞一些需求討論會(huì )，會(huì )上必須把所有的討論記錄下來(lái)，同時(shí)，還要做一定的整理。如果不這樣做，那么結束會(huì )議的時(shí)候就會(huì )發(fā)現，所有的討論只剩下一個(gè)模糊的印象。在座談?dòng)懻撝�后記下所討論的�?wèn)題，請參與討論的用戶(hù)評論并更正。及早并經(jīng)常進(jìn)行座談?dòng)懻撌切枨螳@取成功的一個(gè)關(guān)鍵途徑，只有這樣，才能確定是否真正獲取需求。

　　研究表明：與不成功的項目相比，一個(gè)成功的軟件項目在開(kāi)發(fā)者和用戶(hù)之間采用了更多的交流方式。與單個(gè)客戶(hù)或潛在的用戶(hù)組一起座談，對于業(yè)務(wù)軟件包或信息管理系統（MIS）的應用來(lái)說(shuō)是一種傳統的需求來(lái)源。盡量理解用戶(hù)用于表述他們需求的思維過(guò)程，充分研究用戶(hù)執行任務(wù)時(shí)做出決策的過(guò)程，并提取出潛在的邏輯關(guān)系。流程圖和決策樹(shù)是描述這些邏輯決策途徑的好方法。

　　1.3不能把可行性研究當作是需求分析

　　雖然可行性研究是一次完整的分析設計過(guò)程，此階段已粗略了解了用戶(hù)的需求，甚至提出了一些可行性方案，但卻可能忽略許多細節，而最終在需求分析中卻不能遺漏任何一個(gè)微小的細節，遺漏了可能會(huì )給軟件的開(kāi)發(fā)造成很大的麻煩。

　　2、軟件開(kāi)發(fā)過(guò)程中應注意的問(wèn)題

　　軟件開(kāi)發(fā)的開(kāi)始要明確系統將采取什么體系結構，計算機網(wǎng)絡(luò )采取什么樣的拓撲結構，用戶(hù)將采用什么樣的系統平臺。

　�。�。１　　如何選擇好數據庫管理系統

　　數據庫軟件和開(kāi)發(fā)工具軟件對整個(gè)管理系統的二次開(kāi)發(fā)和系統升級是至關(guān)重要的。建議數據庫管理系統可采用 ORACLE 或 Microsoft SQL Serve，開(kāi)發(fā)工具可采用 ORACLE Developer 2000、PowerBuilder、Delphi 等。一個(gè)好的物業(yè)管理軟件，應構建在一個(gè)好的網(wǎng)絡(luò )、數據庫、程序語(yǔ)言和操作系統平臺上�？梢哉f(shuō)，對數據庫結構的設計和管理與前期需求分析的好壞，決定整個(gè)軟件的質(zhì)量和生命。而開(kāi)發(fā)工具卻可以靈活選擇，因為現在開(kāi)發(fā)信息管理系統前端基本上都采取模塊化形式，這樣，可以使軟件的開(kāi)發(fā)更加靈活，方便軟件的升級和系統的二次開(kāi)發(fā)。

　　2.2采用什么樣的計算機網(wǎng)絡(luò )拓撲結構

　　可以根據管理規模的大小和管理形式靈活設置。 物業(yè)管理信息系統軟件采用客戶(hù)/服務(wù)器 （Client/Server）體系結構。采用局域網(wǎng)（LAN）作為物業(yè)管理上層的內部網(wǎng)絡(luò )。各部門(mén)內的計算機均通過(guò)局域網(wǎng)連接到服務(wù)器上，能為公司內部不同職能部門(mén)的合作提供服務(wù)，包括文件共享、數據共享等因管理規模較大，下屬多個(gè)分公司，采用了上下層結構，分公司采用小型局域網(wǎng)，與總公司的通訊則采用 PSTN（公用電話(huà)網(wǎng)）通過(guò)遠程撥號的形式實(shí)現數據的傳輸。

　　2.3在軟件編寫(xiě)過(guò)程中應注意的問(wèn)題

　�。�1）應盡量考慮最終系統操作人員的技術(shù)及業(yè)務(wù)人員情況，要多與客戶(hù)進(jìn)行溝通，溝通方式應根據內容而多樣化，要講究有效率的溝通。應盡量使客戶(hù)端界面友好、幫助或提示應較完善，應該使操作使用簡(jiǎn)單方便，畢竟現在國內的物業(yè)管理企業(yè)中存在著(zhù)整體素質(zhì)偏低這一普遍現象，他們是軟件的最終使用者。

　�。�2）在軟件的編寫(xiě)過(guò)程中，應重視開(kāi)發(fā)小組的團隊精神與分工協(xié)作問(wèn)題。由于各階段不同角色或同階段不同角色之間的責任分工不同，工作互相推諉、責任互相推卸、不愿意與他人協(xié)作。這些現象或多或少地造成了項目團隊內部資源的損耗，從而影響了項目的進(jìn)展。

　　出現這種情況主要是軟件項目負責人的責任，項目負責人應當盡快地將工作范圍進(jìn)行分解，并將分解的工作責任分配給團隊成員，這樣就可以按任務(wù)分清每個(gè)人的責任。項目負責人應當對項目成員的責任進(jìn)行合理的分配并清楚地說(shuō)明，同時(shí)應強調不同分工、不同環(huán)節的成員應當相互協(xié)作，共同完善。

　�。�3）對于開(kāi)發(fā)過(guò)程中需求的變更也是不可避免的，諸如改變界面、改變操作方式、業(yè)務(wù)需求的改變等，對于業(yè)務(wù)的需求變更一般都是在需求分析中沒(méi)有正確收集信息造成的，應盡量避免，可能一些變更是由于政策變更等不確定因素造成的，這一點(diǎn)在一些國有的物業(yè)管理企業(yè)表現尤為突出，這樣的情況要客觀(guān)對待。如果無(wú)休止的根據用戶(hù)的需求不停地修改軟件，往往會(huì )造成開(kāi)發(fā)過(guò)程一再延續，導致成本成倍增加，使原來(lái)的設計變得支離破碎，系統難以維護。例如，在房屋分戶(hù)合戶(hù)部分由于業(yè)務(wù)人員對業(yè)務(wù)、政策的掌握程度不夠，工作不夠認真，發(fā)生多次變更，導致這一模塊在系統開(kāi)始應用時(shí)還不能正常使用，間接影響了許多與之相關(guān)的功能模塊，造成了很大的麻煩。為避免需求變更的發(fā)生應加強對參加需求分析人員的培訓，增強行業(yè)知識背景，端正工作態(tài)度，加強與用戶(hù)的溝通，把需求分析做的盡量完善。

　　3、在軟件測試階段與使用維護中出現的問(wèn)題

　　軟件測試是發(fā)現軟件中錯誤和缺陷的主要手段。在一般情況下，軟件測試過(guò)程與整個(gè)軟件開(kāi)發(fā)過(guò)程基本上是平行進(jìn)行的。測試計劃早在需求分析階段即應開(kāi)始制定，其它相關(guān)工作，包括測試大綱的制定、測試數據的生成、測試工具的選擇等也應在測試階段之前進(jìn)行。充分的準備工作可以有效地克服測試的盲目性，縮短測試周期，提高測試效率。一般測試工作量占整個(gè)項目開(kāi)發(fā)工程的 40%~50%，對于測試階段出現的問(wèn)題，軟件的開(kāi)發(fā)小組應盡量與使用者進(jìn)行及時(shí)有效地溝通，盡快將問(wèn)題解決。

　　在軟件的使用過(guò)程中系統用戶(hù)包括所有使用物業(yè)管理信息系統的人員，如財務(wù)人員、各層管理人員等，他們對信息系統的了解程度將決定物業(yè)管理信息系統的使用效果。因此，必須加強對他們的業(yè)務(wù)培訓和計算機基礎知識教育。軟件的維護人員應對整個(gè)軟件系統要有較深入的了解，包括業(yè)務(wù)和技術(shù)兩方面。畢竟物業(yè)管理是一門(mén)新興的科學(xué)，應該不斷在實(shí)踐中摸索，并不斷完善軟件的功能。

　　參考文獻：

　　[1] 李瑞軒，楊曼紅，王 俊。Oracle Developer2000 學(xué)習教程[M].北京：北京大學(xué)出版社，2000－07.

　　[2] 張海藩。軟件工程導論[M].北京：清華大學(xué)出版社，1998－01.

　　[3] 劉國濤。物業(yè)規范化管理與業(yè)主關(guān)系協(xié)調及經(jīng)典案例分析實(shí)用手冊[M]. 北京：北京科海高技術(shù)（集團）公司出版，2003－11.

　　[4] 盧琳生。軟件項目管理常見(jiàn)問(wèn)題分析[DB/OL].http://tech.ccidnet.com，2003－12－22.