Методика по разработке прикладных ис custom development method разработана компанией

Основное значение темы

О видах стандартов

Непростые вопросы и различия интересов

Рассматриваемые стандарты

Методика Oracle CDM

Международный стандарт ISO/IEC 12207:
1995-08-01

Стандарты комплекса ГОСТ34

Соотнесение процессов ISO12207 и
соответствующих компонентов ГОСТ34 и CDM

Основные процессы

Итоги

Заключительные замечания

Литература

«Наибольшая свобода — это зависимость только от законов», — провозглашает «АиФ» в московском метро. Не сообщается, любые ли законы годятся? И всегда ли хорошо быть таким свободным? А без знания этого даже согласие подчиняться стандартам разработки систем становится рискованным решением.

Основное значение темы

Растут размеры и сложность автоматизированных систем (АС). Радикально изменились и продолжают меняться требования не только к основным функциям и сервисным возможностям систем, но и к динамике их изменения. Много писалось о том, что классические способы разработки и обеспечения качества АС перестали действовать. Разработка и развитие промышленных систем среднего, а часто и небольшого размера классическими методами не приводит к уровню качества, адекватному реальным требованиям (обзор истоков этой проблемы при разработке АС имеется в ,[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

Источник

2004 г.

Современные технологии создания программного обеспечения. Обзор

А.М. Вендров ,
Jet Info Online , # 4/2004

Примеры ТС ПО различных компаний-поставщиков

Технология Rational Unified Process (IBM Rational Software)

На сегодняшний день практически все ведущие компании — разработчики технологий и программных продуктов (IBM, Oracle, Borland, Computer Associates и др.) располагают развитыми технологиями создания ПО, которые создавались как собственными силами, так и за счет приобретения продуктов и технологий, созданных небольшими специализированными компаниями. Выбор в качестве примера четырех перечисленных компаний объясняется их ведущими позициями на мировом рынке ТС ПО [24], [25], присутствием на российском рынке и ограниченным объемом настоящего обзора.

Одна из наиболее совершенных технологий, претендующих на роль мирового корпоративного стандарта — Rational Unified Process (RUP) [13]. RUP представляет собой программный продукт, разработанный компанией Rational Software (www.rational.com), которая в настоящее время входит в состав IBM.

RUP в значительной степени соответствует стандартам и нормативным документам, связанным с процессами ЖЦ ПО и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и др.). Ее основными принципами являются:

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

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

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

На Рис. 1 показано общее представление RUP в двух измерениях. Горизонтальное измерение представляет время, отражает динамические аспекты процессов и оперирует такими понятиями, как стадии, итерации и контрольные точки. Вертикальное измерение отражает статические аспекты процессов и оперирует такими понятиями, как виды деятельности (технологические операции), рабочие продукты, исполнители и дисциплины (технологические процессы).

Рисунок 1. Общее представление RUP

Согласно RUP, ЖЦ ПО разбивается на отдельные циклы, в каждом из которых создается новое поколение продукта. Каждый цикл, в свою очередь, разбивается на четыре последовательные стадии:

начальная стадия (inception);
стадия разработки (elaboration);
стадия конструирования (construction);
стадия ввода в действие (transition).

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

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

Результатами начальной стадии являются:

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

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

Результатами стадии разработки являются:

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

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

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

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

Стадия разработки занимает около пятой части общей продолжительности проекта. Основными признаками завершения стадии разработки являются два события:

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

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

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

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

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

Назначением стадии ввода в действие является передача готового продукта в распоряжение пользователей. Данная стадия включает:

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

Статический аспект RUP представлен четырьмя основными элементами:

роли;
виды деятельности;
рабочие продукты;
дисциплины.

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

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

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

В рамках RUP определены шесть основных дисциплин:

построение бизнес-моделей;
определение требований;
анализ и проектирование;
реализация;
тестирование;
oразвертывание;

и три вспомогательных:

управление конфигурацией и изменениями;
управление проектом;
создание инфраструктуры.

RUP как продукт входит в состав комплекса Rational Suite, причем каждая из перечисленных выше дисциплин поддерживается определенным инструментальным средством комплекса. Физическая реализация RUP представляет собой Web-сайт, включающий следующие компоненты:

описание всех элементов динамического и статического аспекта RUP;
навигатор по всем элементам RUP, глоссарий и средство быстрого обучения технологии;
руководства для всех участников проектной команды, охватывающие весь жизненный цикл ПО. Руководства представлены в двух видах: для осмысления процесса на верхнем уровне, и в виде подробных наставлений по повседневной деятельности;
наставления по использованию инструментальных средств, входящих в состав Rational Suite;
примеры и шаблоны проектных решений для Rational Rose;
шаблоны проектной документации для SoDa;
шаблоны в формате Microsoft Word, предназначенные для поддержки документации по всем процессам и действиям жизненного цикла ПО;
планы в формате Microsoft Project, отражающие итерационный характер разработки ПО.

Адаптация RUP к потребностям конкретной организации или проекта обеспечивается с помощью Rational Process Workbench (RPW) — специального набора инструментов и шаблонов для настройки и публикации Web-сайтов на основе RUP. RPW поддерживает три основные функции моделирования технологических процессов:

определение процесса;
описание процесса;
представление процесса.

Библиотека элементов процесса содержит текстовую информацию о каждом элементе в модели процесса, все текстовые страницы RUP, а RPW — необходимые шаблоны для создания новых страниц описания. RPW генерирует описание процессов, включающее текст и графику, в виде Web-сайта, соединяя модели процессов и библиотеку описаний в единое целое.

RUP опирается на интегрированный комплекс инструментальных средств Rational Suite. Он существует в следующих вариантах:

Rational Suite AnalystStudio — предназначен для определения и управления полным набором требований к разрабатываемой системе;
Rational Suite DevelopmentStudio — предназначен для проектирования и реализации ПО;
Rational Suite TestStudio — представляет собой набор продуктов, предназначенных для автоматического тестирования приложений;
Rational Suite Enterprise — обеспечивает поддержку полного жизненного цикла ПО и предназначен как для менеджеров проекта, так и отдельных разработчиков, выполняющих несколько функциональных ролей в команде разработчиков.

В состав Rational Suite, кроме самой технологии RUP как продукта, входят следующие компоненты:

o Rational Rose — средство визуального моделирования (анализа и проектирования), использующее язык UML;
o Rational XDE — средство анализа и проектирования, интегрируемое с платформами MS Visual Studio .NET и IBM WebSphere Studio Application Developer;
o Rational Requisite Pro — средство управления требованиями, предназначенное для организации совместной работы группы разработчиков. Оно позволяет команде разработчиков создавать, структурировать, устанавливать приоритеты, отслеживать, контролировать изменения требований, возникающих на любом этапе разработки компонентов приложения;
Rational Rapid Developer — средство быстрой разработки приложений на платформе Java 2 Enterprise Edition;
Rational ClearCase — средство управления конфигурацией ПО;
Rational SoDA — средство автоматической генерации проектной документации;
Rational ClearQuest — средство для управления изменениями и отслеживания дефектов в проекте на основе средств e-mail и Web;
Rational Quantify — средство количественного определения узких мест, влияющих на общую эффективность работы программы;
Rational Purify — средство для локализации трудно обнаруживаемых ошибок времени выполнения программы;
Rational PureCoverage — средство идентификации участков кода, пропущенных при тестировании;
Rational TestManager — средство планирования функционального и нагрузочного тестирования;
Rational Robot — средство записи и воспроизведения тестовых сценариев;
Rational TestFactory — средство тестирования надежности;
Rational Quality Architect — средство генерации кода для тестирования.

Одно из основных инструментальных средств комплекса Rational Rose [9] представляет собой семейство объектно-ориентированных CASE-средств и предназначено для автоматизации процессов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose реализует процесс объектно-ориентированного анализа и проектирования ПО, описанный в RUP. В основе работы Rational Rose лежит построение диаграмм и спецификаций UML, определяющих архитектуру системы, ее статические и динамические аспекты. В составе Rational Rose можно выделить шесть основных структурных компонентов: репозиторий, графический интерфейс пользователя, средства просмотра проекта (браузер), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генераторы кодов для каждого поддерживаемого языка, состав которых меняется от версии к версии.

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

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

В результате разработки проекта с помощью Rational Rose формируются следующие документы:

диаграммы UML, в совокупности представляющие собой модель разрабатываемой программной системы;
спецификации классов, объектов, атрибутов и операций;
заготовки текстов программ.

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

Инструментальное средство Rational XDE представляет собой развитие возможностей Rational Rose в части синхронизации модели и кода (исключающей необходимость прямой и обратной генерации кода). Rational XDE обеспечивает:

синхронизацию между кодом и моделью;
отображение элементов кода Java и С# в UML;
автоматическую синхронизацию с настраиваемым разрешением конфликтов;
одновременное отображение кода и модели;
постоянную синхронизацию модели UML, как части проекта Java или С#.

Технология Oracle

Методическую основу ТС ПО корпорации Oracle (www.oracle.com) составляет метод Oracle (Oracle Method) — комплекс методов, охватывающий большинство процессов ЖЦ ПО. В состав комплекса входят:

CDM (Custom Development Method) — разработка прикладного ПО;
PJM (Project Management Method) — управление проектом;
AIM (Application Implementation Method) — внедрение прикладного ПО;
BPR (Business Process Reengineering) — реинжиниринг бизнес-процессов;
OCM (Organizational Change Management) — управление изменениями, и др.

Метод CDM оформлен в виде консалтингового продукта CDM Advantage — библиотеки стандартов и руководств (включающего также PJM). Он представляет собой развитие достаточно давно созданного Oracle CASE-Method, известного по использованию CASE-средств фирмы Oracle и книгам Р. Баркера. По существу, CDM является методическим руководством по разработке прикладного ПО с использованием инструментального комплекса Oracle Developer Suite, а сам процесс проектирования и разработки тесно связан с Oracle Designer и Oracle Forms.

В соответствии с CDM ЖЦ ПО формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов (Рис. 2):

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

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

На этапе проектирования разрабатывается подробная архитектура системы, проектируются схема реляционной БД и программные модули, устанавливаются перекрестные ссылки между компонентами системы для анализа их взаимного влияния и контроля за изменениями.

На этапе реализации создается БД, строятся прикладные системы, производится их тестирование, проверка качества и соответствия требованиям пользователей. Создается системная документация, материалы для обучения и руководства пользователей.

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

Процессы CDM:

определение бизнес-требований, или постановка задачи (Business Requirements Definition);
исследование существующих систем (Existing Systems Examination). Выполнение этого процесса должно обеспечить понимание состояния существующего технического и программного обеспечения для планирования необходимых изменений;
определение технической архитектуры (Technical Architecture);
проектирование и реализация базы данных (Database Design and Build). Процесс предусматривает проектирование и реализацию реляционной базы данных, включая создание индексов и других объектов БД;
проектирование и реализация модулей (Module Design and Build). Этот процесс является основным в проекте. Он включает непосредственное проектирование приложения и создание кода прикладной программы;
конвертирование данных (Data Conversion). Цель этого процесса — преобразовывать, перенести и проверить согласованность и непротиворечивость данных, оставшихся в наследство от «старой» системы и необходимых для работы в новой системе;
документирование (Documentation);
тестирование (Testing);
обучение (Training);
внедрение, или переход к новой системе (Transition). Этот процесс включает решение задач установки, ввода новой системы в эксплуатацию, прекращения эксплуатации старых систем;
поддержка и сопровождение (Post-System Support).

Процессы состоят из последовательностей взаимосвязанных задач.

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

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

В соответствии с этими факторами в CDM выделяются два основных подхода к разработке:

Классический подход (Classic). Этапы данного подхода представлены на Рис. 2. Классический подход применяется для наиболее сложных и масштабных проектов, он предусматривает последовательный и детерминированный порядок выполнения задач. Для таких проектов характерно большое количество реализуемых бизнес-правил, распределенная архитектура, критичность приложения. Применение классического подхода также рекомендуется при нехватке опыта у разработчиков, неподготовленности пользователей, нечетко определенной задаче. Продолжительность таких проектов от 8 до 36 месяцев.
Подход быстрой разработки (Fast Track). Данный подход, в отличие от каскадного классического, является итерационным и основан на методе DSDM (Dynamic Systems Development Method). В этом подходе четыре этапа — стратегия, моделирование требований, проектирование и генерация системы и внедрение в эксплуатацию. Подход используется для реализации небольших и средних проектов с несложной архитектурой системы, гибкими сроками и четкой постановкой задач. Продолжительность проекта от 4 до 16 месяцев.

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

Управление проектом и предоставление отчетности (Control and Reporting). Этот процесс содержит задачи, в результате решения которых определяются границы проекта и подход к разработке, происходит управление изменениями и контролируется возможный риск;
Управление работой (Work Management). Процесс содержит задачи, помогающие контролировать работы, выполняемые в проекте;
Управление ресурсами (Resource Management). Здесь решаются задачи, связанные с обеспечением каждого этапа исполнителями;
Управление качеством (Quality Management). Процесс управления качеством гарантирует, что в проект отвечает требованиям пользователя в течение всего процесса разработки;
Управление конфигурацией (Configuration Management).

Цикл решения задач PJM состоит из отдельных этапов. Количество этапов зависит от выбранного подхода к разработке. Задачи PJM можно распределить внутри каждого процесса по трем группам — задачи планирования, управления и завершения, и по уровням — отнести задачу на уровень проекта или на уровень отдельного этапа.

По аналогии с CDM, в PJM предусмотрено широкое использование шаблонов разрабатываемых документов.

Комплекс Oracle Developer Suite содержит набор интегрированных средств разработки для быстрого создания приложений. Он включает средства моделирования, программирования на Java, разработки компонентов, бизнес-анализа и составления отчетов. Все эти средства используют общие ресурсы, что позволяет совместно работать над одним проектом группе разработчиков. Oracle Developer Suite интегрирован с Oracle Database и Oracle Application Server, образуя единую платформу для создания и установки приложений.

Oracle Developer Suite поддерживает стандарты J2EE: Enterprise Java Beans (EJB), сервлеты и страницы JavaServer (JSP). В него также входят анализатор XML, процессор XSLT, процессор схем XML и XSQL-сервлет для разработки XML-приложений.

В Oracle Developer Suite встроена поддержка языка UML для разработки приложений на основе моделей. Модели хранятся в общем репозитории Oracle, который предназначен для поддержки больших коллективов разработчиков.

Oracle Developer Suite включает в себя:

Oracle Designer — средство моделирования и генерации приложений;
Oracle Forms — средство быстрой разработки приложений;
Oracle Reports — визуальное средство разработки отчетов;
Oracle JDeveloper — средство визуального программирования на языке Java;
Oracle Discoverer — средство для разработки аналитических приложений;
Oracle Warehouse Builder — система для построения хранилищ данных;
Oracle Portal — средство разработки информационного портала организации.

CASE-средство Oracle Designer является интегрированным средством, обеспечивающим в совокупности со средствами разработки приложений поддержку ЖЦ ПО.

Oracle Designer представляет собой семейство методов и поддерживающих их программных продуктов. Базовый метод Oracle Designer (CDM) — структурный метод проектирования систем, охватывающий полностью все стадии ЖЦ ПО. Версия Oracle Designer для объектно-реляционной СУБД Oracle содержит также расширение в виде средств объектного моделирования, базирующихся на стандарте UML.

Oracle Designer обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий. В состав Oracle Designer входят следующие компоненты:

Repository Administrator — средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);
Repository Object Navigator — средство доступа к репозиторию, обеспечивающее многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;
Process Modeler — средство анализа и моделирования бизнес-процессов;
Systems Modeler — набор средств построения функциональных и информационных моделей проектируемой системы, включающий средства для построения диаграмм «сущность-связь» (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);
Systems Designer — набор средств проектирования ПО, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);
Server Generator — генератор описаний объектов БД Oracle (таблиц, индексов, ключей, последовательностей и т.д.);
Forms Generator — генератор приложений для Oracle Forms. Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки;
Repository Reports — генератор стандартных отчетов, интегрированный с Oracle Reports.

Репозиторий Oracle Designer представляет собой хранилище всех проектных данных и может работать в многопользовательском режиме, обеспечивая параллельное обновление информации несколькими разработчиками. В процессе проектирования автоматически поддерживаются перекрестные ссылки между объектами словаря и могут генерироваться более 70 стандартных отчетов о моделируемой предметной области. Физическая среда хранения репозитория — база данных Oracle.

Технология Borland

Компания Borland (www.borland.com) в результате развития собственных разработок и приобретения целого ряда компаний представила интегрированный комплекс инструментальных средств, реализующих управление полным жизненным циклом приложений (Application Life Cycle Management, ALM). В соответствии с технологией Borland процесс создания ПО включает в себя пять основных этапов:

определение требований;
анализ и проектирование;
разработка;
тестирование и профилирование;
развертывание.

Выполнение всех этапов координируется процессом управления конфигурацией и изменениями.

Определение требований реализуется с помощью системы управления требованиями CaliberRM, которая стала частью семейства продуктов Borland в результате покупки компании Starbase. CaliberRM сохраняет требования в базе данных, документы с их описанием создаются с помощью встроенного механизма генерации документов MS Word на базе заданных шаблонов. Система обеспечивает экспорт данных в таблицы MS Access и импорт из MS Word. CaliberRM поддерживает различные методы визуализации зависимостей между требованиями, с помощью которых пользователь может ограничить область анализа, необходимого в случае изменения того или иного требования. Имеется модуль, который использует данные требования для оценки трудозатрат, рисков и расходов, связанных с реализацией требований.

Средство анализа и проектирования Together ControlCenter [8] разработано компанией TogetherSoft. В основе его применения лежит один из вариантов подхода «Быстрой разработки ПО» под названием Feature Driven Development (FDD) [18].

Together ControlCenter — интегрированная среда проектирования и разработки, поддерживающая визуальное моделирование на UML с последующим написанием приложений для платформ J2EE (Java) и .Net (С#, C++ и Visual Basic). Кроме базовой версии, имеется уменьшенный вариант системы для индивидуальных разработчиков и небольших групп (Together Solo), а также редакции для платформы IBM WebSphere и среды разработки Jbuilder.

В системе реализована технология LiveSource, которая обеспечивает синхронизацию между проектом приложения и изменениями — при внесении изменений в исходные тексты меняется модель программы, а при изменении модели надлежащим образом изменяется текст на языке программирования. Это исключает необходимость вручную модифицировать модель или переписывать код. Контроль версий осуществляется благодаря функциональной интеграции Together и системы StarTeam. Поддерживается также интеграция с системой управления конфигурацией Rational ClearCase.

Инструментальные средства тестирования появилась в составе комплекса Borland в результате покупки компании Optimizeit. К ним относятся Optimizeit Suite 5, Optimizeit Profiler for .NET и Optimizeit ServerTrace. Первые две системы позволяют выявить потенциальные проблемы использования аппаратных ресурсов — памяти и процессорных мощностей на платформах J2EE и .Net соответственно. Интеграция Optimizeit Suite 5 в среду разработки Jbuilder, а Optimizeit Profiler — в C#Builder и Visual Basic .Net позволяет проводить контрольные испытания приложений по мере разработки и ликвидировать узкие места производительности. Система Optimizeit ServerTrace предназначена для управления производительностью серверных J2EE-приложений с точки зрения достижения заданного уровня обслуживания и сбора контрольных данных по виртуальным Java-машинам.

Сущность концепции ALM сосредоточена в системе управления конфигурацией и изменениями: именно она объединяет основные фазы ЖЦ ПО. Такой системой является StarTeam, разработанная компанией Starbase. Она выполняет функции контроля версий, управления изменениями, отслеживания дефектов, управления требованиями (в интеграции с CaliberRM), управления потоком задач и управления проектом.

StarTeam совместима с интерфейсом Microsoft Source Code Control и интегрируется с любой системой разработки, которая поддерживает этот API. Кроме того, в системе реализованы средства интеграции со средствами разработки и моделирования Together, JBuilder, Delphi, C++Builder и C#Builder.

В технологии Borland выделяется три уровня интеграции. Функциональная (touch-point) интеграция позволяет обратиться из одной системы к функциям другой, выбрав соответствующий пункт меню. Например, интерфейс управления изменениями StarTeam непосредственно отображается в системах Together, C#Builder и Visual Studio .Net. Такая интеграция дает возможность разделять информацию между системами, но не обеспечивает единого рабочего пространства, вынуждает пользователя переключать окна и приводит к дублированию процессов управления структурой проекта. Встроенная (embedded) интеграция обеспечивает работу с одной системой непосредственно в среде другой. Например, не выходя из среды разработки Jbuilder, можно просматривать графики производительности, которые создает система Optimizeit. Самый высокий уровень интеграции — синергетический (synergistic), позволяющий сочетать функции двух различных продуктов незаметно для разработчиков. Для большинства продуктов Borland и других поставщиков синергетическая интеграция пока остается делом будущего, однако ее принципы уже начинают реализовываться.

Технология Computer Associates

Компания Computer Associates (www.ca.com) предлагает комплексы инструментальных средств поддержки различных процессов ЖЦ ПО:

AllFusion Modeling Suite — интегрированный комплекс CASE-средств [16], включающий следующие продукты:
- AllFusion Process Modeler (BPwin) — функциональное моделирование;
- AllFusion ERwin Data Modeler (ERwin) — моделирование данных;
- AllFusion Component Modeler (Paradigm Plus) — объектно-ориентированный анализ и проектирование с использованием UML и возможностью генерации кода;
- AllFusion Model Manager (Model Mart) — организация совместной работы команды разработчиков;
- AllFusion Data Model Validator (ERwin Examiner) — проверка структуры и качества моделей данных.
AllFusion Change Management Suite — комплекс средств управления конфигурацией и изменениями.
AllFusion Process Management Suite — средства управления процессами и проектами для различных типов приложений.

CASE-средства ERwin и BPwin были разработаны фирмой Logic Works, которая в 1998 году вошла в состав PLATINUM Technology, а затем Computer Associates.

BPwin — средство моделирования бизнес-процессов, реализующее метод IDEF0, а также поддерживающее диаграммы потоков данных и IDEF3. В процессе моделирования BPwin позволяет переключиться с нотации IDEF0 на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. BPwin поддерживает функционально-стоимостной анализ (ABC).

Семейство продуктов ERwin представляет собой набор средств концептуального моделирования данных, использующих метод IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (Oracle, Sybase, DB2, Microsoft SQL Server и др.) и реверсный инжиниринг существующей БД. ERwin выпускается в нескольких конфигурациях, ориентированных на наиболее распространенные средства разработки приложений.

Для управления групповой разработкой используется средство Model Mart, обеспечивающее многопользовательский доступ к моделям, созданным с помощью ERwin и BPwin. Модели хранятся на центральном сервере и доступны для всех участников группы проектирования.

Model Mart удовлетворяет ряду требований, предъявляемым к средствам управления разработкой крупных систем, а именно:

Совместное моделирование. Каждый участник проекта имеет инструмент поиска и доступа к интересующей его модели в любое время. При совместной работе используются три режима: незащищенный, защищенный и режим просмотра. В режиме просмотра запрещается любое изменение моделей. В защищенном режиме модель, с которой работает один пользователь, не может быть изменена другими пользователями. В незащищенном режиме пользователи могут работать с общими моделями в реальном масштабе времени.
Создание библиотек решений. Model Mart позволяет формировать библиотеки стандартных решений, включающие наиболее удачные фрагменты реализованных проектов, накапливать и использовать типовые модели, объединяя их при необходимости «сборки» больших систем. На основе существующих баз данных с помощью ERwin возможно восстановление моделей (реверсный инжиниринг), которые в процессе анализа пригодности их для новой системы могут объединяться с типовыми моделями из библиотек моделей.
Управление доступом. Для каждого участника проекта определяются права доступа, в соответствии с которыми, они получают возможность работать только с определенными моделями. Права доступа могут быть определены как для групп, так и для отдельных участников проекта. Роль специалистов, участвующих в различных проектах может меняться, поэтому в Model Mart можно определять и управлять правами доступа участников проекта к библиотекам, моделям и даже к специфическим областям модели.

Заключение

По прогнозам IDC [26], рынок ТС ПО, испытавший определенный кризис в 2002 году, в ближайшее пятилетие ожидает устойчивый рост в среднем на 6,3% в год. Определяющим фактором для развития этой тенденции является стремление компаний-разработчиков повысить продуктивность своей работы, сократить сроки вывода новых продуктов на рынок, контролировать расходы и быстро получать отдачу от инвестиций. Достижению этих целей способствует использование сред разработки, позволяющих снизить сложность процессов создания ПО, увеличить их эффективность, уменьшить затраты на разработку и максимально использовать потенциал новых технологий. Аналитики сходятся на том, что основное направление развития инструментальных средств — их сквозная интеграция, переход от частично интегрированных средств к интегрированным комплексам, объединяющим возможности управления требованиями, моделирования, разработки, тестирования, управления конфигурацией и изменениями и развертывания приложений. В ближайшие годы такие комплексы, помимо перечисленных возможностей будут включать в себя средства управления потоками работ и проектами. Рынок таких инструментальных средств ожидает глобальная консолидация, обещающая принести значительные выгоды разработчикам. В то же время проблема обоснованного выбора и эффективного применения ТС ПО в крупномасштабных проектах остается актуальной. Невозможно достичь удовлетворительных результатов от применения даже самых совершенных технологий, если они применяются бессистемно, разработчики не обладают необходимой квалификацией для работы с ними, и сам проект выполняется и управляется хаотически. Систематический, обоснованный подход к выбору и применению ТС ПО может сократить время и повысить качество разработки ПО, обеспечить высокую степень его независимости от конкретных разработчиков, а также снизить затраты на разработку и сопровождение ПО.

Назад Содержание Дальше

Источник

2.4. Методология фирмы Oracle — Custom Development Method (CDM)

Методика Oracle CDM по разработке прикладных ИС под заказ – конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах ИС с опорой на инструментарий фирмы Oracle.

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

Первоначально CDM предназначался для крупных и средних проектов, но его можно использовать и для небольших.

Метод CDM определяет задачи и проектные решения, которые должны включаться в полный ЖЦ любого проекта.

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

Модель методология Oracle CDM имеет два измерения (рис.2.5).

Поделитесь с Вашими друзьями:

Источник

Несмотря на настойчивые рекомендации компаний — вендоров и экспертов в области проектирования и разработки ИС, многие компании продолжают использовать каскадную модель вместо какого-либо варианта итерационной модели. Основные причины, по которым каскадная модель сохраняет свою популярность, следующие
[
2.1
]
:

Привычка — многие ИТ-специалисты получали образование в то время, когда изучалась только каскадная модель, поэтому она используется ими и в наши дни.
Иллюзия снижения рисков участников проекта (заказчика и исполнителя). Каскадная модель предполагает разработку законченных продуктов на каждом этапе: технического задания, технического проекта, программного продукта и пользовательской документации. Разработанная документация позволяет не только определить требования к продукту следующего этапа, но и определить обязанности сторон, объем работ и сроки, при этом окончательная оценка сроков и стоимости проекта производится на начальных этапах, после завершения обследования. Очевидно, что если требования к информационной системе меняются в ходе реализации проекта, а качество документов оказывается невысоким (требования неполны и/или противоречивы), то в действительности использование каскадной модели создает лишь иллюзию определенности и на деле увеличивает риски, уменьшая лишь ответственность участников проекта. При формальном подходе менеджер проекта реализует только те требования, которые содержатся в спецификации, опирается на документ, а не на реальные потребности бизнеса.
Есть два основных типа контрактов на разработку ПО. Первый тип предполагает выполнение определенного объема работ за определенную сумму в определенные сроки (fixed price). Второй тип предполагает повременную оплату работы (time work). Выбор того или иного типа контракта зависит от степени определенности задачи. Каскадная модель с определенными этапами и их результатами лучше приспособлена для заключения контракта с оплатой по результатам работы, а именно этот тип контрактов позволяет получить полную оценку стоимости проекта до его завершения. Более вероятно заключение контракта с повременной оплатой на небольшую систему, с относительно небольшим весом в структуре затрат предприятия. Разработка и внедрение интегрированной информационной системы требует существенных финансовых затрат, поэтому используются контракты с фиксированной ценой, и, следовательно, каскадная модель разработки и внедрения. Спиральная модель чаще применяется при разработке информационной системы силами собственного отдела ИТ предприятия.
Проблемы внедрения при использовании итерационной модели. В
некоторых областях спиральная модель не может применяться, поскольку невозможно использование/тестирование продукта, обладающего неполной функциональностью (например, военные разработки, атомная энергетика и т.д.). Поэтапное итерационное внедрение информационной системы для бизнеса возможно, но сопряжено с организационными сложностями (перенос данных, интеграция систем, изменение бизнес-процессов, учетной политики, обучение пользователей). Трудозатраты при поэтапном итерационном внедрении оказываются значительно выше, а управление проектом требует настоящего искусства. Предвидя указанные сложности, заказчики выбирают каскадную модель, чтобы «внедрять систему один раз».

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

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

Значительный вклад в теорию проектирования и разработки информационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning — методология организационного планирования). Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информационных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в ИТ-проектах, но и проектах по реинжинирингу бизнес-процессов, изменению организационной структуры. Важнейшие шаги процесса BSP, их последовательность (получить поддержку высшего руководства, определить процессы предприятия, определить классы данных, провести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике.

Среди наиболее известных стандартов можно выделить следующие:

ГОСТ 34.601-90 — распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла
[
2.2
]
.
ISO/IEC 12207:1995 — стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов
[
2.3
]
.
Custom Development Method (методика Oracle) по разработке прикладных информационных систем — технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий «быстрой разработки» (Fast Track) или «облегченного подхода», рекомендуемых в случае малых проектов.
Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом
не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP — это создание и сопровождение моделей на базе UML
[
2.4
]
.
Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.
Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:

Основные процессы:
- приобретение;
- поставка;
- разработка;
- эксплуатация;
- сопровождение.
Вспомогательные процессы:
- документирование;
- управление конфигурацией;
- обеспечение качества;
- разрешение проблем;
- аудит;
- аттестация;
- совместная оценка;
- верификация.
Организационные процессы:
- создание инфраструктуры;
- управление;
- обучение;
- усовершенствование.

Источник

Найдиготовую курсовую работувыполненное домашнее заданиерешённую задачуготовую лабораторную работунаписанный рефератподготовленный докладготовую ВКРготовую диссертациюготовую НИРготовый отчёт по практикеответы и шпаргалкиполные лекцииполные семинарызаполненную рабочую тетрадьподготовленную презентациюпереведённый текстнаписанное изложениенаписанное сочинениеготовую статью

73,5% бесплатных материалов

957 руб. средняя цена курсовой работы

351 руб. средняя цена домашнего задания

116 руб. средняя цена решённой задачи

157 руб. средняя цена лабораторной работы

168 руб. средняя цена реферата

167 руб. средняя цена доклада

1648 руб. средняя цена ВКР

671 руб. средняя цена диссертации

608 руб. средняя цена НИР

363 руб. средняя цена отчёта по практике

283 руб. средняя цена ответов (шпаргалок)

199 руб. средняя цена лекций

224 руб. средняя цена семинаров

289 руб. средняя цена рабочей тетради

173 руб. средняя цена презентации

67 руб. средняя цена перевода

135 руб. средняя цена изложения

146 руб. средняя цена сочинения

314 руб. средняя цена статьи

Гарантия возврата средств

Стандарты на проектирование ИС

2020-06-032021-03-09СтудИзба

· 5.2. Стандарты на проектирование ИС

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

Среди наиболее известных стандартов можно выделить следующие:

ГОСТ 34.601-90 — распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла [4].
ISO/IEC 12207:1995 — стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов [5].
Custom Development Method (методика Oracle) по разработке прикладных информационных систем — технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий «быстрой разработки» (Fast Track) или «облегченного подхода», рекомендуемых в случае малых проектов.
Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP — это создание и сопровождение моделей на базе UML [6].
Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.
Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

Свежие статьи

Популярно сейчас

Ответы на популярные вопросы

То есть уже всё готово?

Да! Наши авторы собирают и выкладывают те работы, которые сдаются в Вашем учебном заведении ежегодно и уже проверены преподавателями.

А я могу что-то выложить?

Да! У нас любой человек может выложить любую учебную работу и зарабатывать на её продажах! Но каждый учебный материал публикуется только после тщательной проверки администрацией.

А если в купленном файле ошибка?

Вернём деньги! А если быть более точными, то автору даётся немного времени на исправление, а если не исправит или выйдет время, то вернём деньги в полном объёме!

Отзывы студентов

Добавляйте материалы
и зарабатывайте!

Продажи идут автоматически

643

Средний доход
с одного платного файла

Обучение Подробнее

Источник