SQiPシンポジウムアブストラクト作成のポイント

4. 4Copyright © 2012 NTT DATA Corporation だからお前は誰なんだよ  名前：大杉直樹  専門：ソフトウェア工学（実証的ソフトウェア工学）  経歴：  2004年9月  奈良先端科学技術大学院大学博士後期課程修了  2004年10月～2007年3月  同大学特任助手  2007年～現在  株式会社ＮＴＴデータ技術開発本部勤務  アクセス：  Twitter: @ohsugi  LinkedIn: www.linkedin.com/in/ohsugi

5. 5Copyright © 2012 NTT DATA Corporation お約束  本発表の内容は全て大杉直樹個人の見解であり、公式・非公式を問わず所属組織の見解ではありません。  実名で disりたい議論したいなら今日の講演で。  匿名で disりたい議論したいなら twitter で直接大杉へ。  派手に炎上すると会社員人生が＼(^o^)／ので、オンラインでの議論では手加減を…

6. 6Copyright © 2012 NTT DATA Corporation 品質シンポジウム（ＳＱｉＰ）投稿の種類  経験論文（論文）  ソフトウェア品質に関する新たな提案、既存の方法・技術の実践などを報告する論文。  採録論文についてはさらに専門家がレビューし、論文の品質を改善するためのコメントが送付される。  経験発表（パワーポイントスライド）  実践活用事例、ノウハウなどをまとめた発表。現在取り組んでいる活動の速報、問題提起などもＯＫ。  スライド形式のプレゼンテーションのみでの投稿が可能。

7. 7Copyright © 2012 NTT DATA Corporation 募集テーマ  要求やシステム開発などに関連した観点  要求工学、要件管理、システム開発と業務改善、ベンダとの協調、保守・運用、SLA、 SLM、ITILなど。  ソフトウェア開発技術の観点  アジャイル開発、派生開発・プロダクトライン、形式手法、モデル検査、PSP/TSP、設計品質、アーキテクチャ品質、コーディング規約など。  マネジメント技術の観点  オフショア開発、プロジェクトマネジメント、リスク管理、モチベーション・コミュニケーション、パートナーとの進め方、スキル・キャリア、人材育成、教育／トレーニング、小集団活動など。  品質管理・テスト技術の観点  テスト技術、レビュー、デバッグ、プロセス改善、CMMI/ISO15504、監査、QMS構築、構成管理、メトリクス、不具合管理、受け入れ検査、品質の定量的把握(予実管理・ EVM)など。

8. 8Copyright © 2012 NTT DATA Corporation 書くために準備するもの  ネタ  ソフトウェア品質に関して自慢したいこと！  ソフトウェア品質に関するアイデア・技術・実践・ノウハウ。  例：うちはレビューやテストを工夫してやっている。皆に自慢したい／意見を貰いたい／同じ取り組みをしている人と議論したい。  情熱  ソフトウェア品質に関して伝えたい気持ち！  目立ちたい、自慢したい、形にして残したい。  時間  ソフトウェア品質に関して体系化する時間！  アイデア・技術・実践・ノウハウをいい感じに仕上げる。

9. 9Copyright © 2012 NTT DATA Corporation 良い原稿を作る３つの要素 1. ネタが美味しい  多くの人が「美味しい！」と納得する王道食材。  少数派だけど「美味しい！」とファンが絶賛する変化球食材。 2. ネタが新鮮  メインフレームシステム新規構築のためのウォーターフォールモデルにおける品質管理について ⇒ 何年前の話やねん  ＳＡＰアドオン開発のためのアジャイル品質管理について ⇒ 新鮮！ 3. 産地表示  そのネタは、いつ、誰が、どこで作り始めて、どういう風に育てられ、今回発表するものは従来のものと何が違うのか。

10. 10Copyright © 2012 NTT DATA Corporation 例：コシヒカリＢＬ（Blast resistance Lines）  1944年、新潟県農業試験場の高橋浩之により「農林22号」と「農林1 号」との交配により誕生。戦時下のため栽培中断。  戦争終了後の1946年、仮谷桂と池隆肆が育種事業引き継ぎ。1947年～1952年、石墨慶一郎と岡田正憲が福井の実験所で育成。  1953年から、有望な種子系統である「越南17号」の適応性試験を20府県で開始。1955年、新潟・千葉県の奨励品種となる。  1956年、水稲農林100号「コシヒカリ」として命名登録。米の粘りが強く食味に優れる品種であるが、栽培上は倒伏しやすい、いもち病などに弱いなどの欠点を持つ。  コシヒカリBLは、いもち病に抵抗性を持つように改良された、コシヒカリを親とする品種群。 via Wikipedia http://ja.wikipedia.org/wiki/コシヒカリ http://ja.wikipedia.org/wiki/コシヒカリBL

12. 12Copyright © 2012 NTT DATA Corporation ＳＱｉＰシンポジウムアブストラクト作成のポイント  タイトル  キーワード  1. ねらい  今回紹介する方法で、解決しようとする問題あるいは研究・開発の目標・目的について記してください。  2. 実施概要  実施方法について工夫した点がわかるように概説してください。  1で述べられた問題点を改善できることが分かるように記してください。  3. 実施結果  2の実施によって得られた効果について（できるかぎり具体的に）概説してください。  4. 結論  問題解決の度合い、今後の展開への期待などを主張してください。

13. 13Copyright © 2012 NTT DATA Corporation 「タイトル」の書き方  嘘・大げさ・まぎらわしいは× ○ 軽量開発プロセスにおけるTracを用いたメトリクスの収集・蓄積・利用 × アジャイルプロセスにおける１００倍アジャイルなメトリクス環境  短すぎない・大雑把すぎない △ Tracを用いたメトリクスの収集・蓄積・利用 × メトリクスの収集・蓄積・利用  長すぎない × Wiki、SVN、IRCによるコミュニケーション非同期化による開発プロセスの効率化と、Tracを用いたメトリクスの収集と蓄積、カスタムクエリの条件検索による利用  何かいい感じの言葉を入れるとさらに◎ △ 効率化プロセスにおけるTracを用いたメトリクスの収集・蓄積・利用

14. 14Copyright © 2012 NTT DATA Corporation 「キーワード」の書き方  タイトルに入っていない関連用語を記述する。  軽量開発プロセスにおけるTracを用いたメトリクスの収集・蓄積・利用  計量開発プロセス、Trac、メトリクス ⇒ ×情報量が増えない  バグ密度、生産性、見積り ⇒ ○情報量が増えた！  何の分野の原稿なのか、代表的な用語を記述する。  爆速効率化、メトリクス活用、Trac超利用 ⇒ ×なんの話やねん  プロジェクト管理、品質管理、品質保証 ⇒ ○ああ、その分野の話ね

15. 15Copyright © 2012 NTT DATA Corporation 「1. ねらい」の書き方  何についての発表か。  なぜそれが問題・課題なのか。  この発表でねらうことはなにか。本稿では、開発要員20名未満の中小規模のエンタープライズシステム開発で用いられる軽量開発プロセスにおいて、Tracでプロジェクト管理を実施する場合のメトリクスの収集と利用事例について述べる。開発規模、工数、レビューやテストの量、発見したバグ数などのメトリクスを収集することで、システム開発における見積もり・進捗管理・品質管理などを系統的に実施できる。一方で、信頼性の高いメトリクスを収集し、有効に実務利用するためには計測・蓄積ツールとルールの準備、ルール遵守を担保する監視活動が必要であり、無視できない大きさのコストが必要となる。多くの中小規模開発ではプロジェクト管理に割ける要員や工数が限られているため、メトリクスの収集と利用に大きなコストを確保し難いという問題がある。本稿では、小さいコストでメトリクスを収集・蓄積・利用した事例として、2つの社内システムの新規開発および維持保守開発におけるTracを用いたメトリクスの収集と利用について述べる。プロジェクトの体制や背景、用いたツールと実施手順、収集したメトリクスの分析結果や利用事例紹介することで、同様の課題を抱えるプロジェクトの管理担当者に課題解決に向けた参考情報を提供することがねらいである。何についての発表かなぜそれが問題・課題なのかこの発表でねらうことはなにか

16. 16Copyright © 2012 NTT DATA Corporation 「2. 実施概要」の書き方  実際にやったことを Step by Step で書いていく。  実践した結果や評価検証などについては「3. 実施結果」で書く。  ここでは背景、準備作業、関係する文献やツールなどを書く。主に次の点に留意して開発プロセス、計測ツール、ルールを準備し、可能な限り軽量化した開発プロセスの中でも、小さいコストで現実的にメトリクスを収集・蓄積・利用できる環境を整備した。 Tracを開発プロセスの中心に置き、開発リーダ・作業担当者・レビュア・有識者間でTracのチケットを取り回しながら開発を進めるプロセス（チケット駆動開発[1]で説明されているものと同様のプロセス）を規定し、メトリクスがルール通りに計測・記入されていることを各種レビュー時に並行して監視し、必要に応じて是正した。収集するメトリクス（規模、工数、レビューやテストの量、各工程で発見したバグ数）を、全てTracのカスタムフィールドで収集し、Tracのチケットとしてデータベースに蓄積した。規模はオープンソースのStepCounter[2]、80行程度の自作バッチファイル、Microsoft Excelで計測した。ルールや手順書、議事録や技術情報はWiki、成果物はSubversion（SVN）、日々の雑談や詳細は IRCを利用し、ルールや計測・利用手順の共有、ルール逸脱の是正指示なども席を動かずに実施できる状態とした。蓄積しているメトリクスはTracのカスタムクエリ機能を用いて条件検索し、CSV出力した検索結果を Microsoft Excelに張り込むことでデータ集計できる状態とした。集計したメトリクスは各週の進捗会議、各工程完了時の品質報告で必ず参照し、進捗・品質保証に実際にやったことを Step by Step で背景、準備作業、関係する文献やツール引用した文献やツールは著者や出自を書きたい

17. 17Copyright © 2012 NTT DATA Corporation 「3. 実施結果」の書き方  実際にやったことを Step by Step で書いていく。  スペースの都合上数は限られるが、図表も入れると読み易い。  実践や評価検証の結果を定量的なデータを併せて書く。同様の開発プロセス、計測ツール、ルールを総規模40KS（ピーク時要員数4名）と240KS （20名）の 2つの社内システムの新規開発および維持保守開発で、のべ41ヶ月間運用し、工程毎の作業工数、レビュー工数（人時）に加え、次のメトリクスを収集した。 ED/ID：レビュー頁数（頁）、指摘件数（件） M/UT：追加変更規模（Step）、UT項目数（項目）またはUT規模（Step） IT： IT項目数（項目）またはIT規模（Step）、 ITバグ数（件）、すり抜けUTバグ数（件） ST: ST項目数（項目）またはST規模（Step）、 STバグ数（件）、すり抜けUTバグ数（件）、すり抜けITバグ数（件）図 1に実施した開発プロセスのイメージを示す。画面追加、バグ修正、改善要望反映など、ひとまとまりの開発内容を「案件」と呼び、案件単位で担当者へ作業をアサインした。案件毎に外部/内部設計（ED/ID）、製造/単体テスト（M/UT）、結合テスト（IT）の各工程を実施し、複数案件をまとめたリリース単位で総合テスト（ST）を実施した。案件毎にチケットを発行し、さらに工程毎に発行したチケットを開発リーダ・作業者・レビュア間で取り回して進捗と品質を管理した。STでは試験シナリオ毎 ITM/UTED/ID 案件1： A画面追加案件2： B画面改善要望反映開発要員I 案件3： B画面バグ修正案件4： C画面バグ修正開発要員II 案件5： C画面改善要望反映案件6：移行ツール開発開発III ST 案件7：次々バージョンリリース機能追加開発移行作業次バージョンサービス開始 ITM/UTED/ID ITM/UTED/ID ITM/UTED/ID ITM/UT ITM/UTED/ID ITM/UTED/ID 図 1. 開発プロセスのイメージ実際にやったことを Step by Step で図表も入れると読み易い結果を定量的なデータを併せて書く

18. 18Copyright © 2012 NTT DATA Corporation 「4. 結論」の書き方  書いたことのまとめや要点を再掲する。  今後の課題、考察についても記述する。  課題・他の実践・文献・研究との比較もあるとなおよい。 Tracを中心に置くことで、軽量開発プロセスにおいて現実的にメトリクスを収集・蓄積・利用できる環境を整備できた。開発実施中にもルール、手順、ツールを継続的に改善し、メトリクス計測や利用に要するコストを低減できた。一方、導出して参照したメトリクスは、生産性、レビュー密度、テスト密度、バグ密度など、プロジェクト管理に最低限必要なものに留まっている。（1）工数・規模メトリクスから見積もりモデルを作成するなど、収集したメトリクスの計画時における利用促進、（2）サイクロマチック数、テストカバレッジ、コードクローンなど、コードレビューやUT/ITレビューで観点としていたC0/C1網羅や、保守性低下防止を担保する品質系メトリクスの利用が今後の課題である。書いたことのまとめや要点の再掲今後の課題、考察

20. 20Copyright © 2012 NTT DATA Corporation 読み易い文章を作る５つのコツ 1. 正しいフォントを選ぶ  文章は明朝体／Times系（Times New Romanなど）で。  プレゼンテーションは Sans-serif系（Arial、Helveticaなど）で。 2. 段落の大きさを揃える  段落に含まれる文の量をおよそ揃えて記述量のバランスをとる。 3. 段落の最初の文で一番大事なことを書く  段落の最初の文を繋げて読むと、意味が通じるように。 4. ひとつの段落ではひとつのことだけを書く  一番大事なこと→詳しい説明・理由・事例→付加情報・段落のまとめ 5. 段落同士が繋がって自然に流れるように  段落の最後の文と、次の段落の最初の文が自然に繋がるように。

21. 21Copyright © 2012 NTT DATA Corporation 1. 正しいフォントを選ぶ  原稿本文は明朝体／Times系（Times New Roman など）  プレゼンテーションはゴシック／Sans-serif系（Arial など） – Robin Williams（著）、吉川典秀（訳）、ノンデザイナーズ・デザインブック Second Edition、毎日コミュニケーションズ、2004. ＴｉｍｅｓＮｅｗＲｏｍａｎ明朝体ゴシック体

SQiPシンポジウムアブストラクト作成のポイント

Du liest eine Vorschau.

Hier ansehen

SQiPシンポジウムアブストラクト作成のポイント

Weitere Verwandte Inhalte

Diashows für Sie (20)

Andere mochten auch (7)

Ähnlich wie SQiPシンポジウムアブストラクト作成のポイント (20)

Aktuellste (20)