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

Устройство и природа современных систем изменились. Практически каждая система сегодняшнего дня содержит компьютерные технологии, моделировалась с их помощью и/или поддерживается ими. Это расширение использования компьютеров и ПО привело как к новым возможностям, так и к новым проблемам. В результате эта комбинация аппаратных средств, ПО и людей подняла сложность систем на беспрецедентный уровень. И потребовался свежий взгляд на вещи. (Прим.: подчеркивание автора.) По тексту 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. процесс «Управление ресурсами для а) и б)».

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

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

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

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

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

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

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

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

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

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

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

Литература

Об авторе

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

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

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