軟件技能論文范文

前言：我們精心挑選了數篇優質軟件技能論文文章，供您閱讀參考。期待這些文章能為您帶來啟發，助您在寫作的道路上更上一層樓。

第1篇

軟件運行出現性能方面的故障也是不可靠性問題之一。軟件產生運行故障特指客戶在使用軟件時，忽然出現故障問題，致使軟件產生了不科學的反饋。例如軟件忽然跳出或者造成系統死機。當前市場上幾乎所有的軟件都不可避免地存在運行問題。拿微軟最著名的WORD軟件來講，用戶在應用軟件過程中，會發生軟件沒有任何征兆地跳出的情況。假使客戶事前沒有保存文檔，就會導致之前編輯的內容統統作廢。這時，軟件的BUG就會給客戶使用軟件造成非常大的麻煩。此外，一些軟件存在著安全漏洞，伴隨著科學技術的不斷發展，計算機網絡化成為未來發展的走向，用戶通常會在網絡環境中應用計算機軟件。但是用戶發現部分軟件的性能沒有問題，安全方面卻存在著巨大的紕漏，一旦使用這些存在安全漏洞的軟件就會加大本地計算機的安全風險。我國名企生產的QQ軟件，就是由于出現安全漏洞才使用戶密碼經常被人盜走，給用戶帶來非常大的麻煩。

2軟件不可靠的解決對策

2.1做好軟件的評估審核

在實施軟件技術發展研究的過程中，需要隨時做好軟件的審核評估工作，以減少錯誤現象的發生概率。為保障軟件技術發展各個環節的標準一致，我們需要把軟件開發設計依據程序化實施，規避出現開發環節的跳躍性問題。能夠在軟件開發過程當中要及時進行對軟件的審核評估，這樣可以隨時察覺開發過程中出現的問題。有關的審核人員需要由管理、設計及保障人員共同組成，也包括不同崗位、各個領域的專家，以確保審核的專業水準。軟件的評估審核主要課題是考察設計人員交付的軟件文檔是否與之前文檔的準則與要求相統一，而且需要在考核后通過書面報告的形式得出相關的處理方案和評估結論，而質量保障工作人員則能夠根據審核的意見與結論進行具體的操作。通過這一系列環節的任務能夠有效降低軟件開發的不可靠風險，以提升安全可靠性。另外，我們必須建立系統的質量監控體系，完善管理機制，不應該一味地實施軟件開發人員的編碼、獨立設計與單獨測試，規避增加技術管理缺陷的發生概率。

2.2功能設計合理化

對計算機軟件進行合理化功能設計是非常有必要的。應當知曉軟件設計出來是要讓客戶使用的，因此，我們必須意識到客戶是使用的主要群體，而且軟件的功能設計必須符合客戶的普遍需要，這樣該軟件的開發才有意義。假使客戶要求的功能沒有，用戶則會以為軟件設計技術存在著重大的失誤。所以，軟件在開發之前，程序員不能總是以滿足自己的喜好來實施設計，必須要按照客戶的需求合理取舍，實現軟件設計與用戶需求的平衡。另一方面，使用適當的語言設計軟件程序過程中，如若選擇的語言設計相對比較合適，就會取得事半功倍的效果，假如使用的語言設計不合適，那么該語言就很有可能不符合軟件的需求。譬如你要設計一款管理學校圖書館的應用軟件，就必須依據圖書館數據量的大小挑選最能符合軟件功能需求的數據庫軟件，再選擇兼容性比較強的接口軟件。

3結語

第2篇

本研究為《基于物聯網技術的社區家庭老人實時智能健康監護系統的研究及實現》《The Internet of thingstechnology community home for the elderly health intelligentmonitoring system based on real-time》簡稱 IOT-HMS）項目中應用層軟件設計部分。

1.1 研究目標

①實時檢測被監護人的血壓、脈象、溫度、心跳等各項健康指標。

②利用物聯網技術使用 SIM900A 模塊的 GPRS 功能，將被監護人各項健康指標信息通過打包的方式通過移動數據交換中心發送給 PC 機。

③PC 機中設立數據庫包含被監護人的姓名、性別、照片、家庭地址、應急電話、以往病史以及被監護人健康指標參數等字段，當被監護人健康指標出現問題時，PC 機通過短信模塊向監護人手機發送預警短信，實現遠程監護功能。

④設備上自帶語音模塊，當被監護人出現嚴重健康狀況時，啟動語音模塊提醒鄰近人進行救助。

1.2 研究內容

本系統主要由三部分組成：感知層、傳輸層以及應用層

。①感知層包含被監護人健康指標檢測模塊以及 CPU控制模塊。檢測模塊包括血壓、脈象、溫度、心跳等健康參數檢測設備，負責對被監護人進行健康信息采集，向上傳輸至控制模塊；控制模塊是整個裝置的核心，由 CPU 負責對傳輸進來的各種信息進行智能分析并做出綜合處理。

②傳輸層包含 GPRS 服務器數據傳送模塊和預警短信模塊。GPRS 服務器數據傳送模塊將被監護人的健康參數通過打包的方式通過移動數據交換中心發送給 PC 機；PC 機將信息與數據庫中的信息進行比對，及時向監護人發送預警短信。

③應用層主要指 PC 機上的數據庫的建設。數據庫包含被監護人的姓名、性別、照片、家庭地址、應急電話、以往病史以及被監護人健康指標參數等字段，通過信息比對查詢，及時通過傳輸層發送預警信息。

2 軟件系統設計

軟件系統貫穿整個研究設計過程：從感知層需要運行在 STC12C5A60S2 平臺中的 C 程序，到運行在傳輸層和應用層的 windows 軟件程序。

2.1 軟件架構設計理念 軟件系統設計采用模塊化，各個軟件單獨設計，再集成。從而利于軟件功能的實現。

2.2 軟件設計 當采集數據通過 GSM/GPRS 系統傳輸到服務器中開始使用服務器軟件對數據進行處理。整體軟件架構思路如圖 1。

2.3 軟件處理流程 軟件的數據流處理流程如圖 2。

2.4 文件處理流程 文件的處理流程如圖 3。

2.5 軟件單元模塊

2.5.1 數據采集單元

通過運行于 STC12C5A60S2 單片機平臺中的 C 程序，實現被采集人的體溫等等健康指標的采集，采集數據實時通過 GSM/GPRS 模塊（SIM900B模塊）將數據送往服務器端。被采集人的個人識別信息通過軟件直接寫入單片機運行程序中。服務器端的 IP 地址通過使用花生殼動態域名進行解析，從而保證采集器可以實時通過 TCP/UDP 方式連接到服務器端。從而實現采集數據實時傳輸到服務器中。

2.5.2 數據接收單元

數據接收單元運行于服務器端。將以 TCP/DUP 方式收到的數據以文本文件的方式存儲于服務器中，便于入庫及掃描單元使用。數據接收單元實時運行。實時監控 TCP/UDP 端口的數據變化。

2.5.3 線程服務

線程服務單元為系統線程管理服務，通過該單元可以控制系統 CPU 的使用，控制文件掃描和處理的線程數量等。該單元保證了既充分利用系統資源的同時也避免了處理瓶頸的出現。線程服務單元通過配置文件以供系統組件使用，通過配置文件，可以修改線程池的大小，線程優先級，線程的等待隊列大小等等。線程池的大小決定了處理程序的并發度，線程優先級決定了處理程序獲得 CPU 執行的機會多少，線程的等待隊列可以限制排隊長度，當排隊數量超過指定限制時，向線程服務單元提交處理任務將會被阻塞，直到有線程處理完成且排隊數量減少為止。2.5.4 日志服務 為系統提供日志服務，以便開發和維護使用。可以通過該單元控制日志的輸出信息。

2.5.5 定時調度服務

該單元為服務組件，提供定時調度服務，其他單元可以利用該單元進行定時任務的注冊和解除。通常情況下文件的掃描、文件入庫等等任務都是由相關組件進行注冊，由定時調度單元進行適時調度的。定時調度主要是針對需要按時鐘來觸發的任務，比如說文件掃描任務、文件入庫任務、文件清除任務等等。

2.5.6 配置管理服務

為系統各個單元組件提供配置信息。專門設置配置管理單元，可以更方便的進行系統配置管理。將所有配置文件集中到該單元目錄下，以提供集中的配置管理。當然或許可以通過數據庫或者其他方式進行配置信息的管理。

2.5.7 文件掃描服務

當數據接收單元接收到數據并生成文本文件存于數據接收目錄中時，本組件可以方便的進行文件掃描控制，并可以按各種條件過濾文件：比如按修改時間戳過濾，按文件擴展名過濾。同時該單元會記錄已經處理過的文件，以保證不會被重復處理。該單元同時提供多種文件源掃描，比如 FTP、本地文件等。

2.5.8 標準監護數據計算服務

以 IOT-HMS 所輸出的數據為標準數據，在此單元中實現計算和輸出，輸出數據存入數據庫中。該單元同時控制數據的輸出格式，包括定時、定性數據輸出。該模塊具備可編輯性，能夠定制特定的數據輸出格式。

2.5.9 文件入庫單元

本單元對應文件處理流程中將掃描單元標記的文本文件打開，讀取，處理后將數據直接送入 SQL SERVER2008 數據庫中。數據的入庫將采用即時的入庫方式，從而保障數據查詢的及時性。當然入庫等過程需要周期，延遲當控制在 2分鐘以內。所以入庫的數據將使用 100 行或者 10 行等不同的數量同時入庫的方式。

2.5.10 文件清除單元

根據掃描單元的標記和入庫單元的入庫標記，將已經入庫的文件清除，從而還系統簡潔明快。

2.5.11 SQL SERVER 數據庫檢查單元

數據庫檢查單元負責檢查當前數據庫表結構是否適應于 IOT-HMS 的輸出，如果不適用，則會生成修改數據庫表結構的腳本或者建表腳本。這樣的檢查可以簡化數據庫結構升級，并減少因增減數據字段導致的系統不兼容。該模塊的產生是應對系統數據庫運行是否穩定。以及預防認為的在系統數據庫中增加非法表格和字段，造成系統空間浪費和數據錯誤的發生。一旦檢查發現錯誤，會進行及時修復，保障系統的干凈、高效。

2.5.12 自定義監護數據管理單元

可以自定義 IOT-HMS 系統的監控指標。按照用戶需求進行定義。

3 總結

第3篇

關鍵詞：會計軟件、反記帳、使用限制條件、數據處理

無論在手工會計還是在電算化會計中，都要根據已審核的記帳憑證登記帳薄，稱之為記帳，而反記帳則是將已經登記入帳的會計數據予以取消，使之恢復到記帳前的狀態，它是記帳的逆操作，也是電算化會計系統中才有的一個概念。會計軟件中要不要設有反記帳功能，一直存在激烈的爭論。因此即使會計軟件界在功能設計上借鑒成風的今天，反記帳功能卻遭遇迥異，金蝶第一個吃了螃蟹，在其“會計風暴”中加上了反記帳功能，而用友、安易等老牌會計軟件商則不以為然，拒絕反記帳功能在其軟件上“安家”。他們認為會計數據記帳后就不能修改，唯其如此，才能保證會計信息的質量和可信度，在人們對電子會計數據能否作為審計依據還存在種種爭議的情況下，反記帳功能將更加給人以一種不安全感。筆者認為，反記帳功能是電算化會計系統經濟業務處理結果發生錯誤時予以修正的理想方式，只要在設計時能充分考慮到其各種不足，對其使用設置嚴格的限制條件，就完全可以使其成會計軟件功能的一部分。

—、反記帳功能的作用

反記帳功能在下述情況發生時，有著無可替代的作用：

1、大量的錯誤憑證被登記入帳這種情況在電算化會計系統投入使用初期，尤其在試運行期間，非常容易發生。如果沒有反記帳功能，則只能編制大量的錯帳更正憑證予以更正，從而導致帳薄中存在大量無用的冗余信息，影響對會計信息的使用；也不利于審計工作的進行----當審計人員查到一筆又一筆的錯帳時，它們也許在后續的憑證中進行了更正，這種情況大量出現時，會使審計人員對錯弊產生麻痹思想，影響審計工作的效率和查錯能力。如果有反記帳功能就可以先取消記帳，把錯誤憑證全部修正后再重新記帳，帳薄中的冗余信息就可以大大減少，帳薄信息就會簡潔明了，便于利用。

2、帳證不符手工會計中由于會計人員的粗心，常常發生過帳錯誤，導致帳證不符，這時一般利用劃線更正法予以更正。在電算化會計信息系統中，記帳實質是將記帳憑證庫的有關數據轉入帳簿數據庫中，而且正式過有誤，則不管帳簿記錄是否正確均應先取消帳簿記錄數據，再對錯誤憑證一一進行修改，審核無誤后重新登記入帳。

3、記帳過程意外中斷在手工會計中，這也許不成為一個問題，記帳人員只須隨后續接下去登記就可以了。但在電算化會計系統中，記帳是由計算機自動進行的，當意外斷電、病毒侵襲等非常事件導致核算基本功能規范》也規定，會計軟件“應當具有在計算機發生故障或者由于強行關機及其他原因引起內部和外部會計數據被破壞的情況下，利用現有數據恢復到最近狀態的功能”。這里的最近狀態就是對最后一次記帳進行反記帳后的狀態。

二、反記帳功能使用條件設計

反記帳功能顯然不是一個常用的功能，它只有在前述特殊情況下才能使用。如果濫用反記帳功能，則不但影響會計處理的嚴肅性，也會大大增加工作量。許多人就是以此為反對在會計軟件中設計反記帳功能的理由。因此，對其使用必須嚴格限制。其限制條件至少必須包括：

1、操作者必須是得到系統管理員授權的原記帳人在電算化會計系統中，記帳人員應對帳簿的正確性負完全責任，誰記帳有誤就只能由誰負責修正。反記帳功能的目的，就是取消部分甚至全部的錯誤帳簿記錄以后重新正確記帳，從本質上講，它也是對錯帳的一種更正行為。為了保證記帳操作的嚴肅性，避免濫用反記帳功能，操作者必須同時得到系統管理員授權才能實施反記帳。

2、只能在結帳前進行結帳就是在本期經濟業務全部處理完畢，并被認為正確后予以封帳，使本期的經濟業務固定下來。進行結帳操作就意味著本期已經沒有經濟業務需要處理，因而不但不允許輸入本期的記帳憑證，也不允許對本期經濟業務進行記帳和反記帳。

3、只能按憑證號或日期逆序連續進行記帳是按日期和憑證號順序進行的，只有按其逆序連續取消帳簿數據庫的記錄，才能保證重新記帳的正常進行。這就意味著，反記帳的范圍應該以帳簿數據庫的最后一條記錄或者說是最后一張已記帳憑證為起點，依逆序前溯定位，來確定反記帳的記錄數，而不能允許從帳簿數據庫中間任意抽取幾條記錄（不管是否是連續）作為反記帳的范圍。

三、反記帳過程的數據處理

反記帳是記帳的逆操作，從某種意義上說，它也是記帳的一種特殊形式，因而在設計上必須將兩者結合起來考慮。在所有會計軟件中，記帳都是必備功能，根據一般的說法，計算機回到未記帳憑證庫中去，應該轉回的記錄就是反記帳的范圍。一般來說，這個范圍應該由反記帳執行人員根據需要指定。但是對于記帳過程意外中斷而進行恢復到記帳前狀態這種情況，會計軟件應該提供自動定位的功能。現有會計軟件的解決方案是在每次正式記帳前先將帳薄數據內容備份到硬盤某一固定文件中去，如本次記帳被意外中斷，則以備份文件恢復帳薄數據庫文件，由于每次備份到硬盤的文件名是固定唯一的，所以恢復只能對最后一次記帳進行，也只能進行一次。而且這種備份和恢復是對月內帳薄數據的完全備份和完全恢復，如果一個單位的經濟業務量較大時，在月度較遲時間進行記帳和反記帳，就會耗費較長的時間。為了提高效率，設想采用如下兩種方法加以解決：