SQuBok(R)分類検索
15 件の資料が見つかりました。
ダウンロード数: 2357回
紹介文 :
仕様というソフトウェアの核となる成果物の品質向上については、様々なアプローチが議論されています。このため、それぞれの特徴や役割分担を明確に踏まえ、問題に応じて選択し、組み合わせ活用することが重要です。本論文は、形式仕様記述手法と要求記述手法に関し、この観点から位置づけの整理を試みています。
ダウンロード数: 835回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
開発期間が短い派生開発において、追加機能の要求仕様書が短期間に精度の高いものが書けることは重要だ。そこで仕様モレが少ない表記法として「USDM」を導入しようとしたが、従来の書き方に慣れた人たちにとってギャップが障壁となった。そこで慣れない現場の人たちを誘導するために何が必要かを「現場の目線」から探り出し、初心者向けにUSDMガイドラインを作成した。このような障壁は新しい方法を導入しようとするときにつきものであるが、その解決方法として今回のような優しく誘導するという取り組み方は、ガイドラインを作成することで推進者自身がその手法を理解することになり、いろんなケースに応用できる取り組み方である。
ダウンロード数: 719回
紹介文 :
要求仕様書の品質を上げるための施策を3つ提案している.一つはWモデルの考えで,要求仕様書とテスト設計書を同時作成し,テスト設計書から要求仕様書にフィードバックをかけるとうもの.もう一つは,仕様書にハイパーテキストを使って,仕様書間の矛盾を発見しやすくしたもの.最後は,記載漏れを防ぐためのチェックリストを提案している.
ダウンロード数: 480回
紹介文 :
「一般的な言語 対 ドメイン特化言語」、「上流での実装詳細の捨象の程度」など、記述方式の特化性はソフトウェア開発における難しい問題です。本論文は、フレームワークを用いた開発における形式仕様記述の活用に関し、この問題について様々な観点からの試行と議論を試みています。
ダウンロード数: 465回
年度 : 2004年   分科会 : 第7分科会「テスト」
紹介文 :
機能追加時に追加機能と既存機能との組み合わせテストを実施するにあたり、重要な組み合わせを絞り込むために、類語辞典(シソーラス)を用いて、追加機能の説明文に含まれるキーワードの類似語や反対語を含む既存機能を関連機能として抽出する手法を提案しています。手軽に実施できる可能性がある点がよく、また着眼点として、テストケースの絞り込みにあたり役立てられる可能性があります。
ダウンロード数: 320回
紹介文 :
仕様というソフトウェアの核となる成果物の品質向上については,様々なアプローチが議論されています.このため,それぞれの特徴や役割分担を明確に踏まえ,問題に応じて選択し,組み合わせ活用することが重要です.本論文は,形式仕様記述手法と要求記述手法に関し,以前の位置づけ整理を踏まえ,具体的な手法確立に向けた試行を行っています.
ダウンロード数: 218回
紹介文 :
仕様というソフトウェアの核となる成果物の品質向上について、「形式手法(形式仕様記述)」と「テスト」といった、視点や参加者が異なるコミュニティーにおいて、閉じた視点で別々に議論されてしまっていることが多くあります。本論文では、それらを一つの系統的な視点から比較、議論することを試みています。
ダウンロード数: 159回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では、依頼された変更に対して隠れた変更箇所を見極めにくいことが見積りを難しくしている。その中に変更依頼の内容が具体的すぎるケースがあることに気付いた。 そこでこの問題の解決方法として、「USDM」の「仕様」から「要求」を探る方法に着目したが、この研究のポイントは、届いた変更依頼が「仕様」レベルであるかどうかの「判断」の方法を考案したことであり、これによって、隠れた変更の存在に気付く方法を模索したものである。 この方法に習熟することで見積りのズレが大幅に解消されることが期待できる。 逆にいうと、一般の単純な箇条書きの要求仕様の表現では、この具体的すぎる変更依頼から隠れた変更箇所に気付くことは難しいのかもしれない。
ダウンロード数: 150回
年度 : 2013年   分科会 :
紹介文 :
開発プロジェクトの中でも特に難しい要件定義の見積もりとコントロールに果敢に挑んだ例として目を引きます。特にCCPMとは何かを知りたい方、実際にCCPMを回してみたい方にはおすすめです。今回は要件定義に絞って書かれていますが、見積もりのしやすい作業と難しい作業に分けて別々の管理手法をとるという本論文の考え方は、新技術・新規分野への参入など、工数が読みにくい局面のコントロールに威力を発揮するでしょう。
ダウンロード数: 137回
年度 : 2011年   分科会 : 第6分科会「派生開発」
紹介文 :
システムが大規模化し、関係組織が多岐にわたる状態になっているにもかかわらず、多くの組織ではシステム全体を知る人材を確保してこなかった。そのため、変更が他部門に影響することを事前に判断できなければ、大きな問題が起きる。特に、「仕様」の状態で変更依頼が届くケースでは、直接関係する部分がイメージしやすいため、他への影響に気付きにくい。この報告書では、仕様レベルで届いた変更依頼から、組織レベルで変更を捉え直す方法を提案している。ただし、変更においても「要求」と「仕様」の階層で捉えることが前提となる。
ダウンロード数: 113回
年度 : 2013年   分科会 :
紹介文 :
派生開発における開発プロセスとして、XDDPの有効性が多くの現場で示されています。一方で、従来とは違う成果物が必要になるなど、短期間での開発を求められる現場では、導入への抵抗感が強いのも事実です。本発表では、この両者をスムーズにつなぐための具体的な方法を提示しており、XDDPの推進に意欲的なチームの助けになることでしょう。
ダウンロード数: 109回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
複数の組織がソフトウェアシステムを共有する状況で、届けられた変更依頼が「共通仕様」における変更かどうかを判断できずに変更モレを起こすケースが少なくない。このようなケースでは「人(熟練者)」に依存することが多いが、この研究では、共通仕様に関する変更情報を1箇所に集約して「共有」したことと、共通仕様の判断が困難なときは無理に判断せずに一時「保留」する仕組みを取り入れ、そこに熟練者が判断する機会を集中させたことで、熟練者の負荷を下げているという方法を取った。もう一つの特徴は、共通仕様から「USDM」への展開を自動化したことである。これによって、関係部門に対して同じフォームで展開できるというメリットがある。「熟練者」が関わる部分と「自動化」する部分をうまく使い分けている。
ダウンロード数: 80回
年度 : 2012年   分科会 :
紹介文 :
1つの変更要求が及ぼす影響というのは時として他システムに跨ることもあります。この影響範囲を特定する方法として派生開発で使用されるXDDPを採用しました。 変更依頼を要求と仕様の階層構造で表現し、要求レベルで他システムへの影響を検討することで影響範囲を特定しようとした試みです。
ダウンロード数: 52回
年度 : 2015年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では新規開発時の作りの悪さや、その後の派生開発での変更作業によってソースコードの劣化が進んでいることが多く、変更ミスを引き起こす要因になっている。ソースコードの劣化を改善する方法としてリファクタリングがあるが、仕様の変更作業の中で、”良かれ“と思って、担当者の判断で安易に構造を変えてしまったり、無造作にリファクタリングにとりかかったりすることでかえって事態を悪化させることが多い。 XDDPでは、仕様変更の中でソースコードの劣化を和らげるために、当該関数に限定した「小さなリファクタリング」を許しているが、これだけでは足りない。 そこで、XDDPを応用してリファクタリングに特化した派生開発プロセスとして「R-XDDP」という方法を提案し、リファクタリング・パターンを限定しながら、混乱することなくリファクタリングに取り掛かる方法を勧めている。
ダウンロード数: 9回
紹介文 :
基本設計書を初めとする上流工程のドキュメントでは、しばしばテストなどの後工程で必要な情報が抜けたり、曖昧な記述により情報が伝わらなかったりします。本論文では、テストケースの自動生成を見据えることで後工程に必要な情報を漏れにくくする設計書の作成アプローチを提案しています。
↑