2019-06-04 18:27:58
1.瀑布模型
傳統軟件方法學的軟件過程，基本都可以用瀑布模型來描述。
與傳統的瀑布模型相比，傳統的模型沒有每一階段的驗證，當后期發現錯誤時，則需要全部重頭修改，消耗了大量人力物力。當前的瀑布模型每一階段完成之后都要驗證，保證每一階段工作的准確性與高效性。
瀑布模型特點：必須等前一階段的工作完成之后，才能進入下一個工作階段。
在瀑布模型的每個階段都應該堅持：
（1）每個階段都必須完成每個階段規定的文檔。
（2）每個階段結束前都要對所完成的文檔進行評審，以便於盡早發現問題，改正錯誤。及時審查，是保證軟件質量、降低軟件成本的重要措施。 （所以需求分析、規格說明、設計階段都要驗證。）
實線階段代表開發過程，虛線階段代表維護過程。左側的反饋箭頭表示當前階段發現錯誤時，需要回溯到上個階段檢查。在編碼完成后，要對每個單元的編碼進行測試，下一步進行綜合測試，最后進行維護。在維護完成之后，上面有虛線箭頭分別指向規格說明、設計與編碼階段，是因為在維護過程中，可能出現的問題所在的階段。並且，如果當用戶有變化的需求時，則應當重新開始撰寫需求分析書，向下的步驟依次進行，直到用戶滿意。
2.軟件生命周期
軟件定義時期的任務：確定軟件開發工程中的總目標，確定工程的可行性。估計完成該工程的時間成本，並且制定工程進度表。
（1）問題定義：通過對用戶的調查訪問，確立用戶的問題性質，工程目標等。
（2）可行性研究：確立問題研究的范圍及可行性，及拿些階段應該投入更多的人力物力。
（3）需求分析：與客戶進行密切訪問充分交流信息，以得出用戶想要的系統邏輯模型（是以后設計和實現目標的基礎）。這個階段的重要任務是用正式文檔准確地記錄對目標系統的需求，成為規格說明書。
開發階段的任務：具體設計和設計前一個時期定義的軟件。
（1）總體設計：應該先設計出實現目標系統的幾種可能性方案，還有設計程序的體系結構，即確定程序由哪些模塊組成及模塊之間的關系。
（2）詳細設計：解決了具體實現系統的任務，詳細地設計每個模塊，確定模塊功能所需要的算法及數據結構。
（3）編碼和單元測試：寫出正確的容易理解、易於維護的程序模塊。
（4）綜合測試：通過各種類型的測試達到預定的要求。最基本的測試是集成測試和驗收測試。
運行維護的任務:使軟件持久地滿足用戶的需求。具體來說，當軟件在使用過程發現的錯誤應該及時改正；當環境改變時應修改軟件以適應新的環境；當用戶有新的需求時應及時改進軟件已滿足用戶的新需求。
3.分析模型
數據是模型的核心（數據字典是工具），是關於數據的信息集合，也是對數據流圖中包含的所有元素定義的集合。對於數據流圖中出現的所有被命名的圖形元素加以定義，使得每個圖形元素的名字都有確切的解釋。
實體關系圖（ER圖）：描述數據對象以及對象間的關系，用於數據建模。數據模型包含：數據對象、數據對象的屬性、數據對象彼此間的關系。
數據流圖（DFD圖）：描述了數據流在系統中流動的過程，以及指明對數據流進行變換的功能，是用於功能建模的基礎。是結構化分析的基本工具，描述了信息流和數據轉換，通過對加工進行分解可以得到數據流圖。對應加工規格說明。
狀態轉換圖（STD圖）：描述了對外部事件的響應方式，表示了系統的各種行為模式（稱為狀態）以及在狀態間進行變遷的方式，用於行為建模。狀態是可以被觀察到的系統行為模型，一個狀態代表系統的一種行為模型。對應控制規約。
4.將分析模型轉化為軟件設計
分析模型中的每一個提供了建立設計模型所需的信息。
數據設計將實體關系圖中描述的對象和對象之間的關系，以及數據字典中描述的詳細數據內容轉為數據結構的定義（與數據字典、實體關系圖對應）。
體系結構設計定義軟件系統各主要成分的關系，主要需要分析數據之間怎樣從一個模塊流向另一個模塊以及在模塊內部的流向。（數據流圖）。
總體設計分為數據設計和體系結構設計。
接口設計根據數據流圖定義軟件內部各成分之間、軟件與其他協同系統之間及軟件與用戶之間的交互機制，主要分析數據從不同的模塊之間如何設計接口，需要用到數據流圖。（數據流圖）。
過程設計把結構成分轉化為軟件的過程性描述，牽扯到數據狀態的轉換，以及狀態變化的方式。（狀態轉換圖、控制規格說明、加工規格說明）。
5.測試步驟與方法
測試時，首先進行單元測試，再進行組裝測試，最后進行確認測試。
（1）模塊測試：即單元測試。每個模塊對應一個獨立的子功能，將每個模塊作為一個獨立的實體進行測試，確認每一個單元能夠正常運行，在該階段的錯誤通常是編碼和詳細設計的錯誤。由編碼人員自己完成（白盒法）。
（2）系統集成測試：即接口測試、組裝測試。將經測試后的單元模塊按照一定的順序組裝成系統，同時進行測試。重點是模塊之間的相互通信與協調。當規模系統龐大時，進行集成測試一般分為子系統與系統測試（黑盒法）。應當驗證系統是否能夠實現需求分析的功能與性能，由專門的測試部門完成。
（3）確認測試：合格測試或驗收測試。驗證系統是否達到系統規定的要求。
（4）回歸測試：在集成測試與確認測試之間加入回歸測試。當某一個系統測試出現問題時，與該系統相關的系統進行局部測試，不用進行完全測試，節省時間應該返回就行回歸測試。所以回歸測試是很有必要的。
6.噴泉模型
“噴泉”體現了軟件工程開發過程中的迭代和無縫的特性。
八個關鍵字：“快速迭代，無縫銜接”
不同階段的圓圈相互重疊，表明兩個活動之間存在交迭。
圖中在一個階段中的每一個向下的箭頭表示階段內的迭代（或求精）。維護的圓圈較小，表示在采取了面向對象范型之后維護的時間縮短了。編碼階段與集成測試階段的重疊較大，說明兩個活動之間存在較大的重疊性，編碼階段的“單元測試”由編碼人員自己完成。
與瀑布模型相比，瀑布模型是面向問題的一種軟件模型，而噴泉模型是面向對象分析的一種模型，噴泉模型的各個活動之間存在交迭，且每一部分完成之后都要求精，以節省時間。
7.面向對象分析模型
原型開發指向發現對象，對象也指向原型開發。因為原型開發綜合其他活動進行是為了找出所有對象。早期的原型用於證實客戶的需求，晚期原型用於修改交付用戶前使用的狀態。
建立用況圖是用戶使用/需求情況圖。
發現對象是必要操作，是建立分析模型的必要環節。
詳細說明與發現對象、定義屬性與服務、建立結構與連接、划分主題（包）有雙向箭頭，詳細分析對模型中的成分進行規范的定義和文字說明，可集中可分散。詳細說明是一個反復的工作，因為對象以及對應屬性的不斷完善，所以需要反復進行。相當於面向過程分析模型中的“數據字典”。
建立交互圖、狀態圖、活動圖是輔助模型，可有可無。
圖中每一個過程都有向上回溯的過程，面向對象的一個過程包括對象模型、功能模型與動態模型，各個過程之間界限模糊，為了更詳細地找出對象與之間的關系。而面向過程分析模型由 數據模型--功能模型--行為模型，由一定的順序，遵循嚴格的順序進行，逐步找出對象與動能。
8.面向對象設計模型
4大系統：問題域 人機交互 任務管理 數據管理（關系：並列 無縫）
右邊主要是OOA模型，5個過程之間無嚴格層次，先抽取一部分對象，按照其屬性與服務相同的歸為一個類，當有很多類時存在結構划分，當有更多的結構時划分為主題。對象是在不斷發現的，所以在發現新的對象時，又重新開始進行類與對象的划分。
9.建模過程框圖
一個模型的可信性分為：在演繹中的可信性 在歸納中的可信性 在目的方面的可信性
在進行一個軟件模型建立時，應該具有一定的先驗知識，比如現在要做建設銀行的軟件，可以對比之間做過的農業銀行。
演繹分析應在一個邏輯上正確、數學上嚴格含義進行。
歸納法建模的主要信息來源是實驗數據，其可信性分析是檢查歸納程序是否按數學上和邏輯上進行。
一個模型只有在他用於原定的目標才能體現出它的意義。
10.建模的整個過程
是一個有規律、可推導、可追溯的過程。
業務模型：如何為現實世界建立模型： 人（actor） 事（use-case） 物（object model） 關鍵弄明白什么人，什么人做什么事，什么事產生什么物，中間有什么規則，再把人事物之間的關系定義出來，一個模型也就基本建立。參與者（人）是整個模型的核心，用例 （事）表示驅動者的業務目標。對象模型（物）表示達成這些業務目標過程中所涉及到的事物，用邏輯概念來表示他們，並定義他們之間的關系。業務模型映射了參與者在現實世界中的行為。
概念模型：向上映射了原始需求，向下為計算機提出了一種更高層次的抽象。
邊界類：界面（UI）,所有對計算機的操作都要通過界面進行。
實體類：業務實體的實例化結果 ，添加那些實際業務中使用不到但是轉型計算機邏輯時需要的控制信息。
控制類：原始需求中的動態信息，即業務或用例場景中的步驟和活動。
在這個階段，還可以對這些分析類在不同的視圖上進行歸納和整理，以表達軟件要求的一些信息。軟件架構和框架通常也在這個階段產生。
設計模型：將該概念模型實例化，得到真正可執行的計算機代碼。概念模型中的邊界類可以轉化為操作界面或者系統接口。控制類可以轉化為計算機程序或控制程序。實體類可以轉化為數據庫、文檔或者其他持久化特征的類。
軟件系統建模：先完成9種圖例--完成5種視圖--完成3種轉換
9種圖例：用例圖、類圖、對象圖、狀態圖、順序圖、協作圖、活動圖、構件圖、部署圖
5種視圖：用例、邏輯、構件、並發、部署
3種轉換：現實--業務 業務--概念 概念--設計
2019-07-27 09:53:53 昨天在b站看了一個小視頻，關於互聯網公司的職業划分，在此做一個小分享（原視頻up主：小魚干的藏寶屋 2019/07/21)
一個互聯網產品的誕生，最初都來源於一個想法，無論想法來自於客戶或者來自於老板，在大多數情況下，他們很難去描述自己的業務需求，所以產品經理應運而生，用來真正地了解客戶或者老板的想法並分析用戶和市場需求來設計產品，完成設計后，要把自己的設計寫成文檔和完成設計圖，交付給后面地人員進行開發，同時在產品的開發階段需要配合設計開發測試運營等同事協作完成，進行調整和溝通，保證自己的產品能夠順利上線。
在產品經理設計好文檔及原型圖之后，項目也開始啟動。這時，web后端程序員，設計，架構師，web前端程序員，手機端程序員，數據庫管理員，特殊方向程序員，運維，測試等部門准備就位，勢必要把這個項目撕個粉碎。 可是，這些人如何協作，進度如何跟進？此時，項目經理出現，顧名思義，帶着大家做項目，安排項目計划，主要和人打交道，需要協調各個方面的關系，保證項目進展順利。
項目開始，首先，設計部門開始設計：賞心悅目的界面，舒服的交互性都是視覺、交互、UI設計師需要考慮的。這時，程序員的最高等級架構師開始根據文檔的內容，敲定該產品多用到的技術棧和搭建穩定的基本架構，作為一名合格的架構師，不僅需要過硬的技術能力，還需要對各種編程語言和流行的技術有一定的見解。
確定好技術棧和設計好界面后，程序員上場！程序員分多種： web前端程序員（做網頁設計，根據設計師畫出的精美圖片和產品經理的原型圖制作出精美的網頁） web后端程序員（主要對數據進行邏輯處理，把結果傳給前端程序員或者數據庫，相當於廚師把菜、肉傳給服務員（前端），前端程序員把肉、菜端給客戶品嘗） 手機端程序員（與web前端程序員類似，傳菜和裝修飯店，工作場地是安卓系統和IOS系統） 特殊方向程序員（高端方向：大數據、區塊鏈、人工智能、機器學習、復雜網絡，設計高級的算法及數學知識）
下一階段：測試，就是找茬！主要工作是檢查程序員寫的程序有沒有bug,一般畫風如下：
測試女A:禿頭郭，你這個頁面好像排版不太對呀，這個字體是不是太小了，按鈕是不是太大了！還有你，沒有bug，但是這個結果不對呀，我明明充值了100塊，怎么現在顯示我充值了一萬？
數據庫管理人員（DBA):負責管理數據庫，即相當於負責管理肉、菜類，需要的時候把他交給廚師，一般大公司才有，大多數時候這塊由后端程序員兼任。
運維：主要和服務器打交道，主要的工作是在linux上搭建各種環境，即安裝各種系統和軟件，然后監控各個軟件和硬件的運行狀況，要舉例的話，大概就是負責構建廚房的人吧，讓廚師能愉快地炒菜。
終於，經過開發和測試后，產品上線了，這時候就輪到運營出場了，顧名思義，就是運行和維護這個產品的人，如淘寶里設置開店規則，設計各種活動的，發放優惠券的，調節客戶和賣家的矛盾的。
結合課堂所學與老師所講，老師剛好布置了作業，順便整理了軟件工程與建模相關知識，十張圖為中心。以后隨着知識體系不斷健全，將不斷完善，歡迎指出問題。
參考教材：軟件工程導論（第6版）清華大學出版社
軟件工程與建模 西安交通大學出版社