キーワード検索


 2001年    2002年    2003年
 2004年    2005年    2006年
 2007年    2008年    2009年
 2010年    2011年    2012年
 2013年    2014年    2015年
 2016年    2017年    2018年
 2019年  
43 件の資料が見つかりました。
ダウンロード数: 328回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
ソフトウェア開発プロジェクトの規模は、ソースコードの行数という成果物の量によって定義されるLOC法、またはソフトウェアが提供する機能の量によって定義されるFP法で表現されることが多い。
一方で、サーバ等のハードウェアを導入し、ソフトウェアが稼働するようにIT設備を準備する基盤構築プロジェクトの規模は、メトリクスが確立されていない。
そのため、テストケース数やテスト時に摘出される欠陥数が適切な範囲にあるか、定量的に評価するための品質指標が無い課題がある。
そこで、LOCに該当する基盤構築プロジェクトの規模を表現するメトリクスを導出することで、この課題を解決できると仮説を立てた。
構築スケールに基づく品質指標を導出することを目的に、社内で2015年度より研究活動を開始しており、基盤構築プロジェクトの規模は「構築スケール(Cs:Construction Scale)」と定義した。
構築スケールに基づく品質指標は、以下4点を繰り返し実施することで導出した。

(1)基盤構築プロジェクトのメトリクス収集
(2)因子分析による基盤構築プロジェクトの規模に影響を与える因子の推定
(3)相関分析と重回帰分析による構築スケール算出式の導出
(4)構築スケールに基づく品質指標の有意性検証

本発表では、構築スケールに基づく品質指標の導出過程と有意性検証結果を報告する。
ダウンロード数: 164回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
RPA(Robotic Process Automation)はロボットによってホワイトカラーの事務作業を自動化・効率化する技術として近年多くの企業が採用している。そのような潮流の中、RPA開発の需要は年々増加傾向だか一方でRPA開発における課題も顕在化してきた。

例えば
①RPA開発は工数見積り手法が確立されておらず、過少見積となる場合がある
②非機能観点の設計ルールが確立されておらず、ロボット品質にバラツキが出やすい
の2点が挙げられる。

①RPA開発は機能数や複雑度合いによって開発工数は数人日~数人月と大きく変動するが要件定義段階で精緻な見積が実施されないまま開発に着手するとスケジュールの遅延や品質低下を招く。
②RPAはその自由度の高さからRPAツールを習得すれば直ぐに開発可能だが、複数の開発者にて同時に開発を進めるとエラーに対するリトライ方法が開発者毎にバラバラとなるなど運用が煩雑となり、結果リリース後の保守レベル低下を招く。

上記2点の課題を解決するため、弊社では
・ファンクションポイントを活用した規模試算と工数見積り
・RPA専用の非機能設計ガイド策定
を実施し見積精度と品質向上に取り組んできた。

本発表ではその概要と効果について述べたい。
ダウンロード数: 110回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
ビジネスの変化が急速に進む現代では、システム開発の工期短縮が強く求められている。
システム開発においてテストが要する工数は5割を超えるとも言われており、テストプロセスの改善は急務である。
多くの開発現場では、未だにスクリプトテストが主流であり、テストケース表などのドキュメント作成に必要な工数が重い負担となっている。
一方、探索的テストは、欠陥摘出効率の高いテスト技法として知られているが、スクリプトテストと異なり、テストケース表などのテストの詳細な内容を示したドキュメントを作成しないため、第三者に対してテストの十分性を説明することが難しい。

そこで我々は、探索的テストを応用した新たなテスト手法「SONAR Testing」を開発した。
SONAR Testingはテスト観点をベースとしたテストチャーターを用いることで、観点に対して網羅的なテストを計画できる。
また、テスターの行動を、画面遷移図やシーケンス図といったモデルに変換・可視化するツールを作ることで、レビューを通じて観点に対して十分なテストが実施されたかを確認できる。

本発表では、SONAR Testingの思想や運用方法、作成したツールの概要、および試行適用の結果を報告する。
ダウンロード数: 89回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
ソフトウェアの派生開発において、ソースコードの欠陥は「変更漏れ(追加漏れ/削除漏れも含む)」と「変更誤り」に分類できる。「変更誤り」については、変更仕様に対するテストを漏れなく誤りなく実施することで、欠陥の流出を防止することが可能である。

これに対して、我々の組織では、ソフトウェアメトリクスとレビューを活用し、テストの十分性の判断をしていたが、テスト漏れは検出しきれてはいないかった。

本研究では、「変更仕様に対するテストの漏れ」を検出するために、テストカバレッジの分析手法を考案した。短期間での開発が求められる派生開発において、現実的に実行可能な手法とするため、ソースコードの差分を抽出し、追加・変更箇所に対してテストカバレッジを算出する方針とした。
考案した手法を実開発に適用し、「変更仕様に対するテストの漏れ」及び「テストの漏れを誘発した“解釈誤りを起こす可能性の高い変更仕様”」を検出できた。考案した手法により、「変更誤り」に分類される欠陥の流出を防止する効果が期待出来る。
ダウンロード数: 79回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
近年のソフトウェアテストに求められる「自動化・AIなどの新技術との共存」「大規模・短納期なプロダクトの品質保証」に対し、従来のような「コマンド&コントロールでテスト実行をこなすオペレータ」による人海戦術では太刀打ちできない。
そのため、「コマンド&コントロールで膨大なテスト実行をこなすオペレータ」から「自律的に思考するクリエイティブなテストエンジニア」への転身を促進することが重要であると考えた。

テストエンジニアのスキルアップ・キャリア形成のための教育・トレーニングには様々な手法がある。これまでWACATE(ソフトウェアテストの1泊2日合宿形式勉強会コミュニティ)では、「ワークショップ」という手法を用いることで一定の効果を得てきた。そこで、若手テストエンジニアを主な対象とし、広く適用可能なエントリレベルの新たなワークショップの開発を行った。

ワークショップのテーマとしては、テストエンジニアのスキル領域の中でも「ソフトスキル」が該当することを特定し、特に「自律的な思考」に着目することとした。また、対比する形で「コマンド&コントロール」を置くことで、より「自律的な思考」にフォーカスする新たなコンテンツを開発することができた。

本発表では、『テストエンジニアのマインドを、表を埋める単純作業からクリエイティブなモデリングに変えていく』活動を推進する一手法の提案として、実施内容の紹介と検証結果について説明する。
ダウンロード数: 76回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
当社ではソフトウェアパッケージ製品の開発および販売を行っています。
製品開発プロジェクトは開発プロセスと品質保証プロセスを区別し、独自ではあるがウォーターフォール開発を行っていました。
近年開発プロセスをアジャイルに変えることにより、品質保証プロセスもアジャイルにシフトすることに課題を持っていました。

欧米ではアジャイル開発がスタンダードになりつつありますが、アジャイル開発における品質保証はまだ世の中に確立されていないように思えます。
アジャイル開発は動くソフトウェアを継続的に提供し顧客のニーズに素早く対応するプロセスですが、リリースしたプロダクトは品質が保証されたものか、また第3者に対してプロダクト品質を説明できるかの判断が難しいと言えます。

弊社の品質保証部門はプロダクトの出荷時に市場リリース可能な品質を持ったプロダクトであることを説明する義務があり、第3者が理解可能な品質説明が求められます。

本論文では開発プロセスがアジャイル開発であっても品質保証プロセスにおいてJIS X 25010:2013で定義されている品質特性を利用し品質保証プロセスの指標として活用することにより、最終的な成果物が第3者に対して説明可能なプロダクト品質であることの判断を可能とすることを目的としてます。
また、プロジェクト計画時に戦略的なテスト計画を策定し、アジャイル開発プロジェクトの進行と共に品質が確保され、段階を経て品質を積み上げる仕組みを提案します。
ダウンロード数: 75回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
ソフトウェア開発において、欠陥分析作業は必須のプロセスである。
この作業により、製品の品質もさることながら、プロセスの品質を推し測ることができる。
そのため、自社開発プロジェクトで欠陥分析作業は実施されているものの、その実、作業内容自体には標準というものがない。
分析作業を実施しなければならないことは開発プロセスに組み込まれているが、具体的な作業手順やその内容は標準化されていないのが現実である。
それらは、派生開発で継続的に受け継がれた内容であったり、報告者の独善的な内容であったり、レベルがまちまちな玉石混交な成果である。

上記の課題を解決するために、ODC属性(Orthogonal Defect Classification、直交欠陥分類)を軸とした欠陥分析パターンを案出、さらに欠陥分析作業を標準化することにより、分析レベルの一定化や作業の効率化を図ることを目的とした改善作業について報告する。
ダウンロード数: 75回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
ソフトウェア(以下、SW)をその製作目的に対して保証するためには、稼働後のシステム/ソフトウェアの利用や運用等の前提(以下、コンテキスト情報)を設計やそのレビュー時に考慮することが重要となる。SWの振る舞いがシステムの利用へクリティカルな影響を与える場合、コンテキストの考慮漏れは「想定外の状況や使い方」が発生し、最終的に致命的な事故につながってしまう。その「想定外」を減らすため、SW技術者は、与えられた仕様を満たすSWを製作するだけではなく、SW開発段階でもコンテキスト情報を踏まえた「リスクシナリオ」を識別し続けることが重要である。

一方、宇宙機システム開発では以下の特性のため、コンテキスト情報の抽出や伝達において難しさが存在する。

•利用目的(ミッション)の固有性が高く、システム毎にSWにとってコンテキスト差異が大きい。
•大規模且つ多組織による共同開発であるため、コンテキスト情報の伝達ミスが発生しやすい。
•シミュレーション解析及びモデリング中心であるため、SW技術者がコンテキスト情報を把握する難易度が高い。

本発表では、コンテキスト情報に着目した3つのビューを用いたリスクシナリオの作成方法、および3つのビューをより使いこなすノウハウを移転するためのレビュー技法を提案する。
ダウンロード数: 75回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
OEM向けにおける自動車用ECUの開発では一般的に約3年を要するが、アフターマーケット向けの場合、顧客要求により約1年での開発を要求され、従来の開発モデルでは顧客の要求納期に対応することができない。なぜならば、短納期がゆえに、仕様が固まっていないことがほとんどで、仕様を固めながら開発する必要があるため、開発の途中で仕様の変更や追加が起こるためである。このような開発では、ウォーターフォール型開発ではなくアジャイル型開発が向いていると考えられるが、当社において車載組込み開発においてのアジャイル開発は一般的ではないため、今回、従来のウォーターフォール型開発をベースにしながらアジャイル型開発とのハイブリッドで開発を実施した。

また、Automotive SPICEのアセッサー経験に基づき、優先順位の高いプロジェクト管理(MAN.3)に主眼を置いてプロジェクトを推進した。スケジュールやWBSのフォローも含めたプロジェクト進捗のレビューおよび報告を実施し、活動の達成度を明確化することで、最低限必要なエビデンス、ツール、開発環境が整っている状態を構築・維持しながら開発を推進できた。

本発表では、この活動の概要と進め方、工夫した点について、事例を交えながら紹介し、短納期で開発を行いながら、品質保証とリリース要求を両立した内容を報告する。
ダウンロード数: 73回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
従来のウォーターフォール開発モデルにおいて厳格な開発管理を通じて規律を守るスタイルから、自律して最適解を自ら考えるアジャイルスタイルに切り替えたとき、アジャイルの経験の浅い開発チームは何に注意を払えばよいのかを判断できず、試行錯誤が続いた。
その結果、アジャイル開発手法の1つであるスクラムを取り入れたどの開発チームも、プロダクトバックログが増え続け、納期がどんどんずれていく失敗を繰り返した。
これは、スクラムのバックログ管理を正しく理解していなかったこと、開発管理があいまいになったこと、品質部門が第三者視点で開発管理にどのように関わるべきかを決めきれずに進めていたことなどが原因であると分析した。

対策を考えるとき、スクラムにおける開発管理の節目となる「スプリントレビュー」と改善の機会となる「ふりかえり」に注目した。スプリントレビュー時に、従来の定量的管理の考え方を取り入れて、客観的な判断指標を設定し品質部門が定量的管理を主導するなどの開発プロセスを構築した。そして、スプリントレビューで抽出された課題をふりかえりで議論することを定着させた。

本発表では、以上の経験もとに、ウォーターフォール開発経験者がアジャイル開発を始めるときに陥りやすい点と、経験をもとに得られた知見を紹介する。
ダウンロード数: 73回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
DeNAの品質管理部では、ゲーム系と非ゲーム系の2つのグループに分かれており、各グループの中ではサービス事業種別で複数のチーム、更に各チームの中では具体的なサービス毎での複数のラインに分かれて品質保証を行っている。このように比較的大規模な組織であることから、定量的なテストマネージメントを行うことが課題となっている。

しかし現状、品質保証を行う各現場のテスト活動における定量的なデータを収集できていないため、テスト活動に活用できるメトリクスが整備されていなかった。

今回は、この問題を解決するために行った以下の3つの取り組みについて報告する。

【取り組み①】指標の枠組みの特定:必要なテスト活動メトリクスは何かを特定する
【取り組み②】データ収集方法の確立:現場から収集すべきデータの収集方法を整理する
【取り組み③】テスト活動メトリクス活用方法の確立:得られたテスト活動メトリクスの活用方法を整理する

また以上の取り組みに加え、実際にデータを収集したことで得られた結果とこの活用の見通しについて考察し、今後の取り組みについても報告する。
ダウンロード数: 72回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
機械学習では、従来のシステム開発のようにプログラムを直接的に記述する方法とは異なり、訓練データから帰納的に振る舞いが生成される。そのため、できることとできないことの境界を明確に把握することが容易ではない。また、機械学習は100%の精度を出すことができないため、誤った答えを出す可能性を踏まえた考慮が必要である。このような特性により、機械学習モデル単体での品質保証は難しく、機械学習システム全体としての観点から、機械学習モデルからの出力を運用時に監視や修正をするアーキテクチャ等についてはその必要性が言及されている。
ダウンロード数: 63回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
ソフトウェア製品の顧客満足度向上のためには、製品の使いにくさの問題を検出し改善することが求められる。弊社評価部門では、使い勝手評価としてSQiP2016で発表した「インタラクションデザイン評価手法」をこれまで84製品で実践し、定量的な裏付けである「操作時間」「手番数」を基に使い勝手の向上具合を可視化し評価してきた。
しかし「操作時間」「手番数」の定量データだけでは、使いにくさの問題検出は可能だが、改善点の絞り込みに時間がかかる。これらの手がかりを得るため被験者ヒアリングにて以下を確認してきた。しかし、被験者が無意識に見ていた、あるいは意識的に見ることができなかった部分は回答から改善点が得られないことがある。

・製品や画面の構成を理解できているか、操作の躓きのきっかけは何か
・何かを探すとき、図や説明は視野に入っていたのか

これらを踏まえ、被験者の記憶に頼らず、視線の動きの可視化により前述の手がかりを定量的に捉える手法を考案した。
本取り組みのねらいは、インタラクションデザイン評価へ新たに視線検知技術を導入し、定量的な評価結果を基に開発者が納得できる改善案を提示することで、よりUX面で国際競争力の優れた製品開発を促進することである。

本発表では、視線の動きから製品の使いにくさの問題を検出し、改善点を絞り込む方法と実践結果、および今後の研究の方向性を報告したい。
ダウンロード数: 62回
紹介文 :
レビューという品質向上活動そのものを改善することを目的として、
「レビューの振り返り手法」を提案しています。
「レビュー記録という客観的な事実を活用する」、「作成者とレビューアが個別に振り返る」、
「作成者とレビューアがお互いを振り返る」、「継続すべき項目にも着目する」など、
心理的安全性を高めて参加者全員から前向きな意見が抽出され、有意義で合意と納得の行く振り返りができるように工夫をしています。
ダウンロード数: 62回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
我々はモバイル端末向けゲーム開発におけるEnd to Endテスト(以下E2Eテスト)の自動化に取り組んでいます。これらE2Eテストは1回のテストに10分以上もかかる長編テストとなるため、テストケースの記述にはコストがかかりますし、テスト結果は外乱の影響を受けやすく不安定で失敗の原因分析が必要となります。

これらに対する取り組みとして、テストケースの記述についてはキーワード駆動型テストフレームワークを導入してシナリオと端末操作処理を分離しています。またテスト結果に対しては、当初は実行ログと端末画面のスクリーンショットで確認していましたが、テキストで出力されたログは非エンジニアにはわかりにくくスクリーンショットは欲しいタイミングの記録ができるとは限りません。そこで端末の実行画面を動画として保存しそこにログ情報を字幕として重ねることで両者の欠点を補うことにしました。
これにより、非エンジニアへ直感的な動画での説明ができるようになっただけでなく、テスト実行時の「端末の処理内容」と「テストスクリプトの処理内容」が見えるようになったことで、テストエンジニアは自動テストを改善するためのツールを手に入れることができました。

現在はまだ自動E2Eテストの改善に着手し始めた段階ですが、同様にテスト自動化に立ち向かう方々へ参考となるように我々の取り組みを紹介します。
ダウンロード数: 60回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
当社では64bit OSを搭載し、同OS上で動作するアプリをプリインストールしたパソコンを製造・販売している。筆者が所属する部門の任務は、出荷判定までに、すべてのOS不具合の原因を究明し、処置方針を決定することにある。

OS不具合の中には発生率が0.1%以下という低頻度で致命的な不具合も含まれる。このような不具合を再現させるには、同じ操作を1,000回以上繰り返すことが必要となる。当社ではこれまで自社製の連続試験ツール「Aginger」を用いた再現テストを行っていた。しかし、AgingerはGUI操作やキーボード入力の機能は備えていない。そのため、OS再起動後のサインインなど何らかのユーザ入力を行った場合に発生する現象の再現テストには使えず、人手で同じ操作を繰り返していた。その結果、多大なテスト工数がかかっていた。そこで、再現テストに市販のGUIテスト自動化ツールを活用することを考え、「eggPlant Functional」を導入した。

同ツールの導入効果を測るため、製品開発中に発生したある低頻度OS不具合について、人手でおこなう再現テストの工数と、eggPlant Functionalを用いて自動化した再現テストの工数を比較検証した。その結果、再現テストを約17分の1に効率化でき、大きな効果が得られた。本論文ではその成果を報告する。
ダウンロード数: 59回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
本グループは、AIシステム開発の現場で使える品質保証の観点を抽出することでAIシステムの品質保証活動を支援できる成果物を作成することを目標に活動してきました。品質保証の観点は、「AIシステムの品質保証をするために最低限やるべきこと」、および「AIモデルが最大限の精度を得るためにやるべきこと」の2面で考えました。実際に、簡単なAIモデルを作成して、精度などの改善を検証する過程で、具体的な品質観点を抽出しました。
発表では、本活動の成果物である「AIモデル開発を含むAIシステム開発プロセスの品質観点チェックシート」を中心にご紹介します。
ダウンロード数: 58回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
当社では、お客様に納品した情報システム(以下、システム)で当社が保守を行っている全てのシステムを対象とした、保守作業に対するプロセスの点検(以下、システム点検)を実施している。これは年一回の頻度で実施する、保守作業プロセスの問題点を洗い出して改善していくことを目的とした品質改善活動である。事故事例からの再発防止策を「気付きを与える観点」として点検用のチェックリストに追加しながらシステム点検を実施してきた。システム点検導入後は保守作業プロセスの問題に起因する社外事故が大幅に低減しており、品質の改善に貢献してきた。しかし、近年は事故の低減が下げ止まり状態となり撲滅に至らないことが課題であった。そこで、従来のシステム点検項目で発見できなかった事故のポテンシャルを抽出するために以下の改善施策を講じた。

・事故の未然防止に直結する気付きを保守員に与えるために、踏み込んだ観点を記載したチェックリストの作成
・チェックリストの強化による項目の増大が結果的にチェックリストの形骸化につながることがないよう、点検項目を厳選し減らした

項目数を厳選し、従来の2/3程度まで減少させたが、点検の精度は向上し事故のポテンシャルを抽出することができた。その取り組みと改善施策について紹介する。
ダウンロード数: 57回
SQuBOK分類 :
年度 : 2019年   分科会 : 2018年度 SQiP研究会 2分科会
紹介文 :
レビューの説明や指摘が作成者へ適切に「伝わる場合」と「伝わらない場合」がある。
また、「伝わる相手」と「伝わらない相手」がいる。説明や指摘の意図や期待が伝わらないと、レビューの効果は限定され、あらたな気づきや行動にもつながらない。

我々は、説明や指摘の意図や期待が伝わらない要因として、レビューアと作成者の「コミュニケーションスタイル」の違いに着目した。
つまり、お互いの価値観や考え方に沿わない伝え方をしているから、納得してもらえず、期待する行動にもつながらないのである。
レビューアが、作成者の「コミュニケーションスタイル」に合わせて、指摘の伝え方を変えることで、作成者は指摘を前向きに受け止めて、期待する行動を取ってくれるようになると考えた。

本発表では、「コミュニケーションスタイル」に着目したレビュー手法として、RCS(Review CommunicationStyle)法を提案する。
これは、コーチングで用いられている「コミュニケーションスタイル」の技法を、レビューに応用した手法で、作成者とレビューアの「伝達」方法と「行動」に変化を促す効果が期待できる。RCS法の特徴は以下の二つである。
簡易な方法でレビューコミュニケーションスタイルを診断
スタイルと状況別のレビュー戦略を提案
実験により、RCS法が作成者とレビューアの「伝達」方法の改善と「行動」の変化を促す可能性が高いことを確認した。
ダウンロード数: 56回
SQuBOK分類 :
年度 : 2019年   分科会 :
紹介文 :
当社は石油化学プラント等で使用される制御システムおよび制御に必要なセンサ機器群を主力に開発している。それらは伝統的にウォーターフォール(以下、WF)型で開発され、品証部門もWF型を前提とした開発プロセスやルールを規定し運用してきた。
一方で、様々な背景から当社開発部門でも一部製品や機能の開発にアジャイル型開発の導入が始まり、品証部門もアジャイル型開発に対し“何らかの”取り組みが必要となっている。
発表者は、アジャイル開発手法の一つであるSCRUMを採用したソフトウェア製品の開発プロジェクトチームに「品証担当者」という役割で参加し、その中で「アジャイル開発での品証活動」を模索している。その開発の最初のフェーズが一段落したことを受け、これまでの活動の中で得た経験と自分なりの仮説を、皆様と共有させていただきたい。

詳しくは講演の中で述べさせていただくが、ポイントは以下のとおりである。
1.如何にSCRUM手法を貫くか
(WF型開発しか知らない社内ステークホルダとの相互理解)
2.顧客要求を満足する「品質」をどのように定義するか
(何を作り、クライテリアをどう定義するか)
3.「理想的なSCRUMチームは、良い品質の製品が開発できる」
(理想と現実のギャップの認識と、それを埋めるためのアクション)
まだまだスタートしたばかりだが、今回の活動で得た新たな視点から、従来の品質保証活動への提言もしたいと考えている。
   

1

2

3
↑