Материал предоставлен сайтом Территория Дмитрия Новоженова (http://www.novojonov.ru)
Любое приложение, претендующее на звание корпоративного, является априори большим приложением. Потребность в построении корпоративных приложений или, иначе говоря, приложений уровня предприятия, возникает тогда и только тогда, когда предприятие попадает в "революционную" ситуацию, при которой деятельность нужно осуществлять по-старому а вот управлять этой деятельностью нужно по-новому.
Такая ситуация складывается, как правило, с ростом объемов и децентрализацией деятельности. Ключевой момент - рост объемов. Предприятие растет, бизнес-процессы усложняются, в голове уже все не удержать. Тогда и вспоминают про корпоративные приложения. Именно это и определяет сложность и объем приложения. Вывод из этих сентенций крайне прост: если менеджеры предприятия не могут удержать все в голове, разработчику тоже вряд-ли удастся. Поэтому проектирование играет ключевую роль в процесе разработки.
Основная цель разработки корпоративного приложения - моделирование бизнес-процессов предприятия. Бизнесу требуется максимально полное отражение приложением существующих процессов, включая терминологию, правила и нюансы. А "клиент всегда прав", не так-ли? Поэтому проектирование приложения, фактически, сводится к построению модели предприятия "в натуральную величину".
Теоретики программирования давно проработали процесс моделирования и создали UML, Universal Modeling Language, универсальный язык моделирования. Но есть проблема, во всяком случае я ее так рассматриваю. Как любая универсальная система, концепция UML всеобъемлюща и, как следствие, крайне сложна. Что-то сродни философскому камню. Очень хорошо, если удастся подробно изучить UML в полном объеме, но вряд-ли это целесообразно, поскольку дедушки Паретта никто не отменял, а он говорит, что 20% усилий покроют 80% потребностей.
Если я внимательно читал классиков, они тоже со мной согласны. RUP, Rational Unified Process, в чистом виде никто из моих знакомых не использует за его избыточностью. Меня, например, очаровывает процесс ICONIX, представляющий собой усеченный вариант RUP. Но и его я использую не в чистом виде, мой процесс - адаптация идеи ICONIX для моих нужд. Мой процесс включает в себя следующие шаги:
Каждый из упомянутых выше этапов обязтально должен окончиться составлением документа, который внесет свою лепту в общий проект. Под документом я предполагаю не "тупой лобовой", а неформальный подход. Оформление ТЗ по ГОСТ - это здорово, но отнимет столько времени, что заказчик занервничает. Может даже остановить финансирование =) Именно по этому стоит создавать гранулярные документы и поэтапно обсуждать их с заказчиком вместо долгого написания длинного и хорошего документа. Возникает риск создать отличный документ но дома и за свой счет.
Интервьюирование заказчика имеет важнейшее значение. Цель данного этапа - оказаться "в шкуре" людей, которые будут пользоваться разрабатываемым приложением. Главное на данном этапе - помнить, что софт пишется для пользователей. Не для программистов, не для администраторов, даже не для руководства, а для пользователей. В результате должен быть составлен документ, который на понятном пользователю языке с картинками показывает что именно получит заказчик когда нетленка будет закончена.
Иными словами - составление глоссария. Программисты сколнны мыслить абстрактными категориями. Мы создаем новое приложение и при этом слишком часто забываем о том, что та деятельность, которую мы беремся автоматизировать уже ведется и уже сложились термины и определения. Задача данного этапа собрать все термины и определия, используемые заказчиком и определить однозначное трактование каждого из них в рамках разрабатываемого приложения. Без этого заказчику будет "жать" новое приложение "спасибо" разработчик не получит. Результатом данного этапа должен быть глоссарий.
В автоматизируемых процессах, как правило, задействовано значительное количество человек. Но мыслить в категориях людей может позволить себе заказчик но не разработчик. Разработка приложения может осуществляться исключительно в терминах ролей. Результатом этого этапа должен быть документ, содержащий список ролей с полным описанием функционала каждой роли.
В своей деятельности люди оперируют какими-то объектами. Договорами, контактами, отчетами. На данном этапе нужно определить состав этих объектов, характеристики каждого из них и связи, имеющиеся между ними. Иными словами составить граф модели предметной области. Результатом этапа должна быть аннотированная схема, описывающая объекты предметной области.
Пользователи что-то делают с объектами. Визируют договора, заводят контакты, составляют отчеты. Именно глаголы, примененные к существительным важны на данном этапе. Задачей этого этапа является определение действий, которые будут применять субъекты к объектам. Результатом данного этапа должен быть документ, определяющий и конкретизирующий действия, которые смогут предпринимать пользователи в системе. Единственная форма данного документа, которая удобна мне и моим заказчикам - набор скрин-шотов интерфейсов. Пользователь любит картинки, а мне потом верстать легче =)
На данном этапе определяются последствия, которые возымеют прецеденты. Данный этап явялется одновременно самым простым и самым сложным. Четкость и понятность бизнес-логики (ее и логикой-то можно только в шутку назвать) - притча во языцех. Основное внимание на данном этапе следует уделить пониманию процессов, которые предстоит автоматизировать и условий, которые определяют эти процессы. Для каждого процесса обязательно определяются точки входов и выходов, лежащие в пространстве прецедентов. Результатом данного этапа должен служить набор диаграмм, по одной для каждого из автоматизируемых процессов.
Логическим результатом проектирования является составление ТЗ, технического задания. Составление ТЗ не представляет собой никакой сложности, поскольку является, по сути, сводкой всех документов, порожденных на предыдущих этапах. Формальность ТЗ - предмет соглашения заказчика и исполнителя, мне никогда не доводилось писать формальных (по ГОСТ) ТЗ, поскольку заказчик никогда этого не требовал. Но есть и резкое отличие данного этапа от предыдущих. ТЗ должно быть согласовано и утверждено. И это должно быть где-то зафиксировано.
Не следует пытаться проделать все указанные выше шаги последовательно. Проектирование - процесс итеративный. На каждом этапе выясняется, что мы что-то упустили и не грех вернуться к какому-либо этапу и дополнить, расширить, исправить... Более того, мне наиболее понятна и удобна "спиральная" модель, при которой движение проектирования идет по спирали, когда каждый штрих нанаосится крупными мазками, потом уточняется по мере формирования общей картины. И так раз за разом, круг за кругом, виток за витком.
Также при проектировании приложения следует учитывать некоторые особенности, характерные для любого заказчика и исполнителя. Может где и есть иделальный заказчик и исполнитель без недостатков, но лучше исходить из утверждения "все мы люди" =) Эти особенности таковы:
Таким образом проектирование - основной процесс разработки, призванный свести к минимуму различия в образах мышления заказчика и исполнителя. При проектировании мы фактически договариваемся с заказчиком что он получит и сколько за это заплатит (времени мы потратим). Пренебрежение проектированием приведет к тому, что модель не будет отражать предметной области, приложение придется многократно переписывать и у заказчика сложится вполне определенное мнение о Вашем профессионализме.
Материал предоставлен сайтом Территория Дмитрия Новоженова (http://www.novojonov.ru)