BoatmansHome: АвтоматизированныеСистемы/Манифест34 ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

Манифест системы стандартов ГОСТ 34


В ответ на очень правильный вопрос Юрия Куприянова: https://www.facebook.com/yksi12/posts/992388070831803 – какой манифест (система ценностей) у ГОСТ 34, излагаю свое понимание и приглашаю всех к обсуждению.


Итак.

Манифест


1. Ответственность за улучшение показателей автоматизируемой деятельности. Целью проекта по построению автоматизированной системы (АС) является измененное состояние деятельности пользователей, сопровождаемое улучшением показателей этой деятельности.


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


3. Ответственность за полный жизненный цикл системы. В ходе проектирования рассматривается и прогнозируется полный жизненный цикл АС от самого проектирования до вывода из эксплуатации.


4. Ответственность за полные рамки проекта. Устанавливается полный состав по видам работ, при выполнении которых гарантированно получается действующая АС.


5. Проектирование. Устанавливаются стадии (фазы) создания АС, среди которых минимум 3 проектных стадии, 2 из которых должны выполняться в предпроекте, то есть до фиксации бюджета и сроков построения АС или рассматриваемой части АС.


6. Управление неопределенностью. Устанавливается полный состав проектных решений, не отдаваемых на откуп отдельному исполнителю — решений, которые должны согласовываться с другими решениями по системе и/или с участниками рабочей группы проекта и/или с заказчиком АС. Корректное принятие и реализация этих решений гарантирует построение действующей АС.


Итого: ответственность, проектирование и управление неопределенностью, в итоге — предсказуемость в противовес «смелости» (по определению Юрия Куприянова) в случае с AGILE.
ГОСТ 34 создан для тех, кто не любит слова «не знаем», «не умеем», «это не наша ответственность», «мы подумаем об этом завтра» и «авось». Это накладывает издержки и повышенные требования к квалификации автоматизаторов. По этому не везде есть условия для применения ГОСТ 34.
Каждый сам решает подходит ему это или нет.

Разумные условия для применения ГОСТ 34

  1. Большие и дорогие системы, где есть возможность снимать значительные риски проектированием.
  2. Большая цена ошибки, например, высокая ответственность в рамках автоматизируемой деятельности, дорогое привлечение и подготовка пользователей (например, их много, их надо обучать, их доверие надо завоевывать).
  3. Высокая чувствительность к срыву сроков.
  4. Другие ситуации, где нужно минимизировать «число подходов к снаряду».

Условия для отказа от ГОСТ 34

  1. Существуют размеры систем, где применение ГОСТ противопоказано, а точнее требует неприемлемо высокой квалификации проектировщиков, чтобы сохранить нормальную долю затрат на проектирование в общем бюджете системы.
  2. Низкая стоимость ошибки, низкая ответственность и возможность неограниченное число раз выходить на внедрение или изменение системы.
  3. Низкая квалификация или отсутствие проектровщиков, способных принимать качественные проектные решения.
  4. Требуется высокая скорость реакции команды разработки на анализ ситуации, вызванная неустраняемой высокой неопределенностью.
  5. ГОСТ 34 направлен на систему в целом. Если мы пишем программы, делаем информационные продукты, необходимо уточнять возможности применения ГОСТ 34. Все, что там сказано, вообще-то остается верным, однако, ключевые проблемы и решения могут лежать совсем в другой плоскости и не решаться просто следованием ГОСТ 34.

Естественно, тут же возникает множество вопросов «сколько вешать в граммах». Попробую дать свою версию ответов.

Сколько вешать в граммах

  1. Нормальная доля стоимости всего проектирования в бюджете построения АС – 10–30%. При превышении этих пределов, во-первых, дешевле совершить несколько подходов к снаряду или провести некоторое количество итераций прототипирования и/или макетирования; а во-вторых, стоимость проектирования начинает быть сравнима с предотвращаемыми рисками и тогда мы уже можем застраховать их резервными буферами по срокам и бюджету.
  2. Минимальная граница трудоемкости аналитика на создание приемлемого ТЗ на АС в силу количества отражаемых вопросов – 2–4 человеко-недели (это если две стадии проектирования делаются в уме заказчика, а аналитику надо только заполнить вопросник и внести решения в документ). Таким образом минимальная стоимость системы, где имеет смысл использовать ГОСТ 34 – 7–20 человеко-недель (Сегодня по местным тарифам это 0,85–2,5 млн.руб.). При этом, как мы говорили, чем ниже бюджет, тем выше должна быть квалификация проектировщика, чтобы вписаться в ограничения, но получить полезные артефакты. Мой опыт показывает, что в сегодняшних ценах уверенная нижняя граница бюджета на построение системы для полноценного применения ГОСТ 34 – 5–10 млн.руб. По моей оценке, в проекты с бюджетами от 20 млн.руб. без хотя бы оглядки на принципы ГОСТ 34 лучше не лазить.
  3. Когда мы анализируем стоимость нестыковок в построенной системе, мы решаем, что дешевле: проектировать или переделывать и перевнедрять. Затем принимаем решение, нужно работать по ГОСТ или по более легкому стандарту.

Проблемы, решения и заблуждения

Известные мне проблемы ГОСТ 34 на сегодняшний день, которые надо учитывать в работе с ним:
Проблемы конъюнктуры рынка:

  1. Сегодня в рыночной экономике (2016г., РФ) мало кто хочет платить за предпроектные стадии (заказчик еще не знает, будем ли строить систему, исполнитель экономит, по сути, маркетинговый бюджет), в итоге проекты очень часто остаются без внятных концептуальных решений и целей, что им очень вредно. Только что, по меркам отрасли, в общем дискурсе сформировано мнение, что для создания программы неплохо писать к ней ТЗ, что соответствует стадии технического проектирования автоматизированной системы. И нам осталось «отбить» еще две стадии проектирования системы в целом – концептуальное проектирование и бизнес-проектирование.
  2. Действительно требуются грамотные проектировщики систем. Предыдущие пару десятилетий у нас в ИТ шло насыщение персоналом слоя рядовых работяг при растущем ИТ рынке – программистов, тестеров и т.п. Их квалификация не требует ни высшего образования, ни ответственности проектировщика. По этому даже выходящие из ВУЗов специалисты, получившие достаточное образование, не имели возможности получить как нормальную практику, так и подкрепление нормальных инженерных ценностей и ответственности. Параллельно насыщался слой управленцев, причем очень быстро. Чуть позже спецы с полей пришли в ВУЗы и, в итоге, во многом культура как преподавания, так и самого проектирования автоматизированных систем значительно подорвана. Мы имеем ситуацию, в которой люди с квалификацией, как после техникума, отошедшие от ответственности и ценностей инженерного персонала (у кого они были), пывысились в менеджмент и оттуда чаще всего строят процессы создания ПО и систем, на уровне прораба строительной бригады. Пришедшая мода на управление проектами и на управление процессами в ИТ добавляет немножко системного подхода, однако там тоже требуется квалификация, которая требует как образования, так и практики в соответствующем окружении, но главное – закрепления соответствующих ценностей. Если первое можно найти, то второе гораздо труднее и дороже, а третье практически невозможно. В итоге ГОСТ 34 и 19 в массе больше понятен строительным и машиностроительным проектировщикам, чем профильным ИТ специалистам и менеджерам.

Проблемы самого ГОСТ 34

  1. В самой модели системы разделение на состав системы в физическом слое и в функциональном слое немного размыты. Такое разделение надо явно вводить в ТЗ.
  2. Вообще вопросы многослойной виртуализации не предусмотрены. При проектировании системы надо явно вводить все необходимые слои.
  3. Как было сказано, сами принципы, заложенные в основу, достаточно дороги в применении и подходят не для всех ситуаций.
  4. Существуют классы систем, для которых ГОСТ 34 не является основным и ключевым гарантом успеха при построении системы. Например, системы управления реального времени, где ГОСТ 34 ничему не противоречит, но и не снимает основных проблем и рисков. Недостаток ГОСТ 34 в отсутствии как ясной классификации систем, так и границ применения стандарта.

Распространенные заблуждения относительно ГОСТ 34, вызванные не только низкой квалификацией специалистов, но и распространенной модой на «не читал/ниасилил, но осуждаю»:

  1. Слишком много документации – это не так. Обязательны только ТЗ и ПМИ. По остальной документации надо принимать решение – писать/не писать, и с кем согласовывать.
  2. Диктуется водопад – это не так. Возможно любое пересечение во времени фаз и этапов. Однако ГОСТ 34 устанавливает определенные причинно-следственные связи между решениями, другими решениями и их реализацией, что диктует явные временные зависимости. На фоне отсутствующих механизмов управления проектными решениями это в итоге дает водопад.
  3. ГОСТ 34 устарел – это не совсем так. Там есть, что добавить. Однако большие системы федерального уровня успешно строятся по ГОСТ 34, но главное, переведенной на русский язык и утвержденной замены ему для проектов большого размера не существует, а иностранные стандарты, решающие те же проблемы по сути будут тем же самым.
  4. Есть хорошая статья про остальные мифы: http://reqcenter.pro/gost34-myths/

Естественно – это моя версия манифеста ГОСТ 34.
Для предварительной обкатки в узком кругу она лежит на boatmanshome.ru
и будет обсуждаться здесь:


Затем я положу ее на http://asbok.ru/ для более широкого обсуждения и распространения и мы будем считать, что у ГОСТ 34 есть манифест.


 
Файлов нет.[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]