Выбор технологии проектирования ИС. Критерии выбора

РЕФЕРАТ

Тема:  “Выбор технологии проектирования ИС. Критерии выбора”

Выполнила:

Студентка гр.2/4-И(б)

Одувалова Марта

Проверила:

Камскова И.Д.

Нижний Новгород  2010 г.

Содержание

Требования, предъявляемые к технологии создания программного обеспечения…………………………………………………………………….….3

Оценка и выбор технологии создания программного обеспечения………...…5 Технологии MSF, RUP, XP, ICONIX…………………………………………...11

Модель Microsoft Solution Framework (MSF)……………………………..……13

Rational Unified Process (RUP)…………………………………………………..16

Extreme Programming (XP)………………………………………………………27

Процесс моделирования  ICONIX………………………………………………30

Требования, предъявляемые к технологии создания программного обеспечения

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

1. управление требованиями;

2. анализ и проектирование ПО;

3. разработка ПО;

4. эксплуатация;

5. сопровождение;

6. документирование;

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

8. тестирование;

9. управление проектом.

Полнота поддержки процессов ЖЦ ПО должна поддерживаться комплексом инструментальных средств (CASE-средств).

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

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

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

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

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

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

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

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

Процесс выбора включает в себя следующие действия:

- формулировка задач выбора, включая цели, предположения и ограничения;

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

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

Типичный процесс оценки и/или выбора может использовать набор критериев различных типов. Каждый критерий должен быть выбран и адаптирован экспертом с учетом особенностей конкретного процесса.

Исходные данные для оценки и выбора - набор параметров (технико-экономических характеристик) технологии создания программного обеспечения:

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

2.                              Функциональные характеристики применения (среда функционирования, совместимость с другими ТС ПО, соответствие технологическим стандартам).

3.                              Характеристики качества (надежность, удобство использования, эффективность, сопровождаемость, переносимость).

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

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

Критерии, применяемые для оценки ТС ПО

                  Минимум трудоемкости создания ПО Количество человеко_месяцев, затрачиваемых на создание ПО с использованием ТС ПО

                  Максимум продуктивности Объем работы (измеряемый в количестве строк кода или функциональных точек), приходящийся на единицу трудоемкости (человеко_месяц) при использовании данной ТС ПО

                  Максимум качества создаваемого ПО Количество дефектов в рабочих продуктах при использовании данной ТС ПО

                  Возврат инвестиций (Доход от использования ПО _ Затраты на создание и сопровождение ПО) / (Затраты на создание и сопровождение ПО)

                  Минимум затрат на сопровождение ПО Отношение стоимости сопровождения ПО при использовании данной ТС ПО к совокупным затратам на информационные ТС ПО в организации

                  Минимум времени внедрения ТС ПО Временной интервал от начала внедрения ТС ПО до выхода на безубыточный уровень (начало возврата инвестиций в ТС ПО)

                  Минимум затрат на внедрение ТС ПО Суммарная стоимость приобретения, обучения и сопровождения ТС ПО

                  Минимальный срок окупаемости Временной интервал от начала внедрения ТС ПО до полной окупаемости затрат на внедрение ТС ПО затрат на ее внедрение

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

Выполнение пилотного проекта

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

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

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

Пилотный проект должен обладать следующими характеристиками:

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

- Масштабируемость. Результаты, полученные в пилотном проекте, должны показать масштабируемость технологии создания программного обеспечения. Цель - получить четкое представление о масштабах проектов, для которых данная ТС ПО применима.

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

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

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

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

В процессе оценки пилотного проекта организация должна определить свою позицию по следующим трем вопросам:

- Целесообразно ли внедрять ТС ПО?

- Какие конкретные особенности пилотного проекта привели к его успеху (или неудаче)?

- Какие проекты или подразделения в организации могли бы получить выгоду от использования технологии создания программного обеспечения?

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

-  Внедрить ТС ПО. В этом случае рекомендуемый масштаб внедрения должен быть определен в терминах структурных подразделений и предметной области.

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

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

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

Технологии MSF, RUP, XP, ICONIX

В настоящее время широкое применение получают так называемые промышленные технологии создания программного продукта. Эти технологии были разработаны фирмами, накопившими большой опыт создания ПО. Такие технологии, как правило, поддерживаются набором CASE-средств, охватывают все этапы жизненного цикла продукта и успешно применяются для решения практических задач. На сегодняшний день практически все ведущие компании – разработчики технологий и программных продуктов (IBM, Oracle, Borland, Computer Associates и др.) располагают развитыми технологиями создания ПО, которые создавались как собственными силами, так и за счет приобретения продуктов и технологий, созданных небольшими специализированными компаниями.

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

                        Microsoft Solution Framework (MSF) – разработка фирмы Microsoft, предназначенная для решения широкого круга задач. Технология масштабируема, т.е. настраиваема на решение задач любой сложности коллективом любой численности.

                        Rational Unified Process (RUP) – разработка фирмы Rational, долгое время успешно занимавшейся созданием CASE-средств, применяемых на различных этапах жизненного цикла продукта от анализа до тестирования и документирования. Аналогично MSF, RUP универсальна, масштабируема и настраиваема на применение в конкретных условиях.