情報処理.

Presentation on theme: "情報処理."— Presentation transcript:

1 情報処理

2 システムの利用範囲 身の回りのシステムには、どんなものがあるのか？また、どんな人が利用しているのか？
日ごろ利用しているサービスや興味のあるITサービスについて どんなシステムを開発したいか？

3 業務系システム データ入力を中心とするシステム 定型的な業務 入出庫、仕入、売上、請求書発行など
売上データや在庫データを管理するので、間違ってはダメ！ データ項目に漏れがないかしっかり確認する 業務の流れを分析し、例外処理を事前に検討し、構築する

4 情報系システム データを出力活用するためのシステム 表示中心のシステム 非定型的な業務 売上分析、財務分析、データウェアハウスなど
企業戦略などによって変化する 使い勝手や使い方のノウハウが重要 使われ方や表示スピードを見て、次第に改良していく

5 ITサービスの11分野 （ITスキル標準 IT skill standard、ITSS ）
マーケティング セールス コンサルタント ITアーキテクト プロジェクトマネジメント ITスペシャリスト アプリケーションスペシャリスト ソフトウェアデベロップメント カスタマサービス ITサービスマネジメント エデュケーション

6 資格・試験 情報処理技術者試験センター IPA http://www.jitec.jp/1_08gaiyou/gaiyou.html
ベンダー試験 　　Sun　Oracle　Cisco　など

7 サイト紹介 ＠IT http://www.atmarkit.co.jp/ SQL
勉強会　福岡開催

8 システムの形態 スタンドアロン・システム（一台） ネットワーク・システム（大型コンピューターに複数の端末装置を接続）
LAN（ローカル・エリア・ネットワーク） WAN（ワイド・エリア・ネットワーク）

9 処理のタイミング オンライン・リアルタイム処理 即座に結果を返す ＜例＞POS、銀行ATM、JRの座席予約 バッチ処理
一定のデータがたまって、まとめて処理する ＜例＞給与計算、国勢調査、売上集計

10 開発プロセス 要件定義 システム設計 基本設計 外部設計 内部設計 開発実施 総合テスト システムテスト 本番切替

11 要件定義とは 開始条件 ユーザ側で要求事項が整理されている事。 システム開発案件を受注し、契約が締結されている事。 目的
業務をシステム化するときにユーザの要求をまとめるため ⇒要求定義書 要求を実現するために、システム化の要件をまとめるため ⇒要件定義書 システム化の範囲を明確にし、システム開発にかかる工数や費用を見積もるため 担当 要求定義、要件定義は、ユーザー中心 ユーザ側で関係部門の担当者を集めて、システム化のチームを発足し、要求事項の導出やとりまとめ、要件定義を行う 開発者は、情報システムに関する専門知識を提供し、ユーザの要件定義作業を支援

12 要件定義の方法 ユーザはシステム化したい事を明確に定義し、開発者に漏れなく伝える。
ユーザは自らの業務を定義。いつ、誰が、どこで何を、どのようにしているのか、何の為にそれをしているのかをひとつずつ記述。 業務上何が問題になっているのかを挙げていく。問題に対してどのように解決するのかを記述。 解決方法には、｢その業務を止める｣、｢アウトソーシングする｣、｢運用を変える｣、｢システム化する｣等があり、コスト面や体制面、関係者への影響等、いろいろな側面から検討して、決定。 解決方法の中から「システム化する」ものについて、開発者は情報システムの専門家の立場で助言

13 要件定義の確認 課題は、なにか？ 原因は？ 何時まで続くか？ 何時までに解決しないといけないか？ 放置するとどのような影響？
どのように解決しようとしているか？ なぜ、その解決方法？ 解決したら、どんな効果が見込めるか？ どの部署の誰の担当？ システム化しなかったら？

14 要件定義書の項目 NO 部門 部門担当者 業務名 課題 課題分類コード 対処方法 対処方法分類コード
課題 課題分類コード 対処方法 対処方法分類コード (業務プロセス変更、業務廃止、システム変更、新規システム化等) 実現の可能性 優先度 期限 備考

15 要件定義の成果物 業務定義書 現行業務フロー 要求事項一覧 課題一覧 議事録 要件定義書 ユーザー側と開発側の合意をとること！

16 システム設計 システム概要定義 システムの目的（期待する効果） システムの範囲（対象の業務・対象部署・実現する機能）
システムの前提条件（できる事・できない事・実現の程度） システムの概要（機能概要・運用処理概要） システム方式設計 ハードウェア （サーバ・PC・プリンタ・機種・CPU・メモリ・ハードディスク）構成図 ネットワーク （回線・モデム・ルータ・ハブ・ブリッジ・リピータ・回線速度）構成図 ソフトウェア（ソフトウェア名・バージョン）構成図

17 基本設計 機能一覧 要件定義書から機能の一覧を作成 機能に名前をつける 機能をサブシステム毎に分類 機能定義 機能の目的・範囲・実現方法
画面一覧、帳票一覧 ID・名前、使用目的、主な項目を挙げる 処理フロー 処理の流れ 画面の遷移 帳票の出力タイミング バッチ処理の流れを

18 外部設計 目的 画面や帳票、外部システムとのインターフェイス等を設計 画面設計の方法 画面イメージを作成
画面のサイズ、色調、各項目の配置等は標準規約に従う 操作性についても標準規約に従う メニュー構成を決める 画面遷移図を作成 ※入力チェックや画面遷移ルール等の詳細は内部設計

19 外部設計 帳票設計の方法 帳票イメージを作成 帳票のサイズ、各項目の配置等は標準規約に従う 一覧表の場合、明細の並び順を決める
コード設計の手順 コード化対象を洗い出す コード化対象の特性やデータ量を基にコード構成やサイズを検討 データ量の増加や状況の変化に対し、拡張性の側面から見直す コード一覧を作成 コードの管理方法について検討

20 外部設計 インターフェイス設計の方法 データの受け渡し媒体を外部システム毎に決める 各データのレイアウトを定義 データベース論理設計の方法
帳票や画面からデータを洗い出し、データ一覧作成 （ID、データ名、データの分類属性、データの説明 ） グループ化したものをエンティティとする⇒ER図作成 エンティティをテーブルとし、テーブル一覧作成 （テーブルID、テーブル名、テーブルの説明 ） テーブル定義書作成 （ID、テーブル名、データID、データ名、データ型、サイズ、制約（キー項目・NULL値・値の範囲等）、データの説明 ）

21 内部設計 目的 内部処理やビジネスルール、データ検索・編集・更新処理等を設計 画面設計の方法 画面のビジネスルールを記述
データ入力チェックルールを記述 初期値、デフォルト値を定義 データ検索ルールを記述 データ追加・更新・削除ルールを記述 画面遷移ルールを記述 エラー処理を記述

22 内部設計 帳票設計の方法 帳票のビジネスルールを記述 データ検索ルールを記述 印字項目編集ルールを記述 初期値、デフォルト値を定義
エラー処理を記述 インターフェイス設計の方法 インターフェイスのビジネスルールを記述 データ項目編集ルールを記述

23 内部設計 データベース物理設計の方法 データのライフサイクル（半永久・年単位・半年・月単位・週単位・日単位・一時等）を決定
更新特性（検索・挿入・更新・削除）や１日の更新量を決定 現在のデータ量、データのライフサイクル、更新特性、１日の更新量を考慮しながら、5年後位のデータ量を見積もる I/Oが分散するように配置 更新特性を考慮しながら、初期ロード時の領域使用率を決定 アクセスパスを考慮しながら、インデックスを設定

24 製造と単体テスト 目的 内部設計書に基づき、プログラムを作成 単体テストを実施し、内部設計書通りにプログラムが作成されていることを確認
製造の方法 コーディング規約に従ってコーディング 雛形を作っておけば、コーディング規約が守りやすく、生産性も上がる 新規でコーディングする場合は、コメントから書き始めると構造化しやすくなる 同じような処理は共通モジュール化し、保守性を良くする。 内部設計書を基に単体テスト仕様書を作成 共通のチェックリスト（初期化、エラーハンドリング、ガーベッジコレクション等 ）で、単体テスト仕様書の作成を簡略化できる

25 結合テスト 目的 プログラム間のインターフェイスにおいてデータの連携が正しく行われる事を確認 結合テストの方法 結合テスト計画を立てる
修正にかかる工数や体制を予め取っておく 結合テスト仕様書は外部設計書や内部設計書を基に作成 データパターンを漏れなく洗い出す 機能毎にデータパターンを整理 結合テスト計画書や結合テスト仕様書のレビューを行い、テストパターンやテスト項目の過不足、テストの妥当性についてチェック プログラム間を通して、一連の機能を検証 結合テスト結果を評価し、次の工程に進むべきかどうかの判定

26 総合テスト 目的 サブシステム間のインターフェイスにおいてデータの連携が正しく行われる事を確認 総合テストの方法 総合テスト計画を立てる
修正にかかる工数や体制を予め取っておく 総合テスト仕様書は基本設計書や外部設計書を基に作成 サブシステム間のインターフェイスのデータパターンを漏れなく洗い出す 機能毎にデータパターンを整理 総合テスト計画書や総合テスト仕様書のレビューを行い、テストパターンやテスト項目の過不足、テストの妥当性についてチェック サブシステム間を通して、一連の機能を検証 総合テスト結果を評価し、次の工程に進むべきかどうかの判定

27 システムテスト 目的 ハードウェア、ソフトウェア、アプリケーションの関係において信頼性や性能に問題のない事を確認 システムテストの方法
システムテスト計画を立てる 修正にかかる工数や体制を予め取っておく システムテスト仕様書はシステム設計書を基に作成 システムテスト計画書やシステムテスト仕様書のレビューを行い、テストパターンやテスト項目の過不足、テストの妥当性についてチェック システムテストにて、性能テスト(パフォーマンステスト)と障害テスト システムテスト結果を評価し、次の工程に進むべきかどうかの判定

28 システムテスト 性能テストの方法 本番運用と同等以上のデータを準備
本番運用と同等以上のトランザクションを発生させるツール、もしくはオペレータを準備 サーバの各種資源(CPU・メモリ等)やネットワークの使用率を測定できるようにしておく テストの条件、試行回数、測定方法、体制、役割、スケジュールを決めておく

29 システムテスト 障害テストの方法 想定できる限りの障害パターンを洗い出す 障害発生時の状態を想定しておく 障害パターン毎に復旧手順を確認
効率良くテストができるよう、手順を考えておく 障害復旧にかかる時間を測定 想定外の復旧手順を記録し、障害復旧手順書を修正

30 運用テスト 目的 業務の流れに沿ってシステムのテストを行い、期待する結果が出る事を確認 業務担当者がシステムの操作や運用に慣れる

31 運用テストの方法 受入テストと兼ねることがある 運用テスト計画を立てる 修正にかかる工数や体制を予め取っておく
運用テスト計画書や運用テスト仕様書のレビューを行い、テストパターンやテスト項目の過不足、テストの妥当性についてチェック 本番データを使用 現行システムがある場合、同じ入力を行い、同じ出力結果が出る事を確認 新旧比較を行う事により、検証作業効率を上げる事ができる 業務サイクル(日次・週次・月次・随時・四半期・半期・年次)を仮定してテスト テスト仕様書は要件定義書や基本設計書を基に作成 例外的な業務処理も行ってみる 故意に入力ミスを行ってみる 処理中に電源を落とす等、障害を発生させ、復旧できる事を確認する。また、復旧に要する時間を測定 運用テスト結果を評価し、次の工程に進むべきかどうかの判定

32 受入テスト 目的 ユーザーが業務の流れに沿ってシステムのテストを行い、システムがユーザーの要求仕様通りになっている事を確認
システムを受け入れ、本番稼動させるかどうかを判定

33 受入テストの方法 運用テストと兼ねることがある ユーザーの都合を確認し、受入テストの計画を立てる
受入テスト環境を設定する。通常は本番環境を使用 納入するシステムがユーザーの要求仕様通りになっているかを確認していただく 受入テストは要件定義書に基づいて 受入テストはユーザーが行い、開発者はそれを支援 不具合が発見された場合は、ユーザーと協議の上、期日を設定して修正 要求仕様通りになっていない場合は、ユーザーと協議の上、期日を設定して修正 受入テストの結果を基に本番稼働判定会議 受入テストが合格であれば、ユーザーから検収書をいただく

34 導入・本番切替 開始条件 本番稼動判定会議にてユーザの承認が得られている事 ！

35 導入・本番切替 導入計画 移行期間 前提条件 移行範囲 移行対象 移行方針 移行体制 作業項目 作業内容 作業工数 優先順位 役割分担
移行期間 前提条件 移行範囲 移行対象 移行方針 移行体制 作業項目 作業内容 作業工数 優先順位 役割分担 移行手順 移行方法 移行ツール 制約条件 タイムチャート チェックリスト 検証対象 検証方法 検証ツール バックアップ リカバリー

36 導入・本番切替 導入作業 導入計画 導入手順 復旧手順 導入前バックアップ 本番環境設定 データベース設定 ネットワーク設定
導入計画 導入手順 復旧手順 導入前バックアップ 本番環境設定 データベース設定 ネットワーク設定 アプリケーション設定 バッチ運行管理設定 データ移行 導入後バックアップ 稼働確認 導入後バックアップのリストア 最終確認

37 開発工程 ①要件のヒアリング ②要件整理 ③開発規模の見積もり ④仮スケジュールの作成 ⑤要件確認書・提案書の作成 ⑥発注 ⑦詳細ヒアリング
⑧設計 ⑨開発 ⑩テスト ⑪リリース ⑫納品 ⑬運用管理 ソースファイル・JavaDoc・外部設計書 データベース定義書・環境構築手順書etc 納品物

38 開発モデル ウォーターフォールモデル 手戻りが発生しないように厳密なチェックをしながらすすめる スパイラルモデル
　　手戻りが発生しないように厳密なチェックをしながらすすめる スパイラルモデル 　　作業工程を分割して、ユーザーからの認識のずれを補正しながら、螺旋階段を上る プロトタイピングモデル 　　試作品でユーザーの評価を得ながら開発する

39 プロジェクト管理 PMBOK（ぴんぼっく） Project Management Body of Knowledge
プロジェクト管理に関する知識体系のガイドでプロジェクト活動を管理するための基本的な考え方、手法をまとめたもの

40 品質管理 品質の良いソフトウェアとは、どういうものか？ ①プログラムのバグがない （設計書とプログラムの不一致） ②ユーザーの使い勝手が良い
（ユーザーニーズと設計書の不一致）

41 ソフトウェア品質特性(ISO/IEC9126) 機能性（functionality） 信頼性（reliability）
使用性（usability） 効率性（efficiency） 保守性（maintainability） 移植性（portability）

42 個人情報保護法 個人情報が適正に取り扱われることを目的とする法律 2005年4月に施行 プライバシーポリシー
企業が個人情報を取り扱う際の、個人情報に対する考え方やルールなどをまとめた指針。 どのような目的で、どのような情報を集め、どのように利用するのかといったことを明記している。

43 品質管理活動 QC（quality control） 品質管理活動 TQC（total quality control）
総合的品質管理 / 全社的品質管理 「１人ひとりが品質向上を意識して改善提案を行い、全社的な品質を向上しよう」 という取り組み

44 品質のシフト 当たり前品質 当然備えているべき品質特性 魅力的品質 プラスアルファが備わったもの アジア各国の追い上げを突き放すため、
魅力的品質へシフトしている。

45 ドキュメントとレビュー 単独レビュー 自分自身で行う 内部レビュー メンバーが集まって行う ユーザーレビュー ユーザーも交えて行う
手間は、かかるが、３段階のレビューで品質向上！

46 外注管理

47 外注契約 基本契約書 会社と会社で最初の１回のみ。
秘密保持、委託業務範囲、委託形態、責任事項、免責事項、損害賠償事項、契約変更や解約条件など 個別契約書（「注文書」と「注文請書」の場合もある） プロジェクトごとに契約を結ぶ。 委託具体的内容、納品物、納期、体制、作業場所、管理方法、金額、支払方法、検収方法など

48 協力会社とのコミュニケーション 打ち合わせ議事録 進捗確認 変更管理（変更連絡書） 質問管理（課題管理表） 協力会社スキル管理表

49 オフショア システムの開発や運用管理を海外の事業所や子会社に委託すること インドや中国、ロシア、カナダなど メリットは？ デメリットは？

50 メリットとデメリット メリット 人件費が安い 大量の開発要員を短期間で確保 国際展開が容易 デメリット
言語、カレンダー、文化などの違いによる壁 地理的に離れている為、詳細管理が厳しい 品質チェックや改善対応に時間がかかる

51 見積もり LOC（Lines of Code） プログラムのステップ数から 類似法 過去の類似システム開発の経験から
FP（ファンクションポイント）法 ファンクション（機能）ごとに処理難易度の重みをつけて開発規模を推定する手法

52 コスト管理 週間報告書 プロジェクトメンバーの工数を原価管理する プロジェクトの採算性を共有する
プロジェクトが完了したら、見積もりと実行コストの対比を行い、見積もり精度を見直す

53 IT技術者に必要なスキル これからのIT技術者に必要なスキルとは？

54 コミュニケーションスキル リーダーシップ ディスカッション（意見交換・会議） ネゴシエーション（根回し）
ドキュメンテーション（情報の蓄積・伝達） プレゼンテーション （序論・本論・結論・時間配分）

55 コミュニケーション能力 【業務担当】 【システム担当】 ・曖昧な部分を 調整能力 含んでいる用件 相手の立場が理解でき、全体把握できる能力
　含んでいる用件 ・時とともに 　変更する要望 　膨らむ要望 業務をまとめる 能力 【システム担当】 調整能力 相手の立場が理解でき、全体把握できる能力 理解力・分析力 文書表現能力 仕様調整 体制整備 進捗管理 業務用語？ システム用語？ 《仕様書・設計書》 限界のある仕様書表記

56 コミュニケーション不足 ユーザーとのコミュニケーション不足により起こりうる問題とは？
協力会社とのコミュニケーション不足により起こりうる問題とは？

57 お客様とのコミュニケーション不足 お客様の意図を理解できていない状態で 設計・開発段階に入る ⇒手戻りになる お客様との意思疎通が悪い
設計・開発段階に入る　⇒手戻りになる お客様との意思疎通が悪い ⇒システム定義が曖昧になり、要件が決まらない ⇒追加・変更要求が発生 ⇒工数超過・納期遅延 交渉技術 ディスカッション ネゴシエーション

58 協力会社とのコミュニケーション不足 設計を理解できないでプログラミングに入る 曖昧な箇所が不明確のまま実装する ⇒品質が悪くなる
⇒修正となり、修正工数が発生する ⇒工数肥大で予算オーバー フェーズ単位での進捗管理ができていない ⇒リリースの遅延 ⇒リリースできない場合に損害賠償になることも

59 キャリアマップ 社内SE PG（開発メンバー） SE（開発メンバー） 管理職 サブリーダー 起業 プリセールスSE PL 導入コンサルタント
PM ITコンサルタント 業務コンサルタント シニアコンサルタント