2018軟工實踐第八次做業

目錄

• 團隊信息
• 分工選擇
  • 課上分工
  • 課下分工
  • ToDolist
  • alpha版本要作的事情
  • 燃盡圖
• UML
  • 用例圖
  • 狀態圖
  • 活動圖
  • 類圖
  • 部署圖
  • 實例圖
  • 對象圖
  • 時序圖
  • 包圖
  • 通訊圖
• 貢獻分評定
  • 課上貢獻分
  • 課下貢獻分
• 工具選擇
  • StarUML
  • Process on
• 使用工具感覺
  • StarUML
• PSP表格
• 換隊感覺

團隊信息

隊名 404 Note Found

隊長：胡緒佩

臨時隊長：周政演

團隊會議紀要連接

學號	姓名	博客連接
031602543	周政演	http://www.javashuo.com/article/p-kiosznsv-gh.html
031602510	葛家燦	http://www.javashuo.com/article/p-exmqjzvh-gk.html
031602513	黃鴻傑	http://www.javashuo.com/article/p-weahklwn-gm.html
031602627	劉愷琳	http://www.javashuo.com/article/p-xnrlsola-go.html
031602113	何宇恆	http://www.javashuo.com/article/p-gyatofhg-gp.html
031602444	莊卉	http://www.javashuo.com/article/p-ydcgmnng-ge.html
031602525	劉一好	http://www.javashuo.com/article/p-gbeichju-ev.html
081600410	胡青元	http://www.javashuo.com/article/p-cozmifac-eh.html
031602114	胡緒佩	http://www.javashuo.com/article/p-kstprbhu-dz.html
031602511	何家偉	http://www.javashuo.com/article/p-oynqqnns-dt.html
031602539	翟丹丹	http://www.cnblogs.com/breakbreak/p/9822763.html

分工選擇

課上分工

課下分工

ToDolist

alpha版本要作的事情

迭代原則，由核心功能到輔助功能

燃盡圖

UML

用例圖

描述的部分：

• 描述了咱們軟件必須完成的任務，定義了必須完成的軟件功能；
• 基本呈現用戶與用例之間的具體關係；
• 基本表達系統的基本功能；
• 基本表達系統的具體行爲。

面臨的問題：

• 如何具體對用例進行分類，使得用例更加具體；
• 如何對用戶與不一樣用例之間的關係詳細分析。

解決的問題：

• 初步獲取用戶的需求；
• 指導測試；
• 在整個過程當中對其餘工做流起到指導做用。

狀態圖

【part1】
描述的部分：

• 描述了用戶登陸及未登陸使用的狀態。

面臨的問題：

• 面臨用戶帳號管理及雲備份的問題。

解決的問題：

• 解決了用戶使用雲備份功能的問題。
• 解決了用戶註冊登陸流程的問題。
• 解決了用戶找回密碼的問題。

附圖：

【part2】
描述的部分：

• 描述了用戶新建自定義備忘的狀態。

面臨的問題：

• 面臨用戶添加自定義備忘條目選填信息較多的問題。

解決的問題：

• 用戶只需添加標題即可新建備忘，選填信息個性化添加。

附圖：

【part3】
描述的部分：

• 描述了備忘信息的狀態。

面臨的問題：

• 備忘錄的備忘錄事項狀態較多，如何分類、組織的的問題。

解決的問題：

• 用戶可清晰瞭解備忘錄事項的各類狀態。

附圖：

【part4】
描述的部分：

• 描述了全部備忘展現的狀態。

面臨的問題：

• 備忘信息分類方式不一樣及備忘信息展現形式比較多對於用戶較複雜。

解決的問題：

• 方便用戶切換查看備忘信息的分類方式，如按時間順序與事務類型。
• 方便用戶選擇備忘信息展現的形式。

附圖：

活動圖

描述的部分

• 備忘錄生成過程。
• 個性化壁紙設計。
• 用戶自定義備忘錄設置。

面臨的問題

• 面臨帳戶管理問題。
• 用戶自定義設計問題。如何使用戶得到喜好的簡潔實用的備忘錄壁紙。

解決的問題

• 提供用戶行爲分析功能，對用戶娛樂，遊戲方面進行時間監控。
• 提供智能分析功能，智能讀取快遞信息和訂單信息，將有效信息轉化成備忘錄。
• 提供智能提醒功能，在備忘錄自定義提醒時間以前進行短信提醒，並提供天氣提醒附加功能。
• 提供壁紙生成功能，用戶自定義壁紙樣式，字體顏色及字號，完成個性化特點壁紙設計。

附圖

類圖

描述的部分：

• 描述了咱們軟件必須完成的類、接口以及它們之間的靜態結構和關係；
• 類的部分：用戶、備忘錄、備忘錄分類夾、桌面控件、鎖屏壁紙、圖片、音頻、備忘詳情、智能分析、快遞信息、訂單信息、天氣信息；
• 關係部分：關聯、聚合、泛化；

面臨的問題：

• 繪製類圖軟件的選擇和該軟件在類圖繪製上的使用方法；
• 類的定義（如屬性和方法）和個數比較不明確；
• 各類類之間的關係比較模糊；

解決的問題：

• 1肯定使用StarUML進行類圖繪製並搜索相關博客教程學習使用StarUML繪製類圖；
• 2 與其餘負責後端任務的組員討論交流溝通，肯定主要的類的屬性、方法和個數；
• 3與組內負責前端、原型設計和其餘UML圖繪製的組員反覆溝通；

附圖：

部署圖

描述的部分：

• 描述服務器內部構建
• 描述軟件物理構架示意圖
• 描述軟件與硬件組件之間的物理關係以及處理節點

面臨的問題：

• 咱們沒法提供24小時開機的主機，只能進行租借與託管

解決的問題：

• 解決了開發者對於物理構架的宏觀理解
• 提供了科學可實現的物理框架構建

附圖：

實例圖

描述的部分：

• 描述用戶和軟件之間、軟件各個部分之間的聯繫
• 描述軟件的邏輯結構
• 描述實體與其屬性的聯繫，是用來描述現實世界的概念模型。

面臨的問題：

• 1.具體實際功能要與後端商議，進行必定修改

解決的問題：

• 1.明確了各個部分的具體功能
• 2.具體解決了數據庫的設計

附圖：

對象圖

描述的部分：

• 軟件運行中的靜態時刻，描述對象之間關聯的實例；
• 描述某一個應用情景；

面臨的問題：

• 具體的應用情景需求；
• 數據流圖的設計；
• 抽象語義的可視化描述；

解決的問題：

• 能夠直觀表示出系統在某一個時刻（情景）一組類的實體之間的關係；
• 經過查看某個時刻不一樣類之間的關係，思考概括數據流圖；
• 對系統的設計視圖建模時，可使用一組類圖完整地描述抽象的語義以及它們之間的關係；

附圖：

時序圖

雲備份

描述的部分

• 這裏描述了系統的雲備份部分

面臨的問題

• 要面臨雲搭建的，以及訪問的問題

解決的問題

• 設計幫助後端成員理解這一過程

附圖

登錄系統：

描述的部分

• 這裏描述了用戶登錄系統時遇到的狀況

面臨的問題

• 面臨與數據庫鏈接訪問和與現有信息匹配的問題
  解決的問題
• 幫助編碼人員分析登錄時遇到的狀況

附圖

備忘錄管理：

描述的部分

• 這裏描述了用戶對備忘錄進行操做時遇到的狀況

面臨的問題

• 面臨對備忘錄的內容進行增刪改的問題

解決的問題

• 幫助編碼人員分析錄入備忘錄時遇到的狀況

附圖

備忘錄類別：

描述的部分

• 這裏描述了用戶對備忘錄類別進行操做時遇到的狀況

面臨的問題

• 面臨對備忘錄的類別進行增刪改的問題

解決的問題

• 幫助編碼人員分析修改備忘錄類別時遇到的狀況

附圖

壁紙系統：

描述的部分

• 這裏描述了用戶設定時遇到的狀況

面臨的問題

• 面臨如何使用備忘錄生成壁紙的問題

解決的問題

• 幫助編碼人員分析如何生成壁紙的狀況

附圖

智能分析：

描述的部分

• 這裏描述了備忘錄軟件進行智能分析時遇到的狀況

面臨的問題

• 面臨如何對用戶行爲進行分析和根據短信進行識別的問題

解決的問題

• 幫助編碼人員分析進行智能分析時遇到的狀況

附圖

包圖

描述的部分：

• 基本表達系統的基本功能
• 描述了軟件大體須要實現的功能

面臨的問題：

• 如何對於相關的類進行整合使之成爲更加簡練的包
• 對於相關包之間的關係如何顯示比較好

解決的問題：

• 大體瞭解整個軟件的使用過程
• 對於繁雜的類實現至關於文件夾的功能，看起來更加簡潔
• 實現了uml的附加功能之一

附圖

通訊圖

【part1】
描述的部分

• 描述的是用戶登錄註冊流程。

面臨的問題

• 面臨用戶帳號管理以及雲備份的問題。

解決的問題

• 解決用戶註冊登陸的問題
• 解決了用戶使用雲備份的問題
• 解決用戶找回密碼的問題。

附圖

【part2】

描述的部分

• 描述的備忘錄的生成以及刪除的問題。

面臨的問題

• 面臨備忘錄自動生成和用戶自行建立的問題。

解決的問題

• 解決用戶自動撰寫備忘錄的問題，解決根據手機短信生成備忘錄提醒的問題，解決備忘錄雲備份的問題。

附圖

【part3】

描述的部分

• 這裏是根據用戶手機上其餘APP的使用頻率自動生成分析圖表的部分

面臨的問題

• 應用使用頻率的獲取問題
• 生成分析圖表的問題
• 生成消息提醒的問題。

解決的問題

• 自動獲取應用使用頻率
• 自動生成分析圖表
• 自動發送消息提醒。

附圖

貢獻分評定

分工參考：

團隊內部一致交流後，大體分爲如下三個模塊：任務工做量、任務完成效率、反饋度。貢獻分評定不該當僅僅侷限於工做量，而應該綜合考慮全部對團隊發展的因素。具體理由分析：

• 任務工做量：如構建之法中所說，在軟件行業中，如何衡量工做量這自己就是一個大問題。可是工做量卻並不能由於其難以衡量便不予以考慮，咱們會採起團隊重複討論投票形式比較精確、公平的決定工做量佔比。好比：在還未開始時進行投票哪一個模塊的難度最大，工做量最多，這樣不夠全局天然也會存在誤差，所以咱們還會在實現過程當中中途繼續進行討論對初始工做量、難度的投票結果進行必定程度的更改使之更爲精確。儘可能避免出現：「明明有效的只有十行代碼，卻由於其中加了許多的冗餘代碼甚至是空行使其代碼量看上去較多」這類誤判狀況。所以咱們相信在咱們團隊中評定出的較爲合理的工做量做爲貢獻分佔比的重要參考數據可使團隊更良好的發展，相互良性競爭。

• 任務完成效率：團隊並不是一我的，而是許多個成員之間的總體，多個模塊功能組成的集合，相互之間的影響是很大的，產品的進度極可能會受其中某一個模塊而停滯不前。好比產品發佈時出現先後端有一個模塊還有一半未完成的現象那對整個項目的影響也很是大。所以任務完成效率也是一個重要衡量貢獻分佔比的數據。

• 反饋度：團隊想要良好的發展，就應當每個成員都儘可能保持較高的熱情和動力，這樣團隊纔會持久的具備活力和潛力。所以將反饋做爲一項重要參考數據決定貢獻分，防止出現由於個別成員懈怠致使整個團隊缺少活力，項目完成天然也受到影響。

考慮到本次工做的臨時性，既要考慮到貢獻分評定的公平性，又要考慮要計算的快速性，故採用如下方式

• 臨時貢獻分評定 ：我的任務量 45%+完成度45%+反饋狀況10%
• 要求：組裏總共11我的，分數加起來爲100分
• 每一個人結束前，對臨時隊內的每一個人進行評定，彙總給PM，PM對每一個人的給分進行平均，得出最後貢獻分

課上貢獻分

課下貢獻分

工具選擇

根據助教學姐推薦，以及轉進同窗的使用習慣，本次做業共使用了兩種工具：StarUML，ProcessOn。

StarUML

• 製做工具：staruml2.8
• 選擇理由：staruml功能完整、易上手；
• 本小組組內試用過ProcessOn和visio，前者缺乏部分構圖件，後者使用感受通常。

Process on

• 製做工具 Process on
• 選擇理由：
  • 支持流程圖、思惟導圖、原型圖、UML、網絡拓撲圖等；
  • 支持圖形界面操做，容易上手，方便實用；
  • 隨時將做品分享給隊友，達成團隊之間的共享，可以更好的協同合做，互相促進；資源豐富，圖庫資源強大；

使用工具感覺

本次做業使用了一種工具：StarUML

StarUML

• 這是一個很好的UML設計工具

經過這個工具很好的實現了個人時序圖的部分，日常的軟件一是沒法建立生命線這一重要控件，二是沒法針對各類實際狀況作出應對，例如循環，條件等都沒法進行設計。這款軟件完美地解決了這些問題，而且還能針對時序圖生成代碼，很好地契合了咱們的需求。

PSP表格

PSP8.1	header 2	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	35	30
· Estimate	·估計這個任務須要多少時間	15	5
Development	開發	0	0
· Analysis	需求分析（包括學習新技術）	60	60
· Design Spec	· 生成設計文檔	60	120
· Design Review	· 設計複審	30	30
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	0	0
· Design	· 具體設計	180	240
· Coding	· 具體編碼	0	0
· Code Review	· 代碼複審	0	0
· Test	·測試（自我測試，修改代碼，提交修改）	0	0
Reporting	報告	245	300
· Test Repor	· 測試報告	0	0
· Size Measurement	· 計算工做量	0	0
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	60	60
合計		685	845

換隊感覺

• 換走了pm以及其餘兩位同窗，因爲此次的任務比較簡單，因此沒有太大區別
• 因爲本次個人部分沒有和換來的同窗有交集，因此沒有更多的感覺，看他們的完成狀況仍是很優秀的！