ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9467
Скачиваний: 184
•
постановка
задачи
(
стадия
«
Техническое
задание
»);
•
анализ
требований
и
разработка
спецификаций
(
стадия
«
Эскизный
проект
»);
•
проектирование
(
стадия
«
Технический
проект
»);
•
реализация
(
стадия
«
Рабочий
проект
»).
Традиционно
разработка
также
включала
этап
сопровождения
(
началу
этого
этапа
соответствует
стадия
«
Внедрение
»
по
ГОСТ
).
Однако
по
международному
стандарту
в
соответствии
с
изменениями
,
произошедшими
в
индустрии
разработки
программного
обеспечения
,
этот
процесс
теперь
рассматривается
отдельно
.
Условность
выделения
этапов
связана
с
тем
,
что
на
любом
этапе
возможно
принятие
решений
,
которые
потребуют
пересмотра
решений
,
принятых
ранее
(
см
. § 1.5).
Постановка
задачи
.
В
процессе
постановки
задачи
четко
формулируют
назначение
программного
обеспечения
и
определяют
основные
требования
к
нему
.
Каждое
требование
представляет
собой
описание
необходимого
или
желаемого
свойства
программного
обеспечения
.
Различают
функциональные
требования
,
определяющие
функции
,
которые
должно
выполнять
разрабатываемое
программное
обеспечение
,
и
эксплуатационные
требовани
я
,
определяющие
особенности
его
функционирования
.
Требования
к
программному
обеспечению
,
имеющему
прототипы
,
обычно
определяют
по
аналогии
,
учитывая
структуру
и
характеристики
уже
существующего
программного
обеспечения
.
Для
формулирования
требований
к
программному
обеспечению
,
не
имеющему
аналогов
,
иногда
необходимо
провести
специальные
исследования
,
называемые
предпроектными
.
В
процессе
таких
исследований
определяют
разрешимость
задачи
,
возможно
,
разрабатывают
методы
ее
решения
(
если
они
новые
)
и
устанавливают
наиболее
существенные
характеристики
разрабатываемого
программного
обеспечения
.
Для
выполнения
предпроектных
исследований
,
как
правило
,
заключают
договор
на
выполнение
научно
-
исследовательских
работ
.
В
любом
случае
этап
постановки
задачи
заканчивается
разработкой
технического
задания
,
фиксирующего
принципиальные
требования
,
и
принятием
основных
проектных
решений
(
см
.
гл
. 3).
Анализ
требований
и
определение
спецификаций
.
Спецификациями
называют
точное
формализованное
описание
функций
и
ограничений
разрабатываемого
программного
обеспечения
.
Соответственно
различают
функциональные
и
эксплуатационные
спецификации
.
Совокупность
спецификаций
представляет
собой
общую
логическую
модель
проектируемого
про
-
граммного
обеспечения
.
Для
получения
спецификаций
выполняют
анализ
требований
технического
задания
,
формулируют
содержательную
постановку
задачи
,
выбирают
математический
аппарат
формализации
,
строят
модель
предметной
области
,
определяют
подзадачи
и
выбирают
или
разрабатывают
методы
их
решения
.
Часть
спецификаций
может
быть
определена
в
процессе
предпроектных
исследований
и
,
соответственно
,
зафиксирована
в
техническом
задании
.
На
этом
этапе
также
целесообразно
сформировать
тесты
для
поиска
ошибок
в
проектируемом
программном
обеспечении
,
обязательно
указав
ожидаемые
результаты
.
Проектирование
.
Основной
задачей
этого
этапа
является
определение
подробных
спецификаций
разрабатываемого
программного
обеспечения
.
Процесс
проектирования
сложного
программного
обеспечения
обычно
включает
:
•
проектирование
общей
структуры
-
определение
основных
компонентов
и
их
взаимосвязей
;
•
декомпозицию
компонентов
и
построение
структурных
иерархий
в
соответствии
с
рекомендациями
блочно
-
иерархического
подхода
;
•
проектирование
компонентов
.
Результатом
проектирования
является
детальная
модель
разрабатываемого
программного
обеспечения
вместе
со
спецификациями
его
компонентов
всех
уровней
.
Тип
модели
зависит
от
выбранного
подхода
(
структурный
,
объектный
или
компонентный
)
и
конкретной
технологии
проектирования
.
Однако
в
любом
случае
процесс
проектирования
охватывает
как
проектирование
программ
(
подпрограмм
)
и
определение
взаимосвязей
между
ними
,
так
и
проектирование
данных
,
с
которыми
взаимодействуют
эти
программы
или
подпрограммы
.
Принято
различать
также
два
аспекта
проектирования
:
•
логическое
проектирование
,
которое
включает
те
проектные
операции
,
которые
непосредственно
не
зависят
от
имеющихся
технических
и
программных
средств
,
составляющих
среду
функционирования
будущего
программного
продукта
;
•
физическое
проектирование
-
привязка
к
конкретным
техническим
и
программным
средствам
среды
функционирования
,
т
.
е
.
учет
ограничений
,
определенных
в
спецификациях
.
Реализация
.
Реализация
представляет
собой
процесс
поэтапного
написания
кодов
программы
на
выбранном
языке
программирования
(
кодирование
),
их
тестирование
и
отладку
.
Сопровождение
.
Сопровождение
-
это
процесс
создания
и
внедрения
новых
версий
программного
продукта
.
Причинами
выпуска
новых
версий
могут
служить
:
•
необходимость
исправления
ошибок
,
выявленных
в
процессе
эксплуатации
предыдущих
версий
;
•
необходимость
совершенствования
предыдущих
версий
,
например
,
улучшения
интерфейса
,
расширения
состава
выполняемых
функций
или
повышения
его
производительности
;
•
изменение
среды
функционирования
,
например
,
появление
новых
технических
средств
и
/
или
программных
продуктов
,
с
которыми
взаимодействует
сопровождаемое
программное
обеспечение
.
На
этом
этапе
в
программный
продукт
вносят
необходимые
изменения
,
которые
так
же
,
как
в
остальных
случаях
,
могут
потребовать
пересмотра
проектных
решений
,
принятых
на
любом
предыдущем
этапе
.
С
изменением
модели
жизненного
цикла
программного
обеспечения
(
см
.
далее
)
роль
этого
этапа
существенно
возросла
,
так
как
продукты
теперь
создаются
итерационно
:
сначала
выпускается
сравнительно
простая
версия
,
затем
следующая
с
большими
возможностями
,
затем
следующая
и
т
.
д
.
Именно
это
и
послужило
причиной
выделения
этапа
сопровождения
в
отдельный
процесс
жизненного
цикла
в
соответствии
с
стандартом
1SO/IEC 12207.
Рассматриваемый
стандарт
только
называет
и
определяет
процессы
жизненного
цикла
программного
обеспечения
,
не
конкретизируя
в
деталях
,
как
реализовывать
или
выполнять
действия
и
задачи
,
включенные
в
эти
процессы
.
Эти
вопросы
регламентируются
соответствующими
методами
,
методиками
и
т
.
п
.
Прежде
,
чем
перейти
к
подробному
рассмотрению
последних
,
проанализируем
эволюцию
схем
разработки
программного
обеспечения
от
момента
их
появления
до
настоящего
времени
.
1.5.
Эволюция
моделей
жизненного
цикла
программного
обеспечения
На
протяжении
последних
тридцати
лет
в
программировании
сменились
три
модели
жизненного
цикла
программного
обеспечения
;
каскадная
,
модель
с
промежуточным
контролем
и
спиральная
.
Каскадная
модель
.
Первоначально
(1970-1985
годы
)
была
предложена
и
использовалась
каскадная
схема
разработки
программного
обеспечения
(
рис
. 1.10),
которая
предполагала
,
что
переход
на
следующую
стадию
осуществляется
после
того
,
как
полностью
будут
завершены
проектные
операции
предыдущей
стадии
и
получены
все
исходные
данные
для
следующей
стадии
.
Достоинствами
такой
схемы
являются
:
•
получение
в
конце
каждой
стадии
законченного
набора
проектной
документации
,
отвечающего
требованиям
полноты
и
согласованности
;
•
простота
планирования
процесса
разработки
.
Именно
такую
схему
и
используют
обычно
при
блочно
-
иерархическом
подходе
к
разработке
сложных
технических
объектов
,
обеспечивая
очень
высокие
параметры
эффективности
разработки
.
Однако
данная
схема
оказалась
применимой
только
к
созданию
систем
,
для
которых
в
самом
начале
разработки
удавалось
точно
и
полно
сформулировать
все
требования
.
Это
умень
-
шало
вероятность
возникновения
в
процессе
разработки
проблем
,
связанных
с
принятием
неудачного
решения
на
предыдущих
стадиях
.
На
практике
такие
разработки
встречается
крайне
редко
.
Рис
. 1.10.
Каскадная
схема
разработки
программного
обеспечения
В
целом
необходимость
возвратов
на
предыдущие
стадии
обусловлена
следующими
причинами
:
•
неточные
спецификации
,
уточнение
которых
в
процессе
разработки
может
привести
к
необходимости
пересмотра
уже
принятых
решений
;
•
изменение
требований
заказчика
непосредственно
в
процессе
разработки
;
•
быстрое
моральное
устаревание
используемых
технических
и
программных
средств
;
•
отсутствие
удовлетворительных
средств
описания
разработки
на
стадиях
постановки
задачи
,
анализа
и
проектирования
.
Отказ
от
уточнения
(
изменения
)
спецификаций
приведет
к
тому
,
что
законченный
продукт
не
будет
удовлетворять
потребности
пользователей
.
При
отказе
от
учета
смены
оборудования
и
программной
среды
пользователь
получит
морально
устаревший
продукт
.
А
отказ
от
пересмотра
неудачных
проектных
решений
приводит
к
ухудшению
структуры
программного
продукта
и
,
соответственно
,
усложнит
,
растянет
по
времени
и
удорожит
процесс
его
создания
.
Реальный
процесс
разработки
,
таким
образом
,
носит
итерационный
характер
.
Модель
с
промежуточным
контролем
.
Схема
,
поддерживающая
итерационный
характер
процесса
разработки
,
была
названа
схемой
с
промежуточным
контролем
(
рис
. 1.11).
Контроль
,
который
выполняется
по
данной
схеме
после
завершения
каждого
этапа
,
позволяет
при
необходимости
вернуться
на
любой
уровень
и
внести
необходимые
изменения
.
Основная
опасность
использования
такой
схемы
связана
с
тем
,
что
разработка
никогда
не
будет
завершена
,
постоянно
находясь
в
состоянии
уточнения
и
усовершенствования
.
Рис
. 1.11
.
Схема
разработки
программного
обеспечения
с
промежуточным
контролем
Примечание
.
Народная
мудрость
в
подобных
случаях
говорит
«
лучшее
-
враг
хорошего
».
Осталось
только
понять
,
что
можно
считать
«
хорошим
»
и
как
все
-
таки
добиться
лучшего
...
Спиральная
модель
.
Для
преодоления
перечисленных
проблем
в
середине
80-
х
годов
XX
в
,
была
предложена
спиральная
схема
(
рис
. 1.12).
В
соответствии
с
данной
схемой
программное
обеспечение
создается
не
сразу
,
а
итерационно
с
использованием
метода
прототипирования
,
базирующегося
на
создании
прототипов
.
Именно
появление
прототипирования
привело
к
тому
,
что
процесс
модификации
программного
обеспечения
перестал
восприниматься
,
как
«
необходимое
зло
»,
а
стал
восприниматься
как
отдельный
важный
процесс
.
Прототипом
называют
действующий
программный
продукт
,
реализующий
отдельные
функции
и
внешние
интерфейсы
разрабатываемого
программного
обеспечения
.
На
первой
итерации
,
как
правило
,
специфицируют
,
проектируют
,
реализуют
и
тестируют
интерфейс
пользователя
.
На
второй
-
добавляют
некоторый
ограниченный
набор
функций
.
На
последующих
этапах
этот
набор
расширяют
,
наращивая
возможности
данного
продукта
.
Основным
достоинством
данной
схемы
является
то
,
что
,
начиная
с
некоторой
итерации
,
на
которой
обеспечена
определенная
функциональная
полнота
,
продукт
можно
предоставлять
пользователю
,
что
позволяет
:
•
сократить
время
до
появления
первых
версий
программного
продукта
;
•
заинтересовать
большое
количество
пользователей
,
обеспечивая
быстрое
продвижение
следующих
версий
продукта
на
рынке
;
•
ускорить
формирование
и
уточнение
спецификаций
за
счет
появления
практики
использования
продукта
;
•
уменьшить
вероятность
морального
устаревания
системы
за
время
разработки
.
Основной
проблемой
использования
спиральной
схемы
является
определение
моментов
перехода
на
следующие
стадии
.
Для
ее
решения
обычно
ограничивают
сроки
прохождения
каждой
стадии
,
основываясь
на
экспертных
оценках
.
Изменение
жизненного
цикла
программного
обеспечения
при
использовании
CASE-
технологий
.
CASE
-
технологии
представляют
собой
совокупность
методологий
анализа
,
проектирования
,
разработки
и
сопровождения
сложных
программных
систем
,
основанных
как
на
структурном
,
так
и
на
объектном
подходах
,
которые
поддерживаются
комплексом
взаимосвязан
-
ных
средств
автоматизации
.
В
основе
любой
CASE-
технологии
лежит
парадигма
методология
/
метод
/
нотация
/
средство
.
Методология
строится
на
базе
некоторого
подхода
и
определяет
шаги
работы
,
их
последовательность
,
а
также
правила
распределения
и
назначения
методов
.
Метод
определяет
способ
достижения
той
или
иной
цели
-
выполнение
шага
работы
.
Нотацией
называют
систему
обозначений
,
используемых
для
описания
некоторого
класса
моделей
.
Нотации
бывают
графические
(
предоставление
моделей
в
виде
графов
,
диаграмм
,
таблиц
,
схем
и
т
.
п
.)
и
текстовые
(
описания
моделей
на
формальных
и
естественных
языках
).
В
CASE-
технологиях
нотации
используют
для
описания
структуры
проектируемой
системы
,
эле
-
ментов
данных
,
этапов
обработки
и
т
.
п
.
Средства
-
инструментарий
для
поддержки
методов
:
средства
создания
и
редактирования
графического
проекта
,
организации
проекта
в
виде
иерархии
уровней
абстракции
,
а
также
проверки
соответствия
компонентов
разных
уровней
.
Различают
:
•
CASE-
средства
анализа
требований
,
проектирования
спецификаций
и
структуры
,
редактирования
интерфейсов
(
первое
поколение
CASE-I);
•
CASE-
средства
генерации
исходных
текстов
и
реализации
интегрированного
окружения
поддержки
полного
жизненного
цикла
разработки
программного
обеспечения
(
второе
поколение
CASE-II).
CASE-I
в
основном
включают
средства
для
поддержки
графических
моделей
,
проектирования
спецификаций
,
экранных
редакторов
и
словарей
данных
. CASE-II
отличается
существенно
большими
возможностями
,
обеспечивая
:
контроль
,
анализ
и
связывание
системной
информации
и
информации
по
управлению
процессом
проектирования
,
построение
прототипов
и
моделей
системы
,
тестирование
,
верификацию
и
анализ
сгенерированных
программ
.
Автоматизируя
трудоемкие
операции
,
современные
CASE-
средства
существенно
повышают
производительность
труда
программистов
и
улучшают
качество
создаваемого
программного
обеспечения
.
Они
:
•
обеспечивают
автоматизированный
контроль
совместимости
спецификаций
проекта
;
•
уменьшают
время
создания
прототипа
системы
;
•
ускоряют
процесс
проектирования
и
разработки
;
•
автоматизируют
формирование
проектной
документации
для
всех
этапов
жизненного
цикла
в
соответствии
с
современными
стандартами
;
•
частично
генерируют
коды
программ
для
различных
платформ
разработки
;
•
поддерживают
технологии
повторного
использования
компонентов
системы
;
•
обеспечивают
возможность
восстановления
проектной
документации
по
имеющимся
исходным
кодам
.
Появление
CASE-
технологий
изменило
все
этапы
жизненного
цикла
программного
обеспечения
,
при
этом
наибольшие
изменения
касаются
анализа
и
проектирования
,
которые
предполагают
строгое
и
наглядное
описание
разрабатываемого
программного
обеспечения
.
В
табл
. 1.1
показано
,
какие
качественные
изменения
процесса
разработки
программного
обеспечения
происходят
при
переходе
к
использованию
CASE-
средств
.
Использование
CASE-
средств
позволяет
существенно
снизить
трудозатраты
на
разработку
сложного
программного
обеспечения
{
табл
. 1.2 [30])
в
основном
за
счет
автоматизации
процессов
документирования
и
контроля
.
Однако
следует
иметь
в
виду
,
что
современные
CASE-
средства
дороги
,
а
их
использование
требует
более
высокой
квалификации
разработчиков
.
Следовательно
,
их
имеет
смысл
использовать
в
сложных
проектах
,
причем
,
чем
сложнее
разрабатываемое
программное
обеспечение
,
тем
больше
выигрыш
от
использования
CASE-
технологий
.
На
сегодняшний
день
практически
все
промышленно
производимое
сложное
программное
обеспечение
разрабатывается
с
использованием
CASE-
средств
.