I study Software Engineering Principles

I promised to myself that I wouldn’t blog for sometime…I think I said two months but, I am bad at math and worse at keeping up promises. Actually, I have started jogging, gymming, cut down on booze and for the first time in three years done an assigment on my own. So that’s, lets see…four out of five…which is 80%. Yipee! No attendance shortage!

Now, the key to being an engineering student is the ability to copy shamelessly. Assignments, projects, test, quizzes, exams…just about anything. I mean, after all, engineers are supposed to make things simpler and copying an assignment is a lot simpler than doing it. But now and then, conscience decides to check in for work and that little caterpillar in the top had and colored suit is one major nasty pain. Mine checked in to work day-before.

There are bad subjects and there are worse subjects and then there is Software Engineering. The teacher who teaches that one is two years older than I am, slightly cute ( at any rate cuter than all the girls in my class with make up and 98% than all other women in my college). The subject is, essentially, a whole lot of ways to makes writing a program a hell of a lot more complicated than particle physics. If you can write a whole book on how a program is to be written in the vaguest of terms, then you can go ahead write one and then be cursed by students who use your book. Here…screw you Pressman.

There are four fundamental steps in the development of a software product or solution. They are, namely:
1. Software specification. It is the process of formally specifying the requirements in a structured manner in consultation with the client. In addition, it may also involve team structuring and project scheduling tasks.
2. Software development. This is the phase where the coding for the solution to be developed happens. It also focuses on issues such as system configuration and deployment situations.
3. Software verification and validation. In this phase the product is tested to see whether it does what it was meant to accomplish. This is called verification. Validation is the process of testing the product with a large range of available data and then checking the output against standard pre-computed results.
4. Software evolution. Customer needs change over time. A good software product must be adaptable to suit the needs of a client. The developer should be able to adapt it to the needs of the client, with minimal amount of change to it.

Never mind if you didn’t understand all of that. I’ll put it a little more simply, by way of a small example.
1. Client: “I want to wash my behind after I am done taking a dump.”
Tech Lead : “So…that will be…Sterilizing and disinfecting the posterior after the completion of passing stools.”
C: “No…no…I don’t use a stool, I use a Western style toilet.”
TL: “Yes, sir, but that factor will hike up the project expenditure by a factor of ten.”
C: “I have to clean my ass…do it!”

2. TL: “Now…how do we clean the ass?”
Bright Young Techie : “I know it…we use water”
TL: “Yes…excellent…extra roti at lunch for you. Note that down…WATER. This is a key focus area.”
BYT: “But saar…how do we collect it?”
TL: “Let us use a polymer container that is portable and eco-friendly … a plastic mug!”
BYT:”Saar…there is an extra one in the toilet on third floor. Shall I get it?”
TL: ”Excellent managerial thought…go get it and take another roti for this brilliant cost- effective thought”

3. TL: “Okay, team now lets see if this actually is efficient in pouring water on the rear…Drop your pants, kiddos!”
[BYTs dutifully drop their pants and TL pours the water]
TL: “Eureka…it works…”[strips naked and runs to the Project Manager’s cabin]
TL: “Sir…we have verified that the product is functioning”
PM : “Excellent…two extra rotis for you and a tomato for the rest of your team. Now validate it. Wash everyone’s ass with that for the rest of the day.”

4. C: “Oh…this is excellent! I have never seen anything like this…”
PM: “Yeah…cut the crap. Where’s the payment?”
[Two days later]
C: “We have water shortage at our site. And the desert heat is drying up all the tanks. We need some help with our asses.”
PM: “Don’t worry, we’ll get right back to you”
PM: “TL, we need to evolve our solution. The customer has a shortage of essential input.”
TL: “I ask my team to get on to it.”
TL: “Team we have a problem….No water on the client side. What do we do?”
BYT: “Saar…saar…Toilet paper!”
TL: “Excellent…you can do the verification and validation this time”
BYT: "Saar...can I just have extra roti?"

That, my dear people, is software engineering principles in a nutshell.

I worked on that till half-past four in the morning, put in a case study for good measure and found that it isn’t due for submission for another three days.

Next post: Internet Technologies and Applications to e-Commerce.