作者：Мальцев Евгений 6 年以前
454
МиСПИСиТ-Тема2
Процесс проектирования автоматизированных систем требует тщательного анализа исходных данных и строгого соблюдения нормативных требований. Основные стандарты, такие как ГОСТ 34.601-90 и ГОСТ 34.
作者：Мальцев Евгений 6 年以前
454
更多类似内容
•ГОСТ 34.601 - 90. Информационная технология. Автоматизированные системы. Стадии создания.
•ГОСТ 34.602 - 89. Информационная технология. Техническое задание на создание автоматизированной системы.
• ГОСТ 19.201 - 78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.
1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять
стандартам, спецификациям или другим формальным документам;
3. Документированное представление условий или возможностей для пунктов 1 и 2.
•Требование – это условие или возможность, которой должна соответствовать система
•Требования – это исходные данные, на основании которых проектируются и создаются автоматизированные информационные системы
•Определение требований
•Требования к продукту и процессу
•Функциональные и нефункциональные требования
•Независимые свойства
•Требования с количественной оценкой
•Системные требования и программные требования.
•Основы требований
•Процесс
•Извлечение требований
•Анализ требований
•Спецификация требований
•Утверждение требований
•Практические соображения
•Что такое техническое задание (ТЗ) и для чего оно существует?
•Кто пишет ТЗ?
•Как ТЗ влияет на планирование и выполнение проекта?
•Как ТЗ влияет на формальную приемку проекта?
•Что такое требование к системе?
•Какие бывают виды требований?
Иллюстрированные сценарии прецедентов содержат дополнительные сведения - аспекты применимости, помогающие разработчику лучше понять специфику проблемной области.
В процессе выполнения прецедента менеджер по
приёму заказов выбирает заказчика из клиентской
базы, определяет товарные позиции из справочника
и указывает их количество. Система отображает на
мониторе наименование позиций, цену, сумму и
количество на складе. Менеджер назначает скидку и
определяет порядок оплаты. Система рассчитывает
итоговую сумму.
Аспект применимости - информация, позволяющая расширить описание прецедента описаниями, конкретизирующими те или иные его особенности и, в конечном итоге, повысить степень комфортности пользователя.
Виды аспектов применимости
Средняя интенсивность использования
Средняя интенсивность использования позволяет
выделить сценарии «массового» использования, в
которых всё должно быть идеально
(быстродействие, удобство пользования, минимум
действий на выполнение операций). Например –
интерфейс кассира в супермаркете.
Другая крайность – сценарии, выполняемые от
случая к случаю, не каждый день и не требующие
особой оперативности (например, расчёт заработной
платы за месяц). Эти данные позволяют,
структурировать подачу информации, убрать из
«главных» интерфейсов редко используемые опции и т.п.
Средние значения атрибутов и объемы объектов
Данная информация позволяет оптимальнее
построить пользовательский интерфейс и
оценить на ранних стадиях проекта «узкие
места» в обработке данных, которые могут
повлиять на производительность системы.
Ориентиры
Бумажный прототип - отличная альтернатива рассмотренным выше разновидностям электронных прототипов в случае, когда разработчик ограничен в ресурсах.
Его достоинства:
Эволюционный прототип создается, как первое приближение системы, призванное стать впоследствии самой системой.
Код эволюционного прототипа должен последовательно, в течение одной или более итераций, перерасти в код целевого приложения.
Поэтому данный вид прототипов требует всего того, от чего следует отказаться при создании одноразовых прототипов: скурпулезной разработки, применения технологических методов и приемов, тестирования результатов и т.п.
Одноразовый или исследовательский прототип создается, когда нужно быстро промакетировать те или иные аспекты и компоненты системы.
При его разработке не следует уделять внимание вопросам повторного использования кода, качества, быстродействия, технологичности и т.п.
В результате проучается "сырой" код, который может содержать значительное количество дефектов. Необходимо принеять меры к тому, чтобы фрагменты коды, реализующие такого рода прототипы, не стали частью целевой системы.
Вертикальный или структурный прототип не ограничивается интерфейсом пользователя, он реализует вертикальный "срез" системы, затрагивая все уровни ее реализации.
Основные цели применения такого рода прототипов - анализ применимости, проверка архитектурных концепций.
Горизонтальный или поведенческий прототип моделирует интерфейс пользователя приложения, не затрагивая логику обработки и базу данных.
Горизонтальные прототипы следует использовать для достижения цели прояснения неясных, либо многоальтернативных требований.
1.Введение
2.Позиционирование
3.Описания совладельцев и пользователей
4.Краткий обзор изделия
5.Возможности продукта
6.Ограничения
7.Показатели качества
8.Очередность и приоритеты
9.Другие требования к изделию
10.Требования к документации
11.Приложение.
Правила мозгового штурма предполагают полную раскрепощённость и свободу мнений, даже самых вычурных и на первый взгляд «бредовых». Первое правило мозгового штурма – «полный запрет на любую критику». Всякое высказанное мнение представляет ценность, а полное отсутствие запретов позволяет полноценным образом подключить творческую фантазию.
Затем, на втором этапе, все высказанные мнения тщательным образом обсуждаются, заведомо неприемлемые варианты отсеиваются, формируются коллективные предложения.
“Разъясняющие встречи” или “запланированный мозговой штурм” – термин, пришедший из общей практики менеджмента и базирующийся на идеях сотрудничества заинтересованных лиц для совместного анализа путей решения проблем, определения и предупреждения рисков и т.п.
