2.psp**
personal software process stages
預估耗時（分鐘）
實際耗時（分鐘）
計畫10
15需求分析55
具體設計
2025
具體編碼
120180
**複審
1030
測試30
40總結105
合計200
3003.計算模組介面的設計與實現過程：
思考了這個程式，我們先寫了乙個**框架，定義了乙個類（s），這個類裡面包含了**的核心演算法。裡面寫了三個函式框架，分別為統計檔案單詞總數的countwords函式，統計檔案有效行數的countlines函式，還有統計檔案中各個單詞的出現次數的counttimes函式。然後在主函式中定義介面s依次呼叫這些函式。
下面是**執行效果圖
4.**複審：
在**的複審過程中，我們發現對方的**有許多地方是不易理解的，對**變數的注釋都不夠，導致需要向對方詢問才能知道**的意思，還有執行過程中也缺少了提示性語言。通過協商，我們做了一些改進。在**的格式方面，雙方都還是很默契，按照之前約定的**規範做得很好。
5.計算模組介面部分的效能改進：
為了提公升計算模組的效能，我們採用了正規表示式的方法提取文字檔案，以下是效能分析圖
6.計算模組部分單元測試展示：
在單元測試中，我們設計的**開啟了另乙個比較小的文字檔案，更準確地得到了該文字的資料，用來測試函式正確性，下圖包含了部分測試**。
7.計算模組部分異常處理說明：
這裡設計了乙個異常測試，將測試標準從314修改為了100，導致演算法得到的資料與給出的標準資料不一致，造成了測試失敗。
8.描述結對的過程
一起程式設計的**
在這次結對程式設計中，我給出了**的大致框架，然後劉方俊主要負責完成了各個函式的具體演算法編寫，以及完成模組介面的連線，然後組裝好**，由我進行了**複審和單元測試。
9.**的提交
10.總結
通過這次結對程式設計，我體驗到了兩人一起程式設計的樂趣，體會到了編寫**新的方式，學到了與他人配合的方法，從乙個人編碼變成了與他人配合，這個過程需要的不僅僅是編碼只是，還有團隊協作配合。一開始兩人的配合也不默契，這是因為知識點的不同造成的，例如關於正規表示式的只是我就不了解，在隊友的協助下才勉強看懂了，這也提醒了我學習各方面知識的重要性，不能在團隊中成為拖後腿的那個人。
第三次作業
2 12有600 mb 兆位元組 的資料，需要從南京傳送到北京。一種方法是將資料寫到磁碟上，然後託人乘火車這 些磁碟捎去。另一種方法是用計算機通過長途 線路 設資訊傳送的速率為2.4kb s 傳送此資料。試比較這兩種方法的優劣。若資訊傳送速率為33.6kb s,其結果又如何？解 當傳送速率為2.4k...
第三次作業
1 有600mb 兆位元組 的資料，需要從南京傳送到北京 一種方法是將資料寫到磁碟上，然後託人乘火車將這些磁碟捎去。另一種方法是用計算機通過長途 線路 設資訊傳送的速率為2.4kb s 傳送此資料，試比較這兩種方法的優劣。若資訊傳送的速率為33.6kb s,其結果又如何？解 假定連續傳送且不出錯。若...
第三次作業
p67 2 12 有600mb的資料，需要從南京傳送到北京。一種方法是將資料寫到磁碟上，然後託人乘火車將這些磁碟捎去。另一種方法是用計算機通過長途 線路 設資訊傳送的速率是2.4kbps 傳送此資料。試比較這兩種方法的優劣。若資訊傳送速率為33.6kbps，其結果又如何？解 1 t 600 1024...