ソフトウェア・シンポジウム 2016 論文・報告・Future Presentation

ソフトウェア・シンポジウム 2016 にご投稿いただいた論文・報告・Future Presentation に対して，プログラム委員会で審査を行い，下記を採択いたしました．

皆さま，ご執筆，ご投稿いただき，ありがとうございました．

時間	第2会議室	第3会議室	第4会議室	第5会議室
9:00-10:00	形式手法／OSS	テスト	保守／レビュー	Future Presentation (1)
10:15-11:15	OSS／見積り／テキストマイニング	形式手法／保証ケース	要求獲得／保守	Future Presentation (2),(3)
11:30-12:30	プロセス改善／テスト	開発プロセス	チーム／ふりかえり	Future Presentation (3),(4)

形式手法／OSS

最優秀論文賞
[研究論文]VDM-SL仕様からのSmalltalkプログラムの自動生成
小田朋宏（SRA），荒木啓二郎（九州大学）
要旨：
VDM-SL は実行可能なサブセットを持ち，複数のインタプリタ実装が提供されている形式的仕様記述言語である．本稿は，Smalltalk 環境上に構築された ViennaTalk ライブラリに実装された，VDM-SL による実行可能仕様からのSmalltalk プログラムの自動生成器の実装を説明し，生成されたSmalltalk ソースコードの性能評価を示す．

[研究論文]重大不具合に対するOSS開発者の認識調査
松野祐介（和歌山大学），山谷陽亮（和歌山大学）
要旨：
本研究では，重大不具合(High Impact Bug) に対するOSS 開発者の認識を理解することを目的として，GitHubに登録されているOSS 開発者に対してアンケート調査を行う．大規模・複雑化する近年のソフトウェア開発において，日々報告される多くの不具合に対処することは困難である．そのため，不具合修正プロセスの改善を目的とした研究が盛んに行われているが，個々の不具合の種類については十分に考慮されていない．このような背景から，特に近年，High Impact Bug (HIB) が注目されている．HIB とはユーザや開発者に重大な影響を与える不具合のことである．しかしながら，HIB は主に研究者が着目して研究が進められているものであり，実際には開発者がどのように認識しているのかは十分に明らかではない．そこで本研究では，GitHub に登録されているOSS 開発者に対して， HIB に関するアンケート調査を実施し，その結果を分析した．分析の結果，以下の知見が得た．(1) OSS 開発者は，HIB の内Security バグを最も重要視している．(2) OSS 開発者は，開発スケジュールなど開発に影響を与える不具合よりも，ユーザに影響を与える不具合をHIB として認識している．(3) OSS 開発者は，ソースコードの複雑さ，不十分なテスト，および，外部環境の変化をHIB の主な発生原因と認識している．(4) OSS 開発者は，修正パッチのテストや不具合の再現に時間をかけることでHIB を修正している．(5)開発者の役割には違いはないが，開発するプロダクトのドメインによって重視するHIB は異なる．

テスト

最優秀論文賞
[経験論文]大量の状態とイベントを持つプログラムの自動解析とテスト ～ 想定外のイベントを自動テストする ～
下村翔（デンソー），古畑慶次（デンソー技研センター），松尾谷徹（デバッグ工学研究所）
要旨：
画面遷移を含むGUI アプリケーションプログラムのテストを組合せ論理で取り扱うことは，原理的に難しく，順序論理と呼ばれる状態とイベントの時系列を考慮する必要がある．ブラックボックス的な順序論理の組合せ数は膨大になるため，状態やイベントを厳密にモデル化する必要があるが，現場では実践できていない．ここでは，実際のプログラムから状態とイベントを探索し，モデル化を行う．テストは，得られたモデルから時系列の各ノードに対し，イベントの集合，即ちイベントハンドラが実在するイベントを網羅的にテストする．これにより，ある状態において想定外のイベントに対するテストを自動化できる．テストの効率化のために，SMT ソルバのZ3 を用いて不要なテストケースを削減した．提案手法を過去に開発した試作ソフトに適用し，今まで見つかっていなかった想定外のイベントによる不具合を見つけることができた．

[経験論文]Flash メモリ管理におけるConcolic Testing の活用～メモリパターンを含む自動回帰テスト～
西村隆（デンソークリエイト），古畑慶次（デンソー技研センター），松尾谷徹（デバッグ工学研究所）
要旨：
Flashメモリを含むソフトウェアでは，メモリに書き込まれたパターンの影響を受けることから，網羅的なテストが難しい問題を持っている．ここでは，書き込まれたパターンがプログラムの動作に与える影響をConcolic Testingを用いて解析し，パターンの組合せを特定する．同様に，メモリ管理に与えられた引数（変数）についてもConcolic Testingを用いて網羅性の高いテストケース作成することができる．実際のメモリ管理ソフトウェアを疑似したモデルを作成し，メモリパターンを含むテスト入力を自動生成した．このテストの能力を試すためバグを埋め込み，発見できることを確かめたので報告する．

保守／レビュー

論文奨励賞
[経験論文]性能トラブル解決の勘所
鈴木勝彦（ソフトウェア・メインテナンス研究会／株式会社日立ソリューションズ）
要旨：
ソフトウェア保守では，性能トラブルが発生すると原因究明までに時間がかかることが多い．これは，性能トラブル発生時の調査手順が確立されておらず，場当たり的で試行錯誤しながらの調査となっているためである．また，性能トラブルの原因としてどのような要素があるかなどが体系的にまとめられていないことにも起因している．

本研究では，性能トラブルの要素などを4W1H の概念で体系化し，実際の性能トラブル発生時の調査の勘所をまとめた．性能トラブルでお悩みの方々のお役に立つことができれば幸いである．

[事例報告]レビュー要求分析・設計・実装試行でわかったこと
安達賢二（HBA）
要旨：
これまで，SQiP シンポジウムや客先などのさまざまな場面で，「レビューの問題点」を収集してきた．その結果，ソフトウェア開発・保守を中心とした実務において，レビューの問題点が多数存在し，手間がかかる割に効果が実感できないという意見が多いことがわかった．

その打開に向けて，要求仕様書を題材にしたレビューワークショップを構築・提案し，実施した結果，欠陥検出を目的としたレビューにおいて「アドホックレビュー」よりも「レビュー観点設定に基づくレビュー」の方が指摘件数，指摘内容の両面において有効性が高いという結果を得た．

一方で，同一ワークショップに取り組んだ各チームが設定した観点（大項目）とその詳細（具体的な個別確認項目），および欠陥指摘件数，指摘内容には多くのバラつきがあり，その打開に向けた対策が必要である．

今回は，レビュー観点（大項目）とその詳細（具体的な個別確認項目）のバラつき防止・低減を目指して「レビュー要求分析・設計・実装」を試行し，その効果を確認した．

Future Presentation (1)

[Future Presentation (1)]ソフトウェアの少子高齢化が急加速　～開発中心パラダイムに未来はあるか？～
増井和也（ソフトウェア・メインテナンス研究会）
要旨：
書名に「開発」を含むソフトウェア関連図書は多数出版 1)され， 「ソフトウェア 開発」という言葉に違和感を持つ人は少ないだろう．その図書からは，「開発」作業のイメージや期待値はソフトウェアを新規に創りだす創造性のある作業との印象を強く受ける．

では，ソフトウェアの現場では新規に作りだすようなイメージの作業が大半を占めているのだろうか．実際はそうではなく，長年稼働している既存ソフトウェアに対し，法律 の改正，顧客や利用組織の要件変化，インフラソトウェアの更新，競合相手との優位性の確保・維持 ，潜在不具合や稼働後の改修ミス発見などに伴う修正または比較的小規模な機能追加（エンハス）を行う作業のほうがはるかに多いと聞くことがある．このような作業の費用は当該ソフトウェアの稼働開始から5年間累計で初期開発費初期開発費の2倍を超えるという報告という報告 2) もあり，多くのソフトウェア技術者がそのような稼働中ソフトウェアの延命作業に携わ っているというのが筆者の認識である．多くの現場 でこのような延命作業が大半を占め，新規，新規，新規（初期）開発が極端に少ない状況が続くことを「ソフトウェアの少子高齢化」の状態と呼ぶことにする．

本稿では，「ソフトウェアの少子高齢化」の状態が今後も進む根拠，従来の「開発中心パラダイム」が適用可能な範囲の縮小傾向，将来に向けて既存ソフトウェアを中心にした新しい「保守中心のパラダイム」にシフトする必要性を，筆者個人の立場で論及する．

OSS／見積り／テキストマイニング

[事例報告]製品開発におけるOSS導入のためのOSS事前評価手法確立に向けた調査
松本卓大，山下一寛，亀井靖高，鵜林尚靖（九州大学大学院），大浦雄太，岩崎孝司，高山修一（富士通九州ネットワークテクノロジーズ）
要旨：
本研究では，製品にオープンソースソフトウェア（OSS）を導入するか否かを判断する目安として，OSSの品質を事前に把握するための評価手法の確立を目指す．本発表では，事前評価を開発の現場で実施するにあたって必要となる1）開発者がOSS に求める品質，2）品質を評価するために必要な評価指標の取得時間の2 点について調査を行った．

[研究論文]ISBSGデータを用いた見積もり研究に対するIPA/SECデータを用いた追試
山田悠斗，江川翔太（大阪大学），角田雅照（近畿大学），楠本真二（大阪大学）
要旨：
ソフトウェア開発プロジェクトの見積もり技術に関する研究が盛んに行われている．見積もりに関する研究の評価にはISBSG データが用いられることが多い．一方，実証的ソフトウェア工学の分野では既存研究で得られた知見に対する追試(replication study) が重要であるとされている．追試を行うことによって特定の条件や環境において得られた知見に対する再現性や，異なる実験条件から得られる知見の差異を調査することができる．また，追試を行い様々な条件から得られた知見を統合することによって，新規開発プロジェクトにおいてそれと類似した条件での知見を再利用することが可能となる．

本稿では，ISBSG データが用いられている見積もりの既存研究を対象にした追試を実施する．既存研究とは異なるデータセットを用いて実験を行うことで，得られる知見に差異が生じるかを調査する．過去5 年間でISBSGデータが利用されていた論文22 本の中から4 本の論文を選択し，IPA/SEC データを用いて追試を行った．その結果，2 本の論文では既存研究と類似した知見が，残りの2 本の論文では既存研究と異なる知見が得られた．

論文奨励賞
[経験論文]週報のテキストマイニングによるリスク対応キーワード抽出
野々村琢人，安村明子，弓倉陽介（東芝）
要旨：
ソフトウェアの研究開発管理において，週報などの報告書による情報は重要であるが，以下の課題がある．部門内のチームリーダによる集約された週報では情報が欠落してしまう．逆に部門メンバー全員の週報は膨大で冗長な表現も多く，短時間での確認が困難である．今回，メンバー個人の週報および部門全員の週報に対してテキストマイニングを行い，リスク対応に必要なキーワードを抽出できることを確認した．

形式手法／保証ケース

[事例報告]保証ケース作成支援方式について
山本修一郎（名古屋大学）
要旨：
本稿では，独立行政法人情報処理推進機構 技術本部 ソフトウェア高信頼化センター（ SEC: Software Reliability Enhancement Center）の支援を受けて実施した「保証ケース作成支援方式の研究」の主な成果について述べる．

[事例報告]VDM++仕様からC#コードを生成するツールの開発と評価
千坂優佑，大友楓雅，力武克彰，岡本 圭史（仙台高等専門学校）
要旨：
本報告では，VDM++仕様からC#コードを生成するツール（以下，本ツール）の開発と妥当性・有用性評価について報告する．本ツールを用いることで，VDM++仕様からC#コードを生成でき，CodeContracts による事前・事後・不変条件を用いた生成コードの検証が可能となる．

[研究論文]システム理論的因果律モデルに基づくプロセス改善分析
日下部茂（長崎県立大学），荒木啓二郎（九州大学）
要旨：
プロセスの構築や改善にあたって，システム理論的因果律モデルを用いて対象プロセスを分析するアプローチを提案する．ライフサイクルプロセスを，複数のプラクティスや作業成果物が一つの系をなすシステムと考え，それらの間の相互作用をシステム理論的因果律モデルSTAMP を用いて分析する．STAMP によるモデリングではいくつかの分析が可能であるが本稿では特にSTPAによる分析について議論する．提案手法の有効性については，これまでの形式手法の導入によるプロセス改善の事例と同様の改善が，提案の分析で系統的に導くことができるかという観点で評価する．

要求獲得／保守

[経験論文]ソフトウェア開発現場でのMinute Paperの適用
岡本克也（エヌ・エム・エス），中谷多哉子（放送大学），黒須正明（放送大学）
要旨：
要求工程での打ち合わせにおいてコミュニュケーション不良とクライアントの参加意識の低さがしばしば見られる．これらを早めに検出して関係者の参加意識を高め，ベンダーとクライアントが製品に対して同じイメージを共有することが望ましい．その為にアクティブ・ラーニング手法のひとつであるMinute Paper をソフトウェア開発に適用し，その結果を横断的に分析することで議事録では拾いきれない情報を獲得し，参加意識を高めることでその有用性を確認した．

[事例報告]「保守あるある診断ツール」による保守課題の可視化事例
室谷隆（TIS）
要旨：
近年のシステム開発は，既存のソフトウェアに追加，改修するといった保守開発が大半であり，生産性や品質の向上に向けたプロセス改善のニーズが高まっている．

プロジェクトの課題を可視化する方法としては，CMMIなどのアセスメントや，IPA/SEC が提唱しているSPIN3CHなどがあるが，課題を導き出すための専門家が必要であり，時間，コストも掛かるのが通常である．

この様な背景の中，私達は保守開発の課題を短時間で見付け出すためのツールを作成し，適用した．その結果，保守の課題を可視化するツールとして有効であると認識した．またその使い方に関しても興味深い知見が得られたのでここに事例を紹介する．

[研究論文]記憶力に基づくプログラム理解容易性評価尺度の追加実験
村上優佳紗（近畿大学大学院），角田雅照（近畿大学大学院），中村匡秀（神戸大学大学院）
要旨：
ソフトウェア開発の生産性を高めるためには，理解しやすいソースコードを書くことは非常に重要である．そのため，ソースコードの複雑度を評価する指標が，これまで数多く提案されてきた．例えばサイクロマチック数やCKメトリクスはソースコードの複雑度を評価する代表的な指標である．ただし，複雑度が低い場合でも，必ずしもプログラムが理解しやすいとは限らない．プログラムの理解のしやすさは，理解のために必要とする記憶量の多寡に基づくと仮定し，プログラム理解容易性評価尺度が提案されている．この尺度では，人間の短期記憶は，大きさの限られたキューになっていると仮定し，プログラムを読む時に，覚えるべき変数の個数がキューの大きさの上限を超える場合，理解が難しくなるとしてプログラムの理解容易性を評価している．ただし，指標を評価する実験では，学生を被験者としている．学生は年齢やプログラム経験が比較的均質であり，学生以外の，より幅広い年齢の被験者に適用した場合，必ずしも評価尺度がプログラムの理解容易性を表しているとは限らない．そこで本研究では，大学の教員を被験者実験とし，この評価尺度がプログラムの理解容易性を適切に表すかを確かめた．学生24人と大学教員8人を被験者として実験を行った結果，評価尺度がプログラムの理解容易性を適切に表していることがわかった．

Future Presentation (2),(3)

[Future Presentation(2)]非連続な実装を持つ連続値の境界値分析の考察
秋山浩一（富士ゼロックス）
要旨：
2016 年の閏日（20160229）は素数か否か？ という素朴な疑問から「ある年に素数はいくつあるか」という問題に発展し，この問題を解くプログラムが生まれた．ところがそのプログラムには境界値にまつわるバグがあった．本稿はそのバグの分析と対応について考察したものである．

年月日を“YYYYMMDD”の8 ケタの数値で表現した場合その数値は必ず増加するが，月変わりや年変わりの境界では非連続となる．今回のバグは年変わりの境界で発生した．プログラムは容易にデバッグできたが，デバッグ後のプログラムが正しく動作することの検証について，計算量が多く答えがでなかった．冷静になって考え直したところ，数学的に解ける問題であることがわかった．

この経験を公開することで境界値にまつわるやっかいなバグの解決ヒントになることを期待している．

[Future Presentation (3)]対話型アプリケーションを対象とした多種多様な環境に対応できるテスト実行自動化に関する手法（前半）
安達悠，岩田真治，丹野治門（日本電信電話），清水誠介，今井勝俊（NTTデータ）
要旨：
ソフトウェア開発において，1 つのテストスクリプトで様々なテスト実行環境に対応したテスト実行自動化を実現することで，テスト実行自動化ツールの使い分けによって発生するツール学習コストや，テスト実行環境ごとに発生するテストスクリプト作成の手間を削減する手法について提案する．

プロセス改善／テスト

[経験論文]開発の"待ち"，"遅れ"，"欠陥"を防ぐプロセス改善　～PM改善ナビを利用した"待ち"，"遅れ"，"欠陥"の改善活動～
比嘉定彦（アドバンテスト）
要旨：
開発工程の中で発生する「待ち」や「遅れ」の状態をムダであるとし，(「欠陥」と同様に)改善する手法として，トヨタ開発方式[1]というのがある．我々は，必要な部分から順次カスタマイズし，開発現場へ導入した．その結果，トヨタ開発方式は開発の「待ち」，「遅れ」，「欠陥」を未然に防ぐ有効な解決法であることを確認した[2][3][4]．

開発の「待ち」，「遅れ」，「欠陥」の改善は，プロジェクト管理が扱う範囲全体から見ると一部の領域にすぎない．しかし，プロジェクト管理の実施効果は製品開発のＱＣＤ実績で把握される点を考慮すると，開発の「待ち」，「遅れ」，「欠陥」を改善する活動領域は重要である．

我々は数年に渡るトヨタ開発方式の利用実績を基に，開発の「待ち」，「遅れ」，「欠陥」を改善するための要点を体系化して「PM(ProjectManagement)改善ナビ（以降PM改善ナビと記述する）」へ組込み，開発現場で適用を試みた．

本報告では，開発の「待ち」，「遅れ」，「欠陥」を防ぐプロセス改善を提案し，その改善活動を支援する「PM改善ナビ」を開発現場に適用した結果を紹介する．

最優秀発表賞
[経験論文]ゲーミフィケーションを用いた探索的テストの効果報告
根本紀之（東京エレクトロン）
要旨：
テスト仕様書ベースのテストが好きな開発者は少ない．もちろん例外はあるだろうが，一般的には少ないと言って過言ではないであろう．理由は創造的な活動ではない，テスト仕様書の作成に時間がかかる，など様々である．

本報告では，テスト仕様書ベースのテストの一部を，探索的テストに変え，さらにゲーミフィケーションの要素を入れることで競争争原理が働き，バグを探すことが面白くなり，通常のテスト仕様書ベースのテストより多くのバグを発見できた結果とその効果を報告する．さらにはテスト実行前に戦略立案，テスト実行後にふりかえりを行うことで，バグの効果的に見つける方法を共有する取り組みの効果を紹介する．

[経験論文]ソフトウェア開発プロセスの違いによるテストプロセス成熟度の比較・考察
河野哲也，高野愛美（日立製作所）
要旨：
本稿では，3つの異なる開発プロセスから少数のQAチームを取り上げ，それらのテストプロセス成熟度の比較・考察を行い，それらの違いを明らかにする．我々の事業部では,多様な顧客要求などに応じて,開発プロセスを柔軟にテーラリングしてきた．しかし，QA部門では，それら開発プロセスに特化したテストプロセスは定めず，現場の創意工夫によつてテストプロセスを適応・改善させてきた．本研究では，それらテストプロセスに対して，テストプロセス改善モデルとしてTPI NEX(R)を取りLげ,成熟度の評価を行い評価結果の比較・考察を行う．それにより，異なる開発プロセスにおけるテストプロセスの違いを明らかにする．

開発プロセス

[事例報告]新商品分野でのソフト品質保証プロセスの構築事例
久木達也（リコー）
要旨：
本稿では，プロジェクションシステム(PJS)事業の新規立ち上げに伴い，新たなソフト品質保証プロセスを構築した事例を報告する．

事業ニーズに確実に応えるために，従来からの品質保証プロセスを適用した場合の課題を洗い出し，個々の課題に対し，商品分野の特性や組織の実力を考慮しながら，商品開発／品質保証プロセスを検討した．

この活動の内容と実施結果，及び，得られた知見について述べる．

[経験論文]情報システム開発におけるソフトウェア資産の上流シフトへの対応
松山浩士（サイバーリンクス），鯵坂恒夫，飯ヶ谷拓真（和歌山大学）
要旨：
プログラムコードを自動生成するアプリケーション開発ツールが普及するきざしがある．このツールはデータベーステーブルの設計も自動化するので，ソフトウェア開発のプロセス・視点・方法論がこれまでと大きく変わる．プログラムもテーブルも資産(asset)ではなくなり，問題記述・要求仕様のパターンや記述法がそれに代わることになる．本稿では，このような上流資産として望まれる性質を求めるための試みについて報告する．

[経験論文]BRMSを適用するためのフィージビリティ・スタディ
李東昇（富士通システムズ・イースト）
要旨：
経営やビジネス環境の変化に追随するため，情報システムの開発・変更を即応させなければならない．手段として，超高速開発[1]という考え方とそれを支える超高速開発ツールが注目を浴びている．BRMS（Business Rule Management System）やアジャイル開発手法やDevOpsは，その代表である．BRMSの適用に向けて，下流工程での主な課題として「ルール設計方式の指針はどう決めるか」と「ルール方式導入による性能的に不安はないか」の２つがある．これらの課題に対してビジネスルールの組み合わせ方と性能に着目しフィージビリティ・スタディを行った．本論文では疑似的な業務モデルを想定し，性能測定を通してルール設計方式の選択指針について述べる．

チーム／ふりかえり

[経験論文]チームの協働状態を測る：Team Contribution Ratio　～手間のかかる質問紙からの脱却～
増田礼子（フェリカネットワークス），森本千佳子（東京工業大学），松尾谷徹（デバッグ工学研究所），津田和彦（筑波大学大学院）
要旨：
本論文では，ソフトウェア開発チームの特性を，容易に計量するための指標を構築することを目的とする．ソフトウェア開発に影響を与えるチーム特性には，リーダシップやコミュニケーションなど，さまざまな要因が考えられる．チーム特性の計量には，心理尺度を応用した質問紙を用いた方法が使われている．質問紙による計量は，大量の調査データを統計処理する必要がある．そのため，質問紙を用いた計量は，実務現場においては敷居が高く，個々のチーム特性の把握を容易に行うことができないという課題がある．

本稿では，チーム特性の要素のひとつである協働を対象とし，構築した指標であるチーム貢献係数(Team Contribution Ratio) を用いた計量を実施し，その内容を報告する．チーム貢献係数は，経済学において所得の均等度合いを表すローレンツ曲線とGini 係数を応用した指標である．協働の分析対象は，チームメンバそれぞれが持つ技術，知識，経験を開示し，共有するための知識ベース構築活動とした．具体的には，協働の道具として用いたグループウェアの投稿数と投稿者数を基にした計量である．

[経験論文]PBLにおけるチーム比較を簡便化するための試行的取り組み
森本千佳子（東京工業大学），松尾谷徹（デバッグ工学研究所）
要旨：
本研究の目的は，プロジェクト型のチーム学習の教育効果を実務経験のない教員でもできるだけ容易に把握できるようにする点にある．その第一歩として，本稿ではチームの比較を簡便化する手法の試行結果について報告する．

ソフトウエア開発は複数のメンバーが集まったプロジェクト形態を取ることが多い．それを踏まえて，近年日本では情報系学生の教育にプロジェクト型のアクティブ・ラーニング手法であるProject Based Learning （PBL）を取り入れた教育が増加している．PBLの狙いは，チームでの協働をシミュレーションすることを通して課題解決手法およびチームマネジメントを体験学習させることにある．しかし，従来の講義提供型の授業と異なり，チームをベースとしたPBLではその学習効果の把握手法は未だ確立されていない．とくに，実務経験のない教員にとっては，学習の肝となるチームの状態がどうなっているかを客観的かつタイムリーに把握することが難しい．

本研究では経済学の分野で所得格差の把握に用いられるローレンツ理論のジニ係数をPBL授業への参加状態を把握するチーム貢献係数として応用し，チームの比較を試行した．その結果，チーム貢献係数によってチームの比較が簡便化できたことを報告する．

[経験論文]学生によるUX／アジャイルソフトウェア開発のYWTふりかえり事例
浦本竜，奥村潤，佐野隼輔（北九州市立大学大学院），山崎進（北九州市立大学）
要旨：
チーム開発の経験が少ない初心者のみで構成されたチームにおける開発は，様々な要因で失敗をすることがある．そこで，チーム開発の初心者であった我々が行った 3 件のアジャイル開発手法とUX を取り入れた開発経験をYWT でふりかえることにより，教訓を導く．導かれた教訓によって，初心者のみで構成されたチームにおける開発で，初心者にありがちな失敗を回避できるのではないかと考えた．そこで本稿では以下2 点のことを目的としている．

• チーム開発の初心者に対して，失敗を軽減する為の教訓を導く
• YWT の使用感を考察する

YWT でふりかえりを行い，教訓を導くことができた．また，次の開発の方針を定めることができた．教訓を導くことができ，次の開発の方針が定めることができるYWT はふりかえり手法として有効であると考えられる．

将来課題として，導き出した教訓は，初心者のみで構成されたチームに適用して効果を確かめる必要がある．またふりかえり手法としてYWT は普遍的に有効であるかを調査する必要がある．

Future Presentation (3),(4)

[Future Presentation (3)]対話型アプリケーションを対象とした多種多様な環境に対応できるテスト実行自動化に関する手法（後半）
安達悠，岩田真治，丹野治門（日本電信電話），清水誠介，今井勝俊（NTTデータ）
要旨：
ソフトウェア開発において，1 つのテストスクリプトで様々なテスト実行環境に対応したテスト実行自動化を実現することで，テスト実行自動化ツールの使い分けによって発生するツール学習コストや，テスト実行環境ごとに発生するテストスクリプト作成の手間を削減する手法について提案する．

[Future Presentation (4)]非機能に関する要求仕様書作成の課題 ～開発現場における問題とUSDMを用いた解決方法～
水藤倫彰（デンソー），古畑慶次（デンソー技研センター）
要旨：
現実のソフトウェア開発では，非機能要求を文書化できていないため，要求定義の段階で十分な検討ができていない．そのため，システムテストで非機能要求に関する問題が発生すると，システムレベルでの後戻りが発生し，プロジェクトに大きな影響を与える．

本稿では，要求を仕様化する方法であるUSDMを利用し，設計仕様から非機能要求の抽出を行う方法を提案する．設計，コードレビューの指摘事項である非機能要求についての設計仕様に着目し，非機能要求に関する仕様を抽出する．続いてISO25010の品質特性の観点とロジカルシンキングの抽象化の考え方を適用して，仕様から要求とその理由を導出することにより非機能要求についての要求仕様書を作成する．

メニュー

新着情報
SS2016 について
SS2016 実施報告
SS2016 表彰論文
SS2016 論文集

プログラム

キーノート・フォーラム
論文・報告・FP
ワーキンググループ・チュートリアル
併設イベント

参加申込要領

論文・報告募集
投稿要領
ワーキンググループ募集

スタッフ
リンク集


Facebook ページ

---

Copyright 2015, 2016 Software Engineers Association. All Rights Reserved.

ソフトウェア・シンポジウム 2016 に関するお問い合わせは，ss2016inquiry @ sea.jp までお送りください．