Факторы, влияющие на адаптацию первоклассников
Адаптационный период первоклассников является важной ступенью в их познавательно-обучающем процессе. Родители, учителя и...
Прежде чем говорить об инструментах проектирования, хотелось бы остановиться на немаловажном вопросе: «для чего нужно проектирование информационных систем? ». Достаточно популярным, особенно в среде 1С специалистов, является мнение что проектирование системы - это лишние трудозатраты. Я бы сказал, оно не безосновательно. Многие из задач при внедрении систем являются довольно стандартными и требуют лишь трудозатрат на разработку. Очень часто не создаётся новых механизмов и инструментов, а лишь «дотачиваются» существующие, притом под нужды заказчика, которые регулярно меняются. В этом случае формальный процесс проектирования навряд ли имеет смысл. Речь идет именно о формализации процесса, т.к. сам процесс проектирования является неотъемлемой частью разработки и конечно будет присутствовать, пусть даже только в голове разработчика.
А когда проектирование имеет смысл:
1)
Есть общая стратегия компании, и развитие ИТ систем - часть этой стратегии.2)
Есть понимание от менеджмента какие задачи требуется решить посредством внедрения/развития информационной системы.3)
Есть формальное понимание/описание бизнес процессов компании, или планируется его создание.Ниже схематично представлены предпосылки к созданию проекта системы:
Собственно, всё начинается со стратегии. Инструментарий для создания стратегии компании редко бывает специализированным. Это скорее нечто, что должно быть в голове у топ менеджера. Далее строится модель бизнес процессов (которая должна присутствовать для достижения стратегических целей). Здесь уже в ход идут инструменты моделирования - ARIS , Business Studio . И только после этого речь заходит о модели ИТ процессов. У «продвинутых» западных вендоров для этого есть специализированные средства - УSAP интегрированный ARIS , у IBM - RUP , у Microsoft - MSF , интегрированная в Visual Studio . Вот и у 1С появился собственный инструмент - 1С:СППР.
Теперь возникает второй вопрос: «А как на практике используется 1С:СППР »? В данном случае могу рассказать только о своей личной практике. К сожалению, она может не совпадать с тем, для чего в 1С планировали 1С:СППР. В моей практике 1С:СППР использовался для следующих задач:
Из рисунка, пожалуй, всё понятно - в систему заносится информация исходя из текущих моделей бизнес процессов - проектируется модель системы: процессы и функции, которые декомпозируются до уровня метаданных и алгоритмов. Далее генерируются документы - спецификации на разработку, проектные решения и даже пользовательская документация.
Стоит отметить, что в данном случае речь идёт не столько об 1С:СППР, сколько о системе, которая была разработана на её основе, путём внесения достаточно существенных модификаций. Дело в том, что первая версия 1С:СППР, когда нам требовался подобный инструмент, не отвечала нашим требованиям, да и вообще вряд ли могла отвечать чьим либо требованиям:
Но это уже было кое-что, за что можно «зацепиться» и разработать полнофункциональный инструмент. К счастью, 1С вели разработки 1С:СППР параллельно нашей, и большую часть из того, что приходилось добавлять на текущий момент времени уже реализовано в типовой конфигурации.
В итоге, все функции, которые, на мой взгляд, должны лечь на 1С:СППР можно разбить на следующие 4 части:
1)
Функции моделированияa.
Модель системы, связь с моделью БП (в разных нотациях)b.
Связь модели системы с метаданными и алгоритмами 1Сc.
Интеграция со средами моделирования2)
Функции коллективной работыa.
Работа с требованиямb.
Работа с ошибками3)
Функции документированияa.
Связь документации с модельюb.
Экспорт документации в 1С и Word4) Функции организации разработки и тестирования
a. Спецификации и задачи на разработку
b. Результаты тестирования и отработки ошибок
В типовой 1С:СППР очень хорошо реализован блок (1), за исключением того, что хотелось бы конечно иметь возможность представлять модель в разных нотациях. Нам была ближе EPC , в 1С:СППР реализована только IDEF 0.
Функции коллективной работы в текущей версии реализованы в полном объёме, на мой взгляд конечно, чаще всего это необходимо при работе с ошибками и требованиями.
С документированием возникают уже проблемы. Основной функционал, которого не хватает 1С:СППР - экспорт в Word . Ведь итогом работы проектировщика должна быть спецификация на разработку (ТЗ/ЧТЗ - кто как называет). А спецификация - это нечто, что человек должен иметь возможность прочитать; то есть текстовый файл. Опять же, вордовским файлом должна оформляться документация по системе и проектная документация. Но традиционно 1С не сильно любит интегрироваться с продуктами Microsoft Office . Это противоречит принципам кроссплатформенности, делает решение зависимым от внешних приложений и существенно увеличивает сложность разработки.
Функционала для организации разработки и тестирования в 1 C :СППР просто не существует. Хотя не понятно почему. Редко встретишь опытного разработчика, который хоть раз в своей жизни не написал бы систему учета задач. Если ориентироваться на тот же SAP - в Solution Manager есть как функционал проектирования так и полноценный Service Desk .
Собственно, данный функционал относительно СППР был доработан - основные доработки 1С:СППР касались вывода в Word и создания системы учета задач .
Теперь более подробно рассмотрим функционал типовой 1С:СППР новой версии:
Итак, относительно первой версии появилось много чего интересного:
1) Нормальная работа с метаданными - загрузка метаданных непосредственно из конфигурации, представление, дополнительные свойства объектов метаданных. На разработку подобного функционала в первой версии мы потратили значительное количество времени.
2) Моделирование системы в нотации IDEF . 1С много затратили на разработку данного функционала. Действительно существенный шаг вперед, но, как писал выше, для нас оказалась привычнее и удобнее нотация EPC . Она в 1С:СППР, к сожалению, не реализована.
3) Сбор требований. Функционал очень нужный на проектах.
4) ER модель метаданных. Первое впечатление было «мечта студента». Если кто-то писал диплом по 1С это бы существенно помогло. На самом деле функционал очень полезен и в повседневной рабочей практике. Даже просто загрузив в 1С:СППР механизмы типового прикладного решения построив ER диаграмму по нужным объектам можно гораздо быстрее и проще разобраться как работает тот или иной механизм. О пользе подобных диаграмм при составлении спецификаций можно и не говорить. За данную возможность можно сказать «большое спасибо».
5) Работа с ошибками, тоже очень нужный, но достаточно простой механизм системы.
6) Есть даже инструментарий для написания справочной информации. Он не очень мощный и удобный больше вследствие ограниченности встроенного в 1С редактора текстов, но привязка справки к метаданным и экспорт справочных файлов очень удобный функционал, которым теперь можно пользоваться.
Как у нас используется 1С:СППР
. Вполне возможно наш случай - не типичный сценарий, как его планировали 1С. Общая схема выглядит примерно следующим образом:
В
Скорее всего в типовом сценарии использования, предусмотренным 1С, не подразумевается работа в системе тестировщиков и разработчиков. Так же не предусмотрено детальное описание алгоритмов.
Итак, что мы получаем от использования 1С:СППР:
1) Разработчики отделены от проектировщиков. Best Practice из SAP welcome . Наверное, это правильно, но для того, чтобы это было возможно, система просто необходима. В то же время, при наличии такой системы мы можем сказать, что практически любой разработчик способен выполнять работы практически по любой задаче. Это «открывает двери». Например сегодня у вас 3 разработчика, а завтра может стать 30… т.е. варианты для привлечения внешних подрядчиков не ограничены.
2) Генерация проектной документации.В нашем случае её просто тома. Представьте к примеру задачу описать все метаданные УПП… 1С:СППР просто в десятки раз упрощает данный процесс.
3) Учет задач - когда он интегрирован это очень удобно. Разработчик может сразу видеть всё по назначенной задаче. При необходимости может подняться «уровнем выше» чтобы что-то понять/уточнить для себя. Как проектировщик так и разработчик могут оценивать трудозатраты на разработку и согласовывать оценки. Разработчик может писать вопросы к спецификациями и оперативно наблюдать изменения в них
4) Весь проект есть в системе. По каждому объекту метаданных вы можете отследить когда, для чего и зачем он был сделан.
1) Управление изменениями. Что поменялось, кто согласовал? На что повлияет это изменение. Очень важный момент, конечно сложный в реализации, но управление изменениями сразу вывело бы систему на новый уровень и повысило бы её полезность.
2) Связь с хранилищем конфигурации. Конечно последнего этапа в цепочке не хватает немного. Если бы в системе можно было получить информацию по какому заданию/спецификации была эта разработка?
3) Интеграции с ARIS/Business Studio. К сожалению, встроенные средства 1С существенно проигрывают специализированным в плане удобства и функциональности для постраения диаграмм EPC / IDEF .
Итого, 1С:СППР очень функциональный и полезный в практике продукт. Очевидно, что 1С движется в правильном направлении. Может что-то ещё не так, чего-то не хватает, поэтому с нетерпением ждём развития системы, ну или дорабатываем сами.
************
Приглашаем вас на новую конференцию .
Прежде чем говорить об инструментах проектирования, хотелось бы остановиться на немаловажном вопросе: «для чего нужно проектирование информационных систем? ». Достаточно популярным, особенно в среде 1С специалистов, является мнение что проектирование системы - это лишние трудозатраты. Я бы сказал, оно не безосновательно. Многие из задач при внедрении систем являются довольно стандартными и требуют лишь трудозатрат на разработку. Очень часто не создаётся новых механизмов и инструментов, а лишь «дотачиваются» существующие, притом под нужды заказчика, которые регулярно меняются. В этом случае формальный процесс проектирования навряд ли имеет смысл. Речь идет именно о формализации процесса, т.к. сам процесс проектирования является неотъемлемой частью разработки и конечно будет присутствовать, пусть даже только в голове разработчика.xml:namespace prefix = "o" ns = "urn:schemas-microsoft-com:office:office" /
А когда проектирование имеет смысл:
1) Есть общая стратегия компании, и развитие ИТ систем – часть этой стратегии.
2) Есть понимание от менеджмента какие задачи требуется решить посредством внедрения/развития информационной системы.
3) Есть формальное понимание/описание бизнес процессов компании, или планируется его создание.
Ниже схематично представлены предпосылки к созданию проекта системы:
xml:namespace prefix = "v" ns = "urn:schemas-microsoft-com:vml" /
Собственно, всё начинается со стратегии. Инструментарий для создания стратегии компании редко бывает специализированным. Это скорее нечто, что должно быть в голове у топ менеджера. Далее строится модель бизнес процессов (которая должна присутствовать для достижения стратегических целей). Здесь уже в ход идут инструменты моделирования –
ARIS , Business Studio . И только после этого речь заходит о модели ИТ процессов. У «продвинутых» западных вендоров для этого есть специализированные средства – У SAP интегрированный ARIS , у IBM – RUP , у Microsoft – MSF , интегрированная в Visual Studio . Вот и у 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С:СППР реализована только IDEF 0.
Функции коллективной работы в текущей версии реализованы в полном объёме, на мой взгляд конечно, чаще всего это необходимо при работе с ошибками и требованиями.
С документированием возникают уже проблемы. Основной функционал, которого не хватает 1С:СППР – экспорт в Word . Ведь итогом работы проектировщика должна быть спецификация на разработку (ТЗ/ЧТЗ – кто как называет). А спецификация - это нечто, что человек должен иметь возможность прочитать; то есть текстовый файл. Опять же, вордовским файлом должна оформляться документация по системе и проектная документация. Но традиционно 1С не сильно любит интегрироваться с продуктами Microsoft Office . Это противоречит принципам кроссплатформенности, делает решение зависимым от внешних приложений и существенно увеличивает сложность разработки.
Функционала для организации разработки и тестирования в 1 C :СППР просто не существует. Хотя не понятно почему. Редко встретишь опытного разработчика, который хоть раз в своей жизни не написал бы систему учета задач. Если ориентироваться на тот же SAP – в Solution Manager есть как функционал проектирования так и полноценный Service Desk .
Собственно, данный функционал относительно СППР был доработан – основные доработки 1С:СППР касались вывода в Word и создания системы учета задач .
Теперь более подробно рассмотрим функционал типовой 1С:СППР новой версии:
Итак, относительно первой версии появилось много чего интересного:
1) Нормальная работа с метаданными – загрузка метаданных непосредственно из конфигурации, представление, дополнительные свойства объектов метаданных. На разработку подобного функционала в первой версии мы потратили значительное количество времени.
2) Моделирование системы в нотации IDEF . 1С много затратили на разработку данного функционала. Действительно существенный шаг вперед, но, как писал выше, для нас оказалась привычнее и удобнее нотация EPC . Она в 1С:СППР, к сожалению, не реализована.
3) Сбор требований. Функционал очень нужный на проектах.
4) ER модель метаданных. Первое впечатление было «мечта студента». Если кто-то писал диплом по 1С это бы существенно помогло. На самом деле функционал очень полезен и в повседневной рабочей практике. Даже просто загрузив в 1С:СППР механизмы типового прикладного решения построив ER диаграмму по нужным объектам можно гораздо быстрее и проще разобраться как работает тот или иной механизм. О пользе подобных диаграмм при составлении спецификаций можно и не говорить. За данную возможность можно сказать «большое спасибо».
5) Работа с ошибками, тоже очень нужный, но достаточно простой механизм системы.
6) Есть даже инструментарий для написания справочной информации. Он не очень мощный и удобный больше вследствие ограниченности встроенного в 1С редактора текстов, но привязка справки к метаданным и экспорт справочных файлов очень удобный функционал, которым теперь можно пользоваться.
Как у нас используется 1С:СППР . Вполне возможно наш случай – не типичный сценарий, как его планировали 1С. Общая схема выглядит примерно следующим образом:
Скорее всего в типовом сценарии использования, предусмотренным 1С, не подразумевается работа в системе тестировщиков и разработчиков. Так же не предусмотрено детальное описание алгоритмов.
Итак, что мы получаем от использования 1С:СППР:
1) Разработчики отделены от проектировщиков. Best Practice из SAP welcome . Наверное, это правильно, но для того, чтобы это было возможно, система просто необходима. В то же время, при наличии такой системы мы можем сказать, что практически любой разработчик способен выполнять работы практически по любой задаче. Это «открывает двери». Например сегодня у вас 3 разработчика, а завтра может стать 30… т.е. варианты для привлечения внешних подрядчиков не ограничены.
2) Генерация проектной документации.В нашем случае её просто тома. Представьте к примеру задачу описать все метаданные УПП… 1С:СППР просто в десятки раз упрощает данный процесс.
3) Учет задач – когда он интегрирован это очень удобно. Разработчик может сразу видеть всё по назначенной задаче. При необходимости может подняться «уровнем выше» чтобы что-то понять/уточнить для себя. Как проектировщик так и разработчик могут оценивать трудозатраты на разработку и согласовывать оценки. Разработчик может писать вопросы к спецификациями и оперативно наблюдать изменения в них
4) Весь проект есть в системе. По каждому объекту метаданных вы можете отследить когда, для чего и зачем он был сделан.
1) Управление изменениями. Что поменялось, кто согласовал? На что повлияет это изменение. Очень важный момент, конечно сложный в реализации, но управление изменениями сразу вывело бы систему на новый уровень и повысило бы её полезность.
2) Связь с хранилищем конфигурации. Конечно последнего этапа в цепочке не хватает немного. Если бы в системе можно было получить информацию по какому заданию/спецификации была эта разработка?
3) Интеграции с ARIS/Business Studio. К сожалению, встроенные средства 1С существенно проигрывают специализированным в плане удобства и функциональности для постраения диаграмм EPC / IDEF .
Итого, 1С:СППР очень функциональный и полезный в практике продукт. Очевидно, что 1С движется в правильном направлении. Может что-то ещё не так, чего-то не хватает, поэтому с нетерпением ждём развития системы, ну или дорабатываем сами.
В этой статье мы попытаемся рассказать, как с помощью удаленных и территориально распределенных команд мы наладили процесс выпуска прикладных решений, расширяющих функциональность нашего продукта «1С:ERP Управление предприятием 2».
«1С:ERP 2» - решение, автоматизирующее бОльшую часть процессов многопрофильных предприятий. Но есть целые классы задач и отраслевых особенностей, требующих более детальной проработки, нежели она есть в «1С:ERP 2» – торговля, логистика, управление складом, строительство, сельское хозяйство и т.д. Включать эту функциональность в типовое решение нецелесообразно, т.к. это приведет к усложнению работы большинства пользователей. К тому же у нас самих может не хватить ресурсов для полноценной реализации требуемой функциональности.
Итак, перед нами стоит задача создания отраслевых/специализированных решений, которые:
График качества
Цель – единая бесшовная информационно-управленческая система, построенная на базе «1C:ERP» и других решениях «1С:Предприятие 8»:
Была разработана концепция модульного подхода в архитектуре решений на базе «1С:ERP». Концепция определяет принципы разработки, унификации и интеграции различных конфигураций в рамках единой системы управления и учета.
Все решения в рамках программы «1С-Совместно», расширяющие возможности «1С:ERP», должны следовать концепции модульного подхода. Ключевыми задачами модульного подхода являются:
На момент написания статьи количество уже выпущенных решений линейки – 31 (18 партнеров-разработчиков), с учетом планов разработки, во 2 квартале 2017г. количество решений достигнет 52 (24 партнера-разработчика).
СППР может быть использована как в качестве инструмента для проектирования новых информационных систем, разрабатываемых в среде «1С:Предприятия 8», так и для описания и документирования существующих систем, разработанных ранее без использования СППР.
Мы выбрали СППР как наиболее удобный и подходящий для наших задач и соответствующий выдвигаемым нами требованиям к CASE-средству:
Цели
Для проектируемой функциональности создаются соответствующие технические проекты, с назначением ответственных со стороны партнера-разработчика. В рамках одного технического проекта возможен выпуск сразу нескольких вариантов поставки функциональности (собственно, самих продуктов).
Каждому техническому проекту назначаются плановый срок завершения (управляет и контролирует руководитель направления), и устанавливаются сроки этапов выполнения технического проекта.
Партнер-разработчик указывает сроки контрольных точек в рамках общей длительности проекта. При превышении срока выполнения одного из этапов информация попадает на контроль ответственному менеджеру. Также ответственный менеджер видит сроки выполнения каждого этапа (в том числе и просроченные). Каждый этап завершается согласованием контрольной точки ответственным.
Мы не ставим задачи управлять процессом разработки на стороне партнеров. Каждый партнер применяет собственную устоявшуюся в коллективе методику. Мы контролируем только сроки важных для нас контрольных точек и регулируем результаты необходимыми стандартами и регламентами, знакомство с которыми и их применение также контролируем.
В рамках технических проектов планируются и выполняются не только работы по разработке новой функциональности, но и проведение нагрузочных тестов, унификация общей функциональности, минимизация изменений объектов метаданных типовой конфигурации.
Целостность и непротиворечивость функциональной модели модерируется функциональным архитектором проекта, назначенным со стороны «1С».
Описание нотации СППР
В рамках СППР основные понятия трактуются следующим образом:
Например, «1С:ERP Управление строительной организацией 2» (партнер – разработчик «1С-Рарус») содержит в своем составе:
Библиотека предоставляет собой инструментарий для разработчиков решений «1С:Совместно», содержащий набор универсальных функциональных подсистем, готовые разделы для пользовательской документации и технологию для интеграции в отраслевые и специализированные решения с целью унификации в рамках единой линейки, что позволяет:
Примеры отчетов
Предпроизводственная проверка выполняется в рамках регламента и включает в себя как ручную, так и автоматизированную проверку переданных материалов.
Партнер-разработчик несет ответственность за качество тестирования, комплектность материалов и передает материалы фирме «1С» для проверки перед выпуском полностью работоспособными, протестированными, соответствующими требованиям сертификации «1С:Совместимо», «Системе стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8» и требованиям Регламентов взаимодействия с разработчиками совместных решений.
Также рассматривается возможность включения дополнительных проверок на соответствие функциональной модели в базе СППР ОР/СР: контроль соответствия заявленной функциональности ОР/СР реализованному и контроль соответствия модификации объектов типовой конфигурации заявленным в СППР ОР/СР.
Сервис «1С:Облачная карта решений» предоставляет доступ к функциональным моделям ряда решений фирмы «1С», а также отраслевых и специализированных решений, выпускаемых по схеме 1С-Совместно. Актуализация функциональной модели обеспечивается прямым обращением к веб-сервису базы «СППР для отраслевых и специализированных решений», модель решений в которой поддерживается в актуальном состоянии в соответствии с Концепцией модульного подхода в архитектуре решений на базе «1С:ERP Управление предприятием 2».
Фирма "1С" объявляет о выпуске программного продукта:
Система проектирования прикладных решений (СППР) предназначена для проектирования прикладных решений (конфигураций) на платформе "1С:Предприятие" и ведения технической документации проекта. СППР может быть использована как инструмент для проектирования новых информационных систем, разрабатываемых в среде "1С:Предприятия 8", а также для описания и документирования существующих систем, разработанных ранее без использования СППР.
СППР представляет собой конфигурацию, предназначенную для использования с платформой "1С:Предприятие 8.3".
СППР предоставляет возможность ведения информации о различных разрабатываемых конфигурациях в рамках одной информационной базы , с возможностью разграничения доступа по конфигурациям-проектам.
Конфигурация позволяет создать логическую модель информационной системы, исходя из автоматизируемых процессов.
В основе логического проектирования при помощи СППР лежит функциональная декомпозиция сложных систем с применением стандарта IDEF0. Это позволяет в простой и наглядной форме описывать проектируемую систему с необходимой степенью детализации. Логическая модель строится с учетом процессов, которые планируется автоматизировать, при этом она увязывает исполнителей, рабочие места и информационные потоки. Логическая модель соотносится с метаданными конфигурации.
Функционал СППР включает механизмы управления требованиями и изменениями в проекте . Использование данного функционала позволяет органично внести в имеющийся проект изменения, увязав их с существующей логической моделью.
Наличие формальных правил проверки дает возможность выявить и устранить ошибки и несоответствия в проекте.
Система включает механизмы регистрации и отслеживания ошибок с учетом включаемых конфигураций-библиотек.
СППР позволяет формировать тексты справки с учетом взаимосвязей объектов конфигурации. Справка оформляется в едином стиле. Подготовленные тексты справки могут быть загружены непосредственно в разрабатываемую конфигурацию средствами конфигуратора.
Встроенные механизмы выгрузки-загрузки данных по проектам позволяют организовать публикацию проектной информации для возможности использования и работы с этой информацией в других информационных базах СППР.
Система поддерживает работу в режиме тонкого и веб-клиента.
Информация о системе представлена на сайте по адресу http://v8.1c.ru/model/ . По адресу http://modeling.demo.1c.ru/modeling/ доступна работающая в режиме "онлайн" демоверсия системы.
Программный продукт "1С:Предприятие 8. Система проектирования прикладных решений" включает дистрибутив конфигурации "Система проектирования прикладных решений", документацию по использованию продукта, лицензионное соглашение, регистрационную карточку и пинкод для регистрации на сайте поддержки пользователей. Для использования СППР необходимо наличие у пользователя правомерно приобретенного программного продукта версии ПРОФ или КОРП, включающего платформу "1С:Предприятие". Необходимо использовать версию платформы не ниже 8.3.3.
В поставку продукта входит документация, которая также может приобретаться отдельно:
Зарегистрированные пользователи программного продукта "1С:Предприятие 8. Система проектирования прикладных решений", заключившие договор 1С:ИТС, могут приобретать дополнительные экземпляры документации в необходимом количестве в соответствии с регламентом, описанным в информационном письме №8538 от 20.06.2008 года .
Поддержка пользователей осуществляется по договору информационно-технологического сопровождения системы "1С:Предприятие" (1С:ИТС), заключенному на любую основную поставку, принадлежащую пользователю.
Услуги сопровождения 1С:ИТС включают:
Действующий порядок сопровождения программных продуктов фирмы "1С" опубликован по адресу
Назначение системыСистема проектирования прикладных решений (СППР) предназначена для проектирования прикладных решений (конфигураций) на платформе «1С:Предприятие» и ведения технической документации проекта. СППР может быть использована как в качестве инструмента для проектирования новых информационных систем, разрабатываемых в среде «1С:Предприятия 8», так и для описания и документирования существующих систем, разработанных ранее без использования СППР.
Система проектирования прикладных решений разработана как конфигурация на платформе «1С:Предприятие 8.3».
Использование СППР позволяет:
Руководителям проектов
Разработчикам
Техническим писателям
Тестерам
Внедренцам
Упростить освоение конфигурации пользователями, формировать инструкции по работе с конкретным функционалом.
При проектировании информационной системы описываются автоматизируемые процессы. Исходя из описания процессов, строится логическая модель проектируемой системы. На основании логической модели строится физическая модель, воплощаемая в метаданных разрабатываемой конфигурации.
При необходимости внесения изменений в проект используется механизм технических проектов. Изменения основываются на принятых требованиях и документируются c привязкой к изменяемым процессам, а также объектам логической и физической модели.
Описание автоматизируемых процессов
При проектировании конфигурации важно, чтобы ее функционал отвечал реальным потребностям предприятий. Поэтому важно очертить тот круг процессов, которые позволяет автоматизировать информационная система.
СППР позволяет зафиксировать перечень автоматизируемых процессов, процессы при этом могут быть сгруппированы по усмотрению пользователя.
Процесс детализируется до отдельных шагов, исполняемых конкретным исполнителем.
Создание логической модели проектируемой системы
Логическая модель системы позволяет описать функциональность конфигурации, увязав ее с составом обрабатываемой информации и исполнителями.
Логическая модель в СППР строится с использованием методологии IDEF0. В рамках создания логической модели описываются функции системы и производится их декомпозиция.
Основой описания функции является ее IDEF- схема. Схема позволяет в наглядной форме отразить взаимосвязь отдельных (дочерних) функций, потоков данных и исполнителей.
Разработка архитектуры
Разработка архитектуры конфигурации выполняется на основе логической модели. При этом метаданные соотносятся с объектами данных, перечень которых определяется при разработке функций.
Проектирование интерактивных операций
При работе с системой в рамках того или иного процесса пользователь выполняет определенные действия, реализуя таким образом один из возможных сценариев работы.
Описание последовательностей интерактивных операций, выполняемых пользователем в системе, позволяет проанализировать, реализуем ли закладываемый в систему функционал в рамках конкретного автоматизируемого процесса.
Подготовка справки
СППР позволяет автоматически формировать тексты справки для разрабатываемой конфигурации. Подготовленные тексты справки в формате html могут быть выгружены из СППР и загружены в конфигурацию штатными средствами конфигуратора.
Справка формируется в едином стиле, с использованием единой структуры описания, исходя из взаимосвязей подсистем, объектов метаданных и операций функций. Стили оформления справки (шрифты, отступы, выделения) могут настраиваться непосредственно в СППР.
Работа с требованиями
Управление проектом и изменениями
Для управления проектом и изменениями в СППР используется функциональность ведения технических проектов. Данная функциональность позволяет организовать коллективную работу над проектом, с отслеживанием прохождения различных этапов проекта. При этом возможна гибкая настройка этапов, согласование этих этапов, уведомление участников команды разработки об изменениях.
Использование технических проектов обеспечивает внесение изменений в имеющийся проект таким образом, чтобы эти изменения были увязаны с логической моделью, были прозрачны и информативны для других участников проекта
Работа с ошибками
СППР позволяет вести регистрацию ошибок по разрабатываемым проектам, в разрезе версий, сроков исправления, разделов проекта, статусов и т.д. Функционал системы предлагает готовую методику работы с ошибками, с возможностью формирования различных отчетов, публикации информации об ошибках. Система позволяет настроить связи между проектами, указать, какие проекты-библиотеки включаются в проект, с учетом конкретных версий проектов. Это позволяет получать информацию о наличии в проекте ошибок, источниками которых являются используемые библиотеки.
Прочие возможности
Помимо перечисленных возможностей, СППР содержит следующую функциональность: