聞いたことがある方も多いと思いますが、Wikipediaでは以下の様に定義されています。 ソフトウェア工学はソフトウェアの開発・運用・保守に関して体系的・定量的にその応用を考察する分野である。 ソフトウェア工学には、設計法と生産法の二つに分類される領域がある。ソフトウェア設計法は、ソフトウェア構造を考察する領域であり、一般的にソフトウェア・アーキテクチャと呼称される。ソフトウェア生産法は、ソフトウェア開発工程を考察する領域であり、一般的にソフトウェア・プロセスと呼称される。これら二つの領域は利点と制約の面で相互関係がある。 ソフトウェア開発工程と呼ばれる技法や手順を含み、ソフトウェアの信頼性や保守性の向上を目的とする。具体的には、高度かつ安全なコンピュータのを短期間で設計するための研究などを行なう。 難易度の高いコード桁数が数百万以上になる大規模ソフトウェアの開発に焦点を当てることが多い。 要は、ソフトウェアの開発運用において品質と生産性の向上を目的とした標準化手法です。 私が使用した経験があるのは、富士通のSDEMとSAPのASAPです。 それらの解説はまた改めて議論の場を持ちたいと思いますが、上記二つのMethodはSDEMがスクラッチ開発用でASAPがパッケージ導入用です。 しかし、使用した経験から言えますが密接に関係しています。 例えば、ERP導入にアジャイルのASAPを使おうとしても、SDEMのようなウオーターフォールの素養が無いと使うことは出来ません。 良く、ウオーターフォールは古くてダメでこれからはアジャイルだ、という人がいますが、いくら急いでも肝心なチェックポイントを抑えないと失敗を早めるだけだと言う事です。 話を戻しますが、ソフトウェアの生産性と品質を向上させたら何が起こるでしょうか？ ソフトウエアの生産性と品質の向上に反対する人はいないと思いますが、生産性が向上すると、請け負った開発プロジェクトの価値を掛けた工数つまり人月でしか測れない会社は売り上げが減ります。 品質も重要ですが、運用を顧客任せにする会社にとっては優先度が落ちます。 これらがIT業界のジレンマと言えますが、ともあれ徒手空拳ではどうしようも無いので使わざるをえないと言うのが現状です。 使ってみて良いことは多くありました。 工程や成果物か標準化されると、漏れが無くなりますし、テストもバグの数等を工学的に把握できますから、感等の属人的な要素をある程度排除することが可能です。 ここまでは皆さんもお分かりだと思います。 私の経験では、国を跨ったグローバルプロジェクトの経験が多いのですが、その際に一番助かったのは、言葉が違うメンバーの間で共通のプロジェクト言語としてこれらのMthodを使うことができた事です。 最後に、これらソフトウェアエンジニアリングノ今後の課題として以下を上げたいと思います。 １，新規開発だけでなく、運用中のシステムの改善やリプレース・移行に対する方法論が必要である。 ２，ソフトウェアライフサイクル全般に対するアプローチを可能にする必要がある。 ILTLなど色々な情報もありますが、使いながら改善して行くのが近道だと思います。 ソフトウェアエンジニアリングは、一部学者のものではなく、経験や実績に裏打ちされた常に現場で使えるものであるべきです。
Comments