17.01M

Category:

software

Общие принципы разработки программных средств

1.

Технология разработки
программного обеспечения
ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ
ПРОГРАММНЫХ СРЕДСТВ

2.

Содержание
1. Программное обеспечение - это...
2. Стадии разработки ПО
3. Основные характеристики ПО
4. Виды ПО
5. Прикладное ПО
6. Системное ПО
7. Инструментальное ПО

Что такое программное
обеспечение?
Программное обеспечение (ПО) —
составляющая часть компьютера,
комплекс программ, необходимых
для работы с информацией. Самое
распространенное ПО —
операционная система Windows.
Программное обеспечение управляет
аппаратной частью ПК, которая
производит физические операции.
Удобство и универсальность ПО
заключается в его способности
модифицироваться. Программа,
способная запоминать информацию,
сделала вычислительные машины
гибкими и легко адаптируемыми к
разным условиям работы.

4.

Стадии
разработки
программного
обеспечения
Любая программа проходит 3
этапа: создание, применение и
сопровождение. В процессе
разработки ПО насчитывается 6
стадий:
• определение требований;
• создание проекта;
• разработка команд;
• группировка всех компонентов;
• проверка работоспособности
(тестирование);
• оформление сопроводительной
документации.

5.

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

6.

Виды программного
обеспечения
Различают 3
основных
вида программного
обеспечения:
• системное;
• прикладное;
• инструментарий
технологии
программирования
(инструментальные
средства).

7.

ПО классифициру
ется также в
соответствии с
характеристиками
, выполняемыми
функциями:
По режиму эксплуатации: групповое, индивидуальное, сетевое.
По масштабу: малое, среднее, большое.
По свойствам стабильности: стабильное, средней стабильности,
нестабильное. Стабильные компоненты обеспечения корректно
функционируют, не требуя внесения изменений и дополнений.
Нестабильное оборудование не гарантирует бесперебойной работы.
По требованию защиты: надежные, сомнительные.
По необходимым рабочим характеристикам: гибкие/неизменные,
универсальные, полные.
По исходному языку: машинные, машинно-ориентированные,
алгоритмические, интегрированные, процедурно-ориентированные,
проблемно-ориентированные.
ПО различается в зависимости от характеристик
вычислительной среды: алгоритмической сложности, объемов
файловой системы, разновидности процессора, системности
обработки.
По классу пользователя: простой клиент, расширенный
пользователь, максимум.
По значению критичности: секретность, национальная
безопасность, жизнь человека, паника в социальной сфере, частная
собственность, безопасность в организации.
По видам доступа к использованию: просмотр и редактирование
для всех пользователей, только просмотр, редактирование для
некоторых пользователей, просмотр только для некоторых
пользователей.

8.

• Free — распространяются бесплатно,
доступны для скачивания, копирования;
По способу
распространения и
использования выд
еляют 6 типов:
• Adware — бесплатные, содержащие
платные дополнительные функции;
• Shareware — бесплатные для
индивидуального пользования, доступ
компании разрешается за определенную
оплату;
• Trial — скрипты, позволяющие
бесплатно производить действия в
течение установленного периода (10-30
суток), для дальнейшего доступа
необходима покупка лицензионного
ключа;
• Demo — пробная версия программы;
• Закрытое ПО представляет собой
частную собственность разработчиков,
доступ к которой возможен лишь при
определенных условиях, выставленных
автором.

9.

Прикладное программное
обеспечение
Пакет прикладных программ —
комплекс программ,
сгруппированных для выполнения
задач конкретной тематики.
Выделяют несколько типов
прикладного ПО:
1. Общего назначения. Их задача
состоит в
автоматизации пользовательских
задач различного направления.
Набор таких программ имеется на
каждом компьютере. К ним
относят:
• табличные редакторы;
• текстовые и графические
процессоры;

10.

2. Методо-ориентированные пакеты прикладных программ реализуют
экономико-математические методы выполнения задач. Среди них:
• математическая статистика;
• математическое программирование;
• сетевое планирование и управление;
• теория массового обслуживания.
3. Проблемно-ориентированные используются для выполнения
конкретной задачи в определенной области. К ним относят пакеты:
• бухгалтерского учета;
• банковские;
• правовых справочных систем и финансового менеджмента.
4. Сервисные программные средства предназначены для удобной
организации рабочего пространства пользователя и оказывают
вспомогательное действие.
• переводчики;
• информационные менеджеры.
Одной из самых популярных разновидностей прикладного программного
обеспечения являются компьютерные игры.

11.

Системное программное
обеспечение
Системное ПО (System Software) — группы
программ и их систем, которые обеспечивают
работу компьютера.
СПО предназначается для:
• формирования условий для функционирования
других программных групп;
• обеспечения автоматизации разработки нового
софта;
• регулирования качества работы компьютера и
вычислительной системы;
• диагностирования и профилактики
компьютерной аппаратуры;
• произведения дополнительных технологических
процессов (архивирование, восстановление
компонентов программ и файлов баз данных,
копирование).
Продукты данного вида ПО являются
неотъемлемой частью компьютера и рассчитаны

12.

Инструментальное
программное обеспечение
Инструментальное ПО (системы
программирования) предназначено для
использования разработчиками в процессе
проектирования и создания программ.
Элементами системы программирования являются:
• Текстовые редакторы помогают создавать,
редактировать и объединять тексты.
• Транслятор преобразовывает алгоритмический
язык программы в машинный (двоичные коды),
создавая при этом объектный
модуль. Интерпретатор осуществляет перевод
построчно, не создавая объектный модуль.
• Средства отладки (отладчик) обеспечивают
пошаговое выполнение программ с
предоставлением данных о результатах
исполнения.

13.

Технология разработки
программного обеспечения
(ТРПО)
Включает …
МЕТОДЫ
СРЕДСТВА
(утилиты)
ПРОЦЕДУРЫ
Обеспечивают
решения
определенных задач
в разработке ПО:
анализ требований,
кодирование и т.п.
CASE – средства и
системы
автоматизированной
поддержки методов
разработки ПО
Обеспечивают
совместное
применение
методов
разработки ПО и
CASE-средств

14.

CASE - Computer Aided Software Engineering
- программная инженерия с компьютерной
поддержкой.

15.

Процессы жизненного цикла ПО, обеспечения ресурсами
и организации разработки ПО согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
5.1 Заказ
6 Процессы обеспечения
жизненного цикла ПО ресурсами
6.1 Документирование
5.2 Поставка
6.2 Управление конфигурации
5 Процессы жизненного цикла ПО
6.3 Обеспечение качества
5.4 Эксплуатация
6.4 Версия
6.5 Аттестация
5.3
Разработка
6.6 Совместный анализ
5.5
Сопровождение
6.7 Аудит
6.8 Решение проблем
7 Процессы организации разработки ПО
7.1 Управление
7.2 Создание инфраструктуры
7.3 Усовершенствование
7.4 Обучение

16.

USED AT:
Процессы
жизненного
DATE:
26.12.2009
WORKING цикла ПО
READER
DATE CONTEXT:
PROJECT: Ïðîöåññû ðàçðàáîòêè ÏÎ ïî ISO/IEC
REV: 26.12.2009
DRAFT
согласно МС ISO/IEC 12207:95 (ГОСТ
Р ИСО/МЭК 12207:99) TOP
122007
RECOMMENDED
AUTHOR: Ê.Ý. Ïèñàðåíêî
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
A0
Процессы жизнененного цикла ПО
Заказ
Поставка
Разработка
Подготовка
заказа
Подготовка
поставки
Подготовка процесса разработки
Подготовка
заявки на
подряд
Подготовка
ответа
Проектирование архитектуры
системы
Подготовка
договора
Анализ требований к ПС
Подготовка и
корректировка
договора
Надзор за
поставщиком
Приемка и
закрытие
договора
Анализ требований к системе
Планирование
Проектирование архитектуры
ПС
Выполнение и
контроль
Техническое проектирование ПС
Проверка и
оценка
Поставка и
закрытие
договора
Программирование и
тестирование ПС
Эксплуатация
Подготовка
процесса
эксплуатации
Подготовка
процесса
сопровождения
Эксплуатационные
испытания
Анализ
проблем и
изменений
Эксплуатация
информационной
системы
Поддержка
пользователя
Квалификационные испытания
ПС
Снятие с
эксплуатации
Сборка системы
Обеспечение приемки ПС
A1
Проверка и
приемка при
сопровождении
Перенос
Ввод в действие ПС
TITLE:
Внесение
изменений
Сборка ПС
Квалификационные испытания
системы
NODE:
Сопровождение
Ïðîöåññû æèçíåíåííîãî öèêëà ÏÎ
NUMBER:

17.

Сайт Межотраслевого Совета Информационных технологий
http://www.msovit.ru/

18.

Модели процессов жизненного цикла программного обеспечения
Международные стандарты ISO 12207, ISO/IEC 15288
Подходы к организации процессов жизненного цикла ПО
(подходы позволяют разными способами выполнить требования стандартов)
Однократный
подход
Модель
классического
жизненного
цикла
Инкрементный подход
(подход запланированных
улучшений)
Эволюционный
подход (подход
не запланированных
улучшений)
Инкрементная
модель
Спиральная
модель
Модель быстрой
разработки
(RAD–модель)
Компонентно
-ориентированная
модель

19.

Модель классического жизненного цикла программного обеспечения

20.

Модель классического жизненного цикла программного обеспечения
1 Определяет роль каждого элемента ПО
и их взаимодействие в системе, в которой
планируется применять ПО
2 Определяет технические требования
к каждому элементу ПО
4 Результаты
проектирования
переводятся в текст языка
программирования
3 Определяются: архитектура,
модульная структура,
алгоритмическая структура,
структуры данных,
входной и выходной интерфейс
6 Устранение ошибок и
совершенствование ПО

21.

Инкрементная (операционная) модель процессов жизненного
цикла программного обеспечения

22.

Пример реализации инкрементной модели процессов
жизненного цикла для программного обеспечения
поддерживающего обработку слов
Итерация 1 реализует функции:
- базовой обработки файлов,
-редактирования
- документирования.
Итерация 2 реализует функции:
- проверки орфографии и грамматики.
Итерация 3 реализует функции:
- компоновки страницы .

23.

Модель процессов жизненного цикла ПО
- быстрой разработки ПО (RAD – модель)

24.

Спиральная модель процессов жизненного цикла ПО
1 — начальный сбор требований и планирование проекта;
2 — та же работа, но на основе рекомендаций заказчика;
3 — анализ риска на основе начальных требований;
4 — анализ риска на основе реакции заказчика;
5 — переход к комплексной системе; 6 — начальный макет системы;
7 — следующий уровень макета; 8 — сконструированная система;
9 — оценивание заказчиком

25.

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

26.

27.

Жизненный цикл ПО с применением макетирования

28.

Модели процессов жизненного
цикла программного обеспечения
Практическое задание
1 Выберете модель для разработки
Вашего программного средства.
2 Укажите названия этапов его
разработки

29.

Подход к управлению качеством
программного обеспечения
КАЧЕСТВО СИСТЕМ И ПРОЦЕССОВ МЕНЕДЖМЕНТА
КАЧЕСТВО ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА
КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

30.

Международные стандарты в области управления качеством
КАЧЕСТВО СИСТЕМ И ПРОЦЕССОВ УПРАВЛЕНИЯ:
- МС “ISO 9001:2008 (2000). Системы менеджмента качества. Требования”;
- МС "ISO 9004:2009. Менеджмент в целях достижения устойчивого успеха
организации;
- МС “ISO/IEC 90003-2004. Руководство по применению стандарта
ISO 9001:2000 для программных средств”;
-МС “ISO/IEC 90005-2008. Руководство по применению стандарта
ISO 9001:2000 к процессам жизненного цикла программных средств”;
- МС “ISO/IEС 20000-1:2005. ИТ. Сервис менеджмент. Спецификация”
(предоставление ИТ услуг)”;
- стандарт “Корпоративное управление ИТ” (COBIT) международной
Ассоциации аудита и контроля информационных систем (ISACA).
КАЧЕСТВО ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА:
- МС “ISO 12207:95 (2008). Процессы жизненного цикла ПО”;
- МС “ISO/IEC 15288:2008 . Процессы жизненного цикла систем”;
- МС “ISO/IEC 15504:2004. Оценка процессов.
КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ:
- МС “ISO/IEC 9126 . Оценка программного продукта.
Характеристики качества и руководство по их применению”;
-МС “ISO/IEC 25051:2006. Требования для качества готового коммерческого
программного продукта и инструкция для испытаний”;
- МС “ISO/IEC 14598. Оценка программного продукта”.

31.

Модель системы менеджмента МС ISO 9001:2008

32.

Модель системы управления предоставления ИТ услуг
МС ISO/IEC 20000-1:2005
Процессы предоставления услуг
Управление
мощностью
Управление
непрерывностью и
доступностью услуг
Управление уровнем услуг
Управление
информационной
безопасностью
Подготовка отчетности по
услугам
Бюджетирование и учёт
затрат на услуги ИТ
Процессы контроля
Процесс
релиза
Управление конфигурациями
Управление изменениями
Процессы решения
Управление релизами
Процессы
отношений
Управление инцидентами
Управление
отношениями с
потребителями
Управление проблемами
Управление
подрядчиками

33.

Модель системы управления корпоративными ИТ ресурсами
МС COBIT
Процессы
Процессы

34.

PO1 Разработка стратегического плана развития ИТ
PO2 Определение информационной архитектуры
PO3 Определение направления технологического развития
PO4 Определение организационной структуры и взаимосвязей
PO5 Управление ИТ инвестициями
PO6 Информирование о целях и направлениях развития ИТ
PO7 Управление персоналом
PO8 Управление качеством
PO9 Оценка и управление ИТ рисками
PO10 Управление проектами

35.

36.

Модель системы управления корпоративными ИТ ресурсами МС COBIT
Планирование развития ИТ- инфраструктуры
осуществляется на основе стратегии развития
организации в целом!!!

37.

38.

О – ответственный, У – утверждающий, К – консультирующий, И - информированный

39.

40.

Для каждого
процесса
МС COBIT
применяется
5-ти
уровневая
шкала
зрелости

41.

42.

На основании плана развития IT-инфраструктуры приобретается,
разрабатывается и внедряется программное обеспечение
и аппаратные средства
AI1
Выбор решений по автоматизации
AI2
Приобретение и поддержка программных приложений
AI3
Приобретение и обслуживание технологической инфраструктуры
AI4
Обеспечение выполнения операций
AI5
Поставки ИТ ресурсов
AI6
Управление внесением изменений
AI7
Внедрение и приемка решений и изменений

43.

Закупленные и внедренные программное обеспечение
и аппаратные средства затем эксплуатируются и сопровождаются
DS1
DS2
DS3
DS4
DS5
DS6
DS7
DS8
DS9
DS10
DS11
DS12
DS13
Определение и управление уровнем обслуживания
Управление услугами сторонних организаций
Управление производительностью и мощностями
Обеспечение непрерывности ИТ сервисов
Обеспечение безопасности систем
Определение и распределение затрат
Обучение и подготовка пользователей
Управление службой технической поддержки и инцидентами
Управление конфигурацией
Управление проблемами
Управление данными
Управление физической безопасностью и защитой от воздействия окружающей среды
Управление операциями по эксплуатации систем

44.

Информационная инфраструктура: программное обеспечение
и аппаратные средства периодические оцениваются на
результативность, эффективность и соответствие установленным
требованиям
ME1
Мониторинг и оценка эффективности ИТ
ME2
Мониторинг и оценка системы внутреннего контроля
ME3
Обеспечение соответствия внешним требованиям
ME4
Обеспечение корпоративного управления ИТ

45.

Результаты оценки результативности, эффективности
и соответствия установленным требованиям
информационной инфраструктуры служат основой для
пересмотра планов ее развития

46.

В МС COBIT выделяются следующие ресурсы
информационной инфраструктуры:
1 Приложения
2 Информация
3 Инфраструктура
4 Персонал

47.

Куб
COBIT

48.

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

49.

1 ISO 9001:2008. Системы менеджмента качества
2 ISO 9004:2004. Менеджмент в целях достижения устойчивого
успеха организации
3 Модель Совершенства Европейского фонда менеджмента
качества (EFQM)
4 Прочие стандарты и модели систем менеджмента

50.

Модель системы менеджмента МС ISO 9004:2009.
Менеджмент в целях достижения устойчивого успеха организации
50
08.11.23

51.

Критерии и примитивы качества ПС согласно МС ISO/IEC 9126
USED AT:
A UTHOR: Ê.Ý . Ïèñàðåíêî
DA TE: 27.12.2009
WORKING
PROJECT: Ïðîöåññû ðàçðàáîòêè ÏÎ ïî ISO/IEC
122007
REV :
DRAFT
27.12.2009
REA DER
DA TE CONTEXT:
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
A 1.3.4.1.1
Критерии и примитивы качества ПС
Функциональность
Надежность
Завершенность
Завершенноcть
Точность
Автономность
Устойчивость
Защищенность
Эффективность
Сопровождаемость:
изучаемость и
модифицируемость
Мобильность
П-документированность
Временная
эффективность
С-документированность
Независимость
от устройств
Информативность
Эффективность
по ресурсам
Информативноcть
Автономноcть
Понятность
Коммуникабельность
Эффективность
по устройствам
Структурированность
Cтруктурированность
Легкость
применения
Устойчивоcть
Удобочитаемость
Защищенноcть
Расширяемость
Модульность
NODE:
TITLE:
A1.3.4.1.1.1
Êðèòåðèè è ïðèìèòèâû êà÷åñòâà ÏÑ
NUMBER:
Модульноcть

52.

Практическое задание
Определите уровень развития
информационной инфраструктуры в
компании для которой Вы разрабатываете
программное средства (или любой известной
Вам организации).

53.

Технология разработки
программного обеспечения
ВНЕШНЕЕ ОПИСАНИЕ (СПЕЦИФИКАЦИЯ)
ПРОГРАММНОГО СРЕДСТВА
ЛЕКЦИЯ 2

54.

55.

ВНЕШНЕЕ ОПИСАНИЕ – СПЕЦИФИКАЦИЯ ПС
НЕ СЛЕДУЕТ ПУТАТЬ ТРЕБОВАНИЯ
К ПРОГРАММНОМУ
ОБЕСПЕЧЕНИЮ С ТРЕБОВАНИЯМИ
К ПРОЦЕССАМ ЕГО РАЗРАБОТКИ
Внешнее описание ПС – спецификации ПС:
- играет роль точной постановки задачи,
решение которой должно обеспечить
разрабатываемое ПС;
- должно содержать всю информацию,
которую необходимо знать пользователю
для применения ПС.

56.

ВНЕШНЕЕ ОПИСАНИЕ – СПЕЦИФИКАЦИЯ ПС
Внешнее описание ПС – спецификации ПС
является исходным документом для всех
последующих после анализа требований
этапов разработки ПС

57.

ВНЕШНЕЕ ОПИСАНИЕ – СПЕЦИФИКАЦИЯ ПС
Ошибки и неточности во внешнем описании
трансформируются в ошибки самой ПС
и обходятся особенно дорого
поскольку распространяются
на все последующие этапы разработки ПС

58.

ВНЕШНЕЕ ОПИСАНИЕ – СПЕЦИФИКАЦИЯ ПС
ОСНОВНЫЕ ТРУДНОСТИ В РАЗРАБТКЕ
ВНЕШЕНЕГО ОПИСАНИЯ ПС:
- пользователи часто плохо представляют,
что им на самом деле нужно;
проблемы,
которые
необходимо
отразить
в определении требований, могут не иметь определенной
формулировки, что приводит к постепенному изменению
понимания разработчиками этих проблем.
Причиной
тому является…
РАЗРАБОТКА ПС МОЖЕТ ПОТРЕБОВАТЬ
ПРИНЦИПИАЛЬНОГО ИЗМЕНЕНИЯ ВСЕЙ
ТЕХНОЛОГИИ ДЕЯТЕЛЬНОСТИ ПОЛЬЗОВАТЕЛЕЙ
(О ЧЕМ ПОЛЬЗОВАТЕЛИ, КАК ПРАВИЛО
НЕ ДОГАДЫВАЮТСЯ)

59.

Для помощи
пользователям
в определении
их требований
к ПС “анализу требований”
предшествует
“системный анализ”
1
2

60.

ВНЕШНЕЕ ОПИСАНИЕ – СПЕЦИФИКАЦИЯ ПС
Включает…
Функциональную
спецификацию
Спецификацию
качества
Определяет содержание
функций для реализации
в ПС
USED AT:
AUTHOR: Ê.Ý. Ïèñàðåíêî
PROJECT: Ïðîöåññû ðàçðàáîòêè ÏÎ ïî ISO/IEC
122007
NOTES: 1 2 3 4 5 6 7 8 9 10
Определяет планируемые
значения всех критериев
качества ПС, включая
приоритетность
реализации функций ПС
Определяет…
DATE: 27.12.2009
WORKING
REV:
DRAFT
27.12.2009
READER
DATE CONTEXT:
RECOMMENDED
PUBLICATION
A1.3.4.1.1
Критерии и примитивы качества ПС
Функциональность
Надежность
Завершенность
Завершенноcть
Точность
Автономность
Устойчивость
Защищенность
Легкость
применения
Эффективность
Сопровождаемость:
изучаемость и
модифицируемость
Мобильность
П-документированность
Временная
эффективность
С-документированность
Независимость
от устройств
Информативность
Эффективность
по ресурсам
Информативноcть
Автономноcть
Понятность
Коммуникабельность
Эффективность
по устройствам
Структурированность
Cтруктурированность
Устойчивоcть
Удобочитаемость
Защищенноcть
Расширяемость
Модульность
Модульноcть

61.

1 Определяет, что должно делать ПС
2 Определяет какими внешними свойствами должно обладать ПС
3 Должно быть понято пользователем, в степени достаточной
для принятия окончательного решения о заключении договора
на разработку ПС
4 Ставит для разработчиков ПС ориентиры,
управляющие выбором приемлемых решений
при реализации функций.
Внешнее описание не отвечает на вопросы,
как должно быть устроено ПС.

62.

Существуют также…
1 Спецификация архитектуры ПС
2 Спецификации программных модулей ПС
Можно рассматривать,
как детализации внешнего описания ПС

63.

Структура международного стандарта “IEEE 830-1998. Методика составления
спецификаций требований к программному обеспечению (SRS)”
1.Краткий обзор
1.1 Область действия
2. Публикации
3. Определения
4. Критерии получения качественной SRS
4.1 Сущность SRS
4.2 Среда SRS
4.3 Характеристики качественной SRS
4.4 Совместная подготовка SRS
4.5 Развитие SRS
4.6 Макетирование
4.7 Встраивание структуры в SRS
4.8 Встраивание требований проекта в SRS
5. Разделы SRS
5.1 Введение (Раздел 1 SRS)
5.2 Общее описание (Раздел 2 SRS)
5.3 Специфические требования (Раздел 3 SRS)
5.4 Дополнительная информация
Приложение А (информационное) Шаблоны SRS
Приложение Б (информационное) Указания по соответствию стандарту IEEE/EIA
12207/1-1997

64.

RECOMMENDED
Структура
спецификации
ПС по требованиям
МС
IEEE 830-1998
NOTES: 1 2 3
4 5 6 7 8 9 10
PUBLIC
ATION
Структура спецификации ПС согласно МС IEEE 830-1998
1 Введение
2 Общее
описание
1.1 Назначение
Перспектива ПС
1.2 Область
действия
Функции ПС
1.3 Определения,
акронимы и
сокращения
1.4 Публикации
1.5 Краткий обзор
Характеристики
пользователей
Ограничения
Допущения и
зависимости
Разделение
требований
3 Специфические
требования
Вспомогательная
информация
3.1 Внешние
интерфейсы
Содержание
3.2 Функции
3.3 Требования к
рабочим
характеристикам
3.4 Логические
требования к базе
данных
3.5 Проектные
ограничения
3.6 Атрибуты ПС
3.7 Организация
специфических
требований
3.8 Дополнительные
комментарии
Алфавитный
указатель
Приложения

65.

Структура спецификации ПС согласно МС IEEE 830-1998
1 Введение
2 Общее
описание
1.1 Назначение
Перспектива ПС
1.2 Область
действия
Функции ПС
1.3 Определения,
акронимы и
сокращения
1.4 Публикации
1.5 Краткий обзор
Характеристики
пользователей
Ограничения
Допущения и
зависимости
Разделение
требований
3 Специфические
требования
Вспомогательная
информация
3.1 Внешние
интерфейсы
Содержание
3.2 Функции
3.3 Требования к
рабочим
характеристикам
Алфавитный
указатель
Приложения
3.4 Логические
требования к базе
данных
3.5 Проектные
ограничения
Подраздел "1.1 Назначение":
3.6 Атрибуты ПС
а) назначение спецификации;
3.7 Организация
б) пользователи спецификации.
специфических
Подраздел 1.2 "Область действия“. этот требований
подраздел должен:
а) идентифицировать ПС, например, “Генератор
отчетов” и т.п.;
3.8 Дополнительные
комментарии не будет делать;
б) объяснять, что ПС будет и, в случае необходимости,
NODE:
NUMBER :
в) описывать
применениеTITLE:
задаваемого
включая связанные
ÑòðóêòóðàПС,
ñïåöèôèêàöèè
ÏÑ ñîãëàñíî ÌÑ IEEE
с ним выгоды, A0
цели и задачи;
830-1998
г) согласовываться с аналогичными формулировками в спецификациях
более высокого уровня (например, со спецификацией системных
требований), если они существуют.

66.

Структура спецификации ПС согласно МС IEEE 830-1998
1 Введение
2 Общее
описание
1.1 Назначение
Перспектива ПС
1.2 Область
действия
Функции ПС
1.3 Определения,
акронимы и
сокращения
1.4 Публикации
1.5 Краткий обзор
Характеристики
пользователей
Ограничения
Допущения и
зависимости
Разделение
требований
3 Специфические
требования
Вспомогательная
информация
3.1 Внешние
интерфейсы
Содержание
3.2 Функции
3.3 Требования к
рабочим
характеристикам
Алфавитный
указатель
Приложения
3.4 Логические
требования к базе
данных
3.5 Проектные
ограничения
Подраздел 1.4 "Публикации”.Этот подраздел
должен:
3.6 Атрибуты
ПС
а) представить полный список всех документов,
на которые делаются ссылки
3.7 Организация
специфических
в других местах спецификации;
требований
б) идентифицировать каждый документ по заголовку, номеру отчета
3.8 Дополнительные
(если применяется), дате и издательской организации;
комментарии
в) определить источники, из которых могут быть получены ссылки.
NODE:
TITLE:
NUMBER :
Ñòðóêòóðà
ñïåöèôèêàöèè
ÏÑ ñîãëàñíî
IEEE документ.
Эту информацию можно обеспечить
ссылкой
на приложение
илиÌÑдругой
830-1998
Подраздел 1.5A0
"Краткий обзор". Этот подраздел
должен:
а) описать, какие оставшиеся части содержатся в спецификации;
б) объяснить, как организована спецификация.

67.

68.

69.

Структура спецификации ПС согласно МС IEEE 830-1998
1 Введение
2 Общее
описание
1.1 Назначение
Перспектива ПС
1.2 Область
действия
Функции ПС
1.3 Определения,
акронимы и
сокращения
1.4 Публикации
1.5 Краткий обзор
NODE:
Характеристики
пользователей
Ограничения
Допущения и
зависимости
Разделение
требований
3 Специфические
требования
Вспомогательная
информация
3.1 Внешние
интерфейсы
Содержание
3.2 Функции
3.3 Требования к
рабочим
характеристикам
Алфавитный
указатель
Приложения
3.4 Логические
требования к базе
данных
3.5 Проектные
ограничения
ПОДРАЗДЕЛ 2.1 “ПЕРСПЕКТИВА ИЗДЕЛИЯ”
1 Этот подраздел спецификации оценивает
ПС в перспективе взаимодействия
с другими ПС.
Если ПС является независимым и
полностью автономным, это должно быть
отражено в спецификации.
2 В подразделе описываются различные
ограничения ПС во взаимодействии
с внешним окружением.
3.6 Атрибуты ПС
3.7 Организация
специфических
требований
а) Системные интерфейсы
3.8 Дополнительные
комментарии
TITLE:
Ñòðóêòóðà ñïåöèôèêàöèè ÏÑ ñîãëàñíî ÌÑ IEEE
830-1998
б)
A0 Интерфейсы пользователя
NUMBER :
Возможные ограничения во
взаимодействии с внешней
средой…
в) Аппаратные интерфейсы
г) Интерфейсы программного обеспечения
д) Интерфейсы связи (сетевые интерфейсы)
е) Память
ж) Операции
и) Требования к адаптации места использования

70.

Структура спецификации ПС согласно МС IEEE 830-1998
1 Введение
2 Общее
описание
1.1 Назначение
Перспектива ПС
1.2 Область
действия
Функции ПС
1.3 Определения,
акронимы и
сокращения
1.4 Публикации
1.5 Краткий обзор
Характеристики
пользователей
Ограничения
Допущения и
зависимости
Разделение
требований
3 Специфические
требования
Вспомогательная
информация
3.1 Внешние
интерфейсы
Содержание
3.2 Функции
3.3 Требования к
рабочим
характеристикам
Алфавитный
указатель
Приложения
3.4 Логические
требования к базе
данных
3.5 Проектные
ограничения
3.6 Атрибуты ПС
Подраздел 2.2 "Функции ПС"
3.7 Организация
специфических
Сводка основных функций, выполняемых программным
обеспечением.
требований
3.8 Дополнительные
Подраздел 2.3 "Характеристики пользователя"
комментарии
Описание общих характеристик
пользователей
ПС, включая
NODE:
TITLE:
Ñòðóêòóðà ñïåöèôèêàöèè ÏÑ ñîãëàñíî ÌÑ IEEE
образовательный уровень,
A0опыт и специальные технические
830-1998 знания.
Подраздел 2.5 "Допущения и зависимости"
Перечисление факторов, влияющих на требования, сформулированные
в спецификации.
Подраздел 2.6 "Распределение требований"
Идентификация требований, которые могут быть отложены
до появления будущих версий ПС.
NUMBER :

71.

Структура спецификации ПС согласно МС IEEE 830-1998
1 Введение
2 Общее
описание
1.1 Назначение
Перспектива ПС
1.2 Область
действия
Функции ПС
1.3 Определения,
акронимы и
сокращения
1.4 Публикации
1.5 Краткий обзор
Характеристики
пользователей
Ограничения
Допущения и
зависимости
Разделение
требований
3 Специфические
требования
Вспомогательная
информация
3.1 Внешние
интерфейсы
Содержание
3.2 Функции
3.3 Требования к
рабочим
характеристикам
Алфавитный
указатель
Приложения
3.4 Логические
требования к базе
данных
3.5 Проектные
ограничения
Подраздел 2.4 "Ограничения” (за исключением
ограничений во
3.6 Атрибуты ПС
взаимодействии с внешней средой, описываемых
в разделе 2.1)
3.7 Организация
Этот подраздел спецификации обеспечивает
общее описание любых других
специфических
требований
позиций, которые будут ограничивать возможности
разработчика.
Они включают: а) регулирующие политики; 3.8
б) Дополнительные
аппаратные ограничения (например,
комментарии
требования к синхронизации сигналов); в) интерфейсы с другими приложениями;
NODE:
TITLE:
NUMBER :
ñïåöèôèêàöèè
ÏÑ ñîãëàñíî
ÌÑ IEEE
г) параллельные
операции;
д)Ñòðóêòóðà
функции контроля;
е) функции
управления;
ж) требования A0
к языку более высокого порядка; 830-1998
з) протоколы квитирования
сигналов (например, XON-XOFF..ACK-NACK); и) требования к надежности;
к) критичность применения; л) критерии безопасности и защиты.

72.

Структура спецификации ПС согласно МС IEEE 830-1998
1 Введение
2 Общее
описание
1.1 Назначение
Перспектива ПС
1.2 Область
действия
Функции ПС
1.3 Определения,
акронимы и
сокращения
1.4 Публикации
1.5 Краткий обзор
Характеристики
пользователей
Ограничения
Допущения и
зависимости
Разделение
требований
3 Специфические
требования
Вспомогательная
информация
3.1 Внешние
интерфейсы
Содержание
3.2 Функции
3.3 Требования к
рабочим
характеристикам
Алфавитный
указатель
Приложения
3.4 Логические
требования к базе
данных
3.5 Проектные
ограничения
Этот раздел спецификации содержит
все требования к ПС на уровне
3.6 Атрибуты
ПС
детализации, достаточной, чтобы дать
проектировщикам
возможность
Организациячто ПС удовлетворяет
разработать ПС, а испытателям - 3.7
убедиться,
специфических
заданным требованиям.
требований
Для этого
необходимо …
3.8 Дополнительные
комментарии
NUMBER :
1 Описание TITLE:
каждого
входного
воздействия
на ПС.
Ñòðóêòóðà
ñïåöèôèêàöèè
ÏÑ ñîãëàñíî
ÌÑ IEEE
A0
830-1998
2 Описание каждого выходного сигнала (отклика) ПС
и всех функций, выполняемых ПС в ответ на входное воздействие
или для поддержания выходного сигнала.
NODE:

73.

Структура спецификации ПС согласно МС IEEE 830-1998
1 Введение
2 Общее
описание
1.1 Назначение
Перспектива ПС
1.2 Область
действия
Функции ПС
1.3 Определения,
акронимы и
сокращения
1.4 Публикации
1.5 Краткий обзор
Характеристики
пользователей
Ограничения
Допущения и
зависимости
Разделение
требований
3 Специфические
требования
Вспомогательная
информация
3.1 Внешние
интерфейсы
Содержание
3.2 Функции
3.3 Требования к
рабочим
характеристикам
Алфавитный
указатель
Приложения
3.4 Логические
требования к базе
данных
3.5 Проектные
ограничения
3.6 Атрибуты
ПСпредставляет
Подраздел 3.1 "Внешние интерфейсы". Этот
раздел
3.7 Организация
детализированное описание всех входных испецифических
выходных данных ПС, включая:
требований
а) наименование позиции;
3.8 Дополнительные
б) описание назначения;
комментарии
в) источникNODE:
(для входных данных)
или адресат
(для выходных
TITLE:
NUMBER :
Ñòðóêòóðà
ñïåöèôèêàöèè
ÏÑ ñîãëàñíî данных);
ÌÑ IEEE
A0
830-1998
г) допустимый диапазон,
точность и/или допуск значений;
д) единицы измерения;
е) синхронизация (с другими данными);
ж) cвязи с другими входами/выходами;
и) форматы/организация экрана;
к) форматы/организация окна;
л) форматы данных;
м) форматы команд и др.

74.

Структура спецификации ПС согласно МС IEEE 830-1998
1 Введение
2 Общее
описание
1.1 Назначение
Перспектива ПС
1.2 Область
действия
Функции ПС
1.3 Определения,
акронимы и
сокращения
1.4 Публикации
1.5 Краткий обзор
Характеристики
пользователей
Ограничения
Допущения и
зависимости
Разделение
требований
3 Специфические
требования
Вспомогательная
информация
3.1 Внешние
интерфейсы
Содержание
3.2 Функции
3.3 Требования к
рабочим
характеристикам
Алфавитный
указатель
Приложения
3.4 Логические
требования к базе
данных
3.5 Проектные
ограничения
Подраздел 3.3 "Требования к рабочим характеристикам".
В этом подразделе
3.6 Атрибуты ПС
определяются требования к статическим и динамическим
числовым
3.7 Организация
специфических
характеристикам ПС, таким, как:
требований
а) число поддерживаемых терминалов; б) число
одновременно поддерживаемых
3.8 Дополнительные
комментарии
пользователей; в) количество и тип обрабатываемой информации;
NODE:
TITLE:
NUMBER :
Ñòðóêòóðà
ñïåöèôèêàöèè
ÏÑ ñîãëàñíî
ÌÑ IEEE
г) количество групповых
операций
и
задач;
д)
количество
данных,
которые
будут
A0
830-1998
обрабатываться в пределах определенных периодов времени для нормальных и
пиковых условий рабочей нагрузки.
Подраздел 3.4 "Логические требования к базе данных“. В этом подразделе
описываются логические требования для любой информации, которая должна
размещаться в базе данных. Она может включать следующее:
а) Типы информации, используемой различными функциями; б) Частота
использования; в) Возможности доступа; г) Информационные объекты и их связи;
д) Ограничения целостности; е) Требования к сохранности данных.

75.

PROJECT: Ñòðóêòóðà ñïåöèôèêàöèè ÏÑ ïî
òðåáîâàíèÿì ÌÑ IEEE 830-1998
REV:
27.12.2009
DRAFT
TOP
Структура спецификации ПС по требованиям МС IEEE 830-1998
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLIC ATION
A-0
Структура спецификации ПС согласно МС IEEE 830-1998
1 Введение
2 Общее
описание
1.1 Назначение
Перспектива ПС
1.2 Область
действия
Функции ПС
1.3 Определения,
акронимы и
сокращения
1.4 Публикации
1.5 Краткий обзор
Характеристики
пользователей
Ограничения
Допущения и
зависимости
Разделение
требований
3 Специфические
требования
Вспомогательная
информация
3.1 Внешние
интерфейсы
Содержание
3.2 Функции
3.3 Требования к
рабочим
характеристикам
Алфавитный
указатель
Приложения
3.4 Логические
требования к базе
данных
3.5 Проектные
ограничения
Определяет …
3.6 Атрибуты ПС
USED AT:
AUTHOR: Ê.Ý. Ïèñàðåíêî
DATE: 27.12.2009
WORKING
PROJECT: Ïðîöåññû ðàçðàáîòêè ÏÎ ïî ISO/IEC
специфических
122007
REV:
DRAFT
NOTES: 1 2 3 4 5 6 7 8 9 10
Определяет …
3.7 Организация
27.12.2009
требований
3.8 Дополнительные
комментарии
NODE:
TITLE:
A0
Надежность
Завершенность
Завершенноcть
Точность
Автономность
Устойчивость
Защищенность
DATE CONTEXT:
RECOMMENDED
PUBLICATION
A1.3.4.1.1
Критерии и примитивы качества ПС
Ñòðóêòóðà ñïåöèôèêàöèè ÏÑ ñîãëàñíî ÌÑ IEEE
830-1998
Функциональность
READER
NUMBER :
Легкость
применения
Эффективность
Сопровождаемость:
изучаемость и
модифицируемость
Мобильность
П-документированность
Временная
эффективность
С-документированность
Независимость
от устройств
Информативность
Эффективность
по ресурсам
Информативноcть
Автономноcть
Понятность
Коммуникабельность
Эффективность
по устройствам
Структурированность
Cтруктурированность
Устойчивоcть
Удобочитаемость
Защищенноcть
Расширяемость
Модульность
Модульноcть

76.

Структура спецификации ПС по требованиям МС IEEE 830-1998
1 Стандарт IEEE 830-1998 не требует в точности
повторять описанную структуру
спецификации и описанные наименования
разделов спецификации.
2 Важным является отразить всю информацию
предусмотренную IEEE 830-1998 .
3 Разделы спецификации требуемые IEEE 830-1998
могут содержаться в разных документах, с названиями
отличными от слова “спецификация”. Например
часть или вся требуемая IEEE 830-1998 информация
может быть отражена документе с названием
“Концепции программного продукта”.

77.

Практическое задание
USED AT:
Определите разделы которые Вы бы
включили во внешнее описание: в
спецификацию качества и функциональную
спецификацию Вашего программного
средства.
AUTHOR: Ê.Ý. Ïèñàðåíêî
DATE: 27.12.2009
WORKING
PROJECT: Ñòðóêòóðà ñïåöèôèêàöèè ÏÑ ïî
òðåáîâàíèÿì ÌÑ IEEE 830-1998
REV:
DRAFT
27.12.2009
READER
PUBLIC ATION
Структура спецификации ПС согласно МС IEEE 830-1998
2 Общее
описание
1.1 Назначение
Перспектива ПС
1.2 Область
действия
Функции ПС
1.3 Определения,
акронимы и
сокращения
1.4 Публикации
1.5 Краткий обзор
Характеристики
пользователей
Ограничения
Допущения и
зависимости
Разделение
требований
TOP
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
1 Введение
DATE CONTEXT:
3 Специфические
требования
Вспомогательная
информация
3.1 Внешние
интерфейсы
Содержание
3.2 Функции
3.3 Требования к
рабочим
характеристикам
3.4 Логические
требования к базе
данных
3.5 Проектные
ограничения
3.6 Атрибуты ПС
3.7 Организация
специфических
требований
3.8 Дополнительные
комментарии
Алфавитный
указатель
Приложения
A-0

78.

Показатели и критерии качества описания ПС согласно IEEE 830-1998
Показатель
Критерий
1 Корректность
Каждое требование в спецификации
является требованием, которому должно
удовлетворять программное обеспечение
2 Однозначность
Каждое изложенное требование в
спецификации может интерпретироваться
только однозначно
3 Полнота
Спецификация включает: а) все
существенные требования; б)
определение откликов программного
обеспечения на все классы входных
данных; в) полные обозначения и ссылки
на все рисунки, таблицы, схемы,
определения всех терминов и единиц
измерения
4 Непротиворечивость Никакой набор отдельных требований,
описанных в спецификации, не находится
в противоречии с ней

79.

Показатели и критерии качества описания ПС согласно IEEE 830-1998
Показатель
Критерий
5 Упорядоченность по
значимости и/или
устойчивости
Каждое требование в спецификации
имеет идентификатор, указывающий или
значимость или устойчивость этого
конкретного требования
6 Проверяемость
Каждое требование, изложенное в
спецификации, может быть проверено.
7 Модифицируемость
Структура и стиль спецификации таковы,
что любые изменения требований могут
быть выполнены легко, полностью и
непротиворечивым образом при
сохранении структуры и стиля
спецификации.
8 Отслеживаемость
Спецификация является отслеживаемой,
если четко прослеживается источник
каждого из ее требований и если она
облегчает обращение к каждому из
требований при дальнейшей разработке
или модернизации документации.

80.

Способы определения требований к ПС
Определение
требований к ПС
Управляемое
пользователем
Независимое
от пользователя
Контролируемое
пользователем

81.

Инструменты составления требований к ПС
Инструменты
составления
требований к ПС
Объектноориентированные
Процессноориентированные
Ориентированные
на представление
поведенческих
характеристик
Унифицированный
процесс разработки
объектноориентированных
систем (RUP) и
унифицированный язык
моделирования (UML)
Метод структурного
анализа и
моделирования (SADT)
и диаграммы в
формате IDEF0
Математические
функции и конечные
автоматы

82.

Функциональная спецификация ПС
Функциональная
спецификация ПС
Описание
внешней
информационной
среды
Определение
функций ПС
- используемые каналы
ввода и вывода;
- информационные
объекты;
- существенные связи
между
информационными
объектами
- обозначения всех
определяемых функций;
- спецификации всех
входных данных и
результатов выполнения
каждой функции;
- семантика каждой
функции
Описание
нежелательных
(исключительных)
ситуаций
- все существенные
случаи, когда ПС не
сможет нормально
выполнить ту или иную
свою функцию

83.

Методы контроля внешнего описания ПС
Методы
контроля
внешнего
описания ПС
Статический
просмотр
Ручная имитация
Смежный
контроль
Пользовательский
контроль

84.

Технология разработки
программного обеспечения
АРХИТЕКТУРА ПРОГРАММНЫХ СРЕДСТВ
ЛЕКЦИЯ 3

85.

АРХИТЕКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Архитектура программного обеспечения —
это структура программы или
вычислительной системы, которая включает
программные компоненты, видимые снаружи
свойства этих компонентов, а также отношения
между ними.

86.

Проектирование ПО высокого уровня (концептуальное
проектирование) – архитектурное проектирование.
НЕ РЕШАЕТ ЗАДАЧУ КАКИМ ОБРАЗОМ РЕАЛИЗОВАТЬ
ТРЕБУЕМЫЕ ОТ ПО ФУНКЦИИ
Проектирование ПО низкого уровня – детальное
проектирование. РЕШАТЕТ ЗАДАЧУ РЕАЛИЗАЦИИ
ФУНКЦИЙ ПО В РАМКАХ СОЗДАННОЙ АРХИТЕКТУРЫ –
т.е. в рамках накладываемых ею ограничений.
Архитектура ПО определяет глобальные ограничения,
накладываемые на проектирование системы, такие как:
1)выбор парадигмы программирования
2)стандарты разработки ПО,
3)принципы проектирования и ограничения,
накладываемые государственным законодательством.

87.

88.

Критерии и примитивы качества ПС согласно МС ISO/IEC 9126
USED AT:
A UTHOR: Ê.Ý . Ïèñàðåíêî
DA TE: 27.12.2009
WORKING
PROJECT: Ïðîöåññû ðàçðàáîòêè ÏÎ ïî ISO/IEC
122007
REV :
DRAFT
27.12.2009
REA DER
DA TE CONTEXT:
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
A 1.3.4.1.1
Критерии и примитивы качества ПС
Функциональность
Надежность
Завершенность
Завершенноcть
Точность
Автономность
Устойчивость
Защищенность
Эффективность
Сопровождаемость:
изучаемость и
модифицируемость
Мобильность
П-документированность
Временная
эффективность
С-документированность
Независимость
от устройств
Информативность
Эффективность
по ресурсам
Информативноcть
Автономноcть
Понятность
Коммуникабельность
Эффективность
по устройствам
Структурированность
Cтруктурированность
Легкость
применения
Устойчивоcть
Удобочитаемость
Защищенноcть
Расширяемость
Модульность
Разработка архитектуры
– это способ
со сложность
ПО
Êðèòåðèèборьбы
è ïðèìèòèâû êà÷åñòâà
ÏÑ
NODE:
TITLE:
A1.3.4.1.1.1
NUMBER:
Модульноcть

89.

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

90.

Представления архитектуры интегрированных
информационных систем
(ARIS – Architecture of Integrated Information Systems)
компании IDS Scheer AG

91.

Представления архитектуры ARIS
События
Исполнитель
функции
Состояния
окружения
функций
Функции
Ресурсы
Первый шаг при создании архитектуры интегрированных информационных системы (ARIS) разработка модели бизнес-процесса, для улучшения организации которого разрабатывается ПС

92.

Представления архитектуры ARIS
Состояния
и события
Функции и их
взаимосвязи
Орг. единицы
и их взаимосвязи
Ресурсы
Для упрощения модель бизнес-процесса делится
на отдельные типы моделей

93.

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

94.

Представления архитектуры интегрированных
информационных систем
(ARIS – Architecture of Integrated Information Systems)
компании IDS Scheer AG
Управляющая модель – важнейшая компонента
архитектуры ARIS, отличающая ее от архитектур,
предлагаемых другими авторами.

95.

Модель жизненного цикла
программного обеспечения ARIS
Каждое представление
архитектуры ARIS (каждая
модель ARIS) делится
на уровни представления,
соответствующие каждому
из этапов жизненного цикла ПО

96.

97.

Модели отражают цели
пользователей в работе
с ПО и их язык
Модели отражают требования
пользователей и других
заинтересованных сторон к ПО
в их терминах
Модели отражают требования
пользователей и других
заинтересованных сторон к ПО в
терминах информационных технологий
Модели отражает конкретные
программные и аппаратные компоненты
на которых реализуется ПО

98.

Диаграмма процесса – описание текущих
проблем бизнеса

99.

Функциональное
дерево
– формулировка
требований

100.

Привязка экранов и списков
– спецификация проекта

101.

Привязка типов ПС, типов
программных элементов и
программных элементов
– описание реализации

102.

Представления
архитектуры
унифицированного
процесса
разработки ПО
(RUP)
IBM Rational
1 Бизнес-модель. Определяет абстракцию организации, для которой создается система.
2 Модель области определения. Фиксирует контекстное окружение системы.
3 Модель Use Case – вариантов использования. Определяет функциональные требования к системе.
4 Модель анализа. Интерпретирует требования к системе в терминах проектной модели.
5 Проектная модель. Определяет словарь проблемы и ее решение.
6 Модель размещения. Определяет аппаратную топологию, в которой исполняется система.
7 Модель реализации. Определяет части, которые используются для сборки и реализации физической
системы.
8 Тестовая модель. Определяет тестовые варианты для проверки системы.
9 Модель процессов. Определяет параллелизм в системе и механизмы синхронизации.
В отличие от ARIS каждое представление архитектуры RUP:
1 Ориентировано на определенную группу заинтересованных сторон.
2 Описывается с помощью разных моделей предназначенных для
определенных групп заинтересованных сторон.
3 Каждое представление не делиться на уровни.

103.

Представления
архитектуры
унифицированного
процесса
разработки ПО
(RUP)
IBM Rational
Представления
архитектуры
интегрированных
информационных
систем (ARIS) IDS Sheer AG
В отличие от RUP каждое представление архитектуры ARIS:
1 Ориентировано на все группы заинтересованных сторон.
2 Описывается с помощью одной модели.
3 Каждое представление – модель делиться на уровни
ориентированные на определенные группы заинтересованных сторон.

104.

105.

Пронизывают
Архитектурный
подход
в проектах
Электронного
Правительства
РФ

106.

Пронизывают
Архитектурный
подход
в проектах
Электронного
Правительства
РФ
Аспект: информации и данных
ОПРЕДЕЛЯЕТ
УРОВЕНЬ ДЕЯТЕЛЬНОСТИ:
состав информации,
необходимой для поддержания
административных процессов
(например процессов
взаимодействия между
разными ведомствами
УРОВЕНЬ
ПРИКЛАДНЫХ
СИСТЕМ:
информационные
объекты (сущности) для
реализации на уровне
отдельных прикладных
систем
УРОВЕНЬ
ТЕХНОЛОГИЧЕСКОЙ
ПЛАТФОРМЫ:
информационные
объекты (сущности) для
реализации на уровне
информационной
системы в целом

107.

Пронизывают
Архитектурный
подход
в проектах
Электронного
Правительства
РФ
Аспект: эффективности и результативности
ОПРЕДЕЛЯЕТ
УРОВЕНЬ ДЕЯТЕЛЬНОСТИ:
показатели эффективности работы
органов государственной власти в
результате внедрения
информационной системы
УРОВЕНЬ
ПРИКЛАДНЫХ
СИСТЕМ: показатели
эффективности работы
отдельных прикладных
систем
УРОВЕНЬ
ТЕХНОЛОГИЧЕСКО
Й ПЛАТФОРМЫ:
показатели
эффективности
информационной
системы

108.

Элементы (перспективы) производственной
архитектуры Microsoft Solution Framework (MSF)
Концептуальное, логическое
и физическое представления

109.

Архитектура программного обеспечения
Практическое задание
1 Определите точки зрения каких
заинтересованных сторон и почему должна
отражать архитектура Вашего программного
средства.
2 Какая из рассмотренных моделей
архитектур наиболее приемлема для Вашего
программного средства.

110.

Основные модели структурирования ПС
Модели
структурирования
ПС
на подсистемы
Модели управления
связями между
подсистемами ПС
- Модель хранилища
данных;
- Модель
централизованного
управления;
- модель клиентсервер;
- трехуровневая
модель;
- модель абстрактной
машины.
- модель
событийного
управления.
Модели
декомпозиции
подсистем ПС на
модули
- Модель потока
данных;
- модель объектов.

111.

Модель структурирования программного средства на подсистемы
- Модель хранилища данных
Подсистемы
Данные
хранятся
в общей
памяти

112.

Модель структурирования программного средства на подсистемы
- Модель клиент-сервер
Подсистемы
Разные типы данных
распределены
по разным серверам

113.

Модель структурирования программного средства на подсистемы
- Трехуровневая модель
Подсистемы –
программные
приложения
расположены
на отдельном
сервере
Разные типы данных
распределены
по разным серверам

114.

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

115.

116.

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

117.

Модель управления связями между подсистемами ПС
– Модель менеджера
Системный контролер
– руководит работой
остальных подсистем
Модель
предусматривает
параллельную
работу подсистем

118.

Модель управления связями между подсистемами ПС
– Широковещательная модель
Каждая подсистема уведомляет обработчик
об интересе к тому или иному событию
Обработчик передает событие подсистеме
для обработки
Функции управления
в обработчике событий
отсутствуют

119.

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

120.

Основные модели структурирования ПС
Модели
структурирования
ПС
на подсистемы
Модели управления
связями между
подсистемами ПС
- Модель хранилища
данных;
- Модель
централизованного
управления;
- модель клиентсервер;
- трехуровневая
модель;
- модель
событийного
управления.
- модель абстрактной
машины.
Разбиение по
функциям
Модели
декомпозиции
подсистем ПС на
модули
- Модель потока
данных;
- модель объектов.
Разбиение по
наборам данных,
состояниям и
наборам операций

121.

Информационная
закрытость модуля
Означает
1 Все модули
независимы,
обмениваются только
информацией,
необходимой для
работы
2 Доступ к операциям
и структурам данных
модуля ограничен
Благодаря этому
1 Обеспечивается возможность разработки программных модулей
различными, независимыми коллективами разработчиков
2 Обеспечивается легкая модификация ПО

122.

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

123.

Учитывается
1 Мера сложности внешних связей (между модулями) – "сцепление"
2 Мера сложности внутренних связей (внутри модулей) – "связность"

124.

Состав задач проектирования архитектуры программного средства
согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
Трансформация
требований к ПС
в архитектуру
Описание
структуры и
компонент ПС
Разработка
эскизного проекта
баз данных,
внешних
интерфейсов ПС и
интерфейсов между
его компонентами
Оценка архитектуры
ПС
Разработка
предварительных
требований к
тестированию ПС

125.

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

126.

Содержание МС “ISO ISO/IEC 42010:2007 (IEEE 1471).
Технология систем и программного обеспечения. Рекомендуемая
практика архитектурного описания программно-интенсивных систем
1 Обзор области применения стандарта
2 Ссылки на родственные стандарты
3 Практика архитектурных описаний:
- документирование архитектуры;
- идентификация заинтересованных лиц и их интересов;
- селекция архитектурных точек зрения;
- архитектурные виды;
- обоснование выбора архитектур;
- образцы использования архитектур.
4 Приложения
- библиография;
- замечания по терминологии;
- образцы точек зрения;
- отношения с другими стандартами.

127.

Модель проектирования архитектуры программного средства
МС “ISO ISO/IEC 42010:2007 (IEEE 1471)
Представлена в виде семантической сети, связывающей основные
понятия архитектуры с помощью некоторых отношений
Отношения: 1 Различается; 2 Различается; 3 Выбирается; 4 Агрегируется,
5 Состоит из видов; 6 Имеет; 7 Адресуется; 8 Реализуется; 9 Покрывает;
10 Устанавливает форму; 11 Состоит из моделей; 12 Содержит; 13 Убеждает;
14 Представляет; 15 Использует; 16 Имеет; 17 Размещена; 18 Обеспечивает)

128.

МС “ISO ISO/IEC
42010:2007 (IEEE 1471)
Использует
Различается
Адресуется
Имеет
а) лица приобретающие ПС;
б) эксперты-консультанты, проверяющие целесообразность приобретения;
в) пропагандисты, распространяющие сведения о ПС через документы и обучение;
г) разработчики, создающие ПС;
д) лица сопровождающие, внедряющие и развивающие ПС;
е) снабженцы, поставляющие "комплектующие части";
ж) пользователи, обеспечивающие использование системы по назначению;
и) администраторы, обеспечивающие функционирование ПС;
к) тестировщики, проверяющие корректность работы ПС.

129.

МС “ISO ISO/IEC
42010:2007 (IEEE 1471)
Различается
Имеет
Покрывает
Например
"Интерес к тем функциям, которые исполнимы в ПС,
а значит к поведению ПС"
"Интерес к защищенности ПС по отношению к несанкционированному
доступу"
"Интерес к позитивным эффектам, достижимым при использовании ПС"

130.

Технология разработки
программного обеспечения
РАЗРАБОТКА СТРУКТУРЫ ПРОГРАММЫ
И МОДУЛЬНОЕ ПРОГРАММИРОВАНИЕ
ЛЕКЦИИ 4 - 5

131.

132.

Информационная закрытость модуля

133.

Информационная закрытость модуля

134.

ПРОГРАММНЫЕ МОДУЛИ:
1 “Вычислять синус угла”
2 “Проверять орфографию”
3 “Читать запись файла”
4 “Вычислять координаты цели”
5 “Вычислять зарплату сотрудника”
6 “Определять место пассажира”
В КАЖДОМ МОДУЛЕ ВЫПОЛНЯЕТСЯ ТОЛЬКО ОДНА ФУНКЦИЯ

135.

Модуль "Прием и проверка записи”,
включает следующие элементы:
- 1 - Прочитать запись из файла;
- 2 - Проверить контрольные данные в записи;
- 3 - Удалить контрольные поля в записи;
- 4 - Вернуть обработанную запись;
Конец модуля.
В ОДНОМ МОДУЛЕ ВЫПОЛНЯЕТСЯ НЕСКОЛЬКО ФУНКЦИЙ
(ВЫПОЛНЯЮТСЯ ВСЕ ОБЯЗАТЕЛЬНО), СЛЕДУЮЩИХ
СТРОГО ОДНА ЗА ДРУГОЙ И ИСПОЛЬЗУЮЩИХ ОДИН НАБОР ДАННЫХ

136.

Модуль "Отчет и средняя зарплата"
использует "Таблицу зарплаты служащих"
и включает следующие элементы:
- Сгенерировать "Отчет по зарплате";
- Вычислить параметр "Средняя зарплата";
- Вернуть отчет по зарплате "Средняя зарплата";
Конец модуля
МОДУЛЬ ВКЛЮЧАЕТ НЕСКОЛКО ФУНКЦИЙ КОТОРЫЕ МОГУТ
ВЫПОЛНЯТСЯ ОДНОВРЕМЕННО, В РАЗНОЙ
ПОСЛЕДОВАТЕЛЬНОСТИ, МОГУТ ВЫПОЛНЯТСЯ ВСЕ ФУНКЦИИ ИЛИ
ТОЛЬКО ЧАСТЬ ИЗ НИХ , ПРИ ЭТОМ ВСЕ ОНИ ИСПОЛЬЗУЮТ
ОДНИ И ТЕ ЖЕ НАБОРЫ ДАННЫХ

137.

ФУНКЦИИ МОДУЛЯ
ВЫПОЛНЯЮТСЯ
В РАМКАХ ОДНОЙ
ПРОЦЕДУРЫ.
При этом могут
выполняться
с использованием
разных наборов
данных, но строго
последовательно
Модуль “Вычисление средних значений”
использует Таблицы данных “А” и “В”
суммаТабл-А:= 0
суммаТабл-В:= 0
для i := 1 до 300
суммаТабл-А := суммаТабл-А + Таблица-А(i)
суммаТабл-В :- суммаТабл-В + Таблица-В(i)
конец для
среднееТабл-А := суммаТабл-А / 300
среднееТабл-В := суммаТабл-В / 300
вернуть среднееТабл-А, среднееТабл-В
Конец модуля

138.

ВСЕ ФУНКЦИИ
НЕОБХОДИМО
ВЫПОЛНИТЬ
ОДНОВРЕМЕННО
При этом они могут
использовать разные
наборы данных и
выполняться
в разной
последовательности
Модуль “Инициализировать Систему”:
- 1 - Перемотать магнитную ленту “№1”;
- 2 - Счетчик магнитной ленты “№1”:= 0;
- 3 - Перемотать магнитную ленту “№2”;
- 4 - Счетчик магнитной ленты “№2”:= 0;
- 5 - Таблица тек. записей: = пробел .. пробел;
- 6 - Таблица количества записей:= 0 .. 0;
- 7 - Переключатель №1: = “Выкл.”;
- 8 - Переключатель №2:= “Вкл.”
Конец модуля

139.

ФУНКЦИИ
СВЯЗАНЫ МЕЖДУ
СОБОЙ СМЫСЛУ.
При этом функции
модуля могут
использовать разные
наборы данных,
могут выполняться
все или часть из них
в зависимости от
запроса
пользователя или
другого модуля
Модуль “Пересылка сообщения”
- Переслать по электронной почте
- Переслать по факсу
- Послать в телеконференцию
- Переслать по ftp-протоколу
Конец модуля

140.

ФУНКЦИИ НИКАКИМ
ОБРАЗОМ НЕ
СВЯЗАНЫ МЕЖДУ
СОБОЙ ПО СМЫСЛУ,
ВРЕМЕНИ
ВЫПОЛНЕНИЯ И
ИСПОЛЬЗУЕМЫМ
НАБОРАМ ДАННЫХ
Модуль “Разные функции”
Поздравить с Новым годом (...)
Проверить исправность аппаратуры (...)
Заполнить анкету (...)
Измерить температуру (...)
Вывести собаку на прогулку (...)
Запастись продуктами (...)
Приобрести автомобиль (...)
Конец модуля

141.

SED AT:
AUTHOR: Ê.Ý. Ïèñàðåíêî
DATE: 04.01.2010
WORKING
READER
PROJECT: Ïðîöåññû ðàçðàáîòêè
ÏÎ ïî ISO/IEC 122007
REV: 07.03.2011 связности
DRAFT
Алгоритм
определения
уровня
модуля
RECOMMENDED
программного
средства
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
Начало
Да
1) - Модуль
- е диничная
проблемно
-орие нтированная
функция
Да
Уровень
связанности: =
"Функциональный"
Не т
2) Де йствия
внутри
модуля
связаны
Не т
3) Де йствия
внутри модуля
связаны
данными
5) Порядок
де йствий внутри
модуля важен
Не т
6) Де йствия
внутри модуля
принадле жат к
одной
кате гории
Не т
Да
Да
4) Порядок
де йствий внутри
модуля важен
Да
4) Уровень
Не т, при этом
Не т
связности:
де йствия внутри
4) Уровень
= "Информационный"
модуля связаны
связности: =
потоком
"Коммуникативный"
управле ния
Да
5) Уровень связности: =
"Процедурный"
5) Уровень связности: =
"Вре менной"
6) Уровень связности:
= "Логический"
6) Уровень связности:
= "По совпадению"
Коне ц

142.

ПРОГРАММНЫЕ МОДУЛИ:
1 “Вычислять синус угла”
2 “Проверять орфографию”
3 “Читать запись файла”
4 “Вычислять координаты цели”
5 “Вычислять зарплату сотрудника”
SED AT:
AUTHOR: Ê. Ý. Ï èñàðåí êî
DATE: 04.01. 2010
WORKI NG
PROJECT: Ï ðî öåññû ðàçðàáîòêè ÏÎ ï î ISO/ IEC 122007
REV:
DR AFT
07.03. 2011
REC OMMEND ED
6 “Определять место пассажира”
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLIC ATION
Начало
Да
1) - М одуль
- е диничная
проблемно
-орие нтированная
функция
Да
Уровень
связанности: =
"Функциональный"
Не т
2) Де йствия
внутри
модуля
связаны
Не т
READ ER
3) Де йствия
внутри модуля
связаны
данными
Да
4) Порядок
де йствий внутри
модуля важ ен
Не т, при этом
Не т
де йствия внутри
4) Уровень
модуля связаны
связности: =
потоком
"Коммуникативный"
управле ния
5) Порядок
де йствий внутри
модуля важ ен
Не т
6) Де йствия
внутри модуля
принадле ж ат к
одной
кате гории
Не т
Да
Да
Да
4) Уровень
связности:
= "Информационный"
5) Уровень связности: =
"Процедурный"
5) Уровень связности: =
"Вре менной"
6) Уровень связности:
= "Логический"
6) Уровень связности:
= "По совпадению"
Коне ц

143.

Модуль "Прием и проверка записи”,
включает следующие элементы:
- 1 - Прочитать запись из файла;
- 2 - Проверить контрольные данные в записи;
- 3 - Удалить контрольные поля в записи;
SED AT:
- 4 - Вернуть обработанную запись;
AUTHOR: Ê. Ý. Ï èñàðåí êî
DATE: 04.01. 2010
WORKI NG
PROJECT: Ï ðî öåññû ðàçðàáîòêè ÏÎ ï î ISO/ IEC 122007
REV:
DR AFT
07.03. 2011
READ ER
REC OMMEND ED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLIC ATION
Начало
Да
1) - М одуль
- е диничная
проблемно
-орие нтированная
функция
Да
Уровень
связанности: =
"Функциональный"
Не т
2) Де йствия
внутри
модуля
связаны
Не т
3) Де йствия
внутри модуля
связаны
данными
Да
4) Порядок
де йствий внутри
модуля важ ен
Не т, при этом
Не т
де йствия внутри
4) Уровень
модуля связаны
связности: =
потоком
"Коммуникативный"
управле ния
5) Порядок
де йствий внутри
модуля важ ен
Не т
6) Де йствия
внутри модуля
принадле ж ат к
одной
кате гории
Не т
Да
Да
Да
4) Уровень
связности:
= "Информационный"
5) Уровень связности: =
"Процедурный"
5) Уровень связности: =
"Вре менной"
6) Уровень связности:
= "Логический"
6) Уровень связности:
= "По совпадению"
Коне ц

144.

Модуль "Отчет и средняя зарплата"
использует "Таблицу зарплаты служащих"
и включает следующие элементы:
- Сгенерировать "Отчет по зарплате";
- Вычислить параметр "Средняя зарплата";
SED AT:
- Вернуть отчет по зарплате "Средняя зарплата";
AUTHOR: Ê. Ý. Ï èñàðåí êî
DATE: 04.01. 2010
WORKI NG
PROJECT: Ï ðî öåññû ðàçðàáîòêè ÏÎ ï î ISO/ IEC 122007
REV:
DR AFT
07.03. 2011
READ ER
REC OMMEND ED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLIC ATION
Начало
Да
1) - М одуль
- е диничная
проблемно
-орие нтированная
функция
Да
Уровень
связанности: =
"Функциональный"
Не т
2) Де йствия
внутри
модуля
связаны
Не т
3) Де йствия
внутри модуля
связаны
данными
Да
4) Порядок
де йствий внутри
модуля важ ен
Не т, при этом
Не т
де йствия внутри
4) Уровень
модуля связаны
связности: =
потоком
"Коммуникативный"
управле ния
5) Порядок
де йствий внутри
модуля важ ен
Не т
6) Де йствия
внутри модуля
принадле ж ат к
одной
кате гории
Не т
Да
Да
Да
4) Уровень
связности:
= "Информационный"
5) Уровень связности: =
"Процедурный"
5) Уровень связности: =
"Вре менной"
6) Уровень связности:
= "Логический"
6) Уровень связности:
= "По совпадению"
Коне ц

145.

Модуль “Вычисление средних значений”
использует Таблицы данных “А” и “В”
SED AT:
суммаТабл-А:= 0
суммаТабл-В:= 0
для i := 1 до 300
суммаТабл-А := суммаТабл-А + Таблица-А(i)
суммаТабл-В :- суммаТабл-В + Таблица-В(i)
конец для
среднееТабл-А := суммаТабл-А / 300
AUTHOR: Ê. Ý. Ï èñàðåí êî
DATE: 04.01. 2010
WORKI NG
READ ER
среднееТабл-В
суммаТабл-В
/ 300
PROJECT: Ï ðî öåññû ðàçðàáîòêè ÏÎ ï î ISO/ IEC 122007
REV: :=
07.03.
2011
DR AFT
OMMEND ED
вернуть среднееТабл-А, REC
среднееТабл-В
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLIC ATION
Начало
Да
1) - М одуль
- е диничная
проблемно
-орие нтированная
функция
Да
Уровень
связанности: =
"Функциональный"
Не т
2) Де йствия
внутри
модуля
связаны
Не т
3) Де йствия
внутри модуля
связаны
данными
Да
4) Порядок
де йствий внутри
модуля важ ен
Не т, при этом
Не т
де йствия внутри
4) Уровень
модуля связаны
связности: =
потоком
"Коммуникативный"
управле ния
5) Порядок
де йствий внутри
модуля важ ен
Не т
6) Де йствия
внутри модуля
принадле ж ат к
одной
кате гории
Не т
Да
Да
Да
4) Уровень
связности:
= "Информационный"
5) Уровень связности: =
"Процедурный"
5) Уровень связности: =
"Вре менной"
6) Уровень связности:
= "Логический"
6) Уровень связности:
= "По совпадению"
Коне ц

146.

Модуль “Инициализировать Систему”:
- 1 - Перемотать магнитную ленту “№1”;
- 2 - Счетчик магнитной ленты “№1”:= 0;
- 3 - Перемотать магнитную ленту “№2”;
- 4 - Счетчик магнитной ленты “№2”:= 0;
- 5 - Таблица тек. записей: = пробел .. пробел;
- 6 - Таблица количества записей:= 0 .. 0;
SED AT:
DATE: 04.01. 2010
NG
- 7 - Переключатель
№1:WORKI
= “Выкл.”;
REV: 07.03. 2011
DR AFT
REC OMMEND
ED
- 8 - Переключатель №2:=
“Вкл.”
AUTHOR: Ê. Ý. Ï èñàðåí êî
READ ER
PROJECT: Ï ðî öåññû ðàçðàáîòêè ÏÎ ï î ISO/ IEC 122007
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLIC ATION
Начало
Да
1) - М одуль
- е диничная
проблемно
-орие нтированная
функция
Да
Уровень
связанности: =
"Функциональный"
Не т
2) Де йствия
внутри
модуля
связаны
Не т
3) Де йствия
внутри модуля
связаны
данными
Да
4) Порядок
де йствий внутри
модуля важ ен
Не т, при этом
Не т
де йствия внутри
4) Уровень
модуля связаны
связности: =
потоком
"Коммуникативный"
управле ния
5) Порядок
де йствий внутри
модуля важ ен
Не т
6) Де йствия
внутри модуля
принадле ж ат к
одной
кате гории
Не т
Да
Да
Да
4) Уровень
связности:
= "Информационный"
5) Уровень связности: =
"Процедурный"
5) Уровень связности: =
"Вре менной"
6) Уровень связности:
= "Логический"
6) Уровень связности:
= "По совпадению"
Коне ц

147.

Модуль “Пересылка сообщения”
- Переслать по электронной почте
- Переслать по факсу
- Послать в телеконференцию
SED AT:
- Переслать по ftp-протоколу
AUTHOR: Ê. Ý. Ï èñàðåí êî
PROJECT: Ï ðî öåññû ðàçðàáîòêè ÏÎ ï î ISO/ IEC 122007
DATE: 04.01. 2010
WORKI NG
REV:
DR AFT
07.03. 2011
READ ER
Конец модуля
REC OMMEND ED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLIC ATION
Начало
Да
1) - М одуль
- е диничная
проблемно
-орие нтированная
функция
Да
Уровень
связанности: =
"Функциональный"
Не т
2) Де йствия
внутри
модуля
связаны
Не т
3) Де йствия
внутри модуля
связаны
данными
Да
4) Порядок
де йствий внутри
модуля важ ен
Не т, при этом
Не т
де йствия внутри
4) Уровень
модуля связаны
связности: =
потоком
"Коммуникативный"
управле ния
5) Порядок
де йствий внутри
модуля важ ен
Не т
6) Де йствия
внутри модуля
принадле ж ат к
одной
кате гории
Не т
Да
Да
Да
4) Уровень
связности:
= "Информационный"
5) Уровень связности: =
"Процедурный"
5) Уровень связности: =
"Вре менной"
6) Уровень связности:
= "Логический"
6) Уровень связности:
= "По совпадению"
Коне ц

148.

SED AT:
AUTHOR: Ê. Ý. Ï èñàðåí êî
PROJECT: Ï ðî öåññû ðàçðàáîòêè ÏÎ ï î ISO/ IEC 122007
Модуль “Разные функции”
Поздравить с Новым годом (...)
Проверить исправность аппаратуры (...)
Заполнить анкету (...)
Измерить температуру (...)
Вывести собаку на прогулку (...)
Запастись продуктами (...)
Приобрести автомобиль (...)
Конец модуля
DATE: 04.01. 2010
WORKI NG
REV:
DR AFT
07.03. 2011
READ ER
REC OMMEND ED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLIC ATION
Начало
Да
1) - М одуль
- е диничная
проблемно
-орие нтированная
функция
Да
Уровень
связанности: =
"Функциональный"
Не т
2) Де йствия
внутри
модуля
связаны
Не т
3) Де йствия
внутри модуля
связаны
данными
Да
4) Порядок
де йствий внутри
модуля важ ен
Не т, при этом
Не т
де йствия внутри
4) Уровень
модуля связаны
связности: =
потоком
"Коммуникативный"
управле ния
5) Порядок
де йствий внутри
модуля важ ен
Не т
6) Де йствия
внутри модуля
принадле ж ат к
одной
кате гории
Не т
Да
Да
Да
4) Уровень
связности:
= "Информационный"
5) Уровень связности: =
"Процедурный"
5) Уровень связности: =
"Вре менной"
6) Уровень связности:
= "Логический"
6) Уровень связности:
= "По совпадению"
Коне ц

149.

122007
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
A 1.3.4.1.1
Критерии и примитивы качества ПС
Функциональность
Надежность
Завершенность
Завершенноcть
Точность
Автономность
Устойчивость
Защищенность
Легкость
применения
Эффективность
Сопровождаемость:
изучаемость и
модифицируемость
Мобильность
П-документированность
Временная
эффективность
С-документированность
Независимость
от устройств
Информативность
Эффективность
по ресурсам
Информативноcть
Автономноcть
Понятность
Коммуникабельность
Эффективность
по устройствам
Структурированность
Cтруктурированность
Устойчивоcть
Удобочитаемость
Защищенноcть
Расширяемость
Модульность
NODE:
TITLE:
A1.3.4.1.1.1
Êðèòåðèè è ïðèìèòèâû êà÷åñòâà ÏÑ
NUMBER:
Модульноcть

150.

Практическое задание
1 Опишите функции (действия) нескольких
программных модулей Вашего программного средства.
SED AT:
AUTHOR: Ê.Ý. Ïèñàðåíêî
DATE: 04.01.2010
WORKING
READ ER
DR AFT
2 Определите уровень их внутренней связанности.
PROJECT: Ïðîöåññû ðàçðàáîòêè ÏÎ ïî ISO/IEC 122007
REV: 07.03.2011
REC OMMEND ED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLIC ATION
Начало
Да
1) - Модуль
- е диничная
проблемно
-орие нтированная
функция
Да
Уровень
связанности: =
"Функциональный"
Не т
2) Де йствия
внутри
модуля
связаны
Не т
3) Де йствия
внутри модуля
связаны
данными
Да
4) Порядок
де йствий внутри
модуля важен
Не т, при этом
Не т
де йствия внутри
4) Уровень
модуля связаны
связности: =
потоком
"Коммуникативный"
управле ния
5) Порядок
де йствий внутри
модуля важен
Не т
6) Де йствия
внутри модуля
принадле жат к
одной
кате гории
Не т
Да
Да
Да
4) Уровень
связности:
= "Информационный"
5) Уровень связности: =
"Процедурный"
5) Уровень связности: =
"Вре менной"
6) Уровень связности:
= "Логический"
6) Уровень связности:
= "По совпадению"
Коне ц

151.

Виды сцеплений модулей программных средств
Сцепление по данным
Сцепление по образцу
Сцепление по общей области
Сцепление по содержанию
Сцепление по управлению

152.

НАИЛУЧШИЙ КОЭФИЦИЕНТ
СЦЕПЛЕНИЯ , СЦ=1
Сцепление по данным
Все входные и выходные
параметры вызываемого модуля
— простые элементы данных
(числа, текст и т.п.)

153.

КОЭФИЦИЕНТ СЦЕПЛЕНИЯ , СЦ=3
Сцепление по образцу
В качестве параметров
используются структуры данных
(массивы, матрицы, таблицы и т.п.
Недостаток заключается в том, что
конкретные передаваемые данные
“спрятаны” в структуры, и потому
уменьшается “прозрачность”
связи между модулями

154.

КОЭФИЦИЕНТ СЦЕПЛЕНИЯ , СЦ=4
Модуль А явно управляет
функционированием модуля В
посылая ему информационный
объект (флаг, переключатель) для
управления внутренней логикой
работы модуля
(ПЕРЕКЛЮЧАТЕЛЬ=0, тогда
выполнить один набор
вычислений, ЕСЛИ
ПЕРЕКЛЮЧАТЕЛЬ=1, тогда
выполнить другой набор
вычислений и т.п.)
Сцепление по управлению

155.

КОЭФИЦИЕНТ СЦЕПЛЕНИЯ , СЦ=5
A
B
Элемент данных
(текст, число и т.д.)
Сцепление по внешним ссылкам
Модули А и В ссылаются
на один и тот же глобальный
элемент данных

156.

КОЭФИЦИЕНТ СЦЕПЛЕНИЯ , СЦ=7
Сцепление по общей области
Модули разделяют одну и ту же
глобальную структуру данных
(массив, матрицу, таблицу и т.п.)

157.

КОЭФИЦИЕНТ СЦЕПЛЕНИЯ , СЦ=9
Сцепление по содержимому
Один модуль прямо ссылается
на содержание другого модуля
(из программного модуля идет ссылка
на необходимость выполнения действия описанного
в другом программном модуле и т.п.)

158.

Практическое задание
1 Нарисуйте схему взаимодействия программных модулей Вашего
программного средства.
2 Определите тип их сцепления.

159.

Рутинность модуля — это его независимость
от предыстории обращений к нему.
Модуль называется рутинным, если результат
обращения к нему зависит только от значений
его параметров и не зависит от результатов
предыдущих обращений к нему.

160.

Метод восходящей разработки
программного средства
Разработка модульной структуры программы в виде дерева
Программирование модулей программы,
начиная с модулей самого нижнего уровня
Поочередное тестирование и отладка модулей
в восходящем порядке – от нижнего уровня к высшему

161.

Метод нисходящей разработки
программного средства
Разработка модульной структуры программы в виде дерева
Программирование модулей программы,
начиная с модулей самого верхнего уровня
Поочередное тестирование и отладка модулей
в нисходящем порядке – от верхнего уровня к низшему

162.

Формирование модульной структуры программы
при конструктивном подходе
ШАГ 1 Формируется дерево верхнего уровня программы
и программируются его программные модули

163.

ШАГ 2 Формируются деревья (поддеревья) нижних уровней
программы и программируются их программные модули

164.

Классификация методов разработки
структуры программных модулей (программ)

165.

Технология разработки
программного обеспечения
РАЗРАБОТКА ПРОГРАММНОГО МОДУЛЯ
ЛЕКЦИЯ 6

166.

167.

Порядок разработки программного модуля
1 Изучение и проверка спецификации модуля,
выбор языка программирования
2 Выбор алгоритма и структуры данных
3 Программирование (кодирование) модуля
4 “Шлифовка” текста модуля
5 Проверка модуля
6 Компиляция модуля

168.

Основные управляющие конструкции
– структуры структурного программирования
Следование
где
S, S1, S2 - обобщенные
операторы - узлы
обработки;
Разветвление
S1
P – условие.
Да
P
S2
Повторение
S1
Да
S
Нет
P
Нет
S2

169.

Порядок пошаговой детализации программного кода
программного модуля
1 Описание общей схемы работы модуля
с использованием неформализованных терминов
2 Уточнение и детализация терминов,
до тех пор, пока каждый из них не будет описан
на базовом языке программирования
3 Получение текста модуля
на базовом языке программирования

170.

Головное описание программного модуля на псевдокоде
1 Начало модуля на базовом языке программирования
2 Внешнее описание процедур и функций
на базовом языке программирования
3 Неформальное описание последовательности
операторов, функций и процедур программного модуля
4 Конец модуля на базовом языке программирования

171.

Основные конструкции структурного программирования на псевдокоде
Следование:
Следование
обобщенный_оператор
обобщенный_оператор
Разветвление:
S1
Разветвление
S2
ЕСЛИ условие ТО
обобщенный_оператор
Да
ИНАЧЕ
обобщенный_оператор
S1
P
S2
ВСЕ ЕСЛИ
Повторение
Повторение:
ПОКА условие ДЕЛАТЬ
обобщенный_оператор
ВСЕ ПОКА
S
Да
P
Нет
Нет

172.

Частные случаи оператора перехода
в качестве обобщенного оператора
Выход из повторения (цикла):
ВЫЙТИ
Выход из процедуры (функции):
ВЕРНУТЬСЯ
Переход на обработку исключительной
ситуации:
ВОЗБУДИТЬ имя_исключения
ИСКЛЮЧЕНИЕ имя_исключения
обобщенный_оператор
ВСЕ ИСКЛЮЧЕНИЕ

173.

Пример одного шага детализации на псевдокоде
УДАЛЕНИЕ В ФАЙЛЕ ЗАПИСЕЙ ДО ПЕРВОЙ,
УДОВЛЕТВОРЯЮЩЕЙ ЗАДАННОМУ ФИЛЬТРУ:
УСТАНОВИТЬ НАЧАЛО ФАЙЛА.
ПОКА НЕ КОНЕЦ ФАЙЛА ДЕЛАТЬ
ПРОЧИТАТЬ ОЧЕРЕДНУЮ ЗАПИСЬ.
ЕСЛИ ОЧЕРЕДНАЯ ЗАПИСЬ УДОВЛЕТВОРЯЕТ ФИЛЬТРУ
ТО ВЫЙТИ
ИНАЧЕ
УДАЛИТЬ ОЧЕРЕДНУЮ ЗАПИСЬ ИЗ ФАЙЛА.
ВСЕ ЕСЛИ
ВСЕ ПОКА
ЕСЛИ ЗАПИСИ НЕ УДАЛЕНЫ ТО
НАПЕЧАТАТЬ "ЗАПИСИ НЕ УДАЛЕНЫ".
ИНАЧЕ
НАПЕЧАТАТЬ "УДАЛЕНО н ЗАПИСЕЙ".
ВСЕ ЕСЛИ

174.

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

175.

Технология разработки
программного обеспечения
ДОКАЗАТЕЛЬСТВО СВОЙСТВ ПРОГРАММ
ЛЕКЦИЯ 7

176.

177.

Концепция формального обоснования программы - Триада Хоора
{P} S {Q} - триада Хоора,
где предикаты
P – предусловие,
Q постусловие
выполнения оператора S.
Оператор S
обладает свойством {P} S {Q},
если перед его выполнением
истинен предикат P,
а после его выполнения
истинен предикат Q.
Примеры свойств
оператора S (программы)
{n=0} n:= n+1{n=1},
(9.1)
{n<m} n:= n + k {n<m+k},
(9.2)
{n<m+k} n:=3 n {n<3 (m + k)}, (9.3)
{n>0}
p:=1;
m:=1;
ПОКА m <> n ДЕЛАТЬ
m:=m+1;
p:=p m
ВСЕ ПОКА
{p= n!}.
(9.4)

178.

Свойства простых операторов
ТЕОРЕМА 9.1
Пусть P предикат – утверждение
над информационной средой,
тогда имеет место свойство {P}{P}.

179.

Свойства простых операторов
ТЕОРЕМА 9.2
Условие:
Переменная
IS без X
IS = (X, RIS)
Информационная
среда
Свойство, выполняемое при заданном условии:
{Q(F(X, RIS), RIS)} X:= F(X, RIS) {Q(X, RIS)},
где F(X, RIS) некоторая однозначная функция,
Q предикат.
Пример свойства:
{n=0} n:= n+1{n=1},
(9.1)

180.

Свойства конструкции “Следование” структурного программирования
ТЕОРЕМА 9.3
Условие:
Предикаты – утверждения
{P}S1{Q} и {Q}S2{R}
Следование
S1
S2
Операторы
Свойство, выполняемое при заданном условии:
{P} S1; S2 {R}
Пример:
поскольку выполняются свойства:
{n<m} n:= n + k {n<m+k},
(9.2)
{n<m+k} n:=3 n {n<3 (m + k)}, (9.3),
соответственно будет выполняться свойство:
{n<m} n:= n + k; n:= 3 n {n<3 (m + k)}

181.

Свойства конструкции “Разветвление” стр. программирования
ТЕОРЕМА 9.4
Разветвление
Да
Условие:
Предикаты – утверждения
S1
P
Нет
S2
{P,Q}S1{Q} и { P,Q}S2{R}
Операторы
Свойство, выполняемое при заданном условии для
условного оператора ЕСЛИ P ТО S1 ИНАЧЕ S2 ВСЕ ЕСЛИ :
{Q} ЕСЛИ P ТО S1 ИНАЧЕ S2 ВСЕ ЕСЛИ {R}.

182.

Свойства конструкции “Разветвление” стр. программирования
ТЕОРЕМА 9.5
Разветвление
Да
Условие:
Предикаты – утверждения
S1
{P}S{Q}, P1 P, Q Q1
Оператор
Свойство, выполняемое при заданном условии:
{P1}S{Q1}.
P
Нет
S2

183.

Свойства конструкции “Повторение” структурного программирования
Повторение
ТЕОРЕМА 9.6
Условие:
Предикаты – утверждения
S
{I}S{I}, P I, (I, Q ) R
Да
Оператор
Свойство, выполняемое при заданном условии
для оператора цикла:
{P} ПОКА Q ДЕЛАТЬ S ВСЕ ПОКА {R}.
Пример:
{n>0; p:=1; m:=1}
ПОКА m <> n ДЕЛАТЬ
m:=m+1; p:=p m
ВСЕ ПОКА
{p= n!}.
(9.4)
P
Нет

184.

Завершимость выполнения программы
Условие:
ТЕОРЕМА 9.7
F целочисленная функция,
зависящая от состояния информационной среды
и удовлетворяющая следующим условиям:
– 1 – если для данного состояния информационной среды
истинен предикат Q, то ее значение положительно;
– 2 – она убывает при изменении состояния информационной среды
в результате выполнения оператора S.
Свойство, выполняемое при заданных условиях:
выполнение оператора цикла
ПОКА Q ДЕЛАТЬ S ВСЕ ПОКА завершается.
Пример:
{m:=1}
ПОКА n – m > 0 ДЕЛАТЬ
f: = n m;
ВСЕ ПОКА
{n:=0}

185.

Пример доказательство свойства программы
Программа:
{n>0; p:=1; m:=1}
ПОКА m <> n ДЕЛАТЬ
m:=m+1; p:=p m
(9.4)
ВСЕ ПОКА
{p= n!}.
Шаг 1). n>0 (n>0, p любое, m любое).
(Шаг 2). По теореме 9.2 выполняется следующее
свойство
{n>0, p любое, m любое} p:=1 {n>0, p=1, m
любое}.
(Шаг 3). По теореме 9.2 верно следующее свойство
{n>0, p=1, m любое} m:=1 {n>0, p=1, m=1}.

186.

Пример доказательство свойства программы
Программа:
{n>0; p:=1; m:=1}
ПОКА m <> n ДЕЛАТЬ
m:=m+1; p:=p m
(9.4)
ВСЕ ПОКА
{p= n!}.
(Шаг 4). По теореме 9.3 в силу результатов шагов 2 и 3
выполняется следующее свойство
{n>0, p любое, m любое} p:=1; m:=1 {n>0, p=1, m=1}.
Необходимо доказать, что предикат p= m!
является инвариантом цикла,
т.е. {p=m!} m:=m+1; p:=p m {p=m!}.

187.

Пример доказательство свойства программы
(Шаг 5). По теореме 9.2 выполняется следующее свойство
{p= m!} m:= m+1 {p= (m 1)!},
при этом предусловие представляется
в виде {p= ((m+1) 1)!}.
(Шаг 6). По теореме 9.2 выполняется следующее свойство
{p= (m 1)!} p:= p m {p= m!},
при этом предусловие представляется
в виде {p m= m!}.
(Шаг 7). По теореме 9.2, в силу результатов шагов 5 и 6
выполняется следующее свойство
{p= m!} m:= m+1; p:= p m {p= m!}.

188.

Пример доказательство свойства программы
(Шаг 8). По теореме 9.6 в силу результата шага 7
выполняется следующее свойство
{n>0, p=1, m=1}
ПОКА m <> n ДЕЛАТЬ
m:= m+1; p:= p m
ВСЕ ПОКА {p= n!},
при этом учитывается, что
(n>0, p=1, m= 1) p= m!; (p= m!, m= n) p= n!.

189.

Пример доказательство свойства программы
(Шаг 9). По теореме 9.3 в силу результатов шагов 3 и 8
выполняется следующее свойство
{n>0, p любое, m любое}
p:=1; m:=1;
ПОКА m <> n ДЕЛАТЬ
m:= m+1; p:= p m
ВСЕ ПОКА {p= n!}.
(Шаг 10). По теореме 9.5 в силу результатов шагов 1 и 9
выполняется свойство (9.4)

190.

Технология разработки
программного обеспечения
ТЕСТИРОВАНИЕ И ОТЛАДКА
ПРОГРАММНОГО СРЕДСТВА
ЛЕКЦИЯ 8

191.

192.

Состав задач тестирования ПС
согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
Уточнение
Разработка
Уточнение
Тестирование
документации требований к
процедуры
каждого
испытаний
программного пользователя тестированию
(при
(тестирования) модуля и базы
необходимости)
и данных для
данных
тестирования
каждого
Оценка программных модулей и результатов их
программного
тестирования по следующим критериям:
модуля и базы
a) учет требований к программному модулю и проекту объекта
данных
в целом;
b) внешнее соответствие требованиям и проекту
программного модуля;
c) внутреннее соответствие между требованиями к
программным модулям;
d) тестовое покрытие всех модулей;
e) соответствие методов программирования и используемых
для них стандартов;
f) возможность сборки и тестирования;
g) возможность эксплуатации и сопровождения.

193.

Основные определения тестирования и отладки ПС
Тестирование
также
является частью
аттестации ПС
Отладка =
Выполняется в случае,
несовпадения результатов
тестирования с ожидаемыми
результатами
Тестирование + Поиск ошибок + Редактирование
Проверка
и устранение
несоответствий
Проверка соответствия
полученных результатов
работы ПС ожидаемым
Устранение
выявленных
ошибок

194.

Основные определения тестирования и отладки ПС
Тестирование всегда выполняется
с помощью некоторого набора данных,
который называется тестовым или тестом
При этом …
Хорошим считают тест
с высокой вероятностью
обнаружения еще
не раскрытой ошибки
Успешным называют тест,
который обнаруживает
до сих пор не раскрытую
ошибку

195.

Основные определения тестирования и отладки ПС
ВАЖНО ПОМНИТЬ!
Тестирование не может показать
отсутствия дефектов
- оно может показывать только
присутствие дефектов
Следовательно …
1 Если тесты не обнаруживают ошибок, необходимо проверить
достаточно ли продуманы тесты и что в ПО нет скрытых ошибок
2 Ошибки не выявленные с помощью тестов будут обнаруживаться
на стадии эксплуатации ПО, когда стоимость их устранения возрастет
в 60 – 100 раз

196.

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

197.

Виды тестирования ПО

198.

Принципы и виды отладки программного обеспечения
Успех отладки ПС в значительной степени
предопределяет рациональная организация тестирования
Для рациональной организации отладки ПО
необходимо решить следующие задачи …
1 Подготовить такой набор
тестов, чтобы обнаружить
в ПС по возможности
большее число ошибок.
2 Определить момент
окончания отладки
ПС (или отдельной
его компоненты)
Для оптимизации набора тестов
необходимо
1 Заранее планировать этот набор
2 Использовать рациональную стратегию
планирования (проектирования) тестов

199.

Принципы и виды отладки программного обеспечения
Успех отладки ПС в значительной степени
предопределяет рациональная организация тестирования
Для рациональной организации отладки ПО
необходимо решить следующие задачи …
1 Подготовить такой набор
тестов, чтобы обнаружить
1 Полнота охвата выполненными
в ПС по возможности
Признаки тестами множества различных
большее число ошибок. окончания ситуаций, возникающих
при выполнении ПС
отладки
2 Определить момент
окончания отладки
ПС (или отдельной
его компоненты)
2 Относительно редкое проявление
ошибок в ПС на последнем отрезке
процесса тестирования
При этом, важно помнить!
Чем дольше продолжается процесс тестирования
(и отладки в целом), тем большей становится стоимость ПС.

200.

Планировать набор тестов
можно после получения
требований к ПС,
уточняя его на каждой
стадии жизненного
цикла ПС
Выбор оптимальной
стратегии находится между
двумя крайними подходами
Подходы к тестированию программных средств и выбор
оптимальной стратегии тестирования
Тестирование
“Черного ящика”
Тестирование
по отношению
к спецификациям
Тестирование
“Белого ящика”
Тестирование
по отношению
к текстам программ
Оптимальная
стратегия
Хотя бы один тест на каждую:
- используемую функцию;
- область и границу изменения
какой-либо входной величины;
- особую (исключительную) ситуацию.
Хотя бы один тест на каждую
команду в каждом
программном модуле ПС.

201.

Тесты проектируются
Выбор оптимальной стратегии находится
и выбор
только на основании Подходы к тестированию программных средств
между двумя крайними подходами
оптимальной стратегии тестирования
изучения
Тестирование
Тестирование
спецификации
“Черного ящика”
“Белого ящика”
ПС. Строение модулей
Тесты проектируются
Тестирование
Тестирование
при этом никак
на основании изучения
по отношению
по отношению
не учитывается,
к текстам программ
текстов программ
к спецификациям
т.е. они
с целью протестировать
рассматриваются
все пути выполнения
Оптимальная
как "Черные ящики"
каждой программ ПС.
стратегия
Хотя бы один тест на каждую:
- используемую функцию;
- область и границу изменения
какой-либо входной величины;
- особую (исключительную) ситуацию.
Хотя бы один тест на каждую
команду в каждом
программном модуле ПС.
Оптимальная стратегия тестирования
расположена внутри интервала между крайними
Т.е. программные
модули
рассматриваются,
как "Белые ящики".

202.

Тестирование
“Черного ящика”
Тестирование
по отношению
к спецификациям
Тестирование
“Белого ящика”
Тестирование
по отношению
к текстам программ
Оптимальная
стратегия
Хотя бы один тест на каждую:
- используемую функцию;
- область и границу изменения
какой-либо входной величины;
- особую (исключительную) ситуацию.
Хотя бы один тест на каждую
команду в каждом
программном модуле ПС.
Тесты проектируются на основании
Тесты проектируются только
Оптимальная стратегия тестирования
изучения текстов программ
расположена внутри
на основании изучения спецификации
ПС.интервала между крайними
целью протестировать все пути
подходами, но ближе к левомус краю!
Строение модулей при этом никак не
выполнения каждой программ ПС.
учитывается, т.е. они рассматриваются
Т.е. программные модули
как "Черные ящики"
рассматриваются, как "Белые ящики".
Подход требует
Полного перебора
всех наборов входных данных,
так как в противном случае
некоторые участки программ ПС
могут не работать при пропуске
любого теста, а это значит,
что содержащиеся в них ошибки
не будут проявляться. Такое
тестирование практически
неосуществимо
При этом
Если принять во внимание наличие
в программах циклов с переменным
числом повторений, то различных
путей выполнения программ ПС
может оказаться также чрезвычайно
много, так что их тестирование
будет практически неосуществимо

203.

Тестирование ПС по отношению к спецификациям
– тестирование “Черного ящика”
Тестирование
по отношению
к спецификациям
Тестирование
по отношению
к текстам программ
Оптимальная
стратегия
1 Известны: функции программы.
2 Исследуется: работа каждой функции
на всей области определения.
При тестировании "Черного ящика" рассматриваются системные
характеристики программ, игнорируется их внутренняя логическая структура.
Полное или исчерпывающее тестирование, как правило, невозможно.
Например, если в программе 10 входных величин и каждая принимает
по 10 значений, то потребуется 10^10 тестовых вариантов.

204.

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

205.

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

206.

Подходы к тестированию программных средств и выбор
оптимальной стратегии тестирования
Тестирование
“Черного ящика”
Тестирование
по отношению
к спецификациям
Тестирование
“Белого ящика”
Тестирование
по отношению
к текстам программ
Оптимальная
стратегия
Хотя бы один тест на каждую:
- используемую функцию;
- область и границу изменения
какой-либо входной величины;
- особую (исключительную) ситуацию.
Хотя бы один тест на каждую
команду в каждом
программном модуле ПС.
Оптимальная стратегия тестирования
расположена внутри интервала между крайними
подходами, но ближе к левому краю!

207.

Подходы к тестированию программных средств и выбор
оптимальной стратегии тестирования
Оптимальную стратегию проектирования тестов
можно конкретизировать на основании следующего принципа:
– для каждого программного документа (включая тексты программ),
входящего в состав ПС, должны проектироваться свои тесты
с целью выявления в них ошибок
1 Результаты каждой стадии разработки ПО
отражаются в соответствующих документах
2 Набор и содержание тестов дополняется
и уточняется на каждой стадии разработки ПО

208.

Феномен роста вероятности существования ошибок в ПС
По мере роста числа обнаруженных
и исправленных ошибок в ПС
растет также вероятность
существования в нем
необнаруженных ошибок.

209.

Заповеди по организации отладки программного средства
Заповедь 1. Считайте тестирование ключевой задачей разработки ПС,
поручайте его самым квалифицированным и одаренным программистам;
нежелательно тестировать свою собственную программу.
Заповедь 2. Хорош тот тест, для которого высока вероятность
обнаружить ошибку, а не тот, который демонстрирует
правильную работу программы.
Заповедь 3. Готовьте тесты как для правильных,
так и для неправильных данных.
Заповедь 4. Документируйте пропуск тестов через компьютер;
детально изучайте результаты каждого теста; избегайте тестов,
пропуск которых нельзя повторить.
Заповедь 5. Каждый модуль подключайте к программе только один раз;
никогда не изменяйте программу, чтобы облегчить ее тестирование.
Заповедь 6. Пропускайте заново все тесты, связанные с проверкой
работы какой-либо программы ПС или ее взаимодействия с другими
программами, если в нее были внесены изменения
(например, в результате устранения ошибки).

210.

Практическое задание
1 Опишите графически оптимальную стратегию
тестирования Вашего программного средства.
2 Напишите комментарии к графику, поясняющие Ваш выбор.
Тестирование
“Черного ящика”
Тестирование
по отношению
к спецификациям
Тесты проектируются только
на основании изучения спецификации ПС.
Строение модулей при этом никак не
учитывается, т.е. они рассматриваются
как "Черные ящики"
Подход требует
Полного перебора всех наборов входных
данных, так как в противном случае некоторые
участки программ ПС могут не работать при
пропуске любого теста, а это значит, что
содержащиеся в них ошибки не будут
проявляться.
Тестирование
по отношению
к текстам программ
Тестирование
“Белого ящика”
Тесты проектируются на основании
изучения текстов программ
с целью протестировать все пути
выполнения каждой программ ПС.
Т.е. программные модули
рассматриваются, как "Белые ящики".
При этом
Если принять во внимание наличие
в программах циклов с переменным
числом повторений, то различных
путей выполнения программ ПС
может оказаться чрезвычайно
много.

211.

Виды отладки программного средства
Автономная отладка
Комплексная отладка
Отладка каждого программного модуля
и его окружения (сопряженных модулей)
Один отладочный
модуль – головной
в тестируемой программе
Восходящее тестирование
Тестирование
ПС в целом
Множество отладочных
модулей – отладочных
имитаторов (заглушек)
Нисходящее тестирование

212.

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

213.

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

214.

Очередность
тестирования
модулей
4
3
2
1
Вызывает
подчиненный
модуль
Посылает
элемент данных
(параметр)
из внутренней
таблицы
Отображает
параметр из
подчиненного
модуля
Является
комбинацией
драйверов
ВиС

215.

Отлаживаемый
модуль
Очередность
тестирования
модулей
1
2
Отладочные имитаторы
(заглушки) – имитируют
работу неотлаженных
модулей
3
4
Отображает
трассируемое
сообщение
Отображает
проходящий
параметр
Возвращает
величину
из таблицы
Выполняет табличный
поиск по ключу
(входному параметру)
и возвращает связанный
с ним выходной параметр

216.

На практике часто
применяется
смешанная форма
отладки ПС
Достоинства:
– простота подготовки тестов;
– можно составить полный план
тестирования перед его началом.
Недостатками:
– тестовые данные готовятся,
как правило, в форме,
непонятной пользователю;
– большой объем отладочного
программирования;
– необходимость специального
тестирования сопряжения модулей.
Достоинства:
– большинство тестов готовится
в форме, рассчитанной на
пользователя;
– во многих случаях относительно
небольшой объем отладочного
программирования;
– отпадает необходимость тестирования
сопряжения модулей.
Недостатки:
– невозможность или сильное
затруднение подготовки полного плана
перед началом тестирования.

217.

Этапы автономного тестирования
– Шаг 1 – На основании спецификации отлаживаемого
модуля, подготовка тестов для каждой:
а) возможной ситуации,
б) границы областей допустимых значений всех входных
данных,
в) областей изменения данных, недопустимых значений
всех входных данных и каждого недопустимого условия.
Тестирование
“черного ящика”
– Шаг 2 – Проверка текста модуля, с целью убедиться,
что каждое направление любого разветвления будет
пройдено хотя бы на одном тесте. Добавление недостающих тестов.
– Шаг 3 – Проверка текста модуля, с целью убедиться,
что для каждого цикла – повторения, существуют тесты,
обеспечивающие, по крайней мере, три следующие ситуации:
а) тело цикла не выполняется ни разу;
Тестирование
б) тело цикла выполняется один раз
“белого ящика”
в) тело цикла выполняется максимальное число раз.
Добавление недостающих тестов.
– Шаг 4 – Проверка текста модуля, с целью убедиться,
что существуют тесты, проверяющие чувствительность
к отдельным особым значениям входных данных.
Добавление недостающих тестов.
Тестирование
“черного ящика”

218.

1
2
3
4
5
1
2
3
4
5
Поиск несоответствий между описанием архитектуры, структурой
и взаимодействием программных модулей и подсистем ПС.
Поиск расхождений между функциональной спецификацией
и функциями программных модулей и подсистем ПС
Поиск нарушений требований качества,
сформулированных в спецификации качества ПС
Поиск несоответствий документации заданным требованиям,
ее несогласованности с содержанием и функциями ПО
Поиск несоответствий ПО установленным
требованиям самим заказчиком

219.

СРЕДСТВА АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
HP QTP
AutomatedQA TestComplete
Rational Functional Tester
Borland SilkTest
Microsoft VS
Selenium
Watir
Canoo WebTest
Jemmy
TestPartner
Worksoft Certify
и др.

220.

Технология разработки
программного обеспечения
ОБЕСПЕЧЕНИЕ КАЧЕСТВА
ПРОГРАММНОГО СРЕДСТВА
ЛЕКЦИИ 9 - 10

221.

222.

Критерии и примитивы качества ПС согласно МС ISO/IEC 9126
SED AT:
A UTHOR: Ê.Ý . Ïèñàðåíêî
DA TE: 27.12.2009
WORKING
PROJECT: Ïðîöåññû ðàçðàáîòêè ÏÎ ïî ISO/IEC
122007
REV :
DRAFT
27.12.2009
REA DER
DA TE CONTEXT:
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
A 1.3.4.1.1
Критерии и примитивы качества ПС
Функциональность
Надежность
Завершенность
Завершенноcть
Точность
Автономность
Устойчивость
Защищенность
Легкость
применения
Эффективность
Сопровождаемость:
изучаемость и
модифицируемость
Мобильность
П-документированность
Временная
эффективность
С-документированность
Независимость
от устройств
Информативность
Эффективность
по ресурсам
Информативноcть
Автономноcть
Понятность
Коммуникабельность
Эффективность
по устройствам
Структурированность
Cтруктурированность
Устойчивоcть
Удобочитаемость
Защищенноcть
Расширяемость
Модульность
ODE:
TITLE:
A1.3.4.1.1.1
Êðèòåðèè è ïðèìèòèâû êà÷åñòâà ÏÑ
NUMBER:
Модульноcть

223.

Международные стандарты в области управления качеством
КАЧЕСТВО ПРОЦЕССОВ УПРАВЛЕНИЯ:
- МС “ISO 9001:2008 (2000). Системы менеджмента качества. Требования”;
- МС “ISO/IEC 90003-2004. Руководство по применению стандарта
ISO 9001:2000 для программных средств”;
-МС “ISO/IEC 90005-2008. Руководство по применению стандарта
ISO 9001:2000 к процессам жизненного цикла программных средств”;
- МС “ISO/IEС 20000-1:2005. ИТ. Сервис менеджмент. Спецификация”
(предоставление ИТ услуг)”;
- стандарт “Корпоративное управление ИТ” (COBIT) международной
Ассоциации аудита и контроля информационных систем (ISACA).
КАЧЕСТВО ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА:
- МС “ISO 12207:95 (2008). Процессы жизненного цикла ПО”;
- МС “ISO/IEC 15288:2008 . Процессы жизненного цикла систем”;
- МС “ISO/IEC 15504:2004. Оценка процессов.
КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ:
- МС “ISO/IEC 9126 . Оценка программного продукта.
Характеристики качества и руководство по их применению”;
-МС “ISO/IEC 25051:2006. Требования для качества готового коммерческого
программного продукта и инструкция для испытаний”;
- МС “ISO/IEC 14598. Оценка программного продукта”.

224.

Модель классического жизненного цикла программного обеспечения

225.

226.

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

227.

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

228.

Критерии и примитивы качества ПС
Функциональность
Надежность
Завершенность
Завершенноcть
Точность
Автономность
Устойчивость
Защищенность
Легкость
применения
Эффективность
Сопровождаемость:
изучаемость и
модифицируемость
Мобильность
П-документированность
Временная
эффективность
С-документированность
Независимость
от устройств
Информативность
Эффективность
по ресурсам
Информативноcть
Автономноcть
Понятность
Коммуникабельность
Эффективность
по устройствам
Структурированность
Cтруктурированность
Устойчивоcть
Удобочитаемость
Защищенноcть
Расширяемость
Модульноcть
Модульность
П-документированность - свойство, характеризующее наличие, полноту,
понятность, доступность и наглядность учебной, инструктивной и справочной
документации, необходимой для применения ПС.
Информативность - свойство, характеризующее наличие в составе ПС
информации, необходимой
и достаточной
понимания
назначения
ПС,
ODE:
TITLE:
NUMBER:
Êðèòåðèè
è ïðèìèòèâûдля
êà÷åñòâà
ÏÑ
принятых
предположений, существующих ограничений, входных данных
A1.3.4.1.1.1
и результатов работы отдельных компонент, а также текущего состояния программ
в процессе их функционирования.
Коммуникабельность - свойство, характеризующее степень, в которой ПС
облегчает задание или описание входных данных, и способность выдавать
полезные сведения в достаточно простой форме и с простым для понимания
содержанием;

229.

230.

Принципы обеспечения эффективности программного средства
1 Разработать надежное ПС
с точки зрения требуемой эффективности ПС
2 Довести эффективность ПС до требуемого
спецификацией качества уровня
3 Если эффективность ПС не удовлетворяет
спецификации качества, то найти самые
критические модули (устройства) и оптимизировать
их в первую очередь
Не следует заниматься оптимизацией
модуля, если этого не требуется для
достижения требуемой эффективности ПС!

231.

Критерии и примитивы качества ПС
Функциональность
Надежность
Завершенность
Завершенноcть
Точность
Автономность
Устойчивость
Защищенность
Легкость
применения
Эффективность
Сопровождаемость:
изучаемость и
модифицируемость
Мобильность
П-документированность
Временная
эффективность
С-документированность
Независимость
от устройств
Информативность
Эффективность
по ресурсам
Информативноcть
Автономноcть
Понятность
Коммуникабельность
Эффективность
по устройствам
Структурированность
Cтруктурированность
Устойчивоcть
Удобочитаемость
Защищенноcть
Расширяемость
Модульноcть
Модульность
С-документировапнность - свойство, характеризующее с точки зрения наличия документации, отражающей
требования к ПС и результаты различных этапов разработки данной ПС, включающие возможности,
ограничения и другие черты ПС, а также их обоснование.
Понятность - свойство, характеризующее степень, в которой ПС позволяет изучающему его лицу понять его
назначение, сделанные допущения и ограничения, входные данные и результаты работы его программ,
тексты этих программ и состояние их реализации.
ODE:
TITLE:
NUMBER:
Êðèòåðèè
è ïðèìèòèâû
êà÷åñòâàПС
ÏÑ с точки зрения
Структурированность
- свойство,
характеризующее
программы
организации
A1.3.4.1.1.1
взаимосвязанных
их частей в единое целое определенным образом.
Удобочитаемость - свойство, характеризующее легкость восприятия текста программ ПС.
Расширяемость - свойство, характеризующее способность ПС к использованию большего объема памяти
для хранения данных или расширению функциональных возможностей отдельных компонент.
Модифицируемость - мера, характеризующая ПС с точки зрения простоты внесения необходимых
изменений и доработок на всех этапах и стадиях жизненного цикла ПС.
Модульность - свойство, характеризующее ПС с точки зрения организации его программ из таких
дискретных компонент, что изменение одной из них оказывает минимальное воздействие на другие
компоненты.

232.

233.

Подход к управлению качеством программного обеспечения
Технология структурирования
Технология разработки ПО
функций качества, универсальная
Этап 1. Разработка спецификации
для всех отраслей экономики
качества ПС, включая
критерии и примитивы (показатели)
качества основанные
на требованиях заказчика ПС
Этап 1. Разработка показателей
и критериев качества продукции
и услуг на основе требования
потребителей
Этап 2. Разработка спецификаций
качества программных модулей
(подсистем) ПС, включая
критерии и примитивы
их качества, основанных
на спецификации ПС в целом
Этап 2. Разработка показателей
и критериев качества компонентов
продукции и услуг на основе
показателей и критериев качества
продукции и услуг в целом
Этап 3. Выбор модели процессов
разработки (жизненного цикла)
ПС, включая показатели
и критерии их качества процессов
Этап 3. Разработка показателей
и критериев качества процессов
жизненного цикла продукции и услуг,
обеспечения их ресурсами и управления
Этап 4. Создание проекта
разработки ПС
- процессов разработки ПС
Этап 4. Разработка процессов
жизненного цикла продукции и услуг,
обеспечения их ресурсами и управления

234.

Практическое задание
1 Выпишите в порядке приоритетности критерии качества
которым должно удовлетворять Ваше программное средство.
SED AT:
2 Напротив каждого критерия, дайте комментарии поясняющие
A UTHOR:Ваш
Ê.Ý . Ïèñàðåíêî
DA TE: 27.12.2009
WORKING
REA DER
DA TE CONTEXT:
выбор уровня приоритетности.
PROJECT: Ïðîöåññû ðàçðàáîòêè ÏÎ ïî ISO/IEC
122007
REV :
27.12.2009
DRAFT
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
A 1.3.4.1.1
Критерии и примитивы качества ПС
Функциональность
Надежность
Завершенность
Завершенноcть
Точность
Автономность
Устойчивость
Защищенность
Легкость
применения
Эффективность
Сопровождаемость:
изучаемость и
модифицируемость
Мобильность
П-документированность
Временная
эффективность
С-документированность
Независимость
от устройств
Информативность
Эффективность
по ресурсам
Информативноcть
Автономноcть
Понятность
Коммуникабельность
Эффективность
по устройствам
Структурированность
Cтруктурированность
Устойчивоcть
Удобочитаемость
Защищенноcть
Расширяемость
Модульность
Модульноcть

235.

Технология разработки
программного обеспечения
ДОКУМЕНТИРОВАНИЕ
ПРОГРАММНЫХ СРЕДСТВ
ЛЕКЦИЯ 11

236.

Процессы жизненного цикла ПО, обеспечения ресурсами
и управления по МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)

237.

238.

Назначение документации программного средства
Отчет по системному
анализу: модели “как есть”
и “как должно быть”
1 Концепция ПС
2 Тестовые наборы
1 Архитектура ПС
2 Модели ПС
Текст программы
Отчеты по
тестированию

239.

Модели – документы создаваемые на разных стадиях
унифицированного процесса разработки (RUP) ПО

240.

Документация программного средства
Управления разработкой ПС
Пользовательская
1 Планы, оценки,
расписания
2 Отчеты
об использовании
ресурсов в процессе
разработки
3 Стандарты
4 Рабочие
документы
5 Заметки и
переписка
1 Общее
функциональное
описание ПС
2 Руководство
по инсталляции
ПС
3 Инструкция
по применению ПС
4 Справочник
по применению ПС
руководство
по управлению ПС
Входящая в состав ПС
Сопровождающая
1 Внешнее описание ПС
2 Описание
архитектуры ПС
3 Описание структуры
программных модулей
4 Модели программного ПС
(функциональные, объектные,
информационные и т.п.)
5 Тексты программных
модулей
6 Документы установления
достоверности ПС
7 Руководство
по сопровождению ПС

241.

Критерии и примитивы качества ПС
Функциональность
Надежность
Завершенность
Завершенноcть
Точность
Автономность
Устойчивость
Защищенность
Легкость
применения
Эффективность
Сопровождаемость:
изучаемость и
модифицируемость
Мобильность
П-документированность
Временная
эффективность
С-документированность
Независимость
от устройств
Информативность
Эффективность
по ресурсам
Информативноcть
Автономноcть
Понятность
Коммуникабельность
Эффективность
по устройствам
Структурированность
Cтруктурированность
Устойчивоcть
Удобочитаемость
Защищенноcть
Расширяемость
Модульноcть
Модульность
П-документированность - свойство, характеризующее наличие, полноту, понятность, доступность и
наглядность учебной, инструктивной и справочной документации, необходимой для применения ПС.
Информативность - свойство, характеризующее наличие в составе ПС информации, необходимой и
достаточной для понимания назначения ПС, принятых предположений, существующих ограничений, входных
данных и результатов работы отдельных компонент, а также текущего состояния программ в процессе их
функционирования.
ODE:
TITLE:
NUMBER:
Êðèòåðèè
è ïðèìèòèâû
êà÷åñòâà
ÏÑ
Коммуникабельность - свойство,
характеризующее
степень,
в которой
ПС облегчает задание или описание
A1.3.4.1.1.1
входных
данных, и способность выдавать полезные сведения в достаточно простой форме и с простым для
понимания содержанием.
Понятность - свойство, характеризующее степень, в которой ПС позволяет изучающему его лицу понять его
назначение, сделанные допущения и ограничения, входные данные и результаты работы его программ,
тексты этих программ и состояние их реализации.
Удобочитаемость - свойство, характеризующее легкость восприятия текста программ ПС.
С-документировапнность - свойство, характеризующее с точки зрения наличия документации, отражающей
требования к ПС и результаты различных этапов разработки данной ПС, включающие возможности,
ограничения и другие черты ПС, а также их обоснование.

242.

Процесс “Менеджмент документации ПС” согласно
МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
7.2.1.1 Цель
Цель процесса менеджмента документации
программных средств заключается
в разработке и сопровождении
зарегистрированной информации
по программным средствам, созданной
некоторым процессом.

243.

Состав работ процесса “Менеджмент документации ПС”
согласно МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
1 ПОДГОТОВКА ПРОЦЕССА
2 ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА
3 ВЫПУСК (ПРОИЗВОДСТВО)
4 СОПРОВОЖДЕНИЕ

244.

Состав работ процесса “Менеджмент документации ПС”
согласно МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
1 ПОДГОТОВКА ПРОЦЕССА
Для каждого издаваемого
документа должны быть определены:
a) заголовок или наименование;
b) назначение;
c) пользователи документа;
d) процедуры и обязанности по подготовке исходных материалов,
разработке, проверке, изменению, утверждению, выпуску, хранению,
распространению, сопровождению и управлению конфигурацией;
e) сроки выпуска промежуточных и окончательных редакций.

245.

Состав работ процесса “Менеджмент документации ПС”
согласно МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
2 ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА
2.1 Каждый конкретный документ должен быть
спроектирован в соответствии с используемыми
стандартами на документацию, в части
а) формата;
б) состава и содержания разделов;
в) нумерации страниц;
г) расположения и оформления рисунков и таблиц;
д) отметок об авторских правах, правах доступа;
е) брошюровки и других элементов представления информации.
2.2 Должны быть подтверждены источник
и соответствие исходных материалов для документов
2.3 Подготовленные документы должны быть проверены
и отредактированы в соответствии с используемыми
стандартами на документацию.

246.

Состав работ процесса “Менеджмент документации ПС”
согласно МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
3 ВЫПУСК (ПРОИЗВОДСТВО)
3.1 Документы должны быть изданы и распространены
в соответствии с планом издания
3.2 Средства управления документированием
должны быть определены в соответствии
с процессом управления конфигурацией ПС

247.

Базовые стандарты в области документирования ПС
– ISO/IEC/IEEE 26511:2011. Разработка программного
обеспечения и проектирование систем. Требования
к менеджерам по документации пользователя.
– ГОСТ Р ИСО/МЭК ТО 9294-93. Руководство по управлению
документированием программного обеспечения
(аутентичен ISO/IEC ТR 9294-90. Действующий
международный стандарт ISO/IEC 9294-2005).
– ГОСТ 19.001-77 – единая система программной документации.
– ГОСТ 19.101-77 – виды программ и программных документов.
– ГОСТ 19.102-77 – стадии разработки программ и программной
документации.
– ГОСТ 19.105-78 – требования к оформлению программных
документов, комплексов и систем независимо от их назначения и
области применения. (содержит полный перечень документации,
которая должна сопровождать законченный программный
продукт).

248.

Национальные стандарты
в области документирования ПС
ГОСТ Р ИСО/МЭК 15910-2002. Процесс создания документации пользователя
программного средства.
ГОСТ 19.201-78 – порядок построения и оформления технического
задания на разработку программы или программного изделия.
ГОСТ 19.202-78 – форма и порядок составления спецификации
на программные продукты, определяемые в ГОСТ 19.101-77.
ГОСТ 19.301-79 – программа и методика испытаний
программных продуктов.
ГОСТ 19.401-78 – порядок построения и оформления текста программы
при разработке программных продуктов.
ГОСТ 19.402-78 – описание программы.
ГОСТ 19.403-79 – форма заполнения и содержание ведомости
держателей подлинников, определяемой в ГОСТ 19.105-78.
ГОСТ 19.404-79 – форма заполнения и содержание пояснительной
записки, определяемой в ГОСТ 19.105-78.
ГОСТ 19.501-78 – форма заполнения и содержание формуляра
на программный продукт, определяемый в ГОСТ 19.105-78.

249.

Национальные стандарты
в области документирования ПС
ГОСТ 19.502-78 – форма заполнения и содержание описания
применения, определяемого в ГОСТ 19.105-78.
ГОСТ 19.503-79 – форма заполнения и содержание руководства
системного программиста, определяемого в ГОСТ 19.105-78.
ГОСТ 19.504-79 – форма заполнения и содержание руководства
программиста, определяемого в ГОСТ 19.105-78.
ГОСТ 19.505-79 – форма заполнения и содержание руководства
оператора, определяемого в ГОСТ 19.105-78.
ГОСТ 19.506-79 – форма заполнения и содержание описания языка,
определяемого в ГОСТ 19.105-78.
ГОСТ 19.507-79 – форма заполнения и содержание ведомости
эксплуатационных документов, определяемой в ГОСТ 19.105-78.
ГОСТ 19.508-79 – форма заполнения и содержание руководства
по техническому обслуживанию, определяемому в ГОСТ 19.105-78.
ГОСТ 19.701-90 – схемы алгоритмов, программ, данных и систем.

250.

Содержание ISO/IEC ТО 9294-90. Руководство по управлению
документированием программного обеспечения (ГОСТ Р ИСО/МЭК ТО 9294-93)
4. Роль руководителей
5. Функции программной документации
5.1. Информация для управления
5.2. Связь между задачами
5.3. Обеспечение качества
5.4. Инструкции и справки
5.5. Сопровождение программного обеспечения
5.6. Исторические справки
6. Установление стратегии документирования
7. Определение стандартов и руководств по документированию
7.1. Выбор модели жизненного цикла программного обеспечения
7.2. Определение типов и содержания документов
7.3. Определение качества документов
7.4. Определение форматов документов
7.5. Определение системы обозначения документов
8. Установление процедур документирования
9. Распределение ресурсов для документирования
9.1. Персонал
9.2. Средства
9.3. Финансирование
10. Планирование документирования
Приложение А. Контрольные таблицы для управления программной
документацией

251.

Содержание ISO/IEC ТО 9294-90. Руководство по управлению
документированием программного обеспечения (ГОСТ Р ИСО/МЭК ТО 9294-93)
Раздел 6. Установление стратегии документирования
Стратегия должна поддерживать основные
элементы эффективного документирования:
1) требования документации охватывают весь
жизненный цикл программного обеспечения.
2) документирование должно быть управляемым.
3) документация должна соответствовать
ее читательской аудитории.
4) работы по документированию должны быть объединены
в общий процесс разработки программного обеспечения.
5) должны быть определены и использованы стандарты
по документированию.
6) должны быть определены средства поддержки.

252.

Содержание ISO/IEC ТО 9294-90. Руководство по управлению
документированием программного обеспечения (ГОСТ Р ИСО/МЭК ТО 9294-93)
Раздел 7. Определение стандартов и руководств по
документированию
Внутри организации должны быть приняты стандарты
и руководства для:
1) модели жизненного цикла программного обеспечения;
2) типов и взаимосвязей документов;
3) содержания документа;
4) качества документа;
5) форматов документа;
6) обозначения документа.

253.

254.

Содержание ISO/IEC ТО 9294-90. Руководство по управлению
документированием программного обеспечения (ГОСТ Р ИСО/МЭК ТО 9294-93)
Раздел 8. Установление процедур документирования
Процедура управления документацией ПО:
Шаг 1 - Планирование;
Шаг 2 - Подготовка;
Шаг 3 - Конфигурационное управление;
Шаг 4 - Проверка;
Шаг 5 - Утверждение;
Шаг 6 - Производство;
Шаг 7 - Хранение;
Шаг 8 - Дублирование;
Шаг 9 - Распространение и модернизация;
Шаг 10 - Продажа.

255.

Контрольные таблицы для управления документацией ПС
ISO/IEC ТО 9294-90 (ГОСТ Р ИСО/МЭК ТО 9294-93)
А.1. КОНТРОЛЬНАЯ ТАБЛИЦА СТРАТЕГИИ
а) Будут ли решения направлены на:
1) создание соответствующей программной документации?
2) применение стандартов и руководств по документированию?
3) установление процедур документирования?
4) создание ресурсов, пригодных для документирования?
5) использование средств автоматизированного документирования?
6) определение штата с ответственностями за:
обеспечение стандартами и процедурами по документированию?
контроль качества документации?
б) Будет ли опубликован стратегический отчет?

256.

Контрольные таблицы для управления документацией ПС
ISO/IEC ТО 9294-90 (ГОСТ Р ИСО/МЭК ТО 9294-93)
А.2. КОНТРОЛЬНАЯ ТАБЛИЦА СТАНДАРТОВ
Будут ли приняты или определены стандарты для:
а) модели жизненного цикла программного обеспечения?
б) типов и содержания документов?
в) уровней качества документов?
г) форматов документов?
д) обозначения документов?

257.

Контрольные таблицы для управления документацией ПС
ISO/IEC ТО 9294-90 (ГОСТ Р ИСО/МЭК ТО 9294-93)
А.3. КОНТРОЛЬНАЯ ТАБЛИЦА ПРОЦЕДУР
Будут ли установлены для документирования процедуры:
а) планирования?
б) контроля?
в) производства?
г) проверок и утверждений?
д) распространения?
е) хранения оригинала и дубликата?
ж) актуализации?
и) продажи (распространения)?

258.

Контрольные таблицы для управления документацией ПС
ISO/IEC ТО 9294-90 (ГОСТ Р ИСО/МЭК ТО 9294-93)
А.4. КОНТРОЛЬНАЯ ТАБЛИЦА ПЛАНИРОВАНИЯ ПРОЕКТА
а) Будет ли создан план документирования, который
включает в себя:
1) типы, содержание, качество, форматы, условия
для перевода документов?
2) графики документов?
3) ассигнования на документы?
б) Будут ли определены ответственности за:
1) подготовку документов?
2) проверку и утверждение документов?
в) Будет ли штат обеспечен соответствующими средствами
для задач документирования?

259.

Документирование программных средств
Практическое задание
1 Укажите документы управляющие каждым этапом разработки
Вашего ПС и документы планируемые для создания по
результатам каждого этапа (результаты одного этапа могут
быть управляющими документами для другого).
2 Укажите критерии качества каждого получаемого в результате
разработки Вашего ПС документа.
Этап жизненного
цикла ПС
Управляющий
документ
Документ получаемый
в результате этапа
Критерий
качества
1 Системный
анализ
Цели системного
анализа …
Отчет о системном
анализе:
- функциональные
модели “как есть” …
Достижение
целей
системного
анализа …
…
…
…
…

260.

Технология разработки
программного обеспечения
УПРАВЛЕНИЕ РАЗРАБОТКОЙ И АТТЕСТАЦИЯ
ПРОГРАММНОГО СРЕДСТВА
ЛЕКЦИЯ 12

261.

Процессы жизненного цикла ПО, обеспечения ресурсами
и управления по МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)

262.

Управление проектом разработки программного обеспечения
по технологии IBM Rational Unified Process
Предлагает
1 Структуру управления проектами
2 Практические рекомендации по планированию,
укомплектованию персоналом, выполнению и мониторингу проектов
3 Структуру управления рисками

263.

Включает следующие действия

264.

Поток работ IBM Rational Unified Process: Управление проектом
1 Распределяет ресурсы
2 Определяет приоритеты
3 Координирует взаимодействие заказчиков с разработчиками
4 Руководит группой разработчиков и устанавливает регламенты работ

265.

Поток работ IBM Rational Unified Process: Управление проектом
1 Общее описание ПС
2 Определение контекста предметной области для которой создается ПС
3 Определение цели создания ПС
4 Разработка финансового прогноза
5 Описание проектных ограничений (по имеющимся ресурсам)

266.

Поток работ IBM Rational Unified Process: Управление проектом
1 Идентификация рисков
2 Группировка и сортировка рисков
3 Идентификация стратегий предотвращения рисков
4 Идентификация стратегий уменьшения рисков
5 Идентификация стратегий локализации рисков

267.

Поток работ IBM Rational Unified Process: Управление проектом
Вехи – временные точки перехода
от одной стадии разработки ПО к другой.
Для перехода к новой стадии необходимо
достигнуть все запланированные цели вех
1 Определение вех проекта
2 Определение целей вех
3 Определение количества и длины итераций в пределах стадий
4 Уточнение сроков вех и контекста предметной области создания ПС
5 Определение плана измерений

268.

Поток работ IBM Rational Unified Process: Управление проектом
1 Распределение потребностей в персонале по временным стадиям
2 Распределение обязанностей среди работников
3 Формирование групп разработчиков
4 Обучение персонала

269.

Поток работ IBM Rational Unified Process: Управление проектом
В RUP работник это не конкретная личность,
работник – это понятие описывающее виды работ,
которые личности могут выполнять

270.

Поток работ IBM Rational Unified Process: Управление проектом
1 Определение рамок итерации
2 Определение критериев оценки итерации
3 Определение действий итерации
4 Распределение ответственности

271.

Поток работ IBM Rational Unified Process: Управление проектом
Выполнение плана итерации

272.

Поток работ IBM Rational Unified Process: Управление проектом
1 Документирование результатов итерации
2 Оценка степени достижения запланированных результатов
(оценочных показателей)
3 Документирование полученных уроков
4 Документирование изменений,
которые необходимо выполнить в следующих итерациях

273.

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

274.

Поток работ IBM Rational Unified Process: Управление проектом
Ревизия рисков

275.

Поток работ IBM Rational Unified Process: Управление проектом

276.

Поток работ IBM Rational Unified Process: Управление проектом
Артефакты (документально оформляемые результаты)
потока работ "Управление проектом"

277.

Поток работ IBM Rational Unified Process: Управление проектом
Rational Unified Process рекомендует разрабатывать два вида планов:
1 План проекта – разрабатывается один раз в начале всего проекта
2 Планы итераций – разрабатываются перед началом каждой итерации

278.

279.

280.

Планирование итерации в стадии "Начало"

281.

Планирование итерации в стадии "Уточнение"

282.

Планирование итерации в стадии "Конструирование"

283.

Состав работ процесса “Менеджмент документации ПС”
согласно МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
1 ПОДГОТОВКА И ОПРЕДЕЛЕНИЕ
ОБЛАСТИ УПРАВЛЕНИЯ
2 ПЛАНИРОВАНИЕ
3 ВЫПОЛНЕНИЕ И КОНТРОЛЬ
4 ПРОВЕРКА И ОЦЕНКА
5 ЗАВЕРШЕНИЕ

284.

Состав работ процесса “Менеджмент документации ПС”
согласно МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
1 ПОДГОТОВКА И ОПРЕДЕЛЕНИЕ
ОБЛАСТИ УПРАВЛЕНИЯ
2 ПЛАНИРОВАНИЕ
5 ЗАВЕРШЕНИЕ
4 ПРОВЕРКА И ОЦЕНКА
3 ВЫПОЛНЕНИЕ И КОНТРОЛЬ

285.

Состав работ процесса “Управление”
согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
1 ПОДГОТОВКА И ОПРЕДЕЛЕНИЕ
ОБЛАСТИ УПРАВЛЕНИЯ
1.1 Установление требований к управляемому
процессу.
1.2 Определение возможностей реализации
управляемого процесса, включая проверку
наличия, соответствие и применимость
ресурсов, для выполнения и управления
процессом (персонал, материалы, технологии и
условия), а также реальность сроков реализации
процесса.
1.3 Изменение требований к управляемому
процессу, при необходимости и по согласованию
со всеми заинтересованными сторонами.

286.

Состав работ процесса “Управление”
согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
1 ПЛАНИРОВАНИЕ
1.1 Подготовка планов управляемого процесса.
При этом планы должны охватывать следующие вопросы:
а) установление графиков своевременного решения задач;
б) оценка необходимых трудозатрат;
в) определение ресурсов, необходимых для выполнения задач;
г) распределение задач по исполнителям;
д) определение обязанностей исполнителей;
е) определение критических ситуаций, связанных с задачами
или самим процессом;
ж) установление используемых в процессе критериев
управления качеством;
и) определение затрат, связанных с реализацией процесса;
к) обеспечение условий и определение инфраструктуры
и выполнения процесса.

287.

Состав работ процесса “Управление”
согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
3 ВЫПОЛНЕНИЕ И КОНТРОЛЬ
3.1 Начало реализации плана управляемого процесса.
3.2 Текущий надзор за выполнением плана управляемого
процесса.
3.3 Исследование, анализ и решение проблем, обнаруженных
при выполнении управляемого процесса.
3.4 Подготовка отчетов о реализации управляемого процесса.

288.

Состав работ процесса “Управление”
согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
4 ПРОВЕРКА И ОЦЕНКА
4.1 Оценка программных продуктов
и планов процессов на соответствие
установленным требованиям.
4.2 Проверка результатов оценок программных
продуктов, работ и задач, реализуемых в ходе управляемого
процесса, на соответствие поставленным целям
и на выполнение утвержденных планов.

289.

Состав работ процесса “Управление”
согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
5 ЗАВЕРШЕНИЕ
5.1 Оценка степени соответствия всех программных
продуктов созданных в результате выполнения управляемого
процесса, а также всех работа и задач управляемого процесса
критериям, установленным в договоре
или организационной процедуре
5.2 Контроль результатов и полноты документации созданных
программных продуктов и выполненных работ.

290.

Практическое задание
1 Опишите в виде контекстной диаграммы IDEF0 входные и
выходные данные, руководящие документы и инструменты
необходимые для управления разработкой Вашего
программного средства.
2 Укажите процессы и лица (должности) - поставщики входных
данных, а также процессы и лица (должности)
- потребители выходных данных.
Лица поставщики
Процессыпоставщики
Управление разработкой
программного средства
Лица потребители
Процессыпотребители

291.

МЕЖДУНАРОДНЫЙ СТАНДАРТ “ISO 10006:2006. РУКОВОДСТВО
ПО МЕНЕДЖМЕНТУ КАЧЕСТВА ПРИ ПРОЕКТИРОВАНИИ”

292.

МЕЖДУНАРОДНЫЙ СТАНДАРТ “ISO 10006:2006. РУКОВОДСТВО
ПО МЕНЕДЖМЕНТУ КАЧЕСТВА ПРИ ПРОЕКТИРОВАНИИ”

293.

МЕЖДУНАРОДНЫЙ СТАНДАРТ “ISO 10006:2006. РУКОВОДСТВО
ПО МЕНЕДЖМЕНТУ КАЧЕСТВА ПРИ ПРОЕКТИРОВАНИИ”

294.

МЕЖДУНАРОДНЫЙ СТАНДАРТ “ISO 10006:2006. РУКОВОДСТВО
ПО МЕНЕДЖМЕНТУ КАЧЕСТВА ПРИ ПРОЕКТИРОВАНИИ”

295.

Подход к управлению качеством
программного обеспечения
КАЧЕСТВО ПРОЦЕССОВ УПРАВЛЕНИЯ
КАЧЕСТВО ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА
КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

296.

297.

Модель системы менеджмента
МС ISO 9001:2008

298.

МС “ISO 9001:2008. СИСТЕМЫ МЕНЕДЖМЕНТА КАЧЕСТВА. ТРЕБОВАНИЯ”

299.

Традиционная структура управления
разработкой программных средств
Директор
(вице-президент)
программистской
организации
Менеджер
сферы
разработок
Менеджер
проекта
Лидер
бригады
разработчиков
Менеджер
сферы
разработок
...
Менеджер
проекта
...
...
Лидер
бригады
разработчиков
Бригада по
качеству
Менеджер
по
качеству
...
Бригада по
качеству

300.

Подходы к организации бригад разработчиков
Бригады
ведущего
программиста
Неформальные
демократические
бригады
Обычные
бригады
Главная задача
рядовых членов такой
бригады создать условия для
наиболее
продуктивной
работы ведущего
программиста
Поручаемая
ей работа
обсуждается
совместно всеми
ее членами,
а задания
между ее членами
распределяются
согласованно
Старший
программист
непосредственно
руководит
работой
младших
программистов

301.

Методы оценки примитивов качества ПС
Непосредственное
измерение примитивов
качества ПС
Проверки
соответствия
документации,
включая отчеты
по результатам
тестирований
проведенных
разработчиками
Тестирование
программ ПС
Измерения
Полевые
Тесты
времени
и
составляются,
работы
если у комиссии промышленные
различных
испытания
возникают
устройств
ПС
определенные
и используемых
сомнения
ресурсов при
в полноте
выполнении
тестирования,
контрольных
проведенного
(тестовых) задач разработчиками
Экспертная
оценка
на основании
изучения
программ и
документации
ПС
Оценка
требуемого
примитива
качества ПС
устанавливается
голосованием
членов
экспертной
группы

302.

Состав работ процесса “Аттестация”
согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
1 ПОДГОТОВКА ПРОЦЕССА АТТЕСТАЦИИ
2 АТТЕСТАЦИЯ

303.

Состав работ процесса “Аттестация”
согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
1 ПОДГОТОВКА ПРОЦЕССА АТТЕСТАЦИИ
1.1 Определение необходимости аттестации и степень организационной
независимости при проведении данных работ.
1.2 Если проект разработки ПО предусматривает работы по аттестации,
должен быть установлен процесс аттестации для программного продукта.
1.3 Если проект разработки ПО предусматривает работы по независимой
аттестации, должна быть выбрана квалифицированная организация,
ответственная за проведение аттестации.
1.4 Разработка и документальное оформление план проведения аттестации.
1.5 Реализация плана проведения аттестации. Проблемы и несоответствия,
обнаруженные при проведении аттестации, должны быть введены
в процесс решения проблем.

304.

Состав работ процесса “Аттестация”
согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
1 ПОДГОТОВКА ПРОЦЕССА АТТЕСТАЦИИ
План проведения аттестации должен определять
(но не ограничиваться):
а) объекты, подлежащие аттестации;
б) задачи, решаемые при аттестации;
в) ресурсы, обязанности и график при проведении аттестации;
г) процедуры передачи отчетов об аттестации заказчику
и другим сторонам.

305.

Состав работ процесса “Аттестация”
согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
2 АТТЕСТАЦИЯ
2.1 Подготовка выбранных требований к испытаниям (тестированию),
контрольных примеров и технических условий испытаний
к анализу результатов испытаний.
2.2 Обеспечение того, чтобы требования к испытаниям (тестированию),
контрольные примеры и технические условия испытаний отражали
конкретные требования к конкретным объектам аттестации.
2.3 Проведение испытаний, включая:

306.

Состав работ процесса “Аттестация”
согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
2 АТТЕСТАЦИЯ
Проведение испытаний, включает:
а) испытания при критических, граничных и особых значениях
исходных данных;
б) испытание программного продукта на способность изолировать
и минимизировать эффект ошибок с постепенным понижением влияния сбоев
и запросом помощи оператора при критических, граничных и особых условиях;
в) испытание при участии репрезентативно выбранных пользователей,
могущих успешно решать свои задачи при использовании
данного программного продукта;
г) подтверждение того, что программный продукт удовлетворяет
заявленным возможностям;
д) испытание программного продукта в выбранных областях
среды эксплуатации.

307.

Технология разработки
программного обеспечения
ОБЪЕКТНЫЙ ПОДХОД К РАЗРАБОТКЕ
ПРОГРАММНЫХ СРЕДСТВ
ЛЕКЦИЯ 13

308.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
1 Объект – это воплощение некоторой сущности, которая
имеет некоторое состояние, которое может изменяться
со временем как следствие влияния других объектов,
находящихся с ним в каких-либо отношениях.
2 Объект может иметь внутреннюю структуру:
состоять из других объектов, также находящихся
между собой в некоторых отношениях.
Исходя из этого
Можно построить иерархическое строение
мира из объектов

309.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Объект - сущность в адресном
пространстве вычислительной системы,
появляющаяся при создании экземпляра
класса или копирования прототипа
(например, после запуска результатов
компиляции и связывания исходного
кода на выполнение).

310.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Пример объекта с именем “Стул”
Состояние
объекта

311.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Окружающий нас мир состоит из объектов
и отношений между ними
Если отношение связывает n объектов,
то такое отношение называется n-местным (n-арным)
Объекты, которые могут быть связаны одним
и тем же отношением называются объектами одного класса
Свойства объектов можно определять
по отношениям, в которых они могут участвовать
Окружающий нас мир, можно рассматривать
как иерархическую структуру модельных миров
– миров различных объектов и классов объектов,
из которых он состоит.

312.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Представление объекта с именем Стул
Простые свойства
объекта (отношение
связано с одним объектом “Стулом”)
Состояние объекта
может быть изучено
по значению его простых
или ассоциативных
свойств.
Ассоциативные свойства объекта
(отношения связывают объект “Стул”
с другими объектами: покупателями, продавцами и т.д.)

313.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
ОБЪЕКТЫ
Неделимые
Могут рассматривать,
в зависимости от целей моделирования,
как …
Делимые
Объект может иметь внутреннюю структуру:
состоять из других объектов, находящихся между
собой в некоторых отношениях

314.

315.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Объектно-ориентированное представление ПС
основывается на принципах:
– абстрагирования;
– инкапсуляции;
– модульности;
– иерархической организации.
Абстрагирование — удобный инструмент для борьбы
со сложностью ПС - рассмотрение только существенных
для достижения целей разработки ПС характеристик объектов.
ПРИМЕР: изучение в объекте - абстракции “часы” характеристики
“показывать время”, и игнорировать характеристики:
форма, цвет, материал, цена, изготовитель.

316.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Пример абстракции
Физический объект
— датчик скорости, устанавливаемый на борту летательного аппарата.
Обязанности датчика:
– знать проекцию скорости летательного аппарата
в заданном направлении;
– показывать текущую скорость;
– подвергаться настройке.
Скорость и Направление — вспомогательные подтипы,
обеспечивающие задание абстракции датчика состоящей из функции
показывающих его основное назначения для пользователя:
ДатчикСкорости {
function НовыйДатчик (Направление)
function ТекущаяСкорость (ДатчикСкорости)
function Настраивать(Скорость)}

317.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Объектно-ориентированное представление ПС
основывается на принципах:
– абстрагирования;
– инкапсуляции;
– модульности;
– иерархической организации.
Инкапсуляция и абстракция — взаимодополняющие понятия:
- абстракция выделяет внешнее поведение объекта;
- инкапсуляция содержит и скрывает реализацию,
которая обеспечивает это поведение.

318.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Объектно-ориентированное представление ПС
основывается на принципах:
– абстрагирования;
– инкапсуляции;
– модульности;
– иерархической организации.
Модульность определяет способность системы подвергаться
декомпозиции на ряд сильно связанных и слабо сцепленных модулей.

319.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Объектно-ориентированное представление ПС
основывается на принципах:
– абстрагирования;
– инкапсуляции;
– модульности;
– иерархической организации.
Иерархическая организация задает размещение абстракций
на различных уровнях описания системы.
Двумя важными инструментами иерархической организации
в объектно-ориентированных системах являются:
– структура из классов;
– структура из объектов.

320.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Окружающий нас мир, можно рассматривать
как иерархическую структуру модельных миров
– миров различных объектов и классов объектов,
из которых он состоит.
Каждый объект информационно может быть
представлен некоторой структурой данных, отображающей
его состояние
Для получение информации
об отдельных свойствах объектов
или результаты какого-либо
взаимодействия между объектами
модельного мира
Для получения информации
об изменении состояний объектов
модельного мира в результате
их взаимодействий
Функциональный подход
к разработке ПС
Объектно-ориентированные
подход к разработке ПС

321.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Каждый объект информационно может быть
представлен некоторой структурой данных, отображающей
его состояние
Для получения информации об изменении состояний объектов
модельного мира в результате их взаимодействий
Объектно-ориентированные подход к разработке ПС
Его сущность состоит в систематическом использовании
декомпозиции объектов при описании и построении ПС.
При этом функции, выполняемые ПС,
выражаются через отношения объектов разных уровней.

322.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Категории объектов
Объекты модельного – вещественного мира
Информационные модели объектов реального мира
– пользовательские объекты
Объекты процесса выполнения программ
Объекты процесса разработки ПС
– технологические объекты программирования
Пассивные объекты
Активные объекты
Внешняя активная сила
Внутренняя активная сила

323.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Категории объектов

324.

ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Специфические – "объектные" черты процессов
разработки ПС:
– использование системы понятий,
позволяющих описывать объекты и их классы;
– декомпозиция объектов является
основным средством упрощения ПС;
– использование внепрограммных абстракций
для упрощения процессов разработки;
– предпочтение разработки
структуры данных перед реализацией функций.

325.

Классический жизненный цикл программного обеспечения
1 Определяет роль каждого элемента ПО
и их взаимодействие в системе, в которой
планируется применять ПО
2 Определяет технические требования
к каждому элементу ПО
4 Результаты
проектирования
переводятся в текст языка
программирования
3 Определяются: архитектура,
модульная структура,
алгоритмическая структура,
структуры данных,
входной и выходной интерфейс
6 Устранение ошибок и
совершенствование ПО

326.

327.

Исходные данные и результаты описания ПС
Кодирование
ПС
Определение
требований к ПС
Описание
требований ПС:
- функции
(функциональная
спецификация);
- свойства
(спецификация
качества).
Документация по
применению ПС
Тесты для ПС

328.

329.

330.

Функциональная спецификация ПС при объектном подходе
к его разработке
Формальное описание модельного мира, состоящее из трех частей
Объектной модели Динамической Функциональной
(статической модели)
модели
модели
Определяет то,
что с чем-то
случится
Классы объектов
и отношений между
этими классами
Объекты классов
и отношения между
объектами
Определяет,
когда что-то
случится
Определяет то,
что случилось
Имя класса/объекта
Список атрибутов
класса/объекта
Список операций
класса/объекта
Взаимодействия
Связи объекта
Агрегирования
Ассоциации классов
Абстрагирования

331.

Функциональная спецификация ПС при объектном подходе
к его разработке
Пример операций класса/ объекта

332.

Функциональная спецификация ПС при объектном подходе
к его разработке
Связь агрегации

333.

Примет Ассоциации “взаимодействия”
Страна
Название
Имеет столицу
Город
Название
Примет Ассоциации “агрегирования”
Программа
Модуль
Имя
Имя

334.

Функциональная спецификация ПС при объектном подходе
к его разработке
Формальное описание модельного мира, состоящее из трех частей
Объектной
модели
Динамической
модели
Функциональной
модели
Определяет то,
что с чем-то
случится
Определяет,
когда что-то
случится
Определяет то,
что случилось
События объектов
Состояния объектов
Диаграмма
состояний

335.

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

336.

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

337.

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

338.

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

339.

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

340.

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

341.

342.

Модель разработки
архитектуры
программного средства
МС “ISO ISO/IEC
42010:2007 (IEEE 1471)
Отношения: 1 Различается; 2 Различается; 3 Выбирается; 4 Агрегируется,
5 Состоит из видов; 6 Имеет; 7 Адресуется; 8 Реализуется; 9 Покрывает;
10 Устанавливает форму; 11 Состоит из моделей; 12 Содержит; 13 Убеждает;
14 Представляет; 15 Использует; 16 Имеет; 17 Размещена; 18 Обеспечивает)

343.

Пример компонентой диаграммы

344.

Представление интерфейса

345.

Моделирование реализации системы

346.

Моделирование реализации системы

347.

Особенности
объектно-ориентированного тестирования
Программный модуль
Тестирование
программных
модулей
Тестовые
драйверы восходящем
и заглушки
применяемые
при нисходящем
тестировании
=
Класс объектов
Тестирование классов
осуществляется путем
тестирования экземпляров
классов
Тестовый
драйвер
Создает экземпляры
классов и имитирует
их окружение, посылая
сообщения
и обрабатывая
получаемые данные

348.

Особенности
объектно-ориентированного тестирования
Программный модуль
=
Класс объектов
тестирование
традиционных модулей
ориентировано на поток
управления внутри модуля
и поток данных через
интерфейс модуля
тестирование классов
ориентировано на операции,
инкапсулированные в классе,
и состояния в пространстве
поведения класса
Каждая операция
выполняемая в
программном модуле
тестируется отдельно
Каждая операция
выполняемая в классе
(программном модуле)
тестируется с учетом
особенностей ее
применения подклассами

349.

Технология разработки
программного обеспечения
КОМПЬЮТЕРНАЯ ПОДДЕРЖКА РАЗРАБОТКИ
И СОПРОВОЖДЕНИЯ ПРОГРАММНЫХ СРЕДСТВ
ЛЕКЦИЯ 14

350.

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

351.

Инструменты разработки ПС
Инструментальная среда разработки и сопровождения ПС
- логически связанная совокупность программных
и аппаратных инструментов.
- Редакторы
- Анализаторы
- Преобразователи
- Инструменты, поддерживающие процесс выполнения программ
Редакторы поддерживают конструирование (формирование)
тех или иных программных документов (спецификаций ПС,
функциональных и др. моделей, отчетов по тестированию и т.п.)
на различных этапах жизненного цикла:
- универсальные текстовые редакторы (MS Word и т.п.);
- специализированные редакторы для каждого вида документов
(например графические средства описания диаграмм, синтаксически
управляемые редакторы ориентированные на используемый язык
программирования и т.п.).

352.

Редакторы поддерживают конструирование (формирование)
тех или иных программных документов (спецификаций ПС,
функциональных и др. моделей, отчетов по тестированию и т.п.)
на различных этапах жизненного цикла:
- универсальные текстовые редакторы (MS Word и т.п.);
- специализированные редакторы для каждого вида документов
(например графические средства описания диаграмм, синтаксически
управляемые редакторы ориентированные на используемый язык
программирования и т.п.).

353.

Инструменты разработки ПС
Инструментальная среда разработки и сопровождения ПС
- логически связанная совокупность программных
и аппаратных инструментов.
- Редакторы
- Анализаторы
- Преобразователи
- Инструменты, поддерживающие процесс выполнения программ
Анализаторы производят:
-статическую обработку документов, осуществляя различные виды
их контроля, выявление определенных их свойств и накопление
статистических данных (например, проверку соответствия документов
указанным стандартам),
- динамический анализ программ (например, с целью выявление
распределения времени работы программы по программным
модулям).

354.

Инструменты разработки ПС
Инструментальная среда разработки и сопровождения ПС
- логически связанная совокупность программных
и аппаратных инструментов.
- Редакторы
- Анализаторы
- Преобразователи
- Инструменты, поддерживающие процесс выполнения программ
Преобразователи позволяют автоматически:
- приводить документы к определенной форме представления
(например, форматеры);
-переводить документ одного вида к документу другого вида
(например, конверторы или компиляторы);
- синтезировать какой-либо документ из отдельных частей и т.п.

355.

Инструменты разработки ПС
Инструментальная среда разработки и сопровождения ПС
- логически связанная совокупность программных
и аппаратных инструментов.
- Редакторы
- Анализаторы
- Преобразователи
- Инструменты, поддерживающие процесс выполнения программ
Инструменты, поддерживающие процесс выполнения программ,
позволяют:
- выполнять на компьютере описания процессов или отдельных
их частей, представленных в виде, отличном от машинного кода;
- выполнять машинный код с дополнительными возможностями его
интерпретации:
а) эмуляторы кода другого компьютера;
б) отладчики.

356.

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

357.

Инструментальные среды разработки и сопровождения ПС
Разработка ПС производится
на том же компьютере,
на котором оно будет
применяться
Инструментально
- объектный подход
ПС разрабатывается компьютере,
называемым инструментальным
Применяется на компьютере,
называемым целевым
Признаки инструментальных сред разработки и сопровождения ПС:
– Ориентированность на конкретный язык программирования
– Специализированность
– Комплексность
– Ориентированность на конкретную технологию программирования
– Ориентированность на коллективную разработку
– Интегрированность

358.

359.

360.

Признаки инструментальных сред разработки и сопровождения ПС:
– Ориентированность на конкретный язык программирования
– Специализированность
– Комплексность
– Ориентированность на конкретную технологию программирования
– Ориентированность на коллективную разработку
– Интегрированность
USED AT:
AUTHOR: Ê.Ý . Ïèñàðåíêî
DA TE: 26.12.2009
WORKING
PROJECT: Ïðîöåññû ðàçðàáîòêè ÏÎ ïî ISO/IEC
122007
REV :
DRA FT
26.12.2009
REA DER
DA TE
CONTEXT:
TOP
Степень охвата процессов разработки ПС
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
A0
Процессы жизнененного цикла ПО
Заказ
Поставка
Подготовка
заказа
Подготовка
поставки
Подготовка процесса разработки
Подготовка
заявки на
подряд
Подготовка
ответа
Проектирование архитектуры
системы
Подготовка
договора
Анализ требований к ПС
Подготовка и
корректировка
договора
Надзор за
поставщиком
Приемка и
закрытие
договора
Разработка
Анализ требований к системе
Планирование
Проектирование архитектуры
ПС
Выполнение и
контроль
Техническое проектирование ПС
Проверка и
оценка
Поставка и
закрытие
договора
Программирование и
тестирование ПС
Эксплуатация
Сопровождение
Подготовка
процесса
эксплуатации
Подготовка
процесса
сопровождения
Эксплуатационные
испытания
Анализ
проблем и
изменений
Эксплуатация
информационной
системы
Поддержка
пользователя
Внесение
изменений
Проверка и
приемка при
сопровождении
Сборка ПС
Перенос
Квалификационные испытания
ПС
Снятие с
эксплуатации
Сборка системы
Квалификационные испытания
системы
Ввод в действие ПС
Обеспечение приемки ПС

361.

362.

363.

364.

Признаки инструментальных сред разработки и сопровождения ПС
– Ориентированность
на конкретный язык
программирования
Глобальная ориентированность
Локальная ориентированность
– Специализированность
Среда ориентирована или нет
на предметную область
– Комплексность
Среда поддерживает все или нет
процессы разработки
и сопровождения ПС
– Ориентированность
на конкретную ТРПО
Среда ориентированана
фиксированную ТРПО или нет
– Ориентированность
на коллективную
разработку
Среда поддерживает или нет
управление (management) коллективом
– Интегрированность
Интегрированность по:
- пользовательскому интерфейсу;
- данным (предполагает наличие репозитария);
- действиям.
Инструментальная система - инструментальная среда,
интегрированная по данным или по действиям

365.

Классы инструментальных сред программирования
Инструментальные среды
разработки и сопровождения ПС
Инструментальные
среды
программирования
Инструментальные
системы технологии
программирования
Рабочие места
компьютерной технологии

366.

Могут обладать
следующими
признаками …
Предназначены
для …
– кодирования;
– тестирования;
– отладки ПС.

367.

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

368.

Рабочие места компьютерной технологии
Системный анализ
Спецификации ПС;
Автоматическая
генерация программ
по спецификациям
Инструменты
разработки
ПС…
Конструкторы пользовательских интерфейсов
Инструмент работы со словарем
именованных сущностей
Графические и тестовые редакторы
спецификаций
Анализаторы спецификаций
Генератор программ
Документаторы

369.

Обязательно
обладают
следующими
признаками …
Предназначены
для …
поддержки всех
процессов разработки
и сопровождения
в течение всего
жизненного цикла ПС
и ориентирована на
коллективную
разработку больших
программных систем
с продолжительным
жизненным циклом

370.

Инструментальные системы технологии программирования

371.

Предназначены
для …
– кодирования;
– тестирования;
– отладки ПС.
Инструментальные
среды
программирования
Общего
назначения
(не ориент.
на яз. прогр.)
Ориентированные
на конкретный
язык
программирования
Интерпретирующие
Синтаксически
-управляемые

372.

Инструментальные
среды
программирования
Общего
назначения
(не ориент.
на яз. прогр.)
Ориентированные
на конкретный
язык
программирования
Интерпретирующие
Синтаксически
-управляемые
Интерпретирующая инструментальная среда программирования
обеспечивает интерпретацию программ на языке программирования,
т.е. содержит, прежде всего, интерпретатор языка программирования,
на который эта среда ориентирована.
Такая среда необходима для языков программирования
интерпретирующего типа (таких, как Лисп), но может использоваться
и для других языков (например, на инструментальном компьютере).

373.

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

374.

CASE - Computer Aided Software Engineering
- программная инженерия с компьютерной
поддержкой.
Основные усилия
в разработке программного обеспечения
до внедрения
после внедрения
CASE-технологий …
CASE-технологий …

375.

USED AT:
Изменения основных усилий в разработке
программного обеспечения после внедрения
CASE-технологий
DA TE: 26.12.2009
WORKING
AUTHOR: Ê.Ý . Ïèñàðåíêî
REV :
26.12.2009
DRA FT
PROJECT: Ïðîöåññû ðàçðàáîòêè ÏÎ ïî ISO/IEC
RECOMMENDED
122007
МС ISO/IEC 12207:95
PUBLICATION
NOTES: 1 2 3 4 5 6 7 8 9 10
REA DER
DA TE: 26.12.2009
DA TE CONTEX
WORKING
REV :
DRA FT
26.12.2009
МС ISO/IEC 12207:95
RECOMMENDED
A0
PUBLICATION
Процессы жизнененного цикла ПО Процессы жизнененного цикла П
Заказ
Разработка
Поставка
Подготовка процесса
разработки
Подготовка
Подготовка
Анализ требований
к системе
заказа
поставки
Подготовка
Подготовка
Проектирование архитектуры
заявки
на
ответа
системы
подряд
Подготовка
Анализ требований
к ПС
Подготовка
и
договора
Проектирование
архитектуры
ие корректировка
Планирование
ПС
договора
и
Выполнение ПС
и
Техническое проектирование
Надзор за
контроль
Программирование
и
поставщиком
Проверка
и
тестирование ПС
Приемка и
оценка
Сборка ПС
закрытие
Поставка и
Квалификационные
испытания
договора
закрытие
ПС
договора
Сборка системы
Эксплуатация
Разработка
Сопрово
Подготовка
Подгото
Подготовка
процесса разработки
процесса
процесс
Анализ требований к системе
эксплуатации
сопрово
Проектирование архитектуры
Эксплуатационные
Анализ
системы
испытания
проблем
Анализ требований к ПС изменен
Эксплуатация
Проектирование
архитектуры
информационной
Внесени
ПС
системы
изменен
Техническое
ПС
Поддержкапроектирование
Проверк
Программирование
и
пользователя
приемка
тестирование ПС
сопрово
Сборка ПС
Перенос
Квалификационные испытания
Снятие
ПС
эксплуа
Сборка системы
Квалификационные испытания
системы
Квалификационные испытания
системы
Ввод в действие ПС
Ввод в действие ПС
Обеспечение приемки ПС
Обеспечение приемки ПС

376.

Изменения основных усилий в разработке
программного обеспечения после внедрения
CASE-технологий
Появилась возможность:
- формирования формальных функциональных спецификаций
программ с возможностью автоматической генерации кода;
- формирования формальных спецификаций архитектуры ПС
с возможность автоматической генерации программ;
- автоматической генерации части документации,
необходимой разработчикам и пользователям;
- автоматической генерации тестов по формальным
спецификациям для комплексной – системной отладки ПС;
- автоматического изменения содержания программ по
изменениям в спецификациях.

377.

Жизненный цикл ПС при применении CASE-технологий

378.

Критерии выбора CASE-средств

379.

380.

Технология разработки
программного обеспечения
Технологии разработки
программного обеспечения
ведущих IT-компаний
ЛЕКЦИИ 15 - 16

381.

Унифицированный процесс разработки
программного обеспечения и разработка
в стиле экстремального программирования

382.

383.

Типовая итерация унифицированного процесса
разработки программного обеспечения

384.

Два измерения унифицированного процесса разработки

385.

Модели – документы создаваемые на разных стадиях
унифицированного процесса разработки (RUP) ПО

386.

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

387.

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

388.

Архитектура RUP

389.

Управление рисками в унифицированном процессе разработки ПО
RE = P(UO) x L(UO),
где:
– RE — показатель риска (Risk Exposure — подверженность риску);
– P(UO) — вероятность неудовлетворительного результата
(Unsatisfactory Outcome);
– L(UO) — потеря при неудовлетворительном результате.
УПРАВЛЕНИЕ РИСКОМ ВКЛЮЧАЕТ ШЕСТЬ ДЕЙСТВИЙ:
оценивание риска:
– идентификация риска — выявление элементов риска в проекте;
– анализ риска — оценка вероятности и величины потери
по каждому элементу риска;
– ранжирование риска — упорядочение элементов риска
по степени их влияния;
контроль риска:
– планирование управления риском — подготовка к работе
с каждым элементом риска;
– разрешение риска — устранение или разрешение элементов риска;
– наблюдение риска — отслеживание динамики элементов
риска, выполнение корректирующих действий.

390.

Управление рисками в унифицированном процессе разработки ПО
Выделяют три категории
источников риска:
– проектный риск;
– технический риск;
– коммерческий риск.

391.

Управление рисками в унифицированном процессе разработки ПО
Пример, проверочного списка десяти
главных элементов программного риска:
– дефицит персонала;
– нереальные расписание и бюджет;
– разработка неправильных функций и характеристик;
– разработка неправильного пользовательского интерфейса;
– слишком дорогое обрамление;
– интенсивный поток изменения требований;
– дефицит поставляемых компонентов;
– недостатки в задачах, разрабатываемых смежниками;
– дефицит производительности при работе в реальном
времени;
– деформирование научных возможностей.

392.

393.

Управление рисками в унифицированном процессе разработки ПО
P(UO)
L(UO)
RE = P(UO)xL(UO)

394.

395.

Управление рисками в унифицированном процессе разработки ПО
P(UO)
L(UO)
RE = P(UO)xL(UO)

396.

397.

398.

Унифицированный процесс
разработки программного обеспечения (RUP)
Практическое задание
1 Определите два-три основных риска
в разработке Вашего программного
средства.
2 Определите критерии разрешения
рисков.
Выделяют три категории источников риска:
– проектный риск;
– технический риск;
– коммерческий риск.

399.

Два измерения унифицированного процесса разработки

400.

Два измерения унифицированного процесса разработки
Цели этапа НАЧАЛО:
– определить область применения проектируемой
системы:
а) предназначение;
б) границы;
в) интерфейсы с внешней средой;
г) критерий признания — приемки;
– определить элементы Use Case – диаграмм вариантов
использования, критические для системы:
а) основные сценарии поведения, задающие ее функциональность
и покрывающие главные проектные решения;
– определить общие черты архитектуры, обеспечивающей основные
сценарии, создать демонстрационный макет;
– определить общую стоимость и план всего проекта и обеспечить
детализированные оценки для этапа развития;
– идентифицировать основные элементы риска.

401.

Два измерения унифицированного процесса разработки
Основные действия этапа НАЧАЛО:
– формулировка области применения результатов проекта
разработки ПС;
– планирование и подготовка начального бизнес-плана
проекта разработки ПС и альтернатив его развития;
– определение персонала, необходимого для реализации
плана проекта разработки ПС;
– выявление зависимостей между стоимостью,
планированием и полезностью ПС;
– получение предварительной архитектуры ПС – развитие
компромиссных решений проектирования, определение
решений: разработки, покупки и повторного использования
ПС.

402.

Два измерения унифицированного процесса разработки
Результаты этапа НАЧАЛО - следующие артефакты:
– спецификация представления основных проектных
требований, ключевых характеристик и главных ограничений;
– начальная модель Use Case (20% от полного
представления) и начальный словарь проекта;
– начальный бизнес-план проекта, включающий:
а) содержание бизнеса,
б) критерий успеха — прогноз дохода, прогноз рынка,
финансовый прогноз;
– начальное оценивание рисков проекта;
– план проекта разработки ПС, в котором показаны этапы
и итерации.

403.

Два измерения унифицированного процесса разработки

404.

Два измерения унифицированного процесса разработки
Цели этапа РАЗВИТИЕ:
– определить оставшиеся требования;
– определить архитектуру ПС;
– отслеживать риски и устранять источники наибольших
из них;
– разработать план итераций этапа КОНСТРУИРОВАНИЕ.
В итоге этапа РАЗВИТИЕ создаются следующие
артефакты:
– модель Use Case (80% от полного представления);
– описание архитектуры ПС;
– выполняемый макет ПС;
– пересмотренный список элементов риска
и пересмотренный бизнес-вариант;
- план этапа КОНСТРУИРОВАНИЕ.

405.

Два измерения унифицированного процесса разработки

406.

Два измерения унифицированного процесса разработки
Цели этапа КОНСТРУИРОВАНИЕ:
– минимизировать стоимость разработки путем оптимизации
ресурсов и устранения необходимости доработок;
– добиться быстрого получения приемлемого качества;
– добиться быстрого получения контрольных версий
(альфа, бета и т. д.).
Основные действия этапа КОНСТРУИРОВАНИЕ:
– управление ресурсами, контроль ресурсов, оптимизация
процессов;
– полная разработка компонентов и их тестирование;
– оценивание реализаций продукта по критериям качества.
В итоге этапа КОНСТРУИРОВАНИЕ создаются следующие
артефакты:
– программный продукт, готовый для передачи в руки
конечных пользователей;
– описание текущей реализации;
– руководство пользователя.

407.

Два измерения унифицированного процесса разработки

408.

Два измерения унифицированного процесса разработки
Главное назначение этапа ПЕРЕХОД
— применить программный продукт
в среде пользователей и завершить реализацию ПС.
Этап начинается с предъявления пользователям:
- бета-реализации продукта;
- в ней обнаруживаются ошибки, которые затем
корректируются;
- параллельно решаются вопросы размещения, упаковки
и сопровождения ПС;
- после завершения периода тестирования продукт считается
реализованным.

409.

Практическое задание
Определите критерии (вехи) перехода
разработки Вашего программного
средства между разными временными
этапами RUP.

410.

Пример разработки в рамках унифицированного процесса
разработки программного обеспечения
Этап НАЧАЛО
Общее описание ПС
Разрабатывается Оконный интерфейс пользователя(WUI)
- представляет из себя среду, управляемую событиями
Действия в среде инициируются функциями обратного вызова,
которые вызываются в ответ на событие — пользовательский ввод
WUI должен обеспечивать следующие типы неперекрывающихся окон:
– простое окно, в которое может быть выведен текст;
– окно меню, в котором пользователь может задать вариант действий;
— выбор подменю или функции обратного вызова.
Ядром WUI является цикл обработки событий,
который организуется МЕНЕДЖЕРОМ ВВОДА.

411.

Пример разработки в рамках унифицированного процесса
разработки программного обеспечения
Этап НАЧАЛО
Идентификация актеров

412.

Пример разработки в рамках унифицированного процесса
разработки программного обеспечения
Этап НАЧАЛО
Идентификация элементов Use Case
Описание элемента Use Case Управление окнами.
Действия начинаются администратором системы.
Администратор может создать, удалить или модифицировать окно.
Описание элемента Use Case Использование окон.
Действия начинаются пользователем прикладной программы.
Обеспечивается возможность работы с меню и простыми окнами.

413.

Пример разработки в рамках унифицированного процесса
разработки программного обеспечения
Этап РАЗВИТИЕ
На этом этапе создаются:
– текстовые сценарии для элементов Use Case;
– диаграммы последовательности
(формализующие текстовые представления сценариев);
– классы и диаграммы классов;
– планы следующих этапов разработки.

414.

Пример разработки в рамках
унифицированного процесса разработки
программного обеспечения
Этап РАЗВИТИЕ
На этом этапе создаются:
– текстовые сценарии для элементов Use Case.
– первый сценарий – Создание окна:
Шаг1 – устанавливаются координаты окна на экране
и стиль рамки окна;
Шаг2 – образ окна сохраняется в памяти;
Шаг3 – окно выводится на экран;
Шаг4 – если создается окно меню, содержащее
обращение к функции обратного вызова, то происходит
установка этой функции;
Шаг5 – менеджер окон добавляет окно в список
управляемых окон WUI.

415.

Пример разработки в рамках унифицированного процесса
разработки программного обеспечения
Этап РАЗВИТИЕ
На этом этапе создаются:
– текстовые сценарии для элементов Use Case.
– второй сценарий – Изменение стиля рамки:
Шаг1 – указывается символ, с помощью которого будет
изображаться рамка;
Шаг2 – образ окна сохраняется в памяти;
Шаг3 – окно перерисовывается на экране.

416.

Пример разработки в рамках унифицированного процесса
разработки программного обеспечения
Этап РАЗВИТИЕ
На этом этапе создаются:
– текстовые сценарии для элементов Use Case.
– третий сценарий – Сценарий Уничтожение окна:
Шаг1 – менеджер окон получает указание удалить окно;
Шаг2 – менеджер окон снимает окно с регистрации
(в массиве управляемых окон WUI);
Шаг3 – окно снимает отображение с экрана.

417.

Пример разработки в рамках унифицированного процесса
разработки программного обеспечения
Этап РАЗВИТИЕ
На этом этапе создаются:
– текстовые сценарии для элементов Use Case.
– четвертый сценарий – Использование окна
Шаг1 – символ воспринимается менеджером ввода;
Шаг2 – в зависимости от значения введенного символа
выполняется один из следующих вариантов:
а) при значении ENTER – вариант ОКОНЧАНИЯ ВВОДА;
б) при переключающем значении – вариант
ПЕРЕКЛЮЧЕНИЯ;
г) при обычном значении
– символ выводится
в активное окно.

418.

Пример разработки в рамках унифицированного процесса
разработки программного обеспечения
Этап РАЗВИТИЕ
На этом этапе создаются:
– текстовые сценарии для элементов Use Case;
– диаграммы последовательности
(формализующие текстовые представления сценариев);
– классы и диаграммы классов;
– планы следующих этапов разработки.

419.

Пример разработки в рамках унифицированного процесса разработки ПО
Этап РАЗВИТИЕ
– первый сценарий – Создание окна:
Шаг1 – устанавливаются координаты окна на экране и стиль рамки окна;
Шаг2 – образ окна сохраняется в памяти;
Шаг3 – окно выводится на экран;
Шаг4 – если создается окно меню, содержащее обращение к функции обратного вызова, то происходит
установка этой функции;
Шаг5 – менеджер окон добавляет окно в список
управляемых окон WUI.
– значащие
существительные
превращаются в
объекты,
– значащие
глаголы
превращаются
в сообщения,
пересылаемые
между объектами.

420.

Пример разработки в рамках унифицированного процесса разработки ПО
Этап РАЗВИТИЕ
– второй сценарий – Изменение стиля рамки:
Шаг1 – указывается символ, с помощью которого будет
изображаться рамка;
Шаг2 – образ окна сохраняется в памяти;
Шаг3 – окно перерисовывается на экране.

421.

Пример разработки в рамках унифицированного процесса разработки ПО
Этап РАЗВИТИЕ
– третий сценарий – Сценарий Уничтожение окна:
Шаг1 – менеджер окон получает указание удалить окно;
Шаг2 – менеджер окон снимает окно с регистрации
(в массиве управляемых окон WUI);
Шаг3 – окно снимает отображение с экрана.

422.

Пример разработки в рамках унифицированного процесса разработки ПО
Этап РАЗВИТИЕ
Диаграмма последовательности сценария
“Использование простого окна”

423.

Пример разработки в рамках унифицированного процесса разработки ПО
Этап РАЗВИТИЕ
Диаграмма последовательности сценария
“Использование окна меню”

424.

Пример разработки в рамках унифицированного процесса
разработки программного обеспечения
Этап РАЗВИТИЕ
На этом этапе создаются:
– текстовые сценарии для элементов Use Case;
– диаграммы последовательности
(формализующие текстовые представления сценариев);
– классы и диаграммы классов
На первом этапе выявляются и именуются классы.
На втором этапе выявляются операции классов.
На третьем этапе определяются отношения
ассоциации между классами

425.

Пример разработки в рамках унифицированного процесса разработки ПО
Этап РАЗВИТИЕ
Создание классов и диаграмм классов
На первом этапе выявляются и именуются классы.
Класс: Window_Manager

426.

Пример разработки в рамках унифицированного процесса разработки ПО
Этап РАЗВИТИЕ
Создание классов и диаграмм классов
На втором этапе выявляются операции классов.
Класс: Window_Manager
Операция класса
Window_Manager:
add_to_list()

427.

Пример разработки в рамках унифицированного процесса разработки ПО
Этап РАЗВИТИЕ
Иерархия классов Оконного интерфейса пользователя (WUI)
– Window — класс, объектами которого являются простые окна;
– Menu — класс, объектами которого являются окна меню.
Этот класс является потомком класса Window;
– Menu_title — класс, объектом которого является окно главного меню.
Класс является потомком класса Menu;
– Screen — класс, объектом которого является экран.
Этот класс обеспечивает позиционирование курсора,
вывод изображения на экран дисплея, очистку экрана;
– Input_Manager — объект этого класса управляет
взаимодействием между пользователем и окнами интерфейса.
Его обязанности: начальные установки среды WUI,
запуск цикла обработки событий, закрытие среды WUI;
– Window_Manager — осуществляет общее управление окнами,
отображаемыми на экране.
Используется менеджером ввода для получения доступа к конкретному окну.

428.

Пример разработки в рамках унифицированного процесса разработки ПО
Этап РАЗВИТИЕ
Иерархия классов Оконного интерфейса пользователя (WUI)
Создание классов и диаграмм классов
На третьем этапе
определяются отношения
ассоциации между классами

429.

Пример разработки в рамках унифицированного процесса
разработки программного обеспечения
Этап РАЗВИТИЕ
На этом этапе создаются:
– текстовые сценарии для элементов Use Case;
– диаграммы последовательности
(формализующие текстовые представления сценариев);
– классы и диаграммы классов;
– планы следующих этапов разработки.

430.

Пример разработки в рамках унифицированного процесса
разработки программного обеспечения
Этап РАЗВИТИЕ
Реализация элемента
Use Case несущая
максимальный риск для ПС
Плана итераций этапа
КОНСТРУИРОВАНИЕ
Итерация 1 — реализация сценариев элемента
Use Case Управление окнами:
– Шаг1 – Создание окна;
– Шаг2 – Уничтожение окна;
– Шаг3 – Изменение стиля рамки.
Итерация 2 — реализация сценариев элемента
Use Case Использование окон:
– Шаг1 -Использование простого окна;
– Шаг2 -Использование окна меню.

431.

Два измерения унифицированного процесса разработки

432.

CASE-средства RUP
IBM Rational Rose – Моделирование (поддержка прямой и обратной разработки)
IBM Rational Requisite Pro – Управление требованиями
(фиксация, организация, ранжирование и прослеживаемость)
IBM Rational SoDA – Управление документацией
IBM Rational Apex/Ada, IBM Rational C++/Java – Программирование
Microsoft Project, IBM Rational ClearQuest – Управление разработкой
IBM Rational ClearCase – Управление конфигурацией
IBM Rational SQA Suite, IBM Rational TestMate,
IBM Rational Visual Test – Тестирование

433.

Управление СРЕДОЙ разработки программного обеспечения
по технологии IBM Rational Unified Process
Цель
Обеспечить разработчиков соответствующей средой – процессами
и инструментальными средствами

434.

Управление СРЕДОЙ разработки программного обеспечения
по технологии IBM Rational Unified Process
ДЕЙСТВИЯ ПОТОКА РАБОТ “СРЕДА”

435.

436.

437.

438.

439.