2015年1月20日 (火)

第12回クリティカルソフトウェアワークショップ GSNやIV&Vケースなど

今日は「第12回クリティカルソフトウェアワークショップ (12thWOCS2)」へ。ソフトウェアシステムでの信頼性・安全性の確保に関するもの。3日間のうちの1日のみ参加。

http://www.ipa.go.jp/sec/events/20150120.html


・アシュアランスケース入門

アシュアランスケースは、テスト結果や検証結果を利用者に保証したり確信させるためのドキュメント。具体的には、GSN(D-Case)という表記があるが、説明は主としてそれで行われた。その前段として、トゥールミンの三角ロジックが紹介された。自分としてはディベートでの反駁(はんばく)などがすっきり図示化できる~と、ちょっと感心してしまった。また、アシュアランスケースの標準化作業や認証関係も話が出た。


・セーフティとセキュリティ規格の同時認証方法論について

認証にお金がかかる話も行われ、似かよった2つを同時認証した具体例、またその課題が説明された。以前からセーフティとセキュリティに限らず興味のあった範疇なんだけど、一挙に実践へ向えない色んな事情も感じた。


・ソフトウェアIV&Vの基礎

IV&V自体の説明と、GSNをベースとした「IV&Vケース」の説明があった。


・第1回IV&Vコンテスト(電子レンジ仕様編)審査評・表彰

午前中に行われたコンテストの審査評・表彰。電子レンジの要求に対する検証結果などを確信させるコンテスト。うーん分かりにくいかな...。電子レンジの検証をGNS(IV&Vケース)で書いて、それを審査するコンテスト。チーム対抗で、出場したのは5チーム(だったと思う)。なお、コンテストへの参加はチームで応募するもので、コンテスト参加者のみが午前中に受講と作業。

IV&Vケースの実践的な場と思って、個人的に期待してたもの。ただし、電子レンジの検証全てにわたるわけではなくて、2つくらいの課題に対するIV&Vケースで、自分としてはなんで微細的な視点で考えるんだろうと、少し頭の中がもやもや。

後で、IV&Vケースの説明者に聞いたけど、IV&Vケースの使い方にも色々意見はあるそうだ。俯瞰的な利用の方を好む人もいるようで、自分もそのほうが良さそうに思った。(俯瞰的に眺めた上で、今回のコンテストの2つの課題を掘り下げて記述するのは構わないだろうが。)

ちなみに、本コンテストの優勝チームの1人は少し知った人だった。さすが。


GSNは、(複数の)モデリングツールで利用できるようになっているので、徐々に広まっていくと考えられる。呼称がそのまま広まるかは分からないが、IV&Vケースを実践していく事例も出てくるかもしれない。少し頭の隅においておくつもり。


Amazonでの書籍「ソフトウェア 信頼性 安全」


1月 20, 2015 ソフトウェア品質安心・安全ソフトウェアテスト | | コメント (0) | トラックバック (0)

2015年1月 6日 (火)

自己免疫疾患と品証暴走

今日ちらっと見たテレビ「家庭の医学」で登場したのは、SAPHO症候群。症状的には手足の関節痛なんだけど、リウマチ症などと少し違って皮膚系の症状も現れる。SAPHO症候群が”自己免疫疾患”であることが何度か番組で言われた。(ちなみに関節リウマチも自己免疫疾患かと思う。SAPHO症候群は、NHKの「ドクターG」に登場したようだ。)

医療系の番組で時々出てくる”自己免疫疾患”。外部からの異物への反応が過剰になって、症状を引き起こすというもの。しかも厄介な事に、ある病気と思って対処療法的に治療しても良くならずに色々調べたら自己免疫疾患のほうだったというケースが少なくないような気がする。あくまでTV番組などを見ての感想だけど。なお、ふと自律神経失調症なども含まれるのかと思って調べたら、基本的には含まないが、自律神経失調症の中のいくつかを自己免疫疾患に含めるという書き方のサイトもあった。


ソフトウェアに関しては、このような病気との関係では「ソフトウェア病理学」がピンと来る。ただし、この本では”過大な文書化作業”なる項目はあるが、ソフトウェア開発での自己免疫疾患のような事項は書かれていないようだ。

ソフトウェア開発での自己免疫疾患的な現象は、バグゼロを目指す余りにいつまでたってもテスト終了を出せないとか、静的解析でのワーニングゼロを目指すなどが考えられる。市場トラブルなどでバグが見つかってその対応は必要だが、ソフトウェアでのバグゼロが可能かは議論あるところ。むしろソフトウェア工学的には、「バグがないことは証明できない」が通説だ。

単純な論理構造の場合にバグがないことは言えても、どのシステムでもそうだとは言えない。昨今のように他モジュールや他サービスの利用が進むと、全体的なバグのコントロールはもちろん、(意図した時期のリリースのような)管理さえ難しくなる。

ソフトウェア開発以外でも製品企画や製品出荷、製品製造でも似たような事は発生して、いわゆる”過剰品質”。主体が品証とは限らないけど、声高に高品質が叫ばれ、商品化などがなかなか進まない。品証や品証気取り連中の、言わば暴走。

生物が生きてくために免疫は必要だけど、過剰になると弊害が大きくなる。しかも、その弊害が大きくなると直しにくい。(過度の)過剰品質は、その組織体での問題であり、積極的に対処すべきと考える必要があろう。過剰品質の問題は以前から言われてはいるけど、小さな場合(軽い症状)ならまだ良いが、大きい場合(重篤なら)は根本的な治療が必要だし最悪その組織体がなくなることも考えた方が良い。自己免疫疾がそうであるように、外見では自己免疫疾とは気づかない事もあるから要注意。

TVで「自己免疫疾患」が出て、つい考えてしまった。

Amazonでの過剰品質

1月 6, 2015 ソフトウェア品質ソフトウェアテスト | | コメント (0) | トラックバック (0)

2014年10月19日 (日)

ITプロジェクト成功率 30%→75%にアップ?

日経コンピュータ2014年10月16日号を読んでいて目に飛び込んできたのが、”高い成功率も油断は禁物”、”プロジェクト成功率は75%”。の文字。特集「3069人調査で迫る 情報システムのリアル」での、タイトルや見出しだ。

以前の日経コンピュータでは、成功率が30%程度だった。2008年12月1日号と2003年11月17日号での記事で、それぞれ31.1%と26.7%。以前”日経のプロジェクト成功率”としてブログに書いている。

つまり、ここ数年で成功率が30%→75%にアップしている。喜ばしい事だ。(ただし内心では、以前のブログの行間で述べたつもりだけど、数年前などでは回答側も分析側も失敗の方にバイアスがかかっていた気もする。)

数年前などでの日経の調査は、第1回と第2回の「プロジェクト実態調査」と題するものだった。5年ごとで、次は2013年と気にかけていたが雑誌には掲載されてない。なので今回の10月16日号が、それに代わるものと考えて良いだろう。ちなみにサンプルは全く同じかは不明だが、有効回答数は、2003年が1746、2008年が814、そして今回の2014年が3069なので、回答数自体は増えている。

個人的には、今回の方が実態と合致しているように思える。なお、工程での失敗率の分析や商習慣に対する回答、アジャイル導入比率などの分析も行われていて、参考になると思う。一読をお勧め。


ちなみに日経コンピュータ2014年10月16日号の目次ページは以下、
http://ec.nikkeibp.co.jp/item/backno/NC0871.html

日経コンピュータ2008年12月1日号の目次ページは以下である。
http://ec.nikkeibp.co.jp/item/backno/NC0718.html

10月 19, 2014 書籍・雑誌ソフトウェアプロジェクトマネジメントプロジェクト管理 | | コメント (0) | トラックバック (0)

2014年9月27日 (土)

SysMLツールベンダー3社揃い踏みセミナー

今日はSysMLのセミナーへ。正式名称は「SysMLツールベンダー3社揃い踏みシステムモデリング事例&ツールセミナー」と、結構長い。オージス総研が主催だけど、ツールベンダ(IBM、チェンジビジョン、スパークスシステムズ)が揃って登壇するし、チェンジビジョンは平鍋さんで、スパークスシステムズは河野さんがしゃべるということで応募した。具体的な事例の話もあることや無料というのも自分としてはメリットに感じた。

http://www.ogis-ri.co.jp/event/1219906_6738.html


ちょうど良さそうな時刻にビルに到着したのに、エレベーターに乗ったら5階止まり。今回のセミナーは上の6階で、そのためのエスカレーターや階段があるかもとうろうろする羽目になり、結局受け付け的には終盤の時間になってしまった。なかなか空席が見つからなかったが結構前の方に空いた席があって、一言声をかけて着席。少し急いで、色々準備した。

講演がスタートして、講演者が、こちらの方を向いて「平鍋さん、そうですよね」みたいに言うからびっくり。なんと、平鍋さんの隣に座ってた。最前列でもなかったし、講演者とか事務局用みたいな紙も張ってなかったので、てっきり聴講者のゾーンだと思ってた。(休憩時に隣が平鍋さんだったと自分でつぶやいたり、平鍋さんに一言挨拶したり、、、。)


講演やパネルディスカッションでの印象などを以下に記す。(聞き違いや勘違いは、ご容赦。)

ツールは、IBMがRhapsody、チェンジビジョンがastah、スパークスシステムズがEnterprise Architect(EA)と、代表的なツール。要求管理など、多少関連するツールの話も出た。

事例では、細部で参考なることはあったが、むしろ使う際にそれぞれ創意工夫しながらやってるという基本的なことが皆さん共通項に思えた。ツールの細部への要望が飛び出したりもして、より一層そのように感じた。モデル設計で仮想的に動くのが面白くなって設計過剰になったり、かえって時間を浪費するなどの話も出て、運用的なことへの工夫も行っているんだと感心した。

ツールの説明時は、各ツールとも特徴的なことがコンパクトにまとまって分かりやすかった。astahの海外使用が増えてきておりその事例では、意外な所での利用の話もあって面白かった。

パネルディスカッションの場でだったと思うけど、関連する事項として「インダストリー4.0」の事がちらっと出た。ヨーロッパ(ドイツ?)における産官学による、言わば工場のIT化への取り組み。直接SysMLとは関係ないけど、モデリング→高速製品化と考えると、無関係でもないというか究極的に目指すものが見えてくる。日本の場合はモデリングというとITとかETロボコンのそれが浮かぶけど、製造業を含めた製品化・サービス化への利用も視野に入れておかないと、ヨーロッパ(ドイツ?)などに負けてしまうということも少し頭の隅に入れていて良いのだろう。

また、受け付け脇に質問パネルがあって、パネルディスカッションではその中からの質問も扱った。単刀直入な「ツール開発にツール自身を使ってますか?」との質問があった。Rhapsodyとastahは、部分部分で使用しているとのこと。EAはEAを使っての開発とのことで、逆に開発のための機能(その場では特にメール機能)まで備えているとの説明があった。人によっては、EAになんでメール機能まであるのかが理解できた人もいた様子。

3つのツールの差別化というか特徴のショート説明では、価格の件や国産製のことなど、皆さん感じている事のいわば復唱みたいな感じ。やはり、それぞれ一長一短だ。

フランクなセミナーだったが、そのお陰もあって有意義な情報を得られたと考える。機会あればまた開催してほしいし、(事例発表者などで難しい側面があるかもしれないけど)他の地方での開催もあってもよさそうとふと思った。


なお、個人的にちょっとした”アハ体験”だったのが、SysMLでの”satisfy(充足)”。satisfyは、SysMLでの要求とブロックの要素間の関係を示すもので、ある要求があるブロックで満たされるということを記述できる。実はここ1,2ヶ月間、システム開発などでのモデリング絡みで考えていた事があった。(新しい)OSでのとある機能を利用して実現したいということは、結構発生する。以前のクライアントサーバーへの移行などでも発生したし、昨今のスマフォでのゲーム開発でも少なくないだろう。結局要求が実装と結構結びついてる。

なので、実装を隠蔽する方にむしろ無理があるのではないかと考えたり、それらの結びつきを上手くモデリングというか図示できるほうが良さそうと思いをめぐらしてた。satisfy(充足)はSysMLでは最初からあったかは覚えてなかったり、そのような疑問時にSysMLを直ぐに調べなかった事を猛反省。さらに言えば、SysMLには要求図というものがあり、要求分析でユースケース図とどちらで検討した方が良いかか考えるべきとも思った。ユースケース図のほうが少し変わったアイコンなどもあって見栄え的にはいいんだろうけど、、、。

9月 27, 2014 ソフトウェア | | コメント (0) | トラックバック (0)

2014年7月22日 (火)

ICSE'14勉強会(東工大)へ

今日は、「ICSE'14勉強会」で大岡山の東工大へ。「ICSE'14勉強会」は、ICSE(イクシーと言う人が多い)2014という国際的な学会での論文を、1日でなるべく多く読むというもの。輪講というよりもラントニングトークスに近いかな。主催は情報処理学会 ソフトウェア工学研究会 国際的研究活動活性化WGで、ここ3年ほど続けている。100近い論文のうち、そのほとんどを網羅。今年は93/99で、網羅率94%と言ってた。

「ICSE'14勉強会」のサイトは以下。
http://qwik.jp/se-reading/10.html

当日などのtogetterがあって、以下。
http://togetter.com/li/696308


情報処理学会主催ではあるが、USTREAMで様子を流したり投票を行ったりしてるし、結構フランクな発表も少なくなかった。ある意味若者寄りの運営で、進行やテンポもいい。逆に結構内容的には濃厚で、昼休みや終わってからは少し頭に疲労感が残った。また、大阪、名古屋、福岡をネットで繋ぎ、東京以外にも発表者が分散している格好。ちなみに発表者は大学生が多かったけど、NTTデータやIBMなども人もいた。

なお、講堂のようなところだろうとか玄関に掲示があるだろうと、建物名はメモしたけど、階や部屋の名前をメモしてなかった。そのため、建物内をうろうろ。再度建物の入口に戻って、それでも掲示無かったら(駄目もとで)守衛所で聞くか諦めようかなと思ってた。そしたら知り合いと遭遇。部屋名も知っててラッキーだった。

また、休憩時に声をかけられ、別の知り合いにも遭遇。一応オニギリなどを事前に購入してたけど、昼食はその知り合いと学食へ向かった。食事しながら色んな話をして、懐かしかったり世の中の動きで参考になる見方なども聞けて、有意義な一時になった。


論文はソフトウェア工学全般に渡ったけど、印象的にはテスト関係が多かった気がする。投票で好評だったのがM2:Unit Test Virtualization with VMVMで、テスト関係。ちなみにM2はテストケースは減らさずに高速テストするアイデア。(ただし初期化で共通的なものはまとめてテストするというもので、結構色んなところでやってると思うのだが。) また、Mutation testingに関する発表もあった。

テーマ的には古来からあるテーマでも、モバイルやクラウドを意識した論文になってるような感じ。また、そもそも(大)昔なら、その大学や企業でのプログラムなどの分析での論文だったと思われるが、今回の多くは、オープンソースのモジュールを解析したり分析したりしていた。ある意味、題材がクラウドにあると言ったイメージ。

なお、省エネ(Webのページの配色を省エネになるように設定)やソフトウェア理解(脳波による分析)では、面白い試みもするもんだな~と思いつつ、論文としての掘り下げが少ない気がするものもあった。


蛇足だけど、東工大の大岡山は久しぶり。20数年ぶりぐらいかな。そもそも入口が開放的になってるし、ビルとかが増えたイメージ。驚いたのは、犬の散歩禁止や、大声出さないでの掲示。結構構内に書かれてあった。声の件は、学生にというよりも、構内で遊ぶ子らに対してのもの。犬も似たようなもんで、(小さな?)庶民悪。また、今回の会場のビルは、研究室に入る時は、上履き着用。エレベーターや階段からの所で仕切られてて、そこで履き替え。研究室フロアそのものがカーペットになってた。(知り合いと話したら、富士通の山本卓眞元会長の考えの影響とか言ってたけど、本当か?)


今回の勉強会は具体的に参考になりそうな考え方もポツリポツリとあって、勉強になった。都合がつけば来年も参加したいと思う。情報処理学会(を含め他の団体も)このようなイベントは実施・継続すべきと考える。やっぱ最近の動向を色んな人の目線で聞けるのは貴重だ。そうしないと(古い)教科書のコピペだけになって、進歩から遠ざかってしまう。ふとそんなことも思った。また、本催しでの網羅率に拘る事への反対意見があったけど、100%必須とかでないのなら、今の形態が良いと思う。やはりスピード感があるように思えるし、駄目そうなものでもアイデア的には面白いものがあったり、難解なら難解である旨が分かるのは良い事だ。


7月 22, 2014 ソフトウェアソフトウェアテスト | | コメント (0) | トラックバック (0)

2014年7月18日 (金)

回路図もガラパゴス

2日ほど前に、Twitterでつぶやかれた「無駄な抵抗」。

 https://twitter.com/m9_mukyuu/status/489214129463234560

それ自体は、クスッと笑えるような投稿だったが、知り合いとかと話題にしたのは、そこでの抵抗記号。いわゆるギザギザタイプで書かれていた。自分も1年ほど前に知ったけど、このギザギザ記号は古くて、新しい記号になってる。なので、教室とかの黒板に書かれてたというのは、専門的な学科などでは考えにくいかな~というもの。(そこでの話題は、取り立てて問題視してるわけでもなく、単なる補足的な話題提供レベル。)

以下はたまたま自分が持ってた、「電子機械」(実教出版 平成24年発行)という工業高校用の教科書。その表紙裏の記載。抵抗器は長方形になっている。
P7184830_2

どういうことかというと、これらの電気記号はIEC(国際電気標準会議)で定めてて、JISもそれに則っている。が、JIS-C301(旧JIS記号)とJIS-C0617(新JIS記号:IEC 60617に該当)があり、新JISでもどちらを使っても良いとしている。ただし図面の中では統一しなさいとしている。

新JIS記号では抵抗器が長方形になっており、ここでの教科書は新しいJISに則っているというわけだ。

自分が抵抗などの記号が変わったのを知ったのは、「トランジスタ技術」2013年3月号での回路記号をつらつらと眺めている時だった。

以下はその雑誌での、2つを併記説明している部分。
P7184831

ヨーロッパ等への輸出時は、CEマーク認証の為の図面等の提出は、IEC記号つまり新JIS記号での記載が必要となる。なので、輸出とかが多い企業では、新JIS記号が使われている(はず)。

それでも、新JIS記号が一般に浸透してない大きな理由は、ここで挙げたCQ出版などが旧JIS記号に拘ってるのが大きいと思われる。本屋さんで新JIS記号での記載の書籍を見つけようとしてみたが、電験(電気主任技術者試験)やその対策本と、他は本当に数える程度。そもそも本屋さんでの電気のコーナーにはCQ出版の本や雑誌が多いので、当たり前とも言える。「トランジスタ技術」もそうだし、無線関係もそう。我々ソフトウェア技術者に少し馴染みのある「Interface」もCQ出版である。

グローバル化の中で、旧JIS記号に拘るのは問題じゃないの~とか、日本のガラパゴス携帯のことが言われてるけど、回路図自体がガラパゴスというわけだ。日本の電気屋さんが、世界の潮流に取り残されてるようにも思えた。つまり、欧米と新興国が新JISというかIEC図面でやり取りしてるのを傍らで見てるというか、、、。(ちょっと皮肉りすぎだろうけど。)


だが、話がそれだけでは済まない、、、、。同じ「トランジスタ技術」2013年3月号の別ページに記載されているのが以下。論理回路の記号で、左の方は馴染みのある人は多いと思うが、MILスタンダード。右の方が今まで述べた新JIS記号。
P7184832

MILスタンダード(MIL標準)は正式には「MIL-STD-806」で、MILはアメリカ軍の調達のための規格。MILスタンダードは、論理回路の記号として日本では幅広く定着している/定着していた。

MIL標準も、実際は廃止された規格になってしまっている。(正確には、参照とかもあるしJISでも旧記号を使用してよいとしている。) MIL標準(MIL論理記号)のウィキペディアは以下。
http://ja.wikipedia.org/wiki/MIL%E8%AB%96%E7%90%86%E8%A8%98%E5%8F%B7

論理回路の記号に関しても本屋さんで調べてみたが、教科書的な本で新JIS記号での記述はすぐには見つからなかった。ネットでは、新JIS記号で書いてあるものがあったり旧JIS記号との対比で意見を書いているページもいくつか見つかったが、新JIS記号への反発の意見もちらほらあった。

大学の授業ではどうかがわからないが、論理回路の記号はMIL標準が多いのかもしれない。ちなみに、前述の「電子機械」という工業高校用の教科書の論理回路部分は、MIL標準で書かれている。

また、論理回路に関しては、IECの新しい記号は複雑な回路の記述には適しているとの考えがあるようで、逆に授業程度の簡易回路なら旧JISでも十分だし、敢えて新しい記号のために資料や本を修正する必要も無いとの考えは、そう不自然ではない。

P71948462P71948472左は、昔自分が使っていた情報系とMIL標準の定規。ここ何年、いや何十年、特にMIL定規は使ってない。

そもそも昨今は、ソフトウェア屋さんがハード図面を作成することは皆無だし、論理回路図で議論することは少ないと思われる。さらにはハードウェア屋さんも、海外EMSなどの作成に任せて回路図とかのチェックすら少なくなっている気がする。論理記号を意識する人の絶対数が減っている。なので、論理記号の変更の件は、あまり話題に上ってないのだろう。


さて、抵抗の記号などの時に電験のことを取り上げたけれども、論理回路とかなると情報処理技術者試験の事が気になる。調べたら、以下に、試験で使用する代表的な記号・図などの規定が書かれている。

http://www.jitec.ipa.go.jp/1_02annai/annai_yogo_jis_kyu.html
 情報処理用流れ図など :JIS X 0121
 決定表 :JIS X 0125
 計算機システム構成の図記号 :JIS X 0127
 プログラム構成要素及びその表記法 :JIS X 0128

電気回路や論理回路の記号に関しては、規格を明確には記述してない。


個人的には何でも欧米に合わせるとの考えは好きじゃないけど、電気回路や論理回路の記号に関しては、試験や教科書は順次新JIS記号にした方が良いと考える。特に(入門的なものでは無くて)実務を意識した場合は、どのみち企業内では輸出等の関係で新JIS記号というかIECに則ることになる。そうであれば、新JIS記号で習得していた方がいいだろう。教える側の論理より教わる側の論理で考えたら、明白だと思うのだが。


「回路図」

「論理回路」

「工業高校 教科書」

7月 18, 2014 パソコン・インターネット技術ソフトウェア | | コメント (0) | トラックバック (1)

2014年3月 5日 (水)

再考 メイヤーズの三角形問題

知り合いのTwitterのつぶやきで、表題の「メイヤーズの三角形問題」が取り上げられた。ある数値の組み合わせが、どんな三角形の種類なのかというもの。つぶやきでの考えが自分の考えとちょっと違ってたので、「メイヤーズの三角形問題」をもう一度考えてみた/再読してみた。

メイヤーズの三角形問題とは、書籍「ソフトウェア・テストの技法」の冒頭で取り上げられている、読者への試験みたいなもの。

Myers_1st上のAmazonのは、日本語訳の第2版。左のが日本語の初版。もう35年以上も前の出版で、言わば古典。

なお、第2版ではXPの事などが追記されてるが、本三角形問題の細部で表現などが異なっている(後述)。また、Amazonでは”マイヤーズ”となっているが、ここでは訳本内でも書かれている”メイヤーズ”の表現を用いる。

問題は、第1版ではカードから/第2版では入力ダイヤグラムから、3つの整数を読み込んで、その数字の組み合わせで不等辺三角形、二等辺三角形、正三角形のどれかを印刷/表示するプログラムに対するテストケースを書きなさいというもの。

メイヤーズが記載しているのは、13個のテストケースと、1つの予想される出力を示したかというもの。13個の中に、1つの辺がゼロになるものをテストケースに含めているかとか、1つの辺が負数のものをテストケースに含めているかというのがある。14点満点だけど、プログラマの平均得点は7.8点であるとのこと。また、「全ての可能なあやまりを見つけられると保証はしないが」と述べてて、細部は自分で考えなさいとのスタンスだ。特に14番目でのエラー時のメッセージ(細部仕様)は、各自で考えなさいと暗に示していると個人的に考える。

さて、ここから細部になるけど、12として非整数の話しがある。第1版では非整数のこととしか書いてないが、第2版では”2,5,3.5,5.5”と例示がなってる。つまり数値が4つ。多分、本当は5.5は無いのだろう。(個数が異なるテストは13にある。ただし、例示は2つ。)

Twitterので知り合いとのやり取りでは、0詰め数値のことが言われていたけど、それをテストに含めるのは良いことかもしれない。0詰め数値は、3を”03”のように表記する方法。

ちなみに、例示されてるのは”3,3,4;3,4,3;4,3,3”のような表現。";"を便宜的なデリミタと考えて、3と3と4が1つのカードに書かれているなどと読めばいいのか、デリミタなども含めて記述されてるかによるけど、それらに関するテストも気になった。つまり、先に述べた4つ書かれているケースとか、デリミタまで含めて記述さていたら、”,”の代わりにスペースだったり別記号だった時のテストなどもあった方が良さそうである。

整数でないものとして例示は少数だけど、アスキー文字なども考えられる。

再度深く読んでみると、こんなテストケースもあった方が良いのとか思い付いたから不思議なものである。そもそも第2版は、GUIによるもので、GUIに絡むテスト項目は無いように思える。疑るような視点で再読してみることをお勧めする。(もしかしたら、検討した人とか検討した発表があるかもしれない。ちょっと探してみる。)

また、ここで示されてる条件でテストを請け負えるかとか、どんなテスト計画にするかとか少し膨らませて考えるのも悪くないかと思う。あるいは示されてることをRFPとして、十分と言えるか、あるいは何が不十分かと考えたりするのも悪くない。

なお、第2版と第3版は、カード→入力ダイヤグラムや印字→表示への変化以外に、有効な数値組み合わせという表現から、意味のあるという表現に変わっている。ただしこれは訳上の変更かもしれないが。久々に版による違いなどが面白いと感じた一時でもあった。


3月 5, 2014 書籍・雑誌ソフトウェアソフトウェアテスト | | コメント (0) | トラックバック (0)

2013年8月23日 (金)

三人寄れば文殊の知恵が、、、、、まとまらない

ここ1,2週間、数人での作業が発生した。イメージ的には文章の手直しの作業で、時々意見の相違が発生した。「てにおは」の修正のような(ある意味)微々たる事項から、論理的な文になってないなど様々。ある意味そのための作業であり仕方ないし、話すことで妙案に進展したものもあったが、各自の考え方の相違で多少平行線のものがあった。似たような作業でのここ1年くらいでは、ヒートアップ度やその回数が一番大きかったかもしれない。

で、ふと思い出したのが、開発時の会議や設計ドキュメントのレビュー時の意見対立。直接レビュー会議のような場での意見提示でなくても、トラッキングシステム(大昔なら紙に記載してその紙を回覧しながらコメント記入)でも相反する意見が出ることがある。書いたのがAさんなら、修正案がBさんから出て、別修正案がCさんから出たり、元々のAさん記載が良いとの意見が出たりする。

ものの本ではレビューの必要性などが書かれているけど、レビューの必要性よりもどう収束させるかが悩ましい。その部分は、大昔から良い解法がないように思う。ある意味ではレビュー技法などが発展してないとも言えるし、レビューを実施している人達はレビューに関する記事や論文を余り当てにしてないのかもしれない。より正確な表現を使えば、レビューを実施している人達にとって参考となる記事や論文は少ないのかもしれない。

もちろん、論理的/合理的な説明で収束したり実験検証に委ねたりするケースもあって手法もあるが、リーダー格が「えいやっ」で判断せざる終えない局面もある。平行線になった場合、そのような判断を誰かがしていかないと、効率が悪くてしょうがない。

ここ1,2週間での作業で、意見の相違が多かったのにそれなりにまとまったのは、リーダー格を明示的に決めていたことだったろう。当然と言えば当然だけど、今回は皆さん意見がばらけるかもとの意識があったせいかと思う。

ちなみに、”インスペクション”手法での役割として”モデレーター”があるが、ここで言ってる意見集約での責任者という意味では、個人的にはちょっと違うと認識している。ファシリテーターに近いし兼ねることが出来るかもしれないが、合意形成を素早く行ったり判断が必要な点でも少し異なるように思える。なおここでのリーダー格がちょっと大変なのは、せっかく合意形成が出来たり自分が判断したのに、特に上司や他部門によりひっくり返される時があること。しかし、まっ、こればかりは仕方ないと割り切るしかない。


さて今回の作業などで、つい思い出したことがある。2つのプロジェクト。片方は開発ドキュメントもそうだが、特許明細とか営業やユーザ向けの文書チェック作業も発生。冒頭で書いたような「てにおは」の修正にも神経を使ったそうだ。(大変だったろうが、後述するプロジェクトよりは遙かに精度が高いことになる。)

もう一つは聞きづてのもので、納品物のドキュメントに対して「○○が書かれてないから記載して欲しい」とか誤字脱字の指摘を行った人の話。委託先から一言あってPLも誤字脱字“ばかり”指摘するのもと、修正に消極的。他の件もあって、システム化への意識のもなく横柄なPLとの印象もあって、結構プロジェクトそのものに幻滅したとのこと。本人は、不明な未記載ロジックの記載が主で、誤字脱字はついででの指摘のつもりだったのだが。

結局、納品物はそのままOK。検収とか支払いが絡むからだったのかもしれないが、何のための納品チェックなのか??? 修正などを見越してないやり方だったと言える。案外、請負や丸投げでの根本的な問題なのかもしれない。


つまりレビューをすることの必要性などが記事や論文で書かれているけど、それをそう反映するとか、契約と絡めて議論していかないと/組織体で解決策を持っていないとメリットが生まれない。逆にレビューをやっているところは、反映方法や契約と絡めた対処法をより向上させるべきだろう。

8月 23, 2013 ソフトウェアプロジェクトマネジメント | | コメント (0) | トラックバック (0)

2013年8月22日 (木)

ソフトウェアのお掃除タイミング

しばらく前から気にしてた事項に、ソフトウェアのメンテナンス時期があった。OSSなどを使っていたらセキュリティパッチの情報により、更新したりが必要である。プロダクトラインでの管理をしていたりそうでない場合でも、他機種での変更情報が自分担当の機種に関係するかが気になったりする。

開発中や直近で出荷したものならまだ開発メンバーもいるが、出荷後に期間を経た場合はメンバーが別部署に異動しているケースもある。あるいは退社したり、委託先の会社が消滅していることもありえる。

組込み機器の開発でない場合でもセキュリティパッチへの意識は同様だし、ITシステムの場合は利用側からの変更要望が発生したりする。

セキュリティパッチの場合は、パッチ発生の度に対応していたら効率が悪いことがある。再テストもそうだし、多少厄介なのがパッチリリース自体にバグが潜んでいるケース。かといって対応を延び延びにしていては、忘れてしまったりして重要なトラブルになってしまうことがある。次機種や次のITシステム開発の場合でも、従来のソースコードを見直さないと潜在的なバグが次機種などで発生することがあったり、リファクタリングのための工数が見極めにくい。

つまり、問題発生時や新機種/新システムの開発に向けてのソースコード見直し以外に、ソースコードを綺麗にしたり問題点を見つけておくことが必要だ。ソフトウェアのメンテナンスをコンスタントに行っておく意識が必要。また、集中的なソースコードレビューは行われるだろうが、どうしても重要な部分に限定されたり、時が経つと修正などが入ることがある。自分の経験則では、リーダーのような直接タッチしてない人が何気にソースコードを眺めた時にバグやコーディングルール逸脱が見つかることがある。そう考えたら、ふと家事の特にお掃除のスケジューリングってどうしてるんだろうとか、どう教えてるのか気になった。


で、自分の卒業した高校には、当時”家政科”なるものがあって、同窓会のちょっとしたイベントの時に聞いてみた。「授業で、家事のスケジューリング方法とか教えた?」と。返事としては、習わなかったし実際の主婦でもスケジューリングまでやってる人は少ないかもとのことだった。ある意味、予想どおり。

そこで、ネットで調べると授業の格好でまとまっているのは見かけなかったけど、個人ブログで各自の工夫として掲載しているのはいくつか見つかった。もっと良いのがあるかもしれないが、見かけたのは以下。

http://kajirakuraku.com/cleaning001.html
月と週でスケジュール表を作ってみようというもの。

http://ameblo.jp/kajino-chie2525/entry-11442422842.html
どちらかというと、年/月レベル主体でのスケジューリング。

http://ameblo.jp/logica/entry-10460566887.html
ファストフード店などの掃除の仕方を参考にして、表に掃除する日をマークして、実施したら名前を書くようにしようとの提案。

皆さん、それぞれ工夫している。


そうこうしているうちに気になったのが、事業所での掃除や害虫駆除。法律での背景があるように聞いたので確認してみることにした。(法律が根拠と思ったけど、実際は法律に直接書かれているわけではなくて、基準での運用だった。)

http://www.sharosisikaku.com/backnumber/anneihou/20060318.html
掃除や害虫駆除に関してフランクにまとめてあった。

http://www.mhlw.go.jp/bunya/kenkou/seikatsu-eisei10/
厚労省の「建築物環境衛生管理基準について」のページ。

半年に1度は大掃除をして、害虫がいないかの調査をしなさいとある。


他を参考にする限りでは、曜日や月を決めてソフトウェアのメンテナンスをするのが良さそうだ。また、それらはソースコードをいじっている人以外も巻き込んでスケジュール案を検討するのがよいと言える。暗黙なり明確に、その組織体でルールを決めて実施したかの確認まで行と良い。

(掃除をしたかしないかが一目瞭然なように)ソースコード上のどこを見直したかが視覚的に分かるように工夫したり、出荷後に期間を経た場合でも定常的な業務項目としてノミネートしておくなどすれば完璧だろう。

追記:2013/12/18のNHK「あさイチ」で、掃除術を放送していた。

http://datazoo.jp/tv/%E3%81%82%E3%81%95%E3%82%A4%E3%83%81%28%E6%B0%B4%E6%9B%9C%E6%97%A5%29/689108

その中で登場したのが”予定掃除表”。冷蔵庫や換気扇の掃除予定に○をつけておき、実施したら塗りつぶすというもの。予定の横軸は、曜日だったように思う。

8月 22, 2013 ソフトウェア品質 | | コメント (0) | トラックバック (0)

2013年7月23日 (火)

情報処理学会「デジタルプラクティス」 ”ヘルスケアの現場を支えるIT”

今度の情報処理学会「デジタルプラクティス」の特集は、”ヘルスケアの現場を支えるIT”。さらっと読んだけど、面白い。実践分野の話しがほとんどだし、(デジタルプラクティスでも時々ある)論文のための理論こねくり回しが少ないように思う。

デジタルプラクティス単体でも、Amazonで購入できるそうだ。


実務を踏まえての論文が多いので、分かりやすい。苦労話や今後の課題と感じることも具体的に書かれている論文が多く、(他の分野でも)参考になるだろう。思い付くのは、カルテの閲覧への要望が多くて対応したが、対応したら対応したで分かりにくいとか医者の記載が横柄に思えるとの苦情があったそうだ。ある意味仕方ないと言えるが、その対策として、カルテ部分に内部用の欄を設けたとのこと。海外や地方への展開の際の、法律とか医師会への配慮のことなども書かれていた。

システムの構築と共に事業運営との問題や、虚偽データの扱いなど、結構本質的な問題にも触れている箇所があって考えさせられた。

また知らなかったシステムの紹介もあって、自分の健康維持などに役立ちそうなものがあった。具体的には、全国の血圧の上昇度合いが分かる”にっぽん血圧マップ”。時々アクセスして、自分の血圧データと比較してみたいと思う。(”にっぽん血圧マップ”への要望/切望としては、過去データを見ることができればと思う。せめて1月前程度はクリックか何かで見ることができればありがたい。)


興味あれば、購入して読むのも良いかもしれない。なお、価格が情報処理学会誌と同じような価格で、多少躊躇するかもしれない。今回の号はある程度見合ってるとは思うが、デジタルプラクティスの趣旨などを考えると、もう少し安価にするなども考えて良さそうに思う。

7月 23, 2013 書籍・雑誌技術ソフトウェアテクノロジー | | コメント (1) | トラックバック (0)

2013年7月22日 (月)

「モデルベース開発」 dSPACE Japan(監修)

副題に、―モデリングから、プラント・モデル、コントロール・モデル― と記載されている本。何気に本屋さんで見つけて購入した。帰りの電車の中で斜め読みして、買って良かったとの印象の本。

ちなみに以下での(P~)は、本書でのページ数。

まず監修になってる「dSPACE Japan」だけど、メカトロニクス制御のハードウエアやソフトウエアソリューションを手がけてるドイツ dSPACE社の日本法人。個人的には、コンサル的な活動も少なくないように思う。日本法人は2006年に設立されている。

本書は、dSPACE Japan以外に日産やスマートエナジーという会社の合計4人による共著に近い。結構分野が違ったり、数式的なモデリング主体の話しだったり機能安全を含めたモデル開発の進め方の話しだったりと、千差万別。それらの違いが多少違和感になる時もあるが、幅広く知ることが出来るメリットの方が大きい。ちなみにモデリングでのシミュレーションツールはほぼ、MATLAB/Simulink。また量産コード生成ツールとしては、dSPACEのTargetLinkによる説明になっている。


実務寄りの話しが所々出てきて、モデル開発を行う意味での注意点というか課題などが明確なのがよい。実務者にとっては常識的なことでも、少し違う分野の実務者とか、これからモデルベース開発をやろうかと思っている人にも参考になろう。

具体的には、量産コード生成ツールの高いコード効率への要求として、コントローラの1円コスト増が1億円/年の収益源になる例えの話し。ただし、1000万台/年で平均10台のコントローラでの算出。(P21) 変数のバイト数を固定小数点演算にして2バイトあるいは1バイトにすることでのコスト低減になる話し。(P47)  Simulinkでのブロック線図からCコードへの変換での、遅延処理まで含めた最適化の例の話し。(P47~) 計算負荷=実時間での計算での問題点。(P87) 実装での量子化された値への対応を行うためのアイデア。量子化での具体例として10ビット分解能のA/Dコンバータ。(P120) など。


欠陥生成ユニット(FIU)の話(P57)や、モデルベース開発と機能安全に関しては章を設けて説明している(第5章)。若干ではあるが、コンポーネントベース開発にも言及している(P128)。高信頼性化としても、参考になると考える。


数学モデルが所詮モデルであるし、精度の高い数学モデルを構築しても計算手法での限界があるとの意見も述べられている。(P194)  自動車会社の取り組みも紹介されており、本田技研のシミュレータで全ECU連携(P89)や日産の全てのエンジン制御ソフトウェアにモデルベース開発採用(P130)。 日産の事例は、どの部分/全部のモデリングかなど多少気にはなるが、モデルベース開発が浸透していると言うことだろう。

ソフトウェア技術者に一読を勧めたい一冊。

7月 22, 2013 書籍・雑誌ソフトウェア | | コメント (0) | トラックバック (0)

2013年7月13日 (土)

「コードクローン分析とその応用」

今日は日本技術士会と情報処理学会とのコラボの、表題の催しへ参加した。一般の人が見ることができて、細かいことが書いてあるのは、以下のITコーディネーターのページかもしれない。(技術士の場合は、ここでの料金とは別。)

https://wwu.itc.or.jp/fmi/xsl/seminar_guide_n/seminar_s02.xsl?ID=K13060730

大阪大学の井上先生自らの講義、しかもワークショップがあったので、掘り下げて学ぶことができた。

CCFinderとGeminiの説明があり、ワークショップもその両方を使っての分析だった。というか、今まで自分はGeminiの方を余り詳しく知らなかったが、クローン分析ではGeminiを使っての分析が(も)重要と認識した。(コードクローン分析の、裁判への資料への活用なども紹介もあって、なるほどと納得した。)

我々の班が分析したのは、Python。思った以上にクローンが多かった。どうも、OS毎や型毎の部分をコード生成している。スピード優先しているんだろう。#ifdef などを多用している感じ。で、多少自分の頭の中で、それならソースコードもだけど、プリプロセッサー前のソース“文”を処理できた方が良いのかな~とか、あれそうなると文字列変換とかが絡むとちょっと厄介か~とかが頭を駆け巡った。また、トークン数との表現とコード辺の数との表現の意味的な違いなどが的確に分からずについ色々考えて、分析でのアイデアとかまとめの際の作業が少しおぼつかなかった。

懇親会も開催されて、そちらで修士の方に、トークン数/コード辺の違いを聞いたりして多少は理解できた気がするけど、まだすっきり状態ではないかも。^.^; また、一時期のブーム的な状況と、現在とでは何が違うのか気になった。自分なりの解釈ではなんとなく、利用しているところは利用してるけど、その成果をなかなか発表しにくい感じ。経費的なこともあるし、その企業や製品群の開発方法やソースの“癖”とかに関係するので公にするのを躊躇するのかもしれない。

また、プリプロセッサー前のソース“文”での解析とか、知り合いの大阪大学出身と井上先生が年齢的にも近いから先生が知ってるか聞こうと思った。しかし、前者は自分なりに考えがまとまらないし、後者は卒業年や学部などが同じか考えているうちに、先生のお帰りになる時間になってしまった。(帰って調べたら、どうも同じ卒業年/学部のように思えてきた。学科も同じかも。知り合いに会う機会があれば、そちらで聞いてみようかな。 なお、懇親会なので、他の人との会話などもあってちょっと挨拶のタイミングを失ったのも大きな理由。)


振り返るとある意味、短時間というか少し分析が不十分だったかもしれないが、座学よりも非常に多くのことを学んだ気がする。今回のような学会とのコラボの催しへの参加は何度かあるけど、今回も有意義だった。

7月 13, 2013 ソフトウェア技術士 | | コメント (0) | トラックバック (0)

2013年7月 7日 (日)

Feedly iPad版が動かない

「Googleリーダーは、Feedly へ乗り換え」で書いたように、RSSリーダーはFeedly へ乗り換えた。結構気に入ってはいるが、iPad版と、PC版というかクラウド版とで、見栄えや操作方法が結構違う部分は気になっていた。

RSSのグループ名の表示文字数などの関係で、iPad版の利用は皆無だったけど、Googleリーダーのサービス自体が終わったこともあって、iPad版のバージョンアップがあったり操作性の統一が図られたのかなと思って、iPad版を操作してみた。新しいソフトがリリースされていたのでバージョンアップ。

ところが、 'Over Capacity'というエラーが出て動作しない。再度Googleへのアクセス許可をやっても同様。Feedlyを削除して再インストールなどを行っても同様だった。最初は、Feedlyでも、バグである旨は掲示されていなかったような気がする。最近はバグと書いてはあるけど、どうもクラウド版と接続できるように大きく変更しているようだ。(Feedlyの変更だけでは済まないのかもしれないけど、、、。)

iPhone版のFeedlyはサポートされているとか、iPadでも別のアプリ経由でFreedlyへアクセスできるようだけど新しいアプリをインストールするのは躊躇している。今のところ、iPad版のFeedlyのリリースをしばらく待つ予定。

それにしても、向こうのソフトは、サポート不十分だったり急にサービス停止したりするから厄介だ。まっ、恩恵もあるんだから仕方ないんだどうけど、なんかアナウンスの仕方など工夫が欲しいところ。

7月 7, 2013 パソコン・インターネットソフトウェア | | コメント (0) | トラックバック (0)

2013年7月 4日 (木)

ロボットコンテスト ルールのモデルは?

今日、たまたま目にしたのが「水中ロボコン」。正式名称は、「'13水中ロボットコンベンションin JAMSTEC」。

http://aquarobo.com/jamstec/

JAMSTEC でやるんだ~とかキヤノン財団が協賛なんだ~とか目について、さらっとルール(公式ガイドブック)とかを見てみた。

水中(のみ)で動作するのは大変だよな~と思ったら、水中のみの動作でなくても良いし、遠隔操作でも良いとのこと。つまり、船からつり下げてさらに人の遠隔操作で船を動かしたり的に当てるようにしても良いことになる。船からつり下げるタイプでも良いことに気が付いたのが、ルールの中盤辺りを読んでからだった。(正確には、自立型と遠隔操作型とでは部門を別にしているようだが、、、。)

そのためふと、「ルールがモデルで記述されてれば、早めに気が付いたのかな~」とか思った。ところが、ETロボコンなどにはモデル化したルールがあるような気がしたが、見つからない。そう言えば、今までルールを読んだことがあったけど、普通の文章だったような気がする。

なんで?と気になった。UMLロボコンの頃を含めると10年以上経過しているし、そもそもモデリングも題材にしているコンテストなのに、ルールがモデリングされてないのも不思議と言えば不思議。ITプロジェクトなどで契約がプロジェクト計画の元ネタなどになったりするけど、ルールという要求事項がモデルになっていれば、それ以降の作業も楽になりそうだ。あるいは、ロボコンの審判をモデル化することで、審判の自動化もできそうな気もしてきた。

逆に、ルールをモデリングできないということは、モデルの限界が明確と言うことか、、、、、。(モデル化する人や手間がないのかもしれないけど、それを出題にしても良いかもしれないし、ルールを考える人達の学生さんなどを授業等の一環で活用するのも良いかもしれない。)

なんか、ついそんなことを考えてしまった。

7月 4, 2013 ソフトウェア | | コメント (0) | トラックバック (0)

2013年5月31日 (金)

ソフトウェアにおける「故障モード」

Facebookで知り合いの書き込みにコメントしたら、どうもソフトウェアにおける「故障モード」って整理されてない/一般的なものが存在しないようだと判明。探せば見つかるのかもしれないが、広まっているものがないように思えた。

ちなみに、CiNiiで「ソフトウェア FMEA」で検索すると19件、「ソフトウェア 故障モード」で検索すると7件ヒットした。未公開などの中に良い情報があるかもしれないが、読める論文だと、故障モードが詳細すぎる気がする。(今回ブログに書いたのは、それも理由。) またCiNiiで「FMEA」で検索すると249件、「ソフトウェア 故障モード」で検索すると119件ヒット。

と言うことで、自分の勉強も兼ねて、ソフトウェアにおける「故障モード」について考えてみた。本来は実機器や実システムでの故障モードを考えるべきとか考えるのが普通だけど、多少一般化できないかとの思いで記述。

ちなみに自分自身の「故障モード」やFMEAでの経験だけど、知識として知ってはいても実践はほとんど無い。実践と言っても、概算を机上で考えて重要そうなものを書き出す程度。装置やシステム全体のFMEAを全部記述して算出まで行うのは自分も経験無いし、ハード屋さんのそれも見たことがないように思う。(ハード屋さんは、MTBF算出の方が結構重要だったと思う。)


Fmea_pdf故障モードを具体的にイメージできそうに思ったものが左の二つ。


それぞれ、左の書籍での記載からである。

構成部品での故障を識別できる文言で記載し、上位構成要素(上位システムとか全体を含む)への影響を記載してある。他に発生頻度や重要度を記述し、その対応の必要性を検討する。例示したものは、分かりやすいと感じた。

ただし最初で述べたアクセスしやすい論文では、ソフトウェアのFMEAではトップダウンでのFTA手法と対比を意識するためか、細部の部品での故障に拘ることがあるようだ。ここで例示したような基板やある程度の機能の括りで考えた方が良い(と考える)。

また、記述する”故障モード”であるが、ソフトウェアの場合でのバグ分類のように分類する時/人がいる。仕様漏れで誤作動といった具合。それもおかしい。むしろユーザーとかサービスマン目線で考えるべきだ。(製造時のFMEAを検討する時があるけど、その件とは別で、あくまで一般的な故障モードでの話し。)

上記を敢えて書くのは、特にシステムの場合は、メカやエレキから構成される機器(サブシステム)や基板などが存在し、システムや機器の故障モードを考える場合は、メカやエレキによる故障モードと構成部品や故障の粒度を似たものにすべきであるためである。そうしないと”ちぐはぐ”になり、FMEAの結果を見るサービスマンなどが混乱してしまったり対応の検討も悪いものになる。

また、昨今ではクラウドを利用したソフトウェア開発が少なくない。その際にHDDやメモリーの故障は避けて通れないし、むしろそれを前提に設計する。それと同次元で、ソフトウェアの故障も考えて検討する意味でも、故障の粒度は似たものがよい。


さて、一般的な”故障モード”について。前述の「FMEA手法と実践事例」などでも記載されているが、「IEC 60812;FMEA」での”一般的な故障モード”は以下の4つ。

速めに動作
規定された時間に動作しない
規定された時間に停止しない
動作中の故障

ちなみにJIS Z 8115では以下のように表現している。

故障モード 故障状態の形式による分類。例えば,断線,短絡,折損,摩耗,特性の劣化など。

「FMEA手法と実践事例」では、IEC 60812;FMEAなどをもとに、それらを少し詳細化したり、電気系の機器ならこのような故障モード、電子部品ならこのような故障モードというのが参考として書かれている。例えば、電気系機器や電子部品での故障モードとしては、開放(断線)、短絡(出力が0)などである。


なお、従来のFMEAの考えは構成部品が上位へどう影響するの目線での検討であった。ところが、ソフトウェアの場合は、自分たちの構成部品でないものの影響で全体がダウンするなどがありえる。PCでの自分たちのソフト以外がメモリーやCPUリソースを喰ってしまい、PC全体がダウンするようなケースである。ある意味では、(自分たちの関与しない)他の構成部品からの”攻撃”で、自分たちの構成部品がダウンしてしまう。ウィルスが端的な例である。

ネットワークが絡むと更に”攻撃”への意識が必要な場合がある。具体的にはDoS攻撃などである。一般回線でない機器内のバス結合に近い状況でも、特定の構成部品の故障が結合路へ思わぬ負荷をかけたり、他の構成部品を故障や不正動作を誘発することがある。

CAN(車載ネットワーク)やフライバイワイヤー(航空機の操縦・飛行制御システム)のように、人命などに関わる機器での構成部品間のネットワーク経由での結合が普及している。特殊な通信経路や形態もあるが、汎用的なネットワークケーブルによるLANでのシステムも少なくない。また、機器内にそれらのネットワークを持つと同時に、サービスマン用やクラウドとの接続でWANと繋がる場合も多い。ネットワークに絡む故障モードは、大きな課題でもあり意識が必要とだろう。

他の構成部品や自分たちと関係しない部品やネットワーク経由の処理が、自システムや自システムに影響を及ぼす故障は、FTAでの検討も一つの方法かもしれない。FTAはトップダウン思考なのでマッチしやすいとの考えであり、FTAとFMEAとのハイブリッド的に考えた方が良いとの考えは組織体によるかと思われる。ただし個人的には、冒頭で述べたように、そう全体を整理することはないので、FMEAで”全体”(あるいは他からの影響)というものを構成部品に加えてボトムアップ的なFMEA前提で考える方がよいと思うのだが、、、。


さて、FMEAの検討の際によく利用されるのが、HAZOP(IEC HAZOP)であろう。以下で、HAZOPでのガイドワードをしめす。ちなみにこの一覧は、名古屋工業研究所の小川氏などによる表の、分類~外れの表現部分の抜粋である。


分類 誘導語外れの表現
存在 (existence)無 (no)質文は量が無い
方向 (direction)逆 (reverse)質文は量が反対方向
他 (other than) その他の方向
量 (quantity)大 (more)量的な増大
小 (less)量的な減少
質 (quality)類 (as well as)質的な増大
部 (part of)質的な減少
時間 (time)早 (early) 時間が早い
遅 (late)時間が遅い
順番 (order)前 (before)順番が前(事前)
後 (after) 順番が後(事後)


それらを踏まえて、ソフトウェアの故障モードの私案を示してみる。冒頭で述べたように本来は具体的な機器やシステムでのソフトウェア構成部品の故障モードで考えるべきだけど、ここでの故障モードはある程度汎用的と思われるものにしている。


故障モード 備考
ソフトウェアが存在しない(本来より少ない) 起動してない、起動後(他とのバージョン不整合などにより)自身でexit、killされた、、、
ソフトウェアが本来より多い (規定以上の)二重起動、終了せず
ソフトウェアが動いていない ハングアップ、(一定時間)応答無し、起動後自身でループなどで停止
リターン値が異なる 正しくない値をリターン
リターン値が異常 範囲外や型異常
リターン個数が異なる 多い、少ない
リターンデータが異なる 浮動小数点の微少部分、画像・音声データの微量部分、、
リターンデータが異常 リターンフォーマット異常
リターンタイミングが異なる 早い、遅い、順番が異なる、タイミングがブレル
アクセス異常 アクセスすべきでないものへアクセス。DBへのアクセス、フラグ/GUIなどデータ領域へのアクセス、他ソフトとの通信、他デバイスとの通信
アクセス方法が異常 物理的/論理的にアクセス方法がマッチしてない
アクセスしてない 物理的/論理的にアクセスしてない
アクセスデータ書き込みの値が正しくない値 間違った値のDBへの書き込み、データ領域への書き込み、他ソフトとの通信、他デバイスとの通信
アクセスデータ書き込みが異常値 異常値のDBへの書き込み、データ領域への書き込み、他ソフトとの通信、他デバイスとの通信
アクセスデータ読み込みの結果が異なる/異常 間違ったデータを取り込む。DBからの読み込み、データ領域からの読み込み、他ソフトとの通信、他デバイスとの通信
アクセスデータへのアクセスタイミングが異なる 早い、遅い、順番が異なる、タイミングがブレル

さほど多くない。逆に、もっと個数を絞っても良いかもしれない。(既に述べた、PCなりシステムがダウンするのは、これとは別に構成部品=全体として故障モードを考えればよい。そちらでの故障モードの個数は、多くても数個だろう。)

Facebookを契機にソフトウェアにおける「故障モード」を考えてみたけど、自分なりに気づきも出てきて勉強になったと言える。故障(モード)の検出を分かりやすくするには、どうしたらいいか。ここで示した故障モードでも、うまく区別しきれない状況もあり故障モードとして統合した方が良いのか、あるいは区別できる方法を考えるべきか、、、、。今回のをたたき台にして、ブラッシュアップすることも頭の隅に入れておきたい。

5月 31, 2013 ソフトウェア品質 | | コメント (1) | トラックバック (0)

2013年5月22日 (水)

「テストから見えてくるグーグルのソフトウェア開発」

今日、何気に本屋さんの本棚見たら、表題の「テストから見えてくるグーグルのソフトウェア開発」が1冊置いてあった。

平積みでなかったし、以前(今思えば予約注文だったか)にAmazonとかで見た気がしたので、結構前の出版かなと思った。

ところが巻末見たら、今年の5月23日の発行。パラパラと内容を読んだら結構面白そうで、則購入。

グーグルでの初期の頃のソフトウェア開発やテストの様子、そして現在のことが具体的に書かれてる。GmailやAndroid、インドなどいくつかのグループのテストのマネージャーとのインタビューがあり、話題も多岐に渡っている。

まだ全部読んでないけど、気になった事項をメモ。

・関連する職種として、SWE(ソフトウェアエンジニア)、SET(ソフトウェアエンジニアインテスト)、TE(テストエンジニア)。

TEが開発とは別の外部テストみたいに受け取った。ただし、ドッグフーダー(リリース前の社内利用者)や早期ユーザーとの協力関係もマネジメントするとのこと。

・テストを単体テスト/統合テスト/システムテストと分けずに、Sテスト、Mテスト、Lテストと表現。Sテストは(一般的な)単体テストというか自動テスト化。Lテストはユーザー視点でのシナリオテスト中心。システム全体のテストとして、Eテストなる呼び方のテストが最近出来た/言われるようになった。

・「プロトコルバッファ言語」なるものがある。公開されており、データ構造などの定義に使われる。JavaやPythonなど実際の言語での処理が、予め用意されてる(ひな形はある)感じなのだろう。 SETは、本コードの記述をレビューする。

・Buganizaerなるバグ管理システムがある。バグ票のフィールドで必須なものはごくわずかで、定義を曖昧にし、個々のチームがそれぞれのワークフローに応じて決めることができるようにしている。

・BITE(Browser Integrated Test Environment)と呼ぶ、ブラウザに統合されたテスト環境があり、テストの実践などをブラウザとクラウドで処理する。


インタビューなどの細部を含め、自分たちでも利用できそうな考えや手法などがちりばめられている感じがするので、じっくり読んでみるつもりだ。

5月 22, 2013 ソフトウェア品質ソフトウェアテスト | | コメント (0) | トラックバック (0)

2013年5月17日 (金)

「共通フレーム 2013」

とある所で「共通フレーム 2013」を見て、早速購入。ソフトウェアライフサイクルプロセスで、SLPC-JCF 2013。

ただし、この数日間で新宿の紀伊國屋と神田の三省堂に行っても、2013版は売ってなかった。2007の2版のみ。結局Amazon経由で、購入した。

理由は後述するけど、共通フレームに興味があれば、2007年の2版よりも2013版を入手すべきだ。

P5172547P5172548良い機会だったので、今までの共通フレームの本を並べて撮影。少し分厚くなった。

P5172549_22007年の2版から色々変更されているけど、自分が一番重要と思うのは左の写真。(スキャンでなくて、敢えてデジカメ撮影とした。)

上が2007年の2版で、下が2013年版。2007年でのピンク部分が、2013年版では大きく2つに分かれている。2013年版でのそのうちの上段がシステム開発での目線、下段がソフトウェア開発の目線(呼称的には「ソフトウェア実装プロセス」)である。

2007年の2版までは、ソフトウェアライフサイクルモデルをISO/IEC 12207に準じていた。ところが、”システム”ライフサイクルを定めたISO/IEC 15288が発行され、12207との整合性は当初から話題となっていた。 ちなみに2008年には整合性のために改訂されたが、整合性の第一ステップであり、共通フレームの改訂にまでには至っていなかった。(ISO/IEC 15288のJIS版で、整合性の件には触れていたはずだが、勘違いなら済みません。)

また、ISO/IEC/IEEE 29148があり、そちらは”要求工学”規格と書かれたりすることもあるが、原題は”Systems and Software Engineering – Life Cycle Processes – Requirements. Engineering”。つまりこちらも、システムまで含めた要求管理やライフサイクルの規格である。

今回の共通フレーム 2013では、ISO/IEC 12207と、ISO/IEC 15288やISO/IEC/IEEE 29148との整合性を図っている。ある意味では、”やっと”出版されたとの感想に近い。

ISO/IEC 12207が非常にまずかったのは、ソフトウェアが大きな1つの固まりのように捉えて、設計や実装、テストが進捗するように考えやすい点だ。少なくとも共通フレームなどの図をそのまま受け取って、そう思う人が少なくない。

今回は、上の写真が示すように、システム内のソフトウェアを実装するとの考えである。また、図ではシンプルに表せないので仕方ないが、ソフトウェアがいくつもあって、それらが並行して進捗するイメージである。ITシステムとか組込みでのシステムでの開発は実際はそうで、規格の方がそれらをうまく表現するようになったとも言える。(並行して進捗するイメージというかいくつかのサブシステムより形成されるという点は、規格での明示としてはISO/IEC 15288のJIS(JIS X 0170)での付属書が、参考になるだろう。)

その意味で、本屋さんに2007年の2版があったとしても、2013版を注文するとかネット経由で購入すべきだろう。特にソフトウェア開発を含めたプロセス構築やプロセス改善では、(2007年版ではなく)2013版を参考にしながら行った方が良い。


なおご存じと思うが、共通フレームワーク上のソフトウェア実装プロセスでのプロセスは(正式名称ではないが)以下であり、単体テスとか受け入れテストなどのプロセスはない。

・準備
・要件定義
・方式設計
・詳細設計
・構築
・結合
・適格性確認テスト
・導入
・受入れ支援

2007年版だと開発プロセスに該当するが、各プロセスは大きくは違わない。(2013版での構築プロセスが、2007版では”コード作成及びテスト”としているなどの違いはあり。)

つまり誰が考えても、開発プロセスに”受入れテスト”があるのはおかしい。受入れテストはユーザー側でのプロセスで、開発側ではユーザーへの出荷がOKかの判定とか、ソフトモジュールならリリース判定のようなものが該当するはずだ。ISO/IEC 12207や共通フレームワークでは、当初から”受入れ支援”とか”受入れテストの支援”という用語であり、あくまで”支援”という文言の付いたプロセスとしている。

”ISO/IEC 12207準拠”とか”12207でのプロセス”の文字の後に、(単体テストや統合テスト、)受入れテストが書いてあるのは、極論すると内容も眉唾と考えても良いことが少なくないのが個人感想だ。


「共通フレーム 2013」は、まださらっとしか読んでないが、随所に参考になりそうなネタも少なくない。じっくり読んだり、プロセス構築やプロセス改善の際には手元に置いて参照しながら作業したいと思う。

5月 17, 2013 ソフトウェア | | コメント (0) | トラックバック (0)

2013年4月26日 (金)

「医療用ソフトウェアを巡る最近の規制動向等について-その現状と課題-」受講

今日は、「医療用ソフトウェアを巡る最近の規制動向等について-その現状と課題-」という講演を受講。医療機器関連の話で、自分の場合は関わりの少ない分野。タイトルにもある、医療用ソフトの規制動向が気になって受講した。

以下は、主催者での開催一覧。(しばらくしたら、今回の講演はなくなってると思われるけど。)

http://www.pmrj.jp/kenshu/html/frm050.php?cate=5


会場に150人位いただろうか。医療用ソフトウェアに関する研究会(経産省、ただし文科省や厚労省とも連携)や日本経済再生本部での話、そして薬事法改正との絡みが大きな柱だった。

なお、技術的な話し以外に、一部健康ネタとして興味のある話も出た。(国立循環器病研究センターでの”かるしおレシピ”。センターでの減塩料理のレシピで、25万部売れたそうだ。)


結構断片的だけど、興味を持った事項。勘違いや聞き違いはご容赦。

・医療機器に関連する3団体(JAHIS、JEITA、JIRA)のことを、3Jと呼ぶ。講演では”トリプルJ”と言ってた。保健医療福祉情報システム工業会 (JAHIS)、電子情報技術産業協会(JEITA)、日本画像医療システム工業会(JIRA)。

・ソフトを組み込みソフトとスタンドアローンソフトに分けているが、後者は汎用ハードを利用したソフト。汎用ハードはPCやスマホで、外付けに専用ハード(医療機器)がつながってもスタンドアローンソフトと呼んでいる。

・さらに単体ソフトという言葉もあり、スタンドアローンソフト+組み込みソフトでインストール等により医療機器と一体となるもの。

・単体ソフトの扱いが、他国と比べ、日本は規制が不明確だった。結果的に、スタンドアローンを含むソフトの開発が遅れている(国際的な競争力にも影響)。なお、電子カルテは、ここでの規制とは別扱い。

・規制との関連を考える意味で、極端な例はスマホでの万歩計など。それらが医療行為と結びつく時に、どう考えるべきかなど。

・今後の日本での規制整備の方向性としては、IEC62304がベースになると考えられる。

・「欧米の医療用ソフトウェア規制の外観」を講演したソニーの鴛田氏は、元は富士フイルム。欧米での審査対象の技術文書のことが話された。FDAでは(リスクにおけるクラス分類に依存するけど)、テストケースを1件単位で文書提出。

・講演での説明やQ&Aで、医療点数とか(医薬品などでの)共済制度との、関連や同じような仕組みが必要かもとの話/意見が出た。

・Q&Aでは、宮城県での震災に関連しての230万人レセプロクラウド化の件が事例として紹介された。

・医療機器ソフトでのアップグレード(での規制)に関しては、製造業とサービス業にまたがる事になるので留意。

・欧州の認証機関制度がしっかりしている(金銭的に回るようになってる)件や、日本でのマイナンバー制度との関連も話題となった。

・Q&Aでは、医療データの蓄積や活用に関して、日本の方が個人情報の関連かデータが集まりにくいとかデータ収集/提出に消極的な側面の話も出た。

・個人的にはQ&A自体は良かったけど、途中から会場からの2人程度か委員会メンバーらしき人の発言が長いし多少内部ネタ(を臭わすような)話だったのは、勿体なく感じた。筋道だった議論にならず断片的すぎたため。


会場では「知っておきたい薬害の知識」などの本が、割引で購入できた。結構食指が動いたけど、そうお金の余裕があるわけでもないので断念。ちらっと内容を見たが、良くまとまってると思った。(可能性は低いけど)薬害などで調査することがあったら、図書館で探すとか購入しようと思う。

なお、講演を聴きながら、日本で規制が曖昧ならソフトを出したらどうなったかと思った。質問しても良かったろうけど、愚問っぽくて止めた。帰って薬事法を調べたら、製造と販売で(それぞれ)罪になる。

さらには、医薬品などでの医療現場での臨床試験自体が結構高いハードルで、少し緩めようとする/したとのことがネット記事などに出ていた。それを考えると、医療用ソフトウェア(正確には、医療用かグレーなソフトウェア)を開発しても病院などでの実験で引っかかってしまっていたのだろう。実験なり臨床時に、病院の先生が「これは医療用ではない」とか「医療用とは言えない」と言いにくい/言いにくかったのだろう。ましてやソフトを使用して「医療用ではない」とは言い切れない。日本でのグレーなソフトウェア開発が二の足を踏んでたのは、その辺りが理由に思える。


結構充実し、勉強になった半日だった。

4月 26, 2013 技術ソフトウェア | | コメント (0) | トラックバック (0)

2013年3月18日 (月)

WBC グリーライトのサインも一長一短

今日の昼。ふとTVの前を通ったら何人か見てて、なんだろうと思ったらWBC(ワールド・ベースボール・クラシック)の準決勝。日本対プエリトリコの試合で、8回裏の日本攻撃だった。1,2塁という場面で盗塁したんだけど、(2塁の選手はすぐに戻り)1塁からの選手がアウトになって、皆さんため息になってしまった。

その時にテレビの解説の人が、サインに関して「グリーンライト」がどうこうと言ってたので、さっき調査。テレビ解説者も少し述べてたけど、盗塁を選手の判断に任せるというものらしい。今回のWBCでの日本のチームは結構多用したようで、少し前の台湾戦でも用いて得点に駒を進めたようだ。

解説を聞いた時に、野球にもそんな指示の方法があるんだとか、自主性に任せるのは悪い事じゃないよな~とか考えた。ただし今回の状況は、1,2塁の出塁時。いくら自主性に任すと言っても、1,2塁の各選手の息が合わないとうまく行かない。なので本当にグリーンライトのサインだったか、個人的には疑問だ。

プロジェクトで、自主性に任せることは時々経験がある。なかなかプロジェクトマネジメントの教科書に出てくるテーマではないが、実践の際には留意している事項。ソフトウェアテストでは「殺虫剤のジレンマ」を回避する意図もあって、テストケースとして”***部分は担当者の考える値でテストすること”として、敢えて値や方法を記載しない事も行われる。

プロジェクトやソフトウェア開発でも、自主性に任せても良さそうな時と、それではまずい時があるので、使い分けが必要だ。今日のWBCのプレイを見て、ふとそう思った。

3月 18, 2013 スポーツソフトウェアプロジェクトマネジメント | | コメント (0) | トラックバック (0)

2013年3月13日 (水)

軽めの品質のために

先だってのセミナーも含めて、以前からソフトウェアに対して、軽めの品質管理やテストをどう考えたらいいか思いをめぐらしてた。技術的な考えは後日にでも記載するけど、今日は、アナロジーとして的確と思えるのを見つけた/考えついたので紹介する。

自分自身が少し体育会系なので、以下の「陸上競技ルールブック2012」。(年度でタイトル変わってるかもしれない。)

http://www.jaaf.or.jp/athlete/rule/

ここに”第3部 トラック競技”と”第9部 クロスカントリー競走”があり、さらっと対比してみると良い。そもそもページ数が、38ページと4ページ。トラック競技だとmm単位の記述。クロスカントリーはシーズンだって”冬期期間に行われるべき”とか、”魅力的な”や”おおよそ”なんていう非常に曖昧な表現などが目に付く。

自分でも正確に知らなかったけど、トラック競技での風速測定は定められてて、100m競技だとスタートから10秒間。スタート前の計測でもないし、全員ゴールまでの時間でもない。当然だけど、スタートの記載は”スターターの信号器の発射(閃光/煙)”。

クロスカントリー競走は大抵芝生の所で開催されているけど、ルールブック上は”可能な限り草で覆われた”との表現。自分が事前に想定してたよりも、遙かに記載がアバウトだった。


でソフトウェアの世界では、ここでの例の、クロスカントリーの競技のくせにトラック競技のルールブックで話す愚行を行ってるケースがあまりに多い気がする。

そもそも、競技種目に相当するユーザや必要とされる使われ方が異なるのに、つい同じ土壌(例だと陸上競技)で括ってしまう。それなりの素地(元々のメンバーの能力とか今までの信頼性)があった上で厳密な手法などを話すのならいざ知らず、より高度な技法の説明に終始することもある。せっかくクロスカントリー競技で競う/楽しもうとしてるのに、妙にトラック競技のmmの話を持ち出されて興ざめするようなシーンに近いだろうか。

背景としていろんな手法や技法を知っておくのは良い(悪くない)が、組織体内の議論やセミナーでのグループ討議のための情報では、その組織体やグループに応じた手法や技法を元に議論すべきと考える。

3月 13, 2013 ソフトウェア品質ソフトウェアテスト | | コメント (0) | トラックバック (0)

2013年3月10日 (日)

「アジャイルなテストの見積りと計画づくり」

今日は、「アジャイルなテストの見積りと計画づくり」のワークショップへの参加。イベント案内はZusaarでのイベント案内を参考にして欲しい。また、ハッシュタグは、#NagoyaTesting。ハッシュタグを利用して当日も情報のやり取りをしているので、当日の資料や題材のWebプログラム、我々グループのテスト項目や発見したバグ一覧も辿って見ることができる。

案内を目にして、しばらく経ってから申し込んだせいか、補欠になってしまった。懇親会のビアアッシュに先に申込みする格好になった。結構その時は参加希望が多かった。ところが直前になってキャンセルがあり、繰り上がりで参加できることになった。

ただし、パソコン持参とのことで急遽使用できるように準備。最近ノートPCを使ってないせいか、セキュリティパッチやディスク容量が少なくなっていたので、それらの対応を行った。7日の夜から少しづつ準備しようとしたけど、ディスク容量が少ないことで、不要なアプリを消して少しセキュリティパッチを繰り返すやり方になった。

今朝の出発前でもセキュリティパッチが動いたせいか、シャットダウンに時間がかかってる。強制電源Offしてワークショップで起動しないのは避けたかったので、そのままバッグへ。当初が補欠だったこともあり、ちょっと慌ただしい朝での準備となった。

多少はヒントになるだろうと、「アジャイルな見積りと計画づくり」もカバンに入れた。結論から言えば、この本は今回は電車の中での予習としては役に立たなかったかな。やはりというと変だけど、アジャイルのしかもテストに関する実践主体のワークショップを前にパラパラ見るような本ではない。今回のワークショップがシステムテストなりブラックボックス系のテスト主体の話だろうとのことは分かっていたので、その視点での予習にはあまり役立たなかったという意味。「実践アジャイルテスト」はホワイトボックス系のテストの話だし、自分的に実践とも少しかけ離れている感じがしてるし、、、。皆も手探りのように思える。

ちなみに、電車の中で、お受験風の親子連れが乗り込んできて、なんか問答してる。それなりに大きな声だったので、そっちに気が行ってしまった。社会の工業地帯のお勉強だった。結構暗記してる子だったけど、佐世保で有名なのが“笹かまぼこ”との返答には苦笑。そんなこともあって、予習は実質ゼロ。

少し早めに会場の最寄り駅に着いたし小腹が空いていたので、丼屋へ行ってから会場に向かった。会場はオラクルさん。(オラクルさん、会場提供を含め色々ありがとうございました。)

本来は、Zusaarでのイベントでの自分の番号をメモしておくべきだったんだけど、繰り上がりだったこともあってよく読んでおらず番号の件で少しアタフタ。係の方で調べてくれたけど。ちなみに、プレートにはTwitterアカウント名などを記載。入門証というかQRコード書かれた紙をもらって、そちらでゲートイン。

テーブルについた後は、知った人にちょっと挨拶。それにしても、周りはほとんどMac。自分のPCは、Windowsで表カバーにアップルのカラーシールを貼っているもの。無線LAN使えるとのことだったけど、昨日のうちにイーモバイルを使えるようにしたのでそちらを利用した。(自宅での悪戦苦闘の末にイーモバイルはUSB接続にしたけど。)

11時からのスタート。セッションスタートの最初に、テーブル(グループ)内で自己紹介。自分を含めて、6名。Web系の人が多かったけど、組込みとか企画系が半分という感じ。自分は、この分類ではシステム絡みの組込みかな。全体的にも、テスト系(テストが主)の人は皆無との印象。運営サイドにテスト系の人がチラホラいたけど。 

グループ内のアジャイル実践程度は、微妙にまちまちだったかな。どっちかというと暗中模索しながらやってる人が多いみたいなイメージだった。なお、この類で、趣味の話が出ると和みやすいというか、その後の作業がしやすいと実感した。趣味とその後の作業は直接関係しないけど、思考方法がある程度類推できるというか、、、。

以下、自分の感想を踏まえて様子を記載する。(ワークショップでの講演なども良かったけど、ここでは多少批判めいた記述が多くなって済みません。まっ、自分を含めての今後の参考ということで。)


その後は主催者の説明が2時間ぐらい。13時になって昼食&昼休みだった。タイムテーブルをちゃんと見てなかったし、弁当出るとは出ていたか? 一瞬、それなら丼を食べなくても良かったかなと思ったけど、13時まで続いたから丼食べてて丁度良かった。

スライドは以前30分で講演したのを利用(?)したみたいだけど、2時間でも時間が足りない雰囲気だった。足りないというか、ネタ的に色んな事が含まれてて人によっては消化不良の部分もあったかも。というのも、ソフトウェアテストでのテストレベルやテストタイプ、ISO 9126とかリスクの事にも触れており、非常に幅広い内容。

主催者によるテスト実践の話が出て、具体的で良かったと思う。ソフト開発とは別にソフトウェアテストのタスクボードを用意して進捗管理を行う方法。組み合わせテストを事例としたテスト(タスク)見積りの話も出た。ちなみにテストの複雑度を1~80としてるとかで、個人的には細かすぎるとの印象。また、話にも出たが、プロダクトオーナーの役目や開発とテスト側のやり取りでの見直しなども発生するので、ターゲットとなるソフト種や組織体の雰囲気などによって採用しやすいかが決まるように思う。

(つまり、一般化しやすい/他で利用しやすいとは言えないと感じた。なお、どんなことでも当て嵌まる話として、一般化することよりも、良さそうとの意識があるなら各自が持ち帰ってどう自分の組織体に填め込むか考えれば良い。ただし今回の件は、プロダクトオーナーや開発とテストとがあまりに密でお互いにカバーし合う状況でないと、適応が難しそうだ。そんな組織体が少ないだろうという意味。)


昼食後&昼休み後は、少しおさらいして実習へ。与えられたWebプログラムの仕様書というか概要を元に、グループでテスト計画書/テスト仕様書を作成するというもの。テスト計画書との話だったと思うけど、IEEE 829のような本来の計画書ではなくて、むしろテスト仕様書の作成だったようだ。(テスト仕様書というよりも、テストケースの集団の検討を意識しているようなので、テスト屋さんにはテストスイーツのような言葉の方が通じやすかったかも。もちろん、テスト屋さんは少なかったけど。)

Webプログラムは、作業(タスク)の追加とか変更、項目による並び替えなどが出来るもの。ただし、当初はドキュメントのみを見てテストケースを考え、テストケースを主催者・事務局に見せてOKをもらえたら、WebサービスのURLを教えてもらえるという方法。

我がグループは、最初リーダー的な人と進捗把握の人を決めた。まっ、アジャイル系とかファシリテーションの絡む実習とかでは良く行われるパターン。ただ、一応決めた(と思った)けど、明確なやり取りは無く、誰か(実質2人だったか)が残り時間を時々教えたり、リーダーはダイナミックに変わるようなイメージ。

で、ついグループ作業の最初の方で「テスト観点の説明もあったけど、テスト観点って分かりにくいんだよね~」と口火を切った。まっさらの状態でテスト項目を考えるということでは、かえってテスト観点は邪魔との考えによる。ただし形勢は不利で^.^;、2対4。4人でジャンケンをして、うち1人にこっちのサブグループに入ってもらった。

実習の前に、変更に強い/変更しやすいテスト仕様書とか、(途中からだったか)そのテストでどんなリスクが回避できるかはっきりさせた方が良いとのコメントがあった。帰宅時の電車で思ったことは後述するとして、リスクの検討は当面無視というか、シンプルなWebアプリなのでリスク検討はさほど重要でないと考えて作業した。

変更の事を言われたので、さらっと仕様を復唱して、どんな要望が出そうかを軽く検討。それで変化に強いテスト仕様にとも思ったけど、そもそも変更が具体的でなく検討も含めて我がサブグループは消化不良だったかな。(本件も思うところを後述。)

で、別のサブグループは、テスト項目をGoogleスプレッドに入れてた。こちらはポストイット。決めた時間後に「せぇの~」と見せ合いっこしたら、結構似てた。つい「あれっ、テスト観点を主体に考えると言ってたのに~」と言ってしまった。^.^; 逆に、その後は、こちらのテスト項目を追加したり、考えの相違を検討すれば良かったので作業は楽になった。GoogleスプレッドのURLをTwitterでつぶやいて、ハッシュタグ付けることで、他の人もそのスプレッドへアクセスするという方法。

実は、自分のPCではGoogleスプレッドがうまく見えなかった。ぎりぎり容量でIEは6のままにしてたせい。多少焦ったり、こんな事ならiPadを持ってきても良かったかなと思った。今回はネットサービスの利用だったので、iPadでも作業できたかなと感じた。(ただし、やはり文書作成というか文字入力や編集の手間の件があるから、iPadで実作業できたか不安だけど。)

グループ内で、変更に強くするにはとか、リスク軽減やテスト目的などを少しまとめて判定依頼へ。で判定結果は「検討不十分」。その時にリスク軽減などを言われたのかもしれないが、再検討。他に見積りなどもその時に言われたのだったか?

見積りに関しては、意見色々。そもそも積み上げ式で行くにしても、どんな技法使うかとか、それらの意見を集約させるかなども課題。プランニングポーカーみたいにしたらと(一応)言ってみたけど、反対も無かったし賛同も無し。優先順位の件とか色々用語は飛び交ったけど、うまく収束していかなかった。結局、今回の実習でテストに○○分が与えられるので、それでテストできそうかとか、それに間に合わそうとの話になった(ような、全員賛成でなかったけどその方向だった)ように感じた。

個人的には、アジャイルでのテストの見積りの話をするなら/それが重要とテスト派が言うのなら、そもそも従来のテストの人達の見積り手法を明示すべきと思う。アジャイル系というか開発系からすると、今回の簡易なWebサービス等で、テストに焦点を当てた見積りが必要か?? 開発とテストを一緒に考えて、ストーリー/ストーリーポイントを考えるのが普通だと言える。メンバー全員がそうかは不明だけど、見積りに対して消極的だったのは、テストの(厳密な)見積りの必要性そのものが理解に苦しんだからかもしれない。

それでも、リスクの検討とかテスト目的とか、それっぽい見積り結果の言い方を用意して、2回目の判定へチャレンジ。(これも、グループ内には、まだ不十分との意見もあったり、駄目なら3度目にチャレンジで良いじゃないの意見もあり。)

結果的には、実習の時間のことや、主催者のチェック担当の人の関係も(他に温情も?)あって、Webサービスの実体のURLを教えてもらった。具体的には、ハッシュタグ付きの私宛のつぶやき。(ハッシュタグで他のメンバーもそのURLを知る方法。)

2回目の判定では、ユーザーシナリオが甘いとの指摘もあった。一応テスト一覧に書いてるつもりはあったけど、グループ内で再検討。実URLを教えてもらう前後だったと思うけど、そのあたりを追加/追記や明記する格好になったと思う。

で、実URLを利用してのテスト実施。効率よくするために、グループ内でどう作業するか議論。結局、元我々サブグループの方が機能(いくつかの画面)のテスト、別のサブグループがユーザーシナリオ系をテストすることにした。我々のグループも、画面で分けたり、同一画面のテストならテスト項目の上からの人と下からの人にした。で、バグをポストイットに書いてたけど、ある人がGoogleスプレッドに入力してくれて、そちらに清書をお願いする格好になった。(それも、ハッシュタグ付きでつぶやいて、皆で情報共有。)

なお、テストしようとしたら自分のPCのIEが古いせいか、画面乱れ。ある意味バグレポート1号。^.^; 結局自分自身はテストはできず、別の人と一緒に作業することになった。

先にバグレポートって書いたけど、使用環境が明示されてないので、バグと言えるか疑問ではあった。また色々操作してたら、そもそも仕様がおかしいよなというのもいくつか出てきた。画面遷移が不自然。それらも項目によっては要望と明記したりして、リストアップした。

一応、異常値とか複数人での同時操作などもテストした。変な文字列というか特殊コード、あるいはクロスサイトスクリプティングテスト入門編みたいなテストも行った。具体的には、(手っ取り早くできた)Tabコード入力。案の定というか、おかしな挙動を発見。

最後にGoogleスプレッドでのバグ一覧を元に、皆で議論。KPT(keep, problem, try)の整理も一緒にやったように思う。もしかしたらKPTの議論は、発表後だったかもしれないけど、、、。

なんかグループの2人間で多少意見の隔たりがあって突っ込んだ意見を言い合って、どうしたんだろうと思った時もあったけど余り気にしないことにした。個人的には悪くないグループ作業。個人的な結論(システムテストとしての合否)としては、社内向けならOKと思う旨は言った。もちろん負荷試験とか、ここでできないテストは別扱い。

で、テスト結果の発表は、我々のグループになってしまった。リーダ役の人が説明して、発表の指名時に自分の名前が呼ばれてしまったし、そのせいで前へ出たらコメントを求められたので、グループ内で意見統一できてはいないけど社内利用はOKに近いと述べた。

その後に総括的な話が出て、希望者はビアアッシュへ突入。

個人的には、アジャイルとの目線では、内容が細かすぎる点が多い気もしたが、実プログラムの仕様や挙動でテストする点は非常に良かった。机上で議論してても、得られることは少ない。特に実践で役立つことが少ない。頭でっかちになるだけのことが多い。その点、今回のワークショップは、メンバーとの議論を含めて、教科書に書いてないような次元での気づきがあった。また、今回の題材になかった事項で自分なりに考えがすっきりした事項もあって、ある意味感謝。


ビアアッシュでは、乾杯や歓談の後にLT(ライトニングトークス)とか個別に質問したり質問受けたり、、、。LTでは、プログラミング言語の堅めの話やメイド衣装の超軽めの話題まで多種。まっ、アジャイルなり若い人達のコミュニティ雰囲気ムンムン。面白かった。(コミュニティには、それそれで重宝する居酒屋とか度々登場する話題などがあり、知らないコミュニティのそれらを知ったりやり取りできるとの貴重。つうか、オラクルの人と少し話したけど、コミュニティの居酒屋=実体験があると、対応なり目線が違うというのが今回の実感。まっ、人によってはたいしたこととは思わないだろうけど。)

で、歓談という状況だったので、お礼を軽く述べて、ストレートに以下を述べたりした。

1)やっぱテスト観点は分かりにくかった。

今回のメンバーや開発系の人が多いと、テスト業界的に代表的なテスト観点をいくつか述べて、このどれかで良いので考えてみてください位が良かったかと思う。ISO 9126も一つのテスト観点だろうけど、今回のような実習でほんとに役立つかは別。

さらに言えば、そもそもテスト観点って何?みたいな基本的なことを述べないと理解は難しいかもと。(と言いつつ、自分自身もうまく理解できてないというか、どうも役立つなりツールや手法に思えなかった。あくまで、すんなり自分なりの手法として役立てようという気になってないという意味。そうでないと、他の手法などもそうだけど、応用が効かないというのが持論。ただし、帰りの電車で、テスト観点に関して「そうか~」とのアイデアも出たので、掘り下げて考えるきっかけになったのは良かった。)

2)テストケースを、ばっさり削る話しもしないと、、、。

色んなテスト関連用語が出て”漏れなく”などの用語も飛び出したけど、今回のテーマのアジャイルにテストする/アジャイルなテストをするという感覚と矛盾すると言える。テストケースを削る話しもないと、なんか従来のテストの話と同じになって、聞いててメリットがなんだったか分からなくなると言える。

もちろん反論はあるだろうけど、アジャイラーの人達が本当に”漏れなく”と言われて納得するか疑問。 逆に、”漏れなく”派とそう考えないメンバーとで、(バグ発見率などを)比較するなども面白いと考える。

もちろんテストケース以外に、テストフェーズのどこかなりテストフェーズの作業/負荷分布を見直す意見を言うなどもこれに関する事項である。

他に、他グループがどれくらいバグ発見したか聞いてみたけど、一応我々の発見件数は悪くない感じだった。グループ内の話の際に、ビアアッシュで他のチームのバグ発見件数も聞いてみますねと言って、一部からは否定的な発言もあったけど。ただし、主催者側では、わざとバグを入れてたとのこと。いわゆるエラーシーディング。それは発見できなかったとのことだった。ちょっと残念。やっぱそれなりの準備をしてたんだと内心感心もした。なお、残念って書いたけど、見つからなかったことと”漏れなく”への否定的な意見とは別。どんなバグが仕組まれていたかにも依存すると言える。

(ビアアッシュなので、意見交換すると実は、、、との話もあって、自分も含めて皆さん悩んでること少なくないんだな~とは実感した。これも有意義だった理由。)


なお、LTの最後というか占めに近いところでは、テストクラスの話が出た。テストクラスと表現すべきかは??だけど。 少し酔ってきたこともあって、途中から席に座ってボーッと聞いていたけど、テストクラスの継承みたいなのをどう実装するかの話のように受け取った。そうであればニーズは分からなくはないけど、ツールに実装できても、(特にテスト系メンバーの)誰が使いこなすかも気になるところだった。まっ、本件はこっちの勘違いかもしれないので、深掘りなども当面先/実質やらないかな。


楽しい時間があっと過ぎて、お礼とか述べて解散。いやー良かった。


帰りの電車の中で、ボーッとしながら考えたのが2つ。

1)仕様追加に強いテスト計画/テスト仕様

実習の時は言ってることが理解できなかったけど、イテレーション(スプリント)への対応のことを言ってるとしたら非常に納得がいった。そうであれば、(時間の制約を除けば)演習の際に、例えば全部が3イテレーションで、第2イテレーションと第3イテレーションのテストをするようにすれば良かったかと思う。

で、仕様追加とかの表現ではなく、イテレーション(スプリント)への対応と言ってもらった方がすっきりしたと思う。演習時に仕様追加ではなく機能追加などの表現だったかも?だけど、少なくともイテレーションを意識して欲しいとの話で良かったと思う。例えば、第3イテレーションで実装されるのは、タスク情報の変更(画面追加)とかにすればいい。あくまで、イテレーション対応のことを言おうとしてたのなら。

さらに言えば、自分の中でテスト観点中心でのテスト設計が嫌なのは、これに脆いと思ってるからだろう。誰が考えても、イテレーションで追加されてくのは(ほぼ)機能。であれば、テスト区分のような事項は機能であるべきだ。少なくとも、その方がイテレーションへの対応が楽だ。

2)リスクと説明責任

演習の際に、テストでどんなリスクが低減できるか示した方が良いとの話が出たと思った。また、テストには説明責任が伴うとの話しも。ここも自分的にはすっきりしない。各テストケースでリスクを考えるのはおかしい。むしろIEEE 829の言うテスト計画書で、よりテスト全般とかその関連として明確にすべき事項である。

今回の実習のようなケースだと、「全体的なテスト計画ではリスクの検討とか説明責任に言及しますが、今回はテストケース検討なので、考えなくても良いです。(興味あれば検討してみてください。)」 みたいな表現が良かったように思う。

テスト全体とか計画レベルでリスクや説明責任を考えるのは必要だろうけど、今回の勉強はそっちではないと言える。

テスト計画なども実習での検討範疇との考えもあるだろうけど、今回のようなワークショップだとむしろ上で書いたような複数イテレーションへの対応などに時間を割いた方がメリットあると考える。


なお、上で書いた2つは、自分なりにもっと掘り下げた方が良いし、ちょっとした思いつきも出た。その意味では、実習やそれに対する(上の意見だと少し過剰とも映る)コメントも、考えるヒントになってむしろありがたかった。

色々書いたけど、実習を伴った有意義な1日だった。もし次回に同類のイベントがあるのなら是非参加したいと思う。


追記:後になって、今回のイベントの運営として、ドタキャンが多かった事が書かれたブログを見つけた。こちらは補欠から繰り上がってラッキーだったけど、運営する側からは弁当などのこともあり収支に直結する問題。勉強会のことが雑誌などで取り上げられてるけど、そんな苦労もあるとか、どう改善すべき/してるかの情報共有も必要になってるんだと実感した。

3月 10, 2013 ソフトウェアソフトウェアテスト | | コメント (0) | トラックバック (0)

2013年2月15日 (金)

ETロボコンの部門追加 今までの総括も欲しい

昨日・今日のネットニュースで目を引いたのは、ETロボコンのコンテストが2部門制になるというもの。創造性の高いロボットなり、ロボットの動作が見られそうで、楽しみが増えた感じではある。

ただし、個人的には良い機会なので、ETロボコンにおける「組込みでのモデリングって何だったんだろうか」を総括して欲しい気がする。ETロボコンの発祥は、ご存じのように2002年の「UMLロボットコンテスト」。2002年の最初はUML”のみ”がモデリングの規定だったか分からないが、長く走行時間とモデリング能力の2つがコンテスト対象となった。

組込み屋視点では始めの頃から、以下のような項目は気になった事項。

・モデリング(ツール)を利用して、走行スピードが確保できるか
・処理の全てをモデリングするのか、あるいはモデリングする割合はどれくらいか
・どの程度モデリングツールによるコード生成をするものか
・モデルとして採用されるのは何が多いか
  :

以前は走行スピードの上位入賞者とモデリングの上位入賞者が不一致だったが、最近は両方とも上位にランクされるチームが増えてきた。ただ、そのこととモデリングで高速処理が出来ることを示しているかは別。つまり、同じチームに、モデリングを考えるグループと(モデルは参考にせず)走行スピード検討のグループを設ける作戦もある。それは趣旨に反するだろうけど、少なくとも走行スピードと発表されたモデル(の該当部分)との関連が示されたことは無いように思う。

ただ、モデル(の部分)と走行スピードとの関連を示すのは難しい。ETロボコンでのパネルセッションのモデルを眺めたことがあるが、以前はユースケースの掲示が少なくなかったが、最近はシーケンス図である動作部分のロジックを示す展示が増えたように感じる。パネルでのモデルは、ロジックを示すために利用されていると考えて良いだろう。

モデルのその部分は自動コード生成している/していないはあるかもしれないが、実際の組込み開発でも良く目にする事項だ。つまり、走行スピードに関するソースコードの全部分とモデルの全部分が無いと2つの関連を示すことが出来ないが、モデルで100%コード生成してるとは限らないしモデリング100%が唯一無二でもない。

個人的には上で書いたような必要部分のみをモデリングしているのが実際的だろうけど、せっかくロボコンとして大会を開いているのなら、モデリングの割合などの統計を取っても良いと考える。あるいは、モデリングと走行の相関性を掘り下げたり、モデル→ソースや実際の走行状況の追跡を行っても良いと考える。

後の方に書いたのは結構労力が必要かと思われるので、実現は難しいだろう。しかし、せっかくの節目なので、今までのETロボコンを総括するような語論はあって良い。


追記:オージス総研のETロボコンレポートで、関連しそうなことが書かれていたので紹介。

http://www.ogis-ri.co.jp/otc/hiroba/Report/ETRobocon2012/ChampionshipWorkshopReport/index.html

2013年に向けて「キレイなモデルを評価するのはおしまい、手垢にまみれたモデルを期待」とある。

2012年は、完走率が悪かった。原因を照明とする意見が多い。また組込みならそれへの対応は当然だろうとの意見すらある。ただ後者に関しては、モデリングとのバランスで致し方なかったかも、というのが個人的な感想でもある。後追いでは誰でも言える。また、後になっての要求事項追加のように思えてしまう。

蛇足だが完走率が悪かった原因が照明であれば、それに早期に気が付かなかった大会関係者や、その対応が出来なかったことは反省として述べるべきだ。オリンピックなどだと、風速によって”追い風参考”の記録となるが、あんな感覚が欲しい。今まで大会会場では、マイクで何度も、フラッシュや赤外線の距離計測カメラは使うなと述べている。意識はあったはずだ。今後は、大会向けの”標準”マシンでコースや状況の確認を行う検討などに結びつけて欲しい。(その上で、リスク発生度を大会規定に明示されるのがよい。)

本レポートに書かれている審査委員長の弁は、完走率の低下などに絡めたものだが、今まで再試行とか方法の変更など組込みらしいモデルというか対応説明のパネルもあったように思う。その意味では、委員長の弁は一歩踏み込んだ方向性を示していて良いことだと思う。個人的に、さらに今回書いたようなコード自動生成との絡みやモデル利用率などにも、言及/総括して欲しかったというのが感想である。

2月 15, 2013 ソフトウェアテクノロジーETロボコン | | コメント (0) | トラックバック (0)

2013年2月13日 (水)

ソフトウェア肥大化の行く末

昨日・今日のニュースで気になったのが、電気メーカー「パイオニア」の人員削減。メディアによっては”カーナビなどの販売計画を見直し”となっているが、カーナビが儲かっていないのは明らかと思える。

ここ1,2ヶ月少し気にしていたのが、携帯電話のプログラム行数。IPAとかのセミナーなどで、自動車(カーナビ含む)、携帯電話、DVDレコーダーでのソフトウェア行数が対数目盛で増えていく様子が発表されてた。当時は所謂ガラケーだったと思われるが、その後スマフォになってのプログラム行数のデータがなかなか無い。iPhone(iOS)の行数とかAndroidの行数が書かれているサイトなどはあるようだが、ここで気にしているのは各社独自の部分の行数とか、修正などをやったらその行数。しかも、他のDVDレコーダーなども同様で、行数がそのまま増えていったか分からない。

ただ、察するに携帯電話は、iiOSやAndroidの採用で作成や修正行数は減っていると思われる。DVDは新商品がさほど無くて、横ばいに近づいただろう。カーナビも同様。

電機業界の不振を、DVDや携帯電話、カーナビの不振と捉えると、行数の増える例で示された分野は軒並みダウンというわけだ。以前は、半導体の集積度とか(ソフトウェア利用での)機能アップによる行数アップが言われたが、それらも結局日本の場合は不振業種になってしまった。

そう考えると、行数アップの図は、何を目指そうとしたのか分からなくなっている。つまり、議論として対応が必要そうだとは理解できたが、今となってはそれらの品目自体が売れない/利益を生んでいない。つまり、対応は無駄骨。むしろ行数が増えるとコントロールできなくなるから早めに新分野を開拓した方が良いとのメッセージを発していたら、少しは今と違った状況になったのかもしれない。ふと、そんなことすら思えた。

あるいは、利用する側も、ソフトの肥大化なり機能の肥大化を歓迎してないのかもしれない。パソコン離れも、そんなことが背景にありそうに思えてくる。


実は、ソフトウェア行数の増大の図で、他に記載してあったのが”自動車”。資料によっては”カーナビを含む”としているものもあるが、カーナビと別扱いのものもある。自動車の場合は、各ECUが連携して全体を制御するから状況が多少違う。しかし、ソフトウェア行数の肥大が続いていくのか、あるいはECUの数を増やすなどで対応するのか気になるところではある。  (ちなみに研究レベルでは、ECUの数を極端に減らそうとの取り組みもあるようだが。)

2月 13, 2013 ソフトウェア | | コメント (0) | トラックバック (0)

2013年1月22日 (火)

パッチリリースでのバグ(予防保全とバスタブ曲線)

以前「再考 バスタブ曲線」「ソフトウェアバグとバスタブ曲線」で、バスタブ曲線のことを取り上げたけど、今日興味あるサイトを見つけたので紹介。

http://blog.goo.ne.jp/plant-alpha/e/9b248baf1e47d90f75872f0ae03f0c32

プラントのライフサイクルに関する技術コンサルティングの会社の人のブログ。

7e4d0758e4854e0955d2172a7203d37c特に、その中での左の図。

偶発故障期間に、予防保全を行ったことでトラブルが発生していることを示している。また、その先の方の記述で、むやみに予防保全をすることが、逆にトラブルの頻発を招くことが示されている。


で、この現象は、市場トラブルで対策パッチを出したのに、それが更にバグを引き起こす現象に似ている。よく回帰テストが不十分だったために起こることがあるが、パッチ部分での修正にも一定確率でバグが入っているとの統計的な側面で考えても納得できる話である。

最近一定期間ごとにバージョンリリースするソフトウェアが、ポツリポツリと出てきている。本カーブを考えると、本当に市場投入した方が良いかとか、その期間が適切か再考すべきだろう。

1月 22, 2013 ソフトウェア品質 | | コメント (0) | トラックバック (0)

2013年1月11日 (金)

シナリオ作成エディタと、ソフトウェアドキュメント作成

今年の大河ドラマは「八重の桜」。鹿児島(薩摩)出身なので会津のことはよく知らないしドラマを見ることに多少抵抗があったが、映像が良いことや会津を余り知らないことでかえって新鮮に思えて、続けて見ようと思っている。

で今日改めて知ったのは、西田敏行さん演じる西郷頼母と八重の兄の山本覚馬とが、実際は2歳違いである点。(西田敏行さんは、大河ドラマ「翔ぶが如く」では”西郷”隆盛役で、当初そちらも混乱した。)

実は、年末にシナリオライター向けのエディタなどを調査した。(ソフトウェア)文書の生産性という点で、参考になる点があるかもと思ってのこと。記者用の端末なども詳しく調べた方が良かったかもしれないが、個人で手に入れるというわけにはいかないし余りにその分野のための機能が多そうで我々の文書作成とはほど遠い感じがして、フリーのエディタを主に調べた。

「執筆用ソフト」とか「 シナリオ専用のライティングソフト」とかで検索すると、フリーのソフトがいくつか出てくる。ゲームでのシナリオ作成を意図したエディタもあるようだ。ドラマや小説向けのそれでは縦書きの記述が大きな機能だが、キャラクターの特徴や性格などを別画面として(常時?)表示することが可能になっているものが目に付いた。

今回だと、歴史上2歳差だけど俳優さんは年が離れていることなどをメモとして見ながらシナリオを書いていくイメージかと思う。

ソフトウェアドキュメント作成でも、重要な機能などを別ウィンドウで開きながら作成すれば、間違いが少なくなると思った。あるいは、変更事項が分かりやすくなっている文書が別ウィンドウで見ることができるのも良い。(ここでの別ウィンドウでの情報とは、コンパクトにまとまっているものであるべきで、分厚い基本設計書とかその変更履歴を意味するものではない。あくまでその概要レベル。)

例えば、基本設計書の概要部分にそれらを箇条書きしたり、その変更が分かるようになってて、概要部分を取り出して表示できるようにしておくだけでも違うだろう。


ちなみに昔の論文や記事を読むと、ソフトウェアドキュメントに対する校正ツールをポツリポツリと見かける。自動チェックも含めて、文書化での生産性向上やいかにに文書種を減らすかの工夫が大事とふと思った。

1月 11, 2013 映画・テレビソフトウェア | | コメント (0) | トラックバック (0)

2012年12月16日 (日)

ドキュメント作成やレビューでのイライラ

最近、自分の資料作成や他人の文書レビューに参加して、ちょっとイライラ。自分や相手そのものへのイライラではなくて、文書がうまくまとまっていないとか、ロジックがおかしいと感じてのもの。「そういえば」と、とあるプロジェクトでの様子を思い出した。他のプロジェクトでも大なり小なり発生。むしろ、設計書作成や設計ドキュメントではイライラするくらいが正常と思うようになった。

どういう事かというと、ドキュメント作成時には、そもそもどうまとめるかで議論沸騰。章立てを決める前後は、どこに何を書いた方が良いか悩みが発生する。章立て(見出し)の階層レベルをどうするかも、キーポイントになる。しかも章立てしながら、新しい要望や実装に関する制限が頭に浮かんだりする。

実は、要求工学とか要求開発で、その辺りが知識体系(BOK)として明快な答えが得られるかと思ったけど、無理そうだ。要求開発とかでの妥当性確認(validation)とは、整理された要求項目がユーザ要求と合致しているかとか、ソリューションがユーザ要求と合致しているかの確認である。後者では、元々のユーザ要求というよりも、合意されたなり設計上のユーザ要求と考えて良いだろう。

ちなみに、一般的に「実現性確認」という言葉もあり、ユーザ要求に対するシステム設計が実現できるかの確認を行う。通常は、実現するためのコストなども加味した確認を行う。

当初書いたイライラや悩みは、製品開発の初期にどうのような製品にするかも漠然としている状況で、言わば実現性も検討しながら製品仕様をまとめ上げる過程での悩みである。(ITシステムだと、むしろRFP(提案依頼書)をうまくまとめ上げる作業での悩みに近い。)

小説や映画(文書としては台本というべきか)での生原稿で、いくつも朱書きがある状況がイメージしやすいかも知れない。その後、いく度も推敲を重ね、編集や校正の人の手を経る事になる。

上記で章立てと書いたが、設計とか提案依頼書の作成は複数人で行う事も少なくないので、その作業分担も関することも悩むところである。複数人での作業では、記述の詳細化レベルや表現もばらばらなこともあり、読む側にとってはそれらも気になる。(かと言って、それらの整合性のために余り多くの時間を割くわけにも行かないというのが実情だ。)

逆に、ドキュメントを小さなボリュームの文書に分割して、各々を一人程度で作成することが行われる。それぞれの文書を、それぞれレビューする事が多い。個人的な見聞きでは、大枠が決まってない状態でこれをやると、作業は進んでいるように見えても、ほとんど後々うまく行かなくなる。

設計書や提案依頼書のまとめ上げ方は、案外その組織体での大きなプロセス資産だと思うのだが、どうだろう。


蛇足1:後付でドキュメントを書くことがある。特に多いと感じるのは、システムのちょっとした変更だが実装による制限発生とか使い方での注意点の追記記述。良い例か分からないけどタイムリーなのは、2013年3月のIC乗車券の全国相互利用だろう。システム的には微細な変更だろうが、利用者に分かりやすく説明したり制限を正確に記述するには大変な作業と思われる。設計サイドで書くよりも、ライターとか品質部署の目線での記述が良いかもしれない。あるいは、設計含めたそれら複数グループの協業。

蛇足2:仕様の抜けや漏れが無いようにと言うけど、新製品の適用市場や対象ユーザの想定における抜けや漏れへの意識/(ちょっとした)対策も、結構役立つことがある。

12月 16, 2012 ソフトウェア品質 | | コメント (0) | トラックバック (0)

2012年12月 7日 (金)

ソフトウェアバグとバスタブ曲線

昨日「再考 バスタブ曲線」を書いたけど、そこで少し触れた、ソフトウェアのトラブルとバスタブ曲線に関して、、、。

ソフトウェアの出荷後/リリース後のトラブル(バグ発覚)は、ソフトウェアの経年変化がないので、終盤の故障率アップは無い。出荷直後やリリース直後は、テストが不十分だったりしてバグが発覚する。そしてバグ対策されて、トラブル件数は減ってくる。

その意味では、初期辺りは、バスタブ曲線に合致する。その後は安定して利用され、故障率ゼロに推移する。それがその商品やシステムの寿命まで続く。それが、一般的と言えるかも知れない。あるいは理想。

ただし、現実は、そうならない。

1)偶発期間でも一定の故障率

某OSを含めてセキュリティパッチのことを考えると、一定の故障率が続くと考えた方がすっきりするように思える。

ただし、ひどいのは、バグが継続するケース。そもそもテスト不十分等のままでリリース。修正バージョンを出すけど、修正ミスがチラホラ、デグレード、、、、。(製品回収やサービス停止も視野に入れた)抜本的な対策が必要なケースだ。

2)スポット的な故障発生

安定して使われても、時々トラブルが発生してしまう。(当時の開発メンバーが移籍したりしていることもあり、対応が厄介なケースになることもある。)

良くあるケースとして思い付くのは、システムでのデータ量の増大、外部記憶装置の容量不足、ログの増大などがある。

バスタブ曲線に関連したものとして、部品や機器の故障へのソフトウェアの対応が不十分で、それがトラブルの引き金になる時がある。結構対応やテストをした場合でも、複合的な故障の発生への対応が不十分だったり、想定される故障順番と異なった場合の対応ができていないことがある。後者では、故障率や部品耐用年数のデータでは、Aが故障してBが故障するという想定だったのに、いきなりBが故障するケースなど。

現用/予備の切り替えでのトラブルも、この範疇かも知れない。ただし、この類のトラブルはニュースレベルで目にすることが多いので、世間一般としては設計やテストが不十分と思われかねないジャンルである。

また、運用部門が(組織変更等で)結果的に不慣れとなり、思わぬ操作をして潜在的なバグが発覚することもある。一時的な対応として操作等で回避していたものが恒常的な対策を行わなかった&回避操作をうまく伝達できていなかった事でのトラブル発生もある。


基本的な確認を行わなかったなどは論外としても、見つけにくい/見つかりにくいケースもある。ある程度のレベルの組織体でも、時々発生する。ソフトウェアやシステムの設計やテスト、そして運用では、ソフトウェアの外部が(長いスパンをかけて)経年的に変化する事への対応を検討しておくべきだ。


追記:「日経 SYSTEMS」の2011年2月号(P52)に関連しそうな図が出ていたので紹介。”ノコゴリ曲線”。

2011___systemsp108_場当たり的な改修でトラブルが継続するし、終盤で保守が困難となることを図示している。

本ブログで述べたことは、ここでのノコギリ状態で、トゲのようなスパイクとして発生すると考えればいいかもしれない。多少地震のように、小さなトラブルが兆候として発生することもあるだろうが。なお、通常ならここでの保守困難期でのトラブルは少なく、システムとしての終焉を迎えるし、それを想定するだろう。

逆に、安定期でトラブルが頻発したり、周期的であれば、改修や元々の設計がまずいかも知れないと考えるべきだろう。また保守困難期が発生するかも知れないとして、新システムへの移行などを含め、その対応を検討すべきだろう。


追記:「ソフトウェアの経年変化がないので、終盤の故障率アップは無い」って書いたけど、そのソフトウェア(あるいはシステムと言うべきか)が使用できなくなる状況は発生する。具体的には利用しているOSのサポート切れ。組み込んだオープンソースを含むモジュールが利用できなくなるケースなども該当するだろう。また特にシステムの場合、一般的にメンテナンス契約があり、ソフトウェアはその期間まで動作することになる。

それらを考えると、ソフトウェアのバスタブ曲線は、稼働率のカーブと言えなくもない。あるポイントを0%としてX軸を稼働率100%とすると、従来のバスタブ曲線のように下に凸のカーブとなる。提起メンテナンスなどがあるのなら、想定時間に対する稼働率とすれば、トラブル無しなら100%稼働を意味することになる。

12月 7, 2012 ソフトウェア品質ソフトウェアテスト | | コメント (0) | トラックバック (0)

2012年11月 7日 (水)

機能要求と非機能要件って、ソフトウェアは与り知らないはず

今日、ネットで調べ物してたら、「機能要求と非機能要件」に関して最近書かれたページも結構多いのに気が付いた。”非機能要件のテスト”で検索しても、ポツリポツリとページがある。

前から思ってたんだけど、ソフトウェアのテストや作成の作業の中で、機能要求と非機能要件を分けるのが理解できない。ちなみに自分の場合、ソフトウェアの開発やテストの議論の際は、2つを分けることの是非は本質的ではないので話として割り込むことはしない。2つを区分する話題の部分を聞き流している。


そもそも作成するソフトに、例えばクラスを別にするなどして2つを区別することはない。テストも同様だ。良くレスポンスタイムの事を非機能要件とするけど、本来の要求事項の処理なども関係しているので、レスポンスタイムを速くする対応が1,2箇所をいじって調整できるほど簡単ではないことがほとんどだ。

むしろ、機能要求をユーザーからの要求とし、非機能要件を自社の都合などと考える方がすっきりするくらいだ。非機能要件として保守性などが挙げられることが多くて、非機能要件は多少のバグならOKとの考え方もあるかもしれない。例えば、サービスマン用の表示やログにスペルミスがあったからと言って、(昨今は)出荷NGにすることは皆無だろう。

レスポンスタイムも非機能要件とすることが多いようで、その範疇に含めても良いかもしれない。ただし、レスポンスタイムは契約なりRFPに書かれることが多くなってきている。そうなると、性能を出すことは必須。トラブルシートでも重要度は高レベルになるだろう。

なので、特にテストにおいては、機能要求と非機能要件を区別する必要はないと言える。むしろ重要度なり対策優先度において、その要求なり要件がどのステークホルダーからのものかを認識できる方が重要だ。(どのステークホルダーからかが明示的にどっかに書かれているか、暗黙に運用しているかは別として。) 機能要求と非機能要件を区別するのは、メトリクス取得メンバーがバグの分布などで利用する程度に考えていた方が良いとも言える。


ただし、非機能要件について書かれている本やホームページで、どんな要件が書かれているかは知っておいて損はない。機能要求は商品やサービスのドメインやユーザごとに異なることが多いが、非機能要件はドメインなどに依存しない項目が記載されていることが少なくない。それらが仕様書に書かれていなかったりテスト項目にない場合は、バグが多かったりバグの発見が遅くなったりすることが考えられるためだ。

非機能要件を仕様書に書かれてない項目と理解する人もいるようだけど、それはおかしい。作成するソフトウェアには非機能要件を実装しておく必要があるので、そのためにはドキュメント化しておくべきだ。該当する市場や装置で、常識的なこととして仕様書に敢えて明記しないケースはあるだろうけど。ただ、昨今のようにオフショアでソフト作成させたりテストさせたりするのなら、ドキュメントに掲載しておいた方がよい。(ちなみに、ドキュメントでなくてユーザーストリーで処理する場合は、非機能要件のユーザーストーリーで処理することになり、ここでのドキュメント記載はそれを含んでのこと。)


なお、”非機能要件”は”非機能要求”と表記すべきなどの意見もあるだろうけど、ここでは広く使われていると考える”非機能要件”とした。

”非機能要件のテスト”と大括りにせず、パフォーマンステストとか保守性テストと具体的なことで議論した方が良いだろう。その方が、それぞれの分野でのテスト技法の確立や効率化に結びつく。あるいは、”仕様書未記載のテスト”として、仕様書に書かれていない事項のテストをどうすべきかの議論をすべきだろう。個人的には、よほどの常識的なこと以外は仕様書に明記すべきと考えるが。 ちょっと気になったので、記載しておく。

11月 7, 2012 ソフトウェアソフトウェアテスト | | コメント (0) | トラックバック (0)

2012年11月 1日 (木)

「僕がアップルで学んだこと」

数年前から、時々品質関連の人と話題としたのが、アップル製品(当時だと代表的なのはiPod)の品質に対する感覚と自社製品を含む日本製品に対する感覚の違いは何?というもの。つまり、iPodを使っていると、(時々)音飛びが起きたりする。ところが日本製品だと、多分出荷NG。この違いはなんだろうかとか、判断基準をどう考えるべきかといった話題。実際アップルの製品を使っている人が少なくなくて、どう考えるか聞いたりした。

なかなか結論は見出せなかったが、アップルでの品質保証/品質判定の方法や基準は、その後も気になっていた。

左は、数日前に購入した本。著者の松井氏は、元・米アップル社品質保証部のシニアマネージャ。

実は、2,3ヶ月前とかに、本屋で手に取って見たことはある本。当時はパラパラ捲った程度だった。ところがiOS6でのアップル地図のゴタゴタをネットニュース等で目にして、色々検索。アップルの品質などの検索で、本著者の松井氏が引っかかってきた。そして、この本に品質保証部在籍当時のことが書かれていそうだったので購入した。内情暴露ではないだろうけど、ヒントになることが分かれば良いな~位の思い。

書評などでは、社内政治への対応やアップル回復のことが書かれている。それらの記載ページが多くて、品質保証絡みは所々。ただし、キーとなりそうなことが書かれていて参考になった。

品質保証部の役割は、品質を保証することではなくて、開発プロジェクトの状態を定点観測を行うということ。[P82] テストを行ってバグ分析をし、その製品がどの程度出荷可能レベルに近づいているかを測る。

バグ修正は重要度の高いものから行い、優先順の議論に時間が費やされることもある。[P79] また意見として、過剰品質を求めていないとの記載もある。[P84]

個人的には納得だし、優先順位の議論とかは知り合いなどの自分の回りで良く聞く話で、理解しやすい/当然と考える。

なお他に、マニュアルを少なくしたり無くしたこと[P69]や収益に対する研究開発費が2.3%と低いこと[P77]、デザインでブレが無いことと細部での変更とが書かれている[P64、P78]。

ちなみに、品質保証部門を担当した時の、メンバーの惨状の様子[P109]や整理整頓に心がけたエピソード[P112]に触れている。


先頭の方で記載したiOS6でのアップル地図問題は、iOSの開発統括のスコット・フォーストール上級副社長が来年退任するとのニュースで落ち着いた感じだ。代償が大きくなった。

実情は分からないが、松井氏が退社したことで、P109に述べてあるような惨状に戻ったのかも知れないとふと思った。また松井氏自身、今回のアップル地図問題をどう考えるか、彼のブログなどを注意しているつもりだけど書かれていない。(今は)書きにくいとか、書くべきではないとの判断かも知れない。 個人的には、アップル地図を出さざる終えない事情があるように思えて、申し送り事項(例えばαバージョン扱いにするとか)として明言などで対応する方法もあったように考えるのだが、、、、。

いずれにしろ、アップルを知る上で、個人的には読んで良かったと感じた本だ。


追記:以下の松井氏とのインタビューで、アップルも出荷判定会議をやってるとか、そのリハーサルの準備をした逸話が書かれている。

http://www.cyzo.com/i/2012/07/post_11040_3.html

11月 1, 2012 書籍・雑誌ソフトウェア品質出荷判定ソフトウェアテスト | | コメント (0) | トラックバック (0)

2012年10月26日 (金)

Japan IT Week 2012秋

今日は、「Japan IT Week 2012秋」の展示会見学で、幕張メッセへ。

同じ「Japan IT Week」の春のイメージを重ねすぎていたせいか、会場が狭いし個人的に気になっていた分野の展示が少なく感じた。気になっていた分野は、例えばクラウドインフラ。開発環境とかに関しては、春には「ソフトウェア開発環境展」としてあるけど、秋にはない。気が付いてはいたんだけど、春での招待状と似たような形態だったこともあり、少しは開発環境系の展示があるかもと思ってたがやはり皆無だった。

(コンパクトにまとまり展示内容ががらりと変わるのに、自分の頭が追従できないこともあった。各ブースも少し小さく感じて、見落としたりもしたようだ。特にトヨタマップマスタースの展示があったのに帰ってから気が付いて、少し惜しい事をしたと反省。トヨタマップマスタースは、ナビ絡みで少し気にしていた会社である。)

今回の秋での開催は、「クラウドコンピューティングEXPO 秋」、「情報セキュリティEXPO 秋」、「Web&モバイルマーケティングEXPO 秋」「スマートフォン&モバイルEXPO 秋」、「データセンター構築運用展 秋」「ビッグデータ&データマネジメント 秋」。後の方の2つが、今年の秋から追加された展示だ。

ちょっと面白く感じた展示をいくつか。(聞き違いや勘違いはご容赦。)

・タブレット型POS

いくつか展示があった。特に小型プリンター企業での展示が少なくなかった。クレジットカード読み取りを備えているものが多かった。その読み取りカード種(というかセキュリティレベル)へ対応とか新しいスマフォへの対応など、この分野も技術革新や競争が激しいと実感した。

・M2M関連

スシテナという会社がM2M向けの、モジュールやプラットフォームの展示をしているのが目に止まった。

・iD Lens/lD Broser

ナント・モパイルという会社が展示していたもので、スマフォなどでの物体認識。予め登録したもの(装置名とかバッグ名とか、、、、)と同じと認識したら、その名称をカメラ画像に重ねる。うまく説明できないけど、面白い応用が考えられそう。

・サイボウズのグループウェア kintone

企業間にまたがるコミュニケーションのためのクラウドツールと考えれば良さそう。従来のサイボウズOfficeは社内向け、kintoneは他社とのやり取りとの利用の棲み分けが考えられる。タブレッド端末やスマートフォンでの利用を意識していたり、いくつかアプリが用意されている。

・セキュリティや監視のツール

どちらも色んな種類があったり従来とは違う会社からの出展も少なくなくて、差異などを明確には掴みきれなかった。監視ツールについては、グラフィカルに問題部分を分かりやすく示す工夫などが進んだように感じた。

また当然、スマフォに絡むセキュリティや監視のツールの展示が多くなってきた。

・動的テストツール

ハートランド・データというところの「動的テストツールDT10」の展示があった。製品自体は以前からあった?

・BI関係

想定していたよりも、(新しい?)技術展示は少なかったように思った。


以上。

10月 26, 2012 ソフトウェア | | コメント (0) | トラックバック (0)

2012年10月17日 (水)

趣味の世界の技術革新

技術系会合の後の情報交換会・懇親会で、話題となるのが趣味の世界での”情報”などの技術の浸透。”情報”分野だとIT技術といっても良いだろうけど、ITと言うとエンタープライズ系とも捉えられちょっと違う。

案外というと変だけど、素材関係の進歩もすごい。防寒や防水、軽量化のための素材が進化している。ゴアテックスは結構昔から有名だけど、軽量化や発汗への作用などきめ細かくなっている。登山向けのシューズの紐で使われてるサロモンのQuicklaceもある。Quicklaceは非常に頑丈な糸(?)でペンチとかでないとちぎれない。ストッパーを使って結び位置を調整する。軽量化の最たるものは、カーボン。自転車のフレームなど色んな所で使われている。

ちなみに、技術記事としてネット記事とかの登場が少ないのは、同じ趣味でないと興味をそそられなくて読者数が少ないとの読みかと思う。また、書き手がその趣味でないと書き辛いし、仕事と趣味は別との考えが普通なので仕事に趣味の話を持ってくる抵抗感はあるのかもしれない。さらには、学校の先生などの教える立場となると、さらに扱うのに気が咎める事もありそうに感じる。これは、情報分野もそうだし、素材などもそうだと考える。

さて、情報分野の趣味分野での利用の筆頭は、GPSやランナーチップの利用だろう。

ランナーチップは、マラソン大会などでランナーが靴に装着してレースを行う。特定の箇所にマットを含めた計測装置を置いて、そこでの通過時間を各ランナーごとに測定する。関門での通過チェックや、(号砲からでなくて)スタート位置からゴールまでの実時間(ネットタイム)を計測して、参考として結果に記載することも行われている。計測作業の効率化に繋がっているし、大人数の大会開催にも役立っている。

ランナーチップは、マラソン大会以外でもトライアスロンやオープンウォーターの水泳大会でも利用されている。以下で、ランナーチップの形状や機能などが一覧で表示されている。

http://runnet.jp/runtes/chip/

で、GPS利用の件。以下のNike+は、有名。スマフォなどを一緒に持ち歩いて、走ったコースなどを公開できる。


http://nikeplus.nike.com/plus/products/gps_app/#get_the_software_section

知り合いなどからその人のコースなどを教えてもらって見ることは多いけど、ここで書こうとサンプル的なものを探したけど、すぐに見つからず。身近な人へ公開とのケースが多いからだろう。とりあえず以下辺りを参考のこと。

http://www.yuznak.jp/yodan/blog/2012/07/29/nike-run-club%E3%80%80%EF%BC%94%E5%9B%9E%E7%9B%AE/

他のGPS利用のソフトなりサービスでも同様だけど、コースや高低差、スピードなどを表示してくれる。

Nike+のシューズに付けてiPodやiPhoneで情報を蓄積するもの。

Nike以外の靴でも可能かと思われたが、Nike+の靴は、このチップの取り付け用のくぼみがあるそうだ。他のメーカーにはないし、サードパーティから他のメーカー用のための(靴のベロなどに付ける)グッズも出ているようだがやはり誤差があるようだ。(Nike+の靴でも誤差は多分発生するだろうけど。)

Nikeにあるなら日本のメーカーにもあるかもと調べたら、アシックスのサイトに以下があった。


http://www.asics.co.jp/running/myasics/

こちらもiPhone向けのアプリなどを用意してある。

さらに、アディダスの動向を調べたら、”miCoach”なるものがあり、心拍数や距離などを計測するようだ。

http://adidas.jp/mi/micoach/product/aboutmicoach/

サッカースパイクへの応用が、以下や日経エレクトロニクス 2011年11月14号に書かれている。

http://www.dgfreak.com/blog/2011/10/20111025adizero-f50.html

”miCoach”をユニフォームに付けて、公式試合で利用することになってるという記事が以下。

http://pc.nikkeibp.co.jp/article/news/20120416/1046167/

どんどん進化しているといった感じ。ただし、選手の位置なども分かるのかと思ったが、(勘違いかも知れないが)それは無理みたい。また、そこでのデータが一般に公開されていないのかと調べてみたが見つからなかった。一般の人達でのmiCoach利用のログも同様。一般の人達の利用ログはあっても良さそうだが、そちらも見つからない。位置情報と比較すると、見栄えなどが無いことや相対的に普及していないのかも知れない。


旧来の教科書や情報家電などでの情報分野の利用からは、なかなか発想しづらい分野なのだろう。特に日本人としては。スマートフォンなどで”遊ぶ”みたいな発想がないと、これら趣味での情報化の製品やサービスの提供を思い付かないと言える。何となく、そんな発想の貧弱さが、これらの分野での情報化に立ち遅れた理由かもと思うこの頃だ。

10月 17, 2012 スポーツソフトウェアテクノロジー | | コメント (0) | トラックバック (0)

2012年6月11日 (月)

要求? 要望/要求/要件?

2月ほど前の会合でのテーマは「BABOK」。そこでの講演者のスライドに、要望、要求、要件の記載があった。3つを少し区別して述べたもの。なお、会場からの質問で、BABOK(あるいは英語圏)では要求も要件も同じ requirement としているとの回答はあった。その回答自体は正しいし不満はなかったけど、懇親会では少し突っ込んだ話をしようと思っていた。でも、懇親会では別の話題で盛り上がってしまい、次回に会ったときでもいいやと考えていた。

ところが最近、自分の写真などの公開方法で少し悩む事が発生した。どんなWebサービスを利用すれば良いかの検討で、四苦八苦。とりあえず形になったのは自分のブログ(「トレランコース 弘法山~大山 GPSログと写真整理」)に書いた。

自分の要望としては、、、、。 

 ・写真/GPSログで一般公開にしたいのもあるが、別の写真は知り合いだけに公開したい
 ・知り合いにはインターネットに疎い人もいるので、その人達もアクセスできる方が良い
 ・写真の説明追記やスライドショー化は、Webサービス上で行いたい
 ・GPSログが再生でき、写真も各々を見るのとスライドショー再生を行いたい
 ・写真のスライドショーでは、バックの音楽をつけたい
 ・写真のスライドショーではスピードを変えることや説明も一緒に表示させたい
 ・写真のスライドショーでは、GPSログ上のスピードに応じて各写真の表示時間が変わるのが良い
 ........

実際のWebサービスを探すけど、なかなかぴったりのがない。そもそも技術的にFLASHを利用している段階で、携帯電話やiPadからの閲覧が不可。(工夫すれば出来るけど、今回のメンバーには酷。また自分としてもそのためにiPadにFLASH再生環境を入れようとは思わない。)

実際に良さそうなWebサービスを試してみると、不満な点も見えてきて、また別のWebサービスで実験、、、、。そんな繰り返しだった。

思うに、自分自分の要望の優先順位が整理されていない。しかもその優先順位が、実際のWebサービスでダイナミックに変わっていく。そのため、つい2ヶ月前の会合のことを思い出した。

やはり、要望は要望、要件は要件、要求は要求として管理した方がよいと言うこと。要求との言葉で統一したとしても、タグやフィールドを設けて、3つのく別が分かるようにすべきという意味。あるいはもっと細分化したり、どのステークホルダーからの要求かを識別できるやり方でも良いかもしれない。(自分の経験や他の人の話でも、大なり小なり実施していた人達が少なくない。BTSで管理するケースが多い。)

いくつかの要望をひとまとめにして要件化するようなこともある。例えばいくつかの要望を設定ファイル化して、複数のユーザへも対応できるようにするなどである。

また、実装の検討に伴い要望が分割され、分割後のそれぞれの優先順位が異なってくる現象もある。あるいは実装の関係で、ユーザ要望が変わっていくことが少なくない。場合によっては、コストで要望を断念、極端には「止~めた」となる可能性もある。従って、要望や要求のトレースや、優先順位などの変化に応じた対応が必要になる。(実際、今回の具現化で非公開の方は断念した。従来行ってた写真共有のみにし、宴会などで必要に応じてiPadでのスライドショー再生を行うとした。)

今回の検討は自分の要望から適切なWebサービスを探すことだったが、一部を自分でとかAPIを利用してシステム化を依頼するとなったら、さらに検討すべき事が出てくる。その中には、WebサービスやAPIの変更もある。Webサービスの中止や、以前と操作性や機能が大きく変更されることが珍しくない。せっかく作っても動かなくなることも想定される。


実際のソフトウェアのシステム設計や実装などでの、要求管理の課題が見え隠れした。自分の要望の具現化で、ふとそんなことを再認識した。

6月 11, 2012 ソフトウェア | | コメント (0) | トラックバック (0)

2012年6月 7日 (木)

東京スカイツリーの成長曲線

東京スカイツリーが営業開始して、しばらく経ったが、自分の属するコミュニティで東京スカイツリーの耐震や建築確認申請の変更などが話題となった。特に工事中の610mから634mへの変更。

で、その関連で調べていたら、公式とも言って良いページに日付とツリーの高さが記載されていた。大林組のページ。

http://www.skytree-obayashi.com/pointview/index.php?point=1

ビルの高さも、ある意味では”成長曲線”。普段ソフトウェアの世界での信頼性曲線のことは気にかけているので、それとの対比してみようと考えた。日付と高さを表形式にしてグラフ化したのが以下。

https://docs.google.com/spreadsheet/ccc?key=0At5_RJyc2TPhdEZlUXB5R21TRE8yMFpsOHQtVzJmVUE

多少意見あるだろうけど、一次曲線に近い。心柱作りや上部のアンテナ鉄塔引き上げでも、高さが急成長していないように思える。高精度が要求され、当初からの想定だったのかもしれない。

また、2010年の6・7月では高さ成長がストップている。これは(多分)、第1展望台に関する工事とさらに上の工事のためのジャッキなどに関する工事が関係したのだろう。


以前、本ブログでバグカーブ 対数曲線や二次曲線での近似のお勧めを書いたけど、高さや信頼性をコンスタントに成長させる意識の方が考え方として適しているような気がする。成長曲線になったりするのは、あくまで結果との割り切りの方がよいだろう。ふとそう思った。

6月 7, 2012 日記・コラム・つぶやきソフトウェアテクノロジー | | コメント (0) | トラックバック (0)

2012年5月 9日 (水)

Japan IT Week 2012春

今日は、「Japan IT Week 2012春」のショー見学で,、東京ビッグサイトへ。

以下のいくつかの展示が一緒に開催。

・ソフトウェア開発環境展(第21回)
・データウェアハウス&CRM EXPO(第17回)
・組込みシステム開発技術展(第15回)
・データストレージEXPO(第14回)
・情報セキュリティEXPO春(第9回)
・RFIDソリューションEXPO(第7回)
・ダイレクトマーケティングEXPO(第6回)
・Web&モバイル マーケティングEXPO春(第6回)
・データセンター構築運用展(第4回)
・クラウドコンピューティングEXPO(第3回)
・スマートフォン&モバイルEXPO春(第2回)
・ワイヤレスM2M展(第1回)

東館、西館(しかも2階も)を使用しての開催で、規模が大きくなっていく感じ。IT系(Web系やクラウドを含む)の展示が増えて、組込みシステム開発技術やソフトウェア開発環境展が少し異色に思えてきたし、「ソフトウェア開発環境」の展示意図が少し曖昧になってきたように思う。2,3年前までは、開発環境としてプロジェクト管理関係の展示があったが、少なくなったとも感じた。

Salesforceでの展示では、色んな会社がSalesforceを利用しているのが分かり参考になった。コンビニとかで目にするサービスが、実はSalesforceを利用していたなど。

データセンターの展示では、CD等での長期保存の展示が多くなった。

ソフトウェア品質関係では、ISO26262に向けての開発支援サービスがいくつか。スマフォを含めたテスト自動化や複数機種へのテスト対応の展示もいくつか。

M2M展は初めての展示だったし西館の2階で人が少ないかなと思ったけど、それなりの人。NECの展示が目を引いた。地震測定ソリューションの展示を行っていた。(異音検査ソフトウェアなるものの展示もあったけど、今は工場ラインでの異音検出の用途のようだ。)

M2M展でだったと思うけど、微生物燃料電池なるものの展示もあった。


ついついカタログをもらってしまった。やはり重い。宅配便を利用する手段もあるけど、今回は少し勿体なくて利用しなかった。カタログは、帰ってからスキャン。会場で電子ファイルでもらうなどが出来ればいいかと思うんだけど、難しいんだろうか。

こんなものまでクラウドを含めてWebサービスがあるんだ~と思うものがいくつかあり、参考になることが少なくなかった。ただ会場が広いし出展が多いので、来年とかは少し絞って見学したい。

5月 9, 2012 日記・コラム・つぶやきソフトウェア | | コメント (0) | トラックバック (0)

2012年4月21日 (土)

コンビニでA3スキャン

自炊/他炊で少し悩んでいるものはいくつかあるが、A3サイズのスキャンもその一つ。本とかなら他炊でのサービスを行うところも少ないものの存在するが、プリントしたりのシートタイプの扱いが悩みのタネ。手ごろな価格では、自宅のがそうだし、一般的な家庭用向けではA4サイズが最大。なのでスキャンできずに残ってた。折りたたんでスキャンした後に接合する機能があったりするけど、その後の文字認識精度などで使うことは限定的になってる。

ちょっと都内ならスキャンサービス店があるようだけど、近くの横浜のFedなどではやってないようだ。昔みなとみらいのTSUTAYAでやり出したニュースを目にしたけど、最近は案内から無くなっているようだ。また、印刷を意図したサービス店もあるようだけど、ネットも含めて遠い所がほとんどだしそもそも価格がべらぼうに高い。

ドキュメントの整理でA3でスキャンすべきものが溜まってきて、そろそろとの意識で再調査。すると、コンビニでスキャンできるところがあると出てた。サイトによってはファミマでもやってるとの記載も。ちらっとセブンイレブンでのサービス方法を見て、今朝早朝に散歩がてら出向いた。(早朝でなくてても良かったんだけど、最初の利用で操作に手間取ったりしたら悪いと思ってのこと。)

近くのファミマでは、スキャンがメニューに出てない。稀にコピーで利用してメニューで見かけたこと無かったので、案の定との思い。少し離れたファミマでも同様。で、その先にセブンイレブンがあったので、そちらへ。メニューに出ていて、ラッキーとの思いだった。ちなみに、セブンイレブンでの、スキャンサービスに関するページは以下。(「詳しい操作」を事前に読んどけば良かったと後になって感じた。)

http://www.sej.co.jp/services/scan.html

最初どこにUSBを差すのか分からなかったけど、マルチコピー機の隣上にPCのようなのがあり、DVDやUSBの差し込み口群にプラスチックカバー。開始して確認などを操作すると、そのカバーが動いてUSBなどを差せるようになってる。後は画面に従って操作するだけ。最後に縮小的なイメージで画像を確認できるのも良い。完了でコイン投入して、USBを抜いたらまたカバーが動いて差し込み口群に被さった。

ちなみにPDFにしたけど300dpi固定だったと思うし、OCR機能は処理されてなかった。画質とかはまっそんなもんだろうといった感じかな。(自分の今回のは、A3の16ページで27MB。) むしろ個人的には、A3での折り目を元に戻すようにしたり少し厚めの紙などと一緒に押さえとけば良かったかなと反省。

他に思ったことは、、、。
・ADFじゃないので、ちょっと手間。まっ、こればかりは仕方ないかな。

・1ページ読み取った後の画面操作で、読みとりOKで「これで設定」ボタンが表示されて、その次に継続しようとすると同じ位置に同じような色で「これで設定 終了」といったボタンが表示される。連続してスキャンする時に、つい終了をタッチしそう。後者でのボタンの位置などは工夫が欲しいかな。

・画像を確認したら、定位置に霞んだような何かが。ガラスが綺麗になってなかったようだ。USBなどの媒体と一緒に拭くためのものを持って行った方が良いかなと思った。ひどくはなかったけど、その後でのOCRなどの修正の手間などに影響する。


いずれにしろ、A3スキャンは目処が立って一安心。

4月 21, 2012 技術ソフトウェアテクノロジー電子ブック | | コメント (0) | トラックバック (0)

2012年3月23日 (金)

単体テスト/コンポーネントテスト、、、、、

ソフトウェアテストでのテストレベルの用語(の統一)は気になっている事項だ。ISTQB/JSTQBでは、コンポーネントテスト、統合テスト、システムテスト、システム統合テストなどがシラバスなどに記載されている。

ところが、自分の最近目にするソフトウェアテストに関する記事や論文では、単体テストや結合テストが増えてきた気がする。(開発系では、以前からほとんど単体テストや結合テスト。)

ソフトウェアのISO化などもあり、ちょっと気になって調べたり、確認してみた。まずソフトウェアテストのISO化に関しては、以下が公式的だし、まとまっていると思う。

ISO/IEC JTC 1/SC 7/WG 26の概要 http://www.itscj.ipsj.or.jp/tutorials/tu87.html

そこでの(2)に書かれている”テストレベルを特定しない”ことから、テストレベル自体の明示も行われないような気がしてきた。あるいは、他のISO程度しかレベル分けしないと思える。

そうなると、ソフトウェアの開発なりテストのプロセスは、ISO/IEC 12207 (JIS X 0160)を踏襲すると思われる。ISO/IEC 12207では、ソフトウェア詳細設計、ソフトウェア結合、システム結合、ソフトウェア適格性確認テスト、システム適格性確認テストという用語が明言されている。他に”コードの検証”という用語もある。ちなみに、”Integration”を”結合”と訳している旨が明記されている。

そうなると、テストレベルとしては、単体テスト、結合テストが、ますます定着するように思える。

ちなみに、Googleで”単体テスト”等での検索結果件数は以下。”ユニットテスト” が多いのは、xUnitの関連だろう。

 ・”ユニットテスト”     415000件
 ・”単体テスト”       323000件
 ・”コンポーネントテスト”  14800件

JIS X 0160の頃でも、ソフトウェア開発でのプロセス用語が各社各様で統一に役立つとの記述もあったが、結局そう統一されたわけでもない。また、規格では細部を決めたり例示することを避けている感がある。組織体では、効率や品質向上にためにプロセスを細分化した呼称を用いたりするが、ISOなどはそれをフォローしていない事になる。むしろISOやJISは、ソフトウェア開発/テストのキーの部分から、より広範囲を含めたライフサイクルやプロジェクトの規格化が進んでいる気がする。

組織体で細分化したプロセス呼称を用いる場合もあろうが、企業間での統一は考えにくいと割り切った方が良さそうだ。ただし逆に、他社との情報交換の際には、用語の確認をした方が無難だろう。


個人的には、JISの規格内で単体テスト、結合テストを用語として明示して欲しい気もする。(ただし、こちらが単に知らないだけかも。) また、自分としてはコンポーネントテスト/統合テストという言い方に少し慣れていたが、今後は単体テスト/結合テストを用いることが増えると思う。

3月 23, 2012 ソフトウェアプロジェクトマネジメントソフトウェアテスト | | コメント (0) | トラックバック (0)

2012年3月17日 (土)

画面変更と仕様変更

早朝のテレビ東京「モーニングサテライト」は、結構見ている番組。そこでの表示方法が、今年になって若干変わった。

20120316_左は昨日(16日の放送)での、ニューヨーク株式の値動きの画面など。

http://www.tv-tokyo.co.jp/mv/nms/market/post_17307/での画像だけど、画像圧縮を高めてる。

青っぽい画面で”ダウ 1日”と書いてあるが、昨年までは日付だった。つまり、以前だと前日のダウなので”ダウ 15日”と表示された。日本株式とか為替なども同様。

今年になって表示を見て、システムのトラブルかと思ってしまった。つまり表示に関する日付更新がされてないと。多少日を置いてからだったけど、Twitterに書いたりモーニングサテライトでの問い合わせから投稿したりしても反応無くて、なおさら不可解に思えた。

2月になっても変わらないので、おかしいな~と思いつつ。どうも日付ではなく、期間(1日分)を示すように変えたのかもしれないと思うようになった。そうだと悪くはないんだけど、日本が祝日で向こうの市場が開いてる時にどちらの日か分かりにくいことはある。それよりも日付/期間の表示部分を固定的に出来るので、手間が少なくて済む方を採用したのかもしれない。(1月放送の冒頭で、表示変更のアナウンスがあったのかもしれない。ただそれでも、投稿等での反応で教えてくれても良いのにとは思ったが。)

これが良い例か分からないけど、システムのテストなどで、画面変更が仕様変更なのかトラブルなのかと悩む事は少なくない。リリース前に、変更部分をアナウンスしないなんていう考えられない事もあるようだし。その度に、再試験とかバグ表の発行とか、仕様確認とか無駄な作業が発生するのに懲りないみたい。

また昨今のWebサービスでの画面変更は珍しくないし、新旧画面の切替をユーザーが行えるようになってるケースも多い。操作性が悪くなることは少なくないし、トラブルかと悩むことも時々発生する。

画面変更に対するアナウンスは、多少手間でも行うべきと再認識した次第。

3月 17, 2012 ソフトウェア品質 | | コメント (0) | トラックバック (0)

2012年3月16日 (金)

ソフトウェア開発での進捗の可視化

昨日の「プロジェクトマネジメント学会 2012年度春季」で触れた、ソフトウェア開発でのスケジュール進捗の可視化の件。

プロジェクト管理でのイナズマ線や達成率で進捗を示すことは行われているし、バーンダウン・チャートを用いることも多いだろう。ただし、ここで考えたいのは、ソフトウェア全体でのどの部分が終わってるかの図示化。一昨日の学会での講演だと、配管の3次元表示がスケジュールと一緒に示されたが、ソフトウェアが2次元とか3次元で示されれば言うこと無し。

2次元表現としては、クラス図などが考えられる。ただ、スケジュールでクラスをどう表現するかとか、ツール間の連携が気になった。色々調べたりしたけど、良い考えが思いつかない、、、、。

でふと、スケジュール→チケットと考えると、すっきりしてくるように思えてきた。チケット系のツールと、リバースエンジニアリング系(も機能に持つ)のツールで、連携できるものがある。

なお、全体をプロジェクト管理ツールで行っている場合は、WBSレベルでの情報をチケット情報から引っ張ってくる/作成するやり方が良さそうに思う。つまり主体をチケット系ツールにする。機能実装やテストの進捗とかバグ対策の進捗まで含めた可視化では、チケット情報の方が的確だからだ。(ただし、工数検討などではプロジェクト管理ツールの方がメリットあるだろうから、使い分けを行うだろう。)


結構すっきりして、一人ご満悦状態。

3月 16, 2012 ソフトウェアプロジェクト管理出荷判定 | | コメント (0) | トラックバック (0)

2012年3月11日 (日)

統合テストはフォーメーション練習?

以前から頭の隅にあったのが、統合テストをどうイメージした方が良いかということ。JSTQBでのテストレベルとして、コンポーネントテスト、統合テスト、システムテスト、システム統合テストという用語がある。一般的に使われている単体テストがコンポーネントテストに、結合テストが統合テストに該当するだろう。(ただし、企業やプロジェクトで、そうとも言えないこともある。)

各モジュールのソースに対するテストとしてコンポーネントテストがあり、全体のテストとしてのシステムテストがあることはイメージしやすい。しかし、用語としての統合テストは理解していても、実際のテストでは解決すべき課題が出てくる。

例えば、Aという人なりグループがA1、A2、、、、というモジュールを設計/コーディング。Bという人なりグループがB1、B2、、、、を、Cという人なりグループがC1、C2、、、、を設計/コーディングしているとする。ここでCは、汎用的なモジュールとする。

そんな時、A1とC1やC2との結合テストを行うか? 行うとして全ての組み合わせを行うか。また、AとBに関係し合うモジュールがあったら、それも全組み合わせテストを行うか、、、、。そもそもAとかBの中での統合テストを行うかなどである。(場合によっては、AとかBの中でのテストを、統合テストと呼ぶかも組織体やプロジェクトで異なるかもしれない。)

机上では全組み合わせテストを実施すべきだろうが、実際にそのようなことは行わない。(少なくとも自分の経験では。) そうだとして、統合テストをどうイメージしたらいいかが頭に隅にあった。


で、春になって、野球のキャンプとかを目にして、スポーツに例えるのが分かりやすいような気がしてきた。つまり、コンポーネントテストは、バッティングや守備などのある意味単純な練習。システムテストは、実際の試合。そうすると、統合テストは、フォーメーションの練習かなと。

バスケットやバレーボール、あるいはサッカーなどのチーム競技でも似たようなものだろう。水泳や陸上競技だと、リレーが近いかもしれない。走/泳順に応じた練習が統合テスト。走る順番や、走者/泳者を誰にするかで組み合わせが増えてくる。

フォーメーション練習では、メンバーの組み合わせを含めて、そう全部の練習をする訳じゃない。試合が近づけば、より実践的な練習にしていくだろう。

結局統合テストも、どの組み合わせをテストするかとか、全体テスト(システムテスト)に向けてのテストを意識すべきだろう。日程との調整や、そもそも統合テストの期間見積りが重要なのは言うまでもない。統合テストのためのダミーモジュール/コンポーネント作成の手間が膨大になりすぎては本末転倒でもある。

統合テストの際に、視点として機能に着目するのがよいと考える。ソフトウェアの単純な結合というよりも、機能テストとの視点。システムテストの前段階にもなる。以前、ここのブログの「”スクラム”の原典「ラグビー方式による新製品開発競争」」でフェーズの重なりに触れたが、PMBOK4版(日本語版ではP21)でもプロジェクトマネジメント視点でのフェーズ重なりの図が示されている。コンポーネントテスト→統合テストとフェーズがばっさり区切られるよりも、2つが重なっていたり、機能実現が追加されるイメージがよいだろう。

また、スポーツの場合に基本的な練習も交えながら試合/試合前に臨む事も、対比的に参考にすべきかもしれない。つまり、必要なコンポーネントテストや統合テストを継続していくことへの意識である。(当然ながら、自動化などで効率的に行うべき。)

参考になるか分からないけど、自分では良い見方と思えている。

3月 11, 2012 ソフトウェアソフトウェアテスト | | コメント (0) | トラックバック (0)

2012年3月 6日 (火)

路線バスの時刻表とモデリング

モデリングの話は勉強としては必要(必須)なんだけど、実際のシステム化の際に、モデルが段々崩れていったり醜くくなってくことは良くある。なるべくすっきりしたままにするのが、交渉力だったりするけど、、、。で、今日そんなことを強く感じた事例に遭遇。

趣味で、トレラン(トレイルランニング)に行くけど、結構悩ましいのがバスの時刻。電車だと経路検索のソフトなどで判明するけど、路線バスは困ることが時々ある。特に奥多摩方向での西東京バス。携帯電話での検索でも、他と比べたら、結構操作が面倒に感じる。1時間に1本とかはザラなので、帰りのバスの時刻で別ルートのいくつかを検討するからだろうが。

Tominnomori_2今日知ろうとしたのは、武蔵五日市駅から、数馬や都民の森というポイントへのバス。行きと帰り。

http://www.nisitokyobus.co.jp/rosen/tominnomori.htmlでの時刻表を画像化したものが左。ここでは時刻そのものが重要じゃないので、画像的に細部が分かるようにはしてない。

そもそも、日によって運行するものとそうでないものが多い。グレーの所は、都民の森までは行きませんと言う意味。白+黄色部分は、都民の森に行くけど、黄色部分は運休する時がありますという意味。運行する日が、表の上の方に書かれている。

経由地が3種類あって、急行と普通、都民の森に行くのに乗り換えるのと乗り換え不要とがある。当然、平日と土・日のダイヤの別も。

人間だと、予定している日にちを前提として、この表から探し出すのかな。ただし、この表の情報を元に、出発地と到着地、そして利用日を入力して運行時刻を表示するアプリケーションを考えると、データの持ち方や処理がそこそこ複雑に思える。あるいは、すっきりしない。また、そもそも利用日を入力するのは操作的に良いとも言えない。つまり、デフォルトを当日としたり、土日も直近の土日がありがたい。結果の表示でも到着時刻だけじゃなく、急行かどうかは当然として、乗り換えするのかは判明した方がありがたい。実装時には、他の時刻表のデータ(データベース)との整合性とか連携をどうするかも悩ましそうだ。


経路検索のサービスで、路線バスまで含めているのが少ない訳が分かった気がした。なお今回の事例での運行時刻表示するアプリケーションの必要性は微妙だけど、一般的にも単純なデータ構造にならないケースは少なくない。設計としては単純なデータ構造やロジックにしたいけど、実際の運用がそうでないケース。モデリングの勉強と同時に、そう単純にならないケースへの対応の勉強も必要だろうにと考える。


(念のためだけど、奥多摩に行った時には西東京バスにはお世話になってるので、そのこと自体には感謝。)

3月 6, 2012 ソフトウェア | | コメント (0) | トラックバック (0)

2012年2月22日 (水)

ISO 6592(JIS X0126) 廃止

ISO 6592(JIS X0126)って「応用システムの文書化要領」で、以前このブログで悪くないと思う旨を書いた。で、以前から日本語規格での細かい誤字が気になって、正誤表が出たかなと調べたら、、、、、。規格として、廃止とのこと。

http://www.webstore.jsa.or.jp/webstore/Com/FlowControl.jsp?lang=jp&bunsyoId=JIS+X+0126%3A2001&dantaiCd=JIS&status=2&pageNo=1

ISOそのものが廃止らしい。何に置き換わるんだろうかとちょっと検索したけど、日本語検索程度にしたせいか、見当たらず。個人的には、それらしいISO/JIS規格が思い当たらないし、理由なども不明確で合点がいかず。うーーん。

2月 22, 2012 ソフトウェア | | コメント (0) | トラックバック (0)

2012年1月25日 (水)

iPadでのマインドマップツール 続編

iPadでのマインドマップツールを悩んでいる件を既に述べたけど、段々iPadで作業しようとすることが多くなり、解決しようとの思いに至った。以前のブログで書いたように、Mind42で作成できるが修正ができない、→ついつい作業が億劫になる弊害を感じるようになった。

本来Web系のサービスでiPadでもWindowsでも作業できるのが良いが、あまり値段のかかるのは避けたい。Webサービスで「easy step」も悪くないと思ったら、iPadで編集できない。「Mindmeister」は、再度有料会員になるのも抵抗あるし、、、。またiPad向けのマインドマップやアウトラインプロセッサーの無料ソフトをいくつか試したけど、ノード変更(子ノードを別の親ノードの下へなど)などが操作できない/操作が見つからなかった。

結局、iPadでのマインドマップツール「iThoughtsHD」を、App Storeから購入することにした。\850。

そもそも今までMind42条で作成したマップを、「iThoughtsHD」に移動させる必要がある。ネット検索での上位でヒットしなかったけど、Mind42でのエクスポート形式でFreeMind V9(V8も)あり、そちらでエクスポート。そのファイルをDropBoxに置いて、iThoughtsHDでインポートすることで対応できた。インポートの際に同期する指定も可能だったので、効率良い。しかも同期だとファイル形式も引き継いでくれる(当たり前か)。

Windowsでの利用は、Mind42でDropboxのFreeMindファイルをインポートすることで可能ではある。ただしこちらは自動的に同期はしない。したがって、集中的に作業する時などに限定されて、マインドマップの作業の主体はiPadで行うことになっていくだろう。

ちなみに、iThoughtsHDでのマインドマップそのものでの日本語入力や表示は、自分の使った範囲では問題なし。メニューが日本語でないのはちょっと気になるし、その関係か、Dropboxの指定や同期、一括ダウンロードの操作が、少し分かりにくい気がする。慣れの問題かもしれないが。

まずは一安心だし、この関係で少し延び延びになってた作業をリカバーするつもり。


補足:PC上での操作は、FreeMindを利用してDropbox上のファイルを処理する方法を採用。PC上でファイル操作(PC上でもDropbox同期)した後にPadのiThoughtsHDのマップファイル一覧で見ると、雲マークの他に更新されているアイコンが表示されるのでクリック(タップ)してマップを開くとPCで更新されたマップが表示される。

1月 25, 2012 パソコン・インターネットソフトウェア | | コメント (0) | トラックバック (0)

2011年11月22日 (火)

ハードウェア受け入れテスト

以前”初期「受け入れテスト」”って書いたけど、ハードウェアの受け入れテストも重要である。以前「受け入れテスト」を書いた時も頭の隅にはあったけど、明記しなかったようで、補足的に今日記載。

ハードウェアの受け入れテストも、開発の初期段階に行われるのは同様。ここでのハードウェアって、社内の新規基板の場合もあるけど、他部署での(先々内販/外販予定の)半導体とか、他社の半導体なども含む。

で結構厄介なのが、ソフトウェアにバグがあるように、ハードウェアも完璧なものが最初からある訳じゃない点。しかも量産を意識している場合、修正ハードウェアを入手できるのに期間を要することが多い。(逆にFPGAのように、変更が容易なケースもある。その場合は、修正確認に付き合わされる頻度が多くなる。)

基板のような場合は、ジャンパー線で修正ということも少なくない。試作機が何台もある場合は、修正済みとそうでないものが混在。ハード屋さんは、出来れば修正台数を少なくしたいと言うし、、、。


ハードウェア受け入れテストを、誰が実施するかも懸念点だろう。ソフトウェア開発メンバーになることが多いが、テストの頻度やボリュームが大きいと、委託などの方法も検討する必要がある。ハードウェアの一般的な知識や組込みの知識があった方が良いので、人捜しが難しくなる。

結局、この辺りを含めた開発初期の作業項目列挙や人員の手配などの立案や実施が重要だ。開発のその後を、大きく左右すると言っても過言ではない。

11月 22, 2011 ソフトウェア品質 | | コメント (0) | トラックバック (0)

結局 Goggleノートブック→Evernoteへ

Googleノートブックが終了ということで、結局WebのスクラップはEvernoteを利用することにした。自分なりの終了を聞いての不満はブログで記載済み。

そもそもEvernoteへ移行するのに、Googleノートブックの各ノートをエクスポート。以前はEvernoteでのインポートはhtmlも可能だったように思うけど、Atom形式のみになっていた。一部htmlでのバックアップは取ってて残りもhtmlでバックアップした後にインポートを実験して、Atom形式のみと判明したので、再度Atom形式でバックアップ。ちょっと疲れた。(Evernoteでのhtmlインポートは、勘違いかもしれない。自分のバックアップ確認などでhtmlへのエクスポートを実施していたため?)

Evernoteでのインポートは、(ノートブックのボリュームが大きかったので)それなりの時間。また、後でローカルPCとかiPadの方も同期させようとしたが、そちらも多少の時間が必要だった。

細部は調べてないけど、インポートはOKと思える。(画像を含むノートの確認をちゃんと行ってないけど、駄目なら諦めるしかないかな。また、Googleノートブックでのセッションの考えがEvernoteではタグになって使い勝手に違和感があるけど、そちらは諦め。)

以前はEvernoteの検索や表示がやたらと時間がかかって、Webスクラップとして使うこと自体をやってなかったけど、今回操作した限りでは、少しイライラするときがある程度。結構バンドルされたりしているのを見聞きしているけど、その関連で開発(資金)などがうまく行っているのかもしれない。


なお、少し使い出すと、いくつか不満も。Webの一部選択後の右クリックでメニューにEvernoteへの保存が出てきて、選択部分のみをスクラップするなどを選択する必要がある。ツールバーでのアイコンクリックでも、メニュー操作の必要性は同様。Googleノートブックに対して1アクション追加することになるのが気になった。

Firefoxのアドオンでどうにかならないか調べてみたけど、上手い方法は無さそう。結局”Menu Editor”で右クリック時のメニューの一番上をEvernoteへの保存に変更することにした。

Evernoteを使って良かった事項に、iPadでの利用がある。iPadでも直接Evernoteへ保存が出来ないかな~と思って調べたら、上手い方法を記載してあるサイトを発見。

iPadのSafariから、ツイッターやEvernoteに簡単にポストするブックマークレットまとめ

iPadでの操作自体もEvernoteへの保存処理も、ちょっともたもたした感じにはなるけど、iPadでのWeb閲覧が増えているので個人的には非常に便利だ。

Evernoteを使って良かったもう一つが、Google検索時にもEvernoteの検索を表示する点。Firefoxアドオンの「Evernote Web Clipper」のオプション指定によるもので、Google、Bing、Yahoo、Yandex、Baiduでの検索時に、Evernoteの検索結果も一緒に表示する。

Googleノートブックの中止やそれに伴う移行作業で少しイライラしたけど、EvernoteにしてiPadでもWebスクラップを行えるようになったのは良かった。イライラ自体は収まりつつあるけど、Googleサービスはこれからも少し気をつけながら利用するつもり。

11月 22, 2011 パソコン・インターネットソフトウェア | | コメント (0) | トラックバック (0)

2011年11月18日 (金)

ET2011

今日は、ET2011(Embedded Technology 2011 / 組込み総合技術展)見学。開催場所は、パシフィコ横浜。

http://www.jasa.or.jp/et/ET2011/index.html

ショー会場見学の前に、基調講演を拝聴。

「はやぶさ」-地球帰還までの7年間60億kmの運用を支えたものと新たな展開
〜あきらめない心がつかんだ成果〜

JAXAの川口さんの講演。スライド自体は、写真等は少なく文言(若干英語を併記)がほとんどだったが、話し方や内容で1時間があっという間だった。

冒頭の話しは、予算獲得との関連での、地球内部と小惑星の関係。これは本にも記載されてるかと思う。

次が映画「はやぶさ/HAYABUSA」の件。”真実のドラマ”という表現や、川口さん役の佐野史郎さんがヤカンを持ち歩くシーンのことを面白く話された。

個人的に印象深かった逸話は、カプセル回収後にコンビニでジュースを買ったら、店員さんから「砂が入っていると良いですね」と言われた件。「ジュースに砂は、、、」と笑いを誘っていたが、個人的にはウルっとしてしまった。


その後に、ショー会場へ。奥の方から見学したけど、昨年よりは見学者が少ない感じ。震災などの影響かもしれない。海外からの展示は少なくなかったけど、以前との比較では地方からの小さなブースでの展示が増えたかな。後、大きな企業でもテーマ的な展示よりも、サポート企業による展示がほとんどを占めるようになったと感じた。ET2011で初めての展示とか参考出展の類も減ってきたと思えた。

スマートグリッドはコーナーがあったので、いくつかの展示があったが、ブームというほど見学者が多かったり盛り上がっているようには思えなかった。

三洋のプロジェクターなど面白い製品もあったが、製品よりも半導体/半導体関連の展示が多かったと思う。また自分の目線なのか、電気系よりもメカとの連動のような展示が増えたように感じた。メカトロニクス(自分なりのより正確には、メカ+ソフトウェア)って、日本の技術の骨幹とも言えるかもとか、地方の展示が増えてる背景かもとふと思ってしまった。

会場では、知り合いの説明員の人と少し懇談。また、偶然知り合いとも遭遇して少し立ち話した。今年は、講演との関係でETロボコンの決勝も見学しなかったこともあって、技術や製品よりも、講演や知り合いとの遭遇が印象的な展示会になった。

11月 18, 2011 日記・コラム・つぶやきソフトウェア | | コメント (0) | トラックバック (0)

2011年11月 8日 (火)

初期「受け入れテスト」

少し前に、何度か偶然「コンポーネント指向開発」が話題となることがあり、”コンポーネントテスト”と”コンポーネントのテスト”が気になっていた。コンポーネントテストはユニットテストと呼ばれるもので、ソフトウェアモジュールを分離してテストするもの。後者は一般用語にはなっていないが、ここでのイメージは、開発の際の市販を含めた外部のモジュールをテストするものである。

で、ここでの”コンポーネントのテスト”って、一般的な用語では”受け入れテスト”に近い。開発の最初の頃に、テストフェーズでの終盤のテストと同じような事を実施することになる。反面”受け入れテスト”と多少異なるのは、利用する部分のテストでも十分であることや不具合発見が開発全体に影響することが多いことだろう。(開発の中間や終わりに、中心的なモジュールが利用できないと発覚したら、システム設計自体の見直しにもなりかねない。)

ただその観点で、「受け入れテスト」(ただしコンポーネントのテスト)のテスト技法とかの議論を、あまり見かけないように思えてきた。特にテスト効率などの議論。その辺りが気になった。

で、調べてみたら、JSTQB(ISTQB)のFLシラバスでは、2.2.4. 「受け入れテスト」でいくつかのテストを述べている。FL:Foundation Level AL:Advanced Level

・ユーザ受け入れテスト
・運用受け入れテスト
・契約、および規程による受け入れテスト
・アルファ、ベータ(あるいはフィールド)テスト

また、「市販ソフトウェアプロダクト(COTS)は、インストールや統合時点で受け入れテストを実施する。」、「コンポーネントのユーザピリティの受け入れテストは、コンポーネントテストで実施する。」との記載もある。なので、ここで書いた”コンポーネントのテスト”は、受け入れテストと呼んでも良さそうに思う。ただしJSTQB(ISTQB)では、”受け入れテスト”はテストレベルでの1つとしており、テストレベルはテストフェーズの意味でもあるので、用語の概念としてすっきりしない。

ちなみに、JSTQB(ISTQB)のALシラバスの方では、受け入れテスト自体の細部に関してはFLほどには言及していない。

用語をすっきりさせるには、組織体で○○コンポーネント受け入れテストとか○○モジュール受け入れテストと呼んだり、多少一般化するのなら”コンポーネント受け入れテスト”という用語などを使った方が良さそうに個人的には思えた。


なお、懇親会の類では、特に海外製のモジュールに重大バグがあったり窓口対応が悪かったりで、開発スケジュールに大きな影響が出たなどの話は少なくない。そして、同じ社内のモジュールとか装置開発の遅れ起因がある。割合的には後者は少ない気がするが、起きてシステムプロジェクト側が責任を負わされたり犠牲になることも。同じ社内なので、責任追及しにくかったり、元々駄目チームと分かってても利用しないと行けない事情があるのだろう。

ちなみにコンポーネント受け入れテストで話題になるのは、以下辺りが多い。

・テスト効率
・負荷テスト
・非機能要件
・外部を含めたバグ管理
・スタブ作成チーム、テスト作業チーム形成
・テスト環境保存 (自動化でスクリプトを作成したらその保存なども)

最近は外部機器でもネット接続可能なものが増えたり、市販コンポーネントでもサンプルプログラムが付いたものも少なくない。パソコンを利用して、それらの機器やコンポーネントをテストすることは増えている。さらには、GUIやネット系の自動テストツールや画面操作再生ツールなどを利用すると、結構効率良いテスト環境を構築できる。組込みソフトウェア産業実態調査報告書などで自作テストツールの割合が多いが、今後は市販ツールの利用が増えていくと思われる。

用語がすっきりするのは良いことだが、結局この類のテストの重要性を感じているところは以前も含めて実施しており、何らかの呼称を行っているだろう。また、テスト自動化の議論と多少似てて、実施しているところはさらなる効率化を目指していて、一般的な議論は進みにくいようにも思えてきた。


補足:通常の受け入れテストが発注者側が主体であるのに対して、ここでの”コンポーネントのテスト”や”コンポーネント受け入れテスト”は機器やシステムの開発側/受注者側が主体となる。発注者、開発者/受注者の各々の目線でテストのフェーズを考えることが多いので、それも少し違和感が発生するのかもしれない。開発者/受注者目線で考えるなら、テストのフェーズとしては受け入れテストという言葉よりも、出荷テストとかカットオーバーテストの方が良いように思える。

11月 8, 2011 ソフトウェアプロジェクトマネジメントソフトウェアテスト | | コメント (1) | トラックバック (0)

2011年11月 6日 (日)

Googleノートブックが間もなく終了

ネットサービスでの「Googleノートブック」は、使い続けているサービスの一つ。Google自体は開発を止めてるし、Firefoxの新しいバージョンじゃ慣れた操作ができなくなるなど、逆風の中でも使い続けている。

別のサービスでの表示と同じだろうと、よく読んで無くて今日になって気がついたけど、Googleノートブックを終了するとのアナウンス。Googleノートブック起動の際に、上の方に表示される。

「Google ノートブックは間もなく終了し、ノートブックのデータは自動的に Google ドキュメントにエクスポートされます。ご不明な点がある場合は、よくある質問ページをご覧ください。」

予感はしていたけど、実際のアナウンスを目にするとやはりショック。しかも”Google ドキュメントにエクスポート”って書いてるが、手動でGoogle ドキュメントにエクスポートしてもエラーになってエクスポートできない。1,2回はエクスポートできたかもしれないが、今までも失敗。ちなみに、htmlへのエクスポートなら出来たことはあった。

アナウンスでは”よくある質問ページをご覧ください”って書いてるけど、関連する情報としてはGoogle ドキュメントへのエクスポートくらいしか書いてない。そのせいか、Googleの言うエクスポートがほんとに実行されるか非常に不安だ。

また、Googleによる強制的なエクスポートが実行されたとして、今までのブックマークと似たようなノートブックへのメモ追加の操作をどうするかも悩みのタネ。メモをブックマーク登録するのは可能だけど、ブックマークのエクスポートはブックマーク全体で1つ。ラベル単位では出来ない(みたい)だ。先々のメモ作成の操作をどうするかも悩みどころ。

思うにGoogleノートブックって、ホームページの写真なども含めて(選択部分を)ごっそり保存できる。使う側からするとシンプルな操作だし便利。しかしサービス供給側からすると、それに応じた記憶エリアを用意しないと行けないし、検索なども可能なのでそちらの処理も必要だ。つまりデータが爆発的に増えていく。しかも、ノートブックのみでは広告収入のような収益に結びつく方策がない。利用してて言うのもおかしいが、技術的には容易でも、データ量とか収益といった現実的な考えが乏しかったサービスとも言える。日本だと、特にデータ量なども含めて検討するので、なかなか立ち上げにくいサービスのように思えてきた。ネットサービスのこれからを考える意味でも、参考になるのかもしれない。


Googleノートブック。せめて、何月頃に終了する予定とか書かれていれば、エクスポートの準備なり心づもりも可能なので良いのだが、、、、、。

11月 6, 2011 パソコン・インターネットソフトウェア | | コメント (0) | トラックバック (0)

2011年11月 2日 (水)

iPadでのマインドマップツール

iPadでのマインドマップツール選びに一苦労。以前、Mind42のことを書いたけど、少し修正などでブラッシュアップする必要が発生した。以前のブログにも書いたように、Mind42だと修正とかが出来ない。そこが難点。ノード部分を選択してダブルクリックしても、文字列修正にならない。

念のためと思って、Bluetoothキーボードをつなげてみたが駄目。iPadのマウス接続のことがネットで書かれているけど、自己責任だしマインドマップのためだけに一苦労するのも大変。またマウス接続で、Mind42の操作がうまく行くとも限らないので断念。

Mind42を少し使ったせいか、PC(Windows)でも操作できるのがよいと考えてWebサービスを調べたら、フリーなら公開モードでしか利用できないとか、FLASHを使っていてiPadでは駄目だとか、Javaの関係なのかWindowsのみの利用とか出て、良いのが見つからない。

また、マインドマップツールでWindowsでもiPadでもと言うのが、なかなか無い。OPML形式などに変換して複数のツールで利用する方法もあるが、ひらめいたことを保存する程度にしては大袈裟過ぎる気がして乗り気にならず。

アウトラインプロセッサーソフトでは、さらにWindowsでもiPadでも動くものは見つからず。ふと、Googleドキュメントでのアウトラインモードの利用を思いついたが、なんとiPadでは携帯と認識するせいか、アウトラインモードそのものを利用できない。Evernoteでは、アウトラインモードもだが、そもそも段落の考えがない。

色々調べても、自分の操作方法にフィットしたものが見つからない。時間も勿体ないので、新しいツールの利用は諦めた。少し時間が経ってから、また考えることにした。


ある意味、ソフトウェアツールが過渡期なのかもしれない。AppStoreで、iPad向けやiPhone向けのソフトがいくつも表示されるのに対して、従来のWindowsなどのツールのニュースが少なくなっているように感じた。マインドマップのようなツールは、iPadやiPhoneに向いており、Windowsでも利用する人が少なくなっているのかもしれない。

結局、先々は自分もiPadでのマインドマップツールになるのかもしれない。でも当面は、iPadでMind42に追記して、修正をパソコンで行う方法になりそうだ。

11月 2, 2011 ソフトウェア | | コメント (0) | トラックバック (0)

2011年10月22日 (土)

スクラムギャザリング 東京 2011

19日と今日は、「スクラムギャザリング 東京 2011」。Scrumに関する講演とワークショップ。2日間だが、日が少し離れていて、会場も別。

http://www.scrumgatheringtokyo.org/sgt2011/index.php?id=2

http://www.scrumgatheringtokyo.org/sgt2011/index.php?id=3

1日目は、野村コンファレンスプラザ日本橋。

綺麗なビル。プロジェクトマネジメント学会で懲りておにぎりなどを持参したけど、ビル内の共有スペースでは食事などは不可と。結局少し離れた公園で食べることにした。寒かったし、なかなか公園が見つからず。(ビル内や近くに安く食事できるところもあったので、そっちが良かったかも。事前案内が欲しかった。また、あの辺りってそれなりの広さの公園とかがない。震災とか考えると、結構不安。)

なお、会場内は、ビデオや写真撮影NG。録音もNG。TwitterつぶやきはOK。

オープニングでは、スクラムの概要の話や、参加者が水曜日180人、土曜日231人との話など。日本ではスクラムマスター231人、プロダクトオーナー48人、プロフェッショナル5人らしい。トレーナーとコーチはゼロ。ただし9月時点での調査で、認定サイトに国として日本を登録している人の数。(認定者自らが編集する必要があり編集してない人も多いだろうから、実数はもっと多いと思われる。個人的には、倍くらいか。)


Henrik Kniberg氏の講演では、冒頭に子供に整理整頓させるにはどうするかの事例で、自発性との関係が話された。タスクカンバンの警察での利用例など具体的で、また幅広い応用が可能であることを改めて示された感じ。ベロシティやペアプロに関する考えもいくつか示されて、参考になった。また、自分の家族との旅行と自分の仕事(講演)の話が、スクラムの手法を交えながら話された。終盤では、参考書籍の紹介。


Jeff Patton氏の講演は、usとthemの違いからスタート。(このテーマは、2日間で何度か出てきた。スクラムで言うところの”ニワトリ”と”ブタ”。)

会場の人達に挙手を依頼して、3つに分類。その後各テーブル(5,6人)に分類した3つの人がバランス良く席について、各自の問題点などを列挙するとかした。一種のワークショップ。3つは、意志決定、管理者(プロジェクトマネージャーくらいの意図)、作製者。会場自体の分類が結構偏っていたり、自分の属するテーブルの人達の中で話がうまくまとまらなかった。人数が同じになるような調整とか、テーブル内で立場変更とかやったんだけど、、、。人数が多かったことや、テーブル間移動がちょっと面倒だったのも災いしたかな。個人的には、ちょっと不完全燃焼。


午後からは国内事例。個人的に楽しみにしていた講演。

冒頭のYahoo! JAPANでの事例では、標準化との関係や社内への浸透での苦労話なども聞けて、どこも同じなのかとかYahoo!ですらそうなのかと感じた次第。ただ、目標業績評価制度とか内部統制との関連などを意識しており、それなりの大きさの企業での課題となる事への取り組みを先行して行おうとしていると受け取った。

エムティーアイの発表では、(終盤で話の出た)スクラムマスター66人との言に、自分もだけど結構驚きの声。発表者が日系ブラジル人というのも興味が出てきた。(社内調整で苦労があっただろうにとか、、、。懇親会で、ちらっと質問したりした。) スライドにいくつか面白ネタもあって、そっちも面白かった。

出雲村田製作・テクノプロジェクトの発表は、発注者と受注者が同時に発表するという、ある意味ユニークなプレゼン。地方での事例と言うことも目を引いた。(懇親会では、Rubyとの関連やコーチの人が四国であることの背景などを聞いて納得。)


懇親会は同じビル内。技術系のパーティ形式懇親会としては、料理が美味しかった。色んな人との会話では、既に述べたようなやり取りなどを行えて、参考になった。Yahoo!の講演者とは直接話せなかったが、会場に社員らしき人がいて従来スキームとの関係などを質問。実践の細部は各社で違うけど、そう急激に変貌させてないのはどこも同じと受け取った。


2日目は、早稲田大学。写真撮影NGなどは、1日目と同じ。

帰りにコリアンタウンにでも寄ってみようと、新大久保の駅から歩きにした。門から会場のビルまでの間に、コンビニタイプのお店があると思っていたら無し。昼ご飯のおにぎりなどのために、一旦外に出ることにした。近くにマクドナルドとかユニクロもあって、大学の周りが様変わりしている感じ。(って、2,3回しか来てないし、ちゃんとした記憶がある訳じゃないけど。)

受講したのは、午前は大きな会場(A/B会場)での講演的な話し。午後は、全部C会場での中級SM(スクラムマスター)向けのワークショップ。

CollabNet副社長の講演は、大企業でのアジャイル化戦略。CollabNetは、分散型ソフトウェア開発環境プラットフォームやツールを提供している。3000ユーザー企業と言っていた。従業員は、100を越える国に31000人。(思ったよりも人数が多いけど、利用者など別な種類も含めて聞き違いかも。)

プラットフォームやツールの話よりも、アジャイル化適応のパターン(確立、展開、拡大)の話や、変革の管理の話が主。AMDOCSなどの、ユーザの声の紹介などもあった。


ソニックガーデンの倉貫氏とアマゾンの玉川氏によるアジャイルとクラウドのトークセッションは、EC2やネットフィックス社やリーンスタートアップと、多少技術的な話しもあったけどビジネス目線が多かったかな。テンポ良く進んだけど、我々のようなタイプ(世代)には、話の分野のジャンプも少なくないしちょっと速すぎだったように感じた。


富士通の人達の話は、東日本大震災での動物医療クラウドの話が主。現地へのソフト供給というかシステム化の後、震災現場での要望などでの変更も大変だったと受け取った。あるいは、震災への対応という点を考えるなら、もっとシンプルな仕組みや機能の方が良かったのかとも。


午後からのは少し本格的なワークショップ。講師陣を囲む格好での挙手などによるグループ分けしながら、参加メンバー間で現状の問題分析などの議論を行うワークショップ。示されたタスクボードの事例に関して、テーブルの各グループでの議論(気づき)を深めるワークショップ。「バトルロイヤル」称したセッションでは、ありそうな問題点に関する意見をグループ間で議論してまとめたり、そのことをコーチ役の人とさらに議論したりした。まとめた人によっては、コーチから少しコテンパタンにやられる人もいて、さすが「バトルロイヤル」だと納得。

午後のワークショップは、なかなか言葉で表現しにくい。参加したメンバーの、気づきを起こさせるプログラムになってたと考える。「バトルロイヤル」は結構面白くて、時間があっという間だった。(サポートで)コスプレの人が2,3人いて盛り上げたし、最後には認定証なるものを手渡す遊び心もあって楽しかった。


ラップアップでは、上海大会の様子の紹介や今回の開催への慰労へ感謝の拍手。また、テーブルの隣の人と、自分の課題やその対応を議論し合って紙に書いておくなど。(2週間後だったかに、実践したか情報のやり取りを行おうねとのことだったが、どれくらい実践するか??) 課題の議論は、多少ワークショップでのネタと被っているようにも感じた。

ワークショップの「バトルロイヤル」では知った人とペアになりそうだったけど替えてもらったり、ラップアップでの隣の人も少しは知った人だった。知った人とのペアは、気が楽になる時もあれば、設問によってはやりにくい時もある。スクラムの集まりでは、それまでの研修や飲み会なども含めて知った顔が多くなる。ワークショップの時はある程度突っ込んだ課題になるかもと思って、知った人の席に近づいとくか離れとくか考えた方が良いのかもしれない。講師による質問想定とか、その日の気分によるのかな。今回は二人とも気さくな人だったり、すんなりペア交代に応じてもらい、気が楽だった。

充実した2日間だった。宴会の類があるかもと思ったけど、明日はマラソン大会に向けての練習をする予定で、帰宅。コリアンタウンは、ちょっと歩いて回る程度にした。健康食品っぽいお店があれば行ってみようと思ってたけど、案内地図などをプリントして無くて、町並みを見学した程度。人は多かった。

スクラムメンバーのTwitterで、焼き肉での宴会になったようだ。勿体ない事をしたと思ったけど、仕方ない。機会あれば、また飲み会の類に参加しようと思う。

10月 22, 2011 ソフトウェア | | コメント (0) | トラックバック (0)

2011年9月 9日 (金)

日経コンピュータなどの電子書籍化

本棚の整理で、ついに(というのもおかしいが)雑誌関係も電子ブック化することにした。いわゆる”自炊”と”他炊”。自炊なのは雑誌の一部分を残しているもので、日経エレクトロニクスとか日経コンピュータなど日経の雑誌が多い。他炊なのは、1冊のままで残していたものでBitなど。ちなみに、そもそも雑誌をスキャンしてくれるサービス会社が少ないし、切り抜きしたものを行ってくれるところは皆無。時々利用していたスキャンサービスの会社は、以前は雑誌OKだったのに最近雑誌などサービスの一部を中止してしまった。

日経エレクトロニクスは結構長く購読してたけど、ハードウェアとの関係が薄れたし、本屋さんでの購入や一部分の記事購入も可能となって年間購読は止めてしまった。そのせいもあって、思い切って電子化しておこうとの気持ちに。そうなると、ついでに日経コンピュータなどの方もとの気持ちになって、そちらも電子化することにした。日経コンピュータなどもファイルにしてると、取り出したり開いたりするのにちょっと体力が必要で、面倒くささを感じてしまうようになったためだ。(少し情けない。^.^;;)

ちなみに、雑誌の自炊での注意点は、表紙部分だろう。膠(にかわ)?の付き方が違うのか、表紙とその後の2,3枚はくっつきやすい。つまりスキャナーで重送になりやすい。思い切って幅を短めにカットすればいいが、表紙での文字まで切れてしまうことになって、実際やりながら改良するしかない。(スキャンサービスで雑誌が敬遠されるのも、その辺りが原因だろう。)

P90905962で、日経コンピュータの自炊前に撮影したのが左の写真。丁度創刊準備号から残していたので、懐かしくてパチリ。

上での一番左が、1981年の準備号(特別版春季号)の表紙、真ん中が1982年の1月11日号、右からはそれ移行の各年の初号表紙である。今から思えば初歩的なCGと言っても良さそうな画像の表紙が、10年ほど続いている。当時はCG自体が珍しかったが、こうして今の目線で表紙を眺めると時代の進歩を感じる。

また自炊しながら内容も眺めたりしたが、当時の記事や寄稿には、ITシステムの手作り感が多かった。ITシステムがプログラミングであり、品質を上げるために静的解析ツールを自社開発したり、ドキュメント作成での工夫点などの寄稿が少なくない。今よりも、システム発表の場になっているイメージ。また、システム化やツール化での割り切りの記載などもあって、個人的には今でも参考になりそうな事項も少なくなくて好感。(何となく、最近はなんでも出来るとか、100%達成みたいな内容が少なくない。)

また、長い期間で眺めると、流行の廃れや人物往来に思いを馳せる時も出てきて興味深い。大々的に取り上げていたものが急に話題から遠ざかったり今となっては不成功の烙印を押されたり、、、。人物に関する事項も、「そう言えばあの人は?」と行方などが気になる人も少なくない。なお、業界の浮き沈みという視点では、日経エレクトロニクスで取り上げられた製品群、技術や会社の落差が大きいような気がする。海外移転や空洞化の話題が増えているからなおさらだ。

今や代表的なスキャナーにはOCR機能がついてるので、自分の設定ではOCR処理済みのPDFファイルにしている。その辺りも、後の検索容易さなどで便利だ。もちろんOCR機能は十分な認識率とは言えないが、しおり(Bookmark)の作成には重宝する。

温故知新じゃないが、自炊しながら昔を振り返るのは悪いことではないと改めて認識した次第。

9月 9, 2011 日記・コラム・つぶやき書籍・雑誌ソフトウェア電子ブック | | コメント (0) | トラックバック (0)

2011年9月 1日 (木)

QCDバランスと三角グラフ

QCD(Quality:品質 Cost:コスト Delivery:納期)のバランスをどうするかは、プロジェクトそのものの方針やプロジェクトマネジメントで大きな課題だ。また、そのバランスの可視化は、以前から少し気にしていた。

「アジャイルサムライ」のP89に”トレードオフ・スライダー”の名前で紹介されているのがあり、調査。アジャイル系コミュで以下のサイトが紹介されていて、ちょっと使ってみた。

http://www.mountaingoatsoftware.com/tools/project-success

Photo_2Web上でできるのが、なかなか良い。ただし、自分の頭のイメージにあるのと少し異なる。

トレードオフ・スライダーを見て、自分の頭に漠然とあるものを具現化できる術がないか、ちょっと考えてみた。グラフ種になかったけ?と思って、(今はあんまり使ってない)DeltaGraphのマニュアルを見たら、すぐに見つかった。”三角グラフ”。もっと早めに気づくべきだったかも。

で、Web上で書けるツールはないか探したけど、すぐには見つからなかった。DeltaGraphなどで書けるのは判ってるけど、、、。ちょっとエクセルのアドオンなどにないか調べたら、そちらですぐに見つかった。「Excelによる統計グラフ表現法」第32回(古田 裕繁 著)を参考にしたマクロのようだ。

http://www.sinfonica.or.jp/kanko/estrela/refer/s16/index.html

マクロをインストールするというよりも、ここでの(マクロを含んだ)エクセルシートを利用してグラフを作成してみる感じ。使い方としても、その方が良いかもしれない。

Qcdそれを利用して、品質50%、コスト40%、納期10%をグラフ化したもの。マクロのためのセルがあるようで、敢えてそれらはそのままにした。

プロジェクトでのQCDバランスを可視化しておくには、このようなグラフを残しておいた方が良いかもしれない。最初は品質重視と言いながら、テスト工数などを見積もる/見積もらせることもなく日程が延びたりコストアップ。プロジェクトのさらなる上位層は、後の方になって”がみがみ”。雑誌の記事などで、そんなことが少なくないように思う。プロジェクトの開始時に、このようなQCDのバランス図を記録に残しておけば、少しはましになるのではないだろうか。

なお、ここでは作図ツールを利用したが、線の入った三角形の図のみをプリントして、マグネットか何かを上に置いてデジカメ撮影したものを残す方式でも良いだろう。あるいは、それを壁に貼っておく方法。

ちなみに、QCDバランスでは、3つの合計が100%になる必要があるが、グラフ上はそれ以外も作成できる。したがって、100%に制限するようなマクロとか操作方法も考えられる。が、余力があればかな。

また、上で書いたマグネットを置く方法では、厳密にはその中心で3つの合計が100%になるとは限らない。ただし三角形の中なら、(多分)誤差の範疇だろう。さらには、QCD以外の要素を含めるケースもあるようで、4軸なら「Jチャート」と呼ぶグラフもあるようで利用できるだろう。(個人的には3つのバランスで十分とか、3角グラフを複数用意する方式でも良さそうに思う。)

9月 1, 2011 ソフトウェアプロジェクトマネジメントプロジェクト管理 | | コメント (0) | トラックバック (0)

2011年8月11日 (木)

iPadでの音声認識ソフト

一昨日、iPadにお試し的に音声認識ソフトをインストールしてみた。ひどくないというか、そこそこ使えそう。自分のデスクトップPCだと、音声認識のためにはヘッドセットを取り出して接続が必要で、ちょっと面倒。しかも最近は、閲覧のPDFファイルやメールをiPadで見ることが多いので、メモ的なものはiPad操作の際に多くが発生する。メモを音声認識で残せれば便利と考えて、お試し的にインストール。もう少し早めに気がつけば良かったのだが。

ただし一昨日試したのは、クリックで一挙に変換結果が表示されるタイプ。逐次表示のものとかが自分には合ってそうとのことで、今朝物色。良さそうなのが見つかり、さっきダウンロード。「音声認識メールST(3GS以上専用)」。

http://itunes.apple.com/jp/app/id347250830?mt=8

ソフトウェアのタイトルだとiPad向けに思えないが、条件などに記載してあるようにiPadでも大丈夫。また、以前は115円していたようだが、今は85円。(「音声認識メール クラウド」の方が機能が充実してるようだが、オフラインでの利用もあるし何日かでの利用更新も気になったので、ST版にした。)

音声認識の機能は、思ったよりも素晴らしい。もっぱら連続入力のモードで利用すると思う。文の区切りで認識結果が出るので、それを多少確認しながら次の文を入れるやり方だ。多少、そのための効率落ちるけど、その都度の修正とかができるので自分には合ってる。

また、Evernoteとの連携が可能なのもメリット。デフォルトのノートブックに、認識結果のテキストを置ける。他のアプリもデフォルトノートブックへ置くので、ちょっとEvernoteのデフォルトノートブック名を変更した。 他にTwitterへの投稿なども可能だ。

8月 11, 2011 パソコン・インターネットソフトウェアテクノロジー | | コメント (0) | トラックバック (0)

2011年8月 9日 (火)

Twitterが強制的に新バージョンになって、、、

Twitterの公式Web表示版が、強制的に新バージョンになってしまった。以前から、切り替わりますよとの表示はあったんだけど、、、。

今まで旧バージョン表示にしてた大きな理由は、Twitterの「おすすめユーザ」を消したかったから。こればかりは好みの問題なのかもしれないが。

で、強制的な新バージョン移行で、改めて「おすすめユーザ」(Who to Follow)を消す方法を模索。以前からStylishを使って消すスクリプトをインストールしてたけど、新バージョンで消えない。改めてStylishのサイトを調べたら、更新版(暫定版?)が置いてあった。そちらのインストールで消すことができた。

http://forum.userstyles.org/discussion/27625/x

本来は、スクリプトの意味などをちゃんと分かってやるべき何だろうけど、、、。

8月 9, 2011 パソコン・インターネットソフトウェア | | コメント (0) | トラックバック (0)

2011年8月 1日 (月)

イテレーションとトヨタカレンダー

先だっての講習で、イテレーションを全世界共通にして、(各国間の相違を含め)祝日によるベロシティ差異を吸収するにはトヨタカレンダー(方式)が良いよな~と漠然と考えてた。

で、今朝、トヨタの採用情報を確認。

http://toyota-saiyo.com/tech/i_recruit/index.html

「完全週休2日制(土・日)、GW・夏期・年末年始休暇」の文字。つまり休みに祝日がない。

もちろん冒頭で年間休日数を書いてあるし、トヨタ/トヨタグループに就職しようとしたら、ある程度トヨタカレンダーを知ってて混乱は無いのだろう。

ちなみに、似たような会社がないのか「”完全週休2日制(土・日)” -祝日」で検索したけど、”祝祭日”とか”国民の休日”とかの表記もあって、自動的に見つけるのは困難。でも、エンジニアリング会社で採用している会社もあったりした。

また、日産は以下の表記。(祝日が休みというわけじゃないようで、変則的ということか。)

http://recruit.nissan-careers.com/info/index.html

「週休2日制(※当社カレンダーによる、月5~8日)年間121日」


これから、ちょっと気にしておくつもり。

8月 1, 2011 ソフトウェア自動車プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2011年7月29日 (金)

プロダクトオーナー研修

昨日と今日は、認定スクラムプロダクトオーナー(CSPO)の研修。場所は秋葉原、講師はVernon Stinebaker氏など。ちなみに「プロダクトオーナー」は、ソフトウェア開発手法”スクラム”での役割の一つで、ソフトウェアプロダクトの総責任者。ユーザ要求の管理やビジネス視点での責任を担う。

研修内容細部についてはここでは余り触れないが、勉強になることが多かった。ある程度知っていることでも研修の実作業で気づきも発生したし、研修中のQ&Aや研修後の懇親会で深掘りできた。ちなみに、開催社による”プランニングポーカー”を入手。

4つほど、思いついたことを記載しておく。

・即席チームのファシリテーション

今回の研修では、スクラムを相当実践している人から、ほとんど知らない人まで知識レベルが様々。グループ間のレベル差をなくすために、各グループに色んなレベルの人が混在する編成となった。

講師の問いかけやグループ活動で、スクラムマスターの人達が他のメンバーの発言を促そうとの意図から、発言を控えることが時々あった/あるように感じた。初日の懇親会で少し話題にしたら、余り気にすることなく発言すべきとの意見が。

即席のチーム、しかもレベルの差が大きなチームのファシリテーションの難しさを痛感。あまり知らないメンバーからでも発言があれば、そこからアイデアなどが発展することも少なくないのだが、、、。もしくは、ある程度グループ間競争やその意識を、ゲームなどの格好で取り入れた方が良いのかも知れない。

・実務に近い演習

今回の演習(ゲーム)では、実際のソフトウェア開発を想定してのプロジェクト。タスクカード作成やスプリント見積りもりをチームで行った。タスクカードに対する考え方がメンバー間で大きく異なったのには、ちょっと驚いた。独り言のように、タスクカードに書く内容をつぶやきながら作業すれば、(即席チームのせいもあるけど)ブレは少なくなったかのかもとか考えさせられる点も。

また、見積りはプランニングポーカーで行ったが、時々見積りに大きなばらつきが。チーム内で大きくばらついた理由の多くは、実装方法に依存した。実装に関する基本的な事項を、チームで述べ合うのも悪くない(むしろ良いこと)と感じた。

いずれにしろ普段スクラムを実践している人にとっても、意外な考え方などに遭遇して、ためになったと思う。

・”スクラム”のプレゼン資料が7人制ラグビー

たいしたことでもないかも知れないけど、、、。一般的に、スクラムでのチームサイズは、7プラスマイナス2人程度が良いとされている。もちろんスクラム・オブ・スクラムにより、チームを階層的にしたりして大人数でのスクラムの実践もある。また逆に、3,4人での小さなスクラムチームでの事例の話も少なくない。

ただ7人という人数に拘れば、15人制ラグビーはスクラムだけでも8人であり、少し人数が多い。またスクラム(のみ)の写真では、チームとして得点を獲得するとのイメージとは少し離れてしまう。7人制ラグビーでのスクラムだと、人数少ないし、他のメンバーを含めた7人で得点を重ねるとのイメージが生まれやすい。

講習の際に、そんなこと思いながら、「7人制ラグビーですね」とか言おうか考えたけど、話題はどんどん先に進んでしまった。^.^; 意図しての写真だったか、Q&Aでも聞いても良かったけど、、、、。まっ、頭の隅に入れておき、講習スライドなどを目にすることあったら話題にするかも。 (ちなみに、個人的にはゲームとしての7人制ラグビーは面白味が今ひとつと思えてる。人数の件よりも、15人制と同じフィールドの大きさのためかな。なお、7人制ラグビーは、2016年のリオデジャネイロオリンピックの正式種目で、女子ラグビーはオリンピック初登場。)

・PDU付与

今回の研修は、PDU(Professional Development Unit)が付与されるとなってた。PDUは、プロジェクトマネジメント資格PMPの受験や資格維持のために、必要な単位が決まっている。申込みの際の案内でも判ったのかも知れないが、気がついたのは研修の前日。ある意味個人的にはラッキーだったし、PMIの本部がアジャイル関係資格へ動いていたり、そもそも以前からアジャイルへの取り組みが活発なためだろう。


2日間の研修中のQ&Aで、プロダクトオーナーがスプリントの最初でバックログをレディにする率なども話に出て、考えさせられた。(正確には、レディにしているスクラムチームの割合。) 他にタスクカードの粒度に関しても、工夫の事例の話も出て参考になった。有益な2日間だった。

7月 29, 2011 ソフトウェアプロジェクトマネジメント | | コメント (0) | トラックバック (0)

2011年6月23日 (木)

IBM100周年ビデオでの「ブルックス」

先週だったか、日本IBMに行った際のロビーで目に付いたのが、ブルックス。IBMのシステム360システムの開発マネージャであるが、「ソフトウェア開発の神話」「人月の神話」の著者との方が馴染みがあるかもしれない。(「人月の神話」は、「ソフトウェア開発の神話」の改訂版。)

その際にちらっと見たのは、上司になるボブ・エバンスが、意見の対立した彼をメンバーに含めるくだり。

今日、もしかしたらYouTubeにアップされてないかと調べたら発見。まださらっとしか見てないが、360システムの次には、飛行機の予約システムSABREに関するインタビューもあるので、いくつかのシステムが取り上げられているのだろう。

プロモーション的なIBM100周年のビデオも見たが、技術屋さんにはこちらの方が面白いような気もする。土日に、じっくりと見てみようと思う。

6月 23, 2011 ソフトウェアテクノロジー | | コメント (0) | トラックバック (0)

2011年6月21日 (火)

マインドマップツール(Webサービス) Mind42

今日もう一つ見つけたのが、マインドマップツール(Webサービス)。Mind42.com

結構長い期間、WebサービスレベルでのマインドマップツールはMindMeisterを利用してた。一時期は有料コースにしたが、最近は協業でマインドマップを作成することが少なくなり無料コースへ。しかし、Mindmeister自体が無料では最大3つのマップしか作ることができなくなり、少し悩んでいた。PCベースで動かすソフトは持ってるし、協業でマインドマップを作ることは少ない、でも(無料で)3つじゃ少なすぎる。

今日何気に探し当てたのが、Mind42.com。利用のためには、メールアドレスなどでのアカウント取得するタイプ。

http://mind42.com/

細部まで読み切ってはいないが、フリーでも個数に制限は無さそう。実験で5つ作ってみたけど、特にエラーなどにはならなかった。

もしかしたら、以前も検討での1つだったかもしれない。昔は協業が大きなテーマだったので、MindMeisterにしたような気もする。ただそのニーズは一過性で、最近は協業でのマップ作成がめっきり減ったのでMind42で十分と思う。

また、個人的に非常に重宝しそうなのが、iPadでも使えること。なお、子ノードの作成などをPCではTabキーで行えるが、iPadでは(多分)行えない。カーソルというか指でクリックして、子ノード生成を指示することになる。 まっ、iPadでは、ちょっとした修正や他で作成したマップの閲覧ができれば十分なので、あまり苦にはならなさそうだ。

こちらのツール(サービス)も、しばらく使ってみる予定。


追記:iPadで使えるって書いたけど、マップの修正はどうもうまく行かない。新規での操作もiPadだと多少まどろっこしいので、閲覧が可能くらいに考えた方が良さそう。

6月 21, 2011 パソコン・インターネットソフトウェア | | コメント (0) | トラックバック (0)

プロジェクト管理ソフト (Webサービス) Gantter

今日見つけたのが、プロジェクト管理のソフトというかWebサービス。無料。Gantter。

https://app.gantter.com/

先行タスクの指定とか達成率の入力などが可能。MS Project形式でのやりとりも可能。テスト的に作ってみたのが以下。

Gantterテストした限りでは、日本語もOK。

iPadでもそれっぽく動いたけど、実際の作成や閲覧は実用的では無さそう。なお、画像ファイルへのエキスポートは可能で、機能的には多少不満もあるがiPadで見ることも可能ではある。

自分の場合は、Googleアカウントを利用してプロジェクトのファイルの作成などを行った。ファイルの保存も(主として)Googleドキュメント経由とした。

以前ここのブログで、Googleドキュメントでガントチャートを作成してみたけど、その方法よりも楽。
https://blog-honda.cocolog-nifty.com/gijyutuya_nikki/2009/11/google-6169.html


複数PCでの簡単なスケジュールの作成や検討の作業で、しばらく使ってみるつもり。


6月 21, 2011 ソフトウェアプロジェクトマネジメント | | コメント (0) | トラックバック (0)

2011年5月19日 (木)

注意報や警報の情報

今回の震災に関連して色々調べて、利用してはじめたサービスに「横浜市注意報警報情報」がある。横浜市では、同報系防災無線の設置が見送られているのも理由。

最初は、近くの川が気になって水位の警報程度のみを受信するようにしていた。ところが、雷などを含む注意報も受信しようと設定を変更。最近ほとんどの注意報/警報を受信するようにした。結構便利なんだけど、できれば、あと何時間くらいで発生するかとか警報に変わる可能性があるとかが判ると良いな~というのが感想だった。少し調べたので、メモのつもりで書いとく。

まず、今日10時での横浜市からの注意報のメール文。他に情報のURLなどがある。

■気象警報注意報情報 2011年05月19日 10時08分発表 横浜市:  強風注意報(発表)


で、気象庁の方はどうなってるかというと、以下のページにあって、結構詳しい情報が掲載されている。(以下のページは、注意報などの発生や解除で更新される。)

http://www.jma.go.jp/jp/warn/1410000.html

平成23年 5月19日10時08分 横浜地方気象台発表

神奈川県の注意警戒事項
 神奈川県では、19日昼過ぎから20日明け方まで強風に注意して下さい。東部では、19日夕方から20日明け方まで高波に注意して下さい。


===================================
横浜市 [発表]強風注意報 
 風 注意期間 19日昼過ぎから 19日夜遅くまで
   南の風
   海上 最大風速 12メートル

特に、いつくらいからがあるのが、ありがたい。(一昨日だったかの雷注意報には、いつからとはなかったように思うので、気象の種類によるのかもしれない。)

これらの情報は、週間の予報や当日とか明日の予報を知って使うのが良いのだろう。注意報が警報の前触れかは、そのような知識が役立つ。


なお、気象庁のページを見て、それぞれの注意報や警報の判断基準などを読んでみたら、自治体などで異なるなど相当複雑。花粉の情報なども、(当然)予測には気象データや気象モデルなども利用している。単に“気象データ”とか”予測”って言うけど、この辺りのコンピュータによる(有限要素法などを利用した)処理が複雑なり多量データなのはご存じのとおり。精度を高めるにはデータのメッシュを細かくする必要があるし、それは計算負荷に結びつく。

注意報の発令をちょっと考えてみたけど、予測を10分後、20分後、、、、等で行い、各自治体毎の基準に照らして判断することになる。項目も風力だったり水位だったりする。各メッシュでのポイントがどこの自治体に属するか判断して基準との比較を行うのだろう。ただし、単純に全メッシュ毎に全予測を行い、全項目の基準との比較を行うと、無駄な処理が増える気がする。多分アルゴリズムなどは工夫しているのだろう。

今まではTVでの天気予報とか花粉情報を目にしたり気にかける程度だったけど、注意報や警報の発令を調べたり市の注意報警報情報サービスを利用してみると、奥が深いな~という感想。紫外線とか人々の予報への要望への対応?もあるし、逆に桜の開花予報のように止めた対応もある。計算の複雑さやその回避に関しては、懇親会などの何かの折りに、詳しい人がいたら聞いてみるつもり。

5月 19, 2011 ソフトウェアテクノロジー安心・安全 | | コメント (0) | トラックバック (0)

2011年5月12日 (木)

オープンソースの静的解析ソフト

今日の「Japan IT Week 2011」で見かけたもの。以前ブログで「ソース・コード静的検証によるソフトウェア品質評価の意義」というのを書いたけど、それにも関連する。以前でのブログは、オージス総研での”Adqua”による品質評価ツールに関するもの。そのツールのためには、QACやQAC++が必要だった。(ただし、無償利用のためには、1年間に1件以上の測定データ提出が必要。)

今回オージス総研で展示されていたのは、QACの代用に該当するもので、オープンソースの静的解析ソフト。「AdLint」。AdLintの出力を利用してのAdquaの利用が可能とのこと。GPLなので、社内向けの改良なども可能と思われる。

静的解析も、QACなどのような商品ツール、IT企業による解析サービス、Adquaなどのように俯瞰的な調査サービスなどもあって千差万別である。複数のツールやサービスを利用しているところも少なくないようである。逆に、どんなポリシーで利用するかを組織体で明確にしないと、解析結果に振り回されることになるかもしれない。


ちなみにご存じのように、lintはUNIXなどに備わっているCのコードチェッカー。また、AdLint自体は、C++には現時点では未対応のようだ。

5月 12, 2011 ソフトウェア | | コメント (0) | トラックバック (0)

Japan IT Week 2011

今日は、東京ビッグサイトでの展示会見学。「Japan IT Week 2011」で、ソフトウェア開発環境展や組込みシステム開発技術展などの合同展示。

組込みシステム開発技術展のみが西館(ゆりかもめ駅に近い方)で、そのほかの展示は東館。昨年よりもクラウドコンピューティングEXPOの出展社が増えたことや、スマートフォン&モバイルEXPOの第1回も開催されたことで、IT系のクラウドやWeb系の展示が増えたように感じた。また、西館の方が見学者密度が少なかったように思えた。

クラウドやWeb系としては、個人的には複合機のSalesforceやSAMBAとの連携などが印象的だった。プロジェクト管理(勤怠と言うべきか)をSalesforceで行うシステムなどの展示もあり、月利用料金の安さなどが目を引いた。Salesforce Chatterをベースにした「スマートスクラム」と呼ぶサービスの展示がありSCRUMを多少イメージしてるとの説明だったが、SCRUMとの関連性は良くわからなかった。

アマゾンウェブサービス(AWS)の展示もあった。クラウドでのPDF全文検索とかモバイルコンテンツ変換や電子ブック変換が個人的に印象的。またスマートフォン利用システムは数多く展示されてた。

開発関係では、静的解析やオープンソースに関するサービスが増えたように思う。従来もコンピュータメーカーでのサービスはあったが、NRIのような企業のサービスの展示もあって、広がったイメージ。下請けなり関連会社に導入してもらうことで売り上げにもなるし信頼性向上にもなるので、メリットに結びつくのかもしれない。(運用を間違うとおかしな事になる危惧はあるけど。) テストケース生成の展示もあったが、数は少なかったように思う。 なお、オープンソースの静的解析ツールに関しては別掲。

IBMは災害対策支援も展示してた。

個人的には、HOYAの音声合成ソフトウェア「VOICE TEXT」が面白かった。結構声の抑揚への対応が出来てて自然。文字列で”柿と牡蠣”(だったか”箸と橋”だったか)と入力して発声させてみた。逆にそのための音声データの準備が必要。他に「カラービット」も面白く感じたが、個人的には利用は限定的というか各ユーザの用途に応じてシステム化して収めるケースが多いように思えた。


Webやクラウド、スマートフォンの利用が急拡大する/しているのを、肌で感じた1日だった。それにしても人が多く、次回は見学時間帯や回り方などを少し考えたい。

5月 12, 2011 日記・コラム・つぶやきソフトウェア | | コメント (0) | トラックバック (0)

2011年5月11日 (水)

成熟度と競争優位性

Maturity Model での「成熟」って何だろうって考えることがある。”成熟”という言葉そのものには成長のようなイメージがあって前向きだけど、”熟女”とか”熟年”とかなると、少し陰りのあるようなイメージも付きまとう。

個人的に、CMMが弊害が多い(多かった)との印象があるせいか、成熟度は高ければ高いほど良いというわけでもないだろうにと思えてしまう。ちなみに、CMMでの印象が良くないのは、レベル2認定のため”だけ”に構成管理などを一生懸命やる話を聞いたりしているためだ。レビューなどのレベル3などの話には目もくれない。相手先の条件などのための認定取得ではなく、自組織のプロセス改善のために改善。スタッフが盲目的に指導して、現場とかは混乱するケース。端的には、構成管理のツール(のみの)導入や厳格な運用をしようとして、現場はうんざりといった感じ。(しかも予算の関係もあるだろうけど、継続的な改善として次のレベルを目指すとかCMMI認定を意識することがないようだ。)


で、最近ちょっと目にしたのが、ジェイ・B・バーニーの「競争優位の構築と持続」。

持続的競争優位性として、”自社の持つ経営資源は真似されにくいかどうか?”を挙げている。

また、画家の猪熊弦一郎が、尊敬していた師匠アンリ・マティスから「お前の絵は。うますぎる。」と言われてから自分の作風を確立していった逸話も目にした

スポーツ選手やチームが、その特徴を「弱点であり強み」と表現することがあるように、自分やそのチーム自身の特徴が強みであると同時に弱点になることがある。ただし、弱点部分を急に直そうとすると、バランスが非常に悪くなってしまう事が多い。

ある程度の成熟度のために自組織の成熟度を上げることは大事であるが、成熟度向上だけに固守するのもおかしな話である。また、参考とするその指標自体も数年もすれば改訂される。むしろ組織体の目標を明確にすることや継続的な改善をどうするかを検討すべきと言える。(スポーツの世界では、記録やリーグ優勝などの方が目標であり、打率などを成熟度での指標の1つと考えれば分かりやすいだろうか。)。

なお、昨今は企業経営が多岐にわたり、しかもダイナミックになってきた。1つの製品のみを扱うケースは皆無で、複数の事業を抱え、多くのグループ会社をもつ企業が多い。しかも、100%子会社ばかりではなく、資本支配や提携といった形態も少なくない。M&Aをはじめとして、全くの他企業を傘下に収めることも良く行われている。オーナー企業の方が、革新的な商品やサービスを提供しているケースが少なくない。

それらを考えれば、親企業などの特定企業や特定部署の開発プロセスとか管理方法を100%真似るような目標を持たせること自体が、非現実的である。一般的に言われている成熟度での、統一的な把握や制御は、困難とさえ思える。


とある会合で、成熟と”成長”とは相反するのじゃないかとの意見が出て、「なるほど!」と思った。成長を意識しつつ、成熟度の視点と継続的改善の視点の、両方を持つべきだろう。

5月 11, 2011 ソフトウェアプロジェクトマネジメント | | コメント (0) | トラックバック (0)

2011年5月 8日 (日)

ISO/IEC 6592 (JIS X 0126)も悪くないかも

ISO/IEC 6592(JIS X 0126)は、「応用システムの文書化要領」と題され、ITシステムでの文書のひな形と言える。実は最近目にして、「悪くないな~」との印象。

正確にはJISは2001年に改訂され、そちらが好印象。従来いくつかの文書で構成されているものを、1つの文書(ただしサブ文書より構成される)の表記に変えている。JISの改訂そのものはISOの改訂によるが、そもそも日本は従来のいくつかの文書での構成としたかったらしい。(JIS X 0126の”解説”に詳しい。)

個人的には、設計ドキュメントは少ない方がよいとか少なくすべきとの考えだし、全体把握の文書があるべきとの考えなので、今回の改訂版の方が馴染みやすい。逆に、規格改定などをウォッチしておけば、早めに気がついたのにと少し反省。(以前の版だと、文書種の列挙で閉口したのだと思う。)

1 システム要求
 11 問題の定義
 12 目的
 :
2 システム記述
 21 システムの識別
  211 システム名称

のように書かれている。人的資源や費用/項目、長所/弱点といった項目もある。

個人的には、この規格をもとに、組織体で必要とされる項目を追加したり、対象物によっては未記載にする(削除する項目)などを検討しても良いだろう。また、この規格を文書一覧と考えて各文書を用意するよりも、ここでの項目をなるべく1つの文書にする方が良いと考える。

組込みでもそうだが、1つの製品なりシステムの文書化は、章立てをどうするかとか記載分担をどうするかが悩みの種。組込みでは、特に新規開発とか新分野の開発の場合が顕著である。文書の数を多くして、極端にはエクセルでの断片的な仕様表だらけとか、(やれエクセルが好きとかTexが好きとかで)多くのフォーマットでの文書の乱立ということもあるようだ。文書が増えればメンテナンスが大変だし、そもそも協業での変更管理やCO/CIに関連する弊害も発生する。

まっ、一見をお勧め。

5月 8, 2011 ソフトウェアプロジェクトマネジメント | | コメント (0) | トラックバック (0)

2011年4月18日 (月)

ニフティ「TimeLine」サービス終了に向けて

ニフティの「TimeLine」は、結構気に入ってたサービスだった。実際自分でも作っているコンテンツがあった。それがサービス終了と。

http://timeline.nifty.com/

ちなみに、「TimeLine」での人気コンテンツは”日本史・合戦タイムライン”。ヤマトタケルの東征~第二次世界大戦までの戦いが、各々開始-終了の帯状に書かれている。戦によっては、攻防の図示もあって分かりやすい。


このサービスでの技術よりの特徴を言えば、以下のようになるだろうか。

・日時の指定が、年は西暦1年~9999年、時分秒も指定できる。

ただし、0年でも日によっては処理してくれるかもしれないし、時分秒を含めた細部の確認はしてない。

・見たい部分へのズームイン/ズームアウトが可能。

1画面内を、10年程度を納めるとか1分程度にする事ができる。もちろん、スライドバーを使って別の期間への表示も楽

・Webサービス。

つまり使用ソフトに依存しない。


サービス終了とのことで仕方ないので、他の方法を探そうとしてるけど見つからない。(というか自分もそうだが、コンテンツ書く時の検討で本TimeLineになったので、そう簡単に見つかるわけがない。)

まず日時は、エクセルなどのように処理の内部を特定日時を開始として数値処理することが多い。エクセルだとシリアル値と呼ぶもの。1900年辺りを開始にしている。ちなみにエクセルでの最大期日は、9999/12/31らしい。

ちなみにUnixの2038年問題というものがあり、2038年1月19日3時14分7秒(UTC)になると処理できなくなるというもの。ただし、C言語の実装で上記内部の数値を signed long int型 で処理している場合。long long int型などにしていれば、問題は発生しない。

できれば、プロジェクト管理ソフトで扱えれば良いんだけど、MS Projectでのプロジェクトの開始/終了は 1984/1/1~2049/12/31と、エクセルなどより制限している。(MS Project Pro 2010 お試しダウンロードでの実験)

念のためと思って GanttProject も再度試してみたけど、そもそも年の桁が2桁。


本音言えば、ニフティが有料化しても良いからサービス継続してくれればいいと思ってる。「TimeLine」はRuby on Railsで構築されており、Rubyの普及という観点では価値あるシステムとも思う。またメンテナンスも容易なのではないだろうか。 ただし、開発ブログなどから推察するに、もう開発メンバーがいないようで、機能アップは望むべくも無く、継続の実施になると思われる。あるいは、外部の団体が引き継いでも良さそうに思う。

そうは言っても、上の要望が通る可能性は薄いので、対応をいくつか考えてみた。

・年表作成ソフトの利用

シェアウェアのものを見つけたけど、難点は専用ソフトということ。コンテンツ公開をどうするかがネック。期間のズームインは貴重で、全部を1つのPDFにする方法も芳しくない。

・年月日を独自数値化

例えば、年部分を整数にして少数以下を1年に対する比率。閏年などを無視しても見かけ上は問題ない。

ただ、大きな課題は、その後の表示方法。そもそも”フローティング棒グラフ”がぴったり来るけど、エクセルでも多少作成が面倒。ズームインなどは横軸の最大値/最小値の操作になってしまう。

なお、Googleスプレッドでも積み上げグラフは作成可能。その利用だと利用ソフトに依存しないけど、”フローティング棒グラフ”が書けない。つまり系列を透明色にできない。またグラフ編集で、最小値などの指定ができないのもネック。

蛇足かもしれないけど、GoogleスプレッドではGoogle Motion chart という、ちょっと面白い機能を利用できる。でも、Motion chartでの”年”は1900年以降(ただし細部は未確認)なので、今回のような用途には利用不可。


色々考えてみたけど、上記対応では満足行くものがない。ほんと困った~。今後も探してみるけど、アイデアやヒントになりそうなものがあったら、コメント記載や直メールください。


4月 18, 2011 パソコン・インターネットソフトウェア | | コメント (4) | トラックバック (0)

2011年3月11日 (金)

アジャイルだって偽装請負には留意

少し旧聞の類だが、日経SYSTEM 2010年9月号のアジャイル特集で記載されていた「最近見たRFP(提案依頼書)の中に『開発はアジャイルで』と書かれていたことです」は、気になっていた。

RFPとか契約の類で具体的な表現をせずに、アジャイルと一括りに記載することって無いよな~というのが、率直な感想。ただし、実際のRFPでは具体的なプラクティスが記載されていたけど、紙面上ではぼかして記載したと考えられなくはない。(もしそうでも、アジャイルに興味ある読者を想定すれば、具体的に記載してあった方が良い。そこそこ浸透しだした昨今のことを考えれば。)

で、最近つぶやきの類で目に止まったのは、アジャイルと契約との関係。以前から報告書の類や会合では話題になってるので目新しいとは言えないが、実務で接するケースが増えたということだろう。しかも、ついつぶやきたくなるような事象が発生していると推察する。

アジャイルでやるようにと言われながらも、契約は一括請負とか、、、、、。でも、基本的に注意が必要なのは、「偽装請負」にならないかということ。これは、アジャイルだろうがなんだろうが関係ない。 偽装請負は違法行為で、新聞などで目にすることもある。

偽装請負については、会社で教育されたりもする。例えば、請負契約での担当者を自社構内で作業させてた。ある時、自社内の引っ越しが発生した。その作業担当者の机等も引っ越に関係するので、引っ越しのための作業を作業担当者に指示した。○ですか×ですか? なんていう質問が、新人なり中堅社員向けの教育で行われたりする。実際の教育になくても、基本が判れば回答できる範疇だろう。場合によっては、引っ越し作業をしてもらうには、どうするかなども話されることもあるかもしれない。

アジャイルでのケースだと、一括請負で契約し、ある時から「スタンドアップミーティング」を開催しようと担当者に依頼。○ですか×ですか? といった質問になるかもしれない。

あるいは、偽装請負の範疇じゃないけど、、、、。準委任契約でソフトを作ってもらいました。納入後バグが発覚しました。委託先に無償での修正を依頼しました。○ですか×ですか? こちらも、基本的な質問だろう。

最近のつぶやき読みながら、開発担当側も勉強が必要だろうとか、開発現場に応じて契約関係の社内教育も少し味付けを変えたり補足すべきだろうと、ふとそんなことを思った。

3月 11, 2011 ソフトウェア | | コメント (0) | トラックバック (0)

2011年3月 9日 (水)

PDF しおり(Bookmark)エクスポートツール

自炊のPDFファイルや既成のPDFファイルでの、しおり(Bookmark)の吐き出しソフトは、ずっと頭の隅にあった。最近フリーのものも試してみたけど、ファイル名が英文のみとか、挙動がおかしかった。小さなファイルでも発生したので断念。

で、先週目に止まったのが、以下のソフト。「d-LinkMaker」。

http://www.d-sols.com/product1+index.id+9.htm

購入の決め手は、自分の出身と同じ鹿児島の会社だということ(かな)。 お試しダウンロードもできて実験してOKそう。その後、振り込みなどの処理を行い、正式版に置き換え。(注:Acrobat向けのソフト。Readerでは動かない。)

ちなみに、インストールしたらAcrobatのメニューに、エクスポートなどのアイコンが表示される。個人的には、使い勝手はまあまあ。できれば、フォルダー単位でPDFファイルを指定できれば良いんだけど、、、。今はAcrobatの”キャビネット”の機能を利用してはいる。

いや~、見つかって良かった。

3月 9, 2011 パソコン・インターネットソフトウェア電子ブック | | コメント (0) | トラックバック (0)