1) Основные понятия

ЛЕКЦИЯ ПЕРВАЯ = "ОСНОВНЫЕ ПОНЯТИЯ"

технология программирования – совокупность принципов разработки, обеспечивающих массовое производство ПО требуемого качества в установленные сроки
-------------------
Свойство программы, характеризующееся отсутствием в ней ошибок по отношению к целям разработки, называется правильностью программы
-------------------------------
В связи с тем, что доказать правильность на практике обычно оказывается невозможным , вместо понятия правильности используют понятие качества ПО.
Качество ПО – это вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц (стандарт ISO 9126)
-----------------------------------
Основными критериями качества ПО (6 штук) (criteria of software quality) являются:
+функциональность
+надежность
+эффективность
+эргономичность
+модифицируемость
+мобильность
--------------------------

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

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

Жизненный цикл ПО состоит из
+фазы разработки,
+фазы использования
+фазы продолжающейся разработки (модификации), причем две последние фазы близки или совпадают по времени

-------------------------------
Артефакты – создаваемые человеком информационные сущности (документы), участвующие в качестве входных данных и результатов в различных видах деятельности

Примерами артефактов являются:
+модель предметной области,
+описание требований,
+техническое задание,
+архитектура системы,
+проектная документация на систему в целом и на ее компоненты,
+прототипы системы и компонентов,
+исходный код,
+пользовательская документация,
+документация администратора системы,
+руководство по развертыванию,
+база пользовательских запросов,
+план проекта
------------------------
РОЛЬ

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

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

МОДЕЛИ ПРОЦЕССА РАЗРАБОТКИ

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

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

Линейная стратегия предполагает однократное прохождение всех этапов разработки ПО

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

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

---------------------------
Каскадная модель

Наиболее широко известной и применяемой долгое время оставалась так называемая каскадная или водопадная (waterfall) модель жизненного цикла
Впервые четко сформулирована в 1970 году Уильямом Ройсом (W.W.Royce) и затем закреплена в стандартах Министерства обороны США

Предполагает строго последовательное поэтапное выполнение различных видов деятельности с четким определением границ между этапами
Набор документов, созданный на предыдущем этапе, передается в качестве входных данных для следующего этапа
СТРУКТУРА =
Выработка системных требований->Выработка требований к ПО->Анализ->Проектирование->Кодирование->Тестирование->Эксплуатация
Достоинства модели:
упорядоченность процесса разработки
возможность его строгого планирования во времени.

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

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

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

Анализ->Проектирование->Кодирование->Тестирование
постановка 2-ой версии
Анализ->Проектирование->Кодирование->Тестирование
постановка 3-ей версии и т.д.

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

--------------------------
RAD-модель

Модель быстрой разработки приложений (Rapid Application Development) появилась в 80-х годах прошлого века и является еще одним примером реализации инкрементной стратегии
Предполагает выделение в системе нескольких основных бизнес-функций и разработку каждой из них отдельной группой разработчиков с последующей интеграцией в целую систему

Каждая группа делает следующее(для той части проекта , что разрабатывает) =
Моделирование предметной области->Моделирование данных->Моделирование обработки->Генерация приложения->Объединение и тестирование

Условия применения модели=
Применение данной модели оправдано в проектах, не требующих выполнения сложных алгоритмов, но при жестких ограничениях по сроками выполнения
Как правило RAD-модель используется при работе с мощными инструментальными средствами разработки – визуальными средами проектирования и программирования
Основным достоинством модели является уменьшение сроков разработки
Ее главный недостаток заключается в необходимости использования большого числа квалифицированных разработчиков, что может существенно повысить стоимость разработки

--------------------------
Спиральная модель

Предложена в 1988 г. Барри Боэмом (Barry W. Boehm) и является классическим примером реализации эволюционной стратегии.
Модель определяет четыре действия:
планирование
анализ рисков
конструирование
оценивание

*Планирование заключается в определении целей очередной итерации процесса разработки, выборе вариантов решения и оценки ограничений.

*Анализ рисков – анализ вариантов решения и оценка связанных с ними рисков, т.е. возможностей получения неудовлетворительных результатов.

*Конструирование – это основное действие, заключающееся в создании следующей версии ПО.

*Оценивание – оценка заказчиком качества очередной версии ПО, внесение им предложений по модификации продукта, корректировка требований

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

Недостатки модели:
повышенные требования к заказчику;
трудности контроля и управления временем разработки
------------------------
Прогнозирующие процессы

Все рассмотренные выше модели соответствуют так называемым прогнозирующим ( тяжеловесным ) процессам разработки ПС
Они предполагают планирование всего объема работ и, соответственно, достаточно большой объем документации
Основная цель таких процессов –отделить успешные практики разработки и сопровождения ПО от конкретных людей, умеющих их применять
-----------------------
Адаптивные процессы
В настоящее время все большее распространение получают адаптивные или облегченные, «живые» (agile) процессы разработки
Они не требуют столь жесткой регламентации, допускают возможность частых и существенных изменений требований заказчиков
Адаптивные процессы делают упор на использовании хороших разработчиков, а не хорошо отлаженных процессов разработки
Они избегают фиксации четких схем действий, чтобы обеспечить большую гибкость в каждом конкретном проекте и не требуют разработки дополнительных промежуточных документов

---------------------------------------

Принципы «живой» разработки
Основные принципы «живой» разработки ПО зафиксированы в манифесте, появившемся в 2000 году:
Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты
Работающая программа более важна, чем исчерпывающая документация
Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта
Отработка изменений более важна, чем следование планам.
-----------------

Экстремальное программирование

Наиболее часто используемой адаптивной моделью является модель экстремального программирования (eXtreme Programming, XP-процесс)
XP-процесс ориентирован на группы малого и среднего размера, разрабатывающих ПС в условиях неопределенных или быстро меняющихся требований
Основная идея XP-процесса – устранить высокую стоимость внесения изменений. Это достигается путем резкого (до двух недель) сокращения длительности отдельных итераций. Базовыми действиями являются:
+кодирование,
+тестирование,
+выслушивание заказчика,
+проектирование
-----------------------

Принципы XP

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

Реализация этих принципов достигается за счет использования следующих методов:
+Метафора – вся разработка ведется на основе простой, общедоступной истории о том, как работает система
+Простое проектирование – принимаются наиболее простые (видимо "решения из возможных")
+Непрерывное тестирование как отдельных модулей, так и системы в целом; входным критерием для написания кода является отказавший тестовый вариант
+Реорганизация ( Refactoring ) – улучшение структуры системы при сохранении ее поведения
+Парное программирование – код пишется двумя программистами на одном компьютере
+Коллективное владение кодом – любой разработчик может улучшить код любого модуля системы
+Непрерывная интеграция – система интегрируется как можно чаще; непрерывное регрессионное тестирование гарантирует сохранение функциональности при изменении требований
+Локальный заказчик – в группе все время должен находиться компетентный представитель заказчика
+Стандарты кодирования – должны выдерживаться правила, обеспечивающие одинаковое представление кода во всех частях системы - это способствует скорости разработки и вникаю в "код соседа" - см. предыдущие практики XP