BoatmansHome: АвтоматизированныеСистемы/ЖизненныйЦикл
Данные материалы созданы для размещения на сайте boatmanshome.ru, автор и обладатель исключительного права - Нужненко Сергей Александрович. Для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 
Ниже разбираются стадии жизненного цикла (ЖЦ) автоматизированной системы (АС) и их типичное соответствие фазам проекта из методологий управления проектами, фазам взаимоотношений заказчика и исполнителей с точки зрения контрактирования, бюджетирования и взаиморасчетов.
Моя задача показать цели каждой стадии.
Так же разберем ключевые риски проектов построения АС, вызванные нарушением очередности стадий и/или пропуском ключевых решений и работ.

Оглавление


Стадии жизненного цикла автоматизированной системы

Названия стадий взяты из ГОСТ 34.601, но вне зависимости от стандарта любая АС будет проходить примерно такой же путь с точки зрения последовательности принятия решений.

1. Формирование требований к АС – цель определиться с решаемыми проблемами, классом системы и ключевыми требованиями на вход к следующей стадии.
2. Разработка концепции АС – цель спроектровать эскизную информационную технологию, концептуальную архитектуру АС, прикинуть варианты реализации и стоимости владения. Если повезет, выполнить ТЭО.
3. Техническое задание – цель спланировать создание АС, заложить бюджет, получить при необходимости документацию для запроса котировок или тендера(ов).
4. Эскизный проект – цель предварительное проектрование, макетная проработка и исследовательская проработка сложных частей;
5. Технический проект – цель проектирование системы;
6. Рабочая документация – здесь пишется код, детальные планы развертывания программно-технических средств, методическая и техническая документция и все остальное, что нужно для развертывания.
7. Ввод в действие – собственно, стройка: найм/комплектация людей, их обучение, закупки покупных частей, пуско-наладка железа и софта, а так же испытания в три захода: предварительные, опытная эксплуатация, окончательные.
8. Сопровождение АС – здесь правим баги, разрешаем инциденты и т.п.
9. Следующий цикл развития АС.

Связь с конусом неопределенности

Как (в типичном случае) стадии накладываются на конус неопределенности показано на картинке:

file:asst.png

В качестве меры неопределенности выбран разброс бюджета проекта (который отражает детализацию плана и понимание, что будем делать), который в реальности может быть измерен как по текущей оценке разброса, так и постфактум по разнице между оценкой на данной стадии и фактическими затратами.

При нормальном ходе событий (зеленая линия):

0. До проекта у нас достаточно смутный намек на решаемую проблему и стоимость ее решения пока ограничивается лишь наличием денег. Можно считать, что разброс затрат от -(стоимость компании)* до +(все наличные деньги и высоколиквидные активы).

1. Формирование требований к АС. Определившись с классом системы, рамками объекта автоматизации и решаемыми проблемами, мы можем оцениться по аналогии, что обычно дает точность до порядка.

2. Разработка концепции АС. Здесь становится видна декомпозиция системы – функциональный состав, состав системы на физическом уровне, связи. При сложении оценок хотя бы 50–100 элементов по аналогии должна бы получаться достаточно хорошая точность, но нам портит всю малину нелинейная взаимосвязь элементов, а так же многошаговая технология построения АС, образующая цепочки, вдоль которых проявляет себя эффект накопления дефектов. По этому считается, что точность оценки бюджета на этой стадии – полпорядка** .

3. Техническое задание. Тут не принимаются новые решения по облику системы, максимум – выбирается вариант реализации. Изменение границ оценки связано в основном с трюками на проектном треугольнике и реестре рисков, когда для более жесткой фиксации бюджета мы берем за обязательство среднюю (и выше) оценку и кладем в запас еще 30–50% или делаем плавающими объем и качество, приоритезируя требования.

4. Эскизный проект. На эскизной стадии снимаются ключевые технологические риски, а так же пользователи рассматривают макеты и уточняют свои требования. Это повышает точность планирования на величину снимаемых рисков.

5. Технический проект. Здесь система декомпозируется на достаточное число элементов, чтобы загнать оценки в примелемые ±10% точности. Неопределенность следующих стадий связана в основном с возможным выявлением ошибок.

6. Рабочая документация. Тут не происходит существенного уточнения, но возможно, всплывают ошибки.

7. Ввод в действие. К концу этой стадии мы уже почти точно знаем стоимость создания системы, так как почти все закончено.

8. Сопровождение. На сопровождении будут еще какие-то затраты, однако в нормальном случае (если при проектровании не наляпали ошибок) их величина невелика и хорошо прогнозируется.

Такая форма конуса работает, если

Иначе форма конуса неопределенности может быть более пологой, а окончательной определенности по оставшимся затратам может так и не наступить (красная линия).

Связь с контрактным, бюджетным циклами и фазами проекта

Для не громадной АС ниже на картинке показаны рамки, когда могут выполняться различные работы проектного цикла, контрактного цикла и бюджетного цикла. Здесь показана ситуация, с бюджетом одного уровня и построением системы в один проект с привлечением компании(ий) интегратора/вендора в качестве генподрядчика или поставщика услуг/железа/софта.

file:pcb.png

Для проекта:

С точки зрения контрактного и бюджетного циклов важно понимать, что

Перечисленные выше отношения задают достаточно жесткий (с точки зрения последовательности) нормальный процесс построения АС в организации (про отклонения ниже обсудим).

Для очень маленьких, очень простых и, наоборот, громадных систем цикл может пойти по другому.
В случае с простыми системами концепция может быть ясна и не нуждаться в написании, вместо концепции и ТЗ может выступить текст технико-коммерческого предложения от поставщика, а все создание системы уложится в пару часов установки коробочного ПО и инструктажа полутора пользователей, как с этим обращаться.
В случае с громадными системами может быть несколько уровней бюджета (на систему/на много лет, на подсистему/на год) и самостоятельный бюджетный, контрактный и проектный процессы по каждой подсистеме. Но взаимосвязи и очередность принятия ключевых решений остаются такими же.

Типичные проблемы с ЖЦ АС

Не важно, работает команда по ГОСТ или нет, последовательность принятия решений и взаимосвязи бюджетного, проектного цикла с фазами ЖЦ АС остаются прежними.

Самые большие риски проекта связаны с нарушением правильной последовательности:
1. Перед ТЗ не делается концепция и требования заказчика, ТЗ (или заменяющий его документ) получается расплывчатым, бюджет закладывается без понимания рамок проекта.
2. Если реализуется предудущий пункт, и после запуска проекта так и не происходит проработки концепции системы, команда получает или проектный паралич, или работает «из головы», надолго отрываясь от реальности, что не идет на пользу удовлетворению ожиданий заказчика и пользователей.
3. Если вместо проработки функционального состава системы, НФТ, границ объекта автоматизации и целей автоматизации идет обсуждение внедрения конкретных платформ и марок ПО (например, «будем внедрять MS Project»), то мы получаем прекрасную возможность спорить годами, ни к чему не приходя. Дело в том, что выбор ПО делается или при многовариантной проработке концепции или по итогам запросов котировок с уже написанным ТЗ. Попытка перепрыгнуть сразу три стадии дает слишком много неопределенности и отсутствие здравых критериев выбора. Сюда часто накладывается и путаница с классом системы, которую я описывал в /АвтоматизированныеСистемы/КакОниЕсть.
4. С другой стороны жизненного цикла нас тоже могут ждать подвохи.
4.1. Если в ходе концептуальной проработки не заложены хоть как-то измеримые цели автоматизации, система рискует не выйти из опытной эксплуаптации никогда. Если ТЗ было расплывчатым, то исход сдачи-приемки полностью остается на усмотрение заказчика. Конечно, усмотрение заказчика тоже вещь не всегда враждебная команде проекта, но в любом случае мы, как минимум, получаем дополнительную работу, нервы и расходы, которых можно было избежать. Я лично участвовал во многих проектах, к которым был подключен на стадии завершения с задачей «отстрелить бесконечный хвост и закрыть долги комипании».
4.2 Очень частой причиной постоянных сдвигов завершения опытной эксплуатации (или затяжек при сдаче-приемке) является то, что пользователи боятся, что сейчас автоматизаторы уйдут, и что-то может пойти не так. Это бывает из-за того, что
а) в плане нет поддержки с ясными гарантиями исправления ошибок;
б) пользователи не уверены в полноте функций системы с точки зрения достижения их рабочих целей – это опять следствие плохой концептуальной проработки.

Это все можно коротко подытожить так: качество работ, выполненных до бюджетирования и планирования проекта (а это требования заказчика и концепция) сильно влияют на риски того, что делается после.
На картинке с конусом неопределенности видно, риски какого размера устраняют первые две стадии. Если они выполнены плохо, в проекте остается неопределенность размером в ±порядок-полпорядка.

И часто в нашей практике качество выполнения начальных стадий оставляет желать лучшего:

Сюда примешивается то, что на концептуальную стадию и ТЗ накладывается необходимость урегулировать ряд органических конфликтов организации:

В итоге не смотря на то, что к первым трем стадиям ЖЦ АС часто относятся, как к досадным бумажкам, именно в их правильном выполнении кроется возможность снизить риски внедрения до приемлемых с точки зрения успешного построения АС.

Проблемы следующих стадий чаще всего связаны с технологическими рисками, а так же неполными составми работ, которые недопланированы и недобюджетированы. Сплошь и рядом выстреливают типовые риски:
1. написали софт и забыли купить железо;
2. не выделили пользователей;
3. не заложили обучение;
4. не заложили группу поддержи пользователей;
5. и так далее по списку видов работ (например, из ГОСТ 34.601) вплоть до того, что купили железо, но его некуда ставить, так как забыли выделить серверную.

Некачественное планирование возникает чаще всего в трех случаях:
1. Сознательное (каша из топора) или несознательное (как-нибудь прорвемся) занижение бюджетируемой суммы;
2. Просто не хватает квалификации;
3. Снова разное понимание класса создаваемой системы, вызывающее разрыв ответственности. В /АвтоматизированныеСистемы/КакОниЕсть в последнем разделе я описывал этот эффект.

В целом в ЖЦ АС нет ничего сложного. При этом, в отличие от софта, который поначалу лкгко писать по принципу «найдем баги-перепишем», жизненный цикл автоматизированной системы не прощает отклонений и возвращает многократно каждый дефект, заложенный на предыдущих стадиях.


Примечания:
* – Лучшее лекарство от перхоти – гильотина. Радикальным решением любой проблемы с точки зрения собственника может стать как продажа компании, так и ее закрытие.
** – sqrt(10) примерно равно 3,16 – это примерно равно числу «пи», на которое так любят умножать оценки умудренные опытом коллеги.