Software Best Practices

Hi All,

Some huge and complex softwares, such as ERP, may be customized to meet customer's requirements. The partners usually do the customizations rather than the software vendor. Unfortunately some technical and functional aspects are not well documented, thus the consultants must explore the undocumented codes and features by themselves, which is of course error prone. They could have asked the vendor but it would open so much support requests (and costs) which makes this escalation is only reserved for critical problems only.

Since the project schedule is tight, the system is huge, and the documentation is poor, it would be very painful (if not lazy) and take so much time and resources to understand all the source codes, related data, functionalities, and inter-module dependencies. Though the system is modularized, uncomplete knowledge of the module and inter-module relations would still raise fears that the customization of one feature would accidentally kill other features unknown before, that the testing scenarios are not sufficient, that the project estimation is unreliable, etc,

I know some successful software implementations of this kind, though those problems happened. But I guess it is much because of the highly skillful people involved in those implementation teams, rather than the formal implementation procedures they followed.

I might have missed some similiar discussions. But I would like to know your comments regarding the suitable methodology, approaches, or best practices (especially from design to testing phase, as well as project estimation measurement) to face this problem. Thank you!

Hi Jakarta,

I am not sure there is 'one' suitable methodology but a combination of several flavors might do the trick. My first attempt at an answer will use Grady Booch's concept of intellectual phases that derives all creative work into three parts: discovery, invention, and implementation. What you describe above suggests that discovery (what you want to do) and implementation (how to do it) are not the biggest issues, invention (how to do it) is. So, given that, then I would look to methods that emphasis risk reduction and rapid feedback in the design areas. This may lead me initially to a set of evolutionary prototypes to work with.

The complicating factor you describe is that you are working with an ERP systems. I have worked on one for some time but it used to be that it was really hard to undo a configuration. The idea that you do a prototype, find out it doesn't work, it was almost impossible to back out. Here is where if you can run it on a test sever in a virtual environment (so you can refresh it out) would be really cool. I don't know how big the system is that you are working on.