Как определяется структура создаваемого бизнес приложения

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

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

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

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

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

Цифровые продукты и технологии. Бизнес-интервью. Как создать и продвигать.

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

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

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

Этапы проектирования приложения

Шаг 1. Исследование рынка и аналитика

Шаг 2. Формирование структуры и прототипа

Шаг 3. Разработка дизайна мобильного приложения

Шаг 4. Написание технического задания

Шаг 1. Исследования и аналитика

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

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

Финтех | Денис Сотин, Иван Самолов | Подкаст #31

• Анализ целевой аудитории приложения

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

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

Для исследования ЦА могут использоваться такие методы как:

• опрос покупателей и клиентов, в том числе предполагаемых;
• изучение информации из открытых источников;
• анализ конкурентов.

Чем детальнее будет сегментирована аудитория — тем больше ценной информации получит разработчик.

• Пользовательские сценарии

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

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

• Обзор рынка и конкурентов

Анализ конкурентов и подбор референсов дает возможность понять, чего не хватает приложению, что нравится и не нравится, какие решения кажутся удачными или наоборот. Какие фишки есть у конкурентов? Электронные библиотеки каталогов, 3D-модели, элементы доверия или видео-контент — стоит задуматься, возможно что-то из этого можно добавить в дизайн проект вашего приложения.

Закрывать набор компетенций, необходимый для проведения исследований и аналитики, может разное число сотрудников: иногда достаточно сильного project-менеджера, а иногда не обойтись без полноценного маркетолога-аналитика.

Шаг 2. Формирование структуры и прототипа

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

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

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

Если этот этап пропущен, то вносить изменения приходится уже на этапе разработки, а это всегда намного дороже. Создание прототипа мобильного приложения не только не увеличивает объём работ но и, наоборот, уменьшает его, экономит время и средства.

Шаг 3. Разработка дизайн-макета web-приложения

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

Инструкции как правильно оформлять приложения содержатся в специальных публичных гайдах операционных систем. Для IOS это Human Interface, а для Android — Material Desing, там же описана и логика работы элементов.

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

Для создания макетов дизайнеры Terabit Digital используют Figma. В ней есть все нужные инструменты, для проектирования интерфейсов мобильных приложений, а также удобные возможности для демонстрации результата. В режиме реального времени можно посмотреть макеты, добавить комментарии и согласовать результат.

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

Шаг 4. Написание технического задания на создание приложения

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

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

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

В заключение

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

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

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

Источник: terabit.ai

Этапы разработки мобильного приложения

В этой статье мы, команда разработчиков Sibdev, расскажем о деталях создания мобильных приложений с опорой на собственный опыт.

Иерархия процессов

1. Продуктовая аналитика.
2. Спецификация и вайрфреймы.
3. Оценка и планирование.
4. Дизайн.
5. Программирование.
6. Тестирование.
7. Запуск.

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

• Продуктовая аналитика

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

1. сегментировать целевую аудиторию (ЦА);
2. определить популярные модели взаимодействия пользователей с аналогичными сервисами;
3. изучить конкурентоспособность продукта;
4. сформулировать уникальное торговое предложение (УТП);
5. построить гипотезы, объясняющие мотивы поведения посетителей;
6. сформировать критерии минимально жизнеспособного продукта (minimum viable product, MVP).

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

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

• Спецификация и вайрфреймы

Задача этапа — сформулировать подробные технические требования к функциональности и дизайну мобильного приложения. Целью является донести до команды разработчиков четкое понимание плана реализации проекта.

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

1. введение — цели, термины, представление ЦА, масштаб проекта;
2. описание — видение и функциональность программы, детальная классификация пользователей, операционная среда, стандарты, предположения и зависимости;
3. требования к внешним интерфейсам — пользовательскому (UX), программному, оборудования и коммуникаций;
4. нефункциональные требования — производительность, конфиденциальность данных и безопасность системы, критерии качества продукта;
5. прочее — глоссарий, каталог моделей процессов, перечень базовых задач.

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

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

Пример спецификации мобильного приложения

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

Примеры вайрфреймов мобильного приложения

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

• Оценка и планирование

1. демонстрация структуры продукта (общий объем работ);
2. расписание участия в проекте профильных специалистов;
3. стоимость работ;
4. сроки реализации;
5. оценка вероятности наступления рисковых ситуаций с перечнем мер по предотвращению и ликвидации последствий.

• Дизайн

1. выстраивание дизайн-концепции — уникального художественного стиля продукта, брендирование;
2. сборка UI-кита — набора готовых, часто используемых элементов и шаблонов пользовательского интерфейса;
3. создание дизайн-макета — визуального образа мобильного приложения, демонстрирующего внешний вид страниц после верстки и с разными вариантами наполнения;
4. динамического прототипа — интерактивной анимированной версии продукта, позволяющей оценить качество интерфейса.

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

Пример дизайн-концепции мобильного приложения

• Программирование

Задача этапа — написание кода, построение архитектуры, Back-end и Front-end разработка. Для комплексных и сложных проектов используется тактика MVP.

1. нативный — разработка отдельной версии мобильного приложения для каждой платформы;
2. кроссплатформенный — использование кода, универсального для всех платформ.

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

• Тестирование

Задача этапа — тестирование мобильного приложения с целью выявления недостатков и ошибок.

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

Цель проверки продукта на стабильность, совместимость и безопасность достигается привлечением специалиста-тестировщика, который проверяет функциональность UI/UX, выясняет качество и порядок запросов разрешений, устанавливает отказоустойчивость баз данных и т. д.

По результатам тестирования создается отчет с детальным перечнем ошибок и рекомендациями по устранению.

• Запуск приложения

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

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

Вывод

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

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

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

Разработка бизнес-приложений Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Иванов С.В., Москалева Ю.П.

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Иванов С.В., Москалева Ю.П.

Подготовка документации бизнес-приложений
Модель документирования бизнес-проекта
Системный подход к проектированию при каскадной и итеративной модели жизненного цикла

Функциональные и математические модели управления портфелем услуг фирмы-посредника постановка проблемы

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

Текст научной работы на тему «Разработка бизнес-приложений»

Ученые записки Таврического национального университета имени В.И. Вернадского Серия «Экономика и управление». Том 24 (63). 2011 г. № 1. С. 54-59.

Иванов С.В., Москалева Ю.П.

Таврический Национальный университет имени В.И. Вернадского, Симферополь, Украина

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

Ключевые слова: управление, бизнес-приложения, бизнес—проекты.

ВВЕДЕНИЕ. С каждым днем Internet все больше входит в жизнь человека. Теперь это не просто «место», в котором можно почитать новости, найти интересующую вас книгу или статью. Теперь все больше людей общаются друг с другом в сети, объединяются в социальные сети и, конечно же, совершают покупки. Сейчас нет необходимости бегать по магазинам в поисках интересующего вас товара, достаточно запустить поиск и найдутся электронные магазины, которые предложат вам весь мыслимый ассортимент товаров по ценам «ниже, чем в магазине».

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

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

В отечественной литературе все чаще можно найти статьи, в которых освещаются темы, смежным с рассматриваемой. Целый ряд работ посвящен вопросам, связанным с электронными платежами. Например, в работе Богуславского Е.В [1] исследуется использование электронной валюты. В работе выполнена разработка классификации электронных денег, сделано описание механизма работы платежных систем, проведен детальный анализ украинского рынка карточных продуктов. В работе Богуславского Е.В [2] рассматриваются задачи разработки мероприятий по улучшению работы карточных платежных систем.

Имеются также работы, которые связаны с изучением более специфических вопросов, связанных с процессом разработки приложений. Например, в работе Украинца А.Г. [3] проводится исследование актуальных проблем контроля инвестиций в программное обеспечение на основе концепции бизнес-ориентированного подхода к информационным технологиям. В работе рассматриваются вопросы разработки модели согласования объектно-

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

Проблемой является недостаточная освещенность вопросов разработки бизнес-приложений в отечественной литературе.

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

РЕЗУЛЬТАТЫ ИССЛЕДОВАНИЯ. Рассмотрим процесс разработки бизнес-приложения поэтапно. В качестве первого этапа можно выделить процесс непосредственно предшествующий самой разработке — это процесс оценки и оформления заказа. Некоторая фирма А, назовем ее клиентом, делает заказ фирме В — исполнителю — на разработку некоторого бизнес-приложения. В общем случае, заказчик устраивает тендер для нескольких фирм исполнителей, однако возможен и прямой заказ конкретному исполнителю.

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

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

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

В проводимой оценке нужно учесть такие вопросы, как:

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

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

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

ИВАНОВ С В., МОСКАЛЕВА Ю.П.

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

Практически все проекты бизнес-приложений можно разделить на два вида:

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

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

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

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

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

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

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

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

Разработку можно организовать различными способами. Один из возможных подходов — итеративный. При таком подходе весь процесс разработки разбивается на итерации — части. Итерации могут быть различными по продолжительности — от нескольких дней до месяцев.

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

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

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

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

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

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

ИВАНОВ С.В, МОСКАЛЕВА Ю.П.

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

ЗАКЛЮЧЕНИЕ. На основе проведенного анализа этапов разработки бизнес-приложений, можно сделать следующие выводы:

• каждый из рассмотренных этапов разработки имеет свои особенности;

• на каждом из этапов разработки имеется определенный набор вопросов, которые требуют особого внимания;

• первые этапы являются основополагающими для всего процесса разработки, поскольку правильно заложенная архитектура приложения, глубокое понимание бизнес-логики приложения и корректно оформленная документация являются залогом будущего успеха;

• четкое планирование процесса разработки и при необходимости своевременная корректировка планов позволят избежать больших затрат времени и финансов;

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

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

1. Богуславский Е.В. Международные платежные системы и принципы их работы. Развитие украинского рынка карточных продуктов / Е.В. Богуславский // Культура народов Причерноморья. — 2004. — Т.2, № 50. — С. 21-25.

2. Богуславский Е.В. Мероприятия по улучшению механизма работы карточных платежных систем в Украине / Е.В. Богуславский // Культура народов Причерноморья. — 2006. — № 89. -С. 21-24.

3. Украинец А.Г. Разработка модели согласования объектно-ориентированной методологии и системологического подхода к моделированию бизнеса / А.Г. Украинец // Вюник Мiж:народного Слов’янського ушверситету. Серш Техшчш науки. — 2007. — № 2. — С. 29-37.

Иванов С.В., Москалева Ю.П. Розробка бiзнес-додаткiв / 1ванов С.В., Москалева Ю.П. // Вченi записки Тавршського нацюнального ушверситету iHcni В. I. Вернадського. Серш: Економжа i управлiння. — 2011 — Т. 24 (63). № 1. — С. 54-59.

Розглянуто основш етапи розробки бiзнес-додаткiв, приведено найбiльш важливi питання та задачi, якi мають розробники, а також наведено можливi засобi та заходив управлiннi такими проектами. Ключовi слова: управлшня, бiзнес-додатки, бiзнес-проекти.

Ivanov S.V., Moskaleva Yu.P. Implementation of business applications / Ivanov S.V., Moskaleva Yu.P.

// Scientific Notes of Taurida National V.I. Vernadsky University. — Series: Economy and Management. -2011. — Vol. 24 (63), № 1. — P. 54-59.

The main steps of the business applications implementation have been considered, the main questions and tasks that the developers have to resolve have been set, the possible ways and approaches of managing of such kind of projects have been given.

Key words: managing, business applications, business projects.

Статья поступила в редакцию 20. 12. 2010 г.

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