Select a category from the lists below and read relevant Success Stories. Click on one of the tags below. This list is updated regularly as we complete new projects. Some of the Stories you see here are the re-worked Lessons Learned we collect by the end of each project Iteration.

Free Hosted Continuous Integration Platform, A dedicated team of Java and PHP engineers managed by TechnoPark Corp. developed an free hosted continuous integration platform unique in its class.
published on Nov 3, 2010

Integration Testing Framework, A dedicated distributed team of PHP engineers sponsored by TechnoPark Corp. developed an open-source integration testing framework, called phpRack.
published on May 21, 2010

User acceptance testing instead of manual testing, sometimes it works, There was a difficult web 2.0 system which was estimated in 1100 staff-hours. None of the three previous software companies accepted that system due to several reasons, one of them was -- the client. He likes to test only the whole system with a detailed evaluation of each element.
published on Jul 21, 2007

Not our problem, The main target for any of our projects is the customer's success. That's why sometimes we try to take our focus away from daily project problems and look at the situation from a higher point of view. From this point we can observe wider horizons and identify problems or even risks that can affect the project objectives.
published on Feb 9, 2007

Early architecture decomposition, We're providing early architecture elaboration to identify technical risks as soon as possible. Sometimes this rule saves a lot of time and money, prevents cost losses and helps in reaching the project objectives. This is one of those stories.
published on Feb 5, 2007

Quantitative quality control, The main feature of this project was an online data-storage with a files version control for the metal company with more than 20 offices and 600 employees. The technical solution here was to use PHP+SVN tools. Since SVN is open source software and this connection might be risky, we decided to increase the amount of the component testing. Thus, we planned to find and fix 100 defects of this feature instead of estimated 50. And really, when 50 defects were found the PHP+SVN connection was not stable still. Only when more than 80 defects were fixed, was the System stable. 20 defects left were related to appearance only, and finally we accepted the project with the appropriate quality rating.
published on Nov 28, 2006

Clarification of Vague scope definition in MESSQ project, In the long lasting project MESSQ we had a vague document, describing its functionality. It did not allow us to successfully finish the project because there were great risks of inconsistencies between the document and the final software product. We decided to write a proper software specification based on software defects from the customer's point of view.
published on Nov 9, 2006

Automated deployment environment for multi-parts project, Several functional parts of third-party software with a specific deployment procedure produced great integration management problems during the customizing of a poker room project with the specific needs of a particular customer. We solved this problem by implementing an automatic building and deployment environment.
published on Dec 21, 2005

Risk mitigation approach, The software package we had as a legacy from previous coders didn't have a deployment mechanism. Manual deployment of every consecutive build could take hours. We saw this as the most critical risk. We had held a risk analysis meeting and decided to mitigate this risk by a continuous integration adjustment. The needed tools were found (Maven, nAnt) and integrated into the whole auto-deployment mechanism. It took just 5 minutes to build, test and deploy the system. Finally, this made the project successful.
published on Dec 7, 2005