構造化手法によるソフトウェア開発自体があまり需要が無さそうな現状で、先の記事もあまり読まれていません。なのでその２は書かれないかも。
しかし、おまけです。
何故、構造化手法に興味が持たれなくなっているかという視点で話をしてみますが、これは構造化手法が説いている対象が狭い範囲での開発プロセスであるからだろうと思われます。
現実のソフトウェアのライフサイクルは、一度作ったら改良や修正のサイクルを回してある程度は使い倒すのですが、構造化手法はそのサイクルの一回を最も巧くやろうという感じになってます。
※昔はライフサイクルという視点自体あまりなじみがありませんでしたから。
そのため全ライフサイクルを通して見ると無駄があるだろうし、時間も掛かるだろうという部分が多々ある。また、ライフサイクル全体を通しての段階的な仕様のブラッシュアップというか要求のフィードバックというか、そういうプロセスを組んだ方がより効率的であるのに、局所の開発プロセスにそれを押し込んで高いレベルで実施させようとするため高コストでローンチまでのリードタイムが異様に長くなってしまったりする。
何ゆえ局所の開発プロセス（一回の構造化手法プロセス）に高いレベルの実施を求めてしまうかは、おそらくあまり状況適応的に考えずに教科書的な構造化手法の解説に従ってしまう結果なんだと思われます。局所の範囲では出来るだけ高いレベルにしたいのはもちろんなんですが、その「出来るだけ」が全ライフサイクルを見渡してその中の１サイクルに対するものとして抑えてあれば良いのですが、多くの場合はそのことを忘れて過剰に高レベルを求めてしまう。
なにしろ全ライフサイクルを通じたプロセスは、構造化手法の教科書の範囲外（より大きい範囲）の話なので、書かれてもちょっと言及するくらいでしょう。それを墨守すれば、その視点が落ちるのもむべなるかな。
逆に言えば、その辺りをしっかりおさえていれば構造化手法の適用もなんら問題ないはずなのですが、まあ多分そういう原因分析無しの失敗の歴史が長すぎたのか、不人気な手法になってしまったのでしょう。