Устройство и природа современных систем изменились. Практически каждая система сегодняшнего дня содержит компьютерные технологии, моделировалась с их помощью и/или поддерживается ими. Это расширение использования компьютеров и ПО привело как к новым возможностям, так и к новым проблемам. В результате эта комбинация аппаратных средств, ПО и людей подняла сложность систем на беспрецедентный уровень. И потребовался свежий взгляд на вещи. (Прим.: подчеркивание автора.) По тексту ISO/IEC 15288 CD2: 2000-01-21. Life Cycle Management — System Life Cycle Processes

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

Последние несколько лет практика проектирования все усложняющихся систем, развитие новых ИТ и их влияние на системы как предмет проектирования привели к разработке новых, отвечающих современным условиям стандартов. В результате появилось большое число основных базовых стандартов нового поколения, включая стандарты ISO/IEC и ISO/TR, ГОСТ Р ИСО/МЭК, EIA и ANSI, относящихся к основополагающим стандартам и стандартам на работы и процессы проектирования. Есть и такие, которые детализируют и поясняют способы применения важнейших процессов, описанных этими стандартами. В России лишь некоторые из них — в первую очередь надо назвать ГОСТ Р ИСО/МЭК 12207:99 — переведены, тем более — введены в действие и достаточно широко популяризируются. Однако есть и более чем достаточное количество других проблем.

Противоречия в положении со стандартами и их применением

Когда хотят охарактеризовать сложившееся положение в данной области, говорят, что:

  • рациональный путь развития отечественных систем нормативных документов заключается в применении международных стандартов (огромны накопленные в них запасы знаний, их использование дает «общий язык» для контактов с миром — его проектами, его изделиями, его специалистами);
  • закрепился подход к созданию систем с открытой архитектурой (а этот аспект проектирования — один из важнейших в части создания технических систем и классический в смысле разработки и применения стандартов);
  • новые стандарты проектирования (систем, ПО) ориентированы на процессный подход (то есть содержат в первую очередь описания сквозных бизнес-процессов проектирования и правила их внедрения);
  • существует и пропагандируется подход к созданию крупных систем и отраслевых решений на основе специальным образом формируемых «профилей» — гармонизированных совокупностей подмножеств различных стандартов, обязательных (в определенных рамках) для применения в конкретном проекте или на конкретном предприятии;
  • сформировался подход к оценке и сертификации систем качества и технологической зрелости организаций (не надо лишь путать сертификацию в этой области с реально функционирующей системой качества, приводящей к уменьшению брака, повышению характеристик качества продукции!).

Одновременно констатируется наличие достаточно противоречивого положения, которое — в наших условиях — состоит в том, что:

а) обеспеченность стандартами недостаточна (нет введенных в действие многих важных стандартов), и в то же время

б) совершенно недостаточно используются уже имеющиеся, введенные в действие стандарты.

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

Безусловно, революционность относительна, так как в стандартах нет (и не должно быть) «внезапных» или «эпохальных» открытий, но есть нормативно-методическое обеспечение реальных потребностей, очень часто игнорируемых в так называемых «ИТ-проектах». Причем понятно, что это обеспечение сформировано на основе подходов, ранее описанных в других источниках: статьях, монографиях, фирменных методиках, даже в учебниках. К упомянутым потребностям и подходам, в частности, относятся:

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

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

Вместе с тем очень многие проектировщики и предприятия оказались не готовы к использованию современных подходов и стандартов. Продолжают — с игнорированием необходимости в «интегрально полезных» системах — сохраняться перекосы в ту или иную профессиональную область, определяемые чаще всего доминирующими приоритетами отдельных групп разработчиков. Очень часто таким приоритетом является программное обеспечение (ПО), в лучшем случае — «информационная система» (ИС). Так же часто именно ИС считается конечным продуктом проекта.

Одна из причин этих перекосов состоит в том, что профессиональные приоритеты, которые есть и должны оставаться, трактуются ложно, в узком, «клановом» смысле. Эти перекосы отражаются в следующих типичных высказываниях многих специалистов в ИТ:

«Надо разграничить работы по проектированию ИС и работы по определению целей предприятия, его бизнес-процессов и т. д., надо формализовать переходы между этими работами; вот это и может быть объектом стандартизации!»

или

«Еще можно говорить о включении администраторов баз данных, сетевых администраторов (и т. п.) в состав системы, но включение в нее пользователей выведет нас далеко за пределы того, что определяется стандартами, и того, что является делом профессионалов!..»

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

С учетом сказанного выше тем более полезно рассмотреть такие особенности новых стандартов, как радикальные изменения в трактовке понятия «система», трехуровневая организация процессов проектирования на предприятии, другие существенные характеристики новых НД.

Рекомендации по выбору главных базовых стандартов

Есть ряд причин, стимулировавших разработку новых поколений стандартов. SPC (Software Productivity Consor-tium) относит к ним «трудность гармоничного сочетания и интеграции таких дисциплин, как наука, проектирование, менеджмент и финансы». Не менее важны причины, характерные для новейшего времени: резко возросшая изменчивость условий работы систем и требований к ним, возросшее многообразие условий их разработки и сопровождения, распределенность и глобализация систем, и даже текучесть кадров ИТ-специалистов в условиях, когда «программист», «отладчик» или «системный инженер» стали массовыми профессиями (см. также [1]).

SPC отмечает, что в этих условиях понадобились новые базовые стандарты типа framework, созданные для того, чтобы «улучшить общение и кооперацию между разными дисциплинами и вспомогательными системами, чтобы создавать, использовать [системы] и руководить [этими процессами] в интегрированном, согласованном стиле».

(Многие, включая автора данной статьи, передавали термин framework как тип стандарта словом «рамочный». Это вряд ли удовлетворительно, поскольку к таким стандартам относят и весьма детальные НД, содержащие эталонные модели, процедуры оценки и др.; в данном контексте рассматриваемые стандарты будут называться основными базовыми.)

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

SPC выделяет тот минимум стандартов на процессы проектирования, который рекомендуется взять за основу. В их число включены ISO/IEC 12207, ISO/IEC 15288 CD2, ISO 15504 (SPICE), EIA/ANSI 632, EIA/IS 731 (SECM), TickIT.

Мы рассматриваем здесь особенности содержания следующих НД.

  • ISO/IEC 12207, Information technology — Software life cycle processes. 1995.
  • ISO/IEC TR 15271, Information technology — Guide for ISO/IEC 12207. 1998. (Стандарт ISO/IEC 12207 оказал революционизирующее влияние на многие другие НД, в том числе на стандарты моделей системного проектирования: процессы жизненного цикла систем, модель зрелости процессов.)
  • EIA/ANSI 632, Processes for Engineering a System. 1999. (Этот стандарт не только заменил ряд популярных более старых американских стандартов, но был использован как вклад американской группы в создание ISO/IEC 15288.)
  • EIA/IS-731, System Engineering Capability Model (SECM). 1999. Part 1, SECM Model. Part 2, SECM Appraisal Method. (В области стандартов на уровни зрелости процессов аналогично тому, как модель SW CMM переросла в модель и стандарт SPICE, модель SE CMM переросла в модель и стандарт SECM.)
  • ISO/IEC 15288 CD2, Life Cycle Management — System Life Cycle Processes. 2000.

Нам для обеспечения преемственности полезно добавить в эту группу стандарты ГОСТ 34 (не гармонизированные с новыми, но применимые и полезные из-за совместимости по многим базовым понятиям, по сути многих работ, по опыту применения и др.).

Существенно, что два «потока» стандартов — на SE (system engineering) и на SW (software engineering), развивавшихся параллельно, четко стыкованы посредством указанных документов. И дело не только в том, что указанные НД хорошо согласованы друг с другом по основным понятиям и принципам. Очень важно, что такие, казалось бы, «чисто технические» области, как создание ПО (SW-процессы), регламентированы стандартами, прямо требующими их совместного применения со стандартами на процессы системного проектирования (SE-процессы).

Новая трактовка понятия «система»

Важно правильно определиться с основополагающим понятием, очерчивающим сам предмет рассматриваемой деятельности.

Есть три важных тезиса, из которых первые два связаны в значительной мере с общим пониманием (или непониманием), существующим в этой области, а второй и третий вместе отражают радикальные изменения. Эти тезисы таковы.

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

(В современных стандартах присутствует, например, определение более узкого и технического понятия: «3.1.3. Информационно-технологическая система (IT system): Набор информационно-технологических ресурсов, обеспечивающий услуги по одному или нескольким интерфейсам» (ГОСТ Р ИСО/МЭК ТО 10000-1-99). Это близко к понятию «комплекс средств автоматизации» в методических указаниях РД 50-680-88 из ГОСТ 34, в которых определяются основные положения этого комплекса НД.)

2. Новые базовые стандарты — и из области ПО, и из области системного проектирования согласованно опираются на понятие «система».

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

По определению ГОСТ Р ИСО/МЭК 12207:99: «Система (system) — это комплекс, состоящий из [бизнес-]процессов, технических и программных средств, устройств и персонала, обладающий возможностью удовлетворять установленным потребностям или целям».

Рис. 1. Система. ПО в системе

ISO/IEC TR 15271:1998 (руководство по применению ISO/IEC12207) уточняет и детализирует это определение, в том числе рисунком 1, в котором компьютерная система и поддерживаемые ею процессы входят в систему как часть и «объемлются» в ней бизнес-процессами (включая те, которые не имеют компьютерной поддержки).

Показательно постепенное исчезновение IS даже из названий стандартов при появлении их новых поколений. Так, промежуточный EIA/IS 632 заменен на EIA 632, а если в названии SECM EIA/IS 731 буквы IS остались, то в самом стандарте понятие IS не используется (используется «система»).

По ГОСТ Р ИСО/МЭК 12207 и ISO/IEC TR 15271, «система» — это объединение бизнес-процессов, аппаратных средств, ПО, другого оборудования и людей, дающее возможность удовлетворять определенные потребности, достигать определенные цели.

В отношении программного обеспечения эти стандарты требуют проверки требований к ПО и свойств ПО на соответствие потребностям заказчика (или иного «заинтересованного лица»), которые «передаются» в ПО отображенными в требованиях к системе — но не к ИС.

Заметим, что это не означает отсутствие ИС как сущности реальной жизни. Более того, в ряде случаев именно ИС и будет той итоговой системой, которая станет проектироваться, и это не противоречит указанным выше стандартам. Например, такой системой может быть подсистема выдачи справок о наличии мест в поездах, входящая в систему резервирования железнодорожных билетов. Важно, что такой тип системы — лишь частный случай.

К рассматриваемому понятию «система» ближе понятие «автоматизированная система» в упомянутых выше РД 50-680-88 из ГОСТ 34: «В процессе функционирования автоматизированная система представляет собой совокупность комплекса средств автоматизации, организационно-методических и технологических документов (в том числе описывающих технологию работы пользователей, то есть те самые «пресловутые» бизнес-процессы, которые ГОСТ 34 по понятным причинам так не называет. — Е. З.) и специалистов, использующих их в процессе своей профессиональной деятельности».

3. «Система» определяется не только как совокупность компонентов, действующих во время ее функционирования. Так, в стандартах EIA 632 и в ISO/IEC15288 CD2 в число новых концепций включены положения о том, что

а) Система = HW + SW + другое (персонал, материалы, услуги, данные, ... — «все, что потребует разработки или покупки: корабль, контейнер, мост, сценарий, экспонат, ...»;

б) Система = Конечные продукты (будут действовать в системе) + Вспомогательные продукты (необходимые для разработки, поставки, обучения и др.).

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

Одно это требование уже является достаточно революционным по отношению к существующей практике. Оно также отличает основные положения новых стандартов от таковых в ГОСТ 34.

В связи с определением системы полезно рассматривать и определение системного проектирования, которое, согласно INCOSE, International Council on Systems Engineering (один из разработчиков новых стандартов), представляет собой «междисциплинарный подход и средства, делающие возможным создание успешных систем».

Системное проектирование (толкование INCOSE) — дисциплина разработки продуктов или процессов на основе концепции систем. Оно фокусируется на определении потребностей заказчика и требуемых функций системы, установлении требований, выполнении конструкторского синтеза и аттестации с согласованием как бизнес-аспектов, так и технических аспектов данной задачи. Интегрирует необходимые дисциплины и группы специалистов в одну команду на протяжении всего жизненного цикла разработки (развития) системы.

(Предлагается обратить особое внимание на интеграцию специалистов и дисциплин, что трудно, но необходимо, в том числе для преодоления барьеров и перекосов.)

Новый объем процессов ЖЦ системы

Набор и объем процессов по содержанию кардинально расширились, см. на рис. 2 и 3 иллюстрацию этого расширения, приведенную во вспомогательном материале стандарта EIA 632. В частности, в новых стандартах объем процессов ЖЦ системы непосредственно связывается с определением стратегии и стратегических задач организации.

Рис. 2. Процессы ЖЦ системы по прежней (промежуточной) версии EIA 632 («старый стандарт по проектированию систем»)
Рис. 3. Объем процессов ЖЦ системы по новому стандарту EIA 632 («От старого к новому, от системного проектирования к полному проектированию систем»)

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

  • откуда берутся (должны браться) проекты и проектные программы?
  • как получить стандарты, регламенты, инструкции, которые рационально использовать именно на данном предприятии (стандарты предприятия)?
  • как управлять процессами проектирования на предприятии?
  • как получить набор стандартов конкретного проекта?
  • как обеспечить стыковку различных подпроектов?
  • что является определяющим критерием для проверки правильности выполнения проекта?

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

Принципиальными для изменения объема процессов в стандартах являются:

  • явный учет потребностей предприятия и требований Заинтересованных Лиц (ЗЛ): пользователей, заказчиков, других (инвестор, органы местной власти, профсоюз и др.), их первичность по отношению к «требованиям к системе»;
  • прослеживание эволюции требований (от потребностей и требований ЗЛ всех типов к системным техническим требованиям и далее к выработанным (детальным) техническим требованиям, а также между проектами и подпроектами);
  • большая роль экспертиз аттестации и др.

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

Указанные стандарты предполагают разработку стандартов следующих за ними уровней:

  • второго (конкретные области практики проектирования, стандарты уровня организации или предприятия) и
  • третьего (руководства, содержащие шаблоны для планов проекта, контрольные листы для экспертиз-рассмотрений и др.),

причем со специализацией для

  1. конкретных дисциплин (проектирование ПО, электрооборудования и т. д.),
  2. конкретных отраслей (фармацевтической, банковской, аэрокосмической и др.).

При этом ISO/IEC TR 15271, например, прямо говорит о связи ISO/IEC 12207 со стандартами уровня предприятия (организации) и, далее, со стандартами для конкретных типов задач и применения конкретных методов или приемов.

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

Рис. 4. ISO/IEC 15288. Иерархии систем и процессов (в том числе — управления)

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

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

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

Закреплен переход к рассмотрению проектов и проектных программ как инвестиционных акций. При этом в инвестиционной деятельности проекты анализируются и рассматриваются не как чисто финансовые акции, но с содержательной (в том числе — функциональной, архитектурной, технической) стороны.

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

В качестве примера приводится формулировка цели процесса управления инвестициями по ISO/IEC 15288 CD2:

«Цель процесса:

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

Указанные свойства процессов ЖЦ обеспечиваются в том числе их распределением между тремя уровнями: предприятия, проекта и конструирования, и соответствующей нагрузкой этих процессов.

На рис. 4 в блоке одного (каждого) предприятия показана общая схема трех уровней по ISO/IEC 15288.

Ниже приведены эти уровни и по три первых процесса из соответствующих списков предусмотренных на этих уровнях процессов.

УРОВЕНЬ «ПРОЦЕССЫ ПРЕДПРИЯТИЯ»

  • Управление предприятием (в части внедрения данного стандарта)
  • Управление инвестициями
  • Управление процессами ЖЦС
...

УРОВЕНЬ «ПРОЦЕССЫ ПРОЕКТА»

  • Планирование
  • Оценка (против плана)
  • Контроль
...

УРОВЕНЬ «ТЕХНИЧЕСКИЕ ПРОЦЕССЫ»

  • Определение потребностей ЗЛ
  • Анализ требований
  • Конструирование архитектуры
...

Можно отметить, что в разных стандартах наблюдаются несколько отличающиеся формальные «приписывания» процессов разным уровням, группам и т. п. Это не должно смущать проектировщика, поскольку первична суть процессов. Важно, что во всех случаях новые распределения и нагрузки процессов состоят, в частности, и в том, что вопросы стратегии и стратегические планы/задачи организации, ее бизнес-цели являются предметом анализа, контроля и др. на всех этих уровнях.

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

Организация проектной деятельности, стандарты уровня предприятия и проекта

В стандартах явно предусмотрены работы по постановке проектной деятельности и управлению ею. В ISO/IEC 15288 такими являются:

  1. процесс «Управление предприятием» (внедрение стандарта на основе стратегии предприятия),
  2. процесс «Управление процессами ЖЦС»,
  3. процесс «Управление ресурсами для а) и б)».

Для процесса «Управление предприятием» предусмотрены следующие цель и результаты.

«Цель процесса:

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

Результаты процесса:

  1. Стратегические и тактические планы и цели [предприятия], которые определяют формирование правил и процедур для внедрения требований данного Международного Стандарта.
  2. Правила и процедуры для «управления ЖЦС», включая управление качеством, гарантии и контроль, в соответствии с ISO 9001.
  3. Роли, ответственность и права (власть), способствующие эффективному управлению ЖЦС».

Результатами других процессов являются принятые для предприятия (организации) модели ЖЦС, а также процедуры, методики и другие НД (в том числе стандарты или их подмножества), составляющие стандарт организации. При этом в рассматриваемых нормативных документах подробнее определяется получение такого стандарта уровня предприятия именно в части процессов проектирования.

Специальные процессы адаптации предусмотрены для получения стандартов проекта (в части процессов проектирования таковым является процесс tailoring). Стандарт уровня проекта включает в себя модель ЖЦС, адаптированную для данного проекта (из правил применения ISO/IEC 12207: «Не существует двух одинаковых проектов»). Такая адаптация является частью работ по управлению проектом, и ее целесообразно рассматривать в отдельной публикации.

Существенно, что и по линии ПО (SW), и по линии системного проектирования (SE) за основу модели ЖЦ ПО или системы соответственно берется совокупность стадий, фаз и этапов. Модель ЖЦ генерируется наложением процессов (их работ и задач) на выбранную и приспособленную для проекта совокупность стадий, фаз и этапов. В связи с этим в ISO/IEC 15288 CD2 и ISO/IEC TR 15271 рассматриваются близкие, но не совпадающие типовые наборы стадий (рассматриваемые только как исходные для адаптации). Это говорит о том, что в стандартах не рассматривается процессный подход «в чистом виде», а признание важности организации работ по стадиям и изложение соответствующего подхода генерации модели ЖЦ должны облегчить восприятие и применение новых стандартов.

Важно также, что эти положения стандартов дают конструктивную основу для адаптации стандартов ГОСТ 34 к новым процессам и моделям работы (моделям ЖЦ системы), что позволяет:

  1. обеспечивать преемственность в применении стандартов,
  2. использовать содержательные описания работ и «начинки» документов, имеющиеся в ГОСТ 34 как один из способов конкретизации стандартов уровней предприятия и проекта (см. также [2]).

Такой подход к продолжению использования ГОСТ 34 полностью соответствует, кроме всего прочего, и рекомендациям SPC по использованию накопленных в организациях моделей и закрепленных в контрактах стандартов.

В качестве заключения отметим, что:

требования к техническим частям (ПО, аппаратура) должны соотноситься с требованиями к СИСТЕМЕ и с потребностями в ее приобретении (нельзя замыкаться в требованиях к «ИС»);

в организациях должен вестись новый объем управленческой и методической работы:

  • соединение бизнес-слоя и ИТ-слоя систем,
  • создание и совершенствование моделей ЖЦС для этой организации и для каждого проекта,
  • формирование комплексного стандарта уровня предприятия и уровня проекта с включением в него НД на процессы и стандартов на языки и интерфейсы ИТ, и др.
  • сохранение в стандарте уровня предприятия достаточной гибкости для того, чтобы он мог в нужных пределах адаптироваться под проекты и не становился тормозящим фактором;
  • такая работа может вестись «сверху вниз» (от основных базовых международных стандартов к стандартам проекта), «снизу вверх», но лучше — с применением обоих этих подходов;
  • использование лишь даже отдельных положений новых стандартов в реальных проектах приносит (и уже приносило) несомненную пользу.

Литература

1. Зиндер Е. З. Новое системное проектирование: информационные технологии и бизнес-реинжиниринг // СУБД, 1996, № 1, 2.

2. Зиндер Е. З. Соотнесение и использование стандартов организации жизненных циклов систем // СУБД, 1997, № 3.

Об авторе

Евгений Захарович Зиндер — директор Аналитического и конструкторского бюро «Группа 24», шеф-консультант журнала «Директор информационной службы». Ему можно написать по адресу ezinder@osp.ru


Ключевые моменты:

  • противоречия в положении со стандартами и их применением
  • рекомендации по выбору главных базовых стандартов
  • новая трактовка понятия «система»
  • новый объем и наполнение процессов ЖЦ системы
  • связь проектов систем с бизнесом предприятия
  • организация проектной деятельности и стандарты уровня предприятия

I Всероссийская практическая конференция

«Стандарты в проектах современных информационных систем» — продолжение следует

Евгений Зиндер

17 - 18 апреля в Москве собрались люди, может быть, наиболее заинтересованные в своем деле. Ведь апрель в столице — это месяц экстремального «сгущения» семинаров и конференций. Тематика их бесконечно разнообразна, и то, что столько людей съехались именно на стандарты, доказало необходимость и своевременность конференции. Стандарты — вещь не очень-то развлекательная, можно было найти тему и полегче!

Эта конференция действительно была всероссийской. И дело не только в том, что собрались люди из разных краев и областей — от Дальнего Востока до обоих Новгородов, от Норильска и Сургута до Самары и Воронежа. Она принципиально отличалась от «фирменных» мероприятий, которые часто тоже называют конференциями (надо сказать, что число «настоящих» конференций за последние десять лет уменьшилось многократно).

Проведенная при поддержке ВНИИстандарта Госстандарта России и ряда других авторитетных организаций, конференция была тем не менее первым форумом по тематике стандартов, организованным не по официальному государственному или ведомственному плану, а в результате широкой инициативы заинтересованных специалистов, общественных организаций и предприятий. Журнал «Директор информационной службы» стал тем независимым органом, который объединил представителей различных, иногда конкурирующих предприятий и направлений.

Конференция привлекла более 100 участников (не считая докладчиков). Были представлены администрации (правительства) областей и автономных республик, коммерческие фирмы и исследовательские институты, предприятия Министерства обороны и гражданских отраслей. Слушателями были специалисты и руководители высокого уровня, включая директоров и вице-президентов. Состав докладов формировался на основе их открытого привлечения с двухступенчатым отбором в программном комитете. Большинство участников активнейшим образом работали на конференции все два дня — вплоть до финального заседания, на котором были выработаны важные рекомендации. В работе конференции государственный подход к обсуждаемым вопросам (тема обязывает!) сочетался с реальными рыночными мотивами. Сборник трудов конференции — более 150 страниц — включил расширенные тезисы 29 основных докладов.

Двумя ключевыми вопросами были следующие:

  • в чем причина столь слабого применения уже существующих стандартов (включая новые ГОСТ Р)?
  • в каких областях проектов систем и для каких частей самих систем стандарты нужнее всего?

Ориентация на эти вопросы позволила назвать конференцию практической. Это не значит, что программный комитет игнорировал «научную точку зрения», однако главным было выделение проблемных вопросов, актуальных для живой практики. В сборнике трудов вы можете прочесть материалы, представленные специалистами из Магнитогорска, Тольятти, Перми, Екатеринбурга, а также из Москвы, в которых говорится о практике применения стандартов на предприятиях и в проектах. Во многих отношениях именно они первыми отвечают на те самые ключевые вопросы.

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

На двух тематических дискуссиях и на заключительном заседании было высказано много важных мнений и рекомендаций, вошедших в итоговое заключение конференции, в частности пожелание подготовить статьи на основе докладов, вызвавших существенный интерес, и опубликовать их. Первой подготовленной стала моя статья «Революционные изменения базовых стандартов в области системного проектирования», см. этот выпуск журнала. Далее мы рассчитываем поместить статьи В. И. Артемьева, Е. Н. Филинова и А. В. Бойченко, а также В. В. Васютовича, затем продолжим этот процесс.

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

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

Евгений Захарович Зиндер — председатель оргкомитета конференции

Поделитесь материалом с коллегами и друзьями