キーワード検索


 2001年    2002年    2003年
 2004年    2005年    2006年
 2007年    2008年    2009年
 2010年    2011年    2012年
 2013年    2014年    2015年
 2016年    2017年    2018年
 2019年    2020年  
225 件の資料が見つかりました。
ダウンロード数: 675回
年度 : 2010年   分科会 : 第6分科会「派生開発」
紹介文 :
通常、XDDPの変更プロセスでは「3点セット」を必須としている。これは派生開発で混乱している組織にあっては、この3点セットの成果物を作りながら作業を進めることで秩序を確保するのが狙い。しかしながら、ビジネス系においては「SLCP」などでそれなりの成果物が作られプロセスの秩序も維持されていることがある。また、短納期の要求などもあって、「3点セット」を作成することに抵抗がある。そのような中で、変更を含む要求仕様に関するトラブルに的を絞って取り組むことにしたケース。得意なケースなので、なぜこの「部分適用」の方法が可能なのか、本報告書から読み取って欲しい。
ダウンロード数: 659回
紹介文 :
本研究は継続的にレビューする手法ContinuousReviwについて記すものである。レビュー品質の向上を目指すうえで、「短時間、レビューアのばらつき」の問題は大きい。CR法はプロセスを持つレビュー法であるが、参加者自身がレビューの目的とルールを定め、振り返りを行い、新たなレビュー観点やルールの変更を検討する。特にレビュー期間が限られているプロジェクトの品質担当者にご一読いただきたい。
ダウンロード数: 652回
紹介文 :
設計段階で数値要求又は数値定義を記述しないというバグを予防するため、仕様書に数値記入が必要と考えた振る舞いを定義した。それを使って仕様書の記述漏れ・誤りを抽出したことが報告されている。
ダウンロード数: 638回
紹介文 :
 エンジニアからアイデアを引き出すための手順としての研究です。アイデアは時流にのった旬が大切ですが、採用/不採用に関わらず選定者の観点や責任問題が気になります。最低限何を提出してもらい、どんな観点でレビューすれば良いのかで悩んでいる方にお勧めします。
ダウンロード数: 632回
紹介文 :
ソフトウェア開発において変更が発生したとき、すべての範囲をテストしなおすことは難しい場合に、回帰テストの優先順位をつける方法を提案しています。
限られた期間でデグレードの確認が必要な場合にお勧めです。
ダウンロード数: 631回
紹介文 :
外部からの,プロジェクトとは無関係の「外乱」,とくに保守におけるあらかじめ考えておくことが難しい「外乱」の分類や,要因,対応策を示しています.対応には,外乱が発生した場合の対策と,外乱を発生させないための対策があります.現実のプロジェクトにおいて,すべての外乱をなくしていくことはできないでしょうから,いつ何時であっても,今後発生しうるリスクについて思いを巡らせておく必要があります.このようなときに,現実のプロジェクトとのギャップ分析を行うことによって,それまでは想定外であった外乱があるかもしれないことに気がつくかもしれません.
ダウンロード数: 628回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では、依頼された変更に対して隠れた変更箇所を見極めにくいことが見積りを難しくしている。その中に変更依頼の内容が具体的すぎるケースがあることに気付いた。
そこでこの問題の解決方法として、「USDM」の「仕様」から「要求」を探る方法に着目したが、この研究のポイントは、届いた変更依頼が「仕様」レベルであるかどうかの「判断」の方法を考案したことであり、これによって、隠れた変更の存在に気付く方法を模索したものである。
この方法に習熟することで見積りのズレが大幅に解消されることが期待できる。
逆にいうと、一般の単純な箇条書きの要求仕様の表現では、この具体的すぎる変更依頼から隠れた変更箇所に気付くことは難しいのかもしれない。
ダウンロード数: 603回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発で常に悩まされる問題は、変更に伴って予想外のバグが発生することである。
そのための「気付き」の工夫は、これまでも「派生開発」の分科会でもテーマに取り上げられてきた。「DRBFM」の視点を取り入れて「品質」への支障を取り上げる研究も行われているが、それでは範囲が広がり過ぎて、この種の取り組みに慣れていない現場のエンジニアでは見逃しやすい。そこで研究員の組織の中で実際に起きている「影響」の問題を調べてみると、副作用が起きる「場」として「時間」や「メモリー領域」といった、いわゆる「リソース」に共通することに気付いた。「リソース」に着目する効果としては計測が可能で判断のための「限界値」が定義できることである。
ダウンロード数: 601回
紹介文 :
チームが自立的に動いてくれない。どうすれば自立的に動いてくれるかという古くて新しい問題に立ち向かった。
まずは、チームの能力のよってたつ構造を明らかにした。チームの能力は、4つの属性から成り立っている。環境属性、リーダ属性、メンバ属性、組織属性である。各々の属性は説明変数に分解される。これらの変数には、変えられる変数と変えられない変数、さらにその中間的な変数がある。
リーダは、チームの状況に応じて、どの説明変数を変化させれば良いかを考え、組織を変えたり、メンバーを変えたり、教育したり働きかける。こうすることで、メンバの自主性・主体性が発揮され、チームを活性化できる。
ダウンロード数: 597回
紹介文 :
・パッチの情報を追いかけ適用について。特にパッチ起因の障害発生の可能性とパッチ検証の工数猶予がない問題を解説。NISTの文献 SP800-40(Procedures for Handling Security Patches:米国国家の連邦組織利用のパッチ適用標準)を中心に研究した成果が記載されている。
・また当該NIST基準について国内で展開した場合での弊害/課題についても深く考察されており、2005年当時の課題が今でも有効である点は特筆に値する。(例:NIST標準の適用事業規模、パッチ検証環境の保持困難、管理者負荷、言語の壁他)
・情報セキュリティ早期警戒体制の拡充、強化の一環として、平成16年7月7日に経済産業省から発表された「ソフトウェア等脆弱性関連情報取り扱い基準」および「情報セキュリティ早期警戒パートナーシップガイドライン」についても解説している。
ダウンロード数: 576回
紹介文 :
本論文は、効率よく欠陥を検出できる上級テストエンジニアのテストスキルを、経験の浅い初級テストエンジニアに移転するためのテスト実施トレーニング手法を研究したものです。
具体的には、過去の欠陥情報から上級テストエンジニアのノウハウを抽出し、それをSOHT表にまとめてトレーニングすることで初級テストエンジニアのスキルを向上します。
ダウンロード数: 573回
紹介文 :
専門的なソフトウェアについて、利用者も気づいていない要求を抽出するために、該当ソフトウェアの初心者が熟練者に弟子入りして学ぶ様子を観察しています。
要求を実現する画面案と実機を組み合わせた簡易プロトタイプで評価することで、要求の妥当性検証を短期間・低コストで実施できるよう工夫されています。
ダウンロード数: 565回
紹介文 :
1)リスクを低減するプロジェクト計画についての一考察
要求分析工程のデザインレビューの評価結果から、成功/失敗を予測するモデル「プロジェクト失敗予測モデル」を提案しています。
2)『ソフトウェア開発プロセス点検』の実践と考察
点検の実施結果を定量的に可視化する指標「開発プロセス良好率」を提案しています。
3)4アイテム要求モデルによる要求分析
簡単に導入できる要求分析の手法として、4アイテム(現在の状態、望まれる状態、解決されるべき問題、要求)モデルによる分析方法を提案しています。
ダウンロード数: 550回
紹介文 :
プロジェクトに関わるさまざまな人びとが,各自の仕事の進み具合や課題を全体に投げかけ,また全体として状況を把握し課題に立ち向かっていくためにはどうしたら良いのかということを示しています.このことを考えていくために,コミュニケーションと情報の構造を分析したうえで,具体的な進捗報告の方法の一例が提示されています.プロジェクト全体のコミュニケーションについて考え直したい人や,個々の具体的な進捗報告の方法について考えたい人のそれぞれにとって有用です.
ダウンロード数: 533回
紹介文 :
本研究は、二つのモデルを組織に導入するための、一手段を提供している。                                           興味深い内容としては、CMMIの前モデルである、ソフトウェアプロセス改善モデルCMMとISO9001を融合させる研究の活動内容より、現モデルCMMIへの進化の過程と改善のための構造・構成要素を深く理解することが可能となる。
ダウンロード数: 532回
紹介文 :
研究会で事例を発表し合った。ところが、内容が伝わらない。実際の仕事でも、仕様が誤解されたり、指示が伝わらなかった等、この種の事例にはこと欠かない。そこで、この問題を解こうとした。
 事実を正確に伝え、そこから推論を組み立てるべきなのに、推論が随所に入って議論が混乱してしまう。あるいは、推論同士で根拠の無い議論が空回りしてしまう。まず、事実を正確に伝えることが伝わる第一歩だ。事実が共有できれば、その上にたつ推論の範囲は狭められる。
 元々我々は、話を受ける側の教育ばかり受けてきて、話し手の教育をあまり受けてきていない。一度本論文を読んで、伝わる/えるにはどうすべきか考え直してみると良い。
ダウンロード数: 532回
紹介文 :
1)要求の評価方法の研究
要求の具体的な検証方法として、「貢献度評価による、妥当性及び完全性の評価」を提案しています。
2)形式仕様記述言語による派生開発でのモデル検証
組み込みソフトウェアの派生開発において、スペックアウトした仕様を形式仕様記述言語を用いて整理した事例が紹介されています。
3)プロジェクト管理における統合モデルの提案
特性の異なるプロジェクトに対して統一的な概念で評価およびフィードバックを行うためのプロジェクト管理フレームワークを提案しています。
ダウンロード数: 516回
紹介文 :
WBSを作り、運用するにあたって、
(1) WPの粒度をどう揃えるか
(2) 管理の一元化(WBSとガントチャート)をどのように行うか
(3) 管理の一元化(WBSと課題管理)をどのように行うか
(4) 変更をどう管理するか
(5) EVMにどうつなげるか
(6) メトリクスをどう取るか
(7) 見積りにどう使えばよいのか
という観点で知見をまとめた論文です。
付録のノウハウ集には、実践的なWBSの運用方法が、わかりやすくまとめられています。
ダウンロード数: 504回
紹介文 :
仕様というソフトウェアの核となる成果物の品質向上について、「形式手法(形式仕様記述)」と「テスト」といった、視点や参加者が異なるコミュニティーにおいて、閉じた視点で別々に議論されてしまっていることが多くあります。本論文では、それらを一つの系統的な視点から比較、議論することを試みています。
ダウンロード数: 486回
紹介文 :
現場での課題の分析結果から、レビュープロセスを改善しています。具体的な手順や帳票も提案されており、すぐに現場で活用することが可能です。また、レビューの真の目的は「ソフトウェア品質に対する不安を除去すること」との認識から、不安ヒアリングシートという帳票が開発されており、ユニークな発想で興味深いです。
             

1

2

3

4

5

6

7

8

9

10

11

12
↑