« 2017年5月 | トップページ | 2017年7月 »

2017年6月

2017/06/20

JAXAのRedmine利用事例の講演資料がWeb公開されました

昨年7月に開催された第65回 SEA関西プロセス分科会 & RxTStudy #15における、JAXAのRedmine利用事例の講演資料が公開されていたので、メモ。

【参考】
“CODA” チケット管理システム | JSS2@JAXA:「JAXAスパコン”JSS2″の運用を支えるチケット管理システム”CODA”」, 2016/7/30, イベント: 第65回 SEA関西プロセス分科会 & RxTStudy #15

JAXAの数値シミュレーションとスパコンの歴史 (2016年版) - YouTube

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想: プログラマの思索

JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文: プログラマの思索

JAXAのRedmineモデル~Redmineはレイヤ構造になっている: プログラマの思索

JAXAのRedmine運用に隠れている運用ルール: プログラマの思索

講演資料を読み直すと、昨年7月の講演会の熱い雰囲気が思い出されて懐かしい。
JAXAがなぜRedmineを導入しようとしたのか、その理由も詳しく書かれている。

個人的に興味を惹いた部分は、資料の後半にあるRedmineの管理画面の設定情報だ。

ロールは、レギュラー、文書係など7種類。
トラッカーは、全般、QA、会議開催など9種類。
チケットのステータスは、修正待、再現待、返却・抹消など13種類。
カスタムフィールドは、すごくたくさん。

文書カテゴリは、11個。
たぶん、DMSFプラグインを入れたためだろう。

IssueTemplateプラグインのチケットテンプレートは、5種類。
報告書や会議資料で使われているみたい。

プラグインは、DMSF、IssueTemplate、LocalAvatar、SidebarHideなど7個。
EnterCancelプラグインも入っている。

「プロジェクト分割の目安」も参考になる。
「Redmine活用の大きな要素」であり、「業務範囲の広がり時の分割判断」になる。
PJ分割の指針は下記らしい。

(引用開始)
a. セキュリティ等の属性で参加メンバーが異なる →親子プロジェクトの利用
b. 同一参加メンバー(ユーザ)のロール変更が必要な場合
c. 業務範囲に依存するフィールドの要・不要、更新頻度の多寡
d. Redmine保守は独立プロジェクト
e. プロジェクト毎に選択肢を設定できる、”強力な”標準フィールド「カテゴリ」の活用
(引用終了)

興味を惹くのは、セキュリティなどのユーザ属性でメンバーのロールが変わる場合に親子PJを使う点。
確かに、社外のベンダー開発者と社内メンバーでは、情報アクセス権限が異なるので、分けた方が良い場合はある。

また、「カテゴリ」機能を頻繁に有効活用している点も面白い。
カテゴリはPJ独自に設定できるので、PJの独自性を出したい検索キー項目があれば、カテゴリを使うといいかもしれない。

「フィールドの要・不要、更新頻度の多寡」は、CFのAND条件の運用ルールに相当するだろう。
この運用方法については下記でも書いた。

JAXAのRedmine運用事例の分析~「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索

最後に、「Redmineへの期待」の部分がすごく参考になる。

(引用開始)
1. 高い汎用性を持つチケット管理システム
2. 全体としては非常に満足
3. 活発な開発の継続とコミュニティや情報発信の充実
4. プラグインによる機能面・操作性の充実
5. ASP型エコシステムの確立によるOSSの普及・定着
(引用終了)

Redmineの利用が広まった理由には、コミッタによる定期的なVerUpと頻繁な改善、ユーザコミュニティが活発で書籍やWebの情報が多いことがあるだろう。
つまり、RedmineというOSSのエコシステムが自然に生まれて、成長のらせん構造になっている点があると思う。

コミュニティの一スタッフとしては、OSS活動を通じて、コミッタとユーザの交流と活発な議論によるコミュニティの場が重要であると肌身を持って感じた。
そういう活動を今後もやっていきたいと思う。

| | コメント (0)

2017/06/18

Redmine v3.3.3のER図をastahでリバースしてみた

Redmine v3.3.3のER図をastahでリバースしてみた。
自分のためにリンクを貼っておく。

【参考】
MAEDA, Goさんのツイート: "@flower_norn データベース設計のドキュメントは残念ながら見たことなくて、db/schema.rb でテーブルレイアウトが確認できるくらいです。 rails-erdというgemを使ってER図を作ってみました。 https://t.co/X7Ztl2AHos"

さやか/Sayakaさんのツイート: "@g_maeda Redmineのデータベース設計について記載されたドキュメントなどもしご存知であればご紹介いただきたいです。ブログやmastdonなどで紹介すると、意外と知りたい人がいるかもしれないです。私もDBを触ったことがあって、なぜインクリメントするのか不思議でした。"

RedmineのER図: プログラマの思索

【1】Redmineに蓄積されたチケット情報に対し、障害・課題・進捗・工数などの情報をある特定目的で集計したい場合に、ER図やDB設計書があると便利だ。
直接SQLを発行して、データを抽出した方が早いから。

そういう意図でRedmineのER図を見ると、どのテーブルもサロゲートキーなので、SQLは書きやすい気がする。

【2】なお、渡辺さんの記事では、Railsのようなサロゲートキーが強制されたデータモデリングに関する意見があり、参考になる。

「強制されたサロゲートキー」の事例を眺める: 設計者の発言

【3】astahのDBリバースプラグインはすごく優秀。
稼働中のDBに対し、JDBCがサポートされていれば、ほとんどすべてのスキーマ構造をリバースしてくれる。

DB リバースプラグイン | Astah

また、DB定義書もExcel出力してくれるので便利。
「Excel設計書を直す→DDL作成→DDLを環境へ反映」流れではなく、「DDLを作成→DDLを環境へ反映→astahでDBリバース→Excel設計書を出力」の流れの方がスムーズと思う。
Officeファイルの保守ほど面倒な作業はないから。

一方、ExcelのDB定義書からastahのER図をリバースするプラグインもあるので、astahは正直手放せない。

Excel-ERモデルインポートプラグイン | Astah

[pro] エンティティ定義書エクスポート

| | コメント (0)

2017/06/16

Salesforceのデータモデリング手法の記事のリンク

@hatsanhatさんの記事「データモデリングしてますか?」がとても参考になるのでメモ。
詳しくは下記の記事を参照。

【参考1】
データモデリングしてますか? - TECH BLOG | 株式会社テラスカイ

参考になった箇所は下記の通り。
サロゲートキーだけの開発環境の場合、「複合キーの制約をNotNull制約と更新不可制約で実現する」点が参考になる。

(引用開始)
スキーマビルダーで描画すればそのまま実装も出来るところは大変便利ですが、データモデル構造だけをシンプルに見たいという用途には向きません。
そこで筆者はオープンソースのモデリングツール「X-TEA(エクスティ) Modeler」を使用しています。
モデリングツールは何種類か試しましたが、1:Nの関係を親子関係と参照関係で明示的に表現出来る事と、項目に「更新不可属性」を設定出来る(何故必要かは後述)ためこのツールを重宝しています(作者に感謝)。
(中略)

顧客・顧客担当者・商談だけを関係付けたデータモデルです。
「顧客」と「顧客担当者」の間は鳥の足のような特徴的な線で結ばれています。
これが親子関係を表します。

「顧客担当者」と「商談」の間は先が点々になっています。
これは同じ1:NでもN側にNullを許す参照関係を表しています。

この2つの書き分けが出来るツールは珍しいのでSalesforceに向いています。
(引用終了)

(引用開始)
本当に複雑なデータモデルの時に主キーも正確に表したい時は、外部キー(foreign key)を使います。
複合主キーと外部キーの違いはNotNull制約と更新不可制約だけです。

・主キーはSalesfordeIdの単独主キーとする
・複合主キーとしたい他の項目はNotNULL制約+更新不可制約を付ける
(このためにX-TEA Modelerの「更新不可属性」が必要になります)
(引用終了)

(引用開始)
顧客オブジェクトの先頭の項目「011-id」は顧客オブジェクト(011)のSalesforceIdを示しています。
SalesforceIdとはオブジェクトの各レコードに一意に付けられる番号です。
この値を見れば、会社の中でレコードを1つに特定出来ます。
一般に言う「オブジェクトキー」とほぼ同じです。
Salesforceはこの値をURLに指定するとレコードを検索出来るという奇跡のようなURI設計(笑)になっています。
(引用終了)

【参考2】
あわせて、渡辺さんのBlogとさかばさんのBlogも参考になるのでメモ。
特に、さかばさんの指摘「RDBだから複合キーを使わずに実装できてしまう。モデリングの問題(注:実装と対比して、設計の問題という意味と推測)ではなく実装の問題です」も参考になる。

単独主キーでもDB設計は楽にならない: 設計者の発言

「単独主キー専用環境」と賢くつきあうために: 設計者の発言

複合主キーの扱い方: ソフトウェアさかば

(引用開始)
RDBなのに複合主キーを使わないのではなく、RDBだからサロゲートキーを作りやすいので、複合キーを使わない開発が簡単にできてしまうのだと思います。

つまり、単独主キーで開発を安易に行うことが問題です。

本来、複合主キーで表現されるデータをどう扱うかは、モデリングの問題ではなく実装の問題です。

複合主キーを使わないのは実装の都合なので、そこにある危険性を周知することが重要だと思います。
(引用終了)

| | コメント (0)

2017/06/15

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク

astahの事例を探していた時に、設計書とモデル、プロセスをつなぐ為のアイデアが書かれた資料を見つけたのでメモ。
以下はラフなメモ書き。
間違っていたら後で直す。

【参考】
モデルへの参照を含む多様な設計情報の継続的統合ドキュメント化に向けて

【1】以前、Redmine大阪で宿口さんの講演を聞いた時、機能安全規格を満たすプロセスをRedmineで実現する話があった。
その実装方法を聞くと、Wordの要件定義書ドキュメントの目次の各タイトルに、チケット番号のリンクが貼られていて、そのリンクからRedmineチケットとWordドキュメントの整合性を取るような仕組みを実装されている、とのことだった。

第16回Redmine大阪の感想 #RedmineOsaka: プログラマの思索

その時は、なぜそんなやり方が必要なのだろうか?と不思議に思った。
確かに、WordドキュメントにRedmineのチケット構造が同期されるので、見通しは良くなるが、それはRedmineのプラグインのような一機能で実現した方が良いのではないか?と思ったからだ。

WordやExcelとRedmineを連携しようとすると、結局、VBAマクロを駆使することになり、VBAを扱うのが苦痛だから(笑)

一方、上記の資料を読むと、Wordの要件定義書やアーキテクチャ設計書でモデルや作業構造をまとめるのががなぜ必要なのか、その理由が書かれている気がした。

【2】Word文書で組込みソフトウェアのモデルの絵や説明文をまとめたとする。
しかし、モデルは改変されるので、Word文書に書いた内容やモデルの絵はどんどん古くなる。
改変のたびに、逐一、モデリングツールで描いた絵をコピペしなくてはならない。

一方、要件管理ツールにあるソフトウェアの要件もどんどん変わる。
要件、モデル、そしてそれらの正しさを保証するプロセスも影響を受けて、要件の変更のたびに、派生的に編集作業が発生してしまう。
ドキュメントの保守作業ほど、無駄なコストの発生源であるものはないだろう。

つまり、要件とモデル、設計ドキュメントのトレーサビリティと変更の同期が課題になってくる。
また、標準プロセスで必要とされる成果物やドキュメントが揃っているか、という成果物の保証も関わってくる。

これらの課題はどうやって解決すべきなのか?

【3】上記の資料のストーリーは以下のようなイメージ。

①astah製品でUMLやSysMLなどのモデルを描く

→astahのOfficeプラグインによって、astahで描かれたモデルは、ExcelやWordに埋め込まれる。
 Officeプラグインのお陰で、astah上のモデルの変更は、ExcelやWordに同期される。

Office連携 プラグイン | Astah

②astahのGSN製品で事前に、標準プロセスを描いておき、必要なドキュメントを洗い出しておく

→astahのGSN製品から、要件定義書や設計ドキュメントの雛形を出力する
 標準プロセスに必要なドキュメントは、それぞれのWordやExeclにマッピングされ、astahのGSN製品のD-caseに対応付けられている。

→WordやExcelのドキュメントに、ソフトウェアの要件や仕様を記述していく。
 ドキュメントの中のモデルは、astahのUMLやSysMLに連動されている。

すなわち、astahのGSN製品で機能安全規格が保証された標準プロセスを構築し、その標準プロセスに対応付けられたOfficeドキュメントは、astahGSNで同期されている。
さらに、Officeドキュメントに貼られたモデルの絵は、astahファイルから参照されており、astahのモデルが変更されたら自動的に同期される仕掛けになる。

以前、astahのOffice連携プラグインを使ってみた時、このプラグインのメリットがあまり感じられなかった。
しかし、上記のような使い方をするならば、Office連携プラグインはとても重要な一機能になる。

Office連携 プラグイン | Astah

Astahプラグインの資料のリンク: プログラマの思索

【4】理論的には、上記のようなやり方で、Officeファイルの設計書・UMLやSysMLやER図やDFDなどのモデル・機能安全規格を満たす標準プロセスの3つは、全てastah製品で連携・同期・統一されることになる。

平鍋さんは、たぶんそのようなイメージでastah製品シリーズを作られたのではないか。
そう考えると、非常に上手く考えられているなあ、と感じる。

但し、上記のやり方はあくまでも理想論であり、本当にうまくいくのかは分からない。
実際のソフトウェア開発の現場における要件定義、設計の作業はもっと泥臭いし、労働集約的な作業ばかりだからだ。

たとえば、プログラム開発はGitという非常に強力な構成管理ツールがあるので、大人数の共同開発がやりやすい。
そして、Jenkinsのような強力なビルド管理ツール、Redmineのような強力なチケット管理ツールを組合せた作業環境が既に一般的だ。

一方、要件定義や設計では、astahのモデルやOffice文書は、Gitのような構成管理を行う環境があまり整っていないために、差分やマージ作業、プルリクエストのような共同作業がやりにくい。
また、モデリング作業で発生するQAや課題が発生して、それを解決して、その内容をモデルに反映していく、という一連の流れとチケット管理が、まだ上手く連動できていない。

個人的には、astahのモデル自身も、SubversionだけでなくGitで構成管理できるようにするのが1つの課題ではないか、と思う。

Subversionプラグイン | Astah

astahの品質スイートプラグインとSVNプラグインが凄い: プログラマの思索

TortoiseSVNでastahファイルのリビジョン間の差分を表示する方法: プログラマの思索

また、astahのモデルに要望や課題、仕様追加を反映していく作業と、astahのモデルの変更箇所をRedmineチケットを経由してリンクさせるような仕組みも必要ではないか、と思う。

Enterprise Architectでは、RedmineやTestLinkと連携するプラグインがあるので、astahでも実現してもいいはずだ。

Enterprise ArchitectとRedmineを連携するアドオン: プログラマの思索

TestLinkとEnterprise Architectを連携する: プログラマの思索

【5】astahには、たくさんの可能性があると思っている。
astahを使ったモデル、そのモデルを保証するプロセスの連携方法は、もっといろんなアイデアがあるはずだし、色んな実装方法があるはずだ。

近々、astahの勉強会を開くので、色々議論してみたい。

astah関西 第1回勉強会 - connpass

【追記】
似たようなことは既に他の人も考えている。

Astah*GSNより、ASCEのほうが、ビジネス的には、大きく出来る・・・ - ウィリアムのいたずらの開発日記

Astah GSNが、UML、SysMLと連携してほしい人! - いっぱい!! - ウィリアムのいたずらの開発日記

ウィリアムのいたずらの開発日記 D-caseで検索

| | コメント (0)

2017/06/11

【告知】astah関西 第1回勉強会を7/14金に開催します #astahkansai

astah関西 第1回勉強会を7/14金に開催します。

【参加申込み】
astah関西 第1回勉強会 - connpass

astah*Professionalファーストインプレッション: プログラマの思索

Enterprise Architectの使い方のリンクとメモ: プログラマの思索

astahによるモデリングのメモ: プログラマの思索

(引用開始)
関西圏でモデリングツールastahを使ったモデリング技法と実践事例に関する勉強会を開催します。

astahを使っている人、モデリング大好きな人が集まって、より良いモデリング技法や実践事例を共有する場として設けます。

モデリングの対象は、astah製品を使った設計技法が中心なので、UMLに限らず、ER図やDFDなどのデータモデリング、SysMLなどの組込ソフトウェア設計なども含む予定です。

興味のある方は、ふるってご参加ください。

<テーマ>
キックオフを兼ねた第1回勉強会を開催します。

チェンジビジョン(株)の方にも来阪して頂いて、astah製品の紹介と実際のモデリング技法について講演して頂きます。

次回の参加希望者が多ければ、勉強会スタッフを募集して継続します。
(引用終了)

【開催の発端】
僕自身は、Judeの頃から使い始めて、astah Professionalを2009年から使い続けています。
主な使い道は、UMLのお勉強が発端で、その後は、システム提案や要件定義の時のラフスケッチ、開発プロセスの運用ルール策定やプロセス分析です。

過去に、RationalRoseやEnterprise Architectを開発案件で使用した経験はありますが、正直使いづらかった。
2000年代中頃は、UMLがブームで、設計フェーズをUMLのダイヤグラムで代用する思想が多かったけれど、たくさんの修正が発生したら、ダイヤグラムのマージが面倒で、複数人でダイヤグラムを共有して作業するのも難しい。
結局、astahでも、個人で使用する場面が多いです。

astah Professionalの良い所は、頭の中にあるモヤモヤした内容をUMLの各種ダイアグラムでラフスケッチを即座に描ける点。
1つの問題や事象を、複数の観点の動的・静的ダイヤグラムで描いて、整合性や詳細を詰めていくことが自然にできる点が良かったと思います。
絵で描くと、このI/Fの仕様が甘い、とか、このプロセスは意外に複雑だな、とか、色々気づきが得られやすい。

また、Redmineの運用ルールを説明する時、運用フローをアクティビティ図やステートマシン図で描くと、他人に説明しやすい。
誰とキャッチボールするのか、何がトリガーになるのか、が明確になる点が良いです。

さらに、過去にアジャイル開発やRedmineコミュニティで数多くの発表を行った時、astahで事前に書き溜めたラフスケッチがとても役立ちました。
そういう経験をしてきて、astahによるモデリング技法を周囲の人達と共有したいという気持ちが以前からあって、周囲の後押しを元に、ようやく実現する運びになりました。

僕の周囲ではそもそも、astahを使っている人がいないので、この勉強会が継続できるか分かりません。
関西で、astahを使っている人、astahに興味がある人、UMLやDOAや組込ソフトウェアのモデリング技法に興味がある人が集まるといいな、と思います。


| | コメント (0)

2017/06/01

TestLinkにExcelのテスト項目書をインポートする方法

TestLinkにExcelのテスト項目書をインポートする方法の記事があったのでメモ。

【参考】
【TestLinkでナレッジ蓄積】Excelからテスト項目書をインポートする方法 | Ques

MrBricodage/TestLink--ExcelMacros: Excel files containing Macros that handle XML files compatibles with TestLink

TestLinkのインポート用ExcelマクロImportExcelMacroのリンク: プログラマの思索

TestLink

(引用開始)
TestLinkはExcelから直接インポートできない

TestLinkのインストール作業手順は、インストール方法の記事や書き込みが多いため、
ここでは省略させて頂きます。

TestLinkを使う上で苦労した点はテスト項目書からのインポート作業になります。

TestLinkへインポートするにはXML形式に変換する必要があります。
弊社のテスト項目書(ナレッジ)の多くはExcelで作成されており、
Excelの内容は直接TestLinkへインポートすることができません。
TestLinkへインポートするには、一度、Excel形式からXML形式に変換する必要があります。
TestLink上にて、テストケースを手入力で入力することは可能ですが、
数あるテスト項目書を手入力で行うと時間がかかるため、
短時間で行うには補助ツールが必要になります。

テスト項目書のインポート/エクスポートを補助する便利ツール

ExcelからXMLに変換し、XMLからTestLinkへインポートするには、
Excel→XML変換ツールが必要になります。
また、TestLink上のテスト項目書を編集する場合、
TestLink上よりもExcel上で編集できた方が楽です。
TestLinkにはエクスポート機能があり、実行するとXML形式で保存できます。
エクスポートデータをExcelで編集するにはXML→Excel変換ツールが必要になります。

そこで、下記の両方を行うことができる補助ツールを探してみました。

Excel→XML変換
XML→Excel変換

昔は「TestLinkCnvMacro」という補助ツールがありましたが、今はありません。
今回は「TestLinkCnvMacro」の代わりに、
海外のツールですが、「02-ImportTestCasesIntoTestLink.xls」を使います。
(引用終了)

02-ImportTestCasesIntoTestLink.xlsの使い方は、上記の記事にある。

TestLink上からXML出力
→encoding=”UTF-8″を”Shift-jis”に変更して保存
→文字コードを「Shift-jis」にして保存
→02-ImportTestCasesIntoTestLink.xlsへインポート

02-ImportTestCasesIntoTestLink.xlsからXML出力
→encoding=”ISO-8859-1″を”UTF-8″に変更して保存
→文字コードを「UTF-8」にして保存
→TestLink上でXMLインポート

| | コメント (0)

« 2017年5月 | トップページ | 2017年7月 »