МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
«Дальневосточный федеральный университет»
(ДВФУ)
ШКОЛА ЕСТЕСТВЕННЫХ НАУК
УЧЕБНО-МЕТОДИЧЕСКИЙ КОМПЛЕКС ДИСЦИПЛИНЫ
Технология разработки программного обеспечения
010503.65 Математическое обеспечение и администрирование информационных систем
Форма подготовки (очная)
Школа естественных наук
Кафедра прикладной математики,
механики, управления и программного обеспечения
курс __3_____ семестр ____5,6____
лекции __72_ (час.)
практические занятия___0____час.
семинарские занятия____0____час.
лабораторные работы___0____час.
консультации
всего часов аудиторной нагрузки____72____ (час.)
самостоятельная работа __72_______ (час.)
реферативные работы (количество) 0
контрольные работы (количество) 6
зачет ___________ семестр
экзамен____6______семестр
Учебно-методический комплекс составлен в соответствии с требованиями государственного
образовательного стандарта высшего профессионального образования № 72 мжд/ СП от 10 марта 2000 г.
Учебно-методический комплекс дисциплины обсужден на заседании кафедры прикладной математики,
механики, управления и программного обеспечения______________«__3__» _сентября___2012__г.
Заведующая (ий) кафедрой_________И.Л.Артемьева __________________________.
Составитель (ли):____ доцент________ Шалфеева Е.А._________________________
Аннотация учебно-методического комплекса дисциплины
«Технология разработки программного обеспечения»
Учебно-методический комплекс дисциплины «Технология разработки
программного обеспечения» разработан для студентов 3 курса по
направлению 010503.65 «Математическое обеспечение и администрирование
информационных систем» в соответствие с требованиями государственного
образовательного стандарта высшего профессионального образования № 72
мжд/ СП от 10 марта 2000 г.
Дисциплина «Технология разработки программного обеспечения входит
в обязательную часть СД цикла.
Общая трудоемкость освоения дисциплины составляет 144 часа.
Учебным планом предусмотрены лекционные занятия (72 часа), семинары (0
часов), самостоятельная работа студента (72 часа). Дисциплина реализуется на
3 курсе в 5,6 семестре.
Преподавание дисциплины ТРПО связано с другими дисциплинами
государственного образовательного стандарта, как общепрофессиональными:
«Математическая
логика»,
«Информатика»,
«Программирование»,
«Структуры и алгоритмы компьютерной обработки данных», - так и
специальными:
«Практикум
по
компьютерным
вычислениям»,
«Компьютерный практикум», «Базы данных и СУБД», "Человеко-машинный
интерфейс», - и опирается на их содержание. Материал дисциплины ТРПО
используется в преподавании других дисциплин общепрофессионального и
специального
циклов
учебного
плана
специальности:
«Системы
искусственного интеллекта», «Системы реального времени», «Метрология и
качество программного обеспечения», «Тестирование программного
обеспечения», «Интернет-технологии разработки ПО» и «Web-дизайн»,
«Диалоговое редактирование знаний и экспертные системы», «Коллективная
разработка программного обеспечения», а также при подготовке курсовых и
дипломных работ.
Дисциплина «Технология разработки программного обеспечения»
логически и содержательно связана с такими курсами, как как
общепрофессиональными: «Математическая логика», «Информатика»,
«Программирование», «Структуры и алгоритмы компьютерной обработки
данных», - так и специальными: «Практикум по компьютерным
вычислениям», «Компьютерный практикум», «Базы данных и СУБД»,
"Человеко-машинный интерфейс», - и опирается на их содержание. Материал
дисциплины ТРПО используется в преподавании других дисциплин
общепрофессионального и специального циклов учебного плана
2
специальности: «Системы искусственного интеллекта», «Системы реального
времени», «Метрология и качество программного обеспечения»,
«Тестирование
программного
обеспечения»,
«Интернет-технологии
разработки ПО» и «Web-дизайн», «Диалоговое редактирование знаний и
экспертные системы», «Коллективная разработка программного обеспечения»,
а также при подготовке курсовых и дипломных работ.
Учебно-методический комплекс включает в себя:
•
рабочую программу дисциплины;
•
конспекты лекций (на выбор автора: разбитые по темам полные
конспекты; краткие опорные конспекты; развернутый план лекции,
включающий проблемные вопросы; медиаматериалы по темам; видеолекции и
др. – указать конкретный вид представления лекционного материала);
•
материалы для организации самостоятельной работы студентов (полные
тексты заданий самостоятельной работы, методические указания по их
выполнению);
•
контрольно-измерительные материалы;
•
список литературы (в том числе интернет-ресурсов);
•
дополнительные материалы: учебники (электронные), образовательные
интернет-ресурсы и др.
Автор-составитель учебно-методического комплекса
к.т.н., доцент, доцент кафедры прикладной математики, механики, управления
и программного обеспечения Школы естественных наук ДВФУ
Шалфеева Е.А.
Зав.кафедрой прикладной математики, механики, управления и программного
обеспечения
_____И.Л.Артемьева_____
3
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
«Дальневосточный федеральный университет»
(ДВФУ)
ШКОЛА ЕСТЕСТВЕННЫХ НАУК
РАБОЧАЯ ПРОГРАММА УЧЕБНОЙ ДИСЦИПЛИНЫ (РПУД)
Технология разработки программного обеспечения
010503.65 Математическое обеспечение и администрирование информационных систем
Форма подготовки (очная)
Школа естественных наук
Кафедра прикладной математики,
механики, управления и программного обеспечения
курс __3_____ семестр ____5,6____
лекции __72_ (час.)
практические занятия___0____час.
семинарские занятия____0____час.
лабораторные работы___0____час.
консультации
всего часов аудиторной нагрузки____72____ (час.)
самостоятельная работа __72_______ (час.)
реферативные работы (количество) 0
контрольные работы (количество) 6
зачет ___________ семестр
экзамен____6______семестр
Рабочая программа составлена в соответствии с требованиями государственного образовательного стандарта
высшего профессионального образования № 72 мжд/ СП от 10 марта 2000 г.
Рабочая программа обсуждена на заседании кафедры прикладной математики, механики, управления и
программного обеспечения______________«__3__» _сентября___2012__г.
Заведующая (ий) кафедрой_________И.Л.Артемьева _______________
Составитель (ли):____ доцент________ Шалфеева Е.А._________________________
4
Оборотная сторона титульного листа РПУД
I. Рабочая программа пересмотрена на заседании кафедры:
Протокол от «_____» _________________ 200 г. № ______
Заведующий кафедрой _______________________ __________________
(подпись)
(И.О. Фамилия)
II. Рабочая программа пересмотрена на заседании кафедры:
Протокол от «_____» _________________ 200 г. № ______
Заведующий кафедрой _______________________ __________________
(подпись)
(И.О. Фамилия)
5
АННОТАЦИЯ
Преподавание дисциплины ТРПО связано с другими дисциплинами
государственного образовательного стандарта, как общепрофессиональными:
«Математическая
логика»,
«Информатика»,
«Программирование»,
«Структуры и алгоритмы компьютерной обработки данных», - так и
специальными:
«Практикум
по
компьютерным
вычислениям»,
«Компьютерный практикум», «Базы данных и СУБД», "Человеко-машинный
интерфейс», - и опирается на их содержание. Материал дисциплины ТРПО
используется в преподавании других дисциплин общепрофессионального и
специального
циклов
учебного
плана
специальности:
«Системы
искусственного интеллекта», «Системы реального времени», «Метрология и
качество программного обеспечения», «Тестирование программного
обеспечения», «Интернет-технологии разработки ПО» и «Web-дизайн»,
«Диалоговое редактирование знаний и экспертные системы», «Коллективная
разработка программного обеспечения», а также при подготовке курсовых и
дипломных работ.
Цель курса ориентация студентов в сущности такой области
народохозяйственной деятельности, как создание программного обеспечения
и вычислительных систем. В этом курсе обсуждаются модели процессов,
модели программного обеспечения и основы управления программным
проектом. Этот курс лекций рассматривает основные понятия технологии,
используемой создателями программного обеспечения ЭВМ, процессы
разработки ПС, порядок их прохождения, а также применение в этих
процессах методов и инструментальных средств разработки ПС. Разработка
программного
обеспечения
рассматривается
как
совокупность
производственных процессов, включающих множество разнообразных видов
деятельности и задач.
Условия подготовки студентов к первичному освоению дисциплины –
успешное изучение дисциплин «Информатика», «Программирование»,
«Структуры и алгоритмы компьютерной обработки данных», знакомство с
программированием в рамках спецкурсов, предполагающих практические и
лабораторные работы.
По завершению обучения по дисциплине студент должен:
обладать целостным представлением обо всех видах деятельности,
относящихся к разработке программного обеспечения и их связях между
собой;
иметь общее представление о процессах программного обеспечения;
ориентироваться в популярных подходах и методах, применяемых в
настоящее время в различных процессах программного обеспечения;
уметь анализировать и оценивать методы и средства технологий
программирования с точки зрения эффективности разработки и качества
создаваемой продукции.
6
Для текущего промежуточного контроля предусмотрено выполнение
творческих заданий по моделированию программного обеспечения и
вычислительных систем и проведение контрольных теоретических срезов по
основным темам; для итогового контроля предусмотрен письменный (или
устный) экзамен.
I. СТРУКТУРА И СОДЕРЖАНИЕ ТЕОРЕТИЧЕСКОЙ ЧАСТИ КУРСА
Лекционный материал (72 час.)
Тема 1. "Программные процессы" (10 час.)
Роль программного обеспечения. Возрастание роли технологии
программирования.
Программное обеспечение. Некоторые характеристики программного
обеспечения. Классификация приложений программного обеспечения.
Процессы, методы и средства технологии программирования.
Обобщенный взгляд на технологию программирования. Процессы
программного обеспечения.
Международный стандарт ISO/IEC 12207:1995.
Модели процессов программного обеспечения.
Линейная последовательная модель.
Модель прототипирования.
Методы четвертого поколения и другие модели разработки ПО.
Эволюционные модели программных процессов. Спиральная модель.
Модель с приращениями. Рациональный унифицированный процесс.
Модель зрелости процессов.
Тема 2. "Системная инженерия" (12 час.)
Вычислительная система. Цели и виды деятельности инженерии
требований к системе. Обзор технологии систем.
Моделирование потребности заказчика. Методы выявления требований.
Процесс анализа предметной области. Область анализа: повторное
использование, процесс анализа в области.
Модели архитектуры системы: стили, шаблоны. Разработка модели
системы в шаблоне «ввод-обработка-вывод».
Исследование реализуемости системы. Диаграммы размещения.
Спецификация системы. Экспертиза спецификации.
7
Тема 3. "Анализ требований к программному обеспечению" (14 час.)
Принципы анализа: информационная область, моделирование,
разделение на части, ракурсы видения основной информации и деталей
реализации.
Элементы модели анализа. Моделирование данных: объекты, свойства и
связи данных, словарь данных, диаграммы связей между объектами.
Функциональное моделирование и поток информации: Диаграммы
потоков данных.
Моделирование поведения. Диаграммы перехода состояний, таблицы
решений, схемы диалога с пользователем.
Выполнение структурного анализа: создание диаграммы связей между
объектами, модели потока данных, модели поведения.
Объектно-ориентированный (ОО) анализ: сравнение подходов. Базовые
компоненты модели ОО анализа. Процесс ОО анализа.
Специфицирование требований к программному обеспечению.
Экспертиза спецификации.
Выполнение ОО анализа. Модель связей между объектами. Модель
поведения объектов.
Тема 4. "Проектирование ПО" (14 час.)
Проектирование
программного
обеспечения
и
технология
программирования. Процесс проектирования: проектирование и качество
программного обеспечения, принципы проектирования.
Понятия проектирования: абстракция, уточнение, модульность,
сокрытие информации. ОО понятия: классы и объекты, атрибуты, методы,
сообщения, инкапсуляция, сокрытие информации, полиморфизм.
Эффективное
модульное
проектирование:
функциональная
независимость, связность модуля, сцепление модулей. Эвристики
проектирования для эффективный модульности.
Модель проекта. Проектирование данных.
Проектирование архитектуры. Виды архитектурных моделей.
Структурный
метод
архитектурного
проектирования,
Объектноориентированный метод.
Архитектурное проектирование: поток преобразований,
транзакции. Отображения транзакций: шаги проектирования.
поток
Проектирование интерфейсов: внешний и внутренний интерфейсы.
Проектирования человеко-машинного интерфейса. Рекомендации по
проектированию интерфейсов.
8
Процедурное проектирование: методы представления модулей. Процесс
проектирования объектов.
Проверка ОО моделей: проверка моделей анализа и проектирования,
согласованность моделей ОО анализа и проектирования. ОО метрики и
оценивание. Проектная документация.
Тема 5. "Испытания ПО" (12 час.)
Основы испытаний программного обеспечения: цели испытаний,
принципы испытаний. Стратегический подход к испытаниям программного
обеспечения.
Испытания черного ящика: разбиение по эквивалентности, анализ
граничных значений, испытания сравнением, методы испытаний, основанные
на графах.
Разработка тестов. Испытания белого ящика. Стратегии покрытия для
программных единиц, для их совокупности или целой программной
подсистемы.
Тестирование модулей: соображения об испытаниях модулей,
процедуры испытания модулей.
Испытания при объединении: объединение сверху-вниз, объединение
снизу-вверх, регрессионные испытания, документация испытаний при
объединении.
Испытания для подтверждения. Экспертиза конфигурации, Испытания
системы. Критерии для завершения испытаний.
Испытание документации и средств подсказки, подтверждение и
проверка правильности.
Стратегии ОО испытаний: испытания методов, испытания при
объединении, испытания для подтверждения. Разработка тестов для ОО
программ.
Методы испытаний, применимые на уровне классов. Проектирование
тестов для "межклассовых" испытаний.
Тема 6. " Управление проектами " (10 час.)
Процесс управления. Виды деятельности по управлению проектом.
Процесс управления в стандарте ISO/IEC 12207.
Спектр управления: люди, проблема, процесс.
Управление требованиями. Процесс управления конфигурацией.
Управление рисками: Ответная и профилактическая стратегии
управления рисками. Риски программного обеспечения. Идентификация
рисков, прогноз рисков, смягчение рисков.
9
Поддерживающие процессы ЖЦ. Обеспечение качества программных
средств.
Планирование процесса. Декомпозиция проблемы. Раскрытие проблемы
и процессов, декомпозиция процессов.
Меры, метрики и индикаторы, прямые и непрямые метрики.
II. КОНТРОЛЬ ДОСТИЖЕНИЯ ЦЕЛЕЙ КУРСА
Текущий контроль - контрольные работы
Тема 1.
Основные вопросы организации программных процессов.
Тема 2.
Основные вопросы системной инженерии.
Тема 3.
Основные вопросы анализа программного обеспечения.
Тема 4.
Основные вопросы проектирования программного обеспечения.
Тема 5.
Основные вопросы организации испытаний программного
обеспечения.
Тема 6.
Основные вопросы управления проектами и обеспечения качества
ПО.
Вопросы к экзамену
1. Программные продукты.
2. Обобщенный взгляд на технологию программирования.
3. Процессы программного обеспечения.
4. Международный стандарт ISO/IEC 12207:1995.
5. Модели процессов программного обеспечения.
6. Линейная последовательная модель. Модель прототипирования.
7. Эволюционные модели программных процессов. Спиральная модель.
8. Методы четвертого поколения и другие модели разработки ПО.
9. Модель зрелости процессов
10.Понятия управления программными проектами.
11.Метрики программных процессов и проектов.
12.Планирование программного проекта.
13.Управление рисками.
14.Системная инженерия. Цели и виды деятельности инженерии требований к
системе.
15.Компьютерная система. Основные элементы.
16. Процесс анализа предметной области. Область анализа: повторное
использование.
17.Методы идентификации потребностей. Моделирование потребности
заказчика.
10
18.Модели архитектуры системы: стили, шаблоны.
19.Разработка модели системы в шаблоне «ввод-обработка-вывод».
20.Анализ реализуемости. Диаграммы размещения.
21.Понятия и принципы анализа.
22.Моделирование при анализе.
23. Понятия и принципы проектирования.
24.Методы проектирования.
25.Объектно-ориентированные понятия и принципы.
26.Объектно-ориентированный анализ.
27.Объектно-ориентированное проектирование.
28.Проектирование интерфейсов: внешний и внутренний интерфейсы.
29.Процедурное проектирование: методы представления модулей.
30.Процесс проектирования объектов.
31.Проверка согласованности моделей ОО анализа и проектирования. ОО
метрики и оценивание.
32.Методы и стратегии испытаний программного обеспечения.
33.Разработка тестов. Испытания белого ящика. Испытания черного ящика.
34.Разбиение по эквивалентности, анализ граничных значений.
35.Тестирование модулей, процедуры испытания модулей.
36.Испытания при объединении.
37.Испытания для подтверждения. Испытания системы.
38.Стратегии ОО испытаний: испытания методов, испытания при
объединении, испытания для подтверждения.
39.Методы испытаний, применимые на уровне классов.
40.Проектирование тестов для "межклассовых" испытаний.
III. УЧЕБНО-МЕТОДИЧЕСКОЕ ОБЕСПЕЧЕНИЕ ДИСЦИПЛИНЫ
Основная литература 1. Гагарина Л.Г. Технология разработки программного обеспечения //
ИНФРА-М, 2008. - 400 с.
2. Лаврищева Е.М., Петрухин В.А. Методы и средства инженерии
программного обеспечения. – Учебник. Московский физико-технический
институт (государственный университет), 2006
3. Липаев, В.В. Программная инженерия. Методологические основы [Текст] :
Учеб. / В. В. Липаев ; Гос. ун-т — Высшая школа экономики. — М. : ТЕИС,
2006. — 608 с. (есть в библиотеке ДВФУ).
4. Соммервилл И. Инженерия программного обеспечения. 6-е издание. М.:
Изд. дом Вильямс, 2002. – 624 с. (есть в библиотеке ДВФУ)
11
Дополнительная литература
Тема «Модели процессов программного обеспечения»
Браудэ Э. Технология разработки программного обеспечения,
Издательский дом «Питер», 2004 год, 656 с. (в библиотеке ДВФУ: Ч/З
естественных наук, ауд 303, шифр Б 875 32.973)
Калайда В.Т., Романенко В.В. Технология разработки программного
обеспечения: Учебное пособие. — Томск: Томский межвузовский центр
дистанционного
образования,
2007.
—
257
с.
http://www.twirpx.com/file/812577/
Жоголев. Е. А. Технология программирования. Москва : Научный мир ,
2004. 215 c. (в библиотеке ДВФУ)
Тема «Специфицирование требований к программному обеспечению»
Вигерс К. И. Разработка требований к программному обеспечению (2е
издание). Издательство: Microsoft Press, Русская Редакция, 2004. - 576 с.
http://www.twirpx.com/file/1073166/
Тема «Архитектурное проектирование»
Орлов С.А. Технологии разработки программного обеспечения. СПб:
Питер, 2002. 464 с. (есть в библиотеке ДВФУ)
Тема «Процесс управления. Виды деятельности по управлению
проектом»
Фатрелл Р.Т., Шафер Д.Ф., Шафер Л.И. Управление программными
проектами: достижение оптимального качества при минимуме затрат. М:
Издательский дом “Вильямс”, 2003. http://www.twirpx.com/file/116119/
Интернет-ресурсы
1. http://www.twirpx.com/file/52048/ Брукс М. Как проектируются и создаются
программные комплексы. – М.: Символ-Плюс, 2004. – 304 с.
2. http://www.twirpx.com/file/5956/Соммервилл И. Инженерия программного
обеспечения. 6-е издание. М.: Изд. дом Вильямс, 2002. – 624 с.
3. http://log-in.ru/books/metody-i-sredstva-inzhenerii-programmnogoobespecheniya-uchebnoe-posobie-lavrisheva-e-m-petrukhin-v-a-programming/
Лаврищева Е.М., Петрухин В.А. Методы и средства инженерии
программного обеспечения. – Учебник. Московский физико-технический
институт (государственный университет), 2006
4. http://www.twirpx.com/file/40292/ Гагарина Л.Г. Технология разработки
программного обеспечения // ИНФРА-М, 2008. - 400 с.
12
http://www.twirpx.com/file/7349/ Липаев, В.В. Программная инженерия.
Методологические основы [Текст] : Учеб. / В. В. Липаев ; Гос. ун-т —
Высшая школа экономики. — М. : ТЕИС, 2006. — 608 с.
13
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
«Дальневосточный федеральный университет»
(ДВФУ)
ШКОЛА ЕСТЕСТВЕННЫХ НАУК
КОНСПЕКТЫ ЛЕКЦИЙ
по дисциплине «Технология разработки программного обеспечения»
010503.65 Математическое обеспечение и администрирование информационных систем
14
Конспект лекций
Процессы программного обеспечения
Технология программирования это – "инженерная дисциплина" с "инженерными подходами". В качестве
ее средств рассматриваются "стандарты, методологии, технологические программные средства, процессы,
методы организации, методы управления и системы обеспечения качества".
Инженеры применяют теоретические построения, методы и средства там, где это необходимо, делают это
выборочно и всегда пытаются найти решение задачи, даже если не существует подходящей теории или
методов. Кроме того они вынуждены работать в организационных и финансовых рамках.
Основной принцип, поддерживающий технологию программирования как инженерную дисциплину, это
фокусирование внимания на качестве. Любое применение технологии программирования, означает взятие
организацией-производителем обязательств по выпуску продукции "высокого" качества.
Основным результатом применения технологии является программа, действующая в заданной
вычислительной среде, хорошо отлаженная и документированная, доступная для понимания и развития в
процессе сопровождения.
Для того чтобы результатом некоего производственного процесса стал высококачественный программный
продукт, этот процесс нужно спланировать, оценить ресурсы, для чего, в свою очередь, нужны более или
менее точные спецификации, что же необходимо заказчику. Затем продукт надо спроектировать в виде
системы, состоящей из многих компонентов, описать функции этих компонентов и их связи между собой,
после чего компоненты нужно реализовать, автономно отладить, собрать вместе, провести комплексную
отладку, подготовить документацию на систему, обучить пользователей, провести опытную эксплуатацию и
организовать сопровождение системы на весь период её эксплуатации.
В литературе приводятся различные определения понятия технология программирования. Согласно
американскому стандарту ANSI/IEEE 610.12-1990:
"Технология программирования - это:
1)
Применение систематического, упорядоченного, поддающегося количественному определению
подхода для разработки программного обеспечения, работы с ним и его сопровождения, то есть,
применение инженерного дела к программному обеспечению;
Дисциплина, изучающая подходы (1)."
Подход, который принимается при создании конкретного программного средства, определяется
процессами программного обеспечения. Под процессом программного обеспечения понимается множество
взаимосвязанных видов деятельности разработчиков (этапов, шагов процесса), преобразующих получаемую
ими входную информацию в выходную. На каждом "шаге" разработки получают некоторую информацию
(представленную в различной форме: передаваемую устно, в виде документов, программ и т.д.) от
предыдущего шага и на ее основе создают выходную информацию (также представляемую в различной
форме).
Этап процесса (process) – набор действий, связанных между собой и решающих общую задачу (напр,
анализ требований, проектирование системной архитектуры). Действие (activity) - элементарная часть этапа
процесса, выполняется одним человеком или группой и не может быть разбито на более мелкие действия.
Каждая деятельность представляется набором инженерных рабочих задач.
Процессы программного обеспечения находятся в фокусе всеобщего внимания уже более десяти лет.
Технология программирования, кроме того, охватывает технологии, которые заполняют эти процессы:
технические методы и автоматические средства.
Процессы, методы и средства технологии программирования
Когда говорят, что технология программирования всегда реализуется послойно, имеют в виду, что
основание для технологии программирования - это слой процессов (processes). Следующий слой составляют
Методы (methods) технологии программирования. Они задают техническое описание того, "как сделать",
чтобы построить программное средство или его компонент.
Методы технологии программирования – это структурные решения, предназначенные для разработки ПО и
включающие моделирование и другие наглядные приемы: формализованную нотацию и правила
проектирования, а также способы управления процессом создания ПО. Эти методы представляют собой
структурный подход к созданию ПО, который способствует созданию высококачественного ПО эффективным
способом. Такой метод как структурный анализ связан с определением основных функциональных
компонентов. В 80-90-х годах добавились ОО методы (Буч и Рамбо), интегрированные сейчас в единый
унифицированный метод, построенный на основе унифицированного языка моделирования UML. Rational
Unified Process на сегодняшний день одна из самых известных методологий (или структурированная базу
знаний, в которую вошли методические рекомендации ведущих разработчиков по эффективному созданию
приложений и систем).
2)
15
Cредства (tools) технологии программирования используются в качестве основы методов ТП. Они
обеспечивают автоматическую или полуавтоматическую поддержку процессов и методов.
Когда средства объединены так, что информация, создаваемая одним из них, используется другим, то
говорят, что образована так называемая автоматизированная или поддерживаемая ЭВМ технология
программирования (computer-aided software engineering - CASE). CASE – программные системы,
предназначенные для автоматизации процесса создания ПО. CASE объединяет программы, аппаратуру и базу
данных технологии (архив, содержащий важную информацию об анализе, проектировании, конструировании
программ и испытаниях) для создания среды технологии.
Обобщенный взгляд на технологию программирования
Работа, связанная с технологией программирования, может быть рассмотрена как состоящая из трех
общих фаз, независимо от области приложения, размера проекта и сложности.
Фаза определения фокусирует внимание на том, что может быть передано словом какой (what). То есть, во
время определения разработчик программного средства пытается установить, какая информация должна
обрабатываться, какие функции и характеристики являются желательными, какое поведение системы
ожидается, какими будут интерфейсы, какие существуют ограничения, и какие критерии подтверждения
необходимы для определения успешности разработки системы.
Фаза разработки фокусирует свое внимание на вопросе как (how). То есть, во время разработки инженер
программного обеспечения пытается определить, как должны быть структурированы данные, как должны
быть реализованы функции в рамках архитектуры программного средства, как должны быть реализованы
процедурные детали, как должны быть представлены интерфейсы, как проект будет переводиться на язык
программирования (или непроцедурный язык), как будут осуществлены испытания. В фазе разработки могут
применяться различные методы, но всегда должны решаться следующие три технические задачи:
проектирование программного средства, генерация кода и испытания программного средства.
Фаза сопровождения фокусирует свое внимание на изменениях (changes), связанных с исправлениями
ошибок, адаптациями, необходимыми, когда развивается среда программного средства, и изменениях ввиду
модернизации программного средства из-за изменения требований заказчика. Все удачные ПП подвергаются
изменениям. Требования расширения функций исходит от пользователей, которые удовлетворены основным
назначением и изобретают для него новые применения. Удачный ПП живет дольше обычного срока
существования машины, для которой первоначально был создан. Приходят новые компьютеры или хотя бы
новые диски, мониторы, принтеры и программа должна быть согласована с возможностями новых машин.
Фаза сопровождения заново применяет шаги определения и разработки, но делает это в контексте уже
существующего программного средства.
Процессы программного обеспечения
Общая схема процессов (common process framework) устанавливается определением небольшого числа видов
деятельности схемы (framework activities), которые применимы ко всем проектам программного обеспечения,
независимо от их размера или сложности.
Множество задач (task sets), этапов проекта, программных рабочих продуктов и других компонентов
поставки (deliverables) и вопросов обеспечения качества - дает возможность подгонять виды деятельности
схемы под характеристики программного проекта и требования команды проекта.
Фазы и связанные с ними шаги, описанные в нашем общем взгляде на технологию программирования,
дополняются рядом охватывающих видов деятельности (umbrella activities). Типичными из них являются:
контроль программного проекта и управление им;
формальные технические экспертизы;
обеспечение качества программного средства;
управление конфигурацией программного средства;
подготовка и выпуск документации;
управление повторным использованием;
измерения;
управление рисками.
Охватывающие виды деятельности применяются во всех процессах программного обеспечения.
Международный стандарт ISO/IEC 12207:1995 Информационная технология – Процессы жизненного цикла
программного обеспечения группирует все возможные виды деятельности, выполняемые во время разработки
программного обеспечения, в три категории процессов: основные, поддерживающие и организационные. При
этом определяются пять основных процессов, восемь поддерживающих процессов и четыре организационных
процесса. Структура стандарта, задаваемая определенными в нем процессами, приведена на рис.2.1. Каждый
16
процесс жизненного цикла делится на набор видов деятельности. Каждый вид деятельности представляется
набором задач. Приводятся определения всех процессов этого стандарта.
Основные процессы (primary life cycle processes). Эти процессы реализуются главными участниками
жизненного цикла программного средства. Главный участник – это тот, кто инициирует или осуществляет
разработку, эксплуатацию или сопровождение программного обеспечения: покупатель, поставщик,
разработчик, оператор и специалист по сопровождению программных продуктов. Основные процессы – это:
1) процесс приобретения (acquisition). Он определяет действия покупателя, организации, которая
приобретает систему, программный продукт или программное обслуживание;
2) процесс поставки (supply). Определяет действия поставщика, организации, которая поставляет
систему, программный продукт или программное обслуживание покупателю;
3) процесс разработки (development). Определяет действия разработчика, организации, которая создает
модель программного продукта, а затем разрабатывает его;
4) процесс эксплуатации (operation). Определяет действия оператора, организации, которая
обеспечивает обслуживание функционирования компьютерной системы в ее жизненном окружении
для ее пользователей;
5) процесс сопровождения (maintenance). Определяет действия специалиста по сопровождению,
организации, которая осуществляет сопровождение программного продукта, т.е. управляет его
изменениями для того, чтобы поддерживать его текущее состояние и эксплуатационную пригодность.
Этот процесс включает в себя перенос программного продукта в другие среды и его изъятие из
эксплуатации.
Поддерживающие процессы жизненного цикла (supporting life cycle processes). Стандарт определяет восемь
таких процессов. Поддерживающий процесс поддерживает другой процесс как неделимую часть с
различными целями и вносит определенный вклад в успех и качество программного проекта (project).
Поддерживающий процесс запрашивается и выполняется, если это необходимо, другим процессом.
Поддерживающие процессы – это:
1) процесс документирования (documentation). Состоит из видов деятельности для записи информации,
вырабатываемой другими процессами;
2) процесс управления конфигурацией (configuration management). Определяет виды деятельности по
конфигурационному управлению;
3) процесс обеспечения качества (quality assurance) Определяет виды деятельности для объективного
гарантирования того, что программные продукты и процессы находятся в согласии со
специфицированными требованиями и придерживаются установленных планов. Совместная
экспертиза, проверки, проверка правильности (верификация) и подтверждение могут быть
использованы как методы обеспечения качества;
4) процесс проверки правильности (верификация) (verification). Определяет виды деятельности (для
получателя, поставщика или независимой стороны) для проверки правильности программных
продуктов на переменную глубину, зависящую от проекта; для проверки согласованности, полноты и
корректности между этапами ЖЦ;
5) процесс подтверждения (validation). Определяет виды деятельности (для получателя, поставщика или
независимой стороны) для подтверждения программных продуктов проекта программного
обеспечения; для гарантирования того, что осуществляемые процессы производят продукт,
соответствующий требованиям и критериям качества;
6) процесс совместной экспертизы (joint review). Определяет виды деятельности для оценивания
состояния и продуктов деятельности. Процесс подразумевает поиск возможных дефектов экспертами
или, как в случае формальных технических экспертиз, с помощью котнтрольных списков. Этот
процесс может быть задействован любой из двух сторон, когда одна сторона (оценивающая сторона)
оценивает другую сторону (оцениваемую сторону) на совместном обсуждении;
7) процесс проверки (audit). Определяет виды деятельности для определения согласованности с
требованиями, планами и контрактом как проводимых действий, так и рабочих продуктов;
соответствия документации стандартам, соблюдения графиков и стоимости работ. Обычно
проверяющая сторона – внешняя, независимая комиссия – проверяет программные продукты или
действия другой стороны (проверяемая сторона);
8) процесс разрешения проблем (problem resolution). Определяет процесс анализа и разрешения проблем
(включая несогласованности), какой бы не была их природа или источник. Проблемы
обнаруживаются при разработке, эксплуатации, сопровождении или в других процессах.
При этом совместная экспертиза, ревизия, проверка правильности и подтверждение могут использоваться
как методы обеспечения качества.
Организационные процессы (organizational life cycle processes). Они задействуются организацией для
17
установления и реализации основной структуры, полученной объединенными процессами жизненного цикла
и персонала, и для непрерывного улучшения этой структуры и процессов. Они обычно задействуются извне
сферы конкретных проектов или контрактов. Однако, уроки из таких проектов и контрактов вносят вклад в
улучшение организации. Организационные процессы – это:
1) процесс управления (management). Определяет основные виды деятельности управления, включая
управление проектом, на протяжении процесса жизненного цикла;
2) процесс установления инфраструктуры (infrastructure). Определяет основные виды деятельности для
установления основной структуры процесса жизненного цикла; The Infrastructure Process is a process to
establish and maintain the infrastructure needed for any other process. The infrastructure may include
hardware, software, tools, techniques, standards, and facilities for development, operation, or maintenance.
3) процесс улучшения (improvement). Определяет основные виды деятельности, которые организация
(т.е. получатель, поставщик, разработчик, оператор, специалист по сопровождению или управляющий
другого процесса) выполняет для установления, измерения, управления и улучшения ее процессов
жизненного цикла;
4) процесс обучения (training). Определяет виды деятельности для обеспечения адекватно обученного
персонала.
Жизненный цикл программного средства (ЖЦПС) - модель процессов программного обеспечения .схема, содержащая процессы, виды деятельности и задачи, связанные с разработкой, эксплуатацией и
сопровождением программного продукта, охватывающая жизнь системы, начиная с определения
требований к ней и до завершения ее использования.
Линейная последовательная модель
Рис.1 иллюстрирует линейную последовательную (linear sequential) модель технологии программирования,
называемую "классическим жизненным циклом" (classic life cycle). Работая по этой модели, коллектив
последовательно разрабатывает проект, начиная от исходной концепции до комплексного тестирования. Эта
линейная последовательная модель предлагает систематический подход к разработке программного
обеспечения, которая начинается на системном уровне и проходит через анализ, проектирование,
кодирование, испытания и сопровождение. Ее называли "водопадная" и "каскадной моделью" (waterfall
model), подчёркивая тот факт, что к предыдущей фазе проектирования вернуться невозможно. Эта линейная
последовательная модель охватывает следующие виды деятельности.
Технология создания
Анализ
систем
Проектирование
Кодирование
Испытания
Рис. 1. Линейная последовательная модель.
Системная/информационная инженерия и моделирование (system/information engineering and
modeling). Поскольку программное обеспечение обязано взаимодействовать с другими элементами системы,
такими как люди, оборудование и базы данных, т.е. программное обеспечение всегда является частью
большей системы (или бизнеса), работа начинается с установления требований ко всем элементам системы.
Прежде всего настолько скоpее, насколько это возможно, от заказчика или конечного пользователя узнают,
что система действительно должна делать, из чего она состоит и какова цель создания системы. Исходя из
этой цели устанавливаются требования к системе и каждому ее компоненту.
Затем подмножество требований к элементам системы назначается программному обеспечению.
Анализ требований к программному обеспечению. Процесс сбора требований усиливается и
сосредотачивается на программном обеспечении. Чтобы понять природу программ(-ы), которые(-ая)
должны(-а) быть разработаны(-а), программный инженер ("аналитик") обязан понимать информационную
область программного средства (Важно, чтобы данные, обpабатываемые в пpиложении, были выделены и
опpеделены в понятиях, достyпных как конечным пользователям, так и команде pазpаботчиков.), а также
необходимые функции, поведение, характеристики и взаимодействие с внешним миром. Требования как для
системы, так и для ее программного обеспечения документируются и затем проходят экспертизу у заказчика.
Проектирование. Проектирование программного средства в реальности многошаговый процесс, который
сосредотачивается на четырех различных свойствах программы: структуре данных, архитектуре программы,
представлениях интерфейсов и процедурных (алгоритмических) деталях. Процесс проектирования переводит
требования в такое представление программного средства, которое может быть оценено на качество до того,
как начнется генерация кода. Подобно требованиям, проект документируется и становится частью
конфигурации программного средства.
Генерация кода. Проект должен быть преобразован в интерпретируемую ЭВМ форму. Эту задачу решает
18
шаг генерации кода.
Проектная документация может и должна быть пеpедана команде пpогpаммистов, выполняющих
непосpедственное кодиpование, чтобы они могли записывать код согласно детализиpованномy пpоектy
задачи. Если проект реализован детально, генерация кода может осуществляться чисто механически. В
идеале, все потенциальные yзлы и ловyшки были пpедyсмотpены и обойдены. Если все из вышеописанных
шагов полностью пpойдены, то pеализация пpогpаммы значительно yпpощается.
Испытания. После того, как код сгенерирован, начинаются испытания программы.
Тестиpование может состоять из фаз:
испытания модулей (unit testing),
испытания при объединении,
испытания для подтверждения,
Опытная эксплyатация (испытания системы).
Испытания единиц программы (модулей) (unit testing) устанавливают правильность каждого модуля.
При тестировании модулей главным образом применяются методы испытаний белого ящика, исполняя
конкретные пути в структуре управления модуля, стараясь обеспечить полное покрытие и максимум
обнаружений ошибок.
В испытаниях при объединении (integration testing) основное внимание фокусируется на проекте, т.е.
устройстве программы. При этом решаются сразу две задачи: построение программы и ее подтверждение.
Методы создания тестов для черного ящика являются наиболее распространенными во время объединения,
хотя ограниченный объем испытаний белого ящика может использоваться для обеспечения покрытия
основных путей управления.
Испытания для подтверждения - испытания для выявления ошибок и обеспечения гарантии того, что
определенные входные данные будут давать результаты, которые соответствуют ожидаемым.
Лабоpатоpное тестиpование (Альфа-тестирование) продолжается до тех пор, пока разработчики и заказчик
не удостоверятся, что система полностью соответствует системным требованиям. Это этап процесса
тестирования, после которого система принимается к эксплуатации. Здесь система тестируется с
привлечением данных, предоставляемых заказчиком системы, а не на основе тестовых данных, как было на
предыдущем этапе.
Если система разрабатывается не на заказ, а для продажи на рынке, используется т.наз. бэта
тестиpование (опытная эксплyатация, промышленные испытания ПС) Бета тестиpование - это следyющая
фаза испытаний, пpи котоpой пpогpаммное обеспечение поставляется большому числу потенциальных
пользователей и заказчиков (огpаниченномy кpyгy конечных пользователей) для более жесткого
тестиpования. Хоpошо известно, что "пользователи" иногда использyют пpогpаммное обеспечение не
совсем для тех целей, для котоpых оно пpедназначалось. Поэтомy пользователи часто бyдyт находить
ошибки в тех местах пpогpаммы, где недели лабоpатоpных испытаний не нашли ничего. Этого необходимо
ожидать и не отpицать возможности возвpата к пpедыдyщей фазе - лабоpатоpномy тестиpованию.
Пользователи собирают информацию об особенностях поведения ПС и ее эксплуатационных
характеристиках и отсылают разработчикам отчеты о выявленных проблемах в эксплуатации.
Пpиемо–сдаточные испытания. Вообще, пpиемочный тест становится пpостой фоpмальностью, если
пpедыдyщие стадии тестиpования yспешно завеpшены. Во время приемо-сдаточных испытаний нет
необходимости проведения тестирование ПС в полном объеме (это может слишком дорого стоить).
Аттестационная комиссия должна, прежде всего, изучить предъявленную документацию по проведенному
разработчиками тестированию ПС и лишь выборочно пропустить предъявленные тесты. Дополнительные
тесты составляются, если у комиссии возникают определенные сомнения в полноте тестирования,
проведенного разработчиками. Кроме того, обычно работоспособность и некоторые показатели качества ПС
демонстрируются на решении контрольных задач, предъявляемых заказчиком.
Сопровождение. Программное обеспечение несомненно будет изменяться после того, как оно поставлено
заказчику (возможным исключением является встроенное программное обеспечение). Изменения будут
происходить ввиду обнаруженных ошибок, ввиду того, что конкретное программное средство должно быть
адаптировано к изменениям в его окружении (например, некоторое изменение необходимо ввиду новой
операционной системы или периферийного устройства) или ввиду того, что заказчик требует развития
функций или улучшения характеристик. Что делает сопровождение наиболее непpивлекательным, так это
плохо докyментиpованный код, недостаточно полное начальное пpоектиpование и отсyтствие внешней
докyментации. Если большинство шагов ЖЦРП выполнялись пpавильно, то сопpовождение не бyдет
вызывать сеpьезных пpоблем, а бyдет элементаpной технической поддеpжкой и модификацией пpогpаммного
обеспечения.
Модель прототипирования
Часто заказчик определяет множество общих целей для программного средства, но не идентифицирует
19
детально входные данные, их обработку или требования к выходным данным. В других случаях разработчик
может быть неуверен в эффективности алгоритмов, пригодности операционной системы или в форме,
которую должно бы иметь человеко-машинное взаимодействие. В этих и многих других ситуациях парадигма
прототипирования может предложить наилучший подход. Ключ к нему - определение правил игры с самого
начала, т.е. оба: заказчик и разработчик, должны согласиться, что прототип строится, чтобы служить
механизмом для определения требований.
Цель – поэтапное уточнение требований заказчика и, следовательно, получение законченной
спецификацции, определяющей разрабатываемую систему. С самого начала разработчики пытаются выделить
основные, существенные требования заказчика и реализовать только их в виде работающего прототипа
системы. ЛИБО Прототип строится для экспериментирования с той частью требований заказчика, которые
сформированы нечетко или с внутренними противоречиями.
Осуществляется "быстрое проектирование", которое фокусирует свое внимание на представлении тех
аспектов программного средства, которые будут видимы заказчику/пользователю (например, входная
информация и форматы выходных данных). Быстрое проектирование ведет к конструированию прототипа.
Этот прототип показывается заказчику, чтобы обсудить, правильно ли его поняли и четко сформулировать
требования, глядя на работу прототипа.
Другие линейные парадигмы разработки
Можно определить компьютерную технологию разработки ПС как технологию
программирования, в которой используются программные инструменты для разработки
формализованных спецификаций программ и других документов (включая и графические
спецификации) с последующей автоматической генерацией программ и документов (или хотя бы
значительной их части) по этим спецификациям.
Методы четвертого поколения (4GT) - это разработка с использованием CASE-средств,
позволяющих
разработчику,
«специфицировать
желаемый
результат
(желаемую
функциональность), а не действия, необходимые для достижения этого результата».
Поддерживающее ПС транслирует эти спецификации результата в машинно-исполняемую
программу.
Для разработки систем, которые должны удовлетворить строгим требованиям надежности,
безотказности и безопасности применима такая модель как «Методы формальных преобразований».
Спецификация системных требований имеет вид детализированной формальной спецификации,
записанной с помощью специальной математической нотации. Далее формальная спецификация
путем последовательных формальных преобразований трансформируется в исполняемую
программу.
Эволюционные модели программных процессов
Существует все возрастающее понимание того, что ПО, подобно всем сложным системам (20–30 чел–
лет?), развивается со временем. Требования к бизнесу и продуктам часто изменяются, когда происходит
разработка, что делает прямолинейный путь к концу продукта нереалистичным. В этих и подобных ситуациях
инженеры программного обеспечения нуждаются в эволюционной модели процессов. Такая модель является
итеративной, предполагает циклическое повторение практически всех фаз, постоянный возврат к
предыдущим фазам, и дает возможность программным инженерам разрабатывать все более сложные версии
программных средств.
Модель разработки приращениями
Устанавливайте приоритеты требований. Стесненные сроки могут помешать реализации всех требований.
Если применяется модель жизненного цикла с приращениями, должны быть идентифицированы те
требования, которые будут представлены в первом приращении.
На первых шагах разработки получают компоненты, удовлетворяющие
наиболее критическим
требованиям.
По завершении очередного шага разработки полученный компонент интегрируется с ранее
произведенными компонентами.
Спиральная модель
Спиральная модель объединяет итеративную природу прототипирования с управляемыми и
систематическими сторонами линейной последовательной модели. В ней разработка приложения выглядит
как серия последовательных итераций. При ранних итерациях уточняются спецификации продукта,
приращиваемый выпуск может быть моделью на бумаге или прототипом. При поздних итерациях
20
выпускаются все более увеличивающиеся по сложности версии сконструированной системы, добавляются
новые возможности и функции. В силу своей итеративной природы спиральная модель допускает
корректировки по ходу работы, что способствует улучшению продукта.
Спиральная модель делится на ряд видов деятельности, называемых также областями задач. Обычно
бывает от трех до шести ВД. Рис.2.3 представляет спиральную модель, которая содержит шесть видов
деятельности.
• Общение с заказчиком (customer communication) - задачи, необходимые для установления эффективного
общения разработчика и заказчика.
• Планирование (planning) - задачи, необходимые для определения ресурсов, сроков и другой, связанной с
проектом, информации.
• Анализ рисков (risk analysis) - задачи, необходимые для оценивания как технических рисков, так и рисков
менеджмента.
• Инженерия (engineering) - задачи, необходимые для построения одного или более представлений
приложения (спецификаций требований и проектов).
• Конструирование и выпуск (construction and release) - задачи, необходимые для построения, испытаний,
установки и обеспечения поддержки пользователя (например, документация и обучение).
• Оценивание заказчиком (customer evaluation) - задачи, необходимые для получения обратной связи с
заказчиком и основанные на оценивании представлений программного средства, созданных во время стадии
инженерии и реализованных во время стадии установки.
Планирование
Анализ
рисков
Общение
с заказчиком
Инженерия
Оценивание
заказчиком
Разработка
и выпуск
Рис.2. Типичная спиральная модель.
Одна из целей этой модели - как можно раньше выявить риски и уже в первых версиях продукта устранить
связанные с ним проблемы.
Проект разработки концепции начинается в ядре спирали и будет продолжаться (множество итераций
осуществляется вокруг пути спирали, которых ограничивает центральный область) до тех пор, пока
разработка концепции не будет завершена. Если эта концепция должна быть разработана в рамках реального
продукта, процесс продолжается до следующего витка (точка входа в проект разработки нового продукта), и
начинается новый проект разработки. Этот новый продукт будет эволюционировать, проходя через ряд
итераций вокруг спирали, следуя путем, который ограничивает следующую за ядром область. Подобный
поток процессов осуществляется для других типов проектов.
Rational Unified Process (RUP)
Процесс имеет четыре фазы:
Исследование (Inception)
Уточнение плана (Elaboration)
Построение (Construction)
Развертывание (Transition)
На каждой из фаз основное внимание уделяется разным процессам.
На фазе исследования идет сбор и анализ требований, выбирается часть ПО, которая будет
реализовываться;
на фазе уточнения плана - анализ требований и проектирование системы, исключение из проекта
элементов с наибольшим риском;
на фазе построения - разработка и кодирование, тестирование и отладка компонентов и сборка;
на фазе развертывания – приемочное тестирование (для подтверждения, опытная эксплуатация) и
распространение: передача пользователям или команде, которая будет «вести» следующую итерацию.
21
Методология RUP основана на 9-ти основных потоках (workflows):
Бизнес-анализ (анализ потребностей)
Сбор требований и управление требованиями (перевод требований в функциональные
спецификации)
Анализ и моделирование (перевод требований в программную модель)
Кодирование
Тестирование (проверка того, что программа соответствует требованиям)
Управление конфигурацией и изменениями (отслеживание изменений в разных
версиях продукта)
Управление проектом
Создание и поддержка среды разработки
Развертывание (все что нужно для продажи или передачи продукта).
Любой проект в RUP проходит четыре фазы. Через эти фазы проходят и все девять потоков. Каждая фаза в
свою очередь разбивается на итерации.
Методы четвертого поколения
Термин "методы четвертого поколения" ("forth generation techniques" - 4GT) охватывает широкий спектр
программных средств, которые имеют одно общее свойство: каждое из них дает возможность разработчику
определять некоторые характеристики программного средства на высоком уровне, на уровне, который близок
к естественному языку.
Методы четвертого поколения охватывают непроцедурные языки для запросов к базам данных и
формирования отчетов, генераторов программ и приложений, непроцедурные языки для манипулирования
данными, определения экранов, взаимодействия с ними, высокоуровневые графические возможности;
возможности электронных таблиц.
Первоначально многие их этих средств были доступны только для очень конкретных областей
приложения, но сегодня использование 4GT существенно расширилось, и является жизнеспособным
подходом для многих различных областей приложений.
Совмещенная со средствами автоматизированной технологии программирования (CASE) и генераторами
кода, 4GT предлагает заслуживающее доверия решение многих задач технологии программирования.
Формальные преобразования.
Спецификация системных требований имеет вид детализированной формальной спецификации,
записанной с помощью специальной математической нотации. Далее формальная спецификация путем
последовательных формальных преобразований трансформируется в исполняемую программу.
Методы формальных преобразований обычно применяют для разработки систем, которые должны
удовлетворить строгим требованиям надежности, безотказности и безопасности, т.к. они гарантируют
соответствие созданных систем их спецификациям.
Эти методы не нашли широкого применения, т.к. требуют специальных знаний и опыта использования.
Сборочное программирование – подход, который состоит в том, чтобы скорее собирать, чем разрабатывать
прототип или программу, используя множество существующих компонентов программного обеспечения.
Этот подход предполагает, что ПС конструируется, главным образом, из компонентов, которые уже
существуют.
В этом подходе начальный этап специфицирования требований и этап аттестации такие же, как в других
моделях, а этапы между ними имеют такой смысл:
Анализ компонентов – поиск компонентов, которые могли бы удовлетворять сформулированным
требованиям, обычно невозможно точно сопоставить функции готовых компонентов и требуемые функции.
Компонент ПО может быть структурой данных (или базой данных) или компонентом архитектуры
программного средства (т.е. программой) или процедурным компонентом (т.е. модулем).
Должно быть некоторое хранилище (библиотека) таких компонентов, каждая из которых может
многократно использоваться в разных ПС. Такие компоненты называются повторно используемыми
(reusable).
Модификация требований – анализируются требования с учетом информации о компонентах, полученной
на предыдущем этапе. Они модифицируются так, чтобы максимально использовать возможности отобранных
компонентов.
Проектирование – проектируется структура системы с учетом функциональных возможностей отобранных
готовых программных компонентов.
22
Разработка и сборка – скорее не отдельный этап, а часть разработки системы.
В каждом случае компонент программного обеспечения должен проектироваться так, чтобы дать ему
возможность быть повторноиспользуемым без детального знания его внутренней работы.
Модель зрелости процессов разработки (Capability Maturity Model for Software, SW CMM)
Модель SW CMM «описывает принципы и практические решения, определяющие уровень качества
процесса разработки ПО и призвана помочь организациям-производителям усовершенствовать процессы
разработки эволюционным путем, превратив их из хаотических процессов в процессы со строгой
дисциплиной». Согласно этой модели по некоторому множеству [потенциальных] возможностей
(capabilities) организации-разработчика можно судить о зрелости ее процессов. Сертификация организации на
зрелость ее процессов осуществляется с использованием специального вопросника и пяти-точечной схемы
классификации. Модель определяет уровни зрелости. Пять уровней зрелости схемы - эволюционные шаги,
формирующие основу для непрерывного усовершенствования процессов. (http://www.sei.cmu.edu).
Коротко пять этапов совершенствования CMM можно описать следующим образом.
1. Начальный. Процессы разработки программного обеспечения на этом уровне являются случайными
узкоспециализированными.
2. Повторяемый. Процесс достаточно очевидный, позволяющий организации повторно использовать
процедуры из более ранних, успешных проектов.
3. Определенный. Организация использует документированный, стандартный процесс управления и
конструирования программ во всех своих проектах как по разработке, так и по сопровождению
программного обеспечения.
4. Управляемый. Организация собирает, анализирует и регулирует детальные количественные
параметры качества как самого процесса разработки, так и итоговых продуктов.
5. Оптимизирующий. Главное на этом уровне - непрерывный процесс усовершенствования за счет
обратной связи, подтвержденной количественными параметрами, и контролируемого внедрения
новых идей и технологий.
Эти области аддитивны, т.е. зрелость процессов каждого уровня определяется по его собственным
ключевым областям и по ключевым областям всех предыдущих уровней. Определен порядок, в котором все
эти области ключевых процессов должны внедряться в организации, на каждом из уровней зрелости
процессов.
Уровень зрелости 2:
1)
управление системными требованиями (Цель – установить общее с заказчиком понимание
требований, которые будут реализовываться в ходе программного проекта);
2)
планирование программных проектов (Цель – создать обоснованные планы для выполнения
разработки ПО и управления программным проектом);
3)
контроль программных проектов и надзор за ними (Цель – обеспечить адекватное видение
реального прогресса, чтобы менеджеры могли принять необходимые меры в случае
значительного отклонения от планов);
4)
управление субконтрактами программного обеспечения (Цель – выбрать квалифицированных
субподрядчиков и эффективно управлять ими);
5)
обеспечение качества программных средств (Цель – обеспечить менеджеров соответствующим
видением используемых процессов и производимых продуктов);
6)
управление конфигурацией программного средства (Цель – создать и использовать единое
множество продуктов программного проекта в течение его выполнения);
Уровень зрелости 3:
7)
Интегральное управление разработкой ПО интегрированное управление ?сборкой системы
(ПО) (Цель –объединить виды деятельности по разработке в единый, установленный процесс,
адаптированный из стандартного процесса производства ПО в организации);
8)
межгрупповая координация деятельности (Цель – создать средства для активного
взаимодействия различных групп так, чтобы проект в большей степени удовлетворял
потребности заказчика);
9)
программа обучения (Цель – совершенствовать навыки и знания сотрудников так, чтобы они
могли эффективно исполнять свои обязанности);
10) Внедрение организационного процесса (Фокусирование организации на процессе) сосредоточение внимания на процессах организации (Цель – установить в организации
23
ответственность за действия в рамках программного процесса, которые повысят возможности
общего процесса производства ПО в организации).
11) Формализация организационного процесса (Определение процесса в организации) (Цель –
разработать и эксплуатировать пригодное для использования множество деятельностей
(процессных активов), которое обеспечит основу для долговременной пользы для организации);
12) технология программных продуктов (Проектирование программного продукта) (Цель –
соответствующим образом выполнять хорошо определенный процесс разработки, который
объединяет все виды деятельности по разработке ПО для эффективного производства хороших
ПП);
13) экспертиза с привлечением специалистов (peer reviews - Экспертная оценка) (Цель – удалять
дефекты из рабочих продуктов как можно раньше и эффективнее, улучшать понимание рабочих
продуктов и их дефектов, которые можно предотвратить);
Уровень зрелости 4:
14) управление качеством программных средств (Цель – установить количественное понимание
качества ПП и достичь определенных целей качества);
15) количественное управление процессами (Цель – количественно управлять выполнением
программного процесса в проекте).
Уровень зрелости 5:
16) управление изменениями в процессах (Цель – непрерывно улучшать процесс производства ПО в
организации с целью повышения качества, производительности, и уменьшения времени.
затрачиваемого на разработку продуктов);
17) управление изменениями в технологиях (Цель – обнаруживать новые технологии (средства,
методы, процессы) и последовательно отслеживать их в организации);
18) предотвращение дефектов (Цель – определить причины дефектов и предотвратить их повторное
появление).
24
Инженерия требований к системе
Процесс разработки в соответствии с ISO\IEC 12207 состоит из ВД и задач разработчика: анализа
требований, проектирования, кодирования, комплексирования, испытаний, установки и приемки,
относящимся к ПП. Он также содержит ВД, относящиеся к системе, если это обусловлено
контрактом. И эти ВД в ISO\IEC 12207 – анализ требований к системе и их специфицирование и
проектирование архитектуры системы.
Целью создания системы может быть поддержка некоторой функции бизнеса или разработка
продукта, который должен быть продан для получения коммерческого дохода.
Технология создания систем охватывает процессы создания спец-й, проектирования,
разработки, тестирования, внедрения и сопровождения систем как единого целого.
«Системотехник» должен не только думать о функциях, которые выполняет система, но и
взаимодействии системы с ее окружением. Специалист по ПО должен понимать задачи
«системотехники», поскольку возникающие проблемы часто являются результатом решений,
принятых системотехниками.
Проблемы, которые призваны решить разработчики ПО часто чрезвычайно сложны. Понимание
их природы может быть очень сложным, поэтому трудно установить точно, что система, основанная
на использовании ЭВМ (computer-based systems), называемая для краткости просто
вычислительными системами, должна делать.
Система – совокупность взаимодействующих компонентов, работающих совместно для
достижения определенных целей.
Вычислительная система – “Множество или распределение элементов, которые
организуются для осуществления некоторой предопределенной цели посредством переработки
информации.”
Для достижения цели вычислительная система использует ряд типов элементов системы:
Программное обеспечение (software). Компьютерные программы, структуры данных и связанная
с ними документация, которые служат для осуществления требующегося логического метода,
процедуры или управления.
Аппаратура (hardware). Электронные приборы, которые представляют вычислительные
мощности, и электромеханические приборы (например, датчики, моторы, насосы), которые
обеспечивают функции внешнего мира.
Люди (people). Пользователи и операторы программного обеспечения и аппаратуры.
База данных (database). Большая организованная совокупность информации, доступная
посредством программного обеспечения.
Документация (documentation). Руководства, help–средства и другая информация, которая
описывает использование и/или работу системы.
Процедуры (procedures). Шаги, которые определяют конкретное использование каждого
элемента системы или процедурный контекст, в котором "живет" система.
Процесс установления услуг, которые должна обеспечить вычислительная система, и
ограничений, с которыми она должна функционировать, называется инженерия требований к
системе.
Инженерия требований выполняется со следующими целями: (1) идентифицировать
потребности заказчика; (2) оценить концепцию системы на осуществимость; (3) пытается ввести
программное обеспечение в его окружение (контекст), чтобы точно определить роль программного
25
обеспечения ЭВМ в некотором контексте и установить связи программного обеспечения с другими
частями вычислительной системы; (4) выполнить экономический и технический анализ; (5)
распределить функции между аппаратурой, программным обеспечением, людьми, базой данных и
другими элементами системы; (5) установить ограничения по стоимости и графика работы; (6)
создать определение системы, которое формирует основу для всей последующей технологической
работы.
Процесс инженерии требований имеет следующие принципиальные этапы:
Идентификация потребности и анализ требований – выведение требований к системе через
анализ существующих систем, анализ планирующегося использования создаваемой
системы и обсуждение с заказчиком и потенциальными пользователями и поставщиками
для определения требований к ней. Sommerv (с 92): Заказчик системы должен работать с
аналитиком, чтобы различий между того, ЧТО есть система, и ЧТО есть окружение
системы, и идентифицирование сферы рассмотрения. Могут быть разработаны несколько
различных моделей систем.
Спецификация требований (создание документа описание концепции системы)– подробное и
точное описание требований к системе, которое станет основой для контракта.
Спецификации требований к системе должны быть представлены в форме документа.
Исследование реализуемости, исследование осуществимости (целесообразности) – могут ли
нужды пользователя быть удовлетворены существующими технологиями и в
существующих бюджетных ограничениях.
Проектирование архитектуры системы – установление высокоуровневой архитектуры
системы, идентифицирующей конкретные оборудование, ПО, “данные” (или базы данных)
и “людей”, Построить такую модель этих требований, в которой все требования к системе
распределены между этими компонентами вычислительной системы. Компоненты
конфигурации оборудования, компоненты конфигурации ПО и ручные операции
последовательно идентифицируются из этих компонентов. Архитектура системы и
системные требования, определенные для этих компонентов должны документироваться.
Разработка модели архитектуры системы
В процессе формализации требований к системе и на этапе проектирования система рассматривается как
совокупность компонентов и взаимосвязей между ними.
В общем случае следует попытаться разложить систему на части так, чтобы архитектура была как
можно проще (не более 7 основных объектов).
Для графического представления всей организации системы используются модели системной
архитектуры. Блоки обычно соответствуют основным подсистемам или компонентам, а связи обычно
соответствуют потокам данных. Каждая подсистема может быть представлена как декомпозиция своих
функциональных компонентов (обычно выполняющих одну функцию). Обычно, выделяя подсистему,
акцентируют внимание на выполняемых функциях, а позже решается вопрос, будет ли она реализована
аппаратно или программно (на основе таких факторов как время, наличие на рынке подходящих готовых
устройств).
Технология систем предусматривает единый подход к разработке моделей системы и ее
компонентов в форме преобразования информации с использованием архитектуры “вводобработка-вывод”, либо дополненного обработкой взаимодействия с пользователем и
техническим обслуживанием и выполнением самопроверки.
Для разработки такой модели системы используется шаблон архитектуры (architecture
template). Разработчик системы назначает элементы системы каждой из пяти областей в шаблоне:
26
(1) интерфейсу с пользователем, (2) вводу, (3) функции и управлению системы, (4) выходу и (5)
техническому обслуживанию (maintanance) и самопроверке (self–testing) (диагностический
интерфейс). Формат шаблона архитектуры показан рис.3.
Обработка интерфейса с пользователем
Обработка
входа
Функции
обработки и
управления
Обработка
выхода
Техническое
обслуживание и
самопроверка
Рис.3. Шаблон архитектуры [Pressman-97].
Подобно почти всем методам построения моделей, используемым в технологиях систем и
программирования, шаблон архитектуры позволяет аналитику создавать иерархию деталей.
Архитектурная контекстная диаграмма (architecture context diagram) (АКД) располагается на
верхнем уровне иерархии.
Архитектурная контекстная диаграмма устанавливает информационную границу между системой и
средой, в которой эта система должна работать. То есть, АКД определяет всех внешних производителей
информации, используемой системой, всех внешних потребителей информации, создаваемой системой, и
все объекты и явления, которые связаны через интерфейс или выполняют техническое обслуживание и
самопроверку.
Понятия и принципы анализа
Не имеет никакого значения, насколько хорошо спроектирована или закодирована программа, если плохо
проведен анализ требований к ней и плохи ее спецификации. Она не будет удовлетворять пользователя и
принесет огорчения разработчику.
Задача анализа требований является процессом осознания, уточнения, моделирования и
специфицирования. При этом уточняются детали сферы рассмотрения, первоначально
установленной разработчиком системы и уточненной при планировании программного проекта.
Анализ требований позволяет аналитику (analyst) уточнить его назначение и построить модели
областей данных, функций и эксплуатационных характеристик, которые будут представлены в нем.
И разработчик, и заказчик играют активную роль в анализе требований и специфицировании.
Принципы анализа и специфицирований требований
1. Необходимо понять проблему до начала создания модели анализа. Существует тенденция
спешить с решением еще до того, как проблема понята. Это часто ведет к элегантному
программному средству, которое решает совсем другую проблему!
2. Создаваемая модель должна быть познавательной, описывает систему так, как ее видят ее
пользователи. Это значит, что в модели должны быть представлены объекты прикладной области и
люди, в ней работающие. Спецификация должна позволить понять, как будет реагировать система
на события в прикладной области в терминах этой области.
3. Необходимо определение среды, в которой работает система, и указание того, как реагирует
система на события в среде. Другими словами, должна существовать не только спецификация
системы, но и спецификация среды (что касается ее взаимодействия с системой).
27
4. Должен описываться контекст, в котором работает программное обеспечение, путем
определения его взаимодействия с другими компонентами системы. Другими словами,
спецификация должна охватывать не только программное обеспечение, но и те компоненты
системы, с которыми оно взаимодействует.
5. Необходимо использовать три различных видения требований. Это уменьшает вероятность
пропустить чего-нибудь, и увеличивает вероятность обнаружения противоречий.
А. Должны быть понята и представлена информационная область проблемы.
Б. Должны быть определены функции, которые должно выполнять программное
обеспечение \ система.
В. Должно быть представлено желаемое поведение программного обеспечения \ системы,
описывающее информационную и функциональную реакцию системы на различные
“раздражители” из ее окружения (среды).
6. Модели, которые описывают информацию, функции и поведение должны быть разбиты на
части так, чтобы послойно раскрыть детали.
7. Процесс анализа должен двигаться от самой важной информации к деталям реализации.
8. Спецификация должна быть терпима к неполноте и быть расширяемой. Любая спецификация
– это всегда модель, т.е. абстракция некоторой реальной (или воображаемой) ситуации, которая,
обычно, очень сложна. Поэтому она всегда неполна и может существовать на нескольких уровнях
детализации.
9. Записывайте источник и причину каждого требования. Это будет первым шагом в
установлении прослеживаемости к заказчику.
10. Устанавливайте приоритеты требований. Стесненные сроки могут помешать реализации
всех требований. Если применяется модель жизненного цикла с приращениями, должны быть
идентифицированы те требования, которые будут представлены в первом приращении.
Методы, облегчающие специфицирования приложений
Между заказчиками и разработчиками программных средств часто возникает недопонимание. Сyществyет
огpомная пpопасть междy идеями пользователей и пpедставлением о возможных способах pеализации этих
идей конкpетными pазpаботчиками. Связь является здесь ключевым элементом. Hо даже самая хоpошая связь
междy пользователями и пpогpаммистами не всегда является залогом понимания. Часто опускается важная
информация, и не устанавливаются успешные рабочие связи.
Для избежания этих проблем разработан ориентированный на бригадную работу подход по
сбору требований, который применим на ранних стадиях анализа и специфицирования. Этот
подход, называемый методами, облегчающими специфицирование приложений (facilitated
application specification techniques - FAST), предполагает создание объединенной бригады
заказчиков и разработчиков, которые работают вместе, чтобы идентифицировать проблему,
предложить элементы ее решения, договориться о различных подходах и предварительно
специфицировать требования к решению.
После завершения предварительных совещаний и заказчик, и разработчик пишут одно-двухстраничную “заявку на продукт” (product request). Заявки на продукт рассылаются всем участникам
совещания до даты его начала.Эти заявки рассматриваются в течение нескольких дней до
совещания.
С началом совещания первой темой обсуждения является потребность и обоснование для нового
продукта: каждый должен согласиться с тем, что разработка (или приобретение) продукта
обоснована. После того, как такое согласие установлено единогласно, каждый участник
28
представляет для обсуждения списки объектов, услуг и ограничений будущего продукта, которые
он составлял при рассмотрении заявки.
Анализ тpебований заказчика.
Анализ требований позволяет специфицировать функции и эксплуатационные характеристики ее
программного обеспечения, указать его интерфейс с другими частями системы и установить ограничения,
которым оно должно удовлетворять.
Анализ требований может быть разделен на пять областей приложения усилий: (1) осознание
проблемы; (2) оценивание проблемы и моделирование; (3) специфицирование и (4) экспертизу.
Сначала аналитик изучает спецификацию системы (system specification) и план проекта
программного обеспечения (software project plan). Целостное понимание требований к
программному обеспечению является существенным для успеха в его разработке. Важно понять
программное обеспечение в контексте всей системы и провести экспертизу сферы рассмотрения
программного обеспечения, которая использовалась для количественных оценок при
планировании.
Возможно, для этого понадобится дополнительно выяснить, что же пользователи хотят полyчить
от пpогpаммного пpодyкта. Это может быть интеpактивный пpоцесс.
Каждый участник Fast–бригады должен приготовить список объектов (objects), которые
являются частью среды, окружающей систему, генерируются системой и используются системой
для выполнения ее функций.
Программное обеспечение разрабатывается для обработки данных (data), для преобразования
данных из одной формы в другую, т.е., приема входных данных, их обработки некоторым образом
и генерации выходных данных. Однако, важно отметить, что программное обеспечение также
обрабатывает и события (events). Событие представляет собой одну из сторон управления
системой и является не чем иным, как булевыми данными – оно либо включено, либо выключено;
либо верно, либо нет; есть или нет. Поэтому и данные (числа, символы, изображения, звуки и т.д.),
и управление (события) одинаково свойственны области информации (information domain).
После того, как созданы эти списки, бригада делится на подбригады, каждая из которых должна
разработать мини-спецификаций (mini-specification) для одного или нескольких пунктов из каждого
списка. Мини-спецификации являются уточнениями слов или фраз, содержащихся в списке.
После того, как мини-спецификации завершены, каждый участник FAST-совещаний готовит
список критериев подтверждения для продуктов/системы и представляет свой список бригаде.
Затем создается поддержанный всеми список критериев подтверждения.
FAST не являются панацеей для проблем, с которыми сталкиваются при раннем сборе
требований, но этот бригадный подход имеет важные достоинства: учет многих точек зрения,
мгновенные обсуждения и уточнения, а также конкретный шаг по направлению к разработке
спецификаций.
Один или более участников (или кто-то со стороны) получает задачу написания проекта полных
спецификаций, используя всею информацию FAST-совещаний.
Один из принципов анализа требует изучения области информации. Она содержит три
различных видения данных и управления при их обработке программой ЭВМ: (1) содержание
информации и взаимосвязи; (2) поток информации и (3) структура информации. Чтобы полностью
понять область информации, должна быть рассмотрена каждое из этих видений.
Содержание информации (information content) – это сами отдельные данные и объекты
управления, заключающие в себе информацию, преобразуемую программным обеспечением.
29
Объекты данных и управления могут соотноситься с другими объектами данных или управлений. Во
время анализа области информации эти связи должны быть выявлены.
Поток информации (information flow) представляет способ, которым изменяются данные и
управление при их движении через систему. Входные объекты преобразуются в промежуточную
информацию (данные и/или управление), которые в дальнейшем преобразуются в выходную.
Вдоль этого пути (или путей) информации может вводиться другая информация из существующих
хранилищ данных (data store) (например, файл на диске). Преобразования, применяемые к
данным, являются функциями или подфункциями, которые должна выполнять программа. Данные
и управление, перемещаемые между двумя преобразованиями (функциями) определяют
интерфейс для каждой из функций.
Структура информации (information structure) представляет внутреннюю организацию
элементов данных и управления. Элементы данных и управления должны организовываться как nмерная таблица или иерархическая древовидная структура? Какая информация связана с другой
информацией в рамках этой структуры? Вся информация представлена в этой структуре, или
должны использоваться разные структуры? Как информация в одной структуре соотносится с
информацией в другой структуре? На эти и другие вопросы необходимо ответить при оценивании
структуры информации. Необходимо отметить, что понятие структура данных (data structure),
обсуждаемое далее в данном курсе, относится к проекту и реализации структуры информации.
При оценивании проблемы аналитик создает модели системы, которые помогают в понимании
информации, функций и поведения системы, делая посредством этого задачу анализа требований
более легкой и систематической.
Проектировщик программного обеспечения может преобразовать эти модели в проекты
данных, архитектуры, интерфейсов и процедур. Кроме того, модели становятся главным объектом
экспертизы и поэтому ключом для определения полноты, согласованности и точности
спецификации.
Модели создаются для достижения лучшего понимания создаваемого реального объекта,
информации, которую преобразует программное средство, функций (и подфункций), которые
осуществляют это преобразование, и поведение системы, когда осуществляется это
преобразование.
Функциональные модели (functional models). Программное обеспечение преобразует
информацию, и чтобы делать это, оно должно осуществлять, по меньшей мере, три общих функции:
ввод, обработку и вывод. Когда создается функциональная модель программного обеспечения, его
разработчик фокусирует свое внимание на характерных для проблемы функциях. Функциональная
модель начинается с самой простой модели, т.е. имени программного средства, которое должно
быть разработано. На каждом уровне итерации будет появляться все больше и больше деталей до
тех пор, пока не будет представлено основательное описание функциональности системы.
Поведенческие модели (behavior models). Большая часть программных средств отвечает на
события во внешнем мире. Эта характеристика “раздражения-реакции” формирует основу для
модели поведения. Программа ЭВМ всегда находится в некотором состоянии (state) – внешне
наблюдаемом режиме поведения (например, ожидание, вычисление, печать, опрашивание),
которое изменяется только тогда, когда происходит некоторое событие. Поведенческая модель
создает представление о состояниях программного обеспечения и событиях, которые заставляют
программное обеспечение изменять состояние.
Разделение на части. Области информации, функций и поведения программного обеспечения надо
разделить на части. Подфункции, связанные с основной функцией, могут изучаться показом деталей в
30
иерархии вертикально, чтобы показать увеличение уровня детализации функций при движении вниз. Подход
разделения может применяться и для областей информации и поведения. Разделение потока информации и
поведения системы, обеспечивают дополнительное понимание требований к системе. При разделении
проблемы на части выделяются интерфейсы между функциями. Элементы данных и управления,
перемещаемые через интерфейс, должны ограничиваться входной информацией, необходимой для
выполнения установленной функции, и выходной информацией, необходимой для других функций или
элементов системы.
Спецификация требований. Нет никакого сомнения в том, что режим специфицирования существенно
влияет на качество получаемого решения. Если спецификации неполны или противоречивы, то в итоге это
приводит к снижению качества программного обеспечения и своевременности его поставки.
"Спецификация" описывает, объясняет в бизнес-теpминах, что должно делать ПС и какими
внешними свойствами оно должно обладать. Поэтому иногда называется «внешним описанием»
создаваемого ПС. Внешнее описание должно достаточно точно и полно определять задачи,
которые должны решить разработчики требуемого ПС.
Внешнее описание ПС играет роль точной постановки задачи, решение которой должно
обеспечить разрабатываемое ПС. Оно является исходным документом для трех параллельно
протекающих процессов: разработки (конструированию и кодированию) программ, входящих в ПС,
разработки документации по применению ПС и разработки существенной части комплекта тестов
для тестирования ПС. Ошибки и неточности во внешнем описании, в конечном счете,
трансформируются в ошибки самой ПС и обходятся особенно дорого, во-первых, потому, что они
делаются на самом раннем этапе разработки ПС, и, во-вторых, потому, что они распространяются
на три параллельных процесса. Это требует принятия особенно серьезных мер по их
предупреждению.
Все в нем должно пpедставлять интеpес для пользователя. Он должен отвечать на все вопpосы
пользователей и pазpаботчиков в области фyнкциональной pазpаботки.
Докyмент не должен быть пеpегpyжен техническими подpобностями, стpyктypами файлов и
пpочими технологическими деталями. Докyмент должен быть читаем и хоpошо логически
оpганизован.
Понятия и принципы проектирования
Проектирование ПО служит основанием для всех последующих шагов его разработки и
сопровождения. Оно может быть определено как "процесс применения различных методов и
принципов для целей достаточно детального определения программного продукта или
системы, чтобы обеспечить их физическую реализацию".
Цель проектировщика - создать модель или представление той сущности, которая впоследствии
должна быть построена.
Процесс объединяет интуицию и опыт в разработке аналогичных сущностей, множество принципов
и/или эвристик, которые управляют развитием модели, множество критериев, которые дают возможность
оценить качество, и процесс итераций, которые неуклонно ведут к конечному представлению продукта.
Проектирование - это тот единственный путь, когда создатель программного обеспечения точно
переводит требования заказчика в окончательный программный продукт или систему.
Важность проектирования программного обеспечения может быть передана с помощью одного слова качество (quality). Скорость, надежность, правильность, удобство использования, т.е. такие свойства
программного обеспечения, которые могут наблюдаться пользователем при работе, называются
Внешними свойствами качества (external quality factors).
31
Проектирование обеспечивает разработчика таким представлением ПО, чьи Внутренние свойства
качества (internal quality factors) могут быть оценены. Их учет ведет к высококачественному с
технической точки зрения проекту. Внутреннее свойство продукта – то, которое можно измерить только
в терминах продукта, другими словами, внутренний атрибут измеряется проверкой самого продукта,
отдельно от его поведения.
Проектирование - это тот период разработки, в котором "выращивается" качество. Во время
проектирования принимаются решения, которые будут в конце концов влиять на успешность
конструирования программного обеспечения и, что важно, на простоту, с которой программное
обеспечение будет сопровождаться.
Как указывалось ранее, каждый из элементов модели анализа предоставляет информацию,
необходимую для создания модели проекта. Требования к программному обеспечению,
представляемые моделями данных, функций и поведения, являются входными данными для
процесса проектирования:
Используя один из методов проектирования этот процесс производит проект данных,
архитектурный проект, проект интерфейсов и процедурный проект.
Проект данных (data design) преобразует информационную модель прикладной области,
созданную во время анализа, в структуры данных, которые потребуются для реализации
программного обеспечения. Объекты данных и связи между ними, определенные на диаграмме
связей между объектами, и детализированное содержание данных, представленное в словаре
данных, обеспечивают основу для деятельности по проектированию данных.
Архитектурный проект (architectural design) показывает связи между основными элементами
структуры программы. Это представление проекта может быть получено из спецификации системы
и модели анализа, в частности, из взаимодействия подсистем, определенного в модели анализа.
Проект интерфейсов (interface design) описывает, как части программного обеспечения
взаимодействует внутри него, а также с системами, которые работают с ним, и с людьми, которые
его используют. Интерфейс подразумевает поток информации (т.е. данные и/или управление).
Поэтому диаграммы потоков данных и управления обеспечивают проектировщика информацией,
необходимой для проектирования интерфейсов.
Процедурный проект (procedural design) представляет процедурное описание компонентов
программного обеспечения, определенных ранее как структурные элементы архитектуры
программы. Информация, полученная из спецификаций процесса служит основой для
процедурного проекта.
Принципы проектирования. Основные принципы проектирования дают разработчику
программного обеспечения возможность успешно двигаться по процессу проектирования. Они
формулируются следующим образом.
• Проект должен быть прослеживаемым по отношению к модели анализа. Поскольку
отдельный элемент модели проекта часто прослеживается ко многим требованиям, необходимо
иметь средство для прослеживания того, как требования были удовлетворены моделью проекта.
Проект представляется на высоком уровне абстракции - уровне, на котором могут быть
непосредственно прослежены требования к конкретным данным, функциям и поведению.
• Проектирование не должно заново изобретать колесо. Проектировщики системы должны
пытаться использовать образцы решений, которые приходилось принимать раньше, называемые
повторно используемыми компонентами проектов. Время проектирования должно тратиться на
представление действительно новых идей и объединения моделей, которые уже существуют.
32
• Проектирование, должно создавать ПО подобным той задаче, которая существует в
реальном мире. То есть, структура проекта программного обеспечения должна (всегда, когда это
возможно) подражать структуре области проблемы.
• Проект должен проявлять единообразие и интегрированностъ. Проект является
единообразным, если по нему можно сказать, что его создавал только один человек. Правила
стиля и формат должны определяться для бригады проектирования до того, как начнется работа
по проектированию. Проект является интегрированным, если проработаны интерфейсы между
компонентами проекта.
• Проект должен быть структурирован так, чтобы программное средство прекращало
свою работу постепенно, даже когда встречаются аномальные данные, события или условия
работы. Хорошо спроектированная компьютерная программа никогда не должна "взрываться
как бомба". Она должен быть сконструирована так, чтобы быть приспособленной для необычных
обстоятельств, и, если она должна завершать обработку, то она будет делать это постепенно.
Если описанные выше принципы проектирования применяются надлежащим образом,
разработчик программного обеспечения создает проект, проявляющий как внешние, так и
внутренние свойства качества.
Основные понятия проектирования программного обеспечения представляют необходимую
основу для "получения правильной программы".
Понятия проектирования
Абстракция и уточнения являются взаимодополняющими понятиями.
Абстракция позволяет проектировщику специфицировать процедуры и данные и при этом
скрывать низкоуровневые детали. Уточнение обеспечивает создание полной модели проекта в
процессе его развития.
Проектирование программного обеспечения является итеративным процессом. Первоначально,
представление проекта изображает целостное видение ПО.
Абстракция
Во время анализа требований к ПО его решение устанавливается в терминах, "которые знакомы
в среде проблемы". Это самый верхний уровень абстракции – тот, где решение задается в широких
терминах среды проблемы и представляет собой Процесс начинается с объявление функции (или
описание информации) на высоком уровне абстракции концептуально, так что нет никакой
информации о внутренней работе функции или внутренней структуре информации.
Когда проектирование совершает итерации (т.е. осуществляется движение по процессу
проектирования), последовательные уточнения ведут к таким представлениям проекта, которые имеют
значительно более низкие уровни абстракции.
На более низких уровнях абстракции принимается более процедурная ориентация. И наконец,
на самом нижнем уровне абстракции устанавливается решение в таком виде, который может быть
легко реализован (когда генерируется исходный код). Т.о. может быть установлено несколько
уровней абстракции (levels of abstraction).
На различных уровнях абстракции, мы создаем процедурные абстракции и абстракции данных.
Процедурной абстракцией называется последовательность команд, которые обладают конкретной
и ограниченной функцией. Абстракцией данных называется набор данных, который описывает
объект данных. Третья форма абстракции – абстракция управления. Она подразумевает механизм
управления программой без специфицирования внутренних деталей.
Уточнение
33
Пошаговое уточнение – стратегия проектирования сверху–вниз. Уточнение заставляет
проектировщика развивать первоначальное объявление функции (или информации), обеспечивая
все больше и больше деталей при каждом последующем уточнении (развитии).
Иерархия «процедур» разрабатывается пошаговой декомпозицией процедурной абстракции до
тех пор, пока не будет достигнут уровень операторов языка программирования. Поскольку задачи
уточняются, данные тоже могут требовать уточнения, естественно делать это параллельно.
Проектирование не должно подменять кодирование. Даже когда создаются детальные
процедурные проекты для компонентов программы, уровень абстракции модели проекта должен
быть выше, чем уровень исходного кода.
Модульность
Модульность подразумевает, что ПО разделено на отдельно именуемые и адресуемые
компоненты, называемые модулями (modules), которые объединяются для удовлетворения
требованиям проблемы.
Считается, что "модульность - это единственное свойство ПО , которое позволяет программе
быть интеллектуально управляемой". Монолитное программное обеспечение (т.е. большая
программа, состоящая из единственного модуля) не может быть легко понята читателем. Такие
свойства детального проекта и исходного кода как число путей управления, расстояние между
использованием переменных, число переменных и общая сложность сделали бы понимание такой
программы, близком к невозможному.
Сокрытие информации
Понятие модульности ведет каждого проектировщика программных средств к основному
вопросу Как получить наилучший набор модулей? Принцип сокрытия информации (information
hiding) предполагает, что модули должны специфицироваться и проектироваться так, чтобы
процедуры и данные, содержащиеся в модуле, были недоступны для других модулей, которые и не
нуждаются в такой информации.
Сокрытие подразумевает, что эффективная модульность может достигаться путем определения
независимых модулей, пересылающих друг другу только ту информацию которая необходима для
выполнения их функций. Абстрагирование помогает определить процедурные (или
информационные объекты которые содержит программное средство. Сокрытие определяет и
навязывает ограничение доступа как к процедурным деталям внутри модуля, так и к любой
локальной структуре данных, используемой модулем.
Использование сокрытия информации модульных систем обеспечивает им огромные
преимущества, когда вносятся изменения при испытаниях и позднее при сопровождении ПО.
Поскольку большая часть данных и процедур спрятана от других частей ПО, непреднамеренные
ошибки, введенные при модифицировании, не распространяются в другие его части.
Функциональная независимость
Функциональная независимость достигается разработкой модулей с "единственной" функцией и
"минимальными" взаимодействиями с другими модулями. Другими словами, необходимо
проектировать программное обеспечение так, чтобы каждый модуль относился к конкретной
подфункции требований и имел простой интерфейс с другими частям структуры программы.
Независимые модули проще сопровождать (и испытывать), поскольку вторичные эффекты,
вызываемы изменением в проекте и в коде ограничены, распространение ошибок уменьшено, и
возможно повторное использование модулей.
34
Понятие функциональная независимость (functional independence) является порождением
понятий модульность, абстракция и сокрытие информации. Функциональная независимость ключ
к хорошему проекту, а проект ключ к качеству программного обеспечения.
Независимость оценивается с использованием двух критериев, связности (или прочности) модуля и
сцепления системы модулей. Связность модуля (cohesion) - это мера его относительной функциональной
прочности. Сцепление системы модулей (coupling) - это мера относительной независимости модулей.
Связность модуля
Связность модуля является естественным расширением понятия сокрытие информации, Связный
модуль выполняет единственную задачу в рамках некоторой процедуры ПО, требующий
незначительного взаимодействия с процедурами, исполняемыми в других частях программы.
Проще говоря, связный модуль должен (в идеале) выполнять только что-то одно.
Модуль, выполняющий множество задач, слабо связанных между собой (если они вообще
связаны), называется случайно связанным (coincidentally cohesive). Модуль, выполняющий задачи,
соотносящиеся логически, является логически связанным (logically cohesive). Если модуль содержит
задачи, связанные между собой только тем фактом, что все они должны быть выполнены в один и
тот же интервал времени, такой модуль проявляет временную связность (temporal cohesion). На
практике следует избегать низких уровней связности при проектировании.
Средние уровни связности относительно близки друг к другу в том, что касается независимости
модулей. Когда части модуля, обрабатывающие данные, связаны между собой и должны
выполняться в определенном порядке, то существует процедурная связность модуля (procedural
cohesion). Когда все эти части обрабатывают элементы одной и той же области структуры данных,
то имеет место коммуникационная связность модуля (communicational cohesion).
Высокая связность проявляется модулем, который выполняет единственную, точно
определенную процедурную задачу (или несколько функций, но встречающихся в порядке,
предписанном спецификацией.
Сцепление модулей
Сцепление модулей мера взаимосвязи модулей в структуре программы. Подобно связности
модулей, сцепление может быть представлено на спектре.
Сцепление модулей зависит от сложности интерфейсов между ними, места в программной
единице, в котором происходит вход в модуль или ссылка на другой модуль, и того, какие данные
проходят через интерфейс.
Рисунок ниже представляет пример различных типов сцеплений между модулями. Модули a и d
являются подчиненными различных модулей. Каждый из них никак не связан с другим, между
ними нет никакого межмодульного сцепления. Модуль c является подчиненным модуля a, и
обращение к нему осуществляется с использованием списка простых аргументов, через которые
передаются данные (передаются простые данные: существует соответствие один-к-одному для
элементов данных и их имен). Здесь низкое сцепление между модулями, связь по данным (data
coupling). Одна из версий сцепления по данным, сцепление по сложным данным (stamp coupling),
имеет место тогда, когда часть структуры данных (а не простой их элемент) передается через
интерфейс модуля. На рисунке это происходит между модулями b и a.
35
Никакой
непосредственной
связи
a
Структура
данных
b
d
Данные
(переменные)
Флажок
управления
c
i
e
j
f
g
k
h
Область
глобальных
данных
Рис. 4. Типы сцеплений между модулями.
В проекте программного обеспечения следует стремиться к как можно более низкой
сцепленности модулей между собой. Простое сцепление модулей приводит к программному
обеспечению, которое легче понимать, и оно менее склонно к "волновому эффекту" ("ripple effect"),
возникающему, когда имеет место ошибка в одном месте, и ее влияние распространяется по
системе.
На среднем уровне – сцепление характеризуется передачей управляющих данных между
модулями. Сцепление по управлению (control coupling) является очень частым в программных
проектах, и оно показано на рисунке, где "флажок управления" (переменная, управляющая
решениями в подчиненном или старшем модуле) передается между модулями d и e.
Относительно высокий уровень сцепления – когда модули связаны со средой, внешней по
отношению к данной программе. Внешнее сцепление неотъемлемо для программного
обеспечения, но должно ограничиваться число модулей в структуре программы с таким
сцеплением. Высокое сцепление возникает еще и тогда, когда несколько модулей ссылаются на
область глобальных (или нелокальных) данных. Это сцепление по общим данным (common
coupling). Каждый из модулей c, g и k имеет доступ к одному и тому же компоненту данных в
области глобальных данных).
Самая высокая степень сцепления, сцепление по содержанию (content coupling), возникает, вопервых, тогда, когда один модуль использует данные или управляющую информацию,
находящуюся в границах другого модуля. Во-вторых, – когда один модуль передает управление в
середину другого модуля. Этого режима сцепления можно и нужно избегать.
Множество основных принципов и понятий следует применять к проектам данных, архитектуры,
интерфейсов и процедур независимо от используемого метода проектирования.
Архитектура программного средства
Архитектура программного средства (software architecture) представляет "общую структуру
программного средства и способ, которым эта структура обеспечивает концептуальную целостность
системы" [PRE97].
Цель – разработать структуру модульной программы и представить взаимосвязи по управлению
между модулями, а также общую структуру программы и структуру данных, определяя интерфейсы,
позволяющие данным течь по программе.
Одна из целей проектирования программного средства - получить архитектурное изображение,
на основании которого проводятся детальные работы по проектированию.
Основные задачи разработки архитектуры ПС:
36
Выделение программных компонентов системы (например, модули, объекты, фильтры) и
отображение на них специфицированных функций ПС;
определение способов комплектования и взаимодействия между выделенными
программными компонентами. Например, объекты представляются так, чтобы
инкапулировать как данные, так и обработку этих данных, и взаимодействие посредством
вызова методов.
Структурные модели, модели управления и декомпозиции.
С точки зрения структурирования различают следующие
программных средств:
основные классы архитектур
–
модель репозитория (комплекс автономно выполняемых программ, в том числе одна
автономно выполняемая программа);
–
модель клиент\сервер;
–
многоуровневая модель (модель абстрактной машины, слоистая программная система).
Далее следует этап модульной декомпозиции. Известно немало методов архитектурного
проектирования, каждый базируется на конкретном методе анализа требований и формате
полученной модели анализа. При этом каждый из методов имеет свои сильные и слабые стороны.
Важным фактором для выбора метода проектирования является «тип» приложения.
На этапе модульной декомпозиции рассматриваются две модели:
ОО модель (набор взаимодействующих объектов) и
модель, ориентированная на функции, - набор функциональных модулей, которые получают
входные данные и преобразуют их некоторым образом в выходные.
Не существует идеального метода. ОО методы часто применяются для создания диалогивых
программных систем, но практически не используются при разработке систем, работающих в
режиме реального времени.
Проектирование, ориентированное на функции, применимо ко многим областям приложений.
Теоретически, методы проектирования, использующие диаграммы потоков данных, могут быть
применены при разработке любого ПО. Но в таких приложениях, как системы баз данных,
экспертные системы, ОО-интерфейсы, более разумно применение других методов проектирования.
Данные, поступающие на вход, проходят через все преобразования и достигают выхода.
Преобразования могут выполняться последовательно или параллельно.
Преимущества такой архитектуры: понятность (люди мыслят в терминах обработки
данных); простота реализации и др.
Недостаток: необходимость использовать общий формат передачи данных, который
должен распознаваться всеми преобразованиями.
Разбиение структуры
37
Метод, ориентированный на потоки данных, предполагает, что структура программы должна
разделяться на части горизонтально и вертикально. Как показано на рис. горизонтальное
разбиение (horizontal partitioning) определяет отдельные ветви в иерархии модулей для каждой
большей функции программы. Управляющие модули, представленные затемненными,
используются для согласованного соединения функций программы и ее выполнения.
Простейший подход к горизонтальному разбиению на части определяет три вида функций:
ввод данных, их преобразования (часто называемые обработкой (processing)) и вывод данных.
Разбиение архитектуры в горизонтальном направлении обеспечивает проект рядом преимуществ.
Оно:
• приводит к программному обеспечению, которое легче проверяется;
• ведет к программному обеспечению, которое легче сопровождать и расширять;
• приводит к меньшему распространению побочных эффектов.
Поскольку главные функции разделены между собой, изменения становятся менее сложными, и расширение
системы (общий случай) осуществляется так, что при его выполнении будет меньше побочных эффектов.
Имеется и отрицательное влияние горизонтального разбиения: оно ведет к большему объему данных,
проходящих через интерфейсы модулей, и может усложнять общее управление потоком программы (если
обработка требует быстрое перемещение от одной функции к другой).
Вертикальное разбиение (vertical partitioning) (рис. 10.46), часто называемый разделением на
элементарные операции (factoring) предполагает, что управление (принятие решений) и работа
должны распределяться сверху-вниз в архитектуре программы. Модули верхнего уровня должны
осуществлять функции управления и выполнять небольшой объем реальной работы по обработке.
Модули, которые располагаются внизу в архитектуре, должны быть рабочими, выполняющими все
задачи по вводу, вычислениям и выводу.
Сама природа изменений в архитектуре программы ведет к потребности в вертикальном
разбиении. Изменение в управляющем модуле (высоко в архитектуре) будут иметь белее высокую
вероятность распространения побочных эффектов в модулях, которые являются его подчиненными.
Изменение в рабочем модуле, расположенным на низком уровне в иерархии, вызывает
распространение побочных эффектов с меньшей вероятностью. В общем случае, изменения в
компьютерных программах, вращаются вокруг изменений во входе, вычислениях или
преобразованиях и выходе. Общая структура управления в программе (т.е. ее основное поведение)
значительно менее вероятна для изменений. По этой причине архитектуры, подвергаемые
вертикальным разбиениям, являются менее чувствительными к побочным эффектам при
изменениях, и поэтому они будут более сопровождаемыми - и это является ключевым фактором
качества.
Модели управления.
Модель вызова – возврата – модель организации вызова программных единиц «сверху-вниз»,
в которой управление начинается на вершине иерархии и через вызовы передается на более
нижние уровни иерархии.
Иерархия управления (control hierarchy), называемая также структурой программы (program
structure), представляет организацию (часто иерархическую) компонентов программы (модулей), и
подразумевает иерархию управления.
Для представления иерархии управления используются чаще всего иерархические диаграммы.
Однако, существуют и другие формы описания структуры. (Для объектно-ориентированных
проектов понятие структуры программы является менее очевидным.) Для облегчения
последующего обсуждения структуры, здесь определяются новые простые меры и термины. На рис.
38
6 глубина (depth) и ширина (width) обеспечивают указание числа уровней управления и общий
диапазон управления соответственно. Коэффициент разветвления по выходу (fan-out) является
мерой числа модулей, которые непосредственно управляются другим модулем. Коэффициент
объединения по входу (fan-in) указывает, как много модулей непосредственно управляет данным
модулем.
Преимущества использования модели: относительно простой анализ потоков управления и
легкость выбора компонента, отвечающего за конкретный ввод данных.
Модель диспетчера – совокупность компонентов, один из которых назначается системным
управляющим (диспетчером), и управляет запуском, завершением и координированием других
процессов системы. Процесс (выполняемая подсистема) может протекать параллельно с другими
процессами. Процесс «Системный управляющий», в зависимости от переменных состояния
системы, определяет моменты запуска и завершения процессов. Он обычно работает постоянно,
проверяя датчики и другие процессы или отслеживая изменение состояния. Обычно так
проектируют архитектуру систем реального времени. В последовательных программах такой
механизм передачи управления (чтобы управление переходило к соответствующему обработчику
как можно быстрее после получения входного сигнала) невозможен, поэтому системы реал
времени проектируют обычно как множество параллельно вз-дей-х процессов. Диспетчер
управляет всеми процессами.
Модель передачи сообщений. В этих моделях событие представляет собой передачу сообщения
всем подсистемам. Обработчик сообщений и событий «следит», чтобы «требуемые» события
отправлялись «их требующим» подсистемам. Каждая подсистема уведомляет обработчика о своем
интересе к конкретным событиям. Когда событие (передача сообщения) происходит, обработчик
пересылает его подсистеме, которая может обработать это событие, т.е. управление переходит к
подсистеме, обрабатывающей данное событие. Функции управления в обработчик не
встраиваются.
Преимущество: относительно простая модернизация систем… подсистемы можно реализовать
на разных машинах. Такие модели эффективны при интеграции подсистем, распределенных на
разных компьютерах, объединенных в сеть.
Модели, управляемые прерываниями. Используются в системах реального времени: внешние
прерывания регистрируются обработчиком прерываний, а обрабатываются другим компонентом.
(Пример, система безопасности автомобиля должна определить возможную опасность и успеть
наполнить воздухом подушку безопасности до того, как голова ударится о руль.) [Орлов]: все
прерывания разбиты на группы – типы, которые образуют вектор прерываний. Для каждого типа
прерываний существует свой обработчик. Каждый тип прерывания связан с ячейкой памяти, в
которой хранится адрес обработчика прерывания. При получении определенного прерывания
аппаратный переключатель немедленно передает управление обработчику прерывания. В ответ на
событие, ВЫЗВАННОЕ прерываниЕМ, обработчик МОЖЕТ запустить или завершить другие
процессы. Каждый обработчик реагирует на свой тип прерывания и запускает свой процесс.
Данная модель используется в жестких системах реального времени, где требуется немедленная
реакция на определенные события.
Проектирование при объектном подходе.
На этапе конструирования при объектном подходе продолжается процесс объектного моделирования:
уточняются модели, построенные на этапе внешнего описания, в терминах описания программных систем и
производится дальнейшая декомпозиция объектов.
ОО проектирование переводит модель анализа в модель проекта, служащую планом построения ПО.
Каждая из моделей анализа отображается в одну или более моделей проекта.
39
Основными деятельностями являются: выявление классов и объектов, выяснение семантики этих классов
и объектов, выявление связей между этими классами и объектами, спецификация интерфейса и реализация
этих классов и объектов.
Выявление классов и объектов и выяснение семантики этих классов и объектов
Цель состоит в продумывании объектно-ориентированной декомпозиции разрабатываемой системы. При
этом уточняются намеченные абстракции (классы объектов), продуманно и измеримо распределяются между
ними обязанности, изобретаются новые абстракции (могут появиться классы чисто синтетической природы,
которые не имеют аналогов в реальном мире).
На основе: ДСО, в частности, рассмотривают связи, которые при анализе были помечены, скорее всего,
глаголами, показывающими физическое размещение (next to, part of, contained in), собственность (incorporated
by, is composed of). Рассматриваются конечные автоматы (диаграммы состояний) для представления
некоторых абстракций.
По мере изобретения абстракций в рассматриваемой проблемной области (возможно, по «трассам
событай» обнаруживается сходное поведение объектов) всплывают классы и подклассы создаются
структуры обобщение/специализация.
Результаты:
Диаграммы (классов) объектов показывают объекты (и классы объектов) и их связи в логическом проекте
системы. Существенные элементы – объекты и их отношения (наследования и агрегации).
Выявляют атрибуты каждого объекта (класса), которые определены в классе объекта или в любом из его
суперклассов. Каждый атрибут представляется некоторым именем и может принимать значения
определенного типа.
Другой результат этой деятельности - обновляющийся по мере развития проекта словарь данных и
уточняемые диаграммы взаимодействий.
Пример.
Здесь обобщающий класс датчик усовершенствуется во множество специализаций – датчик входа, датчик
дыма, датчик движения. Атрибуты и операции, помеченные для класса "датчик" наследуются
специализациями класса. Мы создаем простую иерархию классов.
Пример (Г. Буч).
Чтобы объединить все классы, относящиеся к датчикам, в одну иерархию, имеет смысл создать
абстрактный базовый класс Sensor, который является непосредственным суперклассом для
WindDirectionSensor и CalibratingSensor.
Датчик определения направления ветра - несколько отличается от всех остальных, так как он не
нуждается ни в калибровке, ни в вычислении минимальных и максимальных значений. Мы можем определить
данную абстракцию следующим образом:
Имя: WindDirectionSensor
Ответственность:
Поддержание информации о текущем направлении ветра, указываемом как точка на розе
ветров.
Операции:
currentDirection - текущее направление
Атрибуты:
direction - направление
40
Рис. 5 Полная иерархия классов датчиков.
Краткий анализ четырех классов системы (TemperatureSensor, PressureSensor, HumiditySensor и
WindSpeedSensor) показывает, что у них имеется общая черта: калибровка измеренных значений посредством
линейной интерполяции. Вместо того, чтобы реализовывать эту способность по отдельности в каждом из
классов, можно выделить особый суперкласс CalibratingSensor, ответственный за выполнение калибровки.
Имя: CalibratingSensor
Ответственность:
Обеспечение линейной интерполяции значений, лежащих в известном интервале.
Операции:
currentValue - текущее значение
setLowValue - установка минимального значения
setHighValue - установка максимального значения
CalibratingSensor является непосредственным суперклассом для класса HistoricalSensor.
Требования к системе подразумевают наличие общего поведения для всех трех
вышеперечисленных классов. В частности, мы должны обеспечить показ максимального и
минимального значений каждого параметра за 24-часа. Эту обязанность можно отразить в
следующем описании, общем для всех трех классов:
Имя: HistoricalSensor
Отвественность:
Генерация сообщений о максимальных и минимальных значениях параметров за 24-часа.
Операции:
highValue - максимальное значение
lowValue - минимальное значение
41
timeOf HighValue - время, соответствующее максимальному значению
timeOfLowValue - время, соответствующее минимальному значению
Класс HumiditySensor является прямым потомком класса HistoricalSensor, так же как и
TrendSensor. Абстракция для датчика скорости ветра может выглядеть следующим образом:
Имя:
WindSpeedSensor
Ответственность:
Поддержание информации о текущей скорости ветра.
Операции:
currentSpeed - текущая скорость
setLowSpeed - установка минимальной скорости
setHighSpeed - установка максимальной скорости
Атрибуты:
speed - скорость
Абстракцию, соответствующую датчику влажности, можно определить следующим образом:
Имя:
HumiditySensor
Ответственность:
Поддержание информации о текущей влажности, выраженной в процентах от 0% до 100%.
Операции:
currentHumidity - текущая влажность
setLowHumidity - установка минимальной влажности
setHighHumidity - установка максимальной влажности
Атрибуты:
humidity - влажность
Отметив сходство поведения классов TemperatureSensor и PressureSensor, разумно создать
общий суперкласс, ответственный за определение тренда. Назовем его TrendSensor. TrendSensor
служит промежуточным абстрактным классом, переходным между абстрактным HistoricalSensor и
конкретными TemperatureSensor и PressureSensor. Требования к системе предусматривают
определение тенденций изменения температуры и барометрического давления (относительное
изменение, тренд).
И для температурного датчика, и для датчика давления тренд может быть определен как вещественное
число, изменяющееся в диапазоне от -1 до 1 и представляющее собой наклон графика изменений температуры
и давления на некотором интервале времени. Таким образом, к описанию двух вышеупомянутых классов
можно добавить еще одну ответственность и соответствующую ей операцию:
Ответственности:
Определение тренда давления или температуры как наклона графика (в линейном
приближении) изменения их значений за данный интервал времени.
Операции:
trend - тренд
42
Класс TemperatureSensor (температурный датчик) служит аналогом аппаратного температурного
датчика нашей системы. Изолированный анализ поведения этого класса дает в первом
приближении следующий результат:
Имя:
TemperatureSensor
Ответственность:
Поддержание информации о текущей температуре.
Операции:
currentTemperature - текущая температура
setLowTemperature - установка минимальной температуры
setHighTemperature - установка максимальной температуры
Атрибуты:
temperature - температура
Название операции currentTemperature (текущая температура) говорит само за себя. Назначение
двух других операций (установка минимальной и максимальной температур) прямо определяется
требованием к системе, а именно необходимостью проведения калибровки датчиков. Сигнал от
каждого датчика - это число с фиксированной точкой из некоторого рабочего диапазона, граничные
значения которого должны быть заданы. Промежуточные значения температуры вычисляются
простой линейной интерполяцией между этими двумя точками.
Хотя в требованиях к системе ясно сказано, что температурный датчик может быть только один, но в
целях обеспечения возможности повторного использования абстракции мы все же выделяем ее в отдельный
класс. На самом деле количество температурных датчиков не должно влиять на архитектуру нашей системы,
и, выделяя отдельный класс TemperatureSensor, мы открываем возможность его использования в других
программах подобного типа.
Абстракция для датчика барометрического давления может выглядеть следующим образом:
Имя:
PressureSensor
Отвественность:
Поддержание информации о текущем барометрическом давлении.
Операции:
currentPressure - текущее давление
setLowPressure - установка минимального давления
setHighPressure - установка максимального давления
Атрибуты:
pressure - давление
Выявление связей\взимодействий между классами и объектами
Цель - формализовать концептуальное размежевание между абстракциями, специфицировать
взаимодействия, которые формируют механизмы архитектуры.
Связь существует, когда существует ассоциация между соответствующими классами (простая ассоциация,
отношение наследования или отношение включения), т.е существует коммуникация (канал связи) между их
экземплярами, по которой объекты могут посылать друг другу сообщения. Значит, можно вызывать любую
доступную операцию.
Метод: Рассмотреть связи в ДСО (или ДК), которые при анализе были помечены, скорее всего, глаголами,
показывающими коммуникации (transmits to, acquires from), и удовлетворение условия (manages, coordinates,
43
controls). Ассоциация «взаимодействие», по существу, означает, что объекты классов, находящихся в таком
отношении, могут обращаться к атрибутам и операциям других классов.
1) Спецификация ассоциаций. Выбрать множество классов данного уровня абстракции или
ассоциированных с некоторым набором сценариев; нанести на диаграммы все важнейшие
операции и атрибуты, просмотреть сценарий и убедиться, что имеющиеся ассоциации необходимы
и достаточны для получения требуемых переходов и поведения абстракций этого сценария.
Диаграммы классов - основные модели, получаемые на данном этапе.
Диаграммы взаимодействий (Модель последовательностей), формально отражают «раскадровку» каждого
сценария, описывают явное распределение обязанностей среди взаимодействующих объектов. Диаграмма
взаимодействия— развитие модели анализа "трасса событий".
Взаимодействия между объектами,
маркированные в «трассе событий» названиями передаваемых друг другу сообщений, получают здесь более
точные названия – имена операций, которые могут быть совершены над объектами-получателями сообщений
(объектами-серверами). При проектировании можно на вертикальной линии каждого объекта нарисовать
«тонкие прямоугольнички», показывающие периоды, когда управление находится в этом объекте (интервал
времени, в течение которого данный объект был управляющим объектом системы). Объект «берет на себя
управление» в «верхней части» прямоугольника и передает управление другому объекту внизу
прямоугольника.
2) Идентификация взаимодействий и уточнение ассоциаций. Проверяется каждый механизм в
центральных и периферийных сценариях. Где возможен параллелизм, назначить объекты - актеры,
агенты и серверы и способы синхронизации между ними. Объекты могут быть активными и
пассивными. Активный объект имеет свой поток управления, а пассивный – нет.
Для обеспечения контроля сопровождаемости (а, в некоторых случаях, переносимости и
надежности) на этом этапе проектирования требуется проверить согласованность (для каждого
проектируемого класса объектов) связей-абстрагирования (класс-подкласс) на уточненной
диаграмме связи объектов и диаграммах классов.
Спецификация интерфейса (Описание протокола)
Пересматривают протокол каждого класса. Идентифицируют стереотипы его использования
объектами-клиентами, чтобы определить, какие операции являются центральными и,
следовательно, должны быть оптимизированы.
Проектное описание объекта (представителя класса или подкласса) может принимать одну из двух форм:
описание протокола, которое устанавливает интерфейс объекта, определяя каждое сообщение, которое объект
может получить, и выполняемые в ответ на него операцию; или описание реализации, которое показывает
детали реализации для каждой операции, выполняемой в ответ на сообщение, а также информацию о private
part, а именно структуры данных, описывающих атрибуты и процедурные подробности, описывающие
операции.
Описание протокола – ничего более, чем множество сообщений и соответствующий комментарий к
каждому сообщению
Например, часть описания протокола для объекта motion sensor:
…
MESSAGE (motion.sensor) ––>read: RETURNS sensor.ID, sensor.status;
…
Важно разработать точные сигнатуры всех важнейших операций. Рассмотреть возможность
закрытого или защищенного наследования в реализации.
Проектирование интерфейса
Этот проект фокусирует свое внимание на трех основных вещах:
проекте интерфейсов между модулями программы;
проекте интерфейсов между программой и другими производителями и потребителями
информации, кроме человека (Проекте внешних интерфейсов);
44
проекте интерфейса между человеком (пользователем) и компьютером.
Проект внешних интерфейсов включает следующие части:
Интерфейсы с устройствами (Интерфейсы оборудования);
Интерфейсы коммуникации (Communications interfaces);
Интерфейсы с внешними данными;
Интерфейсы с внешними системами.
Проектирование внешнего интерфейса начинается с оценивания каждого внешнего объекта из
ДПД модели анализа. Внешний интерфейс проектируется в соответствии с (определяемыми)
требования к данным и управлению внешнего объекта.
Исходными данными для проектирования внешнего интерфейса являются:
зуемых типах машин и процессоров,
требованиях к памяти, к скорости, архитектуре машин, среде для хранения информации и ее
емкости, внешнему оборудованию (экранам, принтерам, графопостроителям, сканерам, мышам,
клавиатуре, и т.д.) и специальной аппаратуре (специальным графическим картам, сопроцессорам и
т.д.).
системах (имена и версии), библиотеках программного обеспечения, компиляторах, драйверах
устройств и других типах необходимого программного обеспечения.
Интерфейсы с устройствами
Описываются характеристики каждого интерфейса между компонентами ПО и оборудования
системы. В описание могут входить типы поддерживаемых устройств, взаимодействия данных и
элементов управлений между ПО и оборудованием, а также протоколы взаимодействия, которые
будут использоваться.
Пример 1.
Пример описания интерфейса (http://dozen.mephi.ru:8101/student/6-interf.htm)
Описываются компоненты (модули), осуществляющие взаимодействие с графопостроителем (ГП,
плоттером) СМ 6415 (или СМ 6418).
Модуль 1 - преобразование файла графической информации в файл, содержащий
программу на языке ГП - содержит 3 последовательно выполняемые функции:
а) Считывание информации из файла графической информации (двоичный файл);
б) Преобразование графической информации в команды графопостроителя(ГП);
в) Запись полученной команды ГП в текстовый файл.
При начале работы модуля происходит считывание из файла графической информации
размера протокола графического рисунка, записанного в файле.
Далее происходит считывание кода первого элемента. На основе этого кода происходит определение
общего количества байтов, несущих информацию об этом элементе, которые надо считать из файла.
Считанный код и координаты узловых точек чертежа дают возможность сформировать
последовательность команд для ГП, который реализует эту последовательность команд. Так,
если была считана последовательность слов, характеризующих элемент “линия”: 4; X0; Y0; X1;
Y1, то в результате преобразования данной последовательности образуется цепочка команд: PU;
PA X0, Y0; PD; PA X1, Y1; (см. ниже систему команд ГП). Эта последовательность будет записана в
текстовый файл.
Модуль 4 - вывод файла на графопостроитель - начинает свою работу с опроса
последовательного порта вывода с целью установления возможности передачи байта данных в
память ГП. Если передача разрешена, то происходит передача байта данных через порт из
буфера ОЗУ ПЭВМ, в котором хранится программа на языке ГП. При большом объёме
программы и ограниченности буфера памяти ГП (512 байт) программа передаётся поэтапно
(блоками). Вначале передаются первые 512 байтов, затем ГП выполняет переданные команды, а
на освободившееся место в буфер ГП передаются последующие блоки.
Система команд графопостроителя ( язык HPGL)
45
Полная команда языка HPGL имеет следующий формат:
“XX”+ параметрпараметр . . . параметр !
Элементы этой команды интерпретируются следующим образом:
“XX” - мнемоническое изображение команды, состоящее из двух прописных (или
заглавных) букв латинского алфавита без пробелов между буквами;
“+”- символ заполнения (необязательный символ). И т.д.
Пример 2.
Например, ПО для СБД требует взаимодействия через множество внешних датчиков
безопасности.
Проект внешнего интерфейса для каждого датчика основывается на конкретных элементах
данных и управления, необходимых для датчика. Описываются входные сигналы и связанные с
ними реакции системы. Определяются временные ограничения для них.
Входной сигнал «о вторжении» генерируется датчиком. В результате включаются сигналы
звуковой (и световой), генерируется сообщение о месте происшествия и производится телефонный
звонок.
Датчик проверяется дважды в секунду. Звуковой (или световой) сигнал должен прозвучать через
полсекунды после сигнала датчика. Телефонный звонок через заданное при конфигурировании
время.)
Интерфейсы с внешними данными
Определяются данные, к которым будут иметь доступ компоненты ПО, (согласно IEEE Standard
830-1998) элементы баз данных, с которыми система или компонент должны взаимодействовать.
Должны быть представлены схема и форма организации внешних данных, указание тех
компонентов системы, которые являются источниками этих данных,… описание памяти,
необходимой для размещения данных.
Описываются средства (устройства) получения входных данных, в том числе от пользователя
(напр, клавиатура), описывается, если надо взаимодействие ОС (или самого ПС) с этими
устройствами.
Если носителем информации является бланк, то описываются его деление на строки и ячейки,
опознавательные знаки и разделители
Интерфейсы с внешними системами (в IEEE Standard 830-1998: Интерфейсы передачи
информации и Интерфейсы ПО)
Указываются требования для любых функций взаимодействия, которые будут использоваться
продуктом, включая электронную почту, Web-браузер (если интерфейс с пользователем происходит
через интернет-броузеры, то указать номера их версий), протоколы сетевого соединения и
электронные формы. Определяются соответствующие форматы сообщений. Описываются
особенности безопасности взаимодействия или шифрования, частоты передачи данных и
механизмов синхронизации.
Опишите соединения продукта и других компонентов ПО (идентифицированные по имени и
версии), в том числе базы данных, операционные системы, средства, библиотеки и
интегрированные коммерческие компоненты. Укажите назначение элементов сообщений, данных
и элементов управления, обмен которыми происходит между компонентами ПО. Опишите службы,
необходимые внешним компонентам ПО, и природу взаимодействия между компонентами.
В документацию по интерфейсу можно включить ссылки на материал из других документов.
Например, ссылка на спецификацию программного интерфейса другого приложения (API) или на
46
руководство по работе с устройством, где перечислены коды с ошибками, которые устройство
может отправить ПО.
Методы и стратегии испытаний программного обеспечения
Испытания программного обеспечения являются критическим элементом деятельности по
обеспечению качества и представляют конечную экспертизу специфицирования, проектирования и
кодирования.
В настоящее время является совершенно обычным делом, когда организация, разрабатывающая
программное обеспечение, тратит от 30 до 40% общих усилий на испытания того, что она разрабатывает. В
ряде случаев, испытания очень ответственного программного обеспечения (управление полетами, контроль
ядерных реакторов) может стоить в три-пять раз больше, чем все остальные виды деятельности технологии
программирования!
Под термином "испытания" ("test") подразумевается деятельность людей, при которой система или ее
компонент выполняются при определенных условиях, результаты работы наблюдаются или записываются, и
выполняется оценивание некоторых аспектов этой системы или компонента.
Тестирование или проверка (Testing) – конкретное испытание компонентов программного обеспечения:
процесс работы системы или ее компонента при определенных условиях, с наблюдением или записью
результатов и выполнением оценивания некоторых аспектов системы или компонента.
Тест ("Test case") – специальным образом подготовленный и описанный набор (входных) данных для
проверки компонента программного обеспечения
Цели испытаний
В своей классической книге по испытаниям программных средств Глен Майерс [Mай82] устанавливает
несколько правил, которые вполне могут рассматриваться как цели испытаний.
1. Испытание - это процесс выполнения программы с намерением найти ошибку .
2. Хороший тест - это такой, который имеет высокую вероятность нахождения все еще не найденной ошибки.
3. Успешное испытание это такое - которое обнаружило еще необнаруженную ошибку.
Т.о. Испытания программного обеспечения необычны по характеру выполняемой деятельности для
разработчика программного обеспечения. Разработчик создает набор тестов, которые предназначены для
"разрушения" созданного программного средства.
Цель квалифицированного испытателя - подготовить такие испытания, которые
систематически вскрывают различные классы ошибок, и делают это с минимальными затратами
времени и усилий.
Если испытания проводятся успешно (в соответствии с указанными выше целями), они обнаружат
ошибки в программном обеспечении. И лишь в качестве "побочного эффекта", испытания демонстрируют,
что функции программного обеспечения выполняются в соответствии со спецификациями, и что требования к
эксплуатационным характеристикам удовлетворяются. Кроме того, данные, собранные при проведении
испытаний, позволяют оценить надежность программного обеспечения и его качества в целом. Но есть то, что
испытания делать не могут:
Испытания не могут показать отсутствие дефектов, они могут только показать, что ошибки
имеются. Важно всегда помнить об этом, когда проводятся испытания.
Принципы испытаний
Разработчик ПО в своей работе должен принимать во внимание основные принципы, которые
управляют его испытаниями [Pre97].
• Все испытания должны быть прослеживаемы к требованиям заказчика. Как уже отмечалось, цель
испытаний программного обеспечения - обнаружить ошибки. Поэтому наиболее грубые дефекты (с точки
зрения заказчика) - это те, которые вызывают несоответствие программы его требованиям.
• Испытания должны планироваться задолго до того, как они начнутся. Планирование испытаний может
начаться сразу после того, как готова модель требований. Детальное определение требований к
испытаниям может начаться сразу, как утверждена модель проекта. Следовательно, все испытания могут
быть запланированы и подготовлены до того, как сгенерирован хотя бы какой-нибудь код.
Принцип Парето применим к испытаниям программного обеспечения. Принцип Парето подразумевает,
что 80% всех ошибок, обнаруженных при испытаниях, будут относиться к 20% всех программных
модулей. Проблема состоит в том, чтобы выделить эти подозрительные модули и основательно проверить
их.
47
Испытания должны начинаться с проверки "в малом" и развиваться по направлению к проверке "в
целой". Первые запланированные и выполняемые испытания предназначены для нахождения ошибок в
соединенных (комплексированных) группах модулей и затем, в конце концов, в полной системе.
Для того, чтобы быть наиболее эффективными, испытания должны проводиться независимой третьей
стороной. Под "наиболее эффективными" здесь подразумеваются такие испытания, которые имеют
наиболее высокую вероятность нахождения ошибок.
Каждое испытание должно иметь свою собственную, отличное от других испытаний цель (даже если
она слегка отлична). Хорошее испытание не является избыточным. Время и ресурсы испытания
ограничены. Нет никакого смысла в проведении испытания, которое имело бы ту же самую цель, что и
некоторое другое испытание.
Разработка тестов
Любой создаваемый продукт может испытываться одним из двух способов:
Первый подход к испытаниям называется испытание черного ящика (black-box testing) - это испытания
(тестирование), проводимые с помощью их интерфейсов. Они должны продемонстрировать, что входные
данные воспринимаются надлежащим образом, а выходные данные генерируются правильно, т.е. каждая
определенная функция полностью и правильно выполняется, в то же самое время отыскиваются ошибки в
каждой функции. При этом испытания черного ящика проверяют все эти вещи безотносительно к внутреннее
логической структуре программы.
Второй - испытание белого ящика (white-box testing): поскольку известна внутренняя работа продукта,
испытания могут проводиться для проверки того, что все внутренние компоненты взаимодействуют в
соответствии со спецификацией и выполняют все надлежащим образом.
Тест ("Test case") – 1) множество проверяемых входных данных, условий выполнения и ожидаемых
результатов, разработанных для конкретной цели, такой, как пройти по определенному пути в программе или
проверить согласованность с определенным требованием;
2) (IEEE Std 829-1983) документация, определяющая входные данные, ожидаемые результаты и
множество условий выполнения для испытываемого компонента программного обеспечения".
Испытания белого ящика
Испытание белого ящика, иногда называемое испытанием стеклянного ящика (glass-box testing) - это
такой метод создания тестов, при котором структуру управления, определенную в процедурном проекте,
используют для определения того, что должно быть проверено при этих испытаниях (или, другими словами,
для создания тестов).
Испытание программы как белого ящика основывается на рассмотрении процедурных деталей. При
этом поверяются логические пути через программу посредством тестов, каждый из которых предназначен для
определенных наборов условий и/или циклов. В различных точках может проверяться "состояние
переменных", для которых устанавливается, соответствует ли имеющееся состояние ожидаемому.
Существует несколько подходов к тому, что и как должно проверяться при испытаниях белого ящика.
Один из известных взглядов на основные виды испытаний (тестирований) белого ящика состоит в том, что
сначала строится модель потока управления в модуле в форме графа потока управления (control flow graph). В
этой модели узлу графа соответствует некоторая единица выполнения программы (обычно оператор языка
программирования), а дуге - передача управления между этими единицами согласно семантике языка. Затем
определяется покрытие испытаниями (test coverage) модуля программы в терминах языка программирования
и/или его графа потока управления, которого необходимо достичь к концу испытаний.
Простейшим методом испытаний белого ящика является построение таких тестов (наборов входных
данных для модуля), при которых каждый оператор модуля исполняется хотя бы один раз. В таком случае
говорят о покрытии всех операторов (statement coverage). В терминах графа потока управления это означает,
что покрытие операторов предполагает нахождение такого множества путей в графе, чтобы каждый узел
графа лежал хотя бы на одном из путей. Это покрытие узлов графа (node coverage).
Более "сильным" испытанием является такое, в котором каждая ветвь в модуле выполнится хотя бы
один раз. Тогда говорят о покрытии всех ветвей (branch coverage). В терминах графа потока управления это
означает, что должно быть найдено такое множество путей в графе, чтобы каждая дуга графа лежала бы хотя
бы на одном из путей. Это покрытие дуг графа (edge coverage).
Третий по проверенности белого ящика вид испытаний - проверка простых путей (simple path testing),
требующая исполнения каждого простого пути в графе (т.е. пути, который не содержит ту же самую дугу
более одного раза).
Еще большей проверенности белый ящик достигнет при проверке структуры (structured testing) или
линейно независимых путей (lineary-independent-path testing) (т.е. таких путей в графе, из которых могут быть
составлены все остальные возможные пути). Она требует, чтобы, как минимум, были исполнены линейнонезависимые пути через граф потока модуля.
48
Далее в иерархии методов испытаний следует проверка с заходом в каждый цикл (visit-each-loop testing). Эти
испытания требуют, чтобы:
1) осуществилось покрытие всех дуг и
2) для каждого цикла были бы пройдены два пути: как проходящий без исполнения цикла, так и
обходящий цикл хотя бы один раз.
Самым "лучшим", "исчерпывающим" испытанием является такое, при котором каждый возможный путь в
программе выполнится хотя бы один раз. Этот вид испытания называется покрытием путей (path coverage). В
терминах графа потока управления это означает нахождение всех возможных путей в графе потока модуля. И
хотя такой вид испытаний является привлекательным в теории, обычно он невозможен на практике. Если
модуль имеет хотя бы один цикл, тогда покрытие путей может быть никогда не достижимо, поскольку один
цикл позволяет бесконечно возрастать числу путей.
Испытания черного ящика
Метод создания тестов черного ящика фокусируют свое внимание на функциональных требованиях к
ПО и к требованиям к отдельным свойствам его качества,
Испытание черного ящика не являются альтернативой испытаниям белого ящика. Скорее, это
дополнительный подход, который с большей вероятностью обнаружит различные классы ошибок, чем методы
белого ящика. В отличие от испытаний прозрачного (белого) ящика, испытания черного ящика применяются
на более поздних стадиях испытаний и фокусируют внимание на информационной области программы.
Разбиение по эквивалентности
Разбиение по эквивалентности (equivalence partitioning) - это метод испытаний черного ящика, который
разделяет область входных данных программы на классы данных, из которых могут быть получены тесты.
Разбиение по эквивалентности стремится построить такие тесты, которые позволяют обнаруживать целые
классы ошибок, тем самым уменьшая число тестов, которое должно было бы быть разработано в противном
случае.
Каждый класс эквивалентности (equivalence class) представляет собой множество допустимых или
недопустимых состояний для условий на входные данные, которые полностью проверят все функциональные
требования к программе. Обычно, входное условие - это либо конкретное числовое значение, либо диапазон
величин, либо множество связанных величин, либо логическое условие.
Класс эквивалентности может быть определен в соответствии со следующими рекомендациями.
1. Если входное условие специфицирует диапазон (range) величин, то определяется один допустимый
класс и два класса недопустимых (т.е. значения из диапазона, значения, меньшие минимума
диапазона и значения, большие максимума диапазона).
2. Если входное условие требует определенного значения (value), то определяется один допустимый
класс эквивалентности и два недопустимых класса.
3. Если входное условие специфицирует значение из множества (set), то определяется один
допустимый класс эквивалентности (значения множества) и один недопустимый (любое значение, не
принадлежащее множеству).
4. Если входное условие является логическим (Boolean), то определяется один допустимый класс
эквивалентности и один недопустимый.
Анализ граничных значений
Анализ граничных значений (АГЗ) - это метод разработки тестов, который является дополняющим для
метода разделения по эквивалентности. Этот метод ведет в выбору теста на "краях" класса, а не просто
выбирает любой из элементов в классе эквивалентности. Этот метод определяет тесты также и по области
выходных данных, а не только по входным условиям [Май82].
Рекомендации по АГЗ во многом аналогичны рекомендациям для разбиения по эквивалентности.
1. Если входное условие специфицирует диапазон (range), ограниченный значениями а и Ь, то должны
проектироваться тесты со значениям а и со значениями чуть большими, чем а и Ь, и со значениями чуть
меньшими, чем а и Ь.
2. Если входное условие специфицирует ряд значений, то должны разрабатываться тесты, в которых
представлены минимальные и максимальные значения. Кроме того, формируются тесты, в которых
представлены значения чуть большие и чуть меньшие максимума и минимума.
3. Рекомендации 1 и 2 применяются к выходным условиям. Например, в некоторой программе инженерного
анализа требуется построить таблицу зависимости температур от давлений как выходное данное. Тогда
должны разрабатываться тесты для создания выходного отчета с минимумом и максимумом допустимого
числа строк в таблице.
Большинство разработчиков программного обеспечения интуитивно в некоторой степени используют
АГЗ. С применением указанных выше рекомендаций тестирование границ будет выполнено более полно, тем
49
самым обеспечивая большую вероятность обнаружения ошибок.
Методы испытаний, основанные на графах
Чтобы осуществить эти шаги, разработчик ПО начинает с создания графа: множества узлов, которые
представляют объекты, дуг, которые отражают взаимосвязи между объектами, весов узлов, которые
описывают свойства узлов (например, конкретное значение данных или поведение) и весов дуг, которые
описывают некоторые характеристики связи.
При создании тестов их разработчик подробно изучает граф и покрывает тестами каждую из показанных
связей. Эти тесты создаются в попытке найти ошибки в любой из взаимосвязей.
Моделирование конечных состояний. Узлы представляют различные состояния программы,
наблюдаемые пользователями (например, каждый из "экранов", которые появляется, когда служащий,
вводящий заказы, принимает заказы по телефону), и эти связи представляют переходы, которые выполняются
для перехода из состояния в состояние. Диаграммы перехода из состояния в состояние могут использоваться
для создания графов такого типа.
Моделирование потоков данных. Узлы - это потоки данных, а связи - преобразования, которые
выполняются для перевода одного объекта данных в другой.
Моделирование графика выполнения. Узлы являются объектами программы, а связи - это
последовательные соединения между этими объектами. Веса связей используются для специфицирования
требующихся времен исполнения, когда выполняется программа.
Испытание графических интерфейсов с пользователем
Графические интерфейсы с пользователем - ГИП (graphical user interfaces - GUIs) - предоставляют широкие
возможности разработчикам программного обеспечения. Ввиду существования повторно используемых
компонентов, являющихся частями среды разработки ГИП, создание интерфейса с пользователем стало
относительно быстрым и более точным. В то же самое время, сложность ГИПов выросла, ведя к большим
трудностям в проектировании и применении тестов.
Поскольку современные ГИПы имеют в разных местах один и тот же вид и дают те же ощущения, то
может быть построен набор стандартных испытаний. Приводимые ниже примеры вопросов могут служить
руководством для создания общих испытаний для ГИПов.
Для окон:
• Будет ли окно открываться надлежащим образом, основанным на уместных печатаемых или основанных на
меню командах?
• Может это окно быть перемещено, прокручено, изменено в размерах?
• Является ли содержание всех данных, содержащихся в окне, надлежащим образом адресуемым с помощью
мыши, функциональных ключей, направленных стрелок и клавиатуры?
• Все ли функции, которые относятся к окну, имеются в наличии, когда это необходимо?
Испытание документации и средств подсказки
Ошибки в документации (документация относится к печатным материалам и диалоговым средствам
подсказки.) могут быть столь же весомы при признании программного средства неприемлемым, как и ошибки
в данных или исходном коде. Мало что может быть более разочаровывающим, чем точное следование
пользовательскому руководству и получение результатов или поведения, которые не согласуются с таковыми,
предсказанными этим документом. По этой причине, испытание документации должно быть значимой частью
любого плана испытаний программного обеспечения.
Испытание документации может осуществляться в двух фазах. Первая фаза, формальная техническая
экспертиза, проверяет документ с точки зрения редакторской ясности. Вторая фаза, «живые» испытания,
использует документацию в соединении с проверкой работы реальной программы.
Это неожиданно, но живое испытание документации может проводится с использованием методов,
которые аналогичны многим из методов испытаний черного ящика, обсуждавшимся выше. Испытания,
основанные на графах, могут использоваться для описания применения программы. Разделение на классы
эквивалентности и анализ граничных значений могут использоваться для определения различных классов
входных данных и связанных с ними взаимодействий. Тогда применение программы является
прослеживаемым по всей документации. Приводимые ниже вопросы могут быть составной частью проверки
документации.
• Точно ли описывает документация, как реализовать каждый из режимов использования?
• Является ли точным описание каждой последовательности взаимодействий?
• Согласуется ли терминология, описания меню и реакция системы с тем, что дает реальная программа?
• Если используются гипертекстовые связи, являются ли они точными и полными?
Считается, что единственный жизнеспособный путь ответить на подобные вопросы - иметь
50
независимую третью сторону (например, отобранных пользователей), чтобы испытать эту документацию в
контексте использования программы.
Стратегия испытаний ПО
Процесс технологии программного обеспечения может рассматриваться как подъем на некоторую пирамиду,
(техн-я системы -> требования -> проект -> код). На каждом последующем уровне пирамиды уменьшается
уровень абстракции того, что разрабатывается. Стратегия испытания программного обеспечения может
рассматриваться как спуск с пирамиды (Испытания модулей -> Испытания при объединении -> Испытания
для подтверждения -> Испытания системы).
Испытания единиц программы (модулей) (unit testing) начинаются на верхнем уровне «пирамиды».
Они устанавливают правильность каждого модуля. При тестировании модулей главным образом применяются
методы испытаний белого ящика, исполняя конкретные пути в структуре управления модуля, стараясь
обеспечить полное покрытие и максимум обнаружений ошибок.
Далее модули постепенно объединяются в некоторые "конгломераты", которые многократно
подвергаются испытаниям по мере увеличения в размерах. Это испытаниям при объединении (integration
testing). В них основное внимание фокусируется на проекте, т.е. устройстве программы. При этом решаются
сразу две задачи: построение программы или ее подтверждение. Методы создания тестов для черного ящика
являются наиболее распространенными во время объединения, хотя ограниченный объем испытаний белого
ящика может использоваться для обеспечения покрытия основных путей управления.
Когда программа собрана (построена), выполняется набор испытаний для подтверждения (validation
testing). Здесь разработанные программы проверяются на соответствия требованиям, установленным как часть
результата анализа требований к программному обеспечению. Они дают окончательное свидетельство того,
что программное обеспечение удовлетворяет всем требованиям к функциям, поведению и эксплуатационным
характеристикам. Только методы испытаний черного ящика используются при подтверждении.
И наконец, проводятся испытания системы (system testing), где программное обеспечение и другие
элементы системы испытываются как одно целое.
ПО, после того, как оно проверено, должно быть объединено с другими элементами системы (т.е.
аппаратурой, людьми и базами данных). Испытания системы (system testing) проверяет, "сцепляются" ли все
элементы надлежащим образом, и достигаются ли общие функции/эксплуатационные характеристики
системы.
Организация испытаний программного обеспечения
Когда начинаются испытания, всегда существует конфликт интересов людей, причастных к проекту. С
философской точки зрения, анализ и проектирование программного обеспечения (вместе с кодирование)
являются созидательной деятельностью. При испытаниях предпринимаются самые изощренные попытки
"разрушить" то, что "построил" разработчик. С точки зрения разработчика, испытание может рассматриваться
как (психологически) деструктивное. Поэтому, испытывая свою программу сам, разработчик работает так,
что демонстрирует работу его программы, а не разыскивая в ней ошибки. К сожалению, ошибки в программе
останутся. И если разработчик не найдет их, то их найдет заказчик!
Испытания при объединении
Процесс наращивания тестируемой программы отлаженными модулями называется интеграцией
программы.
После того, как все модули испытаны, проблема состоит в том, чтобы "собрать их всех вместе"
(проблема сопряжения).
В интерфейсах могут теряться данные; один модуль может иметь непреднамеренное, неблагоприятное
влияние на другой; объединяемые подфункции могут не давать желаемой общей функции; индивидуально
приемлемые неточности могут быть усилены до неприемлемого уровня; структуры глобальных данных могут
представлять проблемы. Список можно продолжать и продолжать.
Часто существует тенденция попытаться применить объединение без приращения (non-incremental
integration), т.е. собрать программу, использовав подход "большого взрыва" ("big bang"). В этом случае все
модули объединяются одновременно. Вся программа проверяется как единое целое. Обычно результатом
бывает хаос! Встречается множество ошибок. Их исправление является трудным, поскольку выделение
причин усложнено ввиду огромных размеров окончательной программы. После того, как эти ошибки
исправлены, появляются новые, и процесс продолжается в, по-видимому, бесконечном цикле.
Объединение с приращением (incremental integration) - это противоположность подходу большого взрыва
Программа собирается и испытывается маленькими сегментами, где ошибки легко отделить и исправить;
более вероятно проверить полностью интерфейсы; и может быть применен подход систематических
испытаний
Объединение сверху-вниз - это один из подходов с приращениями для построения структуры программы
Модули объединяются, спускаясь сверху-вниз по иерархии управления, начиная с главного управляющего
51
модуля (главной программы). Модули, подчиненные (и опосредованно подчиненные) главному
управляющему модулю встраиваются в структуру двумя путями- в глубину (depth-first) и в ширину (breadthfirst).
Объединение снизу-вверх - такая стратегия испытания модулей, которая начинает построение и испытания
модулей на самых низких уровнях в структуре программы, и подключает модули, восходя по иерархии
управления.
Испытание архитектур клиент/сервер
Архитектуры клиент/сервер (К/С) представляют значительный интерес для испытателей программного
обеспечения. Распределенная природа среды К/С, связанные с обработкой транзакций эксплуатационные
вопросы, потенциальное наличие различных аппаратных платформ, сложности обмена информацией в сети,
необходимость обслуживать множество клиентов из централизованной (или, в некоторых случаях,
распределенной) базы данных, и требования к координации, наложенные на сервер, все это объединяется,
чтобы сделать испытания архитектур К/С и программ и данных, которые постоянно находятся в них,
значительно более трудным, чем испытания самостоятельных приложений.
Испытания для подтверждения
Кульминацией испытаний при объединении является полное объединение программы. К этому времени
ошибки в интерфейсах уже обнаружены и исправлены, и может начинаться конечная серия испытаний испытания для подтверждения (validation testing).
Тестирование при комплексной отладке представляет собой применение ПС к конкретным данным,
которые в принципе могут возникнуть у пользователя (в частности, все тесты готовятся в форме,
рассчитанной на пользователя), но, возможно, в моделируемой (а не в реальной) среде. Например, некоторые
недоступные при комплексной отладке устройства ввода и вывода могут быть заменены их программными
имитаторами.
Разумность определяется в спецификации требовании - документе, который описывает все видимые
пользователем атрибуты ПО. Эта спецификация содержит раздел "Критерии подтверждения". Информация,
содержащаяся в этом разделе, является основой для подхода к испытаниям для подтверждения
Испытания системы
ПО соединяется с другими элементами системы (например, с новым оборудованием, информацией), и
проводится серия объединений системы и испытаний по ее подтверждению.
Управление и планирование в программных проектах
Менеджеры в организациях, создающих и сопровождающих программное обеспечение (программные
менеджеры – software managers) выполняют множество функций. Они ответственны за планирование
работ в проекте. Они следят за тем, чтобы работа выполнялась в соответствии с заданными
стандартами. Они наблюдают за ходом работ, чтобы убедиться в том, что разработка осуществляется
вовремя и в пределах бюджета. Хорошее управление не может гарантировать успех проекта. Плохое
управление обычно приводит к провалу проекта. В этом случае программное средство поставляется с
опозданием, стоит дороже, чем оценено первоначально, и не соответствует требованиям.
Понятия управления программными проектами
Программные менеджеры выполняют такую же работу, как и менеджеры в других инженерных проектах. Но
технология программирования во многих вопросах отличается от других типов инженерных
дисциплин. В частности, выделяют следующие отличия.
1. Продукт таких проектов является "неосязаемым".
2. Не существует стандартного процесса.
3. Большие программные проекты часто являются "особыми" проектами.
В этой главе рассматриваются основные понятия управления (менеджмента) программных проектов.
Процесс управления в стандарте ISO/IEC 12207
Процесс управления (management process) – один из организационных процессов стандарта ISO/IEC 12207.
Менеджер (manager) ответственен за управление продуктом, управление процессом и управление каждой
задачей применяемого(-ых) процесса(-ов).
Процесс управления включает в себя пять основных видов деятельности:
1) инициирование процесса и определение его сферы деятельности;
2) планирование процесса;
3) выполнение процесса и управление этим процессом;
52
4) экспертизу и оценивание;
5) закрытие процесса.
Инициирование и определение сферы деятельности процесса (initiation and scope definition).
Планирование процесса (planning). Одна, но важная задача. Менеджер разрабатывает планы для выполнения
процесса. Эти планы должны включать следующую (но могут включать и дополнительную)
информацию:
а) графики для своевременного завершения задач;
б) оценки необходимых усилий;
в) оценки ресурсов, необходимых для выполнения задач;
г) распределение задач между участниками процесса;
д) исполнителей;
е) количественные оценки рисков, связанных с задачами или самими процессами;
ж) метрики управления качеством, которые должны использоваться на протяжении всего процесса;
з) стоимости, связанные с выполнением процесса;
и) обеспечение средой выполнения и инфраструктурой.
Выполнение процесса и управление им (execution and control).
Экспертиза и оценивание (review and evaluation).
Закрытие (closure).
Спектр управления
Эффективное управление программными проектами фокусирует свое внимание на трех главных компонентах:
людях (people), проблеме (problem) и процессах (processes).
Люди
Модель зрелости способностей управления людьми (People Management Capability Maturity Model PM
CMM) определяет следующие ключевые области практики для людей в программном обеспечении: набор,
отбор, управление производительностью, обучение, вознаграждение, развитие карьеры, организация и
планирование работы, развитие бригады/культуры. Организации, которые достигают высоких уровней
зрелости в области управления людьми, имеют более высокую вероятность реализации эффективной
практики технологии программирования.
Проблема
До написания плана проекта должны быть установлены его цели и сфера охвата; должны быть
рассмотрены альтернативные решения; должны быть идентифицированы технические и управленческие
ограничения. Без этой информации невозможно определить разумные (и точные) оценки стоимости,
эффективную оценку риска, реалистичное разделение проекта на задачи или управляемый график проекта,
который обеспечивает понятную интерпретацию продвижения в проекте.
Процесс
Процесс разработки конкретного программного средства это схема (framework), используемая для
создания исчерпывающего плана разработки. Небольшое число видов деятельности схемы (framework
activities) применимы ко всем программным проектам, независимо от размера и сложности создаваемого
программного обеспечения. Множества задач (task sets) схемы, которыми могут быть собственно задачи из
ISO/IEC 12207, этапы графика работ, создание поставляемых документов и проведение мероприятий
обеспечения качества, дают возможность подгонять виды деятельности схемы под характеристики
конкретного программного проекта и требования бригады проекта. Охватывающие виды деятельности, такие
как обеспечение качества программных средств, управление конфигурацией программных средств и
собственно управление, накладываются на модель процессов. Охватывающие виды деятельности независимы
по отношению к видам деятельности схемы и осуществляются на протяжении всех процессов.
Виды деятельности по управлению
Большинство менеджеров имеют ответственность в некоторых или во всех следующих видах деятельности на
определенных этапах проекта:
в написании предложений;
в оценке стоимости проекта;
в планировании проекта и построении графика работ;
в контроле хода проекта и экспертизах;
в подборе кадров и их оценивании;
53
в написании отчетов и их представлении.
Написание предложений (proposal writing).
Планирование проекта и составление графика работ (project planning and scheduling).
Контроль хода проекта и экспертизы (project monitoring and reviews).
Подбор людей для работы в проекте (personal selection and evaluation). Проблемы.
Менеджеры проекта должны писать сжатые, согласованные документы, содержащих критичную информацию
из детальных отчетов проекта (report writing and presentation).
Планирование проекта
Эффективность управления программным проектом зависит от тщательности планирования хода работ в
проекте. Менеджер проекта должен предвидеть возможные проблемы и найти предварительные
решения этих проблем. План, подготовленный в начале проекта, должен использоваться как
управляющий документ проекта. Этот первоначальный план не является догмой, он должен изменяться
с ходом работ в проекте и с появлением более точной информации.
План
План качества
Описание
Описывает процедуры обеспечения качества и
стандарты, используемые в проекте
План
Описывает подход, ресурсы и график работ при
подтверждения
подтверждении системы
План управления
Описывает процедуры управления
конфигурацией
конфигурацией и структуры, которые должны
при этом использоваться
План
Прогнозирует требования к сопровождению
сопровождения
системы, стоимость сопровождения и
необходимые усилия
План
Описывает, как будут совершенствоваться
совершенствования мастерство и опыт членов команды проекта
персонала
Рис. 7. Типы планов.
Установить ограничения проекта
Сделать начальную оценку параметров проекта
Определить создаваемые в проекте документы и поставляемые документы
Продолжать, пока проект не завершен или не прекращен:
Составить график работ
Инициировать работы в соответствии с графиком
Ждать (некоторое время)
Провести экспертизу хода работ в проекте
Пересмотреть оценки параметров проекта
Изменить график работ
Заново обсудить ограничения проекта и поставляемые документы
Если возникают проблемы
Инициировать техническую экспертизу и возможный пересмотр
Конец Если
Конец Продолжать
Рис. 8. Процесс планирование проекта.
План проекта
План проекта устанавливает ресурсы, необходимые для выполнения проекта, распределение работ и график
для выполнения этих работ. Большинство планов должны включать в себя следующие разделы.
1. Введение.
2. Организация проекта.
3. Анализ рисков.
54
4. Требования к необходимым аппаратным и программным ресурсам.
5. Распределение работ.
6. График выполнения работ в проекте.
7. Механизмы контроля и отчеты.
Каждый план проекта должен регулярно пересматриваться по ходу проекта.
Организация работы
Менеджеры нуждаются в информации. Программное обеспечение неосязаемо, информация может быть
представлена только в форме документов, описывающих выполненную работу.
Когда планируется проект, то устанавливается серия контрольных точек, где каждый такая точка является
конечной точкой в некотором виде деятельности в программном проекте. В каждой такой контрольной
точке менеджменту должен быть представлен формальный отчет о ходе работ. Эти контрольные точки
должны представлять конец некоторого явно выраженного этапа в проекте.
Поставляемые (подлежащие сдаче) документы и программы (deliverables) являются результатом проекта,
поставляемым заказчику. Подлежащие сдаче документы – отчетные документы (т.е., milestones).
Однако, отчетные документы не обязательно подлежат поставке заказчику.
Задачи
Исследование
реализуемости
Анализ
требований
Разработка
прототипа
Исследование при
проектировании
Специфицирование
требований
Отчет о
реализуемости
Определение
требований
Отчет об
оценивании
Архитектурный
проект
Спецификация
требований
Отчетные документы
Рис. 9. Отчетные документы в процессе установления требований.
Одна из причин широкого распространения каскадной модели программного процесса – она обеспечивает
прямое определение контрольных точек на протяжении всего проекта.
Управление рисками
Риски программного обеспечения
Нет общепринятого определения понятия риск программного обеспечения (software risk). Но есть два
обязательных компонента риска: неопределенность (uncertainty) и потери (loss).
Ответная и профилактическая стратегии рисков
Ответная (reactive) стратегия рисков может быть представлена следующими словами: "Не
следует беспокоится о проблемах, пока они не произойдут.
К сожалению, большинство бригад разработчиков программных средств надеются
исключительно на ответные стратегии рисков. Чаще всего бригада программного обеспечения не
делает ничего с рисками, пока что-нибудь не идет плохо. Тогда бригада впадает в "кипучую
деятельность" в попытке быстро исправить положение. При этом зачастую проект находится в
реальной опасности.
Значительно более разумной стратегией для управления рисками является профилактическая
(proactive). Она начинает реализовываться задолго до того, как начнется техническая работа.
Идентифицируются потенциальные риски,
оцениваются их вероятности и влияние, и они располагаются по важности.
Затем бригада проекта устанавливает план управления рисками.
Идентификация рисков
Один из методов идентификации рисков заключается в создании контрольного списка рисков (a
risk item checklist). Этот контрольный список может использоваться для идентификации рисков, и он
фокусирует свое
внимание на подмножестве известных и
предсказуемых рисков по
подкатегориям.
55
Размер продукта
Коммерческое влияние
Характеристики заказчика
Определение процессов
Среда разработки
Технология, которая должна быть разработана
Размеры бригады и ее опыт
Компоненты и причины возникновения риска
Компоненты риска программного средства (software risk components):
риск эксплуатационных характеристик,
риск стоимости,
риск поддержки,
риск графика работы.
Разработка таблицы рисков
Риски
Кате- Вероят- Влияние RMMM
гория ность
Оценка размера может быть существенно заниженной
PS
60
2
Большее число пользователей, чем было запланировано
PS
30
3
Меньше повторного использования, чем было запланировано
PS
70
2
Конечные пользователи противодействуют системе
BU
40
3
Срок поставки будет отодвинут
BU
50
2
Финансирование будет потеряно
CU
40
1
Заказчик изменит требования
PS
80
2
Технология не будет удовлетворять ожиданиям
TE
30
1
Недостаток обучения на готовых средствах
DE
80
3
Члены команды не имеют достаточного опыта
ST
30
2
Текучесть кадров будет высокой
ST
60
2
Категория: PS - Program Size; BU -BUsiness risks; CU - CUstomer risks; TE - TEchnology risks;
DE - DEvelopment risks; ST - STuff risks.
Значения влияния: 1 – катастрофическое, 2 – критическое, 3 – предельное, 4 – несущественное.
Рис 10. Простая таблица рисков до сортировки.
Оценивание влияния риска
Три фактора влияют на последствия, которые вероятны, если риск действительно реализуется: его природа,
его охват и его время.
Смягчение рисков, контроль и управление
Эффективная стратегия управления рисками должна рассматривать три вопроса:
избежание рисков;
контроль рисков и
управление рисками и планирование непредвиденных ситуаций.
Процесс управления конфигурацией
"Искусство координирования разработки программного обеспечения для минимизации ... путаницы
называется управлением конфигурацией. Управление конфигурацией искусство идентификации,
организации и управления модификациями разрабатываемого программного средства командой
разработчиков. Целью этих действий является максимизация продуктивности при минимизации
ошибок" [Pressman-97].
Управление конфигурацией программного средства (УКПС) охватывающая деятельность, осуществляемая
на протяжении всего жизненного цикла программного средства.
Различия между сопровождением программного средства и УКПС.
Процесс Управления Конфигурацией (Configuration Management Process) процесс применения
административных и технических процедур на протяжении жизненного цикла программного средства
для:
1) идентификации, определения и превращения в эталоны основных компонентов программного
средства в системе;
56
управления изменениями и выпусками этих компонентов;
создания отчетов о состоянии компонентов и запросов на изменение;
обеспечения полноты, непротиворечивости и правильности этих компонентов и
управления хранением, манипулированием и поставкой компонентов.
Основные понятия управления конфигурацией программного средства
Результат программного процесса:
1) программы для ЭВМ (в исходном и исполняемом представлении),
2) документы, описывающие компьютерные программы (и предназначенные как для разработчиков, так
и для пользователей), и
3) данные (содержащиеся в программах или являющиеся внешними по отношению к ней).
Все это вместе называется конфигурацией программного средства (software configuration).
Согласно Первому закону технологии разработки систем [Pressman-97]: Не важно, в каком месте
жизненного цикла вы находитесь, система будет изменяться, и желание изменить ее будет
сохраняться на протяжении всего жизненного цикла.
2)
3)
4)
5)
Другие поддерживающие процессы жизненного цикла
Процесс документирования - это процесс записи информации, произведенной процессом ЖЦ или
отдельным видом деятельности. Он включает в себя следующие ВД:
реализация документирования: разрабатывается план, идентифицирующий все необходимые документы
ЖЦ, для каждого из которых указывается название, назначение, аудитория, для которой он предназначен,
ответственных за входную информацию, разработку, экспертизу, сопровождение и т.п., график создания
промежуточной и окончательной версий;
проектирование: решается задача применение стандартов, утверждается источник входных данных;
производство: документы производятся в соответствии с планом, проходят экспертизу для формы и
содержания;
сопровождение: решаются задачи, связанные с изменением документации, для ряда документов в
соответствии с процессом управления конфигурацией.
Процесс проверки правильности - это процесс установления, удовлетворяют ли программные
продукты, произведенные при выполнении некоторого вида деятельности технологии программирования,
требованиям или условиям, наложенным на них в предыдущих видах деятельности.
1. Проверка правильности контракта (contract verification). Контракт должен быть проверен с
рассмотрением таких критериев, как:
• требования непротиворечивы и покрывают потребности пользователей;
• процедуры и их протяженность для взаимодействия и сотрудничества между сторонами оговорены,
включая права собственности, выдаваемые гарантии, авторские права и секретность информации;
• критерии и процедуры приемки оговорены в соответствии с требованиями.
3. Проверка правильности требований (requirements verification). Требования должны быть проверены с
рассмотрением критериев, приводимых ниже:
• требования к системе непротиворечивы, осуществимы и проверяемы;
• требования к системе были надлежащим образом разделены по подсистемам аппаратуры ЭВМ,
подсистемам программного обеспечения и ручным операциям в соответствии с критериями проекта (design
criteria);
• требования к программному обеспечению непротиворечивы, реализуемы, проверяемы и точно
отражают системные требования;
• требования к программному обеспечению, относящиеся к сохранности, безопасности и критичности,
правильны, что показано подходящими строгими методами.
4. Проверка правильности проекта (design verification). Проект должен быть проверен с рассмотрением
критериев:
• проект согласуется с требованиями и прослеживается в них;
• проект реализует надлежащую последовательность событий, входных и выходных данных,
интерфейсов, потока логики, размещение по времени и памяти и установление и локализацию ошибок и
восстановление;
57
• выбранный проект может быть получен из требований;
• проект реализует сохранность, безопасность и другие критические требования правильно, что показано
подходящими строгими методами.
5. Проверка правильности кода (code verification). Код должен быть проверен с рассмотрением критериев,
приводимых ниже:
• код является прослеживаемым в проекте и требованиях, проверяемым, правильным и согласующимся
с требованиями и со стандартами кодирования;
• код
реализует
правильную
последовательность
событий, непротиворечивые интерфейсы,
правильные потоки управления и данных, завершенность, надлежащее согласование по времени размещения
и оценку размеров, определение и локализацию ошибок и восстановление;
• выбранный код может быть получен из проекта и требований;
• код реализует сохранность, безопасность и другие критические требования правильно, что показано
подходящими строгими методами.
6. Проверка правильности комплексирования (integration verification). Комплексирование должно
проверяться с рассмотрением критериев:
• части и компоненты каждой подсистемы программного средства были полностью и правильно
объединены в подсистему программного средства;
• подсистемы аппаратуры ЭВМ, подсистемы программного средства и ручные операции системы
полностью и правильно объединены в систему;
• задачи комплексирования были осуществлены в соответствии с планом комплексирования.
7. Проверка правильности документации (documentation verification). Документация должна быть
проверена с рассмотрением критериев, приводимых ниже:
• документация является адекватной, завершенной и непротиворечивой;
• подготовка документации осуществлена вовремя;
• управление конфигурацией документов следует установленным процедурам.
Процесс подтверждения.
Процесс подтверждения (validation process) - это процесс определения, соответствуют ли: (1)
требования к системе или программному продукту, а также (2) разработанная система или программный
продукт их конкретному предназначению. Подтверждение может проводиться на ранних стадиях. Оно может
проводиться как часть поддержки приемки программного средства.
Этот процесс может выполняться с той или иной степенью независимости. В случае, когда процесс
выполняется организацией, независимой от поставщика, разработчика, эксплуатационника или специалистом
по сопровождению, она называется независимым процессом подтверждения (independent validation process).
1. Подготовка подтверждения. Необходимо подготовить выбранные требования к испытаниям,
тестовые ситуации и спецификации испытаний для анализа результатов испытаний.
2. Уточнение исходных данных. Обеспечить, чтобы эти требования к испытаниям, тестовые ситуации и
спецификации испытаний отражали частные требования для конкретного подразумеваемого использования.
3. Испытания. Провести испытания, используя данные двух первых задач, включая:
• проверку с данными на перегрузку, границы и особые ситуации;
• проверку программного продукта на его способность изолировать и минимизировать влияние ошибки,
т.е. постепенное сокращение возможностей при несоответствии, запрос помощи у оператора при
перегрузке, граничных или особых условиях;
• проверку, что выбранные для испытаний пользователи могут успешно достичь решения своих задач,
используя программный продукт.
4. Подтверждение. Подтвердить, что программный продукт удовлетворяет использованию, для
которого он предназначен.
5. Специализированные испытания. Испытать программный продукт так, как это должно делаться, в
той прикладной области, для которой создан продукт.
Процесс совместной экспертизы.
Процесс совместной экспертизы (joint review process) - это процесс для оценивания состояния и
продуктов некоторой деятельности проекта в зависимости от предназначения. Совместные экспертизы
58
осуществляются как на уровне структуры управления проекта, так и на техническом уровне и выполняются на
протяжении всего жизненного цикла контракта. Этот процесс может быть задействован любой из двух
сторон, где одна сторона (проверяющая сторона) проверяет другую сторону (проверяемую сторону).
3. Вопросы экспертизы. Стороны должны договориться о следующих вопросах для каждой экспертизы:
повестке встречи, программных продуктах (результатах деятельности) и проблемах, для которых должна быть
проведена экспертиза; сфере рассмотрения и процедурах; входных и выходных критериях для экспертизы.
5. Регистрация и распространение результатов экспертизы. Результаты экспертизы должны быть
зарегистрированы и распространены. Проводящая экспертизу сторона должна подтвердить проверяемой
стороне адекватность (например, одобрение, неодобрение или частичное одобрение) результатов экспертизы.
Технические экспертизы (technical review). Эта деятельность состоит из одной задачи. Должны
проводиться технические экспертизы для оценивания рассматриваемых программных продуктов или
обслуживания и получения доказательств того, что:
• они завершены;
• они согласуются со своими спецификациями и со стандартами;
• их изменения реализованы надлежащим образом и влияют только на те области, которые указаны
процессом управления конфигурацией;
• они придерживаются соответствующих графиков;
• они готовы для следующей деятельности;
• разработка, эксплуатация или сопровождение проводится в соответствии с планами, графиками,
стандартами и руководствами проекта.
Процесс ревизии.
Процесс ревизии (audit process) - это процесс определения согласованности с требованиями, планами и
контрактом в зависимости от предназначения. Это процесс может быть задействован любой из обеих сторон,
где одна сторона (проверяющая сторона) проверяет программные продукты или деятельность другой стороны
(проверяемой стороны).
Список видов деятельности.
1. Организация ревизий. В предопределенных точках, как это специфицировано в плане проекта, должны
быть проведены ревизии.
2. Распределение ответственностей. Проверяющий персонал не должен иметь какой-либо прямой
ответственности за программные продукты и виды деятельности, которые он проверяет.
5. Разрешение проблем, выявленных при ревизии. Проблемы, обнаруженные во время ревизии, должны
быть записаны и введены в процесс разрешения проблем, как это определено в этом процессе.
6. Представление результатов ревизии. После завершения ревизии ее результаты должны быть
документированы и представлены проверяемой стороне. Проверяемая сторона должна признать проверяющей
стороне любые проблемы, найденные в ревизии, и связанные с ними запланированные действия по
разрешению проблем.
Ревизия (audit). проводится, чтобы гарантировать, что:
• закодированные программные продукты (такие, как компонент программы) отражают проектную
документацию;
• требования к экспертизе и приемочным испытаниям, предписываемые документацией, адекватны
приемке программных продуктов;
• испытательные данные (тесты) согласуются со спецификациями;
• программные продукты были успешно испытаны и удовлетворяют их спецификациям;
• отчеты об испытаниях верны, и расхождения между действительными и ожидаемыми результатами
разрешены;
• пользовательская документация согласуется со стандартами оговоренным образом;
• виды деятельности проводились согласно применимым требованиям, планами и контрактом;
• стоимости и графики придерживаются установленных планов.
Процесс разрешения проблем – это процесс анализа и разрешения проблем (включая несоответствия)
независимо от их природы и источника, которые вскрываются при выполнении процессов разработки,
эксплуатации, сопровождения или других процессов. Цель этого процесса - обеспечить своевременные,
ответственные и документированные средства, чтобы гарантировать, что обнаруженные проблемы
59
проанализированы и разрешены и тенденции распознаны.
Список видов деятельности.
Должен быть установлен процесс разрешения проблем для обработки всех проблем (включая
несогласованности), обнаруженных в программных продуктах и видах деятельности. Этот процесс должен
удовлетворять следующим требованиям.
1. Этот процесс должен быть замкнутым, гарантирующим, что: (а) обо всех обнаруженных проблемах
немедленно сообщается, и (б) они вводятся в процесс разрешения проблем; (в) по ним инициируется
действие; (г) заинтересованные стороны извещаются о существовании проблемы надлежащим образом; (д)
причины идентифицируются, анализируются и, когда это возможно, устраняются; (е) достигаются
разрешение проблемы, и все "расставляется по местам"; (ж) состояние прослеживается и о нем сообщается;
протоколы проблем сопровождаются, как это обусловлено в контракте.
2. Этот процесс должен содержать схему для разделения проблем по категориям и установления их
приоритетов. Каждая проблема должна быть классифицирована указанием категории и приоритета для
облегчения анализа тенденций и разрешения проблемы.
После того, как проблемы (включая несогласованности) были выявлены в программных продуктах или
видах деятельности, должен быть подготовлен отчет о проблеме для описания каждой обнаруженной
проблемы. Отчет о проблемах должен использоваться как часть замкнутого процесса, описанного выше: от
обнаружения проблемы, через исследование, анализ и разрешение этой проблемы и ее причины, и к
обнаружению тенденций через проблемы.
60
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
«Дальневосточный федеральный университет»
(ДВФУ)
ШКОЛА ЕСТЕСТВЕННЫХ НАУК
МАТЕРИАЛЫ ДЛЯ ОРГАНИЗАЦИИ САМОСТОЯТЕЛЬНОЙ РАБОТЫ СТУДЕНТОВ
по дисциплине «Технология разработки программного обеспечения»
010503.65 Математическое обеспечение и администрирование информационных систем
61
Задания на самостоятельную работу студенты получают по ходу
процесса изложения лекционного материала.
Задания по теме 2:
1) построение модели системы,
2) оформление списка пользовательских требований на разработку
программной системы.
Задания по теме 3:
1) построение модели анализа информации для программного обеспечения
системы,
2) построение модели анализа поведения для программного обеспечения
системы,
3) построение модели анализа функций для программного обеспечения
системы,
Задание по теме 4:
1) построение модели
обеспечения системы.
архитектурного
Задание по теме 5:
1) подготовке тестовых
обеспечения системы.
ситуаций
для
проекта
для
программного
испытаний
программного
Отчеты о выполнении каждого из заданий предоставляется в
рукописном, печатном или электронном виде (по желанию обучаемого).
Предусмотрена первичная проверка заданий, после которой на основании
замечаний и комментариев студент дорабатывает форму и содержание
каждого задания. Затем выполненное задание оценивается преподавателем и
является показателем усвоения лекционного материала. Контроль
самостоятельной работы осуществляется преподавателем в течение всего
семестра
62
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
«Дальневосточный федеральный университет»
(ДВФУ)
ШКОЛА ЕСТЕСТВЕННЫХ НАУК
КОНТРОЛЬНО-ИЗМЕРИТЕЛЬНЫЕ МАТЕРИАЛЫ
по дисциплине «Технология разработки программного обеспечения»
010503.65 Математическое обеспечение и администрирование информационных систем
63
Текущий контроль
Текущий контроль состоит в проверке правильности выполнения заданий
к самостоятельной работе (см. предыдущий раздел), а также проведении
контрольных работ на знание теоретического материала курса. Ниже
приведена тематика контрольных работ. Списки вопросов составляются в
соответствии с соответствующим планом лекций.
Тематика контрольных работ
Тема 1.
Основные вопросы организации программных процессов.
Вариант 1.
1. Роль программного обеспечения. Возрастание роли технологии
программирования.
2. Процессы, методы и средства технологии программирования.
3. Международный стандарт ISO/IEC 12207:1995.
4. Методы четвертого поколения и другие модели разработки ПО.
5. Спиральная модель.
Вариант 2.
1. Некоторые характеристики программного обеспечения.
2. Обобщенный взгляд на технологию программирования.
3. Линейная последовательная модель.
4. Модель прототипирования.
5. Рациональный унифицированный процесс.
Вариант 3
1. Классификация приложений программного обеспечения.
2. Процессы программного обеспечения.
3. Модели процессов программного обеспечения.
4. Модель с приращениями.
5. Модель зрелости процессов.
Тема 2.
Основные вопросы системной инженерии.
Вариант 1
1.Вычислительная система.
2.Методы выявления требований.
3.Обзор технологии систем.
4.Область анализа: повторное использование, процесс анализа в области.
5.Разработка модели системы в шаблоне «ввод-обработка-вывод».
6.Спецификация системы.
64
Вариант 2
1. Цели и виды деятельности инженерии требований к системе.
2. Моделирование потребности заказчика.
3. Процесс анализа предметной области.
4. Модели архитектуры системы: стили, шаблоны.
5. Исследование реализуемости системы. Диаграммы размещения.
6. Экспертиза спецификации.
Тема 3.
Основные вопросы анализа программного обеспечения.
Вариант 1.
1.
Принципы анализа: информационная область, моделирование,
разделение на части, ракурсы видения основной информации и деталей
реализации.
2.
Функциональное моделирование и поток информации: Диаграммы
потоков данных.
3.
Выполнение структурного анализа: создание диаграммы связей между
объектами, модели потока данных, модели поведения.
4.
Специфицирование требований к программному обеспечению.
Экспертиза спецификации.
Вариант 2.
1.
Элементы модели анализа. Моделирование данных: объекты, свойства и
связи данных, словарь данных, диаграммы связей между объектами.
2.
Моделирование поведения. Диаграммы перехода состояний, таблицы
решений, схемы диалога с пользователем.
3.
Объектно-ориентированный (ОО) анализ: сравнение подходов. Базовые
компоненты модели ОО анализа. Процесс ОО анализа.
4.
Выполнение ОО анализа. Модель связей между объектами. Модель
поведения объектов.
Тема 4.
Основные вопросы проектирования программного обеспечения.
Вариант 1.
1.
Принципы анализа: информационная область, моделирование,
разделение на части, ракурсы видения основной информации и деталей
реализации.
2.
Функциональное моделирование и поток информации: Диаграммы
потоков данных.
3.
Выполнение структурного анализа: создание диаграммы связей между
объектами, модели потока данных, модели поведения.
4.
Специфицирование требований к программному обеспечению.
Экспертиза спецификации.
65
Вариант 2.
1.
Элементы модели анализа. Моделирование данных: объекты, свойства и
связи данных, словарь данных, диаграммы связей между объектами.
2.
Моделирование поведения. Диаграммы перехода состояний, таблицы
решений, схемы диалога с пользователем.
3.
Объектно-ориентированный (ОО) анализ: сравнение подходов. Базовые
компоненты модели ОО анализа. Процесс ОО анализа.
4.
Выполнение ОО анализа. Модель связей между объектами. Модель
поведения объектов.
Вопросы к экзамену
1. Программные продукты.
2. Обобщенный взгляд на технологию программирования.
3. Процессы программного обеспечения.
4. Международный стандарт ISO/IEC 12207:1995.
5. Модели процессов программного обеспечения.
6. Линейная последовательная модель. Модель прототипирования.
7. Эволюционные модели программных процессов. Спиральная модель.
8. Методы четвертого поколения и другие модели разработки ПО.
9. Модель зрелости процессов
10.Понятия управления программными проектами.
11.Метрики программных процессов и проектов.
12.Планирование программного проекта.
13.Управление рисками.
14.Системная инженерия. Цели и виды деятельности инженерии требований к
системе.
15.Компьютерная система. Основные элементы.
16. Процесс анализа предметной области. Область анализа: повторное
использование.
17.Методы идентификации потребностей. Моделирование потребности
заказчика.
18.Модели архитектуры системы: стили, шаблоны.
19.Разработка модели системы в шаблоне «ввод-обработка-вывод».
20.Анализ реализуемости. Диаграммы размещения.
21.Понятия и принципы анализа.
22.Моделирование при анализе.
23. Понятия и принципы проектирования.
24.Методы проектирования.
25.Объектно-ориентированные понятия и принципы.
66
26.Объектно-ориентированный анализ.
27.Объектно-ориентированное проектирование.
28.Проектирование интерфейсов: внешний и внутренний интерфейсы.
29.Процедурное проектирование: методы представления модулей.
30.Процесс проектирования объектов.
31.Проверка согласованности моделей ОО анализа и проектирования. ОО
метрики и оценивание.
32.Методы и стратегии испытаний программного обеспечения.
33.Разработка тестов. Испытания белого ящика. Испытания черного ящика.
34.Разбиение по эквивалентности, анализ граничных значений.
35.Тестирование модулей, процедуры испытания модулей.
36.Испытания при объединении.
37.Испытания для подтверждения. Испытания системы.
38.Стратегии ОО испытаний: испытания методов, испытания при
объединении, испытания для подтверждения.
39.Методы испытаний, применимые на уровне классов.
40.Проектирование тестов для "межклассовых" испытаний.
67
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
«Дальневосточный федеральный университет»
(ДВФУ)
ШКОЛА ЕСТЕСТВЕННЫХ НАУК
СПИСОК ЛИТЕРАТУРЫ
по дисциплине «Технология разработки программного обеспечения»
010503.65 Математическое обеспечение и администрирование информационных систем
68
Основная литература 1. Гагарина Л.Г. Технология разработки программного обеспечения //
ИНФРА-М, 2008. - 400 с.
2. Лаврищева Е.М., Петрухин В.А. Методы и средства инженерии
программного обеспечения. – Учебник. Московский физико-технический
институт (государственный университет), 2006
3. Липаев, В.В. Программная инженерия. Методологические основы [Текст] :
Учеб. / В. В. Липаев ; Гос. ун-т — Высшая школа экономики. — М. : ТЕИС,
2006. — 608 с. (есть в библиотеке ДВФУ).
4. Соммервилл И. Инженерия программного обеспечения. 6-е издание. М.:
Изд. дом Вильямс, 2002. – 624 с. (есть в библиотеке ДВФУ)
Дополнительная литература
Тема «Модели процессов программного обеспечения»
Браудэ Э. Технология разработки программного обеспечения,
Издательский дом «Питер», 2004 год, 656 с. (в библиотеке ДВФУ: Ч/З
естественных наук, ауд 303, шифр Б 875 32.973)
Калайда В.Т., Романенко В.В. Технология разработки программного
обеспечения: Учебное пособие. — Томск: Томский межвузовский центр
дистанционного
образования,
2007.
—
257
с.
http://www.twirpx.com/file/812577/
Жоголев. Е. А. Технология программирования. Москва : Научный мир ,
2004. 215 c. (в библиотеке ДВФУ)
Тема «Специфицирование требований к программному обеспечению»
Вигерс К. И. Разработка требований к программному обеспечению (2е
издание). Издательство: Microsoft Press, Русская Редакция, 2004. - 576 с.
http://www.twirpx.com/file/1073166/
Тема «Архитектурное проектирование»
Орлов С.А. Технологии разработки программного обеспечения. СПб:
Питер, 2002. 464 с. (есть в библиотеке ДВФУ)
Тема «Процесс управления. Виды деятельности по управлению
проектом»
Фатрелл Р.Т., Шафер Д.Ф., Шафер Л.И. Управление программными
проектами: достижение оптимального качества при минимуме затрат. М:
Издательский дом “Вильямс”, 2003. http://www.twirpx.com/file/116119/
69
Интернет-ресурсы
1. http://www.twirpx.com/file/52048/ Брукс М. Как проектируются и создаются
программные комплексы. – М.: Символ-Плюс, 2004. – 304 с.
2. http://www.twirpx.com/file/5956/Соммервилл И. Инженерия программного
обеспечения. 6-е издание. М.: Изд. дом Вильямс, 2002. – 624 с.
3. http://log-in.ru/books/metody-i-sredstva-inzhenerii-programmnogoobespecheniya-uchebnoe-posobie-lavrisheva-e-m-petrukhin-v-a-programming/
Лаврищева Е.М., Петрухин В.А. Методы и средства инженерии
программного обеспечения. – Учебник. Московский физико-технический
институт (государственный университет), 2006
4. http://www.twirpx.com/file/40292/ Гагарина Л.Г. Технология разработки
программного обеспечения // ИНФРА-М, 2008. - 400 с.
5.
http://www.twirpx.com/file/7349/ Липаев, В.В. Программная инженерия.
Методологические основы [Текст] : Учеб. / В. В. Липаев ; Гос. ун-т —
Высшая школа экономики. — М. : ТЕИС, 2006. — 608 с.
70
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
«Дальневосточный федеральный университет»
(ДВФУ)
ШКОЛА ЕСТЕСТВЕННЫХ НАУК
ГЛОССАРИЙ
Технология разработки программного обеспечения
010503.65 Математическое обеспечение и администрирование информационных систем
71
1. Абстрагирование от проблемы — игнорирование ряда подробностей с тем,
чтобы свести задачу к более простой задаче.
2. Абстрактная машина Дейкстры — применяется в проектировании
архитектуры системы, самый нижний уровень абстракции — это уровень
аппаратуры. Каждый уровень реализует абстрактную машину с все
большими возможностями.
3. Абстрактный родительский класс — родительский класс, не имеющий
экземпляров объектов.
4. Абстракция — мысленное отвлечение, обособление от тех или иных
сторон, свойств или связей предметов и явлений для выявления
существенных их признаков.
5. Абстракция сущности — произвольная абстракция. Объект представляет
собой полезную модель некой сущности в предметной области.
6. Автоматизированная система (АС) — организационно-техническая
система, обеспечивающая выработку решений на основе автоматизации
информационных процессов в различных сферах деятельности
(управление, проектирование, производство и т. д.) или их сочетаниях,
система, состоящая из персонала и комплекса средств автоматизации его
деятельности, реализующая информационную технологию выполнения
установленных функций.
7. Автономное тестирование (тестирование модуля) (module testing) —
контроль отдельного модуля в изолированной среде (например, с
помощью ведущей программы), инспекция текста модуля на сессии
программистов,
которая
иногда
дополняется
математическим
доказательством правильности модуля.
8. Агрегированный объект — объект, составленный из подобъектов.
Подобъекты называются частями агрегата, и агрегат отвечает за них.
9. Алгоритм — строго однозначно определенная для исполнителя
последовательность действий, приводящих к решению задачи.
10.Альфа-тестирование
(системное
тестирование,
лабораторные
испытания) — фаза тестирования, выполняемая разработчиками для
подтверждения, что все фрагменты правильно интегрированы в систему, а
сама система работает надежно.
11.Анализ (от греч. analysis — разложение, расчленение) — прием умственной
деятельности, связанный с мысленным (или реальным) расчленением на
части предмета, явления или процесса. В теории проектирования анализ —
это процесс определения функционирования по заданному описанию
системы.
72
12.Артефакт реализации — нечто, что нельзя обнаружить в постановке
решаемой задачи, но необходимое для составления программы.
13.Архитектура системы — структура объединения нескольких
программных средств в одно целое.
14.АС — см. автоматизированная система.
15.Аттестация (certification) — авторитетное подтверждение правильности
программы.
16.Бета-тестирование — это фаза общего тестирования, при которой
программное изделие поставляется ограниченному кругу конечных
пользователей для более жесткого тестирования.
17.Блочно-иерархический подход — частный эвроритм системного подхода,
при котором процесс проектирования и представления о самом объекте
расчленяется на иерархические уровни. На высшем уровне используется
наименее детализированное представление, отражающее самые общие
черты и особенности проектируемой системы. На каждом новом
последовательном уровне разработки степень подробности рассмотрения
возрастает, при этом система рассматривается не в целом, а отдельными
блоками..
18.Визуальное моделирование — процесс графического представления модели
с помощью некоторого стандартного набора графических элементов.
19.Внедрение — стадия, по завершении которой программная документация
размножена в нужном количестве, программа установлена и
сопровождается, пользователи обучены.
20.Восстанавливаемость
программного
обеспечения
—
свойство,
характеризующее возможность приспосабливаться к обнаружению ошибок
и их устранению.
21.Генетический анализ — исследование объекта на его соответствие законам
развития программных систем. В процессе анализа изучается история
развития (генезис) исследуемого объекта: конструкции аналогов и
возможных частей, технологии изготовления, объемы тиражирования,
языки программирования и т. д.
22.ГОСТ— государственный стандарт.
23.Деструктор — особый метод самого объекта, обеспечивающий
уничтожение данного объекта.
24.Диаграмма вариантов использования — диаграмма, которая отображает
взаимодействие между вариантами использования, представляющими
функции системы, и действующими лицами, представляющими людей или
системы, получающие или передающие информацию в данную систему.
73
25.Диаграмма классов — диаграмма, отражающая взаимодействие между
классами системы.
26.Диаграмма компонент — диаграмма, показывающая, как выглядит модель
на физическом уровне. На ней изображаются компоненты (файлы)
программы и связи между ними.
27.Диаграмма кооперативная — диаграмма, отражающая ту же самую
информацию, что и диаграммы последовательности, но связь со временем
отсутствует.
28.Диаграмма последовательности — диаграмма, отражающая поток
событий, происходящих в рамках варианта использования.
29.Диаграмма потоков данных (ДПД) — диаграмма, описывающая порядок
изменения данных от их источников через преобразующие их процессы к
их потребителям.
30.Диаграмма размещения — диаграмма, показывающая физическое
расположение различных компонентов программной системы в сети.
31.Диаграмма состояний — диаграмма, предназначенная для моделирования
различных состояний, в которых может находиться объект. В то время как
диаграмма классов показывает статическую картину классов и их связей,
диаграмма состояний применяется при описании динамики поведения
системы.
32.Динамическая переменная — это как бы статическая переменная, но
размещаемая в особой области памяти вне кода программы. В любой
момент времени память для размещения динамических переменных может
как выделяться, так и освобождаться.
33.Динамические структуры данных являются связными. Связность —
особое продуманное логическое устройство сохранения целостности
структуры данных, элементы которой могут находиться в произвольных,
несмежных, неконтролируемых по адресации участках динамически
распределяемой памяти вне кода программы.
34.Динамическое связывание — ассоциация запроса с объектом и одной из его
операций во время выполнения.
35.Доказательство (proof) — попытки найти в программе ошибки путем
доказательств на основе математических теорем о правильности
программы, безотносительно к внешней программной среде.
36.Документ — документ, выполненный по заданной форме, в котором
представлено какое-либо проектное решение.
37.ДПД — Диаграмма потоков данных.
38.Единая система программной документации (ЕСПД) — комплекс
государственных стандартов, устанавливающий взаимоувязанные правила
74
разработки, оформления и обращения программ и программной
документации.
39.ЕСПД — Единая система программной документации.
40.Жизненный цикл — совокупность взаимосвязанных процессов создания и
последовательного изменения состояния продукции от формирования к
ней исходных требований до окончания ее эксплуатации или потребления.
41.Заглушка — макет еще не реализованного модуля, необходимый при
нисходящей реализации, представляет собой простейшую подпрограмму
либо без действий, либо с действиями вывода входных данных, либо
возвращающую в вышестоящие модули тестовые данные (которые обычно
присваиваются внутри заглушки), либо содержащий комбинацию этих
действий.
42.Иерархия — подчиненность.
43.Изменчивость структуры данных — изменение числа элементов и (или)
связей между элементами структуры. В определении изменчивости
структуры не отражен факт изменения значений элементов данных,
поскольку в этом случае все структуры данных имели бы свойство
изменчивости. По признаку изменчивости различают структуры: на
статические структуры данных и динамические структуры данных.
44.Инженер (от лат. ingenium — природный ум, изобретательность) —
специалист по созданию искусственных систем.
45.Инженерия программирования (англ. software engineering, в терминах
автоматизированных систем — разработка программного обеспечения) —
инженерное дело, творческая техническая деятельность. Инженерия
опирается на специфические методы и методики, в том числе
эвристические. Инженерия изучает различные методы и инструментальные
средства с точки зрения определенных целей, то есть имеет очевидную
практическую
направленность.
Основная
идея
инженерии
программирования в том, что разработка программного обеспечения
является формальным процессом, который можно изучать, выражать в
методиках и совершенствовать. Главное различие между технологией
программирования и программной инженерией заключается в способе
рассмотрения
и
систематизации
материала.
В
технологии
программирования акцент делается на изучении процессов разработки
программ (технологических процессов) в порядке их прохождения —
методы и инструментальные средства разработки программ используются
в этих процессах (их применение и образуют технологические процессы).
В программной инженерии изучаются, прежде всего, методы и
инструментальные средства разработки программ с точки зрения
75
достижения определенных целей — они могут использоваться в разных
технологических процессах (и в разных технологиях программирования).
Как эти методы и средства образуют технологические процессы — вопрос
второстепенный.
46.Инженерный технологический подход определяется спецификой
комбинации стадий разработки, этапов и видов работ, ориентированной на
разные классы программного обеспечения и на особенности коллектива
разработчиков.
47.Инженер-программист
—
наименование
должности
согласно
квалификационному
справочнику
должностей
руководителей,
специалистов и других служащих, специалист по созданию и эксплуатации
программ.
48.Инженер-системотехник — наименование должности согласно
квалификационному
справочнику
должностей
руководителей,
специалистов и других служащих, инженер инженеров, специалист по
решению проектных задач создания таких особо сложных искусственных
систем, как автоматизированные системы.
49.Инкапсуляция — это механизм совмещения в классе полей данных с
методами, которые манипулируют защищенными полями данных.
50.Интегрирование структуры данных — структуры данных, составными
частями которых являются другие структуры данных — простые или в
свою очередь интегрированные. Интегрированные структуры данных
конструируются программистом с использованием средств интеграции
данных, предоставляемых языками программирования.
51.Интерфейс — это набор форматов допустимых сообщений. Для
исключения возможных, но недопустимых сообщений используется
механизм сокрытия информации.
52.Испытание (validation) — попытка найти ошибки, выполняя программу в
заданной программной среде.
53.Каркасные инженерные подходы представляют собой каркас для видов
работ и включают их огромное количество. Ярким представителем
каркасного подхода является рациональный унифицированный подход к
выполнению работ (rational unified process). Весомое преимущество
данного подхода состоит в созданном инструментарии его
автоматизированной поддержки — программного продукта Rational Rose
фирмы Rational Software Corporation.
54.Каскадные инженерные технологические подходы задают некоторую
последовательность выполнения видов работ, обычно изображаемую в
76
виде каскада. Эти подходы также иногда называют подходами на основе
модели водопада.
55.Кодирование-исправление (code and fix) — инженерно-технологический
подход, упрощенно может быть описан следующим образом. Разработчик
начинает кодирование системы с самого первого дня, не занимаясь скольлибо серьезным проектированием.
56.Кодировщик программ — программист, пишущий и автономно
тестирующий код компонент программ.
57.Комплексное тестирование (system testing) — контроль и/или испытание
системы по отношению к исходным целям. Является процессом контроля,
если оно выполняется в моделируемой среде, и процессом испытания при
выполнении в реальной среде.
58.Композиция объектов — это реализация составного объекта, состоящего
из нескольких совместно работающих объектов и образующих единое
целое с новой, более сложной функциональностью.
59.Компонентный анализ — рассмотрение объекта, включающего в себя
составные элементы и входящего, в свою очередь, в систему более
высокого ранга.
60.Конструктор — особый метод класса, предназначенный для создания
экземпляра объекта.
61.Контейнер-менеджер, или контейнер, — класс, позволяющий объединять
(агрегировать) в себе самые разные классы объектов, в том числе и другие
контейнеры.
62.Контроль (verification) — попытка найти ошибки, выполняя программу в
тестовой или моделируемой среде.
63.Корректность программного обеспечения — свойство безошибочной
реализации требуемого алгоритма при отсутствии таких мешающих
факторов, как ошибки входных данных, ошибки операторов ЭВМ (людей),
сбоев и отказов ЭВМ.
64.Критерий — показатель качества.
65.Логическая структура данных — рассмотрение структуры данных без
учета ее представления в машинной памяти.
66.ЛПР — лицо, принимающее решение.
67.Метод — способ практического осуществления чего-нибудь.
68.Методика — совокупность методов практического выполнения чегонибудь.
69.Методология (от греч. metnhodos и logos — слово, учение о методах) —
система принципов и способов организации и построения теоретической и
практической деятельности, а также учение об этой системе.
77
70.Методология программирования изучает методы с точки зрения основ
построения. Это объединенная единым философским подходом
совокупность методов, применяемых в процессе разработки программных
продуктов. Любая методология создается на основе уже накопленных в
предметной области эмпирических фактов и практических результатов.
71.Метод мозгового штурма — метод синтеза вариантов систем,
использующий взаимную стимуляцию мышления в группе.
72.Метод морфологических таблиц — согласно данному методу, для
интересующего нас объекта формируется набор отличительных признаков:
наиболее характерных подсистем, свойств или функций. Затем для
каждого из них определяются альтернативные варианты реализации.
Комбинируя альтернативные варианты, можно получить множество
различных решений. Анализируя их, выделяют предпочтительные
варианты.
73.Метод проб и ошибок — метод синтеза вариантов систем, основанный на
последовательном выдвижении и рассмотрении идей.
74.Метод эвристических приемов — метод синтеза вариантов систем,
базирующийся на выделении базовых приемов, найденных при анализе
лучших программных изделий.
75.Методы объекта (methods, member functions) — подпрограммы,
реализующие действия (выполнение алгоритмов) в ответ на их вызов в
виде переданного сообщения.
76.Механизм сокрытия информации — механизм, используемый для
исключения возможных, но недопустимых сообщений объектам.
77.Множественное наследование классов — наследование, при котором
каждый класс может, в принципе, порождаться от одного или сразу от
нескольких родительских классов, наследуя поведение всех своих предков.
78.Модель — один объект или система может выступать в роли модели
другого объекта или системы, если между ними установлено сходство в
каком-то смысле.
79.Модуль — фундаментальное понятие и функциональный элемент
технологии структурного программирования, подпрограмма, но
оформленная в соответствии с особыми правилами.
80.Модуль — в технологии объектно-ориентированного программирования
это файл (unit) с описаниями родственных классов.
81.Модульность программ — основной принцип технологии структурного
программирования, характеризуется тем, что вся программа состоит из
модулей.
78
82.Наследование — определение класса и затем использование его для
построения иерархии классов-потомков, причем каждый потомок
наследует доступ к коду и данным всех своих классов прародителей.
83.Научно-исследовательская работа (НИР) — самостоятельный этап,
проводимый для выявления последних научных достижений с целью их
использования в проекте, проверки реализуемости изделия и уточнения
отдельных его характеристик.
84.НИР — научно-исследовательская работа.
85.Нисходящее проектирование — один из главных принципов технологии
структурного программирования, согласно которому при разработке
иерархии модулей программ выделяются первоначально модули самого
верхнего уровня иерархии, а затем подчиненные модули.
86.Нисходящая реализация программы — в технологии структурного
программирования первичная реализация группы модулей верхних
уровней, которые называются ядром программы, и далее постепенно, в
соответствии с планом, реализуются модули нижних уровней.
Необходимые для линковки программы, недостающие модули
имитируются заглушками.
87.Обобщение — выявление в группе классов общих свойств и вынесение их
в общий базовый класс.
88.Объект — логическая единица, содержащая всю информацию о некотором
физическом предмете или реализуемом в программе понятии,
структурированная переменная типа класс, которая содержит поля данных
и методы с кодом алгоритма.
89.Объектная модель — модель, описывающая структуру объектов,
составляющих систему, их атрибуты, операции, взаимосвязи с другими
объектами. В объектной модели должны быть отражены те понятия и
объекты реального мира, которые важны для разрабатываемой системы.
90.Объектно-ориентированное программирование (ООПр) (object-oriented
programming) — это процесс реализации программ, основанный на
представлении программы в виде совокупности объектов.
91.Объектно-ориентированное проектирование (ООП) (object-oriented design,
OOD) — методология проектирования, соединяющая в себе процесс
объектной декомпозиции и приемы представления логической и
физической, а также статической и динамической моделей проектируемой
системы.
92.Объектно-ориентированный анализ (ООА) (object-oriented analysis) —
методология, при которой требования к системе воспринимаются с точки
79
зрения классов и объектов, прагматически выявленных в предметной
области.
93.Операции над структурами данных — над всеми структурами данных
могут выполняться пять операций: создание, уничтожение, выбор (доступ),
обновление, копирование.
94.Операционный подход к составлению алгоритмов — согласно этому
подходу,
операции
(алгоритмические
действия)
выделяются
последовательно по ходу пути вычислений при каких-то наборах данных.
95.Оптимизация разработки программ — нахождение разумного
компромисса между достигаемой целью и затрачиваемыми на это
ресурсами.
96.Организованность данных — продуманное устройство с целью
рационального использованию по назначению.
97.ОС — операционная система.
98.Отладка (debugging) не является разновидностью тестирования, а является
средством установления точной природы ошибок.
99.Параметрический анализ — установление качественных пределов
развития объекта: физических, экономических, экологических и др.
Применительно к программам параметрами могут быть: время выполнения
какого-нибудь алгоритма, размер занимаемой памяти и т. д.
100. Паспорт модуля — внутренний документ проекта, который обычно
представляет собой конверт с именем модуля. Внутри конверта содержатся
описания прототипа вызова самого модуля и модулей, вызываемых
данным модулем; расшифровка входных и выходных переменных модуля;
описание функции, выполняемой модулем; принципы реализации
алгоритма модуля с описанием основных структур данных.
101. Паттерн проектирования — это образец, типовое решение какого-либо
механизма объектно-ориентированной программы.
102. Планирование на всех стадиях проекта — основополагающий принцип
проектирования, позволяет первоначально спланировать как состав стадий,
так и продолжительность всех этапов работ. Такое планирование
позволяет завершить разработку в заданный срок при заданных затратах на
разработку. Далее планируется порядок и время интеграции модулей во
все расширяющееся ядро. Планируются мероприятия по тестированию
программы от ранних до заключительных этапов.
103. ПО — программное обеспечение автоматизированных систем.
104. Повторное использование — это использование в программе класса для
создания экземпляров или в качестве базового для создания нового класса,
наследующего часть или все характеристики родителя. Повторное
80
использование сокращает объем кода, который необходимо написать и
оттестировать при реализации программы, что сокращает объемы труда.
105. Подпрограмма — некоторая последовательность инструкций, которая
может вызываться в нескольких местах программы; программная единица,
компилируемая независимо от остальных частей программы. В объектноориентированном программировании соответствует методу.
106. Позднее связывание — связи между объектами определяются
динамически во время выполнения программы, сам процесс связывания
заключается в замене адресов памяти виртуальных функций.
107. Показатели качества (критерии) — величины, свойства, понятия,
характеризующие систему с точки зрения субъекта, позволяющие оценить
степень удовлетворения его потребностей.
108. Поле объекта (data members) — порция данных объекта, значения
которых определяют текущее состояние объекта.
109. Полиморфизм — это средство для придания различных значений одному
и тому же событию в зависимости от типа обрабатываемых данных, т. е.
полиморфизм определяет различные формы реализации одноименного
действия.
110. Порт — программный механизм накопления и верификации как
входных, так и выходных данных в соответствующих очередях.
111. Потомок — класс, используемый характеристики другого класса
посредством наследования.
112. Предок — это класс, предоставляющий свои возможности и
характеристики другим классам.
113. Программная документация — единая система программной
документации (ЕСПД).
114. Программный документ — документ, содержащий сведения,
необходимые
для
разработки,
изготовления,
эксплуатации
и
сопровождения программного изделия.
115. Программный продукт — программа, которую можно запускать,
тестировать, исправлять и развивать. Такая программа должна быть
написана в едином стиле, тщательно оттестирована до требуемого уровня
надежности, сопровождена подробной документацией и подготовлена для
тиражирования. Стандартный термин — программное изделие.
116. Программное изделие — программа на носителе данных, являющаяся
продуктом промышленного производства.
117. Программное обеспечение автоматизированных систем (ПО) —
совокупность программ на носителях данных и программных документов,
81
предназначенная для отладки, функционирования и проверки
работоспособности автоматизированных систем.
118. Проект (от лат. projectus — брошенный вперед) — совокупность
проектных документов в соответствии с установленным перечнем, которая
представляет результат проектирования.
119. Проектирование — это разработка проекта, процесс создания
спецификации, необходимой для построения в заданных условиях еще
несуществующего объекта на основе первичного описания этого объекта.
Результатом проектирования является проектное решение или
совокупность проектных решений, удовлетворяющих заданным
требованиям. Заданные требования обязательно должны включать форму
представления решения.
120. Проектная задача (англ. engineering Task) — характеризуется
неопределенностью априори информации: что требуется получить, что
задано. Более того, способ решения задачи является объектом
проектирования. И наконец, решение проектной задачи должно быть
найдено в рамках ограничений внешней среды: доступных денежных
средств, заранее заданных сроков, возможностями технических средств и
инструментария программирования, научных знаний программных заделов
и т. д.
121. Проектная операция — действие или формализованная совокупность
действий, составляющих часть проектной процедуры, алгоритм которых
остается неизменным для ряда проектных процедур, например
вычерчивание схемы, дифференцирование функции.
122. Проектная процедура (методика), составления функциональных
описаний — методика разработки описаний функционирования систем,
отличающаяся использованием особого структурирования. Инструкция
пользования каким-либо устройством, инструкция вообще или алгоритм
программы являются описаниями функционирования.
123. Проектная ситуация — реальность (ситуация), в которой ведется
проектирование.
124. Проектное решение — описание в заданной форме объекта
проектирования или его части, необходимое и достаточное для
определения дальнейшего направления проектирования.
125. Проектный документ — документ, выполненный по заданной форме, в
котором
представлено
какое-либо
проектное
решение.
В
программировании проектные решения оформляются в виде программной
документации. Различают внешнюю программную документацию, которая
82
согласуется с заказчиком, и внутреннюю промежуточную документацию
проекта, которая необходима самим программистам для их работы.
126. Простое наследование классов — наследование, при котором
определенный пользователем класс имеет только одного родителя. Схема
иерархии классов в этом случае представляет собой ряд одиночно стоящих
деревьев (hierarchical classification).
127. Простые структуры данных не могут быть расчленены на составные
части, большие, чем биты и байты. С точки зрения физической структуры
важным является то обстоятельство, что в данной машинной архитектуре,
в данной системе программирования мы всегда можем заранее сказать,
каков будет размер данного простого типа и какова структура его
размещения в памяти. С логической точки зрения простые данные
являются неделимыми единицами. В языках программирования простые
структуры описываются простыми (базовыми) типами. Простые структуры
данных служат основой для построения более сложных интегрированных
структур.
128. Профессиональный программист — это специалист, который обладает
интегральной личностной характеристикой человека: добивается
мастерства в программировании, следует профессиональной ценностной
ориентации, соблюдает профессиональную этику, владеет искусством
общения с людьми, стремится и умеет вызвать интерес общества к
результатам своей профессиональной деятельности.
129. Рабочий проект (РП) — наименование стадии и программный
документ, содержащий описание реализованного изделия.
130. Раннее связывание — связи между объектами определяются статически
во время компиляции.
131. Резидентная программа — не удаляемая ОС программа, постоянно
находящаяся в оперативной памяти ЭВМ.
132. Родитель — непосредственный класс-предок, стоящий у корня схемы
иерархии, и от которого порождаются первые потомки, а от потомков еще
потомки.
133. Родительский класс — начальный класс, от которого наследуются
классы-потомки.
134. РП — рабочий проект.
135. САПР — система автоматизированного проектирования.
136. Свойства (property) — это особым образом оформленные методы,
предназначенные как для чтения и контролируемого изменения
внутренних данных объекта (полей), так и выполнения действий,
связанных с поведением объекта.
83
137. Сессия программистов — встреча кодировщиков для проведения
взаимной инспекции текстов программ и набора использованных тестов.
138. Синтез (от греч. synthesis — соединение, сочетание, составление) —
метод научного исследования явлений действительности в их единстве и
целостности, во взаимодействии их частей, обобщение, сведение в единое
целое. В теории проектирования синтез — это процесс построения
описания системы по заданному функционированию.
139. Система — множество элементов, находящихся в отношениях и связях
друг с другом, которое образует определенную целостность, единство.
140. Системный аналитик — программист, разрабатывающий проект от
требований до внутренней структуры программы и участвующий в
тестировании как при интеграции компонентов в ядро, так и в
комплексном тестировании ПО.
141. Системный подход — общенаучный обобщенный эвроритм,
предусматривающий всестороннее исследование сложного объекта с
использованием
компонентного,
структурного,
функционального,
параметрического и генетического видов анализа.
142. Сквозной структурный контроль — использование на многих этапах
проекта контроля корректности спецификации связей частей программы.
143. Слияние — объединение нескольких небольших, но тесно
взаимодействующих классов в один.
144. Сопровождение — деятельность по оказанию услуг, необходимых для
обеспечения устойчивого функционирования или развития программного
изделия,
включает
анализ
функционирования,
развитие
и
совершенствование программы, а также внесение изменений в нее с целью
устранения ошибок.
145. Спецификация — в сфере проектной деятельности это какое-либо
описание в точных терминах.
146. Стадия проекта — одна из частей процесса создания программы,
установленная нормативными документами и заканчивающаяся выпуском
проектной документации, содержащей описание полной, в рамках
заданных требований модели программы на заданном для данной стадии
уровне, или изготовлением программ. По достижении стадии заказчик
имеет возможность рассмотреть состояние проекта и принять решение по
дальнейшему продолжению проектных работ.
147. Стратегия (от греч. stratos — войско и ago — веду) — наука, искусство
генерации наиболее существенных общих долгосрочных целей и наиболее
общего плана достижения преимущества, курса действий и распределения
ресурсов еще до выполнения реальных действий. Стратегия охватывает
84
теорию и практику подготовки к выполнению проекта, а также наиболее
общее планирование тактик ведения проектов. Стратегия определяет, куда,
в каком направлении двигаться, куда держать курс еще до начала проекта.
А тактика определяет, как, каким способом двигаться, какие конкретные
действия предпринимать при затруднениях в ходе выполнения проекта.
148. Структура программы — искусственно выделенные программистом
взаимодействующие части программы.
149. Структура данных программы — множество элементов данных,
множество связей между ними, а также характер их организованности.
150. Структурное кодирование модулей программ — основной принцип
технологии структурного программирования, воспринятый технологией
объектно-ориентированного программирования, который заключается в
особом оформлении текстов модулей (методов). У модуля должен быть
легко
различимый
заголовок
с
комментарием,
поясняющим
функциональное назначение модуля. Имена переменных должны быть
мнемоническими. Суть переменных и порядок размещения в них
информации должны быть пояснены комментариями, а код закодирован с
использованием типовых алгоритмических структур.
151. Структурный анализ — выявление элементов объекта и связей между
ними.
152. Структурный подход — набор принципов, характеризующий
технологию структурного программирования: модульность программ;
структурное кодирование модулей программ; нисходящее проектирование
рациональной иерархии модулей программ; нисходящая реализация
программы с использованием заглушек; осуществление планирования на
всех стадиях проекта; сквозной структурный контроль программных
комплексов в целом и составляющих их модулей.
153. СУБД — система управления базами данных.
154. Схема иерархии программы — используется в технологии структурного
программирования,
отражает
только
подчиненность
модулей
(подпрограмм), но не порядок их вызова или функционирование
программы.
155. Сценарий — последовательность событий, которая может иметь место
при конкретном выполнении системы.
156. Сценарий диалога программы — последовательность ввода и вывода
информации в диалоговом режиме работы программы.
157. Тактика (от греч. taktika — искусство приводить в порядок) —
фиксированная в своей последовательности совокупность средств и
приемов для достижения намеченной цели и искусство ее применения,
85
способы действия, ориентированные на достижение конкретных целей,
являющиеся звеньями реализации стратегических целей. Целью
применения способа действия является совершение оптимальных действий
в заранее не предсказанных стратегическим планом ситуациях уже в
процессе выполнения реальных действий.
158. Тестирование (testing) — процесс выполнения программы с намерением
найти ошибки; может осуществляться как с ЭВМ, так и без ЭВМ.
159. Тестирование
приемлемости
(acceptance
testing) —
проверка
соответствия программы требованиям пользователя.
160. Тестирование сопряжений (integration testing) — контроль сопряжений
между частями системы как между компонентами в комплексе, так и
между модулями отдельного компонента (например, у заглушки).
161. Тестировщик — программист, готовящий наборы тестов для отладки
разрабатываемого программного изделия.
162. Технический проект (ТП) — комплект проектных документов на
программу, разрабатываемый на стадии "Технический проект",
утвержденный в установленном порядке, содержащий основные
проектные решения по программе в целом, ее функциям и достаточный
для разработки рабочего проекта.
163. Техническое задание (ТЗ) — документ, оформленный в установленном
порядке и определяющий цели создания программы, требования к
программе и основные исходные данные, необходимые для ее разработки,
а также план-график создания программы.
164. Технология (от греч. techne — искусство, мастерство, умение и logos —
слово, учение) — совокупность производственных процессов в
определенной отрасли производства, а также научное описание способов
производства, совокупность приемов, применяемых в каком-либо деле,
мастерстве, искусстве. Современная методология проектирования
позволила довести методы проектирования до технологий с набором
методик.
165. Технология визуального программирования — популярная инженерия
программирования, состоящая в автоматизированной разработке программ
с использованием особой диалоговой оболочки.
166. Технология
объектно-ориентированного
программирования
—
технология, ориентированная на получение программ, состоящих из
объектов.
167. Технология программирования как наука изучает технологические
процессы и порядок их прохождения (с использованием знаний, методов и
средств). Технологический процесс — последовательность направленных
86
на создание заданного объекта действий (технологических процедур и
операций), каждое из которых основано на каких-либо естественных
процессах и человеческой деятельности. Обратим внимание на то, что
знания, методы и средства могут использоваться в разных процессах и,
следовательно, в технологиях. Технология программирования для
инженера — это научная и практически апробированная стратегия
создания программ, содержащая описание совокупности методов и средств
разработки программ, а также порядок применения этих методов и
средств.
168. Технология программирования Дейкстры, основанная на абстракции
данных — в данной технологии во главе ставятся данные; сначала очень
тщательно специфицируется выход, вход, промежуточные данные;
большое внимание уделяется типизации данных с использованием
структур для объединения близкой по смыслу информации в единые
данные.
169. Технология структурного программирования — технология, основанная
на структурном подходе.
170. Типизация — это способ защититься от использования объектов одного
класса вместо другого или, по крайней мере, управлять таким
использованием. Типизация заставляет нас выражать наши абстракции так,
чтобы язык программирования, используемый в реализации, поддерживал
соблюдение принятых проектных решений.
171. ТП — технический проект.
172. Управление разработкой программных систем (software management) —
деятельность, направленная на обеспечение необходимых условий для
работы
коллектива
разработчиков
программного
обеспечения,
планирование и контроль деятельности этого коллектива с целью
обеспечения требуемого качества ПО, выполнения сроков и бюджета
разработки ПО.
173. Устойчивость программного обеспечения — свойство осуществлять
требуемое преобразование информации при сохранении выходных
решений программы в пределах допусков, установленных спецификацией
при воздействии на программы таких факторов неустойчивости, как
ошибки операторов ЭВМ, а также не выявленных ошибок программы.
174. Физическая структура данных — способ физического представления
данных в памяти машины и называется еще структурой хранения,
внутренней структурой, структурой памяти, или дампом.
175. Форма — визуальный компонент, обладающий свойством окна
Windows.
87
176. Функция системы — совокупность действий системы, направленная на
достижение определенной цели.
177. Функциональный анализ — рассмотрение объекта как комплекса
выполняемых им функций.
178. Эвристика — наука, раскрывающая природу мыслительных операций
человека при решении конкретных задач независимо от их конкретного
содержания. В более узком смысле, эвристика — это догадки, основанные
на опыте решения родственных задач.
179. Эвроритм — порядок действия человека при выполнении какой-то
деятельности. В отличие от алгоритма может изменяться в процессе
исполнения благодаря разумности исполнителя.
180. Экземпляр класса — объект.
181. Эксплуатационная документация — часть рабочей документации на
программу, предназначенная для использования при эксплуатации
программы и определяющая правила действия персонала и пользователей
программы при ее функционировании, проверке и обеспечении ее
работоспособности.
182. Экстремальное программирование (extreme programming) (XP) —
адаптивный инженерный подход, рациональное объединение известных
методов и их совокупное использование дает существенные результаты и
успешно выполненные проекты при разработке небольших систем,
требования к которым четко не определены и вполне могут измениться.
183. Эскизный проект (ЭЛ) — комплект проектных документов на
программу, разрабатываемый на стадии "Эскизный проект", утвержденный
в
установленном порядке,
содержащий
описание
нескольких
альтернативных вариантов реализации будущего изделия и уточненные
требования на основе их анализа. Степень проработки при этом должна
быть достаточной лишь для достижения возможности сравнения
вариантов.
184. ЭТ — электронная таблица.
185. Этап проекта — часть стадии проекта, выделенная по соображениям
единства характера работ и (или) завершающего результата или
специализации исполнителей.
186. Ядро — всеувеличивающаяся уже реализованная часть программы.
187. CASE-средства — это программные средства, поддерживающие
процессы создания и сопровождения программных продуктов, включая
анализ и формулировку требований, проектирование продукта и баз
данных, генерацию кода, тестирование, документирование, обеспечение
качества, конфигурационное управление и управление проектом, а также
88
другие процессы. CASE-средства вместе с системным программным
обеспечением и техническими средствами образуют полную среду
разработки программных систем.
188. CASE-технология (Computer Aided Software Engineering) — технология,
представляющая собой методологию проектирования АС, а также набор
инструментальных средств, позволяющих в наглядной форме
моделировать предметную область, анализировать эту модель на всех
этапах разработки и сопровождения программных систем и разрабатывать
приложения в соответствии с информационными потребностями
пользователей.
189. СОМ — Component Object Model.
190. Component Object Model (модель компонентных объектов) —
спецификация метода создания компонент и построения из них программ.
191. CRC-карточка (Component, Responsibility, Collaborator — объект,
обязанности, сотрудники) — промежуточный документ проекта,
необходимый для специфицирования объектов.
192. DFD — ДПД (Data Flow diagramm).
193. RDD-проектирование
(Responsibility-Driven-Design) —
технология
проектирования на основе обязанностей, предложенная Т. Бадтом. Данная
технология по способу мышления аналогична разработке структуры служб
какой-то организации: директора, заместителей директора, служб и
подразделений.
89
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
«Дальневосточный федеральный университет»
(ДВФУ)
ШКОЛА ЕСТЕСТВЕННЫХ НАУК
ДОПОЛНИТЕЛЬНЫЕ МАТЕРИАЛЫ
по дисциплине «Технология разработки программного обеспечения»
010503.65 Математическое обеспечение и администрирование информационных систем
90
Электронные учебники и образовательные интернет-сайты
1. http://swebok.sorlik.ru/Основы Программной Инженерии (по SWEBOK).
Сopyright © 2004-2010 Сергей Орлик. (Русский перевод SWEBOK 2004 с
замечаниями и комментариями Сергея Орлика при участии Юрия Булуя.),
2.
3. http://khpi-iip.mipk.kharkiv.edu/library/case/buch/index.html Буч Г. Объектноориентированный анализ и проектирование с примерами приложений на
C++ //
4. http://www.citforum.ru/database/case/index.shtml Вендров А.М.
CASEтехнологии. Современные методы и средства проектирования
информационных систем //
5. http://www.mista.ru/oop_book/index.htm Гайсарян С.С. Объектноориентированное проектирование, Центр Информационных Технологий,
6. http://www.ispras.ru/~kuliamin/lectures-sdt/sdt-book-2006.pdf Кулямин В. В.
Технологии программирования. Компонентный подход \\
7. http://www.ict.edu.ru/ft/005651/62328e1-st15.pdf Соснин П.И. Архитектурное
моделирование систем, интенсивно использующих программное
обеспечение / Всероссийский конкурсный отбор обзорно-аналитических
статей
по
приоритетному
направлению
"Информационнотелекоммуникационные системы", 2008. - 93 с.
8. http://www.twirpx.com/file/13585/ Липаев В.В. Документирование сложных
программных средств. 9. Единое
окно
доступа
к
образовательным
ресурсам
http://window.edu.ru/library
10.Электронно - библиотечная система образовательных и просветительских
изданий - http://www.iqlib.ru/
11.Электронно-библиотечная система. Электронные версии учебной
литературы по естественным, техническим и гуманитарным наукам.
Технология
программирования.
http://www.twirpx.com/files/informatics/ptechnology/
12.Электронная библиотека издательства «Юрайт» www.biblio-online.ru
13.Научная библиотека ДВФУ. Электронный каталог http://lib.dvfu.ru:8080/
Методическое обеспечение представлено:
1)
монографиями и учебниками (см. подразделы «литературы»),
91
2)
УМКД, включающим конспекты лекций, слайды, дидактические
пособия (в виде фрагментов примеров из учебников и
технической документации, назначение которых - помощь
студенту в учебной деятельности в режиме аудиторной работы).
92
