Engineer: Architect Breakthrough IT Solutions with Computools

Developing reliable IT business solutions, Computools takes an integrated approach, structuring each step and dividing it into subtasks. Over the years of successful activity, an action algorithm that guarantees the development of a high-quality product with a reasonable budget has been developed. Computools’s team can assist at any phase of software engineering to build a solid product and speed up the achievement of your goals.

Building the Team

Before starting development, a preliminary in-depth analysis of the project idea is carried out, all the stakeholders and their goals are clarified. After that, the technological stack is determined and a specification is drawn up. This integrated approach allows to start engineering a project with a clear plan of action and the first step is building a team. Computools make the initial scope based on the specification and estimate and calculate the optimal number of specialists for each role based on expectations for the completion date, taking into account the non-linear productivity increase with a linear hour number increase.

The team’s core consists of professionals who started working on the project from its early stages, i.e. Business Analytic, Architect, Team Lead, Project Manager, UX designer. Ordinary executors are pre-assembled on the project manager’s team. Executors are added according to the level of technical skills and knowledge in the domain. Depending on the project specifics and the number of executors, necessary key roles are involved. If the required number of executors is higher than the allowable level within the same team, additional teams are included in the project. Then an intro meeting is held.

Computools

Software Solutions

Computools is an IT Consulting and Custom Software Development Company that designs solutions to help companies meet the needs of tomorrow. Our clients represent a wide range of industries, including retail, finance, healthcare, consumer service, logistics and more.

Contact us →

Development Process

The next step is to carry out the iterative development phase based on the chosen management framework. The algorithm consists of iterations based on several next steps. Business Analyst specifies the story, including acceptance criteria. Team Lead and Business Analyst decompose the story and consult with an Architect if necessary. Project Manager and Team Lead allocate tasks. The Team Lead approves the estimation of tasks. Task development is carried out in accordance with git flow. By default, it is a feature/branch that includes test development. d out in accordance with git flow. By default, it is a feature/branch that includes test development. There are two methodologies used in the project. A domain driven development (DDD) – used for the architecture of logic and code. It is possible to use alternatives in a number of cases. And a test driven development (TDD) – used for the implementation of the main logic in code. For each task the team creates pull requests with static code analysis using next tools (depending on technology): JetBrain Products (in common cases), Linter (Javascript, Typescript, Dart that built using AirBNB rules), SonarQube (Java), Codesniffer or Mess Detector (PHP), ReSharper (C#), K&R (C++), Golint (Golang).

Code review and fixes consist of a few steps as well. The first one is to determine goals, like: identify logical errors in business rules, identify potential bugs and unwanted side effects, remove duplicates, eliminate complicated implementations, keep unified system structure and unified system style detect errors missed by code analyzers. There are three types of reviews applied by Computools: Team Lead review, security review, and cross-team review – done by all participants of the module development including the Team Lead. Provides higher performance but takes significantly more time. To implement this step GitHub, GitLab, and Bitbucket internal tools are used. Then feature/branch deployment is conducted. The team writes a test case into QA documentation according to task description and design mock-up. Aspect tests and fixes are also included in this algorithm.

There are several important additions, depending on the selected management framework. In the case of Scrum elaborating, decomposing and estimating tasks are carried out during sprint planning. This process allows the Product Owner to make changes for each sprint. Particular attention is paid to grouping tasks in such a way that the Product Owner gets a working project with new functionality at the end of each sprint. Sprint with active development of the new functional and sprint of the stabilization phase are admissible. It is acceptable to go with active development and stabilization sprints. It is possible for the Product Owner to increase the team size, even if it wasn’t planned at the beginning.

In the case of Kanban: elaborating, decomposing, and estimating tasks are performed right before working on them. The process’s main goal is the maximum delivery speed. The Product Owner sets the task’s priority. The Product Owner can increase the team size. even if it wasn’t planned at the beginning.

In the case of Waterfall elaborating, decomposing and estimating tasks are performed during the initial phase. Detailed task decomposition and elaboration are highly important from both the Business Analyst and Team Lead sides. If there is no similar experience, this phase may take significantly more time than in Scrum/Kanban based processes. And at the same time, it is not completely accurate. It is impossible to make significant changes until the project is finished. And they will require repeating the initial phase. To save time, tasks are grouped according to the development team’s priorities. Thus, feedback during the development is not so important, because it’s impossible to make changes. It is difficult for the Product Owner to increase the team size if it wasn’t planned at the beginning because the work schedule and estimates are already done.

Basic principles and development approaches:

· KISS (Keep it short and simple) principles to avoiding over-engineering;

· DRY (Don’t repeat yourself) principles;

· Clean Code approaches and ideas;

· industry standards, for example, AirBNB/PSR;

· OOD principles and methodologies, including SOLID;

· working with efficient tools to achieve high productivity – IDE (JetBrains IDEs, Visual Code, VisualStudio), debugger, profilers, emulators, static code analyzer, bug/task trackers (Atlassian software firstly), domain-specific tools.

· a solved problem is more important than any approach or pattern.

Work on the project is carried out in accordance with the previously defined steps and tasks. If necessary, certain adjustments may be made.

Testing and Stabilization Stage

The next stage starts with work with specifications and documentation: the sooner a bug is detected, the lower the cost of fixing it. Computools has developed a multi-level testing system to ensure high quality and stable operation of the finished product.

The specification and prototype testing are conducted first. Then testing plans and initial test cases are developed. The development team works within stories/tasks: identifying bugs in an isolated feature/branch context, allows them to quickly determine the cause. Task description analysis consists of an analysis of the completeness and clarity of the task; acceptance criteria analysis; discussion of the problem with the Business Analyst and correcting it, if necessary. The next few steps include preparation of test cases and checklists, deployment of the task on dev environment, testing in accordance with a test case design testing by QA, layout testing by UI designer. If a bug is detected, the task is returned to the developer with a detailed description: playback steps, expected result, actual result, information about the environment, additional information. In case of success, the task is moved to ‘done’.

End to end tests and additional automatic tests are implemented according to the requirements based on documentation: UI tests via selenium – main page object design pattern; API test as part of the development stack; load test – is not included in the group of tests launched automatically during the build. Automatic tests run automatically on build servers and developer local environments. The code can be merged only after passing all tests: code analysis, unit test, integration test, autotest (end to end and API).

Regression testing is carried out within the completion of the sprint, or a specific area of ​​work. The main goal is to make sure that there are no hidden bugs at the junction of the tasks or bugs arising due to the side effects of implemented tasks. Regression testing is performed in the QA environment. There is full manual testing of the build in accordance with the documentation. If a bug is detected, a task of type ‘bug’ is created in the task tracking system. The task contains the following description: name (to describe the essence of the problem concisely), code (a unique identifier of the task in the task tracker), type (blocker, critical, major, minor, trivial), priority, general description, reproducing steps (often are supplemented with screenshots or videos), environmental information (link to the environment, hardware, software, etc.), additional information (log, database dump, etc.), expected result, actual result.

The following step is a bug estimation. This process also consists of several mandatory substeps. The team conducts a bug prioritizing: current scope (cannot be postponed) and to backlog – a build can be released with them. This method is not desirable and is applied only in the case of tight deadlines. Then bug distribution and fixing are carried out, as well as, bug acceptance tests matching expected result and the actual result, additional implementation of automatic tests that track this scenario. Further, a repeated regression testing cycle takes place.

The choice of working strategy with a release candidate takes place at the stage of writing test plans and depends on the requirements for system reliability and time to market. The release candidate validation strategy consists of three types of testing. Release candidate’s testing is an analog of regression testing, taking into account the definition of done. The result is the admission of the release candidate’s uploading to staging. Staging/demo testing – testing the release candidate which received approval and was uploaded to staging/demo on a specified set of cases which allows ‘do not block efficiency. Production testing is analogous to staging/demo in a production environment.

There is also a strategy of planned Continuous Delivery (CD). The CD system is an alternative to working with release candidates. In this case, the uploading of operable functional takes place in a semi-automatic mode on schedule. The functional is considered to be operable only if it is passed by regression manual testing. Inoperable functionality is usually excluded from the build and it’s not waited to get stabilized at this time. It also includes planned production/staging testing.

The team conducts penetration testing to find system security issues. Optional types of testing can be applied as well. For example, smoke testing is used to check if the build is ready to be tested. This type of testing is rare because the standard development process implies that the build is always ready for testing. Or research tests that can include penetration testing elements, peak load tests, domain-specific elements. It is carried out with the help of specialized software to identify hidden risks and peak capabilities of the system.

There is always room for improvement. All team members can create improvement tasks during their work on the project. After tasks are created, the Business Analyst works with them additionally. This type of task does not block the build but can be done within the scope. The development team can create tasks for code stabilization and refactoring. The implementation of these tasks does not provide new functionality but can increase system stability, reduce the probability of bug emergence, and speed up development.

Following these highly organized procedures, Computools develop reliable and efficient sophisticated platforms, software suites, or end-user web or mobile apps striving to reach the client’s business goals.

If you would like to learn more about how the Computools’s team works, please, explore the case studies, also feel free to contact the company’s specialist via email info@computools.com to find out what benefits of collaboration with Computools you can get.