軟體工程 事後Postmortem 會議

2022-06-23 22:51:11 字數 1961 閱讀 1812

團隊事後分析會議

會議截圖

設想和目標

1.我們所設計的作品要解決的要求?典型使用者和典型場景?

想要解決當代大學生社團以及交友問題。

典型使用者:在校大學生

典型場景:社團交流、社團招新

2.與之前我們的個人作業和結對作業相比,有什麼進步?

文件寫得更多,技術上的進步,團隊交流以及互相推鍋的能力

3.設計的目標有沒有達到?如果沒有達到,具體原因是什麼?

一開始的目標有偏差,由最初的聊天系統偏離到社團管理,**量過多導致不能按期完成。

預期目標過於龐大,我們的目標整個完成就相當於兩個作品的**量。

前端技術問題也導致了目標沒有完美實現。

計畫1. 是否有充足的時間來做計畫?  

計畫時間充足,但是學習技術時間相對較少。

2. 團隊在計畫階段是如何解決同事們對於計畫的不同意見的?

進行少量討論之後達成共識,但還是缺少更多的商討時間。

3. 原計畫的工作是否最後都做完了? 如果有沒做完的,為什麼?

前端:沒有做完,由於技術問題

後台:完成

測試:完成

發布:完成

4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

5. 是否每一項任務都有清楚定義和衡量的交付件?

實現介面定義之後交付給後台進行連線。

6. 是否專案的整個過程都按照計畫進行,專案出了什麼意外?有什麼風險是當時沒有估計到的,為什麼沒有估計到?

幾乎沒有風險,最主要的就是併發量,沒有對作品進行壓力測試(其實主要是伺服器端的壓力測試)。

由於最初的估計使用者數量比較低,沒有想到這一點。

還有可以通過直接修改位址列中使用者名稱,會直接使用其他的使用者名稱切換使用者。

資源1. 我們有足夠的資源來完成各項任務麼?

有。2. 各項任務所需的時間和其他資源是如何估計的,精度如何?

根據自己之前打**的經驗估計,精度有誤差但在接受的範圍內。

3. 測試的時間,人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度? 

測試資源、人力、時間足夠。

剛開始上手會覺得很簡單,隨著時間會逐漸覺得變難。剛開始覺得前端就只是設計一下樣式,結果後來發現還有與後台對接以及邏輯指令碼設計等,就比較棘手。

4. 你有沒有感到你做的事情可以讓別人來做(更有效率)?

發布:覺得自己的部分並沒有安排很好,因為演示的書序比較靠前,有些緊張還沒有準備好演示內容。

設計/實現

1. 設計工作在什麼時候,由誰來完成的?是合適的時間,合適的人麼?

在編寫規格書之前,由前端與後台一起進行設計。

時間上來說,有一些緊張,因為任務拖到了還剩兩三天。

人選是很合適的,由實現人員作為主導,更容易完成。

2. 設計工作有沒有碰到模稜兩可的情況,團隊是如何解決的?

沒有,意見幾乎一致。

測試/發布

1.是否進行了正式的驗收測試?

測試涵蓋了作品的大部分功能,但是由於對程式語言的不熟悉導致不夠深入。

2.發布過程中遇到的問題?

團隊角色管理/合作

1.影響進度和作品完成度最大的原因?

技術問題,很嚴重。

2.隊長是否起到了積極作用?

有起到積極作用。

3.在完成相關任務的時候,有沒有與其他隊員進行協調?

有,但團隊內部交流不夠。

4.團隊內部氛圍?

雖然我們整體技術不強,但是團隊內部互幫互助還是很強的。

團隊內部貢獻分規則

團隊貢獻分

姓名貢獻分

尚通93.5

孫爭80

李彥霆77

王卓75.5

賴學程47.5

廖浩任44

專案複審請見:

軟體工程 軟體工程概述

一.軟體 定義 計算機系統中的程式及其文件 程式 計算任務的處理物件和處理規則的描述 文件 為了便於了解程式所需的闡明性資料 特點 軟體的種類 按功能劃分 系統軟體 支援軟體 應用軟體 二.軟體工程的起源和概念 早期電腦程式 現在人們認為 在資訊產業中,微電子是基礎,計算機和網路是載體,軟體是核心 ...

軟體工程 軟體工程的概述

軟體工程是研究和應用如何以系統性的 規範化的 可定量的過程化方法去開發和維護軟體,以及如何把經過時間考 驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的學科,它涉及到程式語言 資料庫 軟體 開發工具 系統平台 標準 設計模式等方面。先從軟體工程的第一章開始說起 軟體工程的概述,這一章是...

軟體工程之軟體工程管理

乙個好的工程需要配套的管理體系,軟體工程也不列外。軟體工程就我的理解就是對軟體工程的各個階段都一定規範,俗話說 不以規矩,不能成方圓 而這個規矩就由管理來充當。乙個軟體工程管理需要軟體專案計畫 成本估算 進度計畫 風險分析和人員的組織形式 或調動 一 在軟體專案計畫中,專案的任務是研究專案的效能 功...