キーワード検索


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

37 件の資料が見つかりました。
ダウンロード数: 28回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
レビューの必要性と重要性については、既に、多くの論文や報告で指摘されている。しかし、納期との兼ね合い、人的リソースの逼迫などが障害となり、必ずしも実施されていない。本論文では、多岐にわたるレビュー項目の内でソフトウェア構造の問題点の発見を、AIを応用することで自動化が可能かどうかを試みた。具体的には、ソフトウェアの構造上の問題でバグが発生しそうなコードを機械学習により特定、そのコードに対する修正方法のヒントを、Fuzzy推論で開発に提示するシステムを構築した。このシステムの有効性等について報告する。
ダウンロード数: 19回
紹介文 :
本研究は、品質保証メンバーが客観的役割を基本としつつ、品質保証活動より得られた知見を活かして、開発プロジェクトに積極的に寄り添ってQCD 問題解決を促進する活動の提案である。
調査分析から、開発プロジェクトが品質保証メンバーに期待する支援範囲を抽出し実践した、大変有用性の高い研究である。
ダウンロード数: 17回
SQuBOK分類 :
年度 : 2018年   分科会 : 2017年度演習コースⅢ
紹介文 :
IoT時代における開発方法論は、セーフティだけやセキュリティだけを意識したものではいけない。例えば、セーフティの考え方では、可用性を重要視するため、機器連携をする際に、情報の機密性を保持できていないことがある。また、セキュリティの考え方では、機密性を重要視するため、利便性や機能性を損なう可能性がある。すなわち、これからIoT時代を迎えるにあたって、セーフティとセキュリティ、それぞれにバランスよく対応できる開発方法論が必要である。しかしながら、バランスよく対応できる開発方法論は確立されておらず、既存のセーフティにおける開発手法や、セキュリティにおける開発手法がどの程度バランスよく対応できる設計手法として使えるのか、検証もされていない。本稿では、セーフティの分野で実績のあるSTAMP/STPAを、セキュリティの分野とコラボレートさせた結果、その有効性を検証できたので、セーフティ&セキュリティ開発のための方法論として提案する。 本発表では、新しい安全解析手法「STAMP/STPA」をセキュリティ適用し、さらに、STRIDEを脅威分析手法として適用したことによる成果を中心に述べる。
ダウンロード数: 17回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
ソフトウェアを短サイクルでリリースしフィードバックを受け改良を加えていくアジャイル開発プロセスを適用した開発では、スプリントで作り込んだ機能の利用者視点での評価は次のスプリントの期間に並行して行われ、そこで不具合が検出された場合にはさらに後続のスプリントで修正が行われている。このことにより、利用者にとって価値が高いソフトウェアのリリーススピードが期待したほど上がらないという問題があった。今回、ソフトウェアの利用時品質を定量的に表現した指標であるUXメトリクスという考え方を導入し、開発スプリントの開始時にUX評価シナリオを作成するとともに、シナリオに対してUXメトリクスの目標値を設定し、開発スプリント内で作り込んだ機能のUXを同一スプリント内で評価・フィードバックする技法を考案した。

本報告では、UXメトリクスを用いた開発スプリント内でのUXの作り込みの概要と、それを実際のソフトウェア開発プロジェクトの現場で適用した際の成果と知見を報告する。
ダウンロード数: 16回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
Selenium等のミドルウェアが整備されたこともあり、WebアプリケーションのUIテストを自動化する事例も増えてきた。しかし、自動テストの開発資産が拡充されるのに比例し、その実行に要する 時間は増大する一方である。
主要なWebブラウザーはヘッドレスモードを搭載しているが、膨大なテストケースの前では「焼け石に水」。UIテストの所要時間を大幅に短縮するには、複数のPCにテストケースを分散するのが最 も効果的である。

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

ラズベリーパイのクラスターでUIテストを並列実行するには、自動テストの開発資産についても根本的な見直しが必要になる。本発表では、クラスター構築のノウハウやUIテストを並列実行するための実践的なテクニックを紹介する。
ダウンロード数: 15回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
当社において、ソフトウェア品質に関する分析を行ったところ、そこで見つかった問題の多くは、その背後にある「慢性的な高負荷状態」や「スキル・ノウハウの伝承不足」といった根本原因によるものであることが分かった。そして、それを引き起こしている最も大きな要因として「特定の作業が特定の人にしか出来ない」といった過度な属人化があり、この状態を解消することなくして継続的な品質向上活動を行うことは困難であるとの結論に至った。

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

このようにして、当社では昨年度から「自工程完結」の考え方をソフトウェア開発に応用した「開発現場のプロセス改善」を、属人化解消の切り口で開始することとなった。本発表では、その活動の概要と進め方、またそのために工夫した点について、事例を交えながら紹介する。
ダウンロード数: 11回
紹介文 :
設計を開始する前に要求の漏れを検知し手戻りを抑制することを目的とした「設計着手前レビュー」を提案しています。
「着手前要求確認フレームワーク」と「区分・パラメータ」シートを考案し、
5W1Hの観点で要求を整理し抜け漏れを検知しやすくするための工夫をしています。
ダウンロード数: 11回
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 の略
 (十分な納得性をもって 組織的な振り返りプロセスを 意思をもって積極的に行動する)
ダウンロード数: 10回
紹介文 :
レビューの品質を第三者が評価して必要に応じて対策を促すことを目的とした「レビュー品質の可視化手法」および新しい品質指標「予測重大欠陥レビュー検出率」を提案しています。
第三者が客観的かつ容易に、そして各プロジェクトの特性を踏まえてレビュー品質を評価出来るように工夫した研究です。
ダウンロード数: 9回
紹介文 :
AI/IoT時代の新しい安全分析手法として注目されているSTAMP/STPA (Systems Theoretic Accident Model and Processes / System Theoretic Process Analysis)は、セーフティとセキュリティのリスクを同時分析が可能であることを本分科会では昨年度、初めて提言しました。今年度はSTAMPを用いた場合と用いない場合に分けて、自動運転の利用シーンを具体化した事例による実験を実施し、STAMPによるセーフティセキュリティ分析の有効性を確認しました。
論文とともに具体的な分析の一連の証跡、分析手順、実験の質問事項や結果、用語集など、利用価値の高い付録も収録しています。ぜひご活用ください。
ダウンロード数: 9回
SQuBOK分類 :
年度 : 2018年   分科会 : 2017年度研究コース2
紹介文 :
レビューを実施しても、重大欠陥の検出漏れは後を絶たない。検出漏れが発生する要因の一つとして、欠陥の検出難易度が高いことが挙げられる。検出難易度が高い欠陥とは、レビュー対象である成果物から記載すべき内容が抜け落ちている欠陥、将来の運用や保守性について考慮が漏れている欠陥が該当する。すなわち、検出難易度の高い欠陥は、成果物の記載内容のみをレビューしていては検出できない。

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

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

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

効果検証により、重大欠陥・検出難易度の高い欠陥の検出にD2BOCs法が有効であることを確認できた。
ダウンロード数: 7回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
システムの出荷後障害を分析したところ、運用を考慮した設計が不十分であることが原因で重大な障害を引き起こしていることが分かった。
運用を考慮した設計を行うためには、設計書レビューに運用の観点を取り入れることが重要と考える。
レビューに観点を取り入れるPerspective-Based Reading(PBR)を開発プロジェクトで実践できるようにするため、全国7拠点113名のエンジニアに対し、レビュー手法の演習教育を実施した。
当部門では、個人の経験に基づいたレビュー(Ad Hoc Reading:AHR)を行うプロジェクトが多い背景を踏まえて、教育ではPBRとAHRの違いを参加者が実感できるような工夫を行った。
また、AHRとPBRのレビュー結果から得られたPBRの有効性について報告する。
ダウンロード数: 7回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
我々の部門では昨年度より、開発プロジェクトの一部に、アジャイルプラクティスの導入を推進している。しかし、いくつかのプロジェクトは品質が安定せず、市場不具合が発生していた。そこで、市場不具合を起こしているプロジェクトの傾向を分析すると、バグの摘出がリリース直前に偏っていることが分かった。本発表では、従来ウォーターフォール開発で使われていた「欠陥摘出前倒し率」を、アジャイル開発のようなイテレーティブな開発にも適用可能に改良し、その有用性を検証したため、その取り組みを紹介する。
本取り組みの成果は以下の2点である。

1.「前倒し率」と市場不具合には有意な相関があり、メトリクスの有用性が確認できた。ただし、事例数が少なく、リリース後の経過時間も短いため、継続的な検証が必要である。
2.「前倒し率」は、欠陥をバグトラッキングシステムで管理していれば計算可能であり、メトリクス収集のための追加工数がほとんど必要ない。
ダウンロード数: 7回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
ものづくりの観点である「製品品質」は、開発者にとっては当たり前の観点となっているため、SQuaREの品質モデルを知らなくてもレビュー時に使われていることが多い。
しかし、「製品品質」だけでは顧客の要求など顧客視点をカバーできず、ドキュメントレビューにおいて見落としが生じてしまう。
そこで、品質モデルの一つである「利用時の品質」をドキュメントレビューの観点に取り入れることでレビュー時の顧客視点の不足による見落としが減ると考え、「利用時の品質」観点に基づくドキュメントレビューのための教育カリキュラムを作成した。
カリキュラムは、「利用時の品質」を考慮し「利用時の品質」「製品品質」の関係性を理解してもらい、さらに、レビューの演習を実施し現場で活用できるレベルまで落とし込める内容とした。
我々の狙いは、「利用時の品質」「製品品質」をそれぞれ別の観点にするのではなく、「利用時の品質」の品質特性と関連の強い「製品品質」の品質特性を絞り込んで、顧客の利用目的に即したレビューを行うことである。
教育カリキュラムと演習用教材作成に取り組んだ内容を報告する。
ダウンロード数: 6回
紹介文 :
本研究は、開発プロジェクトが抽出した多数のリスクに対して、リスクを産む要因となるリスク事象ドライバーに着眼することで、品質部門がリスクの繋がりを分析(多変量解析によるモデル化)し、妥当性と網羅性の観点でレビューして、開発部門が見落とした可能性のあるリスクや軽減策を提案する、大変有用性の高い研究である。
ダウンロード数: 6回
紹介文 :
レビュー指摘の伝達において、指摘の意図や期待を作成者に上手く伝えることを目的として、「レビューコミュニケーションスタイル手法」を提案しています。
人と人とのコミュニケーションにおいて「人の好みや性格」といった重要とされつつも取り扱うことが難しかった領域に踏み込み、具体的に理論化・手法化してレビューで活用できるように工夫しています。
ダウンロード数: 6回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
「顧客に言われたとおりに製品を作ってリリースした結果、やり直しになった、あるいは、クレームがきた」という事象は日常的に発生しており、それにより大きなコストの無駄や手戻りが発生している。これは、顧客からすべての情報を引き出すことができず、市場のニーズや開発の背景といったシステム開発工程よりもさらに上流の情報についてを明らかにせず要求や仕様化したうえ、このような状態で作成された仕様書に対して、以下の手段でレビューしていることが原因なのではないかと考えている。

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

その結果、必要な指摘が行われずにレビューを通過してしまうことで、顧客の事前期待や要望を満たしていないまま仕様を確定し、その仕様を実装した結果、このような事態になってしまうのではないだろうか。
我々はそのような状態で作成された仕様書でも、市場のニーズや開発の背景からレビューの観点を導き出し、その観点をもとに仕様書をレビューすることで、ユーザーの利用時や顧客の課題、解決したい問題に応える仕様とするための指摘を行えるのではないかと考え、“コンセプトベースでレビュー”と名付けた手法を実施して検証を行った。
本発表では、その手法の紹介と、検証結果について説明する。
ダウンロード数: 6回
SQuBOK分類 :
年度 : 2018年   分科会 : 2017年度研究コース6
紹介文 :
システム開発における仕様書や設計書は、制御された抽象度を保った厳密な記述により、開発対象が何であるのか、どう作るのかを明らかにする必要がある。また、開発者やテスト設計者などの後工程担当者の様々な関心事に応じて、参照・活用しやすい情報として整理されていることが望ましい。さらに、例えば機能仕様からテスト仕様を生成するなどの自動処理が実現できれば、開発を効率化することができる。そこで我々は、システム開発における基本設計書を対象としたテストケース一覧を自動生成するツールの検討を通して、設計書フォーマットの書きやすさや読みやすさ、テストケースへの自動変換、仕様記述の自由度について実験、考察した。

本論文では、仕様の構造化や、記述方法を制約するなどの試行錯誤をしていくアプローチを通して、特に、仕様の内容と記述に対する自由度を持たせる方法に関する議論をすることで、「制約を、自動化できる最小限にとどめ、仕様を記述するための自由度を残しつつ、後工程でもつかいやすい」基本設計書フォーマットを作成するためのアプローチを提案する。
ダウンロード数: 6回
SQuBOK分類 :
年度 : 2018年   分科会 :
紹介文 :
短納期型開発プロジェクトは要件定義・開発・テストが並行で実施されることが多く、以下の理由によりテスト工数の増加を招くという問題があった。

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

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

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

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

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

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

本発表では、分析フレームワークで技術者の思考を段階的に誘導し、GSN(Goal Structuring Notation)とESD(Event Sequence Diagram)のビューによるレビューを行う方法で解決を試みた結果を説明する。
  

1

2
↑