Проектирование корпоративного приложения

Нам хамов не надо, мы сами хамы. © Ося Бендер в раздел...

Версия для печатиВерсия для печати

Содержание

  1. Задачи проектирования приложения
  2. Интервьюирование заказчика
  3. Определение терминов приложения
  4. Определение субъектов приложения
  5. Определение объектов приложения
  6. Определние прецедентов приложения
  7. Определение бизнес-правил приложения
  8. Составление ТЗ на разработку приложения
  9. Итерации проектирования приложения
  10. Дополнение

Корпоративное приложение: Проектирование

Задачи проектирования приложения Проектирование корпоративного приложения

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

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

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

Теоретики программирования давно проработали процесс моделирования и создали UML, Universal Modeling Language, универсальный язык моделирования. Но есть проблема, во всяком случае я ее так рассматриваю. Как любая универсальная система, концепция UML всеобъемлюща и, как следствие, крайне сложна. Что-то сродни философскому камню. Очень хорошо, если удастся подробно изучить UML в полном объеме, но вряд-ли это целесообразно, поскольку дедушки Паретта никто не отменял, а он говорит, что 20% усилий покроют 80% потребностей.

Если я внимательно читал классиков, они тоже со мной согласны. RUP, Rational Unified Process, в чистом виде никто из моих знакомых не использует за его избыточностью. Меня, например, очаровывает процесс ICONIX, представляющий собой усеченный вариант RUP. Но и его я использую не в чистом виде, мой процесс - адаптация идеи ICONIX для моих нужд. Мой процесс включает в себя следующие шаги:

  1. Интервьюирование заказчика;
  2. Определение терминов;
  3. Определение субъектов;
  4. Определение объектов;
  5. Определние прецедентов;
  6. Определение правил;
  7. Составление ТЗ;

Каждый из упомянутых выше этапов обязтально должен окончиться составлением документа, который внесет свою лепту в общий проект. Под документом я предполагаю не "тупой лобовой", а неформальный подход. Оформление ТЗ по ГОСТ - это здорово, но отнимет столько времени, что заказчик занервничает. Может даже остановить финансирование =) Именно по этому стоит создавать гранулярные документы и поэтапно обсуждать их с заказчиком вместо долгого написания длинного и хорошего документа. Возникает риск создать отличный документ но дома и за свой счет.

Интервьюирование заказчика Проектирование корпоративного приложения

Интервьюирование заказчика имеет важнейшее значение. Цель данного этапа - оказаться "в шкуре" людей, которые будут пользоваться разрабатываемым приложением. Главное на данном этапе - помнить, что софт пишется для пользователей. Не для программистов, не для администраторов, даже не для руководства, а для пользователей. В результате должен быть составлен документ, который на понятном пользователю языке с картинками показывает что именно получит заказчик когда нетленка будет закончена.

Определение терминов приложения Проектирование корпоративного приложения

Иными словами - составление глоссария. Программисты сколнны мыслить абстрактными категориями. Мы создаем новое приложение и при этом слишком часто забываем о том, что та деятельность, которую мы беремся автоматизировать уже ведется и уже сложились термины и определения. Задача данного этапа собрать все термины и определия, используемые заказчиком и определить однозначное трактование каждого из них в рамках разрабатываемого приложения. Без этого заказчику будет "жать" новое приложение "спасибо" разработчик не получит. Результатом данного этапа должен быть глоссарий.

Определение субъектов приложения Проектирование корпоративного приложения

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

Определение объектов приложения Проектирование корпоративного приложения

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

Определние прецедентов приложения Проектирование корпоративного приложения

Пользователи что-то делают с объектами. Визируют договора, заводят контакты, составляют отчеты. Именно глаголы, примененные к существительным важны на данном этапе. Задачей этого этапа является определение действий, которые будут применять субъекты к объектам. Результатом данного этапа должен быть документ, определяющий и конкретизирующий действия, которые смогут предпринимать пользователи в системе. Единственная форма данного документа, которая удобна мне и моим заказчикам - набор скрин-шотов интерфейсов. Пользователь любит картинки, а мне потом верстать легче =)

Определение бизнес-правил приложения Проектирование корпоративного приложения

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

Составление ТЗ на разработку приложения Проектирование корпоративного приложения

Логическим результатом проектирования является составление ТЗ, технического задания. Составление ТЗ не представляет собой никакой сложности, поскольку является, по сути, сводкой всех документов, порожденных на предыдущих этапах. Формальность ТЗ - предмет соглашения заказчика и исполнителя, мне никогда не доводилось писать формальных (по ГОСТ) ТЗ, поскольку заказчик никогда этого не требовал. Но есть и резкое отличие данного этапа от предыдущих. ТЗ должно быть согласовано и утверждено. И это должно быть где-то зафиксировано.

Итерации проектирования приложения Проектирование корпоративного приложения

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

Дополнение Проектирование корпоративного приложения

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

  1. Заказчик всегда считает, что лучше разработчика знает, как писать софт. И это не так. Софт пишется программистами;
  2. Заказчик всегда считает, что вы его понимаете. И это не так. Пока все не записано предельно подробно, понимания нет и быть не может;
  3. Заказчик всегда считает, что ему нужно все из того, что вы назвали. И это не так. Услышав цену (время на разработку) заказчик откажется от ряда претензий;
  4. Исполнитель всегда считает, что делает то, чего хочет заказчик. И это не так. Пока заказчик не увидел результат, никто не знает, чего он хочет;
  5. Исполнитель всегда считает, что главное - надежная архитектура (красивый код). И это нет так. Заказчик заказывает (и оплачивает) интерфейс, остальное второстепенно;
  6. Исполнитель всегда считает, что учел все. И это не так. По окончании работы обязательно возникнет требование "сдвинуть дом на пару метров вправо";

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

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

Версия для печатиВерсия для печати

Индекс цитирования Яндекс
Аттестат участника WebMoney
Этот сайт разрабатывается в соответствии с рекомендациями W3C XHTML 1.0 Transitional
Этот сайт разрабатывается в соответствии с рекомендациями W3C CSS

Сайт "Территория Дмитрия Новоженова" © 2024 год. Программирование на ASP.NET, написание программ на C#, самописные утилиты. Разборки с компьютерами, сетевым оборудованием и другим железом. Коллекции изображений, библиотеки иконок, которые можно скачать и сохранить локально, рисунков и других картинок. Личный фотоальбом, ссылки на фотогаллереи на других сайтах и другие ресурсы посвященные фотографии. Каталог игр на PlayStation 2, тактика прохождения игр, обзоры игр на PlayStation 2. Тематические сборники статей, новости сайта.