ソフトウェアのライフサイクル
問題定義：通信するシステムアナリストやユーザーを示し、図外の「ユーザーが問題を解決するために、コンピュータを必要とするもの」とその後について尋ねられ、「システムの目標と範囲、」と確認がユーザーレビューを投稿します
フィージビリティスタディ：一方では、ターゲットシステムがそれを記述するための言語を明確にするために開発されることを、一方で、経済的、技術的、法的及びその他の側面からフィージビリティ・スタディ
分析を必要とする：機能要件とソフトウェアシステムの非機能要件の決定、データ要件分析ソフトウェアシステム、ロジックモデルの輸出システム、修正されたプロジェクトの開発計画を、必要に応じて、プロトタイプシステムを開発
開発段階：デザイン - >実現 - >テスト
メンテナンス：
- 是正メンテナンス：ソフトウェアの納入後、開発とテストの時に完成する予定で、完了していない、エラーの隠された部分が存在しなければならない運用段階にした、特定の環境でこれらの隠されたエラーが公開されます。
- 適応メンテナンスは：することがある環境に適応するソフトウェアの活動を変更し、変更します。
- メンテナンス性の向上：に応じての過程でユーザーが提起したいくつかの建設的な提案を行っメンテナンス活動。
- 予防保全：さらにするために、ソフトウェアシステムの保守性と信頼性の向上、および将来の改善のための基礎を築くために。
統一プロセス（UP）
甲斐初期段階：ライフサイクルの目的
エッセンス段階：ライフサイクルのフレームワーク
構築フェーズ：初期運動機能
移行フェーズ：製品リリース
CMM（能力成熟度モデル）
初期：ソフトウェアプロジェクト管理システムの不備、プロセス定義の欠如、混乱
反復：基本的なプロジェクト管理プロセスと実践の確立は、プロジェクトのコスト、スケジュール、機能を追跡します
すべての項目は、プロセスと保守ソフトウェアの結果の実際の状況に応じて、標準的なソフトウェアを開発するために使用されます。定義されたレベル
レベルの管理：コレクト詳細なソフトウェアプロセスと製品品質のメトリック、理解し、ソフトウェアプロセスの制御と製品メトリックです
最適化：定量化フィードバックと高度な新しいアイデア、新しい技術のプロセスは、継続的な改善プロセスを促進します
CMMI（能力成熟度モデル統合）
未完成级：表明过程域的一个或多个特定目标没有被满足
已执行级：过程通过转化可识别输入工作产品，产生可识别的输出工作产品，关注于过程域的特定目标的完成
已管理级：
过程作为已管理的过程制度化，针对单个过程的实例的能力
已定义级：
过程作为已定义的过程制度化，关注过程的组织级标准化和部署
量化管理级：
过程作为定量管理的过程制度化
优化级：
过程作为优化的过程制度化，表明过程得到很好的执行且持续得到改进
COCOMO
基本COCOMO模型：静态单变量模型，用于对整个软件系统进行估算
中级COCOMO模型：静态多变量模型，将软件系统模型分为系统和部件两个层次
详细COMO模型：将软件系统分为系统、子系统、模块三个层次，除包括中级模型所考虑的因素外，还考虑了在需求分析、软件设计等每一步的成本驱动属性的影响
COCOMOII
应用组装模型：在软件工程的前期阶段使用，这时用户界面的原型开发、对软件和系统交互的考虑、性能的评估以及技术成熟度的评价是最重要的
早期设计阶段模型：在需求已经稳定并且基本的软件体系结构已经建立时使用
体系结构阶段模型：在软件的构造过程中使用
Putnam估算模型：动态多变量，它是假设在软件开发的整个生存周期中工作量有特定的分布
ISO/IEC 9126(软件质量模型)：
由3个层次组成：第一层是质量特性，第二层是质量子特性
特性含义：
其中各六个质量特性与二十七个质量子特性的关系如下表：
耦合
无直接耦合
（最低耦合）：两个模块之间没有直接的关系，它们分别从属于不同模块的控制与调用，它们之间不传递任何信息。因此，模块间的耦合性最弱，模块独立性最高
数据耦合：两个模块之间有调用关系，传递的是简单的
数据值
标记耦合：两个模块之间传递的是数据结构，如果高级语言的数组名，记录名，文件名等这些名字即为标记，其实传递的是这个
数据结构的地址
内容耦合
（最高耦合）：当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部
控制耦合：模块间传递的信息不但有数据，还包括
控制信息
外部耦合：
模块间通过软件之外的环境联结(如I/O将模块耦合到特定的设备、格式、通信协议上)
公共耦合：
通过一个公共数据环境相互作用的那些模块间的耦合
内聚
功能内聚：完成一个
单一功能，各个部分协同工作，缺一不可(最高)
顺序内聚：处理元素相关，而且
必须顺序执行
通信内聚：所有处理元素集中在一个
数据结构的区域上
过程内聚：处理元素相关，而且
必须按特定的次序执行
瞬时内聚：所包含的任务
必须在同一时间间隔执行
逻辑内聚：完成
逻辑上相关的一组任务
偶然内聚：完成一组
没有关系或松散关系的任务（最低）
软件开发模型
瀑布模型：
给出了软件生存周期中制定开发计划、需求分析、软件设计、编码、测试和维护等阶段以及各阶段的固定顺序，上一阶段完成后才能进入到下一阶段，整个过程如同瀑布流水。该模型为软件的开发和维护提供了一种有效的管理模式，但在大量的实践中暴露出其缺点，其中最为突出的是缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。这些问题有可能造成开发出的软件并不是用户真正需要的，并且这一点只有在开发过程完成后才能发现。所以瀑布模型适用于需求明确，且很少发生较大变化的项目。
演化模型（快速原型模型）：
允许在获取了一组基本需求后，通过快速分析构造出软件的一个初始可运行版本(称作原型)，然后根据用户在适用原型的过程中提出的意见对原型进行改进，从而获得原型的新版本。这一过程重复进行，直到得到令用户满意的软件。该模型主要用于对软件需求缺乏准确认识的情况。
螺旋模型：
将瀑布模型和演化模型进行结合，在保持二者优点的同时，增加了风险分析，从而弥补了二者的不足。该模型沿着螺线旋转，并通过笛卡尔坐标的四个象限分别表示四个方面的活动：制定计划、风险分析、实施工程和客户评估。螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险。
喷泉模型：
以面向对象的软件开发方法为基础，以用户需求为动力，以对象来驱动的模型。该模型主要用于描述面向对象的开发过程，体现了面向对象开发过程的迭代和无间隙特性。迭代指模型中的活动通常需要重复多次，相关功能在每次迭代中被加入新的系统。无间隙是指在各开发活动(如分析、设计、编码)之间没有明显边界。
软件开发方法
结构化方法：
面向
数据流、自顶向下、适合数据处理领域的问题、不适合大规模、复杂的项目、难以适应需求的变化
Jackson方法：
面向
数据结构、适合小规模项目、当输入数据结构与输出数据结构没有对应关系时，难以应用此方法
原型化方法：
适合需求不清、业务理论不确定、需求经常变化的情况
Booch方法：
面向
数据结构
冗余附加技术
屏蔽硬件错误的容错技术：
键程序和数据的冗余及调用；
检测、表决、切换、重构和复算的实现。
屏蔽软件错误的容错技术：
冗余备份程序的存储及调用；
实现错误检测和错误恢复的程序；
实现容错软件所需的固化程序。
软件风险
项目风险：项目风险威胁到项目计划，若发生项目风险，就有可能拖延项目的进度和增加项目的成本。项目复杂度、规模及结构不确定性也属于项目风险因素
技术风险：技术风险威胁到开发软件的交付时间。若发生技术风险，开发工作就可能变得很困难或根本不可能。规格说明的歧义性、技术的不确定性、技术陈旧以及前沿技术也是技术风险因素
商业风险：商业风险威胁到开发软件的生存能力
市场风险：开发了一个没有人真正需要的优良产品或系统
策略风险：开发的产品不再符合公司的整体商业策略
销售风险：开发了一个销售部们不知道如何去销售的产品
管理风险：由于重点的转移或人员的变动而失去了高级管理层的支持
预算风险：没有得到预算或人员的保证
Gantt
无法描述任务之间的依赖关系，也无法确定影响进度的关键任务
Pert和CPM
Pert无法描述任务之间的并行关系
