軟件工程實訓項目案例--Android移動應用開發


實訓過程

角色分工

1.項目經理:負責項目的組織實施,制定項目計划,並進行跟蹤管理
2.開發人員:對項目經理及項目負責
3.需求分析員:負責系統的需求獲取和分析,並協助設計人員進行系統設計
4.系統設計、架構設計:負責系統設計工作,並指導程序員進行系統的開發工作
5.程序員:一般模塊的詳細設計、編碼測試,並交叉進行模塊的白盒測試
6.數據庫管理員:負責數據庫的建立和數據庫的維護工作
7.測試人員:進行項目各階段的測試工作,包括模塊測試、系統需求測試、集成測試、系統測試等工作(對用戶需求負責)
8.配置管理員:負責項目的配置管理
9.質量保證人員:有獨立的小組進行

需求分析及原型設計

1.需求分析階段
(1)獲取需求
+了解項目所有用戶類型及潛在的類型,然后根據用戶要求來確定系統的整體目標和系統的工作范圍
+將需求分為功能需求、非功能需求(如響應時間、平均無故障工作時間、自動恢復時間等)、環境限制、設計約束等類型
+確認需求獲取的結果是否真實地反映了用戶的意圖

(2)分析需求
+以圖形表示的方式描述系統的整體結構,包括系統的邊界與接口
+通過原型、頁面流或其他方式向用戶提供可視化的界面,用戶可對需求做出自己的評價
+系統可行性分析,需求實現的技術可行性、環境分析、費用分析、時間分析等
+以模型描述系統的功能項、數據實體、外部實體、實體之間的關系、實體之間的狀態轉換等方面的內容

(3)編寫需求文檔
+使用自然語言或形式化語言描述
+添加圖形的表達方式和模型表征的方式
+需包括用戶的所有需求(功能性和非功能性)

用於需求建模的方法有很多種,最常用的包括用例圖、實體關系圖和數據流圖三種。用例圖多用在面向對象的開發中,通過描述系統和活動者之間的交互來描述系統的行為,最主要優點在於它是用戶導向的,用戶可根據自己所對應的用例來不斷細化自己的需求,此外,Use Case還可以很方便地得到系統功能的測試用例。

實體關系圖(ERD)用於描述系統實體之間的對應關系,需求分析階段使用ERD描述系統中實體的邏輯關系,在設計階段則使用ERD描述物理表之間的關系。ERD只關注系統中數據間的關系,而缺乏對系統功能的描述。

DFD數據流圖作為結構化系統分析與設計的主要方法,尤其適用於MIS系統的表述。DFD使用4種基本元素描述系統的行為:過程、實體、數據流及數據存儲。DFD方法直觀易懂,使用者可以方便地得到系統的邏輯模型和物理模型,但是無法判斷活動的時序關系。

2.原型設計
對於Android項目而言,原型設計的重要性更為突出,界面(美觀+易用性)是移動應用的靈魂。
原型設計,絕不僅僅是畫幾個界面,設計思路應遵循“用戶導向+簡易操作”原則
+要形成人們希望的產品使用方式,以及人們為什么想用這種產品等問題的見解
+尊重用戶知識水平、文化背景和生活習慣
+通過界面設計,讓用戶明白功能操作,並將作品本身的信息更加順暢得傳遞給使用者
+通過界面給用戶一種情感傳遞,使用戶在接觸作品時產生情感共鳴
+展望未來,要看到產品可能的樣子,它們並不必然就像當前這樣

需求分析階段的注意事項:

1.需求分析階段關注的目標是“做什么”,而不是“怎么做”
2.識別隱含需求(有可能是實現顯式需求的前提條件)
3.需求符合系統的整體目標
4.保證需求項之間的一致性,解決需求項之間可能存在的沖突

需求及原型評審

評審重點:
1.功能:軟件的用途
2.外部接口:此軟件如何與人員、系統硬件、其他硬件及其他軟件進行交互
3.性能:不同軟件功能都有什么樣的速度、可用性、響應時間、恢復時間等
4.屬性:在正確性、可維護性、安全性等方面都有哪些事需要考慮
5.是否指定了在需求規格說明書之外的任何需求
6.不應說明任何設計或實施細節
7.不應該對軟件附加更多約束
8.需求規格說明書是否合理限制了有效設計的范圍而不指定任何特定的設計
9.需求規格說明書是否顯示以下特征:
(1)正確性
(2)明確性:每個需求是否都有一種且只有一種解釋;是否已使用客戶的語言;是否使用圖來補充自然語言說明
(3)完全性:需求規格說明書是否包括所有的重要需求;是否已確定並指出所有可能情況的輸入值的預期范圍;響應是否已同時包括在有效輸入值和無效輸入值中
所有的圖、表和圖表是否都包括所有評測術語和評測單元的完整標注、引用和定義?是否已解決或處理所有的未確定因素
(4)一致性
需求規格書是否與前景文檔、用例模型和補充規約一致?它是否與更高層的規約一致?它是否保持內部一致,其中說明的個別需求的任何部分都不沖突?
(5)排列需求的能力
每個需求是否都已通過標識符來標注,以表明該特定需求的重要性或穩定性?
是否已標識出正確確定優先級的其他重要屬性?
(6)可核實性
在需求規格說明書中說明的所有需求是否可被合適?
是否存在一定數量可節省成本的流程可供人員或機器用來檢查軟件產品是否滿足需求?
(7)可修改性
需求規格說明書的結構和樣式是否允許在保留結構和樣式不變的情況下方便地對需求進行全面統一的更改?
是否確定和最大限度地減少了冗余,並對其進行交叉引用
(8)可追蹤性
每個需求是否都具有明確的標識符
每個需求的來源是否確定
是否通過顯式引用早期的工作來維護向后可追蹤性
需求規格說明書產生的工件是否具有相當大的向前可追蹤性

概要設計

數據庫設計

設計評審

測試



免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM