の目的の1つは、ソースコードの品質保証である。既に、市販の視線計測装置を用いてのプロセスを分析する研究が行われている。しかし、市販の視線計測装置は、ユーザが見た位置をディスプレイ上の座標で出力するため、視線計測中にソースコードの表示位置が変更した場合に対応できない問題がある。そこで本研究では、スクロールを要するソースコードを対象とした、時の視線移動の分析を可能とする視線計測結果分析ツールGAFFAを試作する。評価実験として、スクロールを要するの結果を分析した。結果として、専門家の特徴的な視線移動を確認でき、GAFFAの有用性を示した。

抄録全体を表示

ソースは,ソフトウェアの品質を向上させるための有効な手段の一つであるが,昨今の短期開発やオフショア開発といった開発形態の中で,ソースを厳密に実施することは非常に困難となっている.その結果,テスト後半でのバグの多発や,テスト作業の負荷増大といった問題が起こっている.本論文では,静的解析ツールの導入や第三者によるソースの実施により,プロジェクトの負荷を軽減しつつソースコードの品質を確保するための取り組みについて述べ,その効果について考察する.

抄録全体を表示

オープンソースソフトウェアは，多数のパッチからのソースコードの変更提案を受け入れることで高機能・高品質なソフトウェアへと進化している．しかし，パッチ開発者からの変更提案がプロジェクトの実装方針に従っていないことも多く，ソースコードの内容を検証し適切な内容へと改善するために多くの時間コストがかかっている．変更提案の検証コストを削減するためには，パッチ開発者が変更提案前にソースコード上の問題を取り除くことが望ましいが，何を確認しているか具体的な内容は明らかとなっていない．そこで本稿では，

を通して行われたソースコード改善の内容とその出現回数を分析することで，変更提案に対して修正要求されることの多いソースコード改善の内容，すなわち開発者が確認している項目を明らかにする．4つの Python プロジェクトのデータセットに対する分析の結果，を通して行われる修正のうち56.0%が動作に影響をもたないソースコード改善であることを確認した．また，コード改善のうちパッチ開発者が静的解析ツールを適用することで事前に検出可能な Python 言語の規約違反の問題が13.4%である．本稿の貢献として，で行われているソースコードの変更内容と，静的解析ツールの利用によってパッチ投稿前に検出可能なソースコードの改善内容を明らかにした．

抄録全体を表示

RPA（Robotic Process Automation）とは，主にデスクトップ作業の自動化を目的とした技術である．人間の動作を模倣するbotと呼ばれるプロセスを作成し，外部アプリケーションのUI を操作する．これにより，一定のルールに基づく繰り返しの業務を自動化することが可能となる．しかし，実際の運用では，botに様々な不具合が発生する場合が少なくない．その要因の1つは，開発環境で警告をされない不具合要因に起因する．このRPAで発生する不具合要因は，従来のプログラムとは異なる特性を持つと考えられる．そこで本研究では，RPAにより作成されたbotの不具合要因に関する

を分類する．その結果，分類されたレビューが最多であったカテゴリは，コマンドやbotパーツの置き換えに関する不具合要因が多くの割合を占めるカテゴリ「代替可能な処理」であった．これより，RPAツールにより提供されている既存のコマンドやbotパーツを，可能な限り利用することの重要性を確認した．さらに，とコードの類似度を利用した不具合要因検出ツールの実装も行った．精度検証の結果，RPAで生成されるコードが規則的であることにより，高い精度を得られるとの考察を得た．

抄録全体を表示

近年情報系分野における実践的な教育手法として，ソフトウェア開発型PBL (Project Based Learning)に対する注目が高まっている.GitHubに代表されるソーシャルコーディングツールをソフトウェア開発型PBLに導入する実践事例が報告されている.教育において，学習者へのアドバイスや誤りの指摘等のフィードバックは重要である．とりわけ多くの学習者がはじめてプロジェクト形式でのソフトウェア開発を学ぶソフトウェア開発PBLにおいてフィードバックは重要である．ソフトウェアの品質を高めるためには，開発者同士で検証活動を行うことが効果的であるとされている．一般にFaganにより提唱されたインスペクションが効果的な方法であると認識されている．しかしながら，これらの活動は手間がかかること，同期で行うことなどが障壁となる．このような背景から，近年では，モダン

と呼ばれる，より軽量な方法が実施されている．モダンは，インフォーマルであること，ツールを用いたレビューであること，非同期に行えること，コードの変更のレビューに焦点を当てることを特徴とする方法である．本研究では，これらのソフトウェア開発活動で一般に行われているインスペクションやレビューといった検証活動を開発者同士の枠組みに加え，教授者から学習者への1つのフィードバックの機会ととらえる．具体的には，モダンの対象を要求仕様書や設計文書に拡張し，それらのレビュー活動をGitHub上で実施するためのプロセス(軽量設計文書インスペクションプロセスと呼ぶ)を提案し，このプロセスを実践したソフトウェア開発PBLを報告する．その結果，本稿で提案したインスペクションプロセスを用いることで，教授者が受講生の作成した成果物の各行にコメントでき，的確なフィードバックを提供することが可能となった．

抄録全体を表示

This paper describes a methodology based on domain reference models (DRM) for developing object-oriented software that has few software errors. We have already proposed this concept, which are reference models for modeling domain-specific objects. As the aim of this paper, we give the methodology based on DRM for picking up risk factors that cause software errors.
A DRM define logically the static aspect of a domain independent of infrastructure environment, and represent guidelines of object extraction. For example, we define the DRM that we call the Presentation-Entity-Relay-Service (PERS) model for an industrial monitoring domain. Software engineers classify hot spots, which we redefine as the parts of software that is customized to all unpredictable risk factors, into related components of the DRM. This activity is performed in three phases of system analysis, and object-oriented analysis and design.
We apply our approach to develop communication software of video-exchange systems in Intelligent Transport Systems (ITS). From the results of this application, we could reduce several software errors in the connecting test of this system. Therefore, it is effective for software engineers to develop software with our approach.

抄録全体を表示

オープンソースソフトウェア(OSS)開発においては，コーディングを行うのみならず，開発者割り当て，デバッグ，機能拡張，

，質問回答など，様々な貢献を行う開発者が必要となる．本論文では，貢献タイプを区別するための2つのメトリクスを定義し，多数のOSSプロジェクトの開発者の分布を分析することで， 4つの貢献タイプを同定した．さらに，各貢献タイプに属する開発者に対して原型分析を行い，最終的に7つの貢献タイプを同定した．これらの貢献タイプは，各OSS開発プロジェクトにおいて必要な人的資源の分析に役立つと期待される．

抄録全体を表示

RPA (Robotic Process Automation)とは，主にデスクトップ作業の自動化を目的とした技術である．人間の動作を模倣する Bot と呼ばれるプロセスを作成し，外部アプリケーションの GUI を対象に操作する．これにより，主に繰り返し作業の業務を自動化することが可能となる．しかし，実際の RPA の運用では，Bot に様々な不具合が発生する場合が少なくない．これらの不具合は従来のプログラムと異なる特性を持つと考えられる．そこで本研究では，RPA により作成された Bot の不具合に関する

を分類する．分類基準は不具合の内容と検出手段の 2つである．本分類結果により，RPA の Bot ではプロセスの待機時間の設定が重要であること，アクセス制限などの制約が不十分であること，コードが規則的でありキーワード，類似文検索で検出可能な不具合要因が多いことが分かった．

抄録全体を表示

は重要な品質保証活動であるが，現実には予算や納期の都合により網羅的な実施が難しい場合も多い．そこで本論文では，限られた予算内で“どのモジュールを重点的にレビューすれば最も高い費用対効果を期待できるか”という問題に着目し，各モジュールでのフォールト潜在の可能性，レビューコスト及び他のモジュールとの結合関係を総合的に考慮した0-1計画問題として定式化する手法を提案している．そして，六種類のオープンソースソフトウェアに対するシミュレーション実験を行い，提案法の有効性について論じている．

抄録全体を表示

ソースやデバッグにおいては，ソフトウェアの動作の大局的な流れと処理の詳細の双方を理解する必要がある．呼び出し関係が複雑になると単純に呼び出し関係をたどるだけでは大局的な流れと処理の詳細を理解することは困難である．本研究では，処理の詳細と大局的な流れの双方に対してその理解を支援する手法として，ソースコードを多粒度で表現し，対話的なナビゲーションによるソフトウェア理解支援を可能とするソフトウェアナビゲーションマップを生成する手法を提案する．さらに提案手法を実装したツールを用いて実験を行い，提案手法がソフトウェア理解に有用なナビゲーションを提供できることを確認した．

抄録全体を表示

In October 10, 2013, the ERES (Electronic Records, Electronic Signatures) Committee of PDA Japan Chapter held the symposium titled “Tide of the Computerized Systems in the Pharmaceutical Industry —Impact of PIC/S for the computerized system in the pharmaceutical industries, and CSV (Computerized System Validation) latest information”. We report the outline of the symposium.
  In recent years, new technology, such as Cloud and virtualization, is being introduced into the various industrial worlds, and it is addressed the challenge in the pharmaceutical industry how to validate computerized systems in the case of using such services.
  Although the discussion on CSV has become obsolete in recent years, it can say that new subjects, such as correspondence to new technology, are appearing.
  While EU GMP Annex 11 was reformed, it was adopted also as PIC/S, and we are brighten our prospects of amendment of the CSV guidance (PI 011-3) which will be published by PIC/S.
  On this opportunity, inviting one of GMP inspector of Europe and a consultant who detailed to the CSV, we held the symposium on the newest subject of EU and PIC/S GMP, as well as obtaining the lecture about the devices and efforts towards affiliation of Japan to PIC/S by Mr. Hiyama of former National Institute of Health Sciences Japan. We also presented discussions from our ERES committee on that field.
  The point “Conquest of confliction between a project team and a validation team” which Mr. Stokes, one of invited speaker, displayed the best way for overcome to a new current. Moreover, Mr. Menges, another invited speaker, saying that the focus of Annex 11 is in an operation phase, we can regard as having suggested tacitly that also coming to nothing efforts of project duration and fruiting and making the operation phase over a long period of time farther than a project phase have started constant efforts of those who take charge of it.
  It is also strongly impressed in Mr. Hiyama's lecture, a sincere efforts of the persons related to the PIC/S affiliation of Japan.

抄録全体を表示

株式会社東京証券取引所（以下、東証）では、システムの信頼性向上のための取り組みの一環として、品質管理活動の整備・強化を推進している。この度、発注者視点からの品質管理指標として、「見逃し率」と「すり抜け率」を使用したエラー管理を自社標準（以下、東証システム開発標準）に追加した。ここでは、当該品質管理指標導入の背景とその内容について紹介する。

抄録全体を表示

昨今,ソフトウェア開発業務を行っている日本企業の多くが開発コストの削減を目的として,オフショア開発を実施している.オフショア開発では,安価な労働力が大量に得られる反面,コミュニケーションや品質に対する意識の問題により,納品時に大きな手戻りが発生する恐れがある.そこで我々は,オフショア開発を行うソフトウェア製作フェーズにおいてオフショア先自らが早い段階から均一に品質を作り込んでいけるようにするためのツールに管理図を取り入れ,や単体テストの初期段階でプロセス上の課題を発見し,製作中に改善していくことに取り組んだ.本稿では,オフショア開発における管理図の有効性と,課題に対する改善策について述べる.

抄録全体を表示

当社では,Zone評価をプロダクトや機能単位の品質把握を目的に活用している.Zone評価とは,評価対象の規模と検証量と検出誤り量から,評価対象とプロセスの良し悪しを評価するものである.また,Zone評価の分布とその実績データから潜在誤りの予測も可能である.本稿では,試験フェーズにZone評価を適用した結果をもとに,評価対象の評価と潜在誤り予測の考え方と課題,及びZone評価手法の今後の方向性を述べる.

抄録全体を表示

ソフトウェアプロセス改善活動がITプロジェクト問題, すなわちプロジェクトの納期遅延やソフトウェア品質問題などを解決するという理論的な根拠を明らかにすることを試みた。ITプロジェクトの失敗メカニズム及び改善, メカニズムをモデル化し, そのモデルに基づいてある17件の実際のITプロジェクトを調査し, プロジェクトデータを収集・分析した。その結果, ITブロジェクト問題を引き起こす4件の引き金事象と10件の阻害要因が明らかになった。

抄録全体を表示