SQuBok(R)分類検索
24 件の資料が見つかりました。
ダウンロード数: 2444回
紹介文 :
仕様というソフトウェアの核となる成果物の品質向上については、様々なアプローチが議論されています。このため、それぞれの特徴や役割分担を明確に踏まえ、問題に応じて選択し、組み合わせ活用することが重要です。本論文は、形式仕様記述手法と要求記述手法に関し、この観点から位置づけの整理を試みています。
ダウンロード数: 1475回
年度 : 2007年   分科会 : 第5分科会「テスト」
紹介文 :
テスト終了判定基準について、その、客観性をどうやって確保したらよいかについて書いた論文です。 複数のメトリクスを取得し、多方面からの考察を加えることの重要さについて理解できます。 最終的に「金額」という統一メジャーで測定できないかという展望も述べられています。
ダウンロード数: 1356回
紹介文 :
要求仕様書の作成ページ数及び指摘件数とソース量とシステムテストでの障害件数等を採用し重回帰分析で上流での検出量からシステム試験での障害発生との相関を分析した研究論文。
ダウンロード数: 1201回
紹介文 :
改善推進側の立場から、『プロジェクト特性に見合ったレビュープロセスの適用』と『レビュー成熟度に応じたレビュー改善』を客観的な診断に基づき推進する手法を提案している。また、その診断を各プロジェクトが簡単に自己診断できるためのツールも開発しており、プロジェクトが自立的にレビュー改善を推進できるように工夫されている。
ダウンロード数: 520回
紹介文 :
フィールドで嫡出されたバグを分析して、嫡出漏れを防止するテストを特定する。また、そのテストケースを生成するテストケース設計技法を採用しているかを分析して、その組織に採用が必要なテスト技法を抽出する。 また、分析途中には、どの段階(テストレベル)でどのようなテスト技法を使えばどのようなバグを嫡出できるかという知識が必要になる。そのため、①テスト観点を仕様ベース、構造ベースで分類した表の作成、②テストレベルとテスト技法の関係、③その技法で嫡出可能なバグ例が報告されている。
ダウンロード数: 325回
年度 : 2012年   分科会 :
紹介文 :
システム基盤の構築に要する工数見積もりに関する取組みは少ないものです。国内外の学術機構や企業における事例報告においても十分とは言えません。 そこで、非機能要求のコストに影響にする変数をコストドライバとして定義し定量化を試み、見積もりモデルの有意性を実績との比較で検証し評価しています。 そして、この見積もりモデルをWebツールとして社内展開し運用しています。
ダウンロード数: 322回
紹介文 :
仕様というソフトウェアの核となる成果物の品質向上については,様々なアプローチが議論されています.このため,それぞれの特徴や役割分担を明確に踏まえ,問題に応じて選択し,組み合わせ活用することが重要です.本論文は,形式仕様記述手法と要求記述手法に関し,以前の位置づけ整理を踏まえ,具体的な手法確立に向けた試行を行っています.
ダウンロード数: 269回
紹介文 :
プロセスを定着させる重要なポイントとして、継続的な改善がありますが、ここでは、継続的改善を具体的に行う手法/手順を提案しています。原因分析シート、不遵守原因リスト、対策分析シートを用いた方法は、具体的で説得力があり、ここで提案された方法を各所で実践されることをお薦めします。
ダウンロード数: 252回
年度 : 2012年   分科会 :
紹介文 :
2012年SQiP Effective Award受賞。 振り返りは、品質に貢献しないと思われています。そこで、「KPT」と「なぜなぜ分析」を組み合わせたKWS振り返りを作りました。 議論のフレームワーク、コミュニケーションのフレームワーク、振り返り結果の横展開のフレームワークで組織レベルの改善ができ、KWS振り返りでは、本音の議論ができ、真の原因も見つけられ、問題解決への意識が高まり、人材育成につながるなどの効果が見られます。
ダウンロード数: 232回
SQuBOK分類 :
3.10.3.2  バグ分析
年度 : 2010年   分科会 : 第6分科会「派生開発」
紹介文 :
非熟練技術者プロジェクトではデグレードの防止が極めて難しいことに着目し、習熟度に関わらず変更内容に関するチェック項目を確認できる「気づきナビ」を提案しています。これにより、デグレード防止に必要な知識を補うことができるようになります。
ダウンロード数: 230回
紹介文 :
設計段階で数値要求又は数値定義を記述しないというバグを予防するため、仕様書に数値記入が必要と考えた振る舞いを定義した。それを使って仕様書の記述漏れ・誤りを抽出したことが報告されている。
ダウンロード数: 225回
年度 : 2012年   分科会 :
紹介文 :
市場での故障の低減を目指して、過去10年の故障を分析と問題点を明らかにしました。 それを整理して、テスト観点知識ベースの構築を行い、テスト設計に活用することで、テスト観点と項目の強化を行いました。 その分析から整理、解決策の検討からテスト設計への反映に対する取組みについて述べています。
ダウンロード数: 220回
紹介文 :
仕様というソフトウェアの核となる成果物の品質向上について、「形式手法(形式仕様記述)」と「テスト」といった、視点や参加者が異なるコミュニティーにおいて、閉じた視点で別々に議論されてしまっていることが多くあります。本論文では、それらを一つの系統的な視点から比較、議論することを試みています。
ダウンロード数: 194回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発で常に悩まされる問題は、変更に伴って予想外のバグが発生することである。 そのための「気付き」の工夫は、これまでも「派生開発」の分科会でもテーマに取り上げられてきた。「DRBFM」の視点を取り入れて「品質」への支障を取り上げる研究も行われているが、それでは範囲が広がり過ぎて、この種の取り組みに慣れていない現場のエンジニアでは見逃しやすい。そこで研究員の組織の中で実際に起きている「影響」の問題を調べてみると、副作用が起きる「場」として「時間」や「メモリー領域」といった、いわゆる「リソース」に共通することに気付いた。「リソース」に着目する効果としては計測が可能で判断のための「限界値」が定義できることである。
ダウンロード数: 164回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では、依頼された変更に対して隠れた変更箇所を見極めにくいことが見積りを難しくしている。その中に変更依頼の内容が具体的すぎるケースがあることに気付いた。 そこでこの問題の解決方法として、「USDM」の「仕様」から「要求」を探る方法に着目したが、この研究のポイントは、届いた変更依頼が「仕様」レベルであるかどうかの「判断」の方法を考案したことであり、これによって、隠れた変更の存在に気付く方法を模索したものである。 この方法に習熟することで見積りのズレが大幅に解消されることが期待できる。 逆にいうと、一般の単純な箇条書きの要求仕様の表現では、この具体的すぎる変更依頼から隠れた変更箇所に気付くことは難しいのかもしれない。
ダウンロード数: 133回
年度 : 2012年   分科会 :
紹介文 :
CMMIと品質会計を軸にしながら、定量的管理プロセスを含む開発プロセスを構築したの事例です。 現状を分析しながら、一つずつ、一歩一歩 進めていくアプローチは、標準化に取り組むところ全てに参考になるものです。
ダウンロード数: 123回
年度 : 2012年   分科会 :
紹介文 :
システムテスト工程のバグ数が、上工程設計製造工数に強く相関していること、上工程全体工数(設計製造工数+レビュー工数)に対する上工程レビュー工数の比率がある値よりも低い場合に、バグが多発することが判明したとの報告です。対策として、上工程レビュー比率について基準値を設け、上工程完了時にシステムテストバグ数を見積もることが提案されています。
ダウンロード数: 113回
年度 : 2012年   分科会 :
紹介文 :
本事例は、プロセス徹底・推進のための弱点プロセスや要強化ポイント のあぶり出しや、品質指標の有効性の検証することを目的に、定量データを統合的分析した結果を示したものです。 データマインニングではなく、80以上の仮説を立てて分析した点が特徴的です。
ダウンロード数: 111回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
複数の組織がソフトウェアシステムを共有する状況で、届けられた変更依頼が「共通仕様」における変更かどうかを判断できずに変更モレを起こすケースが少なくない。このようなケースでは「人(熟練者)」に依存することが多いが、この研究では、共通仕様に関する変更情報を1箇所に集約して「共有」したことと、共通仕様の判断が困難なときは無理に判断せずに一時「保留」する仕組みを取り入れ、そこに熟練者が判断する機会を集中させたことで、熟練者の負荷を下げているという方法を取った。もう一つの特徴は、共通仕様から「USDM」への展開を自動化したことである。これによって、関係部門に対して同じフォームで展開できるというメリットがある。「熟練者」が関わる部分と「自動化」する部分をうまく使い分けている。
ダウンロード数: 107回
年度 : 2012年   分科会 :
紹介文 :
テストの実施状況を把握するのは何のためでしょうか。テストに関わる者の立場が違えば、必要とする情報も異なります。 本発表では、テスト管理者・テスト実施者・ソフトウェア開発者が、それぞれどんな情報が必要かを整理し、テスト管理上で有効な分析ビューを定義した事例をしています。
  

1

2
↑