extracted_text:
2.
РАЗРАБОТКА И АНАЛИЗ ТРЕБОВАНИЙ  К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
2.1. Введение в анализ требований
Получение корректных требований для разработки программного
продукта — довольно сложный процесс. Большинство недостатков, найденных в готовом
программном обеспечении, возникло на стадии анализа требований. Практика показывает,
что обычно такие недостатки труднее всего исправить.
Результатом анализа требований является
документ, который обычно называют спецификацией требований или спецификацией
требований к программному обеспечению (SRS — Software Requirements
Specification).
Требования к программному обеспечению — совокупность
утверждений относительно атрибутов, свойств или качеств программной системы (ПС),
подлежащей реализации.
Этапы сбора и анализа требований
Процесс работы с требованиями к продукту
можно разделить на 4 этапа:
•      определение
концепции продукта;
•      сбор
требований;
•      анализ
требований;
•      проектирование
системы.
Определение концепции продукта
Конце́пция (от лат. conceptio — понимание,
система) — определённый способ понимания, трактовки каких-либо явлений, основная
точка зрения. На этапе определения концепции продукта проводится работа с его заказчиком
(инвестором), целью которой является выработка единого видения будущего программного
продукта. По окончании этого этапа производится вывод о том, будет ли этот продукт
разрабатываться или нет.
Сбор требований
На этапе сбора требований основная работа ведется с заказчиком
системы и её будущими пользователями. Цель этапа — точно определить функции продукта
и способы его интеграции в существующие процессы.
Качественное выполнение работ на этом этапе гарантирует
то, что будущий продукт будет соответствовать ожиданиям заказчика. Четкая расстановка
приоритетов обеспечивает реализацию наиболее востребованной функциональности и исключение
второстепенной/невостребованной функциональности, что сэкономит бюджет проекта и
время на разработку.
Анализ требований
На этапе анализа требований проходит структуризация уже
собранных ранее требований. Цель этапа — предоставить четкий список не дублируемых
требований к системе, которые должны быть выделены из избыточных и частично дублирующихся
сценариев и пользовательских историй, которые были получены на предыдущем этапе.

Правильно сгруппированные требования помогут обойтись
минимальным количеством функционала для удовлетворения максимально большего количества
целей.
Проектирование системы
Целью всех предыдущих этапов был сбор информации о том,
кому и зачем необходим будущий продукт. Этап проектирования — это первый этап, на
котором группа разработчиков принимает проектные решения о том, какую функциональность
будет нести продукт, чтобы удовлетворить пользователей.
Результатом этого этапа является законченное техническое
задание к продукту. Оно должно содержать полное описание поведения будущего продукта
и не содержать неоднозначностей и вопросов.
На основе технического задания начинается моделирование
работы программного продукта (ПП) с конечными пользователями (в качестве примера
могут использоваться макеты пользовательского интерфейса) и производится тестирование
технического задания. Это позволяет повысить качество продукта и снизить его стоимость,
так как стоимость внесения изменений в техническое задание всегда меньше, чем в
конечный продукт.
Каждый из четырех вышеперечисленных этапов проводится
на разных уровнях, а потому имеет различную степень влияния на характеристики будущего
продукта.
В таблице 2.1 приводится влияние каждого из этапов работы
с требованиями на характеристики конечного продукта. В зависимости от того, какие
характеристики продукта важнее, можно определить, на какой этап потратить больше
времени.
Таблица 2.1 Влияние качества работ на характеристики конечного продукта

Этап

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

Разработка концепции

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

Сбор требований

Качество — соответствие
  продукта ожиданиям заказчика. Срок вывода на рынок и ориентировочный бюджет продукта

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

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

Проектирование системы

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

С-требования и D-требования
В течение некоторого времени среди программистов проходили
споры относительно того, кому «принадлежат» требования: заказчику или разработчикам.
Для решения этого вопроса анализ требований разделили на два уровня.
Первый уровень документирует желания и
потребности заказчика и пишется на языке, понятном заказчику. Результаты иногда
называют требованиями заказника, С-требованиями (customer). Первичной аудиторией
для С-требований будет сообщество заказчиков, а уже вторичной — сообщество разработчиков.

Второй уровень документирует требования в специальной,
структурированной форме. Эти документы называются требованиями разработчика или
D-требованиями (detail). Первичной аудиторией для D-требований будет сообщество
разработчиков, а уже вторичной — сообщество заказчиков.
Требования оформляются таким образом, что каждое из них
должно быть:
•   четко выражено;

•   легко доступно;

•   пронумеровано;
•   сопровождаться подтверждающими
тестами;
•   предусматриваться
проектом;
•   учтено кодом;
•   протестировано отдельно;

•   протестировано совместно
с другими требованиями;
•   подтверждено тестированием
после того, как выполнена сборка приложения.
Также должно быть указано время, необходимое для выполнения
каждого из этих шагов.
Источником возникновения требований является взаимодействие
с людьми, заинтересованными в данном программном продукте.
2.2. Описание С-требований (требований заказчика)
Перед проектированием ПП необходимо четко сформулировать,
что хотят заказчики и что они ожидают получить.
Заказчики разрабатывают концепцию — часто подсознательную
и непонятную полностью в том, как их приложение будет работать. Эту концепцию иногда
называют моделью приложения или концепцией работы. Разные люди обычно имеют различные
представления о программном продукте.
Например, возможным представлением о работе бюро погоды
может быть следующее:
•   средство для преобразования
необработанных материалов метеоцентра в графическое представление;
•   система реального
времени для предсказания погоды;
•   приложение, предупреждающее
пользователей о погодных аномалиях.
Эти различные представления о работе программного продукта
приведут к совершенно разным программным приложениям.
Менеджер проекта или разработчик требований помогают заказчику
четко сформулировать его концепцию работы. Поскольку обычно заказчики не владеют
технологией выражения таких концепций, инженеры могут предложить подходящие технологии,
такие как варианты использования, потоки данных или переходы состояний.
Ведущую роль в разработке концепции ведет бизнес
аналитик (или Program/Product Manager), занимающийся этим продуктом.
Для определения потребностей заказчика/рынка на весь срок разработки концепции проводится
интенсивная работа с инвестором проекта. Цель — выработка единого видения будущего
продукта. Если это заказной продукт, то инвестором является конечный заказчик. Если
продукт предназначен для открытого рынка, то ответственными за него являются учредители
компании или совет директоров. Далее на основе изученных и систематизированных требований
аналитик вместе с командой экспертов создают образ будущего продукта. В заключение
аналитик с экспертной командой определяют границы проекта, которые должны содержать
ориентировочные сроки и бюджет продукта. На рисунке 2.1 показаны этапы разработки
концепции продукта.

Рис. 2.1
Этапы разработки концепции продукта
Результатом разработки концепции является PVD (Product
Vision Document — документ образа продукта, если продукт разрабатывается
под заказ) или MRD (Marketing Requirement Document — документ рыночных требований,
если продукт предназначен для открытого рынка). Эти документы содержат подробную
информацию о требованиях заказчика, возможностях продукта, которые должны удовлетворять
эти требования, а также ориентировочные сроки его реализации и бюджет. Различием
между PVD и MRD является то, что в MRD обычно более детально описаны целевые сегменты
рынка и сделан детальный обзор конкурентов.
По окончании разработки концепции продукта делается вывод
о целесообразности разработки ПП.
Сбор и анализ бизнес-требований
Первым и самым важным этапом в разработке продукта является
сбор бизнес-требований. Цель этой работы — определить основные требования бизнеса
(исходные данные, истинные цели, которым должен служить продукт, и проблемы, которые
нужно преодолеть).
Для продуктов под заказ и продуктов для открытого рынка
процесс сбора бизнес-требований существенно различается.
Продукт под заказ — заказчик определен с
самого начала, ему известны начальные предпосылки (стимулы) для инициации проекта
и проблемы, которые продукт должен решать. В связи с этим сбор требований начинается
с определения исходных предпосылок, целей продукта и описания сценариев работы пользователей
с будущим продуктом. Анализ конкурентных продуктов, которые могут удовлетворять
схожие сценарии, делается в самом конце
(табл. 2.2).
Таблица 2.2
Последовательность задач, выполняемых на этапе сбора бизнес-требований

Продукт под заказ

Продукт для открытого рынка

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

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

Продукт для открытого рынка — сектор рынка
с самого начала может быть не определен, а цели продукта основываются на конкурентном
анализе.
В результате сразу за определением исходных предпосылок
(стимулов) идет обзор конкурентов, далее идет определение целевого сегмента рынка
и потребностей его заказчиков и только после этого определяются цели продукта и
критерии его успеха.
Причиной создания программного продукта
может быть следующее:
•   потребность рынка;

•   производственная
необходимость;
•   потребность заказчика;

•   технический прогресс;

•   юридические ограничения
или нормы.
Одной из задач является определение одной или нескольких
целей, которые преследуют заинтересованные стороны при разработке продукта. Необходимо
описать основные преимущества, которые предоставит продукт для бизнеса. Сделать
это надо в измеряемом виде. Также нужно определить механизм, используя который,
заинтересованные люди будут измерять успех продукта в конечном итоге.
Например, финансовые:
•   освоить Х%
рынка за Y месяцев;
•   увеличить сектор
рынка в стране X на Y% за Z месяцев;
•   достигнуть объема
продаж X единиц или дохода, равного $Y, за Z месяцев;
•   получить Х%
прибыли или дохода по инвестициям в течение Y меся-
цев;
•   достигнуть положительного
баланса по этому продукту в течение Y месяцев;
•   сэкономить $Х
в год, которые в настоящий момент расходуются на обслуживание системы;
•   уменьшить затраты
на поддержку на Х% за Z месяцев;
•   увеличить валовую
прибыль для существующего бизнеса с Х до Y%;
•   и другое.
Нефинансовые:
•   достигнуть показателя
удовлетворения покупателей, равного X, в течение Y месяцев со времени
выпуска товара;
•   увеличить производительность
обработки транзакций на Х% и снизить уровень ошибок данных до величины не
более Y%;
•   достигнуть определенного
времени для достижения доминирующего положения на рынке;
•   разработать надежную
платформу для «семьи» связанных продуктов;
•   разработать специальную
базовую технологическую основу для организации;
•   получить X
положительных отзывов в отраслевых журналах к определенной дате;
•   добиться признания
продукта лучшим по надежности в опубликованных обзорах продуктов к определенной
дате;
•   соответствовать
определенным федеральным и государственным постановлениям;
•   и другое.
Определение целевого сегмента рынка требуется только для
продуктов, ориентированных на широкий рынок. Принято сегментировать рынок следующим
образом.
Рынок домашних пользователей (может быть также
разделен на обычных и квалифицированных пользователей).
Рынок корпоративных
пользователей:
1.  SMB
(Small and Medium Business) — компании, насчитывающие от 1 до 250 сотрудников.
Также может быть разделен на Micro (или Soho) — 1– 10 сотрудников, Small
— 10–25 — и Medium — 25–250.
2.  Large
— компании, насчитывающие 250–2500 сотрудников.
3.  Corporation
— корпорации с числом сотрудников более 2500.
Это разделение принято использовать в связи с тем, что
требования, налагаемые пользователями, которые принадлежат к разным сегментам рынка,
кардинально отличаются. Это касается как функциональности, способов администрирования,
так и вопросов лицензирования и поддержки продукта. Практически невозможно создать
продукт, который бы подошел одновременно домашним пользователям имог бы эксплуатироваться
в крупной компании.
Для того чтобы правильно выбрать сегмент рынка, необходимо
определить требования, налагаемые каждым из сегментов рынка с учетом предметной
области продукта.
При выборе сегмента рынка следует определить требования,
продиктованные каждым из сегментов к продукту. Выбор целевого сегмента должен основываться
на возможностях: бюджете проекта, квалификации аналитиков и разработчиков, наличии
возможностей для продвижения продукта.
После определения целевого сегмента определяются проблемы,
которые будут решаться при помощи будущего ПП.
Создание сценариев
Наиболее эффективным способом получения ответа на многие
вопросы является определение сценариев работы пользователей с будущим продуктом.
Сценарий — это совокупность всех процессов, в которых будет участвовать продукт,
а также описание окружения, в котором его планируется использовать. Сценарий не
должен являться описанием работы отдельного пользователя для достижения конкретной
цели. Его ценность состоит в том, что он описывает способы взаимодействия с продуктом
всех его пользователей одновременно на протяжении всего цикла эксплуатации продукта.
Таким образом, сценарий гарантирует отсутствие взаимоисключающих требований к продукту
и дает возможность убедиться, что ничто не забыто. Для проверки сценария надо всего
лишь проанализировать его выполнение всеми заинтересованными лицами (проиграть его).

Для продуктов под заказ сценарии использования продукта
формируются самим заказчиком. Как правило, сколько заказчиков, столько и сценариев.
Наиболее эффективным методом является живой диалог с заказчиком, в котором аналитик
задает наводящие вопросы, а заказчик отвечает на них. Если личный контакт невозможен,
то используют вопросники, содержащие «нужные» вопросы, по которым заказчику легче
будет написать сценарий.
Для открытого рынка сначала определяются профили будущих
клиентов продукта, а затем для каждого из них создается подробный сценарий его использования.
Аналитик может описывать сценарии самостоятельно, используя информацию из личного
опыта или открытых источников. Другой вариант — найти клиентов или компании, подходящие
под ранее определенные профили, и получить сценарии непосредственно от них.
Важно не путать понятия клиента и пользователя. Клиентом
может являться компания, в которой множество сотрудников будут являться пользователями
системы. В таком случае профиль клиента описывает характерные черты и проблемы компании,
а профиль пользователя (описываемый позднее) — характеристики её сотрудников.
Благодаря использованию сценариев, основное внимание уделяется
реальным потребностям конкретных пользователей системы, и лишь потом определяется
необходимый функционал продукта. Каждый сценарий содержит все процессы, в которыхпланируется
использовать продукт.
Каждый сценарий должен содержать:
•
имя конкретного заказчика или его профиль (в качестве заголовка);

•
информацию обо всех типах пользователей, которые будут работать с
продуктом;
•
все процессы, которые будут затрагивать продукт;
•
операционную среду, в которой будет использоваться продукт;
•
требования к дизайну: операционную систему, приложения, с которыми
интегрируется, форматы ввода-вывода;
•
приоритет. Зависит от того, насколько важен этот заказчик или как
много покупателей будут попадать под профиль клиента, описанного в сценарии.
Определение функциональных требований и требований
к дизайну
После сбора всей информации от пользователей необходимо
ее систематизировать.
Сценарии избыточны. Они содержат большое количество повторений
или дополнений. В процессе выделения требований должен быть создан список уникальных
требований к продукту, которые не должны повторяться, но могут дополнять друг друга.
Необходимо выделить два типа требований: функциональные бизнес-требования и требования
к дизайну (нефункциональные требования).
Функциональные бизнес-требования описывают потребность
(заказчика/покупателя), которую должен удовлетворить будущий продукт. Основной вопрос,
на который должны отвечать бизнес-требования, — зачем нужна та или иная функциональность.

Требования к дизайну описывают операционную среду,
в которой будет функционировать продукт, интерфейсы взаимодействия с пользователем
или другими системами, форматы хранения и передачи данных, а также требования к
надежности, производительности, обслуживанию и доступности системы. Эти требования
в значительной степени влияют на средства разработки, архитектуру и используемые
технологии при разработке продукта, а значит, и на конечный бюджет и сроки разработки
ПП. Поэтому крайне важно как можно более точно определить важнейшие требования к
дизайну именно на стадии определения концепции.
При разбивании требования на отдельные элементы основным
критерием должна быть возможность реализации этих требований отдельно друг от друга.
Если требования сильно зависят друг от друга, то они должны быть реализованы вместе.
Цель разделения требований на составные части — получение возможности принимать
решения о целесообразности реализации каждого требования в отдельности и назначать
им различные приоритеты, что в дальнейшем обеспечит гибкость в определении списка
требований для первой и всех последующих итераций продукта или исключения из текущей
версии продукта. Это критично для ПП, бюджет и сроки которых строго определены и
не могут быть пересмотрены.
Как только все требования структурированы, следует назначить
им приоритет.
Обзор конкурентов
Для выпуска продукта на рынок требуется придать ему уникальность,
определить, чем он лучше других, почему именно его будут покупать. Это могут быть
большая функциональность, скорость, удобство использования или более низкая цена.
Поэтому для определения текущего положения на рынке важно серьезно подойти к обзору
конкурентов. Это важно как при создании продукта для открытого рынка, так и для
продукта на заказ.
Вторая цель обзора конкурентов — рассмотрение идей, реализованных
в продукте.
Цель проста — использовать наиболее удачные решения,
реализованные в конкурирующих продуктах, и исключить неудачные.  Структура обзора
конкурентов следующая:
•
конкурентное положение на рынке;
•
список конкурентов (резюме по каждому конкуренту); • список проблем, которые
призваны решать продукты;
•
список возможностей продуктов.
1.
Определить список конкурентов на рынке и выделить лидеров.
Работа проводится с лидерами на рынке. Определить лидеров
можно, используя различные обзоры, результаты опросов или продаж. В числе лидеров
могут оказаться не только продукт с отличным функционалом, но и бесплатное приложение,
предоставляющее необходимый минимум возможностей.
Если предметная область продуктов достаточно популярна,
то в сети можно найти уже готовый обзор, который будет содержать необходимую информацию.
Обзор конкурентов, как правило, — самый продолжительный этап определения концепции
продукта.
2.
Узнать цену и способ доставки ПП у конкурентов.
Нужно посмотреть демонстрационную версию продукта или
маркетинговые материалы, содержащие список возможностей и руководство пользователя.

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

Полученная информация может улучшить бизнес-требования
к ПП.
4.
Составить список возможностей.
Здесь нужно описать все важные возможности, которые были
реализованы в конкурентных продуктах для удовлетворения проблем, описанных в предыдущем
пункте. На основе этого списка можно узнать, как хорошо продукт решает заявленные
проблемы, какие у него сильные и слабые стороны.
На этом этапе изучается сам продукт либо
его документация.
Результатом работы будет таблица со списком возможностей,
которые предоставляют все продукты. В столбце продукта напротив каждой возможности
должно быть указано, предоставляет ли конкретный продукт эту возможность (обычно
помечаются как «+» или «−»).
5.
Резюме по сильнейшим конкурентам.
Следует описать их преимущества и недостатки,
выделить интересные идеи.
6.
Конкурентное положение на рынке.
Если проектируется продукт для открытого рынка, то в заключение
необходимо описать его положение на рынке. В нем нужно обозначить зрелость целевого
рынка и выделить продукты, с которыми будет вестись наиболее ожесточенная борьба.

Далее необходимо перечислить наиболее перспективные пути
развития продукта и его шансы на успех.
Создание образа и списка возможностей будущего продукта
При работе над образом решения аналитики определяют очертания
будущего ПП, который бы удовлетворял всем требованиям, описанным выше.
На этом этапе определяются все основные характеристики,
которыми должен обладать будущий продукт, чтобы достичь ранее поставленных целей.
А на основе экспертной оценки уже могут быть определены ожидаемые сроки и бюджет
продукта.
Образ решения служит доказательством того, что разработчики
выбрали правильный путь (или напротив), и оказывает наибольшее влияние при выборе
команды разработчика для тендерных проектов.
Когда известно, кому и зачем нужен продукт, следует определить,
какую функциональность он будет предоставлять для удовлетворения потребностей будущих
пользователей. Задача упрощается тем, что после обзора конкурентов известны решения,
которые уже предлагаются конкурентами, их слабые и сильные стороны.
Работу начинают с определения нефункциональных возможностей,
которые должны удовлетворять ранее собранным требованиям к дизайну. Эти возможности
имеют максимальное влияние на дизайн продукта, а потому должны быть четко определены
на стадии создания концепции. Именно от списка нефункциональных возможностей будет
зависеть сложность реализации основных функций продукта. Следовательно, они будут
определять стоимость реализации и тестирования этих функций.
Нефункциональные возможности должны содержать:

•   имя возможности;

•   приоритет возможности;

•   наличие этой функции
у конкурентов (для каждого конкурента);
•   краткое описание
возможности;
•   примечание для конкурентов.

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

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

•   «является» — категория
продукта;
•   «который» — ключевое
преимущество, основная причина для покупки или использования;
•   «в отличие от»
— основной конкурирующий продукт, текущая система или текущий бизнес-процесс;
•   «наш продукт» —
положение об основном отличии и преимуществе нового продукта.
Список возможностей должен полностью
соответствовать образу решения.
Определение содержания контрольных событий проекта
Образ продукта подразумевает список направлений, по которым
он должен развиваться, а содержание относится к определенному проекту или его итерации,
в которых реализуется меньше возможностей продукта, чем это возможно. Образ продукта
будет изменяться относительно медленно. Содержание, в свою очередь, более динамично,
так как менеджер проекта изменяет содержимое каждой версии в соответствии с графиком,
бюджетом, ресурсами и критериями качества.
Объем первоначальной версии продукта зависит от целей,
которые возлагаются на продукт. Как правило, объем первоначальной версии должен
быть минимально необходимым для того, чтобы удовлетворить пользователей. Это
делается для того, чтобы как можно раньше занять нишу на рынке или предоставить
решение заказчикам.
Для продуктов, разрабатываемых под заказ, функционал строго
определен заказчиком. Но для того, чтобы наладить обратную связь с пользователем
на раннем этапе, продукт часто разбивается на несколько версий. Используется итеративный
процесс разработки, в котором результатом определенных итераций должен быть продукт,
готовый к промышленному внедрению на большом количестве рабочих мест.
Определение контрольных событий — это обязательный этап
процесса разработки проекта, который тесно переплетен со сбором и детализацией требований
к проекту. После определения концепции проекта невозможно точно определить срок
его реализации. Бюджет может быть определен лишь на основе экспертной оценки, его
точность обычно не превышает 50%. По завершении сбора и анализа требований точность
оценки, сделанной на их основе, уже может достигать 60–70%. И только после завершения
проектирования опытный менеджер сможет определить бюджет с точностью до 80–90%.

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

Рис. 2.2
Пример диаграммы
профилей пользователей продукта
Powered by TCPDF
(www.tcpdf.org)
Профили пользователей явно или неявно уже должны
содержаться в сценариях, поэтому их нужно только выделить. Для домашних продуктов
разделение обычно производится исходя из уровня подготовленности пользователя и
его интересов, для корпоративных продуктов основными критериями являются специализация
работника и круг его обязанностей.
При общении с конечными пользователями необходимо узнать,
для достижения каких целей будет использоваться будущий программный продукт.
Для этого производится сбор пользовательских
историй.
Пользовательская история — это вариант использования будущего
продукта в конкретной ситуации с целью достижения измеримого результата. Пользовательские
истории могут содержать как сложные инструкции с ответвлениями, так и конкретные
примеры, при этом используются термины предметной области. Пользовательская история
должна содержать пример реальной ситуации, а их систематизацию и оптимизацию можно
сделать позже. Если же бизнес-процессы, которые автоматизирует продукт, строго формализованы,
то пользовательская история должна содержать алгоритмы действий ПП или людей, работающих
с ней.
Ошибка, которую делают при сборе требований к продуктам,
— это формирование образа продукта на основе ответов на вопросы: «Что должен делать
продукт?» или «Как должен работать продукт?». Целью сбора требований является получение
ответа на вопрос: «Для чего нужен продукт?». А потому единственный вопрос,
который должен задаваться пользователю, — это «Зачем?».
Дизайн пользовательского интерфейса входит в фазу проектирования
программного обеспечения, но его можно считать и частью фазы требований.
Заказчики часто представляют себе приложение в форме
графического пользовательского интерфейса. Описать работу ПП можно, используя черновой
вариант пользовательского интерфейса.
2.3. Шаги разработки пользовательских интерфейсов

Предлагается 11 этапов разработки пользовательских
интерфейсов.
1.  Узнайте
своего пользователя (С) (обработка С-требований).
2.  Поймите
назначение проектируемой системы (С).
3.  Примените
принципы хорошего экранного дизайна (С, D (D-требования)).
4.  Подберите
подходящий тип окон (С, D).
5.  Разработайте
системные меню (С, D).
6.  Выберите
соответствующие аппаратные устройства управления (С).
7.  Выберите
соответствующие экранные элементы управления (С).
8.  Организуйте
и создайте раскладку окон (С, D).
9.  Выберите
подходящие цвета (D).
10.
Создайте осмысленные значки (С, D)
11.
Предоставьте эффективные сообщения, обратную связь и руководство (D).
Шаг 1 (знакомство с пользователем). На этом шаге
рекомендуется оценить общество конечных пользователей программы. В общих чертах
основные факторы приведены в таблице 2.3.
Таблица 2.3
Критерии, по которым оцениваются потенциальные пользователи ПП

Характеристика

Градации

Уровень знаний и опыт

Компьютерная грамотность

Высокий

Средний

Низкий → объяснить каждый термин

Системный опыт

Высокий

Средний

Низкий → представить примеры и анимацию

Опыт работы с подобными программами

Высокий

Средний

Низкий → представить примеры и анимацию

Образование

вуз

Колледж

Школа →
  использовать термины 12-го класса

Уровень чтения

> 12 лет в школе/5–7 классы/

< 5 лет → использовать очень простой язык

Машинопись

135 слов в минуту/55/[10 → предоставить небольшие
  поля для ввода текста, примеры, уделить особое внимание формам для заполнения]

Физические характеристики пользователя

Возраст

Молодой/среднего возраста/пожилой

Пол

Мужской/женский

Развитие рук

Левша/правша/владеющий одинаково обеими руками

Физические недостатки

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

Характеристики заданий и работы пользователя

Способ использования этой программы

По усмотрению/[обязательная → сделать программу
  интересной в использовании]

Частота использования

Постоянная/частая/случайная/[разовая → предоставить
  всю справочную информацию с каждым экраном]

Коэффициент текучести кадров

Низкий/средний/[высокий → предоставить всю справочную
  информацию с каждым экраном]

Продолжение табл. 2.3

Характеристика

Градации

Важность задания

Высокая/средняя/[низкая → сделать интересной в использовании]

Повторяемость задания

Низкая/средняя/[высокая → автоматизировать как можно
  больше шагов, предоставить разнообразие в представляемых данных, предоставить
  возможности обучения]

Предварительное обучение

Нет/самостоятельное изучение по справочникам/[интенсивное
  → предоставить интерактивную систему обучения]

Категория работы

Администратор/менеджер/профессионал/секретарь/[клерк и
  т. д. → использовать знакомый язык, примеры и описания]

Психологические характеристики пользователя

Вероятное отношение к работе

Положительное/безразличное/отрицательное

Вероятные мотивации

Высокие/средние/[низкие → сделать приложение особенно
  привлекательным]

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

Словесный или [пространственный → подчеркнуть геометрический
  вид]
Аналитический или [интуитивный → подчеркнуть символы
  в тексте]
Конкретный или [абстрактный → разработать обобщения]

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

Шаг 3 (понимание принципов хорошего экранного дизайна).
Основные элементы хорошего экранного дизайна могут быть следующими:
1.
Убедитесь в единообразии экранов приложения, а также в логичности каждого
отдельно.
2.
Сделайте предположение о том, откуда обычно пользователь будет начинать работу
(«первый» элемент размещают в верхнем левом углу).
3.
Сделайте навигацию как можно более простой:
•      выровняйте
похожие элементы;
•      сгруппируйте
похожие элементы;
•      учтите
границы вокруг похожих элементов.
4.
Примените иерархию для подчеркивания порядка важности.
5.
Примените принципы приятных визуальных эффектов:
•      баланс,
симметрия, регулярность, предсказуемость;
•      простота,
единообразие, пропорциональность.
6. Предоставьте подписи.

В качестве примера используем информацию о заказчиках и их банковских счетах. Для
улучшения интерфейса в левом верхнем углу разместим наиболее важные элементы и сгруппируем
похожие элементы (рис. 2.3). Далее производим «улучшение» интерфейса (рис. 2.4,
2.5).

Рис. 2.3
Применение принципов хорошего экранного
дизайна — исходный вид

Рис. 2.4
Применение принципов хорошего экранного
дизайна — улучшенный вид

Рис. 2.5
Применение принципов хорошего экранного
дизайна
Шаг 4 (выбор подходящего типа окна). Цели каждого
пользовательского интерфейса могут обслуживаться наиболее эффективно одним или двумя
конкретными типами окон. Пять основных целей графического пользовательского интерфейса
(ГПИ) и типы окон перечислены на рисунке 2.6.

Рис.
2.6 (начало)
Использование окон

Рис. 2.6 (окончание)  Использование
окон
Шаг 5 (разработка системного меню).
Правила для создания главных меню:
•   сделать главное
меню;
•   показать все уместные
альтернативы;
•   привести структуру
меню в соответствие со структурой задачи приложения;
•   минимизировать число
уровней меню.
Пользователям нужен понятный способ использования приложений,
поэтому необходимо постоянное главное меню. Количество элементов в этом меню должно
быть от пяти до девяти, поскольку большинство пользователей чувствуют себя комфортно
именно с таким набором. Например, текстовый редактор имеет девять элементов меню:
«Файл», «Правка», «Вид», «Вставка», «Формат», «Сервис», «Таблица», «Окно» и «Помощь».
Элементов могло бы быть больше, поскольку оставалось довольно много места, но пришлось
бы постоянно сканировать этот список в поисках необходимой команды.
Шаг 6 (выбор подходящих устройств управления).
Под устройствами управления понимаются физические устройства, с помощью которых
пользователи сообщают свои пожелания приложению. Сюда относятся джойстики, трекболы,
графические планшеты, сенсорные экраны, мыши, микрофоны, клавиатуры и др.
Шаг 7 (выбор подходящих экранных элементов управления).
Экранные элементы управления — это символы, появляющиеся на мониторе, с помощью
которых пользователь передает программе вводимые данные и своинамерения. Сюда относятся
значки, кнопки, текстовые окна, списки, изображенные на рисунке 2.8. Правила организации
экранных элементов управления в окне практически те же, что и для дизайна экрана
в общем. Их число также обычно варьируется от пяти до девяти. Это число может быть
увеличено в случае использования иерархии.
Шаг 8 (организация и планирование окон). Правила
для компоновки многочисленных окон аналогичны правилам для дизайна одиночных окон
(в том числе симметрия, пропорциональность и т. д.), но сюда включена также и организация
окон — соприкасающиеся или каскадные (рис. 2.7).

Рис. 2.7
Общие соглашения по графическому пользовательскому
интерфейсу
Шаг 9 (выбор подходящих цветов). Если цвет выбран
с умением и со вкусом, то это может обогатить экран. Использование цвета не делает
автоматически пользовательский интерфейс более полезным или привлекательным, однако
может легко его испортить. По выражению знаменитого дизайнера Поля Рэнда, «цвет
— это воплощение сложности». Инженеры-программисты, не сотрудничающие с профессиональными
дизайнерами, должны быть очень умеренными и консервативными в использовании цветов.

Шаг 10 (осмысленные значки). Значки в интерфейсе
должны быть продуманы как в качественном, так и в количественном соотношении.
Шаг 11 (сообщения, обратная связь, руководства).
Сообщения пользователю должны быть краткими и понятными. Пишется руководство по
работе с программным проектом.
На этом этапе работ применяются диаграммы вариантов использования,
они показывают взаимодействие пользователя и программы. Также можно использовать
диаграммы переходов состояний, если заказчик понимает эту диаграмму. То же касается
и диаграмм потоков данных.
2.4. Методологии и инструментальные средства  для С-требований
Для выражения требований используются многочисленные
методологии.
Структурный анализ формализует потоки данных и функциональную
декомпозицию. В частности, технология структурного анализа и проектирования
(SADT — Structured Analysis and Design Technique) является систематизированным подходом
к работе с системными спецификациями. SADT описывает проблему на самом высоком функциональном
уровне как прямоугольник с входами, ограничениями и выходами («диаграмма контекста»).
Она разделяется в следующий уровень диаграммы потоков данных, который затем аналогично
разделяется дальше. В результате появляется иерархия диаграмм с возрастающим уровнем
детализации потоков данных. Структурный анализ рассматривает приложение с точки
зрения функциональности. Эта функциональность и реализуется в иерархии функций.
Системы реального времени могут быть эффективно описаны с помощью диаграмм переходов
состояний, используемых объективным подходом. Большинство обозначений заимствованы
в UML (Unified Modeling Language).
Быстрое прототипирование — это частичная реализация целевой
программы, в том числе обычно значительной части пользовательского интерфейса. Быстрое
построение прототипа — полезный способ установить требования заказчика, а также
определить и упразднить рискованные части проекта.
Чем детальнее прототип, тем легче понять требования заказчика.
С другой стороны, прототипы сами по себе являются программами, поэтому чем детальнее
прототип, тем он дороже. По мере того, как возрастают расходы на прототип, возрастает
и его пригодность, но также возрастают и расходы из выделенного бюджета (рис.
2.8). Существуют момент, в который затраты оптимальны (точка максимума на кривой),
и некоторая точка, за которой деньги уже потрачены зря (где кривая пересекает горизонтальную
ось).

Рис. 2.8
Выгода от прототипа
Существует риск для всего проекта, когда неочевидно, могут
ли вообще быть реализованы предложенные требования. Если риск реально существует,
то, возможно, потребуется провести исследования осуществимости требований. Эти исследования
предполагают частичную разработку или моделирование программы.
Как только С-требования собраны, SРМР (Software
Project Management Plan — план управления программным проектом) можно обновлять.
Такое обновление происходит в течение всего жизненного цикла ПП.
Хотя процесс анализа требований может иметь много итераций
в течение жизни проекта, у такого итеративного процесса есть свои практические ограничения.
Клиент хочет знать стоимость работы заранее, однако разработчики обычно договариваются
о стоимости только после запрета на изменения требований. Оценка стоимости может
быть уточнена после анализа С-требований. Основное уточнение происходит от улучшенного
понимания разработчиками природы и области применения программы.
2.5. D-требования (детальные требования)
Разработчикам программного обеспечения нужна база для
проектирования и разработки. Эта база состоит из детальных требований. Их также
называют конкретными требованиями, функциональными спецификациями, требованиями
разработчика или D-требованиями. D-требования состоят из полного списка конкретных
свойств и функциональности, которую должна иметь программа. Каждое из этих требований
пронумеровано, помечено и отслеживается по ходу разработки. D-требования должны
быть согласованы с С-требованиями. Предполагается, что D-требования будут читать
преимущественно разработчики.
После завершения этапа сбора требований имеется необходимая
информация о требованиях к будущей системе, но эта информация не систематизирована
и часто дублируется. Для небольшого продукта это неважно, и он может обойтись без
большинства стадий анализа, быстро перейдя к проектированию, но для крупного продукта
это приведет к большому количеству ошибок в процессе проектирования и, как следствие,
к увеличению бюджета и срока разработки. Чем больше продукт, тем более важной является
стадия анализа.
Основными целями анализа требований являются их систематизация
и избавление от дублируемых данных. Это достигается за счет разделения пользовательских
историй на отдельные пакеты по функциональному признаку и их иерархической структуризации.

По окончании этапа анализа требований многостраничный
документ, содержащий сотни пользовательских историй, разбивают на части. Каждая
часть освещает только необходимую функциональность, в её основе используется диаграмма
вариантов использования, на основе которой можно будет легко увидеть все требуемые
функции системы. Описания вариантов использования не дублируются, а только дополняют
друг друга.
Первым этапом анализа требования является выделение пользовательских
историй в отдельные пакеты требований. Для специализированных систем управления
требованиями вроде Borland Caliber RM или Rational Request Pro, в которых все требования
хранятся в базе данных и представлены древовидным списком, пакетами являются элементы
первого уровня, которые будут играть роль контейнера для всех остальных требований.
При использовании текстовых документов пакетами будут являться отдельные файлы,
возможно, с общим индексом.
Главная цель формирования пакетов — упростить доступ к
нужным данным за счет того, что все варианты использования, относящиеся к определенной
функциональности, можно будет увидеть на одной странице (оглавление или диаграмма
вариантов использования). В случае использования текстовых документов пакеты также
существенно упростят процесс последующего редактирования — не нужно будет блокировать
весь документ на время редактирования, а пользователям документа будет легче узнать
об изменениях (как правило, для этого используется секция «История изменений» в
начале каждого документа). Обычно в один пакет входит 20–30 пользовательских историй.

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

•
если необходимо сократить затраты на стадию анализа до минимума, а
количество пользовательских историй в пакете невелико (их содержимое можно просмотреть
не дольше чем за 10 мин).
•
команда разработки не умеет или не хочет работать с вариантами использования
и требует предоставления требований к системе в классическом виде.
Варианты использования
Как правило, у всех пользовательских историй в пакете
есть одна или несколько главных целей и история, которая описывает наиболее простой
способ их достижения. Такая история называется базовой, а описание её действия
— базовый путь. Остальные истории описывают альтернативный способ достижения результата
или содержат дополнительные действия для достижения результата и являются дополнениями
к базовой истории.
Пользовательские истории — это разновидность стандартных
вариантов использования, только с одной особенностью — они описывают взаимодействие
не с реальной, а с гипотетической системой.
Главным критерием определения базового варианта использования
является наличие общих со всеми остальными вариантами использования действий. Базовым
вариантом использования могут быть существующая пользовательская история, которая
имеет результат (приносит пользу), или абстрактный набор действий, который создан
лишь для выделения общих шагов. Для определения базового варианта использования
нет четкого правила, часто в одном и том же пакете есть возможность создать абстрактный
вариант использования или взять за базу одну простейшую или несколько более сложных
историй — и все эти решения будут верными.
Когда есть один или несколько базовых вариантов использования,
описываются его связи с другими вариантами использования. Лучшим способом для этого
является использование диаграммы вариантов использования. Этот вид диаграмм входит
в стандарт UML и получил широкое распространение в сфере проектирования ПО.
В процессе проектирования на диаграмме вариантов использования
необходимо видеть приоритет каждого элемента, для этого обычно используют цветовое
обозначение.
В конечном итоге должны получиться одна или несколько
диаграмм, содержащих все варианты использования системы и их связи между собой.

После того, как все отношения между вариантами использования
определены, следует их отредактировать.
На этапе сбора пользовательских историй можно заметить,
что поток действий большинства пользовательских историй содержит много повторений.
На этапе определения зависимостей общие части были определены, и на их основе была
определена структура элементов на диаграмме вариантов использования. Далее нужно
отредактировать тело вариантов использования с целью исключения общих частей из
их предусловий, постусловий и потоков действий.
Все варианты использования, за исключением базовых, являются
расширением к другим вариантам использования. Поэтому в теле варианта использования
надо указывать ссылку на вариант(-ы) использования, который он расширяет. В предусловиях,
постусловиях и потоке действий должны быть указаны только действия, уникальные именно
для этого варианта использования.
Цель этой работы — повысить информативность описания вариантов
использования и избавиться от дублирования данных в пакете. В итоге каждый вариант
использования должен содержать только уникальную информацию.
Взаимоисключающие требования — достаточно частое явление
для крупного продукта, так как у него много пользователей, а значит, много мнений.
Для того, чтобы противоречащие требования не порождали ошибки в процессе проектирования
или, еще хуже, в процессе разработки, большинство из них должны быть выявлены еще
на этапе анализа.
Если считать, что при сборе требований аналитик не дал
возможности пользователям принимать проектные решения и в результате пользовательские
истории содержат только «правильную» информацию, то будет два типа взаимоисключающих
требований:
1.
Ошибка в пользовательской истории. Автор допустил ошибку в описании истории,
указав неправильное поведение системы. Как правило, основным признаком таких историй
является невозможность их интеграции с другими элементами, но для уверенности нужно
проконсультироваться с автором или специалистом в предметной области, прежде чем
их удалить.
2.
Разные взгляды на одну и ту же проблему. Несколько авторов имеют разные мнения
о том, как должна работать система. Эта проблема может иметь два решения:
•
можно выбрать «более правильную» точку зрения и оставить только её.

Такое решение, как правило, можно принять
на основе приоритетов историй;
•
определить дополнительные условия, при которых обе конфликтующие истории
будут выполняться в рамках одной системы. Это решение может значительно усложнить
систему, но в большинстве случаев оно сделает её более гибкой.
Для того, чтобы иметь максимальную гибкость в процессе
проектирования функциональности, необходимо разбить варианты использования на неделимые
элементы. Признаком того, что вариант использования требуется разбить на части,
является то, что он описывает решение сразу нескольких проблем, которые могли бы
быть решены по отдельности.
Результатом этого процесса должна быть диаграмма вариантов
использования, каждый элемент которой описывает свою уникальную цель.
Диаграмма вариантов использования является хорошим инструментом
для проектирования, ознакомления и дальнейшего модернизирования системы, но есть
процессы, где её использование затруднительно. В связи с этим необходимо преобразовать
диаграмму вариантов использования в нумерованный список. Большинство промышленных
средств проектирования предоставляют возможность сделать это автоматически; если
же выбранный инструмент не содержит эту функциональность, то следует произвести
преобразование самостоятельно, применяя следующие правила:
•
все элементы, которые не являются включениями или расширениями, должны
стать главными узлами списка;
•
элементы, являющиеся расширениями, должны стать дочерними элементами
списка по отношению к тем, кого они расширяют. Если элемент имеет несколько родителей,
то следует воспользоваться средствам трассировки или скопировать элемент в каждую
ветку (с пометкой, что это копия).
Далее работы будут вестись как со списком, так и с диаграммой,
поэтому оба этих представления следует поддерживать в рабочем состоянии.
Спецификация требований
Для нормальной разработки нужен список требований, который
однозначно идентифицирует потребности пользователей и не имеет множественных повторений,
которые присутствуют в пользовательских историях. Для более гибкого проектирования
необходим как можно более детализированный список.
Необходимо выделить все уникальные результаты пользовательских
историй в отдельные требования. Если результат истории оказался уникальным, то его
нужно преобразовать в требования (просто скопировать его тело, используя повелительное
наклонение). Если же похожий результат уже был вынесен в требование в рамках другой
пользовательской истории, то надо проанализировать их возможные отличия и, если
они есть, модернизировать существующее требование или создать дополнительное дочернее
требование/ограничение. Приоритет требования должен быть унаследован от родительской
истории с максимальным приоритетом.
Кроме результата пользовательской истории следует проанализировать
процесс ее выполнения. Он может содержать уточнения/пожелания к поведению продукта,
которые можно учесть. Пожеланиям следует назначать приоритет ниже, чем приоритет
родительской истории.
В результате этой работы должен быть получен древовидный
список требований.
Каждое требование списка должно быть самостоятельным и
не являться контейнером (структурной единицей для хранения дочерних элементов).
Требования должны быть приоритезированы, причем дочернее требование не может иметь
больший приоритет, чем родительское требование (которое оно дополняет).
Для того, чтобы иметь максимальную гибкость в процессе
проектирования функциональности, необходимо разбить требования на неделимые элементы.

Результатом этого процесса должен быть список требований,
каждый элемент которого должен являться:
•
самостоятельным требованием — может расширять, а следовательно, и
зависеть от родительского требования, но не должно быть зависимо от дочерних требований
или требований того же уровня. Это означает, что реализация требования не должна
требовать реализации каких-либо дочерних требований или требований того же уровня.
Если требования связаны настолько сильно, что могут быть реализованы только вместе,
их нужно объединить.
•
неделимыми требованиями — в противоположность предыдущему критерию
требование не должно описывать сразу несколько проблем, которые можно решать порознь.

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

1. Функциональные требования:
•
функциональность приложения.
2. Нефункциональные требования:
1) производительность:
•      скорость;

•      пропускная
способность (трафик);
•      использование
памяти (оперативная память, жесткий диск);
2) надежность
и доступность;
3) обработка
ошибок;
4) интерфейсные
требования (как программа взаимодействует с пользователем и с другими программами).
Ограничения:
•   точность;
•   ограничения на инструменты
и язык, например «должен использоваться С#»;
•   ограничения проектирования;

•   стандарты, которые
должны быть использованы;
•   платформы, которые
должны быть использованы.
3. Обратные требования (чего программа
не делает).
1.
Функциональные требования.

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

Например, приложение, управляющее радарами аэропорта,
должно давать не более двух ошибок в месяц.
Обработка ошибок — эта категория требований объясняет,
как программа должна реагировать на возникающие ошибки. Например, что должна делать
программа, если она получает сообщение из другой программы в неразрешенном формате?
Это не касается ошибок, генерируемых самой программой.
В некоторых случаях обработка ошибок относится к действиям, которые
должна предпринять программа, если она сама создала ошибку из-за дефекта в своей
конструкции. Этот тип требований к ошибкам должен быть использован выборочно, поскольку
целью является создание безошибочных программ, а не исправление ошибок с помощью
бесконечного кода обработки ошибок.
Интерфейсные требования описывают формат, в котором
программа общается с окружением. Например, требование пользователей программы:
«Стоимость посылки статьи от адресата получателю должна постоянно показываться в
текстовом окне „Цена“».
Ограничения на проектирование или реализацию описывают
границы или условия того, как приложение должно быть задумано и разработано. Эти
требования не должны использоваться вместо процесса проектирования — они всего лишь
определяют условия, наложенные на проект заказчиком, а также окружение или другие
обстоятельства. Например, точность: «Вычисления оценки ДТП ПС должны быть выполнены
с точностью до одного сантиметра».
Часто также
накладываются ограничения по инструментам и языкам. Сюда относятся исторически сложившиеся
традиции организации, совместимость и опыт программистов. Ограничения, требующие
следовать определенному стандарту, часто определяются политикой фирмы или заказчиком.

Обратные требования определяют, чего программа не будет делать. Логично,
что существует бесконечное число обратных требований: мы выбираем только те, которые
разъясняют возможное непонимание. Например: «ПС (см. предыдущий раздел) не обязательно
должна анализировать данные ДТП».
2.8. Контрольные вопросы
2.1. Что такое требования к программному
обеспечению?
2.2. Этапы сбора и анализа требований.

2.3. Как влияет качество работ на характеристики
конечного продукта?
2.4. Понятие С-требований и D-требований.

2.5. Сбор и анализ бизнес-требований.

2.6. Для чего нужны сценарии?
2.7. Определение функциональных требований
и требований к дизайну.
2.8. Обзор конкурентов на рынке ПП.
2.9. Создание списка возможностей
будущего продукта.
2.10. Определение основных профилей пользователей.

2.11. Шаги разработки пользовательских
интерфейсов.
2.12. Разработка прототипа ПО.
2.13. Детальные требования.
2.14. Проектирование на основе вариантов
использования.
2.15. Проектирование на основе требований.

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

2.17. Нефункциональные детальные требования.

file_name: Раздел 2.pdf

alt: РАЗРАБОТКА И АНАЛИЗ ТРЕБОВАНИЙ

alt: С-требования и D-требования

alt: Работа проводится с лидерами на рынке

alt: Шаг 1 (знакомство с пользователем)

alt: Рис. 2.6 ( начало ) Использование окон

alt: Шаг 5 (разработка системного меню)

alt: Как только С-требования собраны,

alt: Если считать, что при сборе требований аналитик не дал возможности пользователям принимать проектные решения и в результате пользовательские истории содержат только «правильную» информацию, то будет…


extracted_text:
Почему же атомы не проходят
друг сквозь друга?

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

Именно так и происходят все соударения всех твердых тел – через электростатическое отталкивание элек-тронных оболочек их внешних атомов.
А как поля двух сближающихся электронов «общают-ся» друг с другом, как они друг друга чувствуют? И что такое вообще – поле? Из чего оно сделано?

На этот вопрос физики вам не ответят. На этот во-прос знают ответ только философы. Они говорят так: поле – это особый вид материи. И многозначительно замолкают.

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

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

– Так может, поле состоит из квантов? – озарит кого-то внезапная мысль.

Мысль хорошая. Но неправильная.

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

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

Неплохо завернуто? Такова современная физика, при-выкайте.

Слова «виртуальная реальность» известны нынче всем из-за
массового распространения компьютеров и ком-пьютерных игр. Виртуальная – значит несуществую-щая, придуманная, сказочная, игровая.
Но если для компьютерных миров это определение вполне понят-но, то в устах строгой науки физики выглядит странно.
И это еще очень мягко сказано!
С каких это пор физи-ка оперирует сказочными, выдуманными категориями? А
вот с тех самых пор, когда Планк и Эйнштейн
себе на голову придумали кванты и потом весьма страдали че-рез это интеллектуально. Родив новый раздел физи-ки – квантовую механику, они сами были ею очень не-довольны, уж больно непривычная какая-то физика начинала вырисовываться на горизонте! Недаром Эйн-штейн называл квантовую механику
«магией» и даже
«не-физикой».

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

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

Почему?

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

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

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

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

И если реальные фотоны видят все, кому не лень, то виртуальные «видят» только обменивающиеся ими ча-стицы. По сути – это призраки. Чистая выдумка физи-ков. Теоретический
конструкт, рожденный в их головах. Однако эти неуловимые
призраки передают впол-не реальное
взаимодействие: бац! и бильярдные шары
со стуком разлетелись в разные стороны – просто по-тому, что электроны, находящиеся на их поверхностях, обменялись виртуальными фотонами. Которых как бы и не существует. Или их не существует без всяких «как бы»?
Ведь что такое «существует»?

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

Ну и как проверить, есть ли они «на самом деле»? Да никак! В теории они существуют и объясняют, как про-исходит взаимодействие. А кроме теорий наука боль-ше
ничем, в общем-то, и не оперирует.

Ладно. С этим примерно разобрались – электромаг-нитное взаимодействие передается
с помощью фото-нов.
А остальные виды взаимодействия?

Да так же!

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

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

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

Мы с вами твердо знаем: самые лучшие элементарные частицы – электрон, протон и нейтрон. Я бы на каж-дом из них знак качества
поставил, настолько
они от-личные! Именно из этих кирпичиков сделан весь окру-жающий нас мир – воздух, зеркало, папа с мамой, мо-роженое, деньги, солнце и прочие полезные в быту
предметы. Все остальные частицы по сравнению с эти-ми – сущий мусор.

А какие остальные?

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

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

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

А потом?

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

Скачано с www.znanio.ru

file_name: Физика на пальцах 65.docx

alt: Т а к м о ж е т , п о ле с о с т о и т и з к в а н…

alt: Э т о с в о е г о р о д а « ш и ф р о г р а м - м…

alt: П о э т о м у ф и з и к а м п ри ш л о с ь п ри д у…

alt: Г р а в и т а ц и о нн о е – п е р е д а е т с я с…

alt: Т о ль к о н е й т рин о п р о с т о п р о н з а е т…

title: Физика на пальцах. Для детей и родителей, которые хотят объяснять детям65


extracted_text:
1 Методические указания к составлению пояснительной записки

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

2 Расчетная часть
2.1
Выбор типа и топологии сети
На основании выданного задания необходимо
обосновать выбор типа сети, используемую сетевую архитектуру, а также
топологию проектируемой сети. При проектировании локальных сетей на основе
технологии Ethernet следует учитывать ограничения, указанные в стандартах.
Среди основных ограничений можно
выделить следующие:
-
общее число станций в
сети;
-
общее число станций в
сегменте;
-
максимальное расстояние
между узлами сети;
-
максимальная длина
сегмента;
-
максимальное число
повторителей.
В общем случае, при отклонении от
перечисленных ограничений сеть может оказаться не работоспособной. При
необходимости построения сети с отклонениями от рекомендаций стандартов
следует, согласно методики, осуществить расчеты следующих величин:
-
время двойного оборота
сигнала в сети (Path Delay Value, PDV), которое должно составлять не более 575
битовых интервалов (bit);
-
сокращение межкадрового
интервала (Path Variability Value, PW), которое
должно составлять не более 49 битовых
интервалов.
Отклонение от рекомендаций стандартов
в будущем может привести к усложнению процесса перехода к более современным
технологиям.
Среди методов, используемых при
проектировании сетей, наиболее известным является логическая структуризация
сети. Структуризация сетей используется для того, чтобы устранить возможные
ограничения, возникающие при создании более или менее крупных сетей и,
следовательно, сделать сеть работоспособной. Для устранения таких ограничений,
как длина связей между узлами, количество узлов в сети, интенсивность трафика,
порождаемого узлами и необходима, в основном, логическая структуризация.
Логическая структуризация заключается в том, что используют такое
структурообразующее оборудование, как: мост, коммутатор, маршрутизатор и шлюз.
Для структуризации на логическом уровне применяют разбиение на виртуальные
локальные сети.
Для начальной оценки
работоспособности сети можно ориентироваться на правило "4-х хабов",
которое ориентировано на среду передачи данных на основе витой пары и
волоконно-оптического кабеля (10Base-T, 10Base-F и др.). Данное правило
означает, что не должно быть более 4-х концентраторов между любыми двумя станциями
сети. Для указанных сред передачи данных образуются иерархические древовидные
структуры без петлевидных соединений.
Выбранная топология ЛВС должна
обеспечивать примерно одинаковые возможности доступа к ресурсам сервера для
всех абонентов ЛВС.
На основании выбранной сетевой
технологии, типа и топологии сети и задания, необходимо разработать структурную
электрическую схему ЛВС. Особенности разработки данной схемы также необходимо
пояснить в этом пункте.
На схеме должны быть представлены:
-
изображения узлов сети
(клиентов и сервера);
-
изображение размещаемого
сетевого оборудования проектируемой ЛВС;
-
изображение связей и
обозначение их соединительными линиями в проектируемой ЛВС.
Структурную электрическую схему сети
необходимо привести в графической части, лист КП 00.00.000 Э1.

Пример разработанной электрической структурной схемы сети
приведён в Приложении В.

2.2 Выбор
оборудования и типа кабеля
На основании разработанной
структурной схемы и выбранной сетевой технологии необходимо выбрать сетевое
оборудование и тип кабеля для проектирования плана расположения оборудования и
прокладки кабеля.
Для выбранного оборудования
необходимо привести основные его характеристики, которые необходимо оформить в
виде таблицы. Пример описания оборудования приведён в таблице 3:
Таблица 3- Основные характеристики сетевого
оборудования

Характеристика

Значение

Набор информационных розеток и
розеток питания на каждом рабочем месте пользователя ЛВС необходимо выбирать
одинаковыми. Унификация количества информационных гнёзд (чаще всего RJ45) и
розеток питания на каждом рабочем месте делает кабельную систему универсальной.
Это позволит в будущем оперативно подстраивать данную компьютерную сеть при каждом
изменении структуры организации.
В настоящее время, подавляющее
большинство локальных вычислительных сетей в качестве среды передачи данных
используют витую пару. Такие сети дешевле и проще в обслуживании.
Чаще всего на рабочем месте локальной
вычислительной сети присутствует:
-
информационное гнездо
RG-45, для подключения к ЛВС;
-
одна розетка бытового
электропитания;
-
две розетки
электропитания для компьютеров.
2.3
Выбор программного
обеспечения
На основании разработанной структурной электрической схемы сети
необходимо обосновать выбор программного обеспечения для рабочих станций и
сервера, если он имеется. Здесь необходимо описать основные характеристики
выбранных операционных систем.
2.4
Разработка плана
расположения оборудования и прокладки кабеля
На основании выбранного типа и
топологии сети, а также выбранного сетевог оборудования и типа кабеля
необходимо разработать план расположения оборудования и прокладки кабеля. При
разработке плана обосновать расположение коммутаторов и сервера, прокладку
кабель - каналов и переходы по этажам. Планы прокладки кабельных трасс
выполняются на основе строительных планов этажей зданий. На этих планах должны
быть указаны:
-
помещения, в которых
проектируется расположение узлов активного оборудования ЛВС;
-
трассы прохождения соединительных
линий между узлами ЛВС и абонентами;
-
точки перехода между
зданиями/этажами, используемые для прокладки кабеля.
При проектировании кабельных трасс следует считать, что:
-
кабели связи
прокладываются (главным образом) вдоль коридорных стен на высоте не менее 2,4м;
-
переходы кабелей с этажа
на этаж производятся через кабельные туннели, показанные на плане этажей;
-
переходы кабелей через
межкомнатные переборки допускаются как исключение, не далее, чем из данной
комнаты в одну соседнюю;
-
прокладка кабелей из
коридора в комнату, как правило, не связывается с дверным проемом.
На плане необходимо указать следующую
информацию:
-
размеры комнат,
коридоров;
-
межэтажные шахты
(стояки) силовые и слаботочные;
-
щиты
питания;коммуникационные узлы ЛВС и телефонии (их настоящее или предполагаемое
расположение);
-
расположение рабочих
станций;
План расположения оборудования и прокладки кабеля необходимо
привести в графической части, лист КП 00.00.000 АС.
2.5
Расчет необходимого количества оборудования
Длина кабеля зависит от количества и
месторасположения рабочих станций, сервера и прочего сетевого оборудования, так
как от каждого сетевого устройства до коммутатора прокладывается отдельный
кабель.
При расчете длины горизонтального
кабеля учитываются следующие очевидные положения. Каждая телекоммуникационная
розетка связывается с коммутационным оборудованием в кроссовой этажа одним
кабелем. В соответствии со стандартом ISO/IEC 11801 длина кабелей
горизонтальной подсистемы не должна превышать 90 м. Кабели прокладываются по
кабельным каналам. Принимаются во внимание также спуски, подъемы и повороты
этих каналов.
Существует два метода вычисления
количества кабеля для горизонтальной подсистемы:
-
метод суммирования;
-
эмпирический метод.
Метод суммирования заключается в подсчете
длины трассы каждого горизонтального кабеля с последующим сложением этих длин.
К полученному результату добавляется технологический запас величиной до 13%, а
также запас для выполнения разделки в розетках и на кроссовых панелях.
Достоинством рассматриваемого метода является высокая точность. Однако при
отсутствии средств автоматизации и проектировании компьютерных сетей с большим
количеством портов такой подход оказывается чрезмерно трудоемким, что
практически исключает, в частности, просчет нескольких вариантов организации
кабельной системы. Он может быть рекомендован для использования только в случае
проектирования сетей с небольшим количеством компьютеров.

Длина кабеля, необходимого для всех помещений, рассчитывается
по формуле
(2)
Общий расчет кабеля методом суммирования вычисляется по
формуле

где n -
количество компьютеров; l - длинна сегмента кабеля;
Ks - коэффициент технологического
запаса - 1,3 (13%), который учитывает особенности прокладки кабеля, всех
спуски, подъемы, повороты, межэтажные сквозные проемы (при их наличии) и также
запас для выполнения разделки кабеля.
Длинна кабеля, необходимого для
каждого помещения, равна сумме длинн сегментов всех узлов этого помещения,
умноженного на коэффициент технологического запаса, например, если в помещении
располагаются три узла сети, то расчёт кабеля производится следующим образом

Таким образом, производится расчёт количества кабеля
для всех остальных помещений.
Расчёт необходимого количества кабеля
можно привести в таблице 4:
Таблица 4 - Расчёт необходимого количества
кабеля

№ п/п

Местоположение компьютера

Длина кабеля, м

Итого

1

Наименование кабинета (номер этажа) номер ПК

Например,

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

Таблица 5 - Спецификация оборудования

№ п/п

Наименование оборудования

Тип оборудования

Единица измерения

Количество

2.6
Планирование информационной безопасности
Определить необходимые меры по защите
информации, которые могут быть сгруппированы в организационные и технические
меры. Следует осуществить разграничение доступа к ресурсам.
Предусмотреть решения по бесперебойному питанию, резервному
копированию и антивирусной защите.
Важной задачей разработчика является
обеспечение нормативного уровня безопасности при проектировании сети. Эта
задача решается путём проработки тесно связанных между собой вопросов
безопасности при работе с инструментом и кабелем, поэтому в данном разделе
следует раскрыть следующие вопросы:
2.7 Требования безопасности при прокладке кабеля и
установке сети
В этом подразделе необходимо
рассмотреть следующие вопросы:
-
лица, допускающиеся к
установке сети;
-
меры безопасности при
прокладке кабеля;
-
требованиям, которым
должен отвечать электроинструмент;
-
правила охраны труда при
прокладке кабеля.
2.8 Требования к технике безопасности при работе с ПК
Особенности, характера и условия
труда работников, работающих на ЭВМ.
Мероприятия по снижению опасных факторов. Эргономические
требования к рабочему месту.

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

Таблица 6 - Краткий план сети

Характеристика

Значение

Тип сети

Топология

Тип кабеля

Пассивное оборудование

Архитектура сети

Метод доступа

Активное оборудование

Тип сервера

Аппаратное обеспечение сервера

Дополнительное оборудование

Сетевая операционная система

Локальная операционная система

Сетевой протокол

Графическая
часть
Графическая часть курсового проекта (работы) состоит из
следующих листов:
Лист 1 - Структурная электрическая схема
сети на формате A4
или формате А3.
Лист 2 - План расположения оборудования и
прокладки кабеля на формате А3.
При графическом оформлении по
принятым топологическим решениям в сети следует использовать программные
продукты Microsoft Visio, SPlan, 3D Home и им подобные, либо возможно
использование графических изображений отдельных устройств в сети, которые
используются в аналогичных программных продуктах.
Схема организации связей должна быть
выполнена в соответствии с основными требованиями, приведенными в ГОСТ 2.701-84
«ЕСКД. Схемы. Виды и типы. Общие требования к выполнению». Пример оформления
схемы организации связей приведен в Приложении Г данных методических рекомендациях.
При оформлении плана расположения
оборудования можно использовать условные обозначения, рекомендованные
стандартом ANSI TIA/EIA-606. Российские стандарты, принятые в 2010 г. - ГОСТ Р
53246-2008 «Информационные технологии. Системы кабельные структурированные.
Проектирование основных узлов системы. Общие требования» и ГОСТ Р 53245-2008
«Информационные технологии. Системы кабельные структурированные. Монтаж
основных узлов системы. Методы испытания». Оформление решений по размещению
оборудования можно рекомендовать осуществить путем наложения схемы размещения
на план помещений. Пример оформления плана расположения оборудования и
прокладки кабеля приведен в Приложении
Д данных методических рекомендациях. Обозначения некоторых
элементов коммуникационных средств (розетки, муфты, кроссы и т.п.), а также
обозначения на прокладку кабеля, рекомендуемые данным стандартом, приведены в
таблице 7.
Таблица 7 - Условные обозначения
коммуникационных средств

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

Рекомендуемая
литература
1.
Computerworld Россия
[Электронный ресурс]: [web-сайт]: Ведущий международный еженедельник,
посвященный информационным технологиям. http: //www. osp. ru/cw/
2.
Борисенко, А.А.
Локальная сеть [Текст]. - М.: Изд-во Эксмо, 2006. - 160 с.
3.
Журнал сетевых
решений/LAN [Электронный ресурс]: [web-сайт]: Журнал о компьютерных сетях,
средствах связи, системах передачи данных, управления сетями и проектами,
системах безопасности разного уровня. http://www.osp.ru/lan/
4.
Компъютерные сети.
Сертификация Network+ [Текст] : учебный курс / Microsoft Corporation; пер. с
англ. - М. : Русская Редакция, 2002. - 704 с.
5.
Кузин, А. В.
Компьютерные сети [Текст] : учеб. пособие / А. В. Кузин, В. М. Демин. - 2-е
изд. - М. : ФОРУМ, 2008. - 192 с.
6.
Макин, Дж. К.
Развертывание и настройка Windows Server 2008. Учебный курс Microsoft [Текст] =
Configuring Windows Server 2008 applications infrastructure / Макин, Дж. К.,
Десаи, Анил ; пер. с англ. - М. : Русская редакция, 2011. - 640 с.
7.
Максимов, Н. В.
Компьютерные сети [Текст] : учеб. пособие для студентов учреждений сред. проф.
образования / Н. В. Максимов, И. И. Попов. - 4-е изд. пере- раб. и доп. - М. :
ФОРУМ, 2010. - 464 с.
8.
Олейник, В.Ф.
Современные беспроводные сети: состояние и перспективы развития [Текст]:
Учебное пособие / И.А. Гепко, Олейник В.Ф., Ю.Д.Чайка, А.В. Бон- даренко; под
ред. В.Ф. Олейника. - М.: Изд-во Эксмо, 2009. - 672 с.
9.
Олифер, В.Г., Олифер,
Н.А. Компьютерные сети. Принципы, технологии, протоколы [Текст]: Учебник. 4-е
издание. - СПб.: Питер, 2010. - 944 с.
10.
Основы компьютерных
сетей [Текст + Электронный ресурс]: [CD]: Методическое пособие.- М.: БИНОМ.
Лаборатория знаний, 2006. - 55 с.
11.
Проектирование локальной
компьютерной сети предприятия [Электронный ресурс] / - Режим доступа:
http://createlan.net/
12.
Сети/Network World
[Электронный ресурс]: [web-сайт]: Журнал о технологиях, услугах и решениях для
организации всех видов связи и коммуникаций на предприятиях. http://www.osp.ru/nets/
13.
Служба Active Directory. Ресурсы Windows Server 2008 [Текст] = Active Directory. Resourse Kit. Windows Server 2008 /
Раймер, Стен [и др.] ; пер. с англ. - СПб. : Питер, 2009. - 816 с.
14.
Суперкомпьютеры
[Электронный ресурс]: [web-сайт]: Электронный журнал о достижениях
суперкомпьютерной техники. http://www.supercomputers.ru
15.
Тепляков, И. М.
Телекоммуникационные системы. Сборник задач [Текст]. - М.: РадиоСофт, 2008. -
240 с.
16.
Учебная мастерская
[Электронный ресурс]: [web-сайт]: Мастерская Dr_dimdim. http: //www. edu.
BPwin.ru
17.
Хакер Online
[Электронный ресурс]: [web-сайт]: Новости и открытия в мире компьютерных
технологий и сетей. http://www.xakep.ru
18.
ЦИТфорум [Электронный
ресурс]: [web-сайт]: Новейшие компьютерные технологии. http://www.citforum.ru
19.
Электронное
периодическое издание Ferra.Ru («Ферра.Ру») [Электронный ресурс]: [web-сайт]:
Последние новости в компьютерном мире. http://www.ferra.ru

Приложение Б

Приложение Б

Скачано с www.znanio.ru

file_name: методичка - содержание.docx

alt: Выбор оборудования и типа кабеля

alt: Например, Эмпирический метод реализует на практике положение известной центральной предельной теоремы теории вероятностей и, как показывает опыт разработки, дает хорошие результаты для кабельных систем с…

alt: Список используемых источников

alt: Макин, Дж. К. Развертывание и настройка

alt: Приложение Б

alt: Приложение Б

title: Методические рекомендации по выполнению курсовой работы по М ДК 03.01


extracted_text:
Задания олимпиады по русскому языку для 9 класса

Фамилия, имя участника
Возраст участника                        Наименование образовательной организации                                                                                Населенный пункт
ФИО руководителя                                                                    Должность руководителя

1.
Назовите
как можно больше однокоренных слов с корнем – город-. Составь с ним
словосочетания, вставляя однокоренные слова.

Житель …,  маленький …,
плохонький …, …поезда, русские …

2.      Сложи части и получи сложные слова.
Сам               хозяйка
Дом               пашец
Чист+ О/Е+водитель
Пут              стоятельный
Земл              плотный

3.
«Четвёртый лишний». В
каждой строчке подчеркни «лишнюю» часть речи.
Юноша, мужчина,
старый, старик.
Они, вы, в, я.
Звонкий, звонишь,
стучат, топаем.
Над, от, он, без.
Краснею, чёрный,
синяя, золотой.

4.
В данных существительных
поставьте, где нужно, мягкий знак.
Доч _, меч
__, товарищ __, луж __, обруч __, молодёж__, из училищ __, полноч __, из чащ __,
помощ __, тиш __, без галош __, брош __, от туч __

5.
К глаголам
дружу, дружите,
дружишь, дружит, дружим, дружат подберите местоимения. Укажите их лицо и число.

6.
Укажите, какой приставки
нет в русском языке?
o   На-
o   Но-
o   С-
o   Об-
7.
Как вы назовёте то, что
принадлежит собаке? Запишите получившиеся словосочетания (прил + сущ).
_____________________
конура, ______________________ преданность, _____________________
ошейник,    ____________________ нюх, __________________ рычанье

8.      Запишите правильно словосочетания, подбирая  в каждой
строке нужное имя собственное.
страна
Толстой
край
Ленина
город
Россия
улица
Пермский
писатель
Москва
_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

9.
Запиши
сложные предложения. Вставьте
пропущенные буквы, раскройте скобки и
расставьте запятые.

1.Язык существу..т для
того чтобы люди общ..лись дру.. (с) друг..м.  2.Все пас..ажиры высыпали (на)
палубу когда вд..ли п..казался город.  3.Дети см..трели туда где гасли
п..следние лучи вечерн..й зари.

10.
Составь рассказ на тему
«Зима», используя слова: зима, ветер, небо, земля, река, деревья, дети.

file_name: 9 класс русский язык.docx

alt: Запиши сложные предложения.

title: Разработка олимпиадных заданий по русскому языку для обучающихся с ОВЗ


extracted_text:
Тема: «Воздушный и водный транспорт».
Цель: расширить знания у детей о
воздушном и водном транспорте.
Закреплять знания о водном и воздушном транспорте.
Воспитывать в детях интерес работать коллективно.
Актуализация: закрепления представления о
«водном и воздушном транспорте»
Оборудование: макеты лодки, вертолета,
картинки с изображением воздушного и водного транспорта.
Ход урока:
1.       Организационный
момент: игра «Приветствие» (дети встают в круг)
Собрались сегодня с вами,
Чтобы всем нам стать друзьями,
По играть, по веселится
И чему-то научиться.
«Что это» (дети рассматривают картинки разного
транспорта и дают им название)
-Как называется транспорт который перевозит пассажиров?
-Как называют транспорт который перевозит больных?
-Как называют транспорт который «тушит пожар»?
-Какой транспорт возит грузы?
-Какой транспорт летает в воздухе?
-Какой транспорт идет по воде?
-Какой транспорт важней?
2. Работа по картинкам.
Задание: рассмотреть картинки, объяснить назначение корабля,
лодки, самолета, вертолета.
Ознакомление с основными частями корабля:
-Перед корабля называется носом, корма-задняя часть корабля,
горизонтальные площадки – палубы, их может быть несколько, друг над другом как
этажей в доме, обязательным для кораблей должно быть наличие якоря, у
современных кораблей вместо паруса установлена силовая установка из турбин или
судовых дизелей, каюта это комната на корабле, а окна называют иллюминаторы, и
конечно же штурвал- руль корабля.
3. Физминутка
От зеленого причала
Оттолкнулся пароход (встать)
Он шагнул назад (шаг назад)
А потом шагнул вперед (шаг вперед)
И поплыл, поплыл по речке (движение руками)
Набирая полный ход (ходьба на месте)
Ознакомление с вертолётом.
Без разгона в высь взлетает
Стрекозу напоминает,
Отправляется в полет
Быстроходный….(вертолет)
-Вертолет напоминает стрекозу не только внешне, но и летает
он как стрекоза. Вертолет зависает в воздухе, хоть он и не летает так быстро
как самолет, но при этом самолет не может просто остановиться в воздухе. Если
самолета нужна взлетная полоса, то вертолет может подняться в воздух с любой
ровной площадки.
Давайте внимательно рассмотрим наш вертолет, и определим из
чего он состоит.
-На крыше вертолета расположен несущий винт, лопасти
которого вращаются напоминая вентилятор. Благодаря ему вертолет поднимается в
воздух. А на хвосте можно увидеть маленький пропеллер – рулевой винт. Благодаря
ему вертолет находится в устойчивом положении и не вращается вместе с
лопастями. Если у вертолета откажет двигатель, то он не упадет, а плавно
опустится на землю. Так же у вертолета имеется шасси и кабина пилотов.
4. Классификация воздушного и водного транспорта.
-Какой транспорт ходит по воде, как он называется?
(Рассматривание иллюстраций)
-Какой транспорт называется воздушный? (Рассматривание
иллюстраций)
5. Игра «Что лишнее?»
Дети выбирают лишнюю картинку из предложенных
6. Физминутка  (дети имитируют движения транспортных
средств).
Сели
на машину. Налили бензина.
На
машине ехали, до реки доехали.
Стоп.
Разворот. На реке пароход.
Пароходом
плыли, до горы доплыли,
Пароход
не везет. Надо сесть в самолет.
Самолет
летит, в нем мотор гудит: у-у-у.
7. Игра «Едет, летает, плывёт»
Соответственно названному транспорту дети
выполняют движения: наземный- топают, воздушный- руки в стороны, водный-
руками изображают «волну».
8. Рефлексия.
Ребята чем мы сегодня занимались?
Что вы узнали нового? Что вам больше всего понравилось?

file_name: водный и воздушный транспорт.docx

alt: Тема: «Воздушный и водный транспорт»

title: Конспект по окружающему социальному миру "Воздушный и водный транспорт"