- •Вопрос 1 Разрабо́тка програ́ммного обеспе́чения
- •Разделы дисциплины
- •Понятия процесса и методология разработки
- •Вопрос 2
- •Вопрос 3
- •Виды требований по уровням
- •По характеру
- •Источники требований.
- •Вопрос 4 Какие должны быть требования, их характеристика:
- •Как выявляются требования
- •Вопрос 5 Проверка требований
- •Анализ требований
- •Документирование требований
- •Изменение требований
- •Вопрос 6 Проектирование программного обеспечения
- •Инженерия программного обеспечения
- •Вопрос 7 Тестирование
- •Критерии качества программных средств.
- •Вопрос 8 Классификация тестирование по
- •Вопрос 9 Уровни тестирования по
- •Вопрос 10 Статическое и динамическое тестирование
- •Регрессионное тестирование
- •Тестирование «белого ящика» и «чёрного ящика»
- •Покрытие кода
- •Вопрос 11 Качество исходного кода
- •Факторы качества
- •С точки зрения пользователя
- •Вопрос 12 Определение
- •Процессы жизненного цикла по
- •Вопрос 13 Основные процессы жизненного цикла
- •Приложения
- •Вопрос 14 Вспомогательные процессы жизненного цикла автоматизированной системы (ас)
- •Организационные процессы жизненного цикла ас.
- •Вопрос 15 Каскадная модель
- •Вопрос 16 Итеративная и инкрементальная модель – эволюционный подход
- •Вопрос 17 Спиральная модель
- •Вопрос 18 Общие требования к методологии и технологии
- •Вопрос 19
- •Вопрос 20
- •Вопрос 33 Определение
- •Основные элементы и понятия idef0
- •Построение модели
- •Вопрос 34 Предназначение idef3
- •Два типа диаграмм в idef3
- •Обозначение
- •Вопрос 35 er-диаграммы
- •Семантические модели данных
- •Основные понятия модели Entity-Relationship (Сущность-Связи)
Вопрос 3
Требования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению, в результате анализа требований.
Виды требований по уровням
Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).
Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario).
Функциональные требования — определяют «как» (Ошибка! Не как, а что - "define what a system is supposed to accomplish" (см. англ. статью Functional_requirement)) реализовать продукт. Описывается в системной спецификации (system requirement specification, SRS).
По характеру
Функциональный характер – это требования к системе.
Нефункциональный характер, это требования к системе, которые проистекают не из предметной области, не из среды, на которой пишем, а, например, из свойств автоматизируемого объекта (на станке с ЧПУ есть ограничение хода резца – 1 метр, например).
Системные требования: ограничения на программные интерфейсы, требования к атрибутам качества, применяемому оборудованию и ПО. Атрибут качества – это то, по чему оценивается качество.
Внешние и системные интерфейсы.
Ограничения.
Источники требований.
Нормативное обеспечение организации – документы.
Текущая организация деятельности объектов автоматизации. Пользователи захотят делать на компьютере все так же, как делали и без него (перекладывать бумажки на столе слева-направо).
Модели деятельности. Диаграммы бизнес-процессов.
Представление ожидания потребителей и пользователей. Пользователь может потребовать радио, встроенное в пылесос. Нужно учесть сложность изменения представления пользователя – например, представление пожилых людей изменить сложнее.
Журналы использования существующих программно-аппаратных систем. По ним можно определить нагрузку на систему, цикличность, можно определить какое понадобится железо.
Конкурирующие программные продукты.
Вопрос 4 Какие должны быть требования, их характеристика:
Единичность. Хорошее требование описывает только одну вещь.
Завершенность. Требование в одном месте описано и содержит всю необходимую информацию.
Последовательность. Требования не противоречат друг другу.
Атомарность. Требование не может быть разбито на ряд более детальных требований без потери завершенности или каких-либо других свойств.
Отслеживаемость. Требование полностью или хотя бы частично соответствует деловым нуждам. Не должно быть требований «с потолка снятых».
Актуальность. Требование до сих пор не устарело.
Выполнимость. Требование должно быть в принципе реализуемо.
Недвусмысленность. Требование должно быть определено
Кратко.
Не должно быть обращения к техническому жаргону.
Не должно быть скрытых формулировок. Когда выписываем требование, не нужно определять сущность.
Должно отражать объективные факты, а не чье-то мнение.
Однозначность, единственность интерпретации.
Утверждение при определении требований должно быть простым (не составным) и утверждение не должно быть неотрицательным.
Обязательность. Требование должно определять некоторый функционал, отсутствие которого приведет к неполноте решения. Необязательного требования быть не должно.
Проверяемость. Наличие требование может быть проверено.