1 se 1 1 se
Download
1 / 83

? 1 ? SE ????? 1-1 ???????? SE - PowerPoint PPT Presentation


  • 90 Views
  • Uploaded on

第 1 章 SE の仕事とは 1-1  システム設計と SE. 株式会社ディー・アート 上野淳三・広田直俊・白井伸児 [ 著 ] 「システム設計の考え方」 H102124  宮澤新一. システム開発における SE の役割. システム設計。 システム要件を定義し、それを実現するシステムの機能および構造を具体化する。 システム設計者としての SE の役割は、システム要求の把握からシステムの設計内容をプログラマへ伝達するまでである。. ユーザのシステム要求を把握する. システム要求を把握する作業を一般に「要求分析」、「要求定義」あるいは「要件定義」と呼ぶ。

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '? 1 ? SE ????? 1-1 ???????? SE' - minna


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
1 se 1 1 se l.jpg

1章 SEの仕事とは1-1 システム設計とSE

株式会社ディー・アート

上野淳三・広田直俊・白井伸児[著]

「システム設計の考え方」

H102124 宮澤新一


Slide2 l.jpg
システム開発におけるSEの役割

  • システム設計。

  • システム要件を定義し、それを実現するシステムの機能および構造を具体化する。

  • システム設計者としてのSEの役割は、システム要求の把握からシステムの設計内容をプログラマへ伝達するまでである。


Slide3 l.jpg
ユーザのシステム要求を把握する

  • システム要求を把握する作業を一般に「要求分析」、「要求定義」あるいは「要件定義」と呼ぶ。

  • 要求分析の内容や進め方はユーザの開発システムに関する検討状況や、推進体制によって大きく変わる。


Slide4 l.jpg
ユーザの検討状況との関係

図1-1 ソフトウェアのライフサイクル


Slide5 l.jpg
ユーザの検討状況との関係

  • ソフトウェアのライフサイクルは企画から始まるが、通常、SEは開発段階からプロジェクトに参画する。

  • 開発段階の要求分析工程はライフサイクルの出発点でなく、さらに上流にある。


Slide6 l.jpg
ユーザの検討状況との関係

  • 要求分析は企画と開発の両方の段階で行われる。

  • どの段階からSEがプロジェクトに参画するかにより要求分析の作業内容は異なる。


Slide7 l.jpg
ユーザの検討状況との関係

  • 社内SEの場合

    • 企画段階から入るケースが多い。

    • ユーザが白紙に近い状態からシステムの企画に着手することになる。

    • システム開発の目的や対象業務を定めるところから要求分析が始まる。


Slide8 l.jpg
ユーザの検討状況との関係

  • ユーザがシステム仕様を固めている場合

    • ユーザから要求仕様書の説明を受けるところからSEの作業が始まる。

    • ソフトハウスなどの社外のSEはどちらかと言えば、このケースにあたる。


Slide9 l.jpg
ユーザの推進体制との関係

  • ユーザ側の推進体制が異なれば、要求分析の進め方も変わる。

    図1-2 ユーザからシステム要求を聞きだす


Slide10 l.jpg
ユーザの推進体制との関係

  • 最も単純なケース

    図1-2(1)ユーザの代表者からシステム要求を聞き出す


Slide11 l.jpg
ユーザの推進体制との関係

  • 最も単純なケース

    • 小規模な部門システムを開発するケース。

    • ユーザがあらかじめ要求仕様を固めているケース。

    • ユーザの代表者とSEが1対1で対話するため、システムイメージを頭合わせしやすい。

    • 比較的外乱が少ないが、代表者の背後にいる本当のユーザの意識をつかめないこともある。


Slide12 l.jpg
ユーザの推進体制との関係

  • 一般的なケース

    図1-2(2) 複数のユーザからシステム要求を聞き出す


Slide13 l.jpg
ユーザの推進体制との関係

  • 一般的なケース

    • 複数のユーザグループの代表者からシステム要求を聞き出す。

    • 相反する要求や矛盾する要求もある。

    • 相反・矛盾する要求を整理してグループ間の調整を行い、要求を集約する必要が出てくる。

    • コントロールできない不確定要素が現れてくることもある。


Slide14 l.jpg
ユーザの推進体制との関係

  • 複数のSEが分担するケース

    図1-2(3) 複数のSEがシステム要求を聞き出す


Slide15 l.jpg
ユーザの推進体制との関係

  • 複数のSEが分担するケース

    • システム規模が少し大きくなり、ユーザの代表者が多くなるため、複数のSEが分担して要求分析を行う。

    • SE側で、それぞれが聞き出したシステム要求をSE同士で整理・調整・集約する必要が出てくる。

    • コントロールできない不確定要素が一段と大きくなり、作業プロセスも複雑になる。

    • 統制のとれた活動を展開する必要が出てくる。


Slide16 l.jpg
ユーザの推進体制との関係

  • 新しい情報システムに求める役割が次第に経営や事業活動に密着したものになるにつれて、ユーザ主導でシステムを企画する傾向が強くなっている。

  • システム設計を担当するSEは、ユーザ主導の企画プロセスがどのように進められるかを理解しておく必要がある。


Slide17 l.jpg
システムを設計する

  • SEがシステム設計で心得ておくべきことは、ユーザの要求をそのまま鵜呑みにしてシステム設計を行なってはいけないということ。

  • 業務システムとしてやるべきこと、やってはいけないことをユーザに直言できないようでは、専門家の資格はない。


Slide18 l.jpg
システムを設計する

  • ユーザもSEに対して専門家としての見識を期待しているため、その期待に応えて積極的に提案することが望まれる。

  • ユーザの要求が、必ずしもユーザが求める真の要求でないことも知っておいた方がよい。


Slide19 l.jpg
システムを設計する

  • ユーザは業務に慣れてしまっているため問題自体が見えなくなっていることがある。

  • システム設計者において、ユーザの要求をしっかり見きわめ、取捨選択する必要がある。


Slide20 l.jpg
システムを設計する

  • 必要と判断した要求を実現可能な形に構成し、システムを設計する。

  • 設計した内容はユーザに説明して、ユーザの理解と承認を得る必要がある。


Slide21 l.jpg
システムを設計する

  • 新しいシステムを構築するということは、ある意味で新しい業務モデルを設計する必要があるということである。

  • 現在の業務モデルから直接新しい業務モデルを検討するのではなく、現行のモデルから物理的な要素を排除した論理モデルを作成して検討するようなことを行なう。


Slide22 l.jpg
システムを設計する

  • 図1-3 論理モデルを使ったシステム設計プロセス


Slide23 l.jpg
システムを設計する

  • 論理モデルを採用するのは、現実にある別の問題に気がとられて目的とする新しい業務モデルの検討が進まないといった理由があげられるためである。


Slide24 l.jpg
システムを設計する

  • システム設計で用いる開発技法として、プロセス中心アプローチ(POA:Process Oriented Approach)やデータ中心アプローチ(DOA:Data Oriented Approach)などがある。

  • POAが、処理手順やデータの流れに注目して現状を分析する手法であるのに対して、DOA では、データとその流れの分析に重点を置き、システム設計を進める。


Slide25 l.jpg
プログラマへ設計内容を正確に伝達する

  • システム設計書は、プログラム開発を行なうための仕様書としての役割がある。

  • システム開発プロジェクトの関係者がシステムの完成イメージや実現方法・製作プロセスなどの情報を共有する目的も合わせ持つ。


Slide26 l.jpg
プログラマへ設計内容を正確に伝達する

  • システム設計書には、仕様書としての精緻な面と、関係者に対する新システムのガイドブックとしてのわかりやすさの両面が求められる。


Slide27 l.jpg

1-2 情報化の動向8~17ページ

H102002

安島澄人


Slide28 l.jpg
新情報革命

  • 経営学者として著名なドラッカーは、現在の情報化、つまり、コンピュータの発明以来の情報化を「第4の情報革命」と称している。

  • またドラッカーは、今後、情報技術(IT)の分野における重心は技術(T=Technology)から情報(I=Information)に移行していくと展望している。


Slide29 l.jpg
情報技術のパラダイムシフト

  • 思考の枠組みや考え方(旧体制)が壊れたり、根本的な変化が生じたりすることを「パラダイムシフト」と呼ぶ。

  • 情報技術分野では、これまで、メインフレームを代表とするシステム中心のパラダイムから、80年代にPC中心のパラダイムへ、さらに90年代にはネットワーク中心のパラダイムへと2回のパラダイムシフトが起きている。


Slide30 l.jpg
1-3 情報システムとは

  • SEが取り組む情報システムはどういうものか。

  • 情報システムの処理形態が発展してきた経緯

  • 企業における業務面から見た情報システム

  • 企業における役割から見た情報システム

      を紹介する。


Slide31 l.jpg
情報システムの処理形態

バッチ処理 (データの一括処理)

           ↓

オンライン

リアルタイム処理 (データの即時処理)

           ↓

データベース処理 (データの共有化と一元管理)


Slide32 l.jpg
バッチ処理

  • コンピュータの処理方法

    I:入力(Input)

    P:処理(Process)

    O:出力(Output)


Slide33 l.jpg
コンピュータの利用形態の変化

  • コンピュータ利用開始から

    30年くらい前の利用形態

    (1)技術計算などのコンピュータの計算能力

    (2)給与計算などのデータ処理

    (1)、(2)に重点を置いた使い方が中心だった。


Slide34 l.jpg
コンピュータの利用形態の変化(2)

今日、技術計算は

(1)CAD(Computer Aided Design:

        コンピューター設計)

(2)CAE(Computer Aided Engineering:

       モデルの特性解析シュミレーション)

(1)、(2)やスーパーコンピュータを使った天気予報のシュミレーション計算などの分野に発展している。


Slide35 l.jpg
バッチ処理方式

  • 給与計算のデータ処理が今日のデータ処理に発展した。

  • 給与計算のようなある期間に収集したデータをまとめて一括処理する方式を「バッチ処理方式」と呼ぶ。


Slide36 l.jpg
オンラインリアルタイム処理

  • その後、コンピュータの利用技術が進み、オンラインリアルタイム処理への移行が始まる。

  • コンピュータに端末から直接データを入力し、処理結果が直ちに必要な場所に出力される処理方式である。

  • コンピュータの対象領域の拡大。


Slide37 l.jpg
システム設計の対象範囲

入出力設計や処理ロジックを中心としたバッチ処理システムの設計内容

              ↓

オンラインリアルタイムシステムのシステム設計では業務設計が主要なものとして加わる。

バッチ処理システムに比べて、SEが行うシステム設計の業務内容は質的に変わった。


Slide38 l.jpg
データベース処理

  • 業務システムで蓄積したデータや組織が保有する情報を有効利用するために、それらを整理してコンピュータ上に保存し、必要に応じて取り出す仕組みを「データベース」と呼ぶ。

  • データベースを構築し、活用するソフトウェアを「データベース管理システム DBMS(Data-Base Management System)

  • データベースを運用するシステムを「データベースシステム」と呼ぶ。


Slide39 l.jpg
企業における業務機能面から見た情報システム

  • 基幹業務を対象とした基幹系システムに始まり、そのデータを活用する情報系システムへと発展してきた。

  • 基幹系システム 販売管理、生産管理、在庫管理、財務会計、人事給与等

  • 情報系システム 顧客情報管理、商品情報管理、業績情報管理

  • OAシステム ワープロ、表計算、プレゼンテーションソフトなど

  • グループウェア 電子メール、電子掲示板、文書共有など


Slide40 l.jpg
企業経営における役割から見た情報システム

  • 経営者が求めているのは、企業の将来にかかわる情報である。

  • 企業の情報システムは、データを処理して業務を効率化することから始まり、経営に役立つ情報システムの構築を目指してきた。


Edps electronic data processing system l.jpg
EDPS (Electronic Data Processing System : データ処理システム)

  • コンピュータの初期に始まった情報ビジネスの概念。

  • 経理計算、給与計算などの従来から手作業で行っていたデータ処理を機械化し、処理の効率性向上を狙いとしている。


Mis management information system l.jpg
MIS(Management Information System : 経営情報システム)

  • 1960年代後半に始まった概念。

  • 経営に必要な情報をあらゆる階層で活用することを目指した。

  • 業務の効率化だけでなく、経営面でコンピュータを活用する狙いがあったが、当時の技術レベルでは実現できなかった。


Dss decision support system l.jpg
DSS(Decision Support System : 意思決定支援システム)

  • 80年代に始まった概念。

  • MISが狙いとした、組織の目的に貢献する情報を作り出すという一面を焦点に絞ったシステムである。

  • 経営レベルでの意思決定支援を目的としている。


Sis strategic information system l.jpg
SIS (Strategic Information System : 戦略的情報システム)

  • 90年代にできた概念。

  • 情報技術を活用して既存の企業活動を抜本的に再構築することを目指している。

  • 業務の効率化よりも、売り上げ増や競争優位の確立を目的としている。


Ec electronic commerce l.jpg
EC (Electronic Commerce :電子商取引)

  • 90年代にインターネットの普及とともに急速に広がったシステム

  • 情報技術を活用して、新しい市場機会を生み出すことを目指している。


1 se 1 4 se l.jpg

1章 SEの仕事とは1-4 システム開発プロジェクトにおけるSEの役割

株式会社ディー・アート

上野淳三・広田直俊・白井伸児[著]

「システム設計の考え方」

H102124 宮澤新一


Slide47 l.jpg
情報サービス産業における職能別就業者数

  • 情報サービス産業における職種別就業者数のうち、職種別で一番多いのは「システムエンジニア(SE)」である。

  • 「プログラマ」、「管理・営業」と続き、この人員構成から、SEが情報サービス産業の中核であることがわかる。


Slide48 l.jpg
情報サービス産業における職能別就業者数

図1-8 情報サービス産業における職種別就業者数の 割合


Slide49 l.jpg
SEの役割の拡大と専門分化

  • 情報処理技術者の分類はソフトウェア開発における役割をもとに行なうのが一般的。

  • ユーザの要求分析、システム設計などのシステム開発の上流工程を担当する技術者を「SE」と呼ぶ。


Slide50 l.jpg
SEの役割の拡大と専門分化

  • SEの事業範囲は、以下のものである。

    • 利用者の要求分析

    • システム設計

    • プログラム開発の指導

    • 総合テスト

    • 本番移行時のユーザ支援

    • システム構築の保守

  • ライフサイクル全体にSEが主導的な役割を担う。


Slide51 l.jpg
SEの役割の拡大と専門分化

  • 情報システムがSISやECといった形で企業経営に密接なものになってきている。

  • システムの開発では、どういう形(How)で実現するかは二の次になり、どんなシステム(What)を構築するかが重要になる。


Slide52 l.jpg
SEの役割の拡大と専門分化

  • 開発の最上流工程、あるいは、開発に入る前のシステム企画段階を担当するソリューションの専門家のニーズが大きくなっている。

  • 技術面ではオープンシステム化が進展し、システムを構成するハードウェア、ソフトウェア、ネットワーク、データベース等が急速に多様化・高度化している。


Slide53 l.jpg
SEの役割の拡大と専門分化

  • 大規模なプロジェクトになると、技術者を連携させ、プロジェクト全体をマネジメントする専門家であるプロジェクトマネージャが必要になる。


Slide54 l.jpg
SEの役割の拡大と専門分化

  • 現状では、SEの守備範囲が広がりすぎてSEの定義があいまいになっていると言える。

  • これまで一括にしていたSEの概念でこうした新しい役割をカバーするのは無理があるため、技術者を専門分化する方向が打ち出されている。


Slide55 l.jpg
SEの役割の拡大と専門分化

  • システム化計画の立案などソリューションを担当するITコーディネータやシステムアナリスト、業種・業務に詳しいアプリケーションエンジニア、技術面に特化したテクニカルエンジニアなどが新しい技術者の分類になります。


Slide56 l.jpg
システム構築におけるSEの役割

  • 開発プロジェクトにおける基本的なSEの役割

    1.ユーザの業務要件の分析

    2.システム設計、システム方式設計、システム移行・運用設計

    3.プログラム開発の推進

    4.総合テストの実施

    5.利用部門に対する本番移行の支援


Slide57 l.jpg
システム構築におけるSEの役割

図1-9 開発プロジェクトにおけるSEの役割


Slide58 l.jpg
システム構築におけるSEの役割

  • 建築などの成熟した分野では、設計と施工が明確に分離しています。

  • システムの開発においては、プログラム開発工程への指示を設計書で行なえるかというと、そうはいかない。

  • 現状では、SEがプログラム開発、テスト、本番移行までを一貫して担当し、状況を見ながら細かく指示するのが一般的である。


Slide59 l.jpg
ケースバイケースで変わるSEの役割

  • 専任のプロジェクトマネージャが付くような大規模プロジェクトであれば、SEは担当部分のシステム設計やプログラムソフト開発にある程度専念することができる。

  • プロジェクトマネージャが付かない小規模なプロジェクトになると、リーダ格のSEがプレーイングマネージャを兼ねることができる。


Slide60 l.jpg
ケースバイケースで変わるSEの役割

  • ソフトハウスが開発業務を担当している場合、SE課長がプロジェクトマネージャになると顧客に報告しているケースでも、それは名目上のことで、担当SEが実質的なプロジェクト管理を行うケースが多いようである。


Slide61 l.jpg
SEが行うプロジェクト管理

  • リーダー格のSEになると、プロジェクト全体のプロジェクト管理を行うことが多くなる。

  • 初級SEも、一般に、自分の担当するサブシステムの開発責任を負うことになる。

  • 開発責任を負うということは、担当部分の納期・品質・コストについて責任を持つことを意味する。


Slide62 l.jpg
SEが行うプロジェクト管理

  • システム開発はチームで行う。

  • SEは複数のプログラマで構成された小さなチームを率いることになる。

  • プログラム開発をプログラマ任せにせず、プログラマとよくコミュニケーションをとり、進捗状況を把握して管理する必要がある。


Slide63 l.jpg
SEが行うプロジェクト管理

  • プログラマがプログラム開発に特化するのに対して、SEは他のプロジェクト関係者(ユーザ、プロジェクトマネージャ等)との連携をとりつつ、システム開発に関しては何でもやるつもりでいないと開発責任を全うすることはできない。


Slide64 l.jpg

‐5 SEに求められる    知識と能力

H102042 小林 弘晃


Slide65 l.jpg
SEの専門性(1)

  • プログラマの能力差は把握しやすい

  • SEの専門性や能力差は把握しにくい

    • 取り組んでいるシステムの内容、ユーザのレベルに応じて仕事の難易度が異なる

    • 開発した結果がSEの能力差なのか開発チーム全体の差なのか判断が付きにくい


Slide66 l.jpg
SEの専門性(2)

  • 優秀なSEと、そうでないSEの差は明確

    • システム開発に要した工数

    • テスト期間に発見されたバグの件数


Slide67 l.jpg
優秀なSEと優秀ではないSEの違い

  • 優秀ではないSE

    • 忙しそうに駆け回っている

              ↓

      目先のことしか考えず、トラブルに追われてる

  • 優秀なSE

    • 自席でゆったりしている

              ↓

      先のことを考え、トラブルになる前に先手を打つ


Slide68 l.jpg
SEに要請される知識と能力(1)

  • SEには幅広い知識と能力が求められる


Slide69 l.jpg
SEに要請される知識と能力(2)

  • 若手SEの様子

    • 業務分析や要件定義に単独で放り込まれることはない

    • 担当する部分が次第に増え、開発工程の上流工程へと拡大していく

    • 実践を積みながら業務の幅を広げ、知識とスキルを向上させていく


Slide70 l.jpg
仕事の進め方の基本(1)

  • システム開発業務はプロジェクト対応

    • 基本的に同じ仕事はない

    • 業務環境やプロジェクトメンバーが変わる


Slide71 l.jpg
仕事の進め方の基本(2)

  • 仕事の進め方の基本

    • PDCAサイクルで計画を立てて取り組む

    • 5W1Hで検討項目を洗い出す

    • ホウレンソウを忘れない

    • タスクの優先順位をつける


Slide72 l.jpg
PDCAサイクル(1)

  • P: Plan

    • 目標を設定し具体的な計画に落とし込む

  • D: Do

    • 計画に基づき実行

  • C: Check

    • 実行過程で達成状況を測定・評価

  • A: Action

    • 測定結果を受け、必要に応じて軌道修正



Slide74 l.jpg
PDCAサイクル(3)

  • 基本的に開発業務の中で何かまとまった仕事に着手するときに利用する

  • 手戻り少なく、効率よく仕事を進められる

  • 最初の計画段階が重要

  • 1つのサイクルが終了したら、再設計のプロセスから次のサイクルを回す


Slide75 l.jpg
5W1H

  • 仕事の内容を手早く理解するのに有効

    • Why(なぜ)

    • Who(だれが)

    • What(何を)

    • When(いつ)

    • Where(どこで)

    • How(どのように)


Slide76 l.jpg
5W2H

  • SEの業務では、数量を確認することが多い

    5W1Hにもうひとつ「H」を加える

  • 新たに加えられた「H」とは

    • How much・How many(いくら)


Slide77 l.jpg
ホウレンソウ

  • 報告(ホウ)

    • 結論を先に、簡潔明瞭に事実と意見の区別をつけて報告する

  • 連絡(レン)

    • 上司と関係者に迅速かつ明瞭に伝達する

  • 相談(ソウ)

    • こじれる前に上司や同僚に相談する


Slide78 l.jpg
タスクの優先順位

  • 開発業務が佳境に入ると、SEは複数のタスクを平行して進めることが多くなる

     重要度、難易度、納期などを考慮して、タスクに優先順位をつける


Slide79 l.jpg
ITスキル標準とは(1)

  • 各種IT関連サービスの提供に必要とされる能力を明確化・体系化した指標である

  • ITスキル標準の構成

    • ITサービスを11職種 / 38の専門分野として区分

    • 実務経験・実績をもとに「達成度指標」を設定

    • 必要なスキルを教育・訓練に活用する観点からスキル項目に要素分解

    • スキル項目ごとに「スキル成熟度」と「知識項目」を展開




Slide82 l.jpg
ITスキル標準とは(4)

  • ITスキル標準の活用例

    • 人材育成・調達を行う際の目安となる

    • 自らのスキル開発をどのように行うべきかを判断する指標となる


1 6 se l.jpg

1-6 SEの学習方法

Uploadなし


ad