When I was in college, I remember reading the chapters of “Software engineering” with great admiration, not because I had foreseen its practical usage at my impending job, instead for its simple array of rectangular diagrams imprinted on each page of my official copy of charulatha publications “made-easy” book. No one could have explained the software development life cycle as crystal clear as the author of that made-easy book had. I marveled at the elegant angular diagrams and the hi-tech words it held. Then I thought, if any section of engineering could be simpler, interesting and graspable then it was this software life cycle illustration. I held this belief until I was hunted down for my first project work.
Obviously, the author had maliciously stuffed all the real world complexities behind those equally aligned boxes leaving the smooth top (our-side-faced) surface with nice and attractive words. It is perfectly excusable as his intention is to help only engineering college guys and it is not required for him to waste his care on real engineering geeks. But still I couldn’t convince me to not relate my current despair to my earlier misconception on software life cycle diagram. Because my real project life cycle is, not the simple one shown above but written below.
1)Requirement: Our client with only a vague idea of what they actually want dictated the requirements to our top honchos and techies. Our high-level technical team with vague idea of client’s requirement prepared a fuzzy summary of requirements (SOR) and much fuzzier Business design.
2)Meeting: Everyone was invited by our PM (project manager) for a project meeting . Vague SOR was discussed for client’s clear understanding. Client’s evidently misunderstood the SOR, felt happy for their own requirements and congratulated the team for their so-far hard and sincere work.
3)Analysis : Technical leads assigned the work to their low level information analyst (IA) for detail analysis of requirements. IAs apparently got confused by the requirements, asked thousand questions to their tech leads. Irritated tech leads patiently answered all the questions to convince the IAs and soon IAs prepared a half-baked Technical design.
4) Design : IA’s tried to design the changes form their own invention (Technical design) but there was no progress. IA tried again but still no progress. PM warned the IA’s for not meeting deadline. IA’s excused themselves and tired once more. But still there was no use………
Our project life cycle broke down here throwing the arrows in that diagram infinite meter away. Clear investigations showed that IA’s were not able to do coding because Technical design is wrong –> that’s because Business design is wrong–>that’s because SOR is wrong–>that’s because our Tech honchos understanding on requirements are wrong–>that’s because clients themselves are not clear with what they need.
Then we revisited STEP 1 (Requirements) and progressed all the way down to STEP 4. Again the same problem, same misunderstanding. We again revisited STEP1 and progressed all the way down to STEP4. But still there seems to be a lot of problems. Now this project is a total mess and me being one of the IA have to work on this week end (like last week) to see if we can somehow proceed to the next stage of the lifecycle.
PS – I didn’t edit the post properly due to lack of time. Please bear. I am entirely exhausted.