Вячеслав Мизгулин.

Системный инженер. Как начать карьеру в новом технологическом укладе



скачать книгу бесплатно

– требования к управлению сервисами (Т2, Т3);

– требования к управлению средой (Т1, Т4);

– требования к мониторингу среды;

– требования к мониторингу сервисов.

В скобках приведены идентификаторы тех требований, которые мы уже писали ранее. Как видно, мы интуитивно заметили только две группы требований. Требования к мониторингу сервисов могут быть связаны, например, с количеством сервисов, которыми система должна управлять, типами сервисов и их результатов; это могут быть расстояния, время, частота получения информации и многое другое. Мониторинг среды также имеет свои особенности, например: количество точек сбора информации, конкретные измеряемые характеристики, периодичность измерений и многое другое.

Самое время определиться с тем, какие именно ресурсы и сервисы будут связаны с целевой системой. Это приведет к декомпозиции как самой функции системы, так и к декомпозиции потоков. Важно заметить, что каждый элемент схемы нуждается в спецификации, включающей как минимум:

– идентификатор;

– короткое название;

– полное название;

– входные параеметры;

– выходные параметры;

– иные функциональные связи.

У начинающих системных аналитиков часто возникает вопрос: «А когда нужно прекращать декомпозировать? Сколько уровней должно быть?». Если спецификация функции занимает меньше A4, значит её уже не надо декомпозировать. Еще вариант – если по спецификации можно найти и купить соответствующий модуль.

Когда функциональное описание использующей системы вместе со встроенной целевой системой будет закончено, нужно вспомнить, что было на рисунке 1. У нас есть первый вариант плана. Самое время оценить осуществимость такого плана. На данном этапе, конечно, рано выполнять подсчет затрат на весь проект. Требования совсем «сырые». Однако, имеет смысл пересмотреть список стейкхолдеров. В частности, существуют стейкхолдеры, связанные с системами в операционном окружении, от которых очень сильно зависит успех проекта. Как видно из рисунка 7, целевая система взаимодействует с системами обеспечения комфортных внутренних условий (вентиляция, отопление, увлажнение и проч.) и системами обеспечения сервисов (санузлы, эскалаторы, центры печати и проч.). Наша «коробочка с проводами» начнет использоваться только тогда, когда будет подключена ко всем требуемым системам в операционном окружении. Если отталкиваться от того, что валидация должна выполняться на предмет удовлетворения потребностей стейкхолдеров, то становится не очень понятно, как это сделать, когда система еще не встроена в использующую систему, но уже произведена и должна быть продана, чтобы компенсировать затраты на производство. Валидация, с точки зрения системной инженерии, возможна лишь в условиях эксплуатации (или максимально приближенных) и должна проводиться с участием пользователя и заказчика.

Если вы проектируете «коробочку с проводами», а ваша компания не планирует выполнять монтажные работы, потому что это другой бизнес, то, выходит, вы не можете гарантировать удовлетворение потребностей в рамках текущего проекта.

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

Это огромное количество различных стейкхолдеров, занимающихся эскалаторами, принтерами, кондиционерами, инженерной инфраструктурой, проводкой и т. д. Их то мы и забыли включить в таблицу 3. Надо это обязательно сделать. Тем не менее проблема зависимости от этих стейкхолдеров в вопросе успеха «коробочки» остается нерешенной. Как выполнять валидацию? Валидация – это практика жизненного цикла системы. Может быть, сейчас правильнее задать вопрос – а какой у целевой системы жизненный цикл?

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

Глава 4. Жизненный цикл системы и проекта

Конечно, менеджеры к этому моменту уже должны были согласовать жизненный цикл, но есть ли в нем валидация? Обычно менеджеры без особых проблем решают организационные вопросы с помощью модели жизненного цикла. Часто его выбирают исходя из опыта управления и не ждут сюрпризов, но сейчас возникла ситуация, в которой успех целевой системы «повис на волоске» из-за неоднозначности приемки и валидации, а это, между прочим, непосредственно относится к модели жизненного цикла, то есть инженерные и менеджерские задачи теперь неразделимы.

Допустим вы пойдете к менеджеру проекта и попросите показать выбранную модель жизненного цикла. Самое частое представление, которое я наблюдал на практике в ИТ-компаниях, может быть изображено так (рис. 8).


Рис. 8. Типовой жизненный цикл проекта


Часто проект не любят официально заканчивать. Вообще, у нас понятие проекта иногда имеет под собой какой-то мистический смысл. Ну и, как следствие, есть путаница между жизненным циклом проекта и жизненным циклом системы. В результате, а где, вообще, в жизненном цикле – валидация целевой системы? Если бы всё было так просто – взять и перерисовать этот жизненный цикл – но проблемы заключаются в деньгах.

Каждая стадия жизненного цикла имеет свой бюджет, во многом связанный с различными интересами вполне конкретных стейкхолдеров. Добавить еще одну стадию – забрать деньги из другой.


Рис. 9. Типовой вариант спирального жизненного цикла проекта


Вам могли показать другой вариант жизненного цикла, например как на рисунке 9. Спиральный жизненный цикл часто используют в индустрии программного обеспечения и информационных систем, даже чаще, чем это официально преподносится. Идея такого жизненного цикла предельно проста. Каждый виток – полный набор стадий от замысла до, иногда, продажи и сопровождения. Переход на новый виток выполняется в том случае, когда завершенный виток был успешен и есть благоприятный прогноз развития проекта. Обычно каждый новый виток значительно дороже предыдущего, разрабатываемый функционал шире, сама система сложнее. Вопрос в том, сколько должно быть приемок и валидаций в таком жизненном цикле?

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

Часто валидацию осуществляют путем имитации условий эксплуатации. Например, чтобы выполнить валидацию двигателя, надо где-то взять несколько автомобилей, соответствующих выявленным потребностям, вставить туда новые двигатели, провести тесты, то есть поездить на этих автомобилях, проанализировать результаты, подвести итоги.

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

Если не обговорить необходимость в таких крупных затратах «на берегу», что остается делать в середине проекта? Можно просто сделать «коробочку», а потом продавать её – сразу. Как вы думаете, если сделать новый двигатель, пропустить стадию испытаний на разных, например, автомобилях, и сразу выставить продукцию на продажу – будет ли проект успешен? Какие могут быть последствия от выбора такого жизненного цикла? Самое время обсудить проектные риски с руководством.

Системному инженеру было бы интереснее взглянуть на модель жизненного цикла такого рода (рис. 10).


Рис. 10. Вариант совмещения жизненного цикла системы и жизненного цикла проекта


На представленном рисунке видно, насколько могут различаться жизненные циклы проекта и системы.

Жизненный цикл системы – это набор связанных процессов, реализуемых одновременно, а жизненный цикл проекта – разовая последовательность работ. Проект – это, как бы, один проход через полный или частичный жизненный цикл системы.

Самый главный вопрос, который возникает при просмотре этой диаграммы, заключается в том, когда должен закончиться проект? Это любимый вопрос менеджеров проектов, отводящий нас к цели проекта. Хорошие менеджеры обычно планируют заработать денег на проектах, благодаря чему они отлично знают, когда нужно остановиться. Но это далеко не всегда так. Бывают случаи, когда проект перерастает в другой проект, в новый процесс, в программу, а иногда он просто кончается, порой внезапно. Прогнозировать подобные исходы весьма затруднительно, поэтому инженеру нужно стараться всегда делать системы как можно лучше. Используя наработки по успешным системам, гораздо проще инициировать новые проекты.

Менеджер будет стараться экономить деньги. Инженер должен стараться сделать систему лучше, а для этого потребуются дорогие материалы, модули, участие экспертов. Валидация может стать корнем раздора между менеджером проекта и системным инженером, особенно когда системный инженер подключается к проекту не с самого начала, потому что уровень затрат на валидацию может стать сюрпризом для менеджера.

Между делом выяснилось, что группа специалистов уже давно проектирует умный бизнес-центр без вашего участия. Так получилось, что ваша работа проистекает в команде менеджера проекта и отвечаете вы за документацию, а настоящая разработка идет в другой комнате третий месяц подряд – возможно даже она началась до формальной инициации проекта. Ваша реакция?

Скажем так, это неплохо, когда разработка и концептуализация идут параллельно. Плохо – когда они не связаны между собой в рамках проектирования. Само слово «проектирование» в России имеет несколько значений:

– чаще всего это слово означает любую работу на бумаге, включая концептуальный этап, разработку инженерных решений, иногда даже работу конструктора;

– иногда под проектированием понимают именно написание документации;

– редко, но встречается такой вариант, когда проектирование смешивают с управлением проектом, что нас, как системных инженеров, не устраивает.

Путаница связана с тем, что слово «проект» можно перевести на английский как project и как design. Когда я буду говорить про проект, я обычно буду иметь в виду project, а под проектированием я буду понимать design, при том я буду понимать под проектированием любую работу на бумаге (в компьютере), предшествующую непосредственному изготовлению изделия. Если изделие изготавливается в процессе проектирования – будем называть это конструированием. Если изделие изготавливается серийно, когда проектирование завершено – это уже производство.

Итак, группа специалистов уже запроектировала «коробочку с проводами», которая оперирует набором условий типа:

«Если (выполняется комплекс условий по входам), то (выходной вектор преобразуется по определенным правилам)».

Многие специалисты искренне не понимают, зачем нужны системные специалисты, ведь и так всё понятно, что надо делать. С точки зрения группы специалистов – этот продукционный решатель является, собственно говоря, конечным продуктом. Ну и чего же в нем не хватает? Даже не важно на каком уровне решена задача: микросхемой, программным обеспечением, либо, вообще, механически или гидравлически. Самое удивительное на данный момент заключается в том, что эти специалисты собрали готовый, с их точки зрения, продукт, когда мы с вами еще только обдумываем жизненный цикл системы. Упрекать их в этом, конечно, нельзя.

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


Рис. 11. Горбатая диаграмма жизненного цикла проекта


На горбатой диаграмме представлены распределения человеко-часов по стадиям и практикам жизненного цикла проекта. Практика разработки концепции применяется на стадии исследований и немного захватывает разработку. Инженерия требований идет с некоторой периодичностью вплоть до производства итерациями согласований. Архитектура обычно прорабатывается «большим горбом», потому что изменение архитектуры ведет к непредсказуемым последствиям – прорабатывают один раз и надолго. Дизайн, изготовление, сборка и проверка идут взаимозависимыми колебаниями довольно часто, поскольку речь идет о постоянном выпуске прототипов (опытных образцов). Валидация выполняется в конце разработки (в т.ч. имитационно).

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

Часто реальная продолжительность стадии жизненного цикла вдвое меньше запланированной именно из-за согласований, которые «сжирают» основное рабочее время.

Вот, вы пришли к руководителю проекта и начали тяжелый разговор:

– Ингеборг Карлович, есть несколько проблем.

– Каких? – недовольно пробурчал менеджер проекта.

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

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

Купить и скачать книгу в rtf, mobi, fb2, epub, txt (всего 14 форматов)



скачать книгу бесплатно

страницы: 1 2 3