軟體設計實習報告
實習之後我們需要寫相關的實習報告，大家一起看看下面的軟體設計實習報告，歡迎各位閱讀哦！
軟體設計實習報告
一、實習目的：
檢驗與鞏固理論知識，提高實際操作能力與社會實踐能力。
二、實習時間：
20xx-07-27 至 20xx-10-23
三、實習地點：
廣東廣州
四、實習單位與部門：
廣州**網路科技有限公司·軟體開發部
五、實習內容：
應學校要求，本人於七月二十七號來到廣州**網路科技有限公司實習。初到該公司，聽公司負責人講解了公司狀況以及工作要求，就馬上開始我的工作。從該負責人得知，公司的軟體開發業務並沒有多長時間，所以公司的很多工作流程還不太規範。在3個月的實習時間裡，我參與了一個類似於erp的專案。專案的大致內容是：為一家中型製造業企業量身訂做一套綜合管理系統，包括了倉庫管理，銷售管理，採購管理，生產管理，財務管理以及人事管理，共六個子系統，且這六個子系統是有機的組合，以方便該企業的管理生產資源，人力資源以及財務。在整個參與過程中，在不同時間裡擔任的工作任務也不同。
1、八月份
據瞭解，該專案早在3月份就開始了，而且該專案一直是處於不受控狀態，控制不了的原因有諸多，例如客戶的需求發生了巨大變動，該專案進行期間有很多其他的專案插入到開發過程中等等。於是，我參與了測試程式的工作，以熟悉整個專案的具體內容，功能實現，設計方法等。在做測試工作的過程中，發現實習單位目前對測試不太重視，在以前的專案中也很少有全面的軟體測試階段。主要表現在：一方面，在我實習期間，就陸續有以前做的系統拿回來，重新做測試工作並修改。據瞭解，目前國內的絕大多數軟體企業也是重編碼輕測試，導致軟體的強壯性低下，而在售後的維護階段中經常性需要大幅度修改。這樣一來，經常有不同的新老系統並行，給新系統的專案進度帶來了外部干擾；另方面，公司要求的測試方法也較為簡單，且測試文件的書寫格式極其簡單，這種書寫格式在一些功能上的錯誤和明顯的資料錯誤上有很好的表意效果，但是在表達程式的邏輯錯誤和內部資料錯誤時有很大的欠缺。在整個測試工作中也大概瞭解了該系統的各方面特性。該系統採用b/s結構開發，隨著internet的高速發展、電信部門對網路線路的投入、頻寬的增加等各個對b/s結構有利的條件下，採用b/s結構可以節省很多的成本。在以前採用c/s結構開發的系統中，需要為系統開發客戶端，而且在維護過程中，除了對伺服器端的維護，還要對各個客戶端進行維護，而目前盛行的b/s結構，則只需要開發和維護伺服器端，相比之下，開發和維護的成本也就大大降低。另外，b/s結構在internet裡的應用性比較高。但是，b/s結構也不是完美的選擇，它存在諸如b/s結構的使用者介面上比較難控制，瀏覽器的安全效能沒有很好的保障等問題。整個系統採用asp .net+ms sql server 2000做開發，程式語言採用c#和vb。
測試工作和書寫文件是比較枯燥的工作，測試更是要細心，有耐性的去做，在這個月裡認真的完成了我的工作，還幫忙修改了使用者介面。我的工作得到了負責人的肯定。
2、九月份
八月末就得知要將整個系統重構，因為原有未完成的系統跟變動後的使用者需求有太大的出入，而且系統存在比較多的錯誤，難以修復。負責人要求我參與到系統的重構工作中去，參與設計，程式碼編寫。這對我來說是一個考驗也是一個機會，於是我選擇了“倉庫管理”子系統，用vb作為編碼語言。在九月份的開發過程中，有兩個方面的感觸：
第一是技術方面。由於採用了vb編寫程式碼，而自身只學了c/c++、還有java。對vb只是一點點了解，另外，對asp dotnet更是一點不通。所以，這個時候需要發揮下自學能力，和領悟能力。在開發過程中印象最深的是web form裡datagrid的操作，以及對整個web form的執行過程。首先，由於倉庫管理絕大部分工作是填寫單據，單據是由單頭和單體組成，單頭記錄基本資訊，單體記錄明細資訊。設計決定在填寫單體時，採用datagrid行內編輯，所以datagrid的行內編輯將是技術的難點。dotnet的datagrid控制元件有編輯命令與刪除命令，而新增則可以透過一個button點選來生成一個新行等待編輯。三個操作的程式碼清單如下：
‘編輯命令程式碼清單
private sub datagrid1_editcommand(byval source as object, byval e as system.web.ui.webcontrols.datagridcommandeventargs) handles datagrid1.editcommand
if viewstate("add") <> 1 then
datagrid1.edititemindex = e.item.itemindex ‘將該行的編輯狀態行
datagrid1.databind()
end if
end sub
‘刪除命令程式碼清單
private sub datagrid1_command(byval source as object, byval e as system.web.ui.webcontrols.datagridcommandeventargs) handles datagrid1.command
if viewstate("add") <> 1 then
dim delindex as integer
delindex = cint(e.item.cells(1).text)
dim dr as datarow
dr = dataset1.tables("tblbrand").rows.find(delindex)‘找到該行在資料集中的編號
dr.()‘將該行在資料集中刪除
sqldataadapter1.update(dataset1.tables("tblbrand"))‘更新資料庫表
datagrid1.edititemindex = -1
datagrid1.databind()
end if
end sub
‘新增按扭事件程式碼清單
private sub button1_click(byval sender as system.object, byval e as system.eventargs) handles button1.click
dim dr as datarow
dr = dataset1.tables("tblbrand").newrow()‘新增一行，並將該行插入到資料集
dataset1.tables("tblbrand").rows.at(dr, ataset1.tables("tblbrand").rows.count)
viewstate("add") = 1
end sub
其實datagrid中有很多很好用的特性，具體請參考msdn。其次，為實現一次性提交整張單據到資料庫儲存，採用了sqlaadapter與dataset結合，應用sqlaadatper的uapdate方法特性：對dataset 的資料行做檢索，併發操作，update，三個命令，對刪除行做資料庫刪除，更改的資料行做更新，新增的行做插入。最後，在web form的初始到消除整個生命週期也有了較全面的瞭解。但是感覺dotnet中的web form的生命週期中，所發生的事件有些凌亂，例如datagrid每一行的建立和資料繫結都是比較複雜的，在開發中涉及的技術較多，在此不一一闡述。
第二是工作方面。在這個月中，同樣發現了公司的開發工作有較多的問題。首先，人員工作地點變動大，不便於溝通。在開發工作中，由於人員沒有固定工作地點，只是把任務分配了，接著就各自去完成，這樣一來，在各個模組的協調中經常出現了問題，但又不能很及時的和相關模組的負責人商討解決方法，工作效率也就隨之下降。其次，對整個專案的規劃，整個系統的'設計，編碼，測試等工作分工不明確且不統一。在專案開始時，只是草草的分了下模組，接著這個模組的設計、編碼、測試就由這個模組的負責人來做，沒有先對整個專案進行明確的整體的規劃。而且在設計過程中缺少討論，導致設計出來的模組獨立性過高，沒有考慮到公共的介面等問題。最後，對解決問題的速度慢。當在開發的過程中出現了問題，對問題的解決途徑多固然是好，但是，解決方案出現分歧的時候難以敲定具體實施哪個方案，導致進展緩慢，進度延期。
3、十月份
十月份是整個重構活動的收尾階段，該階段需要完成的工作是資料報表的設計與實現。資料報表設計方面，沿用原有的紙質報表的結構，所以整個設計過程相對輕鬆。但是在實現階段，由於在決定採用何種實現方式的決策問題上出現了飄忽不定的狀況，使得進度上又有了少許的延期，最後採用了crystalreports來實現。拋棄了列印分頁控制難的html方法，以及技術不成熟，安全性差的ms sql server reportingservice報表工具。在這個階段，我負責了倉庫管理、銷售管理、採購管理以及生產管理等四個子系統的報表實現，在此期間學會了crystalreports的使用和程式設計，收益頗多。這次重構活動涉及了資料結構的重構以及程式碼的重構，提高了系統的清晰性、擴充套件性以及重用性。整體效能有了明顯的提升。
六、實習總結：
在這為期3個月的實習過程中，透過擔任各種工作任務，充分的檢驗了自身所學的知識，瞭解了自身知識結構的不足；透過與接觸其他同事以及自我體驗，較深入地瞭解了軟體開發從業人員生活狀況，以及目前大部分中小型軟體開發企業的經營模式和操作流程。總結如下三點：
1、知識“閱兵式”
大學3年來所學的知識，在這次實習中得到了真正的檢閱，同樣，也暴露了知識結構的不合理性。技術上，學校裡所學的基礎知識表面上看似用不上，但卻是這些基礎知識讓我有很牢固的基礎，學起其他的技術知識自然而然的變得容易，能應對開發過程中所遇到的技術層面的問題。但是在業務上，由於缺乏所涉及的業務的相關課程的開展與自身涉獵知識面不廣，而造成了在業務流程轉換為系統設計或程式實現的中間環節頻頻出現困惑。軟體工程專業培養的目標是管理或系統規劃與設計，這一類的高層次人才，而不是純粹的編碼人員，所以對相關的業務應當明確、清晰。建議學校開展一些行業縱向討論課題來彌補這個不足。
2、從業人員的生存狀況
大部分從業人員長期生活在一種“精神高壓”的環境中。由於專案控制的難度大，有了進度表跟沒進度表的專案都一樣，員工基本都是天天在趕工。不管是在大型企業的軟體開發從業人員，還是在中小型企業軟體開發從業人員的工作時間一般都不固定。只要手頭上有沒做完的事情就要趕，也有的企業讓這種不固定變成讓員工靈活安排時間的方法：只要手頭上沒東西做，人可以不用擺在辦公室。但是，這種靈活性不是單方面的靈活，而是員工與管理者雙方面的靈活。只要有事做，管理人員隨時都可以叫上程式設計師一起“奮鬥”。專案驗收交付後，員工才算有休息一下的機會。這樣一來，人員的積極性、生產效率也隨著專案時間的持續而下降。但是，作為一個黃金職業，大部分從業人員都願意吃這個苦。
3、中小型軟體企業的經營模式與操作流程
目前，國內大型軟體開發企業數量較少，就規模而言，有關資料表明：90%以上的企業人數不超過100人，人員超過1000人的只有10家，同樣的，企業的盈利水平也普遍低下。在這些中小型的軟體企業中，他們的經營模式與操作的流程也都是大同小異：從經營的模式來講，一般是接或拉定單，按客戶要求制定靈活性強，適應性強的軟體。做自主研發，零售產品的軟體企業極為少數。從規模到盈利，就好比一家家的裁縫店，而非製衣廠；從操作的流程來講，從專案的規劃到啟動，再到測試驗收交付，其中規劃與測試一般都不充分，從而導致專案風險提高，進度延時以及交付後的產品強壯性差也是中小軟體企業存在的一大問題。
最後，在此感謝公司裡共事的每一位同事，感謝他們在實習期間給我的幫助。