Welcome to ICS
 lang English

ICT Solutions for NGOs

Innovation Consulting & Solutions specializes in designing software solutions for NGOs using AI & cutting-edge technologies. Our Company provides services in artificial intelligence, data analysis, and web/mobile development. Furthermore, we offer a wide range of pre-designed ICT products that are carefully designed to fulfill the needs of NGOs (check our ICT products).

We take the protection of our client’s data very seriously; thus we treat their data confidentiality and in accordance with data protection regulations.

Our methodology

We follow Agile Methodology, specifically the Scrum framework for software development. We have adopted Test Driven Development and Continuous Integration among the different agile practices.

Step 1: PRODUCT BACKLOG CREATION Before any project work begins. We create a product backlog. It replaces the traditional requirements specification artefacts. This is essentially a list of the goals that need to be achieved to create a finished product.

Step2 SPRINT PLANNING - SPRINT BACKLOG CREATION: A sprint is an iteration, a time-boxed effort in which we produce a specified working software. During a sprint planning session, we set a sprint goal and create a sprint backlog from the product backlog.

Step 3: SPRINT PLANNING - TASKS DENOMINATION In the second part of the Sprint planning session, we break down the stories in sprint backlog into tasks that can be tracked easily. The tasks are then checked for dependencies, and the required time is estimated.

Step4: WORKING ON THE SPRINT This is a time where the actual coding, testing, UI designing, technical writeups etc. are performed. We stand for 5-minutes daily scrum meetings to sync everyone with the latest development, improve communications, eliminate other meetings and identify impediments to development for removal, highlight and promote quick decision-making.

Step5: TESTING AND DEBUGGING This is not a separate phase at the end of coding as done typically. Instead, it is done inside the sprint. When the stories are ready for review, they are tested according to the acceptance criteria of the stories.

Step 6: SPRINT REVIEW, RETROSPECTIVE At the end of the sprint, we hold a sprint review session where every - one is involved. In the session, the work is demonstrated.

Our Quality assurance procedures


Quality Assurance is a crucial aspect of every software project, and our company is a commitment to cutting-edge software with high-quality standards. Thus we have established our own QA framework. The proposed framework has five different stages; the following figures explain this in more detail:

Our QA process starts with the project’s kick-off. The QA expert will start to work in parallel with the SRS (Software Requirements Specifications) documentation. He checks the requirements for:

  • completeness
  • redundancies
  • clarity
  • consistency
  • executability
  • executability

When the SRS document is finalised, the “test cases plan” is going to be created. This involves describing the required actions that we need to perform in order to make sure that every piece of the software functions as planned.

After finishing the development, the proposed “test cases plan” will be executed. The main goal of this stage is to check whether the solution is developed properly from the technical perspective and meets the initial product owner’s requirements.

Furthermore, these steps involve different types of testing like ( security testing, integration testing and stress testing).

When a bug is discovered, it will be recorded into our racking system which is also a project management system. For this purpose, we use Team Foundation Server (TFS). TFS enables easy tracking of issues of any level, from a broken login form to security problems, and all team members can see real-time task updates. This simplifies communication inside the team and helps keep a clear overview of the improvement process.

When a developer fixes an issue he/she informs the responsible QA expert, who verify it. The ticket in the bug tracking system is closed when no issue is detected. This rule applies: no bug can be marked as fixed until it is verified.

Do You Need Our IT Solutions? Get Advice From Our Professionals.