はじめて使うJazz ― チーム開発のためのオープンな統合プラットフォーム
チーム開発のためのオープンな統合プラットフォーム「Jazz」 Jazzプロジェクトと言っても日本ではご存じない方もいらっしゃるかもしれません。「Jazz」とは、ソフトウェア開発チームのコラボレーションを支援するための新しいテクノロジー・プラットフォームであり、それらを開発するプロジェクトの名称です。大きな成功を収めたEclipseプロジェクトの次のステージとしてIBMが進めているプロジェクトです。Jazzプロジェクトは、人々がソフトウェア開発においてどのように協調して働くべきか、すなわち、いかにコラボレーションし、生産性を向上させ、透明性を確保してソフトウェア開発を行うかという観点で開発されています。 Eclipseは、エディター、コンパイラー、デバッガーなど開発者がこれまで別々に利用していたツール群を1つの環境に統合したプラットフォームを提供することによって開発者個人の生産性を向上させて
鹿児島大学プロセスモデル
最終更新日：2006.10.19 - 渕田孝康 ソフトウェアのライフサイクル 一般に、ソフトウェアには次のようなサイクルがあるといわれる。 PM-図1 ソフトウェアの開発には時間がかかるものであり、以前のソフトを改良しつつ使いまわすケースが多い。要求が発生してからソフトウェアが作成され、何年かに渡って修正や改良を繰り返し、最後に廃棄されるまでの過程をソフトウェアのライフサイクルと呼ぶ。 ライフサイクルの各工程について簡単に述べる。 要求分析 発注者（顧客）がそのソフトウェアを使って行いたいこと（業務）を明確にし、ソフトウェアが満たすべき機能を決定する。 システム設計 要求をどのようにして機能として実現するかを決定する。この段階で利用者とシステムの情報交換の方法（ユーザーインターフェイス）を決定することが多い。 プログラム設計 機能をどのようにプログラムで実現するかを決定する。複雑なソフトウ
ファンクションポイント法によるソフトウェア開発規模・工数見積の現状
１．ソフトウェア開発環境の変化と見積手法 ソフトウェアの開発形態がメインフレーム（以下Ｍ/Ｆ）からクライアントサーバ（以下Ｃ/Ｓ）に移ってきている中で、プログラムレベルでは、開発方法が手続き（コード）記述ベースからビジュアル開発ツールベースにシフトしてきている。このため、ソフトウェア規模・工数の見積を行う際に、これまでの事実上の標準だった「LOC（Lines of Code:プログラム行数のこと）」を使うことが困難になってきている。こうした中で、ソフトウェアの持つ機能を数えることでソフトウェアの規模を測る尺度「ファンクションポイント法(以下ＦＰ法)」が現在その後を埋める有力候補となっている。 当部では、ＦＰ法の普及動向を把握するため、見積手法に関するアンケート調査、ＦＰ法先行導入企業に対するヒアリング調査を行ったので、ここにご紹介する。 ２．ファンクションポイント法とは ＦＰ法は
ファンクションポイント法入門
ファンクションポイント法とは、ソフトウェアの規模（大きさ）をそのソフトウェアが持っている機能を元に測るための手法です。ソフトウェアという目に見えないものの大きさを測るのは難しい事ですが、現在ISOでも検討が進められており、このファンクションポイント法をベースとした「機能的規模計測」として標準化される見込みです。 ファンクションポイント法の概要については、こちらをご覧下さい→ファンクションポイント法
FP法について - Writing Cafe
[Programs] / 最終更新時間：2004年06月24日 23時45分47秒 概要 最近、開発効率をなんとかしたいという思いが強くていろいろ調べている。どの手法を使うとどうなるのかが分からないと判断がつかない。そこで開発効率を測る物差しとしてファンクションポイント(FP)法に注目してみた。 よりよい開発のあり方については、楽しいプロジェクト運営もどうぞ。 目次 概要 目次 参考本 現状 ソフトウェアの規模 注意すること FP法の用語 用語の言い換え データファイル 要素処理 FP値の計測手順 どんなレポートを書くか？ プロジェクト見積もり 1. FPの計測タイプを識別する 2. 計測範囲とアプリケーション境界を識別する 3. すべてのデータファイルと、その複雑度を識別する ファンクションポイント計測一覧表-ファイルをリスト化 ファンクションポイント計測一覧表-ファイルの複雑度を加える
ソフトウエアエンジニアリング事始（６） ＦＰ法をマスターしよう - ［ITプロフェッショナルのスキル］All About
◆ＦＰ法の全体像 まず、ファンクションポイントの説明をする前に、システムの機能とは何かを説明しておく。システムの機能とは、 ユーザが要求する効用 のことである。 ファンクションポイント（ＦＰ）法が注目されているのは、ＦＰ法が計測対象としている機能が「ユーザからみて」の基準というところに最大のポイントがある。機能は量として計測して、機能量（Functional Size）という形で表現する。 機能量の意味は、工数ではない中間的な量であり，プラットホームに依存しにくいことである。また、ユーザとシステム開発者の見積もりの意識あわせにもつながっていく。 ＦＰ法は機能を一旦、機能量で表現しておき、そこから、本来の見積もり目的である、規模（例えば、行数）や工数に換算する見積もり手法である。図にＦＰ法の全体像を示す ※ 児玉公信「システム開発の見積もりのための実践ファンクション
FrontPage - Trac Lightning Wiki
最近の更新 (Recent Changes)2016-03-02Plugin Plugin/4.0.0/AddCommentMacro 2016-01-30Plugin/4.0.0/TracNavMacro Plugin/4.0.0/TocMacro Plugin/4.0.0/PrivateWikiPlugin 2015-11-22Plugin/4.0.0/FootNoteMacro 最新リリース情報traclight (1.5.2)2008-02-13 23:09trac-lightning (3.2.0)2013-04-29 13:00trac-lightning-dev (3.2.0beta1)2013-03-16 11:37 Wikiガイド(Guide)Wikiの文法 リンクの種類と文法 ブロックプロセッサ 拡張文法 サイドバー プロジェクトWikiでの広告設定 サイドバー (Si
小野和俊のブログ:IT業界の大企業での生々しい話を5つほど
先日某所で講演をする機会があったのだが、 そこでお会いした大企業に所属されている方からの発言でいくつか印象的なものが あったので、ブログに書くことにした。 中にはぐったりしてしまうような内容のものもあるのだが、 会社が大きくなるとこういうことが起こりえるのだという自分への戒めも込めて。 とある大手 SI の方の話。 会社で 2ch へのアクセスを禁止したところ、開発の速度が目に見えて低下したので、 何が起こったのかと現場にヒヤリングしたところ、今までは困ったときに 2ch で聞いて問題を解決していたが、2ch にアクセスできなくなって、 はまってしまったときにどうにもならなくなってしまったとのこと。 これは Messenger / Skype を禁止している会社にも同様のことが言えるだろう。 プロが 2ch で聞くというのはどうなのかという意見もあるとは思うが、 会社の枠を超えた横のつなが
郵政民営化のシステム開発は、デスマーチになっているのではないか?
プロジェクトの火消し屋を長年やっていると、キナ臭い匂いを感じ取れるようになる。郵政解散までやって耳目を集めた「郵政民営化プロジェクト」、中の人はとってもデスマーチだと勝手に忖度して、合掌、礼拝、南無～。 先週、日本郵政公社は、かなり重要な決定を下した。 つまりこうだ―― 「2007.10.1の民営化スタートまでに、システム開発が間に合わないと判断された場合、閣議決定を経て民営化を半年延期する」―― 郵政民営化法には、こんな特例条項がある。社会的に巨大なインパクトを持つプロジェクトだから、GO/NOGOは法律＋閣議決定を要する。 しかしだ、1末時点での開発状況を分析した結果、「一部のシステム開発に遅れがあるものの計画の日程には十分間に合うと判断し、この条項を適用しないことを決めた」という。郵政公社の生田総裁によると、「開発はおおむね順調で、民営化の工程が押されるものではない」（※1）。要する
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「アート・オブ・プロジェクトマネジメント」読書感想文【まとめ】
ITプロジェクトのマネジメントにおいて、本書はまさに宝の山といえる。 一回の探索では持ちきれないほどのアイディアがザクザクと手に入る。しかも、ひとつひとつの宝が、著者の経験に裏打ちされ、考え抜かれているため、一回読みでは消化不良を起こす。それぞれのフェーズで読み返すことで、順番にモノにしていくやり方が良いかと。 このエントリでは、自分の振り返り読みのために、読書感想文エントリの目次と、次に読むべき本・サイトのをまとめた。わたしだけでなく、誰かの参考にもなればイイナ！ その1 ・オーバービュー その2 1章「プロジェクトマネジメントの簡単な歴史」からの考察 ・PMにとっての最重要ツール ・アート ―― 技芸と呼ぶ理由 ・ホワイトボード地獄 その3 2章「スケジュールの真実」および、 3章「やるべきことを洗い出す」からの考察 ・何のための開発プロセスか? ・見積もり確度を上げる2つの質問
POLAR BEAR BLOG アイデアを殺す22の方法
久しぶりに箇条書きネタ。How Blog > Core 77's Design Blog という経由ですが、「アイデアを殺す台詞/態度」というエントリがありました： ■ Idea killers: ways to stop ideas (Berkun Blog) で、内容はというと： 「それはもう試したよ。」 「そんなのうまく行かないよ。」 Would you like a pony? （※すみません、ここ意味分からず。検索すると割とヒットするフレーズなんですが・・・。pony = 子馬、重要でないものということで、「そんなつまらないことしたいのか？」という意味？） 「ばかげているな。」 「君はクビだ。」（※失敗すれば処罰される、という雰囲気では新しいアイデアは表にでない、という意味？） 「君には強く反対する。」 （笑い） 「予算にないな。」 「それは重要な問題じゃないよ。」 「時間がない
「アート・オブ・プロジェクトマネジメント」読書感想文（その4）
いまamazonを見たら在庫切れでやんの、ちょっと意地悪な気分になる。 本書のどのページにもヒントがある。PMな人も、リーダーな人も、ファシリテーターな人も、名前が違うだけで目的はいっしょ。読めば、あちこちに「それ知ってる・ジョーシキ」もしくは「言われて気づいた目からウロコ」のいずれかが埋まっていることだろう。 ■シンプルにすると、本質が見える これをスゴい本だと感心だけでなく、かなり気に入っている。なぜなら、著者の考え方がものすごくシンプルだから。ひょっとすると、"rule#1 : Be Simple!"という標語が壁に大書きされているのかも、と思うぐらい。 どれぐらいシンプルに考えているか、次の例で確かめてほしい。 スケジュールを極限まで簡素化してみると、どのようなプロジェクトでも、その実施期間は、設計、実装、テスティングという3つの工程に分類できます（p.30） 極限までシンプルにし
報奨金制度の提案に起因する、Debian開発者の活動意欲に関する論争 | OSDN Magazine
現在、自らをDunc-Tankと名乗る開発者たちの集団が、特定のプロジェクトを完成させたDebian開発者に対して金銭的な報酬を支払うための準備を進めている。こうしたDunc-Tankによる活動の第一目的は、Debianの次期バージョンをスケジュールどおりにリリースさせることにあるのは分かるとしても、このアナウンスについて懸念されるのは、以前にもプライベートな議論として取り上げられたことのある問題、つまり「従来は個人的な動機から仕事を進めてきたフリーソフトウェア開発者に対し、唐突に金銭的な報酬が与えられるような事態になったらどうなるか」というものである。 Dunc-Tankが最初に発表したニュースリリースによると、この組織は一種の“実験”団体であり、「開発者とユーザおよびDebianのサポータをメンバとする独立団体」であるとのことだ。実際Dunc-Tankには、Debian開発者の間でも特
プロジェクトリーダの罷免が提案されたDebian | OSDN Magazine
Debianのプロジェクトリーダ（DPL）であるAnthony Towns氏について、罷免の投票が行われる可能性がある。問題となっているのは、Dunc-Tankへの関与についてだ。Dunc-Tankとは、Debian etchを12月初頭に予定どおりリリースできるよう、寄付を集めてDebianのリリース・マネージャに財政的支援を行うことを目的とした(OTP翻訳記事)非公式グループである。 この決議の内容や、Debian憲章の下でのこの決議の正当性については、当記事の執筆時点でも議論が続いているが、仮にこれが可決された場合、次のリリースに向けて障害となる可能性が大いにある。未解決の重大なバグの数々に比べても、克服がはるかに困難な障害である。 Debian憲章では、個々の開発者が「一般決議の草案を提案する、またはその賛同者となる」ことができるということと、開発者が集合体として「プロジェクトリー
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「仕様」という言葉の罠を回避する
結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。 客先での仕様調整の場で、新人が手もなくひねられている（騙されているともいう）。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。 あたりまえじゃないか、その機能が入っているのが仕様です なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです だから、その機能が入っていないのはバグなんです したがって、あなたは無償で今すぐこれを実装する必要があります テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小
ksh Days - デスマーチについて考える（デスマーチ経験のエピローグ）
このエントリは デスマーチについて考える前にデスマーチの経験を書く の続きです。(2007/2/16追記) 私はテスタとして、必ず バグの修正を「お願いします」と言う。 バグ修正確認時は、必ず直してないところも最低１箇所は触ってみる。（でよく落ちる） バグ修正が確認できたら、できるかぎり早く「確認できました。ありがとうございました」と言う。 を実践してゆきました。 ある日、一人のプログラマさんから相談を受けました 「今度の機能なんですが、納期が近いから単体テストせずにkshさんにテスト依頼しろってSEさんから言われたんですが、そんなことしたくないんです」 以下、全文はこちら
Joel on Software -
プログラマのためのユーザインタフェースデザイン 第 1 章 第 2 章 第 3 章 第 4 章 第 5 章 第 6 章 第 7 章 第 8 章 第 9 章 ストラテジーレターV 2002年6月12日 ミクロ経済学の補完財の原理について考えていて、私はオープンソースソフトウェアに関する興味深いあることに気がついた。それが何かというと、オープンソースソフトウェア開発に多額の資金を使っている企業の多くは、それが彼らにとって良いビジネス戦略だからそうしているのであって、突然資本主義を信じるのをやめて、「言論の自由と言うときの自由」に浮かれるようになったわけではないということだ。ストラテジーレターⅤ 5つの世界 2002年5月6日 5つの世界：すべてのソフトウェア開発が同じではない。 追記：インターナルシステム、コンサルウェア、パッケージソフトの間には大きなグレーゾーンがあり、この3つの世界はしばし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロジェクトの進め方