1500802034呂占英

一.回想開(kāi)學(xué)初對(duì)于軟件工程這門(mén)課的期望，總結(jié)本課程對(duì)你帶來(lái)的提升：

1.團(tuán)隊(duì)名稱(chēng)

風(fēng)啟團(tuán)隊(duì)

2.項(xiàng)目名稱(chēng)

寢室分配管理系統(tǒng)

3.學(xué)習(xí)和使用的新平臺(tái)

學(xué)習(xí)了基本的APIcloud手機(jī)APP開(kāi)發(fā)平臺(tái)相關(guān)內(nèi)容，利用APIcloud平臺(tái)完成項(xiàng)目
APIcloud進(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)

4.學(xué)習(xí)和使用的新工具

mockplus原型設(shè)計(jì)工具，設(shè)計(jì)項(xiàng)目原型。
Enterprise Architect類(lèi)圖，用例圖。
coding 遠(yuǎn)程代碼倉(cāng)庫(kù)。

5.學(xué)習(xí)和使用的新語(yǔ)言

css語(yǔ)言
HTML語(yǔ)言
JavaScript語(yǔ)言

6.學(xué)習(xí)和掌握的新方法

MarkDown的排版方法

7.完成的代碼量

因?yàn)槲邑?fù)責(zé)的是數(shù)據(jù)庫(kù)發(fā)方面的，所以代碼量大約100行。

二.總結(jié)與展望

1.經(jīng)驗(yàn)總結(jié)

軟件工程這門(mén)課程對(duì)我來(lái)說(shuō)還是很難學(xué)習(xí)的，因?yàn)橛泻芏嘀R(shí)我不會(huì)，學(xué)到些不能夠很好的應(yīng)用。
在這次團(tuán)隊(duì)合作項(xiàng)目的過(guò)程中我明白了很多東西只有團(tuán)隊(duì)一起努力才能更好的完成。

2.對(duì)學(xué)弟學(xué)妹的建議和告知

學(xué)習(xí)每一門(mén)課程都會(huì)接觸很多新東西，對(duì)于新的知識(shí)要努力學(xué)習(xí)并掌握。
認(rèn)真完成老師布置的作業(yè)，不懂得問(wèn)題要多向老師提問(wèn)以提升自己的編程能力。
好好學(xué)習(xí)專(zhuān)業(yè)課知識(shí)，平時(shí)有時(shí)間多學(xué)多問(wèn)。
要注意團(tuán)隊(duì)成員間的合作，有想法和問(wèn)題要及時(shí)討論，多溝通。

3.對(duì)自己團(tuán)隊(duì)的分析

萌芽階段：成員組隊(duì)，初步討論要做的項(xiàng)目
磨合階段：確定要一起合作完成的項(xiàng)目，分工進(jìn)行資料的查詢(xún)
規(guī)范階段：小組之間一起討論，分工，確定要個(gè)人完成的部分
創(chuàng)造階段：通過(guò)自己的學(xué)習(xí)，完成小組組長(zhǎng)分配的任務(wù)并一起整合，最終完成整個(gè)項(xiàng)目的制作

4.個(gè)人發(fā)揮

團(tuán)隊(duì)合作的項(xiàng)目，成員之間的合作溝通才是最重要的

三、對(duì)第一次軟件工程作業(yè)中的五個(gè)問(wèn)題重新回答

1.課本的第六章敏捷流程105頁(yè)提到敏捷流程，它的開(kāi)發(fā)理念我經(jīng)過(guò)查找資料得到：

（1）個(gè)體和溝通勝過(guò)實(shí)施過(guò)程和工具；
（2）可以工作的軟件勝過(guò)面面俱到的文檔；
（3）客戶(hù)合作勝過(guò)合同與談判；
（4）響應(yīng)變化勝過(guò)遵循計(jì)劃。

2.2.課本的第十章第207頁(yè)提到功能驅(qū)動(dòng)設(shè)計(jì)，只寫(xiě)了怎樣分步構(gòu)成，可到底什么才是驅(qū)動(dòng)功能的設(shè)計(jì)呢？

驅(qū)動(dòng)功能的設(shè)計(jì)（FDD）是一種模型驅(qū)動(dòng)開(kāi)發(fā)的軟件過(guò)程，和XP一樣是敏捷軟件開(kāi)發(fā)方法的一種。FDD的主要思想是對(duì)功能的實(shí)現(xiàn)，也就是說(shuō)FDD是以實(shí)現(xiàn)功能為目標(biāo)。把系統(tǒng)分解成一個(gè)一個(gè)的功能集，每個(gè)功能集又習(xí)細(xì)分為具體的功能。是移動(dòng)通信系統(tǒng)中使用的全雙工通信技術(shù)的一種，與TDD相對(duì)應(yīng)。FDD采用兩個(gè)獨(dú)立的信道分別進(jìn)行向下傳送和向上傳送信息的技術(shù)。為了防止鄰近的發(fā)射機(jī)和接收機(jī)之間產(chǎn)生相互干擾，在兩個(gè)信道之間存在一個(gè)保護(hù)頻段。比如說(shuō)用戶(hù)管理是個(gè)功能集，而用戶(hù)管理又包括了增加用戶(hù)、刪除用戶(hù)等具體的功能。域建模是其系統(tǒng)設(shè)計(jì)的方法，用到的是color uml，也就是常說(shuō)的四色原型，在項(xiàng)目設(shè)計(jì)過(guò)程中回有很大的作用。

3.課本第93頁(yè)提到瀑布模型，什么才是瀑布模型，有沒(méi)有缺點(diǎn)？

經(jīng)過(guò)查詢(xún)資料，我知道了瀑布模型是將軟件生存周期的各項(xiàng)活動(dòng)規(guī)定為按固定順序而連接的若干階段工作，形如瀑布流水，最終得到軟件產(chǎn)品。瀑布模型核心思想是按工序?qū)?wèn)題化簡(jiǎn)，將功能的實(shí)現(xiàn)與設(shè)計(jì)分開(kāi)，便于分工協(xié)作，即采用結(jié)構(gòu)化的分析與設(shè)計(jì)方法將邏輯實(shí)現(xiàn)與物理實(shí)現(xiàn)分開(kāi)。將軟件生命周期劃分為制定計(jì)劃、需求分析、軟件設(shè)計(jì)、程序編寫(xiě)、軟件測(cè)試和運(yùn)行維護(hù)等六個(gè)基本活動(dòng)，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級(jí)下落。但是他也有缺點(diǎn)，因?yàn)楦鱾€(gè)階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，會(huì)極大地增加工作量；而且由于開(kāi)發(fā)模型是線(xiàn)性的，用戶(hù)只有等到整個(gè)過(guò)程的末期才能見(jiàn)到開(kāi)發(fā)成果，從而增加了開(kāi)發(fā)風(fēng)險(xiǎn)，雖然缺點(diǎn)是有，但還是一個(gè)很強(qiáng)的模型。除了這些，他還有許多歐典，每次當(dāng)前一階段完成后，只需要去關(guān)注后續(xù)階段，而且可以在迭代模型中應(yīng)用瀑布模型。增量迭代應(yīng)用于瀑布模型。迭代1解決最大的問(wèn)題。每次迭代產(chǎn)生一個(gè)可運(yùn)行的版本,同時(shí)增加更多的功能，每次迭代必須經(jīng)過(guò)質(zhì)量和集成測(cè)試；它還提供了一個(gè)模板，這個(gè)模板使得分析、設(shè)計(jì)、編碼、測(cè)試和支持的方法可以在該模板下有一個(gè)共同的指導(dǎo)，有了這些作用，就能更好的運(yùn)用瀑布模型。

4.課本第十三章軟件測(cè)試中提到黑箱測(cè)試的方法有哪些：

等價(jià)類(lèi)劃分、邊界值分析、錯(cuò)誤推測(cè)、因果圖和綜合策略，其中因果圖測(cè)試用例的基本步驟：
⑴ 分析軟件規(guī)格說(shuō)明描述中，那些是原因（即輸入條件或輸入條件的等價(jià)類(lèi)），那些是結(jié)果（即輸出條件），并給每個(gè)原因和結(jié)果賦予一個(gè)標(biāo)識(shí)符.
⑵ 分析軟件規(guī)格說(shuō)明描述中的語(yǔ)義.找出原因與結(jié)果之間，原因與原因之間對(duì)應(yīng)的關(guān)系. 根據(jù)這些關(guān)系，畫(huà)出因果圖.
⑶ 由于語(yǔ)法或環(huán)境限制，有些原因與原因之間，原因與結(jié)果之間的組合情況不不可能出現(xiàn). 為表明這些特殊情況，在因果圖上用一些記號(hào)表明約束或限制條件.
⑷ 把因果圖轉(zhuǎn)換為判定表.
⑸ 把判定表的每一列拿出來(lái)作為依據(jù)，設(shè)計(jì)測(cè)試用例.

5.課本第一章13頁(yè)提到冒煙測(cè)試，那么什么是冒煙測(cè)試呢：

對(duì)一個(gè)硬件或硬件組件進(jìn)行更改或修復(fù)后，直接給設(shè)備加電。如果沒(méi)有冒煙，則該組件就通過(guò)了測(cè)試。在軟件中，“冒煙測(cè)試”這一術(shù)語(yǔ)描述的是在將代碼更改嵌入到產(chǎn)品的源樹(shù)中之前對(duì)這些更改進(jìn)行驗(yàn)證的過(guò)程。在檢查了代碼后，冒煙測(cè)試是確定和修復(fù)軟件缺陷的最經(jīng)濟(jì)有效的方法。冒煙測(cè)試設(shè)計(jì)用于確認(rèn)代碼中的更改會(huì)按預(yù)期運(yùn)行，且不會(huì)破壞整個(gè)版本的穩(wěn)定性。冒煙測(cè)試是微軟首先提出來(lái)的一個(gè)概念,與微軟一直提倡的每日構(gòu)建有很密切的關(guān)系.具體地說(shuō),冒煙測(cè)試就是在每日構(gòu)建之后,對(duì)系統(tǒng)的基本功能時(shí)行簡(jiǎn)單的測(cè)試,冒煙測(cè)試這個(gè)名稱(chēng)的來(lái)歷,大概是從電路板測(cè)試得來(lái)的,因?yàn)楫?dāng)電路板做好以后,首先會(huì)加電測(cè)試,如果板子沒(méi)有冒煙則進(jìn)行其他測(cè)試,否則電路板冒煙了,則證明電路板有重大缺陷需要重新設(shè)計(jì)和開(kāi)發(fā).在軟件開(kāi)發(fā)中,冒煙測(cè)試的對(duì)象 是每一個(gè)新編譯的需要正式測(cè)試的軟件版本,目的是確認(rèn)軟件基本功能正常,可以進(jìn)行后續(xù)的正式測(cè)試工作.在持續(xù)集成的開(kāi)發(fā)環(huán)境下,每天都會(huì)生成很多可用的Build,但是并不是每個(gè)Build都會(huì)送到測(cè)試人員或者客戶(hù)去測(cè)試,以確認(rèn)系統(tǒng)的基本功能.冒煙測(cè)試可以避免重要的嚴(yán)重錯(cuò)誤被傳送到測(cè)試人員或者客戶(hù)手中,以免造成時(shí)間浪費(fèi)和可能的不良印象.