IPAが書いたアジャイル開発の研究会報告書 - プログラマの思索
IPAが200頁にものぼるアジャイル開発の研究報告を公開していた。 IPAが公開している研究報告は、RubyやRailsやアジャイル開発などの昨今の話題を日本のIT業界のエスタブリッシュメントがどんな観点で見ているのか、を知る上で非常に参考になる。 運営委員に平鍋さんや羽生田さんがいて議論に加わっているのが興味深い。 気になる文言をメモ。 【元ネタ】 情報処理推進機構：ソフトウェアエンジニアリング 調査報告書[1.68MB] 研究会報告書[924KB] 成果概要資料[702KB] ・共通フレームについても、改めて見直してみたが、ウォーターフォールを標榜していると誤解されても仕方が無いなと感じた。ウォーターフォールを定義できる辞書を整備して、最後に、段階的や進化的プロセスも説明できるよという書き方になっている。要求定義が不十分であることが、リスクとして扱われている。アジャイルプロセスでは、こ
プログラマの思索
astahにタイミング図がサポートされたのでメモ。 【参考】 astah* 9.2リリースノート | astah タイミング図 | astah* 機能ガイド plantumlでタイミング図が描けるらしい: プログラマの思索 astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い: プログラマの思索 astah* Mermaid Pluginが公開された: プログラマの思索 Timing図 わかりやすくUMLタイミング図とは 【PlantUMLの使い方】PlantUMLでタイミングチャートを作成する - システムとモデリング UMLのタイミング図を使う機会は正直ほとんどないし、経験もない。 感覚的には、シーケンス図を横型にしたイメージを持っている。 ただ、ハードウェア設計者ならタイミング図をよく使うと聞いているので、どんな状況でどのように使うのか、調べ
事象にユニークなIDを採番する利点 - プログラマの思索
RedmineやTestLinkなどのツールを駆使してプロジェクト運営すると、チケット、バグ、テストケース、要件などSW開発に関する事象にユニークなIDが振られるのに気付く。 すると、チーム内でこんな会話があって、お互いに事象を認識して共有しやすくなっているだろう。 今日は、チケットxxとyyのいずれを最優先で行うか？ 今、チケットzzの作業状態はどうなっている？ このSVNリビジョンrrの修正理由は、チケットIDがxxにある仕様から来たんだね。 今、あのバグxxのステータスはどうなっている？ テストケースは何番まで実施した？ そのテストケースyyは、要件IDがxxから作りました。 要件IDがxxをテストするテストケースが漏れていますね。 その仕様は、要件ID xxから来ているから、勝手に修正してはいけないね。 過去を思い出そう。 Excelでバグ管理していた時、きちんとしたワークフローを
時代はO-Rマッピングからkey-valueストアへ: プログラマの思索
Apache CouchDBに関するメモ書き。 ＃理解が不完全なので、後で正しく書く。 【元ネタ】 Apache CouchDB: The CouchDB Project Web 時代の非リレーショナルデータベース: 第 1 回 Apache CouchDB の概要とインストール Web 時代の非リレーショナルデータベース: 第 2 回 Apache CouchDB と Ruby on Rails を使って wiki アプリケーションを作成する Web 時代の非リレーショナルデータベース: 第 3 回 Apache CouchDB で MapReduce フレームワークに基づく問いあわせを行う MOONGIFT: ? Web2.0時代のニュータイプDB「CouchDb」:オープンソースを毎日紹介 CouchDBはこのように説明されている。 CouchDB を探る CouchDB はオープン
最近の技術のトレンド～分散バージョン管理と関数型言語 - プログラマの思索
「はじめてのGit」「key-value ストア」が読みたくて、WEB+DB PRESS Vol.50を初めて買った。 すごくイイ！ 【WEB+DB PRESS Vol.50の気になる章】 特集2 ブランチもマージも簡単な分散型バージョン管理システム はじめてのGit 特集3 Webアプリのパフォーマンス向上の一策 ［旬のライブラリ大集合］key-valueストア入門 Java＋RDBの技術だけで、IT業界で一生飯は食っていけると思っていた。 でも、Webの世界では、特にGoogleの技術が世界中を席巻しているといっていい。 自分の技術が時代から少しずつ遅れてきている気がしてきた。 オブジェクト指向はもう古い。 MapReduce、レコメンドエンジン、Cookie Session Storeなどのように、リストやハッシュでデータを保持して比較計算する処理技術の方が重要になりつつある。 これ
SW開発で火を噴くパターン - プログラマの思索
【1】SW開発ではいつも結合テスト以降で火を噴く。 設計、開発、単体テストまで順調であっても、結合テストから受入テストに至るまでに致命的な問題が発覚する。 例えば、下記のような問題がいつでもどこでも噴出するのではないか。 設計書には、複数の画面遷移による業務フローが考慮されていなかった。 業務のインターフェイスがシステムとして整合性が取れていなかった。 シナリオに従ってテストしたら、設計時には気付かなかった業務フローが見つかったり、想定しなかったデータが作られて、その対応が漏れていた。 つまり、設計漏れ。 実際に結合テスト環境で動かそうとすると、そもそも動かない。 実は、DB環境にViewやプロシージャがもれていた。 あるいは、帳票出力やPDF出力、バッチ処理などに必要なサードパーティのライブラリがテスト環境に無かった。 モジュールをビルドして、Webサーバーを再起動する作業が手順化されて
Naoyaさんのトークセッション - プログラマの思索
Naoyaさんがジュンク堂で「私と技術書」を講演された感想をメモ。 ＃印象深い部分だけの感想なので注意。 ジュンク堂書店大阪本店 トークセッション情報 【1】可用性、信頼性などのキャパシティ管理はLinuxカーネルのソースコードから解析する Naoyaさんのキャリアを初めて聞いた。 Perlを中心としたWebプログラミングを中心にやってきて、はてなの最高技術責任者になって、負荷分散の技術に随分悩んだ話が興味深かった。 今までは、サーバーの負荷が高い時、どのような対処をすればよいか、対症療法しかできなかった。 だから、パッチのような対処しかできず、ずっと悩んでいた、と。 「詳解 Linuxカーネル」などを読んで、仮想メモリ、マルチタスク、I/Oディスクなどの仕組みがソースレベルで分かった。 Linuxカーネルの動きをソースコードレベルで追えたからこそ、何故負荷がかかるのか、理由をもって説明で
ブロックはRuby流無名関数 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
プログラマの思索: Subversionコードラインのライフサイクル
Subversionを使ったブランチモデル、バージョン管理戦略がだいぶ分かってきたのでまとめてみる。 ＃走り書きなので後でロジカルにまとめる。 元ネタは下記の記事。 複数のアジャイルチームでのバージョン管理 【1】Subversionブランチが作られるタイミングは、2つある。 一つは、本番リリース直後に作るリリースブランチ。 他方は、突然やってきた大きな機能追加に対応するタスクブランチ。 【1-1】リリースブランチは普通で頻繁に作る。 リリースブランチのライフサイクルは、下記の通り。 これがVer1.0, 2.0とバージョンアップするたびに作られる。 Create：本番リリース直後にtrunkから切られたTagから作る。 ↓ Update：緊急のバグ修正を反映する。当然、trunkにもマージする。 ↓ Delete：次のバージョンが本番リリースされた直後に廃止される。 ここで重要なポイント
MapReduceメモ - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
ITの地殻変動はどこで起きているのか？～SeasarとRuby、そしてPF - プログラマの思索
2008年になってみて、ITの地殻変動がどこに起こっているのか？を考えてみる。 ※以下は殴り書き。後でロジカルにまとめる。 【1】XPからPF(プロジェクトファシリテーション)へ ウォーターフォール型開発はメインフレーム＋Cobolの時代の開発プロセス。今となっては古い。 RUPは、業務向けオブジェクト指向開発を基盤とした開発プロセス。 馬鹿でかい。皆こなしきれない。 ウォータフォール型開発に、各フェーズでインクリメンタル型を取り入れただけ。 XPは、Webシステムを基盤とした開発プロセス。 XPは、ここ10年の経験に裏打ちされた開発プロセスの革命。 ソフトウェア工学にも新しい知見を生み出した。 XPでは、プログラマは、コーディングするパンチャーではなく、システムの品質に対する最終責任者。 ドキュメントよりも動くプログラム重視。 プロトタイプ重視。 ソース共有、コーディング規約、常時ビルド
ソフトウェア開発のチームビルディング - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://forza.cocolog-nifty.com/blog/2008/05/kansaipm9_7471.html