- •1.12. Лекция: Процесс разработки программного обеспечения
- •1.1.1[Править] Процесс
- •1.1.2[Править] Совершенствование процесса
- •1.1.3[Править] Классические модели процесса
- •1.2[Править] 3. Рабочий продукт, дисциплина обязательств, проект
- •1.2.1[Править] Рабочий продукт
- •1.2.2[Править] Дисциплина обязательств
- •1.2.3[Править] Проект
- •1.3Интегрированная система поддержки жизненного цикла
- •1.4Введение
- •Определение ис
- •Классификация ис
- •Классификация по масштабу
- •Классификация по архитектуре
- •Классификация по характеру использования информации
- •Классификация по системе представления данных
- •Классификация по поддерживаемым стандартам управления и технологиям коммуникации
- •Классификация по степени автоматизации
- •Роль требований в задаче внедрения аис
- •1.5Понятие требования. Классификации требований
- •1.5.1Определение понятия требования
- •1.5.2Классификация требований
- •Требования к продукту и процессу
- •Уровни требований
- •Системные требования и требования к программному обеспечению
- •Функциональные, нефункциональные требования и характеристики продукта
- •Классификация rup
- •1.5.3Методологии и стандарты, регламентирующие работу с требованиями
- •1.6Свойства требований
- •Полнота.
- •Ясность (недвусмысленность, определенность, однозначность спецификаций).
- •Корректность и согласованность (непротиворечивость).
- •Верифицируемость (пригодность к проверке).
- •1.7Процесс анализа требований
- •1.7.1Рабочий поток анализа требований
- •1.7.2Почему нужно анализировать требования?
- •1.7.3Кто создает и использует требования
- •1.7.4Организация работы с требованиями на примере msf
- •1.8Контекст задачи анализа требований
- •1.8.1Анализ требований, бизнес-анализ, анализ проблемной области
- •Роль глоссария при ат.
- •1.8.2Методологии бизнес-анализа
- •1.8.3Требования и архитектура аис
- •1.8.4Анализ требований и другие рабочие потоки программной инженерии
- •1.9Выявление требований
- •1.9.1Источники требований
- •1.9.2Стратегии выявления требований Интервью
- •1. Подготовка
- •2. Проведение опроса
- •Завершение
- •Что нужно помнить при опросе
- •Анкетирование
- •Наблюдение
- •Самостоятельное описание требований
- •Совместные семинары
- •Прототипирование
- •1.10Формирование видения
- •1.10.1Видение продукта и границы проекта
- •1.10.2Концепция в гост рф
- •1.10.3Видение в rup
- •1.10.4Видение / рамки в msf
- •1.11Классификация и специфицирование требований
- •1.11.1Акторы и варианты использования
- •1.11.2Глоссарий
- •1.11.3Спецификация варианта использования
- •Свободный формат
- •Шаблон полного описания варианта использования по а. Коберну
- •Табличные представления варианта использования
- •Шаблон варианта использования rup
- •1.12Расширенный анализ требований. Моделирование
- •1.12.1Какие модели использовать
- •1.12.2Модели uml, поясняющие функциональность системы Диаграмма вариантов использования
- •Диаграмма действий
- •Диаграмма состояний
- •1.12.3Диаграммы uml, поясняющие внутреннее устройство системы
- •Диаграмма классов
- •1.12.4Альтернативные языки моделирования Диаграмма потоков данных
- •Другие виды моделей
- •1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы
- •1.13.1Цели прототипирования
- •1.13.2Классификация прототипов
- •Горизонтальный прототип
- •Вертикальный прототип
- •Одноразовый прототип
- •Эволюционный прототип
- •Бумажный прототип
- •Раскадровка
- •1.13.3Иллюстрированные сценарии прецедентов
- •Ориентиры
- •Средние значения атрибутов и объемы объектов
- •Средняя интенсивность использования
- •1.14Документирование требований
- •1.14.1Документирование требований в соответствие с гост рф
- •Структура тз в соответствие с гост 34.602-89
- •Описание требований к системе в соответствие с гост 34.602-89
- •1.14.2Документирование требований в rup
- •1.14.3Документирование требований на основе ieee Standard 830-1998
- •1.14.44. Требования к внешнему интерфейсу
- •4.1 Интерфейсы пользователя
- •4.2 Интерфейсы оборудования
- •4.3 Интерфейсы по
- •4.4 Интерфейсы передачи информации
- •1.14.55. Другие нефункциональные требования
- •5.1 Требования к производительности
- •1.14.6Документирование требований в msf
- •1.15Проверка требований
- •1.15.1Верификация и валидация
- •1.15.2Некоторые типичные проблемные ситуации процесса формирования и оценки требований Двусмысленность требований
- •"Золочение" продукта
- •Минимальная спецификация
- •Пропуск типов пользователей
- •1.15.3Методы и средства проверки требований
- •Неофициальные просмотры требований
- •Инспекции
- •Разработка тестов
- •Определение критериев приемлемости
- •1.16Введение в управление требованиями.
- •1.16.1Принципы и приемы управления требованиями Базовая версия требований
- •Процедуры управления требованиями
- •Контроль версий
- •Атрибуты требований
- •Контроль статуса требований
- •Измерение трудозатрат, необходимых для управления требованиями
- •1.16.2Управление изменениями Управление незапланированным ростом объема
- •Процесс контроля изменений
- •Анализ влияния изменения
- •Трассируемость требований
- •1.17Совершенствование процессов работы с требованиями
- •1.17.1Модели совершенствования
- •Область процессов "Управление требованиями"
- •Область процессов "Разработка требований"
- •1.17.2Принципы совершенствования
- •1.17.3Процесс совершенствования
- •Оценка текущих приемов
- •Планирование
- •Создание и апробация новых процессов
- •Оценка результатов и принятие решений
- •1.18Требования в управлении проектом
- •1.18.1От рамок проекта к экспресс-планированию
- •1.18.2Планирование проекта на основе требований, путь rup
- •1.18.3Требования в гибких методологиях
- •Артефакты для работы с требованиями в гибких методологиях
- •Планирование на основе требований на примере xp
- •Планирование версий и итераций
- •1.18.4Анализ требований и управление рисками
- •1.18.5Стратегии и работы по управлению риском
- •1.19Заключение
- •1.19.1Современные тенденции в развитии аис и технологий их создания
- •1.19.2Покупное или заказное по - критерии выбора
- •1.19.4Процесс выбора решения
- •1.20Список литературы
- •Белые страницы msf
- •Microsoft Solutions Framework. Модель процессов msf, версия 3.1
- •Гост 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания
- •Гост 19.201-78 "Техническое задание, требования к содержанию и оформлению"
- •Гост 34.602-89 "Техническое задание на создание автоматизированной системы" (тз на ас)
- •1 Аттестации и программного обеспечения
- •1.1 Перечень объектов, подлежащих сертификации, и их характеристики
- •2 Оценка программного обеспечения
- •3 Системы сертификации программного обеспечения и ее стандарты
- •4 Виды испытаний программного обеспечения
- •Стандарты в области промышленного обеспечения.
- •Структура современного рынка программных средств
- •2Введение в программную инженерию
- •2.1Программная инженерия
- •2.2Связь программной инженерии с другими сферами науки
- •3Жизненный цикл пс
- •4Процесс создания пс
- •4.1Стадии разработки пс
- •4.2Понятие метода и технологии проектирования пс
- •4.2.1Определение метода и технологии
- •4.2.2Требования к технологии
- •5Подходы к проектированию по
- •5.1Нисходящий и восходящий подходы к разработке программ
- •5.2Макетирование
- •5.3Структурное программирование
- •5.4Модульное программирование (мп)
- •5.5Формирование структуры модулей программы
- •5.6Подход к разработке программных средств, используемых для автоматизации организационных процессов
- •6Управление требованиями
- •6.1Определение требования и заинтересованного лица
- •6.2Пирамида Требований
- •6.3Трассировка (Связь) между Требованиями
- •6.4Характеристики Хорошего Требования
- •6.5Процесса Управления Требованиями
- •7Модели жизненного цикла пс
- •7.1Каскадный жизненный цикл
- •7.2Спиральная модель
- •7.3Подход rad
- •8Ресурсы для жизненного цикла сложных программных средств
- •9Показатели качества программных средств
- •10Модели качества процессов конструирования
- •10.2Стандарты iso
- •10.3Шесть сигм
- •11Стандартизация пс
- •11.1Стандартизация программных продуктов
- •11.2Виды стандартных программных документов
- •11.3Стандартизация программных документов
- •12Тестирование пс
- •12.1Аттестация пс
- •12.2Испытания пс
- •12.3Оценка пс
- •12.4Виды испытаний по
- •13Сертификация пс
- •13.1Правовые акты по сертификации программных продуктов
- •13.2Сертификация пс
- •13.3Перечень объектов, подлежащих сертификации и их характеристики
- •13.4Сертификационные испытания пс
1.13.2Классификация прототипов
Вслед за К. Вигерсом [10.2] рассмотрим следующие классификации прототипов:
горизонтальные и вертикальные;
одноразовые и эволюционные;
бумажные и электронные, раскадровки1).
Горизонтальный прототип
Горизонтальный или поведенческий прототип (horizontal prototype, behavioral prototype) моделирует интерфейс пользователя приложения, не затрагивая логику обработки и базу данных.
Если в разработанном интерфейсе используются фрагменты базы данных - они имитируются в программном коде. При этом тексты, отображаемые на экране, должны отражать реальную специфику проблемной области, иначе пользователю будет трудно сосредоточиться. Если при нажатии на элемент управления должны производиться какие-то расчеты или запросы во внешние системы - результаты запросов также имитируются. Желательно реализовать ту часть кода, которая отвечает за перемещение между экранами в процессе исполнения вариантов использования, чтобы пользователь смог понять, как будет действовать система в ответ на его действия.
Горизонтальные прототипы следует использовать для достижения цели прояснения неясных, либо многоальтернативных требований.
Вертикальный прототип
Вертикальный или структурный прототип (vertical prototype, structural prototype) не ограничивается интерфейсом пользователя. Он реализует вертикальный "срез" системы, затрагивая все уровни ее реализации. При создании такого рода прототипов рекомендуется использовать те языки и среды реализации, что и при изготовлении целевой системы (что, вообще говоря, совсем не обязательно для горизонтальных прототипов).
Основные цели применения такого рода прототипов - анализ применимости, проверка архитектурных концепций.
Одноразовый прототип
Одноразовый или исследовательский прототип (throwaway prototype, exploratory prototype) создается, когда нужно быстро промакетировать те или иные аспекты и компоненты системы.
Целям создания исследовательских прототипов служит технология RAD (rapid application development) - быстрая разработка приложений , см. лекцию 6.
Одноразовый прототип должен создаваться быстро. При его разработке не следует уделять внимание вопросам повторного использования кода, качества, быстродействия, технологичности и т.п.
В результате получается "сырой" код, который может содержать значительное количество дефектов. Необходимо принять меры к тому, чтобы фрагменты кода, реализующие такого рода прототипы, не стали частью целевой системы.
К. Вигерс приводит следующую схему перехода от одноразового прототипа к детально проработанному UI:
увеличить изображение Рис. 10.1.
На рисунке присутствует новое, не раскрытое ранее понятие: "карта диалога", говорят также "схема диалога". Прежде, чем создавать горизонтальный прототип, необходимо определиться - какие основные экраны будут присутствовать, какие окна будут открываться, какие правила перехода между ними будут поддерживаться. Информация такого рода хорошо ложится на модель диаграммы состояний, см. лекцию 9., где разным экранам (окнам) сопоставляются состояния, а активным элементам управления, вызывающим закрытие одних интерфейсных элементов и открытие других - переходы.
