本連載では、組込みシステムの派生開発で起こりがちな問題とその対策について説明しています。今回は、設計書やドキュメントにまつわる問題を取り上げます。

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
【派生開発の問題点】　ベースとなる製品のデータを調べたところ、設計書に不備が見つかった。元のコードの開発担当者は異動・転勤または退社しており、確認できない。

【原因】　ソフトウェア開発の成果物が適正に管理・保守されていなかった。

【対策】　現状の問題点を洗い出し、開発成果物の管理・保守のルールを設ける。既に動き出している派生開発については、残されたコードを地道に分析し、設計書の不備を修復する。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

　製品開発が終了した後、設計書やソースコード、テスト情報などがリポジトリに放り込まれたまま、最新の状態にメンテナンスされていなかった、というのはありがちな話です。例えばソースコードの変更が設計書に反映されていなかったり、補足説明のドキュメントが残っていなかったりします。

　派生開発のプロジェクトは、ベースとなる製品の開発が終わった後、何年もたってから開始となることがあります。
問題が発覚したときに、元のコードの開発担当者が不在、という状況は、それほど珍しくありません。
このようなとき、以下の２つのことを並行して考える必要があります。

・再度、同じ状況に陥らないために何をするべきか
・目の前の問題（設計書の不備）にどう対処するか


　前者は、主に開発管理者の仕事です。同じ状況を繰り返さないために、現行の開発成果物の管理・保守のやり方を見直す必要があります。例えば、開発成果物の管理が属人的になっていないか、保守は確実に行われているか、バージョン管理や構成管理は正しく機能しているか、といったことを確認し、必要に応じて管理・保守のためのルールを設けます。
このとき、ツールを使って開発成果物を管理する方法が有効です。シンプルなバージョン管理・構成管理ツールから、ソフトウェアの開発サイクル全体をきめ細かくサポートするものまで、さまざまなタイプの環境が提供されています。

ただし、この手の管理ツールはインストールすればすぐに使い始められるわけではありません。たいていの場合、開発業務の内容や手順に合わせたカスタマイズが必要です。その意味では、ツールを導入する際に、派生開発の内容や手順も含めて吟味する必要があります。

　
　一方、後者の、目の前の問題（設計書の不備）への対処は、派生開発の担当者の仕事です。これについては、ソースコードを地道に分析し、設計書のどこに問題があるのかを自身で確認するしかありません。

ただし、ソースコードを目視で追いかける方法だと、分析に時間がかかります。このような作業を補助するツールが、当社（DTSインサイト）のソフトウェア影響分析ツール「Re:Zolver（リゾルバー）」です。このツールは、プログラム内部の関数や変数の依存関係をグラフ表示する機能を備えています。ベースとなる製品をこのツールにかければ、内部の機能の関係性が分かり、プログラムの構造や処理内容を把握する助けとなります。

　またこのツールは、C++で開発したソフトウェアに対して、クラスの継承関係やUMLクラス図をグラフ表示する機能も備えています。これにより、オブジェクト指向で開発されたプログラムの構造も確認できます。


　次回は、他の人が作成したコードを取り扱う際の問題を、もう少し深く掘り下げます。



デモやお見積りのご依頼などのお問い合わせへのリンク

派生開発では、しばしば過去のソフトウェア資産の不備が見つかる


「クラス関連グラフ」や「UMLクラス図」からC++プログラムの構造を把握



デモやお見積りのご依頼などのお問い合わせへのリンク