2023年 システムアナリスト --- システム企画

1. システム計画のステップ

1. 予備調査: 企業の戦略目標に従って、企業の現在の状況とシステムの運用状況を分析します。
2. システムの目標を決定する: システムのサービス範囲の品質などを決定します。
3. サブシステムの構成の分析: システムの分割とサブシステムの機能の特定
4. システムの実装計画を作成します。サブシステムの優先順位を分析し、開発順序を決定します。
5. フィージビリティスタディ：フィージビリティスタディレポートを作成し、フィージビリティディスカッションミーティングを開催します
6. システム構築計画の策定: 実現可能性調査レポートで提案されたさまざまな技術指標を分析および比較し、さまざまな仮定の前提条件を実装し、システム構築計画を策定し、システム設計タスク ブックを作成します。

2. 実現可能性調査の分類

1. 経済的実現可能性: 建設、運用コスト、およびプロジェクト建設後の経済的利益の可能性を含む費用便益分析。
2. 技術的実現可能性: 技術的リスク分析、既存の技術がシステムの目標の実現をサポートできるかどうか、および既存のリソース (従業員、技術の蓄積、コンポーネント ライブラリ、ソフトウェア、ハードウェアの状態など) がシステムの実装をサポートするのに十分かどうか。計画。
3. Legal Feasibility (Social Feasibility): 国内の法律や政策と矛盾しないこと
4. ユーザーの可用性:

3. 費用便益分析

1. コスト カテゴリ:

1. 1. 固定費：アウトプット、管理職の賃金、事務費、固定資産の減価償却費、社員教育費、広告宣伝費、技術開発費などで変動しない。
   2. 変動費：生産量、直接材料費、製品包装費、外注費、開発賞与などによる変動費
   3. 複合コスト: 光熱費、電話代、品質保証スタッフの給与、設備電力など。
   4. 直接費: プロジェクトへの直接投資、プロジェクト チーム スタッフの給与、材料費
   5. 間接費: プロジェクトに配分される費用、光熱費、スタッフのトレーニング費用

1. 収益分類:

1. 1. 有形の利益: 経済的利益と呼ばれ、お金の時間価値、投資回収期間、投資収益率などの指標によって測定できます。有形の利益は、一時的な経済的利益と非一時的な利益に分けることができます。
   2. 無形の利益：定量化できない利益と呼ばれ、主に定性的および心理的に測定され、直接的な定量的比較を行うことは困難です

1. ブレークスルー分析:

1. 1. 売上＝固定費＋変動費＋税金＋利益（通常時）
   2. 売上＝固定費＋変動費＋税金（損益分岐点）

1. 正味現在価値分析:

1. 1. 静的および動的な問題: 動的分析では、お金の時間価値、通常は割引率が考慮されます
   2. 現在価値: n 年後に F 元を稼ぐことができる場合、これらのお金の現在価値の価​​値は P に制限されます。

1. 投資リターン:

1. 1. 投資回収期間とは、投資回収期間を指します。静的投資回収装置と動的回収装置に分けられる
   2. 静的な回収期間 (お金の時間価値に関係なく)
   3. 動的な回収期間 (貨幣の時間価値要因を考慮)
   4. 回収期間の計算式: 累積割引額が正の値を示し始める年数 -1+|前年度の累積割引額|/当年度の割引額
   5. 投資回収率 = 1 / 投資回収期間 * 100%

4. ソフトウェア工学

1. システム計画：事前調査、システム目的の分析、サブシステム構成、実装計画案、フィージビリティスタディ、システム構築計画の策定、システム設計業務（システム構築計画、実装計画）
2. システム分析: ビジネス プロセス分析、データおよびデータ フロー分析、ソフトウェア要件分析、ネットワーク要件分析; システム要件仕様、ソフトウェア要件仕様、確認テスト計画、システム テスト計画、予備ユーザー マニュアル
3. システム設計：ソフトウェアアーキテクチャ設計、ソフトウェア概略設計、詳細設計、ネットワーク設計、アーキテクチャ設計書、概略設計指示書、詳細設計指示書、プログラム仕様書、概略試験計画書、詳細試験計画書、各種設計図
4. システム実装：ソフトウェアコーディング、ソフトウェアユニット、統合、システムテスト、統合配線、ソースコード、ユニットテスト、統合テストレポート、操作マニュアル
5. システム受入：確認試験、試運転、確認試験報告書、プロジェクト受理報告書

5. ソフトウェア開発モデル

1. プロトタイプモデル：ユーザーの要件を明確にするのに役立つ、「要件が不明なシーン」に適した典型的なプロトタイプ開発方法モデル。
2. ウォーターフォール モデル:

1. 1. ウォーターフォール モデルは、ソフトウェア ライフ サイクルの各アクティビティを、要件分析、設計、コーディング、運用、保守など、直線的な順序で接続された複数の段階として定義するモデルです。
   2. ウォーターフォール モデルの特徴は、理解しやすく、管理コストが低く、各段階には対応する製品があり、各段階には明確な境界とシーケンス要件があり、エラーが発生すると、プロジェクト全体が新たなスタートに追いやられます。
   3. 一般に明確な要件または二次開発として表現される、明確な要件を持つプロジェクト、またはデータ処理プロジェクトに適用可能

1. 増分モデル: ウォーターフォール モデルの基本コンポーネントとプロトタイプ実装の反復機能を統合すると、複数の利用可能なバージョンをリリースでき、多くの場合、コア機能が最初に完成します. これに基づいて、各反復で新しい増分リリースが行われます ,コア機能は完全にテストでき、各インクリメントが運用可能な製品をリリースすることを強調しています。
2. スパイラルモデル：ウォーターフォールモデルとエボリューションモデルの特徴を併せ持つリスク分析の導入が代表的な特徴であり、最大の特徴はリスク分析の追加です。これは、計画、リスク分析、実装エンジニアリング、顧客評価のサイクルで構成され、最初のスパイラルはコンセプト プロジェクトから始まります。
3. V モデル: テスト フェーズに焦点を当てるのではなく、プロジェクト全体でテストが実行されることを強調します。これはテスト開発モデルです。
4. Fountain モデル: 典型的なオブジェクト指向モデル。繰り返し、ギャップがなく、ソフトウェア開発を複数の段階に分割することが特徴ですが、兄の段階には明確な境界がなく、繰り返し交差する可能性があります。
5. 迅速なアプリケーション開発 RAD:

1. 1. コンセプト: RAD はウォーターフォール モデルの高速バリアントであり、従来のライフ サイクルがはるかに速い開発方法に適しています. 非常に短い開発サイクルを強調し、通常はコンポーネント ベースの開発方法を適用して迅速な開発を実現します。 .
   2. プロセス: ビジネス モデリング、データ モデリング、プロセス モデリング、アプリケーション生成、テスト、配信
   3. 適用性: RAD にはモジュール化の要件が比較的高い. 特定の機能をモジュール化できない場合, そのコンポーネントに問題がある. 高性能が指標であり, システムコンポーネントに適応するように調整する必要がある場合, RAD も可能性があります.効果的ではない; RAD は開発者と顧客に一連の需要分析を短期間で完了することを要求し、どちらか一方の不適切な協力は失敗につながる.技術的リスクが高い場合に適しています。

1. ユニファイド プロセス (UP、RUP はユニファイド プロセスの略)

1. 1. 典型的な機能は、ユースケース主導型、アーキテクチャ中心型、反復型、インクリメンタル型です。統一プロセスは、プロジェクトを 4 つの異なるフェーズに分割します。

1. 1. 1. 概念段階 (初期段階): ユーザー コミュニケーションと計画活動の 2 つの側面が含まれ、主なモデルとしてユース ケースの定義と改良が重視されます。

1. 1. 1. 1. プロジェクトの青写真ドキュメント (コア要件、主な機能、主な制約)
         2. ユーザーモデル
         3. プロジェクト計画

1. 1. 1. 精緻化フェーズ: ユーザー コミュニケーションとモデリング アクティビティが含まれ、分析モデルと設計モデルの作成に重点が置かれ、クラス定義とアーキテクチャ表現が重視されます。

1. 1. 1. 1. アーキテクチャ設計を完了する
         2. リスクの高い要素を排除する

1. 1. 1. ビルド フェーズ: 設計を実装、統合、およびテストに変換する

1. 1. 1. 1. UML モデル
         2. テストケース

1. 1. 1. 引き渡し段階: テストと評価のために製品をユーザーにリリースし、ユーザーの意見を収集してから、製品を繰り返し修正して完全なものにします。

1. 1. 1. 1. 実行可能なソフトウェア製品
         2. ユーザーマニュアル
         3. ユーザーサポートプログラム

1. アジャイル開発: アジャイル開発は、小さなステップで実行するという考えを持つ、小さなチームや小さなプロジェクトに適した、人中心の反復型の段階的な開発方法です。一般的なアジャイル開発手法には、エクストリーム プログラミング、クリスタル手法、スクラム手法、および適応型ソフトウェア開発手法があります。

エクストリーム プログラミング XP は、コミュニケーション、シンプルさ、フィードバック、勇気の 4 つの価値を提案する軽量な開発手法です。5 つの原則: 迅速なフィードバック、単純な仮定、漸進的な改訂、変更の提唱、質の高い作業。12 のベスト プラクティス: ゲームの計画、メタファー、スモール リリース、シンプルなデザイン、テスト ファースト、リファクタリング、ペア プログラミング、コードの共同所有権、継続的インテグレーション、週 40 時間労働、スレッド化されたクライアント、およびコーディング標準。

Crystal メソッドは、頻繁な配信を強調し、プロジェクトごとに異なる一連の戦略、規則、および方法論が必要であると考えています。

スクラム方式の核となるのは、反復的で増分的なデリバリー、および実際に 30 日で実行できるソフトウェアの反復的な開発とデリバリーです。

アダプティブ ソフトウェア開発 (ASD 手法) の中心には、推測、共同作業、学習という 3 つの非線形で重複する開発フェーズがあります。

ここでいうオープン コーディングとオープン ソースとは、オープン ソース コミュニティの仕組みを指します。オープン ソース プロジェクトの特徴は、プログラム開発者が地理的に広く分散していることです。一般的なアジャイル手法では、プロジェクト メンバーが同じ場所で作業することが重視されるため、他のアジャイル手法とは異なります。オープン ソース コードの顕著な特徴は、エラー トラブルシューティングの高度な並列性です。エラーを見つけた人は誰でも、ソース コードを修正するための「パッチ」ファイルをメンテナに送信できます。これらの「パッチ」または新しいコードは、メンテナーによってソース コード リポジトリに組み込まれます。

コードの共通ドライバ開発方法

FDD では、プログラミング開発者はリード プログラマーと「クラス」プログラマーの 2 つのカテゴリに分けられます。リード プログラマーは最も経験豊富な開発者であり、プロジェクト コーディネーター、デザイナー、指導者であり、「クラス」プログラマーは主にオリジナルのソース コードの作成を行います。

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

4 つのレベルのリバース エンジニアリング:

1. 実装レベル：プログラムの抽象構文木、記号表、プロセスの設計表現を含む
2. 構造レベル: コール グラフ、構造グラフ、プログラムおよびデータ構造など、プログラム コンポーネント間の相互依存性を反映する情報が含まれます。
3. 機能レベル: プログラム セグメントの機能と、データや制御フロー モデルなどのプログラム セグメント間の関係を反映する情報が含まれます。
4. ドメイン レベル: エンティティなどのプログラム コンポーネントまたはプログラムと、エンティティ関係モデルなどのアプリケーション ドメインの概念との間の対応を反映する情報が含まれます。

リバース エンジニアリングの関連概念:

1. 再構築: 再構築とは、システム記述形式を同じレベルの抽象化で変換することを指します。
2. 設計回復: 設計回復とは、ツールを使用して、データ設計、全体構造設計、およびプロセス設計に関する情報を既存のプログラムから抽出することを指します。
3. リバース エンジニアリング (リバース エンジニアリング): リバース エンジニアは、プログラムを分析し、ソース コードよりも高い抽象度でプログラム表現プロセスを確立しようとし、リバース エンジニアによって設計された回復プロセス
4. フォワード エンジニアリング: フォワード エンジニアリングは、既存のシステムから設計情報を回復するだけでなく、その情報を使用して既存のシステムを変更またはリファクタリングし、全体的な品質を向上させるプロセスです。
5. リエンジニアリング（re-engineering）：リエンジニアリングとは、リバースエンジニアリング、新しい要件検討プロセス、フォワードエンジニアリングの3つのステップを含む、既存のシステムの再開発のプロセスです。