• 検索結果がありません。

レビュア特性の見える化によるドキュメントレビュー支援システムの開発

N/A
N/A
Protected

Academic year: 2021

シェア "レビュア特性の見える化によるドキュメントレビュー支援システムの開発"

Copied!
6
0
0

読み込み中.... (全文を見る)

全文

(1)Vol.2015-SE-190 No.19 2015/12/16. 情報処理学会研究報告 IPSJ SIG Technical Report. レビュア特性の見える化による ドキュメントレビュー支援システムの開発 加藤武文†1 大場みち子†2 概要:ソフトウェア開発において品質を確保し,維持していくためには成果物ごとのドキュメントレビューが重要で ある.一方で,レビュー時に成果物をチェックするレビュアのチェック能力には個人差がある.この差異を把握しな ければレビュアのアサインが適切に行えず品質の低下につながると考えられる.本研究では,ページ辺りに平均して どの程度の件数の指摘ができるのか,どのような分野の指摘が多いのかをレビュア毎に把握することでレビュアのア サインを支援するためのレビュア特性の分析方法を提案する.レビュア特性の分析は,レビュー時にレビュアが指摘 した内容を基に開発チーム内の他のレビュアと相対的に評価する形で行う.また,レビュー時の指摘を自動で取り込 み蓄積した上で,提案する分析方法に従った分析結果を出力する開発支援システムを構築する.レビュア特性の分析 方法について開発したシステムを利用して行った評価実験の結果を報告する. キーワード:ソフトウェア品質,ドキュメントレビュー,レビュア特性,アサイン,開発支援. Development of Review Support System by Visualization of Reviewers’ Ability TAKEFUMI KATO†1 MICHIKO OBA†2 Abstract: In the software development, document review is important for ensuring quality. The ability of reviewers varies from person to person. The ability of reviewer is defect discovery number and percentage of defect classification. Assigning reviewers is difficult, if the ability of reviewers has not been grasped. In this paper, proposing a method of analysis the ability of reviewer. The method analyzes the ability of reviewer from data of review. In addition, this paper proposes the review support system according to the method of analysis the ability of reviewer. The author reports results of evaluation experiment of method and system. Keywords: Software quality,Document review,Ability of reviewer,Assign,Support system. 1. は じ め に. ットワーク関連に詳しい開発者や実装に強い開発者といっ た各人の能力はある程度顕在化されている.一方で,レビ. ソフトウェア開発では,より良いソフトウェアを提供す. ュアとして見た場合にはどのような指摘が多いか,他のレ. るために QCD(Quality, Cost, Delivery)の向上が1つの指. ビュアと比べた際の指摘件数はどうかといった能力はあま. 針となっている[1].その3要素のうちの1つである品質. り把握されていない.本研究では,ソフトウェア開発にお. (Quality)を向上させるための取り組みとしてドキュメン. けるドキュメントレビューの高度化を目的として,ドキュ. トレビューやソフトウェアのテストが挙げられる.ドキュ. メントレビューにおけるレビュアのアサインを支援する手. メントレビューでドキュメントに作り込まれた欠陥をチェ. 法の提案と提案手法に沿ってドキュメントレビューを支援. ックし取り除いた上で,実装したシステムをテストすると. するシステムの開発を目標とする.. いう流れで開発は行われる[2].ドキュメントレビューで取 り除ききれなかった欠陥は実装時に新たな欠陥を作り込む 原因となり,その後のテストや修正に多大なコストをかけ. 2. 関 連 研 究. ることになる.本研究では主に同じチームの開発者間で行. レビュアの能力を分析するにあたって,何の情報を分析. われるウォークスルーやパスアラウンドといったピアレビ. する必要があるかを検討する必要がある.また,分析対象. ューを扱う[3].ドキュメントレビューでは,ドキュメント. となる情報を記録,蓄積していく仕組みも併せて必要とな. をチェックするレビュアを適切に選ぶことが成功のための. る.それらに関連した研究を以下に示す.. 一要素であるといえる.レビューの目的や目指す水準を満. 2.1 開 発 履 歴 の 分 析 に よ る 開 発 者 特 性 の 把 握. たすレビュアを選ぶことができなければ欠陥の除去漏れが. 五田らは,ソフトウェア開発における各開発者が持つ特. 起きる可能性が高くなる.ソフトウェア開発において,ネ. 性を把握すること目的に,過去の開発履歴を分析するとい. †1 公立はこだて未来大学 大学院 Graduate School of Future University Hakodate †2 公立はこだて未来大学 Future University Hakodate. ⓒ 2015 Information Processing Society of Japan. う手法を提案している[4].ここでいう開発者特性は,小野 らの提唱する開発者の風林火山モデルに従っている[5].風 林火山モデルとは,開発者に必要な能力を風林火山の4つ. 1.

(2) Vol.2015-SE-190 No.19 2015/12/16. 情報処理学会研究報告 IPSJ SIG Technical Report に分類したモデルである.風は実装能力を表し,林はプロ ジェクトの管理能力を表している.火はプロセス,プロダ クトを向上させる能力を表し,山はプロダクトの品質を向 上させる能力を表している.開発者の理想としては風林火 山の全ての能力を高い水準で有していることが望ましい. 五田らは,Trac,Subversion,開発者へ行ったアンケートを. 3. 課 題 1章で述べた目標の達成にあたり,レビュア各人のレビ ュー能力を顕在化させる必要がある.本研究では,レビュ アのレビュー能力をレビュア特性と呼称する.レビュア特 性を顕在化させるにあたり,具体的なレビュア特性の定義 とその分析方法を検討しなければならない.. 基に風林火山モデルに基づいて分析することで開発者特性 を把握する手法を提案している.この関連研究で分析され ているのは主に Trac や Subversion といった過去の開発履歴. 4. 予 備 実 験. である.適切にアサインを行うためには,上述した関連研. レビュア特性の定義にあたり,実際のレビュー指摘から. 究のような方法でアサインの対象となるメンバの能力を把. レビュア特性の要素として考えられる要素を検討するため. 握する必要がある.本研究でも,開発者特性と同様にレビ. の予備実験を行った.. ュアに存在すると考えられるレビュア特性の定義とそれを. 4.1 被 験 者. 把握するための分析対象を検討することで,レビュアの能. 被験者は公立はこだて未来大学の学部4年生 15 名であ. 力を測る手法が得られると考えられる.. る.被験者の学生はいずれも公立はこだて未来大学の演習 などでソフトウェア開発を1度以上経験している.. 2.2 レ ビ ュ ー 時 の 指 摘 の 蓄 積. 4.2 実 験 内 容. 加藤らは,ドキュメントレビュー時にレビュアが行った. 被験者にあるソフトウェアのドキュメントをレビューし. 指摘を蓄積し,分析することによってドキュメントの品質. てもらい,その指摘内容を比較することでレビュア特性の. を予測しテストケース作成を支援する手法を提案している. 要素として定義できる内容を検討する.レビュー時の指摘. [6].指摘は,指摘対象のドキュメント,指摘ページ,指摘. は,不整合,不明瞭,系列漏れ,項目誤り,表記ミスの5. の分類,指摘内容の形で提案システム上に蓄積されている.. 分類に分けている.. 蓄積された指摘から,指摘の多いドキュメントやそのドキ. 4.3 結 果. ュメント内の箇所,特に指摘件数の多い指摘分類,被指摘. 一部被験者の結果を抜粋する.被験者 X と被験者 Y のレ. 件数の多いドキュメント作成者による作成箇所などを分析. ビュー結果では,欠陥分類毎の指摘の割合に大きな違いが. することでドキュメントの品質予測を行っている.ドキュ. 見られた.被験者 X と被験者 Y の結果を図1に示す.また,. メントの品質予測はテストケースの作成時に重点的にテス. 被験者 Y と被験者 Z のレビュー結果では,指摘分類毎の割. トすべき箇所の推測に利用され,テストケース作成の支援. 合には大きな違いは見られないが指摘件数自体に大きな差. につながっている.開発上の履歴を利用して品質管理に活. があった.被験者 Y と被験者 Z の結果を図2に示す.. かす既存研究もあるが,前提として過去の類似プロジェク トのデータが必要となっている[7][8].ドキュメントレビュ ーの指摘を利用した分析には過去の類似プロジェクトのデ ータが必要とされないというメリットがある.加藤らの提 案システムでは,指摘を pdf から読み込むという形で蓄積 している.pdf 形式のファイルには任意の箇所に注釈を付 けることができ,Apache Tika というライブラリを用いるこ とでそれらの注釈のデータを取得することが可能である. ドキュメントレビュー対象のファイルのアップロードを pdf 形式に限定し,レビュアはアップロードされたファイ. 図 1 被験者 X と被験者 Y の指摘分類割合. ルに注釈として指摘を付けていき,最終的に注釈の付いた pdf をシステムにアップロードするという形式でレビュー を行うことで注釈として書き込まれた指摘のデータを蓄積 している.本研究では,レビュアの能力を分析する以上ど の指摘がどのレビュアによってなされたかという情報など を付加する必要はあるが,pdf からの指摘の読み込みとい う方法を用いることで指摘を蓄積することができると考え られる.. ⓒ 2015 Information Processing Society of Japan. 2.

(3) Vol.2015-SE-190 No.19 2015/12/16. 情報処理学会研究報告 IPSJ SIG Technical Report. 存設計の見直しなどの必要が見込まれる欠陥指摘. これら4段階の影響度を各指摘の重みとして付加すること で,影響度の高い指摘ほどレビュア特性の高評価につなが りやすい分析が可能になる.最終的なレビュア特性は指摘 分類毎に指摘件数と欠陥重要度に応じてスコアを求めたも のとする.具体的な計算方法については 5.2 節で述べる. 5.2 レ ビ ュ ア 特 性 の 分 析 方 法 の 検 討 各指摘分類のスコアは以下に示す式(1)によって求める. ここで,S はスコア,t は指摘の影響度,n は重要度毎の指 摘件数である. 図 2 被験者 X と被験者 Z の指摘件数. !. 𝑡𝑛! … (1). 𝑆= !!!. 4.4 考 察 実験の結果から,各被験者間で見られた違いとして欠陥 分類毎の指摘割合の違いと指摘の件数の差が挙げられる.. この計算式に従って算出した全指摘分類毎のスコアをレビ. 欠陥分類毎の指摘割合が把握できると,レビューの目的に. ュア特性として位置づける.また,レビュア特性の分析は. 従ったレビュアのアサインが可能になると考えられる.指. レビュー対象となるドキュメント毎に行う.ドキュメント. 摘の件数の多さが把握できると,レビューやレビュー対象. 毎に評価する理由は2点ある.1点目は,ドキュメント毎. のドキュメントの重要度に応じたレビュアのアサインが可. に欠陥の混入数や混入率の高い欠陥分類が異なるという点. 能になると考えられる.本研究では,予備実験の結果を受. である.全てのドキュメントをまとめて評価すると,欠陥. けて上記2点をレビュア特性の要素として定義する.一方. 混入数の多いドキュメントを担当したレビュアほど能力が. で,指摘件数だけで評価した際には軽微な指摘の割合が多. 高いと評価されるという問題がある.2点目は,レビュア. いレビュアが能力の高いレビュアとして評価されるという. 特性の変遷を確認できるようにするためである.ドキュメ. 問題が残っている.. ント毎に分析結果を記録しておくことで,過去のドキュメ ントから遡って分析結果を確認していくことができる.変. 5. 解 決 ア プ ロ ー チ. 遷を見ることによってレビュア特性の成長などを確認する ことができる.変遷情報は,アサインの他にレビュア自身. 3章で述べた課題の解決にあたり,4章で述べた予備実. の振り返りとしても利用することができる.振り返りを行. 験の結果を踏まえてレビュア特性の定義と分析方法を提案. うことで各レビュアの成長にも役立てることができると期. する.. 待される.. 5.1 レ ビ ュ ア 特 性 の 定 義 レビュア特性を定義するにあたって予備実験から得られ た指摘分類毎の指摘割合と指摘件数を要素として用いる.. 6. 実 装 シ ス テ ム. また,軽微な指摘の割合が多くとも全体の指摘数の多いレ. 5章で提案したアプローチに従ってドキュメントのレビ. ビュアが能力の高いレビュアとして評価されるのを避ける. ューを支援するシステムを提案する.. 必要がある.本研究では,各指摘に対して影響度の項目を. 6.1 シ ス テ ム の 概 要. 付加することによって前述の問題の解決を図る.影響度は. システムはソフトウェア開発におけるドキュメントレビ. 4段階で定義され,下記の通りの区分けとなっている.. ューに関して利用され,ドキュメントレビューの指摘の蓄. 影響度1. ドキュメントの可読性や体裁を損ねるレベル. 積とその修正状況の管理,レビュア特性の分析と閲覧の機. で,後工程で新たな欠陥作り込みの原因にはなり得. 能を提供する.レビュア特性の分析結果はレビュアのアサ. ない欠陥指摘.. イン時の判断材料やレビュア自身のためのレビューフィー. 影響度2. ドキュメントの内容について読み手によって. ドバックとして利用する.. は誤解を与え,後工程で新たな欠陥作り込みの原因. 6.2 利 用 フ ロ ー. になる可能性のある欠陥指摘.. システムは図3に示すフローで利用する.作成者がドキ. 影響度3. 明らかな設計のミスや誤り.修正されないまま. ュメントをアップロードし,レビュアにレビューを依頼す. 開発を進めると後工程で新たな欠陥の作り込みにつ. る.レビュアはアップロードされたドキュメントについて. ながる欠陥指摘.. レビューを行い,レビュー結果をアップロードする.修正. 影響度4. 後工程の欠陥の作り込みに限らず手戻りや既. ⓒ 2015 Information Processing Society of Japan. 担当者がレビュー結果に対応した修正を完了したタイミン. 3.

(4) Vol.2015-SE-190 No.19 2015/12/16. 情報処理学会研究報告 IPSJ SIG Technical Report グでレビュアのレビュア特性が分析される.. (4) レビュア特性の分析 レビュア特性の分析は登録されたドキュメントのあるバ ージョンの指摘が全て「修正済み」あるいは「修正見送り」 の状態に更新されたタイミングで行われる.計算内容は 5.2. 節で述べた通りである. (5) レビュア特性の閲覧 レビュア特性はドキュメント毎,バージョン毎に閲覧す ることができる.指摘分類毎に求めたスコアが 0 点を 0%, 最高スコアのレビュアのスコアを 100%としたグラフで表 示される.併せて分析対象となったレビュアの平均点もグ ラフに出力することで,対象のレビュアがレビュアグルー プの中でどのような位置付けにあるかを読み取ることがで きる.. 7. 実 験 と 評 価 5 章で述べたドキュメントレビューの支援手法と 6 章で 述べた実装システムの有効性について評価するために行っ た実験について述べる. 7.1 被 験 者 図 3 システム利用フロー. 公立はこだて未来大学の学部4年生の学生7名を被験者 として実験を行う.7名の学生はいずれも大学の演習など. 6.3 提 供 機 能 詳 細. でチームによるソフトウェア開発を平均4件以上経験して. 提供する機能の詳細について述べる.. おり,それぞれの開発でドキュメントレビューも経験して. (1) ドキュメントの登録. いる.. ドキュメントの登録はドキュメント作成者が行い,ドキ. 7.2 実 験 内 容. ュメント名とバージョンを登録する.. 実験は,公立はこだて未来大学の演習で開発された施設. (2) レビュー結果アップロード. 予約システムのドキュメントを対象として被験者にドキュ. レビューのアップロードと指摘の蓄積については 2.2.節. メントレビューを行ってもらう形で行う.被験者によるド. で述べた関連研究と同様に Apache TIKA を用いる.レビュ. キュメントレビューの結果を提案するシステムに入力とし. アは pdf 形式のレビュー対象ドキュメントに対して注釈を. て与え,分析結果として得られるレビュア特性について評. 付ける形で指摘をし,レビュー完了後にシステムに pdf フ. 価する.また,出力されたレビュア特性は被験者に提示し. ァイルをアップロードする.システムはアップロードされ. て被験者からの感想を評価する.レビューの実施前とレビ. た pdf から Apache Tika を利用して注釈データのみを抜き出. ュア特性の実施後に被験者に対してアンケートを実施する. し指摘データベースに登録する.レビュー担当者はアップ. ことで被験者のレビューに対する意識の変化などを確認す. ロード後に pdf から読み取られた各指摘について指摘分類. る.. と重要度を登録する必要がある.指摘分類と重要度の登録. 7.3 事 前 ア ン ケ ー ト 内 容. 作業はシステム上で行う.. 被験者によるドキュメントレビューの前に実施するアン. (3) 修正状況の管理. ケートの内容は以下の通りである.. ドキュメント作成者はシステム上に登録された指摘に従. 質問 1. ドキュメントレビューの経験回数は何回くらいで. ってドキュメントの修正を行う.指摘に対応した際はシス. すか?. テム上で対応する指摘の状態を「修正済み」に更新する.. 質問 2. 発見するのが得意な指摘分類と苦手な指摘分類は. 指摘の内容が読み取れない場合や指摘自身が間違っている. 何ですか?. 場合は「修正見送り」の状態に更新する.指摘の修正状況. 質問 3. ドキュメントレビューを行う際に注意している点. まで管理するのはレビュア特性の分析に正しい指摘のみを. や意識していることがあれば教えてください.. 用いるためである.修正フェーズで「修正見送り」になっ. 7.4 事 後 ア ン ケ ー ト 内 容. た指摘に関してはレビュア特性の計算対象から外される.. レビュア特性の提示後に実施するアンケートの内容は以 下の通りである.. ⓒ 2015 Information Processing Society of Japan. 4.

(5) Vol.2015-SE-190 No.19 2015/12/16. 情報処理学会研究報告 IPSJ SIG Technical Report 質問 1. 分析結果と自覚しているドキュメントレビューの. レビュアをアサインし,ドキュメントの可読性を向上させ. 能力の間に差異はありましたか?. たい場合は不明瞭と表記ミスのスコアの高いレビュアをア. 質問 2. 分析結果に対する納得感はありましたか?. サインするのが適切である.全体の網羅性を向上させたい. 質問 3. これからのドキュメントレビューで改めて気をつ. 場合は各スコアの平均値を指標にするという方法が考えら. けたいと思った点があれば教えてください.. れる.被験者の中で最も平均値を上回っている分類が多い. 質問 4. ドキュメントレビューの度に今回のような分析結. のは被験者 A である.項目誤りの分類のみ平均値を下回っ. 果がフィードバックとして得られるとしたら利用したいで. ていることから被験者 B や被験者 C,被験者 G を合わせて. すか?. アサインすることで被験者 A の不得意な分類を補うことが. 7.5 結 果. できる.上記の考えに従ってアサインを行えば,2 名のレ. 被験者毎のレビュア特性を表1に,レビュア特性のばら. ビュアを選ぶだけで少なくとも平均以上のチェック能力を. つき具合を計算した結果を表2に示す.また,実験の前後. 確保した上でドキュメントレビューを行うことができると. に行った2つのアンケートではドキュメントレビュー時に. いえる.さらにチェックの質を向上させたい場合は,各欠. 気をつけている内容において多くの被験者で変化が確認さ. 陥分類の最高スコアを取得しているレビュアをアサインす. れた.. るという方法がある.上述したアサインの検討は現段階で はレビュア特性を参照しながら開発メンバが行う必要があ 表 1 被験者毎のレビュア特性. 被験者 . 系列漏れ . る.レビューの目標水準や重視する欠陥分類の入力に対し. 項目誤り . 表記ミス . てそれを満たすレビュアの組み合わせを推薦する機能が提. 不整合 . 不明瞭 . A. 47. 19. 8. 5. 14. 案システムに備わっていることが望ましいと考えられる.. B. 31. 25. 9. 14. 4. 最後に,今回の結果では全体の指摘件数が多い不整合では. C. 31. 7. 0. 6. 3. 他の分類よりばらつきが少なく,全体の指摘が少ない系列. D. 34. 3. 0. 0. 6. 漏れや項目誤りの分類はばらつきが大きいという傾向がみ. E. 50. 27. 4. 0. 4. られた.このような傾向の確認については,欠陥混入率の. F. 23. 2. 10. 2. 2. 異なるドキュメントや別の被験者群による実験を行う必要. G. 36. 15. 2. 11. 7. がある.. 表 2 レビュア特性のばらつき具合 評価値. 系列漏れ. 項目誤り. 8. お わ り に. 不整合. 不明瞭. 表記ミス. 平均. 36.0. 14.0. 4.71. 5.43. 5.71. 分散. 77.1. 90.0. 15.6. 25.1. 13.9. 標準偏差. 8.78. 9.49. 3.95. 5.01. 3.73. 変動係数. 0.24. 0.68. 0.84. 0.92. 0.65. ソフトウェア開発において品質管理は不可欠であり,品 質管理は主にドキュメントレビューとテストに分けられる. ドキュメントレビューにはレビュアのアサインを検討する 際にレビュアの能力を示す指標がないという問題がある. 本研究では,ソフトウェア開発における品質管理の高度化 と効率化を目的に,ドキュメントレビューのアサインの支 援手法と提案手法に沿ったドキュメントレビュー支援シス. 7.6 考 察. テムを提案した.ドキュメントレビュー時のレビュアのア. 表1から,特定の被験者が全ての欠陥分類において1番. サインに利用できる指標が存在しないという課題に対して,. 高いスコアを出していないことがわかる。このことから,. ドキュメントレビューでの指摘からレビュア特性を分析す. レビュアには欠陥分類による発見の得意と不得意があると. ることでレビュアのアサインを支援する手法とその手法に. いうことがわかる.表2からは,各欠陥分類においてスコ. 従ったドキュメントレビュー支援システムの提案を行った.. アが大きくばらついているということがわかる.変動係数. 提案手法と提案システムについて被験者に実際にドキュメ. が平均して 0.6 以上とかなり顕著にレビュアによる差異が. ントをレビューしてもらいその結果を分析するという実験. 確認できるため,実際のアサイン時にレビュア特性を判断. を行った.実験からは,レビュアによる各欠陥分類の発見. 材料として利用できると考えられる.被験者 7 名を実際に. の得意と不得意や各欠陥分類のスコアにはアサインに利用. レビュアとしてアサインする場合について考えたい.ドキ. できるレベルのばらつきがあるという結果が得られた.今. ュメント間の整合性を確保したい場合は,整合性のスコア. 後はレビュア特性の分析結果を基にしたレビュアの組み合. に優れている被験者 A や被験者 E をアサインするのが有効. わせの推薦機能の実装など,提案システムの実用性を高め. であるといえる.同様の考え方で,設計の妥当性をチェッ. るための改善を行っていく.. クしたい場合は系列漏れや項目誤りのスコアの高い被験者. ⓒ 2015 Information Processing Society of Japan. 5.

(6) 情報処理学会研究報告 IPSJ SIG Technical Report. Vol.2015-SE-190 No.19 2015/12/16. 参考文献 1) 福島利彦,春日君男,山田茂:品質指標に基づくソフトウェア 品質とプロセスの定量的評価とその組織的活動,プロジェクトマ ネジメント学会誌 13(6),pp.3-8(2011). 2) SQuBOK 策定部会:ソフトウェア品質知識体系ガイド-SQuBOK Guide-,オーム社,2007. 3) Karl E.Wiegers, 大久保雅一:ピアレビュー,日経 BP 社,2004. 4) 五田篤志,山崎尚,玉田春昭,畑秀明,角田雅照,井垣宏:開発履歴 による開発者特性とアンケートによる自己特性の関連分析,研究 報告ソフトウェア工学(SE) 2015-SE-187(5),pp.1-8(2015). 5) 小野和俊:Developer のための 5 つの習慣 —日本をソフトウ ェア 輸出大国にしていくために,デベロッパーサミット 2006 (2006). 6) 加藤武文,大場みち子,藤原哲:ドキュメントレビュー結果を 利用したテスト項目作成システムの開発,日本ソフトウェア科学 会大会論文集 31,pp.169-173(2014). 7) 湯本剛,松尾谷徹,津田和彦:効率的な機能テスト設計のため の欠陥情報の活用方法,全国大会公演論文集 2013(1), pp.321-323(2013). 8) 小川睦子,森崎修司:過去の欠陥データの深刻度と修正工数に 着目した重点検出欠陥の選択手法,研究報告ソフトウェア工学(SE) 2012-SE-177(9),pp.1-8(2012). . ⓒ 2015 Information Processing Society of Japan. 6.

(7)

図   2  被験者 X と被験者 Z の指摘件数 4.4  考 察    実験の結果から,各被験者間で見られた違いとして欠陥 分類毎の指摘割合の違いと指摘の件数の差が挙げられる. 欠陥分類毎の指摘割合が把握できると,レビューの目的に 従ったレビュアのアサインが可能になると考えられる.指 摘の件数の多さが把握できると,レビューやレビュー対象 のドキュメントの重要度に応じたレビュアのアサインが可 能になると考えられる.本研究では,予備実験の結果を受 けて上記2点をレビュア特性の要素として定義する.一方 で,指

参照

関連したドキュメント

Recognition process with a laser-assisted range sensor(B) 3.1 Principle of coil profile measurement This system is only appii~ble fm the case where the coils are all

Assume that Γ > 3γ/2 and the control bound m is large enough such that the bang arc u m starting from the north pole intersects the singular arc z 0 γ/2δ, Then for the problem

We then compute the cyclic spectrum of any finitely generated Boolean flow. We define when a sheaf of Boolean flows can be regarded as cyclic and find necessary conditions

Abstract. In Section 1 we introduce Frobenius coordinates in the general setting that includes Hopf subalgebras. In Sections 2 and 3 we review briefly the theories of Frobenius

NIST - Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF).

Section 3: infinitely many solutions for quasi-linear problems with odd nonlinear- ities; existence of a weak solution for a general class of Euler’s equations of multiple integrals

In recent work [23], authors proved local-in-time existence and uniqueness of strong solutions in H s for real s > n/2 + 1 for the ideal Boussinesq equations in R n , n = 2, 3

II Midisuperspace models in loop quantum gravity 29 5 Hybrid quantization of the polarized Gowdy T 3 model 31 5.1 Classical description of the Gowdy T 3