Design: Unlock the Power of High-Level Architecture and Prototyping

When they talk about design, the first association is the user experience and the user interface design of the finished product. However, the design of the digital project implies a much more complex structure, which can conditionally be divided into three stages. Computools strives to build smart, reliable, and productive user-centered software solutions with high scalability and usability, hence, developed its own roadmap for the project design phase.

Intro to the High-Level Architecture

The first step is to select an approach and key development stack. This is carried out through an existing analysis of the goals and objectives of the project and an additional analysis of technical solutions. At the very beginning, the team takes into consideration ready-made ‘box’ solutions available on the market and built by in-house developers. It provides Computools with the opportunity to develop most efficiently, minimize the chance of occurring errors, improve the quality of product requirements, and the product itself, get a basic coverage of non-functional and transitive requirements. At this point, the cost of ready-made solutions plays an important role.

To select basic architectural patterns and tools, it is important to make several choices: determine whether it would be a monolithic application or it requires microservice infrastructure; identify vertical and horizontal scaling schemes that impose several requirements for further development; choose basic patterns of module writing, physical and logical placing topologies for key modules, critical external integrations, critical caches and queues, types of used data stores, such as relational or document-oriented databases. At this point, no final decisions are made since these aspects can be updated during the whole architecture forming stage.

Next, engineers form an application stack. During the process, they take into account restrictions and ready-made solutions support; reliability of solutions based on vendor support, and future expansion of platform capabilities; speed the solution’s vendor needs to close security issues. They also analyze some other available options, like cases of using open source solutions without vendor support issues. Despite there are additional risks in that, they can be solved by Computools’ team. One more important factor is the threshold of entry and the prevalence of the solution. Often it also influences the average cost of development. They also keep in mind the cost of the necessary infrastructure, including hosting and VPC prices, additional license costs, etc.; the development speed and quality while using this stack, and the presence of a large number of development and debugging tools.

Computools

Software Solutions

Computools is a full-service software 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 and more.

Contact us →

Creating Raw Specification and Interactive Prototype

The results obtained, in particular, the developed material, allows engineers to proceed to the development of a detailed description of the functional — a specification, that covers all user stories. Specification sections can be grouped by certain scenarios depending on the industry and application type. The specification is based on user stories that are elaborated in detail by a business analyst. The functionality is described in detail but not redundantly, including acceptance criteria and restrictions imposed on them such as speed, security, etc.

Then backlog is forming from the raw user story/cases. Stories can be detailed as part of the initial specification, but final detailing develops as a part of the sprint planning. A fully described user story contains a detailed description, functional requirements, non-functional requirements, acceptance criteria, a breakdown into subtasks to describe what needs to be done to implement the task with decomposition by type of work. In addition, the two diagrams are compiled: an activity diagram and a process diagram from the BA perspective. Within the time when the prototype and high-level architecture are created, only key stories are being built, not the whole specification. The specification is being finalized during the entire project life cycle.

In parallel with the specification, developers and UX designers build an interactive prototype to validate an early concept and confirm a common vision among Computools’s team, client, and stakeholders. A clickable prototype allows you to study the functionality of a future application or web page, visualizing the main idea. It provides capabilities for exploring new options and features in the early stages of the development process. It can be applied as a reference tool for developers, providing answers to functionality and usability issues during the development of particular widgets. Prototyping is beneficial when it comes to reducing overall development time. It is much easier and faster to make functional changes to the prototype than to an already finished product. Moreover, it can be quite costly.

At the end of this stage, engineers form the ‘Definition of Done’ based on the specification and high-level architecture.

Impact of the Build Development Process on the Prototyping

The phase of projecting also includes forming the development process following the identified requirements and interests of stakeholders. Computools adheres to three main frameworks: Scrum, Kanban, and Waterfall. Scrum perfectly fits the active development phase of medium and large projects or small projects where the client does not have a clear 100% insight into. It is also used during the final phases of broad functionalities in ready-made projects. Kanban is applied during the support and optimization phase of an already developed project. The waterfall is used for small projects (up to 2-3 months) or blocks of functionality in ready-made projects with 100% vision from the client and the team.

In case, a project needs more than twenty participants, Computools calculates the number of project teams. The process configuration for each client starts with a discussion of the necessary roles of the project participants. Key roles and their main responsibilities are determined as:

· Product Owner is in charge of forming of the high-level goals and objectives, providing the budget, management of project size and time, approving the task scope. This role is often performed on the client’s side.

· Project Manager is responsible for forming and control of the process, control of agreements, management of the budget provided by a Product Owner, team coordination, reporting to and supporting the Product Owner, solving organizational issues, and risk management.

· Business Analyst is responsible for detailing of the goals provided by the Product Owner, development of the requirements, project analysis, analysis of competitors’ technical solutions, consult the Product Owner, development of project documentation, management of the project scope, is required to give explanations to the team.

· System Architect is in charge of the development of system architecture, high-level decomposition, stack choice, ready-made solutions, and basic tool choice, analysis of the system’s technical component, technical risk management, technical consulting for the Product Owner, Business Analyst and Team Lead.

· UX designer deals with the development of project user experience, user experience analysis, prototyping, the arrangement of UX test plans, and the development of basic UI requirements.

· UI designer is engaged in the development of project design, development of style guide, development of the UI toolkit, page wireframe detailing, development of animations, and adaptive views.

· Team lead is in charge of the coordination of the development team, configuration of development processes, technical decomposition, task distribution, code review, solving of complex and difficult situations during development, and development of key system modules.

· Software Engineer deals with estimation and implementation of development tasks, which include the writing of Unit and integration tests and working with documentation.

· DevOps is responsible for the configuration of used tools, the configuration of all environment types (includes production), creation of CI and CD processes, support testing process (includes autotests), platform work control and monitoring, and configuration of third-party systems.

· QA lead is in charge of testing process configuration, verification of build quality before uploading to demo or production environments, testing plan development, QA team coordination, detection of bugs in design and specification, development of key testing documentation types, and system security testing.

· QA deals with manual testing, feature aspect testing, regression testing, system security testing, load testing, bug reports, development of test cases, and checklists and improvement suggestions.

· Auto QA is responsible for auto, e2e, API, and load test estimations and implementation.

When all roles are defined and selected for the current project, the format of work is discussed and agreed in detail, including points of getting approvals from the client’s team; the client’s role in processes (it’s usually the Product Owner) – the client is considered as a team member and a process participant; the Product Owner involvement into meetings: intro and daily meeting (both optional), meeting with Business Analyst, planning (if the client cannot attend the meeting, the PM agrees upon the scope), retrospective (optional) and demo.

Then the team proceeds to identify reporting points. The more the Product Owner is involved in the project, there will be fewer mistakes caused by inconsistency. Written reports are given every day by default and meetings with the project manager are set up whenever it’s possible. Then several approvals are held on important aspects of the processes: work format is synchronized with Business Analyst; demo formats and time are synchronized with Product Owner; the list and volume of necessary internal meetings are agreed within the team. At this stage, the ‘Definition of Done’ is created.

Next, the team configures the technological processes and interactions between roles. It is based on the company’s overall process which is optimized for the current project taking into account the requirements of team size. Configuration of work result handover formats internally within the team includes task flow, task description, bug reports, design handover, API docs formats, etc. Developers’ testing processes consist of several complex steps: unit tests planned coverage and integration tests; Then engineers define git-flow (by default feature branch), branch flow (naming, releases, etc.), automation of code analysis, code review, pull request; QA flow includes testing from the designer, smoke testing, aspect testing, designer review, regression testing (manual and autotest), release candidate testing (manual and autotest); and CI/CD – deploys flow.

At the end of the design phase, the final team guidelines are approved.
Mistakenly, the design stage is considered preparatory or preliminary in the work on the project. However, this is one of the keys and fundamental stages of the project roadmap. An integrated and thoughtful approach to this issue allows Computools’s engineers to create high-level digital software solutions, regardless of the complexity of the task.

For more information about Computools’s working process, please, read the blog. If you are interested in collaboration feel free to contact the company’s experts through email info@computools.com or the form below.