人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

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

●質問者: moffet1
●カテゴリ:コンピュータ
✍キーワード:システム ファイル ログ 仕様 体験談
○ 状態 :終了
└ 回答数 : 4/4件

▽最新の回答へ

1 ● きゃづみぃ
●18ポイント

http://www.hatena.ne.jp/awindow

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

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


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


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

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


2 ● sparituda
●18ポイント

http://blogs.dion.ne.jp/poor_se/

a poor SE

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


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

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

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

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

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

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

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


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


3 ● 黒猫
●17ポイント

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年目のことでした。なお、私は日立の社員ではありません^^;)

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

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


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


4 ● NYRL
●17ポイント

http://www.hatena.ne.jp/

はてな

URLはダミーです。


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

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


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

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


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


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

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

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ