Декомпозиция программы что это

Декомпозиция в программировании

Способ управления сложными системами известен уже очень давно, еще со времен Древнего Рима – divide et impera (разделяй и властвуй). При проектировании сложной программной системы необходимо ее разделять на все меньшие и меньшие подсистемы, каждую из которых можно создать и совершенствовать независимо, – вот первый шаг в борьбе со сложностью.

Существует два основных способа проектирования программных систем – структурное проектирование, основанное на алгоритмической декомпозиции, и объектно-ориентированное проектирование, основанное на объектно-ориентированной декомпозиции. Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое значение агентам, которые являются либо объектами, либо субъектами действия. Однако эти способы, по сути, ортогональны, поэтому нельзя сконструировать сложную систему одновременно двумя способами. Необходимо начать разделение системы либо по алгоритмам, либо по объектам, а затем, используя полученную структуру, попытаться рассмотреть проблему с другой точки зрения.

Декомпозиция предметной области (на примере магазина)

Алгоритмическую декомпозицию можно представить как обычное разделение алгоритмов, где каждый модуль системы выполняет один из этапов общего процесса. При объектно-ориентированной декомпозиции каждый объект обладает своим собственным поведением, и каждый из них моделирует некоторый объект реального мира. Объект является реальным или виртуальным элементом, который несёт в себе описание данных и действия над этими данными. С этой точки зрения объект является вполне осязаемой вещью, которая демонстрирует вполне определенное поведение. Объекты что-то делают, и мы можем, послав им сообщение, попросить их выполнить некоторые операции.

Что лучше: алгоритмическая или объектная декомпозиция? Ответ – обе хороши (или недостаточно хороши). Разделяя алгоритмы, мы концентрируем внимание на порядке действий, разделяя по объектам, мы концентрируемся на агентах, являющихся или объектами, или субъектами действий.

Объектная декомпозиция имеет несколько преимуществ перед алгоритмической:

· объектная декомпозиция уменьшает размер программных систем за счет повторного использования общих механизмов, что приводит к существенной экономии выразительных средств;

· объектно-ориентированные системы более гибки и проще эволюционируют со временем, потому что их схемы базируется на устойчивых промежуточных формах. Действительно, объектная декомпозиция существенно снижает риск при создании сложной программной системы, так как она развивается из меньших систем, в которых мы уже уверены;

· объектная декомпозиция помогает нам разобраться в сложной программной системе, предлагая нам разумные решения относительно выбора подпространства большого пространства состояний.

Абстракция

У человека есть средство, позволяющее бороться со сложностью, задолго до появления первых компьютеров. Люди абстрагировались от сложности. Не имея возможности объять необъятное, они игнорировали мелкие и не важные детали, сосредоточив свое внимание на основных, ключевых моментах. Мы пытаемся создать некую обобщенную модель действительности. Объекты, полученные в результате декомпозиции, представляют собой абстракции реального мира.

ДЕКОМПОЗИЦИЯ. Как решать большие задачи эффективно.

Объект — это не сами предметы реального мира, а их абстракция (мысленное представление). Но эта абстракция характеризует любой предмет реального мира. Объект — это любое «кто?» или «что?» вне зависимости от их материального или абстрактного содержания. Объект – абстракция множества предметов реального мира, такая что

· все предметы в этом множестве имеют один и тот же набор характеристик;

· все предметы подчинены и согласовываются с одним и тем же набором правил, нормами поведения, законами природы.

Абстракция – описание объекта, изложение явления, при котором одни свойства и детали выделяются, а другие опускаются. Программист в зависимости от задачи выбирает тот или иной уровень абстракции. Хорошей является абстракция, которая подчеркивает детали, существенные для рассмотрения и использования, те детали, которые отличают объект от других объектов, определяет его концептуальные границы, и опускает на данный момент несущественные. Как видите, абстракция — один из главных методов, используемых при решении сложных задач для борьбы со сложностью.

Абстракция подразумевает собой процесс изменения уровня детализации программы. Когда мы абстрагируемся от проблемы, мы предполагаем игнорирование ряда подробностей с тем, чтобы свести задачу к более простой.

После чего декомпозиция такой задачи окажется более простой по сравнению с исходной.

Иерархия

Мы можем рассматривать каждый объект как отдельный элемент, обладающий своей собственной моделью поведения. Но зачем? Многие объекты имеют общее поведение или похожее на поведение других объектов. Разделив объекты на группы, выделив наиболее общую модель поведения и оставляя специализированное поведение на некоторые выделенные объекты, мы сформируем иерархию объектов, что значительно упрощает понимание сложной системы.

Модульность

Модульность – это свойство программной системы, которая была разделена на связные и слабо зацепленные между собой модули, реализующие заданные абстракции разрабатываемой системы. Модульность упрощает задачу объединяя логически связанные абстракции в группы. Модуль – это единица кода, служащая строительным блоком физической структуры системы; программный блок, который содержит объявления, выраженные в соответствие с требованиями языка и образующие физическую реализацию части или всех классов и объектов логического проекта системы. Как правило, модуль состоит из интерфейсной части и реализации.

Модули разрабатываются отдельно, но при сборке между ними легко могут быть установлены связи. Это позволяет собирать программы из модулей. Со временем практическое программирование позволяет накопить большое количество разнообразных модулей, из которых программист может быстро собирать программу.

Отдельные модули уже протестированы и отлажены многократным использованием в различных проектах. Не нужно одно и то же разрабатывать по несколько раз. Кроме своих модулей, программист может использовать модули своих коллег или различных библиотек.

Т.о. модульность способствует сокращению времени разработки и повторному использованию кода, работе в команде. Модульность дополняет абстракцию и инкапсуляцию в процессе практической реализации.

Дата добавления: 2020-01-07 ; просмотров: 478 ; Мы поможем в написании вашей работы!

Источник: studopedia.net

Декомпозиция в разработке мобильных приложений, полезные техники и примеры из практики

Декомпозиция — это деление целого на части, или научный метод, использующий структуру задачи и позволяющий заменить решение одной большой задачи решением серии меньших задач, пусть и взаимосвязанных, но более простых.

1157 просмотров
Для чего нужна декомпозиция

• Для решения сложных задач. Решение сложной задачи заменяем решением нескольких простых задач. Декомпозиция позволяет привести сложную задачу до понятной структуры, которую можно реализовать. Декомпозиция в этом случае позволяет справиться и с прокрастинацией, когда мы встречаемся со сложным вопросом и не занимаемся ее решением по совершенно объективным причинам: мы уверены, что все завалим и даже не беремся за рассмотрение.
• Для оценки ресурсов. Декомпозиция позволяет оценить ресурсы на задачу: время, деньги и т. д.
• Для оценки реалистичности. Задача может быть со временными ограничениями, финансовыми, прочими блокировками. Декомпозировав задачу, можем выбросить нереальные блокировки.
• Для расстановки приоритетов и делегирования. Здесь мы можем обозначить приоритеты и что-то делегировать. Все это поможет выполнить задачу быстрее.

Правила декомпозирования

1. Разбиваем систему по уровням. Исходная система располагается на нулевом уровне. После её разбиения получаются подсистемы первого уровня. Разбиение этих подсистем или некоторых из них приводит к появлению подсистем второго уровня и т. д. Для обозримости рекомендуют выделять на каждом уровне не более 7 подсистем. Это связано с особенностями человеческого мозга: именно столько элементов человек может удержать в памяти.

2. Недопустимо, чтобы одной из подсистем являлась сама система, так как получаем закольцовывание логики.

3. При декомпозиции текущего уровня не нужно думать про следующие уровни.

4. Разбиение должно происходить только по одному, постоянному для всех уровней признаку. Это важный момент.

Разбиение может происходить:

-по типам платформ — mobile, ios, back, front, web.

-по этапам/фазам бизнес-процесса.

-по позитивным/негативным сценариям.

-по списку требований. В первом сценарии реализуем одно требование, во втором — второе и т. п. Цель — сделать число целей каждой задачи минимальным (в идеале, по одному).

-горизонтальная/вертикальная декомпозиция. Горизонтальная — задачи декомпозируются по типу работы, которую необходимо выполнить. Здесь нужно задействовать back, web, front и т. д. Фактически каждая из частей не приводит к конечному результату сама по себе. Для готового функционала необходима реализация всей совокупности связанных задач всеми участниками процесса.

Вертикальная — выделение более мелких задач, фич, функций таким образом, что каждая такая пользовательская история может быть реализована и выпущена отдельно от остальных задач. На таком подходе основывается создание «продуктовой команды», когда эксперты разных направлений группируются по типам задач.

До какого уровня декомпозировать?

Обычно в качестве нижнего (элементарного) уровня подсистем берут такой, на котором располагаются подсистемы, понимание устройства которых или их описание доступно исполнителю, руководителю группы или отдельному человеку. Иерархическая структура ориентирована всегда субъективно и зависит от команды: для более квалифицированного специалиста она будет менее подробна. Чем ниже уровень команды, тем более подробной должна быть декомпозиция.

Для понятия глубины нам важно найти баланс: декомпозиция не должна быть слишком подробной, но и не слишком обобщенной.

Полезные техники

1. Vague Terms, или «неточная формулировка». Если задача сформулирована расплывчато, мы можем постепенно уточнять формулировку. Появляющиеся уточнения и будут элементами декомпозиции. Как это можно использовать на практике, подробно обсуждается здесь.

2. Conjunctions, или «союз». В User-story мы выражаем мысли с помощью союзов “и, при условии, или, когда” и т. д. Если поделим user-story по этим союзам, то получим декомпозированную задачу. В этом отрывке данная техника рассматривается на реальном примере.

Что еще важно учесть

1. Текущие внешние связи. Понять, какие внешние связи уже есть с системой. Система состоит из частей, которые между собой взаимодействуют, а также обменивается с другими системами (в том числе с пользователем, с ОС, если это приложение, внешние интеграции и т. д.). Любая связь нашего модуля и внешнего (нашей задачи) — это потенциально отдельная задача. Именно на связях находятся основные риски.

2. Будущие внешние связи. Это те связи, которые появятся с другими системами.

3. Пользовательские истории. Понять, какие пользовательские истории затрагиваются нашими изменениями, а какие добавляются. Каждая пользовательская история — это потенциально отдельная подзадача.

4. Положительные и негативные сценарии. Пользовательские истории делим на положительные/отрицательные сценарии.

5. Нефункциональные требования. Это требования, которые не относятся непосредственно к функциональности приложения, но предъявляются к нему (требования к версии ОС, типам устройств для мобильных приложений, версиям браузеров, железа, внутренние требования к процессам (долгое ревью, тщательное тестирование, соблюдение архитектуры, работа с техдолгом и т. д.). Не технические требования: требования законодательства, специфические требования заказчика (например, тестовый сервер через VPN), аудит и т. д.

Надо всегда помнить, что состав задачи — это не только кодинг, но и риски, кодревью, затраты на прием, тестирование и управление.

Что делать, если для декомпозиции не хватает знаний, если много зависимостей, блокировок? Отдельные решения этих вопросов можно найти по ссылке.

Источник: vc.ru

Декомпозиция задач: что это и зачем нужно

Приходит маркетолог интернет-магазина к разработчику с задачей:

• добавить на страницу товара счётчик, сколько раз его купили.

Для маркетолога это одна строчка текста. Он думает, что такую простую задачку можно сделать за 15 минут. А разработчик пожимает плечами: «Подумаю, потом назову срок». Что за дичь? А вот так.

Прежде чем эту задачу делать, её было бы неплохо декомпозировать — то есть понять, из чего она состоит, на что влияет и в каком порядке её стоит делать. В случае со счётчиком покупок это получится такой набор подзадач:

• Добавить в базу товаров столбец с количеством покупок.
• Написать новый или доработать старый метод для АПИ, чтобы сайт получал значение из этого столбца.
• Добавить строку текста на страницу товара.
• Протестировать метод и вёрстку.
• Подумать, что делать с редкими случаями, например, товар купили, а потом вернули; или если товар суперпопулярный и его купили 9999999999999999 раз.

В зависимости от архитектуры системы могут быть и другие действия. Поэтому назвать срок сразу разработчик не может: сначала надо понять, что вообще нужно делать и сколько времени займёт каждый пункт.

Чем крупнее задача, тем сложнее обойтись без декомпозиции. «Покрасить кнопку в красный» можно не раскладывать. А «Добавить новый раздел в админку» точно стоит сначала разобрать по частям: тут работа и для фронтенда, и для бэкенда. Декомпозиция нужна не всегда, но очень часто.

Зачем декомпозировать

Понять, что и в каком порядке делать. «Добавить счётчик на страницу» кажется задачей для фронтенд-разработчика. Но на самом деле он сможет сделать свою часть, только когда будет готова база данных и АПИ — механизм, по которому эти данные подтягиваются на сайт.

Если фронтенд попробует сам предположить, как будет выглядеть запрос, то после интеграции могут всплыть непредвиденные баги: бэкенд мог реализовать АПИ не так, как думал фронтенд-разработчик. Декомпозиция поможет понять, с какой стороны подступиться и в какой последовательности двигаться.

Оценить сроки. Когда задача разложена на части, можно оценить по времени каждую и понять, сколько потребуется на всё вместе. Понятно, что не получится запустить счётчик за день, если только на базу данных и АПИ нужно два.

Упростить тестирование. Тестировать проще, когда понятно, что нужно проверить. В случае со счётчиком: базу данных, метод и вёрстку.

Расставить приоритеты. Декомпозиция может показать, что задача большая и требует времени. Например, если маркетолог хочет указать не только количество покупок, но и количество городов, в которые товар доставляли. Разработчик может показать, что делать всё вместе — две недели, но счётчик покупок можно выкатить быстрее. А маркетолог уже решит, как лучше поступить.

Как декомпозировать

Декомпозировать можно по-разному, это зависит от масштаба и сути задачи.

Например, запуск мобильного приложения можно декомпозировать сначала на уровне платформ: iOS и Android. Потом — на уровне пользовательских сценариев: регистрация, просмотр контента, покупка, переписка с контактами. Сценарии можно разложить на интерфейс и серверную часть. А их — на отдельные конкретные задачи.

Чаще всего задачи раскладывают вертикально и горизонтально. Вертикально — значит по типам работ. Горизонтально — значит вглубь одного типа работы. Вот как это работает со счётчиком покупок в интернет-магазине:

Вертикальная декомпозиция:

Бэкенд: считать количество покупок и отдавать данные на фронт.

Фронтенд: запрашивать данные при загрузке страницы и выводить.

Горизонтальная декомпозиция:

• добавить столбец с количеством покупок в БД;
• считать в этом столбце, сколько раз товар купили;
• добавить метод, который будет возвращать количество покупок по id товара.

• добавить на страницу товара строку с количеством покупок;
• обращаться с помощью метода к БД во время загрузки страницы;
• настроить отображение счётчика на экранах разных размеров.

Кто должен декомпозировать

Декомпозировать задачу может сам разработчик, тимлид, менеджер проекта или другой компетентный сотрудник: универсальных правил здесь нет. Руководитель службы разработки Яндекс.Практикума Александр Трегер рассказывает, как это работает у них:

Когда появляется новая большая задача, один из опытных разработчиков берёт её на себя. С этого момента он за неё отвечает: собирает встречи, даёт заказчикам обратную связь, определяет, как решить задачу, декомпозирует её. Для разработчиков это возможность расширить свою зону ответственности, попробовать себя в роли архитектора и менеджера проекта.

Иногда нужно выделить время и разобраться в задаче, подумать про пограничные случаи, изучить технологию, придумать решение. Бывает, что на этом этапе задача может разделиться на несколько этапов: что делаем сейчас, а что потом. Так было, например, с проверкой домашних работ от студентов: сначала они приходили в виде архива на проверку, потом появился полноценный интерфейс для ревью кода. Система будет развиваться и дальше, но декомпозиция помогает понять, что и в какой последовательности можно сделать, чтобы быстрее получить результат.

Почитайте полное интервью с Александром Трегером. Там больше подробностей о разработке Практикума.

Получите ИТ-профессию

В «Яндекс Практикуме» можно стать разработчиком, тестировщиком, аналитиком и менеджером цифровых продуктов. Первая часть обучения всегда бесплатная, чтобы попробовать и найти то, что вам по душе. Дальше — программы трудоустройства.

Источник: thecode.media

Декомпозиция и абстракция, их применение в программировании.

Базовым и основополагающим подходом к решению любой большой задачи является следование принципу «разделяй и властвуй». Поэтому рассмотрим два основных метода, позволяющих добиться выполнения этого принципа – методы абстракции и декомпозиции.

Декомпозицией называется процесс разбиения программы на части. Легко понять, для чего необходимо проводить корректную декомпозицию: ведь к решению объемной и сложной задачи, привлекается большое количество людей, причем это количество возрастает пропорционально сложности решаемой задачи. Вполне может случиться, что регулярные контакты между этими людьми будут затруднены. Следовательно, основную задачу необходимо разбить на части, которые могут быть разработаны по отдельности, и которые впоследствии можно было бы легко объединить в одну систему.

Таким образом, при декомпозиции задачи мы разбиваем ее на ряд подзадач так, что 1)каждая подзадача имеет один и тот же уровень рас­смотрения; 2)каждая задача может быть решена независимо и 3)полученные решения могут быть объединены вместе, позволяя решить исходную проблему.

Декомпозиция является весьма полезным и экономящим время способом решения задач в самых различных областях. При этом очень важно соблюдать корректность декомпозиции. К числу наиболее распространенных проблем относится ситуация, при которой создание отдельных компонент, способных решить соответствующие подзадачи, не приводит к тому, что объединение этих компонент позволяет решить исходную задачу. Эта проблема является одной из причин, по которой интеграция системы часто оказы­вается затруднительной.

Далее подробнее рассмотрим абстракцию. Абстракция представляет собой эффективный способ декомпозиции, осуществляемый посредством изменения списка детализации. Можно дать абстракции такое определение: абстракция есть отвлечение от несущественных подробностей с целью лучшего понимания стороны изучаемого явления и путь к созданию абстрактных понятий. Декомпозиция наиболее эффективна тогда, когда осуществляется на базе абстракции. Декомпозиция используется для разбиения программы на компоненты, которые могут быть объединены, позволив решить основную задачу; абстрагирование же предполагает продуманный выбор этих компонент.

В программировании используются два основных метода абстракции: абстракция через параметризацию и абстракция через спецификацию. Эти два метода позволяют создавать в программе три вида абстракций: процедурная абстракция, абстракция данных, абстракция через итерацию.

Абстракция и декомпозиция. Их взаимодействие при проектировании программ.

Очень небольшая программа, содержащая всего несколько сотен строк, может быть представлена одной неделимой единицей. Однако по мере возрастания размера программы такая монолитная структура становится неудобной, поскольку ее текст уже труден для понимания. Поэтому программа должна быть разбита на ряд независимых небольших программ, называемых модулями, которые сообща выполняют требуемую функцию.

Корректность процесса декомпозиции становится все более и более важной по мере того, как размер программы возрастает. Это обусловливается следующими причинами. Во-первых, в про­цесс составления программы вовлекается все большее число лю­дей. Если над программой работает несколько человек, то есте­ственно предположить их регулярные контакты.

Такой контакт снижает вероятность различных разногласий, касающихся того, кто и что должен делать, и уменьшает серьезность последствий, возникающих в подобных ситуациях. Если над задачей работает много людей, то регулярные взаимодействия между ними стано­вятся невозможными, поскольку они отнимают слишком много времени. По этой причине программа может быть разбита на части, причем каждая из них может создаваться отдельными участниками независимо от остальных, вследствие чего контакты между людьми становятся минимальными.

Полезное время жизни программы (ее «рабочая» стадия) на­чинается с того момента, когда она передается потребителю. Од­нако на этом работа над программой не заканчивается. В тексте программы могут быть требующие исправления ошибки, а для обеспечения удобства работы с программой сообразно с требова­ниями пользователя может возникнуть необходимость в ее дальнейшей модификации. Работа по модификации и сопровождению программы может потребовать больше времени, чем все время, потраченное на ее разработку.

При модификации и сопровождении программы редко оказы­вается разумным начинать работу с ее полной переделки. Вместо этого предпочтительней внести изменения в уже существующую структуру и, следовательно, весьма важно, чтобы структура до­пускала возможность подобной модификации. В частности, необ­ходимо, чтобы части программы были независимы друг от друга с тем, чтобы изменение в одной части могло быть сделано без изменения других ее частей.

И наконец, время жизни большинства программ достаточно велико, поэтому работа с ними продолжается еще долгое время. Кроме этого, необходимо учитывать постоянные изменения в со­ставе рабочей группы, что приводит к тому, что модификация про­грамм обычно выполняется уже не разработчиками задачи. Все эти факторы предполагают структурирование программ таким об­разом, чтобы они были легко понимаемыми.

Целью при декомпозиции программы является создание модулей, которые в свою очередь представляют собой небольшие программы, взаимодействующие друг с другом по хорошо опреде­ленным и простым правилам. Если достигнем этой цели, то разработка отдельных модулей может осуществляться различ­ными людьми независимо друг от друга, без необходимости об­щения друг с другом, при этом все эти объединенные вместе про­граммы будут функционировать правильно. Помимо этого в про­цессе модификации программы появится возможность корректи­ровать отдельные модули без необходимости исправления других.

При декомпозиции задачи мы разбиваем ее на ряд подзадач так, что

1. каждая подзадача имеет один и тот же уровень рас­смотрения;
2. каждая задача может быть решена независимо;
3. полученные решения могут быть объединены вместе, позволяя решить исходную проблему.

Источник: studfile.net

Декомпозиция. Как разобрать огромный проект на понятные сегменты для предварительной оценки

Вот притащили вам с охоты мамонта: выше вас ростом, упитанный и на вид пока несъедобный. Что делать?! Декомпозировать, конечно: лапы отдельно, шкуру отдельно. Но с чего начать? И когда хоть примерно будет готов ужин?

Если вам достался жирненький проект, вопросы примерно такие же — какой круг задач предстоит, и как их предварительно оценить. Декомпозиция — крутой способ разложить всё по полочкам и прикинуть объём работ, заложить резервы на трудные блоки и докопаться до неприятных задач со звездочкой. Как это сделать, мы уже рассказывали в одном из обучающих видео. А для любителей вдумчивого чтения мы преобразовали его в крутую статью.

Уровни декомпозиции

Казалось бы, проще простого: режем проект на большие части, эти части — ещё на части, а те части — снова на части. Но действительно ли всё так просто?!

1 уровень. Крупные блоки или компоненты

Это может быть блок с е-коммерсом, личный кабинет, мобильное приложение, супер-навороченная админка. В общем, любые блоки работ, которые могут быть как-то между собой связаны, но которые можно делать изолированно друг от друга.

2 уровень. Страницы сайта или экраны мобильного приложения

В случае с блоком «мобильное приложение», как на схеме выше, разбиваем его на экраны. Но как узнать, что вы учли все-все-все возможные экраны? Для проверки полноты берите в расчёт сценарии использования — это даст понимание, какие задачи юзеры будут решать в приложении (или на сайте) и каким примерно образом они это будут делать.

Пример

Для e-commerce основной сценарий — продавать, а путь пользователя в нём выглядит так: каталог → список товаров → карточка товара и так далее.

Есть соблазн написать в смете только сценарий использования и его оценку (скажем, сценарий покупки товара или сценарий заказа такси) — ну, ведь понятно же, что там внутри. Нет, непонятно, и есть большой риск потерять множество шагов, поскольку такие сценарии большие, и их крайне сложно адекватно оценить целиком.

Когда сценарий раскладывается на экраны, шансов ошибиться становится меньше. Но помните, что каждый сценарий стоит проверять на связанность — достаточно ли вам вот этих экранов, чтобы этот сценарий сбылся?

Пример

У нас есть маркетплейс — магазин, куда другие производители могут загружать свои товары. Сценарии, лежащие на поверхности: загрузка своих товаров (загрузка и описание, разделы каталога и вот это вот всё), покупка товара (шаги покупателя на пути к цели), обработка заказа (как будут распределяться деньги, как будет получать свою долю маркетплейс и так далее). Если всё это не расписать подробно, можно запросто упустить кучу нюансов.

Будет ещё легче, если вы выделите ключевые роли на проекте (пользователь, администратор интернет-магазина и т. д.), у каждой из которых есть свой сценарий, а у каждого сценария — свой набор экранов. И тогда проверить полноту экранов ещё проще — достаточно посмотреть, связан и выполняется ли сценарий конкретной роли по ним.

3 уровень. Содержание экранов

В общем случае у вас на экранах могут быть какие-то вкладки либо какие-то блоки — грубо, вложенные экраны. Например, страница корзины/оформления заказа — здесь всегда есть блок товаров со своим сценарием (добавить-убавить-очистить), а еще блоки доставки, оплаты, авторизации, бонусной системы и так далее. Бывают ситуации, когда эти блоки также разбивают на экраны по шагам. Зависит от решения, принятого по итогам аналитики — бывает, что удобнее их всё-таки «слить» воедино.

Задача менеджера, когда он добрался до такого экрана, — посмотреть, из чего тот состоит. Бывает, экран легко разбить на блоки, бывает — сложно. Яркий пример сложной разбивки — калькуляторы: по ним чаще всего неочевидно, что происходит и как процесс расчёта делить на шаги.

Когда вы добираетесь до третьего уровня, нужно быть супер-внимательными, потому что на странице могут появляться самые разные вещи. И важно понимать, откуда они там вообще берутся — от этого будут сильно зависеть ваши оценки.

Откуда эта хрень на странице?!

Итак, вы добрались до какого-то блока или страницы. Самое время задать себе вопрос «Откуда это на странице?!». Но проджекты, аналитики и аккаунт-менеджеры (и даже заказчики) вот тут часто-часто ленятся — «подумаем об этом потом».

Например, аналитик сказал: «это мы как-нибудь на коде решим», а потом на планинге сидят 4 умных человека, смотрят друг на друга и спрашивают: «кто это придумал, что это за маразм?!». Такая ситуация — явный признак, что где-то недоработали раньше. Бывает, конечно, что принятие какого-то решения действительно откладывается, но это должно быть осознанно и где-то зафиксировано.

Чем меньше вы понимаете в момент «Откуда это на странице!?», тем больше у вас должен быть зазор в смете. И когда к вам приходит клиент и говорит «а почему тут такой большой зазор?!», у вас должен быть готовый ответ — потому что вы не понимаете, как работает то, то и это (лучше — фиксированный перечень конкретных вопросов), и что эти вопросы вы будете выяснять вместе с ним позже.

Итак, какими могут быть варианты, откуда берутся данные на странице?

Вариант 1. Хардкод

Самый простой в реализации вариант ответа на наш вопрос — хардкод. Это значит, что программисты сели, прямо в коде зафигачили какую-то штуку, и теперь поменять ее могут только они. Самые частые блоки, с которыми так делают — логотипы компаний, иногда ссылки на соцсети, время от времени такое делают с меню (всё реже), телефонами (плохо!), декоративными элементами на верстке. Всё это — более-менее разумные моменты. Неразумно, это когда в код зашиваются, например, ВСЕ страницы или SEO-тексты блоками.

Вариант 2. Включаемая область

У включаемых областей есть специфика: во-первых, их можно случайно удалить. Во-вторых, если в них указываются даты мероприятий или цены на товары, это чревато путаницей, поскольку у этих областей нет связанности: если поменять дату или цену в одном месте, в другом она останется той же. Клиенты зачастую сразу говорят, что такого им не нужно — а значит, придётся продумывать, как менять цены, даты и прочие изменяемые поля автоматически и повсеместно.

Вариант 3. Из админки (из базы данных)

Итак, мы знаем, что какие-то данные выбираются из базы данных. Тогда нам нужно понимать, из какой сущности и из какого поля. Примеры сущностей в интернет-магазине: «товар», «раздел», «пользователь», «заказ» — то есть то, что состоит из каких-то полей. Поля — например, «цена».

Но достаточно ли нам будет понимать, из какой сущности и из какого поля выводятся данные? Не совсем. Когда выбираете какую-то информацию из базы, она может выводиться не в том виде, как она там хранится, а в несколько модифицированном.

Например, это формула

Когда информация хранится в базе, но ее нужно как-то определенным образом модифицировать, появляется понятие «формула». Одна из самых опасных вещей, которую менеджеры часто пропускают.

Когда вам аналитик говорит «ну там это как-то считается» — навострите ушки, впереди точно будет затык. Математики не понимают программистов и считают что, их формулу достаточно переписать и следом «просто» запрограммировать — делов-то. Но когда клиента начинаешь спрашивать о формуле, часто слышишь что-то вроде «ой, она у нас там в excel», или «механика пока непонятна», или вообще «ну скопируйте вон с того сайта».

Видите формулу — копайте глубже. У неё внутри есть коэффициенты — а откуда берутся эти коэффициенты? Добро пожаловать в новый виток расследования «Откуда эта хрень на странице!?».

Вот из-за этого о формулах никто не любит думать:)

Например, это файл

В зависимости от используемой технологии бывает, что часть данных хранится в файлах. Может показаться, что это какая-то сущность или поле сущности, но это всё-таки ФАЙЛ.

Очень часто файлы в самой базе данных не хранятся, чтобы не «раздувать» её. Из-за этого работа с ними организована иначе. В случае банального каталога товаров файлом может быть фотография у пользователя (userpic), описания, спецификации в pdf и всё такое прочее. Такие файлы находятся не совсем в базе, но при оценке важно понимать, что они есть.

С файлами ещё бывает история, что их нужно хранить на отдельных серверах, или в облаках S3, закачивая по специальному протоколу, но это уже нюансы масштабирования. На старте проекта, окупаемость которого непонятна, городить тут огород я не вижу смысла. Исключение — тяжелый видео-контент. Его лучше сразу писать в видеохостинги.

— Владимир Завертайлов, CEO

она «почти есть» — как правило, это говорит о том, что внутри ерунда, а вы будете подопытными обезьянками, на которых будут всё эту сырую штуку тестировать.

Хуже всего бывает, когда говорят «ну вы, программисты, между собой договоритесь и разберитесь сами как-нибудь». Если протокол не формализован и взаимной ответственности нет, критический путь проекта будет пролегать через интеграцию, и на ней он завалится. Или по крайней мере, здесь потратится куча времени на согласование с программистом заказчика его протокола и отладку.

Соответственно, если на проекте планируется интеграция с внешним сервисом, на неё нужно закладывать большие резервы. Лайфхак, если нужно интегрироваться, а протокола пока нет — делать MOCK-объекты. Это специальные заглушки для интеграционного протокола, которые можно быстро сделать. А как только будет реальный протокол — просто заменить их (но обязательно с перепроверкой).

Как все это «подружить»

Начинаем с крупных компонентов: первый, второй третий — можно расписать подробно. Следом важно примерно понять, какие есть пользователи (роли) и какие у них сценарии. Сами сценарии в смету лучше не прописывать. Дальше — идём по страницам. После — работаем с отдельными блоками, используя уже известную схему «Откуда эта хрень на странице?!».

Как только вы слышите слово «калькулятор» или «считается», напрягайтесь 🙂 Когда есть интеграция со сторонним сервисом — тоже. В остальном — ничего страшного, и всё довольно прозрачно 🙂

Когда это может не сработать

Если на проекте есть какая-то дремучая математика, и вы живете в мире, полном злых неожиданностей, то декомпозиция по экранам будет давать сбой. В общем случае она довольно хорошо показывает, что и как происходит на типовых проектах.

Успехов в декомпозиции и почаще заглядывайте к нам на YouTube-канал за новыми полезными видео для проджектов (и не только)!

• оценка времени
• управление проектами
• управление временем
• scrum
• planning poker

Источник: habr.com