IDEs are passe, ADEs are in now, but they too aren't complete. There is lot many integration that had happened while moving from IDEs to ADEs, but still there is a sense of incompleteness when it comes to building an application from scratch till delivery and maintenance. If we could split up the s/w application cycle, it essentially revolves around requirements, prototypes, architectural tools, version control system, coding environment, bugzilla/db, patch & release tools, standards checkers, delivery tools. This list isn't exhaustive, but in s/w development life cycle these are essential.
In any s/w application be it based on python, perl, java, flash, C, C++, etc. the above cycle holds good. And in larger ERP or SCM or cloud applications we would have multiple development methodologies and tools co-existing to develop that entire application. In view of that the ADE should be single/multi level collaborative environment integrating all these pieces. As of now we have them as individual IDEs like requirements and prototyping could fall into one category and the product management who would be the prime owners of this space shall have their own methods/processes in documenting the requirements feeding them to development, tracking changes, prototyping the UI, etc. And this input is fed to the development by a selective set of mechanisms and from there development team takes over, creates there own set of documents, queries, technical feasibility studies, architectural guidelines, coding principles, etc in their own set of tools. Once this formalized, a summary of this representation is forwarded to the testing / QA team who then make their own set of documents, use a set of tools, log bugs for identified issues, etc., Further from here the validated QA certified code sect needs to be packaged together and a suitable patch & release testing are done. again there would be a set of different tools that would be used for this purpose. Any issues here, bugs are logged and tracked by development passing through again the QA clutches successfully and again reaches the release stage.
In all these we could see that through out the cycle at each stage a set of tool, documentation and processes/procedures are followed. Presently these stages are so disconnected that the the cycle undergoes a larger time delay in several thousand man hours while building enterprise scale s/w products. If all this are integrated there could be huge benefits that can be leveraged. Following are a few that I could think of at the moment.
- Reduction in Time Delay
- Reduction in Duplicate issues
- Better Communication between stages of development
- Better Traction from any stage to any stage within the cycle.
- Standardized procedures/processes while allowing scope for newbies
- Better visibility in terms of product completion
- Better understanding of impacts due to internal/external changes
- Lower costs of implementation
- Scalability has to be taken care
- Better in terms of replicating the model for multiple product based enterprise class development
A quick thinking on how the integration should be driven. If you could look through the cycle form requirements stage, identify the tools/ processes required for this stage along with the nature of integration it needs to do with the typical next stage in the cycle as well as any possible integrations it may require with other stages of the cycle. Integration should be loosely coupled from the push side, but rather be tightly coupled from the pull side. Alternatively a stage when passes on information / tasks/actions tom another stage should pass on as minimalistic info as possible it is for the target stage's tools and processes to ensure that they pull enough information based on the information passed onto it. This way an initiation from one stage to another can be done easily and the post initiation the next stage can pull in relevant info that it may require. This is applicable for the tools, processes and procedures that may be required for the next stage. This would avoid the infrequent round trips made in conventional methodologies.
Rather than merely packaging whole lot of tools and utilities if we could make the Application Development Environment better in terms of tagging and integrating it by purpose or ability, s/w product development can be lot more measurable & scalable with good quality.
cheerz,
Sadagopan.
