論述の参考

概要

参考になりそうな書き方を書き留めておく
ファイルを分けられそうなら分ける

H25午後1問1

(X) ソフトウェアを開発して実現する作業
①安否確認の自動化
　大規模地震等の災害時には、安否確認担当者も業務を遂行できる保証がない。また、安否確認担当者による手作業での安否確認では、確認の完了までに時間がかかる上に、確認漏れの恐れもある。そこで私は、安否確認をシステムで自動化することにした。具体的には、社員の緊急連絡先をあらかじめシステムに登録しておき、災害発生時に緊急連絡先がメールアドレスか電話番号かを自動判別し、メールの送信または電話の発呼を行うようにした。メールには応答用WebページのURLを埋め込み、このURLにアクセスすることによって社員が自動認証されて安否情報を登録し、電話では質問に対して数字キーで応答し、その結果が登録されるようにした。

ポイント

自動化の理由として下記3点を網羅
- 担当者の業務執行不能をカバー
- 確認時間の短縮
- ミス（確認漏れ）の排除
  - 防止でない

ユーザー要求絞り込みが必要そうなケースでの定番の論述

前提

要求絞り込み必要が必要な制約例（問題による）
- スケジュール遵守
- 予算遵守
- 人員（コスト）遵守

(X) ユーザー要求の絞り込み
　ABCシステム開発は、協力会社との連携の都合上、スケジュール遵守が求められていた。そこで私は、スケジュール内に開発を完了するために、ユーザー要求に優先順位をつけて絞り込むことにした。優先順位は、業務価値と実装の難易度から4段階で評価した。具体的には、業務価値が高く実装の難易度が低いユーザー要求は「1：今期必ず実装する」、業務価値が低く実装の難易度が低いユーザー要求は「2：できれば今期実装する」、業務価値が高いが実装の難易度も高いユーザー要求は「3：次期の実装を検討する」、業務価値が低く実装の難易度が高いユーザー要求は「4：実装しない」とした。ただし優先度が2および3のユーザー要求については、多機能との関連や緊急性を考慮して優先度を調整する。

良い設計についての論述

午後IIで、変更に強い設計、拡張を見越した設計みたいな観点の論述が求められることがある。その場合はキーワードを適切に用いればそれらしくなる。例えば

抽象化
実装を隠す
インターフェースを分離する
上位モジュールが下位モジュールに依存しない

（X）抽象化の見直しと徹底
　当ソフトウェアは、オブジェクト指向言語で開発されてはいるものの、オブジェクト指向の原則を踏まえているとは言い難かった。また、クラスの追加修正がその場しのぎで行われてきたことも、クラス構造を混乱させていた。結果として、当社のソフトウェアは修正の影響を限定できず、保守コストが高くなる傾向があった。私はこの状況を断ち切るために、既存機能を流用する場合であっても、プログラムを設計し直すことにした。具体的にはSOLIDの原則に従、抽象から具象へのクラス構造を再設計し、クライアントプログラムは抽象度の高いクラスを利用するよう徹底した。またデータベースを利用するプログラムについては、クライアントプログラムごとにインタフェースを分離し、特定のインタフェースに依存しないようにした。

この例だと、もう少し具体的な実装内容まで踏み込んでいると尚良い

ユースケース駆動開発を設計上の留意点や工夫点のネタにするケース

ユースケース駆動開発のメリットとして下記があり、論述のネタとして持っておきたい。

無駄なクラス・冗長なコードが出現しにくい
使用する図式表現が少なく、開発難易度を抑えられる
顧客の理解を得やすい
開発状況を把握しやすい

（X）ユースケース駆動開発の導入
　過去の開発事例では、システムの動的な分析が不足し、無駄なクラスやメソッドを実装するなどの不手際に繋がった。これを避けるため、今回のプロジェクトでは、ユースケースを重要視したユースケース駆動開発を導入することになった。
　ユースケース駆動開発では、ユースケースをいかにもれなく正確に記述するかが成功のポイントになる。そこで私は、ユースケースごとにロバストネス分析を必ず実施し、ユースケースを具体化しながら検証・洗練するよう工夫した。また、メインフローだけではなく、代替フローや例外フローも忘れず洗い出し、それらを同じシーケンス図にまとめるよう留意した。

代替フロー・例外フローを想定するのはICONIXの提唱者曰く「晴れの日と雨の日の両方のシナリオを用意する」という重要な概念・

Hikaru's notes