2_Технологии создания программного обеспечения. Современные технологии создания программного обеспечения. Обзор А. М. Вендров, содержание
 Скачать 396 Kb.
|
|
Технология создания ПО - упорядоченная совокупность взаимосвязанных технологических процессов в рамках ЖЦ ПО. Технологический процесс - совокупность взаимосвязанных технологических операций. Технологическая операция - основная единица работы, выполняемая определенной ролью, которая: подразумевает четко определенную ответственность роли; дает четко определенный результат (набор рабочих продуктов), базирующийся на определенных исходных данных (другом наборе рабочих продуктов); представляет собой единицу работы с жестко определенными границами, которые устанавливаются при планировании проекта. Рабочий продукт - информационная или материальная сущность, которая создается, модифицируется или используется в некоторой технологической операции (модель, документ, код, тест и т.п.). Рабочий продукт определяет область ответственности роли и является объектом управления конфигурацией. Роль - определение поведения и обязанностей отдельного лица или группы лиц в среде организации-разработчика ПО, осуществляющих деятельность в рамках некоторого технологического процесса и ответственных за определенные рабочие продукты. Руководство - практическое руководство по выполнению одной или совокупности технологических операций. Руководства включают методические материалы, инструкции, нормативы, стандарты и критерии оценки качества рабочих продуктов. Инструментальное средство (CASE-средство) - программное средство, обеспечивающее автоматизированную поддержку деятельности, выполняемой в рамках технологических операций. Основным требованием, предъявляемым к современным ТС ПО, является их соответствие стандартам и нормативным документам, связанным с процессами ЖЦ ПО и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и др.). Согласно этим нормативам, ТС ПО должна поддерживать следующие процессы: управление требованиями; анализ и проектирование ПО; разработка ПО; эксплуатация; сопровождение; документирование; управление конфигурацией и изменениями; тестирование; управление проектом. Полнота поддержки процессов ЖЦ ПО должна поддерживаться комплексом инструментальных средств (CASE-средств). Соответствие стандартам означает также, в частности, использование общепринятых, стандартных нотаций и соглашений. Для того чтобы проект мог выполняться разными коллективами разработчиков, необходимо использование стандартных методов моделирования и стандартных нотаций, которые должны быть оформлены в виде нормативов до начала процесса проектирования. Несоблюдение проектных стандартов ставит разработчиков в зависимость от фирмы-производителя данного средства, делает затруднительным формальный контроль корректности проектных решений и снижает возможности привлечения дополнительных коллективов разработчиков, смены исполнителей и отчуждения проекта, поскольку число специалистов, знакомых с данным методом (нотацией), может быть ограниченным. Другим важным требованием является адаптируемость к условиям применения, которая достигается за счет поставки технологии в электронном виде вместе с CASE-средствами и библиотеками процессов, шаблонов, методов, моделей и других компонентов, предназначенных для построения ПО того класса систем, на который ориентирована технология. Электронные технологии должны включать средства, обеспечивающие их адаптацию и развитие по результатам выполнения конкретных проектов. Процесс адаптации заключается в удалении ненужных процессов и действий ЖЦ ПО, в изменении неподходящих или в добавлении собственных процессов и действий, а также методик, стандартов и руководств. Внедрение ТС ПО в организации При внедрении ТС ПО следует руководствоваться рекомендациями, приведенными в стандартах [27], [28], [29] (их краткий перевод приведен в [4]). Эти рекомендации достаточно актуальны и ценны, поскольку отражают опыт, накопленный многими зарубежными пользователями и разработчиками ТС ПО в течение длительного периода их существования. Термин "внедрение" используется в широком смысле и включает все действия - от оценки первоначальных потребностей до полномасштабного использования ТС ПО в различных подразделениях организации. Процесс внедрения ТС ПО состоит из следующих этапов: Определение потребностей в ТС ПО, характеристик объекта внедрения и проектов создания ПО. Определение требований, предъявляемых к ТС ПО (анализ характеристик объекта внедрения и проектов, обоснование требований к ТС ПО, определение приоритетов требований). Оценка вариантов ТС ПО. Предварительная экспертная оценка заключается в анализе доступных ТС ПО на предмет соответствия требованиям, неудовлетворительные варианты (с точки зрения реализации наиболее приоритетных требований) отвергаются, формируется список претендентов. При детализированной оценке для каждой ТС ПО-претендента формируется ее детальное описание. Источники информации для описания - техническая документация поставщика, доступные данные о реальных внедрениях, результаты выполнения пилотных проектов. Выбор ТС ПО. Производится сравнительный анализ технологий и окончательный выбор ТС ПО с помощью экспертной оценки. Адаптация ТС ПО к условиям применения. Производится формирование конкретной рабочей конфигурации ТС ПО, адаптированной к условиям объекта внедрения. В процессе внедрения ТС ПО собирается статистика и оценивается эффективность ее внедрения с точки зрения ряда критериев (минимум трудоемкости сопровождения ПО, минимум затрат на сопровождение ПО и др.). При изменении условий объекта внедрения и по результатам анализа эффективности внедрения ТС ПО принимается решение: а) о внесении изменений в рабочую конфигурацию ТС ПО; б) о переходе на новую ТС ПО. В случае перехода повторяются пп. 3)-4)-5). Оценка и выбор ТС ПО Цель процесса оценки - определение функциональности и качества ТС ПО для последующего выбора. Оценка выполняется в соответствии с конкретными критериями, ее результаты включают как объективные, так и субъективные данные по каждой ТС ПО. Процессы оценки и выбора тесно взаимосвязаны. По результатам оценки цели выбора и/или критерии выбора и их веса могут потребовать модификации. В таких случаях может понадобиться повторная оценка. Когда анализируются окончательные результаты оценки и к ним применяются критерии выбора, может быть рекомендовано приобретение технологии. Альтернативой может быть отсутствие адекватных технологий, в этом случае рекомендуется разработать новую технологию, модифицировать существующую или отказаться от внедрения. Процесс выбора включает в себя следующие действия: формулировка задач выбора, включая цели, предположения и ограничения; выполнение всех необходимых действий по выбору, включая определение и ранжирование критериев, определение технологий-кандидатов, сбор необходимых данных и применение ранжированных критериев к результатам оценки для определения средств с наилучшими показателями; выполнение необходимого количества итераций с тем, чтобы выбрать (или отвергнуть) технологии, имеющие сходные показатели. Типичный процесс оценки и/или выбора может использовать набор критериев различных типов. Каждый критерий должен быть выбран и адаптирован экспертом с учетом особенностей конкретного процесса. Исходные данные для оценки и выбора - набор параметров (технико-экономических характеристик) ТС ПО: Функциональные характеристики, ориентированные на процессы жизненного цикла ПО (управление проектом, управление требованиями, управление конфигурацией и изменениями, анализ и проектирование ПО и др.). Функциональные характеристики применения (среда функционирования, совместимость с другими ТС ПО, соответствие технологическим стандартам). Характеристики качества (надежность, удобство использования, эффективность, сопровождаемость, переносимость). Общие характеристики (затраты на технологию, лицензионная политика, оценочный эффект от внедрения ТС ПО, инфрастуктура, требуемая для внедрения ТС ПО, доступность и качество обучения, сертификация поставщика, поддержка поставщика). На основе данного набора параметров анализируются и классифицируются существующие ТС ПО. Общий набор критериев, применяемых для оценки ТС ПО, приведен в Таб. 1. В результате выполненной оценки может оказаться, что ни одна доступная технология не удовлетворяет в нужной мере всем критериям и не покрывает все потребности проекта. В этом случае может применяться набор средств, позволяющий построить на их базе единую технологическую среду. Таблица 1. Критерии, применяемые для оценки ТС ПО
Выполнение пилотного проекта Перед полномасштабным внедрением выбранной ТС ПО в организации выполняется пилотный проект, целью которого является экспериментальная проверка правильности решений, принятых на предыдущих этапах, и подготовка к внедрению. Пилотный проект позволяет получить важную информацию, необходимую для оценки ТС ПО и его поддержки со стороны поставщика после того, как средство установлено. Важной функцией пилотного проекта является принятие решения относительно приобретения или отказа от использования ТС ПО. Провал пилотного проекта позволяет избежать более значительных и дорогостоящих неудач в дальнейшем, поскольку пилотный проект обычно требует приобретения относительно небольшого количества лицензий и обучения узкого круга специалистов. Пилотный проект должен обладать следующими характеристиками: Типичность предметной области. Чтобы облегчить окончательное определение области применения ТС ПО, предметная область пилотного проекта должна быть типичной для обычной деятельности организации. Пилотный проект должен помочь определить любую дополнительную технологию, обучение или поддержку, которые необходимы для перехода от пилотного проекта к широкомасштабному использованию ТС ПО. В рамках этих ограничений пилотный проект должен иметь небольшой, но значимый размер. Масштабируемость. Результаты, полученные в пилотном проекте, должны показать масштабируемость ТС ПО. Цель - получить четкое представление о масштабах проектов, для которых данная ТС ПО применима. Представительность. Пилотный проект не должен быть необычным или уникальным для организации. ТС ПО должна использоваться для решения задач, относящихся к предметной области, хорошо понимаемой всей организацией. Критичность. Пилотный проект должен иметь существенную значимость, чтобы оказаться в центре внимания, но не должен быть критичным для успешной деятельности организации в целом. Авторитетность. Группа специалистов, участвующих в проекте, должна обладать высоким авторитетом, при этом результаты проекта будут всерьез восприняты остальными сотрудниками организации. Готовность проектной группы. Проектная группа должна обладать готовностью к нововведениям, технической зрелостью и приемлемым уровнем опыта и знаний в данной ТС ПО и предметной области. С другой стороны, группа должна отражать в миниатюре характеристики организации в целом. В процессе оценки пилотного проекта организация должна определить свою позицию по следующим трем вопросам: Целесообразно ли внедрять ТС ПО? Какие конкретные особенности пилотного проекта привели к его успеху (или неудаче)? Какие проекты или подразделения в организации могли бы получить выгоду от использования ТС ПО? Возможным решением должно быть одно из следующих: Внедрить ТС ПО. В этом случае рекомендуемый масштаб внедрения должен быть определен в терминах структурных подразделений и предметной области. Выполнить дополнительный пилотный проект. Такой вариант должен рассматриваться только в том случае, если остались конкретные неразрешенные вопросы относительно внедрения ТС ПО в организации. Отказаться от ТС ПО. В этом случае причины отказа от конкретной ТС ПО должны быть определены в терминах потребностей организации или критериев, которые остались неудовлетворенными. Перед тем как продолжить деятельность по внедрению ТС ПО, потребности организации должны быть пересмотрены на предмет своей обоснованности. Отказаться от использования ТС ПО вообще. Пилотный проект может показать, что организация либо не готова к внедрению ТС ПО, либо автоматизация данного аспекта процесса создания и сопровождения ПО не дает никакого эффекта для организации. Практическое внедрение ТС ПО Процесс перехода к практическому использованию ТС ПО начинается с разработки и последующей реализации плана перехода. Этот план может отражать поэтапный подход к переходу - от тщательно выбранного пилотного проекта до проектов с существенно возросшим разнообразием характеристик. План перехода должен охватывать: информацию относительно целей, критериев оценки, графика и возможных рисков, связанных с реализацией плана; информацию относительно приобретения, установки и настройки ТС ПО; информацию относительно интеграции с существующими средствами, включая как интеграцию средств друг с другом, так и их интеграцию в процессы разработки и эксплуатации ПО, существующие в организации; ожидаемые потребности в обучении и ресурсы, используемые в течение и после завершения процесса перехода; определение стандартных процедур использования ТС ПО. План перехода должен определять начальную практику применения и процедуры использования средств. Реальное применение любой ТС ПО в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта (это особенно актуально при коллективной разработке ПО большим количеством групп специалистов). К таким стандартам относятся следующие: руководства по моделированию и проектированию; соглашения по присвоению имен; процедуры контроля качества и процессов приемки, включая расписание экспертиз и используемые методологии; процедуры резервного копирования, защиты мастер-копий и конфигурирования базы данных проекта; процедуры интеграции с существующими средствами и базами данных; процедуры совместного использования данных и контроля целостности БД; стандарты и процедуры обеспечения секретности; стандарты документирования. стандарт проектирования; стандарт оформления проектной документации; стандарт интерфейса пользователя. Для успешного внедрения ТС ПО в организации существенной является последовательность в ее применении. Поскольку большинство систем разрабатываются коллективно, необходимо определить характер будущего использования ТС ПО как отдельными разработчиками, так и группами. Использование стандартных процедур позволит обеспечить плавный переход между отдельными стадиями ЖЦ ПО. Результатом данного этапа является внедрение ТС ПО в повседневную практику организации. Кроме того, поддержка ТС ПО включается в план текущей поддержки ПО в данной организации. Примеры ТС ПО различных компаний-поставщиков Технология 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): стратегия (определение требований); анализ (формулирование детальных требований к системе); проектирование (преобразование требований в детальные спецификации системы); реализация (написание и тестирование приложений); внедрение (установка новой прикладной системы, подготовка к началу эксплуатации); эксплуатация. Рисунок 2. Этапы и процессы CDM  На этапе стратегии определяются цели создания системы, приоритеты и ограничения, разрабатывается системная архитектура и составляется план разработки. На этапе анализа строятся модель информационных потребностей (диаграмма "сущность-связь"), диаграмма функциональной иерархии (на основе функциональной декомпозиции системы), матрица перекрестных ссылок и диаграмма потоков данных. На этапе проектирования разрабатывается подробная архитектура системы, проектируются схема реляционной БД и программные модули, устанавливаются перекрестные ссылки между компонентами системы для анализа их взаимного влияния и контроля за изменениями. На этапе реализации создается БД, строятся прикладные системы, производится их тестирование, проверка качества и соответствия требованиям пользователей. Создается системная документация, материалы для обучения и руководства пользователей. На этапах внедрения и эксплуатации анализируются производительность и целостность системы, выполняется поддержка и, при необходимости, модификация системы. Процессы 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 выделяются два основных подхода к разработке: |