翻看了自己設定的今目標計劃,50集的軟工視頻在我的跌跌撞撞中看完了,總的原因還是時間管理做得不當。
有時一天可以集中精力看四五集,有時好幾天不看。中間有去找過米老師,好了很多。自己開始做三到五天的計劃,每天都有堅持看,還好每天都完成了自己設定的計劃。
在有專業課考試的壓力下,自己總結就總結了五天,想想自己看的真是不怎麼樣,要不然也不用總結的時候這麼浪費時間。軟工視頻是自己圖畫的最多的一次學習,下面是最後的一張總結圖,只是做最初步的思考。
下面是放大圖,可能有一點亂,點擊可看大圖:
一個好的軟體工程是要讓使用者認可和滿意。在可行性研究的時候就要站在使用者的角度上思考,同時再考慮四個可行性。
軟體計劃是一個前提是一個必要的環節,只有計劃通過了才能有繼續下去的理由,是需求分析的準備工作。
需求分析開始分析軟體到底是做什麼的時候。
軟體設計是比較重要的,因為一些高品質的軟體都是設計出來的,而不是後面管理出來的。就象“一切帝國主義都是紙老虎”那樣可以斷定“差的系統設計必定產生差的軟體系統。”所以我們要努力保證系統設計“根正苗紅”,把一切左傾、右傾的設計思潮消滅在萌芽狀態。有一個很有意思的比喻:
就像一個人身體的任何一個部位設計不好也成不了一個合格的人一樣,一個軟體系統的每一部分都是環環相扣相輔相成的。在你設計系統的時候就要體現全心全意為人民服務的思想,否則很可能就會毀掉一個“人”哪。
程式編碼就是體現一個編程人素質的時候了,從代碼的規範都編程的風格,一段好的代碼不是誰都看不懂才體現出你很牛,恰恰是你的代碼編程的人都可以看得懂,可以拿來用,可以繼續你的工作,並且有很好的規範,才真是技術的嫻熟。
軟體測試,如果前面的準備工作做得好,在測試階段測試出來的錯誤頁就會很少,相應維護所需要的代價就會很低,由於在設計階段出現的失誤就導致在維護階段要付出十倍以上的代價,可見孰輕孰重。
軟體維護,占整個系統生存周期的70%,軟體維護困難的因素是由設計者和使用者共同決定的。
最後是文檔的規範,一個規範的文檔直接決定下一步人員對軟體的理解和對軟體完成的好壞。所以要培養自己寫規範文檔的能力。
軟體工程雖然學的跌跌撞撞,總是沒有踏實地感覺,那就繼續努力吧。
曹操之子曹彰曾建議:“大丈夫當學衛青、霍去病,立功沙漠,長驅數十萬眾,縱橫天下,何能為博士耶。”要後悔的事情太多了,只能現在做得勤快些。明知自己不成大器,但願意亡羊補牢,力求學得更深更廣。小女子更當如此。