能力成熟度モデル統合 (のうりょくせいじゅくどモデルとうごう、英: Capability Maturity Model Integration, CMMI) は、組織がプロセスをより適切に管理できるようになることを目的として遵守するべき指針を体系化したものである[1] 。 平易な言い方をすると、ソフトウェア開発組織及びプロジェクトのプロセスを改善するために、その組織の成熟度レベルを段階的に定義したものである。 CMMIは、もともとは能力成熟度モデル (CMM; Capability Maturity Model) として開発された。 成熟度レベルの特性 CMMIは、プロセスの評価や改善をすすめるための枠組みであり、段階表現と連続表現の2つの表現方法がある。段階表現では、組織の実施プロセスを評価し、レベル1からレベル5までの5段階の成熟度レベルを(組織に対して)出すことができる。連続表現では
ソフトウェア開発をする際、客先に常駐するケースも多々ありますが、 そのときに注意する必要があると思われます、 ソフトウェア契約「請負」と「準委任(委託)」の違いについて、 改めてメモしておこうと思います。 (「請負開発」と「委託開発」とでも言うんでしょうか。。。) 請負も、準委任も、他社の労働力を利用するための契約なんですが、 いくつか違う点があります。 ・請負 仕事が完成することで、報酬が得られる契約。 私のイメージは、受注生産みたいな感じです。 ・準委任契約 労働力を提供することで、報酬が得られる契約。 私のイメージは、日雇い労働者とかアルバイトみたいな感じです。 ちなみに、 委任は、法律行為の事務の委託をすること。 準委任は、法律行為以外の事務の委託をすること。 だそうです。 これに対し「派遣」は、準委任契約に近いですが、 労働者が、派遣先の指揮命令の下で働くことをいいます。 つまり
学生の頃、いわゆる国語の授業や試験が好きではなかった。日本語の文章を読んで何をどのように感じようと人の勝手ではないか。どうしてそのような感じ方に「正解」なるものが存在するのか理解出来なかったし、そもそも国語の試験が存在する意義も良く分からなかったように思う。 しかし、そんな国語の試験から遠く離れてみると、今さらながらだけど、そのような国語の授業の存在価値に気付く時がある。 問題の元凶は、仕様書だ。ソフトウェアの開発を学校で習ってきた人でも、他人に見せるような仕様書を書き上げた経験を持つ人はほとんどいない。会社に入って初めて仕様書を読み書きするわけだが、その中には、そもそもまともな「てにをは」の使い方が出来ていない文が珍しくないし、何を言わんとしているのか、何度読んでも逆さから読んでも想像力たくましく行間を補っても理解出来ない文章も少なくない。 その結果、仕様書を巡って悲劇と喜劇が入り混じっ
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
Software Engineering Ethics Research Institute Department of Computing
ソフトウェア開発の工数・期間の見積もり手法。1981年にバリー・ベーム(Barry Boehm)博士が提唱した。 具体的には開発するソフトウェアの予想されるコード行数に、エンジニアの能力や要求の信頼性といった補正係数を掛け合わせて(名目工数×努力係数)、開発に必要な工数、期間、要員、生産性を算出する。実装言語の違いに左右されず、客観的な数値を算出できるといわれている。また基本の数式モデルについても、実際のプロジェクトにおける適用結果をフィードバックし、精緻化を重ねている。 しかしCOCOMOでは分析・設計工程の見積もりが不可能なことに加え、組織全体の開発能力の成熟度や、開発・テスト・検証を重ねる「繰り返し型開発プロジェクト」に適していないという問題があった。そこで従来のCOCOMOを拡張し、ファンクションポイント法やCMMの概念を取り入れ、より正確な工数算出を実現したCOCOMO IIが提
サッカーで相手チームのオフサイドトラップ戦法で負けたチームの監督が「そもそもオフサイドというルールがあるなんておかしい」と言ったら無能扱いされてしまうでしょう。同様に、他社から特許攻撃を受けている企業が「今の特許システムはおかしい」と言っても、自社の特許戦略がちゃんとしてなかったことを公言しているに過ぎません(もちろん、Googleのことを指して言っています)。 とは言え、そもそも今の特許システムは本当にあるべき姿なのかという議論は当然に必要です。サッカーもその誕生以来ルールは変わってきているわけですから、ルールをどう変えるべきかという議論をするのは当然です(ただし、個々のゲームの話をしている時に、ルール設計というメタな話を持ち出すことは「スレ違い」とうことです)。 ルールがどうあるべきかという話で言えば、現在の特許システムに問題なしと考えている人は(一部のパテントトロールを除いて)ほとん
288ページという少ないページ数の中に、ほとんどの見開きの中に図をいれて、アジャイル開発のすべてがザックリ凝縮された書籍です。思わず「こういうのが欲しかったんだ!」と声に出してしまう内容に仕上がっています。この業界の新人に必ず読ませたいバイブルです。 今の仕事やプロジェクトに問題がある。順調でない。解決策の糸口が欲しい。 アジャイル開発に興味がある。はじめてみたい。どういったものか知りたい。 もっと価値のあるソフトウェアを顧客に提供したい。 ソフトウェア開発に携わるすべての人(プログラマ以外にも)にオススメします。東京に住んでいる人はよかったら読書会に参加してください。 良いコードを書く技術 -読みやすく保守しやすいプログラミング作法 (WEB+DB PRESS plus) 今年、プログラミングを本格的にはじめた人や、会社に入って多人数での開発をはじめてやる人に読んでもらいたい書籍。自分一
生産性という言葉があります。単位時間当たりに何ステップのコードを書けるかを指します。プロジェクトの見積ステップ数を生産性で割り、必要な要員数を勘定するなんてことはめずらしくありません。人月の計算と要員の手配をしている管理側にとっては楽な方法です。 生産性の均一化は本末転倒 そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 http://d.hatena.ne.jp/higayasuo/20080325/1206421786 穴埋め式の解答欄と同じように、穴埋めにロジックを書けば誰でも同じものが出来上がる。誰でもできるから単価を下げられるし、見積値のブレも小さくなる。大手SIerの経営層はそう考えて、研究部門にフレームワークを作らせたり見積手法の研究
個人で10万行を超えるソフトウェアを書くコツがあれば教えてください。 自分は趣味でも仕事でもソフトウェアを書いていますが、だいたい2、3万行程度のソフトウェアを書くことよくあります。逆にそれ以上のソフトウェアを書くことはありません。だいたい、そうなっていしまう理由は、仕事の場合はそれぐらいでソフトウェアが完成するから、趣味の場合もある程度形になってしまうのと、飽きてしまうのが大きいでしょうか。でも、何となく元々自分には10万行超のソフトウェアを書けないのでは、という気がします。 巷をみると、ものすごい生産性で大量のコードを書いている人がいて、そういうのを見ると、いったいそういう人はどうやっているのかな、というのが最近疑問に思っています。 やはり、「きちんとしたソフトウェア」はそれなりの規模になることが多く、個人でもそのような「きちんとしたソフトウェア」を書いてみたいのですが、何かコツがあっ
概要 フールプルーフ(foolproof)とは、機械やソフトウェアなど人が使う道具の設計についての考え方の一つで、利用者が操作や取り扱い方を誤っても危険が生じない、あるいは、そもそも誤った操作や危険な使い方ができないような構造や仕掛けを設計段階で組み込むこと。また、そのような仕組みや構造。 フールプルーフ設計では「人間は間違えるものである」「理解が不十分な人が取り扱うこともある」という前提に立ち、誤った使い方をしても利用者や周囲の人を危険に晒したり、機器が破損したり、致命的な事態や損害を生じさせないような構造に設計する。 また、そもそも誤った使い方ができないような構造や操作方法にしたり、危険な使い方をしようとすると機能が停止したり自動的に初期状態に戻ったりするような機構を組み込むといった対策が行われることもある。 よく知られる例としては、正しい向きにしか挿入できない電池ボックスや、扉や蓋が
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/5/6 ある重要なことがプログラミングやソフトウェア開発についての文献でほとんど語られず、そのため私たちは互いに誤解する結果となっている。 あなたはソフトウェア開発者だ。私もそうだ。しかし私たちの目的や要求は異なっているかもしれない。実際、ソフトウェア開発にはいくつかの異なる世界があり、異なった世界ではルールも異なっている。 あなたがUMLモデリングの本を読んでも、それがデバイスドライバのプログラムを作るのには役立たないということはどこにも書かれていない。あるいは「(.NETに必要な)20MBのランタイムは問題ではない」というアーティクルを読んでも、それは当たり前のことに触れていない:あなたがROMが32KBの携帯電話のためのコードを書いているなら、それは十分に問題だ! ソフトウェア開発には
オープンソースソフトウエアのラインセンシングと IPR:Intellectual Property Right (知的財産権)についての情報です。 オープンソースライセンスの説明
Expanded Memory Specification (EMS) は、MS-DOS上でのメモリ拡張手法。ロータス、インテル、マイクロソフトの3社が提唱したことから、その頭文字を付けてLIM-EMSとも呼ばれる。 初期のMS-DOSはIntel 8086向けに作られていたことから、8086が扱える最大のメモリ空間である1MB以上を扱うことが考慮されていなかった。8086が登場した当初は8ビットプロセッサの最大64KBの空間に比べると余裕があるように見えたが、ROMやVRAMの為に消費される空間を除いたメインメモリ空間は640KBまたは768KBに制限され、アプリケーションの規模が拡大し、また扱うデータが増大すると1MBでも不足するようになった。 やがて1MBを越えるメモリを扱える上位互換品である80286や80386が登場し、メモリモジュールが安価に手に入る時代に入ったが、リアルモード
Inspired by モテる女子力を磨くための4つの心得「オムライスを食べられない女をアピールせよ」等 こんにちは、自由恋愛マネジメントを専攻している日本男児ギークです。私は特許も秘密もありませんしタダですが、自由恋愛に関してはプロフェッショナル。今回は、モテるGNU女子力を磨くための4つの心得を皆さんにお教えしたいと思います。 1. あえて2~3世代前のライセンスを適用するあえて2~3世代前のソフトウェアライセンスを使うようにしましょう。そして飲み会の場で好みのハッカーな男がいたら話しかけ、わざとらしくライセンスの互換性を確認してみましょう。そして「あ~ん! このライセンス本当にマジでチョームカつくんですけどぉぉお~!」と言って、男に「どうしたの?」と言わせましょう。言わせたらもう大成功。「ライセンスとか詳しくなくてぇ~! ずっとコレ使ってるんですけどぉ~! GPLと互換性がなくて使い
EmscriptenはLLVMをJavaScriptに変換するソフトウェア。PythonやLuaをWebブラウザ上で実行できる。 EmscriptenはPython/JavaScript製のオープンソース・ソフトウェア。LLVM(Low Level Virtual Machine)という技術がある。ソースコードをアーキテクチャに依存しない中間コードに変換し、最適化した上で各マシン向けにネイティブなコードを出力することでより効率的なバイナリを作成できるというものだ。 Python実行例 つまりLLVMが生成する中間コードを使えば、元々の言語は気にせずに動くという訳だ(おそらく)。それを実証してくれるプロジェクトがEmscriptenだ。 EmscriptenはLLVMの中間コードをJavaScriptに変換するソフトウェアだ。つまり中間コードにさえ変換できれば、それをJavaScriptに変
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く