This term at Kettering I am taking Software Engineering. I’m pretty geeked about it. I was not previously aware of exactly what software engineering was. I know that the developers at my company use fancy acronyms like SDLC and PMM that don’t seem to really mean much. We have two required texts for the course: The Mythical Man-Month by Brooks and Object-Oriented and Classical Software Engineering by Schach. In the past week, I have read about 150 pages of Brooks and maybe 60 pages of Schach. The term “Software Engineering” seems to have been created because of this problem: large software projects generally run late, over-budget, and create products riddled with bugs. This can be compared with other types of engineering, which appear to have better management, design, and products. (As I am writing this, dozens of engineering failings come to mind ranging from life-ending mistakes at NASA to little things like my car having a rough idle. However, I must admit that engineered building rarely randomly collapse; Windows crashes much more often.)
Brooks concedes that an individual or team of two can write wonderful software. The problem seems to arise when a large project is needed in a short amount of time. The solution is to form a large team to build the software– which is also the source of them problem. Schach seems to implicitly agree, but I haven’t read where he admits small programs could be over-engineered.
Schach repeatedly cites a statistic that 67% of a software budget is spent on maintenance — more than all the other phases combined (requirements, analysis, design, implementation, integration, and retirement).
As I go through this information, I am trying to relate it to my work experience. (As a Kettering student, I have almost two years of fulltime work experience in my field, unlike a typical undergraduate.) Right now I’m thinking the whole software life-cycle idea is very short-sighted. Maybe things will change as I keep reading, but the life-cycle process seems to assume it is operating in a vacuum. The beginning steps are aimed at a client requesting a new software product. While my company has a large IT department, brand new software products are rarities. The only one that comes to mind was the company website created a handful of years ago. Instead of new product requests, we have transformations of existing products and integration of third-party software products. I suppose the transformations are considered maintenance. I do not know what Schach thinks of third-party software products….
Let me digress about maintenance. As I stated before, it seems that the software life-cycle is focused on just new stuff. That means new versions short of complete rewrites are considered maintenance. If we apply that to Microsoft Windows, I guess the requirements, analysis, design, implementation, and integration occurred prior to the 1985 release of version 1.0. Does anybody out there agree with me? I doubt it. From what I have learned so far (which is admittedly relatively small), the software life-cycle does not adequately account for new major versions of software. They are too big to be considered maintenance, but too small to be considered new products. This is a big hole because nearly all software is released in versions. (Some of software life-cycles discussed by Schach accomodate multiple builds of a product, but that is a much smaller scale.)
In my previous work experience, I installed a third-party critical event notification product. It was a small project but still complex; its human and automatic interfaces had to be programmed. The human interfaces involved the way the product communicated with people via pages, phone calls, and e-mails. The automatic interfaces involved how it received events from a separate problem ticket product and later updated the tickets. The problem ticket product in turn interfaced with a network management product.
So far, I don’t see how my past project fits into the world of software engineering. I certainly did not design and program a new software product. However, there were definitely elements of design, implementation, and integration involved. The three big pieces were each “completed&qout; software products (according to the life-cycle), although they all allow for much customization. If the goal of software engineering is to produce a good software product, what do you call it when the goal is to produce a good system of integrated software products? Is it business or information systems or industrial engineering? This work has the same technical demands as software engineering, but the scope is one step bigger.
One possible way to describe this scenario is simply *using* the software products. Despite some work involved in implementing the interfaces, each product was designed to interface with multiple other products after all. So far, I haven’t seen where usage fits in to the software life-cycle. Is it really a good idea to completely ignore it?