"Наибольшая свобода - это зависимость только от законов", - провозглашает "АиФ" в московском метро. Не сообщается, любые ли законы годятся? И всегда ли хорошо быть таким свободным? А без знания этого даже согласие подчиняться стандартам разработки систем становится рискованным решением.
Основное значение темы
Растут размеры и сложность автоматизированных систем (АС). Радикально изменились и продолжают меняться требования не только к основным функциям и сервисным возможностям систем, но и к динамике их изменения. Много писалось о том, что классические способы разработки и обеспечения качества АС перестали действовать. Разработка и развитие промышленных систем среднего, а часто и небольшого размера классическими методами не приводит к уровню качества, адекватному реальным требованиям (обзор истоков этой проблемы при разработке АС имеется в ,[4а], при проектировании баз данных - в [5а]).
Полезны в этом отношении стандарты открытых систем (в первую очередь стандарты на интерфейсы различных видов, включая лингвистические, и на протоколы взаимодействий). Однако разработка систем в новых условиях требует также новых методов проектирования и новой организации проектных работ. Проектирование и методическая поддержка организации разработки АС (включая ПО - программное обеспечение, и БД - базы данных) традиционно поддерживаются многими стандартами и фирменными методиками. Вместе с тем известно, что требуется адаптивное планирование разработки, в том числе - в динамике процесса ее выполнения. Некоторый набор требований адаптивности изложен в третьей части цикла [4а] при характеристике подхода Н.С.П. Одним из способов адаптивного проектирования является разработка и применение профилей Жизненного Цикла (ЖЦ) АС и ПО. Возможный подход к построению таких профилей изложен в работе [г], содержащей полезные исходные сведения и предложение более прагматичного подхода к созданию профилей ЖЦ, чем жесткая трактовка понятия профиля, принятая в международной функциональной стандартизации.
Представляется важным более конкретно рассмотреть несколько принципиальных свойств имеющихся стандартов, в первую очередь - качественное отличие стандарта ISO/IEC 12207:1995 на процессы и организацию ЖЦ от большого числа других стандартов и методик. Это рассмотрение приводит к рекомендациям по способу совместного использования в реальных проектах стандартов (включая стандарты серии ГОСТ 34) и частных (в том числе - фирменных) методик, разработанных на детальном уровне. Представляется, что эти рекомендации отвечают потребностям разработки систем в новых условиях.
Значимость вопроса определяется также:
- ограничивающими свойствами многих национальных стандартов и фирменных методик;
- наличием негативных стереотипов восприятия многими разработчиками и руководителями стандартов ЖЦ АС и ПО;
- часто более низким интересом разработчиков к стандартизации ЖЦ ПО в отличие от функциональной стандартизации;
- недостаточным вниманием к вкладу руководителей в формирование требований и методик организации процессов ЖЦ на предприятии;
- продолжающимся объявлением подходов-"панацей" (например, объектно-ориентированного анализа/проектирования/программирования).
О видах стандартов
После конференции АПО/ROUG97 (Таруса, июнь 1997), где автор сделал доклад "ISO/IEC 12207, ГОСТ34, Oracle CDM - процессы, результаты, соотнесение", обнаружилось, что: а) интерес к теме есть и у отдельных людей, и у коллективов, б) конструктивно говорить на эту тему можно только после выяснения и принятия говорящими более-менее одинакового понимания того, что такое стандарт и какие они бывают.
Примем такую упрощенную картину группировки стандартов и схожих методических материалов:
- по предмету стандартизации: функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию Жизненного Цикла (ЖЦ) создания и использования Автоматизированных Систем (АС) и Программного Обеспечения (ПО);
- по утверждающей организации: официальные международные стандарты, официальные национальные или национальные ведомственные (например ГОСТы, ANSI, IDEF0/1), стандарты международных консорциумов и комитетов по стандартизации (OSF, OMG, ранее широко известный CODASYL), стандарты "де-факто" (таким долгое время был SQL или язык диаграмм SADT Д. Росса), фирменные стандарты (Microsoft ODBC, IBM SNA);
- по методическому источнику: методические материалы фирм-разработчиков ПО, фирм-консультантов, научных центров, консорциумов по стандартизации (например, Oracle Method, Price Waterhouse SMM, SEI CMM); они могут называться по-разному - например, "Метод", "Методология", "Подход", "Модель".
Принципиально важно и часто не очевидно, что в каждую из этих групп и подгрупп входят материалы, существенно разные по:
- степени обязательности для организаций разного типа;
- конкретности и детализации содержащихся требований;
- открытости и гибкости, адаптируемости к конкретным условиям.
Непростые вопросы и различия интересов
В этой ситуации попробуем дать хотя бы часть ответов на вопросы:
- почему полезны "неконкретные" стандарты, несмотря на их кажущуюся многим полную бессмысленность: "одни общие слова, а что собственно делать - не написано !";
- в какой мере можно (полезно или вредно - другой вопрос) делать стандарты обязательными для себя - своей фирмы или проекта;
- как безопасным для себя образом использовать жесткие и конкретные методические конструкции фирменных методик или стандартов.
Такой "зачин" отчасти появился после небольшого опроса среди практиков-разработчиков и руководителей (как проектов, так и софтверных фирм), но также поставщиков ПО, внедренцев, конечных пользователей, стихийно проведенного автором в мае-июле 1997 года. Местами опроса были Москва, Сан-Франциско, калифорнийский Ньюпорт-бич и калужская Таруса. В разных формах и с разной степенью настойчивости задавался один вопрос: "считаете ли вы действительно полезным для себя применять стандарты на ЖЦ АС и ПО?" Конечно, ни выборку респондентов, ни методику опроса нельзя назвать научно корректными, но они сформировали определенное личное впечатление, которое и приводится.
1) Почти все соглашались с пользой функциональных стандартов, но многие отмечали, что и при наличии международных стандартов работать чаще приходится с фирменными, например с конкретным SQL Oracle 7.3. (Возникала интересная тема: насколько готовы программисты к самодисциплине применения только стандартных подмножеств фирменных реализаций языков программирования?)
2) Разработчики-программисты чаще рассматривали ГОСТы или другие стандарты на ЖЦ, т. е. на организацию разработки ПО, как нежизненные материалы, мешающие в практической работе, которая слишком часто сегодня идет не так, как планировалось вчера.
Требования к обеспечению качества ПО, включающие несколько видов внутреннего контроля, характеризовались некоторыми респондентами как мазохизм особого рода, который может быть теоретически хорош, но на который в реальной жизни нет времени. Внешний контроль рассматривался как вмешательство во внутреннюю кухню и не приветствовался.
(Оценки московских практиков во многом совпадали с оценками американских программистов, работающих и в небольших, и в весьма крупных компаниях. Тем не менее, во многих фирмах США специальность "quality assurance" стала чуть ли не массовой профессией.)
3) Многие разработчики, в первую очередь - аналитики, выполнившие и оформившие несколько проектов по какому-либо стандарту или методике и за счет этого накопившие свой набор образцов проектной документации, говорили о той пользе, которую дает использование этих образцов в качестве шаблонов: "заменил фактические данные, слегка поправил остальной текст - и новый проект готов!". О пользе шаблонов говорили и приверженцы детальных фирменных методик. Однако были и другие сообщения, в которых признавалось неудобство малой гибкости в предусмотренных методикой способах ее адаптации к конкретному проекту: жизнь оказывалась богаче таких способов.
4) Руководители проектов чаще считали стандарты на ЖЦ полезными или даже необходимыми, рассматривая их в первую очередь как средство организации управления разработкой. Наблюдался "уклон" в предпочтение конкретных методик по причине более простой управляемости проектами. При обсуждении требований к контролю качества разработок выяснялась ситуация: реальное осуществление этих требований далеко не всегда признавалось полезным, так как удорожало разработки, требовало внедрения новых организационных механизмов, а по сути - выращивания новой производственной культуры в фирме.
5) Может быть, поскольку внедрение этих механизмов сложно и дорого, руководители организаций часто уходили от принятия решений об использовании или неиспользовании стандартов и действий по обеспечению качества, отдавали их на откуп руководителям проектов и служб: "у них есть БД выполненных фирмой проектов, фирменная методика по проектированию систем и Intrаnet - пусть сами и решают!".
6) Самое осознанное стремление к использованию стандартов и методик с максимальным использованием предусмотренных требований, типов документов и действий по обеспечению качества демонстрировали грамотные и опытные заказчики/покупатели ПО и АС и внедренцы этих систем. Это давало им инструмент, на который они могли рассчитывать в непростых ситуациях приемки заказанного продукта для обеспечения его полноты и качества.
7) Конечным пользователям (настоящим, а не программистам или начальникам) важно было только "чтобы работало правильно, было удобно и не ломалось".
Различие интересов отразилось и в некоторых положениях работы [2], наприме, в выделении компонентов Информационных Систем (ИС). Отметим, что ИС в огромном числе практически значимых случаев является системой автоматизации функций управления на предприятии, то есть "пресловутой" АСУ. В этом случае скелет организации работ по созданию ИС образуют также руководства по созданию организационного обеспечения системы (включая аспекты бизнес-анализа и возможного BPR), правового обеспечения, и др. Вряд ли можно согласиться с тем, что разработка ПО является наиболее трудоемкой частью создания АСУ. Это видно и на примерах ИС других типов, например ИСС, в которых неизмеримо большим является объем трудозатрат на поиск и подготовку (и актуализацию в последующем) данных, составляющих информационную базу ИСС. Также нельзя согласиться и с тем, что срок жизни ИС определяется сроком жизни ПО. Автору приходилось осуществлять успешные проекты, когда ИСС (включая ее персонал) продолжала и продолжает функционировать на принципиально новых компьютерных средствах - аппаратных, ОС, СУБД, прикладном программном комплексе - используя (и продолжая наращивать) свою информационную базу, составляющую наибольшую ценность этой ИСС.
Можно предположить, что многие обсуждаемые оценки в известном смысле типичны, поскольку определены "программистско-центристским" взглядом компьютерных специалистов.
Рассматриваемые стандарты
Далее будем рассматривать следующие стандарты и методики, касающиеся ЖЦ АС и ПО:
- Стандарты комплекса ГОСТ 34 на создание и развитие АС - обобщенные, но воспринимаемые как весьма жесткие по структуре ЖЦ и проектной документации. Кроме того, эти стандарты многими считаются бюрократическими до вредности и консервативными до устарелости. Насколько это так, а насколько ГОСТ 34 остается работающим с пользой - полезно разобраться.
- Международный стандарт ISO/IEC 12207: 1995-08-01 на организацию жизненного цикла продуктов программного обеспечения (ПО) - казалось бы весьма неконкретный, но вполне новый и отчасти "модный" стандарт. См. также [2].
- Методика Oracle CDM (Custom Development Method) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, расчитанных на прямое использование в проектах АС с опорой на инструментарий Oracle. См. [3], [1].
К сожалению, рассматривать стандарты может быть очень скучным для чтения делом.*) К тому же - каждый из указанных выше материалов изложен на многих десятках и даже сотнях страниц. Поэтому больше внимания уделим основным характеристикам и положениям ISO 12207, тем более, что Oracle CDM представлен в [1]. Хочется надеяться, что ГОСТ 34 известен "по жизни" (если это не так, то пробел рекомендуется ликвидировать), поэтому приведем лишь некоторые положения этого объемного комплекса. Такое описание приемлемо, так как в журнальной публикации соотнесение этих стандартов возможно также только на уровне общей структуры и основных особенностей.
Методика Oracle CDM
1) Возникла как развитие разработанной давно версии Oracle CASE-Method, известной по использованию Oracle CASE (ныне Designer/2000) и книгам Р. Баркера. CDM теснейшим образом опирается на использование инструментария Oracle, несмотря на утверждения (см. описание CDM) о простом приспособлении CDM к проектам, в которых используется другой инструментальный комплекс.
2) Общая структура.
2.1. ЖЦ формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов.
2.2. Этапы:
- "Определение требований" (представляется более точным по форме и содержанию переводом, чем "Стратегия" в [1], далее наименования в большинстве случаев - но не всегда - выбраны совпадающими с принятыми в указанной публикации);,
- "Анализ" (формулирование детальных требований к прикладной системе);
- "Проектирование" (преобразование требований в детальные спецификации системы);
- "Реализация" (написание и тестирование приложений);
- "Внедрение" (установка новой прикладной системы, подготовка к началу эксплуатации);
- "Эксплуатация" (поддержка и слежение за приложением, планирование будущих функциональных расширений).
2.3. Процессы:
- RD - Определение производственных требований,
- ES - Исследование существующих систем,
- TA - Определение технической архитектуры,
- DB - Проектирование и построение БД,
- MD - Проектирование и реализация модулей,
- CV - Конвертирование данных,
- DO - Документирование,
- TE - Тестирование,
- TR - Обучение,
- TS - Переход к новой системе,
- PS - Поддержка и сопровождение.
2.4. Процессы состоят из последовательностей задач, задачи разных процессов взаимосвязаны явно указанными ссылками. CDM наиболее сильно связан с методикой "Oracle PJM" по организации управления проектом.
3) Особенности.
3.1. Степень адаптивности CDM ограничивается тремя моделями ЖЦ: "классическая" (предусмотрены все работы/задачи и этапы), "быстрая разработка" (Fast Track), еще более сильно ориентированная на использование инструментов моделирования и программирования Oracle, "облегченный подход", рекомендуемый в случае малых проектов и возможности быстро прототипировать приложения.
Методика не предусматривает: включение дополнительной задачи, которой нет в CDM, и ее привязку к остальным; дополнительное удаление задачи (и порождаемых ею документов), не предусмотренное одной из трех моделей ЖЦ; изменение последовательности выполнения задач по сравнению с предложенной, тем более - по ходу процесса проектирования.
3.2. Все модели ЖЦ АС и ПП являются по сути каскадными; даже "облегченный подход", несмотря на понятную итерационность выполнения действий по прототипированию, сохраняет общий последовательный и детерминированный порядок выполнения задач.
3.3. Степень обязательности: методика необязательна, но может считаться фирменным стандартом; при формальном применении степень обязательности полностью соответствует ограничениям возможностей адаптации.
3.4. Прикладная система рассматривается в основном как программно-техническая система - например, моменты организации выполнения вполне возможных оргструктурных преобразований, реально всегда происходящих при переходе к новой АС (вовсе не имеется в виду BPR!), и соответствующего обеспечения отсутствуют в этой методике. Другой фактической ориентацией методики является ее (исторически понятная) направленность на создание Информационной Системы с Базами Данных в достаточно традиционном понимании.
Международный стандарт ISO/IEC 12207: 1995-08-01
1) Первая редакция ISO12207 подготовлена в 1995 году объединенным техническим комитетом ISO/IEC JTC1"Информационные технологии, подкомитет SC7, проектирование программного обеспечения".
По определению, ISO12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные (любые!) виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.
Очень важное ЗАМЕЧАНИЕ СТАНДАРТА: процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми во время ЖЦ АС. (Отсюда понятна целесообразность совместного использования стандартов на АС и на ПО.)
ОПРЕДЕЛЕНИЕ СТАНДАРТА: система - это объединение одного или более процессов, аппаратных средств, программного обеспечения, оборудования и людей для обеспечения возможности удовлетворения определенных потребностей или целей.
В отличие от Oracle CDM стандарт ISO12207 равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны - из одной организации.
2) Общая структура.
2.1. Процессы ЖЦ. По сравнению с CDM стандарт ISO состоит из гораздо более крупных обобщенных процессов: "приобретение", "поставка", "разработка" и т. п. Грубо говоря, один такой процесс сравним со всеми процессами CDM вместе взятыми.
Каждый процесс разделен на набор действий, каждое действие - на набор задач. Очень важное отличие ISO: каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.). См. далее о "динамичности" стандарта.
2.1.1. Описаны 5 основных процессов ЖЦ ПО:
1. Процесс приобретения. Определяет действия предприятия-покупателя, которое приобретает АС, программный продукт или сервис ПО.
2. Процесс поставки. Определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или сервисом ПО.
3. Процесс разработки. Определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт.
4. Процесс функционирования. Определяет действия предприятия-оператора, которое обеспечивает обслуживание системы (а не только ПО) в процессе ее функционирования в интересах пользователей. В отличие от действий, которые определяются разработчиком в инструкциях по эксплуатации (эта деятельность разработчика предусмотрена во всех трех рассматриваемых стандартах), определяются действия оператора по консультированию пользователей, получению обратной связи и др., которые он планирует сам и берет на себя соответствующе обязанности.
5. Процесс сопровождения. Определяет действия персонала сопровождения, который обеспечивает сопровождение программного продукта, что представляет собой управление модификациями программного продукта, поддержку его текущего состояния и функциональной пригодности, включает в себя инсталляцию и удаление программного изделия на вычислительной системе.
2.1.2. Описаны 8 вспомогательных процессов, которые поддерживают реализацию другого процесса, будучи неотъемлемой частью всего ЖЦ программного изделия, и обеспечивают должное качество проекта ПО. Вспомогательные процессы это процессы - решения проблем, документирования, управления конфигурацией, гарантирования качества, последний из которых использует результаты остальных процессов группы обеспечения качества, в которую входят: Процесс верификации, Процесс аттестации, Процесс совместной оценки, Процесс аудита.
2.1.3. Описаны 4 организационных процесса: Процесс управления, Процесс создания инфраструктуры, Процесс усовершенствования, Процесс обучения.
К ним примыкает особый Процесс адаптации, который определяет основные действия, необходимые для адаптации стандарта к условиям конкретного проекта.
Под процессом усовершенствования здесь понимается не усовершенствование АС или ПО, а улучшение самих процессов приобретения, разработки, гарантирования качества и т. п., реально осуществляемых в организации.
2.2. Каких - либо этапов, фаз, стадий не предусмотрено, что дает описываемую ниже степень адаптивности.
3) Особенности.
3.1. "Динамический" характер стандарта определяется способом определения последовательности выполнения процессов и задач, при котором один процесс при необходимости вызывает другой или его часть.
Примеры:
- выполнение Процесса приобретения в части анализа и фиксации требований к системе или ПО может вызывать исполнение соответствующих задач Процесса разработки;
- в Процессе поставки поставщик должен управлять субподрядчиками согласно Процессу приобретения и выполнять верификацию и аттестацию по соответствующим процессам;
- сопровождение может требовать развития системы и ПО, что выполняется по Процессу разработки.
Такой характер позволяет реализовывать любую модель ЖЦ.
ОПРЕДЕЛЕНИЕ СТАНДАРТА: Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.
3.2. Степень адаптивности: максимальная. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации является процессом исключения процессов, видов деятельности и задач, не применимых в конкретном проекте.
ЗАМЕЧАНИЕ СТАНДАРТА: Добавление уникальных или специфических процессов, действий и задач должно быть оговорено в контракте между сторонами. Контракт понимается в широком смысле: от юридически оформленного контракта до неформального соглашения, соглашение может быть определено и единственной стороной как задача, поставленная самому себе.
3.3. Стандарт принципиально не содержит конкретные методы действий, тем более - заготовки решений или документации. Он описывает архитектуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить услуги и задачи, включенные в процессы, не предназначен для предписывания имени, формата или точного содержимого получаемой документации. Решения такого типа принимаются использующим стандарт.
Конкретность пользы стандарта в том, что он содержит наборы задач, характеристик качества, критериев оценки и др., дающие всесторонний охват проектных ситуаций. Например, при выполнении анализа требований к системе предусматривается, что:
- рассматривается область применения системы для определения требований системы;
- спецификация требований системы должна описывать: функции и возможности системы, бизнес, организационные требования и требования пользователя, безопасность, защищенность, человеческие факторы, эргономику, связи, операции и требования сопровождения; проектные ограничения и квалификационные требования;
- квалификация требований системы должна быть документирована.
Далее, при выполнении анализа требований к ПО предусмотрено 11 классов характеристик качества, которые используются позже при гарантировании качества.
При этом разработчик должен установить и документировать как требования к программному обеспечению:
а) функциональные и возможные спецификации, включая исполнение, физические характеристики и условия среды эксплуатации, при которых единица программного обеспечения должна быть выполнена;
б) внешние связи (интерфейсы) с единицей программного обеспечения;
в) требования квалификации;
г) спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и вероятностью травмы персонала;
д) спецификации защищенности, включая спецификации, связанные с компрометированием точности информации;
е) человеческие факторы спецификаций по инженерной психологии (эргономике), включая связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями на персонал и областями, нуждающимися в концентрированном человеческом внимании, которые являются чувствительными к ошибкам человека и обучению;
ж) определение данных и требований базы данных;
з) установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации);
и) документация пользователя;
к) работа пользователя и требования выполнения;
л) требования сервиса пользователя.
(Интересно и важно, что эти и аналогичные характеристики хорошо корреспондируются с характеристиками АС, предусматриваемыми в ГОСТ34 по видам обеспечения системы.)
ОПРЕДЕЛЕНИЕ СТАНДАРТА: Требование квалификации - набор критериев или условий (квалификационные требования), которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт как подчиняющийся (удовлетворяющий условиям) его спецификациям и готовый для использования в целевой окружающей среде.
Стандарт не предписывает конкретную модель ЖЦ или метод разработки ПО, но определяет, что стороны-участники использования стандарта ответственны за выбор модели ЖЦ для проекта ПО, за адаптацию процессов и задач стандарта к этой модели, за выбор и применение методов разработки ПО, за выполнение действий и задач, подходящих для проекта ПО.
3.4. Гарантирование качества разными процессами выполняется с разной предусмотренной степенью организационной независимости контролирующей деятельности вплоть до обязательных требований к полной независимости проверяющего персонала от какой-либо прямой ответственности за проверяемые объекты.
В отличие от CDM, контроли этого вида предусмотрены на самых ранних шагах разработки, начиная с анализа системных требований посредством их проверок на соответствие потребностям приобретения.
3.5. Степень обязательности: после решения организации о применении ISO12207 в качестве условия торговых отношений является ее ответственность за указание минимального набора требуемых процессов и задач, которые составляют согласованность с этим стандартом.
3.6. Стандарт содержит предельно мало описаний, направленных на проектирование БД. Это можно считать оправданным, так как разные системы и разные прикладные комплексы ПО могут не только использовать весьма специфические типы БД**), но и не использовать БД вовсе.
Стандарты комплекса ГОСТ34
1) ГОСТ34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Мотивы и получившиеся результаты описаны ниже в "Особенностях" ГОСТ34. Объектами стандартизации являются АС различных (любых!) видов и все виды их компонентов, а не только ПО и БД.
Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично ISO12207 предусмотрено, что заказчик может разрабатывать АС для себя сам (если создаст для этого специализированное подразделение). Однако формулировки ГОСТ34 не ориентированы на столь явное и, в известном смысле, симметричное отражение действий обеих сторон, как ISO12207. Поскольку ГОСТ34 в основном уделяет внимание содержанию проектных документов, распределение действий между сторонами обычно делается отталкиваясь от этого содержания.
2) Общая структура.
2.1) Из всех существующих и не реализованных групп документов будем основываться только на Группе 0 "Общие положения" и Группе 6 "Создание, функционирование и развитие АС". Наиболее популярными можно считать стандарты ГОСТ 34.601-90 (Стадии создания АС), ГОСТ 34.602-89 (ТЗ на создание АС) и методические указания РД 50-34.698-90 (Требования к содержанию документов). Стандарты предусматривают стадии и этапы выполнения работ по созданию АС, но не предусматривают сквозных процессов в явном виде.
2.2) Для общего случая разработки АС стадии и этапы ГОСТ34 приведены в таблице:
| 1. ФТ - Формирование требований к АС. | 1.1. Обследование объекта и обоснование необходимости
создания АС; 1.2. Формирование требований пользователя к АС; 1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания); |
| 2. РК - Разработка концепции АС. | 2.1. Изучение объекта; 2.2. Проведение необходимых научно-исследовательских работ; 2.3. Разработка вариантов концепции АС, удовлетворяющей требованиям пользователя 2.4. Оформление отчета о выполненной работе; |
| 3. ТЗ - Техническое создание АС. | 3.1. Разработка и утверждение технического задания на задание. |
| 4. ЭП - Эскизный проект. | 4.1. Разработка предварительных проектных решений по
системе и ее частям; 4.2. Разработка документации на АС и ее части. |
| 5. ТП - Технический проект. | 5.1. Разработка проектных решений по системе и ее частям;
5.2. Разработка документации на АС и ее части; 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и/или технических требований (технических заданий) на их разработку; 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации. |
| 6. РД - Рабочая документация. | 6.1. Разработка рабочей документации на систему и ее
части; 6.2. Разработка или адаптация программ. |
| 7. ВД - Ввод в действие. | 7.1. Подготовка объекта автоматизации к вводу АС в действие;
7.2. Подготовка персонала; 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями); 7.4. Строительно-монтажные работы; 7.5. Пуско-наладочные работы; 7.6. Проведение предварительных испытаний; 7.7. Проведение опытной эксплуатации; 7.8. Проведение приемочных испытаний. |
| 8. Сп - Сопровождение АС. | 8.1. Выполнение работ в соответствии с гарантийными обязательствами;
8.2. Послегарантийное обслуживание. |
2.3) Описано содержание документов, разрабатываемых на каждом этапе. Это определяет потенциальные возможности выделения на содержательном уровне сквозных работ, выполняемых параллельно или последовательно (то есть по сути - процессов), и составляющих их задач. Такой прием может использоваться при построении профиля стандартов ЖЦ проекта, включающего согласованные подмножества стандартов ГОСТ34 и ISO12207.
3) Особенности.
3.1) Главный мотив: разрешить проблему "вавилонской башни". В 80-х годах сложилось положение, при котором в различных отраслях и областях деятельности использовалась плохо согласованная или несогласованная НТД - "нормативно-техническая документация". Это затрудняло интеграцию систем, обеспечение их эффективного совместного функционирования. Действовали следующие комплексы и системы стандартов, устанавливающие требования к различным видам АС:
- единая система стандартов автоматизированных систем управления (24-я система) для АСУ, ОАСУ, АСУП, АСУТП и др. организационно-экономических систем;
- комплекс стандартов системы 23501, распространявшихся на САПР - системы автоматизированного проектирования;
- четвертая группа 14-й системы стандартов, распространяющаяся на АС технологической подготовки производства.
Практика применения стандартов на ОАСУ, АСУП, АСУТП, САПР, АСТПП показала, что в них применяется по существу (но не по строгим определениям) единая система понятий, есть много общих объектов стандартизации, однако требования стандартов не согласованы между собой, имеются различия по составу и содержанию работ, различия по обозначению, составу, содержанию и оформлению документов и пр.
Конечно, эта ситуация отчасти отражала и естественное многообразие условий разработки АС, целей разработчиков, применяемых подходов и методик.
В этих условиях можно было провести анализ такого многообразия и далее поступить, например, одним из двух во многом противоположных способов:
1. Выработать одну обобщенную понятийную и терминологическую систему, общую схему разработки, общий набор документов с их содержанием и определить их как обязательные для всех АС;
2. Определить также одну общую понятийную и терминологическую систему, обобщенный комплекс системных требований, набор критериев качества, но предоставить максимальную свободу в выборе схемы разработки, состава документов и других аспектов, наложив только минимум обязательных требований, которые позволяли бы:
- определять уровень качества результата;
- выбирать те конкретные методики (с их моделями ЖЦ, набором документов и др.), которые наиболее подходят к условиям разработки и соответствуют используемым Информационным Технологиям;
- работать, таким образом, с минимальными ограничениями эффективных действий проектировщика АС.
Разработчики комплекса стандартов 34 выбрали способ, близкий к первому из указанных выше, то есть пошли по пути, более близкому к схемам конкретных методик, чем к стандартам типа ISO12207. Тем не менее, благодаря общности понятийной базы стандарты остаются применимыми в весьма широком диапазоне случаев.
3.2) Степень адаптивности формально определяется возможностями:
- опускать стадию эскизного проектирования и объединять стадии "Технический проект" и "Рабочая документация";
- опускать этапы, объединять и опускать большинство документов и их разделов;
- вводить дополнительные документы, разделы документов и работы;
- динамически создавая т. н. ЧТЗ - частные технические задания - достаточно гибко формировать ЖЦ АС; как правило, этот прием используется на уровне крупных единиц (подсистем, комплексов), ради которых считается оправданным создавать ЧТЗ, однако нет никаких существенных оснований сильно ограничивать этот способ управления ЖЦ.
Стадии и этапы, выполняемые организациями - участниками работ по созданию АС, устанавливаются в договорах и техническом задании, что близко к подходу ISO.
3.3) Несмотря на сказанное выше, стадии и этапы на практике ориентируют разработчиков на каскадную схему ЖЦ или близкую к ней.
3.4) Введение единой, достаточно качественно определенной терминологии (см. материалы Группы 0 ГОСТ34), наличие достаточно разумной классификации работ, документов, видов обеспечения и др. безусловно полезно. ГОСТ34 способствует более полной и качественной стыковке действительно разных систем, что особенно важно в условиях, когда разрабатывается все больше сложных комплексных АС, например, типа CAD-CAM, которые включают в свой состав АСУТП, АСУП, САПР-конструктора, САПР-технолога, АСНИ и др. системы.
3.5) Определено несколько важных положений, отражающих особенности АС как объекта стандартизации, например: "в общем случае АС состоит из программно-технических (ПТК), программно-методических (ПМК) комплексов и отдельных компонентов организационного, технического, программного и информационного обеспечений". Разделение понятий ПТК и АС закрепляло принцип, по которому АС есть не "ИС с БД", но:
- "организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т. д.) или их сочетаниях" (по РД 50-680-88), что особенно актуально в аспектах бизнес-реинжиниринга;
- "система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций" (по ГОСТ 34.003-90).
Эти определения указывают на то, что АС - это, в первую очередь, персонал, принимающий решения и выполняющий другие управляющие действия, поддержанный организационно-техническими средствами.
Замечание: Эти определения и определение системы в ISO12207 вполне совместимы для их совместного использования.
3.6) Гарантирование качества определяется в ТЗ - техническом задании на АС - и производится на любых последующих этапах и с любой степенью независимости экспертизы. В каскадной траектории ЖЦ эти экспертизы располагаются несколько позже, чем в ISO12207. Тем не менее, имеются очень большие потенциальные возможности, которые часто слабо эксплуатируются на практике.
3.7) Степень обязательности: прежняя полная обязательность отсутствует, материалы ГОСТ34 по сути стали методической поддержкой, причем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и проведению испытаний АС. При этом польза ГОСТ34 может многократно возрасти в случае их более гибкого использования при формировании профиля ЖЦ АС.
3.8) Ключевым документом взаимодействия сторон является ТЗ - техническое задание на создание АС. ТЗ является основным исходным документом для создания АС и его приемки, ТЗ определяет важнейшие точки взаимодействия заказчика и разработчика. При этом ТЗ разрабатывает организация-разработчик (по ГОСТ 34.602-89), но формально выдает ТЗ разработчику заказчик (по РД 50-680-88).
Соотнесение процессов ISO12207 и соответствующих компонентов ГОСТ34 и CDM
Соотнесение произведено на верхнем структурном уровне. Даже на таком уровне оно не отражает совпадений в формальном смысле, так как один материал содержит только процессы и не содержит явных этапов, а другой явно содержит только стадии и этапы (работы соответствуют документам и не связаны явно в процессы).
Более того, соотнесение и должно делаться в условных соответствиях, так как:
- ГОСТ34 и CDM в первую очередь ориентированы на действия по созданию и поддержке систем, а ISO12207 - на приобретение и эксплуатацию систем, а разработка является процессом, логически вытекающим из приобретения;
- и главное: ISO12207 изначально предусматривает конкретные применения своих положений после построения профиля для конкретного проекта; таким образом, очень часто некоторый элемент конкретной методики или стандарта может или должен только условно соотноситься с элементами исходных положений ISO12207 и наоборот. Таким образом, конкретное сотнесение элементов должно делаться в процессе адаптации стандартов к проекту и выработки профиля ЖЦ.
Тем не менее, и в этих условиях соотнесение приносит пользу. Оно придает большую ясность выводам и рекомендациям, формулируемым в разделе ИТОГИ.
Основные процессы
В таблице 2 в первом столбце указаны стадии и этапы ГОСТ 34.601-90, как материала, направленного на формирование ЖЦ системы в целом. Во втором столбце указаны процессы ISO12207, в третьем - процессы CDM. В четвертом столбце примечания показывают возможную трактовку соотнесения, возникающую при традиционной (на взгляд автора) трактовке организации ЖЦ АС, близкой к ИС организационно-экономического типа.
| ГОСТ 34.601-90; "э.X.Y" - этап Y стадии X | ISO/IEC12207: 1995-08-01 | Oracle CDM; | Примечание |
| э.5.3 ТП, э.7.3 ВД. | 1) Процесс приобретения разработчиком | нет | в ГОСТ это приобретение планируется |
| нет | 2) Процесс поставки | нет | CDM содержит процесс CV, |
| Все этапы ГОСТ34.601 кроме 8. Сп, а именно: 1. ФТ, 2. РК, 3. ТЗ, 4. ЭП, 5. ТП,6. РД, 7. ВД. | 3) Процесс разработки. Определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт (в контексте создания системы). | RD, ES, TA, DB, MD, (DO), TE, (TR), TS. | аналог есть в ГОСТ (э.7.5 ВД и ранее), в ISO аналога нет в явном виде. Процессы DO TR из CDM указаны в скобках, так как они отражены и в других стандартах ГОСТ34 и процессах ISO12207. |
| нет | 4) Процесс эксплуатации | нет | По ISO организация-оператор разрабатывает план и гарантирует соответствие плану |
| 8. Сп., развитие АС - по пункту.1.3 ГОСТ 34.601. | 5) Процесс сопровождения | PS | ISO предполагает развитие как элемент сопровождения, вызывающий новый процесс разработки, в CDM в этом смысле полномасштабное развитие не предусмотрено |
ИТОГИ
1. Ни один из рассмотренных материалов не является полным, не описывает все виды действий и задач, реально требующиеся в конкретных проектах АС и ПО. Выходя за рамки приведенной выше таблицы, можно предположить, что эта ситуация является объективно неизбежной для любых достаточно конкретных стандартов и фирменных методик.
Так, CDM предусматривает существенно меньший набор действий по гарантированию качества, развитию системы и ПО, функционированию системы, определению действий пользователя и др. Вместе с тем, CDM явно вводит принципиально важный в реальных проектах смены поколений АС процесс CV - "конвертирование данных", который не выделен в ISO12207 и слишком косвенно отражен в ГОСТ 34.601-90. Кроме того, CDM вводит процесс проектирования баз данных в трактовке, близкой к классической.
2. Однако наличие в практике использования значительного числа конкретных методик, ориентированных к тому же на различные инструменты и терминологические "школы", заново воспроизводит, и, может быть, в еще более острой форме проблему "вавилонской башни", для решения которой создавался ГОСТ34.
3. В то же время ISO12207 имеет набор процессов, действий и задач, охватывающий наиболее широкий спектр возможных ситуаций при максимальной адаптируемости.
Он показывает пример того, как должен строиться хорошо организованный стандарт, содержащий минимум органичений (принцип "нет одинаковых проектов"). При этом детальные определения процессов, форм документов и т. п. целесообразно выносить в различные функциональные стандарты, ведомственные нормативные документы или фирменные методики, которые могут быть использованы или не использованы в конкретном проекте.
4. По этой причине центральным стандартом, положения которого берутся за начальный "стержневой" набор положений в процессе построения профиля стандартов ЖЦ для конкретного проекта, полезно рассматривать именно ISO12207. Этот "стержень" может задавать модель ЖЦ ПО и АС, принципиальную схему гарантирования качества, модель управления проектом. Другие стандарты или материалы полезно включать в профиль теми положениями, требованиями и методами, которые:
а) согласовывают модель ЖЦ с требованиями стандартов на АС в целом и ее компоненты, отличные от ПО,
б) определяют конкретные способы анализа или программирования, формы проектных документов и инструменты проектирования, применяемые в каждом конкретном процессе или задаче.
5. Фирменные методики целесообразно представлять в том стиле, в котором методика рассматривается как библиотека методов, где каждая отдельная работа описывается как достаточно отдельный метод, отдельный функциональный блок, который может быть использован, модифицирован, заменен на схожий или не использован в проекте, а последовательность (или параллельность) применения этих блоков в проекте определяется в стиле ISO12207. Включение или не включение отдельных задач фирменной методики в профиль ЖЦ проекта является адаптацией этой методики к проекту.
Так, например, задачи и формы CDM могут быть полезны в процессе такого создания конкретного профиля стандартов проекта разработки Информационной Системы под заказ (особенно при использовании инструментов Oracle).
6. Стандарты комплекса ГОСТ34 могут с пользой применяться при создании профиля стандартов на АС, если их использовать в открытом и динамичном стиле, определяемом ISO12207. ГОСТ34 полно и фундаментально определяет: систему как объект создания или развития; аналитические и, при необходимости, исследовательские работы, направленные на разработку обоснованной концепции АС; виды т. н. "обеспечений" системы, которые хорошо гармонизируются с требованиями ISO12207 к системе и ПО, и т. п. Материалы ГОСТ34 почти так же, как и ISO12207, а, может быть, еще более четко определяют, что АС - это в первую очередь люди, которые выполняют свои функции с помощью Информационных Технологий.
ГОСТ34 благодаря своей комплексной ориентации на систему помогает избегать ситуаций, в которых разработчики разных профессий (например, финансовые аналитики, специалисты по оргструктурам и человеческому фактору, проектировщики баз данных и др.) говорят на столь разных языках, что страдает итоговая цельность проекта, глубина комплексной проработки.
7. Применять ГОСТ34 в указанном выше стиле - выбор и задача обеих сторон, участвующих в Жизненном Цикле АС. Действительное получение пользы от такого применения и, более того, успешное сочетание в одном профиле стандартов ГОСТ34 (и, например, задач и документов CDM) - вещь, зависящая от квалификации, опыта и здравого смысла участвующих сторон.
8. Использование ISO12207:
- фиксирует необходимость организационного отделения действий по непосредственному "изготовлению" ПО и АС от нескольких видов работ, связанных с гарантированием качества (независимые верификация и аттестация, аудит как экспертиза хода проекта и его результатов);
- фактически определяет конкретные позиции ответственности руководителей организаций и проектов за установление соответствующей профессиональной культуры, технологии и требований к качеству разработок (и, как и в моделях SEI CMM, к уровню совершенства процесса разработки), или же за согласие с отказом от целенаправленной деятельности такого рода (например, отказ от регулярного применения процессов текущей верификации или аттестации, т. е. от гарантирования качества).
9. Работы по построению профилей ЖЦ проекта на основе ISO12207 описанным выше образом могут сделать проектные работы более дорогими. Стоимость работ возрастает также при доброкачественном проведении действий по гарантированию качества. На первый взгляд, это создает ненужные тяготы и риски в проектировании АС, которое и так относится к деятельности повышенного риска. Однако заказчикам и разработчикам полезно учитывать следующее:
Разработчик получает методику и нормативную базу для полного и понятного заказчику описания всех своих работ по тестированию ПО и АС, организации параллельной работы новой и старой систем, других работ по "внедрению". Разработчик может с большим успехом избегать гибельных для бюджета проекта ситуаций, когда он вынужден бесплатно производить эти объемные работы, поскольку иначе заказчик не принимает работу и не платит денег. Разработчик может получать более качественный продукт и укреплять свой авторитет на рынке.
Заказчик получает методику и нормативную базу для действительного гарантирования качества того продукта, который он получит за свои или госбюджетные деньги. Заказчик сможет обосновать свои затраты перед финансирующим или проверяющим органом (например, советом директоров или собранием акционеров), избежать распространенных ситуаций, когда либо через год-два нужно снова запрашивать деньги на смену неудачной системы или программного комплекса, либо оставаться с непригодным продуктом, "молчать сжав зубы" (выражение одного из неудачливых заказчиков).
| Вспомогательные и организационные процессы | |||
| ГОСТ 34.601-90; другие документы ГОСТ34 | ISO/IEC12207: 1995 | Oracle CDM; смежные методики | Примечание |
| Вспомогательные процессы | |||
| ГОСТ 34.201, ГОСТ 34.602, РД50-682. | Процесс документирования | DO | |
| нет | Процесс управления конфигурацией ПО | нет | |
| ГОСТ34.601: э. 6.1 РП, стадия 7 ВД, | Процесс обеспечения качества. TE, Определяет действия для объективной гарантии, что программные продукты и процессы соответствуют определенным требованиям к ним; определены также в процессах "верификация", "аттестация", "совместная оценка", "аудит". | ISO12207 PS.050, Oracle PJM.QM. | использует также возможность применять дополнительно другие международные стандарты, например ISO9001 |
| приложения: к ГОСТ34.602, аналогично. | Процесс решения проблем. Определяет процесс анализа и устранения РД50-34698 и проблем, какова бы ни была их природа или источник, на протяжении разработки, эксплуатации, сопровождения или других процессов. | PS.050, Oracle PJM | Сведения в ГОСТ - минимальные и неполные с точки зрения процессов управления проектами. PS.050 - задача соответствующего процесса Oracle CDM. |
| Организационные процессы | |||
| в приложениях | 1) Процесс управления. | Oracle PJM | ГОСТ - недостаточно. |
| нет | 2) Процесс создания инфраструктуры. Определяет действия для создания структуры, на которую будут опираться процессы ЖЦ. | Oracle PJM.RM | ГОСТ: может быть предусмотрен в ТЗ (например, как ЧТЗ) |
| нет | 3) Процесс усовершенствования процессов ЖЦ | нет | ISO12207 предусматривает связь с ISO 9000 |
| ГОСТ34.601, стадия 7. ВД | 4) Процесс обучения | TR | |
Заключительные замечания
Безусловно полезно "позадачное" соотнесение стандартов и методик, что создало основу для доклада, упомянутого в начале статьи. Такое соотнесение, например для задач процесса "Разработка" ISO12207, дает конструктивную основу для планирования реальных проектов, но выходит за рамки данной публикации.
Автор благодарит Е. Н. Филинова и А. В. Бойченко за содержательную беседу о построении профилей стандартов в проектах сложных систем, А. В. Шкотина - за обсуждение вопросов применения Oracle CDM, а также всех заинтересованых специалистов, участвовавших в весьма полезных дискуссиях по упоминающимся в статье вопросам.
Автор с удовлетворением отмечает, что предложенный им в 1995 г. (см. цикл, начатый в [4а]) подход к современному системному проектированию, условно названный "Н.С.П.", с входящей в него адаптивной организацией проектирования, очень хорошо соответсвуют как открытости, адаптивности схемы организации работ в Жизненном Цикле по ISO12207, так и снятию барьеров между разработкой ПО, разработкой АС в целом и бизнес-реинжинирингом.
Стандарт ISO12207 (как и подход Н.С.П. в более широком плане) показывает новые пути в мир проектов открытых систем. Этот пути могут быть непривычными, но их время пришло.
Литература
- CDM - метод разработки информационных систем фирмы Oracle//Oracle Magazine / Russian Edition #2, 1997.
- Липаев В. В., Филинов Е. Н. Формирование и применение профилей открытых информационных систем//Открытые системы #5, 1997.
- Oracle CDM Method Handbook. Oracle corp. 1996.
- Зиндер Е. З. Новое Системное Проектирование: информационные технологии и бизнес-реинжиниринг//Часть 1 - СУБД #4, 1995 //. Часть 2 - бизнес-реинжиниринг //СУБД #1, 1996 //. Часть 3 - методы Нового Системного Проектирования//СУБД #2, 1996.
- Зиндер Е. З. Проектирование баз данных: новые требования, новые подходы //СУБД. #3. 1996.
*) Автор делает такой вывод, допуская, что читать о стандартах может быть скучнее, чем писать о них.
**) Например такие, которые, к сожалению, еще не стали активно рассматриваться в журнале "СУБД"! (Прим. авт.)
Евгений Захарович Зиндер, LVS/Price Waterhouse Business Solutions, тел. (095) 258-4100, E-mail: ez@lvs.msk.su, Evgeny_Zinder@europe.notes.pw.com