Обращаясь в компанию Дакар, Вы получите высокий класс разработки, гарантированную скорость и качество выполняемых работ.
Компания Дакар осуществляет свою деятельность не только в Ростове, а и по всей территории РФ.
В нашей компании есть все необходимые специалисты: программисты 1С, аналитики 1С, архитектор 1С, руководитель проектов и многие другие, что позволяет нам предложить заказчику реализацию разработки на основе типовых продуктов, создание конфигураций 1С с нуля под требования клиента, а также осуществлять сложные интеграции.
Если позволяют вводные данные (специфика бизнеса клиента, его пожелания), то мы предпочитаем использовать типовые решения от 1С и типовой функционал, что значительно удешевляет проект внедрения, а также минимизирует сроки его реализации. Как показывает практика, многие доработки (с которыми мы сталкиваемся в ходе перевнедрения), которые были сделаны в типовой конфигурации (толи штатными сотрудниками предприятия, толи фрилансерами, пытавшимися что-то внедрить) на самом деле были не нужны. Эти доработки являются следствием того, что горе-внедренцы не знали в доскональности типовые конфигурации, или не поняли, что хочет заказчик.
Кому и для чего нужна разработка на 1С
- Разработка на 1С необходима, если есть потребность в сложных и нестандартных интеграциях (например, интегрировать 1С с IBMWebSphere, SAP, MSProjectServer или Почтой России).
- Бизнес клиента – очень специфический (зачастую, чем больше бизнес, тем больше набирается «специфических моментов», не укладывающихся в стандартные схемы.
Ведение проекта
1. Организация документооборота:
- Документирование требований и задач.
- Документирование хода проекта.
2. Участие архитектора (роль – контроль качества) — следит за качеством кода, оптимальностью решений, соответствием того, что делают программисты 1С, первоначальной задумке.
3. Задействование методолога — следит за тем, чтобы все участники проекта поняли задачи бизнеса и решали их.
4. Управление проектом.
Технологии:
- Продуманная архитектура, максимальное использование типового функционала.
- Высокий уровень разработки (оптимальный быстрый и чистый код).
- Обновляемость (решения должны быть настолько обновляемыми, насколько это возможно).
- Внутреннее тестирование.
Подходы к разработке:
Существует несколько методов разработки ПО. Приведем самые популярные и часто используемые:
1. Waterfall — традиционный подход (каскадная разработка);
2. Agile — общая методология гибкой разработки;
3. RUP (Rational Unified Process) — рациональный (итеративная разработка);
4. Crystal Clear — подход с уравниванием разработчиков в коллективе;
5. Spiral — спиральный метод;
6. FDD (Feature Driven Development) — методология, рассматривающая будущие изменения;
7. DSDM (Dynamic Systems Development Model) — динамическая модель;
8. JAD (Joint Application Development) — ориентированный на пользователя подход;
9. RAD (Rapid Application Development) — модель быстрой разработки;
10. Scrum — концепция работы в условиях сорванных сроков и идеологического кризиса;
11. XP (Extreme Programming) — экстремальная разработка в динамической среде;
12. LD (Lean Development) — метод, предполагающий бережное отношение ко всем участникам процесса.
Компания Дакар использует 2 подхода к разработке в зависимости от потребностей заказчика и ситуации, в которой реализовывается проект.
«Waterfall Model» (каскадная модель или «водопад») – классическая версия
Данная методика подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. Эта модель является самой комфортной для работы команд с двух сторон, со стороны заказчика и исполнителя. В модели Waterfall легко управлять проектом. Благодаря её жесткой регламентированности, разработка проходит по запланированным срокам, а стоимость заранее всем сторонам известна. Следует иметь ввиду, что каскадная модель (Waterfall) дает стопроцентный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности «передумать» и вернуться на несколько шагов назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Одновременно с этим, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.
Когда использовать каскадную (Waterfall) методологию?
- Исключительно тогда, когда требования известны и зафиксированы.
- В относительно небольших проектах.
«Agile Model» (гибкая методология разработки)
В «Agile» (гибкой) методологии разработки после каждой итерации заказчик может наблюдать результат и сделать выводы, удовлетворяет он его или нет. Это одно из самых главных преимуществ гибкой модели. Вроде бы выглядит безупречно, но и тут есть свои подводные камни. Из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку.
Методология «Agile» это квинтэссенция для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка. Соответственно, в процессе реализации возникает потребность в изменениях.
Когда использовать Agile?
- Когда потребности пользователей постоянно меняются в динамическом бизнесе.
- В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.
Итеративность и инкрементальность
Итеративная разработка — это когда мы показываем заказчику и утверждаем промежуточные результаты.
«Iterative Model» (итеративная или итерационная модель)
Итерационная модель жизненного цикла не требует для начала полной спецификации требований. Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. Как Вы понимаете, версия будет неидеальна, главное, чтобы она была работоспособной. Понимая конечную цель, мы шаг за шагом идем к ней таким образом, чтобы каждый шаг был результативен, а каждая версия — работоспособна.
На картинке показана итерационная «разработка» Мона Лизы. Этакий пример чтобы всем было понятно, о чем идет речь. Как можно заметить, в первой итерации есть лишь набросок Джоконды, деталей еще нет, только слабые очертания силуэта, но уже сейчас понятно, что хочет рисовать художник. Во второй — появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. Обратите внимание, что на первом наброске руку планировалось нарисовать в другой позиции.
Когда оптимально использовать итеративную модель?
- Требования к конечной системе заранее четко определены и понятны.
- Проект большой или очень большой.
- Основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.
Инкрементальная разработка — это когда мы делаем кусочек продукта, которым может пользоваться клиент. Вообще такой подход похож на кусочки пазлов.
Инкрементная разработка представляет собой процесс частичной реализации всей системы 1С и планомерного наращивания функциональных возможностей. Этот подход дает возможность уменьшить затраты, понесенные до момента достижения уровня исходной производительности. С помощью этой модели ускоряется процесс создания функционирующей системы. Этому способствует применяемый принцип компоновки из блоков, благодаря которому обеспечивается контроль над процессом разработки изменяющихся требований.
Инкрементная модель действует по принципу каскадной модели с перекрытиями, благодаря чему функциональные возможности продукта, пригодные к эксплуатации, формируется раньше. Для этого может понадобиться полный заранее сформированный набор требований, которые выполняются в виде последовательных, небольших по размеру проектов, либо выполнение проекта может начаться с формулирования общих целей, которые затем уточняются и реализуются группами разработчиков.