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

Основные понятия технологии программирования

Орлов С.А. Технологии разработки программного обеспечения: Учебник для вузов. 3-е изд. ­– СПб.: Питер, 2004. – 527 с.: ил.
Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD.: Пер. с англ.: – М.: Издательско-торговый дом «Русская Редакция», 2000. – 608 с.: ил.
Лингер, Р. Теория и практика структурного программирования / Ричард Лингер, Хэрлан Миллс, Бернард Уитт.: Пер. с англ.: – М.: Мир, 1982. – 406 с.: ил.
Грис, Дэвид. Наука программирования.: Пер. с англ.: – М.: Мир, 1984. – 416 с.: ил.
Буч, Грейди. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. 2-е изд.: Пер. с англ.: – СПб.: Невский диалект, 1998. – 560 с.: ил.
Оберг, Роберт, Дж. Технология COM+. Основы и программирование.: Пер. с англ.: Уч. пос. – М.: Издательский дом «Вильямс», 2000. – 480 с.: ил.
Уоткинз, Д. Программирование на платформе .Net / Деймьен Уоткинз, Марк Хаммонд, Брэд Эйбрамз.
Delphi и технологияCOM. Мастер-класс / Н. Елманова, С. Трепалин, А. Тенцер. – СПб: Питер, 2003 – 698 с.: ил.
В. В. Кулямин. Технологии программирования. Компонентный подход. http://panda.ispras.ru/~kuliamin/sdt-cou...

==================
Основная тема данного курса —

методы разработки «больших» и сложных программ

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

Для «малых» программ можно указать следующие характерные особенности:

1. сравнительно небольшой размер (порядка нескольких сотен строк);
2. направленность на решение одной четко поставленной задачи с хорошо известными ограничениями;
3. отсутствие оптимизации по скорости выполнения;
4. практическое отсутствие ущерба от неправильной работы программы;
5. отсутствие необходимости дополнять программу новыми возможностями и разрабатывать ее новые версии;
6. минимальная потребность в документировании

Большие» программы.

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

• всевозможные системы автоматизации производственных процессов,
• системы управления и контроля,
• СУБД и т.д

Свойства «больших» программ

«Большая» программа обычно обладает следующими свойствами:

1. решает одну или несколько связанных задач, важных для каких-либо лиц или организаций, получающих существенные выгоды от ее использования;
2. ее неправильная работа или низкая производительность на реальных данных наносит ощутимый ущерб пользователям и другим организациям и лицам;
3. сопровождается полной и понятной пользователям документацией, а также специальной документацией для администраторов;
4. дополняется проектной документации к ПС, что позволяет развивать ее даже без привлечения первоначальных разработчиков;
5. такую программу невозможно написать с первой попытки, с небольшими усилиями и в одиночку; ее разработка ведется коллективом специалистов

Программное обеспечение

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

Программная инженерия и технология программирования

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

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

Методы и средства ТП

Технология программирования состоит из средств и методов.

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

Методы ТП

определяют=

1. организационную структуру коллектива разработчиков,
2. способы разбиения процесса разработки на отдельные этапы,
3. последовательность этих этапов и т.д.

Средства ТП

Средствами технологии программирования называются утилиты, обеспечивающие автоматизированную или автоматическую поддержку методов
Совместно используемые утилиты объединяются в системы автоматизированной разработки ПО
Такие системы принято называть CASE-средствами (Computer Aided Software Engineering)

Понятие «правильности» программы

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

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

Это объясняется тем, что=

1. во-первых, практически невозможно выполнить полное доказательство или проверку правильности такой программы;
2. во-вторых, требования к данному ПО у разных групп пользователей могут существенно различаться и значительно изменяться с течением времени

Понятие качества программного обеспечения

Качество ПО – это вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц (стандарт ISO 9126)

Критерии качества ПО

Основными критериями качества ПО (criteria of software quality) являются:

1. функциональность
2. надежность
3. эффективность
4. эргономичность
5. модифицируемость
6. мобильность

Теперь разберём эти понятия подробнее

1) Функциональность ПО =
Способность ПО выполнять набор функций (действий), удовлетворяющих заданным или подразумеваемым потребностям пользователей
Набор указанных функций определяется во внешнем описании ПО

2) Надежность программного обеспечения =
Надежность (reliability) ПО - это его способность с достаточно большой вероятностью безотказно выполнять определенные функции при заданных условиях и в течение заданного периода времени

3)Эффективность программного обеспечения =
Соотношение уровня услуг, предоставляемых ПО пользователю при заданных условиях, и объема используемых для этого ресурсов
К числу таких ресурсов могут относиться =

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

4) Эргономичность ПО =
Характеристики ПО, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПО и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя

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

6) Мобильность ПО =
Способность ПО быть перенесенным из одной среды (окружения) в другую, в частности, с одной аппаратной платформы на другую

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

Проблемы разработки программного обеспечения

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

-----

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

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

Жизненный цикл ПО состоит из=

1. фазы разработки,
2. фазы использования
3. и фазы продолжающейся разработки (модификации)

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

---------

Артефакты

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

При этом создаются и перерабатываются различного рода артефакты

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

Примерами артефактов являются:

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

Роли

На различных этапах в создание и эксплуатацию ПО вовлекаются люди, выполняющие различные роли

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

Примерами ролей являются:

1. бизнес-аналитик,
2. инженер по требованиям,
3. архитектор,
4. проектировщик пользовательского интерфейса,
5. программист-кодировщик,
6. технический писатель,
7. тестировщик,
8. руководитель проекта по разработке,
9. работник отдела продаж,
10. конечный пользователь,
11. администратор системы,
12. инженер по поддержке и т.п.

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

Модели процесса разработки

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

Стратегии разработки ПО

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

Отдельные модели соответствуют одной из стратегий разработки –

1. линейной
2. инкрементной
3. или эволюционной

О них подробнее=

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

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

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

ВИДЫ МОДЕЛЕЙ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

Предполагает строго последовательное поэтапное выполнение различных видов деятельности с четким определением границ между этапами

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

СТРУКТУРА =

Выработка системных требований->Выработка требований к ПО->Анализ->Проектирование->Кодирование->Тестирование->Эксплуатация

Достоинства модели:

1. упорядоченность процесса разработки
2. возможность его строгого планирования во времени.

Недостатки модели:

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

----------

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

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

СТРУКТУРА =

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

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

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

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

-----------

RAD-модель

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

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

Каждая группа делает следующее(для той части проекта , что разрабатывает) =

Моделирование предметной области->Моделирование данных->Моделирование обработки->Генерация приложения->Объединение и тестирование

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

Как правило RAD-модель используется при работе с мощными инструментальными средствами разработки – визуальными средами проектирования и программирования

Основным достоинством модели является уменьшение сроков разработки

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

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

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

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

Модель определяет четыре действия:=

1. планирование
2. анализ рисков
3. конструирование
4. оценивание.

О них подробнее =
1) Планирование заключается в =

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

2) Анализ рисков – анализ вариантов решения и оценка связанных с ними рисков, т.е. возможностей получения неудовлетворительных результатов
3) Конструирование – это основное действие, заключающееся в создании следующей версии ПО
4) Оценивание – оценка заказчиком качества очередной версии ПО, внесение им предложений по модификации продукта, корректировка требований

Достоинства модели:

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

Недостатки модели:

1. повышенные требования к заказчику;
2. трудности контроля и управления временем разработки

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

Прогнозирующие процессы

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

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

Многочисленные вспомогательные действия [позволяют] выполнить успешную разработку с помощью имеющихся работников, не обязательно являющихся "суперпрофессионалами"

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

Адаптивные процессы

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

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

------

Принципы «живой» разработки

Основные принципы «живой» разработки ПО зафиксированы в манифесте, появившемся в 2000 году:=

1. Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты
2. Работающая программа более важна, чем исчерпывающая документация
3. Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта
4. Отработка изменений более важна, чем следование планам

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

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

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

XP-процесс (экстремальное программирование)

Основная идея XP-процесса – устранить высокую стоимость внесения изменений. Это достигается путем резкого (до двух недель) сокращения длительности отдельных итераций.
Базовыми действиями xp являются:=

1. кодирование,
2. тестирование,
3. выслушивание заказчика,
4. проектирование

Принципы XP

Высокий динамизм разработки обеспечивается следующими принципами:=

1. непрерывная связь с заказчиком,
2. простота выбираемых решений,
3. быстрая обратная связь на основе оперативного тестирования,
4. профилактика рисков

Практики XP разработки

Реализация этих принципов достигается за счет использования следующих методов:=

1. Метафора – вся разработка ведется на основе простой, общедоступной истории о том, как работает система
2. Простое проектирование – принимаются наиболее простые из возможных проектные решения
3. Непрерывное тестирование как отдельных модулей, так и системы в целом; входным критерием для написания кода является отказавший тестовый вариант
4. Реорганизация ( Refactoring ) – улучшение структуры системы при сохранении ее поведения
5. Парное программирование – код пишется двумя программистами на одном компьютере
6. Коллективное владение кодом – любой разработчик может улучшить код любого модуля системы
7. Непрерывная интеграция – система интегрируется как можно чаще; непрерывное регрессионное тестирование гарантирует сохранение функциональности при изменении требований
8. Локальный заказчик – в группе все время должен находиться компетентный представитель заказчика
9. Стандарты кодирования – должны выдерживаться правила, обеспечивающие одинаковое представление кода во всех частях системы

схема XP разработки

изображение XP (схема XP разработки ):

------------[конец лекции]---------------------------