「ウォーターフォール」として作用することを狙った SDLC は、その目的を達成してはいない。
以下のような問題点が露呈している。

　（1） ユーザ要件の捕捉漏れ
　（2） 手法の「翻訳変換」
　（3） SDLC と ビジネス周期との乖離

ユーザ 要件の捕捉漏れとは以下の２つをいう。

　（1） インフォーマル・システム の捕捉漏れ
　（2） CSF （Critical Success Factor ）の捕捉漏れ

SDLC を アプリケーション 単位に適用した ソフトウェア・エンジニアリング が、以下の「重複」を蔓延したことは、すでに述べた（「DOA の進化形 [ DOA＋ ]」を参照されたい）。

　（1） 20倍の データ名重複
　（2） 70％の データ重複
　（3） 90％の無駄プログラム

すなわち、１つの アプリケーション・システム を例にすれば、１つの データ項目に対して平均 20個の マチマチ な名称が プログラム のなかで使われ──たとえば、従業員番号という１つの データ に対して、EMP-NO や E-NUMBER や Ｅ-Ｎ など マチマチ の データ名称が付与されていて──、データ・ストーレッジ のなかに収められている データ の 70％が重複していて、（或る生命保険会社の例では、） 過去に作成された プログラム の ソース・コード の 90％が無駄であった、という調査が報告されている。

このような状態のなかで、メンテナンス の整合性が崩れて、コンピュータ が出力する数値が、たとえば、同じ数値であるべき売上高の数値が複数の レポート を 比べたら マチマチ の数値（近似値ではあるが、、、）表示されている、という現象が起こっている。

コンピュータ の数値を信用していない エンドユーザ は、自らの仕事を守るために、仕事のなかで使う データ あるいは情報を隠蔽して使っている。仕事のなかで隠蔽されて使われている数値こそが、仕事を実際に運用している数値なのである。すなわち、フォーマル な コンピュータ・システム とはべつの世界として インフォーマル・システム が稼働している。

責任持って事業過程 （購買過程・生産過程・販売過程・財務過程・労務過程） のなかで仕事をしたことのない システム・エンジニア が、エンドユーザ の従事している「業務を直接の対象として」分析できるのかどうか、、、あるいは、複数の エンドユーザ が隠蔽している インフォーマル・データ（または、情報）を捕捉できるのかどうか [ できない（！）]。また、責任持って経営過程のなかで仕事をしたことのない システム・エンジニア が、「事実を記述する」ことができなければ、環境変化と事業の現状を対比して、事業の環境適応能力を判断して CSF を考えることができるのかどうか　[ できない （！）]。

したがって、SDLC の最初の段階（分析工程）において、われわれが再検討しなければならない点は、「事実の記述（事業の現状を記述すること）」とはどういうことなのか、という点である。

SDLC のなかに断層があるので、それぞれの工程の アウトプット は、次の工程の インプット として継承するために「翻訳変換」される。「翻訳変換」するということは、システム・エンジニア の解釈（価値観）が入り込む、ということである。「属人性」の排除が叫ばれていても、SDLC の断層を認めれば、「属人性」は排除できない。したがって、システム の失敗を以下の２点が原因であると考えることは 的が外れている。

　（1） システム・エンジニアの業務知識
　（2） プロジェクト管理

プロジェクト管理と称して多量の ドキュメント を作成しても、SDLC の断層を前提にしていれば、根本的な問題点の排除にはならない。

SDLC の断層があれば、製造工程（プログラム の作成）は、前の工程を度外視しても成立する。つまり、DFD も DOA も OOA・OOD も、プログラム の作成に対して拘束力にはならない。

製造工程の前工程が製造工程に対して拘束力となるためには、「設計図」を用意しなければならない（当然のことではあるが、、、しかし、この当然のことが実現されていないのである！）。たとえば、音楽では、訓練された人々が楽譜を読めば音楽を想像できるように、設計図というのは、それを読めば、完成した システム を想像できなければならない。しかも、全体の構造を一目で見て取ることができなければならない。

コンピュータ・システム が経営に役立つことを目的として構成されるためには、事業を分析した段階で、分析図は構造を見て取ることができる設計図でなければならない。SDLC の断層を解消するためには、SDLC の最初の段階で設計図が作成され、製造工程に対して拘束力となるようにしなければならない。

どんな定型業務でも、同じやりかたを 2年も 3年も続けていたら縮小再生産に陥ってしまう。
だから、業務改善や TQC が実施される。

しかし、SDLC のそれぞれの工程を「凍結」しながら、（たとえば、1,000,000 ステップ の中規模な アプリケーション・システム を対象にすれば）SDLC が２年にも及んでしまい、システム作りの途中で、事業環境に対応するために変化を続ける実際の事業とは乖離してしまっている。

ユーザ は事業のなかで業務を改善しているのに、コンピュータ・システム が リリース されるのが２年後というのは 「現実離れ」している。逆の言いかたをすれば、 ２年前の前提に立って作られた コンピュータ・システム が今の前提に立って実施されている事業に役立つと考えるほうが非常識である。SDLC の期間と事業の周期とが乖離している。

とすれば、SDLC に対して、われわれが再検討しなければならない点は、（たとえば、1,000,000 ステップ の アプリケーション・システム を対象にするなら）事業の周期（６ヶ月）以内に作らなければならない、という点である。

SDLC を前提にして従来のやりかたを変えないならば、納期を短くするには、工程のなかの幾つかの手順を外さなければならなくなって──製造工程を外すことができないから、テスト 段階を外すとか、事業の分析を外すとか──、システム の品質が、ますます悪くなる。納期を短縮して システム の品質を高めるには、SDLC を前提にして従来のやりかたを使い続けてはいけない。

SDLC が機能していないにもかかわらず、プロジェクト管理と称して、SDLC のそれぞれの工程において多量の ドキュメント を作成することは本末転倒である。われわれが検討しなければならない点は以下の諸点である。

　（1） システム作りの期間を６ヶ月以内にする。

　（2） 最初の段階（事業分析の段階）で システム の設計図を完成する。
　　　[ 事業分析 ＝ データ正規形 ]

　（3） システム の設計図を製造工程に対して拘束力にする。
　　　[ 設計図 ＝ 製造の拘束力 ]

　（4） ソース・コード の作成を、できるかぎり、削減する。
　　　[ データ正規形 ＝ アルゴリズム のI/O 化 ]