三連星さんのお小言2

三連星さんのお小言です。

エーロン様
こんばんは　三連星です。

お小言（辛口？）と期待されているようなので行きますよ。
データベース関連（嫌いだあ。）ばかりなので、工夫点そのものにメスをわけに
はいかず、「何を書くか」主体のレスです。

　超初心（診）者さんの論文の設問イですが、これは「報告書」と呼ばれる、失
敗論文の代表パターンの１つです。原田奈美さんのトコ(Tea Party)では、同じ
ことを「作文」と言っています。（私のところでは、「作文」とは、屁理屈でい
いから理屈をこじつけるという意味で使います。）
　「報告書」の特徴は、業務全般にわたって、内容なり工夫点を書こうとしてい
ること。経験論文というのはそうではなくて、業務の中で最も問題となる点をと
りあげ、それをどう解決したかを書くのが基本です。（問題点が複数ある場合、
その１つを取り上げれば良い。）
　で、問題文の前フリにあるとおり、システムテストを完全にやるのは現実には
無理だから、その現状をふまえて、如何に効率よく見落としが少ないテスト方法
をとったか、それを書きます。ですから、たとえば
＞2.3.セキュリテイの確保
は、工夫点には違いないのですが、セキュリテイに関するテストについて記述し
ていないのは論文として片手落ちです。セキュリテイに関するテストの工夫点を
書くか、セキュリィティーについては全く触れないか、どちらかにする必要があ
ります。

で、論旨の例ですが、
問題文に「制約条件を踏まえた上で」とあるのでこれは守らないとなりません。
　制約条件として、「将来目標２００社のオンラインシステムの構築をしたい
が、当面は１３社しか協力できない」を選ぶと、テスト内容のうち困ったちゃん
は、「月末などにアクセスが集中した場合のレスポンスのチェック」というのが
考えられ、テストの工夫点としては、「時刻を決めて１３社が一斉にアクセスし
てテストした。２００社が本当に同時アクセスすることは考えにくいので、１０
社同時が上限と予想された」
（取扱商品次第ではもっと集中するかもしれませんが、それはそれ。）


次に、設問ウですが、書く内容を勘違いしています。
プロジェクトがうまくいったかどうかを中心に書いていますが、そうじゃないの
です。
要は、完全なテストができずに見切り発車したわけだから、
・テスト内容はそれで良かったか。テスト内容に重大な落ち度が無かったか。
・省略可能なテスト項目があったか。
のような、テスト計画についての評価（スケジュール等の評価も含む）を書かな
いとなりません。
ですから、たとえプロジェクトとして失敗（納期の遅れなど）しても、
「テストにより早期段階で致命的バグが見つかった」などの実績があれば、テス
トの方法としては失敗したことにはならないので、堂々と、
「テスト方法が正しかったから手戻りが最小ですんだ」と書いてかまわない筈です。

次、えび天さん。
えび天さんの論文より、Naokiさんのコメントに意義あり、かな？
＞＞プロトタイプは、システムのターンアラウンドタイム
＞＞を計測するためのものである。
＞本当にそれだけでしょうか、ＵＩの確認とかにも使うのではないでしょうか？
＞問題文にもそのような説明がありますね。色々な視点があります。
＞色々な視点があるなかで、今回私はこういう理由でこの視点で対応しました。
＞と主張するのは良いことですが、可能性を考えずにこうだといいきってしまう
＞のは、狭い視野しかもっていないのかな？と思われてしまいます。

元論文ですが、まず
＞＞プロトタイプは、システムのターンアラウンドタイム…を主な目的として
＞＞作成した。
と修正が必要です。
それを前提にしますが、後ろのほうで
＞＞レスポンスタイムが焦点となる。
とあり、開発のボトルネック解消のためにプロトタイプを作ったことになるので
Naokiさんのいうようにオカシイこととは言えないでしょう。


＞あと３．工夫した点では、話が性能向上のほうへ寄っていています。
プロトタイプ作成の目的がレスポンス調査にあるのだから、性能向上のほうへ向
くのは当然では？

むしろ気になる点は、
＞＞ユーザより同時にユーザインターフェースの
＞＞確認も行いたいとの要望があった。
主題が性能改善なのだから、こんなことは書かなければいいのに……
「報告書」を書いているのではないのだってば。


＞＞２−２　効果があった点
＞＞画面平均描画部品点数５００点のデータでテストし、
＞＞目標の５秒以内を実現した。
平均作画部品点数でテストし、その結果目標ギリギリでパスしたなら、
「総画面のうち半数は目標時間内では作画できない」
ということになりません？


それから、本チャンなら減点対象にはならないでしょうが、
＞＞１−１　システム概要
＞＞この為、これを未然に防ぐ為には、

この為……防ぐ為　　と、「為」がダブっています。


最後は、Kennyさん。
＞1-1.システム概要
＞引取業者は、このバーコードを読み込み、Ｋ社に引
＞取情報として送信することになっている。
「○○することになっている」と書かれた場合、
「でも、それはタテマエで現実にはそうなっていない」
と継続することを予想して読みますが、ここでは計画どおりに処理されています。
よって、
「バーコードを読み込み、Ｋ社に引取情報として送信している。」
とする必要あり。

＞1-1.システム概要
＞　Ｒ社では、法施行に伴う設立により、業務フロー等が
＞確立されておらず、さらに情報システムをどう活用して
＞いくのか、といったビジョンも明確化されていない状態
＞で、本システムにおける運用要件も特に定められていな
＞かった。
後続で何も展開されていません。したがって、書く必要ナシ。

Naokiさんは、
＞＞「業務要件が不明確」と書いては、減点されてしまう可能性があります。
＞＞たとえ本当のことでも、書かない方が良い。
とありますが異議アリで、書いてはダメなのはその後の展開が無いからであり、
展開次第では書いても良いという意見です。例えば、
　支店との通信はISDNで当初計画していたが、要件を整理してみるとそれでは
　どう工夫しても要件を満たさず、ADSLに変更した。
なら、別にかまわないでしょう。


設問イは、特に質問ナシ。

＞3-2.性能改善を効果的に行うための方法
＞　性能要件は、適切な業務要件が有って初めて目標値を
＞設定できる。そのため、如何に的確な性能要件を設定で
＞きるかにかかっている。
設問イで、目標値設定に苦労したのならばこう書いてもよいのでしょうが、明ら
かに、目標値が決まっている場合におけるシステム改善のことを書いているの
で、このような書き方は疑問となります。

＞　そして、テストにおいては、性能要件を満たすべく適
＞切なテスト環境・項目の設定を行い、テストを実施
　おおまかにはデータ量に比例する処理時間がかかっており、この対策を重点事
項にあげています。それなら、何故最大データ量（２年分蓄積された時）の処理
時間チェックを行なわないのかが不思議です。既に１ヶ月分のデータがあるわけ
だから、そのデータの年・月を変えながら２４回コピーすれば、仮想の２年分の
データが簡単に作れそうです。
　で、設問イで、そうやったことを書いて、設問ウで、
「稼働してから２年後には、データ量は予想の１．２倍、処理時間は１．４倍で
あった。テスト時の環境を考えれば想定誤差内といえるので、当初のテスト方法
は妥当であった」
のような書き方ができます。
　※これではシステムテスト論文用になってしまうかな？

多忙なドクターのかわりにお小言をくれた三連星さん。どうも有難う。患者の方々もこのお小言を良く聞きいて、たくさん論文書いてください。