Precautions CIOs Should Take Before Developing In-House Software

When we first started designing the ItzCash system we thought about completely outsourcing the entire development. However, as with any new concept, the requirements kept evolving and changing and the same was with ItzCash. We had submitted our specifications to a software development company for their quotation and by the time they reverted back with their estimates, our requirements and priorities had changed. Hence, we decided to go in for a homegrown system.

Typically, when we have any major development work in hand, we first do an assessment of the internal skill sets available, the implementation deadlines, efforts involved, the module on which the code will get added to and its impact on our overall system. We also broaden the requirements to take care of future requirements or to make the development more generic and configurable.

In cases where the efforts involved exceed 30 days, or a fairly standard requirement or if it’s a new module and also a limited risk of any impact on our system, we will always get a quote from a software development company. If their estimates (both in efforts and delivery dates) match with our internal assessments, then we outsource the work to it.

In case the decision to outsource has been made, the following precautions need to be taken:

1. Vendor selection criteria should include their domain expertise and reputable reference checks. The vendor should be a relatively long-term player and its client-list should be on par with the size q of your organisation.
2. A proper NDA needs to be signed with the vendor
3. CVs of critical people involved in the project need to be approved
4. Escalation and penalty clauses need to be included to minimise risks of project overruns and delivery shortfalls
5. AMC and manpower cost need to be frozen for the next two years
   For Critical Applications that are outsourced, the following things have to be kept in mind:
6. The planning and system design should be done in-house
7. The project should be divided into 2-3 parts which should be given to 2-3 parties module-wise
8. Integration of these parts into the main system should be done by internal resources
9. Complete source code should be delivered with detailed documentation
10. Timeframes for handover and knowledge transfer to internal resources should be well defined
11. Test cases should be prepared, based on all possible scenarios
12. Ethical hacking or sabotage of the system should be attempted to check the quality of the code and detect common security vulnerabilities

In case the application being developed is mission critical, then internal skill sets need to be developed within 6-12 months. If development is to be done internally, we first decide on the language to be used. In our organisation we have servers that run both ASP on Windows as well as JSP and servlets on Linux. We make the choice between the two, based on the existing source code v/s the new development, that is, if any of our existing code can be reused, to save on development time. We have on occasion, even developed the user interface on ASP, which called servlets in the background.

In cases where development is done jointly with the in-house team and a vendor, the resources of the vendor are stationed onsite at our premises and reported to our internal Project Leader. Such joint efforts typically take place when a lot of interaction with our in-house team is needed, such as for change requests or locating bugs that cannot be easily reproduced, or if we are short of resources for a particular requirement and the development involves some mission critical code.

Separate test cases are prepared internally, even if the development is outsourced. While testing the new code, both the test cases are covered. In case the development is modified or has an impact on any module, then regression testing is also done. If the development touches our main business logic code, then testing of the entire system is done along with a load test, irrespective of the nature or volume of the code changed. Any problems found during testing are classified based on the deviation from the specifications and impact on the rest of the system. The classification groups, besides the simple Pass and Fail, for the functionality checks are, None, Low, Medium, High and Critical.

Prakash Pawar, CTO And Head, HRD & Operations, Intrex, India