ソフトウェアエンジニアリングの概要

最初に、ソフトウェアエンジニアリングの意味を理解しましょう。この用語は、ソフトウェアとエンジニアリングという2つの単語で構成されています。

ソフトウェア*は単なるプログラムコードではありません。プログラムは実行可能なコードであり、何らかの計算目的に役立ちます。ソフトウェアは、実行可能なプログラミングコード、関連するライブラリ、およびドキュメントのコレクションと見なされます。ソフトウェアは、特定の要件に合わせて作成された場合、*ソフトウェア製品*と呼ばれます。

一方、*エンジニアリング*は、明確に定義された科学的な原則と方法を使用した製品の開発に関するものです。

ソフトウェアエンジニアリング

ソフトウェアエンジニアリング*は、明確に定義された科学的原則、方法、手順を使用したソフトウェア製品の開発に関連するエンジニアリングブランチです。ソフトウェアエンジニアリングの結果は、効率的で信頼性の高いソフトウェア製品です。

定義

IEEEは、ソフトウェアエンジニアリングを次のように定義しています。

'__ （1）ソフトウェアの開発、運用、保守に対する体系的で、規律化された、定量化可能なアプローチの適用。つまり、ソフトウェアへのエンジニアリングの適用です。

（2）上記のようなアプローチの研究。 '__

ドイツのコンピューター科学者であるFritz Bauerは、ソフトウェアエンジニアリングを次のように定義しています。

'_ソフトウェアエンジニアリングは、信頼性が高く、実際のマシンで効率的に動作するソフトウェアを経済的に入手するための、健全なエンジニアリングの原則の確立と使用です。_

ソフトウェアの進化

ソフトウェアエンジニアリングの原則と方法を使用してソフトウェア製品を開発するプロセスは、*ソフトウェアの進化*と呼ばれます。これには、ソフトウェアの初期開発とその保守および更新が含まれます。

ソフトウェアの進化

進化は、要件収集プロセスから始まります。その後、開発者は目的のソフトウェアのプロトタイプを作成し、ソフトウェア製品開発の初期段階でフィードバックを得るためにユーザーに提示します。ユーザーは変更を提案しますが、それにはいくつかの連続した更新とメンテナンスも変更され続けます。このプロセスは、目的のソフトウェアが完成するまで、元のソフトウェアに変更されます。

ユーザーが手元にあるソフトウェアを望んだ後でも、進歩する技術と変化する要件により、ソフトウェア製品はそれに応じて変化します。ソフトウェアをゼロから再作成し、要件に応じて1対1に移行することは現実的ではありません。実行可能で経済的な唯一のソリューションは、既存のソフトウェアを最新の要件に一致するように更新することです。

ソフトウェア進化の法則

リーマンは、ソフトウェアの進化に関する法律を制定しています。彼はソフトウェアを3つの異なるカテゴリーに分けました。

* S-type（static-type）-*これは、定義された[.underline] #specifications and solutions。＃に従って厳密に機能するソフトウェアです。＃ソリューションとそれを達成する方法は、コーディング前にすぐに理解されます。 s-typeソフトウェアは変更の影響を受けにくいため、これが最も簡単です。たとえば、数学計算用の計算プログラム。
* P-type（practical-type）-*これは、[。underline]＃procedures。＃のコレクションを持つソフトウェアです。＃これは、プロシージャが実行できる内容によって正確に定義されます。このソフトウェアでは、仕様を記述できますが、解決策はすぐにはわかりません。たとえば、ゲームソフトウェア。
* E-type（embedded-type）-*このソフトウェアは、実際の[.underline]＃environment。＃の要件として密接に機能します。＃このソフトウェアは、法律、税金などにさまざまな変更があるため、高度に進化しています。現実世界の状況で。たとえば、オンライン取引ソフトウェア。

E-Typeソフトウェアの進化

リーマンは、E-Typeソフトウェアの進化に関して8つの法律を定めています-

継続的な変更- Eタイプのソフトウェアシステムは、現実の世界の変化に適応し続ける必要があります。そうしないと、徐々に有用性が低下します。
複雑さの増加- Eタイプのソフトウェアシステムが進化するにつれて、保守または削減のための作業を行わない限り、その複雑さは増加する傾向があります。
*親しみやすさの保存-*ソフトウェアへの親しみ、またはソフトウェアの開発方法、その特定の方法で開発された理由など。システムの変更を実装するために、いかなるコストでも保持する必要があります。
*継続的な成長-*何らかのビジネス上の問題を解決することを目的としたEタイプシステムの場合、ビジネスのライフスタイルの変化に応じて、変更を実装するサイズが大きくなります。
*品質の低下-*変化する運用環境に厳密に維持され、適応されない限り、Eタイプソフトウェアシステムの品質は低下します。
フィードバックシステム Eタイプソフトウェアシステムは、マルチループ、マルチレベルフィードバックシステムを構成し、正常に変更または改善するには、そのように扱う必要があります。
自己規制- Eタイプのシステム進化プロセスは、製品およびプロセスの測定値が通常に近い状態で自己調整します。
*組織の安定性-*進化するEタイプシステムの平均的な有効なグローバルアクティビティレートは、製品の耐用年数にわたって変化しません。

ソフトウェアのパラダイム

ソフトウェアパラダイムは、ソフトウェアの設計中に行われる方法と手順を指します。現在提案されている多くの方法があり、現在作業中ですが、これらのパラダイムがソフトウェアエンジニアリングのどこに位置するかを確認する必要があります。これらはさまざまなカテゴリに組み合わせることができますが、それぞれが互いに含まれています。

ソフトウェアの進化

プログラミングパラダイムは、ソフトウェア開発パラダイムのサブセットであるソフトウェア設計パラダイムのサブセットです。

ソフトウェア開発パラダイム

このパラダイムは、ソフトウェア開発に関するすべてのエンジニアリング概念が適用されるソフトウェアエンジニアリングパラダイムとして知られています。ソフトウェア製品の構築に役立つさまざまな調査と要件の収集が含まれます。で構成されます–

要件収集
ソフトウェア設計
プログラミング

ソフトウェア設計パラダイム

このパラダイムはソフトウェア開発の一部であり、次のものが含まれます。

設計
メンテナンス
プログラミング

プログラミングのパラダイム

このパラダイムは、ソフトウェア開発のプログラミングの側面と密接に関連しています。これも -

コーディング
テスト
統合

ソフトウェアエンジニアリングの必要性

ユーザーの要件とソフトウェアが動作している環境の変化率が高いため、ソフトウェアエンジニアリングの必要性が生じます。

*大規模なソフトウェア-*ソフトウェアのサイズが大きくなると、家や建物よりも壁を構築するのが簡単になります。
*スケーラビリティ-*ソフトウェアプロセスが科学的および工学的概念に基づいていない場合、既存のソフトウェアをスケーリングするよりも新しいソフトウェアを再作成する方が簡単です。
*コスト-*ハードウェア業界がそのスキルを示し、巨大な製造業がコンピューターと電子ハードウェアの価格を引き下げました。しかし、適切なプロセスが適応されない場合、ソフトウェアのコストは高いままです。
*動的な性質-*ソフトウェアの常に成長し適応する性質は、ユーザーが作業する環境に大きく依存します。ソフトウェアの性質が常に変化している場合、既存の機能を新たに強化する必要があります。これは、ソフトウェアエンジニアリングが重要な役割を果たす場所です。
*品質管理-*ソフトウェア開発のプロセスを改善することで、ソフトウェア製品の品質が向上します。

優れたソフトウェアの特徴

ソフトウェア製品は、それが提供するものとそれがどれだけうまく使用できるかによって判断できます。このソフトウェアは、次の理由で満たす必要があります。

運用中
過渡的
メンテナンス

適切に設計され、細工されたソフトウェアには、次の特性が期待されます。

運用中

これは、ソフトウェアが運用でどれだけうまく機能するかを示しています。以下で測定できます。

予算
使いやすさ
効率
正しさ
機能性
信頼性
セキュリティ
安全性

過渡的

この側面は、ソフトウェアがあるプラットフォームから別のプラットフォームに移動する場合に重要です。

移植性
相互運用性
再利用性
適応性

メンテナンス

この側面では、変化し続ける環境でソフトウェアがそれ自体を維持する能力をどれだけ備えているかについて簡単に説明します。

モジュール性
保守性
柔軟性
スケーラビリティ

要するに、ソフトウェアエンジニアリングはコンピューターサイエンスの一部門であり、効率的で耐久性があり、スケーラブルな予算内および期限内のソフトウェア製品を生産するために必要な明確に定義されたエンジニアリングコンセプトを使用します。

ソフトウェア開発ライフサイクル

ソフトウェア開発ライフサイクル、略してSDLCは、目的のソフトウェア製品を開発するためのソフトウェアエンジニアリングの段階の明確に定義された構造化されたシーケンスです。

SDLCアクティビティ

SDLCは、ソフトウェア製品を効率的に設計および開発するために従うべき一連のステップを提供します。 SDLCフレームワークには次の手順が含まれます。

SDLC

コミュニケーション

これは、ユーザーが目的のソフトウェア製品の要求を開始する最初のステップです。彼はサービスプロバイダーに連絡し、条件の交渉を試みます。彼はサービス提供組織に書面で要求を提出します。

要件の収集

ソフトウェア開発チームがこのステップに進むと、プロジェクトを続行します。チームは、問題領域のさまざまな利害関係者と議論を行い、その要件について可能な限り多くの情報を引き出します。要件は考慮され、ユーザー要件、システム要件、および機能要件に分けられます。要件は、指定されたいくつかのプラクティスを使用して収集されます-

既存または廃止されたシステムおよびソフトウェアの調査、
ユーザーと開発者へのインタビューの実施、
データベースを参照する、または
アンケートから回答を収集します。

実現可能性調査

要件を収集した後、チームはソフトウェアプロセスの大まかな計画を立てます。このステップで、チームは、ユーザーのすべての要件を満たすためにソフトウェアを作成できるかどうか、およびソフトウェアがもはや有用ではなくなる可能性があるかどうかを分析します。プロジェクトが財政的、実際的、技術的に組織にとって実現可能であるかどうかが判明します。開発者がソフトウェアプロジェクトの実現可能性を結論付けるのに役立つ多くのアルゴリズムが利用可能です。

システム分析

このステップで、開発者は計画のロードマップを決定し、プロジェクトに適した最適なソフトウェアモデルを作成しようとします。システム分析には、ソフトウェア製品の制限の理解、システム関連の問題または既存のシステムで事前に行われる変更の学習、プロジェクトが組織や人員に与える影響の特定と対処などが含まれます。プロジェクトチームは、プロジェクトの範囲を分析し、それに応じてスケジュールとリソースを計画します。

ソフトウェア設計

次のステップは、要件と分析に関するすべての知識を机上に持ち込み、ソフトウェア製品を設計することです。ユーザーからの入力および要件収集フェーズで収集された情報は、このステップの入力です。このステップの出力は、2つのデザインの形式で提供されます。論理設計と物理設計。エンジニアは、メタデータおよびデータ辞書、論理図、データフロー図、場合によっては擬似コードを作成します。

コーディング

このステップは、プログラミング段階とも呼ばれます。ソフトウェア設計の実装は、適切なプログラミング言語でプログラムコードを記述し、エラーのない実行可能プログラムを効率的に開発することから始まります。

テスト

推定では、ソフトウェア開発プロセス全体の50％をテストする必要があるとされています。エラーは、ソフトウェアをクリティカルレベルからそれ自体の削除まで破壊する可能性があります。開発者によるコーディング中にソフトウェアテストが行われ、モジュールテスト、プログラムテスト、製品テスト、社内テスト、ユーザー側での製品テストなど、さまざまなレベルのコードのテストエキスパートによって徹底的なテストが行われます。エラーの早期発見とその対策は、信頼できるソフトウェアの鍵です。

統合

ソフトウェアは、ライブラリ、データベース、およびその他のプログラムと統合する必要がある場合があります。 SDLCのこの段階は、ソフトウェアと外界のエンティティとの統合に関係しています。

実装

これは、ユーザーマシンにソフトウェアをインストールすることを意味します。ソフトウェアは、ユーザーエンドでインストール後の構成が必要になる場合があります。ソフトウェアの移植性と適応性がテストされ、実装中に統合関連の問題が解決されます。

操作とメンテナンス

このフェーズでは、より効率的でエラーが少ないという点でソフトウェアの動作を確認します。必要に応じて、ユーザーは、ソフトウェアの操作方法およびソフトウェアの操作性を維持する方法に関するドキュメントのトレーニングを受けるか、ドキュメントの支援を受けます。ソフトウェアは、ユーザーエンド環境またはテクノロジーで行われた変更に従ってコードを更新することにより、タイムリーに維持されます。この段階では、隠れたバグや現実世界の未確認の問題による課題に直面する可能性があります。

配置

時間が経過すると、ソフトウェアはパフォーマンス面で低下する可能性があります。完全に時代遅れになるか、激しいアップグレードが必要になる場合があります。したがって、システムの大部分を排除する緊急の必要性が生じます。このフェーズには、データと必要なソフトウェアコンポーネントのアーカイブ、システムの終了、廃棄アクティビティの計画、および適切なシステム終了時にシステムの終了が含まれます。

ソフトウェア開発パラダイム

ソフトウェア開発パラダイムは、開発者がソフトウェアを開発するための戦略を選択するのに役立ちます。ソフトウェア開発パラダイムには、独自のツール、方法、および手順のセットがあり、それらは明確に表現され、ソフトウェア開発ライフサイクルを定義します。ソフトウェア開発パラダイムまたはプロセスモデルのいくつかは、次のように定義されています。

滝モデル

ウォーターフォールモデルは、ソフトウェア開発パラダイムの最も単純なモデルです。 SDLCのすべての段階が次々と線形に機能するという。つまり、最初のフェーズが終了すると、2番目のフェーズのみが開始されます。

image

このモデルは、すべてが前の段階で計画されたとおりに完全に実行および実行されることを想定しており、次の段階で発生する可能性のある過去の問題について考える必要はありません。前のステップでいくつかの問題が残っている場合、このモデルはスムーズに動作しません。モデルのシーケンシャルな性質により、操作を元に戻したりやり直したりすることはできません。

このモデルは、開発者が過去に同様のソフトウェアをすでに設計および開発しており、そのすべてのドメインを認識している場合に最適です。

反復モデル

このモデルは、反復でソフトウェア開発プロセスをリードします。 SDLCプロセスのすべてのサイクルの後にすべてのステップを繰り返して、周期的に開発プロセスを投影します。

反復モデル

ソフトウェアは最初に非常に小規模に開発され、考慮されるすべてのステップが実行されます。その後、次の反復ごとに、より多くの機能とモジュールが設計、コーディング、テストされ、ソフトウェアに追加されます。すべてのサイクルでソフトウェアが生成されます。ソフトウェアはそれ自体が完全であり、以前のものよりも多くの機能を備えています。

各反復の後、管理チームはリスク管理に取り組み、次の反復に備えることができます。サイクルにはソフトウェアプロセス全体のごく一部が含まれるため、開発プロセスの管理は簡単ですが、より多くのリソースを消費します。

スパイラルモデル

スパイラルモデルは、反復モデルとSDLCモデルの1つを組み合わせたものです。 1つのSDLCモデルを選択し、それを循環プロセス（反復モデル）と組み合わせるかのように見えます。

スパイラルモデル

このモデルはリスクを考慮しますが、これは他のほとんどのモデルでは見過ごされがちです。モデルは、1回の反復の開始時にソフトウェアの目的と制約を決定することから始まります。次のフェーズでは、ソフトウェアのプロトタイプを作成します。これにはリスク分析が含まれます。次に、1つの標準SDLCモデルを使用してソフトウェアを構築します。次の反復の計画の第4段階で準備されます。

V –モデル

ウォーターフォールモデルの主な欠点は、前のステージが終了したときにのみ次のステージに移動することであり、後のステージで問題が見つかった場合に戻ることができませんでした。 V-Modelは、各段階でソフトウェアを逆の方法でテストする手段を提供します。

V-Model

すべての段階で、テスト計画とテストケースが作成され、その段階の要件に従って製品を検証および検証します。たとえば、要件収集段階では、テストチームは要件に対応してすべてのテストケースを準備します。その後、製品が開発され、テストの準備が整ったら、この段階のテストケースで、この段階での要件に対するソフトウェアの有効性を検証します。

これにより、検証と検証の両方が並行して行われます。このモデルは、検証および検証モデルとも呼ばれます。

ビッグバンモデル

このモデルは、その形式で最も単純なモデルです。それには、少しの計画、たくさんのプログラミング、そしてたくさんの資金が必要です。このモデルは、宇宙のビッグバンを中心に概念化されています。科学者が言うように、ビッグバンの後、たくさんの銀河、惑星と星はちょうど出来事として進化した。同様に、多くのプログラミングと資金を集めれば、最高のソフトウェア製品を実現できます。

ビッグバンモデル

このモデルでは、非常に少量の計画が必要です。どのプロセスにも従わないか、顧客が要件や将来のニーズについて確信を持てない場合があります。したがって、入力要件は任意です。

このモデルは、大規模なソフトウェアプロジェクトには適していませんが、学習や実験には適しています。

SDLCとそのさまざまなモデルの詳細については、http：//www.finddevguides.com/sdlc/index [ここをクリックしてください]

ソフトウェアプロジェクト管理

ソフトウェア開発に携わるIT企業の職務パターンは、2つの部分に分かれています。

ソフトウェア作成
ソフトウェアプロジェクト管理

プロジェクトは明確に定義されたタスクであり、目標を達成するために行われたいくつかの操作の集まりです（たとえば、ソフトウェアの開発と配布）。プロジェクトは次のように特徴付けられます。

すべてのプロジェクトには、独自の明確な目標があります。
プロジェクトは、日常的な活動や日常業務ではありません。
プロジェクトには開始時刻と終了時刻があります。
プロジェクトはその目標が達成されたときに終了するため、組織の存続期間における一時的な段階です。
プロジェクトには、時間、人材、資金、材料、知識バンクの面で十分なリソースが必要です。

ソフトウェアプロジェクト

ソフトウェアプロジェクトは、要件の収集からテストとメンテナンスまでのソフトウェア開発の完全な手順であり、目的のソフトウェア製品を実現するために、指定された期間内に実行方法に従って実行されます。

ソフトウェアプロジェクト管理の必要性

ソフトウェアは無形の製品と言われています。ソフトウェア開発は、世界のビジネスにおけるまったく新しい流れの一種であり、ソフトウェア製品の構築に関する経験はほとんどありません。ほとんどのソフトウェア製品は、クライアントの要件に合わせてカスタマイズされています。最も重要なことは、基盤となる技術が頻繁にかつ急速に変化および進歩するため、ある製品の経験が他の製品に適用されない可能性があることです。こうしたビジネス上の制約や環境上の制約はすべて、ソフトウェア開発にリスクをもたらすため、ソフトウェアプロジェクトを効率的に管理することが不可欠です。

Time_Cost_Quality

上の画像は、ソフトウェアプロジェクトの3つの制約を示しています。高品質の製品を提供し、クライアントの予算内でコストを抑え、計画どおりにプロジェクトを実施することは、ソフトウェア組織の重要な部分です。このトリプルコンストレイントライアングルに影響を与える可能性のある内部および外部のいくつかの要因があります。 3つの要因のいずれかが他の2つの要因に深刻な影響を与える可能性があります。

したがって、予算と時間の制約とともにユーザー要件を組み込むには、ソフトウェアプロジェクト管理が不可欠です。

ソフトウェアプロジェクトマネージャー

ソフトウェアプロジェクトマネージャーは、ソフトウェアプロジェクトを実行する責任を負います。ソフトウェアプロジェクトマネージャーは、ソフトウェアが通過するSDLCのすべてのフェーズを完全に認識しています。プロジェクトマネージャーは、最終製品の生産に直接関与することはありませんが、生産に関わる活動を管理および管理します。

プロジェクトマネージャーは、開発プロセスを綿密に監視し、さまざまな計画を準備および実行し、必要かつ適切なリソースを手配し、コスト、予算、リソース、時間、品質、顧客満足度の問題に対処するためにすべてのチームメンバー間のコミュニケーションを維持します。

プロジェクトマネージャーが負う責任をいくつか見てみましょう。

管理人

プロジェクトリーダーとして行動する
利害関係者との連絡
人事管理
レポート階層などの設定

管理プロジェクト

プロジェクト範囲の定義と設定
プロジェクト管理活動の管理
進行状況とパフォーマンスの監視
あらゆる段階でのリスク分析
問題を回避または解決するために必要な措置を講じる
プロジェクトスポークスマンとして行動する

ソフトウェア管理活動

ソフトウェアプロジェクト管理は、プロジェクトの計画、ソフトウェア製品の範囲の決定、さまざまな用語でのコストの見積もり、タスクとイベントのスケジューリング、およびリソース管理を含む多数のアクティビティで構成されます。プロジェクト管理活動には以下が含まれます。

プロジェクト計画
スコープ管理
プロジェクト見積もり

プロジェクト計画

ソフトウェアプロジェクトの計画はタスクであり、ソフトウェアの生産が実際に開始される前に実行されます。ソフトウェア生産のためにありますが、ソフトウェア生産と方向性のある具体的な活動は一切含まれていません。むしろ、ソフトウェアの生産を促進する複数のプロセスのセットです。プロジェクトの計画には次のものが含まれます。

スコープ管理

プロジェクトの範囲を定義します。これにはすべてのアクティビティが含まれ、成果物のソフトウェア製品を作成するためにプロセスを実行する必要があります。スコープ管理は、プロジェクトで行われることと行われないことを明確に定義することでプロジェクトの境界を作成するため、不可欠です。これにより、プロジェクトに限定された定量化可能なタスクが含まれるようになり、簡単に文書化でき、コストと時間の超過を回避できます。

プロジェクトスコープの管理中に、次のことが必要です-

スコープを定義する
検証と制御を決定する
管理を容易にするために、プロジェクトをさまざまな小さな部分に分割します。
スコープを確認する
スコープに変更を組み込むことにより、スコープを制御します

プロジェクト見積もり

効果的な管理のためには、さまざまな測定値の正確な推定が必須です。正しい見積もりにより、マネージャーはプロジェクトをより効率的かつ効果的に管理および制御できます。

プロジェクトの見積もりには、次のものが含まれます。

ソフトウェアサイズの見積もり

ソフトウェアのサイズは、KLOC（Kilo Line of Code）の観点から、またはソフトウェア内の機能ポイントの数を計算することによって推定できます。コードの行はコーディング慣行に依存し、機能ポイントはユーザーまたはソフトウェアの要件によって異なります。

工数の見積もり

マネージャーは、ソフトウェアを作成するために必要な人員要件と工数の面で努力を見積もります。労力を見積もるには、ソフトウェアのサイズがわかっている必要があります。これは、管理者の経験、組織の履歴データ、またはソフトウェアのサイズを標準的な式を使用して成果に変換することにより導き出すことができます。

時間の見積もり

サイズと労力が見積もられると、ソフトウェアの作成に必要な時間を見積もることができます。必要な努力は、要件の仕様およびソフトウェアのさまざまなコンポーネントの相互依存性に従って、サブカテゴリに分類されます。ソフトウェアタスクは、ワークブレイクスルー構造（WBS）によって小さなタスク、アクティビティ、またはイベントに分割されます。タスクは、毎日または暦月ごとにスケジュールされます。

すべてのタスクを数時間または数日で完了するために必要な時間の合計は、プロジェクトを完了するために費やされた合計時間です。

費用の見積もり

これは、これまでのどの要素よりも多くの要素に依存しているため、すべての中で最も難しいと考えられるかもしれません。プロジェクトコストを見積もるには、以下を考慮する必要があります-

ソフトウェアのサイズ
ソフトウェア品質
ハードウェア
追加のソフトウェアまたはツール、ライセンスなど
タスク固有のスキルを持つ熟練した人材
関係する旅行
コミュニケーション
トレーニングとサポート

プロジェクト推定手法

サイズ、労力、時間、コストなど、プロジェクトの見積もりに関連するさまざまなパラメーターについて説明しました。

プロジェクトマネージャーは、広く知られている2つの手法を使用して、リストされた要因を推定できます。

分解技術

この手法は、ソフトウェアをさまざまな構成の製品として想定しています。

主に2つのモデルがあります-

*コードの行*推定は、ソフトウェア製品のコードの行数に代わって行われます。
*機能ポイント*推定は、ソフトウェア製品の機能ポイントの数に代わって行われます。

経験的推定手法

この手法では、経験的に導出された式を使用して推定を行います。これらの式はLOCまたはFPに基づいています。

パトナムモデル +このモデルは、Lawrence Hによって作成されました。パットナム、ノルデンの頻度分布（レイリー曲線）に基づいています。パトナムモデルは、ソフトウェアサイズに必要な時間と労力をマッピングします。
ココモ + COCOMOは、バリーWが開発したCOnstructive COst MOdelの略です。ベーム。ソフトウェア製品を、オーガニック、セミデタッチ、および組み込みの3つのソフトウェアカテゴリに分類します。

プロジェクトのスケジューリング

プロジェクトのプロジェクトスケジューリングとは、指定された順序で、各アクティビティに割り当てられたタイムスロット内で実行されるすべてのアクティビティのロードマップを指します。プロジェクトマネージャーは、さまざまなタスクを定義し、プロジェクトのマイルストーンを作成し、さまざまな要因を考慮してそれらを調整する傾向があります。タスクは、スケジュール内のクリティカルパスにあります。これは、特定の方法（タスクの相互依存性）で、厳密に割り当てられた時間内に完了するために必要です。クリティカルパスの範囲外にあるタスクの配置は、プロジェクトのすべてのスケジュールに影響を与える可能性が低くなります。

プロジェクトをスケジュールするには、次のことが必要です-

プロジェクトのタスクをより小さく管理しやすい形式に分解する
さまざまなタスクを見つけて相関させる
各タスクに必要な推定時間枠
時間を作業単位に分割する
各タスクに適切な数のワークユニットを割り当てます
プロジェクトの開始から終了までに必要な合計時間を計算する

資源管理

ソフトウェア製品の開発に使用されるすべての要素は、そのプロジェクトのリソースと見なされる場合があります。これには、人的資源、生産的なツール、ソフトウェアライブラリが含まれる場合があります。

リソースは限られた量で利用可能であり、資産のプールとして組織にとどまります。リソースの不足はプロジェクトの開発を妨げ、スケジュールより遅れることがあります。追加のリソースを割り当てると、最終的に開発コストが増加します。したがって、プロジェクトに十分なリソースを見積もり、割り当てる必要があります。

リソース管理に含まれるもの-

プロジェクトチームを作成し、各チームメンバーに責任を割り当てることにより、適切な組織プロジェクトを定義する
特定の段階で必要なリソースとその可用性の決定
必要なときにリソース要求を生成し、不要になったときにリソースの割り当てを解除して、リソースを管理します。

プロジェクトリスク管理

リスク管理には、プロジェクトの予測可能および予測不可能なリスクの特定、分析、およびプロビジョニングに関するすべてのアクティビティが含まれます。リスクには次のものが含まれます。

プロジェクトを離れる経験豊富なスタッフと新しいスタッフがやってくる。
組織管理の変更。
要件の変更または要件の誤解。
必要な時間とリソースの過小評価。
技術変化、環境変化、ビジネス競争。

リスク管理プロセス

リスク管理プロセスには次のアクティビティが含まれます。

*識別-*プロジェクトで発生する可能性のあるすべてのリスクをメモします。
*分類-*既知のリスクを、プロジェクトへの影響の可能性に応じて、高、中、低のリスク強度に分類します。
*管理-*さまざまな段階でリスクが発生する確率を分析します。リスクを回避または直面する計画を立てます。副作用を最小限に抑えるようにします。
*監視-*潜在的なリスクとその初期症状を綿密に監視します。また、それらを軽減または回避するために実行された手順の影響を監視します。

プロジェクトの実行と監視

このフェーズでは、プロジェクト計画に記述されているタスクがスケジュールに従って実行されます。

実行は、すべてが計画どおりに進んでいるかどうかを確認するために監視する必要があります。監視とは、リスクの可能性を確認するために観察し、リスクに対処したり、さまざまなタスクのステータスを報告したりすることです。

これらの手段には以下が含まれます-

*アクティビティの監視-*一部のタスク内でスケジュールされたすべてのアクティビティは、毎日監視できます。タスク内のすべてのアクティビティが完了すると、完了したと見なされます。
*ステータスレポート-*レポートには、特定の時間枠（通常は1週間）内に完了したアクティビティとタスクのステータスが含まれます。ステータスは、完了、保留中、または進行中などとしてマークできます。
*マイルストーンチェックリスト-*すべてのプロジェクトは、SDLCのフェーズに基づいて主要なタスク（マイルストーン）が実行される複数のフェーズに分割されます。このマイルストーンチェックリストは、数週間に1回作成され、マイルストーンのステータスを報告します。

プロジェクトコミュニケーション管理

効果的なコミュニケーションは、プロジェクトの成功に不可欠な役割を果たします。これは、クライアントと組織の間のギャップを、チームメンバーとプロジェクトのその他の利害関係者（ハードウェアサプライヤなど）の間で埋めます。

コミュニケーションは口頭でも書面でも可能です。通信管理プロセスには、次の手順があります。

計画-このステップには、プロジェクトのすべての利害関係者の識別とそれらの間のコミュニケーションのモードが含まれます。また、追加の通信機能が必要かどうかも考慮します。
共有-計画のさまざまな側面を決定した後、マネージャーは正しい情報を正しい時間に正しい人と共有することに集中します。これにより、プロジェクトに関係するすべての人がプロジェクトの進捗状況とステータスを最新の状態に保ちます。
フィードバック-プロジェクトマネージャーは、さまざまな手段とフィードバックメカニズムを使用して、ステータスおよびパフォーマンスレポートを作成します。このメカニズムにより、さまざまな利害関係者からのインプットがフィードバックとしてプロジェクトマネージャーに送られます。
閉鎖-各主要イベントの終了時、SDLCのフェーズの終了時、またはプロジェクト自体の終了時に、電子メールの送信、文書のハードコピーの配布、またはその他の効果的な手段により、すべての利害関係者を更新するための管理上の閉鎖が正式に発表されますコミュニケーション。

閉鎖後、チームは次のフェーズまたはプロジェクトに移行します。

構成管理

構成管理は、製品の要件、設計、機能、および開発の観点からソフトウェアの変更を追跡および制御するプロセスです。

IEEEは、「システム内のアイテムを識別および定義し、ライフサイクル全体でこれらのアイテムの変更を制御し、アイテムおよび変更リクエストのステータスを記録および報告し、アイテムの完全性と正確性を検証するプロセス」と定義しています。

一般に、SRSが完成すると、ユーザーが変更を要求する可能性は低くなります。それらが発生した場合、コストと時間のオーバーランの可能性があるため、変更は上級管理職の事前承認によってのみ対処されます。

ベースライン

SDLCのフェーズは、ベースライン化された場合、つまり、ベースラインは、フェーズの完全性を定義する測定値です。フェーズは、それに関連するすべてのアクティビティが終了し、十分に文書化されるとベースラインになります。最終段階ではない場合、その出力は次の即時段階で使用されます。

構成管理は、組織管理の分野であり、フェーズのベースライン化後に変更（プロセス、要件、技術的、戦略的など）の発生を処理します。 CMは、ソフトウェアで行われた変更を常にチェックします。

変更管理

変更管理は構成管理の機能であり、ソフトウェアシステムに加えられたすべての変更が一貫性を保ち、組織の規則および規制に従って行われることを保証します。

製品の構成の変更は、次の手順を経て行われます-

識別-変更要求は、内部ソースまたは外部ソースから到着します。変更要求が正式に識別されると、適切に文書化されます。
検証-変更要求の有効性が確認され、その処理手順が確認されます。
分析-変更要求の影響は、スケジュール、コスト、および必要な労力の観点から分析されます。システムに対する将来の変更の全体的な影響が分析されます。
コントロール-予想される変更がシステム内のエンティティに影響を与えすぎるか、避けられない場合、変更がシステムに組み込まれる前に、高い権限の承認を取ることが必須です。変更を組み込む価値があるかどうかが決定されます。そうでない場合、変更要求は正式に拒否されます。
実行-前のフェーズが変更要求の実行を決定した場合、このフェーズは変更を実行するために適切なアクションを実行し、必要に応じて徹底的な改訂を行います。
閉じるリクエスト-変更が正しい実装とシステムの他の部分とのマージのために検証されます。このソフトウェアに新たに組み込まれた変更は適切に文書化され、リクエストは正式にクローズされます。

プロジェクト管理ツール

リスクと不確実性は、プロジェクトが設定された方法論に従って開発された場合でも、プロジェクトのサイズに関して複数倍に上昇します。

効果的なプロジェクト管理を支援するツールが利用可能です。いくつかの説明があります-

ガントチャート

ガントチャートは、ヘンリーガント（1917）によって考案されました。これは、期間に関するプロジェクトスケジュールを表します。これは、プロジェクトのアクティビティとスケジュールされたアクティビティを表す横棒グラフです。

ガントチャート

PERTチャート

PERT（プログラム評価とレビュー手法）チャートは、プロジェクトをネットワーク図として描写するツールです。プロジェクトのメインイベントを並列的および連続的な方法でグラフィカルに表すことができます。次々に発生するイベントは、前のイベントに対する後のイベントの依存関係を示します。

PERT Chart

イベントは番号付きノードとして表示されます。これらは、プロジェクト内のタスクのシーケンスを示すラベル付き矢印で接続されています。

リソースヒストグラム

これは、プロジェクトイベント（またはフェーズ）に必要なリソース（通常は熟練したスタッフ）の数を表す棒グラフまたはチャートを含むグラフィカルツールです。リソースヒストグラムは、スタッフの計画と調整のための効果的なツールです。

image:/softwareengineering/histogram table.png [ヒストグラムテーブル] ヒストグラムチャート

クリティカルパス分析

このツールは、プロジェクト内の相互依存タスクを認識するのに役立ちます。また、プロジェクトを正常に完了するための最短パスまたはクリティカルパスを見つけるのにも役立ちます。 PERTダイアグラムのように、各イベントには特定の時間枠が割り当てられます。このツールは、前のイベントが完了した場合にのみイベントが次に進むことができると仮定して、イベントの依存関係を示します。

イベントは、可能な限り早い開始時間に従って配置されます。開始ノードと終了ノードの間のパスはクリティカルパスであり、これ以上減らすことはできず、すべてのイベントを同じ順序で実行する必要があります。

ソフトウェア要件

ソフトウェア要件は、ターゲットシステムの機能の説明です。要件は、ソフトウェア製品に対するユーザーの期待を伝えます。要件は、クライアントの観点から明らかまたは非表示、既知または未知、予想または予期しないものである可能性があります。

要件エンジニアリング

クライアントからソフトウェア要件を収集し、分析して文書化するプロセスは、要件エンジニアリングと呼ばれます。

要件エンジニアリングの目標は、洗練された記述的な「システム要件仕様」ドキュメントを開発して維持することです。

要件エンジニアリングプロセス

次の4つのステップから成るプロセスです–

実現可能性調査
要件の収集
ソフトウェア要件仕様
ソフトウェア要件の検証

プロセスを簡単に見てみましょう-

実現可能性調査

目的の製品を開発するためにクライアントが組織に近づくと、ソフトウェアが実行しなければならないすべての機能と、ソフトウェアに期待されるすべての機能について大まかなアイデアが思いつきます。

この情報を参照して、アナリストは、目的のシステムとその機能が開発可能かどうかについて詳細な調査を行います。

この実現可能性調査は、組織の目標に焦点を当てています。この調査では、ソフトウェア製品が実装、プロジェクトの組織への貢献、コストの制約、および組織の価値と目的によって実際に実現できるかどうかを分析します。使いやすさ、保守性、生産性、統合能力など、プロジェクトと製品の技術的側面を調査します。

このフェーズのアウトプットは、プロジェクトを実施すべきかどうかについての管理のための適切なコメントと推奨事項を含むべき実行可能性調査報告書であるべきです。

要件の収集

実行可能性レポートがプロジェクトの実施に肯定的である場合、次のフェーズはユーザーから要件を収集することから始まります。アナリストとエンジニアは、クライアントとエンドユーザーと通信して、ソフトウェアが提供するものとソフトウェアに含める機能に関するアイデアを把握します。

ソフトウェア要件仕様

SRSは、さまざまな利害関係者から要件が収集された後、システムアナリストによって作成されたドキュメントです。

SRSは、目的のソフトウェアがハードウェア、外部インターフェイス、操作速度、システムの応答時間、さまざまなプラットフォームでのソフトウェアの移植性、保守性、クラッシュ後の回復速度、セキュリティ、品質、制限などと対話する方法を定義します。

クライアントから受け取った要件は、自然言語で書かれています。システム開発者は、要件を技術用語で文書化して、ソフトウェア開発チームが理解し、役立つようにする必要があります。

SRSは次の機能を考え出す必要があります。

ユーザー要件は自然言語で表されます。
技術要件は、組織内で使用される構造化言語で表現されます。
デザインの説明は、擬似コードで記述する必要があります。
フォームのフォーマットとGUI画面印刷。
DFDなどの条件付きおよび数学表記

ソフトウェア要件の検証

要件仕様が作成された後、このドキュメントに記載されている要件が検証されます。ユーザーが違法で非現実的な解決策を要求したり、専門家が要件を誤って解釈したりする場合があります。これは、芽に挟まれていない場合、コストの大幅な増加につながります。要件は、次の条件に対して確認できます-

実際に実装できる場合
それらが有効であり、ソフトウェアの機能およびドメインに従って
あいまいな点がある場合
それらが完全な場合
実証できる場合

要件の引き出しプロセス

要件の抽出プロセスは、次の図を使用して説明できます。

要件抽出プロセス

*要件の収集-*開発者はクライアントおよびエンドユーザーと話し合い、ソフトウェアに対する期待を把握します。
*要件の整理-*開発者は、重要度、緊急度、および便利さの順に要件を優先順位付けおよび調整します。
*交渉と議論-*要件があいまいな場合、またはさまざまな利害関係者の要件に何らかの矛盾がある場合は、利害関係者と交渉し、話し合います。その後、要件が優先され、合理的に侵害される可能性があります。 +要件はさまざまな利害関係者からのものです。あいまいさと矛盾を取り除くために、それらは明確さと正確さのために議論されています。非現実的な要件は合理的に妥協されます。
*ドキュメント-*すべての正式および非公式の機能的および非機能的要件はドキュメント化され、次のフェーズの処理に利用可能になります。

要件の引き出し手法

要件の抽出とは、クライアント、エンドユーザー、システムユーザー、およびソフトウェアシステム開発に関与している他のユーザーと通信することにより、目的のソフトウェアシステムの要件を見つけるプロセスです。

要件を発見するにはさまざまな方法があります

インタビュー

インタビューは、要件を収集するための強力な手段です。組織は、次のようないくつかのタイプのインタビューを実施できます。

収集するすべての情報が事前に決定されている構造化された（クローズド）インタビューは、パターンと議論の問題をしっかりと守ります。
収集する情報が事前に決定されておらず、より柔軟で偏りの少ない非構造化（オープン）インタビュー。
口頭インタビュー
書面によるインタビュー
テーブルを渡って2人の間で行われる1対1のインタビュー。
参加者のグループ間で行われるグループインタビュー。多数の人々が関与しているため、欠落している要件を明らかにするのに役立ちます。

調査

組織は、今後のシステムからの期待と要件について照会することにより、さまざまな利害関係者間で調査を実施できます。

アンケート

事前定義された客観的な質問とそれぞれのオプションのセットを含むドキュメントは、すべての利害関係者に渡されて回答され、収集およびコンパイルされます。

この手法の短所は、アンケートで問題のオプションが記載されていない場合、問題が放置される可能性があることです。

タスク分析

エンジニアと開発者のチームは、新しいシステムが必要な操作を分析できます。クライアントが特定の操作を実行するためのソフトウェアをすでに持っている場合、それが調査され、提案されたシステムの要件が収集されます。

ドメイン分析

すべてのソフトウェアは、いくつかのドメインカテゴリに分類されます。ドメインの専門家は、一般的および特定の要件を分析するのに非常に役立ちます。

ブレーンストーミング

さまざまな利害関係者の間で非公式の議論が行われ、さらなる要件分析のためにすべてのインプットが記録されます。

プロトタイピング

プロトタイプは、ユーザーが目的のソフトウェア製品の機能を解釈するための詳細機能を追加せずにユーザーインターフェイスを構築しています。要件をよりよく理解するのに役立ちます。開発者が参照するためにクライアント側にソフトウェアがインストールされておらず、クライアントが独自の要件を認識していない場合、開発者は最初に言及した要件に基づいてプロトタイプを作成します。プロトタイプがクライアントに表示され、フィードバックが記録されます。クライアントのフィードバックは、要件収集の入力として機能します。

観察

専門家チームがクライアントの組織または職場を訪問します。既存のインストール済みシステムの実際の動作を観察します。クライアント側のワークフローと、実行の問題の対処方法を観察します。チーム自体が、ソフトウェアに期待される要件を形成するのに役立ついくつかの結論を導き出します。

ソフトウェア要件の特性

ソフトウェア要件の収集は、ソフトウェア開発プロジェクト全体の基盤です。したがって、それらは明確で正しく、明確に定義されている必要があります。

完全なソフトウェア要件仕様は次のとおりである必要があります。

クリア
正しい
一貫した
コヒーレント
わかりやすい
変更可能
検証可能
優先順位付け
明確な
追跡可能
信頼できるソース

ソフトウェア要件

要件抽出フェーズでどのような要件が発生する可能性があり、ソフトウェアシステムにどのような要件が予想されるのかを理解する必要があります。

ソフトウェア要件は、大きく分けて次の2つのカテゴリに分類する必要があります。

機能要件

ソフトウェアの機能面に関連する要件は、このカテゴリに分類されます。

それらは、ソフトウェアシステム内外の機能を定義します。

例 -

さまざまな請求書から検索するためにユーザーに与えられた検索オプション。
ユーザーは、レポートを管理者に郵送できる必要があります。
ユーザーをグループに分割し、グループに個別の権限を付与できます。
ビジネスルールと管理機能を遵守する必要があります。
ソフトウェアは、下位互換性を損なわずに開発されています。

非機能要件

要件は、ソフトウェアの機能面とは関係ありませんが、このカテゴリに分類されます。これらは、ユーザーが想定するソフトウェアの暗黙的または予想される特性です。

非機能要件には次が含まれます-

セキュリティ
ロギング
ストレージ
設定
パフォーマンス
Cost
相互運用性
柔軟性
災害からの回復
アクセシビリティ

要件は論理的に次のように分類されます

Must Have ：それらなしではソフトウェアは動作可能とは言えません。
Should have ：ソフトウェアの機能を強化します。
Could have ：ソフトウェアは、これらの要件でも適切に機能します。
ウィッシュリスト：これらの要件は、ソフトウェアのいかなる目的にも対応していません。

ソフトウェアの開発中は、「必要」を実装する必要があります。「必要」は、利害関係者との議論と否定の問題ですが、ソフトウェアの更新については「必要」と「希望リスト」を保持できます。

ユーザーインターフェイスの要件

UIは、ソフトウェア、ハードウェア、またはハイブリッドシステムの重要な部分です。ソフトウェアは、広く受け入れられています-

操作が簡単
迅速な対応
操作エラーを効果的に処理する
シンプルでありながら一貫したユーザーインターフェイスを提供する

ユーザーの受け入れは、ユーザーがソフトウェアを使用する方法に大きく依存します。ユーザーがシステムを認識する唯一の方法はUIです。優れたパフォーマンスのソフトウェアシステムには、魅力的で明確で一貫性のある応答性の高いユーザーインターフェイスも装備する必要があります。そうしないと、ソフトウェアシステムの機能を便利な方法で使用できません。システムは、それを効率的に使用する手段を提供するのであれば良いと言われます。ユーザーインターフェイスの要件を以下に簡単に説明します-

コンテンツのプレゼンテーション
簡単なナビゲーション
シンプルなインターフェース
レスポンシブ
一貫性のあるUI要素
フィードバック機構
デフォルトの設定
意図的なレイアウト
色とテクスチャの戦略的使用。
ヘルプ情報を提供する
ユーザー中心のアプローチ
グループベースのビュー設定。

ソフトウェアシステムアナリスト

IT組織のシステムアナリストは、提案されたシステムの要件を分析し、要件が適切かつ正確に考案および文書化されていることを確認する人です。アナリストの役割は、SDLCのソフトウェア分析フェーズで始まります。開発したソフトウェアがクライアントの要件を満たしていることを確認するのはアナリストの責任です。

システムアナリストには次の責任があります。

対象ソフトウェアの要件の分析と理解
プロジェクトが組織の目標にどのように貢献するかを理解する
要件のソースを特定する
要件の検証
要件管理計画を作成および実装する
ビジネス、技術、プロセス、製品の要件の文書化
要件を優先し、曖昧さを排除するためのクライアントとの調整
クライアントおよびその他の利害関係者との受け入れ基準の最終決定

ソフトウェアのメトリックと測定

ソフトウェア測定は、ソフトウェアのさまざまな属性と側面を定量化および記号化するプロセスとして理解できます。

ソフトウェアメトリックは、ソフトウェアプロセスおよびソフトウェア製品のさまざまな側面の指標を提供します。

ソフトウェア測定は、ソフトウェアエンジニアリングの基本的な要件です。これらは、ソフトウェア開発プロセスの制御に役立つだけでなく、究極の製品の品質を優れたものにするのにも役立ちます。

（ソフトウェアエンジニア）Tom DeMarcoによると、「測定できないものを制御することはできません。」と彼は言っています。

いくつかのソフトウェアメトリックを見てみましょう。

サイズメトリック- LOC（コード行）。ほとんどの場合、KLOCと表記される数千のソースコード行で計算されます。 + Function Point Countは、ソフトウェアによって提供される機能の測定値です。機能ポイント数は、ソフトウェアの機能面のサイズを定義します。
複雑度メトリクス- McCabeの循環的複雑度は、プログラム内の独立したパスの数の上限を定量化します。これは、プログラムまたはそのモジュールの複雑度として認識されます。制御フローグラフを使用して、グラフ理論の概念で表されます。
*品質メトリクス-*欠陥、そのタイプと原因、結果、深刻度の強度、およびその意味が製品の品質を定義します。 +開発プロセスで見つかった欠陥の数と、製品がクライアント側でインストールまたは配信された後にクライアントによって報告された欠陥の数は、製品の品質を定義します。
プロセスメトリック- SDLCのさまざまなフェーズで使用される方法とツール、会社の標準、および開発のパフォーマンスは、ソフトウェアプロセスメトリックです。
*リソースメトリック-*努力、時間、および使用されるさまざまなリソースは、リソース測定のメトリックを表します。

ソフトウェア設計の基本

ソフトウェア設計は、ユーザーの要件を何らかの適切な形式に変換するプロセスであり、ソフトウェアのコーディングと実装のプログラマーを支援します。

ユーザー要件を評価するために、SRS（Software Requirement Specification）ドキュメントが作成されますが、コーディングと実装には、ソフトウェア用語でより具体的かつ詳細な要件が必要です。このプロセスの出力は、プログラミング言語での実装に直接使用できます。

ソフトウェア設計はSDLC（Software Design Life Cycle）の最初のステップであり、問題の領域からソリューションの領域に集中します。 SRSに記載されている要件を満たす方法を指定しようとします。

ソフトウェア設計レベル

ソフトウェア設計では、3つのレベルの結果が得られます。

*建築設計-*建築設計は、システムの最も抽象的なバージョンです。ソフトウェアは、相互に作用する多くのコンポーネントを持つシステムとして識別されます。このレベルでは、設計者は提案されたソリューションドメインのアイデアを得ることができます。
*高レベルの設計-*高レベルの設計は、アーキテクチャ設計の「単一エンティティ-複数コンポーネント」の概念をサブシステムとモジュールの抽象度の低いビューに分割し、相互作用を示します。高度な設計では、システムとそのすべてのコンポーネントをモジュール形式で実装する方法に焦点を当てています。各サブシステムのモジュール構造と、それらの相互関係および相互作用を認識します。
*詳細設計-*詳細設計では、前の2つの設計でシステムおよびそのサブシステムと見なされるものの実装部分を扱います。モジュールおよびそれらの実装に関してより詳細に説明されています。他のモジュールと通信するために、各モジュールとそのインターフェースの論理構造を定義します。

モジュール化

モジュール化は、ソフトウェアシステムを複数の個別の独立したモジュールに分割する技術であり、独立したタスクを実行できることが期待されます。これらのモジュールは、ソフトウェア全体の基本的な構成要素として機能します。設計者は、個別に実行および/またはコンパイルできるようにモジュールを設計する傾向があります。

モジュール設計は、意図せずに「分割して征服する」問題解決戦略のルールに従います。これは、ソフトウェアのモジュール設計には他にも多くの利点があるためです。

モジュール化の利点：

小さいコンポーネントは保守が簡単です
プログラムは機能面に基づいて分割できます
希望するレベルの抽象化をプログラムに組み込むことができます
凝集力の高いコンポーネントは再利用できます
同時実行が可能になります
セキュリティ面からの要望

並行性

昔のことですが、すべてのソフトウェアは順番に実行されるものです。順次実行とは、コード化された命令が次から次へと実行されることを意味します。これは、プログラムの特定の部分のみが常にアクティブ化されることを意味します。ソフトウェアには複数のモジュールがあり、すべてのモジュールのうち1つだけが実行中にアクティブであることがわかります。

ソフトウェア設計では、モジュールのような複数の独立した実行単位にソフトウェアを分割し、それらを並列に実行することにより、並行性が実装されます。言い換えれば、並行性は、ソフトウェアにコードの複数の部分を互いに並行して実行する機能を提供します。

プログラマーと設計者は、これらのモジュールを認識する必要があります。これらのモジュールは、並列実行が可能です。

例

ワードプロセッサのスペルチェック機能は、ソフトウェアのモジュールであり、ワードプロセッサ自体と並行して実行されます。

カップリングと凝集

ソフトウェアプログラムがモジュール化されると、そのタスクはいくつかの特性に基づいていくつかのモジュールに分割されます。私たちが知っているように、モジュールはいくつかのタスクを達成するためにまとめられた命令のセットです。ただし、これらは単一のエンティティと見なされますが、相互に連携して連携する場合があります。モジュールの設計の品質とモジュール間の相互作用を測定できる手段があります。これらの手段は、結合および凝集と呼ばれます。

凝集

凝集度は、モジュールの要素内の内部依存性の程度を定義する尺度です。凝集度が大きいほど、プログラム設計は良くなります。

凝集には7つのタイプがあります。

*偶然の結合-*計画外でランダムな結合であり、モジュール化のためにプログラムを小さなモジュールに分割した結果である可能性があります。これは計画外であるため、プログラマーを混乱させる可能性があり、一般に受け入れられません。
*論理的結合-*論理的に分類された要素がモジュールにまとめられるとき、それは論理的結合と呼ばれます。
* Temporal Cohesion-*モジュールの要素が同様の時点で処理されるように編成される場合、それは時間的凝集と呼ばれます。
*手続き的結合-*モジュールの要素がグループ化され、タスクを実行するために順番に実行される場合、手続き的結合と呼ばれます。
*通信の結合-*モジュールの要素がグループ化され、順次実行され、同じデータ（情報）を処理するとき、それは通信の結合と呼ばれます。
*順次結合-*ある要素の出力が別の要素への入力として機能するなどの理由でモジュールの要素がグループ化される場合、それは順次結合と呼ばれます。
*機能的凝集力-*最高の凝集力と考えられており、非常に期待されています。機能的結合のモジュールの要素は、すべて明確に定義された単一の機能に寄与するため、グループ化されます。再利用することもできます。

カップリング

カップリングは、プログラムのモジュール間の相互依存性のレベルを定義する尺度です。モジュールが相互に干渉し、相互作用するレベルを示します。カップリングが低いほど、プログラムは良くなります。

結合には5つのレベルがあります。つまり-

*コンテンツカップリング-*モジュールが別のモジュールのコンテンツに直接アクセス、変更、または参照できる場合、コンテンツレベルカップリングと呼ばれます。
*共通結合-*複数のモジュールがグローバルデータへの読み取りおよび書き込みアクセス権を持っている場合、それは共通またはグローバル結合と呼ばれます。
制御結合- 2つのモジュールの1つが他のモジュールの機能を決定するか、実行フローを変更する場合、2つのモジュールは制御結合と呼ばれます。
*スタンプカップリング-*複数のモジュールが共通のデータ構造を共有し、その異なる部分で動作する場合、スタンプカップリングと呼ばれます。
*データカップリング-*データカップリングとは、2つのモジュールが（パラメーターとして）データを渡すことによって相互作用することです。モジュールがデータ構造をパラメーターとして渡す場合、受信モジュールはそのすべてのコンポーネントを使用する必要があります。

理想的には、最高のカップリングは考慮されません。

設計検証

ソフトウェア設計プロセスの出力は、設計文書、擬似コード、詳細な論理図、プロセス図、およびすべての機能要件または非機能要件の詳細な説明です。

次のフェーズであるソフトウェアの実装は、上記のすべての出力に依存します。

その後、次のフェーズに進む前に出力を検証する必要があります。誤りが早期に検出されると、より良いか、製品のテストまで検出されない場合があります。設計段階の出力が正式な表記形式である場合は、検証用の関連ツールを使用する必要があります。そうでない場合は、検証と検証に徹底的な設計レビューを使用できます。

構造化された検証アプローチにより、レビュアーはいくつかの条件を見落とすことによって引き起こされる可能性がある欠陥を検出できます。優れた設計レビューは、優れたソフトウェア設計、精度、品質にとって重要です。

ソフトウェア分析および設計ツール

ソフトウェアの分析と設計には、要件仕様を実装に変換するのに役立つすべてのアクティビティが含まれます。要件仕様は、ソフトウェアからのすべての機能的および非機能的期待を指定します。これらの要件仕様は、人間が読める、理解できるドキュメントの形をとっており、コンピューターには何の関係もありません。

ソフトウェアの分析と設計は中間段階であり、人間が読み取れる要件を実際のコードに変換するのに役立ちます。

ソフトウェア設計者が使用するいくつかの分析および設計ツールを見てみましょう。

データフロー図

データフロー図は、情報システム内のデータの流れをグラフィカルに表現したものです。着信データフロー、発信データフロー、および保存されたデータを表すことができます。 DFDは、データがシステムをどのように流れるかについては何も言及していません。

DFDとフローチャートの間には顕著な違いがあります。このフローチャートは、プログラムモジュールの制御の流れを示しています。 DFDは、さまざまなレベルでのシステム内のデータの流れを表します。 DFDには、コントロール要素またはブランチ要素は含まれていません。

DFDのタイプ

データフロー図は論理的または物理的です。

*論理DFD *-このタイプのDFDは、システムプロセス、およびシステム内のデータフローに集中します。たとえば、銀行ソフトウェアシステムでは、異なるエンティティ間でのデータの移動方法。
*物理DFD *-このタイプのDFDは、データフローが実際にシステムに実装される方法を示します。より具体的で、実装に近い。

DFDコンポーネント

DFDは、次の一連のコンポーネントを使用して、データのソース、宛先、ストレージ、およびフローを表すことができます-

DFDコンポーネント

エンティティ-エンティティは、情報データのソースおよび宛先です。エンティティは、それぞれの名前を持つ長方形で表されます。
プロセス-データに対して実行されたアクティビティとアクションは、円または角丸長方形で表されます。
データストレージ-データストレージには2つのバリエーションがあります。両方の小さい辺がない長方形、または片側だけが欠けている開いた長方形として表すことができます。
データフロー-データの移動は、先の尖った矢印で示されます。データの移動は、矢印の基部からソースとして矢印の先端に向かって表示されます。

DFDのレベル

*レベル0 *-最高の抽象化レベルDFDはレベル0 DFDとして知られ、情報システム全体を、すべての基礎となる詳細を隠す1つの図として表します。レベル0 DFDは、コンテキストレベルDFDとも呼ばれます。
*レベル1 *-レベル0 DFDは、より具体的なレベル1 DFDに分類されます。レベル1 DFDは、システム内の基本モジュールと、さまざまなモジュール間のデータの流れを示します。レベル1 DFDは、基本的なプロセスと情報源にも言及しています。
*レベル2 *-このレベルでは、DFDはレベル1で言及したモジュール内のデータの流れを示します。 +高いレベルのDFDは、必要な仕様レベルが達成されない限り、より深いレベルの理解でより具体的な低いレベルのDFDに変換できます。

構造図

構造チャートは、データフロー図から派生したチャートです。 DFDよりも詳細にシステムを表します。システム全体を最も機能の低いモジュールに分割し、システムの各モジュールの機能とサブ機能をDFDよりも詳細に説明します。

構造図は、モジュールの階層構造を表します。各層で特定のタスクが実行されます。

構造図の構築に使用される記号は次のとおりです-

モジュール-プロセス、サブルーチン、またはタスクを表します。制御モジュールは、複数のサブモジュールに分岐します。ライブラリモジュールは再利用可能であり、どのモジュールからでも呼び出すことができます。 SCモジュール
条件-モジュールのベースにある小さなひし形で表されます。これは、制御モジュールが何らかの条件に基づいて任意のサブルーチンを選択できることを示しています。 SC条件
ジャンプ-サブモジュールの中央でコントロールがジャンプすることを示すために、モジュール内を指す矢印が表示されます。 SC Module Jump
ループ-曲線矢印はモジュール内のループを表します。ループの対象となるすべてのサブモジュールは、モジュールの実行を繰り返します。 SC Loop
データフロー-末尾に空の円の付いた有向矢印は、データフローを表します。 SC Dataflow
制御フロー-最後に塗りつぶされた円の付いた有向矢印は、制御フローを表します。 SC ControlFlow

HIPO図

HIPO（階層的入力プロセス出力）図は、システムを分析し、文書化の手段を提供する2つの組織化された方法の組み合わせです。 HIPOモデルは、1970年にIBMによって開発されました。

HIPOダイアグラムは、ソフトウェアシステム内のモジュールの階層を表します。アナリストは、HIPOダイアグラムを使用して、システム機能の高レベルのビューを取得します。機能を階層的にサブ機能に分解します。システムによって実行される機能を示しています。

HIPO図は、文書化の目的に適しています。グラフィカルな表現により、設計者や管理者はシステム構造の図を簡単に把握できます。

HIPO図

モジュール内の制御とデータのフローを示すIPO（入力プロセス出力）図とは対照的に、HIPOはデータフローまたは制御フローに関する情報を提供しません。

IPO Chart

例

HIPO図、階層表示、およびIPOチャートの両方の部分は、ソフトウェアプログラムの構造設計と同様のドキュメント化に使用されます。

構造化された英語

ほとんどのプログラマーはソフトウェアの全体像に気付いていないため、マネージャーから指示された内容のみに依存しています。プログラマーに正確な情報を提供して正確かつ高速なコードを開発することは、高度なソフトウェア管理の責任です。

グラフや図を使用する他の形式の方法は、人によって解釈が異なる場合があります。

したがって、ソフトウェアのアナリストとデザイナーは、構造化英語などのツールを思いつきます。それは、コーディングに必要なものとそのコーディング方法の説明に他なりません。構造化された英語は、プログラマがエラーのないコードを書くのに役立ちます。

グラフまたは図を使用する他の形式の方法は、人によって解釈が異なる場合があります。ここでは、構造化英語と擬似コードの両方が、その理解のギャップを緩和しようとします。

構造化英語は、構造化プログラミングパラダイムで単純な英語の単語を使用します。これは究極のコードではなく、コーディングに必要なものとそのコーディング方法の一種の説明です。以下は、構造化プログラミングのいくつかのトークンです。

IF-THEN-ELSE,
DO-WHILE-UNTIL

アナリストは同じ変数とデータ名を使用します。これらはデータディクショナリに格納されており、コードの記述と理解がより簡単になります。

例

オンラインショッピング環境での顧客認証の同じ例を取り上げます。顧客を認証するこの手順は、構造化された英語で次のように記述できます。

Enter Customer_Name
SEEK Customer_Name in Customer_Name_DB file
IF Customer_Name found THEN
   Call procedure USER_PASSWORD_AUTHENTICATE()
ELSE
   PRINT error message
   Call procedure NEW_CUSTOMER_REQUEST()
ENDIF

構造化英語で書かれたコードは、日常の話し言葉の英語に似ています。ソフトウェアのコードとして直接実装することはできません。構造化英語はプログラミング言語に依存しません。

擬似コード

擬似コードは、プログラミング言語により近く書かれています。これは、拡張されたプログラミング言語であり、コメントや説明が満載されていると見なされる場合があります。

擬似コードは変数宣言を回避しますが、C、Fortran、Pascalなどの実際のプログラミング言語の構造を使用して記述されます。

擬似コードには、構造化英語よりも多くのプログラミングの詳細が含まれています。コンピュータがコードを実行しているかのように、タスクを実行する方法を提供します。

例

n個までのフィボナッチを印刷するプログラム。

void function Fibonacci
Get value of n;
Set value of a to 1;
Set value of b to 1;
Initialize I to 0
for (i=0; i< n; i++)
{
   if a greater than b
   {
      Increase b by a;
      Print b;
   }
   else if b greater than a
   {
      increase a by b;
      print a;
   }
}

決定表

決定表は、構造化された表形式で、条件とそれに対処するために実行される各アクションを表します。

エラーをデバッグして防止するための強力なツールです。同様の情報を1つのテーブルにグループ化し、テーブルを組み合わせることにより、簡単で便利な意思決定を実現します。

決定表の作成

決定表を作成するには、開発者は基本的な4つの手順に従う必要があります。

対処可能なすべての条件を特定する
特定されたすべての条件に対するアクションを決定する
最大可能ルールを作成する
各ルールのアクションを定義する

決定表はエンドユーザーが検証する必要があり、最近ではルールとアクションの重複を排除することで簡素化できます。

例

インターネット接続に関する日々の問題の簡単な例を見てみましょう。まず、インターネットの起動中に発生する可能性のあるすべての問題と、それぞれの可能な解決策を特定することから始めます。

列の条件の下で起こりうるすべての問題と、列のアクションの下で予想されるアクションをリストします。

条件/アクション

規則

条件

接続済みを表示

N

Y

Pingは機能しています

N

Y

N

Y

ウェブサイトを開く

Y

N

Y

N

Y

N

Y

N

行動

ネットワークケーブルを確認してください

X

インターネットルーターを確認する

X

Webブラウザを再起動します

X

サービスプロバイダーに連絡する

X

何もしない

Table : Decision Table – In-house Internet Troubleshooting

エンティティ関係モデル

エンティティ関係モデルは、実世界のエンティティとそれらの間の関係の概念に基づくデータベースモデルの一種です。現実のシナリオをERデータベースモデルにマッピングできます。 ERモデルは、属性、制約のセット、およびエンティティ間の関係を持つエンティティのセットを作成します。

ERモデルは、データベースの概念設計に最適です。 ERモデルは次のように表すことができます。

ERモデル

エンティティ-ERモデルのエンティティは現実世界であり、 _ attributes_ と呼ばれるいくつかのプロパティがあります。すべての属性は、 _ domain_ と呼ばれる対応する値のセットによって定義されます。 +たとえば、学校のデータベースを考えます。ここでは、学生はエンティティです。学生には、名前、ID、年齢、クラスなどのさまざまな属性があります。
関係-エンティティ間の論理的な関連付けは relationship と呼ばれます。関係はさまざまな方法でエンティティとマッピングされます。カーディナリティのマッピングは、2つのエンティティ間の関連付けの数を定義します。 +カーディナリティのマッピング：
一対一
一対多
多対一
多対多

データ辞書

データディクショナリは、データに関する情報の集中管理されたコレクションです。データの意味と起源、他のデータとの関係、使用のためのデータ形式などを保存します。データディクショナリには、ユーザーおよびソフトウェアデザイナーを容易にするために、すべての名前の厳密な定義があります。

データディクショナリは、多くの場合、メタデータ（データに関するデータ）リポジトリとして参照されます。ソフトウェアプログラムのDFD（データフロー図）モデルとともに作成され、DFDが変更または更新されるたびに更新されることが期待されています。

データ辞書の要件

データは、ソフトウェアの設計および実装中にデータ辞書を介して参照されます。データディクショナリは、あいまいさの可能性を排除します。プログラム内のどこでも同じオブジェクト参照を使用しながら、プログラマーとデザイナーの作業を同期させます。

データディクショナリは、完全なデータベースシステムを1か所で文書化する方法を提供します。 DFDの検証は、データディクショナリを使用して実行されます。

内容

データディクショナリには、次に関する情報が含まれている必要があります

データフロー
データ構造
データ要素
データストア
情報処理

データフローは、前述のようにDFDを使用して記述され、説明されているように代数形式で表されます。

=	Composed of
\{}	Repetition
()	Optional
+	And
[/]	Or

例

住所=家番号+（通り/エリア）+市+州

コースID =コース番号+コース名+コースレベル+コースグレード

データ要素

データ要素は、データおよび制御項目の名前と説明、内部または外部のデータストアなどで構成されます。次の詳細を使用します。

一次名
セカンダリ名（エイリアス）
ユースケース（使用方法と使用場所）
コンテンツの説明（表記法など。 )
補足情報（プリセット値、制約など）

データストア

データがシステムに入力され、システム外に存在する場所からの情報を保存します。データストアには以下が含まれます。

ファイル
ソフトウェアの内部。
ソフトウェアの外部ですが、同じマシン上にあります。
別のマシンにあるソフトウェアおよびシステムの外部。
テーブル
命名規則
インデックス作成プロパティ

情報処理

データ処理には2つのタイプがあります。

*論理：*ユーザーが見るとおり
*物理：*ソフトウェアが見るとおり

ソフトウェア設計戦略

ソフトウェア設計は、ソフトウェア要件をソフトウェア実装に概念化するプロセスです。ソフトウェア設計では、ユーザーの要件を課題とし、最適なソリューションを見つけようとします。ソフトウェアが概念化されている間、意図されたソリューションを実装するための最良の設計を見つけるための計画がチョークアウトされます。

ソフトウェア設計には複数のバリエーションがあります。簡単に調べてみましょう。

構造化設計

構造化設計は、問題をいくつかのよく組織化されたソリューション要素に概念化したものです。基本的にはソリューションの設計に関係しています。構造化設計の利点は、問題の解決方法をよりよく理解できることです。また、構造化された設計により、設計者はより正確に問題に集中できます。

構造化設計は、主に「分割統治」戦略に基づいており、問題はいくつかの小さな問題に分割され、各小さな問題は問題全体が解決されるまで個別に解決されます。

問題の小さな部分は、ソリューションモジュールによって解決されます。構造化設計では、正確なソリューションを実現するために、これらのモジュールが適切に編成されていることが強調されています。

これらのモジュールは階層構造になっています。彼らは互いに通信します。優れた構造設計は、常に複数のモジュール間の通信に関するいくつかのルールに従います。

*Cohesion* -機能的に関連するすべての要素のグループ化。

カップリング-異なるモジュール間の通信。

優れた構造設計には、高い凝集力と低い結合配置があります。

機能指向設計

機能指向設計では、システムは機能として知られる多くの小さなサブシステムで構成されます。これらの機能は、システムで重要なタスクを実行できます。システムは、すべての機能のトップビューと見なされます。

機能指向設計は、分割統治法が使用される構造化設計のいくつかのプロパティを継承します。

この設計メカニズムは、システム全体をより小さな機能に分割し、情報とその操作を隠すことにより抽象化の手段を提供します。これらの機能モジュールは、グローバルに利用可能な情報の受け渡しと使用により、相互に情報を共有できます。

関数の別の特徴は、プログラムが関数を呼び出すと、その関数がプログラムの状態を変更することです。これは、他のモジュールでは受け入れられない場合があります。機能指向設計は、システムの状態が重要でなく、プログラム/機能が状態ではなく入力で機能する場合にうまく機能します。

設計プロセス

システム全体は、データフロー図によってシステム内でデータがどのように流れるかと見なされます。
DFDは、機能がシステム全体のデータと状態をどのように変更するかを示します。
システム全体は、システム内での操作に基づいて、論理的に機能と呼ばれる小さな単位に分割されます。
次に、各機能の概要を説明します。

オブジェクト指向設計

オブジェクト指向設計は、ソフトウェアシステムに関係する機能ではなく、エンティティとその特性を中心に機能します。この設計戦略は、エンティティとその特性に焦点を当てています。ソフトウェアソリューションの概念全体は、関与するエンティティを中心に展開します。

オブジェクト指向設計の重要な概念を見てみましょう。

*オブジェクト-*ソリューション設計に関係するすべてのエンティティはオブジェクトと呼ばれます。たとえば、人、銀行、会社、顧客はオブジェクトとして扱われます。すべてのエンティティには、いくつかの属性が関連付けられており、属性に対して実行するメソッドがいくつかあります。
*クラス-*クラスは、オブジェクトの一般化された説明です。オブジェクトはクラスのインスタンスです。クラスは、オブジェクトが持つことができるすべての属性と、オブジェクトの機能を定義するメソッドを定義します。 +ソリューション設計では、属性は変数として保存され、機能はメソッドまたはプロシージャによって定義されます。
カプセル化- OODでは、属性（データ変数）とメソッド（データに対する操作）が一緒にバンドルされ、カプセル化と呼ばれます。カプセル化は、オブジェクトの重要な情報をまとめるだけでなく、外部からのデータとメソッドへのアクセスを制限します。これは情報隠蔽と呼ばれます。
継承- OODを使用すると、同様のクラスを階層的に積み重ねることができ、下位クラスまたはサブクラスは、許可された変数とメソッドを直接のスーパークラスからインポート、実装、再利用できます。 OODのこのプロパティは、継承と呼ばれます。これにより、特定のクラスを簡単に定義し、特定のクラスから一般化されたクラスを作成できます。
多態性- OOD言語は、同様のタスクを実行するが引数が異なるメソッドに同じ名前を割り当てることができるメカニズムを提供します。これはポリモーフィズムと呼ばれ、単一のインターフェイスでさまざまなタイプのタスクを実行できます。関数の起動方法に応じて、コードの各部分が実行されます。

設計プロセス

ソフトウェア設計プロセスは、一連の明確に定義されたステップとして捉えることができます。デザインアプローチ（関数指向またはオブジェクト指向）によって異なりますが、次の手順が含まれる場合があります。

ソリューション設計は、要件または以前に使用されたシステムやシステムシーケンス図から作成されます。
オブジェクトは、属性特性の類似性のために識別され、クラスにグループ化されます。
クラス階層とそれらの間の関係が定義されます。
アプリケーションフレームワークが定義されます。

ソフトウェア設計アプローチ

ソフトウェア設計のための2つの一般的なアプローチを次に示します。

トップダウンデザイン

システムは複数のサブシステムで構成され、多くのコンポーネントが含まれていることがわかっています。さらに、これらのサブシステムとコンポーネントは、サブシステムとコンポーネントのセットを持ち、システム内に階層構造を作成します。

トップダウン設計では、ソフトウェアシステム全体を1つのエンティティとして扱い、それを分解して、いくつかの特性に基づいて複数のサブシステムまたはコンポーネントを実現します。各サブシステムまたはコンポーネントは、システムとして扱われ、さらに分解されます。このプロセスは、トップダウン階層でシステムの最低レベルが達成されるまで実行され続けます。

トップダウン設計は、システムの一般化されたモデルから始まり、システムのより具体的な部分を定義し続けます。すべてのコンポーネントが構成されると、システム全体が存在します。

トップダウン設計は、ソフトウェアソリューションをゼロから設計する必要があり、具体的な詳細が不明な場合に適しています。

ボトムアップ設計

ボトムアップ設計モデルは、最も具体的で基本的なコンポーネントから始まります。基本または低レベルのコンポーネントを使用して、より高いレベルのコンポーネントを構成します。目的のシステムが単一のコンポーネントとして進化しない限り、より高いレベルのコンポーネントを作成し続けます。各レベルが高くなると、抽象化の量が増加します。

ボトムアップ戦略は、新しいシステムで基本的なプリミティブを使用できる既存のシステムからシステムを作成する必要がある場合に適しています。

トップダウンとボトムアップの両方のアプローチは、個別に実用的ではありません。代わりに、両方の適切な組み合わせが使用されます。

ソフトウェアユーザーインターフェイスの設計

ユーザーインターフェイスは、ユーザーがソフトウェアを使用するために対話するフロントエンドアプリケーションビューです。ユーザーは、ユーザーインターフェイスを使用して、ソフトウェアとハードウェアを操作および制御できます。今日、ユーザーインターフェースは、コンピューター、携帯電話、車、音楽プレーヤー、飛行機、船など、デジタルテクノロジーが存在するほぼすべての場所にあります。

ユーザーインターフェイスはソフトウェアの一部であり、ユーザーがソフトウェアを理解できるように設計されています。 UIは、人間とコンピューターの対話のための基本的なプラットフォームを提供します。

UIは、基盤となるハードウェアとソフトウェアの組み合わせに応じて、グラフィカル、テキストベース、オーディオビデオベースにすることができます。 UIは、ハードウェアまたはソフトウェア、あるいはその両方の組み合わせにすることができます。

ソフトウェアは、ユーザーインターフェイスが次の場合に人気があります。

魅力的
使い方が簡単
短時間で応答する
わかりやすい
すべてのインターフェース画面で一貫

UIは大きく2つのカテゴリに分類されます。

コマンドラインインターフェース
グラフィカル・ユーザー・インターフェース

コマンドラインインターフェース（CLI）

ビデオディスプレイモニターが登場するまで、CLIはコンピューターとの対話の優れたツールでした。 CLIは、多くの技術ユーザーおよびプログラマーの最初の選択肢です。 CLIは、ソフトウェアがユーザーに提供できる最小限のインターフェイスです。

CLIは、ユーザーがコマンドを入力してシステムに入力するコマンドプロンプトを提供します。ユーザーは、コマンドの構文とその使用法を覚えておく必要があります。以前のCLIは、ユーザーエラーを効果的に処理するようにプログラムされていませんでした。

コマンドは、システムによって実行されることが期待される一連の命令へのテキストベースの参照です。ユーザーが簡単に操作できるようにするマクロやスクリプトなどのメソッドがあります。

CLIは、GUIと比較して使用するコンピューターリソースの量が少なくなります。

CLI要素

コマンドラインインターフェイス（CLI）

テキストベースのコマンドラインインターフェイスには、次の要素を含めることができます。

コマンドプロンプト-テキストベースの通知機能で、ユーザーが作業しているコンテキストを主に表示します。ソフトウェアシステムによって生成されます。
カーソル-入力中の文字の位置を表す小さな水平線または行の高さの垂直バーです。カーソルはほとんどが点滅状態にあります。ユーザーが何かを書き込んだり削除したりすると移動します。
コマンド-コマンドは実行可能な命令です。 1つ以上のパラメーターがあります。コマンド実行時の出力は、画面にインラインで表示されます。出力が生成されると、コマンドプロンプトが次の行に表示されます。

グラフィカル・ユーザー・インターフェース

グラフィカルユーザーインターフェイスは、システムと対話するためのユーザーグラフィカル手段を提供します。 GUIは、ハードウェアとソフトウェアの両方を組み合わせることができます。 GUIを使用して、ユーザーはソフトウェアを解釈します。

通常、GUIはCLIよりも多くのリソースを消費します。高度な技術を使用して、プログラマーとデザイナーは、より効率的、正確、高速に動作する複雑なGUIデザインを作成します。

GUI要素

GUIは、ソフトウェアまたはハードウェアと対話するためのコンポーネントのセットを提供します。

すべてのグラフィカルコンポーネントは、システムを操作する方法を提供します。 GUIシステムには、次のような要素があります。

グラフィカルユーザーインターフェイス

ウィンドウ-アプリケーションのコンテンツが表示される領域。ウィンドウがファイル構造を表す場合、ウィンドウの内容はアイコンまたはリストの形式で表示できます。ユーザーは、探索ウィンドウ内のファイルシステム内を簡単に移動できます。ウィンドウは、画面のサイズに合わせて最小化、サイズ変更、または最大化できます。画面上のどこにでも移動できます。ウィンドウには、子ウィンドウと呼ばれる同じアプリケーションの別のウィンドウを含めることができます。
タブ-アプリケーションがそれ自体の複数のインスタンスの実行を許可する場合、それらは別々のウィンドウとして画面に表示されます。 Tabbed Document Interface が、同じウィンドウで複数のドキュメントを開くようになりました。このインターフェイスは、アプリケーションの設定パネルの表示にも役立ちます。最新のWebブラウザはすべてこの機能を使用しています。
メニュー-メニューは標準コマンドの配列であり、グループ化されてアプリケーションウィンドウ内の表示場所（通常は上部）に配置されます。メニューは、マウスクリックで表示または非表示になるようにプログラムできます。
アイコン-アイコンは、関連するアプリケーションを表す小さな画像です。これらのアイコンをクリックまたはダブルクリックすると、アプリケーションウィンドウが開きます。アイコンは、システムにインストールされているアプリケーションとプログラムを小さな写真の形で表示します。
カーソル-マウス、タッチパッド、デジタルペンなどの対話型デバイスは、GUIではカーソルとして表されます。画面上のカーソルは、ほぼリアルタイムでハードウェアからの指示に従います。カーソルは、GUIシステムではポインターとも呼ばれます。メニュー、ウィンドウ、その他のアプリケーション機能を選択するために使用されます。

アプリケーション固有のGUIコンポーネント

アプリケーションのGUIには、リストされた1つ以上のGUI要素が含まれます。

アプリケーションウィンドウ-ほとんどのアプリケーションウィンドウは、オペレーティングシステムが提供する構成を使用しますが、多くは、アプリケーションのコンテンツを含めるために顧客が作成した独自のウィンドウを使用します。
ダイアログボックス-ユーザーへのメッセージと実行するアクションの要求を含む子ウィンドウです。例：アプリケーションは、ファイルを削除するための確認をユーザーから取得するダイアログを生成します。 + ダイアログボックス
テキストボックス-ユーザーがテキストベースのデータを入力および入力するための領域を提供します。
ボタン-実際のボタンを模倣し、ソフトウェアに入力を送信するために使用されます。 + ラジオボタン
ラジオボタン-選択可能なオプションを表示します。提供されるすべての中から1つだけを選択できます。
チェックボックス-リストボックスに似た機能。オプションを選択すると、ボックスにチェックマークが付きます。チェックボックスで表される複数のオプションを選択できます。
リストボックス-選択可能な項目のリストを提供します。複数のアイテムを選択できます。 + リストボックス

他の印象的なGUIコンポーネントは次のとおりです。

スライダー
コンボボックス
データグリッド
ドロップダウンリスト

ユーザーインターフェイスのデザインアクティビティ

ユーザーインターフェイスを設計するために実行されるアクティビティは多数あります。 GUIの設計と実装のプロセスは、SDLCに似ています。ウォーターフォールモデル、反復モデル、またはスパイラルモデルの間で、GUIの実装に任意のモデルを使用できます。

GUIの設計と開発に使用されるモデルは、これらのGUI固有のステップを満たす必要があります。

GUIプロセス

* GUI要件の収集*-設計者は、GUIのすべての機能要件と非機能要件のリストを作成できます。これは、ユーザーおよび既存のソフトウェアソリューションから取得できます。
ユーザー分析-デザイナーは、ソフトウェアGUIを使用するユーザーを調査します。ユーザーの知識と能力レベルに応じて設計の詳細が変化するため、対象読者は重要です。ユーザーが技術に精通している場合、高度で複雑なGUIを組み込むことができます。初心者ユーザーには、ソフトウェアの使用方法に関する詳細情報が含まれています。
タスク分析-設計者は、ソフトウェアソリューションによって実行されるタスクを分析する必要があります。ここGUIでは、どのように実行されるかは関係ありません。タスクは、1つの主要なタスクを取得し、それをさらに小さなサブタスクに分割する階層的な方法で表すことができます。タスクは、GUIプレゼンテーションの目標を提供します。サブタスク間の情報の流れにより、ソフトウェアのGUIコンテンツの流れが決まります。
* GUIの設計と実装*-要件、タスク、ユーザー環境に関する情報を取得した後、デザイナーはGUIを設計し、コードに実装し、バックグラウンドで作業用ソフトウェアまたはダミーソフトウェアを使用してGUIを埋め込みます。その後、開発者が自己テストします。
テスト-GUIテストはさまざまな方法で実行できます。組織は社内検査を行うことができ、ユーザーの直接関与とベータ版のリリースはほとんどありません。テストには、ユーザビリティ、互換性、ユーザーの承認などが含まれます。

GUI実装ツール

デザイナーがマウスクリックでGUI全体を作成できるツールがいくつかあります。一部のツールは、ソフトウェア環境（IDE）に組み込むことができます。

GUI実装ツールは、GUIコントロールの強力な配列を提供します。ソフトウェアのカスタマイズについては、設計者はそれに応じてコードを変更できます。

さまざまな用途とプラットフォームに応じて、GUIツールにはさまざまなセグメントがあります。

例

モバイルGUI、コンピューターGUI、タッチスクリーンGUIなど。 GUIを構築するのに便利ないくつかのツールのリストを次に示します。

流体
AppInventor（Android）
LucidChart
ウェーブメーカー
ビジュアルスタジオ

ユーザーインターフェイスのゴールデンルール

ShneidermanとPlaisantの本（Designing the User Interface）で説明されているGUIデザインの黄金のルールとして、次のルールが言及されています。

一貫性の確保-同様の状況では、一貫したアクションのシーケンスが必要です。プロンプト、メニュー、およびヘルプ画面で同じ用語を使用する必要があります。一貫したコマンドを一貫して使用する必要があります。
頻繁にアクセスするユーザーがショートカットを使用できるようにする-ユーザーの操作回数を減らしたいという要望は、使用頻度とともに増加します。略語、ファンクションキー、隠しコマンド、マクロ機能は、エキスパートユーザーにとって非常に役立ちます。
有益なフィードバックを提供-オペレーターのアクションごとに、システムフィードバックが必要です。頻繁でマイナーなアクションの場合、対応は控えめである必要があり、まれでメジャーなアクションの場合、対応はより実質的でなければなりません。
閉鎖をもたらす設計ダイアログ-アクションのシーケンスは、開始、中間、終了のグループに編成する必要があります。一連のアクションの完了時の有益なフィードバックは、オペレータに達成の満足、安心感、緊急事態計画とオプションを頭から落とす信号を与えます。アクションのグループ。
シンプルなエラー処理を提供-可能な限り、ユーザーが重大なエラーを起こさないようにシステムを設計します。エラーが発生した場合、システムはそれを検出し、エラーを処理するためのシンプルでわかりやすいメカニズムを提供できるはずです。
アクションの簡単な反転を許可-ユーザーがエラーを取り消すことができることを知っているため、この機能は不安を和らげます。アクションの簡単な反転は、なじみのないオプションの調査を促進します。可逆性の単位は、単一のアクション、データ入力、またはアクションの完全なグループです。
内部統制のサポート-経験豊富なオペレーターは、システムを担当し、システムが自分のアクションに応答するという感覚を強く望んでいます。ユーザーがレスポンダーではなくアクションのイニシエーターになるようにシステムを設計します。
短期メモリの負荷を軽減-短期メモリでの人間の情報処理の制限により、ディスプレイをシンプルに保ち、複数ページのディスプレイを統合し、ウィンドウモーションの頻度を減らし、コードに十分なトレーニング時間を割り当て、ニーモニック、およびアクションのシーケンス。

ソフトウェア設計の複雑さ

複雑性という用語は、相互接続された複数のリンクと非常に複雑な構造を持つイベントまたは物事の状態を表します。ソフトウェアプログラミングでは、ソフトウェアの設計が実現されると、要素の数とそれらの相互接続が次第に巨大になり、一度に理解するのが難しくなります。

ソフトウェア設計の複雑さは、複雑さの指標と尺度を使用せずに評価することは困難です。 3つの重要なソフトウェアの複雑さの尺度を見てみましょう。

ハルステッドの複雑さの尺度

1977年、 Maurice Howard Halsteadは、ソフトウェアの複雑さを測定するためのメトリックを導入しました。 Halsteadのメトリックは、プログラムの実際の実装とその測定値に依存します。これらの測定値は、ソースコードの演算子とオペランドから静的に直接計算されます。 C/C ++/Javaソースコードのテスト時間、語彙、サイズ、難易度、エラー、および努力を評価できます。

Halsteadによれば、「コンピュータープログラムは、演算子またはオペランドのいずれかに分類できるトークンの集合と見なされるアルゴリズムの実装です」。 Halsteadメトリックは、プログラムを一連の演算子とそれに関連するオペランドと見なします。

彼は、モジュールの複雑さをチェックするためのさまざまな指標を定義しています。

Parameter	Meaning
n1	Number of unique operators
n2	Number of unique operands
N1	Number of total occurrence of operators
N2	Number of total occurrence of operands

ソースファイルを選択してその複雑さの詳細をMetric Viewerで表示すると、次の結果がMetric Reportに表示されます。

Metric	Meaning	Mathematical Representation
n	Vocabulary	n1 + n2
N	Size	N1 + N2
V	Volume	Length *Log2 Vocabulary
D	Difficulty	(n1/2)* (N1/n2)
E	Efforts	Difficulty * Volume
B	Errors	Volume/3000
T	Testing time	Time = Efforts/S, where S=18 seconds.

循環的複雑度の測定

すべてのプログラムには、実行する必要のあるステートメントを決定するタスクやその他の意思決定ステートメントを実行するために実行するステートメントが含まれます。これらの意思決定構造は、プログラムの流れを変えます。

同じサイズの2つのプログラムを比較すると、プログラムの制御が頻繁にジャンプするため、より多くの意思決定ステートメントを持つプログラムがより複雑になります。

McCabeは、1976年に、特定のソフトウェアの複雑さを定量化するための循環的複雑度測定を提案しました。 if-else、do-while、repeat-until、switch-case、gotoステートメントなどのプログラムの意思決定構造に基づいたグラフ駆動モデルです。

フロー制御グラフを作成するプロセス：

プログラムを小さなブロックに分割し、意思決定の構成要素で区切る。

これらの各ノードを表すノードを作成します。

次のようにノードを接続します。

制御がブロックiからブロックjに分岐できる場合 +弧を描く
出口ノードから入口ノードへ +円弧を描きます。

プログラムモジュールの循環的複雑度を計算するには、次の式を使用します-

V(G) = e – n + 2

Where
e is total number of edges
n is total number of nodes

サイクロマティック複雑度の測定

上記のモジュールの循環的複雑度は

e = 10
n = 8
Cyclomatic Complexity = 10 - 8 + 2
                      = 4

Pによると Jorgensen、モジュールの循環的複雑度は10を超えてはなりません。

ファンクションポイント

ソフトウェアのサイズを測定するために広く使用されています。ファンクションポイントは、システムが提供する機能に集中しています。システムの機能は、ソフトウェアの複雑さを測定するために使用されます。

ファンクションポイントは、外部入力、外部出力、論理内部ファイル、外部インターフェイスファイル、および外部照会という名前の5つのパラメーターをカウントします。ソフトウェアの複雑さを考慮するために、各パラメーターは単純、平均、または複雑にさらに分類されます。

ファンクションポイント

関数点のパラメーターを見てみましょう。

外部入力

外部からシステムへのすべての一意の入力は、外部入力と見なされます。 2つの入力が同じ形式であってはならないため、入力の一意性が測定されます。これらの入力は、データまたは制御パラメーターのいずれかです。

シンプル-入力カウントが少なく、内部ファイルへの影響が少ない場合
複雑-入力カウントが多く、より多くの内部ファイルに影響する場合
平均-単純と複雑の中間。

外部出力

システムによって提供されるすべての出力タイプは、このカテゴリにカウントされます。出力形式や処理が一意である場合、出力は一意と見なされます。

シンプル-出力数が少ない場合
複雑-出力数が多い場合
平均-単純と複雑の中間。

論理内部ファイル

すべてのソフトウェアシステムは、機能情報を維持し、適切に機能するために内部ファイルを維持します。これらのファイルは、システムの論理データを保持しています。この論理データには、機能データと制御データの両方が含まれる場合があります。

シンプル-レコードタイプの数が少ない場合
複雑-レコードタイプの数が多い場合
平均-単純と複雑の中間。

外部インターフェイスファイル

ソフトウェアシステムは、そのファイルを何らかの外部ソフトウェアと共有する必要がある場合があります。または、処理のために、または何らかの関数のパラメーターとしてファイルを渡す必要がある場合があります。これらのファイルはすべて、外部インターフェイスファイルとしてカウントされます。

シンプル-共有ファイルのレコードタイプの数が少ない場合
複雑-共有ファイルのレコードタイプの数が多い場合
平均-単純と複雑の中間。

外部からの問い合わせ

照会は入力と出力の組み合わせであり、ユーザーは入力として照会するデータを送信し、システムは照会の出力を処理してユーザーに応答します。クエリの複雑さは、外部入力および外部出力以上のものです。入力と出力が形式とデータの点で一意である場合、クエリは一意であると言われます。

シンプル-クエリの処理が少なく、少量の出力データが生成される場合
複雑-クエリが高いプロセスを必要とし、大量の出力データを生成する場合
平均-単純と複雑の中間。

システム内のこれらの各パラメーターには、クラスと複雑さに応じた重みが与えられます。以下の表は、各パラメーターに与えられた重みを示しています。

Parameter	Simple	Average	Complex
Inputs	3	4	6
Outputs	4	5	7
Enquiry	3	4	6
Files	7	10	15
Interfaces	5	7	10

上記の表は、未加工の関数ポイントを生成します。これらの機能ポイントは、環境の複雑さに応じて調整されます。システムは、14の異なる特性を使用して説明されます。

データ通信
分散処理
性能目標
操作構成の負荷
取引レート
オンラインデータ入力、
エンドユーザーの効率
オンライン更新
複雑な処理ロジック
再利用性
インストールが簡単
操作性
複数のサイト
変更を促進したい

次に、これらの特性係数は、以下に示すように0から5に評価されます

影響なし
偶発
適度な
平均
重要な
エッセンシャル

すべての評価がNとして合計されます。 Nの値の範囲は0〜70（14種類の特性x 5種類の評価）です。次の式を使用して、複雑度調整係数（CAF）を計算するために使用されます。

CAF = 0.65 + 0.01N

その後、

Delivered Function Points (FP)= CAF x Raw FP

このFPは、次のようなさまざまなメトリックで使用できます。

ソフトウェア実装

この章では、ソフトウェアの実装におけるプログラミング方法、ドキュメント、および課題について学習します。

構造化プログラミング

コーディングのプロセスでは、コードの行が増え続けるため、ソフトウェアのサイズが大きくなります。徐々に、プログラムの流れを覚えることはほとんど不可能になります。ソフトウェアとその基礎となるプログラム、ファイル、手順の構築方法を忘れると、プログラムの共有、デバッグ、変更が非常に難しくなります。これに対する解決策は、構造化プログラミングです。開発者がコードで単純なジャンプを使用する代わりにサブルーチンとループを使用することを推奨します。これにより、コードを明確にし、効率を向上させます。構造化プログラミングは、プログラマーがコーディング時間を短縮し、コードを適切に編成するのにも役立ちます。

構造化プログラミングには、プログラムのコーディング方法が記載されています。構造化プログラミングでは、3つの主要な概念を使用します。

トップダウン分析-ソフトウェアは常に合理的な作業を行うために作成されます。この合理的な作業は、ソフトウェア用語では問題として知られています。したがって、問題の解決方法を理解することが非常に重要です。トップダウン分析では、問題は小さな部分に分割され、それぞれに重要性があります。各問題は個別に解決され、手順は問題の解決方法について明確に述べられています。
モジュール式プログラミング-プログラミング中、コードは命令の小さなグループに分解されます。これらのグループは、モジュール、サブプログラム、またはサブルーチンと呼ばれます。トップダウン分析の理解に基づいたモジュール式プログラミング。プログラム内で「goto」ステートメントを使用してジャンプを阻止します。これにより、多くの場合、プログラムフローが追跡不可能になります。構造化プログラミングでは、ジャンプは禁止されており、モジュール形式が推奨されます。
構造化コーディング-トップダウン分析に関連して、構造化コーディングは、モジュールを実行順にさらに小さなコード単位に細分化します。構造化プログラミングでは制御構造を使用してプログラムのフローを制御しますが、構造化コーディングでは制御構造を使用して命令を定義可能なパターンに編成します。

関数型プログラミング

関数型プログラミングは、数学関数の概念を使用するプログラミング言語のスタイルです。数学の関数は、同じ引数を受け取ったときに常に同じ結果を生成する必要があります。手続き型言語では、プログラムのフローは手順を実行します。プログラムの制御は、呼び出されたプロシージャに転送されます。制御フローがあるプロシージャから別のプロシージャに転送されている間、プログラムはその状態を変更します。

手続き型プログラミングでは、同じ引数で呼び出されたときにプロシージャが異なる結果を生成する可能性があります。プログラム自体は呼び出し中に異なる状態になる可能性があるためです。これは、プロシージャプログラミングの欠点であると同時にプロパティであり、プロシージャ実行のシーケンスまたはタイミングが重要になります。

関数型プログラミングは、プログラムの状態に関係なく結果を生成する数学関数として計算の手段を提供します。これにより、プログラムの動作を予測できます。

関数型プログラミングでは、次の概念を使用します。

ファーストクラスおよび高次関数-これらの関数は、別の関数を引数として受け入れるか、結果として他の関数を返す機能を備えています。
純粋な関数-これらの関数には破壊的な更新は含まれていません。つまり、I/Oやメモリに影響を与えず、使用されていない場合は、プログラムの残りの部分を妨げることなく簡単に削除できます。
再帰-再帰は、関数がそれ自体を呼び出し、事前定義された条件が一致しない限り、その中のプログラムコードを繰り返すプログラミング手法です。再帰は、関数型プログラミングでループを作成する方法です。
厳密な評価-関数に引数として渡された式を評価する方法です。関数型プログラミングには、厳密（熱心）または非厳密（遅延）の2種類の評価方法があります。厳密な評価では、関数を呼び出す前に常に式が評価されます。厳密でない評価では、必要でない限り式は評価されません。
λ-calculus-ほとんどの関数型プログラミング言語は、型システムとしてλ-calculusを使用します。 λ式は、発生時に評価することで実行されます。

Common Lisp、Scala、Haskell、Erlang、およびF＃は、関数型プログラミング言語の例です。

プログラミングスタイル

プログラミングスタイルは、すべてのプログラマがコードを記述するためのコーディングルールのセットです。複数のプログラマーが同じソフトウェアプロジェクトで作業する場合、他の開発者が作成したプログラムコードを頻繁に使用する必要があります。すべての開発者が標準のプログラミングスタイルに従ってプログラムをコーディングしないと、これは退屈になり、時には不可能になります。

適切なプログラミングスタイルには、目的のタスクに関連する関数名と変数名の使用、適切なインデントの使用、読者の利便性のためのコードのコメント、およびコードの全体的な表示が含まれます。これにより、すべての人がプログラムコードを読みやすく、理解しやすくなり、デバッグとエラー解決が容易になります。また、適切なコーディングスタイルは、文書化と更新を容易にします。

コーディングのガイドライン

コーディングスタイルの実践は、組織、オペレーティングシステム、コーディング自体の言語によって異なります。

次のコーディング要素は、組織のコーディングガイドラインの下で定義できます。

命名規則-このセクションでは、関数、変数、定数、グローバル変数の命名方法を定義します。
インデント-これは行の先頭に残っているスペースで、通常2〜8個の空白または単一のタブです。
空白-通常、行末では省略されます。
演算子-数学演算子、代入演算子、論理演算子の記述規則を定義します。たとえば、代入演算子「=」には、「x = 2」のように前後にスペースが必要です。
制御構造-if-then-else、case-switch、while-untilの記述規則、および制御フローステートメント専用のネストされた形式。
行の長さと折り返し-1行に含める文字数を定義します。ほとんどの場合、行は80文字です。折り返しは、長すぎる場合に行を折り返す方法を定義します。
関数-これは、パラメーターの有無にかかわらず、関数を宣言および呼び出す方法を定義します。
変数-さまざまなデータ型の変数がどのように宣言および定義されるかについて言及しています。
コメント-これは重要なコーディングコンポーネントの1つです。コードに含まれるコメントは、コードが実際に行うことと他のすべての関連する説明を記述するためです。このセクションは、他の開発者向けのヘルプドキュメントの作成にも役立ちます。

ソフトウェアドキュメント

ソフトウェアのドキュメントは、ソフトウェアプロセスの重要な部分です。よく書かれたドキュメントは、ソフトウェアプロセスについて知るために必要な情報リポジトリの優れたツールと手段を提供します。ソフトウェアのドキュメントには、製品の使用方法に関する情報も記載されています。

よく管理されたドキュメントには、次のドキュメントが含まれている必要があります。

要件のドキュメント-このドキュメントは、ソフトウェア設計者、開発者、およびテストチームがそれぞれのタスクを実行するための重要なツールとして機能します。このドキュメントには、対象ソフトウェアの機能、非機能、および動作に関するすべての説明が含まれています。 +このドキュメントのソースは、ソフトウェアに関する以前に保存されたデータ、クライアント側で既に実行されているソフトウェア、クライアントのインタビュー、アンケート、調査などです。通常、それは、ハイエンドのソフトウェア管理チームとともにスプレッドシートまたはワープロ文書の形式で保存されます。 +このドキュメントは、開発されるソフトウェアの基盤として機能し、主に検証および検証フェーズで使用されます。ほとんどのテストケースは、要件ドキュメントから直接構築されます。
ソフトウェア設計ドキュメント-これらのドキュメントには、ソフトウェアの構築に必要なすべての必要な情報が含まれています。 （a）*高レベルソフトウェアアーキテクチャ、（b）ソフトウェア設計の詳細、（c）データフロー図、（d）*データベース設計 +これらのドキュメントは、開発者がソフトウェアを実装するためのリポジトリとして機能します。これらのドキュメントには、プログラムのコーディング方法に関する詳細は記載されていませんが、コーディングと実装に必要なすべての必要な情報が記載されています。
技術文書-これらの文書は、開発者と実際のコーダーによって管理されています。これらのドキュメントは、全体として、コードに関する情報を表しています。また、プログラマーは、コードの作成中に、コードの目的、コードの作成者、必要な場所、実行内容と実行方法、コードが使用する他のリソースなどにも言及します。 +技術文書は、同じコードで作業するさまざまなプログラマー間の理解を深めます。コードの再利用機能を強化します。デバッグが簡単で追跡可能になります。 +利用可能なさまざまな自動化ツールがあり、一部はプログラミング言語自体に付属しています。たとえば、javaにはコードの技術文書を生成するJavaDocツールが付属しています。
ユーザーマニュアル-このマニュアルは、上記のすべてのマニュアルとは異なります。以前のすべてのドキュメントは、ソフトウェアとその開発プロセスに関する情報を提供するために維持されています。ただし、ユーザーマニュアルでは、ソフトウェア製品がどのように機能し、目的の結果を得るためにどのように使用されるべきかを説明しています。 +これらのドキュメントには、ソフトウェアのインストール手順、ハウツーガイド、ユーザーガイド、アンインストール方法、およびライセンスの更新などの詳細情報を取得するための特別な参照が含まれる場合があります。

ソフトウェア実装の課題

ソフトウェアの実装中に開発チームが直面するいくつかの課題があります。それらのいくつかを以下に説明します。

コードの再利用-現在の言語のプログラミングインターフェイスは非常に洗練されており、膨大なライブラリ関数が装備されています。それでも、最終製品のコストを下げるために、組織管理者は、他のソフトウェア用に以前に作成されたコードを再利用することを好みます。プログラマーは、互換性チェックと再利用するコードの量を決定するために、大きな問題に直面しています。
バージョン管理-新しいソフトウェアが顧客に発行されるたびに、開発者はバージョンおよび構成関連のドキュメントを維持する必要があります。このドキュメントは、非常に正確で、時間通りに利用できる必要があります。
ターゲットホスト-組織で開発されているソフトウェアプログラムは、顧客側のホストマシン用に設計する必要があります。ただし、ターゲットマシンで動作するソフトウェアを設計することは不可能な場合があります。

ソフトウェアテストの概要

ソフトウェアテストは、ユーザーとシステム仕様から収集した要件に対するソフトウェアの評価です。テストは、ソフトウェア開発ライフサイクルのフェーズレベルまたはプログラムコードのモジュールレベルで実行されます。ソフトウェアテストは、検証と検証で構成されます。

ソフトウェア検証

検証とは、ソフトウェアがユーザーの要件を満たしているかどうかを調べるプロセスです。 SDLCの最後に実行されます。ソフトウェアが作成された要件に一致する場合、検証されます。

検証により、開発中の製品がユーザーの要件に従っていることを確認します。
検証は、「ユーザーがこのソフトウェアから必要とするすべてを試行する製品を開発していますか？」という質問に答えます。
検証では、ユーザーの要件に重点が置かれます。

ソフトウェア検証

検証は、ソフトウェアがビジネス要件を満たしているかどうかを確認するプロセスであり、適切な仕様と方法論に従って開発されます。

検証により、開発中の製品が設計仕様に従っていることを確認します。
検証は、「すべての設計仕様をしっかりと守ってこの製品を開発しているのですか？」
検証は、設計とシステムの仕様に集中します。

テストの対象は-

エラー-これらは開発者が実際にコーディングした間違いです。また、ソフトウェアの出力と目的の出力に違いがあり、エラーと見なされます。
障害-エラーが存在する場合、障害が発生します。バグとも呼ばれる障害は、システムの障害を引き起こす可能性のあるエラーの結果です。
障害-障害とは、システムが目的のタスクを実行できないことです。システムに障害が存在する場合、障害が発生します。

手動テストと自動テスト

テストは手動または自動テストツールを使用して実行できます。

手動-このテストは、自動テストツールを使用せずに実行されます。ソフトウェアテスターは、コードのさまざまなセクションとレベルのテストケースを準備し、テストを実行して結果をマネージャーに報告します。 +手動テストは時間とリソースを消費します。テスターは、正しいテストケースが使用されているかどうかを確認する必要があります。テストの大部分には手動テストが含まれます。
*自動化*このテストは、自動化されたテストツールを使用して実行されるテスト手順です。手動テストの制限は、自動テストツールを使用して克服できます。

テストでは、Internet ExplorerでWebページを開くことができるかどうかを確認する必要があります。これは手動テストで簡単に実行できます。しかし、Webサーバーが100万人のユーザーの負荷を処理できるかどうかを確認するために、手動でテストすることはまったく不可能です。

テスターが負荷テスト、ストレステスト、リグレッションテストを実施するのに役立つソフトウェアおよびハードウェアツールがあります。

テストアプローチ

テストは、次の2つのアプローチに基づいて実施できます。

機能テスト
実装テスト

実際の実装を考慮せずに機能をテストする場合、ブラックボックステストと呼ばれます。反対側はホワイトボックステストと呼ばれ、機能がテストされるだけでなく、実装方法も分析されます。

徹底的なテストは、完全なテストに最も望ましい方法です。入力値と出力値の範囲内のすべての可能な値がテストされます。値の範囲が大きい場合、現実世界のシナリオですべての値をテストすることはできません。

ブラックボックステスト

プログラムの機能をテストするために実行されます。「行動」テストとも呼ばれます。この場合のテスターには、一連の入力値とそれぞれの望ましい結果があります。入力の提供時に、出力が目的の結果と一致する場合、プログラムは「OK」でテストされ、それ以外の場合は問題があります。

ブラックボックステスト

このテスト方法では、コードの設計と構造はテスターに知られておらず、テストエンジニアとエンドユーザーはソフトウェアでこのテストを行います。

ブラックボックスのテスト手法：

等価クラス-入力は同様のクラスに分割されます。クラスの1つの要素がテストに合格すると、すべてのクラスが合格したと見なされます。
境界値-入力は上限値と下限値に分割されます。これらの値がテストに合格した場合、その間のすべての値も合格すると想定されます。
原因効果グラフ-以前の方法では、一度に1つの入力値のみがテストされます。原因（入力）–効果（出力）は、入力値の組み合わせを体系的にテストするテスト手法です。
ペアワイズテスト-ソフトウェアの動作は複数のパラメーターに依存します。ペアワイズテストでは、複数のパラメーターが異なる値に対してペアワイズでテストされます。
状態ベースのテスト-システムは入力の提供時に状態を変更します。これらのシステムは、その状態と入力に基づいてテストされます。

ホワイトボックステスト

コードの効率または構造を改善するために、プログラムとその実装をテストするために実施されます。「構造」テストとも呼ばれます。

ホワイトボックステスト

このテスト方法では、コードの設計と構造がテスターに知られています。コードのプログラマは、コードに対してこのテストを実施します。

以下は、ホワイトボックステストのテクニックです。

制御フローテスト-すべてのステートメントと分岐条件をカバーするテストケースを設定するための制御フローテストの目的。分岐条件は、trueとfalseの両方についてテストされるため、すべてのステートメントをカバーできます。
データフローテスト-このテスト手法は、プログラムに含まれるすべてのデータ変数をカバーすることを重視しています。変数が宣言および定義された場所と、変数が使用または変更された場所をテストします。

テストレベル

テスト自体は、SDLCのさまざまなレベルで定義できます。テストプロセスは、ソフトウェア開発と並行して実行されます。次のステージにジャンプする前に、ステージはテスト、検証、および検証されます。

ソフトウェアに隠れたバグや問題が残っていないことを確認するために、個別にテストが行われます。ソフトウェアはさまざまなレベルでテストされています-

単体テスト

コーディング中に、プログラマはそのプログラム単位でいくつかのテストを実行し、エラーがないかどうかを確認します。テストはホワイトボックステストアプローチで実行されます。ユニットテストは、開発者がプログラムの個々のユニットが要件に従って機能しており、エラーがないことを判断するのに役立ちます。

統合テスト

ソフトウェアのユニットが個別に正常に機能していても、ユニットが統合されていればエラーなく機能するかどうかを確認する必要があります。たとえば、引数の受け渡しやデータの更新など。

システムテスト

ソフトウェアは製品としてコンパイルされ、全体としてテストされます。これは、次のテストの1つ以上を使用して実現できます。

機能テスト-要件に対してソフトウェアのすべての機能をテストします。
パフォーマンステスト-このテストは、ソフトウェアの効率を証明します。ソフトウェアが目的のタスクを実行するのにかかる有効性と平均時間をテストします。パフォーマンステストは、さまざまな環境条件下でソフトウェアが高いユーザー負荷とデータ負荷を受ける負荷テストとストレステストによって行われます。
セキュリティと移植性-これらのテストは、ソフトウェアがさまざまなプラットフォームで動作することを意図しており、多くの人がアクセスするときに行われます。

受け入れ試験

ソフトウェアを顧客に引き渡す準備ができたら、最後のテスト段階を経て、ユーザーとのやり取りと応答をテストする必要があります。これは、ソフトウェアがすべてのユーザー要件に一致し、ユーザーがその表示や動作を好まない場合でも拒否される可能性があるため、重要です。

アルファテスト-開発者自身のチームが、まるで作業環境で使用されているかのようにシステムを使用してアルファテストを実行します。彼らは、ユーザーがソフトウェアのアクションにどのように反応するか、システムが入力にどのように応答するかを見つけようとします。
ベータテスト-ソフトウェアが内部でテストされた後、テスト目的でのみ本番環境で使用するためにユーザーに引き渡されます。これはまだ提供されている製品ではありません。開発者は、この段階のユーザーがわずかな問題をもたらすことを期待していますが、それらは出席するためにスキップされました。

回帰試験

ソフトウェア製品が新しいコード、機能、または機能で更新されるたびに、追加されたコードに悪影響があるかどうかを検出するために徹底的にテストされます。これは回帰テストとして知られています。

テストドキュメント

テストドキュメントはさまざまな段階で準備されます-

テスト前

テストはテストケースの生成から始まります。参考のために次の書類が必要です–

* SRSドキュメント*-機能要件ドキュメント
テストポリシードキュメント-これは、製品をリリースする前にテストをどこまで行う必要があるかを説明しています。
テスト戦略ドキュメント-テストチーム、責任マトリックス、およびテストマネージャーとテストエンジニアの権利/責任の詳細な側面に言及しています。
トレーサビリティマトリックスドキュメント-これはSDLCドキュメントであり、要件収集プロセスに関連しています。新しい要件が来ると、このマトリックスに追加されます。これらのマトリックスは、テスターが要件の原因を知るのに役立ちます。それらは前後にトレースできます。

テスト中

テストの開始中および実行中には、次のドキュメントが必要になる場合があります。

テストケースドキュメント-このドキュメントには、実施が必要なテストのリストが含まれています。ユニットテスト計画、統合テスト計画、システムテスト計画、受け入れテスト計画が含まれます。
テストの説明-このドキュメントは、すべてのテストケースとそれらを実行する手順の詳細な説明です。
テストケースレポート-このドキュメントには、テストの結果としてのテストケースレポートが含まれています。
テストログ-このドキュメントには、すべてのテストケースレポートのテストログが含まれています。

テスト後

テスト後に次のドキュメントが生成される場合があります。

テスト概要-このテスト概要は、すべてのテストレポートとログの集合分析です。ソフトウェアを起動する準備ができているかどうかをまとめてまとめています。ソフトウェアは、起動準備ができている場合、バージョン管理システムの下でリリースされます。

テストvs. 品質管理、品質保証および監査

ソフトウェアテストは、ソフトウェア品質保証、ソフトウェア品質管理、ソフトウェア監査とは異なることを理解する必要があります。

ソフトウェア品質保証-これらはソフトウェア開発プロセスの監視手段であり、それによってすべての対策が組織の基準に従って行われることが保証されます。この監視は、適切なソフトウェア開発方法に従っていることを確認するために行われます。
ソフトウェア品質管理-これは、ソフトウェア製品の品質を維持するためのシステムです。ソフトウェア製品の機能的側面と非機能的側面が含まれることがあり、組織の善意を高めます。このシステムにより、顧客は要件に合った高品質の製品を受け取り、「使用に適した」製品として認定されます。
ソフトウェア監査-これは、組織がソフトウェアを開発するために使用した手順のレビューです。開発チームから独立した監査チームが、SDLCのソフトウェアプロセス、手順、要件、およびその他の側面を調査します。ソフトウェア監査の目的は、そのソフトウェアとその開発プロセスが標準、規則、規制に準拠していることを確認することです。

ソフトウェア保守の概要

ソフトウェアメンテナンスは、今日ではSDLCの一部として広く受け入れられています。ソフトウェア製品の配信後に行われたすべての変更および更新を表します。いくつかの理由、変更が必要な理由がありますが、そのいくつかを以下に簡単に説明します。

市場条件-課税や簿記の維持方法などの新たに導入された制約など、時間の経過とともに変化するポリシーにより、変更の必要性が生じる場合があります。
クライアントの要件-時間の経過とともに、お客様はソフトウェアの新しい機能を要求する場合があります。
ホストの変更-ターゲットホストのハードウェアやプラットフォーム（オペレーティングシステムなど）が変更された場合、適応性を維持するためにソフトウェアの変更が必要です。
組織の変更-組織の強度の低下、別の会社の買収、新しいビジネスへの進出など、クライアント側でビジネスレベルの変更がある場合、元のソフトウェアを変更する必要が生じる場合があります。

メンテナンスの種類

ソフトウェアの寿命では、メンテナンスの種類はその性質に応じて異なる場合があります。これは、一部のユーザーがバグを発見したための単なる日常的なメンテナンス作業の場合もあれば、メンテナンスのサイズや性質に基づいたそれ自体の大きなイベントの場合もあります。以下は、その特性に基づいたいくつかのタイプのメンテナンスです。

修正メンテナンス-これには、ユーザーによって発見された、またはユーザーエラーレポートによって結論付けられた問題を修正または修正するために行われた変更および更新が含まれます。
アダプティブメンテナンス-これには、ソフトウェア製品を最新の状態に保つために適用され、技術とビジネス環境の絶えず変化する世界に合わせた修正と更新が含まれます。
完全なメンテナンス-これには、ソフトウェアを長期間使用できるようにするために行われた変更と更新が含まれます。これには、ソフトウェアを改良し、信頼性とパフォーマンスを向上させるための新しい機能、新しいユーザー要件が含まれています。
予防保守-これには、ソフトウェアの将来の問題を防ぐための変更と更新が含まれます。現時点では重要ではないが、将来深刻な問題を引き起こす可能性がある問題に対処することを目的としています。

メンテナンス費用

報告によると、メンテナンスのコストが高いことが示唆されています。ソフトウェアメンテナンスの見積もりに関する調査では、メンテナンスのコストは、ソフトウェアプロセスサイクル全体のコストの67％と同じくらい高いことがわかりました。

メンテナンスコストチャート

ソフトウェアメンテナンスのコストは、平均してすべてのSDLCフェーズの50％以上です。以下のような、メンテナンスコストが高くなるさまざまな要因があります。

メンテナンスコストに影響する実際の要因

ソフトウェアの標準年齢は、最大10〜15年と見なされます。
古いソフトウェアは、メモリとストレージ容量が少ない低速のマシンで動作することを目的としており、最新のハードウェアで新しく提供される拡張ソフトウェアに対して挑戦し続けることはできません。
技術が進歩するにつれて、古いソフトウェアを維持するのは費用がかかります。
ほとんどのメンテナンスエンジニアは初心者であり、試行錯誤を行って問題を修正します。
多くの場合、変更はソフトウェアの元の構造を簡単に傷つけ、その後の変更を困難にします。
多くの場合、変更は文書化されずに残り、将来さらに競合が発生する可能性があります。

メンテナンスコストに影響するソフトウェア終了要因

ソフトウェアプログラムの構造
プログラミング言語
外部環境への依存
スタッフの信頼性と可用性

メンテナンス活動

IEEEは、順次メンテナンスプロセスアクティビティのフレームワークを提供します。繰り返し使用することができ、拡張してカスタマイズされたアイテムとプロセスを含めることができます。

メンテナンスアクティビティ

これらのアクティビティは、次の各フェーズと密接に関連しています。

識別とトレース-変更または保守の要件の識別に関するアクティビティが含まれます。ユーザーによって生成されるか、システム自体がログまたはエラーメッセージを介して報告する場合があります。ここでは、メンテナンスタイプも分類されます。
分析-変更は、安全およびセキュリティへの影響を含むシステムへの影響について分析されます。予想される影響が深刻な場合、代替ソリューションを探します。必要な変更のセットは、要求仕様に具体化されます。変更/保守のコストが分析され、推定が完了します。
設計-交換または変更が必要な新しいモジュールは、前の段階で設定された要件仕様に対して設計されています。検証と検証のためにテストケースが作成されます。
実装-新しいモジュールは、設計ステップで作成された構造化設計の助けを借りてコーディングされます。すべてのプログラマーは、ユニットテストを並行して行うことが期待されます。
システムテスト-新しく作成されたモジュール間で統合テストが行われます。統合テストは、新しいモジュールとシステムの間でも実行されます。最後に、回帰テスト手順に従って、システム全体がテストされます。
受け入れテスト-システムを内部でテストした後、ユーザーの助けを借りて受け入れテストを行います。この状態で、ユーザーが次の反復で対処するために対処または指摘された問題に苦情を申し立てた場合。
配信-受け入れテストの後、システムは小規模な更新パッケージまたはシステムの新規インストールによって組織全体に展開されます。最終テストは、ソフトウェアが配信された後、クライアント側で行われます。 +必要に応じて、ユーザーマニュアルのハードコピーに加えて、トレーニング施設が提供されます。
メンテナンス管理-構成管理は、システムメンテナンスの重要な部分です。バージョン管理ツールを使用して、バージョン、セミバージョン、またはパッチ管理を管理できます。

ソフトウェアのリエンジニアリング

機能に影響を与えることなく、現在の市場に維持するためにソフトウェアを更新する必要がある場合は、ソフトウェアのリエンジニアリングと呼ばれます。これは、ソフトウェアの設計が変更され、プログラムが書き直される徹底的なプロセスです。

レガシーソフトウェアは、市場で入手可能な最新のテクノロジーでチューニングを続けることができません。ハードウェアが陳腐化するにつれて、ソフトウェアの更新は頭痛の種になります。ソフトウェアが時間とともに古くなっても、機能は変わりません。

たとえば、当初Unixはアセンブリ言語で開発されました。言語Cが登場すると、アセンブリ言語での作業が困難だったため、UnixはCで再設計されました。

これ以外に、プログラマーは、ソフトウェアのいくつかの部分が他の部分よりも多くのメンテナンスを必要とし、リエンジニアリングも必要であることに気付くことがあります。

リエンジニアリングのプロセス

リエンジニアリングプロセス

*決定*リエンジニアリングするもの。ソフトウェア全体ですか、それとも一部ですか？
*実行*既存のソフトウェアの仕様を取得するためのリバースエンジニアリング。
*必要に応じて*プログラムを再構築します。たとえば、関数指向プログラムをオブジェクト指向プログラムに変更します。
*必要に応じて*データを再構築します。
*リエンジニアリングされたソフトウェアを入手するために、フォワードエンジニアリングの概念を適用します。

ソフトウェアのリエンジニアリングで使用される重要な用語はほとんどありません

リバースエンジニアリング

これは、既存のシステムを徹底的に分析、理解することにより、システム仕様を達成するプロセスです。このプロセスは、逆SDLCモデル、つまりより低い抽象化レベルを分析することにより、より高い抽象化レベルを取得しようとします。

既存のシステムは以前に実装された設計であり、それについては何も知りません。次に、設計者はコードを見てリバースエンジニアリングを行い、設計を取得しようとします。設計を手に入れて、彼らは仕様を結論付けようとします。したがって、コードからシステム仕様に逆順になります。

リバースエンジニアリング

プログラムの再編

これは、既存のソフトウェアを再構築および再構築するプロセスです。同じプログラミング言語で、またはあるプログラミング言語から別のプログラミング言語にソースコードを再配置することがすべてです。再構築には、ソースコードの再構築とデータの再構築のいずれか、または両方が含まれます。

再構築はソフトウェアの機能には影響しませんが、信頼性と保守性を向上させます。非常に頻繁にエラーを引き起こすプログラムコンポーネントは、変更したり、再構築で更新したりできます。

廃止されたハードウェアプラットフォームでのソフトウェアの信頼性は、再構築によって削除できます。

フォワードエンジニアリング

フォワードエンジニアリングは、リバースエンジニアリングによってダウンした手元の仕様から目的のソフトウェアを取得するプロセスです。過去に既にソフトウェアエンジニアリングが行われていることを前提としています。

フォワードエンジニアリングは、ソフトウェアエンジニアリングプロセスと同じですが、唯一の違いがあります。リバースエンジニアリングの後に常に実行されます。

フォワードエンジニアリング

コンポーネントの再利用性

コンポーネントは、システム内の独立したタスクを実行するソフトウェアプログラムコードの一部です。それは小さなモジュールまたはサブシステム自体である場合があります。

例

Webで使用されるログイン手順はコンポーネントと見なすことができ、ソフトウェアの印刷システムはソフトウェアのコンポーネントと見なすことができます。

コンポーネントは、機能の凝集度が高く、結合率が低い、つまりそれらは独立して動作し、他のモジュールに依存せずにタスクを実行できます。

OOPでは、設計されたオブジェクトは懸念事項に非常に固有であり、他のソフトウェアで使用される可能性が少なくなります。

モジュール式プログラミングでは、モジュールは他の多くのソフトウェアプログラムで使用できる特定のタスクを実行するようにコーディングされています。

ソフトウェアコンポーネントの再利用に基づいたまったく新しい分野があり、コンポーネントベースソフトウェアエンジニアリング（CBSE）として知られています。

コンポーネント

さまざまなレベルで再利用できます

アプリケーションレベル-アプリケーション全体が新しいソフトウェアのサブシステムとして使用される場合。
コンポーネントレベル-アプリケーションのサブシステムが使用される場所。
モジュールレベル-機能モジュールが再利用される場所。 +ソフトウェアコンポーネントは、さまざまなコンポーネント間の通信を確立するために使用できるインターフェイスを提供します。

再利用プロセス

要件を同じにしてコンポーネントを調整する方法と、コンポーネントを同じにして要件を変更する方法の2種類の方法を採用できます。

再利用プロセス

要件仕様-機能要件と非機能要件が指定されており、既存のシステム、ユーザー入力、またはその両方の助けを借りて、ソフトウェア製品が準拠する必要があります。
設計-これは標準のSDLCプロセスステップでもあり、ソフトウェア用語の観点から要件が定義されます。システム全体の基本アーキテクチャとそのサブシステムが作成されます。
コンポーネントの指定-ソフトウェア設計を検討することにより、設計者はシステム全体をより小さなコンポーネントまたはサブシステムに分離します。 1つの完全なソフトウェア設計は、連携して動作する膨大なコンポーネントの集合に変わります。
適切なコンポーネントの検索-ソフトウェアコンポーネントリポジトリは、機能性と目的のソフトウェア要件に基づいて、設計者が一致するコンポーネントを検索するために参照します。
コンポーネントを組み込む-一致したすべてのコンポーネントは、完全なソフトウェアとしてそれらを形作るために一緒に梱包されます。

ソフトウェアケースツールの概要

CASEは* C omputer A ided S oftware E * ngineeringの略です。つまり、さまざまな自動化ソフトウェアツールを使用したソフトウェアプロジェクトの開発と保守です。

ケースツール

CASEツールは、SDLCアクティビティの自動化に使用されるソフトウェアアプリケーションプログラムのセットです。 CASEツールは、ソフトウェアプロジェクトマネージャー、アナリスト、およびエンジニアがソフトウェアシステムを開発するために使用します。

分析ツール、設計ツール、プロジェクト管理ツール、データベース管理ツール、ドキュメントツールなど、ソフトウェア開発ライフサイクルのさまざまな段階を簡素化するためのCASEツールがいくつかあります。

CASEツールを使用すると、プロジェクトの開発が加速され、望ましい結果が得られ、ソフトウェア開発の次の段階に進む前に欠陥を発見できます。

CASEツールのコンポーネント

CASEツールは、特定のSDLCステージでの使用に基づいて、次の部分に大きく分けることができます。

中央リポジトリ-CASEツールには、共通の統合された一貫性のある情報のソースとして機能する中央リポジトリが必要です。中央リポジトリは、製品の仕様、要件ドキュメント、関連レポートおよび図、管理に関するその他の有用な情報が保存される中央ストレージの場所です。中央リポジトリはデータ辞書としても機能します。 + ケースツール
上部ケースツール-上部CASEツールは、SDLCの計画、分析、設計段階で使用されます。
ローワーケースツール-ローワーケースツールは、実装、テスト、およびメンテナンスに使用されます。
統合されたケースツール-統合されたCASEツールは、要件の収集からテストおよび文書化まで、SDLCのすべての段階で役立ちます。

CASEツールは、同様の機能、プロセスアクティビティ、および他のツールと統合する機能を備えている場合、グループ化できます。

ケースツールの範囲

CASEツールの範囲はSDLC全体に及びます。

ケースツールの種類

次に、さまざまなCASEツールについて簡単に説明します

ダイアグラムツール

これらのツールは、システムコンポーネント、データ、およびさまざまなソフトウェアコンポーネント間での制御フローとシステム構造をグラフィカルな形式で表すために使用されます。たとえば、最先端のフローチャートを作成するためのフローチャート作成ツール。

プロセスモデリングツール

プロセスモデリングは、ソフトウェアの開発に使用されるソフトウェアプロセスモデルを作成する方法です。プロセスモデリングツールは、管理者がソフトウェア製品の要件に従ってプロセスモデルを選択または変更するのに役立ちます。たとえば、EPF Composer

プロジェクト管理ツール

これらのツールは、プロジェクトの計画、コストと労力の見積もり、プロジェクトのスケジューリング、およびリソースの計画に使用されます。マネージャーは、プロジェクトの実行をソフトウェアプロジェクト管理の上記のすべての手順に厳密に準拠する必要があります。プロジェクト管理ツールは、組織全体でプロジェクト情報をリアルタイムで保存および共有するのに役立ちます。たとえば、Creative Pro Office、Trac Project、Basecamp。

ドキュメンテーションツール

ソフトウェアプロジェクトの文書化は、ソフトウェアプロセスの前に開始され、SDLCのすべてのフェーズを経て、プロジェクトの完了後に行われます。

ドキュメント作成ツールは、テクニカルユーザーとエンドユーザー向けのドキュメントを生成します。技術ユーザーは、システムマニュアル、リファレンスマニュアル、トレーニングマニュアル、インストールマニュアルなどを参照する開発チームの社内専門家です。エンドユーザードキュメントには、ユーザーマニュアルなど、システムの機能と操作方法が記載されています。たとえば、ドキュメントのDoxygen、DrExplain、Adobe RoboHelp。

分析ツール

これらのツールは、要件を収集し、不整合、ダイアグラムの不正確さ、データの冗長性、または誤った欠落を自動的にチェックするのに役立ちます。たとえば、要件分析には360、Accompa、CaseCompleteを受け入れ、全体分析にはVisible Analystを受け入れます。

設計ツール

これらのツールは、ソフトウェア設計者がソフトウェアのブロック構造を設計するのに役立ちます。ソフトウェアのブロック構造は、洗練技術を使用して、より小さなモジュールにさらに分割できます。これらのツールは、各モジュールの詳細とモジュール間の相互接続を提供します。たとえば、アニメーションソフトウェアデザイン

構成管理ツール

ソフトウェアのインスタンスは、1つのバージョンでリリースされます。構成管理ツールは以下を扱います–

バージョンおよびリビジョン管理
ベースライン構成管理
変更管理

CASEツールは、自動追跡、バージョン管理、リリース管理によりこれを支援します。たとえば、Fossil、Git、Accu REV。

変更管理ツール

これらのツールは、構成管理ツールの一部と見なされます。ベースラインが修正された後、またはソフトウェアが最初にリリースされたときに、ソフトウェアに加えられた変更を処理します。 CASEツールは、変更追跡、ファイル管理、コード管理などを自動化します。また、組織の変更ポリシーの実施にも役立ちます。

プログラミングツール

これらのツールは、IDE（統合開発環境）、組み込みモジュールライブラリ、シミュレーションツールなどのプログラミング環境で構成されています。これらのツールは、ソフトウェア製品の構築に包括的な支援を提供し、シミュレーションとテストの機能を備えています。たとえば、C、Eclipseでコードを検索するCscope。

プロトタイピングツール

ソフトウェアプロトタイプは、対象のソフトウェア製品のシミュレーションバージョンです。プロトタイプは、製品の初期のルックアンドフィールを提供し、実際の製品のいくつかの側面をシミュレートします。

プロトタイプCASEツールには、基本的にグラフィカルライブラリが付属しています。ハードウェアに依存しないユーザーインターフェイスとデザインを作成できます。これらのツールは、既存の情報に基づいて迅速なプロトタイプを構築するのに役立ちます。さらに、ソフトウェアプロトタイプのシミュレーションも提供します。たとえば、Serenaプロトタイプ作曲家、Mockup Builder。

Web開発ツール

これらのツールは、フォーム、テキスト、スクリプト、グラフィックなどのすべての関連要素を持つWebページの設計を支援します。 Webツールは、開発中のものと完成後の様子をライブプレビューすることもできます。たとえば、Fontello、Adobe Edge Inspect、Foundation 3、Brackets。

品質保証ツール

ソフトウェア組織の品質保証は、組織の標準に従って品質の適合を保証するために、ソフトウェア製品を開発するために採用されたエンジニアリングプロセスと方法を監視しています。 QAツールは、構成および変更管理ツールとソフトウェアテストツールで構成されています。たとえば、SoapTest、AppsWatch、JMeter。

メンテナンスツール

ソフトウェアメンテナンスには、ソフトウェア製品の配信後の変更が含まれます。自動ロギングおよびエラー報告技術、自動エラーチケット生成、および根本原因分析は、SDLCのメンテナンスフェーズでソフトウェア組織を支援するいくつかのCASEツールです。たとえば、障害追跡用のBugzilla、HP Quality Center。 Software-engineering-se-exams-questions-answers Software-engineering-interview-questions Software-engineering-details?id=com.tutorialspoint

Software-engineering-quick-guide

ソフトウェアエンジニアリングの概要

定義

ソフトウェアの進化

ソフトウェア進化の法則

E-Typeソフトウェアの進化

ソフトウェアのパラダイム

ソフトウェア開発パラダイム

ソフトウェア設計パラダイム

プログラミングのパラダイム

ソフトウェアエンジニアリングの必要性

優れたソフトウェアの特徴

運用中

過渡的

メンテナンス

ソフトウェア開発ライフサイクル

SDLCアクティビティ

コミュニケーション

要件の収集

実現可能性調査

システム分析

ソフトウェア設計

コーディング

テスト

統合

実装

操作とメンテナンス

配置

ソフトウェア開発パラダイム

滝モデル

反復モデル

スパイラルモデル

V –モデル

ビッグバンモデル

ソフトウェアプロジェクト管理

ソフトウェアプロジェクト

ソフトウェアプロジェクト管理の必要性

ソフトウェアプロジェクトマネージャー

管理人

管理プロジェクト

ソフトウェア管理活動

プロジェクト計画

スコープ管理

プロジェクト見積もり

プロジェクト推定手法

分解技術

経験的推定手法

プロジェクトのスケジューリング

資源管理

プロジェクトリスク管理

リスク管理プロセス

プロジェクトの実行と監視

プロジェクトコミュニケーション管理

構成管理

ベースライン

変更管理

プロジェクト管理ツール

ガントチャート

PERTチャート

リソースヒストグラム

クリティカルパス分析

ソフトウェア要件

要件エンジニアリング

要件エンジニアリングプロセス

実現可能性調査

要件の収集

ソフトウェア要件仕様

ソフトウェア要件の検証

要件の引き出しプロセス

要件の引き出し手法

インタビュー

調査

アンケート

タスク分析

ドメイン分析

ブレーンストーミング

プロトタイピング

観察

ソフトウェア要件の特性

ソフトウェア要件