Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Методики управления развитием ис на базе 1с

187 views

Published on

Данная презентация была представлена в ходе вебинара "Методики управления развитием ИС на базе 1С. СППР как возможный инструмент поддержки данных методик". Ведущий - Олег Демиденко, руководитель отдела внедрения, руководитель проектов компания "Кодерлайн".

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Методики управления развитием ис на базе 1с

  1. 1. Методики управления развитием ИС на базе 1С Олег Демиденко
  2. 2. В момент внедрения системы и добавления функционала • Делают не то • Делают одно, другое ломают • Работы выполненные разными специалистами оказываются во взаимном противоречии Причины проблемы: плохие коммуникации • Каждый понял по своему что ему надо делать. Заказчик ждёт одно, программист может очень хорошо сделать но не то, что нужно • Бизнес-заказчики и программисты не знают над чем работают их коллеги. • В худшем случае, два бизнес-заказчика одновременно попросят сделать одинаковые / противоположные функции у двух разных программистов. В чем проблема? Зачем какие-то методики?
  3. 3. В чем проблема? Зачем какие-то методики?
  4. 4. При развитии системы • Забывается что и зачем было сделано. Появляется священный страх делать изменения (а вдруг что-нибудь сломается) • Стоимость добавления нового функционала растёт, т.к. внедрить его учтя все взаимосвязи становится всё сложнее Причины проблемы: • Отсутствие документации проектных решений • Плохая архитектура – сложно разобраться в клубке разных программных функций непонятно как и зачем связанных между собой В чем проблема? Зачем какие-то методики?
  5. 5. При смене системы • Никто не помнит зачем старая система так работала. Поэтому выбирают один из двух путей: делают новую систему как копию старой, сохраняя груз проблем. Или делают новую систему с нуля, с огромными повторными затратами на бизнес-анализ. Причины проблемы: • Отсутствие документации проектных решений В чем проблема? Зачем какие-то методики?
  6. 6. • Некачественная передача информации между людьми, или вообще отсутствие коммуникации. • Важная информация хранится в головах. Постепенно происходит забывание или отток голов, хранивших эту информацию. • Некоторые проектные решения иногда неоптимально влияют на ИС, делаются наспех, в виде заплаток. Копится груз проблем. Итого: • 2,5 проблемы имеют организационную причину. • 0,5 проблемы имеют техническую причину (недостаток тех.квалификации) В чем корень проблемы
  7. 7. • Нужно чтобы Заказчик и Исполнитель смогли точно понять друг друга, чтобы Исполнитель сделал то, что нужно Заказчику • Разработчики должны общаться между собой, чтобы не ломать работу друг друга • Архитектор системы должен вовремя и понятно сообщить о критическом числе заплаток и необходимости провести рефакторинг, приводящий систему в божеский вид Методики решения: • Обсуждение требований в виде максимально исключающим взаимонепонимание: простой язык, наглядные примеры • Разработчики должны регулярно общаться, на стадии проектирования своих доработок, чтобы не оказалось что что-то было сделано зря • Учет «Технического долга» накопленного при проектировании системы Задача – наладить коммуникации
  8. 8. Пойдем от обратного: • Оплачивайте программистам только то время, когда они сидят и пишут код, а не чешут языком. Программистов вообще не просили разбираться в бизнесе, который они автоматизируют. Как им сказали, так пусть и делают. • Пишите ТЗ в технических терминах со всеми нюансами. Не тратьте время на переписывание ТЗ ради такого абстрактного понятия как «удобочитаемость». Тогда пользователь его подпишет не читая. • Не используйте графические картинки и схемы • Предполагайте что всё, что вы не стали обсуждать, вы с заказчиком понимаете одинаково. Ведь мы же все разумные люди, и скорее всего предполагаем примерно одно и то же. • Не показывайте заказчику промежуточный прототип, всё равно не поймет. Только время зря потратим. Как однозначно понять друг друга?
  9. 9. • Разработчик и заказчик должны провести достаточное время в обсуждении сути задачи и выработки эффективного подхода к её решению. Они должны придти к однозначному общему пониманию задачи • Договоренности должны быть задокументированы простым и достаточно исчерпывающим способом. Сценарии использования, схемы бизнес- процессов, графические схемы. • До реализации полного функционала должен быть разработан интерфейсный прототип. Данный прототип должен быть обязательно согласован с заказчиком, чтобы убедиться что разработка ведётся в верном направлении. Как однозначно понять друг друга?
  10. 10. • Необходимо чтобы программисты согласовывали друг с другом свои задачи на предмет выявления нестыковок • Необходимо чтобы программисты обменивались информацией о работе друг друга, чтобы итоговый результат было более унифицированным в подходах и за счет этого, более эффективным в использовании. Не продуктивные варианты: • Схема «звезда» не работает. Один человек не способен проконтролировать полную стыковку всех блоков даже в небольшой команде. • При почасовой оплате работы программистов, и необходимости доказать полезность каждого часа своей работы – общение между собой доказать труднее всего. Как согласовать работу разработчиков
  11. 11. Организация совместной разработки в фирме 1С с использованием «Системы проектирования прикладных решений»
  12. 12. • Функциональное моделированцие (IDEF 0) • Функционал планирования, контроля и документирования технических проектов • Баг-трекинг • Учет требований • Система подготовки встроенной справки • Система проектирования прав доступа Что вообще умеет СППР
  13. 13. Бывает полезно при согласовании и объяснении верхнеуровневой архитектуры, на уровне руководства. Внутри отделов разработки используется редко Функциональное моделирование
  14. 14. • Средство контроля кто что и зачем будет делать • «Память» проекта – кто что и зачем сделал • Контроль формальных правил выполнения проекта: контрольные точки и контрольные вопросы «Технический проект»
  15. 15. • Способ формализации подхода к выполнению задач «Технический проект»
  16. 16. • Контроль выполненных изменений «Технический проект»
  17. 17. • Средство подготовки встроенной справки и документации к релизам • История изменений в разрезе объектов метаданных • Реестр требований, с указанием источников, ответственных и приоритетов; возможностью группировки по тематикам • Баг-трекер • Система постановки задач друг другу • Интеграция с документооборотом • Поддержка работы с несколькими хранилищами/ветками разработки Что еще есть в СППР
  18. 18. СППР – не самоцель. И, возможно, не самый удобный инструмент. Преимущества СППР: • Однообразно по всей компании • На платформе 1С, можно дорабатывать под свои нужды • Есть положительный опыт из фирмы 1С по разработке сложных систем • У нас есть тоже положительный опыт • Это технология, которую активно рекламирует сама фирма «1С» на всех своих бизнес-форумах, посвященных ERP. • Технологию СППР фирма 1С обязывает использовать на VIP-проектах, которые проходят под её надзором Почему именно СППР?
  19. 19. Спасибо за внимание

×