Ответы к экзамену (Технология программирования)

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

Недостаток: 10-ти кратное увеличение затрат на разработку.

V-модель (разработка через тестирование)

5.*УНИФИЦИРОВАННЫЙ ПРОЦЕСС РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ RUP. ОСНОВНЫЕ ФАЗЫ РАЗРАБОТКИ

RATIONAL UNIFIED PROCESS (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.

RUP использует итеративную модель разработки.

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

Быстрое реагирование на меняющиеся требования,

Обнаружение и устранение рисков на ранних стадиях проекта,

Эффективный контроль качества создаваемого продукта.

11

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

Начальная фаза (Inception)

В начале фазы:

o Формируются видение и границы проекта.

o Создается экономическое обоснование (business case).

oОпределяются основные требования, ограничения и ключевая функциональность продукта.

o Создается базовая версия модели прецедентов.

oОцениваются риски.

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

Уточнение (Elaboration)

Анализ предметной области и построение исполняемой архитектуры, в

т.ч.:

o Документирование требований (включая детальное описание для большинства прецедентов);

o Спроектированную, реализованную и оттестированную исполняемую архитектуру;

o Обновленное экономическое обоснование и более точные оценки сроков и стоимости;

o Сниженные основные риски;

спешное выполнение фазы уточнения означает достижение этапа жизненного цикла архитектуры.

Построение (Construction)

реализация большей части функциональности продукта;

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

Внедрение (Transition)

создается финальная версия продукта и передается от разработчика к заказчику:

12

o программу бета-тестирования, o обучение пользователей,

oопределение качества продукта.

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

6.*УНИФИЦИРОВАННЫЙ ПРОЦЕСС РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ UML. ОСНОВНЫЕ ВИДЫ МОДЕЛЕЙ

УНИФИЦИРОВАННЫЙ ПРОЦЕСС РАЗРАБОТКИ ПО - Rational Unified Process, RUP - является примером так называемого "тяжелого" процесса, детально описанного и предполагающего поддержку собственно разработки исходного кода ПО большим количеством вспомогательных действий (разработка планов, ТЗ, проектных моделей, проектной документации и пр.

Унифицированный процесс разработки ПО основан на следующих идеях:

Весь ход работ направляется итоговыми целями проекта, выраженными в виде вариантов использования (use cases). Разработка начинается с выделения вариантов использования и на каждом шаге контролируется степенью приближения к их реализации;

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

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

RUP выделяет в жизненном цикле 4 основные фазы, в рамках каждой из которых возможно проведение нескольких итераций:

ФАЗА НАЧАЛА ПРОЕКТА (Inception) - определяются основные цели проекта, руководитель и бюджет, основные средства выполнения — технологии, инструменты, ключевые исполнители;

13

ФАЗА ПРОЕКТИРОВАНИЯ (Elaboration) - цель этой фазы — на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта;

ФАЗА ПОСТРОЕНИЯ (CONSTRUCTION) - цель этой фазы — детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры;

ФАЗА ВНЕДРЕНИЯ (Transition) - происходит развертывание системы в ее рабочей среде, бета-тестирование, подгонка мелких деталей под нужды пользователей.

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

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

ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ – способ представления идей и проблем реального мира с помощью моделей. Модель помогает понять проблему всем участникам, задействованным в проекте, вне зависимости от уровня подготовки.

МОДЕЛЬ - это абстракция, описывающая суть сложной проблемы или структуры без акцента на несущественных деталях, тем самым делая ее более понятной.

1.МОДЕЛЬ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ определяет требования к ПО (что система должна делать) в виде набора вариантов использования. Каждый вариант использования задаёт сценарий взаимодействия системы с актёрами (люди и системы, взаимодействующие с разрабатываемой системой).

14

2.МОДЕЛЬ АНАЛИЗА включает классы, необходимые для реализации выделенных вариантов использования и возможные связи между классами (это набор сущностей, в виде которых система представляется пользователям). Классы делятся на ИНТЕРФЕЙСНЫЕ (boundary classes) – взаимодействуют с внешней средой, УПРАВЛЯЮЩИЕ (control classes) – алгоритмы, управляющие обменом данными и КЛАССЫ ДАННЫХ (entity classes) – описывают однотипные сущности системы.

3.МОДЕЛЬ ПРОЕКТИРОВАНИЯ состоит из классов, но из более определённых, чем классы модели анализа. Они имеют более детальное определение обязанностей и должны быть специализированы для конкретной используемой платформы (ОС вовлечённых машин, интерфейсы и классы конкретных компонентных сред, интерфейсы для управления БД, используемые библиотеки разработки пользовательского интерфейса и пр.).

4.МОДЕЛЬ РЕАЛИЗАЦИИ представляет собой в рамках RUP и UML набор компонентов результирующей системы и связей между ними. Под компонентом здесь имеется в виду компонент сборки — минимальный по размерам кусок кода системы, который может участвовать или не участвовать в определенной ее конфигурации, единица сборки и конфигурационного управления. Связи между компонентами представляют собой зависимости между ними. Если компонент зависит от другого компонента, он не может быть

15

поставлен отдельно от него. Часто компоненты представляют собой отдельные файлы с исходным кодом.

5.МОДЕЛЬ РАЗВЁРТЫВАНИЯ представляет собой набор узлов системы, являющихся физически отдельными устройствами, которые способны обрабатывать информацию — серверами, рабочими станциями, принтерами, контроллерами датчиков и пр., со связями между ними, образованными различного рода сетевыми соединениями.

6.МОДЕЛЬ ТЕСТИРОВАНИЯ определяет тестовые примеры (test cases) и тестовые процедуры (test scripts). ТЕСТОВЫЕ ПРИМЕРЫ являются определенными сценариями работы одного или нескольких действующих лиц с системой, разворачивающимися в рамках одного из вариантов использования. Включает, помимо входных данных на каждом шаге, где они могут быть введены, условия выполнения отдельных шагов и корректные ответы системы для всякого шага, на котором ответ системы можно наблюдать. ТЕСТОВАЯ ПРОЦЕДУРА представляет собой способ выполнения одного или нескольких тестовых вариантов и их составных элементов (отдельных шагов и проверок). Это может быть инструкция по ручному выполнению входящих в тестовый вариант действий или программный компонент, автоматизирующий запуск тестов.

7.МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ. Задачи этой деятельности — понять предметную область или бизнес-контекст, в которых должна будет работать система, и убедиться, что все заинтересованные лица понимают его одинаково, осознать имеющиеся проблемы, оценить их возможные решения и их последствия для бизнеса организации, в которой будет работать система. В результате моделирования предметной области должна появиться ее модель в виде набора диаграмм классов (объектов предметной области) и деятельностей (представляющих бизнесоперации и бизнес-процессы). Эта модель служит основой модели анализа.

8.ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ. Задачи — понять, что должна делать система, и убедиться во взаимопонимании по этому поводу между заинтересованными лицами, определить границы системы и основу для планирования проекта и оценок затрат ресурсов в нём. Требования принято фиксировать в виде модели вариантов использования.

16

9.АНАЛИЗ И ПРОЕКТИРОВАНИЕ. Задачи — выработать архитектуру системы на основе требований, убедиться, что данная архитектура может быть основой работающей системы в контексте её будущего использования. В результате проектирования должна появиться модель проектирования, включающая диаграммы классов системы, диаграммы её компонентов, диаграммы взаимодействий между

объектами в ходе реализации вариантов использования, диаграммы состояний для отдельных объектов и диаграммы развёртывания.

10.РЕАЛИЗАЦИЯ. Задачи — определить структуру исходного кода системы, разработать код её компонентов и протестировать их, интегрировать систему в работающее целое.

11.ТЕСТИРОВАНИЕ. Задачи — найти и описать дефекты системы (проявления недостатков ее качества), оценить её качество в целом, оценить, выполнены или нет гипотезы, лежащие в основе проектирования, оценить степень соответствия системы требованиям.

12.РАЗВЁРТЫВАНИЕ. Задачи — установить систему в её рабочем окружении и оценить её работоспособность на том месте, где она должна будет работать.

13.УПРАВЛЕНИЕ КОНФИГУРАЦИЯМИ И ИЗМЕНЕНИЯМИ. Задачи — определение элементов, подлежащих хранению в депозитарии проекта и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений.

14.УПРАВЛЕНИЕ ПРОЕКТОМ. Задачи — планирование, управление персоналом, обеспечение взаимодействия на благо проекта между всеми заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта.

15.УПРАВЛЕНИЕ СРЕДОЙ ПРОЕКТА. Задачи — подстройка процесса под конкретный проект, выбор и замена технологий и инструментов, используемых в проекте.

7.*ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ. ОСНОВНЫЕ ПРИНЦИПЫ

17

ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ (англ. Extreme Programming, XP)

— одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

ТЕСТИРОВАНИЕ

написание автоматических тестов, особое внимание юнит-тестам модулей и функциональному тестированию);

Рефакторинг — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы;

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

ИГРА В ПЛАНИРОВАНИЕ

Цель - быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими.

Заказчик отвечает за принятие бизнес-решений, а команда разработчиков отвечает за принятие технических решений.

18

ЗАКАЗЧИК ВСЕГДА РЯДОМ

Заказчик – это конечный пользователь продукта, который всё время на связи и доступен для вопросов.

ПАРНОЕ ПРОГРАММИРОВАНИЕ

Весь код создается парами программистов, работающих за одним компьютером.

Один человек работает непосредственно с текстом программы, другой просматривает его работу.

При необходимости клавиатура свободно передаётся от одного к другому.

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

НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ

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

ЧАСТЫЕ НЕБОЛЬШИЕ РЕЛИЗЫ

Релизы продукта должны поступать в эксплуатацию как можно чаще.

Работа над каждой версией должна занимать как можно меньше времени.

ПРОСТОТА ПРОЕКТИРОВАНИЯ

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

Проектирование выполняется постоянно небольшими этапами в течение всего времени работы над проектом.

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

МЕТАФОРА СИСТЕМЫ

19

Метафора системы даёт команде представление о том, каким образом система работает в настоящее время, в каких местах добавляются новые компоненты, и какую форму они должны принять.

СТАНДАРТЫ ОФОРМЛЕНИЯ КОДА

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

КОЛЛЕКТИВНОЕ ВЛАДЕНИЕ

Каждый член команды несёт ответственность за весь исходный код.

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

8.*ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ. ДОСТОИНСТВА И НЕДОСТАТКИ

ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ (англ. Extreme Programming, XP)

— одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

Следующие преимущества XP имеют смысл, когда команда полноценно использует хотя бы одну из практик XP:

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

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

код всегда работает за счёт постоянного тестирования и непрерывной интеграции;

команда легко поддерживает код, т.к. он написан по единому стандарту и постоянно рефакторится;

быстрый темп разработки за счёт парного программирования, отсутствия переработок, присутствия заказчика в команде;

высокое качество кода;

20