來源:https://blog.csdn.net/Rong_Toa/article/details/80771976 程序員
軟件危機是指在計算機軟件的開發和維護過程當中所遇到的一系列嚴重問題。這些問題表如今如下幾個方面:算法
(1)用戶對開發出的軟件很難滿意。 (2)軟件產品的質量每每靠不住。 (3)通常軟件很難維護。 (4)軟件生產效率很低。 (5)軟件開發成本愈來愈大。 (6)軟件成本與開發進度難以估計。 (7)軟件技術的發展遠遠知足不了計算機應用的普及與深刻的須要。數據庫
(1)開發人員方面,對軟件產品缺少正確認識,沒有真正理解軟件產品是一個完整的配置組成。形成開發中制定計劃盲目、編程草率,不考慮維護工做的必要性。 (2)軟件自己方面,對於計算機系統來講,軟件是邏輯部件,軟件開發過程沒有統一的、公認的方法論和規範指導,形成軟件維護困難。 (3)尤爲是隨着軟件規模愈來愈大,複雜程度愈來愈高,原有軟件開發方式效率不高、質量不能保證、成本太高、研製週期不易估計、維護困難等一系列問題更爲突出,技術的發展已經遠遠不能適應社會需求。編程
(1)充分吸取和借鑑人類長期以來從事各類工程項目中積累的行之有效的有效原理、概念、技術與方法,特別是吸收幾十年來人類從事計算機硬件研究和開發的經驗教訓。在開發軟件的過程當中努力做到良好的組織,嚴格的管理,相互友好的協做。 (2)推廣在實踐中總結出來的開發軟件的成功的技術和方法,並研究更好、更有效的技術和方法,儘快克服在計算機系統早期發展階段造成的一些錯誤概念和做法。 (3)根據不一樣的應用領域,開發更好的軟件工具並使用這些工具。將軟件開發各個階段使用的軟件工具集合成一個總體,造成一個很好的軟件開發支環環境。 總之爲了解決軟件危機,既要有技術措施(方法和工具),又要有必要的組織管理措施。數組
應用程序、系統程序、面向用戶的文檔資料和麪向開發者的文檔資料。安全
軟件生存週期是指從軟件定義、開發、使用、維護到淘汰的全過程。(軟件定義、軟件開發、軟件維護)數據結構
(1)任何一個階段的具體任務不只獨立,並且簡單,便於不一樣人員分工協做, 從而下降整個軟件開發工做的困難程度。 (2)能夠下降每一個階段任務的複雜程度,簡化不一樣階段的聯繫,有利於工程的組織管理,也便於採用良好的技術方法。 (3)使軟件開發的全過程以一種有條不紊的方式進行,保證軟件的質量,特別是提升了軟件的可維護性。框架
(1)每個階段的任務儘量獨立; (2)同一階段內的任務性質儘量相同; (3)每個階段任務的開始和結束有嚴格的標準。編輯器
瀑布型開發方法是按照軟件生存週期的劃分依次實施,每個階段有明確規定的任務。分佈式
(1)各個階段的順序性和依賴性; (2)劃分邏輯設計與物理設計,儘量推遲程序的物理實現; (3)每一個階段必須完成規定的文檔,對其中問題經過複審及早發現,及早解決。
(1)從部分需求出發,先創建一個不徹底的系統,經過測試運行該系統取得經驗和信息反饋,加深對軟件需求的理解,進一步使系統擴充和完善。如此反覆, 直至軟件人員和用戶對所設計完成的軟件系統滿意爲止。 (2)在漸增型開發下的軟件是隨軟件開發的過程而逐漸造成的。 (3)漸增型開發方法適合於知識型軟件的開發,設計系統時對用戶需求的認識開始不是很清楚的,須要在開發過程當中不斷認識、不斷得到新的知識去豐富和完善系統。多數研究性質的試驗軟件,通常採用此方法。
(1)從軟件需求的形式化規格說明出發,通過一系列的程序變換,獲得最終的程序系統。 (2)該方法必須有嚴格的數學理論和形式化技術的支持。
軟件工程是指導計算機軟件開發和維護的工程學科。 (1)它採用工程的概念、原理、技術和方法來開發和維護軟件; (2)它將管理技術與當前通過時間考驗的而證實是正確的技術方法結合起來; (3)它強調使用生存週期方法學和結構分析和結構技術; (4)通過人們長期的努力和探索,圍繞着實現軟件優質高產這個目標,從技術到管理兩個方面作了大量的努力,逐漸造成了"軟件工程學"這一新的學科。
方法與工具的結合,加上配套的軟、硬件支持稱爲軟件工程環境。它能支持開發者按照軟件工程的方法,全面完成生存週期中的各項任務。
問題定義的任務:將用戶提出的要求具體化、定量化;肯定研製系統的範圍,明確研製的邊界。
問題定義階段的工做:
(1)經過調查研究,瞭解系統需求; (2)肯定系統的功能需求、性能需求、可靠性需求、安全及保密性、資源、 開發費用及開發進度等的需求; (3)問題定義階段的產品--系統目標與範圍說明書。
肯定在問題定義中所提出的問題是否值得去解,在限制條件下,問題可否解決。
(1)進一步分析和澄清問題的定義,在澄清問題的基礎上,導出系統的邏輯模型; (2)從系統邏輯模型中,選擇問題的若干種主要解法,研究每一種解法的可行性,爲之後的行動提出建議; (3)若是問題沒有可行的解,建議中止系統開發;若是問題有可行的解, 應該推薦一個較好的解決方案,併爲工程制定一個初步的計劃。
(1)技術可行性:現有技術可否實現本系統,現有技術人員可否勝任,開發系統的資源可否知足; (2)經濟可行性:經濟效益是否超出開發成本; (3)操做可行性:系統操做在用戶內部行得通嗎? (4)法律可行性:新系統開發是否會侵犯他人、集體或國家利益,是否違反國家法律。
(1)複查系統的規模和目標; (2)研究目前正在使用的系統,總結現有系統的優劣,提出新系統的雛形; (3)導出新系統的高層邏輯模型; (4)推薦建議方案; (5)推薦行動方針; (6)書寫計劃任務書(可行性報告); (7)提交審查。
可行性分析的結果是可行性研究報告,內容包括:
(1)系統概述:說明開發的系統名稱,提出單位和開發單位。 (2)可行性研究的前提:系統目標;要求;約束和限制;可行性研究的基本準則等。 (3)對現有系統的分析:處理流程,圖示說明現有系統的處理流程和數據流程;現有系統存在的問題。 (4)系統需求:主要功能;主要性能及其要求;操做要求;信息要求;限制性要求。 (5)建議系統:系統目標;處理流程;系統結構,功能,性能;系統技術可行性;投資和效益分析;操做可行性;法律可行性。 (6)其它可選方案:與國內外同類型方案的比較;提出一兩個可行性方案供論證和探討。 (7)制定下一階段的預算。 (8)結論性意見:由用戶方、設計方和投資方共同簽署意見。
有數據流圖、數據字典、斷定表、斷定樹、結構化天然語言、層次方框圖、Warnier圖、IPO 圖和需求描述語言等。
準肯定義將來系統的目標,肯定爲了知足用戶的須要系統必須作什麼。
創建目標系統的邏輯模型的過程也就是數據流圖的分解過程。
結構化分析:使用數據流程圖、數據字典、結構化英語、斷定表和斷定樹等工具, 來創建一種新的、稱爲結構化說明書的目標文檔-需求規格說明書。 結構化體如今將軟件系統抽象爲一系列的邏輯加工單元,各單元之間以數據流發生關聯。
(1)引言:編寫目的、背景說明、術語定義及參考資料等。 (2)概述主要功能、約束條件或特殊需求。 (3)數據流圖與數據字典。 (4)用戶接口、硬件接口及軟件接口。 (5)性能需求、屬性等。 (6)其它需求,如數據庫、操做及故障處理等。
畫分層的 DFD 要遵循哪些原則:
(1)父圖與子圖之間數據要平衡。 (2)分解的深度和層次達到使加工足夠簡單、易於理解的基本加工爲止。 (3)區分局部文件和局部外部項(侷限於數據流中某一層或某幾層的文件和外部項)。 (4)不要把控制流做爲數據流。 (5)忽略瑣碎的枝節。 (6)每一個數據流要有一個合適的名字,儘可能使用現實系統中有具體意義的名字。
系統流程圖描述系統物理模型的工具,數據流程圖描述系統邏輯模型的工具。系統流程圖從系統功能的角度抽象的描述系統的各個部分及其相互之間信息流動的狀況。 數據流程圖從數據傳送和加工的角度抽象的描述信息在系統中的流動和數據處理的工做情況。
數據字典是描述數據流圖中數據的信息的集合。它對數據流圖上每個成分: 數據項、文件(數據結構)、數據流、數據存儲、加工和外部項等給以定義和說明; 它主要由數據流描述、加工描述和文件描述三部分組成。對用戶來說,數據字典爲他們提供了數據的明肯定義;對系統分析員來說,數據字典幫助他們比較容易修改已創建的系統邏輯模型。
有決策樹(又稱斷定樹)、決策表(又稱判斷表)和結構化語言等。
(1)若是是分房申請,則根據申請者的狀況(年齡、工齡、職稱、職務、家庭人口等)計算其分數,當分數高於閥值分數時,按分數高低將申請單插到分房隊列的適當位置。在進行分房時,從空房文件中讀出空房信息,如房號、面積、等級、單位面積房租等,把好房優先分給排在分房隊列前面的符合該等級房條件的申請者;從空房文件中刪掉這個房號的信息,並從分房隊列中刪掉該申請單,再把此房號的信息和住戶信息一塊兒寫到住房文件中,輸出住房分配單給住戶,同時計算房租,並將算出的房租寫到房租文件中。 (2)若是是退房申請,則從住房文件和房租文件中刪除有關信息,再把此房號的信息寫到空房文件中。 (3)若是是調房申請,則根據申請者的狀況肯定其住房等級,而後在空房文件中查找屬於該等級的空房,退掉原住房,再進行與分房相似的處理。 (4)住戶能夠向系統查詢目前分房的閥值分數,居住某類房屋的條件,某房號的單位面積及房租等信息。房產科能夠要求系統打印住房狀況的統計表,或更改某類房屋的居住條件、單位面積和房租等。 用數據流圖描繪該系統的功能需求;在數據字典中給出主要的數據流、文件和加工說明。
系統設計包括整體設計與詳細設計兩個階段。
整體設計的主要任務是完成軟件結構的設計,肯定系統的模塊及其模塊之間的關係。
模塊是數聽說明、可執行語句等程序對象的集合,能夠單獨命名且可經過名字來訪問。 模塊具備輸入和輸出(參數傳遞)、功能、內部數據結構(局部變量)和程序代碼四個特性。 概要設計主要考慮輸入、輸出(參數傳遞)和功能兩個特性。
模塊化是按規定的原則將一個大型軟件劃分爲一個個較小的、相對獨立但又相關的模塊。
模塊設計的準則:
(1)改進軟件結構, 提升模塊獨立性:在對初步模塊進行合併、分解和移動的分析、精化過程當中力求提升模塊的內聚,下降藕合。 (2)模塊大小要適中:大約 50 行語句的代碼,過大的模塊應分解以提升理解性和可維護性;太小的模塊,合併到上級模塊中。 (3)軟件結構圖的深度、寬度、扇入和扇出要適當。通常模塊的調用個數不要超過 5 個。 (4)儘可能下降模塊接口的複雜程度; (5)設計單入口、單出口的模塊。 (6)模塊的做用域應在控制域以內。
變換型結構由三部分組成:傳入路徑、變換(加工)中心和傳出路徑。
(1)區分傳入、傳出和變換中心三部分,劃分 DFD 圖的分界線; (2)完成第一級分解:創建初始 SC 圖的框架; (3)完成第二級分解:分解 SC 圖的各個分支; (4)對初始結構圖按照設計準則進行精化與改進。
事務型結構由至少一條接受路徑、一個事務中心與若干條動做路徑組成。
(1)在 DFD 圖中肯定事務中心、接收部分(包含所有接收路徑)和發送部分 (包含所有動做路徑); (2)畫出 SC 圖框架,把 DFD 圖的三部分分?quot;映射"爲事務控制模塊,接收模塊和動做發送模塊.通常獲得 SC 圖的頂層和第一層(若是第一層簡單能夠併入頂層); (3)分解和細化接收分支和動做分支,完成初始的 SC 圖; (4)對初始結構圖按照設計準則進行精化與改進。
(1)層次方框圖描繪數據的層次結構, 結構圖描繪的是軟件結構。 (2)兩者都採用多層次矩形框樹形結構。層次方框圖的頂層矩形框表明完整的數據結構, 下面各層矩形框依次表明上個框數據的子集;結構圖是在層次圖的每個方框內註明模塊的名字或主要功能,方框之間的直線表示模塊的調用關係,用帶註解的箭頭表示模塊調用過程當中傳遞的信息。
(1)業務分類處理:系統首先根據儲戶所填的存/取款單,肯定本次業務的性質,並將存/取款單和存摺交下一步處理; (2)存款處理:系統將存款單上的存款金額分別記錄在存摺和賬目文件中,並將現金存入現金庫;最後將存摺還給儲戶; (3)取款處理:系統將取款單上的取款金額分別記錄在存摺和賬目文件中,並從現金庫提取現金;最後將現金和存摺還給儲戶。
爲軟件結構圖(SC 圖或 HC 圖)中的每個模塊肯定採用的算法和塊內數據結構, 用某種選定的表達工具給出清晰的描述.
編寫軟件的「詳細設計說明書」.軟件人員要完成的工做:
(1)爲每個模塊肯定採用的算法, 選擇某種適當的工具表達算法的過程,寫出模塊的詳細過程描述. (2)肯定每一模塊使用的數據結構. (3)肯定模塊結構的細節,包括對系統外部的接口和用戶界面,對系統內部其它模塊的接口,以及關於模塊輸入數據、輸出數據及局部數據的所有細節. (4)爲每個模塊設計出一組測試用例,以便在編碼階段對模塊代碼(即程序) 進行預約的測試.
在詳細設計中全部模塊都使用單入口、單出口的順序、選擇、循環三種基本控制結構.
(1)遵照結構程序設計「由頂向下」逐步細化的原則,並以其爲共同的基礎; (2)均服從「程序結構必須適應問題結構」的基本原則,各自擁有從問題結構 (包括數據結構)導出程序結構的一組映射規則。
(1)面向數據流的設計以數據流圖爲基礎,在分析階段用 DFD 表示軟件的邏輯模型,在設計階段按數據流類型,將數據流圖轉換爲軟件結構。面向數據結構的設計以數據結構爲基礎,從問題的數據結構出發導出它的程序結構。 (2)面向數據流的設計的最終目標是軟件的最終 SC 圖,面向數據結構的設計的最終目標是程序的過程性描述。
Jackson 與 LCP 設計方法都是以數據結構爲出發點,以程序的過程描述爲最終目標,設計步驟基本類似。它們的主要差異是:
(1)使用不一樣的表達工具,其中 LCP 方法中的表達工具 Warnier 圖比 Jackson 設計方法中的表達工具 Jackson 圖有更大的通用性; (2)Jackson 方法的步驟和指導原則有必定的靈活性,而 LCP 設計方法則更加嚴密。
不管哪類描述工具不只要具備描述設計過程,如控制流程、處理功能、數據組織及其它方面的細節的能力,並且在編碼階段可以直接將它翻譯爲用程序設計語言書寫的源程序。
使用選定的程序設計語言,把模塊的過程性描述翻譯爲用語言書寫的源程序(源代碼)。
源程序要求:正確可靠、簡明清晰、效率高。
(1)源程序的正確性是對程序質量的最基本要求; (2)源程序的簡明清晰,便於驗證源代碼和模塊規格說明的一致性,容易進行測試和維護; (3)對於大多數模塊,編碼時應該把簡明清晰放在第一位; (4)除了編碼階段產生源代碼外,在測試階段也須要編寫一些測試程序,用於對軟件的測試。
(1)名字說明:程序中使用對象的名字,能爲編譯程序所檢查和識別; (2)類型說明:定義對象的類型,肯定該對象的使用方式; (3)初始化:爲變量提供適當的初始值或由系統給變量賦一特殊的代表未初始化的值; (4)對象的局部性:程序中真正須要的那部分才能訪問的對象; (5)程序模塊:控制程序對象的名字; (6)循環控制結構:如 FOR 語句、WHILE-DO 語句、REPEAT-UNTIL 語句等; (7)分支控制結構:如 IF 語句、CASE 語句等; (8)異常處理:爲程序運行過程當中發生的錯誤和意外事件提供檢測和處理上的幫助; (9)獨立編譯:能分別編譯各個程序單元。
(1)選擇用戶熟悉、便於用戶維護的語言。 (2)選擇目標系統的環境中能夠提供的編譯程序所能選用的語言。 (3)選擇能夠獲得的軟件工具,能支持程序開發中能夠利用的語言。 (4)根據工程規模的大小、目標系統應用範圍,如實時應用選擇 Ada 語言或彙編語言,系統軟件開發選擇 C 語言或彙編語言,軟件開發中若含有大量數據操做則選擇 SQL、dBASE 等數據庫語言等。 (5)選擇程序員熟悉的語言。 (6)選擇標準化程度高、程序可移植性好的語言。 (7)根據算法與計算的複雜性、數據結構的複雜性選擇。如對於系統程序和結構複雜的應用程序,選擇支持數組、記錄(或結構)與指針動態數據結構的Pascal 語言或 C 語言。 (8)根據實時要求系統須要的響應速度和效率選擇相應的語言。
(1)源程序:包括適當的標識符、適當的註解、程序清單的合理佈局與清晰; (2)數聽說明:數據結構或數據類型的說明次序標準化;變量名稱儘可能有意義;對複雜的數據結構在註解中要說明在程序設計中實現這個數據結構的方法。 (3)語句的構造簡單明瞭:不要爲節省空間將多個語句寫在同一行;儘可能避免複雜的條件及「非」條件的測試;避免大量使用循環嵌套和條件嵌套;括號的使用是爲了使邏輯表達式和算術表達式的運算順序清晰直觀。 (4)效率:考慮程序運行的時間存儲器效率、輸入/輸出的效率;在處理程序正確性、清晰與效率之間的關係時先求程序正確後求快;先求清楚後求快;保持程序簡單以求快;書寫清楚,不爲「效率」犧牲清晰。
(1)具備很強的數據管理能力,能對數據庫進行有效的存取、查詢和其它有關操做; (2)能提供一組高效的、非過程化的命令,組成語言的基本語句,編程時用戶只需用這些命令說明「作什麼」,沒必要描述實現的細節; (3)能知足多功能、一體化的要求。爲此,語言中除必須含有控制程序邏輯與實現數據庫操做的語句外,還應包括生成與處理報表、表格、圖形,以及實現數據運算和分析統計功能的各類語句,共同構成一個一體化的語言,以適應多種應用開發的須要。
軟件測試是按照特定的規則,發現軟件錯誤的過程;好的測試方案是儘量發現迄今尚 未發現錯誤的測試;成功的測試方案是發現迄今還沒有發現錯誤的測試;
(1)測試從一個側面證實程序員的失敗;調試證實程序員的正確; (2)測試從已知條件開始,使用預先定義的程序,且有預知的結果,不可預見的僅是程序是否經過測試;調試從不可知內部條件開始,除統計性調試外,結果是不可預見的; (3)測試有計劃而且要進行測試設計;調試不受時間約束; (4)測試是發現錯誤、改正錯誤、從新測試的過程;調試是一個推理的過程; (5)測試執行是有規程的;調試執行要求程序員進行必要的推理; (6)測試由獨立的測試組在不瞭解軟件設計的件下完成;調試由瞭解詳細設計的程序員完成; (7)大多數測試的執行和設計可由工具支持;調試用的工具主要是調試器。
人工複審的方式:代碼會審、走查和排練和辦公桌檢查; 人工複審的做用:檢查程序的靜態錯誤。
黑盒測試也稱爲功能測試,它着眼於程序的外部特徵,而不考慮程序的內部邏輯結構。測試者把被測程序當作一個黑盒,不用關心程序的內部結構。黑盒測試是在程序接口處進行測試,它只檢查程序功能是否能按照規格說明書的規定正常使用,程序是否能適當地接收輸入數據產生正確的輸出信息,而且保持外部信息(如數據庫或文件)的完整性。 黑盒測試主要採用的技術有:等價分類法、邊沿值分析法、錯誤推測法和因果圖等技術。
測試者瞭解被測程序的內部結構和處理過程,對程序的全部邏輯路徑進行測試,在不一樣點檢查程序狀態,肯定實際狀態與預期狀態是否一致。 白盒測試主要採用的技術有:路徑測試技術和事務處理流程技術,對包含有大量邏輯判斷或條件組合的程序採用基於邏輯的測試技術。
斷定覆蓋:使被測程序中的每個分支至少執行一次。故也稱爲分支覆蓋。條件覆蓋:執行全部可能的穿過程序的控制路流程。 條件組合測試:設計足夠的測試用例,使每一個斷定中的全部可能條件取值組合至少執行一次。
(1)爲每一個等價類編號; (2)設計一個新的測試方案,以儘量多的覆蓋還沒有被覆蓋的有效等價類,重複這一步驟,直到全部有效等價類被覆蓋爲止。 (3)設計一個新的測試方案,使它覆蓋一個還沒有被覆蓋的無效等價類, 重複這一步驟,直到全部無效等價類被覆蓋爲止。
單元測試、子系統測試、系統測試、驗收測試、平行測試。
非漸增式測試方式:分別測試模塊,再把全部模塊按設計要求放在一塊兒組成所要的程序。該方法編寫測試軟件工做量大,模塊間的接口錯誤發現得晚,錯誤定位較難診斷,整體測試有的錯誤容易漏掉,測試時間相對較少,能夠並行測試全部模塊,能充分利用人力,加快工程進度。。 漸增式測試方式:把下一個要測試的模塊,同已經測試好的那些模塊結合起來進行測試。該方法利用已測試過的模塊做測試軟件,開銷小,較早發現模塊間的接口錯誤,錯誤定位每每和最近入的模塊相關,對已測試好的模塊可在新加入模塊的條件下受到新的檢驗,測試更完全,須要較多的測試時間,不能並行測試。 總的來講,漸增式測試方法比較好。
(1)在任何狀況下都應使用邊界值分析的方法。 (2)必要時用等價類劃分法補充測試方案。 (3)必要時再用錯誤推測法補充測試方案。 (4)對照程序邏輯,檢查已設計出的測試方案。 (5)根據對程序可靠性的要求採用不一樣的邏輯覆蓋標準,再補充一些測試方案。二.某電力公司有 A、B、C、D 共四類收費標準,並規定,居民用電每個月 200 度如下按 A類收費, 200 度以上按 B 類收費。動力電以每個月 1 萬度爲分界,非高峯用電不足 1 萬度按 B 類收費,達到或超過 1 萬度按 C 類收費。高峯用電不足 1 萬度按 C 類收費,達到或超過 1 萬度按 D 類收費。試用基於邏輯的測試方法爲它設計足夠的測試用例實現條件組合的徹底覆概。
由於軟件的開發過程當中,通常很難檢測到全部的錯誤,其次軟件在應用過程當中須要隨用戶新的要求或運行環境的變化而進行軟件的修改或完成功能的增刪等,爲了提升軟件的應用水平和使用壽命,軟件的維護是不可避免的。
改正性維護:知足用戶對已開發產品的性能與運行環境不斷提升的要求,進而達到延長軟件壽命的目的。 適應性維護:對程序使用期間發現的程序錯誤進行診斷和改正的過程,配合變化了的環境進行修改軟件的活動; 完善性維護:知足用戶在使用過程當中提出增長新的功能或修改已有功能的建議而進行的工做; 預防性維護:爲了改善將來的可維護性或可靠性而修改軟件的工做。
開發方法:採用模塊化詳細設計文檔有助於理解軟件的結構、界面功能和內部流程;開發過程當中嚴格而科學的管理規劃及清晰可靠的文檔資料對發生錯誤後的理解與糾錯是相當重要的;開發過程當中模塊的獨立程度越高,對軟件修改越容易,對軟件的改進和移植越方便。 開發條件:軟件開發及維護人員的水平決定了軟件開發的質量和維護的效率;開發過程當中使用標準的程序設計語言和標準的操做系統接口,能夠大大提升軟件的可維護性;在測試過程當中用例的有效性,可極大地減小軟件存在的錯誤; 其次使用規範化的文檔資料可爲維護提供更好的依據。
(1)通常來說,維護人員對開發人員寫的程序及文檔,理解都比較困難,對維護工做不會喜歡; (2)維護持續時間都很長,在開發人員不在現場的輕快下,維護軟件一般是很困難的; (3)絕大多數軟件在設計時對未來的軟件修改都沒有考慮或考慮很少,尤爲未能在設計中強調並認真解決好模塊的獨立性,使軟件的修改既困難又易發生差錯。
(1)軟件的可理解性、可測試性、可修改性; (2)文檔描述符合要求、用戶文檔簡潔明確、系統文檔完整而且標準。
在軟件的生命週期中,軟件維護的工做量很是大,不一樣應用領域的維護成本差異也很大。通常大型軟件的維護成本遠遠高於開發成本若干倍。所以軟件價格中應該計入維護成本。
(1)教材銷售採購系統; (2)圖書管理系統; (3)房產管理系統。
(1)費用管理: 對軟件開發進行成本覈算,使軟件生產按照商品生產的規律辦事。包括:以簡單、科學方法估算軟件開發費用,做爲簽訂開發合同的根據;管理開發費用的有效使用,即用經濟手段來保證產品如期按質完成。 (2)質量管理: 按項目的質量保證計劃,確保各個開發階段的開發和維護工做所有按軟件工程的規範進行,保證軟件產品的質量。 (3)配置管理:經過對於程序、文檔和數據的各類版本所進行的管理,保證資料的完整性與一致性。 (4)項目管理:制定《項目實施計劃》,按照計劃的內容組織和實施軟件的工程化生產。最終目標是以合理的費用和進度,圓滿完成計劃所規定的軟件項目。
(1)軟件項目與其餘任何產業項目不一樣,它是算法、思想、概念、組織、流程、效率、優化等的融合體; (2)開發軟件項目產品,在多數狀況下,用戶給不出明確的想法和要求。 (3)在開發過程當中,程序及其相關的文檔資料經常須要修改,在修改過程當中又可能帶來新的問題,且這些問題要在好久之後纔會發現。 (4)在研製開發過程當中,文檔資料是不可缺乏的,但工做量又是巨大的,每每也是人們不肯去做的。 (5)參加軟件項目的工做人員,要求具備必定的業務水平和實際工做經驗, 而很難徹底避免的人員流動,對工做的影響是很大的。離開的人員不只帶走了重要的信息,並且帶走了工做經驗。
自頂向下估計: 首先估算出項目總的開發成本,而後在項目內部進行成本分配。由少數專家參與,依靠他們過去的經驗,將要開發的軟件與過去開發過的軟件進行"類比",以估計新的軟件開發所須要的工做量和成本。 自底向上估計: 將開發任務分紅若干子任務,子任務又分紅子子任務,直到每個單元內容足夠明確爲止;把各個任務單元的成本估計出來,匯合成項目的總成本。該方法獲得的結果比較接近實際。
大量軟件開發實踐說明:向一個已經延遲的項目追加開發人員,可能使它完成得更晚。由於當開發人員以算術級數增加時,而人員之間的通訊將以幾何級數增加,每每"得不償失"。
(1)產品運行:正確性、風險性、效率、完整性、健壯性和可用性; (2)產品修改:可理解性、可維護性、靈活性、可測試性; (3)產品轉移:可移植性、可重用性和互運行性。
軟件工具是指爲支持計算機軟件及其文檔的開發、維護、模擬、移植或管理而研製的程序系統。按照軟件生存週期可將其分爲以下幾類:
(1)需求分析:如數據流圖繪製與分析工具、狀態轉換圖繪製與分析工具、 面向對象的模型和分析工具、快速原型構造工具、數據字典與數據庫工具等。 (2)軟件設計:如 HIPO 圖、PDL(程序設計語言)或 PAD(問題分析圖)支持工具等。 (3)編碼:集成化的程序員工做平臺。如各類正文編輯器和常規的編譯程序、 彙編程序、連結程序及符號調試器等。 (4)軟件測試:如靜態分析器、動態覆蓋率測試器、測試用例生成器、測試報告生成器及環境模擬器等。 (5)軟件維護:如反彙編程序、反編譯程序、程序結構分析器、源程序格式化工具、文檔生成工具、源程序至 PAD(問題分析圖)或流程圖的自動轉換工具等。
(1)易用性:友好的用戶界面,用戶樂於使用; (2)對開發方法的支持:能知足預期的任務和功能需求,且能支持完成該任務所遵循的方法學; (3)穩健性:具有自檢測機制,即便在故障狀況下也不會致使嚴重後果; (4)性能:能使資源獲得充分有效的利用; (5)工具結構柔性:工具結構是柔軟的、可修改的和可擴充的。
將一組相關的軟件工具按照必定的軟件開發方法、軟件生產和維護模型有機的組合起來,爲特定的領域所使用,以支持從需求分析、設計、編碼、測試直到維護的整個軟件生命週期的計算機輔輔助開發程序系統稱爲軟件開發環境。 按技術發展方向軟件開發環境可分爲以語言爲中心的環境、面向結構化的環境和工具箱環境。
(1)在某種 OS 基礎上經過一組小的實用工具構成; (2)雖然各工具之間相互獨立,但系統能提供統一的用戶命令界面及工具之間統一的數據交換方式; (3)工具箱中各工具之間是相互獨立的,用戶可根據須要進行靈活的增長和裁減; (4)工具箱環境中通常除了包括支持編碼階段的工具(如編輯程序、編譯程序、彙編程序、連結程序調試程序等)外,還可包括支持大型軟件開發方面的工具; (5)因爲工具箱環境具備較強的通用性和靈活性,於是目前商品化的算機繫系統上配置的軟件環境大多屬於這一類。如:UNIX 程序設計環境、及 VAX/VNS SET、PCDE、APCE 等程序設計環境。
軟件開發環境的構成:交互式人機界面、工具集及軟件環境數據庫。 交互式人機界面:人機界面(也稱用戶界面或人機對話)是用戶與計算機系統之間相互交流的中間媒介。 工具集:工具集中軟件工具是構成軟件開發環境的基本成分。包含在軟件開發環境中的工具不是各自封閉和分離的,而是與某種軟件開發方法或某種軟件加工模型相適應,並以一種綜合的、一致的和總體連貫的形態來支持軟件開發的全過程。 軟件環境數據庫:是各個軟件工具之間共享數據及相互連結的統一媒介。
軟件環境數據庫是用於支持軟件項目的大型數據庫;軟件環境數據庫中主要存儲軟件開發過程當中產生的有關產品或半成品的數據及各類項目數據,如源程序、測試數據和各類文檔等,它構成軟件開發和維護過程當中全部項目數據的集中化的存儲設施,是集成化軟件開發環境的核心組成部分,也是各個軟件工具之間共享數據及相互連結的統一媒介。
(1)集成化和相互兼容的工具集; (2)支持項目的管理和控制; (3)支持配置管理; (4)支持多種語言的軟件開發; (5)支持硬件開發; (6)容許宿主機和目標機使用分佈式系統。
CASE 是計算機輔助軟件工程的簡稱。簡單的說,能夠將 CASE 理解爲: CASE= 軟件工程+自動化工具.從狹義角度解釋它是一組工具和方法的結合;從廣義角度解釋它是輔助軟件開發的任何計算機技術;從學術研究角度解釋:它是軟件開發方法、軟件開發管理和軟件工具等方面多年研究和發展的產物;從軟件產業角度解釋它是種類繁多的軟件開發和系統集成的產品和軟件工具的集合。
CASE 工具能夠理解爲除 OS 外的全部軟件工具的總稱。按對軟件過程的支持範圍 CASE 工具分爲三類:一是工具: 支持單個任務;二是工做臺:支持某一軟件過程或一個過程當中的某些活動;三是環境:支持某些軟件過程及相關的大部分活動。
工做臺實現軟件工具集成的方式是經過共享文件、共享倉庫或共享數據結構來集成。