Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Основы разработки программного обеспечения на примере языка С. Учебное пособие для СПО
.pdf
спиральный цикл создания сложных систем. Она позволяет переходить
на следующий этап, не дожидаясь полного завершения работы за счёт
частичной реализации функциональности программного продукта. Тем
самым активизируется процесс уточнения и дополнения требований со
стороны пользователей системы.
Рис. 1.4. Спиральная модель ЖЦ разработки
1.4. Процессная модель
Стоит различать понятие модели жизненного цикла и жизненный цикл
конкретного программного продукта. Конкретный программный проект
обычно использует различные модели ЖЦ для различных компонент
программного продукта. Некоторые компоненты могут быть
заимствованы из предшествующих проектов или приобретены на рынке
ПО, другие проходят итерационный спиральный или каскадный ЖЦ. На
практике мы имеем дело со множеством параллельно протекающих
процессов разработки, каждый из которых может находиться в
состоянии, отличном от других (рис. 1.5
).
Так, первая компонента разрабатывается по классическому жизненному
циклу: требования, проектирование, реализация, интеграция. Вторая
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
21
компонента - по сокращенному жизненному циклу. Третья относится к
разряду приобретаемых или заимствованных компонент и потому
проходит интеграционные испытания сразу после определения к ней
требований.
Разработка четвертой компоненты явно определяется спиральным ЖЦ,
в рамках которого последовательно реализуется два прототипа. На
основании интеграционных исследований прототипов каждый раз
производится уточнение требований. На третьем витке спирали,
наконец, производится полномасштабное проектирование (создание
документов описания архитектуры системы) и реализация
окончательного варианта программной компоненты.
Применение процессной модели позволяет более точно отразить ход
программной разработки, подчеркивая тот факт, что программный
комплекс не однороден и содержит части, степень сложности которых
сильно различается. Какие-то функции системы реализовались уже не
один раз и могут использоваться практически без изменений в новых
проектах. Другие требуют проведения исследовательских работ,
многократного моделирования, оценки различных вариантов их
реализации.
В общем случае следует отличать ЖЦ разработки ПО, который
описывает именно процессы разработки, и ЖЦ самого ПО. В
жизненном цикле проекта (разработки) присутствуют такие этапы, как
формирование и обучение коллектива, закупка оборудования, создание
стендов отладки и тестирования. ЖЦ программного продукта
определяет, в свою очередь, процессы, связанные с
функционированием самой программы, такие как:
установка/настройка;
эксплуатация;
обновление;
резервное копирование;
временный останов;
вывод из обращения.
Таким образом, можно и нужно говорить и о таком понятии, как ЖЦ
проекта разработки ПО, который обычно на фазе инициализации
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
22
включает в себя и подписание контракта с заказчиком, приобретение
лицензий на инструментальное ПО, формирование среды
информационной поддержки проекта, подбор и обучение персонала и
т.п.
Рис. 1.5. Процессная модель разработки программного обеспечения
1.5. Формальные преобразования
Рассматривая разные подходы к процессу создания программного
обеспечения, нельзя не упомянуть о таком, как метод формальных
преобразований. Он заключается в автоматическом построении
программы на основе ее формального описания, что гарантирует
получение кода, который будет абсолютно точно соответствовать
исходной спецификации.
Формальные преобразования - это набор методов, позволяющих
математически корректно трансформировать исходные спецификации в
код целевой программной системы. Т.к. переход от требований к коду
происходит математически корректно, то проблема тестирования и
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
23
доказательства корректности конечной программы по отношению к
спецификации исчезает. Но верификация спецификаций по отношению
к требованиям к системе остается.
Очевидно, что этот метод требует наличия формальных спецификаций,
составление и доказательство корректности которых является
нетривиальной задачей. Именно поэтому метод формальных
преобразований редко используется для всего программного комплекса.
В большинстве случаев он применяется для той части сложной системы
и реализации тех алгоритмов, где исходные требования хорошо
формализуемы.
Вопросы и задачи для самостоятельного решения
Что включает в себя понятие ЖЦ разработки?
Что такое ЖЦ программы?
Имеет ли преимущества поэтапная модель ЖЦ разработки по
сравнению со спиральной? Если да, то какие?
Чем отличается процессная модель от поэтапной?
Какие основные этапы разработки программных систем вам
известны?
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
24
Основные элементы программной документации
Все приказы отдавайте устно. Не оставляйте записей и документов,
которые могут обернуться против вас.
Артур Блох
Технология создания ПО требует выполнить определенные работы,
связанные с составлением проектной документации. Новичкам часто
кажется, что написание спецификаций является не очень важной
частью процесса разработки или даже ненужной тратой времени.
Однако это не так, документация проекта содержит в себе все основные
мысли, решения, принятые в ходе бесконечных обсуждений,
договоренности и требования заказчика. Кроме того, четкая фиксация
информации помогает выявить неточности и противоречия, а также
определить ясную и четкую политику, которая может стать доступной
всему коллективу в документальном виде. Сама же документация
становится достаточно формальным описанием будущей системы и
позволяет впоследствии проводить верификацию.
2.1. Состав и взаимосвязи документов
В ходе каждого процесса (этапа) разработки формируется определенный
набор документов (выходные данные), которые являются входными
данными для следующих процессов (этапов). Практически каждый
документ базируется на ранее созданных документах и включает в себя
дополнительные уточнения описания конечного продукта или
связанных с его построением процессов.
В свое время Г. Майерсом [5
] была предложена модель разработки ПО
как модель трансляции одного описания программного продукта в
другое. Если встать на эту позицию, то надо предполагать, что
первичные требования заказчика - описание продукта на языке очень
высокого уровня. Коллектив разработчиков просто транслирует его
поэтапно, постепенно доводя это описание до уровня машинной
реализации. При этом, кроме формально исполняемых документов программ, создаются и другие документы - эксплуатационные. Часть из
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
25
них - инструкции по эксплуатации исполняют люди.
Таким образом, для процесса "Разработка требований" можно
определить следующий набор документов:
системные требования;
требования к ПО;
требования к аппаратному обеспечению;
требования к информационному обеспечению;
организационные требования.
Для процесса "Проектирование" характерны следующие документы:
описание модулей;
описание архитектуры моделей.
Процесс "Реализация" формирует на выходе код программы.
"Тестирование" включает в себя создание таких документов, как:
тест-требования;
тест-план;
отчет о тестировании (прогоне теста).
На рис. 2.1
приведены основные документы и результаты, получаемые в
ходе разработки ПО. Здесь рассматривается обобщенная модель и
обобщенные типы документов. Из соображений компактности
изображения названия закодированы латинскими буквами. В реальной
разработке их количество существенно больше, часто возникают
ситуации замены приведенных документов другими типами,
добавления новых видов документов или невыполнения части этапов
при разработке.
На начальном этапе формируется общее представление о потребностях
в будущем продукте и ставится задача разработки (SOW - Statement Of
Work). Это обычно и есть первичное описание необходимого продукта.
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
26
Рис. 2.1. Основные документы, создаваемые при разработке ПО
Далее идет разработка системных требований, т.е. требований ко всему
разрабатываемому изделию, детально определяющих все свойства
будущего продукта (SYS - System requirements). Далее обычно удается
определить, какую часть работы в системе будет выполнять аппаратура,
какую - программное обеспечение, а какую - человек.
Поэтому на основе SYS-документации составляются требования к ПО
(SRD - Software Requirements Document), которые детализируют все
требования SYS, относящиеся к программной части. Эти требования
также являются частью конечного продукта. Основная задача
требований к ПО - определить, что должна делать система, а не как она
это будет делать. Параллельно идет уточнение требований к аппаратной
части (HRD - Hardware Requirements Document) и разработка
организационных требований (ORD), включающих в себя описание
необходимых документов, и установление протокола взаимодействия
пользователей с программной системой.
На основе требований к ПО вся программная система разбивается на
набор функциональных областей, требования к каждой области
детализируются в документе, описывающем архитектуру программной
системы. Здесь же описываются интерфейсы функциональных
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
27
областей, и этот документ нужно рассматривать как часть конечного
продукта.
Каждая функциональная область делится на модули, которые в свою
очередь могут снова делиться на модули. Требования к модулю,
описание его работы и его интерфейсы приводятся в документе DDD
(Detailed Design Description), который также входит в состав конечного
продукта. Здесь уже можно определять, как должен работать модуль,
однако и тут степень детализации может быть разной, и часть
алгоритмических решений может быть оставлена кодировщику.
Под интерфейсом модуля (или функциональной области) понимаются
все функции, типы, константы и переменные, используемые для
взаимодействия модуля с другими модулями, т.е. все, что связывает
модуль с "внешним миром".
Таким образом, возможно отделение реализации модуля от "внешнего
мира". Для других модулей будет доступен только интерфейс, а про
реализацию они могут ничего не знать. Если реализация некоторого
объекта недоступна для других модулей, а доступ происходит лишь на
уровне экспортируемых модулем функций, то можно говорить об
абстрактном или скрытом типе. Использование абстрактных типов
упрощает разработку и повышает надежность общей системы.
На основе описаний модулей выполняется кодирование и интеграция
уже с использованием особенностей выбранного языка
программирования. Результат этого этапа - исполняемая программа
(загрузочный модуль), соответствующая требованиям к ПО.
После разработки кода программы начинается этап тестирования
(верификации), заключающийся в проверке соответствия поведения
кода отдельных модулей DDD-требованиям, собранных
функциональных областей - требованиям к функциональным областям
(FA - Functional Areas TEST), собранной в целом системе
функциональных областей - SRD-требованиям к ПО. Готовая система
тестируется совместно с аппаратной частью, определенной в HRD, и в
совокупности проверяется соответствие требованиям к системе SYS. На
каждом этапе формируются отчеты о тестировании (или отчеты о
прогоне тестов). Иногда такие отчеты могут составлять часть конечного
продукта или входить в состав документации, предоставляемой
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
28
сертифицирующему органу.
Необходимо заметить, что все этапы разработки не являются
независимыми, а наоборот, постоянно происходит "трансляция" одного
описания в другое - более детальное. При этом на каждом этапе
разработки требований идет проверка соответствия текущих
требований требованиям, уже определенным в предыдущем документе,
т.е. соответствие SYS - SRD, соответствие SRD архитектуре
программной системы и т.д. Часто ведется трассировка требований, т.е.
для любого требования последующего документа можно проследить
требование, из которого оно было определено в предшествующем
документе. При этом первичными требованиями является SYS.
Ф. Брукс [10
] дает следующую оценку трудоемкости для основных
этапов ЖЦ разработки ПО:
1/3 - планирование и разработка требований (R);
1/6 - архитектура и кодирование (D+C);
1/4 - тестирование модулей (I);
1/4 - системное тестирование (I).
Считая, что оба вида тестирования относятся к (I) интеграционному
процессу, получаем диаграмму распределения трудозатрат,
приведенную на рис. 2.2
Рис. 2.2. Распределение трудозатрат
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
29
Из приведенной оценки и необходимых для разработки системы
документов видно, что процесс кодирования является не самым
большим и не самым трудоемким этапом разработки ПО, однако
ключевым. Именно в ходе кодирования создается конечный продукт,
ради получения которого и проводятся все вышеописанные действия.
Отметим важное свойство программного текста - пишется один раз (на
этапе кодирования), а читается много раз как на всех последующих
этапах разработки, так и при внесении изменений в код. Поэтому
"читабельность" - важнейшая черта программного текста.
2.2. Спецификация (документирование) учебных задач
В случае несложной программы, модуля или функции всю
документацию можно объединить в общую спецификацию программы,
описывающую требования к ПО, его интерфейс, тест-требования и
некоторые другие аспекты.
Стоит отметить, что спецификация или ее отдельные разделы могут
проходить инспекции, дорабатываться, утверждаться, поэтому на работу
с этим документом накладываются различные ограничения. Как
минимум необходимо, чтобы в спецификации были указаны ее автор и
текущая версия. Для отслеживания всех действий рекомендуется вести
таблицу изменений, отмечать в ней, кто, когда, что и почему изменил, и
указывать номер новой версии. Пример таблицы изменений можно
увидеть в приложении Б.
Определение требований к решаемой задаче
Спецификация делится на разделы, соответствующие разным
документам при разработке ПО. Схема написания спецификации,
рекомендованной для данного учебного курса, полностью приведена в
приложении А.
Первый раздел - это краткое описание конечного продукта (аналог
SOW). Описание должно быть достаточно кратким, но давать четкое
понимание назначения продукта. Здесь же следует указывать язык
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
30
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]