• 軟件：包含程序、數據及相關文檔
• 軟件工程：涉及到軟件開發、維護、管理等多方面的原理、工具與環境 。最終的目的是開發高質量的軟件。
• 目的：提高軟件生産率、提高軟件質量、降低軟件成本。

文檔作用：

• 提高軟件開發過程的能見度
• 提高開發效率，便于發現錯誤和不一緻性；
• 作為開發人員在一定階段的工作成果和結束标志；
• 記錄開發過程中的有關信息，便于協調以後的軟件、開發、使用和維護；
• 提供對軟件的運行、維護和培訓的有關信息，便于相關人員和用戶之間的協作、交流和了解；
• 便于潛在用戶了解軟件的功能、性能，為選購提供選擇依據。

按軟件生成周期為序來制定的開發模型，适合需求明确的模型，但缺乏靈活性。

在短時間先開發一個很簡易的原型版本。

基于原型模型，對需求缺乏準确認識的情況下，根據用戶使用過程中提出的意見和建議對原型不斷重複改進，缺點是要對用戶要求加以控制。

基于原型模型，把需求先劃分多個模塊，每個模塊可進行增量開發。

适合風險比較大的項目，加入了風險分析。

以用戶需求為基礎，适用于面向對象開發。開發要重複多次。

用例和風險驅動，以架構為中心。

盡可能早地、持續地對有價值的軟件的交付，強調是快速、時效性高，不強調文檔。

自上向下逐層分解。

面向對象分析、設計與實現，适合比較複雜的項目模型。

面向結構的開發方法。

需求不清晰、業務不确定的情況。

• 技術可行性
• 經濟可行性
• 操作可行性

• 功能需求
• 非功能需求
• 設計約束

• 抽象：内聚（模塊内的交互程度）、耦合（模塊間的交互程度），希望高内聚、低耦合；
• 模塊化
• 信息隐蔽
• 模塊獨立

• 功能内聚：最強的内聚，完成一個單一功能；
• 順序内聚：前一個功能的輸出是後一個功能的輸入；
• 通信内聚：所有處理元素集中在一個數據結構的區域上；
• 過程内聚
• 暧時内聚（時間内聚）：同時執行的動作組合在一起
• 邏輯内聚
• 偶然内聚：功能間沒有任何聯系

非直接耦合：模塊間沒有直接關系，模塊間不傳遞任何信息。

一般使用白盒測試（知道内部結構和程序流等）

黑盒測試，按系統設計說明書進行測試。

黑盒測試，檢查軟件的功能、性能和其他特征是否與用戶的需求一緻。

墨盒測試，把軟件放在實際的硬件和網絡環境中進行測試，主要測試軟件的非功能需求和質量屬性是否得到滿足。

• 語句覆蓋：被測程序的每個語句至少執行一次(最弱的覆蓋标準)。
• 判定覆蓋：判定條件(if)至少獲得一次真、假值。
• 條件覆蓋：每個判定語句中的每個邏輯條件的各種可能值至少滿足一次。
• 路徑覆蓋：覆蓋所有可能的程序運行路徑。
• 判定/條件覆蓋：同時滿足判定和條件覆蓋。
• 條件組合覆蓋：……

• 盡早測試、測試應貫穿在開發的各個階段；
• 測試工作應避免由開發者承擔；
• 設計測試方案的時候，不僅要确定輸入數據，還要根據系統功能确定預期的輸出結果；
• 設計測試用例時，要輸入不合理的數據或條件；
• 測試程序中要檢驗程序是否做了該做的事、還要确認不要多做了事情；
• 測試要有計劃，測試計劃、測試用例作為文檔的一部分保存；
• 測試用例精心設計 ，便于重複使用。

• 發現錯誤較多的模塊，在糾正錯誤後，遺留的錯誤也比較多；
• 測試的目的是為了發現錯誤，而不是驗證程序沒有錯誤；
• 通過軟件測試不可能完全發現錯誤；
• 不可能保證程序100%沒問題；
• 測試工作由開發方負責，從需求階段提出；
• 開發時将質量也構建進産品；
• 測試人員與開發人員要密切合作；
• 軟件測試的目的不僅要找出缺陷，還要随時提供質量相關信息。

• 可理解性
• 可測試性
• 可修改性

軟件維護類型：

• 正确性維護：更正程序錯誤。
• 适應性維護：使用軟件适應新技術變化或管理需求變化。
• 預防性維護：為了改進應用軟件的可靠性和可維護性，為了适應未來的軟硬件的變化，主動增加預防性的功能。
• 完善性維護：擴充功能和改善性能。

• 用分階段的生命周期計劃嚴格管理，将複雜問題簡化處理；
• 堅持進行階段評審；
• 嚴格的版本管理；
• 采用現代程序設計技術，但不追求最新技術；
• 審查記錄；
• 開發小組人員少而精；
• 知識管理。

• 正确性
• 可用性
• 可靠性
• 友好性
• 可讀性
• 健壯性：不合理的數據操作可以檢查、糾正、提示；
• 效率
• 可移值性

• 有團隊精神和較強的溝通能力
• 文檔與知識管理
• 版本管理
• 編碼規範
• 測試體系

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!