JPH05314142A - 構造化手法に基づく設計作業の進捗状況管理システム - Google Patents

Abstract

(57)【要約】 【目的】 構造化手法に基づくソフトウェア設計作業の
進捗状況管理システムに関し、時間の経過に伴い作成す
る設計単位の数が変動する設計作業の進捗状況が容易に
把握できるシステムを提供することを目的とする。 【構成】 入出力手段１より入力される情報を設計図面
として編集し、編集を終了した設計図面と設計単位の種
類及び各設計単位の完了状況を設計図面蓄積手段３に蓄
積する設計支援処理部２と、入出力手段により予め設定
された条件に従って設計図面蓄積手段３より設計単位の
種類及び各設計単位の完了状況を識別する情報を読み出
し、設計単位ごとに予定数と完了数を時系列情報として
進捗管理情報蓄積手段５に蓄積させる進捗管理情報抽出
処理手段４と、入出力手段よりの進捗状況表示要求によ
り、進捗管理情報蓄積手段より設計単位の予定数と完了
数を読み出し、時系列グラフに編集して入出力手段に出
力する進捗管理情報処理手段６を備えるように構成す
る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は構造化手法に基づくソフ
トウェア設計作業の進捗状況管理システムに関する。

【０００２】近年、ソフトウェアの設計手法として、与
えられた問題を幾つかのより小さい問題に分解して記述
し、それらの問題を更に小さな問題に分割して記述す
る、と言う作業を段階的に繰り返し実施することにより
解となる最終の詳細な記述（例えばプログラム）に到達
する構造化手法が採り入れられるようになっている。

【０００３】このような構造化手法に基づくソフトウェ
アの設計作業は、作業が進むことによって初めて設計対
象の詳細化や見直しが行われることから、設計単位（段
階的に行う作業の単位）の数が時間の経過に連れて変動
しながら次第に確定する、と言う性質を有している。

【０００４】即ち、構造化手法に基づくソフトウェア設
計作業は設計開始当初において設計単位の数が不確定で
あり、かつ時間の経過とともに変動するために、設計作
業の進捗状況の把握が本質的に難しい、という特質をも
っている。

【０００５】このため、構造化手法に基づくソフトウェ
ア設計作業の進捗状況の把握を容易にするシステムの出
現が望まれている。

【０００６】

【従来の技術】従来のソフトウェア設計作業の進捗状況
の把握方法では、予め何らかの方法で推定した設計単位
の数を予定数とし、この予定した設計単位ごとに完了し
たか否かを確認し、完了した設計単位の数を実績値とし
て進捗状況を把握するのが普通である。また、プログラ
ム設計などの段階では、作成するプログラムステップ数
の概算値を予め推定し、これに対して作成を終了したプ
ログラムステップ数を各プログラムの作成者から報告を
受けて進捗状況を把握していた。

【０００７】従って、従来においては設計開始当初にお
いて作成すべき設計単位やプログラムステップ数がある
程度把握されているため、進捗状況の把握が比較的容易
であった。しかし、従来の方法においても、設計単位ご
との完了状況は各設計者からの完了したか否か、即ち、
１か０かの報告によるため、設計単位の数や内容に変化
が生じているような場合に進捗状況全体をきめ細かく把
握することが難しく、特に、プログラムステップ数によ
る進捗管理の場合は、作成するプログラムステップ数の
概算値が推定値であるために、作成したプログラムステ
ップ数がその概算値に達していても、プログラムはまだ
完成していない、と言った事態が生ずることも多かっ
た。

【０００８】一方、構造化手法に基づくソフトウェア設
計作業では設計開始当初において作成すべき設計単位の
数やプログラムのステップ数が概算値としても明かでな
いばかりでなく、作業の進行に伴ってその数が変化する
ため、設計単位（タスク、モジュール、図面など）の数
が数値として把握できるのは開発管理者が各設計者に作
成した設計図面の数やプログラムステップ数などを確認
した時となる。即ち、開発管理者が把握する設計単位の
数は設計が完了した数となるため、工程の後の方になら
ないと進捗状況の把握ができないこととなり、従来にお
けるような形で進捗状況を管理することができなかっ
た。

【０００９】このため、特に設計単位の数が多い大規模
な設計作業においては、開発管理者は設計の進行に合わ
せてその都度変動量を考慮した予定と実績を定量的なデ
ータに変換し、汎用の表計算プログラムや専用のプログ
ラムに投入することにより進捗状況を把握しているが、
この方法は進捗状況の把握の準備に多大の時間を要する
と言う問題を有している。

【００１０】

【発明が解決しようとする課題】従来手法によるソフト
ウェア設計作業においては、設計開始当初において作成
すべき設計単位の数が概算値として把握されているた
め、進捗状況の把握が比較的容易であったが、構造化手
法に基づくソフトウェア設計作業では設計開始当初にお
いて設計単位の数が不確定であり、かつ時間の経過とと
もに変動するために、従来のような進捗状況の把握方法
が使用できず、開発管理者が進捗状況の把握のために多
大の時間を費やすと言う問題が生じていた。

【００１１】本発明は、時間の経過に伴い作成する設計
単位の数が変動する設計作業の進捗状況が容易に把握で
きるシステムを提供することを目的とする。

【００１２】

【課題を解決するための手段】図１は本発明の基本構成
図である。図中、１は入出力手段、２は前記入出力手段
１と情報を授受し、該入出力手段１より入力される情報
を設計図面として編集し、編集を終了した設計図面と該
設計図面に使用された設計単位の種類及び各設計単位の
完了状況を識別する情報を設計図面蓄積手段３に蓄積す
る設計支援処理部、４は前記入出力手段１により予め設
定された条件に従って前記設計図面蓄積手段３より前記
設計単位の種類及び各設計単位の完了状況を識別する情
報を読み出し、設計単位ごとに予定数と完了数を時系列
情報として進捗管理情報蓄積手段５に蓄積させる進捗管
理情報抽出処理部手段、６は前記入出力手段１より進捗
状況の表示要求が行われたときに、要求された設計単位
の予定数と完了数を前記進捗管理情報蓄積手段５より読
み出し、時系列グラフに編集して前記入出力手段に出力
する進捗管理情報処理手段である。

【００１３】

【作用】図１のシステムにおいてはソフトウェアの設計
を行う際に、設計支援処理部２が入出力手段１と情報を
授受し、該入出力手段１より入力される情報を設計図面
として編集し、編集を終了した設計図面と該設計図面に
使用された設計単位の種類及び各設計単位の完了状況を
識別する情報を設計図面蓄積手段３に蓄積する。

【００１４】進捗管理情報抽出処理手段４は入出力手段
１が予め設定した条件に従って前記設計図面蓄積手段３
より前記設計単位の種類及び各設計単位の完了状況を識
別する情報を読み出し、設計単位ごとに予定数と完了数
を時系列情報として進捗管理情報蓄積手段５に蓄積させ
る。

【００１５】上記の状態において、入出力手段１より進
捗状況の表示要求が行われると、進捗管理情報処理手段
６は要求された設計単位の予定数と完了数を前記進捗管
理情報蓄積手段５より読み出し、時系列グラフに編集し
て前記入出力手段に出力する。これによって、入出力手
段１ではその時点までの該当設計単位の予定数と完了数
を時系列的に把握することができる。

【００１６】以上の如く、図１においては、設計単位の
数が設計開始当初において不確定で、時間の経過ととも
に変動するために設計作業の進捗状況の把握が本質的に
難しいという特質をもっている構造化手法に基づくソフ
トウェア設計作業の進捗状況を把握することが可能とな
る。

【００１７】

【実施例】図２は本発明の実施例構成図、図３及び図４
は本発明の実施例フローチャート、図５及び図６は本発
明の実施例進捗管理ファイル構成説明図、図７は本発明
の実施例表示状態図である。

【００１８】全図を通じ、同一記号は同一対象物を示
し、７は進捗管理条件ファイル、８は進捗段階管理テー
ブル、９は入出力インタフェース部である。図２は本発
明による進捗状況管理出力の実施例の構成図である。図
の入出力装置１はシステムに複数台設置されるが、図２
では１台の入出力装置１のみを図示している。通常、複
数の入出力装置１は開発管理者や設計者によって随意に
使用されるが、使用者はＩＤ番号等によりシステムに識
別される。しかし、以下においては説明の便のため、開
発管理者や各設計者がそれぞれ専用の入出力装置１を使
用するものとする。

【００１９】設計支援処理部２は所謂ＣＡＤ（Computer
Aided Design)機能部で、入出力装置１と入出力インタ
フェース９を介して情報を授受し、入出力装置１より入
力される情報を設計図面（以下、仕様書、設計書、図面
などを総称して設計図面と記す）として編集し、編集を
終了した設計図面を設計図面ファイル３に蓄積するもの
で、その主要機能は公知のものである。

【００２０】設計図面ファイル３は例えばソフトウェア
システムごとに１組づつ設けられるが、図２では１組の
設計図面ファイル３のみを図示している。なお、蓄積す
る図面は完成した図面とは限らず、一日の設計作業を終
了した時点で一時蓄積する場合を含むが、完成した時に
は入出力装置１より完成したことを識別する情報（以
下、完成情報と記す）を入力するものとする。この完成
情報は設計支援処理部２を介し、図面情報とともに設計
図面ファイル３に蓄積される。

【００２１】また、設計支援部２は作成した図面の中に
記載されている例えば、タスク名、モジュール名または
図面名称などを設計単位として抽出する機能を有してい
る。設計図面ファイル３は設計単位ごとに設計図面を蓄
積しているので、一つのソフトウェアシステムの設計図
面ファイル３を読み出すことにより、その時点で作成す
る予定の設計単位の数及び名称が確認できる。また、前
記の完成情報も設計単位に対応して記録されるので、各
設計単位が完成しているか否かも確認できる。

【００２２】以上を前提に、図２乃至図７を用いて本発
明による進捗状況の管理方法を説明する。なお、Ｓ１〜
Ｓ24は図３及び図４のフローチャートの各ステップを識
別する記号、Ｄ１〜Ｄ６は図７の表示状態を識別する記
号である。

【００２３】図２のシステムにおいては進捗状況の管理
を行う場合、最初に進捗状況の管理条件を設定する。こ
の設定を行うために開発管理者が入出力装置１を起動す
ると、入出力インタフェース９を介して設計支援処理部
２が起動され、図７に示すシステムメニュー（初期メニ
ュー）Ｄ１が表示される（図３のＳ１参照）。システム
メニューＤ１は設計支援処理部２の中で使用するＣＡＤ
機能を指定するためのものであるが、図２のシステムで
は従来のＣＡＤ機能に「進捗管理機能」が付加されてい
るので、図７のＤ１中の「進捗管理機能起動」を選択す
る（図３のＳ２）と、処理が設計支援処理部２より進捗
管理情報処理部６に移される。

【００２４】進捗管理情報処理部６が起動されると図７
のＤ２に示すような進捗管理機能メニューが入出力装置
１に表示される（図３のＳ３）ので、入出力装置１が
「進捗管理条件設定」を選択すると図７のＤ３に示す進
捗管理条件設定画面が入出力装置１に表示される（図３
のＳ４〜Ｓ５）。

【００２５】入出力装置１が抽出期間（進捗管理のため
の情報を設計図面ファイル３より抽出して記録する期
間）として抽出開始時期と終了時期の情報、管理単位期
間として例えば「毎週」を選択して入力を行うと、進捗
管理情報処理部６はこの情報を進捗管理条件ファイル７
に蓄積して進捗管理条件の設定を終了する（図３のＳ
６）。この進捗管理条件は入出力装置１ごとに記憶さ
れ、下記のように各設計単位の予定数と実績を抽出期間
の間、管理単位期間（この場合、一週間）ごとに記録す
るのに使用される。

【００２６】次に、上記進捗管理条件ファイル７が設定
された後、設計作業が行われた場合の動作を説明する。
設計者が自己の入出力装置１より設計支援処理部２を動
作させて自己の担当する設計単位の設計作業を行い、そ
の日の作業を終えた時に作成した設計図面を保存するコ
マンドを入力すると、設計支援処理部２はその入出力装
置１により作成された設計図面を設計図面ファイル３に
蓄積する。その際、その日の作業によりその設計図面が
完了したのであれば設計者は完了情報を同時に入力す
る。

【００２７】設計図面ファイル３に蓄積された設計図面
を進捗状況を管理するために抽出する方法には各種の方
法があるが、ここでは毎朝、各入出力装置１が電源を投
入したときに、その入出力装置１が前日設計図面ファイ
ル３に蓄積した設計図面のデータを読み出すものとす
る。

【００２８】入出力装置１が電源を投入し、設計支援処
理部２が起動されて初期メニューＤ１（図７）が表示さ
れる（図４のＳ21) と、設計者はその日に行う作業の内
容に応じて適当な機能、例えば「ドキュメント編集起
動」を選択して作業を開始する。このとき、設計支援処
理部２は進捗管理情報抽出処理部４を起動して設計図面
ファイル３より設計図面データの抽出を行わせる。

【００２９】進捗管理情報抽出処理部４は先ず進捗管理
条件ファイル７が存在するか否かを図示省略された方法
で確認し（図４のＳ22）、存在しない場合はそのまま処
理を終了する。進捗管理条件ファイル７が存在すればこ
れにアクセスし、該当入出力装置１によって作成された
設計図面の進捗状況管理条件を読み出す（Ｓ23）。

【００３０】その日が進捗状況管理条件に適合しない場
合、即ち、進捗状況を記録する日に当たっていなければ
特に処理を行わずに終了するが、進捗状況管理条件に適
合していれば設計図面ファイル３より関連する設計図面
のデータを抽出する（Ｓ24〜Ｓ25）。

【００３１】設計図面ファイル３にはタスクなど設計単
位に該当する項目はシンボルで記載されているため、設
計図面のデータを抽出することによってその作業で作成
すべきタスクやモジュールの数が把握できる。説明を簡
単にするために、一つのソフトウェアシステム（サブシ
ステムである場合を含む）は複数のタスクからなり、各
タスクは複数のモジュールからなり、更に各モジュール
は複数種類の図面からなるとすると、ここで計数された
数が各設計単位（システム、タスク、モジュール）の予
定数となる。例えば、タスクが５個計数されれば、この
システムのその時点のタスクの予定数が５であることと
なる。構造化手法によるソフトウェア設計では設計単位
の数は設計の進展に伴い増加して行くのが普通であるた
め、設計単位の予定数はあくまでその時点の経過的な数
値となる。

【００３２】一方、各設計単位については作成しなけれ
ばならない項目（以下、管理項目と記す）が予め定めら
れており、全管理項目の該当設計図面が全部作成を完了
していればその設計単位は完了したと判定する。なお、
この管理項目はタスク、モジュールなど設計単位ごとに
予め定められているため、設計開始から設計の終了まで
変わることはない。図２の進捗段階管理テーブル８は構
造化手法により設計作業を段階的に細分化した場合の各
段階における各設計単位について、上記した管理項目を
記憶しているテーブルである。

【００３３】進捗管理情報抽出処理部４は設計図面のデ
ータを抽出すると、進捗状況データとして編集するが、
このとき、前記進捗段階管理テーブル８より情報を得る
（Ｓ26) 。これによって作成された進捗状況データは進
捗管理テーブルとして進捗管理ファイル５に蓄積され
（Ｓ27) 、入出力装置１に関する進捗管理ファイル５の
作成処理は終了する。

【００３４】図５及び図６はこのようにして進捗管理フ
ァイル５に蓄積された進捗管理テーブルの構成の例を説
明する図である。図５は進捗管理条件として一週間ごと
に進捗管理を行うことを指定した入出力装置１の或る一
週間（この例では1992年 3月30日〜 4月 5日）の設計作
業のタスクに関する進捗管理データが記憶された進捗管
理テーブルの例である。この記憶は設計作業が行われた
一週間の次の週の初日（この例では1992年 4月 6日）の
朝、該当入出力装置１が電源を投入したときに進捗管理
テーブル５に蓄積されたことになる。進捗管理ファイル
５には図５及び図６のような進捗管理テーブルが時系列
的に蓄積されている。

【００３５】図５のテーブルはこのソフトウェアシステ
ム（サブシステムを含む。図２の進捗状況管理システム
との混同を避けるため、以下、すべてサブシステムと記
す）が５つのタスク（タスク＃１〜＃５と記す）で構成
されることを示している。従って、このテーブルはサブ
システム及び該サブシステムを構成するタスク全体の進
捗状況の管理に使用できる。このタスク数の５は、この
テーブルが作成された時点における該当サブシステムの
設計単位（タスク）の予定数を示しており、将来タスク
数が増加する可能性があることは前述のとおりである。

【００３６】図５は同時に各タスク個別の進捗状況を示
している。前記のように各タスクの管理項目は進捗段階
管理テーブル８により統一されるが、この例では何れも
同一内容の３項目が管理項目となっている。また、この
例ではタスク＃１は３つの管理項目全部について設計を
終了しているが、他の４つのタスク＃２〜＃５はいずれ
も完了していない管理項目を有しているとする。各タス
クの進捗状況を（完了管理項目数）／（予定管理項目
数）で表し、サブシステムの進捗状況は（完了タスク
数）／（全タスク数）で表すとすれば、図５のタスク＃
１は３／３で完了しており、タスク全体、即ち、サブシ
ステムとしての進捗状況（完了度）は１／５となる。

【００３７】図６は図５と同一の期間におけるモジュー
ルに関する進捗管理データが記憶された進捗管理テーブ
ルの例である。図では説明のために一つのタスクのみで
なく、システムを構成する図５の５つのタスクのそれぞ
れについての進捗状況を示している。この場合も各モジ
ュールの管理項目は一定（この例では５種類）である
が、モジュール数はタスクごとに変わり、将来変化する
可能性がある。

【００３８】図６の進捗管理テーブルにより、その時点
における各タスクを構成する設計単位、即ちモジュール
の予定数と完了数が把握でき、また、モジュールの進捗
状況（完了度）も、（完了モジュール数）／（全モジュ
ール数）によって把握することができる。

【００３９】次に上記のようにして作成された進捗管理
ファイル５を用いて進捗管理を行う場合について説明す
る。開発管理者が進捗状況を知るために入出力装置１を
起動すると、入出力インタフェース９を介して設計支援
処理部２が起動され、図７に示すシステムメニュー（初
期メニュー）Ｄ１が表示される（図３のＳ１参照）。開
発管理者が「進捗管理機能起動」を選択する（図３のＳ
２）と、処理が設計支援処理部２より進捗管理情報処理
部６に移され、図７の進捗管理機能メニューＤ２が入出
力装置１に表示される（図３のＳ３）。

【００４０】ここで、開発管理者が「進捗状況表示」を
指定すると、図７のＤ４に示す進捗状況表示メニューが
入出力装置１に表示される（図３のＳ４→Ｓ７）。ここ
で開発管理者が図５に示したタスク＃１の進捗状況を知
りたい場合は、入出力装置１より「タスク」と「個別」
を選択するコマンドを入力し、設計単位名として「タス
ク＃１」を指定する（図３のＳ８）。進捗管理ファイル
５が作成されていなければ、ここで処理は終了する（Ｓ
９) が、進捗管理ファイル５が存在すれば、進捗管理情
報処理部６が進捗管理ファイル５より関連するデータを
抽出し、時系列のグラフに編集して入出力装置１にＤ５
のように表示する（Ｓ10，Ｓ11) 。

【００４１】図７のＤ５に示すように、個別の進捗状況
では管理項目数は一定値であるため、予定数は設計開始
時点から一定となり、実績は設計の進行とともに増加す
る。なお、図５ではタスクの管理項目を３項目とした
が、図７のＤ５では説明の便から項目数を増加して図示
し、また、進捗管理者の進捗状況表示要求時期を８月10
日からの一週間の間であるとした。

【００４２】図３のＳ８において開発管理者がそのサブ
システムのタスク全体の進捗状況を知りたい場合は、入
出力装置１より「タスク」と「全体」を選択するコマン
ドを入力する（なお、複数のサブシステムがある場合に
は設計単位名として該当サブシステム名も入力する）。
この場合は図７のＤ６に示すようなグラフが表示され
る。図７の例は設計単位の予定数、即ち、タスクの予定
数が設計開始当初は少なく、設計の進展に伴って増加す
る状況を示している。設計単位の実績（完了数）は当初
は当然０で、時間の経過とともに増加する。

【００４３】構造化手法によるソフトウェア設計では設
計単位の予定数は設計の進展に伴い増加するが、図示の
例のように設計期間の末期になるほど設計単位の予定数
の増加が飽和するのが普通である。従って、開発管理者
が進捗状況を把握しようとした８月10日時点ではタスク
数の増加が今後少なく、タスク全体の完成度が高いと判
断することができる。一方、設計開始後、比較的早い時
期、例えば図７のＤ６に示す４月６日頃に進捗状況を表
示させた場合には設計単位の予定数が急速に増加してい
るため、たとえ実績が高い値を示していても開発管理者
はその時点における進捗状況はまだ信頼できる精度に達
していないと判断することができる。

【００４４】タスク＃１のモジュール全体の進捗状況を
把握する場合も同様に、図３のＳ８において入出力装置
１より「モジュール」と「全体」を選択するコマンドを
入力し、設計単位名として「タスク＃１」を入力する。
これによって、タスク＃１におけるモジュールの予定数
と完了モジュール数（実績）がグラフ表示される（図示
省略）。

【００４５】以上のように、図２のシステムでは、進捗
状況把握のために特別な準備を要することなく、構造化
手法に基づくソフトウェア設計作業の進捗状況を精度高
く把握することができる。

【００４６】以上、図２乃至図７により本発明の実施例
を説明したが、図２乃至図７はあくまで一実施例を示し
たものに過ぎず、本発明が図示したもののみに限定され
るものでないことは言うまでもない。例えば、図３及び
図４に示したタスク及びモジュールの管理項目の名称と
数、図７に図示された表示内容などは何れも説明のため
のもので、図示のものに限定されないことは当然であ
る。また、図２の設計図面ファイル３、進捗管理ファイ
ル５、進捗管理条件ファイル７及び進捗段階管理テーブ
ル８はいずれもディスクのシンボルで示しているが、こ
れらを半導体メモリで構成しても本発明の効果が変わら
ないことは明かである。

【００４７】また、設計図面データを読み出し、進捗管
理データとして進捗管理ファイル５に蓄積する時期を毎
朝、入出力装置１の電源投入時としたが、何時、どのよ
うな情報を用いて蓄積するかについては各種の方法があ
る。しかし、いずれの方法によっても本発明の効果は変
わらない。

【００４８】

【発明の効果】以上説明したように、本発明によれば、
設計単位の数が設計開始当初に不確定で、時間の経過と
ともに変動するために設計作業の進捗状況の把握が本質
的に難しいという特質をもっている構造化手法に基づく
ソフトウェア設計作業において、特別の準備を要するこ
となく進捗状況を精度良く把握することができるため、
かかる構造化手法に基づくソフトウェア設計作業の進捗
状況の管理の精度の向上と進捗状況把握に要する労力の
軽減に著しい効果を発揮する。

【図面の簡単な説明】

【図１】 本発明の基本構成図

【図２】 本発明の実施例構成図

【図３】 本発明の実施例フローチャート（１）

【図４】 本発明の実施例フローチャート（２）

【図５】 本発明の実施例進捗管理ファイル構成説明図
（１）

【図６】 本発明の実施例進捗管理ファイル構成説明図
（２）

【図７】 本発明の実施例表示状態図

【符号の説明】

１ 入出力手段 ２ 設計支援処理部 ３ 設計図面蓄積手段 ４ 進捗管理情報抽出処理手段 ５ 進捗管理情報蓄積手段 ６ 進捗管理情報処理手段

フロントページの続き (72)発明者 久保田 優二 北海道札幌市厚別区下野幌テクノパーク１ 丁目１番５号 富士通北海道通信システム 株式会社内 (72)発明者 種田 はるみ 神奈川県川崎市中原区上小田中1015番地 富士通株式会社内

Claims (1)

【特許請求の範囲】
1. 【請求項１】 構造化手法に基づくソフトウェア設計
   作業の進捗状況を管理する進捗状況管理システムであっ
   て、 入出力手段(1) と情報を授受し、該入出力手段(1) より
   入力される情報を設計図面として編集し、編集を終了し
   た設計図面と該設計図面に使用された設計単位の種類及
   び各設計単位の完了状況を識別する情報を設計図面蓄積
   手段(3) に蓄積する設計支援処理部(2) と、 前記入出力手段(1) により予め設定された条件に従って
   前記設計図面蓄積手段(3) より前記設計単位の種類及び
   各設計単位の完了状況を識別する情報を読み出し、設計
   単位ごとに予定数と完了数を時系列情報として進捗管理
   情報蓄積手段(5) に蓄積させる進捗管理情報抽出処理手
   段(4) と、 前記入出力手段(1) より進捗状況の表示要求が行われた
   ときに、要求された設計単位の予定数と完了数を前記進
   捗管理情報蓄積手段(5) より読み出し、時系列グラフに
   編集して前記入出力手段に出力する進捗管理情報処理手
   段(6) を備え、 構造化手法に基づくソフトウェア設計作業の進捗状況を
   時系列グラフで表示することを特徴とする構造化手法に
   基づく設計作業の進捗状況管理システム。