Friday, December 08, 2006

A typical Indian Software Industry - A Novice view

Free lancing!!! I have done a quite a few free lancing not for money but for experiment and want to know kind of attitude "why so many software industries including giants fail to make it". So much of money, time and resource harvested are scraped in no time. I know I am amateur and a kid to do a complete market study on why this is happening. But I write this with the little amount of experience I have had in the industry.

SCRAP THE PROJECT. I find many reasoning it, to have chosen a wrong software life cycle model, framework, resource planning and stuff like that. But I personally feel the mistake is in the granular level. Most small/medium sized companies find it lazy enough to have a Quality team (here I am not talking about the testing team rather a team that checks to see if the processes are in place), Technical Document Write and failing to create awareness among the developers about the Code and the coding practice.

In an ideal scenario (waterfall model), the following process is followed

Information and system analysis: Establishing requirements for all system elements and then allocating some subset of these requirements to software. It must consider other elements like hard ware, people, environment (intranet or internet) and other factors. A study is to be made about the existing system and spruce up the process.
Software Requirement analysis: Once the above is done feasibility study is done based on the above. Then the team furnishes a document that holds the different specific recommendations for the candidate system. It also includes the personnel assignments, costs, project schedule, and target dates. System engineer ("analyst") must understand the information domain for the software, as well as required function, behavior, performance and interfacing. The essential purpose of this phase is to find the need and to define the problem that needs to be solved.
System Analyst: This phase is usually about the software technology, factors like Client/server, Architecture, Data structure, Framework and Database design is finalized. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase.
Coding (Interesting Phase): Once all the above are frozen. Knowledge transfer is done to the resources and the developers start their work. I don't think mush of the explanation is needed here as most of you must know this.
Testing: A quality testing team does rigorous testing before the end product is finalized. This testing team must be proactive and should be virtually disconnected from the development team. Ideally the development team must not interact with the testing team. Any communication should be routed through the Quality or the project lead.

And this will ensure the success of the project.

The Key word is here is Ideal. But unfortunately the word Ideal has just been in the dictionary right from the day the word was coined.

Ideally a client should know what he wants. Ideally Analysis team should do a right design and architecture. Ideally by now we should have had some SDLC Model that can guarantee success to a project. Ideally when a programmer spews an Ideal Code, where in there should be virtually no bugs in the project. Ideally if Testing team can find all the defects, then Client should be happy by now.

And I am sure most of the above is not happening. So at any point I find it pointless talking about an Ideal scenario.

So what is that we have to do in order to ensure atleast 60% satisfaction if not 100% to the client?

Any Big software giants do this. Yes, Patch work. By patch work I don't mean a patch fix. A patch fix is something that we do after the project is done and patch work is something that we do during the project in order to save the unexpected. Just as the old proverb goes "Prevention is better than cure"

And these patch work is also billed with the customer.

Remember I had already mentioned about 3 important factors in the Granular level. Let's see why and in what way they can contribute to the project.

Quality Team
Documents Writer
Programmers awareness to the Coding Style and Coding techniques

The Quality analyst must ensure that all the processes are in place. A constant code review, documentation and he has to ensure that, there is always a buffer time for the developers to relax towards the end of the project (Not for a picnic or a team outing but for developers to be available for any changes from the testing time towards the end). It's the part of the quality team to remind the developers about the unit test, a constant status update meetings. He has to keep constant check on the documents and the new functionality changes from the Client.

The Complexity lies in development process and its documentation. Alteration of the documentation during maintenance is an important problem for improvement of quality. The documentation to be evaluated is often complex and voluminous. Because of complex relationships between technical data products, planning documentation, test requirement, and different phases of development life cycle elements, this documentation is difficult to evaluate to assure that all activities have been adequately addressed. Documentation provides communication between all groups concerned with development on the one hand, and the control of project process on the other. I found the following lines in one of the websites and I think it's worth mentioning it here. 'Software in the application process must be constantly adapted and altered. The maintenance programmer usually does not have the time alteration to documentation. Often suitable tools are not available either. This causes the quality of documentation to suffer". And I truly subscribe to this.

Most developers (be it a lateral or a fresher) who are newly introduced to the code start experimenting with the code apart from their initial knowledge sharing sessions. Trial and error methods are all about it. Declaring unwanted variables and adding functions that might already exist with a different syntax. Coping a pre-existing code is usually found to be an easy alternative of creating a new page. But out of my experience, I have found it is more time consuming and is prone to bugs in the later stage. This is usually because most of us fail to alter few small keywords that later has a drastic effect. Constant unit testing has to be done after each and ever module. Feedback from the Quality team should be constantly monitored and reviewed. Most companies do code review but this practice slowly fades away towards the dead line. The 80-20 rule applies here. 80% of the issues come from 20% of the code.

Before I complete this note, I would like to mention that these are just the missing patch work that can be done in order to move one step towards the success of the project.

Again if all the above can ideally happen then the project can be a success.

0 Comments:

Post a Comment

<< Home