Our Methodology

Nesh’s software development methodology is lean, agile and flexible while addressing risks that come with it through test driven development and automated reviews, tests and release engineering practices.


We have adopted the best practices from the XP (eXtreme Programming) world and selectively leverage the iterative approach to releases to achieve right-first-time (RFT) delivery. The salient aspects of our approach are highlighted in the diagrams given below.


During the Analysis phase, our team of requirements experts work with clients directly onsite or over conference calls to understand key business drivers and elaborate on system requirements. The requirements are documented in Use Case form and user interface wireframes and mock-ups are shared to help clients visualize the proposed system.

Applying our Methodology


Business Analysis

Nesh has senior consultants who will work with your senior staff to understand and capture the as-is busines process to scope the system for automation. Find below example process flow diagrams from recent case studies.

Our Sample Analysis

We use tools like Balsamiq to capture the usability aspects of the proposed applications. The screen mock-ups trace back to the use cases gathered during the analysis phase.User comments, feedback and sign-off are directly provided against individual screens.


Once the mock-ups are developed, the graphical aspects such as themes, colors, icons and images for the screens are created by the UX designers. The image below shows a sample screen created from a mock-up.


The design stage involves creating object model diagrams and assessment of technology choices and cloud platforms (e.g., AWS, Google App Engine, Heroku, Spring etc) that would best meet the functional and non-functional requirements. At the time of implementation, the key mantra is “first-things-first”. During the initial release, we adopt a breadth-first approach where the priority is given to key main scenarios in each use case and subsequent iterations will focus a level deeper in each use case and continue to build on the initial releases. In the case of mobile applications and web portals, within a few weeks of starting the implementation phase of a new project, our teams upload a working build to test sites on a daily basis for user and client feedback. This greatly enhances the chances of building the right product and reducing risks with respect to usability, integration and deployment issues at a later time.

Continuous Integration Approach

At Nesh, we apply continuous integration practices when applying the Agile methodologies. Team members integrate their work frequently which ensures that new code developed gets integrated and tested regularly. Continuous Integration (CI) server (like Jenkins) works in the background and alerts the development team about the status of the build. It combines the features of Scheduling, automated build and test and feedback to the development team. The key benefit of the CI server is the constant feedback that it provides on the status of the software. Since CI detects deficiencies early on in development, defects are easier to resolve.

Scheduling: Jenkins can be scheduled to perform integration at specific times or after every change to the source control. The key advantage of the CI server is its ability to monitor changes to the source code held under revision control. Jenkins keeps polling the source control software like SVN and detects the change as soon a developer commits changes to software.

Automated Build and Test: The CI server can be configured to use automated build and test tools (such as ANT, NAnt, Nunit etc). The build and test results are published within a structured dashboard making it easy to view the status as well as the reasons for any failures.

Feedback: The CI server supports various forms of notifications like emails or RSS feeds thereby alerting the development team immediately of any test failures so that they can be corrected immediately. Developers can easily fix a bug in the code written a few minutes before compared to the code written several days ago.