Перш ніж говорити про інструменти проектування, хотілося б зупинитися на важливому питанні: «для чого потрібне проектування інформаційних систем?». Досить популярною, особливо в середовищі 1С фахівців, є думка, що проектування системи - це зайві трудовитрати. Я сказав би, воно не безпідставне. Багато завдань при впровадженні систем є досить стандартними і вимагають лише трудовитрат на розробку. Дуже часто не створюється нових механізмів та інструментів, а лише «доточуються» існуючі, причому під потреби замовника, які регулярно змінюються.
І тут формальний процес проектування навряд чи має сенс. Йдеться про формалізації процесу, т.к. сам процес проектування є невід'ємною частиною розробки і, звичайно, буде присутнім, нехай навіть у голові розробника.
А коли проектування має сенс:
- Є загальна стратегія компанії, і розвиток ІТ систем – частина цієї стратегії.
- Є розуміння від менеджменту, які завдання потрібно вирішити за допомогою впровадження/розвитку інформаційної системи.
- Є формальне розуміння/опис бізнес-процесів компанії, або планується його створення.
Власне, все починається із стратегії. Інструментарій до створення стратегії компанії рідко буває спеціалізованим. Це швидше щось, що має бути у голові у топ менеджера. Далі будується модель бізнес-процесів (яка повинна бути присутньою для досягнення стратегічних цілей). Тут уже в хід ідуть інструменти моделювання - 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С
с. Інтеграція із середовищами моделювання
2) Функції колективної роботи
a. Робота з вимогами
b. Робота з помилками
3) Функції документування
a. Зв'язок документації з моделлю
b. Експорт документації в 1С та Word
4) Функції організації розробки та тестування
a. Специфікації та завдання на розробку
b. Результати тестування та відпрацювання помилок
У типовий 1С:СППР дуже добре реалізований блок (1), за винятком того, що хотілося б мати можливість представляти модель в різних нотаціях. Нам була ближча EPC, в 1С:СППР реалізована тільки IDEF 0.
Функції колективної роботи в поточній версії реалізовані в повному обсязі, на мій погляд, звичайно, найчастіше це необхідно при роботі з помилками та вимогами.
З документуванням виникають проблеми. Основний функціонал, якого не вистачає 1С:СППР - експорт уWord. Адже результатом роботи проектувальника має бути специфікація на розробку (ТЗ/ЧТЗ – хто як називає). А специфікація - це щось, що людина повинна мати змогу прочитати; тобто текстовий файл. Знову ж таки, вордовським файлом має оформлятися документація по системі та проектна документація. Але зазвичай 1С не дуже любить інтегруватися з продуктами Microsoft Office. Це суперечить принципам кросплатформенності, робить рішення залежним від зовнішніх додатків та суттєво збільшує складність розробки.
Функціонала для організації розробки та тестування в 1C: СППР просто не існує. Хоча незрозуміло чому. Рідко зустрінеш досвідченого розробника, який хоч раз у житті не написав би систему обліку завдань. Якщо орієнтуватися на той же 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С:Підприємство» та ведення технічної документації проекту. СППР може бути використана як інструмент для проектування нових інформаційних систем, що розробляються в середовищі «1С:Підприємства 8», так для опису та документування існуючих систем, розроблених раніше без використання СППР.
Система проектування прикладних рішень розроблена як конфігурація на платформі "1С:Підприємство 8.3".
Переваги для користувачів
Використання СППР дозволяє:
Керівникам проектів
- Організувати централізований облік вимог та побажань до інформаційної системи.
- Вибудувати цілісну модель системи, відштовхуючись від процесів, що автоматизуються, з можливістю перевірки коректності моделі.
- Керувати змінами у проекті.
- Формувати план виконання проекту.
- Аналізувати завершеність проекту (виконання необхідних завдань, відсутність помилок).
Розробникам
- Спроектувати функціонал у загальному контексті проекту.
- Враховувати при проектуванні зафіксовані вимоги та побажання.
- Єдино документувати проект.
- Планувати свою роботу.
- Відстежувати необхідність участі в суміжних проектах.
- Організувати обмін повідомленнями з учасниками проекту, в контексті об'єктів, що цікавлять.
- Спростити розробку обмежень доступу.
Технічним письменникам
- Спростити підготовку довідкової інформації в єдиному стилі з урахуванням структури конфігурації та взаємозв'язків різних об'єктів конфігурації.
- Використовувати проектні матеріали для підготовки документації та інших матеріалів.
Тестерам
- Отримати доступ до проектних матеріалів, що описують функціонал, що тестується.
- Забезпечити реєстрацію та відстеження помилок.
Внедренцям
- Розібратися у типовому рішенні, використовуючи проектну документацію.
- Співвіднести реальні процеси підприємства з моделлю системи, проаналізувавши покриття процесів функціоналом та виявивши необхідність доробок.
- Органічно внести власні доробки до типового функціоналу з вивіркою отриманої моделі.
Спростити освоєння конфігурації користувачами, формувати інструкції роботи з конкретним функціоналом.
Процес проектування у СППР
Проектування за допомогою СППР охоплює такі етапи:
На малюнку представлені взаємозв'язки основних понять СППР.
При проектуванні інформаційної системи описуються процеси, що автоматизуються. З опису процесів, будується логічна модель проектованої системи. На підставі логічної моделі будується фізична модель, що втілюється в метаданих конфігурації, що розробляється.
За потреби внесення змін до проекту використовується механізм технічних проектів. Зміни ґрунтуються на прийнятих вимогах і документуються з прив'язкою до змінних процесів, а також об'єктів логічної та фізичної моделі.
Опис процесів, що автоматизуються
Під час проектування конфігурації важливо, щоб її функціонал відповідав реальним потребам підприємств. Тому важливо окреслити те коло процесів, що дозволяє автоматизувати інформаційну систему.
СППР дозволяє зафіксувати перелік процесів, що автоматизуються, процеси при цьому можуть бути згруповані на розсуд користувача.
При описі процесу фіксується його опис, що відображає суть процесу, події початку та закінчення процесу.
Процес деталізується до окремих кроків, що виконуються конкретним виконавцем.
Створення логічної моделі проектованої системи
Логічна модель системи дозволяє описати функціональність конфігурації, ув'язавши її зі складом оброблюваної інформації та виконавцями.
Логічна модель СППР будується з допомогою методології IDEF0. У межах створення логічної моделі описуються функції системи та виробляється їхня декомпозиція.
Основою опису функції є її IDEF-схема. Схема дозволяє у наочній формі відобразити взаємозв'язок окремих (дочірніх) функцій, потоків даних та виконавців.
Розробка архітектури
Розробка архітектури конфігурації виконується з урахуванням логічної моделі. У цьому метадані співвідносяться з об'єктами даних, перелік яких визначається розробки функцій.
Проектування інтерактивних операцій
При роботі з системою в рамках того чи іншого процесу користувач виконує певні дії, реалізуючи таким чином один із можливих сценаріїв роботи.
Опис послідовностей інтерактивних операцій, що виконуються користувачем в системі, дозволяє проаналізувати, чи реалізуємо функціонал, що закладається в систему, в рамках конкретного автоматизованого процесу.
Підготовка довідки
СППР дозволяє автоматично формувати тексти довідки для конфігурації, що розробляється. Підготовлені тексти довідки у форматі html можуть бути вивантажені із СППР та завантажені у конфігурацію штатними засобами конфігуратора.
Довідка формується в єдиному стилі, з використанням єдиної структури опису, виходячи із взаємозв'язків підсистем, об'єктів метаданих та операцій функцій. Стилі оформлення довідки (шрифти, відступи, виділення) можуть налаштовуватися безпосередньо у СППР.
Робота з вимогами
Управління проектом та змінами
Для управління проектом та змінами у СППР використовується функціональність ведення технічних проектів. Ця функціональність дозволяє організувати колективну роботу над проектом, з відстеженням проходження різних етапів проекту. При цьому можливе гнучке настроювання етапів, погодження цих етапів, повідомлення учасників команди розробки про зміни.
Використання технічних проектів забезпечує внесення змін до наявного проекту таким чином, щоб ці зміни були пов'язані з логічною моделлю, були прозорі та інформативні для інших учасників проекту
Робота з помилками
СППР дозволяє вести реєстрацію помилок за проектами, що розробляються, в розрізі версій, термінів виправлення, розділів проекту, статусів і т.д. Функціонал системи пропонує готову методику роботи з помилками, з можливістю формування різних звітів, публікації інформації про помилки. Система дозволяє налаштувати зв'язки між проектами, вказати, які проекти-бібліотеки включаються до проекту з урахуванням конкретних версій проектів. Це дозволяє отримувати інформацію про наявність у проекті помилок, джерелами яких є бібліотеки, що використовуються.
Інші можливості
Крім перерахованих можливостей, СППР містить таку функціональність:
- Контролює зміни об'єктів СППР у розрізі різних користувачів.
- Версіонування проектної інформації.
- Можливість налаштування правил перевірки функціональної моделі у режимі «1С:Підприємство».
- Можливість налаштування додаткової інформації щодо об'єктів інформаційної бази.
- Можливість використання додаткових звітів та обробок.
- Обмін повідомленнями між учасниками проектної команди.
- Розсилання повідомлень з технічних проектів, завдань та помилок, нових повідомлень у системі.
- Можливість налаштування розсилок звітів електронною поштою.
- Повнотекстовий пошук.
- Робота із регламентними завданнями.
Система проектування прикладних рішень (СППР) призначена для проектування прикладних рішень (конфігурацій) на платформі "1С:Підприємство" та ведення технічної документації проекту. СППР може бути використана як інструмент для проектування нових інформаційних систем, що розробляються в середовищі "1С:Підприємства 8", а також для опису та документування існуючих систем, розроблених раніше без використання СППР.
СППР є конфігурацією, призначеною для використання з платформою "1С:Підприємство 8.3".
Керівникам проектів
- Організувати централізований облік вимог та побажань до інформаційної системи.
- Вибудувати цілісну модель системи, відштовхуючись від процесів, що автоматизуються, з можливістю перевірки коректності моделі.
- Керувати змінами у проекті.
- Формувати план виконання проекту.
- Аналізувати завершеність проекту (виконання необхідних завдань, відсутність помилок).
Розробникам
- Спроектувати функціонал у загальному контексті проекту.
- Враховувати при проектуванні зафіксовані вимоги та побажання.
- Єдино документувати проект.
- Планувати свою роботу.
- Відстежувати необхідність участі в суміжних проектах.
- Організувати обмін повідомленнями з учасниками проекту в контексті об'єктів, що цікавлять.
- Спростити розробку обмежень доступу.
Технічним письменникам
- Спростити підготовку довідкової інформації в єдиному стилі з урахуванням структури конфігурації та взаємозв'язків різних об'єктів конфігурації.
- Використовувати проектні матеріали для підготовки документації та інших матеріалів.
Тестерам
- Отримати доступ до проектних матеріалів, що описують функціонал, що тестується.
- Забезпечити реєстрацію та відстеження помилок.
Внедренцям
- Розібратися у типовому рішенні, використовуючи проектну документацію.
- Співвіднести реальні процеси підприємства з моделлю системи, проаналізувавши покриття процесів функціоналом та виявивши необхідність доробок.
- Органічно внести власні доробки до типового функціоналу з вивіркою отриманої моделі.
- Спростити освоєння конфігурації користувачами, формувати інструкції роботи з конкретним функціоналом.
СППР надає можливість ведення інформації про різноманітні конфігурації в рамках однієї інформаційної бази, з можливістю розмежування доступу за конфігураціями-проектами.
Конфігурація дозволяє створити логічну модель інформаційної системи, виходячи з процесів, що автоматизуються.
У основі логічного проектування з допомогою СППР лежить функціональна декомпозиція складних систем із застосуванням стандарту IDEF0. Це дозволяє в простій і наочній формі описувати проектовану систему з необхідним ступенем деталізації. Логічна модель будується з урахуванням процесів, які планується автоматизувати, у своїй пов'язує виконавців, робочі місця та інформаційні потоки. Логічна модель співвідноситься з метаданими конфігурації.
Функціонал СППР включає механізми управління вимогами та змінами у проекті. Використання даного функціоналу дозволяє органічно внести в проект зміни, пов'язавши їх з існуючої логічної моделлю.
Наявність формальних правил перевірки дає можливість виявити та усунути помилки та невідповідності у проекті.
Система включає механізми реєстрації та відстеження помилок з урахуванням включаються конфігурацій-бібліотек.
СППР дозволяє формувати тексти довідки з урахуванням взаємозв'язків об'єктів конфігурації. Довідка оформляється у єдиному стилі. Підготовлені тексти довідки можуть бути завантажені безпосередньо в конфігурацію, що розробляється засобами конфігуратора.
Вбудовані механізми розвантаження-завантаження даних за проектами дозволяють організувати публікацію проектної інформації для можливості використання та роботи з цією інформацією в інших інформаційних базах СППР.
Зовнішній вигляд товару, його комплектація та основні технічні характеристикиможуть бути змінені виробником без попередження. Опис носить довідково-ознайомчий характері і може бути основою претензій. Щоб уникнути непорозумінь, повну інформаціюпо товару уточнюйте телефоном у менеджера.
У цій статті ми спробуємо розповісти, як за допомогою віддалених та територіально розподілених команд ми налагодили процес випуску прикладних рішень, що розширюють функціональність нашого продукту «1С:ERP Управління підприємством 2».
Галузеві та спеціалізовані продукти, що розширюють функціональність «1С:ERP Управління підприємством 2»
На основі нашої технологічної платформи «1С:Підприємство 8» ми самі, фірма «1С», випускаємо близько 20 рішень найрізноманітнішого калібру – від «Управління нашою фірмою», «1С:Бухгалтерії» різних редакцій (від «Спрощенки» до «Корпоративної» ) до нашого найфункціональніше насиченого рішення - «1С:ERP Управління підприємством 2».«1С:ERP 2» - рішення, що автоматизує більшу частину процесів багатопрофільних підприємств. Але є цілі класи завдань та галузевих особливостей, що вимагають більш детального опрацювання, ніж вона є у «1С:ERP 2» – торгівля, логістика, управління складом, будівництво, сільське господарство тощо. Включати цю функціональність типове рішення недоцільно, т.к. це призведе до ускладнення роботи більшості користувачів. До того ж, у нас самих може не вистачити ресурсів для повноцінної реалізації необхідної функціональності.
Отже, маємо завдання створення галузевих/спеціалізованих рішень, які:
- відповідають потребам ринку;
- розробляються із мінімально можливим залученням ресурсів власне фірми «1С»;
- мають гарантовану якість реалізації.
- Рішення створюються нашими партнерами, які мають компетенції у відповідній галузі
- Від фірми «1С» у створенні рішення бере участь «модератори» - архітектори проекту та куратори напрямків.
- Ми розробили регламенти проектування та розробки рішень, що дозволяють контролювати якість продукту
Співпраця з партнерами «1С-Спільно»
У проекті «1С-Совместно» продукт створюється партнером фірми «1С», але правовласником є фірма «1С». Ми самі визначаємо вимоги до продукту та контролюємо його якість.Порядок розробки спільних рішень:
- Ми шукаємо затребувану ринком функціональність, що ще не реалізована в наших продуктах, і складаємо функціональні вимоги до нового продукту;
- Ми оголошуємо конкурс на розробку нових «1C-спільних» рішень, а також приймаємо заявки на випуск продуктів з ініціативи партнерів;
- Ми визначаємо партнерів з найбільшими компетенціями та готовністю довгострокового розвитку напряму;
- Ми замовляємо партнеру розробку, розвиток та підтримку продукту.
Графік якості
Концепція модульного підходу в архітектурі рішень на базі "1С:ERP Управління підприємством 2"
З погляду концепції та архітектури, «1С:ERP» є абсолютно новим продуктом у порівнянні з його попередником «1С:Управління виробничим підприємством». Одна з ключових відмінностей нового рішення – головність функцій керування. При розробці лінійки галузевих та спеціалізованих рішень важливо було підтримати це й у рішеннях «1С-Спільно». Особлива увага була приділена завданням інтегрованості рішень між собою та з «1С:ERP», можливості побудови єдиної інформаційної системи, що складається з набору модулів із ключовим інтеграційним ядром – «1С:ERP».Ціль – єдина безшовна інформаційно-управлінська система, побудована на базі «1C:ERP» та інших рішеннях «1С:Підприємство 8»:
Було розроблено концепцію модульного підходу в архітектурі рішень на базі «1С:ERP». Концепція визначає принципи розробки, уніфікації та інтеграції різних змін у межах єдиної системи управління та обліку.
Всі рішення в рамках програми «1С-Спільно», що розширюють можливості «1С:ERP», повинні дотримуватися концепції модульного підходу. Ключовими завданнями модульного підходу є:
- Формування лінійки продуктів, що взаємодіють як на рівні інтеграційного ядра «1С:ERP», так і між собою
- Спрощення створення єдиного рішення для користувачів із набору галузевих та спеціалізованих рішень
- Мінімізація трудовитрат зі зміни складу модулів рішення та подальшого супроводу рішення
- Виключення дублювання загальних функціональних підсистем у різних продуктах
На момент написання статті кількість вже випущених рішень лінійки – 31 (18 партнерів-розробників) з урахуванням планів розробки у 2 кварталі 2017р. кількість рішень досягне 52 (24 партнери-розробники).
Процес проектування, розробки та контролю галузевих та спеціалізованих рішень для «1С:ERP»
Взаємодія розробників у єдиному середовищі проектування
У роботі над проектом беруть участь територіально розподілені та слабко пов'язані між собою команди розробників. Так, сьогодні у нас у роботі:- 28 територіально розподілених команд розробників;
- 44 активні проекти;
- 19 нових рішень.
- Аналіз, проектування та документування функціональності
- Формулювання вимог до інших рішень
- Контроль термінів проходження етапів проектування та розробки
- Актуалізація моделі рішення
- Контроль заявленої функціональності
- Обговорення вимог та побажань у рамках Круглого столу для розробників
СППР для галузевих та спеціалізованих рішень (СППР ОР/СР) – CASE-засіб для спільного проектування рішень
Усі розробники рішення взаємодіють через продукт "1С: Система проектування прикладних рішень" (скорочено СППР). СППР допомагає проектувати прикладні рішення на платформі «1С:Підприємство» та дозволяє обслуговувати завдання повного циклу розробки ПЗ – збір вимог, контроль змін, документування, баг-трекінг тощо. СППР розроблена як конфігурація на платформі "1С:Підприємство 8".СППР може бути використана як інструмент для проектування нових інформаційних систем, що розробляються в середовищі «1С:Підприємства 8», так для опису та документування існуючих систем, розроблених раніше без використання СППР.
Ми вибрали СППР як найбільш зручний і відповідний для наших завдань і відповідний вимогам до CASE-засобу, що висуваються нами:
- Можливість побудови моделі складної системи
- Управління життєвим цикломпродукту
- Мультипроектність
- Кастомізованість
- Інтеграція із середовищем розробки
- Доступність для партнерів-впроваджених 1С
Цілі
- Проектування та документування проектних рішень
- Контроль результатів розробки
- підтримка актуального опису автоматизованих процесів підприємств та реалізованої для цього функціональності
- верифікація цілісності єдиної моделі всіх рішень
- контроль термінів виконання проектів
- контроль функціональності конфігурацій описаної моделі
- реалізація єдиного середовища проектування при спільній роботі великої кількості розробників
Управління життєвим циклом випуску продуктів
Весь проект розділений на функціональні області (розділи проекту), кожен розділ займається керівником напряму з боку «1С». Розділи наповнюються функціональністю рішень (продуктів), причому:- функціональність одного розділу не обов'язково визначається одним продуктом,
- функціональність всього розділу може розроблятися кількома партнерами-розробниками.
Для функціональності, що проектується, створюються відповідні технічні проекти, з призначенням відповідальних з боку партнера-розробника. В рамках одного технічного проекту можливий випуск відразу кількох варіантів постачання функціональності (власне самих продуктів).
Кожному технічному проекту призначаються плановий термін завершення (керує та контролює керівник напряму), та встановлюються терміни етапів виконання технічного проекту.
Партнер-розробник вказує терміни контрольних точок у межах загальної тривалості проекту. При перевищенні терміну виконання однієї з етапів інформація потрапляє контролювати відповідальному менеджеру. Також відповідальний менеджер бачить терміни виконання кожного етапу (зокрема прострочені). Кожен етап завершується узгодженням контрольної точки відповідальним.
Ми не ставимо завдання керувати процесом розробки на стороні партнерів. Кожен партнер застосовує власну методику, що устала в колективі. Ми контролюємо лише терміни важливих для нас контрольних точок та регулюємо результати необхідними стандартами та регламентами, знайомство з якими та їх застосування також контролюємо.
В рамках технічних проектів плануються і виконуються не тільки роботи з розробки нової функціональності, але й проведення тестів навантаження, уніфікація загальної функціональності, мінімізація змін об'єктів метаданих типової конфігурації.
Логічна модель рішень у методології IDEF0
У основі СППР ОР/СР функціональність всіх рішень лінійки описується у межах одного проекту. В основі логічного проектування закладено методологію IDEF0.Цілісність та несуперечність функціональної моделі модерується функціональним архітектором проекту, призначеним з боку «1С».
Опис нотації СППР
У межах СППР основні поняття трактуються так:
- Функціональний блок (Activity Box)- деяка конкретна функція створення нової інформації в рамках системи, що розглядається
- Зв'язок– інформація, що обробляється функціональним блоком (входи та виходи) або надає інший вплив на функцію (управління та виконуючі зв'язки – профілі користувачів):
- Вхід функції- Зв'язок (інформація), що споживається функцією. На схемі відображається у вигляді стрілки, спрямованої до лівої сторони функціонального блоку
- Вихід функції- Зв'язок (інформація), що породжується в результаті виконання функції. На схемі відображається у вигляді стрілки, що виходить з правої сторонифункціонального блоку
- Управління (керуюча дія на функцію, правило)– зв'язок (інформація) аналізована до прийняття рішень на рамках функцій. На схемі відбивається як стрілки до верхній стороні функціонального блоку.
- Виконання (профіль користувача)- Вплив на функцію з боку одного або декількох користувачів системи. На схемі відбивається як стрілки до верхній стороні функціонального блоку.
Функціональність всіх рішень піддається верифікації відповідно до правил перевірки, які є частиною механізму аудиту моделі системи, що розробляється на відповідність формальним правилам проектування. Таким чином підтримується цілісність логічної моделі всіх рішень лінійки.
Варіанти постачання продуктів
Концепція модульного підходу припускає різні варіанти постачання продуктів:- функціональність у складі «1С:ERP»,
- функціональність у вигляді самостійно працюючої конфігурації,
- функціональність для інтеграції до «1С:ERP».
Наприклад, «1С:ERP Управління будівельною організацією 2» (партнер – розробник «1С-Рарус») містить у своєму складі:
- функціональні можливості типовий «1С:ERP»,
- власну оригінальну галузеву функціональність,
- функціональність окремих рішень:
- «1С:Кошторис 3»,
- Модуль «1С: Ріелтор. Управління продажами нерухомості для 1С:ERP»,
- Модуль «1С:Оренда та управління нерухомістю для 1C:ERP»,
- Модуль "1С: Управління автотранспортом для 1С: ERP".
Бібліотека функціональних підсистем 1С-Спільно
З метою уніфікації рішень лінійки виділяється загальний універсальний функціонал та формується «Бібліотека функціональних підсистем 1С-Спільно».Бібліотека надає інструментарій для розробників рішень «1С:Спільно», що містить набір універсальних функціональних підсистем, готові розділи для документації користувача та технологію для інтеграції в галузеві та спеціалізовані рішення з метою уніфікації в рамках єдиної лінійки, що дозволяє:
- Забезпечити загальні підходи у реалізації єдиних універсальних механізмів у рішеннях «1С-Спільно»;
- скоротити трудомісткість випуску нових рішень з допомогою використання готової функціональності;
- спростити інтеграцію рішень різних партнерів-розробників при поєднанні змін;
- скоротити кількість різних реалізацій єдиних механізмів для користувачів, які одночасно використовують кілька рішень.
Повідомлення відповідальних про хід реалізації технічних проектів
З огляду на велику кількість учасників проектів розробки необхідні контрольні інструменти для повідомлення відповідальних про хід реалізації технічних проектів.У основі СППР ОР/СР налаштовані регламентні завдання, формують розсилки листів. З цією метою виділені такі групи одержувачів:
- Відповідальні за проект
- Відповідальні за розділи проекту
- Відповідальні за технічні проекти
- Контроль виконання технічних проектів – щотижня
- Контроль активності партнерів-розробників – щотижня
- Повідомлення про необхідність виконання дій у базі (завдання, повідомлення тощо) - щоденно
- Повідомлення про наявність помилок у моделях - щоденно
- Терміни виконання контрольних точок (етапів)
- Терміни виконання технічних проектів
- Зміни об'єктів метаданих типової конфігурації
- Помилки та попередження у моделі
- Актуальні завдання
- Активність роботи над технічним проектом
Приклади звітів
Підготовка конфігурацій до тиражування
Загальна функціональна схема передвиробничої перевірки рішення:
Передвиробнича перевірка виконується в рамках регламенту і включає як ручну, так і автоматизовану перевірку переданих матеріалів.
Партнер-розробник несе відповідальність за якість тестування, комплектність матеріалів та передає матеріали фірмі «1С» для перевірки перед випуском повністю працездатними, протестованими, відповідними вимогам сертифікації «1С:Сумісно», «Системі стандартів та методик розробки конфігурацій для платформи 1С:Підприємство 8» та вимог Регламентів взаємодії з розробниками спільних рішень.
Також розглядається можливість включення додаткових перевірок на відповідність функціональної моделі в базі СППР ОР/СР: контроль відповідності заявленої функціональності ОР/СР реалізованому та контроль відповідності модифікації об'єктів типової конфігурації заявленим у СППР ОР/СР.
Сервіс 1С:Хмарна карта рішень
Для потенційних користувачів нових рішень потрібно зробити зручний і простий сервіс з легкодоступними для розуміння інструментами. Для цього був розроблений спеціальний веб-сервіс та клієнт для відображення схем:
Сервіс «1С:Хмарна карта рішень» надає доступ до функціональних моделей ряду рішень фірми «1С», а також галузевих та спеціалізованих рішень, що випускаються за схемою 1С-Спільно. Актуалізація функціональної моделі забезпечується прямим зверненням до веб-сервісу бази «СППР для галузевих та спеціалізованих рішень», модель рішень у якій підтримується в актуальному стані відповідно до Концепції модульного підходу в архітектурі рішень на базі «1С:ERP Управління підприємством 2».
- Функція «Комплексна інформаційна система управління на базі 1С: ERP Управління підприємством 2»
- Функція "1С:PDM Управління інженерними даними"
Переваги використання сервісу
Для потенційних клієнтів:- Отримання уявлення про функціональність готових рішень фірми «1С»
- Підготовка функціональних вимог для організації конкурсів з проектів автоматизації
- Вивчення функціональності готових рішень для автоматизації галузевих та спеціалізованих бізнес-процесів, визначення продуктів, що містять функціональність.
- Можливість обрати партнера, ознайомитися з умовами придбання, інформаційними матеріалами, успішними проектами впровадження, а також взяти участь у найближчих заходах та отримати доступ до демонстраційної бази (за наявності такої можливості) шляхом переходу на сторінку продукту сайту http://solutions.1c. ru
- Розширення областей автоматизації у межах використовуваних рішень шляхом вивчення та застосування всіх закладених функціональних можливостей.
Використання сервісу партнерами
- Демонстрація потенційним клієнтам функціональної моделі готових рішень (моделі містять докладну інформацію про продукти, їх функціональність, автоматизовані бізнес-процеси, робочі місця). Демонстрація існуючим клієнтам функціональних можливостей продуктів, що містять галузеву специфіку, реалізацію предметних завдань.
- Участь у конкурсах, підготовка пропозицій: порівняння необхідної функціональності із функціональністю всього комплексу готових рішень. Вибір готових продуктів для покриття функціональних розривів. Підготовка пропозицій з використанням прикладів інтеграційних рішень та бізнес-кейсів успішних проектів.
- Впровадження: співвідношення реальних процесів підприємства з функціональною моделлю, вивчення принципів взаємодії функціональних блоків.
Команда розробників – команда професіоналів
Результати будь-якого проекту залежать від команди. Для розробки лінійки рішень для «1С:ERP» вдалося зібрати велику команду професіоналів, готових до експериментів, які готові спільно долати труднощі. Враховуючи кількість партнерів-розробників, навести повний списокскладно, виділяти окремих партнерів також не хотілося б.Вважаємо, у виборі партнерів, їхньої компетенції кожного у своїй галузі та синергії у досягненні єдиної мети, ми не помилилися.
На закінчення
Ми поділилися з вами ключовими процесами розроблення лінійки рішень для 1С:ERP. Повністю процес досить складний, що включає велику кількість учасників як з нашого боку, так і з боку партнерів-розробників. Насамперед хотілося донести до читача процеси проектування та контролю ходу такого складного проекту. Подібний підхід ми застосовуємо вперше та сподіваємося поширити цей досвід і на розробку інших лінійок рішень.Система проектування прикладних рішень (СППР) призначена для проектування прикладних рішень (конфігурацій) на платформі «1С:Підприємство» та ведення технічної документації проекту. СППР може бути використана як інструмент для проектування нових інформаційних систем, що розробляються в середовищі «1С:Підприємства 8», так для опису та документування існуючих систем, розроблених раніше без використання СППР.
Система проектування прикладних рішень розроблена як конфігурація на платформі "1С:Підприємство 8.3".
Переваги для користувачів
Використання СППР дозволяє:
Керівникам проектів
- Організувати централізований облік вимог та побажань до інформаційної системи
- Вибудувати цілісну модель системи, відштовхуючись від процесів, що автоматизуються, з можливістю перевірки коректності моделі
- Керувати змінами у проекті
- Формувати план виконання проекту
- Аналізувати завершеність проекту (виконання необхідних завдань, відсутність помилок)
Розробникам
- Спроектувати функціонал у загальному контексті проекту
- Враховувати при проектуванні зафіксовані вимоги та побажання
- Єдино документувати проект
- Планувати власну роботу
- Відслідковувати необхідність власної участі у суміжних проектах
- Організувати обмін повідомленнями з учасниками проекту, в контексті об'єктів, що цікавлять
- Спростити розробку обмежень доступу
Технічним письменникам
- Спростити підготовку довідкової інформації в єдиному стилі з урахуванням структури конфігурації та взаємозв'язків різних об'єктів конфігурації
- Використовувати проектні матеріали для підготовки документації та інших матеріалів
Тестерам
- Отримати доступ до проектних матеріалів, що описують функціонал, що тестується.
- Забезпечити реєстрацію та відстеження помилок
Внедренцям
- Розібратися у типовому рішенні, використовуючи проектну документацію
- Співвіднести реальні процеси підприємства з моделлю системи, проаналізувавши покриття процесів функціоналом та виявивши необхідність доробок
- Органічно внести власні доробки до типового функціоналу з вивіркою отриманої моделі
Спростити освоєння конфігурації користувачами, формувати інструкції роботи з конкретним функціоналом.
Процес проектування у СППР
При проектуванні інформаційної системи описуються процеси, що автоматизуються. З опису процесів, будується логічна модель проектованої системи. На підставі логічної моделі будується фізична модель, що втілюється в метаданих конфігурації, що розробляється.
За потреби внесення змін до проекту використовується механізм технічних проектів. Зміни ґрунтуються на прийнятих вимогах і документуються з прив'язкою до змінних процесів, а також об'єктів логічної та фізичної моделі.
Опис процесів, що автоматизуються
Під час проектування конфігурації важливо, щоб її функціонал відповідав реальним потребам підприємств. Тому важливо окреслити те коло процесів, що дозволяє автоматизувати інформаційну систему.
СППР дозволяє зафіксувати перелік процесів, що автоматизуються, процеси при цьому можуть бути згруповані на розсуд користувача.
Процес деталізується окремих кроків, виконуваних конкретним виконавцем.
Створення логічної моделі проектованої системи 
Логічна модель системи дозволяє описати функціональність конфігурації, ув'язавши її зі складом оброблюваної інформації та виконавцями.
Логічна модель СППР будується з допомогою методології IDEF0. У межах створення логічної моделі описуються функції системи та виробляється їхня декомпозиція.
Основою опису функції є її IDEF-схема. Схема дозволяє у наочній формі відобразити взаємозв'язок окремих (дочірніх) функцій, потоків даних та виконавців.
Розробка архітектури
Розробка архітектури конфігурації виконується з урахуванням логічної моделі. У цьому метадані співвідносяться з об'єктами даних, перелік яких визначається розробки функцій.
Проектування інтерактивних операцій 
При роботі з системою в рамках того чи іншого процесу користувач виконує певні дії, реалізуючи таким чином один із можливих сценаріїв роботи.
Опис послідовностей інтерактивних операцій, що виконуються користувачем в системі, дозволяє проаналізувати, чи реалізуємо функціонал, що закладається в систему, в рамках конкретного автоматизованого процесу.
Підготовка довідки
СППР дозволяє автоматично формувати тексти довідки для конфігурації, що розробляється. Підготовлені тексти довідки у форматі html можуть бути вивантажені із СППР та завантажені у конфігурацію штатними засобами конфігуратора.
Довідка формується в єдиному стилі, з використанням єдиної структури опису, виходячи із взаємозв'язків підсистем, об'єктів метаданих та операцій функцій. Стилі оформлення довідки (шрифти, відступи, виділення) можуть налаштовуватися безпосередньо у СППР.
Робота з вимогами
Управління проектом та змінами 
Для управління проектом та змінами у СППР використовується функціональність ведення технічних проектів. Ця функціональність дозволяє організувати колективну роботу над проектом, з відстеженням проходження різних етапів проекту. При цьому можливе гнучке настроювання етапів, погодження цих етапів, повідомлення учасників команди розробки про зміни.
Використання технічних проектів забезпечує внесення змін до наявного проекту таким чином, щоб ці зміни були пов'язані з логічною моделлю, були прозорі та інформативні для інших учасників проекту
Робота з помилками
СППР дозволяє вести реєстрацію помилок за проектами, що розробляються, в розрізі версій, термінів виправлення, розділів проекту, статусів і т.д. Функціонал системи пропонує готову методику роботи з помилками, з можливістю формування різних звітів, публікації інформації про помилки. Система дозволяє налаштувати зв'язки між проектами, вказати, які проекти-бібліотеки включаються до проекту з урахуванням конкретних версій проектів. Це дозволяє отримувати інформацію про наявність у проекті помилок, джерелами яких є бібліотеки, що використовуються.
Інші можливості
Крім перерахованих можливостей, СППР містить таку функціональність:
- Контролює зміни об'єктів СППР у розрізі різних користувачів
- Версіонування проектної інформації
- Можливість налаштування правил перевірки функціональної моделі в режимі «1С:Підприємство»
- Можливість налаштування додаткової інформації про об'єкти інформаційної бази
- Можливість використання додаткових звітів та обробок
- Обмін повідомленнями між учасниками проектної команди
- Розсилка повідомлень за технічними проектами, завданнями та помилками, новими повідомленнями в системі
- Можливість налаштування розсилок звітів електронною поштою
- Повнотекстовий пошук
- Робота з регламентними завданнями
Завантаження...
