12. Вид и назначение диаграммы сценариев Use case diagram.

Диаграмма прецедентов (use case) или вариантов использования показывает совокупность прецедентов и действующих лиц (actor), а также отношения между ними. Прецеденты - это не зависящее от реализации высокоуровневое представление того, что пользователь ожидает от системы, т.е. описание функциональности системы. Действующее лицо - это все, что взаимодействует с создаваемой системой. Варианты использования и действующие лица определяют сферу применения создаваемой системы. При этом прецеденты описывают все то, что происходит внутри системы, а действующие лица - то, что происходит снаружи. На языке UML действующие лица представляются в виде значков фигур, а варианты использования - в виде овалов

В UML для вариантов использования и действующих лиц поддерживается несколько типов связей:

- связи коммуникации описывают связи между действующими лицами и вариантами использования,

- связи расширения (extends) и использования (uses) отражают связи между вариантами использования,

- обобщения действующего лица описывают связи между действующими лицами.

13. Процессный подход к разработке по. Стандарты CobIt, itil, Scrum.

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

Таким образом, основные задачи автоматизации можно представить в виде набора «кубиков» (процессов), у которых информационные входы одних связаны с информационными выходами других.

CobiT (сокращение от Control Objectives for Information and Related Technology («Задачи информационных и смежных технологий») — представляет собой пакет открытых документов, около 40 международных и национальных стандартов и руководств в области управления IT, аудита и IT-безопасности. Задача CobiT заключается в ликвидации разрыва между руководством компании с их видением бизнес-целей и IT-департаментом, осуществляющим поддержку информационной инфраструктуры, которая должна способствовать достижению этих целей.

CobiT, благодаря единой терминологии, служит своеобразной платформой-буфером для конструктивного диалога между всеми участниками бизнеса:

топ-менеджерами;

руководителями среднего звена (IT-директором, начальниками отделов);

непосредственными исполнителями (инженерами, программистами и т. д.);

аудиторами.

В CobiT детально описаны цели и принципы управления, объекты управления, чётко определены все IT-процессы (задачи), протекающие в компании, и требования к ним, описан возможный инструментарий (практики) для их реализации. В описании IT-процессов также приведены практические рекомендации по управлению IT-безопасностью.

Кроме того, CobiT вводит целый ряд показателей (метрик) для оценки эффективности реализации системы управления IT, которые часто используются аудиторами IT-систем. В их число входят показатели качества и стоимости обработки информации, характеристики её доставки получателю, показатели, относящиеся к субъективным аспектам обработки информации (например стиль, удобство интерфейсов). Оцениваются показатели, описывающие соответствие компьютерной IT-системы принятым стандартам и требованиям, достоверность обрабатываемой в системе информации, её действенность, общепринятые показатели информационной безопасности — конфиденциальность, целостность и доступность обрабатываемой в системе информации.

Управление IT по CobiT можно представить в следующем ступенчатом виде (по порядку реализации):

Стратегии (выстраивание IT-процесса по бизнес-целям, постановка задачи, цели и создание концепции IT-процесса; ответственные: руководство бизнес-подразделений).

Политики (методы достижения целей в рамках стратегий, например: «длина пароля регламентируется»; ответственные: руководство IT-подразделений).

Стандарты (метрики для политик-методов, например: «длина пароля должна составлять не менее 8 символов»; ответственные: руководство IT-подразделений).

Процедуры (регламенты работ для применения политик-методов с использованием стандартов-метрик, рабочие инструкции для исполнителей; ответственные: руководство IT-подразделений).

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

ITIL (произносится как «айти́л», англ. IT Infrastructure Library — библиотека инфраструктуры информационных технологий) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

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

Использованный в библиотеке процессный подход полностью соответствует стандартам серии ISO 9000 (ГОСТ Р ИСО 9000). Процессный подход акцентирует внимание предприятия на достижении поставленных целей, анализе ключевых показателей "эффективности" (KPI), а также на ресурсах, затраченных на достижение этих целей.

Наиболее известная часть ITIL — десять базовых процессов, обеспечивающих поддержку и предоставление ИТ сервисов — IT Service Management или ITSM:

Процесс управления инцидентами

Процесс управления проблемами

Процесс управления конфигурациями

Процесс управления изменениями

Процесс управления релизами

Процесс управления уровнем услуг

Процесс управления мощностями (ёмкостью)

Процесс управления доступностью

Процесс управления непрерывностью

Процесс управления финансами

Кроме того, в структуре процессов ITSM важную роль играет служба поддержки пользователей — Service Desk.

Scrum — методология управления разработкой информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки. Кроме управления проектами по разработке ПО Scrum может также использоваться в работе команд поддержки программного обеспечения (software support teams), или как подход управления разработкой и сопровождением программ.

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

Спринт — итерация в скрам, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно Scrum стандарту Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объема работ в спринте можно использовать предварительную оценку, измеряемую в очках истории, где 1 очко истории приблизительно равно 1 человекодню. Предварительная оценка фиксируется в резерве проекта. На протяжении спринта никто не имеет права менять список требований к работе, внесенном в резерв проекта.

Резерв проекта — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются «пожеланиями пользователя» (user story) или элементами резерва (backlog items). Резерв проекта открыт для редактирования для всех участников скрам процесса.

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