標籤:
一、引言
1、編寫目的
由於大多數人對於醫學知識的匱乏,導致很多人一生病就直接去醫院,導致小病麻煩治,如果能夠有一個健康助手,當你生病的時候能夠提醒你該什麼時候吃藥、吃什麼藥,可以極大的方便以及及時的對症下藥,早日康複。
目前智能手機已經極大化的豐富了人們的生活,鑒於目前市場上主流的手機系統,所以決定開發一款基於安卓系統的app,來為人們的健康提供合理的建議。
2、項目背景
a、軟體名稱:尋醫問藥;
b、項目的任務提出者:李國松;
c、開發人員:李國松、夏雪、朱慧萍、葉婷、肖曼、高珂婷;
3、定義
預存程序是儲存在本機資料庫上的由sql語句和控制流程語句組成的一個先行編譯集合
觸發器屬於一種特殊的預存程序,可以在其中包含複雜的sql語句。觸發器與預存程序的區別在於觸發器能夠自動執行並且不含有參數。
4、參考資料
二、可行性研究的前提
1、要求
a、功能:能夠針對使用者的目前病理特徵做出準確的癥狀匹配,並推薦對應的藥物;
b、效能:當使用者輸入初始癥狀能夠列出相關的併發症狀作為可選目標。使用者還可以輸入列舉的沒有的癥狀;
c、輸入:文字輸入、語音輸入(預想功能,版本升級後可使用);
d、輸出:文字輸出、語音輸出(預想功能,版本升級後可使用);
e、完成期限:15天。
2、目標
a、控制精度:對發病癥狀的模糊比對,不得多於兩個癥狀;
b、管理資訊服務:對於使用者的個人病例資訊,採用密碼驗證方式進行保護,避免使用者隱私泄露;
c、對小組內人員進行合理分配任務,使得工作效率能夠顯著提高。
3、條件、假定和限制
a、建議軟體啟動並執行最短壽命:1年;
b、使用限制:本軟體只針對日常的普通病症,對於較重的病症,不建議使用本軟體,應及時就醫,以免耽誤病情;
c、法律責任聲明:本軟體僅對日常普通疾病提出建議,使用者需自行辨識,如有某些醫學意外發生,開發人員不擔負任何責任;
d、運行環境:安卓系統4.4版本及以上版本;
e、開發工具:eclipse;
4、可行性研究方法
決定可行性的主要因素:各種藥物與癥狀的匹配的準確性。
三、對現有現有的系統的分析
1、處理流程和資料流程
使用者輸入已知的癥狀,軟體調用資料庫對使用者輸入的癥狀進行匹配,如果有多個病症相對應,返回各個癥狀間不同點呈現,讓使用者選擇有哪些癥狀進行精確匹配。如果最後對應兩個以及兩個以上的癥狀,則返回無法匹配,讓使用者及時就醫。
2、人員、裝置
人員配備:
組長:李國松【軟體主體架構的搭建,邏輯結構的編程】
組員:夏雪【檔案的收集整理存檔資料庫文檔的錄入】
肖曼【檔案的收集整理存檔資料庫文檔的錄入】
高珂婷【資料庫的搭建與維護】
朱慧萍【資料庫的搭建與維護】
葉婷【ui介面的設計以及製作】
3、局限性:目前病例少,驗證機會少,對有些問題的判斷不一定 準確。
四、社會因素可行性分析
1、法律因素:本軟體僅對日常普通疾病提出建議,使用者需自行辨識,如有某些醫學意外發生,開發人員不擔負任何責任;
2、使用者使用可行性
基本能夠解決家庭生活遇到的基本疾病問題,尤其適合自身對藥理知識不瞭解的人。
五、結論
通過本次課程設計,將課堂上講的知識與實踐相結合,能夠提高團隊合作意識,尤其是在觀察、分析和解決問題的實際工作能力有所提高。通過這次課程設計,知道了軟體開發的流程,在軟體設計時首先要根據使用者的要求對整個工程的架構進行細緻的劃分,需要完成哪些的功能,功能如何進行分類,都應該在開發之前確定好。對工程進行模組化設計,畫出整體架構結構圖,這樣在開發時可以按部就班,有條不紊的根據先前的設計來進行。對於資料庫的的設計,對資料之間的關係要進行詳細的分析,對各個表單之間的引用和從屬關係應有的關聯圖表來表示。介面的功能應儘可能的具有多樣性,避免功能分散,如果對話方塊很複雜,使用者使用起來會比較麻煩。程式碼盡量做到簡潔明快,盡量將具有獨立功能的代碼提煉出來,在偵錯工具時也減少了很多麻煩。
另外,系統應具備較強的容錯能力,對使用者非法的輸入應有準備,因為程式的實際操作人員可能並不懂得這些,在實際操作時可能常會出現錯誤操作或者非法輸入。所以我們編寫程式就應該對此有所防範,對於誤操作或非法輸入應在執行相應的處理前做防錯處理,彈出提示對話方塊。
在這次課程設計中,我深切體會到物件導向的額博大精深,正如軟體工程的原則:項目不管大小,對待的方法都是一樣的,這和人類處理問題的方式一樣,首先要知道要完成的這個項目是什麼,他的特性是什麼,其次在完成的過程中會遇到哪些問題,遇到這些問題要採用什麼辦法去解決,最後就是如何?計劃來解決這些問題,完成項目。
與隊友的合作是一件快樂的事情,只有彼此都付出,彼此都努力維護才能將作品做的更加完美。而團隊合作也是當今社會最提倡的。
尋醫問藥軟體