配置図から非機能用件を類推する - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
プログラマの思索: 日本のパッケージベンダーが駄目な理由
ひがさんのBlogを読んで、日本のパッケージベンダーが駄目な理由が垣間見えた気がした。 スルガ銀行のIBM提訴にみるパッケージビジネスの難しさ SIerが自動車産業をまねしようとするのはいい加減やめなさい 日本のパッケージベンダーが駄目な理由は2つある。 一つは、パッケージそのものが変化に対応しきれないこと。 もう一つは、分業化しすぎて技術力そのものが劣化していること。 金融系の勘定系システムは、大手SIベンダーのメインフレーム上のパッケージ製品が多い。 だが、それは余りにも大きすぎて、誰も仕様も技術も全部は分からない。 パラメータTblに顧客ごとの値を設定してカスタマイズすれば、すぐにできると宣伝するが、実際は、顧客の要求に合わせていくうちに、元々のパッケージと似て似つかぬシステムになる。 品質も保守性もボロボロになるのがいつものパターン。 ソフトウェアプロダクトラインの発想が
【感想】第24回Ruby/Rails勉強会@関西 - プログラマの思索
第24回Ruby/Rails勉強会@関西へ行ってきた感想を書く。 【1】REST思想が解決しようとするもの moriqさんの講演。 REST思想をアーキテクチャの観点から非常に丁寧に深く解説してくれて、かなり概念が整理された。 Webシステムの特徴のひとつは、デプロイが独立していること。 つまり、クライアントのVerUpは、サーバーは無関係であること。 Railsの弱点は、デプロイにあると思う。 おそらく、JRubyがそれを解決してくれるはず。 REST思想のモチベーションは、セッションを汚さないこと。 できるだけ、画面の状態は、URLが指し示すリソースで持つ。 GET、POSTだけでなく、HTTPメソッドにあるPUT、DELETEを使って、セッションで保持しなくてもいいようにする。 少なくとも、注文ボタンの2度押し問題は、POSTメソッドでなく、PUTメソッドを使えば解決できる。 PUT
システム開発から属人性を排除しようとして失敗する - プログラマの思索
ひがさんの記事「「誰が書いても同じコード」は大事なことなのか」を読んで思ったことを書いてみる。 大手SIerは独自の重量級の開発プロセスを持つ。 それは多分、メインフレーム＋Cobol時代の開発プロセスを最近のオープン系に焼き直したものに過ぎない。 その現場のプロジェクトは大規模で人数も多いから、少数精鋭チームで自由に動くわけにはいかない。 その開発プロセスの意図は、誰が作業しても同じような品質を保つ所に重点を置く。 つまり、属人性を排除しようとする。 だから、できない人もルーチンのような作業までレベルアップするが、できる人は、無駄なドキュメント作成やマネジメント、そして古臭くなったコーディング規約などの運用ルールに縛られている。 彼らのプロジェクトはタンカーのように、一度動き出したら進路を変えるのは凄く難しい。 現在の特にWebシステム開発では、頻繁なリリースによるバージョンアップが多い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
