Жизненный цикл ПО

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

Классический жизненный цикл (каскадная или водопадная модель)

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

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

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

Кодирование состоит в переводе результатов проектирования в текст на языке программирования. Кодирование состоит в переводе результатов проектирования в текст на языке программирования. Тестирование выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта. Тестирование выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

Сопровождение это внесение изменений в эксплуатируемое ПО. Цели изменений: исправление ошибок; исправление ошибок; адаптация к изменениям внешней для ПО среды; адаптация к изменениям внешней для ПО среды; усовершенствование ПО по требованиям заказчика. усовершенствование ПО по требованиям заказчика.

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

Инкрементная модель

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

Инкрементная модель Экстремальное программирование ХР Быстрая разработка приложений RAD

RAD-модель обеспечивает экстремально короткий цикл разработки (достигается за счет использования компонентно- ориентированного конструирования); обеспечивает экстремально короткий цикл разработки (достигается за счет использования компонентно- ориентированного конструирования); создает полностью функциональную систему за очень короткое время (60-90 дней); создает полностью функциональную систему за очень короткое время (60-90 дней); ориентирован на разработку информационных систем ориентирован на разработку информационных систем

Этапы разработки RAD-модели бизнес-моделирование; бизнес-моделирование; моделирование данных; моделирование данных; моделирование обработки; моделирование обработки; генерация приложения; генерация приложения; тестирование и объединение. тестирование и объединение.

Модель быстрой разработки приложений

Ограничения RAD-модели 1. Для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп). 2. RAD применима только для таких приложений, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной. 3. RAD не применима в условиях высоких технических рисков (то есть при использовании новой технологии).

Экстремальное программирование ХР Основная идея ХР устранить высокую стоимость изменения, характерную для приложений с использованием объектов, паттернов и реляционных баз данных ______________________________________ Паттерн является решением типичной проблемы в определенном контексте

Базовые действия в ХР-цикле в ХР-цикле Кодирование Тестирование Выслушивание заказчика Проектирование

Идеальный ХР-процесс

Экстремумы в экстремальном программировании Практика здравого смысла ХР-экстремумХР-реализация Проверки кода Код проверяется все время Парное программирование Код проверяется все время Парное программирование Тестирование модуля, функциональное тестирование Проектирование Проектирование является частью ежедневной деятельности каждого разработчика Реорганизация (refactoring) Простота Для системы выбирается простейшее проектное решение, поддерживающее ее текущую функциональность Самая простая вещь, которая могла бы работать

Практика здравого смысла ХР-экстремумХР-реализация Архитектура Каждый постоянно работает над уточнением архитектуры Метафора Тестирование интеграции Интегрируется и тестируется несколько раз в день Непрерывная интеграция Короткие итерации Итерации являются предельно короткими, продолжаются секунды, минуты, часы, а не недели, месяцы или годы Игра планирования

Базисные методы ХР 1. Игра планирования (Planning game) быстрое определение области действия следующей реализации путем объединения деловых приоритетов и технических оценок. Заказчик формирует область действия, приоритетность и сроки с точки зрения бизнеса, а разработчики оценивают и прослеживают продвижение (прогресс). 2. Частая смена версий (Small releases) быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле. 3. Метафора (Metaphor) вся разработка проводится на основе простой, общедоступной истории о том, как работает вся система.

Базисные методы ХР 4. Простое проектирование (Simple design) проектирование выполняется настолько просто, насколько это возможно в данный момент. 5. Тестирование (Testing) непрерывное написание тестов для модулей, которые должны выполняться безупречно; заказчики пишут тесты для демонстрации законченности функций. «Тестируй, а затем кодируй» означает, что входным критерием для написания кода является «отказавший» тестовый вариант. 6. Реорганизация (Refactoring) система деструктурируется, но ее поведение не изменяется; цель устранить дублирование, улучшить взаимодействие, упростить систему или добавить в нее гибкость.

Базисные методы ХР 7. Парное программирование (Pair programming) весь код пишется двумя программистами, работающими на одном компьютере. 8. Коллективное владение кодом (Collective ownership) любой разработчик может улучшать любой код системы в любое время. 9. Непрерывная интеграция (Continuous integration) система интегрируется и строится много раз в день, по мере завершения каждой задачи. Непрерывное регрессионное тестирование, то есть повторение предыдущих тестов, гарантирует, что изменения требований не приведут к регрессу функциональности.

Базисные методы ХР часовая неделя (40-hour week) как правило, работают не более 40 часов в неделю. Нельзя удваивать рабочую неделю за счет сверхурочных работ. 11. Локальный заказчик (On-site customer) в группе все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы разработчиков. 12. Стандарты кодирования (Coding standards) должны выдерживаться правила, обеспечивающие одинаковое представление программного кода во всех частях программной системы.

Эволюционная стратегия конструирования Спиральная модель Спиральная модель Компонентно-ориентированная модель Компонентно-ориентированная модель

Спиральная модель 1 начальный сбор требований и планирование проекта; 2 та же работа, но на основе рекомендаций заказчика; 3 анализ риска на основе начальных требований; 4 анализ риска на основе реакции заказчика; 5 переход к комплексной системе; 6 начальный макет системы; 7 следующий уровень макета; 8 сконструированная система; 9 оценивание заказчиком

Модель определяет четыре действия, представляемые четырьмя квадрантами спирали. 1. Планирование определение целей, вариантов и ограничений. 2. Анализ риска анализ вариантов и распознавание/выбор риска. 3. Конструирование разработка продукта следующего уровня. 4. Оценивание оценка заказчиком текущих результатов конструирования.

Компонентно-ориентированная модель

Достоинства компонентно-ориентированной модели: 1) уменьшает на 30% время разработки программного продукта; 2) уменьшает стоимость программной разработки до 70%; 3) увеличивает в полтора раза производительность разработки.

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