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

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

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

1.Введение2.Позиционирование3.Описания совладельцев и пользователей4.Краткий обзор изделия5.Возможности продукта6.Ограничения7.Показатели качества8.Очередность и приоритеты9.Другие требования к изделию10.Требования к документации11.Приложение.

Формирование виденияВыявление требованийКлассификация и специфицирование требованийРасширенный анализ требований (граф. моделирование и прототипирование)Документирование требованийПроверка требованийУправление требованиямиСовершенствование процесса работы с требованиями

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

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

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

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

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

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

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

ОриентирыСредние значения атрибутов и объемы объектовСредняя интенсивность использования

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

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

Средняя интенсивность использования позволяетвыделить сценарии «массового» использования, вкоторых всё должно быть идеально(быстродействие, удобство пользования, минимумдействий на выполнение операций). Например –интерфейс кассира в супермаркете.Другая крайность – сценарии, выполняемые отслучая к случаю, не каждый день и не требующиеособой оперативности (например, расчёт заработнойплаты за месяц). Эти данные позволяют,структурировать подачу информации, убрать из«главных» интерфейсов редко используемые опции и т.п.

В процессе выполнения прецедента менеджер поприёму заказов выбирает заказчика из клиентскойбазы, определяет товарные позиции из справочникаи указывает их количество. Система отображает намониторе наименование позиций, цену, сумму иколичество на складе. Менеджер назначает скидку иопределяет порядок оплаты. Система рассчитываетитоговую сумму.

•Что такое техническое задание (ТЗ) и для чего оно существует?•Кто пишет ТЗ?•Как ТЗ влияет на планирование и выполнение проекта?•Как ТЗ влияет на формальную приемку проекта?•Что такое требование к системе?•Какие бывают виды требований?

•Основы требований•Процесс•Извлечение требований•Анализ требований•Спецификация требований•Утверждение требований•Практические соображения

•Определение требований•Требования к продукту и процессу•Функциональные и нефункциональные требования•Независимые свойства•Требования с количественной оценкой•Системные требования и программные требования.

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

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

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

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