開発プロセス

開発プロセスモデルの使い方

とあるソフトウェアエンジニアが、最近はCMMIやらSPICEやら、開発プロセスモデルの導入ばかりが強調されて、なんでもかんでも、一定の型にはめようとするものだから、これまで自分のやり方で上手く出来ていた開発が、上手くいかなくなることがある、と言っていた。

実際、CMMIやSPICEのアセスメントの専門家からも、そのような失敗のリスクの話はよく聞く。

開発プロセスモデルの導入に際して注意すべきことは、開発プロセスモデルはあくまで「モデル」なので、そこに書かれていることをそのまま開発に適用することはできないということだ。

モデルには、

  • ここではこういう事をすると良い
  • ある事と別の事はこういう関係にある

といったことが書かれている。

自分たちの組織の規則や、開発チームで使っている方法論や開発手法やツールを改めて見てみると、今現在、モデルに書かれていることをやっているのか、やっていないことは何なのかを発見することができる。

そして、

やっている場合、もっと上手くやることはできないのか?

やっていない場合、どうすればできるのか?

を考えてみる。

CMMIにせよSPICEにせよ、モデルとはそのように使うものであって、決して「型にはめる」ようなものではない。

★WOZ★

CMMI基本と実践-プロジェクトが変わるプロセス改善のすべて Book CMMI基本と実践-プロジェクトが変わるプロセス改善のすべて

著者:アクセンチュア
販売元:ソフトバンククリエイティブ
Amazon.co.jpで詳細を確認する

| | コメント (0) | トラックバック (0)

KPT

KPTという言葉は、あまり知られていないかもしれないが、

  • Keep
  • Problem
  • Try

の頭文字を並べた、プロセス改善関係の用語だ。

ある仕事が一区切りしたときに、その仕事を振り返り、

  • うまく行ったので引き続きすること(Keep)
  • 問題があったので、やめること(Problem)
  • うまく行きそうなので新たにやってみたいこと(Try)

を整理することをいう。

ただ、一つの仕事が終わると、大抵は次の仕事が待ち構えていて、終わった仕事を振り返るどころではない、というのが現実だろう。

一度に振り返るのは大変なので、普段から少しづつ書き留めておき、最後はまとめるだけ、という具合に工夫したい。

また、KPTを整理して次回の開発に活用することはISO9001やCMMIが求める「継続的改善」にあたるので、程度はともかく、そのプロセスは実施しておきたい。

★WOZ★

| | コメント (0) | トラックバック (0)

モデル検査とテストの役割

モデル検査は調査中だが、モデル検査とテストの適用順序は次のようになると思う。

1.アルゴリズム設計
2.アルゴリズムのモデル検査
3.設計
4.実装
5.静的コード解析
6.テスト(カバレッジテストを含む)
7.アルゴリズムのモデル検査(デバッグ)

4、5、6は、4→5→6→4→5、、、というように繰り返す。
7は原因のわからないバグがある場合に行う。

実際、モデル検査をバグ調査に適用して成果を出している企業もあるので、開発プロセスに7を入れるのは効果的だと思う。

★WOZ★

| | コメント (0) | トラックバック (0)

あなたの会社の開発力を診断してみよう

株式会社エクスモーションのサイトに、「開発力診断」というコンテンツがある。

質問に答えていくと組織の開発力を診断してくれる。

質問数は数問なのだが、CMMIのアセスメントでチェックするポイントを上手く抑えていると思う。

エクスモーションのキャッチコピーは「組込みシステム開発を現場から支援する」だが、この開発力診断は、Webアプリケーションを開発する組織やデスクトップアプリケーションを開発する組織、あるいはハードウェアを開発する組織でも活用することができる。

★WOZ★

| | コメント (0) | トラックバック (0)

CMMIやISO9000を上手に使おう

CMMIやISO9000についてのよくある勘違い」では、CMMIレベル5やISO9000取得を過信してはいけない、という話を書いた。
今回は、それとは一見矛盾するようだが、CMMIやISO9000にも良いところはあるという話だ。

どの辺りが良いのかというと、CMMIやISO9000には、ソフトウェア開発組織が仕事を楽にするために何をするべきかという情報が、体系的にまとめられているところだ。

CMMIでいうと、

  • 計画を立てて、
  • 構成管理をして、
  • リスク管理をして、
  • 計画を見直すタイミングをきめて、
  • レビューやテストをして、
  • 、、、(その他もろもろ)

ということが体系的に書かれている。

これらは一度分かってしまえば当たり前のことなのだが、ゼロから体系化するのは大変な仕事なのだ。この「知識が既に体系的にまとめられている」ところに、CMMIやISO9000の価値がある。

CMMIやISO9000というと、小難しく堅苦しい印象があると思うし、実際にそれらに対応しろと言われれば、面倒なわりに効果がないと感じることもあるだろう。やらされ感を強く感じるかもしれない。

しかし実際は、CMMIやISO9000はソフトウェア開発者が楽に仕事をするための道具として使える。食わず嫌いをせず、まずは勉強してみよう。そして、これらの知識を「誰かのために」ではなく、「自分たちのために」使っていこう。

★WOZ★

CMMI基本と実践-プロジェクトが変わるプロセス改善のすべて Book CMMI基本と実践-プロジェクトが変わるプロセス改善のすべて

著者:アクセンチュア
販売元:ソフトバンククリエイティブ
Amazon.co.jpで詳細を確認する

CMMI基本と実践 CMMI基本と実践

販売元:楽天ブックス
楽天市場で詳細を確認する

| | コメント (0) | トラックバック (0)

CMMIやISO9000についてのよくある勘違い

ソフトウェア開発組織が自分たちの能力を評価する方法には2種類ある。

一つはCMMIなどのアセスメントを受けることで、

もう一つはISO9000の監査を受けることだ。

CMMIの方は、その組織の成熟度を5段階評価するとともに、その組織の強みと弱みを明確にする。

ISO9000の方は、その組織の品質マネジメント上の問題点を明らかにする。

とくにCMMIの方は、数年前に流行して、国内海外を問わず、多くのソフトウェア開発会社がレベル5(最上位)を目指して、実際にレベル5の評価を受けた。そして、それらの会社に仕事を発注する側も、CMMIのレベル5を発注要件としたものだ。この傾向は今も続いている。

しかし、ここで気をつけないといけないのは、ある会社の成熟度がCMMIレベル5だ、あるいは、ある会社がISO9000を取得したといっても、それは単に「継続的に改善を進めることができる」あるいは「品質マネジメントシステムがあり、有効だ」と言っているだけであって、その会社が作り出すソフトウェアの品質や性能が良いと言っているわけではない、ということだ。

ここのところをしっかりと理解しておかないと、

  • CMMIレベル5の会社に発注したから、受け入れテストをしなくても安心と思っていたが、いざ使ってみたらバグだらけ
  • ISO9000を取得した会社に部品を発注したのに、約束どおりに納品されず、その結果、自社の顧客に製品を納められなかったために、顧客から慰謝料をとられて大赤字

という憂き目にあうことになりかねない。

★WOZ★

| | コメント (0) | トラックバック (0)

ソフトウェアにもハードウェアにも開発プロセスは必要だ

このところ、ソフトウェアの品質が以前より強く求められるようになった。

昔からハードウェアをやってきて、いまは組織で偉くなっている人がとくにそう言うことが多いように思う。

だが、そんなこと、いまさら言われなくてもわかってます。

偉そうに品質品質っていうなら、君たちハードウェア関係者は、開発プロセスを守っているのかい?

計画も立ててないし、構成管理もしてないし、進捗管理も、品質管理も、なんにもやってないんじゃないの?

知ってるよ。やってないのを。

で、きちんとやれと言われたら、やってないのを棚にあげて、ぐだぐだ言い訳をして、挙句の果てには、「改善するやりがいがあるからいいんじゃない?」とかわけの分からないことを言い出す始末だ。

「やりがいがあっていい」?

ものは言いようだが、子供の遊びや趣味で製品を作っているのではないのだから、組織としてもっときちんとするべきだろう?

お金もらってるんでしょ?

開発プロセスくらい守れよ。

と考えながら、他人に言う前に、ソフトウェアもきちんと品質確保はしないといけないなぁと考えるクリスマスでした。

★WOZ★

CMMI基本と実践-プロジェクトが変わるプロセス改善のすべて Book CMMI基本と実践-プロジェクトが変わるプロセス改善のすべて

著者:アクセンチュア
販売元:ソフトバンククリエイティブ
Amazon.co.jpで詳細を確認する

CMMI基本と実践 CMMI基本と実践

販売元:楽天ブックス
楽天市場で詳細を確認する

| | コメント (0) | トラックバック (0)

開発プロセスも勉強してみよう

最近、まわりの人と話していて、よく話題に上るのは、「そういえば、開発プロセスっていうのは、大学でも教えてもらわないし、会社でも教えてもらわないなぁ」ということだ。
で、それに続く話題は、「仕事に使わないプログラミング技術や言語を知らないのは良いとして、開発プロセスぐらい知らんと、仕事にならんだろう~」ということだったりする。

実際、世の中のいろんなプロジェクトを調べてみると、一見うまくいっているようでも、リスク管理やテスト管理がおざなりになっているのをよく見かける。構成管理や構成監査などもカタチだけ、ということも多い。

そんなプロジェクトはきまって、本来しなくてもいいはずの無駄な作業が多くなってしまい、そこで働いている人々が長時間労働を強いられて疲弊してしまう傾向にある。残念なことだ。

ということで、時間があれば、というか、時間を見つけて、こんな本を読んでみるのはどうだろう。
ソフトウェア開発に限らず、”仕事”と呼ばれる活動について、何を考え、何をしなければならないのか、をコンパクトに解説している著作だ。

★WOZ★

CMMI基本と実践-プロジェクトが変わるプロセス改善のすべて Book CMMI基本と実践-プロジェクトが変わるプロセス改善のすべて

著者:アクセンチュア
販売元:ソフトバンククリエイティブ
Amazon.co.jpで詳細を確認する


CMMI基本と実践 CMMI基本と実践

販売元:楽天ブックス
楽天市場で詳細を確認する



ブログランキング・にほんブログ村へ
にほんブログ村

| | コメント (0) | トラックバック (0)

構成管理できない人々

ソフトウェア開発を混乱させる原因はたくさんあるが、よくあるものの一つが構成管理をしないことだ。
構成管理をしない人々は、もちろん構成監査もベースライン管理もしない。
これは、つまり自分が何をどこまで作ったのかを把握していないことと同じだ。

そんな人々に、なぜ構成管理をしないのかと問うと、きまって同じ答えが帰ってくる。

「それは自分たちの仕事ではない」

耳を疑うような答えだが、実際、彼らはそう信じている。
そして、案の定、バグがいつまで経ってもなくならないとか、テストができないとか、一度治ったバグがまた出てくるとか、そんな構成管理ミスに起因する問題が次々と起こり、ソフトウェア開発はどんどん混乱していくことになる。

果たしてどうすれば、彼らを救うことはできるのだろうか?
残念ながら、その答えは持ち合わせていないが、これからソフトウェア業界に入っていこうとする若い人達には、是非、構成管理を勉強してほしい。
そうすれば、ソフトウェア開発をストレスが多くて辛いことばかりにした旧世代のエンジニア達が去った後で、きっと本来のクリエイティブなソフトウェア開発に一歩近づけるに違いない。

★WOZ★

Subversion実践入門第2版 Subversion実践入門第2版

販売元:楽天ブックス
楽天市場で詳細を確認する


実用Subversion 実用Subversion

販売元:楽天ブックス
楽天市場で詳細を確認する

| | コメント (0) | トラックバック (0)