« 2009年12月 | トップページ | 2010年2月 »

2010年1月

Ubuntu9.04にSpinとXspinをインストールする方法

Ubuntu9.04へのSpinとXspinのインストールは、次の手順で行う。

なお、SpinとXspinのソースコードはダウンロードページにある。

1.Spinのインストール

ダウンロードページから、spinのソースコード(spin*.tar.gz)をダウンロードして適当なディレクトリで解凍する。下記はspin524.tar.gzの場合だ。

gunzip spin524.tar.gz

tar -xf spin524.tar

cd Spin/Src5.2.4

make

makeが成功すればSrc5.2.4にspinという名前の実行ファイルができているので、それをパスの通っているディレクトリ(/usr/local/bin等)に置く。

2.Xspinのインストール

xspinはtcl/tkを使うので、もしインストールしていなければ、先にそれらをインストールする。

sudo apt-get install tcl

sudo apt-get install tk

次に、ダウンロードページから、xspinのソースコード(xspin*.tcl)をダウンロードする。下記はxspin523.tclの場合だ。

このファイルは、そのままでは動かないので、3行目を次のように書き換える。

exec wish /usr/local/bin/xspin -- $*

なお、これはxspinのソースコードを/usr/local/binに置く場合だ。

次に書き換えたファイルを/usr/local/binに置き、実行可能にする。

cp xspin523.tcl /usr/local/bin/xspin

chmod +x /usr/local/bin/xspin

これで、GUIでSpinを使えるようになる。

XSpinの使い方は「モデル検査・初級編」がわかりやすい。

Spinの詳細は、Spinのサイトを参照していただきたい。

★WOZ★

モデル検査 初級編―基礎から実践まで4日で学べる Book モデル検査 初級編―基礎から実践まで4日で学べる

著者:産業技術総合研究所システム検証研究センター
販売元:ナノオプトメディア
Amazon.co.jpで詳細を確認する

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

Go言語のインストールの不具合(2010年1月31日)

今日(2010年1月31日)、Ubuntu9.04にGo言語をインストールしようとしたところ、

yerr.h:17: error: ‘loadsys’ undeclared here

というエラーが出てインストールできないことがわかった。

golang-nutsを調べたところ、
1月29日, 午後5:40のRuss Coxさんの記事に、

Instead of ./all.bash try LANG=C ./all.bash.
Sorry for the trouble.  This will be fixed in the
next release.

という記述を発見した。
この通りにやってみてインストールに成功した。

★WOZ★

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

スモークテストの由来

ソフトウェア開発で、ビルドの後、そのビルドが成功していることを確認するために、広く浅く行うテストのことをスモークテストという。

実は「スモークテスト」という言葉は、ソフトウェア工学が始めて使ったものではなく、昔からある言葉だ。

例えば、配管を組み立てたり修理した後、パイプに漏れがないことを確かめたり、電子回路を組み立てた後、始めて動かしたときに回路が焼けて煙がでないことを確かめたりすることを「スモークテスト」と呼ぶ。電子回路の場合はまさに煙が出るので、スモークテストのイメージがよくわかる。

これ以外でも、木管楽器を組み立てたり修理した後で、キーから空気が漏れていないことを確認することも「スモークテスト」というそうだ。

ビルド後に行う開発やテストは、そのビルドが成功していることを前提としている。それを保証するために、スモークテストは必ず行う必要がある。

★WOZ★

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

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

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

スモークテストは自動化に向いているテストだ

ソースコードを更新した後、ビルドが成功していることを確認するスモークテストは、自動化に向いているテストの一つだ。

例えばWindows上の開発なら、UIオートメーションを使うと、GUIのテストまで自動化できるので、テスト工数を大幅に削減できる。

またLinux上の開発では、Dogtailを使うとGUIテストを自動化できる。

スモークテストはビルドの度に繰り返されるので、この工数削減は非常に効果的だと言える。以前見積もった一例をあげると、自動化コードの作成コストは、2回のスモークテストで元がとれるケースがあった。

もちろん、いつまでたっても自動化コードを継続的に追加したり修正したりする必要があれば、それだけ自動化によるコスト削減効果は薄れることになる。どこまでを自動化し、どこからを手作業でテストするのかの判断が重要だ。

★WOZ★

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

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

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

大切なのはツールを使いこなすことだ~静的解析ツールの誤検知

ソースコードの静的解析は、ソフトウェアを動かすことなく字面から、バグの可能性を見つけるために行う。静的解析ツールとしては、QAC、QAC++が有名だが、最近はPreventもよく使われるようになっている。

しかし、いずれのツールを使うにせよ、バグの誤検知や過剰検知が起こりうる。静的解析ツールを使う上で気をつけなくてはいけないのは、それら誤検知や過剰検知を精査することを忘れてはならないということだ。

実際に、ある開発チームでは、QAC++の検知結果をすべて真に受けて、本来修正しなくても良いところまで修正することに決めたため、その修正作業に多くの時間を使ってしまった。そして、その無駄を残業や休日出勤で補うことになった。さらに悪いことに、本来触らなくてもよい部分まで修正した際に、新たなバグを埋め込む危険まであったのだ。

実はそのチームには、QAC++の検知結果を精査する目利きがいなかったために、そのようなことになったのだが、この話から得られる教訓は、どんなツールを使うにせよ、ツールに使われるのではなくツールを使いこなすことが重要だということだ。

★WOZ★

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

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

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

定量的品質マネジメント

「定量的な品質予測」というと難しそうだが、考え方自体は難しいものではない。

基本は次のようなものだ。

  • 開発プロジェクトの[状態]を表す[変数]を決める
  • その変数の[上限]と[下限]をきめる
  • その変数の値を定期的に[測定]する
  • その変数の値が上限または下限を越えそうかどうかを判断する
  • 越えそうなら、 開発プロジェクトで何が起こっているかを調査する
  • 変数の値を上限と下限の間に戻すための施策を決める
  • その施策を実行する
  • 変数の値が期待する動きをしていることを確認する

難しいのは上記の確固で囲った部分、つまり「状態」「変数」「上限」「下限」「測定」だ。

  • 開発プロジェクトの何の状態を調べたいのか?
  • その状態は何(どの変数)に現れるのか?
  • その変数の異常値は何か?
  • 開発メンバーに測定する余裕があるのか?

例えば、ある設計書について、レビュープロセスが適切に行われている(これが状態だ)ことを確認したいのであれば、レビュー時間(変数1、レビュー会議の時間×参加人数)と検出誤り密度(変数2、設計書1頁あたりの検出誤り数)を測定する。変数の上限と下限は、あらかじめ見積もっておく。例えば、

  • レビュー会議は1時間~3時間で3人~5人の有識者にレビューしてもらおう
  • 60頁の設計書なら、1頁あたり3つ~7つの誤りを見つけたい

というように見積もる。
見積りについては、最初から完璧を目指すのではなく、文献や経験を参考にして、とりあえず始めてみることが大切だ。
やっているうちにデータと知識と経験が蓄積されていき、自分なりの見積り手法を確立できる。

★WOZ★

定量的品質予測のススメ―ITシステム開発における品質予測の実践的アプローチ (SEC BOOKS) Book 定量的品質予測のススメ―ITシステム開発における品質予測の実践的アプローチ (SEC BOOKS)

販売元:オーム社
Amazon.co.jpで詳細を確認する

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

スモークテストは必ず実施しよう

ソフトウェアのソースコードを追加、削除、修正してビルドしたときに、これまで動いていたソフトウェアが動かなくなってしまうことがある。しかも、ソフトウェアの規模が大きくなればなるほど、そういうことは起こりがちだ。

ビルドして動かなくなってしまったら、その後に続く実装、テスト、バグ調査が実質的にできなくなってしまう。

そんな事態に陥るのを避けるために、ビルド後すぐにソフトウェアが動くことを確認するテストを行う。このテストをスモークテストという。

スモークテストではビルドが成功していることを確認できれば良いので、広く浅いテストでよいが、ビルドしたときには毎回、全テストをする必要がある。

スモークテストにより、ビルドの失敗を早期に発見できれば、開発者が、正しく動いていないソフトウェアを使って、実装、テスト、バグ調査をする無駄を排除することができる。

★WOZ★

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

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

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

Subversionで文書管理を確実にしよう

ファイル名やディレクトリ名を日付入りにして、バージョン管理をしている人は多いだろう。例えば、

file20100123.doc

とか、

dir20100123

という具合だ。

同じ日にバージョンが上がる場合は、

file20100123-1

とか、

file20100123a

といった名前になる。

こういう管理方法は、一見わかりやすいように思えるので、多くの人や組織がこの方法を使っている。

しかし、この方法では、ファイルやディレクトリが増えてくるとあっという間に混乱してしまう。最新だと思って人に渡したソースコードが実は古いものだったり、正しいと思ってコーディングのインプットにした設計書が、実はバグ修正前の正しくないものだったりすることが起こりがちなのだ。

しかも、こんな方法でファイルを管理していると、ISO9001の監査で不適合になる可能性が高い。

つまり、

  • 文書の変更の識別及び現在の改訂版の識別を確実にする
  • 該当する文書の適切な版が、必要なときに、必要なところで使用可能な状態にあることを確実にする
  • 廃止文書が誤って使用されないようにする。また、これらを何らかの目的で保持する場合には、適切な識別をする

という要求を満たせない可能性が高いのだ。

こんな間違いや不適合の可能性に心当たりがあるなら、バージョン管理システムを使うことを検討してみてはいかがだろうか。

2010年現在、広く使われているバージョン管理システムはSubversionだ。

もちろん、これさえ使えば完璧というものではないが、バージョン管理にまつわる失敗の多くをなくすことができるのは間違いない。

★WOZ★

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

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

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

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

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

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

★WOZ★

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

Subversionのログを使って開発チームの状況を調べよう

Subversionのログ解析ツールStatSVNを使えば、

  • 開発者ごとのコミットのタイミング
  • リポジトリに含まれるソースコードや文書の量や変化

などを知ることができる。

このようなデータを解析することで、

  • 最近チームメンバが深夜まで働いている
  • そろそろテストも終盤だというのに、ソースコードが急に増えた

といった開発プロジェクトの危険な兆候を見える化することができる。

しかし、StatSVNでログ解析するには、調べたいリポジトリをチェックアウトしなければならない。開発マネージャにしてみれば、いちいちチェックアウトするのは面倒だろうし、リポジトリのサイズが大きければ余計な時間もかかってしまう。

また、普段から開発の実務に慣れていない開発マネージャなら、うっかりとリポジトリを壊してしまうかもしれない。そんなリスクは避けたい。

実は、リポジトリをチェックアウトしなくても、次のように、ある程度まで開発の状況を調べることができる。

コミットログを調べたいなら次のコマンドを実行する。

$ svn log リポジトリのURL -v --xml > log.xml

これで、誰が、何時、何をコミットしたのかというコミット履歴を取得できる。

また、リポジトリに含まれるファイル一覧を調べたいなら次のコマンドを実行する。

$ svn list リポジトリのURL  -R --xml > list.xml

これらを調べるだけでも、何時ぐらいまで開発メンバが働いているかとか、成果物の出来具合はどうかなど、開発の状況を知ることができる。

また、上記のように出力ファイル形式をxmlにしておけば、その後の加工も用意なので、StatSVNのようなツールを自分で作って、好きなように解析することもできる。

★WOZ★

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

プログラミングのパラダイム

プログラミング・パラダイムとは、ソフトウェアを作るときの基本的な考え方を、プログラマに与えるものだ。次のように考えるとわかりやすい。

今、一人の新卒エンジニアがいるとする。彼は会社の新入社員向けのプログラミング講座で、始めてプログラミングとC言語を学んだ。
その彼に、Pythonの入門書と次のような問題を与えてみる。

問題「0から9までの整数のうち、偶数だけをコンソールに出力するプログラムを作りなさい」

彼はたぶん、こんなコードを書くだろう。

for i in range(10):
    if i % 2 == 0:
        print i
    else:
        pass

このコードはもちろん、次のC言語のコードからの類推だ。

#include <stdio.h>

int
main()
{
        int i;
        for(i = 0; i < 10; i++) {
                if (i % 2 ==0) {
                        printf("%d\n", i);
                }
        }

        return (0);
}

彼はC言語で手続き型の考え方しか学んでいないのだから、当然だろう。
ここで彼に、さっきの問題は素直に手順として見るだけでなく、例えば次のような見方もできるだろうと伝えてみる。

問題「0から9までの整数のうち、偶数だけをコンソールに出力するプログラムを作りなさい」
 ↓
・0から9までのリストをつくる
・そこから偶数だけ抜き出して別のリストをつくる
・その偶数だけのリストをコンソールに出力する

この見方を理解できれば、その新卒エンジニアはPythonの入門書を読みつつ、次のようなコードにたどり着くだろう。

a = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

b = [x for x in a if x%2==0]

for x in b:
        print x

両方のプログラムとも、結果は同じなのだが、過程が異なる。一方は問題を一連の手続きとして見ているのに対し、もう一方は問題をさらに小さな問題の連続として見ている。前者が手続き型のプログラミング・パラダイムで後者が関数型のプログラミング・パラダイムだ。

このように、パラダイムは、ある問題をみたときの捉え方、つまりその問題を解決するソフトウェアを作る時の基本的な考え方を、プログラマに与えるものだ。
いろいろな問題を臨機応変に上手く解決していくには、いろいろなパラタイムを知っていることが重要だと言える。

★WOZ★



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

モデリングの勉強方法

モデリングはどうやって勉強するのかを尋ねられることがある。

2010年の時点で一般的なモデリング言語はUMLなので、UMLの基礎知識はもちろん必要だ。テキストやネットで勉強しよう。

そして、要求分析や設計の機会があれば、勉強した知識を実際に使ってみよう。良いトレーニングになる。

さらに、難しいと思われることを、理解、分解、再構築する練習をしよう。対象はソフトウェア分野でも良いし、異分野でも良い。

僕がここ数年、面白いと思って調べている分野は経済学だ。経済学というと文系だと思っていたが、意外に理系の学問だと感じた。例えば、「にっき」で紹介した、竹森教授の金融危機の分析本は、前回1997年の金融危機を「ナイトの不確実性」を使って分析し、解説している。理路整然と書かれているので、モデリングの練習には最適だと思う。

★WOZ★

1997年――世界を変えた金融危機 (朝日新書 74) Book 1997年――世界を変えた金融危機 (朝日新書 74)

著者:竹森 俊平
販売元:朝日新聞社
Amazon.co.jpで詳細を確認する

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

Go言語のforループ

Go言語のforループには次の3つの形式がある。

// Like a C for
for init; condition; post {}

// Like a C while
for condition {}

// Like a C for(;;)
for {}

一つ目の形式のサンプルだ。
この形式はC言語プログラマも馴染みやすい。
//
package main

func main() {
        sum := 0;
        for i := 0; i < 10; i++ {
                sum += i
        }
        println(sum)
}
//

二つ目の形式のサンプルだ。
forがwhileだと思えば、問題なし。
//
package main

func main() {
        sum := 0
        i := 0
        for i < 10 {
                sum += i
                i++
        }
        println(sum)
}
//

三つ目の形式のサンプルだ。
これはCプログラマには違和感があるだろう。
//
package main

func main() {
        sum := 0;
        a := [...]int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}

        for _, i := range a {
                sum += i
        }
        println(sum)
}
//
しかし、この3つ目の形式もリスト処理になれているPythonプログラマなら問題なしだ。
//
#!/usr/bin/env python
# -*- coding: utf-8 -*-

a = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

sum = 0
for i in a:
        sum += i

print sum
//

Go言語は、C言語の良いところとPython言語の良いところをうまく持ち合わせていると思う。

★WOZ★

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

ソフトウェアエンジニアのためのHDL入門

そう遠くない未来、ハードウェアが単にソフトウェアを動かすための一つの部品になる時代が来るだろう。そして、そんな時代では、ソフトウェアエンジニアがハードウェアも設計しているに違いない。

「HDLによる高性能ディジタル回路設計」は、そんな時代の到来を予感させる一冊だ。

この本は、デジタル回路設計をソフトウェアからトップダウンに説明しており、ソフトウェアと同じようにハードウェアを考えてしまうと失敗するポイントをうまく説明している。ソフトウェアとハードウェアの違いを意識することができる。

この本は、以前紹介したe-Learning教材「CQ Endeavor VHDL」で、デジタル回路設計の基礎を学んだ後に読むのがおすすめだ。

★WOZ★

HDLによる高性能ディジタル回路設計―ソフトウェア感覚を離れてハードウェアを意識する (Design Wave BOOKS) Book HDLによる高性能ディジタル回路設計―ソフトウェア感覚を離れてハードウェアを意識する (Design Wave BOOKS)

著者:森岡 澄夫
販売元:CQ出版
Amazon.co.jpで詳細を確認する

HDL独習ソフトで学ぶCQ Endeavor VHDL Book HDL独習ソフトで学ぶCQ Endeavor VHDL

著者:小林 優,hdLab開発グループ
販売元:CQ出版
Amazon.co.jpで詳細を確認する

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

Go言語の関数リテラル(function literals)

関数リテラル(function literals)は匿名関数のことで、Go言語では例えば次のように使う。

f := func(x, y int) int { return x+y }

関数リテラルはgo文と一緒に使うと便利だ。

★WOZ★
//
package main

func main() {

        c := make(chan int)
        var g int
        go func(i int, c chan int) {
                s := 0
                for j := 0; j < i; j++ { s += j }
                g = s

                c <- 1
        } (10, c)

        <- c
        println(g)
}
//
(Go for C++ Programmersより)

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

ソフトウェア開発は気合や根性でやり遂げるものではない

どう考えても実現不可能なソフトウェア開発計画を前にして、

  • がんばります
  • どんなことがあってもやりとげます
  • 残業と休日出勤で遅れを取り戻します

と宣言する健気な人がいる。

さらに困ったことに、そういう浪花節を美徳と評価する上司も多いようだ。

しかし、間違わないで欲しいのは、ソフトウェア開発は頑張ってできるものではない、ということだ。

ソフトウェアは、あくまでも理詰めで論理的につくるものだ。

完成までの論理的な計画が立てられれば、とくに頑張る必要はない。

そして、論理的に考えてできないものは、それはやはりできないのだ。

ソフトウェア開発を気合や根性でやり遂げるものだと考えている人には、とりあえず、下の二冊の本を読むことから始めてほしい。論理的な計画立案と、そのための見積り方法について書かれている。

★WOZ★

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか? Book クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

著者:エリヤフ ゴールドラット,三本木 亮
販売元:ダイヤモンド社
Amazon.co.jpで詳細を確認する

ソフトウェア見積り―人月の暗黙知を解き明かす Book ソフトウェア見積り―人月の暗黙知を解き明かす

著者:久手堅 憲之,スティーブ マコネル
販売元:日経BPソフトプレス
Amazon.co.jpで詳細を確認する

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

捨てるプロトタイプと育てるプロトタイプ(2)

1月4日に捨てるプロトタイプと育てるプロトタイプの話を書いたが、Promelaで書いてSPINで動かすソフトウェアは典型的な「捨てるプロトタイプ」だ。

Promelaで書くソフトウェアは、UMLモデルや設計書、あるいは実装済みのソースコードにある、論理的に確認したい要素を取り出して抽象化したプロトタイプだ。

モデルや設計が論理的に正しいことを確認したり、実装済みのソースコードにあるバグを見つけた後は、捨ててしまう。

ただし、ここでいう「捨てる」というのは、製品には組み入れないという意味だ。Promelaで書いたプロトタイプは、モデル検証のエビデンスとして構成管理する。

モデル検証のエビデンスを構成管理するというのは、テストデータやテストコードを構成管理するというのと同じだ。

★WOZ★

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

Go言語で並行処理の待ち合わせを書いてみた

Go言語のgoroutineとchannelを使うと、並行処理の待ち合わせを簡単に書ける。

10個の並行処理を生成して、それらが全て終わったのを待って、10個の平行処理の結果を使って何かの処理をする、という場合だと次のように書けば良い。

  1. 並行処理の呼び出し側で、待ち合わせ用のバッファなしチャンネルを一つ作って、そのチャンネルを並行処理を起動するときに渡す。
  2. それぞれの並行処理処理は、自分の計算が終わったら、そのチャンネルに完了通知を送る。
  3. 並行処理の呼び出し側では、全ての並行処理から完了通知を受け取ったら、次の処理に移る。

★WOZ★

//コードここから
package main

const NumberOfProc = 10

func myfunc(i int, c chan int) {
        println(i)
        c <- 1
}

func main() {
        c := make(chan int)

        for i := 0; i < NumberOfProc; i++ {
                go myfunc(i, c)
        }

        for i := 0; i < NumberOfProc; i++ {
                <-c
        }
        println("all done")
}      
//ここまで

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

ライフハックと5S

「5S(ごえす)」という言葉がある。

ローマ字で書いたときに、アルファベットの'S'から始まる5つの言葉のことで、製造業やサービス業の職場環境の維持改善で用いられるスローガンだ。

【5S】

  • 整理(せいり、Seiri) - いらないものを捨てること
  • 整頓(せいとん、Seiton) - 決められた物を決められた場所に置き、いつでも取り出せる状態にしておくこと
  • 清掃(せいそう、Seisou) - 常に掃除をして、職場を清潔に保つこと
  • 清潔(せいけつ、Seiketsu) - 上の3S(整理、整頓、清掃)を維持すること
  • 躾(しつけ、Shitsuke) - 決められたルール・手順を正しく守る習慣をつけること

(Wikipediaから引用)

これらは、ソフトウェアエンジニアとはあまり関係なさそうに思えるが、そうでもない。

整理と整頓は構成管理の話だし、ファイルシステムやデスクトップはいつも綺麗にしておきたい(清掃)。躾は標準プロセスを守りましょう、ということだ。

ソフトウェアエンジニアのためのライフハックと言うこともできるだろう。

しかし、会社の生産管理部の人などが、ソフトウェアエンジニアのところにいって、5Sに関して何を言うかといえば、やれ机の上が汚いだの、机の下に荷物がおいてあるだの、ひきだしの中が整理されていないだのと、ソフトウェア開発とはまったく違う観点で文句をいうから、ソフトウェアエンジニアは面倒くさくなってしまって、5Sのイメージが悪くなる。5Sを推進する立場の人たちには、もう少し本質的な観点をもって、よく考えて、ものを言ってほしいものだ。

とはいえ、上で書いたように、5S自体はソフトウェア開発を楽にするための、ライフハックのヒントになる良いアイデアだ。

簡単なことなので、ツールをうまく使いながら、ソフトウェア開発生活にとりいれていこう。

★WOZ★

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

ソフトウェア開発を見積もってみよう

ソフトウェア開発プロジェクトを始めるにあたり、費用や規模や工数を、最初に正しく見積もるにはどうすれば良いのかという相談を受けることがある。

相談をする人は、最初から正しく見積もる手法があるという前提で、その答えを求めているのだが、実際には最初から正確に見積もることはできない。不確定要素が多いのだ。

それでも開発を始める前に、大雑把に見積もることはできる。そして、少し開発をやってみて、見積りに必要な情報が集まってきたら、その時点で再度見積もる。

そしてまた、少し開発を進めてみて、さらに情報が集まってきた時点で、もう一度見積りを見直す。

これを繰り返していくうちに、見積り精度はどんどん上がってくるものだ。

スティーブ・マコネルの「ソフトウェア見積り」は、こういう見積りの実践的なやり方をわかりやすく説明している一冊だ。

邦訳が出ているが、できれば原書で読むことをおすすめする。

★WOZ★

ソフトウェア見積り―人月の暗黙知を解き明かす Book ソフトウェア見積り―人月の暗黙知を解き明かす

著者:久手堅 憲之,スティーブ マコネル
販売元:日経BPソフトプレス
Amazon.co.jpで詳細を確認する

Software Estimation: Demystifying the Black Art (Best Practices (Microsoft)) Book Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))

著者:Steve McConnell
販売元:Microsoft Press
Amazon.co.jpで詳細を確認する

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

Subversionのログ解析ツール〜StatSVN

構成管理ツールにSubversionを使っている人は多いだろう。

そのSubversionのログ解析ツールがStatSVNだ。

StatSVNを使えば、

  • 開発者ごとのコミット履歴
  • リポジトリに含まれるソースコードや設計文書の量とその変化

などを知ることができる。

開発マネージャは、このようなデータを解析することで、

  • 設計文書やソースコードが計画通りに出来ていない
  • 最近、チームメンバが深夜まで働くようになった
  • そろそろテストも終盤だというのに、ソースコードが急に増えた

といった開発プロジェクトの危険な兆候を見える化することができる。

★WOZ★

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

要求分析ではモデリングが重要だ

ソフトウェア開発では、要求分析フェーズから実装までの間に、これから作ろうとするものの構造と振る舞いを整理する。この整理する作業がモデリングであり、その成果物がモデルだ。

モデルは、モデリングの過程で、構造(静的モデル)と振る舞い(動的モデル)の間を行ったり来たりしながら具体化されていくとともに、顧客や開発チームのレビューを受けて洗練されていく。それが最終的にはソースコードになる。

要求分析にモデリングを使う文化は、日本ではまだそれほど普及していないが、早い段階で要求を整理して仕様化するために、モデリングはかなり有効な手法だ。

★WOZ★

ユースケース入門―ユーザマニュアルからプログラムを作る (Object Technology Series) Book ユースケース入門―ユーザマニュアルからプログラムを作る (Object Technology Series)

著者:ダグ ローゼンバーグ,ケンドール スコット
販売元:ピアソンエデュケーション
Amazon.co.jpで詳細を確認する

ユースケース入門 ユースケース入門

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

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

マインドマップでアイデアを整理しよう

最近はアイデアを整理するのに、よくマインドマップを使う。マインドマップは知識やアイデアを図示する手法だ。

会議の議事録をとるのにマインドマップを使ったり、オブジェクト指向分析にマインドマップを使うこともある。

ホワイトボードにマインドマップを描いていくと、ただ箇条書きにするより、会議や分析の進行がスムーズになり、成果が出やすいと感じることが多い。
 

簡単にマインドマップを描くことができる フリーソフトウェアもあり、人気だ。

★WOZ★

「できる社員」の最強メソッド マインドマップ(R)ビジネス超発想術 (アスキームック) Book 「できる社員」の最強メソッド マインドマップ(R)ビジネス超発想術 (アスキームック)

著者:遠竹智寿子、月刊アスキー編集部
販売元:アスキー
Amazon.co.jpで詳細を確認する

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

Redmineで開発管理しよう!(3)

2010年1月1日に、Redmine.JPのサイトに”Redmine.JP Blog”ができた。
「Redmineをより活用するためのtipsなどをお届けするブログサイト」だ。

Redmineを使ったチケット駆動開発が一般化すれば、プロジェクト崩れになるリスクも小さくなると思う。

★WOZ★

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

Go言語の最新リリース(2009年12月22日版)を使ってみた

2009年12月22日にGo言語の新しいリリースが公開されていた。
Go言語は構成管理ツールにMarcurialを使っているので、次のコマンドでGoogleのリポジトリと同期できる。

$ hg pull
$ hg update release

今回のリリースではセミコロンを省略できるケースが大幅に増えているようだ。
例えば以前のバージョンの場合、文と文の間はセミコロンで区切る必要があった。

//以前のバージョン
package main

import "fmt"

func main() {
        fmt.Printf("hello world\n");
        fmt.Printf("こんにちは\n")
}
//ここまで

12月22日のバージョンでは、次のようにセミコロンを省略できる。

//新しいバージョン
package main

import "fmt"

func main() {
        fmt.Printf("hello world\n")  //ここのセミコロンが不要
        fmt.Printf("こんにちは\n")
}
//ここまで

この改良はうれしい。
見た目もすっきりするし、セミコロンのつけ忘れでコンパイルエラーになることもなくなるので、思考を中断することなくコーディングできそうだ。

★WOZ★

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

UMLモデリング

動くソフトウェア至上主義」では、ソースコードがあれば詳細設計書なんていらない、と書いた。

しかし、これはソースコードをいきなり書き始めようと言っているわけではない。

ソースコードを書き始める前にモデリングをしよう。

要求分析フェーズから実装までの間に、これから作ろうとするものの構造と振る舞いを整理する。作りたいソフトウェアに関連するアイデアを、理解・分解・再構築する過程、それがモデリングだ。

モデルは、顧客や開発チームに説明して、レビューを受けて、さらに理解・分解・再構築を繰り返しながら、どんどん洗練されていく。それが最終的にはソースコードになる。

モデリングで使う言語としてはUMLが一般的だが、書き方は厳密でなくてもかまわない。アイデアを気軽にスケッチしてみよう。

★WOZ★

UML モデリングのエッセンス 第3版 (Object Oriented SELECTION) Book UML モデリングのエッセンス 第3版 (Object Oriented SELECTION)

著者:マーチン・ファウラー
販売元:翔泳社
Amazon.co.jpで詳細を確認する

UMLモデリングのエッセンス第3版 UMLモデリングのエッセンス第3版

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

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

捨てるプロトタイプと育てるプロトタイプ

リスク管理に敏感なソフトウェア開発チームでは、開発プロジェクトの早い段階でプロトタイプを作って、開発チーム内の認識合わせをしたり、顧客に対して妥当性確認をしたりする。

しかし、ここで一つ問題が発生することがある。

それは、せっかく作ったのだからと、そのプロトタイプを製品に流用させようとする上司が現れることだ。

そもそもプロトタイプは速く作ることが重要であり、内部の構造やエラー処理は二の次だ。それが何であるかがわかり、動けば良い。

ここのところを理解せずに、製品に流用しようとすると、必ずとっていいほど失敗する。このため、上のような上司が現れたら、無理に指示に従おうとせず、プロトタイプ作成の意図をきちんと説明して理解を求めよう。そして製品を作る時には、プロトタイプを思い切って捨てよう。

一方で、育てるプロトタイプというものもある。スパイラル開発では、最初は小さなソフトウェアから徐々に大きなソフトウェアに成長させていく。その最初のコアになる部分は「育てる」プロトタイプだ。

フレームワークやツールキットが充実しているWebアプリケーションではプロトタイプを育てやすいと思う。

★WOZ★

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

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

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

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

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

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

★WOZ★

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

Linuxでのカバレッジテスト

LinuxでC/C++を使ってソフトウェアを作る場合、カバレッジテストにはgcovを使うと良い。カバレッジテスト用の製品としてはIBMのPureCoverageが有名だが、一本20万円以上するので、気軽に使ってみるというわけにもいかないだろう。

その点、gcovならLinuxに標準で入っているし、使い方も簡単なので導入も用意だ。

例えば、test.cというファイルに書かれたCのプログラムについて、カバレッジテストを行う場合、次のようにしてC0とC1のカバレッジを算出することができる。

$ gcc --coverage test.c

$ ./a.out

$ gcov -b test.c

テスト結果は、test.c.gcovという名前のファイルに出力されるので、次のようにして確認できる。

$ less test.c.gcov

★WOZ★

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

画像編集ソフトウェアGIMPでミニチュア写真を作ってみた

世間では風景写真をミニチュアのように撮影するのが流行っており、専用の撮影モードを備えたデジカメまであるという。

調べたところ、ぼかし、コントラスト、彩度を調整すれば普通の写真をミニチュア写真のように加工できるというので、実際にソフトウェアでどこまでできるのかを試してみた。下の2枚がその写真だ。

今回、ミニチュア写真を作るのに使ったのはGIMPというソフトウェアだ。

GIMPは高機能な画像編集ソフトウェアだが、フリーソフトウェアなので無料で使える。海外のソフトウェアだが、日本語の情報サイトも多い。

Wikipediaにも紹介文がある。

また、こことかここで使い方を説明している。

僕が使っているUbuntu9.04や9.10には標準でインストールされているが、Windows用もあるので、画像編集に興味のある方は是非使ってみてほしい。

★WOZ★

P1000335mini320x240

P1000153320x240

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

動くソフトウェア至上主義

モデリングを十分に行い、開発チーム内で基本設計を共有できたら、詳細設計フェーズをとばして、コーディングを開始する。少人数の開発チームなら、 こんな開発プロセスでも良いと思う。

なにしろ、ソースコードは最も正確な詳細設計書なのだから、それをわざわざ不正確であいまいな表現になりがちな自然言語を使って、詳細設計書として書き直す必要はないだろう。

詳細設計書が必要な理由としてよく聞くのが、

  • みんながソースコードを読めるわけではないので詳細設計書が必要
  • ソースコードが汚いので詳細設計書が必要

というものがあるが、いずれも的外れだ。

ソースコードが読めないということは一般生活では言葉が喋れないのと同じだし、汚くて読めないようなソースコードはレビュー不足だ。いずれも詳細設計書が必要な理由にはならない。

それに、いくら立派な詳細設計書をつくっても、動くソフトウェアがなければ何の意味もない。ソフトウェアは動いてなんぼだ。詳細設計書の作成に時間を使うのなら、ソフトウェアを動かすために使いたい。

そして、ここが重要なのだが、ソフトウェア開発では、動くソフトウェアをいかに早く作るかが最も大切だ。そのためには、不要なものは思い切って省略することも必要だ。

★WOZ★

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

テスト駆動開発

実際に導入してみて成功した開発手法に「テスト駆動開発」がある。

テスト駆動開発は、次の1〜4を繰り返すことでソフトウェアを作っていく開発手法だ。

  1. 最初に、ユニット(関数やメソッド)が正しく実装されていることを検証するテストコードを先に書く(テストファースト)
  2. 次に、そのテストを失敗させるようにユニットを実装する(実際は有効なコードは何も書かない。例えば、return (false)等を書く)
  3. その後、仕様を満たすようにユニットを実装してテストを成功させる
  4. 最後にそのユニットのコードを整理して完成させる(リファクタリング)

この手法はソフトウェアが満足すべき仕様をテストという形で定義できるので、設計の検証を早く行えるというメリットがある。

また、3の段階でとりあえず動くソフトウェアが手に入るので、結合テストを早く始められるというメリットがある。

さらに、1で書いたテストコードはスモークテストにも使えるので、ユニットの修正による新たなバグの埋め込みを早期に見つけることができる。

このテスト駆動開発を支援するツールは、プログラミング言語ごとに用意されている。

  • C++にはCppUnit
  • C#にはNUnit
  • PythonにはPyUnit
  • JavaにはJUnit

という具合だ。

★WOZ★

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

軽快で多機能なUMLモデリングツール〜Enterprise Architect(2)

僕が、ソフトウェア開発に使うUMLモデリングツールに「Enterprise Architect」を採用した理由の一つは、そのリバースエンジニアリング機能だ。

Enterprise Architect のリバースエンジニアリング機能は優れもので、ソースコードからクラス図を自動生成できるのはもちろん、ソフトウェアの動きを記録して、シーケンス図を自動生成することもできる。

このシーケンス図の自動生成機能は、ソフトウェアの動きが設計通りかどうかを、プログラマと設計者が検証するのに効果的だ。

また、リバースエンジニアリング機能で生成したクラス図やシーケンス図を設計書に反映させることにより、設計書の作成コストを大幅に削減できるとともに、設計書とソースコードの同期という難しい課題を解決することもできる。

そのシーケンス図の自動生成機能を含む、Enterprise Architectの諸機能については、販売元のスパークシステムズのサイトに動画デモがあるので、購入前に確認することができる。

★WOZ★

UMLモデリングツール Enterprise Architect 入門 Book UMLモデリングツール Enterprise Architect 入門

著者:河野岳史/杉本美弥子
販売元:パレード
Amazon.co.jpで詳細を確認する

UMLモデリングツールEnterprise Architect入門 UMLモデリングツールEnterprise Architect入門

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

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

UIオートメーションによるWindowsアプリケーションの自動テスト

WindowsのGUIアプリケーションのテストは、UIオートメーションにより自動化できる。

UIオートメーションは、Windows Presentation Foundation (WPF) をサポートするすべてのオペレーティングシステムで利用可能な、Microsoft Windows の新しいアクセシビリティフレームワークだ。

自動テストを実行する側のプログラムは、UIオートメーションの動作原理がわかってしまえば簡単に作ることができる。まずは、UIオートメーションの概要を簡潔に説明していて、サンプルプログラムがわかりやすい@itの記事を読むのが良いだろう。またUIオートメーションの詳細はMSDNに記載されている。

実際の開発に適用したところ、手作業でテストにするのに比べて大幅にテスト時間とコストを削減することができた。

注意すべきことは、マイクロソフトにより、テスト可能なGUI部品が順次追加されているものの、自動テストに対応していない部品があるということだ。

もし、ある部品が自動テストに対応していないなら、対応している部品で置き換えられれば一番良い。しかし、顧客の要求その他の理由で、そうできない場合もあるだろう。自動化できない部品が関係するテストは手作業ですることになるが、その場合でも自動化の恩恵は得られるだろう。

しかし、最初から自動テストに対応している部品を把握しておき、それらの部品だけを使ってGUIを構成することを目標にして、顧客との間で要求仕様をまとめていくのが最善だと思う。

★WOZ★

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

SPINを使うモデル検査(3)

「SPINモデル検査」の第10章「デザイン検証の実際を知る」には、EJB1.1仕様書を、PromelaとLTL式で形式化してSPINで検査する「デザイン検査」の事例が書かれている。
その「10.3 まとめ」で、「形式化の作業で得られた振る舞い仕様は、繰り返し修正を行いながら振る舞い解析から得た知見をもとに洗練した記述である」と言っており、「SPINモデル検査ツールを軽量デザインカリキュレータとして用いることで形式記述を洗練する繰り返し過程の支援が可能になった」と言っている。
この部分が、設計ツールとしてのSPINの性格をうまく表現していると思う。

★WOZ★

SPINモデル検査―検証モデリング技法 Book SPINモデル検査―検証モデリング技法

著者:中島 震
販売元:近代科学社
Amazon.co.jpで詳細を確認する

SPINモデル検査 SPINモデル検査

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

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

HDL入門者におすすめのe-Learning教材

去年、VHDLについて調べてみようと思い立ったときに買ってきたのが、このe-Learning教材だ。

一日に1時間30分勉強して、一週間程度でやり終える分量だ。

  • レッスンを受けながらメモをとるためのワークブックがついている
  • 実際に手を動かしてプログラミングするようにカリキュラムが組まれている

というところが気に入ったし、勉強が続けやすかった。

始めたときはVHDLは初心者だったのだが、全レッスンを終えたときには、明日からFPGAの設計を始めれる程度の知識は身についていたと思う。

デジタル回路専攻の学生さんにも、新卒エンジニアにも安心してすすめることができる一冊だ。

なお、この本にはVerilogHDL用の姉妹品もあるので、好きな方を選べる。

★WOZ★

アマゾンなら、

HDL独習ソフトで学ぶCQ Endeavor VHDL Book HDL独習ソフトで学ぶCQ Endeavor VHDL

著者:小林 優,hdLab開発グループ
販売元:CQ出版
Amazon.co.jpで詳細を確認する


HDL独習ソフトで学ぶCQ Endeavor Verilog Book HDL独習ソフトで学ぶCQ Endeavor Verilog

著者:小林 優,hdLab開発グループ
販売元:CQ出版
Amazon.co.jpで詳細を確認する

楽天市場なら、

HDL独習ソフトで学ぶCQ Endeavor VHDL HDL独習ソフトで学ぶCQ Endeavor VHDL

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



HDL独習ソフトで学ぶCQ Endeavor Verilog HDL HDL独習ソフトで学ぶCQ Endeavor Verilog HDL

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

| | コメント (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)

プロトタイプで早期に妥当性確認をしよう

ソフトウェアの妥当性確認は、CMMIではValidationと呼ばれるプロセスだ。

さて、その妥当性確認だが、ソフトウェアテストの最終段階であるシステムテストでだけ行えば良いと考えている人が多い。

しかし、これは誤りだ。

妥当性確認は、ソフトウェア開発の初期段階、つまり要求分析フェーズから行っておくべきことだ。

例えば、ユーザインタフェースのデザインや、性能、ハードウェア的な制約、保守性、あるいは基本設計の妥当性などを、プロトタイプを作って確認する。

開発プロジェクトの早い時期から、プロトタイプによる妥当性確認を行って、顧客と開発チームとの認識を同じにしておくことが、開発プロジェクト成功の鍵となる。

★WOZ★

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

SPINを使うモデル検査(2)

SPINの使い方には次の2種類がある。

  • デザイン段階でソフトウェアの振る舞いを確認しておきたい場合の使い方
  • ソフトウェアの不具合の原因を調べたい場合の使い方

前者は"a correctness by construction"または"model-based design"と呼ばれる。後者は"a posteriori verification"と呼ばれる。

つまり、SPINによるモデル検査は、検証(設計時のレビューと実装後のテスト)を強力にサポートする検証手法だ。

★WOZ★

SPINモデル検査―検証モデリング技法 Book SPINモデル検査―検証モデリング技法

著者:中島 震
販売元:近代科学社
Amazon.co.jpで詳細を確認する

SPINモデル検査 SPINモデル検査

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

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

謹賀新年

あけましておめでとうございます。
本年もよろしくお願いいたします。

def SayNewYearGreeting():
    print "Happy new year !!"

SayNewYearGreeting()

★WOZ★

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

« 2009年12月 | トップページ | 2010年2月 »