SQuBok(R)分類検索
44 件の資料が見つかりました。
ダウンロード数: 6805回
紹介文 :
KPTとなぜなぜ分析を各々改良して組み合わせた、「KWS振り返り」 ([K]PT+[W]hy なぜなぜ分析+[S]olution 対策)を用いた振り返りの仕組みを確立した。 「KWS振り返り」は3つのフレームワーク(議論、コミュニケーション、横展開)、2つの手法(KPT、なぜなぜ分析)、およびそれらを活用するためのプロセスとテンプレートからなり、プロジェクトの振り返りに有効であった。 本研究は2012年度も継続して研究され以下のテーマで登録され知恵るので、参照していただければ幸いである。「KWS振り返りで得られた知識と知恵を、組織的に活用する仕組みの研究- 同じ失敗を繰り返さないために、先人の知恵と知識を先取りする仕組み -」
ダウンロード数: 3807回
紹介文 :
プロセス改善を進めるにあたって発生する様々な課題について各社の対応事例を分析しガイド(事例集)としてまとめたもの。プロセス改善の難しさの一つとして、対応する組織やプロジェクトの状況が経験した改善と同じ状態ということがほとんど存在しない場合が多い。このため、多くの解の中から適切な事例を参考に対応することが多く、手持ちの解を充実させるためにも有益な研究となっている。
ダウンロード数: 2344回
紹介文 :
本論文は、論文作成時最新のプロセスモデルであったCMMI-SE/SW v1.02について、調査とその試行結果をまとめたものであるが、アセスメントに必要な工数や、モデルの意義や懸念などがまとめられており、現時点においても、CMMIに基づくプロセス改善を行う際には、十分参考になるものである。
ダウンロード数: 1119回
紹介文 :
UCD手法をアジャイル開発に取り入れて実施することで、ユーザビリティの高い製品を効果的に開発することができる方法を提案しています。短納期で使いやすいものを作ろうとする場合に参考になります。
ダウンロード数: 1007回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
開発期間が短い派生開発において、追加機能の要求仕様書が短期間に精度の高いものが書けることは重要だ。そこで仕様モレが少ない表記法として「USDM」を導入しようとしたが、従来の書き方に慣れた人たちにとってギャップが障壁となった。そこで慣れない現場の人たちを誘導するために何が必要かを「現場の目線」から探り出し、初心者向けにUSDMガイドラインを作成した。このような障壁は新しい方法を導入しようとするときにつきものであるが、その解決方法として今回のような優しく誘導するという取り組み方は、ガイドラインを作成することで推進者自身がその手法を理解することになり、いろんなケースに応用できる取り組み方である。
ダウンロード数: 880回
年度 : 2014年   分科会 : 第6分科会「派生開発」
紹介文 :
データベース(以降、DB)を共有し合う業務システムでは、他システムのDBの変更が自システムへ与える影響を正確に把握し対処する必要がある。過去の不具合事例を分析したところ、データ項目間の関係性の変化やデータバランスの変化を発生させる類の変更は、不具合の可能性を見過ごしやすいことがわかった。そこで、DB変更時の必須チェック項目と、関連システムのTMを組み込んだシートを作成し、これを介して「変更要求」「理由(背景)」「想定される影響」を伝達するしくみを考案した。
ダウンロード数: 855回
年度 : 2009年   分科会 : 第6分科会「派生開発」
紹介文 :
XDDPは、派生開発に特化した開発プロセスであり、要求仕様からソースコードの変更までの範囲を扱う。一般に、プロセスは個人の習慣や組織の慣習になっているため、XDDPの導入の際にそれまでの慣習が障壁になる。本報告書は、「XDDPの導入障壁」を最初に扱ったもので、障壁の種類や背景について整理されており、さらにいくつかの障壁について克服のヒントを提示している。 ここから、XDDPに取り組む際にはどのような障壁が生じるか、またその克服方法を考えるヒントが得られるだろう。
ダウンロード数: 677回
紹介文 :
現状アジャイル開発でウォータフォールと同じような品質保証活動を行うと、過大な工数がかかるか、品質保証活動が開発の終盤になってしまう。 この課題を解決するために、品質保証部門のみによる監査ではなく、開発現場自身がセルフチェックを行うことで相乗効果を狙うアプローチを「QAAD42」(Quality Assurance in Agile Development by 42)と命名し検証を実施し、その効果を確認した。
ダウンロード数: 632回
年度 : 2012年   分科会 :
紹介文 :
ソフトウェアを修正した場合の影響範囲をいかにして把握し、考慮漏れを防止するのかが提案されています。影響範囲が発生するメカニズムの考察や影響確認の手法も参考になります。
ダウンロード数: 578回
紹介文 :
プロトタイプを用いることでお客様の真の要求を掴み、サービス品質を高めることで、CS(Customer Satisfaction)を超えるCD(Customer Delight):顧客歓喜を実現するプロセスが提案されています。業績向上、従業員満足度向上につながるサイクルも提示され、経営者にとっても魅力的な研究内容になっています。
ダウンロード数: 576回
年度 : 2014年   分科会 : 第6分科会「派生開発」
紹介文 :
既存システムに対して変更や機能追加を行う際、変更箇所や変更による影響範囲を特定するために既存システムのソースコードを調査する。この調査方法が人によって様々で、調査結果もレビューに耐えられるものではなかった。そこで、調査の目的を3種に分類し、標準調査プロセスと調査プロセスガイドラインを作成・検証した。
ダウンロード数: 433回
年度 : 2012年   分科会 :
紹介文 :
開発規模の増大、開発期間の短縮、仕様変更への柔軟な対応を目的に、チケット駆動型開発を取り入れた事例です。新たな開発プロセスを導入した際に、プロセスの理解度向上を図る取り組みも併せて紹介されています。
ダウンロード数: 350回
紹介文 :
リスク管理から閾値を超えた場合は課題管理にうつり、課題の振りかえりにより、次の開発時に新たなリスクの抽出にしよする。このリスクが閾値を超えた場合は課題管理にうつる。この無限につづく繰り返しを「乙∞(おつむげんだい)モデル」として開発した。課題管理プロセスとリスク管理プロセスを融合した、「乙∞(おつむげんだい)モデル」は、プロセス効果の定量化と合わせて有効性で現場で適用可能であると結論付けられた。
ダウンロード数: 321回
年度 : 2012年   分科会 :
紹介文 :
アジャイルプラクティスを教育の場としながらも品質を確保する取り組みの事例紹介です。課題設定とアプローチ、その実施結果が明瞭にわかりやすく表現されているでとても参考になります。
ダウンロード数: 222回
年度 : 2013年   分科会 :
紹介文 :
エンジン制御器(コントローラ)開発においてモデルベース開発(MBD)を導入することにより開発期間の短縮は実現できましたが開発プロセス後半の開発効率の低下は改善できなかったことからMBDの開発プロセスを見直しを行い、ソフトウェア構造と制御対象(プラント)に着目し、シミュレーションを用いるテスト駆動開発を取り入れたプロセス改善方法について提案しています。発表内容はエンジン制御に特化していますが、他の制御機器にも適用できる開発プロセスだと思います。
ダウンロード数: 222回
紹介文 :
「開発の上流文書の質が良くないと下流のテストがタイヘンになる、だったらテストエンジニアが上流から関わってはどうか」というところから出発した報告です。テストエンジニアの視点は設計者や開発者とは異なることを利用し、テストで発見されるべきバグを要求仕様書の段階で見つける試みです。 設計・開発とテスト担当者が別のチームであるプロジェクトなどには、有効な考え方です。
ダウンロード数: 216回
紹介文 :
本研究は、新たな開発スタイルにも柔軟に対応可能な、組織資産管理システムの一手段を提案している。 「組織標準プロセスの構造とテーラリングの概念」にて、部品化した組織標準プロセス(静的プロセス)を、時系列を考慮したライフサイクル(動的プロセス)に合わせて、プロジェクト特性に最適なプロセスを選択するテーラリング指針の概念を提供する。
ダウンロード数: 205回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発で常に悩まされる問題は、変更に伴って予想外のバグが発生することである。 そのための「気付き」の工夫は、これまでも「派生開発」の分科会でもテーマに取り上げられてきた。「DRBFM」の視点を取り入れて「品質」への支障を取り上げる研究も行われているが、それでは範囲が広がり過ぎて、この種の取り組みに慣れていない現場のエンジニアでは見逃しやすい。そこで研究員の組織の中で実際に起きている「影響」の問題を調べてみると、副作用が起きる「場」として「時間」や「メモリー領域」といった、いわゆる「リソース」に共通することに気付いた。「リソース」に着目する効果としては計測が可能で判断のための「限界値」が定義できることである。
ダウンロード数: 188回
紹介文 :
「KWS 振り返り」([K]PT+[W]hy なぜなぜ分析+[S]olution 対策)を用いて振り返りをこなった後の『横展開』と『再利用』のため仕組みの構築である。これにより、組織レベルで同類の問題の再発防止に役立つことが判明した。
ダウンロード数: 176回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では、依頼された変更に対して隠れた変更箇所を見極めにくいことが見積りを難しくしている。その中に変更依頼の内容が具体的すぎるケースがあることに気付いた。 そこでこの問題の解決方法として、「USDM」の「仕様」から「要求」を探る方法に着目したが、この研究のポイントは、届いた変更依頼が「仕様」レベルであるかどうかの「判断」の方法を考案したことであり、これによって、隠れた変更の存在に気付く方法を模索したものである。 この方法に習熟することで見積りのズレが大幅に解消されることが期待できる。 逆にいうと、一般の単純な箇条書きの要求仕様の表現では、この具体的すぎる変更依頼から隠れた変更箇所に気付くことは難しいのかもしれない。
   

1

2

3
↑