軟工大做業·傾物語（一）

文章來源：中國軟工亞洲指揮中心（Steins;Gate）
共同做者：紀神，爵爺，老闆，小男孩（按首字拼音排序）
責任編輯：爵爺

    本週六咱們進行了一整個下午的詳盡討論，圍繞如下幾點進行了細緻的分析，而且有了比較明晰的結論。

    一、APP的名字。這是最先被提出的問題，但也多是（不僅是一個笨手笨腳的大做業，對於全部的項目都是）最難的一個問題之一。這幾乎不涉及技術問題，而是須要外對於總體產品和用戶市場、內對於項目定位的一個精準的把控。

    因爲條件的限制，咱們並不能在這一點上花費太多的時間，咱們認爲基於咱們實際狀況的最佳的名字應該可以同時反映信息收集 + （基於共同關注點的）社交這兩點，在頭腦風暴中，咱們想了不少正兒八經以及奇奇怪怪的名字。

• 信息人大
• 校園風
• 三人行
• 校園通
• 圈裏信息
• 校園知事
• ······

    最終咱們比較中意的是「校園知事」，它知足了咱們提出的兩點基本要求，而且發音同「芝士」也讓人多少有些親切感（→_→ Fate第十職階Eater）。暫定這個名字，只有有更好的想法再進行修改。

    二、 關於《需求規格說明書》以及《可行性分析報告》。在定下了基本的思路與設計以後咱們開始着手書面材料。第一步要作的就是《需求規格說明書》以及《可行性分析報告》。在《需求規格說明書》中咱們將按照課件上的標準進行編寫，而且對成員進行了分工，具體分工以下：

• 第一部分：系統規格說明：小男孩。內容包括系統概貌、功能要求、性能要求、運行要求、可能增長的要求、DFD、IPO
• 第二部分：數據要求：紀神。內容包括DD、Hierarchy或Warnier Diaggram
• 第三部分：用戶系統描述：爵爺。內容包括初步用戶手冊：從用戶的觀點考慮系統，系統功能、性能 、使用與步驟
• 第四部分：修正的開發計劃：老闆。 內容包括成本估計 ，資源使用計劃 ，進度計劃等。

    在《可行性分析報告》上，若是按照業界正式工程的格式來作的話會很是繁冗，而且其中涉及的市場背景、政策背景、法律背景以及資金鍊等對於咱們目前來講有些不切實際，因此咱們對於《可行性分析報告的規格》的格式進行了適應性調整。主要分爲六個部分：

• 1）背景瞭解以及基於問卷調查的需求分析；
• 2）對市場現有的產品進行分析對比；
• 3）咱們知足這個需求的思路想法；
• 4）技術層面上實現咱們的思路想法；
• 5）產品的測試和維護；
• 6）產品的推廣和運營。

    《可行性分析報告》將於《需求規格說明書》以後完成，屆時將根據狀況進行調整。預計最晚於下週末完成《需求規格說明書》和《可行性分析報告》這兩份書面材料。

    三、關於微人大權限以及各院API接口。由於涉及人大身份（目前APP只覆蓋人大範圍）驗證問題，咱們須要微人大的開發者權限，而且在信息收集這方面若是能直接拿到各個學院的新聞API豈不美哉[王司徒臉]。

    在微人大權限上，咱們在微人大上申請了開發者帳號，系統說7日以內會給回覆，然而兩個七日過去了······再等等，再催催好了，另外關於微人大的討論中又催生出了一個問題：登陸模式。是直接採用微人大帳號登陸仍是新註冊帳號登陸，再於APP中進行人大身份驗證（就像進入APP後再進行郵箱驗證同樣）。通過討論咱們認爲，若是使用微人大帳號登陸雖然直接方便，可是給人一種官方死板的氣息（不吹不黑），且不利於以後用戶羣體的擴展（怎麼能佔領清華北大呢）；使用獨立帳號註冊 + 後期驗證的方式雖然多了一步流程，可是讓人感受不受束縛（這種感受很難描述），而且可讓用戶先體驗一部分功能，並有利於以後對清華北大的佔領工做。

    在各院新聞API獲取這方面，咱們以儘量誠懇的語氣向30多個學院發送了郵件，分析了雙贏新性並詢問是否能拿到新聞的接口，但截至目前沒有任何學院給予回覆（其實也難怪，人大黃頁上找到的郵箱地址有好幾個格式都是錯的，還有幾個要麼沒這個主機要麼沒這個用戶）。咱們並不許備就以上的經從來分析辦事效率問題，由於極可能是咱們的方法出了問題。目前看來用爬蟲抓新聞是比較可行的選擇，現階段沒法預料在爬蟲部分將遇到的問題，咱們將於下週寫一份爬蟲的demo，並鏈接LeanCloud進行測試。

    四、作最小化原型的詳細功能設計以及簡略的UI。這兩部分是結合在一塊兒作的，在簡要功能的討論中畫出了主要的UI。咱們不在這裏貼出討論過程當中的草圖，以後咱們會用原型設計軟件從新把圖畫一遍再發布。主要的界面就是新聞消息、 好友、發現（與本身關注點相同的人，瞭解本身最近的關注點或者查看本身的時間軸等等）以及更多（我的信息以及應用設置等）。雖然這是相當重要的一點，可是咱們認爲於」空想階段「在這上面花費太多的時間不太合適，應該結合最小化原型設計出一個簡略的功能框架，而後在作的過程當中踩坑。

    五、進度安排。在這點上咱們一樣沒法作出細緻的估計，由於涉及公關處理、策略轉型或團隊配合等方方面面的問題，咱們只是作了一個大階段的預期。

• 四月份：初版開發與測試
• 五月份：初版集中測試，第二版開發與測試
• 六月份：第二版集中測試，產品推廣

    整體來講咱們目前的進度是能夠接受的，在初版的開發過程當中必定會遇到很是多的問題，並且這些問題中有些將超出咱們的預期與能力（即所謂的」坑「），咱們會翔實地把這個過程當中的心得體會記錄下來，做爲以後的一個寶貴的參考。