キーワード検索


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

39 件の資料が見つかりました。
ダウンロード数: 1218回
SQuBOK分類 :
年度 : 2017年   分科会 :
紹介文 :
新規ソフトウェア開発プロジェクトにおいて、仕様や設計段階での漏れ/誤りの多発、あるいはコーディングやテストでバグが収束しない等の品質問題を起こすことは、比較的よくあるケースである。
今回の経験事例における対象プロジェクトについても同様の品質問題を抱えたプロジェクトであり、フェーズ1開発完了時点で品質問題が顕在化した状態であり、フェーズ2開発以降において開発品質をどうやって改善/向上させるかが重要課題となっていた。
当プロジェクトの品質改善の為に自身がPMOおよび品質管理の役割で参画し、品質悪化要因について分析した結果、当プロジェクトはオフショアを含む多拠点で編成されたプロジェクト、且つ新規メンバ中心で構成された体制であり、開発プロセスやコミュニケーションの観点などにおいて改善すべき点が多々あることが判明した。特に
 ・開発プロセス理解/周知不足で成果物の品質が一定でない
 ・仕様/設計における拠点間の認識齟齬の多発
 ・仕様/設計/コーディングでのレビュー不足多発
 ・テスト項目網羅不足
などの弱点が顕著であった事から、これらの観点に着目した改善施策を立案/実行した。
その結果、当プロジェクトのフェーズ2開発以降において、大幅な品質改善が見られたことから、当経験を事例として発表する。
ダウンロード数: 788回
紹介文 :
認知心理学・社会心理学の理論「認知バイアス」をご存知だろうか?
「曖昧性効果」「専門偏向」「共有情報バイアス」「ゼロリスクバイアス」「アンカリング」など、193個の定義があるが、その中から、ソフトウェア開発の現場で作成者が掛かる可能性が高く、かつ、その影響度が高い13個に絞り込み、レビュー時の欠陥検出に活用する方法が提案されている。
レビュー対象成果物への記載漏れや考慮不足といった検出難易度が高い欠陥をどうやって検出すれば良いのか悩んでいる方は、一読されることをお勧めする。
ダウンロード数: 312回
SQuBOK分類 :
年度 : 2017年   分科会 :
紹介文 :
STAMP/STPA (Systems Theoretic Accident Model and Processes / System-Theoretic Process Analysis)は、数多くのシステムがつながることにより発生する事故の解析に有用とされており、安全性解析の新しい手法として注目されている。
従来の安全性解析手法(FTA、FMEA)では、事故を引き起こす原因はシステムの故障であるとしている。それに対してSTAMP/STPAでは、システムがシステムの状態を誤認識することにより、 “安全ではないアクション”を実行することが事故の原因であり、それを特定するためにプロセスモデル(システムが認識するシステムの状態)の抽出が必要であるとしている。しかし、プロセスモデルの具体的な抽出方法については提示されておらず、分析者がアドホックに抽出するしかないという課題がある。
この課題に対し、MITのJohn Thomas氏はExtending STPAというコンテキスト(システムの状態)を分解してプロセスモデルを具体化していく手法を発表している。本提案は、この手法の前に、6W3Hを適用してコンテキストを幅広く捉え、プロセスモデルの漏れを予防しようとするものである。
ダウンロード数: 212回
SQuBOK分類 :
年度 : 2017年   分科会 :
紹介文 :
Agile開発におけるチームマネージメント方法についてScrumが知られているが、導入に際して効果的に定着出来ていないプロジェクトが散見される。特に導入段階で躓くプロジェクトの多くに幾つかの共通点がある。形骸化されたロール定義による誤った責任分担。Scrumの原則を順守しないイテレーション開発の実施。その結果、プロダクトの品質が確保できず、Agilityが上がらないチーム開発になり、期待した結果を得られない事が多い。
原因は、Scrum自体が抽象度の高い開発プロセスである事がその一つだと考えている。実案件においては開発プロセスを補完するために従来型の開発方法の知見を利用する事になる。Agile開発の本質は、可能な限り早く顧客に価値を提供する事を優先する事だが、しかしながら適応した知見がAgile開発との相性が悪いと、効果が出るまでの障害となる事がある。この問題については、Agileに適した知見を共有する事で問題解決するのではないかと考えた。
本発表では、これからScrumを導入するプロジェクトに適した幾つかのプラクティスを示す。プラクティスを導入した実案件のプロダクトの品質の分析結果およびプロジェクトの課題を共有する。
ダウンロード数: 112回
SQuBOK分類 :
年度 : 2017年   分科会 :
紹介文 :
ソフトウェア開発において、開発作業の進捗は評価できるが、プロダクト品質(コードにバグがどれだけ存在するか)はテストが完了するまで分かり難い。そのため、ソフトウェアのバグが計画より多く存在し、バグ修正に掛かる時間と労力が計画より増えること、今後について再計画が必要であるということに気付くには、多くの時間が必要である。特に大規模で短期間のソフトウェア開発は、バグが多いリスク、納期が遅延するリスク、コストが増えるリスクが高いため、早期に品質の悪い部分を検出し改善させるサイクル(よいプロセスに改善する)が重要である。
よいプロセスの習慣化には各工程で活用するセルフチェック(標準的なチェック観点)やレビューを愚直に実施させることが有効である。実施状況を数値化することで作業品質を評価できる。この作業品質の尺度を用いることで、"異常値"(=作業品質が悪いモジュール)は開発要員の理解不足、手抜き(嘘)を客観的に検出できスキル向上の指導を施すことができる。
私たちは本施策をQM3S”Quality Mind and Skill Scoring System”と呼び、開発作業における作業品質を定量的に評価する手法がソフトウェアの品質確保に有効であることを確かめた。本発表ではQM3Sの特徴説明を行うとともに適用効果の報告を実施する。
ダウンロード数: 101回
SQuBOK分類 :
年度 : 2017年   分科会 :
紹介文 :
業務システムの受託開発において、要件定義工程の成果物として業務フロー図が作成される。業務フロー図には、業務全体の流れに沿ってシステム化する範囲と作業概要が記述される。その記述内容に基づき、発注者と開発者とで合意形成が行われ、設計工程やテスト工程の成果物が作成される。
業務フロー図をテスト工程の入力成果物として利用するとき、実務中に実行される業務シナリオがすべて記述されておらず、十分なテストを設計できないことが多い。典型的な業務フロー図では、基本シナリオ(業務目的を達成できる代表的なシナリオ)は記述されるが、代替シナリオ(業務目的を達成できる基本シナリオ以外のシナリオ)/例外シナリオ(業務目的を達成できないシナリオ)の記述が一部に留まっている。
業務フロー図に記述されない代替/例外シナリオを表現するため、状態遷移図/表を利用する方法がある。状態遷移図/表は、複数の業務に紐づく代替/例外シナリオを簡潔に表現できる。
しかし、業務システムの受託開発においては、設計工程でもテスト工程でも状態遷移図/表が作成されず、十分なテストを設計できたか検証するのが困難になるという課題がある。
本論文では、業務フロー図および各業務を詳細化した設計書から状態遷移を抽出し、業務フロー図に記載されていない代替/例外シナリオを補完してテストするためのテスト設計手法およびその適用事例について報告する。
ダウンロード数: 92回
紹介文 :
要件定義段階で顧客・ユーザとの認識の齟齬を減らすには、UX手法が効果的ですが、
開発現場で導入するにはまだまだ敷居が高い状況です。しかし、従来のやり方や設計書の
書式を大きく変えなくても、要件定義時に5W1Hを考慮するというちょっとした工夫を
加えるだけで、要件の齟齬や漏れを減らす効果があります。
またスマートスピーカーを題材にした検証結果も掲載されており、実践の参考になります。
ダウンロード数: 88回
紹介文 :
過去のレビュー指摘を分類・活用しようとすると、これまでは必ずと言っていいほど、管理者視点で行われてきた。
本論文では管理者視点と共存する形で、作成者視点の分類・活用方法が提案されている。
実験で付与されたタグは大きく6つに分類され、「機能系」「対応方法系」「品質特性系」だけでなく、「注意喚起系」「表現方法系」「影響度系」といった作成者ならでは視点があり、具体的なキーワードでタグが付与されている。
作成者にとってレビュー指摘を検索・活用しやすくなると共に、作成者自身が自由にタグを付与できるため、品質向上活動への能動的な関与の促進が期待できる。
レビュー指摘を組織的に蓄積・横展開し、作成時の品質向上に活用したいと考えている組織の方は、一読されることをお勧めする。
ダウンロード数: 81回
SQuBOK分類 :
年度 : 2017年   分科会 :
紹介文 :
ウォーターフォール開発プロセスは、上流工程における成果物の完成度をできる限り高めることにより、当該工程以降に検出されたバグの修正による後戻り作業を低減するモデルといえる。そこで、品質管理部門では、上流工程の成果物の完成度の程度を測るための各種メトリクスを定義・運用して、品質上のリスクを見極める判断をしている。
筆者の組織では、プロセスメトリクスの一つであるレビュー工数の基準値を定め、レビュープロセスを確実に実行するように、組織的なプロセス標準を規程し品質管理を運用してきた。その結果、レビュー工数の増加と供に、出荷後のバグ数は減少し、一定の成果が得られたと考えられる。しかし、レビュー工数がある程度確保され、レビュープロセスが安定して実行されるようにプロセスが成熟した組織に対して、レビュー工数を軸にした品質管理だけでは品質リスクの見極めが難しくなってきた。
そこで、レビュー記録に着目し、レビュー記録のテキスト情報から得られるメトリクスについて設計品質に影響を与える要因を分析した。レビュー記録のテキスト情報から抽出したメトリクスには、バグの指摘率、レビュー指摘文の長さ、および、レビュー指摘文の述語の種類別の頻出度などである。
本発表では、これらの分析結果をもとにして、レビューにおける多角的な品質管理方法について提案する。
ダウンロード数: 81回
SQuBOK分類 :
年度 : 2017年   分科会 :
紹介文 :
ソフトウェア開発において、品質と生産性の向上は永遠の課題である。
弊社では、ソフトウェア開発を行っている組織から毎年プロジェクトデータを収集・蓄積し、組織横断的なデータ分析を行い、品質や生産性への影響要因を分析することにより、全社的な品質・生産性の改善活動に結びつけてきている。
今般、2015年度に終了した527件のプロジェクトデータを使用し、出荷後の品質状況、設計・製造工程のレビューにかけた工数、設計・製造工程の工数、テスト工程の工数、各工程の摘出バグ数等から、品質および生産性の関係を分析したところ、設計・製造工程でレビューに時間をかけて、より多くのバグを摘出するほど、出荷後の品質がよく、生産性もよいことがわかった。
本発表では、これらの分析結果を説明し、品質と生産性はトレードオフの関係ではなく、品質・生産性向上を両立させて改善できることを報告する。
ダウンロード数: 77回
SQuBOK分類 :
年度 : 2017年   分科会 :
紹介文 :
Internet of Things(IoT)や人工知能(AI)など、社会にイノベーションを起こす技術の急速な進展に伴い、これらを具現化するソフトウェアの重要性がますます高まっている。特にその品質は、社会基盤やビジネスに大きな影響を与えており、ソフトウェア製品・サービスそのものに対する要求はもちろん、利用時の視点での要求、そして、市場競争力強化への要求など、多面的に捉えられてきている。本稿では、「多面化するソフトウェア品質要求をどのように実現できるか」をテーマに、『ソフトウェア品質要求』を『品質特性』に読み替えることに着眼し、品質確保するアプローチを考案・検証した。本品質確保のアプローチは、『品質特性』を実現するために採用する『品質技術』の選択手法、そして、『品質特性』の達成度を評価できる『メトリクス』の活用手法から構成した。品質特性とその達成度を評価するメトリクスは、国際規格ISO/IEC 25000シリーズ(SQuaRE)をベースに、品質技術は、網羅・体系化が必要となるため、「ソフトウェア品質知識体系ガイド(SQuBOKガイド)」をベースとして研究を行った。最後に「IPA 2015年度ソフトウェア工学分野の先導的研究支援事業(RISE)」(早稲田大学)が調査結果として報告した「異なる品質間の関係を総合的に実証した世界初のベンチマーク(WSQB2017)」との検証も行い、ひとつの実践結果を示すとともに、今後広く展開するための深掘りの観点と考察を発表する。
ダウンロード数: 74回
紹介文 :
新しい安全解析手法「STAMP/STPA」にセキュリティ適用をし、
「アシュアランスケース」で分析の妥当性確認をした初めての研究事例です。
脅威にはSTRIDE分析、影響評価基準にはASILを用いました。
保証の全体像を定めた上で、セーフティとセキュリティ双方のリスク抽出、評価、対策まで作り込みました。
「自動運転」での事例はお役立ち間違いなしです!
ダウンロード数: 73回
紹介文 :
プロジェクトの振り返り”活動結果を、他のプロジェクトでも活用し、反映させ展開することは、実際には難しいという問題がある。
 本テーマは、この問題に焦点を当て、展開すべき振り返り結果の改善策(TRY)の納得感を高めるため、振り返り分析プロセスについて、観点シートで網羅的な成功点/問題点(KEEP/PROBLEM)を抽出し、QCD観点から他への展開の重要度が高い問題点を選定して、それを分析シートで真因分析するよう、手を加えることから始め、担当者だけでなく管理者や改善支援担当も含めた展開のための振り返りも行って、改善策の反映プロセスでの情報伝達・実践状況の実行支援の仕組みまでを一貫させて結合しようとする、組織改善に欠かせないプロセス基盤構築の研究である。
ダウンロード数: 66回
SQuBOK分類 :
年度 : 2017年   分科会 :
紹介文 :
一般的な開発プロジェクトではテスト工程終了時の工程移行判定にて品質判断しているため、品質問題が起きた場合はスケジュール遅延のリスクが発生しやすい。当社では本リスク対策を行っている。
当社の品質保証部門では最終成果物であるソフトウェアの品質要求を品質特性で定義しており、品質特性を品質指標として活用している。テストレベル毎に品質副特性ベースで定義された品質要求を達成することを念頭にテストレベル毎にクオリティゲートとなるクライテリアを定義している。
この品質保証プロセスを活用し、品質問題が起因したスケジュール遅延リスクの対策として、テストレベル毎にクオリティゲートとなる当社独自の「受入テスト」という仕組みを構築し、予定しているテストが手戻りなくスケジュール通りにテスト可能な品質が備わっていることをシミュレーションしている。
当社独自の受入テストは、網羅性のある品質特性で定義された品質要求が確保されていることを念頭に対応するテストタイプからテストケースを抽出しているため、テストレベル毎の受入テストをパスすることにより、品質確保の状況が分かりやすくなる。
本論文では、テストレベル開始前条件に品質判断する手法として当社独自の受入テスト技法を紹介し、本技法の効果であるプロダクトリスクの回避や品質の見える化実現に向けたプロセスの解説とともに説明する。
ダウンロード数: 62回
紹介文 :
基本設計書を初めとする上流工程のドキュメントでは、しばしばテストなどの後工程で必要な情報が抜けたり、曖昧な記述により情報が伝わらなかったりします。本論文では、テストケースの自動生成を見据えることで後工程に必要な情報を漏れにくくする設計書の作成アプローチを提案しています。
ダウンロード数: 56回
SQuBOK分類 :
年度 : 2017年   分科会 :
紹介文 :
近年のソフトウェア開発では流用開発やOSSの活用等、開発者は他者が開発した機能を開発対象に組み込むことが一般化してきている。この開発方法は開発工数の大幅な削減が期待できる。その一方で、他者が開発した機能を取り込むことで、開発対象のソースコードがブラックボックス化・複雑化し、ソースコードの品質劣化による障害の誘発や、障害調査・修正に多くの時間を要する等の問題が発生している。開発者に開発対象のソースコードの品質情報を提供すれば、問題の早期発見や修正時間の短縮化につながると考え、ソースコードの品質状況をメトリクスにより自動測定し、定量的に把握する仕組みの確立、および開発現場への展開を行ってきた。しかし、開発現場からは「メトリクスを見ても対応方法が判らない」等の声があがっており、定量的なメトリクス情報に基づいてソースコードの品質を改善するプロセスが現場に根付かない問題があった。
そこで本稿ではソースコードの品質劣化を表すメトリクスと、その後のソースコードの修正回数や修正日数(品質リスクと呼ぶ)との関係を分析し、これらの間に関連があることを示す。これにより開発者にメトリクスを活用したソースコード品質改善の早期対応への動機づけを行う。あわせて品質リスクへの具体的な対応案を開発現場に提示し、品質劣化を防止することで、追加コストの発生および納期遅延を未然防止することを狙いとする。
ダウンロード数: 50回
SQuBOK分類 :
年度 : 2017年   分科会 :
紹介文 :
 派生開発では、変更の影響箇所に潜在する欠陥を、回帰テストで見逃さず検出することが必要である。限られた時間で、影響範囲に対するテスト漏れを防止するためには「確実な影響範囲の特定」に加えて「テストの網羅性の確認」と「影響範囲を小さくする設計」が重要である。本発表では「制御の流れとデータ更新・参照の流れから影響箇所を特定可能」という考えから、影響波及パスという概念を定義し、それを利用した手法「影響波及パス分析法」を提案する。本手法を実開発に適用した結果、影響範囲に対するテスト漏れによる欠陥流出の防止に繋がる効果が確認できた。
ダウンロード数: 50回
紹介文 :
製品知識や開発情報・技術のノウハウは特定の担当者によって異なるが、偏りが進み過ぎると、伝達すべき情報や技術が継承されず,製品を改造・流用する際に製品仕様や設計、実装時の検討漏れや誤りなどの原因となって問題を引き起こす場合が多い。
 本テーマは、この“いわゆる属人化状態”の分析に焦点を当て、プロジェクトチーム内の担当者同士による技術面での個人依存度の主観的な相互評価の値と、レビュー実施時の各担当者別の発言時間という客観的な測定値とを組み合わせ、担当者を「職人領域」,「属人領域」,「教育領域」,「点検領域」,「適正領域」の五つに分類し、チーム内の担当者の相対的な属人化の進行の不均衡さ(チームバランス)を可視化することによって、
管理者が各領域のバランス状態を確認し、必要な育成リソースに対する過不足を把握して、
問題発生前の事前対応計画作成に役立てられるよう、属人化状態の測定・可視化を通して改善する仕組みを構築しようとする研究である。
ダウンロード数: 47回
SQuBOK分類 :
年度 : 2017年   分科会 :
紹介文 :
探索的テストは、バグの摘出効率が優れており、品質向上や生産性向上を目指す多くの組織に注目・活用されている。
しかし、システムの受託開発を行う業者における、探索的テストの採用事例は少ない。
探索的テストは、事前にテストケースを作成しないため、テストの総量や実施範囲が不透明であり、テスト管理が難しいことが原因の1つと考えられる。
そこで、受託開発におけるテスト管理に求められる要件を明確にすべく、JSTQB Foundation Levelシラバス「5. テストのマネジメント」に記載の6つのカテゴリに着目し、これらのカテゴリごとに、探索的テスト導入時の問題点を整理し、改善目標を定義した。
本発表では、テストをセッションと呼ばれる時間の枠で管理する「Session-based Test Management」を活用することで、定義した改善目標を満たしながら、探索的テストを実施する方法を検討し、実際の開発現場で適用した結果を紹介する。
ダウンロード数: 44回
SQuBOK分類 :
年度 : 2017年   分科会 :
紹介文 :
通常、ソフトウェアテストにおいては、テスト要因を分析し、その要因を組み合わせてテスト項目を作成し実行する。作業効率化のため、実行と結果確認を自動化しても、テスト項目作成は人手であり、実施可能な組み合わせ数に限界があった。そこで我々は、要因をランダムに組み合わせ大量のテスト項目を自動生成し、生成されたテストの実行および回答との結果比較まで自動化する手法により組み合わせのバリエーションを拡張したテストを実施し、多くの障害を検出した。
しかし、活用の実績から2つの問題があることが明らかになっている。1つは、テスト項目を、ランダムに要因を組み合わせ生成した順に実行するため、品質リスクに応じた順番でテストできず、早期の品質確保ができないことである。もう1つは、結果比較でNGとなるテスト項目を大量に検出した場合、それらが同一原因によるものかの確認は人手であり、工数がかかることである。
本報告では、これらの問題を解決するため、障害に関係する重要な要因を含むテスト項目を優先的に実施する手法と、検出した障害を、そのテスト項目の要因に着目して同一原因かどうか自動で分類し、原因の究明を効率化する手法を提案し、実際のテスト作業においてこの手法を適用した効果について報告する。
  

1

2
↑