ソフトウェア設計可視化および設計改善支援

現状の問題点

• 仕様書、設計書の不足から、ソースコード中心の開発となった結果、個人に依存し、開発者の交代や要員の追加が難しくなっている
• ソースコードレベルで機能追加や修正を繰り返しているため、ソースコードが複雑になってきている
• 外部委託したいが仕様書、設計書がないので委託できない
• 仕様変更や機能追加に際し、設計書がないので影響範囲や変更箇所を特定するのが難しく、対応に時間がかかる。場合によってはデグレードが発生する
   

設計可視化および設計改善のポイント

• リファクタリング、設計改善の目的を明確にすること
• 改善すること自体が目的となっている設計改善には効果がありません
• 自動テスト環境を用意すること
  • 設計改善はデグレードのリスクを伴うため、自動テスト環境が必須です
  • 自動テスト環境が無い状態でのリファクタリングは危険です
• リファクタリング、設計改善個所を見極めること
  • ソースコード、設計が複雑でも品質が安定していて、将来の追加・修正の可能性がないところを改善しても意味はありません
  • 改善箇所の見極めには、設計の可視化だけでなく、不具合データの分析等も含めた多面的な分析が有効です
• 設計と実装、及び、テストケースが常に一致しているように設計情報を維持すること
  • 開発中での維持が難しいのであれば、その状態の回復を開発とは別のタイミングで実施するのも有効です

設計可視化、及び、設計改善サービス概要

• 設計の可視化(リバースエンジニアリング)
  • 既存のソースコードの構造をUML、SysML等で可視化し、設計情報を回復します
  • ソースコードをお借りして弊社側で実施することもできますし、お客様の場所で共同で実施することも可能です
• 設計上の問題点の分析
  • リバースエンジニアリングの結果を利用し、現在の設計の問題点の分析、改善施策の提案を行います
• 設計改善支援
  • 設計上の問題点を解決するための再設計を支援します
  • 必要に応じて弊社要員が一緒に再設計を行うことも可能です
• 設計改善活動の開発プロセスへの組込み
  • 設計改善活動を開発プロセスに組込み、設計品質を維持できるプロセスの構築を支援します
• 人材育成
  • 設計可視化や設計の問題点の分析ができる技術者を育成します
  • 関連講座→「設計可視化講座」
     

進め方

• 目標達成に向けた全体の進め方（例）
  • 分析、改善、定着と3Stepでの段階的な進め方をお勧めします
  • 進めながら明らかになる課題をキャッチアップし、改善をはかります
• 想定される課題（例）
  • ソースコードの書き方に合わせた、リバースエンジニアリングのルール作り
  • 設計改善のための環境の構築(デグレード検出のための自動テスト環境構築)
  • 設計の問題点に対する重要度の分析

設計可視化サービスの特長

• オブジェクト指向技術の豊富な経験
  • UMLを用いてソースコードから設計情報を可視化します
  • モデルを適度な粒度になるように階層化します
  • お客様のご要望に合わせたUMLツールを使用します
    例： Enterprise Architect、astah* など
  • アーキテクチャ/フレームワーク設計の経験が豊富です
• 課題ベースでの進め方
  • 現実に起きている不具合やその分析結果、プロセス課題から設計の可視化、リファクタリング、設計の改善方法を決めていていきます。
• 技術面だけでなく、開発プロセス、人材育成の面からもサポート
   

参考資料

弊社の技術著書「UML2 表記法ガイド」