現在SEをしています。

新規のシステムを触ることになる場合、まずは設計書を読むと思いますが、どの設計書から、どんな観点で読むか、よい体験談があればご教授ください(設計書があればの話ですが・・)
【背景】
障害等で対応するとき、作業の中で、必要なものが頭から出てこない事がよくあります。例えば「APLのログの位置がわからない」など基盤面や、「システムでできるファイル名や、具体的な作成場所がわからない」といった業務仕様面。ざっと設計書を読んでいたのに、イざっという時に出てこない・・・これでは迅速な対応ができないので「ここだけは押さえておくべき」というものが知りたいです(対象はあくまで、そのシステムに未経験な人が読むべきものです)。よろしくお願いします。

回答の条件
  • URL必須
  • 1人2回まで
  • 登録:2005/07/26 22:45:46
  • 終了:--

回答(4件)

id:taknt No.1

きゃづみぃ回答回数13539ベストアンサー獲得回数11982005/07/26 23:39:38

ポイント18pt

まず、全体の流れを把握しますね。

システム構成や、どういった目的のものなのかなどを 把握します。


概要を知ってそれから 詳細ですね。


背景のほうを考慮すると どこに何が書かれているのかを 知っておく必要がありそうですね。

検索できる能力を身につけておくということです。

id:sparituda No.2

sparituda回答回数57ベストアンサー獲得回数02005/07/26 23:43:12

ポイント18pt

手前味噌でスミマセン。このブログに、今回の回答が書いてある訳ではないですが、私の経験をもとに整理してみます。なお、私の経験は、販売管理、物量管理など、主に事務処理系のシステムです。


ハード、基本ソフト、ネットワークに関しては、その利用技術によって事情が異なると思いますので、割愛させて頂きます。

1)システム概念図とか全体業務フローとか、その手の、システム全体が一覧できるものを見て、全体像を把握しましょう。他システムとの関連が解る資料があれば、それも見ておきます。

2)各種の一覧表を見ます。ファイルやデータベーステーブルの一覧、機能やプログラムの一覧、システムの利用場所(事務所や倉庫、あるいは組織)などの一覧です。

3)上記の一覧に載っているものについての関連を示す資料を見ます。ファイルとプログラムの関連、機能と組織の関連、などです。

4)システムの各機能については、その機能が動作するタイミングも重要です。利用者が随時起動するのか、1日に1回起動するのか、1ヶ月に1回なのか...。前述に一覧表に乗っていれば良いのですが、処理スケジュールの様なものがあれば、それを見ておきます。

5)そのシステムが既に運用されているものであれば、トラブルの履歴を見ておきます。解決済の初期トラブルについては、気にしなくて良いでしょう。

6)あとは、重要だと思われるものについて、順に掘り下げて行けばいいと思います。


わかりやすい設計書がそろっているといいですね。がんばって下さい。

id:KuroNeko666 No.3

黒猫回答回数144ベストアンサー獲得回数22005/07/27 00:06:54

ポイント17pt

http://www.atmarkit.co.jp/flinux/rensai/theory02/theory02a.html

各ディレクトリの役割を知ろう(ルートディレクトリ編)(1/2)

「新規のシステムを触ることに」を「すでに稼動しているシステムの新担当となって」と読み替えて、話を進めます。

(新規のシステム構築でしたら、ごめんなさい)


設計書のまえに、そのシステムは、どんな目的で作られていますか?

私の場合、目的がわかればシステム要件は限られてきますので、あとは仕様書(設計書)で規模を確認します。

(いまの私のように、部門ネットワーク全ての面倒をみる現場で無い限り…)

これが第1段階だと思います。


余裕があれば、過去の障害履歴をみてみます。

経験上、HDD障害とか電源障害とかが多いです。

また、障害時の対応マニュアルが存在するはずです。

なければ作ります。

専門の部署があるのにこれが無い場合は職務怠慢だと思います。


基本は、障害が発生したらマニュアルどおりに進めることです。


マニュアルが無い場合もあるので、ここを押さえておけば障害対応は早いだろうという部分を。

・障害などは、(UNIXの場合)メッセージログで確認します。

Linuxなら /var/log/messages ファイルです。

(moffet1さんが例で挙げられているような項目は大体確認できますし)

すいませんが、windowsでのシステムは経験がないので…


・また、エラーログの読み方が重要かと。

具体的な体験ですが…

日立のシステムはエラーログ解説書だけで何十冊とあります。

しかし、OS面やPPなどで一意のIDがある上に、日本語マニュアルということもあり、かなりやりやすかったです。

IDの上○桁で、主な機能がわかり、残りの桁で、詳細なエラーIDがでてきたので。

障害対応は、不謹慎ですが逆に楽だったりしました。

(SEとして配属1年目のことでした。なお、私は日立の社員ではありません^^;)

それだけでもいいのですが、私の場合は普段から、どのファイルがどんな役割をしているのか、いちいち開いて実際に見ています。

障害時の迅速な対応は、設計段階から考慮されていないと本当に厄介です。


蛇足ですが、システムの目的や担当などをおおまかに書かれると、反応も出やすいと思います。

id:NYRL No.4

NYRL回答回数14ベストアンサー獲得回数02005/07/27 12:51:16

ポイント17pt

URLはダミーです。


新規のシステムを触ると書いていますが背景を見ると既存の稼動しているシステムに対して

いきなりメンテナンスして欲しいと言われた時に必要な資料という感じかなと思って書きます。


実際の経験から言うとソースのみを見て資料はあまりみません、理由としては普通は資料が逐一メンテナンスされていることは期待できない(私の当たりが悪いから?)からです。

なので資料は読むとしても「概要設計書」で業務のおおまかな流れとフォルダ構成、プログラム構成あたりをみます。


詳細の設計書まであるものもあったんですが実際のプログラムと違っていて当てにならないことが多いので概要とソースのコメント、あとはソースをGrepかけてなんとかしています。


必要な資料は最新の使用まで反映された概要設計書と引きやすい索引が一番欲しいですね

詳細な設計書は大抵の場合膨大な量になるのでその中から必要なところを探すよりはソースをGrepかけたほうが早いことが多かったので・・・

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません