1コンピュータソフトウェア
1.1ソフトウェア
コンピュータソフトウェアは、コンピュータプログラムとドキュメントシステムを指し、プログラムを処理するタスクや処理ルールを計算する記述されています。
1.2ソフトウェアの機能
- 論理エンティティ。
- メンテナンスは、ワークロード。
- ソフトウェア保守プロセスは、副作用を紹介します。
1.3ソフトウェアカテゴリ
1.3.1システムソフトウェア
オペレーティングシステムなどのハードウェア層に最も近いです。
1.3.2サポートソフトウェア
そのような、各種のIDEととしてのソフトウェア開発、ソフトウェアの保守・運用、。
1.3.3アプリケーションソフトウェア
特定の分野で使用されるソフトウェア。
2ソフトウェア言語
要件定義言語、関数型言語、言語設計、プログラミング言語およびドキュメントの言語を含む言語。
2.1要件定義言語
機能要件と非機能要件を含むソフトウェア要件定義を、記述するための言語。典型的な言語PSL。
2.2関数型言語
法令のソフトウェア機能の言語で書かれた、何をすべきか、どのようなソフトウェアのみを記述している。典型的な言語は、言語、Z言語の広いスペクトルを持っています。
2.3デザイン言語
規程の書き込みの言語ソフトウェア設計、ソフトウェア設計の厳格かつ完全な説明である。典型的な言語PDL。
2.4プログラミング言語
すなわち、プログラミング言語、言語はより低いレベルの言語に分け、非手続き型言語手続き型言語、および特定の言語の共通言語、対話型および非対話型の言語の言語、言語言語、配列分布並行することが可能です。
2.5ドキュメントの言語
ソフトウェア書かれた言語は、このようなZ言語として、文書で使用されています。
3ソフトウェア工学
ソフトウェア工学は、信頼性が高く、実際のマシン上で効率的に実行することができ、経済のソフトウェアを入手するためには、健全なエンジニアリングの原則のセットの確立と使用することである。ソフトウェアエンジニアリングは、によると、プロジェクトの管理原則のコンピュータ科学の理論と方法を応用したものです予算とスケジュールのソフトウェア製品エンジニアリングのユーザーの要件を満たすために達成するために、または研究対象として。
ソフトウェア工学の4つの基本原則
4.1適切な開発標準
ソフトウェア開発の持続可能性を確保するために適切な開発標準の選択、および最終ソフトウェア製品は、顧客の需要を満たすために。
4.2適切な設計手法
ソフトウェアの問題のモジュール性、情報隠蔽、ローカリゼーション、一貫性と適応性を検討するために、適切な設計および実装アプローチの使用は、サポートの問題を解決するのに役立ちます。
4.3高品質のエンジニアリングサポート
このような構成管理、品質保証などの高品質なエンジニアリングサポートを提供する必要があります。
4.4効果的なソフトウェアプロジェクト管理
プロジェクト管理ソフトウェアは直接生産性ソフトウェアの組織を改善するために利用可能なリソースの効率的な利用に影響を与えます。
5ソフトウェアのライフサイクル
ソフトウェアのライフサイクルは6つの段階に分かれています。
5.1コンピュータ・システム工学
タスクをエンジニアリングコンピュータシステムを開発するためのソフトウェアと範囲の一般的な要件だけでなく、コンピュータソフトウェアおよび他のシステム要素、コスト見積もりとメイクスケジューリング、および実現可能性の分析との間の関係を決定することです。
5.2要求分析
主な需要分析ソフトウェアは、ソフトウェア要求仕様書を生成し、何をすべきかの問題に対処するソフトウェアの機能、パフォーマンス、データ、インタフェースの要件を決定するために開発されます。
5.3デザイン
行う方法の問題点を解決するために開発されるソフトウェアの設計ソフトウェアは、通常、システム設計と詳細設計に分けることができ、システム設計のタスクは、ソフトウェアシステムのアーキテクチャを設計することで、詳細設計タスクは、さまざまなコンポーネントの実装の詳細を設計することです。
5.4エンコーディング
プログラミング言語を使用してエンコードされました。
5.5テスト
検出し、単体テスト、統合テスト、システムテストと検証テストを含むソフトウェアの欠陥に正しいエラー。
5.6運用・保守
メンテナンス、ソフトウェアの変更中に実行するためのソフトウェアが必要。
6 CMM
CMMは、CMMで、ソフトウェアプロセスは初期レベル、反復レベル、規定されたレベル、管理レベル、最適化レベルを含む5つの成熟度レベルを定義します。
6.1初期の段階
ソフトウェアプロセスの特長は、ほとんどのプロセスは、明確に定義された結果である、さえ混沌、乱れています。
6.2反復
必要な規律を開発するためのコスト、スケジュール、およびプロセスの機能特性を追跡するために、基本的なプロジェクト管理プロセスを確立し、我々はこのプロジェクトで行われた前回の同様のアプリケーションの成功を繰り返すことができます。
6.3定義されたレベル
管理とエンジニアリング活動は、両方のソフトウェアプロセスの文書化されて標準化し、そして組織の標準ソフトウェアプロセスに統合されています。すべてのプロジェクトの開発とソフトウェアを維持するために承認され、仕立ての標準ソフトウェアプロセスを使用します。
6.4管理レベル
ソフトウェアプロセスと製品の品質、ソフトウェアプロセスと製品の収集詳細なメトリックを定量的に理解され、制御されます。
6.5最適化レベル
継続的改善のプロセスを促進するためのフィードバックプロセスと高度な新しいアイデア、新しい技術を定量化します。
7 CMMI
CMMIは、多くの改良と統合プロセスモデルであるシステムは、複数の技術分野及びサポートの分野であり、現代工学の特性やニーズに適応することができる一貫したプロセス改善フレームワークは、プロセスの質と効率を向上させることができ、2 .CMMIがあります表記：連続は、モデルとモデルを上演しました。
7.1段階モデル
構造モデル同様のCMMを上演し、5つの成熟度レベルに分割されます。
7.1.1初期
プロセスの予測不可能性とコントロールの欠如。
管理7.1.2
プロジェクトのプロセスサービス。
定義7.1.3
サービス組織のためのプロセス。
7.1.4定量的管理
プロセスは、メジャーとコントロールを持っています。
7.1.5最適化
集中化とプロセス改善。
7.2連続モデル
連続的なプロセスモデルは、異なるプロセスのドメイン組織がプロセス能力レベルの異なる分野で達成することができ、各ドメインの能力に焦点を当てた。CMMIのプロセス領域は、6つの能力レベルを含め、レベル0~5の数、レベルは、単一のプロセスの能力を示します。どれだけ共通の目標と関連する一般的な方法など、現場レベルを実行するための組織の能力、各能力レベルを意味し、任意の個々のプロセス領域に独立して適用することができます。
7.2.1 CL0
取るかCL1で定義されているすべての目標を達成するために、ドメインに障害が発生した未完成のプロセス。
7.2.2 CL1
実行された、共通の目標は、プロセス領域でサポートされている特定の目標を達成するために、識別出力作業成果物への入力作業成果物を変換することができ、プロセスを識別することです。
7.2.3 CL2
共通の目標に焦点を当てることに成功したプロセスが管理されている制度化することである。プロセスの操作は手順が使用される組織のポリシーに応じて、プロジェクトが働いているすべての人が利用十分に権利があり、計画やプロセスの記述に従うことが報告されていますリソースは、すべてのタスクと作業成果物は、制御および評価を監視しています。
7.2.4 CL3
定義された共通の目標が定義されている制度のプロセスに焦点を当てることである。裁縫プロセスは、組織の標準プロセスのガイドラインに従ってカットを得るために、組織に焦点を当てている、あなたはまた、収集メトリックは、資産やプロセス、および将来のためのプロセスを処理しなければなりません改善に。
7.2.5 CL4
定量的管理、共通の目標を定量的プロセス領域、経営指針として品質と実行上の定量的な目標の確立と利用を改善するために、計測と制御と品質保証を使用して管理することができ、プロセスの制度化に焦点を当てることです。
7.2.6 CL5
最適化された量子効果変更手段の変化と顧客の要求および継続的なプロセス改善計画のドメインに対応するためのプロセス領域を最適化します。
8つのソフトウェアプロセスモデル
また、ソフトウェアをモデル化するために使用されるソフトウェア開発プロセスモデル、すべてのソフトウェア開発プロセス、活動や構造的な枠組みのタスクとして知られています。
8.1滝モデル
1970年、舞台活動上のイベント後の次の段階は、移行を完了ウォーターフォールモデルのステージ上でのソフトウェア製品を開発してしまうために、ソフトウェアライフサイクル活動の固定順与えられ、W.Royceによって提案されたが、完全で活動ですレビューが活動の次の段階を開始することができた後、によって特徴付けられます：
- 入力イベント・アクティビティとして、このフェーズの最後のステージの結果を受けました。
- このフェーズでは、キャンペーンのフェーズの結果に基づいて、活動の実施によって完成されなければなりません。
- この段階の活動を確認します。
- 出力段として、この活動の結果は、次のステージに渡されます。
8.1.1利点
最も広く使用されているモデルでは、まず、ソフトウェア開発の円滑な進行を確保するソフトウェア開発プロジェクトの品質と効率を向上させる上で重要な役割を果たして登場しました。
8.1.2短所
- 明らかに、すべてのユーザーのニーズを記述することは困難、開発プロセスのニーズがありそうな変化にもあります。
- エラーが見つかった場合、順序正しいミスフォールバックし、その結果、前段に戻ります。
- テストは、あなたがソフトウェアを実行することができます見ることができます完了した後までは、問題を修正するコストが膨大である見つけました。
8.2インクリメンタルモデル
ソフトウェア開発プロセスの増分モデルは、時間スタガスケジュール線形配列の複数に分割され、線状配列は以前のバージョンにバージョン変更や追加後に放出され得る各増分バージョンのために生成され、増分リリース処理を繰り返します最終完璧な製品まで。
8.2.1利点
頻繁に将来の増分需要の開発のニーズを変更するためのソフトウェアは、徐々に他に添加することができる技術的なリスクを管理するために計画している可能性があります。
8.2.2短所
部品への損傷を避けるためには良いアーキテクチャの必要性は、モデルを変更することによって、学習に縮退する可能性が全体的に良好な分析を持っているために、システムの構築部品、システムのニーズに追加、またはされています。
8.3プロトタイプモデル
...対象ソフトウェアの選択されたサブセットのプロトタイプがすべての制約を満たす必要はありませんが、目的は迅速かつ安価にステップがあるのプロトタイプを構築することができ、プロトタイプシステムの実行可能なバージョンは、システムの性質を反映することが期待されています。
8.3.1利点
ユーザーと開発者は、プロトタイプに同意のエラー、短縮開発サイクルを短縮し、コスト削減を加速します。
8.3.2短所
最終製品としてのプロトタイプに助長されていません、プロトタイプは単に正確なプロトタイプ設計がより困難、それは部分的または完全に放棄されるだろう、ユーザの要件を定義するために使用建てられた、革新的な開発者に助長されていません。
8.4スパイラルモデル
タスク領域4（4つの象限）内のウォーターフォールモデル制御までの体系的反復結合特性プロトタイプの実装のスパイラルモデルおよび態様、螺旋に沿って外向きに螺旋を回転するリスク分析モデルを増やすことは、ありました次のタスクを実行します。
- 第一象限：リスク分析、選択したプログラムの評価、リスクの特定、明確なリスク。
- 第二象限：計画に、対象ソフトウェアを決定するためには、プロジェクト開発の制限を明確に、実施形態を選択しました。
- 第三象限：クライアント査定、評価および開発作業は、修正案を提案します。
- 第4象限：プロジェクトの実施、ソフトウェア開発の実装、検証の製品。
（出典：HTTPS：//www.itread01.com/content/1544588849.html）
8.4.1利点
簡単にコストを計算するために、柔軟な設計、顧客は常に効果的な相互作用することができ、開発の各段階に参加しています。
8.4.2短所
リスクを特定するために失敗は必然的に重大な損失につながる場合長いサイクルは、リスク評価における豊富な経験と専門知識を必要とします。
8.5噴水モデル
噴水モデルは、オブジェクト指向開発プロセスモデルのサポートである。噴水は、反復および非ギャップのオブジェクト指向特性を具体化します。
8.5.1利点
様々な段階に明らかな境界が存在しない、開発者は、開発時間を節約し、ソフトウェア開発プロジェクトの効率を改善、発展を同期させることができます。
8.5.2短所
それは困難な監査、文書化要求、プロジェクトマネジメントを助長されていません。
8.6コンポーネントベースの開発モデル
パッケージ化されたメンバーに構築するアプリケーションを利用する。メンバーは、社内メンバーに開発され、商業的部材であってもよいです。
8.6.1利点
再利用可能なコンポーネントは、簡単なソフトウェアの生産性を向上させるのに非常に役立つ、保守、およびソフトウェアの品質を向上させ、コストを削減します。
8.6.2短所
100％は、メンバーが使用するのに非常に適していないかもしれないが、構成要素の100％から構成される既存のコンポーネントに基づいて、テストに合格しないことがあり、既存の、品質を確保することが困難である、適切な手段を見出すことは困難です。
8.7形式手法モデル
形式手法は、ソフトウェア開発手法の厳密な数学的根拠に基づいた厳密な数学的言語と法令の機能仕様やデザインの意味記述と、数学的解析と導出を通じて、あいまいさの需要を見つけるのは簡単、完全されており、矛盾、分析モデル、設計モデルと手順を簡単に検証。数学的計算、プログラムコード変換に縮小機能に規程にフォーマルなデザインフォーマルなパーティー、そして正式な設計が可能になるように。
8.7.1利点
数学の精度を向上させ、あいまいさの問題仕様を解決するために数学の言語を証明し、検証ソフトウェアは、ユーザーのニーズを満たすためにプログラムされ、システムが可能となり、視覚的にシミュレーション/実行モデルことを確認するための手段を提供します。
8.7.2短所
詳細に入手しやすい他の技術よりも抽象化のレベルを下げるために正式な方法は、我々は通常、一貫性のあるモデルを修正するために制限され、事前にシステムの境界を決定する必要があるが、それはモデルと一致し、ほとんどの場合には正しくありません。