******************************************************************************** セッションS4-a テーマ:「システム開発文書の品質を考えよう」 講師: 山本雅基 (名古屋大学)    小林直子 (アヴァシス株式会社)    森川聡久 (株式会社ヴィッツ) 日時:2015/08/28 13:00~14:20 参加人数:20名 ******************************************************************************** <議事録本文> システム開発文書の評価方法について、講師から説明を受けた後、4班に分かれて、文書を書く際に気をつけていることや、注意すべきことなどを上げ、それらの性質を分類した。 1. 文書品質モデルの紹介 概要:下記ページの「システム開発文書品質モデル」に関する説明があった.    http://asdoq.jp/research.html 役割:開発に必要な情報を記録して伝えること。 文章について読む事、書く事ができていないことに気づくことがある。 感想文⇔実用文 システム開発文書には読み手にわかるように、仕様を書く必要があり、読み手が文書の品質を決める。 読み手の開発文書の取り扱いの手順   認識→理解→行為      認識、理解 : 記述品質      行為 : 情報品質 システム開発文書モデルの3層構造  第1階層:品質特性  (1)完全性  (2)論理性  (3)理解容易性  (4)可読性  (5)規範適合性  第2階層:品質副特性   第1階層をさらに14種類に分類  第3階層:測定項目  測定項目については様々あるので、例えば注目する測定項目を設定し、それを実行した後、それができているかを評価する。    測定値  (機械による測定)    ・外形的な計測    ・不適切な助詞の使用法の検出。  (人手による測定)    ・チェックリストを用いた測定    ・質問紙を用いた測定    利用目的に応じて評価する。    単に○×で評価することなく、評価基準を透明化する。   2. ワーク発表 概要:前段で説明があった文書品質モデルを活用して、様々な気づきを得た. 4班に別れ、システム文書の例(紙媒体)が配られた。それに対する指摘、もしくは自分たちが文書を書くときに気をつけていることなどを出し合い、それを提示された項目に分類する。これを通して考えたこと、感じたことを発表する。 1班 ・仕様書を書くとき、読むときに注意して。 ・分類しにくかったもの     設計に矛盾がないかどうか。     簡潔でわかりやすく(図を描く)     同じ語尾をそろえる。 ・可読性、規範的に分類されたものが多かった。 ・texで書く。 ・同じ可読性でもさらに細分化して評価しないと、正しく評価できない。 2班 ・理解容易性と可読性が多く、この2点の重みが大きい。しかし、改善しやすい。改善することで、その上の完全性などについて評価。 ・そもそも文章にする必要があったのか。 3班 ・文章を書くときに気をつける。 ・代名詞を避ける。 ・主語の省略に注意する。 4班 (提示された例への指摘を中心に) ・目次がない。 ・よくわからない記述は避ける。 ・図の番号を書くべき。 ・変更履歴がない。