OpenSourceを使っての開発

投稿者

投稿内容

BRYAN: 会議室デビュー日: 2004/10/06; 投稿数: 4

投稿日時: 2005-10-25 01:10

　プログラムデザイン工程に進んだ場合、通常ではプログラム仕様書なるものを作成します。しかしながら、OpenSource等を使いカスタマイズ開発する場合は、あらかじめモジュール設計などはされているので、変更部分だけを明確とした仕様書を作ろうと思っています。
　100％品質を目指す場合に、ソフトウェア開発工程の全てをきちんとやることが基本的には100％だと思います。ソースコードを追ってPD仕様書を書いて、全ての項目を作って全ルート試験をするのも、もったいないし、かと言って変更部分だけを試験しただけではシステム全体としてよいとはいえない。
　皆さんはどのように進めているのですか？

らい: 大ベテラン; 会議室デビュー日: 2005/08/02; 投稿数: 159; お住まい・勤務地: 東京都と千葉県のさかいめ

投稿日時: 2005-10-25 09:24

はじめまして、らいと申します。

引用:

BRYANさんの書き込み (2005-10-25 01:10) より:
　プログラムデザイン工程に進んだ場合、通常ではプログラム仕様書なるものを作成します。しかしながら、OpenSource等を使いカスタマイズ開発する場合は、あらかじめモジュール設計などはされているので、変更部分だけを明確とした仕様書を作ろうと思っています。

う～ん、OpenSourceを使った開発と、その他の開発って、仕様書の書き方が変わるんですか。
いや、私はOpenSourceの開発ってやったことないのでわからないのですが。
まぁ、その辺は置いといて。
基本的に、変更部分のみですむのであれば、それでいいのではないかと思います。
ただし、その変更部分が変更しない部分と密接にかかわっている場合は、
この限りではないかと思われます。

引用:

　100％品質を目指す場合に、ソフトウェア開発工程の全てをきちんとやることが基本的には100％だと思います。ソースコードを追ってPD仕様書を書いて、全ての項目を作って全ルート試験をするのも、もったいないし、かと言って変更部分だけを試験しただけではシステム全体としてよいとはいえない。
　皆さんはどのように進めているのですか？

自分だったら、全部やります。
というか、「もったいない」って、何がもったいないのでしょうか？
多分、ニュアンス的に「時間」のように読み取れます。

では、想像してみましょう。
たとえば、「時間がもったいない」ということで、
変更部分のみの試験をしたとしましょう。
で、問題ないのでリリースしました。
がしかし、変更部分以外で問題が発生しました。
# ここでは、変更部分と絡み合った問題としましょう。
ですが、実は全ての試験をしていれば発見できた問題でした。

さぁ、どうします？
あなたは「もったいない」といって、全体の試験をやらないで済ませますか？
逆に、全体の試験をやって、問題がなければ、
大手を振ってリリースできるのではないでしょうか？

BRYANさんも本文で「100％品質を目指す」と書いていますので
わかっているとは思いますが、やって無駄ということはないはずです。
たしかに、「やる」「やらない」は開発者（もしくはデバッガー）の勝手ですが、
品質の向上を目指す以上、チェックは「これでもか！」というくらい
やったほうがいいと考えています。

_________________
一寸先は闇
安定してるシステムって言ったじゃん（泣）

uk: ぬし; 会議室デビュー日: 2003/05/20; 投稿数: 1155; お住まい・勤務地: 東京都

投稿日時: 2005-10-26 11:11

プロダクトをブラックボックスとして扱うのであれば、オープンソースであろうとなかろうと
同じ、つまりわざわざその部分単体でのテストは行わないのが普通だと思いますが、中身を
改変しているとなると話が違いますよね。その改変の影響範囲を見定めた上でテスト計画を
立てる必要があります。

そのプロダクトにテストスイートがついていれば、それを実行してみるのは手だと思いますが、
そうでなければなかなか大変ですよね。

OpenSourceを使っての開発

スキルアップ／キャリアアップ（JOB@IT）