要件定義の勘どころ
はじめに 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。 「何でこの機能が必要なんですか？」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。 本稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。 何をやるのか、そしてなぜそうするのか 要件定義書はジグソーパズル？ システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていまし
suicaは実はたまに落ちている - 紅茶屋くいっぱのあれこれ日記
suicaのサーバーはみんなの知らないところで、実はたまに落ちているそうだ。 だがシステムが止まることはない、計算上センターは3日ぐらいは止まっていても大丈夫だそうだ。 だからサーバーが落ちたなどとニュース沙汰になることは殆ど無い。 suica開発陣頭指揮をされていたかたが、その実績をまとめてと頼まれ、博士論文にしたそうだ。 suicaの実例を述べるだけだと技術論文になってしまうので、一般化して論文を書きあげたそうなのだが、審査に携わった専門家の人達はそんなものが動くわけないだろうといったらしい。しかし現実問題としてsuicaは動いてしまっている。 本人いわく、だってそれで動いちゃってるんだもん。だそうだ。 実装は時として奇妙に見えるかもしれない。 フィールドには神がいる。 …その意や、なんで落ちても大丈夫かなどはまた後ほど。 スイカのセミナー 昨日はスイカのセミナーだった。 JR東でスイ
概要設計工程でRedmine導入してみた事例 - T/O
やっぱり事例だよねということで、自分とこの事例をまとめてみる。 お仕事の概要 規模 => 当初の見積もりは900時間。ただし、途中で2割くらい減った。 期間 => 2ヶ月 メンバー => 3~4名。自分込み。 2〜3名が設計書作成、自分はレビュアーとして参加しつつ雑務。 概要設計に先立ち、要件定義は完了。30項目ほど。 滝。 Redmineの設定など 「概要設計」をバージョンとして作成。 30項目の要件をチケットとして登録。 ターゲットバージョン => 「概要設計」 開始日 => 登録したその日 期限日 => 概要設計完了予定日の2w前 予定工数 => それぞれの見積もり値を設定 担当者 => 設定しない ユーザの権限は全て「管理者」。 5名程度なら問題ないんじゃないの？ チケットのフロー 新規 -> 担当 -> 作成済 -> レビュー済 -> 完了 運用方法 タスクの割り振り それぞれが
情報システム関係の人とかこれ見とくといいよ - チョコっとラブ的なにか
こんなの出てたから、見ておくといいかもね。 経済産業省では、情報システムの取引において、現行の「人月方式」以外での価格決定方法を模索するため、情報システムの付加価値に着目して価格を決定する「パフォーマンスベース契約」について検討を行ってまいりました。 今般、「情報システムのパフォーマンスベース契約に関する調査研究」報告書として取りまとめましたので、公表いたします。 「情報システムのパフォーマンスベース契約に関する調査研究」報告書の公表について - 経済産業省 本文のさわりにはこんなことが書いてあったよ。 1 はじめに 1-1 背景と目的 我が国の情報システム市場は、現在、主として「人月ベース」の価格表示を行っており、それに伴う価格の根拠がユーザ側の価格への不信感につながっていることは従来から多数指摘されている※が、残念ながら、この課題は現在まで業界全体として抜本的に解決されるには至っていな
プロジェクト管理やテスト工程をクラウド化する - プログラマの思索
Hudsonの下記記事を読んだ感想をメモ書き。 【元ネタ】 Hudson Selenium PluginでHudsonクラスタをSelenium Gridに - 川口耕介の日記 近年、HadoopやSeleniumなど、複数のサーバ上で動作する事が前提のツールが増えてきており、マルチコア化・クラウド絡みで、このトレンドは今後も続くと予想されます。 ところが、こういったツールはセットアップと運用保守に手間がかかるという欠点があります。 Hudsonで僕がやろうと思っている事の一つは、Hudsonのクラスタ上にこういったツールをインストールするのを簡単にすることです。 Hudsonのクラスタはインストールがとても簡単ですし、プラグインのインストールも容易なので、この環境の上に他のツールをオーバーレイすることで、手間なく様々なツールを利用できるようになります。 「ThoughtWorksアンソロ
チケット駆動開発の論文 - プログラマの思索
さかばさんがチケット駆動開発の論文を書かれたのでリンクしておく。 【元ネタ】 ソフトウェアさかば: TiDD：チケット駆動によるアジャイル開発法 さかばさんの論文の主張を抽出すると下記になる。 １・TiDD(Ticket Driven Development)は、古くからある障害管理ツールなどを包括的な構成管理ツールへ拡張し、それらのツールに合わせた開発プロセスである。 例： バージョン管理(ソース管理)→Subversion 障害管理→Redmine 単体テスト→テスト駆動開発 自動ビルド→継続的インテグレーション ２・アジャイル開発を運用する上での難点の一つである進化的保守は、TiDDでは、プロジェクト管理をチケット管理で置き換えることで解決しようとする。 ３・二つ目の難点である並行開発は、メインラインモデルとチケット管理の組み合わせで解決しようとする。 ４・３つ目の難点である頻繁なリ
Springの新しいメンテナンスポリシーでJava界の勢力図が変わる - ひがやすを技術ブログ
Springの新しいメインテナンスポリシーが発表されました。 http://www.springsource.com/node/558 それに対するTSSの反応はこちら。 http://www.theserverside.com/news/thread.tss?thread_id=50727 新しいメンテナンスポリシーがどういうものかというと、 新しいメジャーバージョンをリリース後、3ヶ月はコミュニティー(無償)バージョンをリリースする。 3ヶ月たった後のメンテナンスリリースは、エンタープライズ(有償)版のお客様だけにリリースする。 エンタープライズ版は、3年間保障する。 3ヶ月たった後に行われた修正は、次のメジャーリリースには含まれる。 というものです。メジャーバージョンとは、二つ目の数字までのリリースのこと。例えば、2.1.xの次に2.5.0がリリースされれば、メジャーバージョンのリリ
CVS/Subversionを使ったバージョン管理（前編：バージョン管理の基礎） | OSDN Magazine
ソフトウェアを開発する際、ソースコードや各種リソースの管理に役立つのがバージョン管理システムだ。バージョン管理システムはソースコード管理システムなどとも呼ばれ、大規模な開発を行う際には必須と言っても過言ではない。また、大規模な開発だけでなく小規模な開発や個人による開発においても、ファイルの変更履歴の記録やバックアップといった用途に活用できる。 本特集ではバージョン管理システムの基本的な考え方や用語を解説するとともに、オープンソースソフトウェア/フリーソフトウェア開発において多く利用されているバージョン管理システムである、SubversionおよびCVSを使ったバージョン管理方法について説明する。前編となる本記事では、まずバージョン管理システムの基本的な考え方と、用語について解説する。 バージョン管理システムのメリット バージョン管理システムとは、その名のとおりプログラムのソースコードや各種
ソフトウェア構成管理に至るまでの道のり - プログラマの思索
「何故、設計書をバージョン管理するのか？」という疑問から、ソフトウェア構成管理について考え直してみる。 ＃あくまでもメモ書き。 【元ネタ】 ■[development][trac]構成管理ツールをいかにして導入するか ■[システム開発][構成管理]構成管理ツールはどのようなタイミングで導入し、どのように活用すべきなのだろうか？ ■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 ソフトウェア構成管理 【1】バージョン管理が無かった頃 今でも多いが、WordやExcelの設計書をバージョン管理していないプロジェクトは多い。 その時の最大の問題点は、■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 にその理由が書かれている。 ほっておくと自然増殖してくるのが、下記のような形式のドキュメント
ソフトウェア開発をIT化する - プログラマの思索
【1】開発の殆どの現場はIT化されていない 「ソフトウェア開発をIT化する」という言葉は自己矛盾な気もする。 しかし、SIerの開発の現場をのぞくと、作業は実は殆どIT化されていない事実に気づく。 プロジェクトリーダーならば、顧客や上司から下記の報告をいつも求められているはずだ。 1-1・プロジェクトで開発する全機能のうち、今、進捗は何％で、後何％残っていますか？ 1-2・システムテストで上がったバグは今いくつで、後いくつ残っていますか？ 1-3・明日のリリースの前に、今残作業はいくつで、その優先度はどうなっていますか？ 1-4・見積の工数と実績工数の差はどれくらいですか？ 上記の数値を一瞬で出せる現場は、実は殆どないのではなかろうか？ 理由は、顧客や上司が求める数値は引き算で要求されるので、一旦現状の数値をメモリに保持して計算しないといけないから。 プロジェクトリーダーは、上記の数値を毎
Redmineでプロジェクトを見える化する - プログラマの思索
顧客の業務を良く見ると、EXCELはシステム化してない業務で使われる。 経理で締めの計上をEXCELで計算して提出。 営業マンが集めた顧客データをEXCELでまとめて提出。 IT業界も然り。 仕様書をEXCELで書いて開発者に渡す。 バグ報告票をEXCELでやり取り。 更に、Excelで扱う業務では、ソフトウェア構成管理(SCM)が使いにくい。 バイナリファイルのため、履歴が残せないから。 IT化の利点はリアルタイムに集計して業務の見える化をすること。 又、集計をリアルタイムに自動化できること。 なのに、Excelの集計作業で、かなりの時間を浪費しているのが普通だろう。 進捗管理をExcelとRedmineで比較してみよう。 DBにあれば色んな観点からリアルタイムに集計できるのに、Excelで管理すると、VBAマクロを使いまくって、Excelが一つの複雑なシステムとなる。 特に、プロジェク
プログラマの思索: RedmineがExcelよりも素晴らしい点
Redmineの使い方は下記を見よ。 http://www.redmine.org/projects/show/redmine 【1】以下、Redmineを使った感想を書いてみる。 1-0.ガントチャートがリアルタイムに表示される。 こいつに一番感動した。 プロジェクトリーダーは、ガントチャート保守に、彼の作業時間の殆どを費やす。 その理由は、プロジェクトのリスクがガントチャートでしか把握できないからだろう。 考えてみれば、作業の開始日と終了日、作業状態さえ入力すれば、リアルタイムにガントチャートは計算できるはず。 殆どのITプロジェクトのガントチャートは、手作業でかなりの時間を浪費して作っているか、MSProjectのように保守しても理解しにくいか、どちらかだ。 ソフトウェア開発のプロジェクト管理で最もIT化されていない部分と言える。 1-1.SVNリポジトリとチケットが相互リンクできる
ソフトウェア開発を志望する人が学生時代にやっておくべきこと - 千里霧中
FETISH STATION - Re: 学生のうちにしておくべきこと 403 Forbidden 学生時代を振り返ると、あれをやっておけば良かった、などと後悔がいろいろと立ちますが、一方であれをやっていて今思えば幸運だったと思うこともいくつか思い出されます。 最近学生時代の過ごし方についてアドバイスするエントリをよく見かけますが、そこで私も、ソフトウェア技術者を目指す新大学生にむけて、個人的な経験上、学生時代にやっておいた方が良いと考えることについて、いくつか取り上げたいと思います。 ・多くの良書を読む ソフトウェア開発の世界では、例え本であっても、技術や考え方の基礎となるような高い価値を持つ良書が沢山あります。 しかし社会人になってしまうとまず読書の時間がなくなります。確実に自分のためになると分かっていながら、読めない本が大量に発生するのもざらです。また手に取る本も仕事に直接関係のある
アメリカにはSIerなんて存在しない - GoTheDistance
知人のmark-wadaさんのBlogからTB。 親子丼的ビジネス奮闘記(4) IT業界構造 SIerなんてものは無い 米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のＩＴ部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。 ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日本のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。 親子丼的ビジネス奮闘記(4) IT業界構造 言われてみれば・・・、っていう感じですが改めて目が鱗です
へ〜たのめも:Google のソフトウェア・エンジニアリング - livedoor Blog（ブログ）
2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
動的コンテンツ配信システムの作り方 （システム設計） : 研究開発
http://forza.cocolog-nifty.com/blog/2008/05/post_2646.html