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

admin

Содержание:

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

FAU: Аудит безопасности

Автоматическая реакция аудита безопасности (FAU_ARP)

Сигналы нарушения безопасности (FAU_ARP.1)

Генерация данных аудита безопасности (FAU_GEN)

Генерация данных аудита (FAU_GEN.1)

Ассоциация идентификатора пользователя (FAU_GEN.2)

Просмотр аудита безопасности (FAU_SAR)

Просмотр аудита (FAU_SAR.1)

Ограниченный просмотр аудита (FAU_SAR.2)

Выборочный просмотр аудита (FAU_SAR.3)

Выбор событий аудита безопасности (FAU_SEL)

Избирательный аудит (FAU_SEL.1)

Хранение данных аудита безопасности (FAU_STG)

Защищенное хранение журнала аудита (FAU_STG.1)

Предотвращение потери данных аудита (FAU_STG.4)

FCS: Криптографическая поддержка

Управление криптографическими ключами (FCS_CKM)

Генерация криптографических ключей (FCS_CKM.1)

Распределение криптографических ключей (FCS_CKM.2)

Доступ к криптографическим ключам (FCS_CKM.3)

Уничтожение криптографических ключей (FCS_CKM.4)

Криптографические операции (FCS_COP)

Криптографические операции (FCS_COP.1)

FDP: Защита данных пользователя

Политика управления доступом (FDP_ACC)

Полное управление доступом (FDP_ACC.2)

Функции управления доступом (FDP_ACF)

Управление доступом, основанное на атрибутах безопасности (FDP_ACF.1)

Экспорт данных за пределы действия ФБО (FDP_ETC)

Экспорт данных пользователя с атрибутами безопасности (FDP_ETC.2)

Экспорт данных за пределы действия ФБО (FDP_ETC)

Экспорт данных пользователя с атрибутами безопасности (FDP_ETC.2)

Политика управления информационными потоками (FDP_IFC)

Полное управление информационными потоками (FDP_IFC.2)

Функции управления информационными потоками (FDP_IFF)

Иерархические атрибуты безопасности (FDP_IFF.2)

Продолжение таблицы 2.4.1

Импорт данных из-за пределов действия ФБО (FDP_ITC)

Импорт данных пользователя без атрибутов безопасности (FDP_ITC.1)

Импорт данных пользователя с атрибутами безопасности (FDP_ITC.2)

Передача в пределах ОО (FDP_ITT)

Базовая защита внутренней передачи (FDP_ITT.1)

Защита остаточной информации (FDP_RIP)

Полная защита остаточной информации (FDP_RIP.2)

FIA: Идентификация и аутентификация

Отказы аутентификации (FIA_AFL)

Обработка отказов аутентификации (FIA_AFL.1)

Определение атрибутов пользователя (FIA_ATD)

Определение атрибутов пользователя (FIA_ATD.1)

Спецификация секретов (FIA_SOS)

Верификация секретов (FIA_SOS.1)

Аутентификация пользователя (FIA_UAU)

Выбор момента аутентификации (FIA_UAU.1)

Аутентификация с защищенной обратной связью (FIA_UAU.7)

Идентификация пользователя (FIA_UID)

Выбор момента идентификации (FIA_UID.1)

Связывание пользователь-субъект (FIA_USB)

Связывание пользователь-субъект (FIA_USB.1)

FMT: Управление безопасностью

Управление отдельными функциями ФБО (FMT_MOF)

Управление режимом выполнения функций безопасности (FMT_MOF.1)

Управление атрибутами безопасности (FMT_MSA)

Управление атрибутами безопасности (FMT_MSA.1)

Безопасные значения атрибутов безопасности (FMT_MSA.2)

Инициализация статических атрибутов (FMT_MSA.3)

Управление данными ФБО (FMT_MTD)

Управление данными ФБО (FMT_MTD.1)

Срок действия атрибута безопасности (FMT_SAE)

Ограниченная по времени авторизация (FMT_SAE.1)

Роли управления безопасностью (FMT_SMR)

Роли безопасности (FMT_SMR.1)

Принятие ролей (FMT_SMR.3)

Тестирование базовой абстрактной машины (FPT_AMT)

Тестирование абстрактной машины (FPT_AMT.1)

Передача данных ФБО в пределах ОО (FPT_ITT)

Базовая защита внутренней передачи данных ФБО (FPT_ITT.1)

Продолжение таблицы 2.4.1

Мониторинг целостности данных ФБО (FPT_ITT.3)

Надежное восстановление (FPT_RCV)

Ручное восстановление (FPT_RCV.1)

Посредничество при обращениях (FPT_RVM)

Невозможность обхода ПБО (FPT_RVM.1)

Разделение домена (FPT_SEP)

Отделение домена ФБО (FPT_SEP.1)

Метки времени (FPT_STM)

Надежные метки времени (FPT_STM.1)

Согласованность данных ФБО между ФБО (FPT_TDC)

Базовая согласованность данных ФБО между ФБО (FPT_TDC.1)

Согласованность данных ФБО при дублировании в пределах ОО (FPT_TRC)

Согласованность дублируемых данных ФБО (FPT_TRC.1)

Самотестирование ФБО (FPT_TST)

Тестирование ФБО (FPT_TST.1)

FRU: Использование ресурсов

Распределение ресурсов (FRU_RSA)

Максимальные квоты (FRU_RSA.1)

FTA: Доступ к ОО

Блокирование сеанса (FTA_SSL)

Блокирование сеанса, инициированное ФБО (FTA_SSL.1)

WEB за чашечкой кофе

Навигация по записям

Какие требования бывают

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

Бизнес-требования(business requirements)

Бизнес-требования(business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

Требования пользователей (user requirements)

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.

Функциональные требования (functional requirements)

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные вход­ные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых слу­чаях указывается, что система не должна делать.

Эти требования описывают поведение системы и сервисы (функции), которые она выполняет, и зависят от типа разрабатываемой системы и от потребностей пользовате­лей. Если функциональные требования оформлены как пользовательские, они, как прави­ло, описывают системы в обобщенном виде. В противоположность этому функциональ­ные требования, оформленные как системные, описывают систему максимально подроб­но, включая ее входные и выходные данные, исключения и т.д.

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

1. Пользователь должен иметь возможность проводить поиск необходимых ему книг и документов или по всему множеству доступных каталожных баз данных или по определенному их подмножеству.

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

3. Каждый заказ должен быть снабжен уникальным идентификатором (ORDER_ID), который копируется в формуляр пользователя для постоянного хранения.

Эти функциональные пользовательские требования определяют свойства, которыми должна обладать система. Они взяты из документа, содержащего пользовательские требо­вания, и показывают, что функциональные требования могут быть описаны с разным уровнем детализации (сравните первое и третье требования).

Многие проблемы, возникающие при разработке систем, связаны с неточностью и «размытостью» спецификации требований. Естественно, разработчики интерпретируют требования, допускающие двоякое толкование, так, чтобы систему было проще реализо­вать. Но это толкование может не совпадать с ожиданиями заказчика. Такая ситуация приводит к разработке новых требований и внесению изменений в систему. Это, в свою очередь, ведет к задержке сдачи готовой системы и ее удорожанию.

Другие публикации:  Лицензия на холодное оружие россия

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

Системные требования (system requirements)

Системные требования (system requirements) — это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.

Бизнес-правила (business rules)

Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные ВИ, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

Характеристика продукта (feature)

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

Какими характеристиками должны обладать хорошие требования?

Характеристики качества превосходных требований:

— Полнота. Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработчиков, чтобы тем удалось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку «TBD» (to be determined — необходимо определить) на полях как стан-
дартный флаг для выделения такого места. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструированию этой функции.

— Корректность. Каждое требование должно точно описывать желаемую функциональность. Для соблюдения корректности необходима связь с источниками требований, например с пожеланиями пользователей или высокоуровневыми системными. Требования к ПО, которые конфликтуют с родительскими требованиями, нельзя считать корректными. Однако основная оценка здесь— за представителями пользователей, вот почему им или их непосредственным заместителям необходимо предоставлять требования для просмотра.

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

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

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

— Однозначность. Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям. «Ясность»— цель качества требований, связанная с точностью: читатели должны четко понимать каждое положение. Занесите все специальные и запутанные термины в словарь.

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

Какие бывают требования?

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

Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

Системные требования (system requirements) — это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.

Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные ВИ, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.

Другие публикации:  Исковое заявление об отсрочке долга

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

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

АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

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

Функциональные требования описывают сервисы, предоставляемые программной системой, ее поведение в определенных ситуациях, реакцию на те или иные входные данные и действия, которые система позволит выполнять пользователям. Иногда сюда добавляются сведения о том, чего система делать не должна [37, 61].

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

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

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

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

Функциональная спецификация состоит из трех частей:

  • 1. Описание внешней информационной среды, с которой будет взаимодействовать разрабатываемое программное обеспечение. Должны быть определены все используемые каналы ввода и вывода и все информационные объекты, к которым будет применяться разрабатываемое ПС, а также существенные связи между этими информационными объектами.
  • 2. Определение функций программного обеспечения, определенных на множестве состояний этой информационной среды. Вводятся обозначения всех определяемых функций, специфицируются их входные данные и результаты выполнения, с указанием типов данных и заданий всех ограничений, которым должны удовлетворять эти данные и результаты. Определяется содержание каждой из этих функций.
  • 3. Описание исключительных ситуаций, если таковые могут возникнуть при выполнении программ, и реакций на эти ситуации, которые должны обеспечить соответствующие программы. Должны быть перечислены все существенные случаи, когда программное обеспечение не сможет нормально выполнить ту или иную свою функцию. Для каждого такого случая должна быть определена реакция программы.

Функциональные обязанности системного администратора

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

Как появилась данная профессия…

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

Сегодня такая классификация абсолютно неадекватна, так как даже ребенок может разобраться в простейших программах. На первую ступень важных характеристик вместо простого понимания процессов вышло умение ими пользоваться и управлять так, чтобы компания, в которой трудится специалист, была полностью уверенна, что вся информация, которая хранится в электронном формате, будет сохранена и конфиденциальна. Хорошего системного администратора можно сравнить с дирижером, который так должен настроить свой оркестр (то есть компьютерную сеть предприятия или фирмы и ее технику), чтобы никаких сбоев в звучании и работе просто не могло быть.

Обязанности системного администратора – разбираемся поэтапно

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

В обязанности системного администратора включают множество заданий, самыми главными из которых являются:

  • обслуживание, установка и переустановка офисной оргтехники, обеспечение ее высокопродуктивной деятельности;
  • поиск хорошего программного обеспечения, его установка, корректировка его деятельности;
  • обеспечение постоянной бесперебойной работы сети компании, гарантирование конфиденциальности данных;
  • копирование данных (резервное);
  • быстрое и полное восстановление данных при потери части или всей информации по вине любого из сотрудников;
  • помощь пользователям-работникам компании, для которых компьютер или другая оргтехника – сложны для понимания (здесь очень важен человеческий фактор, такие обязанности системного администратора должны выполняться спокойно и максимально доходчиво для пользователя);
  • формирование отчетной документации для руководства.
Другие публикации:  Цена подать заявление на развод

Первые требования, которые будут предъявлены претенденту на такую должность

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

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

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

Без образования сегодня – никуда

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

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

Большие города – вот где нужно искать работу сисадминам

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

Сегодня сисадмины нужны и в больницах…

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

Большие перспективы

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

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

Авторы: Алфимов Р.В., Красникова С.А., Золотухина Е.Б. (сертифицированный специалист по решениям IBM Rational, преподаватель в Учебно-Консалтинговом центре компании «Интерфейс»).

Значительной популярностью при разработке автоматизированных систем в настоящее время в России пользуется универсальный язык моделирования (Unified Modeling Language — UML). Несмотря на безусловные плюсы, использование UML сопряжено с рядом трудностей методического характера, на которые мы хотели бы обратить внимание читателя. Прежде всего, в UML вводится собственный понятийный аппарат, в рамках которого традиционные термины и понятия, связанные с созданием автоматизированных систем и используемые в течение десятилетий, заменяются на термины и понятия, не нашедшие пока в полной мере отражения в международных и отечественных стандартах в области информационных технологий.

Особенно это касается базового элемента языка UML «Use Case», который трактуется отечественными переводчиками как «вариант использования», «прецедент». При этом контекст, в котором переводится термин, не учитывается. Несмотря на то, что понятие активно используется уже довольно давно — путаницы возникает все больше и больше. Так, участники некоторых Интернет- форумов дошли до того, что сравнивают «Use Case» с техническим заданием. По мнению авторов, все это обусловлено стандартным описанием UML, не связанным с процессом разработки автоматизированных систем (АС), а также упущенной возможностью при переводе оригинала такое сопоставление произвести. К тому же существующие современные методики создания программных систем от ведущих мировых производителей, основанных на использовании UML и других нотациях, к сожалению, большинству отечественных разработчиков в оригинале просто не доступны.

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

В данной статье представлен способ описания функциональных требований к АС и ее функций с использованием стандартов в области информационных технологий, современных методологий создания АС, и диаграмм «Use Case Diagram» и «Actvity Diagram» универсального языка моделирования UML 2.0. Авторы рассчитывают, что использование «Use Case» в контексте определения требований в соответствии со стандартами создания АС приобретет большую ясность.

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

При использовании стандартов создания АС в соответствии с [1, 2] на стадии «Техническое задание» в документе техническое задание (ТЗ) фиксируются функциональные и нефункциональные требования к АС. Схема функциональной структуры АС разрабатывается на стадии «Эскизное проектирование» и «Техническое проектирование», описание автоматизируемых функций АС производится на стадии «Техническое проектирование».

При разработке АС в соответствии с [1] должны быть отслежены связи между функциональными требованиями к системе и функциями системы, их реализующими. Функции системы в свою очередь должны быть детально описаны.

В табл. 1. представлены стадии работ по созданию АС и документы, формируемыми на стадиях, связанных с описанием требований и функций [1-3].

Как видно из табл. 1, создание АС на стадиях 3-5, подразумевает подготовку:

Страница не найдена

Возможно она была удалена из-за нарушения авторских прав или же не имела веса. Воспользуйтесь поиском google:

А также прочитайте САМЫЕ ЛУЧШИЕ ИЗРЕЧЕНИЯ СТУДЕНТОВ — уверяем вам они понравятся!

Или же прочитайте самые посещаемые страницы нашего сайта:

185.238.139.36 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)
очень нужно