なんだか愚痴っぽい

昨日で、一旦手離れ。
思考は連続していたはずなのに、残ってる資料には連続性が...
“またダメだなぁ”と思いながら、コアとなる抽象事項だけは、なんとか整理しておいた。

最初は、ドキュメントの連続性を目標にしてたはずなのに、なんだかコーディング始めると、脆くも概念設計が一部崩壊。まぁ、対象システムの癖を、きちんと調査していなかったことが悪かったのだけど。
いや、今思えば、もっと引いた視点で捉えれば、より抽象化した概念で包括することも可能だったと。
概念と実装の変換方法をうまく定義すれば、それでいいんだけど。

テスト仕様書の書き方にも、なにかしら納得できないものがあるし。ほんとにこれで、網羅できてんのかなぁ。
それにテスト実施書のフォーマットが醜い。自分で作ってて何なのだが。

要求仕様（と呼べるのかわからないA4１枚半の汚い文章、いや、もはやそれは文章としは機能せず、そこにある単語のみがヒントを与えてくれるような代物でしなかいのだが...）を渡され、ユースケースを起こし、シーケンス図を描く。重要概念はクラス図で整理。画面遷移図を作成。シーケンス図を詳細化し、システムに必要な機能を整理。
C言語へのマッピング方法を定義し、コーディング。と行きたいとこたっだのだが、システムのGUI制御実装ロジックの特徴から、想定していた方法が上手くいかないが判明。（あー、最初に調査すべきだった）
テストプログラムをいろいろと作成し、コーディングパターンの検討に丸一日を消費。（ここで、もうちょっと引いた視点で認識できたら、オブジェクト指向の概念で捕捉できた気がするのに）
なんだか、シーケンス図から離れて画面遷移に依存したコーディングに突っ走ってしまう自分に危うさを感じつつ、それでも突入（ダメじゃん）。新規単位機能および新規単位情報については、クラス風にコーディングを堅持。インターフェースレベルの画面遷移関連コードでは、実装レベルコードを晒さないことを絶対防衛線として心に刻みつつ格闘。なんとか画面遷移レベルと抽象レベルと実装レベルの３層の認識でコーディング完了。

画面周りはシステムのGUI制御ロジックに依存するから仕方ないし、なんとか最低レベルはクリアといったところか。

いや、ホントは実装レベルの設計書を記述すべきなんだろうか。抽象レベルと実装レベルへの変換仕様さえあればいいと思う気もするが。
まぁ、どちらにしろドキュメントを残すことが重要なのだが...。

あーなんだが愚痴っぽい。
ていうか愚痴だな、これ。