Software engineering: What is it?

In spite of many years of work by a multitude of organizations, a clear and simple standard for software engineering and management requirements and a method to assess their applicability to projects of various types and sizes remains elusive. From IEEE to CMMI to NASA's NPR 7150.2, there is no shortage of sources of information providing various types of requirements and standards for software engineering. Even a book on software project management for “dummies” approaches 400 pages. Wading through this information can dizzy the mind of even the most experienced software engineer; the newbie just trying to “do the right thing” will probably give up, open a text editor and start coding. This lack of clarity and simplicity perhaps goes a long way towards explaining why, in spite of this large body of work, there remains such an incredible variability in the knowledge and application of software engineering discipline not only from one organization to the next, but between groups within the same organization, or even between individual developers in the same group! Surely at least the basics of what should be done and why those things should be done can be conveyed in less than a novel-sized volume. There must be some timeless principles that cut across structured and object-oriented techniques, waterfall and agile methods, and CMMI and NASA standards. To properly interpret software engineering requirements and approaches and successfully (and selectively) apply them, one must first understand them at a fundamental level and how they can benefit the project. This paper will make an admittedly bold and brash attempt to boil it all down into something anyone can understand, hopefully resulting in a brief reference — a type of lens through which existing standards can be more practically viewed.