Categorie: Tutti - требования - проектирование - система - разработка

da Мальцев Евгений mancano 6 anni

490

МиСПИСиТ-Тема2

Процесс проектирования автоматизированных систем требует тщательного анализа исходных данных и строгого соблюдения нормативных требований. Основные стандарты, такие как ГОСТ 34.601-90 и ГОСТ 34.

МиСПИСиТ-Тема2

Анализ исходных данных для проектирования

Требования

ГОСТ РФ

•ГОСТ 34.601 - 90. Информационная технология. Автоматизированные системы. Стадии создания.

•ГОСТ 34.602 - 89. Информационная технология. Техническое задание на создание автоматизированной системы.

• ГОСТ 19.201 - 78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.

Определение IEEE

1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей;

2. Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять

стандартам, спецификациям или другим формальным документам;

3. Документированное представление условий или возможностей для пунктов 1 и 2.

Как и кем используются требования
Требование к АИС

•Требование – это условие или возможность, которой должна соответствовать система

•Требования – это исходные данные, на основании которых проектируются и создаются автоматизированные информационные системы

Основы требований

•Определение требований

•Требования к продукту и процессу

•Функциональные и нефункциональные требования

•Независимые свойства

•Требования с количественной оценкой

•Системные требования и программные требования.

Основные области SWEBOOK

•Основы требований

•Процесс

•Извлечение требований

•Анализ требований

•Спецификация требований

•Утверждение требований

•Практические соображения

Анализ требований

•Что такое техническое задание (ТЗ) и для чего оно существует?

•Кто пишет ТЗ?

•Как ТЗ влияет на планирование и выполнение проекта?

•Как ТЗ влияет на формальную приемку проекта?

•Что такое требование к системе?

•Какие бывают виды требований?

Процесс требований

Иллюстрированные сценарии прецедентов

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


Прецедент с ориентиром

В процессе выполнения прецедента менеджер по

приёму заказов выбирает заказчика из клиентской

базы, определяет товарные позиции из справочника

и указывает их количество. Система отображает на

мониторе наименование позиций, цену, сумму и

количество на складе. Менеджер назначает скидку и

определяет порядок оплаты. Система рассчитывает

итоговую сумму.

Аспект применимости

Аспект применимости - информация, позволяющая расширить описание прецедента описаниями, конкретизирующими те или иные его особенности и, в конечном итоге, повысить степень комфортности пользователя.

Виды аспектов применимости

Средняя интенсивность использования

Средняя интенсивность использования позволяет

выделить сценарии «массового» использования, в

которых всё должно быть идеально

(быстродействие, удобство пользования, минимум

действий на выполнение операций). Например –

интерфейс кассира в супермаркете.

Другая крайность – сценарии, выполняемые от

случая к случаю, не каждый день и не требующие

особой оперативности (например, расчёт заработной

платы за месяц). Эти данные позволяют,

структурировать подачу информации, убрать из

«главных» интерфейсов редко используемые опции и т.п.

Средние значения атрибутов и объемы объектов

Данная информация позволяет оптимальнее

построить пользовательский интерфейс и

оценить на ранних стадиях проекта «узкие

места» в обработке данных, которые могут

повлиять на производительность системы.

Ориентиры

Виды прототипов
Бумажный прототип

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

Его достоинства:

  1. Заказчик не станет акцентировать внимание на цветовом решении, форме кнопок и т.п., отвлекаясь от анализа функциональности.
  2. Заказчик никогда не скажет, глядя на бумажный интерфейс: "Да вы, я вижу, уже создали системы на 85%! Давайте закончим ее в течение недели".
Эволюционный прототип

Эволюционный прототип создается, как первое приближение системы, призванное стать впоследствии самой системой.

Код эволюционного прототипа должен последовательно, в течение одной или более итераций, перерасти в код целевого приложения.

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


Одноразовый прототип

Одноразовый или исследовательский прототип создается, когда нужно быстро промакетировать те или иные аспекты и компоненты системы.

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

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

Вертикальный прототип

Вертикальный или структурный прототип не ограничивается интерфейсом пользователя, он реализует вертикальный "срез" системы, затрагивая все уровни ее реализации.

Основные цели применения такого рода прототипов - анализ применимости, проверка архитектурных концепций.

Горизонтальный прототип

Горизонтальный или поведенческий прототип моделирует интерфейс пользователя приложения, не затрагивая логику обработки и базу данных.

Горизонтальные прототипы следует использовать для достижения цели прояснения неясных, либо многоальтернативных требований.

Работа с требованиями


Шаблон документа "Vision" RUP

1.Введение

2.Позиционирование

3.Описания совладельцев и пользователей

4.Краткий обзор изделия

5.Возможности продукта

6.Ограничения

7.Показатели качества

8.Очередность и приоритеты

9.Другие требования к изделию

10.Требования к документации

11.Приложение.

Мозговой штурм

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


Затем, на втором этапе, все высказанные мнения тщательным образом обсуждаются, заведомо неприемлемые варианты отсеиваются, формируются коллективные предложения.

Разъясняющие встречи

“Разъясняющие встречи” или “запланированный мозговой штурм” – термин, пришедший из общей практики менеджмента и базирующийся на идеях сотрудничества заинтересованных лиц для совместного анализа путей решения проблем, определения и предупреждения рисков и т.п.