軟件工程軟件工程實踐綜述

單擊此處編輯母版標題樣式,單擊此處編輯母版文本樣式,第二級,第三級,第四級,第五級,*,軟件工程,第二部分 軟件工程實踐,第5章軟件工程實踐綜述,Chapter 5,Practice:A Generic View,軟件過程提供了路線圖,軟件工程實踐提供了沿路駕駛細節(jié),軟件工程實踐四要素：概念、原則、方法、開發(fā)工具軟件工程實踐,軟件工程實踐,Practice is a broad array of concepts,principles,methods,and tools that you must consider as software is planned and developed.,It represents the detailsthe technical considerations and how tosthat are below the surface of the software processthe things that youll need to actually build high-quality computer software.,George Polya在How to Solve it中解決問題的本質(zhì)思路，也是軟件工程實踐的精髓：,理解問題（交流和分析）。

計劃解決方案（建模和軟件設(shè)計）實施計劃（代碼生成）檢查結(jié)果的精確度（測試和質(zhì)量保證）,5.1.1 實踐的精髓,5.1.1 實踐的精髓,George Polya,in a book written in 1945(!),describes the essence of software engineering practice,Understand the problem,(communication and analysis).,Plan a solution,(modeling and software design).,Carry out the plan,(code generation).,Examine the result for accuracy,(testing and quality assurance).,At its core,good practice is common-sense problem solving,將討論一些不同層次上的原則一部分關(guān)注軟件工程的整體一部分關(guān)注特定的、通用的框架活動（如溝通）一部分關(guān)注軟件工程的活動（如架構(gòu)設(shè)計）或技術(shù)任務（如用例場景書寫）。

5.1.2 核心原則,David Hooker提出7個關(guān)注軟件工程整體實踐的核心原則：,存在原則,：對用戶是否有用？,保持簡潔,：,簡潔，不是簡化，不是快速和粗糙,維護視圖,：,清晰的視圖是軟件項目成功的基礎(chǔ),生產(chǎn)者要讓消費者理解,：,讓別人明白你在做什么,面向未來,：,設(shè)計不要限于一隅，但不要過分,計劃復用,：復用省時省力，但也有代價,認真思考,：動手之前要認真思考,5.1.2 核心原則,5.1.2 核心原則,Provide value to the customer and the user,KISkeep it simple!,Maintain the product and project“vision”,What you produce,others will consume,Be open to the future,Plan ahead for reuse,Think!,在分析、建模之前，需要通過溝通活動（也稱需求誘導）收集客戶需求軟件工程師的溝通工作存在于：,與其他技術(shù)人員,與客戶和其他共同利益者,與項目經(jīng)理,5.2 溝通實踐,5.2 溝通實踐,與客戶溝通的原則,傾聽,：,謙虛。

易經(jīng)：謙之一卦，六爻皆吉六十四卦，唯一無缺點的卦：謙卦,有準備的溝通,：不打無準備的仗,需要有人推動,：讓溝通有效、化解沖突,最好當面溝通,：打電話比短信來去有效多了,記錄所有決定,：好習慣,保持通力協(xié)作,：,聚焦并協(xié)調(diào)話題,：保持話題局部化，不是擺龍門陣,采用圖形表示,：一圖勝千言,繼續(xù)前進原則,：溝通也有時間限制,談判雙贏原則,：雙贏，而不是戰(zhàn)勝對方,5.2 溝通實踐,5.2 溝通實踐,Principles,Listen,Prepare before you communicate,Facilitate the communication,Face-to-face is best,Take notes and document decisions,Collaborate with the customer,Stay focused,Draw pictures when things are unclear,Move on,Negotiation works best when both parties win.,5.2 溝通實踐,5.2 溝通實踐,適度計劃的原則：,理解項目范圍,：,確定目標。

如果不知道去何處，就無法使用路線圖客戶參與策劃,：項目交付時間、順序等,采用迭代計劃,：,項目計劃不可能一成不變，及時調(diào)整計劃,基于已知估計,：,估計的基礎(chǔ)要清楚，否則估計無意義,計劃考慮風險,：,對風險要有應急計劃，計劃要能適應風險,保持腳踏實地,：,人不能每天每時每刻都工作,調(diào)整計劃粒度,：靈活調(diào)整計劃的粒度制定計劃確保質(zhì)量,：確定如何確保開發(fā)的質(zhì)量,描述如何適應變化,：無法控制的變化有殺傷力,經(jīng)常跟蹤、校正計劃,：隨機應變,5.3 策劃實踐,5.3 策劃實踐,通過創(chuàng)建模型可以更好地理解需要構(gòu)建的實體實體是物理實體時，可以創(chuàng)建在形式和形狀上都和實物相同的模型（如雕塑小樣、飛機模型、大廈模型、沙盤）,實體是軟件時，模型是另外一種樣子，不同抽象層次下模型也不同5.4 建模實踐,在軟件工程中需要創(chuàng)建兩類模型：分析模型和設(shè)計模型分析模型從三方面表達客戶的需求：信息域、功能域、行為域,設(shè)計模型描述能幫助軟件開發(fā)人員進行高效開發(fā)的軟件特征：體系結(jié)構(gòu)/架構(gòu)、用戶界面、構(gòu)件級的細節(jié)5.4 建模實踐,5.4 建模實踐,We create models to gain a better understanding of the actual entity to be built,Analysis models,represent the customer requirements by depicting the software in three different domains:,the information domain,the functional domain,and the behavioral domain,.,Design models,represent characteristics of the software that help practitioners to construct it effectively:,the architecture,the user interface,and component-level detail,.,雖然有許多分析建模方法，每種分析方法都有其獨立觀點，不過所有的分析方法有共同的操作原則：,描述并理解問題的信息域,。

信息域包括流入系統(tǒng)數(shù)據(jù)、流出系統(tǒng)的數(shù)據(jù)、搜集和組織永久性數(shù)據(jù)對象的數(shù)據(jù)描述軟件所要實現(xiàn)的功能,軟件功能直接為最終用戶服務功能可以從不同抽象層次描述描述軟件的行為（作為外部事件的結(jié)果）,軟件的行為受外部環(huán)境交互驅(qū)動描述信息、功能和行為的模型必須能分解，以便揭示分層（或分級）細節(jié),分而治之分析方法能從本質(zhì)信息轉(zhuǎn)向?qū)崿F(xiàn)細節(jié),銜接分析模型和設(shè)計模型分析建模從最終用戶角度描述問題開始，在沒有考慮解決方案的前提下描述問題的“本質(zhì)”5.4.1 分析建模原則,5.4.1 分析建模原則,Analysis modeling principles,Represent the information domain,Represent software functions,Represent software behavior,Partition these representations,Move from essence toward implementation,Elements of the analysis model(Chapter 8),Data model,Flow model,Class model,Behavior model,5.4.1 分析建模原則,5.4.1 分析建模原則,軟件設(shè)計模型如同建筑師的房屋設(shè)計方案。

由描述所要建造的東西（如建立房屋結(jié)構(gòu)的三維透視圖）開始，然后逐漸進行細化，為每個構(gòu)建詳圖（如管線分布圖）提供指導類似，軟件設(shè)計模型為系統(tǒng)提供各式各樣的視圖5.4.2 設(shè)計建模原則,軟件設(shè)計方法有多種：數(shù)據(jù)驅(qū)動的、模式驅(qū)動的、面向?qū)ο蟮亩际褂猛惶自O(shè)計原則：,設(shè)計可以追溯到分析模型,經(jīng)常關(guān)注待建系統(tǒng)的架構(gòu),軟件架構(gòu)是系統(tǒng)的骨架設(shè)計應從架構(gòu)開始，然后才考慮構(gòu)件級設(shè)計數(shù)據(jù)設(shè)計和功能設(shè)計同等重要,數(shù)據(jù)設(shè)計是架構(gòu)設(shè)計的基本要素必須設(shè)計接口（包括內(nèi)部接口和外部接口）,要的接口設(shè)計讓集成變得簡單，并能輔助測試人員進行構(gòu)件功能測試用戶界面設(shè)計必須符合最終用戶要求,界面設(shè)計強調(diào)使用方便性用戶界面是軟件中可見的部分，不好的界面設(shè)計使整個軟件變得很糟糕5.4.2 設(shè)計建模原則,軟件設(shè)計方法有多種：數(shù)據(jù)驅(qū)動的、模式驅(qū)動的、面向?qū)ο蟮亩际褂猛惶自O(shè)計原則：,功能獨立的構(gòu)件級設(shè)計,構(gòu)件提供的功能是內(nèi)聚的構(gòu)件之間以及構(gòu)件與外部環(huán)境之間松散耦合,耦合可以通過多種方式實現(xiàn)：構(gòu)件接口、消息傳遞、全局數(shù)據(jù),耦合度高則發(fā)生錯誤的概率高，軟件可維護性低設(shè)計模型應盡可能易于理解,讓別人知道你做的是什么設(shè)計應該迭代進行每次迭代，設(shè)計者都應該盡力簡化,。

5.4.2 設(shè)計建模原則,5.4.2 設(shè)計建模原則,Principles,Design must be traceable to the analysis model,Always consider architecture,Focus on the design of data,Interfaces(both user and internal)must be designed,Components should exhibit functional independence,Components should be loosely coupled,Design representation should be easily understood,The design model should be developed iteratively,Elements of the design model,Data design,Architectural design,Component design,Interface design,5.4.2 設(shè)計建模原則,構(gòu)建活動包括一系列編碼和測試任務,5.5 構(gòu)建實踐,5.5.1 編碼的原則和概念,5.5.1 編碼的原則和概念,5.5 構(gòu)建實踐,5.5.2 測試原則,Davis提出了一套測試原則：,所有的測試都應該可以追溯到用戶需求,。

測試計劃應早于測試,在完成分析模型后就開始測試計劃將Pareto原則應用于軟件測試,80%的錯誤集中在20%的構(gòu)件中測試應從“微觀”開始，逐步轉(zhuǎn)向“宏觀”窮舉測試是不可能的交付一個軟件增量時應遵守的原則：,客戶對于軟件的期望必須得到管理完整的交付應高包括安裝和測試技術(shù)支持必須在軟件交付之前就確定下來必須為最終用戶提供適當?shù)恼f明材料有缺陷的軟件應該先改正再交付5.6 部署實踐,5.6 部署。