5 件の資料が見つかりました。
ダウンロード数: 2144回
紹介文 :
予め指摘難易度の異なる欠陥を埋め込んだ仕様書を被験者にレビューさせ、的確に指摘ができるかを見るという興味深い実験をしている。実験結果として、難易度が一番簡単な欠陥は有意に指摘率が高かった。指摘率と被験者の開発経験には有意な関係は見られなかった。実験結果は部分的な成果ではあったが、要求から仕様に落とす際のパターンをモデル化し、その難易度を設定した「要求分析スキルモデル」はスキル評価以外にも大いに活用できるであろう。
予め指摘難易度の異なる欠陥を埋め込んだ仕様書を被験者にレビューさせ、的確に指摘ができるかを見るという興味深い実験をしている。実験結果として、難易度が一番簡単な欠陥は有意に指摘率が高かった。指摘率と被験者の開発経験には有意な関係は見られなかった。実験結果は部分的な成果ではあったが、要求から仕様に落とす際のパターンをモデル化し、その難易度を設定した「要求分析スキルモデル」はスキル評価以外にも大いに活用できるであろう。
ダウンロード数: 1173回
紹介文 :
レビュー担当者のスキルおよび欠陥の種類の違いによって、レビュー手法の有効性にどのような影響を与えるのか、その関係を実験により明らかにしています。実験結果では、ユーザやテスト担当者などの観点別に行うレビュー手法が (Perspective-based Reading: PBR)、経験や知識がない人でも,高い精度で欠陥が検出できることが示されています。
レビュー担当者のスキルおよび欠陥の種類の違いによって、レビュー手法の有効性にどのような影響を与えるのか、その関係を実験により明らかにしています。実験結果では、ユーザやテスト担当者などの観点別に行うレビュー手法が (Perspective-based Reading: PBR)、経験や知識がない人でも,高い精度で欠陥が検出できることが示されています。
ダウンロード数: 849回
SQuBOK分類 :
紹介文 :
近年のソフトウェア開発では流用開発やOSSの活用等、開発者は他者が開発した機能を開発対象に組み込むことが一般化してきている。この開発方法は開発工数の大幅な削減が期待できる。その一方で、他者が開発した機能を取り込むことで、開発対象のソースコードがブラックボックス化・複雑化し、ソースコードの品質劣化による障害の誘発や、障害調査・修正に多くの時間を要する等の問題が発生している。開発者に開発対象のソースコードの品質情報を提供すれば、問題の早期発見や修正時間の短縮化につながると考え、ソースコードの品質状況をメトリクスにより自動測定し、定量的に把握する仕組みの確立、および開発現場への展開を行ってきた。しかし、開発現場からは「メトリクスを見ても対応方法が判らない」等の声があがっており、定量的なメトリクス情報に基づいてソースコードの品質を改善するプロセスが現場に根付かない問題があった。
そこで本稿ではソースコードの品質劣化を表すメトリクスと、その後のソースコードの修正回数や修正日数(品質リスクと呼ぶ)との関係を分析し、これらの間に関連があることを示す。これにより開発者にメトリクスを活用したソースコード品質改善の早期対応への動機づけを行う。あわせて品質リスクへの具体的な対応案を開発現場に提示し、品質劣化を防止することで、追加コストの発生および納期遅延を未然防止することを狙いとする。
近年のソフトウェア開発では流用開発やOSSの活用等、開発者は他者が開発した機能を開発対象に組み込むことが一般化してきている。この開発方法は開発工数の大幅な削減が期待できる。その一方で、他者が開発した機能を取り込むことで、開発対象のソースコードがブラックボックス化・複雑化し、ソースコードの品質劣化による障害の誘発や、障害調査・修正に多くの時間を要する等の問題が発生している。開発者に開発対象のソースコードの品質情報を提供すれば、問題の早期発見や修正時間の短縮化につながると考え、ソースコードの品質状況をメトリクスにより自動測定し、定量的に把握する仕組みの確立、および開発現場への展開を行ってきた。しかし、開発現場からは「メトリクスを見ても対応方法が判らない」等の声があがっており、定量的なメトリクス情報に基づいてソースコードの品質を改善するプロセスが現場に根付かない問題があった。
そこで本稿ではソースコードの品質劣化を表すメトリクスと、その後のソースコードの修正回数や修正日数(品質リスクと呼ぶ)との関係を分析し、これらの間に関連があることを示す。これにより開発者にメトリクスを活用したソースコード品質改善の早期対応への動機づけを行う。あわせて品質リスクへの具体的な対応案を開発現場に提示し、品質劣化を防止することで、追加コストの発生および納期遅延を未然防止することを狙いとする。
ダウンロード数: 311回
紹介文 :
単体テストで見逃す欠陥数に最も相関が高いのが規模であるという、非常に単純かつ強烈なメッセージを投げかけています。データ分析の進め方という意味では非常に参考になる論文です。サイクロマティック数やネスト深さなどいかにも関係ありそうな数値はあまり効いていないことがわかるのもよい点です。ただ惜しむらくは、肝心の規模等すべて相対値なので、読んですぐ使えるタイプの論文ではありません。また対象としているソフトウェア規模も比較的小さく、実験的性格の強い論文であることを念頭に置いて読む必要があるでしょう。
単体テストで見逃す欠陥数に最も相関が高いのが規模であるという、非常に単純かつ強烈なメッセージを投げかけています。データ分析の進め方という意味では非常に参考になる論文です。サイクロマティック数やネスト深さなどいかにも関係ありそうな数値はあまり効いていないことがわかるのもよい点です。ただ惜しむらくは、肝心の規模等すべて相対値なので、読んですぐ使えるタイプの論文ではありません。また対象としているソフトウェア規模も比較的小さく、実験的性格の強い論文であることを念頭に置いて読む必要があるでしょう。
ダウンロード数: 85回
SQuBOK分類 :
紹介文 :
ウォーターフォール型ソフトウェア開発は前工程を終えたのちに後工程を開始し、後戻りすることなく逐次的に進めるものとして一般に 認識されている。しかしウォーターフォールモデルにおいて隣り合う2工程の間には双方向の関係がありこの関係のためそれらの工程は部分的に並行して実施され得る。筆者らの経験においてもウォーターフォール型ソフトウェア開発の日程計画において工程間に重なりを持たせることはしばしば行われている 。ウォーターフォール型ソフトウェア開発は工程が逐次的に進められることが基本ではあるものの、工程間に重なりを持たせた日程計画を立てることは一般的なことであるといえる 。工程間に重なりを持たせることにはメリットとデメリットの両面がある。工程を重ねることで作業を並行して実施することができ、開発期間を短縮できたり次工程の作業者の手持ち時間を減らせたりできるなどのメリットが 得られ る。これにより、プロジェクトの利益率向上が期待される。一方で過度に工程を重ねてしまうと前工程で生じた変更が次工程またはそれ以降の工程での後戻り作業を増やすことになり計画時に比べて品質やコストに悪影響を及ぼしてしまう。これにより、プロジェクトの利益率が悪化するリスクが高くなってしまう 。工程間の重なりに関する検討は、これまでシミュレーション研究として扱われたり、並行ソフトウェア開発などのプロセスモデルとして論じられたりしてきた 。しかし、ウォーターフォール型ソフトウェア開発における工程の重なりがプロジェクトの利益率にどのような影響を与えるのかについての実証的な取り組みは筆者らが知る限り十分に示されていない 。アジャイル開発が広がりを見せている一方で、 ウォーターフォール型ソフトウェア開発は依然として広く利用されておりそれを適用することが望ましい場合や顧客都合などの理由によりそれを適用せざるを得ない場合もある。ウォーターフォール型ソフトウェア開発における工程間の重なりと利益率の関係に関する知見を実証的に導き出し、開発現場へと適用することは意義ある取り組みであると筆者らは考えている 。
本論文ではウォーターフォール型ソフトウェア開発プロジェクトを対象に収集したデータを基に工程の重なりと利益率との関係について分析を行う。 工程の重なりにはメリットとデメリットの両面があり重なりの度合いは利益率に何らかの関係がある可能性がある 。また、工程を個別に見たときにどの工程とどの工程の重なりが利益率と関わりがあるのかについて掘り下げて検討する必要がある。 さらに、品質メトリクスを含めて総合的に捉えたときに、利益率に関わる要因同士の構造が明らかになれば、プロジェクトの日程計画を立案する上で有益な知見が得られるものと期待できる 。そのため本研究では次のResearch Questionsを設定する。
RQ1プロジェクト全体で見た工程の重なりと利益率との間には、どのような関係があるのか。
RQ2:工程の重なりを個別に見たときに、利益率と関わりのある工程はどれか 。
RQ3 工程の重なりと品質メトリクスを用いて、利益率を説明することはできるか。
2章では分析対象について述べたのちに 、分析に用いた変数である工程の重なり、利益率予実差、および品質メトリクスについて、それぞれの概要とデータの概要を示す。 3章ではRQ1からRQ3についての分析結果を示す。 4章で考察を述べ、最後に5章でまとめを述べる。
ウォーターフォール型ソフトウェア開発は前工程を終えたのちに後工程を開始し、後戻りすることなく逐次的に進めるものとして一般に 認識されている。しかしウォーターフォールモデルにおいて隣り合う2工程の間には双方向の関係がありこの関係のためそれらの工程は部分的に並行して実施され得る。筆者らの経験においてもウォーターフォール型ソフトウェア開発の日程計画において工程間に重なりを持たせることはしばしば行われている 。ウォーターフォール型ソフトウェア開発は工程が逐次的に進められることが基本ではあるものの、工程間に重なりを持たせた日程計画を立てることは一般的なことであるといえる 。工程間に重なりを持たせることにはメリットとデメリットの両面がある。工程を重ねることで作業を並行して実施することができ、開発期間を短縮できたり次工程の作業者の手持ち時間を減らせたりできるなどのメリットが 得られ る。これにより、プロジェクトの利益率向上が期待される。一方で過度に工程を重ねてしまうと前工程で生じた変更が次工程またはそれ以降の工程での後戻り作業を増やすことになり計画時に比べて品質やコストに悪影響を及ぼしてしまう。これにより、プロジェクトの利益率が悪化するリスクが高くなってしまう 。工程間の重なりに関する検討は、これまでシミュレーション研究として扱われたり、並行ソフトウェア開発などのプロセスモデルとして論じられたりしてきた 。しかし、ウォーターフォール型ソフトウェア開発における工程の重なりがプロジェクトの利益率にどのような影響を与えるのかについての実証的な取り組みは筆者らが知る限り十分に示されていない 。アジャイル開発が広がりを見せている一方で、 ウォーターフォール型ソフトウェア開発は依然として広く利用されておりそれを適用することが望ましい場合や顧客都合などの理由によりそれを適用せざるを得ない場合もある。ウォーターフォール型ソフトウェア開発における工程間の重なりと利益率の関係に関する知見を実証的に導き出し、開発現場へと適用することは意義ある取り組みであると筆者らは考えている 。
本論文ではウォーターフォール型ソフトウェア開発プロジェクトを対象に収集したデータを基に工程の重なりと利益率との関係について分析を行う。 工程の重なりにはメリットとデメリットの両面があり重なりの度合いは利益率に何らかの関係がある可能性がある 。また、工程を個別に見たときにどの工程とどの工程の重なりが利益率と関わりがあるのかについて掘り下げて検討する必要がある。 さらに、品質メトリクスを含めて総合的に捉えたときに、利益率に関わる要因同士の構造が明らかになれば、プロジェクトの日程計画を立案する上で有益な知見が得られるものと期待できる 。そのため本研究では次のResearch Questionsを設定する。
RQ1プロジェクト全体で見た工程の重なりと利益率との間には、どのような関係があるのか。
RQ2:工程の重なりを個別に見たときに、利益率と関わりのある工程はどれか 。
RQ3 工程の重なりと品質メトリクスを用いて、利益率を説明することはできるか。
2章では分析対象について述べたのちに 、分析に用いた変数である工程の重なり、利益率予実差、および品質メトリクスについて、それぞれの概要とデータの概要を示す。 3章ではRQ1からRQ3についての分析結果を示す。 4章で考察を述べ、最後に5章でまとめを述べる。