| 這個作業屬于哪個課程 | 軟體工程 |
|---|---|
| 這個作業要求在哪裡 | 在這 |
| 這個作業的目标 | 回顧這門課程帶來的提升、團隊總結、實踐中的經驗總結、對下屆同學的建議、個人技術總結 |
| 作業正文 | |
| 其他參考文獻 | Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605 |
一、回望
1. 對比之前的目标
回顧了幾個月前對于自我長進的預期值，我的目标針對于軟體App類的開發，還捎帶有說過想涉獵前端部分。到了這學期結束我才意識到我把精力完完全全放在了前端部分。當初在標明團隊項目時有讨論過是Web開發還是App開發，因為大家都不熟悉App類開發是以標明了大家都有基礎的Web開發。正是如此，我的重心就偏離了當初想學的App開發。不過好在前端我也很喜歡。
2.對比之前的預期值
2.1 算法
之前我想要掌握多一點的常用算法，這一部分在本學期的另一門課《算法設計與分析》上得到了實作。
2.2 軟體需求
在之前的課程作業中，很少甚至根本不用涉及到需求分析的部分，是以我對它的分析方式以及編寫流程完全不熟悉，而這個學期學到了NABCD等分析法，自己的條理性也變得清晰了。
2.3 軟體設計
軟體設計部分來說是有提高的（自認為），不論是個人程式設計作業還是結對程式設計以及後續的團隊程式設計作業，每次開始前我腦子裡都會有比較完整的實作流程，好在我知道怎麼下手，明白了設計思路，開始實作就會變得簡單許多。
2.4 軟體測試
第一次接觸軟體測試是在本學期的單元測試部分，明白了怎麼實作程式的單元測試。在之前所有的作業中，我測試代碼的方法就是多設定幾個輸出标志，手動監控程式的走向。後期團隊程式設計中前端工作的檢驗測試是靠着浏覽器的調試部分進行的，要說這部分測試的提高可能就是更熟練運用檢查工具了，容易找到錯誤所在及原因。
3. 總結
3.1 統計時間與代碼量
| 所用時間(小時) | 代碼量（行） | |
|---|---|---|
| 寒假作業（1/2） | 10 | |
| 寒假作業（2/2） | 23.5 | 800 |
| 結對第一次作業 | 26.5 | |
| 團隊第一次 | 5 | |
| 結對第二次作業 | 40.3 | 1487 |
| 團隊第二次——實戰 | 12 | 400 |
| 團隊第三次——需求分析 | 6 | |
| 團隊第四次——系統與資料庫設計 | ||
| 軟體測評 | ||
| 團隊第五次——alpha | 80 | 2653 |
| 團隊第六次——beta | 40 | 同上合 |
| 個人總結 | ||
| 合計 | 275.3 | 5340 |
3.2 印象最深刻的作業
實話說，我認為每次作業都蠻深刻的。每次作業側重點不同，這種高連續性的作業布置之前也是沒有經曆過的。是以每次作業都是新鮮難忘的感覺。非要選出一個印象最深的就是團隊第二次作業，實戰一天完成口罩預約系統的那次。原因一是因為該作業的時間很短，二是因為這是團隊内第一次合作項目，三是因為我對所用架構并不熟悉。我還記得布置作業的那天早上，之前是完全沒有征兆的，突如其來的“大項目”給我沉重一擊，完了。後面組員快速地分好了任務，接着就是接觸我還沒開始學習的Vue架構。短時間根本不可能完成的任務造就了我黑暗的一天，夾雜着怕給組内拖後腿的壓力，硬着頭皮肝了一天，基本完成了表面界面的代碼編寫。那一天就吃了一頓飯，剩下的時間都是在想破腦袋鑽研Vue的實作，是真的無休息。跌跌撞撞的一天裡組内第一次合作産生了不少的麻煩和摩擦，加上大家都身心俱疲，真的是最難忘的一次作業。
3.3 累計時間
由上表可知，累計花了275.3個小時，平均每周花25個小時。
3.4 學習的新軟體、新工具、新語言、新平台
(1) 新軟體
在團隊合作項目階段，我一直使用的是VS Code。它不算新軟體，但是之前是不常用的，可以勉強算為新軟體吧。
XMind ZEN。這是我見過的最好用的思維導圖制作軟體，上手簡單，做出來的圖也很美觀。清晰的思維導圖在每次作業中都幫了大忙。
Typora。Markdown編輯軟體。是因為本次課我才第一次接觸markdown這種類型的文本編輯類型。這個編輯軟體也很好用，簡單易學，主要是界面很簡潔大方，給人一種寫作的欲望。
(2) 新工具
在課程的多次作業中我都有進行産品的原型設計，這也是我第一次接觸原型，是以學習掌握了多個原型工具，例如：墨刀、Axure RP。
(3) 新語言
Vue架構結合了之前學過的html+css+js，形成了“新”的前端開發語言，是我最主要學習的部分。
(4) 新平台
github。幾乎每一次作業都能用上github，它的功能屬實強大。第一次用的時候确實很難，密密麻麻的英文提示與功能。但是後期使用次數變多了之後就容易了不少，尤其是一些常用的功能已經可以很好地了解了。對于團隊合作來說真的很好用，實時更新同步很贊！
teambition。第一次接觸這個團隊協作平台。它可以友善我們記錄每個成員的任務，還可以自己生成燃盡圖，勾掉完成的任務框還蠻有成就感的。
部落格園。第一次将自己的文章釋出到這樣一個公開的平台。部落格園裡還有很多打代碼的大佬，有很多可以學習的各個方面的計算機知識，是一個很好的學習平台。自己可以DIY自己的部落格園還蠻有趣的，展現自己的風格。
3.5 提升
(1) 工程能力
對于大型的項目來說，工程能力太重要了。要把項目當成一個工程去看。之前我做作業的時候都是直接上手，做到哪一步算哪一步，是以最後的代碼複用性很差，耦合度也高，像一個毛線團。經過這幾次作業的學習，慢慢知道一個軟體産品的誕生是要經過各樣的過程，周圍繁瑣的工作是很多的。經過初期需求分析，架構設計，制定規範等過程才能有底氣去開始編寫代碼。這樣的代碼就會更好複用，結構性，條理性也會更好。
(2) 團隊合作
第一次和同學合作開發項目。好處是在大家可以互相幫助，各有所長，大大降低了整個産品的開發複雜度。壞處在于人多免不了管理困難以及合并代碼困難。團隊合作讓我提高了自己的溝通能力，學會和隊友合作商量一個課題内容的完成，可以聽到更多不同的想法，也學到了一些比較厲害的同學的開發經驗和知識。一個好的帶領者勝過幾十頁冷冰冰的教程。團隊合作也提升了我的集體榮譽感，有了一份責任。
(3) 測評能力
有一次作業要求測評騰訊實時通訊IM，我學會了用多個方面去評測一個産品，也會去尋找一些bug。并且針對同類産品進行較詳細的比較，并提出自己的一些想法，把所有的都整理在一篇文檔裡面。在用客觀的角度去使用和評價一個産品時，也是考驗總結能力和思維能力的。包括其中要求的采訪環節，第一次的體驗很新奇，提高了我的表達能力和概括問題的能力。測評能力對于之後自己開發的軟體也有較大的作用，真實客觀的評價可以提升産品品質。
二、 團隊總結
我在團隊中是前端開發，我完成了任務，我覺得我蠻适合這個角色的。
1. 組員發言
我作為組員，我認為組長的分工安排較為合理。我們組一共有七個人，開始是按照自願原則來安排分工的，剛好四個人選擇前端三個人選擇後端，而在第一次合作時，前端的一個同學自願退居到部落格編寫的工作了，就形成了三比三的穩定局面。組長的選舉我認為要公平公正。其實在分組的時候就差不多已經定了組長的人選，滿足的條件就是自己代碼編寫能力開發能力要強，可以協調好整組同學的工作，接納隊友的意見，是整個團隊的首位加入者，自然而然就選出來了。
2. 換組
本學期我沒有換組。
應該很少人想要被換掉。因為大家都在一起合作了很久，項目也都比較熟悉了，是以突然被移出原組除了重新接觸陌生項目的無力感還有離開熟悉環境的悲傷。剛開始我是不能了解的，覺得過于殘忍。新成員往往很難短時間融入這個新組，而新組也會安排較少的任務給新成員，感覺開發效率普遍降低。但是後來又看到助教發的換組的原因，也能了解了，提前适應職場上的變化也是一種好事。
3. 分析團隊
3.1 萌芽階段
我們團隊有經過萌芽階段，也就是團隊第一次作業，選題的時候。每個人才剛剛聚集在一起，都很陌生，所做的事沒有被記錄下來，因為責任不明确，為組做的一些小事就容易被忽略。大家都很和睦客氣，對于組内的事情的讨論也容易妥協或者不願提出自己的意見。在這期間組長帶領配置設定任務明确項目的雛形産生一個大概的項目開發計劃。
3.2 磨合階段
我們團隊有經過磨合階段，也就是團隊項目的第二次作業實戰時，組内就有較多的沖突。因為第一次合作，組内具體分工沒有落實，不知道自己該幹什麼。一整天都是處在自己給自己找活幹的情況中。最後有的部分沒有完成的也不知道是誰的責任，導緻最後大家都很累并且有點不滿。這次作業是我們團隊吸取最多經驗的一次。
3.3 規範階段
我們團隊有經過規範階段，也就是團隊項目的前期準備，需求分析、系統設計、資料庫設計時。每個人的職責非常明确，都很有默契的自己完成自己的部分，最後彙總到一起。組長扮演促成者的工作，幫助我們稽核完成的文檔内容，保證項目的順利進行。
3.4 創造階段
我們團隊順利地到達了創作階段。在alpha沖刺和beta沖刺階段即進入了創造階段。大家都很有目标地去完成團隊項目任務，所要做的工作也較為明确。組員之間溝通默契，遇到問題也能互相協商解決，越來越熟悉。每天的工作不需要組長的監督就能自覺地完成。自己分内的工作完成後還能去幫助别人做一些力所能及的部分。這也就促成了我們團隊項目成功落地的結果。
三、人月神話
1. 團隊
1.1 研發出符合使用者需求的軟體
我們團隊的産品在成功落地後有公開釋出出去讓其他同學也就是潛在使用者試用，并且制作了問卷收集大家的意見和建議。
使用者調查報告
在決定做這個項目之前，我們有讨論過選題。當時剛好是疫情肆虐期間，大家所有的學習和工作都是線上上完成的，是以我們組決定開發一個可以實時跟進成員進度的線上辦公團隊協作的産品。是符合大多數在職在學使用者需求的軟體。是以隻要能持續開發，前景是很不錯的。
1.2 通過一系列工具，流程，團隊合作，能夠在預計的時間内釋出 “足夠好” 的軟體
我們團隊有項目規劃/需求/設計/實作/釋出/維護，有定時的進度釋出。
首先是項目開發的總體時間安排
我們團隊使用tb來作為管理成員進度的工具。可以很好地給成員配置設定任務并且形成最後的燃盡圖。
(1) 項目規劃
2020年突如其來疫情使手機，網際網路在生活工作中成為了我們最重要的東西。在這樣的大環境下，線上工作的重要性尤為突出。是以，我們組提出的線上協作辦公的解決方案，緻力于為使用者營造便捷舒适的線上辦公體驗。
功能預設
其他子產品預設
(2) 需求分析
需求規格說明書
(3) 設計
類圖設計
E-R圖設計&資料表設計
使用者表設計
詳細設計部分包括系統設計與資料庫設計都在這篇部落格中項目系統設計與資料庫設計
(4) 實作
整體開發實作部分分為alpha和beta沖刺。
alpha階段時間安排
| 時間區間 | 任務内容 |
|---|---|
| 4.27 | 進行項目環境配置、項目啟動會議 |
| 4.27-4.30 | 各子產品功能工作初期 |
| 4.30-5.3 | 各子產品任務大體完成，有基本功能實作 |
| 5.4-5.6 | 功能子產品優化、深入測試 |
十天沖刺實作的部落格合集：alpha沖刺部落格彙總
beta階段時間安排
| 時間 | 任務 |
|---|---|
| 沖刺前——5.27 | 負責前端學習知識，後端設計新的接口，修複bug，并發測試準備，新舊成員交接 |
| 5.28 | 前端完善個人資料上傳，後端完成檔案子產品接口 |
| 5.29 | 後端動态子產品，前端日程互動細節 |
| 5.30 | 後端完善提醒子產品，前端動态檢視子產品互動 |
| 5.31 | 後端完善群聊接口，前端完成檔案子產品 |
| 6.1 | 後端繼續完成群聊子產品，前端完成細節互動優化 |
| 6.2 | 功能測試，軟體安全性提升 |
| 6.3 | 界面優化，代碼審查 |
七天沖刺實作的部落格合集：beta沖刺彙總
每天的沖刺都會有每個成員的任務進度彙總，有實時的任務跟進，每天也有燃盡圖。可以證明我們的項目是在一步步慢慢推進的，有規律有計劃。
(5) 釋出
項目連結：17
問卷連結：問卷
登陸賬号：[email protected]
密碼：123456（自己注冊也行）
1.3 通過資料展現軟體是可以維護和繼續發展的
我們的實作都是基于github平台彙總代碼，每次都有标明意義的送出，可以友善後續維護和修改。可複用性也很高。所需要的項目有關的邊角分析文檔以及設計文檔都有儲存。
我們也有釋出代碼規範，對于之後若有修改維護的部分則很有利，也友善新加入的成員讀懂我們的代碼。
代碼規範
2. 個人
2.1 個人實踐
個人實踐基本都是以部落格為主的總結測評或者自我定位，隻有一次程式設計項目是個人完成的，其餘都是組隊。個人實踐相對來說時間安排比較自由，可以自己按照每天的實際情況安排工作，缺點就是自己要統管所有，耗費精力。
經驗總結：部落格類的撰寫越早開始越好，除了要總結的部落格隻能等到所有工作結束後才能開始撰寫。部落格的内容要求一般都比較廣泛，類型條目要求明确細緻，越早開始，可以為後來的補充細節空出時間。部落格的撰寫不比程式設計省力，他需要較強的概括能力和表達能力，讓别人看得懂是關鍵。首先明确部落格内容點的順序，再往裡填充。我一般是在寫A部分的時候，B部分的内容突然靈光乍現，就跳轉到去寫B，這樣部落格的内容會更加豐富，時刻地補充。有些部落格的要求内容一時沒有想法，那就跳過，總會有靈感的時候。
2.2 結對
結對作業概括來說是做的疫情可視化的網頁。
經驗總結：第一次結對作業隻做了原型，是以界面設計地不是很美觀，以為并不會實作。而第二次要求實作原型，按照原有原型去做，用代碼顯示出來，隻會更難看。這裡我就不得不說有一個好用的前端架構Vue是多麼重要了。當時的我隻是一個埋頭苦幹的純手工編寫了幾百行html代碼的人，又醜又費力，類似這樣：
看到這我也忍不了自己。
還有一個經驗就是，多去看看設計網頁排版的資料，别讓美好的想法隻存在于腦子裡了。
2.3 團隊合作
這是我第一次和團隊一起開發一個真正能使用的項目。說起來當初對這個項目的未來又恐懼又興奮。
經驗總結：
(1) 千萬要在每次工作前分好工
有很多次項目任務小的細節是被忽略的。每次的分工隻針對于大子產品的開發，但對于一些不知道該誰負責的“中性地帶”最後收工稽核的時候就可能引發沖突。
(2) html+css和js是不可分割的
在alpha沖刺階段，我們前端一共三個人，分工類似于這種：
html+css和js是分開完成的。這樣安排的原因是有同學對于Vue的js互動掌握還不夠，這就不得不将js攬到一個同學的身上，但這種安排在alpha的後期階段得到了慘痛的結果。前端壓力不均。要想修改不同隊友的代碼并且為其合并js是很難的，因為每個子產品的邏輯都不相同，資料要求顯示的位置不同。是以在beta階段我們改成每人都負責幾個完整的子產品，将html+css+js完美的融合，大大提高了效率。
(3) 不恥下問
我作為Vue的初學者，經常被一些簡單問題糾結幾個小時甚至一天，百度上資訊繁雜很難找到對口的問題，是以積極性被打擊。後來慢慢在群裡詢問同學，找到解決的辦法。一個活生生的人要比冷冰冰的度娘好太多了。代碼的效率也變得很高。
(4) 圖示文字同行對齊（界面細節問題）
我們的項目中有很多處都需要将圖示和文字對齊，這是個細節問題，但是确實很難控制得很好。例如：
我剛開始的時候是并沒有對齊的，但是自己也沒有意識到，是靠同組隊友的提醒才發現這樣确實影響美觀：
上網去查找更加細節的對其方式，然後發現vertical-align屬性設定元素的垂直對齊方式，該屬性定義行内元素的基線相對于該元素所在行的基線的垂直對齊。作為類似情況的細節調節簡直太合适了。調整好所有對其問題，整個界面果然美觀了很多，細節問題對于前端來說最容易忽略但也起關鍵性的作用。
四、 建議
1. 軟工實踐
軟工實踐課程一學期以來的任務安排都是有不同的循序漸進的任務目的的。作業的安排上我并沒有什麼具體的建議，因為已經足夠專業。但是我想建議一下在作業中期的團隊第二次作業實戰前，就是類似于這樣高強度短時間的作業，可以提前預告一下，不然真的太突然了。這算是團隊的第一次合作，容易打擊大家的自信心還可能造成隊友間的沖突。
2. 助教工作
本學期我們班上的助教都很負責，都有認真看每個同學的部落格，關注每個團隊的進度。助教也有随時提醒大家的作業進度，展示大家的成績評分。對于助教工作來說，我沒有什麼建議，因為助教做得工作真的很好，一些想象不到的細節助教也做得很好。
3. 自己今後
我給自己的建議就是要提高自己的抗壓能力。這幾次作業已經很仁慈了，但是我總給自己一些莫須有的壓力，讓自己變得很累，很怕每次新作業的布置。在未來的工作中壓力肯定會更大，是以希望自己既然能很好地按時完成任務，就不要再想東想西地産生心理包袱了。還有一個建議是希望自己能不怕不被回複的尴尬，主動地提出一些不一樣的建議，自信一點啊。相信所有任務自己都能完成就可以了。還有就是不要懶惰，積極學習，要會笨鳥先飛。
4. 下一屆同學
不要被軟工實踐的作業概況吓退！雖然我一開始接觸這個課程的時候很害怕，但是慢慢來，一步步做起來還是不可怕的。你們可能會遇到各種沒見過沒學過的知識，但是循序漸進地學，總會完成的。團隊組隊的時候一定要慎重，選擇自己熟悉的同學會少去很多時間。如果認真地完成每一次作業，最後肯定會有收獲的，别在中途放棄，這一路确實很累。
五、 個人技術總結
Vue前後端資料互動與顯示
概述：将後端所計算的資料呈現在前端頁面的相應位置并根據使用者點選操作改變相應的資料和界面，再傳值給後端。該技術是Web開發必備，是前後端互動的紐帶。難點在于擷取後端資料并且防止資料關聯。
六、 閱讀筆記
參考論文文獻：
[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605
文獻連結
文獻中主要講述軟體品質的評測和重要性。在這一方面我是很欠缺的。每次我僅僅将關注點放在完成項目上，即軟體跑起來了就行，不出錯就好。但對于軟體産品的品質監控是一片空白。也有一個原因是在我短暫的學習中，真正做出長久被使用的軟體，并為此優化性能的情況為零。是以我想為完整的工程思想增添一些新的知識。
- Preparing the quality specifications for a software product. Formulating what functions you need and how much performance (speed, accuracy) you need are fairly straightforward. Indicating that you also need to maintain ability or understandability is important, but much more difficult to formulate in some testable fashion.
- Checking for compliance with quality specifications. This is essential if the quality specifications are to be meaningful. It can clearly be done with a large investment of good people, but this sort of checking is both expensive and hard on people 'S morale.
- Making proper design trade-offs between development costs and operational costs. This is especially important because tight development budgets or schedules cause projects to skimp on maintainability, portability, and usability.
Software package selection. Here again, many users need a relative
assessment of how easily each package can be adapted to their installation's changing needs and hardware base.
首先在産品開發前就要為産品準備品質規範，制定需要的功能以及需要多少性能(速度、準确性)。性能作為一個廣泛的概念，它與計算機的硬體條件、軟體記憶體、不同使用的時間、使用的時長都有關系。我往往以定性來制定性能要求，但是良好的軟體品質要求定量性能标準。并且，軟體産品的所需品質随潛在使用者的需求和優先級而不同。是以，沒有一個單一的度量能夠對軟體品質進行普遍有用的評級。在最好的情況下，一個潛在的使用者可以得到一個有用的評級，為品質評級系統提供了一套全面的核對表和優先次序。即便如此，由于這些名額并不是詳盡無遺的，是以此時度量的最佳使用是作為單獨的名額，作為軟體開發、測試計劃、維護的指南。
文獻中提到一次實驗，在兩個計算機程式控制實驗中的應用(大約400個FORTRAN語句)獨立編寫成相同的規格說明。此外，兩者在品質重點方面存在故意差異。一個是由一個要求提高代碼效率的程式員完成，另一個則是由一個被要求程式設計簡單的程式員完成。結果在追求效率的“程式”中檢測到的錯誤是原來的十倍(超過1000次測試運作的相同系列)。在簡單的程式上，程式品質的測量值明顯較高，是以，穩定的代碼是相對操作可靠性的良好名額。追求高速軟體的同時有可能喪失最基本的軟體品質的要求。
檢查是否符合品質規範。如果品質規格是有意義的，這是必不可少的。我還沒有接觸過品質規範的編寫，這也是我想去學習的一部分，作為一個有當産品經理夢想的人來說，軟體品質的實時監管與敲定是必備的基礎知識，是以這篇文獻可以給日後的學習帶來便利（順便學英語了）。
在開發成本和營運成本之間進行适當的設計權衡。否則會使得軟體在可維護性、可移植性和可用性方面有所欠缺。我在現今的學習中，還都是零開發成本，因為做的東西比較低端，還沒有考慮過開發成本營運成本的問題。但是對于可維護性可用性來說，我還是略有感觸，比如本次項目需要運作在穩定的伺服器上，而我們組内大多數都是小白，伺服器成本為零的情況下隻能挂接在幾個同學的伺服器上，速度不太樂觀。是以充裕的成本預算也成就了良好的軟體品質。
軟體度量的選取：
- Define a set of characteristics that are important for software, and reasonably exhaustive and non-overlapping.
- Develop candidate metrics for assessing the degree to which the software has the defined characteristic.
- Investigate the characteristics and associated metrics to determine their correlation with software quality, magnitude of potential benefits of using, quantifiability, and ease of automation.
- Evaluate each candidate metric with respect to the above criteria, and with respect to its interactions with other metrics: overlaps, dependencies, shortcomings, etc.
- Based on these evaluations, refine the set of software characteristics into a set that is more mutually exclusive and exhaustive and supportive of software quality evaluation.
- Refine the candidate metrics and realign them in the context of the revised set of characteristics.
根據不同軟體品質特征的識别和選取，建立一個層次特征集和一組異常檢測名額。這就是軟體品質評估開始的基礎。