Цикл статей по проектированию веб-сервиса

    Всем привет!

    Мы, Денис Бесков (beskov) и Илья Поляк (ilyap1) начинаем публикацию цикла статей, посвящённых процессу проектирования веб-сервисов. Цикл построен вокруг 3-хуровневого процесса, в котором явным образом выделяются уровни анализа и проектирования:
    1. Бизнеса
    2. Продукта
    3. Технологий
    Здесь, на хабре, достаточно хорошо освещается тема проектирования на уровне технологий. Мы хотим показать взаимосвязь этого уровня, видов работ и проектных решений с вышестоящими уровнями на примере сквозного демо-кейса — проектирования веб-сервиса бронирования билетов в кино, в разработке которого участвовал пару лет назад один из авторов.

    Цикл статей построен вокруг избыточной документации по проекту (требования), которую разрабатывают внутренние сотрудники компании, содержит краткое описание теоретических аспектов и помогает ответить на следующие вопросы, которые могут у вас возникнуть в работе:
    1. Какими способами можно описывать требования к ПО?
    2. Какие из требований к системе обязательно необходимо включать в ТЗ, а без каких можно обойтись?
    3. Какие могут быть варианты при выборе форматов описания требований?
    4. Как зависит выбор вида описания требований от параметров (продолжительности, рисков и др.) проекта?
    5. Какого рода решения помогают принять соответствующие виды требований?
    В цикле не рассматриваются аспекты заказной разработки ПО. Статья рассчитана на пользователей, которые работают в некорпортивной среде, т.е. не привязаны к каким-либо регламентам.

    На примере проектирования новой услуги для развлекательно-информационного портала мы расскажем и покажем:
    1. Какие решения необходимо принимать на 3-х фазах анализа и проектирования: «бизнес», «продукт» и «технология»;
    2. Классический подход к анализу и проектированию продукта;
    3. Различные форматы представления требований (модели процессов, глоссарий, варианты использования и др.);
    4. Какой формат представления требований наиболее уместен в каждой ситуации;
    Цикл рассчитан на менеджеров проектов, начинающих системных аналитиков, дизайнеров, проектировщиков интерфейсов, маркетологов и разработчиков, которым хочется узнать, как проектировать веб-сервисы не «на коленке», а опираясь на лучшие отраслевые практики из индустрии разработки ПО.

    Процесс принятия проектных решений на нескольких уровнях разработки требований к программному продукту (бизнес-анализ и проектирование, продуктовый анализ и проектирование, технический анализ и проектирование) показан на примере услуги бронирования билетов на сайте afisha.ru.

    Мы будем публиковать по одной статье в неделю. Пожалуйста, задавайте вопросы, будем рады на них ответить.

    Оглавление
    Бизнес-анализ. Контекст и профили заинтересованных лиц
    Бизнес-анализ. Описание существующих бизнес-процессов (AS-IS)
    Бизнес-анализ. Описание предметной области
    Бизнес-анализ. Анализ бизнес-проблем
    • +6
    • 16,1k
    • 8
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 8
    • +5
      а где статья-то?
      • 0
        дописали второй пост
        какие вы нетерпеливые прямо )
        • +1
          тут дело в другом. Зачем такой отдельный топик-анонс? Его следовало в шапку первой статьи и добавить, а не флудить подряд топиками.
          • +1
            нам удобнее работать с небольшими материалами
            мы планируем их понемногу дорабатывать по тексту, а-ля вики
            • 0
              Кроме того, этот пост будет постоянно обновляемым оглавлением-навигацией по ± 10 статьям цикла. Это оглавление, на наш взгляд, имеет самостоятельную ценность и пользу.
        • +6
          щас так модно на хабре, делать Анонсы(трейлер)…
          • 0
            Хочу отметить, что подобный процесс подходит для любого проектирования будь то программка под заказ, или анализ интернет-магазина для увеличения конверсии (я сейчас как раз хочу попробовать сделать анализ по приведенной системе)
            • 0
              Не совсем так. Приведенный нами framework, как и написано, предназначен в основном для проектирования продуктов. В заказной разработке появляются свои детали.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.