Usefulness of UML, SDLC and Software Engineering as a whole to software development
Posted on 2006-04-08
Hi. I am a software engineering freshman and am just beginning to learn about SE as a whole.
My question is more of a doubt about the usefulness of all these Software Engineering hoo-hah, processes etc that I am learning about.
On UML, why would it be useful if say we're writing a website that's constantly changing, and then once we make a change, we have to go back to the documentation and update the UML. It just sounds like alot of work for the software developer. And lets say if he works in a support organization where he has to do enhancements to applications, and he has like 20 odd applications under him. The enhancements are pretty simple, like just adding a field here or there. Then he'd have to update the UML diagrams for 20 of the applications, which sounds to me like its not just worth the effort!
So alot of my friends say UML is useless and no point learning it unless we have to.
Then on SDLC. I have a friend who's like championing the SDLC processes, waterfall, iterative development, rapid prototyping, etc. But would it make sense to apply it just a small computer programming project which we usually get after SE classes? Would we necessarily need to do scope documents, requirements gathering, bla bla, versus just looking at the homework problem and hack away at the keyboard?
On SE as a whole, I understand that SE is about making software development a disciplined, measurable approach to produce high quality programs, but I mean, good software isn't simply about high quality. There are cost factors and timeliness factors. Lets say I got a contract to setup a website for some company or develop their simple "employee diary" system which just requires input and output. Exploiting the fact that we're just students, they will pay USD100 for the whole thing. They give us like 2 weeks to finish it up. If I were to follow the SE processes that the lecturers have been singing about, i'd probably not be able to deliver it on-time and on-budget. That would have a more worsening impact on the company's expectations than say if we just hack some crap out, deploy it to the users and figure out the bugs later (which we can charge as maintenance fees). I mean, the users won't be able to tell what's under the hood so how crappy the code looks like doesn't matter, and the only benchmark they have to compare the crappy software is well 'nothing', so they'd obviously see some benefits of the new system me and my schoolmates hacked out. They might even go as far as praise us and give us a USD 50 bonus and call us a genius or something. And all the while I would be more puzzled when I sit in on a Software Engineering lecture about software development.
Any feedback and thoughts on this would be very helpful.