キーワード検索


 2001年    2002年    2003年
 2004年    2005年    2006年
 2007年    2008年    2009年
 2010年    2011年    2012年
 2013年    2014年    2015年
 2016年    2017年    2018年

37 件の資料が見つかりました。
ダウンロード数: 78回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
レビューの必要性と重要性については、既に、多くの論文や報告で指摘されている。しかし、納期との兼ね合い、人的リソースの逼迫などが障害となり、必ずしも実施されていない。本論文では、多岐にわたるレビュー項目の内でソフトウェア構造の問題点の発見を、AIを応用することで自動化が可能かどうかを試みた。具体的には、ソフトウェアの構造上の問題でバグが発生しそうなコードを機械学習により特定、そのコードに対する修正方法のヒントを、Fuzzy推論で開発に提示するシステムを構築した。このシステムの有効性等について報告する。
ダウンロード数: 69回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
当社において、ソフトウェア品質に関する分析を行ったところ、そこで見つかった問題の多くは、その背後にある「慢性的な高負荷状態」や「スキル・ノウハウの伝承不足」といった根本原因によるものであることが分かった。そして、それを引き起こしている最も大きな要因として「特定の作業が特定の人にしか出来ない」といった過度な属人化があり、この状態を解消することなくして継続的な品質向上活動を行うことは困難であるとの結論に至った。

品質向上活動では、ベストプラクティスを手順化するといった標準化の方法が一般的である。しかし、属人化してしまう知識やノウハウは、ユーザ業務やアプリケーションが異なれば、まったく別のものとなる。そのため、この属人化の問題は、標準化アプローチによって解消できるものではなかった。では、どのように取り組めばよいのか。さんざん悩んだ末、トヨタ自動車の「自工程完結」に問題解決のヒントを見出すこととなった。

このようにして、当社では昨年度から「自工程完結」の考え方をソフトウェア開発に応用した「開発現場のプロセス改善」を、属人化解消の切り口で開始することとなった。本発表では、その活動の概要と進め方、またそのために工夫した点について、事例を交えながら紹介する。
ダウンロード数: 59回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
Selenium等のミドルウェアが整備されたこともあり、WebアプリケーションのUIテストを自動化する事例も増えてきた。しかし、自動テストの開発資産が拡充されるのに比例し、その実行に要する 時間は増大する一方である。
主要なWebブラウザーはヘッドレスモードを搭載しているが、膨大なテストケースの前では「焼け石に水」。UIテストの所要時間を大幅に短縮するには、複数のPCにテストケースを分散するのが最 も効果的である。

そこで注目されるのがラズベリーパイである。インテルのプロセッサを搭載したPCに比べると、スペック的にはだいぶ見劣りするものの、テストクライアントとしての性能は十分である。足りていないのは、(CPUパワーではなく)クライアントの数だからである。
ラズベリーパイは、Ubuntuなどのディストリビューションが利用できるLinux PCである。Linuxのソフトウェア資産をそのまま継承できるため、Dockerコンテナを稼働させることも可能である。ラ ズベリーパイを8台、16台、32台とクラスタリングすることで、数世代前のスパコンに匹敵する計算能力を手にすることができる。

ラズベリーパイのクラスターでUIテストを並列実行するには、自動テストの開発資産についても根本的な見直しが必要になる。本発表では、クラスター構築のノウハウやUIテストを並列実行するための実践的なテクニックを紹介する。
ダウンロード数: 55回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
ソフトウェアを短サイクルでリリースしフィードバックを受け改良を加えていくアジャイル開発プロセスを適用した開発では、スプリントで作り込んだ機能の利用者視点での評価は次のスプリントの期間に並行して行われ、そこで不具合が検出された場合にはさらに後続のスプリントで修正が行われている。このことにより、利用者にとって価値が高いソフトウェアのリリーススピードが期待したほど上がらないという問題があった。今回、ソフトウェアの利用時品質を定量的に表現した指標であるUXメトリクスという考え方を導入し、開発スプリントの開始時にUX評価シナリオを作成するとともに、シナリオに対してUXメトリクスの目標値を設定し、開発スプリント内で作り込んだ機能のUXを同一スプリント内で評価・フィードバックする技法を考案した。

本報告では、UXメトリクスを用いた開発スプリント内でのUXの作り込みの概要と、それを実際のソフトウェア開発プロジェクトの現場で適用した際の成果と知見を報告する。
ダウンロード数: 47回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
開発プロジェクトの終了時に「振り返り」を行い、次の開発プロジェクトへの教訓として「KPT(KEEP:良い点、PROBLEM:問題点、TRY:改善点)」を挙げている。
しかし、次の開発プロジェクトでKPTが十分実践されていないという問題がある。
本問題に対し、以下2つの原因があると考えた。
・振り返りが不十分で、KPTの内容に納得感がない。
・次の開発プロジェクトでの実践を、プロジェクト内メンバに任せている。

そこで、我々は「FOPA(*)振り返りプロセス」を作成し、「十分な振り返り実現による納得性向上」と「KPTの実践支援方法確立」を実現することで、これらの原因を対処した。

さらに、開発現場での実践を通じて「より手軽に振り返りを行い、かつKPTの実践支援を強化したい。」という意見を受け、「FOPA振り返りプロセス Ver.2」として改善し、プロセスの軽量化と支 援体制の強化を行った。

本発表では、「FOPA振り返りプロセス Ver.2」における、狙い、プロセス体系と内容、開発現場での効果検証結果、および今後のさらなる活用に向けた展望について述べる。


*FOPA: Full persuasive and Organized Process of retrospective with Aggressiveness の略
 (十分な納得性をもって 組織的な振り返りプロセスを 意思をもって積極的に行動する)
ダウンロード数: 45回
SQuBOK分類 :
年度 : 2018年   分科会 : 2017年度研究コース2
紹介文 :
レビューを実施しても、重大欠陥の検出漏れは後を絶たない。検出漏れが発生する要因の一つとして、欠陥の検出難易度が高いことが挙げられる。検出難易度が高い欠陥とは、レビュー対象である成果物から記載すべき内容が抜け落ちている欠陥、将来の運用や保守性について考慮が漏れている欠陥が該当する。すなわち、検出難易度の高い欠陥は、成果物の記載内容のみをレビューしていては検出できない。

そこで我々は、作成者に掛かる認知バイアスに着目した。認知バイアスとは、人の思考を無意識に歪め、誘導するものである。作成者が認知バイアスに掛かることで、ヒューマンエラーが引き起こされる。その結果、成果物に必要な情報が記載されず、検出難易度の高い欠陥を混入してしまうのである。

本発表では、認知バイアスに着目したレビュー手法として、D2BOCs(Defect Detection from Background of Cognitive bias)法を提案する。D2BOCs法の特徴は以下の二つである。

1.認知バイアスを推測し、欠陥の傾向を特定する
2.高リスクの範囲を重点的にレビューする

効果検証により、重大欠陥・検出難易度の高い欠陥の検出にD2BOCs法が有効であることを確認できた。
ダウンロード数: 44回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
JAXAでは、新規のシステムを開発する際、ソフトウェアの要求定義や設計段階で、要求の抽出や設計のレビュー、試験ケースの網羅性向上、運用への制約を抽出するためにFMEA(故障モードと影響解析)を行っている。FMEAの効果を向上させるためには、一般的に「故障モード」を如何に網羅的に導出するかと、システムへの影響が大きい「故障」を洗い出せるかが重要である。一方、ソフトウェアの製品としての特性からFMEAを適用する際、下記の課題が発生していた。

課題①:ソフトウェアへFMEAを適用する単位は抽象的なアイテムになるため、ソフトウェアの「故障(求められる機能を遂行できない)」を発想する難易度が高い。
課題②:ソフトウェアは、システムの利用や運用状況を分析して製作されるため、アイテム(機能等)の特性に合わせた上位システムへの影響を分析する難易度が高い。

本発表では、分析フレームワークで技術者の思考を段階的に誘導し、GSN(Goal Structuring Notation)とESD(Event Sequence Diagram)のビューによるレビューを行う方法で解決を試みた結果を説明する。
ダウンロード数: 44回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
研究開発におけるソフトウェアプロダクトは、インキュベーションから商用にいたるまで幅広く、その種類も業務アプリケーション、メディア処理エンジン、OSS、ミドルウェアなど多種多様である。こうしたプロダクトの多様性が開発ベンダやリリース先の事業サイドとのトラブルの原因になることがある。例えば、開発主管が品質(非機能要件)の作りこみの程度を把握できていないために開発作業に過不足があり要求する品質を達成できない場合や、開発主管(研究所)が想定していない使い方を事業サイドがする場合である。このような問題を解決するために、利用条件を明確化し、どのような品質を念頭において開発をするかをあらかじめ計画することを徹底することが求められていた。

そこで、ソフトウェアプロダクトのリスクマネジメントを目的として開発標準を策定し、プロダクトの使われ方で分類した「品質クラス」の概念と、ISO/IEC 9126の品質特性を105の具体的な観点にブレークダウンした「品質確認表」を導入した。それにより、使われ方を意識した非機能要件設定とそれを具現化するための開発作業の具体的な取捨選択が可能になった。
さらに開発標準を中心に据えた(1)リスクマネジメント運用のルール化、(2)形骸化防止のためのモニタリングと第三者チェック、(3)実プロジェクトの開発文書の公開とe-learningによる自学自習、(4)集合知共有を目的とした統計データ公開を制度設計し、システム化を行った。

本発表ではその概要と効果について述べる。
ダウンロード数: 40回
SQuBOK分類 :
年度 : 2018年   分科会 : 2017年度演習コースⅢ
紹介文 :
IoT時代における開発方法論は、セーフティだけやセキュリティだけを意識したものではいけない。例えば、セーフティの考え方では、可用性を重要視するため、機器連携をする際に、情報の機密性を保持できていないことがある。また、セキュリティの考え方では、機密性を重要視するため、利便性や機能性を損なう可能性がある。すなわち、これからIoT時代を迎えるにあたって、セーフティとセキュリティ、それぞれにバランスよく対応できる開発方法論が必要である。しかしながら、バランスよく対応できる開発方法論は確立されておらず、既存のセーフティにおける開発手法や、セキュリティにおける開発手法がどの程度バランスよく対応できる設計手法として使えるのか、検証もされていない。本稿では、セーフティの分野で実績のあるSTAMP/STPAを、セキュリティの分野とコラボレートさせた結果、その有効性を検証できたので、セーフティ&セキュリティ開発のための方法論として提案する。 本発表では、新しい安全解析手法「STAMP/STPA」をセキュリティ適用し、さらに、STRIDEを脅威分析手法として適用したことによる成果を中心に述べる。
ダウンロード数: 39回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
ソフトウェア開発で行われるようなプロジェクトの完遂までに生じる諸問題を検討するタイプの会議を対象として考える。ステークホルダーは会議を開き、議論を通して現状を認識し、問題に対する合意形成を行う。

しかし、我々はその会議において参加者は想起した自分の意見を必ずしもすべて発言という形で表出しないのではないかと考える。例えば会議中に持っていたものの結局発言されなかった意見や会議終了後に思いついた意見など、それらの意見は発言を記録する議事録には記録されていない。しかしその発言されなかった想起のもととなった意見や疑問も消えてしまったと考える理由はない。いつかもう一度想起されて表に出てくる可能性がある。次の会議か次の次の会議かもしかして成果物が出来上がってなにか問題が発生してから思い出されるその意見は、時間やコストを消費し、成果物の機能や特性に影響を及ぼすものであったかも知れない。

記録されなかったために問題として認識されず、議論もされなかったために問題は潜在化したままになったのである。我々はこの問題を解消するためには、まず会議で参加者が想起した意見をそのタイミングで収集して記録する必要があると考える。我々はMinute Paperと呼ばれる質問紙でそのような意見が記録できるか実験を通して確認し、それをフィードバックすることで今後の議論に含めることができるか検証した。
ダウンロード数: 38回
SQuBOK分類 :
年度 : 2018年   分科会 : 2017年度第5分科会
紹介文 :
ソフトウェアのメンテナンスフェーズを対象とした欠陥の分析や予測は、新規開発と並んで重要である。また、現状のメンテナンスフェーズにおける品質関連の研究の多くは、残存欠陥の「数」に着目したものである。

我々は、残存欠陥の検知数には何らかの周期的な変動があり、その変動要因を知ることができればソフトウェア欠陥の発生傾向の分析や予測につなげることが出来るのではないかと考えた。しかし、それを裏付けるような研究は行われていなかった。

そこで我々は、実際のプロジェクトにおける欠陥検知数の特徴的な変動から周期を検出し、それに基づく要因分析を行うことによって、ソフトウェア欠陥の発生傾向の分析や予測を可能にする手法である「CDAM(Cyclic Defect Analysis Method)」を考えた。

本発表では、CDAMの詳細について実例を交えながら報告する。その上で、欠陥検知の周期性と変動要因を認知することで可能になる、ソフトウェアの品質向上のためのアプローチを提案する。
ダウンロード数: 37回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
プロジェクトを遂行する上で、一番厄介なものは人間関係といえる。
プロジェクト内での衝突・言った言わない問題などに代表される人間が関わる問題・課題をできる限り事前に取り除き、プロジェクトの失敗をなくすことが理想である。
本稿では、上述の問題・課題としてコミュニケーションエラーに焦点を当て、解決へのアプローチを提案する。

問題・課題を解決するときには、様々なツールや手法から選択する必要がある。
エラー特性のモデル化、およびツール・手法のモデル化をすることにより、適用特性・場面によって モデルを選択し解決手段を効果的に使うことができる。このことにより、プロジェクトマネジメントの成熟度やチームの友好度が異なる組織においても、これから起こりうる問題・課題に対してモデルを事前に参照し対策を施すことにより、円滑にプロジェクト遂行を行いプロジェクトの失敗を防ぐことができると考える。
これにより、組織やプロジェクトを横断した共通の問題・課題などを解決するためのプラットフォームになるのではと考えた。

そのアプローチ方法として、マズローの欲求段階と TOC の抵抗の六階層を用いてモデル化したもの、およびツールや手法などによる解決手段を心理的障壁(エラー特性の各分類)ごとに分類したRPGモデル(仮)を提案する。
ダウンロード数: 35回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
我々の部門では昨年度より、開発プロジェクトの一部に、アジャイルプラクティスの導入を推進している。しかし、いくつかのプロジェクトは品質が安定せず、市場不具合が発生していた。そこで、市場不具合を起こしているプロジェクトの傾向を分析すると、バグの摘出がリリース直前に偏っていることが分かった。本発表では、従来ウォーターフォール開発で使われていた「欠陥摘出前倒し率」を、アジャイル開発のようなイテレーティブな開発にも適用可能に改良し、その有用性を検証したため、その取り組みを紹介する。
本取り組みの成果は以下の2点である。

1.「前倒し率」と市場不具合には有意な相関があり、メトリクスの有用性が確認できた。ただし、事例数が少なく、リリース後の経過時間も短いため、継続的な検証が必要である。
2.「前倒し率」は、欠陥をバグトラッキングシステムで管理していれば計算可能であり、メトリクス収集のための追加工数がほとんど必要ない。
ダウンロード数: 35回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
ものづくりの観点である「製品品質」は、開発者にとっては当たり前の観点となっているため、SQuaREの品質モデルを知らなくてもレビュー時に使われていることが多い。
しかし、「製品品質」だけでは顧客の要求など顧客視点をカバーできず、ドキュメントレビューにおいて見落としが生じてしまう。
そこで、品質モデルの一つである「利用時の品質」をドキュメントレビューの観点に取り入れることでレビュー時の顧客視点の不足による見落としが減ると考え、「利用時の品質」観点に基づくドキュメントレビューのための教育カリキュラムを作成した。
カリキュラムは、「利用時の品質」を考慮し「利用時の品質」「製品品質」の関係性を理解してもらい、さらに、レビューの演習を実施し現場で活用できるレベルまで落とし込める内容とした。
我々の狙いは、「利用時の品質」「製品品質」をそれぞれ別の観点にするのではなく、「利用時の品質」の品質特性と関連の強い「製品品質」の品質特性を絞り込んで、顧客の利用目的に即したレビューを行うことである。
教育カリキュラムと演習用教材作成に取り組んだ内容を報告する。
ダウンロード数: 34回
紹介文 :
本研究は、品質保証メンバーが客観的役割を基本としつつ、品質保証活動より得られた知見を活かして、開発プロジェクトに積極的に寄り添ってQCD 問題解決を促進する活動の提案である。
調査分析から、開発プロジェクトが品質保証メンバーに期待する支援範囲を抽出し実践した、大変有用性の高い研究である。
ダウンロード数: 34回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
既存システムの改修を行う派生開発では、スクラッチ開発に較べて開発コスト、期間を低減できるメリットがある一方、無影響確認を含めた大規模なテストが必要となるが、開発側が作成したテストケースの妥当性を顧客側が判断する事は時間的にもスキル的にも難しいのが一般的である。

そこで我々は、開発工数見積りにおいては普及が進む第三者による検証をテストケース見積りに応用し、開発側が作成したテストケースと第三者が作成したテストケースを比較し検証する手法を考案した。

本発表では、本手法によりテストケースの網羅性を客観的に評価し適正なテスト計画とする事でテスト品質の向上に寄与できることを示す。 加えて、CRUD表からテストケースを自動生成する手法もあわせて発表する。
ダウンロード数: 32回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
ベースソフトを部分的にしか理解できていない状況での作業が強いられる派生開発において、変更漏れに分類される欠陥の流出を防止することは重要な課題である。
組織の流出欠陥情報を分析し、派生開発で特定が漏れるソースコードの変更箇所には、次の3つのタイプがあることがわかった。

 A)変更仕様から直接特定可能な箇所
 B)ソースコードの変化点から直接影響を受ける箇所
 C)設計制約の変化から影響を受ける箇所

C)の「設計制約の変化から影響を受ける箇所」については、変更漏れを防止するための効果的な手法がなく、変更箇所特定漏れにより、欠陥が流出した。この問題は、ベースソフトの調査が、人の知識・経験に依存していることから起きる。

本研究では、「設計制約の変化から影響を受ける箇所」を漏れなく特定するために、ベースソフト調査手法を開発した。提案手法の技術要素として、「欠陥混入メカニズムの知識の表現方法」と「欠陥混入メカニズムの知識を活用したDRBFM実施手順」の2つを定義した。
実験により、提案手法を適用することで、過去に発生した変更箇所の特定漏れが再現しないことを確認した。本手法を実開発に適用することで、派生開発における変更漏れ確実に防止する効果が期待できる。
ダウンロード数: 31回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
短納期型開発プロジェクトは要件定義・開発・テストが並行で実施されることが多く、以下の理由によりテスト工数の増加を招くという問題があった。

・仕様変更多発のために手順記述式テストの修正による手戻り工数が増える
・テスト実行スケジュールが開発完了のタイミングに左右されるため、計画通りのテストができない

そこで我々は問題解決のために、マインドマップによるテスト分析を活用した探索的テストを適用した。このテスト手法を「FaRSeT(Flexible and Rapid Software Test)/ファルセット」とチーム内で呼んでおり、2015年頃から段階的にブラッシュアップを重ね、多くのプロジェクト(主に短納期の業務系システム)に対して適用してきた。

FaRSeTは、以下の2つの要素から成り立つ。

1.仕様変更の影響を受けづらい業務要件の分析をマインドマップで行い、変更可能性の高いUI部分などは手順記述式テストを採用せずに探索的テストを活用する。
2.開発スケジュールの変更に対応するため、探索的テストマトリクスにて品質状況や実施優先度の可視化と共有を行うことによってテスト実施個所の関係者合意を行う

FaRSeTを短納期プロジェクトへ適用した場合の効果が得られたため、この手法及び効果を報告する。
ダウンロード数: 31回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
ミッションクリティカルなお客様システムに対して、信頼性を中心とした非機能要件の充足性を向上させるために第三者検証を実施している。従来のシステム点検では、システムを構成するハードウェア、ソフトウェアの製品内部仕様や構造が把握できることを前提とし、製品内部の故障事象を始点とするホワイトボックステストにより、リカバリ設計の漏れが無いことを点検し、システム稼働前に障害を検出、対処を行ってきた。

しかしながら、近年のミッションクリティカルシステムはOSSを含めたマルチベンダー構成が主流となっており、構成する製品の内部仕様の全ては公開されていないことから、ホワイトボックステストは適用出来ず、ブラックボックステストによる点検のみとなる。ブラックボックステストの課題は、業務プロセスの無応答のような、外部仕様として表れない例外事象に対するリカバリ設計の不足、および設計漏れにより発生するトラブルを、システム稼働前の点検で検出、対処することが難しいことである。

この課題に対し、内部仕様が不明確なマルチベンダー構成システムの点検手法として、製品内部仕様として表れる故障事象に着目するのではなく、故障がシステムの業務処理に与える影響とその応答をモデル化し、モデル化した応答に対してシステムが備えるべきリカバリ設計を可視化する「フェールセーフ設計に対する点検手法」を開発した。その点検手法と適用結果について報告する。
ダウンロード数: 30回
紹介文 :
設計を開始する前に要求の漏れを検知し手戻りを抑制することを目的とした「設計着手前レビュー」を提案しています。
「着手前要求確認フレームワーク」と「区分・パラメータ」シートを考案し、
5W1Hの観点で要求を整理し抜け漏れを検知しやすくするための工夫をしています。
  

1

2
↑