« 2017年11月 | トップページ

2017年12月

2017/12/16

Friends of astah*になりました

このたび、Friends of astah*になりました。
とても嬉しいです。

【参考】
Friends of astah*

振り返ると、自分は10年以上前からastahを使っていたんですね。

【再考】GanttProjectとFreeMindとJude: プログラマの思索

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

本格的にastahを使い始めたのは、Redmineによるチケット駆動開発の開発プロセスをUMLで分析してみよう、と思い立って色々描いていた時。
その頃は、アクティビティ図とステートマシン図、配置図がメインだった。

我流のプロセス分析をしながら、色んな気づきがあった。
たとえば、プロセスの例外処理はJavaやVBスクリプトの例外処理に似ているなあ、と思った。
また、プロセスが複雑な理由は組織の構造や権限をそのまま反映しているからだ、と気づいた。
つまり、コンウェイの法則そのままじゃないか、とか。

また、要件定義でシステム構成図、機能構成図、業務フロー、データモデルを書きながら、それぞれのダイアグラムにトレーサビリティという関連があること、粒度を保ちながらレイヤ化という思想で詳細化していく、という発想も身を持って体験できた。

こういう体験は、モデリングツールがあったからこそ、できたのだろうと思う。
なぜなら、Excelやパワポで絵を描くと、ちょっとしたレイアウト変更だけで労力を費やして、本来明示したい設計思想を忘れてしまいがちだから。
また、ダイアグラムを試行錯誤して描くことで、複数の観点でモデルを分析することが自然に身に付くし、各ダイヤグラムのトレーサビリティや粒度を気にするようになるから。

一般に、日本企業では、設計書は日本語という自然語で記述するのが普通。
しかし、日本語では守護が明示されていない、構造が明確化されていない、などの弱点があるので、いくら詳しく書いても必ず漏れる。
巻物みたいなExcel設計書をたくさん書いても、その後のマイグレーション案件では役立たない。

むしろ、A3の1枚用紙に描いたシステム全体概要の方が役立つ時もあったりする。
そんな経験もあって、自分の理解も深めるために、astahを重宝している。

しかし、astahも10年以上使っていると、こういう機能も欲しい、という思いも強くなってくる。
そんな思いも書いてみた。

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

また、XPJUG関西メンバーの後押しもあり、astah関西というコミュニティも立ち上げてみた。
来年度も、Redmineコミュニティと合わせて、色々活動してみたいと思う。

astah関西 第1回勉強会 - connpass

個人的には、ソフトウェア工学の実験ツールであるRedmineと同様に、astahも、ツールがモデリング技術の可能性を高める部分が沢山あると思っている。

ツールがプロセスを改善していく。
ツールが開発プロセスに新たな利用シーン、想定していなかった副次効果をもたらす。
ツールがモデリング技術の新たな可能性を開拓していく。

そんなアイデアを色々考えてみたいと思っている。

| | コメント (0)

RedmineをMSProcjetっぽく使う事例

第2回Lychee Redmineユーザ会で、MSProjectのようなガントチャート運用のようにRedmineを使っている事例の資料があったのでメモ。

Redmineが日本企業に受入れやすい理由の一つは、従来のWF型開発でガチガチのガントチャート管理をチケット管理で実現しやすいためだろう。
なぜなら、親子チケットで階層化すれば、WBSをそのまま実現できるからだ。

しかし、Redmine標準のガントチャートでは、予実管理までの機能はなく、MSProjectに付随しているベースライン管理、リソース管理、PERT図のような機能まではないから、MSProjectをバリバリ使っているプロジェクトリーダーの観点では不満があるだろう。

上記の資料では、Lycheeガントチャートという有償プラグインを導入することで、MSProjectの大半の機能をRedmine上でも同様に利用することで運用しようとしている。

興味深い点は3つある。

一つ目は、 開発プロセス用トラッカーは、測定項目を共通化し4種類に集約していること。
明示されていないけれど、分析、設計、実装、検査の項目と思われる。
一般にプロセスをトラッカーにするのはあまり推奨されていないけれど、小規模チームならば問題ないと思う。
個別PJだけのチケット管理の運用ルールに特化しているから。
つまり、チームの運用に合わせるようにRedmineを当てはめて、タスク管理をスムーズに実行することを目的としているから。

2つ目は、チケットの基本項目や測定項目を全て必須入力とし、工数、検査項目数、NG数などの入力漏れを無くし、 承認待ちステータスを入れて責任者が最終確認して完了する運用を徹底したこと。
たぶん、完了したタスクに対し、設計プロセスで仕様漏れが発生していないか、その使用漏れが後工程まで引きずっているか、というメトリクスも収集し集計したい意図があるのだろう。
特に、組込み製品開発では、後工程の手戻りがあるとコスト増加に大きく響いてしまうから。

また、承認ステータスを入れることで、「いつの間にかタスクが完了していた」という事態をなくせる。
おそらく、必ずプロジェクトリーダーの承認を経てタスクをクローズする運用を徹底することで、当初の計画通りに成果物が作られたのか、という検査をきちんと記録に残すことができ、システム監査で説明できる資料にしたいためだろう。

3つ目は、 ベースライン保存機能で保存したスケジュールのスナップショットと、現在のスケジュールを同時表示 し、スケジュール変更前後を比較可能とし、打ち合わせ時にチケット棚卸しを実施していること。
MSProjectでは、基準計画という機能があり、たとえば顧客都合の仕様追加でリスケが発生したら、リスケ前とリスケ後のスケジュールを別々の保持する機能がある。
この機能を使えば、リスケ後に、顧客に、これだけの工数が追加したので別請求で代金を支払って下さい、と請求できる根拠を示せる。
また、開発者にも、リスケ後にこれだけ工数が追加で発生したと説明できるし、どれだけの実績工数の差異が発生したのか、を追跡できるようになる。

一般に、受託開発案件は一括請負契約が多いので、こういうスコープ変更に伴う追加代金の請求の根拠となる資料はとても重要だから。

上記の資料ではオフショア開発にRedmineを展開していたようなので、資料に書かれていない内容でたくさんの苦労があったのではないか、と勝手に想像する。

こういう資料を読んでいると、日本のSIではPJ管理にすごく苦労しているんだろうな、と感じる。
資料の背後に隠されている泥臭い作業をイメージできてしまうから。

できれば、開発チームのメンバーのフィードバック、開発チームや開発プロセスの効果も聞きたかかったな。

Redmineがそういう作業を全て解決できるか否かは分からない。
でも、そういうPJ管理の問題点が見える化されることで、根本原因は何か、真の解決策は何か、を考えるきっかけになる気はする。
そういう問題点、根本原因を明確にすることで、解決策がメンバーと共有されて、解決されていくと思うから。

| | コメント (0)

Redmineの普及促進にはRedmine警察やRedmineマイスターという役割の人達が必要

打ち捨てられていたRedmineが復活するまでの軌跡 - Qiitaという記事で、Redmine警察とRedmineマイスターが共同でチケット運用する方法が書かれていたのでメモ。
非常に分かりやすい。
感想をラフなメモ書き。

【参考】
打ち捨てられていたRedmineが復活するまでの軌跡 - Qiita

【1】上記の記事で気になったポイントはいくつかある。

一つ目は、チャットツールとRedmineの使い分けや連携方法に関するノウハウを持つべきこと。
二つ目は、「Redmine警察」「Redmineマイスター」という役割の人達が、Redmine運用の浸透に欠かせない、という点に早く気づくこと。

【2】チャットツールに依存しすぎるとRedmineが使われなくなるし、技術や仕様のノウハウがチャットに埋もれてしまい、ナレッジとして蓄積されない問題は、東京Redmine勉強会でも話題に上がっていた。
しかし、現在の開発現場では、Slackのようなチャットツールは普通だし、必須だろう。
チャットツールを無くすことは不可能。

上記の記事でも、下記の問題点があげられていた。

(引用開始)
チャットに情報が集約されることの問題点
この状況の一番の問題は、重要なコミュニケーションが全てチャットのタイムライン内に散逸してしまうことです。これにはいくつものデメリットがあります。

異なるトピックがランダムに折り混ざり、問題の切り分けがしにくい
古いトピックの状況や結論を忘れる
メンバー外への情報共有がはかどらない
(引用終了)

そこで、いくつかの対策を講じている。
チャットツールとRedmineの使い分けのルール策定はもちろん、チャットツールとRedmineを連携するプラグインを導入して、Redmine→チャットという情報の流れを作っている。
Redmineにノウハウを集約するのは大事だが、チャット文化を否定するのではなく、情報が一元化されたRedmineからチャットへ情報を流してチャットも有効活用する、という方針は、この問題の一つの解決策だろう。

sciyoshi/redmine-slack: Slack notification plugin for Redmine

hokkey/redmine_chatwork: A Redmine plugin to notify updates to ChatWork rooms

【3】「Redmine警察」「Redmineマイスター」を導入している、という話は、Redmineの普及促進には、社内にRedmineエバンジェリストと言うべき役割の人達が必要である、という事実を示唆していると思う。

(引用開始)
僕は今LIGでフロントエンドエンジニアとして働いていますが、同時に社内随一のRedmine警察であることも自負しています。

LIGではプロジェクト管理ツールとしてRedmineを導入していますが、僕の入社当初はほとんど打ち捨てられたも同然の状態で放置されかけていました。そのような状況をどうやって改善し、社内にRedmineの運用を浸透させていったかについて、経緯や施策を説明します。
(引用終了)

(引用開始)
Redmine警察としてみんなの運用の相談にのる
「この案件のタスクはどんな粒度で起票すれば良いか」「バージョンと子チケットの棲み分けはどうするべきか」といった微妙な問題があれば、立ち話で相談に乗るようにしています。また、ITSの運用に慣れている同僚をRedmineマイスターに認定し、Redmine警察と共同でチケット運用の普及に努めています。
(引用終了)

たとえば、以前、@sakaba37さんが、CMMI運用の頃にも、CMMIの普及とレベル向上には、プロセスチャンピオンという名の役割の人が必要、と話されていた。

[#xpfes12] 先駆者の集まりから、プロセス・チャンピオンの集まりに - XP祭り関西2012 -: ソフトウェアさかば

また、以前の東京Redmine勉強会の講演でも、社内にRedmineエバンジェリストがいたから、すぐにAWSにRedmineを環境構築してくれて、ベストプラクティスも持っていたから、すぐに運用を開始できた、という話もあった。

RedmineがIoT企業に異常にマッチしてしまった話 - 僕のYak Shavingは終わらない

(引用開始)
ただここで大事なことを言っておくと、やはり導入にはRedmineエバンジェリストみたいな人が必要だと思います。 正直いなかったらやってなかったですね。
(引用終了)

その話と同様に、Redmine警察としてRedmineの運用を見張る(笑)、Redmineマイスターとしてチーム内の質問に対応する、という役割の人達がたくさん必要なわけだ。

そう言えば、BTSを使っていなかった頃、ある案件の結合テストフェーズで、開発チームのリーダーは特に何も担当せずに自由に開発者の相談やフォローに乗る役割を担っていた時があった。
そんなリーダーは、開発メンバーから、ポリス(警察の人)みたい、と言われていたのを思い出した。

Redmine警察も似たような役割かな。

【4】「Redmineが社内になかなか普及しない」と嘆く現場では、たぶん、Redmineエバンジェリスト、Redmine警察、Redmineマイスターのような人達がいないか、そういう役割を担う人が少なすぎるのだろう。

僕は、各部署に品質保証担当の人がいるならば、彼にRedmine警察やRedmineマイスターを名乗る役割を与えて、普及促進に務める、という組織的対応も必要だろうと思う。

スタッフ部門だけがRedmineを促進しようとしても難しいのではないか。
また、Redmineエバンジェリストとは言えなくても、Redmine警察やRedmineマイスターを社内に育成することは可能ではないだろうか?

結局、人を通じてしか、プロセスは変えられないから。


| | コメント (0)

2017/12/13

Redmineにおけるトレーサビリティの課題は何か?

Redmineにおけるトレーサビリティの現状と課題について考えたことをメモ。
ロジカルでないラフなメモ書き。

【参考】
現場の声からプロセス改善を深掘りする(3):要求から成果物へのトレーサビリティ (1/2) - MONOist(モノイスト)

保守性・拡張性に優れたシステムを作る(11):キミの設計に「トレーサビリティ」はあるか (2/2) - ITmedia エンタープライズ

アジャイルプロジェクトにおけるトレーサビリティ・マトリックス

チケット駆動開発がもたらした新しい観点part2~トレーサビリティの拡張: プログラマの思索

チケット駆動開発におけるトレーサビリティのチートシート: プログラマの思索

Redmineをもっと強化できるポイントpart1~上流工程のトレーサビリティ強化: プログラマの思索

アジャイル開発と要件管理: プログラマの思索

日本でモデリングツールが使われない背景: プログラマの思索

【1】ソフトウェア開発におけるトレーサビリティがいかに重要であるか、という点は、システム開発をやっている人なら痛感しているはず。

たとえば、チケット駆動開発の最大のメリットはトレーサビリティだ、という意見がRedmineによるタスクマネジメント実践技法 - プログラマーな日々で紹介されている。
派生開発や、受託開発で本番リリース直後の混乱を経験している人ならば、納得するのではないか?

(引用開始)
チケット駆動開発の効用は、何といってもトレーサビリティ(追跡可能性)の確保だろう。

ソースの変更と変更理由の結束の保証。
一度でも開発を経験した人なら、これがどれだけ大きな価値をもつか説明は不要だろう。
顧客の「いつどんな理由でこの変更をしたのですか?」という問い合わせにマネージャは即答でき、開発者はコメントが書かれていることを祈りながら過去のソースコードを追う必要がなくなるわけだから。

問題は導入コストだろう。
この書籍で実現されていることには憧憬すら覚えたが、アプリケーションは無償でも学習コストは非常に高いと感じた。

段階的導入は可能だろうか?
まずはタスクのワークフローとして使ってみるとか。導入コストは非常に大きな問題だ。
どうにかしてメンバーが前向きに取り組めるようにしないと、やらされていると感じているうちは導入は遅々として進まないだろう。

結論。開発者はもちろん、マネージャにこそ読んでほしい本だ。
(引用終了)

しかし、チケット駆動でトレーサビリティを実現できる基盤がある、と言っても、それを効果的に運用できるか否かは、その組織の成熟度に大きく依存している。

【2】トレーサビリティの利用シーンを洗い出してみる。
トレーサビリティが保証された開発プロセスでは、下記の利用シーンで大いに役立つはず。

【2-1】コードレビュー

Redmineならば、チケットにソース修正履歴があるので、レビューで修正箇所を追跡できる。
機能単位、障害単位にコードレビューしやすい。

【2-2】バグ修正や仕様変更時に、過去の要件を探る

修正対象のソースにある複雑に混み入ったIF文を勝手に修正してよいか?
本番リリース直後の混乱時に、沢山の人のパッチが当たって、何とか収束したパッチなのに、勝手に手を入れてよいのか?
意味不明なパッチにも実は過去の障害修正を引き継いでいる。
触らぬ神に祟りなし。
Redmineならば、仕様変更で修正するソースの修正履歴にチケットNoがあるので、過去の要件と仕様確定の理由を探って、修正要否を判断できる。

【2-3】顧客問合せで、現状の機能や要件の経緯を調査する

この機能はなぜ実装されたのか? という顧客問合せ。
Redmineならば、全文検索して、チケットから要件と要件確定の経緯を探れる。

【2-4】リリース履歴として公開する

Redmineならば、リリースバージョン→チケット→ソースへドリルダウンして、成果物のソースまで追跡できる。
顧客に説明しやすくなる。
リリース後の保守作業で、開発メンバーもシステムの変更履歴を探しやすくなる。

【2-5】仕様変更のインパクト分析

仕様変更があった時、関係する機能はどれくらいの影響を受けるのか?
対象ソースを直したら、修正が発生するソースの範囲、デグレしていないことを確認すべき回帰テストの対象機能の範囲はどれくらいか?
つまり、インパクト分析で使いたい。

【2-6】トレーサビリティマトリクスの元ネタ

原理的には、縦軸が要求、横軸が機能のトレーサビリティマトリクスを出力できる。
トレーサビリティマトリクスがあれば、派生開発でソース修正を行う時、どれくらいの修正箇所があるのか、影響を受けるソースはどれだけか、回帰テストすべき対象範囲はどれくらいか、を把握できる。
たとえば、XDDPのトレーサビリティマトリクスも、原理的にはRedmineから出力できるはず。

古いプラグインだが、下記のイメージ。

Traceability matrix - Plugins - Redmine

また、トレーサビリティマトリクスを使えば、テスト工程における要件カバレッジやテストカバレッジにも利用できる。
テスト工程の中盤で、どの範囲の要件はテストで品質が保証されたか、テストで網羅できた機能や成果物はどれだけの範囲なのか、を把握できる。
しかも、時系列でトレーサビリティマトリクスや要件カバレッジ、コードカバレッジを出力できれば、品質保証の範囲の時系列の変化を見ることができて、有意義なはず。

【2-7】成果物そのものから、成果物の変更履歴を除去できる

昔は、Excel設計書の修正のたびに変更履歴を追記したり、吹き出しを書いたりしていたが、そういう変更履歴はGitのような構成管理ツールがあれば不要。
変更履歴のようなメタ情報は、構成管理ツールで管理すべき対象だから。
よって、設計書やソースから変更履歴のようなガラクタのコメントは除去されて、最新版で状態維持されているので、成果物がシンプルになる。

SCMコミットログはファイルのメタ情報: プログラマの思索

【3】しかし、トレーサビリティの実現はやはり難しいと思う。
以下、トレーサビリティの課題をあげてみる。

【3-1】トレーサビリティの保証は、手動の運用ルールだけで十分か?

チケット駆動開発の運用ルール「No ticket, No Commit」が徹底されているならば、チケット経由で「要件→チケット→成果物(ソース・設計書)」のトレーサビリティが実現される。
その運用を支える基盤は、構成管理ツール連携というRedmineの一機能で実現できている。

しかし、スキルの低いメンバーでは関連付けの意識が薄く、徹底できない場合も多い。
コミットログに書かれたチケットNoが間違っている時、漏れている時はないか?

但し、Redmineでは、コミット後に関連づけを編集する機能があるので、トレーサビリティを正しい状態へ修正する方法は残されている。

Redmine 1.4新機能紹介: チケットとリビジョンの関連づけの追加・削除 | Redmine.JP Blog

トレーサビリティは自動で生成できるか?
AIを使ったり、機械学習を使ったり、とか。

でも、自動生成されたトレーサビリティが本当に全て正しいの?という疑問がいつもある。
経験上、自動化しても多分あまり意味がないと思う。
モデル駆動開発におけるソース自動生成のアンチパターンと同じ。
自動生成に頼った運用は、メンバーのモチベーションを高めないから。

【3-2】トレーサビリティを実現する他の方法はあるか?

最も簡単かつ、今後発展性のある機能は、全文検索機能だ。
実際、アジャイルプロジェクトにおけるトレーサビリティ・マトリックスの記事でも「バージョン管理ツールや変更をトラッキングするツールを使用せよ」だけでなく、「シンプルな検索ベースのトレーサビリティ(「Googleで検索するだけ!」)」が紹介されている。

Redmineなら、全文検索プラグインを使うのが一つの解決方法。

Redmineで高速に全文検索する方法 - ククログ(2016-04-11)

Redmineでもっと高速に全文検索する方法 - ククログ(2017-09-25)

全文検索プラグインでは、チケット画面に類似チケットが表示される機能がある。
類似チケット機能は、Redmineというシステムそのものがトレーサビリティを補完する機能と見なすこともできる。
さらに、チケットにスマートフォンのスマートナビのような機能が実現されれば、面白いだろう。

【3-3】チケット関連図を作りたい

要件→チケット→ソースのマップが見たい。
つまり、Lycheeのチケット関連図のような機能がRedmineに欲しい。
この機能は、後方追跡性に相当する。

チケット関連図 | Lychee Redmine(ライチレッドマイン)でプロジェクトの見える化を。そして管理ももっと楽にしよう。

Redmine Lychee Enterpriseシリーズの解剖part3~Redmineのチケット関連図 Lychee Association ChartとRedmineの予実管理をサポートする Lychee Actual Date: プログラマの思索

利用シーンとしては、仕様変更のインパクト分析で使いたい。
たとえば、セキュリティ強化に関する要件に紐づく機能から、実装すべき機能チケットやソースへ追跡して、ソースの修正量、開発工数を測定したい。
そこから、修正見積りに使いたい。

また、プロセス保証にも使いたい。
たとえば、機能安全に関する要件に紐づく機能は本当に実装されているのか、作成された設計書やソースを追跡して、成果物に漏れがないことを確認したい。
そこから、製造物責任法や機能安全規格に関する要件を満たしていることを説明したい。

実現方法としては、親チケット=要件、子チケット=タスク、リビジョン=成果物の変更スナップショット、で対応付けできれば良い。
その後、要件→チケット→ソースのリビジョンのツリー構造の絵、つまりチケット関連図を紙で出力できればいい。
また、それら要件は、リリースバージョンでグルーピングすれば、ロードマップ画面がそのままリリース履歴になる。

しかし、いくつか問題も出てくる。
大規模な要件の場合、チケット関連図にあるツリー構造は非常に複雑になるだろう。
A3の紙1枚に収まらないかもしれない。
そうなると、漏れがないのか、確認するのも大変だ。

つまり、要件となる親チケットをグルーピングしたチケット関連図が欲しくなる。
その場合、どんな内容を出力すればいいのか?

一方、ソース→チケット→要件への前方追跡性はどう実現するか?
利用シーンとしては、手を入れるソースを元に影響するソースの範囲、要件の範囲を知りたい。
そこから、ソースの修正量、回帰テストの範囲、修正工数を測定して、見積りに使いたい。
これも一つのインパクト分析。
むしろ、リスク分析にもなる。

派生開発や保守案件のリーダーにとっては、前方追跡性の方が重要だろう。
見積り作業の効率化に直結するからだ。

Lycheeのチケット関連図には、そこまでの機能はないみたい。

【3-4】トレーサビリティマトリクスを作りたい

トレーサビリティマトリクスを作っても、要求や機能の項目が多くなると、A3の1枚資料に収まらなくなる。
要求チケットやソースが多すぎると読みにくくなる。
だから、要求や機能をカテゴリ化する必要が出てくる。

これもチケット関連図の問題点と同じ。

【3-5】チケット関連図やトレーサビリティマトリクスのスナップショットを保持したい

従来は、チケット関連図やトレーサビリティマトリクスを手作業でExcelで作っていた。
しかし、仕様変更やリリースが増えるたびに、これらExcel設計書の保守コストがすごく大きくなる。
度重なる仕様変更を要件管理で反映することすら大変なのに、チケット関連図やトレーサビリティマトリクスを保守するのはもっと大変だ。

本来は、Redmineのようなツールが、チケット関連図やトレーサビリティマトリクスをいつでも欲しい時に自動生成すべきだ。
なぜなら、Redmineにトレーサビリティに関する情報は全て一元管理されているからだ。
それらは、手作業で保守して維持すべき成果物ではない。

一般に、チケット関連図やトレーサビリティマトリクスは、リリースバージョンの単位でスナップショットを残し、記録していくのが良いだろう。
つまり、リリース履歴と一緒に、チケット関連図やトレーサビリティマトリクスも出力されて、要件カバレッジやコードカバレッジも出力できる。
そうすれば、リリースのたびに、システムの要件や機能が時系列でどのように増えていっているのか、その変化を見ることもできるだろう。
たとえば、今回の仕様変更で機能やコード量が大幅に増えたね、とか、一目で分かるはず。

【4】以上のように、Redmineにおけるトレーサビリティの課題を思いつくままあげてみた。
おそらくRedmine標準の機能だけでは、トレーサビリティに関する運用は不十分だろう。

しかし、Redmineによるチケット駆動開発に埋め込まれている「構成管理ツール連携」「全文検索」という機能には大いに可能性が秘められていると思う。
Redmineという一つの箱に全てのデータが一元管理されて集約されているのだから、チケット関連図やトレーサビリティマトリクスのような要望は、チケット集計するだけのRedmineの一プラグインとして実現できるはずだ。

また、全文検索プラグインが提供する「類似チケット」のような機械学習の機能は、もっと色んなアイデアで発展できる余地がある。
Redmineのデータマイニングは、所詮はテキストマイニングに過ぎないのだから、現在のライブラリを流用して色んなことができるはず。
自分たちの会社のRedmineに蓄積された作業ログはその組織文化に依存しているのだから、その会社特有の隠語やコンテキストを事前に把握できれば、効率的に機械学習できるはず。

アイデア段階にすぎないが、トレーサビリティにまつわる機能は、Redmineがあるからこそ、その利用シーンや実現可能性を色々考えることができる。

従来は手作業でトレーサビリティに関する成果物を作成していたが、これがRedmineというツールで手軽に実現できるようになると、開発プロセスにどんな効果を与えてくれるのか?
Redmineによるトレーサビリティのプロセス基盤は、CMMIレベル4やレベル5のようなプロセス保証をどこまで、低コストで実現してくれるのか?

色々考えてみたい。

| | コメント (0)

2017/12/09

日本のRedmineコミュニティの活動報告と今後の抱負

Redmine Advent Calendar 2017 - Qiitaに初参加です。
日本のRedmineコミュニティの活動報告と今後の抱負を書きます。

私が書くのは恐れ多いと思いますが、改めて、Redmine大阪スタッフとredmine.tokyoスタッフの皆さんに大変感謝です。

【参考】 Redmine Advent Calendar 2017 - Qiita

【1】日本のRedmineコミュニティ

現在活動中の日本のRedmineコミュニティは、Redmine大阪とredmine.tokyoの二つがあります。
Redmineは誕生して11年も経ちますが、どちらのRedmineコミュニティも2011年に創立されたので割と浅いです。

Redmineの9年間の歩みを振り返ってみる

Redmine 10周年記念 10年ふりかえり

私はその二つのコミュニティでスタッフとして関わっているので、その立場から生い立ちとその歴史を簡単に振り返ります。

【2】Redmine大阪

Redmine大阪 - connpass

RxTstudy

過去のイベント - RxTStudy~Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

【2-1】勉強会の発端は、2011年6月に、@pinkmacさんが「【緩募】関西でRedmineをタスク管理に使いたい勉強会を開催したら参加/発表してみたいという方!」というTwitterが流れたことです。
あっという間にスタッフや講演者、参加者が集まり、「RxTStudy~Redmineとタスクマネジメントに関する勉強会」というコミュニティとして発足しました。
「RxTStudy」は「Redmineとタスクマネジメント(Task)に関する勉強会(Study)」という意味です。

その後、Redmineが日本で知名度が上がる中、「RxTStudy」という名前では分かりにくいという声があったため、2016年に地域名を付けた「Redmine大阪」にコミュニティ名を変更して、今に至っています。

【2-2】第1回目の経緯は下記に書いています。

【告知】Redmineでのタスク管理を考える勉強会@大阪で発表します #RxTstudy: プログラマの思索

記念の1回目の勉強会は、その頃にRedmine本を出版した前田剛さん、倉貫さん、阪井さんと僕が講演したこともあって、定員50人があっという間に埋まり、当日の模様がUStreamで中継されてたいへん盛り上がったことを覚えています。
また、僕が講演した内容「RedmineのFAQとアンチパターン集」は、当時はすごく反響が大きかったことを覚えてます。

それから、最近は年2回ペースで開催され、現在は17回まで続いています。

【2-3】勉強会の内容は、Redmineの利用事例からRedmineのカスタマイズ方法、最新バージョンの機能紹介など多岐にわたります。
今までの中で、僕の記憶に残る主な講演は下記かな。

(1)@daipresentsさんの「チームにRedmineを適用せよ! #RxTstudy」では、楽天における1000人という当時は大規模なRedmine利用事例でした。

(2)@akahane92さんの「情報システム部門のタスク管理とIT全般統制 ~ Excel管理からの脱却 ~ (ITS Redmine #RxTstudy #5)」では、島津製作所の基幹系業務システムのタスク管理とIT全般統制にRedmineを導入して運用して効果を上げている事例でした。
その後、JaSSTやSQIPなどでも講演されて一躍有名になりましたね。

(3)陸野さんの「Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用」では、パナソニックにおける組込みソフトウェア開発にRedmineを導入運用した事例でした。
従来まで数多くのプロジェクト管理のパッケージ製品を導入してきたけれど、パッケージ製品には販売元の会社のプロセスが埋め込まれていて、自分たちの組織に合わない、という指摘に改めて刺激を受けたことを思い出します。

(4)JAXAの藤田さんの「JAXAスパコン"JSS2"の運用を支えるチケット管理システム"CODA"」では、JAXAスーパーコンピュータ活用課にて、業務の管理にRedmineを利用している事例でした。
実際のRedmine画面を見ることができて大変貴重でした。

(5)@ktouさんの「全文検索でRedmineをさらに活用!」では、Redmineの全文検索の機能強化と今後の可能性に関する事例でした。
Redmineに機械学習や人工知能などの技術を組み込むと、新たな可能性が広がる、というワクワク感が満載でした。

【3】redmine.tokyo

概要 - redmine.tokyo

【3-1】勉強会の発端は、僕がちょうど東京にいた頃、東京にいる熱心なRedmineユーザが集まって、勉強会を開こう、という話があがったことでした。
2011年当時は、@nobiinu_andさん曰く「東のTrac、西のRedmine」と言われるぐらい、東京ではTracコミュニティが活発だったので、Redmineもコミュニティが欲しいなあ、という雰囲気があったためです。

Shibuya.trac Wiki - Shibuya.trac - OSDN

nobiinu_andさんのツイート: "ですね! USTあるとイイなぁ… 実は東のtrac、西のredmineという状況だったりして RT @akipii: @nobiinu_and Redmineでのタスク管理を考える勉強会@大阪で議論できると思います。http://t.co/X2o1jPF #RxTstudy"

たしか、キックオフ飲み会が暑い8月に行われた時、当時はRedmineで唯一の日本人コミッタである@marutosijpさんも来られて、Redmineを話題に盛り上がったのを思い出します。

記念の第1回目の勉強会は、IPAで場所をお借りして開催されました。
第1回目の内容は、下記に書いています。

【告知】第1回品川Redmine勉強会を開催します #47redmine: プログラマの思索

当初は「品川Redmine」という名称でしたが、参加者から限定的なコミュニティのイメージを持たれることもあり、2014年から地域名を付けた「redmine.tokyo」にコミュニティ名を変更して、今に至っています。

それから、ほぼ年2回ペースで開催され、現在は13回まで続いています。

【3-2】勉強会の内容は主に、講演が数本、ライトニングトークスやグループディスカッションです。

redmine.tokyoの最大の特徴は、参加者がすごく多い点でしょう。
@naitohさんがまとめてくれているアンケート資料「Redmine.tokyo 13 questionnaire」を見ると、過去は参加者が100名超えの時もありました。
よって、いつも大変盛り上がっているのが印象的です。

また、@tkusukawaさんたちがボランティアで、UstreamやYoutubeで講演をリアル放映してくれています。
そのおかげで、いつも満員御礼になっているにも関わらず、参加できなかった人や東京以外の地方のRedmineユーザも視聴できます。
いつもありがとうございます。

【3-3】勉強会の内容はRedmine大阪と同じく、Redmineの利用事例からRedmineのカスタマイズ方法、最新バージョンの機能紹介など多岐にわたります。
今までの中で、僕の記憶に残る主な講演は下記かな。

(1)Takashi Okamotoさんの講演「RedmineとGitとスクラム」では、当時最新の使い方であったRedmineとGit連携の事例でした。

(2)@akahane92さんの講演「Redmineチューニングの実際と限界 - Redmine performance tuning」では、100万チケットでも耐えれるRedmineのチューニングノウハウの紹介でした。

(3)@netazoneさんの講演「ある工場のRedmine +(Plus)」では、製造業におけるRedmineの運用事例でした。
当時の環境では、プラグインが23個もあるのが驚異的でした。

(4)@onozatyさんの講演「View customize pluginを使いこなす」では、View customize pluginによるRedmineのカスタマイズ事例でした。
この発表後、View customize pluginの利用が広まったように思います。

(5)@kazuphさんの講演「IoT企業とRedmine // Speaker Deck」では、IOT企業のハード製造部門とソフト開発部門、サポートデスクの3部門におけるRedmine利用事例でした。
かんばんとガントチャートを使い分けている点が興味深ったです。

(6)JAXA木元さんの講演「CODAの定義・運用の現在 - 2017年版 -」では、JAXAにおけるRedmineのノウハウを惜しみなく公開した事例でした。

【4】参加している人たち

【4-1】参加者は、実際にRedmineを使ってプロジェクト運営しているSIのプロジェクトリーダー、Redmineのパッチを作ったりプラグインを開発する人達、SIでRedmineのサーバーのインフラを管理する人、などが多いです。
さらに、参加者層を分析すると、開発プロセスに興味がある人たちだけでなく、Redmineのパッチを作ったり、プラグイン開発者が割と多いことが特徴的だろうと思います。

つまり、素のRedmineを運用してみて不足している機能はプラグインで開発して、それをGithubで公開されている人が多いように感じます。
たとえば、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@two_packさん、@onozatyさんたちです。
また、@naitohさんのように、PDFの日本語化Gemを開発して貢献されている方もいます。

【4-2】Redmineコミュニティに携わるスタッフの立場では、プロジェクト管理や開発プロセスに興味を持つ人たちだけでなく、Redmineの機能強化につながるプラグイン開発者は非常に重要と思います。
なぜなら、Redmineの不足機能をプラグインで代替できるようにオープンソースで提供してくれているからです。

そのおかげで、ユーザはRedmineを自社の組織文化に合わせてカスタマイズすることが容易になります。
つまり、ユーザ自身が設計したプロセスへツールを合わせるように運用しやすくすることで、自然にプロセス改善の雰囲気がチーム内に発生し、チーム自身で問題解決していくという自律化の雰囲気を醸し出すメリットもあるのだろう、と感じるからです。

【4-3】最近は、勉強会の参加者層は幅広くなったように感じています。

グループディスカッションで聞いてみると、IT業界に限らず、製造業やゲーム業界、Webデザイン業界、など幅広い業界の人たちが参加しているようです。
また、Redmineを長年使っている人たちだけでなく、PMOや品質保証部に在籍する上層部の人や、興味があるから来てみたという初心者も増えているようです。

背景には、Redmineが日本でかなり知名度が上がり、実際に使われている場面が多くなっているからでしょう。
実際、日本国内におけるGoogleトレンドを見ると、現時点ではTracやJiraよりもRedmineが上位に上がるケースが多いようです。

Redmine 10周年記念 10年ふりかえり

【5】今後の抱負

Redmineコミュニティに携わるスタッフとして、今後の個人的な抱負は2つあります。

【5-1】一つ目は、Redmineコミュニティの参加者の多様化を図る事です。

Redmineが持つ特徴として、二つの側面があります。
まず、プロジェクト管理を柔軟に運用できるプロセス基盤または、ソフトウェア工学の理論を実験できるメトリクス収集・集計基盤であること。

「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」

SQIP2015講演資料「チケット駆動開発の運用パターン集~問題はチケットに分割して統治せよ」

次に、汎用的なプロジェクト管理ツールの開発基盤であること。

第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine~Redmineをカスタマイズするポイント」

すなわち、Redmineの利用者層は、前者の観点では、プロジェクトリーダーやPMO、品質保証部のような立場でプロセスを構築し運用する人達である一方、後者の観点では、プラグインを開発したりRedmineをカスタマイズするRuby開発者という二つの側面があるのです。
そして、その両方に詳しい技能を持つ人は非常に少ないでしょう。

よって、全く異なる技能を持つ人達が集まることで、プロジェクト管理やソフトウェア工学で困っている問題がプラグインやカスタマイズで解決できたり、新たなプラグイン提供によってプロジェクト管理の新たな使い方が生み出されることもあるでしょう。
つまり、プラグイン開発者とプロセス管理者がお互いに有意義な議論を重ねながら、ソフトウェア開発の現場を改善する道具として、Redmineは発展できるはずと考えます。

そういう化学反応、シナジー効果を提供する場を構築したいと考えてます。

【5-2】2つ目は、Redmineのエコシステムを作る事です。

日本の企業でRedmineがかなり普及している現在、Redmineは日本のSIにおける事実上の基幹業務システムではないか、と思います。
すると、Redmineは今後も安定的に機能改善されて保守されて欲しい。

幸いなことに、Redmineの歴史をたどると、自動テストが整備されたおかげで、RubyやRailsのバージョンアップにも追随しており、セキュリティパッチも早急に対処されています。
そのおかげで、Redmineの品質は割と高いのではないか、と思います。

Redmine build status

Redmine code coverage

また、性能面でも、Redmine大阪第17回勉強会に参加した - Basicに記載あるように「機能が増え続けるRedmineの処理の重さを、RubyやRailsの足回りが地道に改善してカバーしている」ように進化しています。

しかし、現在のRedmineのコミッタはJPLを含めて3人しかいない。

今後の夢としては、オープンソースの成功事例であるLinuxやRubyのような永続的なオープンソースとして確立して欲しい、と思っています。

たとえば、LinuxやRubyも当初は、開発者のおもちゃと見なされて、エンタープライズでは使えない、と思われた時期もありました。
しかし、コミュニティが発展してマーケットが広がっていくうちに、エンタープライズ界隈にも広がり、今ではむしろ、オープンソースで無いと保守され続けなくなるリスクがあるように見受けられます。
そして、LinuxやRubyも、コミッタと熱心なユーザだけでなく、ベンダーもユーザの一部として加わり、マーケットが拡大する方向へ成長している状況があります。

よって、RedmineもLinuxやRubyのように、コミッタ・ユーザ・ベンダーの三者が良好な関係を保ち、成長のらせん構造を昇っていけるような環境をいつか作りたい、と思っています。

| | コメント (0)

2017/12/04

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿

astahを使いながら、モデルの粒度とトレーサビリティのあるべき姿について考えたことをメモ。
以下は、最終的には、astahへの改善要望になるだろう。
ラフなメモ書き。

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

派生開発における変更指示をモデルで表現する(問題編) - Qiita

【1】個人的には、astahは好きだ。

astah* オンラインマニュアル

理由は2つある。
一つ目は、他のモデリングツールに比べて、操作が直感的でサクサク描けるから。
astahでUMLのダイアグラムを書く時に、迷うことがないし、サクサク描けるので、アイデアが無くなることも少ない。
一方、他のモデリングツールでは、UMLの各種ダイアグラムを描く時に、どうやって書けばいいんだっけ、と迷う時間が多いと、その間にアイデアは消えてしまう。
また、線を引っ張る時、保存する時にプログレスバーが出て待たされるようでは、イライラしてしまう。

二つ目は、一つのモデルを複数の観点で分析する考え方が自然に身につくことだ。
UMLでは約7種類、他にER図やDFD、マインドマップもあるので、一つのシステム像を表現したい時、静的なモデルだけでなく、動的なモデル、物理的な配置図、論理的なモデル、DOA的な視点、などでも自然に考えるようになる。
複数の観点でシステムの要件や機能を考えることによって、モデルの整合性やトレーサビリティにも気づきやすくなる。

そんな経験をしながら、モデリング技法のあるべき姿について考える時がある。
astahで色々書いていると、まだ何か足りない気がしてくるのだ。

【2】では、astahでモデルを書いていて、何が足りないと感じるのか?
不足していると感じる観点は、モデル間のトレーサビリティと粒度、変更管理に関する内容だ。

【2-1】モデル間のトレーサビリティ

たとえば、要件定義フェーズで、業務フローをアクティビティ図で描いて分析したら、その後、どこをIT化すべきか、という方向に分析が進む。
すると、業務フロー図に出てくるアクターがシステムである箇所で、アクティビティがあれば、そのアクティビティがユースケースに対応付けられる。
それらユースケースを集めると、ユースケース図になり、システムの全体像が定まる。

つまり、業務フローの各アクティビティ→ユースケースへの詳細化が後方追跡性に相当する。

また、各ユースケースは、論理モデルや実装モデルの観点で、クラス図やシーケンス図に分解されていく。
つまり、ユースケース図の各ユースケース→クラス図、シーケンス図への詳細化という後方追跡性が発生する。

しかし、アクティビティ図→ユースケース図→クラス図、シーケンス図へトレーサビリティが発生するのに、それらモデルのトレーサビリティを表現する方法がastahでは直感的に表現されていない。

モデラーの観点では、アクティビティ図のアクティビティをクリックしたら、対応するユースケースに遷移して、さらにユースケースをクリックしたら、対応するクラス図やシーケンス図を選択して表示される、という利用シーンを実現して欲しい。
そうすれば、要件定義→設計へモデルが詳細化されていく作業をトレーサビリティの機能によって補完することができる。

では、なぜそんなにトレーサビリティが必要なのか?
なぜなら、モデル間のトレーサビリティを考えることで、モデル要素の漏れや矛盾に気づきやすくなり、モデルの精度を上げられるからだ。
おそらくどのモデラーも、概要レベルのモデルを描いた後で、詳細化したモデルは別に描き、それらの整合性をどこかで考えているはず。
そういうモデル間の整合性を考える作業を支援する機能が欲しいのだ。

一方、現状のastahでトレーサビリティに相当する機能は、ハイパーリンク機能に相当するだろう。
つまり、モデル要素のリンク機能で十分だ。
モデル要素をクリックしたら、別のモデルへ遷移するように、ハイパーリンク情報を設定すればいい。

しかし、ハイパーリンク情報を設定するには、詳細画面を開き、遷移先のモデルを選択して更新する、という操作が発生し、とても面倒。
この操作を1クリックで操作できるようにしたい。
つまり、遷移元のモデル要素(ダイアグラム)を遷移先のモデル要素にドラッグ・アンド・ドロップすると、自動で相互リンクするようにハイパーリンク情報が設定される、といったイメージだ。
たとえば、アクティビティ図にあるアクティビティをドラッグして、ユースケース図へドロップすると、相互リンクが設定される、というイメージ。

すなわち、ハイパーリンク機能を流用したトレーサビリティの実現は、そんなに難しくないだろうと思うし、その効果はすごく大きいだろう、と考えている。

なお、モデラーの観点では、トレーサビリティの制御は手動の設定で十分だ。
ラフなスケッチでモデルをたくさん描いていくので、そんなに難しい機能は必要ないから。

【2-2】モデル間のレイヤ化、モデル間の粒度

業務システムの設計を開始すると、サブシステムの観点で、作ったモデルをグルーピングして整理したくなってくる。
たとえば、ECサイトなら、注文システム、商品検索システム、バックエンドのマスタ管理システムなど。
すると、普通は、パッケージをフォルダ代わりに使ってモデルをグルーピングして、モデルをどんどん深掘りしていく。
つまり、パッケージによるグルーピングは、モデルの粒度を揃えて整理する作業に相当する。

しかし、astahではパッケージ図でモデルをまとめた時に、モデルの内容が表示されないし、モデルへリンクする機能がない。
モデラーの観点では、パッケージ図に、パッケージでまとめたモデル名(ダイアグラム)が表示され、表示されたモデル名をクリックすると遷移する、という機能が欲しい。
そうすれば、モデルの粒度を揃えながら、モデルのトレーサビリティ機能を使って、モデルの漏れや整合性を考えやすくなる。

なぜ、モデルのグルーピング後のリンク機能が必要なのか?
なぜなら、モデルの粒度を揃えながら、モデルをレイヤ化する作業を行い、各レイヤ間のモデルのトレーサビリティを考えることで、モデルの精度を上げようとしているからだ。
こういうレイヤ化の作業は、設計作業だけでなく、プログラミングにおいても普通に行われている。
レイヤを一つ増やすことで、絡み合った仕様を整理し、ソフトウェアの複雑さを軽減していく手法は非常に重要だし、モデリングツールがそういう作業を支援するようにして欲しい。

しかし、astahではパッケージ図があるものの、EnterpriseArchitectのように、パッケージにモデル要素を表示してリンクする機能がないので、レイヤ化や粒度による整理がやりにくい。
逐一、構造ツリーでポチポチ開いて確認するしかない。
こんなイメージ。

ビュー

なお、現状のastahでは、パッケージやパッケージ図そのものにもハイパーリンク機能があるので、相互リンクさせることは可能だ。
但し、トレーサビリティの相互リンクと同じく、操作回数が多いので、イライラしてしまう時がある。

Enterprise Architectにはこの機能はあるので、astahにあともう少し機能があれば、という所だろう。

追跡(トレーサビリティ) - Enterprise Architect 13.5 日本語版 ヘルプ

ダイアグラムのトレーサビリティについて スパークスシステムズジャパン フォーラム - ユーザー掲示板

【2-3】モデルの変更管理と構成管理

要件定義では、顧客打合せをしながら、要件や仕様をモデルに反映していく。
その反映作業は、ソースにパッチを当てていく感覚と同じだ。
そして、モデルへのパッチ当ての作業は、行ったり来たりする場合も多い。
顧客の要望、実現すべき機能、実装可能な技術の選択、スコープと納期・コストとのトレードオフを考慮しながら、要件を固めていくので、手戻りはよく発生する。

この作業中に、当初作られたモデルはたくさんのパッチが当てられて、どんどん変化していく。
これがソースコードならば、Gitで構成管理されるので、変更理由のRedmineチケットと相互リンクされてどんどんコミットされていく。
そのコミット履歴から、ソースコードの変更箇所が特定できるし、どういう変更の経緯から発生したのか、という変更理由もチケットから辿ることができる。

しかし、モデルは普通は構成管理されていないので、変更履歴が残っていない。
モデルをGitで管理したとしても、差分箇所を表示できないので、日次バックアップにしか過ぎない。

また、各モデルが変更された時に、どんな変更理由で変わったのか、というRedmineチケットとモデルが相互リンクされていない。
よって、なぜモデルのこの部分が変わったのか、という理由を、後から辿ることが難しい。

本来は、モデルであろうとも、Git等の構成管理ツールの配下におき、変更履歴を管理し、チケット経由でトレーサビリティを実現したい。
しかし、その手法が現実的でないならば、せめて、モデルのメタ情報に、変更が発生したチケットNoを埋め込んでリンクする機能が欲しい。

そういう機能がないと、モデルに数多くのノートが作られて、いつどんな理由で変更された、というコメントがたくさん混じりこんでしまう。
この症状は、ソースコードにガラクタのコメントがたくさん残っている状況と同じだ。
残骸となったコメントは後からリファクタリングするのが難しくなるから、そういうコメントは不要。

さらに、メリットとして、Redmine上でモデルの変更履歴を全文検索できるので、保守フェーズで別の開発者が過去の要件や仕様を探しやすくなる。
また、Redmineにモデルの変更履歴が一元管理されるので、そこから、たとえば、レビュー指摘事項の修正件数や手戻りの設計工数などのメトリクスを集計して分析することもできる。

なお、現実的な機能としては、モデルを描いた後で、astah画面右下(拡張ビュー)でチケット登録できて、登録したチケット一覧が表示される機能があればよい。
そして、拡張ビューのチケット一覧で、チケットNoを押下すると、Redmineチケットへ遷移する機能があれば十分。
実際は、RedmineのREST APIキーとURLをastahで保持しておき、astahのモデル上でチケット情報を入力したら、Redmineでチケットが新規作成されて、拡張ビューに新規チケットが表示される、という流れになるだろう。

この機能が実現できれば、モデルの変更理由の一覧がRedmineチケット一覧と同一視できるので、開発工程以後でモデルの変更理由を探す時に役立つだろう。

Enterprise ArchitectにもRedmine連携プラグインがあるので、astahでも同様に実現できるはず。

Enterprise Architect-Redmine連携アドイン

あるいは、Backlogのastahプラグインがあるので、同様にRedmineプラグインをastahで作れるはず。

Backlog Connector for astah

【3】以上をまとめると、幅・深さのトレーサビリティと変更管理という要望にまとめられる。

1)幅のトレーサビリティ→同じ粒度のモデル間のトレーサビリティ

たとえば、1つのユースケースに含まれるクラス図、シーケンス図、ステートマシン図は相互リンクで行き来できる。

2)深さのトレーサビリティ→別レイヤのモデル間のトレーサビリティ

たとえば、パッケージ図において、グループ化されたパッケージに含まれるモデルへ深掘りしながら、リンクして行き来できる。

3)モデルの変更履歴

たとえば、モデルの変更履歴は、外部サーバーにあるRedmineチケットへリンクして確認する。
つまり、モデルの変更履歴の内容は、astahのモデルそのものに書くのではなく、メタ情報として外部サーバーのRedmineへ蓄積され、参照されるようにして、モデルから分離できる。
変更履歴がモデルから分離されることで、モデルは常に最新版の状態だけ保持すればよく、シンプルなモデルになる。

【4】レイヤ化されたモデル間のトレーサビリティが強化されれば、一つの全体的なモデルとして網の目状に紐付けられた成果物になる。
そして、astahのトレーサビリティマップの機能を使えば、相互リンクで紐付けられた状況を一目で見ることも可能なはずだ。

トレーサビリティマップ 【p】

[pro] トレーサビリティマップ

最終的には、さらに、トレーサビリティマトリクスが生成できるといい。
つまり、全てのモデル間で相互リンクがあるか否かを一目で確認できるクロス集計表が出力できればいい。
この機能は、XDDPのトレーサビリティマトリクスに相当するものだろう。

ソフトウエア改造力 - 第6回 改造の影響を調べる:ドキュメントをまとめ作業計画をレビューする:ITpro

XDDP成果物:USDM、トレーサビリティマトリクス、変更設計書

『XDDP』では「トレーサビリティマトリクス(TM)」で変更箇所を特定

このトレーサビリティマトリクスを生成できれば、特に派生開発やソフトウェア保守で、影響箇所の調査にすごく役立つだろう。
設計フェーズの事前調査で、あらかじめ仕様変更によるモデルの影響箇所を即座に把握できるようになるからだ。

また、モデルの変更履歴がRedmineに蓄積されることで、モデルから不要なコメントがなくなり、モデルは常に最新版だけ保持されるようになる。
残骸となった変更履歴のコメントはモデルには不要。
変更履歴の内容は本来、構成管理ツールで管理すべきだからだ。

なお、トレーサビリティの設定はモデラー自身が手動で設定すればいい。
実際、RedmineとGitなどの構成管理ツール連携によるトレーサビリティも、手動でチケットNoを入力することで対応しているので、違和感はないから。

【5】以上のような事を考えると、モデリングツールはまだまだ改善の余地があるし、換言すれば、数多くの可能性を秘めているのだろうと思う。
Redmineのように、ツールを使いながらプロセスを改善していくアイデアが思いつくように、モデリングツールを使いながら設計技法を改善するアイデアは、もっとたくさん出てくると思う。

| | コメント (0)

« 2017年11月 | トップページ