キーワード検索


 2001年    2002年    2003年
 2004年    2005年    2006年
 2007年    2008年    2009年
 2010年    2011年    2012年
 2013年    2014年    2015年
 2016年    2017年    2018年
 2019年    2020年  
41 件の資料が見つかりました。
ダウンロード数: 3659回
紹介文 :
品質レベルの兆候をいち早く察知し事前に手を打つことは、品質確保の究極の活動である。
本テーマは、「健康診断」にて活用される「問診票」の考え方をプロジェクトの予兆察知に活用し、ソフトウェア品質確保に適用した事例である。
「問診票」をチェックリストとして活用しているが、人の行動や思いにフォーカスした質問も含んだ形態であり、質問内容の抽出の過程に興味を引く論文である。
ダウンロード数: 2749回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
本発表では、欠陥密度の管理限界を適切に定めるにはどの程度のデータ蓄積が必要なのかの判定方法について議論する。

ソフトウェアの品質管理において欠陥密度は、上下の管理限界を定めその範囲に収まれば懸念なしとし、範囲外になった場合は品質に懸念ありとするように用いられることが多い。このため実務上妥当な管理を行うには管理限界を適切に定めることが重要になる。

管理限界を定める際に過去蓄積されたデータを用いる場合、適切な管理限界を得るためにどれだけのサンプルを集めなければならないかの判断基準が必要になる。

本発表では、欠陥密度は発見された欠陥数をLOC数で割ったものとする。また欠陥数はLOC数に対し離散的に発生するのでポアソン分布に従うとする。ポアソン分布においては上下の管理限界は、それまでに蓄積したサンプルの累積欠陥数を累積LOC数で割った欠陥密度があれば定めることができる。本発表では、ある時点において集まったデータを元に算出された平均値が、その後、継続的にデータを蓄積していくにつれどのように推移していくかを予測し、その予測の変動幅がデータ蓄積規模の増加対比小さい範囲に収まっているといえる状態に至れば妥当な管理が可能な程度にサンプルが集まったと判断できると考え、その方法を提案するとともに実施例を提示する。
ダウンロード数: 2231回
紹介文 :
改善推進側の立場から、『プロジェクト特性に見合ったレビュープロセスの適用』と『レビュー成熟度に応じたレビュー改善』を客観的な診断に基づき推進する手法を提案している。また、その診断を各プロジェクトが簡単に自己診断できるためのツールも開発しており、プロジェクトが自立的にレビュー改善を推進できるように工夫されている。
ダウンロード数: 1716回
紹介文 :
プロジェクトの状況・内容・特性を把握し、そのプロジェクトにとってレビューの効果を最大限に発揮することを目的として、研究論文や書籍、SQiP研究会や各種勉強会、各研究員の現場での実践事例など、様々な所で語られているレビューにおける戦略の手法をレビューの計画・準備・実施・振り返りのプロセス毎に整理して「レビュー戦略マニュアル」にまとめている。レビュー戦略の立て方など具体的な事例が書かれており、実用性を考えた内容になっている。
ダウンロード数: 1582回
紹介文 :
各設計工程での手戻り削減と開発計画遵守を目的として、レビューを早期に実施する手法「TPR(TriPartition Review)」を提案している。
早期にレビューを実施するレビュー手法は過去にも提唱されているが、TPRは、各設計工程の期間を大枠・詳細・総合の3つのフェーズに分割し、各フェーズ終了時点の3回で、予め用意したレビュー観点表を用いてレビューを行うという手法で、レビューの実施時期とレビュー観点が決まっているので誰でも効果が得られるという点が特徴となっている。
ダウンロード数: 1348回
年度 : 2014年   分科会 : 第6分科会「派生開発」
紹介文 :
データベース(以降、DB)を共有し合う業務システムでは、他システムのDBの変更が自システムへ与える影響を正確に把握し対処する必要がある。過去の不具合事例を分析したところ、データ項目間の関係性の変化やデータバランスの変化を発生させる類の変更は、不具合の可能性を見過ごしやすいことがわかった。そこで、DB変更時の必須チェック項目と、関連システムのTMを組み込んだシートを作成し、これを介して「変更要求」「理由(背景)」「想定される影響」を伝達するしくみを考案した。
ダウンロード数: 1279回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
組込みソフトウェア医療機器(e.g.血圧計や血糖計)の設計検証においては、FDAの定めるGeneral Principles of Software Validation(以下、GPSVと記す)を遵守することを念頭におき活動している。GPSVでは、「ソフトウェアの仕様がユーザのニーズや意図する用途に一致しており、ソフトウェアに実装された特定の要件が一貫して満たされていることを、検査および客観的な証拠の提出により確認すること」と定義されているが、具体的にどうやってそれを実現するかは、製造業者に任されている。
従来はソフトウェア要求仕様書をテストベースとして、明示的な仕様のテストプロトコルを作成してきた。また、暗黙的な仕様を押さえるために、過去事例からテスト観点を抽出し、エラー推測しながらテストを実施してきた。しかし、この方法ではソフトウェア要求仕様書のヌケモレを検証できないため、十分なシステムテストができていることを保証できなかった。
そこで、ソフトウェア要求仕様書を試験性の観点でテスト分析する手法を研究し、検証設計ガイドラインとして手順化した。今回、そのテスト分析手法について発表する。
ダウンロード数: 1277回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
ソフトウェアプロセス改善を行う場合,CMMI(Capability Maturity Model Integration)などに代表される「モデルベース型のプロセス改善」と,SaPID(Systems analysis/Systems approach based Process Improvement methoD)などに代表される「問題解決型のプロセス改善」がある.モデルベース型プロセス改善は,実績のある効果的な手法が体系的にプロセスモデルとして纏まっているが,開発現場などの当事者自身が問題の存在に合意できないと,モデル適合を目的化しがちなり,「やらされ感」が出てしまうという課題がある.また,問題解決型プロセス改善は,当事者自身が問題分析を行うため「やらされ感」は出づらいが,適切な分析結果とそれによる十分な改善効果を得るためには,問題分析のスキルや時間が必要となるという課題がある.
本報告では,改善推進者が当事者に既存手法を導入することでプロセス改善を推進する場合,第三のアプローチとして「マフィアオファー型プロセス改善」を提案する.マフィアオファーは,導入したい手法の特徴から,それが解決できる問題の構造を導き,「質問」という形にする.つまり,直接,当事者の問題分析するのではなく,手法が解決可能な問題の存在を質問し,当事者自身に問題構造について考えさせることで「やらされ感」を払拭する.問題構造を推進者側から提示するため,当事者側には問題分析のスキルや多く時間を必要としない.
本報告では,派生開発手法であるXDDP(eXtreme Derivative Development Process)の導入について,マフィアオファーを試行した結果について述べる.
ダウンロード数: 1250回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
当社の情報システムエンジニアリング部門における品質管理ノウハウは、従来から各職場での開発経験をもとにOJTとして先輩から若手に継承してきた。しかし近年は、プロジェクトが大規模化する一方で開発案件に対する要求納期が短納期化の傾向にあり、開発要員の役割分担の細分化、開発業務の委託外注化が進んだことから、プロジェクトの計画段階から終了まで当社の社員(SE)自身による一貫した品質管理業務の機会が失われてきている。
そこで、当社では開発業務での品質マネジメント経験を形式知化したテキストに、現場のプラクティスを元にした演習を加えた教育コンテンツを整備し、広くSEに教育を実施することとした。
また、教育・育成への効果的な動機付けとして、品質管理のプロフェッショナルである「品質管理エキスパート」の認定制度も立上げ、講座受講と業務経験を要件に段階的に認定する制度も開始した。
本発表では、職場のOJTだけに頼らない、品質管理業務を実践できる人材の育成に関する全社的な取り組みの内容、および現時点の成果と今後の方向性について紹介する。
ダウンロード数: 1043回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
アドバンテストではソフト開発の工期と品質を両立するため、トヨタ開発方式*1をカスタマイズ*2しソフト開発現場で利用している。
*1) 次の文献にて著者が名付けた開発方式であり、「欠陥」だけでなく開発工程で生じる「待ち」や「遅れ」の状態もムダとし、改善対象とする特徴を持つ。
”トヨタ製品開発システム”James M.Morgan、Jeffrey K.Liker著
*2) カスタマイズし利用している内容は、次の3点である(SQiP2013にて発表)。
・開発を切り出して部署間の活動を同期化し、かつ平準化を図る。
・切り出した開発目標(マイルストン内容)を詳細計画が網羅する。
・課題ばらしの実施を計画に組み込み、事前に十分な検討を行う。
今回の発表はカスタマイズ内容*2の3点目を深掘りしたものである。工期の遅延が日常化している複数のプロジェクトについて、遅れの原因を確認したところ、課題ばらしの質が確保されていない点が共通していることが分かった。そこで、課題ばらしの質の改善に重点を置いた活動を行った。この活動に際し、LAMDAサイクル(トヨタ開発方式)*3 と PQ指標*4を新たに導入した。
*3) LAMDAサイクル(Look/Ask/Model/Discus/Act)
*4) PQ指標(Pは課題抽出力、Qは課題解決力)
上記の手法と指標を導入し活動した結果、課題ばらしの質を向上する効果が出た事を確認できたので紹介する。
ダウンロード数: 966回
年度 : 2014年   分科会 : 第6分科会「派生開発」
紹介文 :
既存システムに対して変更や機能追加を行う際、変更箇所や変更による影響範囲を特定するために既存システムのソースコードを調査する。この調査方法が人によって様々で、調査結果もレビューに耐えられるものではなかった。そこで、調査の目的を3種に分類し、標準調査プロセスと調査プロセスガイドラインを作成・検証した。
ダウンロード数: 901回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
 ソフトウエア開発において、障害(ソフトウエアバグ)対応コストは、後工程になるほど高額になっていくため、出来るだけ前工程で障害を検出することが、品質向上、生産性向上につながると言われている。
 しかし、ソフトウエア開発工程の障害対応コストの見える化は、ほとんど行われていない。
 そこで、ソフトウエア開発工程ごとに1件あたりの障害対応にかかるコストを定義し、過去の複数案件について、設計から稼働後までの障害件数を金額に換算することを試みた。
 この試行の結果、上流工程での品質確保の必要性や、コスト増となる「バグ曲線」の存在が明らかになった。
 さらに、「障害分類や障害検出基準」と「コスト定義」を組み合わせることで、“無駄なコスト”や、“本来コストをかけるべき工程”が見えることもわかり、これらの試行結果を整理し、「コストモデル」の作成に至った。
 今後は、「コストモデル」という“ものさし”を使い、品質管理とコスト管理を共存させながら、開発中にギャップを是正するプロジェクトマネジメントを追求していく。
ダウンロード数: 849回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
フェリカネットワークスでは,人と技術の両側面からチームのパフォーマンスを高める活動に取り組んでいる.どのようなことを行えばチームのパフォーマンスを高めることができるのだろうか.著者の所属するソフトウェア開発プロジェクトでは,複数の関係する会社と共に,製品の円滑な開発と,品質の確保,チーム力の強化を目指し, 9 年間に渡って試行錯誤を重ね,さまざまな取り組みを行ってきた.
働きやすい職場とはどのようなものか,個々人が切磋琢磨しながらチームとして何かを生み出していくためのコミュニケーションはどうあるべきなのか,チームでディスカッションを重ね,さらにチームワークの練習を繰り返し行ってきた.この活動を継続することにより,お互いを受け入れ,共通のゴールに向かって知恵を絞り,協力することができるチームの文化を築くことができた.品質を高めていくための技術の導入に,その技術を支える人という面からのアプローチを加えることにより,チームは成長を続け,開発の成功につながり,さらに自分たちのコミュニケーション力の向上という面でも成果を出した.
この活動を振り返り,「チームの立ち上げ期」,「チーム学習の発展期」,「チーム文化の定着期」の 3 段階に分けて,各段階において行ってきた活動の内容と,その効果について報告,考察することにより,チームビルディングの有効性について論じる.
ダウンロード数: 808回
紹介文 :
現場の開発者がUX手法の本来の目的をしっかりと理解し、かつ手法の効果があがるように展開するためには、UX手法の有識者によるサジェストが有効であると提案している。UX手法の組織導入・展開を行う場合に有益な示唆を与えてくれる内容である。検証実験で使用したサンプルも付録に掲載されているので参考になる。
ダウンロード数: 745回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
近年、成果物の品質の良し悪しに関わらず、多くのプロジェクトで進捗遅れが頻発していた。日々遅れのリカバリに追われ、進捗管理がうまく回っていないように見受けられた。
進捗管理では、計画・成果量・成果物の品質・工数・要求の変化・管理の状況など、様々な要素をもとに進捗を監視・コントロールする(問題に手を打つ)必要がある。しかし、忙しく混乱した現場ではこれらすべての要素に目を向けることは難しく、うまく進捗管理ができていないことが分かった。
そこで、工数以外の要素も重要だが、まずは我々の組織で風土として根付いており忙しい状況でも計測できている工数を活かして進捗管理ができる姿を目指し、進捗遅れの減少に取り組んだ。
工数からできる限り多くの情報を掴み進捗管理に利用するために、進捗遅れが発生しないための進捗管理のあるべき姿を考えた。それをもとに、工数から直接分かる作業時間や生産性だけでなく、遅れの度合いや品質確保状況の概観を掴む指標、仕事ぶりの見方などを定義し、工数を進捗管理で活用する方法を明らかにした。そして、それらが現場で実行され定着するための仕組みとして、「進捗管理トレーニング」「PM層に対するコンサル」「改善推進者による密着支援」を構築し、実施してきた。
本発表では、工数に重点を置いた進捗管理の定着の取り組みと、現場で進捗管理を実践した結果について紹介する。
ダウンロード数: 702回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
 筆者は2008年にパナソニックエレクトリックデバイス(PED)のコーポレートSQAに着任、社内事業場のSQAの仕組み強化と役立ち度アップのため、SQAのスキル要件を定義し、必要スキルを満たすSQAがソフトウェアの監査を実施する仕組みとした。また、SQAスキル要件と連動したトレーニングマップを作成し、活用、改善を行ってきた。
 このPEDのSQAスキル要件を、パナソニック全社の車載関連部門のSQAに展開し、さらに広範囲のSQAのレベルアップを図ることになった。そこで、スキル要件の更なる体系化の検討を行った結果、SQuBOKを活用することとした。SQAに関する知識体系であるSQuBOKを活用することで、求めるSQA像を、より分かりやすく表現することができ、スキル要件の客観性、網羅性、使用性が向上することを期待したためである。
 本取組みと、SQuBOKを用いて得られたメリット、更に、今回改定したSQAスキル要件とひも付いたトレーニングの体系、スキルレベルの認定制度など、パナソニック車載関連部門におけるSQA育成の取組みを共有し、SQAの育成について、共に考える機会としたい。
ダウンロード数: 630回
紹介文 :
ソフトウェア開発において変更が発生したとき、すべての範囲をテストしなおすことは難しい場合に、回帰テストの優先順位をつける方法を提案しています。
限られた期間でデグレードの確認が必要な場合にお勧めです。
ダウンロード数: 558回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
企業が使用する業務用ソフトウェアシステムの多くは、複数のIT統制、監査、
認証に対応しなければならない。経営管理者はシステム開発・運用に係る管理
記録を整備し、システムの管理品質と製品品質を長く維持しなければならない。
その一方で、開発・運用現場には多種多様な記録・管理方法の混用があり、記
憶に頼る属人的な習慣も根強い。従来の方法では、管理要求を達成するために
多くのコストが必要となり、また、対象システムの増加や規模拡大により、手
順の実現と定着は容易でない。

IT統制、監査、認証の要求実現の急所は「管理記録の網羅性・完全性・追跡可
能性の同時成立」にある。一方で、現場の要求は作業利便性と効率性の追求に
ある。2つの要求に通底する共通課題に着目し、統合情報基盤の構築による、
強制力のみに依らない要求の実現と、有効な定着を目指した。

本論文では、島津製作所グループの基幹業務を支える業務用システムの開発・
運用現場(100種、200名)において、IT統制水準とシステム品質の向上を目
的としたIssue Tracking System(ITS - Redmine)の全面導入事例を紹介する。
5年間のITS運用結果(12万チケット)の定量・定性分析に基づいて「効率・
品質・統制」の観点で導入効果を検証した。その結果、各種要求の実現、管理
手順の有効な定着、低負荷の工数管理、多重管理の無駄をなくす、という効果
が確認できた。
ダウンロード数: 528回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
ソフトウェアの欠陥はリポジトリシステムによって管理されることが多くなっており,リポジトリシステムとCI(continuous integration)ツールを連動させ,開発からテストといったソフトウェア開発の全工程を管理することも往々にして行われている.そこで,我々はCIツールへのプラグインとして,リポジトリシステムで管理されている欠陥データから,それぞれの欠陥に対して発見した時間を取得,ソフトウェア信頼度成長曲線に適応,今後発生すると予測される欠陥数についてグラフ化を行い,CIツールにて確認できる環境の構築を行った.
我々が開発したプラグインを用いることで,予測される欠陥数を定量的に把握することができ,開発者やマネージャが悩んでいた欠陥数を見積もることができ,開発の進捗状況を日々確認することができる.加えて,残りの欠陥について後どれだけの欠陥を発見すればよいか定量的な目標ができ開発者のモチベーションの向上や維持につながることが期待される.本研究は共同研究企業とともに有効性を検証している.
ダウンロード数: 526回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
同じ開発母体による類似製品の並行派生開発において,複数製品で同じ機能に対する仕様(これを共通仕様という)の漏れや誤った解釈は,その影響が複数製品に及ぶ可能性が高いため品質リスクが大きい.
この問題に対し,専門組織を設置し共通仕様を取りまとめて管理する解決方法があるが,小規模な派生開発では開発コストに厳しい制限があり,適用が困難であった.
そこで筆者らは,過去の方法論であまり対象としていない,小規模な並行開発にも対応可能な専門組織に代わる方法により,共通仕様の検出とこれを並行開発する製品の関係者で共有する仕組みを考案した.本発表では、この仕組みについて紹介する.
   

1

2

3
↑