2005年05月31日

[ テクニカルエンジニア(データベース)/H17 ]

H17午後II 問1設問2(2),(3)

H17午後II 問1
機械式駐車場設備メンテナンス業務

設問2(2)
要件を整理し,出動目的と属性値の決定に関するデシジョンテーブルを完成させる。
出動目的は,表4 出動目的一覧の出動目的からそのまま引用する。

埋めやすいものから手を付ける。
f) 緊急呼出し年月日にXがあるのはこれだけなので,出動目的は「緊急呼出し」
g) よく分からず,とりあえず保留
h) 修理指示メーカ番号のXと完全に一致するので,出動目的は「メーカ指示修理」
i) 提案番号のXと完全に一致するので,出動目的は「提案修理」
j) 前回出動番号のXと完全に一致するので,出動目的は「継続出動」
残るは「定期点検」のみ。よって,g)は「定期点検」

解答例:設問2(2)
 f)緊急呼出し
 g)定期点検
 h)メーカ指示修理
 i)提案修理
 j)継続出動

設問2(3)
要件実現の検討(未対応指摘,対応方策記述)

要件1:出動目的別の出動回数の把握
 出動→出動内訳←出動目的
 特に問題なく,対応可能。
 (目的別の出動回数合計は,本当の出動回数の合計と一致しない点には注意が必要・・・問題には関係ないが)

要件2:出動目的別部位装置別修理実績の把握
確認すべき項目は
① 出動目的→出動内訳←出動→・?・→駐車場設備修理
② 「修理」と「出動」の業務的な関係

表3「メンテナンス作業における出動指示書と報告書提出の関係」と業務の説明より確認する。
・定期点検:定期点検の結果によって,必要な修理を実施する。
・自発的部品交換:修理報告書はないが交換部品を登録する。
・メーカ指示修理
・緊急呼出し:不具合箇所の特定と修理
・継続出動:定期点検結果による修理及び緊急呼出しによる修理の2日目の作業
・提案修理

疑問1:「修理」=「修理報告書」なのか,自発的部品交換を含むのか
疑問2:継続出動時のエンティティ「出動内訳」の扱い
     例)定期点検の場合
      1日目) 定期点検 1レコード
      2日目) 継続出動 1レコード
       なのか
      1日目) 定期点検 1レコード
      2日目) 定期点検,継続出動 2レコード
       なのか。。。
       デジョンテーブルに出動目的が「継続出動」のみのものがあるため,前者と思われる。
   
出動内訳←出動→・?・→駐車場設備修理
出動に対して,駐車場設備修理は一意に特定できる。
しかし,出動の出動内訳が複数ある場合は,どの出動内訳による修理なのか特定できない。
そもそも「どの出動内訳による修理」なのか特定する必要があるのか?
⇒表6のデジョンテーブルを見ると,修理作業がある出動目的の組合せが混在している。
 と,いうか全ての出動目的で修理作業が発生し得る。
 どの出動内訳なのか特定する必要があると思われる。

 さて,対応する方策だが,「属性の変更,追加だけで対応」という条件が付いているので,その範囲内で考える。
 一番手っ取り早いのは,エンティティ@駐車場設備修理に属性@出動目的番号を追加することではないだろうか。(安易過ぎるか?)

解答例①:要件2
対応できない理由
 出動目的が複数ある時に修理作業が発生した場合,どの出動目的による修理作業か特定できないため。(46文字)
対応するための方策
 部位装置別に出動目的が管理できるよう,エンティティ“駐車場設備修理”に属性“出動目的番号”を追加する。(50文字@禁則処理)
 

要件3:1日で完了しなかった修理作業の把握
疑問2:継続出動時のエンティティ「出動内訳」の扱い
が,また。。。
2日目の出動内訳は,「継続出動」だけと想定する。

疑問3:「修理作業」って何?定義は?
メーカ指示修理+提案修理? それとも 修理報告書を提出する作業? それとも 駐車場設備修理を行ったすべての作業?
疑問4:「提案修理」の2日目以降の「出動目的」は何?と,いういか2日目以降はデータ登録しているの?2日以上の場合,修理作業結果はどう登録するのさ? ・・・ 分からん事が多すぎる。

 1日で完了しなかった修理作業=継続出動で修理を行った作業であるが,提案修理の2日目以降の作業は「継続出動」と呼ばない。(「前回出動番号」も持っていない。)
 もうひとつ別の側面から考える。継続作業時に別の出動目的と重なり,別の出動目的で修理を行うとどうだろうか?ここが疑問2のミソなんだよなぁ。。。「継続作業時には継続作業のみを実施する。」とは書いていないし,『緊急呼出し→継続出動@修理+ついでに自発的部品交換@修理』なんてな(どのみち修理には変わりないか。。。)

 1日で完了しなかった(提案修理が何日かかろうが知らないということであれば)修理作業は,継続出動をカウントすれば把握できる?とも思ったが,提案修理は2日目以降の作業を「継続作業」と呼ばない。つまり,2日目は「継続作業」ではないので,これはNG。
 では,駐車場設備修理がない提案修理は1日目で完了しなかった作業か?
 疑問4が立ちはだかる。2日以上かかっても,最初の出動に修理結果を登録すると。。。NG。

解答例②:要件3
対応できない理由
 提案修理による作業は継続出動として管理されないため,何日で修理が完了したか把握できない。(44文字)
対応するための方策
 作業日数を把握するため,エンティティ“出動”に属性“作業完了年月日”を追加する。(40文字)


要件4:修理が発生しなかった緊急呼出し回数の把握
{出動内訳(緊急呼出し)→出動}
 -{出動内訳(緊急呼出し)→出動→・?・→駐車場設備修理}
 -{前回出動番号の出動目的が緊急呼出しの出動内訳(継続出動)→出動→・?・→駐車場設備修理}
差集合演算で求められる。(と,思う)

Posted by g@kko at 2005/05/31 09:54 | 個別記事表示 | コメントを見る (2) |
この記事をLicWikiに埋め込む:
コメント
2 :前スレ973:05/05/31 21:56:26 [RES]

> (目的別の出動回数合計は,本当の出動回数の合計と一致しない点には注意が必要・・・問題には関係ないが)
まさにそれを理由に1を選択してしまった。
解決策は、「主たる出動目的」を付加する・・・ OTL


3 :g@kko:05/06/02 21:25:55 [RES]

>>2 :前スレ973
 この設問の要件って曖昧さ全開なんすよね。
 どう数えたいのか。。。

 曖昧さのない要求定義を頼む!
 と,叫びたいw