« 2010年3月 | トップページ | 2010年5月 »

2010年4月

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

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

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

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

モデルには、

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

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

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

そして、

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

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

を考えてみる。

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

★WOZ★

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

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

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

ソフトウェア品質保証の仕事

ソフトウェア品質保証の仕事を、北風と太陽の寓話に例えて、開発部門に規則を強制するのではなく、規則を守るメリットを伝えて納得してもらう「太陽」のようなやり方をした方が良いという人がいる。

しかし、それは間違った考え方だ。

最初の間違いは、北風と太陽の寓話は「状況によって手段を臨機応変に変えるのが良い」という話であり、必ずしも「太陽」のやり方が良いという話ではない。

次に、規則は守っても守らなくても良いものではなく、守らなくてはならないものだ。開発部門が納得しているかどうかは関係ない。

例えば「飲酒運転はしてはいけない」という規則に納得できなければ、規則を無視して飲酒運転しても良いのか?

あるいは「人のものを盗んではいけない」という規則に納得できなければ、規則を無視して窃盗しても良いのか?

規則が存在する社会で、そんなことはありえない。

それらと同様に、ある組織がソフトウェア開発の規則を定めていれば、開発部門がそれに従うのは当然だ。

品質保証部門は、開発部門が規則を守っているかどうかをチェックし、守っていなければ強制的に守らせなければならない。

証拠調べを徹底して行い、開発部門の間違いを探し出して、その間違いを正す。

それはちょうど、会計監査部門の仕事と同じだ。

会計監査部門の仕事なら、冒頭の「北風と太陽」になぞらえる人はいないだろう。

ソフトウェア品質保証も会計監査と同様、組織が規則違反を犯すことで破綻するのを、未然に防ぐ仕事だ。

今一度、品質保証部門の責任と権限をきちんと考えたい。

★WOZ★

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

SQLiteは軽快なデータベースシステムだ

SQLiteはファイルベースのコンパクトなデータベースシステムだ。

Firefox、RubyOnRails、iPhoneOSのデータベースにも使われている。

全世界で普及している製品に使われているので、実用システムとしても安心して使えるだろう。

ところで、このSQLiteは、数人の小さなチームが自分たちの業務改善に利用するのにも向いている。

例えば、昨今のセキュリティ強化のために、独自サーバの運用が許可されず、また、社内のデータベースシステムへのアクセスも許可されず、という八方塞がりになってしまっているチームにとって、SQLiteのような小さなデータベースシステムを日常業務に上手く利用するのは良い方法だ。

さらに、Pythonなどの軽快なプログラミング言語と組み合わせれば、日常の仕事を手早く片付けることができるだろう。

SQLiteはオラクル同様にSQLでデータベースにアクセスできるので、SQLを少し知っていれば、すぐに使い始めることができる。

★WOZ★

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

質も量も大事

とある設計書のレビュー会が、予定時間の半分で終わった。

設計書の出来がいつもより良かったのと、参加者がレビューポイントを明確に意識していたのが良かったのだろう。

質的に、とても良いレビュー会だったと思う。

しかし残念ながら、こういう質的な部分は定量データにしてしまうと見えなくなってしまう。

定量的には、いつもより時間が短いので不十分だ、と評価される可能性が大きい。

そして、結果的にレビュー指摘密度が高くなっていると、設計書の質が悪いと評価されるかもしれない。

しかし、実際には設計書の質は良かったのだ。

そして、参加者の質も心構えも十分に良かったのだ。

だから、この場合、定量的評価は実態を表してはいないことになる。

ソフトウェア業界は、全体的に、定量的な評価を重視しがちな風潮があるが、同時に質を考えることの重要性を忘れてはならない。

★WOZ★

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

単体テストを意識してソースコードを書く

ソフトウェアの単体テストは、コードを書く時から意識していないと、きちんと行うことは難しい。

オブジェクト指向プログラミング言語でコードを書いている場合は、クラスとクラスの依存関係が多かったり、OSやミドルウェアとの依存関係が多かったりすると、後から単体テスト用のモッククラスを作るのに、かなりの労力を必要とする。

もともとモッククラスを作るのには、手間がかかるので、あとからクラスの依存関係を分析しながらモッククラスを作るのは、経験豊富なプログラマにとっても気が重くなる仕事であることだろう。

そこで、モッククラスを作る時間がない場合などはデバッグ手法をつかって、単体テストの代わりをすることになるのだが、この方法は後々のことを考えると賢明は方法とは思えない。

確かにその時は、単体テスト相当のことができるだろうが、テストコードが後に残らないので、後になって他の人が同じコードをテストしなくてはならなくなった場合や、最初にコードをテストした本人が数ヶ月後にまたテストをしなくてはならなくなった場合に、同じテストができる可能性がかなり小さい。

単体テストがしやすいように、最初からテストを意識したソースコードを書くことを心がけたい。

★WOZ★

知識ゼロから学ぶ ソフトウェアテスト Book 知識ゼロから学ぶ ソフトウェアテスト

著者:高橋 寿一
販売元:翔泳社
Amazon.co.jpで詳細を確認する

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

iPadのプログラミング環境

以前書いたiPad関連記事にコメントを寄せていただいた方から、Squeakは既にiPadに移植されているものの、アップルがAppStoreへの登録を許可していないとの情報をいただいた。

Squeakはこのブログで何度も紹介しているオブジェクト指向プログラミング環境だ。

小さな子供でも学習が容易で、プログラミングを授業に取り入れている小学校もある。Squeakをさらに使いやすくしたScratchという環境もあり、こちらも広く使われている。

さて、そのSqueakだが、アップルが正式にAppStoreに登録してくれれば、iPadシステムをプログラミングによって再定義する力を、ユーザに与えることになる。

もしそうなれば、パーソナルコンピューティングの新しい世界への道を切り開くことになるのは間違いないと思うが、アップルが気づきあげたMPAモデルと相反するため、アップルが積極的にそうしないのも理解できる。

しかし、コンピューティングの新しい世界が訪れれば、また新しいビジネスモデルが出てくるのが歴史の必然であるので、アップルがそれをしなくても、いずれ別の会社がそういう世界を作っていくことになるのだろう。

★WOZ★

スクイークであそぼう【CD-ROM付】 Book スクイークであそぼう【CD-ROM付】

著者:Thoru Yamamoto,阿部 和広
販売元:翔泳社
Amazon.co.jpで詳細を確認する


自由自在Squeakプログラミング Book 自由自在Squeakプログラミング

著者:梅沢 真史
販売元:ソフトリサーチセンター
Amazon.co.jpで詳細を確認する

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

Pythonでファイルやディレクトリのリストを作る

ちらかしてしまったディスクの整理を久しぶりにする時、あるディレクトリより下に、どんなディレクトリやファイルがあるのかを調べたくなる。
そんな時にもPythonを使うと、そんなディレクトリやファイルのリストを簡単に作ることが出来る。
例えば、あるディレクトリより下にある全てのファイルのリストを作るなら、次のようなコードを使えば良い(コード1)。

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os
for root, dirs, files in os.walk('.'):
    for file in files:
        print (os.path.join(root, file))

また、あるディレクトリより下にある全てのディレクトリのリストを作るなら、次のようなコードを使えば良い(コード2)。

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os
for root, dirs, files in os.walk('.'):
    print (root)

以上

//

初出時は、以下のように書いていたが、上のコード2がより適切だ。

以下の方法でも結果は同じだが、冗長だ。

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os
for root, dirs, files in os.walk('.'):
    for file in files:
        print (root)

ただ、このコードを実行すると、同じディレクトリが重複して表示されてしまうため、コードの実効結果を次のように加工すれば良いだろう。

getdirs.py | sort | uniq

ここで、getdirs.pyはコード2だ。
なおコード1とコード2はPython3.xで動作する。

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

テクノロジーの勝利

Preventという静的コード解析ツールがある。

コベルティという会社が販売しているのだが、確か、この春から名前を変えて再デビューしているはずだ。とにかくこの冬はPreventという名前だった。

とにかく、そのPreventに、大昔のCのソースコードを解析させてみた。

そのソースコードは、長年にわたって改造が繰り替えされた結果、誰もきちんと保守できなくなってしまい、原因不明の不具合が頻発しているというソースコードだ。さらに、設計書の更新もしていないため、何が正しい仕様なのか、分からなくなっている。

さて解析だが、Preventの処理が途中で止まってしまう。

ソースコードを調べてみると、"far"、"near"という懐かしいキーワードが見つかった。これではダメだ。

Preventのエラーメッセージを見てみると、ヘッダファイルまわりも、どうやらgccではコンパイルできないらしい。

気を取り直して、"far"と"near"を#defineで消して、コンパイラもVisualC++に変えて再挑戦だ。

今度はうまくいった。

解析もできているようだ。

未初期化変数が多いな。

他にもどんどん不適切な記述が見つかる。

お約束のように、バッファオーバフローが見つかる。

今回の解析で見つかったバグを修正すれば、原因不明の不具合のいくつかは解決されるだろう。

このソースコード、できた当時は十分な静的解析を受けられなかったに違いない。

大昔のソースコードが、最新のテクノロジーで解析されて修正されていく。

まさにテクノロジーの勝利といったところだ。

感慨深い。

★WOZ★

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

ソフトウェアの正しさ

ソフトウェアの正しさには2種類ある。

それは、

  • 正しく作る
  • 正しいものを作る

の2種類だ。

正しく作るというのは、仕様通りにソフトウェアを作るということで、レビューとテストによって、その正しさを保証する。

一方の正しいものを作るというのは、そのソフトウェアの発注者あるいはエンドユーザが求めているものを作るということで、妥当性確認によって、ソフトウェアが正しいものであることを保証する。

前者を疎かにすると、文字通り正しく動かないソフトウェアになってしまうし、後者を疎かにすると、正しく動いてはいるものの、実際には使い物にならないソフトウェアを作ってしまうことになる。

★WOZ★

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

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

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

iPadとダイナブック

ついに米国でiPadが発売された。

なかなか順調な販売状況だそうだ。数週間後に3G通信モジュール内臓タイプも発売されるので、さらに売れることだろう。

ところでこのiPadだが、多くの人が、アラン・ケイが1972年に描いたダイナブックに似ていると感じたようだ。確かに、サイズも機能も似ている。

アラン・ケイはその後、暫定ダイナブックとしてAltoを開発したのだが、ジョブズは1979年にAltoを見たという。

暫定ダイナブックであるAltoを見てから、ジョブズは30年かけてダイナブックを作り上げたのだろうか。

と、ここまでは良いのだが、問題はプログラミング環境だ。

ダイナブックは、プログラミングによりシステムそのものを再定義できる機能をもち、さらに、子供でもプログラミングできることを目指していたはずだ。

現在のiPadにはその要素が抜けている。

そもそもアップルはMPAモデルにより収益を得ようとしているのだから、ユーザが勝手にシステムを書き換えたり、アプリケーションを作ってしまう状態は望んでいないはずだ。

もしかしたら、Smalltalkを乗せてくるのか?

あるいはブラウザで動くWebクライアントの開発環境を乗せてくるのか?

と興味はつきない。

この後、どんなiPad用のプログラミング環境が出てくるのかが楽しみだ。

★WOZ★

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

ソフトウェアの出荷

メーカーがソフトウェアを出荷しようとする時、しばしば問題が起こる。
製品を予定の期日通りに出荷したい製造部門と、出荷に根拠を持たせたいテスト部門と、出荷後の品質問題のリスクをできるだけ下げておきたい品質保証部門の間である種の戦いが勃発するのがそれだ。
製造部門は、品質よりも期日優先で、QCDのDを守ろうとする。
テスト部門と品質保証部門は、期日よりも品質優先でQCDのQを守ろうとする。
しかし、この問題が起こるのは、むしろ健全な状態と見るべきだろう。
それぞれの部門がそれぞれの責任を全うしようとしているのだから。
それより問題なのは、このような問題が起こらず、馴れ合いで製品を出荷してしまう場合だ。
あるいは、馴れ合いとまでは言わなくても、誤った知識や勘違い、傲慢さによって、品質に問題がある製品が出荷されてしまうことはあるだろう。
その中でも誤った知識でよくあるのが、テストに合格した証拠、エビデンスについての認識だ。
よく聞くのが、テスト部門の合格印が、テストに合格したエビデンスである、という主張だ。
しかし、それは間違っている。
テストに合格したエビデンスは、テスト実施の記録を伴うテスト成績書だ。
どのような結果を期待するテストを行い、確かにその通りの結果を得られたという記録がなければ、そのテストを実施したとは言えない。
つまり成績書が存在しなければ、いくら長い時間と多くの人をかけてテストをしても、何もしていないのと同じなのだ。
このことは、CMMIやISO9000の立場からも、とても重要なことなので、実際に仕事をしている担当者だけではなく、それぞれの部門のマネージャにもしっかりと理解しておいてもらいたいものだ。

★WOZ★


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

手軽に情報共有

とある業務の進捗管理用にホワイトボードを使うことにした。

その業務の担当者が数人いて、受付→処理→承認、とフローが進むたぐいのものだ。

最初はWebアプリケーションで管理しようかと思ったのだが、壁に張り出すなどしたほうが、みんなで情報を共有しやすいという声が多かったので、壁にホワイトボードを張り付けてそこに進捗状況を書き出すようにしたのだ。

調達予定のホワイトボードが届くまでの間、行き先表示版の一角を借りて、試して見たところ、思った以上にわかりやすい。

お金をかけず、手軽に、みんなで情報共有するには、よく見えるところに情報を張り出しておくのが良さそうだ。

★WOZ★

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

« 2010年3月 | トップページ | 2010年5月 »