Today computers are becoming key elements influencing our daily lives in a number of ways. We cannot imagine several applications such as banking, financial transactions, manufacturing, defence, process control, communication etc without the use of computers in some way. Computers, per se, are dumb pieces of hardware. It is the software that gives life to them. With the near total control of our lives by computers, any malfunctioning in either the hardware or the software will lead to disastrous consequences. While it is relatively easy to ensure reliability of hardware components by stringent quality measures in the manufacturing process, the same cannot be said of software. Though software development process is still not an exact science, it is imperative that software always behaves in a predictable manner. Therefore it is necessary that software in the real world is developed through a well defined and systematic process.

A simple code and test approach may suffice in a lab or an academic situation, real world applications on the other hand require a structured and comprehensive approach. Some critical elements of real life software projects are:

Methodology : Before starting the development exercise one needs to choose between two methodologies - “Object Oriented Methodology” and “ “Procedure oriented methodology”.

Planning : All software development exercises take place against client requirements. Every client will have time, cost and other constraints. Therefore a great deal of planning needs to be done to meet these constraints.

Team effort : No piece of software in the real world is ever developed by a single individual. All large software development efforts require a team of specialists - domain experts, software experts, coding specialists, testers, hardware and networking professionals etc. While each group works on a specific aspect, no group works in isolation and there is a need for constant interaction among the team members.

Quality : A lab effort basically concentrates on meeting the functionality expected. In the real world the software, in addition to meeting the functional requirements, should meet additional quality constraints in terms of performance, security etc.

Maintenance : The life of a piece of software is really long and during this period the original development team members would certainly not be available for maintaining the package. Some others would be given the responsibility of maintaining the software. In some cases it would be a totally different organisation too.

Change management :Any real world project has to cope with change. Before making any change, its impact on all the parts of the software has to be analysed.

Lay user : In most cases the software is used by non-technical people who may not be computer savvy. Therefore the software has to be highly robust.

Documentation : Clear and unambiguous documentation is required in any real world project for a number of reasons. Client signoff will be required at various stages of the project and submission of documentation is therefore manadatory for this purpose. Once developed, the software will live for a long time and during its life it will have to be mainatained and as noted earlier there may be several occasions necessitating a change. Without design specs and well documented code, it will be impossible to do either.

Standards : To ensure that the documentation is clear and unambiguous it is necessary to follow standards. For example, there are IEEE standards for requirement specifications, design etc. Most major sofware companies have their own standards for documentation and coding and sometimes the client may specify the standards to be followed.

Reuse : In order to reduce development effort and to optimise on costs and time, reusability of code is a major consideration while developing new software. Mathematical libraries, GUIs, EJBs etc are all prime candidates for reusability.

Version Control :Since there will be many changes in the life of any software developed, keeping track of changes made is necessary. Therefore all changes and functionality have to be mapped on to a particular version. In case, for example, there is a problem with a new version, the client can roll back to an earlier version without difficulty.

       STUDENTS TESTIMONIALS   >>>