УСЛУГИ

Заказная разработка программного обеспечения


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

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

Предоставление полного цикла услуг по разработке заказного ПО:

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


Преимущества работы:

  • подтвержденный опыт решения масштабных задач, опыт разработки и поддержки комплексных, сложных ИТ систем в таких отраслях как банки, страхование, гос управление;
  • использование в работе передовых практик и стандартов в области управления проектами;
  • наличие команды высококвалифицированных сертифицированных специалистов (наличие сертифицированных специалистов PMI, IPMA);
  • Наличие готовых отраслевых решений и опыт реальных внедрений;
  • комплексность подхода к решению задач и использование лучших практик в области заказной разработки;
  • возможность организации и проведения обучения технических специалистов клиента и конечных пользователей системы.

IT-аутсорсинг


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

Что же делать спросите вы? Совсем отказаться от разработки программных продуктов и использовать только безумно дорогие решения на базе промышленных продуктов Microsoft, IBM, Oracle или SAP.

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

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

В чем же здесь разница спросите вы? Сидели свои разработчики и мы могли делать с ними все, что захотим, а теперь сидят чужие и "тянут" из нас деньги за всякую ерунду?

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

 

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


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

Проект по проведению аутсорсинга предполагает совместную работу исполнителей со стороны заказчика и команды специалистов по аутсорсингу и состоит из следующих основных работ:
Приём программного проекта. 
Диагностика.
Описание бизнес-процессов и создание (актуализация) пользовательской документации.
Перевод исходного кода и запросов на изменение на систему ApplicationLifecycleManagement (Subversion/Tracи т. п.).
Описание архитектуры приложения, документирование (актуализация документации) структуры базы данных и кода.
Ведение программного проекта. 
Работа с запросами от конечных и ключевых пользователей, формулирование на их основе задач на доработку.
Создание и выполнение приёмочных тестов.
Создание (актуализация) модульных тестов.
Выполнение задач на доработку и исправление ошибок существующего функционала.
Рефакторинг кода.

1. Приём программного проекта

В зависимости от состояния проекта, передаваемого в отдел аутсорсинга, трудозатраты и сроки выполнения работ в части «приём программного проекта» могут различаться. Работы в этой части выполняются, как правило, однократно в начале работы с программным проектом.

1.1. Диагностика

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

Результатами диагностики являются:
Предназначенные для внутреннего пользования экспертные оценки состояния передаваемого на аутсорсинг программного проекта, включающие в себя объективные и субъективные показатели, по которым в дальнейшем оценивается состояние проекта и трудоёмкость работы с ним. В числе показателей указываются:
Объём написанного Delphi-кода (в строках).
Количество Delphi-модулей и форм.
Прочие метрики Delphi-проекта.
Тип используемой СУБД.
Количество таблиц, хранимых процедур и представлений в базе данных.
Объём (в мегабайтах) рабочей базы данных заказчика.
Перечень используемых в проекте компонент сторонних разработчиков.
Наличие пользовательской документации: процент документированности случаев использования системы, субъективная оценка качества документации.
Наличие приёмочных тестов: процент покрытия приёмочными тестами случаев использования системы, способ их выполнения (вручную, с помощью автоматической системы тестирования).
Наличие документации к исходному коду: процент документированности protectedи public-методов и свойств классов программной системы, метод ведения документации (JavaDoc/DelphiDoc, вручную и т. п.), субъективная оценка качества документации.
Наличие модульных тестов: процент покрытия модульными тестами классов бизнес-логики приложения.
Общая субъективная оценка качества проектирования архитектуры программного проекта: отсутствие продуманной архитектуры/спонтанно созданный проект; средний уровень; высококачественный код, строго следующий определённой архитектуре.
Степень удовлетворённости пользователей надёжностью, удобством и быстродействием продукта.
Прочие существенные сведения о программном проекте.
Направляемый клиенту отчёт о проведении диагностики, содержащий в себе:
общее видение проекта, его целей и границ,
некоторые экспертные оценки состояния передаваемого на аутсорсинг проекта, служащие обоснованием для оценок трудоёмкости и стоимости работ по аутсорсингу.
Направляемое клиенту коммерческое предложение.

Этап диагностики считается выполненным, когда сформированы выходные документы и клиенту направлены отчёт о проведении диагностики и коммерческое предложение.

1.2 Описание бизнес-процессов и создание пользовательской документации

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

Целью этапа является:
Детальное изучение и точное описание тех бизнес-процессов, которые автоматизированы системой или которые предполагается автоматизировать в ходе проекта;
Выявление и документирование концептуальных требований клиента к системе;
Уточнение границ проекта;
Уточнение предварительных оценок трудозатрат на последующие этапы проекта;

Этап выполняется в случае, если клиентом принято коммерческое предложение и подписан договор на проведение работ.

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

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

Этап считается выполненным, когда заказчиком приняты документы 1–3.

1.3. Перевод исходного кода и учёта запросов на изменение на систему ApplicationLifecycleManagement

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

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

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

Этап считается выполненным, если:
Авторизованные сотрудники заказчика и отдела аутсорсинга имеют доступ к артефактам проекта на сервере ApplicationLyfecycleManagement через собственные учётные записи, привязанные к лицензиям.
Данных, находящихся на сервере контроля версий, достаточно, чтобы можно было получить все необходимые файлы и скомпилировать проект на чистой машине.
Пользователи заказчика обучены работой с запросами на изменение. Любая дальнейшая работа программистов по проекту производится только при условии наличия назначенного на программиста запроса на изменение (ChangeRequest).

1.4. Описание архитектуры приложения, документирование структуры базы данных и кода

Целью этого этапа является обеспечение работающих над системой программистов сведениями, необходимыми для доработки системы с максимальным использованием существующего кода. Данный этап может производиться параллельно с прочими работами по проекту аутсорсинга после выполнения этапа 1.3 «Перевод исходного кода и учёта запросов на изменение на систему Application Lifecycle Management».

В процессе этого этапа производится
Дополнение исходных кодов комментариями в формате JavaDoc/DelphiDocс описанием функциональности модулей, public/protectedметодов и свойств классов, определённых в interface-секции модуля, типов, функций, процедур и констант, определённых в interface-секции модуля.
Создание документации по структуре базы данных, с описанием таблиц, их полей и связей с другими таблицами, а также представлений, триггеров и хранимых процедур.

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

2. Ведение программного проекта

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

2.1. Работа с запросами от конечных и ключевых пользователей, формулирование на их основе задач на доработку

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

Данная работа может проводиться как целиком усилиями Заказчика, так и быть передана на аутсорсинг. Для эффективного выполнения этой работы организуется helpdesk— система учёта запросов с веб-интерфейсом, доступ к которой имеют все пользователи программной системы (например, Trac).

2.2. Создание и выполнение приёмочных тестов

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

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

Приёмочные тесты выполняются создателями теста после того, как по задаче завершается разработка.

2.3. Создание модульных тестов

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

2.4. Выполнение задач на доработку и исправление ошибок существующего функционала

Все работы по аутсорсингу учитываются в системе учётов запросов на изменение (ChangeRequests), интегрированной в систему ApplicationLfecycleManagement. Никаких трудозатрат, не отнесённых к какой-либо задаче из системы учёта, не производится. При этом выполняются следующие правила:
Первичный ввод задачи (CR) производится ответственным лицом со стороны заказчика в форме системы учёта. При этом обязательно заполняются поля «Заголовок», «Описание» и «Приоритетность. 
В поле «Заголовок» вводится краткое название задачи.
Информация, содержащаяся в текстовом поле «описание» задачи и в прикреплённых файлах, должна как минимум давать чёткое представление о функциональных требованиях, предъявляемых к доработке. Если имеются иные требования или указания по поводу методов решения задачи, они также должны быть включены в описание или прикрепляемые файлы.
В поле «приоритетность» постановщик задачи выбирает значение, которое будет учитываться при выборе очерёдности выполнения задач. Задачи одного приоритета выполняются по мере их поступления, при этом в первую очередь выполняются все задачи более высокого приоритета.
Логически независимые доработки (даже мелкие) должны проходить в системе разными задачами. Не допускается создание задач, содержащих перечень независимых доработок.
После создания задачи постановщик переводит её в состояние «Открыто» (Open), и задача переходит в ведение группы разработчиков аутсорсинга. Группа оценивает качество и реализуемость постановки, даёт предварительные оценки по трудозатратам. В случае, если постановка требует уточнений или реализовать задачу по текущему варианту постановки представляется невозможным, руководитель группы разработки может с помощью отклонить задачу, переведя ответственность на постановщика, переведя задачу в статус «CannotReproduce», из которого в состояние «Open» задача может быть вновь выведена постановщиком после изменения постановки.
Из состояния «Открыто» руководитель группы разработки аутсорсинга назначет исполнителя (программиста) по данной задаче, указывая его в поле «Responsibility», а также устанавливает связь с работой (task), по трудозатратам на которую необходимо отчитываться. Назначенный на задачу программист переводит задачу в состояние «InProgress», и с этого момента начинается фактическая разработка по задаче.
Программистом при чекине модулей в систему контроля версий в поле «LinkandpinprocessItem» указывается ссылка на запрос на изменение, в комментариях в коде также может быть указан идентификатор — в дальнейшем это позволяет отследить причину возникновения того или иного кода в системе.
После завершения разработки и первичного тестирования программист переводит задачу в состояние «Fixed», тем самым инициируя работу тестировщика. Как правило, роли тестировщика и постановщика совпадают. Тестировщик, проверяя результаты работы программиста, может либо вернуть задачу в состояние «Open» с указанием ошибок/недоработок разработчика, либо перевести задачу в состояние «VerifiedFixed», соглашаясь тем самым с проделанной работой.
Протестированная задача из состояния «VerifiedFixed» переводится постановщиком в состояние «ClosedFixed» и становится архивной. В случае возникновения непредвиденных обстоятельств (новые требования, плохо проведённое тестирование) задача может быть возвращена постановщиком в статус «Open», однако при этом она пройдёт полный цикл обработки.
Архивная задача из статуса «ClosedFixed» может быть вновь переведена в статус «Open». Как правило, это происходит при обнаружении программных ошибок или при изменении бизнес-требований по этой задаче.

2.5. Рефакторинг кода

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

Консалтинг


Рынок услуг и продуктов в России динамичен и в определенный момент развития в любой компании встает вопрос о повышении ее эффективности. Не имеет значения, какова проблема и касается ли она организации работы и распределения ответственности, контроля материальных и финансовых потоков, повышения эффекта от загрузки производства или работы склада. Важно как подойти к проблеме, и какие инструменты применить.
Большинством российских компаний опробован традиционный путь — внедрение ИТ решений для автоматизации бизнеса. Уровень понимания эффективности ИТ сейчас довольно высок, существенные вложения в ИТ не всегда дают ожидаемый эффект и практически все компании хотели бы достичь большего. Иными словами в современных ИТ-продуктах заложено множество возможностей для реализации и все обусловлены «лучшей практикой». В этом случае вопросы управления и четкая структура бизнес-задач являются критерием выбора.
Мы используем комплексный подход, основанный на отработанной методологии внедрения и методиках управленческого консультирования, направленных на успех внедрения.
Если ИТ-решение не является подходящим инструментом развития бизнеса, либо допустимы ограниченные изменения в ИТ-поддержке, то предпочтение отдается внутренним изменениям организации взаимодействия и ответственности либо новым методикам работы. Внедрение новых методик работы обычно связано со стремлением достичь либо изменить значения показателей бизнеса.
В своих проектах мы применяем гибкий подход, основанный на понимании специфики различных направлений бизнеса и на применении специальных аналитических инструментов для моделирования сценариев развития и оценки изменений целевых показателей.
Таким образом, основой подхода является:

  • понимание специфики бизнеса наших клиентов;
  • существенный опыт бизнес-консультантов как в области применения ИТ, так и в вопросах управления;
  • наличие методической базы, накопленной за десятилетие работы;
  • совместная работа с опытными командами внедрения передовых ИТ-решений, построенных на продуктах Microsoft и Open Source решениях.


Основные направления консалтинга:

  • анализ, формализация, оптимизация бизнес-процессов. Разработка регламентов бизнес-процессов;
  • разработка методологии анализа и обработки данных на на основе анализа бизнесс процессов пердприятия;
  • разработки методологии внедрения ERP и CRM систем на основе анализа бизнесс процессов пердприятия;
  • сопровождение внедрения ИТ-решений.

Microsoft Dynamics

Компания «Ланселот» является сертифицированным партнёром Microsoft по линейке продуктов Microsoft Dynamics.

Специалисты «Ланселота» имеют многолетний (более 10 лет) активный опыт внедрения системы Microsoft Dynamics NAV, их проектные резюме насчитывают десятки успешных проектов.

«Ланселот» сотрудничает по направлению Navision с крупной международной компанией с 2010г. За этот период был реализован проект по разработке и внедрению системы учета продаж запасных частей и обработки отчетов по гарантийным ремонтам для сети авторизованных сервисных центров на территории России, Украины, Белоруссии и Казахстана на базе платформы Microsoft Dynamics NAV. В рамках проекта были решены задачи по информационному взаимодействию с корпоративной системой SAP/R3 в части передачи финансовых транзакций, а также рядом других специализированных систем. В настоящий момент компанией «Ланселот» осуществляется текущее сопровождение и доработка созданного решения.