第7-9章做業彙總

1.對四則運算軟件需求的獲取方式進行實踐，例如使用調查問卷訪問相關關係人等。

對四則運算軟件需求的獲取方式進行實踐，例如使用調查問卷訪問相關關係人等。

根據做業要求，咱們組採用了調查問卷的方式，在「問卷星」上建立了一份調查問卷。

調查問卷網址 https://sojump.com/jq/9930327.aspx

個人一個同窗如今在作小學數學老師，因此我就請她幫忙，讓她的同事以及學生幫我作了幾份調查問卷。雖然人數很少，可是，我以爲這個問卷結果對咱們的項目最終完成，仍有必定的幫助。

截止10月9日，調查結果分析報告：

http://files.cnblogs.com/files/msec2016/《小學生四則運算網站》需求分析問卷調查－報告.pdf

2採用四象限法將你小組的四則運算軟件的需求功能進行分類。闡述其優點與不足。

通過網上資料的收集，我深刻了解了四象限法則。

它把工做按照重要和緊急兩個不一樣的程度進行了劃分，基本上能夠分爲四個「象限」：既緊急又重要、重要但不緊急、緊急但不重要、既不緊急也不重要。

第一象限包含的是一些具備緊迫性和重要性的事情，沒法迴避也不能拖延，必須首先處理優先解決。

第二象限不一樣於第一象限，這一象限的事件不具備時間上的緊迫性，可是它具備極其重大的意義。計劃、準備、學習、培訓等事情都是屬於第二象限的工做。

第三象限中是那些緊急但不重要的事情，這些不重要的事件每每由於它緊急，就會佔據人們的不少寶貴時間。

第四象限中的事件沒有時間緊迫性，沒有重要性的。須要盡力去減小這些事情的存在，纔會提升工做效率。

這就是關於時間管理的「四象限法則」。

它的使用將會對咱們項目進展和實施進行有效的管理和約束，同時對於咱們平常學習工做生活中時間的管理也有極大的益處和啓發做用。

那麼針對咱們小組的四則運算軟件的開發，咱們提出的需求功能列舉以下：

1：註冊功能：用戶可以完成註冊；

2：登陸功能：用戶根據本身的帳號密碼進行登陸；

3：習題練習功能：用戶能夠進行作題練習，這也是系統實現的主要功能。

4：限時考試功能：用戶能夠選擇考試方式在規定時間內進行答題，而且系統會給出考試成績。

5：結果統計功能：用戶能夠看到本身練習的總題數，錯誤題數，以及計算出錯誤率。

6：錯題顯示功能：用戶能夠選擇曾經錯誤的題目進行仔細查看和分析。

7：教師查看功能：教師身份登陸能夠對學生的答題狀況經過系通通計查看。

8：教師出題功能：教授身份登陸能夠進行題目的添加和提交。

對於這些需求功能的分析我獲得以下劃分：

第一象限（重要緊急）：習題練習功能；結果統計功能；

第二象限（重要不緊急）：限時考試功能；成績顯示功能；錯題顯示功能；

第三象限（不重要緊急）：註冊功能；登陸功能；

第四象限（不重要不緊急）：教師查看功能；教師出題功能；

優勢：

首先，第一象限中包含的功能是該系統具有的最重要的功能，可以知足該系統存在所能提供的基本意義。

其次，對於咱們軟件系統功能進行劃分後我發現分佈於四個象限的事件數量均勻分佈。

雖然這並非最好的時間分配現狀，但也讓咱們有了更加明確的操做思路；給咱們一些提示如何去改進目前的工做；

例如方更多的時間和關注在第一象限的需求功能上，減小第四象限中功能的時間投入，獲取最大的工做效率，進一步確保項目如期按時的完成。

缺點：

對於第一象限和第二象限中這些緊急的需求功能，咱們組還未能按照預期時間進行開發未完成。

相比於第三第四象限中那些不緊急的事情若是還沒完成的狀況之下，重要工做的未完成讓咱們更有緊迫感的同時也指明瞭目前工做的缺陷；

咱們下一步就是加快進度，投入更多的時間在重要功能的實現上。

3.嘗試把四則運算軟件需求進行分解，變爲每一個小組成員可執行的積壓工做項，分配這些工做項到小組成員，並預算完成時間（以小時爲單位）。並在完成後填入實際用時。

對於咱們的系統詳細列出以下需求：

對於這些需求進行細分，獲得每一個人能夠執行的積壓工做項：

咱們組的進度因爲剛開始組員的畏懼心理已經超出了預計的任務完成時間節點，

所以在有限的時間裏，咱們組目前須要着重加快進度的部分就是進行代碼編寫的完成。

由於前端後端任務分配開了，所以每一個組員都要加快本身手頭的工做進度了。

4.總結近5周以來的github上的工做狀況，以圖表方式分析你小組的工做狀況、存在的問題及解決的方案。

工做狀況

圖表主要摘錄自 github 的 Graphs 項，首先是 contributors，

能夠看出組長同窗仍是寫的代碼比較多的，因爲前端的代碼尚未正式開始提交，因此有一位同窗的代碼貢獻還不能體現出來。

而後是整個小組的總體 commits 狀況，右上角紅框顯示了從 9 月 4 日（第一個 commit）開始每週的提交狀況，

能夠看出總體的工做狀態仍是不錯的，代碼提交量穩步上升（最近的那周是國慶放假）。

而後是代碼提交的時間分佈 punch card，絕大多數都是在下午以及晚上進行提交，

這是很容易理解的，畢竟標準的作法即是回宿舍前提交如下，算是整個一天工做的結束。

Network 給出了提交的一個時間跨度上的展現，仍舊是由於前端代碼尚未正式進行，因此，顯得比較單一。

最後是一個總體的 commit 展現，其頻率和數目挺多的，可仍舊是協做人員較少，沒能很好的體現整個小組做爲一個總體的工做。

存在的問題及解決的方案

咱們的進度是已經晚於預期了，緣由在於以前覺得會在國慶假期期間作一些工做，不過很遺憾，你們都有本身的安排，

另外，實驗室的一些不能提早預期的工做也給整個進度帶來很不利的影響。

還有就是你們 WEB 服務的程序編寫仍是比較生疏，負責前端編寫的兩位同窗是從零基礎學習，你們都是有些摸着石頭過河的感受。

固然，困難是客觀存在的，但作事總不能半途而廢，同時考慮到實際狀況，因此準備按照許多小的階段（迭代）進行，

先完成主要功能，即出題、解題的主要交互，以後考慮用戶的一些操做，而後再實現一些美化以及附加功能。