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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модели ЖЦ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лекция 2. МОДЕЛИ И ИХ РОЛЬ В СОЗДАНИИ СИСТЕМ. ОБЪЕКТНАЯ МОДЕЛЬ

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

• структурной сложностью (большим количеством элементов и сложными взаимосвязями между ними);

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

• необходимостью интеграции существующих и вновь разрабатываемых приложений;

• функционированием в неоднородной среде на нескольких аппаратных платформах;

• высокими требованиями к надежности и производительности.

Сложность управления порождается следующими причинами:

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

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

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

• значительная временная протяженность проекта.

Подход к решению этой проблемы основан на принципе «разделяй и властвуй» (divide et impera). Сложная программная система должна быть разделена на небольшие подсистемы, каждую из которых можно разрабатывать независимо (в какой-то степени) от других. Декомпозиция является главным способом преодоления сложности разработки ПО. Принципы декомпозиции:

• количество связей между подсистемами должно быть минимальным («низкая связанность» или «слабое зацепление» – Low Coupling);

• степень взаимодействия внутри каждой подсистемы должна быть максимальной («сильная связность» или «высокая прочность» – High Cohesion).

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

• каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);

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

Следование этим правилам увеличивает понятность и модифицируемость создаваемого ПО.

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

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

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