Прежде чем говорить об инструментах проектирования, хотелось бы остановиться на немаловажном вопросе: «для чего нужно проектирование информационных систем?». Достаточно популярным, особенно в среде 1С специалистов, является мнение что проектирование системы - это лишние трудозатраты. Я бы сказал, оно не безосновательно. Многие из задач при внедрении систем являются довольно стандартными и требуют лишь трудозатрат на разработку. Очень часто не создается новых механизмов и инструментов, а лишь «дотачиваются» существующие, притом под нужды заказчика, которые регулярно меняются.
В этом случае формальный процесс проектирования навряд ли имеет смысл. Речь идет именно о формализации процесса, т.к. сам процесс проектирования является неотъемлемой частью разработки и конечно будет присутствовать, пусть даже только в голове разработчика.
А когда проектирование имеет смысл:
- Есть общая стратегия компании, и развитие ИТ систем – часть этой стратегии.
- Есть понимание от менеджмента какие задачи требуется решить посредством внедрения/развития информационной системы.
- Есть формальное понимание/описание бизнес процессов компании, или планируется его создание.
Ниже схематично представлены предпосылки к созданию проекта системы:
Собственно, все начинается со стратегии. Инструментарий для создания стратегии компании редко бывает специализированным. Это скорее нечто, что должно быть в голове у топ менеджера. Далее строится модель бизнес процессов (которая должна присутствовать для достижения стратегических целей). Здесь уже в ход идут инструменты моделирования – ARIS, BusinessStudio. И только после этого речь заходит о модели ИТ процессов. У «продвинутых» западных вендоров для этого есть специализированные средства – УSAPинтегрированный ARIS, у IBM– RUP, у Microsoft – MSF, интегрированная в VisualStudio. Вот и у 1С появился собственный инструмент – 1С:СППР.
Теперь возникает второй вопрос: «А как на практике используется 1С:СППР»? В данном случае могу рассказать только о своей личной практике. К сожалению, она может не совпадать с тем, для чего в 1С планировали 1С:СППР. В моей практике 1С:СППР использовался для следующих задач:
Из рисунка, пожалуй, все понятно – в систему заносится информация исходя из текущих моделей бизнес процессов – проектируется модель системы: процессы и функции, которые декомпозируются до уровня метаданных и алгоритмов. Далее генерируются документы – спецификации на разработку, проектные решения и даже пользовательская документация.
Стоит отметить, что в данном случае речь идет не столько об 1С:СППР, сколько о системе, которая была разработана на ее основе, путем внесения достаточно существенных модификаций. Дело в том, что первая версия 1С:СППР, когда нам требовался подобный инструмент, не отвечала нашим требованиям, да и вообще вряд ли могла отвечать чьим либо требованиям:
Но это уже было кое-что, за что можно «зацепиться» и разработать полнофункциональный инструмент. К счастью, 1С вели разработки 1С:СППР параллельно нашей, и большую часть из того, что приходилось добавлять на текущий момент времени уже реализовано в типовой конфигурации.
В итоге, все функции, которые, на мой взгляд, должны лечь на 1С:СППР можно разбить на следующие 4 части:
1) Функции моделирования
a. Модель системы, связь с моделью БП (в разных нотациях)
b. Связь модели системы с метаданными и алгоритмами 1С
c. Интеграция со средами моделирования
2) Функции коллективной работы
a. Работа с требованиям
b. Работа с ошибками
3) Функции документирования
a. Связь документации с моделью
b. Экспорт документации в 1С и Word
4) Функции организации разработки и тестирования
a. Спецификации и задачи на разработку
b. Результаты тестирования и отработки ошибок
В типовой 1С:СППР очень хорошо реализован блок (1), за исключением того, что хотелось бы конечно иметь возможность представлять модель в разных нотациях. Нам была ближе EPC, в 1С:СППР реализована только IDEF0.
Функции коллективной работы в текущей версии реализованы в полном объеме, на мой взгляд конечно, чаще всего это необходимо при работе с ошибками и требованиями.
С документированием возникают уже проблемы. Основной функционал, которого не хватает 1С:СППР – экспорт в Word. Ведь итогом работы проектировщика должна быть спецификация на разработку (ТЗ/ЧТЗ – кто как называет). А спецификация - это нечто, что человек должен иметь возможность прочитать; то есть текстовый файл. Опять же, вордовским файлом должна оформляться документация по системе и проектная документация. Но традиционно 1С не сильно любит интегрироваться с продуктами MicrosoftOffice. Это противоречит принципам кроссплатформенности, делает решение зависимым от внешних приложений и существенно увеличивает сложность разработки.
Функционала для организации разработки и тестирования в 1C:СППР просто не существует. Хотя не понятно почему. Редко встретишь опытного разработчика, который хоть раз в своей жизни не написал бы систему учета задач. Если ориентироваться на тот же SAP– в SolutionManagerесть как функционал проектирования так и полноценный ServiceDesk.
Собственно, данный функционал относительно СППР был доработан – основные доработки 1С:СППР касались вывода в Word и создания системы учета задач.
Теперь более подробно рассмотрим функционал типовой 1С:СППР новой версии:
Итак, относительно первой версии появилось много чего интересного:
1) Нормальная работа с метаданными – загрузка метаданных непосредственно из конфигурации, представление, дополнительные свойства объектов метаданных. На разработку подобного функционала в первой версии мы потратили значительное количество времени.
2) Моделирование системы в нотации IDEF. 1С много затратили на разработку данного функционала. Действительно существенный шаг вперед, но, как писал выше, для нас оказалась привычнее и удобнее нотация EPC. Она в 1С:СППР, к сожалению, не реализована.
3) Сбор требований. Функционал очень нужный на проектах.
4) ERмодель метаданных. Первое впечатление было «мечта студента». Если кто-то писал диплом по 1С это бы существенно помогло. На самом деле функционал очень полезен и в повседневной рабочей практике. Даже просто загрузив в 1С:СППР механизмы типового прикладного решения построив ERдиаграмму по нужным объектам можно гораздо быстрее и проще разобраться как работает тот или иной механизм. О пользе подобных диаграмм при составлении спецификаций можно и не говорить. За данную возможность можно сказать «большое спасибо».
5) Работа с ошибками, тоже очень нужный, но достаточно простой механизм системы.
6) Есть даже инструментарий для написания справочной информации. Он не очень мощный и удобный больше вследствие ограниченности встроенного в 1С редактора текстов, но привязка справки к метаданным и экспорт справочных файлов очень удобный функционал, которым теперь можно пользоваться.
Как у нас используется 1С:СППР. Вполне возможно наш случай – не типичный сценарий, как его планировали 1С. Общая схема выглядит примерно следующим образом:
Скорее всего в типовом сценарии использования, предусмотренным 1С, не подразумевается работа в системе тестировщиков и разработчиков. Так же не предусмотрено детальное описание алгоритмов.
Итак, что мы получаем от использования 1С:СППР:
1) Разработчики отделены от проектировщиков. BestPractice из SAPwelcome. Наверное, это правильно, но для того, чтобы это было возможно, система просто необходима. В то же время, при наличии такой системы мы можем сказать, что практически любой разработчик способен выполнять работы практически по любой задаче. Это «открывает двери». Например сегодня у вас 3 разработчика, а завтра может стать 30… т.е. варианты для привлечения внешних подрядчиков не ограничены.
2) Генерация проектной документации. В нашем случае ее просто тома. Представьте к примеру задачу описать все метаданные УПП… 1С:СППР просто в десятки раз упрощает данный процесс.
3) Учет задач – когда он интегрирован это очень удобно. Разработчик может сразу видеть все по назначенной задаче. При необходимости может подняться «уровнем выше» чтобы что-то понять/уточнить для себя. Как проектировщик так и разработчик могут оценивать трудозатраты на разработку и согласовывать оценки. Разработчик может писать вопросы к спецификациями и оперативно наблюдать изменения в них
4) Весь проект есть в системе. По каждому объекту метаданных вы можете отследить когда, для чего и зачем он был сделан.
Мы уже пошли в чем то дальше чем 1С:СППР в развитии системы, но есть вещи которых нахватает как в нашей системе так и в типовой 1С:СППР:
1) Управление изменениями. Что поменялось, кто согласовал? На что повлияет это изменение. Очень важный момент, конечно сложный в реализации, но управление изменениями сразу вывело бы систему на новый уровень и повысило бы ее полезность.
2) Связь с хранилищем конфигурации. Конечно последнего этапа в цепочке не хватает немного. Если бы в системе можно было получить информацию по какому заданию/спецификации была эта разработка?
3) Интеграции с ARIS/Business Studio. К сожалению, встроенные средства 1С существенно проигрывают специализированным в плане удобства и функциональности для постраения диаграмм EPC/IDEF.
Итого, 1С:СППР очень функциональный и полезный в практике продукт. Очевидно, что 1С движется в правильном направлении. Может что-то еще не так, чего-то не хватает, поэтому с нетерпением ждем развития системы, ну или дорабатываем сами.
Начать дискуссию