Software Design

論理削除と物理削除

よもやま — Sat, 30 Aug 2008 12:05:00 GMT

システム設計段階にてデータ削除を物理削除もしくは論理削除のいずれかを
選択する事になります。
論理削除を主とした場合、いずれかのタイミングで物理削除をしなければいけなくなります。

この論理削除データをどう取り扱うかに焦点をおいてみましょう。
・論理削除されたデータをユーザーに参照させ、確認同意した上で物理削除する
・論理削除されたデータをユーザーに確認させずに削除した上で新規データを登録する
・論理削除した段階でデータをユーザーにメール送信し、復活の機会を作る（期間限定）
等の対策を取る事になります。

ユーザー側ではどうでしょうか？
・削除はユーザー自身の行為
・本当は削除しちゃいけなかったデータ
この本意はシステム側からは判断つきません。
システム開発側は、時折くる「復活の呪文電話（？）」を割り切って「削除はユーザー自身の行為」とします。

論理削除されたデータはいつまで残しておくべきか、いつ物理削除するか・・
・未来永劫データベースに保存
・１年に１回等タイミングを見計らって論理削除
・論理削除された日時からＮヶ月経過したレコードを削除
このあたりは、システムの特性に左右されます。

システム特性といっても業種・業務のサポート支援ですから
何かあったときに追跡調査できなきゃいけなかったりと様々です。

一方の論理

よもやま — Fri, 22 Aug 2008 22:53:00 GMT

システム要件定義から構想・設計に至るまで
様々な人、様々な立場な人と接する機会がありますが
「自分ならこう考える」事を思わず口にしがちです。

が、ここで思いとどまってほしいのです。

思いとどまってほしい点としては
「相手に一日の長があるということ」他です。

というのは今現状抱えている問題や改善点というのは
相手の喉まで出かかっていたりするものなのです。
といはいえ、こちらは、相手の事をほとんど知りません。

ですから、「私は～～考えたりしますがいかがでしょう？」と違う着眼点で
話しかけてみるのです。

と「どばっ」と出てくる事もあるし、あ～それ昔話題に出たねぇとなるかもしれません。

なにせシステムを作る鍵は、こちらが持っているのではなく相手にあると言っても過言ではないと思います。

あとは、システム設計にあたり現状の情報をどれだけ集め、分析できるかですが・・
分析に関しては、相手の力も借りましょう。

・現状こうなってる。
・抱えてる問題は、ＸＸＸＸ。
・こうしたい。
この３点に絞り込んでシステム要件を洗い出すのも手だと思います。

テストケース

よもやま — Fri, 15 Aug 2008 18:32:00 GMT

なんだか不思議な感覚に悩まされています。
システム開発を行っていますが、その際に作成する試験仕様書の取り扱いについてです。

一方の論理にも一理あるのですが、これって・・どうなのよといったものです。

さて、一方の論理とは・・
システム開発を先行着手してきた先輩曰く
１．試験仕様書作成に時間をかけたくない。
２．試験仕様書のテストケースは、発注元が汎用的にとりまとめられた項目から機能に会わせ選択。
という路線なのです。
したがって・・
仕様書に記載される条件分岐によって左右される結果想定なんか項目として登場しません。
しかも、試験にかける工数見積もりは、汎用的にとりまとめられた項目から導きだされる工数ですから
実際にしなければならない試験内容とはかけ離れています。

結果、プログラマに作ってもらった機能をテストするにも、漏れてるわけで・・
結局、条件分岐を考慮したテストケースを作成し、再度テストする事になるのです。

で、先輩曰く
「仕様書を見落としなく実装できているなら、こんなことにならないのでは？」ということに。

ん～、仕様書を見落としなく実装できているかどうか判定する為に試験を行うのに
その試験内容が穴だらけなのは気のせいですか・・

さらに先輩が、外注のプログラマさんに・・
「品質高いプログラム作成に心がえてくださいよぉ、このままだとクレームきちゃうから」

いやいや、なんか違うから
てか、質の高いプログラムを要求するなら、渡すテスト仕様書もそれなりにしようよ・・

外注さんに仕様書と試験仕様書から導き出される見積もりを取り
発注した時点で、この結末は目に見えていたのか・・
契約範囲外として外注さんからクレームがきたのは言うまでもありません。
それなら、中途半端な試験仕様書を渡すべきじゃなく、試験仕様書の作成も含めて見積もり作成してもらったほうがよかったとか・

外注さんに仕事を発注する際には、される側の思考ルーチン（？）も考慮にいれておきましょう・・

Document Review(DR) - Part 0-「ＤＲって何？」

よもやま — Mon, 08 Oct 2007 00:46:00 GMT

まず、ドキュメントレビューとは何ものでしょうか
このあたりから始めたいと思います。

お客様から要望／要求（プラス希望納期等）が提示され、
ソフトウェアを作成するにあたって作成する各種設計書
作成した設計書類の内容で要望／要求事項が満たせているか等を確認する為に
ドキュメントレビューが行われます。

ただ場合によっては、書類をメールで送付しておいて
内容を確認してもらいつつ、開発に着手していく事もあると思います。

ここでは、仮のお客をＹＯＭＯ、製作会社をＺＺＺＺとしましょう。
まず、ＹＯＭＯ会社は、ＹＡＭＡ会社に「要望／要求提示／見積照会」を~~ＹＡＭＡ~~ＺＺＺＺに行います。
次に、ＺＺＺＺ会社は、要望／要求提示の内容から、不明点の質問、瑕疵範囲の確定等を
ＹＯＭＯ会社と行います。

後、ＺＺＺＺ会社が製作できる判断が行われた後、見積書がＹＯＭＯ会社に提出されます。

そして、ＺＺＺＺ会社が各種設計文書を作成し、ＹＯＭＯ会社にてドキュメントレビュー開催。

ドキュメントレビューでは、どのような事がやりとりがなされるのでしょうか。
様々なケースがあり一概に申し上げる事はできませんが、
制作者側主導にて、内容確認が進行するものとしましょう。
要望／要求実現に対する意見交換や、ＺＺＺＺ会社が作成した文書記述訂正を行っていきます。
要望／要求実現に対する意見交換を行う事で
お客の奥底に潜んでいる「本当は、こんなこともやらせたい」が出てきたりします。
納期、技術的問題、製作するソフトウェアに占める重要度から
持ち帰り後日検討する事項も出てきます。

まとめますと・・

≪製作側にとってドキュメントレビューとは≫

お客様の奥底に潜んでいる要求／要望の発掘
お客様の視点・思想とのギャップを減らす。
瑕疵範囲の明確化
提案の場（たとえば、ファイルの格納場所であったり管理方法であったり等）

≪お客にとってドキュメントレビューとは≫

製作側の意図把握（どんな風に実現するのだろうといったところ）
製作に対する取り組む姿勢（どんな人がどこを作るのだろうといったところ）
要望／要望の実現性確認や整合性確認

各種書類の作成関してチェックポイント資料がありましたので紹介しておきます。
ドキュメントレビューに役立つチェックポイント（＠ＩＴ）

また、ソフトウェア工学関連で書籍も発売されているようですので、
本屋で見つけたら、チラ見してみてはいかがでしょうか。
#立ち読みは、営業妨害とならない程度に・・

#う～む、前提条件他書いていたら長くなってしまった。orz
#私の経験則で記述しておりますので、間違った表記等ありましたらコメント投稿お願いします。
～～
#HTMLタグ LIは各項目ごとに閉じるんじゃなかったかなぁ、Live Writerで生成するHTML見ると最後の項目にしか無いんだよねぇ。W3Cで調べてこようっと。
＜ＯＬ＞
＜ＬＩ＞テスト＜／ＬＩ＞
＜／ＯＬ＞
#2007/10/8 修正