??? 04/10/12 05:39 Read: times |
#187084 - Your references aren't exactly backing your view Responding to: ???'s previous message |
Richard Erlacher said:
Many years ago, when people first were trying to recover from the notion that "software engineering" was an oxymoron, which still persists today, there were a couple of authors of systems engineering works, namely Yourdon (http://en.wikipedia.org/wiki/Edward_Yourdon) and DeMarco (http://en.wikipedia.org/wiki/Tom_DeMarco). They were both popular back in the early '80's, as they had figured out that you can't code what you haven't designed, just as you can't measure what you haven't built.
I'd suggest you pick up one or more of each of their works and do some basic research into what software engineering is. RE I suggest that maybe, just maybe, you move forward 30 years. Software engineering have moved forward. But then again, the ideas are still sane. It's just that you have this narrow view that all documentation can be written during the analysis phase and that the design phase is strictly writing code with all facts known. That is not a view backed by your references. In fact, a big part about software engineering is the required design changes as the development progresses. So much about the work on software engineering is about writing robust code and about robust methodologies for being able to transform code based on changes in requirements or design changes after practical tests. And I'm afraid that you might have missed some parts of the reason why software engineering is sometimes seen as an oxymoron. In traditional engineering, you can use a pocket calculator to compute strength, load factors, material densities, bend coefficients etc. So you can prove a design. Software can often not be proved. It can be tested, which is something completely different. But let's go the engineering route. An adjustable wrench/spanner wasn't invented as a single step - document everything first and then make one. And even if the invention is over 100 years old, there have been many iterative steps to improve on the design. How do you expect source code to reach the final form without any iterative design steps, for nontrivial problems? Or do you really think the world of software engineering only spans (or only needs) trivial problems? |