TAKAが試したこと考えたこと

ソース管理してる？ ワンステップでビルドできる？ デイリービルドしている？ バグデータベースがある？ 新しいコードを書く前にバグを直している？ アップデートされたスケジュールがある？ 仕様書はある？ プログラムは静かな環境で作業している？ 手に入る最高のツールを使っている？ テスタはいる？ 採用面接のときにコードを書かせている？ ユーザビリティテストはしてる？ Joel on Software 作者: Joel Spolsky, 青木靖 出版社/メーカー: オーム社 発売日: 2005/12 メディア: 単行本 購入: 8人 クリック: 44回 Amazon.co.jpで詳細を見る の3章に記述してあるチーム判定基準です。 CMMIを調べていた身からするとこれはよいですね。 手軽で本質を表している感じ。 品質に関するアイディアを組み込めばこっちの方がよさそうだと個人的には思います。

[続きを読む →]

昨日偶然にも大間のマグロを食べる機会があった。 ブランド品にこだわるつもりはないがやはり別物。 びっくりした

[続きを読む →]

後輩と話していて、この雑誌がいいですと薦められて読んだのが Web Designing 2006/2 http://book.mycom.co.jp/wd/currentissue/index.html Web2.0に関する特集がありました。その中でも JotSpot*1 ベースはWikiでありながら、いろいろなアプリケーション・フォームを提供しているのがこのサイト。 URIの同一性を保ちながらプロジェクト管理、CRMなどいろいろなアプリケーションとして動作している思想がWeb2.0のイメージがはっきりしました。 ある意味言葉遊び的な部分もありますが新しい概念を生み出そうとしているのではないかと感じています。 *1：http://www.jot.com/

[続きを読む →]

すべてのシステム開発プロジェクトを同じ視点・同じ戦略で語るのには無理があると思う。 分類した上で各分類に対して適切な方法を議論できるのではと思っています。 もしかしたら分類できないのかもしれませんが。 ＃各プロジェクトによってだったら悲しい。 顧客の範囲 変な言葉を作りましたが、これは顧客側のステークホルダーが何種類いるのかという意味です。1種類であれば（1種類はまれで、現場とスポンサーといった2種類いるのが普通ですが）、個別最適をすればよいので機能要求で対立することは少ない。 そのため、フィードバックを重視した開発戦略をとるのが一番よいと思われます。 機能単位ごとに顧客にフィードバックもらっても大きな混乱がおこらないので顧客にとって価値のある順につくればよいのかと。 複数のステークホルダーがいる場合は、多くの場合「要求の対立」が起こるのでその調整を最初にやっておかないといけません。もし、この手順を踏まないでフィードバックを重視するとフィードバック毎に大きな変更が起こりアーキテクチャそのものも変わらず得ない場合がありプロジェクトが混乱する可能性があります。 規模 ある程度以上の規模があるとプロジェクトの参加メンバーが増えます。 もちろん、「困難は分割して解決せよ」という考え方を用いて組織を分割することで対応しますがそれでも階層が深くなると分割すればよいということでもなくなっていきます。 その規模の大きさはプロジェクトを実施する組織によって異なると考えられます。 プロジェクト組織の配置 プロジェクトを実施する組織の場所をどう確保するのかというのが一つの問題になります。プロジェクト全員を同じ場所に集めることができるか否かというのがプロジェクトの方法が変わることになります。 コストの問題で「オフショア」*1といういこともあるわけです。 その場合の開発の進め方がかわるでしょう。 リスク プロジェクトが持っているリスクによっても大きく変わると考えられます。 上記の問題も分類していくと最後はリスクに行き着くわけですが。 *1：いいか悪いかは別の問題

[続きを読む →]

昨日、会社の帰りにEvoを確認しようとして 初めてのアジャイル開発 ?スクラム、XP、UP、Evoで学ぶ反復型開発の進め方? 作者: クレーグ・ラーマン, ウルシステムズ株式会社, 児高慎治郎, 松田直樹, 越智典子 出版社/メーカー: 日経BP社 発売日: 2004/09/09 メディア: 単行本 購入: 2人 クリック: 11回 Amazon.co.jpで詳細を見る を買いにいったところいろいろ眼について買ってしまいました。 Joel on Software 話題になっている本なのでとりあえず購入。 Joel on Software 作者: Joel Spolsky, 青木靖 出版社/メーカー: オーム社 発売日: 2005/12 メディア: 単行本 購入: 8人 クリック: 44回 Amazon.co.jpで詳細を見る 開発の現場 毎号買っているのでとりあえず。 開発の現場 Vol.003 効率UP&スキルUP エンジニアのための実践ソフトウェア技術誌 作者: SE編集部 出版社/メーカー: 翔泳社 発売日: 2006/01/14 [...]

[続きを読む →]

id:m_pixyさんのところで話題になっていたのでまとめておこうと思いました。 ウォータフォールはソフトウェアライフサイクルモデルの一つです。 他のライフサイクルモデルとして何があるかというと、反復やスパイラル、プロトタイプなどなどがあります。（詳細はSWEBOK9.2.1、IEEE12207.0など） これらの違いを考えてみるとウォータフォールの意図がわかる気がします。

[続きを読む →]

機能要求 機能要求は、意見はいろいろありますが私は「ユースケース」が良いと思っています。但し、機能仕様レベルを記述するには向いていないのでまずは目的レベルユースケース*1を記述するとよいと思っています。ユースケース記述をテンプレート化したフォーマットで記述します。 イベントフロー イベントフローは、以下のテンプレートで記述します。 アクター（実際のアクター名）はシステムに対して～する システムはアクター（実際のアクター名）に対して～する という組で記述します。システム内部で何が起こっているかはここでは問題にしません。 一般に「アクターがシステムに対して～する」というのは、入力を表しており、「システムはアクターに対して～する」というのは出力を表しています。 このような入出力イベントをフローとして記述するのがイベントフローです。 イベントフローと機能仕様 上記に記述したイベントフローの2つのテンプレートは組で機能を表しています。 そのため、この組を一つの機能仕様として捉えます。 入力→内部動作→出力といった形で記述します。 イベントフローにおいては、内部の動作を注目しませんでしたが機能仕様は内部の動作を意識します。要求において整理された業務ルールをこの内部動作にマッピングする形でトレーサビリティを保っておくとよいでしょう。 機能仕様における内部動作 内部動作は自然言語と図解によって記述されます。この動作は大きく分けて 入力のバリデーション 入力形式→内部構造の変換（形式的） 内部構造（形式的）から内部格納形式への変換およびシステム状態の変化（業務ロジック） 内部格納形式の永続化 出力する情報の検索 出力情報の構築 出力先の確定 に分かれます。 内部構造（形式的）とは、入力形式が特別な形式（ミドルウェアなどに依存）している場合に内部のオブジェクトなどにマッピングする作業です。 例えば、Webアプリケーションであれば入力情報はすべて文字列になっているので数値データは数値に変換するといったことです。 また、StrutsではActionFormという形式なため論理構造に変換するとわかりやすくなります。最近のDIコンテナを利用すればこの入力形式をPOJOに自動変換してくれるのでその必要はないかもしれません。 出力情報の構築とは、ViewHelperなどの出力情報を組み立てることを表しています。 非機能要件の記述 詳細はこれから勉強しますが、EvoのPlanguageに着目しています。 その意味で今日にでもこの本を買いたいと思っています。 初めてのアジャイル開発 ?スクラム、XP、UP、Evoで学ぶ反復型開発の進め方? 作者: クレーグ・ラーマン, ウルシステムズ株式会社, 児高慎治郎, 松田直樹, 越智典子 出版社/メーカー: 日経BP社 発売日: 2004/09/09 メディア: 単行本 購入: 2人 クリック: 11回 Amazon.co.jpで詳細を見る *1：ユーザの要求を満たす単位。通常、画面遷移を伴いいくつかのワークフローやチェックポイントがあったりします。アクターは何種類か登場することになるかもしれません。例えば、旅費清算をするというユースケースであれば、出張者が申請をして、承認者が承認して、清算担当者が手続きを取り、清算承認者が承認するといったことになります。

[続きを読む →]

今日、連絡があって12月に予約していたW-ZERO3が手に入りました。 京ぽんからの機種交換で意外に愛着がありましたがせっかくの新製品なので 試してみようと機種交換しました。 いろいろと試してみようと思います。

[続きを読む →]

このように抽出した情報を整理し、要求仕様としてまとめます。 要求仕様の網羅度チェック 要求仕様の網羅度をチェックするために重要なのが入力と出力の整合性チェックです。 ギャップがあった場合には 入力情報を加工すれば出力情報になる 入力情報が漏れている 出力情報が誤っている といったパターンが考えられます。 このうち1番目は加工するためのルールを業務ロジック*1として名前をつけておきます。 最後のパターンがこのチェックの主たる目的なので、入力すべき状況を洗い出し要求として追加します。 *1：情報系のルールとして決めておきます

[続きを読む →]

システムで何よりも難しいのが人間から情報を引き出すこと。 網羅性を持って、構造的に整理された情報を引き出すことはまずありません。 業務を実践している人にとって情報は取捨選択されていることが多く、当たり前の情報は表に出てきません。 その意味でいろいろな想起法を利用して、情報を引き出すことになります。 関連を利用して引き出すのが王道なので、業務フローやゴールモデルなどを用いた方法や芋づる的に引き出させるマインドマップなどを利用できます。

[続きを読む →]