情報システム開発論

システムの移行・保守

学修目標

  • 移行作業の手順と作業内容
  • 保守作業の内容と留意点

システムの移行

  • 周到な計画,準備,オリエンテーションが必要

移行の事前準備

  • 要員計画
    • 増員の検討
    • 勤務体制
    • 教育訓練
  • 運用ドキュメントの点検
    • 各種マニュアルの点検/修正
  • 運用体制の整備
    • 体制の確認
    • チェックシート
    • ファイル管理表
  • データの移行準備
    • データの整備や不足分の作成
    • トランザクション件数やトラフィックの調査
  • 設備負荷の調査
    • コンピュータ資源への負荷
    • オンライン負荷
    • 回線負荷
    • ファイル容量

移行作業要件

  • 時期
    • 移行時期の検討
    • 区切りのよい時期
      • 忙しい
    • 作業時間の取れる時期
      • 区切りが悪い
  • オリエンテーション
    • 新システムのユーザへの説明
  • 教育およびユーザマニュアル
    • エンドユーザへの教育
    • わかりやすいマニュアルの準備
  • 並行処理および切り替え
    • 切り替え方法の検討
      • 徐々に行う
      • 暫く並行処理をする

移行実施形態

  • 並行移行
    • 現行システムと並行運用後切り替える
      • 直ちに旧システムに戻せる
      • 高コスト
  • 一括移行(ワンポイント切り替え)
    • 一気に新システムに切り替える
      • 単純で移行期間も短い
      • 障害時の影響が大きい

移行計画書

  • 計画段階で立案
  • 設計・構築段階から準備

移行要員計画

  • 要員数
  • 勤務体制
  • 教育訓練

マスタファイルの作成

  • 既存システムのマスタファイルから移行
    • 不要データの削除
    • 不足データの作成

システム開発最終評価

  • 目的を明確にする
    • 項目毎に細分化し,定量化
  • 評価方法
    • 定量的評価
      • 数量的な評価
    • 定性的評価
      • 質的な評価
  • 評価項目
    • 経済的評価
      • システム費用(開発費,運用費)
      • システム効果(直接的効果,間接的評価)
    • 性能的評価
      • 効率性
      • 適時性
      • 正確性
      • 信頼性
      • 柔軟性
      • 安全性
      • 機密性

システムの保守

  • 常に運用可能な状態に維持すること
  • 作業量,費用とも増大
  • 重要性が充分認識されていない
  • 充分な準備と検討が必要

システム保守の管理上の要件

  • 保守専任の体制で臨む
  • 保守担当者は設計フェイズから参加する
    • 全体を把握し,目的を理解する
  • 開発体制に似た保守体制をとる
  • データ管理者を設ける
    • 入出力のチェックも行う
  • ドキュメント/ライブラリ管理者を設ける
  • ユーザの窓口となる担当者を設ける
    • 保守担当者と作業を分ける

システム保守体制の確立と要員計画

  • 業務別の保守体制
    • 責任の所在が明確
    • ユーザからの要求に素早く対応できる
    • コスト面でも有利
    • 開発と保守の兼任という体制をとることも多い
  • システム単位の保守体制
    • システム毎に保守グループを作る

システム保守手順の設計

  • 保守作業の内容
    • 修正作業
      • プログラムの誤り
    • 変更作業
      • 環境の変化(データ環境,処理環境)
    • 改良作業
      • 処理機能の改善
  • 保守作業の注意点
    • 修正作業の注意点
      • 対応が済み次第,障害分析を行い,ドキュメントとして残す
    • 変更/改良作業の注意点
      • 作業内容を充分理解するための時間が必要

システム保守要員の教育

  • 運用スケジュール
    • 通常
    • 例外
  • 起動・停止処理手順
  • 実行手順
  • 出力情報の配付手順
  • 障害時対策方法とリカバリ手順
  • 事務処理作業手順
  • 交代時の引継事項の確認

プログラムの修正と保守

  • なぜ修正が必要なのか
  • どれくらいの作業量になるのか
  • 品質やユーザ満足度にどう影響するのか
  • 保守ルールを作り,それを遵守する保守体制をとる

プログラム修正と保守管理上の要件

  • 修正に関する情報を必ず記録
  • 修正要求手順,プログラム管理ルールの確立
  • バージョン管理
    • バージョン番号とリビジョン番号を付ける
  • 世代管理
    • 管理対象の世代範囲を決める

プログラムの保守体制

  1. 要求者はプログラム修正票に記入し,保守グループに提出
  2. 修正票の内容を,修正要求ファイルに入力
  3. ユーザ連絡係が修正票を受け取り,影響を受ける業務に関する面倒を見る
  4. ユーザ連絡係は修正票を保守リーダに提出して検討してもらう
    また,状況をユーザに報告したり,スケジュールや理由を修正要求ファイルに記録する
  5. 保守リーダがスケジュールを立ててチームに割り当てる
    ユーザ連絡係は要求者に知らせたり,修正要求ファイルの更新を行う
  6. 大きなものは保守統括者の承認を得る

リエンジニアリング

  • ソフトウェアの再利用
  • CASEツールを利用*1し既存システムを再利用する
  • リバースエンジニアリング*2実施後,フォワードエンジニアリング*3を適用し,再構築する

*1 上流工程の仕様を変更して下流工程を自動生成する。
*2 既に動作しているシステムを分析し,その仕様書を導きだす。即ち「プログラム」→「仕様書」
*3 通常のシステム開発の流れ。即ち「仕様書」→「プログラム」

トップ   編集 凍結解除 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2006-12-13 (水) 07:26:07 (4633d)