キーワード検索


 2001年    2002年    2003年
 2004年    2005年    2006年
 2007年    2008年    2009年
 2010年    2011年    2012年
 2013年    2014年    2015年
 2016年    2017年    2018年
 2019年    2020年  
35 件の資料が見つかりました。
ダウンロード数: 3142回
SQuBOK分類 :
年度 : 2020年   分科会 :
紹介文 :
近年、システムの構成要素としてOSSの活用が増えている。OSSはソースコードが公開されているが、OSSのソースコードを解読しているとシステム構築に時間がかかるため、OSSの導入メリットがなくなってしまう。そのため、OSSはブラックボックスの状態で活用する場合が多い。
従来、システムの全体的な品質確保の目的で品質特性の利用や、重大障害防止のためにFTA(Fault Tree Analysis)やFMEA(Failure Mode and Effect Analysis)などのリスク分析手法を用いたテスト観点の導出を行っていた。
しかし、FTAやFMEAを適用するには、内部処理を詳細に知っておかないと効果的なテスト観点を導出することが難しく、OSS活用が増えてきた近年ではこれらのリスク分析手法の適用が難しくなってきている。
本発表では、機能間インタフェースに着目して安全性(ハザード)を解析する手法であるSTAMP/STPA(Systems-Theoretic Accident Model and Process/STAMP based Process Analysis)を、テスト観点導出に適用した事例について紹介する。
具体的には、OSSを活用したオンプレミスのシステムにおける、STAMP/STPAを適用した品質保証部のテスト観点の導出、およびそのテスト観点を用いたテスト結果について紹介する。
ダウンロード数: 294回
SQuBOK分類 :
年度 : 2020年   分科会 :
紹介文 :
当社では、本番障害の多くが上流工程の問題に起因しており、40%弱が外部設計工程での埋め込みとなっている。

主な埋め込み要因
・開発メンバー間で同じことをイメージできる状態まで設計内容を記載していない。
・検証可能性の観点からテストケースを導出できない。
・システム間で認識齟齬が発生し、誤った思い込みのまま開発を進めている。

そこで上流工程の問題に対する打ち手が、効率的・効果的な品質向上につながると考え、上流工程からの品質の作りこみを実現するために今年から工程完了判定を導入した。

当社では年間300弱の開発案件が立ち上がるが、レビューアとして参画できる品質マネジャーは2名というリソースの制約があった。
そのため、開発案件に対して、どのようにメリハリをつけて過不足のない品質保証活動を行うのかが最も重要なポイントとなり、そこで開発案件毎にリスクレベルを設定し、レベルに応じてレビュー度合いをテーラリングする仕組みを検討した。
また過去3年間の本番障害の内容を分析することで、外部設計書における欠陥の埋め込みを予防する観点を抽出し、過去の障害の再発予防を徹底した。
さらに今後はWモデルを適用することにより、外部設計書の欠陥を早期に検出できるよう品質の作りこみを強化していく。

同様の課題を抱えている参加者に対して、工程完了判定の導入で工夫した具体的内容とその導入効果を紹介する。
ダウンロード数: 227回
SQuBOK分類 :
年度 : 2020年   分科会 :
紹介文 :
ソフトウェア開発を成功に導くために、技術者の能力の均質化や底上げ、開発プロジェクト内での共通認識の醸成を目的として、開発標準などのドキュメントを作成している企業は非常に多い。しかし、ソフトウェア開発プロジェクトは複雑であるため、開発標準に記すべきノウハウは多岐にわたる。そのため開発標準が重厚長大なドキュメント群となってしまうことが多い。多くの技術者は多忙な開発の中で重厚長大な開発標準を読むこととなり、大変な苦労を感じている。結果として開発標準は技術者から「役に立たない」・「読みたくない」といった評価を受けることがある。また、ソフトウェア開発に関する技術やテクニックは、常に進化しており、開発標準も進化に追従していかなければない。しかし、重厚長大なドキュメントを修正するには、執筆やレビューの工数が負担となり、迅速な改善が難しい。その結果、開発標準に記されているノウハウが、時代遅れとなってしまうことも珍しくなく、技術者からの評価がより悪化してしまう。開発標準が、ユーザである技術者から見て魅力のないドキュメントとなってしまうと、目的であった技術者の能力向上や、共通認識の醸成がうまく進まず、ソフトウェア開発プロジェクトが失敗に終わってしまうことがある。そこで我々は、オープンソースソフトウェアの開発技術・文化を、組織などの閉じたコミュニティで実践するインナーソース開発のノウハウを、開発標準の作成に適用し、このような問題を解決した。本発表では、これらの経験に基づくノウハウや、考え方を紹介する。
ダウンロード数: 156回
SQuBOK分類 :
年度 : 2020年   分科会 :
紹介文 :
従来型のウォーターフォール開発では、工程ごとに次工程に移行するための品質チェック
の基準が設けられ、後戻りのないように上流工程から品質を 作り込んでいく。一方、アジ
ャイル開発などのイテレーティブな開発手法 では、ウォーターフォール開発において工程
ごとに実施されていた品質チェック が暗黙的となりやすく、欠陥の発見が遅れることがある。我々は、従来型 の工程ごとの品質チェックとは異なる観点で、アジャイル開発に適した構造化 された品質チェック項目を作成する方法を検討してきた。本発表では、その方法を実際のアジャイル開発プロジェクトに適用し、効果を確かめた結果を 報告する。アジャイル開発のプラクティスのインプット・アウトプット・ステークホルダー を整理し、マトリクス形式で品質チェック項目が構造化できることを確かめた。 その上で、品質チェック項目の効果を検証するため、過去に検出された欠陥の うち、品質チェック項目により早期検出可能な欠陥がどの程度あるか分析した。 分析の結果、実際に検出された時点よりも早期に検出できた可能性がある 欠陥があることが示され、当初の狙いを達成できていることが分かった。 さらに、早期に検出できた可能性のある 欠陥の多くが従来の要件定義のレビュー やテストケースのレビューに該当するチェック項目で検出できた可能性があることが分かり、対象としたアジャイル開発プロジェクトの改善点を見出すことができた。
ダウンロード数: 123回
紹介文 :
ソフトウェア開発時に、以前の類似システムのときと同じ原因の不具合を混入させないようにする、再発防止は十分に実施できているでしょうか? 開発現場で再発防止策を定着させることは実際にはなかなか容易ではなく、以前の類似システムと同じような問題が繰り返し発生してしまうケースが少なからずあります。
この論文では、再発防止策の定着に有効な要素が何であるかを特定するため、ソフトウェア開発者が再発防止策を実施するときのモチベーションやヒューマンファクターに着目して調査・分析しています。また、分析結果から、再発防止策の定着に結び付ける展開・伝達手法として、どのようなアプローチを用いるとより有効となるのか(「あつ森法」)を提案しています。
ダウンロード数: 106回
SQuBOK分類 :
年度 : 2020年   分科会 :
紹介文 :
弊社において、大規模なサービスを過去10年以上にわたりウォーターフォールでプロダクト開発を進めていた中で、生産性の向上を目的として開発体制の一部でアジャイル開発を採用し、リーンアプローチを続けていた。しかし、その中でも小さいウォーターフォールのような体系は残ることが多く、各メンバー同士の役割も大きく変化することはなかった。結果、プロダクト開発に対する意識や理解のズレが発生し、QAメンバーのモチベーションや開発効率の低下に影響していた。そこで、QAが固定化された役割の中で動くのではなく、コミュニケーションをとりつつ全体の進捗に応じて緩やかな連携を行うことで、「生産性の向上」を図った。
 今回、新たなチーム作りにおいては、QAメンバーの役割の再定義(越境)と開発プロセスにおけるQAメンバーの立ち位置を変化させることに焦点を当てた。QAメンバーの役割を考え抜く中でプロジェクトにおける業務内容も変化し、モチベーションの向上やチーム全体の開発効率の最大化に繋げることに成功した。
 弊社のように長い間ウォーターフォールで取り組んできた大規模な開発現場では、アジャイルなどに取り組む際に、QAの役割は以前のやり方を踏襲することも多い。本発表では、その中でどのようにQAの役割を再定義したのか、新たな取り組みに対してデメリットやリスクを会話する中で最適な解を出せるように取り組んだ事例をご紹介します。
ダウンロード数: 93回
SQuBOK分類 :
年度 : 2020年   分科会 :
紹介文 :
 UI/UXが訴求ポイントの一つとなってから久しいが、業務システム開発の分野では、未だに単調で大量の画面と、大量のマニュアルを作り続けていることが多い。これは「業務システムの価値観」において「主要」はバックエンド処理であり、UI/UXは「コストオン」として、重要と認識しつつも優先度を下げて取り扱われてきたからである。「変化に柔軟に対応して価値向上を目指し続ける価値観」への転換が求められている昨今、「業務システムでもUI/UXの向上を」との意識は強まっているものの、十分な対応ができる技術者が少ないとの問題も出てきた。
 そこで、とある金融系業務システムにおいて「デザインシステム」を構築・運用することを始めた。「デザインシステム」とは、プロダクトやサービスのデザインに関する様々な情報を「言語化」「可視化」し、関係者間で共有できるようにしたものである。これまでも似たようなものに「UI標準」があったが、それと違うのは、プロダクトやサービスと乖離せずに一緒に成長していく仕組みまで含まれている点である。これによって、部品やレイアウトなどの一貫性・統一感といった「デザインメリット」が得られただけでなく、部品の再利用・柔軟性による「開発効率化メリット」、部品名で会話して素早く認識を合わせることができる「コミュニケーションメリット」が得られた。
 本発表では、構築した「デザインシステム」の概要とそこから得られた効果を紹介する。
ダウンロード数: 66回
紹介文 :
リモートワーク環境下での開発における品質/生産性向上を目的として、「リモート開発におけるレビュー改善方法」を提案しています。
「リモート開発におけるレビュー改善の手順」がわかりやすく、具体的に示されており、「レビュー成功要因関連図」や「レビュー改善Tips」も具体的で実践的な内容が紹介されています。
ダウンロード数: 66回
SQuBOK分類 :
年度 : 2020年   分科会 :
紹介文 :
ソフトウェア開発の定量的な品質管理では、プログラムコード行数あたりのバグ摘出数・テスト数といった指標を使うことが多い。昨今は業務パッケージソフトウェアの利用などでプログラムコードを直接書かないプロジェクトが増え、プログラムコード行数を用いた指標を利用することが難しくなってきている。また上限・下限値といった水準値を定めて指標値を評価するが、
統計的に意味のある類似したプロジェクトの情報の入手が前提となっている。昨今は技術の多様化が進んでいるため類似したプロジェクトを見つけるのが厳しくなっており、この点からもプログラムコード行数を用いた指標を利用することが難しい。そこで本論文ではテストプロセスを対象とした、プログラムコード行数を用いない品質分析技術を提案する。
また現代のビジネスにとってソフトウェアの重要性は増しており、 その開発を高速に行うことが市場に求められている 。迅速に提供できたとしても ソフトウェアの品質が悪ければ提供価値が下がるため品質管理の重要性は変わらない 。品質を保ちつつ品質管理にかかる作業は高速であることも求められている。プロジェクトでは次のフェーズに進んで良いか判断するために、各フェーズの終了時に品質を 確認するクオリティゲートを設定することがよくあるそのための品質報告 情報のとりまとめや、次のフェーズに進んで良いか判定している期間がソフトウェア開発を停滞させてしまうことがある 。この点に品質管理を高速にするための改善余地があると考え、解決するための手法を提案する。
定量的な品質管理は開発中に日々行うことが理想ではあるが、実現できているプロジェクトは多くはない。そこで日々の品質管理のために何を確認しているのかヒアリングを行った。 その結果、テスト観点に対してテストを網羅的に実施できているかと、すり抜けバグの 発生状況の確認を行っていることが多かった。この 2 つを定量的に確認できるような品質分析技術として整理し、無理なく品質管理を日々行うことで開発速度を落とさない品質管理 手法を策定した。
本論文では2 章で解決したい課題を明確にし、3章で改善策の提案を行い、4章で提案手法の適用結果を紹介し、 5 章で今後の展開を述べる
ダウンロード数: 63回
SQuBOK分類 :
年度 : 2020年   分科会 :
紹介文 :
 レガシーシステムで培ってきた品質を確保するための開発ノウハウは、デジタル化の潮流など新しい技術が注目される現在も重要と考え、品質管理部門は、障害報告書を活用した開発ノウハウ可視化に取り組んでいる。この取組みは「経験不足を補う良い活動」といった声がある一方で、開発ノウハウ可視化作業は経験のあるベテラン社員が相応の工数を要して作成することから、開発ノウハウ数がなかなか伸びないという問題がある。また、開発ノウハウへのアクセスが少なく活用度が低いという問題もある(テキストで公開しているため検索できないという背景もあり)。
 これら問題に対して、AI(機械学習)を利用した文書検索エンジンで解決できないか、試作品を開発し効果検証した。問題解決のアプローチは、可視化数がなかなか伸びない問題に対しては、開発ノウハウで紹介している障害事例と、同水準の件数とバリエーションの障害報告書を文書検索エンジンで検索できれば、障害の注意喚起機能を代替できると考えた。ノウハウへのアクセスが少ない問題に対しては、ネット検索のような利便性の高い検索エンジンを作ることができれば開発ノウハウへのアクセス数が伸びると考えた。本プログラムでは、効果検証の結果、文書検索エンジンの開発で苦労/工夫したことを紹介する。
ダウンロード数: 61回
紹介文 :
ソフトウェアの設計レビューで指摘できた不具合の発生原因を集め、うまく傾向を分類・分析し、原因の傾向に合わせて適切な対策を実施できているでしょうか? 実際には傾向分析の入力である、分類した原因区分に誤りが割と多く、傾向分析の結果が不正確で、適切な対策になっていないことが起こりがちです。このため、下流工程のテストでも設計時と類似した原因による不具合が残っていることも少なくありません。
そこで、この論文では、品質管理責任者が原因区分の誤りの程度を判断して傾向分析の“確からしさ”を判断でき、そしてレビュー指摘を受けたレビューイも原因区分の誤りを是正できるような、設計レビューでの不具合の原因区分を明確にする仕組みを研究し、「ARCメソッド(Ascertain the Roots Cause method)」手法を提案しています。
ダウンロード数: 49回
紹介文 :
自動運転は社会的期待が大きい技術だが、安全性において多くの課題を抱えている。その解決のために実際に起きた事故から学ぶことは重要である。
本研究は2018年3月に米国アリゾナ州で発生したUberの自動運転システムの人身事故報告書をSTAMPモデルを用いた事故分析手法CAST(Casual Analysis using System Theory)とハザード分析手法STPA(System-Theoretic Process Analysis)とレジリエンスエンジニアの機能共鳴手法FRAM の3つの分析手法を用いて改めて分析したものである。さらに新たに社会、組織、人を含んだシステム全体を捉えるために5階層モデルの考え方を適応することを試みた。いずれも大変新規性の高い取り組みである。
論文とともに具体的な分析の一連の証跡、分析手順、結果など、利用価値の高い付録も収録しているので、ぜひ活用してほしい。
ダウンロード数: 49回
SQuBOK分類 :
年度 : 2020年   分科会 :
紹介文 :
ている。このことは、開発から納品までの工期が短い「短納期型開発プロジェクト」でも同様であり、短い工期中に発生するテストの手戻りは大きな負担になる問題がある。我々はこの問題の解決策として、FaRSeT(Flexible and Rapid Software Test)というテスト手法を提案し、SQiPシンポジウム2018にて発表した。
FaRSeTを用いた探索的テストにより、事前にテストケースを準備する必要がなくなり、仕様変更が多い部分の手戻りを解消することができた。また、重要な探索箇所についてステークホルダの合意を得ながら優先して探索的テストを実施できるようになり、テストの効率化を図ることもできた。
しかしながら、以下2点の問題点が浮き彫りとなった。
? 未実施のテストは不具合が発生していないため、重要な探索箇所として判断できない。
? 不具合数だけでは、残存不具合を想定することができない。
これらの問題点により、重要な探索箇所を判断するための根拠が欠けるため、ステークホルダに探索箇所の合意を得る際の障害になっている。
そこで本研究では、これらの問題点を解決するために、重要な探索箇所を推測し、それを提示する手法「FaRSeT-#(ファルセットシャープ)」を提案する。重要な探索箇所を判断するための手法として、機械学習の1つである自己組織化マップ(Self-Organizing Maps)を利用し、セッションを二次元マップ上に可視化し提示する。
ダウンロード数: 48回
SQuBOK分類 :
年度 : 2020年   分科会 :
紹介文 :
ドメイン知識の共有は多くのチームで重要な課題となっている。我々のプロジェクトでも 以下の状況が
見受けられ ドメイン知識が共有できている状態にする必要があった。
・情報を見つけるのに時間がかかった
・見ていた情報が誤っていた
・知らない情報があり失敗した
・同じような質問を何度もされ回答が面倒
分析の結果、ドメイン知識を共有する活動を継続的に行うためには 以下の 問題を解決する必要があると考えた。
・知識提供者には、知識利用者から必要とされるドメイン知識がわからない
・知識提供者には、ナレッジ DB へのドメイン知識の登録を妨げる 時間 的 制約 と 心理的障壁がある
本研究では知識共有を妨げる問題を解決するために 先行研究を参考に、知識共有を妨げる要因を解消できる「ナレッジスタッフを中心としたニーズ駆動知識共有アプローチ」を考案した ま た 考案したアプローチをもとに、ドメイン知識共有システム を 構築 し た
構築したシステムを 1 年間運用し Wiki が継続的に更新・参照され 知識利用者から必要とされるドメイン知識が Wiki に登録され続ける状態が維持できることを確認した。
考案したアプローチとシステムにより ドメイン知識を共有する活動が継続し ソフトウェア開発の効率
向上と品質安定化に繋がる効果が期待できる
ダウンロード数: 39回
SQuBOK分類 :
紹介文 :
ソフトウェアテストチームがテスト活動に取り組む上で、リーダーから指示を受けるメンバーに受動的な行動が多い場合は、リーダーの管理工数が増加する傾向がある。管理工数を抑えるには、能動的な行動が求められるため、受動的なメンバーに対して能動的になるように育成する必要がある。

育成のポイントを明確にするため、リーダーの行動に着目した。リーダーは能動的な活動ができていると仮定し、メンバーの行動との差を抽出した。
理想的な行動はコンピテンシーモデルを参考に、そこから抽出した特性を基にアンケートを実施し、165名から回答を得た。その結果、受動的なメンバーを効率よく育成するためには、「課題分析能力」と「当事者意識」が重要なポイントであることが分かった。

これらを向上させるため、「CLDAT Method:'Causal Loop Diagram for Active Test engineers' Method」手法を考案した。
はじめに「課題分析能力」と「当事者意識」を阻害している要因に着目した因果関係を示した図を準備した。それを元に阻害している要因を特定、取り除くことで、メンバーの行動を変え、潜在的に持っているソフトスキルを引き出し成長させることを狙った。
実際にCLDAT Methodを活用し、短期間で効果を得ることができたので、その活用方法を紹介する。
ダウンロード数: 38回
SQuBOK分類 :
紹介文 :
アジャイル開発において、どのようなメトリクスが有効かをテーマにした研究です。メトリクスにはいろいろな目的があります。品質を管理する目的が代表的ですが、メトリクスにメッセージを持たせて、見た人に行動するモチベーションを生み出す目的もあります。特に、アジャイル開発では、そのメッセージを早くフィードバックして、改善効果を狙うことができます。一方で、効果を狙うためには、メトリクスも改善させなければなりません。メトリクスの改善や、測定することはコストがかかります。
この研究では、できるだけコストをかけないでフィードバックして、現場の行動をかえていくメトリクスを策定し、効果を評価しました。ごく簡単に取れるデータでも視点を変えて見える化することで、現場の行動が変わったことを確認しました。
アジャイル開発におけるメトリクスの考えの参考になると思います。
ダウンロード数: 37回
紹介文 :
本研究では、ビジネスと機械学習を用いたシステム開発をしっかりとつなぐことを動機とした取り組みを行っています。
既存の機械学習プロジェクトキャンバスをベースラインとし、経験者が加えて考慮する観点をしっかりと調査することで、不確実性を低減するための提言をまとめています。
ダウンロード数: 37回
SQuBOK分類 :
年度 : 2020年   分科会 :
紹介文 :
日本情報システム・ユーザー協会(JUAS)の年次レポート「企業IT 動向調査」によると、日
本企業のIT 予算は8 割が現行ビジネスの維持に使われている。ここ数年「現行ビジネス維持8 割:
新規2 割」の状況が続いており、システム維持管理費の高止まりが経営課題解決に向けたIT 投資
の阻害要因のひとつとなっている。
このような課題を解決すべく当社では『システムカルテ診断支援サービス』を実施している。
本サービスは、稼働中の全システムを対象に保守作業の生産性を検証しシステム保守費の適正化
による投資余力の創出を支援するものである。同サービス導入により得た知見を発表したい。
本論文が日本におけるIT コスト構造変革の一助になれば幸いである。
ダウンロード数: 36回
紹介文 :
コロナ禍によって研究活動自体がオンライン実施となったことを逆手にとって、完全オンライン環境でUXデザイン手法の実践に取り組んだ経験論文です。
UXデザインだけでなく、オンライン環境でのコミュニケーション実施例としても、とても参考になります。
ダウンロード数: 35回
SQuBOK分類 :
年度 : 2020年   分科会 :
紹介文 :
東芝グループでは、SEPG(Software Engineering Process Group)とSQAG(Software Quality
Assurance Group)の両輪にて開発部隊を支える体制で、長期戦略のもとSPI(Software Process
Improvement)活動を推進している。報告者はコーポレートSEPG に所属し、部門のSEPG やSQAG
と連携しながら活動している。本報告では、”組織の成熟度”と”SQAG の成長”の2 軸からなる
「SQAG 進化チャート」と呼ばれる活動の参照モデルを用いて、SQAG の活動を段階的に取り組む際
の問題点とその解決方法を、事例を交えて紹介する。
  

1

2
↑