Конспект по курсу. Объектно ориентированный анализ и проектирование (1133667), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

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

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

Процесс разработки включает в себя следующие действия: подготовительную работу; анализ требований к ПО; проектирование архитектуры ПО; детальное проектирование ПО; кодирование ПО; тестирование ПО; интеграцию ПО; установку ПО; приемку ПО. Действующие лица: разработчик, заказчик. Задачи разработки: выбор модели ЖЦ ПО и согласование с заказчиком; определение требований к ПО (функциональных и нефункциональных); определение состава компонентов ПО и создание документации по каждому компоненту; моделирование и спецификация компонент ПО; планирование интеграции компонент; создание исходных текстов компонент; поиск и исправление ошибок в исходных текстах и документации; сборка ПО; развертывание ПО; оценка результатов.

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

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

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

Процесс управления конфигурацией в себя следующие действия: подготовительную работу; создание базы знаний о ПО (конфигурации); контроль за конфигурацией; учет состояния конфигурации; оценку конфигурации; управление выпуском и поставку ПО. Конфигурация ПО – это совокупность сведений о его функциональных и физических характеристиках на всех стадиях ЖЦ ПО. Основная задача управления конфигурацией: организация, систематический учет и контроль внесения изменений в ПО.

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

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

Процесс аттестации состоит в определении полноты соответствия разработанного ПО требованиям заказчика. Основная задача аттестации – оценка достоверности тестирования ПО. Как правило, для аттестации привлекают независимых экспертов.

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

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

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

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

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

Процесс усовершенствования предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО. Основная задача усовершенствования – повышение производительности труда.

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

Процессы ЖЦ ПО взаимосвязаны.

Динамику, т. е. развитие ЖЦ во времени определяет модель жизненного цикла.

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

В любой модели ЖЦ рассматривается как совокупность стадий ЖЦ.

Стадия ЖЦ – это часть ЖЦ ограниченная временными рамками, по завершении которой достигается определенный важный результат в соответствии с требованиями для данной стадии ЖЦ.

Модели ЖЦ:

• каскадная (водопадная);

• эволюционная;

• основанная на формальных преобразованиях;

• итерационные (пошаговая и спиральная).

С хема каскадной модели ЖЦ:

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

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

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

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

На этапе тестирования производится собственно тестирование, а также отладка и оценка качества ПО.

Ввод в действие – это развертывание ПО на целевой вычислительной системе, обучение пользователей и т.п.

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

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

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

Неизбежные возвраты на предыдущие стадии в каскадной модели

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

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

Схема модели ЖЦ, основанной на формальных преобразованиях

Особенности итерационных моделей:

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

• действия не привязаны намертво к определенным стадиям ЖЦ, а выполняются по мере необходимости, повторяются, до тех пор, пока не будет получен нужный результат;

• с каждой пройденной итерацией ПО наращивается, в него интегрируются новые разработанные компоненты.

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

Схема пошаговой итерационной модели ЖЦ

Схема спиральной модели ЖЦ

Особенности спиральной модели:

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

• решение о начале новой итерации принимается на основе результатов предыдущей;

• досрочное прекращение проекта в случае обнаружения его нецелесообразности;

• в конце «миникаскад», завершающийся выпуском финальной версии ПС.

Достоинства итерационных моделей:

• полный учет требований заказчика, большее его участие в проекте;

• равномерная нагрузка на группу разработчиков;

• раннее обнаружение проблем и их разрешение по мере возникновения;

• уменьшение рисков на каждой итерации.

Недостатки итерационных моделей: сложность планирования; плохая документированность создаваемого ПО.

Проблемой современной программной инженерии являются «тяжелые» процессы. Характеристики «тяжелого» процесса:

1. необходимость документировать каждое действие разработчиков;

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

3. отсутствие гибкости;

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

Противоположностью «тяжелого» процесса является «легковесный» процесс – основа быстрой или гибкой разработки ПО (agile software development). Гибкая разработка ориентируется на эффективную коммуникацию между разработчиками, высокую квалификацию разработчиков и другие факторы, позволяющие сократить расходы на «бюрократию».

Манифест гибкой разработки:

• Индивидуумы и взаимодействия ценятся выше процессов и инструментов.

• Работающее ПО ценится выше всеобъемлющей документации.

• Сотрудничество с заказчиками ценится выше согласования условий договора.

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

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

Принципы быстрой разработки:

1. Д
   иалог «лицом к лицу» – самый эффективный способ обмена информацией.

2. Избыточная «тяжесть» технологии (дополнительные рабочие продукты, планы, диаграммы, документы) стоит дорого.

3. Более многочисленные команды требуют более «тяжелых» технологий.

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

1. Большая «тяжесть» процесса подходит для проектов с большей критичностью.

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

1. потеря удобства;

2. потеря важных данных и/или рабочего времени;

3. потеря невозместимых средств, дорогостоящего оборудования;

4. потеря человеческой жизни.

Примеры: I) данные выданы не в виде диаграммы, а в виде таблицы; II) «синий экран смерти»; III) взрыв ракеты «Ариан-5» 4 июня 1996 года (500 000 000$) и массовое отключение электричества в Северной Америке 14 августа 2003 г. (4-10 Гига$); IV) неправильная работа медицинской рентгеновской установки Therac-25 (3 смерти).

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

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

1. Дисциплина, умение и понимание противостоят процессу, формальности и документированию.

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

1. Потеря эффективности в некритических видах деятельности вполне допустима.

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

Характеристики

Список файлов лекций