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

Размещено на http://www.allbest.ru/

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

Москва

2018 г.

СОДЕРЖАНИЕ

РЕФЕРАТ

ОПРЕДЕЛЕНИЯ

ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

ВВЕДЕНИЕ

1. НЕОБХОДИМОСТЬ ПРОЕКТА

1.1 Обоснование необходимости проекта

1.2 Видение проекта

1.3 Анализ выгод

2. КОНЦЕПЦИЯ РЕШЕНИЯ

2.1 Цели и задачи проекта

2.2 Предположения и ограничения

2.3 Анализ использования

2.3.1 Пользователи

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

2.4 Требования функциональности

2.4.1 Требования пользователей

2.4.2 Системные требования

3. РАМКИ РЕШЕНИЯ

3.1 Функциональность решения

3.2 За рамками решения

3.3 Критерии одобрения решения

4. СТРАТЕГИИ ДИЗАЙНА РЕШЕНИЯ

4.1 Стратегия архитектурного дизайна

4.2 Стратегия технологического дизайна

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ



РЕФЕРАТ

Отчет «Разработка концепции проекта», 30 листов, 7 рисунков, 10 источников.

Ключевые слова: концепция проекта, рамки решения, стратегии дизайна.

Целью выполнения отчета является разработка концепции проекта.

Задачи работы:

· Обоснование необходимости проекта.

· Разработка концепции решения.

· Обоснование рамок решения.

· Разработка стратегии дизайна решения.



ОПРЕДЕЛЕНИЯ

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



ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

АНО	--	автономная некоммерческая организация
ИС	--	информационная система
ИТ	--	информационные технологии
ТЗ	--	техническое задание
email	--	electronic mail - электронная почта
MySQL	--	My Structured Query Language - свободная реляционная система управления базами данных
SQL	--	Structured Query Language - язык структурированных запросов
UML	--	Unified Modeling Language -- унифицированный язык моделирования

ВВЕДЕНИЕ

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

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

В отчете рассмотрены следующие основные вопросы:

Раздел 1 Необходимость проекта, включая: обоснование необходимости проекта, видение проекта, анализ выгод.

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

Раздел 3 Рамки решения, включая: функциональность решения, за рамками решения, критерии одобрения решения.

Раздел 4 Стратегии дизайна решения, включая: стратегию архитектурного дизайна, стратегию технологического дизайна.



1. НЕОБХОДИМОСТЬ ПРОЕКТА

1.1 Обоснование необходимости проекта

Основные характеристики компании

Заказчиком выступает автономная некоммерческая организация «Институт дизайна», сокращенно - «АНО «Институт дизайна» (далее по тексту - институт) с государственной аккредитацией. Высшим органом управления институтом является общее собрание учредителей института. Непосредственно руководит институтом исполнительный директор, которому подчиняются заместитель директора, все отделы, факультеты и сотрудники; ориентировочное число сотрудников - 40 - 60 человек.

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

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

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

Необходимость проекта

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

За последние два года количество студентов, обучающихся на дистанционном обучении, увеличилось почти в три раза: с 80 до 225 студентов. Текущая организация взаимодействия со студентами посредством электронной почты устарела, так как преподаватель физически не успевает отвечать на десятки электронных писем в день.

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

1.2 Видение проекта

Видение (vision) - это ничем не ограничиваемое представление о том, каким должно быть решение (solution). Видение проекта направлено на формирование у всех вовлеченных в проект сторон единого понимания его концепции. Формулировка видения (vision statement) должна быть достаточно краткой для запоминания, достаточно ясной для понимания и достаточно сильной для мотивирования. Хорошая формулировка видения ориентируется на пять SMART характеристик:

· Specific (определенность/конкретность) - видение четко указывает на то (идеальное) состояние, достижение которого является целью проекта.

· Measurable (измеримость) - дает проектной группе четкий критерий успешности проекта и достижения поставленных целей.

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

· Relevant (обоснованность) - цели, сформулированные в видении, должны иметь существенное значение для заинтересованных сторон и напрямую быть связанными с их проблемами и/или потребностями.

· Time-based (ограниченность во времени) - видение должно четко указывать на ожидаемые временные рамки, в которые решение будет достигнуто.

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

1.3 Анализ выгод

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



2. КОНЦЕПЦИЯ РЕШЕНИЯ

2.1 Цели и задачи

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

· Администрация вуза: цель - увеличить количество студентов за счет повышения производительности преподавателей.

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

· Студенты: цель - получить более качественное преподавание дисциплины «Дизайн» за счет использования более удобного инструмента обучения.

Все цели каждой заинтересованной стороны объединяются в единую, общую цель всего проекта: разработка электронного учебного комплекса по дисциплине «Дизайн» для дистанционного обучения студентов.

Для достижения поставленной цели необходимо решить следующие задачи:

· Изучить предметную область, составить список требований к создаваемому учебному комплексу.

· Выбрать средства проектирования электронного учебного комплекса.

· Построить функциональную и логическую модели.

· Спроектировать макеты основных форм пользовательского интерфейса.

· Выбрать средства реализации электронного учебного комплекса.

· Реализовать комплекс на основе созданных проектов с помощью выбранных средств реализации.

· Написать руководство пользователя разработанного комплекса.

· Внедрить комплекс в процесс обучения студентов дистанционного обучения.

2.2 Предположения и ограничения

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

Для института основные предположения и ограничения следующие: разрабатываемый комплекс должен быть выполнен в виде web-сайта, доступ к которому возможен из глобальной сети интернет. Весь контент, представленный на сайте, должен быть защищен от несанкционированного доступа с помощью авторизации пользователей.



2.3 Анализ использования

2.3.1 Пользователи

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

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

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

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

Диаграмма вариантов использования системы каждой группой пользователей представлена на рисунке 1.

Рисунок 1 - Диаграмма вариантов использования

Преподаватель выполняет первоначальную загрузку материалов: (методических указаний к лабораторным работам) и вводит вопросы для тестов. Сценарии данных вариантов использования представлены на рисунках 2 и 3



Рисунок 2 - Диаграмма сценария для варианта «Загрузка материалов»

Рисунок 3 - Диаграмма сценария для варианта «Ввод вопросов для тестов»

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

Рисунок 4 - Диаграмма сценария для варианта «Выполнение лабораторных работ»



Рисунок 5 - Диаграмма сценария для варианта «Решение тестовых заданий»

Затем преподаватель выполняет проверку результатов студента (отчета о лабораторной работе и оценку за тесты). Диаграмма сценария для варианта «Проверка результатов» представлена на рисунке 6.



Рисунок 6 - Диаграмма сценария для варианта «Проверка результатов»

2.4 Требования функциональности

2.4.1 Требования пользователей

Для преподавателя важны следующие функциональные требования:

· управление лабораторными работами;

· управление тестами, вопросами и вариантами ответов к ним;

· управление пользователями;

· проверка результатов выполнения заданий;

· уведомления на e-mail об основных событиях.

Для студента важны следующие функциональные требования:

· изучение материалов, просмотр лабораторных работ;

· загрузка отчетов о выполнении;

· возможность задать преподавателю вопрос;

· уведомления на email об основных событиях.

2.4.2 Системные требования

Необходимо реализовать следующие функции:

· Групповая политика пользователей: разделение доступа к различным функциям, в зависимости от группы пользователя;

· Загрузка файлов как преподавателями, так и студентами;

· Изменение всех учебно-методических материалов, представленных на сайте (только пользователями, находящимися в группе преподавателей);

· Доступ в любое время с любого устройства, имеющего выход в интернет;

· Хранение конфиденциальных данных в базе данных в зашифрованном виде.

Разрабатываемая информационная система будет реализована в виде web-сайта, размещена на хостинге для обеспечения возможности беспрерывного доступа к ИС из сети Интернет.



3. РАМКИ РЕШЕНИЯ

3.1 Функциональность решения

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

Рамки решения определяют функциональность решения и его возможности. Функциональные рамки проекта составляет консультант/аналитик - сотрудник проектной команды исполнителя - на основе интервью с ключевыми специалистами заказчика.

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

Функции преподавателя.

Работа с учебно-методическими материалами:

· Добавление/изменение/удаление лабораторных работ и файлов к ним;

· Скрытие лабораторной работы из общего списка доступных студенту работ (без удаления работы с сайта);

· Просмотр результатов выполнения лабораторной студентами, оценивание и комментирование отчетов по лабораторным.

Работа с тестами:

· Добавление/изменение/удаление тестов, а также вопросов для тестов и вариантов ответов к ним;

· Скрытие всего теста или его отдельного вопроса из доступных студенту.

Работа с пользователями:

· Добавление и изменение пользователей;

· Просмотр результатов выполнения заданий каждым пользователем;

· Блокировка пользователю доступа к системе.

· Функции студента:

· Просмотр лабораторных работ и скачивание прикрепленных к ним файлов;

· Прохождение тестов;

· Дополнительные возможности:

· в тестах имеется два типа вопросов: с одним правильным вариантом ответа и с несколькими;

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

· просмотр истории прохождения тестов.

· уведомления на email пользователя о ключевых событиях в ИС.



3.2 За рамками решения

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

3.3 Критерии одобрения решения

Решение будет считаться одобренным, если будут корректно реализованы все заявленные функции и возможности.



4. СТРАТЕГИИ ДИЗАЙНА РЕШЕНИЯ

4.1 Стратегия архитектурного дизайна

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

Для описания архитектурного дизайна воспользуемся диаграммой компонентов (рисунок 7).

Рисунок 7 - Диаграмма компонентов

В программе имеется три главных компонента: база данных для хранения данных, пользовательский интерфейс для просмотра этих данных и формы ввода информации.

Взаимодействие с базой данных осуществляется с помощью отправки SQL-запросов и обработки результатов и выполнения.

4.2 Стратегия технологического дизайна

Разработка решения потребует использования определенных продуктов и технологий. Стратегия технологического дизайна (technical design strategy) описывает, какие технологии и продукты выбраны проектной группой в качестве средства реализации решения. Для реализации электронного учебного комплекса необходимо выбрать язык программирования для создания пользовательского интерфейса и систему управления базой данных для создания базы данных.

В качестве языка программирования был выбран язык PHP.

PHP (PersonalHomePageTools - «Инструмент для создания персональных веб-страниц») - является скриптовым языком программирования общего пользования, используемый для создания Web-приложений. В данный момент времени поддерживают подавляющие большинство хостинг-провайдеров и стал одним из ведущих языком программирования, использующих для разработки динамических Web-сайтов.

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

· автоматически извлекаемые GET и POST-параметров, а также переменных окружения веб-сервера в предопределённые массивы;

· взаимодействует с очень большим количеством разных СУБД (MySQL, SQLite,MySQLi, Oracle (OCI8), PostgreSQL, Microsoft SQL Server и пр.);

· автоматическая отправка HTTP-заголовков;

· работает с HTTP-авторизацией;

· работает с сессиями и cookies;

· работает с удалёнными и локальными файлами, сокетами;

· обрабатывает файлы, загруженные на сервер;

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

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

Для данного проекта был выбран фреймворк Symfony 2 - полностью бесплатный фреймворк, написанный на PHP5, который использует паттерн Model-View-Controller.

Symfony предлагает быструю разработку и управление веб-приложениями, позволяет легко решать рутинные задачи веб-программиста. Работает с разлиными версиями PHP. Имеет поддержку множества баз данных (MySQL, PostgreSQL, SQLite или любая другая PDO-совместимая СУБД). Информация о реляционной базе данных в проекте связывается с объектной моделью.

В качестве системы управления базой данных была выбрана СУБД MySQL.

MySQL - разработка шведской компании MySQL AB. СУБД MySQL является программным обеспечением с открытым исходным кодом, распространяемым по лицензии GNU (GPL) и коммерческой лицензии для ситуаций, не подпадающих под действие лицензии GPL.

MySQL поддерживает реляционную модель данных, т. е. представляет собой реляционную СУБД.



ЗАКЛЮЧЕНИЕ

Целью выполнения отчета является разработка концепции проекта.

Получены следующие основные результаты.

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

2. Разработана концепция решения, в том числе цели и задачи проекта, предположения и ограничения, анализ использования, требования функциональности. Основные предположения и ограничения следующие: разрабатываемый комплекс должен быть выполнен в виде web-сайта, доступ к которому возможен из глобальной сети интернет. Весь контент, представленный на сайте, должен быть защищен от несанкционированного доступа с помощью авторизации пользователей.

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

4. Сформирована и обоснована стратегия дизайна решения, включая стратегию архитектурного дизайна и стратегию технологического дизайна.

5. Для описания архитектурного дизайна используется диаграмма компонентов. В программе имеется три главных компонента: база данных для хранения данных, пользовательский интерфейс для просмотра этих данных и формы ввода информации.

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



СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Архипенков С. Лекции по управлению проектами. http://arkhipenkov.ru/index.files/publications.htm.

2. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. - 2-е изд., перераб. и доп. - М.: Финансы и Статистика, 2006. - 544 с.

3. Вендров А. М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. Пособие. - М.: Финансы и статистика, 2006.

4 Вендров А. М. CASE-технологии. Современные методы и средства проектирования информационных систем. - М.: Финансы и статистика.

5. Сапожкова Т.Е. Интернет-курс по дисциплине «Проектирование информационных систем» М. 2010

6. https://cyberpedia.su/14x5a0c.html

7. http://vuz.edunetwork.ru/faq-f/9

8. http://pcnews.ru/blogs/diagramma_scenariev_ispolzovania_v_processe_razrabotki_po-728283.html

9. https://www.syl.ru/article/206012/new_uml-diagramma-vidyi-diagramm-uml

10. http://pandia.ru/text/78/181/39488.php

Размещено на Allbest.ru