キーワード検索


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

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

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

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

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

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

本報告では、UXメトリクスを用いた開発スプリント内でのUXの作り込みの概要と、それを実際のソフトウェア開発プロジェクトの現場で適用した際の成果と知見を報告する。
ダウンロード数: 36回
SQuBOK分類 :
年度 : 2018年   分科会 : 2017年度演習コースⅢ
紹介文 :
IoT時代における開発方法論は、セーフティだけやセキュリティだけを意識したものではいけない。例えば、セーフティの考え方では、可用性を重要視するため、機器連携をする際に、情報の機密性を保持できていないことがある。また、セキュリティの考え方では、機密性を重要視するため、利便性や機能性を損なう可能性がある。すなわち、これからIoT時代を迎えるにあたって、セーフティとセキュリティ、それぞれにバランスよく対応できる開発方法論が必要である。しかしながら、バランスよく対応できる開発方法論は確立されておらず、既存のセーフティにおける開発手法や、セキュリティにおける開発手法がどの程度バランスよく対応できる設計手法として使えるのか、検証もされていない。本稿では、セーフティの分野で実績のあるSTAMP/STPAを、セキュリティの分野とコラボレートさせた結果、その有効性を検証できたので、セーフティ&セキュリティ開発のための方法論として提案する。 本発表では、新しい安全解析手法「STAMP/STPA」をセキュリティ適用し、さらに、STRIDEを脅威分析手法として適用したことによる成果を中心に述べる。
ダウンロード数: 33回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
研究開発におけるソフトウェアプロダクトは、インキュベーションから商用にいたるまで幅広く、その種類も業務アプリケーション、メディア処理エンジン、OSS、ミドルウェアなど多種多様である。こうしたプロダクトの多様性が開発ベンダやリリース先の事業サイドとのトラブルの原因になることがある。例えば、開発主管が品質(非機能要件)の作りこみの程度を把握できていないために開発作業に過不足があり要求する品質を達成できない場合や、開発主管(研究所)が想定していない使い方を事業サイドがする場合である。このような問題を解決するために、利用条件を明確化し、どのような品質を念頭において開発をするかをあらかじめ計画することを徹底することが求められていた。

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

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

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

本発表では、分析フレームワークで技術者の思考を段階的に誘導し、GSN(Goal Structuring Notation)とESD(Event Sequence Diagram)のビューによるレビューを行う方法で解決を試みた結果を説明する。
ダウンロード数: 31回
紹介文 :
本研究は、品質保証メンバーが客観的役割を基本としつつ、品質保証活動より得られた知見を活かして、開発プロジェクトに積極的に寄り添ってQCD 問題解決を促進する活動の提案である。
調査分析から、開発プロジェクトが品質保証メンバーに期待する支援範囲を抽出し実践した、大変有用性の高い研究である。
ダウンロード数: 31回
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 の略
 (十分な納得性をもって 組織的な振り返りプロセスを 意思をもって積極的に行動する)
ダウンロード数: 30回
紹介文 :
設計を開始する前に要求の漏れを検知し手戻りを抑制することを目的とした「設計着手前レビュー」を提案しています。
「着手前要求確認フレームワーク」と「区分・パラメータ」シートを考案し、
5W1Hの観点で要求を整理し抜け漏れを検知しやすくするための工夫をしています。
ダウンロード数: 30回
SQuBOK分類 :
年度 : 2018年   分科会 : 2017年度研究コース2
紹介文 :
レビューを実施しても、重大欠陥の検出漏れは後を絶たない。検出漏れが発生する要因の一つとして、欠陥の検出難易度が高いことが挙げられる。検出難易度が高い欠陥とは、レビュー対象である成果物から記載すべき内容が抜け落ちている欠陥、将来の運用や保守性について考慮が漏れている欠陥が該当する。すなわち、検出難易度の高い欠陥は、成果物の記載内容のみをレビューしていては検出できない。

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

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

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

効果検証により、重大欠陥・検出難易度の高い欠陥の検出にD2BOCs法が有効であることを確認できた。
ダウンロード数: 29回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
プロジェクトを遂行する上で、一番厄介なものは人間関係といえる。
プロジェクト内での衝突・言った言わない問題などに代表される人間が関わる問題・課題をできる限り事前に取り除き、プロジェクトの失敗をなくすことが理想である。
本稿では、上述の問題・課題としてコミュニケーションエラーに焦点を当て、解決へのアプローチを提案する。

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

そのアプローチ方法として、マズローの欲求段階と TOC の抵抗の六階層を用いてモデル化したもの、およびツールや手法などによる解決手段を心理的障壁(エラー特性の各分類)ごとに分類したRPGモデル(仮)を提案する。
ダウンロード数: 29回
SQuBOK分類 :
年度 : 2018年   分科会 : 2017年度第5分科会
紹介文 :
ソフトウェアのメンテナンスフェーズを対象とした欠陥の分析や予測は、新規開発と並んで重要である。また、現状のメンテナンスフェーズにおける品質関連の研究の多くは、残存欠陥の「数」に着目したものである。

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

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

本発表では、CDAMの詳細について実例を交えながら報告する。その上で、欠陥検知の周期性と変動要因を認知することで可能になる、ソフトウェアの品質向上のためのアプローチを提案する。
ダウンロード数: 28回
紹介文 :
AI/IoT時代の新しい安全分析手法として注目されているSTAMP/STPA (Systems Theoretic Accident Model and Processes / System Theoretic Process Analysis)は、セーフティとセキュリティのリスクを同時分析が可能であることを本分科会では昨年度、初めて提言しました。今年度はSTAMPを用いた場合と用いない場合に分けて、自動運転の利用シーンを具体化した事例による実験を実施し、STAMPによるセーフティセキュリティ分析の有効性を確認しました。
論文とともに具体的な分析の一連の証跡、分析手順、実験の質問事項や結果、用語集など、利用価値の高い付録も収録しています。ぜひご活用ください。
ダウンロード数: 24回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
「顧客に言われたとおりに製品を作ってリリースした結果、やり直しになった、あるいは、クレームがきた」という事象は日常的に発生しており、それにより大きなコストの無駄や手戻りが発生している。これは、顧客からすべての情報を引き出すことができず、市場のニーズや開発の背景といったシステム開発工程よりもさらに上流の情報についてを明らかにせず要求や仕様化したうえ、このような状態で作成された仕様書に対して、以下の手段でレビューしていることが原因なのではないかと考えている。

・自らの知識を頼りに、仕様に記載された内容のみをレビューしている。
・要求と仕様を比較するだけのレビューをしている。

その結果、必要な指摘が行われずにレビューを通過してしまうことで、顧客の事前期待や要望を満たしていないまま仕様を確定し、その仕様を実装した結果、このような事態になってしまうのではないだろうか。
我々はそのような状態で作成された仕様書でも、市場のニーズや開発の背景からレビューの観点を導き出し、その観点をもとに仕様書をレビューすることで、ユーザーの利用時や顧客の課題、解決したい問題に応える仕様とするための指摘を行えるのではないかと考え、“コンセプトベースでレビュー”と名付けた手法を実施して検証を行った。
本発表では、その手法の紹介と、検証結果について説明する。
ダウンロード数: 24回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
既存システムの改修を行う派生開発では、スクラッチ開発に較べて開発コスト、期間を低減できるメリットがある一方、無影響確認を含めた大規模なテストが必要となるが、開発側が作成したテストケースの妥当性を顧客側が判断する事は時間的にもスキル的にも難しいのが一般的である。

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

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

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

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

本研究では、「設計制約の変化から影響を受ける箇所」を漏れなく特定するために、ベースソフト調査手法を開発した。提案手法の技術要素として、「欠陥混入メカニズムの知識の表現方法」と「欠陥混入メカニズムの知識を活用したDRBFM実施手順」の2つを定義した。
実験により、提案手法を適用することで、過去に発生した変更箇所の特定漏れが再現しないことを確認した。本手法を実開発に適用することで、派生開発における変更漏れ確実に防止する効果が期待できる。
ダウンロード数: 23回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
ソフトウェア開発で行われるようなプロジェクトの完遂までに生じる諸問題を検討するタイプの会議を対象として考える。ステークホルダーは会議を開き、議論を通して現状を認識し、問題に対する合意形成を行う。

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

記録されなかったために問題として認識されず、議論もされなかったために問題は潜在化したままになったのである。我々はこの問題を解消するためには、まず会議で参加者が想起した意見をそのタイミングで収集して記録する必要があると考える。我々はMinute Paperと呼ばれる質問紙でそのような意見が記録できるか実験を通して確認し、それをフィードバックすることで今後の議論に含めることができるか検証した。
ダウンロード数: 23回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
我々の部門では昨年度より、開発プロジェクトの一部に、アジャイルプラクティスの導入を推進している。しかし、いくつかのプロジェクトは品質が安定せず、市場不具合が発生していた。そこで、市場不具合を起こしているプロジェクトの傾向を分析すると、バグの摘出がリリース直前に偏っていることが分かった。本発表では、従来ウォーターフォール開発で使われていた「欠陥摘出前倒し率」を、アジャイル開発のようなイテレーティブな開発にも適用可能に改良し、その有用性を検証したため、その取り組みを紹介する。
本取り組みの成果は以下の2点である。

1.「前倒し率」と市場不具合には有意な相関があり、メトリクスの有用性が確認できた。ただし、事例数が少なく、リリース後の経過時間も短いため、継続的な検証が必要である。
2.「前倒し率」は、欠陥をバグトラッキングシステムで管理していれば計算可能であり、メトリクス収集のための追加工数がほとんど必要ない。
ダウンロード数: 22回
紹介文 :
レビューの品質を第三者が評価して必要に応じて対策を促すことを目的とした「レビュー品質の可視化手法」および新しい品質指標「予測重大欠陥レビュー検出率」を提案しています。
第三者が客観的かつ容易に、そして各プロジェクトの特性を踏まえてレビュー品質を評価出来るように工夫した研究です。
  

1

2
↑