 |
VOOZH | about |
|
VOOZH | about |
導讀：在上一篇博客軟體工程：軟體計劃及軟體需求中，解決了「能幹否（可行性分析）」，如果能，則「幹什麼（需求分析）」的問題。接下來將要解決的是：「怎麼幹（設計）」，「實施（編碼）」，「干成否（測試）」，「更好否（維護）」。
在設計階段中，將形成的文檔有：概要設計說明書，詳細設計說明書，用戶手冊，測試計劃，資料庫設計說明書，數據描述說明書。
俗話說：沒有規矩，不成方圓。設計，是及其重要的一步，相當於建築圖紙，是施工的藍圖。可以說，沒有設計，就沒有好的框架結構，而沒有好的框架結構，那麼建構出來的東西也就是歪瓜裂棗，搖搖欲墜。寧肯在設計這一塊多費點時、費點心，也不要像無頭蒼蠅一樣亂撞，最後全軍覆沒。
在這一段的學習中，學到了編碼的規範。回想自己的編碼，注釋說明不充分，造成了理解困難，也就難以調試修改。在今後的學習中，當改正這一缺陷，走向正規化、職業化的道路。
在測試階段中，形成的文檔有：測試分析報告，項目開發總結報告，操作手冊。
學習了這段內容，再回想自己進行系統驗收的事兒，發現自己都違背了測試的原則，也難怪師傅一抓，就抓出問題一大把。我都是自己測試我的系統，也沒有進行邊界情況測試。做得最好的也就是早測，多測了。
第26講
從影響維護工作量的因素來看，更加凸顯了文檔的重要性，也學到了要對信息進行及時的備份，在修改的時候，我知道我得保留一份原始數據，然後再把每次修改的內容進行標記，然後備份。這樣以後，就可以進行追蹤，就像工作日誌一樣。
一開始的想法是，維護嘛，就是添加一些功能。學習了這段，才發現，維護，首先解決的是當前出現的問題。也就是，改正性維護——適應性維護——完善性維護——預防性維護。
學習到現在，真正的推翻了我原先的想法。我原來想學一點就寫一點的文檔，可是寫出來的東西都欠缺全局性。那時候也不知道下面會講些什麼，就一個勁的瞎寫。現在，我看到了軟體的維護，軟體的生存周期的各個階段，也算是有了全局的了解了，真的發現，做什麼事都要先從整體上去把握，然後逐步細化，才能更好。
好好學習，天天向上。
