キーワード検索


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

41 件の資料が見つかりました。
ダウンロード数: 1397回
紹介文 :
改善推進側の立場から、『プロジェクト特性に見合ったレビュープロセスの適用』と『レビュー成熟度に応じたレビュー改善』を客観的な診断に基づき推進する手法を提案している。また、その診断を各プロジェクトが簡単に自己診断できるためのツールも開発しており、プロジェクトが自立的にレビュー改善を推進できるように工夫されている。
ダウンロード数: 997回
紹介文 :
プロジェクトの状況・内容・特性を把握し、そのプロジェクトにとってレビューの効果を最大限に発揮することを目的として、研究論文や書籍、SQiP研究会や各種勉強会、各研究員の現場での実践事例など、様々な所で語られているレビューにおける戦略の手法をレビューの計画・準備・実施・振り返りのプロセス毎に整理して「レビュー戦略マニュアル」にまとめている。レビュー戦略の立て方など具体的な事例が書かれており、実用性を考えた内容になっている。
ダウンロード数: 928回
年度 : 2014年   分科会 : 第6分科会「派生開発」
紹介文 :
データベース(以降、DB)を共有し合う業務システムでは、他システムのDBの変更が自システムへ与える影響を正確に把握し対処する必要がある。過去の不具合事例を分析したところ、データ項目間の関係性の変化やデータバランスの変化を発生させる類の変更は、不具合の可能性を見過ごしやすいことがわかった。そこで、DB変更時の必須チェック項目と、関連システムのTMを組み込んだシートを作成し、これを介して「変更要求」「理由(背景)」「想定される影響」を伝達するしくみを考案した。
ダウンロード数: 743回
紹介文 :
各設計工程での手戻り削減と開発計画遵守を目的として、レビューを早期に実施する手法「TPR(TriPartition Review)」を提案している。
早期にレビューを実施するレビュー手法は過去にも提唱されているが、TPRは、各設計工程の期間を大枠・詳細・総合の3つのフェーズに分割し、各フェーズ終了時点の3回で、予め用意したレビュー観点表を用いてレビューを行うという手法で、レビューの実施時期とレビュー観点が決まっているので誰でも効果が得られるという点が特徴となっている。
ダウンロード数: 674回
年度 : 2014年   分科会 : 第6分科会「派生開発」
紹介文 :
既存システムに対して変更や機能追加を行う際、変更箇所や変更による影響範囲を特定するために既存システムのソースコードを調査する。この調査方法が人によって様々で、調査結果もレビューに耐えられるものではなかった。そこで、調査の目的を3種に分類し、標準調査プロセスと調査プロセスガイドラインを作成・検証した。
ダウンロード数: 561回
紹介文 :
品質レベルの兆候をいち早く察知し事前に手を打つことは、品質確保の究極の活動である。
本テーマは、「健康診断」にて活用される「問診票」の考え方をプロジェクトの予兆察知に活用し、ソフトウェア品質確保に適用した事例である。
「問診票」をチェックリストとして活用しているが、人の行動や思いにフォーカスした質問も含んだ形態であり、質問内容の抽出の過程に興味を引く論文である。
ダウンロード数: 403回
紹介文 :
ソフトウェア開発において変更が発生したとき、すべての範囲をテストしなおすことは難しい場合に、回帰テストの優先順位をつける方法を提案しています。
限られた期間でデグレードの確認が必要な場合にお勧めです。
ダウンロード数: 323回
紹介文 :
現場の開発者がUX手法の本来の目的をしっかりと理解し、かつ手法の効果があがるように展開するためには、UX手法の有識者によるサジェストが有効であると提案している。UX手法の組織導入・展開を行う場合に有益な示唆を与えてくれる内容である。検証実験で使用したサンプルも付録に掲載されているので参考になる。
ダウンロード数: 211回
紹介文 :
エキスパートレビューアを育成するためのトレーニング手法として、特に伝え方や教育が難しいドメイン知識に着目し、経験の浅いプロジェクトメンバーに実務において失敗させずにドメイン知識を習得してもらう手法として、EIDeR-Training法(Error Injected Document Review - Training 法)を提案している。短時間での教材作成や、個人学習なのに疑似的失敗体験ができる仕掛けなど工夫がされている。
ダウンロード数: 207回
紹介文 :
プログラムを自動解析・自動実行するConcolic Testingは、制御パスを通るテストケースを自動生成し、抽出した値を使ってパスを自動実行するテスト技術です。
この技術のツールであるCRESTを、リグレッションテストに適用し、利用方法と検証結果をまとめました。
Concolic Testingに取り組もうとする方や、リグレッションテストの自動化に興味のある方の一助となる論文です。
ダウンロード数: 170回
紹介文 :
ソフトウェア開発の現場で起きている失敗の原因とUX手法が解決できる問題を突き合わせることで、現場や問題の状況に合わせて適切なUX手法を選択することを提案している。単に手法ありきで導入するのではなく、本来の目的を把握・意識したうえで、本当に望まれている結果を導くための重要な考え方を提示している。
ダウンロード数: 127回
紹介文 :
基本仕様の制度や品質は、ソフトウェア開発の後工程の工数や品質に
大きな影響を与えます。
そこでこの論文では、テスト技法であるCFD法を基本仕様策定時に取り入れることで、機能仕様の組合せを正確かつ網羅的に抽出し、あいまい性のない表記で記述する方法を提案しています。
テスト技法を利用した上流工程の改善に効果があります。
ダウンロード数: 113回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
ソフトウェアプロセス改善を行う場合,CMMI(Capability Maturity Model Integration)などに代表される「モデルベース型のプロセス改善」と,SaPID(Systems analysis/Systems approach based Process Improvement methoD)などに代表される「問題解決型のプロセス改善」がある.モデルベース型プロセス改善は,実績のある効果的な手法が体系的にプロセスモデルとして纏まっているが,開発現場などの当事者自身が問題の存在に合意できないと,モデル適合を目的化しがちなり,「やらされ感」が出てしまうという課題がある.また,問題解決型プロセス改善は,当事者自身が問題分析を行うため「やらされ感」は出づらいが,適切な分析結果とそれによる十分な改善効果を得るためには,問題分析のスキルや時間が必要となるという課題がある.
本報告では,改善推進者が当事者に既存手法を導入することでプロセス改善を推進する場合,第三のアプローチとして「マフィアオファー型プロセス改善」を提案する.マフィアオファーは,導入したい手法の特徴から,それが解決できる問題の構造を導き,「質問」という形にする.つまり,直接,当事者の問題分析するのではなく,手法が解決可能な問題の存在を質問し,当事者自身に問題構造について考えさせることで「やらされ感」を払拭する.問題構造を推進者側から提示するため,当事者側には問題分析のスキルや多く時間を必要としない.
本報告では,派生開発手法であるXDDP(eXtreme Derivative Development Process)の導入について,マフィアオファーを試行した結果について述べる.
ダウンロード数: 103回
紹介文 :
 プロジェクトマネジャーは忙しいという研究員の言葉を聞いて、それは『プロジェクトマネジャー消防士論』に則ってないからだとこたえたのが始まり。ここで言う消防士とは、火消しではなく『火事が起きないように願い予防処置をする人』が消防士だ。つまり、火消しは消防士 ではなく、消防士は、自分の仕事が無くなるようにと自己否定しながら生きる不思議な人だ。
そのためにはどうすれば良いか。人、組織、システム化対象物、プロジェクト、ソフトウェア、コンピュータの仕組みなど諸々を知り、その特性に合わせて予防処置をすることだ。つまり、プロジェクト・マネジャは、物事の本質をとらえて意思決定をすることである。
さて、本質とは何か。論文を読んでいただこう。
ダウンロード数: 102回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
本発表では、欠陥密度の管理限界を適切に定めるにはどの程度のデータ蓄積が必要なのかの判定方法について議論する。

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

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

本発表では、欠陥密度は発見された欠陥数をLOC数で割ったものとする。また欠陥数はLOC数に対し離散的に発生するのでポアソン分布に従うとする。ポアソン分布においては上下の管理限界は、それまでに蓄積したサンプルの累積欠陥数を累積LOC数で割った欠陥密度があれば定めることができる。本発表では、ある時点において集まったデータを元に算出された平均値が、その後、継続的にデータを蓄積していくにつれどのように推移していくかを予測し、その予測の変動幅がデータ蓄積規模の増加対比小さい範囲に収まっているといえる状態に至れば妥当な管理が可能な程度にサンプルが集まったと判断できると考え、その方法を提案するとともに実施例を提示する。
ダウンロード数: 98回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
センサで車両周囲の環境を検知し、その結果を用いて車両制御する超音波センサシステムの新規開発を担当している。このシステムは、ユーザの実使用環境の影響を受け易いため、仕様開発と量産開発の2つのフェーズに分けて開発している。
しかしながら、近年、自動車メーカからの車載システム機能の高度化、複雑化、短納期かつ高品質要求に応えるためには、従来の2フェーズ開発方式を保つことが難しくなった。
そこで、前後二つのフェーズの一部を重ね合わせたコンカレント開発方式に切り替えることで、品質を落とさずに製品開発期間を短縮する効果を得た。本発表では、具体的な施策と、その結果について紹介する。
ダウンロード数: 97回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
フェリカネットワークスでは,人と技術の両側面からチームのパフォーマンスを高める活動に取り組んでいる.どのようなことを行えばチームのパフォーマンスを高めることができるのだろうか.著者の所属するソフトウェア開発プロジェクトでは,複数の関係する会社と共に,製品の円滑な開発と,品質の確保,チーム力の強化を目指し, 9 年間に渡って試行錯誤を重ね,さまざまな取り組みを行ってきた.
働きやすい職場とはどのようなものか,個々人が切磋琢磨しながらチームとして何かを生み出していくためのコミュニケーションはどうあるべきなのか,チームでディスカッションを重ね,さらにチームワークの練習を繰り返し行ってきた.この活動を継続することにより,お互いを受け入れ,共通のゴールに向かって知恵を絞り,協力することができるチームの文化を築くことができた.品質を高めていくための技術の導入に,その技術を支える人という面からのアプローチを加えることにより,チームは成長を続け,開発の成功につながり,さらに自分たちのコミュニケーション力の向上という面でも成果を出した.
この活動を振り返り,「チームの立ち上げ期」,「チーム学習の発展期」,「チーム文化の定着期」の 3 段階に分けて,各段階において行ってきた活動の内容と,その効果について報告,考察することにより,チームビルディングの有効性について論じる.
ダウンロード数: 83回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
ソフトウェアの欠陥はリポジトリシステムによって管理されることが多くなっており,リポジトリシステムとCI(continuous integration)ツールを連動させ,開発からテストといったソフトウェア開発の全工程を管理することも往々にして行われている.そこで,我々はCIツールへのプラグインとして,リポジトリシステムで管理されている欠陥データから,それぞれの欠陥に対して発見した時間を取得,ソフトウェア信頼度成長曲線に適応,今後発生すると予測される欠陥数についてグラフ化を行い,CIツールにて確認できる環境の構築を行った.
我々が開発したプラグインを用いることで,予測される欠陥数を定量的に把握することができ,開発者やマネージャが悩んでいた欠陥数を見積もることができ,開発の進捗状況を日々確認することができる.加えて,残りの欠陥について後どれだけの欠陥を発見すればよいか定量的な目標ができ開発者のモチベーションの向上や維持につながることが期待される.本研究は共同研究企業とともに有効性を検証している.
ダウンロード数: 79回
SQuBOK分類 :
年度 : 2014年   分科会 :
紹介文 :
 ソフトウエア開発において、障害(ソフトウエアバグ)対応コストは、後工程になるほど高額になっていくため、出来るだけ前工程で障害を検出することが、品質向上、生産性向上につながると言われている。
 しかし、ソフトウエア開発工程の障害対応コストの見える化は、ほとんど行われていない。
 そこで、ソフトウエア開発工程ごとに1件あたりの障害対応にかかるコストを定義し、過去の複数案件について、設計から稼働後までの障害件数を金額に換算することを試みた。
 この試行の結果、上流工程での品質確保の必要性や、コスト増となる「バグ曲線」の存在が明らかになった。
 さらに、「障害分類や障害検出基準」と「コスト定義」を組み合わせることで、“無駄なコスト”や、“本来コストをかけるべき工程”が見えることもわかり、これらの試行結果を整理し、「コストモデル」の作成に至った。
 今後は、「コストモデル」という“ものさし”を使い、品質管理とコスト管理を共存させながら、開発中にギャップを是正するプロジェクトマネジメントを追求していく。
ダウンロード数: 76回
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は課題解決力)
上記の手法と指標を導入し活動した結果、課題ばらしの質を向上する効果が出た事を確認できたので紹介する。
   

1

2

3
↑