ソフトウェアの機能成熟度モデルをまだ信じている人はいますか?

https://stackoverflow.com/questions/65296

09-06-2019
|

質問

10年前に初めて出会ったとき、ソフトウェア用三次元測定機多くの人と同じように、私も、特にヒーローへの依存に関する言及で、多くの企業におけるソフトウェア開発の混沌とした「レベル 1」の状態を非常に正確に描写しているように見えることに衝撃を受けました。また、組織がプロセスを改善してレベルアップするための現実的な指針を提供するようにも思えました。

しかし、CMM は改善のための優れたモデルと現実的な指針を提供しているように見えましたが、CMM の遵守が私が働いたことのある組織に大きなプラスの影響を与えているのを実際に目撃したことはありませんでした。私が知っているある大手ソフトウェアコンサルタント会社は、最高レベルである CMM レベル 5 を主張していますが、そのプロセスが他の非 CMM ビジネスと同様に混沌としており、ソフトウェア製品の品質が多様であることを直接目にすることができます。

そこで気になるのですが、CMM に従ったプロセス改善を順守することで実際に目に見えるメリットを実感した人はいるでしょうか?

また、改善が見られた場合、その改善は特に CMM によるものだと思いますか、それとも別のアプローチ (たとえば、シックスシグマ）同等かそれ以上に有益でしたか？

まだ信じている人がいますか？

余談ですが、まだ見ていない人は、この面白い、本当だから見てください。パロディー

解決

典型的な CMM レベル 1 プログラミングショップの場合、レベル 2 に到達するために努力する価値はあります。これは、プロセスについて考えて書き留める必要があることを意味します。当然のことながら、これは、標準、ドキュメント、テストケースによって限界を感じているカウボーイプログラマーからの抵抗に遭うでしょう。

レベル 2 (「プロセスがある」) からレベル 3 (「全員が同じプロセスを持っている」) に移行する取り組みは、通常、部門間の戦争で行き詰まってしまうため、おそらく始める価値はありません。

他のヒント

これは、主に契約の取得/維持の手段として使用される、肥大化した文書作成作業であることがわかりました。契約を結んだ後は、そのプロセスを回避する練習になりました。

開発者として、私はそこから何も得られませんでしたが、CMMI をいじくり回して職業生活の数か月を無駄にしました。

同じことが、私が「Common Sense in a Box」と名付けた 6 Sigma にも当てはまります。プロセスにとって問題が何であるかを理解する方法を訓練される必要はありませんでした。それは一般的に非常に明白でした。

私にとっては、小規模なチームとアジャイルなメカニズムの方がはるかにうまく機能します。短いサイクルでたくさんのコミュニケーション。すべての環境で機能するとは限りませんが、私の環境では間違いなく機能します。

私の2セントだけです。

問題の中心にはこの問題があり、CMM ガイダンス自体によって明確に説明されています...

“...CMM を正しく洞察力を持って使用するには、健全な判断が必要です。知性、経験、知識が、特定の環境における CMM の適切な解釈を形成する必要があります。その解釈は、組織とプロジェクトのビジネスニーズと目的に基づく必要があります。チェックリスト指向の機械的な CMM の適用は、組織を助けるどころか害を及ぼす可能性があります...”

14 ページ、セクション 1.6 より 機能成熟度モデル、ソフトウェアプロセスを改善するためのガイドライン カーネギーメロン大学ソフトウェア工学研究所著、ISBN 0-201-54664-7。

CMM が実行されていることが表示される場合。そして速く走ってください。

組織が教えようとしている教訓を真摯に受け止めている場合、CMM と CMMI は両方ともいくつかの利点をもたらします。問題は、より高いレベルに到達するのは非常に難しく、費用がかかることです。組織がそのような努力をしているのを私が見たのは、顧客が一定のレベルに達するまで契約に入札させてくれないためです。

これにより、組織はプロセスを改善することを実際には気にせず、「数字を取得することだけ」に全力を尽くしてしまうという効果があります。

ハイエンド？いいえ。CMM-5 のショップは印象に残りません。

下端？はい。CMM-1組織は私を怖がらせます。

CMM は、新人/初心者チームが自分自身を測定し、自己改善を行うのに役立ちます。

CMMI は実際にはソフトウェアを改善することではなく、行ったことを文書化することです。企業が作成する文書の重みによって、企業の CMMI レベルをほぼ推定できます。

背景：私はソフトウェアエンジニアリングの大学院プログラムで CMMI を研究し、そのガイドラインに従ったチームで働いてきました。

私の経験では、CMM は非常に曖昧であるため、実現するのは非常に簡単です。また、彼らはあなたを認定するために来るとき、あなたの組織が選択したプロジェクトを調べます。私が以前働いていた場所では、実際の期限はなく、十分な資金があり、プロセスの隅々まで時間を費やすことができるプロジェクトでした。他のプロジェクトの多くは、ソフトウェアのバージョン管理を行わずに、コード/設計のレビューをほとんど、またはまったく行わずに継続しました。

CMM認証を重視しているのは残念だと思います。企業はシステムの運用方法を熟知しており、実際に実行しています。収益を達成するための実際のプロセスの改善に焦点を当てるのではなく、認定を取得してシステムを稼働させることに重点を置いています。正直に言うと、ほとんどの組織は後者に多くの時間を費やすよりも、前者に時間を費やしたいと考えています。

本当に重要なのは、開発に関する適切な意思決定をしたいと考えており、その決定を下すには支援が必要であることを理解している良心的な人々を抱えていることです。プログラミングは継続的なグループ活動であり、他の人たちと同じように間違いを犯す可能性があることを理解している、質の高いプログラマーの代わりはいません。

私は反復開発を行う小規模なチームの面接を何度も行ってきました。個人的には、履歴書に CMM を見た場合、それは結果よりもプロセスに関心があることを示す大きな危険信号です。

書籍/トレーニングコース/認定資格を販売するために、あらゆる正式な方法が存在しますが、それ以外の理由はありません。そのため、形式的なメソッドが非常に多く存在します。これに気づいたら、あなたは自由です:-)

ユルドンはまだ信じています. 。しかし、彼はまだ世界が2000年に終わると信じているかもしれない。

これは私個人としてはあまり信頼できるものではありませんし、将来的にもそれに従うつもりはありません。しかし、多くの場合、私たちはその理由を説明できません...

追伸少し話が逸れましたが、偽の CMMI 認定資格は、賄賂によって取得された本物の認定資格と同様に非常に一般的であることについて言及しておきたいと思います。

CMM は実際にはソフトウェアの品質については語っていませんが、ドキュメント化とプロセスの再現性に重点を置いています。言い換えれば、秩序正しく反復可能な開発プロセスを実行していても、依然として粗悪なソフトウェアを作成する可能性があるということです。プロセスが適切に文書化されている限り、CMM レベル 5 を達成することは可能です。

結局のところ、CMM は使用することも誤用することもできるツールです。最終目標がソフトウェアの品質を向上させることである場合、CMM を使用して開発プロセスを改善し、ソフトウェアの品質を向上させることができます。特定の CMM レベルを達成することが目標である場合、ソフトウェアの品質が低下する可能性が高くなります。

このモデルの信頼性を失いつつあるのは、まず企業がより成熟したソフトウェア開発モデルを求めているのではなく、CCMI レベルまで評価されることを求めてこのモデルを採用しているためです。

そしてもう一つの問題は、信頼性の喪失につながると私が思うのは、請負業者として、CMMI 評価サプライヤーが販売しているプロジェクトがモデルの実践を使用して開発されるという保証がないことです。CMMi ラベルには、同社がかつて特定の CMMi 成熟度レベルに準拠していると評価されたプロジェクトを開発したことがあるということのみが記載されています。

問題は CMMi だけではなく、企業が開発したプロセスにもあります。CMMi はプロセス自体を説明するのではなく、プロセスが何をすべきかだけを説明します。PMBOK でも同じ問題があります。実際、問題は PMBOK だけではなく、主に PMI ステートメントに従うと主張する悪いプロジェクトマネージャーに問題があります。

学校では次のように教えられました。CMM は良いアイデアですが、認定がなければ (誰でもレベル 5 / レベル 4 であると言えます)、オフショアショップ向けのマーケティングツールになってしまいます。はい、その考えは正しいですが、遵守していることをどうやって証明すればよいでしょうか?

以前はよく＿＿していた。しかし今では、CMM と CMMI はアジャイルアプローチにあまり適合していないことがわかりました。

確かに、丸い穴に四角い釘を差し込むために物を押し込むことはできますが、プッシュが必要なときは、必要なものすべてを予測し、遭遇するすべてのものを予測する能力に基づいてアプローチを構築する必要があります。ソフトウェアシステム。

そして、そのアプローチが実生活でどれほどうまく機能するかは誰もが知っています。(-:

乾杯、

ロブ

アジャイルは次の CMM ですが、どちらも脆弱です。プロセスおよび品質コンサルティングの分野は、どの業界でも優れたビジネスであり、エンジニアリング担当者と同様に、誰もが資金の流れを維持するために新しい流行語を必要としています。

SEI から最初に発表されたときの CMM は、確かな学術研究に基づいた優れた概念でしたが、すぐにプロセスコンサルタントに取り上げられ、今では価値のない資格となり、ほとんどの CIO が自分の尻を隠すために使用しています (誰も解雇されませんでした) CMM レベル 5 の会社を選択する)

アジャイルは間もなくその道を歩むことになるでしょう、そして、すぐに次の特効薬が見つかるでしょう :)

私が民間飛行ソフトウェアに取り組んでいたとき、CMM を使用していましたが、プロセスが改善されるにつれて、完了時間を正確に予測する能力も向上しました。しかし、これは面倒なプロセスでした。他のアプローチでも同様に機能するはずです。

小規模なプロジェクトでは、成功のためのプロセスへの依存度が低くなります。重要な指標は、ヒーローと傍観者の比率です。HTBR が 0.2 未満のプロジェクトは深刻な問題に直面しています。

組織自身の利益のために、どのような組織でもすぐに応用して採用できる優れたアイデアは数多くありますが、あらゆる種類の冗長な文書が必要なため、バッジを取得するのは面倒です。

問題は、CMMi がプロセスではなく、どのようなプロセスを選択するかについての単なるガイドであり、それ自体が中途半端なアイデアを飛び交わせることになるということです。

もう一つのポイントは、移行は始めたばかりのときは本当に苦痛ですが、それは他の歯が生えるトラブルと同じだと思います。

CMMi の価値を理解する際の主な問題は、CMMi 自体を理解することです。

CMMi は、ソフトウェア生産の継続的改善に対する文書化されたアプローチです。

SPC による継続的改善を理解することは製造業でも十分に困難ですが、無形のソフトウェア製品が加わると、その困難さは指数関数的に高まります。

CMMi を初めて使用する人または組織には、次のことをお勧めします。現在のプロセスを文書化してから、プロセスとは独立してどのような結果 (コスト/利益) を測定できるかを検討します。このようにして、標準のプロセスや手順が変更された場合、「より良い」結果が得られます。この演習の前提条件は、文書化された安定した反復可能なプロセスです。アドホックな環境では、「似たもの」を比較していないため、変更によるメリットを測定することは不可能です。

最初に上記の概念に焦点を当てることで、組織は CMMi の本質的な価値を理解し、受け入れ始めます。

伝説によれば、多くの契約を結んだ米国国防総省は、多くのプロジェクトが時間とコストの超過に直面しており、たとえ納品されたとしても、そのプロジェクトは注文どおりではなかったという。

そこで彼らは、請負業者が時間通りに、予算内で、要求に近いものを確実に納品できる方法を求めていました。こうして、能力成熟度モデルが誕生しました。

理論は、物事を書き留めておけば、消耗しても生き残れるということです。しかし、すべてを書き留めるだけでは十分ではなく、それらが正しく書かれているかどうかを確認する必要があります。とりわけ。

このすべてを通じ、彼らはこれらすべてを行うためのコストを考慮することを決して考えませんでした。なぜなら、国防総省の観点からすると、1 年以内に何かを得るために 100 万ドルのプロジェクトを出し、結局 10 年間で 1,000 万ドルを支払ったが、望んでいたものは得られなかったとして、そして今、代わりに得られたとしたら、実際に欲しかったものを手に入れるために、同じものに 500 万ドルを支払っても、彼らはまだ 500 万ドルを節約しており、実際に何かを手に入れていることは言うまでもありません。

したがって、米国国防省などの請負業者である場合は、CMM を入手してください。これが要件となるためです。しかし、限られた予算、限られた時間などでプロジェクトを獲得するために、elance で何千ものソフトウェア開発ショップと競争しているとしたら...CMM は良い選択ではありません。

そうは言っても、CMMI Dev PDF (執筆時点では v 1.3) を自由に読んでください。良い点がたくさんあります。それは組織を非常にうまく解体します。そして、「なるほど！」と思う点があれば。私にはこの問題があります」という場合は、ぜひその知恵を使って問題を解決してください。私たちの場合、小さな変更の 1 つは、要件を提供できるすべての人のリストを作成することでした。要件を提供できる人が複数いる場合、あるソースからの要件は他の人に回覧され、バックログに追加する前に「オーケー」と言わなければなりませんでした。この小さな変更により、作業と再作業の量に大きな違いが生じました。

つまり、プロセス領域を見て、痛みのある領域と比較し、CMM からの提案を受け入れます。実装方法はあなた自身のものです。また、時間もコストもあまりかからない方法でいつでも実装できます。しかし、関連する ISO/IEC 規格にも同じことが当てはまると思います。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow