Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






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






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

— интервьюирования и анкетирования — создание структурированного интервью; проведение интервью с 5—15 пользователями и/или заинтересованными лицами; подведение итогов совокупности интервью, формулирование 10—15 наиболее часто упоминавшихся потребностей заказчика и пользователей;

— совещания, посвященные анализу и синтезу требований — формулирование и определение целей программного продукта; ознакомление с ними всех участников проекта и установление, что они с ними согласны; если это не так, следует остановиться и уточнениями добиться согласия; обязательно убедиться в согласии заказчиков;

— мозговой штурм и отбор идей, чтобы: выявить и/или уточнить функции проекта; отсечь нецелесообразные идеи; провести классификацию функций, чтобы определить приоритеты, риски, трудоемкости реализации функций;

— анализ иллюстративных прецедентов в приложении к концепции требований (или системному проекту), чтобы их функции были наглядны и понятны;

— по возможности выявление или создание временных прототипов на основе первичных требований.

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

В требованиях к ПС следует указывать, какие функции должны осуществляться, а не то, как они могут реализоваться

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

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






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.