Usefulness of UML, SDLC and Software Engineering as a whole to software development

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.
Thank you!
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Over 30 or more years I have had to decipher many programmers work (including my own) to debug it, to update it.  In the light of that experience one valid answer to your question is that, after 6 months of having written a routine, even the author will often scratch their head for a while before understanding why something was written the way it was.  The bigger the code being examined, the longer it will take, the more chances that the original reasons for doing something are misunderstood, which results in new bugs in the updated code.  

One of the holy grails of SE is the ability to write Documentation and to produce the code directly from that.  Ideally one should never have to touch code, only documentation.  As someone who has written programs in languages ranging from Assembler to RAD languages I can see that things are getting closer to that goal, but there's still a long way to go.
On your other point.  Arguably most money in software development is spent after the software is commissioned.  The more time that is spent on getting things right before a single line of code is written, the better the chances that the software will not become a major long-term burden for the developers.  

The trouble with a lot of software is that is built on shaky foundations which continue to haunt the developers years after the software is released.  But wait, you can't rip out the whole thing and start again.  Microsoft still has the legacy of DOS to contend with all these decades later because people still use it.  Nothing wrong with DOS these days, apart from it's inherent limitations, but let's look now at Windows XP.  The developers left many Boundary Conditions unchecked and look at the ongoing aggro that is still causing, to this day.  

Do not be pressured into accepting tight deadlines.  If the job is to be done poroperly, there are no shortcuts.
When I was at college we were encouraged to show our "working out" on the exam paper.  No point in sticking down just the answer they'd say: if you made a teensy mistake: no marks.  However, showing your working out will get you 90% of the mark if in the heat of the moment 1+1=3.

I'm surprised if your lecturers are encouraging you to do a project which just shows the answers??

>Maintenance fees
Tut tut.  I take it your comment was tongue in cheek, but would you keep taking your car to the same garage if it (the car, and the garage lol) kept developing faults?  There comes a point where you will sell it and buy something else.
PMI ACP® Project Management

Prepare for the PMI Agile Certified Practitioner (PMI-ACP)® exam, which formally recognizes your knowledge of agile principles and your skill with agile techniques.

AphroditusAuthor Commented:
Thanks for the feedback and advice moorhouselondon.

Its interesting that I just read about code generation from UML diagrams before reading your comment about programming someday would be from documentation or simply from providing the machine diagrams. I think that would be very cool, ie doing programming using diagrams which we can easily visualize in our head to solve a problem, instead of today's cryptic text in a variety of programming languages. I mean, people used to use DOS or even before that, bash shells on Unix systems and the next step for that is the graphical user interface and the mouse. Don't you think so?

On showing the "working out" on exam paper, my lecturers aren't encouraging us to just show the answers. We are required to give a presentation on the project, but little emphasis is given to the process we followed and more on the obvious results. The general mentality is that if the results are right, the process must be right as well which I have learnt isn't the case. Same goes to the right process giving the wrong results.

Good point on the maintenance fees. But yep, I had a friend who's working in a multinational company doing maintenance who's advise was to not give a perfect product, but leave bugs and document them as 'difficult problems introduced by changing business requirements to be fixed in the next maintenance release' lest we want to work ourselves out of a job.

Hello Aphroditus,

First of all I would like to say, this is a very good question in terms of Software Engineering. I'm on the concept of applying SE in small projects. SE is often said as aimed to large contract based projects. Now our related issue is how the discipline can be implemented for development being done by small groups or individuals. The standard Software Engineering models used by so-called big companies differs from rather small companies or group.

In this concern I would like to name WISDOM. Are u aware of this? Anyways WISDOM stands for Whitewater Interactive System Development with Object Models. This a Software Development Model that can be used for small & low scale based projects. This process has 3 main components –

[1] PROCESS:- A software process based on user-centered, evolutionary, and rapid-prototyping model.

[2] CONCEPTUAL MODELLING:- A set of conceptual modeling notations that support the modeling of functional and nonfunctional components.

[3] PROJECT MANAGEMENT:- A project management philosophy based on tool usage standards and open documentation.

WISDOM is also comprised of 3 main workflows-


Read more about WISDOM:~

Hope this helps

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
One point I forgot to mention that the WISDOM model is completely based upon UML modelling. So UML can be applied easily with the mentioned model.

In my view the trouble with evolutionary/just do it approach with software is where backtracking due to a wrong assumption early in the design phase.  I often sell my services on the point that in-house development of databases is fraught with problems if the simple group of tables that the client says they want sprouts other tables in unenvisaged ways.  The Just Do It approach seems to work well with websites where it is customary for ad hoc changes to be made, but you still have problems when people click on out of date links - some websites let users flounder in such cases, others feel duty bound to maintain the links to updated pages, which brings us back to the legacy problem again.

To a certain extent I like the idea of evolutionary design in the sense that you have long discussions with a client about the "scope" of their project.  Once this is established, there can be leeway to take things in various directions in much the same way that a musician who specialises in improvisation will start off with a musical framework which is designed to be moulded according to their mood "on the night".

Maybe there are ways that Wisdom can recover from taking the wrong fork.  I would have thought though that such a mechanism would involve extra resources in documenting and recoding.
I disagree whith quite few points. first there is not a one-way ticket from Model to Implementation. And the code changes over time so whatver happens the original design and the actual code to drift apart.

Now if you write such a miserable code that you can not understand it ins some weeks, then you should change you attitude and try harder to write better code. Code quality matters and it matters nearly the most of all (even if everyone seems to disagree about that). In the end just the code which gets compiled is the program.

An UML diagram just a sheet of paper and it's easy to make it look "fine". But how can you check? So in the end UML fall in the category of "statistics", and you know there are lies, damn lies and statistics.

Unfortunatly the attitude towards programming is that it does not matter and that everyone can do it if the design is good enough. Well how could it be then that so many project fail? This is especially a point which has driven me away from ACM, the "pretend" that software writing is a known art and that it's easy, but well the do not show their code. I guess they don't for  a reason.

I just do not one programmer which does get all the things right from the beginning. So if you are not prepared to rethink about the things you are doing and if you are not willing to make your hands dirty, and redesign you stuff you whole undertakings will be pointless.

However I agree it can be difficult to get into some code and this is especially true if it's code not written by you, but this is often a problem if the programmers are
1) either treated as code monkeys
2) do not bother to write good code

I've seen to much of 2) and I fully disagree with that attitude. However it seems getting things done in some way is more important then try to do it "right".

Now I'm not as long in the business as this 30 year veteran, so he has some extra points but in the end he must have understand the code to change things.

Now I do not say that a higher level is bad, but it's just one part and to much things can go wrong down the line. The right thing IMHO is starting small implement a working design, it does not have to do anything useful, but it has to do something.
You can discuss it internally or with you customer, after a few rounds you have a much better understanding on how things might work.

Then you step back and see the shortcoming and you start implementing things which solve one task at hand, you try you best to make this parts testable stand-alone, and you do your best you build a stable interface between this components.

I think one of the really large problems in software development is that you have you System Analyser, some Designer, and a lot of programmers. On every bound information get's lost is modified and in the end the programmers implement something they think the Designer meant to have and this Designers have implemented a design which they thought the Analyser has meant.

The right thing IMHO is not doing it that way. One should take a small group of people and let them work on it from start to the end. They are not allowed to bail out after Analysis or Design they have to go through all the phases. From start till actually having it run in the wild.

However that might frighten managers like hell and so it's not done. The do like to believe in Snake Oil. Another consultant comes away which is though to be much smarter, they introduce the newest hype of the day and away they are...


AphroditusAuthor Commented:
MilanKM, thanks for sharing your WISDOM. I find the techniques there useful. I do have some questions and doubts which I hope can be answered.

1. Are there measurable results or real-world implementations of Wisdom?

2. There are situations where users require detailed complex logic changes to the user interface which will be messy to be modelled in UML.
For example, when the name is being entered into the field, the system should validate validate the user roles and tailor certain fields for the user and change the behaviour of the user-interface to suit that particular user. Since WISDOM uses UML as the base in alot of its activities, a strict adherence to the UML is necessary as developers would use it to translate design to implementation. This creates the problem of over-documentation as the UML would become complex and hard to comprehend from first glance. I would imagine developers being late for their developer meetings because they're too busy printing pages of UML.

3. Another point is that the UML2 standard doesn't cater for some circumstances in design, and different architects would sometimes use their own notations or borrow from UML1. This exacerbates the problem of the UML diagrams becoming too complex to be beneficial.

4. Could you provide or direct us to more examples of how WISDOM is actually being used, from the start of a project till the end? It would be great to have a solid example to draw best-practices upon.

Other than these points, WISDOM seems to me as a more organized approach to software development compared to the Nike just-do-it way and it is tailored for smalled projects/software developments.

AphroditusAuthor Commented:

Thanks for your perspective on the topic.

On the matter of code quality, I still have this thought especially for business applications that it would only matter depending on the project (expected life-time, frequency of use, impact to the business, etc). With respect to moorhouselondon's point on doing it right anyway, I still don't see a point in spending too much time on making sure the code is flexible, extensible, scalable and optimal if it is going to be used just once, which sadly in my case would be until it gets handed up or presented to the lecturer. It'd be great if you could refute this way of thinking.

I believe writing bad code and still get management or user praise and approval happens all the time. Can this be considered as some form of art(or con)?
Of course, techniques like WISDOM would help with ensuring user expectations are translated. I'm thinking along the lines of what matters most to the users which most often isn't about the code (unless the users are developers or technical experts).

Hopefully from yours and posts from other experts I will be able to change my perspective and start writing better code and following through on the analysis and design with my other college mates (who'd probably waste the spare time on computer gaming anyway).

Thanks. Any other thoughts on the topic would be helpful.

First of all thanks as WISDOM may solve your problem. See the following link, I think it will answer all your questions above and also consists of a real world example of "Hotel Reservations System"

Hope u got it
Here I can provide you a new idea. It just my own modification done over the Waterfall Model so that it can be used for small projects as well. The modified version of waterfall model as described below.

The waterfall model is actually for those software where software is a part of a large system. In this very model documents are the most important part in each phases and a phase is incomplete till it is properly documented & checked by SQA group. Modifying the Waterfall Model, so that it can be used with small software projects, that increases in complexity over time. Here I’ve documented some modifications for Waterfall Model according to my own views, so that it can be used for small projects.

Modifications Done
1] As the waterfall model describes the team structure that controlled by a centralized team. Where a top-level problem solving and internal team co-ordination often managed by a team leader. As a document driven model, a SQA team & finally a debugging & testing team is required.

According to me the team structure should be Democratic Decentralized (DD). As DD team does not has a particular or permanent team leader. The group should divide into several teams for a specific job.

2] In Waterfall model every documents are passed to a SQA group. In my modified model, the documentation will be created in a team & frequent meeting will be held after competition of each phase, during this meeting document will be reviewed thoroughly & a final decision will be made.

This will decrease the cost of SQA group & eliminate the time of re-documentation problem.

3] In my modified model, requirement & specification phase will be merged into one single phase. The requirement analysis will be held in presence of customer group & a final decision will be taken.

4] Right after the previous phase, the design phase will be started.

5] After a successful designing phase, the coding & testing team will be made with existing persons. Right after a beta release will be made.

With all these I'll also suggest you to take a look @ the Incremental Model. You can also take it in you own way. Just do some modification as above or anything you think would be better for that.

All the best
Hey Aphroditus,

The modified Waterfall Model may not fit your kind of problem. Just given for informational purpose. So, what about the previous link? Have u got those question answered?

Doing it right.

Trouble with not doing it right in the one-off situation of "deceiving" a college lecturer, is that there may be the temptation to extend that into industrial experience.  If you were a "first time employee" who goes to work for an employer who doesn't go to great lengths to check your work (many big companies go to great lengths to make sure that you don't put "Easter Eggs" and "back doors" in their products), then there is going to be the thought that a short-cut can be taken which nobody will find out about.  Just think that code you write might end up in an aeroplane or air traffic control system.  Now would you be sweating if you found that the aeroplane you might one day board has your software directly or indirectly embedded in it?  Unlikely?  Extreme example maybe, but how many times in your life are you going to curse someone for taking short-cuts when writing their software?  You need to set a good example to your peers and do things by the book, and to tell them to do so too.  If they are inspired by this short-cut method of achieving results, and they go into writing systems for an aerospace manufacturer, are you going to sweat if you find that out??  

Ok, an analogy.  You are in a supermarket.  You have a basket full of food.  You are a boracic# student.  You see an open door to the carpark which you know is not being checked, you know you can get away with it.  Do you take the "short cut"?  Or do you go to the check out?  Answer that and think of your reasoning, and apply it to this question.

AphroditusAuthor Commented:

The waterfall model modifications is useful. I can see how to use it in my current assignment (to create sorting and searching algorithm demonstration suites). I'll replace the customer group with the lecturer and go from there. WISDOM uses UML which I'm still learning, so I will study it again once I grasp the UML concepts and practice on it.

For the 4th question, I was hoping for examples other than the hotel reservation system cited in your journal paper to get a better look at how people are using WISDOM to their advantage. But if there are none currently documented, then it is alright.

My other questions have been answered. Thanks.
AphroditusAuthor Commented:

I get it now. Good thing I didn't stick to taking shortcuts and being a 'wise-guy' for too long. I take that you mean doing it the wrong way all the time and taking short-cuts may develop into a form of bad habit for graduates.

Thanks for the advice!
AphroditusAuthor Commented:
I will leave this question open for feedback for a few days.
Well the problem is that code has the feature  that is simply stays. It changes over time but it stays. Every UML diagram will sooner or later be thrown in the garbage.

Telling that the code may just be used once is a meager excuse for writing bad code.


Considering your career lies in Software Development I would definately reccomend practicing / learning / developing your skills in both UML and the various SDLC methodologies. Using them in your own small projects may seem like overkill and probably is. I'd reccomend using various portions of both in order to build up your skillset.

Employers will ask for both UML and what methodologies you have practiced, and having practiced these skills (and having examples) will put you in good stead.

Good luck

AphroditusAuthor Commented:
Thanks Snoopstaa.

After exhaustive questioning of some of the people working in software development, I found that alot of them do not really follow the strict UML rules and standards as proposed by the OMG. Seems that UML2 dropped some notations from the original UML and added other new ones and software development teams don't really bother with updating the diagrams as it doesn't give them any benefit. Besides, the team is already familiar with UML1 and they even introduced their own non-normative diagrams.

But as you said, it is always useful to know UML and the SDLC concepts. I've been reading about agile development and it seems rather promising, could borrow a good practice or two from there and apply it on my school projects. :)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Programming Theory

From novice to tech pro — start learning today.