Заказчик отказался принимать мобильное приложение, ссылаясь на несоответствие ТЗ и критические дефекты. Разработчик считал работу выполненной и требовал оплаты.
Между заказчиком и подрядчиком возник спор по договору на разработку мобильного приложения. Заказчик отказался подписывать акт приёмки, утверждая, что приложение не соответствует техническому заданию, часть заявленных функций не работает, а на устройствах пользователей возникают сбои и аварийные завершения. Разработчик настаивал, что приложение разработано в полном объёме согласно ТЗ, работоспособно, а претензии заказчика связаны с эксплуатацией, а не с качеством продукта.
Спор осложнялся тем, что мобильное приложение работает на множестве версий операционных систем и моделей устройств, а понятия «работает» и «соответствует ТЗ» стороны трактовали по-разному. Требовалось формализовать требования ТЗ в проверяемые критерии, провести функциональное тестирование на репрезентативном наборе устройств и версий платформ, зафиксировать реализованные и нереализованные функции, воспроизвести и классифицировать дефекты по степени критичности и оценить полноту переданной поставки.
Часть функциональных требований ТЗ реализована в полном объёме, часть лишь частично, отдельные обязательные функции отсутствуют в переданной сборке.
Приложение запускается и в основных сценариях работает на части заявленных версий платформ; на ряде конфигураций воспроизводятся отказы и аварийные завершения.
Выявлены дефекты, нарушающие выполнение ключевых пользовательских сценариев, в том числе потерю данных и сбои авторизации в отдельных условиях.
Структура кода и сборочного процесса в части не соответствует распространённым инженерным практикам, что осложняет дальнейшее сопровождение.
Комплект переданных материалов и сборок не полностью соответствует составу, предусмотренному договором и ТЗ.
Требования ТЗ реализованы частично: ряд обязательных функций отсутствует или реализован не полностью. Работоспособность приложения зависит от платформы: на части конфигураций воспроизводятся отказы. Выявлены критические дефекты, нарушающие ключевые пользовательские сценарии. Качество кода и организация сборки частично не соответствуют инженерным практикам. Состав переданной поставки не в полной мере соответствует условиям договора и ТЗ.
Заключение дало сторонам объективную матрицу соответствия ТЗ и реестр подтверждённых дефектов с оценкой критичности. Это позволило обоснованно решить вопрос о приёмке и расчётах по договору и сформировать правовую позицию по спору.
Опишите ситуацию, и ведущий эксперт бесплатно оценит перспективу, сроки и стоимость.
