2007年09月30日

ソフトウエア開発プロセス 〜ウオーターフォール編〜 つづき3

理由は単純明快で、今までやってきたことを変えるのが怖いからです。特にソフトウエア開発には多大な費用がかかるというのも要因でしょう。

メインフレームの時代から数十年以上、ウオーターフォール型で開発を進めてきて、見積もり手法や、プロジェクト管理方法、生産物(納品物)のあり方、受け入れのあり方など、仕事の枠的なもの全てがウオーターフォール型をベースにして出来上がってしまっています。

実際のところ、開発が進行するにつれリスクが不明瞭に蓄積していくウオーターフォール型開発は、非常にプロジェクト管理(リスクマネジメント)がしづらいものです。

猫つづく
posted by 台北猫々 at 23:02| Comment(0) | TrackBack(0) | コラムみたいな

秋ですね

IMG_0169.JPG
posted by 台北猫々 at 14:20| Comment(0) | TrackBack(0) | 日記

2007年09月29日

ふい〜

今日は会社の飲み会でした。
眠い〜猫
posted by 台北猫々 at 01:17| Comment(0) | TrackBack(0) | 日記

2007年09月27日

気がつけば商店街

気づくと、私は道路の真ん中に立っていました。

道路はどこまでも続いていて、その両側は商店街で、似たような構えのお店がどこまでも並んでいました。道路は舗装されおらず、土の道路で街路樹もなく、ひとっこひとりいない、殺風景といえば殺風景な光景です。

お店は木造2階建てで、1階部分はガラス戸になっていました。昭和30年代を思わせるような佇まいでした。

私は、なんのお店なのかなと思ってガラス戸を覗いてみました。中には自動販売機らしきものが、数台並んでいました。人はいませんでした。

さらによく見てみると、その自動販売機は一昔前にあった「エロ本」の自動販売機でした。

私は、「一体どういうお店?」と思いながら、隣のお店を覗きましたが、ここも同じ自動販売機が並んでいました。

その隣もその隣も同じでした。どこまでいっても、同じでした。

posted by 台北猫々 at 23:23| Comment(0) | TrackBack(0) | 夢日記

2007年09月26日

湯の小屋

旅行先の一枚
湯の小屋の「湯の小屋」

IMG_0168.JPG
posted by 台北猫々 at 21:29| Comment(0) | TrackBack(0) | 日記

2007年09月24日

今日は遅い夏休み

今日から、遅い夏休み(秋休み?)で温泉にいってきます。
posted by 台北猫々 at 10:03| Comment(0) | TrackBack(0) | 日記

2007年09月23日

ことの葉ひらひら その5

「人生はクローズアップで見れば悲劇。ロングショットで見れば喜劇。」

喜劇王


人生劇場。自分の役割は、なんだろうと思うと、舞台の上の梁で、舞台を見ていたいな、などと思ったりします。猫
posted by 台北猫々 at 21:43| Comment(0) | TrackBack(0) | ことの葉

2007年09月22日

今日は早朝掃除、そして洗濯へ

朝7時から、掃除開始。久しぶりに全体を掃除しました。台所、風呂場、トイレ、部屋の奥の方などなど。2時間ぐらいやりましたが、既に一日分のパワーを使ってしまった感じ。

そして、それから洗濯を2回、もう、くたくたです。猫
posted by 台北猫々 at 16:33| Comment(0) | TrackBack(0) | 日記

ソフトウエア開発プロセス 〜ウオーターフォール編〜 つづき2

メインフレームからオープンシステムへ移行し、多様なシステムの乱立と連携、色々なデータベース、また開発環境、言語やアーキテクチャは同じ第三世代であるにも関わらず多種多様です。さらにエンドユーザの要求は日々複雑になっています。

これらの要因の相乗効果により、既にシステムの複雑度は人間の脳の許容量を超えてしまっているのだろうと私は思っています。

つまり、「やってみないとわからない」ことが大変多くなっているのだと思います。

そのため、逐次的で手戻りを許さず、システムの実物ができるまで時間のかかるウォーターフォールは、現状のシステムの複雑度には、全く対応できていないと言えます。

そして、このこと、もしくは近いことを現場で働いている人間を気づいているはずです。

なぜ、改められないのでしょうか?

猫つづく



posted by 台北猫々 at 16:20| Comment(0) | TrackBack(0) | コラムみたいな

2007年09月21日

ことの葉ひらひら その4

「I stand alone.」

喜劇王


孤高という場所から見える風景はどんなだったのでしょうか。
posted by 台北猫々 at 23:52| Comment(0) | TrackBack(0) | ことの葉

2007年09月20日

吸血鬼の女の子と私

父親が「組織から預かってきた」と言って、女の子を家に連れてきました。事情を聞くと、その子は吸血鬼だそうです。

それから、彼女は私の妹として生活を共にしました。初めは慣れませんでしたが、段々と「家族」になっていきました。

しかし、その日は突然訪れました。父親が帰って来ると私に伝えました。「「組織」が吸血鬼の女の子の破棄を決定した」と。「だから、私にあの子を殺せ」と。

「組織」は絶対です。私は迷いましたが、そのころには本当の妹のように思えていた彼女を殺せずはずがありません。私は、彼女を連れて逃げる決心をしました。

しかし、私の翻意に気づいた父親と弟は、私に協力しようとしてくれた姉を殺し、私をも殺そうと迫ってきました。

私は、吸血鬼の女の子を連れて必死に逃げて逃げて逃げて・・・・


posted by 台北猫々 at 22:33| Comment(0) | TrackBack(0) | 夢日記

2007年09月19日

ソフトウエア開発プロセス 〜ウオーターフォール編〜 つづき

多分、ある程度の規模の受託システム開発を経験している方であれば、開発工程後期に基本設計レベルの仕様バグが出てくることが少なくないことを知っているでしょう(そして、こういったものはスケジュールに関わらず、組み込まないと運用に支障が出てしまうことも)。

こういったことは、要件定義不足・基本(外部)設計考慮不足・考慮漏れにより発生するものですが、責任の所在としては、ユーザと上流で動いているSEにあるといえます。

この辺については昨今、ユーザやSEのスキル低下が指摘されていますね。ですが、本質的には個人のスキルに起因するのでは、ないと私は考えています。

猫つづく
posted by 台北猫々 at 22:07| Comment(0) | TrackBack(0) | コラムみたいな

2007年09月18日

ソフトウエア開発プロセス 〜ウオーターフォール編〜

ウォーターフォール

言わずとしれた欠陥プロセスですね。

http://www.atmarkit.co.jp/aig/04biz/waterfall.html
にありますが、「フィードバックループ」が欠落しているものが、普及してしまったというのが実情のようです。「フィードバックループ」があれば、現在の状況は変わっていたのかもしれないですね。

現状のウォーターフォールは、一度開発に失敗したシステムにのみ適用できるものです。

これは、ウォーターフォールは仕様変更(※1)に対する許容能が低いためです(低許容能は、開発が進むにつれて仕様変更にかかるコストが指数関数的に増加することに起因します。)。

別の言い方をすると、ウォーターフォールは仕様変更(※1)がないことを前提としています。

(※1 ここでいう「仕様変更」は、「要件定義・仕様考慮不足 or 漏れ」によるものを指しています。)

猫 長くなるので次回に続く
posted by 台北猫々 at 23:10| Comment(0) | TrackBack(0) | コラムみたいな

2007年09月17日

ことの葉ひらひら その3

「サクラ、サクラ」

水戸陸軍歩兵第二連隊 中川州男

たった6文字に、一体どれだけの想いを込めることが。

posted by 台北猫々 at 22:50| Comment(0) | TrackBack(0) | ことの葉

2007年09月15日

ふい〜

今日は、ちょっと遠出してバーベキューをしに行きます。

むー眠い・・・早起き苦手猫
posted by 台北猫々 at 05:26| Comment(0) | TrackBack(0) | 日記

2007年09月14日

Ruby on RailsをEclipseでいこう その9 〜DBトランザクションを制御するの巻〜

データベースを扱うシステムでは、テーブル間の整合性を保障するために、AテーブルとBテーブルへの更新が両方正常に行えた段階でコミットしたい時があります。

なので、今日はRuby on Railsでのトランザクション制御について。

ActiveRecordには、"transaction"というメソッド(っていうのかな?)が用意されているので、これにトランザクション処理ブロックを渡します。

具体的には、

その7とその8で作成したモデルを例にします。
モデルの呼び出し側(コントローラー)

@bookmark = Bookmark.new(params[:bookmark])
@item = Item.new(params[:item])

Bookmark.transaction(@bookmark, @item) do
#このブロック内部が1つのトランザクションとして扱われます。
#ブロック内部でSQLエラーが発生した場合はRollBackされます。
@bookmark.save
@item.save
end


今回の例では、2つのテーブルは同一DBにあるので、トランザクションはBookmarkでもItemでも、どちらのものを使ってもOK。

補足ですが、データベース自体がトランザクションをサポートしていることが前提の機能です。なので、MySQLのMyISAMのような非トランザクションタイプのデータベースでは、使えません。

分散データベース構成の場合の整合性は・・・まあ、あまり期待しすぎてはいかんですね。

posted by 台北猫々 at 21:53| Comment(0) | TrackBack(0) | 技術メモ(Ruby)

2007年09月13日

真夏の雪夜

気づくと、見知らぬアパートの二階の畳部屋に立っていました。

周りをみると8畳ぐらいの広さで、家具などは一切ありません。「殺風景な部屋だなあ」などと思っていました。

その部屋はとても暑くて、部屋にある大きな窓からは夏の日差しが差し込んでいます。

「外はどうなっているかなあ」と思って、窓に近づいて外を見ると、なぜか外は雪夜で、積もった雪が街灯に照らされています。

私は「ああ、そうか雪があんなに降ったら暑いよなあ」などと思っていました。
posted by 台北猫々 at 21:18| Comment(0) | TrackBack(0) | 夢日記

2007年09月12日

ことの葉ひらひら その2

「誰も僕のことを知らない場所にいったなら、僕は目と耳を塞ぎ、口を噤んだ人間になろうと思うんだ」

”ライ麦畑でつかまえて”より

posted by 台北猫々 at 21:04| Comment(0) | TrackBack(0) | ことの葉

2007年09月11日

今日の技術メモで思ったこと

今日の技術メモでは、Ruby on RailsでPKが複合キーの場合の対処を書きましたが、基本的にはRuby on Rails本体は複合キーはサポート外なので、もし受託開発であれば当対処は適用するのは難しいですよね。

複合キーというのは、業務システムでは珍しいことではないと思うのですが、サポート外というのはどういうことなのでしょう。

例えば、受発注システムでのお約束のDBテーブルとして、「伝票テーブル」と「伝票明細テーブル」というのがあると思います。

この2つのテーブルは親子関係であり、
「伝票テーブル」のPKは「伝票番号」
「伝票明細テーブル」のPKは複合キーで「伝票番号、明細番号」
リレーションキーは「伝票番号」
というのがありがちなものと思います(さらにいうと「伝票番号」は単純な通番ではなく、伝票の種別的な情報を埋め込む場合もあると思います)。

Ruby on Railsの考え方では、多分ですが、業務的に意味ある列(「伝票番号」「明細番号」)をPKにせず、Rails用の「id」列を設けてPKとするDB設計を想定しているのでしょう。

しかし、ある程度の規模になれば、伝票系のテーブルのレコード数は数百万件レベル以上になると思われ、そうなると、1つの列の追加(この場合、「伝票番号」「明細番号」にインデックスをはることになるので、その分も含めて)はストレージの設計にも影響が出ると思われます。

極端に言えば、Ruby on Railsを使うためのディスク容量は、Ruby on Railsを使わない場合と比較して、増量する可能性もあり、当然設備投資費用も増えます。

速度的な問題だけでなく、この辺についてもRuby on Railsは小規模システムの開発向けなのだろうなあと思いました。

まあ、第二印象といったところですが猫


posted by 台北猫々 at 23:33| Comment(0) | TrackBack(1) | 日記

Ruby on RailsをEclipseでいこう その8 〜PKが複合キーだよの巻〜

今日は、PKが複合キーの場合です。

Ruby on Railsは複合キーをサポートしないため、Composite Primary Keys
にあるように以下のコマンドをDOSコマンドプロンプトから実行して、拡張モジュールをインストールします。

>gem install composite_primary_keys

インストールができたら、Railsプロジェクトの
/config/environment.rbの末尾に以下の文を追加します。
require 'composite_primary_keys'

次に以下のDBテーブルを作成しましょう。
CREATE TABLE bookmark (
bookmark_id INTEGER(11) NOT NULL,
branch_no INTEGER(10) UNSIGNED NOT NULL,
url VARCHAR(255) NOT NULL,
PRIMARY KEY(bookmark_id, branch_no)
);

そして、EclipseのRadRailsのジェネレータタブからscaffoldを以下のように実行しましょう。
(ActiveRecord::Base.pluralize_table_names = falseの設定が前提です。)

scaffold Bookmark Bookmark

できあがった/models/bookmark.rbを以下のように改造します。

(変更前)
class Bookmark < ActiveRecord::Base
end

(変更後)
class Bookmark < ActiveRecord::Base
set_primary_keys :bookmark_id, :branch_no

#"branch_no"は"1"固定にしています。とりあえずね。
def before_create
self.id = [ self.bookmark_id_next, 1 ]
end

def bookmark_id_next
return ActiveRecord::Base.connection.select_value('select ifnull(max(bookmark_id),0)+1 from bookmark')
end
end


いつものようにWEBrickで確認しましょう(http://localhost:3000/bookmark)←実際は全部半角小文字

ただし、登録フォームに"branch_no"がありますが、/models/bookmark.rbで"1"固定にしているので、画面からの入力値は無視されます。


posted by 台北猫々 at 19:25| Comment(0) | TrackBack(0) | 技術メモ(Ruby)