第1回 要求仕様に関係する落とし穴
整理術的改善ポイント では、ここから改善のポイントを1つずつ解説していきます。 （1）要求仕様書とリリース製品が正しく保管されていること （2） 要求仕様書とリリース製品が関連付けされていること まず、製品開発時に参照すべき唯一の要求仕様書が、正しく管理されていることが大前提として挙げられます。正しくとは、管理されている要求仕様書が間違いなく参照すべき唯一の要求仕様書であることを識別できること、開発メンバーの全員が同一の要求仕様書を参照していること、勝手な改ざんができないことを意味します。この大前提が成り立っていれば、少なくとも、開発メンバー全員が、同じ要求仕様書を基に同じものを開発しようと試みているといえるわけです。 次に、この要求仕様書を基に出来上がったリリース製品について、いつでも誰でも、要求仕様書とリリース製品を一対一で特定できることが重要です。このためには、何らかの手段で対応を識
その“ソリューション”は本物か？
問題を抱えている社内の顧客（業務部門）に対し、具体的な解決策＝ソリューションを提示するのが「情報エキスパート」だ。本連載では、情報エキスパートが持つべき視点や考え方について解説する。 企業経営と情報技術を結び付け、企業に経営的効果をもたらす役員をCIOと呼びますが、役員以外でその役割を果たす人物には呼び名がありません。ここではそれを「情報エキスパート」と呼ぶことにしたいと思います。 CIOは企業内の役割（役職）ですが、情報エキスパートは問題を抱えている社内外の顧客にソリューション（問題の解決）を提供する人材です。本連載では、情報エキスパートが持つべき視点や考え方を何回かに分けてお話ししていきます。特にユーザー企業のIT部門で、IT化の計画立案策定・実行に携わる情報マネージャおよびミドル層で次のような疑問を感じている方にぜひ読んでいただきたいと思います。 自分が社内に提供しているサービスは、
The Rational Edge 要求仕様の決定に時間を割かない結末
The Rational Edge 要求仕様の決定に時間を割かない結末は？ Jim Heumann Rational Software Corporation 2002/1/22 次のような話を聞いたことはあるだろうか？ 「要求仕様をまとめる時間がない。すぐにコーディングに取り掛からないと納期には絶対に間に合わない」 このような話（よく聞く話だが）は、個人もしくはチームの考え方や成熟度を測るための重要な手掛かりになる。要求仕様をまとめる時間がないという言葉が出てくるのは実際にはどういうときであり、どのような意味があるのだろうか？ 本稿で詳しく見ていこう。 「要求仕様」という単語には多くの定義があり、メソッド、プロセス、方法論、そして専門家ごとにそれぞれ固有の解釈があるようだ。しかし、要求仕様はそのプロジェクトが何を構築し、提供するのかを明確に記述すべきである、との点ではだれも異論はないはず
アジャイルソフトウェア開発（あじゃいるそふとうぇあかいはつ）
ソフトウェア要求仕様の変更などの変化に対して機敏な対応ができ、顧客に価値あるソフトウェアを迅速に提供することを目的とするソフトウェア開発方法論の総称。特に「アジャイルソフトウェア開発宣言」に合意しているもの、「アジャイルアライアンス」に参加しているものを指す。アジャイル（agile）とは「俊敏な」「機敏な」という意味で、軽量型（ライトウェイト）開発ともいう。 ウォーターフォールやRUPなどの“重厚な（ヘビーウェイト）開発プロセス”が事前に仕様を定義して、それに基づいてアーキテクチャ中心に計画的な設計を行い（この間、仕様書や設計書など中間成果物を作成する）、その設計に沿ってプログラミングを行っていくというプロセスであるのに対して、アジャイルソフトウェア開発は仕様や設計の（場合によっては大幅な）変更が当然あるものという前提で、最初から厳密な仕様を抽出しようとせず、大まかな仕様だけで細かいイテレ
【XP】こんなXPerはいやだ - 翔ソフトウェア (Sho's) Wiki
翔ソフトウェア (Sho's) Wiki フロントページ 「こんな XPer (エクストリーム・プログラマ) はいやだ」と思うものを自由にあげていくテスト。 # 誰でも自由に追加・編集して構いません。 手がスナック菓子の油でいつもテカテカしていて，キーボードにカラムーチョなどの粉が付く。 足が異様にくさい。そばでは呼吸が困難。 ペアプロ中、いつもぶつぶつ独り言を言っている。 ペアプロ中、ずっと赤ちゃん言葉でパートナーをする。 あれあれ、おかちいでちゅねー。 そこ、ちがいまちゅよー。 頑固一徹。人の意見に耳を貸さない。メタファでいうと「ナベツネ」。 仕事中、ずっとヘッドホンで八代亜紀を聴いている。 ずっと在宅勤務。 週に40時間、夜のバイトをしている。 で、香水はシャネルだ。(それはそれでいいかも…^^;) 毎日スタンドアップ ミーティング中に貧血を起こして倒れる。 プロジェクト
パターン･ムーブメントからアジャイル・ムーブメントへ：An Agile Way：オルタナティブ・ブログ
ソフトウェアパターンとXPをはじめとするアジャイルムーブメントは共通点が多い。より正確には、ソーシャルな形（人脈）で歴史的連続性を持っているために、思想的に共通するのは当然だといえる。 パターンが建築家Christopher Alexander（以下C.A.）の思想を、Kent Beckがソフトウェアの世界に持ち込んだ、ということは有名である。1987年、最初にソフトウェアにパターンを持ち込んだのは Kent Beck と Ward Cunningham によるGUI設計に関するものだ。KentとWardはパターンコミュニティHillside Groupを発足させる。そこでパターンを収集する活動がPLoPと呼ばれるもので、現在も続いている。 このコミュニティでJim Coplien（通称Cope）が重要な働きをしている（彼は2001年沖縄のMensorePLoPにも来日している）。Cope
Linux Links Directory - LinuxLinks
Last Updated on October 24, 2021 The Linux Links Directory has been retired. Instead check out our great content. The largest compilation of the best free and open source software in the universe. Each article is supplied with a legendary ratings chart helping you to make informed decisions. Hundreds of in-depth reviews offering our unbiased and expert opinion on software. We offer helpful and imp
＠IT：ソフトウェア開発をちゃんと考える（1）
本連載は、メタボリックスの山田正樹氏が、仕事の合間に読む数冊の書籍に刺激を受けて思考した過程やその結果を記述したものである。参考にするのは必ずしもソフトウェア工学に関わる書籍ではないかもしれないが、いずれその思考の軌跡はソフトウェア工学的な輪郭を帯びることになる。（＠IT編集部） 生産性向上のメカニズム ソフトウェア開発における「生産性」とは何か。厳密に定義するのは難しい。生産性とは基本的には「あるアウトプットを得るのにどれだけのコストをかけたか」という尺度だ。さすがに「アウトプット」をソース・コード行数で測っても無駄だという認識は広まってきたと思うが、じゃあ代わりに何を使えばいいのかはいまだにはっきりしない。ユースケースやストーリーで測る考え方もある。そんなものは存在しないという意見すらある。 そういう場合には視点を1レベル上げて考えてみよう。つまり、ソフトウェア開発だけ考えているから分
Linux 上で Windows 用インストーラを作成する
Linux 上で Windows 用インストーラを作成する NSIS の 2.01 が9月24日にリリースされていた。 目玉はNSISコンパイラ(makensis)が、POSIX プラットフォームで動くようになったこと。 Linux 上で Windows 用インストーラが作成できるようになる。 インストールしたいプログラム/データが(Javaプログラムだったり、クロスコンパイルできるものだったり、コンパイル不要のスクリプトだったりで)用意できるならば、Linux 上でインストーラまで通して作れるのでこれは有り難い。 インストール tar jxvf nsis201.tar.bz2 cd NSIS/Source make USE_PRECOMPILED_EXEHEADS=1 cd .. fromdos install.sh su ./install.sh /usr/local/NSIS-2.0
Visual Basic 6.0ユーザーはVisual Basic 2005に移行せよ
Visual Basicによるアプリケーション開発の現場では、いまだに旧バージョンを利用しているところも多いと聞く。なぜ、最新バージョンへの移行が行われていないのだろうか。その理由を考えてみる。 社内システムなどビジネスアプリケーションの開発シーンでは、Visual Basic（VB）が利用されている。VBの現行バージョンはVisual Basic .NET 2003だが、開発現場ではいまだに旧バージョンのVB 6を使用しているところが多い。なぜ2003に移行していないのだろうか。 VB .NETに移行しなかった理由 なかなかVB .NETに移行できないのには、どうも訳があったようだ。VB 6ユーザーのVB .NET 2003に対する不満点の中に、構造化言語であった従来のVBから、完全なオブジェクト指向言語であるVB .NETに変わってしまったからだ、という意見がある。確かにこの変化は大き
ObjectClub - アジャイル勘違い集
やる気さえあればできるというのは、ある意味では正しいのですが、盲目にそう信じてしまうと痛い目を見ることになるでしょう。 アジャイルな手法は、変化に対応したり、コミュニケーションをとったり、改善を模索したりという行動を要求します。 そうした行動が苦手な人や嫌いな人は、アジャイル手法が苦痛になってしまうかもしれません。 さらにそういう人はアジャイル手法に対して意識的・無意識的に抵抗して、チーム全体の足を引っ張ることさえあります。 アジャイルに向いた人もいれば、重厚な方法論に向いた人もいます。向き不向きを考えてメンバーを集めるか、 メンバーが固定しているプロジェクトではそのメンバーに向いたやり方を考えたりしましょう。それがプロジェクト成功の早道です。
使いにくい業務システムが生まれる理由
「これからは，現場のユーザーのことを考えた使い勝手の高いシステムを作れないITベンダーさんには，発注しません」。ソニー生命保険は最近，取引先のITベンダーに対してこんな方針を打ち出した。 目的は，営業支援システムなど基幹業務システムの刷新を本格化するに当たって，使い勝手の高いシステムを設計開発できる体制を整えるためである。そのため今年1月までに，業務システムの使い勝手（ユーザビリティ）とは何かを定義したうえで，ユーザー・インタフェースの設計プロセスや画面一つひとつのデザイン方法などに関する社内標準を策定。それらに準拠することを，取引先のITベンダーにも求め始めたというわけだ。 ユーザー・インタフェース設計の責任者となった長尾和洋 営業企画本部営業情報支援部web支援課主事は，元営業担当者としての経験を踏まえてこう語る。「システムのちょっとした使い勝手の悪さも，それを日々使う現場のユーザーに
ソフトウェア開発における人月について - besus’s diary
アークランプの鈴木雄介さんが、最近のソフトウェア業界における人月の意味合いについてエントリを書いていた。以下の話は、オープンソースソフトウェア開発(オープンソースの導入、カスタマイズ、オープンソースそのものの開発)における話が、大部分を占めており、従来から存在するプロプライエタリソフトウェア開発には余り当て嵌らないと考えており、そのあたりは注意が必要と考えている。 http://www.arclamp.jp/blog/archives/000633.html プログラムのビジネス上の単位である人月は、開発者・発注者のいずれからみても、正しく基準となり得ていないという問題を孕んでいることは、よく知られた事実である。しかし、現在のところ、他に最適なモノサシがないため、やむを得ず、これを使っているのが現状ではないだろうか。鈴木さんは、その人月が、ある開発手法においては、有効になってくるのではない
オープンソースUMLエディタは、有力なプロプライエタリ版に劣る - SourceForge.JP Magazine
オープンソースプロジェクトへの参加者が最初にする作業は、普通、ソースをダウンロードして、研究することである。これはときにうんざりするような作業で、プロジェクトの規模が大きくなるほどその傾向も強まる。 リーダーがプロジェクト全体のグラフィカル表現でも用意してくれていれば、現参加者は開発中のソフトウェアの全体像を見失わずにすむし、将来の参加者はソフトウェアの部分間の相互関係を視覚的に把握できる。現にほとんどの市販ソフトウェアでは、開発者どうしがそのようなグラフィカル表現を――それも、UML（Unified Modeling Language）という標準的な方法で――共有できるようになっている。これに対し、オープンソースプロジェクトの最大リポジトリを標榜するSourceForge.netで探しても、ソフトウェアをUMLで記述しているオープンソースプロジェクトは数えるほどしかない。この理由の一部は
やってはいけない、設計と実装の並行作業
“常識的な判断”って何？ 前編（「コレだけ準備すれば分散開発に失敗しない」）では、（遠隔）分散開発に携わる、アーキテクチャやチーム運営、設計手法に主な視点を当ててきました。後編ではむしろ、実装からリリースまでのより現場の中で起きていたことに焦点を当ててゆきます。この分散開発中に東京の元請けから発せられた言葉で非常に印象に残っているものがあります。興味深いと思われるので紹介します。プロジェクトの初期に画面設計書の記述をするに当たって、仕様の確認をしていたときに顧客から“そこは常識的な判断でお願いします”と仕様の不明確な部分に関して言葉を濁されてしまったことが何度かありました。 システムを作るうえで“常識的な判断”って何でしょうか？ 複数のラジオボタンが並んでいてもある人は当然単一選択だと思い、また別の人は複数選択できるかもしれないと考えるでしょう。この企業間、個人間の“常識”という言葉の食い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
こんなのはどうだろうか - senzogawaのNな日々
http://www.ogis-swe.jp/process/am-res/am/artifacts/userStory.html
- ペアプロ小劇場 - 2003/04/02
http://oss.timedia.co.jp/index.fcgi/kahua-web/show/column/%A4%B4%CD%F8%CD%D1%A4%CF%B7%D7%B2%E8%C5%AA%A4%CB%A1%CA%B7%D7%B2%E8%A5%B2%A1%BC%A5%E0%A1%CB
http://www.nskint.co.jp/technology/xp_report.html