КОНСПЕКТ ОБЗОРНОЙ ЛЕКЦИИ

Для студентов специальности
Т1002 «Программное обеспечение информационных технологий»

(А.М.Кадан, к.т.н., доцент)

 

ВОПРОС № 33. ТЕХНОЛОГИЯ ПРОГРАММИРОВАНИЯ

 

  1. Методология и технология программирования.
  2. Жизненный цикл программного обеспечения.
  3. Технологические подходы, процессы и стадии.
  4. Критерии «правильного» программирования.

 

Методология и технология программирования

 

Приведем основные определения.

 

Программа — завершенный продукт, пригодный для запуска своим автором на системе, на которой он был разработан.

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

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

 

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

Существует простейшее представление жизненного цикла, которое включает следующие стадии:

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

 

Методология программирования – совокупность методов, применимых в жизненном цикле программного обеспечения и объединенных общим философским подходом.

 

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

 

Технология программирования изучает технологические процессы и порядок их прохождения – стадии (с использованием знаний, методов и средств).

 

Технологические подходы, процессы и стадии

 

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

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

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

 

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

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

 

История и эволюция. В истории технологии программирования можно выделить три этапа.

1)     Осмысление опыта разработки больших систем. Понимание того, что важно не только на каком языке программирования разрабатывается программа, но и как это делается. Проведение первых международных и национальных конференций (конец 60-х — 70-е годы XX века).

a)     1968 г. — НАТО проводит первую конференцию по инженерии программирования (Software Engineering).

b)     1975 г. — 1-я международная конференция IEEE.

c)     1979 г. — 1-я Всесоюзная конференция по технологии программирования.

2)     Разработка новых технологических подходов (начало 70-х годов XX века — настоящее время).

a)     1973 г. — Дагласом Россом (Douglas Ross) разработана технология проектирования сложных систем SADT (Structured Analysis and Design Technique). Стандартизована под названием IDEF (Integrated DEFinition).

b)     1985 г. — Харланом Миллзом (Harlan Mills) сформулированы основные идеи технологии стерильного цеха.

c)     1995 г. — в октябре появилась первая пробная версия Унифицированного метода. Этот проект с 1996 года известен как UML (Unified Modeling Language)..

3)     Принятие стандартов на состав процессов жизненного цикла программного обеспечения (середина 80-х годов XX века — настоящее время). Попытки решить проблему качества программных продуктов.

a)     1985 г. — впервые утвержден стандарт жизненного цикла для проектирования программных систем (для систем военного назначения по заказам Министерства обороны США).

b)     1994 г. — в Великобритании создан международный консорциум, разрабатывающий на постоянной основе проекты стандартов и технологии быстрого создания приложений DSDM (Dnamic Systems Development Method).

c)     1995 г. — принят международный стандарт ISO 12207:1995 "Information Technology — Software Life Cycle Processes", регламентирующий состав процессов жизненного цикла программного обеспечения.

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

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

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

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

Классификация технологических процессов. Все наборы (множества) технологических процессов можно разделить на две группы. Первый набор — классический, включающий основные процессы, сложившиеся исторически в результате практического опыта разработки программного обеспечения. Второй набор — стандартный, т. е. основанный на стандарте ISO 12207:1995. Процессы классического набора фактически являются подмножеством стандартного, выступая там как процессы или действия процессов.

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

·         Ввод в действие

·         Эксплуатация и сопровождение

·         Завершение эксплуатации

Процессы жизненного цикла, определяемые международным стандартом ISO 12207 [ISO/IEC 12207:1995], делятся на три группы.

1) Основные процессы.

a)      Приобретение

b)      Поставка

c)      Разработка

d)      Эксплуатация

e)      Сопровождение

2)     Вспомогательные процессы.

a)  Документирование

b)  Управление конфигурацией

c)  Обеспечение качества

d)  Верификация

e)  Аттестация

f)    Совместная оценка

g)  Аудит

h)  Разрешение проблем

3)      Организационные процессы.

a)  Управление

b)  Создание инфраструктуры

c)  Усовершенствование

d)  Обучение

 

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

 

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

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

Максимизация скорости разработки. Это направление в большей степени обращено к искусству, импровизации и поиску. Гибкие и адаптивные технологические подходы поддерживают именно этот путь. Особенность разработки определяется появлением новых классов систем. За последние несколько десятков лет такими классами были, например, системы "клиент-сервер", распределенные системы, интерактивные системы, системы Internet-приложений.

С точки зрения технологий, задача разработки Internet-приложений является очень специфичной. Базироваться на классических технологических подходах ей не позволяют следующие особенности:

•       задача, как правило, не будет четко определена и специфицирована;

•       заказчики не смогут точно сформулировать свои требования;

•       как только система будет завершена, она устареет;

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

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

 

Основные технологические подходы (модели жизненного цикла)

 

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

Подход "кодирование и исправление". Подход "кодирование-исправление" (code and fix) упрощенно может быть описан следующим образом. Разработчик начинает кодирование системы с самого первого дня, не занимаясь сколько-либо серьезным проектированием.

Все ошибки обнаруживаются, как правило, к концу кодирования и требуют исправления через повторное кодирование.

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

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

Каскадные технологические подходы.

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

Каскадный подход. Каскадный подход (pure waterfall) считается "дедушкой" технологических подходов к ведению жизненного цикла. Фактически, его можно рассматривать гак отправную точку для огромного количества других подходов. Сформировался каскадный подход в период с 1970 по 1985 годы. Специфика "чистого" каскадного подхода такова, что переход к следующему процессу осуществляется только после того, как завершена работа с текущим процессом (см. рис. выше). Возвраты к уже пройденным процессам не предусмотрены.

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

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

 

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

Каскадный подход с перекрывающимися процессами. Классический каскадный подход позволяет выполнять каждый процесс отдельной команде. Достаточно разумным является использование команды на том же самом процессе в следующей разработке. Каскадный подход с перекрывающимися процессами (waterfall with overlapping) предполагает наличие таких специализированных команд, позволяющих до определенной степени сократить передаваемую документацию. Следующий процесс начинается до завершения текущего. Более того, несколько процессов могут выполняться параллельно.

 

Каскадный подход с подпроцессами. Каскадный подход с подпроцессами (waterfall with subprocesses) очень близок подходу с перекрывающимися процессами. Особенность его в том, что с архитектурной точки зрения проект достаточно часто может быть разделен на подпроекты, которые могут разрабатываться индивидуально. В данном подходе требуется дополнительная фаза тестирования подсистем до объединения их в единую систему. Следует особое внимание обращать на грамотное деление проекта на подпроекты, которое должно учесть все возможные зависимости между подсистемами.

Спиральная модель. Спиральная модель (spiral model) была предложена Барри Боэмом (Barry Вoеm) в середине 80-х годов XX века с целью сократить возможный риск разработки. Фактически, это была первая реакция на устаревание каскадной модели. Спиральная модель использует понятие прототипа — программы, реализующей частичную функциональность создаваемого программного продукта. Создание прототипов осуществляется за несколько витков спирали, каждый из которых состоит из "анализа риска", "некоторого процесса" и "верификации". Обращение к каждому процессу предваряет "анализ риска", причем, если риск превышения сроков и стоимости проекта оказывается существенным, то разработка заканчивается. Это позволяет предотвратить более крупные денежные потери в будущем.

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

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

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

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

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

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

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

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

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

• полезной, если задача, которую она решает, представляет практическую ценность;

• эффективной, если объем требуемых для ее работы ресурсов ЭВМ не превышает допустимого предела;

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

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

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