Ответы к госэкзамену по технологии разработки программных продуктов для ССУЗов

Подождите немного. Документ загружается.

Технология разработки программных продуктов

1. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНЫХ СРЕДСТВ: ОСНОВНЫЕ

ПОНЯТИЯ, КАСКАДНАЯ МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА.

Жизненный цикл программного обеспечения (ПО)— период времени, который

начинается с момента принятия решения о необходимости создания программного

продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл—

процесс построения и развития ПО.

Процессы жизненного цикла ПО

1. Основные:

a. Приобретение (действия и задачи заказчика, приобретающего ПО)

b. Поставка (действия и задачи поставщика, который снабжает заказчика

программным продуктом или услугой)

c. Разработка (действия и задачи, выполняемые разработчиком: создание ПО,

оформление проектной и эксплуатационной документации, подготовка тестовых и

учебных материалов и т. д.)

d. Эксплуатация (действия и задачи оператора — организации,

эксплуатирующей систему)

e. Сопровождение (действия и задачи, выполняемые сопровождающей

организацией, то есть службой сопровождения). Сопровождение — внесений

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

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

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

a. Документирование (формализованное описание информации, созданной в

течение ЖЦ ПО)

b. Управление конфигурацией (применение административных и технических

процедур на всем протяжении ЖЦ ПО для определения состояния компонентов

ПО, управления его модификациями).

c. Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее

ЖЦ соответствуют заданным требованиям и утвержденным планам)

d. Верификация (определение того, что программные продукты, являющиеся

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

условиям, обусловленным предшествующими действиями)

e. Аттестация (определение полноты соответствия заданных требований и

созданной системы их конкретному функциональному назначению)

f. Совместная оценка (оценка состояния работ по проекту: контроль

планирования и управления ресурсами, персоналом, аппаратурой,

инструментальными средствами)

g. Аудит (определение соответствия требованиям, планам и условиям

договора)

h. Разрешение проблем (анализ и решение проблем, независимо от их

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

эксплуатации, сопровождения или других процессов)

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

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

стороной, управляющей своими процессами)

b. Создание инфраструктуры (выбор и сопровождение технологии, стандартов

и инструментальных средств, выбор и установка аппаратных и

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

сопровождения ПО)

Технология разработки программных продуктов

c. Усовершенствование (оценка, измерение, контроль и усовершенствование

процессов ЖЦ)

d. Обучение (первоначальное обучение и последующее постоянное повышение

квалификации персонала)

Каждый процесс включает ряд действий. Например, процесс приобретения

охватывает следующие действия:

 Инициирование приобретения

 Подготовка заявочных предложений

 Подготовка и корректировка договора

 Надзор за деятельностью поставщика

 Приемка и завершение работ

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

предложений должна предусматривать:

Формирование требований к системе

Формирование списка программных продуктов

Установление условий и соглашений

Описание технических ограничений (среда функционирования системы и т. д.)

Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями

Модель жизненного цикла ПО — структура, определяющая последовательность

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

Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель

жизненного цикла. Его положения являются общими для любых моделей жизненного

цикла, методов и технологий создания ИС. Он описывает структуру процессов

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

включенные в эти процессы.

Модель ЖЦ ПО включает в себя:

1. Стадии;

2. Результаты выполнения работ на каждой стадии;

3. Ключевые события — точки завершения работ и принятия решений.

Стадия — часть процесса создания ПО, ограниченная определенными временными

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

компонентов, документации), определяемого заданными для данной стадии

требованиями.

На каждой стадии могут выполняться несколько процессов, определенных в

стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может

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

определяется используемой моделью жизненного цикла ПО.

Модели жизненного цикла ПО

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

Каскадная модель жизненного цикла («модель водопада», англ. waterfall model)

была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное

выполнение всех этапов проекта в строго фиксированном порядке. Переход на

следующий этап означает полное завершение работ на предыдущем этапе. Требования,

определенные на стадии формирования требований, строго документируются в виде

технического задания и фиксируются на все время разработки проекта. Каждая стадия

Технология разработки программных продуктов

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

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

Этапы проекта в соответствии с каскадной моделью:

 Формирование требований;

 Проектирование;

 Реализация;

 Тестирование;

 Внедрение;

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

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

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов

Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act).

При использовании этой модели ПО создается в несколько итераций (витков спирали)

методом прототипирования.

Прототип — действующий компонент ПО, реализующий отдельные функции и

внешние интерфейсы. Каждая итерация соответствует созданию фрагмента или версии

ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных

результатов и планируются работы следующей итерации.

На каждой итерации оцениваются:

риск превышения сроков и стоимости проекта;

необходимость выполнения еще одной итерации;

степень полноты и точности понимания требований к системе;

целесообразность прекращения проекта.

Один из примеров реализации спиральной модели — RAD (англ. Rapid Application

Development, метод быстрой разработки приложений).

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

Естественное развитие каскадной и спиральной моделей привело к их сближению и

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

сочетание этих моделей. Различные варианты итерационного подхода реализованы в

большинстве современных технологий и методов (RUP, MSF, XP).

Технология разработки программных продуктов

2. ХАРАКТЕРИСТИКИ КАЧЕСТВА ПРОГРАММНЫХ

ПРОДУКТОВ.

Под показателем качества программной продукции в соответствии с ГОСТ 15467—

79 следует понимать количественную характеристику одного или нескольких свойств

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

условиям ее создания и эксплуатации. Свойство продукции — это объективная

особенность, которая может проявиться при создании или эксплуатации продукции. В

определении понятия «Показатель качества» слова «Количественная характеристика» не

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

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

строго количественных, числовых характеристик предпочтительней.

Показатели качества программной продукции в зависимости от характера

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

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

свойств; место применения в процедуре оценки; стадии определения значений

показателей.

По способу выражения различают показатели, выраженные в натуральных

единицах, и показатели, выраженные в стоимостных единицах. В качестве натуральных

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

т. п.), а также баллы и безразмерные единицы. ПС являются информационными

объектами. Какими-либо собственными физическими свойствами они не обладают,

поэтому единицы физических величин в традиционном виде при определении значений

показателей качества ПС почти не применяются, за исключением единиц времени. Но как

составной элемент системы обработки данных ПС вносит определенную долю

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

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

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

строка текста и т. п. Стоимостные единицы применяют при определении значений

экономических показателей качества программной продукции.

По количеству характеризуемых свойств различают единичные и комплексные

показатели. Единичные показатели качества характеризуют одно из свойств ПС,

комплексный—несколько. Комплексные показатели могут быть групповыми,

обобщенными или интегральными.

В зависимости от места применения в процедуре оценки уровня качества ПС

различают базовые и относительные показатели. Базовым значением показателя качества

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

качества продукции. Относительное значение показателя качества продукции

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

продукции к базовому значению этого показателя.

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

проектные, производственные и эксплуатационные показатели. Прогнозируемыми

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

составления ТЗ на разработку ПС, т. е. на тех стадиях, когда нет еще ни детального

проекта ПС, ни, тем более, самого ПС. Значения прогнозируемых показателей в основном

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

носят субъективный характер.

Технология разработки программных продуктов

Значения проектных показателей определяют на основе анализа проектов ПС

(эскизного, технического, рабочего), а также путем испытания опытного образца ПС. Эти

показатели носят более объективный характер. Степень их достоверности зависит от

эффективности используемых инструментальных средств анализа и испытания.

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

изготовление ПС сводится к простому копированию. Если же копированию предшествуют

операции сборки или генерации ПС, то производственные показатели качества таких ПС

могут существенно отличаться от проектных.

Значения эксплуатационных показателей определяют по результатам

промышленной эксплуатации ПС. При соблюдении определенных правил сбора и

обработки данных о качестве ПС в процессе эксплуатации эксплуатационные показатели

дают наиболее объективную и достоверную оценку. Только по этим показателям можно

произвести действительную оценку научно-технического уровня и качества ПС.

Технология разработки программных продуктов

3. ОБЩИЕ ПОНЯТИЯ ОТЛАДКИ. ВИДЫ ОШИБОК.

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

исправления ошибок, после того, как ошибки были обнаружены в процессе тестирования.

Из всех этапов проектирования логики программных модулей этап отладки

является наименее формализованным. В нем выделяют две задачи:

 определение природы ошибки;

 исправление ошибки.

Решение первой из этих задач занимает около 95 % времени, затрачиваемых на

отладку. Поэтому любые средства ускорения процесса определения местоположения

ошибки в программ имеют важное значение.

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

называемые методы ‘грубой силы’. К ним относят:

 отладку с использованием дампа памяти;

 отладку с использованием операторов печати по всей программе;

 отладку с использованием автоматических средств.

Дампы памяти практически невозможно использовать при программировании на

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

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

Для системной расстановки нужны четкие представления о структуре алгоритма (схема

работы программы или блок-схема).Серьезным недостатком этого метода отладки

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

могут послужить дополнительным источником ошибок.

Использование автоматических средств отладки из этой группы методов наиболее

предпочтительно.

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

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

ними не применять более гибкие методы, к которым относятся:

 метод индукции;

 метод дедукции.

Название методов напоминают о криминалистике и не напрасно, ибо есть аналогия

между этими методами и расследованием преступления.

Метод индукции включает:

 определение данных тестирования, имеющих отношение к ошибке;

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

пункта 1);

 в результате анализа (п.2) выдвигается гипотеза о причине ошибки;

 для подтверждения гипотезы 3 разрабатывается один или больше тестов,

которые должны либо подтвердить, либо опровергнуть гипотезу;

 если дополнительные тесты подтверждают гипотезу, можно приступать к

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

случае возврат к п.3, а в худшем - к п.2.

Альтернативный метод дедукции заключается в:

 перечисление возможных причин или гипотез:

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

причин;

Технология разработки программных продуктов

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

использованием дополнительных тестов:

 доказательство выбранной гипотезы совпадает с п.4 и п.5 метода индукции.

4. ОБЩИЕ ПОНЯТИЯ ТЕСТИРОВАНИЯ. ВИДЫ ТЕСТИРОВАНИЯ

Тестирование (testing), как мы уже выяснили,—процесс выполнения программы

(или части программы) с намерением (или целью) найти ошибки.

Доказательство (proof) — попытка найти ошибки в программе безотносительно к

внешней для программы среде. Большинство методов доказательства предполагает

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

математических теорем о правильности программы. Доказательства могут

рассматриваться как форма тестирования, хотя они и не предполагают прямого

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

тестированию — взгляд во многом ошибочный; более подробно это обсуждается в гл. 17.

Контроль (verification) — попытка найти ошибки, выполняя программу в тестовой,

или моделируемой, среде.

Испытание (validation) — попытка найти ошибки, выполняя программу в

заданной реальной среде.

Аттестация (certification) — авторитетное подтверждение правильности

программы, аналогичное аттестации электротехнического оборудования Underwriters

Laboratories. При тестировании с целью аттестации выполняется сравнение с некоторым

заранее определенным стандартом.

Отладка (debugging) не является разновидностью тестирования. Хотя слова

“отладка” и “тестирование” часто используются как синонимы, под ними

подразумеваются разные виды деятельности. Тестирование — деятельность, направленная

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

ошибки, а затем — на исправление этой ошибки. Эти два вида деятельности связаны —

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

Тестирование модуля, или автономное тестирование (module testing, unit

testing) — контроль отдельного программного модуля, обычно в изолированной среде (т.

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

также математическое доказательство.

Тестирование сопряжении (integration testing) — контроль сопряжении между

частями системы (модулями, компонентами, подсистемами).

Тестирование внешних функций (external function testing) — контроль внешнего

поведения системы, определенного внешними спецификациями.

Комплексное тестирование (system testing) — контроль и/или испытание системы

по отношению к исходным целям. Комплексное тестирование является процессом

контроля, если оно выполняется в моделируемой среде, и процессом испытания, если

выполняется в среде реальной, жизненной.

Тестирование приемлемости (acceptance testing) — проверка соответствия

программы требованиям пользователя.

Тестирование настройки (installation testing) — проверка соответствия каждого

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

процессе настройки системы.

ВОСХОДЯЩЕЕ ТЕСТИРОВАНИЕ.

Технология разработки программных продуктов

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

модули самого нижнего уровня (“терминальные” модули; модули, не вызывающие других

модулей) тестируются изолированно, автономно. После того как тестирование этих

модулей завершено, вызов их должен быть так же надежен, как вызов встроенной

функции языка или оператор присваивания. Затем тестируются модули, непосредственно

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

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

повторяется до тех пор, пока не будет достигнута вершина. Здесь завершаются и

тестирование модулей, и тестирование сопряжении программы.

При восходящем тестировании для каждого модуля необходим драйвер: нужно

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

решении — написать для каждого модуля небольшую ведущую программу. Тестовые

данные представляются как “встроенные” непосредственно в эту программу переменные

и структуры данных, и она многократно вызывает тестируемый модуль, с каждым

вызовом передавая ему новые тестовые данные. Имеется и лучшее решение:

воспользоваться программой тестирования модулей — это инструмент тестирования,

позволяющий описывать тесты на специальном языке и избавляющий от необходимости

писать драйверы.

НИСХОДЯЩЕЕ ТЕСТИРОВАНИЕ.

Нисходящее тестирование (называемое также нисходящей разработкой не является

полной противоположностью восходящему, но в первом приближении может

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

тестируется сверху вниз. Изолировано тестируется только головной модуль. После того

как тестирование этого модуля завершено, с ним соединяются (например, редактором

связей) один за другим модули, непосредственно вызываемые им, и тестируется

полученная комбинация. Процесс повторяется до тех пор, пока не будут собраны и

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

При этом подходе немедленно возникает два вопроса: что делать, когда

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

еще не существует), и как подаются тестовые данные. Ответ на первый вопрос состоит в

том, что для имитации функций недостающих модулей программируются модули-

заглушки”, которые моделируют функции отсутствующих модулей. Фраза “просто

напишите заглушку” часто встречается в описании этого подхода, но она способна ввести

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

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

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

фиксированные выходные данные, которые она всегда и возвращает. Это иногда

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

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

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

пытается моделировать.

Интересен и второй вопрос: в какой форме готовятся тестовые данные и как они

передаются программе? Если бы головной модуль содержал все нужные операции ввода и

вывода, ответ был бы прост:

Тесты пишутся в виде обычных для пользователей внешних данных и передаются

программе через выделенные ей устройства ввода. Так, однако, случается редко. В

хорошо спроектированной программе физические операции ввода-вывода выполняются

на нижних уровнях структуры, поскольку физический ввод-вывод — абстракция довольно

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

модули добавляются не в строго нисходящей последовательности (все модули одного

Технология разработки программных продуктов

горизонтального уровня, затем модули следующего уровня), а таким образом, чтобы

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

Когда эта цель достигнута, нисходящее тестирование получает значительное

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

пользователя.

Остается еще один вопрос: в какой форме пишутся тесты до тех пор, пока не будет

достигнута эта цель? Ответ: они включаются в некоторые из заглушек.

Нисходящий метод имеет как достоинства, так и недостатки по сравнению с

восходящим. Самое значительное достоинство — в том, что этот метод совмещает

тестирование модуля, тестирование сопряжении и частично тестирование внешних

функций. С этим же связано другое его достоинство — когда модули ввода-вывода уже

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

том случае, когда есть сомнения относительно осуществимости программы в целом или

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

Преимуществом нисходящего подхода очень часто считают отсутствие

необходимости в драйверах; вместо драйверов вам просто следует написать “заглушки”.

Как читатель сейчас уже, вероятно, понимает, это преимущество спорно.

Нисходящий метод тестирования имеет, к сожалению, некоторые недостатки.

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

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

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

времени на их программирование, а вместо этого пишет простые заглушки и проверяет

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

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

тестирования определенно не лучшее решение, поскольку об отложенных условиях часто

забывают.

Второй тонкий недостаток нисходящего подхода состоит в том, что он может

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

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

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

Большинство опытных проектировщиков признает, что проектирование программы —

процесс итеративный. Редко первый проект оказывается совершенным. Нормальный

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

нижних уровней вернуться назад и подправить верхний уровень, внеся в него некоторые

усовершенствования или исправляя ошибки, либо иногда даже выбросить проект и начать

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

часть программы уже запрограммирована и оттестирована, то возникает серьезное

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

улучшений обычно можно сэкономить больше, чем те несколько дней или недель,

которые рассчитывает выиграть проектировщик, приступая к программированию

слишком рано.

Технология разработки программных продуктов

5. СТИЛЬ ПРОГРАММИРОВАНИЯ. ВИДЫ КОММЕНТАРИЕВ

Работая над программой, программист, особенно начинающий, должен хорошо

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

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

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

над проектом. Поэтому для того, чтобы работа была эффективной, программа должна

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

решаемой задачи. Как этого добиться? Надо следовать правилам хорошего стиля

программирования. Стиль программирования — это набор правил, которым следует

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

Очевидно, что хороший программист должен следовать правилам хорошего стиля.

Хороший стиль программирования предполагает:

 использование комментариев;

 использование несущих смысловую нагрузку имен переменных, процедур и

функций;

 использование отступов;

 использование пустых строк.

Следование правилам хорошего стиля программирования значительно уменьшает

вероятность появления ошибок на этапе набора текста, делает программу легко читаемой,

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

Четкого критерия оценки степени соответствия программы хорошему стилю

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

соответствует программа хорошему стилю или нет.

Сводить понятие стиля программирования только к правилам записи текста

программы было бы неверно. Стиль, которого придерживается программист, проявляется

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

дружественной по отношению к пользователю.

Надежность подразумевает, что программа, не полагаясь на "разумное" поведение

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

которые по какой-либо причине могут быть не выполнены, например, операций с

файлами.

Дружественность предполагает хорошо спроектированные диалоговые окна,

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

поведение программы.

Комментарии

Комментарии это часть текста программы, которая не обрабатывается при

компиляции исходного кода. Как правило, комментарии отделяются определенными

символами (эти символы называют символами комментария) от кода программы.

Основное назначение комментариев это пояснение текста программы на естественном

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

кода из обработки (например, при исправлении программы, можно сохранить код до

исправления, закомментировав его).

Комментарии можно разделить на два вида: