システムアーキテクチャ設計の専門スキル・ソフトウェアエンジニアリングソフトウェアのテストと保守

シリーズ記事の目次

システムアーキテクチャ設計の専門スキル・ネットワークの企画・設計（3） 【システムアーキテクト】
システムアーキテクチャ設計の専門スキル・システムセキュリティ分析・設計（4） 【システムアーキテクト】
システムアーキテクチャ設計の高度なスキル・ソフトウェアアーキテクチャ設計（1） ) 【システムアーキテクト】
システムアーキテクチャ設計の高度なスキル・システム品質特性とアーキテクチャ評価(2) 【システムアーキテクト】
システムアーキテクチャ設計の高度なスキル・ソフトウェア信頼性分析・設計(3) 【システムアーキテクト】

现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.

1. ソフトウェアテスト

できるだけ早く、継続的にテストを行う
プログラマは、自分で設計したプログラムのテストを避ける
有効かつ妥当なデータだけでなく、無効で不合理なデータも選択する必要がある
修正後は、回帰テストを実行して、
未発見のエラーの数とエラーの数を確認する必要があるプログラム内で見つかったエラーの数。に比例します。

1.1 テストの種類

1.2 テスト段階

1.3 ソフトウェアのデバッグ

テストはエラーを見つけること、デバッグはエラー コードとその原因を見つけることです。

デバッグでは、エラーの正確な位置を特定し、問題の原因を特定して修正を試み、修正後に回帰テストを実行する必要があります。

デバッグ方法には、総当たり法、バックトラッキング法（エラーが発生した場所から遡って行う）、原因除去法（演繹法、帰納法、二分法など、考えられる原因をすべて見つけて一つずつ取り除く方法）があります。 ）。

1.4 ソフトウェアのメトリクス

ソフトウェアには 2 つの属性があります。外部属性は、管理者とユーザーの属性を指します。これらは直接測定でき、一般にパフォーマンスの指標となります。内部属性とは、信頼性など、間接的にのみ測定できるソフトウェア製品自体の属性を指します。

McCabe 計量: 循環的複雑度としても知られ、有向グラフ内の有向エッジの数が m、ノードの数が n であると仮定すると、この有向グラフの循環的複雑度は m-n+2 です。

m と n の意味を混同しないように注意してください。最も単純なループを使用して、特別な値についてこの式を覚えておくことができます。さらに、プログラム フローチャートの場合、各分岐エッジ (接続) は有向エッジであり、各 A ステートメントは(ステートメントボックス) は頂点です。

2. ソフトウェアのメンテナンス

2.1. レガシーシステムの進化戦略

レガシー システムとは、基本的に、新しく変化するビジネス ニーズに合わせて変更および進化することができない情報システムを指します。

レガシー システム評価の目的は、レガシー システムをより深く理解することです。レガシー システムは、レガシー システム進化の基礎であり、レガシー システム進化プロジェクトの出発点です。主な評価方法には、システムの技術レベル、ビジネス価値、および関連する企業特性の測定が含まれ、その結果は治療戦略を選択するための基礎となります。

• 変革戦略、高レベル、高価値領域、つまりレガシーシステムは技術内容が高く、それ自体が大きな活力を持っています。このシステムはビジネス価値が高く、基本的に企業の業務運営と意思決定支援のニーズを満たすことができます。このようなシステムは短期間しか構築できない可能性があり、そのようなレガシー システムの進化戦略はトランスフォーメーションと呼ばれます。この変革には、システム機能の強化とデータ モデルの変革という 2 つの側面が含まれます。システムの機能強化とは、レガシーシステム自体は変更せずに、オリジナルシステムをベースに新たなアプリケーション要件を追加することを指し、データモデルの変換とは、レガシーシステムの古いデータモデルを新しいデータモデルに変換することを指します。
• 継承戦略、低レベル、高価値領域、つまり、レガシー システムは技術的な内容が低く、企業運営の機能要件またはパフォーマンス要件を満たしているが、高い商業的価値を持っています。企業の現在のビジネスは依然として密接に依存しています。システム上で。レガシー システムのこの進化戦略は継承と呼ばれます。新しいシステムを開発する場合、レガシー システムの機能モデルおよびデータ モデルと完全な互換性がある必要があります。ビジネスの継続性を確保するには、一定期間新旧システムを並行して稼働させ、その後徐々に新システムに切り替える必要があります。
• 統合戦略、高レベル、低価値領域、つまりレガシー システムは技術的内容は高いが、ビジネス価値は低く、特定の部門 (または子会社) のビジネス管理のみを完了する可能性があります。この種のシステムは、それぞれのローカル領域ではうまく機能しますが、企業全体では、そのようなシステムが複数存在します。異なるシステムは異なるプラットフォームと異なるデータ モデルに基づいており、情報の島を形成しています。このレガシーはシステムの進化戦略です。統合。
• 廃止戦略、低レベル、低価値領域、つまりレガシー システムは技術的な内容が低く、ビジネス価値が低いです。この種のレガシー システムの進化戦略は、排除、つまりレガシー システムに代わる新しいシステムの包括的な再開発です。完全な排除は極端な戦略です。一般に、企業のビジネスが根本的に変化し、レガシー システムが基本的に企業運営のニーズに適合しなくなったか、レガシー システムの保守要員と保守文書が失われています。評価の結果、古いシステムを改修するよりも、レガシー システムを完全に削除してまったく新しいシステムを開発する方が費用対効果が高いことがわかりました。

2.2. 新旧システム間の変換戦略

新旧システム間の変換を実装する場合、通常は次の 3 つの変換戦略があります。

• 直接変換戦略は、新しいシステムがそれほど複雑ではない場合、または既存のシステムがまったく使用できない場合に適しており、新しいシステムは変換前に詳細かつ厳密なテストを受ける必要があります。
• 並行移行戦略では、新システムと既存システムを一定期間並行して運用し、試行期間を経た後、正式に既存システムを新システムに置き換えます。
• セグメント化された変換戦略は、ステップバイステップ変換戦略とも呼ばれ、直接変換方法と並列変換方法を組み合わせたもので、バッチでステップバイステップ変換を採用します。一般に、この方法はスムーズな運用を保証でき、コストもそれほど高くないため、または既存のシステムが比較的安定しており、独自のビジネス開発ニーズや新旧間の変換に適応できるため、大規模なシステムに適しています。非常にリスクの高いシステム（たとえば、オンライン注文、請求書発行システム、銀行の中間業務システムなど）では、セグメント化された変換戦略を採用することもできます。セグメント化された変換戦略の利点は、新旧システム間の変換ショックが比較的小さく、ユーザーに受け入れられやすいことです。しかし、段階的なアプローチのため、新旧システム間の移行サイクルが長すぎると同時に、需要の変化が新システムの安定性に比較的大きな影響を与えます。さらに、セグメント化された移行戦略にはシステムの設計と実装に一定の要件があり、移行プロセス中に新旧システム間のインターフェイスを開発し、段階的な移行目標と計画を策定する必要があります。

2.3. データの変換と移行

データ移行には大きく分けて、系切り替え前のツールによる移行、系切り替え前の手入力、系切り替え後の新システムによる生成の3つがあります。

データ移行の実装は、データ移行前の準備、データの変換と移行、データ移行後の検証の 3 つの段階に分けることができます。準備作業は次の 7 つの側面で行う必要があります。

(1) データの保存方法、データ量、データの期間など、移行するデータ ソースの詳細な説明。
(2) 新旧システムのデータベースのデータディクショナリを構築し、既存システムの履歴データの品質分析を実施し、新旧システムのデータ構造の差異を分析します。
(3) 新旧システム間のコードデータの差分解析。
(4) 新旧システムデータベーステーブル間のマッピング関係を確立し、マッピングできないフィールドに対処します。
(5) ETL ツールを開発または購入して展開します。
(6) データ変換のためのテスト計画と検証手順を作成します。
(7) データ変換に関する緊急措置を講じる。

データの移行が完了したら、移行されたデータを検証する必要があります。データ移行後の検証は、移行の品質を確認すると同時に、新システムを正式に稼働できるかどうかを判断する重要な判断材料でもあります。移行されたデータは、次の 2 つの方法で検証できます。
(1) 移行されたデータの品質分析。
(2) 新旧システムのクエリデータの比較検査。

2.4. ソフトウェアの保守性に影響を与える要因

• 【わかりやすさ】とは、ソースコードや関連ドキュメントを読んだときの、ソフトウェアの機能や動作の理解しやすさを指します。
• 【Modability】とは、ソフトウェアの改変の容易さを指します。
• 【テスト容易性】とは、ソフトウェアプログラムが正しいかどうかの検証の容易さを指します。
  テスト容易性が優れたソフトウェアとは、通常、ソフトウェア設計がシンプルで複雑さが低いことを意味します。ソフトウェアが複雑になればなるほど、テストが難しくなるからです。
• 【信頼性】 ソフトウェアの信頼性が高いほど、メンテナンスが必要になる可能性が低くなります。
• [移植性] とは、ある環境からソフトウェアを移植して、新しい環境で正しく実行できる容易さを指します。
  ソフトウェアの保守ではソフトウェアの動作環境の変化がつきものですが、移植性の高いソフトウェアであれば保守の可能性が低くなります。

2.5. ソフトウェアメンテナンスの種類

ソフトウェア保守は単にエラーを修正するだけではなく、新機能の追加や既存機能の変更、全般的な改善など、ユーザーの要望や提案に応えるために徹底的な保守が必要であり、ソフトウェア保守の重要な部分です。

• 事後保全[バグ修正]: 正確性維持とも呼ばれ、システムの開発段階で発生したが、システムのテスト段階でまだ発見されていないエラーを修正すること[バグやエラーを修正する]ことを指します。
• 適応型メンテナンス[緊急事態]:環境変化 [外部環境、データ環境] に適応するためにアプリケーション ソフトウェアを変更することを指します。
• 完全維持[新要件]：機能拡張や性能向上のための修正。
• 予防保守[将来に向けて]:将来のソフトウェアおよびハードウェア環境の変化に適応するために、システムが削除されることなくさまざまな変化に適応できるように、新しい予防機能を積極的に追加する必要があります。例えば、将来のレポート形式の変更に対応するために、特殊レポート機能は一般レポート作成機能に変更されます。