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

Определение требований к системе

Читайте также:
  1. A. Определение элементов операций в пользу мира
  2. I. Определение потенциального валового дохода.
  3. II. Определение геометрических размеров двигателя
  4. II.ОПРЕДЕЛЕНИЕ ПРОИЗВОДИТЕЛЬНОСТИ ЛА
  5. P.2.3.2.1(с) Определение удельной теплоемкости твердых тел
  6. Анализ соблюдения требований производственной санитарии.
  7. Антропогенез. Положение человека в общей системе природы. Черты, доказывающие принадлежность человека к каждой систематической группе.
  8. Б) Определение жёсткости
  9. в системе образования Беларуси
  10. В системе психологического научного знания
  11. В) Определение объема движений
  12. В) Определение щёлочности.

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

Имеются 3 класса:

1. Управляемая пользователем – требования к системе непосредственно разрабатываются организацией пользователя.

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

3. Не зависящая от пользователя – вся ответственность ложится на разработчика. Разрабатывается небольшой группой: представитель заказчика который может принимать решения (обычно он не является пользователем системы), человек, который будет пользователем системы и обладает достаточным опытом в своей области. От организации разработчика: специалисты, которые отвечают за внешнее и внутренне проектирование. Хотя бы один человек, который обладает опытом взаимодействия с заказчиками.

 

Цели.

Конкретные ориентиры, которые необходимо достичь при проектировании программного продукта. Это процесс принятия различных компонентных решений. Существует, как правило, 2 набора целей: цели продукта (которые надо достичь с точки зрения пользователя) и цели проекта (относятся к самому проекту: график работ, стоимость этапов, степень тестируемости и т. д.)

Цели продукта:

1) Резюме: назначение разрабатываемого продукта

2) Определение пользователя

3) Публикация – необходимо разработать документацию для определенных групп пользователей

4) Эффективность системы – пропускная способность, временные характеристики, использование ресурсов

5) Совместимость с другими продуктами

6) Конфигурации – указываются различные конфигурации аппаратуры ПО, на которых система может работать, и другие продукты, от которых она будет зависеть

7) Безопасность

8) Обслуживание – намечается стоимость и время исправления ошибок

9) Установка – описываются методы и средства настройки системы на конкретные условия эксплуатации

10) Надежность – среднее время между отказами, примерное количество ошибок, должны быть описаны последствия отказов, допустимый объем данных, утрачиваемых в случае отказа, жизненно важная информация, функции для обнаружения и исправления ошибок.

Внешнее проектирование – процесс описания поведения системы с точки зрения внешнего по отношению к этой системе наблюдателя. Т. е. внимания внутренней архитектуре, данным, алгоритмам не уделяется, интересует внешний вид программы и ее реакции.

Цель этого процесса – конструирование внешнего взаимодействия будущего продукта без конкретизации внутреннего устройства. Результат – внешние спецификации.

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

Концептуальная целостность представляет собой меру единообразия взаимодействия пользователя с системой.

Как правило, ответственность за внешнее проектирование несут 1-2 человека: системный аналитик и специалист по интерфейсам.

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

Как правило, делается:

1. Предварительное внешнее проектирование – определяются все функции для пользователя, но их точные синтаксис, семантика и результаты остаются неопределенными

2. Детальное внешнее проектирование более подробно определяют и описывают:

а) описание входных выходных данных

б) преобразование системы

в) характеристики надежности

г) эффективность

д) замечания по программированию

Многие функции могут не только порождать какие-то конкретные данные, но и изменять состояние системы. Такие преобразования должны быть описаны с точки зрения пользователя. Это могут быть логи или что-то другое.

Надежность – описание возможных воздействий отказов системы на саму систему и файл.


1 | 2 | 3 | 4 | 5 |

Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.004 сек.)