軟件工程心得論文

軟件工程論文以溝通為出發(fā)點，以溝通為中心進(jìn)行項目的開展，可以有效地進(jìn)行項目的管理，提高項目的質(zhì)量，降低風(fēng)險與成本。溝通，不僅僅是指用言語進(jìn)行溝通，還可以以書面，文檔，手冊，電話，郵件，會議等方式進(jìn)行。靈活運用多種的溝通方式，使參與項目開發(fā)的每個成員能夠有統(tǒng)一的思想，不會產(chǎn)生歧義。當(dāng)然，溝通不僅僅是在工作上的溝通，也需要工作下的溝通。簡單來說，項目經(jīng)理對員工的不同程度的問候，或多或少會提升員工的工作積極性與主動性。而這也就升華到管理的層面，是管理項目，還是管理人？可以從底層分析，項目是由誰來做？是參與項目的員工。那么項目的質(zhì)量直接由什么來決定？員工的工作心態(tài)。但是員工的心理活動往往低多變的，沒有人能夠掌控，那么適當(dāng)?shù)臏贤?，不僅僅可以將這種情感活動向益于工作的方向轉(zhuǎn)移，而且也可以進(jìn)一步促進(jìn)公司的凝聚力，讓員工從心里將公司當(dāng)成一個大家來對待。而工作層面，適當(dāng)?shù)臏贤ǎ梢宰尡舜肆私鈱Ψ降乃伎挤绞?，迅速的采取合適的辦法，讓彼此的意見得到統(tǒng)一。而不是因為意見向左，產(chǎn)生分析，得不到進(jìn)一步的解決。從項目整體來講，合適的溝通可以降低項目需求的多變性，從而降低項目開發(fā)的成本；合適的溝通可以將技術(shù)層面的難題，得到共同的思想靠攏，從而得到解決；合適的溝通可以讓各崗位職責(zé)的人能夠明白彼此的意見，提高工作效率的同時，也進(jìn)一步降低因為溝通不當(dāng)，導(dǎo)致項目BUG出現(xiàn)的幾率。溝通分層次，同一個層次的人群互相溝通，不會有太大的難度與理論上的偏差。而針對不同領(lǐng)域，不同層次的人來說，彼此之間的溝通成為了一個難題。所以從公司的角度分析，首先項目組成員必須具備最基本的理論基礎(chǔ)，如:《軟件工程》，《軟件質(zhì)量》等。從細(xì)節(jié)劃分，編程人員需要有關(guān)于具體編碼規(guī)范等額外理論基礎(chǔ)，測試人員需要有關(guān)測試方面等額外理論基礎(chǔ)，針對項目經(jīng)理，不僅需要編程人員與測試人員的基礎(chǔ)理論，也需要整個項目的理論，如《軟件項目管理》，《項目管理知識體系》等管理知識。只有理論背景差別大不的情況下，互相之間的溝通，才會更加有效率，進(jìn)一步降低信息在傳輸之間的損耗，使開發(fā)出的軟件更加接近客戶的要求，提高客戶對公司產(chǎn)品的滿意度，有利于產(chǎn)品的市場推廣。所以完美的項目不存在，只能在共同的努力下，產(chǎn)品才能夠向完美進(jìn)一步靠近。以下從項目的整體來闡述溝通對各個層次的影響。競標(biāo)階段，競標(biāo)的成敗與否，在于自己的產(chǎn)品是否接近客戶心中的目標(biāo)，從而贏得投標(biāo)，其中的關(guān)鍵在雙方的溝通。眾所周知，項目從哪來，是從客戶的需求得來。那么從公司的角度出發(fā)，如何獲得客戶的認(rèn)可，得到項目的投標(biāo)？這是個很現(xiàn)實的問題。在《軟件工程導(dǎo)論》上得到很多信息，如何快速開發(fā)出客戶滿意的模型，在于需求分析師從客戶交流中，得到有用信息的有效程度。其中的信息不僅僅是項目的功能，也有客戶的背景，使用環(huán)境，客戶群的習(xí)慣等等方面。根據(jù)市場調(diào)研顯示，客戶的體驗度已經(jīng)成為一個不可忽視的環(huán)節(jié)，雖然所開發(fā)的系統(tǒng)已經(jīng)完成了用戶的基本功能要求，但是從客戶最直接的感官出發(fā)，系統(tǒng)操作不夠簡便，系統(tǒng)畫面不夠人性化等等細(xì)節(jié)體現(xiàn)出，客戶的滿意度沒有達(dá)到應(yīng)該有的高度。所以，中間的溝通也就成了關(guān)鍵。作為項目前期需求的主導(dǎo)--需求分析師的素質(zhì)成為了主要因素。對于大多數(shù)人來說，獲取對方話語的有效的信息量為80%，而經(jīng)過需求分析師的再一次理解，到了開發(fā)人員的手中的文檔的有效信息不到實際的70%，所以常常開發(fā)出來的軟件無法達(dá)到滿意的效果。如何在溝通中獲取全面的有效信息？最有效，也最全面的方式，莫過于在溝通交流之前，需求分析師進(jìn)行一次全面的市場調(diào)研，對該客戶的環(huán)境，業(yè)務(wù)等方面進(jìn)行理解與學(xué)習(xí)。然后在此基礎(chǔ)上，結(jié)合自己的理解與客戶進(jìn)行下一步的溝通，在客戶的角度思考問題，用自己的話語闡述客戶的各種需求，得到對方的肯定，最終整理出最滿意的客戶需求。那么如何快速的讓客戶的需求，轉(zhuǎn)變?yōu)榭梢钥吹降降奈锢砟Ｐ?，這里提倡使用快速原型法。系統(tǒng)架構(gòu)師根據(jù)前期的客戶需求文檔，運用axure等建模工具,快速有效地開發(fā)出前期的模型，使文字性的描述，轉(zhuǎn)變?yōu)樽钪庇^的物理模型，不僅可以更清晰的展現(xiàn)用戶需求，也可以更直觀的確認(rèn)該模型是否符合客戶的要求，以及時作出合理的調(diào)整，作出讓用戶滿意的模型產(chǎn)品。開發(fā)模型的同時，成本的估算工作已經(jīng)展開。有了具體的值，才會有實際給客戶的報價。所以如何估算？使用哪種方式估算？以哪個項目為藍(lán)本？需要進(jìn)一步的分析與思考。結(jié)合自己學(xué)的知識，以及向前輩請教的經(jīng)驗，發(fā)現(xiàn)（UCP）功能點算法，（LOC）代碼行算法,(WBS)工作結(jié)構(gòu)分解法已成為主流。對于UCP，主要用于面向?qū)ο蟮捻椖?，LOC與WBS沒有具體限制。每個算法都有自己的優(yōu)缺點，對于不同的項目，項目的不同階段，使用不同的算法，能夠很好地解決成本估算的問題。其中具體估算的同時，經(jīng)驗也是非常重要的，經(jīng)常性的去總結(jié)每個項目，詳細(xì)具體到單元，功能的估算，收錄成冊，形成良好的循環(huán)，對于公司是至關(guān)重要的。而這里是項目第一次的初步估算，是為贏得競標(biāo)的概要值，得到標(biāo)后，需要進(jìn)行詳細(xì)的成本估算與具體商榷的價格。理論與經(jīng)驗的結(jié)合，可以進(jìn)一步精確項目的成本估算，對于項目下一步的開展，起到良好的前期鋪墊作用。公司得到競標(biāo)后，進(jìn)入需求分析階段，參與人員主要為需求分析師，系統(tǒng)架構(gòu)師，項目經(jīng)理。主要輸出為，詳細(xì)的項目成本估算，項目進(jìn)度估算與需求規(guī)格說明書，概要設(shè)計，詳細(xì)設(shè)計等文檔。參與者之間，需要進(jìn)行詳細(xì)的溝通，達(dá)成思想上的統(tǒng)一。項目成本估算與項目進(jìn)度的估算越詳細(xì)越好。實際中,為了滿足顧客期望的日期而造成的不合理進(jìn)度安排，在軟件領(lǐng)域比其他的任何工程領(lǐng)域要普遍得多。而且，非階段化方法的采用，少得可憐的數(shù)據(jù)支持，加上完全借助軟件經(jīng)理的直覺，這樣的方式很難生產(chǎn)出健壯可靠和規(guī)避風(fēng)險的估計。所以在這個階段，開發(fā)并推行生產(chǎn)率圖表、缺陷率、估算規(guī)則等等，對于整個公司來說，最終會從這些數(shù)據(jù)的共享上獲益，形成良好的循環(huán)。分別來講，在成本的估算上，推崇使用UCP（功能點算法）。這種方法，可以將項目中的各個方面，包括各種風(fēng)險都能夠考慮進(jìn)去。其中，在風(fēng)險方面，需要全面的分析整個項目，從整體分析，然后小到局部，考慮未來可能出現(xiàn)的風(fēng)險，評估每個風(fēng)險的概率，計算出對應(yīng)的功能點，然后估算每個功能點的費用，從而得到比較理想的成本估算。在進(jìn)度的估算上，推崇使用WBS（工作結(jié)構(gòu)分解法），將項目任務(wù)進(jìn)行合理的細(xì)分，分到可以確認(rèn)的程度，然后估算每個WBS要素的時間，從而得出整個項目的時間。當(dāng)然WBS也可以適用于估算項目的成本，這里因人，因項目而異。靈活使用不同的方法，可以進(jìn)一步精確最終的估算值，將風(fēng)險減小到最少，利于下個階段的展開。在整個需求分析階段，要將需求做的更細(xì)，更準(zhǔn)確為目標(biāo)，不斷地與客戶溝通，嚴(yán)格杜絕使用習(xí)慣性的想法，去掩蓋客戶的真實需求，溝通應(yīng)該具體到每個功能點，得到客戶的肯定后，進(jìn)行下個功能點的溝通。關(guān)注客戶的顏色感官，操作習(xí)慣等細(xì)節(jié)方面。盡可能全面的從客戶的角度去分析問題，然后結(jié)合公司的技術(shù)，給用戶合理的反饋，得到最終雙方都滿意的結(jié)論。需求分析師需要具有良好的溝通能力外，也需要出色的理解分析能力，具備業(yè)務(wù)基礎(chǔ)，項目成本評估，以及各種文檔的編寫能力。一個成熟的需求分析師，可以將溝通中信息的損耗減小到最低，提高用戶的滿意度，整理出比較全面的《需求規(guī)格說明書》，有利于系統(tǒng)架構(gòu)師的工作開展?！缎枨笠?guī)格說明書》得到后，系統(tǒng)架構(gòu)師需要在此基礎(chǔ)上，完成系統(tǒng)的架構(gòu)，整理《系統(tǒng)概要設(shè)計說明書》與《系統(tǒng)詳細(xì)設(shè)計說明書》，完成系統(tǒng)的前期搭建工作。良好的系統(tǒng)架構(gòu)師需要具有相關(guān)的知識與經(jīng)驗外，也需要很強(qiáng)的分析，解決問題的能力，戰(zhàn)略規(guī)劃能力，業(yè)務(wù)流程建模能力，信息數(shù)據(jù)結(jié)構(gòu)能力等多方面的素質(zhì)。從細(xì)節(jié)方面分析，系統(tǒng)架構(gòu)師需要從需求到設(shè)計的每個細(xì)節(jié)都要考慮，把握整個項目，使設(shè)計的項目盡量效率高，開發(fā)容易，維護(hù)方便，升級簡單等等。工具方面，熟練使用RationalRose、PowerDesigner等工具進(jìn)行設(shè)計開發(fā)，提高工作效率。在《系統(tǒng)詳細(xì)設(shè)計說明書》完成后，參與項目的各成員需要進(jìn)行評審工作，評審《需求規(guī)格說明書》與《系統(tǒng)詳細(xì)設(shè)計說明書》，提出自己的看法與觀點。在總的設(shè)計環(huán)境下，尋找不足與欠缺的地方，盡可能去完美這個設(shè)計，發(fā)現(xiàn)以后可能要面臨的問題，提前思考與解決，降低系統(tǒng)的開發(fā)難度，利于編碼工作有力進(jìn)行。所以，各種文檔的輸出需要統(tǒng)一化，利于閱讀人員的理解，也就是在書面的溝通上不會產(chǎn)生細(xì)想上的偏差，將理解上的風(fēng)險降到最低。所以在開發(fā)的初期，參與項目的各個成員必須達(dá)成思想上的一致，可以細(xì)致到需求文檔中每個功能都是一樣的理解。如此，項目的最終產(chǎn)品，才會偏差最小，越接近用戶的需求，達(dá)到更高的用戶滿意度，得到更好的業(yè)界好評。綜合考慮，需求分析階段主要做四個方面的工作。1.問題的識別，即雙方確定對問題的綜合需求，這些需求包括功能需求，性能需求，環(huán)境需求，用戶界面需求等。2.分析與整合，導(dǎo)出軟件的邏輯模型。3.各種文檔的輸出，即寫出詳細(xì)的需求規(guī)格說明書，用戶使用手冊，測試計劃，測試用例，系統(tǒng)概要設(shè)計等文檔。4.評審與反饋，分為技術(shù)評審與需求評審，發(fā)現(xiàn)更多的問題，防范于未然。編碼階段，主要為程序員之間的溝通，程序員與經(jīng)理之間的溝通，程序員與系統(tǒng)架構(gòu)師之間的溝通成為影響軟件質(zhì)量，項目進(jìn)度的主要因素。項目編碼階段，項目經(jīng)理需要了解參與項目中的每個人的技術(shù)程度，這將是分配模塊的困難程度的一個重要環(huán)節(jié)。簡單的模塊交給技術(shù)不好的人來做，難的模塊交給技術(shù)達(dá)人來做。如果如此安排，新人還是新人，技術(shù)達(dá)人依然會更加忙碌，更加累，沒有任何改變，也不利于公司的長遠(yuǎn)發(fā)展。所以合理的搭配難易程度，讓新手在編程梯度漸增與技術(shù)達(dá)人的合作環(huán)境下，快速成長，同時也緩解了技術(shù)達(dá)人的壓力，可以將更多地精力投入到技術(shù)難點中，提高項目組整體的效率。編碼期間，對成本與項目進(jìn)度的控制，也是項目經(jīng)理的一個重要任務(wù)。為了提前項目進(jìn)度或者壓縮項目成本，而采取不合理的工作安排，如經(jīng)常性的加班，項目工作裁剪等手段，往往是非常致命的，不僅會使項目的質(zhì)量整體下降，而且會使員工的凝聚力降低。雖然如此做可以完成項目的功能目標(biāo)，但是項目的后期維護(hù)將會是一個災(zāi)難。而且不合理的時間安排，也會使員工心理產(chǎn)生不可控制的活動，從而對公司的長遠(yuǎn)發(fā)展產(chǎn)生隱性的影響。這些往往是大多數(shù)經(jīng)理人不會考慮的，對員工的忽視，導(dǎo)致員工的離職，成為社會的一個主流，這對正在進(jìn)行的項目來說，會造成很大的成本與風(fēng)險壓力。老員工的離職，新員工的進(jìn)入，不僅僅是人員的改變，也是對開發(fā)團(tuán)隊的再一次整合，去熟悉新人的做事風(fēng)格與思考問題的方式，期間所消耗的時間已遠(yuǎn)遠(yuǎn)超過培訓(xùn)的時間，而結(jié)果往往會延誤項目進(jìn)度。通常當(dāng)意識到進(jìn)度的偏移時，下意識（以及傳統(tǒng)）的反應(yīng)是增加人力。這就像使用汽油滅火一樣，只會使事情更糟。越來越大的火勢需要更多的汽油，從而進(jìn)入了一場注定會導(dǎo)致災(zāi)難的循環(huán)。Brooks法則—“向進(jìn)度落后的項目中增加人手，只會使進(jìn)度更加落后”。落后的項目不增加技術(shù)人員，唯一的風(fēng)險也就是進(jìn)度的延期，而增加人手，改變計劃往往將增大項目不可控制的風(fēng)險，而這些風(fēng)險常常是致命的。研究表明，缺乏合理的時間進(jìn)度是造成項目滯后的最主要原因，它比其他所有因素加起來的影響還要大。所以可控的項目進(jìn)度，是項目經(jīng)理所追求的，不斷變化的環(huán)境，需要更加合理的方式去解決。理想中，已經(jīng)計劃好的進(jìn)度不會實現(xiàn)，只會因為不確定的因素而改變。實際工作中,遇到項目進(jìn)度的偏移，采取必要的增加人手往往是唯一的辦法。雖然每次估計項目的成本最終為人月的計算，但是人和月之間的互換，緊靠單純的數(shù)據(jù)是顯示不出來的。每個人的編程風(fēng)格的不一致，技術(shù)水平的高低，理解能力的不同，會造成或多或少的時間損失與成本損失。更重要的是，每個人的性格不同，與人的溝通方式不同，融入新的團(tuán)隊，那么這會因為新人的加入而使整個團(tuán)隊發(fā)生”化學(xué)反應(yīng)”,當(dāng)然這里所說的化學(xué)反應(yīng)可不是NBA那樣，是促進(jìn)型的。再加上彼此之間的磨合期，適應(yīng)期，互相熟悉彼此的代碼風(fēng)格等等,這些都隱含的消耗掉大量時間。所以人月的互換，需要仔細(xì)的去更改原有的項目計劃，以適應(yīng)新的變化。如果僅僅靠增加人手，而對應(yīng)的項目不做相應(yīng)的改變，那么最終的項目會超出應(yīng)有的控制，向著不可預(yù)料的方向發(fā)展，最終的后果往往是不可承受的。如何控制項目進(jìn)度與成本，降低項目的風(fēng)險？需要項目經(jīng)理全面地掌握項目進(jìn)度的開發(fā)，那么其中會議的開展是必要的。這里將會議分為兩種，周例會與年例會。每周定時的開會，討論目前工作中所遇到的問題，對項目的風(fēng)險與進(jìn)度是有很大的好處，問題的及時提出，重大BUG的發(fā)現(xiàn)，并得到關(guān)注與解決，都會對項目的進(jìn)度造成一定程度上的影響。所以，前期階段的問題排查與解決，對項目后期的測試與維護(hù)工作有很大幫助。前期的努力在一定程度上降低了項目的成本。當(dāng)然，每周例會或多或少會留下少許的問題，或者重現(xiàn)的問題，這些問題會在時間上不斷地堆積，所以必要的年會可以更好地解決這類問題，3個月或者6個月的大會也是最好的選擇。發(fā)現(xiàn)與總結(jié)前段時間的問題，可以更好地控制項目前進(jìn)的方向。另一點，這些會議不僅可以解決決策上的問題，而且可以使決策更容易被接受。每個人都在傾聽，每個人都在參與，每個人對復(fù)雜約束和決策之間的相互關(guān)系有了更透徹的理解。也有利于員工對于有疑問的點，或者問題，盡可能與架構(gòu)師或者分析師溝通，得到一個權(quán)威性的結(jié)論，而不是自己去猜測著去工作，埋下隱性問題，為以后的測試工作造成壓力。綜上所述，一個優(yōu)秀的項目經(jīng)理人，對項目的開展有極其重要的作用。那么項目經(jīng)理，不僅在編程方面需要有一定的水平，而且在項目的管理方面，也需要有著豐富的經(jīng)驗。由于項目在開展過程中，會遇到各種各樣的問題，所以，具備良好的應(yīng)變能力的經(jīng)理人，對項目的持續(xù)開展有著極其重要的意義。測試階段，測試人員與程序員之間思想上的統(tǒng)一，在一定程度上決定了軟件的質(zhì)量。通常我們將測試階段分為單元測試，集成測試與用戶測試，使用的工具為JIRA或者Bugzilla等缺陷工具。單元測試是指對軟件中的最小可測試單元進(jìn)行檢查和驗證。對于單元測試中單元的含義，一般來說，要根據(jù)實際情況去判定其具體含義，如Java里單元指一個類，圖形化的軟件中可以指一個窗口或一個菜單等。單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動，軟件的獨立單元將在與程序的其他部分相隔離的情況下進(jìn)行測試。所以,單元測試是由程序員自己來完成，最終受益的也是程序員自己。程序員有責(zé)任編寫功能代碼，同時也就有責(zé)任為自己的代碼編寫單元測試。但是在實際項目中，往往程序員比較理想化，測試自己的代碼找不出明顯的BUG。所以，這里需要使用一種小組成對的方式，互相測試對方的代碼，可以更明顯的發(fā)現(xiàn)其中的問題。中間就涉及到了溝通的問題，代碼是他人寫的，需要讀懂彼此代碼，就必須進(jìn)行不斷地交流，如此才能更好地進(jìn)行測試。而這個方式，不僅可以有效地發(fā)現(xiàn)彼此代碼中的問題，也可以進(jìn)一步加強(qiáng)團(tuán)隊里面人員的溝通，適應(yīng)彼此之間的思維模式，提高團(tuán)隊整體開發(fā)效率。雖然這個方式需要花費比較多的時間與成本，但是與維護(hù)中發(fā)現(xiàn)的BUG的成本相比，會有很大的差別。其中這種方式，需要責(zé)任到人，才能體現(xiàn)出更好地效果地方。集成測試是指在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計要求組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現(xiàn)。所以對集成測試的工作，必須加強(qiáng)落實，而不能像走過場一樣，簡單走遍流程，功能實現(xiàn)就結(jié)束，應(yīng)該將所有出現(xiàn)的細(xì)節(jié)問題得以重視，并且及時反饋信息，得到有效地解決。集成測試期間最主要的參與人員為測試人員，但反饋的信息，需要開發(fā)人員的確認(rèn)，所以兩者之間的溝通成為必然。測試人員如果發(fā)現(xiàn)問題，如何將自己的思想有效地傳遞給對應(yīng)的開發(fā)人員，成為一個問題。通常過程中，我們是以書面或者口頭上的簡單陳述來表達(dá)問題，但是往往發(fā)現(xiàn)，同一個問題，需要多次返工，才能得到有效地解決。而這里，提倡使用圖形，BUG重現(xiàn)與文字結(jié)合的方式，更加清晰地反應(yīng)問題的實質(zhì)，指明要點，如此可以進(jìn)一步減小因為溝通上的原因，造成返工的次數(shù)。而總體來說，在集成測試階段發(fā)現(xiàn)的BUG越多，對后期維護(hù)的壓力越小，維護(hù)的成本越低。所以集成測試期間，需要全員的配合，共同努力，發(fā)現(xiàn)系統(tǒng)的問題，調(diào)高軟件的質(zhì)量。在完成單元測試與集成測試的基礎(chǔ)上，進(jìn)行最有一步的用戶的測試。當(dāng)然，這里最好的方式，是將軟件先交付給項目組以外的成員，開辟一段時間去使用。而是這些成員不需要懂軟件，是從用戶的角度出發(fā)使用軟件，發(fā)現(xiàn)其中的問題。當(dāng)然，從項目的整體來講，這里的測試使用，可以從項目的里程碑開始，每完成一個里程碑，就可以